Message ID | 1386348542-9584-1-git-send-email-ynvich@gmail.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On Friday 06 December 2013, Sergei Ianovich wrote: > new file mode 100644 > index 0000000..2612e60 > --- /dev/null > +++ b/arch/arm/configs/lp8x4x_defconfig > @@ -0,0 +1,235 @@ > +CONFIG_CROSS_COMPILE="arm-linux-gnueabi-" This will break some build bots, please remove it here and add it to your build environment instead. > +# CONFIG_LBDAF is not set > +CONFIG_BLK_CMDLINE_PARSER=y > +CONFIG_PARTITION_ADVANCED=y > +CONFIG_BSD_DISKLABEL=y > +CONFIG_MINIX_SUBPARTITION=y > +CONFIG_SOLARIS_X86_PARTITION=y > +CONFIG_UNIXWARE_DISKLABEL=y > +CONFIG_LDM_PARTITION=y You have some rather unusual options in here. I'd suggest you go through the reduced defconfig file and remove all options that look like they are unnecessary for your system. It's probably based on some distro config that enables lots of modules you don't actually want. > +#define LP8X4X_FPGA_PHYS 0x17000000 > +#define LP8X4X_FPGA_VIRT ((void *) 0xf1000000) > +#define LP8X4X_P2V(x) IOMEM((x) - LP8X4X_FPGA_PHYS + LP8X4X_FPGA_VIRT) > +#define LP8X4X_V2P(x) ((x) - LP8X4X_FPGA_VIRT + LP8X4X_FPGA_PHYS) I think you misunderstood my comment, the point was that you should move the IOMEM() to the LP8X4X_FPGA_VIRT definition, like #define LP8X4X_FPGA_VIRT ((void __iomem *) 0xf1000000) #define LP8X4X_P2V(x) (x) - LP8X4X_FPGA_PHYS + LP8X4X_FPGA_VIRT) which would result in the correct type because of pointer arithmetics. > +/* board level registers in the FPGA */ > + > +#define LP8X4X_EOI LP8X4X_P2V(0x17009006) > +#define LP8X4X_INSINT LP8X4X_P2V(0x17009008) > +#define LP8X4X_ENSYSINT LP8X4X_P2V(0x1700900A) > +#define LP8X4X_PRIMINT LP8X4X_P2V(0x1700900C) > +#define LP8X4X_SECOINT LP8X4X_P2V(0x1700900E) > +#define LP8X4X_ENRISEINT LP8X4X_P2V(0x17009010) > +#define LP8X4X_CLRRISEINT LP8X4X_P2V(0x17009012) > +#define LP8X4X_ENHILVINT LP8X4X_P2V(0x17009014) > +#define LP8X4X_CLRHILVINT LP8X4X_P2V(0x17009016) > +#define LP8X4X_ENFALLINT LP8X4X_P2V(0x17009018) > +#define LP8X4X_CLRFALLINT LP8X4X_P2V(0x1700901a) Thinking about this again, it's actually better if you just get rid of LP8X4X_P2V() entirely and redefine these to #define LP8X4X_EOI 0x0006 #define LP8X4X_INSINT 0x0008 ... and change the users to do e.g. readl(LP8X4X_FPGA_VIRT + LP8X4X_INSINT); This is closer to the normal way of adding the offset to an __iomem pointer returned from ioremap. > + platform_device_register_resndata(NULL, "pxa2xx-flash", 0, > + &lp8x4x_flash_resources[0], 1, > + &lp8x4x_flash_data[0], sizeof(lp8x4x_flash_data[0])); > + platform_device_register_resndata(NULL, "pxa2xx-flash", 1, > + &lp8x4x_flash_resources[1], 1, > + &lp8x4x_flash_data[1], sizeof(lp8x4x_flash_data[1])); > + platform_device_register_simple("dm9000", 0, > + &lp8x4x_dm9000_resources[0], 3); > + platform_device_register_simple("dm9000", 1, > + &lp8x4x_dm9000_resources[3], 3); This looks much better than the first version, a slight improvement IMHO would be to split the resource arrays into one symbol per device to turn this into platform_device_register_resndata(NULL, "pxa2xx-flash", 0, &lp8x4x_flash_resources0, 1, &lp8x4x_flash_data0, sizeof(lp8x4x_flash_data0)); platform_device_register_resndata(NULL, "pxa2xx-flash", 1, &lp8x4x_flash_resources1, 1, &lp8x4x_flash_data1, sizeof(lp8x4x_flash_data1)); It's not important though if you have a strong preference for the way you did this, it just seems unusual. Arnd
On Sun, 2013-12-08 at 03:21 +0100, Arnd Bergmann wrote: > On Friday 06 December 2013, Sergei Ianovich wrote: > You have some rather unusual options in here. I'd suggest you go through > the reduced defconfig file and remove all options that look like they > are unnecessary for your system. > > It's probably based on some distro config that enables lots of modules > you don't actually want. I tried to future-proof the config, by enabling all partition tables and USB disks and modems that could be plugged into the device. I'll remove those. However, I would like to retain config options related to low latency and small kernel size. Keeping them will hopefully allow being notified about changes affecting the system. Will this fly? > > +#define LP8X4X_FPGA_PHYS 0x17000000 > > +#define LP8X4X_FPGA_VIRT ((void *) 0xf1000000) > > +#define LP8X4X_P2V(x) IOMEM((x) - LP8X4X_FPGA_PHYS + LP8X4X_FPGA_VIRT) > > +#define LP8X4X_V2P(x) ((x) - LP8X4X_FPGA_VIRT + LP8X4X_FPGA_PHYS) > > I think you misunderstood my comment, the point was that you should > move the IOMEM() to the LP8X4X_FPGA_VIRT definition, like > > #define LP8X4X_FPGA_VIRT ((void __iomem *) 0xf1000000) > #define LP8X4X_P2V(x) (x) - LP8X4X_FPGA_PHYS + LP8X4X_FPGA_VIRT) > > which would result in the correct type because of pointer arithmetics. > > > +/* board level registers in the FPGA */ > > + > > +#define LP8X4X_EOI LP8X4X_P2V(0x17009006) > > +#define LP8X4X_INSINT LP8X4X_P2V(0x17009008) > > +#define LP8X4X_ENSYSINT LP8X4X_P2V(0x1700900A) > > +#define LP8X4X_PRIMINT LP8X4X_P2V(0x1700900C) > > +#define LP8X4X_SECOINT LP8X4X_P2V(0x1700900E) > > +#define LP8X4X_ENRISEINT LP8X4X_P2V(0x17009010) > > +#define LP8X4X_CLRRISEINT LP8X4X_P2V(0x17009012) > > +#define LP8X4X_ENHILVINT LP8X4X_P2V(0x17009014) > > +#define LP8X4X_CLRHILVINT LP8X4X_P2V(0x17009016) > > +#define LP8X4X_ENFALLINT LP8X4X_P2V(0x17009018) > > +#define LP8X4X_CLRFALLINT LP8X4X_P2V(0x1700901a) > > Thinking about this again, it's actually better if you just get rid of > LP8X4X_P2V() entirely and redefine these to > > #define LP8X4X_EOI 0x0006 > #define LP8X4X_INSINT 0x0008 > ... > > and change the users to do e.g. > > readl(LP8X4X_FPGA_VIRT + LP8X4X_INSINT); I am trying to boot the system with device tree. If I manage, I'll move this code into drivers/irqchip/ as a platform device. Otherwise, I'll make this change. > This is closer to the normal way of adding the offset to an __iomem > pointer returned from ioremap. > > > + platform_device_register_resndata(NULL, "pxa2xx-flash", 0, > > + &lp8x4x_flash_resources[0], 1, > > + &lp8x4x_flash_data[0], sizeof(lp8x4x_flash_data[0])); > > + platform_device_register_resndata(NULL, "pxa2xx-flash", 1, > > + &lp8x4x_flash_resources[1], 1, > > + &lp8x4x_flash_data[1], sizeof(lp8x4x_flash_data[1])); > > + platform_device_register_simple("dm9000", 0, > > + &lp8x4x_dm9000_resources[0], 3); > > + platform_device_register_simple("dm9000", 1, > > + &lp8x4x_dm9000_resources[3], 3); > > This looks much better than the first version, a slight improvement IMHO would > be to split the resource arrays into one symbol per device to turn this into > > platform_device_register_resndata(NULL, "pxa2xx-flash", 0, > &lp8x4x_flash_resources0, 1, > &lp8x4x_flash_data0, sizeof(lp8x4x_flash_data0)); > platform_device_register_resndata(NULL, "pxa2xx-flash", 1, > &lp8x4x_flash_resources1, 1, > &lp8x4x_flash_data1, sizeof(lp8x4x_flash_data1)); > > It's not important though if you have a strong preference for the way you > did this, it just seems unusual. I'll make this change, if device tree doesn't boot. Thanks for reviewing.
Except for defconfig, this is a completely new series. The first eight patches fix outstanding issues with device tree support in PXA. The 9th boots ICP DAS LP-8x4x. Daniel chose to add a lot of selects for his MACH_PXA3XX_DT config option. I feel that it will be easier to create multi-machine kernel configurations and support per-machine workaround, if those selects reside in separate machine options. If Daniel agrees with my arguments, MACH_PXA3XX_DT and MACH_PXA27X_DT could be merged into a single MACH_PXA_DT option. CC: Daniel Mack <zonque@gmail.com> CC: Arnd Bergmann <arnd@arndb.de> Sergei Ianovich (9): ARM: dts: pxa2xx fix compatible strings ARM: dts: fix pxa27x-gpio interrupts ARM: fix ohci-pxa27x build error with OF enabled ARM: pxa: remove unused variable ARM: dts: provide DMA config to pxamci ARM: dts: pxa3xx: move declaration to header ARM: dts: pxa27x: skip static platform devices ARM: dts: pxa27x: device tree irq init ARM: pxa27x: device tree support ICP DAS LP-8x4x Documentation/devicetree/bindings/mmc/pxa-mmc.txt | 2 + arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/pxa27x-lp8x4x.dts | 111 +++++++++++++++ arch/arm/boot/dts/pxa27x.dtsi | 10 ++ arch/arm/boot/dts/pxa2xx.dtsi | 5 +- arch/arm/configs/lp8x4x_defconfig | 162 ++++++++++++++++++++++ arch/arm/mach-pxa/Kconfig | 31 +++++ arch/arm/mach-pxa/Makefile | 1 + arch/arm/mach-pxa/include/mach/irqs.h | 4 + arch/arm/mach-pxa/include/mach/pxa27x.h | 4 + arch/arm/mach-pxa/irq.c | 2 - arch/arm/mach-pxa/pxa27x-dt.c | 97 +++++++++++++ arch/arm/mach-pxa/pxa27x.c | 17 +++ arch/arm/mach-pxa/pxa3xx.c | 2 - drivers/mmc/host/pxamci.c | 50 +++++-- drivers/usb/host/ohci-pxa27x.c | 1 + 16 files changed, 482 insertions(+), 18 deletions(-) create mode 100644 arch/arm/boot/dts/pxa27x-lp8x4x.dts create mode 100644 arch/arm/configs/lp8x4x_defconfig create mode 100644 arch/arm/mach-pxa/pxa27x-dt.c
On Sunday 08 December 2013, Sergei Ianovich wrote: > On Sun, 2013-12-08 at 03:21 +0100, Arnd Bergmann wrote: > > On Friday 06 December 2013, Sergei Ianovich wrote: > > You have some rather unusual options in here. I'd suggest you go through > > the reduced defconfig file and remove all options that look like they > > are unnecessary for your system. > > > > It's probably based on some distro config that enables lots of modules > > you don't actually want. > > I tried to future-proof the config, by enabling all partition tables and > USB disks and modems that could be plugged into the device. > > I'll remove those. However, I would like to retain config options > related to low latency and small kernel size. Keeping them will > hopefully allow being notified about changes affecting the system. > > Will this fly? Yes, of course, keep as many as you need. I was just trying to ensure that you had put some thought in it, and e.g. the various USB serial modules and some other things appeared to be fairly random, but I can see them making sense now. > > #define LP8X4X_EOI 0x0006 > > #define LP8X4X_INSINT 0x0008 > > ... > > > > and change the users to do e.g. > > > > readl(LP8X4X_FPGA_VIRT + LP8X4X_INSINT); > > I am trying to boot the system with device tree. If I manage, I'll move > this code into drivers/irqchip/ as a platform device. Otherwise, I'll > make this change. Ok, cool. If you need help with the DT conversion, just ask here or on IRC (#armlinux or #mvlinux on freenode.net, there might also be a PXA specific channel I don't know). Arnd
On Sunday 08 December 2013, Sergei Ianovich wrote: > > Except for defconfig, this is a completely new series. The first > eight patches fix outstanding issues with device tree support > in PXA. The 9th boots ICP DAS LP-8x4x. Awesome! That was very quick. The main comment I have is for the dmaengine support, you will need to rebase on Daniel's patches for that. I also found few minor details. Arnd
On Mon, 2013-12-09 at 02:51 +0100, Arnd Bergmann wrote: > On Sunday 08 December 2013, Sergei Ianovich wrote: > > > > Except for defconfig, this is a completely new series. The first > > eight patches fix outstanding issues with device tree support > > in PXA. The 9th boots ICP DAS LP-8x4x. > > Awesome! That was very quick. The main comment I have is for the > dmaengine support, you will need to rebase on Daniel's patches for > that. I also found few minor details. Thanks for review. I've applied and tested changes to meet review remarks for all patches, except 5/9. However, there is no point to respin the series until the decision about DMA is made. Daniel, could please CC me when you post update pxa-dma series?
On Fri, Dec 6, 2013 at 5:48 PM, Sergei Ianovich <ynvich@gmail.com> wrote: > ICP DAS calls LP-8x4x 'programmable automation controller'. It is > an industrial computer based on PXA270 SoC. They ship it with a 2.6.19 > kernel and proprietary kernel module and userspace library to access > its industrial IO. OK... so we only have device tree support for PXA3xx and noone is working on PXA2xx. And now we pile up some more legacy code. Such is life. But this: > +static unsigned long lp8x4x_pin_config[] = { > + /* MMC */ > + GPIO32_MMC_CLK, > + GPIO112_MMC_CMD, > + GPIO92_MMC_DAT_0, > + GPIO109_MMC_DAT_1, > + GPIO110_MMC_DAT_2, > + GPIO111_MMC_DAT_3, > + > + /* USB Host Port 1 */ > + GPIO88_USBH1_PWR, > + GPIO89_USBH1_PEN, > +}; (...) > +static void __init lp8x4x_init(void) > +{ > + pxa2xx_mfp_config(ARRAY_AND_SIZE(lp8x4x_pin_config)); (...) Argh! Now you're adding another user for a legacy custom pin control implementation. But if noone is going to modernize PXA2xx what can we do :-/ Yours, Linus Walleij
On Tue, 2013-12-10 at 13:43 +0100, Linus Walleij wrote: > Argh! Now you're adding another user for a legacy custom pin control > implementation. But if noone is going to modernize PXA2xx what > can we do :-/ I've rewritten the device to use device tree and posted patch series for that. I will also implement LP-8x4x custom irq controller in drivers/irqchip/
On Tue, Dec 10, 2013 at 3:43 PM, Linus Walleij <linus.walleij@linaro.org> wrote: > On Fri, Dec 6, 2013 at 5:48 PM, Sergei Ianovich <ynvich@gmail.com> wrote: > >> ICP DAS calls LP-8x4x 'programmable automation controller'. It is >> an industrial computer based on PXA270 SoC. They ship it with a 2.6.19 >> kernel and proprietary kernel module and userspace library to access >> its industrial IO. > > OK... so we only have device tree support for PXA3xx and noone is > working on PXA2xx. And now we pile up some more legacy code. > Such is life. But this: > >> +static unsigned long lp8x4x_pin_config[] = { >> + /* MMC */ >> + GPIO32_MMC_CLK, >> + GPIO112_MMC_CMD, >> + GPIO92_MMC_DAT_0, >> + GPIO109_MMC_DAT_1, >> + GPIO110_MMC_DAT_2, >> + GPIO111_MMC_DAT_3, >> + >> + /* USB Host Port 1 */ >> + GPIO88_USBH1_PWR, >> + GPIO89_USBH1_PEN, >> +}; > > (...) >> +static void __init lp8x4x_init(void) >> +{ >> + pxa2xx_mfp_config(ARRAY_AND_SIZE(lp8x4x_pin_config)); > (...) > > Argh! Now you're adding another user for a legacy custom pin control > implementation. But if noone is going to modernize PXA2xx what > can we do :-/ I tried a ~year ago, but it's not so trivial. PXA2xx has no separate pin control module, it's highly integrated into GPIO controller. I've asked the maillist what should I do for that case, but AFAIR no one answered. Regards Vasily > Yours, > Linus Walleij > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Tue, Dec 10, 2013 at 1:47 PM, Sergei Ianovich <ynvich@gmail.com> wrote: > On Tue, 2013-12-10 at 13:43 +0100, Linus Walleij wrote: >> Argh! Now you're adding another user for a legacy custom pin control >> implementation. But if noone is going to modernize PXA2xx what >> can we do :-/ > > I've rewritten the device to use device tree and posted patch series for > that. THANKS! For doing this. Yours, Linus Walleij
On Tue, Dec 10, 2013 at 1:54 PM, Vasily Khoruzhick <anarsoul@gmail.com> wrote: > On Tue, Dec 10, 2013 at 3:43 PM, Linus Walleij <linus.walleij@linaro.org> wrote: >> Argh! Now you're adding another user for a legacy custom pin control >> implementation. But if noone is going to modernize PXA2xx what >> can we do :-/ > > I tried a ~year ago, but it's not so trivial. PXA2xx has no separate > pin control module, it's > highly integrated into GPIO controller. I've asked the maillist what > should I do for that case, but AFAIR no one answered. It is very common for pin controllers and GPIO blocks to be integrated. The usual solution is to make a combined driver that registers both pinctrl and GPIO interfaces and put that into drivers/pinctrl. Here is a recent example that can be used as inspiration: http://marc.info/?l=linux-doc&m=138629591206248&w=2 Yours, Linus Walleij
Fixed most review requirements. Details in respective patches. I've completely met the requirement for using dmaengine-based DMA in patch v2-03/16. Tests showed new DMA was underperforming. It added on top of a pre-existing problem with MMC bus width and made the system barely usable. However, the new code in this patch work correctly with both the existing and the new DMA. Even if the new DMA is compiled into the kernel, the exisitng DMA initializes first. I've also decided not to create a single mfd device for machine-specific devices. Instead each type is supported by a separate driver in respective subsystem. It was tempting to hardcode all the constants in one source file, but that requires ugly initialization. The taken way produces much cleaner code. Sergei Ianovich (16): ARM: dts: pxa2xx fix compatible strings ARM: dts: fix pxa27x-gpio interrupts ARM: dts: provide DMA config to pxamci ARM: dts: pxa3xx: move declaration to header ARM: dts: pxa27x: irq init using device tree ARM: pxa27x: device tree support ICP DAS LP-8x4x rtc: support DS1302 RTC on ICP DAS LP-8x4x mtd: support BB SRAM on ICP DAS LP-8x4x ARM: pxa: support ICP DAS LP-8x4x FPGA irq serial: support for 16550A serial ports on LP-8x4x misc: support for LP-8x4x custom parallel bus misc: support for serial slots in LP-8x4x misc: support for parallel slots in LP-8x4x misc: support for I-8041 in LP-8x4x misc: support for I-8042 in LP-8x4x misc: support for I-8024 in LP-8x4x .../bindings/interrupt-controller/irq-lp8x4x.txt | 49 ++ .../devicetree/bindings/misc/lp8x4x-bus.txt | 18 + Documentation/devicetree/bindings/mmc/pxa-mmc.txt | 5 + .../devicetree/bindings/rtc/rtc-ds1302.txt | 14 + .../devicetree/bindings/serial/lp8x4x-serial.txt | 35 ++ Documentation/misc-devices/lp8x4x_bus.txt | 74 +++ arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/pxa27x-lp8x4x.dts | 165 ++++++ arch/arm/boot/dts/pxa27x.dtsi | 20 + arch/arm/boot/dts/pxa2xx.dtsi | 5 +- arch/arm/configs/lp8x4x_defconfig | 164 ++++++ arch/arm/mach-pxa/Kconfig | 15 + arch/arm/mach-pxa/Makefile | 1 + arch/arm/mach-pxa/include/mach/irqs.h | 2 + arch/arm/mach-pxa/include/mach/pxa27x.h | 1 + arch/arm/mach-pxa/pxa27x-dt.c | 64 +++ arch/arm/mach-pxa/pxa27x.c | 10 + arch/arm/mach-pxa/pxa3xx.c | 2 - drivers/irqchip/Kconfig | 5 + drivers/irqchip/Makefile | 1 + drivers/irqchip/irq-lp8x4x.c | 238 +++++++++ drivers/misc/Kconfig | 13 + drivers/misc/Makefile | 1 + drivers/misc/lp8x4x_bus.c | 570 +++++++++++++++++++++ drivers/mmc/host/pxamci.c | 59 ++- drivers/mtd/devices/Kconfig | 14 + drivers/mtd/devices/Makefile | 1 + drivers/mtd/devices/sram_lp8x4x.c | 227 ++++++++ drivers/rtc/Kconfig | 2 +- drivers/rtc/rtc-ds1302.c | 111 +++- drivers/tty/serial/8250/8250_lp8x4x.c | 161 ++++++ drivers/tty/serial/8250/Kconfig | 12 + drivers/tty/serial/8250/Makefile | 1 + 33 files changed, 2042 insertions(+), 19 deletions(-) create mode 100644 Documentation/devicetree/bindings/interrupt-controller/irq-lp8x4x.txt create mode 100644 Documentation/devicetree/bindings/misc/lp8x4x-bus.txt create mode 100644 Documentation/devicetree/bindings/rtc/rtc-ds1302.txt create mode 100644 Documentation/devicetree/bindings/serial/lp8x4x-serial.txt create mode 100644 Documentation/misc-devices/lp8x4x_bus.txt create mode 100644 arch/arm/boot/dts/pxa27x-lp8x4x.dts create mode 100644 arch/arm/configs/lp8x4x_defconfig create mode 100644 arch/arm/mach-pxa/pxa27x-dt.c create mode 100644 drivers/irqchip/irq-lp8x4x.c create mode 100644 drivers/misc/lp8x4x_bus.c create mode 100644 drivers/mtd/devices/sram_lp8x4x.c create mode 100644 drivers/tty/serial/8250/8250_lp8x4x.c
On Fri, 2013-12-13 at 06:27 +0400, Sergei Ianovich wrote: > Fixed most review requirements. Details in respective patches. > > I've completely met the requirement for using dmaengine-based DMA > in patch v2-03/16. Tests showed new DMA was underperforming. It added > on top of a pre-existing problem with MMC bus width and made the system > barely usable. However, the new code in this patch work correctly with > both the existing and the new DMA. Even if the new DMA is compiled into > the kernel, the exisitng DMA initializes first. s/I've/I've not/
On Friday 13 December 2013, Sergei Ianovich wrote: > Fixed most review requirements. Details in respective patches. > > I've completely met the requirement for using dmaengine-based DMA > in patch v2-03/16. Tests showed new DMA was underperforming. It added > on top of a pre-existing problem with MMC bus width and made the system > barely usable. However, the new code in this patch work correctly with > both the existing and the new DMA. Even if the new DMA is compiled into > the kernel, the exisitng DMA initializes first. As mentioned, I think this is a good approach, as long as it's coordinated with Daniel's patches for the dmaengine. I would expect that once we get to the bottom of this, there will only be a small overhead from not directly using the dma registers but going through the dmaengine API. > I've also decided not to create a single mfd device for > machine-specific devices. Instead each type is supported by a separate > driver in respective subsystem. It was tempting to hardcode all the > constants in one source file, but that requires ugly initialization. > The taken way produces much cleaner code. I think you should at least change the DT representation for the FPGA to show one device as the actual FPGA and attach children to that, multiple indirection levels if necessary. I suspect that the fpga is on some external-bus port with a specific chip-select, so I would model this as extbus { compatible = "simple-bus"; #address-cells = <1>; #size-cells = <1>; /* bus addresses 0-0xfffff mapped to 0x17000000 */ ranges = <0 0x17000000 0x100000>; interrupt-parent = <&fpga-irq>; fpga-irq: irq@6 { regs = <6 16>; /* translated addresses ... }; fgpa-bus { #address-cells = <1>; #size-cells = <1>; ranges; serial@9050 { ... }; }; }; I also think you don't need to make the devices quite as fine-grained here but instead group things together more. I would probably indeed put everything that is not on one of the slots into a common device, including the irqchip. Arnd
On Sat, 2013-12-14 at 22:03 +0100, Arnd Bergmann wrote: > On Friday 13 December 2013, Sergei Ianovich wrote: > > I've also decided not to create a single mfd device for > > machine-specific devices. Instead each type is supported by a separate > > driver in respective subsystem. It was tempting to hardcode all the > > constants in one source file, but that requires ugly initialization. > > The taken way produces much cleaner code. > > I think you should at least change the DT representation for the FPGA > to show one device as the actual FPGA and attach children to that, > multiple indirection levels if necessary. > > I suspect that the fpga is on some external-bus port with a specific > chip-select, so I would model this as > > extbus { > compatible = "simple-bus"; > #address-cells = <1>; > #size-cells = <1>; > /* bus addresses 0-0xfffff mapped to 0x17000000 */ > ranges = <0 0x17000000 0x100000>; > interrupt-parent = <&fpga-irq>; > > fpga-irq: irq@6 { > regs = <6 16>; /* translated addresses > ... > }; > > fgpa-bus { > #address-cells = <1>; > #size-cells = <1>; > ranges; > > serial@9050 { > ... > }; > }; > }; > > I also think you don't need to make the devices quite as fine-grained > here but instead group things together more. I would probably indeed > put everything that is not on one of the slots into a common device, > including the irqchip. There are basically 2 options: one-for-all mfd device and one-for-one device drivers. MFD pros: * easy to add into the tree (one file) * easy config (one option) Separate devices * easy to support devices as respective subsystems evolve * easy to add new feature without breaking existing ones. Eg. it may make sense to provide industrial IO interface on analog IO devices * possible to have fine-grained configuration (eg. SRAM in kernel, serial and slot as modules) * proper device tree serves as a datasheet for the machine, so anyone who needs to work on it will have a decent view of the internals I believe long-term benefits of separate devices outweigh immediate effects of an MFD. However, I certainly don't see the big picture and will accept your decision. Please make one.
On Saturday 14 December 2013, Sergei Ianovich wrote: > On Sat, 2013-12-14 at 22:03 +0100, Arnd Bergmann wrote: > > On Friday 13 December 2013, Sergei Ianovich wrote: > > > I've also decided not to create a single mfd device for > > > machine-specific devices. Instead each type is supported by a separate > > > driver in respective subsystem. It was tempting to hardcode all the > > > constants in one source file, but that requires ugly initialization. > > > The taken way produces much cleaner code. > > > > I think you should at least change the DT representation for the FPGA > > to show one device as the actual FPGA and attach children to that, > > multiple indirection levels if necessary. > > > > I suspect that the fpga is on some external-bus port with a specific > > chip-select, so I would model this as > > > > extbus { > > compatible = "simple-bus"; > > #address-cells = <1>; > > #size-cells = <1>; > > /* bus addresses 0-0xfffff mapped to 0x17000000 */ > > ranges = <0 0x17000000 0x100000>; > > interrupt-parent = <&fpga-irq>; > > > > fpga-irq: irq@6 { > > regs = <6 16>; /* translated addresses > > ... > > }; > > > > fgpa-bus { > > #address-cells = <1>; > > #size-cells = <1>; > > ranges; > > > > serial@9050 { > > ... > > }; > > }; > > }; > > > > I also think you don't need to make the devices quite as fine-grained > > here but instead group things together more. I would probably indeed > > put everything that is not on one of the slots into a common device, > > including the irqchip. > > There are basically 2 options: one-for-all mfd device and one-for-one > device drivers. > > MFD > pros: > * easy to add into the tree (one file) > * easy config (one option) > > Separate devices > * easy to support devices as respective subsystems evolve > * easy to add new feature without breaking existing ones. Eg. it may > make sense to provide industrial IO interface on analog IO devices > * possible to have fine-grained configuration (eg. SRAM in kernel, > serial and slot as modules) > * proper device tree serves as a datasheet for the machine, so anyone > who needs to work on it will have a decent view of the internals > > I believe long-term benefits of separate devices outweigh immediate > effects of an MFD. However, I certainly don't see the big picture and > will accept your decision. Please make one. Unfortunately I don't have a good way to judge the tradeoffs without understanding more about the design of the hardware. Did I understand you right that you expect future versions of the FPGA bitstream to implement additional features or have a different set of endpoint devices? If so, I would argue that anything that you consider an optional sub-device should have its own device node in the device tree. Also, do you have to model hardware that is connected to the FPGA rather than being part of it? I suspect that you may have a different understanding of the term MFD than what I was suggesting: A typical MFD driver in Linux is basically a container device that has some registers on its own like a version detection or the irqchip but mainly is there to create sub-devices that each have a subset of the available registers. The sub-devices may or may not be describe in DT in this case. Arnd
On Sun, 2013-12-15 at 01:53 +0100, Arnd Bergmann wrote: > On Saturday 14 December 2013, Sergei Ianovich wrote: > > There are basically 2 options: one-for-all mfd device and one-for-one > > device drivers. > > > > MFD > > pros: > > * easy to add into the tree (one file) > > * easy config (one option) > > > > Separate devices > > * easy to support devices as respective subsystems evolve > > * easy to add new feature without breaking existing ones. Eg. it may > > make sense to provide industrial IO interface on analog IO devices > > * possible to have fine-grained configuration (eg. SRAM in kernel, > > serial and slot as modules) > > * proper device tree serves as a datasheet for the machine, so anyone > > who needs to work on it will have a decent view of the internals > > > > I believe long-term benefits of separate devices outweigh immediate > > effects of an MFD. However, I certainly don't see the big picture and > > will accept your decision. Please make one. > > Unfortunately I don't have a good way to judge the tradeoffs without > understanding more about the design of the hardware. Did I understand > you right that you expect future versions of the FPGA bitstream > to implement additional features or have a different set of endpoint > devices? I am trying to reduce time you spend on review as much as possible. Please feel free to say if I do something to the opposite. I could write a lengthy description of the machine as I understand it, if need be. I am not related to its vendor in any way, so it may or may not be correct. I've made to work 100% of features my client needs in the machine. It is ~80% of the devices on the frame and ~10% of possible slot modules. There are chances someone else will work on the rest, eg. the device vendor. This page contains a photo, if there is any interest to see how it looks like: http://www.icpdas.com/root/product/solutions/pac/linpac/lp-8x4x_hardware.html > If so, I would argue that anything that you consider an optional > sub-device should have its own device node in the device tree. > > Also, do you have to model hardware that is connected to the FPGA > rather than being part of it? Anything that can be plugged into the device is discoverable, so doesn't require to be in the device tree. > I suspect that you may have a different understanding of the term > MFD than what I was suggesting: A typical MFD driver in Linux is > basically a container device that has some registers on its own > like a version detection or the irqchip but mainly is there to > create sub-devices that each have a subset of the available > registers. The sub-devices may or may not be describe in DT in this > case. I may be missing something. My general understanding seems to be as follows. MFD will have probe/remove functionality of drivers for SRAM, RTC, serial modules in the patch series. MFD will be to FPGA what C language machine file was to machine: lots of hardcoded constants and functions which implement non-standard behavior (like set_termios in 8250_lp8x4x.c). This seems to be wrong to me, as device tree is specifically designed to handle platform device initialization. The tree you drafted in the previous mail was 100% correct. I though about doing something like that. I decided not to, since all devices behind the FPGA are transparently accessed by CPU. I like the idea. I haven't resent a series with FPGA bus only because you wrote in the same mail that we need an MFD. If you say so, we will have an MFD.
On Sunday 15 December 2013, Sergei Ianovich wrote: > On Sun, 2013-12-15 at 01:53 +0100, Arnd Bergmann wrote: > > On Saturday 14 December 2013, Sergei Ianovich wrote: > > Unfortunately I don't have a good way to judge the tradeoffs without > > understanding more about the design of the hardware. Did I understand > > you right that you expect future versions of the FPGA bitstream > > to implement additional features or have a different set of endpoint > > devices? > > I am trying to reduce time you spend on review as much as possible. > Please feel free to say if I do something to the opposite. > > I could write a lengthy description of the machine as I understand it, > if need be. I am not related to its vendor in any way, so it may or may > not be correct. > > I've made to work 100% of features my client needs in the machine. It is > ~80% of the devices on the frame and ~10% of possible slot modules. > There are chances someone else will work on the rest, eg. the device > vendor. > > This page contains a photo, if there is any interest to see how it looks > like: > http://www.icpdas.com/root/product/solutions/pac/linpac/lp-8x4x_hardware.html I see, thanks for the clarification. > > If so, I would argue that anything that you consider an optional > > sub-device should have its own device node in the device tree. > > > > Also, do you have to model hardware that is connected to the FPGA > > rather than being part of it? > > Anything that can be plugged into the device is discoverable, so doesn't > require to be in the device tree. Ah, good. > > I suspect that you may have a different understanding of the term > > MFD than what I was suggesting: A typical MFD driver in Linux is > > basically a container device that has some registers on its own > > like a version detection or the irqchip but mainly is there to > > create sub-devices that each have a subset of the available > > registers. The sub-devices may or may not be describe in DT in this > > case. > > I may be missing something. My general understanding seems to be as > follows. MFD will have probe/remove functionality of drivers for SRAM, > RTC, serial modules in the patch series. MFD will be to FPGA what C > language machine file was to machine: lots of hardcoded constants and > functions which implement non-standard behavior (like set_termios in > 8250_lp8x4x.c). This seems to be wrong to me, as device tree is > specifically designed to handle platform device initialization. > > The tree you drafted in the previous mail was 100% correct. I though > about doing something like that. I decided not to, since all devices > behind the FPGA are transparently accessed by CPU. I like the idea. I > haven't resent a series with FPGA bus only because you wrote in the same > mail that we need an MFD. > > If you say so, we will have an MFD. I think I was confused by the fact that the FPGA both has multiple integrated devices and multiple pluggable devices. Given your explanations, I think the way you have structured your code is good, and an MFD would not help. Please just restructure the DT representation to contain the external-bus and/or the fpga connected to it. You probably don't need both, but it doesn't hurt to show them as different device-nodes either. Your choice. Arnd
Two review comments are not finally settled:
1. Use of new DMA
My best guess is to split the patch in two, so that Daniel could easily
revert the workaround, once a solution is ready.
2. Device tree representation
I've put extbus into platform include file, since the bus is platform-
specific, not board-specific.
Frame support is now close to 95%, pluggable module support is
at around 20%. Most modules should be possible to handele by already
working get_DI/DO/AO set_DO/AO functions. I am not including support,
since I didn't actually tested the hardware. The same about RS232/485
pluggable port.
ICP DAS calls LP-8x4x 'programmable automation controller'. It is
an industrial computer based on PXA270 SoC. They ship it with a 2.6.19
kernel and proprietary kernel module and userspace library to access
its industrial IO.
This patch allows to boot the device with a modern kernel with device
tree. It adds support for:
* MMC card interface on PXA270
* USB 1.1 port on PXA270
* 2 NOR flash devices
* 2 onboard ethernet Davicom DM9000 devices
* 3 serial UART ports on PXA270
* front panel red LED
* 64bit 1-wire system ID chip
* 16 kiB EEPROM (reading)
Support for these devices will be added in separate patches, since
they are not currently supported by the kernel:
* DS1302 RTC
* 512kiB SRAM
* FPGA irq chip
* 3 built-in 16550A serial UART ports
* industrial IO parallel bus
* 10 position rotary switch
* 8 pin DIP switch
* 16 kiB EEPROM (writing)
* serial interface for digital and analog industrial IO modules on
parallel bus (all I-87... modules)
* digital and analog industrial IO modules for parallel bus:
** I-8024 4 port analog output
** I-8041 32 port digital output
** I-8042 16 port digital output/16 port digital input
Not supported for now:
* VGA interface on PXA270 for lack of dts binding
* the rest of parallel bus (I-8...) modules for lack of hardware
* GPIO reset for lack of relevance (watchdog reset is working)
NOTE: USB support requires U-Boot patch series which setups GPIO.
Signed-off-by: Sergei Ianovich <ynvich@gmail.com>
CC: Daniel Mack <zonque@gmail.com>
CC: Arnd Bergmann <arnd@arndb.de>
CC: Haojian Zhuang <haojian.zhuang@gmail.com>
Sergei Ianovich (21):
serial: rewrite pxa2xx-uart to use 8250_core
ARM: dts: pxa2xx fix compatible strings
ARM: dts: fix pxa27x-gpio interrupts
ARM: dts: pxa3xx: move declaration to header
ARM: dts: pxa27x: irq init using device tree
ARM: dts: provide DMA config to pxamci on PXA27x
ARM: dts: parse DMA config in pxamci
ARM: pxa27x: device tree support ICP DAS LP-8x4x
rtc: support DS1302 RTC on ICP DAS LP-8x4x
mtd: support BB SRAM on ICP DAS LP-8x4x
ARM: pxa: support ICP DAS LP-8x4x FPGA irq
serial: support for 16550A serial ports on LP-8x4x
misc: support for LP-8x4x custom parallel bus
misc: support for LP-8x4x rotary switch
misc: support for LP-8x4x DIP switch
misc: support for writing to LP-8x4x EEPROM
misc: support for serial slots in LP-8x4x
misc: support for parallel slots in LP-8x4x
misc: support for I-8041 in LP-8x4x
misc: support for I-8042 in LP-8x4x
misc: support for I-8024 in LP-8x4x
.../bindings/interrupt-controller/irq-lp8x4x.txt | 49 ++
.../devicetree/bindings/misc/lp8x4x-bus.txt | 34 +
Documentation/devicetree/bindings/mmc/pxa-mmc.txt | 5 +
.../devicetree/bindings/rtc/rtc-ds1302.txt | 14 +
.../devicetree/bindings/serial/lp8x4x-serial.txt | 35 +
Documentation/misc-devices/lp8x4x_bus.txt | 83 ++
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/pxa27x-lp8x4x.dts | 224 +++++
arch/arm/boot/dts/pxa27x.dtsi | 37 +
arch/arm/boot/dts/pxa2xx.dtsi | 5 +-
arch/arm/configs/am200epdkit_defconfig | 3 +-
arch/arm/configs/cm_x2xx_defconfig | 3 +-
arch/arm/configs/cm_x300_defconfig | 3 +-
arch/arm/configs/colibri_pxa270_defconfig | 3 +-
arch/arm/configs/colibri_pxa300_defconfig | 3 +-
arch/arm/configs/corgi_defconfig | 4 +-
arch/arm/configs/em_x270_defconfig | 3 +-
arch/arm/configs/ezx_defconfig | 3 +-
arch/arm/configs/h5000_defconfig | 3 +-
arch/arm/configs/imote2_defconfig | 3 +-
arch/arm/configs/lp8x4x_defconfig | 172 ++++
arch/arm/configs/lpd270_defconfig | 3 +-
arch/arm/configs/lubbock_defconfig | 3 +-
arch/arm/configs/mainstone_defconfig | 3 +-
arch/arm/configs/mmp2_defconfig | 3 +-
arch/arm/configs/pcm027_defconfig | 3 +-
arch/arm/configs/pxa168_defconfig | 3 +-
arch/arm/configs/pxa255-idp_defconfig | 3 +-
arch/arm/configs/pxa3xx_defconfig | 3 +-
arch/arm/configs/pxa910_defconfig | 3 +-
arch/arm/configs/raumfeld_defconfig | 3 +-
arch/arm/configs/spitz_defconfig | 4 +-
arch/arm/configs/trizeps4_defconfig | 3 +-
arch/arm/configs/viper_defconfig | 4 +-
arch/arm/configs/xcep_defconfig | 3 +-
arch/arm/mach-pxa/Kconfig | 15 +
arch/arm/mach-pxa/Makefile | 1 +
arch/arm/mach-pxa/include/mach/irqs.h | 2 +
arch/arm/mach-pxa/include/mach/pxa27x.h | 1 +
arch/arm/mach-pxa/pxa27x-dt.c | 64 ++
arch/arm/mach-pxa/pxa27x.c | 10 +
arch/arm/mach-pxa/pxa3xx.c | 2 -
drivers/irqchip/Kconfig | 5 +
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-lp8x4x.c | 205 +++++
drivers/misc/Kconfig | 13 +
drivers/misc/Makefile | 1 +
drivers/misc/lp8x4x_bus.c | 665 ++++++++++++++
drivers/mmc/host/pxamci.c | 59 +-
drivers/mtd/devices/Kconfig | 14 +
drivers/mtd/devices/Makefile | 1 +
drivers/mtd/devices/sram_lp8x4x.c | 227 +++++
drivers/rtc/Kconfig | 2 +-
drivers/rtc/rtc-ds1302.c | 100 ++-
drivers/tty/serial/8250/8250_lp8x4x.c | 162 ++++
drivers/tty/serial/8250/8250_pxa.c | 178 ++++
drivers/tty/serial/8250/Kconfig | 21 +
drivers/tty/serial/8250/Makefile | 2 +
drivers/tty/serial/Kconfig | 23 -
drivers/tty/serial/Makefile | 1 -
drivers/tty/serial/pxa.c | 971 ---------------------
61 files changed, 2439 insertions(+), 1041 deletions(-)
create mode 100644 Documentation/devicetree/bindings/interrupt-controller/irq-lp8x4x.txt
create mode 100644 Documentation/devicetree/bindings/misc/lp8x4x-bus.txt
create mode 100644 Documentation/devicetree/bindings/rtc/rtc-ds1302.txt
create mode 100644 Documentation/devicetree/bindings/serial/lp8x4x-serial.txt
create mode 100644 Documentation/misc-devices/lp8x4x_bus.txt
create mode 100644 arch/arm/boot/dts/pxa27x-lp8x4x.dts
create mode 100644 arch/arm/configs/lp8x4x_defconfig
create mode 100644 arch/arm/mach-pxa/pxa27x-dt.c
create mode 100644 drivers/irqchip/irq-lp8x4x.c
create mode 100644 drivers/misc/lp8x4x_bus.c
create mode 100644 drivers/mtd/devices/sram_lp8x4x.c
create mode 100644 drivers/tty/serial/8250/8250_lp8x4x.c
create mode 100644 drivers/tty/serial/8250/8250_pxa.c
delete mode 100644 drivers/tty/serial/pxa.c
Hi Arnd, We had an intensive discussion of the series in the beginning of December 2013 [1]. The discussion resulted in 3 versions of the series in less than 3 weeks. Then there was a decision to block this series until Daniel Mack's DMA-engine-for-PXA series is ready. Unfortunately Daniel neigther agrees to review my trivial temporary solution to the DMA-in-device-tree (patch 7 of 21), nor he is active in DMA series development. There is no progress for 3 months. As with any big out of tree series, its support is painful. It requires extensive merging when doing bisects, on each step. It would great if the decision to block could be reconsidered, and we could move forward. Best, Sergei Ianovich 1. http://linux-kernel.2935.n7.nabble.com/PATCH-00-11-ARM-support-for-ICP-DAS-LP-8x4x-td761919.html
Hi, On 04/16/2014 07:13 PM, Sergei Ianovich wrote: > We had an intensive discussion of the series in the beginning of > December 2013 [1]. The discussion resulted in 3 versions of the series > in less than 3 weeks. Then there was a decision to block this series > until Daniel Mack's DMA-engine-for-PXA series is ready. For whatever reason, I only received patches 1-8 out of 21 in this series. > Unfortunately Daniel neigther agrees to review my trivial temporary > solution to the DMA-in-device-tree (patch 7 of 21), nor he is active > in DMA series development. There is no progress for 3 months. Well, IIRC, I asked you to look into the MMC performance regressions that you reported and see what we can do about them. I currently don't have hardware to reproduce this, so I can't do it myself. My impression is that the transisiton will only be painless if the mmp_pdma driver provides comparable performance to the existing implementation. I also still think that adding hacks to the drivers to manually parse the dma properties (as in #8) brings us further away from a proper solution, not closer. > As with any big out of tree series, its support is painful. It requires > extensive merging when doing bisects, on each step. I know that, and I'm not violently against getting your patches in. I was just hoping for some help around here in order to sort out things and implement it properly. The reason why I haven't been working on these drivers lately is simply the sheer lack of time :( Thanks, Daniel
Daniel Mack <zonque@gmail.com> wrote: >Hi, > >On 04/16/2014 07:13 PM, Sergei Ianovich wrote: >> We had an intensive discussion of the series in the beginning of >> December 2013 [1]. The discussion resulted in 3 versions of the >series >> in less than 3 weeks. Then there was a decision to block this series >> until Daniel Mack's DMA-engine-for-PXA series is ready. > >For whatever reason, I only received patches 1-8 out of 21 in this >series. The rest is related to exotic parts of the tree and 'scripts/get_maintainer.pl' decided not to spam you. The whole series is sent to both lkml and arm lists. I can add you to cc by hand if you are interested. >> Unfortunately Daniel neigther agrees to review my trivial temporary >> solution to the DMA-in-device-tree (patch 7 of 21), nor he is active >> in DMA series development. There is no progress for 3 months. > >Well, IIRC, I asked you to look into the MMC performance regressions >that you reported and see what we can do about them. I currently don't >have hardware to reproduce this, so I can't do it myself. I hate to point fingers, but you promissed to refresh the code on several occasions. It is from 3.8 tree at the moment. The regression may be introduced by an error in my merging of your patches. I published the one I tested in one piece with the results. >My impression is that the transisiton will only be painless if the >mmp_pdma driver provides comparable performance to the existing >implementation. I also still think that adding hacks to the drivers to >manually parse the dma properties (as in #8) brings us further away >from >a proper solution, not closer No doubt about that. But the regression is not the only problem. Driver for video capture requires an extensive rewrite as well. The result is that a working pxa DT device is kept out of the tree and there is no supported DT devices in tree. So no proper examples for new devices and no drive-by improvements. All of this prevents rather than facilitates eventual DT migration of tha PXA platform.
On 04/16/2014 10:59 PM, Sergei Ianovich wrote: >> Well, IIRC, I asked you to look into the MMC performance >> regressions that you reported and see what we can do about them. I >> currently don't have hardware to reproduce this, so I can't do it >> myself. > > I hate to point fingers, but you promissed to refresh the code on > several occasions. It is from 3.8 tree at the moment. The regression > may be introduced by an error in my merging of your patches. I > published the one I tested in one piece with the results. Ok, well. I didn't see this as a potential reason, sorry. Point taken. I spent some hours on this topic again now, and rebased and tested my tree to 3.15-rc1. Pushed it here: https://github.com/zonque/linux/tree/pxa-dma-3.15 There's some overlap to the patches you sent, which I'll comment on directly soon. I'm booting my board with pxa[23]xx.dtsi taken from my tree. Please, if you find some time, test this tree and see if you still see the performance regression. >> My impression is that the transisiton will only be painless if the >> mmp_pdma driver provides comparable performance to the existing >> implementation. I also still think that adding hacks to the drivers >> to manually parse the dma properties (as in #8) brings us further >> away from a proper solution, not closer > > No doubt about that. But the regression is not the only problem. > Driver for video capture requires an extensive rewrite as well. Jup, I totally see your point. I was hoping for more support from someone with access to hardware to work on this, and possibly add the missing bits to the DMA framework to make the hot-linking possible. This didn't happen, which is unfortunate, so we in fact might need to recondider on how to move forward here. > The > result is that a working pxa DT device is kept out of the tree and > there is no supported DT devices in tree. So no proper examples for > new devices and no drive-by improvements. All of this prevents rather > than facilitates eventual DT migration of tha PXA platform. Ok, so how about this: 1. We keep the old API around, along with compat wrappers for existing drivers until someone finally finds time to at least test the patches that I can only compile-test myself. 2. For platforms that don't need those exotic drivers for devices that nobody seems to be interested in, use DT and the pxa-mmp-dma driver, and make sure it performs as well as the old implementation. 3. Do not add hacks for DT-compatability of existing drivers to make them work with the old DMA implementation (like your patch #7). 4. For new drivers, don't add any compat code for the old DMA implementation but soley rely on the new DMA framework. Does this sound suitable for you? Thanks, Daniel
On Thu, 2014-04-17 at 12:38 +0200, Daniel Mack wrote: > I spent some hours on this topic again now, and rebased and tested my > tree to 3.15-rc1. Pushed it here: > > https://github.com/zonque/linux/tree/pxa-dma-3.15 Great. > There's some overlap to the patches you sent, which I'll comment on > directly soon. > > I'm booting my board with pxa[23]xx.dtsi taken from my tree. > > Please, if you find some time, test this tree and see if you still see > the performance regression. Sure. > Ok, so how about this: > > 1. We keep the old API around, along with compat wrappers for existing > drivers until someone finally finds time to at least test the patches > that I can only compile-test myself. > > 2. For platforms that don't need those exotic drivers for devices that > nobody seems to be interested in, use DT and the pxa-mmp-dma driver, and > make sure it performs as well as the old implementation. > > 3. Do not add hacks for DT-compatability of existing drivers to make > them work with the old DMA implementation (like your patch #7). > > 4. For new drivers, don't add any compat code for the old DMA > implementation but soley rely on the new DMA framework. > > > > Does this sound suitable for you? No. I see no value in #3. There are obvious reasons to use DT whenever possible. #3 effectively blocks DT usage for new devices. I have all the reasons to believe, that LP-8x4x support would already have be merged, if I didn't try to use DT. My plan: A. We need to know whether the new DMA implementation performs on par with the old one. (I'm starting to check). if so B. We need to thinks whether it's acceptable to kill support for video capture. In short: if (A && B) we drop old DMA else we take my patch #7
On 04/17/2014 02:12 PM, Sergei Ianovich wrote: > On Thu, 2014-04-17 at 12:38 +0200, Daniel Mack wrote: >> 1. We keep the old API around, along with compat wrappers for existing >> drivers until someone finally finds time to at least test the patches >> that I can only compile-test myself. >> >> 2. For platforms that don't need those exotic drivers for devices that >> nobody seems to be interested in, use DT and the pxa-mmp-dma driver, and >> make sure it performs as well as the old implementation. >> >> 3. Do not add hacks for DT-compatability of existing drivers to make >> them work with the old DMA implementation (like your patch #7). >> >> 4. For new drivers, don't add any compat code for the old DMA >> implementation but soley rely on the new DMA framework. >> >> Does this sound suitable for you? > > No. I see no value in #3. There are obvious reasons to use DT whenever > possible. Of course. But if you do, you should really use the mmp-pdma driver, and make sure it works. That way, that driver gets more test coverage. Please, let's *not* introduce new hacks that lead to more users of the old DMA API instead. > #3 effectively blocks DT usage for new devices. No, it doesn't. It just makes sure those new boards use the new dma implementation, and obtain their DMA runtime information from the common APIs. After all, the problem here is the lack of users who are willing to dig into the DMA bits of the drivers they're using. By making it a requirement to use the new pdma driver, we can possibly change that. > I have all the > reasons to believe, that LP-8x4x support would already have be merged, > if I didn't try to use DT. That might be, but that's not the point. We want progress here, and that means we occasionally have to get rid of legacy. > My plan: > A. We need to know whether the new DMA implementation performs on par > with the old one. (I'm starting to check). Good, thanks! > if so > B. We need to thinks whether it's acceptable to kill support for video > capture. We can't. As I said, for this particular driver, we can keep the old API around. We can even make it depend on !CONFIG_DMA_ENGINE, so if anyone actually wants to use it with DT-enabled boards, we finally have a user and things can be fixed up. Similar for other drivers we can't test ourselves. > In short: > > if (A && B) > we drop old DMA > else > we take my patch #7 If A works, there's no need to for patch #7, right? If A doesn't work, we have to check why and fix it. Arnd, any oppinion on this? Thanks, Daniel
On Thursday 17 April 2014, Daniel Mack wrote: > On 04/17/2014 02:12 PM, Sergei Ianovich wrote: > > On Thu, 2014-04-17 at 12:38 +0200, Daniel Mack wrote > > I have all the > > reasons to believe, that LP-8x4x support would already have be merged, > > if I didn't try to use DT. > > That might be, but that's not the point. We want progress here, and that > means we occasionally have to get rid of legacy. In most cases, I would strongly support that statement. However, for PXA in particular, my opinion is that progress is not the highest priority as I see no realistic hope of converting all the existing machines over to use DT and change the platform to "multiplatform" support. Anything more modern than PXA I hope we can eventually get at least done for multiplatform, same for a few of the older and simpler platforms. Then again, I'm certainly not stopping you from trying to use add modern platforms to PXA. One of the ideas I had earlier was to extend mach-mmp enough to run any fully DT-enabled PXA machines and leave mach-pxa for the old ATAGS support and stuff like the legacy DMA support. However, I don't think we should try that as long as mach-mmp is lacking some essential DT support, e.g. for the clocks that were only partially converted to use the common clock framework. > > if so > > B. We need to thinks whether it's acceptable to kill support for video > > capture. > > We can't. As I said, for this particular driver, we can keep the old API > around. We can even make it depend on !CONFIG_DMA_ENGINE, so if anyone > actually wants to use it with DT-enabled boards, we finally have a user > and things can be fixed up. Similar for other drivers we can't test > ourselves. Sounds good to me. > > In short: > > > > if (A && B) > > we drop old DMA > > else > > we take my patch #7 > > If A works, there's no need to for patch #7, right? If A doesn't work, > we have to check why and fix it. > > Arnd, any oppinion on this? No strong opinion, I wouldn't object patch #7 if there is a strong reason to not use the dmaengine driver for PXA like I would object doing it for MMP. Then again, I see that you and recently also Laurent are driving a lot of good work on PXA, and if neither the arm-soc maintainers nor the three maintainers listed for mach-pxa have a strong opinion, I'd rather leave it up to your judgement. Arnd
diff --git a/arch/arm/configs/lp8x4x_defconfig b/arch/arm/configs/lp8x4x_defconfig new file mode 100644 index 0000000..2612e60 --- /dev/null +++ b/arch/arm/configs/lp8x4x_defconfig @@ -0,0 +1,235 @@ +CONFIG_CROSS_COMPILE="arm-linux-gnueabi-" +# CONFIG_LOCALVERSION_AUTO is not set +# CONFIG_SWAP is not set +CONFIG_SYSVIPC=y +CONFIG_NO_HZ=y +CONFIG_HIGH_RES_TIMERS=y +CONFIG_RCU_BOOST=y +CONFIG_LOG_BUF_SHIFT=14 +CONFIG_NAMESPACES=y +# CONFIG_UTS_NS is not set +# CONFIG_IPC_NS is not set +CONFIG_CC_OPTIMIZE_FOR_SIZE=y +# CONFIG_UID16 is not set +# CONFIG_SHMEM is not set +CONFIG_EMBEDDED=y +# CONFIG_COMPAT_BRK is not set +CONFIG_SLOB=y +CONFIG_JUMP_LABEL=y +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +CONFIG_MODVERSIONS=y +# CONFIG_LBDAF is not set +CONFIG_BLK_CMDLINE_PARSER=y +CONFIG_PARTITION_ADVANCED=y +CONFIG_BSD_DISKLABEL=y +CONFIG_MINIX_SUBPARTITION=y +CONFIG_SOLARIS_X86_PARTITION=y +CONFIG_UNIXWARE_DISKLABEL=y +CONFIG_LDM_PARTITION=y +# CONFIG_EFI_PARTITION is not set +# CONFIG_IOSCHED_DEADLINE is not set +CONFIG_ARCH_PXA=y +CONFIG_MACH_LP8X4X=y +# CONFIG_ARM_THUMB is not set +CONFIG_PREEMPT=y +CONFIG_AEABI=y +# CONFIG_COMPACTION is not set +# CONFIG_CROSS_MEMORY_ATTACH is not set +CONFIG_ZBOOT_ROM_TEXT=0x0 +CONFIG_ZBOOT_ROM_BSS=0x0 +CONFIG_CMDLINE="init=/sbin/init root=/dev/mmcblk0p1 rw rootfstype=ext4 console=ttyS0,115200 mem=128M rootwait" +# CONFIG_SUSPEND is not set +CONFIG_NET=y +CONFIG_PACKET=y +CONFIG_UNIX=y +CONFIG_INET=y +CONFIG_IP_PNP=y +CONFIG_IP_PNP_BOOTP=y +CONFIG_BRIDGE=m +CONFIG_BRIDGE_VLAN_FILTERING=y +CONFIG_VLAN_8021Q=m +CONFIG_VLAN_8021Q_GVRP=y +CONFIG_VLAN_8021Q_MVRP=y +# CONFIG_WIRELESS is not set +CONFIG_DEVTMPFS=y +CONFIG_DEVTMPFS_MOUNT=y +# CONFIG_FW_LOADER is not set +CONFIG_MTD=y +CONFIG_MTD_CMDLINE_PARTS=y +CONFIG_MTD_BLOCK=y +CONFIG_MTD_CFI=y +CONFIG_MTD_CFI_ADV_OPTIONS=y +CONFIG_MTD_CFI_GEOMETRY=y +CONFIG_MTD_CFI_INTELEXT=y +CONFIG_MTD_PXA2XX=y +CONFIG_BLK_DEV_LOOP=y +CONFIG_BLK_DEV_LOOP_MIN_COUNT=2 +CONFIG_SCSI=y +# CONFIG_SCSI_PROC_FS is not set +CONFIG_BLK_DEV_SD=y +# CONFIG_SCSI_LOWLEVEL is not set +CONFIG_NETDEVICES=y +CONFIG_BONDING=m +CONFIG_MACVLAN=m +CONFIG_MACVTAP=m +CONFIG_TUN=m +# CONFIG_NET_VENDOR_ARC is not set +# CONFIG_NET_CADENCE is not set +# CONFIG_NET_VENDOR_BROADCOM is not set +# CONFIG_NET_VENDOR_CIRRUS is not set +CONFIG_DM9000=y +CONFIG_DM9000_FORCE_SIMPLE_PHY_POLL=y +# CONFIG_NET_VENDOR_FARADAY is not set +# CONFIG_NET_VENDOR_INTEL is not set +# CONFIG_NET_VENDOR_MARVELL is not set +# CONFIG_NET_VENDOR_MICREL is not set +# CONFIG_NET_VENDOR_NATSEMI is not set +# CONFIG_NET_VENDOR_SEEQ is not set +# CONFIG_NET_VENDOR_SMSC is not set +# CONFIG_NET_VENDOR_STMICRO is not set +# CONFIG_NET_VENDOR_VIA is not set +# CONFIG_NET_VENDOR_WIZNET is not set +CONFIG_PPP=m +CONFIG_PPP_BSDCOMP=m +CONFIG_PPP_DEFLATE=m +CONFIG_PPPOE=m +CONFIG_PPP_ASYNC=m +CONFIG_PPP_SYNC_TTY=m +CONFIG_SLIP=m +CONFIG_SLIP_COMPRESSED=y +# CONFIG_WLAN is not set +CONFIG_INPUT_MOUSEDEV_SCREEN_X=800 +CONFIG_INPUT_MOUSEDEV_SCREEN_Y=600 +CONFIG_INPUT_EVDEV=y +# CONFIG_INPUT_KEYBOARD is not set +# CONFIG_INPUT_MOUSE is not set +# CONFIG_SERIO is not set +# CONFIG_DEVKMEM is not set +CONFIG_SERIAL_8250=y +# CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set +CONFIG_SERIAL_8250_CONSOLE=y +CONFIG_SERIAL_8250_NR_UARTS=40 +CONFIG_SERIAL_8250_RUNTIME_UARTS=40 +CONFIG_SERIAL_8250_EXTENDED=y +CONFIG_SERIAL_8250_MANY_PORTS=y +CONFIG_SERIAL_8250_SHARE_IRQ=y +CONFIG_SERIAL_PXA=y +CONFIG_HW_RANDOM=y +CONFIG_I2C=m +# CONFIG_I2C_COMPAT is not set +CONFIG_I2C_PXA=m +CONFIG_I2C_PXA_SLAVE=y +# CONFIG_HWMON is not set +CONFIG_WATCHDOG=y +CONFIG_SA1100_WATCHDOG=m +CONFIG_FB=y +CONFIG_FB_PXA=y +CONFIG_FRAMEBUFFER_CONSOLE=y +CONFIG_LOGO=y +CONFIG_HID_GENERIC=m +CONFIG_HID_A4TECH=m +CONFIG_HID_CYPRESS=m +CONFIG_HID_KEYTOUCH=m +CONFIG_HID_KENSINGTON=m +CONFIG_HID_LOGITECH=m +CONFIG_HID_MICROSOFT=m +CONFIG_HID_MONTEREY=m +CONFIG_USB_HIDDEV=y +CONFIG_I2C_HID=m +CONFIG_USB=m +CONFIG_USB_OHCI_HCD=m +CONFIG_USB_ACM=m +CONFIG_USB_PRINTER=m +CONFIG_USB_STORAGE=m +CONFIG_USB_STORAGE_REALTEK=m +CONFIG_USB_STORAGE_DATAFAB=m +CONFIG_USB_STORAGE_FREECOM=m +CONFIG_USB_STORAGE_ISD200=m +CONFIG_USB_STORAGE_USBAT=m +CONFIG_USB_STORAGE_SDDR09=m +CONFIG_USB_STORAGE_SDDR55=m +CONFIG_USB_STORAGE_JUMPSHOT=m +CONFIG_USB_STORAGE_ALAUDA=m +CONFIG_USB_STORAGE_ONETOUCH=m +CONFIG_USB_STORAGE_KARMA=m +CONFIG_USB_STORAGE_CYPRESS_ATACB=m +CONFIG_USB_STORAGE_ENE_UB6250=m +CONFIG_USB_SERIAL=m +CONFIG_USB_SERIAL_GENERIC=y +CONFIG_USB_SERIAL_SIMPLE=m +CONFIG_USB_SERIAL_AIRCABLE=m +CONFIG_USB_SERIAL_ARK3116=m +CONFIG_USB_SERIAL_BELKIN=m +CONFIG_USB_SERIAL_CH341=m +CONFIG_USB_SERIAL_WHITEHEAT=m +CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m +CONFIG_USB_SERIAL_CP210X=m +CONFIG_USB_SERIAL_CYPRESS_M8=m +CONFIG_USB_SERIAL_EMPEG=m +CONFIG_USB_SERIAL_FTDI_SIO=m +CONFIG_USB_SERIAL_VISOR=m +CONFIG_USB_SERIAL_IPAQ=m +CONFIG_USB_SERIAL_IR=m +CONFIG_USB_SERIAL_EDGEPORT=m +CONFIG_USB_SERIAL_EDGEPORT_TI=m +CONFIG_USB_SERIAL_F81232=m +CONFIG_USB_SERIAL_GARMIN=m +CONFIG_USB_SERIAL_IPW=m +CONFIG_USB_SERIAL_IUU=m +CONFIG_USB_SERIAL_KEYSPAN_PDA=m +CONFIG_USB_SERIAL_KEYSPAN=m +CONFIG_USB_SERIAL_KLSI=m +CONFIG_USB_SERIAL_KOBIL_SCT=m +CONFIG_USB_SERIAL_MCT_U232=m +CONFIG_USB_SERIAL_METRO=m +CONFIG_USB_SERIAL_MOS7720=m +CONFIG_USB_SERIAL_MOS7840=m +CONFIG_USB_SERIAL_NAVMAN=m +CONFIG_USB_SERIAL_PL2303=m +CONFIG_USB_SERIAL_OTI6858=m +CONFIG_USB_SERIAL_QCAUX=m +CONFIG_USB_SERIAL_QUALCOMM=m +CONFIG_USB_SERIAL_SPCP8X5=m +CONFIG_USB_SERIAL_SAFE=m +CONFIG_USB_SERIAL_SAFE_PADDED=y +CONFIG_USB_SERIAL_SIERRAWIRELESS=m +CONFIG_USB_SERIAL_SYMBOL=m +CONFIG_USB_SERIAL_TI=m +CONFIG_USB_SERIAL_CYBERJACK=m +CONFIG_USB_SERIAL_XIRCOM=m +CONFIG_USB_SERIAL_OPTION=m +CONFIG_USB_SERIAL_OMNINET=m +CONFIG_USB_SERIAL_OPTICON=m +CONFIG_USB_SERIAL_XSENS_MT=m +CONFIG_USB_SERIAL_WISHBONE=m +CONFIG_USB_SERIAL_ZTE=m +CONFIG_USB_SERIAL_SSU100=m +CONFIG_USB_SERIAL_QT2=m +CONFIG_MMC=y +CONFIG_MMC_PXA=y +CONFIG_RTC_CLASS=y +CONFIG_RTC_DRV_PXA=m +# CONFIG_IOMMU_SUPPORT is not set +CONFIG_EXT2_FS=m +CONFIG_EXT3_FS=y +CONFIG_EXT4_FS=y +CONFIG_REISERFS_FS=m +CONFIG_ISO9660_FS=m +CONFIG_MSDOS_FS=y +CONFIG_VFAT_FS=y +CONFIG_NTFS_FS=m +CONFIG_NTFS_RW=y +CONFIG_JFFS2_FS=y +CONFIG_JFFS2_COMPRESSION_OPTIONS=y +CONFIG_NFS_FS=y +CONFIG_NFS_V4=y +CONFIG_ROOT_NFS=y +CONFIG_CIFS=m +CONFIG_CIFS_STATS=y +CONFIG_CODA_FS=m +CONFIG_NLS_DEFAULT="cp1251" +CONFIG_NLS_CODEPAGE_1251=y +CONFIG_NLS_ISO8859_1=y +CONFIG_NLS_UTF8=y +CONFIG_PRINTK_TIME=y diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig index 96100db..efaf2d0 100644 --- a/arch/arm/mach-pxa/Kconfig +++ b/arch/arm/mach-pxa/Kconfig @@ -273,6 +273,22 @@ config MACH_VPAC270 comment "End-user Products (sorted by vendor name)" +config MACH_LP8X4X + bool "ICP DAS LP-8X4X" + select IWMMXT + select PXA27x + help + Say Y here if you intend to run this kernel on an ICP DAS + LP-8x4x programmable automation controller. + + LP-8x4x is ARM-based and built around PXA270 SoC. The device + has 128 MiB SDRAM, 48 or 96 MiB NOR flash, VGA port with + 800x600 resolution, MMC card slot, 2 Ethernet ports, 1 USB + port, 5 serial ports (1 on them is wired internally to + expansion slots). The device has a range of digital and + analog expansion IO modules which can be installed in 1, 4 or + 8 slots depending on the model. + config MACH_H4700 bool "HP iPAQ hx4700" select HAVE_PWM diff --git a/arch/arm/mach-pxa/Makefile b/arch/arm/mach-pxa/Makefile index 648867a..b264325 100644 --- a/arch/arm/mach-pxa/Makefile +++ b/arch/arm/mach-pxa/Makefile @@ -63,6 +63,7 @@ obj-$(CONFIG_MACH_COLIBRI320) += colibri-pxa3xx.o colibri-pxa320.o obj-$(CONFIG_MACH_VPAC270) += vpac270.o # End-user Products +obj-$(CONFIG_MACH_LP8X4X) += lp8x4x.o obj-$(CONFIG_MACH_H4700) += hx4700.o obj-$(CONFIG_MACH_H5000) += h5000.o obj-$(CONFIG_MACH_HIMALAYA) += himalaya.o diff --git a/arch/arm/mach-pxa/lp8x4x.c b/arch/arm/mach-pxa/lp8x4x.c new file mode 100644 index 0000000..0d3d8c0 --- /dev/null +++ b/arch/arm/mach-pxa/lp8x4x.c @@ -0,0 +1,473 @@ +/* + * linux/arch/arm/mach-pxa/lp8x4x.c + * + * Support for ICP DAS LP-8x4x programmable automation controller + * Copyright (C) 2013 Sergei Ianovich <ynvich@gmail.com> + * + * borrowed heavily from + * Support for the Intel HCDDBBVA0 Development Platform. + * + * Author: Nicolas Pitre + * Created: Nov 05, 2002 + * Copyright: MontaVista Software Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation or any later version. + */ +#include <linux/gpio.h> +#include <linux/init.h> +#include <linux/platform_device.h> +#include <linux/syscore_ops.h> +#include <linux/interrupt.h> +#include <linux/sched.h> +#include <linux/bitops.h> +#include <linux/fb.h> +#include <linux/ioport.h> +#include <linux/mtd/mtd.h> +#include <linux/mtd/partitions.h> +#include <linux/input.h> +#include <linux/dm9000.h> +#include <linux/slab.h> +#include <linux/leds.h> +#include <linux/ktime.h> +#include <linux/irqchip/chained_irq.h> + +#include <asm/types.h> +#include <asm/setup.h> +#include <asm/memory.h> +#include <asm/mach-types.h> +#include <mach/hardware.h> +#include <asm/irq.h> +#include <asm/sizes.h> + +#include <asm/mach/arch.h> +#include <asm/mach/map.h> +#include <asm/mach/irq.h> +#include <asm/mach/flash.h> + +#include <mach/irqs.h> +#include <mach/pxa27x.h> +#include <linux/platform_data/video-pxafb.h> +#include <linux/platform_data/mmc-pxamci.h> +#include <linux/platform_data/usb-ohci-pxa27x.h> +#include <mach/smemc.h> + +#include "generic.h" +#include "devices.h" + +#define LP8X4X_ETH0_BASE 0x0c000000 +#define LP8X4X_ETH0_IO 0x0c004000 +#define LP8X4X_ETH0_IRQ PXA_GPIO_TO_IRQ(9) + +#define LP8X4X_ETH1_BASE 0x0d000000 +#define LP8X4X_ETH1_IO 0x0d004000 +#define LP8X4X_ETH1_IRQ PXA_GPIO_TO_IRQ(82) + +#define LP8X4X_FPGA_PHYS 0x17000000 +#define LP8X4X_FPGA_VIRT ((void *) 0xf1000000) +#define LP8X4X_P2V(x) IOMEM((x) - LP8X4X_FPGA_PHYS + LP8X4X_FPGA_VIRT) +#define LP8X4X_V2P(x) ((x) - LP8X4X_FPGA_VIRT + LP8X4X_FPGA_PHYS) + +/* board level registers in the FPGA */ + +#define LP8X4X_EOI LP8X4X_P2V(0x17009006) +#define LP8X4X_INSINT LP8X4X_P2V(0x17009008) +#define LP8X4X_ENSYSINT LP8X4X_P2V(0x1700900A) +#define LP8X4X_PRIMINT LP8X4X_P2V(0x1700900C) +#define LP8X4X_SECOINT LP8X4X_P2V(0x1700900E) +#define LP8X4X_ENRISEINT LP8X4X_P2V(0x17009010) +#define LP8X4X_CLRRISEINT LP8X4X_P2V(0x17009012) +#define LP8X4X_ENHILVINT LP8X4X_P2V(0x17009014) +#define LP8X4X_CLRHILVINT LP8X4X_P2V(0x17009016) +#define LP8X4X_ENFALLINT LP8X4X_P2V(0x17009018) +#define LP8X4X_CLRFALLINT LP8X4X_P2V(0x1700901a) + +/* board specific IRQs */ + +#define LP8X4X_IRQ(x) (IRQ_BOARD_START + (x)) +#define LP8X4X_SLOT1_IRQ LP8X4X_IRQ(0) +#define LP8X4X_SLOT2_IRQ LP8X4X_IRQ(1) +#define LP8X4X_SLOT3_IRQ LP8X4X_IRQ(2) +#define LP8X4X_SLOT4_IRQ LP8X4X_IRQ(3) +#define LP8X4X_SLOT5_IRQ LP8X4X_IRQ(4) +#define LP8X4X_SLOT6_IRQ LP8X4X_IRQ(5) +#define LP8X4X_SLOT7_IRQ LP8X4X_IRQ(6) +#define LP8X4X_SLOT8_IRQ LP8X4X_IRQ(7) +#define LP8X4X_TIMER1_IRQ LP8X4X_IRQ(8) +#define LP8X4X_TIMER2_IRQ LP8X4X_IRQ(9) +#define LP8X4X_TIMEROUT_IRQ LP8X4X_IRQ(10) +#define LP8X4X_HOTPLUG_IRQ LP8X4X_IRQ(11) +#define LP8X4X_BATLOW_IRQ LP8X4X_IRQ(12) +#define LP8X4X_TTYS0_IRQ LP8X4X_IRQ(13) +#define LP8X4X_TTYS1_IRQ LP8X4X_IRQ(14) +#define LP8X4X_TTYS2_IRQ LP8X4X_IRQ(15) + +#define LP8X4X_NR_IRQS (IRQ_BOARD_START + 16) + +static unsigned char lp8x4x_irq_sys_enabled; +static unsigned char lp8x4x_irq_high_enabled; + +static void lp8x4x_ack_irq(struct irq_data *d) +{ + unsigned mask; + int irq = d->irq - IRQ_BOARD_START; + + if (irq < 0 || irq > 15) { + pr_err("lp8x4x: wrong irq handler for irq %i\n", d->irq); + return; + } + + if (irq < 8) { + mask = ioread8(LP8X4X_CLRHILVINT); + mask |= 1 << irq; + iowrite8(mask, LP8X4X_CLRHILVINT); + } else if (irq < 13) { + irq -= 8; + mask = ioread8(LP8X4X_SECOINT); + mask |= 1 << irq; + iowrite8(mask, LP8X4X_SECOINT); + } else { + irq -= 8; + mask = ioread8(LP8X4X_PRIMINT); + mask |= 1 << irq; + iowrite8(mask, LP8X4X_PRIMINT); + } +} + +static void lp8x4x_mask_irq(struct irq_data *d) +{ + int irq = d->irq - IRQ_BOARD_START; + + if (irq < 0 || irq > 15) { + pr_err("lp8x4x: wrong irq handler for irq %i\n", d->irq); + return; + } + + if (irq < 8) { + lp8x4x_irq_high_enabled &= ~(1 << irq); + iowrite8(lp8x4x_irq_high_enabled, LP8X4X_ENHILVINT); + } else { + irq -= 8; + lp8x4x_irq_sys_enabled &= ~(1 << irq); + iowrite8(lp8x4x_irq_sys_enabled, LP8X4X_ENSYSINT); + } +} + +static void lp8x4x_unmask_irq(struct irq_data *d) +{ + unsigned mask; + int irq = d->irq - IRQ_BOARD_START; + + if (irq < 0 || irq > 15) { + pr_err("wrong irq handler for irq %i\n", d->irq); + return; + } + + if (irq < 8) { + lp8x4x_irq_high_enabled |= 1 << irq; + mask = ioread8(LP8X4X_CLRHILVINT); + mask |= 1 << irq; + iowrite8(mask, LP8X4X_CLRHILVINT); + iowrite8(lp8x4x_irq_high_enabled, LP8X4X_ENHILVINT); + } else if (irq < 13) { + irq -= 8; + lp8x4x_irq_sys_enabled |= 1 << irq; + mask = ioread8(LP8X4X_SECOINT); + mask |= 1 << irq; + iowrite8(mask, LP8X4X_SECOINT); + iowrite8(lp8x4x_irq_sys_enabled, LP8X4X_ENSYSINT); + } else { + irq -= 8; + lp8x4x_irq_sys_enabled |= 1 << irq; + mask = ioread8(LP8X4X_PRIMINT); + mask |= 1 << irq; + iowrite8(mask, LP8X4X_PRIMINT); + iowrite8(lp8x4x_irq_sys_enabled, LP8X4X_ENSYSINT); + } +} + +static struct irq_chip lp8x4x_irq_chip = { + .name = "FPGA", + .irq_ack = lp8x4x_ack_irq, + .irq_mask = lp8x4x_mask_irq, + .irq_unmask = lp8x4x_unmask_irq, +}; + +static spinlock_t fpga_irq_lock; + +static void lp8x4x_irq_handler(unsigned int irq, struct irq_desc *desc) +{ + int loop, n; + unsigned long mask; + unsigned long flags; + struct irq_chip *chip = irq_desc_get_chip(desc); + + spin_lock_irqsave(&fpga_irq_lock, flags); + chained_irq_enter(chip, desc); + + do { + loop = 0; + mask = ioread8(LP8X4X_CLRHILVINT) & 0xff; + mask |= (ioread8(LP8X4X_SECOINT) & 0x1f) << 8; + mask |= (ioread8(LP8X4X_PRIMINT) & 0xe0) << 8; + mask &= (lp8x4x_irq_high_enabled + | (lp8x4x_irq_sys_enabled << 8)); + for_each_set_bit(n, &mask, BITS_PER_LONG) { + loop = 1; + + generic_handle_irq(IRQ_BOARD_START + n); + } + } while (loop); + + chained_irq_exit(chip, desc); + iowrite8(0, LP8X4X_EOI); + spin_unlock_irqrestore(&fpga_irq_lock, flags); +} + +static void __init lp8x4x_init_irq(void) +{ + int irq; + int err; + + err = irq_set_irq_type(PXA_GPIO_TO_IRQ(3), IRQ_TYPE_EDGE_RISING); + if (err < 0) { + pr_err("lp8x4x: irq init failed\n"); + return; + } + + spin_lock_init(&fpga_irq_lock); + irq_set_chained_handler(PXA_GPIO_TO_IRQ(3), lp8x4x_irq_handler); + + for (irq = IRQ_BOARD_START; irq < LP8X4X_NR_IRQS; irq++) { + irq_set_chip_and_handler(irq, &lp8x4x_irq_chip, + handle_level_irq); + set_irq_flags(irq, IRQF_VALID | IRQF_PROBE); + } + + iowrite8(0, LP8X4X_CLRRISEINT); + iowrite8(0, LP8X4X_ENRISEINT); + iowrite8(0, LP8X4X_CLRFALLINT); + iowrite8(0, LP8X4X_ENFALLINT); + iowrite8(0, LP8X4X_CLRHILVINT); + iowrite8(0, LP8X4X_ENHILVINT); + iowrite8(0, LP8X4X_ENSYSINT); + iowrite8(0, LP8X4X_PRIMINT); + iowrite8(0, LP8X4X_SECOINT); + + return; +} + +static unsigned long lp8x4x_pin_config[] = { + /* MMC */ + GPIO32_MMC_CLK, + GPIO112_MMC_CMD, + GPIO92_MMC_DAT_0, + GPIO109_MMC_DAT_1, + GPIO110_MMC_DAT_2, + GPIO111_MMC_DAT_3, + + /* USB Host Port 1 */ + GPIO88_USBH1_PWR, + GPIO89_USBH1_PEN, +}; + +static struct resource lp8x4x_flash_resources[] __initdata = { + [0] = { + .start = PXA_CS0_PHYS, + .end = PXA_CS0_PHYS + SZ_64M - 1, + .flags = IORESOURCE_MEM, + }, + [1] = { + .start = PXA_CS1_PHYS, + .end = PXA_CS1_PHYS + SZ_32M - 1, + .flags = IORESOURCE_MEM, + }, +}; + +static struct mtd_partition lp8x4x_flash0_partitions[] = { + { + .name = "Bootloader", + .size = 0x00040000, + .offset = 0, + }, { + .name = "Settings", + .size = 0x00040000, + .offset = 0x00040000, + }, { + .name = "Kernel", + .size = 0x00280000, + .offset = 0x00080000, + }, { + .name = "Filesystem", + .size = MTDPART_SIZ_FULL, + .offset = 0x00300000 + } +}; + +static struct flash_platform_data lp8x4x_flash_data[] __initdata = { + { + .map_name = "cfi_probe", + .parts = lp8x4x_flash0_partitions, + .nr_parts = ARRAY_SIZE(lp8x4x_flash0_partitions), + .width = 4, + }, { + .map_name = "cfi_probe", + .parts = NULL, + .nr_parts = 0, + .width = 2, + } +}; + +static struct pxafb_mode_info lp8x4x_vga_60_mode = { + .pixclock = 38461, + .xres = 640, + .yres = 480, + .bpp = 16, + .hsync_len = 64, + .left_margin = 78, + .right_margin = 46, + .vsync_len = 12, + .upper_margin = 22, + .lower_margin = 10, + .sync = 0, +}; + +static struct pxafb_mach_info lp8x4x_pxafb_info = { + .num_modes = 1, + .lccr0 = LCCR0_Act, + .lccr3 = LCCR3_PCP, +}; + +static int lp8x4x_mci_init(struct device *dev, + irq_handler_t mstone_detect_int, void *data) +{ + return 0; +} + +static int lp8x4x_mci_setpower(struct device *dev, unsigned int vdd) +{ + return 0; +} + +static void lp8x4x_mci_exit(struct device *dev, void *data) +{ +} + +static struct pxamci_platform_data lp8x4x_mci_platform_data = { + .ocr_mask = MMC_VDD_32_33|MMC_VDD_33_34, + .init = lp8x4x_mci_init, + .setpower = lp8x4x_mci_setpower, + .exit = lp8x4x_mci_exit, + .gpio_card_detect = -1, + .gpio_card_ro = -1, + .gpio_power = -1, +}; + +static struct resource lp8x4x_dm9000_resources[] __initdata = { + [0] = { + .start = LP8X4X_ETH0_BASE, + .end = LP8X4X_ETH0_BASE + 2 - 1, + .flags = IORESOURCE_MEM, + }, + [1] = { + .start = LP8X4X_ETH0_IO, + .end = LP8X4X_ETH0_IO + 2 - 1, + .flags = IORESOURCE_MEM, + }, + [2] = { + .start = LP8X4X_ETH0_IRQ, + .end = LP8X4X_ETH0_IRQ, + .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_HIGHEDGE, + }, + [3] = { + .start = LP8X4X_ETH1_BASE, + .end = LP8X4X_ETH1_BASE + 2 - 1, + .flags = IORESOURCE_MEM, + }, + [4] = { + .start = LP8X4X_ETH1_IO, + .end = LP8X4X_ETH1_IO + 2 - 1, + .flags = IORESOURCE_MEM, + }, + [5] = { + .start = LP8X4X_ETH1_IRQ, + .end = LP8X4X_ETH1_IRQ, + .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_HIGHEDGE, + }, +}; + +static struct pxaohci_platform_data lp8x4x_ohci_platform_data = { + .port_mode = PMM_PERPORT_MODE, + .flags = ENABLE_PORT1 | OC_MODE_PERPORT, +}; + +static void lp8x4x_restart(enum reboot_mode mode, const char *cmd) +{ + /* Switch off fast-bus and turbo mode */ + asm volatile("mcr p14, 0, %0, c6, c0, 0" : : + "r"(2)); + /* SDRAM hangs on watchdog reset on Marvell PXA270 (erratum 71) */ + pxa_restart(REBOOT_SOFT, cmd); +} + +static void __init lp8x4x_init(void) +{ + pxa2xx_mfp_config(ARRAY_AND_SIZE(lp8x4x_pin_config)); + + pxa_set_ffuart_info(NULL); + pxa_set_btuart_info(NULL); + pxa_set_stuart_info(NULL); + + /* system bus arbiter setting + * - Core_Park + * - LCD_wt:DMA_wt:CORE_Wt = 2:3:4 + */ + ARB_CNTRL = ARB_CORE_PARK | 0x234; + + pxa_set_mci_info(&lp8x4x_mci_platform_data); + pxa_set_ohci_info(&lp8x4x_ohci_platform_data); + + platform_device_register_resndata(NULL, "pxa2xx-flash", 0, + &lp8x4x_flash_resources[0], 1, + &lp8x4x_flash_data[0], sizeof(lp8x4x_flash_data[0])); + platform_device_register_resndata(NULL, "pxa2xx-flash", 1, + &lp8x4x_flash_resources[1], 1, + &lp8x4x_flash_data[1], sizeof(lp8x4x_flash_data[1])); + platform_device_register_simple("dm9000", 0, + &lp8x4x_dm9000_resources[0], 3); + platform_device_register_simple("dm9000", 1, + &lp8x4x_dm9000_resources[3], 3); + + lp8x4x_pxafb_info.modes = &lp8x4x_vga_60_mode; + pxa_set_fb_info(NULL, &lp8x4x_pxafb_info); + + /* Could not do this in MACHINE since GPIO is not ready then */ + lp8x4x_init_irq(); +} + +static struct map_desc lp8x4x_io_desc[] __initdata = { + { /* CPLD */ + .virtual = (unsigned long) LP8X4X_FPGA_VIRT, + .pfn = __phys_to_pfn(LP8X4X_FPGA_PHYS), + .length = 0x00100000, + .type = MT_DEVICE + } +}; + +static void __init lp8x4x_map_io(void) +{ + pxa27x_map_io(); + iotable_init(lp8x4x_io_desc, ARRAY_SIZE(lp8x4x_io_desc)); +} + +MACHINE_START(LP8X4X, "ICP DAS LP-8x4x programmable automation controller") + .atag_offset = 0x100, + .map_io = lp8x4x_map_io, + .nr_irqs = LP8X4X_NR_IRQS, + .init_irq = pxa27x_init_irq, + .handle_irq = pxa27x_handle_irq, + .init_time = pxa_timer_init, + .init_machine = lp8x4x_init, + .restart = lp8x4x_restart, +MACHINE_END
ICP DAS calls LP-8x4x 'programmable automation controller'. It is an industrial computer based on PXA270 SoC. They ship it with a 2.6.19 kernel and proprietary kernel module and userspace library to access its industrial IO. This patch allows to boot the device with a modern kernel. It adds support for: * FPGA irq chip * MMC card interface on PXA270 * USB 1.1 port on PXA270 * 2 NOR flash devices * VGA interface on PXA270 * 2 onboard ethernet Davicom DM9000 devices * 3 serial UART ports on PXA270 Support for these devices will be added in separate patches, since they are not currently supported by the kernel: * DS1302 RTC * 512kiB SRAM * 3 built-in and up to 32 pluggable 8250 serial UART ports * industrial IO parallel bus * digital and analog industrial IO modules for parallel bus * serial interface for digital and analog industrial IO modules on parallel bus Signed-off-by: Sergei Ianovich <ynvich@gmail.com> CC: Arnd Bergmann <arnd@arndb.de> --- changes v1..v2 * clean up defconfig (reduces size by 10) as suggested by Arnd Bergmann * fixed constant address definition to include (void *) cast as suggested by Arnd Bergmann * moved fixed virtual addresses into the machine source file. Header file is dropped. * static platform devices are replaced by dynamically allocated as suggested by Arnd Bergmann arch/arm/configs/lp8x4x_defconfig | 235 +++++++++++++++++++ arch/arm/mach-pxa/Kconfig | 16 ++ arch/arm/mach-pxa/Makefile | 1 + arch/arm/mach-pxa/lp8x4x.c | 473 ++++++++++++++++++++++++++++++++++++++ 4 files changed, 725 insertions(+) create mode 100644 arch/arm/configs/lp8x4x_defconfig create mode 100644 arch/arm/mach-pxa/lp8x4x.c