| Message ID | 1387198885.13062.154.camel@host5.omatika.ru (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Monday 16 December 2013, Sergei Ianovich wrote: > PXA27x memory bus can have up to 10 devices: up to 6 slower > flash/SRAM/variable-latency-IO selected by nCS<0> to <5>, and up to 4 > partions of SDRAM selected by nSDCS<0> to <3>. > > It appears that the FPGA is directly connected to the memory bus and is > selected by nCS<5>. According to MSC2 configuration (already in the > mainstream U-Boot), the FPGA is configured as a synchronous SRAM with > access cycle of 30x memory bus cycles. So I made it a top-level bus like > pxabus. > > Ethernet devices are also connected to the memory bus via some kind of > gate array. This one is a bit faster -- 15x memory cycles, which is > still a lot. It explains why network transfers are never faster than 15 > Mbit/s. Ok, I see. This sounds like some of the other platforms we have with external memory buses. If there is a chance that Linux ever has to program the per-CS settings into the bus controller, I would suggest to represent that as well as a separate node, like this extbus { compatible = "simple-bus"; #address-cells = <2>; /* first cell is nCS, second is address */ #size-cells = <1>; ranges = <0 0 0 0x04000000> <1 0 0x04000000 0x04000000> <2 0 0x08000000 0x04000000> <3 0 0x0c000000 0x04000000> <4 0 0x10000000 0x04000000> <5 0 0x14000000 0x04000000>; timings = ...; flash@0 { reg = <0 0x0 0x02000000>; ... }; flash@1 { reg = <1 0x0 0x02000000>; ... }; fpga@5 { #address-cells = <1>; #size-cells = <1>; ranges = <0 5 0x03000000 0x10000>; ... }; }; In case there is a driver for the extbus node, I would not make it "simple-bus" but instead add a separate compatible string to match the driver, and let that driver call of_platform_populate to probe the children after the bus is set up. Arnd
On Mon, 2013-12-16 at 18:56 +0100, Arnd Bergmann wrote: > Ok, I see. This sounds like some of the other platforms we have with > external memory buses. If there is a chance that Linux ever has to > program the per-CS settings into the bus controller, I would suggest > to represent that as well as a separate node, like this This is a platform-specific bus (PXA27x). Should it go into pxa27x.dtsi rather than machine dts? > In case there is a driver for the extbus node, I would not make it > "simple-bus" but instead add a separate compatible string to match > the driver, and let that driver call of_platform_populate > to probe the children after the bus is set up. There seems to be none at the moment. However, some machines need to setup these partitions as a part of their initialization. So complete migration to DT will require this driver. In LP-8x4x case everything is setup by the bootloader. So "simple-bus" works for me.
On Monday 16 December 2013, Sergei Ianovich wrote: > On Mon, 2013-12-16 at 18:56 +0100, Arnd Bergmann wrote: > > Ok, I see. This sounds like some of the other platforms we have with > > external memory buses. If there is a chance that Linux ever has to > > program the per-CS settings into the bus controller, I would suggest > > to represent that as well as a separate node, like this > > This is a platform-specific bus (PXA27x). Should it go into pxa27x.dtsi > rather than machine dts? Yes, that was the idea. > > In case there is a driver for the extbus node, I would not make it > > "simple-bus" but instead add a separate compatible string to match > > the driver, and let that driver call of_platform_populate > > to probe the children after the bus is set up. > > There seems to be none at the moment. However, some machines need to > setup these partitions as a part of their initialization. So complete > migration to DT will require this driver. > > In LP-8x4x case everything is setup by the bootloader. So "simple-bus" > works for me. Hmm, this is a bit tricky then. I think it would be best to not use "simple-bus" then, to allow migrating the other platforms later, but that will be a little more work. Maybe you can register a trivial driver in the platform code that only calls of_platform_populate on the device for now? Arnd
On Wed, 2013-12-18 at 21:50 +0100, Arnd Bergmann wrote: > > This is a platform-specific bus (PXA27x). Should it go into pxa27x.dtsi > > rather than machine dts? > > Yes, that was the idea. Great. > > There seems to be none at the moment. However, some machines need to > > setup these partitions as a part of their initialization. So complete > > migration to DT will require this driver. > > > > In LP-8x4x case everything is setup by the bootloader. So "simple-bus" > > works for me. > > Hmm, this is a bit tricky then. I think it would be best to not > use "simple-bus" then, to allow migrating the other platforms later, > but that will be a little more work. Maybe you can register a trivial > driver in the platform code that only calls of_platform_populate on > the device for now? Could we postpone this until someone needs this functionality?
On Wednesday 18 December 2013, Sergei Ianovich wrote: > > Hmm, this is a bit tricky then. I think it would be best to not > > use "simple-bus" then, to allow migrating the other platforms later, > > but that will be a little more work. Maybe you can register a trivial > > driver in the platform code that only calls of_platform_populate on > > the device for now? > > Could we postpone this until someone needs this functionality? We have to be sure that any device tree files you write now can remain compatible with future kernels if we add it later. My reasoning at first was that this wouldn't work if we had to change the "compatible" string for the bus node, but after re-thinking it now I believe that it's fine. You would still be able to boot a kernel with an old dts file on a new kernel if it just contains a "simple-bus" node here, as long as it doesn't need any boot-time setup at the bus controller. We can change the dts file later if we need to add this functionality, which would break booting old kernels with the new dts files, which isn't much of a problem in general. Arnd
On Wed, 2013-12-18 at 22:10 +0100, Arnd Bergmann wrote: > On Wednesday 18 December 2013, Sergei Ianovich wrote: > > Could we postpone this until someone needs this functionality? > > We have to be sure that any device tree files you write now can remain > compatible with future kernels if we add it later. My reasoning at first > was that this wouldn't work if we had to change the "compatible" string > for the bus node, but after re-thinking it now I believe that it's fine. Great. > You would still be able to boot a kernel with an old dts file on a new > kernel if it just contains a "simple-bus" node here, as long as it doesn't > need any boot-time setup at the bus controller. We can change the dts > file later if we need to add this functionality, which would break booting > old kernels with the new dts files, which isn't much of a problem in > general. It should actually only break old kernels which require new functionally. Otherwise, dts can have compatible = "marvell,pxa-extbus", "simple-bus"; and an older kernel will be happy with "simple-bus". Please correct me if I'm wrong.
On Wednesday 18 December 2013, Sergei Ianovich wrote: > > You would still be able to boot a kernel with an old dts file on a new > > kernel if it just contains a "simple-bus" node here, as long as it doesn't > > need any boot-time setup at the bus controller. We can change the dts > > file later if we need to add this functionality, which would break booting > > old kernels with the new dts files, which isn't much of a problem in > > general. > > It should actually only break old kernels which require new > functionally. Otherwise, dts can have > > compatible = "marvell,pxa-extbus", "simple-bus"; > > and an older kernel will be happy with "simple-bus". Please correct me > if I'm wrong. This would work only if we can probe the devices behind the external bus controller before the controller itsef has been set up, since the initialization order can depend on a number of things but not the bus hierarchy. It will also work if the code setting up the bus controller can be guaranteed to run before we call of_platform_populate for the regular devices, which is probably the best solution here. Arnd
On Thu, 2013-12-19 at 06:30 +0100, Arnd Bergmann wrote: > This would work only if we can probe the devices behind the external > bus controller before the controller itsef has been set up, since > the initialization order can depend on a number of things but not > the bus hierarchy. It will also work if the code setting up the > bus controller can be guaranteed to run before we call > of_platform_populate for the regular devices, which is probably > the best solution here. There has been no activity for 3 weeks. Could we resume the series?
On Fri, 2014-01-10 at 03:12 +0400, Sergei Ianovich wrote: > On Thu, 2013-12-19 at 06:30 +0100, Arnd Bergmann wrote: > > This would work only if we can probe the devices behind the external > > bus controller before the controller itsef has been set up, since > > the initialization order can depend on a number of things but not > > the bus hierarchy. It will also work if the code setting up the > > bus controller can be guaranteed to run before we call > > of_platform_populate for the regular devices, which is probably > > the best solution here. > > There has been no activity for 3 weeks. Could we resume the series? It's over a month now. Is anything wrong?
On 01/20/2014 05:08 PM, Sergei Ianovich wrote: > On Fri, 2014-01-10 at 03:12 +0400, Sergei Ianovich wrote: >> On Thu, 2013-12-19 at 06:30 +0100, Arnd Bergmann wrote: >>> This would work only if we can probe the devices behind the external >>> bus controller before the controller itsef has been set up, since >>> the initialization order can depend on a number of things but not >>> the bus hierarchy. It will also work if the code setting up the >>> bus controller can be guaranteed to run before we call >>> of_platform_populate for the regular devices, which is probably >>> the best solution here. >> >> There has been no activity for 3 weeks. Could we resume the series? > > It's over a month now. Is anything wrong? > No, I'm busy, that's all. That said, the current situation is a) we need someone to have a look at the performance regression of the MMC file system layer that you reported. I couldn't find a PXA-based board yet with a MMC slot soldered on it. But as you apparently have such hardware, I'd really appreciate your help here. Could you do some measurements and see whether you see major differences in packet size or timings? b) Marek Vasut thankfully reported back to me and signaled success with his pxa-pata driver. So we're most probably good in that area. c) Robert Jarzmik is still in the process of converting the camera driver. Here as well, I lack hardware, I can't even compile-test anything here. So please, if you have any spare time, have a look at the MMC regressions and see if you can contribute anything. I'll hope to find some time to rebase my patches on top of 3.13 very soon, so we have a new base to work on. Thanks, Daniel
On Mon, 2014-01-20 at 17:20 +0100, Daniel Mack wrote: > On 01/20/2014 05:08 PM, Sergei Ianovich wrote: > > It's over a month now. Is anything wrong? > No, I'm busy, that's all. Thanks for reply. > That said, the current situation is > > a) we need someone to have a look at the performance regression of the > MMC file system layer that you reported. I couldn't find a PXA-based > board yet with a MMC slot soldered on it. But as you apparently have > such hardware, I'd really appreciate your help here. Could you do some > measurements and see whether you see major differences in packet size or > timings? I have the hardware with MMC, but none of the other devices. Could you give some pointer where to start? How would you do measurements? (...) > So please, if you have any spare time, have a look at the MMC > regressions and see if you can contribute anything. I'll hope to find > some time to rebase my patches on top of 3.13 very soon, so we have a > new base to work on. It would be nice to have updated patches. Most interesting is whether the new DMA still works as expected for other devices. Apart from that, would mind if my series is landed with a workaround (Patch v3 7/21). I hope you understand it doesn't feel good to depend on something with no development activity.
On 01/20/2014 05:52 PM, Sergei Ianovich wrote: > On Mon, 2014-01-20 at 17:20 +0100, Daniel Mack wrote: >> On 01/20/2014 05:08 PM, Sergei Ianovich wrote: >>> It's over a month now. Is anything wrong? >> No, I'm busy, that's all. > > Thanks for reply. > >> That said, the current situation is >> >> a) we need someone to have a look at the performance regression of the >> MMC file system layer that you reported. I couldn't find a PXA-based >> board yet with a MMC slot soldered on it. But as you apparently have >> such hardware, I'd really appreciate your help here. Could you do some >> measurements and see whether you see major differences in packet size or >> timings? > > I have the hardware with MMC, but none of the other devices. Could you > give some pointer where to start? How would you do measurements? Please check whether the DMA engine transfers data in chunks of comparable size in both cases. Also, take time stamps when the packet is submitted, and calculate the delta when the transfer returns. See if any significant time gap contributes to the regression you see. After all, it's still quite possible that the DMA driver has performance bottlenecks. We need to find the code where so much more time is spent with the new implementation. > It would be nice to have updated patches. Most interesting is whether > the new DMA still works as expected for other devices. I'll allocate a time slot for that :) > Apart from that, would mind if my series is landed with a workaround > (Patch v3 7/21). I hope you understand it doesn't feel good to depend on > something with no development activity. I understand, but that shouldn't keep you you from maintaining a patch stack out-of-tree until things are in shape enough to go mainline. Thanks for you help, Daniel
diff --git a/arch/arm/boot/dts/pxa27x-lp8x4x.dts b/arch/arm/boot/dts/pxa27x-lp8x4x.dts new file mode 100644 index 0000000..cb2a31d --- /dev/null +++ b/arch/arm/boot/dts/pxa27x-lp8x4x.dts @@ -0,0 +1,208 @@ +/* Device tree for ICP DAS LP-8x4x */ +/dts-v1/; + +#include <dt-bindings/interrupt-controller/arm-gic.h> +#include "pxa27x.dtsi" + +/ { + model = "ICP DAS LP-8x4x programmable automation controller"; + compatible = "marvell,lp8x4x", "marvell,pxa270"; + + aliases { + ethernet0 = ð0; + ethernet1 = ð1; + }; + + memory { + /* + * SDRAM + * connected to CPU via nSDCS<0> + */ + reg = <0xa0000000 0x08000000>; + }; + + regulators { + compatible = "simple-bus"; + #address-cells = <1>; + #size-cells = <0>; + + vmmc: regulator@0 { + compatible = "regulator-fixed"; + reg = <0>; + regulator-name = "vmmc"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-always-on; + }; + }; + + flash@00000000 { + /* + * Boot memory + * connected to CPU via nCS<0> + */ + compatible = "cfi-flash"; + reg = <0x0 0x02000000>; + bank-width = <4>; + device-width = <2>; + #address-cells = <1>; + #size-cells = <1>; + fs@0 { + label = "u-boot"; + reg = <0 0x40000>; + }; + fs@40000 { + label = "settings"; + reg = <0x40000 0x40000>; + }; + fs@80000 { + label = "kernel"; + reg = <0x80000 0x280000>; + }; + fs@300000 { + label = "root_fs"; + reg = <0x300000 0x1d00000>; + }; + }; + + flash@04000000 { + /* + * connected to CPU via nCS<1> + */ + compatible = "cfi-flash"; + reg = <0x04000000 0x02000000>; + bank-width = <2>; + device-width = <1>; + }; + + pxabus { + pxairq: interrupt-controller@40d00000 { + marvell,intc-priority; + marvell,intc-nr-irqs = <34>; + }; + + uart@40100000 { + status = "okay"; + }; + + uart@40200000 { + status = "okay"; + }; + + uart@40700000 { + status = "okay"; + }; + + mmc@41100000 { + status = "okay"; + vmmc-supply = <&vmmc>; + }; + + ohci@4c000000 { + status = "okay"; + marvell,port-mode = <3>; + marvell,oc-mode-perport; + marvell,enable-port1; + }; + }; + + extbus { + /* + * Transparent bus, 2 byte-wide access + * connected to CPU via nCS<3> + */ + compatible = "simple-bus"; + #address-cells = <1>; + #size-cells = <1>; + ranges; + interrupt-parent = <&gpio>; + + eth0: eth@0c000000 { + compatible = "davicom,dm9000"; + reg = <0x0c000000 0x2 + 0x0c004000 0x2>; + interrupts = <9 IRQ_TYPE_EDGE_RISING>; + status = "okay"; + }; + + eth1: eth@0d000000 { + compatible = "davicom,dm9000"; + reg = <0x0d000000 0x2 + 0x0d004000 0x2>; + interrupts = <82 IRQ_TYPE_EDGE_RISING>; + status = "okay"; + }; + }; + + fpgabus { + /* + * Transparent bus, 1 byte-wide access, even addresses only + * connected to CPU via nCS<5> + */ + compatible = "simple-bus"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x17000000 0x10000>; + interrupt-parent = <&fpga>; + + rtc@901c { + compatible = "ds,rtc-ds1302"; + reg = <0x901c 0x1>; + status = "okay"; + }; + + sram@a000 { + compatible = "icpdas,sram-lp8x4x"; + reg = <0xa000 0x1000 + 0x901e 0x1>; + }; + + fpga: irq@9006 { + compatible = "icpdas,irq-lp8x4x"; + reg = <0x9006 0x16>; + interrupt-parent = <&gpio>; + interrupts = <3 IRQ_TYPE_EDGE_FALLING>; + #interrupt-cells = <1>; + interrupt-controller; + status = "okay"; + }; + + uart@9050 { + compatible = "icpdas,uart-lp8x4x"; + reg = <0x9050 0x10 + 0x9030 0x02>; + interrupts = <13>; + status = "okay"; + }; + + uart@9060 { + compatible = "icpdas,uart-lp8x4x"; + reg = <0x9060 0x10 + 0x9032 0x02>; + interrupts = <14>; + status = "okay"; + }; + + uart@9070 { + compatible = "icpdas,uart-lp8x4x"; + reg = <0x9070 0x10 + 0x9034 0x02>; + interrupts = <15>; + status = "okay"; + }; + + backplane@9046 { + compatible = "icpdas,backplane-lp8x4x"; + reg = <0x9046 0x2 + 0x9004 0x2 + 0x1000 0x10 + 0x2000 0x10 + 0x3000 0x10 + 0x4000 0x10 + 0x5000 0x10 + 0x6000 0x10 + 0x7000 0x10 + 0x8000 0x10>; + }; + }; +};