Re: [RFC PATCH 00/21] IIO: Channel registration rework, buffer chardevcombining and rewrite of triggers as 'virtual' irq_chips.

From: Jonathan Cameron
Date: Mon Apr 04 2011 - 14:07:37 EST


....
>>
>>> However there are some limitations.
>>> read_raw() value is currently type int, depending on the channel type,
>>> int type might be too short.
>>>
>> True. How far do you think we should go? s64? I did wonder if it makes sense
>> to have two value pointers (perhaps NULL) So base unit (val1) and
>> decimal places of base unit (val2).
>>
>> So true raw values (e.g. sensor readings) will only set val1, but we have plenty
>> of space for things like scale at sufficient accuracy. That also means we can
>> flatten together the attributes in the core for both cases (not a great saving
>> but nice to have none the less).
>>
>> What do you think?
>>
> 64-bit arithmetic is a bit tricky on Linux. On some platforms you can't
> use the native 64-bit divide.
> You have to use do_div() instead. So I don't think we should always use
> type s64.
> As you proposed in your follow up email - depending on the return value
> we can use val1 and val2.
Cool, I'll give that a go. I'll also blindly port a few more drivers
over to the new framework and see where problems occur.
>>>
>>>
>>>> Patches 9 and 10 are minor rearrangements of code in the one
>>>> driver I know of where the physical interrupt line for events
>>>> is the same as that for data ready signals (though not at the
>>>> same time).
>>>>
>>>>
>>> I wouldn't consider this being a corner case. I know quite a few devices
>>> that trigger data availability,
>>> and other events from the same physical interrupt line, and they may do
>>> it at the same time.
>>>
>> If they do it at the same time things may get a bit nasty. Things are somewhat
>> simpler after some of the later patches, as the irq requests are entirely
>> handled in the drivers. Thus the driver could have one interrupt handler.
>> The restriction will be that it would only be able to do nested irq calls
>> limiting us to not having a top half for anything triggered from such an
>> interrupt. This is because identifying whether we have a dataready or
>> other event will require querying the device and hence sleeping. Note
>> the sysfs trigger driver will also have this restriction (as posted yesterday).
>>
>> For devices where they share the line but cannot happen at the same time I'd
>> prefer to do what we have in the lis3l02dq and completely separate the two
>> uses of the interrupt line.
I've been persuaded otherwise ;) See other branch of thread.
>>
>>
>>>
>>>
>>>> In a rare situation we have complete control of these virtual
>>>> interrupts within the subsystem. As such we want to be able to
>>>> continue to build the subsystem as a module. This requires a
>>>> couple of additional exports in the generic irq core code and
>>>> also arm (for my test board anyway).
>>>> Patches 13 and 14 make these changes. I hope they won't prove
>>>> to controversial.
>>>>
>>>> Patch 15 adds a board info built in element to the IIO subsystem
>>>> so we have a means of platform data telling us what interrupt
>>>> numbers are available for us to play with. Does anyone have
>>>> a better way of doing this? Patch 16 is an example of what
>>>> needs to go in board files.
>>>>
>>>>
>>> Since this is purely platform dependent, setting the irq pool from the
>>> board setup looks acceptable to me, and depending on the arch or machine
>>> it might be necessary two tweak some other defines.
>>> However many arches define NR_IRQS always greater than actually used. So
>>> why not make IR-Base a Kconfig option?
>>>
>> There is currently a nasty hack in the irq codes to deal with the fact that
>> for at least some (maybe all) arm chips NR_IRQS is set to those on the SOC
>> and doesn't include any others. The work around for that is that all the
>> irq handling adds a chunk of padding. I would hope that will go away at
>> some point in the future.
>>
> Back in 2009, when doing the ADP5520 MFD, I came to the same conclusion.
> Sad to see that things are still the same.
>
> http://kerneltrap.org/mailarchive/linux-kernel/2009/9/29/4492190/thread
Yes. I guess that fuzz has to happen somewhere even if it is just a case
of platforms defining it to be big enough for all known boards (which is
hideous).
...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/