From: rjui@broadcom.com (Ray Jui)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv1] rtc: bcm-iproc: Add support for Broadcom iproc rtc
Date: Tue, 16 Dec 2014 12:27:54 -0800 [thread overview]
Message-ID: <549095CA.7090505@broadcom.com> (raw)
In-Reply-To: <1418783023.hzNZBNCmFc@wuerfel>
On 12/16/2014 12:19 PM, Arnd Bergmann wrote:
> On Tuesday 16 December 2014 12:05:08 Arun Ramamurthy wrote:
>> On 14-12-16 11:42 AM, Arnd Bergmann wrote:
>>> On Tuesday 16 December 2014 11:22:30 arun.ramamurthy at broadcom.com wrote:
>>>> + rtc: iproc_rtc at 0x03026000 {
>>>> + compatible = "brcm,iproc-rtc";
>>>> + reg = spru_bbl: <0x03026000 0xC>,
>>>> + crmu_pwr_good_status: <0x0301C02C 0x14>,
>>>> + crmu_bbl_auth: <0x03024C74 0x8>;
>>>> + interrupts = spru_rtc_periodic: <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
>>>> + spru_alarm: <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>;
>>>
>>> The reg properties look really random, could it be that the registers
>>> are really part of some other device that contains multiple functions?
>>>
>> This RTC block is on a battery backed logic island and is accessed
>> indirectly using the spru_bbl registers. The CRMU registers are required
>> to read the power status and write to some authentication registers.
>> Without writing to these authentication
>> registers, we cannot access any of the spru_bbl registers. In conclusion
>> I don't think the CRMU register accesses can be considered as another
>> device access. Do you agree Arnd?
>
> It sounds like CRMU is some other unit aside from the RTC. Could this
> be something like a generic system controller? I think it should
> either have its own driver or use the syscon logic if that is what
> this is.
>
Giving that CRMU has scattered, miscellaneous control logic for multiple
different peripherals, it probably makes more sense to use the syscon
logic here.
>>> Also, what do you use the labels for?
>>>
>> The labels are purely to improve readability of the device tree entry
>
> Please remove them then, they don't help at all.
>
> Arnd
>
WARNING: multiple messages have this Message-ID (diff)
From: Ray Jui <rjui-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
To: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Cc: Arun Ramamurthy
<arun.ramamurthy-dY08KVG/lbpWk0Htik3J/w@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: Tue, 16 Dec 2014 12:27:54 -0800 [thread overview]
Message-ID: <549095CA.7090505@broadcom.com> (raw)
In-Reply-To: <1418783023.hzNZBNCmFc@wuerfel>
On 12/16/2014 12:19 PM, Arnd Bergmann wrote:
> On Tuesday 16 December 2014 12:05:08 Arun Ramamurthy wrote:
>> On 14-12-16 11:42 AM, Arnd Bergmann wrote:
>>> On Tuesday 16 December 2014 11:22:30 arun.ramamurthy-dY08KVG/lbpWk0Htik3J/w@public.gmane.org wrote:
>>>> + rtc: iproc_rtc@0x03026000 {
>>>> + compatible = "brcm,iproc-rtc";
>>>> + reg = spru_bbl: <0x03026000 0xC>,
>>>> + crmu_pwr_good_status: <0x0301C02C 0x14>,
>>>> + crmu_bbl_auth: <0x03024C74 0x8>;
>>>> + interrupts = spru_rtc_periodic: <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
>>>> + spru_alarm: <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>;
>>>
>>> The reg properties look really random, could it be that the registers
>>> are really part of some other device that contains multiple functions?
>>>
>> This RTC block is on a battery backed logic island and is accessed
>> indirectly using the spru_bbl registers. The CRMU registers are required
>> to read the power status and write to some authentication registers.
>> Without writing to these authentication
>> registers, we cannot access any of the spru_bbl registers. In conclusion
>> I don't think the CRMU register accesses can be considered as another
>> device access. Do you agree Arnd?
>
> It sounds like CRMU is some other unit aside from the RTC. Could this
> be something like a generic system controller? I think it should
> either have its own driver or use the syscon logic if that is what
> this is.
>
Giving that CRMU has scattered, miscellaneous control logic for multiple
different peripherals, it probably makes more sense to use the syscon
logic here.
>>> Also, what do you use the labels for?
>>>
>> The labels are purely to improve readability of the device tree entry
>
> Please remove them then, they don't help at all.
>
> 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: Ray Jui <rjui@broadcom.com>
To: Arnd Bergmann <arnd@arndb.de>, <linux-arm-kernel@lists.infradead.org>
Cc: Arun Ramamurthy <arun.ramamurthy@broadcom.com>,
<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: Tue, 16 Dec 2014 12:27:54 -0800 [thread overview]
Message-ID: <549095CA.7090505@broadcom.com> (raw)
In-Reply-To: <1418783023.hzNZBNCmFc@wuerfel>
On 12/16/2014 12:19 PM, Arnd Bergmann wrote:
> On Tuesday 16 December 2014 12:05:08 Arun Ramamurthy wrote:
>> On 14-12-16 11:42 AM, Arnd Bergmann wrote:
>>> On Tuesday 16 December 2014 11:22:30 arun.ramamurthy@broadcom.com wrote:
>>>> + rtc: iproc_rtc@0x03026000 {
>>>> + compatible = "brcm,iproc-rtc";
>>>> + reg = spru_bbl: <0x03026000 0xC>,
>>>> + crmu_pwr_good_status: <0x0301C02C 0x14>,
>>>> + crmu_bbl_auth: <0x03024C74 0x8>;
>>>> + interrupts = spru_rtc_periodic: <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
>>>> + spru_alarm: <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>;
>>>
>>> The reg properties look really random, could it be that the registers
>>> are really part of some other device that contains multiple functions?
>>>
>> This RTC block is on a battery backed logic island and is accessed
>> indirectly using the spru_bbl registers. The CRMU registers are required
>> to read the power status and write to some authentication registers.
>> Without writing to these authentication
>> registers, we cannot access any of the spru_bbl registers. In conclusion
>> I don't think the CRMU register accesses can be considered as another
>> device access. Do you agree Arnd?
>
> It sounds like CRMU is some other unit aside from the RTC. Could this
> be something like a generic system controller? I think it should
> either have its own driver or use the syscon logic if that is what
> this is.
>
Giving that CRMU has scattered, miscellaneous control logic for multiple
different peripherals, it probably makes more sense to use the syscon
logic here.
>>> Also, what do you use the labels for?
>>>
>> The labels are purely to improve readability of the device tree entry
>
> Please remove them then, they don't help at all.
>
> Arnd
>
next prev parent reply other threads:[~2014-12-16 20:27 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 [this message]
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
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=549095CA.7090505@broadcom.com \
--to=rjui@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.