Re: [PATCH 0/2] Fix few omap gpmc regressions when booted with device tree
Hello Tony,
On Wed, Apr 23, 2014 at 8:08 PM, Tony Lindgren wrote:
> * Tony Lindgren [140422 17:01]:
>> * Tony Lindgren [140422 08:24]:
>> > * Javier Martinez Canillas [140421 23:55]:
>> > > On Tue, Apr 22, 2014 at 2:54 AM, Tony Lindgren wrote:
>> > > >
>> > > > 2. There seems to be some timing issues with smc911x where
>> > > >rsync of larger files and apt-get dist-upgrade can produce
>> > > >strange errors. This seems to work reliably when booted in
>> > > >legacy mode.
>> > > >
>> > >
>> > > In what board are you having this issue? The smsc911x driver supports
>> > > both SMSC's LAN911x and LAN921x families and I see that we have two
>> > > .dtsi files with different timings
>> > > (arm/boot/dts/omap-gpmc-smsc{911x,9221}.dtsi).
>> > >
>> > > This is only a wild guess, but maybe your board has a smsc LAN921x
>> > > chip but is including omap-gpmc-smsc911x.dtsi on its DTS?
>> >
>> > Yes it seems to have two LAN9220s, so this could be the reason.
>> > I don't think we had the omap-gpmc-smsc9221.dtsi when I added the
>> > timings initially.
>> >
>> > This is on a sbc-t3730 that I'm using as a gateway that was behaving
>> > reliably before I upgraded it to DT based booting. It's currently
>> > at v3.13-rc3 something, but I don't think we've much GPMC changes
>> > since then.
>> >
>> > I'll try upgrading the kernel today and running some tests with
>> > rsync. Looks like we can also remove quite a bit of duplicate
>> > timing data by using omap-gpmc-smsc9221.dtsi, I'll try something
>> > like the patch below.
>> >
>> > In any case, I suggest others run some tests on their GPMC Ethernet
>> > too.
>> >
>> > +#include "omap-gpmc-smsc9221.dtsi"
>> > +
>>
>> The 9221 timings won't work at all on 9220, it requires a 9221.
>> I'll post a better clean-up patch to use the 911x timings.
>>
>> Upgraded the kernel and the occasional corruption is still
>> there. I guess I need to test also the same kernel in legacy
>> mode to try to narrow it down.
>
> OK hopefully got it figured out now. For legacy booting we were
> always using just the bootloader timings. With device tree, we
> started using the timings with your commit d72b4415 (ARM: dts:
> omap3-igep0020: Add SMSC911x LAN chip support) that was probably
> actually tested on a LAN9221 instead of LAN9220?
>
Right, since the same driver (drivers/net/ethernet/smsc/smsc911x.c) is
used for both SMSC families I assumed that the same timings could be
used by both chips.
So I took the timings from IGEP board support in u-boot but then you
did the refactoring and later Florian added another .dtsi for SMSC
9221 in commit aac9aa3 ("ARM: dts: omap: Add common file for
SMSC9221").
I didn't notice about this new .dtsi file until you reported your
issue and the IGEPv2 does indeed have a SMSC LAN9221i ethernet chip so
it is wrongly including omap-gpmc-smsc911x.dtsi and should include
omap-gpmc-smsc9221.dtsi instead.
> In any case, I've patched omap-gpmc-smsc911x.dtsi so the values
> match the u-boot values, and so far that seems to be working just
> fine. Will post few patches shortly.
>
Great, I'll patch the IGEPv2 DTS file too to use
omap-gpmc-smsc9221.dtsi, do some testing and post a patch.
> Regards,
>
> Tony
>
Thanks a lot and best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Fix few omap gpmc regressions when booted with device tree
* Tony Lindgren [140422 17:01]:
> * Tony Lindgren [140422 08:24]:
> > * Javier Martinez Canillas [140421 23:55]:
> > > On Tue, Apr 22, 2014 at 2:54 AM, Tony Lindgren wrote:
> > > >
> > > > 2. There seems to be some timing issues with smc911x where
> > > >rsync of larger files and apt-get dist-upgrade can produce
> > > >strange errors. This seems to work reliably when booted in
> > > >legacy mode.
> > > >
> > >
> > > In what board are you having this issue? The smsc911x driver supports
> > > both SMSC's LAN911x and LAN921x families and I see that we have two
> > > .dtsi files with different timings
> > > (arm/boot/dts/omap-gpmc-smsc{911x,9221}.dtsi).
> > >
> > > This is only a wild guess, but maybe your board has a smsc LAN921x
> > > chip but is including omap-gpmc-smsc911x.dtsi on its DTS?
> >
> > Yes it seems to have two LAN9220s, so this could be the reason.
> > I don't think we had the omap-gpmc-smsc9221.dtsi when I added the
> > timings initially.
> >
> > This is on a sbc-t3730 that I'm using as a gateway that was behaving
> > reliably before I upgraded it to DT based booting. It's currently
> > at v3.13-rc3 something, but I don't think we've much GPMC changes
> > since then.
> >
> > I'll try upgrading the kernel today and running some tests with
> > rsync. Looks like we can also remove quite a bit of duplicate
> > timing data by using omap-gpmc-smsc9221.dtsi, I'll try something
> > like the patch below.
> >
> > In any case, I suggest others run some tests on their GPMC Ethernet
> > too.
> >
> > +#include "omap-gpmc-smsc9221.dtsi"
> > +
>
> The 9221 timings won't work at all on 9220, it requires a 9221.
> I'll post a better clean-up patch to use the 911x timings.
>
> Upgraded the kernel and the occasional corruption is still
> there. I guess I need to test also the same kernel in legacy
> mode to try to narrow it down.
OK hopefully got it figured out now. For legacy booting we were
always using just the bootloader timings. With device tree, we
started using the timings with your commit d72b4415 (ARM: dts:
omap3-igep0020: Add SMSC911x LAN chip support) that was probably
actually tested on a LAN9221 instead of LAN9220?
In any case, I've patched omap-gpmc-smsc911x.dtsi so the values
match the u-boot values, and so far that seems to be working just
fine. Will post few patches shortly.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Fix few omap gpmc regressions when booted with device tree
* Tony Lindgren [140422 08:24]:
> * Javier Martinez Canillas [140421 23:55]:
> > On Tue, Apr 22, 2014 at 2:54 AM, Tony Lindgren wrote:
> > >
> > > 2. There seems to be some timing issues with smc911x where
> > >rsync of larger files and apt-get dist-upgrade can produce
> > >strange errors. This seems to work reliably when booted in
> > >legacy mode.
> > >
> >
> > In what board are you having this issue? The smsc911x driver supports
> > both SMSC's LAN911x and LAN921x families and I see that we have two
> > .dtsi files with different timings
> > (arm/boot/dts/omap-gpmc-smsc{911x,9221}.dtsi).
> >
> > This is only a wild guess, but maybe your board has a smsc LAN921x
> > chip but is including omap-gpmc-smsc911x.dtsi on its DTS?
>
> Yes it seems to have two LAN9220s, so this could be the reason.
> I don't think we had the omap-gpmc-smsc9221.dtsi when I added the
> timings initially.
>
> This is on a sbc-t3730 that I'm using as a gateway that was behaving
> reliably before I upgraded it to DT based booting. It's currently
> at v3.13-rc3 something, but I don't think we've much GPMC changes
> since then.
>
> I'll try upgrading the kernel today and running some tests with
> rsync. Looks like we can also remove quite a bit of duplicate
> timing data by using omap-gpmc-smsc9221.dtsi, I'll try something
> like the patch below.
>
> In any case, I suggest others run some tests on their GPMC Ethernet
> too.
>
> +#include "omap-gpmc-smsc9221.dtsi"
> +
The 9221 timings won't work at all on 9220, it requires a 9221.
I'll post a better clean-up patch to use the 911x timings.
Upgraded the kernel and the occasional corruption is still
there. I guess I need to test also the same kernel in legacy
mode to try to narrow it down.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Fix few omap gpmc regressions when booted with device tree
* Javier Martinez Canillas [140421 23:55]:
> On Tue, Apr 22, 2014 at 2:54 AM, Tony Lindgren wrote:
> >
> > 2. There seems to be some timing issues with smc911x where
> >rsync of larger files and apt-get dist-upgrade can produce
> >strange errors. This seems to work reliably when booted in
> >legacy mode.
> >
>
> In what board are you having this issue? The smsc911x driver supports
> both SMSC's LAN911x and LAN921x families and I see that we have two
> .dtsi files with different timings
> (arm/boot/dts/omap-gpmc-smsc{911x,9221}.dtsi).
>
> This is only a wild guess, but maybe your board has a smsc LAN921x
> chip but is including omap-gpmc-smsc911x.dtsi on its DTS?
Yes it seems to have two LAN9220s, so this could be the reason.
I don't think we had the omap-gpmc-smsc9221.dtsi when I added the
timings initially.
This is on a sbc-t3730 that I'm using as a gateway that was behaving
reliably before I upgraded it to DT based booting. It's currently
at v3.13-rc3 something, but I don't think we've much GPMC changes
since then.
I'll try upgrading the kernel today and running some tests with
rsync. Looks like we can also remove quite a bit of duplicate
timing data by using omap-gpmc-smsc9221.dtsi, I'll try something
like the patch below.
In any case, I suggest others run some tests on their GPMC Ethernet
too.
Regards,
Tony
8< --
--- a/arch/arm/boot/dts/omap3-cm-t3x30.dtsi
+++ b/arch/arm/boot/dts/omap3-cm-t3x30.dtsi
@@ -10,18 +10,6 @@
cpu0-supply = <&vcc>;
};
};
-
- vddvario: regulator-vddvario {
- compatible = "regulator-fixed";
- regulator-name = "vddvario";
- regulator-always-on;
- };
-
- vdd33a: regulator-vdd33a {
- compatible = "regulator-fixed";
- regulator-name = "vdd33a";
- regulator-always-on;
- };
};
&omap3_pmx_core {
@@ -51,42 +39,18 @@
};
};
+#include "omap-gpmc-smsc9221.dtsi"
+
&gpmc {
ranges = <5 0 0x2c00 0x0100>;
- smsc1: ethernet@5,0 {
+ smsc1: ethernet@gpmc {
compatible = "smsc,lan9221", "smsc,lan9115";
pinctrl-names = "default";
pinctrl-0 = <&smsc1_pins>;
interrupt-parent = <&gpio6>;
interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
reg = <5 0 0xff>;
- bank-width = <2>;
- gpmc,mux-add-data;
- gpmc,cs-on-ns = <0>;
- gpmc,cs-rd-off-ns = <186>;
- gpmc,cs-wr-off-ns = <186>;
- gpmc,adv-on-ns = <12>;
- gpmc,adv-rd-off-ns = <48>;
- gpmc,adv-wr-off-ns = <48>;
- gpmc,oe-on-ns = <54>;
- gpmc,oe-off-ns = <168>;
- gpmc,we-on-ns = <54>;
- gpmc,we-off-ns = <168>;
- gpmc,rd-cycle-ns = <186>;
- gpmc,wr-cycle-ns = <186>;
- gpmc,access-ns = <114>;
- gpmc,page-burst-access-ns = <6>;
- gpmc,bus-turnaround-ns = <12>;
- gpmc,cycle2cycle-delay-ns = <18>;
- gpmc,wr-data-mux-bus-ns = <90>;
- gpmc,wr-access-ns = <186>;
- gpmc,cycle2cycle-samecsen;
- gpmc,cycle2cycle-diffcsen;
- vddvario-supply = <&vddvario>;
- vdd33a-supply = <&vdd33a>;
- reg-io-width = <4>;
- smsc,save-mac-address;
};
};
--- a/arch/arm/boot/dts/omap3-sb-t35.dtsi
+++ b/arch/arm/boot/dts/omap3-sb-t35.dtsi
@@ -2,20 +2,6 @@
* Common support for CompuLab SB-T35 used on SBC-T3530, SBC-T3517 and
SBC-T3730
*/
-/ {
- vddvario_sb_t35: regulator-vddvario-sb-t35 {
- compatible = "regulator-fixed";
- regulator-name = "vddvario";
- regulator-always-on;
- };
-
- vdd33a_sb_t35: regulator-vdd33a-sb-t35 {
- compatible = "regulator-fixed";
- regulator-name = "vdd33a";
- regulator-always-on;
- };
-};
-
&omap3_pmx_core {
smsc2_pins: pinmux_smsc2_pins {
pinctrl-single,pins = <
@@ -38,27 +24,28 @@
bank-width = <2>;
gpmc,mux-add-data;
gpmc,cs-on-ns = <0>;
- gpmc,cs-rd-off-ns = <186>;
- gpmc,cs-wr-off-ns = <186>;
- gpmc,adv-on-ns = <12>;
- gpmc,adv-rd-off-ns = <48>;
- gpmc,adv-wr-off-ns = <48>;
- gpmc,oe-on-ns = <54>;
- gpmc,oe-off-ns = <168>;
- gpmc,we-on-ns = <54>;
- gpmc,we-off-ns = <168>;
- gpmc,rd-cycle-ns = <186>;
- gpmc,wr-cycle-ns = <186>;
- gpmc,access-ns = <114>;
- gpmc,page-burst-access-ns = <6>;
- gpmc,bus-turnaround-ns = <12>;
- gpmc,cycle2cycle-delay-ns = <18>;
- gpmc,wr-data-
Re: [PATCH 0/2] Fix few omap gpmc regressions when booted with device tree
Hi Tony,
On Tue, Apr 22, 2014 at 2:54 AM, Tony Lindgren wrote:
> Hi all,
>
> Here are two fixes to GPMC issues I've seen. It seems that we have
> few more issues left to solve:
>
> 1. The remap of a device with gpmc_cs_remap seems to fail for
>a device if it's address specified in the .dts file is
>different from the address used by the bootloader
>
> 2. There seems to be some timing issues with smc911x where
>rsync of larger files and apt-get dist-upgrade can produce
>strange errors. This seems to work reliably when booted in
>legacy mode.
>
In what board are you having this issue? The smsc911x driver supports
both SMSC's LAN911x and LAN921x families and I see that we have two
.dtsi files with different timings
(arm/boot/dts/omap-gpmc-smsc{911x,9221}.dtsi).
This is only a wild guess, but maybe your board has a smsc LAN921x
chip but is including omap-gpmc-smsc911x.dtsi on its DTS?
> 3. The DT mappings of GPMC devices are wrong for most devices
>where the ranges property should contain the GPMC partition
>size (16, 32, 128 or 256 MB), and the reg property for the
>device should only contain the device IO range. So only NOR
>should use large values for ranges and IO range, the rest
>should use the minimum 16 MB range for GPMC partition, and
>0x4 - 0x2 for the IO range. And while patching these
>it makes sense to also unify the GPMC ranges being used for
>devices.
>
> Pekon, can you take a look at 1 and 2 above?
>
> Then for 3 above, it seems that we cannot safely change
> ranges before 1 and 2 are working reliably. Or else we have
> patch things twice, once to fix the range sizes, then to
> unify the mappings for the range address...
>
> Regards,
>
> Tony
>
> Tony Lindgren (2):
> ARM: OMAP2+: Fix oops for GPMC free
> ARM: OMAP2+: Fix GPMC remap for devices using an offset
>
These fixes look good to me.
Reviewed-by: Javier Martinez Canillas
> arch/arm/mach-omap2/gpmc.c | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> --
> 1.8.1.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Fix few omap gpmc regressions when booted with device tree
Hi all, Here are two fixes to GPMC issues I've seen. It seems that we have few more issues left to solve: 1. The remap of a device with gpmc_cs_remap seems to fail for a device if it's address specified in the .dts file is different from the address used by the bootloader 2. There seems to be some timing issues with smc911x where rsync of larger files and apt-get dist-upgrade can produce strange errors. This seems to work reliably when booted in legacy mode. 3. The DT mappings of GPMC devices are wrong for most devices where the ranges property should contain the GPMC partition size (16, 32, 128 or 256 MB), and the reg property for the device should only contain the device IO range. So only NOR should use large values for ranges and IO range, the rest should use the minimum 16 MB range for GPMC partition, and 0x4 - 0x2 for the IO range. And while patching these it makes sense to also unify the GPMC ranges being used for devices. Pekon, can you take a look at 1 and 2 above? Then for 3 above, it seems that we cannot safely change ranges before 1 and 2 are working reliably. Or else we have patch things twice, once to fix the range sizes, then to unify the mappings for the range address... Regards, Tony Tony Lindgren (2): ARM: OMAP2+: Fix oops for GPMC free ARM: OMAP2+: Fix GPMC remap for devices using an offset arch/arm/mach-omap2/gpmc.c | 15 +-- 1 file changed, 13 insertions(+), 2 deletions(-) -- 1.8.1.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
