Re: [PATCH v2 02/11] arm: pxa27x: support ICP DAS LP-8x4x
On Tue, Dec 10, 2013 at 1:54 PM, Vasily Khoruzhick wrote: > On Tue, Dec 10, 2013 at 3:43 PM, 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 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=138629591206248=2 Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 02/11] arm: pxa27x: support ICP DAS LP-8x4x
On Tue, Dec 10, 2013 at 1:47 PM, Sergei Ianovich 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 02/11] arm: pxa27x: support ICP DAS LP-8x4x
On Tue, Dec 10, 2013 at 1:47 PM, Sergei Ianovich ynv...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 02/11] arm: pxa27x: support ICP DAS LP-8x4x
On Tue, Dec 10, 2013 at 1:54 PM, Vasily Khoruzhick anars...@gmail.com wrote: On Tue, Dec 10, 2013 at 3:43 PM, Linus Walleij linus.wall...@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-docm=138629591206248w=2 Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 02/11] arm: pxa27x: support ICP DAS LP-8x4x
On Tue, 10 Dec 2013 13:43:27 +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 plan to work on pxa2xx (pxa25x to be precise) after finishing with sa1100 - my second (well, first) PDA is Sharp SL-6000 (pxa255). StrongARM somewhat resembles pxa2xx, so some of the drivers will be shared, some expertise will be shared, etc. I tried doing pxa first, but later found that it might be easier to update sa1100. -- With best wishes Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 02/11] arm: pxa27x: support ICP DAS LP-8x4x
On Tue, Dec 10, 2013 at 3:43 PM, Linus Walleij wrote:
> On Fri, Dec 6, 2013 at 5:48 PM, Sergei Ianovich 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-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 02/11] arm: pxa27x: support ICP DAS LP-8x4x
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/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 02/11] arm: pxa27x: support ICP DAS LP-8x4x
On Fri, Dec 6, 2013 at 5:48 PM, Sergei Ianovich 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 02/11] arm: pxa27x: support ICP DAS LP-8x4x
On Tue, 10 Dec 2013 13:43:27 +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 plan to work on pxa2xx (pxa25x to be precise) after finishing with sa1100 - my second (well, first) PDA is Sharp SL-6000 (pxa255). StrongARM somewhat resembles pxa2xx, so some of the drivers will be shared, some expertise will be shared, etc. I tried doing pxa first, but later found that it might be easier to update sa1100. -- With best wishes Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 02/11] arm: pxa27x: support ICP DAS LP-8x4x
On Fri, Dec 6, 2013 at 5:48 PM, Sergei Ianovich ynv...@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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 02/11] arm: pxa27x: support ICP DAS LP-8x4x
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/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 02/11] arm: pxa27x: support ICP DAS LP-8x4x
On Tue, Dec 10, 2013 at 3:43 PM, Linus Walleij linus.wall...@linaro.org wrote:
On Fri, Dec 6, 2013 at 5:48 PM, Sergei Ianovich ynv...@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-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 02/11] arm: pxa27x: support ICP DAS LP-8x4x
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 02/11] arm: pxa27x: support ICP DAS LP-8x4x
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 02/11] arm: pxa27x: support ICP DAS LP-8x4x
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 0x1700
> > +#define LP8X4X_FPGA_VIRT ((void *) 0xf100)
> > +#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 *) 0xf100)
> #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_INSINTLP8X4X_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_CLRRISEINTLP8X4X_P2V(0x17009012)
> > +#define LP8X4X_ENHILVINT LP8X4X_P2V(0x17009014)
> > +#define LP8X4X_CLRHILVINTLP8X4X_P2V(0x17009016)
> > +#define LP8X4X_ENFALLINT LP8X4X_P2V(0x17009018)
> > +#define LP8X4X_CLRFALLINTLP8X4X_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,
> > + _flash_resources[0], 1,
> > + _flash_data[0], sizeof(lp8x4x_flash_data[0]));
> > + platform_device_register_resndata(NULL, "pxa2xx-flash", 1,
> > + _flash_resources[1], 1,
> > + _flash_data[1], sizeof(lp8x4x_flash_data[1]));
> > + platform_device_register_simple("dm9000", 0,
> > + _dm9000_resources[0], 3);
> > + platform_device_register_simple("dm9000", 1,
> > + _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,
> _flash_resources0, 1,
> _flash_data0, sizeof(lp8x4x_flash_data0));
> platform_device_register_resndata(NULL, "pxa2xx-flash", 1,
> _flash_resources1, 1,
> _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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 02/11] arm: pxa27x: support ICP DAS LP-8x4x
On Friday 06 December 2013, Sergei Ianovich wrote:
> new file mode 100644
> index 000..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 0x1700
> +#define LP8X4X_FPGA_VIRT ((void *) 0xf100)
> +#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 *) 0xf100)
#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_INSINTLP8X4X_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_CLRRISEINTLP8X4X_P2V(0x17009012)
> +#define LP8X4X_ENHILVINT LP8X4X_P2V(0x17009014)
> +#define LP8X4X_CLRHILVINTLP8X4X_P2V(0x17009016)
> +#define LP8X4X_ENFALLINT LP8X4X_P2V(0x17009018)
> +#define LP8X4X_CLRFALLINTLP8X4X_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,
> + _flash_resources[0], 1,
> + _flash_data[0], sizeof(lp8x4x_flash_data[0]));
> + platform_device_register_resndata(NULL, "pxa2xx-flash", 1,
> + _flash_resources[1], 1,
> + _flash_data[1], sizeof(lp8x4x_flash_data[1]));
> + platform_device_register_simple("dm9000", 0,
> + _dm9000_resources[0], 3);
> + platform_device_register_simple("dm9000", 1,
> + _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,
_flash_resources0, 1,
_flash_data0, sizeof(lp8x4x_flash_data0));
platform_device_register_resndata(NULL, "pxa2xx-flash", 1,
_flash_resources1, 1,
_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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 02/11] arm: pxa27x: support ICP DAS LP-8x4x
On Friday 06 December 2013, Sergei Ianovich wrote: new file mode 100644 index 000..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 0x1700 +#define LP8X4X_FPGA_VIRT ((void *) 0xf100) +#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 *) 0xf100) #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_INSINTLP8X4X_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_CLRRISEINTLP8X4X_P2V(0x17009012) +#define LP8X4X_ENHILVINT LP8X4X_P2V(0x17009014) +#define LP8X4X_CLRHILVINTLP8X4X_P2V(0x17009016) +#define LP8X4X_ENFALLINT LP8X4X_P2V(0x17009018) +#define LP8X4X_CLRFALLINTLP8X4X_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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 02/11] arm: pxa27x: support ICP DAS LP-8x4x
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 0x1700 +#define LP8X4X_FPGA_VIRT ((void *) 0xf100) +#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 *) 0xf100) #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_INSINTLP8X4X_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_CLRRISEINTLP8X4X_P2V(0x17009012) +#define LP8X4X_ENHILVINT LP8X4X_P2V(0x17009014) +#define LP8X4X_CLRHILVINTLP8X4X_P2V(0x17009016) +#define LP8X4X_ENFALLINT LP8X4X_P2V(0x17009018) +#define LP8X4X_CLRFALLINTLP8X4X_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. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 02/11] arm: pxa27x: support ICP DAS LP-8x4x
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 CC: Arnd Bergmann --- 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 diff --git a/arch/arm/configs/lp8x4x_defconfig b/arch/arm/configs/lp8x4x_defconfig new file mode 100644 index 000..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
[PATCH v2 02/11] arm: pxa27x: support ICP DAS LP-8x4x
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 ynv...@gmail.com CC: Arnd Bergmann a...@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 diff --git a/arch/arm/configs/lp8x4x_defconfig b/arch/arm/configs/lp8x4x_defconfig new file mode 100644 index 000..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
