From: arun.ramamurthy@broadcom.com (Arun Ramamurthy)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv1] rtc: bcm-iproc: Add support for Broadcom iproc rtc
Date: Wed, 11 Mar 2015 13:00:22 -0700 [thread overview]
Message-ID: <55009ED6.4050205@broadcom.com> (raw)
In-Reply-To: <2216310.NqXA88JvvL@wuerfel>
On 15-03-04 02:58 PM, Arnd Bergmann wrote:
> On Wednesday 04 March 2015 14:53:40 Arun Ramamurthy wrote:
>> On 15-03-04 02:50 PM, Arnd Bergmann wrote:
>>> On Wednesday 04 March 2015 14:40:13 Arun Ramamurthy wrote:
>>>> On 15-03-04 02:21 PM, Arnd Bergmann wrote:
>>>>> On Thursday 12 February 2015 14:17:41 Arun Ramamurthy wrote:
>>>>>> Hi Arnd
>>>>>>
>>>>>> My apologies for the late reply, I was moved to other work items. I
>>>>>> wanted to get more clarification on the syscon issue so that I can
>>>>>> submit the next patch set. If I understand correctly, you would like
>>>>>> me to move the CRMU logic to a new driver under mfd/ and use the syscon
>>>>>> api calls in my rtc driver? Thanks
>>>>>
>>>>> It depends a lot on what's in there, I can best advise you if you
>>>>> have some form of register list.
>>>>>
>>>>> A common approach would be to not have a driver for the crmu at all,
>>>>> but just mark it as syscon, and have the other drivers either reference
>>>>> the syscon node through a phandle, or create them as childrem of
>>>>> the syscon node. The latter case makes most sense if all uses of
>>>>> the crmu have no other MMIO registers.
>>>>>
>>>>
>>>> Thank you Arnd, I am going to follow the approach of adding a child node
>>>> to the syscon node. Several other driver use other registers in the CRMU
>>>> so I think the child node approach makes the most sense.
>>>
>>> Just to be sure we have the same understanding: of those other drivers,
>>> do you think that they would use only CRMU registers, or could there
>>> be drivers that have both CRMU as well as other MMIO registers?
>>>
>> The other drivers have both CRMU and other MMIO registers. So I thought
>> they could also switch to using the syscon child nodes.
>>
>
> No, in this case, better not use child nodes at all. When other platforms
> use child nodes of a syscon, the common case is that they use the 'reg'
> property to refer to syscon registers, which are in a different address
> space from other MMIO, and you can't easily mix the two.
>
Arnd, this is the device tree entry that I would end up with and I plan
to use syscon_regmap_lookup_by_phandle in the rtc driver. Does this look
acceptable?
rtc: iproc_rtc at 0x03026000 {
compatible = "brcm,iproc-rtc";
reg = <0x03026000 0xC>,
iso_cell_syscon = <&crmu_iso_cell_control>;
bbl_auth_syscon = <&crmu_bbl_auth>
status = "okay";
crmu_iso_cell_control:crmu at 0x0301C02C {
compatible = "syscon";
reg = <0x0301C038 0x8>
}
crmu_bbl_auth:crmu at 0x03024C74 {
compatible = "syscon";
reg = <0x03024C74 0x8>;
}
Thanks
> Arnd
>
WARNING: multiple messages have this Message-ID (diff)
From: Arun Ramamurthy <arun.ramamurthy-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
To: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Cc: Ray Jui <rjui-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
a.zummo-BfzFCNDTiLLj+vYz1yj4TQ@public.gmane.org,
sbranden-dY08KVG/lbpWk0Htik3J/w@public.gmane.org,
pawel.moll-5wv7dgnIgG8@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org,
Arun Ramamurthy
<arunrama-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w@public.gmane.org,
galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
rtc-linux-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
Subject: Re: [PATCHv1] rtc: bcm-iproc: Add support for Broadcom iproc rtc
Date: Wed, 11 Mar 2015 13:00:22 -0700 [thread overview]
Message-ID: <55009ED6.4050205@broadcom.com> (raw)
In-Reply-To: <2216310.NqXA88JvvL@wuerfel>
On 15-03-04 02:58 PM, Arnd Bergmann wrote:
> On Wednesday 04 March 2015 14:53:40 Arun Ramamurthy wrote:
>> On 15-03-04 02:50 PM, Arnd Bergmann wrote:
>>> On Wednesday 04 March 2015 14:40:13 Arun Ramamurthy wrote:
>>>> On 15-03-04 02:21 PM, Arnd Bergmann wrote:
>>>>> On Thursday 12 February 2015 14:17:41 Arun Ramamurthy wrote:
>>>>>> Hi Arnd
>>>>>>
>>>>>> My apologies for the late reply, I was moved to other work items. I
>>>>>> wanted to get more clarification on the syscon issue so that I can
>>>>>> submit the next patch set. If I understand correctly, you would like
>>>>>> me to move the CRMU logic to a new driver under mfd/ and use the syscon
>>>>>> api calls in my rtc driver? Thanks
>>>>>
>>>>> It depends a lot on what's in there, I can best advise you if you
>>>>> have some form of register list.
>>>>>
>>>>> A common approach would be to not have a driver for the crmu at all,
>>>>> but just mark it as syscon, and have the other drivers either reference
>>>>> the syscon node through a phandle, or create them as childrem of
>>>>> the syscon node. The latter case makes most sense if all uses of
>>>>> the crmu have no other MMIO registers.
>>>>>
>>>>
>>>> Thank you Arnd, I am going to follow the approach of adding a child node
>>>> to the syscon node. Several other driver use other registers in the CRMU
>>>> so I think the child node approach makes the most sense.
>>>
>>> Just to be sure we have the same understanding: of those other drivers,
>>> do you think that they would use only CRMU registers, or could there
>>> be drivers that have both CRMU as well as other MMIO registers?
>>>
>> The other drivers have both CRMU and other MMIO registers. So I thought
>> they could also switch to using the syscon child nodes.
>>
>
> No, in this case, better not use child nodes at all. When other platforms
> use child nodes of a syscon, the common case is that they use the 'reg'
> property to refer to syscon registers, which are in a different address
> space from other MMIO, and you can't easily mix the two.
>
Arnd, this is the device tree entry that I would end up with and I plan
to use syscon_regmap_lookup_by_phandle in the rtc driver. Does this look
acceptable?
rtc: iproc_rtc@0x03026000 {
compatible = "brcm,iproc-rtc";
reg = <0x03026000 0xC>,
iso_cell_syscon = <&crmu_iso_cell_control>;
bbl_auth_syscon = <&crmu_bbl_auth>
status = "okay";
crmu_iso_cell_control:crmu@0x0301C02C {
compatible = "syscon";
reg = <0x0301C038 0x8>
}
crmu_bbl_auth:crmu@0x03024C74 {
compatible = "syscon";
reg = <0x03024C74 0x8>;
}
Thanks
> Arnd
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Arun Ramamurthy <arun.ramamurthy@broadcom.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Ray Jui <rjui@broadcom.com>,
<linux-arm-kernel@lists.infradead.org>, <mark.rutland@arm.com>,
<a.zummo@towertech.it>, <sbranden@broadcom.com>,
<pawel.moll@arm.com>, <devicetree@vger.kernel.org>,
<ijc+devicetree@hellion.org.uk>,
Arun Ramamurthy <arunrama@broadcom.com>,
<linux-kernel@vger.kernel.org>, <grant.likely@linaro.org>,
<robh+dt@kernel.org>, <bcm-kernel-feedback-list@broadcom.com>,
<galak@codeaurora.org>, <rtc-linux@googlegroups.com>
Subject: Re: [PATCHv1] rtc: bcm-iproc: Add support for Broadcom iproc rtc
Date: Wed, 11 Mar 2015 13:00:22 -0700 [thread overview]
Message-ID: <55009ED6.4050205@broadcom.com> (raw)
In-Reply-To: <2216310.NqXA88JvvL@wuerfel>
On 15-03-04 02:58 PM, Arnd Bergmann wrote:
> On Wednesday 04 March 2015 14:53:40 Arun Ramamurthy wrote:
>> On 15-03-04 02:50 PM, Arnd Bergmann wrote:
>>> On Wednesday 04 March 2015 14:40:13 Arun Ramamurthy wrote:
>>>> On 15-03-04 02:21 PM, Arnd Bergmann wrote:
>>>>> On Thursday 12 February 2015 14:17:41 Arun Ramamurthy wrote:
>>>>>> Hi Arnd
>>>>>>
>>>>>> My apologies for the late reply, I was moved to other work items. I
>>>>>> wanted to get more clarification on the syscon issue so that I can
>>>>>> submit the next patch set. If I understand correctly, you would like
>>>>>> me to move the CRMU logic to a new driver under mfd/ and use the syscon
>>>>>> api calls in my rtc driver? Thanks
>>>>>
>>>>> It depends a lot on what's in there, I can best advise you if you
>>>>> have some form of register list.
>>>>>
>>>>> A common approach would be to not have a driver for the crmu at all,
>>>>> but just mark it as syscon, and have the other drivers either reference
>>>>> the syscon node through a phandle, or create them as childrem of
>>>>> the syscon node. The latter case makes most sense if all uses of
>>>>> the crmu have no other MMIO registers.
>>>>>
>>>>
>>>> Thank you Arnd, I am going to follow the approach of adding a child node
>>>> to the syscon node. Several other driver use other registers in the CRMU
>>>> so I think the child node approach makes the most sense.
>>>
>>> Just to be sure we have the same understanding: of those other drivers,
>>> do you think that they would use only CRMU registers, or could there
>>> be drivers that have both CRMU as well as other MMIO registers?
>>>
>> The other drivers have both CRMU and other MMIO registers. So I thought
>> they could also switch to using the syscon child nodes.
>>
>
> No, in this case, better not use child nodes at all. When other platforms
> use child nodes of a syscon, the common case is that they use the 'reg'
> property to refer to syscon registers, which are in a different address
> space from other MMIO, and you can't easily mix the two.
>
Arnd, this is the device tree entry that I would end up with and I plan
to use syscon_regmap_lookup_by_phandle in the rtc driver. Does this look
acceptable?
rtc: iproc_rtc@0x03026000 {
compatible = "brcm,iproc-rtc";
reg = <0x03026000 0xC>,
iso_cell_syscon = <&crmu_iso_cell_control>;
bbl_auth_syscon = <&crmu_bbl_auth>
status = "okay";
crmu_iso_cell_control:crmu@0x0301C02C {
compatible = "syscon";
reg = <0x0301C038 0x8>
}
crmu_bbl_auth:crmu@0x03024C74 {
compatible = "syscon";
reg = <0x03024C74 0x8>;
}
Thanks
> Arnd
>
next prev parent reply other threads:[~2015-03-11 20:00 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-16 19:22 [PATCHv1] rtc: bcm-iproc: Add support for Broadcom iproc rtc arun.ramamurthy at broadcom.com
2014-12-16 19:22 ` arun.ramamurthy
2014-12-16 19:22 ` arun.ramamurthy-dY08KVG/lbpWk0Htik3J/w
2014-12-16 19:42 ` Arnd Bergmann
2014-12-16 19:42 ` Arnd Bergmann
2014-12-16 19:42 ` Arnd Bergmann
2014-12-16 20:05 ` Arun Ramamurthy
2014-12-16 20:05 ` Arun Ramamurthy
2014-12-16 20:05 ` Arun Ramamurthy
2014-12-16 20:19 ` Arnd Bergmann
2014-12-16 20:19 ` Arnd Bergmann
2014-12-16 20:19 ` Arnd Bergmann
2014-12-16 20:27 ` Ray Jui
2014-12-16 20:27 ` Ray Jui
2014-12-16 20:27 ` Ray Jui
2014-12-16 21:54 ` Arun Ramamurthy
2014-12-16 21:54 ` Arun Ramamurthy
2014-12-16 21:54 ` Arun Ramamurthy
2014-12-17 14:31 ` Arnd Bergmann
2014-12-17 14:31 ` Arnd Bergmann
2014-12-17 14:31 ` Arnd Bergmann
2015-02-12 22:17 ` Arun Ramamurthy
2015-02-12 22:17 ` Arun Ramamurthy
2015-02-12 22:17 ` Arun Ramamurthy
2015-03-04 22:21 ` Arnd Bergmann
2015-03-04 22:21 ` Arnd Bergmann
2015-03-04 22:40 ` Arun Ramamurthy
2015-03-04 22:40 ` Arun Ramamurthy
2015-03-04 22:40 ` Arun Ramamurthy
2015-03-04 22:50 ` Arnd Bergmann
2015-03-04 22:50 ` Arnd Bergmann
2015-03-04 22:50 ` Arnd Bergmann
2015-03-04 22:53 ` Arun Ramamurthy
2015-03-04 22:53 ` Arun Ramamurthy
2015-03-04 22:53 ` Arun Ramamurthy
2015-03-04 22:58 ` Arnd Bergmann
2015-03-04 22:58 ` Arnd Bergmann
2015-03-11 20:00 ` Arun Ramamurthy [this message]
2015-03-11 20:00 ` Arun Ramamurthy
2015-03-11 20:00 ` Arun Ramamurthy
2015-03-11 20:31 ` Arnd Bergmann
2015-03-11 20:31 ` 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=55009ED6.4050205@broadcom.com \
--to=arun.ramamurthy@broadcom.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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.