rpi-4.7.y enable clock manager and modify all subsystems to use it - with reverts #1629
Conversation
This reverts commit 846ee11.
This reverts commit 224a465.
This reverts commit b99821f.
This reverts commit 6019d04.
This reverts commit fb8d849.
…rect values" This reverts commit 01506b7.
This reverts commit 658794c.
This reverts commit f66b42f.
This reverts commit d4c84d9.
This reverts commit d4481e2.
…sfers"" This reverts commit b3b4815.
Enable the clock manager by default. Signed-off-by: Martin Sperl <[email protected]>
Removed clock registers from reg and added clock to i2s devicetree node. Signed-off-by: Martin Sperl <[email protected]>
Upstream mandates the use of "serial" as name inside the device-tree. Note that this does not affect the use of the alias - there uart0 and uart1 are permissible. This also fixed the patch references inside the overlays for the rpi3. Signed-off-by: Martin Sperl <[email protected]>
Moved uart0 to use new clock framework. At the same time removed the fixed clock clk_uart0 and the corresponding references, as the clock is now read directly from the configured clocks. If it ever becomes necessary the following can get added to modify the base clock rate later: assigned-clocks = <&clocks BCM2835_CLOCK_UART>; assigned-clock-rates = <X>; Signed-off-by: Martin Sperl <[email protected]>
use spi0 to use new clock framwork Signed-off-by: Martin Sperl <[email protected]>
move i2c to use the new clock framework instead of the fixed clock Signed-off-by: Martin Sperl <[email protected]>
Move PWM to use the new clock framework Signed-off-by: Martin Sperl <[email protected]>
Fix the auxiliar clock provider to use the clock framework Signed-off-by: Martin Sperl <[email protected]>
Fix the register range of the spi-aux devices, as they do not control the gate. Signed-off-by: Martin Sperl <[email protected]>
Move to new aux-uart driver (from upstream) and enable it correctly in the device tree Note that this may also solve the "serial not 115200 baud" issue on the rpi3... With an extension to the driver (requesting clock change notifications) the driver could change the baud divider when such a clock change occurs... It still would require some communication between the firmware and the kernel, so that this would get propagated. Signed-off-by: Martin Sperl <[email protected]>
Remove no longer necessary fixed pwm clock. Signed-off-by: Martin Sperl <[email protected]>
Use clock manager instead of self-made clockmanager. Also fix some error paths that showd up during development (especially missing release of dma resources on rmmod) Signed-off-by: Martin Sperl <[email protected]>
Move smi to use clock framework. Signed-off-by: Martin Sperl <[email protected]>
Move mmc to use clock framework. For some reason the emmc clock dirver does not claim the clock - enable count stays at 0 for the emmc clock. Signed-off-by: Martin Sperl <[email protected]>
Move the sdhost device to use the clock framework. Unfortunately I can not test it on my CM, as it seem as if there is no overlay that would enable sdhost and change the gpio-mux to the correct ALT0 (from Alt3 from mmc). Signed-off-by: Martin Sperl <[email protected]>
Remove clk_core from device tree as it is no longer used. Any "modification" to the core_clock in the bootloader is now automatically detected via the cnew clockmgr. Signed-off-by: Martin Sperl <[email protected]>
Revert the i2s-mmap dt overlay (7ee829f). Signed-off-by: DigitalDreamtime <[email protected]>
Moved uart0 to use new clock framework. At the same time removed the fixed clock clk_uart0 and the corresponding references, as the clock is now read directly from the configured clocks. If it ever becomes necessary the following can get added to modify the base clock rate later: assigned-clocks = <&clocks BCM2835_CLOCK_UART>; assigned-clock-rates = <X>; Signed-off-by: DigitalDreamtime <[email protected]>
Remove clk_core from device tree as it is no longer used. Any "modification" to the core_clock in the bootloader is now automatically detected via the cnew clockmgr. Signed-off-by: DigitalDreamtime <[email protected]>
|
Thanks for working on/testing this. |
It tries to initialise some subsystems before clockmgr is initialised, so deferred probe. It's fine. I don't think we should hide those messages. I'd rather see them. ;) |
Sorry, I forgot. I know you already told me the answer to this.... Is the LibreELEC build using 4.6 or 4.7 tree? |
|
The wording and red colouration in dmesg will probably cause unwanted bug reports. Maybe there is a way to make it seem more normal. LE uses 4.7 kernel. |
|
|
Note that I have posted a patch to the rpi and clock list to initialize clockmgr early - You could try that... |
|
Yes, that's what my patch looks like (except without the deprecated braces around a single line block). |
|
Please get someone to test smi and pwm... |
@msperl LOL. Martin, make it easy for a fool. Can you give me a link to the patch rather than me scouring mailing list archives? |
|
https://patchwork.kernel.org/patch/9128797/ |
|
Thanks. Hmmm. |
|
Well, it was related to the second patch to claim the sdram clock early, which Eric wanted to get implemented differently (probably because the sdram clocks are only accessible from vc4) |
|
I'd add a Tested-By and be asking the RPi guys to pull it, but seen as it is't going to receive upstream acceptance, it'll just remain part of my local, ever growing, patch set. It didn't apply cleanly so I removed "err" variable and used the already defined "ret". |
|
Yes, I also cherry-picked the patch to 4.7 tree. It avoids the deferred probe warnings. |
|
I will try to upstream the early init patch alone - glad to hear that it makes a difference on its own... |
Cool! Makes perfect sense to me, that something on which everything else now depends, get's initialised early and avoids a bunch of deferred probes..... sdhost, mmc, serial.... |
|
Well, if I remember correctly, there was one concern about possible drivers that during init enable a clock and then fail/defer on something else, which would disable a clock which could disable a necessary pll or pll-divider... But then I guess that driver needs to get modified. |
|
So I guess this is finally done - now we require the support by Eric to get vc4 updates into the 4.7 kernel... |
@msperl Yes, we're done. Will be interesting to see if there is any "fall-out" after the next LibreELEC build. The real question is, do we want to pull the "subsystems to use clockmgr rather than clocks directly, backport" into rpi-4.4.y, as this is going to be the "default" RPi kernel for the foreseeable future.... #1592 (If Pi guys are going to wait for next LTS. And if that is to be 4.9, that's not going to be before the end of the year.) Anyway, this is finally "put to bed". Thank you Martin! You did all of the heavy lifting. I mostly did the "getting frustrated"..... ISTR, it was January when I started running the new dma code. (That took its time to make it into downstream.) And I've lost track of how many months ago, I was testing a rpi-4 tree "backport" of dma/I2S/clockmgr...... I'd like to return to trying to get that "simple framework" callback stuff into upstream simple-card, if you're up for it? I made a few more mods. Next week I'll make a new rpi-4.7.y branch..... |
|
@clivem as for the backport: the patches should be easy to apply, but I guess foundation will not want to move that way as there is a bigger risk in breaking things unexpectedly. The risk is still there with 4.7, but a move to a newer kernel makes it more obvious that things may break. I wonder if we now can get the vc4 driver into 4.7, because going from there it should then be easy to move to the next stable kernel, as we are mostly upstream already.... But I guess that popcornmix will need to make that decision. |
Agreed. But my concern is that we think we have put this to bed..... (I thought this was finished 3 months ago when I had everything I needed to work with clockmgr, working with a patched rpi-4.4 build.) If they really do wait for a 4.9 LTS release before moving from 4.4, this is going to come up again around Christmas, if there are any issues...... Don't know about you but I'd rather see them resolved now, rather than deferred for 3 months.
I wonder if we need to ask @popcornmix et @pelwell to make a "next" build from the rpi-4.7.y tree so it gets some wider testing. (I'm not convinced that OpenELEC is enough. The stuff those guys are testing. ie. the audio, I'm fairly sure we are on safe ground already. I'm not sure they are interested in VC4.) I think we should ping Eric and ask him to get VC4 "up to scratch" in this rpi-4.7.y tree and get a "next" build out there for the people who might want to live a little dangerously and not sit out the rest of the year with a rpi-4.4 kernel build. There are several people who did want I2S and VC4 at the same time. Make it easy for them with a "next" build they can rpi-update to, and they will test! ;) |
|
Having had cause to look closely at the logs on my CM test subject today, I noticed the enc28j60 spi ethernet not initialising on 4.7.y .... I wondered whether this was related to clockmgr.... Still works fine on my rpi-4.4.y plus clockmgr backport.... (So most likely something else changed between rpi-4.4.y and rpi-4.7.y.) I'll have to take a closer look later in the week. |
|
It is "correctly" detected, as otherwise eth0 does not probe - "enc28j60_chipset_init" fails... You can load enc28j60 with the kernel argument debug=... (up to 0xffff) That should give you messages like "chip RevID:" and that indicates that spi is working and the chip is detected... |
|
Ping @anholt - the rpi-4.7.y tree now uses the upstream clock framework. |
|
For completeness: the clock patches have gone into clk-next, so they should show up in 4.9... |
PR raspberrypi#1629 removed a dereference in the original code leading to smi_bus_address being wrong
bef1575 (raspberrypi#1629) removed a dereference in the original code leading to smi_bus_address being wrong
Make use of the clock framework for all drivers (no more opt in like with the 4.4 kernels, where lots of things stop working when the clock framework is enabled - especially i2s)
This is the equivalent patch to #1628, but here with reverted reverts instead of a single "bulk" revert.