lkml.org 
[lkml]   [2010]   [Dec]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v3 0/4] Introduce hardware spinlock framework
    On Sat, Dec 4, 2010 at 2:29 AM, David Daney <ddaney@caviumnetworks.com> wrote:
    > Does anything other than OMAP4 have one of these things?

    I'm not aware of any, but David Brownell had some ideas about it in
    our previous v2 discussion (see
    http://www.mail-archive.com/linux-omap@vger.kernel.org/msg39413.html).

    Btw, you might want to read throughout that entire discussion with
    David, since it was touching the same questions you raise here.

    > And are there any
    > devices that are commonly encountered across more than one platform that
    > might have these hardware spinlocks, thus making it advantageous to have a
    > common framework?

    Such devices are just multiple processors that have no alternative
    mechanism to accomplish synchronization.

    OMAP4 has a few non-coherent heterogeneous processors that do not
    support fancy synchronization primitives, so it needs this hwspinlock
    peripheral.

    Otherwise, I don't know how common that is (/might become), and I'd
    hate speculating, but I suspect that OMAP is not going to be the only
    platform with multiple coprocessors, that have no other means of
    achieving synchronization, and with which inter-processor
    communications is desired.

    >
    > If not why a general purpose framework for a very chip specific feature?

    We started out with an omap-specific driver (see first iteration at
    http://lwn.net/Articles/410375/), but were asked to make it a
    platform-agnostic framework, in order to keep the IPC drivers that
    will use it generic (and assuming that more users will show up for
    such framework).

    To me it sounds reasonable, but again, I prefer not to speculate how
    many users will show up for this, if any.

    Both ways (framework / omap-specific driver) will work for us just fine.

    >
    > There are chips with hardware atomic memory, but the only time it makes
    > sense to use it is in conjunction with specialize on-chip devices.  So the
    > implementation details are kept in the drivers rather than creating a
    > general purpose hwatomic (with its hwatomic_add() et al.) type.

    This case is a bit different IMHO: some of the potential users of
    hwspinlocks are just generic IPC drivers that are by no means
    platform-specific. It's not a special on-chip device: it's just one
    processor, trying to achieve mutual exclusion with another processor,
    before manipulating some shared data structure.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2010-12-04 02:31    [W:0.023 / U:332.656 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site