Messages in this thread | | | Date | Mon, 04 Apr 2011 19:09:08 +0100 | From | Jonathan Cameron <> | Subject | Re: [RFC PATCH 00/21] IIO: Channel registration rework, buffer chardev combining and rewrite of triggers as 'virtual' irq_chips. |
| |
.... >> >>> 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). ...
| |