[lkml]   [2011]   [Apr]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [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.
    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

     \ /
      Last update: 2011-04-04 20:09    [W:0.032 / U:48.100 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site