* [PATCH 0/2] ARM: Add Rockchip rk3288w support @ 2020-03-02 15:57 Mylène Josserand 2020-03-02 15:57 ` [PATCH 1/2] ARM: Rockchip: Handle rk3288/rk3288w revision Mylène Josserand 2020-03-02 15:57 ` [PATCH 2/2] clk: rockchip: rk3288: Handle clock tree for rk3288w Mylène Josserand 0 siblings, 2 replies; 15+ messages in thread From: Mylène Josserand @ 2020-03-02 15:57 UTC (permalink / raw) To: linux, heiko, mturquette, sboyd Cc: mylene.josserand, kernel, linux-clk, linux-arm-kernel, linux-rockchip Hello everyone, This series adds the support for the Rockchip RK3288w which is a revision of the RK3288. It is mostly the same SOC except for, at least, one clock tree which is different. This difference is only known by the BSP kernel repository [1]. Currently, the mainline kernel will not hang on rk3288w but it is probably by "chance" because we got an issue on a lower kernel version. According to Rockchip's U-Boot [2], the rk3288w can be detected using the HDMI revision number (= 0x1A) in this version of the SOC. Not to rely on U-Boot about the compatible, the patch 01 will handle the detection of the HDMI version in the rockchip subsystem. Let me know what you think! Best regards, Mylène Josserand [1] https://github.com/rockchip-linux/kernel/blob/develop-4.4/drivers/clk/rockchip/clk-rk3288.c#L960..L964 [2] https://github.com/rockchip-linux/u-boot/blob/next-dev/arch/arm/mach-rockchip/rk3288/rk3288.c#L378..L388 Mylène Josserand (2): ARM: Rockchip: Handle rk3288/rk3288w revision clk: rockchip: rk3288: Handle clock tree for rk3288w arch/arm/mach-rockchip/rockchip.c | 45 +++++++++++++++++++++++++++++++ drivers/clk/rockchip/clk-rk3288.c | 21 +++++++++++++-- include/soc/rockchip/revision.h | 22 +++++++++++++++ 3 files changed, 86 insertions(+), 2 deletions(-) create mode 100644 include/soc/rockchip/revision.h -- 2.25.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH 1/2] ARM: Rockchip: Handle rk3288/rk3288w revision 2020-03-02 15:57 [PATCH 0/2] ARM: Add Rockchip rk3288w support Mylène Josserand @ 2020-03-02 15:57 ` Mylène Josserand 2020-03-04 10:59 ` Heiko Stübner 2020-03-02 15:57 ` [PATCH 2/2] clk: rockchip: rk3288: Handle clock tree for rk3288w Mylène Josserand 1 sibling, 1 reply; 15+ messages in thread From: Mylène Josserand @ 2020-03-02 15:57 UTC (permalink / raw) To: linux, heiko, mturquette, sboyd Cc: mylene.josserand, kernel, linux-clk, linux-arm-kernel, linux-rockchip 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. [1]:https://github.com/rockchip-linux/u-boot/blob/f992fe3334aa5090acb448261982628b5a3d37a5/arch/arm/include/asm/arch-rockchip/cpu.h#L30..L34 Signed-off-by: Mylène Josserand <mylene.josserand@collabora.com> --- arch/arm/mach-rockchip/rockchip.c | 45 +++++++++++++++++++++++++++++++ include/soc/rockchip/revision.h | 22 +++++++++++++++ 2 files changed, 67 insertions(+) create mode 100644 include/soc/rockchip/revision.h diff --git a/arch/arm/mach-rockchip/rockchip.c b/arch/arm/mach-rockchip/rockchip.c index f9797a2b5d0d..b907ba390093 100644 --- a/arch/arm/mach-rockchip/rockchip.c +++ b/arch/arm/mach-rockchip/rockchip.c @@ -9,12 +9,14 @@ #include <linux/kernel.h> #include <linux/init.h> #include <linux/io.h> +#include <linux/of_address.h> #include <linux/of_platform.h> #include <linux/irqchip.h> #include <linux/clk-provider.h> #include <linux/clocksource.h> #include <linux/mfd/syscon.h> #include <linux/regmap.h> +#include <soc/rockchip/revision.h> #include <asm/mach/arch.h> #include <asm/mach/map.h> #include <asm/hardware/cache-l2x0.h> @@ -22,6 +24,49 @@ #include "pm.h" #define RK3288_TIMER6_7_PHYS 0xff810000 +#define RK3288_HDMI_REV_REG 0x04 +#define RK3288W_HDMI_REV 0x1A + +static const struct of_device_id rk3288_dt_hdmi_match[] __initconst = { + { .compatible = "rockchip,rk3288-dw-hdmi" }, + { } +}; + +int rk3288_get_revision(void) +{ + static int revision = RK3288_SOC_REV_UNKNOWN; + struct device_node *dn; + void __iomem *hdmi_base; + + if (revision != RK3288_SOC_REV_UNKNOWN) + return revision; + + dn = of_find_matching_node(NULL, rk3288_dt_hdmi_match); + if (!dn) { + pr_err("%s: Couldn't find HDMI node\n", __func__); + return -EINVAL; + } + + hdmi_base = of_iomap(dn, 0); + of_node_put(dn); + + if (!hdmi_base) { + pr_err("%s: Couldn't map %pOF regs\n", __func__, + hdmi_base); + return -ENXIO; + } + + if (readl_relaxed(hdmi_base + RK3288_HDMI_REV_REG) == + RK3288W_HDMI_REV) + revision = RK3288_SOC_REV_RK3288W; + else + revision = RK3288_SOC_REV_RK3288; + + iounmap(hdmi_base); + + return revision; +} +EXPORT_SYMBOL(rk3288_get_revision); static void __init rockchip_timer_init(void) { diff --git a/include/soc/rockchip/revision.h b/include/soc/rockchip/revision.h new file mode 100644 index 000000000000..226419c60af0 --- /dev/null +++ b/include/soc/rockchip/revision.h @@ -0,0 +1,22 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Copyright 2020 Collabora + */ + +#ifndef __SOC_ROCKCHIP_REVISION_H__ +#define __SOC_ROCKCHIP_REVISION_H__ + +enum rk3288_soc_revision { + RK3288_SOC_REV_UNKNOWN, + RK3288_SOC_REV_RK3288, + RK3288_SOC_REV_RK3288W, +}; + +int rk3288_get_revision(void); + +static inline bool soc_is_rk3288w(void) +{ + return rk3288_get_revision() == RK3288_SOC_REV_RK3288W; +} + +#endif /* __SOC_ROCKCHIP_REVISION_H__ */ -- 2.25.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: [PATCH 1/2] ARM: Rockchip: Handle rk3288/rk3288w revision 2020-03-02 15:57 ` [PATCH 1/2] ARM: Rockchip: Handle rk3288/rk3288w revision Mylène Josserand @ 2020-03-04 10:59 ` Heiko Stübner 2020-03-05 0:03 ` Ezequiel Garcia 2020-03-06 10:45 ` Geert Uytterhoeven 0 siblings, 2 replies; 15+ messages in thread From: Heiko Stübner @ 2020-03-04 10:59 UTC (permalink / raw) To: Mylène Josserand Cc: sboyd, mturquette, linux, linux-rockchip, kernel, linux-clk, linux-arm-kernel Hi, 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 ;-) (2) I guess the rk3288w will not be the last soc doing this and on arm64 you can't do it that way, as there is no mach-rockchip there So my personal preference would really would be just a specific compatible for affected ip blocks. Heiko > [1]:https://github.com/rockchip-linux/u-boot/blob/f992fe3334aa5090acb448261982628b5a3d37a5/arch/arm/include/asm/arch-rockchip/cpu.h#L30..L34 > > Signed-off-by: Mylène Josserand <mylene.josserand@collabora.com> > --- > arch/arm/mach-rockchip/rockchip.c | 45 +++++++++++++++++++++++++++++++ > include/soc/rockchip/revision.h | 22 +++++++++++++++ > 2 files changed, 67 insertions(+) > create mode 100644 include/soc/rockchip/revision.h > > diff --git a/arch/arm/mach-rockchip/rockchip.c b/arch/arm/mach-rockchip/rockchip.c > index f9797a2b5d0d..b907ba390093 100644 > --- a/arch/arm/mach-rockchip/rockchip.c > +++ b/arch/arm/mach-rockchip/rockchip.c > @@ -9,12 +9,14 @@ > #include <linux/kernel.h> > #include <linux/init.h> > #include <linux/io.h> > +#include <linux/of_address.h> > #include <linux/of_platform.h> > #include <linux/irqchip.h> > #include <linux/clk-provider.h> > #include <linux/clocksource.h> > #include <linux/mfd/syscon.h> > #include <linux/regmap.h> > +#include <soc/rockchip/revision.h> > #include <asm/mach/arch.h> > #include <asm/mach/map.h> > #include <asm/hardware/cache-l2x0.h> > @@ -22,6 +24,49 @@ > #include "pm.h" > > #define RK3288_TIMER6_7_PHYS 0xff810000 > +#define RK3288_HDMI_REV_REG 0x04 > +#define RK3288W_HDMI_REV 0x1A > + > +static const struct of_device_id rk3288_dt_hdmi_match[] __initconst = { > + { .compatible = "rockchip,rk3288-dw-hdmi" }, > + { } > +}; > + > +int rk3288_get_revision(void) > +{ > + static int revision = RK3288_SOC_REV_UNKNOWN; > + struct device_node *dn; > + void __iomem *hdmi_base; > + > + if (revision != RK3288_SOC_REV_UNKNOWN) > + return revision; > + > + dn = of_find_matching_node(NULL, rk3288_dt_hdmi_match); > + if (!dn) { > + pr_err("%s: Couldn't find HDMI node\n", __func__); > + return -EINVAL; > + } > + > + hdmi_base = of_iomap(dn, 0); > + of_node_put(dn); > + > + if (!hdmi_base) { > + pr_err("%s: Couldn't map %pOF regs\n", __func__, > + hdmi_base); > + return -ENXIO; > + } > + > + if (readl_relaxed(hdmi_base + RK3288_HDMI_REV_REG) == > + RK3288W_HDMI_REV) > + revision = RK3288_SOC_REV_RK3288W; > + else > + revision = RK3288_SOC_REV_RK3288; > + > + iounmap(hdmi_base); > + > + return revision; > +} > +EXPORT_SYMBOL(rk3288_get_revision); > > static void __init rockchip_timer_init(void) > { > diff --git a/include/soc/rockchip/revision.h b/include/soc/rockchip/revision.h > new file mode 100644 > index 000000000000..226419c60af0 > --- /dev/null > +++ b/include/soc/rockchip/revision.h > @@ -0,0 +1,22 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +/* > + * Copyright 2020 Collabora > + */ > + > +#ifndef __SOC_ROCKCHIP_REVISION_H__ > +#define __SOC_ROCKCHIP_REVISION_H__ > + > +enum rk3288_soc_revision { > + RK3288_SOC_REV_UNKNOWN, > + RK3288_SOC_REV_RK3288, > + RK3288_SOC_REV_RK3288W, > +}; > + > +int rk3288_get_revision(void); > + > +static inline bool soc_is_rk3288w(void) > +{ > + return rk3288_get_revision() == RK3288_SOC_REV_RK3288W; > +} > + > +#endif /* __SOC_ROCKCHIP_REVISION_H__ */ > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 1/2] ARM: Rockchip: Handle rk3288/rk3288w revision 2020-03-04 10:59 ` Heiko Stübner @ 2020-03-05 0:03 ` Ezequiel Garcia 2020-03-05 0:51 ` Heiko Stübner 2020-03-06 10:45 ` Geert Uytterhoeven 1 sibling, 1 reply; 15+ messages in thread From: Ezequiel Garcia @ 2020-03-05 0:03 UTC (permalink / raw) To: Heiko Stübner, Mylène Josserand Cc: sboyd, mturquette, linux, linux-rockchip, kernel, linux-clk, linux-arm-kernel Hi Heiko, On Wed, 2020-03-04 at 11:59 +0100, Heiko Stübner wrote: > Hi, > > 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 guess you have something like this in mind: static void __init rk3288_clk_init(struct device_node *np) { __rk3288_clk_init(np, RK3288_SOC_REV_RK3288W); } CLK_OF_DECLARE(rk3288_cru, "rockchip,rk3288-cru", rk3288_clk_init); static void __init rk3288w_clk_init(struct device_node *np) { __rk3288_clk_init(np, RK3288_SOC_REV_RK3288); } CLK_OF_DECLARE(rk3288_cru, "rockchip,rk3288w-cru", rk3288w_clk_init); And the rest is mostly untouched, except the revision is no longer queried and is now passed by the DT? This would be cleaner for the kernel, with the obvious drawback being that you now have to maintain another DTS. This could be an inconvenience. I believe RK3288W is meant as a direct replacement for RK3288, so folks building products would expect to just use RK3288W, and not really bother with passing a different DTS or what not. > I somehow don't expect boards to just switch between soc variants > on the fly. > While I agree they are nasty, quirks like this are not uncommon. > Also, doing things in mach-rockchip is not very future-proof: > There is actually no reason to keep this in mach-rockchip, right? The quirk could be placed in other places. For instance, directly in the clock driver. Thanks for reviewing! Ezequiel > (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 ;-) > (2) I guess the rk3288w will not be the last soc doing this and on arm64 you > can't do it that way, as there is no mach-rockchip there > > So my personal preference would really would be just a specific compatible > for affected ip blocks. > > Heiko > > > [1]:https://github.com/rockchip-linux/u-boot/blob/f992fe3334aa5090acb448261982628b5a3d37a5/arch/arm/include/asm/arch-rockchip/cpu.h#L30..L34 > > > > Signed-off-by: Mylène Josserand <mylene.josserand@collabora.com> > > --- > > arch/arm/mach-rockchip/rockchip.c | 45 +++++++++++++++++++++++++++++++ > > include/soc/rockchip/revision.h | 22 +++++++++++++++ > > 2 files changed, 67 insertions(+) > > create mode 100644 include/soc/rockchip/revision.h > > > > diff --git a/arch/arm/mach-rockchip/rockchip.c b/arch/arm/mach-rockchip/rockchip.c > > index f9797a2b5d0d..b907ba390093 100644 > > --- a/arch/arm/mach-rockchip/rockchip.c > > +++ b/arch/arm/mach-rockchip/rockchip.c > > @@ -9,12 +9,14 @@ > > #include <linux/kernel.h> > > #include <linux/init.h> > > #include <linux/io.h> > > +#include <linux/of_address.h> > > #include <linux/of_platform.h> > > #include <linux/irqchip.h> > > #include <linux/clk-provider.h> > > #include <linux/clocksource.h> > > #include <linux/mfd/syscon.h> > > #include <linux/regmap.h> > > +#include <soc/rockchip/revision.h> > > #include <asm/mach/arch.h> > > #include <asm/mach/map.h> > > #include <asm/hardware/cache-l2x0.h> > > @@ -22,6 +24,49 @@ > > #include "pm.h" > > > > #define RK3288_TIMER6_7_PHYS 0xff810000 > > +#define RK3288_HDMI_REV_REG 0x04 > > +#define RK3288W_HDMI_REV 0x1A > > + > > +static const struct of_device_id rk3288_dt_hdmi_match[] __initconst = { > > + { .compatible = "rockchip,rk3288-dw-hdmi" }, > > + { } > > +}; > > + > > +int rk3288_get_revision(void) > > +{ > > + static int revision = RK3288_SOC_REV_UNKNOWN; > > + struct device_node *dn; > > + void __iomem *hdmi_base; > > + > > + if (revision != RK3288_SOC_REV_UNKNOWN) > > + return revision; > > + > > + dn = of_find_matching_node(NULL, rk3288_dt_hdmi_match); > > + if (!dn) { > > + pr_err("%s: Couldn't find HDMI node\n", __func__); > > + return -EINVAL; > > + } > > + > > + hdmi_base = of_iomap(dn, 0); > > + of_node_put(dn); > > + > > + if (!hdmi_base) { > > + pr_err("%s: Couldn't map %pOF regs\n", __func__, > > + hdmi_base); > > + return -ENXIO; > > + } > > + > > + if (readl_relaxed(hdmi_base + RK3288_HDMI_REV_REG) == > > + RK3288W_HDMI_REV) > > + revision = RK3288_SOC_REV_RK3288W; > > + else > > + revision = RK3288_SOC_REV_RK3288; > > + > > + iounmap(hdmi_base); > > + > > + return revision; > > +} > > +EXPORT_SYMBOL(rk3288_get_revision); > > > > static void __init rockchip_timer_init(void) > > { > > diff --git a/include/soc/rockchip/revision.h b/include/soc/rockchip/revision.h > > new file mode 100644 > > index 000000000000..226419c60af0 > > --- /dev/null > > +++ b/include/soc/rockchip/revision.h > > @@ -0,0 +1,22 @@ > > +/* SPDX-License-Identifier: GPL-2.0-only */ > > +/* > > + * Copyright 2020 Collabora > > + */ > > + > > +#ifndef __SOC_ROCKCHIP_REVISION_H__ > > +#define __SOC_ROCKCHIP_REVISION_H__ > > + > > +enum rk3288_soc_revision { > > + RK3288_SOC_REV_UNKNOWN, > > + RK3288_SOC_REV_RK3288, > > + RK3288_SOC_REV_RK3288W, > > +}; > > + > > +int rk3288_get_revision(void); > > + > > +static inline bool soc_is_rk3288w(void) > > +{ > > + return rk3288_get_revision() == RK3288_SOC_REV_RK3288W; > > +} > > + > > +#endif /* __SOC_ROCKCHIP_REVISION_H__ */ > > > > > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 1/2] ARM: Rockchip: Handle rk3288/rk3288w revision 2020-03-05 0:03 ` Ezequiel Garcia @ 2020-03-05 0:51 ` Heiko Stübner 2020-03-05 11:32 ` Ezequiel Garcia 0 siblings, 1 reply; 15+ messages in thread From: Heiko Stübner @ 2020-03-05 0:51 UTC (permalink / raw) To: Ezequiel Garcia Cc: Mylène Josserand, sboyd, mturquette, linux, linux-rockchip, kernel, linux-clk, linux-arm-kernel Hi Ezequiel, Am Donnerstag, 5. März 2020, 01:03:30 CET schrieb Ezequiel Garcia: > Hi Heiko, > > On Wed, 2020-03-04 at 11:59 +0100, Heiko Stübner wrote: > > Hi, > > > > 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 guess you have something like this in mind: > > static void __init rk3288_clk_init(struct device_node *np) > { > __rk3288_clk_init(np, RK3288_SOC_REV_RK3288W); > } > CLK_OF_DECLARE(rk3288_cru, "rockchip,rk3288-cru", rk3288_clk_init); > > static void __init rk3288w_clk_init(struct device_node *np) > { > __rk3288_clk_init(np, RK3288_SOC_REV_RK3288); > } > CLK_OF_DECLARE(rk3288_cru, "rockchip,rk3288w-cru", rk3288w_clk_init); > > And the rest is mostly untouched, except the revision is > no longer queried and is now passed by the DT? Essentially yes, but I guess I was more thinking along the lines of the rk3188/rk3066a/rk3188a (drivers/clk/rockchip/clk-rk3188.c) > This would be cleaner for the kernel, with the obvious > drawback being that you now have to maintain > another DTS. Right now we would end up with the pretty minimal devicetree having just that cru. So not very invasive. > This could be an inconvenience. I believe > RK3288W is meant as a direct replacement for RK3288, > so folks building products would expect to just use > RK3288W, and not really bother with passing a > different DTS or what not. Not sure I follow. As below, I don't think boards will magically switch between soc variants, so a boards devicetree should just include the variant - especially as I don't really know how many additional new boards we will see with it (rk3288 being quite old itself). > > I somehow don't expect boards to just switch between soc variants > > on the fly. > > > > While I agree they are nasty, quirks like this > are not uncommon. > > > Also, doing things in mach-rockchip is not very future-proof: > > > > There is actually no reason to keep this in mach-rockchip, right? > > The quirk could be placed in other places. For instance, > directly in the clock driver. Mapping the hdmi controller inside the clock driver to read some "random" register that hopefully indicates an (undocumented) distinction between soc variants. Somehow just having that minimal devicetree for the "w" sounds way cleaner ;-) . It's definitly cool to have support for the rk3288w but I don't like adding hacks for something that is after all some sort of niche product. Heiko > > (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 ;-) > > (2) I guess the rk3288w will not be the last soc doing this and on arm64 you > > can't do it that way, as there is no mach-rockchip there > > > > So my personal preference would really would be just a specific compatible > > for affected ip blocks. > > > > Heiko > > > > > [1]:https://github.com/rockchip-linux/u-boot/blob/f992fe3334aa5090acb448261982628b5a3d37a5/arch/arm/include/asm/arch-rockchip/cpu.h#L30..L34 > > > > > > Signed-off-by: Mylène Josserand <mylene.josserand@collabora.com> > > > --- > > > arch/arm/mach-rockchip/rockchip.c | 45 +++++++++++++++++++++++++++++++ > > > include/soc/rockchip/revision.h | 22 +++++++++++++++ > > > 2 files changed, 67 insertions(+) > > > create mode 100644 include/soc/rockchip/revision.h > > > > > > diff --git a/arch/arm/mach-rockchip/rockchip.c b/arch/arm/mach-rockchip/rockchip.c > > > index f9797a2b5d0d..b907ba390093 100644 > > > --- a/arch/arm/mach-rockchip/rockchip.c > > > +++ b/arch/arm/mach-rockchip/rockchip.c > > > @@ -9,12 +9,14 @@ > > > #include <linux/kernel.h> > > > #include <linux/init.h> > > > #include <linux/io.h> > > > +#include <linux/of_address.h> > > > #include <linux/of_platform.h> > > > #include <linux/irqchip.h> > > > #include <linux/clk-provider.h> > > > #include <linux/clocksource.h> > > > #include <linux/mfd/syscon.h> > > > #include <linux/regmap.h> > > > +#include <soc/rockchip/revision.h> > > > #include <asm/mach/arch.h> > > > #include <asm/mach/map.h> > > > #include <asm/hardware/cache-l2x0.h> > > > @@ -22,6 +24,49 @@ > > > #include "pm.h" > > > > > > #define RK3288_TIMER6_7_PHYS 0xff810000 > > > +#define RK3288_HDMI_REV_REG 0x04 > > > +#define RK3288W_HDMI_REV 0x1A > > > + > > > +static const struct of_device_id rk3288_dt_hdmi_match[] __initconst = { > > > + { .compatible = "rockchip,rk3288-dw-hdmi" }, > > > + { } > > > +}; > > > + > > > +int rk3288_get_revision(void) > > > +{ > > > + static int revision = RK3288_SOC_REV_UNKNOWN; > > > + struct device_node *dn; > > > + void __iomem *hdmi_base; > > > + > > > + if (revision != RK3288_SOC_REV_UNKNOWN) > > > + return revision; > > > + > > > + dn = of_find_matching_node(NULL, rk3288_dt_hdmi_match); > > > + if (!dn) { > > > + pr_err("%s: Couldn't find HDMI node\n", __func__); > > > + return -EINVAL; > > > + } > > > + > > > + hdmi_base = of_iomap(dn, 0); > > > + of_node_put(dn); > > > + > > > + if (!hdmi_base) { > > > + pr_err("%s: Couldn't map %pOF regs\n", __func__, > > > + hdmi_base); > > > + return -ENXIO; > > > + } > > > + > > > + if (readl_relaxed(hdmi_base + RK3288_HDMI_REV_REG) == > > > + RK3288W_HDMI_REV) > > > + revision = RK3288_SOC_REV_RK3288W; > > > + else > > > + revision = RK3288_SOC_REV_RK3288; > > > + > > > + iounmap(hdmi_base); > > > + > > > + return revision; > > > +} > > > +EXPORT_SYMBOL(rk3288_get_revision); > > > > > > static void __init rockchip_timer_init(void) > > > { > > > diff --git a/include/soc/rockchip/revision.h b/include/soc/rockchip/revision.h > > > new file mode 100644 > > > index 000000000000..226419c60af0 > > > --- /dev/null > > > +++ b/include/soc/rockchip/revision.h > > > @@ -0,0 +1,22 @@ > > > +/* SPDX-License-Identifier: GPL-2.0-only */ > > > +/* > > > + * Copyright 2020 Collabora > > > + */ > > > + > > > +#ifndef __SOC_ROCKCHIP_REVISION_H__ > > > +#define __SOC_ROCKCHIP_REVISION_H__ > > > + > > > +enum rk3288_soc_revision { > > > + RK3288_SOC_REV_UNKNOWN, > > > + RK3288_SOC_REV_RK3288, > > > + RK3288_SOC_REV_RK3288W, > > > +}; > > > + > > > +int rk3288_get_revision(void); > > > + > > > +static inline bool soc_is_rk3288w(void) > > > +{ > > > + return rk3288_get_revision() == RK3288_SOC_REV_RK3288W; > > > +} > > > + > > > +#endif /* __SOC_ROCKCHIP_REVISION_H__ */ > > > > > > > > > > > > > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 1/2] ARM: Rockchip: Handle rk3288/rk3288w revision 2020-03-05 0:51 ` Heiko Stübner @ 2020-03-05 11:32 ` Ezequiel Garcia 2020-03-05 11:35 ` Ezequiel Garcia 0 siblings, 1 reply; 15+ messages in thread From: Ezequiel Garcia @ 2020-03-05 11:32 UTC (permalink / raw) To: Heiko Stübner Cc: Mylène Josserand, sboyd, mturquette, linux, linux-rockchip, kernel, linux-clk, linux-arm-kernel On Thu, 2020-03-05 at 01:51 +0100, Heiko Stübner wrote: > Hi Ezequiel, > > Am Donnerstag, 5. März 2020, 01:03:30 CET schrieb Ezequiel Garcia: > > Hi Heiko, > > > > On Wed, 2020-03-04 at 11:59 +0100, Heiko Stübner wrote: > > > Hi, > > > > > > 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 guess you have something like this in mind: > > > > static void __init rk3288_clk_init(struct device_node *np) > > { > > __rk3288_clk_init(np, RK3288_SOC_REV_RK3288W); > > } > > CLK_OF_DECLARE(rk3288_cru, "rockchip,rk3288-cru", rk3288_clk_init); > > > > static void __init rk3288w_clk_init(struct device_node *np) > > { > > __rk3288_clk_init(np, RK3288_SOC_REV_RK3288); > > } > > CLK_OF_DECLARE(rk3288_cru, "rockchip,rk3288w-cru", rk3288w_clk_init); > > > > And the rest is mostly untouched, except the revision is > > no longer queried and is now passed by the DT? > > Essentially yes, but I guess I was more thinking along the lines of > the rk3188/rk3066a/rk3188a (drivers/clk/rockchip/clk-rk3188.c) > > > > This would be cleaner for the kernel, with the obvious > > drawback being that you now have to maintain > > another DTS. > > Right now we would end up with the pretty minimal devicetree > having just that cru. So not very invasive. > > > > This could be an inconvenience. I believe > > RK3288W is meant as a direct replacement for RK3288, > > so folks building products would expect to just use > > RK3288W, and not really bother with passing a > > different DTS or what not. > > Not sure I follow. As below, I don't think boards will magically switch > between soc variants, so a boards devicetree should just include > the variant - especially as I don't really know how many > additional new boards we will see with it (rk3288 being quite old itself). > It's not about new boards, any company does sells some RK32888-based product, will eventually want to produce some more. If I understand correctly, RK3288W is the SoC that Rockchip is now offering, and not RK3288 anymore. So, if you have to produce another batch of _the same RK3288_ product, you'll have to use RK3288W. In other words, they would "just switch" between SoC variants. In fact, such a case motivates these patches :-) > > > > I somehow don't expect boards to just switch between soc variants > > > on the fly. > > > > > > > While I agree they are nasty, quirks like this > > are not uncommon. > > > > > Also, doing things in mach-rockchip is not very future-proof: > > > > > > > There is actually no reason to keep this in mach-rockchip, right? > > > > The quirk could be placed in other places. For instance, > > directly in the clock driver. > > Mapping the hdmi controller inside the clock driver to read some "random" > register that hopefully indicates an (undocumented) distinction between soc > variants. > > Somehow just having that minimal devicetree for the "w" sounds > way cleaner ;-) . > > > It's definitly cool to have support for the rk3288w but I don't like > adding hacks for something that is after all some sort of niche product. > Why do you think it's a niche product? Thanks, Ezequiel > > Heiko > > > > > (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 ;-) > > > (2) I guess the rk3288w will not be the last soc doing this and on arm64 you > > > can't do it that way, as there is no mach-rockchip there > > > > > > So my personal preference would really would be just a specific compatible > > > for affected ip blocks. > > > > > > Heiko > > > > > > > [1]:https://github.com/rockchip-linux/u-boot/blob/f992fe3334aa5090acb448261982628b5a3d37a5/arch/arm/include/asm/arch-rockchip/cpu.h#L30..L34 > > > > > > > > Signed-off-by: Mylène Josserand <mylene.josserand@collabora.com> > > > > --- > > > > arch/arm/mach-rockchip/rockchip.c | 45 +++++++++++++++++++++++++++++++ > > > > include/soc/rockchip/revision.h | 22 +++++++++++++++ > > > > 2 files changed, 67 insertions(+) > > > > create mode 100644 include/soc/rockchip/revision.h > > > > > > > > diff --git a/arch/arm/mach-rockchip/rockchip.c b/arch/arm/mach-rockchip/rockchip.c > > > > index f9797a2b5d0d..b907ba390093 100644 > > > > --- a/arch/arm/mach-rockchip/rockchip.c > > > > +++ b/arch/arm/mach-rockchip/rockchip.c > > > > @@ -9,12 +9,14 @@ > > > > #include <linux/kernel.h> > > > > #include <linux/init.h> > > > > #include <linux/io.h> > > > > +#include <linux/of_address.h> > > > > #include <linux/of_platform.h> > > > > #include <linux/irqchip.h> > > > > #include <linux/clk-provider.h> > > > > #include <linux/clocksource.h> > > > > #include <linux/mfd/syscon.h> > > > > #include <linux/regmap.h> > > > > +#include <soc/rockchip/revision.h> > > > > #include <asm/mach/arch.h> > > > > #include <asm/mach/map.h> > > > > #include <asm/hardware/cache-l2x0.h> > > > > @@ -22,6 +24,49 @@ > > > > #include "pm.h" > > > > > > > > #define RK3288_TIMER6_7_PHYS 0xff810000 > > > > +#define RK3288_HDMI_REV_REG 0x04 > > > > +#define RK3288W_HDMI_REV 0x1A > > > > + > > > > +static const struct of_device_id rk3288_dt_hdmi_match[] __initconst = { > > > > + { .compatible = "rockchip,rk3288-dw-hdmi" }, > > > > + { } > > > > +}; > > > > + > > > > +int rk3288_get_revision(void) > > > > +{ > > > > + static int revision = RK3288_SOC_REV_UNKNOWN; > > > > + struct device_node *dn; > > > > + void __iomem *hdmi_base; > > > > + > > > > + if (revision != RK3288_SOC_REV_UNKNOWN) > > > > + return revision; > > > > + > > > > + dn = of_find_matching_node(NULL, rk3288_dt_hdmi_match); > > > > + if (!dn) { > > > > + pr_err("%s: Couldn't find HDMI node\n", __func__); > > > > + return -EINVAL; > > > > + } > > > > + > > > > + hdmi_base = of_iomap(dn, 0); > > > > + of_node_put(dn); > > > > + > > > > + if (!hdmi_base) { > > > > + pr_err("%s: Couldn't map %pOF regs\n", __func__, > > > > + hdmi_base); > > > > + return -ENXIO; > > > > + } > > > > + > > > > + if (readl_relaxed(hdmi_base + RK3288_HDMI_REV_REG) == > > > > + RK3288W_HDMI_REV) > > > > + revision = RK3288_SOC_REV_RK3288W; > > > > + else > > > > + revision = RK3288_SOC_REV_RK3288; > > > > + > > > > + iounmap(hdmi_base); > > > > + > > > > + return revision; > > > > +} > > > > +EXPORT_SYMBOL(rk3288_get_revision); > > > > > > > > static void __init rockchip_timer_init(void) > > > > { > > > > diff --git a/include/soc/rockchip/revision.h b/include/soc/rockchip/revision.h > > > > new file mode 100644 > > > > index 000000000000..226419c60af0 > > > > --- /dev/null > > > > +++ b/include/soc/rockchip/revision.h > > > > @@ -0,0 +1,22 @@ > > > > +/* SPDX-License-Identifier: GPL-2.0-only */ > > > > +/* > > > > + * Copyright 2020 Collabora > > > > + */ > > > > + > > > > +#ifndef __SOC_ROCKCHIP_REVISION_H__ > > > > +#define __SOC_ROCKCHIP_REVISION_H__ > > > > + > > > > +enum rk3288_soc_revision { > > > > + RK3288_SOC_REV_UNKNOWN, > > > > + RK3288_SOC_REV_RK3288, > > > > + RK3288_SOC_REV_RK3288W, > > > > +}; > > > > + > > > > +int rk3288_get_revision(void); > > > > + > > > > +static inline bool soc_is_rk3288w(void) > > > > +{ > > > > + return rk3288_get_revision() == RK3288_SOC_REV_RK3288W; > > > > +} > > > > + > > > > +#endif /* __SOC_ROCKCHIP_REVISION_H__ */ > > > > > > > > > > > > > > > > > > > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 1/2] ARM: Rockchip: Handle rk3288/rk3288w revision 2020-03-05 11:32 ` Ezequiel Garcia @ 2020-03-05 11:35 ` Ezequiel Garcia 2020-03-06 2:44 ` Kever Yang 0 siblings, 1 reply; 15+ messages in thread From: Ezequiel Garcia @ 2020-03-05 11:35 UTC (permalink / raw) To: Heiko Stübner, kever.yang Cc: Mylène Josserand, sboyd, mturquette, linux, linux-rockchip, kernel, linux-clk, linux-arm-kernel (Adding Kever to the loop) On Thu, 2020-03-05 at 08:32 -0300, Ezequiel Garcia wrote: > On Thu, 2020-03-05 at 01:51 +0100, Heiko Stübner wrote: > > Hi Ezequiel, > > > > Am Donnerstag, 5. März 2020, 01:03:30 CET schrieb Ezequiel Garcia: > > > Hi Heiko, > > > > > > On Wed, 2020-03-04 at 11:59 +0100, Heiko Stübner wrote: > > > > Hi, > > > > > > > > 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 guess you have something like this in mind: > > > > > > static void __init rk3288_clk_init(struct device_node *np) > > > { > > > __rk3288_clk_init(np, RK3288_SOC_REV_RK3288W); > > > } > > > CLK_OF_DECLARE(rk3288_cru, "rockchip,rk3288-cru", rk3288_clk_init); > > > > > > static void __init rk3288w_clk_init(struct device_node *np) > > > { > > > __rk3288_clk_init(np, RK3288_SOC_REV_RK3288); > > > } > > > CLK_OF_DECLARE(rk3288_cru, "rockchip,rk3288w-cru", rk3288w_clk_init); > > > > > > And the rest is mostly untouched, except the revision is > > > no longer queried and is now passed by the DT? > > > > Essentially yes, but I guess I was more thinking along the lines of > > the rk3188/rk3066a/rk3188a (drivers/clk/rockchip/clk-rk3188.c) > > > > > > > This would be cleaner for the kernel, with the obvious > > > drawback being that you now have to maintain > > > another DTS. > > > > Right now we would end up with the pretty minimal devicetree > > having just that cru. So not very invasive. > > > > > > > This could be an inconvenience. I believe > > > RK3288W is meant as a direct replacement for RK3288, > > > so folks building products would expect to just use > > > RK3288W, and not really bother with passing a > > > different DTS or what not. > > > > Not sure I follow. As below, I don't think boards will magically switch > > between soc variants, so a boards devicetree should just include > > the variant - especially as I don't really know how many > > additional new boards we will see with it (rk3288 being quite old itself). > > > > It's not about new boards, any company does sells some RK32888-based product, > will eventually want to produce some more. > > If I understand correctly, RK3288W is the SoC that Rockchip is now offering, > and not RK3288 anymore. > > So, if you have to produce another batch of _the same RK3288_ product, > you'll have to use RK3288W. In other words, they would "just switch" > between SoC variants. > > In fact, such a case motivates these patches :-) > > > > > I somehow don't expect boards to just switch between soc variants > > > > on the fly. > > > > > > > > > > While I agree they are nasty, quirks like this > > > are not uncommon. > > > > > > > Also, doing things in mach-rockchip is not very future-proof: > > > > > > > > > > There is actually no reason to keep this in mach-rockchip, right? > > > > > > The quirk could be placed in other places. For instance, > > > directly in the clock driver. > > > > Mapping the hdmi controller inside the clock driver to read some "random" > > register that hopefully indicates an (undocumented) distinction between soc > > variants. > > > > Somehow just having that minimal devicetree for the "w" sounds > > way cleaner ;-) . > > > > > > It's definitly cool to have support for the rk3288w but I don't like > > adding hacks for something that is after all some sort of niche product. > > > > Why do you think it's a niche product? > > Thanks, > Ezequiel > > > Heiko > > > > > > > > (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 ;-) > > > > (2) I guess the rk3288w will not be the last soc doing this and on arm64 you > > > > can't do it that way, as there is no mach-rockchip there > > > > > > > > So my personal preference would really would be just a specific compatible > > > > for affected ip blocks. > > > > > > > > Heiko > > > > > > > > > [1]:https://github.com/rockchip-linux/u-boot/blob/f992fe3334aa5090acb448261982628b5a3d37a5/arch/arm/include/asm/arch-rockchip/cpu.h#L30..L34 > > > > > > > > > > Signed-off-by: Mylène Josserand <mylene.josserand@collabora.com> > > > > > --- > > > > > arch/arm/mach-rockchip/rockchip.c | 45 +++++++++++++++++++++++++++++++ > > > > > include/soc/rockchip/revision.h | 22 +++++++++++++++ > > > > > 2 files changed, 67 insertions(+) > > > > > create mode 100644 include/soc/rockchip/revision.h > > > > > > > > > > diff --git a/arch/arm/mach-rockchip/rockchip.c b/arch/arm/mach-rockchip/rockchip.c > > > > > index f9797a2b5d0d..b907ba390093 100644 > > > > > --- a/arch/arm/mach-rockchip/rockchip.c > > > > > +++ b/arch/arm/mach-rockchip/rockchip.c > > > > > @@ -9,12 +9,14 @@ > > > > > #include <linux/kernel.h> > > > > > #include <linux/init.h> > > > > > #include <linux/io.h> > > > > > +#include <linux/of_address.h> > > > > > #include <linux/of_platform.h> > > > > > #include <linux/irqchip.h> > > > > > #include <linux/clk-provider.h> > > > > > #include <linux/clocksource.h> > > > > > #include <linux/mfd/syscon.h> > > > > > #include <linux/regmap.h> > > > > > +#include <soc/rockchip/revision.h> > > > > > #include <asm/mach/arch.h> > > > > > #include <asm/mach/map.h> > > > > > #include <asm/hardware/cache-l2x0.h> > > > > > @@ -22,6 +24,49 @@ > > > > > #include "pm.h" > > > > > > > > > > #define RK3288_TIMER6_7_PHYS 0xff810000 > > > > > +#define RK3288_HDMI_REV_REG 0x04 > > > > > +#define RK3288W_HDMI_REV 0x1A > > > > > + > > > > > +static const struct of_device_id rk3288_dt_hdmi_match[] __initconst = { > > > > > + { .compatible = "rockchip,rk3288-dw-hdmi" }, > > > > > + { } > > > > > +}; > > > > > + > > > > > +int rk3288_get_revision(void) > > > > > +{ > > > > > + static int revision = RK3288_SOC_REV_UNKNOWN; > > > > > + struct device_node *dn; > > > > > + void __iomem *hdmi_base; > > > > > + > > > > > + if (revision != RK3288_SOC_REV_UNKNOWN) > > > > > + return revision; > > > > > + > > > > > + dn = of_find_matching_node(NULL, rk3288_dt_hdmi_match); > > > > > + if (!dn) { > > > > > + pr_err("%s: Couldn't find HDMI node\n", __func__); > > > > > + return -EINVAL; > > > > > + } > > > > > + > > > > > + hdmi_base = of_iomap(dn, 0); > > > > > + of_node_put(dn); > > > > > + > > > > > + if (!hdmi_base) { > > > > > + pr_err("%s: Couldn't map %pOF regs\n", __func__, > > > > > + hdmi_base); > > > > > + return -ENXIO; > > > > > + } > > > > > + > > > > > + if (readl_relaxed(hdmi_base + RK3288_HDMI_REV_REG) == > > > > > + RK3288W_HDMI_REV) > > > > > + revision = RK3288_SOC_REV_RK3288W; > > > > > + else > > > > > + revision = RK3288_SOC_REV_RK3288; > > > > > + > > > > > + iounmap(hdmi_base); > > > > > + > > > > > + return revision; > > > > > +} > > > > > +EXPORT_SYMBOL(rk3288_get_revision); > > > > > > > > > > static void __init rockchip_timer_init(void) > > > > > { > > > > > diff --git a/include/soc/rockchip/revision.h b/include/soc/rockchip/revision.h > > > > > new file mode 100644 > > > > > index 000000000000..226419c60af0 > > > > > --- /dev/null > > > > > +++ b/include/soc/rockchip/revision.h > > > > > @@ -0,0 +1,22 @@ > > > > > +/* SPDX-License-Identifier: GPL-2.0-only */ > > > > > +/* > > > > > + * Copyright 2020 Collabora > > > > > + */ > > > > > + > > > > > +#ifndef __SOC_ROCKCHIP_REVISION_H__ > > > > > +#define __SOC_ROCKCHIP_REVISION_H__ > > > > > + > > > > > +enum rk3288_soc_revision { > > > > > + RK3288_SOC_REV_UNKNOWN, > > > > > + RK3288_SOC_REV_RK3288, > > > > > + RK3288_SOC_REV_RK3288W, > > > > > +}; > > > > > + > > > > > +int rk3288_get_revision(void); > > > > > + > > > > > +static inline bool soc_is_rk3288w(void) > > > > > +{ > > > > > + return rk3288_get_revision() == RK3288_SOC_REV_RK3288W; > > > > > +} > > > > > + > > > > > +#endif /* __SOC_ROCKCHIP_REVISION_H__ */ > > > > > > > > > > > > > > > > > > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 1/2] ARM: Rockchip: Handle rk3288/rk3288w revision 2020-03-05 11:35 ` Ezequiel Garcia @ 2020-03-06 2:44 ` Kever Yang 2020-03-06 10:30 ` Ezequiel Garcia 0 siblings, 1 reply; 15+ messages in thread From: Kever Yang @ 2020-03-06 2:44 UTC (permalink / raw) To: Ezequiel Garcia, Heiko Stübner Cc: Mylène Josserand, sboyd, mturquette, linux, linux-rockchip, kernel, linux-clk, linux-arm-kernel Hi Ezequiel, On 2020/3/5 下午7:35, Ezequiel Garcia wrote: > (Adding Kever to the loop) > > On Thu, 2020-03-05 at 08:32 -0300, Ezequiel Garcia wrote: >> On Thu, 2020-03-05 at 01:51 +0100, Heiko Stübner wrote: >>> Hi Ezequiel, >>> >>> Am Donnerstag, 5. März 2020, 01:03:30 CET schrieb Ezequiel Garcia: >>>> Hi Heiko, >>>> >>>> On Wed, 2020-03-04 at 11:59 +0100, Heiko Stübner wrote: >>>>> Hi, >>>>> >>>>> 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 guess you have something like this in mind: >>>> >>>> static void __init rk3288_clk_init(struct device_node *np) >>>> { >>>> __rk3288_clk_init(np, RK3288_SOC_REV_RK3288W); >>>> } >>>> CLK_OF_DECLARE(rk3288_cru, "rockchip,rk3288-cru", rk3288_clk_init); >>>> >>>> static void __init rk3288w_clk_init(struct device_node *np) >>>> { >>>> __rk3288_clk_init(np, RK3288_SOC_REV_RK3288); >>>> } >>>> CLK_OF_DECLARE(rk3288_cru, "rockchip,rk3288w-cru", rk3288w_clk_init); >>>> >>>> And the rest is mostly untouched, except the revision is >>>> no longer queried and is now passed by the DT? >>> Essentially yes, but I guess I was more thinking along the lines of >>> the rk3188/rk3066a/rk3188a (drivers/clk/rockchip/clk-rk3188.c) >>> >>> >>>> This would be cleaner for the kernel, with the obvious >>>> drawback being that you now have to maintain >>>> another DTS. >>> Right now we would end up with the pretty minimal devicetree >>> having just that cru. So not very invasive. >>> >>> >>>> This could be an inconvenience. I believe >>>> RK3288W is meant as a direct replacement for RK3288, >>>> so folks building products would expect to just use >>>> RK3288W, and not really bother with passing a >>>> different DTS or what not. >>> Not sure I follow. As below, I don't think boards will magically switch >>> between soc variants, so a boards devicetree should just include >>> the variant - especially as I don't really know how many >>> additional new boards we will see with it (rk3288 being quite old itself). >>> >> It's not about new boards, any company does sells some RK32888-based product, >> will eventually want to produce some more. >> >> If I understand correctly, RK3288W is the SoC that Rockchip is now offering, >> and not RK3288 anymore. No, the RK3288 will continue to supply to the legacy projects which may have a long contract with Rockchip, and RK3288W is the recommend to use in all new project. >> >> So, if you have to produce another batch of _the same RK3288_ product, >> you'll have to use RK3288W. In other words, they would "just switch" >> between SoC variants. >> >> In fact, such a case motivates these patches :-) >> >>>>> I somehow don't expect boards to just switch between soc variants >>>>> on the fly. >>>>> >>>> While I agree they are nasty, quirks like this >>>> are not uncommon. >>>> >>>>> Also, doing things in mach-rockchip is not very future-proof: >>>>> >>>> There is actually no reason to keep this in mach-rockchip, right? >>>> >>>> The quirk could be placed in other places. For instance, >>>> directly in the clock driver. >>> Mapping the hdmi controller inside the clock driver to read some "random" >>> register that hopefully indicates an (undocumented) distinction between soc >>> variants. >>> >>> Somehow just having that minimal devicetree for the "w" sounds >>> way cleaner ;-) . I agree with Heiko on this. What Rockchip done is: - kernel is using "rockchip,rk3288w" compatible to identify rk3288w, which is clean in kernel; - kernel evb dts do not have compatible "rockchip,rk3288w" for we would like to identify it dynamic in bootloader; - We use U-Boot to identify the rk3288w with HDMI reg value, and pass it to kernel via modify the dtb pass to kernel, so that we can support all kind of rockchip customer projects with any kind of rk3288; - For upstream kernel, it make sense to add "rockchip,rk3288w" in board dts for which using rk3288w SoC. Thanks, - Kever >>> >>> >>> It's definitly cool to have support for the rk3288w but I don't like >>> adding hacks for something that is after all some sort of niche product. >>> >> Why do you think it's a niche product? >> >> Thanks, >> Ezequiel >> >>> Heiko >>> >>> >>>>> (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 ;-) >>>>> (2) I guess the rk3288w will not be the last soc doing this and on arm64 you >>>>> can't do it that way, as there is no mach-rockchip there >>>>> >>>>> So my personal preference would really would be just a specific compatible >>>>> for affected ip blocks. >>>>> >>>>> Heiko >>>>> >>>>>> [1]:https://github.com/rockchip-linux/u-boot/blob/f992fe3334aa5090acb448261982628b5a3d37a5/arch/arm/include/asm/arch-rockchip/cpu.h#L30..L34 >>>>>> >>>>>> Signed-off-by: Mylène Josserand <mylene.josserand@collabora.com> >>>>>> --- >>>>>> arch/arm/mach-rockchip/rockchip.c | 45 +++++++++++++++++++++++++++++++ >>>>>> include/soc/rockchip/revision.h | 22 +++++++++++++++ >>>>>> 2 files changed, 67 insertions(+) >>>>>> create mode 100644 include/soc/rockchip/revision.h >>>>>> >>>>>> diff --git a/arch/arm/mach-rockchip/rockchip.c b/arch/arm/mach-rockchip/rockchip.c >>>>>> index f9797a2b5d0d..b907ba390093 100644 >>>>>> --- a/arch/arm/mach-rockchip/rockchip.c >>>>>> +++ b/arch/arm/mach-rockchip/rockchip.c >>>>>> @@ -9,12 +9,14 @@ >>>>>> #include <linux/kernel.h> >>>>>> #include <linux/init.h> >>>>>> #include <linux/io.h> >>>>>> +#include <linux/of_address.h> >>>>>> #include <linux/of_platform.h> >>>>>> #include <linux/irqchip.h> >>>>>> #include <linux/clk-provider.h> >>>>>> #include <linux/clocksource.h> >>>>>> #include <linux/mfd/syscon.h> >>>>>> #include <linux/regmap.h> >>>>>> +#include <soc/rockchip/revision.h> >>>>>> #include <asm/mach/arch.h> >>>>>> #include <asm/mach/map.h> >>>>>> #include <asm/hardware/cache-l2x0.h> >>>>>> @@ -22,6 +24,49 @@ >>>>>> #include "pm.h" >>>>>> >>>>>> #define RK3288_TIMER6_7_PHYS 0xff810000 >>>>>> +#define RK3288_HDMI_REV_REG 0x04 >>>>>> +#define RK3288W_HDMI_REV 0x1A >>>>>> + >>>>>> +static const struct of_device_id rk3288_dt_hdmi_match[] __initconst = { >>>>>> + { .compatible = "rockchip,rk3288-dw-hdmi" }, >>>>>> + { } >>>>>> +}; >>>>>> + >>>>>> +int rk3288_get_revision(void) >>>>>> +{ >>>>>> + static int revision = RK3288_SOC_REV_UNKNOWN; >>>>>> + struct device_node *dn; >>>>>> + void __iomem *hdmi_base; >>>>>> + >>>>>> + if (revision != RK3288_SOC_REV_UNKNOWN) >>>>>> + return revision; >>>>>> + >>>>>> + dn = of_find_matching_node(NULL, rk3288_dt_hdmi_match); >>>>>> + if (!dn) { >>>>>> + pr_err("%s: Couldn't find HDMI node\n", __func__); >>>>>> + return -EINVAL; >>>>>> + } >>>>>> + >>>>>> + hdmi_base = of_iomap(dn, 0); >>>>>> + of_node_put(dn); >>>>>> + >>>>>> + if (!hdmi_base) { >>>>>> + pr_err("%s: Couldn't map %pOF regs\n", __func__, >>>>>> + hdmi_base); >>>>>> + return -ENXIO; >>>>>> + } >>>>>> + >>>>>> + if (readl_relaxed(hdmi_base + RK3288_HDMI_REV_REG) == >>>>>> + RK3288W_HDMI_REV) >>>>>> + revision = RK3288_SOC_REV_RK3288W; >>>>>> + else >>>>>> + revision = RK3288_SOC_REV_RK3288; >>>>>> + >>>>>> + iounmap(hdmi_base); >>>>>> + >>>>>> + return revision; >>>>>> +} >>>>>> +EXPORT_SYMBOL(rk3288_get_revision); >>>>>> >>>>>> static void __init rockchip_timer_init(void) >>>>>> { >>>>>> diff --git a/include/soc/rockchip/revision.h b/include/soc/rockchip/revision.h >>>>>> new file mode 100644 >>>>>> index 000000000000..226419c60af0 >>>>>> --- /dev/null >>>>>> +++ b/include/soc/rockchip/revision.h >>>>>> @@ -0,0 +1,22 @@ >>>>>> +/* SPDX-License-Identifier: GPL-2.0-only */ >>>>>> +/* >>>>>> + * Copyright 2020 Collabora >>>>>> + */ >>>>>> + >>>>>> +#ifndef __SOC_ROCKCHIP_REVISION_H__ >>>>>> +#define __SOC_ROCKCHIP_REVISION_H__ >>>>>> + >>>>>> +enum rk3288_soc_revision { >>>>>> + RK3288_SOC_REV_UNKNOWN, >>>>>> + RK3288_SOC_REV_RK3288, >>>>>> + RK3288_SOC_REV_RK3288W, >>>>>> +}; >>>>>> + >>>>>> +int rk3288_get_revision(void); >>>>>> + >>>>>> +static inline bool soc_is_rk3288w(void) >>>>>> +{ >>>>>> + return rk3288_get_revision() == RK3288_SOC_REV_RK3288W; >>>>>> +} >>>>>> + >>>>>> +#endif /* __SOC_ROCKCHIP_REVISION_H__ */ >>>>>> >>>>> >>> >> > > > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 1/2] ARM: Rockchip: Handle rk3288/rk3288w revision 2020-03-06 2:44 ` Kever Yang @ 2020-03-06 10:30 ` Ezequiel Garcia 0 siblings, 0 replies; 15+ messages in thread From: Ezequiel Garcia @ 2020-03-06 10:30 UTC (permalink / raw) To: Kever Yang, Heiko Stübner Cc: Mylène Josserand, sboyd, mturquette, linux, linux-rockchip, kernel, linux-clk, linux-arm-kernel On Fri, 2020-03-06 at 10:44 +0800, Kever Yang wrote: > Hi Ezequiel, > > > On 2020/3/5 下午7:35, Ezequiel Garcia wrote: > > (Adding Kever to the loop) > > > > On Thu, 2020-03-05 at 08:32 -0300, Ezequiel Garcia wrote: > > > On Thu, 2020-03-05 at 01:51 +0100, Heiko Stübner wrote: > > > > Hi Ezequiel, > > > > > > > > Am Donnerstag, 5. März 2020, 01:03:30 CET schrieb Ezequiel Garcia: > > > > > Hi Heiko, > > > > > > > > > > On Wed, 2020-03-04 at 11:59 +0100, Heiko Stübner wrote: > > > > > > Hi, > > > > > > > > > > > > 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 guess you have something like this in mind: > > > > > > > > > > static void __init rk3288_clk_init(struct device_node *np) > > > > > { > > > > > __rk3288_clk_init(np, RK3288_SOC_REV_RK3288W); > > > > > } > > > > > CLK_OF_DECLARE(rk3288_cru, "rockchip,rk3288-cru", rk3288_clk_init); > > > > > > > > > > static void __init rk3288w_clk_init(struct device_node *np) > > > > > { > > > > > __rk3288_clk_init(np, RK3288_SOC_REV_RK3288); > > > > > } > > > > > CLK_OF_DECLARE(rk3288_cru, "rockchip,rk3288w-cru", rk3288w_clk_init); > > > > > > > > > > And the rest is mostly untouched, except the revision is > > > > > no longer queried and is now passed by the DT? > > > > Essentially yes, but I guess I was more thinking along the lines of > > > > the rk3188/rk3066a/rk3188a (drivers/clk/rockchip/clk-rk3188.c) > > > > > > > > > > > > > This would be cleaner for the kernel, with the obvious > > > > > drawback being that you now have to maintain > > > > > another DTS. > > > > Right now we would end up with the pretty minimal devicetree > > > > having just that cru. So not very invasive. > > > > > > > > > > > > > This could be an inconvenience. I believe > > > > > RK3288W is meant as a direct replacement for RK3288, > > > > > so folks building products would expect to just use > > > > > RK3288W, and not really bother with passing a > > > > > different DTS or what not. > > > > Not sure I follow. As below, I don't think boards will magically switch > > > > between soc variants, so a boards devicetree should just include > > > > the variant - especially as I don't really know how many > > > > additional new boards we will see with it (rk3288 being quite old itself). > > > > > > > It's not about new boards, any company does sells some RK32888-based product, > > > will eventually want to produce some more. > > > > > > If I understand correctly, RK3288W is the SoC that Rockchip is now offering, > > > and not RK3288 anymore. > > No, the RK3288 will continue to supply to the legacy projects which may > have a long contract with Rockchip, > > and RK3288W is the recommend to use in all new project. > I guess this means that if a company not having a long contract wants to keep producing an RK3288-based product, it will have to resort to RK3288W. And IIRC, it's meant to be a direct replacement. > > > So, if you have to produce another batch of _the same RK3288_ product, > > > you'll have to use RK3288W. In other words, they would "just switch" > > > between SoC variants. > > > > > > In fact, such a case motivates these patches :-) > > > > > > > > > I somehow don't expect boards to just switch between soc variants > > > > > > on the fly. > > > > > > > > > > > While I agree they are nasty, quirks like this > > > > > are not uncommon. > > > > > > > > > > > Also, doing things in mach-rockchip is not very future-proof: > > > > > > > > > > > There is actually no reason to keep this in mach-rockchip, right? > > > > > > > > > > The quirk could be placed in other places. For instance, > > > > > directly in the clock driver. > > > > Mapping the hdmi controller inside the clock driver to read some "random" > > > > register that hopefully indicates an (undocumented) distinction between soc > > > > variants. > > > > > > > > Somehow just having that minimal devicetree for the "w" sounds > > > > way cleaner ;-) . > > I agree with Heiko on this. > > What Rockchip done is: > > - kernel is using "rockchip,rk3288w" compatible to identify rk3288w, > which is clean in kernel; > > - kernel evb dts do not have compatible "rockchip,rk3288w" for we would > like to identify it dynamic in bootloader; > > - We use U-Boot to identify the rk3288w with HDMI reg value, and pass it > to kernel via modify the > > dtb pass to kernel, so that we can support all kind of rockchip > customer projects with any kind of rk3288; > > - For upstream kernel, it make sense to add "rockchip,rk3288w" in board > dts for which using rk3288w SoC. > So you proposing to move this revision detection code from the kernel to all the bootloaders (U-Boot is not the only one, right?). I understand that bootloaders are maybe less strict to quirks like this, but OTOH this approach seems like just movint things around, plus requiring now to update two components, instead of just one. And also, are we sure the bootloaders maintainers will accept the quirk? Thanks, Ezequiel _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 1/2] ARM: Rockchip: Handle rk3288/rk3288w revision 2020-03-04 10:59 ` Heiko Stübner 2020-03-05 0:03 ` Ezequiel Garcia @ 2020-03-06 10:45 ` Geert Uytterhoeven 2020-03-26 13:50 ` Mylene Josserand 1 sibling, 1 reply; 15+ messages in thread From: Geert Uytterhoeven @ 2020-03-06 10:45 UTC (permalink / raw) To: Heiko Stübner Cc: Mylène Josserand, Stephen Boyd, Michael Turquette, Russell King, open list:ARM/Rockchip SoC..., Collabora Kernel ML, linux-clk, Linux ARM Hi Heiko, On Wed, Mar 4, 2020 at 12:00 PM Heiko Stübner <heiko@sntech.de> 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. > (2) I guess the rk3288w will not be the last soc doing this and on arm64 you > can't do it that way, as there is no mach-rockchip there There's drivers/soc/rockchip ;-) > So my personal preference would really would be just a specific compatible > for affected ip blocks. Doing that only for affected IP blocks may miss integration differences. Of course, you can always resort to soc_device_match() to handle those... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 1/2] ARM: Rockchip: Handle rk3288/rk3288w revision 2020-03-06 10:45 ` Geert Uytterhoeven @ 2020-03-26 13:50 ` Mylene Josserand 2020-03-26 15:31 ` Geert Uytterhoeven 0 siblings, 1 reply; 15+ messages in thread From: Mylene Josserand @ 2020-03-26 13:50 UTC (permalink / raw) To: Geert Uytterhoeven, Heiko Stübner Cc: Stephen Boyd, Michael Turquette, Russell King, open list:ARM/Rockchip SoC..., Collabora Kernel ML, linux-clk, Linux ARM Hello everyone, Thank you for all these feedback and discussion about my patches. On 3/6/20 11:45 AM, Geert Uytterhoeven wrote: > Hi Heiko, > > On Wed, Mar 4, 2020 at 12:00 PM Heiko Stübner <heiko@sntech.de> 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 :( > >> (2) I guess the rk3288w will not be the last soc doing this and on arm64 you >> can't do it that way, as there is no mach-rockchip there > > There's drivers/soc/rockchip ;-) > >> So my personal preference would really would be just a specific compatible >> for affected ip blocks. > > Doing that only for affected IP blocks may miss integration differences. > Of course, you can always resort to soc_device_match() to handle those... > > Gr{oetje,eeting}s, > > Geert > It would be a great idea indeed if there was not this clock registration too soon for initcalls. I am currently running out of ideas to propose a better solution than this V1. Is anyone has any recommendation to handle that? I would really appreciate :) Thank you in advance! Best regards, Mylène _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 1/2] ARM: Rockchip: Handle rk3288/rk3288w revision 2020-03-26 13:50 ` Mylene Josserand @ 2020-03-26 15:31 ` Geert Uytterhoeven 2020-03-27 6:20 ` Mylene Josserand 0 siblings, 1 reply; 15+ messages in thread From: Geert Uytterhoeven @ 2020-03-26 15:31 UTC (permalink / raw) To: Mylene Josserand Cc: Heiko Stübner, Stephen Boyd, Michael Turquette, Russell King, open list:ARM/Rockchip SoC..., Collabora Kernel ML, linux-clk, Linux ARM Hi Mylene, On Thu, Mar 26, 2020 at 2:50 PM Mylene Josserand <mylene.josserand@collabora.com> wrote: > On 3/6/20 11:45 AM, Geert Uytterhoeven wrote: > > On Wed, Mar 4, 2020 at 12:00 PM Heiko Stübner <heiko@sntech.de> 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 -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 1/2] ARM: Rockchip: Handle rk3288/rk3288w revision 2020-03-26 15:31 ` Geert Uytterhoeven @ 2020-03-27 6:20 ` Mylene Josserand 0 siblings, 0 replies; 15+ messages in thread From: Mylene Josserand @ 2020-03-27 6:20 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Heiko Stübner, Stephen Boyd, Michael Turquette, Russell King, open list:ARM/Rockchip SoC..., Collabora Kernel ML, linux-clk, Linux ARM 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@collabora.com> wrote: >> On 3/6/20 11:45 AM, Geert Uytterhoeven wrote: >>> On Wed, Mar 4, 2020 at 12:00 PM Heiko Stübner <heiko@sntech.de> 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-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH 2/2] clk: rockchip: rk3288: Handle clock tree for rk3288w 2020-03-02 15:57 [PATCH 0/2] ARM: Add Rockchip rk3288w support Mylène Josserand 2020-03-02 15:57 ` [PATCH 1/2] ARM: Rockchip: Handle rk3288/rk3288w revision Mylène Josserand @ 2020-03-02 15:57 ` Mylène Josserand 2020-03-04 5:34 ` kbuild test robot 1 sibling, 1 reply; 15+ messages in thread From: Mylène Josserand @ 2020-03-02 15:57 UTC (permalink / raw) To: linux, heiko, mturquette, sboyd Cc: mylene.josserand, kernel, linux-clk, linux-arm-kernel, linux-rockchip The revision rk3288w has a different clock tree about "hclk_vio" clock, according to the BSP kernel code [1]. This patch handles this difference by detecting which SOC it is and creating the div accordingly. [1]: https://github.com/rockchip-linux/kernel/blob/develop-4.4/drivers/clk/rockchip/clk-rk3288.c#L960..L964 Signed-off-by: Mylène Josserand <mylene.josserand@collabora.com> --- drivers/clk/rockchip/clk-rk3288.c | 21 +++++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/drivers/clk/rockchip/clk-rk3288.c b/drivers/clk/rockchip/clk-rk3288.c index cc2a177bbdbf..e7d6e3a095a5 100644 --- a/drivers/clk/rockchip/clk-rk3288.c +++ b/drivers/clk/rockchip/clk-rk3288.c @@ -10,6 +10,7 @@ #include <linux/of_address.h> #include <linux/syscore_ops.h> #include <dt-bindings/clock/rk3288-cru.h> +#include <soc/rockchip/revision.h> #include "clk.h" #define RK3288_GRF_SOC_CON(x) (0x244 + x * 4) @@ -425,8 +426,6 @@ static struct rockchip_clk_branch rk3288_clk_branches[] __initdata = { COMPOSITE(0, "aclk_vio0", mux_pll_src_cpll_gpll_usb480m_p, CLK_IGNORE_UNUSED, RK3288_CLKSEL_CON(31), 6, 2, MFLAGS, 0, 5, DFLAGS, RK3288_CLKGATE_CON(3), 0, GFLAGS), - DIV(0, "hclk_vio", "aclk_vio0", 0, - RK3288_CLKSEL_CON(28), 8, 5, DFLAGS), COMPOSITE(0, "aclk_vio1", mux_pll_src_cpll_gpll_usb480m_p, CLK_IGNORE_UNUSED, RK3288_CLKSEL_CON(31), 14, 2, MFLAGS, 8, 5, DFLAGS, RK3288_CLKGATE_CON(3), 2, GFLAGS), @@ -819,6 +818,16 @@ static struct rockchip_clk_branch rk3288_clk_branches[] __initdata = { INVERTER(0, "pclk_isp", "pclk_isp_in", RK3288_CLKSEL_CON(29), 3, IFLAGS), }; +static struct rockchip_clk_branch rk3288w_hclkvio_branch[] __initdata = { + DIV(0, "hclk_vio", "aclk_vio1", 0, + RK3288_CLKSEL_CON(28), 8, 5, DFLAGS), +}; + +static struct rockchip_clk_branch rk3288_hclkvio_branch[] __initdata = { + DIV(0, "hclk_vio", "aclk_vio0", 0, + RK3288_CLKSEL_CON(28), 8, 5, DFLAGS), +}; + static const char *const rk3288_critical_clocks[] __initconst = { "aclk_cpu", "aclk_peri", @@ -931,6 +940,14 @@ static void __init rk3288_clk_init(struct device_node *np) return; } + /* Check for the rk3288w revision as Clock tree is different */ + if (soc_is_rk3288w()) + rockchip_clk_register_branches(ctx, rk3288w_hclkvio_branch, + ARRAY_SIZE(rk3288w_hclkvio_branch)); + else + rockchip_clk_register_branches(ctx, rk3288_hclkvio_branch, + ARRAY_SIZE(rk3288_hclkvio_branch)); + rockchip_clk_register_plls(ctx, rk3288_pll_clks, ARRAY_SIZE(rk3288_pll_clks), RK3288_GRF_SOC_STATUS1); -- 2.25.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: [PATCH 2/2] clk: rockchip: rk3288: Handle clock tree for rk3288w 2020-03-02 15:57 ` [PATCH 2/2] clk: rockchip: rk3288: Handle clock tree for rk3288w Mylène Josserand @ 2020-03-04 5:34 ` kbuild test robot 0 siblings, 0 replies; 15+ messages in thread From: kbuild test robot @ 2020-03-04 5:34 UTC (permalink / raw) To: Mylène Josserand Cc: mylene.josserand, kbuild-all, heiko, linux-rockchip, sboyd, mturquette, linux, clang-built-linux, kernel, linux-clk, linux-arm-kernel [-- Attachment #1: Type: text/plain, Size: 1198 bytes --] Hi "Mylène, Thank you for the patch! Yet something to improve: [auto build test ERROR on v5.6-rc4] [cannot apply to rockchip/for-next next-20200303] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see https://stackoverflow.com/a/37406982] url: https://github.com/0day-ci/linux/commits/Myl-ne-Josserand/ARM-Add-Rockchip-rk3288w-support/20200303-034350 base: 98d54f81e36ba3bf92172791eba5ca5bd813989b config: arm64-defconfig (attached as .config) compiler: clang version 11.0.0 (git://gitmirror/llvm_project 211fb91f1067ecdf7c0b8a019bcf76554d813129) reproduce: # FIXME the reproduce steps for clang is not ready yet If you fix the issue, kindly add following tag Reported-by: kbuild test robot <lkp@intel.com> All errors (new ones prefixed by >>): aarch64-linux-gnu-ld: drivers/clk/rockchip/clk-rk3288.o: in function `rk3288_clk_init': >> clk-rk3288.c:(.init.text+0x44): undefined reference to `rk3288_get_revision' --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org [-- Attachment #2: .config.gz --] [-- Type: application/gzip, Size: 47088 bytes --] [-- Attachment #3: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2020-03-27 6:20 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-03-02 15:57 [PATCH 0/2] ARM: Add Rockchip rk3288w support Mylène Josserand 2020-03-02 15:57 ` [PATCH 1/2] ARM: Rockchip: Handle rk3288/rk3288w revision Mylène Josserand 2020-03-04 10:59 ` Heiko Stübner 2020-03-05 0:03 ` Ezequiel Garcia 2020-03-05 0:51 ` Heiko Stübner 2020-03-05 11:32 ` Ezequiel Garcia 2020-03-05 11:35 ` Ezequiel Garcia 2020-03-06 2:44 ` Kever Yang 2020-03-06 10:30 ` Ezequiel Garcia 2020-03-06 10:45 ` Geert Uytterhoeven 2020-03-26 13:50 ` Mylene Josserand 2020-03-26 15:31 ` Geert Uytterhoeven 2020-03-27 6:20 ` Mylene Josserand 2020-03-02 15:57 ` [PATCH 2/2] clk: rockchip: rk3288: Handle clock tree for rk3288w Mylène Josserand 2020-03-04 5:34 ` kbuild test robot
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).