linux-arm-kernel.lists.infradead.org archive mirror
 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
>>

  reply	other threads:[~2014-12-16 21:54 UTC|newest]

Thread overview: 15+ 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:42 ` Arnd Bergmann
2014-12-16 20:05   ` Arun Ramamurthy
2014-12-16 20:19     ` Arnd Bergmann
2014-12-16 20:27       ` Ray Jui
2014-12-16 21:54         ` Arun Ramamurthy [this message]
2014-12-17 14:31           ` Arnd Bergmann
2015-02-12 22:17             ` Arun Ramamurthy
2015-03-04 22:21               ` Arnd Bergmann
2015-03-04 22:40                 ` Arun Ramamurthy
2015-03-04 22:50                   ` Arnd Bergmann
2015-03-04 22:53                     ` Arun Ramamurthy
2015-03-04 22:58                       ` Arnd Bergmann
2015-03-11 20:00                         ` Arun Ramamurthy
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).