* Re: [PATCH 13/13] video: omap: allow building on !MMU
From: Tony Lindgren @ 2014-05-08 21:53 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Peter Griffin, Arnd Bergmann, linux-kernel, linaro-kernel,
Jean-Christophe Plagniol-Villard, linux-fbdev, linux-omap,
Aaro Koskinen, Janusz Krzysztofik
In-Reply-To: <5369F973.10803@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140507 02:15]:
> On 24/04/14 15:28, Peter Griffin wrote:
> > From: Arnd Bergmann <arnd@arndb.de>
> >
> > The omap lcdc driver has an elaborate mmap_kern function
> > to map the frame buffer into kernel address space as
> > write-combined. This uses functions that are only available
> > on MMU-enabled builds.
> >
> > It does seem equivalent to ioremap_wc though, so we should
> > be able to just use that instead.
> >
> > This patch is build-tested only, it needs to be run on real
> > hardware before applying.
>
> I don't have omap1 boards, and I don't know anyone that has. I don't
> even know if the omap1 fb is working or not...
>
> Tony, any idea of omap1's fb? Are you able to test this?
I have three omap1 boards in my rack that I use for my boot
testing. Tried to enable framebuffer but so far no luck on
any of them. So I'm not much of a help here. Looks like the
patch should work though..
Aaro & Janusz, care to take a look at the patch in this
thread?
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 13/13] video: omap: allow building on !MMU
From: Aaro Koskinen @ 2014-05-08 23:04 UTC (permalink / raw)
To: Tony Lindgren
Cc: Tomi Valkeinen, Peter Griffin, Arnd Bergmann, linux-kernel,
linaro-kernel, Jean-Christophe Plagniol-Villard, linux-fbdev,
linux-omap, Janusz Krzysztofik
In-Reply-To: <20140508215338.GE2198@atomide.com>
Hi,
On Thu, May 08, 2014 at 02:53:38PM -0700, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [140507 02:15]:
> > I don't have omap1 boards, and I don't know anyone that has. I don't
> > even know if the omap1 fb is working or not...
OMAP1 fb is working very well. As a matter of fact, it's much more usable
for me than fb on OMAP2/3 - apart from N900 (on which fb is working again
with 3.15) none of my 4 other OMAP2/3 boards have a working display/fb
in mainline yet. :-(
> > Tony, any idea of omap1's fb? Are you able to test this?
>
> I have three omap1 boards in my rack that I use for my boot
> testing. Tried to enable framebuffer but so far no luck on
> any of them. So I'm not much of a help here. Looks like the
> patch should work though..
>
> Aaro & Janusz, care to take a look at the patch in this
> thread?
I couldn't figure out how to enter this code path. Amstrad E3 & Nokia
770 will take the alloc_fbmem() path & exit, and based on quick look
I could not see way to enter mmap_kern(). Is that dead code?
A.
^ permalink raw reply
* Re: [PATCH 13/13] video: omap: allow building on !MMU
From: Tony Lindgren @ 2014-05-08 23:17 UTC (permalink / raw)
To: Aaro Koskinen
Cc: Tomi Valkeinen, Peter Griffin, Arnd Bergmann, linux-kernel,
linaro-kernel, Jean-Christophe Plagniol-Villard, linux-fbdev,
linux-omap, Janusz Krzysztofik
In-Reply-To: <20140508230415.GA6670@drone.musicnaut.iki.fi>
* Aaro Koskinen <aaro.koskinen@iki.fi> [140508 16:09]:
> Hi,
>
> On Thu, May 08, 2014 at 02:53:38PM -0700, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [140507 02:15]:
> > > I don't have omap1 boards, and I don't know anyone that has. I don't
> > > even know if the omap1 fb is working or not...
>
> OMAP1 fb is working very well. As a matter of fact, it's much more usable
> for me than fb on OMAP2/3 - apart from N900 (on which fb is working again
> with 3.15) none of my 4 other OMAP2/3 boards have a working display/fb
> in mainline yet. :-(
I hear you.. What do you have in the .config for omap1?
Would be nice to enable the framebuffer in omap1_defconfig?
> > > Tony, any idea of omap1's fb? Are you able to test this?
> >
> > I have three omap1 boards in my rack that I use for my boot
> > testing. Tried to enable framebuffer but so far no luck on
> > any of them. So I'm not much of a help here. Looks like the
> > patch should work though..
> >
> > Aaro & Janusz, care to take a look at the patch in this
> > thread?
>
> I couldn't figure out how to enter this code path. Amstrad E3 & Nokia
> 770 will take the alloc_fbmem() path & exit, and based on quick look
> I could not see way to enter mmap_kern(). Is that dead code?
Could be. It may be something left from when we had code to keep
the bootloader logo displayed while booting kernel.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
From: Tony Lindgren @ 2014-05-08 23:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1398815562-24113-2-git-send-email-tony@atomide.com>
* Tony Lindgren <tony@atomide.com> [140429 16:53]:
> Otherwise we can get often errors like the following and the
> display won't come on:
>
> omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay
> omapdss APPLY error: SYNC_LOST on channel lcd, restarting
> the output with video overlays disabled
>
> There are some earlier references to this issue:
>
> http://www.spinics.net/lists/linux-omap/msg59511.html
> http://www.spinics.net/lists/linux-omap/msg59724.html
>
> It seems that it's safe to set the lower values even for 3630.
> If we can confirm that 3630 works with the higher values
> reliably we can add further detection.
BTW, I'm also seeing this warning on 3730-evm it may be related:
[ 3.523101] ------------[ cut here ]------------
[ 3.528015] WARNING: CPU: 0 PID: 6 at drivers/video/fbdev/omap2/dss/dss.c:483 dss_set_fck_rate+0x6c/0x8c()
[ 3.538360] clk rate mismatch: 108000000 != 115200000
[ 3.543518] Modules linked in:
[ 3.546966] CPU: 0 PID: 6 Comm: kworker/u2:0 Tainted: G W 3.15.0-rc3-00015-gaa296fa-dirty #391
[ 3.557159] Workqueue: deferwq deferred_probe_work_func
[ 3.562774] [<c0014cbc>] (unwind_backtrace) from [<c001191c>] (show_stack+0x10/0x14)
[ 3.571014] [<c001191c>] (show_stack) from [<c05660b4>] (dump_stack+0x80/0x9c)
[ 3.578704] [<c05660b4>] (dump_stack) from [<c003f558>] (warn_slowpath_common+0x68/0x8c)
[ 3.587249] [<c003f558>] (warn_slowpath_common) from [<c003f610>] (warn_slowpath_fmt+0x30/0x40)
[ 3.596496] [<c003f610>] (warn_slowpath_fmt) from [<c03129f0>] (dss_set_fck_rate+0x6c/0x8c)
[ 3.605407] [<c03129f0>] (dss_set_fck_rate) from [<c0323728>] (dpi_display_enable+0x23c/0x2e4)
[ 3.614562] [<c0323728>] (dpi_display_enable) from [<c03323a8>] (sharp_ls_enable+0x58/0xc4)
[ 3.623474] [<c03323a8>] (sharp_ls_enable) from [<c0335ee0>] (omapfb_probe+0x548/0x848)
[ 3.631988] [<c0335ee0>] (omapfb_probe) from [<c0378cfc>] (platform_drv_probe+0x18/0x48)
[ 3.640594] [<c0378cfc>] (platform_drv_probe) from [<c0377938>] (driver_probe_device+0x110/0x22c)
[ 3.650024] [<c0377938>] (driver_probe_device) from [<c0376038>] (bus_for_each_drv+0x44/0x8c)
[ 3.659088] [<c0376038>] (bus_for_each_drv) from [<c03777f0>] (device_attach+0x74/0x8c)
[ 3.667541] [<c03777f0>] (device_attach) from [<c0376ecc>] (bus_probe_device+0x88/0xb0)
[ 3.676025] [<c0376ecc>] (bus_probe_device) from [<c03772d0>] (deferred_probe_work_func+0x64/0x94)
[ 3.685546] [<c03772d0>] (deferred_probe_work_func) from [<c0057220>] (process_one_work+0x1b4/0x4bc)
[ 3.695251] [<c0057220>] (process_one_work) from [<c0057908>] (worker_thread+0x11c/0x398)
[ 3.704620] [<c0057908>] (worker_thread) from [<c005df10>] (kthread+0xc8/0xe4)
[ 3.712280] [<c005df10>] (kthread) from [<c000e768>] (ret_from_fork+0x14/0x2c)
[ 3.719909] ---[ end trace 1c9526c1a2975498 ]---
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> drivers/video/fbdev/omap2/dss/dss.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/fbdev/omap2/dss/dss.c b/drivers/video/fbdev/omap2/dss/dss.c
> index d55266c..ad6561f 100644
> --- a/drivers/video/fbdev/omap2/dss/dss.c
> +++ b/drivers/video/fbdev/omap2/dss/dss.c
> @@ -707,9 +707,10 @@ static const struct dss_features omap34xx_dss_feats __initconst = {
> .dpi_select_source = &dss_dpi_select_source_omap2_omap3,
> };
>
> +/* Supposedly 3630 can use div 32 mult 2, but that needs to be rechecked */
> static const struct dss_features omap3630_dss_feats __initconst = {
> - .fck_div_max = 32,
> - .dss_fck_multiplier = 1,
> + .fck_div_max = 16,
> + .dss_fck_multiplier = 2,
> .parent_clk_name = "dpll4_ck",
> .dpi_select_source = &dss_dpi_select_source_omap2_omap3,
> };
> --
> 1.8.1.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" 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 2/4] OMAPDSS: panel-sharp-ls037v7dw01: update to use gpiod
From: Tony Lindgren @ 2014-05-08 23:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5369EB90.8060007@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140507 01:15]:
> On 30/04/14 02:52, Tony Lindgren wrote:
> > +static struct gpio_desc *
> > +sharp_ls_get_gpio(struct device *dev, int gpio, unsigned long flags,
> > + char *desc)
> > +{
> > + int r;
> > +
> > + r = devm_gpio_request_one(dev, gpio, flags, desc);
> > + if (r) {
> > + dev_err(dev, "no %s gpio\n", desc);
>
> As it's fine to not have a gpio, I guess this error print should be removed.
OK I made it a dev_dbg, it may help somebody while
configuring the panel.
> Also, if the error is EPROBE_DEFER, the driver should fail and return
> that. The same goes for the DT version in the next patch.
Good catch. It's a bit unfortunate that all drivers have to
sprinkle EPROBE_DEFER handling all over the place, that issue
is really caused by a missing resource management layer at
the bus level :(
Below is the updated patch, please feel free to pick if OK.
Regards,
Tony
8<---------------
From: Tony Lindgren <tony@atomide.com>
Date: Mon, 28 Apr 2014 20:22:20 -0700
Subject: [PATCH] OMAPDSS: panel-sharp-ls037v7dw01: update to use gpiod
Using gpiod will make it easier to add device tree support
for this panel in the following patches.
Note that all the GPIOs for this panel are optional, any
of the the GPIOs could be configured with external pulls
instead of GPIOs, so let's not error out if GPIOs are not
found to make the panel more generic.
Signed-off-by: Tony Lindgren <tony@atomide.com>
--- a/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
@@ -26,11 +26,11 @@ struct panel_drv_data {
struct omap_video_timings videomode;
- int resb_gpio;
- int ini_gpio;
- int mo_gpio;
- int lr_gpio;
- int ud_gpio;
+ struct gpio_desc *resb_gpio; /* low = reset active min 20 us */
+ struct gpio_desc *ini_gpio; /* high = power on */
+ struct gpio_desc *mo_gpio; /* low = 480x640, high = 240x320 */
+ struct gpio_desc *lr_gpio; /* high = conventional horizontal scanning */
+ struct gpio_desc *ud_gpio; /* high = conventional vertical scanning */
};
static const struct omap_video_timings sharp_ls_timings = {
@@ -105,11 +105,11 @@ static int sharp_ls_enable(struct omap_dss_device *dssdev)
/* wait couple of vsyncs until enabling the LCD */
msleep(50);
- if (gpio_is_valid(ddata->resb_gpio))
- gpio_set_value_cansleep(ddata->resb_gpio, 1);
+ if (!IS_ERR(ddata->resb_gpio))
+ gpiod_set_value_cansleep(ddata->resb_gpio, 1);
- if (gpio_is_valid(ddata->ini_gpio))
- gpio_set_value_cansleep(ddata->ini_gpio, 1);
+ if (!IS_ERR(ddata->ini_gpio))
+ gpiod_set_value_cansleep(ddata->ini_gpio, 1);
dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
@@ -124,11 +124,11 @@ static void sharp_ls_disable(struct omap_dss_device *dssdev)
if (!omapdss_device_is_enabled(dssdev))
return;
- if (gpio_is_valid(ddata->ini_gpio))
- gpio_set_value_cansleep(ddata->ini_gpio, 0);
+ if (!IS_ERR(ddata->ini_gpio))
+ gpiod_set_value_cansleep(ddata->ini_gpio, 0);
- if (gpio_is_valid(ddata->resb_gpio))
- gpio_set_value_cansleep(ddata->resb_gpio, 0);
+ if (!IS_ERR(ddata->resb_gpio))
+ gpiod_set_value_cansleep(ddata->resb_gpio, 0);
/* wait at least 5 vsyncs after disabling the LCD */
@@ -182,6 +182,21 @@ static struct omap_dss_driver sharp_ls_ops = {
.get_resolution = omapdss_default_get_resolution,
};
+static struct gpio_desc *
+sharp_ls_get_gpio(struct device *dev, int gpio, unsigned long flags,
+ char *desc)
+{
+ int r;
+
+ r = devm_gpio_request_one(dev, gpio, flags, desc);
+ if (r) {
+ dev_dbg(dev, "no %s gpio\n", desc);
+ return ERR_PTR(r);
+ }
+
+ return gpio_to_desc(gpio);
+}
+
static int sharp_ls_probe_pdata(struct platform_device *pdev)
{
const struct panel_sharp_ls037v7dw01_platform_data *pdata;
@@ -204,11 +219,26 @@ static int sharp_ls_probe_pdata(struct platform_device *pdev)
dssdev = &ddata->dssdev;
dssdev->name = pdata->name;
- ddata->resb_gpio = pdata->resb_gpio;
- ddata->ini_gpio = pdata->ini_gpio;
- ddata->mo_gpio = pdata->mo_gpio;
- ddata->lr_gpio = pdata->lr_gpio;
- ddata->ud_gpio = pdata->ud_gpio;
+ ddata->mo_gpio = sharp_ls_get_gpio(&pdev->dev, pdata->mo_gpio,
+ GPIOF_OUT_INIT_LOW, "lcd MO");
+ if (PTR_ERR(ddata->mo_gpio) = -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ ddata->lr_gpio = sharp_ls_get_gpio(&pdev->dev, pdata->lr_gpio,
+ GPIOF_OUT_INIT_HIGH, "lcd LR");
+ if (PTR_ERR(ddata->lr_gpio) = -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ ddata->ud_gpio = sharp_ls_get_gpio(&pdev->dev, pdata->ud_gpio,
+ GPIOF_OUT_INIT_HIGH, "lcd UD");
+ if (PTR_ERR(ddata->ud_gpio) = -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ ddata->resb_gpio = sharp_ls_get_gpio(&pdev->dev, pdata->resb_gpio,
+ GPIOF_OUT_INIT_LOW, "lcd RESB");
+ if (PTR_ERR(ddata->resb_gpio) = -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ ddata->ini_gpio = sharp_ls_get_gpio(&pdev->dev, pdata->ini_gpio,
+ GPIOF_OUT_INIT_LOW, "lcd INI");
+ if (PTR_ERR(ddata->ini_gpio) = -EPROBE_DEFER)
+ return -EPROBE_DEFER;
return 0;
}
@@ -233,41 +263,6 @@ static int sharp_ls_probe(struct platform_device *pdev)
return -ENODEV;
}
- if (gpio_is_valid(ddata->mo_gpio)) {
- r = devm_gpio_request_one(&pdev->dev, ddata->mo_gpio,
- GPIOF_OUT_INIT_LOW, "lcd MO");
- if (r)
- goto err_gpio;
- }
-
- if (gpio_is_valid(ddata->lr_gpio)) {
- r = devm_gpio_request_one(&pdev->dev, ddata->lr_gpio,
- GPIOF_OUT_INIT_HIGH, "lcd LR");
- if (r)
- goto err_gpio;
- }
-
- if (gpio_is_valid(ddata->ud_gpio)) {
- r = devm_gpio_request_one(&pdev->dev, ddata->ud_gpio,
- GPIOF_OUT_INIT_HIGH, "lcd UD");
- if (r)
- goto err_gpio;
- }
-
- if (gpio_is_valid(ddata->resb_gpio)) {
- r = devm_gpio_request_one(&pdev->dev, ddata->resb_gpio,
- GPIOF_OUT_INIT_LOW, "lcd RESB");
- if (r)
- goto err_gpio;
- }
-
- if (gpio_is_valid(ddata->ini_gpio)) {
- r = devm_gpio_request_one(&pdev->dev, ddata->ini_gpio,
- GPIOF_OUT_INIT_LOW, "lcd INI");
- if (r)
- goto err_gpio;
- }
-
ddata->videomode = sharp_ls_timings;
dssdev = &ddata->dssdev;
@@ -287,7 +282,6 @@ static int sharp_ls_probe(struct platform_device *pdev)
return 0;
err_reg:
-err_gpio:
omap_dss_put_device(ddata->in);
return r;
}
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tony Lindgren @ 2014-05-08 23:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140507175919.GH9502@atomide.com>
* Tony Lindgren <tony@atomide.com> [140507 11:00]:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [140507 09:03]:
> > On 07/05/14 18:03, Tony Lindgren wrote:
> > >
> > > BTW, I'm also personally fine with all five gpios showing in a single
> > > gpios property, I'm not too exited about naming anything in DT..
> >
> > I don't have a strong opinion here. I don't have much experience with
> > DT, especially with making bindings compatible with other ones.
> >
> > I'd just forget the simple-panel, and have single gpio array.
>
> Well if it's a don't care flag for both of us, let's try to use
> the existing standard for simple-panel.txt and add mode-gpios
> property. I'll post a patch for that.
Here's an updated version using enable-gpios, reset-gpios and
mode-gpios. So it follows simple-panel.txt and adds mode-gpios
that's currently specific to this panel only.
Also updated for -EPROBE_DEFER handling, tested that by changing
one of the GPIOs to be a twl4030 GPIO.
Regards,
Tony
8<------------------
From: Tony Lindgren <tony@atomide.com>
Date: Mon, 28 Apr 2014 20:22:21 -0700
Subject: [PATCH] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
We can pass the GPIO configuration for ls037v7dw01 in a standard
gpios property.
Signed-off-by: Tony Lindgren <tony@atomide.com>
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt
@@ -0,0 +1,56 @@
+SHARP LS037V7DW01 TFT-LCD panel
+
+Required properties:
+- compatible: should be "sharp,ls037v7dw01"
+
+Optional properties:
+- enable-gpios: a GPIO spec for the optional enable pin
+ this pin is the INI pin as specified in the LS037V7DW01.pdf file.
+- reset-gpios: a GPIO spec for the optional reset pin
+ this pin is the RESB pin as specified in the LS037V7DW01.pdf file.
+- mode-gpios: a GPIO
+ ordered MO, LR, and UD as specified in the LS037V7DW01.pdf file.
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
+
+This panel can have zero to five GPIOs to configure
+to change configuration between QVGA and VGA mode
+and the scan direction. As these pins can be also
+configured with external pulls, all the GPIOs are
+considered optional with holes in the array.
+
+Example when connected to a omap2+ based device:
+
+ lcd0: display {
+ compatible = "sharp,ls037v7dw01";
+ power-supply = <&lcd_3v3>;
+ enable-gpios = <&gpio5 24 GPIO_ACTIVE_HIGH>; /* gpio152, lcd INI */
+ reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>; /* gpio155, lcd RESB */
+ mode-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH /* gpio154, lcd MO */
+ &gpio1 2 GPIO_ACTIVE_HIGH /* gpio2, lcd LR */
+ &gpio1 3 GPIO_ACTIVE_HIGH>; /* gpio3, lcd UD */
+
+ panel-timing {
+ clock-frequency = <19200000>;
+ hback-porch = <28>;
+ hactive = <480>;
+ hfront-porch = <1>;
+ hsync-len = <2>;
+ vback-porch = <1>;
+ vactive = <640>;
+ vfront-porch = <1>;
+ vsync-len = <1>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ de-active = <1>;
+ pixelclk-active = <1>;
+ };
+
+ port {
+ lcd_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+ };
+
--- a/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
@@ -12,15 +12,19 @@
#include <linux/delay.h>
#include <linux/gpio.h>
#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
#include <linux/platform_device.h>
#include <linux/slab.h>
-
+#include <linux/regulator/consumer.h>
+#include <video/of_display_timing.h>
#include <video/omapdss.h>
#include <video/omap-panel-data.h>
struct panel_drv_data {
struct omap_dss_device dssdev;
struct omap_dss_device *in;
+ struct regulator *vcc;
int data_lines;
@@ -95,7 +99,8 @@ static int sharp_ls_enable(struct omap_dss_device *dssdev)
if (omapdss_device_is_enabled(dssdev))
return 0;
- in->ops.dpi->set_data_lines(in, ddata->data_lines);
+ if (ddata->data_lines)
+ in->ops.dpi->set_data_lines(in, ddata->data_lines);
in->ops.dpi->set_timings(in, &ddata->videomode);
r = in->ops.dpi->enable(in);
@@ -240,6 +245,88 @@ static int sharp_ls_probe_pdata(struct platform_device *pdev)
if (PTR_ERR(ddata->ini_gpio) = -EPROBE_DEFER)
return -EPROBE_DEFER;
+ ddata->videomode = sharp_ls_timings;
+
+ return 0;
+}
+
+static struct gpio_desc *
+sharp_ls_get_gpio_of(struct device *dev, int index, int val, char *desc)
+{
+ struct gpio_desc *gpio;
+
+ gpio = devm_gpiod_get_index(dev, desc, index);
+ if (IS_ERR(gpio))
+ return gpio;
+
+ gpiod_direction_output(gpio, val);
+
+ return gpio;
+}
+
+static int sharp_ls_probe_of(struct platform_device *pdev)
+{
+ struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct device_node *node = pdev->dev.of_node;
+ struct omap_dss_device *in;
+ struct display_timing timing;
+ struct videomode vm;
+ int r;
+
+ ddata->vcc = devm_regulator_get(&pdev->dev, "envdd");
+ if (IS_ERR(ddata->vcc)) {
+ dev_err(&pdev->dev, "failed to get regulator\n");
+ return PTR_ERR(ddata->vcc);
+ }
+
+ r = regulator_enable(ddata->vcc);
+ if (r != 0) {
+ dev_err(&pdev->dev, "failed to enable regulator\n");
+ return r;
+ }
+
+ /* lcd INI */
+ ddata->ini_gpio = sharp_ls_get_gpio_of(&pdev->dev, 3, 0, "enable");
+ if (PTR_ERR(ddata->ini_gpio) = -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+
+ /* lcd RESB */
+ ddata->resb_gpio = sharp_ls_get_gpio_of(&pdev->dev, 0, 0, "reset");
+ if (PTR_ERR(ddata->resb_gpio) = -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+
+ /* lcd MO */
+ ddata->mo_gpio = sharp_ls_get_gpio_of(&pdev->dev, 0, 0, "mode");
+ if (PTR_ERR(ddata->mo_gpio) = -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+
+ /* lcd LR */
+ ddata->lr_gpio = sharp_ls_get_gpio_of(&pdev->dev, 1, 1, "mode");
+ if (PTR_ERR(ddata->lr_gpio) = -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+
+ /* lcd UD */
+ ddata->ud_gpio = sharp_ls_get_gpio_of(&pdev->dev, 2, 1, "mode");
+ if (PTR_ERR(ddata->ud_gpio) = -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+
+ r = of_get_display_timing(node, "panel-timing", &timing);
+ if (r) {
+ dev_err(&pdev->dev, "failed to get video timing\n");
+ return r;
+ }
+
+ videomode_from_timing(&timing, &vm);
+ videomode_to_omap_video_timings(&vm, &ddata->videomode);
+
+ in = omapdss_of_find_source_for_first_ep(node);
+ if (IS_ERR(in)) {
+ dev_err(&pdev->dev, "failed to find video source\n");
+ return PTR_ERR(in);
+ }
+
+ ddata->in = in;
+
return 0;
}
@@ -259,12 +346,14 @@ static int sharp_ls_probe(struct platform_device *pdev)
r = sharp_ls_probe_pdata(pdev);
if (r)
return r;
+ } else if (pdev->dev.of_node) {
+ r = sharp_ls_probe_of(pdev);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
- ddata->videomode = sharp_ls_timings;
-
dssdev = &ddata->dssdev;
dssdev->dev = &pdev->dev;
dssdev->driver = &sharp_ls_ops;
@@ -302,12 +391,20 @@ static int __exit sharp_ls_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id sharp_ls_of_match[] = {
+ { .compatible = "sharp,ls037v7dw01", },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, sharp_ls_of_match);
+
static struct platform_driver sharp_ls_driver = {
.probe = sharp_ls_probe,
.remove = __exit_p(sharp_ls_remove),
.driver = {
.name = "panel-sharp-ls037v7dw01",
.owner = THIS_MODULE,
+ .of_match_table = sharp_ls_of_match,
},
};
^ permalink raw reply
* Re: [PATCH 4/4] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp
From: Tony Lindgren @ 2014-05-08 23:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140505183919.GA15463@atomide.com>
* Tony Lindgren <tony@atomide.com> [140505 11:40]:
> * Tony Lindgren <tony@atomide.com> [140430 10:48]:
> > * Joachim Eastwood <manabian@gmail.com> [140429 18:08]:
> > > On 30 April 2014 01:52, Tony Lindgren <tony@atomide.com> wrote:
> > > > + reset-gpios = <&gpio2 23 GPIO_ACTIVE_HIGH>; /* gpio55, lcd RESB */
> > > > + gpios = <&gpio2 24 GPIO_ACTIVE_LOW /* gpio56, lcd MO */
> > >
> > > enable-gpios ?
> >
> > Oops yes, changed from gpios to enable-gpios while reading the panel
> > binding doc, probably forgot to commit the change, will update.
>
> Here's an updated version of this one.
One more update for the use of enable-gpios, reset-gpios and
mode-gpios to follow the binding described in simple-panel.txt.
Tomi feel free to pick this one up too, I'd assume you prefer
to do an immutable branch for the .dts changes that we both
can merge in as needed.
Regards,
Tony
8<-------------------
From: Tony Lindgren <tony@atomide.com>
Date: Mon, 28 Apr 2014 20:22:21 -0700
Subject: [PATCH] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp
Looks like quite a few omaps have sharp ls037v7dw01 that's configured
as various panel dpi entries for whatever legacy reasons. For device
tree based support, let's just configure these properly for panel
ls037v7dw01 instead of panel dpi.
This patch creates a common file for panel ls037v7dw01, and makes
boards ldp and omap3-evm to use it. The panel for ldp is configured
in the qvga mode and omap3-evm panel in vga mode.
The ls037v7dw01 also seems to be coupled with an ad7846 touchscreen
controller for the omaps, so let's add a basic configuration for
the touchscreen also using the default values.
Note that we can now remove the regulator-name = "vdds_dsi"
entry for ldp, that's no longer needed as we have the entry
for vdds_dsi-supply = <&vpll2>.
Signed-off-by: Tony Lindgren <tony@atomide.com>
--- /dev/null
+++ b/arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
@@ -0,0 +1,82 @@
+/*
+ * Common file for omap dpi panels with QVGA and reset pins
+ *
+ * Note that the board specifc DTS file needs to specify
+ * at minimum the GPIO enable-gpios for display, and
+ * gpios for gpio-backlight.
+ */
+
+/ {
+ aliases {
+ display0 = &lcd0;
+ };
+
+ backlight0: backlight {
+ compatible = "gpio-backlight";
+ };
+
+ /* 3.3V GPIO controlled regulator for LCD_ENVDD */
+ lcd_3v3: regulator-lcd-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "lcd_3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ startup-delay-us = <70000>;
+ regulator-always-on;
+ };
+
+ lcd0: display {
+ compatible = "sharp,ls037v7dw01";
+ label = "lcd";
+ power-supply = <&lcd_3v3>;
+ panel-timing {
+ clock-frequency = <5400000>;
+ hback-porch = <39>;
+ hactive = <240>;
+ hfront-porch = <3>;
+ hsync-len = <3>;
+ vback-porch = <7>;
+ vactive = <320>;
+ vfront-porch = <2>;
+ vsync-len = <1>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ de-active = <1>;
+ pixelclk-active = <1>;
+ };
+
+ port {
+ lcd_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+ };
+};
+
+&dss {
+ status = "ok";
+ vdds_dsi-supply = <&vpll2>;
+ port {
+ dpi_out: endpoint {
+ remote-endpoint = <&lcd_in>;
+ data-lines = <18>;
+ };
+ };
+};
+
+&mcspi1 {
+ tsc2046@0 {
+ reg = <0>; /* CS0 */
+ compatible = "ti,tsc2046";
+ spi-max-frequency = <1000000>;
+ vcc-supply = <&lcd_3v3>;
+ ti,x-min = /bits/ 16 <0>;
+ ti,x-max = /bits/ 16 <8000>;
+ ti,y-min = /bits/ 16 <0>;
+ ti,y-max = /bits/ 16 <4800>;
+ ti,x-plate-ohms = /bits/ 16 <40>;
+ ti,pressure-max = /bits/ 16 <255>;
+ ti,swap-xy;
+ linux,wakeup;
+ };
+};
--- a/arch/arm/boot/dts/omap3-evm-37xx.dts
+++ b/arch/arm/boot/dts/omap3-evm-37xx.dts
@@ -26,7 +26,44 @@
};
};
+&dss {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ &dss_dpi_pins1
+ &dss_dpi_pins2
+ >;
+};
+
&omap3_pmx_core {
+ dss_dpi_pins1: pinmux_dss_dpi_pins2 {
+ pinctrl-single,pins = <
+ OMAP3_CORE1_IOPAD(0x20d4, PIN_OUTPUT | MUX_MODE0) /* dss_pclk.dss_pclk */
+ OMAP3_CORE1_IOPAD(0x20d6, PIN_OUTPUT | MUX_MODE0) /* dss_hsync.dss_hsync */
+ OMAP3_CORE1_IOPAD(0x20d8, PIN_OUTPUT | MUX_MODE0) /* dss_vsync.dss_vsync */
+ OMAP3_CORE1_IOPAD(0x20da, PIN_OUTPUT | MUX_MODE0) /* dss_acbias.dss_acbias */
+
+ OMAP3_CORE1_IOPAD(0x20e8, PIN_OUTPUT | MUX_MODE0) /* dss_data6.dss_data6 */
+ OMAP3_CORE1_IOPAD(0x20ea, PIN_OUTPUT | MUX_MODE0) /* dss_data7.dss_data7 */
+ OMAP3_CORE1_IOPAD(0x20ec, PIN_OUTPUT | MUX_MODE0) /* dss_data8.dss_data8 */
+ OMAP3_CORE1_IOPAD(0x20ee, PIN_OUTPUT | MUX_MODE0) /* dss_data9.dss_data9 */
+ OMAP3_CORE1_IOPAD(0x20f0, PIN_OUTPUT | MUX_MODE0) /* dss_data10.dss_data10 */
+ OMAP3_CORE1_IOPAD(0x20f2, PIN_OUTPUT | MUX_MODE0) /* dss_data11.dss_data11 */
+ OMAP3_CORE1_IOPAD(0x20f4, PIN_OUTPUT | MUX_MODE0) /* dss_data12.dss_data12 */
+ OMAP3_CORE1_IOPAD(0x20f6, PIN_OUTPUT | MUX_MODE0) /* dss_data13.dss_data13 */
+ OMAP3_CORE1_IOPAD(0x20f8, PIN_OUTPUT | MUX_MODE0) /* dss_data14.dss_data14 */
+ OMAP3_CORE1_IOPAD(0x20fa, PIN_OUTPUT | MUX_MODE0) /* dss_data15.dss_data15 */
+ OMAP3_CORE1_IOPAD(0x20fc, PIN_OUTPUT | MUX_MODE0) /* dss_data16.dss_data16 */
+ OMAP3_CORE1_IOPAD(0x20fe, PIN_OUTPUT | MUX_MODE0) /* dss_data17.dss_data17 */
+
+ OMAP3_CORE1_IOPAD(0x2100, PIN_OUTPUT | MUX_MODE3) /* dss_data18.dss_data0 */
+ OMAP3_CORE1_IOPAD(0x2102, PIN_OUTPUT | MUX_MODE3) /* dss_data19.dss_data1 */
+ OMAP3_CORE1_IOPAD(0x2104, PIN_OUTPUT | MUX_MODE3) /* dss_data20.dss_data2 */
+ OMAP3_CORE1_IOPAD(0x2106, PIN_OUTPUT | MUX_MODE3) /* dss_data21.dss_data3 */
+ OMAP3_CORE1_IOPAD(0x2108, PIN_OUTPUT | MUX_MODE3) /* dss_data22.dss_data4 */
+ OMAP3_CORE1_IOPAD(0x210a, PIN_OUTPUT | MUX_MODE3) /* dss_data23.dss_data5 */
+ >;
+ };
+
mmc1_pins: pinmux_mmc1_pins {
pinctrl-single,pins = <
0x114 (PIN_OUTPUT_PULLUP | MUX_MODE0) /* sdmmc1_clk.sdmmc1_clk */
@@ -75,6 +112,19 @@
};
};
+&omap3_pmx_wkup {
+ dss_dpi_pins2: pinmux_dss_dpi_pins1 {
+ pinctrl-single,pins = <
+ 0x0a (PIN_OUTPUT | MUX_MODE3) /* sys_boot0.dss_data18 */
+ 0x0c (PIN_OUTPUT | MUX_MODE3) /* sys_boot1.dss_data19 */
+ 0x10 (PIN_OUTPUT | MUX_MODE3) /* sys_boot3.dss_data20 */
+ 0x12 (PIN_OUTPUT | MUX_MODE3) /* sys_boot4.dss_data21 */
+ 0x14 (PIN_OUTPUT | MUX_MODE3) /* sys_boot5.dss_data22 */
+ 0x16 (PIN_OUTPUT | MUX_MODE3) /* sys_boot6.dss_data23 */
+ >;
+ };
+};
+
&mmc1 {
pinctrl-names = "default";
pinctrl-0 = <&mmc1_pins>;
--- a/arch/arm/boot/dts/omap3-evm-common.dtsi
+++ b/arch/arm/boot/dts/omap3-evm-common.dtsi
@@ -44,6 +44,11 @@
#include "twl4030.dtsi"
#include "twl4030_omap3.dtsi"
+#include "omap-panel-sharp-ls037v7dw01.dtsi"
+
+&backlight0 {
+ gpios = <&twl_gpio 18 GPIO_ACTIVE_HIGH>;
+};
&i2c2 {
clock-frequency = <400000>;
@@ -61,6 +66,48 @@
};
};
+&lcd_3v3 {
+ gpio = <&gpio5 25 GPIO_ACTIVE_LOW>; /* gpio153 */
+ enable-active-low;
+};
+
+&lcd0 {
+ enable-gpios = <&gpio5 24 GPIO_ACTIVE_HIGH>; /* gpio152, lcd INI */
+ reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>; /* gpio155, lcd RESB */
+ /*
+ * The LCD is sideways, so we want the VGA mode instead of
+ * QVGA mode. Probably also want to have omapfb.rotate=3
+ * in the kernel cmdline until there's a binding for that.
+ */
+ mode-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH /* gpio154, lcd MO */
+ &gpio1 2 GPIO_ACTIVE_HIGH /* gpio2, lcd LR */
+ &gpio1 3 GPIO_ACTIVE_HIGH>; /* gpio3, lcd UD */
+
+ panel-timing {
+ clock-frequency = <19200000>;
+ hback-porch = <28>;
+ hactive = <480>;
+ hfront-porch = <1>;
+ hsync-len = <2>;
+ vback-porch = <1>;
+ vactive = <640>;
+ vfront-porch = <1>;
+ vsync-len = <1>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ de-active = <1>;
+ pixelclk-active = <1>;
+ };
+};
+
+&mcspi1 {
+ tsc2046@0 {
+ interrupt-parent = <&gpio6>;
+ interrupts = <15 0>; /* gpio175 */
+ pendown-gpio = <&gpio6 15 0>;
+ };
+};
+
&mmc1 {
vmmc-supply = <&vmmc1>;
vmmc_aux-supply = <&vsim>;
--- a/arch/arm/boot/dts/omap3-ldp.dts
+++ b/arch/arm/boot/dts/omap3-ldp.dts
@@ -164,6 +164,11 @@
#include "twl4030.dtsi"
#include "twl4030_omap3.dtsi"
+#include "omap-panel-sharp-ls037v7dw01.dtsi"
+
+&backlight0 {
+ gpios = <&twl_gpio 15 GPIO_ACTIVE_LOW>;
+};
&i2c2 {
clock-frequency = <400000>;
@@ -173,6 +178,24 @@
clock-frequency = <400000>;
};
+&lcd_3v3 {
+ gpio = <&twl_gpio 7 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+};
+
+&lcd0 {
+ reset-gpios = <&gpio2 23 GPIO_ACTIVE_HIGH>; /* gpio55, lcd RESB */
+ mode-gpios = <&gpio2 24 GPIO_ACTIVE_LOW>; /* gpio56, lcd MO */
+};
+
+&mcspi1 {
+ tsc2046@0 {
+ interrupt-parent = <&gpio2>;
+ interrupts = <22 0>; /* gpio54 */
+ pendown-gpio = <&gpio2 22 0>;
+ };
+};
+
&mmc1 {
/* See 35xx errata 2.1.1.128 in SPRZ278F */
compatible = "ti,omap3-pre-es3-hsmmc";
@@ -247,8 +270,3 @@
/* Needed for ads7846 */
regulator-name = "vcc";
};
-
-&vpll2 {
- /* Needed for DSS */
- regulator-name = "vdds_dsi";
-};
^ permalink raw reply
* [PATCH] backlight: gpio-backlight: Fix warning when the GPIO is on a I2C chip
From: Tony Lindgren @ 2014-05-09 1:24 UTC (permalink / raw)
To: Lee Jones
Cc: linux-kernel, linux-fbdev, linux-omap, Bryan Wu, Jingoo Han,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen
If the GPIO for the backlight is on an I2C chip, we currently
get nasty warnings like this during the boot:
WARNING: CPU: 0 PID: 6 at drivers/gpio/gpiolib.c:2364 gpiod_set_raw_value+0x40/0x4c()
Modules linked in:
CPU: 0 PID: 6 Comm: kworker/u2:0 Not tainted 3.15.0-rc4-12393-gcde9f4e #400
Workqueue: deferwq deferred_probe_work_func
[<c0014cbc>] (unwind_backtrace) from [<c001191c>] (show_stack+0x10/0x14)
[<c001191c>] (show_stack) from [<c0566ae0>] (dump_stack+0x80/0x9c)
[<c0566ae0>] (dump_stack) from [<c003f61c>] (warn_slowpath_common+0x68/0x8c)
[<c003f61c>] (warn_slowpath_common) from [<c003f65c>] (warn_slowpath_null+0x1c/0x24)
[<c003f65c>] (warn_slowpath_null) from [<c02f7e10>] (gpiod_set_raw_value+0x40/0x4c)
[<c02f7e10>] (gpiod_set_raw_value) from [<c0308fbc>] (gpio_backlight_update_status+0x4c/0x74)
[<c0308fbc>] (gpio_backlight_update_status) from [<c030914c>] (gpio_backlight_probe+0x168/0x254)
[<c030914c>] (gpio_backlight_probe) from [<c0378fa8>] (platform_drv_probe+0x18/0x48)
[<c0378fa8>] (platform_drv_probe) from [<c0377c40>] (driver_probe_device+0x10c/0x238)
[<c0377c40>] (driver_probe_device) from [<c0376330>] (bus_for_each_drv+0x44/0x8c)
[<c0376330>] (bus_for_each_drv) from [<c0377afc>] (device_attach+0x74/0x8c)
[<c0377afc>] (device_attach) from [<c03771c4>] (bus_probe_device+0x88/0xb0)
[<c03771c4>] (bus_probe_device) from [<c03775c8>] (deferred_probe_work_func+0x64/0x94)
[<c03775c8>] (deferred_probe_work_func) from [<c00572e8>] (process_one_work+0x1b4/0x4bc)
[<c00572e8>] (process_one_work) from [<c00579d0>] (worker_thread+0x11c/0x398)
[<c00579d0>] (worker_thread) from [<c005dfd8>] (kthread+0xc8/0xe4)
[<c005dfd8>] (kthread) from [<c000e768>] (ret_from_fork+0x14/0x2c)
Fix this by using gpio_set_value_cansleep() as suggested in
drivers/gpio/gpiolib.c:2364. This is what the other backlight drivers
are also doing.
Signed-off-by: Tony Lindgren <tony@atomide.com>
--- a/drivers/video/backlight/gpio_backlight.c
+++ b/drivers/video/backlight/gpio_backlight.c
@@ -38,7 +38,8 @@ static int gpio_backlight_update_status(struct backlight_device *bl)
bl->props.state & (BL_CORE_SUSPENDED | BL_CORE_FBBLANK))
brightness = 0;
- gpio_set_value(gbl->gpio, brightness ? gbl->active : !gbl->active);
+ gpio_set_value_cansleep(gbl->gpio,
+ brightness ? gbl->active : !gbl->active);
return 0;
}
^ permalink raw reply
* Re: [PATCH] backlight: gpio-backlight: Fix warning when the GPIO is on a I2C chip
From: Jingoo Han @ 2014-05-09 2:25 UTC (permalink / raw)
To: 'Tony Lindgren'
Cc: 'Lee Jones', linux-kernel, linux-fbdev, linux-omap,
'Bryan Wu', 'Jean-Christophe Plagniol-Villard',
'Tomi Valkeinen', 'Jingoo Han'
In-Reply-To: <20140509012454.GL2198@atomide.com>
On Friday, May 09, 2014 10:25 AM, Lee Jones wrote:
>
> If the GPIO for the backlight is on an I2C chip, we currently
> get nasty warnings like this during the boot:
>
> WARNING: CPU: 0 PID: 6 at drivers/gpio/gpiolib.c:2364 gpiod_set_raw_value+0x40/0x4c()
> Modules linked in:
> CPU: 0 PID: 6 Comm: kworker/u2:0 Not tainted 3.15.0-rc4-12393-gcde9f4e #400
> Workqueue: deferwq deferred_probe_work_func
> [<c0014cbc>] (unwind_backtrace) from [<c001191c>] (show_stack+0x10/0x14)
> [<c001191c>] (show_stack) from [<c0566ae0>] (dump_stack+0x80/0x9c)
> [<c0566ae0>] (dump_stack) from [<c003f61c>] (warn_slowpath_common+0x68/0x8c)
> [<c003f61c>] (warn_slowpath_common) from [<c003f65c>] (warn_slowpath_null+0x1c/0x24)
> [<c003f65c>] (warn_slowpath_null) from [<c02f7e10>] (gpiod_set_raw_value+0x40/0x4c)
> [<c02f7e10>] (gpiod_set_raw_value) from [<c0308fbc>] (gpio_backlight_update_status+0x4c/0x74)
> [<c0308fbc>] (gpio_backlight_update_status) from [<c030914c>] (gpio_backlight_probe+0x168/0x254)
> [<c030914c>] (gpio_backlight_probe) from [<c0378fa8>] (platform_drv_probe+0x18/0x48)
> [<c0378fa8>] (platform_drv_probe) from [<c0377c40>] (driver_probe_device+0x10c/0x238)
> [<c0377c40>] (driver_probe_device) from [<c0376330>] (bus_for_each_drv+0x44/0x8c)
> [<c0376330>] (bus_for_each_drv) from [<c0377afc>] (device_attach+0x74/0x8c)
> [<c0377afc>] (device_attach) from [<c03771c4>] (bus_probe_device+0x88/0xb0)
> [<c03771c4>] (bus_probe_device) from [<c03775c8>] (deferred_probe_work_func+0x64/0x94)
> [<c03775c8>] (deferred_probe_work_func) from [<c00572e8>] (process_one_work+0x1b4/0x4bc)
> [<c00572e8>] (process_one_work) from [<c00579d0>] (worker_thread+0x11c/0x398)
> [<c00579d0>] (worker_thread) from [<c005dfd8>] (kthread+0xc8/0xe4)
> [<c005dfd8>] (kthread) from [<c000e768>] (ret_from_fork+0x14/0x2c)
>
> Fix this by using gpio_set_value_cansleep() as suggested in
> drivers/gpio/gpiolib.c:2364. This is what the other backlight drivers
> are also doing.
OK, I see.
However, gpio_backlight drive can be used by a lot of gpio drivers.
In some cases, 'can_sleep' is 'false' and gpio_set_value_cansleep()
is unnecessary.
In my opinion, gpio_set_value_cansleep() or gpio_set_value() can be
called selectively by 'can_sleep' value.
How about the following?
- gpio_set_value(gbl->gpio, brightness ? gbl->active : !gbl->active);
+ if (gpio_cansleep(gbl->gpio))
+ gpio_set_value_cansleep(gbl->gpio,
+ brightness ? gbl->active : !gbl->active);
+ else
+ gpio_set_value(gbl->gpio, brightness ? gbl->active : !gbl->active);
Best regards,
Jingoo Han
>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
>
> --- a/drivers/video/backlight/gpio_backlight.c
> +++ b/drivers/video/backlight/gpio_backlight.c
> @@ -38,7 +38,8 @@ static int gpio_backlight_update_status(struct backlight_device *bl)
> bl->props.state & (BL_CORE_SUSPENDED | BL_CORE_FBBLANK))
> brightness = 0;
>
> - gpio_set_value(gbl->gpio, brightness ? gbl->active : !gbl->active);
> + gpio_set_value_cansleep(gbl->gpio,
> + brightness ? gbl->active : !gbl->active);
>
> return 0;
> }
> --
^ permalink raw reply
* Re: [PATCH] backlight: gpio-backlight: Fix warning when the GPIO is on a I2C chip
From: Tony Lindgren @ 2014-05-09 3:09 UTC (permalink / raw)
To: Jingoo Han
Cc: 'Lee Jones', linux-kernel, linux-fbdev, linux-omap,
'Bryan Wu', 'Jean-Christophe Plagniol-Villard',
'Tomi Valkeinen'
In-Reply-To: <004701cf6b2d$e1a39c10$a4ead430$%han@samsung.com>
* Jingoo Han <jg1.han@samsung.com> [140508 19:25]:
> On Friday, May 09, 2014 10:25 AM, Lee Jones wrote:
> >
> > If the GPIO for the backlight is on an I2C chip, we currently
> > get nasty warnings like this during the boot:
> >
> > WARNING: CPU: 0 PID: 6 at drivers/gpio/gpiolib.c:2364 gpiod_set_raw_value+0x40/0x4c()
> > Modules linked in:
> > CPU: 0 PID: 6 Comm: kworker/u2:0 Not tainted 3.15.0-rc4-12393-gcde9f4e #400
> > Workqueue: deferwq deferred_probe_work_func
> > [<c0014cbc>] (unwind_backtrace) from [<c001191c>] (show_stack+0x10/0x14)
> > [<c001191c>] (show_stack) from [<c0566ae0>] (dump_stack+0x80/0x9c)
> > [<c0566ae0>] (dump_stack) from [<c003f61c>] (warn_slowpath_common+0x68/0x8c)
> > [<c003f61c>] (warn_slowpath_common) from [<c003f65c>] (warn_slowpath_null+0x1c/0x24)
> > [<c003f65c>] (warn_slowpath_null) from [<c02f7e10>] (gpiod_set_raw_value+0x40/0x4c)
> > [<c02f7e10>] (gpiod_set_raw_value) from [<c0308fbc>] (gpio_backlight_update_status+0x4c/0x74)
> > [<c0308fbc>] (gpio_backlight_update_status) from [<c030914c>] (gpio_backlight_probe+0x168/0x254)
> > [<c030914c>] (gpio_backlight_probe) from [<c0378fa8>] (platform_drv_probe+0x18/0x48)
> > [<c0378fa8>] (platform_drv_probe) from [<c0377c40>] (driver_probe_device+0x10c/0x238)
> > [<c0377c40>] (driver_probe_device) from [<c0376330>] (bus_for_each_drv+0x44/0x8c)
> > [<c0376330>] (bus_for_each_drv) from [<c0377afc>] (device_attach+0x74/0x8c)
> > [<c0377afc>] (device_attach) from [<c03771c4>] (bus_probe_device+0x88/0xb0)
> > [<c03771c4>] (bus_probe_device) from [<c03775c8>] (deferred_probe_work_func+0x64/0x94)
> > [<c03775c8>] (deferred_probe_work_func) from [<c00572e8>] (process_one_work+0x1b4/0x4bc)
> > [<c00572e8>] (process_one_work) from [<c00579d0>] (worker_thread+0x11c/0x398)
> > [<c00579d0>] (worker_thread) from [<c005dfd8>] (kthread+0xc8/0xe4)
> > [<c005dfd8>] (kthread) from [<c000e768>] (ret_from_fork+0x14/0x2c)
> >
> > Fix this by using gpio_set_value_cansleep() as suggested in
> > drivers/gpio/gpiolib.c:2364. This is what the other backlight drivers
> > are also doing.
>
> OK, I see.
> However, gpio_backlight drive can be used by a lot of gpio drivers.
> In some cases, 'can_sleep' is 'false' and gpio_set_value_cansleep()
> is unnecessary.
>
> In my opinion, gpio_set_value_cansleep() or gpio_set_value() can be
> called selectively by 'can_sleep' value.
>
> How about the following?
>
> - gpio_set_value(gbl->gpio, brightness ? gbl->active : !gbl->active);
> + if (gpio_cansleep(gbl->gpio))
> + gpio_set_value_cansleep(gbl->gpio,
> + brightness ? gbl->active : !gbl->active);
> + else
> + gpio_set_value(gbl->gpio, brightness ? gbl->active : !gbl->active);
It should be always fine to use gpio_set_value_cansleep(), see your
old thread from few years ago related to another backlight driver:
https://lkml.org/lkml/2012/12/5/343
Regards,
Tony
^ permalink raw reply
* Re: [PATCH] backlight: gpio-backlight: Fix warning when the GPIO is on a I2C chip
From: Jingoo Han @ 2014-05-09 3:42 UTC (permalink / raw)
To: 'Tony Lindgren'
Cc: 'Lee Jones', linux-kernel, linux-fbdev, linux-omap,
'Bryan Wu', 'Jean-Christophe Plagniol-Villard',
'Tomi Valkeinen', 'Linus Walleij',
'Alexandre Courbot', 'Russell King',
'Jingoo Han'
In-Reply-To: <20140509030925.GN2198@atomide.com>
On Friday, May 09, 2014 12:09 PM, Tony Lindgren wrote:
> On Friday, May 09, 2014 11:25 AM, Jingoo Han wrote:
> > On Friday, May 09, 2014 10:25 AM, Lee Jones wrote:
> > >
> > > If the GPIO for the backlight is on an I2C chip, we currently
> > > get nasty warnings like this during the boot:
> > >
> > > WARNING: CPU: 0 PID: 6 at drivers/gpio/gpiolib.c:2364 gpiod_set_raw_value+0x40/0x4c()
> > > Modules linked in:
> > > CPU: 0 PID: 6 Comm: kworker/u2:0 Not tainted 3.15.0-rc4-12393-gcde9f4e #400
> > > Workqueue: deferwq deferred_probe_work_func
> > > [<c0014cbc>] (unwind_backtrace) from [<c001191c>] (show_stack+0x10/0x14)
> > > [<c001191c>] (show_stack) from [<c0566ae0>] (dump_stack+0x80/0x9c)
> > > [<c0566ae0>] (dump_stack) from [<c003f61c>] (warn_slowpath_common+0x68/0x8c)
> > > [<c003f61c>] (warn_slowpath_common) from [<c003f65c>] (warn_slowpath_null+0x1c/0x24)
> > > [<c003f65c>] (warn_slowpath_null) from [<c02f7e10>] (gpiod_set_raw_value+0x40/0x4c)
> > > [<c02f7e10>] (gpiod_set_raw_value) from [<c0308fbc>] (gpio_backlight_update_status+0x4c/0x74)
> > > [<c0308fbc>] (gpio_backlight_update_status) from [<c030914c>] (gpio_backlight_probe+0x168/0x254)
> > > [<c030914c>] (gpio_backlight_probe) from [<c0378fa8>] (platform_drv_probe+0x18/0x48)
> > > [<c0378fa8>] (platform_drv_probe) from [<c0377c40>] (driver_probe_device+0x10c/0x238)
> > > [<c0377c40>] (driver_probe_device) from [<c0376330>] (bus_for_each_drv+0x44/0x8c)
> > > [<c0376330>] (bus_for_each_drv) from [<c0377afc>] (device_attach+0x74/0x8c)
> > > [<c0377afc>] (device_attach) from [<c03771c4>] (bus_probe_device+0x88/0xb0)
> > > [<c03771c4>] (bus_probe_device) from [<c03775c8>] (deferred_probe_work_func+0x64/0x94)
> > > [<c03775c8>] (deferred_probe_work_func) from [<c00572e8>] (process_one_work+0x1b4/0x4bc)
> > > [<c00572e8>] (process_one_work) from [<c00579d0>] (worker_thread+0x11c/0x398)
> > > [<c00579d0>] (worker_thread) from [<c005dfd8>] (kthread+0xc8/0xe4)
> > > [<c005dfd8>] (kthread) from [<c000e768>] (ret_from_fork+0x14/0x2c)
> > >
> > > Fix this by using gpio_set_value_cansleep() as suggested in
> > > drivers/gpio/gpiolib.c:2364. This is what the other backlight drivers
> > > are also doing.
> >
> > OK, I see.
> > However, gpio_backlight drive can be used by a lot of gpio drivers.
> > In some cases, 'can_sleep' is 'false' and gpio_set_value_cansleep()
> > is unnecessary.
> >
> > In my opinion, gpio_set_value_cansleep() or gpio_set_value() can be
> > called selectively by 'can_sleep' value.
> >
> > How about the following?
> >
> > - gpio_set_value(gbl->gpio, brightness ? gbl->active : !gbl->active);
> > + if (gpio_cansleep(gbl->gpio))
> > + gpio_set_value_cansleep(gbl->gpio,
> > + brightness ? gbl->active : !gbl->active);
> > + else
> > + gpio_set_value(gbl->gpio, brightness ? gbl->active : !gbl->active);
>
> It should be always fine to use gpio_set_value_cansleep(), see your
> old thread from few years ago related to another backlight driver:
>
> https://lkml.org/lkml/2012/12/5/343
(+cc Linus Walleij, Alexandre Courbot, Russell King)
OK, I see.
gpio_set_value_cansleep() calls gpiod_set_raw_value_cansleep(),
and gpio_set_value() calls gpiod_set_raw_value() as below.
./drivers/gpio/gpiolib.c
void gpiod_set_raw_value_cansleep(struct gpio_desc *desc, int value)
{
might_sleep_if(extra_checks);
if (!desc)
return;
_gpiod_set_raw_value(desc, value);
}
EXPORT_SYMBOL_GPL(gpiod_set_raw_value_cansleep);
./drivers/gpio/gpiolib.c
void gpiod_set_raw_value(struct gpio_desc *desc, int value)
{
if (!desc)
return;
/* Should be using gpio_set_value_cansleep() */
WARN_ON(desc->chip->can_sleep);
_gpiod_set_raw_value(desc, value);
}
EXPORT_SYMBOL_GPL(gpiod_set_raw_value);
Then, the difference between gpio_set_value_cansleep() or
gpio_set_value() is whether might_sleep_if(extra_checks) is
called or not.
So, you said that "It should be always fine to use
gpio_set_value_cansleep()", right?
Linus Walleij,
Is there any reason to keep these two functions such as
gpiod_set_raw_value_cansleep() and gpiod_set_raw_value()?
Best regards,
Jingoo Han
^ permalink raw reply
* Re: [PATCH 4/4] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp
From: Tomi Valkeinen @ 2014-05-09 7:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140508233628.GJ2198@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 1409 bytes --]
On 09/05/14 02:36, Tony Lindgren wrote:
> --- /dev/null
> +++ b/arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
> @@ -0,0 +1,82 @@
> +/*
> + * Common file for omap dpi panels with QVGA and reset pins
> + *
> + * Note that the board specifc DTS file needs to specify
> + * at minimum the GPIO enable-gpios for display, and
> + * gpios for gpio-backlight.
> + */
This looks very board specific to me... The regulator and the use of
mcspi1 depend on the board, so this file can't be used on just any omap
board with the same panel. And this can (probably) only be used on
boards with a single display. Do those boards have tv-out?
So I have nothing against having common files, but shouldn't this be
named something more specific? If the boards involved are TI's OMAP3
development boards, maybe this should be something like...
omap3-ti-dev-panel-sharp-ls037v7dw01.dtsi. Well, that's a quite long one.
> +/ {
> + aliases {
> + display0 = &lcd0;
> + };
> +
> + backlight0: backlight {
> + compatible = "gpio-backlight";
> + };
> +
> + /* 3.3V GPIO controlled regulator for LCD_ENVDD */
> + lcd_3v3: regulator-lcd-3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "lcd_3v3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + startup-delay-us = <70000>;
> + regulator-always-on;
Why always-on?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tomi Valkeinen @ 2014-05-09 7:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140508233300.GI2198@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 4120 bytes --]
On 09/05/14 02:33, Tony Lindgren wrote:
> We can pass the GPIO configuration for ls037v7dw01 in a standard
> gpios property.
>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
>
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt
> @@ -0,0 +1,56 @@
> +SHARP LS037V7DW01 TFT-LCD panel
> +
> +Required properties:
> +- compatible: should be "sharp,ls037v7dw01"
> +
> +Optional properties:
> +- enable-gpios: a GPIO spec for the optional enable pin
> + this pin is the INI pin as specified in the LS037V7DW01.pdf file.
> +- reset-gpios: a GPIO spec for the optional reset pin
> + this pin is the RESB pin as specified in the LS037V7DW01.pdf file.
> +- mode-gpios: a GPIO
> + ordered MO, LR, and UD as specified in the LS037V7DW01.pdf file.
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
The video port data is required also. See for example
Documentation/devicetree/bindings/video/panel-dsi-cm.txt or
Documentation/devicetree/bindings/video/hdmi-connector.txt.
Also, all the bindings I've made are in
Documentation/devicetree/bindings/video/, and I'd rather keep the video
bindings OMAP uses in the same place.
> +This panel can have zero to five GPIOs to configure
> +to change configuration between QVGA and VGA mode
> +and the scan direction. As these pins can be also
> +configured with external pulls, all the GPIOs are
> +considered optional with holes in the array.
> +
> +Example when connected to a omap2+ based device:
> +
> + lcd0: display {
> + compatible = "sharp,ls037v7dw01";
> + power-supply = <&lcd_3v3>;
> + enable-gpios = <&gpio5 24 GPIO_ACTIVE_HIGH>; /* gpio152, lcd INI */
> + reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>; /* gpio155, lcd RESB */
> + mode-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH /* gpio154, lcd MO */
> + &gpio1 2 GPIO_ACTIVE_HIGH /* gpio2, lcd LR */
> + &gpio1 3 GPIO_ACTIVE_HIGH>; /* gpio3, lcd UD */
> +
> + panel-timing {
> + clock-frequency = <19200000>;
> + hback-porch = <28>;
> + hactive = <480>;
> + hfront-porch = <1>;
> + hsync-len = <2>;
> + vback-porch = <1>;
> + vactive = <640>;
> + vfront-porch = <1>;
> + vsync-len = <1>;
> + hsync-active = <0>;
> + vsync-active = <0>;
> + de-active = <1>;
> + pixelclk-active = <1>;
> + };
I don't think we should define panel-timing here. We know it's
sharp,ls037v7dw01, so the driver knows the video timings. Also, if we
would extend the driver to support both resolution modes, it needs to
support two different timings, so the above doesn't work in that case
either.
Although if the MO gpio is not controlled by the driver, we should tell
the driver whether that gpio is high or low.
> +static int sharp_ls_probe_of(struct platform_device *pdev)
> +{
> + struct panel_drv_data *ddata = platform_get_drvdata(pdev);
> + struct device_node *node = pdev->dev.of_node;
> + struct omap_dss_device *in;
> + struct display_timing timing;
> + struct videomode vm;
> + int r;
> +
> + ddata->vcc = devm_regulator_get(&pdev->dev, "envdd");
> + if (IS_ERR(ddata->vcc)) {
> + dev_err(&pdev->dev, "failed to get regulator\n");
> + return PTR_ERR(ddata->vcc);
> + }
> +
> + r = regulator_enable(ddata->vcc);
> + if (r != 0) {
> + dev_err(&pdev->dev, "failed to enable regulator\n");
> + return r;
> + }
The regulator should be enabled when the panel is enabled, not at probe
time.
> +static const struct of_device_id sharp_ls_of_match[] = {
> + { .compatible = "sharp,ls037v7dw01", },
At the moment our display drivers are OMAP specific, and for that reason
we should prefix the compatible strings with "omapdss,". For example,
drivers/video/fbdev/omap2/displays-new/panel-dsi-cm.c:
{ .compatible = "omapdss,panel-dsi-cm", },
But we should still have the right compatible string in the .dts, so we
convert the compatible name in arch/arm/mach-omap2/display.c, with
'dss_compat_conv_list' array, to which this panel's name should be added.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
From: Tomi Valkeinen @ 2014-05-09 7:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1398815562-24113-2-git-send-email-tony@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 1983 bytes --]
On 30/04/14 02:52, Tony Lindgren wrote:
> Otherwise we can get often errors like the following and the
> display won't come on:
>
> omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay
> omapdss APPLY error: SYNC_LOST on channel lcd, restarting
> the output with video overlays disabled
>
> There are some earlier references to this issue:
>
> http://www.spinics.net/lists/linux-omap/msg59511.html
> http://www.spinics.net/lists/linux-omap/msg59724.html
Those don't sound like the same issue, but it's hard to say. What kind
of clock rates do you get? Cat you paste debugfs/omapdss/clk, with and
without this patch?
What resolution do you have? If it's a very high resolution (say, DVI
output to a monitor), it could just be an issue of
not-enough-memory-bandwidth.
> It seems that it's safe to set the lower values even for 3630.
> If we can confirm that 3630 works with the higher values
> reliably we can add further detection.
>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> drivers/video/fbdev/omap2/dss/dss.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/fbdev/omap2/dss/dss.c b/drivers/video/fbdev/omap2/dss/dss.c
> index d55266c..ad6561f 100644
> --- a/drivers/video/fbdev/omap2/dss/dss.c
> +++ b/drivers/video/fbdev/omap2/dss/dss.c
> @@ -707,9 +707,10 @@ static const struct dss_features omap34xx_dss_feats __initconst = {
> .dpi_select_source = &dss_dpi_select_source_omap2_omap3,
> };
>
> +/* Supposedly 3630 can use div 32 mult 2, but that needs to be rechecked */
> static const struct dss_features omap3630_dss_feats __initconst = {
> - .fck_div_max = 32,
> - .dss_fck_multiplier = 1,
> + .fck_div_max = 16,
> + .dss_fck_multiplier = 2,
These values tell about the clock hardware, they are not settings that
can be changed to change the clock. OMAP3630 has a fixed x2 multiplier
and a divider with maximum value of 16.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
From: Tomi Valkeinen @ 2014-05-09 8:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140508232006.GG2198@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 1273 bytes --]
On 09/05/14 02:20, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [140429 16:53]:
>> Otherwise we can get often errors like the following and the
>> display won't come on:
>>
>> omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay
>> omapdss APPLY error: SYNC_LOST on channel lcd, restarting
>> the output with video overlays disabled
>>
>> There are some earlier references to this issue:
>>
>> http://www.spinics.net/lists/linux-omap/msg59511.html
>> http://www.spinics.net/lists/linux-omap/msg59724.html
>>
>> It seems that it's safe to set the lower values even for 3630.
>> If we can confirm that 3630 works with the higher values
>> reliably we can add further detection.
>
> BTW, I'm also seeing this warning on 3730-evm it may be related:
>
> [ 3.523101] ------------[ cut here ]------------
> [ 3.528015] WARNING: CPU: 0 PID: 6 at drivers/video/fbdev/omap2/dss/dss.c:483 dss_set_fck_rate+0x6c/0x8c()
> [ 3.538360] clk rate mismatch: 108000000 != 115200000
> [ 3.543518] Modules linked in:
Hmm... Can you paste the clk_summary from debugfs? Somehow the clock
framework calculates the clock rate differently than the dss. Or do we
have different clock.dts files used for 3730 and 3630?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tomi Valkeinen @ 2014-05-09 8:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140508233300.GI2198@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 7924 bytes --]
On 09/05/14 02:33, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [140507 11:00]:
>> * Tomi Valkeinen <tomi.valkeinen@ti.com> [140507 09:03]:
>>> On 07/05/14 18:03, Tony Lindgren wrote:
>>>>
>>>> BTW, I'm also personally fine with all five gpios showing in a single
>>>> gpios property, I'm not too exited about naming anything in DT..
>>>
>>> I don't have a strong opinion here. I don't have much experience with
>>> DT, especially with making bindings compatible with other ones.
>>>
>>> I'd just forget the simple-panel, and have single gpio array.
>>
>> Well if it's a don't care flag for both of us, let's try to use
>> the existing standard for simple-panel.txt and add mode-gpios
>> property. I'll post a patch for that.
>
> Here's an updated version using enable-gpios, reset-gpios and
> mode-gpios. So it follows simple-panel.txt and adds mode-gpios
> that's currently specific to this panel only.
>
> Also updated for -EPROBE_DEFER handling, tested that by changing
> one of the GPIOs to be a twl4030 GPIO.
To speed things up a bit, I made the changes I suggested. Compile tested
only.
From f8360778e8bc96096cbb1793a18a8c240376ca09 Mon Sep 17 00:00:00 2001
From: Tony Lindgren <tony@atomide.com>
Date: Mon, 28 Apr 2014 20:22:21 -0700
Subject: [PATCH] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
Add device tree support for sharp-ls037v7dw01 panel.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
.../bindings/video/sharp,ls037v7dw01.txt | 44 ++++++++++
.../omap2/displays-new/panel-sharp-ls037v7dw01.c | 95 +++++++++++++++++++++-
2 files changed, 136 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/video/sharp,ls037v7dw01.txt
diff --git a/Documentation/devicetree/bindings/video/sharp,ls037v7dw01.txt b/Documentation/devicetree/bindings/video/sharp,ls037v7dw01.txt
new file mode 100644
index 000000000000..2a60fd9a2607
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/sharp,ls037v7dw01.txt
@@ -0,0 +1,44 @@
+SHARP LS037V7DW01 TFT-LCD panel
+===================================
+
+Required properties:
+- compatible: "sharp,ls037v7dw01"
+
+Optional properties:
+- label: a symbolic name for the panel
+- enable-gpios: a GPIO spec for the optional enable pin
+ this pin is the INI pin as specified in the LS037V7DW01.pdf file.
+- reset-gpios: a GPIO spec for the optional reset pin
+ this pin is the RESB pin as specified in the LS037V7DW01.pdf file.
+- mode-gpios: a GPIO
+ ordered MO, LR, and UD as specified in the LS037V7DW01.pdf file.
+
+Required nodes:
+- Video port for DPI input
+
+This panel can have zero to five GPIOs to configure
+to change configuration between QVGA and VGA mode
+and the scan direction. As these pins can be also
+configured with external pulls, all the GPIOs are
+considered optional with holes in the array.
+
+Example
+-------
+
+Example when connected to a omap2+ based device:
+
+lcd0: display {
+ compatible = "sharp,ls037v7dw01";
+ power-supply = <&lcd_3v3>;
+ enable-gpios = <&gpio5 24 GPIO_ACTIVE_HIGH>; /* gpio152, lcd INI */
+ reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>; /* gpio155, lcd RESB */
+ mode-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH /* gpio154, lcd MO */
+ &gpio1 2 GPIO_ACTIVE_HIGH /* gpio2, lcd LR */
+ &gpio1 3 GPIO_ACTIVE_HIGH>; /* gpio3, lcd UD */
+
+ port {
+ lcd_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+};
diff --git a/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c b/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
index 8adde628ad38..91eeb2ec93a8 100644
--- a/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
@@ -12,15 +12,18 @@
#include <linux/delay.h>
#include <linux/gpio.h>
#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
#include <linux/platform_device.h>
#include <linux/slab.h>
-
+#include <linux/regulator/consumer.h>
#include <video/omapdss.h>
#include <video/omap-panel-data.h>
struct panel_drv_data {
struct omap_dss_device dssdev;
struct omap_dss_device *in;
+ struct regulator *vcc;
int data_lines;
@@ -95,12 +98,21 @@ static int sharp_ls_enable(struct omap_dss_device *dssdev)
if (omapdss_device_is_enabled(dssdev))
return 0;
- in->ops.dpi->set_data_lines(in, ddata->data_lines);
+ if (ddata->data_lines)
+ in->ops.dpi->set_data_lines(in, ddata->data_lines);
in->ops.dpi->set_timings(in, &ddata->videomode);
+ if (ddata->vcc) {
+ r = regulator_enable(ddata->vcc);
+ if (r != 0)
+ return r;
+ }
+
r = in->ops.dpi->enable(in);
- if (r)
+ if (r) {
+ regulator_disable(ddata->vcc);
return r;
+ }
/* wait couple of vsyncs until enabling the LCD */
msleep(50);
@@ -136,6 +148,9 @@ static void sharp_ls_disable(struct omap_dss_device *dssdev)
in->ops.dpi->disable(in);
+ if (ddata->vcc)
+ regulator_disable(ddata->vcc);
+
dssdev->state = OMAP_DSS_DISPLAY_DISABLED;
}
@@ -243,6 +258,68 @@ static int sharp_ls_probe_pdata(struct platform_device *pdev)
return 0;
}
+static struct gpio_desc *
+sharp_ls_get_gpio_of(struct device *dev, int index, int val, char *desc)
+{
+ struct gpio_desc *gpio;
+
+ gpio = devm_gpiod_get_index(dev, desc, index);
+ if (IS_ERR(gpio))
+ return gpio;
+
+ gpiod_direction_output(gpio, val);
+
+ return gpio;
+}
+
+static int sharp_ls_probe_of(struct platform_device *pdev)
+{
+ struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct device_node *node = pdev->dev.of_node;
+ struct omap_dss_device *in;
+
+ ddata->vcc = devm_regulator_get(&pdev->dev, "envdd");
+ if (IS_ERR(ddata->vcc)) {
+ dev_err(&pdev->dev, "failed to get regulator\n");
+ return PTR_ERR(ddata->vcc);
+ }
+
+ /* lcd INI */
+ ddata->ini_gpio = sharp_ls_get_gpio_of(&pdev->dev, 3, 0, "enable");
+ if (PTR_ERR(ddata->ini_gpio) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+
+ /* lcd RESB */
+ ddata->resb_gpio = sharp_ls_get_gpio_of(&pdev->dev, 0, 0, "reset");
+ if (PTR_ERR(ddata->resb_gpio) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+
+ /* lcd MO */
+ ddata->mo_gpio = sharp_ls_get_gpio_of(&pdev->dev, 0, 0, "mode");
+ if (PTR_ERR(ddata->mo_gpio) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+
+ /* lcd LR */
+ ddata->lr_gpio = sharp_ls_get_gpio_of(&pdev->dev, 1, 1, "mode");
+ if (PTR_ERR(ddata->lr_gpio) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+
+ /* lcd UD */
+ ddata->ud_gpio = sharp_ls_get_gpio_of(&pdev->dev, 2, 1, "mode");
+ if (PTR_ERR(ddata->ud_gpio) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+
+ in = omapdss_of_find_source_for_first_ep(node);
+ if (IS_ERR(in)) {
+ dev_err(&pdev->dev, "failed to find video source\n");
+ return PTR_ERR(in);
+ }
+
+ ddata->in = in;
+
+ return 0;
+}
+
static int sharp_ls_probe(struct platform_device *pdev)
{
struct panel_drv_data *ddata;
@@ -259,6 +336,10 @@ static int sharp_ls_probe(struct platform_device *pdev)
r = sharp_ls_probe_pdata(pdev);
if (r)
return r;
+ } else if (pdev->dev.of_node) {
+ r = sharp_ls_probe_of(pdev);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
@@ -302,12 +383,20 @@ static int __exit sharp_ls_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id sharp_ls_of_match[] = {
+ { .compatible = "omapdss,sharp,ls037v7dw01", },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, sharp_ls_of_match);
+
static struct platform_driver sharp_ls_driver = {
.probe = sharp_ls_probe,
.remove = __exit_p(sharp_ls_remove),
.driver = {
.name = "panel-sharp-ls037v7dw01",
.owner = THIS_MODULE,
+ .of_match_table = sharp_ls_of_match,
},
};
--
1.9.1
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply related
* Re: [PATCH] backlight: gpio-backlight: Fix warning when the GPIO is on a I2C chip
From: Linus Walleij @ 2014-05-09 9:06 UTC (permalink / raw)
To: Jingoo Han
Cc: Tony Lindgren, Lee Jones, linux-kernel@vger.kernel.org,
linux-fbdev@vger.kernel.org, Linux-OMAP, Bryan Wu,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
Alexandre Courbot, Russell King
In-Reply-To: <000001cf6b38$a6a3ffa0$f3ebfee0$%han@samsung.com>
On Fri, May 9, 2014 at 5:42 AM, Jingoo Han <jg1.han@samsung.com> wrote:
> Linus Walleij,
> Is there any reason to keep these two functions such as
> gpiod_set_raw_value_cansleep() and gpiod_set_raw_value()?
Yes, the former can *not* be called from interrupt context,
and thus erroneous usage can be detected with runtime checks.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v3] video: mx3fb: Add backlight control support
From: Tomi Valkeinen @ 2014-05-09 9:11 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1399559916-15183-1-git-send-email-alexander.stein@systec-electronic.com>
[-- Attachment #1: Type: text/plain, Size: 1460 bytes --]
On 08/05/14 17:38, Alexander Stein wrote:
> This patch add backlight control support to allow dimming the backlight
> using the internal PWM. Currently the brightness is set fixed to a
> maximum of 255.
>
> Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
> ---
> Changes in v3:
> * Add a more descriptive commit message
>
> Changes in v2:
> * rebased to v3.15-rc4
>
> drivers/video/fbdev/mx3fb.c | 98 +++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 98 insertions(+)
>
> diff --git a/drivers/video/fbdev/mx3fb.c b/drivers/video/fbdev/mx3fb.c
> index 142e860..10a7244 100644
> --- a/drivers/video/fbdev/mx3fb.c
> +++ b/drivers/video/fbdev/mx3fb.c
> @@ -27,6 +27,7 @@
> #include <linux/clk.h>
> #include <linux/mutex.h>
> #include <linux/dma/ipu-dma.h>
> +#include <linux/backlight.h>
>
> #include <linux/platform_data/dma-imx.h>
> #include <linux/platform_data/video-mx3fb.h>
> @@ -34,6 +35,12 @@
> #include <asm/io.h>
> #include <asm/uaccess.h>
>
> +#if defined(CONFIG_BACKLIGHT_CLASS_DEVICE) || \
> + (defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE) && \
> + defined(CONFIG_MX3FB_MODULE))
> +#define PWM_BACKLIGHT_AVAILABLE
> +#endif
I'm not very fond of this kind of ifdeffery. It makes the driver rather
messy and confusing, especially if large blocks of code are inside the
ifdefs.
Can't you just make the driver select BACKLIGHT_CLASS_DEVICE?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 0/4] OMAPDSS: Add support for panel ls037v7dw01
From: Tomi Valkeinen @ 2014-05-09 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140505184138.GB15463@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 905 bytes --]
On 05/05/14 21:41, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [140429 16:53]:
>> Hi all,
>>
>> Here are few patches to add devicetree support for panel ls037v7dw01
>> that's found on many omap3 boards. They seem to be often mis-configured
>> as various panel dpi entries, but really should be move to use panel
>> ls037v7dw01 instead. This panel is found at least on the omap3 sdp,
>> ldp, omap3 evm and few other development boards.
>
> Tomi, assuming no more comments, do you want to pick up the first
> three patches of this series? I can queue the .dts changes or you
> can also set up a separate .dts changes branch for DSS that I can
> merge in too.
If it's all the same to you, I'd like to collect all display related
arch/arm/ patches into my tree, and I'll send you a merge request when
it's stable.
I already have OMAP5 and AM43xx stuff there.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v3 0/3] Add display support for gta04 device
From: Tomi Valkeinen @ 2014-05-09 9:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1399580212-5183-1-git-send-email-marek@goldelico.com>
[-- Attachment #1: Type: text/plain, Size: 1244 bytes --]
On 08/05/14 23:16, Marek Belisko wrote:
> This 3 patches adding display support for openmoko gta04 device.
> First patch add DT bindings for topolly td028 panel. Second add description for
> dss + panel and third fix panel probing when panel is compiled as module.
>
> Changes from v2:
> - add missing 'port' node for dpi_out endpoint (comment from Tomi Valkeinen)
>
> Changes from v1:
> - extend panel compatible string by 'omapdss'
> - add tpo-td028 panel to dss_compat_conv_list
> - add MODULE_ALIAS macro to properly probe panel when is compiled as module
>
> Marek Belisko (3):
> omapdss: panel-tpo-td028ec1: Add DT support.
> ARM: dts: oma3-gta04: Add display support
> omapdss: panel-tpo-td028ec1: Add module alias
>
> .../bindings/video/toppoly,td028ttec1.txt | 30 ++++++++
> arch/arm/boot/dts/omap3-gta04.dts | 87 ++++++++++++++++++++++
> arch/arm/mach-omap2/display.c | 1 +
> .../omap2/displays-new/panel-tpo-td028ttec1.c | 33 +++++++-
> 4 files changed, 150 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/video/toppoly,td028ttec1.txt
>
I think this series looks fine. I'll pick it up.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [RFC 1/6] omapdss: remove check for simpler port/endpoint binding
From: Tomi Valkeinen @ 2014-05-09 9:59 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-fbdev, linux-omap
In-Reply-To: <1399540517-17883-1-git-send-email-archit@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1064 bytes --]
On 08/05/14 12:15, Archit Taneja wrote:
> The support for simpler port/endpoint binding was removed in the merged version
> of omapdss DT. But dss_init_ports still tries to get to an endpoint even if no
> port exists. Remove this as this doesn't work.
>
> Signed-off-by: Archit Taneja <archit@ti.com>
> ---
> drivers/video/fbdev/omap2/dss/dss.c | 6 +-----
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/drivers/video/fbdev/omap2/dss/dss.c b/drivers/video/fbdev/omap2/dss/dss.c
> index d55266c..31ef262 100644
> --- a/drivers/video/fbdev/omap2/dss/dss.c
> +++ b/drivers/video/fbdev/omap2/dss/dss.c
> @@ -784,12 +784,8 @@ static int __init dss_init_ports(struct platform_device *pdev)
> return 0;
>
> port = omapdss_of_get_next_port(parent, NULL);
> - if (!port) {
> -#ifdef CONFIG_OMAP2_DSS_DPI
> - dpi_init_port(pdev, parent);
> -#endif
> + if (!port)
> return 0;
> - }
>
> do {
> u32 reg;
>
I'll try to find time to review the rest, but I'll queue this one
already for 3.16.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] uvesafb: abort initialization if video=uvesafb is not set
From: Tomi Valkeinen @ 2014-05-09 10:06 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1396791873-22606-1-git-send-email-lxnay@sabayon.org>
[-- Attachment #1: Type: text/plain, Size: 1542 bytes --]
On 06/04/14 16:44, lxnay@sabayon.org wrote:
> From: Fabio Erculiani <lxnay@sabayon.org>
>
> This patch makes possible to ship kernels with both vesafb and uvesafb
> in order to guarantee a smooth transition to uvesafb and cope with
> potential incompatibiles introduced by uvesafb making possible to disable
> it via cmdline.
>
> In case both vesafb and uvesafb are built-in, the kernel will try to
> initialize both, which makes possible to select the wanted one using
> either video=vesafb:... or video=uvesafb:....
> In this way, old distro installations will keep working as before while
> new ones can adopt video=uvesafb.
>
> The behaviour does not change if uvesafb is built as a module.
> ---
> drivers/video/uvesafb.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/video/uvesafb.c b/drivers/video/uvesafb.c
> index d428445..04c4742 100644
> --- a/drivers/video/uvesafb.c
> +++ b/drivers/video/uvesafb.c
> @@ -1957,6 +1957,10 @@ static int uvesafb_init(void)
>
> if (fb_get_options("uvesafb", &option))
> return -ENODEV;
> + if (!option || !*option)
> + /* if vesafb is enabled, this will make possible to fallback to it */
> + return -ENODEV;
> +
> uvesafb_setup(option);
> #endif
> err = cn_add_callback(&uvesafb_cn_id, "uvesafb", uvesafb_cn_callback);
>
I'm not familiar with vesa fbs, so I'd like to hear from other people if
this change is ok. Cc'd a bunch of random people from git log.
Reviewed-by, tested-by, acked-by from anyone?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: some divide by zero bugs in >fb_check_var() functions
From: Tomi Valkeinen @ 2014-05-09 10:18 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20140124223503.GA4251@elgon.mountain>
[-- Attachment #1: Type: text/plain, Size: 1042 bytes --]
On 02/05/14 18:48, Geert Uytterhoeven wrote:
> On Tue, Jan 28, 2014 at 10:28 PM, Kees Cook <keescook@chromium.org> wrote:
>> Is it ever valid to have pixclock, xres_virtual, or bits_per_pixel be
>> zero? Seems like it'd be trivial to check for those in fb_set_var()?
>
> pixclock could be zero for some special fixed type of display that doesn't
> have timings. Hmm, you could use 1 for that. Are there any in-tree users?
I have no idea if we have such drivers. But in that case I would rather
use pixel clock of 0 than 1. It's usually much easier to notice uses of
non-valid value if it's 0 than 1.
But maybe that'd warrant a new flag somewhere, to mark the fb as having
no timings.
> Anyway, the checker reported issues with specific drivers, not with the core,
> right?
Yes, but the issue seemed to be so common that it'd be nice if the core
would check it.
But looking at the longer list sent by Dan, it looks to me that there
are also lots of cases where it must be the driver doing the checks.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH 1/5] OMAPDSS: Fix writes to DISPC_POL_FREQ
From: Tomi Valkeinen @ 2014-05-09 12:32 UTC (permalink / raw)
To: linux-fbdev, linux-omap; +Cc: Archit Taneja, Tomi Valkeinen
When omapdss writes to DISPC_POL_FREQ register, it always ORs the bits
with the current contents of the register, never clearing the old ones,
causing wrong signal polarity settings.
As we write all the bits in DISPC_POL_FREQ, we don't need to care about
the current contents of the register. So fix the issue by constructing
new register value from scratch.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/fbdev/omap2/dss/dispc.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/dispc.c b/drivers/video/fbdev/omap2/dss/dispc.c
index f18397c33e8f..a22c64e26172 100644
--- a/drivers/video/fbdev/omap2/dss/dispc.c
+++ b/drivers/video/fbdev/omap2/dss/dispc.c
@@ -2945,13 +2945,13 @@ static void _dispc_mgr_set_lcd_timings(enum omap_channel channel, int hsw,
BUG();
}
- l = dispc_read_reg(DISPC_POL_FREQ(channel));
- l |= FLD_VAL(onoff, 17, 17);
- l |= FLD_VAL(rf, 16, 16);
- l |= FLD_VAL(de_level, 15, 15);
- l |= FLD_VAL(ipc, 14, 14);
- l |= FLD_VAL(hsync_level, 13, 13);
- l |= FLD_VAL(vsync_level, 12, 12);
+ l = FLD_VAL(onoff, 17, 17) |
+ FLD_VAL(rf, 16, 16) |
+ FLD_VAL(de_level, 15, 15) |
+ FLD_VAL(ipc, 14, 14) |
+ FLD_VAL(hsync_level, 13, 13) |
+ FLD_VAL(vsync_level, 12, 12);
+
dispc_write_reg(DISPC_POL_FREQ(channel), l);
}
--
1.9.1
^ permalink raw reply related
* [PATCH 2/5] OMAPDSS: remove venc_panel.c
From: Tomi Valkeinen @ 2014-05-09 12:32 UTC (permalink / raw)
To: linux-fbdev, linux-omap; +Cc: Archit Taneja, Tomi Valkeinen
In-Reply-To: <1399638727-23254-1-git-send-email-tomi.valkeinen@ti.com>
The use of venc_panel.c was removed in
09d2e7cdebd53b7572380a215008b334ff6321a5 (OMAPDSS: VENC: remove code
related to old panel model), but the file itself was left behind. Remove
the unused file.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/fbdev/omap2/dss/venc_panel.c | 232 -----------------------------
1 file changed, 232 deletions(-)
delete mode 100644 drivers/video/fbdev/omap2/dss/venc_panel.c
diff --git a/drivers/video/fbdev/omap2/dss/venc_panel.c b/drivers/video/fbdev/omap2/dss/venc_panel.c
deleted file mode 100644
index af68cd444d7e..000000000000
--- a/drivers/video/fbdev/omap2/dss/venc_panel.c
+++ /dev/null
@@ -1,232 +0,0 @@
-/*
- * Copyright (C) 2009 Nokia Corporation
- * Author: Tomi Valkeinen <tomi.valkeinen@nokia.com>
- *
- * VENC panel driver
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2 as published by
- * the Free Software Foundation.
- *
- * 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.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program. If not, see <http://www.gnu.org/licenses/>.
- */
-
-#include <linux/kernel.h>
-#include <linux/err.h>
-#include <linux/io.h>
-#include <linux/mutex.h>
-#include <linux/module.h>
-
-#include <video/omapdss.h>
-
-#include "dss.h"
-
-static struct {
- struct mutex lock;
-} venc_panel;
-
-static ssize_t display_output_type_show(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- struct omap_dss_device *dssdev = to_dss_device(dev);
- const char *ret;
-
- switch (dssdev->phy.venc.type) {
- case OMAP_DSS_VENC_TYPE_COMPOSITE:
- ret = "composite";
- break;
- case OMAP_DSS_VENC_TYPE_SVIDEO:
- ret = "svideo";
- break;
- default:
- return -EINVAL;
- }
-
- return snprintf(buf, PAGE_SIZE, "%s\n", ret);
-}
-
-static ssize_t display_output_type_store(struct device *dev,
- struct device_attribute *attr, const char *buf, size_t size)
-{
- struct omap_dss_device *dssdev = to_dss_device(dev);
- enum omap_dss_venc_type new_type;
-
- if (sysfs_streq("composite", buf))
- new_type = OMAP_DSS_VENC_TYPE_COMPOSITE;
- else if (sysfs_streq("svideo", buf))
- new_type = OMAP_DSS_VENC_TYPE_SVIDEO;
- else
- return -EINVAL;
-
- mutex_lock(&venc_panel.lock);
-
- if (dssdev->phy.venc.type != new_type) {
- dssdev->phy.venc.type = new_type;
- omapdss_venc_set_type(dssdev, new_type);
- if (dssdev->state = OMAP_DSS_DISPLAY_ACTIVE) {
- omapdss_venc_display_disable(dssdev);
- omapdss_venc_display_enable(dssdev);
- }
- }
-
- mutex_unlock(&venc_panel.lock);
-
- return size;
-}
-
-static DEVICE_ATTR(output_type, S_IRUGO | S_IWUSR,
- display_output_type_show, display_output_type_store);
-
-static int venc_panel_probe(struct omap_dss_device *dssdev)
-{
- /* set default timings to PAL */
- const struct omap_video_timings default_timings = {
- .x_res = 720,
- .y_res = 574,
- .pixelclock = 13500000,
- .hsw = 64,
- .hfp = 12,
- .hbp = 68,
- .vsw = 5,
- .vfp = 5,
- .vbp = 41,
-
- .vsync_level = OMAPDSS_SIG_ACTIVE_HIGH,
- .hsync_level = OMAPDSS_SIG_ACTIVE_HIGH,
-
- .interlace = true,
- };
-
- mutex_init(&venc_panel.lock);
-
- dssdev->panel.timings = default_timings;
-
- return device_create_file(dssdev->dev, &dev_attr_output_type);
-}
-
-static void venc_panel_remove(struct omap_dss_device *dssdev)
-{
- device_remove_file(dssdev->dev, &dev_attr_output_type);
-}
-
-static int venc_panel_enable(struct omap_dss_device *dssdev)
-{
- int r;
-
- dev_dbg(dssdev->dev, "venc_panel_enable\n");
-
- mutex_lock(&venc_panel.lock);
-
- if (dssdev->state != OMAP_DSS_DISPLAY_DISABLED) {
- r = -EINVAL;
- goto err;
- }
-
- omapdss_venc_set_timings(dssdev, &dssdev->panel.timings);
- omapdss_venc_set_type(dssdev, dssdev->phy.venc.type);
- omapdss_venc_invert_vid_out_polarity(dssdev,
- dssdev->phy.venc.invert_polarity);
-
- r = omapdss_venc_display_enable(dssdev);
- if (r)
- goto err;
-
- dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
-
- mutex_unlock(&venc_panel.lock);
-
- return 0;
-err:
- mutex_unlock(&venc_panel.lock);
-
- return r;
-}
-
-static void venc_panel_disable(struct omap_dss_device *dssdev)
-{
- dev_dbg(dssdev->dev, "venc_panel_disable\n");
-
- mutex_lock(&venc_panel.lock);
-
- if (dssdev->state = OMAP_DSS_DISPLAY_DISABLED)
- goto end;
-
- omapdss_venc_display_disable(dssdev);
-
- dssdev->state = OMAP_DSS_DISPLAY_DISABLED;
-end:
- mutex_unlock(&venc_panel.lock);
-}
-
-static void venc_panel_set_timings(struct omap_dss_device *dssdev,
- struct omap_video_timings *timings)
-{
- dev_dbg(dssdev->dev, "venc_panel_set_timings\n");
-
- mutex_lock(&venc_panel.lock);
-
- omapdss_venc_set_timings(dssdev, timings);
- dssdev->panel.timings = *timings;
-
- mutex_unlock(&venc_panel.lock);
-}
-
-static int venc_panel_check_timings(struct omap_dss_device *dssdev,
- struct omap_video_timings *timings)
-{
- dev_dbg(dssdev->dev, "venc_panel_check_timings\n");
-
- return omapdss_venc_check_timings(dssdev, timings);
-}
-
-static u32 venc_panel_get_wss(struct omap_dss_device *dssdev)
-{
- dev_dbg(dssdev->dev, "venc_panel_get_wss\n");
-
- return omapdss_venc_get_wss(dssdev);
-}
-
-static int venc_panel_set_wss(struct omap_dss_device *dssdev, u32 wss)
-{
- dev_dbg(dssdev->dev, "venc_panel_set_wss\n");
-
- return omapdss_venc_set_wss(dssdev, wss);
-}
-
-static struct omap_dss_driver venc_driver = {
- .probe = venc_panel_probe,
- .remove = venc_panel_remove,
-
- .enable = venc_panel_enable,
- .disable = venc_panel_disable,
-
- .get_resolution = omapdss_default_get_resolution,
- .get_recommended_bpp = omapdss_default_get_recommended_bpp,
-
- .set_timings = venc_panel_set_timings,
- .check_timings = venc_panel_check_timings,
-
- .get_wss = venc_panel_get_wss,
- .set_wss = venc_panel_set_wss,
-
- .driver = {
- .name = "venc",
- .owner = THIS_MODULE,
- },
-};
-
-int venc_panel_init(void)
-{
- return omap_dss_register_driver(&venc_driver);
-}
-
-void venc_panel_exit(void)
-{
- omap_dss_unregister_driver(&venc_driver);
-}
--
1.9.1
^ 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