lkml.org 
[lkml]   [2012]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 5/8] mfd: Provide the PRCMU with its own IRQ domain
    On Mon, Aug 20, 2012 at 05:49:50PM +0100, Lee Jones wrote:
    > On Mon, Aug 20, 2012 at 05:29:23PM +0100, Mark Brown wrote:

    > > All of the regmap devices could use this.

    > Only if they have linear domains and don't support DT.

    Neither of those restrictions really apply...

    > If they don't have linear domains there's no point, if they support DT
    > then they can use it as it is.

    All this stuff just works for any IRQ domain type, there's no
    requirement for a particular one. It's not urgently exciting for legacy
    domains but it's not harmful either and pushes all the handling of this
    stuff out of the MFD core and into the irqdomain code which is
    definitely an abstraction win.

    As far as DT goes supporting DT isn't enough, the current code will only
    work on systems that actively use DT and do so using a particular style
    of binding. Since the majority of Linux architectures don't support DT
    at all and it's not universally deployed on those that do this means
    that generic drivers can't rely on it, and even drivers that use DT
    might not be using the binding pattern which the framework code now
    uses.

    Indeed now that I think about the above isn't this going to be actively
    harmful for generic drivers if they use this pattern for their bindings?
    On DT systems the framework will unconditionally do the mapping but on
    others no mapping will be done. The function drivers don't know if the
    mapping has been performed or not.

    Unless I'm missing something here we need to fix this before the merge
    window...

    > To stop being DT dependent we'd need to remove all hand-rolled stuff
    > that these drivers are currently using, or else they will be attempting
    > to convert and already converted VIRQ value.

    Well, yes - using framework code would be the goal here...
    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2012-08-20 20:41    [W:4.361 / U:0.620 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site