LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Arun Ramamurthy <arun.ramamurthy@broadcom.com>
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, 17 Dec 2014 15:31:25 +0100 [thread overview]
Message-ID: <1603624.EMYvBCWhuM@wuerfel> (raw)
In-Reply-To: <5490A9FC.6030305@broadcom.com>
On Tuesday 16 December 2014 13:54:04 Arun Ramamurthy wrote:
> On 14-12-16 12:27 PM, Ray Jui wrote:
> > On 12/16/2014 12:19 PM, Arnd Bergmann wrote:
> >>
> >> 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?
>
This is something that's normally up to the platform maintainers, depending
on what works best for a given SoC. If you have a control block that
wants to export the same high-level API for multiple drivers, that's
fine, but if literally every register does something different, a syscon
driver works best.
It's also possible that some of the functions of the CRMU already have
abstractions, like system-reset, device-reset, regulator or clock support.
In that case, you can still use syscon but have the more other drivers
use that for accessing the registers.
Arnd
next prev parent reply other threads:[~2014-12-17 14:32 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
2014-12-17 14:31 ` Arnd Bergmann [this message]
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=1603624.EMYvBCWhuM@wuerfel \
--to=arnd@arndb.de \
--cc=a.zummo@towertech.it \
--cc=arun.ramamurthy@broadcom.com \
--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).