* [PATCHv3 1/9] arm: vt8500: Add device tree files for VIA/Wondermedia SoC's
From: Tony Prisk @ 2012-08-21 20:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1345582058-2291-1-git-send-email-linux@prisktech.co.nz>
Add device tree files for VT8500, WM8505 and WM8650 SoC's and
reference boards.
Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
---
arch/arm/boot/dts/vt8500-bv07.dts | 31 +++++++++
arch/arm/boot/dts/vt8500.dtsi | 100 +++++++++++++++++++++++++++
arch/arm/boot/dts/wm8505-ref.dts | 31 +++++++++
arch/arm/boot/dts/wm8505.dtsi | 126 +++++++++++++++++++++++++++++++++
arch/arm/boot/dts/wm8650-mid.dts | 31 +++++++++
arch/arm/boot/dts/wm8650.dtsi | 138 +++++++++++++++++++++++++++++++++++++
6 files changed, 457 insertions(+)
create mode 100644 arch/arm/boot/dts/vt8500-bv07.dts
create mode 100644 arch/arm/boot/dts/vt8500.dtsi
create mode 100644 arch/arm/boot/dts/wm8505-ref.dts
create mode 100644 arch/arm/boot/dts/wm8505.dtsi
create mode 100644 arch/arm/boot/dts/wm8650-mid.dts
create mode 100644 arch/arm/boot/dts/wm8650.dtsi
diff --git a/arch/arm/boot/dts/vt8500-bv07.dts b/arch/arm/boot/dts/vt8500-bv07.dts
new file mode 100644
index 0000000..339a664
--- /dev/null
+++ b/arch/arm/boot/dts/vt8500-bv07.dts
@@ -0,0 +1,31 @@
+/*
+ * vt8500-bv07.dts - Device tree file for Benign BV07 Netbook
+ *
+ * Copyright (C) 2012 Tony Prisk <linux@prisktech.co.nz>
+ *
+ * Licensed under GPLv2 or later
+ */
+
+/dts-v1/;
+/include/ "vt8500.dtsi"
+
+/ {
+ model = "Benign BV07 Netbook";
+
+ /*
+ * Display node is based on Sascha Hauer's patch on dri-devel.
+ * Added a bpp property to calculate the size of the framebuffer
+ * until the binding is formalized.
+ */
+ display: display {
+ xres = <800>;
+ yres = <480>;
+ left-margin = <88>;
+ right-margin = <40>;
+ hsync-len = <0>;
+ upper-margin = <32>;
+ lower-margin = <11>;
+ vsync-len = <1>;
+ bpp = <16>;
+ };
+};
diff --git a/arch/arm/boot/dts/vt8500.dtsi b/arch/arm/boot/dts/vt8500.dtsi
new file mode 100644
index 0000000..78571d5
--- /dev/null
+++ b/arch/arm/boot/dts/vt8500.dtsi
@@ -0,0 +1,100 @@
+/*
+ * vt8500.dtsi - Device tree file for VIA VT8500 SoC
+ *
+ * Copyright (C) 2012 Tony Prisk <linux@prisktech.co.nz>
+ *
+ * Licensed under GPLv2 or later
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+ compatible = "via,vt8500";
+
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ ranges;
+ interrupt-parent = <&intc>;
+
+ intc: interrupt-controller@d8140000 {
+ compatible = "via,vt8500-intc";
+ interrupt-controller;
+ reg = <0xd8140000 0x10000>;
+ #interrupt-cells = <1>;
+ };
+
+ gpio: gpio-controller@d8110000 {
+ compatible = "via,vt8500-gpio";
+ gpio-controller;
+ reg = <0xd8110000 0x10000>;
+ #gpio-cells = <3>;
+ };
+
+ pmc@d8130000 {
+ compatible = "via,vt8500-pmc";
+ reg = <0xd8130000 0x1000>;
+ };
+
+ timer@d8130100 {
+ compatible = "via,vt8500-timer";
+ reg = <0xd8130100 0x28>;
+ interrupts = <36>;
+ };
+
+ ehci@d8007900 {
+ compatible = "via,vt8500-ehci";
+ reg = <0xd8007900 0x200>;
+ interrupts = <43>;
+ };
+
+ uhci@d8007b00 {
+ compatible = "platform-uhci";
+ reg = <0xd8007b00 0x200>;
+ interrupts = <43>;
+ };
+
+ fb@d800e400 {
+ compatible = "via,vt8500-fb";
+ reg = <0xd800e400 0x400>;
+ interrupts = <12>;
+ via,display = <&display>;
+ };
+
+ ge_rops@d8050400 {
+ compatible = "wm,prizm-ge-rops";
+ reg = <0xd8050400 0x100>;
+ };
+
+ uart@d8200000 {
+ compatible = "via,vt8500-uart";
+ reg = <0xd8200000 0x1040>;
+ interrupts = <32>;
+ };
+
+ uart@d82b0000 {
+ compatible = "via,vt8500-uart";
+ reg = <0xd82b0000 0x1040>;
+ interrupts = <33>;
+ };
+
+ uart@d8210000 {
+ compatible = "via,vt8500-uart";
+ reg = <0xd8210000 0x1040>;
+ interrupts = <47>;
+ };
+
+ uart@d82c0000 {
+ compatible = "via,vt8500-uart";
+ reg = <0xd82c0000 0x1040>;
+ interrupts = <50>;
+ };
+
+ rtc@d8100000 {
+ compatible = "via,vt8500-rtc";
+ reg = <0xd8100000 0x10000>;
+ interrupts = <48>;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/wm8505-ref.dts b/arch/arm/boot/dts/wm8505-ref.dts
new file mode 100644
index 0000000..fcd9836
--- /dev/null
+++ b/arch/arm/boot/dts/wm8505-ref.dts
@@ -0,0 +1,31 @@
+/*
+ * wm8505-ref.dts - Device tree file for Wondermedia WM8505 reference netbook
+ *
+ * Copyright (C) 2012 Tony Prisk <linux@prisktech.co.nz>
+ *
+ * Licensed under GPLv2 or later
+ */
+
+/dts-v1/;
+/include/ "wm8505.dtsi"
+
+/ {
+ model = "Wondermedia WM8505 Netbook";
+
+ /*
+ * Display node is based on Sascha Hauer's patch on dri-devel.
+ * Added a bpp property to calculate the size of the framebuffer
+ * until the binding is formalized.
+ */
+ display: display {
+ xres = <800>;
+ yres = <480>;
+ left-margin = <88>;
+ right-margin = <40>;
+ hsync-len = <0>;
+ upper-margin = <32>;
+ lower-margin = <11>;
+ vsync-len = <1>;
+ bpp = <32>;
+ };
+};
diff --git a/arch/arm/boot/dts/wm8505.dtsi b/arch/arm/boot/dts/wm8505.dtsi
new file mode 100644
index 0000000..64a3d7f
--- /dev/null
+++ b/arch/arm/boot/dts/wm8505.dtsi
@@ -0,0 +1,126 @@
+/*
+ * wm8505.dtsi - Device tree file for Wondermedia WM8505 SoC
+ *
+ * Copyright (C) 2012 Tony Prisk <linux@prisktech.co.nz>
+ *
+ * Licensed under GPLv2 or later
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+ compatible = "wm,wm8505";
+
+ cpus {
+ cpu@0 {
+ compatible = "arm,arm926ejs";
+ };
+ };
+
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ ranges;
+ interrupt-parent = <&intc0>;
+
+ intc0: interrupt-controller@d8140000 {
+ compatible = "via,vt8500-intc";
+ interrupt-controller;
+ reg = <0xd8140000 0x10000>;
+ #interrupt-cells = <1>;
+ };
+
+ /* Secondary IC cascaded to intc0 */
+ intc1: interrupt-controller@d8150000 {
+ compatible = "via,vt8500-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ reg = <0xD8150000 0x10000>;
+ interrupts = <56 57 58 59 60 61 62 63>;
+ };
+
+ gpio: gpio-controller@d8110000 {
+ compatible = "wm,wm8505-gpio";
+ gpio-controller;
+ reg = <0xd8110000 0x10000>;
+ #gpio-cells = <3>;
+ };
+
+ pmc@d8130000 {
+ compatible = "via,vt8500-pmc";
+ reg = <0xd8130000 0x1000>;
+ };
+
+ timer@d8130100 {
+ compatible = "via,vt8500-timer";
+ reg = <0xd8130100 0x28>;
+ interrupts = <36>;
+ };
+
+ ehci@d8007100 {
+ compatible = "via,vt8500-ehci";
+ reg = <0xd8007100 0x200>;
+ interrupts = <43>;
+ };
+
+ uhci@d8007300 {
+ compatible = "platform-uhci";
+ reg = <0xd8007300 0x200>;
+ interrupts = <43>;
+ };
+
+ fb@d8050800 {
+ compatible = "wm,wm8505-fb";
+ reg = <0xd8050800 0x200>;
+ via,display = <&display>;
+ };
+
+ ge_rops@d8050400 {
+ compatible = "wm,prizm-ge-rops";
+ reg = <0xd8050400 0x100>;
+ };
+
+ uart@d8200000 {
+ compatible = "via,vt8500-uart";
+ reg = <0xd8200000 0x1040>;
+ interrupts = <32>;
+ };
+
+ uart@d82b0000 {
+ compatible = "via,vt8500-uart";
+ reg = <0xd82b0000 0x1040>;
+ interrupts = <33>;
+ };
+
+ uart@d8210000 {
+ compatible = "via,vt8500-uart";
+ reg = <0xd8210000 0x1040>;
+ interrupts = <47>;
+ };
+
+ uart@d82c0000 {
+ compatible = "via,vt8500-uart";
+ reg = <0xd82c0000 0x1040>;
+ interrupts = <50>;
+ };
+
+ uart@d8370000 {
+ compatible = "via,vt8500-uart";
+ reg = <0xd8370000 0x1040>;
+ interrupts = <31>;
+ };
+
+ uart@d8380000 {
+ compatible = "via,vt8500-uart";
+ reg = <0xd8380000 0x1040>;
+ interrupts = <30>;
+ };
+
+ rtc@d8100000 {
+ compatible = "via,vt8500-rtc";
+ reg = <0xd8100000 0x10000>;
+ interrupts = <48>;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/wm8650-mid.dts b/arch/arm/boot/dts/wm8650-mid.dts
new file mode 100644
index 0000000..d37dbf0
--- /dev/null
+++ b/arch/arm/boot/dts/wm8650-mid.dts
@@ -0,0 +1,31 @@
+/*
+ * wm8650-mid.dts - Device tree file for Wondermedia WM8650-MID Tablet
+ *
+ * Copyright (C) 2012 Tony Prisk <linux@prisktech.co.nz>
+ *
+ * Licensed under GPLv2 or later
+ */
+
+/dts-v1/;
+/include/ "wm8650.dtsi"
+
+/ {
+ model = "Wondermedia WM8650-MID Tablet";
+
+ /*
+ * Display node is based on Sascha Hauer's patch on dri-devel.
+ * Added a bpp property to calculate the size of the framebuffer
+ * until the binding is formalized.
+ */
+ display: display {
+ xres = <800>;
+ yres = <480>;
+ left-margin = <88>;
+ right-margin = <40>;
+ hsync-len = <0>;
+ upper-margin = <32>;
+ lower-margin = <11>;
+ vsync-len = <1>;
+ bpp = <16>;
+ };
+};
diff --git a/arch/arm/boot/dts/wm8650.dtsi b/arch/arm/boot/dts/wm8650.dtsi
new file mode 100644
index 0000000..e4ca840
--- /dev/null
+++ b/arch/arm/boot/dts/wm8650.dtsi
@@ -0,0 +1,138 @@
+/*
+ * wm8650.dtsi - Device tree file for Wondermedia WM8650 SoC
+ *
+ * Copyright (C) 2012 Tony Prisk <linux@prisktech.co.nz>
+ *
+ * Licensed under GPLv2 or later
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+ compatible = "wm,wm8650";
+
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ ranges;
+ interrupt-parent = <&intc0>;
+
+ intc0: interrupt-controller@d8140000 {
+ compatible = "via,vt8500-intc";
+ interrupt-controller;
+ reg = <0xd8140000 0x10000>;
+ #interrupt-cells = <1>;
+ };
+
+ /* Secondary IC cascaded to intc0 */
+ intc1: interrupt-controller@d8150000 {
+ compatible = "via,vt8500-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ reg = <0xD8150000 0x10000>;
+ interrupts = <56 57 58 59 60 61 62 63>;
+ };
+
+ gpio: gpio-controller@d8110000 {
+ compatible = "wm,wm8650-gpio";
+ gpio-controller;
+ reg = <0xd8110000 0x10000>;
+ #gpio-cells = <3>;
+ };
+
+ pmc@d8130000 {
+ compatible = "via,vt8500-pmc";
+ reg = <0xd8130000 0x1000>;
+
+ clocks {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ref25: ref25M {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <25000000>;
+ };
+
+ plla: plla {
+ #clock-cells = <0>;
+ compatible = "wm,wm8650-pll-clock";
+ clocks = <&ref25>;
+ reg = <0x200>;
+ };
+
+ pllb: pllb {
+ #clock-cells = <0>;
+ compatible = "wm,wm8650-pll-clock";
+ clocks = <&ref25>;
+ reg = <0x204>;
+ };
+
+ arm: arm {
+ #clock-cells = <0>;
+ compatible = "via,vt8500-device-clock";
+ clocks = <&plla>;
+ divisor-reg = <0x300>;
+ };
+
+ sdhc: sdhc {
+ #clock-cells = <0>;
+ compatible = "via,vt8500-device-clock";
+ clocks = <&pllb>;
+ divisor-reg = <0x328>;
+ divisor-mask = <0x3f>;
+ enable-reg = <0x254>;
+ enable-bit = <18>;
+ };
+ };
+ };
+
+ timer@d8130100 {
+ compatible = "via,vt8500-timer";
+ reg = <0xd8130100 0x28>;
+ interrupts = <36>;
+ };
+
+ ehci@d8007900 {
+ compatible = "via,vt8500-ehci";
+ reg = <0xd8007900 0x200>;
+ interrupts = <43>;
+ };
+
+ uhci@d8007b00 {
+ compatible = "platform-uhci";
+ reg = <0xd8007b00 0x200>;
+ interrupts = <43>;
+ };
+
+ fb@d8050800 {
+ compatible = "wm,wm8505-fb";
+ reg = <0xd8050800 0x200>;
+ via,display = <&display>;
+ };
+
+ ge_rops@d8050400 {
+ compatible = "wm,prizm-ge-rops";
+ reg = <0xd8050400 0x100>;
+ };
+
+ uart@d8200000 {
+ compatible = "via,vt8500-uart";
+ reg = <0xd8200000 0x1040>;
+ interrupts = <32>;
+ };
+
+ uart@d82b0000 {
+ compatible = "via,vt8500-uart";
+ reg = <0xd82b0000 0x1040>;
+ interrupts = <33>;
+ };
+
+ rtc@d8100000 {
+ compatible = "via,vt8500-rtc";
+ reg = <0xd8100000 0x10000>;
+ interrupts = <48>;
+ };
+ };
+};
--
1.7.9.5
^ permalink raw reply related
* [PATCHv3 0/9] *** ARM: Update arch-vt8500 to Devicetree ***
From: Tony Prisk @ 2012-08-21 20:47 UTC (permalink / raw)
To: linux-arm-kernel
This patchset updates arch-vt8500 to devicetree and removes all the old-style
code. Support for WM8650 has also been added.
Example dts/dtsi files are given for the three currently supported models.
Major changes:
GPIO code has been converted to a platform_device and rewritten as WM8505
support was broken. Add support for WM8650 gpio controller.
UHCI support was missing. Added this as a generic non-pci uhci controller as
it doesn't require anything special. Should be usable by any system that doesn't
have special requirements to get the UHCI controller working.
Framebuffer code patched to support WM8650. The bindings for this are of concern
but there doesn't seem to be a formalized binding yet. This patch is based off
Sascha Hauer's current patch on the dri-devel mailing list and should be easily
patched out when its finalized.
Patchset based on Arnd's arm-soc/for-next branch.
Could I get this reviewed, hopefully for inclusion into v3.7.
Regards
Tony Prisk
Changes
v2:
Cleanup style/formatting errors
Removed erroneous commit message about GPIO not being converted to devicetree
Corrected arch-vt8500/irq.c header to correct filename
Changed GPIO driver to use module_platform_driver()
Renamed vt8500_gpio_bank_regs -> vt8500_gpio_bank_regoffsets
Changed vt8500_gpio_bank_regoffset fields to unsigned int
Changed bit-setting code to use BIT() macro
Removed of_find_compatible() and use pdev->dev.of_node in _probe()
Removed regoff field and related code - leftover from old design
Added kerneldoc regarding struct vt8500_gpio_bank_regoffsets fields
Update MODULE_LICENSE on all platform devices to "GPL v2" to match their headers
Renamed dts board files to clarify product names
v3:
Corrected serial driver issue after porting to device tree. pdev->id no longer
valid.
Corrected irq.c to properly initialize slaved interrupt controller.
Updated framebuffer drivers to use phandles for display node.
Corrected dts definitions for updated framebuffer driver.
EHCI/UHCI patch (Patch 4/9) already in -next via usb-next tree.
Included common clock frame support.
Added initialization code to arch/arm/mach-vt8500/vt8500.c for clocks.
Updated wm8650.dtsi to include basic clocks.
Tony Prisk (9):
arm: vt8500: Add device tree files for VIA/Wondermedia SoC's
rtc: vt8500: Add devicetree support for vt8500-rtc
serial: vt8500: Add devicetree support for vt8500-serial
usb: vt8500: Add devicetree support for vt8500-ehci and -uhci.
video: vt8500: Add devicetree support for vt8500-fb and wm8505-fb
arm: vt8500: Update arch-vt8500 to devicetree support.
arm: vt8500: doc: Add device tree bindings for arch-vt8500 devices
arm: vt8500: gpio: Devicetree support for arch-vt8500
arm: vt8500: clk: Add Common Clock Framework support
Documentation/devicetree/bindings/arm/vt8500.txt | 15 +
.../bindings/arm/vt8500/via,vt8500-intc.txt | 16 +
.../bindings/arm/vt8500/via,vt8500-pmc.txt | 13 +
.../bindings/arm/vt8500/via,vt8500-timer.txt | 15 +
Documentation/devicetree/bindings/clock/vt8500.txt | 72 +++
.../devicetree/bindings/gpio/gpio_vt8500.txt | 24 +
.../devicetree/bindings/rtc/via,vt8500-rtc.txt | 15 +
.../bindings/tty/serial/via,vt8500-uart.txt | 15 +
.../devicetree/bindings/usb/platform-uhci.txt | 15 +
.../devicetree/bindings/usb/via,vt8500-ehci.txt | 15 +
.../devicetree/bindings/vendor-prefixes.txt | 2 +
.../devicetree/bindings/video/via,vt8500-fb.txt | 48 ++
.../devicetree/bindings/video/wm,prizm-ge-rops.txt | 13 +
.../devicetree/bindings/video/wm,wm8505-fb.txt | 22 +
arch/arm/Kconfig | 5 +
arch/arm/boot/dts/vt8500-bv07.dts | 31 ++
arch/arm/boot/dts/vt8500.dtsi | 100 ++++
arch/arm/boot/dts/wm8505-ref.dts | 31 ++
arch/arm/boot/dts/wm8505.dtsi | 126 +++++
arch/arm/boot/dts/wm8650-mid.dts | 31 ++
arch/arm/boot/dts/wm8650.dtsi | 138 ++++++
arch/arm/mach-vt8500/Kconfig | 72 +--
arch/arm/mach-vt8500/Makefile | 9 +-
arch/arm/mach-vt8500/bv07.c | 80 ----
arch/arm/mach-vt8500/common.h | 28 ++
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/restart.h | 4 +-
arch/arm/mach-vt8500/include/mach/vt8500_irqs.h | 88 ----
arch/arm/mach-vt8500/include/mach/vt8500_regs.h | 79 ----
arch/arm/mach-vt8500/include/mach/wm8505_irqs.h | 115 -----
arch/arm/mach-vt8500/include/mach/wm8505_regs.h | 78 ---
arch/arm/mach-vt8500/irq.c | 209 +++++----
arch/arm/mach-vt8500/restart.c | 54 ---
arch/arm/mach-vt8500/timer.c | 67 ++-
arch/arm/mach-vt8500/vt8500.c | 196 ++++++++
arch/arm/mach-vt8500/wm8505_7in.c | 79 ----
drivers/clk/Makefile | 1 +
drivers/clk/clk-vt8500.c | 496 ++++++++++++++++++++
drivers/gpio/Kconfig | 6 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-vt8500.c | 313 ++++++++++++
drivers/rtc/rtc-vt8500.c | 9 +-
drivers/tty/serial/vt8500_serial.c | 37 +-
drivers/usb/host/Kconfig | 4 +-
drivers/usb/host/ehci-vt8500.c | 25 +-
drivers/usb/host/uhci-hcd.c | 5 +
drivers/usb/host/uhci-platform.c | 169 +++++++
drivers/video/Kconfig | 6 +-
drivers/video/vt8500lcdfb.c | 79 +++-
drivers/video/wm8505fb.c | 97 +++-
drivers/video/wmt_ge_rops.c | 9 +-
55 files changed, 2384 insertions(+), 1581 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/vt8500.txt
create mode 100644 Documentation/devicetree/bindings/arm/vt8500/via,vt8500-intc.txt
create mode 100644 Documentation/devicetree/bindings/arm/vt8500/via,vt8500-pmc.txt
create mode 100644 Documentation/devicetree/bindings/arm/vt8500/via,vt8500-timer.txt
create mode 100644 Documentation/devicetree/bindings/clock/vt8500.txt
create mode 100644 Documentation/devicetree/bindings/gpio/gpio_vt8500.txt
create mode 100644 Documentation/devicetree/bindings/rtc/via,vt8500-rtc.txt
create mode 100644 Documentation/devicetree/bindings/tty/serial/via,vt8500-uart.txt
create mode 100644 Documentation/devicetree/bindings/usb/platform-uhci.txt
create mode 100644 Documentation/devicetree/bindings/usb/via,vt8500-ehci.txt
create mode 100644 Documentation/devicetree/bindings/video/via,vt8500-fb.txt
create mode 100644 Documentation/devicetree/bindings/video/wm,prizm-ge-rops.txt
create mode 100644 Documentation/devicetree/bindings/video/wm,wm8505-fb.txt
create mode 100644 arch/arm/boot/dts/vt8500-bv07.dts
create mode 100644 arch/arm/boot/dts/vt8500.dtsi
create mode 100644 arch/arm/boot/dts/wm8505-ref.dts
create mode 100644 arch/arm/boot/dts/wm8505.dtsi
create mode 100644 arch/arm/boot/dts/wm8650-mid.dts
create mode 100644 arch/arm/boot/dts/wm8650.dtsi
delete mode 100644 arch/arm/mach-vt8500/bv07.c
create mode 100644 arch/arm/mach-vt8500/common.h
delete mode 100644 arch/arm/mach-vt8500/devices-vt8500.c
delete mode 100644 arch/arm/mach-vt8500/devices-wm8505.c
delete mode 100644 arch/arm/mach-vt8500/devices.c
delete mode 100644 arch/arm/mach-vt8500/devices.h
delete mode 100644 arch/arm/mach-vt8500/gpio.c
delete mode 100644 arch/arm/mach-vt8500/include/mach/vt8500_irqs.h
delete mode 100644 arch/arm/mach-vt8500/include/mach/vt8500_regs.h
delete mode 100644 arch/arm/mach-vt8500/include/mach/wm8505_irqs.h
delete mode 100644 arch/arm/mach-vt8500/include/mach/wm8505_regs.h
delete mode 100644 arch/arm/mach-vt8500/restart.c
create mode 100644 arch/arm/mach-vt8500/vt8500.c
delete mode 100644 arch/arm/mach-vt8500/wm8505_7in.c
create mode 100644 drivers/clk/clk-vt8500.c
create mode 100644 drivers/gpio/gpio-vt8500.c
create mode 100644 drivers/usb/host/uhci-platform.c
--
1.7.9.5
^ permalink raw reply
* [PATCH -next] HID: picoLCD: Add missing #include <linux/uaccess.h>
From: Geert Uytterhoeven @ 2012-08-21 20:41 UTC (permalink / raw)
To: Bruno Prémont, Jiri Kosina
Cc: linux-input, linux-next, linux-kernel, linux-fbdev,
Geert Uytterhoeven
m68k/allmodconfig:
drivers/hid/hid-picolcd_debugfs.c: In function ‘picolcd_debug_reset_write’:
drivers/hid/hid-picolcd_debugfs.c:54: error: implicit declaration of function ‘copy_from_user’
drivers/hid/hid-picolcd_debugfs.c: In function ‘picolcd_debug_eeprom_read’:
drivers/hid/hid-picolcd_debugfs.c:112: error: implicit declaration of function ‘copy_to_user’
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
http://kisskb.ellerman.id.au/kisskb/buildresult/6990818/
drivers/hid/hid-picolcd_debugfs.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/hid/hid-picolcd_debugfs.c b/drivers/hid/hid-picolcd_debugfs.c
index f2491fa..15c22f2 100644
--- a/drivers/hid/hid-picolcd_debugfs.c
+++ b/drivers/hid/hid-picolcd_debugfs.c
@@ -27,6 +27,7 @@
#include <linux/debugfs.h>
#include <linux/module.h>
+#include <linux/uaccess.h>
#include "hid-picolcd.h"
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH v4 1/3] Runtime Interpreted Power Sequences
From: Mark Brown @ 2012-08-21 16:57 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Thierry Reding, Alex Courbot, Stephen Warren, Simon Glass,
Grant Likely, Rob Herring, Anton Vorontsov, David Woodhouse,
Arnd Bergmann, Leela Krishna Amudala, linux-tegra@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-fbdev@vger.kernel.org,
devicetree-discuss@lists.ozlabs.org, linux-doc@vger.kernel.org
In-Reply-To: <1345542860.4085.40.camel@deskari>
[-- Attachment #1: Type: text/plain, Size: 873 bytes --]
On Tue, Aug 21, 2012 at 12:54:20PM +0300, Tomi Valkeinen wrote:
> However, if we already have a generic driver for that type of panel,
> (which we would need anyway for the DT based approach), the developer
> only needs to add the name of the panel and the data for the power
> sequence to the panel driver's database, which is about the same amount
> of work as with DT.
> So it's really just a question of where to put the data in question, DT
> or driver. Both contain the same data, and the data structure may also
> be the same. In DT's case it just needs to be parsed first, whereas in
> database case you'll enter the data in structs.
I think the device tree idiomatic way of doing this is to have a bunch
of .dtsi files for the panels which then get included by reference in
the board files. This isn't helpful to people working on non-DT
architectures though.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] fbcon: fix race condition between console lock and cursor timer
From: Josh Boyer @ 2012-08-21 13:19 UTC (permalink / raw)
To: Dave Airlie
Cc: linux-fbdev, dri-devel, linux-kernel, Linus, Alan Cox,
Randy Dunlap, kernel-team
In-Reply-To: <1345531207-24926-1-git-send-email-airlied@redhat.com>
On Tue, Aug 21, 2012 at 2:40 AM, Dave Airlie <airlied@redhat.com> wrote:
> So we've had a fair few reports of fbcon handover breakage between
> efi/vesafb and i915 surface recently, so I dedicated a couple of
> days to finding the problem.
>
> Essentially the last thing we saw was the conflicting framebuffer
> message and that was all.
>
> So after much tracing with direct netconsole writes (printks
> under console_lock not so useful), I think I found the race.
>
> Thread A (driver load) Thread B (timer thread)
> unbind_con_driver -> |
> bind_con_driver -> |
> vc->vc_sw->con_deinit -> |
> fbcon_deinit -> |
> console_lock() |
> | |
> | fbcon_flashcursor timer fires
> | console_lock() <- blocked for A
> |
> |
> fbcon_del_cursor_timer ->
> del_timer_sync
> (BOOM)
>
> Of course because all of this is under the console lock,
> we never see anything, also since we also just unbound the active
> console guess what we never see anything.
>
> Hopefully this fixes the problem for anyone seeing vesafb->kms
> driver handoff.
>
> Signed-off-by: David Airlie <airlied@redhat.com>
> ---
> drivers/video/console/fbcon.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
> index 2e471c2..f8a79fc 100644
> --- a/drivers/video/console/fbcon.c
> +++ b/drivers/video/console/fbcon.c
> @@ -372,8 +372,12 @@ static void fb_flashcursor(struct work_struct *work)
> struct vc_data *vc = NULL;
> int c;
> int mode;
> + int ret;
> +
> + ret = console_trylock();
> + if (ret = 0)
> + return;
>
> - console_lock();
> if (ops && ops->currcon != -1)
> vc = vc_cons[ops->currcon].d;
>
I have a Dell XPS 8300 machine with a Radeon card in it that started
showing this problem yesterday with 3.6-rc2 kernels. I tested this
patch on top of v3.6-rc2-206-g10c63c9 this morning and the problem
seems to have been cleared up for me. That includes making sure the
grub2 file has the gfxterm set, etc.
I know we've been seeing this quite a bit more on Fedora 17, so we'll
want to have some people test a 3.5 build with it but things are
looking better.
josh
^ permalink raw reply
* Re: [PATCH] fbcon: fix race condition between console lock and cursor timer
From: Peter Zijlstra @ 2012-08-21 12:15 UTC (permalink / raw)
To: Alan Cox
Cc: Dave Airlie, linux-fbdev, dri-devel, linux-kernel, Linus,
Randy Dunlap, Josh Boyer
In-Reply-To: <20120821101505.61c0221a@pyramind.ukuu.org.uk>
On Tue, 2012-08-21 at 10:15 +0100, Alan Cox wrote:
> > So after much tracing with direct netconsole writes (printks
> > under console_lock not so useful), I think I found the race.
>
> Direct netconsole write would be a useful patch to have mainline I think
> 8)
could we make that use the earlyprintk infrastructure?
^ permalink raw reply
* Re: [PATCH] fbcon: fix race condition between console lock and cursor timer
From: Peter Zijlstra @ 2012-08-21 12:14 UTC (permalink / raw)
To: Dave Airlie
Cc: linux-fbdev, dri-devel, linux-kernel, Linus, Alan Cox,
Randy Dunlap, Josh Boyer
In-Reply-To: <1345531207-24926-1-git-send-email-airlied@redhat.com>
On Tue, 2012-08-21 at 16:40 +1000, Dave Airlie wrote:
> So after much tracing with direct netconsole writes (printks
> under console_lock not so useful)
I always use earlyprintk on serial..
^ permalink raw reply
* Re: [PATCH V5 1/6] OMAPDSS: DISPC: cleanup cpu_is_xxxx checks
From: Mahapatra, Chandrabhanu @ 2012-08-21 11:32 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1345545102.4085.44.camel@deskari>
On Tue, Aug 21, 2012 at 4:01 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On Mon, 2012-08-20 at 18:52 +0530, Chandrabhanu Mahapatra wrote:
>> All the cpu_is checks have been moved to dispc_init_features function providing
>> a much more generic and cleaner interface. The OMAP version and revision
>> specific functions and data are initialized by dispc_features structure which is
>> local to dispc.c.
>>
>> Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
>> ---
>> drivers/video/omap2/dss/dispc.c | 433 +++++++++++++++++++++++++--------------
>> 1 file changed, 278 insertions(+), 155 deletions(-)
>>
>> diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
>> index ff52702..3fad33a 100644
>> --- a/drivers/video/omap2/dss/dispc.c
>> +++ b/drivers/video/omap2/dss/dispc.c
>> @@ -81,6 +81,23 @@ struct dispc_irq_stats {
>> unsigned irqs[32];
>> };
>>
>> +struct dispc_features {
>> + int hp_max;
>> + int vp_max;
>> + int sw_max;
>> + int sw_start;
>> + int fp_start;
>> + int bp_start;
>
> Here you could use a bit smaller datatype. u16 should probably be more
> than enough.
>
After looking at the values that these variables take I think hp_max,
vp_max and sw_max can be u16 and the rest three sw_start, fp_start and
bp_start can be u8.
>> +static int __init dispc_init_features(struct device *dev)
>> +{
>> + struct dispc_features *feat = devm_kzalloc(dev, sizeof(*feat),
>> + GFP_KERNEL);
>> + if (!feat) {
>> + dev_err(dev, "Failed to allocate DISPC Features\n");
>> + return -ENOMEM;
>> + }
>> +
>> + if (cpu_is_omap24xx()) {
>> + memcpy(feat, &omap24xx_dispc_feats, sizeof(*feat));
>> + } else if (cpu_is_omap34xx()) {
>> + if (omap_rev() < OMAP3430_REV_ES3_0)
>> + memcpy(feat, &omap34xx_rev1_0_dispc_feats,
>> + sizeof(*feat));
>> + else
>> + memcpy(feat, &omap34xx_rev3_0_dispc_feats,
>> + sizeof(*feat));
>> + } else if (cpu_is_omap44xx()) {
>> + memcpy(feat, &omap44xx_dispc_feats, sizeof(*feat));
>> + } else {
>> + return -ENODEV;
>> + }
>> +
>> + dispc.feat = feat;
>> +
>> + return 0;
>> +}
>
> This becomes much cleaner with something like the following (same could
> be used in dss.c also):
>
> const struct dispc_features *src;
> struct dispc_features *dst;
>
> dst = devm_kzalloc(dev, sizeof(*dst), GFP_KERNEL);
> if (!dsst) {
> dev_err(dev, "Failed to allocate DISPC Features\n");
> return -ENOMEM;
> }
>
> if (cpu_is_omap24xx()) {
> src = &omap24xx_dispc_feats;
> } else if (cpu_is_omap34xx()) {
> if (omap_rev() < OMAP3430_REV_ES3_0)
> src = &omap34xx_rev1_0_dispc_feats;
> else
> src = &omap34xx_rev3_0_dispc_feats;
> } else if (cpu_is_omap44xx()) {
> src = &omap44xx_dispc_feats;
> } else {
> return -ENODEV;
> }
>
> memcpy(dst, src, sizeof(*dst));
>
> dispc.feat = dst;
>
> Tomi
>
ok, looks cleaner.
--
Chandrabhanu Mahapatra
Texas Instruments India Pvt. Ltd.
^ permalink raw reply
* Re: [PATCH V5 5/6] ARM: OMAP: Disable venc for OMAP4
From: Mahapatra, Chandrabhanu @ 2012-08-21 11:25 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: tony, paul, linux-omap, linux-fbdev
In-Reply-To: <1345545159.4085.45.camel@deskari>
On Tue, Aug 21, 2012 at 4:02 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On Mon, 2012-08-20 at 18:54 +0530, Chandrabhanu Mahapatra wrote:
>> This is a alternative to "HACK: OMAP: DSS2: VENC: disable VENC on OMAP4 to
>> prevent crash" (ba02fa37de) by Tomi Valkeinen <tomi.valkeinen@ti.com> to prevent
>> VENC from crashing OMAP4 kernel. This prevents OMAPDSS from initial registration
>> of a device for VENC on OMAP4.
>>
>> Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
>> ---
>> arch/arm/mach-omap2/display.c | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
>> index af1ed7d..ee40739 100644
>> --- a/arch/arm/mach-omap2/display.c
>> +++ b/arch/arm/mach-omap2/display.c
>> @@ -95,7 +95,6 @@ static const struct omap_dss_hwmod_data omap4_dss_hwmod_data[] __initdata = {
>> { "dss_core", "omapdss_dss", -1 },
>> { "dss_dispc", "omapdss_dispc", -1 },
>> { "dss_rfbi", "omapdss_rfbi", -1 },
>> - { "dss_venc", "omapdss_venc", -1 },
>> { "dss_dsi1", "omapdss_dsi", 0 },
>> { "dss_dsi2", "omapdss_dsi", 1 },
>> { "dss_hdmi", "omapdss_hdmi", -1 },
>
> You need to reorder this and the previous patch. If you first remove the
> workaround from the previous patch, the kernel will crash if after that
> patch. So this one should be before the previous patch.
>
> Tomi
>
Ok.
--
Chandrabhanu Mahapatra
Texas Instruments India Pvt. Ltd.
^ permalink raw reply
* Re: [PATCH V5 3/6] OMAPDSS: DSS: Cleanup cpu_is_xxxx checks
From: Tomi Valkeinen @ 2012-08-21 11:20 UTC (permalink / raw)
To: Mahapatra, Chandrabhanu; +Cc: linux-omap, linux-fbdev
In-Reply-To: <CAF0AtAtvyKdW-J97NJ+YNi5pUGQFyxk=B2Eqn_74MZD4dWebEA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1867 bytes --]
On Tue, 2012-08-21 at 16:36 +0530, Mahapatra, Chandrabhanu wrote:
> On Tue, Aug 21, 2012 at 4:05 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > On Mon, 2012-08-20 at 18:53 +0530, Chandrabhanu Mahapatra wrote:
> >> All the cpu_is checks have been moved to dss_init_features function providing a
> >> much more generic and cleaner interface. The OMAP version and revision specific
> >> initializations in various functions are cleaned and the necessary data are
> >> moved to dss_features structure which is local to dss.c.
> >>
> >> Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
> >> ---
> >> drivers/video/omap2/dss/dss.c | 117 ++++++++++++++++++++++++++---------------
> >> 1 file changed, 76 insertions(+), 41 deletions(-)
> >>
> >> diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
> >> index 10566ae..f6d3d0a 100644
> >> --- a/drivers/video/omap2/dss/dss.c
> >> +++ b/drivers/video/omap2/dss/dss.c
> >> @@ -31,6 +31,7 @@
> >> #include <linux/clk.h>
> >> #include <linux/platform_device.h>
> >> #include <linux/pm_runtime.h>
> >> +#include <linux/gfp.h>
> >>
> >> #include <video/omapdss.h>
> >>
> >> @@ -65,6 +66,12 @@ struct dss_reg {
> >> static int dss_runtime_get(void);
> >> static void dss_runtime_put(void);
> >>
> >> +struct dss_features {
> >> + u16 fck_div_max;
> >> + int dss_fck_multiplier;
> >> + char *clk_name;
> >
> > const char *
> >
> > Tomi
> >
>
> All the values are const. So we have a const pointer dss.feat to hold
> this structure. Is a separate
> const char *clk_name required?
Yes, the values are const, so the pointer itself is const. However, the
chars where the pointer points are not const. So:
feat.clk_name = 1234; // this is rejected by the compiler
feat.clk_name[0] = 0; // this would be accepted
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH V5 3/6] OMAPDSS: DSS: Cleanup cpu_is_xxxx checks
From: Mahapatra, Chandrabhanu @ 2012-08-21 11:18 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1345545312.4085.46.camel@deskari>
On Tue, Aug 21, 2012 at 4:05 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On Mon, 2012-08-20 at 18:53 +0530, Chandrabhanu Mahapatra wrote:
>> All the cpu_is checks have been moved to dss_init_features function providing a
>> much more generic and cleaner interface. The OMAP version and revision specific
>> initializations in various functions are cleaned and the necessary data are
>> moved to dss_features structure which is local to dss.c.
>>
>> Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
>> ---
>> drivers/video/omap2/dss/dss.c | 117 ++++++++++++++++++++++++++---------------
>> 1 file changed, 76 insertions(+), 41 deletions(-)
>>
>> diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
>> index 10566ae..f6d3d0a 100644
>> --- a/drivers/video/omap2/dss/dss.c
>> +++ b/drivers/video/omap2/dss/dss.c
>> @@ -31,6 +31,7 @@
>> #include <linux/clk.h>
>> #include <linux/platform_device.h>
>> #include <linux/pm_runtime.h>
>> +#include <linux/gfp.h>
>>
>> #include <video/omapdss.h>
>>
>> @@ -65,6 +66,12 @@ struct dss_reg {
>> static int dss_runtime_get(void);
>> static void dss_runtime_put(void);
>>
>> +struct dss_features {
>> + u16 fck_div_max;
>> + int dss_fck_multiplier;
>> + char *clk_name;
>
> const char *
>
> Tomi
>
All the values are const. So we have a const pointer dss.feat to hold
this structure. Is a separate
const char *clk_name required?
--
Chandrabhanu Mahapatra
Texas Instruments India Pvt. Ltd.
^ permalink raw reply
* Re: [PATCH V5 3/6] OMAPDSS: DSS: Cleanup cpu_is_xxxx checks
From: Tomi Valkeinen @ 2012-08-21 10:35 UTC (permalink / raw)
To: Chandrabhanu Mahapatra; +Cc: linux-omap, linux-fbdev
In-Reply-To: <94a123bbc0a4ecd48fc71275fd5efbe0aac93b87.1345468541.git.cmahapatra@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1208 bytes --]
On Mon, 2012-08-20 at 18:53 +0530, Chandrabhanu Mahapatra wrote:
> All the cpu_is checks have been moved to dss_init_features function providing a
> much more generic and cleaner interface. The OMAP version and revision specific
> initializations in various functions are cleaned and the necessary data are
> moved to dss_features structure which is local to dss.c.
>
> Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
> ---
> drivers/video/omap2/dss/dss.c | 117 ++++++++++++++++++++++++++---------------
> 1 file changed, 76 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
> index 10566ae..f6d3d0a 100644
> --- a/drivers/video/omap2/dss/dss.c
> +++ b/drivers/video/omap2/dss/dss.c
> @@ -31,6 +31,7 @@
> #include <linux/clk.h>
> #include <linux/platform_device.h>
> #include <linux/pm_runtime.h>
> +#include <linux/gfp.h>
>
> #include <video/omapdss.h>
>
> @@ -65,6 +66,12 @@ struct dss_reg {
> static int dss_runtime_get(void);
> static void dss_runtime_put(void);
>
> +struct dss_features {
> + u16 fck_div_max;
> + int dss_fck_multiplier;
> + char *clk_name;
const char *
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH V5 5/6] ARM: OMAP: Disable venc for OMAP4
From: Tomi Valkeinen @ 2012-08-21 10:32 UTC (permalink / raw)
To: Chandrabhanu Mahapatra; +Cc: tony, paul, linux-omap, linux-fbdev
In-Reply-To: <a07a3a216827e830cfa249f4f39ad26e75dc0afd.1345468541.git.cmahapatra@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1288 bytes --]
On Mon, 2012-08-20 at 18:54 +0530, Chandrabhanu Mahapatra wrote:
> This is a alternative to "HACK: OMAP: DSS2: VENC: disable VENC on OMAP4 to
> prevent crash" (ba02fa37de) by Tomi Valkeinen <tomi.valkeinen@ti.com> to prevent
> VENC from crashing OMAP4 kernel. This prevents OMAPDSS from initial registration
> of a device for VENC on OMAP4.
>
> Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
> ---
> arch/arm/mach-omap2/display.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
> index af1ed7d..ee40739 100644
> --- a/arch/arm/mach-omap2/display.c
> +++ b/arch/arm/mach-omap2/display.c
> @@ -95,7 +95,6 @@ static const struct omap_dss_hwmod_data omap4_dss_hwmod_data[] __initdata = {
> { "dss_core", "omapdss_dss", -1 },
> { "dss_dispc", "omapdss_dispc", -1 },
> { "dss_rfbi", "omapdss_rfbi", -1 },
> - { "dss_venc", "omapdss_venc", -1 },
> { "dss_dsi1", "omapdss_dsi", 0 },
> { "dss_dsi2", "omapdss_dsi", 1 },
> { "dss_hdmi", "omapdss_hdmi", -1 },
You need to reorder this and the previous patch. If you first remove the
workaround from the previous patch, the kernel will crash if after that
patch. So this one should be before the previous patch.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH V5 1/6] OMAPDSS: DISPC: cleanup cpu_is_xxxx checks
From: Tomi Valkeinen @ 2012-08-21 10:31 UTC (permalink / raw)
To: Chandrabhanu Mahapatra; +Cc: linux-omap, linux-fbdev
In-Reply-To: <978118e2c23e2da40ceb740665fd19f86810b58a.1345468541.git.cmahapatra@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2558 bytes --]
On Mon, 2012-08-20 at 18:52 +0530, Chandrabhanu Mahapatra wrote:
> All the cpu_is checks have been moved to dispc_init_features function providing
> a much more generic and cleaner interface. The OMAP version and revision
> specific functions and data are initialized by dispc_features structure which is
> local to dispc.c.
>
> Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
> ---
> drivers/video/omap2/dss/dispc.c | 433 +++++++++++++++++++++++++--------------
> 1 file changed, 278 insertions(+), 155 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
> index ff52702..3fad33a 100644
> --- a/drivers/video/omap2/dss/dispc.c
> +++ b/drivers/video/omap2/dss/dispc.c
> @@ -81,6 +81,23 @@ struct dispc_irq_stats {
> unsigned irqs[32];
> };
>
> +struct dispc_features {
> + int hp_max;
> + int vp_max;
> + int sw_max;
> + int sw_start;
> + int fp_start;
> + int bp_start;
Here you could use a bit smaller datatype. u16 should probably be more
than enough.
> +static int __init dispc_init_features(struct device *dev)
> +{
> + struct dispc_features *feat = devm_kzalloc(dev, sizeof(*feat),
> + GFP_KERNEL);
> + if (!feat) {
> + dev_err(dev, "Failed to allocate DISPC Features\n");
> + return -ENOMEM;
> + }
> +
> + if (cpu_is_omap24xx()) {
> + memcpy(feat, &omap24xx_dispc_feats, sizeof(*feat));
> + } else if (cpu_is_omap34xx()) {
> + if (omap_rev() < OMAP3430_REV_ES3_0)
> + memcpy(feat, &omap34xx_rev1_0_dispc_feats,
> + sizeof(*feat));
> + else
> + memcpy(feat, &omap34xx_rev3_0_dispc_feats,
> + sizeof(*feat));
> + } else if (cpu_is_omap44xx()) {
> + memcpy(feat, &omap44xx_dispc_feats, sizeof(*feat));
> + } else {
> + return -ENODEV;
> + }
> +
> + dispc.feat = feat;
> +
> + return 0;
> +}
This becomes much cleaner with something like the following (same could
be used in dss.c also):
const struct dispc_features *src;
struct dispc_features *dst;
dst = devm_kzalloc(dev, sizeof(*dst), GFP_KERNEL);
if (!dsst) {
dev_err(dev, "Failed to allocate DISPC Features\n");
return -ENOMEM;
}
if (cpu_is_omap24xx()) {
src = &omap24xx_dispc_feats;
} else if (cpu_is_omap34xx()) {
if (omap_rev() < OMAP3430_REV_ES3_0)
src = &omap34xx_rev1_0_dispc_feats;
else
src = &omap34xx_rev3_0_dispc_feats;
} else if (cpu_is_omap44xx()) {
src = &omap44xx_dispc_feats;
} else {
return -ENODEV;
}
memcpy(dst, src, sizeof(*dst));
dispc.feat = dst;
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v4 1/3] Runtime Interpreted Power Sequences
From: Tomi Valkeinen @ 2012-08-21 9:54 UTC (permalink / raw)
To: Thierry Reding
Cc: Alex Courbot, Stephen Warren, Simon Glass, Grant Likely,
Rob Herring, Mark Brown, Anton Vorontsov, David Woodhouse,
Arnd Bergmann, Leela Krishna Amudala,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20120821091306.GA4819-RM9K5IK7kjIQXX3q8xo1gnVAuStQJXxyR5q1nwbD4aMs9pC9oP6+/A@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2466 bytes --]
On Tue, 2012-08-21 at 11:13 +0200, Thierry Reding wrote:
> On Tue, Aug 21, 2012 at 11:57:45AM +0300, Tomi Valkeinen wrote:
> > This doesn't mean that we'd have a separate driver for each device. For
> > example, we have a generic panel driver in OMAP, which contains a kind
> > of small panel database. The panel database contains the name of the
> > panel as a key, and panel specific configuration as a value. This
> > configuration could also contain some kind of generic power sequence.
>
> I see. I do like the idea of it, because it is more straightforward than
> representing the whole sequence in DT. Matching could be done using the
> standard compatible property.
Right.
> However this also means we'll essentially just be moving the board code.
What do you mean "just"? Wasn't the point of the whole "arm board file
mess" to get rid of the code from the board files? If the code in the
board file is device specific code, not board specific, then the driver
of the device is a logical place to place it.
And as I said, I don't have any problems with some kind of generic power
sequences. So the code in the board file could be moved and converted to
use the power sequences, if that is better than just plain c code.
> Being in a central location it would be easier to refactor commonalities
> though.
>
> > I'd like to require the board developer to only fill in to the DT data
> > what panel he is using, and how it's connected on his board. Not panel's
> > internal functionality.
>
> The amount of work required by the board developer would largely depend
> on whether support for the panel is already present or not. For new
> panels this would mean that a new driver needs to be written, while
> representing the power sequence in DT might be easier to do, and readily
> available from some datasheet.
That's true.
However, if we already have a generic driver for that type of panel,
(which we would need anyway for the DT based approach), the developer
only needs to add the name of the panel and the data for the power
sequence to the panel driver's database, which is about the same amount
of work as with DT.
So it's really just a question of where to put the data in question, DT
or driver. Both contain the same data, and the data structure may also
be the same. In DT's case it just needs to be parsed first, whereas in
database case you'll enter the data in structs.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [RFC 0/5] Generic panel framework
From: Laurent Pinchart @ 2012-08-21 9:23 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-fbdev, dri-devel, linux-leds, linux-media, Bryan Wu,
Richard Purdie, Marcus Lorentzon, Sumit Semwal, Archit Taneja,
Sebastien Guiriec, Inki Dae, Kyungmin Park
In-Reply-To: <1345528197.15491.8.camel@lappyti>
Hi Tomi,
On Tuesday 21 August 2012 08:49:57 Tomi Valkeinen wrote:
> On Tue, 2012-08-21 at 01:29 +0200, Laurent Pinchart wrote:
> > On Monday 20 August 2012 14:39:30 Tomi Valkeinen wrote:
> > > On Sat, 2012-08-18 at 03:16 +0200, Laurent Pinchart wrote:
> > > > Hi Tomi,
> > > >
> > > > mipi-dbi-bus might not belong to include/video/panel/ though, as it
> > > > can be used for non-panel devices (at least in theory). The future
> > > > mipi-dsi-bus certainly will.
> > >
> > > They are both display busses. So while they could be used for anything,
> > > I find it quite unlikely as there are much better alternatives for
> > > generic bus needs.
> >
> > My point is that they could be used for display devices other than panels.
> > This is especially true for DSI, as there are DSI to HDMI converters.
> > Technically speaking that's also true for DBI, as DBI chips convert from
> > DBI to DPI, but we can group both the DBI-to-DPI chip and the panel in a
> > single panel object.
>
> Ah, ok. I thought "panels" would include these buffer/converter chips.
>
> I think we should have one driver for one indivisible hardware entity.
> So if you've got a panel module that contains DBI receiver, buffer
> memory and a DPI panel, let's just have one "DBI panel" driver for it.
>
> If we get lots of different panel modules containing the same DBI RX IP,
> we could have the DBI IP part as a common library, but still have one
> panel driver per panel module.
Sounds good to me.
> But how do you see the case for separate converter/buffer chips? Are
> they part of the generic panel framework? I guess they kinda have to be.
> On one side they use the "panel" API control the bus they are connected
> to, and on the other they offer an API for the connected panel to use
> the bus they provide.
The DBI/DSI APIs will not be panel-specific (they won't contain any reference
to "panel") I'm thus thinking of moving them from drivers/video/panel/ to
drivers/video/.
Furthermore, a DSI-to-HDMI converter chip is not a panel, but needs to expose
display-related operations in a way similar to panels. I was thus wondering if
we shouldn't replace the panel structure with some kind of video entity
structure that would expose operations similar to panels. We could then extend
that structure with converter-specific operations later. The framework would
become a bit more generic, while remaining display-specific.
> Did you just mean we should have a separate directory for them, while
> still part of the same framework, or...?
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH] fbcon: fix race condition between console lock and cursor timer
From: Alan Cox @ 2012-08-21 9:15 UTC (permalink / raw)
To: Dave Airlie
Cc: linux-fbdev, dri-devel, linux-kernel, Linus, Randy Dunlap,
Josh Boyer
In-Reply-To: <1345531207-24926-1-git-send-email-airlied@redhat.com>
> So after much tracing with direct netconsole writes (printks
> under console_lock not so useful), I think I found the race.
Direct netconsole write would be a useful patch to have mainline I think
8)
> Hopefully this fixes the problem for anyone seeing vesafb->kms
> driver handoff.
Not really the proper fix but its clear and is probably the best thing to
go in initially with a cc: stable. Can you at least stick a large
+ /* FIXME: we should sort out the unbind locking instead */
on the patch however.
^ permalink raw reply
* Re: [PATCH v4 1/3] Runtime Interpreted Power Sequences
From: Thierry Reding @ 2012-08-21 9:13 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Alex Courbot, Stephen Warren, Simon Glass, Grant Likely,
Rob Herring, Mark Brown, Anton Vorontsov, David Woodhouse,
Arnd Bergmann, Leela Krishna Amudala, linux-tegra@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-fbdev@vger.kernel.org,
devicetree-discuss@lists.ozlabs.org, linux-doc@vger.kernel.org
In-Reply-To: <1345539465.4085.22.camel@deskari>
[-- Attachment #1: Type: text/plain, Size: 2921 bytes --]
On Tue, Aug 21, 2012 at 11:57:45AM +0300, Tomi Valkeinen wrote:
> On Tue, 2012-08-21 at 10:33 +0200, Thierry Reding wrote:
>
> > I suppose power sequences aren't needed if you have a specific driver
> > for every panel out there. However that also means that you'd have to
> > write drivers for literally every panel that requires support. In the
> > end this will just result in discussion down the road how the common
> > functionality can be refactored and we may end up with power sequences
> > again.
> >
> > Also as you mentioned, power sequences are useful for a number of other
> > use-cases. Without power sequences you'll have to potentially create
> > extra frameworks tha reimplement parts of the power sequence code for
> > their specific hardware needs.
>
> Right. I think my main concern is the use of DT data, not power
> sequences as such. I've been going back and forth in my mind with this
> issue with OMAP also.
>
> The question is: what stuff belongs to DT data and what belongs to the
> kernel? I've been trying to go to the direction where DT is used to
> describe the HW connections of different IP blocks and to pass board
> specific configuration. Everything else is in the driver.
>
> This doesn't mean that we'd have a separate driver for each device. For
> example, we have a generic panel driver in OMAP, which contains a kind
> of small panel database. The panel database contains the name of the
> panel as a key, and panel specific configuration as a value. This
> configuration could also contain some kind of generic power sequence.
I see. I do like the idea of it, because it is more straightforward than
representing the whole sequence in DT. Matching could be done using the
standard compatible property.
However this also means we'll essentially just be moving the board code.
Being in a central location it would be easier to refactor commonalities
though.
> I'd like to require the board developer to only fill in to the DT data
> what panel he is using, and how it's connected on his board. Not panel's
> internal functionality.
The amount of work required by the board developer would largely depend
on whether support for the panel is already present or not. For new
panels this would mean that a new driver needs to be written, while
representing the power sequence in DT might be easier to do, and readily
available from some datasheet.
> The one benefit I see with DT based approach is that if we have, say,
> 10000 panels, we'd have quite a big database in kernel memory and a
> board may only need one or two of those. But perhaps that could be
> helped with the use of __initdata.
I haven't worked with many different panels, so maybe I can't judge this
too well, but if panel drivers were kept in a central location, then the
number can be reduced by generalizing parts of existing drivers.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v4 1/3] Runtime Interpreted Power Sequences
From: Tomi Valkeinen @ 2012-08-21 8:57 UTC (permalink / raw)
To: Thierry Reding
Cc: Alex Courbot, Stephen Warren, Simon Glass, Grant Likely,
Rob Herring, Mark Brown, Anton Vorontsov, David Woodhouse,
Arnd Bergmann, Leela Krishna Amudala, linux-tegra@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-fbdev@vger.kernel.org,
devicetree-discuss@lists.ozlabs.org, linux-doc@vger.kernel.org
In-Reply-To: <20120821083329.GA28992@avionic-0098.adnet.avionic-design.de>
[-- Attachment #1: Type: text/plain, Size: 1912 bytes --]
On Tue, 2012-08-21 at 10:33 +0200, Thierry Reding wrote:
> I suppose power sequences aren't needed if you have a specific driver
> for every panel out there. However that also means that you'd have to
> write drivers for literally every panel that requires support. In the
> end this will just result in discussion down the road how the common
> functionality can be refactored and we may end up with power sequences
> again.
>
> Also as you mentioned, power sequences are useful for a number of other
> use-cases. Without power sequences you'll have to potentially create
> extra frameworks tha reimplement parts of the power sequence code for
> their specific hardware needs.
Right. I think my main concern is the use of DT data, not power
sequences as such. I've been going back and forth in my mind with this
issue with OMAP also.
The question is: what stuff belongs to DT data and what belongs to the
kernel? I've been trying to go to the direction where DT is used to
describe the HW connections of different IP blocks and to pass board
specific configuration. Everything else is in the driver.
This doesn't mean that we'd have a separate driver for each device. For
example, we have a generic panel driver in OMAP, which contains a kind
of small panel database. The panel database contains the name of the
panel as a key, and panel specific configuration as a value. This
configuration could also contain some kind of generic power sequence.
I'd like to require the board developer to only fill in to the DT data
what panel he is using, and how it's connected on his board. Not panel's
internal functionality.
The one benefit I see with DT based approach is that if we have, say,
10000 panels, we'd have quite a big database in kernel memory and a
board may only need one or two of those. But perhaps that could be
helped with the use of __initdata.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v4 1/3] Runtime Interpreted Power Sequences
From: Alex Courbot @ 2012-08-21 8:53 UTC (permalink / raw)
To: Thierry Reding
Cc: Tomi Valkeinen, Stephen Warren, Simon Glass, Grant Likely,
Rob Herring, Mark Brown, Anton Vorontsov, David Woodhouse,
Arnd Bergmann, Leela Krishna Amudala, linux-tegra@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-fbdev@vger.kernel.org,
devicetree-discuss@lists.ozlabs.org, linux-doc@vger.kernel.org
In-Reply-To: <20120821083329.GA28992@avionic-0098.adnet.avionic-design.de>
On Tuesday 21 August 2012 16:33:30 Thierry Reding wrote:
> I suppose power sequences aren't needed if you have a specific driver
> for every panel out there. However that also means that you'd have to
> write drivers for literally every panel that requires support. In the
> end this will just result in discussion down the road how the common
> functionality can be refactored and we may end up with power sequences
> again.
>
> Also as you mentioned, power sequences are useful for a number of other
> use-cases. Without power sequences you'll have to potentially create
> extra frameworks tha reimplement parts of the power sequence code for
> their specific hardware needs.
Yes, I can imagine what a mess it would become it we had one driver for every
panel out there which sole purpose would be to define power sequences over more
generic drivers. That reassures me about the usefulness of this work.
Another (small) benefit of power sequences over specific drivers is that being
defined in the DT, they would allow an old kernel to operate a newer device if
the base driver is the same.
Alex.
^ permalink raw reply
* Re: [PATCH v4 1/3] Runtime Interpreted Power Sequences
From: Thierry Reding @ 2012-08-21 8:33 UTC (permalink / raw)
To: Alex Courbot
Cc: Tomi Valkeinen, Stephen Warren, Simon Glass, Grant Likely,
Rob Herring, Mark Brown, Anton Vorontsov, David Woodhouse,
Arnd Bergmann, Leela Krishna Amudala, linux-tegra@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-fbdev@vger.kernel.org,
devicetree-discuss@lists.ozlabs.org, linux-doc@vger.kernel.org
In-Reply-To: <1562509.b0FYTUZ1D8@percival>
[-- Attachment #1: Type: text/plain, Size: 3880 bytes --]
On Tue, Aug 21, 2012 at 05:22:12PM +0900, Alex Courbot wrote:
> Hi Tomi,
>
> On Tuesday 21 August 2012 15:44:29 Tomi Valkeinen wrote:
> > > +Problem
> > > +-------
> > > +One very common board-dependent code is the out-of-driver code that is
> > > used to +turn a device on or off. For instance, SoC boards very commonly
> > > use a GPIO +(abstracted to a regulator or not) to control the power
> > > supply of a backlight, +disabling it when the backlight is not used in
> > > order to save power. The GPIO +that should be used, however, as well as
> > > the exact power sequence that may +also involve other resources, is
> > > board-dependent and thus unknown of the driver. +
> > > +This was previously addressed by having hooks in the device's platform
> > > data that +are called whenever the state of the device might reflect a
> > > power change. This +approach, however, introduces board-dependant code
> > > into the kernel and is not +compatible with the device tree.
> >
> > I've been having the same problems on OMAP display related code, but the
> > problem has always been fixable by just having the driver to use a
> > common framework to do the job (a framework which may not have existed
> > at the time). The problems have never been board specific in the end,
> > but device specific.
> >
> > Can you describe your particular HW problem a bit more? In the backlight
> > case, what exactly requires the delays and the sequence you show in the
> > example to enable/disable the backlight?
>
> In the example, the sequence (including delays) is clearly stated by the
> backlight specification, which is part of the panel specification. The backlight
> uses a PWM, which makes it suitable to use the generic PWM backlight driver,
> but how to turn the backlight on and off is very backlight specific. The power
> sequences allow to replace the board-specific backlight callbacks by sequences
> in the DT.
>
> On the other hand, I saw your discussion with Laurent about the panel
> framework, and I wonder how this would fit into it. Backlights are typically
> embedded within panels. Power sequences are a good way to deal with the
> absence of specific drivers for every panels, since they allow to tailor the
> behavior of generic drivers to fit particular needs. But if every panel comes
> with its own driver (which would define the backlight device using the most
> appropriate driver), then it could just as well perform its backlight's
> sequences via regular callbacks. In this particular case, there would be no
> need for power sequences.
>
> Power sequences are supposed to go beyond backlight drivers and support all
> sort of devices (I have heard that it could be useful for modems as well), but
> I wonder how relevant they are when there is a proper driver for a device. I
> hate to question my own work but now I cannot help but think that a proper
> driver could do the same job. So what are we trying to achieve with power
> sequences? Are we trying to avoid a drivers' explosion by keeping some of the
> specifics out of them? Which approach would be preferable? Are there cases
> where a dedicated driver could not replace power sequences?
I suppose power sequences aren't needed if you have a specific driver
for every panel out there. However that also means that you'd have to
write drivers for literally every panel that requires support. In the
end this will just result in discussion down the road how the common
functionality can be refactored and we may end up with power sequences
again.
Also as you mentioned, power sequences are useful for a number of other
use-cases. Without power sequences you'll have to potentially create
extra frameworks tha reimplement parts of the power sequence code for
their specific hardware needs.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v4 1/3] Runtime Interpreted Power Sequences
From: Alex Courbot @ 2012-08-21 8:22 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Stephen Warren, Thierry Reding, Simon Glass, Grant Likely,
Rob Herring, Mark Brown, Anton Vorontsov, David Woodhouse,
Arnd Bergmann, Leela Krishna Amudala, linux-tegra@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-fbdev@vger.kernel.org,
devicetree-discuss@lists.ozlabs.org, linux-doc@vger.kernel.org
In-Reply-To: <1345535069.4085.7.camel@deskari>
Hi Tomi,
On Tuesday 21 August 2012 15:44:29 Tomi Valkeinen wrote:
> > +Problem
> > +-------
> > +One very common board-dependent code is the out-of-driver code that is
> > used to +turn a device on or off. For instance, SoC boards very commonly
> > use a GPIO +(abstracted to a regulator or not) to control the power
> > supply of a backlight, +disabling it when the backlight is not used in
> > order to save power. The GPIO +that should be used, however, as well as
> > the exact power sequence that may +also involve other resources, is
> > board-dependent and thus unknown of the driver. +
> > +This was previously addressed by having hooks in the device's platform
> > data that +are called whenever the state of the device might reflect a
> > power change. This +approach, however, introduces board-dependant code
> > into the kernel and is not +compatible with the device tree.
>
> I've been having the same problems on OMAP display related code, but the
> problem has always been fixable by just having the driver to use a
> common framework to do the job (a framework which may not have existed
> at the time). The problems have never been board specific in the end,
> but device specific.
>
> Can you describe your particular HW problem a bit more? In the backlight
> case, what exactly requires the delays and the sequence you show in the
> example to enable/disable the backlight?
In the example, the sequence (including delays) is clearly stated by the
backlight specification, which is part of the panel specification. The backlight
uses a PWM, which makes it suitable to use the generic PWM backlight driver,
but how to turn the backlight on and off is very backlight specific. The power
sequences allow to replace the board-specific backlight callbacks by sequences
in the DT.
On the other hand, I saw your discussion with Laurent about the panel
framework, and I wonder how this would fit into it. Backlights are typically
embedded within panels. Power sequences are a good way to deal with the
absence of specific drivers for every panels, since they allow to tailor the
behavior of generic drivers to fit particular needs. But if every panel comes
with its own driver (which would define the backlight device using the most
appropriate driver), then it could just as well perform its backlight's
sequences via regular callbacks. In this particular case, there would be no
need for power sequences.
Power sequences are supposed to go beyond backlight drivers and support all
sort of devices (I have heard that it could be useful for modems as well), but
I wonder how relevant they are when there is a proper driver for a device. I
hate to question my own work but now I cannot help but think that a proper
driver could do the same job. So what are we trying to achieve with power
sequences? Are we trying to avoid a drivers' explosion by keeping some of the
specifics out of them? Which approach would be preferable? Are there cases
where a dedicated driver could not replace power sequences?
Alex.
^ permalink raw reply
* Re: [PATCH v4 1/3] Runtime Interpreted Power Sequences
From: Tomi Valkeinen @ 2012-08-21 7:44 UTC (permalink / raw)
To: Alexandre Courbot
Cc: Stephen Warren, Thierry Reding, Simon Glass, Grant Likely,
Rob Herring, Mark Brown, Anton Vorontsov, David Woodhouse,
Arnd Bergmann, Leela Krishna Amudala,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-doc-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1345097337-24170-2-git-send-email-acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1387 bytes --]
Hi,
On Thu, 2012-08-16 at 15:08 +0900, Alexandre Courbot wrote:
> +Problem
> +-------
> +One very common board-dependent code is the out-of-driver code that is used to
> +turn a device on or off. For instance, SoC boards very commonly use a GPIO
> +(abstracted to a regulator or not) to control the power supply of a backlight,
> +disabling it when the backlight is not used in order to save power. The GPIO
> +that should be used, however, as well as the exact power sequence that may
> +also involve other resources, is board-dependent and thus unknown of the driver.
> +
> +This was previously addressed by having hooks in the device's platform data that
> +are called whenever the state of the device might reflect a power change. This
> +approach, however, introduces board-dependant code into the kernel and is not
> +compatible with the device tree.
I've been having the same problems on OMAP display related code, but the
problem has always been fixable by just having the driver to use a
common framework to do the job (a framework which may not have existed
at the time). The problems have never been board specific in the end,
but device specific.
Can you describe your particular HW problem a bit more? In the backlight
case, what exactly requires the delays and the sequence you show in the
example to enable/disable the backlight?
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH] fbcon: fix race condition between console lock and cursor timer
From: Dave Airlie @ 2012-08-21 6:40 UTC (permalink / raw)
To: linux-fbdev
Cc: dri-devel, linux-kernel, Linus, Alan Cox, Randy Dunlap,
Josh Boyer, Dave Airlie
So we've had a fair few reports of fbcon handover breakage between
efi/vesafb and i915 surface recently, so I dedicated a couple of
days to finding the problem.
Essentially the last thing we saw was the conflicting framebuffer
message and that was all.
So after much tracing with direct netconsole writes (printks
under console_lock not so useful), I think I found the race.
Thread A (driver load) Thread B (timer thread)
unbind_con_driver -> |
bind_con_driver -> |
vc->vc_sw->con_deinit -> |
fbcon_deinit -> |
console_lock() |
| |
| fbcon_flashcursor timer fires
| console_lock() <- blocked for A
|
|
fbcon_del_cursor_timer ->
del_timer_sync
(BOOM)
Of course because all of this is under the console lock,
we never see anything, also since we also just unbound the active
console guess what we never see anything.
Hopefully this fixes the problem for anyone seeing vesafb->kms
driver handoff.
Signed-off-by: David Airlie <airlied@redhat.com>
---
drivers/video/console/fbcon.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index 2e471c2..f8a79fc 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -372,8 +372,12 @@ static void fb_flashcursor(struct work_struct *work)
struct vc_data *vc = NULL;
int c;
int mode;
+ int ret;
+
+ ret = console_trylock();
+ if (ret = 0)
+ return;
- console_lock();
if (ops && ops->currcon != -1)
vc = vc_cons[ops->currcon].d;
--
1.7.10.2
^ permalink raw reply related
* [PATCH 23/23] OMAPDSS: Remove old way of setting manager and device links
From: Archit Taneja @ 2012-08-21 6:10 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, rob, sumit.semwal, Archit Taneja
In-Reply-To: <1345528711-27801-1-git-send-email-archit@ti.com>
Now that an omap_dss_output can be used to link between managers and devices, we
can remove the old way of setting manager and device links. This involves
removing the device and manager pointers from omap_overlay_manager and
omap_dss_device respectively, and removing the set_device/unset_device ops from
omap_overlay_manager.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/apply.c | 64 -------------------------------------
drivers/video/omap2/dss/manager.c | 2 --
include/video/omapdss.h | 5 ---
3 files changed, 71 deletions(-)
diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index d584f0c..0ae70ab 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -1247,70 +1247,6 @@ void dss_mgr_get_info(struct omap_overlay_manager *mgr,
spin_unlock_irqrestore(&data_lock, flags);
}
-int dss_mgr_set_device(struct omap_overlay_manager *mgr,
- struct omap_dss_device *dssdev)
-{
- int r;
-
- mutex_lock(&apply_lock);
-
- if (dssdev->manager) {
- DSSERR("display '%s' already has a manager '%s'\n",
- dssdev->name, dssdev->manager->name);
- r = -EINVAL;
- goto err;
- }
-
- if ((mgr->supported_displays & dssdev->type) = 0) {
- DSSERR("display '%s' does not support manager '%s'\n",
- dssdev->name, mgr->name);
- r = -EINVAL;
- goto err;
- }
-
- dssdev->manager = mgr;
- mgr->device = dssdev;
-
- mutex_unlock(&apply_lock);
-
- return 0;
-err:
- mutex_unlock(&apply_lock);
- return r;
-}
-
-int dss_mgr_unset_device(struct omap_overlay_manager *mgr)
-{
- int r;
-
- mutex_lock(&apply_lock);
-
- if (!mgr->device) {
- DSSERR("failed to unset display, display not set.\n");
- r = -EINVAL;
- goto err;
- }
-
- /*
- * Don't allow currently enabled displays to have the overlay manager
- * pulled out from underneath them
- */
- if (mgr->device->state != OMAP_DSS_DISPLAY_DISABLED) {
- r = -EINVAL;
- goto err;
- }
-
- mgr->device->manager = NULL;
- mgr->device = NULL;
-
- mutex_unlock(&apply_lock);
-
- return 0;
-err:
- mutex_unlock(&apply_lock);
- return r;
-}
-
int dss_mgr_set_output(struct omap_overlay_manager *mgr,
struct omap_dss_output *output)
{
diff --git a/drivers/video/omap2/dss/manager.c b/drivers/video/omap2/dss/manager.c
index d14ffc5..953f5ee 100644
--- a/drivers/video/omap2/dss/manager.c
+++ b/drivers/video/omap2/dss/manager.c
@@ -570,8 +570,6 @@ int dss_init_overlay_managers(struct platform_device *pdev)
break;
}
- mgr->set_device = &dss_mgr_set_device;
- mgr->unset_device = &dss_mgr_unset_device;
mgr->set_output = &dss_mgr_set_output;
mgr->unset_output = &dss_mgr_unset_output;
mgr->apply = &omap_dss_mgr_apply;
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index b3faea7..2be7629 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -466,7 +466,6 @@ struct omap_overlay_manager {
enum omap_dss_output_id supported_outputs;
/* dynamic fields */
- struct omap_dss_device *device;
struct omap_dss_output *output;
/*
@@ -480,9 +479,6 @@ struct omap_overlay_manager {
* interrupt context
*/
- int (*set_device)(struct omap_overlay_manager *mgr,
- struct omap_dss_device *dssdev);
- int (*unset_device)(struct omap_overlay_manager *mgr);
int (*set_output)(struct omap_overlay_manager *mgr,
struct omap_dss_output *output);
int (*unset_output)(struct omap_overlay_manager *mgr);
@@ -634,7 +630,6 @@ struct omap_dss_device {
enum omap_display_caps caps;
- struct omap_overlay_manager *manager;
struct omap_dss_output *output;
enum omap_dss_display_state state;
--
1.7.9.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox