* LOAN
From: Bakker, K. @ 2014-04-28 17:30 UTC (permalink / raw)
Dear valued customer,
Do you need an urgent loan to pay of your bills, invest more on your business, if yes PREMIUM CAPITAL LOAN offer loan at 3% interest rate. We are fast and reliable when it comes to loan lending contact email: premiumcapitalloan@hotmail.co.uk for more information.
Contact email: premiumcapitalloan@hotmail.co.uk
^ permalink raw reply
* Re: [PATCH 06/23] ARM: OMAP: add OMAP5 DSI muxing
From: Tomi Valkeinen @ 2014-04-29 5:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140428164528.GM20807@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 1419 bytes --]
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.
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.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH 1/2] video: fbdev: Fix format string mismatch in wm8505fb.c
From: Masanari Iida @ 2014-04-29 12:21 UTC (permalink / raw)
To: plagnioj, tomi.valkeinen, linux-fbdev, linux-kernel; +Cc: Masanari Iida
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,
--
2.0.0.rc1
^ permalink raw reply related
* [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
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