| Message ID | 1468095718-18515-1-git-send-email-hdegoede@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Sat, Jul 09, 2016 at 10:21:55PM +0200, Hans de Goede wrote: > There is a new Orange Pi PC Plus available now, rather then adding > yet another dts file for this variant, extend the existing > Orange Pi PC to support the sdio wifi and emmc found on this variant. > > Downside of this approach is the following messages in dmesg when run > on the non Plus Orange Pi PC: > > sunxi-mmc 1c10000.mmc: fatal err update clk timeout > sunxi-mmc 1c11000.mmc: smc 2 err, cmd 8, RTO !! > sunxi-mmc 1c11000.mmc: smc 2 err, cmd 55, RTO !! > sunxi-mmc 1c11000.mmc: smc 2 err, cmd 55, RTO !! > sunxi-mmc 1c11000.mmc: smc 2 err, cmd 55, RTO !! > sunxi-mmc 1c11000.mmc: smc 2 err, cmd 55, RTO !! > sunxi-mmc 1c11000.mmc: smc 2 err, cmd 1, RTO !! > > Note these are completely harmless and there is no adverse effect > to the functioning of the non Plus Orange Pi PC. > > Signed-off-by: Hans de Goede <hdegoede@redhat.com> > --- > arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 40 +++++++++++++++++++++++++++++- > 1 file changed, 39 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts > index b8340f7..f9bf260 100644 > --- a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts > +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts > @@ -49,11 +49,13 @@ > #include <dt-bindings/pinctrl/sun4i-a10.h> > > / { > - model = "Xunlong Orange Pi PC"; > + model = "Xunlong Orange Pi PC / PC Plus"; > compatible = "xunlong,orangepi-pc", "allwinner,sun8i-h3"; > > aliases { > serial0 = &uart0; > + /* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */ > + ethernet1 = &rtl8189ftv; > }; > > chosen { > @@ -118,6 +120,42 @@ > status = "okay"; > }; > > +/* Note only present on orangepi pc *plus* */ > +&mmc1 { > + pinctrl-names = "default"; > + pinctrl-0 = <&mmc1_pins_a>; > + vmmc-supply = <®_vcc3v3>; > + bus-width = <4>; > + non-removable; > + status = "okay"; > + > + /* > + * Explicitly define the sdio device, so that we can add an ethernet > + * alias for it (which e.g. makes u-boot set a mac-address). > + */ > + rtl8189ftv: sdio_wifi@1 { > + reg = <1>; > + }; > +}; Nothing prevents you from including the orange pi pc dts, from the orange pi plus dts. It prevents the duplication you were trying to avoid, and it doesn't create all those spurious errors and devices. Maxime
Hi, On 13-07-16 10:45, Maxime Ripard wrote: > On Sat, Jul 09, 2016 at 10:21:55PM +0200, Hans de Goede wrote: >> There is a new Orange Pi PC Plus available now, rather then adding >> yet another dts file for this variant, extend the existing >> Orange Pi PC to support the sdio wifi and emmc found on this variant. >> >> Downside of this approach is the following messages in dmesg when run >> on the non Plus Orange Pi PC: >> >> sunxi-mmc 1c10000.mmc: fatal err update clk timeout >> sunxi-mmc 1c11000.mmc: smc 2 err, cmd 8, RTO !! >> sunxi-mmc 1c11000.mmc: smc 2 err, cmd 55, RTO !! >> sunxi-mmc 1c11000.mmc: smc 2 err, cmd 55, RTO !! >> sunxi-mmc 1c11000.mmc: smc 2 err, cmd 55, RTO !! >> sunxi-mmc 1c11000.mmc: smc 2 err, cmd 55, RTO !! >> sunxi-mmc 1c11000.mmc: smc 2 err, cmd 1, RTO !! >> >> Note these are completely harmless and there is no adverse effect >> to the functioning of the non Plus Orange Pi PC. >> >> Signed-off-by: Hans de Goede <hdegoede@redhat.com> >> --- >> arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 40 +++++++++++++++++++++++++++++- >> 1 file changed, 39 insertions(+), 1 deletion(-) >> >> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts >> index b8340f7..f9bf260 100644 >> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts >> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts >> @@ -49,11 +49,13 @@ >> #include <dt-bindings/pinctrl/sun4i-a10.h> >> >> / { >> - model = "Xunlong Orange Pi PC"; >> + model = "Xunlong Orange Pi PC / PC Plus"; >> compatible = "xunlong,orangepi-pc", "allwinner,sun8i-h3"; >> >> aliases { >> serial0 = &uart0; >> + /* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */ >> + ethernet1 = &rtl8189ftv; >> }; >> >> chosen { >> @@ -118,6 +120,42 @@ >> status = "okay"; >> }; >> >> +/* Note only present on orangepi pc *plus* */ >> +&mmc1 { >> + pinctrl-names = "default"; >> + pinctrl-0 = <&mmc1_pins_a>; >> + vmmc-supply = <®_vcc3v3>; >> + bus-width = <4>; >> + non-removable; >> + status = "okay"; >> + >> + /* >> + * Explicitly define the sdio device, so that we can add an ethernet >> + * alias for it (which e.g. makes u-boot set a mac-address). >> + */ >> + rtl8189ftv: sdio_wifi@1 { >> + reg = <1>; >> + }; >> +}; > > Nothing prevents you from including the orange pi pc dts, from the > orange pi plus dts. > > It prevents the duplication you were trying to avoid, and it doesn't > create all those spurious errors and devices. That would solve the copy paste problem on the kernel side, but that would still mean adding a new u-boot defconfig for this, which means that all the distro's which ship with prebuild u-boot binaries need to build for yet another board, something which I would like to avoid. Regards, Hans
Hi, On Wed, Jul 13, 2016 at 12:01:41PM +0200, Hans de Goede wrote: > Hi, > > On 13-07-16 10:45, Maxime Ripard wrote: > >On Sat, Jul 09, 2016 at 10:21:55PM +0200, Hans de Goede wrote: > >>There is a new Orange Pi PC Plus available now, rather then adding > >>yet another dts file for this variant, extend the existing > >>Orange Pi PC to support the sdio wifi and emmc found on this variant. > >> > >>Downside of this approach is the following messages in dmesg when run > >>on the non Plus Orange Pi PC: > >> > >>sunxi-mmc 1c10000.mmc: fatal err update clk timeout > >>sunxi-mmc 1c11000.mmc: smc 2 err, cmd 8, RTO !! > >>sunxi-mmc 1c11000.mmc: smc 2 err, cmd 55, RTO !! > >>sunxi-mmc 1c11000.mmc: smc 2 err, cmd 55, RTO !! > >>sunxi-mmc 1c11000.mmc: smc 2 err, cmd 55, RTO !! > >>sunxi-mmc 1c11000.mmc: smc 2 err, cmd 55, RTO !! > >>sunxi-mmc 1c11000.mmc: smc 2 err, cmd 1, RTO !! > >> > >>Note these are completely harmless and there is no adverse effect > >>to the functioning of the non Plus Orange Pi PC. > >> > >>Signed-off-by: Hans de Goede <hdegoede@redhat.com> > >>--- > >> arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 40 +++++++++++++++++++++++++++++- > >> 1 file changed, 39 insertions(+), 1 deletion(-) > >> > >>diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts > >>index b8340f7..f9bf260 100644 > >>--- a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts > >>+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts > >>@@ -49,11 +49,13 @@ > >> #include <dt-bindings/pinctrl/sun4i-a10.h> > >> > >> / { > >>- model = "Xunlong Orange Pi PC"; > >>+ model = "Xunlong Orange Pi PC / PC Plus"; > >> compatible = "xunlong,orangepi-pc", "allwinner,sun8i-h3"; > >> > >> aliases { > >> serial0 = &uart0; > >>+ /* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */ > >>+ ethernet1 = &rtl8189ftv; > >> }; > >> > >> chosen { > >>@@ -118,6 +120,42 @@ > >> status = "okay"; > >> }; > >> > >>+/* Note only present on orangepi pc *plus* */ > >>+&mmc1 { > >>+ pinctrl-names = "default"; > >>+ pinctrl-0 = <&mmc1_pins_a>; > >>+ vmmc-supply = <®_vcc3v3>; > >>+ bus-width = <4>; > >>+ non-removable; > >>+ status = "okay"; > >>+ > >>+ /* > >>+ * Explicitly define the sdio device, so that we can add an ethernet > >>+ * alias for it (which e.g. makes u-boot set a mac-address). > >>+ */ > >>+ rtl8189ftv: sdio_wifi@1 { > >>+ reg = <1>; > >>+ }; > >>+}; > > > >Nothing prevents you from including the orange pi pc dts, from the > >orange pi plus dts. > > > >It prevents the duplication you were trying to avoid, and it doesn't > >create all those spurious errors and devices. > > That would solve the copy paste problem on the kernel side, but that > would still mean adding a new u-boot defconfig for this, which means that > all the distro's which ship with prebuild u-boot binaries need to build > for yet another board, something which I would like to avoid. Still, registering devices that are not present on the board is not an option. Maxime
Hi, On 07/25/2016 08:40 AM, Maxime Ripard wrote: > Hi, > > On Wed, Jul 13, 2016 at 12:01:41PM +0200, Hans de Goede wrote: >> Hi, >> >> On 13-07-16 10:45, Maxime Ripard wrote: >>> On Sat, Jul 09, 2016 at 10:21:55PM +0200, Hans de Goede wrote: >>>> There is a new Orange Pi PC Plus available now, rather then adding >>>> yet another dts file for this variant, extend the existing >>>> Orange Pi PC to support the sdio wifi and emmc found on this variant. >>>> >>>> Downside of this approach is the following messages in dmesg when run >>>> on the non Plus Orange Pi PC: >>>> >>>> sunxi-mmc 1c10000.mmc: fatal err update clk timeout >>>> sunxi-mmc 1c11000.mmc: smc 2 err, cmd 8, RTO !! >>>> sunxi-mmc 1c11000.mmc: smc 2 err, cmd 55, RTO !! >>>> sunxi-mmc 1c11000.mmc: smc 2 err, cmd 55, RTO !! >>>> sunxi-mmc 1c11000.mmc: smc 2 err, cmd 55, RTO !! >>>> sunxi-mmc 1c11000.mmc: smc 2 err, cmd 55, RTO !! >>>> sunxi-mmc 1c11000.mmc: smc 2 err, cmd 1, RTO !! >>>> >>>> Note these are completely harmless and there is no adverse effect >>>> to the functioning of the non Plus Orange Pi PC. >>>> >>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com> >>>> --- >>>> arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 40 +++++++++++++++++++++++++++++- >>>> 1 file changed, 39 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts >>>> index b8340f7..f9bf260 100644 >>>> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts >>>> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts >>>> @@ -49,11 +49,13 @@ >>>> #include <dt-bindings/pinctrl/sun4i-a10.h> >>>> >>>> / { >>>> - model = "Xunlong Orange Pi PC"; >>>> + model = "Xunlong Orange Pi PC / PC Plus"; >>>> compatible = "xunlong,orangepi-pc", "allwinner,sun8i-h3"; >>>> >>>> aliases { >>>> serial0 = &uart0; >>>> + /* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */ >>>> + ethernet1 = &rtl8189ftv; >>>> }; >>>> >>>> chosen { >>>> @@ -118,6 +120,42 @@ >>>> status = "okay"; >>>> }; >>>> >>>> +/* Note only present on orangepi pc *plus* */ >>>> +&mmc1 { >>>> + pinctrl-names = "default"; >>>> + pinctrl-0 = <&mmc1_pins_a>; >>>> + vmmc-supply = <®_vcc3v3>; >>>> + bus-width = <4>; >>>> + non-removable; >>>> + status = "okay"; >>>> + >>>> + /* >>>> + * Explicitly define the sdio device, so that we can add an ethernet >>>> + * alias for it (which e.g. makes u-boot set a mac-address). >>>> + */ >>>> + rtl8189ftv: sdio_wifi@1 { >>>> + reg = <1>; >>>> + }; >>>> +}; >>> >>> Nothing prevents you from including the orange pi pc dts, from the >>> orange pi plus dts. >>> >>> It prevents the duplication you were trying to avoid, and it doesn't >>> create all those spurious errors and devices. >> >> That would solve the copy paste problem on the kernel side, but that >> would still mean adding a new u-boot defconfig for this, which means that >> all the distro's which ship with prebuild u-boot binaries need to build >> for yet another board, something which I would like to avoid. > > Still, registering devices that are not present on the board is not an > option. Ok, I'll send a new patch which adds a separate dts file for the Orange Pi PC Plus. Regards, Hans
Hi, On 07/25/2016 08:40 AM, Maxime Ripard wrote: > Hi, > > On Wed, Jul 13, 2016 at 12:01:41PM +0200, Hans de Goede wrote: >> Hi, >> >> On 13-07-16 10:45, Maxime Ripard wrote: >>> On Sat, Jul 09, 2016 at 10:21:55PM +0200, Hans de Goede wrote: >>>> There is a new Orange Pi PC Plus available now, rather then adding >>>> yet another dts file for this variant, extend the existing >>>> Orange Pi PC to support the sdio wifi and emmc found on this variant. >>>> >>>> Downside of this approach is the following messages in dmesg when run >>>> on the non Plus Orange Pi PC: >>>> >>>> sunxi-mmc 1c10000.mmc: fatal err update clk timeout >>>> sunxi-mmc 1c11000.mmc: smc 2 err, cmd 8, RTO !! >>>> sunxi-mmc 1c11000.mmc: smc 2 err, cmd 55, RTO !! >>>> sunxi-mmc 1c11000.mmc: smc 2 err, cmd 55, RTO !! >>>> sunxi-mmc 1c11000.mmc: smc 2 err, cmd 55, RTO !! >>>> sunxi-mmc 1c11000.mmc: smc 2 err, cmd 55, RTO !! >>>> sunxi-mmc 1c11000.mmc: smc 2 err, cmd 1, RTO !! >>>> >>>> Note these are completely harmless and there is no adverse effect >>>> to the functioning of the non Plus Orange Pi PC. >>>> >>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com> >>>> --- >>>> arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 40 +++++++++++++++++++++++++++++- >>>> 1 file changed, 39 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts >>>> index b8340f7..f9bf260 100644 >>>> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts >>>> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts >>>> @@ -49,11 +49,13 @@ >>>> #include <dt-bindings/pinctrl/sun4i-a10.h> >>>> >>>> / { >>>> - model = "Xunlong Orange Pi PC"; >>>> + model = "Xunlong Orange Pi PC / PC Plus"; >>>> compatible = "xunlong,orangepi-pc", "allwinner,sun8i-h3"; >>>> >>>> aliases { >>>> serial0 = &uart0; >>>> + /* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */ >>>> + ethernet1 = &rtl8189ftv; >>>> }; >>>> >>>> chosen { >>>> @@ -118,6 +120,42 @@ >>>> status = "okay"; >>>> }; >>>> >>>> +/* Note only present on orangepi pc *plus* */ >>>> +&mmc1 { >>>> + pinctrl-names = "default"; >>>> + pinctrl-0 = <&mmc1_pins_a>; >>>> + vmmc-supply = <®_vcc3v3>; >>>> + bus-width = <4>; >>>> + non-removable; >>>> + status = "okay"; >>>> + >>>> + /* >>>> + * Explicitly define the sdio device, so that we can add an ethernet >>>> + * alias for it (which e.g. makes u-boot set a mac-address). >>>> + */ >>>> + rtl8189ftv: sdio_wifi@1 { >>>> + reg = <1>; >>>> + }; >>>> +}; >>> >>> Nothing prevents you from including the orange pi pc dts, from the >>> orange pi plus dts. >>> >>> It prevents the duplication you were trying to avoid, and it doesn't >>> create all those spurious errors and devices. >> >> That would solve the copy paste problem on the kernel side, but that >> would still mean adding a new u-boot defconfig for this, which means that >> all the distro's which ship with prebuild u-boot binaries need to build >> for yet another board, something which I would like to avoid. > > Still, registering devices that are not present on the board is not an > option. Ok, new version send. What about the other 3 patches in this series ? Regards, Hans
Hi Hans, On Tue, Jul 26, 2016 at 11:07:23PM +0200, Hans de Goede wrote: > >>>Nothing prevents you from including the orange pi pc dts, from the > >>>orange pi plus dts. > >>> > >>>It prevents the duplication you were trying to avoid, and it doesn't > >>>create all those spurious errors and devices. > >> > >>That would solve the copy paste problem on the kernel side, but that > >>would still mean adding a new u-boot defconfig for this, which means that > >>all the distro's which ship with prebuild u-boot binaries need to build > >>for yet another board, something which I would like to avoid. > > > >Still, registering devices that are not present on the board is not an > >option. > > Ok, new version send. > > What about the other 3 patches in this series ? I guess the same comment applies for patch 2. I'll look at the two others. Maxime
Hi, On 28-07-16 20:17, Maxime Ripard wrote: > Hi Hans, > > On Tue, Jul 26, 2016 at 11:07:23PM +0200, Hans de Goede wrote: >>>>> Nothing prevents you from including the orange pi pc dts, from the >>>>> orange pi plus dts. >>>>> >>>>> It prevents the duplication you were trying to avoid, and it doesn't >>>>> create all those spurious errors and devices. >>>> >>>> That would solve the copy paste problem on the kernel side, but that >>>> would still mean adding a new u-boot defconfig for this, which means that >>>> all the distro's which ship with prebuild u-boot binaries need to build >>>> for yet another board, something which I would like to avoid. >>> >>> Still, registering devices that are not present on the board is not an >>> option. >> >> Ok, new version send. >> >> What about the other 3 patches in this series ? > > I guess the same comment applies for patch 2. The difference is that there really is no harm at all from enabling the extra usb controllers used on the plus 2e on the plus and plus 2 as well, no errors, no nothing, they just sit their as usb controllers without an usb device plugged in. But if you insist I can do a separate dts + u-boot defconfig for the plus 2e as well (but I would rather not). Regards, Hans
Hi, On 28-07-16 22:36, Hans de Goede wrote: > Hi, > > On 28-07-16 20:17, Maxime Ripard wrote: >> Hi Hans, >> >> On Tue, Jul 26, 2016 at 11:07:23PM +0200, Hans de Goede wrote: >>>>>> Nothing prevents you from including the orange pi pc dts, from the >>>>>> orange pi plus dts. >>>>>> >>>>>> It prevents the duplication you were trying to avoid, and it doesn't >>>>>> create all those spurious errors and devices. >>>>> >>>>> That would solve the copy paste problem on the kernel side, but that >>>>> would still mean adding a new u-boot defconfig for this, which means that >>>>> all the distro's which ship with prebuild u-boot binaries need to build >>>>> for yet another board, something which I would like to avoid. >>>> >>>> Still, registering devices that are not present on the board is not an >>>> option. >>> >>> Ok, new version send. >>> >>> What about the other 3 patches in this series ? >> >> I guess the same comment applies for patch 2. > > The difference is that there really is no harm at all from > enabling the extra usb controllers used on the plus 2e > on the plus and plus 2 as well, no errors, no nothing, they > just sit their as usb controllers without an usb device plugged > in. But if you insist I can do a separate dts + u-boot defconfig > for the plus 2e as well (but I would rather not). Ping, what is the verdict on this, are you ok with the patch or do you want me to create a separate dts file for the Orange Pi Plus 2E, note that doing so is going to be highly confusing to users, there are 3 plus boards: Orange Pi Plus Orange Pi Plus 2 (same as the original plus but with 2G RAM, uses same u-boot defconfig / dts file) Orange Pi Plus 2E (drops the USB-hub instead using all 3 host controllers) So if you insist on a separate dts for the 2E, we get a case where the user with the "2" needs to guess which config to use, sure we can document this, but who is going to read the docs ? Regards, Hans
Hi, On 07-08-16 16:25, Hans de Goede wrote: > Hi, > > On 28-07-16 22:36, Hans de Goede wrote: >> Hi, >> >> On 28-07-16 20:17, Maxime Ripard wrote: >>> Hi Hans, >>> >>> On Tue, Jul 26, 2016 at 11:07:23PM +0200, Hans de Goede wrote: >>>>>>> Nothing prevents you from including the orange pi pc dts, from the >>>>>>> orange pi plus dts. >>>>>>> >>>>>>> It prevents the duplication you were trying to avoid, and it doesn't >>>>>>> create all those spurious errors and devices. >>>>>> >>>>>> That would solve the copy paste problem on the kernel side, but that >>>>>> would still mean adding a new u-boot defconfig for this, which means that >>>>>> all the distro's which ship with prebuild u-boot binaries need to build >>>>>> for yet another board, something which I would like to avoid. >>>>> >>>>> Still, registering devices that are not present on the board is not an >>>>> option. >>>> >>>> Ok, new version send. >>>> >>>> What about the other 3 patches in this series ? >>> >>> I guess the same comment applies for patch 2. >> >> The difference is that there really is no harm at all from >> enabling the extra usb controllers used on the plus 2e >> on the plus and plus 2 as well, no errors, no nothing, they >> just sit their as usb controllers without an usb device plugged >> in. But if you insist I can do a separate dts + u-boot defconfig >> for the plus 2e as well (but I would rather not). > > Ping, what is the verdict on this, are you ok with the patch or > do you want me to create a separate dts file for the Orange Pi > Plus 2E, note that doing so is going to be highly confusing to > users, there are 3 plus boards: > > Orange Pi Plus > Orange Pi Plus 2 (same as the original plus but with 2G RAM, uses same u-boot defconfig / dts file) > Orange Pi Plus 2E (drops the USB-hub instead using all 3 host controllers) > > So if you insist on a separate dts for the 2E, we get a case where > the user with the "2" needs to guess which config to use, sure we > can document this, but who is going to read the docs ? Ping can you please make a call on this, I'm ok with doing this either way (*), but please lets just make a call and move forward. Regards, Hans *) With a preference for a single dts file for all plus boards as explained in my previous email > > Regards, > > Hans
Hi Hans, Sorry for the slow response, it was burried in my inbox. On Sun, Aug 07, 2016 at 04:25:20PM +0200, Hans de Goede wrote: > Hi, > > On 28-07-16 22:36, Hans de Goede wrote: > >Hi, > > > >On 28-07-16 20:17, Maxime Ripard wrote: > >>Hi Hans, > >> > >>On Tue, Jul 26, 2016 at 11:07:23PM +0200, Hans de Goede wrote: > >>>>>>Nothing prevents you from including the orange pi pc dts, from the > >>>>>>orange pi plus dts. > >>>>>> > >>>>>>It prevents the duplication you were trying to avoid, and it doesn't > >>>>>>create all those spurious errors and devices. > >>>>> > >>>>>That would solve the copy paste problem on the kernel side, but that > >>>>>would still mean adding a new u-boot defconfig for this, which means that > >>>>>all the distro's which ship with prebuild u-boot binaries need to build > >>>>>for yet another board, something which I would like to avoid. > >>>> > >>>>Still, registering devices that are not present on the board is not an > >>>>option. > >>> > >>>Ok, new version send. > >>> > >>>What about the other 3 patches in this series ? > >> > >>I guess the same comment applies for patch 2. > > > >The difference is that there really is no harm at all from > >enabling the extra usb controllers used on the plus 2e > >on the plus and plus 2 as well, no errors, no nothing, they > >just sit their as usb controllers without an usb device plugged > >in. But if you insist I can do a separate dts + u-boot defconfig > >for the plus 2e as well (but I would rather not). > > Ping, what is the verdict on this, are you ok with the patch or > do you want me to create a separate dts file for the Orange Pi > Plus 2E, note that doing so is going to be highly confusing to > users, there are 3 plus boards: I still believe that enabling clocks, regulators, claiming pins for device that are entirely unused on the board is not ok. > Orange Pi Plus > Orange Pi Plus 2 (same as the original plus but with 2G RAM, uses same u-boot defconfig / dts file) Yes, that makes sense. > Orange Pi Plus 2E (drops the USB-hub instead using all 3 host controllers) However, I'm really worried about this one. If we go this way, there's essentially no going back. If for some reason we want to have a separate DT in the future (some unforeseen quirk to apply, pin to setup that conflicts on another board, etc.), we will be completely screwed because our users will be expecting to use the common DT, while it wouldn't be wise anymore. The other way around is much easier to deal with. Maxime
Hi, On 31-08-16 18:28, Maxime Ripard wrote: > Hi Hans, > > Sorry for the slow response, it was burried in my inbox. > > On Sun, Aug 07, 2016 at 04:25:20PM +0200, Hans de Goede wrote: >> Hi, >> >> On 28-07-16 22:36, Hans de Goede wrote: >>> Hi, >>> >>> On 28-07-16 20:17, Maxime Ripard wrote: >>>> Hi Hans, >>>> >>>> On Tue, Jul 26, 2016 at 11:07:23PM +0200, Hans de Goede wrote: >>>>>>>> Nothing prevents you from including the orange pi pc dts, from the >>>>>>>> orange pi plus dts. >>>>>>>> >>>>>>>> It prevents the duplication you were trying to avoid, and it doesn't >>>>>>>> create all those spurious errors and devices. >>>>>>> >>>>>>> That would solve the copy paste problem on the kernel side, but that >>>>>>> would still mean adding a new u-boot defconfig for this, which means that >>>>>>> all the distro's which ship with prebuild u-boot binaries need to build >>>>>>> for yet another board, something which I would like to avoid. >>>>>> >>>>>> Still, registering devices that are not present on the board is not an >>>>>> option. >>>>> >>>>> Ok, new version send. >>>>> >>>>> What about the other 3 patches in this series ? >>>> >>>> I guess the same comment applies for patch 2. >>> >>> The difference is that there really is no harm at all from >>> enabling the extra usb controllers used on the plus 2e >>> on the plus and plus 2 as well, no errors, no nothing, they >>> just sit their as usb controllers without an usb device plugged >>> in. But if you insist I can do a separate dts + u-boot defconfig >>> for the plus 2e as well (but I would rather not). >> >> Ping, what is the verdict on this, are you ok with the patch or >> do you want me to create a separate dts file for the Orange Pi >> Plus 2E, note that doing so is going to be highly confusing to >> users, there are 3 plus boards: > > I still believe that enabling clocks, regulators, claiming pins for > device that are entirely unused on the board is not ok. > >> Orange Pi Plus >> Orange Pi Plus 2 (same as the original plus but with 2G RAM, uses same u-boot defconfig / dts file) > > Yes, that makes sense. > >> Orange Pi Plus 2E (drops the USB-hub instead using all 3 host controllers) > > However, I'm really worried about this one. If we go this way, there's > essentially no going back. If for some reason we want to have a > separate DT in the future (some unforeseen quirk to apply, pin to > setup that conflicts on another board, etc.), we will be completely > screwed because our users will be expecting to use the common DT, > while it wouldn't be wise anymore. > > The other way around is much easier to deal with. OK, fair enough, one patch to add a separate dts file for the plus 2e coming up. Regards, Hans
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts index b8340f7..f9bf260 100644 --- a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts @@ -49,11 +49,13 @@ #include <dt-bindings/pinctrl/sun4i-a10.h> / { - model = "Xunlong Orange Pi PC"; + model = "Xunlong Orange Pi PC / PC Plus"; compatible = "xunlong,orangepi-pc", "allwinner,sun8i-h3"; aliases { serial0 = &uart0; + /* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */ + ethernet1 = &rtl8189ftv; }; chosen { @@ -118,6 +120,42 @@ status = "okay"; }; +/* Note only present on orangepi pc *plus* */ +&mmc1 { + pinctrl-names = "default"; + pinctrl-0 = <&mmc1_pins_a>; + vmmc-supply = <®_vcc3v3>; + bus-width = <4>; + non-removable; + status = "okay"; + + /* + * Explicitly define the sdio device, so that we can add an ethernet + * alias for it (which e.g. makes u-boot set a mac-address). + */ + rtl8189ftv: sdio_wifi@1 { + reg = <1>; + }; +}; + +/* Note only present on orangepi pc *plus* */ +&mmc2 { + pinctrl-names = "default"; + pinctrl-0 = <&mmc2_8bit_pins>; + vmmc-supply = <®_vcc3v3>; + bus-width = <8>; + non-removable; + cap-mmc-hw-reset; + status = "okay"; +}; + +&mmc2_8bit_pins { + /* Increase drive strength for DDR modes */ + allwinner,drive = <SUN4I_PINCTRL_40_MA>; + /* eMMC is missing pull-ups */ + allwinner,pull = <SUN4I_PINCTRL_PULL_UP>; +}; + &ohci1 { status = "okay"; };
There is a new Orange Pi PC Plus available now, rather then adding yet another dts file for this variant, extend the existing Orange Pi PC to support the sdio wifi and emmc found on this variant. Downside of this approach is the following messages in dmesg when run on the non Plus Orange Pi PC: sunxi-mmc 1c10000.mmc: fatal err update clk timeout sunxi-mmc 1c11000.mmc: smc 2 err, cmd 8, RTO !! sunxi-mmc 1c11000.mmc: smc 2 err, cmd 55, RTO !! sunxi-mmc 1c11000.mmc: smc 2 err, cmd 55, RTO !! sunxi-mmc 1c11000.mmc: smc 2 err, cmd 55, RTO !! sunxi-mmc 1c11000.mmc: smc 2 err, cmd 55, RTO !! sunxi-mmc 1c11000.mmc: smc 2 err, cmd 1, RTO !! Note these are completely harmless and there is no adverse effect to the functioning of the non Plus Orange Pi PC. Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 40 +++++++++++++++++++++++++++++- 1 file changed, 39 insertions(+), 1 deletion(-)