* [PATCH v2] ARM: dts: i.MX8MM: describe feature controller @ 2022-08-30 7:50 Ahmad Fatoum 2022-08-30 8:10 ` Marco Felsch 2022-08-31 6:41 ` Sascha Hauer 0 siblings, 2 replies; 6+ messages in thread From: Ahmad Fatoum @ 2022-08-30 7:50 UTC (permalink / raw) To: barebox; +Cc: Ahmad Fatoum Now with i.MX8M feature controller driver support available, have the OCOTP provide feature control on the i.MX8MM to ensure the kernel DT does not cause Linux to access the VPU and its power domains, when barebox knows them to be unavailable. This is needed because the upstream kernel imx8mm.dtsi only describes the full-featured SoC, which can lead to hangs when instantiating drivers for hardware that's unavailable in a less-featureful variant of the SoC. Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> --- v1 was RFC patch 10/10 of: https://lore.barebox.org/barebox/20220818051955.2088238-11-a.fatoum@pengutronix.de/T/#u Patches 01-08 are still applicable, this replaces the approach in v1 with a standalone feature controller with having the OCOTP as feature controller, like is done for i.MX8MN in patch 08/10 of above referenced series. --- arch/arm/dts/imx8mm.dtsi | 52 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 52 insertions(+) diff --git a/arch/arm/dts/imx8mm.dtsi b/arch/arm/dts/imx8mm.dtsi index cdf212820594..1e81d03d6b84 100644 --- a/arch/arm/dts/imx8mm.dtsi +++ b/arch/arm/dts/imx8mm.dtsi @@ -1,10 +1,18 @@ // SPDX-License-Identifier: (GPL-2.0+ OR MIT) + +#include <dt-bindings/features/imx8m.h> + / { aliases { gpr.reboot_mode = &reboot_mode_gpr; }; }; +feat: &ocotp { + #feature-cells = <1>; + barebox,feature-controller; +}; + &pgc_otg1 { barebox,allow-dummy; }; @@ -24,3 +32,47 @@ mode-serial = <0x00000010>, <0x40000000>; }; }; + +&A53_1 { + barebox,feature-gates = <&feat IMX8M_FEAT_CPU_DUAL>; +}; + +&A53_2 { + barebox,feature-gates = <&feat IMX8M_FEAT_CPU_QUAD>; +}; + +&A53_3 { + barebox,feature-gates = <&feat IMX8M_FEAT_CPU_QUAD>; +}; + +&gpc { + barebox,feature-gates = <&feat 0>; +}; + +&vpu_g1 { + barebox,feature-gates = <&feat IMX8M_FEAT_VPU>; +}; + +&vpu_g2 { + barebox,feature-gates = <&feat IMX8M_FEAT_VPU>; +}; + +&vpu_blk_ctrl { + barebox,feature-gates = <&feat IMX8M_FEAT_VPU>; +}; + +&pgc_vpumix { + barebox,feature-gates = <&feat IMX8M_FEAT_VPU>; +}; + +&pgc_vpu_g1 { + barebox,feature-gates = <&feat IMX8M_FEAT_VPU>; +}; + +&pgc_vpu_g2 { + barebox,feature-gates = <&feat IMX8M_FEAT_VPU>; +}; + +&pgc_vpu_h1 { + barebox,feature-gates = <&feat IMX8M_FEAT_VPU>; +}; -- 2.30.2 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] ARM: dts: i.MX8MM: describe feature controller 2022-08-30 7:50 [PATCH v2] ARM: dts: i.MX8MM: describe feature controller Ahmad Fatoum @ 2022-08-30 8:10 ` Marco Felsch 2022-08-30 8:19 ` Ahmad Fatoum 2022-08-31 6:41 ` Sascha Hauer 1 sibling, 1 reply; 6+ messages in thread From: Marco Felsch @ 2022-08-30 8:10 UTC (permalink / raw) To: Ahmad Fatoum; +Cc: barebox Hi Ahamd, On 22-08-30, Ahmad Fatoum wrote: > Now with i.MX8M feature controller driver support available, have the > OCOTP provide feature control on the i.MX8MM to ensure the kernel DT > does not cause Linux to access the VPU and its power domains, > when barebox knows them to be unavailable. > > This is needed because the upstream kernel imx8mm.dtsi only > describes the full-featured SoC, which can lead to hangs when > instantiating drivers for hardware that's unavailable in a > less-featureful variant of the SoC. > > Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> > --- > v1 was RFC patch 10/10 of: > https://lore.barebox.org/barebox/20220818051955.2088238-11-a.fatoum@pengutronix.de/T/#u > > Patches 01-08 are still applicable, this replaces the approach in v1 > with a standalone feature controller with having the OCOTP as feature > controller, like is done for i.MX8MN in patch 08/10 of above referenced > series. > --- > arch/arm/dts/imx8mm.dtsi | 52 ++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 52 insertions(+) > > diff --git a/arch/arm/dts/imx8mm.dtsi b/arch/arm/dts/imx8mm.dtsi > index cdf212820594..1e81d03d6b84 100644 > --- a/arch/arm/dts/imx8mm.dtsi > +++ b/arch/arm/dts/imx8mm.dtsi > @@ -1,10 +1,18 @@ > // SPDX-License-Identifier: (GPL-2.0+ OR MIT) > + > +#include <dt-bindings/features/imx8m.h> > + > / { > aliases { > gpr.reboot_mode = &reboot_mode_gpr; > }; > }; > > +feat: &ocotp { > + #feature-cells = <1>; > + barebox,feature-controller; > +}; Why not just appending the node like: / { aliases { gpr.reboot_mode = &reboot_mode_gpr; }; feat: ocotp { #feature-cells = <1>; barebox,feature-controller; }; }; Regards, Marco > + > &pgc_otg1 { > barebox,allow-dummy; > }; > @@ -24,3 +32,47 @@ > mode-serial = <0x00000010>, <0x40000000>; > }; > }; > + > +&A53_1 { > + barebox,feature-gates = <&feat IMX8M_FEAT_CPU_DUAL>; > +}; > + > +&A53_2 { > + barebox,feature-gates = <&feat IMX8M_FEAT_CPU_QUAD>; > +}; > + > +&A53_3 { > + barebox,feature-gates = <&feat IMX8M_FEAT_CPU_QUAD>; > +}; > + > +&gpc { > + barebox,feature-gates = <&feat 0>; > +}; > + > +&vpu_g1 { > + barebox,feature-gates = <&feat IMX8M_FEAT_VPU>; > +}; > + > +&vpu_g2 { > + barebox,feature-gates = <&feat IMX8M_FEAT_VPU>; > +}; > + > +&vpu_blk_ctrl { > + barebox,feature-gates = <&feat IMX8M_FEAT_VPU>; > +}; > + > +&pgc_vpumix { > + barebox,feature-gates = <&feat IMX8M_FEAT_VPU>; > +}; > + > +&pgc_vpu_g1 { > + barebox,feature-gates = <&feat IMX8M_FEAT_VPU>; > +}; > + > +&pgc_vpu_g2 { > + barebox,feature-gates = <&feat IMX8M_FEAT_VPU>; > +}; > + > +&pgc_vpu_h1 { > + barebox,feature-gates = <&feat IMX8M_FEAT_VPU>; > +}; > -- > 2.30.2 > > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] ARM: dts: i.MX8MM: describe feature controller 2022-08-30 8:10 ` Marco Felsch @ 2022-08-30 8:19 ` Ahmad Fatoum 2022-08-30 8:29 ` Marco Felsch 0 siblings, 1 reply; 6+ messages in thread From: Ahmad Fatoum @ 2022-08-30 8:19 UTC (permalink / raw) To: Marco Felsch; +Cc: barebox Hello Marco, On 30.08.22 10:10, Marco Felsch wrote: > Hi Ahamd, > > On 22-08-30, Ahmad Fatoum wrote: >> Now with i.MX8M feature controller driver support available, have the >> OCOTP provide feature control on the i.MX8MM to ensure the kernel DT >> does not cause Linux to access the VPU and its power domains, >> when barebox knows them to be unavailable. >> >> This is needed because the upstream kernel imx8mm.dtsi only >> describes the full-featured SoC, which can lead to hangs when >> instantiating drivers for hardware that's unavailable in a >> less-featureful variant of the SoC. >> >> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> >> --- >> v1 was RFC patch 10/10 of: >> https://lore.barebox.org/barebox/20220818051955.2088238-11-a.fatoum@pengutronix.de/T/#u >> >> Patches 01-08 are still applicable, this replaces the approach in v1 >> with a standalone feature controller with having the OCOTP as feature >> controller, like is done for i.MX8MN in patch 08/10 of above referenced >> series. >> --- >> arch/arm/dts/imx8mm.dtsi | 52 ++++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 52 insertions(+) >> >> diff --git a/arch/arm/dts/imx8mm.dtsi b/arch/arm/dts/imx8mm.dtsi >> index cdf212820594..1e81d03d6b84 100644 >> --- a/arch/arm/dts/imx8mm.dtsi >> +++ b/arch/arm/dts/imx8mm.dtsi >> @@ -1,10 +1,18 @@ >> // SPDX-License-Identifier: (GPL-2.0+ OR MIT) >> + >> +#include <dt-bindings/features/imx8m.h> >> + >> / { >> aliases { >> gpr.reboot_mode = &reboot_mode_gpr; >> }; >> }; >> >> +feat: &ocotp { >> + #feature-cells = <1>; >> + barebox,feature-controller; >> +}; > > Why not just appending the node like: > > / { > aliases { > gpr.reboot_mode = &reboot_mode_gpr; > }; > > feat: ocotp { > #feature-cells = <1>; > barebox,feature-controller; > }; > }; Yours adds a new /ocotp node while my patch gives the existing node pointed at by &ocotp an additional label and extends it. I prefer the additional label, because it gives us flexibility in future if upstream decides that there should be a dedicated feature controller. In that case we would only need to move the label instead of touching all references. see RFC patch 10/10 referenced above. Cheers, Ahmad > > Regards, > Marco > >> + >> &pgc_otg1 { >> barebox,allow-dummy; >> }; >> @@ -24,3 +32,47 @@ >> mode-serial = <0x00000010>, <0x40000000>; >> }; >> }; >> + >> +&A53_1 { >> + barebox,feature-gates = <&feat IMX8M_FEAT_CPU_DUAL>; >> +}; >> + >> +&A53_2 { >> + barebox,feature-gates = <&feat IMX8M_FEAT_CPU_QUAD>; >> +}; >> + >> +&A53_3 { >> + barebox,feature-gates = <&feat IMX8M_FEAT_CPU_QUAD>; >> +}; >> + >> +&gpc { >> + barebox,feature-gates = <&feat 0>; >> +}; >> + >> +&vpu_g1 { >> + barebox,feature-gates = <&feat IMX8M_FEAT_VPU>; >> +}; >> + >> +&vpu_g2 { >> + barebox,feature-gates = <&feat IMX8M_FEAT_VPU>; >> +}; >> + >> +&vpu_blk_ctrl { >> + barebox,feature-gates = <&feat IMX8M_FEAT_VPU>; >> +}; >> + >> +&pgc_vpumix { >> + barebox,feature-gates = <&feat IMX8M_FEAT_VPU>; >> +}; >> + >> +&pgc_vpu_g1 { >> + barebox,feature-gates = <&feat IMX8M_FEAT_VPU>; >> +}; >> + >> +&pgc_vpu_g2 { >> + barebox,feature-gates = <&feat IMX8M_FEAT_VPU>; >> +}; >> + >> +&pgc_vpu_h1 { >> + barebox,feature-gates = <&feat IMX8M_FEAT_VPU>; >> +}; >> -- >> 2.30.2 >> >> >> > -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] ARM: dts: i.MX8MM: describe feature controller 2022-08-30 8:19 ` Ahmad Fatoum @ 2022-08-30 8:29 ` Marco Felsch 2022-08-30 9:01 ` Ahmad Fatoum 0 siblings, 1 reply; 6+ messages in thread From: Marco Felsch @ 2022-08-30 8:29 UTC (permalink / raw) To: Ahmad Fatoum; +Cc: barebox On 22-08-30, Ahmad Fatoum wrote: > Hello Marco, > > On 30.08.22 10:10, Marco Felsch wrote: > > Hi Ahamd, > > > > On 22-08-30, Ahmad Fatoum wrote: > >> Now with i.MX8M feature controller driver support available, have the > >> OCOTP provide feature control on the i.MX8MM to ensure the kernel DT > >> does not cause Linux to access the VPU and its power domains, > >> when barebox knows them to be unavailable. > >> > >> This is needed because the upstream kernel imx8mm.dtsi only > >> describes the full-featured SoC, which can lead to hangs when > >> instantiating drivers for hardware that's unavailable in a > >> less-featureful variant of the SoC. > >> > >> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> > >> --- > >> v1 was RFC patch 10/10 of: > >> https://lore.barebox.org/barebox/20220818051955.2088238-11-a.fatoum@pengutronix.de/T/#u > >> > >> Patches 01-08 are still applicable, this replaces the approach in v1 > >> with a standalone feature controller with having the OCOTP as feature > >> controller, like is done for i.MX8MN in patch 08/10 of above referenced > >> series. > >> --- > >> arch/arm/dts/imx8mm.dtsi | 52 ++++++++++++++++++++++++++++++++++++++++ > >> 1 file changed, 52 insertions(+) > >> > >> diff --git a/arch/arm/dts/imx8mm.dtsi b/arch/arm/dts/imx8mm.dtsi > >> index cdf212820594..1e81d03d6b84 100644 > >> --- a/arch/arm/dts/imx8mm.dtsi > >> +++ b/arch/arm/dts/imx8mm.dtsi > >> @@ -1,10 +1,18 @@ > >> // SPDX-License-Identifier: (GPL-2.0+ OR MIT) > >> + > >> +#include <dt-bindings/features/imx8m.h> > >> + > >> / { > >> aliases { > >> gpr.reboot_mode = &reboot_mode_gpr; > >> }; > >> }; > >> > >> +feat: &ocotp { > >> + #feature-cells = <1>; > >> + barebox,feature-controller; > >> +}; > > > > Why not just appending the node like: > > > > / { > > aliases { > > gpr.reboot_mode = &reboot_mode_gpr; > > }; > > > > feat: ocotp { > > #feature-cells = <1>; > > barebox,feature-controller; > > }; > > }; > > Yours adds a new /ocotp node while my patch gives the existing > node pointed at by &ocotp an additional label and extends it. This should extend the ocotp node as well or would it be a new node due to the new label? To me it locked very strange, therefore I asked. I never noticed that: "new_label: &old_label {}" is even possible. Regards, Marco > I prefer the additional label, because it gives us flexibility > in future if upstream decides that there should be a dedicated > feature controller. In that case we would only need to move > the label instead of touching all references. see RFC patch 10/10 > referenced above. > > Cheers, > Ahmad > > > > > Regards, > > Marco > > > >> + > >> &pgc_otg1 { > >> barebox,allow-dummy; > >> }; > >> @@ -24,3 +32,47 @@ > >> mode-serial = <0x00000010>, <0x40000000>; > >> }; > >> }; > >> + > >> +&A53_1 { > >> + barebox,feature-gates = <&feat IMX8M_FEAT_CPU_DUAL>; > >> +}; > >> + > >> +&A53_2 { > >> + barebox,feature-gates = <&feat IMX8M_FEAT_CPU_QUAD>; > >> +}; > >> + > >> +&A53_3 { > >> + barebox,feature-gates = <&feat IMX8M_FEAT_CPU_QUAD>; > >> +}; > >> + > >> +&gpc { > >> + barebox,feature-gates = <&feat 0>; > >> +}; > >> + > >> +&vpu_g1 { > >> + barebox,feature-gates = <&feat IMX8M_FEAT_VPU>; > >> +}; > >> + > >> +&vpu_g2 { > >> + barebox,feature-gates = <&feat IMX8M_FEAT_VPU>; > >> +}; > >> + > >> +&vpu_blk_ctrl { > >> + barebox,feature-gates = <&feat IMX8M_FEAT_VPU>; > >> +}; > >> + > >> +&pgc_vpumix { > >> + barebox,feature-gates = <&feat IMX8M_FEAT_VPU>; > >> +}; > >> + > >> +&pgc_vpu_g1 { > >> + barebox,feature-gates = <&feat IMX8M_FEAT_VPU>; > >> +}; > >> + > >> +&pgc_vpu_g2 { > >> + barebox,feature-gates = <&feat IMX8M_FEAT_VPU>; > >> +}; > >> + > >> +&pgc_vpu_h1 { > >> + barebox,feature-gates = <&feat IMX8M_FEAT_VPU>; > >> +}; > >> -- > >> 2.30.2 > >> > >> > >> > > > > > -- > Pengutronix e.K. | | > Steuerwalder Str. 21 | http://www.pengutronix.de/ | > 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] ARM: dts: i.MX8MM: describe feature controller 2022-08-30 8:29 ` Marco Felsch @ 2022-08-30 9:01 ` Ahmad Fatoum 0 siblings, 0 replies; 6+ messages in thread From: Ahmad Fatoum @ 2022-08-30 9:01 UTC (permalink / raw) To: Marco Felsch; +Cc: barebox On 30.08.22 10:29, Marco Felsch wrote: > On 22-08-30, Ahmad Fatoum wrote: >> Hello Marco, >> >> On 30.08.22 10:10, Marco Felsch wrote: >>> Hi Ahamd, >>> >>> On 22-08-30, Ahmad Fatoum wrote: >>>> Now with i.MX8M feature controller driver support available, have the >>>> OCOTP provide feature control on the i.MX8MM to ensure the kernel DT >>>> does not cause Linux to access the VPU and its power domains, >>>> when barebox knows them to be unavailable. >>>> >>>> This is needed because the upstream kernel imx8mm.dtsi only >>>> describes the full-featured SoC, which can lead to hangs when >>>> instantiating drivers for hardware that's unavailable in a >>>> less-featureful variant of the SoC. >>>> >>>> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> >>>> --- >>>> v1 was RFC patch 10/10 of: >>>> https://lore.barebox.org/barebox/20220818051955.2088238-11-a.fatoum@pengutronix.de/T/#u >>>> >>>> Patches 01-08 are still applicable, this replaces the approach in v1 >>>> with a standalone feature controller with having the OCOTP as feature >>>> controller, like is done for i.MX8MN in patch 08/10 of above referenced >>>> series. >>>> --- >>>> arch/arm/dts/imx8mm.dtsi | 52 ++++++++++++++++++++++++++++++++++++++++ >>>> 1 file changed, 52 insertions(+) >>>> >>>> diff --git a/arch/arm/dts/imx8mm.dtsi b/arch/arm/dts/imx8mm.dtsi >>>> index cdf212820594..1e81d03d6b84 100644 >>>> --- a/arch/arm/dts/imx8mm.dtsi >>>> +++ b/arch/arm/dts/imx8mm.dtsi >>>> @@ -1,10 +1,18 @@ >>>> // SPDX-License-Identifier: (GPL-2.0+ OR MIT) >>>> + >>>> +#include <dt-bindings/features/imx8m.h> >>>> + >>>> / { >>>> aliases { >>>> gpr.reboot_mode = &reboot_mode_gpr; >>>> }; >>>> }; >>>> >>>> +feat: &ocotp { >>>> + #feature-cells = <1>; >>>> + barebox,feature-controller; >>>> +}; >>> >>> Why not just appending the node like: >>> >>> / { >>> aliases { >>> gpr.reboot_mode = &reboot_mode_gpr; >>> }; >>> >>> feat: ocotp { >>> #feature-cells = <1>; >>> barebox,feature-controller; >>> }; >>> }; >> >> Yours adds a new /ocotp node while my patch gives the existing >> node pointed at by &ocotp an additional label and extends it. > > This should extend the ocotp node as well or would it be a new node > due to the new label? To me it locked very strange, therefore I asked. I > never noticed that: "new_label: &old_label {}" is even possible. It would be a new node, because the ocotp isn't at top level, but instead at /soc@0/bus@30000000/efuse@30350000. Instead of using the full path, I used the &ocotp label and instead of using &ocotp everywhere, I add an additional &feat alias to better convey that the ocotp acts as a feature controller. I intend to upstream this and will likely just use the ocotp label directly then, but having the &feat label here for now allows easily trying out other providers as mentioned in my previous mail. Cheers, Ahmad > > Regards, > Marco > >> I prefer the additional label, because it gives us flexibility >> in future if upstream decides that there should be a dedicated >> feature controller. In that case we would only need to move >> the label instead of touching all references. see RFC patch 10/10 >> referenced above. >> >> Cheers, >> Ahmad >> >>> >>> Regards, >>> Marco >>> >>>> + >>>> &pgc_otg1 { >>>> barebox,allow-dummy; >>>> }; >>>> @@ -24,3 +32,47 @@ >>>> mode-serial = <0x00000010>, <0x40000000>; >>>> }; >>>> }; >>>> + >>>> +&A53_1 { >>>> + barebox,feature-gates = <&feat IMX8M_FEAT_CPU_DUAL>; >>>> +}; >>>> + >>>> +&A53_2 { >>>> + barebox,feature-gates = <&feat IMX8M_FEAT_CPU_QUAD>; >>>> +}; >>>> + >>>> +&A53_3 { >>>> + barebox,feature-gates = <&feat IMX8M_FEAT_CPU_QUAD>; >>>> +}; >>>> + >>>> +&gpc { >>>> + barebox,feature-gates = <&feat 0>; >>>> +}; >>>> + >>>> +&vpu_g1 { >>>> + barebox,feature-gates = <&feat IMX8M_FEAT_VPU>; >>>> +}; >>>> + >>>> +&vpu_g2 { >>>> + barebox,feature-gates = <&feat IMX8M_FEAT_VPU>; >>>> +}; >>>> + >>>> +&vpu_blk_ctrl { >>>> + barebox,feature-gates = <&feat IMX8M_FEAT_VPU>; >>>> +}; >>>> + >>>> +&pgc_vpumix { >>>> + barebox,feature-gates = <&feat IMX8M_FEAT_VPU>; >>>> +}; >>>> + >>>> +&pgc_vpu_g1 { >>>> + barebox,feature-gates = <&feat IMX8M_FEAT_VPU>; >>>> +}; >>>> + >>>> +&pgc_vpu_g2 { >>>> + barebox,feature-gates = <&feat IMX8M_FEAT_VPU>; >>>> +}; >>>> + >>>> +&pgc_vpu_h1 { >>>> + barebox,feature-gates = <&feat IMX8M_FEAT_VPU>; >>>> +}; >>>> -- >>>> 2.30.2 >>>> >>>> >>>> >>> >> >> >> -- >> Pengutronix e.K. | | >> Steuerwalder Str. 21 | http://www.pengutronix.de/ | >> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | >> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | >> > -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] ARM: dts: i.MX8MM: describe feature controller 2022-08-30 7:50 [PATCH v2] ARM: dts: i.MX8MM: describe feature controller Ahmad Fatoum 2022-08-30 8:10 ` Marco Felsch @ 2022-08-31 6:41 ` Sascha Hauer 1 sibling, 0 replies; 6+ messages in thread From: Sascha Hauer @ 2022-08-31 6:41 UTC (permalink / raw) To: Ahmad Fatoum; +Cc: barebox On Tue, Aug 30, 2022 at 09:50:45AM +0200, Ahmad Fatoum wrote: > Now with i.MX8M feature controller driver support available, have the > OCOTP provide feature control on the i.MX8MM to ensure the kernel DT > does not cause Linux to access the VPU and its power domains, > when barebox knows them to be unavailable. > > This is needed because the upstream kernel imx8mm.dtsi only > describes the full-featured SoC, which can lead to hangs when > instantiating drivers for hardware that's unavailable in a > less-featureful variant of the SoC. > > Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> > --- > v1 was RFC patch 10/10 of: > https://lore.barebox.org/barebox/20220818051955.2088238-11-a.fatoum@pengutronix.de/T/#u > > Patches 01-08 are still applicable, this replaces the approach in v1 > with a standalone feature controller with having the OCOTP as feature > controller, like is done for i.MX8MN in patch 08/10 of above referenced > series. > --- > arch/arm/dts/imx8mm.dtsi | 52 ++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 52 insertions(+) Applied, thanks Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-08-31 6:42 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-08-30 7:50 [PATCH v2] ARM: dts: i.MX8MM: describe feature controller Ahmad Fatoum 2022-08-30 8:10 ` Marco Felsch 2022-08-30 8:19 ` Ahmad Fatoum 2022-08-30 8:29 ` Marco Felsch 2022-08-30 9:01 ` Ahmad Fatoum 2022-08-31 6:41 ` Sascha Hauer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox