* Re: [PATCH v4] drivers: video: use module_platform_driver_probe()
From: Fabio Porcedda @ 2013-04-02 10:08 UTC (permalink / raw)
To: linux-fbdev, linux-omap
Cc: Florian Tobias Schandinat, Tomi Valkeinen, David Howells,
Geert Uytterhoeven, Kuninori Morimoto
In-Reply-To: <1363352558-6275-1-git-send-email-fabio.porcedda@gmail.com>
On Fri, Mar 15, 2013 at 2:02 PM, Fabio Porcedda
<fabio.porcedda@gmail.com> wrote:
> This patch converts the drivers to use the
> module_platform_driver_probe() macro which makes the code smaller and
> a bit simpler.
>
> Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> # atmel_lcdfb.c
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: David Howells <dhowells@redhat.com>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> # amifb.c
> Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> ---
>
> Notes:
> v4:
> - add acked-by Nicolas & Laurent
> - fix amifb.c
> v3:
> - add missing drivers: amifb, atmel_lcdfb, vrfb
> - split patch set to each maintainer to easy up respin
> v2:
> - rebased over linux-next and remove already converted drivers
>
> drivers/video/amifb.c | 14 +-------------
> drivers/video/atmel_lcdfb.c | 13 +------------
> drivers/video/omap2/vrfb.c | 13 +------------
> drivers/video/sh_mipi_dsi.c | 12 +-----------
> drivers/video/sh_mobile_hdmi.c | 12 +-----------
> 5 files changed, 5 insertions(+), 59 deletions(-)
>
> diff --git a/drivers/video/amifb.c b/drivers/video/amifb.c
> index 7fa1bf8..77cb4ff 100644
> --- a/drivers/video/amifb.c
> +++ b/drivers/video/amifb.c
> @@ -3788,19 +3788,7 @@ static struct platform_driver amifb_driver = {
> },
> };
>
> -static int __init amifb_init(void)
> -{
> - return platform_driver_probe(&amifb_driver, amifb_probe);
> -}
> -
> -module_init(amifb_init);
> -
> -static void __exit amifb_exit(void)
> -{
> - platform_driver_unregister(&amifb_driver);
> -}
> -
> -module_exit(amifb_exit);
> +module_platform_driver_probe(amifb_driver, amifb_probe);
>
> MODULE_LICENSE("GPL");
> MODULE_ALIAS("platform:amiga-video");
> diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
> index 12cf5f3..654e102 100644
> --- a/drivers/video/atmel_lcdfb.c
> +++ b/drivers/video/atmel_lcdfb.c
> @@ -1150,18 +1150,7 @@ static struct platform_driver atmel_lcdfb_driver = {
> },
> };
>
> -static int __init atmel_lcdfb_init(void)
> -{
> - return platform_driver_probe(&atmel_lcdfb_driver, atmel_lcdfb_probe);
> -}
> -
> -static void __exit atmel_lcdfb_exit(void)
> -{
> - platform_driver_unregister(&atmel_lcdfb_driver);
> -}
> -
> -module_init(atmel_lcdfb_init);
> -module_exit(atmel_lcdfb_exit);
> +module_platform_driver_probe(atmel_lcdfb_driver, atmel_lcdfb_probe);
>
> MODULE_DESCRIPTION("AT91/AT32 LCD Controller framebuffer driver");
> MODULE_AUTHOR("Nicolas Ferre <nicolas.ferre@atmel.com>");
> diff --git a/drivers/video/omap2/vrfb.c b/drivers/video/omap2/vrfb.c
> index 10560ef..5261229 100644
> --- a/drivers/video/omap2/vrfb.c
> +++ b/drivers/video/omap2/vrfb.c
> @@ -397,18 +397,7 @@ static struct platform_driver vrfb_driver = {
> .remove = __exit_p(vrfb_remove),
> };
>
> -static int __init vrfb_init(void)
> -{
> - return platform_driver_probe(&vrfb_driver, &vrfb_probe);
> -}
> -
> -static void __exit vrfb_exit(void)
> -{
> - platform_driver_unregister(&vrfb_driver);
> -}
> -
> -module_init(vrfb_init);
> -module_exit(vrfb_exit);
> +module_platform_driver_probe(vrfb_driver, vrfb_probe);
>
> MODULE_AUTHOR("Tomi Valkeinen <tomi.valkeinen@ti.com>");
> MODULE_DESCRIPTION("OMAP VRFB");
> diff --git a/drivers/video/sh_mipi_dsi.c b/drivers/video/sh_mipi_dsi.c
> index 701b461..6cad530 100644
> --- a/drivers/video/sh_mipi_dsi.c
> +++ b/drivers/video/sh_mipi_dsi.c
> @@ -581,17 +581,7 @@ static struct platform_driver sh_mipi_driver = {
> },
> };
>
> -static int __init sh_mipi_init(void)
> -{
> - return platform_driver_probe(&sh_mipi_driver, sh_mipi_probe);
> -}
> -module_init(sh_mipi_init);
> -
> -static void __exit sh_mipi_exit(void)
> -{
> - platform_driver_unregister(&sh_mipi_driver);
> -}
> -module_exit(sh_mipi_exit);
> +module_platform_driver_probe(sh_mipi_driver, sh_mipi_probe);
>
> MODULE_AUTHOR("Guennadi Liakhovetski <g.liakhovetski@gmx.de>");
> MODULE_DESCRIPTION("SuperH / ARM-shmobile MIPI DSI driver");
> diff --git a/drivers/video/sh_mobile_hdmi.c b/drivers/video/sh_mobile_hdmi.c
> index 930e550..bfe4728 100644
> --- a/drivers/video/sh_mobile_hdmi.c
> +++ b/drivers/video/sh_mobile_hdmi.c
> @@ -1445,17 +1445,7 @@ static struct platform_driver sh_hdmi_driver = {
> },
> };
>
> -static int __init sh_hdmi_init(void)
> -{
> - return platform_driver_probe(&sh_hdmi_driver, sh_hdmi_probe);
> -}
> -module_init(sh_hdmi_init);
> -
> -static void __exit sh_hdmi_exit(void)
> -{
> - platform_driver_unregister(&sh_hdmi_driver);
> -}
> -module_exit(sh_hdmi_exit);
> +module_platform_driver_probe(sh_hdmi_driver, sh_hdmi_probe);
>
> MODULE_AUTHOR("Guennadi Liakhovetski <g.liakhovetski@gmx.de>");
> MODULE_DESCRIPTION("SuperH / ARM-shmobile HDMI driver");
> --
> 1.8.1.5
>
ping
Regards
--
Fabio Porcedda
^ permalink raw reply
* [PATCHv2 6/6] video: fb: vt8500: Convert framebuffer drivers to standardized binding
From: Tony Prisk @ 2013-04-02 4:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1364878200-26343-1-git-send-email-linux@prisktech.co.nz>
Now that a display timing binding is available, convert our almost identical
binding to use the standard binding.
This patch converts the vt8500 and wm8505 framebuffer drivers and
associated dts/dtsi files to use the standard binding as defined in
bindings/video/display-timing.txt.
There are two side-effects of making this conversion:
1) The fb node should now be in the board file, rather than the soc file as
the display-timing node is a child of the fb node.
2) We still require a bits per pixel property to initialize the framebuffer
for the different lcd panels. Rather than including this as part of the
display timing, it is moved into the framebuffer node.
I have also taken the opportunity to alphabetise the includes of each
driver to avoid double-ups.
Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
Reviewed-by: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
---
.../devicetree/bindings/video/via,vt8500-fb.txt | 48 ++++----------
.../devicetree/bindings/video/wm,wm8505-fb.txt | 32 ++++++----
arch/arm/boot/dts/vt8500-bv07.dts | 34 +++++-----
arch/arm/boot/dts/vt8500.dtsi | 4 +-
arch/arm/boot/dts/wm8505-ref.dts | 34 +++++-----
arch/arm/boot/dts/wm8505.dtsi | 4 +-
arch/arm/boot/dts/wm8650-mid.dts | 36 +++++------
arch/arm/boot/dts/wm8650.dtsi | 4 +-
arch/arm/boot/dts/wm8850-w70v2.dts | 40 ++++++------
arch/arm/boot/dts/wm8850.dtsi | 4 +-
drivers/video/Kconfig | 6 ++
drivers/video/vt8500lcdfb.c | 53 ++++++----------
drivers/video/wm8505fb.c | 67 ++++++++------------
13 files changed, 154 insertions(+), 212 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/via,vt8500-fb.txt b/Documentation/devicetree/bindings/video/via,vt8500-fb.txt
index c870b64..2871e21 100644
--- a/Documentation/devicetree/bindings/video/via,vt8500-fb.txt
+++ b/Documentation/devicetree/bindings/video/via,vt8500-fb.txt
@@ -5,58 +5,32 @@ Required properties:
- compatible : "via,vt8500-fb"
- reg : Should contain 1 register ranges(address and length)
- interrupts : framebuffer controller interrupt
-- display: a phandle pointing to the display node
+- bits-per-pixel : bit depth of framebuffer (16 or 32)
-Required nodes:
-- display: a display node is required to initialize the lcd panel
- This should be in the board dts.
-- default-mode: a videomode within the display with timing parameters
- as specified below.
+Required subnodes:
+- display-timings: see display-timing.txt for information
Example:
- fb@d800e400 {
+ fb@d8050800 {
compatible = "via,vt8500-fb";
reg = <0xd800e400 0x400>;
interrupts = <12>;
- display = <&display>;
- default-mode = <&mode0>;
- };
-
-VIA VT8500 Display
------------------------------------------------------
-Required properties (as per of_videomode_helper):
-
- - hactive, vactive: Display resolution
- - hfront-porch, hback-porch, hsync-len: Horizontal Display timing parameters
- in pixels
- vfront-porch, vback-porch, vsync-len: Vertical display timing parameters in
- lines
- - clock: displayclock in Hz
- - bpp: lcd panel bit-depth.
- <16> for RGB565, <32> for RGB888
-
-Optional properties (as per of_videomode_helper):
- - width-mm, height-mm: Display dimensions in mm
- - hsync-active-high (bool): Hsync pulse is active high
- - vsync-active-high (bool): Vsync pulse is active high
- - interlaced (bool): This is an interlaced mode
- - doublescan (bool): This is a doublescan mode
+ bits-per-pixel = <16>;
-Example:
- display: display@0 {
- modes {
- mode0: mode@0 {
+ display-timings {
+ native-mode = <&timing0>;
+ timing0: 800x480 {
+ clock-frequency = <0>; /* unused but required */
hactive = <800>;
vactive = <480>;
- hback-porch = <88>;
hfront-porch = <40>;
+ hback-porch = <88>;
hsync-len = <0>;
vback-porch = <32>;
vfront-porch = <11>;
vsync-len = <1>;
- clock = <0>; /* unused but required */
- bpp = <16>; /* non-standard but required */
};
};
};
+
diff --git a/Documentation/devicetree/bindings/video/wm,wm8505-fb.txt b/Documentation/devicetree/bindings/video/wm,wm8505-fb.txt
index 3d325e1..0bcadb2 100644
--- a/Documentation/devicetree/bindings/video/wm,wm8505-fb.txt
+++ b/Documentation/devicetree/bindings/video/wm,wm8505-fb.txt
@@ -4,20 +4,30 @@ Wondermedia WM8505 Framebuffer
Required properties:
- compatible : "wm,wm8505-fb"
- reg : Should contain 1 register ranges(address and length)
-- via,display: a phandle pointing to the display node
+- bits-per-pixel : bit depth of framebuffer (16 or 32)
-Required nodes:
-- display: a display node is required to initialize the lcd panel
- This should be in the board dts. See definition in
- Documentation/devicetree/bindings/video/via,vt8500-fb.txt
-- default-mode: a videomode node as specified in
- Documentation/devicetree/bindings/video/via,vt8500-fb.txt
+Required subnodes:
+- display-timings: see display-timing.txt for information
Example:
- fb@d8050800 {
+ fb@d8051700 {
compatible = "wm,wm8505-fb";
- reg = <0xd8050800 0x200>;
- display = <&display>;
- default-mode = <&mode0>;
+ reg = <0xd8051700 0x200>;
+ bits-per-pixel = <16>;
+
+ display-timings {
+ native-mode = <&timing0>;
+ timing0: 800x480 {
+ clock-frequency = <0>; /* unused but required */
+ hactive = <800>;
+ vactive = <480>;
+ hfront-porch = <40>;
+ hback-porch = <88>;
+ hsync-len = <0>;
+ vback-porch = <32>;
+ vfront-porch = <11>;
+ vsync-len = <1>;
+ };
+ };
};
diff --git a/arch/arm/boot/dts/vt8500-bv07.dts b/arch/arm/boot/dts/vt8500-bv07.dts
index 567cf4e..877b33a 100644
--- a/arch/arm/boot/dts/vt8500-bv07.dts
+++ b/arch/arm/boot/dts/vt8500-bv07.dts
@@ -11,26 +11,22 @@
/ {
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@0 {
- modes {
- mode0: mode@0 {
- hactive = <800>;
- vactive = <480>;
- hback-porch = <88>;
- hfront-porch = <40>;
- hsync-len = <0>;
- vback-porch = <32>;
- vfront-porch = <11>;
- vsync-len = <1>;
- clock = <0>; /* unused but required */
- bpp = <16>; /* non-standard but required */
- };
+&fb {
+ bits-per-pixel = <16>;
+ display-timings {
+ native-mode = <&timing0>;
+ timing0: 800x480 {
+ clock-frequency = <0>; /* unused but required */
+ hactive = <800>;
+ vactive = <480>;
+ hfront-porch = <40>;
+ hback-porch = <88>;
+ hsync-len = <0>;
+ vback-porch = <32>;
+ vfront-porch = <11>;
+ vsync-len = <1>;
};
};
};
diff --git a/arch/arm/boot/dts/vt8500.dtsi b/arch/arm/boot/dts/vt8500.dtsi
index cf31ced..68c8dc6 100644
--- a/arch/arm/boot/dts/vt8500.dtsi
+++ b/arch/arm/boot/dts/vt8500.dtsi
@@ -98,12 +98,10 @@
interrupts = <43>;
};
- fb@d800e400 {
+ fb: fb@d8050800 {
compatible = "via,vt8500-fb";
reg = <0xd800e400 0x400>;
interrupts = <12>;
- display = <&display>;
- default-mode = <&mode0>;
};
ge_rops@d8050400 {
diff --git a/arch/arm/boot/dts/wm8505-ref.dts b/arch/arm/boot/dts/wm8505-ref.dts
index fd4e248..edd2cec 100644
--- a/arch/arm/boot/dts/wm8505-ref.dts
+++ b/arch/arm/boot/dts/wm8505-ref.dts
@@ -11,26 +11,22 @@
/ {
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@0 {
- modes {
- mode0: mode@0 {
- hactive = <800>;
- vactive = <480>;
- hback-porch = <88>;
- hfront-porch = <40>;
- hsync-len = <0>;
- vback-porch = <32>;
- vfront-porch = <11>;
- vsync-len = <1>;
- clock = <0>; /* unused but required */
- bpp = <32>; /* non-standard but required */
- };
+&fb {
+ bits-per-pixel = <32>;
+ display-timings {
+ native-mode = <&timing0>;
+ timing0: 800x480 {
+ clock-frequency = <0>; /* unused but required */
+ hactive = <800>;
+ vactive = <480>;
+ hfront-porch = <40>;
+ hback-porch = <88>;
+ hsync-len = <0>;
+ vback-porch = <32>;
+ vfront-porch = <11>;
+ vsync-len = <1>;
};
};
};
diff --git a/arch/arm/boot/dts/wm8505.dtsi b/arch/arm/boot/dts/wm8505.dtsi
index e74a1c0..bcf668d 100644
--- a/arch/arm/boot/dts/wm8505.dtsi
+++ b/arch/arm/boot/dts/wm8505.dtsi
@@ -128,11 +128,9 @@
interrupts = <0>;
};
- fb@d8050800 {
+ fb: fb@d8050800 {
compatible = "wm,wm8505-fb";
reg = <0xd8050800 0x200>;
- display = <&display>;
- default-mode = <&mode0>;
};
ge_rops@d8050400 {
diff --git a/arch/arm/boot/dts/wm8650-mid.dts b/arch/arm/boot/dts/wm8650-mid.dts
index cefd938..61671a0 100644
--- a/arch/arm/boot/dts/wm8650-mid.dts
+++ b/arch/arm/boot/dts/wm8650-mid.dts
@@ -11,26 +11,24 @@
/ {
model = "Wondermedia WM8650-MID Tablet";
+};
+
+&fb {
+ bits-per-pixel = <16>;
- /*
- * 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@0 {
- modes {
- mode0: mode@0 {
- hactive = <800>;
- vactive = <480>;
- hback-porch = <88>;
- hfront-porch = <40>;
- hsync-len = <0>;
- vback-porch = <32>;
- vfront-porch = <11>;
- vsync-len = <1>;
- clock = <0>; /* unused but required */
- bpp = <16>; /* non-standard but required */
- };
+ display-timings {
+ native-mode = <&timing0>;
+ timing0: 800x480 {
+ clock-frequency = <0>; /* unused but required */
+ hactive = <800>;
+ vactive = <480>;
+ hfront-porch = <40>;
+ hback-porch = <88>;
+ hsync-len = <0>;
+ vback-porch = <32>;
+ vfront-porch = <11>;
+ vsync-len = <1>;
};
};
};
+
diff --git a/arch/arm/boot/dts/wm8650.dtsi b/arch/arm/boot/dts/wm8650.dtsi
index db3c0a1..9313407 100644
--- a/arch/arm/boot/dts/wm8650.dtsi
+++ b/arch/arm/boot/dts/wm8650.dtsi
@@ -128,11 +128,9 @@
interrupts = <43>;
};
- fb@d8050800 {
+ fb: fb@d8050800 {
compatible = "wm,wm8505-fb";
reg = <0xd8050800 0x200>;
- display = <&display>;
- default-mode = <&mode0>;
};
ge_rops@d8050400 {
diff --git a/arch/arm/boot/dts/wm8850-w70v2.dts b/arch/arm/boot/dts/wm8850-w70v2.dts
index fcc660c..32d2253 100644
--- a/arch/arm/boot/dts/wm8850-w70v2.dts
+++ b/arch/arm/boot/dts/wm8850-w70v2.dts
@@ -15,28 +15,6 @@
/ {
model = "Wondermedia WM8850-W70v2 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@0 {
- modes {
- mode0: mode@0 {
- hactive = <800>;
- vactive = <480>;
- hback-porch = <88>;
- hfront-porch = <40>;
- hsync-len = <0>;
- vback-porch = <32>;
- vfront-porch = <11>;
- vsync-len = <1>;
- clock = <0>; /* unused but required */
- bpp = <16>; /* non-standard but required */
- };
- };
- };
-
backlight {
compatible = "pwm-backlight";
pwms = <&pwm 0 50000 1>; /* duty inverted */
@@ -45,3 +23,21 @@
default-brightness-level = <5>;
};
};
+
+&fb {
+ bits-per-pixel = <16>;
+ display-timings {
+ native-mode = <&timing0>;
+ timing0: 800x480 {
+ clock-frequency = <0>; /* unused but required */
+ hactive = <800>;
+ vactive = <480>;
+ hfront-porch = <40>;
+ hback-porch = <88>;
+ hsync-len = <0>;
+ vback-porch = <32>;
+ vfront-porch = <11>;
+ vsync-len = <1>;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/wm8850.dtsi b/arch/arm/boot/dts/wm8850.dtsi
index e8cbfdc..7149cd1 100644
--- a/arch/arm/boot/dts/wm8850.dtsi
+++ b/arch/arm/boot/dts/wm8850.dtsi
@@ -135,11 +135,9 @@
};
};
- fb@d8051700 {
+ fb: fb@d8051700 {
compatible = "wm,wm8505-fb";
reg = <0xd8051700 0x200>;
- display = <&display>;
- default-mode = <&mode0>;
};
ge_rops@d8050400 {
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index ad762ed..d0c932a 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -1794,6 +1794,9 @@ config FB_VT8500
select FB_SYS_FILLRECT if (!FB_WMT_GE_ROPS)
select FB_SYS_COPYAREA if (!FB_WMT_GE_ROPS)
select FB_SYS_IMAGEBLIT
+ select FB_MODE_HELPERS
+ select OF_DISPLAY_TIMING
+ select OF_VIDEOMODE
help
This is the framebuffer driver for VIA VT8500 integrated LCD
controller.
@@ -1804,6 +1807,9 @@ config FB_WM8505
select FB_SYS_FILLRECT if (!FB_WMT_GE_ROPS)
select FB_SYS_COPYAREA if (!FB_WMT_GE_ROPS)
select FB_SYS_IMAGEBLIT
+ select FB_MODE_HELPERS
+ select OF_DISPLAY_TIMING
+ select OF_VIDEOMODE
help
This is the framebuffer driver for WonderMedia WM8xxx-series
integrated LCD controller. This driver covers the WM8505, WM8650
diff --git a/drivers/video/vt8500lcdfb.c b/drivers/video/vt8500lcdfb.c
index 1c34821..6bba262 100644
--- a/drivers/video/vt8500lcdfb.c
+++ b/drivers/video/vt8500lcdfb.c
@@ -15,20 +15,21 @@
* GNU General Public License for more details.
*/
-#include <linux/module.h>
-#include <linux/kernel.h>
-#include <linux/errno.h>
-#include <linux/string.h>
-#include <linux/mm.h>
-#include <linux/slab.h>
#include <linux/delay.h>
+#include <linux/dma-mapping.h>
+#include <linux/errno.h>
#include <linux/fb.h>
#include <linux/init.h>
#include <linux/interrupt.h>
#include <linux/io.h>
-#include <linux/dma-mapping.h>
+#include <linux/kernel.h>
+#include <linux/mm.h>
+#include <linux/module.h>
#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/string.h>
#include <linux/wait.h>
+#include <video/of_display_timing.h>
#include "vt8500lcdfb.h"
@@ -290,11 +291,11 @@ static int vt8500lcd_probe(struct platform_device *pdev)
{
struct vt8500lcd_info *fbi;
struct resource *res;
+ struct display_timings *disp_timing;
void *addr;
int irq, ret;
struct fb_videomode of_mode;
- struct device_node *np;
u32 bpp;
dma_addr_t fb_mem_phys;
unsigned long fb_mem_len;
@@ -359,32 +360,18 @@ static int vt8500lcd_probe(struct platform_device *pdev)
goto failed_free_res;
}
- np = of_parse_phandle(pdev->dev.of_node, "default-mode", 0);
- if (!np) {
- pr_err("%s: No display description in Device Tree\n", __func__);
- ret = -EINVAL;
- goto failed_free_res;
- }
+ disp_timing = of_get_display_timings(pdev->dev.of_node);
+ if (!disp_timing)
+ return -EINVAL;
- /*
- * This code is copied from Sascha Hauer's of_videomode helper
- * and can be replaced with a call to the helper once mainlined
- */
- ret = 0;
- ret |= of_property_read_u32(np, "hactive", &of_mode.xres);
- ret |= of_property_read_u32(np, "vactive", &of_mode.yres);
- ret |= of_property_read_u32(np, "hback-porch", &of_mode.left_margin);
- ret |= of_property_read_u32(np, "hfront-porch", &of_mode.right_margin);
- ret |= of_property_read_u32(np, "hsync-len", &of_mode.hsync_len);
- ret |= of_property_read_u32(np, "vback-porch", &of_mode.upper_margin);
- ret |= of_property_read_u32(np, "vfront-porch", &of_mode.lower_margin);
- ret |= of_property_read_u32(np, "vsync-len", &of_mode.vsync_len);
- ret |= of_property_read_u32(np, "bpp", &bpp);
- if (ret) {
- pr_err("%s: Unable to read display properties\n", __func__);
- goto failed_free_res;
- }
- of_mode.vmode = FB_VMODE_NONINTERLACED;
+ ret = of_get_fb_videomode(pdev->dev.of_node, &of_mode,
+ OF_USE_NATIVE_MODE);
+ if (ret)
+ return ret;
+
+ ret = of_property_read_u32(pdev->dev.of_node, "bits-per-pixel", &bpp);
+ if (ret)
+ return ret;
/* try allocating the framebuffer */
fb_mem_len = of_mode.xres * of_mode.yres * 2 * (bpp / 8);
diff --git a/drivers/video/wm8505fb.c b/drivers/video/wm8505fb.c
index 5057457..d571723 100644
--- a/drivers/video/wm8505fb.c
+++ b/drivers/video/wm8505fb.c
@@ -14,23 +14,24 @@
* GNU General Public License for more details.
*/
-#include <linux/module.h>
-#include <linux/kernel.h>
-#include <linux/errno.h>
-#include <linux/string.h>
-#include <linux/mm.h>
-#include <linux/slab.h>
#include <linux/delay.h>
+#include <linux/dma-mapping.h>
#include <linux/fb.h>
+#include <linux/errno.h>
#include <linux/init.h>
#include <linux/interrupt.h>
#include <linux/io.h>
-#include <linux/dma-mapping.h>
-#include <linux/platform_device.h>
-#include <linux/wait.h>
+#include <linux/kernel.h>
+#include <linux/memblock.h>
+#include <linux/mm.h>
+#include <linux/module.h>
#include <linux/of.h>
#include <linux/of_fdt.h>
-#include <linux/memblock.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+#include <linux/wait.h>
+#include <video/of_display_timing.h>
#include "wm8505fb_regs.h"
@@ -276,12 +277,12 @@ static struct fb_ops wm8505fb_ops = {
static int wm8505fb_probe(struct platform_device *pdev)
{
struct wm8505fb_info *fbi;
- struct resource *res;
+ struct resource *res;
+ struct display_timings *disp_timing;
void *addr;
int ret;
- struct fb_videomode of_mode;
- struct device_node *np;
+ struct fb_videomode mode;
u32 bpp;
dma_addr_t fb_mem_phys;
unsigned long fb_mem_len;
@@ -321,33 +322,19 @@ static int wm8505fb_probe(struct platform_device *pdev)
if (fbi->regbase = NULL)
return -EBUSY;
- np = of_parse_phandle(pdev->dev.of_node, "default-mode", 0);
- if (!np) {
- pr_err("%s: No display description in Device Tree\n", __func__);
+ disp_timing = of_get_display_timings(pdev->dev.of_node);
+ if (!disp_timing)
return -EINVAL;
- }
- /*
- * This code is copied from Sascha Hauer's of_videomode helper
- * and can be replaced with a call to the helper once mainlined
- */
- ret = 0;
- ret |= of_property_read_u32(np, "hactive", &of_mode.xres);
- ret |= of_property_read_u32(np, "vactive", &of_mode.yres);
- ret |= of_property_read_u32(np, "hback-porch", &of_mode.left_margin);
- ret |= of_property_read_u32(np, "hfront-porch", &of_mode.right_margin);
- ret |= of_property_read_u32(np, "hsync-len", &of_mode.hsync_len);
- ret |= of_property_read_u32(np, "vback-porch", &of_mode.upper_margin);
- ret |= of_property_read_u32(np, "vfront-porch", &of_mode.lower_margin);
- ret |= of_property_read_u32(np, "vsync-len", &of_mode.vsync_len);
- ret |= of_property_read_u32(np, "bpp", &bpp);
- if (ret) {
- pr_err("%s: Unable to read display properties\n", __func__);
- return -EINVAL;
- }
+ ret = of_get_fb_videomode(pdev->dev.of_node, &mode, OF_USE_NATIVE_MODE);
+ if (ret)
+ return ret;
+
+ ret = of_property_read_u32(pdev->dev.of_node, "bits-per-pixel", &bpp);
+ if (ret)
+ return ret;
- of_mode.vmode = FB_VMODE_NONINTERLACED;
- fb_videomode_to_var(&fbi->fb.var, &of_mode);
+ fb_videomode_to_var(&fbi->fb.var, &mode);
fbi->fb.var.nonstd = 0;
fbi->fb.var.activate = FB_ACTIVATE_NOW;
@@ -356,7 +343,7 @@ static int wm8505fb_probe(struct platform_device *pdev)
fbi->fb.var.width = -1;
/* try allocating the framebuffer */
- fb_mem_len = of_mode.xres * of_mode.yres * 2 * (bpp / 8);
+ fb_mem_len = mode.xres * mode.yres * 2 * (bpp / 8);
fb_mem_virt = dmam_alloc_coherent(&pdev->dev, fb_mem_len, &fb_mem_phys,
GFP_KERNEL);
if (!fb_mem_virt) {
@@ -364,8 +351,8 @@ static int wm8505fb_probe(struct platform_device *pdev)
return -ENOMEM;
}
- fbi->fb.var.xres_virtual = of_mode.xres;
- fbi->fb.var.yres_virtual = of_mode.yres * 2;
+ fbi->fb.var.xres_virtual = mode.xres;
+ fbi->fb.var.yres_virtual = mode.yres * 2;
fbi->fb.var.bits_per_pixel = bpp;
fbi->fb.fix.smem_start = fb_mem_phys;
--
1.7.9.5
^ permalink raw reply related
* [PATCHv2 5/6] video: vt8500: Adjust contrast in wm8505 framebuffer driver.
From: Tony Prisk @ 2013-04-02 4:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1364878200-26343-1-git-send-email-linux@prisktech.co.nz>
The contrast value was typo'd on the original commit (0x80 instead of
0x08). Following feedback from an enduser, a value of 0x10 seems more
suitable due to the default backlight being <100%.
Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
Reviewed-by: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
---
drivers/video/wm8505fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/wm8505fb.c b/drivers/video/wm8505fb.c
index b94ebc9..5057457 100644
--- a/drivers/video/wm8505fb.c
+++ b/drivers/video/wm8505fb.c
@@ -373,7 +373,7 @@ static int wm8505fb_probe(struct platform_device *pdev)
fbi->fb.screen_base = fb_mem_virt;
fbi->fb.screen_size = fb_mem_len;
- fbi->contrast = 0x80;
+ fbi->contrast = 0x10;
ret = wm8505fb_set_par(&fbi->fb);
if (ret) {
dev_err(&pdev->dev, "Failed to set parameters\n");
--
1.7.9.5
^ permalink raw reply related
* [PATCHv2 4/6] drivers/video/wm8505fb.c: use devm_ functions
From: Tony Prisk @ 2013-04-02 4:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1364878200-26343-1-git-send-email-linux@prisktech.co.nz>
From: Julia Lawall <Julia.Lawall@lip6.fr>
The various devm_ functions allocate memory that is released when a driver
detaches. This patch uses these functions for data that is allocated in
the probe function of a platform device and is only freed in the remove
function.
The patch makes some other cleanups. First, the original code used
devm_kzalloc, but kfree. This would lead to a double free. The problem
was found using the following semantic match (http://coccinelle.lip6.fr/):
// <smpl>
@@
expression x,e;
@@
x = devm_kzalloc(...)
... when != x = e
?-kfree(x,...);
// </smpl>
The error-handing code of devm_request_and_ioremap does not print any
warning message, because devm_request_and_ioremap does this.
The call to dma_alloc_coherent is converted to its devm equivalent,
dmam_alloc_coherent. This implicitly introduces a call to
dmam_free_coherent, which was completly missing in the original code.
A semicolon is removed at the end of the error-handling code for the call
to dma_alloc_coherent.
The block of code calling fb_alloc_cmap is moved below the block of code
calling wm8505fb_set_par, so that the error-handing code of the call to
wm8505fb_set_par can just return ret. This way there is only one block of
error-handling code that needs to call fb_dealloc_cmap, and so this is
moved up to the place where it is needed, eliminating the need for all
gotos and labels in the function. This was suggested by Tony Prisk.
The initializations of fbi and ret at the beginning of the function are not
necessary and are removed. The call platform_set_drvdata(pdev, NULL); at
the end of the function is also removed.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
Reviewed-by: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
---
drivers/video/wm8505fb.c | 79 +++++++++++-----------------------------------
1 file changed, 19 insertions(+), 60 deletions(-)
diff --git a/drivers/video/wm8505fb.c b/drivers/video/wm8505fb.c
index ce23a00..b94ebc9 100644
--- a/drivers/video/wm8505fb.c
+++ b/drivers/video/wm8505fb.c
@@ -287,15 +287,11 @@ static int wm8505fb_probe(struct platform_device *pdev)
unsigned long fb_mem_len;
void *fb_mem_virt;
- ret = -ENOMEM;
- fbi = NULL;
-
fbi = devm_kzalloc(&pdev->dev, sizeof(struct wm8505fb_info) +
sizeof(u32) * 16, GFP_KERNEL);
if (!fbi) {
dev_err(&pdev->dev, "Failed to initialize framebuffer device\n");
- ret = -ENOMEM;
- goto failed;
+ return -ENOMEM;
}
strcpy(fbi->fb.fix.id, DRIVER_NAME);
@@ -321,31 +317,14 @@ static int wm8505fb_probe(struct platform_device *pdev)
fbi->fb.pseudo_palette = addr;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (res = NULL) {
- dev_err(&pdev->dev, "no I/O memory resource defined\n");
- ret = -ENODEV;
- goto failed_fbi;
- }
-
- res = request_mem_region(res->start, resource_size(res), DRIVER_NAME);
- if (res = NULL) {
- dev_err(&pdev->dev, "failed to request I/O memory\n");
- ret = -EBUSY;
- goto failed_fbi;
- }
-
- fbi->regbase = ioremap(res->start, resource_size(res));
- if (fbi->regbase = NULL) {
- dev_err(&pdev->dev, "failed to map I/O memory\n");
- ret = -EBUSY;
- goto failed_free_res;
- }
+ fbi->regbase = devm_request_and_ioremap(&pdev->dev, res);
+ if (fbi->regbase = NULL)
+ return -EBUSY;
np = of_parse_phandle(pdev->dev.of_node, "default-mode", 0);
if (!np) {
pr_err("%s: No display description in Device Tree\n", __func__);
- ret = -EINVAL;
- goto failed_free_res;
+ return -EINVAL;
}
/*
@@ -364,7 +343,7 @@ static int wm8505fb_probe(struct platform_device *pdev)
ret |= of_property_read_u32(np, "bpp", &bpp);
if (ret) {
pr_err("%s: Unable to read display properties\n", __func__);
- goto failed_free_res;
+ return -EINVAL;
}
of_mode.vmode = FB_VMODE_NONINTERLACED;
@@ -378,12 +357,12 @@ static int wm8505fb_probe(struct platform_device *pdev)
/* try allocating the framebuffer */
fb_mem_len = of_mode.xres * of_mode.yres * 2 * (bpp / 8);
- fb_mem_virt = dma_alloc_coherent(&pdev->dev, fb_mem_len, &fb_mem_phys,
+ fb_mem_virt = dmam_alloc_coherent(&pdev->dev, fb_mem_len, &fb_mem_phys,
GFP_KERNEL);
if (!fb_mem_virt) {
pr_err("%s: Failed to allocate framebuffer\n", __func__);
return -ENOMEM;
- };
+ }
fbi->fb.var.xres_virtual = of_mode.xres;
fbi->fb.var.yres_virtual = of_mode.yres * 2;
@@ -394,28 +373,29 @@ static int wm8505fb_probe(struct platform_device *pdev)
fbi->fb.screen_base = fb_mem_virt;
fbi->fb.screen_size = fb_mem_len;
- if (fb_alloc_cmap(&fbi->fb.cmap, 256, 0) < 0) {
- dev_err(&pdev->dev, "Failed to allocate color map\n");
- ret = -ENOMEM;
- goto failed_free_io;
- }
-
- wm8505fb_init_hw(&fbi->fb);
-
fbi->contrast = 0x80;
ret = wm8505fb_set_par(&fbi->fb);
if (ret) {
dev_err(&pdev->dev, "Failed to set parameters\n");
- goto failed_free_cmap;
+ return ret;
}
+ if (fb_alloc_cmap(&fbi->fb.cmap, 256, 0) < 0) {
+ dev_err(&pdev->dev, "Failed to allocate color map\n");
+ return -ENOMEM;
+ }
+
+ wm8505fb_init_hw(&fbi->fb);
+
platform_set_drvdata(pdev, fbi);
ret = register_framebuffer(&fbi->fb);
if (ret < 0) {
dev_err(&pdev->dev,
"Failed to register framebuffer device: %d\n", ret);
- goto failed_free_cmap;
+ if (fbi->fb.cmap.len)
+ fb_dealloc_cmap(&fbi->fb.cmap);
+ return ret;
}
ret = device_create_file(&pdev->dev, &dev_attr_contrast);
@@ -429,25 +409,11 @@ static int wm8505fb_probe(struct platform_device *pdev)
fbi->fb.fix.smem_start + fbi->fb.fix.smem_len - 1);
return 0;
-
-failed_free_cmap:
- if (fbi->fb.cmap.len)
- fb_dealloc_cmap(&fbi->fb.cmap);
-failed_free_io:
- iounmap(fbi->regbase);
-failed_free_res:
- release_mem_region(res->start, resource_size(res));
-failed_fbi:
- platform_set_drvdata(pdev, NULL);
- kfree(fbi);
-failed:
- return ret;
}
static int wm8505fb_remove(struct platform_device *pdev)
{
struct wm8505fb_info *fbi = platform_get_drvdata(pdev);
- struct resource *res;
device_remove_file(&pdev->dev, &dev_attr_contrast);
@@ -458,13 +424,6 @@ static int wm8505fb_remove(struct platform_device *pdev)
if (fbi->fb.cmap.len)
fb_dealloc_cmap(&fbi->fb.cmap);
- iounmap(fbi->regbase);
-
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- release_mem_region(res->start, resource_size(res));
-
- kfree(fbi);
-
return 0;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCHv2 3/6] video: vt8500: Correct descriptions in video/Kconfig
From: Tony Prisk @ 2013-04-02 4:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1364878200-26343-1-git-send-email-linux@prisktech.co.nz>
This patch corrects the descriptions for the VIA VT8500 and
Wondermedia WM8xxx-series framebuffer drivers to correctly reflect
which hardware they support.
Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
Reviewed-by: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
---
drivers/video/Kconfig | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 661aa54..ad762ed 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -1789,7 +1789,7 @@ config FB_AU1200
option au1200fb:panel=<name>.
config FB_VT8500
- bool "VT8500 LCD Driver"
+ bool "VIA VT8500 framebuffer support"
depends on (FB = y) && ARM && ARCH_VT8500
select FB_SYS_FILLRECT if (!FB_WMT_GE_ROPS)
select FB_SYS_COPYAREA if (!FB_WMT_GE_ROPS)
@@ -1799,17 +1799,18 @@ config FB_VT8500
controller.
config FB_WM8505
- bool "WM8505 frame buffer support"
+ bool "Wondermedia WM8xxx-series frame buffer support"
depends on (FB = y) && ARM && ARCH_VT8500
select FB_SYS_FILLRECT if (!FB_WMT_GE_ROPS)
select FB_SYS_COPYAREA if (!FB_WMT_GE_ROPS)
select FB_SYS_IMAGEBLIT
help
- This is the framebuffer driver for WonderMedia WM8505/WM8650
- integrated LCD controller.
+ This is the framebuffer driver for WonderMedia WM8xxx-series
+ integrated LCD controller. This driver covers the WM8505, WM8650
+ and WM8850 SoCs.
config FB_WMT_GE_ROPS
- bool "VT8500/WM85xx accelerated raster ops support"
+ bool "VT8500/WM8xxx accelerated raster ops support"
depends on (FB = y) && (FB_VT8500 || FB_WM8505)
default n
help
--
1.7.9.5
^ permalink raw reply related
* [PATCHv2 2/6] video: vt8500: Remove unused platform_data/video-vt8500lcdfb.h
From: Tony Prisk @ 2013-04-02 4:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1364878200-26343-1-git-send-email-linux@prisktech.co.nz>
With the conversion to devicetree only for arch-vt8500, this
header is no longer required. This patch removes the #include
from the two framebuffer drivers that used it, and the header file.
Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
Reviewed-by: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
---
drivers/video/vt8500lcdfb.c | 2 --
drivers/video/wm8505fb.c | 2 --
include/linux/platform_data/video-vt8500lcdfb.h | 31 -----------------------
3 files changed, 35 deletions(-)
delete mode 100644 include/linux/platform_data/video-vt8500lcdfb.h
diff --git a/drivers/video/vt8500lcdfb.c b/drivers/video/vt8500lcdfb.c
index d8cc1f6..1c34821 100644
--- a/drivers/video/vt8500lcdfb.c
+++ b/drivers/video/vt8500lcdfb.c
@@ -30,8 +30,6 @@
#include <linux/platform_device.h>
#include <linux/wait.h>
-#include <linux/platform_data/video-vt8500lcdfb.h>
-
#include "vt8500lcdfb.h"
#ifdef CONFIG_FB_WMT_GE_ROPS
diff --git a/drivers/video/wm8505fb.c b/drivers/video/wm8505fb.c
index db49803..ce23a00 100644
--- a/drivers/video/wm8505fb.c
+++ b/drivers/video/wm8505fb.c
@@ -32,8 +32,6 @@
#include <linux/of_fdt.h>
#include <linux/memblock.h>
-#include <linux/platform_data/video-vt8500lcdfb.h>
-
#include "wm8505fb_regs.h"
#ifdef CONFIG_FB_WMT_GE_ROPS
diff --git a/include/linux/platform_data/video-vt8500lcdfb.h b/include/linux/platform_data/video-vt8500lcdfb.h
deleted file mode 100644
index 7f399c3..0000000
--- a/include/linux/platform_data/video-vt8500lcdfb.h
+++ /dev/null
@@ -1,31 +0,0 @@
-/*
- * VT8500/WM8505 Frame Buffer platform data definitions
- *
- * Copyright (C) 2010 Ed Spiridonov <edo.rus@gmail.com>
- *
- * This software is licensed under the terms of the GNU General Public
- * License version 2, as published by the Free Software Foundation, and
- * may be copied, distributed, and modified under those terms.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- */
-
-#ifndef _VT8500FB_H
-#define _VT8500FB_H
-
-#include <linux/fb.h>
-
-struct vt8500fb_platform_data {
- struct fb_videomode mode;
- u32 xres_virtual;
- u32 yres_virtual;
- u32 bpp;
- unsigned long video_mem_phys;
- void *video_mem_virt;
- unsigned long video_mem_len;
-};
-
-#endif /* _VT8500FB_H */
--
1.7.9.5
^ permalink raw reply related
* [PATCHv2 1/6] video: vt8500: Make wmt_ge_rops optional
From: Tony Prisk @ 2013-04-02 4:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1364878200-26343-1-git-send-email-linux@prisktech.co.nz>
wmt_ge_rops is a seperate driver to vt8500/wm8505 framebuffer
driver but is currently a required option. This patch makes
accelerated raster ops optional.
Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
Reviewed-by: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
---
drivers/video/Kconfig | 22 ++++++++++++----------
drivers/video/vt8500lcdfb.c | 15 +++++++++++++++
drivers/video/wm8505fb.c | 15 +++++++++++++++
3 files changed, 42 insertions(+), 10 deletions(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 4c1546f..661aa54 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -212,14 +212,6 @@ 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 Engine operations.
-
config FB_DEFERRED_IO
bool
depends on FB
@@ -1799,7 +1791,8 @@ config FB_AU1200
config FB_VT8500
bool "VT8500 LCD Driver"
depends on (FB = y) && ARM && ARCH_VT8500
- select FB_WMT_GE_ROPS
+ select FB_SYS_FILLRECT if (!FB_WMT_GE_ROPS)
+ select FB_SYS_COPYAREA if (!FB_WMT_GE_ROPS)
select FB_SYS_IMAGEBLIT
help
This is the framebuffer driver for VIA VT8500 integrated LCD
@@ -1808,12 +1801,21 @@ config FB_VT8500
config FB_WM8505
bool "WM8505 frame buffer support"
depends on (FB = y) && ARM && ARCH_VT8500
- select FB_WMT_GE_ROPS
+ select FB_SYS_FILLRECT if (!FB_WMT_GE_ROPS)
+ select FB_SYS_COPYAREA if (!FB_WMT_GE_ROPS)
select FB_SYS_IMAGEBLIT
help
This is the framebuffer driver for WonderMedia WM8505/WM8650
integrated LCD controller.
+config FB_WMT_GE_ROPS
+ bool "VT8500/WM85xx accelerated raster ops support"
+ depends on (FB = y) && (FB_VT8500 || FB_WM8505)
+ default n
+ help
+ This adds support for accelerated raster operations on the
+ VIA VT8500 and Wondermedia 85xx series SoCs.
+
source "drivers/video/geode/Kconfig"
config FB_HIT
diff --git a/drivers/video/vt8500lcdfb.c b/drivers/video/vt8500lcdfb.c
index aa2579c..d8cc1f6 100644
--- a/drivers/video/vt8500lcdfb.c
+++ b/drivers/video/vt8500lcdfb.c
@@ -33,7 +33,10 @@
#include <linux/platform_data/video-vt8500lcdfb.h>
#include "vt8500lcdfb.h"
+
+#ifdef CONFIG_FB_WMT_GE_ROPS
#include "wmt_ge_rops.h"
+#endif
#ifdef CONFIG_OF
#include <linux/of.h>
@@ -249,12 +252,24 @@ static int vt8500lcd_blank(int blank, struct fb_info *info)
return 0;
}
+#ifndef CONFIG_FB_WMT_GE_ROPS
+static int wmt_ge_sync(struct fb_info *p)
+{
+ return 0;
+}
+#endif
+
static struct fb_ops vt8500lcd_ops = {
.owner = THIS_MODULE,
.fb_set_par = vt8500lcd_set_par,
.fb_setcolreg = vt8500lcd_setcolreg,
+#ifdef CONFIG_FB_WMT_GE_ROPS
.fb_fillrect = wmt_ge_fillrect,
.fb_copyarea = wmt_ge_copyarea,
+#else
+ .fb_fillrect = sys_fillrect,
+ .fb_copyarea = sys_copyarea,
+#endif
.fb_imageblit = sys_imageblit,
.fb_sync = wmt_ge_sync,
.fb_ioctl = vt8500lcd_ioctl,
diff --git a/drivers/video/wm8505fb.c b/drivers/video/wm8505fb.c
index 4dd0580..db49803 100644
--- a/drivers/video/wm8505fb.c
+++ b/drivers/video/wm8505fb.c
@@ -35,7 +35,10 @@
#include <linux/platform_data/video-vt8500lcdfb.h>
#include "wm8505fb_regs.h"
+
+#ifdef CONFIG_FB_WMT_GE_ROPS
#include "wmt_ge_rops.h"
+#endif
#define DRIVER_NAME "wm8505-fb"
@@ -248,12 +251,24 @@ static int wm8505fb_blank(int blank, struct fb_info *info)
return 0;
}
+#ifndef CONFIG_FB_WMT_GE_ROPS
+static int wmt_ge_sync(struct fb_info *p)
+{
+ return 0;
+}
+#endif
+
static struct fb_ops wm8505fb_ops = {
.owner = THIS_MODULE,
.fb_set_par = wm8505fb_set_par,
.fb_setcolreg = wm8505fb_setcolreg,
+#ifdef CONFIG_FB_WMT_GE_ROPS
.fb_fillrect = wmt_ge_fillrect,
.fb_copyarea = wmt_ge_copyarea,
+#else
+ .fb_fillrect = sys_fillrect,
+ .fb_copyarea = sys_copyarea,
+#endif
.fb_imageblit = sys_imageblit,
.fb_sync = wmt_ge_sync,
.fb_pan_display = wm8505fb_pan_display,
--
1.7.9.5
^ permalink raw reply related
* [PATCHv2 0/6] fb: vt8500: patches for 3.10
From: Tony Prisk @ 2013-04-02 4:49 UTC (permalink / raw)
To: linux-arm-kernel
V2 Changes:
Split the SoC and board portions of the binding into their respective files.
Removed the forced non-interlaced code from wm8505fb.c and vt8500lcdfb.c
Julia Lawall (1):
drivers/video/wm8505fb.c: use devm_ functions
Tony Prisk (5):
video: vt8500: Make wmt_ge_rops optional
video: vt8500: Remove unused platform_data/video-vt8500lcdfb.h
video: vt8500: Correct descriptions in video/Kconfig
video: vt8500: Adjust contrast in wm8505 framebuffer driver.
video: fb: vt8500: Convert framebuffer drivers to standardized
binding
.../devicetree/bindings/video/via,vt8500-fb.txt | 48 ++----
.../devicetree/bindings/video/wm,wm8505-fb.txt | 32 ++--
arch/arm/boot/dts/vt8500-bv07.dts | 34 ++---
arch/arm/boot/dts/vt8500.dtsi | 4 +-
arch/arm/boot/dts/wm8505-ref.dts | 34 ++---
arch/arm/boot/dts/wm8505.dtsi | 4 +-
arch/arm/boot/dts/wm8650-mid.dts | 36 +++--
arch/arm/boot/dts/wm8650.dtsi | 4 +-
arch/arm/boot/dts/wm8850-w70v2.dts | 40 +++--
arch/arm/boot/dts/wm8850.dtsi | 4 +-
drivers/video/Kconfig | 37 +++--
drivers/video/vt8500lcdfb.c | 70 ++++-----
drivers/video/wm8505fb.c | 159 ++++++++------------
include/linux/platform_data/video-vt8500lcdfb.h | 31 ----
14 files changed, 218 insertions(+), 319 deletions(-)
delete mode 100644 include/linux/platform_data/video-vt8500lcdfb.h
--
1.7.9.5
^ permalink raw reply
* [PATCH V4 4/4] fbcon: queue work on unbound wq
From: Viresh Kumar @ 2013-03-31 14:43 UTC (permalink / raw)
To: tj
Cc: linaro-kernel, patches, robin.randhawa, Steve.Bannister,
Liviu.Dudau, charles.garcia-tobin, arvind.chauhan, davem, airlied,
axboe, tglx, peterz, mingo, rostedt, linux-rt-users, linux-kernel,
Viresh Kumar, linux-fbdev
In-Reply-To: <cover.1364740180.git.viresh.kumar@linaro.org>
fbcon uses workqueues and it has no real dependency of scheduling these on the
cpu which scheduled them.
On a idle system, it is observed that and idle cpu wakes up many times just to
service this work. It would be better if we can schedule it on a cpu which the
scheduler believes to be the most appropriate one.
This patch replaces system_wq with system_unbound_wq.
Cc: Dave Airlie <airlied@redhat.com>
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
drivers/video/console/fbcon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index 3cd6759..6c1f7c3 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -404,7 +404,7 @@ static void cursor_timer_handler(unsigned long dev_addr)
struct fb_info *info = (struct fb_info *) dev_addr;
struct fbcon_ops *ops = info->fbcon_par;
- schedule_work(&info->queue);
+ queue_work(system_unbound_wq, &info->queue);
mod_timer(&ops->cursor_timer, jiffies + HZ/5);
}
--
1.7.12.rc2.18.g61b472e
^ permalink raw reply related
* [PATCH V4 4/4] fbcon: queue work on unbound wq
From: Viresh Kumar @ 2013-03-31 14:39 UTC (permalink / raw)
To: linux-fbdev
fbcon uses workqueues and it has no real dependency of scheduling these on the
cpu which scheduled them.
On a idle system, it is observed that and idle cpu wakes up many times just to
service this work. It would be better if we can schedule it on a cpu which the
scheduler believes to be the most appropriate one.
This patch replaces system_wq with system_unbound_wq.
Cc: Dave Airlie <airlied@redhat.com>
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
drivers/video/console/fbcon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index 3cd6759..6c1f7c3 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -404,7 +404,7 @@ static void cursor_timer_handler(unsigned long dev_addr)
struct fb_info *info = (struct fb_info *) dev_addr;
struct fbcon_ops *ops = info->fbcon_par;
- schedule_work(&info->queue);
+ queue_work(system_unbound_wq, &info->queue);
mod_timer(&ops->cursor_timer, jiffies + HZ/5);
}
--
1.7.12.rc2.18.g61b472e
^ permalink raw reply related
* [PATCH] geodefb: Depend on X86_32
From: Jean Delvare @ 2013-03-31 13:04 UTC (permalink / raw)
To: linux-fbdev
From: Jeff Mahoney <jeffm@suse.com>
Geode is 32-bit only so only enable it for X86_32.
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: Jean Delvare <jdelvare@suse.de>
---
We have this patch in the Suse kernel tree for almost a year, it would
be great if it could finally make it upstream.
drivers/video/geode/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/video/geode/Kconfig
+++ b/drivers/video/geode/Kconfig
@@ -3,7 +3,7 @@
#
config FB_GEODE
bool "AMD Geode family framebuffer support"
- depends on FB && PCI && X86
+ depends on FB && PCI && X86_32
---help---
Say 'Y' here to allow you to select framebuffer drivers for
the AMD Geode family of processors.
--
Jean Delvare
Suse L3
^ permalink raw reply
* Re: [PATCH 0/5] video: vt8500 patches for 3.10
From: Tony Prisk @ 2013-03-30 21:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130329184413.GJ20693@game.jcrosoft.org>
On 30/03/13 07:44, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 19:46 Sat 23 Mar , Tony Prisk wrote:
>> Hi Florian,
>>
>> These patches were posted for 3.9, but I didn't recieve any reply back at the
>> time. Reposting for 3.10 - based on 3.9-rc2
>>
>> Regards
>> Tony P
> look ok
>
> Best Regards,
> J.
>
Jean-Christope,
Can I add a reviewed-by for these patches?
Regards
Tony P
^ permalink raw reply
* [PATCH]video:uvesafb: Fix dereference NULL pointer code path
From: Wang YanQing @ 2013-03-30 2:53 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: spock, linux-fbdev, FlorianSchandinat, linux-kernel
platform_device_alloc could failed and return NULL,
we should check this before call platform_device_put.
Signed-off-by: Wang YanQing <udknight@gmail.com>
---
drivers/video/uvesafb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/video/uvesafb.c b/drivers/video/uvesafb.c
index 2f8f82d..230bd45 100644
--- a/drivers/video/uvesafb.c
+++ b/drivers/video/uvesafb.c
@@ -1975,7 +1975,8 @@ static int __devinit uvesafb_init(void)
err = -ENOMEM;
if (err) {
- platform_device_put(uvesafb_device);
+ if (uvesafb_device)
+ platform_device_put(uvesafb_device);
platform_driver_unregister(&uvesafb_driver);
cn_del_callback(&uvesafb_cn_id);
return err;
--
1.7.11.1.116.g8228a23
^ permalink raw reply related
* [PATCH] drivers/video: fsl-diu-fb: add hardware cursor support
From: Timur Tabi @ 2013-03-30 0:36 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1358281046-31552-1-git-send-email-timur@tabi.org>
The Freescale DIU supports a 32x32 color hardware cursor. Framebuffer
cursors are monochrome, so the driver converts the image data to the
format that the DIU expects and then programs to hardware accordingly.
The support cursor enabling/disabling, we provide two cursor image buffers.
One is always blank (all zeroes), and the other contains the real cursor
image data. To disable the cursor (used typically for cursor blinking),
we just tell the hardware to use the blank cursor data.
Signed-off-by: Timur Tabi <timur@tabi.org>
---
drivers/video/fsl-diu-fb.c | 157 ++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 155 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
index 41fbd94..6c27805 100644
--- a/drivers/video/fsl-diu-fb.c
+++ b/drivers/video/fsl-diu-fb.c
@@ -375,7 +375,10 @@ struct fsl_diu_data {
struct diu_ad dummy_ad __aligned(8);
struct diu_ad ad[NUM_AOIS] __aligned(8);
u8 gamma[256 * 3] __aligned(32);
- u8 cursor[MAX_CURS * MAX_CURS * 2] __aligned(32);
+ /* It's easier to parse the cursor data as little-endian */
+ __le16 cursor[MAX_CURS * MAX_CURS] __aligned(32);
+ /* Blank cursor data -- used to hide the cursor */
+ __le16 blank_cursor[MAX_CURS * MAX_CURS] __aligned(32);
uint8_t edid_data[EDID_LENGTH];
bool has_edid;
} __aligned(32);
@@ -824,7 +827,6 @@ static void update_lcdc(struct fb_info *info)
/* Program DIU registers */
out_be32(&hw->gamma, DMA_ADDR(data, gamma));
- out_be32(&hw->cursor, DMA_ADDR(data, cursor));
out_be32(&hw->bgnd, 0x007F7F7F); /* Set background to grey */
out_be32(&hw->disp_size, (var->yres << 16) | var->xres);
@@ -968,6 +970,156 @@ static u32 fsl_diu_get_pixel_format(unsigned int bits_per_pixel)
}
/*
+ * Copies a cursor image from user space to the proper place in driver
+ * memory so that the hardware can display the cursor image.
+ *
+ * Cursor data is represented as a sequence of 'width' bits packed into bytes.
+ * That is, the first 8 bits are in the first byte, the second 8 bits in the
+ * second byte, and so on. Therefore, the each row of the cursor is (width +
+ * 7) / 8 bytes of 'data'
+ *
+ * The DIU only supports cursors up to 32x32 (MAX_CURS). We reject cursors
+ * larger than this, so we already know that 'width' <= 32. Therefore, we can
+ * simplify our code by using a 32-bit big-endian integer ("line") to read in
+ * a single line of pixels, and only look at the top 'width' bits of that
+ * integer.
+ *
+ * This could result in an unaligned 32-bit read. For example, if the cursor
+ * is 24x24, then the first three bytes of 'image' contain the pixel data for
+ * the top line of the cursor. We do a 32-bit read of 'image', but we look
+ * only at the top 24 bits. Then we increment 'image' by 3 bytes. The next
+ * read is unaligned. The only problem is that we might read past the end of
+ * 'image' by 1-3 bytes, but that should not cause any problems.
+ */
+static void fsl_diu_load_cursor_image(struct fb_info *info,
+ const void *image, uint16_t bg, uint16_t fg,
+ unsigned int width, unsigned int height)
+{
+ struct mfb_info *mfbi = info->par;
+ struct fsl_diu_data *data = mfbi->parent;
+ __le16 *cursor = data->cursor;
+ __le16 _fg = cpu_to_le16(fg);
+ __le16 _bg = cpu_to_le16(bg);
+ unsigned int h, w;
+
+ for (h = 0; h < height; h++) {
+ uint32_t mask = 1 << 31;
+ uint32_t line = be32_to_cpup(image);
+
+ for (w = 0; w < width; w++) {
+ cursor[w] = (line & mask) ? _fg : _bg;
+ mask >>= 1;
+ }
+
+ cursor += MAX_CURS;
+ image += DIV_ROUND_UP(width, 8);
+ }
+}
+
+/*
+ * Set a hardware cursor. The image data for the cursor is passed via the
+ * fb_cursor object.
+ */
+static int fsl_diu_cursor(struct fb_info *info, struct fb_cursor *cursor)
+{
+ struct mfb_info *mfbi = info->par;
+ struct fsl_diu_data *data = mfbi->parent;
+ struct diu __iomem *hw = data->diu_reg;
+
+ if (cursor->image.width > MAX_CURS || cursor->image.height > MAX_CURS)
+ return -EINVAL;
+
+ /* The cursor size has changed */
+ if (cursor->set & FB_CUR_SETSIZE) {
+ /*
+ * The DIU cursor is a fixed size, so when we get this
+ * message, instead of resizing the cursor, we just clear
+ * all the image data, in expectation of new data. However,
+ * in tests this control does not appear to be normally
+ * called.
+ */
+ memset(data->cursor, 0, sizeof(data->cursor));
+ }
+
+ /* The cursor position has changed (cursor->image.dx|dy) */
+ if (cursor->set & FB_CUR_SETPOS) {
+ uint32_t xx, yy;
+
+ yy = (cursor->image.dy - info->var.yoffset) & 0x7ff;
+ xx = (cursor->image.dx - info->var.xoffset) & 0x7ff;
+
+ out_be32(&hw->curs_pos, yy << 16 | xx);
+ }
+
+ /*
+ * FB_CUR_SETIMAGE - the cursor image has changed
+ * FB_CUR_SETCMAP - the cursor colors has changed
+ * FB_CUR_SETSHAPE - the cursor bitmask has changed
+ */
+ if (cursor->set & (FB_CUR_SETSHAPE | FB_CUR_SETCMAP | FB_CUR_SETIMAGE)) {
+ unsigned int image_size + DIV_ROUND_UP(cursor->image.width, 8) * cursor->image.height;
+ unsigned int image_words + DIV_ROUND_UP(image_size, sizeof(uint32_t));
+ unsigned int bg_idx = cursor->image.bg_color;
+ unsigned int fg_idx = cursor->image.fg_color;
+ uint8_t buffer[image_size];
+ uint32_t *image, *source, *mask;
+ uint16_t fg, bg;
+ unsigned int i;
+
+ if (info->state != FBINFO_STATE_RUNNING)
+ return 0;
+
+ /*
+ * Determine the size of the cursor image data. Normally,
+ * it's 8x16.
+ */
+ image_size = DIV_ROUND_UP(cursor->image.width, 8) *
+ cursor->image.height;
+
+ bg = ((info->cmap.red[bg_idx] & 0xf8) << 7) |
+ ((info->cmap.green[bg_idx] & 0xf8) << 2) |
+ ((info->cmap.blue[bg_idx] & 0xf8) >> 3) |
+ 1 << 15;
+
+ fg = ((info->cmap.red[fg_idx] & 0xf8) << 7) |
+ ((info->cmap.green[fg_idx] & 0xf8) << 2) |
+ ((info->cmap.blue[fg_idx] & 0xf8) >> 3) |
+ 1 << 15;
+
+ /* Use 32-bit operations on the data to improve performance */
+ image = (uint32_t *)buffer;
+ source = (uint32_t *)cursor->image.data;
+ mask = (uint32_t *)cursor->mask;
+
+ if (cursor->rop = ROP_XOR)
+ for (i = 0; i < image_words; i++)
+ image[i] = source[i] ^ mask[i];
+ else
+ for (i = 0; i < image_words; i++)
+ image[i] = source[i] & mask[i];
+
+ fsl_diu_load_cursor_image(info, image, bg, fg,
+ cursor->image.width, cursor->image.height);
+ };
+
+ /*
+ * Show or hide the cursor. The cursor data is always stored in the
+ * 'cursor' memory block, and the actual cursor position is always in
+ * the DIU's CURS_POS register. To hide the cursor, we redirect the
+ * CURSOR register to a blank cursor. The show the cursor, we
+ * redirect the CURSOR register to the real cursor data.
+ */
+ if (cursor->enable)
+ out_be32(&hw->cursor, DMA_ADDR(data, cursor));
+ else
+ out_be32(&hw->cursor, DMA_ADDR(data, blank_cursor));
+
+ return 0;
+}
+
+/*
* Using the fb_var_screeninfo in fb_info we set the resolution of this
* particular framebuffer. This function alters the fb_fix_screeninfo stored
* in fb_info. It does not alter var in fb_info since we are using that
@@ -1312,6 +1464,7 @@ static struct fb_ops fsl_diu_ops = {
.fb_ioctl = fsl_diu_ioctl,
.fb_open = fsl_diu_open,
.fb_release = fsl_diu_release,
+ .fb_cursor = fsl_diu_cursor,
};
static int install_fb(struct fb_info *info)
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH 1/2] video: ssd1307fb: Add support for SSD1306 OLED controller
From: Maxime Ripard @ 2013-03-29 19:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130329183842.GH20693@game.jcrosoft.org>
Hi Jean Christophe,
Le 29/03/2013 19:38, Jean-Christophe PLAGNIOL-VILLARD a écrit :
> On 17:44 Wed 06 Mar , Maxime Ripard wrote:
[snip]
>> static int ssd1307fb_probe(struct i2c_client *client,
>> const struct i2c_device_id *id)
>> {
>> struct fb_info *info;
>> - u32 vmem_size = SSD1307FB_WIDTH * SSD1307FB_HEIGHT / 8;
>> + struct device_node *node = client->dev.of_node;
>> + u32 vmem_size;
>> struct ssd1307fb_par *par;
>> u8 *vmem;
>> int ret;
>>
>> - if (!client->dev.of_node) {
>> + if (!node) {
> why this will be DT only?
>
> a platform or ARN that does not support DT can not use this driver
>
> this looks not right
Because the platform I was developing that for was DT-only, and I guess
if someone wants to use this driver on a non-DT platform, that
hypothetical someone can always send a patch to enable the "old-style"
probing in this driver.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 0/5] video: vt8500 patches for 3.10
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-03-29 18:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1364021193-19835-1-git-send-email-linux@prisktech.co.nz>
On 19:46 Sat 23 Mar , Tony Prisk wrote:
> Hi Florian,
>
> These patches were posted for 3.9, but I didn't recieve any reply back at the
> time. Reposting for 3.10 - based on 3.9-rc2
>
> Regards
> Tony P
look ok
Best Regards,
J.
>
> Julia Lawall (1):
> drivers/video/wm8505fb.c: use devm_ functions
>
> Tony Prisk (4):
> video: vt8500: Make wmt_ge_rops optional
> video: vt8500: Remove unused platform_data/video-vt8500lcdfb.h
> video: vt8500: Correct descriptions in video/Kconfig
> video: vt8500: Adjust contrast in wm8505 framebuffer driver.
>
> drivers/video/Kconfig | 31 ++++----
> drivers/video/vt8500lcdfb.c | 17 +++-
> drivers/video/wm8505fb.c | 96 ++++++++---------------
> include/linux/platform_data/video-vt8500lcdfb.h | 31 --------
> 4 files changed, 66 insertions(+), 109 deletions(-)
> delete mode 100644 include/linux/platform_data/video-vt8500lcdfb.h
>
> --
> 1.7.9.5
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] video: ssd1307fb: Add support for SSD1306 OLED controller
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-03-29 18:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1362588251-1824-2-git-send-email-maxime.ripard@free-electrons.com>
On 17:44 Wed 06 Mar , Maxime Ripard wrote:
> The Solomon SSD1306 OLED controller is very similar to the SSD1307,
> except for the fact that the power is given through an external PWM for
> the 1307, and while the 1306 can generate its own power without any PWM.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> .../devicetree/bindings/video/ssd1307fb.txt | 10 +-
> drivers/video/ssd1307fb.c | 267 ++++++++++++++------
> 2 files changed, 203 insertions(+), 74 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/video/ssd1307fb.txt b/Documentation/devicetree/bindings/video/ssd1307fb.txt
> index 3d0060c..7a12542 100644
> --- a/Documentation/devicetree/bindings/video/ssd1307fb.txt
> +++ b/Documentation/devicetree/bindings/video/ssd1307fb.txt
> @@ -1,13 +1,17 @@
> * Solomon SSD1307 Framebuffer Driver
>
> Required properties:
> - - compatible: Should be "solomon,ssd1307fb-<bus>". The only supported bus for
> - now is i2c.
> + - compatible: Should be "solomon,<chip>fb-<bus>". The only supported bus for
> + now is i2c, and the supported chips are ssd1306 and ssd1307.
> - reg: Should contain address of the controller on the I2C bus. Most likely
> 0x3c or 0x3d
> - pwm: Should contain the pwm to use according to the OF device tree PWM
> - specification [0]
> + specification [0]. Only required for the ssd1307.
> - reset-gpios: Should contain the GPIO used to reset the OLED display
> + - solomon,height: Height in pixel of the screen driven by the controller
> + - solomon,width: Width in pixel of the screen driven by the controller
> + - solomon,page-offset: Offset of pages (band of 8 pixels) that the screen is
> + mapped to.
>
> Optional properties:
> - reset-active-low: Is the reset gpio is active on physical low?
> diff --git a/drivers/video/ssd1307fb.c b/drivers/video/ssd1307fb.c
> index 395cb6a..95f76e2 100644
> --- a/drivers/video/ssd1307fb.c
> +++ b/drivers/video/ssd1307fb.c
> @@ -16,24 +16,39 @@
> #include <linux/pwm.h>
> #include <linux/delay.h>
>
> -#define SSD1307FB_WIDTH 96
> -#define SSD1307FB_HEIGHT 16
> -
> #define SSD1307FB_DATA 0x40
> #define SSD1307FB_COMMAND 0x80
>
> #define SSD1307FB_CONTRAST 0x81
> +#define SSD1307FB_CHARGE_PUMP 0x8d
> #define SSD1307FB_SEG_REMAP_ON 0xa1
> #define SSD1307FB_DISPLAY_OFF 0xae
> +#define SSD1307FB_SET_MULTIPLEX_RATIO 0xa8
> #define SSD1307FB_DISPLAY_ON 0xaf
> #define SSD1307FB_START_PAGE_ADDRESS 0xb0
> +#define SSD1307FB_SET_DISPLAY_OFFSET 0xd3
> +#define SSD1307FB_SET_CLOCK_FREQ 0xd5
> +#define SSD1307FB_SET_PRECHARGE_PERIOD 0xd9
> +#define SSD1307FB_SET_COM_PINS_CONFIG 0xda
> +#define SSD1307FB_SET_VCOMH 0xdb
> +
> +struct ssd1307fb_par;
> +
> +struct ssd1307fb_ops {
> + int (*init)(struct ssd1307fb_par *);
> + int (*remove)(struct ssd1307fb_par *);
> +};
>
> struct ssd1307fb_par {
> struct i2c_client *client;
> + u32 height;
> struct fb_info *info;
> + struct ssd1307fb_ops *ops;
> + u32 page_offset;
> struct pwm_device *pwm;
> u32 pwm_period;
> int reset;
> + u32 width;
> };
>
> static struct fb_fix_screeninfo ssd1307fb_fix = {
> @@ -43,15 +58,10 @@ static struct fb_fix_screeninfo ssd1307fb_fix = {
> .xpanstep = 0,
> .ypanstep = 0,
> .ywrapstep = 0,
> - .line_length = SSD1307FB_WIDTH / 8,
> .accel = FB_ACCEL_NONE,
> };
>
> static struct fb_var_screeninfo ssd1307fb_var = {
> - .xres = SSD1307FB_WIDTH,
> - .yres = SSD1307FB_HEIGHT,
> - .xres_virtual = SSD1307FB_WIDTH,
> - .yres_virtual = SSD1307FB_HEIGHT,
> .bits_per_pixel = 1,
> };
>
> @@ -134,16 +144,16 @@ static void ssd1307fb_update_display(struct ssd1307fb_par *par)
> * (5) A4 B4 C4 D4 E4 F4 G4 H4
> */
>
> - for (i = 0; i < (SSD1307FB_HEIGHT / 8); i++) {
> - ssd1307fb_write_cmd(par->client, SSD1307FB_START_PAGE_ADDRESS + (i + 1));
> + for (i = 0; i < (par->height / 8); i++) {
> + ssd1307fb_write_cmd(par->client, SSD1307FB_START_PAGE_ADDRESS + i + par->page_offset);
> ssd1307fb_write_cmd(par->client, 0x00);
> ssd1307fb_write_cmd(par->client, 0x10);
>
> - for (j = 0; j < SSD1307FB_WIDTH; j++) {
> + for (j = 0; j < par->width; j++) {
> u8 buf = 0;
> for (k = 0; k < 8; k++) {
> - u32 page_length = SSD1307FB_WIDTH * i;
> - u32 index = page_length + (SSD1307FB_WIDTH * k + j) / 8;
> + u32 page_length = par->width * i;
> + u32 index = page_length + (par->width * k + j) / 8;
> u8 byte = *(vmem + index);
> u8 bit = byte & (1 << (j % 8));
> bit = bit >> (j % 8);
> @@ -227,16 +237,137 @@ static struct fb_deferred_io ssd1307fb_defio = {
> .deferred_io = ssd1307fb_deferred_io,
> };
>
> +static int ssd1307fb_ssd1307_init(struct ssd1307fb_par *par) {
> + int ret;
> +
> + par->pwm = pwm_get(&par->client->dev, NULL);
> + if (IS_ERR(par->pwm)) {
> + dev_err(&par->client->dev, "Could not get PWM from device tree!\n");
> + return PTR_ERR(par->pwm);
> + }
> +
> + par->pwm_period = pwm_get_period(par->pwm);
> + /* Enable the PWM */
> + pwm_config(par->pwm, par->pwm_period / 2, par->pwm_period);
> + pwm_enable(par->pwm);
> +
> + dev_dbg(&par->client->dev, "Using PWM%d with a %dns period.\n", par->pwm->pwm, par->pwm_period);
> +
> + /* Map column 127 of the OLED to segment 0 */
> + ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SEG_REMAP_ON);
> + if (ret < 0)
> + return ret;
> +
> + /* Turn on the display */
> + ret = ssd1307fb_write_cmd(par->client, SSD1307FB_DISPLAY_ON);
> + if (ret < 0)
> + return ret;
> +
> + return 0;
> +}
> +
> +static int ssd1307fb_ssd1307_remove(struct ssd1307fb_par *par) {
> + pwm_disable(par->pwm);
> + pwm_put(par->pwm);
> + return 0;
> +}
> +
> +static struct ssd1307fb_ops ssd1307fb_ssd1307_ops = {
> + .init = ssd1307fb_ssd1307_init,
> + .remove = ssd1307fb_ssd1307_remove,
> +};
> +
> +static int ssd1307fb_ssd1306_init(struct ssd1307fb_par *par) {
> + int ret;
> +
> + /* Set initial contrast */
> + ret = ssd1307fb_write_cmd(par->client, SSD1307FB_CONTRAST);
> + ret = ret & ssd1307fb_write_cmd(par->client, 0x7f);
> + if (ret < 0)
> + return ret;
> +
> + /* Set COM direction */
> + ret = ssd1307fb_write_cmd(par->client, 0xc8);
> + if (ret < 0)
> + return ret;
> +
> + /* Set segment re-map */
> + ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SEG_REMAP_ON);
> + if (ret < 0)
> + return ret;
> +
> + /* Set multiplex ratio value */
> + ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_MULTIPLEX_RATIO);
> + ret = ret & ssd1307fb_write_cmd(par->client, par->height - 1);
> + if (ret < 0)
> + return ret;
> +
> + /* set display offset value */
> + ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_DISPLAY_OFFSET);
> + ret = ssd1307fb_write_cmd(par->client, 0x20);
> + if (ret < 0)
> + return ret;
> +
> + /* Set clock frequency */
> + ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_CLOCK_FREQ);
> + ret = ret & ssd1307fb_write_cmd(par->client, 0xf0);
> + if (ret < 0)
> + return ret;
> +
> + /* Set precharge period in number of ticks from the internal clock */
> + ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_PRECHARGE_PERIOD);
> + ret = ret & ssd1307fb_write_cmd(par->client, 0x22);
> + if (ret < 0)
> + return ret;
> +
> + /* Set COM pins configuration */
> + ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_COM_PINS_CONFIG);
> + ret = ret & ssd1307fb_write_cmd(par->client, 0x22);
> + if (ret < 0)
> + return ret;
> +
> + /* Set VCOMH */
> + ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_VCOMH);
> + ret = ret & ssd1307fb_write_cmd(par->client, 0x49);
> + if (ret < 0)
> + return ret;
> +
> + /* Turn on the DC-DC Charge Pump */
> + ret = ssd1307fb_write_cmd(par->client, SSD1307FB_CHARGE_PUMP);
> + ret = ret & ssd1307fb_write_cmd(par->client, 0x14);
> + if (ret < 0)
> + return ret;
> +
> + /* Turn on the display */
> + ret = ssd1307fb_write_cmd(par->client, SSD1307FB_DISPLAY_ON);
> + if (ret < 0)
> + return ret;
> +
> + return 0;
> +}
> +
> +static struct ssd1307fb_ops ssd1307fb_ssd1306_ops = {
> + .init = ssd1307fb_ssd1306_init,
> +};
> +
> +static const struct of_device_id ssd1307fb_of_match[] = {
> + { .compatible = "solomon,ssd1306fb-i2c", .data = (void*)&ssd1307fb_ssd1306_ops },
> + { .compatible = "solomon,ssd1307fb-i2c", .data = (void*)&ssd1307fb_ssd1307_ops },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, ssd1307fb_of_match);
> +
> static int ssd1307fb_probe(struct i2c_client *client,
> const struct i2c_device_id *id)
> {
> struct fb_info *info;
> - u32 vmem_size = SSD1307FB_WIDTH * SSD1307FB_HEIGHT / 8;
> + struct device_node *node = client->dev.of_node;
> + u32 vmem_size;
> struct ssd1307fb_par *par;
> u8 *vmem;
> int ret;
>
> - if (!client->dev.of_node) {
> + if (!node) {
why this will be DT only?
a platform or ARN that does not support DT can not use this driver
this looks not right
> dev_err(&client->dev, "No device tree data found!\n");
> return -EINVAL;
> }
> @@ -247,6 +378,36 @@ static int ssd1307fb_probe(struct i2c_client *client,
> return -ENOMEM;
> }
>
> + par = info->par;
> + par->info = info;
> + par->client = client;
> +
> + par->ops = (struct ssd1307fb_ops*)of_match_device(ssd1307fb_of_match, &client->dev)->data;
> +
> + par->reset = of_get_named_gpio(client->dev.of_node,
> + "reset-gpios", 0);
> + if (!gpio_is_valid(par->reset)) {
> + ret = -EINVAL;
> + goto fb_alloc_error;
> + }
> +
> + if (of_property_read_u32(node, "solomon,width", &par->width))
> + par->width = 96;
> +
> + printk("Width\t%u\n", par->width);
> +
> + if (of_property_read_u32(node, "solomon,height", &par->height))
> + par->width = 16;
> +
> + printk("Height\t%u\n", par->height);
> +
> + if (of_property_read_u32(node, "solomon,page-offset", &par->page_offset))
> + par->page_offset = 1;
> +
> + printk("Offset\t%u\n", par->page_offset);
> +
> + vmem_size = par->width * par->height / 8;
> +
> vmem = devm_kzalloc(&client->dev, vmem_size, GFP_KERNEL);
> if (!vmem) {
> dev_err(&client->dev, "Couldn't allocate graphical memory.\n");
> @@ -256,9 +417,15 @@ static int ssd1307fb_probe(struct i2c_client *client,
>
> info->fbops = &ssd1307fb_ops;
> info->fix = ssd1307fb_fix;
> + info->fix.line_length = par->width / 8;
> info->fbdefio = &ssd1307fb_defio;
>
> info->var = ssd1307fb_var;
> + info->var.xres = par->width;
> + info->var.xres_virtual = par->width;
> + info->var.yres = par->height;
> + info->var.yres_virtual = par->height;
> +
> info->var.red.length = 1;
> info->var.red.offset = 0;
> info->var.green.length = 1;
> @@ -272,17 +439,6 @@ static int ssd1307fb_probe(struct i2c_client *client,
>
> fb_deferred_io_init(info);
>
> - par = info->par;
> - par->info = info;
> - par->client = client;
> -
> - par->reset = of_get_named_gpio(client->dev.of_node,
> - "reset-gpios", 0);
> - if (!gpio_is_valid(par->reset)) {
> - ret = -EINVAL;
> - goto reset_oled_error;
> - }
> -
> ret = devm_gpio_request_one(&client->dev, par->reset,
> GPIOF_OUT_INIT_HIGH,
> "oled-reset");
> @@ -293,23 +449,6 @@ static int ssd1307fb_probe(struct i2c_client *client,
> goto reset_oled_error;
> }
>
> - par->pwm = pwm_get(&client->dev, NULL);
> - if (IS_ERR(par->pwm)) {
> - dev_err(&client->dev, "Could not get PWM from device tree!\n");
> - ret = PTR_ERR(par->pwm);
> - goto pwm_error;
> - }
> -
> - par->pwm_period = pwm_get_period(par->pwm);
> -
> - dev_dbg(&client->dev, "Using PWM%d with a %dns period.\n", par->pwm->pwm, par->pwm_period);
> -
> - ret = register_framebuffer(info);
> - if (ret) {
> - dev_err(&client->dev, "Couldn't register the framebuffer\n");
> - goto fbreg_error;
> - }
> -
> i2c_set_clientdata(client, info);
>
> /* Reset the screen */
> @@ -318,34 +457,25 @@ static int ssd1307fb_probe(struct i2c_client *client,
> gpio_set_value(par->reset, 1);
> udelay(4);
>
> - /* Enable the PWM */
> - pwm_config(par->pwm, par->pwm_period / 2, par->pwm_period);
> - pwm_enable(par->pwm);
> -
> - /* Map column 127 of the OLED to segment 0 */
> - ret = ssd1307fb_write_cmd(client, SSD1307FB_SEG_REMAP_ON);
> - if (ret < 0) {
> - dev_err(&client->dev, "Couldn't remap the screen.\n");
> - goto remap_error;
> + if (par->ops->init) {
> + ret = par->ops->init(par);
> + if (ret)
> + goto reset_oled_error;
> }
>
> - /* Turn on the display */
> - ret = ssd1307fb_write_cmd(client, SSD1307FB_DISPLAY_ON);
> - if (ret < 0) {
> - dev_err(&client->dev, "Couldn't turn the display on.\n");
> - goto remap_error;
> + ret = register_framebuffer(info);
> + if (ret) {
> + dev_err(&client->dev, "Couldn't register the framebuffer\n");
> + goto panel_init_error;
> }
>
> dev_info(&client->dev, "fb%d: %s framebuffer device registered, using %d bytes of video memory\n", info->node, info->fix.id, vmem_size);
>
> return 0;
>
> -remap_error:
> - unregister_framebuffer(info);
> - pwm_disable(par->pwm);
> -fbreg_error:
> - pwm_put(par->pwm);
> -pwm_error:
> +panel_init_error:
> + if (par->ops->remove)
> + par->ops->remove(par);
> reset_oled_error:
> fb_deferred_io_cleanup(info);
> fb_alloc_error:
> @@ -359,8 +489,8 @@ static int ssd1307fb_remove(struct i2c_client *client)
> struct ssd1307fb_par *par = info->par;
>
> unregister_framebuffer(info);
> - pwm_disable(par->pwm);
> - pwm_put(par->pwm);
> + if (par->ops->remove)
> + par->ops->remove(par);
> fb_deferred_io_cleanup(info);
> framebuffer_release(info);
>
> @@ -368,17 +498,12 @@ static int ssd1307fb_remove(struct i2c_client *client)
> }
>
> static const struct i2c_device_id ssd1307fb_i2c_id[] = {
> + { "ssd1306fb", 0 },
> { "ssd1307fb", 0 },
> { }
> };
> MODULE_DEVICE_TABLE(i2c, ssd1307fb_i2c_id);
>
> -static const struct of_device_id ssd1307fb_of_match[] = {
> - { .compatible = "solomon,ssd1307fb-i2c" },
> - {},
> -};
> -MODULE_DEVICE_TABLE(of, ssd1307fb_of_match);
> -
> static struct i2c_driver ssd1307fb_driver = {
> .probe = ssd1307fb_probe,
> .remove = ssd1307fb_remove,
> --
> 1.7.10.4
>
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
^ permalink raw reply
* Re: [PATCH 1/1] video: fbomn: fix type VESA_DMT_VSYNC_HIGH
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-03-29 18:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <002801ce2c1c$e93564a0$bba02de0$%han@samsung.com>
On 10:29 Fri 29 Mar , Jingoo Han wrote:
> On Friday, March 29, 2013 6:03 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >
> > it's VESA_DMT_VSYNC_HIGH not VESA_DMT_HSYNC_HIGH
> > to check to enable the FB_SYNC_VERT_HIGH_ACT
> >
> > Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Cc: linux-fbdev@vger.kernel.org
>
> CC'ed Steffen Trumtrar.
>
> The same patch was already submitted as below:
> (https://patchwork.kernel.org/patch/2183811/)
>
> I will resend this patch, soon.
did not see ok
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
so
Best Regards,
J.
^ permalink raw reply
* Re: [PATCH RESEND] fbmon: use VESA_DMT_VSYNC_HIGH to fix typo
From: Steffen Trumtrar @ 2013-03-29 8:41 UTC (permalink / raw)
To: Jingoo Han
Cc: akpm, linux-kernel, linux-fbdev, tomi.valkeinen,
FlorianSchandinat, plagnioj
In-Reply-To: <8984685.165951364521249756.JavaMail.weblogic@epml18>
On Fri, Mar 29, 2013 at 01:40:52AM +0000, Jingoo Han wrote:
> VESA_DMT_VSYNC_HIGH should be used instead of VESA_DMT_HSYNC_HIGH,
> because FB_SYNC_VERT_HIGH_ACT is related to vsync, not to hsync.
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
> Cc: Steffen Trumtrar <s.trumtrar@pengutronix.de>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> drivers/video/fbmon.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
> index 94ad0f7..7f67099 100644
> --- a/drivers/video/fbmon.c
> +++ b/drivers/video/fbmon.c
> @@ -1400,7 +1400,7 @@ int fb_videomode_from_videomode(const struct videomode *vm,
> fbmode->vmode = 0;
> if (vm->dmt_flags & VESA_DMT_HSYNC_HIGH)
> fbmode->sync |= FB_SYNC_HOR_HIGH_ACT;
> - if (vm->dmt_flags & VESA_DMT_HSYNC_HIGH)
> + if (vm->dmt_flags & VESA_DMT_VSYNC_HIGH)
> fbmode->sync |= FB_SYNC_VERT_HIGH_ACT;
> if (vm->data_flags & DISPLAY_FLAGS_INTERLACED)
> fbmode->vmode |= FB_VMODE_INTERLACED;
> --
> 1.7.2.5
Hi,
I already implied this on the original mail, but to be clear:
Acked-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Thanks,
Steffen
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH] compat/compat-drivers/linux-next: fb skip_vt_switch
From: Luis R. Rodriguez @ 2013-03-29 7:29 UTC (permalink / raw)
To: Julia Lawall
Cc: Jesse Barnes, florianschandinat, linux-fbdev, dri-devel,
backports@vger.kernel.org, cocci, linux-kernel@vger.kernel.org,
rodrigo.vivi, Daniel Vetter, rafael.j.wysocki
In-Reply-To: <alpine.DEB.2.02.1303290720350.2023@localhost6.localdomain6>
On Thu, Mar 28, 2013 at 11:21 PM, Julia Lawall <julia.lawall@lip6.fr> wrote:
>> > I looked in today's linux-next, and there seems to be only one
>> > initialization of this field, to true, and one test of this field. So
>> > perhaps the case for setting the field to false just isn't needed.
>>
>> Oh sorry now I get what you mean! I thought about this -- and yes I
>> decided to not add a bool false setting for the structure field given
>> that the assumption is this would not be something dynamic, and data
>> structure would be kzalloc()'d so by default they are 0.
>
> What do you do about the test, though?
Return the value.
Luis
^ permalink raw reply
* Re: [PATCH] compat/compat-drivers/linux-next: fb skip_vt_switch
From: Julia Lawall @ 2013-03-29 6:21 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Julia Lawall, Jesse Barnes, florianschandinat, linux-fbdev,
dri-devel, backports@vger.kernel.org, cocci,
linux-kernel@vger.kernel.org, rodrigo.vivi, Daniel Vetter,
rafael.j.wysocki
In-Reply-To: <CAB=NE6WX5Dv9p2jrNwe9GxfH=EUm596uvSspsLQ5-Uuonc6Fqg@mail.gmail.com>
> > I looked in today's linux-next, and there seems to be only one
> > initialization of this field, to true, and one test of this field. So
> > perhaps the case for setting the field to false just isn't needed.
>
> Oh sorry now I get what you mean! I thought about this -- and yes I
> decided to not add a bool false setting for the structure field given
> that the assumption is this would not be something dynamic, and data
> structure would be kzalloc()'d so by default they are 0.
What do you do about the test, though?
julia
^ permalink raw reply
* [PATCH RESEND] fbmon: use VESA_DMT_VSYNC_HIGH to fix typo
From: Jingoo Han @ 2013-03-29 1:40 UTC (permalink / raw)
To: akpm
Cc: linux-kernel, linux-fbdev, tomi.valkeinen, FlorianSchandinat,
s.trumtrar, plagnioj, jg1.han
VkVTQV9ETVRfVlNZTkNfSElHSCBzaG91bGQgYmUgdXNlZCBpbnN0ZWFkIG9mIFZFU0FfRE1UX0hT
WU5DX0hJR0gsDQpiZWNhdXNlIEZCX1NZTkNfVkVSVF9ISUdIX0FDVCBpcyByZWxhdGVkIHRvIHZz
eW5jLCBub3QgdG8gaHN5bmMuDQoNClNpZ25lZC1vZmYtYnk6IEppbmdvbyBIYW4gPGpnMS5oYW5A
c2Ftc3VuZy5jb20+DQpDYzogU3RlZmZlbiBUcnVtdHJhciA8cy50cnVtdHJhckBwZW5ndXRyb25p
eC5kZT4NCkNjOiBUb21pIFZhbGtlaW5lbiA8dG9taS52YWxrZWluZW5AdGkuY29tPg0KLS0tDQog
ZHJpdmVycy92aWRlby9mYm1vbi5jIHwgICAgMiArLQ0KIDEgZmlsZXMgY2hhbmdlZCwgMSBpbnNl
cnRpb25zKCspLCAxIGRlbGV0aW9ucygtKQ0KDQpkaWZmIC0tZ2l0IGEvZHJpdmVycy92aWRlby9m
Ym1vbi5jIGIvZHJpdmVycy92aWRlby9mYm1vbi5jDQppbmRleCA5NGFkMGY3Li43ZjY3MDk5IDEw
MDY0NA0KLS0tIGEvZHJpdmVycy92aWRlby9mYm1vbi5jDQorKysgYi9kcml2ZXJzL3ZpZGVvL2Zi
bW9uLmMNCkBAIC0xNDAwLDcgKzE0MDAsNyBAQCBpbnQgZmJfdmlkZW9tb2RlX2Zyb21fdmlkZW9t
b2RlKGNvbnN0IHN0cnVjdCB2aWRlb21vZGUgKnZtLA0KIAlmYm1vZGUtPnZtb2RlID0gMDsNCiAJ
aWYgKHZtLT5kbXRfZmxhZ3MgJiBWRVNBX0RNVF9IU1lOQ19ISUdIKQ0KIAkJZmJtb2RlLT5zeW5j
IHw9IEZCX1NZTkNfSE9SX0hJR0hfQUNUOw0KLQlpZiAodm0tPmRtdF9mbGFncyAmIFZFU0FfRE1U
X0hTWU5DX0hJR0gpDQorCWlmICh2bS0+ZG10X2ZsYWdzICYgVkVTQV9ETVRfVlNZTkNfSElHSCkN
CiAJCWZibW9kZS0+c3luYyB8PSBGQl9TWU5DX1ZFUlRfSElHSF9BQ1Q7DQogCWlmICh2bS0+ZGF0
YV9mbGFncyAmIERJU1BMQVlfRkxBR1NfSU5URVJMQUNFRCkNCiAJCWZibW9kZS0+dm1vZGUgfD0g
RkJfVk1PREVfSU5URVJMQUNFRDsNCi0tIA0KMS43LjIuNQ0K
^ permalink raw reply
* Re: [PATCH 1/1] video: fbomn: fix type VESA_DMT_VSYNC_HIGH
From: Jingoo Han @ 2013-03-29 1:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1364504606-2087-1-git-send-email-plagnioj@jcrosoft.com>
On Friday, March 29, 2013 6:03 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>
> it's VESA_DMT_VSYNC_HIGH not VESA_DMT_HSYNC_HIGH
> to check to enable the FB_SYNC_VERT_HIGH_ACT
>
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: linux-fbdev@vger.kernel.org
CC'ed Steffen Trumtrar.
The same patch was already submitted as below:
(https://patchwork.kernel.org/patch/2183811/)
I will resend this patch, soon.
Best regards,
Jingoo Han
> ---
> drivers/video/fbmon.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
> index 94ad0f7..7f67099 100644
> --- a/drivers/video/fbmon.c
> +++ b/drivers/video/fbmon.c
> @@ -1400,7 +1400,7 @@ int fb_videomode_from_videomode(const struct videomode *vm,
> fbmode->vmode = 0;
> if (vm->dmt_flags & VESA_DMT_HSYNC_HIGH)
> fbmode->sync |= FB_SYNC_HOR_HIGH_ACT;
> - if (vm->dmt_flags & VESA_DMT_HSYNC_HIGH)
> + if (vm->dmt_flags & VESA_DMT_VSYNC_HIGH)
> fbmode->sync |= FB_SYNC_VERT_HIGH_ACT;
> if (vm->data_flags & DISPLAY_FLAGS_INTERLACED)
> fbmode->vmode |= FB_VMODE_INTERLACED;
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] compat/compat-drivers/linux-next: fb skip_vt_switch
From: Luis R. Rodriguez @ 2013-03-28 23:25 UTC (permalink / raw)
To: Julia Lawall
Cc: Jesse Barnes, florianschandinat, linux-fbdev, dri-devel,
backports@vger.kernel.org, cocci, linux-kernel@vger.kernel.org,
rodrigo.vivi, Daniel Vetter, rafael.j.wysocki
In-Reply-To: <alpine.DEB.2.02.1303282328200.2022@localhost6.localdomain6>
On Thu, Mar 28, 2013 at 3:29 PM, Julia Lawall <julia.lawall@lip6.fr> wrote:
> On Thu, 28 Mar 2013, Luis R. Rodriguez wrote:
>
>> On Thu, Mar 28, 2013 at 11:10 AM, Julia Lawall <julia.lawall@lip6.fr> wrote:
>> > On Thu, 28 Mar 2013, Luis R. Rodriguez wrote:
>> >>
>> >> Thanks Julia! I'll be sure to try to add this to compat-drivers if the
>> >> upstream fb patch is not accepted. If it is accepted we would not need
>> >> this at all!
>> >>
>> >> > Then I guess there would be a similar rule for the false case?
>> >>
>> >> Nope, see that's the proactive strategy taken by the static inline and
>> >> hence the patch. compat would have a static inline for both cases, and
>> >> for the false case it'd be a no-op. If accepted upstream though then
>> >> we would not need any changes for this collateral evolution. However
>> >> *spotting* these collateral evolutions and giving you SmPL for them as
>> >> a proactive strategy might be good given that if these type of patches
>> >> are indeed welcomed upstream we'd then be able to address these as
>> >> secondary steps. If they are not accepted then indeed we'd use them to
>> >> backport that collateral evolution through both compat (adds the
>> >> static inlines) and compat-drivers (the SmPL).
>> >
>> > Probably I am missing something, since I haven't looked at the code in
>> > detail, bu wouldn't it be nicer to have a function call for the false
>> > case, if there is a function call for the true case?
>>
>> Yes, and indeed we have that, its the same function call, in the
>> negative case its a no-op, in the newer kernels it wraps to modifying
>> the element as in the original code.
>>
>> > In looking at the
>> > code, one could wonder why things are not done in a parallel way.
>>
>> Not sure I get this.
>
> I looked in today's linux-next, and there seems to be only one
> initialization of this field, to true, and one test of this field. So
> perhaps the case for setting the field to false just isn't needed.
Oh sorry now I get what you mean! I thought about this -- and yes I
decided to not add a bool false setting for the structure field given
that the assumption is this would not be something dynamic, and data
structure would be kzalloc()'d so by default they are 0.
Luis
^ permalink raw reply
* Re: [PATCH] compat/compat-drivers/linux-next: fb skip_vt_switch
From: Julia Lawall @ 2013-03-28 22:29 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Julia Lawall, Jesse Barnes, florianschandinat, linux-fbdev,
dri-devel, backports@vger.kernel.org, cocci,
linux-kernel@vger.kernel.org, rodrigo.vivi, Daniel Vetter,
rafael.j.wysocki
In-Reply-To: <CAB=NE6VPRu8DvneVdwd=pXF0ngi5OifNTpZtX3pLi50i116_OA@mail.gmail.com>
On Thu, 28 Mar 2013, Luis R. Rodriguez wrote:
> On Thu, Mar 28, 2013 at 11:10 AM, Julia Lawall <julia.lawall@lip6.fr> wrote:
> > On Thu, 28 Mar 2013, Luis R. Rodriguez wrote:
> >>
> >> Thanks Julia! I'll be sure to try to add this to compat-drivers if the
> >> upstream fb patch is not accepted. If it is accepted we would not need
> >> this at all!
> >>
> >> > Then I guess there would be a similar rule for the false case?
> >>
> >> Nope, see that's the proactive strategy taken by the static inline and
> >> hence the patch. compat would have a static inline for both cases, and
> >> for the false case it'd be a no-op. If accepted upstream though then
> >> we would not need any changes for this collateral evolution. However
> >> *spotting* these collateral evolutions and giving you SmPL for them as
> >> a proactive strategy might be good given that if these type of patches
> >> are indeed welcomed upstream we'd then be able to address these as
> >> secondary steps. If they are not accepted then indeed we'd use them to
> >> backport that collateral evolution through both compat (adds the
> >> static inlines) and compat-drivers (the SmPL).
> >
> > Probably I am missing something, since I haven't looked at the code in
> > detail, bu wouldn't it be nicer to have a function call for the false
> > case, if there is a function call for the true case?
>
> Yes, and indeed we have that, its the same function call, in the
> negative case its a no-op, in the newer kernels it wraps to modifying
> the element as in the original code.
>
> > In looking at the
> > code, one could wonder why things are not done in a parallel way.
>
> Not sure I get this.
I looked in today's linux-next, and there seems to be only one
initialization of this field, to true, and one test of this field. So
perhaps the case for setting the field to false just isn't needed.
julia
^ permalink raw reply
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