Re: [PATCH v3] mfd: ADP5520 Multifunction LCD Backlight and KeypadInput Device Driver

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

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.