Messages in this thread | | | Date | Wed, 7 Oct 2009 14:03:37 +0100 | From | Mark Brown <> | Subject | Re: [PATCH v3] mfd: ADP5520 Multifunction LCD Backlight and KeypadInput Device Driver |
| |
On Wed, Oct 07, 2009 at 01:11:40PM +0100, Hennerich, Michael wrote:
> In case I would have done the whole ADP5520 in a single file exposing > functionality to the input, backlight, led and gpio infrastructure - I > probably wouldn't find a subtree maintainer that is likely to merge this > blob.
Why do you say this?
> But apart from the GPIO interrupt capabilities - I wouldn't need doing > an interrupt controller. > I think you agree.
I'm not sure I do, TBH - if there's more than one
> So this notifier chain seemed like a good approach to notifiy the > input/keypad/adp5520-keys about some work. BTW - this approach is used > by other drivers for exactly the same reason too.
The only ones using the specific approach are da903x and ab3100, both of which predate the availability of the genirq improvements.
> Honestly - I'm not yet convinced that this new irq stuff really works in > combination with my ADP5520 Low Level IRQ. > My chained_handler (for demux) as well as irq_desc .mask .unmask .ack > and .set_type need to also be allowed to invoke sleeping i2c > transfers!!!?
You don't need to use chained_handler explicitly. You can just use a regular threaded IRQ handler for the primary IRQ, register an IRQ chip for the IRQs it provides then call handle_nested_irq() from within the primary IRQ handler. The chaining is only needed if running in hard IRQ context.
The bus_lock stuff is there so that mask, unmask and ack don't need to do I2C interactions. The idea is that you update local variables in those and then when sync_unlock() is called you write out all the changes to the device. The framework is set up to cope with this.
> I should do following: (unfortunately this is all on the bleeding edge > of technology, with no example driver actually using this craft)
I have a patch for wm831x which does the switchover to the new model - I hope to be able to publish it very soon, I did some blind changes that I need to test. I'll include you in the CCs when I post it.
> >I think I forgot to mention it previously but there's some work on > >getting a standard ALS interface in the kernel too. I'd really expect > >the GPIOs to end up being used as GPIOs in some designs as well.
> This is really interesting. Do you know where this discussion currently > takes place, and who is taking the lead (came up with a proposal)?
Not precisely, though there's an active thread 'New home for DS1682 driver' on the I2C list with some mutterings about it - it should at least give some pointers for further archive trawling.
| |