login
Search
This adds support for the family of Systems-on-Chip produced initially by VIA and now its subsidiary WonderMedia that have recently become widespread in lower-end Chinese ARM-based tablets and netbooks. Support is included for both VT8500 and WM8505. Suitable code is selected (if compiled in) at early initialization time by reading a platform-specific identification register, as current bootloaders do not provide any reliable machine id to the kernel. Included are basic machine initialization files, register and interrupt definitions, support for the on-chip interrupt controller, high-precision OS timer, GPIO lines, necessary macros for early debug, pulse-width-modulated outputs control, as well as platform device configurations for the specific drivers implemented elsewhere. Signed-off-by: Alexey Charkov <alchark@gmail.com> --- Please review and (if appropriate) commit to a relevant git tree for further integration in 2.6.38. Compared to the previous submissions, this code introduces boot-time determintaion of SoC version (instead of just compile-time preselection), boot-argument override for the LCD panel size (used when preallocating frame buffer memory), better guesses for PCI I/O space configuration (thanks to Arnd Bergmann for suggestions), as well as a rebase against the latest changes introduced in 2.6.37 merge window. Due credits go to the community for providing feedback, advice and testing for the code in this patch and follow-ups. arch/arm/Kconfig | 14 + arch/arm/Makefile | 1 + arch/arm/boot/compressed/Makefile | 4 + arch/arm/boot/compressed/head-vt8500.S | 46 +++ arch/arm/mach-vt8500/Kconfig | 65 ++++ arch/arm/mach-vt8500/Makefile | 6 + arch/arm/mach-vt8500/Makefile.boot | 3 + arch/arm/mach-vt8500/bv07.c | 70 ++++ arch/arm/mach-vt8500/devices.c | 429 ...
This adds a driver for the serial ports found in VIA and WonderMedia Systems-on-Chip. Interrupt-driven FIFO operation is implemented. The hardware also supports pure register-based operation (which is slower) and DMA-based FIFO operation. As the FIFOs are only 16 bytes long, DMA operation is probably not worth the hassle. Signed-off-by: Alexey Charkov <alchark@gmail.com> --- Please review and (if appropriate) commit to a relevant git tree for further integration in 2.6.38. Compared to the previous submission, this code just contains a rebase against the latest changes introduced in 2.6.37 merge window. Relevant platform definitions are introduced by PATCH 1/6 in this series, so one would need that to make use of this code. Due credits go to the community for providing feedback, advice and testing. drivers/serial/Kconfig | 10 + drivers/serial/Makefile | 1 + drivers/serial/vt8500_serial.c | 637 ++++++++++++++++++++++++++++++++++++++++ include/linux/serial_core.h | 3 + 4 files changed, 651 insertions(+), 0 deletions(-) create mode 100644 drivers/serial/vt8500_serial.c diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig index aff9dcd..6e76a59 100644 --- a/drivers/serial/Kconfig +++ b/drivers/serial/Kconfig @@ -1381,6 +1381,16 @@ config SERIAL_MSM_CONSOLE depends on SERIAL_MSM=y select SERIAL_CORE_CONSOLE +config SERIAL_VT8500 + bool "VIA VT8500 on-chip serial port support" + depends on ARM && ARCH_VT8500 + select SERIAL_CORE + +config SERIAL_VT8500_CONSOLE + bool "VIA VT8500 serial console support" + depends on SERIAL_VT8500=y + select SERIAL_CORE_CONSOLE + config SERIAL_NETX tristate "NetX serial port support" depends on ARM && ARCH_NETX diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile index c570576..86b8587 100644 --- a/drivers/serial/Makefile +++ b/drivers/serial/Makefile @@ -86,6 +86,7 @@ obj-$(CONFIG_SERIAL_TIMBERDALE) += timbuart.o obj-$(CONFIG_SERIAL_GRLIB_GAISLER_APBUART) += ...
What is your locking for this versus a hangup ? - tty can go NULL ? If you don't support other CS values then also do termios->c_flag &=~CSIZE; termios->c_cflag |= CS8; here.. so the app knows, likewise if you don't support mark/space (CMSPAR) then clear the CMSPAR These major/minors belong to an existing device - use new ones, or in fact unless they must be fixed use dynamic ones. If they need fixed ones then we probably want to assign four from the range for small ports. The world really doesn't need to know about each driver being loaded. pr_debug() should be fine Looks pretty good. --
This adds a driver for the serial ports found in VIA and WonderMedia Systems-on-Chip. Interrupt-driven FIFO operation is implemented. The hardware also supports pure register-based operation (which is slower) and DMA-based FIFO operation. As the FIFOs are only 16 bytes long, DMA operation is probably not worth the hassle. Signed-off-by: Alexey Charkov <alchark@gmail.com> --- Thanks for the comments, Alan! Hopefully, I've fixed the issues in a right way. Best regards, Alexey drivers/serial/Kconfig | 10 + drivers/serial/Makefile | 1 + drivers/serial/vt8500_serial.c | 647 ++++++++++++++++++++++++++++++++++++++++ include/linux/serial_core.h | 3 + 4 files changed, 661 insertions(+), 0 deletions(-) create mode 100644 drivers/serial/vt8500_serial.c diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig index aff9dcd..6e76a59 100644 --- a/drivers/serial/Kconfig +++ b/drivers/serial/Kconfig @@ -1381,6 +1381,16 @@ config SERIAL_MSM_CONSOLE depends on SERIAL_MSM=y select SERIAL_CORE_CONSOLE +config SERIAL_VT8500 + bool "VIA VT8500 on-chip serial port support" + depends on ARM && ARCH_VT8500 + select SERIAL_CORE + +config SERIAL_VT8500_CONSOLE + bool "VIA VT8500 serial console support" + depends on SERIAL_VT8500=y + select SERIAL_CORE_CONSOLE + config SERIAL_NETX tristate "NetX serial port support" depends on ARM && ARCH_NETX diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile index c570576..86b8587 100644 --- a/drivers/serial/Makefile +++ b/drivers/serial/Makefile @@ -86,6 +86,7 @@ obj-$(CONFIG_SERIAL_TIMBERDALE) += timbuart.o obj-$(CONFIG_SERIAL_GRLIB_GAISLER_APBUART) += apbuart.o obj-$(CONFIG_SERIAL_ALTERA_JTAGUART) += altera_jtaguart.o obj-$(CONFIG_SERIAL_ALTERA_UART) += altera_uart.o +obj-$(CONFIG_SERIAL_VT8500) += vt8500_serial.o obj-$(CONFIG_SERIAL_MRST_MAX3110) += mrst_max3110.o obj-$(CONFIG_SERIAL_MFD_HSU) += mfd.o obj-$(CONFIG_SERIAL_OMAP) += omap-serial.o diff --git ...
You missed a ttyS Otherwise looks great. Alan --
This adds a driver for the serial ports found in VIA and WonderMedia Systems-on-Chip. Interrupt-driven FIFO operation is implemented. The hardware also supports pure register-based operation (which is slower) and DMA-based FIFO operation. As the FIFOs are only 16 bytes long, DMA operation is probably not worth the hassle. Signed-off-by: Alexey Charkov <alchark@gmail.com> --- This fixes the last remaining "ttyS" mentioned by Alan and also adds 6 as the number of UARTs (which is the case for WM8505, VT8500 has 4). drivers/serial/Kconfig | 10 + drivers/serial/Makefile | 1 + drivers/serial/vt8500_serial.c | 648 ++++++++++++++++++++++++++++++++++++++++ include/linux/serial_core.h | 3 + 4 files changed, 662 insertions(+), 0 deletions(-) create mode 100644 drivers/serial/vt8500_serial.c diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig index aff9dcd..6e76a59 100644 --- a/drivers/serial/Kconfig +++ b/drivers/serial/Kconfig @@ -1381,6 +1381,16 @@ config SERIAL_MSM_CONSOLE depends on SERIAL_MSM=y select SERIAL_CORE_CONSOLE +config SERIAL_VT8500 + bool "VIA VT8500 on-chip serial port support" + depends on ARM && ARCH_VT8500 + select SERIAL_CORE + +config SERIAL_VT8500_CONSOLE + bool "VIA VT8500 serial console support" + depends on SERIAL_VT8500=y + select SERIAL_CORE_CONSOLE + config SERIAL_NETX tristate "NetX serial port support" depends on ARM && ARCH_NETX diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile index c570576..86b8587 100644 --- a/drivers/serial/Makefile +++ b/drivers/serial/Makefile @@ -86,6 +86,7 @@ obj-$(CONFIG_SERIAL_TIMBERDALE) += timbuart.o obj-$(CONFIG_SERIAL_GRLIB_GAISLER_APBUART) += apbuart.o obj-$(CONFIG_SERIAL_ALTERA_JTAGUART) += altera_jtaguart.o obj-$(CONFIG_SERIAL_ALTERA_UART) += altera_uart.o +obj-$(CONFIG_SERIAL_VT8500) += vt8500_serial.o obj-$(CONFIG_SERIAL_MRST_MAX3110) += mrst_max3110.o obj-$(CONFIG_SERIAL_MFD_HSU) += mfd.o obj-$(CONFIG_SERIAL_OMAP) += ...
VIA and WonderMedia Systems-on-Chip feature a standard i8042-compatible keyboard and mouse controller. This adds necessary glue to enable use of the standard driver with these systems. Signed-off-by: Alexey Charkov <alchark@gmail.com> --- Please review and (if appropriate) commit to a relevant git tree for further integration in 2.6.38. Previous version of this code was 'Acked-by: Dmitry Torokhov <dtor@mail.ru>' This one only differs by using runtime-selected IRQ definitions instead of static compile-time preprocessor macros. Relevant register and interrupt definitions are provided by PATCH 1/6 in this series, so one would need that to make use of this code. drivers/input/serio/Kconfig | 3 +- drivers/input/serio/i8042-vt8500.h | 74 ++++++++++++++++++++++++++++++++++++ drivers/input/serio/i8042.h | 2 + 3 files changed, 78 insertions(+), 1 deletions(-) create mode 100644 drivers/input/serio/i8042-vt8500.h diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig index 6256233..ff799f3 100644 --- a/drivers/input/serio/Kconfig +++ b/drivers/input/serio/Kconfig @@ -21,7 +21,8 @@ if SERIO config SERIO_I8042 tristate "i8042 PC Keyboard controller" if EMBEDDED || !X86 default y - depends on !PARISC && (!ARM || ARCH_SHARK || FOOTBRIDGE_HOST) && \ + depends on !PARISC && \ + (!ARM || ARCH_SHARK || ARCH_VT8500 || FOOTBRIDGE_HOST) && \ (!SUPERH || SH_CAYMAN) && !M68K && !BLACKFIN help i8042 is the chip over which the standard AT keyboard and PS/2 diff --git a/drivers/input/serio/i8042-vt8500.h b/drivers/input/serio/i8042-vt8500.h new file mode 100644 index 0000000..4ff9e1c --- /dev/null +++ b/drivers/input/serio/i8042-vt8500.h @@ -0,0 +1,74 @@ +#ifndef _I8042_VT8500_H +#define _I8042_VT8500_H + +#include <mach/mmio_regs.h> +#include <mach/irq_defs.h> + +/* + * 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 ...
Any comments about this? Thanks, Alexey --
Looks good to me (ignoring the fact that whole i8042 initialization needs to be reworked and pushed into arch/board code which is out of scope of these series). I expect it will be merged with the rest of VT8500 patches through whatever tree takes them. Thanks. -- Dmitry --
Thanks, Dmitry! Best regards, Alexey --
VIA and WonderMedia Systems-on-Chip feature a standard i8042-compatible keyboard and mouse controller. This adds necessary glue to enable use of the standard driver with these systems. Signed-off-by: Alexey Charkov <alchark@gmail.com> --- This version of the patch introduces yet another trivial update to follow changes in arch code (namely variables that hold the register and interrupt numbers). Otherwise it is identical to v2. Best regards, Alexey drivers/input/serio/Kconfig | 3 +- drivers/input/serio/i8042-vt8500.h | 73 ++++++++++++++++++++++++++++++++++++ drivers/input/serio/i8042.h | 2 + 3 files changed, 77 insertions(+), 1 deletions(-) create mode 100644 drivers/input/serio/i8042-vt8500.h diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig index 6256233..ff799f3 100644 --- a/drivers/input/serio/Kconfig +++ b/drivers/input/serio/Kconfig @@ -21,7 +21,8 @@ if SERIO config SERIO_I8042 tristate "i8042 PC Keyboard controller" if EMBEDDED || !X86 default y - depends on !PARISC && (!ARM || ARCH_SHARK || FOOTBRIDGE_HOST) && \ + depends on !PARISC && \ + (!ARM || ARCH_SHARK || ARCH_VT8500 || FOOTBRIDGE_HOST) && \ (!SUPERH || SH_CAYMAN) && !M68K && !BLACKFIN help i8042 is the chip over which the standard AT keyboard and PS/2 diff --git a/drivers/input/serio/i8042-vt8500.h b/drivers/input/serio/i8042-vt8500.h new file mode 100644 index 0000000..a7e6673 --- /dev/null +++ b/drivers/input/serio/i8042-vt8500.h @@ -0,0 +1,73 @@ +#ifndef _I8042_VT8500_H +#define _I8042_VT8500_H + +#include <mach/i8042.h> + +/* + * 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. + */ + +static void __iomem *regbase; + +/* + * Names. + */ + +#define I8042_KBD_PHYS_DESC "vt8500ps2/serio0" +#define I8042_AUX_PHYS_DESC "vt8500ps2/serio1" +#define I8042_MUX_PHYS_DESC ...
VIA and WonderMedia Systems-on-Chip feature a standard EHCI host
controller. This adds necessary glue to use the standard driver
with these systems.
Signed-off-by: Alexey Charkov <alchark@gmail.com>
---
Please review and (if appropriate) commit to a relevant git tree for
further integration in 2.6.38.
Compared to the previous submission, this code just contains a rebase
against the latest changes introduced in 2.6.37 merge window.
Relevant platform definitions are introduced by PATCH 1/6 in this series,
so one would need that to make use of this code.
Due credits go to the community for providing feedback, advice and
testing.
drivers/usb/Kconfig | 1 +
drivers/usb/host/ehci-hcd.c | 5 +
drivers/usb/host/ehci-vt8500.c | 172 ++++++++++++++++++++++++++++++++++++++++
3 files changed, 178 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/host/ehci-vt8500.c
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 67eb377..7d13506 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -66,6 +66,7 @@ config USB_ARCH_HAS_EHCI
default y if ARCH_AT91SAM9G45
default y if ARCH_MXC
default y if ARCH_OMAP3
+ default y if ARCH_VT8500
default PCI
# ARM SA1111 chips have a non-PCI based "OHCI-compatible" USB host interface.
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 502a7e6..10f985d 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1216,6 +1216,11 @@ MODULE_LICENSE ("GPL");
#define PLATFORM_DRIVER ehci_octeon_driver
#endif
+#ifdef CONFIG_ARCH_VT8500
+#include "ehci-vt8500.c"
+#define PLATFORM_DRIVER vt8500_ehci_driver
+#endif
+
#if !defined(PCI_DRIVER) && !defined(PLATFORM_DRIVER) && \
!defined(PS3_SYSTEM_BUS_DRIVER) && !defined(OF_PLATFORM_DRIVER) && \
!defined(XILINX_OF_PLATFORM_DRIVER)
diff --git a/drivers/usb/host/ehci-vt8500.c b/drivers/usb/host/ehci-vt8500.c
new file mode 100644
index 0000000..2016806
--- /dev/null
+++ ...This adds a driver for the RTC devices in VIA and WonderMedia
Systems-on-Chip. Alarm, 1Hz interrupts, reading and setting time
are supported.
Signed-off-by: Alexey Charkov <alchark@gmail.com>
---
Please review and (if appropriate) commit to a relevant git tree for
further integration in 2.6.38.
Compared to the previous submission, this code just contains a rebase
against the latest changes introduced in 2.6.37 merge window.
Relevant platform definitions are introduced by PATCH 1/6 in this series,
so one would need that to make use of this code.
Due credits go to the community for providing feedback, advice and
testing.
drivers/rtc/Kconfig | 7 +
drivers/rtc/Makefile | 1 +
drivers/rtc/rtc-vt8500.c | 363 ++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 371 insertions(+), 0 deletions(-)
create mode 100644 drivers/rtc/rtc-vt8500.c
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 2883428..27ed129 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -865,6 +865,13 @@ config RTC_DRV_PXA
This RTC driver uses PXA RTC registers available since pxa27x
series (RDxR, RYxR) instead of legacy RCNR, RTAR.
+config RTC_DRV_VT8500
+ tristate "VIA/WonderMedia 85xx SoC RTC"
+ depends on ARCH_VT8500
+ help
+ If you say Y here you will get access to the real time clock
+ built into your VIA VT8500 SoC or its relatives.
+
config RTC_DRV_SUN4V
bool "SUN4V Hypervisor RTC"
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 4c2832d..1a354e1 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -97,6 +97,7 @@ obj-$(CONFIG_RTC_DRV_TWL4030) += rtc-twl.o
obj-$(CONFIG_RTC_DRV_TX4939) += rtc-tx4939.o
obj-$(CONFIG_RTC_DRV_V3020) += rtc-v3020.o
obj-$(CONFIG_RTC_DRV_VR41XX) += rtc-vr41xx.o
+obj-$(CONFIG_RTC_DRV_VT8500) += rtc-vt8500.o
obj-$(CONFIG_RTC_DRV_WM831X) += rtc-wm831x.o
obj-$(CONFIG_RTC_DRV_WM8350) += rtc-wm8350.o
obj-$(CONFIG_RTC_DRV_X1205) += rtc-x1205.o
diff ...Any comments about this? Thanks, Alexey --
Is there any specific reason why you don't keep the irq requested for the lifetime of the device? It would be better if you added descriptive defines for the bits of the CR register. You should rather implement these by providing the update_irq_enable and - Lars --
This adds a driver for the RTC devices in VIA and WonderMedia
Systems-on-Chip. Alarm, 1Hz interrupts, reading and setting time
are supported.
Signed-off-by: Alexey Charkov <alchark@gmail.com>
---
This implements the suggestions made by Lars. Reference to wakeup
was removed, as currently other code does not yet provide any
support for that.
It now also checks the status register for indication of a valid
time value before trying to read date/time registers.
Thanks,
Alexey
drivers/rtc/Kconfig | 7 +
drivers/rtc/Makefile | 1 +
drivers/rtc/rtc-vt8500.c | 365 ++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 373 insertions(+), 0 deletions(-)
create mode 100644 drivers/rtc/rtc-vt8500.c
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 2883428..27ed129 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -865,6 +865,13 @@ config RTC_DRV_PXA
This RTC driver uses PXA RTC registers available since pxa27x
series (RDxR, RYxR) instead of legacy RCNR, RTAR.
+config RTC_DRV_VT8500
+ tristate "VIA/WonderMedia 85xx SoC RTC"
+ depends on ARCH_VT8500
+ help
+ If you say Y here you will get access to the real time clock
+ built into your VIA VT8500 SoC or its relatives.
+
config RTC_DRV_SUN4V
bool "SUN4V Hypervisor RTC"
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 4c2832d..1a354e1 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -97,6 +97,7 @@ obj-$(CONFIG_RTC_DRV_TWL4030) += rtc-twl.o
obj-$(CONFIG_RTC_DRV_TX4939) += rtc-tx4939.o
obj-$(CONFIG_RTC_DRV_V3020) += rtc-v3020.o
obj-$(CONFIG_RTC_DRV_VR41XX) += rtc-vr41xx.o
+obj-$(CONFIG_RTC_DRV_VT8500) += rtc-vt8500.o
obj-$(CONFIG_RTC_DRV_WM831X) += rtc-wm831x.o
obj-$(CONFIG_RTC_DRV_WM8350) += rtc-wm8350.o
obj-$(CONFIG_RTC_DRV_X1205) += rtc-x1205.o
diff --git a/drivers/rtc/rtc-vt8500.c b/drivers/rtc/rtc-vt8500.c
new file mode 100644
index 0000000..e4f2aa9
--- /dev/null
+++ ...Hi Looks good to me now, except for the drivers release function. And some minor stylistic issues. Comments are inline. In my opinion it would be a good idea to move the read and write of the register outside of if-else statement and just modify tmp in there. That should make the code I don't think you need to lock here. You should free the irqs before you unregister the rtc device, otherwise it might be possible that the irq handler tries to report an interrupt to the already --
This adds a driver for the RTC devices in VIA and WonderMedia
Systems-on-Chip. Alarm, 1Hz interrupts, reading and setting time
are supported.
Signed-off-by: Alexey Charkov <alchark@gmail.com>
---
Thanks for the comments, Lars! This version implements the latest
ones as well.
Best regards,
Alexey
drivers/rtc/Kconfig | 7 +
drivers/rtc/Makefile | 1 +
drivers/rtc/rtc-vt8500.c | 359 ++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 367 insertions(+), 0 deletions(-)
create mode 100644 drivers/rtc/rtc-vt8500.c
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 2883428..27ed129 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -865,6 +865,13 @@ config RTC_DRV_PXA
This RTC driver uses PXA RTC registers available since pxa27x
series (RDxR, RYxR) instead of legacy RCNR, RTAR.
+config RTC_DRV_VT8500
+ tristate "VIA/WonderMedia 85xx SoC RTC"
+ depends on ARCH_VT8500
+ help
+ If you say Y here you will get access to the real time clock
+ built into your VIA VT8500 SoC or its relatives.
+
config RTC_DRV_SUN4V
bool "SUN4V Hypervisor RTC"
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 4c2832d..1a354e1 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -97,6 +97,7 @@ obj-$(CONFIG_RTC_DRV_TWL4030) += rtc-twl.o
obj-$(CONFIG_RTC_DRV_TX4939) += rtc-tx4939.o
obj-$(CONFIG_RTC_DRV_V3020) += rtc-v3020.o
obj-$(CONFIG_RTC_DRV_VR41XX) += rtc-vr41xx.o
+obj-$(CONFIG_RTC_DRV_VT8500) += rtc-vt8500.o
obj-$(CONFIG_RTC_DRV_WM831X) += rtc-wm831x.o
obj-$(CONFIG_RTC_DRV_WM8350) += rtc-wm8350.o
obj-$(CONFIG_RTC_DRV_X1205) += rtc-x1205.o
diff --git a/drivers/rtc/rtc-vt8500.c b/drivers/rtc/rtc-vt8500.c
new file mode 100644
index 0000000..cdf4f63
--- /dev/null
+++ b/drivers/rtc/rtc-vt8500.c
@@ -0,0 +1,359 @@
+/*
+ * drivers/rtc/rtc-vt8500.c
+ *
+ * Copyright (C) 2010 Alexey Charkov <alchark@gmail.com>
+ *
+ * Based on rtc-pxa.c
+ *
+ * This software is licensed ...Any further comments about this code? Could it be merged now? Lars, sorry for double-posting this (forgot to CC the lists and others last time). Thanks, Alexey --
Looks good to me, except one small thing: request_mem_region allocates the resource struct it returns. You should pass the same struct to release_mem_region to free it again. When that is fixed feel free to add a --
This adds a driver for the RTC devices in VIA and WonderMedia
Systems-on-Chip. Alarm, 1Hz interrupts, reading and setting time
are supported.
Signed-off-by: Alexey Charkov <alchark@gmail.com>
---
This fixes the issue with releasing the resource mentioned by Lars.
In addition, I've fixed the years range to reflect what the hardware seems
to actually expect (2000-2199 instead of 1900-... as implied by prior code).
In the process, it turned out that using rtc_valid_tm() when reading time
precludes any obvious recovery path if for some reason the hardware contains
garbage at kernel initialization: `hwclock -w` tries to read time before
updating, and fails. However, bad time values are handled gracefully by the
userspace, so I just put in 'return 0' there. In-kernel hctosys also checks
the returned time, so this seems to be valid behaviour.
Reading alarm values still returns through rtc_valid_tm().
Thanks,
Alexey
drivers/rtc/Kconfig | 7 +
drivers/rtc/Makefile | 1 +
drivers/rtc/rtc-vt8500.c | 366 ++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 374 insertions(+), 0 deletions(-)
create mode 100644 drivers/rtc/rtc-vt8500.c
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 2883428..27ed129 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -865,6 +865,13 @@ config RTC_DRV_PXA
This RTC driver uses PXA RTC registers available since pxa27x
series (RDxR, RYxR) instead of legacy RCNR, RTAR.
+config RTC_DRV_VT8500
+ tristate "VIA/WonderMedia 85xx SoC RTC"
+ depends on ARCH_VT8500
+ help
+ If you say Y here you will get access to the real time clock
+ built into your VIA VT8500 SoC or its relatives.
+
config RTC_DRV_SUN4V
bool "SUN4V Hypervisor RTC"
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 4c2832d..1a354e1 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -97,6 +97,7 @@ obj-$(CONFIG_RTC_DRV_TWL4030) += rtc-twl.o
obj-$(CONFIG_RTC_DRV_TX4939) += ...This adds drivers for the LCD controller found in VIA VT8500 SoC, GOVR display controller found in WonderMedia WM8505 SoC and for the Graphics Engine present in both of them that provides hardware accelerated raster operations (used for copyarea and fillrect). Signed-off-by: Alexey Charkov <alchark@gmail.com> --- Please review and (if appropriate) commit to a relevant git tree for further integration in 2.6.38. Compared to the previous submission, this code just contains a rebase against the latest changes introduced in 2.6.37 merge window. Relevant platform definitions are introduced by PATCH 1/6 in this series, so one would need that to make use of this code. Due credits go to the community for providing feedback, advice and testing. Driver for WM8505 is by Ed Spiridonov, as stated in the relevant copyright header, parts modified by myself. Invaluable work wrt the Graphics Engine documentation has been done by Giuseppe Gatta aka nextvolume. Also special thanks go to Angus Gratton aka projectgus for convincing VIA to partly release GPL kernel sources for the vendor-provided images, which greatly helped in understanding some parts of WM8505's complex video handling chain. drivers/video/Kconfig | 26 +++ drivers/video/Makefile | 3 + drivers/video/vt8500lcdfb.c | 452 +++++++++++++++++++++++++++++++++++++++++ drivers/video/vt8500lcdfb.h | 34 +++ drivers/video/wm8505fb.c | 438 +++++++++++++++++++++++++++++++++++++++ drivers/video/wm8505fb_regs.h | 76 +++++++ drivers/video/wmt_ge_rops.c | 186 +++++++++++++++++ drivers/video/wmt_ge_rops.h | 5 + 8 files changed, 1220 insertions(+), 0 deletions(-) create mode 100644 drivers/video/vt8500lcdfb.c create mode 100644 drivers/video/vt8500lcdfb.h create mode 100644 drivers/video/wm8505fb.c create mode 100644 drivers/video/wm8505fb_regs.h create mode 100644 drivers/video/wmt_ge_rops.c create mode 100644 drivers/video/wmt_ge_rops.h diff --git a/drivers/video/Kconfig ...
This looks like a bogus test, you've already allocated enough space for the pseudo_palette and will have bailed out on the kmalloc() failing well before this. You also don't have any error handling for fbi->palette_cpu, ... What in the name of all that is holy are you doing here? If you need to have your platform deal with virtual address allocation and freeing then you should pass in callbacks for that and hide the instrumentation details there. Presently this is tying you down to an alloc_pages_exact() interface buried in the board setup, which isn't going to mesh well with other platforms that may wish to go about this an alternate way (like Uhm, no. If this is only used in this driver then just make it static. Given that you are using the driver model here though and could theoretically support multiple rop engines, you're much better off making this private data and burying it under the appropriate per-device data While I admire your optimism in your hardware, experience suggests you really want a timeout here. You may also wish to insert a cpu_relax() here. --
True, this has to be corrected (old copy-paste error left unnoticed
somehow). It's also deallocated wrongly in the error path, which I
Actually, this is a leftover from a previous implementation with
alloc_pages_exact(), which could not work for larger screen sizes (due
to the framebuffer growing over 4MB). Now memory is reserved via
Is that platform_{set,get}_drvdata() what you are talking about? Using
I wonder if this callback is allowed to sleep? In principle, the
hardware seems to support interrupt generation on operation
completion, so maybe wait_event_interruptible_timeout() could be used
here to remove the busy wait altogether?
Thank you for the comments, Paul!
Best regards,
Alexey
--
This adds drivers for the LCD controller found in VIA VT8500 SoC,
GOVR display controller found in WonderMedia WM8505 SoC and for the
Graphics Engine present in both of them that provides hardware
accelerated raster operations (used for copyarea and fillrect).
Signed-off-by: Alexey Charkov <alchark@gmail.com>
---
This incorporates fixes to the issues that Paul has identified.
MMIO register pointer in wmt_ge_rops was just made static, as I
could not find any immediately obvious way to pass drvdata around
(the whole functionality of this driver is in exported functions
that are called from a display driver context, which does not know
about the rop engine specific data structures).
fb_sync callback has just received a (pretty large) timeout. This
seems to work fine in my use cases (fbcon on 800x480 panel).
drivers/video/Kconfig | 26 +++
drivers/video/Makefile | 3 +
drivers/video/vt8500lcdfb.c | 455 +++++++++++++++++++++++++++++++++++++++++
drivers/video/vt8500lcdfb.h | 34 +++
drivers/video/wm8505fb.c | 434 +++++++++++++++++++++++++++++++++++++++
drivers/video/wm8505fb_regs.h | 76 +++++++
drivers/video/wmt_ge_rops.c | 186 +++++++++++++++++
drivers/video/wmt_ge_rops.h | 5 +
8 files changed, 1219 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/vt8500lcdfb.c
create mode 100644 drivers/video/vt8500lcdfb.h
create mode 100644 drivers/video/wm8505fb.c
create mode 100644 drivers/video/wm8505fb_regs.h
create mode 100644 drivers/video/wmt_ge_rops.c
create mode 100644 drivers/video/wmt_ge_rops.h
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 27c1fb4..954f6e9 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -186,6 +186,14 @@ config FB_SYS_FOPS
depends on FB
default n
+config FB_WMT_GE_ROPS
+ tristate
+ depends on FB
+ default n
+ ---help---
+ Include functions for accelerated rectangle filling and area
+ copying using WonderMedia Graphics ...Sice you are open-coding this container_of() all over the place you may
simply want to make a wrapper for this. ie,
#define to_wm8505fb_info(info) container_of(info, struct wm8505fb_info, fb)
and then just doing struct wm855fb_info *fbi = to_wm8505fb_info(info);
This wiwll also save you from having that ugly multi-line split in the
I would kill this test as well. If this ever triggers, something horribly
As your remove function is flagged devexit, this ought to be wrapped with
__devexit_p(). This will save you a bit of space as the kernel will
discard the remove function outright if you're not using this as a module
...
Is there a particular reason why you are favouring EXPORT_SYMBOL? In
general we prefer that new infrastructure patches and the like stick with
EXPORT_SYMBOL_GPL, as this discourages use by non-GPLed modules going
You might also want to do something like:
/* Only one ROP engine is presently supported. */
if (unlikely(regbase)) {
WARN_ON(1);
return -EBUSY;
}
regbase = ioremap(...);
You're missing a:
writel(0, regbase + GE_ENABLE_OFF);
Your other drivers appear to be lacking AUTHOR and DESCRIPTION
definitions.
--
But a couple of extra instructions for error handling to hold in the kernel binary should not hurt, should they? Are there benefits aside Well, I have no personal preference towards these, so I just took what was in cfb*.c as a guidance. If the *_GPL variant is more welcome, it But for that I'd have to initialize regbase to NULL (so as not to use an uninitialized variable), wouldn't I? checkpatch.pl complains on In fact, this module only uses a subset of GE functions, so I'm somewhat reluctant to disable the hardware altogether when unloading the module. And should the hardware really be disabled when the driver Will be fixed. Thanks, Alexey --
It's not a realistic situation. The only way this would trigger is if the pointer you got handed is one that didn't go through the probe path or was otherwise corrupted. If it was corrupted, you're going to notice regardless. The driver core does sensible refcounting already, there's no Those exports go back a ways. The idea with the _GPL exports was not to change symbol export behaviour retroactively, so the old ones stay the way they were and newer stuff can choose which way it wants to go. If you are not using this driver with an out-of-tree non-GPLed module then you You're the only one who can answer that. I just noticed in your other drivers that this is the pattern that you opted for, so I thought that perhaps this was an oversight in the rop engine code. Having said that, the general expectation is that a remove will balance out the probe. If the probe is enabling random blocks then the remove should be disabling them. If this driver is primarily used as a client by the other drivers and you're concerned from it being ripped out underneath them, then a bit more thinking and refcounting is needed. This is however something that can be done later if its a direction you wish to head in. --
From 95942cc0cd0909d700c236ba63d3488ec9fccf1a Mon Sep 17 00:00:00 2001 From: Alexey Charkov <alchark@gmail.com> Date: Tue, 9 Nov 2010 02:25:40 +0300 Subject: [PATCH 3/3] ARM: Add support for the display controllers in VT8500 and WM8505 This adds drivers for the LCD controller found in VIA VT8500 SoC, GOVR display controller found in WonderMedia WM8505 SoC and for the Graphics Engine present in both of them that provides hardware accelerated raster operations (used for copyarea and fillrect). Signed-off-by: Alexey Charkov <alchark@gmail.com> --- This incorporates fixes to the issues last mentioned by Paul. I just dropped <asm/irq.h>, as that seems to be not used at all currently (must have been some old cut-and-paste as well). As for the Graphics Engine, I decided not to disable it for now at device exit time, at least until we reach a conclusion on how or whether to implement support for its alpha-mixing capabilities. Unlike with display drivers, this should have no user-visible consequences. This can be changed later, when time comes for device clocks and power management support. Thanks, Alexey drivers/video/Kconfig | 26 +++ drivers/video/Makefile | 3 + drivers/video/vt8500lcdfb.c | 447 +++++++++++++++++++++++++++++++++++++++++ drivers/video/vt8500lcdfb.h | 34 +++ drivers/video/wm8505fb.c | 422 ++++++++++++++++++++++++++++++++++++++ drivers/video/wm8505fb_regs.h | 76 +++++++ drivers/video/wmt_ge_rops.c | 192 ++++++++++++++++++ drivers/video/wmt_ge_rops.h | 5 + 8 files changed, 1205 insertions(+), 0 deletions(-) create mode 100644 drivers/video/vt8500lcdfb.c create mode 100644 drivers/video/vt8500lcdfb.h create mode 100644 drivers/video/wm8505fb.c create mode 100644 drivers/video/wm8505fb_regs.h create mode 100644 drivers/video/wmt_ge_rops.c create mode 100644 drivers/video/wmt_ge_rops.h diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index 27c1fb4..954f6e9 100644 --- ...
Looks good to me! Reviewed-by: Paul Mundt <lethal@linux-sh.org> --
Thanks, Paul! Is there anybody I should address specifically to get this merged? Best regards, Alexey --
In the absence of a fbdev maintainer, such patches, as long as they don't touch the core, apart from the obvious and trivial Makefile and Kconfig hunks, they normally get mainlined via respective arch trees, i.e., you can just push them the same way as your other SoC patches. OTOH you can also ask Andrew Morton to pull them. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ --
I've set up an fbdev tree now, so I'll just take this through there. It looks like the ordering shouldn't be important, so this can be applied independent of the rest, and it simply won't show up until the other bits have settled in .38. --
Yes, the different parts of the patch series are completely independent, apart from the corresponding platform definitions and memblock reservations that take place in PATCH 1/6 (which contains basic board code). Thanks, Alexey --
I assume you've read the comment at the top of linux/irq.h ? --
I had forgotten about that. This comment predates git, so I'm unaware of what the context is, could you elaborate on it? I'm aware this won't work for s390, but as that has NO_IOMEM in the first place it's a non-issue. I assume this was added at a time before ARM selected GENERIC_HARDIRQS, but this is no longer the case. The odd ones out that do support iomem are m68k and sparc32, both of which are being converted. Given that and that s390 remains special cased for now, what exactly is the concern? There is a reasonable expectation that we will start to see irq_data references in drivers, so it's not entirely obvious that the assertion made by the comment will remain true (all of the stragglers have work in progress patches already, as far as I'm aware). --
It's from a time when we didn't have generic irq (and as I understand, generic irq is still optional.) When you didn't have generic irq support for an arch, having drivers include linux/irq.h resulted in build errors, caused by nothing more than "use linux/foo.h rather than asm/foo.h" - as those architectures won't provide an asm/hw_irq.h. It looks to me like the only arch in the kernel which doesn't support generic irq is sh. --
On Tue, Nov 9, 2010 at 12:04, Russell King - ARM Linux
IIRC, m68k, sparc32, and s390.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
Yes, and among those, no driver in s390 should need asm/irq.h either because they do not have interrupt numbers -- every device on s390 has an implicit interrupt. Arnd --
Which is exactly what I stated in my original response. Moving along then.. --
From a very brief look, the two drivers look rather similar. What is the reason to have separate drivers instead of just one? Could you perhaps take the common parts and move them into a third module that exports symbols to be used by the two drivers? Arnd --
Quite frankly, I would say that all SoC framebuffer drivers are quite similar ;-) Register offsets, timing formats, accepted pixel formats, buffer alignment requirements are all different, so I do not really believe that there'd be much benefit from introducing another abstraction level. This is open to debate, of course. Alexey --
Ok, I took a more detailed look at the code now. You're absolutely right here. Arnd --
I'd much prefer that the allocation of memblock memory is done via the 'reserve' machine callback, rather than trying to group it into the IO mapping callback. Is there a reason it can't be? --
I believe it can. Thanks for the info, I just didn't know about that. Will fix this shortly. Is it OK to leave resources assignment in map_io or is there a better place to do that as well? --
Well, surely resources don't need to be set this early, because they're not going to be used before their associated devices are registered - which presumably happens in your init_machine callback. So, can you not call a function from the init_machine callbacks to setup these resources? --
This adds support for the family of Systems-on-Chip produced initially by VIA and now its subsidiary WonderMedia that have recently become widespread in lower-end Chinese ARM-based tablets and netbooks. Support is included for both VT8500 and WM8505. Suitable code is selected (if compiled in) at early initialization time by reading a platform-specific identification register, as current bootloaders do not provide any reliable machine id to the kernel. Included are basic machine initialization files, register and interrupt definitions, support for the on-chip interrupt controller, high-precision OS timer, GPIO lines, necessary macros for early debug, pulse-width-modulated outputs control, as well as platform device configurations for the specific drivers implemented elsewhere. Signed-off-by: Alexey Charkov <alchark@gmail.com> --- This incorporates fixes for the issue that Russel has just identified, namely reserving memblock memory from the appropriate callback, checking ioremap return values for errors in all instances and not specifying the unneeded 'default n' in Kconfig. arch/arm/Kconfig | 14 + arch/arm/Makefile | 1 + arch/arm/boot/compressed/Makefile | 4 + arch/arm/boot/compressed/head-vt8500.S | 46 +++ arch/arm/mach-vt8500/Kconfig | 63 ++++ arch/arm/mach-vt8500/Makefile | 6 + arch/arm/mach-vt8500/Makefile.boot | 3 + arch/arm/mach-vt8500/bv07.c | 81 ++++ arch/arm/mach-vt8500/devices.c | 442 +++++++++++++++++++++++ arch/arm/mach-vt8500/devices.h | 46 +++ arch/arm/mach-vt8500/gpio.c | 230 ++++++++++++ arch/arm/mach-vt8500/include/mach/debug-macro.S | 31 ++ arch/arm/mach-vt8500/include/mach/entry-macro.S | 32 ++ arch/arm/mach-vt8500/include/mach/gpio.h | 6 + arch/arm/mach-vt8500/include/mach/hardware.h | ...
This adds support for the family of Systems-on-Chip produced initially by VIA and now its subsidiary WonderMedia that have recently become widespread in lower-end Chinese ARM-based tablets and netbooks. Support is included for both VT8500 and WM8505. Suitable code is selected (if compiled in) at early initialization time by reading a platform-specific identification register, as current bootloaders do not provide any reliable machine id to the kernel. Included are basic machine initialization files, register and interrupt definitions, support for the on-chip interrupt controller, high-precision OS timer, GPIO lines, necessary macros for early debug, pulse-width-modulated outputs control, as well as platform device configurations for the specific drivers implemented elsewhere. Signed-off-by: Alexey Charkov <alchark@gmail.com> --- In addition to the fixes in v3 of this patch (to those issues that Russell has identified above), this iteration also brings in timeouts and cpu_relax() in busy waits (PWM and timer), according to what was suggested for device drivers in the related sub-threads. It also incorporates a fix to the misspelling of Russell's name introduced in the comment to v3, for which I beg his pardon :-) arch/arm/Kconfig | 14 + arch/arm/Makefile | 1 + arch/arm/boot/compressed/Makefile | 4 + arch/arm/boot/compressed/head-vt8500.S | 46 +++ arch/arm/mach-vt8500/Kconfig | 63 ++++ arch/arm/mach-vt8500/Makefile | 6 + arch/arm/mach-vt8500/Makefile.boot | 3 + arch/arm/mach-vt8500/bv07.c | 81 ++++ arch/arm/mach-vt8500/devices.c | 442 +++++++++++++++++++++++ arch/arm/mach-vt8500/devices.h | 46 +++ arch/arm/mach-vt8500/gpio.c | 230 ++++++++++++ arch/arm/mach-vt8500/include/mach/debug-macro.S | 31 ++ ...
please replace dove with vt8500 saeed --
That doesn't make sense - how can a file be created, based upon itself? --
On Wed, Nov 10, 2010 at 5:18 PM, Russell King - ARM Linux your are right, please ignore my comment. saeed --
This adds support for the family of Systems-on-Chip produced initially by VIA and now its subsidiary WonderMedia that have recently become widespread in lower-end Chinese ARM-based tablets and netbooks. Support is included for both VT8500 and WM8505. Suitable code is selected (if compiled in) at early initialization time by reading a platform-specific identification register, as current bootloaders do not provide any reliable machine id to the kernel. Included are basic machine initialization files, register and interrupt definitions, support for the on-chip interrupt controller, high-precision OS timer, GPIO lines, necessary macros for early debug, pulse-width-modulated outputs control, as well as platform device configurations for the specific drivers implemented elsewhere. Signed-off-by: Alexey Charkov <alchark@gmail.com> --- I decided to drop the override for sched_clock and just use the default implementation instead. As the hardware timer has quite a significant overhead when read (due to the necessity of busy-waiting for hardware synchronization), the default implementation turns out to perform much better (4s kernel initialization time vs. 14s on my device), and the code is simpler. Please consider this version instead of the previous ones. Best regards, Alexey arch/arm/Kconfig | 14 + arch/arm/Makefile | 1 + arch/arm/boot/compressed/Makefile | 4 + arch/arm/boot/compressed/head-vt8500.S | 46 +++ arch/arm/mach-vt8500/Kconfig | 63 ++++ arch/arm/mach-vt8500/Makefile | 6 + arch/arm/mach-vt8500/Makefile.boot | 3 + arch/arm/mach-vt8500/bv07.c | 81 ++++ arch/arm/mach-vt8500/devices.c | 442 +++++++++++++++++++++++ arch/arm/mach-vt8500/devices.h | 46 +++ arch/arm/mach-vt8500/gpio.c | 230 ++++++++++++ ...
The good news is that it's getting harder to find things wrong... Only three points follow below. These set_irq_handler's probably warn if you have spinlock debugging enabled. --
This adds support for the family of Systems-on-Chip produced initially by VIA and now its subsidiary WonderMedia that have recently become widespread in lower-end Chinese ARM-based tablets and netbooks. Support is included for both VT8500 and WM8505. Suitable code is selected (if compiled in) at early initialization time by reading a platform-specific identification register, as current bootloaders do not provide any reliable machine id to the kernel. Included are basic machine initialization files, register and interrupt definitions, support for the on-chip interrupt controller, high-precision OS timer, GPIO lines, necessary macros for early debug, pulse-width-modulated outputs control, as well as platform device configurations for the specific drivers implemented elsewhere. Signed-off-by: Alexey Charkov <alchark@gmail.com> --- This fixes asm/ versus linux/ includes ordering and changes <mach/gpio.h> to <linux/gpio.h> as Russell has requested. Russell, could you please elaborate on your comment regarding spinlocks and irq handlers? I always compile my kernel with all kinds of lock debugging, and have not run into any associated warnings. Is there anything suspicious specifically? Thanks, Alexey arch/arm/Kconfig | 14 + arch/arm/Makefile | 1 + arch/arm/boot/compressed/Makefile | 4 + arch/arm/boot/compressed/head-vt8500.S | 46 +++ arch/arm/mach-vt8500/Kconfig | 63 ++++ arch/arm/mach-vt8500/Makefile | 6 + arch/arm/mach-vt8500/Makefile.boot | 3 + arch/arm/mach-vt8500/bv07.c | 82 +++++ arch/arm/mach-vt8500/devices.c | 442 +++++++++++++++++++++++ arch/arm/mach-vt8500/devices.h | 46 +++ arch/arm/mach-vt8500/gpio.c | 230 ++++++++++++ arch/arm/mach-vt8500/include/mach/debug-macro.S | 31 ++ ...
My fault: actually, those were not all lock debugging functions. It
really prints errors when lock correctness proving is enabled. I thus
decided to just assign the callback functions directly to irq_desc
struct fields, as it is done in mach-msm.
There is, however, another error showing up: it complains about my use
of ioremap inside arch_reset(). Is it fine to just hardcode the
virtual address of the respective register and use that directly in
this case? Something along the lines of:
/* PM Software Reset request register */
#define VT8500_PMSR_VIRT 0xf8130060
static inline void arch_reset(char mode, const char *cmd)
{
writel(1, VT8500_PMSR_VIRT);
}
Thanks,
Alexey
--
This adds support for the family of Systems-on-Chip produced initially by VIA and now its subsidiary WonderMedia that have recently become widespread in lower-end Chinese ARM-based tablets and netbooks. Support is included for both VT8500 and WM8505. Suitable code is selected (if compiled in) at early initialization time by reading a platform-specific identification register, as current bootloaders do not provide any reliable machine id to the kernel. Included are basic machine initialization files, register and interrupt definitions, support for the on-chip interrupt controller, high-precision OS timer, GPIO lines, necessary macros for early debug, pulse-width-modulated outputs control, as well as platform device configurations for the specific drivers implemented elsewhere. Signed-off-by: Alexey Charkov <alchark@gmail.com> --- There were no further comments on v6 of this patch, so this just introduces direct assignment of handler callbacks to irq_desc fields to avoid spinlock problems. For the same reason, the ioremap call in arch_reset() was removed and replaced with a direct write to the relevant virtual memory address. Please review and, if possible, merge this for inclusion in 2.6.38 together with the input-related code [1], which Dmitry Torokhov acks and expects to be merged together with the arch code [2]. Serial, USB and fbdev-related parts have already been merged to their respective trees, and RTC is awaiting maintainer's resolution after having implemented the suggestions. Thanks, Alexey [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2010-November/030782.html [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2010-November/031358.html arch/arm/Kconfig | 14 + arch/arm/Makefile | 1 + arch/arm/boot/compressed/Makefile | 4 + arch/arm/boot/compressed/head-vt8500.S | 46 +++ arch/arm/mach-vt8500/Kconfig | 63 ++++ ...
This adds support for the family of Systems-on-Chip produced initially by VIA and now its subsidiary WonderMedia that have recently become widespread in lower-end Chinese ARM-based tablets and netbooks. Support is included for both VT8500 and WM8505. Suitable code is selected (if compiled in) at early initialization time by reading a platform-specific identification register, as current bootloaders do not provide any reliable machine id to the kernel. Included are basic machine initialization files, register and interrupt definitions, support for the on-chip interrupt controller, high-precision OS timer, GPIO lines, necessary macros for early debug, pulse-width-modulated outputs control, as well as platform device configurations for the specific drivers implemented elsewhere. Signed-off-by: Alexey Charkov <alchark@gmail.com> --- Compared to the previous submission, this version contains a definition for 1024x576 panels (courtesy of John Mitchell) and slight adjustments for other panel timings. Also, the reservation callback is now assigned above the map_io one, and the Kconfig reference to CLK is dropped for now (as there is no code for that yet, and the framework is changing, as far as I could see). Russell, are there any outstanding issues with this code that I should fix before you could take it to your tree? The merge window is approaching, so I'm getting a bit anxious :-) Best regards, Alexey arch/arm/Kconfig | 13 + arch/arm/Makefile | 1 + arch/arm/boot/compressed/Makefile | 4 + arch/arm/boot/compressed/head-vt8500.S | 46 +++ arch/arm/mach-vt8500/Kconfig | 73 ++++ arch/arm/mach-vt8500/Makefile | 6 + arch/arm/mach-vt8500/Makefile.boot | 3 + arch/arm/mach-vt8500/bv07.c | 82 ++++ arch/arm/mach-vt8500/devices.c | 460 +++++++++++++++++++++++ ...
Looks good to me, thanks for addressing all my previous concerns. Reviewed-by: Arnd Bergmann <arnd@arndb.de> --
Everything looks good, except for the above. You don't need to select GENERIC_TIME - it doesn't exist anymore. It's also good to see that you've picked up on registering clocksources with the _hz/_khz functions. --
Yes, these are quite handy. I will also check if my previously spotted performance issues with sched_clock are relieved with the latest clocksource-related instrumentary in 'devel': maybe it wasn't all due to evil busy-waiting on counter-to-bus synchronization. However, that would probably be worth a separate small patch. Thanks, Alexey --
This adds support for the family of Systems-on-Chip produced initially by VIA and now its subsidiary WonderMedia that have recently become widespread in lower-end Chinese ARM-based tablets and netbooks. Support is included for both VT8500 and WM8505, selectable by a configuration switch at kernel build time. Included are basic machine initialization files, register and interrupt definitions, support for the on-chip interrupt controller, high-precision OS timer, GPIO lines, necessary macros for early debug, pulse-width-modulated outputs control, as well as platform device configurations for the specific drivers implemented elsewhere. Signed-off-by: Alexey Charkov <alchark@gmail.com> --- Dropped GENERIC_TIME selection from Kconfig. No further changes compared to v8. This is against current Linus' 'master' branch. Best regards, Alexey arch/arm/Kconfig | 12 + arch/arm/Makefile | 1 + arch/arm/boot/compressed/Makefile | 4 + arch/arm/boot/compressed/head-vt8500.S | 46 +++ arch/arm/mach-vt8500/Kconfig | 73 ++++ arch/arm/mach-vt8500/Makefile | 6 + arch/arm/mach-vt8500/Makefile.boot | 3 + arch/arm/mach-vt8500/bv07.c | 82 ++++ arch/arm/mach-vt8500/devices.c | 460 +++++++++++++++++++++++ arch/arm/mach-vt8500/devices.h | 46 +++ arch/arm/mach-vt8500/gpio.c | 230 +++++++++++ arch/arm/mach-vt8500/include/mach/debug-macro.S | 31 ++ arch/arm/mach-vt8500/include/mach/entry-macro.S | 32 ++ arch/arm/mach-vt8500/include/mach/gpio.h | 6 + arch/arm/mach-vt8500/include/mach/hardware.h | 12 + arch/arm/mach-vt8500/include/mach/io.h | 28 ++ arch/arm/mach-vt8500/include/mach/irq_defs.h | 124 ++++++ arch/arm/mach-vt8500/include/mach/irqs.h | 22 ++ arch/arm/mach-vt8500/include/mach/memory.h | 28 ...
Hi Alexey,
Quick review below.
Should be strcmp. If the length of str is less than panels[i].mode.name
What's happening here? Does something else fill these in? If so, there
Ah, this makes more sense. But why have all the indirection? The
wmt_regmaps table could just be replaced with #defines and then have
separate device files for the VT8500 and the WM8505. This would also
There is a mix of hex and decimal constants here and exact sizes and
Separate files. If more variants get added, this file will become
Not sure if this should exist in the platform code or the framebuffer
driver. In the latter case it would automatically be CONFIG_FB_VT8500
and the platform_data can still be set in the platform code. Is there a
This could all disappear if you had separate files for the vt8500/wm8505
This would be more readable as:
unsigned val;
val = readl(regbase + vt8500_chop->regoff);
val |= 1 << vt8500_chop->shift << offset;
writel(val, regbase + vt8500_chip->regoff);
It's much clearer what is actually being done. Same goes for other
printk strings should be on a single line (can be > 80 columns) to make
I'm not sure what the state of the various efforts to provide a common
Ugh. If you are going to busy wait, can't you delay for a known amount
of time? Even better, can this be replaced with wait_event or some
Maybe a bit clearer and more concise like this? Also replaces -ENOENT
(No such file or directory) with -ENODEV (No such device):
pwm = ERR_PTR(-ENODEV);
mutex_lock(&pwm_lock);
list_for_each_entry(pwm, &pwm_list, node) {
if (pwm->pwm_id == pwm_id) {
if (pwm->use_count != 0) {
pwm = ERR_PTR(-EBUSY);
break;
}
pwm->use_count++;
pwm->label = label;
break;
}
}
mutex_unlock(&pwm_lock);
~Ryan
--
Bluewater Systems Ltd - ARM Technology Solution Centre
Ryan Mallon 5 Amuri Park, 404 Barbadoes St
ryan@bluewatersys.com PO Box 13 889, Christchurch ...Ok, will add a comment. This was the way I implemented it originally. However, Arnd made quite a valid suggestion to allow runtime selection of the chip variant, thus registers and interrupts need to be held in an indexed data type instead of just compile-time macros. In addition, there is now some overall movement towards unification of binary kernel images for different ARM variants (as far as I can see), so this would be required in any case. Furthermore, as with many unbranded Chinese products, it's somewhat difficult to reliably determine the exact chip version used in your netbook without disassembling it. Reading a hardware register for Is it really worthwhile to create separate files for single 12-line functions? After all, WonderMedia does not release new chips every now I can't reserve memory via memblock from the driver, and usual runtime allocation functions can't handle it (need alignment to 4 megabytes in 8500, framebuffer sizes exceed 4 megabytes in 8505). Ok. That's true, will use tabs instead. Ok. I'm not the one who chooses :) In fact, there is some wakeup functionality, but it's not yet implemented. I could re-add the functions when some useful code Well, checkpatch.pl complained about that in the first place, so I split the line. Should I merge them back in all instances? The delay should be on the order of several bus cycles, where udelay actually busy-waits, too. wait_event would be longer than that to set I just followed PXA implementation in this regard. Are there any specific suggestions? Note that c should not be a complie-time constant eventually, as this is the guessed PWM base frequency (should Isn't pwm overwritten inside the loop? -ENODEV will then be lost with We have 4 pwm outputs that share status registers, so they are not really separable. None that I could come up with. Again, the delay should be on the order of several bus cycles. Vendor's code disables interrupts. I ...
Okay, that makes sense. I still think there must be a better way than
having a massive indirect table with all the values. Why not detect the
variant in the core code and then have something like:
int init_devices(void)
{
int board_type = detect_board_type();
switch (board_type) {
case BOARD_TYPE_VT8500:
return vt8500_init_devices();
case BOARD_TYPE_WM8505:
return wm8500_init_devices();
}
pr_err("Unknown board type\n");
BUG(); /* panic()? */
while (1)
;
}
Then you can have the peripheral setup for each of the variants in their
own files and use #defines. It may get tricky in a couple of places if
you need to be able to access some value directly which is different on
each of the variants, but that can be handled on a case by case basis.
The majority of the numbers will be passed into drivers via the resource
I meant if you have the full peripheral initialisation for each variant
Can you use one of the initcalls from a driver to to the memblock
reserve? I don't know much about how memblock works. There are also the
various large page allocators in the works, but I don't think anything
Yes. I think checkpatch has been changed to warn about spitting printk
I meant if the hardware has some specific maximum wait time then you
could just delay that long. If there is no interrupt then wait_event and
friends probably aren't going to work.
Maybe convert this to a timed loop (i.e. 1 second timeout) using
jiffies. That way you are never dependent on cpu speed. You should
probably also emit a warning if the timeout is reached and the device
I didn't have a particular solution in mind, but often by changing the
units used and rearranging the math a bit you can often avoid having to
do horrible multiplies and divides.
For now at least you could avoid the do_div by assigning period_cycles
Oops, yes. You would need a second temporary pwm for the list iterator.
It's not a big deal anyway, just though it could be made more concise ...This is more or less what I'm doing right now - except for the separation between different files. I tried to avoid duplication of similar things here. Is the indirect table really a big issue? I'm a bit reluctant to copy about the whole devices.c for each chip variant, which would be otherwise required. Further, it would add more complexity to the timer, irq, gpio, i8042 and probably some other No, drivers are initialized too late, even if compiled statically. Memblock can only be reserved through the designated machine callback, Agreed, will look into that. There is no definite maximum wait time, It depends on period_ns, which is passed in as an argument from whatever uses PWM, so I'm not sure it can be assigned directly. Thanks, Alexey --
Yeah, agreed about the duplication. My approach would require the common peripherals to be defined for each variant. I'm not entirely against the indirect table (and am even starting to think it may be the best overall solution), it's just that it can be a bit difficult to follow because to add a device you need to do the following: - Add a partially empty resource/platform_device struct - Add resource entries to the resource table definition - Add resource values to the resource table - Add assignment of resource values to device init code The indirection also makes it harder to quickly determine the IRQ number of memory address of a peripheral. The current solution using the indirect table is okay, but it would be Ah. How big a number is period_ns? Can you do something like this instead? period_cycles = ((250 / 2) * period_ns) / 10000; and still safely avoid overflows? ~Ryan -- Bluewater Systems Ltd - ARM Technology Solution Centre Ryan Mallon 5 Amuri Park, 404 Barbadoes St ryan@bluewatersys.com PO Box 13 889, Christchurch 8013 http://www.bluewatersys.com New Zealand Phone: +64 3 3779127 Freecall: Australia 1800 148 751 Fax: +64 3 3779135 USA 1800 261 2934 --
That's actually only one step more than what machines with static resource definitions require (the last one). Flexibility does come at a cost, so there should be a mathematical limit to optimization of The only current in-kernel user of PWM is the backlight, and that currently uses period_ns = 250000. At this value it does not overflow. However, in a general case the base frequency will also be returned as a large number (like 12500000) as per CLK infrastructure conventions (once that part is implemented). Further, I can't see any built-in reasons for period_ns to be bounded by anything below sizeof(int). The hardware will work with up to 4096*1024*1000000000/base_frequency (see the code for constraints), so it can in principle overflow with 32 bit arithmetics. Best regards, Alexey --
This discussion led me to look closer at the duty counter calculation: if period_ns and duty_ns are both large and close to each other (about 0.3 seconds, rare but possible use case for PWM), then (pv * duty_ns) can overflow in 32 bit multiplication for permissible argument values. Should I use do_div((u64)pv * (u64)duty_ns, period_ns) here? Best regards, Alexey --
No it isn't. You don't have the massive table, which requires
modifications to both the definition and declaration, on machines with
static resource definitions.
How about using the resource structures directly rather than introducing
the table which is effectively holding the same information? Something
like this?
In vt8500_resources.c (and similarly for wm8505_resources.c):
static struct resource vt8500_resources_uart0[] __initdata = {
[0] = {
.flags = IORESOURCE_MEM,
.start = VT8500_UART0_PHYS_BASE,
.end = VT8500_UART0_PHYS_BASE + 0xff,
},
[1] = {
.flags = IORESOURCE_IRQ,
.start = VT8500_UART0_IRQ,
.end = VT8500_UART0_IRQ,
},
};
struct resource *vt8500_resources[] __initdata = {
[VT8500_UART0] = &vt8500_resources_uart0,
...
};
In devices.c:
extern struct resource *vt8500_resources;
extern struct resource *wm8505_resources;
/* Set this pointer according to board variant */
static struct resource *resources;
void __init wmt_set_resources(void)
{
vt8500_device_uart0.resource = resources[VT8500_UART0];
...
}
This way we only have a single externed resource structure per
board-variant, there is no additional table needed, and the resource
definitions can be read clearly. Alternatively the wmt_regmaps/wmt_irqs
tables could be modified to use struct resource rather than individual
fields which would simplify the assignments later.
~Ryan
--
Bluewater Systems Ltd - ARM Technology Solution Centre
Ryan Mallon 5 Amuri Park, 404 Barbadoes St
ryan@bluewatersys.com PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com New Zealand
Phone: +64 3 3779127 Freecall: Australia 1800 148 751
Fax: +64 3 3779135 USA 1800 261 2934
--
This way we will again duplicate quite much: those files will mostly
differ in just the macro definitions of specific registers/irqs.
What if I just move all the initializations inside my runtime helper
function, and add a macro to save space and improve readability?
Something along the lines of:
static struct resource resources_lcdc[2] __initdata;
#define WMT_MMIO_RES(__start, __size) \
{\
.flags = IORESOURCE_MEM,\
.start = __start,\
.end = __start + __size - 1,\
}
#define WMT_IRQ_RES(__irq) \
{\
.flags = IORESOURCE_IRQ,\
.start = __irq,\
.end = __irq,\
}
void __init wmt_set_resources(void)
{
resources_lcdc[0] = WMT_MMIO_RES(wmt_current_regs->lcdc, SZ_1K);
resources_lcdc[1] = WMT_IRQ_RES(wmt_current_irqs->lcdc);
...
}
Then there will be no half-empty initializations scattered around
separate from the other assignments (which is probably the worst thing
in current configuration).
Best regards,
Alexey
--
If you use platform_device_add_resources() to add the resource at a later point, or platform_device_register_simple, you don't even need to statically allocate the resource structure, which may also make this simpler because you can keep all the data structures local to the function filling them out. Arnd --
Sure, that works. In this case, can we remove the wmt_current_regs table
and just have a switch statement with the two board variants in place?
The latter will actually be half as much code because the struct
definition for the table is no longer needed and each resource
assignment is still one line. i.e.:
void __init wmt_set_resources(void)
{
switch (board_type) {
case BOARD_TYPE_VT8500:
resources_lcdc[0] = WMT_MMIO_RES(VT8500_LCDC_BASE, SZ_1K);
resources_lcdc[1] = WMT_IRQ_RES(VT8500_LCDC_IRQ);
...
break;
case BOARD_TYPE_WM8505:
resources_lcdc[0] = WMT_MMIO_RES(WM8505_LCDC_BASE, SZ_1K);
resources_lcdc[1] = WMT_IRQ_RES(WM8505_LCDC_IRQ);
...
break;
}
}
~Ryan
--
Bluewater Systems Ltd - ARM Technology Solution Centre
Ryan Mallon 5 Amuri Park, 404 Barbadoes St
ryan@bluewatersys.com PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com New Zealand
Phone: +64 3 3779127 Freecall: Australia 1800 148 751
Fax: +64 3 3779135 USA 1800 261 2934
--
This adds support for the family of Systems-on-Chip produced initially by VIA and now its subsidiary WonderMedia that have recently become widespread in lower-end Chinese ARM-based tablets and netbooks. Support is included for both VT8500 and WM8505, selectable by a configuration switch at kernel build time. Included are basic machine initialization files, register and interrupt definitions, support for the on-chip interrupt controller, high-precision OS timer, GPIO lines, necessary macros for early debug, pulse-width-modulated outputs control, as well as platform device configurations for the specific drivers implemented elsewhere. Signed-off-by: Alexey Charkov <alchark@gmail.com> --- Welcome the jubilee tenth revision of this patch ;-) I've tried to incorporate the suggestions by Ryan and Arnd, hope that there is nothing left out. There was a massive reorganization of code to remove less-than-obvious magic with MMIO registers and irqs being held in huge structs, now they are again macro definitions. Those macros are, however, only included in single isolated files, and actual values to use are chosen at runtime by calling the respective routines at machine initialization. There are also stylistic changes all around, where Ryan suggested. As a result, i8042 should again be adjusted a bit to reflect the new place to find respective register/irq definitions, that one will be sent in the respective thread shortly. Best regards, Alexey arch/arm/Kconfig | 12 + arch/arm/Makefile | 1 + arch/arm/boot/compressed/Makefile | 4 + arch/arm/boot/compressed/head-vt8500.S | 46 ++++ arch/arm/mach-vt8500/Kconfig | 73 ++++++ arch/arm/mach-vt8500/Makefile | 9 + arch/arm/mach-vt8500/Makefile.boot | 3 + arch/arm/mach-vt8500/bv07.c | 77 +++++++ arch/arm/mach-vt8500/devices-vt8500.c | 117 ...
These functions can be marked __init (though I guess they already are if
marked inline?). They should also have lower case names since they are
proper functions.
Do these functions generate warnings about returning temporary values
off the stack? If so, they could be rewritten as:
static __init void wmt_mmio_res(struct resource *res,
u32 start, u32 size)
{
res->flags = IORESOURCE_MEM;
res->start = start;
res->end = start + size - 1;
}
You could also make these functions static inline in devices.h to avoid
This could be written as a proper function. The resource add is unlikely
to fail. Maybe keep the warning but don't worry about printing the
device name?
~Ryan
--
Bluewater Systems Ltd - ARM Technology Solution Centre
Ryan Mallon 5 Amuri Park, 404 Barbadoes St
ryan@bluewatersys.com PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com New Zealand
Phone: +64 3 3779127 Freecall: Australia 1800 148 751
Fax: +64 3 3779135 USA 1800 261 2934
--
As inline functions are unrolled into the caller at compile time, and the caller is __init, I would expect their code to be freed after init There is memory allocation inside platform_device_add_resources, so probably there is scope for failure. I could add unlikely(), though. Thanks, Alexey --
If the compiler decided not to inline them for whatever reason they
would stick around. They should also probably be marked __init to make
I thought you might get compile time warnings. Returning things off the
stack in general is error prone. I think passing a pointer to the
I meant more in terms of losing the device name in the error which seems
to be the sole point of the macro. i.e it could be rewritten as:
static void wmt_add_resource(struct platform_device *pdev,
const struct resource *res,
unsigned num)
{
if (platform_device_add_resources(pdev, res, num))
pr_err("Failed to add device resource\n");
}
Because the add resource failing would indicate some serious problem you
may even want to BUG().
~Ryan
--
Bluewater Systems Ltd - ARM Technology Solution Centre
Ryan Mallon 5 Amuri Park, 404 Barbadoes St
ryan@bluewatersys.com PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com New Zealand
Phone: +64 3 3779127 Freecall: Australia 1800 148 751
Fax: +64 3 3779135 USA 1800 261 2934
--
This adds support for the family of Systems-on-Chip produced initially
by VIA and now its subsidiary WonderMedia that have recently become
widespread in lower-end Chinese ARM-based tablets and netbooks.
Support is included for both VT8500 and WM8505, selectable by a
configuration switch at kernel build time.
Included are basic machine initialization files, register and
interrupt definitions, support for the on-chip interrupt controller,
high-precision OS timer, GPIO lines, necessary macros for early debug,
pulse-width-modulated outputs control, as well as platform device
configurations for the specific drivers implemented elsewhere.
Signed-off-by: Alexey Charkov <alchark@gmail.com>
---
This incorporates latest comments by Ryan regarding helper inlines
in devices-{vt8500,wm8505}.c
Best regards,
Alexey
arch/arm/Kconfig | 12 +
arch/arm/Makefile | 1 +
arch/arm/boot/compressed/Makefile | 4 +
arch/arm/boot/compressed/head-vt8500.S | 46 ++++
arch/arm/mach-vt8500/Kconfig | 73 ++++++
arch/arm/mach-vt8500/Makefile | 9 +
arch/arm/mach-vt8500/Makefile.boot | 3 +
arch/arm/mach-vt8500/bv07.c | 77 +++++++
arch/arm/mach-vt8500/devices-vt8500.c | 91 ++++++++
arch/arm/mach-vt8500/devices-wm8505.c | 99 +++++++++
arch/arm/mach-vt8500/devices.c | 270 +++++++++++++++++++++++
arch/arm/mach-vt8500/devices.h | 88 ++++++++
arch/arm/mach-vt8500/gpio.c | 233 +++++++++++++++++++
arch/arm/mach-vt8500/include/mach/debug-macro.S | 31 +++
arch/arm/mach-vt8500/include/mach/entry-macro.S | 32 +++
arch/arm/mach-vt8500/include/mach/gpio.h | 6 +
arch/arm/mach-vt8500/include/mach/hardware.h | 12 +
arch/arm/mach-vt8500/include/mach/i8042.h | 18 ++
arch/arm/mach-vt8500/include/mach/io.h | 28 +++
...The magic numbers (0x20) in the gpio functions should probably be
#defined as register names. I'm guessing this is the input enable
register? Often people do helper functions for this, i.e:
static inline void gpio_write_reg(struct vt8500_gpio_chip *chip,
unsigned val, unsigned reg)
{
writel(val, regbase + chip->regoff + reg);
}
Other than that, looks good.
Reviewed-by: Ryan Mallon <ryan@bluewatersys.com>
--
Bluewater Systems Ltd - ARM Technology Solution Centre
Ryan Mallon 5 Amuri Park, 404 Barbadoes St
ryan@bluewatersys.com PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com New Zealand
Phone: +64 3 3779127 Freecall: Australia 1800 148 751
Fax: +64 3 3779135 USA 1800 261 2934
--
This adds support for the family of Systems-on-Chip produced initially by VIA and now its subsidiary WonderMedia that have recently become widespread in lower-end Chinese ARM-based tablets and netbooks. Support is included for both VT8500 and WM8505, selectable by a configuration switch at kernel build time. Included are basic machine initialization files, register and interrupt definitions, support for the on-chip interrupt controller, high-precision OS timer, GPIO lines, necessary macros for early debug, pulse-width-modulated outputs control, as well as platform device configurations for the specific drivers implemented elsewhere. Signed-off-by: Alexey Charkov <alchark@gmail.com> --- This fixes magic numbers in gpio.c Thanks, Alexey arch/arm/Kconfig | 12 + arch/arm/Makefile | 1 + arch/arm/boot/compressed/Makefile | 4 + arch/arm/boot/compressed/head-vt8500.S | 46 ++++ arch/arm/mach-vt8500/Kconfig | 73 ++++++ arch/arm/mach-vt8500/Makefile | 9 + arch/arm/mach-vt8500/Makefile.boot | 3 + arch/arm/mach-vt8500/bv07.c | 77 +++++++ arch/arm/mach-vt8500/devices-vt8500.c | 91 ++++++++ arch/arm/mach-vt8500/devices-wm8505.c | 99 +++++++++ arch/arm/mach-vt8500/devices.c | 270 +++++++++++++++++++++++ arch/arm/mach-vt8500/devices.h | 88 ++++++++ arch/arm/mach-vt8500/gpio.c | 240 ++++++++++++++++++++ arch/arm/mach-vt8500/include/mach/debug-macro.S | 31 +++ arch/arm/mach-vt8500/include/mach/entry-macro.S | 32 +++ arch/arm/mach-vt8500/include/mach/gpio.h | 6 + arch/arm/mach-vt8500/include/mach/hardware.h | 12 + arch/arm/mach-vt8500/include/mach/i8042.h | 18 ++ arch/arm/mach-vt8500/include/mach/io.h | 28 +++ arch/arm/mach-vt8500/include/mach/irqs.h | 22 ++ ...
Russell, will you take this for .38? Please note that the last revision of this patch was also submitted to the ARM Linux patch tracking system: http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=6597/1 Best regards, Alexey --
A couple of other points - sorry, should've been in the last mail. ioremap() is generally regarded as a function which can fail, and therefore needs its return value checked. There seems to be multiple instances of this through this patch. --
Is it OK to simply skip the code that uses the relevant pointer if ioremap fails (possibly issuing an error via printk)? The problem is that these are void functions, so I can't just return -ENODEV on failure. --
