LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
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: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-16 19:22 arun.ramamurthy
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=a.zummo@towertech.it \
    --cc=arnd@arndb.de \
    --cc=arunrama@broadcom.com \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=grant.likely@linaro.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=pawel.moll@arm.com \
    --cc=rjui@broadcom.com \
    --cc=robh+dt@kernel.org \
    --cc=rtc-linux@googlegroups.com \
    --cc=sbranden@broadcom.com \
    --subject='Re: [PATCHv1] rtc: bcm-iproc: Add support for Broadcom iproc rtc' \
    /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

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).