"Chemparathy, Cyril" <[email protected]> writes: > Hi, > >> I'm not crazy about this approach. >> >> Both the existing functions and the new functions all do basically the same >> thing: >> - read base + offset >> - set/clear bit(s) based on GPIO# >> - write base + offset >> >> I think a cleaner solution to this would be to clean the existing GPIO >> layer of direct knowledge of register layout. Instead, convert the >> gpio_controller struct into struct that holds register offsets from a >> base. This array of offsets is what needs to be different between >> davinci and tnetv107x. > > Agreed. I'll work on this a bit and propose a more generic implementation. > >> Also, Re: locking. You shouldn't need to globally disable interrupts >> here. What I'm guessing you need is a mutex. > > My intent was to keep the gpios non-sleeping (gpio_can_sleep() == 0) > so that they remain usable in interrupt handlers.
Then you should be using spin_lock_irq* instead of a global IRQ disable. Locks should always be as fine grained as possible. Even better would be to make the spinlock bank specific so only concurrent accesses to the same bank would need to be serialized. Kevin > Since mutexes might_sleep(), we can't really use them to serialize > register read-modify-write. I think that the read-modify-write > itself shouldn't take more than a few cycles, and therefore > disabling interrupts for the duration should be ok. _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
