Re: [PATCH] usb: host: xhci-plat: add firmware for the R-Car M3 xHCI controllers
Hi Shimoda-san,
On Tue, Apr 12, 2016 at 8:42 AM, Yoshihiro Shimoda
wrote:
> This patch adds a firmware for the USB 3.0 host controllers of Renesas
> R-Car M3 SoC.
I guess you mean "R-Car M3-W"?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH] usb: host: xhci-plat: add firmware for the R-Car M3 xHCI controllers
This patch adds a firmware for the USB 3.0 host controllers of Renesas
R-Car M3 SoC.
- This firmware is possible to be used on R-Car H2 and M2. However,
this version causes performance degradation on such SoCs.
- This firmware is impossible to be used on R-Car H3 because data
transfer might not work correctly.
So, we would like to keep the v1 and v2 firmware.
Signed-off-by: Yoshihiro Shimoda
---
WHENCE| 3 ++-
r8a779x_usb3_v3.dlmem | Bin 0 -> 9472 bytes
2 files changed, 2 insertions(+), 1 deletion(-)
create mode 100644 r8a779x_usb3_v3.dlmem
diff --git a/WHENCE b/WHENCE
index c2d83f4..02b46c7 100644
--- a/WHENCE
+++ b/WHENCE
@@ -2922,10 +2922,11 @@ Licence:
--
-Driver: xhci-rcar -- Renesas R-Car H2/M2/H3 USB 3.0 host controller driver
+Driver: xhci-rcar -- Renesas R-Car Gen2/3 USB 3.0 host controller driver
File: r8a779x_usb3_v1.dlmem
File: r8a779x_usb3_v2.dlmem
+File: r8a779x_usb3_v3.dlmem
Licence: Redistributable. See LICENCE.r8a779x_usb3 for details.
diff --git a/r8a779x_usb3_v3.dlmem b/r8a779x_usb3_v3.dlmem
new file mode 100644
index
..eac36a96bee1a8614eef9caa88e5a9de136af30c
GIT binary patch
literal 9472
zcmai44O~=J+J9z-JD0DE%!QeY2nRwwB{K
zD4Ci1rfYs>HkeYmO5m31jV34~)&K>O6o(P~7+pbD-BR(s|8ob#ecSi9{C@v?&b{~C
z=R9BMInQ~9;u*j3Mp7NIzY7#;Wi4;XjLuOsWLNsr{b*C7mr~CYucqgTozEhh{^R~y
z;vS+T2HOp?$LiOfB6?v)tUmHIQGg^i{2qOuk!V3ieSzE5L0Y{>@tLiXt@SPOBxf;E
zcrN-@$=L9oxZiARx2;Ij7m}7V@vjlZ%gTD4C)LZbUMqSBIZC^3^pDz$QG`+K+il|K
zoUE)CDx}B;>vpN(*eD`dshO-vOVTf;lBi+&&3%Xx^|@h0OUc1_f4i^UdWA?Am#Du6
zN-vUarO`e}U&H23NYn>vw6vJa9UQ0O#=ag%y4R9SWH%TEW028$gSvva0iw=m`=i-@
z|0oUh7jq>;W}k{QXrMIFP-14!wKIal-C~6yJ8`HKY|@aldci7j(9}uJ-_~}8Ol5ox(>FZatD9fi
zHHEJcG-8TWD>&P0g)CnS=N58&wL+&*X0$643HCADmA#SI1-oL>RN|VTE#vIUe4Sl6
z5LwA-U^}hkOso~U#&n*J(UYOLSUZM2Z8Tl4XB@COWn~lWTcwV^g1dx%va;gtlT+}<
z(E)a4XTX5?FO@@gWM$#qcjeHR(BKd+8fE2ZGHla8MoYSKb+SQYWRfyJvu@Wk99u~k
z`FTUG)Db8vv3I|>li#0iYyDm)D`9uvJ-;UP#
zebKXWzJ^Kmicyo6l2If0rE7^}d{Et6;vR6sc&$}!P$0f9ShrKdF^PF=aEe{=QvLI?
z5WqTP01yCir>9m)ZtKZwustPX^?o?;pR1)71GTUI$yVc}{Yk
z+JjgbP5o`{`yGk;X7I^Y412d{gs0Xwf@x%#__NI^{Ugw0IB3)OZ18h!a|P8K&2cNh
z*RDobScrv}KYU(;H53z|r6sU>6<4wHvxXvJypMUAHf@=R`O|zCPqZ;_`8lxS?a&5K
zZ4+jnZLuqEU6NjjQ@u-F;|oEBt#MiT9i(eE_V|GdewHO3G&-eOtsX0=#eU({OA6Q3_wH`g4JJk*j#1q`|JNr}_!D_Rk?@g*wuc>c-stql(62J+(p?
z0*fNe5w`ZPFy?|fhWU2UQ1-r1jUZEFSY&!b?N3qrtJHpjRaSmdW!A(WR-U}WzE}o|
zer}uKUw*DC-U|gMgVgojD{DIE_YPUfhOCQBOjb1pwfBWwFX62&?zL`Da@-xe+9WHb
zCKg?6?PexF-Y|VxC4YQrfgKqa%bk>S(_XRz+co-blCjQtIV>JKOxv7E8~XQ+FL*)M$h=LwO>X5
zA+;|nuf}^?I-%|42`om-%C#Y|_B}Gr#JFA=^Ki#(50CaCHgOd^`QW1_wsvP4lhVT}
z*f0y4ik5n%-_$+pCk2UmS9hOjucVu@tUP(o=x@{!J#lz|2+El}B6kSlH~L+i5pnbe
zUF3{BYa2MD-slk52?G$vxdyfi`u}Y08q5*N`z2=k!(~KxE%t}O-OmQ%{cyGK_uzqa
zSgF2cG1c(a8=v*DN7~aBW!ZGc^yQHjQ$Moahzi^n5sHSk^#G*h|dt#6Fh{lUgiyOQABldGC{67$R18wk1cvYsY*SasObFpzr>7<)%
zaD$gY(YWt&h%Mdgd|lTDq4$g3>KDwyy(>xX=1f**4)Ub3$kRMXR-zv0{i^xyS9X3N
z)>7Dmp41YIJ09Dk6Tp)wP0rRn1{SPVrNByD%wmzgBX_1QqH*@t*^T16;z4LtV~4imCL8K(tY0N=7PV8|
zX%(rl8F-UN_9>|jbBMk}sl{$~DFgfLyb-OBV=vH-_L@Qw0iGzRFnE9aU7wWrME&Ss
zrm=2K(Ia|_DK56&aMAn=P94h`9LO2g2_-^3BKqd!dSnU1sR-AX={od(F1eD^B04vP
zITMShYfK&2Zw$LX5ayKj5Tes*7EhQIuJ$5g^wt}5RH{XwXL^)fD;{N(!crqL51|)TniM8YAf9d#TzGnW%z7r{4EEGAG8`P*k#{IqpC8h*;z#CW3Z_uHkHRP%
zSCJxdH6a^)B}L|AC&>Ip-~bRaQRb6@?Gw3pnV%{w?WXX(O2G^o;h`*BAD8*ODKa1V1ZDx6fOnph`RM0zZ6S5Jm=K!-+r(UPvvB&K
zdh&AH&hw~hdK}*fzd!lyqf0G8g+{d&vVw=uW>#%uRngp|C
zM2whz>9n|A{91Hh9UyA3?-dz)Mw&B1s49H`jZgDQ0!Z1A(J@x
z@^NmW8g~Y&UX+EswbPg@uCsL-^TcIludo5DApsdc->yn=gP1J3O*%@EBBcVXhIkEI
z2bOs(KJ3!4bwF8_TrfQTV6Z6>Fyi~U9;#Y2fP`6V<{VFZH|_0dp~%3p(#~?vrn$LbaN*+|
z@ak{J^`Uysnz-Lrov<}Q7l-^dfKxR;3HcF=o&Roam(G>>>UoF+^Fy$9DnkDmlfule|w#?548nZ(|!N>b4WZ^_uB4mqht{xF2DHkzkfq?f__q_LV+1(Ll
z(gK;+=gIt{yfBQ}#oPIoaCYLa^i^DZjeo=O8vhos4%h&^3v2`4cj!GUiEqRn`J7oQ
zaNIY#Uz|V6RAGf>=9l5RCLjJ34tk6E#w`?Bvzda9=sjDhA851a<-TZ+qXf%D3%oL3
z-!JaI(a}kLCt-ie?-$3SmjB*Qbrsvu7P0u%cT#i`n~lvA^FkZ0=`XO^GGD-K$W3~=
z@8PijV#eXvD^3TS!%xqLm=L{~(d(g=znIZFx|q?T7yX=P5z|BkxOH*vi-RSO_?d5#
zcB(e6CT&w%@Hh>vq_y!`vv&^7ne8^`&MqF&gh-nO&E|*>VS%_48A>3$A-dqYjkUK6
z%G9=b#dR~gcdaZl`@bmR7Kluu`GrN0bYbCj;a{IWQ^>emQ^>e0E$pcRu^i@J4!>;=
zKwM>Xs@0LNzwufIr{+c&
zP(AzWY2EnZ4fIU$)q=^$uvzx6mjd7m%w{aAWhLyN;U1ckP&?LZ%uQ%|B1>%Hyh0AH
z4xw!Vsxz)iT=QKUaDB3<4H;nYuClTBjw%}=E9D<-z%|CzHWd1HmEpRvs9@;5qY7-Y
zlKVj$^1sFp%5ZhM3UEy-syE&{itT^a56W=e`#}M&ajtp}`#@0fv{zO@bpr?P(Q3>iy8-(#*MhSFKz4ErK
zZ1e9>$ru@h(_u7fi%JJu+iG^xL5Mf8dJVF*9Q3{y-xMbslF~)&Pd-5_PLxn{`8R*8nr*#d
z73?~T=@c!C(29ntz~QfPAyyex9gmVEkRxWEIrSkrL*|i
zq;cVSclQ2A|MMg~cWazdOOVGUr+&>UmzVGUb+^UP4sQ39t|`&OcYn^H%Boa+Zfp
zHf+X;b08`OsC{m{zo8B_yxw;^pVF}!P5Ch6RO4hr$qYZmHK5qT;TlvJe#xH?`Odam
zZha`-yl&n2hg)@jA*y&gw_Kg!J;EBP#jbi2zaMB4C|NsMRxS_IVwZ0TvPxOy4)HtG
zBwB*XP-&;~*<)vp2v0t&9O|-~ZU?fg)?zA0z1?CW3um-RpDeSEJQT$8Ti$qB*?x19
zTDkUH#$)huxyY;*U=P^lH)z`
z0#)DOU%{Ich0-23WMijG+89
Re: [PATCH/RFC 1/9] clk: shmobile: r8a7795: Add FCP clocks
Hi Laurent > > > The parent clock isn't documented in the datasheet, use S2D1 as a best > > > guess for now. > > > > Would you be able to find out what the parent clock is for the FCP and LVDS > > (patch 2/9) clocks ? > > Thanks ! > I asked it to HW team It is too late information for you LVDS (APB) is using S0D4 (200MHz)
Re: [GIT PULL] Renesas ARM Based SoC Fixes for v4.6
On Mon, Apr 11, 2016 at 09:11:19AM +0200, Geert Uytterhoeven wrote: > Hi Simon, > > On Mon, Apr 11, 2016 at 3:52 AM, Simon Horman > wrote: > > Hi Olof, Hi Kevin, Hi Arnd, > > > > Please consider these Renesas ARM based SoC fixes for v4.6. > > > > > > Allow serial to work once again on the Porter board (Revision B) which > > does not have the oscillator in question mounted. > > Have you tested this on Porter? I don't have working access to a porter at this time. > I believe there's another change to be made for this revert to actually work, > cfr. "[PATCH] ARM: dts: r8a7791: Don't disable referenced optional clocks" > (https://lkml.org/lkml/2016/4/6/350) Ok, understood. Could someone verify that?
Re: Boot failure on Lager with CONFIG_DEBUG_RODATA
On Mon, Apr 11, 2016 at 7:04 PM, Laurent Pinchart wrote: > The subject says it all. When CONFIG_DEBUG_RODATA is enabled the kernel fails > to handle the DTB. > > I've debugged it to the point where setup_machine_fdt() is called with > __atags_pointer == 0 and then had to move on to the other work. > > Is this a known issue ? Yep, -EKERNELTOOBIG. With that option enabled, there are too many . = ALIGN(1<
Re: [PATCH/RFC v2] gpio: rcar: Add Runtime PM handling for interrupts
Hi Marc,
On Mon, Apr 11, 2016 at 6:55 PM, Marc Zyngier wrote:
> On 11/04/16 17:26, Laurent Pinchart wrote:
>> On Friday 19 Feb 2016 11:59:40 Marc Zyngier wrote:
>>> On 19/02/16 09:18, Linus Walleij wrote:
Top-quoting so everyone on the new To:-line gets the context.
I definately need an indication from an irqchip maintainer like tglx or
Marc Z before I merge this. Also, as in reply to the previous letter,
coordinate efforts with Jon Hunters similar problem space.
>>>
>>> Seems pretty straightforward to me.
>>>
>>> Acked-by: Marc Zyngier
>>
>> Too straightforward to be correct :-/
>>
>> [6.232681] BUG: sleeping function called from invalid context at
>> /home/laurent/src/iob/renesas/linux/drivers/base/power/runtime.c:955
>> [6.244795] in_atomic(): 1, irqs_disabled(): 128, pid: 658, name: udevd
>> [6.251429] CPU: 3 PID: 658 Comm: udevd Tainted: P
>> 4.6.0-rc3 #756
>> [6.258844] Hardware name: Generic R8A7790 (Flattened Device Tree)
>
> [...]
>
> Ah! That will teach me a lesson.
>
>> The .irq_request_resources() handler is called with a spinlock held, it thus
>> can't call the synchronous version of the PM runtime functions.
>
> OK, so we're back to square one. Is that just a matter of calling the
> non-synchronous version? My hunch is that it is not that simple...
>
> Geert?
Unfortunately it's not that simple.
The irqchip must be runtime-resumed before we can access its registers.
I'm afraid we'll have to keep gpio-rcar runtime-resumed all the time,
i.e. revert both of
b26a719bdb ("gpio: rcar: Add Runtime PM handling for interrupts")
65194cb174 ("gpio: rcar: Fine-grained Runtime PM support")
until Jon Hunter's "genirq: Add runtime power management support for IRQ chips"
(and perhaps a few more patches from his series) is applied.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] sh_eth: re-enable-E-MAC interrupts in sh_eth_set_ringparam()
Hello. On 04/10/2016 04:27 AM, David Miller wrote: The E-MAC interrupts are left disabled when the ring parameters are changed via 'ethtool'. In order to fix this, it's enough to call sh_eth_dev_init() with 'true' instead of 'false' for the second argument (which conveniently allows us to remove the following code re-enabling E-DMAC interrupts and reception). Signed-off-by: Sergei Shtylyov Applied, thanks. Thanks! Unfortunately, this patch isn't fit for the stable kernels because there's a prerequisite cleanup (most recent patch merged to this driver). I clearly hadn't thought this out well -- should have enabled the E-MAC interrupts outside sh_eth_dev_init() and then removed the duplicate code like I did here. MBR, Sergei
Boot failure on Lager with CONFIG_DEBUG_RODATA
Hello, The subject says it all. When CONFIG_DEBUG_RODATA is enabled the kernel fails to handle the DTB. I've debugged it to the point where setup_machine_fdt() is called with __atags_pointer == 0 and then had to move on to the other work. Is this a known issue ? -- Regards, Laurent Pinchart
Re: [PATCH/RFC v2] gpio: rcar: Add Runtime PM handling for interrupts
On 11/04/16 17:26, Laurent Pinchart wrote: > On Friday 19 Feb 2016 11:59:40 Marc Zyngier wrote: >> On 19/02/16 09:18, Linus Walleij wrote: >>> Top-quoting so everyone on the new To:-line gets the context. >>> >>> I definately need an indication from an irqchip maintainer like tglx or >>> Marc Z before I merge this. Also, as in reply to the previous letter, >>> coordinate efforts with Jon Hunters similar problem space. >> >> Seems pretty straightforward to me. >> >> Acked-by: Marc Zyngier > > Too straightforward to be correct :-/ > > [6.232681] BUG: sleeping function called from invalid context at > /home/laurent/src/iob/renesas/linux/drivers/base/power/runtime.c:955 > [6.244795] in_atomic(): 1, irqs_disabled(): 128, pid: 658, name: udevd > [6.251429] CPU: 3 PID: 658 Comm: udevd Tainted: P > 4.6.0-rc3 #756 > [6.258844] Hardware name: Generic R8A7790 (Flattened Device Tree) [...] Ah! That will teach me a lesson. > The .irq_request_resources() handler is called with a spinlock held, it thus > can't call the synchronous version of the PM runtime functions. OK, so we're back to square one. Is that just a matter of calling the non-synchronous version? My hunch is that it is not that simple... Geert? M. -- Jazz is not dead. It just smells funny...
Re: [PATCH/RFC v2] gpio: rcar: Add Runtime PM handling for interrupts
On Friday 19 Feb 2016 11:59:40 Marc Zyngier wrote: > On 19/02/16 09:18, Linus Walleij wrote: > > Top-quoting so everyone on the new To:-line gets the context. > > > > I definately need an indication from an irqchip maintainer like tglx or > > Marc Z before I merge this. Also, as in reply to the previous letter, > > coordinate efforts with Jon Hunters similar problem space. > > Seems pretty straightforward to me. > > Acked-by: Marc Zyngier Too straightforward to be correct :-/ [6.232681] BUG: sleeping function called from invalid context at /home/laurent/src/iob/renesas/linux/drivers/base/power/runtime.c:955 [6.244795] in_atomic(): 1, irqs_disabled(): 128, pid: 658, name: udevd [6.251429] CPU: 3 PID: 658 Comm: udevd Tainted: P4.6.0-rc3 #756 [6.258844] Hardware name: Generic R8A7790 (Flattened Device Tree) [6.265036] Backtrace: [6.267535] [] (dump_backtrace) from [] (show_stack+0x20/0x24) [6.275124] r6: r5: r4:6093 r3: [6.280850] [] (show_stack) from [] (dump_stack+0x8c/0xac) [6.288105] [] (dump_stack) from [] (___might_sleep+0x100/0x158) [6.295863] r5:03bb r4:c06ca340 [6.299474] [] (___might_sleep) from [] (__might_sleep+0x6c/0xa8) [6.307317] r4:c05b6a24 [6.309880] [] (__might_sleep) from [] (__pm_runtime_resume+0x98/0xa0) [6.318159] r6:00dc r5:0004 r4:ea280010 [6.322831] [] (__pm_runtime_resume) from [] (gpio_rcar_irq_request_resources+0x2c/0x34) [6.332674] r7: r6:00dc r5:e95b3c00 r4:e99f3c00 [6.338397] [] (gpio_rcar_irq_request_resources) from [] (__setup_irq+0x24c/0x5dc) [6.347724] [] (__setup_irq) from [] (request_threaded_irq+0xdc/0x180) [6.356004] r10:bf0aabc8 r9:00dc r8:e9bc3000 r7:c0075be8 r6:e99f3c00 r5:2003 [6.363905] r4:e95b3c00 [6.366466] [] (request_threaded_irq) from [] (devm_request_threaded_irq+0x6c/0xac) [6.375874] r10:ea2db810 r9:ea2db810 r8: r7:bf0aabc8 r6:00dc r5:e9bc3000 [6.383773] r4:e95b3b50 r3:2003 [6.387410] [] (devm_request_threaded_irq) from [] (mmc_gpiod_request_cd_irq+0xa4/0xd0 [mmc_core]) [6.398121] r10:ea2db800 r8:e9bc3000 r7:e9bed598 r6:00dc r5:e9bed524 r4:e9bc3000 [6.406065] [] (mmc_gpiod_request_cd_irq [mmc_core]) from [] (mmc_start_host+0x70/0x90 [mmc_core]) [6.416779] r6:e9bc3300 r5: r4:e9bc3000 [6.421476] [] (mmc_start_host [mmc_core]) from [] (mmc_add_host+0x54/0x78 [mmc_core]) [6.431146] r4:e9bc3000 r3:0001 [6.434782] [] (mmc_add_host [mmc_core]) from [] (tmio_mmc_host_probe+0x3ac/0x450 [tmio_mmc_core]) [6.445498] r5:ffe0 r4: [6.449119] [] (tmio_mmc_host_probe [tmio_mmc_core]) from [] (sh_mobile_sdhi_probe+0x198/0x414 [sh_mobile_sdhi]) [6.461051] r10:bf150d04 r9:e9bed598 r8:0001 r7:ea2db810 r6:ea2db800 r5:e9bc3300 [6.468958] r4:e9bed590 [6.471532] [] (sh_mobile_sdhi_probe [sh_mobile_sdhi]) from [] (platform_drv_probe+0x60/0xc0) [6.481811] r10:0011 r9: r8:bf151464 r7:bf151464 r6:fdfb r5:ea2db810 [6.489712] r4: [6.492271] [] (platform_drv_probe) from [] (driver_probe_device+0x224/0x440) [6.501156] r7:c06c45f8 r6:c08e2b44 r5:c08e2b3c r4:ea2db810 [6.506878] [] (driver_probe_device) from [] (__driver_attach+0x104/0x128) [6.515508] r10: r9:bf1514c0 r8:c06c4520 r7: r6:bf151464 r5:ea2db810 [6.523411] r4:ea2db844 [6.525965] [] (__driver_attach) from [] (bus_for_each_dev+0x64/0x98) [6.534156] r6:c02cd19c r5:bf151464 r4: r3: [6.539874] [] (bus_for_each_dev) from [] (driver_attach+0x2c/0x30) [6.547895] r6:c06ace08 r5:ea294c80 r4:bf151464 [6.552561] [] (driver_attach) from [] (bus_add_driver+0x18c/0x268) [6.560586] [] (bus_add_driver) from [] (driver_register+0x88/0x104) [6.568691] r8:bf153000 r7:0001 r6:e9ba7a40 r5:c067cfc8 r4:bf151464 [6.575464] [] (driver_register) from [] (__platform_driver_register+0x50/0x54) [6.584523] r5:c067cfc8 r4:c067cfc8 [6.588141] [] (__platform_driver_register) from [] (sh_mobile_sdhi_driver_init+0x18/0x24 [sh_mobile_sdhi]) [6.599654] [] (sh_mobile_sdhi_driver_init [sh_mobile_sdhi]) from [] (do_one_initcall+0xc0/0x200) [6.610292] [] (do_one_initcall) from [] (do_init_module+0x70/0x1dc) [6.618398] r10:05fa r9:bf1514c0 r8:c00a1f28 r7:0001 r6:e94f3fc0 r5:0001 [6.626299] r4:bf1514c0 [6.628860] [] (do_init_module) from [] (load_module+0x19c8/0x2164) [6.636878] r7:0001 r6:e955ec00 r5:0001 r4:e9b73f3c [6.642603] [] (load_module) from [] (SyS_finit_module+0xb0/0xe0) [6.650447] r10: r9:e9b72000 r8:b6f75330 r7:0009 r6: r5: [6.658342] r4:7fff [6.660901] [] (SyS_finit_module) from [] (ret_fast_syscall+0x0/0x34) [6.669093] r8:c0011ae4 r7:017b r6: r5: r4:0002 The .irq_request_resources() ha
Re: [PATCH v4 03/11] soc: renesas: rcar-sysc: Add DT support for SYSC PM domains
Hi Laurent,
Thanks for your comments!
On Sat, Apr 9, 2016 at 9:50 PM, Laurent Pinchart
wrote:
> On Thursday 07 Apr 2016 14:20:20 Geert Uytterhoeven wrote:
>> Populate the SYSC PM domains from DT, based on the presence of a device
>> node for the System Controller. The actual power area hiearchy, and
>> features of specific areas are obtained from tables in the C code.
>>
>> The SYSCIER and SYSCIMR register values are derived from the power areas
>> present, which will help to get rid of the hardcoded values in R-Car H1
>> and R-Car Gen2 platform code later.
>>
>> Initialization is done in two phases:
>> 1. SYSC initialization and setup of power areas containing CPUs or
>> SCUs is done from an early_initcall(), to make sure these PM
>> Domains are initialized before secondary CPU bringup,
>> 2. Setup of the always-on power area (which is basically an alias for
>> the CPG/MSSR or CPG/MSTP Clock Domain), and of I/O power areas is
>> done from builtin_platform_driver_probe(), when the Clock Domain is
>> available.
>> --- a/drivers/soc/renesas/rcar-sysc.c
>> +++ b/drivers/soc/renesas/rcar-sysc.c
>> +/*
>> + * Initialization phase 1, including setup of CPU and SCU domains
>> + */
>> +static int __init rcar_sysc_early(void)
>> +{
>> + const struct rcar_sysc_info *info;
>> + const struct of_device_id *match;
>> + struct rcar_pm_domains *domains;
>> + struct device_node *np;
>> + u32 syscier, syscimr;
>> + void __iomem *base;
>> + unsigned int i;
>> + int error;
>> +
>> + np = of_find_matching_node_and_match(NULL, rcar_sysc_matches, &match);
>> + if (!np)
>> + return -ENODEV;
>> +
>> + info = match->data;
>> +
>> + base = of_iomap(np, 0);
>> + if (!base) {
>> + pr_warn("%s: Cannot map regs\n", np->full_name);
>> + error = -ENOMEM;
>> + goto out_put;
>> + }
>> +
>> + rcar_sysc_base = base;
>> +
>> + domains = kzalloc(sizeof(*domains), GFP_KERNEL);
>> + if (!domains) {
>> + error = -ENOMEM;
>> + goto out_put;
>
> You might want to iounmap() when cleaning up.
That's a bit tricky. The R-Car H1 and H2 platform code may still call
rcar_sysc_power_*() if initialization fails here, which relies on
rcar_sysc_base pointing to the mapped registers.
So until that code is cleaned up (I have local patches), I would like to keep
it this way.
>> + /*
>> + * Mask all interrupt sources to prevent the CPU from receiving them.
>> + * Make sure not to clear reserved bits that were set before.
>> + */
>> + syscimr = ioread32(base + SYSCIMR);
>> + syscimr |= syscier;
>> + pr_debug("%s: syscimr = 0x%08x\n", np->full_name, syscimr);
>> + iowrite32(syscimr, base + SYSCIMR);
>
> Should you mask the interrupt sources before enabling them in SYSCIER ?
It doesn't matter much, as they're disabled at the GIC level anyway.
Note that the current platform code doesn't mask them at all.
I'll change the order, though.
>> +/*
>> + * Initialization phase 2, including setup of always-on and I/O domains
>> + */
>> +static int __init rcar_sysc_probe(struct platform_device *pdev)
>> +{
>> + struct device *dev = &pdev->dev;
>> +
>> + if (!rcar_sysc_onecell_data)
>> + return -ENODEV;
>> +
>> + rcar_sysc_onecell_data->domains[RCAR_PD_ALWAYS_ON] =
>> + pd_to_genpd(dev->pm_domain);
>
> This part, or rather the power-domains = <&cpg_clocks>; property in the SYSC
> DT node, bothers me. I don't think the DT property really describes the
> hardware. I like your " clk: renesas: cpg-mssr: Export
> cpg_mssr_{at,de}tach_dev()" approach better.
I had two issues with the other approach:
1. It required keeping a static pointer to the cpg_mssr_clk_domain structure,
2. The SYSC driver had to call the CPG/MSSR driver directly.
The second issue made it complicated to support the SYSC "always-on" PM Domain
on R-Car H1 and Gen2, as these SoCs (currently) don't use the CPG/MSSR driver,
but the CPG/MSTP driver, so the SYSC driver has to differentiate to call into
the right Clock Domain driver. Migrating these SoCs over to CPG/MSSR and
preserving backwards compatibility is even more complicated.
Hence the need to express the relationship in DT.
Would you be more comfortable using a custom property instead of the
"power-domains" property to link SYSC to CPG in DT?
E.g.:
renesas,cpg = <&cpg_clocks>;
The "Connected module" subsection of the "System Controller (SYSC)" section of
the User's Manual does list the "Clock Pulse Generator (CPG)" as a connected
module, so that would describe the hardware.
Then I can call of_genpd_get_from_provider() to get a pointer to the Clock
Domain, and call its .attach/detach() methods directly from
rcar_sysc_{at,de}tach_dev(), without walking the parent PM Domains.
>> --- /dev/null
>> +++ b/drivers/soc/renesas/rcar-sysc.h
>> +/*
>> + * Power Domain flags
>> + */
>> +#define PD_CPU
Re: [PATCH v4 11/11] soc: renesas: rcar-sysc: Add support for R-Car H3 power areas
On Sat, Apr 9, 2016 at 9:22 PM, Laurent Pinchart
wrote:
>> --- /dev/null
>> +++ b/drivers/soc/renesas/r8a7795-sysc.c
>> @@ -0,0 +1,53 @@
>> +/*
>> + * Renesas R-Car H3 System Controller
>> + *
>> + * Copyright (C) 2016 Glider bvba
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; version 2 of the License.
>> + */
>> +
>> +#include
>
> Why do you need this header ? ARRAY_SIZE is defined in linux/kernel.h and
> __initconst in linux/init.h. Am I missing something ?
ARRAY_SIZE() uses __must_be_array() uses BUILD_BUG_ON_ZERO().
IIRC, I sent a patch to include bug.h a while ago, but it was rejected.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [GIT PULL] Renesas ARM Based SoC Fixes for v4.6
Hi Simon,
On Mon, Apr 11, 2016 at 3:52 AM, Simon Horman
wrote:
> Hi Olof, Hi Kevin, Hi Arnd,
>
> Please consider these Renesas ARM based SoC fixes for v4.6.
>
>
> Allow serial to work once again on the Porter board (Revision B) which
> does not have the oscillator in question mounted.
Have you tested this on Porter?
I believe there's another change to be made for this revert to actually work,
cfr. "[PATCH] ARM: dts: r8a7791: Don't disable referenced optional clocks"
(https://lkml.org/lkml/2016/4/6/350)
> The following changes since commit f55532a0c0b8bb6148f4e07853b876ef73bc69ca:
>
> Linux 4.6-rc1 (2016-03-26 16:03:24 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git
> tags/renesas-fixes-for-v4.6
>
> for you to fetch changes up to e885767418bff0c591cc1e45babdd25d91b4a795:
>
> Revert "ARM: dts: porter: Enable SCIF_CLK frequency and pins" (2016-04-08
> 15:56:28 +0900)
>
>
> Renesas ARM Based SoC Fixes for v4.6
>
> * Revert "ARM: dts: porter: Enable SCIF_CLK frequency and pins"
>
>
> Sjoerd Simons (1):
> Revert "ARM: dts: porter: Enable SCIF_CLK frequency and pins"
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
