Rpi 3.9.y please pull into 3.9 branch. Changes are below: use of CONFIG_USB_FIQ_ENABLED instead of fiq_fix_enabled in USB also fixing issues with timeouts during I2C clock stretching in i2c-bcm2708 driver.

[vkorehov]

1. (essential)I've replaced fiq_fix_enable with a proper config (CONFIG_USB_FIQ_ENABLED and by default it is Y), because variable checks were missing in quite a few places and it still used local_fiq_disable, in few places which I did not want at all.

2. (non-essential)I've added special driver (rpi2c) which is replacing bcm2708_gpio.c in arch/arm/mach-bcm2708 folder. This is disabled by default, so you have normal gpio module loaded. In Case you want to receive I2C events (with basic I2C slave support: receive only!) in rpi, then you can enable my module and you can still use i2c-bcm2708.c for master mode. they integrate nicely. Only thing is to add back GPIO functionality on unused GPIO pins (basically copy/paste from bcm2708_gpio.c driver) Also need some thinking how to integrate FIQ handler with remaining GPIO pins, because FIQ currently will receive interrupts form IRQ_GPIO0 and IRQ_GPIO0 is disabled now. Only GPIO1 is enabled and GPIO2 could be enabled also. for RPI this only leaves 3 pins to be able to take adwantage of interrupts (28..31 and one pin is reserved for existing GPIO handler in this driver)
   This driver uses trick to hardwire IRQ_GPIO1 with FIQ_GPIO0 so driver will gett notifications on IRQs just after FIQ handler finished, and then it is able to send nitifications about completion of reads for all pending reads. in FIQ you cannot call kernel functions. SO this is one way how to owercome this limitation. Which work very reliably and I had no crashes.

3. (essential) while f**ing alot with making Rpi work with PIC microcontrollers I2C (this time using standard i2c-bcm2708 driver in Master mode) I found issues with related to clock stretching for flash writes (i'm developing bootloader for PIC) . I found that dramatic improvement is to disable bcm2708 clock stretching timeout (writing zero) feature. I've put a kernel param so if someone needs it then he could reenable default timeout of 0x40 cycles. Putting zero solved almost all of isues of marrying PIC and bcm2708 in master mode. And clock stretching works nicely during ACK phase, I've confirmed with oscilloscope.

[P33M]

So, which of these 3 pull requests you have open should I consider?

[vkorehov]

only the last one(this one) from me, please close over ones for wrong branch combinations, etc.
it is first time I'm using this feature on github

[P33M]

This PR is unmergeable in its current state.

I suggest you go read https://www.kernel.org/doc/Documentation/SubmittingPatches - note that most of it will be irrelevant because a) we're not the actual kernel and b) the github interface obviates much of the technical requirements. In particular, Section 1 parts 2, 3 & 4 and most of section 2.

As I can see it, there are two separate features you are requesting to be added;

First is having a nicer USB driver if another FIQ handler is registered, and the FIQ for the USB is disabled. This should not be a compilation option - we will ship only a single version of the kernel and it will only be with the FIQ compiled-in. It would be much better if your changes were runtime dependent on the fiq_fix_enable module parameter.

The second is your FIQ bitbashed implementation of I2c - this is interesting because of certain hardware limitations of the BSC serial controller that you correctly describe. You will be a bit limited because in the BCM2835 architecture, the ARM interrupt controller can nominate only a single interrupt source to trigger the FIQ.

You seem to have squashed other "fixes" into it - namely setting the ACK timeout to 0 in the existing driver produces "better" behaviour. This again would be better as a separate request, with more information - example scope waveforms or link to a forum post that found this out would be nice.

If you want to submit multiple pull requests for these features in future, then create separate branches in your github repo and create PRs from each branch.