[lkml]   [2010]   [Oct]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 3/3] omap: add hwspinlock device
    On Mon, Oct 25, 2010 at 9:02 PM, Tony Lindgren <> wrote:
    >> if you feel that (2) is justifiable/desirable, I would be more
    >> than happy to submit that version.
    > Yes (2) please. I would assume there will be more use of this. And then
    > we (or probably me again!) don't have to deal with cleaning up the drivers
    > again in the future.

    Sounds good.

    >> Or do you mean a variation of (2) with only the specific locking bits
    >> coming from pdata func pointers ? I guess that in this case we just
    >> might as well go with the full (2).
    > Yes variation of (2) where you only pass the locking function via
    > platform data would be best.

    It feels a bit funky to me because we would still have code that is
    omap-specific inside the "common" probe()/remove() calls.

    I suggest to move everything that is omap-specific to a small omap
    module that, once probed, would register itself with the common
    hwspinlock framework (after initializing its hardware).

    That small platfom-specific module probably doesn't have to sit in the
    arch/ folder; we can follow established conventions like

    With that in hand, the hwspinlock would really be hardware-agnostic,
    and then applying s/omap_hwspin/hwspin/ would be justified.

    Does this sound reasonable to you ?


     \ /
      Last update: 2010-10-26 13:57    [W:0.019 / U:2.260 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site