From: "James Tai [戴志峰]" <james.tai@realtek.com>
To: "Andreas Färber" <afaerber@suse.de>, "Marc Zyngier" <maz@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>,
"linux-realtek-soc@lists.infradead.org"
<linux-realtek-soc@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Russell King <linux@armlinux.org.uk>,
Olof Johansson <olof@lixom.net>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: RE: [PATCH v3 8/8] ARM: realtek: Enable RTD1195 arch timer
Date: Fri, 20 Mar 2020 16:16:52 +0000 [thread overview]
Message-ID: <bb54e2e716b14ec6bbeb40dafeca56d6@realtek.com> (raw)
In-Reply-To: <4dc05879-f6d9-f754-908e-ad2431d8ff5a@suse.de>
Hi Andreas,
> >>>> What is the name of the register 0xff018000?
> >>>> Is 0x1 a BIT(0) write, or how are the register bits defined?
> >>>> Is this a reset or a clock gate? How should we model it in DT?
>
> No, I was pointing out that I myself had already asked pretty much the same
> questions you just asked me. How did you expect me to have answers to your
> "Shouldn't this be a read/modify/write sequence?" then? It seemed like you
> missed my questions up there:
>
> Without knowing how the register is structured, I can't implement a
> read/modify/write sequence - for that we'd need to know whether it's a single
> bit we can just set or a field that we would need to mask first before writing
> into it.
This register is counter control register of CoreSight timestamp generator. [1][2].
The CPU timer count input signal is inherited from the timestamp generator, so it must be enabled before CPU timer initial.
This register setting can move into boot code.
[1] https://developer.arm.com/docs/100806/0200/9-programmers-model/css600_tsgen/control-interface-register-descriptions
[2] https://developer.arm.com/docs/100806/0200/5-timestamp-components-functional-description/timestamp-generator
Thanks.
Regards,
James
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: "James Tai [戴志峰]" <james.tai@realtek.com>
To: "Andreas Färber" <afaerber@suse.de>, "Marc Zyngier" <maz@kernel.org>
Cc: "linux-realtek-soc@lists.infradead.org"
<linux-realtek-soc@lists.infradead.org>,
Russell King <linux@armlinux.org.uk>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Olof Johansson <olof@lixom.net>, Arnd Bergmann <arnd@arndb.de>
Subject: RE: [PATCH v3 8/8] ARM: realtek: Enable RTD1195 arch timer
Date: Fri, 20 Mar 2020 16:16:52 +0000 [thread overview]
Message-ID: <bb54e2e716b14ec6bbeb40dafeca56d6@realtek.com> (raw)
In-Reply-To: <4dc05879-f6d9-f754-908e-ad2431d8ff5a@suse.de>
Hi Andreas,
> >>>> What is the name of the register 0xff018000?
> >>>> Is 0x1 a BIT(0) write, or how are the register bits defined?
> >>>> Is this a reset or a clock gate? How should we model it in DT?
>
> No, I was pointing out that I myself had already asked pretty much the same
> questions you just asked me. How did you expect me to have answers to your
> "Shouldn't this be a read/modify/write sequence?" then? It seemed like you
> missed my questions up there:
>
> Without knowing how the register is structured, I can't implement a
> read/modify/write sequence - for that we'd need to know whether it's a single
> bit we can just set or a field that we would need to mask first before writing
> into it.
This register is counter control register of CoreSight timestamp generator. [1][2].
The CPU timer count input signal is inherited from the timestamp generator, so it must be enabled before CPU timer initial.
This register setting can move into boot code.
[1] https://developer.arm.com/docs/100806/0200/9-programmers-model/css600_tsgen/control-interface-register-descriptions
[2] https://developer.arm.com/docs/100806/0200/5-timestamp-components-functional-description/timestamp-generator
Thanks.
Regards,
James
next prev parent reply other threads:[~2020-03-20 16:17 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-17 7:21 [PATCH v3 0/8] ARM: Initial RTD1195 and MeLE X1000 support Andreas Färber
2019-11-17 7:21 ` Andreas Färber
2019-11-17 7:21 ` [PATCH v3 1/8] dt-bindings: arm: realtek: Add RTD1195 and MeLE X1000 Andreas Färber
2019-11-17 7:21 ` Andreas Färber
2019-11-17 7:21 ` [PATCH v3 2/8] ARM: Prepare Realtek RTD1195 Andreas Färber
2019-11-17 7:21 ` Andreas Färber
2019-11-17 7:21 ` [PATCH v3 3/8] ARM: dts: Prepare Realtek RTD1195 and MeLE X1000 Andreas Färber
2019-11-17 7:21 ` Andreas Färber
2019-11-17 10:47 ` Marc Zyngier
2019-11-17 10:47 ` Marc Zyngier
2019-11-17 15:40 ` Andreas Färber
2019-11-17 15:40 ` Andreas Färber
2019-11-17 16:22 ` Marc Zyngier
2019-11-17 16:22 ` Marc Zyngier
2019-11-18 1:24 ` Andreas Färber
2019-11-18 1:24 ` Andreas Färber
2019-11-18 9:14 ` Marc Zyngier
2019-11-18 9:14 ` Marc Zyngier
2019-11-17 7:21 ` [PATCH v3 4/8] ARM: dts: rtd1195: Introduce r-bus Andreas Färber
2019-11-17 7:21 ` Andreas Färber
2019-11-17 7:21 ` [PATCH v3 5/8] dt-bindings: reset: Add Realtek RTD1195 Andreas Färber
2019-11-17 7:21 ` Andreas Färber
2019-11-17 7:21 ` [PATCH v3 6/8] ARM: dts: rtd1195: Add reset nodes Andreas Färber
2019-11-17 7:21 ` Andreas Färber
2019-11-18 9:22 ` James Tai
2019-11-18 9:22 ` James Tai
2019-11-19 8:34 ` Andreas Färber
2019-11-19 8:34 ` Andreas Färber
2019-11-20 6:53 ` James Tai
2019-11-20 6:53 ` James Tai
2019-11-17 7:21 ` [PATCH v3 7/8] ARM: dts: rtd1195: Add UART resets Andreas Färber
2019-11-17 7:21 ` Andreas Färber
2019-11-17 7:21 ` [PATCH v3 8/8] ARM: realtek: Enable RTD1195 arch timer Andreas Färber
2019-11-17 7:21 ` Andreas Färber
2019-11-17 11:02 ` Marc Zyngier
2019-11-17 11:02 ` Marc Zyngier
2019-11-17 17:08 ` Andreas Färber
2019-11-17 17:08 ` Andreas Färber
2019-11-18 9:27 ` Marc Zyngier
2019-11-18 9:27 ` Marc Zyngier
2019-11-18 22:48 ` Andreas Färber
2019-11-18 22:48 ` Andreas Färber
2020-03-20 16:16 ` James Tai [戴志峰] [this message]
2020-03-20 16:16 ` James Tai [戴志峰]
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=bb54e2e716b14ec6bbeb40dafeca56d6@realtek.com \
--to=james.tai@realtek.com \
--cc=afaerber@suse.de \
--cc=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-realtek-soc@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=maz@kernel.org \
--cc=olof@lixom.net \
/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.