All of lore.kernel.org
 help / color / mirror / Atom feed
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: Tue, 16 Dec 2014 13:54:04 -0800	[thread overview]
Message-ID: <5490A9FC.6030305@broadcom.com> (raw)
In-Reply-To: <549095CA.7090505@broadcom.com>



On 14-12-16 12:27 PM, Ray Jui wrote:
>
>
> 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.
>
Arnd, thanks for the feedback. If I was to write a separate driver for 
the CRMU, I would have to export certain functions and create an api 
that only this RTC driver would use. I am not sure that is efficient or 
required. What is your opinion?
Would it be better if I use the syson api in my current driver and move 
the CRMU registers to separate syscon device tree entry?

>>>> 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.
>>
Sure, I will remove the labels
>>     Arnd
>>

WARNING: multiple messages have this Message-ID (diff)
From: Arun Ramamurthy <arun.ramamurthy-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
To: Ray Jui <rjui-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>,
	Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Cc: 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 13:54:04 -0800	[thread overview]
Message-ID: <5490A9FC.6030305@broadcom.com> (raw)
In-Reply-To: <549095CA.7090505-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>



On 14-12-16 12:27 PM, Ray Jui wrote:
>
>
> 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.
>
Arnd, thanks for the feedback. If I was to write a separate driver for 
the CRMU, I would have to export certain functions and create an api 
that only this RTC driver would use. I am not sure that is efficient or 
required. What is your opinion?
Would it be better if I use the syson api in my current driver and move 
the CRMU registers to separate syscon device tree entry?

>>>> 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.
>>
Sure, I will remove the labels
>>     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: Ray Jui <rjui@broadcom.com>, Arnd Bergmann <arnd@arndb.de>,
	<linux-arm-kernel@lists.infradead.org>
Cc: <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 13:54:04 -0800	[thread overview]
Message-ID: <5490A9FC.6030305@broadcom.com> (raw)
In-Reply-To: <549095CA.7090505@broadcom.com>



On 14-12-16 12:27 PM, Ray Jui wrote:
>
>
> 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.
>
Arnd, thanks for the feedback. If I was to write a separate driver for 
the CRMU, I would have to export certain functions and create an api 
that only this RTC driver would use. I am not sure that is efficient or 
required. What is your opinion?
Would it be better if I use the syson api in my current driver and move 
the CRMU registers to separate syscon device tree entry?

>>>> 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.
>>
Sure, I will remove the labels
>>     Arnd
>>

  reply	other threads:[~2014-12-16 21:54 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 [this message]
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=5490A9FC.6030305@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.