diff mbox

[v2,02/11] arm: pxa27x: support ICP DAS LP-8x4x

Message ID 1386348542-9584-1-git-send-email-ynvich@gmail.com (mailing list archive)
State New, archived
Headers show

Commit Message

Sergey Yanovich Dec. 6, 2013, 4:48 p.m. UTC
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

Comments

Arnd Bergmann Dec. 8, 2013, 2:21 a.m. UTC | #1
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
Sergey Yanovich Dec. 8, 2013, 7:05 a.m. UTC | #2
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.
Sergey Yanovich Dec. 8, 2013, 10:53 p.m. UTC | #3
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
Arnd Bergmann Dec. 9, 2013, 12:54 a.m. UTC | #4
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
Arnd Bergmann Dec. 9, 2013, 1:51 a.m. UTC | #5
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
Sergey Yanovich Dec. 9, 2013, 6:44 p.m. UTC | #6
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?
Linus Walleij Dec. 10, 2013, 12:43 p.m. UTC | #7
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
Sergey Yanovich Dec. 10, 2013, 12:47 p.m. UTC | #8
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/
Vasily Khoruzhick Dec. 10, 2013, 12:54 p.m. UTC | #9
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
Linus Walleij Dec. 12, 2013, 7:58 p.m. UTC | #10
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
Linus Walleij Dec. 12, 2013, 8:07 p.m. UTC | #11
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
Sergey Yanovich Dec. 13, 2013, 2:27 a.m. UTC | #12
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
Sergey Yanovich Dec. 13, 2013, 2:33 a.m. UTC | #13
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/
Arnd Bergmann Dec. 14, 2013, 9:03 p.m. UTC | #14
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
Sergey Yanovich Dec. 14, 2013, 9:55 p.m. UTC | #15
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.
Arnd Bergmann Dec. 15, 2013, 12:53 a.m. UTC | #16
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
Sergey Yanovich Dec. 15, 2013, 2:12 a.m. UTC | #17
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.
Arnd Bergmann Dec. 15, 2013, 2:55 a.m. UTC | #18
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
Sergey Yanovich Dec. 17, 2013, 7:37 p.m. UTC | #19
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
Sergey Yanovich April 16, 2014, 5:13 p.m. UTC | #20
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
Daniel Mack April 16, 2014, 5:39 p.m. UTC | #21
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
Sergey Yanovich April 16, 2014, 8:59 p.m. UTC | #22
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.
Daniel Mack April 17, 2014, 10:38 a.m. UTC | #23
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
Sergey Yanovich April 17, 2014, 12:12 p.m. UTC | #24
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
Daniel Mack April 17, 2014, 12:34 p.m. UTC | #25
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
Arnd Bergmann April 19, 2014, 11:59 a.m. UTC | #26
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 mbox

Patch

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