[RFC] What is the preferred way to share ADC unit between hwmon and input(ts) drivers?

[RFC] What is the preferred way to share ADC unit between hwmon and input(ts) drivers?

[Ilya Yanok]

Hello,

we are working with Freescale i.MX25 SoC which has the same register
space for ADC and touch-screen controller (AFAIK, that's pretty common
situation).
So, to add both input and hwmon drivers we need to serialize the
register accesses. I was thinking about adding some middle-layer to
perform the actual conversion. The question is what is the preferred way
to add such a middle layer? Should we use a multi-function device driver
for this or just some platform-specific code (as S3C does)? Or maybe
there is another way?
We hope to push our changes upstream so I'd like to know how such thing
is supposed to be implemented.

Thanks.

Regards, Ilya.

[RFC] What is the preferred way to share ADC unit between hwmon and input(ts) drivers?

[Kurt Van Dijck]

On Mon, Apr 25, 2011 at 04:37:38AM +0400, Ilya Yanok wrote:
> Hello,
> 
> we are working with Freescale i.MX25 SoC which has the same register
> space for ADC and touch-screen controller (AFAIK, that's pretty common
> situation).
> So, to add both input and hwmon drivers we need to serialize the
> register accesses.

1 physical device may contain several 'class_device's, even if they're of
different types.  So in a single platform_device probe function, you can do
both 'input_register_device' and 'hwmon_register_device'.
This way of working actually puts 2 drivers in 1 file, and let those
share 1 lock (mutex or so). A peripheral with 2 functions mixed together
should IMHO be addressed this way. Your driver is the coupling
between hardware (mixed functions) and Linux device model (clean seperation).

> I was thinking about adding some middle-layer to
> perform the actual conversion. The question is what is the preferred way
> to add such a middle layer?

IMHO a middle layer for this type of problem is a bit overkill.

> Should we use a multi-function device driver
> for this or just some platform-specific code (as S3C does)? Or maybe
> there is another way?

AFAIK MFD is a solution when multiple devices have sequential register maps.
MFD does no locking.

Just my ideas...
Maybe I don't understand your problem exactly...

Kurt

[RFC] What is the preferred way to share ADC unit between hwmon and input(ts) drivers?

[Ilya Yanok]

Hello Kurt,

On 25.04.2011 09:25, Kurt Van Dijck wrote:
>> So, to add both input and hwmon drivers we need to serialize the
>> register accesses.
> 
> 1 physical device may contain several 'class_device's, even if they're of
> different types.  So in a single platform_device probe function, you can do
> both 'input_register_device' and 'hwmon_register_device'.
> This way of working actually puts 2 drivers in 1 file, and let those
> share 1 lock (mutex or so). A peripheral with 2 functions mixed together
> should IMHO be addressed this way. Your driver is the coupling
> between hardware (mixed functions) and Linux device model (clean seperation).

Yes, I know this is possible. Still, I think it's not desired. I should
ask my customer...
My concern is pushing these changes upstream. Is such two-in-one driver
going to be easily accepted?

Anyway, thanks for the idea.

>> I was thinking about adding some middle-layer to
>> perform the actual conversion. The question is what is the preferred way
>> to add such a middle layer?
> 
> IMHO a middle layer for this type of problem is a bit overkill.

Still I can see that at least S3C does this.

>> Should we use a multi-function device driver
>> for this or just some platform-specific code (as S3C does)? Or maybe
>> there is another way?
> 
> AFAIK MFD is a solution when multiple devices have sequential register maps.
> MFD does no locking.

Well, yes. MFD was just another idea where to put custom API piece...

Thanks!

Regards, Ilya.

[RFC] What is the preferred way to share ADC unit between hwmon and input(ts) drivers?

[Mark Brown]

On Mon, Apr 25, 2011 at 04:37:38AM +0400, Ilya Yanok wrote:

> So, to add both input and hwmon drivers we need to serialize the
> register accesses. I was thinking about adding some middle-layer to
> perform the actual conversion. The question is what is the preferred way
> to add such a middle layer? Should we use a multi-function device driver
> for this or just some platform-specific code (as S3C does)? Or maybe
> there is another way?

IIO would probably be the standard API to use but that's still stuck in
staging.  I'd suggest doing a custom API and then transitioning to IIO
when that moves out of staging.

[RFC] What is the preferred way to share ADC unit between hwmon and input(ts) drivers?

[Ilya Yanok]

Hello Mark,

On 25.04.2011 15:02, Mark Brown wrote:
>> So, to add both input and hwmon drivers we need to serialize the
>> register accesses. I was thinking about adding some middle-layer to
>> perform the actual conversion. The question is what is the preferred way
>> to add such a middle layer? Should we use a multi-function device driver
>> for this or just some platform-specific code (as S3C does)? Or maybe
>> there is another way?
> 
> IIO would probably be the standard API to use but that's still stuck in
> staging.  I'd suggest doing a custom API and then transitioning to IIO
> when that moves out of staging.

Thanks for the pointer. Yes, I think we'll do as you advised.

Thanks!

Regards, Ilya.

[RFC] What is the preferred way to share ADC unit between hwmon and input(ts) drivers?

[Jonathan Cameron]

On 04/25/11 12:02, Mark Brown wrote:
> On Mon, Apr 25, 2011 at 04:37:38AM +0400, Ilya Yanok wrote:
> 
>> So, to add both input and hwmon drivers we need to serialize the
>> register accesses. I was thinking about adding some middle-layer to
>> perform the actual conversion. The question is what is the preferred way
>> to add such a middle layer? Should we use a multi-function device driver
>> for this or just some platform-specific code (as S3C does)? Or maybe
>> there is another way?
> 
> IIO would probably be the standard API to use but that's still stuck in
> staging.  I'd suggest doing a custom API and then transitioning to IIO
> when that moves out of staging.
IIO is fine for the adc side if it is general purpose (and typically
used as such). If it's typically used for power supply monitoring then
hwmon is the right place.

The touch screen element should definitely be in input though so
you will need a solution to the problem of shared registers.

[RFC] What is the preferred way to share ADC unit between hwmon and input(ts) drivers?

[Ithamar R. Adema]

On Fri, 2011-05-06 at 14:43 +0100, Jonathan Cameron wrote:
> The touch screen element should definitely be in input though so
> you will need a solution to the problem of shared registers.

Would it be worth considering generalizing the model that s3c uses[1]
for adc? I've reused that for at least two other platforms already,
though not mainlined (yet).

It could make for a good /drivers/adc/ base IMHO. Any opinions?

Regards,

Ithamar.

[1]:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/plat-samsung/adc.c

[RFC] What is the preferred way to share ADC unit between hwmon and input(ts) drivers?

[Mark Brown]

On Fri, May 06, 2011 at 04:13:26PM +0200, Ithamar R. Adema wrote:

> Would it be worth considering generalizing the model that s3c uses[1]
> for adc? I've reused that for at least two other platforms already,
> though not mainlined (yet).

> It could make for a good /drivers/adc/ base IMHO. Any opinions?

I'd have expected that this stuff should be able to fit into IIO and
that it would be able to be used by in-kernel users.

[RFC] What is the preferred way to share ADC unit between hwmon and input(ts) drivers?

[Jonathan Cameron]

On 05/06/11 15:23, Mark Brown wrote:
> On Fri, May 06, 2011 at 04:13:26PM +0200, Ithamar R. Adema wrote:
> 
>> Would it be worth considering generalizing the model that s3c uses[1]
>> for adc? I've reused that for at least two other platforms already,
>> though not mainlined (yet).
> 
>> It could make for a good /drivers/adc/ base IMHO. Any opinions?
> 
> I'd have expected that this stuff should be able to fit into IIO and
> that it would be able to be used by in-kernel users.
To my mind this is just like any other bit of hardware used by drivers
in different subsystems. Fits in MFD as far as I am concerned (and there
are several parts doing this ls drivers/mfd/*adc*).
Take the jz4740-adc.c file.  That provides adc reading to a touchscreen
a battery monitor and hwmon driver.  Any thing else is just reinventing
the wheel...

We can add in kernel hooks to IIO (would be easy enough -
for low rate stuff). I'd be happy to accept patches for this (it's not
a priority for any current active developers as far as I know).
However, that's silly if all you want is to pass it directly to input and hwmon.
Just write a driver that registers both interfaces directly.
If one of the adc channels needs stuff from IIO, add that as well.

IIO does have a (prototype) bridge to input, but that's done via userspace
is there to handle people doing unusual things with sensors typically used
for very different purposes (using 500 dolar IMU as a joystick for example).
We could do this in kernel, but that involves adding some logic at the
back end of the high data rate paths and hence would rather not...

Jonathan

[RFC] What is the preferred way to share ADC unit between hwmon and input(ts) drivers?

[Mark Brown]

On Fri, May 06, 2011 at 04:15:25PM +0100, Jonathan Cameron wrote:

> We can add in kernel hooks to IIO (would be easy enough -
> for low rate stuff). I'd be happy to accept patches for this (it's not
> a priority for any current active developers as far as I know).

The fact that the interface is stuck in staging has been putting me off
looking at this, building on top of staging would be a step back for the
uses I have.  I'd guess that most of the existing users have no other
option than to use IIO which isn't the case for this sort of user.

> However, that's silly if all you want is to pass it directly to input and hwmon.
> Just write a driver that registers both interfaces directly.
> If one of the adc channels needs stuff from IIO, add that as well.

The pattern that's present in a lot of PMICs it that there's an AUXADC
which is used for voltage/temperature monitoring (typically exposed by
hwmon and power) and can also be used for random inputs (in the style of
IIO).  The AUXADC is logically just a bunch of random ADC channels that
needs some software on top of it to provide semantics, which sounds a
lot like IIO.

Currently you end up with a part-specific ADC interface that some of the
other drivers are consumers for.  I'd really expect that IIO would be
able to save everyone having to reinvent this per chip.

[RFC] What is the preferred way to share ADC unit between hwmon and input(ts) drivers?

[Jonathan Cameron]

On 05/06/11 16:56, Mark Brown wrote:
> On Fri, May 06, 2011 at 04:15:25PM +0100, Jonathan Cameron wrote:
> 
>> We can add in kernel hooks to IIO (would be easy enough -
>> for low rate stuff). I'd be happy to accept patches for this (it's not
>> a priority for any current active developers as far as I know).
> 
> The fact that the interface is stuck in staging has been putting me off
> looking at this, building on top of staging would be a step back for the
> uses I have.  I'd guess that most of the existing users have no other
> option than to use IIO which isn't the case for this sort of user.
Sure - this sort of user isn't what I at least conceive IIO as being for.
> 
>> However, that's silly if all you want is to pass it directly to input and hwmon.
>> Just write a driver that registers both interfaces directly.
>> If one of the adc channels needs stuff from IIO, add that as well.
> 
> The pattern that's present in a lot of PMICs it that there's an AUXADC
> which is used for voltage/temperature monitoring (typically exposed by
> hwmon and power) and can also be used for random inputs (in the style of
> IIO).  The AUXADC is logically just a bunch of random ADC channels that
> needs some software on top of it to provide semantics, which sounds a
> lot like IIO.
> 
> Currently you end up with a part-specific ADC interface that some of the
> other drivers are consumers for.  I'd really expect that IIO would be
> able to save everyone having to reinvent this per chip.
Currently at least, IIO sits at the same level as input and hwmon. We
are interested in handling parts that are too fast / too complicated or just
plain don't fit in one of those.  It would be easy enough to add what you
are talking about, but in the same fashion as in theory input could add
interfaces for hwmon if they wanted to.  The question is whether this a
job for IIO or should be abstracted below this level (and I agree there
is scope for abstraction here).  I'm a little worried that if we put
it in IIO it will result in bloat away from the core aims of handling
the many weird and wonderful sensors out there in a coherent way.

So you could write a hwmon driver that talks through an iio driver
(easy enough to do I think - though only a small subset of stuff would
be supported). It's also low rate so the iio and hwmon interfaces
wouldn't get in each others way very much.

Input is trickier as the data paths for IIO and input
are deliberately rather different due to different requirements.
Yes we could write a driver that hooks in at a low level, but that
would then break the IIO data flow.

Basically, yes - we could bludgeon support for ADC in kernel sharing
into IIO, but its not all that close to our current scope.  If anyone
wants to look at that, feel free, but I still feel that this sits
better in mfd.  Often you will be sharing interrupts as well and they
may well be a mix of ADC and non ADC sources.

[RFC] What is the preferred way to share ADC unit between hwmon and input(ts) drivers?

[Mark Brown]

On Fri, May 06, 2011 at 05:29:39PM +0100, Jonathan Cameron wrote:

> Currently at least, IIO sits at the same level as input and hwmon. We
> are interested in handling parts that are too fast / too complicated or just
> plain don't fit in one of those.  It would be easy enough to add what you
> are talking about, but in the same fashion as in theory input could add
> interfaces for hwmon if they wanted to.  The question is whether this a
> job for IIO or should be abstracted below this level (and I agree there
> is scope for abstraction here).  I'm a little worried that if we put
> it in IIO it will result in bloat away from the core aims of handling
> the many weird and wonderful sensors out there in a coherent way.

I'm not clear what an abstraction below IIO for a plain ADC would be.

> Input is trickier as the data paths for IIO and input
> are deliberately rather different due to different requirements.
> Yes we could write a driver that hooks in at a low level, but that
> would then break the IIO data flow.

I'm not personally interested in that case, but if the input device is
really reading from the ADC using the same ADC interface as the rest of
the world then presumably the abstraction mismatch would be handled
above IIO?  I can't think what would be unusual about this from the
point of view of the ADC.

> Basically, yes - we could bludgeon support for ADC in kernel sharing
> into IIO, but its not all that close to our current scope.  If anyone

It's not really ADC sharing as such - there's one physical ADC but to
software these things look like a multi-channel ADC that happens to have
a single register to push data out of.  It happens to be lower volume
than most of the IIO ADCs but that doesn't seem like it should make too
much of a difference?

> wants to look at that, feel free, but I still feel that this sits
> better in mfd.

I'm not clear why MFD would be useful here?  These things are single
function ADCs and don't always appear as part of a larger Linux device.
Some CPUs have these, for example, so they just appear as a memory
mapped platform device.  They often end up with the custom API in the
core MFD driver where there is one of those but that's not because the
MFD API is relevant. 

>                 Often you will be sharing interrupts as well and they
> may well be a mix of ADC and non ADC sources.

You will generally be sharing an interrupt, yes.  I'm not sure what you
mean by a mix of ADC and non-ADC sources, though - the devices I'm
thinking of really are just ADCs.

[RFC] What is the preferred way to share ADC unit between hwmon and input(ts) drivers?

[Jonathan Cameron]

On 05/06/11 18:20, Mark Brown wrote:
> On Fri, May 06, 2011 at 05:29:39PM +0100, Jonathan Cameron wrote:
> 
>> Currently at least, IIO sits at the same level as input and hwmon. We
>> are interested in handling parts that are too fast / too complicated or just
>> plain don't fit in one of those.  It would be easy enough to add what you
>> are talking about, but in the same fashion as in theory input could add
>> interfaces for hwmon if they wanted to.  The question is whether this a
>> job for IIO or should be abstracted below this level (and I agree there
>> is scope for abstraction here).  I'm a little worried that if we put
>> it in IIO it will result in bloat away from the core aims of handling
>> the many weird and wonderful sensors out there in a coherent way.
> 
> I'm not clear what an abstraction below IIO for a plain ADC would be.
In summary what bothers me is not that IIO can't handle this - it can
with a few minor tweaks but rather that using IIO is massive overkill.
I can certainly see the benefit in adding what you suggest, but I'm a
little worried the main response would be 'why are you putting
all this stuff in place given you are just acting as distribution
layer for adc reading?'.

Basically my worry is bloat - IIO can't be everything

Perhaps I will have a moment to give this a go on top of IIO and
see whether it is simpler than I currently think...
> 
>> Input is trickier as the data paths for IIO and input
>> are deliberately rather different due to different requirements.
>> Yes we could write a driver that hooks in at a low level, but that
>> would then break the IIO data flow.
> 
> I'm not personally interested in that case, but if the input device is
> really reading from the ADC using the same ADC interface as the rest of
> the world then presumably the abstraction mismatch would be handled
> above IIO?
This is my point. IIO is high performance - if there is 'above' IIO, then
you've just wrecked one of our main reasons for existence.  IIO goes to userspace
via the shortest possible path.

The only valid hook in point would be to divert right at the bottom from our
slow read route (read_raw in the patches currently under review).  The burden
of ensuring that multiple drivers from different subsystems could safely
manipulate this would be pushed to the drivers.
> I can't think what would be unusual about this from the
> point of view of the ADC.
I really think you have misunderstood what IIO is targeting.  It is not
currently about providing a small layer to allow other kernel subsystems
to access an adc - it's about two main things.  Unified consistent userspace
interfaces and the option of a fast data path to userspace.  We can put in
what you want and have sufficient information to do it (unlike hwmon and input
I guess), but as yet I'm unconvinced that we should.
> 
>> Basically, yes - we could bludgeon support for ADC in kernel sharing
>> into IIO, but its not all that close to our current scope.  If anyone
> 
> It's not really ADC sharing as such - there's one physical ADC but to
> software these things look like a multi-channel ADC that happens to have
> a single register to push data out of.  It happens to be lower volume
> than most of the IIO ADCs but that doesn't seem like it should make too
> much of a difference?
We would have no problem handing the ADC's what we would need to add
is the description layer that provides the right information to input
and hwmon drivers sat on top + a few bits of infrastructure to connect
it all up.  Basically anything beyond the trivial adc channels with no
side information, would be rapidly become complex.
> 
>> wants to look at that, feel free, but I still feel that this sits
>> better in mfd.
> 
> I'm not clear why MFD would be useful here?  These things are single
> function ADCs and don't always appear as part of a larger Linux device.
> Some CPUs have these, for example, so they just appear as a memory
> mapped platform device.  They often end up with the custom API in the
> core MFD driver where there is one of those but that's not because the
> MFD API is relevant.
You may view an adc as a single device - but if you want the option in
kernel to have it sometimes act as input and sometimes act as hwmon -
to do it coherently you probably need to viewing it as a combined hwmon
and input device (and IIO).  Thus it has multiple functions and so
to my mind belongs as an mfd core and separate hwmon and input drivers.

I agree we would be replicating a few bits of IIO (basically just the
iio_chan_spec structures for describing channels) and a few callback
functions.
> 
>>                 Often you will be sharing interrupts as well and they
>> may well be a mix of ADC and non ADC sources.
> 
> You will generally be sharing an interrupt, yes.  I'm not sure what you
> mean by a mix of ADC and non-ADC sources, though - the devices I'm
> thinking of really are just ADCs.
Fair enough, but on some PMICs for example IIRC that isn't the case.

I am thoroughly in favour of unifying code at this sort of low level for
the various subsystems that need to read from the ADC. All I'm arguing is
that IIO is not the right place.  What you need here is a clean abstraction
for what is effectively reading from a device register.

Then you need to have a 'bus' to which your hwmon / input / iio drivers
appear to be connected.  The irq stuff can be handled using irq chips.

And please note, this is not a general purpose bit of code covering all adcs.
There are certainly cases that would benefit, but it's no where near all of
them.

All comments on what is currently in IIO welcomed of course!

Jonathan

[RFC] What is the preferred way to share ADC unit between hwmon and input(ts) drivers?

[Mark Brown]

On Mon, May 09, 2011 at 02:25:41PM +0100, Jonathan Cameron wrote:
> On 05/06/11 18:20, Mark Brown wrote:

> > I'm not clear what an abstraction below IIO for a plain ADC would be.

> In summary what bothers me is not that IIO can't handle this - it can
> with a few minor tweaks but rather that using IIO is massive overkill.
> I can certainly see the benefit in adding what you suggest, but I'm a
> little worried the main response would be 'why are you putting
> all this stuff in place given you are just acting as distribution
> layer for adc reading?'.

Isn't that essentially what IIO is (well, there's the DAC side as well)?
You're currently focusing on distributing data to userspace but that
seems like a fixable limitation rather than anything else, I don't see a
fundamental disconnect between users.

> > I'm not personally interested in that case, but if the input device is
> > really reading from the ADC using the same ADC interface as the rest of
> > the world then presumably the abstraction mismatch would be handled
> > above IIO?

> This is my point. IIO is high performance - if there is 'above' IIO, then
> you've just wrecked one of our main reasons for existence.  IIO goes to userspace
> via the shortest possible path.

It doesn't seem terribly invasive to be able to have a choice of things
to notify, you already have to at least be able to work out which
userspace thing to tell...  It certainly doesn't seem like we'd want
another subsystem to offer a different userspace interface, or even a
reimplementation of the same userspace interface, for the generic
channels.  It also doesn't seem like kernel space is going to be
explicitly looking for low performance, in the touchscreen example you
mentioned the focus is typically very much on reducing latency.

> > I can't think what would be unusual about this from the
> > point of view of the ADC.

> I really think you have misunderstood what IIO is targeting.  It is not
> currently about providing a small layer to allow other kernel subsystems
> to access an adc - it's about two main things.  Unified consistent userspace
> interfaces and the option of a fast data path to userspace.  We can put in
> what you want and have sufficient information to do it (unlike hwmon and input
> I guess), but as yet I'm unconvinced that we should.

Well, if we don't do that I guess we have to invent another subsystem
for generic ADCs and DACs which doesn't seem ideal either, and I'd guess
a bunch of drivers (at a guess many of them) would get pushed down from
IIO into that and use some generic IIO to convertor adaption layer?

> > It's not really ADC sharing as such - there's one physical ADC but to
> > software these things look like a multi-channel ADC that happens to have
> > a single register to push data out of.  It happens to be lower volume
> > than most of the IIO ADCs but that doesn't seem like it should make too
> > much of a difference?

> We would have no problem handing the ADC's what we would need to add
> is the description layer that provides the right information to input
> and hwmon drivers sat on top + a few bits of infrastructure to connect
> it all up.  Basically anything beyond the trivial adc channels with no
> side information, would be rapidly become complex.

Can't the higher level subsystems deal with this?  It doesn't seem like
a problem the ADC layer should be worrying about.

> > I'm not clear why MFD would be useful here?  These things are single
> > function ADCs and don't always appear as part of a larger Linux device.
> > Some CPUs have these, for example, so they just appear as a memory
> > mapped platform device.  They often end up with the custom API in the
> > core MFD driver where there is one of those but that's not because the
> > MFD API is relevant.

> You may view an adc as a single device - but if you want the option in
> kernel to have it sometimes act as input and sometimes act as hwmon -
> to do it coherently you probably need to viewing it as a combined hwmon
> and input device (and IIO).  Thus it has multiple functions and so
> to my mind belongs as an mfd core and separate hwmon and input drivers.

Like I say this isn't really the model the hardware is presenting here -
it looks much more like a set of n ADC channels some of which have
fixed purposes and some of which are generic than a single ADC.

> I am thoroughly in favour of unifying code at this sort of low level for
> the various subsystems that need to read from the ADC. All I'm arguing is
> that IIO is not the right place.  What you need here is a clean abstraction
> for what is effectively reading from a device register.

> Then you need to have a 'bus' to which your hwmon / input / iio drivers
> appear to be connected.  The irq stuff can be handled using irq chips.

You could do that, but like I say if we do that then what it's
suggesting to me is that we should be pulling the chip drivers out of
IIO and pushing them down into some new subsystem, leaving IIO as a
wrapper around that subsystem for otherwise unclaimed channels (or
possibly explicitly exposed channels).

What I'm looking for here is a standard way of writing drivers for
generic ADCs and DACs.  It doesn't have to be IIO but if it isn't then
it's really suggesting to me that we need to start pushing things down
out of IIO so we have a consistent way to implement support for random
generic ADCs and DACs.

Re: [RFC] What is the preferred way to share ADC unit between hwmon and input(ts) drivers?

[Jonathan Cameron]

On 05/09/11 15:39, Mark Brown wrote:
> On Mon, May 09, 2011 at 02:25:41PM +0100, Jonathan Cameron wrote:
>> On 05/06/11 18:20, Mark Brown wrote:
> 
>>> I'm not clear what an abstraction below IIO for a plain ADC would be.
> 
>> In summary what bothers me is not that IIO can't handle this - it can
>> with a few minor tweaks but rather that using IIO is massive overkill.
>> I can certainly see the benefit in adding what you suggest, but I'm a
>> little worried the main response would be 'why are you putting
>> all this stuff in place given you are just acting as distribution
>> layer for adc reading?'.
> 
> Isn't that essentially what IIO is (well, there's the DAC side as well)?
> You're currently focusing on distributing data to userspace but that
> seems like a fixable limitation rather than anything else, I don't see a
> fundamental disconnect between users.
Indeed, we could do it.  I suppose a lot of why I'm not just saying 'lets
try it and see how we go' is that there is a lot going
on in IIO right now with over 20,000 lines of patches under review...
(vast majority of that is core changes).

You've convinced me it may be sensible (and worth trying to see).  I'm not
sure everyone else will agree though! Mind you, despite some good responses
from those who have taken a look, I'm not sure Linus for one is going to like
IIO when we eventually send him a pull request..
> 
>>> I'm not personally interested in that case, but if the input device is
>>> really reading from the ADC using the same ADC interface as the rest of
>>> the world then presumably the abstraction mismatch would be handled
>>> above IIO?
> 
>> This is my point. IIO is high performance - if there is 'above' IIO, then
>> you've just wrecked one of our main reasons for existence.  IIO goes to userspace
>> via the shortest possible path.
> 
> It doesn't seem terribly invasive to be able to have a choice of things
> to notify, you already have to at least be able to work out which
> userspace thing to tell...
Not really.  That is the main difference between input and iio.
There is one userspace route for data per device.  This is pretty bare
bones. There is buffering in between the device and userspace, sometime
it is in hardware, sometime software.

>  It certainly doesn't seem like we'd want
> another subsystem to offer a different userspace interface, or even a
> reimplementation of the same userspace interface, for the generic
> channels.  It also doesn't seem like kernel space is going to be
> explicitly looking for low performance, in the touchscreen example you
> mentioned the focus is typically very much on reducing latency.
Exactly.  Why bounce through another subsystem when you can share at a
much lower level? Also as you say, input is about latency, we are often
about through put right now.
We 'could' put a low latency path in place, and certainly intend to do
it (see the interchangable 'buffer' element of IIO, but it is not trivial.
It's on the todo list, but it's not there now. The other thing we have
is two data paths vs input's one. Input calls everything an event
and hence has to separately describe every bit of data coming out.
We still have events for threshold etc, but we also have 'data'
(e.g. channel reads) going through a path without needing to describe
the individual pieces of data (this is fixed if userspace doesn't try
to change it).  Note that this 'data' path is very much about ripping
the raw stuff off the channel (typically as a 'scan') and shoving it
onwards.

To get it into input for example, we would need to provide a translation
layer which reads our channel descriptions > figures out input event types
> passes on to input.  Right now this is done in userspace (obviously
not appropriate for touch screens).

It may make sense to do this in kernel but it is going to be rather big
and messy (hence the input guys suggested doing it using uinput in
the first place!).
> 
>>> I can't think what would be unusual about this from the
>>> point of view of the ADC.
> 
>> I really think you have misunderstood what IIO is targeting.  It is not
>> currently about providing a small layer to allow other kernel subsystems
>> to access an adc - it's about two main things.  Unified consistent userspace
>> interfaces and the option of a fast data path to userspace.  We can put in
>> what you want and have sufficient information to do it (unlike hwmon and input
>> I guess), but as yet I'm unconvinced that we should.
> 
> Well, if we don't do that I guess we have to invent another subsystem
> for generic ADCs and DACs which doesn't seem ideal either, and I'd guess
> a bunch of drivers (at a guess many of them) would get pushed down from
> IIO into that and use some generic IIO to convertor adaption layer?
You are beginning to persuade me...
(it wouldn't be that many of our current drivers, but it might well cover
a good set of possible future ones ).

I'm still bothered that people will not like the weight of IIO under
the other subsystems.  It is only heavy if people enable the interesting
bits, but a lot of people might not realize that.
> 
>>> It's not really ADC sharing as such - there's one physical ADC but to
>>> software these things look like a multi-channel ADC that happens to have
>>> a single register to push data out of.  It happens to be lower volume
>>> than most of the IIO ADCs but that doesn't seem like it should make too
>>> much of a difference?
> 
>> We would have no problem handing the ADC's what we would need to add
>> is the description layer that provides the right information to input
>> and hwmon drivers sat on top + a few bits of infrastructure to connect
>> it all up.  Basically anything beyond the trivial adc channels with no
>> side information, would be rapidly become complex.
> 
> Can't the higher level subsystems deal with this?  It doesn't seem like
> a problem the ADC layer should be worrying about.
> 
>>> I'm not clear why MFD would be useful here?  These things are single
>>> function ADCs and don't always appear as part of a larger Linux device.
>>> Some CPUs have these, for example, so they just appear as a memory
>>> mapped platform device.  They often end up with the custom API in the
>>> core MFD driver where there is one of those but that's not because the
>>> MFD API is relevant.
> 
>> You may view an adc as a single device - but if you want the option in
>> kernel to have it sometimes act as input and sometimes act as hwmon -
>> to do it coherently you probably need to viewing it as a combined hwmon
>> and input device (and IIO).  Thus it has multiple functions and so
>> to my mind belongs as an mfd core and separate hwmon and input drivers.
> 
> Like I say this isn't really the model the hardware is presenting here -
> it looks much more like a set of n ADC channels some of which have
> fixed purposes and some of which are generic than a single ADC.
I still disagree on this point.  Lets say we have an adc with 8 channels.

1-2 -> touch screen (input device)
3-4 -> power monitoring (hwmon device)
5-8 -> general purpose (IIO device - complete with 'scan' functions if
that makes sense the device).

Looks exactly like an mfd to me.  There are clearly 3 functions there.
To a hardware engineer perhaps they look like a single one (ADC) but
that is clearly not how the board in question is wired up.

I'm not suggesting mfd is ideal for this, but rather that it is a valid
option to consider.

> 
>> I am thoroughly in favour of unifying code at this sort of low level for
>> the various subsystems that need to read from the ADC. All I'm arguing is
>> that IIO is not the right place.  What you need here is a clean abstraction
>> for what is effectively reading from a device register.
> 
>> Then you need to have a 'bus' to which your hwmon / input / iio drivers
>> appear to be connected.  The irq stuff can be handled using irq chips.
> 
> You could do that, but like I say if we do that then what it's
> suggesting to me is that we should be pulling the chip drivers out of
> IIO and pushing them down into some new subsystem, leaving IIO as a
> wrapper around that subsystem for otherwise unclaimed channels (or
> possibly explicitly exposed channels).
Indeed - I have been suggesting a very small layer underneath
(which I still think is going to look remarkably like mfd) may make more sense.  I'm basically
not sure either way.  We can do it in IIO, but is that the right option?

As I've said, I'm happy to give it a go and see (or let someone else
try it out).  We do have iio_chan_spec structures and the relevant
callbacks to figure out everything needed to do what you suggest.
> 
> What I'm looking for here is a standard way of writing drivers for
> generic ADCs and DACs.  It doesn't have to be IIO but if it isn't then
> it's really suggesting to me that we need to start pushing things down
> out of IIO so we have a consistent way to implement support for random
> generic ADCs and DACs.

Lets sumarize what we would need. I've cc'd linux-iio (probably should have
done that long ago!) as they may give more feedback on practicalities.

Assume only dealing with hwmon, input and IIO as output routes for now.
Note if you enable input, certain things will not work in IIO.

V1 - no clever reading tricks or high throughput.

1) A nice generic way of specifying which channels are for which subsystem.
2) Sufficient information on adc to provide the nice unit converted stuff hwmon
expects and the info on noise etc that input wants. The chan spec structures go
a way towards this - see 
https://git.kernel.org/?p=linux/kernel/git/jic23/iio-onwards.git;a=blob;f=drivers/staging/iio/iio.h

3) hwmon driver - actually this is easy given we match a lot of their interfaces
anyway and its SLOW..
4) input driver - polled only initially. Later add ability to 'steal' the trigger
from iio to do data ready interrupt based reading.  I can't see an easy way 
of making these play well together. Basically if you want to use the device for
anything else you have to fix the functionality of the IIO path way more than normal.

V2 - buffer routing - this is nasty and may never make sense.

1) Allow for diversion of raw data into 'input' or the IIO buffer on triggering.
Note configurable triggers will still not be possible as far as I can see.
To configure them you have to disable all sampling - if someone else is using them
you can't do that.

So all in all - hwmon and polled input would be reasonably straight forward.
I suspect they may well disagree about whether this is a good idea.

Mark - do note that the stuff in staging-next right now is no where near the
same as the tree we are mostly working with...
https://git.kernel.org/?p=linux/kernel/git/jic23/iio-onwards.git;a=summary

Pushing this out is waiting one last driver conversion/fixup (and responding to any
reviews that turn up in the meantime!)

Jonathan

[RFC] What is the preferred way to share ADC unit between hwmon and input(ts) drivers?

[Jonathan Cameron]

On 05/09/11 15:39, Mark Brown wrote:
> On Mon, May 09, 2011 at 02:25:41PM +0100, Jonathan Cameron wrote:
>> On 05/06/11 18:20, Mark Brown wrote:
> 
>>> I'm not clear what an abstraction below IIO for a plain ADC would be.
> 
>> In summary what bothers me is not that IIO can't handle this - it can
>> with a few minor tweaks but rather that using IIO is massive overkill.
>> I can certainly see the benefit in adding what you suggest, but I'm a
>> little worried the main response would be 'why are you putting
>> all this stuff in place given you are just acting as distribution
>> layer for adc reading?'.
> 
> Isn't that essentially what IIO is (well, there's the DAC side as well)?
> You're currently focusing on distributing data to userspace but that
> seems like a fixable limitation rather than anything else, I don't see a
> fundamental disconnect between users.
Indeed, we could do it.  I suppose a lot of why I'm not just saying 'lets
try it and see how we go' is that there is a lot going
on in IIO right now with over 20,000 lines of patches under review...
(vast majority of that is core changes).

You've convinced me it may be sensible (and worth trying to see).  I'm not
sure everyone else will agree though! Mind you, despite some good responses
from those who have taken a look, I'm not sure Linus for one is going to like
IIO when we eventually send him a pull request..
> 
>>> I'm not personally interested in that case, but if the input device is
>>> really reading from the ADC using the same ADC interface as the rest of
>>> the world then presumably the abstraction mismatch would be handled
>>> above IIO?
> 
>> This is my point. IIO is high performance - if there is 'above' IIO, then
>> you've just wrecked one of our main reasons for existence.  IIO goes to userspace
>> via the shortest possible path.
> 
> It doesn't seem terribly invasive to be able to have a choice of things
> to notify, you already have to at least be able to work out which
> userspace thing to tell...
Not really.  That is the main difference between input and iio.
There is one userspace route for data per device.  This is pretty bare
bones. There is buffering in between the device and userspace, sometime
it is in hardware, sometime software.

>  It certainly doesn't seem like we'd want
> another subsystem to offer a different userspace interface, or even a
> reimplementation of the same userspace interface, for the generic
> channels.  It also doesn't seem like kernel space is going to be
> explicitly looking for low performance, in the touchscreen example you
> mentioned the focus is typically very much on reducing latency.
Exactly.  Why bounce through another subsystem when you can share at a
much lower level? Also as you say, input is about latency, we are often
about through put right now.
We 'could' put a low latency path in place, and certainly intend to do
it (see the interchangable 'buffer' element of IIO, but it is not trivial.
It's on the todo list, but it's not there now. The other thing we have
is two data paths vs input's one. Input calls everything an event
and hence has to separately describe every bit of data coming out.
We still have events for threshold etc, but we also have 'data'
(e.g. channel reads) going through a path without needing to describe
the individual pieces of data (this is fixed if userspace doesn't try
to change it).  Note that this 'data' path is very much about ripping
the raw stuff off the channel (typically as a 'scan') and shoving it
onwards.

To get it into input for example, we would need to provide a translation
layer which reads our channel descriptions > figures out input event types
> passes on to input.  Right now this is done in userspace (obviously
not appropriate for touch screens).

It may make sense to do this in kernel but it is going to be rather big
and messy (hence the input guys suggested doing it using uinput in
the first place!).
> 
>>> I can't think what would be unusual about this from the
>>> point of view of the ADC.
> 
>> I really think you have misunderstood what IIO is targeting.  It is not
>> currently about providing a small layer to allow other kernel subsystems
>> to access an adc - it's about two main things.  Unified consistent userspace
>> interfaces and the option of a fast data path to userspace.  We can put in
>> what you want and have sufficient information to do it (unlike hwmon and input
>> I guess), but as yet I'm unconvinced that we should.
> 
> Well, if we don't do that I guess we have to invent another subsystem
> for generic ADCs and DACs which doesn't seem ideal either, and I'd guess
> a bunch of drivers (at a guess many of them) would get pushed down from
> IIO into that and use some generic IIO to convertor adaption layer?
You are beginning to persuade me...
(it wouldn't be that many of our current drivers, but it might well cover
a good set of possible future ones ).

I'm still bothered that people will not like the weight of IIO under
the other subsystems.  It is only heavy if people enable the interesting
bits, but a lot of people might not realize that.
> 
>>> It's not really ADC sharing as such - there's one physical ADC but to
>>> software these things look like a multi-channel ADC that happens to have
>>> a single register to push data out of.  It happens to be lower volume
>>> than most of the IIO ADCs but that doesn't seem like it should make too
>>> much of a difference?
> 
>> We would have no problem handing the ADC's what we would need to add
>> is the description layer that provides the right information to input
>> and hwmon drivers sat on top + a few bits of infrastructure to connect
>> it all up.  Basically anything beyond the trivial adc channels with no
>> side information, would be rapidly become complex.
> 
> Can't the higher level subsystems deal with this?  It doesn't seem like
> a problem the ADC layer should be worrying about.
> 
>>> I'm not clear why MFD would be useful here?  These things are single
>>> function ADCs and don't always appear as part of a larger Linux device.
>>> Some CPUs have these, for example, so they just appear as a memory
>>> mapped platform device.  They often end up with the custom API in the
>>> core MFD driver where there is one of those but that's not because the
>>> MFD API is relevant.
> 
>> You may view an adc as a single device - but if you want the option in
>> kernel to have it sometimes act as input and sometimes act as hwmon -
>> to do it coherently you probably need to viewing it as a combined hwmon
>> and input device (and IIO).  Thus it has multiple functions and so
>> to my mind belongs as an mfd core and separate hwmon and input drivers.
> 
> Like I say this isn't really the model the hardware is presenting here -
> it looks much more like a set of n ADC channels some of which have
> fixed purposes and some of which are generic than a single ADC.
I still disagree on this point.  Lets say we have an adc with 8 channels.

1-2 -> touch screen (input device)
3-4 -> power monitoring (hwmon device)
5-8 -> general purpose (IIO device - complete with 'scan' functions if
that makes sense the device).

Looks exactly like an mfd to me.  There are clearly 3 functions there.
To a hardware engineer perhaps they look like a single one (ADC) but
that is clearly not how the board in question is wired up.

I'm not suggesting mfd is ideal for this, but rather that it is a valid
option to consider.

> 
>> I am thoroughly in favour of unifying code at this sort of low level for
>> the various subsystems that need to read from the ADC. All I'm arguing is
>> that IIO is not the right place.  What you need here is a clean abstraction
>> for what is effectively reading from a device register.
> 
>> Then you need to have a 'bus' to which your hwmon / input / iio drivers
>> appear to be connected.  The irq stuff can be handled using irq chips.
> 
> You could do that, but like I say if we do that then what it's
> suggesting to me is that we should be pulling the chip drivers out of
> IIO and pushing them down into some new subsystem, leaving IIO as a
> wrapper around that subsystem for otherwise unclaimed channels (or
> possibly explicitly exposed channels).
Indeed - I have been suggesting a very small layer underneath
(which I still think is going to look remarkably like mfd) may make more sense.  I'm basically
not sure either way.  We can do it in IIO, but is that the right option?

As I've said, I'm happy to give it a go and see (or let someone else
try it out).  We do have iio_chan_spec structures and the relevant
callbacks to figure out everything needed to do what you suggest.
> 
> What I'm looking for here is a standard way of writing drivers for
> generic ADCs and DACs.  It doesn't have to be IIO but if it isn't then
> it's really suggesting to me that we need to start pushing things down
> out of IIO so we have a consistent way to implement support for random
> generic ADCs and DACs.

Lets sumarize what we would need. I've cc'd linux-iio (probably should have
done that long ago!) as they may give more feedback on practicalities.

Assume only dealing with hwmon, input and IIO as output routes for now.
Note if you enable input, certain things will not work in IIO.

V1 - no clever reading tricks or high throughput.

1) A nice generic way of specifying which channels are for which subsystem.
2) Sufficient information on adc to provide the nice unit converted stuff hwmon
expects and the info on noise etc that input wants. The chan spec structures go
a way towards this - see 
https://git.kernel.org/?p=linux/kernel/git/jic23/iio-onwards.git;a=blob;f=drivers/staging/iio/iio.h

3) hwmon driver - actually this is easy given we match a lot of their interfaces
anyway and its SLOW..
4) input driver - polled only initially. Later add ability to 'steal' the trigger
from iio to do data ready interrupt based reading.  I can't see an easy way 
of making these play well together. Basically if you want to use the device for
anything else you have to fix the functionality of the IIO path way more than normal.

V2 - buffer routing - this is nasty and may never make sense.

1) Allow for diversion of raw data into 'input' or the IIO buffer on triggering.
Note configurable triggers will still not be possible as far as I can see.
To configure them you have to disable all sampling - if someone else is using them
you can't do that.

So all in all - hwmon and polled input would be reasonably straight forward.
I suspect they may well disagree about whether this is a good idea.

Mark - do note that the stuff in staging-next right now is no where near the
same as the tree we are mostly working with...
https://git.kernel.org/?p=linux/kernel/git/jic23/iio-onwards.git;a=summary

Pushing this out is waiting one last driver conversion/fixup (and responding to any
reviews that turn up in the meantime!)

Jonathan

Re: [RFC] What is the preferred way to share ADC unit between hwmon and input(ts) drivers?

[Mark Brown]

On Mon, May 09, 2011 at 05:35:01PM +0100, Jonathan Cameron wrote:
> On 05/09/11 15:39, Mark Brown wrote:

> > Isn't that essentially what IIO is (well, there's the DAC side as well)?
> > You're currently focusing on distributing data to userspace but that
> > seems like a fixable limitation rather than anything else, I don't see a
> > fundamental disconnect between users.

> Indeed, we could do it.  I suppose a lot of why I'm not just saying 'lets
> try it and see how we go' is that there is a lot going
> on in IIO right now with over 20,000 lines of patches under review...
> (vast majority of that is core changes).

Right, as I've said before one of the reasons I've not looked at IIO in
too much detail is that there's a lot of change and it's still in
staging.

> You've convinced me it may be sensible (and worth trying to see).  I'm not
> sure everyone else will agree though! Mind you, despite some good responses
> from those who have taken a look, I'm not sure Linus for one is going to like
> IIO when we eventually send him a pull request..

One way to find out :)

> > It doesn't seem terribly invasive to be able to have a choice of things
> > to notify, you already have to at least be able to work out which
> > userspace thing to tell...

> Not really.  That is the main difference between input and iio.
> There is one userspace route for data per device.  This is pretty bare
> bones. There is buffering in between the device and userspace, sometime
> it is in hardware, sometime software.

Yes, and my thought here was essentially that the bit that kicks
userspace could with suitable use of callbacks be easily replaced by
something that kicked an in-kernel user without too much hassle for the
userspace users.

> We 'could' put a low latency path in place, and certainly intend to do
> it (see the interchangable 'buffer' element of IIO, but it is not trivial.
> It's on the todo list, but it's not there now. The other thing we have
> is two data paths vs input's one. Input calls everything an event
> and hence has to separately describe every bit of data coming out.
> We still have events for threshold etc, but we also have 'data'
> (e.g. channel reads) going through a path without needing to describe
> the individual pieces of data (this is fixed if userspace doesn't try
> to change it).  Note that this 'data' path is very much about ripping
> the raw stuff off the channel (typically as a 'scan') and shoving it
> onwards.

With the above approach I don't think IIO (or whatever) would need to
worry about the difference - it just lets whatever is consuming the data
deal with the blocks of data that get thrown out.

> It may make sense to do this in kernel but it is going to be rather big
> and messy (hence the input guys suggested doing it using uinput in
> the first place!).

Yeah, I don't know that the specific example of input makes much sense.

> I'm still bothered that people will not like the weight of IIO under
> the other subsystems.  It is only heavy if people enable the interesting
> bits, but a lot of people might not realize that.

So long as there's suitable fast/light paths I think we'd be fine.  I
guess another option would be to split out the userspace API from the
driver API so that people could skip the userspace API.

> >> and input device (and IIO).  Thus it has multiple functions and so
> >> to my mind belongs as an mfd core and separate hwmon and input drivers.

> > Like I say this isn't really the model the hardware is presenting here -
> > it looks much more like a set of n ADC channels some of which have
> > fixed purposes and some of which are generic than a single ADC.
> I still disagree on this point.  Lets say we have an adc with 8 channels.

> 1-2 -> touch screen (input device)
> 3-4 -> power monitoring (hwmon device)
> 5-8 -> general purpose (IIO device - complete with 'scan' functions if
> that makes sense the device).

> Looks exactly like an mfd to me.  There are clearly 3 functions there.
> To a hardware engineer perhaps they look like a single one (ADC) but
> that is clearly not how the board in question is wired up.

MFD would feel more comfortable if you had a watchdog and an RTC or
whatever in there, and even then having three devices all of which are
thin wrappers around a custom per-chip bit of code in the MFD core feels
icky.

> > You could do that, but like I say if we do that then what it's
> > suggesting to me is that we should be pulling the chip drivers out of
> > IIO and pushing them down into some new subsystem, leaving IIO as a
> > wrapper around that subsystem for otherwise unclaimed channels (or
> > possibly explicitly exposed channels).

> Indeed - I have been suggesting a very small layer underneath
> (which I still think is going to look remarkably like mfd) may make more sense.  I'm basically
> not sure either way.  We can do it in IIO, but is that the right option?

MFD is really only about register maps, registering subdevices and (for
randomness) IRQ controllers - anything too substantial beyond those
really feels a bit wrong there.  The ADC stuff definitely feels too
heavyweight, especially when you start adding things like comparators on
top of that.  There should be some subsystem we can slot this into.

> V1 - no clever reading tricks or high throughput.
> 
> 1) A nice generic way of specifying which channels are for which subsystem.
> 2) Sufficient information on adc to provide the nice unit converted stuff hwmon
> expects and the info on noise etc that input wants. The chan spec structures go
> a way towards this - see 
> https://git.kernel.org/?p=linux/kernel/git/jic23/iio-onwards.git;a=blob;f=drivers/staging/iio/iio.h

Looks sensible.

> 3) hwmon driver - actually this is easy given we match a lot of their interfaces
> anyway and its SLOW..

Yes, and also /sys/class/power_supply usage.

> 4) input driver - polled only initially. Later add ability to 'steal' the trigger
> from iio to do data ready interrupt based reading.  I can't see an easy way 
> of making these play well together. Basically if you want to use the device for
> anything else you have to fix the functionality of the IIO path way more than normal.

The stuff with stealing the trigger seems like a callback type problem
to me.

> V2 - buffer routing - this is nasty and may never make sense.

> 1) Allow for diversion of raw data into 'input' or the IIO buffer on triggering.
> Note configurable triggers will still not be possible as far as I can see.
> To configure them you have to disable all sampling - if someone else is using them
> you can't do that.

For low volume devices I guess you can do a lot of this in software
relatively painlessly; so long as it doesn't impact high volume devices
("I used DMA to fill that buffer, honest!") I guess that's fine.

[RFC] What is the preferred way to share ADC unit between hwmon and input(ts) drivers?

[Mark Brown]

On Mon, May 09, 2011 at 05:35:01PM +0100, Jonathan Cameron wrote:
> On 05/09/11 15:39, Mark Brown wrote:

> > Isn't that essentially what IIO is (well, there's the DAC side as well)?
> > You're currently focusing on distributing data to userspace but that
> > seems like a fixable limitation rather than anything else, I don't see a
> > fundamental disconnect between users.

> Indeed, we could do it.  I suppose a lot of why I'm not just saying 'lets
> try it and see how we go' is that there is a lot going
> on in IIO right now with over 20,000 lines of patches under review...
> (vast majority of that is core changes).

Right, as I've said before one of the reasons I've not looked at IIO in
too much detail is that there's a lot of change and it's still in
staging.

> You've convinced me it may be sensible (and worth trying to see).  I'm not
> sure everyone else will agree though! Mind you, despite some good responses
> from those who have taken a look, I'm not sure Linus for one is going to like
> IIO when we eventually send him a pull request..

One way to find out :)

> > It doesn't seem terribly invasive to be able to have a choice of things
> > to notify, you already have to at least be able to work out which
> > userspace thing to tell...

> Not really.  That is the main difference between input and iio.
> There is one userspace route for data per device.  This is pretty bare
> bones. There is buffering in between the device and userspace, sometime
> it is in hardware, sometime software.

Yes, and my thought here was essentially that the bit that kicks
userspace could with suitable use of callbacks be easily replaced by
something that kicked an in-kernel user without too much hassle for the
userspace users.

> We 'could' put a low latency path in place, and certainly intend to do
> it (see the interchangable 'buffer' element of IIO, but it is not trivial.
> It's on the todo list, but it's not there now. The other thing we have
> is two data paths vs input's one. Input calls everything an event
> and hence has to separately describe every bit of data coming out.
> We still have events for threshold etc, but we also have 'data'
> (e.g. channel reads) going through a path without needing to describe
> the individual pieces of data (this is fixed if userspace doesn't try
> to change it).  Note that this 'data' path is very much about ripping
> the raw stuff off the channel (typically as a 'scan') and shoving it
> onwards.

With the above approach I don't think IIO (or whatever) would need to
worry about the difference - it just lets whatever is consuming the data
deal with the blocks of data that get thrown out.

> It may make sense to do this in kernel but it is going to be rather big
> and messy (hence the input guys suggested doing it using uinput in
> the first place!).

Yeah, I don't know that the specific example of input makes much sense.

> I'm still bothered that people will not like the weight of IIO under
> the other subsystems.  It is only heavy if people enable the interesting
> bits, but a lot of people might not realize that.

So long as there's suitable fast/light paths I think we'd be fine.  I
guess another option would be to split out the userspace API from the
driver API so that people could skip the userspace API.

> >> and input device (and IIO).  Thus it has multiple functions and so
> >> to my mind belongs as an mfd core and separate hwmon and input drivers.

> > Like I say this isn't really the model the hardware is presenting here -
> > it looks much more like a set of n ADC channels some of which have
> > fixed purposes and some of which are generic than a single ADC.
> I still disagree on this point.  Lets say we have an adc with 8 channels.

> 1-2 -> touch screen (input device)
> 3-4 -> power monitoring (hwmon device)
> 5-8 -> general purpose (IIO device - complete with 'scan' functions if
> that makes sense the device).

> Looks exactly like an mfd to me.  There are clearly 3 functions there.
> To a hardware engineer perhaps they look like a single one (ADC) but
> that is clearly not how the board in question is wired up.

MFD would feel more comfortable if you had a watchdog and an RTC or
whatever in there, and even then having three devices all of which are
thin wrappers around a custom per-chip bit of code in the MFD core feels
icky.

> > You could do that, but like I say if we do that then what it's
> > suggesting to me is that we should be pulling the chip drivers out of
> > IIO and pushing them down into some new subsystem, leaving IIO as a
> > wrapper around that subsystem for otherwise unclaimed channels (or
> > possibly explicitly exposed channels).

> Indeed - I have been suggesting a very small layer underneath
> (which I still think is going to look remarkably like mfd) may make more sense.  I'm basically
> not sure either way.  We can do it in IIO, but is that the right option?

MFD is really only about register maps, registering subdevices and (for
randomness) IRQ controllers - anything too substantial beyond those
really feels a bit wrong there.  The ADC stuff definitely feels too
heavyweight, especially when you start adding things like comparators on
top of that.  There should be some subsystem we can slot this into.

> V1 - no clever reading tricks or high throughput.
> 
> 1) A nice generic way of specifying which channels are for which subsystem.
> 2) Sufficient information on adc to provide the nice unit converted stuff hwmon
> expects and the info on noise etc that input wants. The chan spec structures go
> a way towards this - see 
> https://git.kernel.org/?p=linux/kernel/git/jic23/iio-onwards.git;a=blob;f=drivers/staging/iio/iio.h

Looks sensible.

> 3) hwmon driver - actually this is easy given we match a lot of their interfaces
> anyway and its SLOW..

Yes, and also /sys/class/power_supply usage.

> 4) input driver - polled only initially. Later add ability to 'steal' the trigger
> from iio to do data ready interrupt based reading.  I can't see an easy way 
> of making these play well together. Basically if you want to use the device for
> anything else you have to fix the functionality of the IIO path way more than normal.

The stuff with stealing the trigger seems like a callback type problem
to me.

> V2 - buffer routing - this is nasty and may never make sense.

> 1) Allow for diversion of raw data into 'input' or the IIO buffer on triggering.
> Note configurable triggers will still not be possible as far as I can see.
> To configure them you have to disable all sampling - if someone else is using them
> you can't do that.

For low volume devices I guess you can do a lot of this in software
relatively painlessly; so long as it doesn't impact high volume devices
("I used DMA to fill that buffer, honest!") I guess that's fine.

Re: [RFC] What is the preferred way to share ADC unit between hwmon and input(ts) drivers?

[Jonathan Cameron]

On 05/09/11 20:54, Mark Brown wrote:
> On Mon, May 09, 2011 at 05:35:01PM +0100, Jonathan Cameron wrote:
>> On 05/09/11 15:39, Mark Brown wrote:
> 
>>> Isn't that essentially what IIO is (well, there's the DAC side as well)?
>>> You're currently focusing on distributing data to userspace but that
>>> seems like a fixable limitation rather than anything else, I don't see a
>>> fundamental disconnect between users.
> 
>> Indeed, we could do it.  I suppose a lot of why I'm not just saying 'lets
>> try it and see how we go' is that there is a lot going
>> on in IIO right now with over 20,000 lines of patches under review...
>> (vast majority of that is core changes).
> 
> Right, as I've said before one of the reasons I've not looked at IIO in
> too much detail is that there's a lot of change and it's still in
> staging.
Fair enough. We'll definitely appreciate your feedback once it's stabilized!
> 
>> You've convinced me it may be sensible (and worth trying to see).  I'm not
>> sure everyone else will agree though! Mind you, despite some good responses
>> from those who have taken a look, I'm not sure Linus for one is going to like
>> IIO when we eventually send him a pull request..
> 
> One way to find out :)
Too true...  Need to hammer down the remaining ugly corners first ;)
> 
>>> It doesn't seem terribly invasive to be able to have a choice of things
>>> to notify, you already have to at least be able to work out which
>>> userspace thing to tell...
> 
>> Not really.  That is the main difference between input and iio.
>> There is one userspace route for data per device.  This is pretty bare
>> bones. There is buffering in between the device and userspace, sometime
>> it is in hardware, sometime software.
> 
> Yes, and my thought here was essentially that the bit that kicks
> userspace could with suitable use of callbacks be easily replaced by
> something that kicked an in-kernel user without too much hassle for the
> userspace users.
True for the slow path (one that feeds sysfs stuff).
The fast path deals with 'scans' of data channels. Breaking those up will be
'interesting' - it doesn't generalize well and right now it's basically up
to the individual drivers to describe what they did rather than the core
to insist on any particular form for the data.  All the information is there
to unwind this but it's going to be a little messy. All this gets to go
in the 'client' input / hwmon / other drivers anyway so not so bad as 
far as I'm concerned ;)

> 
>> We 'could' put a low latency path in place, and certainly intend to do
>> it (see the interchangable 'buffer' element of IIO, but it is not trivial.
>> It's on the todo list, but it's not there now. The other thing we have
>> is two data paths vs input's one. Input calls everything an event
>> and hence has to separately describe every bit of data coming out.
>> We still have events for threshold etc, but we also have 'data'
>> (e.g. channel reads) going through a path without needing to describe
>> the individual pieces of data (this is fixed if userspace doesn't try
>> to change it).  Note that this 'data' path is very much about ripping
>> the raw stuff off the channel (typically as a 'scan') and shoving it
>> onwards.
> 
> With the above approach I don't think IIO (or whatever) would need to
> worry about the difference - it just lets whatever is consuming the data
> deal with the blocks of data that get thrown out.
True to a certain extent, the trick is ensuring those consumers have enough
information to be able to tell what they got.
> 
>> It may make sense to do this in kernel but it is going to be rather big
>> and messy (hence the input guys suggested doing it using uinput in
>> the first place!).
> 
> Yeah, I don't know that the specific example of input makes much sense.
I thought this was one of the commonest cases for shared use ADCs?
> 
>> I'm still bothered that people will not like the weight of IIO under
>> the other subsystems.  It is only heavy if people enable the interesting
>> bits, but a lot of people might not realize that.
> 
> So long as there's suitable fast/light paths I think we'd be fine.  I
> guess another option would be to split out the userspace API from the
> driver API so that people could skip the userspace API.
That may well be worth doing - but not right now!  A lot of the stuff
Arnd suggested makes this easier.
> 
>>>> and input device (and IIO).  Thus it has multiple functions and so
>>>> to my mind belongs as an mfd core and separate hwmon and input drivers.
> 
>>> Like I say this isn't really the model the hardware is presenting here -
>>> it looks much more like a set of n ADC channels some of which have
>>> fixed purposes and some of which are generic than a single ADC.
>> I still disagree on this point.  Lets say we have an adc with 8 channels.
> 
>> 1-2 -> touch screen (input device)
>> 3-4 -> power monitoring (hwmon device)
>> 5-8 -> general purpose (IIO device - complete with 'scan' functions if
>> that makes sense the device).
> 
>> Looks exactly like an mfd to me.  There are clearly 3 functions there.
>> To a hardware engineer perhaps they look like a single one (ADC) but
>> that is clearly not how the board in question is wired up.
> 
> MFD would feel more comfortable if you had a watchdog and an RTC or
> whatever in there, and even then having three devices all of which are
> thin wrappers around a custom per-chip bit of code in the MFD core feels
> icky.
Not ideal.  If it were done in mfd I'd certainly suggest some extra core infrastructure
to support it. Ultimately wherever it is I think we'll end up with a bus 
(which IIO is anyway) with hwmon etc devices hanging off that.
> 
>>> You could do that, but like I say if we do that then what it's
>>> suggesting to me is that we should be pulling the chip drivers out of
>>> IIO and pushing them down into some new subsystem, leaving IIO as a
>>> wrapper around that subsystem for otherwise unclaimed channels (or
>>> possibly explicitly exposed channels).
> 
>> Indeed - I have been suggesting a very small layer underneath
>> (which I still think is going to look remarkably like mfd) may make more sense.  I'm basically
>> not sure either way.  We can do it in IIO, but is that the right option?
> 
> MFD is really only about register maps, registering subdevices and (for
> randomness) IRQ controllers - anything too substantial beyond those
> really feels a bit wrong there.  The ADC stuff definitely feels too
> heavyweight, especially when you start adding things like comparators on
> top of that.  There should be some subsystem we can slot this into.
Comparators should be fine if we do this with IIO,
but will need a few more hooks inserted. Translation of these into the
interfaces of hwmon in particular may be fiddly (hwmon has very limited
view of what a comparator can be telling you).

> 
>> V1 - no clever reading tricks or high throughput.
>>
>> 1) A nice generic way of specifying which channels are for which subsystem.
>> 2) Sufficient information on adc to provide the nice unit converted stuff hwmon
>> expects and the info on noise etc that input wants. The chan spec structures go
>> a way towards this - see 
>> https://git.kernel.org/?p=linux/kernel/git/jic23/iio-onwards.git;a=blob;f=drivers/staging/iio/iio.h
> 
> Looks sensible.
> 
>> 3) hwmon driver - actually this is easy given we match a lot of their interfaces
>> anyway and its SLOW..
> 
> Yes, and also /sys/class/power_supply usage.
> 
>> 4) input driver - polled only initially. Later add ability to 'steal' the trigger
>> from iio to do data ready interrupt based reading.  I can't see an easy way 
>> of making these play well together. Basically if you want to use the device for
>> anything else you have to fix the functionality of the IIO path way more than normal.
> 
> The stuff with stealing the trigger seems like a callback type problem
> to me.
The issue is that in IIO triggers are completely flexible (at least in theory
- a few corner cases in drivers trip us up). Any available trigger can driver
sampling on any device.  Obviously, much of the time if there is a dataready
signal, it is used to trigger the device providing it (defaults to this), but
that dataready can also be used to trigger other sensors - and there are 
fun use cases where even a device with a dataready is triggered by another
source.  If other 'clients' - e.g. input are registered, I think the trigger
will have to be locked to the data ready.  No one cares about datardy with
hwmon anyway so that can just read when it likes. Might put a glitch in the
IIO data stream, but those happen anyway for all sorts of other reasons! 
> 
>> V2 - buffer routing - this is nasty and may never make sense.
> 
>> 1) Allow for diversion of raw data into 'input' or the IIO buffer on triggering.
>> Note configurable triggers will still not be possible as far as I can see.
>> To configure them you have to disable all sampling - if someone else is using them
>> you can't do that.
> 
> For low volume devices I guess you can do a lot of this in software
> relatively painlessly; so long as it doesn't impact high volume devices
> ("I used DMA to fill that buffer, honest!") I guess that's fine.
Yup, ideally need to keep even the hooks out of high volume path.  Guess driver
writer can decide if their device is going to support alternate data paths
or not!

[RFC] What is the preferred way to share ADC unit between hwmon and input(ts) drivers?

[Jonathan Cameron]

On 05/09/11 20:54, Mark Brown wrote:
> On Mon, May 09, 2011 at 05:35:01PM +0100, Jonathan Cameron wrote:
>> On 05/09/11 15:39, Mark Brown wrote:
> 
>>> Isn't that essentially what IIO is (well, there's the DAC side as well)?
>>> You're currently focusing on distributing data to userspace but that
>>> seems like a fixable limitation rather than anything else, I don't see a
>>> fundamental disconnect between users.
> 
>> Indeed, we could do it.  I suppose a lot of why I'm not just saying 'lets
>> try it and see how we go' is that there is a lot going
>> on in IIO right now with over 20,000 lines of patches under review...
>> (vast majority of that is core changes).
> 
> Right, as I've said before one of the reasons I've not looked at IIO in
> too much detail is that there's a lot of change and it's still in
> staging.
Fair enough. We'll definitely appreciate your feedback once it's stabilized!
> 
>> You've convinced me it may be sensible (and worth trying to see).  I'm not
>> sure everyone else will agree though! Mind you, despite some good responses
>> from those who have taken a look, I'm not sure Linus for one is going to like
>> IIO when we eventually send him a pull request..
> 
> One way to find out :)
Too true...  Need to hammer down the remaining ugly corners first ;)
> 
>>> It doesn't seem terribly invasive to be able to have a choice of things
>>> to notify, you already have to at least be able to work out which
>>> userspace thing to tell...
> 
>> Not really.  That is the main difference between input and iio.
>> There is one userspace route for data per device.  This is pretty bare
>> bones. There is buffering in between the device and userspace, sometime
>> it is in hardware, sometime software.
> 
> Yes, and my thought here was essentially that the bit that kicks
> userspace could with suitable use of callbacks be easily replaced by
> something that kicked an in-kernel user without too much hassle for the
> userspace users.
True for the slow path (one that feeds sysfs stuff).
The fast path deals with 'scans' of data channels. Breaking those up will be
'interesting' - it doesn't generalize well and right now it's basically up
to the individual drivers to describe what they did rather than the core
to insist on any particular form for the data.  All the information is there
to unwind this but it's going to be a little messy. All this gets to go
in the 'client' input / hwmon / other drivers anyway so not so bad as 
far as I'm concerned ;)

> 
>> We 'could' put a low latency path in place, and certainly intend to do
>> it (see the interchangable 'buffer' element of IIO, but it is not trivial.
>> It's on the todo list, but it's not there now. The other thing we have
>> is two data paths vs input's one. Input calls everything an event
>> and hence has to separately describe every bit of data coming out.
>> We still have events for threshold etc, but we also have 'data'
>> (e.g. channel reads) going through a path without needing to describe
>> the individual pieces of data (this is fixed if userspace doesn't try
>> to change it).  Note that this 'data' path is very much about ripping
>> the raw stuff off the channel (typically as a 'scan') and shoving it
>> onwards.
> 
> With the above approach I don't think IIO (or whatever) would need to
> worry about the difference - it just lets whatever is consuming the data
> deal with the blocks of data that get thrown out.
True to a certain extent, the trick is ensuring those consumers have enough
information to be able to tell what they got.
> 
>> It may make sense to do this in kernel but it is going to be rather big
>> and messy (hence the input guys suggested doing it using uinput in
>> the first place!).
> 
> Yeah, I don't know that the specific example of input makes much sense.
I thought this was one of the commonest cases for shared use ADCs?
> 
>> I'm still bothered that people will not like the weight of IIO under
>> the other subsystems.  It is only heavy if people enable the interesting
>> bits, but a lot of people might not realize that.
> 
> So long as there's suitable fast/light paths I think we'd be fine.  I
> guess another option would be to split out the userspace API from the
> driver API so that people could skip the userspace API.
That may well be worth doing - but not right now!  A lot of the stuff
Arnd suggested makes this easier.
> 
>>>> and input device (and IIO).  Thus it has multiple functions and so
>>>> to my mind belongs as an mfd core and separate hwmon and input drivers.
> 
>>> Like I say this isn't really the model the hardware is presenting here -
>>> it looks much more like a set of n ADC channels some of which have
>>> fixed purposes and some of which are generic than a single ADC.
>> I still disagree on this point.  Lets say we have an adc with 8 channels.
> 
>> 1-2 -> touch screen (input device)
>> 3-4 -> power monitoring (hwmon device)
>> 5-8 -> general purpose (IIO device - complete with 'scan' functions if
>> that makes sense the device).
> 
>> Looks exactly like an mfd to me.  There are clearly 3 functions there.
>> To a hardware engineer perhaps they look like a single one (ADC) but
>> that is clearly not how the board in question is wired up.
> 
> MFD would feel more comfortable if you had a watchdog and an RTC or
> whatever in there, and even then having three devices all of which are
> thin wrappers around a custom per-chip bit of code in the MFD core feels
> icky.
Not ideal.  If it were done in mfd I'd certainly suggest some extra core infrastructure
to support it. Ultimately wherever it is I think we'll end up with a bus 
(which IIO is anyway) with hwmon etc devices hanging off that.
> 
>>> You could do that, but like I say if we do that then what it's
>>> suggesting to me is that we should be pulling the chip drivers out of
>>> IIO and pushing them down into some new subsystem, leaving IIO as a
>>> wrapper around that subsystem for otherwise unclaimed channels (or
>>> possibly explicitly exposed channels).
> 
>> Indeed - I have been suggesting a very small layer underneath
>> (which I still think is going to look remarkably like mfd) may make more sense.  I'm basically
>> not sure either way.  We can do it in IIO, but is that the right option?
> 
> MFD is really only about register maps, registering subdevices and (for
> randomness) IRQ controllers - anything too substantial beyond those
> really feels a bit wrong there.  The ADC stuff definitely feels too
> heavyweight, especially when you start adding things like comparators on
> top of that.  There should be some subsystem we can slot this into.
Comparators should be fine if we do this with IIO,
but will need a few more hooks inserted. Translation of these into the
interfaces of hwmon in particular may be fiddly (hwmon has very limited
view of what a comparator can be telling you).

> 
>> V1 - no clever reading tricks or high throughput.
>>
>> 1) A nice generic way of specifying which channels are for which subsystem.
>> 2) Sufficient information on adc to provide the nice unit converted stuff hwmon
>> expects and the info on noise etc that input wants. The chan spec structures go
>> a way towards this - see 
>> https://git.kernel.org/?p=linux/kernel/git/jic23/iio-onwards.git;a=blob;f=drivers/staging/iio/iio.h
> 
> Looks sensible.
> 
>> 3) hwmon driver - actually this is easy given we match a lot of their interfaces
>> anyway and its SLOW..
> 
> Yes, and also /sys/class/power_supply usage.
> 
>> 4) input driver - polled only initially. Later add ability to 'steal' the trigger
>> from iio to do data ready interrupt based reading.  I can't see an easy way 
>> of making these play well together. Basically if you want to use the device for
>> anything else you have to fix the functionality of the IIO path way more than normal.
> 
> The stuff with stealing the trigger seems like a callback type problem
> to me.
The issue is that in IIO triggers are completely flexible (at least in theory
- a few corner cases in drivers trip us up). Any available trigger can driver
sampling on any device.  Obviously, much of the time if there is a dataready
signal, it is used to trigger the device providing it (defaults to this), but
that dataready can also be used to trigger other sensors - and there are 
fun use cases where even a device with a dataready is triggered by another
source.  If other 'clients' - e.g. input are registered, I think the trigger
will have to be locked to the data ready.  No one cares about datardy with
hwmon anyway so that can just read when it likes. Might put a glitch in the
IIO data stream, but those happen anyway for all sorts of other reasons! 
> 
>> V2 - buffer routing - this is nasty and may never make sense.
> 
>> 1) Allow for diversion of raw data into 'input' or the IIO buffer on triggering.
>> Note configurable triggers will still not be possible as far as I can see.
>> To configure them you have to disable all sampling - if someone else is using them
>> you can't do that.
> 
> For low volume devices I guess you can do a lot of this in software
> relatively painlessly; so long as it doesn't impact high volume devices
> ("I used DMA to fill that buffer, honest!") I guess that's fine.
Yup, ideally need to keep even the hooks out of high volume path.  Guess driver
writer can decide if their device is going to support alternate data paths
or not!

[RFC] What is the preferred way to share ADC unit between hwmon and input(ts) drivers?

[Ithamar R. Adema]

On Fri, 2011-05-06 at 15:23 +0100, Mark Brown wrote:
> I'd have expected that this stuff should be able to fit into IIO and
> that it would be able to be used by in-kernel users. 

My bad, I misread IIO for something else. After a quick glance at the
IIO patches I fully agree it would be a much better solution.

Sorry for the noise...

Ithamar.

[RFC] What is the preferred way to share ADC unit between hwmon and input(ts) drivers?

[Linus Walleij]

2011/4/25 Ilya Yanok <yanok@emcraft.com>:

> So, to add both input and hwmon drivers we need to serialize the
> register accesses.(...) Should we use a multi-function device driver
> for this

Yes. Use MFD. We use MFD for say drivers/mfd/ab3100-core.c and
what is does is essentially serialize the I2C read/writes using a
mutex, it spawnd MFD cell children for say drivers/regulator/ab3100.c

In your case spawn a foo-hwmon and foo-input MFD cell from your
MFD driver core.

> or just some platform-specific code (as S3C does)?

And where are you going to put that? Into arch/arm/mach-* where
Linus (the other one) is already upset with the prevalence of
driver code not being factored to share common infrastructure?

Yours,
Linus Walleij