[lkml]   [2011]   [Dec]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH v2 0/4] irq/of: Cleanup and Enchance irq_domain support.
    On Fri, Dec 30, 2011 at 8:30 AM, Rob Herring <> wrote:
    > David,
    > On 12/14/2011 08:32 PM, David Daney wrote:
    >> From: David Daney <>
    >> Back in early Nov. I send the first version of this patch set.  Now
    >> things are heating up again in the world of irq_domain, so I wanted to
    >> try to get some closure on the issues I had.  The Octeon patch is
    >> included here to show how I am using irq_domain, but is part of a much
    >> larger effort to merge Octeon device tree support.
    >> The basic problem I am attempting to solve is using irq domains when
    >> there is a 'non-linear' mapping of hwirq <--> irq within a domain.
    >> Octeon has a single set of irq numbers that is used across two
    >> different implementations of the interrupt controller as well as more
    >> than 10 different SOCs all which use different subsets of the irq
    >> number space.  The result is that the hwirq to irq mapping function
    >> contains many gaps and discontinuities, it is really quite random.
    >> The existing irq domain infrastructure assumes a continuous linear
    >> mapping of hwirq to irq that can be encapsulated by the irq_base,
    >> hwirq_base and nr_irq elements of struct irq_domain.  This is not
    >> suitable for the Octeon implementation.
    >> The gist of my change is to add an optional iterator function to
    >> irq_domain_ops which knows how to iterate over the irq numbers in a
    >> given domain.  For simple linear domains (those currently supported),
    >> we iterate using the current method based on irq_base, hwirq_base and
    >> nr_irq.
    >> Summary of the patches:
    >> 1) Get rid of some unused code to make subsequent changes simpler.
    >> 2) Cleanup the data type used by various hwirq functions and users.
    >> 3) Add the irq iterator, and fix up the ARM GIC code to use it instead
    >> of the current irq_domain_for_each_irq().
    >> 4) Add the Octeon users of the interface.
    >> In an earlier exchange, Rob Herring had said:
    >>    ... Handling sparse irqs is a potentially common problem, so we
    >>    should address that in the core irqdomain code.
    >> Which is what this patch set is doing.
    >> There was a suggestion that perhaps having .to_irq() return a magic
    >> value if there was no mapping would also work.  However I prefer this
    >> approach as it separates the concepts of iteration and mapping of irq
    >> numbers.
    >> Please comment.
    > Can we first have a patch that just allows irq domains to be enabled on
    > MIPS. It collides because of multiple versions of irq_create_of_mapping.

    I'm working on this. I made some poor decisions when first
    implementing irq_domain which have made it difficult to bring into
    sync with powerpc. Right now I'm working on a series to replace the
    new irq_domain with the existing (working-for-years) powerpc code and
    converting over all the users. Basically what I should have done in
    the first place.


    Grant Likely, B.Sc., P.Eng.
    Secret Lab Technologies Ltd.
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2011-12-30 19:23    [W:0.024 / U:1.788 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site