* Re: [PATCH] OMAPDSS: HACK: Ensure DSS clock domain gets out of idle when HDMI is enabled
From: Tomi Valkeinen @ 2012-02-09 12:02 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux, linux-fbdev
In-Reply-To: <1328769888-24790-1-git-send-email-archit@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1171 bytes --]
Hi,
On Thu, 2012-02-09 at 12:14 +0530, Archit Taneja wrote:
> For DSS clock domain to transition from idle to active state, it's necessary
> to enable the optional clock DSS_FCLK before we enable the module using the
> MODULEMODE bits in the DSS clock domain's CM_DSS_DSS_CLKCTRL register.
>
> This sequence was not followed correctly for the 'dss_hdmi' hwmod and it led
> to DSS clock domain not getting out of idle when pm_runtime_get_sync() was
> called for hdmi's platform device.
>
> Since the clock domain failed to change it's state to active, the hwmod code
> disables any clocks it had enabled before for this hwmod. This led to the clock
> 'dss_48mhz_clk' getting disabled.
>
> When hdmi's runtime_resume() op is called, the call to dss_runtime_get()
> correctly enables the DSS clock domain this time. But the clock 'dss_48mhz_clk'
> disabled before is needed for HDMI's PHY to function. Hence, the driver fails
There's something wrong with the "But the clock..." sentence above.
The patch looks good, but I think it'd be better to add brief HACK
comments in the code also. Otherwise it's too easy to forget about this.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH] ARM: OMAP1: ams-delta: clean up init data section assignments
From: Janusz Krzysztofik @ 2012-02-09 11:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1328696173-17226-1-git-send-email-grinberg@compulab.co.il>
The main purpose of this patch is to fix several section mismatch
warnings from the board file and a few board specific drivers,
introduced mostly with recent Amstrad Delta patch series, some of them
rising up only when building with CONFIG_MODULES not set.
While being at it, section assignments of all init data found in the
board file have been revised and hopefully optimised.
Created and tested on top of current linux-omap/omap1, commit
967809bd7faf71ddc29c8081e0f21db8b201a0f4.
Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
---
arch/arm/mach-omap1/board-ams-delta.c | 35 +++++++++++++++++----------------
drivers/input/serio/ams_delta_serio.c | 2 +-
drivers/mtd/nand/ams-delta.c | 2 +-
drivers/video/omap/lcd_ams_delta.c | 2 +-
4 files changed, 21 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c
index 87b1303..dc2455f 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -126,7 +126,7 @@ static const unsigned int ams_delta_keymap[] = {
#define LATCH2_PHYS 0x08000000
#define LATCH2_VIRT 0xEC000000
-static struct map_desc ams_delta_io_desc[] __initdata = {
+static struct map_desc ams_delta_io_desc[] __initconst = {
/* AMS_DELTA_LATCH1 */
{
.virtual = LATCH1_VIRT,
@@ -150,17 +150,17 @@ static struct map_desc ams_delta_io_desc[] __initdata = {
}
};
-static struct omap_lcd_config ams_delta_lcd_config = {
+static struct omap_lcd_config ams_delta_lcd_config __initconst = {
.ctrl_name = "internal",
};
-static struct omap_usb_config ams_delta_usb_config __initdata = {
+static struct omap_usb_config ams_delta_usb_config __initdata_or_module = {
.register_host = 1,
.hmc_mode = 16,
.pins[0] = 2,
};
-static struct omap_board_config_kernel ams_delta_config[] __initdata = {
+static struct omap_board_config_kernel ams_delta_config[] __initconst = {
{ OMAP_TAG_LCD, &ams_delta_lcd_config },
};
@@ -181,7 +181,7 @@ static struct bgpio_pdata latch1_pdata __initconst = {
.ngpio = LATCH1_NGPIO,
};
-static struct platform_device latch1_gpio_device = {
+static struct platform_device latch1_gpio_device __refdata = {
.name = "basic-mmio-gpio",
.id = 0,
.resource = latch1_resources,
@@ -205,7 +205,7 @@ static struct bgpio_pdata latch2_pdata __initconst = {
.ngpio = AMS_DELTA_LATCH2_NGPIO,
};
-static struct platform_device latch2_gpio_device = {
+static struct platform_device latch2_gpio_device __refdata = {
.name = "basic-mmio-gpio",
.id = 1,
.resource = latch2_resources,
@@ -271,7 +271,7 @@ void ams_delta_latch_write(int base, int ngpio, u16 mask, u16 value)
}
EXPORT_SYMBOL(ams_delta_latch_write);
-static struct resource ams_delta_nand_resources[] = {
+static struct resource ams_delta_nand_resources[] __initconst_or_module = {
[0] = {
.start = OMAP1_MPUIO_BASE,
.end = OMAP1_MPUIO_BASE +
@@ -280,14 +280,14 @@ static struct resource ams_delta_nand_resources[] = {
},
};
-static struct platform_device ams_delta_nand_device = {
+static struct platform_device ams_delta_nand_device __refdata = {
.name = "ams-delta-nand",
.id = -1,
.num_resources = ARRAY_SIZE(ams_delta_nand_resources),
.resource = ams_delta_nand_resources,
};
-static struct resource ams_delta_kp_resources[] = {
+static struct resource ams_delta_kp_resources[] __initconst_or_module = {
[0] = {
.start = INT_KEYBOARD,
.end = INT_KEYBOARD,
@@ -300,14 +300,14 @@ static const struct matrix_keymap_data ams_delta_keymap_data = {
.keymap_size = ARRAY_SIZE(ams_delta_keymap),
};
-static struct omap_kp_platform_data ams_delta_kp_data __initdata = {
+static struct omap_kp_platform_data ams_delta_kp_data __initconst_or_module = {
.rows = 8,
.cols = 8,
.keymap_data = &ams_delta_keymap_data,
.delay = 9,
};
-static struct platform_device ams_delta_kp_device = {
+static struct platform_device ams_delta_kp_device __refdata = {
.name = "omap-keypad",
.id = -1,
.dev = {
@@ -363,7 +363,8 @@ static struct gpio_led_platform_data leds_pdata __initconst = {
.num_leds = ARRAY_SIZE(gpio_leds),
};
-static struct i2c_board_info ams_delta_camera_board_info[] = {
+static struct i2c_board_info __initconst_or_module
+ams_delta_camera_board_info[] = {
{
I2C_BOARD_INFO("ov6650", 0x60),
},
@@ -387,7 +388,7 @@ static int ams_delta_camera_power(struct device *dev, int power)
#define ams_delta_camera_power NULL
#endif
-static struct soc_camera_link ams_delta_iclink = {
+static struct soc_camera_link ams_delta_iclink __initconst_or_module = {
.bus_id = 0, /* OMAP1 SoC camera bus */
.i2c_adapter_id = 1,
.board_info = &ams_delta_camera_board_info[0],
@@ -395,7 +396,7 @@ static struct soc_camera_link ams_delta_iclink = {
.power = ams_delta_camera_power,
};
-static struct platform_device ams_delta_camera_device = {
+static struct platform_device ams_delta_camera_device __refdata = {
.name = "soc-camera-pdrv",
.id = 0,
.dev = {
@@ -408,7 +409,7 @@ static struct omap1_cam_platform_data ams_delta_camera_platform_data = {
.lclk_khz_max = 1334, /* results in 5fps CIF, 10fps QCIF */
};
-static struct platform_device *ams_delta_devices[] __initdata = {
+static struct platform_device *ams_delta_devices[] __initconst = {
&latch1_gpio_device,
&latch2_gpio_device,
&ams_delta_kp_device,
@@ -459,7 +460,7 @@ static void __init ams_delta_init(void)
omap_writew(omap_readw(ARM_RSTCT1) | 0x0004, ARM_RSTCT1);
}
-static struct plat_serial8250_port ams_delta_modem_ports[] = {
+static struct plat_serial8250_port ams_delta_modem_ports[] __initdata = {
{
.membase = IOMEM(MODEM_VIRT),
.mapbase = MODEM_PHYS,
@@ -473,7 +474,7 @@ static struct plat_serial8250_port ams_delta_modem_ports[] = {
{ },
};
-static struct platform_device ams_delta_modem_device = {
+static struct platform_device ams_delta_modem_device __refdata = {
.name = "serial8250",
.id = PLAT8250_DEV_PLATFORM1,
.dev = {
diff --git a/drivers/input/serio/ams_delta_serio.c b/drivers/input/serio/ams_delta_serio.c
index 0571e2e..0830a76 100644
--- a/drivers/input/serio/ams_delta_serio.c
+++ b/drivers/input/serio/ams_delta_serio.c
@@ -103,7 +103,7 @@ static void ams_delta_serio_close(struct serio *serio)
gpio_set_value(AMS_DELTA_GPIO_PIN_KEYBRD_PWR, 0);
}
-static struct gpio ams_delta_gpios[] __initconst_or_module = {
+static const struct gpio ams_delta_gpios[] = {
{
.gpio = AMS_DELTA_GPIO_PIN_KEYBRD_DATA,
.flags = GPIOF_DIR_IN,
diff --git a/drivers/mtd/nand/ams-delta.c b/drivers/mtd/nand/ams-delta.c
index 85934dc..7341695 100644
--- a/drivers/mtd/nand/ams-delta.c
+++ b/drivers/mtd/nand/ams-delta.c
@@ -145,7 +145,7 @@ static int ams_delta_nand_ready(struct mtd_info *mtd)
return gpio_get_value(AMS_DELTA_GPIO_PIN_NAND_RB);
}
-static struct gpio _mandatory_gpio[] __initconst_or_module = {
+static const struct gpio _mandatory_gpio[] = {
{
.gpio = AMS_DELTA_GPIO_PIN_NAND_NCE,
.flags = GPIOF_OUT_INIT_HIGH,
diff --git a/drivers/video/omap/lcd_ams_delta.c b/drivers/video/omap/lcd_ams_delta.c
index 0e71e28..d3a3113 100644
--- a/drivers/video/omap/lcd_ams_delta.c
+++ b/drivers/video/omap/lcd_ams_delta.c
@@ -99,7 +99,7 @@ static struct lcd_ops ams_delta_lcd_ops = {
/* omapfb panel section */
-static struct gpio _gpios[] __initconst_or_module = {
+static const struct gpio _gpios[] = {
{
.gpio = AMS_DELTA_GPIO_PIN_LCD_VBLEN,
.flags = GPIOF_OUT_INIT_LOW,
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH 00/16] rmk's patch series for fixing OMAP
From: Tomi Valkeinen @ 2012-02-09 10:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1328776220.12747.5.camel@lws-gamez>
[-- Attachment #1: Type: text/plain, Size: 545 bytes --]
On Thu, 2012-02-09 at 09:30 +0100, Teresa Gamez wrote:
> Am Donnerstag, den 09.02.2012, 09:02 +0200 schrieb Tomi Valkeinen:
> > The problem is present in all kernels where we have the HDMI driver, so
> > 2.6.39+.
>
> Are there already backported patches out there for 3.0/3.1?
> We are quite interested in this.
I pushed three branches to git://gitorious.org/linux-omap-dss2/linux.git
fixes/for-3.0-stable
fixes/for-3.1-stable
fixes/for-3.2-stable
Which contain the necessary backported patches for each version.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 00/16] rmk's patch series for fixing OMAP
From: Teresa Gamez @ 2012-02-09 8:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1328770969.1909.11.camel@deskari>
Am Donnerstag, den 09.02.2012, 09:02 +0200 schrieb Tomi Valkeinen:
> On Thu, 2012-02-09 at 00:53 +0000, Russell King - ARM Linux wrote:
>
> > Moreover, only last Monday did I enable the OMAP2 DSS subsystem on the
> > 4430 SDP platform, _including_ the HDMI code, and looking at the commit
> > it could be one of those platforms which is affected.
> >
> > As I don't have a HDMI cable connected to the system, and I ran that
> > kernel overnight, and I tried opening each /dev/fb* device, what I'm now
> > wondering is: have I destroyed the HDMI PHY on my 4430SDP?
>
> Probably not. I don't know the exact details of the HW bug (I wrote the
> patch as it took too long for the person responsible for it to come up
> with a decent patch), but my understanding is that the cable needs to be
> plugged in at some point, and then removed.
>
> Thinking about this now, I guess I should've sent queries to get a
> proper description of the situation where the bug happens.
>
> > However, you raise another point, a much more serious one at that. Is
> > this problem also present in 3.2? The patch seems to apply almost cleanly
> > to that kernel version, so I guess it is. It fails to apply to v3.1
> > because of missing files, so I guess 3.1 is unaffected.
> >
> > So, why isn't this patch copied to the stable people?
>
> Good point, I'll take it to the stable people.
>
> The problem is present in all kernels where we have the HDMI driver, so
> 2.6.39+.
Are there already backported patches out there for 3.0/3.1?
We are quite interested in this.
Regards,
Teresa
>
> > For hardware destruction issues, once the problem has been identified, it
> > should be shouted about very loudly to get it upstream as quickly as
> > possible. I'm sure Linus would've even taken it in patch form.
> >
> > (You do realise that Linus does apply patches as well as pulling trees?)
>
> Yes, I should've taken this directly to Linus.
>
> Tomi
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 00/16] rmk's patch series for fixing OMAP
From: Tomi Valkeinen @ 2012-02-09 7:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120209005334.GG25414@n2100.arm.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1726 bytes --]
On Thu, 2012-02-09 at 00:53 +0000, Russell King - ARM Linux wrote:
> Moreover, only last Monday did I enable the OMAP2 DSS subsystem on the
> 4430 SDP platform, _including_ the HDMI code, and looking at the commit
> it could be one of those platforms which is affected.
>
> As I don't have a HDMI cable connected to the system, and I ran that
> kernel overnight, and I tried opening each /dev/fb* device, what I'm now
> wondering is: have I destroyed the HDMI PHY on my 4430SDP?
Probably not. I don't know the exact details of the HW bug (I wrote the
patch as it took too long for the person responsible for it to come up
with a decent patch), but my understanding is that the cable needs to be
plugged in at some point, and then removed.
Thinking about this now, I guess I should've sent queries to get a
proper description of the situation where the bug happens.
> However, you raise another point, a much more serious one at that. Is
> this problem also present in 3.2? The patch seems to apply almost cleanly
> to that kernel version, so I guess it is. It fails to apply to v3.1
> because of missing files, so I guess 3.1 is unaffected.
>
> So, why isn't this patch copied to the stable people?
Good point, I'll take it to the stable people.
The problem is present in all kernels where we have the HDMI driver, so
2.6.39+.
> For hardware destruction issues, once the problem has been identified, it
> should be shouted about very loudly to get it upstream as quickly as
> possible. I'm sure Linus would've even taken it in patch form.
>
> (You do realise that Linus does apply patches as well as pulling trees?)
Yes, I should've taken this directly to Linus.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH] OMAPDSS: HACK: Ensure DSS clock domain gets out of idle when HDMI is enabled
From: Archit Taneja @ 2012-02-09 6:56 UTC (permalink / raw)
To: linux-omap; +Cc: tomi.valkeinen, linux, linux-fbdev, Archit Taneja
For DSS clock domain to transition from idle to active state, it's necessary
to enable the optional clock DSS_FCLK before we enable the module using the
MODULEMODE bits in the DSS clock domain's CM_DSS_DSS_CLKCTRL register.
This sequence was not followed correctly for the 'dss_hdmi' hwmod and it led
to DSS clock domain not getting out of idle when pm_runtime_get_sync() was
called for hdmi's platform device.
Since the clock domain failed to change it's state to active, the hwmod code
disables any clocks it had enabled before for this hwmod. This led to the clock
'dss_48mhz_clk' getting disabled.
When hdmi's runtime_resume() op is called, the call to dss_runtime_get()
correctly enables the DSS clock domain this time. But the clock 'dss_48mhz_clk'
disabled before is needed for HDMI's PHY to function. Hence, the driver fails
when it tries to enable HDMI's PHY.
Fix this for now by ensuring that dss_runtime_get() is called before we call
pm_runtime_get_sync() for hdmi's platform device. A correct fix for later would
be to modify the DSS related hwmod's mainclks, and also some changes in how
opt clocks are handled in the DSS driver.
This fixes the issue of HDMI not working when it's the default display. The
issue is not seen if any other display is already enabled as the first display
would have already correctly enabled the DSS clock domain.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/hdmi.c | 16 +++++++++++++++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index d7aa3b0..ce16a91 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -165,9 +165,21 @@ static int hdmi_runtime_get(void)
DSSDBG("hdmi_runtime_get\n");
+ r = dss_runtime_get();
+ if (r < 0)
+ goto err_get_dss;
+
r = pm_runtime_get_sync(&hdmi.pdev->dev);
WARN_ON(r < 0);
- return r < 0 ? r : 0;
+ if (r < 0)
+ goto err_get_hdmi;
+
+ return 0;
+
+err_get_hdmi:
+ dss_runtime_put();
+err_get_dss:
+ return r;
}
static void hdmi_runtime_put(void)
@@ -178,6 +190,8 @@ static void hdmi_runtime_put(void)
r = pm_runtime_put_sync(&hdmi.pdev->dev);
WARN_ON(r < 0);
+
+ dss_runtime_put();
}
int hdmi_init_display(struct omap_dss_device *dssdev)
--
1.7.5.4
^ permalink raw reply related
* [PATCH v2] video:da8xx-fb: calculate pixel clock period for the panel
From: Manjunathappa, Prakash @ 2012-02-09 6:36 UTC (permalink / raw)
To: linux-fbdev
Cc: Florian Tobias Schandinat, davinci-linux-open-source,
linux-kernel, Manjunathappa, Prakash
Patch calculates pixel clock period in pico seconds and updates
the same in variable screen information structure. fbset utility
uses this information.
Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com>
---
Since v1:
Fixed the spelling mistake.
drivers/video/da8xx-fb.c | 19 ++++++++++++++++++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index f360d62..882dd67 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -32,6 +32,7 @@
#include <linux/console.h>
#include <linux/slab.h>
#include <video/da8xx-fb.h>
+#include <asm/div64.h>
#define DRIVER_NAME "da8xx_lcdc"
@@ -174,7 +175,6 @@ static struct fb_var_screeninfo da8xx_fb_var __devinitdata = {
.activate = 0,
.height = -1,
.width = -1,
- .pixclock = 46666, /* 46us - AUO display */
.accel_flags = 0,
.left_margin = LEFT_MARGIN,
.right_margin = RIGHT_MARGIN,
@@ -1048,6 +1048,22 @@ static struct fb_ops da8xx_fb_ops = {
.fb_blank = cfb_blank,
};
+/* Calculate and return pixel clock period in pico seconds */
+static unsigned int da8xxfb_pixel_clk_period(struct da8xx_fb_par *par)
+{
+ unsigned int lcd_clk, div;
+ unsigned int configured_pix_clk;
+ unsigned long long pix_clk_period_picosec = 1000000000000ULL;
+
+ lcd_clk = clk_get_rate(par->lcdc_clk);
+ div = lcd_clk / par->pxl_clk;
+ configured_pix_clk = (lcd_clk / div);
+
+ do_div(pix_clk_period_picosec, configured_pix_clk);
+
+ return pix_clk_period_picosec;
+}
+
static int __devinit fb_probe(struct platform_device *device)
{
struct da8xx_lcdc_platform_data *fb_pdata @@ -1209,6 +1225,7 @@ static int __devinit fb_probe(struct platform_device *device)
da8xx_fb_var.hsync_len = lcdc_info->hsw;
da8xx_fb_var.vsync_len = lcdc_info->vsw;
+ da8xx_fb_var.pixclock = da8xxfb_pixel_clk_period(par);
/* Initialize fbinfo */
da8xx_fb_info->flags = FBINFO_FLAG_DEFAULT;
--
1.7.1
^ permalink raw reply related
* [PATCH] video:da8xx-fb: calculate pixel clock period for the panel
From: Manjunathappa, Prakash @ 2012-02-09 5:16 UTC (permalink / raw)
To: linux-fbdev
Cc: Florian Tobias Schandinat, davinci-linux-open-source,
linux-kernel, Manjunathappa, Prakash
In-Reply-To: <1328763879-16345-1-git-send-email-prakash.pm@ti.com>
Patch calculates pixel clock period in pico seconds and updates
the same in variable screen information structure. fbset utility
uses this information.
Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com>
---
drivers/video/da8xx-fb.c | 21 ++++++++++++++++++++-
1 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index f360d62..8b0a174 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -32,6 +32,7 @@
#include <linux/console.h>
#include <linux/slab.h>
#include <video/da8xx-fb.h>
+#include <asm/div64.h>
#define DRIVER_NAME "da8xx_lcdc"
@@ -174,7 +175,6 @@ static struct fb_var_screeninfo da8xx_fb_var __devinitdata = {
.activate = 0,
.height = -1,
.width = -1,
- .pixclock = 46666, /* 46us - AUO display */
.accel_flags = 0,
.left_margin = LEFT_MARGIN,
.right_margin = RIGHT_MARGIN,
@@ -1048,6 +1048,24 @@ static struct fb_ops da8xx_fb_ops = {
.fb_blank = cfb_blank,
};
+/*
+ * Calculate and return pixel clock period in pico secods
+ */
+static unsigned int da8xxfb_pixel_clk_period(struct da8xx_fb_par *par)
+{
+ unsigned int lcd_clk, div;
+ unsigned int configured_pix_clk;
+ unsigned long long pix_clk_period_picosec = 1000000000000ULL;
+
+ lcd_clk = clk_get_rate(par->lcdc_clk);
+ div = lcd_clk / par->pxl_clk;
+ configured_pix_clk = (lcd_clk / div);
+
+ do_div(pix_clk_period_picosec, configured_pix_clk);
+
+ return pix_clk_period_picosec;
+}
+
static int __devinit fb_probe(struct platform_device *device)
{
struct da8xx_lcdc_platform_data *fb_pdata @@ -1209,6 +1227,7 @@ static int __devinit fb_probe(struct platform_device *device)
da8xx_fb_var.hsync_len = lcdc_info->hsw;
da8xx_fb_var.vsync_len = lcdc_info->vsw;
+ da8xx_fb_var.pixclock = da8xxfb_pixel_clk_period(par);
/* Initialize fbinfo */
da8xx_fb_info->flags = FBINFO_FLAG_DEFAULT;
--
1.7.1
^ permalink raw reply related
* [PATCH] video: da8xx-fb: Fix build warning on unused label
From: Manjunathappa, Prakash @ 2012-02-09 5:16 UTC (permalink / raw)
To: linux-fbdev
Cc: Florian Tobias Schandinat, davinci-linux-open-source,
linux-kernel, Manjunathappa, Prakash
Patch fixes build warning on label "err_cpu_freq" when CONFIG_CPU_FREQ
is not defined.
Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com>
---
drivers/video/da8xx-fb.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 29577bf..f360d62 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -1264,8 +1264,8 @@ static int __devinit fb_probe(struct platform_device *device)
irq_freq:
#ifdef CONFIG_CPU_FREQ
lcd_da8xx_cpufreq_deregister(par);
-#endif
err_cpu_freq:
+#endif
unregister_framebuffer(da8xx_fb_info);
err_dealloc_cmap:
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 00/16] rmk's patch series for fixing OMAP
From: Russell King - ARM Linux @ 2012-02-09 0:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4F32DBB5.4010004@gmx.de>
On Wed, Feb 08, 2012 at 08:31:49PM +0000, Florian Tobias Schandinat wrote:
> Hi Russell,
>
> On 02/08/2012 04:35 PM, Russell King - ARM Linux wrote:
> > commit c49d005b6cc8491fad5b24f82805be2d6bcbd3dd
> > Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > Date: Tue Jan 17 11:09:57 2012 +0200
> >
> > OMAPDSS: HDMI: PHY burnout fix
> >
> > A hardware bug in the OMAP4 HDMI PHY causes physical damage to the board
> > if the HDMI PHY is kept powered on when the cable is not connected.
>
> I agree this is a serious issue.
>
> > which now has me wondering if, by trying to boot v3.3-rc2 on this board
> > during the past week, I have a destroyed HDMI interface on it.
>
> I am not sure as I don't keep track of all OMAP changes, but you make it
> sound like a regression, is there any difference to 3.2 behavior?
I've no idea when the problem was introduced, that's not the point that
I'm making. The point that I'm making is that the patch is dated January
17th, it was apparantly committed on the 26th, and it went into mainline
on the 8th February.
For a patch which fixes a _hardware_ _destruction_ issue, three weeks is
_FAR_ too long for it to take to get into mainline.
Moreover, only last Monday did I enable the OMAP2 DSS subsystem on the
4430 SDP platform, _including_ the HDMI code, and looking at the commit
it could be one of those platforms which is affected.
As I don't have a HDMI cable connected to the system, and I ran that
kernel overnight, and I tried opening each /dev/fb* device, what I'm now
wondering is: have I destroyed the HDMI PHY on my 4430SDP?
But that's not really the point. The point is, for someone to sit on such
a patch for weeks is, in my opinion, as good as saying to your users "I
don't care if you bust your hardware."
However, you raise another point, a much more serious one at that. Is
this problem also present in 3.2? The patch seems to apply almost cleanly
to that kernel version, so I guess it is. It fails to apply to v3.1
because of missing files, so I guess 3.1 is unaffected.
So, why isn't this patch copied to the stable people?
And why is there this seemingly lack of care for hardware destruction bugs?
Please, if it affects v3.2, PLEASE PLEASE PLEASE tell the stable people
who know nothing about this commit until I asked them this evening about
it.
> > So, a big thanks for sitting on that fix and exposing peoples hardware
> > to damage, that shows real professionalism.
>
> Well, I am no professional to begin with, at least in the sense of getting paid
> for it. That said I'm quite happy if I manage to find a few hours every weekend
> to do the work. Given that the final thing should be tested in -next before I
> ask Linus to pull, it is completely usual (and even quite fast) if things take
> 8-13 days on my end. If this isn't fast enough for Tomi, he'd better ask Linus
> to pull directly for such issues.
For hardware destruction issues, once the problem has been identified, it
should be shouted about very loudly to get it upstream as quickly as
possible. I'm sure Linus would've even taken it in patch form.
(You do realise that Linus does apply patches as well as pulling trees?)
^ permalink raw reply
* [PATCH v2] backlight: add support for Pandora backlight
From: Grazvydas Ignotas @ 2012-02-08 23:42 UTC (permalink / raw)
To: linux-fbdev
This patch adds support for pandora (openpandora.org) backlight.
It might look like all this could be done using pwm_bl.c instead,
but there is a need of special programming sequence when turning
on the LED driver chip or else it will misbehave. Doing this using
pwm_bl.c would require to use some register programming and pwm
functions from platform code, and ARM maintainers are allergic to
driver-like code in /arch/arm nowadays. The PMIC PWM driver is
currently missing too, so pwm_bl.c can't be used anyway.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
---
changed in v2: fixed a bug where setting brightness to 0 twice
would actually turn the backlight on.
We had this driver in pandora tree for a couple of years now, but
while cleaning it up for mainline submission I've introduced this
bug, sorry for the noise.
drivers/video/backlight/Kconfig | 7 ++
drivers/video/backlight/Makefile | 1 +
drivers/video/backlight/pandora_bl.c | 171 ++++++++++++++++++++++++++++++++++
3 files changed, 179 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/backlight/pandora_bl.c
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 681b369..3f03954 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -334,6 +334,13 @@ config BACKLIGHT_AAT2870
If you have a AnalogicTech AAT2870 say Y to enable the
backlight driver.
+config BACKLIGHT_PANDORA
+ tristate "Backlight driver for Pandora console"
+ depends on TWL4030_CORE
+ help
+ If you have a Pandora console, say Y to enable the
+ backlight driver.
+
endif # BACKLIGHT_CLASS_DEVICE
endif # BACKLIGHT_LCD_SUPPORT
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index af5cf65..c73169c 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -38,4 +38,5 @@ obj-$(CONFIG_BACKLIGHT_ADP8870) += adp8870_bl.o
obj-$(CONFIG_BACKLIGHT_88PM860X) += 88pm860x_bl.o
obj-$(CONFIG_BACKLIGHT_PCF50633) += pcf50633-backlight.o
obj-$(CONFIG_BACKLIGHT_AAT2870) += aat2870_bl.o
+obj-$(CONFIG_BACKLIGHT_PANDORA) += pandora_bl.o
diff --git a/drivers/video/backlight/pandora_bl.c b/drivers/video/backlight/pandora_bl.c
new file mode 100644
index 0000000..4ec3074
--- /dev/null
+++ b/drivers/video/backlight/pandora_bl.c
@@ -0,0 +1,171 @@
+/*
+ * Backlight driver for Pandora handheld.
+ * Pandora uses TWL4030 PWM0 -> TPS61161 combo for control backlight.
+ * Based on pwm_bl.c
+ *
+ * Copyright 2009,2012 Gražvydas Ignotas <notasas@gmail.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.
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/platform_device.h>
+#include <linux/delay.h>
+#include <linux/fb.h>
+#include <linux/backlight.h>
+#include <linux/i2c/twl.h>
+#include <linux/err.h>
+
+#define TWL_PWM0_ON 0x00
+#define TWL_PWM0_OFF 0x01
+
+#define TWL_INTBR_GPBR1 0x0c
+#define TWL_INTBR_PMBR1 0x0d
+
+#define TWL_PMBR1_PWM0_MUXMASK 0x0c
+#define TWL_PMBR1_PWM0 0x04
+#define PWM0_CLK_ENABLE BIT(0)
+#define PWM0_ENABLE BIT(2)
+
+/* range accepted by hardware */
+#define MIN_VALUE 9
+#define MAX_VALUE 63
+#define MAX_USER_VALUE (MAX_VALUE - MIN_VALUE)
+
+#define PANDORABL_WAS_OFF BL_CORE_DRIVER1
+
+static int pandora_backlight_update_status(struct backlight_device *bl)
+{
+ int brightness = bl->props.brightness;
+ u8 r;
+
+ if (bl->props.power != FB_BLANK_UNBLANK)
+ brightness = 0;
+ if (bl->props.state & BL_CORE_FBBLANK)
+ brightness = 0;
+ if (bl->props.state & BL_CORE_SUSPENDED)
+ brightness = 0;
+
+ if ((unsigned int)brightness > MAX_USER_VALUE)
+ brightness = MAX_USER_VALUE;
+
+ if (brightness = 0) {
+ if (bl->props.state & PANDORABL_WAS_OFF)
+ goto done;
+
+ /* first disable PWM0 output, then clock */
+ twl_i2c_read_u8(TWL4030_MODULE_INTBR, &r, TWL_INTBR_GPBR1);
+ r &= ~PWM0_ENABLE;
+ twl_i2c_write_u8(TWL4030_MODULE_INTBR, r, TWL_INTBR_GPBR1);
+ r &= ~PWM0_CLK_ENABLE;
+ twl_i2c_write_u8(TWL4030_MODULE_INTBR, r, TWL_INTBR_GPBR1);
+
+ goto done;
+ }
+
+ if (bl->props.state & PANDORABL_WAS_OFF) {
+ /*
+ * set PWM duty cycle to max. TPS61161 seems to use this
+ * to calibrate it's PWM sensitivity when it starts.
+ */
+ twl_i2c_write_u8(TWL4030_MODULE_PWM0, MAX_VALUE,
+ TWL_PWM0_OFF);
+
+ /* first enable clock, then PWM0 out */
+ twl_i2c_read_u8(TWL4030_MODULE_INTBR, &r, TWL_INTBR_GPBR1);
+ r &= ~PWM0_ENABLE;
+ r |= PWM0_CLK_ENABLE;
+ twl_i2c_write_u8(TWL4030_MODULE_INTBR, r, TWL_INTBR_GPBR1);
+ r |= PWM0_ENABLE;
+ twl_i2c_write_u8(TWL4030_MODULE_INTBR, r, TWL_INTBR_GPBR1);
+
+ /*
+ * TI made it very easy to enable digital control, so easy that
+ * it often triggers unintentionally and disabes PWM control,
+ * so wait until 1 wire mode detection window ends.
+ */
+ usleep_range(2000, 10000);
+ }
+
+ twl_i2c_write_u8(TWL4030_MODULE_PWM0, MIN_VALUE + brightness,
+ TWL_PWM0_OFF);
+
+done:
+ if (brightness != 0)
+ bl->props.state &= ~PANDORABL_WAS_OFF;
+ else
+ bl->props.state |= PANDORABL_WAS_OFF;
+
+ return 0;
+}
+
+static int pandora_backlight_get_brightness(struct backlight_device *bl)
+{
+ return bl->props.brightness;
+}
+
+static const struct backlight_ops pandora_backlight_ops = {
+ .options = BL_CORE_SUSPENDRESUME,
+ .update_status = pandora_backlight_update_status,
+ .get_brightness = pandora_backlight_get_brightness,
+};
+
+static int pandora_backlight_probe(struct platform_device *pdev)
+{
+ struct backlight_properties props;
+ struct backlight_device *bl;
+ u8 r;
+
+ memset(&props, 0, sizeof(props));
+ props.max_brightness = MAX_USER_VALUE;
+ props.type = BACKLIGHT_RAW;
+ bl = backlight_device_register(pdev->name, &pdev->dev,
+ NULL, &pandora_backlight_ops, &props);
+ if (IS_ERR(bl)) {
+ dev_err(&pdev->dev, "failed to register backlight\n");
+ return PTR_ERR(bl);
+ }
+
+ platform_set_drvdata(pdev, bl);
+
+ /* 64 cycle period, ON position 0 */
+ twl_i2c_write_u8(TWL4030_MODULE_PWM0, 0x80, TWL_PWM0_ON);
+
+ bl->props.state |= PANDORABL_WAS_OFF;
+ bl->props.brightness = MAX_USER_VALUE;
+ backlight_update_status(bl);
+
+ /* enable PWM function in pin mux */
+ twl_i2c_read_u8(TWL4030_MODULE_INTBR, &r, TWL_INTBR_PMBR1);
+ r &= ~TWL_PMBR1_PWM0_MUXMASK;
+ r |= TWL_PMBR1_PWM0;
+ twl_i2c_write_u8(TWL4030_MODULE_INTBR, r, TWL_INTBR_PMBR1);
+
+ return 0;
+}
+
+static int pandora_backlight_remove(struct platform_device *pdev)
+{
+ struct backlight_device *bl = platform_get_drvdata(pdev);
+ backlight_device_unregister(bl);
+ return 0;
+}
+
+static struct platform_driver pandora_backlight_driver = {
+ .driver = {
+ .name = "pandora-backlight",
+ .owner = THIS_MODULE,
+ },
+ .probe = pandora_backlight_probe,
+ .remove = pandora_backlight_remove,
+};
+
+module_platform_driver(pandora_backlight_driver);
+
+MODULE_AUTHOR("Gražvydas Ignotas <notasas@gmail.com>");
+MODULE_DESCRIPTION("Pandora Backlight Driver");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:pandora-backlight");
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 02/16] ARM: omap: fix oops in drivers/video/omap2/dss/dpi.c
From: Tony Lindgren @ 2012-02-08 23:32 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: linux-omap, Tomi Valkeinen, Florian Tobias Schandinat,
linux-fbdev
In-Reply-To: <20120208225012.GA25414@n2100.arm.linux.org.uk>
* Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 14:19]:
> On Wed, Feb 08, 2012 at 10:36:07AM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 08:05]:
> > > When a PMIC is not found, this driver is unable to obtain its
> > > 'vdds_dsi_reg' regulator. Even through its initialization function
> > > fails, other code still calls its enable function, which fails to
> > > check whether it has this regulator before asking for it to be enabled.
> > >
> > > This fixes the oops, however a better fix would be to sort out the
> > > upper layers to prevent them calling into a module which failed to
> > > initialize.
> > >
> > > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> >
> > Tomi can look into fixing this properly for v3.4:
> >
> > Acked-by: Tony Lindgren <tony@atomide.com>
>
> No, it's a thing for v3.3, because you can still get this oops.
>
> I expect _most_ of these patches will go into v3.3, and anything with
> 'fix' or 'oops' in especially I want to see in v3.3.
I acked your patch for -rc. Then Tomi can work on the "better fix part"
you mention above for v3.4 and that's what I meant by my comment
above.
Or is there something else that needs fixing for the -rc series there?
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 02/16] ARM: omap: fix oops in drivers/video/omap2/dss/dpi.c
From: Russell King - ARM Linux @ 2012-02-08 22:50 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-omap, Tomi Valkeinen, Florian Tobias Schandinat,
linux-fbdev
In-Reply-To: <20120208183607.GB29796@atomide.com>
On Wed, Feb 08, 2012 at 10:36:07AM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 08:05]:
> > When a PMIC is not found, this driver is unable to obtain its
> > 'vdds_dsi_reg' regulator. Even through its initialization function
> > fails, other code still calls its enable function, which fails to
> > check whether it has this regulator before asking for it to be enabled.
> >
> > This fixes the oops, however a better fix would be to sort out the
> > upper layers to prevent them calling into a module which failed to
> > initialize.
> >
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>
> Tomi can look into fixing this properly for v3.4:
>
> Acked-by: Tony Lindgren <tony@atomide.com>
No, it's a thing for v3.3, because you can still get this oops.
I expect _most_ of these patches will go into v3.3, and anything with
'fix' or 'oops' in especially I want to see in v3.3.
^ permalink raw reply
* Re: [PATCH 00/16] rmk's patch series for fixing OMAP
From: Florian Tobias Schandinat @ 2012-02-08 20:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120208163546.GA15849@n2100.arm.linux.org.uk>
Hi Russell,
On 02/08/2012 04:35 PM, Russell King - ARM Linux wrote:
> commit c49d005b6cc8491fad5b24f82805be2d6bcbd3dd
> Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Date: Tue Jan 17 11:09:57 2012 +0200
>
> OMAPDSS: HDMI: PHY burnout fix
>
> A hardware bug in the OMAP4 HDMI PHY causes physical damage to the board
> if the HDMI PHY is kept powered on when the cable is not connected.
I agree this is a serious issue.
> which now has me wondering if, by trying to boot v3.3-rc2 on this board
> during the past week, I have a destroyed HDMI interface on it.
I am not sure as I don't keep track of all OMAP changes, but you make it sound
like a regression, is there any difference to 3.2 behavior?
> So, a big thanks for sitting on that fix and exposing peoples hardware
> to damage, that shows real professionalism.
Well, I am no professional to begin with, at least in the sense of getting paid
for it. That said I'm quite happy if I manage to find a few hours every weekend
to do the work. Given that the final thing should be tested in -next before I
ask Linus to pull, it is completely usual (and even quite fast) if things take
8-13 days on my end. If this isn't fast enough for Tomi, he'd better ask Linus
to pull directly for such issues.
This one was also somewhat special as I had to learn how to deal with PGP and
signed tags to make Linus happy.
Best regards,
Florian Tobias Schandinat
^ permalink raw reply
* Re: [PATCH 00/16] rmk's patch series for fixing OMAP
From: Tony Lindgren @ 2012-02-08 19:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120208163546.GA15849@n2100.arm.linux.org.uk>
* Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 08:05]:
> This is my set of patches for fixing OMAP for v3.3.
>
> This is the complete series of patches I'm currently applying to _my_
> tree to get v3.3-rc2 into a usable and sane state.
I've acked all but two. The if (1) hack must have some better
solution, then I'd like to see Paul's ack on the error formatting
patch.
Other than that go for it. Thanks for the nice series, too bad
these were not found earlier.
> I want to see most of the problems uncovered in this series fixed sooner
> rather than later, and certainly not taking three plus weeks to get into
> mainline like this rather serious looking commit did:
>
> commit c49d005b6cc8491fad5b24f82805be2d6bcbd3dd
> Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Date: Tue Jan 17 11:09:57 2012 +0200
>
> OMAPDSS: HDMI: PHY burnout fix
>
> A hardware bug in the OMAP4 HDMI PHY causes physical damage to the board
> if the HDMI PHY is kept powered on when the cable is not connected.
>
> which now has me wondering if, by trying to boot v3.3-rc2 on this board
> during the past week, I have a destroyed HDMI interface on it.
>
> So, a big thanks for sitting on that fix and exposing peoples hardware
> to damage, that shows real professionalism.
Not good.
Tony
^ permalink raw reply
* Re: [PATCH 02/16] ARM: omap: fix oops in drivers/video/omap2/dss/dpi.c
From: Tony Lindgren @ 2012-02-08 18:36 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: linux-omap, Tomi Valkeinen, Florian Tobias Schandinat,
linux-fbdev
In-Reply-To: <E1RvAVQ-0006Gp-Is@rmk-PC.arm.linux.org.uk>
* Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 08:05]:
> When a PMIC is not found, this driver is unable to obtain its
> 'vdds_dsi_reg' regulator. Even through its initialization function
> fails, other code still calls its enable function, which fails to
> check whether it has this regulator before asking for it to be enabled.
>
> This fixes the oops, however a better fix would be to sort out the
> upper layers to prevent them calling into a module which failed to
> initialize.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tomi can look into fixing this properly for v3.4:
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* [PATCH 02/16] ARM: omap: fix oops in drivers/video/omap2/dss/dpi.c
From: Russell King - ARM Linux @ 2012-02-08 16:36 UTC (permalink / raw)
To: linux-omap; +Cc: Tomi Valkeinen, Florian Tobias Schandinat, linux-fbdev
In-Reply-To: <20120208163546.GA15849@n2100.arm.linux.org.uk>
When a PMIC is not found, this driver is unable to obtain its
'vdds_dsi_reg' regulator. Even through its initialization function
fails, other code still calls its enable function, which fails to
check whether it has this regulator before asking for it to be enabled.
This fixes the oops, however a better fix would be to sort out the
upper layers to prevent them calling into a module which failed to
initialize.
Unable to handle kernel NULL pointer dereference at virtual address 00000038
pgd = c0004000
[00000038] *pgd\0000000
Internal error: Oops: 5 [#1] PREEMPT
Modules linked in:
CPU: 0 Not tainted (3.3.0-rc2+ #228)
PC is at regulator_enable+0x10/0x70
LR is at omapdss_dpi_display_enable+0x54/0x15c
pc : [<c01b9a08>] lr : [<c01af994>] psr: 60000013
sp : c181fd90 ip : c181fdb0 fp : c181fdac
r10: c042eff0 r9 : 00000060 r8 : c044a164
r7 : c042c0e4 r6 : c042bd60 r5 : 00000000 r4 : c042bd60
r3 : c084de48 r2 : c181e000 r1 : c042bd60 r0 : 00000000
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 10c5387d Table: 80004019 DAC: 00000015
Process swapper (pid: 1, stack limit = 0xc181e2e8)
Stack: (0xc181fd90 to 0xc1820000)
fd80: c001754c c042bd60 00000000 c042bd60
fda0: c181fdcc c181fdb0 c01af994 c01b9a04 c0016104 c042bd60 c042bd60 c044a338
fdc0: c181fdec c181fdd0 c01b5ed0 c01af94c c042bd60 c042bd60 c1aa8000 c1aa8a0c
fde0: c181fe04 c181fdf0 c01b5f54 c01b5ea8 c02fc18c c042bd60 c181fe3c c181fe08
fe00: c01b2a18 c01b5f48 c01aed14 c02fc160 c01df8ec 00000002 c042bd60 00000003
fe20: c042bd60 c1aa8000 c1aa8a0c c042eff8 c181fe84 c181fe40 c01b3874 c01b29fc
fe40: c042eff8 00000000 c042f000 c0449db8 c044ed78 00000000 c181fe74 c042eff8
fe60: c042eff8 c0449db8 c0449db8 c044ed78 00000000 00000000 c181fe94 c181fe88
fe80: c01e452c c01b35e8 c181feb4 c181fe98 c01e2fdc c01e4518 c042eff8 c0449db8
fea0: c0449db8 c181fef0 c181fecc c181feb8 c01e3104 c01e2f48 c042eff8 c042f02c
fec0: c181feec c181fed0 c01e3190 c01e30c0 c01e311c 00000000 c01e311c c0449db8
fee0: c181ff14 c181fef0 c01e1998 c01e3128 c18330a8 c1892290 c04165e8 c0449db8
ff00: c0449db8 c1ab60c0 c181ff24 c181ff18 c01e2e28 c01e194c c181ff54 c181ff28
ff20: c01e2218 c01e2e14 c039afed c181ff38 c04165e8 c041660c c0449db8 00000013
ff40: 00000000 c03ffdb8 c181ff7c c181ff58 c01e384c c01e217c c181ff7c c04165e8
ff60: c041660c c003a37c 00000013 00000000 c181ff8c c181ff80 c01e488c c01e3790
ff80: c181ff9c c181ff90 c03ffdcc c01e484c c181ffdc c181ffa0 c0008798 c03ffdc4
ffa0: c181ffc4 c181ffb0 c0056440 c0187810 c003a37c c04165e8 c041660c c003a37c
ffc0: 00000013 00000000 00000000 00000000 c181fff4 c181ffe0 c03ea284 c0008708
ffe0: 00000000 c03ea208 00000000 c181fff8 c003a37c c03ea214 1073cec0 01f7ee08
Backtrace:
[<c01b99f8>] (regulator_enable+0x0/0x70) from [<c01af994>] (omapdss_dpi_display_enable+0x54/0x15c)
r6:c042bd60 r5:00000000 r4:c042bd60
[<c01af940>] (omapdss_dpi_display_enable+0x0/0x15c) from [<c01b5ed0>] (generic_dpi_panel_power_on+0x34/0x78)
r6:c044a338 r5:c042bd60 r4:c042bd60
[<c01b5e9c>] (generic_dpi_panel_power_on+0x0/0x78) from [<c01b5f54>] (generic_dpi_panel_enable+0x18/0x28)
r7:c1aa8a0c r6:c1aa8000 r5:c042bd60 r4:c042bd60
[<c01b5f3c>] (generic_dpi_panel_enable+0x0/0x28) from [<c01b2a18>] (omapfb_init_display+0x28/0x150)
r4:c042bd60
[<c01b29f0>] (omapfb_init_display+0x0/0x150) from [<c01b3874>] (omapfb_probe+0x298/0x318)
r8:c042eff8 r7:c1aa8a0c r6:c1aa8000 r5:c042bd60 r4:00000003
[<c01b35dc>] (omapfb_probe+0x0/0x318) from [<c01e452c>] (platform_drv_probe+0x20/0x24)
[<c01e450c>] (platform_drv_probe+0x0/0x24) from [<c01e2fdc>] (really_probe+0xa0/0x178)
[<c01e2f3c>] (really_probe+0x0/0x178) from [<c01e3104>] (driver_probe_device+0x50/0x68)
r7:c181fef0 r6:c0449db8 r5:c0449db8 r4:c042eff8
[<c01e30b4>] (driver_probe_device+0x0/0x68) from [<c01e3190>] (__driver_attach+0x74/0x98)
r5:c042f02c r4:c042eff8
[<c01e311c>] (__driver_attach+0x0/0x98) from [<c01e1998>] (bus_for_each_dev+0x58/0x98)
r6:c0449db8 r5:c01e311c r4:00000000
[<c01e1940>] (bus_for_each_dev+0x0/0x98) from [<c01e2e28>] (driver_attach+0x20/0x28)
r7:c1ab60c0 r6:c0449db8 r5:c0449db8 r4:c04165e8
[<c01e2e08>] (driver_attach+0x0/0x28) from [<c01e2218>] (bus_add_driver+0xa8/0x22c)
[<c01e2170>] (bus_add_driver+0x0/0x22c) from [<c01e384c>] (driver_register+0xc8/0x154)
[<c01e3784>] (driver_register+0x0/0x154) from [<c01e488c>] (platform_driver_register+0x4c/0x60)
r8:00000000 r7:00000013 r6:c003a37c r5:c041660c r4:c04165e8
[<c01e4840>] (platform_driver_register+0x0/0x60) from [<c03ffdcc>] (omapfb_init+0x14/0x34)
[<c03ffdb8>] (omapfb_init+0x0/0x34) from [<c0008798>] (do_one_initcall+0x9c/0x164)
[<c00086fc>] (do_one_initcall+0x0/0x164) from [<c03ea284>] (kernel_init+0x7c/0x120)
[<c03ea208>] (kernel_init+0x0/0x120) from [<c003a37c>] (do_exit+0x0/0x2d8)
r5:c03ea208 r4:00000000
Code: e1a0c00d e92dd870 e24cb004 e24dd004 (e5906038)
---[ end trace 9e2474c2e193b223 ]---
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
drivers/video/omap2/dss/dpi.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 395d658..faaf305 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -180,6 +180,11 @@ int omapdss_dpi_display_enable(struct omap_dss_device *dssdev)
{
int r;
+ if (cpu_is_omap34xx() && !dpi.vdds_dsi_reg) {
+ DSSERR("no VDSS_DSI regulator\n");
+ return -ENODEV;
+ }
+
if (dssdev->manager = NULL) {
DSSERR("failed to enable display: no manager\n");
return -ENODEV;
--
1.7.4.4
^ permalink raw reply related
* [PATCH 00/16] rmk's patch series for fixing OMAP
From: Russell King - ARM Linux @ 2012-02-08 16:35 UTC (permalink / raw)
To: linux-arm-kernel
This is my set of patches for fixing OMAP for v3.3.
This is the complete series of patches I'm currently applying to _my_
tree to get v3.3-rc2 into a usable and sane state.
I want to see most of the problems uncovered in this series fixed sooner
rather than later, and certainly not taking three plus weeks to get into
mainline like this rather serious looking commit did:
commit c49d005b6cc8491fad5b24f82805be2d6bcbd3dd
Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
Date: Tue Jan 17 11:09:57 2012 +0200
OMAPDSS: HDMI: PHY burnout fix
A hardware bug in the OMAP4 HDMI PHY causes physical damage to the board
if the HDMI PHY is kept powered on when the cable is not connected.
which now has me wondering if, by trying to boot v3.3-rc2 on this board
during the past week, I have a destroyed HDMI interface on it.
So, a big thanks for sitting on that fix and exposing peoples hardware
to damage, that shows real professionalism.
^ permalink raw reply
* RE: [RESENT][PATCH v2 0/2] fb: add early fb blank feature
From: Inki Dae @ 2012-02-07 5:53 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <003f01cc8280$7510c5c0$5f325140$%dae@samsung.com>
Hi, Florian and Andrew.
Like below email threads, I had posted this patch last year but there is no
any answer. as Florian mentioned, It seems like Richard does no longer
handle LCD/backlight stuff so Andrew, could you please look into this patch
set? And if there is no problem, please apply it to mainline.
Thanks,
Inki Dae.
> -----Original Message-----
> From: Florian Tobias Schandinat [mailto:FlorianSchandinat@gmx.de]
> Sent: Sunday, October 30, 2011 8:24 PM
> To: Andrew Morton
> Cc: Inki Dae; rpurdie@rpsys.net; linux-fbdev@vger.kernel.org;
> lars@metafoo.de; kyungmin.park@samsung.com
> Subject: Re: [RESENT][PATCH v2 0/2] fb: add early fb blank feature
>
> Hi Andrew,
>
> can you take care of this patch series?
> It seems like Richard does no longer handle LCD/backlight stuff (why is he
> listed as maintainer?) and I really cannot say whether the patch to the
> LCD code
> is correct and therefore I do not intend to carry such a patch without any
> Ack.
> You can add an "Acked-by: Florian Tobias Schandinat
> <FlorianSchandinat@gmx.de>"
> to the fb patch 2/2 (well actually I think the order should be swapped as
> 1 does
> not compile without 2) but I ask you to handle it as well as it is useless
> without the other patch.
>
>
> Thanks,
>
> Florian Tobias Schandinat
>
> On 10/04/2011 10:29 AM, Inki Dae wrote:
> > this patch adds early fb blank feature that a callback of lcd panel
> driver
> > is called prior to specific fb driver's one. in case of MIPI-DSI based
> video
> > mode LCD Panel, for lcd power off, the power off commands should be
> > transferred to lcd panel with display and mipi-dsi controller enabled
> > because the commands is set to lcd panel at vsync porch period. and in
> > opposite case, the callback of fb driver should be called prior to lcd
> panel
> > driver's one because of same issue. and also if fb_blank mode is changed
> to
> > FB_BLANK_POWERDOWN then display controller would be off(clock disable)
> but
> > lcd panel would be still on. at this time, you could see some issue like
> > sparkling on lcd panel because video clock to be delivered to ldi module
> of
> > lcd panel was disabled. this issue could occurs for all lcd panels.
> >
> > the callback order is as the following:
> >
> > at fb_blank function of fbmem.c
> > -> fb_notifier_call_chain(FB_EARLY_EVENT_BLANK)
> > -> lcd panel driver's early_set_power()
> > -> info->fbops->fb_blank()
> > -> spcefic fb driver's fb_blank()
> > -> fb_notifier_call_chain(FB_EVENT_BLANK)
> > -> lcd panel driver's set_power()
> > -> fb_notifier_call_chain(FB_R_EARLY_EVENT_BLANK) if
> > info->fops->fb_blank() was failed.
> >
> > fb_notifier_call_chain(FB_R_EARLY_EVENT_BLANK) would be called to revert
> the
> > effects of previous FB_EARLY_EVENT_BLANK call. and note that if
> > early_set_power() of lcd_ops is NULL then early fb blank callback would
> be
> > ignored.
> >
> > this patch is based on git repository below:
> > git://github.com/schandinat/linux-2.6.git
> > branch: fbdev-next
> > commit-id: 2b7a905dd0d24d14a1099653ba63b7113a82fc54
> >
> > Links to previous versions of the patchset:
> > v1: < http://lkml.indiana.edu/hypermail/linux/kernel/1109.1/00413.html >
> >
> > Changelog v2:
> > fb: add fb early blank event instead of early_blank_mode variable.
> > fb notifier can know whether early blank mode is support or not
> > checking if early_set_power callback is NULL or not.
> >
> > fb: add exception codes at fb_blank().
> > the effects of previous FB_EARLY_EVENT_BLANK call should be
> reverted
> > if info->fbops->fb_blank() was failed.
> >
> > fb: add code clean.
> >
> > Changelog RESEND:
> > fb: fixed condition.
> > this patch changes 'if (early_ret < 0)' to 'if (!early_ret)' of
> > fb_blank function.
> >
> > these patch series are as the following:
> > [RESEND][PATCH v2 0/2] fb: add early fb blank feature.
> > introduce new early fb blank feature.
> > [RESEND][PATCH v2 1/2] lcd: add callbacks for early fb event blank
> support.
> > [RESEND][PATCH v2 2/2] fb: add events for early fb event support.
> >
> > Signed-off-by: Inki Dae <inki.dae@samsung.com>
> > Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-fbdev"
> in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
^ permalink raw reply
* [GIT PULL] fbdev fixes for 3.3
From: Florian Tobias Schandinat @ 2012-02-07 0:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: LKML, linux-fbdev@vger.kernel.org
Hi Linus,
please pull the changes below.
The key has not been signed yet as I didn't have time to take care about it.
Thanks,
Florian Tobias Schandinat
The following changes since commit f787f32e67e00b072f46b2ae3c454d2c0a1fcdb7:
module_param: make bool parameters really bool (drivers/video/i810)
(2012-01-12 23:28:59 +0000)
are available in the git repository at:
git://github.com/schandinat/linux-2.6.git fbdev-fixes-for-3.3-1
for you to fetch changes up to 9f1065032ceb7e86c7c9f16bb86518857e88a172:
atmel_lcdfb: fix usage of CONTRAST_CTR in suspend/resume (2012-01-28 19:50:22
+0000)
----------------------------------------------------------------
fbdev fixes for 3.3
It includes:
- a compile fix for fsl-diu-fb
- a fix for a suspend/resume issue in atmel_lcdfb
- a fix for a suspend/resume issue in OMAP
- a workaround for a hardware bug to avoid physical damage in OMAP
- a really trivial dead code removal in intelfb
----------------------------------------------------------------
Dan Carpenter (1):
intelfb: remove some dead code
Florian Tobias Schandinat (1):
Merge branch 'for-3.3-rc' of git://gitorious.org/linux-omap-dss2/linux
into fbdev-for-linus
Hubert Feurstein (1):
atmel_lcdfb: fix usage of CONTRAST_CTR in suspend/resume
Michael Neuling (1):
drivers/video: compile fixes for fsl-diu-fb.c
Tomi Valkeinen (7):
OMAPDSS: use sync versions of pm_runtime_put
OMAP: 4430SDP/Panda: use gpio_free_array to free HDMI gpios
OMAP: 4430SDP/Panda: rename HPD GPIO to CT_CP_HPD
OMAPDSS: remove wrong HDMI HPD muxing
OMAP: 4430SDP/Panda: setup HDMI GPIO muxes
OMAP: 4430SDP/Panda: add HDMI HPD gpio
OMAPDSS: HDMI: PHY burnout fix
arch/arm/mach-omap2/board-4430sdp.c | 18 ++++++--
arch/arm/mach-omap2/board-omap4panda.c | 18 ++++++--
arch/arm/mach-omap2/display.c | 4 --
drivers/video/atmel_lcdfb.c | 2 +-
drivers/video/fsl-diu-fb.c | 4 +-
drivers/video/intelfb/intelfbdrv.c | 1 -
drivers/video/omap2/dss/dispc.c | 2 +-
drivers/video/omap2/dss/dsi.c | 2 +-
drivers/video/omap2/dss/dss.c | 2 +-
drivers/video/omap2/dss/hdmi.c | 5 ++-
drivers/video/omap2/dss/rfbi.c | 2 +-
drivers/video/omap2/dss/ti_hdmi.h | 4 ++
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 68 +++++++++++++++++++++++++++--
drivers/video/omap2/dss/venc.c | 2 +-
include/video/omapdss.h | 5 ++
15 files changed, 113 insertions(+), 26 deletions(-)
^ permalink raw reply
* [PATCH] OMAP: DSS2: TPO-TD03MTEA1: update default gamma
From: Grazvydas Ignotas @ 2012-02-07 0:13 UTC (permalink / raw)
To: linux-fbdev; +Cc: Tomi Valkeinen, linux-omap, Grazvydas Ignotas
In-Reply-To: <1328573630-7348-1-git-send-email-notasas@gmail.com>
Over time better gamma has been determined and tuned with some
equipment so update the defaults. From subjective point of view
dark shades should be better visible.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
---
.../video/omap2/displays/panel-tpo-td043mtea1.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
index 741e9d7..d63e5e5 100644
--- a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
+++ b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
@@ -47,7 +47,7 @@
TPO_R03_EN_PRE_CHARGE | TPO_R03_SOFTWARE_CTL)
static const u16 tpo_td043_def_gamma[12] = {
- 106, 200, 289, 375, 460, 543, 625, 705, 785, 864, 942, 1020
+ 105, 315, 381, 431, 490, 537, 579, 686, 780, 837, 880, 1023
};
struct tpo_td043_device {
--
1.7.0.4
^ permalink raw reply related
* [PATCH] OMAP: DSS2: TPO-TD03MTEA1: fix suspend hang
From: Grazvydas Ignotas @ 2012-02-07 0:13 UTC (permalink / raw)
To: linux-fbdev; +Cc: Tomi Valkeinen, linux-omap, Grazvydas Ignotas
During system suspend, at the time DSS is being suspended, SPI is
already suspended and it's clocks are cut. Because of this trying to
communicate with the LCD controller results in a deadlock.
To fix this, split out LCD programming parts of display enable/disable
functions and perform them from SPI PM callbacks instead when system is
being suspended. If the display is just being enabled/disabled, do it
from DSS callbacks as before.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
---
rather invasive so best for upcoming merge window I guess..
.../video/omap2/displays/panel-tpo-td043mtea1.c | 151 ++++++++++++++------
1 files changed, 108 insertions(+), 43 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
index e6649aa..741e9d7 100644
--- a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
+++ b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
@@ -53,10 +53,14 @@ static const u16 tpo_td043_def_gamma[12] = {
struct tpo_td043_device {
struct spi_device *spi;
struct regulator *vcc_reg;
+ int nreset_gpio;
u16 gamma[12];
u32 mode;
u32 hmirror:1;
u32 vmirror:1;
+ u32 powered_on:1;
+ u32 spi_suspended:1;
+ u32 power_on_resume:1;
};
static int tpo_td043_write(struct spi_device *spi, u8 addr, u8 data)
@@ -265,28 +269,16 @@ static const struct omap_video_timings tpo_td043_timings = {
.vbp = 34,
};
-static int tpo_td043_power_on(struct omap_dss_device *dssdev)
+static int tpo_td043_power_on(struct tpo_td043_device *tpo_td043)
{
- struct tpo_td043_device *tpo_td043 = dev_get_drvdata(&dssdev->dev);
- int nreset_gpio = dssdev->reset_gpio;
- int r;
+ int nreset_gpio = tpo_td043->nreset_gpio;
- if (dssdev->state = OMAP_DSS_DISPLAY_ACTIVE)
+ if (tpo_td043->powered_on)
return 0;
- r = omapdss_dpi_display_enable(dssdev);
- if (r)
- goto err0;
-
- if (dssdev->platform_enable) {
- r = dssdev->platform_enable(dssdev);
- if (r)
- goto err1;
- }
-
regulator_enable(tpo_td043->vcc_reg);
- /* wait for power up */
+ /* wait for regulator to stabilize */
msleep(160);
if (gpio_is_valid(nreset_gpio))
@@ -301,19 +293,15 @@ static int tpo_td043_power_on(struct omap_dss_device *dssdev)
tpo_td043->vmirror);
tpo_td043_write_gamma(tpo_td043->spi, tpo_td043->gamma);
+ tpo_td043->powered_on = 1;
return 0;
-err1:
- omapdss_dpi_display_disable(dssdev);
-err0:
- return r;
}
-static void tpo_td043_power_off(struct omap_dss_device *dssdev)
+static void tpo_td043_power_off(struct tpo_td043_device *tpo_td043)
{
- struct tpo_td043_device *tpo_td043 = dev_get_drvdata(&dssdev->dev);
- int nreset_gpio = dssdev->reset_gpio;
+ int nreset_gpio = tpo_td043->nreset_gpio;
- if (dssdev->state != OMAP_DSS_DISPLAY_ACTIVE)
+ if (!tpo_td043->powered_on)
return;
tpo_td043_write(tpo_td043->spi, 3,
@@ -329,54 +317,94 @@ static void tpo_td043_power_off(struct omap_dss_device *dssdev)
regulator_disable(tpo_td043->vcc_reg);
+ tpo_td043->powered_on = 0;
+}
+
+static int tpo_td043_enable_dss(struct omap_dss_device *dssdev)
+{
+ struct tpo_td043_device *tpo_td043 = dev_get_drvdata(&dssdev->dev);
+ int r;
+
+ if (dssdev->state = OMAP_DSS_DISPLAY_ACTIVE)
+ return 0;
+
+ r = omapdss_dpi_display_enable(dssdev);
+ if (r)
+ goto err0;
+
+ if (dssdev->platform_enable) {
+ r = dssdev->platform_enable(dssdev);
+ if (r)
+ goto err1;
+ }
+
+ /*
+ * If we are resuming from system suspend, SPI clocks might not be
+ * enabled yet, so we'll program the LCD from SPI PM resume callback.
+ */
+ if (!tpo_td043->spi_suspended) {
+ r = tpo_td043_power_on(tpo_td043);
+ if (r)
+ goto err1;
+ }
+
+ dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
+
+ return 0;
+err1:
+ omapdss_dpi_display_disable(dssdev);
+err0:
+ return r;
+}
+
+static void tpo_td043_disable_dss(struct omap_dss_device *dssdev)
+{
+ struct tpo_td043_device *tpo_td043 = dev_get_drvdata(&dssdev->dev);
+
+ if (dssdev->state != OMAP_DSS_DISPLAY_ACTIVE)
+ return;
+
if (dssdev->platform_disable)
dssdev->platform_disable(dssdev);
omapdss_dpi_display_disable(dssdev);
+
+ if (!tpo_td043->spi_suspended)
+ tpo_td043_power_off(tpo_td043);
}
static int tpo_td043_enable(struct omap_dss_device *dssdev)
{
- int ret;
-
dev_dbg(&dssdev->dev, "enable\n");
- ret = tpo_td043_power_on(dssdev);
- if (ret)
- return ret;
-
- dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
-
- return 0;
+ return tpo_td043_enable_dss(dssdev);
}
static void tpo_td043_disable(struct omap_dss_device *dssdev)
{
dev_dbg(&dssdev->dev, "disable\n");
- tpo_td043_power_off(dssdev);
+ tpo_td043_disable_dss(dssdev);
dssdev->state = OMAP_DSS_DISPLAY_DISABLED;
}
static int tpo_td043_suspend(struct omap_dss_device *dssdev)
{
- tpo_td043_power_off(dssdev);
+ dev_dbg(&dssdev->dev, "suspend\n");
+
+ tpo_td043_disable_dss(dssdev);
+
dssdev->state = OMAP_DSS_DISPLAY_SUSPENDED;
+
return 0;
}
static int tpo_td043_resume(struct omap_dss_device *dssdev)
{
- int r = 0;
-
- r = tpo_td043_power_on(dssdev);
- if (r)
- return r;
-
- dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
+ dev_dbg(&dssdev->dev, "resume\n");
- return 0;
+ return tpo_td043_enable_dss(dssdev);
}
static int tpo_td043_probe(struct omap_dss_device *dssdev)
@@ -491,6 +519,7 @@ static int tpo_td043_spi_probe(struct spi_device *spi)
return -ENOMEM;
tpo_td043->spi = spi;
+ tpo_td043->nreset_gpio = dssdev->reset_gpio;
dev_set_drvdata(&spi->dev, tpo_td043);
dev_set_drvdata(&dssdev->dev, tpo_td043);
@@ -509,10 +538,46 @@ static int __devexit tpo_td043_spi_remove(struct spi_device *spi)
return 0;
}
+#ifdef CONFIG_PM_SLEEP
+static int tpo_td043_spi_suspend(struct device *dev)
+{
+ struct tpo_td043_device *tpo_td043 = dev_get_drvdata(dev);
+
+ dev_dbg(dev, "tpo_td043_spi_suspend, tpo %p\n", tpo_td043);
+
+ tpo_td043->power_on_resume = tpo_td043->powered_on;
+ tpo_td043_power_off(tpo_td043);
+ tpo_td043->spi_suspended = 1;
+
+ return 0;
+}
+
+static int tpo_td043_spi_resume(struct device *dev)
+{
+ struct tpo_td043_device *tpo_td043 = dev_get_drvdata(dev);
+ int ret;
+
+ dev_dbg(dev, "tpo_td043_spi_resume\n");
+
+ if (tpo_td043->power_on_resume) {
+ ret = tpo_td043_power_on(tpo_td043);
+ if (ret)
+ return ret;
+ }
+ tpo_td043->spi_suspended = 0;
+
+ return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(tpo_td043_spi_pm,
+ tpo_td043_spi_suspend, tpo_td043_spi_resume);
+
static struct spi_driver tpo_td043_spi_driver = {
.driver = {
.name = "tpo_td043mtea1_panel_spi",
.owner = THIS_MODULE,
+ .pm = &tpo_td043_spi_pm,
},
.probe = tpo_td043_spi_probe,
.remove = __devexit_p(tpo_td043_spi_remove),
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 1/2] OMAPDSS: Features: Maintain dss_feats as a list
From: Archit Taneja @ 2012-02-06 11:51 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Archit Taneja, linux-omap, linux-fbdev
In-Reply-To: <1328527692.1997.2.camel@lappy>
On Monday 06 February 2012 04:58 PM, Tomi Valkeinen wrote:
> On Mon, 2012-02-06 at 16:54 +0530, Archit Taneja wrote:
>> On Monday 06 February 2012 04:12 PM, Tomi Valkeinen wrote:
>>> Hi,
>>>
>>> On Mon, 2012-01-30 at 10:52 +0530, Archit Taneja wrote:
>>>> The number of dss_feat_id members has increased to a large value, the current
>>>> way of assigning a subset of these features (for a particular OMAP) as a mask
>>>> is no longer feasible.
>>>>
>>>> Maintain the subset of features supported as lists. Make the function
>>>> dss_has_feature() traverse through this list.
>>>
>>> I think this makes the code easier to maintain, so in that sense it is
>>> good. But I do hesitate a bit, I think many features are checked in
>>> often used code paths (the configuration done on each frame when
>>> swapping/panning), and bit compare versus finding an item in a list
>>> could have performance impact.
>>>
>>> Then again, I'm purely guessing here, as it could well be that compared
>>> to the other code, checking the features is insignificant. Thus, I'm
>>> fine with this patch, and we can optimize it later if need be.
>>>
>>> However, I'm anyway giving a few ideas how this could also be handled:
>>>
>>> - 64 bit mask. Would be simple, but we'd still have a hard limit there.
>>>
>>> - Variable length bitmask, i.e. an int or byte array from which a
>>> particular bit is checked. There could be a ready made datatype for this
>>> in the kernel.
>>>
>>
>> There seems to be a bitmask library:
>>
>> tools/power/cpupower/utils/helpers/bitmask.c
>>
>> I don't know how easy it would be to access this though.
>>
>>> - Lists like in this patch, but in sorted order. Then, if we're looking
>>> for a feat which has, say, number 4 assigned to it, we can stop
>>> iterating the list when we hit a feat> 4 in the list. Quite simple
>>> optimization, but needs extra maintenance to keep the feat lists sorted.
>>
>> This sounds fine. It shouldn't be too much of an effort to maintain
>> sorted lists. We'll just need to ensure that a new feature added has the
>> largest integer value, and is always added at the end of the list(s).
>
> Not necessarily. As we always search the list from index 0 forward, the
> most often needed features could be in the beginning of the list so they
> are found faster. At least some features are clearly needed only in some
> enable/disable paths or similar, and they could clearly be low priority.
Right, it would be harder to maintain sorted lists in this case, and it
wouldn't be always straight forward to decide which feature has more
priority over other :)
Archit
>
> Tomi
>
^ permalink raw reply
* Re: [PATCH 1/2] OMAPDSS: Features: Maintain dss_feats as a list
From: Archit Taneja @ 2012-02-06 11:36 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Archit Taneja, linux-omap, linux-fbdev
In-Reply-To: <1328524943.1898.38.camel@deskari>
On Monday 06 February 2012 04:12 PM, Tomi Valkeinen wrote:
> Hi,
>
> On Mon, 2012-01-30 at 10:52 +0530, Archit Taneja wrote:
>> The number of dss_feat_id members has increased to a large value, the current
>> way of assigning a subset of these features (for a particular OMAP) as a mask
>> is no longer feasible.
>>
>> Maintain the subset of features supported as lists. Make the function
>> dss_has_feature() traverse through this list.
>
> I think this makes the code easier to maintain, so in that sense it is
> good. But I do hesitate a bit, I think many features are checked in
> often used code paths (the configuration done on each frame when
> swapping/panning), and bit compare versus finding an item in a list
> could have performance impact.
>
> Then again, I'm purely guessing here, as it could well be that compared
> to the other code, checking the features is insignificant. Thus, I'm
> fine with this patch, and we can optimize it later if need be.
>
> However, I'm anyway giving a few ideas how this could also be handled:
>
> - 64 bit mask. Would be simple, but we'd still have a hard limit there.
>
> - Variable length bitmask, i.e. an int or byte array from which a
> particular bit is checked. There could be a ready made datatype for this
> in the kernel.
>
There seems to be a bitmask library:
tools/power/cpupower/utils/helpers/bitmask.c
I don't know how easy it would be to access this though.
> - Lists like in this patch, but in sorted order. Then, if we're looking
> for a feat which has, say, number 4 assigned to it, we can stop
> iterating the list when we hit a feat> 4 in the list. Quite simple
> optimization, but needs extra maintenance to keep the feat lists sorted.
This sounds fine. It shouldn't be too much of an effort to maintain
sorted lists. We'll just need to ensure that a new feature added has the
largest integer value, and is always added at the end of the list(s).
Archit
>
> Tomi
>
^ permalink raw reply
* Re: [PATCH 1/2] OMAPDSS: Features: Maintain dss_feats as a list
From: Tomi Valkeinen @ 2012-02-06 11:28 UTC (permalink / raw)
To: Archit Taneja; +Cc: Archit Taneja, linux-omap, linux-fbdev
In-Reply-To: <4F2FB86D.2090205@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2419 bytes --]
On Mon, 2012-02-06 at 16:54 +0530, Archit Taneja wrote:
> On Monday 06 February 2012 04:12 PM, Tomi Valkeinen wrote:
> > Hi,
> >
> > On Mon, 2012-01-30 at 10:52 +0530, Archit Taneja wrote:
> >> The number of dss_feat_id members has increased to a large value, the current
> >> way of assigning a subset of these features (for a particular OMAP) as a mask
> >> is no longer feasible.
> >>
> >> Maintain the subset of features supported as lists. Make the function
> >> dss_has_feature() traverse through this list.
> >
> > I think this makes the code easier to maintain, so in that sense it is
> > good. But I do hesitate a bit, I think many features are checked in
> > often used code paths (the configuration done on each frame when
> > swapping/panning), and bit compare versus finding an item in a list
> > could have performance impact.
> >
> > Then again, I'm purely guessing here, as it could well be that compared
> > to the other code, checking the features is insignificant. Thus, I'm
> > fine with this patch, and we can optimize it later if need be.
> >
> > However, I'm anyway giving a few ideas how this could also be handled:
> >
> > - 64 bit mask. Would be simple, but we'd still have a hard limit there.
> >
> > - Variable length bitmask, i.e. an int or byte array from which a
> > particular bit is checked. There could be a ready made datatype for this
> > in the kernel.
> >
>
> There seems to be a bitmask library:
>
> tools/power/cpupower/utils/helpers/bitmask.c
>
> I don't know how easy it would be to access this though.
>
> > - Lists like in this patch, but in sorted order. Then, if we're looking
> > for a feat which has, say, number 4 assigned to it, we can stop
> > iterating the list when we hit a feat> 4 in the list. Quite simple
> > optimization, but needs extra maintenance to keep the feat lists sorted.
>
> This sounds fine. It shouldn't be too much of an effort to maintain
> sorted lists. We'll just need to ensure that a new feature added has the
> largest integer value, and is always added at the end of the list(s).
Not necessarily. As we always search the list from index 0 forward, the
most often needed features could be in the beginning of the list so they
are found faster. At least some features are clearly needed only in some
enable/disable paths or similar, and they could clearly be low priority.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox