RE: [PATCH v12 6/9] dmtimer: switch-over to platform device driver
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Saturday, March 12, 2011 12:44 AM To: DebBarma, Tarun Kanti Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH v12 6/9] dmtimer: switch-over to platform device driver * DebBarma, Tarun Kanti tarun.ka...@ti.com [110310 21:33]: [...] * Tarun Kanti DebBarma tarun.ka...@ti.com [110308 15:41]: switch-over to platform device driver through following changes: (a) initiate dmtimer early initialization from omap2_gp_timer_init() in timer-gp.c. This is equivalent of timer_init()-timer- init(). (b) modify plat-omap/dmtimer routines to use new register map and platform data. This patch breaks booting for 2420 and makes boot hang early on 2430. Note that to test with omap-for-linus branch you need to disable the following in omap2plus_defconfig: CONFIG_ARCH_OMAP3 CONFIG_ARCH_OMAP4 CONFIG_CPU_32v6K I disabled above options on omap-for-linus *WITHOUT* my patch series. I am still seeing crash. Here is the log. I tried on two different setups. Not sure if I am missing something. Hmm sounds like H4 needs some attention. Can you try the following completely untested patch? This works fine! OK thanks, can I add your Tested-by then? YES. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 00/10] OMAP4 : DSS2 : HDMI support on OMAP4
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Hiremath, Vaibhav
Sent: Friday, March 11, 2011 6:53 PM
To: Valkeinen, Tomi; K, Mythri P
Cc: Stephan Raue; linux-omap@vger.kernel.org
Subject: RE: [PATCH v5 00/10] OMAP4 : DSS2 : HDMI support on OMAP4
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Valkeinen, Tomi
Sent: Friday, March 11, 2011 12:55 PM
To: K, Mythri P
Cc: Stephan Raue; linux-omap@vger.kernel.org
Subject: Re: [PATCH v5 00/10] OMAP4 : DSS2 : HDMI support on OMAP4
On Fri, 2011-03-11 at 00:16 -0600, K, Mythri P wrote:
Hi Stephan,
On Fri, Mar 11, 2011 at 5:37 AM, Stephan Raue
mailingli...@openelec.tv
wrote:
thanks, this helps to boot the kernel. but now i get:
snip
see also: http://paste.pocoo.org/show/351648/
I see that you kernel is not booting because of dss clk
[3.335601] PC is at dss_clk_disable_no_ctx+0x0/0xa4
[3.335632] LR is at omap_dispc_register_isr+0xa4/0xcc
Tomi is this related to the clock issue you were mentioning , which
gets solved by adding a delay ?
Well, I have a hack patch in my tree which adds a delay of 10us. That
fixed the problem for me, but the 10us is just a random guess. It could
be that it needs to be longer wait. But this could be something else
also.
Tomi
[Hiremath, Vaibhav] Tomi, just thought of updating you,
The linux-omap/dss2 OMAP3EVM seems to be broken, I am trying to debug this
at the moment and will update about my findings.
Since linux-omap/master is booting up fine, it looks like one of new DSS
patch leading to this.
[Hiremath, Vaibhav] I think I found the where and why the kernel is crashing
but not sure about root-cause -
The root-cause turned out to be -
void dss_clk_enable(enum dss_clock clks)
{
...
if (check_ctx cpu_is_omap34xx() dss_need_ctx_restore())
restore_all_ctx();
...
}
In this case, restore never happens, if I understand correctly, I am expecting,
the context must be restored when all clock (especially interface clock) is
disabled.
In order to do this, dss_need_ctx_restore must be implemented here, which I
think should be ORed with other conditions.
if (cpu_is_omap34xx() (check_ctx || dss_need_ctx_restore()))
(This results in kernel crash at my end)
Personally I don't know any platform is implementing this function OR how one
should make use of it. I remember last time we had similar discussion and the
comment came was, restore only required in case of off mode. I feel, this is
not applicable here, since irrespective of retention/inactive/off mode if
driver is disabling clock for the peripheral we must restore the context.
Thanks,
Vaibhav
Thanks,
Vaibhav
--
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
--
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 2/2] omap4: mux: Remove duplicate mux modes
Hi Tony,
On 3/11/2011 9:34 PM, Tony Lindgren wrote:
Remove duplicate mux modes to make the binary smaller:
textdata bss dec hex filename
9378 24472 0 33850843a mux44xx.o
9378 19104 0 284826f42 mux44xx.o
Cc: Benoit Coussonb-cous...@ti.com
Signed-off-by: Tony Lindgrent...@atomide.com
---
arch/arm/mach-omap2/mux44xx.c | 282 +
1 files changed, 6 insertions(+), 276 deletions(-)
diff --git a/arch/arm/mach-omap2/mux44xx.c b/arch/arm/mach-omap2/mux44xx.c
index c322e7b..9a66445 100644
--- a/arch/arm/mach-omap2/mux44xx.c
+++ b/arch/arm/mach-omap2/mux44xx.c
@@ -755,25 +755,9 @@ static struct omap_ball __initdata omap4_core_cbl_ball[] =
{
#endif
/*
- * Superset of all mux modes for omap4 ES2.0
+ * Signals different on ES2.0 compared to superset
I didn't do it originally due to the huge amount of differences between
the two versions and the impact at runtime it will imply to fix the
modified entries at boot time. It might still be interesting to measure it.
Since ES1 is no longer used on any board except the early one, that you
probably still have :-), it might be better to consider ES2 as the
superset and then store ES1 diff as the subset. It will avoid any
performance impact for the latest devices.
Regards,
Benoit
*/
-static struct omap_mux __initdata omap4_es2_core_muxmodes[] = {
- _OMAP4_MUXENTRY(GPMC_AD0, 0, gpmc_ad0, sdmmc2_dat0, NULL, NULL,
- NULL, NULL, NULL, NULL),
- _OMAP4_MUXENTRY(GPMC_AD1, 0, gpmc_ad1, sdmmc2_dat1, NULL, NULL,
- NULL, NULL, NULL, NULL),
- _OMAP4_MUXENTRY(GPMC_AD2, 0, gpmc_ad2, sdmmc2_dat2, NULL, NULL,
- NULL, NULL, NULL, NULL),
- _OMAP4_MUXENTRY(GPMC_AD3, 0, gpmc_ad3, sdmmc2_dat3, NULL, NULL,
- NULL, NULL, NULL, NULL),
- _OMAP4_MUXENTRY(GPMC_AD4, 0, gpmc_ad4, sdmmc2_dat4,
- sdmmc2_dir_dat0, NULL, NULL, NULL, NULL, NULL),
- _OMAP4_MUXENTRY(GPMC_AD5, 0, gpmc_ad5, sdmmc2_dat5,
- sdmmc2_dir_dat1, NULL, NULL, NULL, NULL, NULL),
- _OMAP4_MUXENTRY(GPMC_AD6, 0, gpmc_ad6, sdmmc2_dat6,
- sdmmc2_dir_cmd, NULL, NULL, NULL, NULL, NULL),
- _OMAP4_MUXENTRY(GPMC_AD7, 0, gpmc_ad7, sdmmc2_dat7,
- sdmmc2_clk_fdbk, NULL, NULL, NULL, NULL, NULL),
+static struct omap_mux __initdata omap4_es2_core_subset[] = {
_OMAP4_MUXENTRY(GPMC_AD8, 32, gpmc_ad8, kpd_row0, c2c_data15,
gpio_32, NULL, sdmmc1_dat0, NULL, NULL),
_OMAP4_MUXENTRY(GPMC_AD9, 33, gpmc_ad9, kpd_row1, c2c_data14,
@@ -792,52 +776,15 @@ static struct omap_mux __initdata
omap4_es2_core_muxmodes[] = {
gpio_39, NULL, sdmmc1_dat7, NULL, NULL),
_OMAP4_MUXENTRY(GPMC_A16, 40, gpmc_a16, kpd_row4, c2c_datain0,
gpio_40, venc_656_data0, NULL, NULL, safe_mode),
- _OMAP4_MUXENTRY(GPMC_A17, 41, gpmc_a17, kpd_row5, c2c_datain1,
- gpio_41, venc_656_data1, NULL, NULL, safe_mode),
- _OMAP4_MUXENTRY(GPMC_A18, 42, gpmc_a18, kpd_row6, c2c_datain2,
- gpio_42, venc_656_data2, NULL, NULL, safe_mode),
- _OMAP4_MUXENTRY(GPMC_A19, 43, gpmc_a19, kpd_row7, c2c_datain3,
- gpio_43, venc_656_data3, NULL, NULL, safe_mode),
- _OMAP4_MUXENTRY(GPMC_A20, 44, gpmc_a20, kpd_col4, c2c_datain4,
- gpio_44, venc_656_data4, NULL, NULL, safe_mode),
- _OMAP4_MUXENTRY(GPMC_A21, 45, gpmc_a21, kpd_col5, c2c_datain5,
- gpio_45, venc_656_data5, NULL, NULL, safe_mode),
- _OMAP4_MUXENTRY(GPMC_A22, 46, gpmc_a22, kpd_col6, c2c_datain6,
- gpio_46, venc_656_data6, NULL, NULL, safe_mode),
- _OMAP4_MUXENTRY(GPMC_A23, 47, gpmc_a23, kpd_col7, c2c_datain7,
- gpio_47, venc_656_data7, NULL, NULL, safe_mode),
_OMAP4_MUXENTRY(GPMC_A24, 48, gpmc_a24, kpd_col8, c2c_clkout0,
gpio_48, NULL, NULL, NULL, safe_mode),
- _OMAP4_MUXENTRY(GPMC_A25, 49, gpmc_a25, NULL, c2c_clkout1,
- gpio_49, NULL, NULL, NULL, safe_mode),
- _OMAP4_MUXENTRY(GPMC_NCS0, 50, gpmc_ncs0, NULL, NULL, gpio_50,
- sys_ndmareq0, NULL, NULL, NULL),
- _OMAP4_MUXENTRY(GPMC_NCS1, 51, gpmc_ncs1, NULL, c2c_dataout6,
- gpio_51, NULL, NULL, NULL, safe_mode),
_OMAP4_MUXENTRY(GPMC_NCS2, 52, gpmc_ncs2, kpd_row8,
c2c_dataout7, gpio_52, NULL, NULL, NULL,
safe_mode),
- _OMAP4_MUXENTRY(GPMC_NCS3, 53, gpmc_ncs3, gpmc_dir,
- c2c_dataout4, gpio_53, NULL, NULL, NULL,
- safe_mode),
- _OMAP4_MUXENTRY(GPMC_NWP, 54, gpmc_nwp, dsi1_te0, NULL, gpio_54,
- sys_ndmareq1, NULL, NULL, NULL),
RE: [PATCH 1/3] omap2plus: clock: Add an alias cpu_ck to be used in common cpufreq driver
-Original Message- From: Kevin Hilman [mailto:khil...@ti.com] Sent: Friday, March 11, 2011 3:43 AM To: Santosh Shilimkar Cc: linux-omap@vger.kernel.org; vishwanath...@ti.com Subject: Re: [PATCH 1/3] omap2plus: clock: Add an alias cpu_ck to be used in common cpufreq driver Santosh Shilimkar santosh.shilim...@ti.com writes: Add an alias clock node for cpu clock control on all OMAP2PLUS devices. The intention is avoid cpu_is_() checks in the common cpufreq driver. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Rather than having hard-coded clkdev nodes, Since CPUfreq will be the only user of these clocks, it might make sense to just use cpu_is_* in the CPUfreq init and do clk_add_alias(). Since we are ok to have cpu_is_*() in CPUfreq init, we don't even need to clk_add_alias(). We just the correct clock node handle based on SOC. 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
RE: [PATCH v5 00/10] OMAP4 : DSS2 : HDMI support on OMAP4
On Mon, 2011-03-14 at 03:35 -0500, Hiremath, Vaibhav wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Hiremath, Vaibhav
Sent: Friday, March 11, 2011 6:53 PM
To: Valkeinen, Tomi; K, Mythri P
Cc: Stephan Raue; linux-omap@vger.kernel.org
Subject: RE: [PATCH v5 00/10] OMAP4 : DSS2 : HDMI support on OMAP4
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Valkeinen, Tomi
Sent: Friday, March 11, 2011 12:55 PM
To: K, Mythri P
Cc: Stephan Raue; linux-omap@vger.kernel.org
Subject: Re: [PATCH v5 00/10] OMAP4 : DSS2 : HDMI support on OMAP4
On Fri, 2011-03-11 at 00:16 -0600, K, Mythri P wrote:
Hi Stephan,
On Fri, Mar 11, 2011 at 5:37 AM, Stephan Raue
mailingli...@openelec.tv
wrote:
thanks, this helps to boot the kernel. but now i get:
snip
see also: http://paste.pocoo.org/show/351648/
I see that you kernel is not booting because of dss clk
[3.335601] PC is at dss_clk_disable_no_ctx+0x0/0xa4
[3.335632] LR is at omap_dispc_register_isr+0xa4/0xcc
Tomi is this related to the clock issue you were mentioning , which
gets solved by adding a delay ?
Well, I have a hack patch in my tree which adds a delay of 10us. That
fixed the problem for me, but the 10us is just a random guess. It could
be that it needs to be longer wait. But this could be something else
also.
Tomi
[Hiremath, Vaibhav] Tomi, just thought of updating you,
The linux-omap/dss2 OMAP3EVM seems to be broken, I am trying to debug this
at the moment and will update about my findings.
Since linux-omap/master is booting up fine, it looks like one of new DSS
patch leading to this.
[Hiremath, Vaibhav] I think I found the where and why the kernel is crashing
but not sure about root-cause -
The root-cause turned out to be -
void dss_clk_enable(enum dss_clock clks)
{
...
if (check_ctx cpu_is_omap34xx() dss_need_ctx_restore())
restore_all_ctx();
...
}
In this case, restore never happens, if I understand correctly, I am
expecting, the context must be restored when all clock (especially interface
clock) is disabled.
In order to do this, dss_need_ctx_restore must be implemented here, which I
think should be ORed with other conditions.
if (cpu_is_omap34xx() (check_ctx || dss_need_ctx_restore()))
(This results in kernel crash at my end)
Personally I don't know any platform is implementing this function OR how one
should make use of it. I remember last time we had similar discussion and the
comment came was, restore only required in case of off mode. I feel, this is
not applicable here, since irrespective of retention/inactive/off mode if
driver is disabling clock for the peripheral we must restore the context.
I don't know about OMAP4, but on OMAP3 the register contents are only
lost when DSS goes to OFF mode. If you just turn off the clocks and OFF
mode is not enabled in the PM, context restore is not needed. I am not
sure of the current status of OFF mode in the mainline kernel.
However, for some reason DSS works fine on my Overo board. I would
imagine that it would break also if OFF is enabled for all omap
boards...
As for get_last_off_on_transaction_id(), it seems to be called
get_context_loss_count() in the mainline kernel and returns u32, not
int. I haven't tested it, but get_last_off_on_transaction_id pointer in
the dss platform data should be set to get_context_loss_count in the
board file (or in arch/arm/plat-omap/display.c if using the dss2 tree).
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 00/10] OMAP4 : DSS2 : HDMI support on OMAP4
-Original Message-
From: Valkeinen, Tomi
Sent: Monday, March 14, 2011 2:55 PM
To: Hiremath, Vaibhav
Cc: K, Mythri P; Stephan Raue; linux-omap@vger.kernel.org
Subject: RE: [PATCH v5 00/10] OMAP4 : DSS2 : HDMI support on OMAP4
On Mon, 2011-03-14 at 03:35 -0500, Hiremath, Vaibhav wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Hiremath, Vaibhav
Sent: Friday, March 11, 2011 6:53 PM
To: Valkeinen, Tomi; K, Mythri P
Cc: Stephan Raue; linux-omap@vger.kernel.org
Subject: RE: [PATCH v5 00/10] OMAP4 : DSS2 : HDMI support on OMAP4
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Valkeinen, Tomi
Sent: Friday, March 11, 2011 12:55 PM
To: K, Mythri P
Cc: Stephan Raue; linux-omap@vger.kernel.org
Subject: Re: [PATCH v5 00/10] OMAP4 : DSS2 : HDMI support on OMAP4
On Fri, 2011-03-11 at 00:16 -0600, K, Mythri P wrote:
Hi Stephan,
On Fri, Mar 11, 2011 at 5:37 AM, Stephan Raue
mailingli...@openelec.tv
wrote:
thanks, this helps to boot the kernel. but now i get:
snip
see also: http://paste.pocoo.org/show/351648/
I see that you kernel is not booting because of dss clk
[3.335601] PC is at dss_clk_disable_no_ctx+0x0/0xa4
[3.335632] LR is at omap_dispc_register_isr+0xa4/0xcc
Tomi is this related to the clock issue you were mentioning ,
which
gets solved by adding a delay ?
Well, I have a hack patch in my tree which adds a delay of 10us.
That
fixed the problem for me, but the 10us is just a random guess. It
could
be that it needs to be longer wait. But this could be something else
also.
Tomi
[Hiremath, Vaibhav] Tomi, just thought of updating you,
The linux-omap/dss2 OMAP3EVM seems to be broken, I am trying to debug
this
at the moment and will update about my findings.
Since linux-omap/master is booting up fine, it looks like one of new
DSS
patch leading to this.
[Hiremath, Vaibhav] I think I found the where and why the kernel is
crashing but not sure about root-cause -
The root-cause turned out to be -
void dss_clk_enable(enum dss_clock clks)
{
...
if (check_ctx cpu_is_omap34xx() dss_need_ctx_restore())
restore_all_ctx();
...
}
In this case, restore never happens, if I understand correctly, I am
expecting, the context must be restored when all clock (especially
interface clock) is disabled.
In order to do this, dss_need_ctx_restore must be implemented here,
which I think should be ORed with other conditions.
if (cpu_is_omap34xx() (check_ctx || dss_need_ctx_restore()))
(This results in kernel crash at my end)
Personally I don't know any platform is implementing this function OR
how one should make use of it. I remember last time we had similar
discussion and the comment came was, restore only required in case of off
mode. I feel, this is not applicable here, since irrespective of
retention/inactive/off mode if driver is disabling clock for the
peripheral we must restore the context.
I don't know about OMAP4, but on OMAP3 the register contents are only
lost when DSS goes to OFF mode. If you just turn off the clocks and OFF
mode is not enabled in the PM, context restore is not needed. I am not
sure of the current status of OFF mode in the mainline kernel.
However, for some reason DSS works fine on my Overo board. I would
imagine that it would break also if OFF is enabled for all omap
boards...
As for get_last_off_on_transaction_id(), it seems to be called
get_context_loss_count() in the mainline kernel and returns u32, not
int. I haven't tested it, but get_last_off_on_transaction_id pointer in
the dss platform data should be set to get_context_loss_count in the
board file (or in arch/arm/plat-omap/display.c if using the dss2 tree).
[Hiremath, Vaibhav] Let me try this out.
Thanks,
Vaibhav
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] OMAP3: wdtimer: Fix CORE idle transition
Hi Paul, -Original Message- From: ext Paul Walmsley [mailto:p...@pwsan.com] Sent: 10. maaliskuuta 2011 16:53 From: Paul Walmsley p...@pwsan.com The HW superwised smart idle for wdtimer in OMAP3 prevents CORE power domain idle transitions. Disable it by swithing to SW supervised transitions. This could be a hardware bug in the OMAP3 wdtimer2 block. Signed-off-by: Kalle Jokiniemi kalle.jokini...@nokia.com Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Benoit Cousson b-cous...@ti.com I've queued this one for 2.6.39, since it seems pretty clear that target smart- idle mode doesn't work with this IP block. What about the 1/2 patch? Is that going in, and to which kernel version (our integrator would like to put in a note when we can remove the back ported patch) - Kalle Probably we'll need to do the same thing for OMAP2420/2430, but I'm not going to touch those right now, since we're so close to the merge window. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 00/10] OMAP4 : DSS2 : HDMI support on OMAP4
Hi Tomi, On Thu, Mar 10, 2011 at 2:44 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: I think this version is good. It works for me, at least =). Any Panda or Blaze owners reading this want to give this a try? Tested on my pandaboard, with these patches applied on top of your dss2 tree: I get a working display on my DVI or my HDMI screen. = I tested by running the Ubuntu UI. I have a couple of these traces from times to times (seems linked to screen saver enabling/disabling the screen): omapdss DISPC error: timeout waiting for EVSYNC The best screen resolution is properly selected on both of my screens, but the frame-buffer is sized to 640x480. So the display works but the usable surface when going though /dev/fb0 is quite reduced. Is there a way to get the FB sized according to the screen resolution (in the init sequence, it appears that the FBs are allocated before the init of the HDMI)? Fyi, I have also tested with the patches for DVI support and can get both outputs working simultaneously (my tree is here: http://dev.omapzoom.org/?p=sebjan/kernel.git;a=shortlog;h=refs/tags/topic-display-iv1-2.6.38-rc7). -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP4: clockdomain: Follow recommended enable sequence
On 3/12/2011 1:23 PM, Rajendra Nayak wrote: Hi Kevin, On 3/11/2011 10:17 PM, Kevin Hilman wrote: Rajendra Nayakrna...@ti.com writes: [...] It's also breaking boot on OMAP35xx BeagleBoard rev C2. The kernel boot messages are below - omap2plus_defconfig + DEBUG_LL. Reverting the patch fixes it. Could you please take a look? I got hold of a Beagle, a sticker on which says rev C1D. Not sure if there is a better way to identify the rev, but this one seems to boot fine for me even with this patch. I just applied this one patch on top of the the tag 'integration-2.6.39-20110310-008' of git://git.pwsan.com/linux- integration. In the process of testing Santosh's OMAP4 PM series (which includes $SUBJECT patch) on OMAP3, I also noticed some problems on beagle (mine is a C3.) Specifially, with $SUBJECT patch applied, none of the powerdomains ever reach inactive or RET during idle (suspend seems to work fine.) Just reverting $SUBJECT patch makes things go back to working normally. I pushed the test branch I used which is a merge of Santosh's v3 branch with my pm branch (branch: tmp/santosh-omap4-pm) I tested by first doing a suspend test and confirming all the powerdomains hit retention. That worked fine. Then I did an idle test: echo 5 /sys/devices/platform/omap/omap_uart.0/sleep_timeout echo 5 /sys/devices/platform/omap/omap_uart.1/sleep_timeout echo 5 /sys/devices/platform/omap/omap_uart.2/sleep_timeout echo 1 /debug/pm_debug/sleep_while_idle and waited for the UARTs to timeout. Well after the UART timeouts expired, I do not see any powerdomains transitioning from ON. What's even more strange is that the same thing is working fine on all the other OMAP3 platforms I tested: 3430/n900, 3630/zoom3 and even a different 3530-based platform, the OMAP3EVM. I probably know whats going wrong with this patch, even though I haven't really been able to reproduce any of these issues myself. The below change which should be the only one affecting non-OMAP4 platforms actually is calling clkdm_allow_idle() for all clkdms without really checking for a CLKDM_CAN_ENABLE_AUTO flag, which seems wrong. I was somehow under the impression that the clkdm_allow_idle() function would internally do this check but that does not seem to be the case. Actually I was wrong, clkdm_allow_idle() does seem to have a check for the CLKDM_CAN_ENABLE_AUTO flag. -- 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 2/2] omap: rx51: initialize platform data for twl4030 powerbutton
Hi,
On Fri, 11 Mar 2011, Denis Karpov wrote:
From: Denis Karpov ext-denis.2.kar...@nokia.com
Adds and initializes platform data for TWL4030 powerbutton.
Disable repeat input events from a button press (default behaviour).
[...]
+static struct twl4030_pwrbutton_data rx51_pwrbutton_data = {
+ .rep= 1,
+};
+
Doesn't this enable them? If you want to keep the default behaviour,
you can just omit the platform data.
static struct twl4030_madc_platform_data rx51_madc_data = {
.irq_line = 1,
};
@@ -758,6 +762,7 @@ static struct twl4030_platform_data rx51_twldata __initdata
= {
/* platform_data for children goes here */
.gpio = rx51_gpio_data,
.keypad = rx51_kp_data,
+ .pwrbutton = rx51_pwrbutton_data,
A.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] power button repeat input events
On Fri, Mar 11, 2011 at 10:25:27PM +0530, ext Nishanth Menon wrote: Denis Karpov wrote, on 03/11/2011 10:07 PM: Hi, this patchset adds optional generation of repeat input events for twl4030 power button. It adds optional platform data for twl4030-pwrbutton and initializes it for RX51/N900 (default behavior kept - repeated input events disabled). We are working on an OMAP3 with TWL5031 MFD. In one of the use scenarios userspace wants to receive repeated input events from long press of power button. dumb question - is'nt this a userspace responsibility as far as power button is concerned? what is the benefit of providing repeat events like a generic keypad for the power button? In our case userspace needs this to track the continuous button press of power button. Denis -- 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 2/2] omap: rx51: initialize platform data for twl4030 powerbutton
From: Denis Karpov ext-denis.2.kar...@nokia.com
+static struct twl4030_pwrbutton_data rx51_pwrbutton_data = {
+.rep= 1,
+};
+
Doesn't this enable them? If you want to keep the default behaviour,
you can just omit the platform data.
Yes, you are right, thanks. I meant to set it to 0 after testing, but
then it is not needed indeed.
So patch 2/2 is not needed and patch 1/2 does not belong here - I'll
resend it to input/mfd lists/maintainers.
Denis
--
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 v2 0/2] [pm-wip/cpufreq] OMAP: CPUfreq cleanup and SMP support
This series is an attempt to clean-up OMAP CPUfreq driver.
- The OMAP1 and OMAP2PLUS cpufreq support is split to avoid
any #ifdefery
- The omap2plus_cupfreq support is updated to work on
SMP_ON_UP builds
- SMP support is added which can be used on OMAP4
The series is generated against Kevin's latest cpufreq branch.
The following changes since commit 444a22eb04ae07aef45cd4d0154f6f2bbe76daa9:
Kevin Hilman (1):
cpufreq: fixup after new OPP layer merged
Santosh Shilimkar (2):
OMAP: cpufreq: Split OMAP1 and OMAP2PLUS CPUfreq drivers.
OMAP2PLUS: cpufreq: Add SMP support to cater OMAP4430
arch/arm/mach-omap1/Makefile |3 +
.../cpu-omap.c = mach-omap1/omap1-cpufreq.c} | 68 +++--
arch/arm/mach-omap2/Makefile |3 +
.../cpu-omap.c = mach-omap2/omap2plus-cpufreq.c} | 156 +---
arch/arm/plat-omap/Makefile|1 -
5 files changed, 128 insertions(+), 103 deletions(-)
copy arch/arm/{plat-omap/cpu-omap.c = mach-omap1/omap1-cpufreq.c} (75%)
rename arch/arm/{plat-omap/cpu-omap.c = mach-omap2/omap2plus-cpufreq.c} (55%)
--
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 v2 2/2] OMAP2PLUS: cpufreq: Add SMP support to cater OMAP4430
On OMAP SMP configuartion, both processors share the voltage
and clock. So both CPUs needs to be scaled together and hence
needs software co-ordination.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Kevin Hilman khil...@ti.com
cc: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/omap2plus-cpufreq.c | 73 ++-
1 files changed, 62 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c
b/arch/arm/mach-omap2/omap2plus-cpufreq.c
index 216704e..84caa6d 100644
--- a/arch/arm/mach-omap2/omap2plus-cpufreq.c
+++ b/arch/arm/mach-omap2/omap2plus-cpufreq.c
@@ -26,9 +26,11 @@
#include linux/clk.h
#include linux/io.h
#include linux/opp.h
+#include linux/cpu.h
#include asm/system.h
#include asm/smp_plat.h
+#include asm/cpu.h
#include plat/clock.h
#include plat/omap-pm.h
@@ -63,7 +65,7 @@ static unsigned int omap_getspeed(unsigned int cpu)
{
unsigned long rate;
- if (cpu)
+ if (cpu = NR_CPUS)
return 0;
rate = clk_get_rate(mpu_clk) / 1000;
@@ -74,9 +76,13 @@ static int omap_target(struct cpufreq_policy *policy,
unsigned int target_freq,
unsigned int relation)
{
- int ret = 0;
+ int i, ret = 0;
struct cpufreq_freqs freqs;
+ /* Changes not allowed until all CPUs are online */
+ if (is_smp() (num_online_cpus() NR_CPUS))
+ return ret;
+
/* Ensure desired rate is within allowed range. Some govenors
* (ondemand) will just pass target_freq=0 to get the minimum. */
if (target_freq policy-min)
@@ -84,15 +90,25 @@ static int omap_target(struct cpufreq_policy *policy,
if (target_freq policy-max)
target_freq = policy-max;
- freqs.old = omap_getspeed(0);
+ freqs.old = omap_getspeed(policy-cpu);
freqs.new = clk_round_rate(mpu_clk, target_freq * 1000) / 1000;
- freqs.cpu = 0;
+ freqs.cpu = policy-cpu;
if (freqs.old == freqs.new)
return ret;
- cpufreq_notify_transition(freqs, CPUFREQ_PRECHANGE);
+ if (!is_smp()) {
+ cpufreq_notify_transition(freqs, CPUFREQ_PRECHANGE);
+ goto set_freq;
+ }
+
+ /* notifiers */
+ for_each_cpu(i, policy-cpus) {
+ freqs.cpu = i;
+ cpufreq_notify_transition(freqs, CPUFREQ_PRECHANGE);
+ }
+set_freq:
#ifdef CONFIG_CPU_FREQ_DEBUG
pr_info(cpufreq-omap: transition: %u -- %u\n, freqs.old, freqs.new);
#endif
@@ -105,12 +121,33 @@ static int omap_target(struct cpufreq_policy *policy,
* CONFIG_SMP enabled. Below code is added only to manage that
* scenario
*/
- if (!is_smp())
+ freqs.new = omap_getspeed(policy-cpu);
+ if (!is_smp()) {
loops_per_jiffy =
cpufreq_scale(loops_per_jiffy, freqs.old, freqs.new);
+ cpufreq_notify_transition(freqs, CPUFREQ_POSTCHANGE);
+ goto skip_lpj;
+ }
- cpufreq_notify_transition(freqs, CPUFREQ_POSTCHANGE);
+#ifdef CONFIG_SMP
+ /*
+* Note that loops_per_jiffy is not updated on SMP systems in
+* cpufreq driver. So, update the per-CPU loops_per_jiffy value
+* on frequency transition. We need to update all dependent CPUs.
+*/
+ for_each_cpu(i, policy-cpus)
+ per_cpu(cpu_data, i).loops_per_jiffy =
+ cpufreq_scale(per_cpu(cpu_data, i).loops_per_jiffy,
+ freqs.old, freqs.new);
+#endif
+ /* notifiers */
+ for_each_cpu(i, policy-cpus) {
+ freqs.cpu = i;
+ cpufreq_notify_transition(freqs, CPUFREQ_POSTCHANGE);
+ }
+
+skip_lpj:
return ret;
}
@@ -118,6 +155,7 @@ static int __init omap_cpu_init(struct cpufreq_policy
*policy)
{
int result = 0;
struct device *mpu_dev;
+ static cpumask_var_t cpumask;
if (cpu_is_omap24xx())
mpu_clk = clk_get(NULL, virt_prcm_set);
@@ -129,12 +167,12 @@ static int __init omap_cpu_init(struct cpufreq_policy
*policy)
if (IS_ERR(mpu_clk))
return PTR_ERR(mpu_clk);
- if (policy-cpu != 0)
+ if (policy-cpu = NR_CPUS)
return -EINVAL;
- policy-cur = policy-min = policy-max = omap_getspeed(0);
-
+ policy-cur = policy-min = policy-max = omap_getspeed(policy-cpu);
mpu_dev = omap2_get_mpuss_device();
+
if (!mpu_dev) {
pr_warning(%s: unable to get the mpu device\n, __func__);
return -EINVAL;
@@ -154,7 +192,20 @@ static int __init omap_cpu_init(struct cpufreq_policy
*policy)
policy-min = policy-cpuinfo.min_freq;
policy-max = policy-cpuinfo.max_freq;
- policy-cur = omap_getspeed(0);
+ policy-cur = omap_getspeed(policy-cpu);
+
+ /*
+
[PATCH v2 1/2] OMAP: cpufreq: Split OMAP1 and OMAP2PLUS CPUfreq drivers.
This patch is an attempt to cleanup the #ifdeferry in the
omap CPUfreq drivers.
The split betwenn OMAP1 and OMAP2PLUS is logical because
- OMAP1 doesn't support opp layer.
- OMAP1 build is seperate from omap2plus.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap1/Makefile |3 +
.../cpu-omap.c = mach-omap1/omap1-cpufreq.c} | 68 +--
arch/arm/mach-omap2/Makefile |3 +
.../cpu-omap.c = mach-omap2/omap2plus-cpufreq.c} | 91 ++--
arch/arm/plat-omap/Makefile|1 -
5 files changed, 70 insertions(+), 96 deletions(-)
copy arch/arm/{plat-omap/cpu-omap.c = mach-omap1/omap1-cpufreq.c} (75%)
rename arch/arm/{plat-omap/cpu-omap.c = mach-omap2/omap2plus-cpufreq.c} (76%)
diff --git a/arch/arm/mach-omap1/Makefile b/arch/arm/mach-omap1/Makefile
index ba6009f..cb2d3a6 100644
--- a/arch/arm/mach-omap1/Makefile
+++ b/arch/arm/mach-omap1/Makefile
@@ -10,6 +10,9 @@ obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
obj-$(CONFIG_OMAP_32K_TIMER) += timer32k.o
+# CPUFREQ driver
+obj-$(CONFIG_CPU_FREQ) += omap1-cpufreq.o
+
# Power Management
obj-$(CONFIG_PM) += pm.o sleep.o pm_bus.o
diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/mach-omap1/omap1-cpufreq.c
similarity index 75%
copy from arch/arm/plat-omap/cpu-omap.c
copy to arch/arm/mach-omap1/omap1-cpufreq.c
index 1c1b80b..682cdc8 100644
--- a/arch/arm/plat-omap/cpu-omap.c
+++ b/arch/arm/mach-omap1/omap1-cpufreq.c
@@ -1,5 +1,5 @@
/*
- * linux/arch/arm/plat-omap/cpu-omap.c
+ * OMAP1 cpufreq driver
*
* CPU frequency scaling for OMAP
*
@@ -27,31 +27,18 @@
#include linux/io.h
#include linux/opp.h
-#include mach/hardware.h
-#include plat/clock.h
#include asm/system.h
-#if defined(CONFIG_ARCH_OMAP3) !defined(CONFIG_OMAP_PM_NONE)
+#include plat/clock.h
#include plat/omap-pm.h
-#include plat/common.h
-#endif
+
+#include mach/hardware.h
#define VERY_HI_RATE 9
static struct cpufreq_frequency_table *freq_table;
-
-#ifdef CONFIG_ARCH_OMAP1
-#define MPU_CLKmpu
-#elif defined(CONFIG_ARCH_OMAP3)
-#define MPU_CLKarm_fck
-#else
-#define MPU_CLKvirt_prcm_set
-#endif
-
static struct clk *mpu_clk;
-/* TODO: Add support for SDRAM timing changes */
-
static int omap_verify_speed(struct cpufreq_policy *policy)
{
if (freq_table)
@@ -85,13 +72,7 @@ static int omap_target(struct cpufreq_policy *policy,
unsigned int target_freq,
unsigned int relation)
{
-#ifdef CONFIG_ARCH_OMAP1
struct cpufreq_freqs freqs;
-#endif
-#if defined(CONFIG_ARCH_OMAP3) !defined(CONFIG_OMAP_PM_NONE)
- unsigned long freq;
- struct device *mpu_dev = omap2_get_mpuss_device();
-#endif
int ret = 0;
/* Ensure desired rate is within allowed range. Some govenors
@@ -101,25 +82,22 @@ static int omap_target(struct cpufreq_policy *policy,
if (target_freq policy-max)
target_freq = policy-max;
-#ifdef CONFIG_ARCH_OMAP1
freqs.old = omap_getspeed(0);
freqs.new = clk_round_rate(mpu_clk, target_freq * 1000) / 1000;
freqs.cpu = 0;
if (freqs.old == freqs.new)
return ret;
+
cpufreq_notify_transition(freqs, CPUFREQ_PRECHANGE);
+
#ifdef CONFIG_CPU_FREQ_DEBUG
- printk(KERN_DEBUG cpufreq-omap: transition: %u -- %u\n,
- freqs.old, freqs.new);
+ pr_info(cpufreq-omap: transition: %u -- %u\n, freqs.old, freqs.new);
#endif
ret = clk_set_rate(mpu_clk, freqs.new * 1000);
+
cpufreq_notify_transition(freqs, CPUFREQ_POSTCHANGE);
-#elif defined(CONFIG_ARCH_OMAP3) !defined(CONFIG_OMAP_PM_NONE)
- freq = target_freq * 1000;
- if (opp_find_freq_ceil(mpu_dev, freq))
- omap_pm_cpu_set_freq(freq);
-#endif
+
return ret;
}
@@ -127,7 +105,7 @@ static int __init omap_cpu_init(struct cpufreq_policy
*policy)
{
int result = 0;
- mpu_clk = clk_get(NULL, MPU_CLK);
+ mpu_clk = clk_get(NULL, mpu);
if (IS_ERR(mpu_clk))
return PTR_ERR(mpu_clk);
@@ -136,13 +114,7 @@ static int __init omap_cpu_init(struct cpufreq_policy
*policy)
policy-cur = policy-min = policy-max = omap_getspeed(0);
- if (!cpu_is_omap34xx()) {
- clk_init_cpufreq_table(freq_table);
- } else {
- struct device *mpu_dev = omap2_get_mpuss_device();
-
- opp_init_cpufreq_table(mpu_dev, freq_table);
- }
+ clk_init_cpufreq_table(freq_table);
if (freq_table) {
result = cpufreq_frequency_table_cpuinfo(policy, freq_table);
@@ -184,7 +156,7 @@ static struct cpufreq_driver omap_driver = {
.get= omap_getspeed,
.init = omap_cpu_init,
.exit =
Re: [PATCH 0/2] power button repeat input events
On Mon, Mar 14, 2011 at 16:43, Denis Karpov ext-denis.2.kar...@nokia.com wrote: On Fri, Mar 11, 2011 at 10:25:27PM +0530, ext Nishanth Menon wrote: Denis Karpov wrote, on 03/11/2011 10:07 PM: Hi, this patchset adds optional generation of repeat input events for twl4030 power button. It adds optional platform data for twl4030-pwrbutton and initializes it for RX51/N900 (default behavior kept - repeated input events disabled). We are working on an OMAP3 with TWL5031 MFD. In one of the use scenarios userspace wants to receive repeated input events from long press of power button. dumb question - is'nt this a userspace responsibility as far as power button is concerned? what is the benefit of providing repeat events like a generic keypad for the power button? In our case userspace needs this to track the continuous button press of power button. thanks for your explanation, but a follow on dumb question: include/linux/input.h #define KEY_POWER 116 /* SC System Power Down */ in twl-powerbutton.c, I see: input_report_key(pwr, KEY_POWER, value PWR_PWRON_IRQ); where value is the value from the register status, should'nt we get two events? one on press and one on release after say 10 mins(assuming person keeps it pressed for 10 mins? Is there different behavior we intend to implement in userspace which differentiates 1 KEY_POWER event Vs 10 KEY_POWER event? Regards, Nishanth Menon -- 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] arm: plat-omap: iommu: fix request_mem_region() error path
request_mem_region() error exit will leak ioremapped memory. Fix this
by moving the ioremap() after request_mem_region(), which is the proper
order to do this anyway.
Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com
---
arch/arm/plat-omap/iommu.c | 14 --
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
index b1107c0..50be5e7 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -957,11 +957,6 @@ static int __devinit omap_iommu_probe(struct
platform_device *pdev)
err = -ENODEV;
goto err_mem;
}
- obj-regbase = ioremap(res-start, resource_size(res));
- if (!obj-regbase) {
- err = -ENOMEM;
- goto err_mem;
- }
res = request_mem_region(res-start, resource_size(res),
dev_name(pdev-dev));
@@ -970,6 +965,12 @@ static int __devinit omap_iommu_probe(struct
platform_device *pdev)
goto err_mem;
}
+ obj-regbase = ioremap(res-start, resource_size(res));
+ if (!obj-regbase) {
+ err = -ENOMEM;
+ goto err_ioremap;
+ }
+
irq = platform_get_irq(pdev, 0);
if (irq 0) {
err = -ENODEV;
@@ -998,8 +999,9 @@ static int __devinit omap_iommu_probe(struct
platform_device *pdev)
err_pgd:
free_irq(irq, obj);
err_irq:
- release_mem_region(res-start, resource_size(res));
iounmap(obj-regbase);
+err_ioremap:
+ release_mem_region(res-start, resource_size(res));
err_mem:
clk_put(obj-clk);
err_clk:
--
1.5.6.5
--
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] arm: plat-omap: iommu: fix request_mem_region() error path
Hi Aaro, From: Aaro Koskinen aaro.koski...@nokia.com Subject: [PATCH] arm: plat-omap: iommu: fix request_mem_region() error path Date: Mon, 14 Mar 2011 14:28:32 +0200 request_mem_region() error exit will leak ioremapped memory. Fix this by moving the ioremap() after request_mem_region(), which is the proper order to do this anyway. Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com --- arch/arm/plat-omap/iommu.c | 14 -- 1 files changed, 8 insertions(+), 6 deletions(-) True. Thank you for catching this. -- 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: alsa-soc: Remove restrictive check for cpu type
Current check for cpu type is too restrictive leading to
failures for other silicons in same family.
The problem was found while testing audio playback on
AM37x and AM35x processors. But should exist on OMAP36xx
as well.
Signed-off-by: Sanjeev Premi pr...@ti.com
---
sound/soc/omap/omap-mcbsp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 2175f09..84d434a 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -146,7 +146,7 @@ static int omap_mcbsp_dai_startup(struct snd_pcm_substream
*substream,
* 2 channels (stereo): size is 128 / 2 = 64 frames (2 * 64 words)
* 4 channels: size is 128 / 4 = 32 frames (4 * 32 words)
*/
- if (cpu_is_omap343x() || cpu_is_omap44xx()) {
+ if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
/*
* Rule for the buffer size. We should not allow
* smaller buffer than the FIFO size to avoid underruns
--
1.7.2.2
--
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] omap3: alsa-soc: Remove restrictive check for cpu type
On Mon, 14 Mar 2011 19:01:53 +0530 Sanjeev Premi pr...@ti.com wrote: Current check for cpu type is too restrictive leading to failures for other silicons in same family. The problem was found while testing audio playback on AM37x and AM35x processors. But should exist on OMAP36xx as well. Signed-off-by: Sanjeev Premi pr...@ti.com --- sound/soc/omap/omap-mcbsp.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) There are two other cpu_is_omap343x tests as well. Care to check them too? -- Jarkko -- 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] omap3: alsa-soc: Remove restrictive check for cpu type
On Mon, 14 Mar 2011 15:55:42 +0200 Jarkko Nikula jhnik...@gmail.com wrote: On Mon, 14 Mar 2011 19:01:53 +0530 Sanjeev Premi pr...@ti.com wrote: Current check for cpu type is too restrictive leading to failures for other silicons in same family. The problem was found while testing audio playback on AM37x and AM35x processors. But should exist on OMAP36xx as well. Signed-off-by: Sanjeev Premi pr...@ti.com --- sound/soc/omap/omap-mcbsp.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) There are two other cpu_is_omap343x tests as well. Care to check them too? Sorry, only one additional test. I forgot the commit 2686e07 ASoC: McBSP: get hw params from McBSP driver that is coming via linux-omap and which removes one test. -- Jarkko -- 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] omap3: alsa-soc: Remove restrictive check for cpu type
-Original Message- From: Jarkko Nikula [mailto:jhnik...@gmail.com] Sent: Monday, March 14, 2011 7:31 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org; alsa-de...@alsa-project.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH] omap3: alsa-soc: Remove restrictive check for cpu type On Mon, 14 Mar 2011 15:55:42 +0200 Jarkko Nikula jhnik...@gmail.com wrote: On Mon, 14 Mar 2011 19:01:53 +0530 Sanjeev Premi pr...@ti.com wrote: Current check for cpu type is too restrictive leading to failures for other silicons in same family. The problem was found while testing audio playback on AM37x and AM35x processors. But should exist on OMAP36xx as well. Signed-off-by: Sanjeev Premi pr...@ti.com --- sound/soc/omap/omap-mcbsp.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) There are two other cpu_is_omap343x tests as well. Care to check them too? Sorry, only one additional test. I forgot the commit 2686e07 ASoC: McBSP: get hw params from McBSP driver that is coming via linux-omap and which removes one test. Checking now... ~sanjeev -- Jarkko -- 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] omap3: alsa-soc: Remove restrictive check for cpu type
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Premi, Sanjeev Sent: Monday, March 14, 2011 7:47 PM To: Jarkko Nikula Cc: linux-omap@vger.kernel.org; alsa-de...@alsa-project.org; linux-arm-ker...@lists.infradead.org Subject: RE: [PATCH] omap3: alsa-soc: Remove restrictive check for cpu type -Original Message- From: Jarkko Nikula [mailto:jhnik...@gmail.com] Sent: Monday, March 14, 2011 7:31 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org; alsa-de...@alsa-project.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH] omap3: alsa-soc: Remove restrictive check for cpu type On Mon, 14 Mar 2011 15:55:42 +0200 Jarkko Nikula jhnik...@gmail.com wrote: On Mon, 14 Mar 2011 19:01:53 +0530 Sanjeev Premi pr...@ti.com wrote: Current check for cpu type is too restrictive leading to failures for other silicons in same family. The problem was found while testing audio playback on AM37x and AM35x processors. But should exist on OMAP36xx as well. Signed-off-by: Sanjeev Premi pr...@ti.com --- sound/soc/omap/omap-mcbsp.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) There are two other cpu_is_omap343x tests as well. Care to check them too? Sorry, only one additional test. I forgot the commit 2686e07 ASoC: McBSP: get hw params from McBSP driver that is coming via linux-omap and which removes one test. Checking now... Other check shouldn't be there are well... Had asked someone (off-this -list) to help me test the change - but seems to be in todo. Will test it myself and post updated patch today... ~sanjeev -- Jarkko -- 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
[PATCH] omap: zoom: host should not pull up wl1271's irq line
The wl1271's irq line is completely controlled by the 1271 device, and
the host does not not need to pull it up.
While there's no functional effect, letting the host pull this line up is
just redundant, and wastes power.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/mach-omap2/board-zoom.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom.c b/arch/arm/mach-omap2/board-zoom.c
index e26754c..c59d07b 100644
--- a/arch/arm/mach-omap2/board-zoom.c
+++ b/arch/arm/mach-omap2/board-zoom.c
@@ -49,7 +49,7 @@ static void __init omap_zoom_init_irq(void)
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
/* WLAN IRQ - GPIO 162 */
- OMAP3_MUX(MCBSP1_CLKX, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(MCBSP1_CLKX, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
/* WLAN POWER ENABLE - GPIO 101 */
OMAP3_MUX(CAM_D2, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
/* WLAN SDIO: MMC3 CMD */
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] power button repeat input events
On Mon, Mar 14, 2011 at 05:10:22PM +0530, ext Menon, Nishanth wrote: Date: Mon, 14 Mar 2011 17:10:22 +0530 From: ext Menon, Nishanth n...@ti.com To: Denis Karpov ext-denis.2.kar...@nokia.com CC: t...@atomide.com, linux-omap@vger.kernel.org Subject: Re: [PATCH 0/2] power button repeat input events In-Reply-To: 20110314111327.ga10...@smart.research.nokia.com On Mon, Mar 14, 2011 at 16:43, Denis Karpov ext-denis.2.kar...@nokia.com wrote: On Fri, Mar 11, 2011 at 10:25:27PM +0530, ext Nishanth Menon wrote: Denis Karpov wrote, on 03/11/2011 10:07 PM: Hi, this patchset adds optional generation of repeat input events for twl4030 power button. It adds optional platform data for twl4030-pwrbutton and initializes it for RX51/N900 (default behavior kept - repeated input events disabled). We are working on an OMAP3 with TWL5031 MFD. In one of the use scenarios userspace wants to receive repeated input events from long press of power button. dumb question - is'nt this a userspace responsibility as far as power button is concerned? what is the benefit of providing repeat events like a generic keypad for the power button? In our case userspace needs this to track the continuous button press of power button. thanks for your explanation, but a follow on dumb question: include/linux/input.h #define KEY_POWER 116 /* SC System Power Down */ in twl-powerbutton.c, I see: input_report_key(pwr, KEY_POWER, value PWR_PWRON_IRQ); where value is the value from the register status, should'nt we get two events? one on press and one on release after say 10 mins(assuming person keeps it pressed for 10 mins? Is there different behavior we intend to implement in userspace which differentiates 1 KEY_POWER event Vs 10 KEY_POWER event? No, but due to specifics of userspace sw components involved it seems not to be possible to reliably save the state for power button to detect long keypresses. I thought that this change if implemented as optional feature and localized to scpecific devices/boards would not hurt. twl-keypad.c implements exactly same behavior for keypad keys, why not to do this for the power key ? Denis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] power button repeat input events
Denis Karpov wrote, on 03/14/2011 08:05 PM: On Mon, Mar 14, 2011 at 05:10:22PM +0530, ext Menon, Nishanth wrote: Date: Mon, 14 Mar 2011 17:10:22 +0530 From: ext Menon, Nishanthn...@ti.com To: Denis Karpovext-denis.2.kar...@nokia.com CC: t...@atomide.com, linux-omap@vger.kernel.org Subject: Re: [PATCH 0/2] power button repeat input events In-Reply-To:20110314111327.ga10...@smart.research.nokia.com On Mon, Mar 14, 2011 at 16:43, Denis Karpov ext-denis.2.kar...@nokia.com wrote: On Fri, Mar 11, 2011 at 10:25:27PM +0530, ext Nishanth Menon wrote: Denis Karpov wrote, on 03/11/2011 10:07 PM: Hi, this patchset adds optional generation of repeat input events for twl4030 power button. It adds optional platform data for twl4030-pwrbutton and initializes it for RX51/N900 (default behavior kept - repeated input events disabled). We are working on an OMAP3 with TWL5031 MFD. In one of the use scenarios userspace wants to receive repeated input events from long press of power button. dumb question - is'nt this a userspace responsibility as far as power button is concerned? what is the benefit of providing repeat events like a generic keypad for the power button? In our case userspace needs this to track the continuous button press of power button. thanks for your explanation, but a follow on dumb question: include/linux/input.h #define KEY_POWER 116 /* SC System Power Down */ in twl-powerbutton.c, I see: input_report_key(pwr, KEY_POWER, value PWR_PWRON_IRQ); where value is the value from the register status, should'nt we get two events? one on press and one on release after say 10 mins(assuming person keeps it pressed for 10 mins? Is there different behavior we intend to implement in userspace which differentiates 1 KEY_POWER event Vs 10 KEY_POWER event? No, but due to specifics of userspace sw components involved it seems not to be possible to reliably save the state for power button to detect long keypresses. I thought that this change if implemented as optional feature and localized to scpecific devices/boards would not hurt. twl-keypad.c implements exactly same behavior for keypad keys, why not to do this for the power key ? Are'nt the key events different? KEY_POWER is meant to shutdown the system if my reading is right (other keys need repeatability) - I mean trying to add a feature because userspace handling is flawed in some manner makes me wonder if we are moving the code to kernelspace because it is convenient? I have no debates about just the board in question using this, but just worried if we are taking a hack for userspace in kernel given that no other board or other userspace variants had a necessity for this change previously. -- Regards, Nishanth Menon -- 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] staging: tidspbridge: protect dmm_map properly
g...@kroah.com wrote: On Sun, Mar 13, 2011 at 01:42:35AM +0200, Felipe Contreras wrote: On Sat, Mar 12, 2011 at 7:36 PM, Greg KH g...@kroah.com wrote: How about I send it to Linus for .39 and then add it to the .38-stable tree when it comes out? That was the plan for .38/.37-stable. I'd say that's fine, but it would be even better to avoid people getting bit by this on plain .38. What is one more week, when you all waited months to get this to me? In other words, why should I suddenly now rush when no one else did? The reason is because it didn't seem like it was happening often, but in Tuomas' case, it does so much it's basically unusable. So _now_ we know this could have possibly been affecting many people we didn't know about. You have to remember that this driver only started to work on .37, so people might have tried it, seen it crashing and said oh well, it's on 'staging' for a reason, having no point of reference that would be a valid conclusion, while in fact this is a regression from pre-staging (the issue wasn't there). Anyway, I don't think .38.1 is going to be released in one week, but I guess if people are having issues and not reporting them, they can wait more. Cheers. -- Felipe Contreras -- 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] staging: tidspbridge: protect dmm_map properly
On Mon, Mar 14, 2011 at 05:33:09PM +0200, Felipe Contreras wrote: g...@kroah.com wrote: On Sun, Mar 13, 2011 at 01:42:35AM +0200, Felipe Contreras wrote: On Sat, Mar 12, 2011 at 7:36 PM, Greg KH g...@kroah.com wrote: How about I send it to Linus for .39 and then add it to the .38-stable tree when it comes out? That was the plan for .38/.37-stable. I'd say that's fine, but it would be even better to avoid people getting bit by this on plain .38. What is one more week, when you all waited months to get this to me? In other words, why should I suddenly now rush when no one else did? The reason is because it didn't seem like it was happening often, but in Tuomas' case, it does so much it's basically unusable. So _now_ we know this could have possibly been affecting many people we didn't know about. You have to remember that this driver only started to work on .37, so people might have tried it, seen it crashing and said oh well, it's on 'staging' for a reason, having no point of reference that would be a valid conclusion, while in fact this is a regression from pre-staging (the issue wasn't there). I understand you feeling like there is a rush here, but again, please recognize that we all have different priorities. The number of users out there using this driver is very small and again, this patch can safely wait until the first .38-stable release comes out. Anyway, I don't think .38.1 is going to be released in one week, Is that a challenge? :) but I guess if people are having issues and not reporting them, they can wait more. Thanks, I think they can. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: hwmod: add syss reset done flags to omap2, omap3 hwmods
On Thu, Mar 03, 2011 at 02:28:21PM -0700, Paul Walmsley wrote: On Thu, 24 Feb 2011, Avinash.H.M wrote: Some of the omap2, omap3 peripherals support software reset. This can be done through the softreset bit in sysconfig register. The reset status can be checked through resetdone bit of sysstatus register. syss_has_reset_status is added to the hwmod database of peripherals which have resetdone bit in sysstatus register. Cc: Rajendra Nayak rna...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Benoit Cousson b-cous...@ti.com Cc: Kevin Hilman khil...@ti.com Reviewed-by: Govindraj.R govindraj.r...@ti.com Signed-off-by: Avinash.H.M avinas...@ti.com Thanks, queued for 2.6.39. Thanks very much Paul. br - avinash - Paul -- 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 2/2] omap4: mux: Remove duplicate mux modes
* Cousson, Benoit b-cous...@ti.com [110314 01:39]:
Hi Tony,
On 3/11/2011 9:34 PM, Tony Lindgren wrote:
Remove duplicate mux modes to make the binary smaller:
textdata bss dec hex filename
9378 24472 0 33850843a mux44xx.o
9378 19104 0 284826f42 mux44xx.o
Cc: Benoit Coussonb-cous...@ti.com
Signed-off-by: Tony Lindgrent...@atomide.com
---
arch/arm/mach-omap2/mux44xx.c | 282
+
1 files changed, 6 insertions(+), 276 deletions(-)
diff --git a/arch/arm/mach-omap2/mux44xx.c b/arch/arm/mach-omap2/mux44xx.c
index c322e7b..9a66445 100644
--- a/arch/arm/mach-omap2/mux44xx.c
+++ b/arch/arm/mach-omap2/mux44xx.c
@@ -755,25 +755,9 @@ static struct omap_ball __initdata
omap4_core_cbl_ball[] = {
#endif
/*
- * Superset of all mux modes for omap4 ES2.0
+ * Signals different on ES2.0 compared to superset
I didn't do it originally due to the huge amount of differences
between the two versions and the impact at runtime it will imply to
fix the modified entries at boot time. It might still be interesting
to measure it.
A quick test shows the difference is 0.007324218 - 0.007202148 seconds.. :)
Since ES1 is no longer used on any board except the early one, that
you probably still have :-), it might be better to consider ES2 as
the superset and then store ES1 diff as the subset. It will avoid
any performance impact for the latest devices.
Well the performance impact is minimal in this case. But from cutting
down the size point of view that makes sense as then we could later on
optionally compile out OMAP_PACKAGE_CBL.
Sounds like that's a separate incremental patch on top of this one
though.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v12 4/9] OMAP2+: dmtimer: convert to platform devices
* Kevin Hilman khil...@ti.com [110311 16:00]: Tony Lindgren t...@atomide.com writes: * DebBarma, Tarun Kanti tarun.ka...@ti.com [110310 20:18]: From: Hilman, Kevin I guess Tony has the final say here, but personally, I don't really like the special treatment of a system timer, unless it is an init-time only special treatment. Since we now have dynamically configurable clocksources, the concept of a system timer doesn't really exist (except for in early boot.) At any time during runtime, we could dynamically switch the clocksource to a different timer device. At this point, one would expect runtime PM for the previous timer to kick in and idle the timer. That cannot happen with this approach. I am open to suggestions. There's no need to dynamically change the clocksource. We can to set up things so we have a system timer running with minimal code and faster clock rate. Then we can use a separate timer with the 32KiHZ source just to provide wake-up events for idle modes. And this second wake-up timer can be just a regular device driver. The system timer code needs to be fast. And I don't want to add any dependencies to anything except clock framework. Like I've said, the rest of the timers can be just a regular device driver. There are a couple problems with this approach. The special case handling of a system timer leads to duplicate code (this series is a good example.) I think the related inline functions can be shared. The other problem is PM. If we switch away from the original system timer (for whatever reason), since it is not a regular device, it will not have runtime PM We'll then need special case PM code for the system timer, which I think is wasted effort. This should not cause problems either, there should not be any need to switch the timers in the setup what I'm thinking. In the long run, think local timer for runtime, and then wakeup timer that gets only programmed when we enter idle. The local timer will continue operating normally after we wake-up and the wakeup timer will be just one shot event. Of course in the omap[23] case the local timer is really a faster dmtimer, but in the omap4+ case there's are real local timers. If this can be done such that the system timer is eventually a regular device driver, then that should be fine. In this setup there should not be need to mess with the system timer after boot as we don't need to switch clock sources. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] omap4: mux: Remove duplicate mux modes
On 3/14/2011 5:59 PM, Tony Lindgren wrote:
* Cousson, Benoitb-cous...@ti.com [110314 01:39]:
Hi Tony,
On 3/11/2011 9:34 PM, Tony Lindgren wrote:
Remove duplicate mux modes to make the binary smaller:
textdata bss dec hex filename
9378 24472 0 33850843a mux44xx.o
9378 19104 0 284826f42 mux44xx.o
Cc: Benoit Coussonb-cous...@ti.com
Signed-off-by: Tony Lindgrent...@atomide.com
---
arch/arm/mach-omap2/mux44xx.c | 282 +
1 files changed, 6 insertions(+), 276 deletions(-)
diff --git a/arch/arm/mach-omap2/mux44xx.c b/arch/arm/mach-omap2/mux44xx.c
index c322e7b..9a66445 100644
--- a/arch/arm/mach-omap2/mux44xx.c
+++ b/arch/arm/mach-omap2/mux44xx.c
@@ -755,25 +755,9 @@ static struct omap_ball __initdata omap4_core_cbl_ball[] =
{
#endif
/*
- * Superset of all mux modes for omap4 ES2.0
+ * Signals different on ES2.0 compared to superset
I didn't do it originally due to the huge amount of differences
between the two versions and the impact at runtime it will imply to
fix the modified entries at boot time. It might still be interesting
to measure it.
A quick test shows the difference is 0.007324218 - 0.007202148 seconds.. :)
Whaoo, 122us, that chip is really fast :-)
Since ES1 is no longer used on any board except the early one, that
you probably still have :-), it might be better to consider ES2 as
the superset and then store ES1 diff as the subset. It will avoid
any performance impact for the latest devices.
Well the performance impact is minimal in this case. But from cutting
down the size point of view that makes sense as then we could later on
optionally compile out OMAP_PACKAGE_CBL.
Sounds like that's a separate incremental patch on top of this one
though.
OK, I'll try to make that for 2.6.40.
Benoit
--
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 2 00/18] I2C: OMAP: Fixes and removal of cpu_... from driver
Hi Ben Andy, * Tony Lindgren t...@atomide.com [110309 11:09]: * Cousson, Benoit b-cous...@ti.com [110309 06:00]: Hi Tony, On 3/9/2011 12:38 AM, Tony Lindgren wrote: * Cousson, Benoitb-cous...@ti.com [110308 13:34]: Hi Andy, Thanks for that really fast update. That looks pretty good at first glance. I still have to review in details. Yes nice job! And we need to find some volunteers for OMAP1 2 testing. I gave it a quick try on osk5912, seems to work just fine. Will apply these for testing purposes to linux-omap tree while waiting for the minor fixes. Looks like Benoit should take the arch/arm/*omap*/*hwmod* patches, the rest should go throug Ben. So for all of them: Paul and I already acked the hwmod data, but the whole series should maybe go through Ben, because the hwmod files will need some defines added in the i2c header file. So we cannot separate the hwmod* patches from the driver files patches. Unfortunately the hwmod patches depend on omap-for-linus branch.. Considering this, it's probably best that I queue the whole series assuming we get acks from Ben for the driver related changes. After looking at this again, I've changed my mind. It looks like this series can be rebased on v2.6.38-rc8 and should merge just fine with what we have queued in omap-for-linus. I guess I forgot we already did the i2c-omap hwmod conversion last merge window :) Andy, please repost the related patches against v2.6.38-rc8 with the acks posted earlier. Then Ben, please feel free to queue it after you get the rebased series. We've had this series applied for testing for a while. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2 00/18] I2C: OMAP: Fixes and removal of cpu_... from driver
On 03/14/2011 05:42 PM, Somebody in the thread at some point said: Hi - It looks like this series can be rebased on v2.6.38-rc8 and should merge just fine with what we have queued in omap-for-linus. I guess I forgot we already did the i2c-omap hwmod conversion last merge window :) Andy, please repost the related patches against v2.6.38-rc8 with the acks posted earlier. Alright, I will do that with the reordered patch from Benoit and the change to BIT() instead of constants. Thanks. -Andy -- 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] arm: plat-omap: iommu: fix request_mem_region() error path
* Hiroshi DOYU hiroshi.d...@nokia.com [110314 05:50]: Hi Aaro, From: Aaro Koskinen aaro.koski...@nokia.com Subject: [PATCH] arm: plat-omap: iommu: fix request_mem_region() error path Date: Mon, 14 Mar 2011 14:28:32 +0200 request_mem_region() error exit will leak ioremapped memory. Fix this by moving the ioremap() after request_mem_region(), which is the proper order to do this anyway. Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com --- arch/arm/plat-omap/iommu.c | 14 -- 1 files changed, 8 insertions(+), 6 deletions(-) True. Thank you for catching this. Applying. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: zoom: host should not pull up wl1271's irq line
* Ohad Ben-Cohen o...@wizery.com [110314 07:29]: The wl1271's irq line is completely controlled by the 1271 device, and the host does not not need to pull it up. While there's no functional effect, letting the host pull this line up is just redundant, and wastes power. Applying. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 3/5] OMAP2+:Common CPU DIE ID reading code reads wrong registers for OMAP4430
* Andy Green a...@warmcat.com [110312 14:49]: This adapts the register offsets used to read the CPU DIE ID registers when run on 44XX so they match what is in the OMAP4430 Reference Manual page 269 I'll apply only this patch, looks like the rest needs more discussion. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GPIO chip select support in McSPI
On Sun, Mar 13, 2011 at 03:04:11PM -0400, Ben Gamari wrote: I've included the OMAP list so that I can hopefully get some feedback from folks more familiar with this code. Background: I've been working on adding support for GPIO chip select lines to the McSPI driver. Grant has been working with me to try getting the in-kernel interface right and we have finally converged on a solution whereby a table of GPIO lines will be passed to the McSPI driver through platform_device.device.platform_data. Unfortunately, as explained below, there is no clear path to support this in the current McSPI initialization code. On Thu, 03 Mar 2011 14:42:07 -0700, Grant Likely grant.lik...@secretlab.ca wrote: The spi_master platform device is registered somewhere in the inappropriate support code. You need to arrange to make sure the correct pdata is attached to it when it gets registered. There /should/ be a mechanism for doing so. All spi devices already specify a cs number anyway. What you can do is use the cs number as the lookup index into the gpio table, and remember to reserve a cs# for the 'native' cs line. I've done as you suggested and added support to the McSPI driver by passing a GPIO table through platform_data. A patch will be coming shortly. Unfortunately, I'm really not sure how to restructure the OMAP code to pass this information along. Currently the McSPI devices are registered in arch/arm/mach-omap2/devices.c (omap_init_mcspi). In order to make the GPIO CS support configurable by board code, we need some way to change the (currently static) platform_devices prior to registration. Does anyone have any suggestions on how this code could be refactored to allow for this with minimal code duplication? Obviously we could just move the platform_devices into the board files but this seems like a lot of code duplication to support functionality that few boards will use. I see two solutions: 1) platform code registers a bus notifier so that it gets called back before the device gets bound to a driver. Then it can augment the platform data. 2) add an api to arch/arm/mach-omap2/devices.c for providing a cs table before the device gets registered (must be called before arch_initcall() time). g. -- 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
Code for v2.6.39 merge window frozen, patches archived
Hi all, I've applied few random fix like patches today into omap-for-linus but that's it for this merge window. So let's do some testing with with Stephen's for-next and omap-for-linus and start queueing up fixes for the -rc cycle. I've also moved all the patchwork.kernel.org patches into archived-v2.6.39 bundle and marked them as archived: https://patchwork.kernel.org/user/bundle/1381/ You can still find the patches there if you click on Filters and changed Archived from No to Both. Looks like there's one smartreflex patch that does not seem to exist in patchwork though.. So that one is still lurking around on the patchwork list of patches until the issue has been fixed in patchwork.kernel.org. Cheers, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] OMAP3: wdtimer: Fix CORE idle transition
Hello Kalle, On Mon, 14 Mar 2011, kalle.jokini...@nokia.com wrote: What about the 1/2 patch? Is that going in, and to which kernel version (our integrator would like to put in a note when we can remove the back ported patch) It's queued for Linus for the upcoming merge window: http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=0503add9d251db22ba2f610fb8d9b7743a9786da Thread here: http://www.spinics.net/lists/linux-omap/msg48381.html If there aren't further comments on the watchdog patch, and Linus is okay with the branch, it should appear in 2.6.39. - Paul -- 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] mcspi: Add support for GPIO chip select lines
On Sun, Mar 13, 2011 at 03:05:19PM -0400, Ben Gamari wrote:
Many applications require more chip select lines than the board or
processor allow. Introduce a mechanism to allow use of GPIO pins as
chip select lines with the McSPI controller. To use this functionality,
one simply provides a table mapping CS line numbers to GPIO numbers in
omap2_mcspi_platform_config.cs_gpios.
Signed-off-by: Ben Gamari bgamari.f...@gmail.com
---
arch/arm/plat-omap/include/plat/mcspi.h |3 ++-
drivers/spi/omap2_mcspi.c | 15 ++-
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mcspi.h
b/arch/arm/plat-omap/include/plat/mcspi.h
index 1254e49..cac1d84 100644
--- a/arch/arm/plat-omap/include/plat/mcspi.h
+++ b/arch/arm/plat-omap/include/plat/mcspi.h
@@ -2,7 +2,8 @@
#define _OMAP2_MCSPI_H
struct omap2_mcspi_platform_config {
- unsigned short num_cs;
+ unsigned short num_cs;
+ int *cs_gpios;
};
struct omap2_mcspi_device_config {
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index abb1ffb..59cbed4 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -35,6 +35,7 @@
#include linux/slab.h
#include linux/spi/spi.h
+#include linux/gpio.h
#include plat/dma.h
#include plat/clock.h
@@ -235,11 +236,15 @@ static void omap2_mcspi_set_enable(const struct
spi_device *spi, int enable)
static void omap2_mcspi_force_cs(struct spi_device *spi, int cs_active)
{
- u32 l;
-
- l = mcspi_cached_chconf0(spi);
- MOD_REG_BIT(l, OMAP2_MCSPI_CHCONF_FORCE, cs_active);
- mcspi_write_chconf0(spi, l);
+ struct omap2_mcspi_platform_config *pconfig =
spi-master-dev.platform_data;
+ if (pconfig-cs_gpios) {
+ int gpio = pconfig-cs_gpios[spi-chip_select];
+ gpio_set_value(gpio, cs_active);
+ } else {
+ u32 l = mcspi_cached_chconf0(spi);
+ MOD_REG_BIT(l, OMAP2_MCSPI_CHCONF_FORCE, cs_active);
+ mcspi_write_chconf0(spi, l);
+ }
What if the board wanted to use both the native SPI ss line as well as
one or more GPIOs? You probably want to reserve cs0 for the native
gpio line.
Otherwise this patch looks good to me.
g.
--
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: [GIT PULL] OMAP PM updates for 2.6.39
Hi, Am 11.03.2011 01:59, schrieb Kevin Hilman: Dave Martin (5): ARM: omap4: Provide do_wfi() for Thumb-2 ARM: omap4: Convert END() to ENDPROC() for correct linkage with CONFIG_THUMB2_KERNEL ARM: omap3: Remove hand-encoded SMC instructions ARM: omap3: Remove hand-encoded SMC instructions fails for me with: /home/stephan/projects/openelec/build.OpenELEC-panda.arm-devel/toolchain/bin/arm-openelec-linux-gnueabi-gcc -Wp,-MD,arch/arm/mach-omap2/.sleep34xx.o.d -nostdinc -isystem /home/stephan/projects/openelec/build.OpenELEC-panda.arm-devel/toolchain/lib/gcc/arm-openelec-linux-gnueabi/4.5.2/include -I/home/stephan/projects/openelec/build.OpenELEC-panda.arm-devel/linux-2.6.38-rc8/arch/arm/include -Iinclude -include include/generated/autoconf.h -D__KERNEL__ -mlittle-endian -Iarch/arm/mach-omap2/include -Iarch/arm/plat-omap/include -D__ASSEMBLY__ -mabi=aapcs-linux -mno-thumb-interwork -funwind-tables -mthumb -Wa,-mimplicit-it=always -Wa,-mno-warn-deprecated -Wa,-mthumb -D__LINUX_ARM_ARCH__=7 -march=armv7-a -include asm/unified.h -msoft-float -gdwarf-2 -Wa,-march=armv7-a -c -o arch/arm/mach-omap2/sleep34xx.o arch/arm/mach-omap2/sleep34xx.S arch/arm/mach-omap2/sleep34xx.S: Assembler messages: arch/arm/mach-omap2/sleep34xx.S:149: Error: selected processor does not support ARM mode `smc #1' arch/arm/mach-omap2/sleep34xx.S:416: Error: selected processor does not support ARM mode `smc #1' arch/arm/mach-omap2/sleep34xx.S:427: Error: selected processor does not support ARM mode `smc #1' arch/arm/mach-omap2/sleep34xx.S:452: Error: selected processor does not support ARM mode `smc #0' arch/arm/mach-omap2/sleep34xx.S:458: Error: selected processor does not support ARM mode `smc #0' arch/arm/mach-omap2/sleep34xx.S:463: Error: selected processor does not support ARM mode `smc #0' make[2]: *** [arch/arm/mach-omap2/sleep34xx.o] Error 1 make[1]: *** [arch/arm/mach-omap2] Error 2 replacing in arch/arm/mach-omap2/Makefile: AFLAGS_sleep24xx.o :=-Wa,-march=armv6 AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a to: AFLAGS_sleep24xx.o :=-Wa,-march=armv6 AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a$(plus_sec) helps compiling (see also: https://patchwork.kernel.org/patch/369681/) thanks Stephan -- 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: [GIT PULL] OMAP PM updates for 2.6.39
* Stephan Raue mailingli...@openelec.tv [110314 12:32]: Hi, Am 11.03.2011 01:59, schrieb Kevin Hilman: Dave Martin (5): ARM: omap4: Provide do_wfi() for Thumb-2 ARM: omap4: Convert END() to ENDPROC() for correct linkage with CONFIG_THUMB2_KERNEL ARM: omap3: Remove hand-encoded SMC instructions ARM: omap3: Remove hand-encoded SMC instructions fails for me with: /home/stephan/projects/openelec/build.OpenELEC-panda.arm-devel/toolchain/bin/arm-openelec-linux-gnueabi-gcc -Wp,-MD,arch/arm/mach-omap2/.sleep34xx.o.d -nostdinc -isystem /home/stephan/projects/openelec/build.OpenELEC-panda.arm-devel/toolchain/lib/gcc/arm-openelec-linux-gnueabi/4.5.2/include -I/home/stephan/projects/openelec/build.OpenELEC-panda.arm-devel/linux-2.6.38-rc8/arch/arm/include -Iinclude -include include/generated/autoconf.h -D__KERNEL__ -mlittle-endian -Iarch/arm/mach-omap2/include -Iarch/arm/plat-omap/include -D__ASSEMBLY__ -mabi=aapcs-linux -mno-thumb-interwork -funwind-tables -mthumb -Wa,-mimplicit-it=always -Wa,-mno-warn-deprecated -Wa,-mthumb -D__LINUX_ARM_ARCH__=7 -march=armv7-a -include asm/unified.h -msoft-float -gdwarf-2 -Wa,-march=armv7-a -c -o arch/arm/mach-omap2/sleep34xx.o arch/arm/mach-omap2/sleep34xx.S arch/arm/mach-omap2/sleep34xx.S: Assembler messages: arch/arm/mach-omap2/sleep34xx.S:149: Error: selected processor does not support ARM mode `smc #1' arch/arm/mach-omap2/sleep34xx.S:416: Error: selected processor does not support ARM mode `smc #1' arch/arm/mach-omap2/sleep34xx.S:427: Error: selected processor does not support ARM mode `smc #1' arch/arm/mach-omap2/sleep34xx.S:452: Error: selected processor does not support ARM mode `smc #0' arch/arm/mach-omap2/sleep34xx.S:458: Error: selected processor does not support ARM mode `smc #0' arch/arm/mach-omap2/sleep34xx.S:463: Error: selected processor does not support ARM mode `smc #0' make[2]: *** [arch/arm/mach-omap2/sleep34xx.o] Error 1 make[1]: *** [arch/arm/mach-omap2] Error 2 replacing in arch/arm/mach-omap2/Makefile: AFLAGS_sleep24xx.o :=-Wa,-march=armv6 AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a to: AFLAGS_sleep24xx.o :=-Wa,-march=armv6 AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a$(plus_sec) helps compiling (see also: https://patchwork.kernel.org/patch/369681/) Care to post a patch for this and mention your compiler version too? Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] OMAP PM updates for 2.6.39
Am 14.03.2011 20:38, schrieb Tony Lindgren: * Stephan Rauemailingli...@openelec.tv [110314 12:32]: Hi, Am 11.03.2011 01:59, schrieb Kevin Hilman: Dave Martin (5): ARM: omap4: Provide do_wfi() for Thumb-2 ARM: omap4: Convert END() to ENDPROC() for correct linkage with CONFIG_THUMB2_KERNEL ARM: omap3: Remove hand-encoded SMC instructions ARM: omap3: Remove hand-encoded SMC instructions fails for me with: /home/stephan/projects/openelec/build.OpenELEC-panda.arm-devel/toolchain/bin/arm-openelec-linux-gnueabi-gcc -Wp,-MD,arch/arm/mach-omap2/.sleep34xx.o.d -nostdinc -isystem /home/stephan/projects/openelec/build.OpenELEC-panda.arm-devel/toolchain/lib/gcc/arm-openelec-linux-gnueabi/4.5.2/include -I/home/stephan/projects/openelec/build.OpenELEC-panda.arm-devel/linux-2.6.38-rc8/arch/arm/include -Iinclude -include include/generated/autoconf.h -D__KERNEL__ -mlittle-endian -Iarch/arm/mach-omap2/include -Iarch/arm/plat-omap/include -D__ASSEMBLY__ -mabi=aapcs-linux -mno-thumb-interwork -funwind-tables -mthumb -Wa,-mimplicit-it=always -Wa,-mno-warn-deprecated -Wa,-mthumb -D__LINUX_ARM_ARCH__=7 -march=armv7-a -include asm/unified.h -msoft-float -gdwarf-2 -Wa,-march=armv7-a -c -o arch/arm/mach-omap2/sleep34xx.o arch/arm/mach-omap2/sleep34xx.S arch/arm/mach-omap2/sleep34xx.S: Assembler messages: arch/arm/mach-omap2/sleep34xx.S:149: Error: selected processor does not support ARM mode `smc #1' arch/arm/mach-omap2/sleep34xx.S:416: Error: selected processor does not support ARM mode `smc #1' arch/arm/mach-omap2/sleep34xx.S:427: Error: selected processor does not support ARM mode `smc #1' arch/arm/mach-omap2/sleep34xx.S:452: Error: selected processor does not support ARM mode `smc #0' arch/arm/mach-omap2/sleep34xx.S:458: Error: selected processor does not support ARM mode `smc #0' arch/arm/mach-omap2/sleep34xx.S:463: Error: selected processor does not support ARM mode `smc #0' make[2]: *** [arch/arm/mach-omap2/sleep34xx.o] Error 1 make[1]: *** [arch/arm/mach-omap2] Error 2 replacing in arch/arm/mach-omap2/Makefile: AFLAGS_sleep24xx.o :=-Wa,-march=armv6 AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a to: AFLAGS_sleep24xx.o :=-Wa,-march=armv6 AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a$(plus_sec) helps compiling (see also: https://patchwork.kernel.org/patch/369681/) Care to post a patch for this and mention your compiler version too? Tony patch attached. i am using http://gitorious.org/linux-omap-dss2/linux with gcc-4.5.2, binutils-2.21 thanks Stephan diff -Naur linux-2.6.38-rc8/arch/arm/mach-omap2/Makefile linux-2.6.38-rc8.patch/arch/arm/mach-omap2/Makefile --- linux-2.6.38-rc8/arch/arm/mach-omap2/Makefile 2011-03-14 20:38:21.039926899 +0100 +++ linux-2.6.38-rc8.patch/arch/arm/mach-omap2/Makefile 2011-03-14 20:39:01.679108209 +0100 @@ -68,7 +68,7 @@ obj-$(CONFIG_OMAP_SMARTREFLEX_CLASS3) += smartreflex-class3.o AFLAGS_sleep24xx.o :=-Wa,-march=armv6 -AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a +AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a$(plus_sec) ifeq ($(CONFIG_PM_VERBOSE),y) CFLAGS_pm_bus.o+= -DDEBUG
Re: [Security] [PATCH 00/20] world-writable files in sysfs and debugfs
On Sat, 12 Mar 2011 23:23:06 +0300 Vasiliy Kulikov seg...@openwall.com wrote: Vasiliy Kulikov (20): mach-ux500: mbox-db5500: world-writable sysfs fifo file leds: lp5521: world-writable sysfs engine* files leds: lp5523: world-writable engine* sysfs files misc: ep93xx_pwm: world-writable sysfs files rtc: rtc-ds1511: world-writable sysfs nvram file scsi: aic94xx: world-writable sysfs update_bios file scsi: iscsi: world-writable sysfs priv_sess file These are still not merged :( I grabbed them and shall merge some and send others at relevant maintainers, thanks. -- 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] mcspi: Add support for GPIO chip select lines
On Mon, 14 Mar 2011 13:27:18 -0600, Grant Likely grant.lik...@secretlab.ca wrote: What if the board wanted to use both the native SPI ss line as well as one or more GPIOs? You probably want to reserve cs0 for the native gpio line. Hmm, I had thought about this and assumed it would be easiest to punt on this, requiring the user to use the native line as a GPIO. This of course assumes that all of the CS lines also have pinmux configurations as GPIO pins. Is this not a good assumption? Otherwise this patch looks good to me. Thanks! - Ben -- 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] mcspi: Add support for GPIO chip select lines
On Mon, Mar 14, 2011 at 10:06:40PM -0400, Ben Gamari wrote: On Mon, 14 Mar 2011 13:27:18 -0600, Grant Likely grant.lik...@secretlab.ca wrote: What if the board wanted to use both the native SPI ss line as well as one or more GPIOs? You probably want to reserve cs0 for the native gpio line. Hmm, I had thought about this and assumed it would be easiest to punt on this, requiring the user to use the native line as a GPIO. This of course assumes that all of the CS lines also have pinmux configurations as GPIO pins. Is this not a good assumption? As a general principle I would say no since it would mean adding a 2nd GPIO device will potentially break the first if the infrastructure isn't in place to handle the first line as a gpio. g. -- 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: GPIO chip select support in McSPI
On Mon, 14 Mar 2011 13:25:36 -0600, Grant Likely grant.lik...@secretlab.ca wrote: I see two solutions: 1) platform code registers a bus notifier so that it gets called back before the device gets bound to a driver. Then it can augment the platform data. This sounds like it might be a bit involved and I'm not terribly familiar with these facets of the driver model. This would probably be the more flexible approach but I think I'll stick with the simpler option. 2) add an api to arch/arm/mach-omap2/devices.c for providing a cs table before the device gets registered (must be called before arch_initcall() time). This is along the lines of what I was thinking. Any thoughts on how to get function called before arch_initcall()? - Ben -- 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 00/20] world-writable files in sysfs and debugfs
On Sat, 2011-03-12 at 23:23 +0300, Vasiliy Kulikov wrote: Vasiliy Kulikov (20): mach-ux500: mbox-db5500: world-writable sysfs fifo file leds: lp5521: world-writable sysfs engine* files leds: lp5523: world-writable engine* sysfs files misc: ep93xx_pwm: world-writable sysfs files rtc: rtc-ds1511: world-writable sysfs nvram file scsi: aic94xx: world-writable sysfs update_bios file scsi: iscsi: world-writable sysfs priv_sess file These are still not merged :( OK, so I've not been tracking where we are in the dizzying ride on security systems. However, I thought we landed up in the privilege separation arena using capabilities. That means that world writeable files aren't necessarily a problem as long as the correct capabilities checks are in place, right? James -- 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: Code for v2.6.39 merge window frozen, patches archived
Tony Lindgren wrote, on 03/15/2011 12:55 AM: [..] Looks like there's one smartreflex patch that does not seem to exist in patchwork though.. So that one is still lurking around on the patchwork list of patches until the issue has been fixed in patchwork.kernel.org. Guess it is too late, but am curious: http://marc.info/?l=linux-omapm=129933897910785w=2 Why has it been dropped from .39(aka archived out)? I dont see any review comments to the contrary from any maintainers explaining why we should'nt take it. -- Regards, Nishanth Menon -- 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: [Security] [PATCH 00/20] world-writable files in sysfs and debugfs
On Mon, Mar 14, 2011 at 10:26:05PM -0400, James Bottomley wrote: On Sat, 2011-03-12 at 23:23 +0300, Vasiliy Kulikov wrote: Vasiliy Kulikov (20): mach-ux500: mbox-db5500: world-writable sysfs fifo file leds: lp5521: world-writable sysfs engine* files leds: lp5523: world-writable engine* sysfs files misc: ep93xx_pwm: world-writable sysfs files rtc: rtc-ds1511: world-writable sysfs nvram file scsi: aic94xx: world-writable sysfs update_bios file scsi: iscsi: world-writable sysfs priv_sess file These are still not merged :( OK, so I've not been tracking where we are in the dizzying ride on security systems. However, I thought we landed up in the privilege separation arena using capabilities. That means that world writeable files aren't necessarily a problem as long as the correct capabilities checks are in place, right? There are no capability checks on sysfs files right now, so these all need to be fixed. thanks, greg k-h -- 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
[HELP] Audio on BeagleBoard xM can't work
Hi, folks, I am using 2.6.37-rc3(from linux-2.6.git not linux-omap.git) and I am not able to play any audio on my beagleboard-xM. The log is like this: - # aplay a.wav Playing WAVE 'a.wav' : Signed 16 bit Little Endasoc: interface omap-mcbsp-dai.1 hw params failed ian, Rate 8000 Hz, Mono aplay: set_params:1053: Unable to install hw params: ACCESS: RW_INTERLEAVED FORMAT: S16_LE SUBFORMAT: STD SAMPLE_BITS: 16 FRAME_BITS: 16 CHANNELS: 1 RATE: 8000 PERIOD_TIME: 125000 PERIOD_SIZE: 1000 PERIOD_BYTES: 2000 PERIODS: 4 BUFFER_TIME: 50 BUFFER_SIZE: 4000 BUFFER_BYTES: 8000 TICK_TIME: 0 # - It seems that the code in sound/soc/omap/omap-mcbsp.c uses the function cpu-is-omap343x() which fails and returns ENODEV. But I have enabled OMAP3430 support in System Type / TI OMAP2/3/4 Specific Features, why it still return ENODEV? (Attached my kernel config). And after I changed that check to cpu-is-omap34xx(), there was no error message but neither any audio output, I can't hear any sound. # aplay a.wav Playing WAVE 'a.wav' : Signed 16 bit Little Endian, Rate 8000 Hz, Mono - And suggestion is welcome, Thanks! -- Regards, --Bob beagle-audio.config Description: Binary data
Re: GPIO chip select support in McSPI
On Mon, Mar 14, 2011 at 10:22:31PM -0400, Ben Gamari wrote: On Mon, 14 Mar 2011 13:25:36 -0600, Grant Likely grant.lik...@secretlab.ca wrote: I see two solutions: 1) platform code registers a bus notifier so that it gets called back before the device gets bound to a driver. Then it can augment the platform data. This sounds like it might be a bit involved and I'm not terribly familiar with these facets of the driver model. This would probably be the more flexible approach but I think I'll stick with the simpler option. 2) add an api to arch/arm/mach-omap2/devices.c for providing a cs table before the device gets registered (must be called before arch_initcall() time). This is along the lines of what I was thinking. Any thoughts on how to get function called before arch_initcall()? You can call it from .init_machine() g. - Ben -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 00/10] OMAP4 : DSS2 : HDMI support on OMAP4
On Mon, 2011-03-14 at 05:37 -0500, Jan, Sebastien wrote: Hi Tomi, On Thu, Mar 10, 2011 at 2:44 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: I think this version is good. It works for me, at least =). Any Panda or Blaze owners reading this want to give this a try? Tested on my pandaboard, with these patches applied on top of your dss2 tree: I get a working display on my DVI or my HDMI screen. = I tested by running the Ubuntu UI. I have a couple of these traces from times to times (seems linked to screen saver enabling/disabling the screen): omapdss DISPC error: timeout waiting for EVSYNC Yes, I get those every time I enable or disable the HDMI output. That shouldn't cause any problems, but it's something that needs to be fixed at some point. The best screen resolution is properly selected on both of my screens, but the frame-buffer is sized to 640x480. So the display works but the usable surface when going though /dev/fb0 is quite reduced. Is there a way to get the FB sized according to the screen resolution (in the init sequence, it appears that the FBs are allocated before the init of the HDMI)? Currently the resolution has to be configured by the user manually. I haven't tried, but I think giving the resolution with boot parameters should also work. Mythri, have you tried that? I don't think it is possible for the omapdss, panel or omapfb drivers to configure the resolution automatically, except at boot time. After we have booted up, there may be users for the framebuffer and changing it secretly would cause problems. I think the best way here is that the HDMI/omapdss driver gives hotplug event, which is conveyed through omapfb to an userspace application. This application can then query the available resolutions via some mechanism, and select one of those. Fyi, I have also tested with the patches for DVI support and can get both outputs working simultaneously (my tree is here: http://dev.omapzoom.org/?p=sebjan/kernel.git;a=shortlog;h=refs/tags/topic-display-iv1-2.6.38-rc7). Thanks. I'll also set up a test branch in DSS2 tree shortly, to which I'll add DVI and HDMI patches for easier testing. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 10/10] OMAP4 : HDMI : Add HDMI structure in the board file for OMAP4 PANDA
On Thu, 2011-03-10 at 04:44 -0600, K, Mythri P wrote:
Adding board file structure for display which adds the display
structure with HDMI as the default driver when the display init
is called.
HDMI GPIO configurations are also done in this file.
Signed-off-by: Mythri P K mythr...@ti.com
---
arch/arm/mach-omap2/board-omap4panda.c | 74
1 files changed, 74 insertions(+), 0 deletions(-)
snip
+static struct omap_dss_device *sdp4430_dss_devices[] = {
+ sdp4430_hdmi_device,
+};
+
+static struct omap_dss_board_info sdp4430_dss_data = {
+ .num_devices= ARRAY_SIZE(sdp4430_dss_devices),
+ .devices= sdp4430_dss_devices,
+ .default_device = sdp4430_hdmi_device,
+};
+
+void omap_panda_display_init(void)
+{
+ sdp4430_hdmi_mux_init();
+ omap_display_init(sdp4430_dss_data);
+}
+
The sdp4430 structs and functions should be renamed to panda.
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP2PLUS: DSS2: FEATURES: Fix usage of dss_reg_field and dss_clk_source_name
The structures dss_reg_field and dss_clk_source_name have enum members which
specify the register field and the clock source respectively. These members are
not used to choose the correct result in the corresponding feature functions.
Remove these members and change the features array declaration to incorporate
these enums.
The structure dss_clk_source_name without the enum member is just a pointer to
an string. Remove the structure and use a character pointer directly.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dss.c | 10 ++--
drivers/video/omap2/dss/dss.h |6 ---
drivers/video/omap2/dss/dss_features.c | 77
3 files changed, 43 insertions(+), 50 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index aed9345..06ad312 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -82,10 +82,10 @@ static struct {
u32 ctx[DSS_SZ_REGS / sizeof(u32)];
} dss;
-static const struct dss_clk_source_name dss_generic_clk_source_names[] = {
- { DSS_CLK_SRC_DSI_PLL_HSDIV_DISPC, DSI_PLL_HSDIV_DISPC },
- { DSS_CLK_SRC_DSI_PLL_HSDIV_DSI, DSI_PLL_HSDIV_DSI },
- { DSS_CLK_SRC_FCK, DSS_FCK },
+static const char * const dss_generic_clk_source_names[] = {
+ [DSS_CLK_SRC_DSI_PLL_HSDIV_DISPC] = DSI_PLL_HSDIV_DISPC,
+ [DSS_CLK_SRC_DSI_PLL_HSDIV_DSI] = DSI_PLL_HSDIV_DSI,
+ [DSS_CLK_SRC_FCK] = DSS_FCK,
};
static void dss_clk_enable_all_no_ctx(void);
@@ -232,7 +232,7 @@ void dss_sdi_disable(void)
const char *dss_get_generic_clk_source_name(enum dss_clk_source clk_src)
{
- return dss_generic_clk_source_names[clk_src].clksrc_name;
+ return dss_generic_clk_source_names[clk_src];
}
void dss_dump_clocks(struct seq_file *s)
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index b845468..26a43c9 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -126,12 +126,6 @@ enum dss_clk_source {
* OMAP4: DSS_FCLK */
};
-/* Correlates clock source name and dss_clk_source member */
-struct dss_clk_source_name {
- enum dss_clk_source clksrc;
- const char *clksrc_name;
-};
-
struct dss_clock_info {
/* rates that we get with dividers below */
unsigned long fck;
diff --git a/drivers/video/omap2/dss/dss_features.c
b/drivers/video/omap2/dss/dss_features.c
index 6eb6ec6..8de3344 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -30,7 +30,6 @@
/* Defines a generic omap register field */
struct dss_reg_field {
- enum dss_feat_reg_field id;
u8 start, end;
};
@@ -45,43 +44,43 @@ struct omap_dss_features {
const unsigned long max_dss_fck;
const enum omap_display_type *supported_displays;
const enum omap_color_mode *supported_color_modes;
- const struct dss_clk_source_name *clksrc_names;
+ const char * const *clksrc_names;
};
/* This struct is assigned to one of the below during initialization */
static struct omap_dss_features *omap_current_dss_features;
static const struct dss_reg_field omap2_dss_reg_fields[] = {
- { FEAT_REG_FIRHINC, 11, 0 },
- { FEAT_REG_FIRVINC, 27, 16 },
- { FEAT_REG_FIFOLOWTHRESHOLD, 8, 0 },
- { FEAT_REG_FIFOHIGHTHRESHOLD, 24, 16 },
- { FEAT_REG_FIFOSIZE, 8, 0 },
- { FEAT_REG_HORIZONTALACCU, 9, 0 },
- { FEAT_REG_VERTICALACCU, 25, 16 },
- { FEAT_REG_DISPC_CLK_SWITCH, 0, 0 },
+ [FEAT_REG_FIRHINC] = { 11, 0 },
+ [FEAT_REG_FIRVINC] = { 27, 16 },
+ [FEAT_REG_FIFOLOWTHRESHOLD] = { 8, 0 },
+ [FEAT_REG_FIFOHIGHTHRESHOLD]= { 24, 16 },
+ [FEAT_REG_FIFOSIZE] = { 8, 0 },
+ [FEAT_REG_HORIZONTALACCU] = { 9, 0 },
+ [FEAT_REG_VERTICALACCU] = { 25, 16 },
+ [FEAT_REG_DISPC_CLK_SWITCH] = { 0, 0 },
};
static const struct dss_reg_field omap3_dss_reg_fields[] = {
- { FEAT_REG_FIRHINC, 12, 0 },
- { FEAT_REG_FIRVINC, 28, 16 },
- { FEAT_REG_FIFOLOWTHRESHOLD, 11, 0 },
- { FEAT_REG_FIFOHIGHTHRESHOLD, 27, 16 },
- { FEAT_REG_FIFOSIZE, 10, 0 },
- { FEAT_REG_HORIZONTALACCU, 9, 0 },
- { FEAT_REG_VERTICALACCU, 25, 16 },
- { FEAT_REG_DISPC_CLK_SWITCH, 0, 0 },
+ [FEAT_REG_FIRHINC] = { 12, 0 },
+ [FEAT_REG_FIRVINC] = { 28, 16 },
+ [FEAT_REG_FIFOLOWTHRESHOLD] = { 11, 0 },
+ [FEAT_REG_FIFOHIGHTHRESHOLD]= { 27, 16 },
+ [FEAT_REG_FIFOSIZE] = { 10, 0 },
+ [FEAT_REG_HORIZONTALACCU] = { 9, 0 },
+ [FEAT_REG_VERTICALACCU] = { 25, 16 },
+ [FEAT_REG_DISPC_CLK_SWITCH] = { 0, 0 },
};
static const struct dss_reg_field omap4_dss_reg_fields[] = {
- {
[PATCH] OMAP: DSS2: FEATURES: Functions to return min and max values of parameters
Create 2 functions dss_feat_get_param_min() and dss_feat_get_param_max() which
return the minimum and maximum value of a parameter. Introduce a enum in
dss_features called dss_range_param which contains parameters whose ranges we
are interested in.
Replace this with dss_feat_get_max_dss_fck() which is specific to the parameter
DSS_FCK.
Signed-off-by: Archit Taneja arc...@ti.com
---
Note: Applies over:
http://gitorious.org/linux-omap-dss2/linux/commits/master
and the patch submitted on linux-omap:
OMAP2PLUS: DSS2: FEATURES: Fix usage of dss_reg_field and dss_clk_source_name
drivers/video/omap2/dss/dsi.c |2 +-
drivers/video/omap2/dss/dss.c |2 +-
drivers/video/omap2/dss/dss_features.c | 36 ---
drivers/video/omap2/dss/dss_features.h |7 +-
4 files changed, 36 insertions(+), 11 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index be7694f..6e7f468 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -864,7 +864,7 @@ int dsi_pll_calc_clock_div_pck(bool is_tft, unsigned long
req_pck,
dss_sys_clk = dss_clk_get_rate(DSS_CLK_SYSCK);
- max_dss_fck = dss_feat_get_max_dss_fck();
+ max_dss_fck = dss_feat_get_param_max(FEAT_PARAM_DSS_FCK);
if (req_pck == dsi.cache_req_pck
dsi.cache_cinfo.clkin == dss_sys_clk) {
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 06ad312..562d8d2 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -457,7 +457,7 @@ int dss_calc_clock_div(bool is_tft, unsigned long req_pck,
prate = dss_get_dpll4_rate();
- max_dss_fck = dss_feat_get_max_dss_fck();
+ max_dss_fck = dss_feat_get_param_max(FEAT_PARAM_DSS_FCK);
fck = dss_clk_get_rate(DSS_CLK_FCK);
if (req_pck == dss.cache_req_pck
diff --git a/drivers/video/omap2/dss/dss_features.c
b/drivers/video/omap2/dss/dss_features.c
index 8de3344..4c8b32a 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -33,6 +33,10 @@ struct dss_reg_field {
u8 start, end;
};
+struct dss_param_range {
+ int min, max;
+};
+
struct omap_dss_features {
const struct dss_reg_field *reg_fields;
const int num_reg_fields;
@@ -41,10 +45,10 @@ struct omap_dss_features {
const int num_mgrs;
const int num_ovls;
- const unsigned long max_dss_fck;
const enum omap_display_type *supported_displays;
const enum omap_color_mode *supported_color_modes;
const char * const *clksrc_names;
+ const struct dss_param_range *dss_params;
};
/* This struct is assigned to one of the below during initialization */
@@ -179,6 +183,18 @@ static const char * const omap4_dss_clk_source_names[] = {
[DSS_CLK_SRC_FCK] = DSS_FCLK,
};
+static const struct dss_param_range omap2_dss_param_range[] = {
+ [FEAT_PARAM_DSS_FCK]= { 0, 17300 },
+};
+
+static const struct dss_param_range omap3_dss_param_range[] = {
+ [FEAT_PARAM_DSS_FCK]= { 0, 17300 },
+};
+
+static const struct dss_param_range omap4_dss_param_range[] = {
+ [FEAT_PARAM_DSS_FCK]= { 0, 18600 },
+};
+
/* OMAP2 DSS Features */
static struct omap_dss_features omap2_dss_features = {
.reg_fields = omap2_dss_reg_fields,
@@ -191,10 +207,10 @@ static struct omap_dss_features omap2_dss_features = {
.num_mgrs = 2,
.num_ovls = 3,
- .max_dss_fck = 17300,
.supported_displays = omap2_dss_supported_displays,
.supported_color_modes = omap2_dss_supported_color_modes,
.clksrc_names = omap2_dss_clk_source_names,
+ .dss_params = omap2_dss_param_range,
};
/* OMAP3 DSS Features */
@@ -210,10 +226,10 @@ static struct omap_dss_features omap3430_dss_features = {
.num_mgrs = 2,
.num_ovls = 3,
- .max_dss_fck = 17300,
.supported_displays = omap3430_dss_supported_displays,
.supported_color_modes = omap3_dss_supported_color_modes,
.clksrc_names = omap3_dss_clk_source_names,
+ .dss_params = omap3_dss_param_range,
};
static struct omap_dss_features omap3630_dss_features = {
@@ -229,10 +245,10 @@ static struct omap_dss_features omap3630_dss_features = {
.num_mgrs = 2,
.num_ovls = 3,
- .max_dss_fck = 17300,
.supported_displays = omap3630_dss_supported_displays,
.supported_color_modes = omap3_dss_supported_color_modes,
.clksrc_names = omap3_dss_clk_source_names,
+ .dss_params = omap3_dss_param_range,
};
/* OMAP4 DSS Features */
@@ -247,10 +263,10 @@ static struct omap_dss_features omap4_dss_features = {
.num_mgrs = 3,
.num_ovls = 3,
- .max_dss_fck = 18600,
.supported_displays = omap4_dss_supported_displays,
.supported_color_modes =
[PATCH v2] OMAP: DSS2: FEATURES: DSI PLL parameter cleanup
The DSI PLL parameters (regm, regn, regm_dispc, regm_dsi, fint) have different
fields and also different Max values on OMAP3 and OMAP4. Use dss features to
calculate the register fields and min/max values based on current OMAP revision.
Signed-off-by: Archit Taneja arc...@ti.com
---
v2:
use dss_feat_get_param_max()/min() instead of calculating range from field's
start and end.
Note: Applies over:
http://gitorious.org/linux-omap-dss2/linux/commits/master
and the patches submitted on linux-omap:
OMAP2PLUS: DSS2: FEATURES: Fix usage of dss_reg_field and dss_clk_source_name
OMAP: DSS2: FEATURES: Functions to return min and max values of parameters
drivers/video/omap2/dss/dsi.c | 69 +-
drivers/video/omap2/dss/dss_features.c | 84 +--
drivers/video/omap2/dss/dss_features.h | 10
3 files changed, 113 insertions(+), 50 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 6e7f468..86d4852 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -185,14 +185,6 @@ struct dsi_reg { u16 idx; };
#define DSI_DT_RX_SHORT_READ_1 0x21
#define DSI_DT_RX_SHORT_READ_2 0x22
-#define FINT_MAX 210
-#define FINT_MIN 75
-#define REGN_MAX (1 7)
-#define REGM_MAX ((1 11) - 1)
-#define REGM_DISPC_MAX (1 4)
-#define REGM_DSI_MAX (1 4)
-#define LP_DIV_MAX ((1 13) - 1)
-
enum fifo_size {
DSI_FIFO_SIZE_0 = 0,
DSI_FIFO_SIZE_32= 1,
@@ -277,6 +269,11 @@ static struct
spinlock_t irq_stats_lock;
struct dsi_irq_stats irq_stats;
#endif
+ /* DSI PLL Parameter Ranges */
+ unsigned long regm_max, regn_max;
+ unsigned long regm_dispc_max, regm_dsi_max;
+ unsigned long fint_min, fint_max;
+ unsigned long lpdiv_max;
} dsi;
#ifdef DEBUG
@@ -751,7 +748,7 @@ static int dsi_set_lp_clk_divisor(struct omap_dss_device
*dssdev)
lp_clk_div = dssdev-phy.dsi.div.lp_clk_div;
- if (lp_clk_div == 0 || lp_clk_div LP_DIV_MAX)
+ if (lp_clk_div == 0 || lp_clk_div dsi.lpdiv_max)
return -EINVAL;
dsi_fclk = dsi_fclk_rate();
@@ -801,16 +798,16 @@ static int dsi_pll_power(enum dsi_pll_power_state state)
static int dsi_calc_clock_rates(struct omap_dss_device *dssdev,
struct dsi_clock_info *cinfo)
{
- if (cinfo-regn == 0 || cinfo-regn REGN_MAX)
+ if (cinfo-regn == 0 || cinfo-regn dsi.regn_max)
return -EINVAL;
- if (cinfo-regm == 0 || cinfo-regm REGM_MAX)
+ if (cinfo-regm == 0 || cinfo-regm dsi.regm_max)
return -EINVAL;
- if (cinfo-regm_dispc REGM_DISPC_MAX)
+ if (cinfo-regm_dispc dsi.regm_dispc_max)
return -EINVAL;
- if (cinfo-regm_dsi REGM_DSI_MAX)
+ if (cinfo-regm_dsi dsi.regm_dsi_max)
return -EINVAL;
if (cinfo-use_sys_clk) {
@@ -829,7 +826,7 @@ static int dsi_calc_clock_rates(struct omap_dss_device
*dssdev,
cinfo-fint = cinfo-clkin / (cinfo-regn * (cinfo-highfreq ? 2 : 1));
- if (cinfo-fint FINT_MAX || cinfo-fint FINT_MIN)
+ if (cinfo-fint dsi.fint_max || cinfo-fint dsi.fint_min)
return -EINVAL;
cinfo-clkin4ddr = 2 * cinfo-regm * cinfo-fint;
@@ -899,17 +896,17 @@ retry:
/* no highfreq: 0.75MHz Fint = clkin / regn 2.1MHz */
/* highfreq: 0.75MHz Fint = clkin / (2*regn) 2.1MHz */
/* To reduce PLL lock time, keep Fint high (around 2 MHz) */
- for (cur.regn = 1; cur.regn REGN_MAX; ++cur.regn) {
+ for (cur.regn = 1; cur.regn dsi.regn_max; ++cur.regn) {
if (cur.highfreq == 0)
cur.fint = cur.clkin / cur.regn;
else
cur.fint = cur.clkin / (2 * cur.regn);
- if (cur.fint FINT_MAX || cur.fint FINT_MIN)
+ if (cur.fint dsi.fint_max || cur.fint dsi.fint_min)
continue;
/* DSIPHY(MHz) = (2 * regm / regn) * (clkin / (highfreq + 1)) */
- for (cur.regm = 1; cur.regm REGM_MAX; ++cur.regm) {
+ for (cur.regm = 1; cur.regm dsi.regm_max; ++cur.regm) {
unsigned long a, b;
a = 2 * cur.regm * (cur.clkin/1000);
@@ -921,7 +918,7 @@ retry:
/* dsi_pll_hsdiv_dispc_clk(MHz) =
* DSIPHY(MHz) / regm_dispc 173MHz/186Mhz */
- for (cur.regm_dispc = 1; cur.regm_dispc
REGM_DISPC_MAX;
+ for (cur.regm_dispc = 1; cur.regm_dispc
dsi.regm_dispc_max;
++cur.regm_dispc) {
struct dispc_clock_info cur_dispc;
cur.dsi_pll_hsdiv_dispc_clk =
@@ -994,6 +991,8 @@ int dsi_pll_set_clock_div(struct dsi_clock_info *cinfo)
int r = 0;
Re: [PATCH v5 00/10] OMAP4 : DSS2 : HDMI support on OMAP4
Hi Tomi,Sebastien, On Tue, Mar 15, 2011 at 9:36 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Mon, 2011-03-14 at 05:37 -0500, Jan, Sebastien wrote: Hi Tomi, On Thu, Mar 10, 2011 at 2:44 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: I think this version is good. It works for me, at least =). Any Panda or Blaze owners reading this want to give this a try? Tested on my pandaboard, with these patches applied on top of your dss2 tree: I get a working display on my DVI or my HDMI screen. = I tested by running the Ubuntu UI. I have a couple of these traces from times to times (seems linked to screen saver enabling/disabling the screen): omapdss DISPC error: timeout waiting for EVSYNC Yes, I get those every time I enable or disable the HDMI output. That shouldn't cause any problems, but it's something that needs to be fixed at some point. The best screen resolution is properly selected on both of my screens, but the frame-buffer is sized to 640x480. So the display works but the usable surface when going though /dev/fb0 is quite reduced. Is there a way to get the FB sized according to the screen resolution (in the init sequence, it appears that the FBs are allocated before the init of the HDMI)? Currently the resolution has to be configured by the user manually. I haven't tried, but I think giving the resolution with boot parameters should also work. Mythri, have you tried that? You could configure the timings later on with the sysfs ( set_timings ) or HDMI driver would pick the best timing (as suggested by standard) , but yes framebuffer would have picked the timing on probe so it will not update. I don't think it is possible for the omapdss, panel or omapfb drivers to configure the resolution automatically, except at boot time. After we have booted up, there may be users for the framebuffer and changing it secretly would cause problems. I think the best way here is that the HDMI/omapdss driver gives hotplug event, which is conveyed through omapfb to an userspace application. This application can then query the available resolutions via some mechanism, and select one of those. Fyi, I have also tested with the patches for DVI support and can get both outputs working simultaneously (my tree is here: http://dev.omapzoom.org/?p=sebjan/kernel.git;a=shortlog;h=refs/tags/topic-display-iv1-2.6.38-rc7). Thanks. I'll also set up a test branch in DSS2 tree shortly, to which I'll add DVI and HDMI patches for easier testing. Tomi Thanks and regards, Mythri. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] OMAP4: Intialize IVA Device in addition to DSP device.
On Sat, Mar 12, 2011 at 16:09, Shweta Gulati shweta.gul...@ti.com wrote:
OMAP4 has two different Devices IVA and DSP. DSP is bound
with IVA for DVFS. The registration of IVA dev in API
'omap2_init_processor_devices' was missing. Init dev for
'iva_dev' is added.
This also fixes the following error seen during boot as
omap2_set_init_voltage can now find the iva device
omap2_set_init_voltage: Invalid parameters!
omap2_set_init_voltage: Unable to put vdd_iva to its init voltage
Signed-off-by: Shweta Gulati shweta.gul...@ti.com
---
Tested on OMAP4430 SDP Board.
Baseline:
http://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
Branch :pm-core
V2:
Rephrased the Commit log.
arch/arm/mach-omap2/pm.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 30af335..49486f5 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -89,6 +89,7 @@ static void omap2_init_processor_devices(void)
if (cpu_is_omap44xx()) {
_init_omap_device(l3_main_1, l3_dev);
_init_omap_device(dsp, dsp_dev);
+ _init_omap_device(iva, iva_dev);
} else {
_init_omap_device(l3_main, l3_dev);
}
--
Looks fine to me.
Regards,
Nishanth Menon
--
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
