From: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
To: Santosh Shilimkar <santosh.shilimkar@ti.com>,
Arnd Bergmann <arnd@arndb.de>
Cc: dbaryshkov@gmail.com, dwmw2@infradead.org,
ijc+devicetree@hellion.org.uk, robh+dt@kernel.org,
pawel.moll@arm.com, mark.rutland@arm.com, galak@codeaurora.org,
grant.likely@linaro.org, rdunlap@infradead.org,
linux@arm.linux.org.uk, grygorii.strashko@ti.com, olof@lixom.net,
w-kwok2@ti.com, sboyd@codeaurora.org, devicetree@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [Patch v3 0/5] Introduce keystone reset driver
Date: Tue, 20 May 2014 21:35:23 +0300 [thread overview]
Message-ID: <537BA06B.5060200@ti.com> (raw)
In-Reply-To: <537B5D5D.8030106@ti.com>
On 05/20/2014 04:49 PM, Santosh Shilimkar wrote:
> On Tuesday 20 May 2014 09:44 AM, Arnd Bergmann wrote:
>> On Tuesday 20 May 2014 16:16:08 Ivan Khoronzhuk wrote:
>>> Thank for the reply
>>>
>>> The reset driver uses two ranges:
>>> - RSTYPE, RSTCTRL,RSTCFG, RSISO (Reset Main PLL Controller)
>>> - RESETMUX8-10 registers
>>>
>>> The content of these register ranges are completely used by the reset
>>> driver.
>>> Currently no one on the SoC can access them instead of the reset driver.
>>> Also we don't use syscon/regmap at all - so adding this will be some
>>> overhead.
>>>
>>> As I posted previously:
>>> "...configuring Reset multiplexer & PLL. And it tunes not only watchdog
>>> usage..."
>>>
>>> Yes, it tunes not only watchdog usage and uses part of registers from
>>> PLL controller,
>>> but all it works with are connected with reset functionality. These
>>> ranges are used only
>>> by reset driver and their purpose is reset functionality.
>>>
>>> Maybe in the future some soft can use ranges in question for own tasks,
>>> but it should be
>>> done via reset driver. So as I see there is no reasons to use regmap for
>>> reset driver.
>> You should not look at these registers in isolation, they are part of
>> some register area that has other functions as well and that you should
>> at least represent correctly in DT.
>>
>> When I see something like
>>
>> + reg = <0x23100e4 0x10>,
>> + <0x2620328 0x10>;
>>
>> I am certain that there are other things between 0x2310000 and 0x23100e3, and
>> probably after 0x23100f4 as well. There must be some data sheet that
>> gives this register range a proper name, so put that into DT rather than
>> making up some arbitrary stuff that happens to match how today's kernel
>> driver needs it.
>>
> Even though there are no other users, I think you have a valid point about
> DT representing the hardware layout in the correct form.
>
> Regards,
> Santosh
>
Thank for the note.
Ok.
Memory map:
[00 02310000 - 00 023101FF] size=512 PLL Controller
[00 02620000 - 00 02620FFF] size=4K device state control registers
I'll define in DT two new syscon compatible nodes like:
pllctrl: pll_controller {
compatible = "syscon";
reg = <0x2310000 0x200>;
};
devctrl: device_state_control {
compatible = "syscon";
reg = <0x2620000 0x1000>;
};
then correct reset-controller node like:
rstctrl: reset-controller {
compatible = "ti,keystone-reset";
reg = <0xE4 0x10>, <0x328 0x10>;
reg-names = "pllregs", "muxregs";
syscon1 = <&pllctrl>;
syscon2 = <&devctrl>;
ti,wdt_list = <0>;
};
And correct reset-controller code to get regmap by phandle,
then access registers by regmap.
Also I'll post two separate patches that add syscon nodes in question.
--
Regards,
Ivan Khoronzhuk
next prev parent reply other threads:[~2014-05-20 18:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-19 10:25 [Patch v3 0/5] Introduce keystone reset driver Ivan Khoronzhuk
2014-05-19 10:25 ` [Patch v3 1/5] Power: reset: keystone-reset: introduce " Ivan Khoronzhuk
2014-05-19 10:25 ` [Patch v3 2/5] Power: reset: add bindings for " Ivan Khoronzhuk
2014-05-19 10:25 ` [Patch v3 3/5] ARM: keystone: remove redundant reset stuff Ivan Khoronzhuk
2014-05-19 10:25 ` [Patch v3 4/5] ARM: dts: keystone: update reset node to work with reset driver Ivan Khoronzhuk
2014-05-19 10:25 ` [Patch v3 5/5] ARM: keystone: enable reset driver support Ivan Khoronzhuk
2014-05-19 15:07 ` [Patch v3 0/5] Introduce keystone reset driver Santosh Shilimkar
2014-05-19 17:47 ` Arnd Bergmann
2014-05-20 13:16 ` Ivan Khoronzhuk
[not found] ` <537B5598.8070603-l0cyMroinI0@public.gmane.org>
2014-05-20 13:44 ` Arnd Bergmann
2014-05-20 13:49 ` Santosh Shilimkar
2014-05-20 18:35 ` Ivan Khoronzhuk [this message]
[not found] ` <537BA06B.5060200-l0cyMroinI0@public.gmane.org>
2014-05-20 19:27 ` Arnd Bergmann
2014-05-21 14:28 ` Ivan Khoronzhuk
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=537BA06B.5060200@ti.com \
--to=ivan.khoronzhuk@ti.com \
--cc=arnd@arndb.de \
--cc=dbaryshkov@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=dwmw2@infradead.org \
--cc=galak@codeaurora.org \
--cc=grant.likely@linaro.org \
--cc=grygorii.strashko@ti.com \
--cc=ijc+devicetree@hellion.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=mark.rutland@arm.com \
--cc=olof@lixom.net \
--cc=pawel.moll@arm.com \
--cc=rdunlap@infradead.org \
--cc=robh+dt@kernel.org \
--cc=santosh.shilimkar@ti.com \
--cc=sboyd@codeaurora.org \
--cc=w-kwok2@ti.com \
/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).