* [PATCH 2/2] video: fbdev: Fix format string mismatch in gbefb.c
From: Masanari Iida @ 2014-04-29 12:21 UTC (permalink / raw)
To: plagnioj, tomi.valkeinen, linux-fbdev, linux-kernel; +Cc: Masanari Iida
In-Reply-To: <1398774115-15353-1-git-send-email-standby24x7@gmail.com>
Fix format string mismatch in gbefb_show_memsize().
Signed-off-by: Masanari Iida <standby24x7@gmail.com>
---
drivers/video/fbdev/gbefb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/gbefb.c b/drivers/video/fbdev/gbefb.c
index 3ec65a8..4aa56ba 100644
--- a/drivers/video/fbdev/gbefb.c
+++ b/drivers/video/fbdev/gbefb.c
@@ -1068,7 +1068,7 @@ static struct fb_ops gbefb_ops = {
static ssize_t gbefb_show_memsize(struct device *dev, struct device_attribute *attr, char *buf)
{
- return snprintf(buf, PAGE_SIZE, "%d\n", gbe_mem_size);
+ return snprintf(buf, PAGE_SIZE, "%u\n", gbe_mem_size);
}
static DEVICE_ATTR(size, S_IRUGO, gbefb_show_memsize, NULL);
--
2.0.0.rc1
^ permalink raw reply related
* Re: [PATCH 06/23] ARM: OMAP: add OMAP5 DSI muxing
From: Tony Lindgren @ 2014-04-29 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <535F37E9.8090609@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140428 22:26]:
> On 28/04/14 19:45, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [140427 23:53]:
> >> On 25/04/14 18:31, Tony Lindgren wrote:
> >>
> >>> Chances are any mux register in the syscon area already works with
> >>> pinctrl-single,pins or pinctrl-single,bits option. The ones in the
> >>> padconf area should be already mapped so the driver just has to
> >>> request them.
> >>
> >> If using the padconf (say omap4_padconf_global for omap4), doesn't that
> >> mean we need to have platform specific bits in the driver? Isn't that
> >> something we've been trying to remove all the time?
> >
> > No, it's all done in a Linux generic way during driver probe, see
> > drivers/base/pinctrl.c. You just need to define the default pins
> > in the .dts files. If you need dynamic remuxing in the driver,
> > you can define other named states that the driver can then toggle
> > with pinctrl_select_state().
>
> omap4_padconf_global is a syscon node, not pinctrl. As syscon just gives
> a raw regmap to its memory area, the driver needs to know about the OMAP
> control registers to use it.
That would be probably best set up the same way we have already set up
for example omap4_padconf_global: tisyscon@4a1005a0. Then drivers can
access it using regmap, see how drivers/regulator/pbias-regulator.c
sets up the pbias regulator with regmap for MMC.
> Pinctrl-single cannot be used for CONTROL_DSIPHY register, as the
> register contents are a bit funny and DSI1 and DSI2 bits are mixed
> together. And CONTROL_DSIPHY is already in the memory region defined by
> the omap4_padconf_global, so I guess it wouldn't be good to map parts of
> the same memory region in a pinctrl node.
If it's more than a mux, then it should not be set up as a pinctrl
register. Looks like CONTROL_DSIPHY is already available for drivers
via regmap as it falls into the *_padconf_global mappings for omap4
and omap5.
Regards,
Tony
^ permalink raw reply
* [PATCH 1/3] drm/dsi: Support device shutdown
From: Thierry Reding @ 2014-04-29 15:28 UTC (permalink / raw)
To: dri-devel, linux-fbdev; +Cc: Stephen Warren
From: Thierry Reding <treding@nvidia.com>
Hook up the MIPI DSI bus's .shutdown() function to allow drivers to
implement code that should be run when a device is shut down.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
drivers/gpu/drm/drm_mipi_dsi.c | 10 ++++++++++
include/drm/drm_mipi_dsi.h | 2 ++
2 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index 09821f46d768..e633df2f68d8 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -282,6 +282,14 @@ static int mipi_dsi_drv_remove(struct device *dev)
return drv->remove(dsi);
}
+static void mipi_dsi_drv_shutdown(struct device *dev)
+{
+ struct mipi_dsi_driver *drv = to_mipi_dsi_driver(dev->driver);
+ struct mipi_dsi_device *dsi = to_mipi_dsi_device(dev);
+
+ drv->shutdown(dsi);
+}
+
/**
* mipi_dsi_driver_register - register a driver for DSI devices
* @drv: DSI driver structure
@@ -293,6 +301,8 @@ int mipi_dsi_driver_register(struct mipi_dsi_driver *drv)
drv->driver.probe = mipi_dsi_drv_probe;
if (drv->remove)
drv->driver.remove = mipi_dsi_drv_remove;
+ if (drv->shutdown)
+ drv->driver.shutdown = mipi_dsi_drv_shutdown;
return driver_register(&drv->driver);
}
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 7209df15a3cd..944f33f8ba38 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -135,11 +135,13 @@ ssize_t mipi_dsi_dcs_read(struct mipi_dsi_device *dsi, unsigned int channel,
* @driver: device driver model driver
* @probe: callback for device binding
* @remove: callback for device unbinding
+ * @shutdown: called at shutdown time to quiesce the device
*/
struct mipi_dsi_driver {
struct device_driver driver;
int(*probe)(struct mipi_dsi_device *dsi);
int(*remove)(struct mipi_dsi_device *dsi);
+ void (*shutdown)(struct mipi_dsi_device *dsi);
};
#define to_mipi_dsi_driver(d) container_of(d, struct mipi_dsi_driver, driver)
--
1.9.2
^ permalink raw reply related
* [PATCH 2/3] drm/panel: simple - Disable panel on shutdown
From: Thierry Reding @ 2014-04-29 15:28 UTC (permalink / raw)
To: dri-devel, linux-fbdev; +Cc: Stephen Warren
In-Reply-To: <1398785339-8107-1-git-send-email-thierry.reding@gmail.com>
From: Thierry Reding <treding@nvidia.com>
When a device is shut down, disable the panel to make sure the display
backlight doesn't stay lit.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
drivers/gpu/drm/panel/panel-simple.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 309f29e9234a..a790f4c337cf 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -262,6 +262,13 @@ static int panel_simple_remove(struct device *dev)
return 0;
}
+static void panel_simple_shutdown(struct device *dev)
+{
+ struct panel_simple *panel = dev_get_drvdata(dev);
+
+ panel_simple_disable(&panel->base);
+}
+
static const struct drm_display_mode auo_b101aw03_mode = {
.clock = 51450,
.hdisplay = 1024,
@@ -412,6 +419,11 @@ static int panel_simple_platform_remove(struct platform_device *pdev)
return panel_simple_remove(&pdev->dev);
}
+static void panel_simple_platform_shutdown(struct platform_device *pdev)
+{
+ panel_simple_shutdown(&pdev->dev);
+}
+
static struct platform_driver panel_simple_platform_driver = {
.driver = {
.name = "panel-simple",
@@ -420,6 +432,7 @@ static struct platform_driver panel_simple_platform_driver = {
},
.probe = panel_simple_platform_probe,
.remove = panel_simple_platform_remove,
+ .shutdown = panel_simple_platform_shutdown,
};
struct panel_desc_dsi {
@@ -561,6 +574,11 @@ static int panel_simple_dsi_remove(struct mipi_dsi_device *dsi)
return panel_simple_remove(&dsi->dev);
}
+static void panel_simple_dsi_shutdown(struct mipi_dsi_device *dsi)
+{
+ panel_simple_shutdown(&dsi->dev);
+}
+
static struct mipi_dsi_driver panel_simple_dsi_driver = {
.driver = {
.name = "panel-simple-dsi",
@@ -569,6 +587,7 @@ static struct mipi_dsi_driver panel_simple_dsi_driver = {
},
.probe = panel_simple_dsi_probe,
.remove = panel_simple_dsi_remove,
+ .shutdown = panel_simple_dsi_shutdown,
};
static int __init panel_simple_init(void)
--
1.9.2
^ permalink raw reply related
* [PATCH 3/3] pwm-backlight: Disable backlight on shutdown
From: Thierry Reding @ 2014-04-29 15:28 UTC (permalink / raw)
To: dri-devel, linux-fbdev; +Cc: Stephen Warren
In-Reply-To: <1398785339-8107-1-git-send-email-thierry.reding@gmail.com>
From: Thierry Reding <treding@nvidia.com>
When a device is shut down, make sure to disable the backlight. If it
stays lit, it gives the impression that the device hasn't turned off.
Furthermore keeping the backlight on may consume power, which is not
what users expect when they shut down a device.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
drivers/video/backlight/pwm_bl.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 994f424eb289..b85479b14971 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -368,6 +368,14 @@ static int pwm_backlight_remove(struct platform_device *pdev)
return 0;
}
+static void pwm_backlight_shutdown(struct platform_device *pdev)
+{
+ struct backlight_device *bl = platform_get_drvdata(pdev);
+ struct pwm_bl_data *pb = bl_get_data(bl);
+
+ pwm_backlight_power_off(pb);
+}
+
#ifdef CONFIG_PM_SLEEP
static int pwm_backlight_suspend(struct device *dev)
{
@@ -413,6 +421,7 @@ static struct platform_driver pwm_backlight_driver = {
},
.probe = pwm_backlight_probe,
.remove = pwm_backlight_remove,
+ .shutdown = pwm_backlight_shutdown,
};
module_platform_driver(pwm_backlight_driver);
--
1.9.2
^ permalink raw reply related
* Re: [PATCH 1/3] drm/dsi: Support device shutdown
From: Stephen Warren @ 2014-04-29 15:59 UTC (permalink / raw)
To: Thierry Reding, dri-devel, linux-fbdev
In-Reply-To: <1398785339-8107-1-git-send-email-thierry.reding@gmail.com>
On 04/29/2014 09:28 AM, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> Hook up the MIPI DSI bus's .shutdown() function to allow drivers to
> implement code that should be run when a device is shut down.
The series,
Tested-by: Stephen Warren <swarren@nvidia.com>
(On an NVIDIA Tegra Dalmore board. Now, the backlight actually turns off
when the system is shut down. Note that the backlight power on this
system is directly sourced from the AC adapter for some strange reason,
rather than passing through the main system PMIC, and hence backlight
power isn't shut off even when the rest of the system really is powered off)
^ permalink raw reply
* Re: [PATCH 06/23] ARM: OMAP: add OMAP5 DSI muxing
From: Tomi Valkeinen @ 2014-04-29 16:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140429150529.GA27571@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 816 bytes --]
On 29/04/14 18:05, Tony Lindgren wrote:
>> omap4_padconf_global is a syscon node, not pinctrl. As syscon just gives
>> a raw regmap to its memory area, the driver needs to know about the OMAP
>> control registers to use it.
>
> That would be probably best set up the same way we have already set up
> for example omap4_padconf_global: tisyscon@4a1005a0. Then drivers can
> access it using regmap, see how drivers/regulator/pbias-regulator.c
> sets up the pbias regulator with regmap for MMC.
Right, but it means that the driver will contain platform specific code
for all the omap revisions it supports. Isn't that wrong?
I already have a patch for DSI that uses the syscon-method, and it works
fine. But it's quite ugly, imo, to fiddle with the OMAP control
registers in a driver.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 06/23] ARM: OMAP: add OMAP5 DSI muxing
From: Tomi Valkeinen @ 2014-04-29 16:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <535FD10B.4020108@ti.com>
[-- Attachment #1: Type: text/plain, Size: 982 bytes --]
On 29/04/14 19:19, Tomi Valkeinen wrote:
> On 29/04/14 18:05, Tony Lindgren wrote:
>
>>> omap4_padconf_global is a syscon node, not pinctrl. As syscon just gives
>>> a raw regmap to its memory area, the driver needs to know about the OMAP
>>> control registers to use it.
>>
>> That would be probably best set up the same way we have already set up
>> for example omap4_padconf_global: tisyscon@4a1005a0. Then drivers can
>> access it using regmap, see how drivers/regulator/pbias-regulator.c
>> sets up the pbias regulator with regmap for MMC.
>
> Right, but it means that the driver will contain platform specific code
> for all the omap revisions it supports. Isn't that wrong?
>
> I already have a patch for DSI that uses the syscon-method, and it works
> fine. But it's quite ugly, imo, to fiddle with the OMAP control
> registers in a driver.
Oh, also, if I do that, I need to know both the SoC version and the DSS
version in the driver.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 06/23] ARM: OMAP: add OMAP5 DSI muxing
From: Tony Lindgren @ 2014-04-29 17:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <535FD43B.3030102@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140429 09:33]:
> On 29/04/14 19:19, Tomi Valkeinen wrote:
> > On 29/04/14 18:05, Tony Lindgren wrote:
> >
> >>> omap4_padconf_global is a syscon node, not pinctrl. As syscon just gives
> >>> a raw regmap to its memory area, the driver needs to know about the OMAP
> >>> control registers to use it.
> >>
> >> That would be probably best set up the same way we have already set up
> >> for example omap4_padconf_global: tisyscon@4a1005a0. Then drivers can
> >> access it using regmap, see how drivers/regulator/pbias-regulator.c
> >> sets up the pbias regulator with regmap for MMC.
> >
> > Right, but it means that the driver will contain platform specific code
> > for all the omap revisions it supports. Isn't that wrong?
> >
> > I already have a patch for DSI that uses the syscon-method, and it works
> > fine. But it's quite ugly, imo, to fiddle with the OMAP control
> > registers in a driver.
Anything using the system control module registers should be a separate
driver. And it should ideally be implemeting some Linux generic framework
that the consumer driver can then use. That leaves out the need to export
custom functions.
I guess we don't have a PHY framework for displays though, so how about
just a separate minimal driver under drivers/video/omap2 that uses the
syscon?
> Oh, also, if I do that, I need to know both the SoC version and the DSS
> version in the driver.
Don't you get all you need in the compatible string? Something like
compatible ti,dss-phy-omap5?
Regards,
Tony
^ permalink raw reply
* [PATCH 0/4] OMAPDSS: Add support for panel ls037v7dw01
From: Tony Lindgren @ 2014-04-29 23:52 UTC (permalink / raw)
To: linux-arm-kernel
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.
Regards,
Tony
Tony Lindgren (4):
OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
OMAPDSS: panel-sharp-ls037v7dw01: update to use gpiod
OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and
ldp
.../bindings/panel/sharp,ls037v7dw01.txt | 53 +++++++
.../arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi | 82 ++++++++++
arch/arm/boot/dts/omap3-evm-37xx.dts | 50 ++++++
arch/arm/boot/dts/omap3-evm-common.dtsi | 47 ++++++
arch/arm/boot/dts/omap3-ldp.dts | 31 +++-
.../omap2/displays-new/panel-sharp-ls037v7dw01.c | 176 ++++++++++++++-------
drivers/video/fbdev/omap2/dss/dss.c | 5 +-
7 files changed, 379 insertions(+), 65 deletions(-)
create mode 100644 Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt
create mode 100644 arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
--
1.8.1.1
^ permalink raw reply
* [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
From: Tony Lindgren @ 2014-04-29 23:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1398815562-24113-1-git-send-email-tony@atomide.com>
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.
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
^ permalink raw reply related
* [PATCH 2/4] OMAPDSS: panel-sharp-ls037v7dw01: update to use gpiod
From: Tony Lindgren @ 2014-04-29 23:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1398815562-24113-1-git-send-email-tony@atomide.com>
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>
---
.../omap2/displays-new/panel-sharp-ls037v7dw01.c | 92 +++++++++-------------
1 file changed, 38 insertions(+), 54 deletions(-)
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 b2f710b..de8473a 100644
--- 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_err(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,16 @@ 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");
+ ddata->lr_gpio = sharp_ls_get_gpio(&pdev->dev, pdata->lr_gpio,
+ GPIOF_OUT_INIT_HIGH, "lcd LR");
+ ddata->ud_gpio = sharp_ls_get_gpio(&pdev->dev, pdata->ud_gpio,
+ GPIOF_OUT_INIT_HIGH, "lcd UD");
+ ddata->resb_gpio = sharp_ls_get_gpio(&pdev->dev, pdata->resb_gpio,
+ GPIOF_OUT_INIT_LOW, "lcd RESB");
+ ddata->ini_gpio = sharp_ls_get_gpio(&pdev->dev, pdata->ini_gpio,
+ GPIOF_OUT_INIT_LOW, "lcd INI");
return 0;
}
@@ -233,41 +253,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 +272,6 @@ static int sharp_ls_probe(struct platform_device *pdev)
return 0;
err_reg:
-err_gpio:
omap_dss_put_device(ddata->in);
return r;
}
--
1.8.1.1
^ permalink raw reply related
* [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tony Lindgren @ 2014-04-29 23:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1398815562-24113-1-git-send-email-tony@atomide.com>
We can pass the GPIO configuration for ls037v7dw01 in a standard
gpios property.
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
.../bindings/panel/sharp,ls037v7dw01.txt | 53 ++++++++++++++
.../omap2/displays-new/panel-sharp-ls037v7dw01.c | 84 ++++++++++++++++++++--
2 files changed, 133 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt
diff --git a/Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt b/Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt
new file mode 100644
index 0000000..7f6f5e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt
@@ -0,0 +1,53 @@
+SHARP LS037V7DW01 TFT-LCD panel
+
+Required properties:
+- compatible: should be "sharp,ls037v7dw01"
+
+Optional properties:
+- reset-gpios: a GPIO spec for the optional reset pin
+- enable-gpios: a GPIO array for the optional configuration GPIOs
+ ordered MO, LR, UD, INI 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>;
+ reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>; /* gpio155, lcd RESB */
+ enable-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 */
+ &gpio5 24 GPIO_ACTIVE_HIGH>; /* gpio152, lcd INI */
+
+ 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>;
+ };
+ };
+ };
+
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 de8473a..3a04fb0 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,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);
@@ -230,6 +235,67 @@ static int sharp_ls_probe_pdata(struct platform_device *pdev)
ddata->ini_gpio = sharp_ls_get_gpio(&pdev->dev, pdata->ini_gpio,
GPIOF_OUT_INIT_LOW, "lcd INI");
+ 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))
+ 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;
+ }
+
+ ddata->resb_gpio = sharp_ls_get_gpio_of(&pdev->dev, 0, 0, "reset"); /* lcd RESB */
+ ddata->mo_gpio = sharp_ls_get_gpio_of(&pdev->dev, 0, 0, "enable"); /* lcd MO */
+ ddata->lr_gpio = sharp_ls_get_gpio_of(&pdev->dev, 1, 1, "enable"); /* lcd LR */
+ ddata->ud_gpio = sharp_ls_get_gpio_of(&pdev->dev, 2, 1, "enable"); /* lcd UD */
+ ddata->ini_gpio = sharp_ls_get_gpio_of(&pdev->dev, 3, 0, "enable"); /* lcd INI */
+
+ 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;
}
@@ -249,12 +315,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;
@@ -292,12 +360,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,
},
};
--
1.8.1.1
^ permalink raw reply related
* [PATCH 4/4] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp
From: Tony Lindgren @ 2014-04-29 23:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1398815562-24113-1-git-send-email-tony@atomide.com>
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>
---
.../arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi | 82 ++++++++++++++++++++++
arch/arm/boot/dts/omap3-evm-37xx.dts | 50 +++++++++++++
arch/arm/boot/dts/omap3-evm-common.dtsi | 47 +++++++++++++
arch/arm/boot/dts/omap3-ldp.dts | 31 ++++++--
4 files changed, 205 insertions(+), 5 deletions(-)
create mode 100644 arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
diff --git a/arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi b/arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
new file mode 100644
index 0000000..f5252da
--- /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;
+ };
+};
diff --git a/arch/arm/boot/dts/omap3-evm-37xx.dts b/arch/arm/boot/dts/omap3-evm-37xx.dts
index 4df68ad..a181e30 100644
--- 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>;
diff --git a/arch/arm/boot/dts/omap3-evm-common.dtsi b/arch/arm/boot/dts/omap3-evm-common.dtsi
index 3007e79..0ab9650 100644
--- 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 {
+ 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.
+ */
+ enable-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 */
+ &gpio5 24 GPIO_ACTIVE_HIGH>; /* gpio152, lcd INI */
+
+ 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>;
diff --git a/arch/arm/boot/dts/omap3-ldp.dts b/arch/arm/boot/dts/omap3-ldp.dts
index 0abe986..50fdac9 100644
--- a/arch/arm/boot/dts/omap3-ldp.dts
+++ b/arch/arm/boot/dts/omap3-ldp.dts
@@ -164,6 +164,7 @@
#include "twl4030.dtsi"
#include "twl4030_omap3.dtsi"
+#include "omap-panel-sharp-ls037v7dw01.dtsi"
&i2c2 {
clock-frequency = <400000>;
@@ -173,6 +174,31 @@
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 */
+ gpios = <&gpio2 24 GPIO_ACTIVE_LOW /* gpio56, lcd MO */
+ 0 /* lcd LR */
+ 0 /* lcd UD */
+ 0>; /* lcd INI */
+};
+
+&backlight0 {
+ gpios = <&twl_gpio 15 GPIO_ACTIVE_LOW>;
+};
+
+&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 +273,3 @@
/* Needed for ads7846 */
regulator-name = "vcc";
};
-
-&vpll2 {
- /* Needed for DSS */
- regulator-name = "vdds_dsi";
-};
--
1.8.1.1
^ permalink raw reply related
* Re: [PATCH 4/4] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp
From: Joachim Eastwood @ 2014-04-30 1:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1398815562-24113-5-git-send-email-tony@atomide.com>
On 30 April 2014 01:52, Tony Lindgren <tony@atomide.com> wrote:
> 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>
> ---
> .../arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi | 82 ++++++++++++++++++++++
> arch/arm/boot/dts/omap3-evm-37xx.dts | 50 +++++++++++++
> arch/arm/boot/dts/omap3-evm-common.dtsi | 47 +++++++++++++
> arch/arm/boot/dts/omap3-ldp.dts | 31 ++++++--
> 4 files changed, 205 insertions(+), 5 deletions(-)
> create mode 100644 arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
> diff --git a/arch/arm/boot/dts/omap3-ldp.dts b/arch/arm/boot/dts/omap3-ldp.dts
> index 0abe986..50fdac9 100644
> --- a/arch/arm/boot/dts/omap3-ldp.dts
> +++ b/arch/arm/boot/dts/omap3-ldp.dts
> @@ -164,6 +164,7 @@
>
> #include "twl4030.dtsi"
> #include "twl4030_omap3.dtsi"
> +#include "omap-panel-sharp-ls037v7dw01.dtsi"
>
> &i2c2 {
> clock-frequency = <400000>;
> @@ -173,6 +174,31 @@
> 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 */
> + gpios = <&gpio2 24 GPIO_ACTIVE_LOW /* gpio56, lcd MO */
enable-gpios ?
> + 0 /* lcd LR */
> + 0 /* lcd UD */
> + 0>; /* lcd INI */
> +};
regards
Joachim Eastwood
^ permalink raw reply
* Re: [PATCH 06/23] ARM: OMAP: add OMAP5 DSI muxing
From: Tomi Valkeinen @ 2014-04-30 6:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140429173838.GB27571@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 2979 bytes --]
On 29/04/14 20:38, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [140429 09:33]:
>> On 29/04/14 19:19, Tomi Valkeinen wrote:
>>> On 29/04/14 18:05, Tony Lindgren wrote:
>>>
>>>>> omap4_padconf_global is a syscon node, not pinctrl. As syscon just gives
>>>>> a raw regmap to its memory area, the driver needs to know about the OMAP
>>>>> control registers to use it.
>>>>
>>>> That would be probably best set up the same way we have already set up
>>>> for example omap4_padconf_global: tisyscon@4a1005a0. Then drivers can
>>>> access it using regmap, see how drivers/regulator/pbias-regulator.c
>>>> sets up the pbias regulator with regmap for MMC.
>>>
>>> Right, but it means that the driver will contain platform specific code
>>> for all the omap revisions it supports. Isn't that wrong?
>>>
>>> I already have a patch for DSI that uses the syscon-method, and it works
>>> fine. But it's quite ugly, imo, to fiddle with the OMAP control
>>> registers in a driver.
>
> Anything using the system control module registers should be a separate
> driver. And it should ideally be implemeting some Linux generic framework
> that the consumer driver can then use. That leaves out the need to export
> custom functions.
Ok.
> I guess we don't have a PHY framework for displays though, so how about
> just a separate minimal driver under drivers/video/omap2 that uses the
> syscon?
Well, this one is not really about DSI PHY. The CONTROL_DSIPHY register
is not in the DSI PHY block, but in the control module, and it is used
to enable/disable the pins (for omap4/5) and to set pull up/down for the
pins (only for omap4). Oddly, for omap5, there's also a normal padconfig
register for the DSI pins, but not so for omap4.
To me it looks like a pad config register. I don't know why there's a
separate odd register for it and it's not using the normal padconfig system.
I'd like to use the pinctrl framework for it, but the pinctrl-single
cannot handle such a funny register. So, if "Anything using the system
control module registers should be a separate driver", then I guess I
need to write a pinctrl driver for this single register?
>> Oh, also, if I do that, I need to know both the SoC version and the DSS
>> version in the driver.
>
> Don't you get all you need in the compatible string? Something like
> compatible ti,dss-phy-omap5?
We do use different compatible strings for different major versions of
the DSS blocks, like ti,omap5-dsi. But that exactly same DSS block could
be used on some other SoC, with different control stuff.
We could use separate compatible string for each SoC that uses DSS, but
then we're really encoding the SoC version into the compatible string,
not DSS version.
Of course, if there will be a separate driver managing the
CONTROL_DSIPHY register, then that one should use compatible string
specific to the SoC, as it's not a DSS driver at all.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] video: fbdev: Fix format string mismatch in wm8505fb.c
From: Tomi Valkeinen @ 2014-04-30 8:26 UTC (permalink / raw)
To: Masanari Iida, plagnioj, linux-fbdev, linux-kernel
In-Reply-To: <1398774115-15353-1-git-send-email-standby24x7@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 862 bytes --]
On 29/04/14 15:21, Masanari Iida wrote:
> Fix format string mismatch in contrast_show().
>
> Signed-off-by: Masanari Iida <standby24x7@gmail.com>
> ---
> drivers/video/fbdev/wm8505fb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/wm8505fb.c b/drivers/video/fbdev/wm8505fb.c
> index 537d199..d2fafbb 100644
> --- a/drivers/video/fbdev/wm8505fb.c
> +++ b/drivers/video/fbdev/wm8505fb.c
> @@ -162,7 +162,7 @@ static ssize_t contrast_show(struct device *dev,
> struct fb_info *info = dev_get_drvdata(dev);
> struct wm8505fb_info *fbi = to_wm8505fb_info(info);
>
> - return sprintf(buf, "%d\n", fbi->contrast);
> + return sprintf(buf, "%u\n", fbi->contrast);
> }
>
> static ssize_t contrast_store(struct device *dev,
>
Thanks, queued this and the 2/2 patch for 3.16.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] video: mmp: Remove references to CPU_MMP3
From: Tomi Valkeinen @ 2014-04-30 8:37 UTC (permalink / raw)
To: Paul Bolle, Jean-Christophe Plagniol-Villard
Cc: Richard Weinberger, linux-fbdev, linux-kernel
In-Reply-To: <1397561044.1985.47.camel@x220>
[-- Attachment #1: Type: text/plain, Size: 434 bytes --]
On 15/04/14 14:24, Paul Bolle wrote:
> From: Richard Weinberger <richard@nod.at>
>
> References to the Kconfig symbol CPU_MMP3 were added to the tree since
> v3.6. But that Kconfig symbol has never been part of the tree. So get
> rid of these references.
>
> Signed-off-by: Richard Weinberger <richard@nod.at>
> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Thanks, queued this and the 2/2 patch for 3.16.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] fbdev: omap2: Fix format string mismatch in display-sysfs.c
From: Tomi Valkeinen @ 2014-04-30 8:43 UTC (permalink / raw)
To: Jingoo Han, 'Masanari Iida'
Cc: 'Jean-Christophe Plagniol-Villard', linux-fbdev,
linux-omap
In-Reply-To: <002401cf62d3$634cc1f0$29e645d0$%han@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 2094 bytes --]
On 28/04/14 14:17, Jingoo Han wrote:
> On Monday, April 28, 2014 7:54 PM, Masanari Iida wrote:
>>
>> Fix two format string mismatch in display-sysfs.c
>>
>> Signed-off-by: Masanari Iida <standby24x7@gmail.com>
>> ---
>> drivers/video/fbdev/omap2/dss/display-sysfs.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/video/fbdev/omap2/dss/display-sysfs.c b/drivers/video/fbdev/omap2/dss/display-
>> sysfs.c
>> index 5a2095a..5928bc9 100644
>> --- a/drivers/video/fbdev/omap2/dss/display-sysfs.c
>> +++ b/drivers/video/fbdev/omap2/dss/display-sysfs.c
>> @@ -184,7 +184,7 @@ static ssize_t display_rotate_show(struct device *dev,
>> if (!dssdev->driver->get_rotate)
>> return -ENOENT;
>> rotate = dssdev->driver->get_rotate(dssdev);
>
> According to 'struct omap_dss_driver', get_rotate() returns 'u8'.
> Then, how about changing the type of 'rotate' variable from 'int'
> to 'u8' as below?
>
> --- a/drivers/video/fbdev/omap2/dss/display-sysfs.c
> +++ b/drivers/video/fbdev/omap2/dss/display-sysfs.c
> @@ -180,7 +180,7 @@ static ssize_t display_rotate_show(struct device *dev,
> struct device_attribute *attr, char *buf)
> {
> struct omap_dss_device *dssdev = to_dss_device_sysfs(dev);
> - int rotate;
> + u8 rotate;
> if (!dssdev->driver->get_rotate)
> return -ENOENT;
> rotate = dssdev->driver->get_rotate(dssdev);
>
>
> Best regards,
> Jingoo Han
>
>> - return snprintf(buf, PAGE_SIZE, "%u\n", rotate);
>> + return snprintf(buf, PAGE_SIZE, "%d\n", rotate);
>> }
>>
>> static ssize_t display_rotate_store(struct device *dev,
>> @@ -215,7 +215,7 @@ static ssize_t display_mirror_show(struct device *dev,
>> if (!dssdev->driver->get_mirror)
>> return -ENOENT;
>> mirror = dssdev->driver->get_mirror(dssdev);
>> - return snprintf(buf, PAGE_SIZE, "%u\n", mirror);
>> + return snprintf(buf, PAGE_SIZE, "%d\n", mirror);
>> }
And get_mirror returns a bool, not int, so I guess that could be fixed also.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [patch] video: mmpfb: cleanup some static checker warnings in probe()
From: Tomi Valkeinen @ 2014-04-30 10:58 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20140414080929.GB13372@mwanda>
[-- Attachment #1: Type: text/plain, Size: 515 bytes --]
On 14/04/14 11:09, Dan Carpenter wrote:
> Sparse complains about using zero instead of NULL for pointers.
> Probably, if we enabled the warning, then GCC would complain about the
> unused initializers. I've just removed them.
>
> Smatch complains that we first check if "fbi" is NULL and then
> dereference it in the error handling. It turns out that "fbi" can't be
> NULL so I've removed the check.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Thanks, queued for 3.16.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH V2] video: pxa3xx-gcu: use devm_ioremap_resource()
From: Tomi Valkeinen @ 2014-04-30 11:02 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <008201cf52e6$7314ea60$593ebf20$%han@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 475 bytes --]
On 08/04/14 07:53, Jingoo Han wrote:
> Use devm_ioremap_resource() because devm_request_and_ioremap() is
> obsoleted by devm_ioremap_resource().
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
> Cc: Daniel Mack <zonque@gmail.com>
> Cc: Dan Carpenter <dan.carpenter@oracle.com>
> ---
> Changes since v1:
> - remove unnecessary error message, because devm_ioremap_resource()
> already prints one in all failure cases.
Thanks, queued for 3.16.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2] fbdev: Fix tmiofb driver dependencies
From: Tomi Valkeinen @ 2014-04-30 11:05 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20140424103258.4083cb69@endymion.delvare>
[-- Attachment #1: Type: text/plain, Size: 1155 bytes --]
On 24/04/14 11:32, Jean Delvare wrote:
> The tmiofb driver should not depend on MFD_CORE but on MFD_TMIO.
> Without the tmio_core driver, tmiofb has no platform device to bind
> to and is thus useless.
>
> Signed-off-by: Jean Delvare <jdelvare@suse.de>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> I suspect that MFD_TMIO was originally intended and MFD_CORE was a
> typo.
>
> Changes since v1:
> * Added COMPILE_TEST as suggested by Geert Uytterhoeven.
>
> drivers/video/fbdev/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- linux-3.15-rc2.orig/drivers/video/fbdev/Kconfig 2014-04-23 11:51:17.163933232 +0200
> +++ linux-3.15-rc2/drivers/video/fbdev/Kconfig 2014-04-24 09:49:07.433062918 +0200
> @@ -1993,7 +1993,7 @@ config FB_SH_MOBILE_HDMI
>
> config FB_TMIO
> tristate "Toshiba Mobile IO FrameBuffer support"
> - depends on FB && MFD_CORE
> + depends on FB && (MFD_TMIO || COMPILE_TEST)
> select FB_CFB_FILLRECT
> select FB_CFB_COPYAREA
> select FB_CFB_IMAGEBLIT
Thanks, queued for 3.16.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/3] video: clps711x: Add new Cirrus Logic CLPS711X framebuffer driver
From: Tomi Valkeinen @ 2014-04-30 11:14 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1397285583-15187-1-git-send-email-shc_work@mail.ru>
[-- Attachment #1: Type: text/plain, Size: 1369 bytes --]
On 24/04/14 19:35, Alexander Shiyan wrote:
>> The right way to do it is, as I wrote above, by gradually changing the
>> old driver with a patch series. And my question is, why not do it that
>> way? Then it would be possible to review the patches one by one, seeing
>> what has changed.
>
> "gradually changing"...
> I repeat that this is not an old modified driver, but written new.
Yes, I understand that. Again, my question is, why didn't you modify the
old driver? That's how things should normally be done. Instead, you made
a totally new one, making proper review against the old driver impossible.
> if you imagine a new file as a diff to the old, this can be clearly seen.
>
> There is no reason to waste time on a series of changes since I
> can not even check these changes on real hardware, but only in the
> last stage when the driver will be the current version.
Hmm what? So is the old driver totally broken, and cannot be used at the
moment? Or why you can't test on real hardware?
Note that I don't know anything about the fb hardware in question, nor
the driver. Maybe there's a valid reason to write a new driver from
scratch. But there very rarely is.
And "because I already wrote a new driver, and it's a waste of time for
me to throw away my work and patch the old one", is not a very good reason.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/3] video: clps711x: Add new C =?UTF-8?B?aXJydXMgTG9naWMgQ
From: Alexander Shiyan @ 2014-04-30 12:36 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1398327006.501536964@f133.i.mail.ru>
V2VkLCAzMCBBcHIgMjAxNCAxNDoxNDozNiArMDMwMCDQvtGCIFRvbWkgVmFsa2VpbmVuIDx0b21p
LnZhbGtlaW5lbkB0aS5jb20+Ogo+IE9uIDI0LzA0LzE0IDE5OjM1LCBBbGV4YW5kZXIgU2hpeWFu
IHdyb3RlOgoKSGVsbG8uCgpJJ20gYSByZW9yZGVyIHF1b3RlcyBhIGJpdCBmb3IgY29udmVuaWVu
Y2UuCgo+ID4+IFRoZSByaWdodCB3YXkgdG8gZG8gaXQgaXMsIGFzIEkgd3JvdGUgYWJvdmUsIGJ5
IGdyYWR1YWxseSBjaGFuZ2luZyB0aGUKPiA+PiBvbGQgZHJpdmVyIHdpdGggYSBwYXRjaCBzZXJp
ZXMuIEFuZCBteSBxdWVzdGlvbiBpcywgd2h5IG5vdCBkbyBpdCB0aGF0Cj4gPj4gd2F5PyBUaGVu
IGl0IHdvdWxkIGJlIHBvc3NpYmxlIHRvIHJldmlldyB0aGUgcGF0Y2hlcyBvbmUgYnkgb25lLCBz
ZWVpbmcKPiA+PiB3aGF0IGhhcyBjaGFuZ2VkLgo+ID4gCj4gPiAiZ3JhZHVhbGx5IGNoYW5naW5n
Ii4uLgo+ID4gSSByZXBlYXQgdGhhdCB0aGlzIGlzIG5vdCBhbiBvbGQgbW9kaWZpZWQgZHJpdmVy
LCBidXQgd3JpdHRlbiBuZXcuCj4gCj4gWWVzLCBJIHVuZGVyc3RhbmQgdGhhdC4gQWdhaW4sIG15
IHF1ZXN0aW9uIGlzLCB3aHkgZGlkbid0IHlvdSBtb2RpZnkgdGhlCj4gb2xkIGRyaXZlcj8gVGhh
dCdzIGhvdyB0aGluZ3Mgc2hvdWxkIG5vcm1hbGx5IGJlIGRvbmUuIEluc3RlYWQsIHlvdSBtYWRl
Cj4gYSB0b3RhbGx5IG5ldyBvbmUsIG1ha2luZyBwcm9wZXIgcmV2aWV3IGFnYWluc3QgdGhlIG9s
ZCBkcml2ZXIgaW1wb3NzaWJsZS4KLi4uCj4gSG1tIHdoYXQ/IFNvIGlzIHRoZSBvbGQgZHJpdmVy
IHRvdGFsbHkgYnJva2VuLCBhbmQgY2Fubm90IGJlIHVzZWQgYXQgdGhlCj4gbW9tZW50PyBPciB3
aHkgeW91IGNhbid0IHRlc3Qgb24gcmVhbCBoYXJkd2FyZT8KCkZpcnN0bHksIHRoZSBkcml2ZXIg
dXNlcyBhIGZpeGVkIHZhbHVlcyBmb3IgeHJlcywgeXJlcywgcGl4Y2xvY2sgYW5kIHNwZWNpZmlj
CnZhcmlhYmxlIGFjX3ByZWNhbGUuClNlY29uZGx5LCB0aGUgZHJpdmVyIHVzZXMgYSBmaXhlZCB2
YWx1ZSBmb3IgdGhlIHBoeXNpY2FsIGFkZHJlc3Mgb2YgdGhlIGJ1ZmZlci4KVG90YWxseSwgaXQg
ZG9lcyBub3QgZ2l2ZSBtZSB0aGUgYWJpbGl0eSB0byB1c2UgdGhlIGRyaXZlciBpbiB0aGUgY3Vy
cmVudCBzdGF0ZS4KVW5saWtlbHkgdGhhdCB0aGlzIHdpbGwgbG9vayBnb29kIGlmIEkgbWFrZSB0
aGVzZSB0d28gc2lnbmlmaWNhbnQgY2hhbmdlcyBpbgphIHNpbmdsZSBwYXRjaC4uLgoKQXQgdGhp
cyB0aW1lIHRoZSBkcml2ZXIgaGFzIHRocmVlIHVzZXIuCk9ubHkgb25lIG9mIHRoZW0gc2hvdWxk
IHRoZW9yZXRpY2FsbHkgd29yay4KY2xwczcxMXgtYXV0Y3B1MTIgc2hvdWxkIG5vdCB3b3JrIGlu
IHRoZSBhYnNlbmNlIG9mIG1lbWJsb2NrX3Jlc2VydmUoKS4KY2xwczcxMXgtcDcyMHQgc2hvdWxk
IG5vdCB3b3JrIGR1ZSB0byBwaHlzaWNhbCBhZGRyZXNzIGxpbWl0YXRpb24gYXMgaQpub3RpY2Vk
IGJlZm9yZS4gQm9hcmQgbWVhbnMgdG8gdXNlIFNSQU0gaW5zdGVhZCBvZiBTRFJBTS4KT25seSBj
bHBzNzExeC1lZGI3MjExIHNob3VsZCB3b3JrIGZpbmUgKGluIHRoZW9yeSkuCklzIHRoaXMgYSBn
b29kIHJlYXNvbiB0byByZXBsYWNlIHRoZSBkcml2ZXI/IEkgdGhpbmsgeWVzLgoKPiBOb3RlIHRo
YXQgSSBkb24ndCBrbm93IGFueXRoaW5nIGFib3V0IHRoZSBmYiBoYXJkd2FyZSBpbiBxdWVzdGlv
biwgbm9yCj4gdGhlIGRyaXZlci4gTWF5YmUgdGhlcmUncyBhIHZhbGlkIHJlYXNvbiB0byB3cml0
ZSBhIG5ldyBkcml2ZXIgZnJvbQo+IHNjcmF0Y2guIEJ1dCB0aGVyZSB2ZXJ5IHJhcmVseSBpcy4K
PiAKPiBBbmQgImJlY2F1c2UgSSBhbHJlYWR5IHdyb3RlIGEgbmV3IGRyaXZlciwgYW5kIGl0J3Mg
YSB3YXN0ZSBvZiB0aW1lIGZvcgo+IG1lIHRvIHRocm93IGF3YXkgbXkgd29yayBhbmQgcGF0Y2gg
dGhlIG9sZCBvbmUiLCBpcyBub3QgYSB2ZXJ5IGdvb2QgcmVhc29uLgoKPiA+IGlmIHlvdSBpbWFn
aW5lIGEgbmV3IGZpbGUgYXMgYSBkaWZmIHRvIHRoZSBvbGQsIHRoaXMgY2FuIGJlIGNsZWFybHkg
c2Vlbi4KPiA+IAo+ID4gVGhlcmUgaXMgbm8gcmVhc29uIHRvIHdhc3RlIHRpbWUgb24gYSBzZXJp
ZXMgb2YgY2hhbmdlcyBzaW5jZSBJCj4gPiBjYW4gbm90IGV2ZW4gY2hlY2sgdGhlc2UgY2hhbmdl
cyBvbiByZWFsIGhhcmR3YXJlLCBidXQgb25seSBpbiB0aGUKPiA+IGxhc3Qgc3RhZ2Ugd2hlbiB0
aGUgZHJpdmVyIHdpbGwgYmUgdGhlIGN1cnJlbnQgdmVyc2lvbi4KClN1bW1pbmcgdXAsIEkgd2Fu
dCB0byBhc2sgd2h5IHRoZSBkcml2ZXIgY2FuIG5vdCBiZSByZXZpZXdlZCBhcyBhCm5ldyBhbmQg
bm90IGNvbXBhcmVkIHRvIHRoZSBvbGQ/CkFuZCB5ZXMsIHRoZSB0aW1lIGNhbiBiZSBzcGVudCBv
biBtb3JlIHByb2R1Y3RpdmUgdGhpbmdzIHRvIGRvIHRoYW4KdG8gY3JlYXRlIGEgc2VyaWVzLCBs
ZWFkaW5nIGV2ZW50dWFsbHkgdG8gdGhlIHNhbWUgcmVzdWx0LgpBcyBmYXIgYXMgSSBrbm93LCBn
dWlkZSB0byBjcmVhdGluZyBrZXJuZWwgcGF0Y2hlcyBhbGxvd3Mgc3VjaCBjYXNlcy4KClRoYW5r
cy4KCi0tLQoK
^ permalink raw reply
* Re: [PATCH 4/4] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp
From: Tony Lindgren @ 2014-04-30 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGhQ9Vwa8xXQEo5dNEKAvmaS9DoBjVSthtd8=owk+atVdFuiiA@mail.gmail.com>
* Joachim Eastwood <manabian@gmail.com> [140429 18:08]:
> On 30 April 2014 01:52, Tony Lindgren <tony@atomide.com> wrote:
> > 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>
> > ---
> > .../arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi | 82 ++++++++++++++++++++++
> > arch/arm/boot/dts/omap3-evm-37xx.dts | 50 +++++++++++++
> > arch/arm/boot/dts/omap3-evm-common.dtsi | 47 +++++++++++++
> > arch/arm/boot/dts/omap3-ldp.dts | 31 ++++++--
> > 4 files changed, 205 insertions(+), 5 deletions(-)
> > create mode 100644 arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
>
> > diff --git a/arch/arm/boot/dts/omap3-ldp.dts b/arch/arm/boot/dts/omap3-ldp.dts
> > index 0abe986..50fdac9 100644
> > --- a/arch/arm/boot/dts/omap3-ldp.dts
> > +++ b/arch/arm/boot/dts/omap3-ldp.dts
> > @@ -164,6 +164,7 @@
> >
> > #include "twl4030.dtsi"
> > #include "twl4030_omap3.dtsi"
> > +#include "omap-panel-sharp-ls037v7dw01.dtsi"
> >
> > &i2c2 {
> > clock-frequency = <400000>;
> > @@ -173,6 +174,31 @@
> > 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 */
> > + 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.
Tony
^ 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