All of lore.kernel.org
 help / color / mirror / Atom feed
From: Suman Anna <s-anna@ti.com>
To: Kumar Gala <galak@codeaurora.org>
Cc: Ohad Ben-Cohen <ohad@wizery.com>,
	Tony Lindgren <tony@atomide.com>,
	Benoit Cousson <bcousson@baylibre.com>,
	linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org,
	devicetree@vger.kernel.org
Subject: Re: [PATCH 1/2] hwspinlock/omap: add support for dt nodes
Date: Wed, 4 Sep 2013 11:27:41 -0500	[thread overview]
Message-ID: <52275F7D.4030305@ti.com> (raw)
In-Reply-To: <71570936-39F5-4AE1-AD05-163EA3179271@codeaurora.org>

Kumar,

>>>>>
>>>>>> HwSpinlock IP is present only on OMAP4 and other newer SoCs,
>>>>>> which are all device-tree boot only. This patch adds the
>>>>>> base support for parsing the DT nodes, and removes the code
>>>>>> dealing with the traditional platform device instantiation.
>>>>>>
>>>>>> Signed-off-by: Suman Anna <s-anna@ti.com>
>>>>>> ---
>>>>>> .../devicetree/bindings/hwlock/omap-hwspinlock.txt | 28 ++++++++++
>>>>>> arch/arm/mach-omap2/Makefile                       |  3 --
>>>>>> arch/arm/mach-omap2/hwspinlock.c                   | 60 ----------------------
>>>>>> drivers/hwspinlock/omap_hwspinlock.c               | 21 ++++++--
>>>>>> 4 files changed, 45 insertions(+), 67 deletions(-)
>>>>>> create mode 100644 Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
>>>>>> delete mode 100644 arch/arm/mach-omap2/hwspinlock.c
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
>>>>>> new file mode 100644
>>>>>> index 0000000..adfb8ad
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
>>>>>> @@ -0,0 +1,28 @@
>>>>>> +OMAP4+ HwSpinlock Driver
>>>>>> +
>>>>>> +Required properties:
>>>>>> +- compatible:		Currently supports only "ti,omap4-hwspinlock" for
>>>>>> +				OMAP44xx, OMAP54xx, AM33xx, AM43xx, DRA7xx SoCs
>>>>>> +- reg:			Contains the hwspinlock register address range (base
>>>>>> +			address and length)
>>>>>> +- ti,hwmods:		Name of the hwmod associated with the hwspinlock device
>>>>>> +
>>>>>> +Optional properties:
>>>>>> +- base_id:		Base Id for the locks for a particular hwspinlock
>>>>>> +			device. If not mentioned, a default value of 0 is used.
>>>>>> +			This property is mandatory ONLY if a SoC has several
>>>>>> +			hwspinlock devices. There are currently no such OMAP
>>>>>> +			SoCs.
>>>>>
>>>>> Should this be ti,base_id ? [ I know its kinda generic in its intent for any SoC w/multiple blocks ]
>>>>
>>>> I didn't add the "ti," prefix exactly for the same reason - it is
>>>> generic w.r.t the hwspinlock core irrespective of the SoC family, and
>>>> there is nothing ti or OMAP specific about it. I have added it to keep
>>>> the DT node definition in sync with the driver code. If it is too
>>>> generic a name, it can always be renamed as hwlock_base_id. This will be
>>>> SoC agnostic property for the hwspinlock driver. What do you think?
>>>
>>> I'm wondering if we should use cell-index for this purpose.
>>
>> I didn't get you completely. Do you intend to compute the base_id using
>> cell-index and number of locks (which may be a separate field altogether
>> if this information cannot be read from the h/w)? My understanding is
>> that cell-index is primarily used for identifying the h/w instance number.
> 
> I was suggesting using cell-index instead of base_id.  What we should probably due is have a devicetree/bindings/hwlock/hwlock.txt that would describe generic properties like this and just reference that in the omap binding spec.

Common hwlock.txt sounds good. Will make the change.

> 
> I'm thinking if we dont use cell-index, that it should probably be hwlock-base-id
> 

I prefer to use hwlock-base-id. I think we should also be defining a
common property name for number of locks, say hwlock-num-locks.

regards
Suman


WARNING: multiple messages have this Message-ID (diff)
From: Suman Anna <s-anna@ti.com>
To: Kumar Gala <galak@codeaurora.org>
Cc: Ohad Ben-Cohen <ohad@wizery.com>,
	Tony Lindgren <tony@atomide.com>,
	Benoit Cousson <bcousson@baylibre.com>,
	<linux-kernel@vger.kernel.org>, <linux-omap@vger.kernel.org>,
	<devicetree@vger.kernel.org>
Subject: Re: [PATCH 1/2] hwspinlock/omap: add support for dt nodes
Date: Wed, 4 Sep 2013 11:27:41 -0500	[thread overview]
Message-ID: <52275F7D.4030305@ti.com> (raw)
In-Reply-To: <71570936-39F5-4AE1-AD05-163EA3179271@codeaurora.org>

Kumar,

>>>>>
>>>>>> HwSpinlock IP is present only on OMAP4 and other newer SoCs,
>>>>>> which are all device-tree boot only. This patch adds the
>>>>>> base support for parsing the DT nodes, and removes the code
>>>>>> dealing with the traditional platform device instantiation.
>>>>>>
>>>>>> Signed-off-by: Suman Anna <s-anna@ti.com>
>>>>>> ---
>>>>>> .../devicetree/bindings/hwlock/omap-hwspinlock.txt | 28 ++++++++++
>>>>>> arch/arm/mach-omap2/Makefile                       |  3 --
>>>>>> arch/arm/mach-omap2/hwspinlock.c                   | 60 ----------------------
>>>>>> drivers/hwspinlock/omap_hwspinlock.c               | 21 ++++++--
>>>>>> 4 files changed, 45 insertions(+), 67 deletions(-)
>>>>>> create mode 100644 Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
>>>>>> delete mode 100644 arch/arm/mach-omap2/hwspinlock.c
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
>>>>>> new file mode 100644
>>>>>> index 0000000..adfb8ad
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
>>>>>> @@ -0,0 +1,28 @@
>>>>>> +OMAP4+ HwSpinlock Driver
>>>>>> +
>>>>>> +Required properties:
>>>>>> +- compatible:		Currently supports only "ti,omap4-hwspinlock" for
>>>>>> +				OMAP44xx, OMAP54xx, AM33xx, AM43xx, DRA7xx SoCs
>>>>>> +- reg:			Contains the hwspinlock register address range (base
>>>>>> +			address and length)
>>>>>> +- ti,hwmods:		Name of the hwmod associated with the hwspinlock device
>>>>>> +
>>>>>> +Optional properties:
>>>>>> +- base_id:		Base Id for the locks for a particular hwspinlock
>>>>>> +			device. If not mentioned, a default value of 0 is used.
>>>>>> +			This property is mandatory ONLY if a SoC has several
>>>>>> +			hwspinlock devices. There are currently no such OMAP
>>>>>> +			SoCs.
>>>>>
>>>>> Should this be ti,base_id ? [ I know its kinda generic in its intent for any SoC w/multiple blocks ]
>>>>
>>>> I didn't add the "ti," prefix exactly for the same reason - it is
>>>> generic w.r.t the hwspinlock core irrespective of the SoC family, and
>>>> there is nothing ti or OMAP specific about it. I have added it to keep
>>>> the DT node definition in sync with the driver code. If it is too
>>>> generic a name, it can always be renamed as hwlock_base_id. This will be
>>>> SoC agnostic property for the hwspinlock driver. What do you think?
>>>
>>> I'm wondering if we should use cell-index for this purpose.
>>
>> I didn't get you completely. Do you intend to compute the base_id using
>> cell-index and number of locks (which may be a separate field altogether
>> if this information cannot be read from the h/w)? My understanding is
>> that cell-index is primarily used for identifying the h/w instance number.
> 
> I was suggesting using cell-index instead of base_id.  What we should probably due is have a devicetree/bindings/hwlock/hwlock.txt that would describe generic properties like this and just reference that in the omap binding spec.

Common hwlock.txt sounds good. Will make the change.

> 
> I'm thinking if we dont use cell-index, that it should probably be hwlock-base-id
> 

I prefer to use hwlock-base-id. I think we should also be defining a
common property name for number of locks, say hwlock-num-locks.

regards
Suman


  reply	other threads:[~2013-09-04 16:27 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-03 17:52 [PATCH 1/2] hwspinlock/omap: add support for dt nodes Suman Anna
2013-09-03 17:52 ` Suman Anna
2013-09-03 18:50 ` Kumar Gala
2013-09-03 18:50   ` Kumar Gala
2013-09-03 19:10   ` Suman Anna
2013-09-03 19:10     ` Suman Anna
2013-09-03 19:37     ` Kumar Gala
2013-09-03 19:37       ` Kumar Gala
2013-09-03 22:34       ` Suman Anna
2013-09-03 22:34         ` Suman Anna
2013-09-04 14:46         ` Kumar Gala
2013-09-04 14:46           ` Kumar Gala
2013-09-04 16:27           ` Suman Anna [this message]
2013-09-04 16:27             ` Suman Anna
2013-09-04 16:42             ` Kumar Gala
2013-09-04 16:42               ` Kumar Gala
2013-09-04 17:03               ` Suman Anna
2013-09-04 17:03                 ` Suman Anna
2013-09-04 17:51                 ` Kumar Gala
2013-09-04 17:51                   ` Kumar Gala
2013-09-04 20:04                   ` Suman Anna
2013-09-04 20:04                     ` Suman Anna
2013-09-04  8:09 ` Stanimir Varbanov
2013-09-04 16:30   ` Suman Anna
2013-09-04 16:30     ` Suman Anna
2013-10-03 18:05 ` Tony Lindgren
     [not found]   ` <20131003180546.GP8949-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
2013-10-03 18:16     ` Suman Anna
2013-10-03 18:16       ` Suman Anna
     [not found]       ` <524DB48B.7020906-l0cyMroinI0@public.gmane.org>
2013-10-03 18:19         ` Tony Lindgren
2013-10-03 18:19           ` Tony Lindgren

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=52275F7D.4030305@ti.com \
    --to=s-anna@ti.com \
    --cc=bcousson@baylibre.com \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=ohad@wizery.com \
    --cc=tony@atomide.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.