RE: [PATCH v4 4/4] OMAP: DSS: Add picodlp panel driver
-Original Message- From: Valkeinen, Tomi Sent: Monday, May 16, 2011 12:29 PM To: Janorkar, Mayuresh Cc: linux-omap@vger.kernel.org; K, Mythri P Subject: RE: [PATCH v4 4/4] OMAP: DSS: Add picodlp panel driver On Mon, 2011-05-16 at 09:54 +0530, Janorkar, Mayuresh wrote: -Original Message- From: Valkeinen, Tomi Sent: Thursday, May 12, 2011 8:40 PM To: Janorkar, Mayuresh Cc: linux-omap@vger.kernel.org; K, Mythri P Well, when is picodlp_i2c_remove() called? Isn't it called when the i2c client is being removed, i.e. when somebody has called i2c_unregister_device()? The matching API for i2c_add_device is i2c_del_device. These are _driver_ functions not device. And i2c_unregister_device is a matching API for i2c_new_device. i2c_del_device (a call present in picodlp_exit) would call i2c_remove and then i2c_remove has a call to i2c_unregister_device which would unregister the i2c_device. So panel_remove should also have a call to i2c_unregister_device. This would solve the problem. I believe panel_remove should be the only place to have i2c_unregister_device. It is, as you said, counterpart of i2c_new_device, and that is called from panel_probe. Looks fine. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/6] OMAP: LDP: Port the display driver to new DSS2
-Original Message-
From: Valkeinen, Tomi
Sent: Monday, May 16, 2011 2:23 PM
To: Igor Grinberg
Cc: Janorkar, Mayuresh; t...@atomide.com; linux-omap@vger.kernel.org;
Stanley Miao
Subject: Re: [PATCH 4/6] OMAP: LDP: Port the display driver to new DSS2
On Thu, 2011-05-12 at 09:40 +0300, Igor Grinberg wrote:
On 05/11/11 09:32, Tomi Valkeinen wrote:
On Wed, 2011-05-11 at 10:28 +0530, Janorkar, Mayuresh wrote:
+static void __init ldp_display_init(void)
+{
+ int r;
+
+ struct gpio gpios[] = {
+ {LCD_PANEL_RESET_GPIO, GPIOF_OUT_INIT_HIGH, LCD
RESET},
+ {LCD_PANEL_QVGA_GPIO, GPIOF_OUT_INIT_HIGH, LCD QVGA},
+ {LCD_PANEL_ENABLE_GPIO, GPIOF_OUT_INIT_LOW, LCD
ENABLE},
+ {LCD_PANEL_BACKLIGHT_GPIO, GPIOF_OUT_INIT_LOW, LCD
BACKLIGHT},
+ };
+
+ r = gpio_request_array(gpios, ARRAY_SIZE(gpios));
+ if (r) {
+ pr_err(Cannot request LCD GPIOs, error %d\n, r);
+ return;
+ }
If I test with this patch, this request is returning error.
Hmm. Well, the GPIOs are the same as in the old driver. However, the
old
driver doesn't even seem to check if it manages to request the GPIOs,
so
it may well be that it was failing also.
Can you check from /sys/class/gpio/ if some of the GPIOs are already
allocated: 207, 199, 55, 56?
The definition of two of those GPIOs look kinda funny to me: (15 +
OMAP_MAX_GPIO_LINES). I don't know what OMAP_MAX_GPIO_LINES means, but
it sure doesn't sound ok to have a GPIO number that is 15 over the
maximum =).
This means that some kind of gpio expander is used.
I bet those are twl gpios (or may be some other discrete chip).
If those are twl gpios then you need to provide the .setup callback
in struct twl4030_gpio_platform_data which will request and setup those
gpios.
Here's an updated patch with the twl gpio code.
All the old omapfb porting patches, including new drivers for DSS2, can
be found from
git://gitorious.org/linux-omap-dss2/linux.git old-omapfb-port
Tomi
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-
ldp.c
index e2ba779..ed78b9a 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -44,6 +44,9 @@
#include asm/delay.h
#include plat/usb.h
+#include video/omapdss.h
+#include video/omap-panel-generic-dpi.h
+
#include board-flash.h
#include mux.h
#include hsmmc.h
@@ -275,19 +278,70 @@ static inline void __init ldp_init_smsc911x(void)
gpio_direction_input(eth_gpio);
}
-static struct platform_device ldp_lcd_device = {
- .name = ldp_lcd,
- .id = -1,
+/* LCD */
+
+static int ldp_backlight_gpio;
+static int ldp_lcd_enable_gpio;
+
+#define LCD_PANEL_RESET_GPIO 55
+#define LCD_PANEL_QVGA_GPIO 56
+
+static int ldp_panel_enable_lcd(struct omap_dss_device *dssdev)
+{
+ gpio_direction_output(ldp_lcd_enable_gpio, 1);
+ gpio_direction_output(ldp_backlight_gpio, 1);
+
+ return 0;
+}
+
+static void ldp_panel_disable_lcd(struct omap_dss_device *dssdev)
+{
+ gpio_direction_output(ldp_lcd_enable_gpio, 0);
+ gpio_direction_output(ldp_backlight_gpio, 0);
+}
+
+static struct panel_generic_dpi_data ldp_panel_data = {
+ .name = 2430sdp,
+ .platform_enable= ldp_panel_enable_lcd,
+ .platform_disable = ldp_panel_disable_lcd,
+};
+
+static struct omap_dss_device ldp_lcd_device = {
+ .name = lcd,
+ .driver_name= generic_dpi_panel,
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .phy.dpi.data_lines = 16,
From a working DSS code at:
http://lxr.linux.no/#linux+v2.6.38/drivers/video/omap/lcd_ldp.c
.data_lines should be 18
+ .data = ldp_panel_data,
};
-static struct omap_lcd_config ldp_lcd_config __initdata = {
- .ctrl_name = internal,
+static struct omap_dss_device *ldp_dss_devices[] = {
+ ldp_lcd_device,
};
-static struct omap_board_config_kernel ldp_config[] __initdata = {
- { OMAP_TAG_LCD, ldp_lcd_config },
+static struct omap_dss_board_info ldp_dss_data = {
+ .num_devices= ARRAY_SIZE(ldp_dss_devices),
+ .devices= ldp_dss_devices,
+ .default_device = ldp_lcd_device,
};
+static void __init ldp_display_init(void)
+{
+ int r;
+
+ static struct gpio gpios[] __initdata = {
+ {LCD_PANEL_RESET_GPIO, GPIOF_OUT_INIT_HIGH, LCD RESET},
+ {LCD_PANEL_QVGA_GPIO, GPIOF_OUT_INIT_HIGH, LCD QVGA},
+ };
+
+ r = gpio_request_array(gpios, ARRAY_SIZE(gpios));
+ if (r) {
+ pr_err(Cannot request LCD GPIOs, error %d\n, r);
+ return;
+ }
+
+ omap_display_init(ldp_dss_data);
+}
+
static void __init omap_ldp_init_early
RE: [PATCH v4 4/4] OMAP: DSS: Add picodlp panel driver
-Original Message-
From: Valkeinen, Tomi
Sent: Thursday, May 12, 2011 8:40 PM
To: Janorkar, Mayuresh
Cc: linux-omap@vger.kernel.org; K, Mythri P
Subject: RE: [PATCH v4 4/4] OMAP: DSS: Add picodlp panel driver
On Thu, 2011-05-12 at 20:25 +0530, Janorkar, Mayuresh wrote:
-Original Message-
From: Valkeinen, Tomi
Sent: Thursday, May 12, 2011 7:58 PM
To: Janorkar, Mayuresh
Cc: linux-omap@vger.kernel.org; K, Mythri P
Subject: Re: [PATCH v4 4/4] OMAP: DSS: Add picodlp panel driver
On Tue, 2011-05-10 at 18:55 +0530, Mayuresh Janorkar wrote:
picodlp panel driver is required for driving DLP dpp2600.
It consists of a dss driver and an i2c_client.
i2c_client is required for sending commands to dpp (DLP Pico
Projector).
Based on original design from Mythri P K mythr...@ti.com
The power-up sequence consists of:
Setting PWRGOOD to a logic low state. Once power is stable and thus
the
++
3 files changed, 622 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/displays/panel-picodlp.c
snip
+
+#include plat/display.h
+#include plat/panel-picodlp.h
+
+#include panel-picodlp.h
+
+#define DRIVER_NAMEpicodlp_i2c_driver
+
+#define MAX_TRIAL_VALUE100
I'll repeat my comment from previous review round:
The name of this define is not descriptive and you use this define in
two places which have nothing to do with each other. I think it's
better
just to use the value where it's needed.
I think it looks more readable if we have a MACRO.
But as they are used at only couple of places I would remove these
MACROs.
Well, the problem with this macro is that it's very unclear. What does
max trial value mean? It doesn't define anything sensible, just a number
which doesn't mean anything without the code context.
If it was MAX_TRIAL_TIME_MS, telling the maximum time in milliseconds
that the code would wait, then it would be sensible.
Another problem is that you used the same macro in two different places,
which have nothing to do with each other. The other place requires a
wait of 500ms, if I recall right, and is related to the power up. The
other one is related to waiting for some DMA transfer inside pico to
finish, and this time is in microseconds or possibly few milliseconds if
I understood right.
It's not good to use the same define in such different places,
especially as it only defines a max loop number, so it depends on the
msleeps in the code.
+struct picodlp_data {
+ struct mutex lock;
+static int picodlp_i2c_remove(struct i2c_client *client)
+{
+ struct picodlp_i2c_data *picodlp_i2c_data =
+ i2c_get_clientdata(client);
+
+ kfree(picodlp_i2c_data);
+ i2c_unregister_device(client);
You add the i2c device in the dss probe function, but unregister it in
i2c remove function. That's probably not right. These things should
usually be symmetric, and the unregister should be at the dss remove
function.
Isnt it good to have a remove function removing i2c_client?
Well, when is picodlp_i2c_remove() called? Isn't it called when the i2c
client is being removed, i.e. when somebody has called
i2c_unregister_device()?
The matching API for i2c_add_device is i2c_del_device.
And i2c_unregister_device is a matching API for i2c_new_device.
i2c_del_device (a call present in picodlp_exit) would call i2c_remove and then
i2c_remove has a call to i2c_unregister_device which would unregister the
i2c_device.
So panel_remove should also have a call to i2c_unregister_device.
This would solve the problem.
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/6] OMAP: LDP: Port the display driver to new DSS2
-Original Message-
From: Igor Grinberg [mailto:grinb...@compulab.co.il]
Sent: Thursday, May 12, 2011 2:08 PM
To: Valkeinen, Tomi
Cc: Janorkar, Mayuresh; t...@atomide.com; linux-omap@vger.kernel.org;
Stanley Miao
Subject: Re: [PATCH 4/6] OMAP: LDP: Port the display driver to new DSS2
On 05/12/11 10:16, Igor Grinberg wrote:
On 05/12/11 09:40, Igor Grinberg wrote:
On 05/11/11 09:32, Tomi Valkeinen wrote:
On Wed, 2011-05-11 at 10:28 +0530, Janorkar, Mayuresh wrote:
+static void __init ldp_display_init(void)
+{
+ int r;
+
+ struct gpio gpios[] = {
+ {LCD_PANEL_RESET_GPIO, GPIOF_OUT_INIT_HIGH, LCD
RESET},
+ {LCD_PANEL_QVGA_GPIO, GPIOF_OUT_INIT_HIGH, LCD QVGA},
+ {LCD_PANEL_ENABLE_GPIO, GPIOF_OUT_INIT_LOW, LCD
ENABLE},
+ {LCD_PANEL_BACKLIGHT_GPIO, GPIOF_OUT_INIT_LOW, LCD
BACKLIGHT},
+ };
+
+ r = gpio_request_array(gpios, ARRAY_SIZE(gpios));
+ if (r) {
+ pr_err(Cannot request LCD GPIOs, error %d\n, r);
+ return;
+ }
If I test with this patch, this request is returning error.
Hmm. Well, the GPIOs are the same as in the old driver. However, the
old
driver doesn't even seem to check if it manages to request the GPIOs,
so
it may well be that it was failing also.
Can you check from /sys/class/gpio/ if some of the GPIOs are already
allocated: 207, 199, 55, 56?
The definition of two of those GPIOs look kinda funny to me: (15 +
OMAP_MAX_GPIO_LINES). I don't know what OMAP_MAX_GPIO_LINES means, but
it sure doesn't sound ok to have a GPIO number that is 15 over the
maximum =).
This means that some kind of gpio expander is used.
I bet those are twl gpios (or may be some other discrete chip).
If those are twl gpios then you need to provide the .setup callback
in struct twl4030_gpio_platform_data which will request and setup those
gpios.
No need to wonder ;)
Mayuresh,
try the attached patch (though some changes to Tomi's patch will be
needed)
if it works, then we're good.
there is a typo in the function name:
s/ldp_twl_gpio_setup/ldp_twl_gpios_setup/
Also,
+ };
+
+ r = gpio_request_array(twl_gpios, ARRAY_SIZE(gpios));
This should be ARRAY_SIZE(twl_gpios));
And one more thing:
We need to use regulator for OMAP3430.
Something like this:
+/* VPLL2 for digital video outputs */
+static struct regulator_consumer_supply ldp_vpll2_supplies[] = {
+REGULATOR_SUPPLY(vdds_dsi, omapdss),
+REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi1),
+};
+
+static struct regulator_init_data ldp_vpll2 = {
+.constraints = {
+.name = VDVI,
+.min_uV = 180,
+.max_uV = 180,
+.apply_uV = true,
+.valid_modes_mask = REGULATOR_MODE_NORMAL
+| REGULATOR_MODE_STANDBY,
+.valid_ops_mask = REGULATOR_CHANGE_MODE
+| REGULATOR_CHANGE_STATUS,
+},
+.num_consumer_supplies = ARRAY_SIZE(ldp_vpll2_supplies),
+.consumer_supplies = ldp_vpll2_supplies,
+};
@@ -340,6 +514,7 @@ static struct twl4030_platform_data ldp_twldata = {
.vmmc1 = ldp_vmmc1,
.gpio = ldp_gpio_data,
.keypad = ldp_kp_twl4030_data,
+ .vpll2 = ldp_vpll2,
sorry...
--
Regards,
Igor.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/6] OMAP: LDP: Port the display driver to new DSS2
-Original Message-
From: Valkeinen, Tomi
Sent: Thursday, May 12, 2011 5:18 PM
To: Igor Grinberg
Cc: Janorkar, Mayuresh; t...@atomide.com; linux-omap@vger.kernel.org;
Stanley Miao
Subject: Re: [PATCH 4/6] OMAP: LDP: Port the display driver to new DSS2
On Thu, 2011-05-12 at 14:20 +0300, Igor Grinberg wrote:
Right. Do both fixes make it work?
If it is, then Tomi,
will you add both fixes to the patch set with our SOBs?
or do you want this to be sent properly as a follow up?
Yes, I can add these all to the same patch and handle it through DSS
tree. Although due to the reluctance to make changes to arch/arm/*omap*,
I guess we'll pass these patches in this merge window.
Mayuresh, if you're able to test this and it works, can you send me the
full diff so that I don't make any mistakes combining the code?
Tomi
Please find the patch below.
I have also attached the same.
There are formatting problems with this patch. But this can be used as a
reference.
I have verified bootup with Penguins on LDP board.
From 1f3470d3d792721bf5aa4d060c1cf79f5a587497 Mon Sep 17 00:00:00 2001
From: Mayuresh Janorkar ma...@ti.com
Date: Thu, 12 May 2011 18:53:46 +0530
Subject: [PATCH] LDP Tomi patch
---
arch/arm/mach-omap2/board-ldp.c | 87 ++--
drivers/video/omap2/displays/Kconfig |5 +
drivers/video/omap2/displays/Makefile|1 +
drivers/video/omap2/displays/panel-ldp.c | 223 ++
4 files changed, 305 insertions(+), 11 deletions(-)
mode change 100644 = 100755 arch/arm/mach-omap2/board-ldp.c
create mode 100755 drivers/video/omap2/displays/panel-ldp.c
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
old mode 100644
new mode 100755
index e2ba779..fa6327a
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -43,6 +43,7 @@
#include asm/delay.h
#include plat/usb.h
+#include plat/display.h
#include board-flash.h
#include mux.h
@@ -53,6 +54,11 @@
#define LDP_SMSC911X_GPIO 152
#define DEBUG_BASE 0x0800
#define LDP_ETHR_START DEBUG_BASE
+#define LCD_PANEL_BACKLIGHT_GPIO (15 + OMAP_MAX_GPIO_LINES)
+#define LCD_PANEL_ENABLE_GPIO (7 + OMAP_MAX_GPIO_LINES)
+
+#define LCD_PANEL_RESET_GPIO 55
+#define LCD_PANEL_QVGA_GPIO56
static struct resource ldp_smsc911x_resources[] = {
[0] = {
@@ -275,19 +281,78 @@ static inline void __init ldp_init_smsc911x(void)
gpio_direction_input(eth_gpio);
}
-static struct platform_device ldp_lcd_device = {
- .name = ldp_lcd,
- .id = -1,
+#define SDP3430_LCD_PANEL_BACKLIGHT_GPIO 8
+#define SDP3430_LCD_PANEL_ENABLE_GPIO 5
+
+static unsigned backlight_gpio;
+static unsigned enable_gpio;
+static int lcd_enabled;
+
+static void __init sdp3430_display_init(void)
+{
+ printk(KERN_INFO \n LDP:: sdp3430_display_init );
+return;
+}
+
+static int sdp3430_panel_enable_lcd(struct omap_dss_device *dssdev)
+{
+ int status;
+ return 0;
+}
+
+static void sdp3430_panel_disable_lcd(struct omap_dss_device *dssdev)
+{
+ lcd_enabled = 0;
+
+ gpio_direction_output(enable_gpio, 0);
+ gpio_direction_output(backlight_gpio, 0);
+
+ gpio_direction_output(LCD_PANEL_ENABLE_GPIO, 0);
+ gpio_direction_output(LCD_PANEL_BACKLIGHT_GPIO, 0);
+
+}
+
+static struct omap_dss_device sdp3430_lcd_device = {
+ .name = lcd,
+ .driver_name= ldp_panel,
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .phy.dpi.data_lines = 16,
+ .platform_enable= sdp3430_panel_enable_lcd,
+ .platform_disable = sdp3430_panel_disable_lcd,
};
-static struct omap_lcd_config ldp_lcd_config __initdata = {
- .ctrl_name = internal,
+static struct omap_dss_device *sdp3430_dss_devices[] = {
+ sdp3430_lcd_device,
};
-static struct omap_board_config_kernel ldp_config[] __initdata = {
- { OMAP_TAG_LCD, ldp_lcd_config },
+static struct omap_dss_board_info sdp3430_dss_data = {
+ .num_devices= ARRAY_SIZE(sdp3430_dss_devices),
+ .devices= sdp3430_dss_devices,
+ .default_device = sdp3430_lcd_device,
};
+/* VPLL2 for digital video outputs */
+static struct regulator_consumer_supply sdp3430_vpll2_supplies[] = {
+REGULATOR_SUPPLY(vdds_dsi, omapdss),
+REGULATOR_SUPPLY(vdds_dsi, omap_dsi1),
+};
+
+static struct regulator_init_data sdp3430_vpll2 = {
+.constraints = {
+.name = VDVI,
+.min_uV = 180,
+.max_uV = 180,
+.apply_uV = true,
+.valid_modes_mask = REGULATOR_MODE_NORMAL
+| REGULATOR_MODE_STANDBY,
+.valid_ops_mask = REGULATOR_CHANGE_MODE
RE: [PATCH 4/6] OMAP: LDP: Port the display driver to new DSS2
-Original Message- From: Valkeinen, Tomi Sent: Thursday, May 12, 2011 8:17 PM To: Janorkar, Mayuresh Cc: Igor Grinberg; linux-omap@vger.kernel.org; Stanley Miao Subject: RE: [PATCH 4/6] OMAP: LDP: Port the display driver to new DSS2 On Thu, 2011-05-12 at 20:06 +0530, Janorkar, Mayuresh wrote: -Original Message- From: Valkeinen, Tomi Sent: Thursday, May 12, 2011 5:18 PM To: Igor Grinberg Cc: Janorkar, Mayuresh; t...@atomide.com; linux-omap@vger.kernel.org; Stanley Miao Subject: Re: [PATCH 4/6] OMAP: LDP: Port the display driver to new DSS2 On Thu, 2011-05-12 at 14:20 +0300, Igor Grinberg wrote: Right. Do both fixes make it work? If it is, then Tomi, will you add both fixes to the patch set with our SOBs? or do you want this to be sent properly as a follow up? Yes, I can add these all to the same patch and handle it through DSS tree. Although due to the reluctance to make changes to arch/arm/*omap*, I guess we'll pass these patches in this merge window. Mayuresh, if you're able to test this and it works, can you send me the full diff so that I don't make any mistakes combining the code? Tomi Please find the patch below. I have also attached the same. There are formatting problems with this patch. But this can be used as a reference. I have verified bootup with Penguins on LDP board. Why did you create a new panel for LDP? The generic panel driver should handle it well enough. The attached panel driver is also quite messed up. It does things that belong to the board file, and the timings are a bit high, giving refresh rate of 120MHz. Does LDP have a 120MHz panel? You can use that code as reference and not as a patch. Please take a look at changes in board file. There is no need to create a new panel. It can be added as a part of generic panel. I have taken timings info from: drivers/video/omap/lcd_ldp.c #ifdef CONFIG_FB_OMAP_LCD_VGA #define LCD_XRES480 #define LCD_YRES640 #define LCD_PIXCLOCK_MAX41700 #else #define LCD_XRES240 #define LCD_YRES320 #define LCD_PIXCLOCK_MAX185186 #endif Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 4/4] OMAP: DSS: Add picodlp panel driver
-Original Message-
From: Valkeinen, Tomi
Sent: Thursday, May 12, 2011 7:58 PM
To: Janorkar, Mayuresh
Cc: linux-omap@vger.kernel.org; K, Mythri P
Subject: Re: [PATCH v4 4/4] OMAP: DSS: Add picodlp panel driver
On Tue, 2011-05-10 at 18:55 +0530, Mayuresh Janorkar wrote:
picodlp panel driver is required for driving DLP dpp2600.
It consists of a dss driver and an i2c_client.
i2c_client is required for sending commands to dpp (DLP Pico Projector).
Based on original design from Mythri P K mythr...@ti.com
The power-up sequence consists of:
Setting PWRGOOD to a logic low state. Once power is stable and thus the
++
3 files changed, 622 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/displays/panel-picodlp.c
snip
+
+#include plat/display.h
+#include plat/panel-picodlp.h
+
+#include panel-picodlp.h
+
+#define DRIVER_NAMEpicodlp_i2c_driver
+
+#define MAX_TRIAL_VALUE100
I'll repeat my comment from previous review round:
The name of this define is not descriptive and you use this define in
two places which have nothing to do with each other. I think it's better
just to use the value where it's needed.
I think it looks more readable if we have a MACRO.
But as they are used at only couple of places I would remove these MACROs.
+struct picodlp_data {
+ struct mutex lock;
+static int picodlp_i2c_remove(struct i2c_client *client)
+{
+ struct picodlp_i2c_data *picodlp_i2c_data =
+ i2c_get_clientdata(client);
+
+ kfree(picodlp_i2c_data);
+ i2c_unregister_device(client);
You add the i2c device in the dss probe function, but unregister it in
i2c remove function. That's probably not right. These things should
usually be symmetric, and the unregister should be at the dss remove
function.
Isnt it good to have a remove function removing i2c_client?
I will add this sequence at dss_remove
+ return 0;
+}
+* then only i2c commands can be successfully sent to dpp2600
+*/
+ msleep(510);
+ if (omapdss_dpi_display_enable(dssdev)) {
+ dev_err(dssdev-dev, failed to enable DPI\n);
+ goto err;
+ }
+ dssdev-state = OMAP_DSS_DISPLAY_ACTIVE;
+
+ picodlp_i2c_data =
+ i2c_get_clientdata(picod-picodlp_i2c_client);
+
+ if (!picodlp_i2c_data) {
+ dev_err(dssdev-dev, could not find picodlp i2c data\n);
+ goto err;
If you goto err here, you have to call dpi_display_disable.
I think it's simpler if you get the picodlp_i2c_data somewhere in the
beginning of this function. That way you can bail out if it's NULL
before doing any HW writes.
That looks to be the BEST approach.
+ }
+ r = picodlp_i2c_init(picod-picodlp_i2c_client);
+ if (r)
+ goto err;
And same here.
Yes, I would add dpi_display_disable at err label.
+
+ return r;
+err:
+ if (dssdev-platform_disable)
+ dssdev-platform_disable(dssdev);
+
+ return r;
+}
+
+static void picodlp_panel_power_off(struct omap_dss_device *dssdev)
+{
+ struct picodlp_panel_data *picodlp_pdata = get_panel_data(dssdev);
+
+ omapdss_dpi_display_disable(dssdev);
+
+ picod-picodlp_i2c_client = picodlp_i2c_client;
+
+ picodlp_i2c_data =
+ i2c_get_clientdata(picod-picodlp_i2c_client);
+
+ if (!picodlp_i2c_data) {
+ dev_err(dssdev-dev, could not fine picodlp i2c data);
+ r = -ENODEV;
+ goto err;
+ }
You shouldn't use picodlp_i2c_data here. You don't need it and there's
no guarantee that the i2c probe has been ran yet.
It's enough to check it at power_on.
Looks fine.
+ dev_set_drvdata(dssdev-dev, picod);
+ return r;
+
+err:
+ kfree(picod);
+ return r;
+}
+
+static void picodlp_panel_remove(struct omap_dss_device *dssdev)
+{
+ struct picodlp_data *picod = dev_get_drvdata(dssdev-dev);
+
+ dev_set_drvdata(dssdev-dev, NULL);
+ dev_dbg(dssdev-dev, removing picodlp panel\n);
+ return r;
+}
+
+static void __exit picodlp_exit(void)
+{
+ i2c_del_driver(picodlp_i2c_driver);
+ omap_dss_unregister_driver(picodlp_driver);
+}
These two could be the other way around. I'm not sure it affects the
removal, but it's usually safer to do things in reverse order.
Looks fine.
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 3/4] OMAP4: DSS: Adding a picodlp in OMAP4430 SDP board file
-Original Message-
From: Valkeinen, Tomi
Sent: Thursday, May 12, 2011 6:57 PM
To: Janorkar, Mayuresh
Cc: linux-omap@vger.kernel.org; K, Mythri P
Subject: Re: [PATCH v4 3/4] OMAP4: DSS: Adding a picodlp in OMAP4430 SDP
board file
On Tue, 2011-05-10 at 18:55 +0530, Mayuresh Janorkar wrote:
An on-board projector named picodlp is available for OMAP4430 SDP.
Entry for this picodlp as a panel is being added in dss_devices array
to the board file.
It needs 4 GPIO pins for interfacing with host processor
and these are defined and two of them are configured in board file.
Two GPIOs power_on and display_select are configured here.
picodlp also needs an i2c client over i2c controller-2 at address 0x1b.
Signed-off-by: Mayuresh Janorkar ma...@ti.com
Signed-off-by: Mythri P K mythr...@ti.com
---
Changes since v3:
All GPIOs are requested here and assigned to init value.
Changes since v2:
Changed GPIO names to power_on, emu_done and pwrgood
arch/arm/mach-omap2/board-4430sdp.c | 59
+++
1 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-
omap2/board-4430sdp.c
index 570e83f..7078037
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -38,6 +38,7 @@
#include plat/omap4-keypad.h
#include plat/display.h
#include plat/nokia-dsi-panel.h
+#include plat/panel-picodlp.h
#include mux.h
#include hsmmc.h
@@ -52,6 +53,8 @@
#define HDMI_GPIO_HPD 60 /* Hot plug pin for HDMI */
#define HDMI_GPIO_LS_OE 41 /* Level shifter for HDMI */
#define LCD_BL_GPIO27 /* LCD Backlight GPIO */
+#define OMAP4_DLP_POWER_ON_GPIO40
+#define OMAP4_DLP_DISPLAY_SELECT_GPIO 59
/* PWM2 and TOGGLE3 register offsets */
#define LED_PWM2ON 0x03
#define LED_PWM2OFF0x04
@@ -812,9 +815,64 @@ static struct omap_dss_device sdp4430_hdmi_device =
{
.channel = OMAP_DSS_CHANNEL_DIGIT,
};
+static struct picodlp_panel_data sdp4430_picodlp_pdata = {
+ .picodlp_adapter_id = 2,
+ .emu_done_gpio = 44,
+ .pwrgood_gpio = 45,
+};
It's better to define all the gpio numbers with defines, like you do for
the power_on and display_select gpios. And use the defines in the gpios
array below.
+
+static void sdp4430_picodlp_init(void)
+{
+ int status;
+ struct gpio picodlp_gpios[] = {
+ {OMAP4_DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW,
+ DLP POWER ON},
+ {OMAP4_DLP_DISPLAY_SELECT_GPIO, GPIOF_OUT_INIT_LOW,
+ DLP DISPLAY SELECT},
+ {sdp4430_picodlp_pdata.emu_done_gpio, GPIOF_IN,
+ DLP EMU DONE},
+ {sdp4430_picodlp_pdata.pwrgood_gpio, GPIOF_OUT_INIT_LOW,
+ DLP PWRGOOD},
+ };
+
+ status = gpio_request_array(picodlp_gpios,
ARRAY_SIZE(picodlp_gpios));
+ if (status)
+ pr_err(Cannot request OMAP4_DLP_GPIOs, error %d\n, status);
+
+ gpio_set_value(OMAP4_DLP_DISPLAY_SELECT_GPIO, 0);
+ gpio_set_value(OMAP4_DLP_POWER_ON_GPIO, 0);
+ gpio_set_value(sdp4430_picodlp_pdata.pwrgood_gpio, 1);
gpio_request_array already sets the gpio values as defined in the gpios
array.
Why do you set pwrgood to 1?
Look fine. Even the spec says that this should be kept low in case of power
down.
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/6] OMAP: LDP: Port the display driver to new DSS2
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Valkeinen, Tomi
Sent: Monday, May 09, 2011 1:06 PM
To: t...@atomide.com
Cc: linux-omap@vger.kernel.org; Valkeinen, Tomi; Stanley Miao
Subject: [PATCH 4/6] OMAP: LDP: Port the display driver to new DSS2
Port the old omapfb panel driver to DSS2i. This patch changes the board
file only, the driver is ported in separate patch.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Stanley Miao stanley.m...@windriver.com
---
arch/arm/mach-omap2/board-ldp.c | 73 +-
1 files changed, 63 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-
ldp.c
index e2ba779..2fdfd7f 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -43,6 +43,8 @@
#include asm/delay.h
#include plat/usb.h
+#include plat/display.h
+#include plat/panel-generic-dpi.h
#include board-flash.h
#include mux.h
@@ -275,19 +277,71 @@ static inline void __init ldp_init_smsc911x(void)
gpio_direction_input(eth_gpio);
}
-static struct platform_device ldp_lcd_device = {
- .name = ldp_lcd,
- .id = -1,
+/* LCD */
+
+#define LCD_PANEL_BACKLIGHT_GPIO (15 + OMAP_MAX_GPIO_LINES)
+#define LCD_PANEL_ENABLE_GPIO(7 + OMAP_MAX_GPIO_LINES)
+#define LCD_PANEL_RESET_GPIO 55
+#define LCD_PANEL_QVGA_GPIO 56
+
+static int ldp_panel_enable_lcd(struct omap_dss_device *dssdev)
+{
+ gpio_direction_output(LCD_PANEL_ENABLE_GPIO, 1);
+ gpio_direction_output(LCD_PANEL_BACKLIGHT_GPIO, 1);
+
+ return 0;
+}
+
+static void ldp_panel_disable_lcd(struct omap_dss_device *dssdev)
+{
+ gpio_direction_output(LCD_PANEL_ENABLE_GPIO, 0);
+ gpio_direction_output(LCD_PANEL_BACKLIGHT_GPIO, 0);
+}
+
+static struct panel_generic_dpi_data ldp_panel_data = {
+ .name = 2430sdp,
LDP is a 3430 board.
+ .platform_enable= ldp_panel_enable_lcd,
+ .platform_disable = ldp_panel_disable_lcd,
};
-static struct omap_lcd_config ldp_lcd_config __initdata = {
- .ctrl_name = internal,
+static struct omap_dss_device ldp_lcd_device = {
+ .name = lcd,
+ .driver_name= generic_dpi_panel,
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .phy.dpi.data_lines = 16,
+ .data = ldp_panel_data,
};
-static struct omap_board_config_kernel ldp_config[] __initdata = {
- { OMAP_TAG_LCD, ldp_lcd_config },
+static struct omap_dss_device *ldp_dss_devices[] = {
+ ldp_lcd_device,
+};
+
+static struct omap_dss_board_info ldp_dss_data = {
+ .num_devices= ARRAY_SIZE(ldp_dss_devices),
+ .devices= ldp_dss_devices,
+ .default_device = ldp_lcd_device,
};
+static void __init ldp_display_init(void)
+{
+ int r;
+
+ struct gpio gpios[] = {
+ {LCD_PANEL_RESET_GPIO, GPIOF_OUT_INIT_HIGH, LCD RESET},
+ {LCD_PANEL_QVGA_GPIO, GPIOF_OUT_INIT_HIGH, LCD QVGA},
+ {LCD_PANEL_ENABLE_GPIO, GPIOF_OUT_INIT_LOW, LCD ENABLE},
+ {LCD_PANEL_BACKLIGHT_GPIO, GPIOF_OUT_INIT_LOW, LCD
BACKLIGHT},
+ };
+
+ r = gpio_request_array(gpios, ARRAY_SIZE(gpios));
+ if (r) {
+ pr_err(Cannot request LCD GPIOs, error %d\n, r);
+ return;
+ }
If I test with this patch, this request is returning error.
+
+ omap_display_init(ldp_dss_data);
+}
+
static void __init omap_ldp_init_early(void)
{
omap2_init_common_infrastructure();
@@ -390,7 +444,6 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
static struct platform_device *ldp_devices[] __initdata = {
ldp_smsc911x_device,
- ldp_lcd_device,
ldp_gpio_keys_device,
};
@@ -441,8 +494,6 @@ static struct mtd_partition ldp_nand_partitions[] = {
static void __init omap_ldp_init(void)
{
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
- omap_board_config = ldp_config;
- omap_board_config_size = ARRAY_SIZE(ldp_config);
ldp_init_smsc911x();
omap_i2c_init();
platform_add_devices(ldp_devices, ARRAY_SIZE(ldp_devices));
@@ -459,6 +510,8 @@ static void __init omap_ldp_init(void)
omap2_hsmmc_init(mmc);
/* link regulators to MMC adapters */
ldp_vmmc1_supply.dev = mmc[0].dev;
+
+ ldp_display_init();
}
MACHINE_START(OMAP_LDP, OMAP LDP board)
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at
RE: [PATCH v3 4/4] OMAP: DSS: Add picodlp panel driver
-Original Message-
From: Valkeinen, Tomi
Sent: Tuesday, May 10, 2011 3:03 PM
To: Janorkar, Mayuresh
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH v3 4/4] OMAP: DSS: Add picodlp panel driver
On Mon, 2011-05-09 at 20:48 +0530, Mayuresh Janorkar wrote:
snip
+/* This defines the minit of data which is allowed into single write
block */
+#define MAX_I2C_WRITE_BLOCK_SIZE 32
+#define PICO_MAJOR 1 /* 2 bits */
+#define PICO_MINOR 1 /* 2 bits */
+#define MAX_TRIAL_VALUE50
The name of this define is not descriptive and you use this define in
two places which have nothing to do with each other. I think it's better
just to use the value where it's needed.
Looks fine.
+struct picodlp_data {
+ struct mutex lock;
+ struct i2c_client *picodlp_i2c_client;
+};
+
+static struct i2c_board_info picodlp_i2c_board_info = {
+ I2C_BOARD_INFO(picodlp_i2c_driver, 0x1b),
+};
+ r = i2c_transfer(client-adapter, msg, msg_count);
+ mutex_unlock(picodlp_i2c_data-xfer_lock);
+
+ /*
+* i2c_transfer returns:
+* number of messages sent in case of success
+* a negative error number in case of failure
+* i2c controller might timeout, in such a case sleep for sometime
+* and then retry
+*/
The comment here doesn't look right, there's no retry.
Fine.
+ if (r != msg_count)
+ goto err;
+
+ /* In case of success */
+ for (i = 0; i len; i++)
+ dev_dbg(client-dev,
+ {SEQ_CONTROL, 1}
+ };
+
+ msleep(510);
You are again sleeping in a place where there are no clear actions after
and before the sleep. You should always sleep between two well defined
actions. In this case it's the emu_done going up and the first i2c
transaction, so a better place for this sleep is in the power_on
function, before calling this function. With a comment saying what we
are waiting for.
I would move this to power_on function with an appropriate comment.
+ r = picodlp_i2c_write_array(client, init_cmd_set1,
+ ARRAY_SIZE(init_cmd_set1));
+ if (r)
+ return r;
+ msleep(5);
+ }
You defined the trial value to 50, which means this could timeout after
250ms. If I remember right, it could take 500ms until emu_done changes.
And your error says going down, doesn't the emu_done gpio go up when
it's ready?
Looks fine. I would change the counter.
My bad. I meant to say emu_done is still down.
+
+ r = omapdss_dpi_display_enable(dssdev);
+ if (r) {
+ dev_err(dssdev-dev, failed to enable DPI\n);
+ goto err;
+static void picodlp_panel_power_off(struct omap_dss_device *dssdev)
+{
+ struct picodlp_panel_data *picodlp_pdata = get_panel_data(dssdev);
+
+ omapdss_dpi_display_disable(dssdev);
+
+ gpio_set_value(picodlp_pdata-emu_done_gpio, 0);
emu_done is an input pin, you can't set its value.
Yes.
+ gpio_set_value(picodlp_pdata-pwrgood_gpio, 0);
+
+ if (dssdev-platform_disable)
+ dssdev-platform_disable(dssdev);
+}
+
+static int picodlp_panel_probe(struct omap_dss_device *dssdev)
+{
+ struct picodlp_data *picod;
+ struct picodlp_panel_data *picodlp_pdata = get_panel_data(dssdev);
+ struct i2c_adapter *adapter;
+ struct i2c_client *picodlp_i2c_client;
+ struct picodlp_i2c_data *picodlp_i2c_data;
+ struct gpio picodlp_gpios[] = {
+ {picodlp_pdata-emu_done_gpio, GPIOF_IN, DLP EMU DONE},
+ {picodlp_pdata-pwrgood_gpio, GPIOF_INIT_LOW, DLP PWRGOOD},
+ };
pwrgood_gpio should be GPIOF_OUT_INIT_LOW.
Looks fine
It is better to request and initialize the GPIOs in the board file. The
reason for this is that the PicoDLP device should be off if it's not
used, or if the driver is not even compiled in. So the board file should
make sure that the GPIOs are in such state that the device is off.
The board file has only init. There is no exit.
So if I request gpios in init once, I could not find a place to free them.
Is it a good idea to request gpios in platform_enable and free them in
platform_disable?
+
+ int r = 0, picodlp_adapter_id;
+
+ dssdev-panel.config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_ONOFF |
+ OMAP_DSS_LCD_IHS | OMAP_DSS_LCD_IVS;
+ r = -ENODEV;
+ goto err;
+ }
+
+ picod-picodlp_i2c_client = picodlp_i2c_client;
+
+ picodlp_i2c_data =
+ i2c_get_clientdata(picod-picodlp_i2c_client);
+
+ mutex_init(picodlp_i2c_data-xfer_lock);
I don't think this is right. You have no guarantees that the i2c device
probe would have been called when the execution reaches here. So
picodlp_i2c_data could be NULL.
I would add a check for this.
And anyway, why would you initialize the mutex here, as the mutex
belongs to the i2c side
RE: [PATCH v3 4/4] OMAP: DSS: Add picodlp panel driver
-Original Message- From: Valkeinen, Tomi Sent: Tuesday, May 10, 2011 4:44 PM To: Janorkar, Mayuresh Cc: linux-omap@vger.kernel.org Subject: RE: [PATCH v3 4/4] OMAP: DSS: Add picodlp panel driver On Tue, 2011-05-10 at 15:57 +0530, Janorkar, Mayuresh wrote: It is better to request and initialize the GPIOs in the board file. The reason for this is that the PicoDLP device should be off if it's not used, or if the driver is not even compiled in. So the board file should make sure that the GPIOs are in such state that the device is off. The board file has only init. There is no exit. So if I request gpios in init once, I could not find a place to free them. If the GPIOs are not shared, and they go only to picodlp, there's not really any need to free them. They are not a shared resource, and they can be kept reserved for picodlp all the time. Is it a good idea to request gpios in platform_enable and free them in platform_disable? No, that wouldn't fix the problem. For example, consider a case where the kernel is compiled without picodlp driver. So platform_enable/disable is never called, and the GPIOs are never requested or initialized. This means that depending on the values of the GPIOs, the picodlp could be always on, consuming power. So my suggestion is to request all the GPIOs in the board file, in display init, and initialize the GPIOs to some sane value so that the picodlp is off. Then pass the two GPIOs to the picodlp driver, which can then use the GPIOs, and handle the two other GPIOs in the board file in platform_enable/disable. Looks fine. I would set: OMAP4_DLP_DISPLAY_SELECT_GPIO to 0, OMAP4_DLP_POWER_ON_GPIO to 0, And pwrgood_gpio to 1, as init values of these gpios. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/8] OMAP: DSS2: Miscellaneous patches
-Original Message- From: linux-fbdev-ow...@vger.kernel.org [mailto:linux-fbdev- ow...@vger.kernel.org] On Behalf Of Valkeinen, Tomi Sent: Tuesday, May 10, 2011 9:54 PM To: linux-omap@vger.kernel.org; linux-fb...@vger.kernel.org Cc: Valkeinen, Tomi Subject: [PATCH 0/8] OMAP: DSS2: Miscellaneous patches Here are some smallish fixes and cleanups I made while porting N800's display driver to DSS2. Tomi Tomi Valkeinen (8): OMAP: DSS2: Add missing dummy functions OMAPFB: fix wrong clock aliases and device name OMAP: DSS2: RFBI: add rfbi_bus_lock OMAP: DSS2: RFIB: clock enable/disable changes RFIB a typo? OMAP: DSS2: RFBI: add omap_rfbi_configure OMAP: DSS2: RFIB: cleanup Same here OMAP: DSS2: OMAPFB: remove dead code OMAP: DSS2: OMAPFB: Reduce stack usage arch/arm/plat-omap/include/plat/display.h |4 + drivers/video/omap/dispc.c|4 +- drivers/video/omap/omapfb_main.c |2 +- drivers/video/omap/rfbi.c |2 +- If the series touches drivers/video/omap then the title should be DSS and DSS2 using only DSS2 is misleading. drivers/video/omap2/dss/dss.h | 28 - drivers/video/omap2/dss/rfbi.c| 174 +--- - drivers/video/omap2/omapfb/omapfb-main.c | 78 + 7 files changed, 86 insertions(+), 206 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-fbdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 8/8] OMAP: DSS2: OMAPFB: Reduce stack usage
-Original Message-
From: linux-fbdev-ow...@vger.kernel.org [mailto:linux-fbdev-
ow...@vger.kernel.org] On Behalf Of Valkeinen, Tomi
Sent: Tuesday, May 10, 2011 9:54 PM
To: linux-omap@vger.kernel.org; linux-fb...@vger.kernel.org
Cc: Valkeinen, Tomi
Subject: [PATCH 8/8] OMAP: DSS2: OMAPFB: Reduce stack usage
omapfb_mode_to_timings() had struct fb_info, struct fb_var and struct
fb_ops allocated from stack. This caused the stack usage grow quite
high.
Use kzalloc to allocate the structs instead.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/omapfb/omapfb-main.c | 49 +
-
1 files changed, 28 insertions(+), 21 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
b/drivers/video/omap2/omapfb/omapfb-main.c
index 30c958b..ae3e2be 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -1996,9 +1996,9 @@ static int omapfb_create_framebuffers(struct
omapfb2_device *fbdev)
static int omapfb_mode_to_timings(const char *mode_str,
struct omap_video_timings *timings, u8 *bpp)
{
- struct fb_info fbi;
- struct fb_var_screeninfo var;
- struct fb_ops fbops;
+ struct fb_info *fbi;
+ struct fb_var_screeninfo *var;
+ struct fb_ops *fbops;
int r;
#ifdef CONFIG_OMAP2_DSS_VENC
@@ -2016,25 +2016,25 @@ static int omapfb_mode_to_timings(const char
*mode_str,
/* this is quite a hack, but I wanted to use the modedb and for
* that we need fb_info and var, so we create dummy ones */
- memset(fbi, 0, sizeof(fbi));
- memset(var, 0, sizeof(var));
- memset(fbops, 0, sizeof(fbops));
- fbi.fbops = fbops;
+ fbi = kzalloc(sizeof(*fbi), GFP_KERNEL);
If memory allocation fails, kzalloc would return NULL,
It is good to check for this condition
+ var = kzalloc(sizeof(*var), GFP_KERNEL);
+ fbops = kzalloc(sizeof(*fbops), GFP_KERNEL);
Same at these two places
+ fbi-fbops = fbops;
- r = fb_find_mode(var, fbi, mode_str, NULL, 0, NULL, 24);
+ r = fb_find_mode(var, fbi, mode_str, NULL, 0, NULL, 24);
if (r != 0) {
- timings-pixel_clock = PICOS2KHZ(var.pixclock);
- timings-hbp = var.left_margin;
- timings-hfp = var.right_margin;
- timings-vbp = var.upper_margin;
- timings-vfp = var.lower_margin;
- timings-hsw = var.hsync_len;
- timings-vsw = var.vsync_len;
- timings-x_res = var.xres;
- timings-y_res = var.yres;
-
- switch (var.bits_per_pixel) {
+ timings-pixel_clock = PICOS2KHZ(var-pixclock);
+ timings-hbp = var-left_margin;
+ timings-hfp = var-right_margin;
+ timings-vbp = var-upper_margin;
+ timings-vfp = var-lower_margin;
+ timings-hsw = var-hsync_len;
+ timings-vsw = var-vsync_len;
+ timings-x_res = var-xres;
+ timings-y_res = var-yres;
+
+ switch (var-bits_per_pixel) {
case 16:
*bpp = 16;
break;
@@ -2045,10 +2045,17 @@ static int omapfb_mode_to_timings(const char
*mode_str,
break;
}
- return 0;
+ r = 0;
} else {
- return -EINVAL;
+ *bpp = 0;
+ r = -EINVAL;
}
+
+ kfree(fbi);
+ kfree(var);
+ kfree(fbops);
+
+ return r;
}
static int omapfb_set_def_mode(struct omapfb2_device *fbdev,
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-fbdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 3/7] OMAP: DSS: Adding a picodlp panel driver
-Original Message-
From: Valkeinen, Tomi
Sent: Tuesday, May 03, 2011 11:56 PM
To: Janorkar, Mayuresh
Cc: linux-omap@vger.kernel.org; K, Mythri P
Subject: Re: [PATCH v2 3/7] OMAP: DSS: Adding a picodlp panel driver
On Mon, 2011-05-02 at 20:22 +0530, Mayuresh Janorkar wrote:
From: Mythri P K mythr...@ti.com
A projector panel named picodlp is supported by OMAP.
panel driver is required to be added with the name picodlp_panel.
It is a WVGA panel with resolution 864 X 480 and panel timing data
is defined in the panel driver.
picodlp makes use of parallel (DPI) interface multiplexed with secondary
lcd
in case of OMAP4.
Signed-off-by: Mythri P K mythr...@ti.com
Signed-off-by: Mayuresh Janorkar ma...@ti.com
---
Changes since v1:
1. Removed msleep
drivers/video/omap2/displays/panel-picodlp.c | 226
++
1 files changed, 226 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/displays/panel-picodlp.c
snip
+static void picodlp_panel_disable(struct omap_dss_device *dssdev)
+{
+ struct picodlp_data *picod = dev_get_drvdata(dssdev-dev);
+
+ mutex_lock(picod-lock);
+ /* Turn off DLP Power */
+ if (dssdev-state == OMAP_DSS_DISPLAY_ACTIVE)
+ picodlp_panel_power_off(dssdev);
+
+ dev_dbg(dssdev-dev, disabling picodlp panel\n);
+ dssdev-state = OMAP_DSS_DISPLAY_DISABLED;
+
+ mutex_unlock(picod-lock);
Many of the debug prints in this file have an extra space in the
beginning of the string, like above.
You should try to keep the code inside lock and unlock as minimal as
possible. Here the dev_dbg() could as well be outside the lock (granted,
dev_dbg() is a null op if DEBUG is not defined, but still).
Additionally, usually it's good to print the debug print before doing
the action, so here (and similar cases elsewhere in this file) it would
make sense to move the dev_dbg() before the lock.
I will take care of this
+}
+
+static int picodlp_panel_suspend(struct omap_dss_device *dssdev)
+{
+ struct picodlp_data *picod = dev_get_drvdata(dssdev-dev);
+
+ mutex_lock(picod-lock);
+ /* Turn off DLP Power */
+ if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE) {
+ dev_dbg(dssdev-dev, unable to suspend picodlp panel,\
+panel is not ACTIVE\n);
This is not a debug print, but an error. Similar problem in the function
below.
Fine
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 4/7] OMAP: DSS: Add i2c client driver for picodlp
-Original Message- From: Valkeinen, Tomi Sent: Wednesday, May 04, 2011 12:15 AM To: Janorkar, Mayuresh Cc: linux-omap@vger.kernel.org; K, Mythri P Subject: Re: [PATCH v2 4/7] OMAP: DSS: Add i2c client driver for picodlp On Mon, 2011-05-02 at 20:22 +0530, Mayuresh Janorkar wrote: The configurations and data transfer with picodlp panel happens through i2c. An i2c client with name picodlp_i2c_driver is registered inside panel. dpp2600 requires 4 gpio lines for interfacing it with any processor, phy_reset, ready_reset, park, display_select Hmm, so what is dpp2600? It's mentioned here for the first time, the documentation doesn't mention it. Patch 0 does mention about dpp2600. It means DLP Pico Processor and I have also provided link to wiki page which talks more about dpp2600. Earlier version of patch also had functions dpp2600_configure_flash. If it means the picodlp, just use the same name all the time. If not, you could tell what it is first. DPP means DLP pico processor. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 4/7] OMAP: DSS: Add i2c client driver for picodlp
-Original Message- From: Valkeinen, Tomi Sent: Wednesday, May 04, 2011 4:36 PM To: Janorkar, Mayuresh Cc: linux-omap@vger.kernel.org; K, Mythri P Subject: RE: [PATCH v2 4/7] OMAP: DSS: Add i2c client driver for picodlp On Wed, 2011-05-04 at 15:31 +0530, Janorkar, Mayuresh wrote: -Original Message- From: Valkeinen, Tomi Sent: Wednesday, May 04, 2011 12:15 AM To: Janorkar, Mayuresh Cc: linux-omap@vger.kernel.org; K, Mythri P Subject: Re: [PATCH v2 4/7] OMAP: DSS: Add i2c client driver for picodlp On Mon, 2011-05-02 at 20:22 +0530, Mayuresh Janorkar wrote: The configurations and data transfer with picodlp panel happens through i2c. An i2c client with name picodlp_i2c_driver is registered inside panel. dpp2600 requires 4 gpio lines for interfacing it with any processor, phy_reset, ready_reset, park, display_select Hmm, so what is dpp2600? It's mentioned here for the first time, the documentation doesn't mention it. Patch 0 does mention about dpp2600. It means DLP Pico Processor and I have also provided link to wiki page which talks more about dpp2600. Earlier version of patch also had functions dpp2600_configure_flash. Remember that patch 0 is just an intro for the patch set. It's not included in the kernel tree. So the basic rule is that patch 0 should not contain any important info that is not available from the patches itself. Where does the DPP2600 name come from? The documentation doesn't mention it, it's only mentioned in the wiki page written by you. I didn't find anything with a quick googling either. You can check it here: https://focus.ti.com/myti/docs/extranet.tsp?sectionId=403 You might have to create an extranet account to access it. If it means the picodlp, just use the same name all the time. If not, you could tell what it is first. DPP means DLP pico processor. So DPP is the processor part inside the projector? I'm not sure if that knowledge is relevant here. From the kernel driver's point of view there's just the projector, where the GPIOs, i2c and video lines go. Does it matter that there's a DPP2600 processor inside? My bad it means DLP Pico Projector. There is no processor. Also, in the patch comment above you write picodlp panel. The PicoDLP is not panel, so you shouldn't speak of picodlp panel. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 5/7] OMAP: DSS: Adding initialization routine to picodlp panel
-Original Message-
From: Valkeinen, Tomi
Sent: Wednesday, May 04, 2011 12:28 AM
To: Janorkar, Mayuresh
Cc: linux-omap@vger.kernel.org; K, Mythri P
Subject: Re: [PATCH v2 5/7] OMAP: DSS: Adding initialization routine to
picodlp panel
On Mon, 2011-05-02 at 20:22 +0530, Mayuresh Janorkar wrote:
From: Mythri P K mythr...@ti.com
picodlp_i2c_client needs to send commands over i2c as a part of
initialiazation.
system controller dlp pico processor dpp2600 is used.
It configures the splash screen of picodlp using a sequence of commands.
A programmer's guide is available at:
http://focus.ti.com/lit/ug/dlpu002a/dlpu002a.pdf
API is defined for sending command over i2c as an i2c_write operation.
Signed-off-by: Mythri P K mythr...@ti.com
Signed-off-by: Mayuresh Janorkar ma...@ti.com
---
Changes since v1:
1. Removed initial splash screen
2. i2c_commands regrouped
3. Removed long msleep
4. Added try-after-sleep in i2c_write
drivers/video/omap2/displays/panel-picodlp.c | 212
++
1 files changed, 212 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-picodlp.c
b/drivers/video/omap2/displays/panel-picodlp.c
index fdbfdcf..493a411 100644
--- a/drivers/video/omap2/displays/panel-picodlp.c
+++ b/drivers/video/omap2/displays/panel-picodlp.c
@@ -32,7 +32,15 @@
#include plat/display.h
#include plat/panel-picodlp.h
+#include panel-picodlp.h
+
#define DRIVER_NAMEpicodlp_i2c_driver
+
+/* This defines the minit of data which is allowed into single write
block */
+#define MAX_I2C_WRITE_BLOCK_SIZE 32
+#define PICO_MAJOR 1 /* 2 bits */
+#define PICO_MINOR 1 /* 2 bits */
+
struct picodlp_data {
struct mutex lock;
struct i2c_client *picodlp_i2c_client;
@@ -50,6 +58,11 @@ struct i2c_device_id picodlp_i2c_id[] = {
{ picodlp_i2c_driver, 0 },
};
+struct picodlp_i2c_command {
+ u8 reg;
+ u32 value;
+};
+
static struct omap_video_timings pico_ls_timings = {
.x_res = 864,
.y_res = 480,
@@ -70,6 +83,197 @@ static inline struct picodlp_panel_data
return (struct picodlp_panel_data *) dssdev-data;
}
+static int picodlp_i2c_write_block(struct i2c_client *client,
+ u8 *data, int len)
+{
+ struct i2c_msg msg;
+ int i, r, msg_count = 1, trial = 4;
+
+ struct picodlp_i2c_data *picodlp_i2c_data =
i2c_get_clientdata(client);
+
+ if (len 1 || len MAX_I2C_WRITE_BLOCK_SIZE) {
+ dev_err(client-dev,
+ too long syn_write_block len %d\n, len);
+ return -EIO;
+ }
+retry:
+ mutex_lock(picodlp_i2c_data-xfer_lock);
+
+ msg.addr = client-addr;
+ msg.flags = 0;
+ msg.len = len;
+ msg.buf = data;
+ r = i2c_transfer(client-adapter, msg, msg_count);
+ mutex_unlock(picodlp_i2c_data-xfer_lock);
+
+ /*
+* i2c_transfer returns:
+* number of messages sent in case of success
+* a negative error number in case of failure
+* i2c controller might timeout, in such a case sleep for sometime
+* and then retry
+*/
+ if (r != msg_count) {
+ msleep(2);
+ if (trial--)
+ goto retry;
This is not good. Hacks like these should only be used as a last option.
I'm still saying that you should find the document mentioned in the
documents you have. I refuse to believe that we (TI) do not know what
our hardware does, especially in a basic issue like this.
I'm 99% sure there is documentation telling the required power-up
sequence. And if that 1% happens, we should find the HW designers and
yell at them until they make the documents.
Yes it is mentioned.
You can check it here:
https://focus.ti.com/myti/docs/extranet.tsp?sectionId=403
A delay is required after i2c client creation and it is 1 second.
So this part of code would be removed.
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/7] OMAP: DSS: Adding a picodlp panel driver
-Original Message-
From: Valkeinen, Tomi
Sent: Tuesday, April 19, 2011 4:40 PM
To: Janorkar, Mayuresh
Cc: linux-omap@vger.kernel.org; K, Mythri P
Subject: Re: [PATCH 3/7] OMAP: DSS: Adding a picodlp panel driver
On Mon, 2011-04-18 at 11:45 +0530, Mayuresh Janorkar wrote:
From: Mythri P K mythr...@ti.com
A projector panel named picodlp is supported by OMAP.
panel driver is required to be added with the name picodlp_panel.
It is a WVGA panel with resolution 864 X 480 and panel timing data
is defined in the panel driver.
picodlp makes use of parallel (DPI) interface multiplexed with secondary
lcd
in case of OMAP4.
Signed-off-by: Mythri P K mythr...@ti.com
Signed-off-by: Mayuresh Janorkar ma...@ti.com
---
drivers/video/omap2/displays/panel-picodlp.c | 228
++
1 files changed, 228 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/displays/panel-picodlp.c
diff --git a/drivers/video/omap2/displays/panel-picodlp.c
b/drivers/video/omap2/displays/panel-picodlp.c
new file mode 100644
index 000..4f12903
--- /dev/null
+++ b/drivers/video/omap2/displays/panel-picodlp.c
@@ -0,0 +1,228 @@
+/*
+ * picodlp panel driver
+ *
+ * Copyright (C) 2009-2011 Texas Instruments
+ * Author: Mythri P K mythr...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
it
+ * under the terms of the GNU General Public License version 2 as
published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/input.h
+#include linux/platform_device.h
+#include linux/interrupt.h
+#include linux/firmware.h
+#include linux/slab.h
+#include linux/mutex.h
+#include linux/delay.h
+
+#include plat/display.h
+#include plat/panel-picodlp.h
+
+struct picodlp_data {
+ struct mutex lock;
+};
+
+static struct omap_video_timings pico_ls_timings = {
+ .x_res = 864,
+ .y_res = 480,
+ .hsw= 7,
+ .hfp= 11,
+ .hbp= 7,
+
+ .pixel_clock= 19200,
+
+ .vsw= 2,
+ .vfp= 3,
+ .vbp= 14,
+};
+
+static int picodlp_panel_power_on(struct omap_dss_device *dssdev)
+{
+ int r;
+
+ if (dssdev-platform_enable) {
+ r = dssdev-platform_enable(dssdev);
+ if (r)
+ return r;
+ }
+
+ r = omapdss_dpi_display_enable(dssdev);
+ if (r) {
+ dev_err(dssdev-dev, failed to enable DPI\n);
+ goto err;
+ }
+ /* after enabling, wait for some initialize sync interrupts */
+ msleep(675);
+ dssdev-state = OMAP_DSS_DISPLAY_ACTIVE;
+
+ return 0;
+
+err:
+ if (dssdev-platform_disable)
+ dssdev-platform_disable(dssdev);
+
+ return r;
+}
Why is the msleep needed there? It's a huge sleep, and can't find
information about it from the documents you gave links to. I think I've
asked this three times already.
It is practically observed that without this delay the pico panel does not get
initialized.
Also, it's rather strange to sleep at the end of the function. Normally
you would sleep between two actions.
Some of the panels in drivers/video/omap2/displays sleep after
dpi_display_enable.
I agree here the sleep is huge. But I could not minimize it below this value.
I can handle it in some other ways:
See if the i2c_pakcet is sent. If not sent wait for some time ~50ms and then
resend.
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/7] OMAP: DSS: Add i2c client driver for picodlp
-Original Message- From: Valkeinen, Tomi Sent: Tuesday, April 19, 2011 5:12 PM To: Janorkar, Mayuresh Cc: linux-omap@vger.kernel.org; K, Mythri P Subject: Re: [PATCH 4/7] OMAP: DSS: Add i2c client driver for picodlp On Mon, 2011-04-18 at 11:45 +0530, Mayuresh Janorkar wrote: The configurations and data transfer with picodlp panel happens through i2c. An i2c client with name picodlp_i2c_driver is registered inside panel. Signed-off-by: Mythri P K mythr...@ti.com Signed-off-by: Mayuresh Janorkar ma...@ti.com Signed-off-by: Mythri P K mythr...@ti.com --- drivers/video/omap2/displays/panel-picodlp.c | 130 +- 1 files changed, 126 insertions(+), 4 deletions(-) snip @@ -65,8 +131,10 @@ static int picodlp_panel_power_on(struct omap_dss_device *dssdev) msleep(675); dssdev-state = OMAP_DSS_DISPLAY_ACTIVE; - return 0; + picodlp_i2c_data = + i2c_get_clientdata(picod-picodlp_i2c_client); This variable is not used at all. Not in this patch but it is used in next patch. I would add it as a part of next patch where it is used. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 5/7] OMAP: DSS: Adding initialization routine to picodlp panel
-Original Message-
From: Valkeinen, Tomi
Sent: Tuesday, April 19, 2011 5:23 PM
To: Janorkar, Mayuresh
Cc: linux-omap@vger.kernel.org; K, Mythri P
Subject: Re: [PATCH 5/7] OMAP: DSS: Adding initialization routine to
picodlp panel
On Mon, 2011-04-18 at 11:45 +0530, Mayuresh Janorkar wrote:
From: Mythri P K mythr...@ti.com
picodlp_i2c_client needs to send commands over i2c as a part of
initialiazation.
system controller dlp pico processor dpp2600 is used.
It configures the splash screen of picodlp using a sequence of commands.
A programmer's guide is available at:
http://focus.ti.com/lit/ug/dlpu002a/dlpu002a.pdf
API is defined for sending command over i2c as an i2c_write operation.
Signed-off-by: Mythri P K mythr...@ti.com
Signed-off-by: Mayuresh Janorkar ma...@ti.com
---
drivers/video/omap2/displays/panel-picodlp.c | 317
++
1 files changed, 317 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-picodlp.c
b/drivers/video/omap2/displays/panel-picodlp.c
index e361674..785e406 100644
--- a/drivers/video/omap2/displays/panel-picodlp.c
+++ b/drivers/video/omap2/displays/panel-picodlp.c
@@ -32,7 +32,15 @@
#include plat/display.h
#include plat/panel-picodlp.h
+#include panel-picodlp.h
+
#define DRIVER_NAMEpicodlp_i2c_driver
+
+/* This defines the minit of data which is allowed into single write
block */
+#define MAX_I2C_WRITE_BLOCK_SIZE 32
+#define PICO_MAJOR 1 /* 2 bits */
+#define PICO_MINOR 1 /* 2 bits */
+
struct picodlp_data {
struct mutex lock;
struct i2c_client *picodlp_i2c_client;
@@ -50,6 +58,11 @@ struct i2c_device_id picodlp_i2c_id[] = {
{ picodlp_i2c_driver, 0 },
};
+struct picodlp_i2c_command {
+ u8 reg;
+ u32 value;
+};
+
static struct omap_video_timings pico_ls_timings = {
.x_res = 864,
.y_res = 480,
@@ -70,6 +83,305 @@ static inline struct picodlp_panel_data
return (struct picodlp_panel_data *) dssdev-data;
}
+static int picodlp_i2c_write_block(struct i2c_client *client,
+ u8 *data, int len)
+{
+ struct i2c_msg msg;
+ int i, r;
+
+ struct picodlp_i2c_data *picodlp_i2c_data =
i2c_get_clientdata(client);
+
+ if (len 1 || len MAX_I2C_WRITE_BLOCK_SIZE) {
+ dev_err(client-dev,
+ too long syn_write_block len %d\n, len);
+ return -EIO;
+ }
+
+ mutex_lock(picodlp_i2c_data-xfer_lock);
+
+ msg.addr = client-addr;
+ msg.flags = 0;
+ msg.len = len;
+ msg.buf = data;
+
+ r = i2c_transfer(client-adapter, msg, 1);
+ mutex_unlock(picodlp_i2c_data-xfer_lock);
+
+ if (r == 1) {
+ for (i = 0; i len; i++)
+ dev_dbg(client-dev,
+ addr %x bw 0x%02x[%d]: 0x%02x\n,
+ client-addr, data[0] + i, i, data[i]);
+ return 0;
+ }
+
+ dev_err(client-dev, picodlp_i2c_write error\n);
+ return r;
This is, at least to my eyes, a bit uncommon way to do this. Usually the
error path is handled inside an if(), and the ok path is at the end of
the function.
Would change this as per the most used formats.
+}
+ int r;
+ static const struct picodlp_i2c_command init_cmd_set1[] = {
+ {SOFT_RESET, 1}, {DMD_PARK_TRIGGER, 1},
+ {MISC_REG, (PICO_MAJOR 2 | PICO_MINOR)}, {SEQ_CONTROL, 0},
+ {SEQ_VECTOR, 0x100}, {DMD_BLOCK_COUNT, 7},
+ {DMD_VCC_CONTROL, 0x109}, {DMD_PARK_PULSE_COUNT, 0xA},
+ {DMD_PARK_PULSE_WIDTH, 0xB}, {DMD_PARK_DELAY, 0x2ED},
+ {DMD_SHADOW_ENABLE, 0}, {FLASH_OPCODE, 0xB},
+ {FLASH_DUMMY_BYTES, 1}, {FLASH_ADDR_BYTES, 3},
+ };
It would make these command lists clearer if there was only one command
per line.
Fine
+
+ if (r)
+ return r;
+
+ /* display logo splash image */
+ r = picodlp_dpp2600_config_splash(client);
+ if (r)
+ return r;
So this will show some hardcoded splash screen? How much of the code
could be removed if the splash screen feature is removed? I don't see
much point in such a feature, and it looks to me that at least two of
the functions above are just for the splash screen. It's just extra code
for a feature nobody wants.
Yes, this would show a hardcoded splash screen.
+ r = picodlp_i2c_write_array(client, init_cmd_set3,
+ ARRAY_SIZE(init_cmd_set3));
+ if (r)
+ return r;
+
+ r = picodlp_dpp2600_config_rgb(client);
+ if (r)
+ return r;
+
+ return 0;
+}
+
static int picodlp_i2c_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
@@ -134,6 +446,11 @@ static int picodlp_panel_power_on(struct
RE: [PATCH 6/7] OMAP4: DSS: Adding a picodlp in OMAP4430 SDP board file
-Original Message-
From: Valkeinen, Tomi
Sent: Tuesday, April 19, 2011 5:24 PM
To: Janorkar, Mayuresh
Cc: linux-omap@vger.kernel.org; K, Mythri P
Subject: Re: [PATCH 6/7] OMAP4: DSS: Adding a picodlp in OMAP4430 SDP
board file
On Mon, 2011-04-18 at 11:45 +0530, Mayuresh Janorkar wrote:
An on-board panel named picodlp projector is available for OMAP4430 SDP.
Entry for this panel is being added in dss_devices in the board file.
It also needs 4 GPIO pins and are defined and used in board file.
picodlp also needs an i2c client over i2c controller-2 at address 0x1b.
Signed-off-by: Mayuresh Janorkar ma...@ti.com
Signed-off-by: Mythri P K mythr...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 40
+++
1 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-
omap2/board-4430sdp.c
index 1503f0b..6827612
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -38,6 +38,7 @@
#include plat/omap4-keypad.h
#include plat/display.h
#include plat/nokia-dsi-panel.h
+#include plat/panel-picodlp.h
#include mux.h
#include hsmmc.h
@@ -585,6 +586,7 @@ static struct i2c_board_info __initdata
sdp4430_i2c_boardinfo[] = {
.platform_data = sdp4430_twldata,
},
};
+
Unneeded change.
Fine.
static struct i2c_board_info __initdata sdp4430_i2c_3_boardinfo[] = {
{
I2C_BOARD_INFO(tmp105, 0x48),
@@ -598,6 +600,7 @@ static struct i2c_board_info __initdata
sdp4430_i2c_4_boardinfo[] = {
I2C_BOARD_INFO(hmc5843, 0x1e),
},
};
+
Unneeded change.
Fine
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP: Added recalculation of clock rate in 'clk_set_rate'
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Gulati, Shweta
Sent: Wednesday, April 20, 2011 2:55 PM
To: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org; Gulati, Shweta; Nayak, Rajendra;
Paul Wamsley
Subject: [PATCH] OMAP: Added recalculation of clock rate in 'clk_set_rate'
From: Gulati, Shweta shweta.gul...@ti.com
Core Clk Tree shows incorrect Clk rates at OPP50, as
in commit e07f469d284ca3d1f5dcf5438c22982be98bc071
calling of 'recalc' in API clk_set_rate is unintentionally
removed, because of which clock's tree rates get goofed
up when DVFS happens. This Patch adds recalc API back.
I see that the patch is not adding API back.
It is adding a call to the API.
Tested on OMAP3630 SDP Board.
Signed-off-by: Shweta Gulati shweta.gul...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Paul Wamsley p...@pwsan.com
---
arch/arm/plat-omap/clock.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index c9122dd..5a0d06b 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -130,8 +130,11 @@ int clk_set_rate(struct clk *clk, unsigned long rate)
spin_lock_irqsave(clockfw_lock, flags);
ret = arch_clock-clk_set_rate(clk, rate);
- if (ret == 0)
+ if (ret == 0) {
checking if (!ret) is an intelligent way.
But it is an individual's choice.
+ if (clk-recalc)
+ clk-rate = clk-recalc(clk);
propagate_rate(clk);
+ }
spin_unlock_irqrestore(clockfw_lock, flags);
return ret;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 00/10] OMAP4 : DSS2 : HDMI support on OMAP4
Raue, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Valkeinen, Tomi Sent: Thursday, March 17, 2011 4:41 PM To: Stephan Raue Cc: K, Mythri P; linux-omap@vger.kernel.org Subject: Re: [PATCH v5 00/10] OMAP4 : DSS2 : HDMI support on OMAP4 Hi, On Wed, 2011-03-16 at 18:49 -0500, Stephan Raue wrote: i tried this test tree with omap2plus_defconfig. it seems the kernel crashes and poweroff the board on loading this hdmi stuff, but dont print any crashlog. is there a way any backtraces will be printed? output from serial console: http://paste.pocoo.org/show/354850/ kernel config (omap2plus_defconfig, added squashfs support, added support to include initramfs in kernel, build omapfb stuff statically into the kernel): http://paste.pocoo.org/show/354853/ Is it possible for you to enable low-level debugging and pass omapfb.debug=1 omapdss.debug=1 in your bootargs? This would show the Framebuffer and DSSDBG prints. We would get an idea if kernel is getting stuck in DSS/OMAPFB. Let me know if you any help in enabling debug prints. Also one more suggestion/ question, are you seeing a hang if DSS is not enabled in kernel? -Thanks, Mayuresh Have the HDMI on your setup worked in any (prebuilt) image? What I'm asking is if you are sure the HDMI HW works on your board? Powering off quietly sounds strange. Is your power supply sufficient? Well, I don't think that would explain the first crash you posted... Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: State of LDP3430 platform
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Thursday, February 24, 2011 4:20 AM To: Russell King - ARM Linux Cc: linux-omap@vger.kernel.org; Paul Walmsley; Shilimkar, Santosh; Woodruff, Richard Subject: Re: State of LDP3430 platform * Russell King - ARM Linux li...@arm.linux.org.uk [110212 08:09]: On Sat, Feb 12, 2011 at 04:02:16PM +, Russell King - ARM Linux wrote: Another LDP3430 report... The LDP3430 seems to be getting there, but: 1. LCD screen seems wrong. The X display looks rather large, and flickery - looks like the LCD timing parameters are wrong. Some text disappears off the RHS. fbset reports: mode 240x320-510 # D: 48.001 MHz, H: 168.424 kHz, V: 510.375 Hz geometry 240 320 240 320 16 timings 20833 3 39 2 7 3 1 accel false rgba 5/11,6/5,5/0,0/0 kernel config: CONFIG_FB_OMAP=y CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE=2 with the supplied kernel: mode 640x480-64 # D: 21.601 MHz, H: 31.396 kHz, V: 63.813 Hz geometry 640 480 640 640 16 timings 46295 40 4 8 2 4 2 accel false rgba 5/11,6/5,5/0,0/0 so the LCD timings in the kernel appear to be wrong for the panel on the LDP. What is 'CONFIG_FB_OMAP_LCD_VGA'? There's *no* help I would send a patch for this to Tomi. for this configuration option so god only knows what it's right setting should be. Please give it some help text to explain what it is and what it does. I think it is because x_res and y_res of panel are set to QVGA (320 X 240) and the content sent is VGA (640 X 480) With CONFIG_FB_OMAP_LCD_VGA=y the resolution taken is VGA (640 X 480) You can check drivers/video/omap/lcd_ldp.c http://lxr.linux.no/#linux+v2.6.37/drivers/video/omap/lcd_ldp.c#L185 LCD works better with FB_OMAP_LCD_VGA set, but why is this necessary? This would set the resolution to VGA (640 X 480) 3430 SDP has a switch to toggle between VGA (640 X 480) and QQVGA (320 X 240). So this switch must also be toggled along with the when we are booting a kernel with CONFIG_FB_OMAP_LCD_VGA=y In LDP it is controlled by a GPIO: #define LCD_PANEL_QVGA_GPIO 56 Depending on value of this the resolution is selected. If LCD_PANEL_QVGA_GPIO is 1 then resolution is 320 X 240 Also, could you please share other CONFIG options which you are enabling over omap2plus_defconfig? (Otherwise please share .config) -Thanks, Mayuresh 2. Keyboard - numeric keys produce wrong ascii for their labelled function. This is from /dev/tty1 with X running: 1 gives nothing 2 gives 4 3 gives 7 4 gives 2 5 gives 5 6 gives 8 7 gives 3 8 gives nothing 9 gives 9 * gives nothing 0 gives E # gives nothing off-hook (green phone) gives 0 on-hook (red phone) gives 1b5b31397e Killing X and then running evtest on /dev/input/event1 doesn't return any events, neither does reading /dev/tty1 for the twl4030 keypad - the numeric keys are completely dead. /proc/interrupts shows no new interrupt counts when pressing the key for 'twl4030_keypad'. Unbinding/rebinding the twl4030 driver doesn't sort it out, neither does restarting X. 3. Touchscreen is dead, presumably because no devices are bound to ads7846 SPI driver. ls -al /sys/bus/spi/devices/ total 0 drwxr-xr-x 2 root root 0 Jan 1 01:02 . drwxr-xr-x 4 root root 0 Jan 1 01:02 .. lrwxrwxrwx 1 root root 0 Jan 1 01:02 spi1.0 - ../../../devices/platform/omap2_mcspi.1/spi1.0 is the only SPI device which appears, but is unbound. I'm sure this used to work at some point. Anybody from TI looking into these? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RESEND][PATCH v2] OMAP: DSS: Adding two APIs for panel-taal: check_timings and set_timings
Tomi, -Original Message- From: Valkeinen, Tomi Sent: Wednesday, February 16, 2011 7:28 PM To: Janorkar, Mayuresh Cc: linux-omap@vger.kernel.org Subject: Re: [RESEND][PATCH v2] OMAP: DSS: Adding two APIs for panel-taal: check_timings and set_timings Hi, On Wed, 2011-02-16 at 07:54 -0600, Janorkar, Mayuresh wrote: check_timings and set_timings APIS are not present for panel-taal. OMAPFB provides a bootarg omapfb.mode for setting mode parameters which include display, resolution, bits-per-pixel. OMAPFB expects panel driver to have check_timings and set_timings APIs. These are checked by omapfb in case we wish to set default mode through bootargs. e.g.: omapfb.mode=lcd:864x480-16 (display device:width X height - bits per pixel) omapfb_set_def_mode function in omapfb-main.c essentially needs these functions otherwise it would return -EINVAL and default mode sent through bootargs would be ignored. I don't like this patch. You cannot change the timings for Taal, so those added functions look quite hacky. The reason for this patch isn't clear from the description (it should). If I guess correctly, the point of the patch is to be able to change the default color format via boot arguments when using taal panel? The intent of this patch was ability to change bits-per-pixel of framebuffer through bootargs. If so, I think the change should be in the omapfb driver. Perhaps the omapfb driver should: 1. check if check_timings set_timings exist 2. if they do exist, do the same thing as the code does now 3. if they don't, use get_timings to verify that the given resolution is correct But that would lead to a situation in which you would set the bits-per-pixel without checking if panel supports it. That wouldn't be perfect either, but I guess it should do the job. But this is again something where FB framework and OMAP HW do not quite match, and we end up with hacky solution, no matter what we do. But we can try to keep the hacks in the omapfb driver =). OMAPFB depends a on the attached panel for configuring FB parameters. panel-generic-dpi.c it has an API dpi_check_timings which checks whether timings are supported or not. How about adding a similar API for dsi_check_timings? We would call it from panel-taal. (I do understand that timings required by taal are only xres and yres much less compared to dpi) Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: linux-omap tree
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Friday, February 11, 2011 3:07 AM To: Janorkar, Mayuresh Cc: linux-omap@vger.kernel.org Subject: Re: linux-omap tree * Janorkar, Mayuresh ma...@ti.com [110209 22:25]: Hi! I am not able to find linux-omap tree on git.kernel.org. But linux-omap-pm is present. Something might have gone wrong while maintaining the tree. Is there any other place where the tree is being mirrored? Hmm seems to be there at: http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap- 2.6.git;a=summary Can you check again please? Let me know if there are issues. I can see it now. Thanks a lot for your help. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
linux-omap tree
Hi! I am not able to find linux-omap tree on git.kernel.org. But linux-omap-pm is present. Something might have gone wrong while maintaining the tree. Is there any other place where the tree is being mirrored? -Thanks, Mayuresh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: linux-omap tree
Thanks Keerthy that link is working fine. My concern was that on git.kernel.org (Main Page) I am unable to find linux-omap. -Thanks, Mayuresh -Original Message- From: J, KEERTHY Sent: Thursday, February 10, 2011 12:13 PM To: Janorkar, Mayuresh Cc: linux-omap@vger.kernel.org Subject: Re: linux-omap tree Mayuresh, Can you try this link: http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git Regards, Keerthy On Thu, Feb 10, 2011 at 11:57 AM, Janorkar, Mayuresh ma...@ti.com wrote: Hi! I am not able to find linux-omap tree on git.kernel.org. But linux-omap-pm is present. Something might have gone wrong while maintaining the tree. Is there any other place where the tree is being mirrored? -Thanks, Mayuresh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Regards and Thanks, Keerthy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: omapfb: no driver for display error with linux-2.6.37-rc7
Felipe, Elvis, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Elvis Dowson Sent: Monday, December 27, 2010 11:30 AM To: Felipe Contreras Cc: Linux OMAP Mailing List Subject: Re: omapfb: no driver for display error with linux-2.6.37-rc7 On Dec 27, 2010, at 4:39 AM, Felipe Contreras wrote: [2.175872] omapfb omapfb: no driver for display [Mayuresh]: This clearly shows that there is something went wrong in registering displays. So OMAPFB has not found any registered displays. Try passing omapdss.debug=1, omapfb.debug=1 in your bootargs and the log would be self explanatory. [2.180999] omapfb omapfb: failed to setup omapfb My bootargs are as follows: mmcargs=setenv bootargs console=ttyO2,115200n8 vram=12M omapfb.vram=0:2M omapfb.mode=480x272mr...@60 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait Do you have a proper CONFIG_OMAP2_VRAM_SIZE in your config? I've set the VRAM to 12, but the number of framebuffers to 1. Should it be 1 ? [Mayuresh]: No that should not matter. 12MB of vram for 1 FB is fine. And your bootargs state that you need 480*272*2 Bytes of memory. So 12 MB of total VRAM size is more than enough. But your bootargs state that you are providing only 2MB to FB0. Please try using omapfb.vram=0:5M. But if the problem is with the memory then OMAPFB would throw an error: Failed to allocate memory. (Yet your kernel execution has not reached there). CONFIG_OMAP2_VRAM_SIZE=12 CONFIG_FB_OMAP2=y CONFIG_FB_OMAP2_NUM_FBS=1 I've pasted a section of my .config file below. This is with omap2plus_defconfig, for a custom beagleboard. # # Graphics support # # CONFIG_DRM is not set # CONFIG_VGASTATE is not set # CONFIG_VIDEO_OUTPUT_CONTROL is not set CONFIG_FB=y CONFIG_FIRMWARE_EDID=y # CONFIG_FB_DDC is not set # CONFIG_FB_BOOT_VESA_SUPPORT is not set CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y # CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set # CONFIG_FB_SYS_FILLRECT is not set # CONFIG_FB_SYS_COPYAREA is not set # CONFIG_FB_SYS_IMAGEBLIT is not set # CONFIG_FB_FOREIGN_ENDIAN is not set # CONFIG_FB_SYS_FOPS is not set # CONFIG_FB_SVGALIB is not set # CONFIG_FB_MACMODES is not set # CONFIG_FB_BACKLIGHT is not set CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y # # Frame buffer hardware drivers # # CONFIG_FB_ARMCLCD is not set # CONFIG_FB_UVESA is not set # CONFIG_FB_S1D13XXX is not set # CONFIG_FB_TMIO is not set # CONFIG_FB_VIRTUAL is not set # CONFIG_FB_METRONOME is not set # CONFIG_FB_MB862XX is not set # CONFIG_FB_BROADSHEET is not set # CONFIG_FB_OMAP_BOOTLOADER_INIT is not set CONFIG_OMAP2_VRAM=y CONFIG_OMAP2_VRFB=y CONFIG_OMAP2_DSS=y CONFIG_OMAP2_VRAM_SIZE=12 CONFIG_OMAP2_DSS_DEBUG_SUPPORT=y # CONFIG_OMAP2_DSS_COLLECT_IRQ_STATS is not set CONFIG_OMAP2_DSS_DPI=y # CONFIG_OMAP2_DSS_RFBI is not set CONFIG_OMAP2_DSS_VENC=y # CONFIG_OMAP2_DSS_SDI is not set # CONFIG_OMAP2_DSS_DSI is not set # CONFIG_OMAP2_DSS_FAKE_VSYNC is not set CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=0 CONFIG_FB_OMAP2=y # CONFIG_FB_OMAP2_DEBUG_SUPPORT is not set CONFIG_FB_OMAP2_NUM_FBS=1 # # OMAP2/3 Display Device Drivers # # CONFIG_PANEL_GENERIC is not set # CONFIG_PANEL_SHARP_LS037V7DW01 is not set # CONFIG_PANEL_SHARP_LQ043T1DG01 is not set # CONFIG_PANEL_TOPPOLY_TDO35S is not set # CONFIG_PANEL_TPO_TD043MTEA1 is not set [Mayuresh]: I guess, you need to enable atleast one panel driver over here. Try enabling PANEL_GENERIC or SHARP_LS037V7DW01. CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_LCD_CLASS_DEVICE=y # CONFIG_LCD_L4F00242T03 is not set # CONFIG_LCD_LMS283GF05 is not set # CONFIG_LCD_LTV350QV is not set # CONFIG_LCD_TDO24M is not set # CONFIG_LCD_VGG2432A4 is not set CONFIG_LCD_PLATFORM=y # CONFIG_LCD_S6E63M0 is not set CONFIG_BACKLIGHT_CLASS_DEVICE=y CONFIG_BACKLIGHT_GENERIC=y # CONFIG_BACKLIGHT_ADP8860 is not set # # Display device support # CONFIG_DISPLAY_SUPPORT=y # # Display hardware drivers # # # Console display driver support # CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=y # CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y CONFIG_FONTS=y CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y # CONFIG_FONT_6x11 is not set # CONFIG_FONT_7x14 is not set # CONFIG_FONT_PEARL_8x8 is not set # CONFIG_FONT_ACORN_8x8 is not set # CONFIG_FONT_MINI_4x6 is not set # CONFIG_FONT_SUN8x16 is not set # CONFIG_FONT_SUN12x22 is not set # CONFIG_FONT_10x18 is not set # CONFIG_LOGO is not set Elvis Dowson -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at
[PATCH v2]: OMAP: DSS2: Adding check_timings and set_timings for panel-taal
Adding two APIs for panel-taal: check_timings and set_timings
These are required by omapfb in case we wish to set default mode through
bootargs.
e.g.: omapfb.mode=lcd:640x480-16 (display device:width X height - bits per
pixel)
omapfb_set_def_mode function in omapfb-main.c essentially needs these functions
otherwise it would return -EINVAL and default mode sent through bootargs
would be ignored.
Signed-off-by: Mayuresh Janorkar ma...@ti.com
---
drivers/video/omap2/displays/panel-taal.c | 27 +++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-taal.c
b/drivers/video/omap2/displays/panel-taal.c
index e1c765d..0bb2c30 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -476,6 +476,31 @@ static void taal_get_timings(struct omap_dss_device
*dssdev,
*timings = dssdev-panel.timings;
}
+static void taal_set_timings(struct omap_dss_device *dssdev,
+ struct omap_video_timings *timings)
+{
+ /*
+* TAAL panel's timing struct has only x_res and y_res
+* other timing parameters are not set
+*/
+ dssdev-panel.timings.x_res = timings-x_res;
+ dssdev-panel.timings.y_res = timings-y_res;
+}
+
+static int taal_check_timings(struct omap_dss_device *dssdev,
+ struct omap_video_timings *timings)
+{
+ /*
+* TAAL panel's timing struct has only x_res and y_res
+* other timing parameters are not set
+*/
+ if (!timings || timings-x_res != dssdev-panel.timings.x_res ||
+ timings-y_res != dssdev-panel.timings.y_res)
+ return -EINVAL;
+
+ return 0;
+}
+
static void taal_get_resolution(struct omap_dss_device *dssdev,
u16 *xres, u16 *yres)
{
@@ -1563,6 +1588,8 @@ static struct omap_dss_driver taal_driver = {
.memory_read= taal_memory_read,
.get_timings= taal_get_timings,
+ .set_timings= taal_set_timings,
+ .check_timings = taal_check_timings,
.driver = {
.name = taal,
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP: DSS2: Adding check_timings and set_timings for panel-taal
From: Mayuresh Janorkar ma...@ti.com
This patch would add two APIs for panel-taal:
check_timings and set_timings.
These are required by omapfb in case we wish to set default mode through
bootargs.
e.g.: omapfb.mode=lcd:640x480-16 (display device:width X height - bits per
pixel)
omapfb_set_def_mode function in omapfb-main.c essentially needs these functions
otherwise it would return -EINVAL and default mode sent through bootargs
would be ignored.
Signed-off-by: Mayuresh Janorkar ma...@ti.com
---
drivers/video/omap2/displays/panel-taal.c | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-taal.c
b/drivers/video/omap2/displays/panel-taal.c
index e1c765d..e29c308 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -476,6 +476,29 @@ static void taal_get_timings(struct omap_dss_device
*dssdev,
*timings = dssdev-panel.timings;
}
+static void taal_set_timings(struct omap_dss_device *dssdev,
+ struct omap_video_timings *timings)
+{
+ /* TAAL panel's timing struct has only x_res and y_res
+* other timing parameters are not set
+*/
+ dssdev-panel.timings.x_res = timings-x_res;
+ dssdev-panel.timings.y_res = timings-y_res;
+}
+
+static int taal_check_timings(struct omap_dss_device *dssdev,
+ struct omap_video_timings *timings)
+{
+ /* TAAL panel's timing struct has only x_res and y_res
+* other timing parameters are not set
+*/
+ if (!timings || timings-x_res != dssdev-panel.timings.x_res ||
+ timings-y_res != dssdev-panel.timings.y_res)
+ return -EINVAL;
+
+ return 0;
+}
+
static void taal_get_resolution(struct omap_dss_device *dssdev,
u16 *xres, u16 *yres)
{
@@ -1563,6 +1586,8 @@ static struct omap_dss_driver taal_driver = {
.memory_read= taal_memory_read,
.get_timings= taal_get_timings,
+ .set_timings= taal_set_timings,
+ .check_timings = taal_check_timings,
.driver = {
.name = taal,
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/3] Backlight: driver for Sharp LS037V7DW01 panel on OMAP machine
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Bryan Wu
Sent: Tuesday, November 30, 2010 5:38 PM
To: tomi.valkei...@nokia.com; linux-omap@vger.kernel.org; linux-arm-
ker...@lists.infradead.org; Gadiyar, Anand; rpur...@rpsys.net
Subject: [PATCH 1/3] Backlight: driver for Sharp LS037V7DW01 panel on OMAP
machine
This driver is split from drivers/video/backlight/sharp_ls037v7dw01.c
Signed-off-by: Bryan Wu bryan...@canonical.com
---
drivers/video/backlight/Kconfig | 10 ++
drivers/video/backlight/Makefile|1 +
drivers/video/backlight/sharp_ls037v7dw01.c | 144
+++
3 files changed, 155 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/backlight/sharp_ls037v7dw01.c
diff --git a/drivers/video/backlight/Kconfig
b/drivers/video/backlight/Kconfig
index e54a337..46b2415 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -307,6 +307,16 @@ config BACKLIGHT_PCF50633
If you have a backlight driven by a NXP PCF50633 MFD, say Y here
to
enable its driver.
+config BACKLIGHT_SHARP_LS037V7DW01
+ tristate Backlight driver for SHARP LS037V7DW01 Panel
+ depends on PANEL_GENERIC_DPI
+ help
+ If you are using Sharp LS037V7DW01 LCD panel, say Y here to enable
this driver.
+
+ To compile this driver as a module, choose M here: the module will
+ be called sharp_ls037v7dw01.
+
+
[Mayuresh]: Please do not introduce extra new lines.
endif # BACKLIGHT_CLASS_DEVICE
endif # BACKLIGHT_LCD_SUPPORT
diff --git a/drivers/video/backlight/Makefile
b/drivers/video/backlight/Makefile
index 44c0f81..c756f49 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -35,4 +35,5 @@ obj-$(CONFIG_BACKLIGHT_ADP5520) += adp5520_bl.o
obj-$(CONFIG_BACKLIGHT_ADP8860) += adp8860_bl.o
obj-$(CONFIG_BACKLIGHT_88PM860X) += 88pm860x_bl.o
obj-$(CONFIG_BACKLIGHT_PCF50633) += pcf50633-backlight.o
+obj-$(CONFIG_BACKLIGHT_SHARP_LS037V7DW01)+= sharp_ls037v7dw01.o
diff --git a/drivers/video/backlight/sharp_ls037v7dw01.c
b/drivers/video/backlight/sharp_ls037v7dw01.c
new file mode 100644
index 000..e90595e
--- /dev/null
+++ b/drivers/video/backlight/sharp_ls037v7dw01.c
@@ -0,0 +1,144 @@
+/*
+ * Backlight driver for Sharp LS037V7DW01
+ *
+ * Copyright (C) 2010 Canonical Ltd.
+ * Author: Bryan Wu bryan...@canonical.com
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify
it
+ * under the terms of the GNU General Public License version 2 as
published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/module.h
+#include linux/device.h
+#include linux/backlight.h
+#include linux/fb.h
+#include linux/err.h
+
+/* This OMAP platform header file is required by this driver */
+#include plat/display.h
+
+static int sharp_ls_bl_update_status(struct backlight_device *bl)
+{
+ struct omap_dss_device *dssdev = bl_get_data(bl);
+ int level;
+
+ if (!dssdev-set_backlight)
+ return -EINVAL;
+
+ if (bl-props.fb_blank == FB_BLANK_UNBLANK
+ bl-props.power == FB_BLANK_UNBLANK)
+ level = bl-props.brightness;
+ else
+ level = 0;
+
+ return dssdev-set_backlight(dssdev, level);
+}
+
+static int sharp_ls_bl_get_brightness(struct backlight_device *bl)
+{
+ if (bl-props.fb_blank == FB_BLANK_UNBLANK
+ bl-props.power == FB_BLANK_UNBLANK)
+ return bl-props.brightness;
+
+ return 0;
+}
+
+static const struct backlight_ops sharp_ls_bl_ops = {
+ .get_brightness = sharp_ls_bl_get_brightness,
+ .update_status = sharp_ls_bl_update_status,
+};
+
+static int __devinit sharp_ls_bl_probe(struct platform_device *pdev)
+{
+ struct backlight_properties props;
+ struct backlight_device *bl;
+ struct omap_dss_device *dssdev = pdev-dev.platform_data;
+
+ if (!dssdev)
+ return -EINVAL;
+
+ memset(props, 0, sizeof(struct backlight_properties));
+ props.max_brightness = dssdev-max_backlight_level;
+
+ bl = backlight_device_register(sharp-ls-bl, dssdev-dev, dssdev,
+ sharp_ls_bl_ops, props);
+ if (IS_ERR(bl))
+ return PTR_ERR(bl);
+
+ bl-props.fb_blank =
RE: DSS2 crash with shutdown -h now
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Robert Nelson
Sent: Wednesday, October 20, 2010 6:33 PM
To: Steve Sakoman
Cc: linux-omap@vger.kernel.org
Subject: Re: DSS2 crash with shutdown -h now
On Wed, Oct 20, 2010 at 7:44 AM, Steve Sakoman sako...@gmail.com wrote:
On Tue, Oct 19, 2010 at 9:42 PM, Taneja, Archit arc...@ti.com wrote:
Hi,
linux-omap-ow...@vger.kernel.org wrote:
I'm using a 2.6.35 kernel, and the generic panel driver.
I see this crash about 25% of the time, so I suspect a race condition.
Is anyone else encountering this?
Steve
Unmounting local filesystems...
Unhandled fault: external abort on non-linefetch (0x1028) at
0xfa050040 Internal error: : 1028 [#1] last sysfs file:
/sys/devices/virtual/vc/vcs12/uevent
Modules linked in: ipv6 uvcvideo videodev v4l1_compat ads7846
CPU: 0 Not tainted (2.6.35 #1)
PC is at dss_select_dispc_clk_source+0x20/0x40
LR is at omapdss_dpi_display_disable+0x20/0x50
pc : [c01f74d4] lr : [c01ffc80] psr: 6013
sp : ded59e38 ip : 0090 fp : 0001
r10: 0001 r9 : ded58000 r8 : c0032084
r7 : ded59e50 r6 : r5 : c01fcc28 r4 : c057da00
r3 : r2 : fa05 r1 : c05d062c r0 : 0002
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 10c5387d Table: 9ed84019 DAC: 0015 Process
halt (pid: 503, stack limit = 0xded582f0)
Stack: (0xded59e38 to 0xded5a000)
9e20:
c057da00 c020a430
9e40: c01fcc48 ded59e50 c022f424 dfc3fc78 dfccc170
dfe02400 c057d4cc
9e60: c057d4c0 c05d4fac c0230ba4 c0575de0 c022c6f8 28121969
cdef0123
9e80: fee1dead c0065d58 28121969 c0065ed4 0014 dfc17dd8 0001
dfc299c0
9ea0: ded59eb0 c0062ee4 c00546f0 000a4800 a013
ded59f08
9ec0: 0001 0014 ded58000 0001 0001 c0063068
ded59f08
9ee0: dfc299c0 dfc18500 ded59f08 0014 ded58000 c0063cb8 0001
9f00: 0006 c0063d2c 0014 0164 01f7
dfc299f8
9f20: 0164 dfc299f0 c057f598 fffd
c006e810
9f40: ded59f6c dfc299c0 c0052fbc dfc299c0 dff16e00
dec41080 dec92540
9f60: ded59fac ded59f70 c03e841c c0052f90 ff9c c0031f58
dec927a8 ded58000
9f80: 0006 0025
0006
9fa0: 0058 c0031f00 fee1dead 28121969 4321fedc
9fc0: 0006 0058 0001 0001 0001
0001
9fe0: 00011e50 bef36cb0 925c 400e23f8 2010 fee1dead
[c01f74d4]
(dss_select_dispc_clk_source+0x20/0x40) from [c01ffc80]
(omapdss_dpi_display_disable+0x20/0x50)
[c01ffc80] (omapdss_dpi_display_disable+0x20/0x50) from [c020a430]
(generic_panel_disable+0xc/0x18)
[c020a430] (generic_panel_disable+0xc/0x18) from [c01fcc48]
(dss_disable_device+0x20/0x2c)
[c01fcc48] (dss_disable_device+0x20/0x2c) from [c022f424]
(bus_for_each_dev+0x4c/0x8c) [c022f424] (bus_for_each_dev+0x4c/0x8c)
from
[c0230ba4] (platform_drv_shutdown+0x1c/0x24)
[c0230ba4] (platform_drv_shutdown+0x1c/0x24) from [c022c6f8]
(device_shutdown+0x70/0x94) [c022c6f8] (device_shutdown+0x70/0x94)
from
[c0065d58] (kernel_halt+0x10/0x2c) [c0065d58]
(kernel_halt+0x10/0x2c)
from [c0065ed4] (sys_reboot+0x118/0x1dc) [c0065ed4]
(sys_reboot+0x118/0x1dc) from [c0031f00]
(ret_fast_syscall+0x0/0x30)
Code: e5833000 eafd e59f101c e5912000 (e5923040)
OMAPFB: pan_display(0)
OMAPFB: setcmap
OMAPFB: setcmap
OMAPFB: setcmap
Are you running a fb app while shutting down?
My test method is to use a relatively minimal rootfs. It does launch
a console session on the fb using a USB KB on musb, which sits at the
login prompt throughout the test. I do not login via this console
session.
I login via serial port, wait till uptime reports 10 minutes, then
issue 'shutdown -h now'
Hi Steve
10 minutes?
Sounds very much like: http://www.spinics.net/lists/linux-
omap/msg34582.html
Yes, I also think that this patch would solve the issue.
Steve,
If you wish to disable display auto blanking, you can add this in your
bootargs: consoleblank=0
With that the crash would not be seen.
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=blob;f=Documentation/kernel-parameters.txt
-Thanks,
Mayuresh
*there might be a newer patch, that's just the one i had marked on my
list..
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at
OMAPFB query
Hi! For OMAPFB we have two header files: drivers/video/omap2/omapfb/omapfb.h include/linux/omapfb.h There are some definitions like: #define FB2OFB(fb_info) ((struct omapfb_info *)(fb_info-par)) This is not available in include/linux/omapfb.h Can anybody help me in understanding how a user space application can use these definitions in omap2/omapfb/omapfb.h -Thanks, Mayuresh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap4: fb: Adds missing display update call when panning
Hi Tomi, Could you please provide me info on how to update the screen from user's space incase of manual update mode? -Thanks, Mayuresh -Original Message- From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] Sent: Monday, July 26, 2010 1:17 PM To: Janorkar, Mayuresh Cc: linux-omap@vger.kernel.org; Diaz Prado, Gustavo Subject: Re: [PATCH] omap4: fb: Adds missing display update call when panning Hi, On Thu, 2010-07-15 at 14:37 +0200, ext Mayuresh Janorkar wrote: From: Gustavo Diaz Prado x0083...@ti.com Adds the missing display update call when panning, this is needed for the DSI panel when the auto-update feature is not enabled. The omapfb driver is not meant to make updates automatically, except on a few special cases (currently on initialization and when unblanking). It's the user space's responsibility to update the screen. The reason for this should be obvious if you think of a use case where you have, say, all 3 overlays on the LCD, and you want to pan all of them. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap4: fb: Adds missing display update call when panning
-Original Message-
From: Shilimkar, Santosh
Sent: Thursday, July 15, 2010 6:19 PM
To: Janorkar, Mayuresh; tomi.valkei...@nokia.com
Cc: linux-omap@vger.kernel.org; Diaz Prado, Gustavo
Subject: RE: [PATCH] omap4: fb: Adds missing display update call when
panning
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Janorkar, Mayuresh
Sent: Thursday, July 15, 2010 6:07 PM
To: tomi.valkei...@nokia.com
Cc: linux-omap@vger.kernel.org; Diaz Prado, Gustavo; Janorkar, Mayuresh
Subject: [PATCH] omap4: fb: Adds missing display update call when
panning
From: Gustavo Diaz Prado x0083...@ti.com
Adds the missing display update call when panning, this
is needed for the DSI panel when the auto-update feature is
not enabled.
Signed-off-by: Gustavo Diaz Prado x0083...@ti.com
Signed-off-by: Mayuresh Janorkar ma...@ti.com
---
drivers/video/omap2/omapfb/omapfb-main.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
b/drivers/video/omap2/omapfb/omapfb-main.c
index 4abb1d1..12d5382 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -1068,7 +1068,8 @@ static int omapfb_pan_display(struct
fb_var_screeninfo *var,
{
struct omapfb_info *ofbi = FB2OFB(fbi);
struct fb_var_screeninfo new_var;
- int r;
+ int r = 0;
+ struct omap_dss_device *display = fb2display(fbi);
DBG(pan_display(%d)\n, FB2OFB(fbi)-id);
@@ -1086,6 +1087,11 @@ static int omapfb_pan_display(struct
fb_var_screeninfo *var,
r = omapfb_apply_changes(fbi, 0);
+ if (display display-driver-update
+ display-driver-get_update_mode(display)
+ == OMAP_DSS_UPDATE_MANUAL)
If the display dereference is checked, there is no need to check the base
pointer (display), right ?
[Mayuresh]: That's correct. I would take it into account.
+ display-driver-update(display, 0, 0, var-xres, var-yres);
+
omapfb_put_mem_region(ofbi-region);
return r;
--
1.5.4.7
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Are there any more comments?
If not can I resend the patch incorporating Santosh's comments?
-Thanks,
Mayuresh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
