All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Ohad Ben-Cohen <ohad@wizery.com>
Cc: linux-omap@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH 04/10] hwspinlock/core/omap: fix id issues on multiple hwspinlock devices
Date: Wed, 21 Sep 2011 09:14:06 -0700	[thread overview]
Message-ID: <20110921161406.GF2937@atomide.com> (raw)
In-Reply-To: <1315846025-11453-5-git-send-email-ohad@wizery.com>

* Ohad Ben-Cohen <ohad@wizery.com> [110912 09:14]:
> hwspinlock devices provide system-wide hardware locks that are used
> by remote processors that have no other way to achieve synchronization.
> 
> For that to work, each physical lock must have a system-wide unique id
> number that all processors are familiar with, otherwise they can't
> possibly assume they're using the same hardware lock.
> 
> Usually SoCs have a single hwspinlock device, which provides several
> hwspinlocks, and in this case, they can be trivially numbered 0 to
> (num-of-locks - 1).
> 
> In case boards have several hwspinlocks devices (each of which
> providing numerous hardware spinlocks) a different base id should be
> used for each hwspinlock device (they can't all use 0 as a starting
> id!).
> 
> While this is certainly not common, it's just plain wrong to just
> silently use 0 as a base id whenever the hwspinlock driver is probed.
> 
> This patch provides a hwspinlock_pdata structure, that boards can use
> to set a different base id for each of the hwspinlock devices they may
> have, and demonstrates how to use it with the omap hwspinlock driver
> (ultimately it will be DT which will supply this base_id information).
> 
> While we're at it, make sure the hwspinlock core prints an explicit
> error message in case an hwspinlock is registered with an id number
> that already exists; this will help users catch such base id issues.
> 
> Reported-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>

Acked-by: Tony Lindgren <tony@atomide.com>

WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 04/10] hwspinlock/core/omap: fix id issues on multiple hwspinlock devices
Date: Wed, 21 Sep 2011 09:14:06 -0700	[thread overview]
Message-ID: <20110921161406.GF2937@atomide.com> (raw)
In-Reply-To: <1315846025-11453-5-git-send-email-ohad@wizery.com>

* Ohad Ben-Cohen <ohad@wizery.com> [110912 09:14]:
> hwspinlock devices provide system-wide hardware locks that are used
> by remote processors that have no other way to achieve synchronization.
> 
> For that to work, each physical lock must have a system-wide unique id
> number that all processors are familiar with, otherwise they can't
> possibly assume they're using the same hardware lock.
> 
> Usually SoCs have a single hwspinlock device, which provides several
> hwspinlocks, and in this case, they can be trivially numbered 0 to
> (num-of-locks - 1).
> 
> In case boards have several hwspinlocks devices (each of which
> providing numerous hardware spinlocks) a different base id should be
> used for each hwspinlock device (they can't all use 0 as a starting
> id!).
> 
> While this is certainly not common, it's just plain wrong to just
> silently use 0 as a base id whenever the hwspinlock driver is probed.
> 
> This patch provides a hwspinlock_pdata structure, that boards can use
> to set a different base id for each of the hwspinlock devices they may
> have, and demonstrates how to use it with the omap hwspinlock driver
> (ultimately it will be DT which will supply this base_id information).
> 
> While we're at it, make sure the hwspinlock core prints an explicit
> error message in case an hwspinlock is registered with an id number
> that already exists; this will help users catch such base id issues.
> 
> Reported-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>

Acked-by: Tony Lindgren <tony@atomide.com>

  reply	other threads:[~2011-09-21 16:14 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-12 16:46 [PATCH 00/10] hwspinlock-next Ohad Ben-Cohen
2011-09-12 16:46 ` Ohad Ben-Cohen
2011-09-12 16:46 ` Ohad Ben-Cohen
2011-09-12 16:46 ` [PATCH 01/10] hwspinlock/core: simplify Kconfig Ohad Ben-Cohen
2011-09-12 16:46   ` Ohad Ben-Cohen
2011-09-12 16:46   ` Ohad Ben-Cohen
2011-09-12 16:46 ` [PATCH 02/10] hwspinlock/core: simplify 'owner' handling Ohad Ben-Cohen
2011-09-12 16:46   ` Ohad Ben-Cohen
2011-09-12 16:46   ` Ohad Ben-Cohen
2011-09-12 16:46 ` [PATCH 03/10] hwspinlock/omap: simplify allocation scheme Ohad Ben-Cohen
2011-09-12 16:46   ` Ohad Ben-Cohen
2011-09-12 16:46   ` Ohad Ben-Cohen
2011-09-12 16:46 ` [PATCH 04/10] hwspinlock/core/omap: fix id issues on multiple hwspinlock devices Ohad Ben-Cohen
2011-09-12 16:46   ` Ohad Ben-Cohen
2011-09-12 16:46   ` Ohad Ben-Cohen
2011-09-21 16:14   ` Tony Lindgren [this message]
2011-09-21 16:14     ` Tony Lindgren
2011-09-12 16:47 ` [PATCH 05/10] hwspinlock/core: use a mutex to protect the radix tree Ohad Ben-Cohen
2011-09-12 16:47   ` Ohad Ben-Cohen
2011-09-12 16:47   ` Ohad Ben-Cohen
2011-09-12 16:47 ` [PATCH 06/10] hwspinlock/core: remove stubs for register/unregister Ohad Ben-Cohen
2011-09-12 16:47   ` Ohad Ben-Cohen
2011-09-12 16:47   ` Ohad Ben-Cohen
2011-09-12 16:47 ` [PATCH 07/10] hwspinlock/core: register a bank of hwspinlocks in a single API call Ohad Ben-Cohen
2011-09-12 16:47   ` Ohad Ben-Cohen
2011-09-12 16:47   ` Ohad Ben-Cohen
2011-09-12 16:47 ` [PATCH 08/10] hwspinlock/u8500: add hwspinlock driver Ohad Ben-Cohen
2011-09-12 16:47   ` Ohad Ben-Cohen
2011-09-12 16:47   ` Ohad Ben-Cohen
2011-09-12 16:47 ` [PATCH 09/10] hwspinlock/omap: omap_hwspinlock_remove should be __devexit Ohad Ben-Cohen
2011-09-12 16:47   ` Ohad Ben-Cohen
2011-09-12 16:47   ` Ohad Ben-Cohen
2011-09-12 16:47 ` [PATCH 10/10] hwspinlock: add MAINTAINERS entries Ohad Ben-Cohen
2011-09-12 16:47   ` Ohad Ben-Cohen
2011-09-12 16:47   ` Ohad Ben-Cohen
2011-09-12 16:58   ` Joe Perches
2011-09-12 16:58     ` Joe Perches
2011-09-12 16:58     ` Joe Perches
2011-09-12 17:01     ` Ohad Ben-Cohen
2011-09-12 17:01       ` Ohad Ben-Cohen
2011-09-12 17:01       ` Ohad Ben-Cohen
2011-09-20  9:07 ` [PATCH 00/10] hwspinlock-next Ohad Ben-Cohen
2011-09-20  9:07   ` Ohad Ben-Cohen
2011-09-20  9:07   ` Ohad Ben-Cohen
2011-09-20 23:13   ` Tony Lindgren
2011-09-20 23:13     ` Tony Lindgren
2011-09-20 23:45     ` Greg KH
2011-09-20 23:45       ` Greg KH
2011-09-21 15:24       ` Tony Lindgren
2011-09-21 15:24         ` Tony Lindgren
2011-09-21 14:12     ` Arnd Bergmann
2011-09-21 14:12       ` Arnd Bergmann
2011-09-21 15:28       ` Tony Lindgren
2011-09-21 15:28         ` Tony Lindgren
2011-09-21 15:56         ` Ohad Ben-Cohen
2011-09-21 15:56           ` Ohad Ben-Cohen
2011-09-21 15:56           ` Ohad Ben-Cohen
2011-09-21 16:07           ` Ohad Ben-Cohen
2011-09-21 16:07             ` Ohad Ben-Cohen
2011-09-21 16:14             ` Tony Lindgren
2011-09-21 16:14               ` Tony Lindgren
2011-09-21 16:16               ` Ohad Ben-Cohen
2011-09-21 16:16                 ` Ohad Ben-Cohen
2011-09-21 15:53       ` Linus Walleij
2011-09-21 15:53         ` Linus Walleij
2011-09-21 16:21         ` Arnd Bergmann
2011-09-21 16:21           ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110921161406.GF2937@atomide.com \
    --to=tony@atomide.com \
    --cc=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=ohad@wizery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.