Re: [PATCH v5 08/17] OMAP2,3: DSS2: Build omap_device for each DSS HWIP
Hi Kevin,
On Sat, Jan 8, 2011 at 5:04 AM, Kevin Hilman khil...@ti.com wrote:
Sumit Semwal sumit.sem...@ti.com writes:
From: Senthilvadivu Guruswamy svad...@ti.com
Looks up the hwmod database for each of the given DSS HW IP and builds
omap_device which inturn does the platform device register for each of DSS
HW IP
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
---
arch/arm/mach-omap2/display.c | 44
+
arch/arm/plat-omap/include/plat/display.h | 6
2 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 26d3feb..276b800 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -36,10 +36,54 @@ static struct platform_device omap_display_device = {
},
};
+static struct omap_device_pm_latency omap_dss_latency[] = {
+ [0] = {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
Without any latency numbers or AUTO_ADJUST you're going to have noisy
output from omap_device.
+ },
+};
+
int __init omap_display_init(struct omap_dss_board_info
*board_data)
{
int r = 0;
+ struct omap_hwmod *oh;
+ struct omap_device *od;
+ int i;
+ struct omap_display_platform_data pdata;
+ char *oh_name[] = { dss_dss, /* omap2,3 */
+ dss_dispc, /* omap2,3 */
+ dss_rfbi, /* omap2,3 */
+ dss_venc, /* omap2,3 */
+ dss_dsi1 }; /* omap3 */
Why all the extra whitespace before the strings?
+ char *dev_name[] = { omap_dss, omap_dispc, omap_rfbi,
+ omap_venc, omap_dsi1 };
ditto
+ int oh_count;
+
+ if (cpu_is_omap24xx()) {
+ oh_count = ARRAY_SIZE(oh_name) - 1;
+ /* last hwmod dev in oh_name is not available for omap2 */
+ } else {
+ oh_count = ARRAY_SIZE(oh_name);
+ }
braces not needed
+ pdata.board_data = board_data;
extra whitespace not necessary
+ pdata.board_data-get_last_off_on_transaction_id = NULL;
instead, you should probably zero all of pdata before using it since it
is on the stack
+ for (i = 0; i oh_count; i++) {
+ oh = omap_hwmod_lookup(oh_name[i]);
+ if (!oh) {
+ pr_err(Could not look up %s\n, oh_name[i]);
+ return r;
+ }
+ od = omap_device_build(dev_name[i], -1, oh, pdata,
+ sizeof(struct omap_display_platform_data),
+ omap_dss_latency,
+ ARRAY_SIZE(omap_dss_latency), 0);
+
+ WARN((IS_ERR(od)), Could not build omap_device for %s\n,
+ oh_name[i]);
yet code below will still try and register it?
+ }
omap_display_device.dev.platform_data = board_data;
r = platform_device_register(omap_display_device);
diff --git a/arch/arm/plat-omap/include/plat/display.h
b/arch/arm/plat-omap/include/plat/display.h
index 871bbae..23afd6d 100644
--- a/arch/arm/plat-omap/include/plat/display.h
+++ b/arch/arm/plat-omap/include/plat/display.h
@@ -26,6 +26,7 @@
#include linux/platform_device.h
#include asm/atomic.h
+
stray whitespace change
#define DISPC_IRQ_FRAMEDONE (1 0)
#define DISPC_IRQ_VSYNC (1 1)
#define DISPC_IRQ_EVSYNC_EVEN (1 2)
@@ -224,6 +225,11 @@ struct omap_dss_board_info {
/* Init with the board info */
extern int omap_display_init(struct omap_dss_board_info *board_data);
+struct omap_display_platform_data {
+ struct omap_dss_board_info *board_data;
+ /* TODO: Additional members to be added when PM is considered */
+};
+
struct omap_video_timings {
/* Unit: pixels */
u16 x_res;
Thanks for all your comments; will incorporate in the upcoming version.
Best regards,
~Sumit.
Kevin
--
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 09/17] OMAP2,3: DSS2: DSS: create platform_driver, move init,exit to driver
Hi Kevin,
On Sat, Jan 8, 2011 at 5:13 AM, Kevin Hilman khil...@ti.com wrote:
Sumit Semwal sumit.sem...@ti.com writes:
From: Senthilvadivu Guruswamy svad...@ti.com
Hwmod adaptation design requires each of the DSS HW IP to be a platform
driver.
So a platform_driver of DSS is created and init exit methods are moved from
core.c
to its driver probe,remove. pdev member has to be maintained by its own
drivers.
DSS platform driver is registered from inside omap_dss_probe, in the order
desired.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
---
drivers/video/omap2/dss/core.c | 21 +++
drivers/video/omap2/dss/dss.c | 55
++-
drivers/video/omap2/dss/dss.h | 4 +-
3 files changed, 65 insertions(+), 15 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 48d20d8..faca859 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -497,9 +497,9 @@ static inline void dss_uninitialize_debugfs(void)
static int omap_dss_probe(struct platform_device *pdev)
{
struct omap_dss_board_info *pdata = pdev-dev.platform_data;
- int skip_init = 0;
int r;
int i;
+ int skip_init = 0;
looks like unnessary move.
maybe you meant to remove this var since its usage was removed from this
function?
core.pdev = pdev;
@@ -517,15 +517,9 @@ static int omap_dss_probe(struct platform_device *pdev)
core.ctx_id = dss_get_ctx_id();
DSSDBG(initial ctx id %u\n, core.ctx_id);
-#ifdef CONFIG_FB_OMAP_BOOTLOADER_INIT
- /* DISPC_CONTROL */
- if (omap_readl(0x48050440) 1) /* LCD enabled? */
- skip_init = 1;
-#endif
-
- r = dss_init(skip_init);
+ r = dss_init_platform_driver();
if (r) {
- DSSERR(Failed to initialize DSS\n);
+ DSSERR(Failed to initialize DSS platform driver\n);
goto err_dss;
}
@@ -553,6 +547,11 @@ static int omap_dss_probe(struct platform_device *pdev)
goto err_venc;
}
+#ifdef CONFIG_FB_OMAP_BOOTLOADER_INIT
+ /* DISPC_CONTROL */
+ if (omap_readl(0x48050440) 1) /* LCD enabled? */
+ skip_init = 1;
+#endif
nope, you just moved it here.
But it's also duplicated in dsshw_probe below. Is that needed?
Yes; these two are needed as both dss_init() (which is replaced with
dss_init_platform_driver() in this patch) and also by sdi_init().
sdi_init() is a software init, so it will not be moved to a
platform_driver. That's why we need the #ifdef.. #endif in both
dss_probe() and dsshw_probe().
if (cpu_is_omap34xx()) {
r = sdi_init(skip_init);
if (r) {
@@ -610,7 +609,7 @@ err_dispc:
err_dpi:
rfbi_exit();
err_rfbi:
- dss_exit();
+ dss_deinit_platform_driver();
s/deinit/uninit/ or uninitial
Sure, will change.
err_dss:
dss_clk_disable_all_no_ctx();
dss_put_clocks();
@@ -636,7 +635,7 @@ static int omap_dss_remove(struct platform_device *pdev)
sdi_exit();
}
- dss_exit();
+ dss_deinit_platform_driver();
/* these should be removed at some point */
c = core.dss_ick-usecount;
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 77c3621..ebb294a 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -59,6 +59,7 @@ struct dss_reg {
dss_write_reg(idx, FLD_MOD(dss_read_reg(idx), val, start, end))
static struct {
+ struct platform_device *pdev;
void __iomem *base;
struct clk *dpll4_m4_ck;
@@ -549,7 +550,7 @@ void dss_set_dac_pwrdn_bgz(bool enable)
REG_FLD_MOD(DSS_CONTROL, enable, 5, 5); /* DAC Power-Down Control */
}
-int dss_init(bool skip_init)
+static int dss_init(bool skip_init)
{
int r;
u32 rev;
@@ -629,7 +630,7 @@ fail0:
return r;
}
-void dss_exit(void)
+static void dss_exit(void)
{
if (cpu_is_omap34xx())
clk_put(dss.dpll4_m4_ck);
@@ -639,3 +640,53 @@ void dss_exit(void)
iounmap(dss.base);
}
+/* DSS HW IP initialisation */
+static int omap_dsshw_probe(struct platform_device *pdev)
+{
+ int r;
+ int skip_init = 0;
+
+ dss.pdev = pdev;
+
+#ifdef CONFIG_FB_OMAP_BOOTLOADER_INIT
+ /* DISPC_CONTROL */
+ if (omap_readl(0x48050440) 1) /* LCD enabled? */
+ skip_init = 1;
+#endif
+
+ r = dss_init(skip_init);
+ if (r) {
+ DSSERR(Failed to initialize DSS\n);
+ goto err_dss;
+ }
+
+err_dss:
+
+ return r;
+}
+
+static int omap_dsshw_remove(struct platform_device *pdev)
+{
+ dss_exit();
+
+ return 0;
+}
+
+static struct platform_driver omap_dsshw_driver = {
+ .probe = omap_dsshw_probe,
+ .remove = omap_dsshw_remove,
+
Re: [PATCH 0/3] OMAP4: DSS OMAP4 hwmod support
Hi Kevin, On Sat, Jan 8, 2011 at 4:32 AM, Kevin Hilman khil...@ti.com wrote: Sumit Semwal sumit.sem...@ti.com writes: This patch series enables support for OMAP4 DSS, and adds hwmod support for dss, dispc, dsi1, dsi2, hdmi, rfbi and venc hwmods. This series is confusing as the 3 patches here do not do all the things described here. It also doesn't apply to the master branch (e.g. PATCH 3/3 modifies display.c, which doesn't exist until your other series.) First up, apologies for submitting these patches while the dependent patch series is still under discussion - I guess I should've waited till the hwmod patch series is accepted, but I thought mentioning the dependency might be sufficient. will take care in future. Though I don't quite understand why you think that the 3 patches don't do all that is described. The first patch enables building DSS for OMAP4 by updating the Kconfig accordingly. The second patch enables hwmod support for all the dss IP hwmod devices, and the third one enhances the hwmod lookup to lookup OMAP4 devices as well. If you could tell me what is missing or extra, I would correct that and send an updated version. Thanks, and best regards, ~Sumit. Please take care when writing these cover letters to be sure they are accurate, otherwise reviewers/maintainers can't help but be confused about what is going on. Kevin In OMAP4 there are severals IPs that can be reached by differents interconnect paths depending of the access initiator (MPU vs. SDMA). In the case of the DSS, both L3 direct path and L4 CFG path can be used to access all the DSS IPs. dss is also considered as an IP as dispc, rfbi, and named as dss_dss. TODO: This patch doesn't handle the opt clocks via hwmod - there will be a separate patch series which will take opt clock roles from hwmod, populate them in the device structure, so that the driver can ask for relevant opt-clocks. Also TBD is the migration to pm_runtime APIs, which need to be adapted a little for handling DSS-family of clocks completely. Patch Base: === url = git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git branch master Commit id: fa3b4e23ec20cfc944db7cc2b30b0d82c20e4472 Description: cbus: Fix retu_rtc_do_reset + hwmod patches under discussion: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg41534.html + patch series: OMAP2PLUS: DSS: Generalize clock names Benoit Cousson (1): OMAP4: hwmod data: add DSS DISPC DSI1,2 RFBI HDMI VENC Mayuresh Janorkar (1): OMAP2PLUS: DSS2: Add OMAP4 support Sumit Semwal (1): OMAP4: DSS2: Add hwmod device names for OMAP4. arch/arm/mach-omap2/display.c | 23 +- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 588 drivers/video/omap2/dss/Kconfig | 6 +- drivers/video/omap2/omapfb/Kconfig | 6 +- 4 files changed, 609 insertions(+), 14 deletions(-) -- 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: Issues with ADATA SD cards on OMAP?
FWIW, I am seeing this same behavior with a brand new SanDisk 4GB Class 4 microSD card. Steve On Sat, Jan 8, 2011 at 10:04 PM, Steve Sakoman sako...@gmail.com wrote: I've recently been testing memory card performance to identify the best performing brands/models. As expected, I found a huge difference in performance between brands. What I didn't expect to find, however, was a brand (ADATA) that doesn't seem to play well with the 2.6.36 kernel on OMAP3 hardware. I'm wondering if this failure might be exposing an issue in the OMAP mmc driver/hw setup. I tested both 4GB and 8GB versions of the ADATA Class 6 cards. I was not able to boot successfully from either card on both Overo and Beagle hardware (both 35xx and 37xx versions were tested). The error was the same in all cases: x-load, u-boot, and the kernel were all loaded successfully from SD, but the kernel was not able to mount the rootfs: Waiting for root device /dev/mmcblk0p2... mmc0: host does not support reading read-only switch. assuming write-enable. mmc0: new high speed SDHC card at address 0260 mmcblk0: mmc0:0260 SD 3.75 GiB mmcblk0: p1 p2 EXT3-fs: barriers not enabled kjournald starting. Commit interval 5 seconds EXT3-fs (mmcblk0p2): using internal journal EXT3-fs (mmcblk0p2): mounted filesystem with writeback data mode VFS: Mounted root (ext3 filesystem) on device 179:2. devtmpfs: mounted Freeing init memory: 168K INIT: version 2.86 booting Please wait: booting... Starting udev Remounting root file system... mmcblk0: error -110 sending read/write command, response 0x900, card status 0xe00 mmcblk0: error -110 transferring data, sector 3556505, nr 8, card status 0xc00 end_request: I/O error, dev mmcblk0, sector 3556512 Buffer I/O error on device mmcblk0p2, logical block 426490 lost page write due to I/O error on mmcblk0p2 mmcblk0: error -110 sending read/write command, response 0x900, card status 0xe00 mmcblk0: error -110 transferring data, sector 4076825, nr 8, card status 0xc00 end_request: I/O error, dev mmcblk0, sector 4076832 Buffer I/O error on device mmcblk0p2, logical block 491530 lost page write due to I/O error on mmcblk0p2 mmcblk0: error -110 sending read/write command, response 0x900, card status 0xe00 mmcblk0: error -110 transferring data, sector 4126233, nr 8, card status 0xc00 end_request: I/O error, dev mmcblk0, sector 4126234 Buffer I/O error on device mmcblk0p2, logical block 497706 lost page write due to I/O error on mmcblk0p2 And so on, with many more mmc errors. If I reset and try again, things go wrong even sooner: Waiting for root device /dev/mmcblk0p2... mmc0: host does not support reading read-only switch. assuming write-enable. mmc0: new high speed SDHC card at address 0260 mmcblk0: mmc0:0260 SD 3.75 GiB mmcblk0: p1 p2 EXT3-fs: barriers not enabled mmcblk0: error -110 sending read/write command, response 0x900, card status 0xe00 mmcblk0: error -110 transferring data, sector 147545, nr 8, card status 0xc00 end_request: I/O error, dev mmcblk0, sector 147552 Buffer I/O error on device mmcblk0p2, logical block 370 lost page write due to I/O error on mmcblk0p2 The ADATA cards seem to work with no issues on my desktop system. Has anyone else run into this issue? Any theories on where to start looking? FWIW, there is this thread on the beagleboard list discussing issues with mmc writes: http://groups.google.com/group/beagleboard/browse_thread/thread/0083724ff7e54c58/f55578bb1c1379db#f55578bb1c1379db In this thread Gerald Coley speculates that the driver may be setting the mmc1 voltage to 3.0V rather than 3.15V. Regards, Steve PS: For those who might be interested in the microSD card performance tests: http://www.sakoman.com/OMAP/microsd-card-perfomance-test-results.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: Issues with ADATA SD cards on OMAP?
Hi Steve, On Jan 9, 2011, at 9:00 PM, Steve Sakoman wrote: mmcblk0: error -110 sending read/write command, response 0x900, card status 0xe00 Error -110 is ETIMEOUT. The card might be getting detected but not powering up, perhaps? something to do with voltage regulator setup or probably a bad mmc hardware port? I'm using a 2GB class 4 SanDisk microSD card with a custom beagle board, and tried it with android-2.6.32 kernel as well as mainline 2.6.37-rc7 kernel, it worked fine. 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
Re: Issues with ADATA SD cards on OMAP?
On Sun, Jan 9, 2011 at 9:07 AM, Elvis Dowson elvis.dow...@mac.com wrote: Hi Steve, On Jan 9, 2011, at 9:00 PM, Steve Sakoman wrote: mmcblk0: error -110 sending read/write command, response 0x900, card status 0xe00 Error -110 is ETIMEOUT. The card might be getting detected but not powering up, perhaps? something to do with voltage regulator setup or probably a bad mmc hardware port? Not likely to be bad hardware since it fails the same way on multiple Overo and Beagle boards. And not likely to be a bad SD card, since the cards work perfectly on my desktop and laptop. I suspect something marginal in the mmc interface hw/config. If you look at the schematics for most boards the mmc card is directly connected to the OMAP for signal lines, and the twl4030 for power. As such, I'm not surprised that these cards fail with every OMAP3 board I've tried. I'm using a 2GB class 4 SanDisk microSD card with a custom beagle board, and tried it with android-2.6.32 kernel as well as mainline 2.6.37-rc7 kernel, it worked fine. Sure, I have tons of SanDisk cards that work perfectly (and always have). It is the brand new, just out of the box Sandisk that fails. Steve -- 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] omap3: clocks: Fix build error 'CK_3430ES2' undeclared here
At latest mainline commit 0c21e3aaf6a, omap2plus build is broken. This
patch is trivial fix for the missed usb clock node for CK_3430ES2PLUS
flag update.
CHK include/generated/compile.h
CC arch/arm/mach-omap2/clock3xxx_data.o
arch/arm/mach-omap2/clock3xxx_data.c:3289: error: 'CK_3430ES2' undeclared
here (not in a function)
make[1]: *** [arch/arm/mach-omap2/clock3xxx_data.o] Error 1
make: *** [arch/arm/mach-omap2] Error 2
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clock3xxx_data.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index d3ab1c9..c54cc33 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3286,7 +3286,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, cpefuse_fck, cpefuse_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, ts_fck, ts_fck,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, usbtll_fck, usbtll_fck,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK(ehci-omap.0, usbtll_fck, usbtll_fck,CK_3430ES2 |
CK_AM35XX),
+ CLK(ehci-omap.0, usbtll_fck, usbtll_fck,CK_3430ES2PLUS
| CK_AM35XX),
CLK(omap-mcbsp.1, prcm_fck, core_96m_fck, CK_3XXX),
CLK(omap-mcbsp.5, prcm_fck, core_96m_fck, CK_3XXX),
CLK(NULL, core_96m_fck, core_96m_fck, CK_3XXX),
--
1.6.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 v3] LEDS: Add output invertion option to backlight trigger
This patch extends the LED backlight tirgger driver with an option that
allows for inverting the trigger output polarity.
With the invertion option provided, I (ab)use the backlight trigger for
driving a LED that indicates LCD display blank condtition on my Amstrad
Delta videophone. Since the machine has no dedicated power LED, it was
not possible to distinguish if the display was blanked, or the machine
was turned off, without touching it.
The invert sysfs control is patterned after a similiar function of the
GPIO trigger driver.
Created and tested against linux-2.6.37 on Amstrad Delta.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Cc: Richard Purdie rpur...@rpsys.net
---
v2 - v3 changes, all provided, requested or inspired by Andrew Morton
(thanks!):
- sysfs file should show 0 or 1 to match the thing which the user
wrote there,
- use strict_strtoul() so the kernel correctly rejects non-numerical
input,
- disallow any input other than 0 or 1,
- new sysfs file should be documented,
- the new sysfs file name could be consistent with the one already used
by the gpio trigger for a similiar function.
v1 - v2 changes:
- improve some conditional expressions to be more readable; thanks to
Ralph Corderoy (from e3-hacking) and Lars-Peter Clausen for their
suggestions,
- refresh against linux-2.6.36-rc5.
Documentation/ABI/testing/sysfs-class-led | 10
drivers/leds/ledtrig-backlight.c | 61 --
2 files changed, 67 insertions(+), 4 deletions(-)
--- linux-2.6.37/drivers/leds/ledtrig-backlight.c.orig 2011-01-10
02:55:26.0 +0100
+++ linux-2.6.37/drivers/leds/ledtrig-backlight.c 2011-01-10
03:12:46.0 +0100
@@ -26,6 +26,7 @@ struct bl_trig_notifier {
int brightness;
int old_status;
struct notifier_block notifier;
+ unsigned invert;
};
static int fb_notifier_callback(struct notifier_block *p,
@@ -36,23 +37,64 @@ static int fb_notifier_callback(struct n
struct led_classdev *led = n-led;
struct fb_event *fb_event = data;
int *blank = fb_event-data;
+ int new_status = *blank ? BLANK : UNBLANK;
switch (event) {
case FB_EVENT_BLANK :
- if (*blank n-old_status == UNBLANK) {
+ if (new_status == n-old_status)
+ break;
+
+ if ((n-old_status == UNBLANK) ^ n-invert) {
n-brightness = led-brightness;
led_set_brightness(led, LED_OFF);
- n-old_status = BLANK;
- } else if (!*blank n-old_status == BLANK) {
+ } else {
led_set_brightness(led, n-brightness);
- n-old_status = UNBLANK;
}
+
+ n-old_status = new_status;
+
break;
}
return 0;
}
+static ssize_t bl_trig_invert_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct led_classdev *led = dev_get_drvdata(dev);
+ struct bl_trig_notifier *n = led-trigger_data;
+
+ return sprintf(buf, %u\n, n-invert);
+}
+
+static ssize_t bl_trig_invert_store(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t num)
+{
+ struct led_classdev *led = dev_get_drvdata(dev);
+ struct bl_trig_notifier *n = led-trigger_data;
+ unsigned long invert;
+ int ret;
+
+ ret = strict_strtoul(buf, 10, invert);
+ if (ret 0)
+ return ret;
+
+ if (invert 1)
+ return -EINVAL;
+
+ n-invert = invert;
+
+ /* After inverting, we need to update the LED. */
+ if ((n-old_status == BLANK) ^ n-invert)
+ led_set_brightness(led, LED_OFF);
+ else
+ led_set_brightness(led, n-brightness);
+
+ return num;
+}
+static DEVICE_ATTR(inverted, 0644, bl_trig_invert_show, bl_trig_invert_store);
+
static void bl_trig_activate(struct led_classdev *led)
{
int ret;
@@ -66,6 +108,10 @@ static void bl_trig_activate(struct led_
return;
}
+ ret = device_create_file(led-dev, dev_attr_inverted);
+ if (ret)
+ goto err_invert;
+
n-led = led;
n-brightness = led-brightness;
n-old_status = UNBLANK;
@@ -74,6 +120,12 @@ static void bl_trig_activate(struct led_
ret = fb_register_client(n-notifier);
if (ret)
dev_err(led-dev, unable to register backlight trigger\n);
+
+ return;
+
+err_invert:
+ led-trigger_data = NULL;
+ kfree(n);
}
static void bl_trig_deactivate(struct led_classdev *led)
@@ -82,6 +134,7 @@ static void bl_trig_deactivate(struct le
(struct bl_trig_notifier *) led-trigger_data;
if (n) {
+ device_remove_file(led-dev, dev_attr_inverted);
fb_unregister_client(n-notifier);
cpuidle omap 4430, some clarifications please?
Hello,
I'm using linux-2.6.35.3 on a pandaboard taking power measurements in different
idle states (I've written a userspace governor for cpuidle).
It seems like the code which is supposed to put the cores in deep sleep never
actually gets called, see code below with my comments...
Taken from arch/arm/mach-omap2/cpuidle44xx.c, omap4_enter_idle, which gets
called by cpuidle:
===
/*
* Do only WFI for non-boot CPU(aux cores)
*/
if (dev-cpu) {
wmb();
do_wfi();
goto return_sleep_time;
}
So on OMAP 4430, CPU1 never goes deeper than WFI?
/*
* Do only a WFI as long as CPU1 is online
*/
if (num_online_cpus() 1) {
wmb();
do_wfi();
goto return_sleep_time;
}
So while CPU1 is online (it never goes offline due to the above code) CPU0 will
never go deeper than WFI?
/*
* Hold on till CPU1 hits OFF
*/
cpu1_state = pwrdm_read_pwrst(cpu1_pd);
if (cpu1_state != PWRDM_POWER_OFF) {
wmb();
do_wfi();
goto return_sleep_time;
}
It seems like CPU1 will never 'hit off' ?
if (cx-type OMAP4_STATE_C1)
clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu_id);
#ifdef CONFIG_PM_DEBUG
pwrdm_pre_transition();
#endif
The code below never gets called, therefore neither CPU0, CPU1 nor the MPU go
into a deeper sleep state?
pwrdm_set_logic_retst(mpu_pd, cx-mpu_logic_state);
omap4_set_pwrdm_state(mpu_pd, cx-mpu_state);
omap4_set_pwrdm_state(core_pd, cx-core_state);
omap4_enter_sleep(dev-cpu, cx-cpu0_state);
=
Can someone clarify for me?
Cheers,
Etienne Le Sueur
--
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: cpuidle omap 4430, some clarifications please?
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Etienne Le Sueur
Sent: Monday, January 10, 2011 10:36 AM
To: linux-omap@vger.kernel.org
Subject: cpuidle omap 4430, some clarifications please?
Hello,
I'm using linux-2.6.35.3 on a pandaboard taking power measurements
in different idle states (I've written a userspace governor for
cpuidle).
It seems like the code which is supposed to put the cores in deep
sleep never actually gets called, see code below with my comments...
Taken from arch/arm/mach-omap2/cpuidle44xx.c, omap4_enter_idle,
which gets called by cpuidle:
===
/*
* Do only WFI for non-boot CPU(aux cores)
*/
if (dev-cpu) {
wmb();
do_wfi();
goto return_sleep_time;
}
So on OMAP 4430, CPU1 never goes deeper than WFI?
/*
* Do only a WFI as long as CPU1 is online
*/
if (num_online_cpus() 1) {
wmb();
do_wfi();
goto return_sleep_time;
}
So while CPU1 is online (it never goes offline due to the above
code) CPU0 will never go deeper than WFI?
/*
* Hold on till CPU1 hits OFF
*/
cpu1_state = pwrdm_read_pwrst(cpu1_pd);
if (cpu1_state != PWRDM_POWER_OFF) {
wmb();
do_wfi();
goto return_sleep_time;
}
It seems like CPU1 will never 'hit off' ?
if (cx-type OMAP4_STATE_C1)
clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER,
cpu_id);
#ifdef CONFIG_PM_DEBUG
pwrdm_pre_transition();
#endif
The code below never gets called, therefore neither CPU0, CPU1 nor
the MPU go into a deeper sleep state?
pwrdm_set_logic_retst(mpu_pd, cx-mpu_logic_state);
omap4_set_pwrdm_state(mpu_pd, cx-mpu_state);
omap4_set_pwrdm_state(core_pd, cx-core_state);
omap4_enter_sleep(dev-cpu, cx-cpu0_state);
=
Can someone clarify for me?
Yes.
Simple rule is, no low power states are targeted when both CPUs
are online. The C-states gets targeted only when secondary
CPU gets offline through hotplug infrastrcutre. CPU1 hits
OFF mode through hot-plug path and not via idle.
With this CPU1 hits OFF state, and IDLE thread running
on master CPU can hit deeper low power states. It's more of
hardware restriction what is there on OMAP4.
To put it in slightly simpler terms,
In SMP mode, no active PM is exercised in IDLE and
gets triggered when secondary cores are out of the system.
Hope this clarifies.
Regards,
Santosh
--
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
