Hi Geert,
On 3/26/20 4:31 PM, Geert Uytterhoeven wrote:
Hi Mylene,
On Thu, Mar 26, 2020 at 2:50 PM Mylene Josserand
<mylene.josserand@xxxxxxxxxxxxx> wrote:
On 3/6/20 11:45 AM, Geert Uytterhoeven wrote:
On Wed, Mar 4, 2020 at 12:00 PM Heiko Stübner <heiko@xxxxxxxxx> wrote:
Am Montag, 2. März 2020, 16:57:02 CET schrieb Mylène Josserand:
Determine which revision of rk3288 by checking the HDMI version.
According to the Rockchip BSP kernel, on rk3288w, the HDMI
revision equals 0x1A which is not the case for the rk3288 [1].
As these SOC have some differences, the new function
'soc_is_rk3288w' will help us to know on which revision
we are.
what happened to just having a different compatible in the dts?
Aka doing a
rk3288w.dtsi with
#include "rk3288.dtsi"
&cru {
compatible = "rockchip,rk3288w-cru";
}
I somehow don't expect boards to just switch between soc variants
on the fly.
Also, doing things in mach-rockchip is not very future-proof:
(1) having random soc-specific APIs spanning the kernel feels wrong,
especially as at some point it might not be contained to our own special
drivers like the cru. I cannot really see people being enthusiastic if
something like this would be needed in say the core Analogix-DP bridge ;-)
Indeed. You're better of registering an soc_device_attribute using
soc_device_register(), after which any driver can use soc_device_match()
to differentiate based on the SoC revision.
Thank you for this suggestion. The issue is that clocks are registered
at an early stage of the boot so using initcalls is too late for the
clock differentiation :(
IC, rk388 is still using CLK_OF_DECLARE().
What about converting it to a platform driver, registered from e.g.
subsys_initcall()?
If you need some clocks early (e.g. for timers), you can do split
registration, with the early part still using CLK_OF_DECLARE().
That should work, assumed the timer clocks don't need differentiation.
Gr{oetje,eeting}s,
Geert
oh, nice, thanks for the help!
I will try that and send a new version if it is working fine.
Best regards,
Mylène
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-rockchip
