Hi Geert,
On 28.04.2016 10:07, Geert Uytterhoeven wrote:
Hi Dirk,
On Thu, Apr 28, 2016 at 8:58 AM, Dirk Behme <dirk.behme@xxxxxxxxxxxx> wrote:
On 28.04.2016 08:52, Geert Uytterhoeven wrote:
On Thu, Apr 28, 2016 at 8:08 AM, Dirk Behme <dirk.behme@xxxxxxxxxxxx> wrote:
@@ -46,7 +48,8 @@ Examples
cpg: clock-controller@e6150000 {
compatible = "renesas,r8a7795-cpg-mssr";
- reg = <0 0xe6150000 0 0x1000>;
+ reg = <0 0xe6150000 0 0x1000>,
+ <0 0xe6160060 0 0x4>;
The MODEMR register is not part of the CPG block, but of the RST block.
So IMHO it doesn't belong in the clock-controller node.
Ok, fine.
So we agree hat this ugly hard coded register address stuff has to be
removed and replaced by a device tree based solution. Correct?
Yes we agree.
BTW, I still prefer something like
"[PATCH 0/6] arm64: renesas: Obtain MD pin values using syscon/regmap"
(http://www.spinics.net/lists/linux-sh/msg44757.html).
What's the status of this? I see there a date "1 Sep 2015" ;)
We were considering alternative solutions, cfr. "[PATCH/RFC 0/6] boot-mode-reg:
Add core" (http://www.spinics.net/lists/linux-sh/msg45969.html).
To avoid delaying upstream r8a7795, we settled for the ugly hard coded
register access as an interim solution.
Is this available in any testing tree we could try?
It used to be part of older renesas-drivers releases.
Would it be possible to add them again then, now?
Best regards
Dirk
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
