Re: [PATCH] omap: hsmmc funtionality breaks when CONFIG_PM not define
Ghorai, Sukumar wrote:
Adrian,
-Original Message-
From: Adrian Hunter [mailto:adrian.hun...@nokia.com]
Sent: Tuesday, July 20, 2010 2:44 PM
To: Ghorai, Sukumar
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Shilimkar,
Santosh; Chikkature Rajashekar, Madhusudhan; Andrew Morton
Subject: Re: [PATCH] omap: hsmmc funtionality breaks when CONFIG_PM not
define
Ghorai, Sukumar wrote:
-Original Message-
From: Adrian Hunter [mailto:adrian.hun...@nokia.com]
Sent: Tuesday, July 20, 2010 2:10 PM
To: Ghorai, Sukumar
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Shilimkar,
Santosh; Chikkature Rajashekar, Madhusudhan; Andrew Morton
Subject: Re: [PATCH] omap: hsmmc funtionality breaks when CONFIG_PM not
define
Ghorai, Sukumar wrote:
Adrian,
-Original Message-
From: Adrian Hunter [mailto:adrian.hun...@nokia.com]
Sent: Tuesday, July 20, 2010 1:40 PM
To: Ghorai, Sukumar
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Shilimkar,
Santosh; Chikkature Rajashekar, Madhusudhan; Andrew Morton
Subject: Re: [PATCH] omap: hsmmc funtionality breaks when CONFIG_PM
not
define
Ghorai, Sukumar wrote:
-Original Message-
From: Adrian Hunter [mailto:adrian.hun...@nokia.com]
Sent: Tuesday, July 20, 2010 12:39 PM
To: Ghorai, Sukumar
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org;
Shilimkar,
Santosh; Chikkature Rajashekar, Madhusudhan; Andrew Morton
Subject: Re: [PATCH] omap: hsmmc funtionality breaks when CONFIG_PM
not
define
Sukumar Ghorai wrote:
Issue if power_saving option passed from board file and
CONFIG_PM
not define.
This is because hosts refer to wrong operation table and that
try
to
power save.
power_saving is not related to power management. It should work
with
or
without
CONFIG_PM. What problem are you seeing?
[Ghorai] when CONFIG_PM is not defined but power_saving flag is TRUE,
then host operation table point to table which handles in state
machine
as: ENABLE - CARDSLEEP - REGSLEEP - DISABLED for power/clock cut.
And
do the reverse for the enable clock/power.
And power saving is not required and wont work when CONFIG_PM is not
enabled.
How is that a problem? It would be useful to know what you need?
[Ghorai] do men when CONFIG_PM is not enabled still we should do power
saving in mmc?
Why not?
Because issue is iclk/fclk is quite depended on PRCM framework when we
are
using omap_hsmmc_ps_ops operation table.
iclk is left alone.
fclk is manipulated with or without power_saving.
I still do not understand your problem sorry :-(
[Ghorai] thanks and need input again,
we have two tables -
1. static const struct mmc_host_ops omap_hsmmc_ops = {
}
-- This is without CONFIG_PM, assumed.
No it is independent of CONFIG_PM
With CONFIG_PM
- the driver will restore registers if the host controller
has been powered off / on by PRCM
- suspend / resume can be used
2. static const struct mmc_host_ops omap_hsmmc_ps_ops = {
}
- this with CONFIG_PM, assumed.
No it is independent of CONFIG_PM
Without CONFIG_PM
- card will be put to sleep after 1 second
- card will be powered off after another 8 seconds
a. And you feel we should remove #1
Nothing should need to be removed.
b. use omap_hsmmc_ps_ops default.
With power_saving it is yes.
[Ghorai] Is it that power_saving (true or false) is independent of CONFIG_PM?
Yes, power_saving (true or false) *is* independent of CONFIG_PM.
c. And it should work in all case?
It should work in all cases.
So if CONFIG_PM is not enable, then it should do simple clock
disable/enable, and not via the power state machine.
If that is what you want, simply change your board file:
#if CONFIG_PM
.power_saving = true,
#else
.power_saving = false,
#end
[Ghorai] the fix I send is to guard in MMC/SD host driver to avoid
mistake in board file(s). And this file is used for multiple omap3,
omap4
boards.
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
CC: Madhusudhan Chikkature madhu...@ti.com
CC: Andrew Morton a...@linux-foundation.org
---
Tested on omap3, omap4430 ES2.0
drivers/mmc/host/omap_hsmmc.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c
b/drivers/mmc/host/omap_hsmmc.c
index b032828..f84eed0 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2015,9 +2015,11 @@ static int __init omap_hsmmc_probe(struct
platform_device *pdev)
platform_set_drvdata(pdev, host);
INIT_WORK(host-mmc_carddetect_work, omap_hsmmc_detect);
+#ifdef CONFIG_PM
if (mmc_slot(host).power_saving)
mmc-ops = omap_hsmmc_ps_ops;
else
+#endif
mmc-ops = omap_hsmmc_ops;
/*
--
To unsubscribe from this list: send the line unsubscribe linux-
mmc
in
the body of a message to majord...@vger.kernel.org
More majordomo info at
RE: [PATCH] omap: hsmmc funtionality breaks when CONFIG_PM not define
Adrian,
-Original Message-
From: Adrian Hunter [mailto:adrian.hun...@nokia.com]
Sent: Wednesday, July 21, 2010 11:46 AM
To: Ghorai, Sukumar
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Shilimkar,
Santosh; Chikkature Rajashekar, Madhusudhan; Andrew Morton
Subject: Re: [PATCH] omap: hsmmc funtionality breaks when CONFIG_PM not
define
[Ghorai] thanks and need input again,
we have two tables -
1. static const struct mmc_host_ops omap_hsmmc_ops = {
}
-- This is without CONFIG_PM, assumed.
No it is independent of CONFIG_PM
With CONFIG_PM
- the driver will restore registers if the host controller
has been powered off / on by PRCM
- suspend / resume can be used
2. static const struct mmc_host_ops omap_hsmmc_ps_ops = {
}
- this with CONFIG_PM, assumed.
No it is independent of CONFIG_PM
Without CONFIG_PM
- card will be put to sleep after 1 second
- card will be powered off after another 8 seconds
a. And you feel we should remove #1
Nothing should need to be removed.
b. use omap_hsmmc_ps_ops default.
With power_saving it is yes.
[Ghorai] Is it that power_saving (true or false) is independent of
CONFIG_PM?
Yes, power_saving (true or false) *is* independent of CONFIG_PM.
[Ghorai] Thanks and would you please reply for query from Kishore and now query
from my side too?
Is there any use case or a valid scenario when to use omap_hsmmc_ps_ops or
omap_hsmmc_ops ? I meant using power_saving option and without power_saving
option.
Ideally I feel having omap_hsmmc_ps_ops as default with or without CONFIG_PM
would be better as it internally has a state handling.
Regards,
Ghorai
--
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: hsmmc funtionality breaks when CONFIG_PM not define
kishore kadiyala wrote:
Hi Adrian,
Is there any use case or a valid scenario whether to use
omap_hsmmc_ps_ops or omap_hsmmc_ops ?
I meant using power_saving option and without power_saving option
There are two disadvantages of power_saving:
1. It introduces latency to wake-up or re-initialize.
Waking up a sleeping card can take 10-20ms (or more). Re-initializing
a card that was powered off entirely can take 300-1000ms.
2. The current implementation powers-up the card even
if it just wants to suspend and power it off again.
Ideally I feel having omap_hsmmc_ps_ops as default with or without
CONFIG_PM would be better as it internally has a state handling.
Sure, you could rename power_saving to no_power_saving, invert the
logic and drop it from the board files that had power_saving = true.
If that is what you want, make a patch and see if anyone comments.
Regards,
Kishore
On Tue, Jul 20, 2010 at 2:43 PM, Adrian Hunter adrian.hun...@nokia.com wrote:
Ghorai, Sukumar wrote:
-Original Message-
From: Adrian Hunter [mailto:adrian.hun...@nokia.com]
Sent: Tuesday, July 20, 2010 2:10 PM
To: Ghorai, Sukumar
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Shilimkar,
Santosh; Chikkature Rajashekar, Madhusudhan; Andrew Morton
Subject: Re: [PATCH] omap: hsmmc funtionality breaks when CONFIG_PM not
define
Ghorai, Sukumar wrote:
Adrian,
-Original Message-
From: Adrian Hunter [mailto:adrian.hun...@nokia.com]
Sent: Tuesday, July 20, 2010 1:40 PM
To: Ghorai, Sukumar
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Shilimkar,
Santosh; Chikkature Rajashekar, Madhusudhan; Andrew Morton
Subject: Re: [PATCH] omap: hsmmc funtionality breaks when CONFIG_PM not
define
Ghorai, Sukumar wrote:
-Original Message-
From: Adrian Hunter [mailto:adrian.hun...@nokia.com]
Sent: Tuesday, July 20, 2010 12:39 PM
To: Ghorai, Sukumar
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Shilimkar,
Santosh; Chikkature Rajashekar, Madhusudhan; Andrew Morton
Subject: Re: [PATCH] omap: hsmmc funtionality breaks when CONFIG_PM
not
define
Sukumar Ghorai wrote:
Issue if power_saving option passed from board file and
CONFIG_PM
not define.
This is because hosts refer to wrong operation table and that
try
to
power save.
power_saving is not related to power management. It should work with
or
without
CONFIG_PM. What problem are you seeing?
[Ghorai] when CONFIG_PM is not defined but power_saving flag is TRUE,
then host operation table point to table which handles in state machine
as: ENABLE - CARDSLEEP - REGSLEEP - DISABLED for power/clock cut.
And
do the reverse for the enable clock/power.
And power saving is not required and wont work when CONFIG_PM is not
enabled.
How is that a problem? It would be useful to know what you need?
[Ghorai] do men when CONFIG_PM is not enabled still we should do power
saving in mmc?
Why not?
Because issue is iclk/fclk is quite depended on PRCM framework when we
are
using omap_hsmmc_ps_ops operation table.
iclk is left alone.
fclk is manipulated with or without power_saving.
I still do not understand your problem sorry :-(
[Ghorai] thanks and need input again, we have two tables -
1. static const struct mmc_host_ops omap_hsmmc_ops = {
}
-- This is without CONFIG_PM, assumed.
No it is independent of CONFIG_PM
With CONFIG_PM
- the driver will restore registers if the host controller
has been powered off / on by PRCM
- suspend / resume can be used
2. static const struct mmc_host_ops omap_hsmmc_ps_ops = {
}
- this with CONFIG_PM, assumed.
No it is independent of CONFIG_PM
Without CONFIG_PM
- card will be put to sleep after 1 second
- card will be powered off after another 8 seconds
a. And you feel we should remove #1
Nothing should need to be removed.
b. use omap_hsmmc_ps_ops default.
With power_saving it is yes.
c. And it should work in all case?
It should work in all cases.
So if CONFIG_PM is not enable, then it should do simple clock
disable/enable, and not via the power state machine.
If that is what you want, simply change your board file:
#if CONFIG_PM
.power_saving = true,
#else
.power_saving = false,
#end
[Ghorai] the fix I send is to guard in MMC/SD host driver to avoid
mistake in board file(s). And this file is used for multiple omap3, omap4
boards.
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
CC: Madhusudhan Chikkature madhu...@ti.com
CC: Andrew Morton a...@linux-foundation.org
---
Tested on omap3, omap4430 ES2.0
drivers/mmc/host/omap_hsmmc.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c
b/drivers/mmc/host/omap_hsmmc.c
index b032828..f84eed0 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2015,9 +2015,11 @@ static int __init omap_hsmmc_probe(struct
platform_device *pdev)
RE: [PATCH 2/2] omap:mailbox-provide multiple reader support
Apologies - top posting and not quoting properly due to having to use MS's
braindead OWA.
It appears that most of the changes are simply indentation changes caused by
the inclusion of a new inner block here:
+ if (atomic_inc_return(mbox-use_count) == 1) {
rather than just using a goto to skip past the unneeded parts. (Hmmm, is it not
simply an immediate return now?)
The goto/return is both more idiomatic in linux, and I'm sure a simpler patch.
Phil
From: linux-omap-ow...@vger.kernel.org [linux-omap-ow...@vger.kernel.org] On
Behalf Of ext Hari Kanigeri [h-kanige...@ti.com]
Sent: 21 July 2010 01:41
To: Linux Omap; Tony Lindgren; Doyu Hiroshi (Nokia-MS/Helsinki)
Cc: Ohad Ben-Cohen; Hari Kanigeri
Subject: [PATCH 2/2] omap:mailbox-provide multiple reader support
This patch provides mutiple readers support for a mailbox
instance.
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
---
arch/arm/plat-omap/include/plat/mailbox.h |6 ++-
arch/arm/plat-omap/mailbox.c | 63
2 files changed, 40 insertions(+), 29 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mailbox.h
b/arch/arm/plat-omap/include/plat/mailbox.h
index 0486d64..c8e47d8 100644
--- a/arch/arm/plat-omap/include/plat/mailbox.h
+++ b/arch/arm/plat-omap/include/plat/mailbox.h
@@ -68,13 +68,15 @@ struct omap_mbox {
void*priv;
void(*err_notify)(void);
+ atomic_tuse_count;
+ struct blocking_notifier_head notifier;
};
int omap_mbox_msg_send(struct omap_mbox *, mbox_msg_t msg);
void omap_mbox_init_seq(struct omap_mbox *);
-struct omap_mbox *omap_mbox_get(const char *);
-void omap_mbox_put(struct omap_mbox *);
+struct omap_mbox *omap_mbox_get(const char *, struct notifier_block *nb);
+void omap_mbox_put(struct omap_mbox *, struct notifier_block *nb);
int omap_mbox_register(struct device *parent, struct omap_mbox *);
int omap_mbox_unregister(struct omap_mbox *);
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index baac315..f9f2af4 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -149,8 +149,8 @@ static void mbox_rx_work(struct work_struct *work)
if (unlikely(len != sizeof(msg)))
pr_err(%s: kfifo_out anomaly detected\n, __func__);
- if (mq-callback)
- mq-callback((void *)msg);
+ blocking_notifier_call_chain(mq-mbox-notifier, len,
+ (void *)msg);
}
}
@@ -252,28 +252,30 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
}
}
- ret = request_irq(mbox-irq, mbox_interrupt, IRQF_SHARED,
- mbox-name, mbox);
- if (unlikely(ret)) {
- printk(KERN_ERR
- failed to register mailbox interrupt:%d\n, ret);
- goto fail_request_irq;
- }
+ if (atomic_inc_return(mbox-use_count) == 1) {
+ ret = request_irq(mbox-irq, mbox_interrupt, IRQF_SHARED,
+ mbox-name, mbox);
+ if (unlikely(ret)) {
+ printk(KERN_ERR failed to register mailbox interrupt:
+ %d\n, ret);
+ goto fail_request_irq;
+ }
- mq = mbox_queue_alloc(mbox, NULL, mbox_tx_tasklet);
- if (!mq) {
- ret = -ENOMEM;
- goto fail_alloc_txq;
- }
- mbox-txq = mq;
+ mq = mbox_queue_alloc(mbox, NULL, mbox_tx_tasklet);
+ if (!mq) {
+ ret = -ENOMEM;
+ goto fail_alloc_txq;
+ }
+ mbox-txq = mq;
- mq = mbox_queue_alloc(mbox, mbox_rx_work, NULL);
- if (!mq) {
- ret = -ENOMEM;
- goto fail_alloc_rxq;
+ mq = mbox_queue_alloc(mbox, mbox_rx_work, NULL);
+ if (!mq) {
+ ret = -ENOMEM;
+ goto fail_alloc_rxq;
+ }
+ mbox-rxq = mq;
+ mq-mbox = mbox;
}
- mbox-rxq = mq;
-
return 0;
fail_alloc_rxq:
@@ -281,6 +283,7 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
fail_alloc_txq:
free_irq(mbox-irq, mbox);
fail_request_irq:
+ atomic_dec(mbox-use_count);
if (likely(mbox-ops-shutdown)) {
if (atomic_dec_return(mbox_refcount) == 0)
mbox-ops-shutdown(mbox);
@@ -291,10 +294,12 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
static void omap_mbox_fini(struct omap_mbox *mbox)
{
- mbox_queue_free(mbox-txq);
- mbox_queue_free(mbox-rxq);
- free_irq(mbox-irq, mbox);
+ if (atomic_dec_return(mbox-use_count) == 0) {
+
RE: [PATCH] omap4: fb: Adds missing display update call when panning
-Original Message-
From: Shilimkar, Santosh
Sent: Thursday, July 15, 2010 6:19 PM
To: Janorkar, Mayuresh; tomi.valkei...@nokia.com
Cc: linux-omap@vger.kernel.org; Diaz Prado, Gustavo
Subject: RE: [PATCH] omap4: fb: Adds missing display update call when
panning
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Janorkar, Mayuresh
Sent: Thursday, July 15, 2010 6:07 PM
To: tomi.valkei...@nokia.com
Cc: linux-omap@vger.kernel.org; Diaz Prado, Gustavo; Janorkar, Mayuresh
Subject: [PATCH] omap4: fb: Adds missing display update call when
panning
From: Gustavo Diaz Prado x0083...@ti.com
Adds the missing display update call when panning, this
is needed for the DSI panel when the auto-update feature is
not enabled.
Signed-off-by: Gustavo Diaz Prado x0083...@ti.com
Signed-off-by: Mayuresh Janorkar ma...@ti.com
---
drivers/video/omap2/omapfb/omapfb-main.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
b/drivers/video/omap2/omapfb/omapfb-main.c
index 4abb1d1..12d5382 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -1068,7 +1068,8 @@ static int omapfb_pan_display(struct
fb_var_screeninfo *var,
{
struct omapfb_info *ofbi = FB2OFB(fbi);
struct fb_var_screeninfo new_var;
- int r;
+ int r = 0;
+ struct omap_dss_device *display = fb2display(fbi);
DBG(pan_display(%d)\n, FB2OFB(fbi)-id);
@@ -1086,6 +1087,11 @@ static int omapfb_pan_display(struct
fb_var_screeninfo *var,
r = omapfb_apply_changes(fbi, 0);
+ if (display display-driver-update
+ display-driver-get_update_mode(display)
+ == OMAP_DSS_UPDATE_MANUAL)
If the display dereference is checked, there is no need to check the base
pointer (display), right ?
[Mayuresh]: That's correct. I would take it into account.
+ display-driver-update(display, 0, 0, var-xres, var-yres);
+
omapfb_put_mem_region(ofbi-region);
return r;
--
1.5.4.7
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Are there any more comments?
If not can I resend the patch incorporating Santosh's comments?
-Thanks,
Mayuresh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/3] OMAP: DSS2: Zorder enum in display.h
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Archit Taneja
Sent: Monday, July 19, 2010 5:40 PM
To: tomi.valkei...@nokia.com
Cc: linux-omap@vger.kernel.org; Semwal, Sumit; Nilofer,
Samreen; Taneja, Archit
Subject: [PATCH 1/3] OMAP: DSS2: Zorder enum in display.h
From: Sumit Semwal sumit.sem...@ti.com
Add Zorder enum in display.h
Patches 1 and 2 in the series can easily be conbined into one.
Separating few line changes in header file from implementation
across 2 patches isn't useful.
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
Signed-off-by: Samreen samr...@ti.com
Signed-off-by: Archit Taneja arc...@ti.com
---
arch/arm/plat-omap/include/plat/display.h |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/display.h
b/arch/arm/plat-omap/include/plat/display.h
index d1da317..197ce8c
--- a/arch/arm/plat-omap/include/plat/display.h
+++ b/arch/arm/plat-omap/include/plat/display.h
@@ -206,6 +206,13 @@ enum omap_overlay_manager_caps {
OMAP_DSS_OVL_MGR_CAP_DISPC = 1 0,
};
+enum omap_overlay_zorder {
+ OMAP_DSS_OVL_ZORDER_0 = 0x0,
+ OMAP_DSS_OVL_ZORDER_1 = 0x1,
+ OMAP_DSS_OVL_ZORDER_2 = 0x2,
+ OMAP_DSS_OVL_ZORDER_3 = 0x3,
+};
Is _DSS_ really needed in these emums? considering that enum
itself doesn't contain _dss_ in its name.
~sanjeev
+
/* RFBI */
struct rfbi_timings {
@@ -308,6 +315,7 @@ struct omap_overlay_info {
u16 out_width; /* if 0, out_width == width */
u16 out_height; /* if 0, out_height == height */
u8 global_alpha;
+ enum omap_overlay_zorder zorder;
};
struct omap_overlay {
--
1.6.3.3
--
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] [ARM] video/omap2/tdo35s: fix visual artefacts
ping!
TDO35S samples the data on the falling adge of the pixel clock,
therefore the data strobe should be on the raising edge.
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
.../video/omap2/displays/panel-toppoly-tdo35s.c|8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-toppoly-tdo35s.c
b/drivers/video/omap2/displays/panel-toppoly-tdo35s.c
index fa434ca..e320e67 100644
--- a/drivers/video/omap2/displays/panel-toppoly-tdo35s.c
+++ b/drivers/video/omap2/displays/panel-toppoly-tdo35s.c
@@ -73,8 +73,12 @@ static void toppoly_tdo_panel_power_off(struct
omap_dss_device *dssdev)
static int toppoly_tdo_panel_probe(struct omap_dss_device *dssdev)
{
- dssdev-panel.config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
- OMAP_DSS_LCD_IHS;
+ dssdev-panel.config = OMAP_DSS_LCD_TFT |
+OMAP_DSS_LCD_IVS |
+OMAP_DSS_LCD_IHS |
+OMAP_DSS_LCD_IPC |
+OMAP_DSS_LCD_ONOFF;
+
dssdev-panel.timings = toppoly_tdo_panel_timings;
return 0;
--
Regards,
Igor.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 08/11] staging: tidspbridge: remove IN modifier
Hi, From: Menon, Nishanth IN modifier does not exist. remove it Signed-off-by: Nishanth Menon n...@ti.com --- [...] diff --git a/drivers/staging/tidspbridge/include/dspbridge/drv.h b/drivers/staging/tidspbridge/include/dspbridge/drv.h index 020bed0..753a317 100644 --- a/drivers/staging/tidspbridge/include/dspbridge/drv.h +++ b/drivers/staging/tidspbridge/include/dspbridge/drv.h @@ -70,8 +70,8 @@ #define OMAP_DMMU_BASE 0x5D00 #define OMAP_DMMU_SIZE 0x1000 -#define OMAP_PRCM_VDD1_DOMAIN 1 -#define OMAP_PRCM_VDD2_DOMAIN 2 +#define OMAP_PRCM_VDD1_DOMA1 +#define OMAP_PRCM_VDD2_DOMA2 Unexpected change? Regards, Omar -- 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 08/11] staging: tidspbridge: remove IN modifier
On Wed, Jul 21, 2010 at 9:59 AM, Ramirez Luna, Omar omar.rami...@ti.com wrote: Hi, From: Menon, Nishanth IN modifier does not exist. remove it Signed-off-by: Nishanth Menon n...@ti.com --- [...] diff --git a/drivers/staging/tidspbridge/include/dspbridge/drv.h b/drivers/staging/tidspbridge/include/dspbridge/drv.h index 020bed0..753a317 100644 --- a/drivers/staging/tidspbridge/include/dspbridge/drv.h +++ b/drivers/staging/tidspbridge/include/dspbridge/drv.h @@ -70,8 +70,8 @@ #define OMAP_DMMU_BASE 0x5D00 #define OMAP_DMMU_SIZE 0x1000 -#define OMAP_PRCM_VDD1_DOMAIN 1 -#define OMAP_PRCM_VDD2_DOMAIN 2 +#define OMAP_PRCM_VDD1_DOMA1 +#define OMAP_PRCM_VDD2_DOMA2 Unexpected change? wooops... Sorry about that.. Regards, Omar -- 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: Add macros to evaluate cpu revision
This patch adds macros to evaluate the cpu revision. These macros increase readability by reducing the repetitive code when multiple silicon and their revisions have to be tested. Example usage would be: if (cpu_rev_eq(omap34xx, ES_1_0)) Signed-off-by: Sanjeev Premi pr...@ti.com --- arch/arm/plat-omap/include/plat/cpu.h | 32 1 files changed, 32 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h index aa2f4f0..14b1a44 100644 --- a/arch/arm/plat-omap/include/plat/cpu.h +++ b/arch/arm/plat-omap/include/plat/cpu.h @@ -70,6 +70,7 @@ unsigned int omap_rev(void); #define OMAP_REVBITS_200x20 #define OMAP_REVBITS_300x30 #define OMAP_REVBITS_400x40 +#define OMAP_REVBITS_500x50 /* * Get the CPU revision for OMAP devices @@ -460,4 +461,35 @@ OMAP3_HAS_FEATURE(isp, ISP) OMAP3_HAS_FEATURE(192mhz_clk, 192MHZ_CLK) OMAP3_HAS_FEATURE(io_wakeup, IO_WAKEUP) +/* + * Map revision bits to silicon specific revisions + */ +#define ES_1_0 OMAP_REVBITS_00 +#define ES_2_0 OMAP_REVBITS_10 +#define ES_2_1 OMAP_REVBITS_20 +#define ES_3_0 OMAP_REVBITS_30 +#define ES_3_1 OMAP_REVBITS_40 +#define ES_3_1_2 OMAP_REVBITS_50 + +/* + * Macros to evaluate CPU revision + */ +#define cpu_rev_lt(cpu,rev)\ + ((cpu_is_omap ##cpu() (GET_OMAP_REVISION() (rev))) ? 1 : 0) + +#define cpu_rev_le(cpu,rev)\ + ((cpu_is_omap ##cpu() (GET_OMAP_REVISION() = (rev))) ? 1 : 0) + +#define cpu_rev_eq(cpu,rev)\ + ((cpu_is_omap ##cpu() (GET_OMAP_REVISION() == (rev))) ? 1 : 0) + +#define cpu_rev_ne(cpu,rev)\ + ((cpu_is_omap ##cpu() (GET_OMAP_REVISION() != (rev))) ? 1 : 0) + +#define cpu_rev_ge(cpu,rev)\ + ((cpu_is_omap ##cpu() (GET_OMAP_REVISION() = (rev))) ? 1 : 0) + +#define cpu_rev_gt(cpu,rev)\ + ((cpu_is_omap ##cpu() (GET_OMAP_REVISION() (rev))) ? 1 : 0) + #endif -- 1.6.6.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] omap: Add macros to evaluate cpu revision
Premi, Sanjeev had written, on 07/21/2010 10:12 AM, the following: This patch adds macros to evaluate the cpu revision. These macros increase readability by reducing the repetitive code when multiple silicon and their revisions have to be tested. Example usage would be: if (cpu_rev_eq(omap34xx, ES_1_0)) Signed-off-by: Sanjeev Premi pr...@ti.com --- arch/arm/plat-omap/include/plat/cpu.h | 32 1 files changed, 32 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h index aa2f4f0..14b1a44 100644 --- a/arch/arm/plat-omap/include/plat/cpu.h +++ b/arch/arm/plat-omap/include/plat/cpu.h @@ -70,6 +70,7 @@ unsigned int omap_rev(void); #define OMAP_REVBITS_200x20 #define OMAP_REVBITS_300x30 #define OMAP_REVBITS_400x40 +#define OMAP_REVBITS_500x50 /* * Get the CPU revision for OMAP devices @@ -460,4 +461,35 @@ OMAP3_HAS_FEATURE(isp, ISP) OMAP3_HAS_FEATURE(192mhz_clk, 192MHZ_CLK) OMAP3_HAS_FEATURE(io_wakeup, IO_WAKEUP) +/* + * Map revision bits to silicon specific revisions + */ +#define ES_1_0 OMAP_REVBITS_00 probably need ES_1_1, 1_2 (considering 3630) +#define ES_2_0 OMAP_REVBITS_10 +#define ES_2_1 OMAP_REVBITS_20 makes sense to go to 2_2 +#define ES_3_0 OMAP_REVBITS_30 +#define ES_3_1 OMAP_REVBITS_40 +#define ES_3_1_2 OMAP_REVBITS_50 3_2? + +/* + * Macros to evaluate CPU revision + */ +#define cpu_rev_lt(cpu,rev)\ + ((cpu_is_omap ##cpu() (GET_OMAP_REVISION() (rev))) ? 1 : 0) + +#define cpu_rev_le(cpu,rev)\ + ((cpu_is_omap ##cpu() (GET_OMAP_REVISION() = (rev))) ? 1 : 0) + +#define cpu_rev_eq(cpu,rev)\ + ((cpu_is_omap ##cpu() (GET_OMAP_REVISION() == (rev))) ? 1 : 0) + +#define cpu_rev_ne(cpu,rev)\ + ((cpu_is_omap ##cpu() (GET_OMAP_REVISION() != (rev))) ? 1 : 0) + +#define cpu_rev_ge(cpu,rev)\ + ((cpu_is_omap ##cpu() (GET_OMAP_REVISION() = (rev))) ? 1 : 0) + +#define cpu_rev_gt(cpu,rev)\ + ((cpu_is_omap ##cpu() (GET_OMAP_REVISION() (rev))) ? 1 : 0) + #endif -- 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: Buffer overrun in the TWL4030 keypad driver with Nokia RX51
Hi Dmitry, On Tuesday 20 July 2010 20:07:45 Dmitry Torokhov wrote: On Tuesday, July 20, 2010 04:06:08 am Laurent Pinchart wrote: On Saturday 17 July 2010 23:37:05 Dmitry Torokhov wrote: On Fri, Jul 16, 2010 at 05:28:43PM +0200, Laurent Pinchart wrote: I've spent the day debugging a kernel crash in the USB networking code to find out the problem was caused by a buffer overrun in the TWL4030 keypad driver. The Nokia RX51 board code (arch/arm/mach-omap2/board-rx51-peripherals.c) defines a key map for the matrix keypad keyboard. The hardware seems to use all of the 8 rows and 8 columns of the keypad, although not all possible locations are used. The TWL4030 supports keypads with at most 8 rows and 8 columns. Most keys are defined with a row and column number between 0 and 7, except KEY(0xff, 2, KEY_F9), KEY(0xff, 4, KEY_F10), KEY(0xff, 5, KEY_F11), The row number is set to 0xff. As the generic matrix keypad support (include/linux/input/matrix_keypad.h) supports at most 16 rows and 16 columns, it masks all but the lower 4 bits of the row and column numbers in the KEY macro. [..snipped..] Thanks for the report. Could yo uplease try the patch below and let me know if it works. The patch fixes the crash at startup, Great. but the F9, F10 and F11 key events are never reported. That might be because those keys are not wired up to anything though. I would not know... If you see all keys on the device being handled then I guess it's the case... Tony, Amit, any ideas? All keys on the keyboard, as well as the F7 and F8 keys (volume up and down on the of the case) I guess we need to remap them to KEY_VOLUMEUP and KEY_VOLUMEDOWN then. So is F7 == Up and F8 == Down? It's the other way around. F7 is volume down, F8 is volume up. Note that the same keys have different meanings depending on the context. In the photo viewer, they are used to zoom (volume down zooms out, volume up zooms in). generate the proper events. All other keys (keyboard slider switch, power button, focus button, lock switch, proximity sensor) report events through other devices. I have some concerns with the keymap assignments, I see that Amit changed them during KEY(col, row) - KEY(row, col) conversion. I marked the entries I am concerned with with XXX. F7, F8, right alt and left shift are properly mapped. I don't know what F9, F10 and F11 are supposed to be. OK, thanks. Since you don't crash anymore I think it is worth pushing it out. -- Regards, Laurent Pinchart -- 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: Prevent SDRC deadlock when L3 is changing frequency
From: Jon Hunter jon-hun...@ti.com
When changing the L3 clock frequency, the CPU is executing from internal RAM
and the SDRC clock is disabled. During this time accesses made to external
DDR are stalled. If the ARM subsystem attempts to access the DDR while the
SDRC clock is disabled this will stall the CPU until the access to the SDRC
timeouts. A timeout on the SDRC should never occur. Once a timeout occurs all
the following accesses will be aborted and the DDR is no longer accessible.
Although the code being executed in the internal RAM does not directly access
the DDR, it was found that the branch prediction logic in the CPU may cause
the CPU to prefetch code from a DDR location while the SDRC clock is disabled.
This was causing an SDRC timeout which resulted in a system hang.
This patch fixes this problem by ensuring the branch prediction logic is
disabled while changing the L3 clock frequency. The branch prediction logic
is disabled by clearing the Z-bit in the ARM AUX CTRL register.
Disabling the branch prediction logic does not have any noticable impact
on the execution time of this code section. The hardware observability
signals were used to monitor the sdrc idle time with and without this
patch when operating at different CPU frequencies (150MHz, 500MHz and
600MHz) and the total sdrc idle time when changing frequenct was in
the range of 9-11us. This was measured on an omap3430 SDP running the
omapzoom p-android-omap-2.6.29 branch.
This change has been commited to both TI's android 2.6.29 and 2.6.32 kernels.
The commits can be viewed here:
http://git.omapzoom.org/?p=kernel/omap.git;a=commit;h=5679c7b1142f3cc2b9285181d53f6b40c4d0296d
http://git.omapzoom.org/?p=kernel/omap.git;a=commit;h=cf16e57823575d98e9d5165aa7a498ffb751c940
This patch has been rebased on the latest linux-omap tree and tested on
Kevin Hilman's pm branch.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/sram34xx.S |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/sram34xx.S b/arch/arm/mach-omap2/sram34xx.S
index de99ba2..e87e730 100644
--- a/arch/arm/mach-omap2/sram34xx.S
+++ b/arch/arm/mach-omap2/sram34xx.S
@@ -129,8 +129,11 @@ ENTRY(omap3_sram_configure_core_dpll)
ldr r4, [sp, #80]
str r4, omap_sdrc_mr_1_val
skip_cs1_params:
+ mrc p15, 0, r8, c1, c0, 0 @ read aux ctrl register
+ bic r10, r8, #0x800 @ clear Z-bit, disable branch prediction
+ mcr p15, 0, r10, c1, c0, 0 @ write aux ctrl register
dsb @ flush buffered writes to interconnect
-
+ isb @ prevent speculative exec past here
cmp r3, #1 @ if increasing SDRC clk rate,
bleqconfigure_sdrc @ program the SDRC regs early (for RFR)
cmp r1, #SDRC_UNLOCK_DLL@ set the intended DLL state
@@ -148,6 +151,7 @@ skip_cs1_params:
beq return_to_sdram @ return to SDRAM code, otherwise,
bl configure_sdrc @ reprogram SDRC regs now
return_to_sdram:
+ mcr p15, 0, r8, c1, c0, 0 @ restore aux ctrl register
isb @ prevent speculative exec past here
mov r0, #0 @ return value
ldmfd sp!, {r1-r12, pc} @ restore regs and return
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 03/20] mmc: support embedded data field in mmc_host
Add support to set/get mmc_host private embedded
data.
This is needed to allow software to dynamically
create (and remove) SDIO functions which represents
embedded SDIO devices.
Typically, it will be used to set the context of
a driver that is creating a new SDIO function
(and would then expect to be able to get that context
back upon creation of the new sdio func).
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
include/linux/mmc/host.h | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index f65913c..80db597 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -209,6 +209,8 @@ struct mmc_host {
struct led_trigger *led; /* activity led */
#endif
+ void*embedded_data;
+
struct dentry *debugfs_root;
unsigned long private[0] cacheline_aligned;
@@ -264,5 +266,15 @@ static inline void mmc_set_disable_delay(struct mmc_host
*host,
host-disable_delay = disable_delay;
}
+static inline void *mmc_get_embedded_data(struct mmc_host *host)
+{
+ return host-embedded_data;
+}
+
+static inline void mmc_set_embedded_data(struct mmc_host *host, void *data)
+{
+ host-embedded_data = data;
+}
+
#endif
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 04/20] omap zoom2: wlan board muxing
Add board muxing to support the wlan wl1271 chip that is
hardwired to mmc2 (third mmc controller) on the ZOOM2.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/mach-omap2/board-zoom2.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom2.c
b/arch/arm/mach-omap2/board-zoom2.c
index 803ef14..1520a2c 100644
--- a/arch/arm/mach-omap2/board-zoom2.c
+++ b/arch/arm/mach-omap2/board-zoom2.c
@@ -71,6 +71,19 @@ static struct twl4030_platform_data zoom2_twldata = {
#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),
+ /* WLAN POWER ENABLE - GPIO 101 */
+ OMAP3_MUX(CAM_D2, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
+ /* WLAN SDIO: MMC3 CMD */
+ OMAP3_MUX(MCSPI1_CS1, OMAP_MUX_MODE3 | OMAP_PIN_INPUT_PULLUP),
+ /* WLAN SDIO: MMC3 CLK */
+ OMAP3_MUX(ETK_CLK, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+ /* WLAN SDIO: MMC3 DAT[0-3] */
+ OMAP3_MUX(ETK_D3, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(ETK_D4, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(ETK_D5, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(ETK_D6, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#else
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 05/20] omap zoom3: wlan board muxing
Add board muxing to support the wlan wl1271 chip that is
hardwired to mmc2 (third mmc controller) on the ZOOM3.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/mach-omap2/board-zoom3.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom3.c
b/arch/arm/mach-omap2/board-zoom3.c
index 3314704..7d17046 100644
--- a/arch/arm/mach-omap2/board-zoom3.c
+++ b/arch/arm/mach-omap2/board-zoom3.c
@@ -46,6 +46,19 @@ 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),
+ /* WLAN POWER ENABLE - GPIO 101 */
+ OMAP3_MUX(CAM_D2, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
+ /* WLAN SDIO: MMC3 CMD */
+ OMAP3_MUX(MCSPI1_CS1, OMAP_MUX_MODE3 | OMAP_PIN_INPUT_PULLUP),
+ /* WLAN SDIO: MMC3 CLK */
+ OMAP3_MUX(ETK_CLK, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+ /* WLAN SDIO: MMC3 DAT[0-3] */
+ OMAP3_MUX(ETK_D3, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(ETK_D4, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(ETK_D5, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(ETK_D6, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#else
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 06/20] wireless: wl1271: make wl12xx.h common to both spi and sdio
Move wl12xx.h outside of the spi-specific location,
so it can be shared with both spi and sdio solutions.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/net/wireless/wl12xx/wl1251_sdio.c |2 +-
drivers/net/wireless/wl12xx/wl1251_spi.c |2 +-
drivers/net/wireless/wl12xx/wl1271_spi.c |2 +-
include/linux/spi/wl12xx.h| 34 -
include/linux/wl12xx.h| 34 +
5 files changed, 37 insertions(+), 37 deletions(-)
delete mode 100644 include/linux/spi/wl12xx.h
create mode 100644 include/linux/wl12xx.h
diff --git a/drivers/net/wireless/wl12xx/wl1251_sdio.c
b/drivers/net/wireless/wl12xx/wl1251_sdio.c
index c561332..416d5aa 100644
--- a/drivers/net/wireless/wl12xx/wl1251_sdio.c
+++ b/drivers/net/wireless/wl12xx/wl1251_sdio.c
@@ -24,7 +24,7 @@
#include linux/mmc/sdio_func.h
#include linux/mmc/sdio_ids.h
#include linux/platform_device.h
-#include linux/spi/wl12xx.h
+#include linux/wl12xx.h
#include linux/irq.h
#include wl1251.h
diff --git a/drivers/net/wireless/wl12xx/wl1251_spi.c
b/drivers/net/wireless/wl12xx/wl1251_spi.c
index e814742..4847b6a 100644
--- a/drivers/net/wireless/wl12xx/wl1251_spi.c
+++ b/drivers/net/wireless/wl12xx/wl1251_spi.c
@@ -26,7 +26,7 @@
#include linux/slab.h
#include linux/crc7.h
#include linux/spi/spi.h
-#include linux/spi/wl12xx.h
+#include linux/wl12xx.h
#include wl1251.h
#include wl1251_reg.h
diff --git a/drivers/net/wireless/wl12xx/wl1271_spi.c
b/drivers/net/wireless/wl12xx/wl1271_spi.c
index 5189b81..e866049 100644
--- a/drivers/net/wireless/wl12xx/wl1271_spi.c
+++ b/drivers/net/wireless/wl12xx/wl1271_spi.c
@@ -25,7 +25,7 @@
#include linux/module.h
#include linux/crc7.h
#include linux/spi/spi.h
-#include linux/spi/wl12xx.h
+#include linux/wl12xx.h
#include linux/slab.h
#include wl1271.h
diff --git a/include/linux/spi/wl12xx.h b/include/linux/spi/wl12xx.h
deleted file mode 100644
index a223ecb..000
--- a/include/linux/spi/wl12xx.h
+++ /dev/null
@@ -1,34 +0,0 @@
-/*
- * This file is part of wl12xx
- *
- * Copyright (C) 2009 Nokia Corporation
- *
- * Contact: Kalle Valo kalle.v...@nokia.com
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
- * 02110-1301 USA
- *
- */
-
-#ifndef _LINUX_SPI_WL12XX_H
-#define _LINUX_SPI_WL12XX_H
-
-struct wl12xx_platform_data {
- void (*set_power)(bool enable);
- /* SDIO only: IRQ number if WLAN_IRQ line is used, 0 for SDIO IRQs */
- int irq;
- bool use_eeprom;
-};
-
-#endif
diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
new file mode 100644
index 000..137ac89
--- /dev/null
+++ b/include/linux/wl12xx.h
@@ -0,0 +1,34 @@
+/*
+ * This file is part of wl12xx
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ *
+ * Contact: Kalle Valo kalle.v...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#ifndef _LINUX_WL12XX_H
+#define _LINUX_WL12XX_H
+
+struct wl12xx_platform_data {
+ void (*set_power)(bool enable);
+ /* SDIO only: IRQ number if WLAN_IRQ line is used, 0 for SDIO IRQs */
+ int irq;
+ bool use_eeprom;
+};
+
+#endif
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 07/20] wireless: wl1271: support return value for the set power func
Make it possible for the set power method to indicate a
success/failure return value. This is needed to support
more complex power on/off operations such as bringing up
(and down) sdio functions.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/net/wireless/wl12xx/wl1271.h |2 +-
drivers/net/wireless/wl12xx/wl1271_io.h |8 +---
drivers/net/wireless/wl12xx/wl1271_main.c |4 +++-
drivers/net/wireless/wl12xx/wl1271_sdio.c |4 +++-
drivers/net/wireless/wl12xx/wl1271_spi.c |4 +++-
5 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1271.h
b/drivers/net/wireless/wl12xx/wl1271.h
index 6f1b6b5..a21cdb2 100644
--- a/drivers/net/wireless/wl12xx/wl1271.h
+++ b/drivers/net/wireless/wl12xx/wl1271.h
@@ -340,7 +340,7 @@ struct wl1271_if_operations {
bool fixed);
void (*reset)(struct wl1271 *wl);
void (*init)(struct wl1271 *wl);
- void (*power)(struct wl1271 *wl, bool enable);
+ int (*power)(struct wl1271 *wl, bool enable);
struct device* (*dev)(struct wl1271 *wl);
void (*enable_irq)(struct wl1271 *wl);
void (*disable_irq)(struct wl1271 *wl);
diff --git a/drivers/net/wireless/wl12xx/wl1271_io.h
b/drivers/net/wireless/wl12xx/wl1271_io.h
index bc806c7..4a5b92c 100644
--- a/drivers/net/wireless/wl12xx/wl1271_io.h
+++ b/drivers/net/wireless/wl12xx/wl1271_io.h
@@ -144,10 +144,12 @@ static inline void wl1271_power_off(struct wl1271 *wl)
clear_bit(WL1271_FLAG_GPIO_POWER, wl-flags);
}
-static inline void wl1271_power_on(struct wl1271 *wl)
+static inline int wl1271_power_on(struct wl1271 *wl)
{
- wl-if_ops-power(wl, true);
- set_bit(WL1271_FLAG_GPIO_POWER, wl-flags);
+ int ret = wl-if_ops-power(wl, true);
+ if (ret == 0)
+ set_bit(WL1271_FLAG_GPIO_POWER, wl-flags);
+ return ret;
}
diff --git a/drivers/net/wireless/wl12xx/wl1271_main.c
b/drivers/net/wireless/wl12xx/wl1271_main.c
index b7d9137..6bd748e 100644
--- a/drivers/net/wireless/wl12xx/wl1271_main.c
+++ b/drivers/net/wireless/wl12xx/wl1271_main.c
@@ -620,7 +620,9 @@ static int wl1271_chip_wakeup(struct wl1271 *wl)
int ret = 0;
msleep(WL1271_PRE_POWER_ON_SLEEP);
- wl1271_power_on(wl);
+ ret = wl1271_power_on(wl);
+ if (ret 0)
+ goto out;
msleep(WL1271_POWER_ON_SLEEP);
wl1271_io_reset(wl);
wl1271_io_init(wl);
diff --git a/drivers/net/wireless/wl12xx/wl1271_sdio.c
b/drivers/net/wireless/wl12xx/wl1271_sdio.c
index 9903ae9..571c6b9 100644
--- a/drivers/net/wireless/wl12xx/wl1271_sdio.c
+++ b/drivers/net/wireless/wl12xx/wl1271_sdio.c
@@ -144,7 +144,7 @@ static void wl1271_sdio_raw_write(struct wl1271 *wl, int
addr, void *buf,
}
-static void wl1271_sdio_set_power(struct wl1271 *wl, bool enable)
+static int wl1271_sdio_set_power(struct wl1271 *wl, bool enable)
{
struct sdio_func *func = wl_to_func(wl);
@@ -159,6 +159,8 @@ static void wl1271_sdio_set_power(struct wl1271 *wl, bool
enable)
sdio_disable_func(func);
sdio_release_host(func);
}
+
+ return 0;
}
static struct wl1271_if_operations sdio_ops = {
diff --git a/drivers/net/wireless/wl12xx/wl1271_spi.c
b/drivers/net/wireless/wl12xx/wl1271_spi.c
index e866049..85a167f 100644
--- a/drivers/net/wireless/wl12xx/wl1271_spi.c
+++ b/drivers/net/wireless/wl12xx/wl1271_spi.c
@@ -313,10 +313,12 @@ static irqreturn_t wl1271_irq(int irq, void *cookie)
return IRQ_HANDLED;
}
-static void wl1271_spi_set_power(struct wl1271 *wl, bool enable)
+static int wl1271_spi_set_power(struct wl1271 *wl, bool enable)
{
if (wl-set_power)
wl-set_power(enable);
+
+ return 0;
}
static struct wl1271_if_operations spi_ops = {
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 08/20] wireless: wl1271: take irq info from private board data
Remove the hard coded irq information, and instead take
the irq information from the board private data
which is supplied by the sdio function.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/net/wireless/wl12xx/wl1271_sdio.c | 14 --
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1271_sdio.c
b/drivers/net/wireless/wl12xx/wl1271_sdio.c
index 571c6b9..75901a6 100644
--- a/drivers/net/wireless/wl12xx/wl1271_sdio.c
+++ b/drivers/net/wireless/wl12xx/wl1271_sdio.c
@@ -28,15 +28,14 @@
#include linux/mmc/sdio_func.h
#include linux/mmc/sdio_ids.h
#include linux/mmc/card.h
+#include linux/mmc/host.h
+#include linux/wl12xx.h
#include plat/gpio.h
#include wl1271.h
#include wl12xx_80211.h
#include wl1271_io.h
-
-#define RX71_WL1271_IRQ_GPIO 42
-
static const struct sdio_device_id wl1271_devices[] = {
{ SDIO_DEVICE(SDIO_VENDOR_ID_TI, SDIO_DEVICE_ID_TI_WL1271) },
{}
@@ -178,6 +177,7 @@ static int __devinit wl1271_probe(struct sdio_func *func,
const struct sdio_device_id *id)
{
struct ieee80211_hw *hw;
+ struct wl12xx_platform_data *wlan_data;
struct wl1271 *wl;
int ret;
@@ -197,9 +197,11 @@ static int __devinit wl1271_probe(struct sdio_func *func,
/* Grab access to FN0 for ELP reg. */
func-card-quirks |= MMC_QUIRK_LENIENT_FN0;
- wl-irq = gpio_to_irq(RX71_WL1271_IRQ_GPIO);
- if (wl-irq 0) {
- ret = wl-irq;
+ wlan_data = mmc_get_embedded_data(func-card-host);
+ if (wlan_data wlan_data-irq)
+ wl-irq = wlan_data-irq;
+ else {
+ ret = -EINVAL;
wl1271_error(could not get irq!);
goto out_free;
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 10/20] omap: zoom: add fixed regulator device for wlan
Add a fixed regulator vmmc device to enable power control
of the wl1271 wlan device.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/mach-omap2/board-zoom-peripherals.c | 34 ++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index 6b39849..2fc0f4a 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -16,6 +16,7 @@
#include linux/gpio.h
#include linux/i2c/twl.h
#include linux/regulator/machine.h
+#include linux/regulator/fixed.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -27,6 +28,8 @@
#include mux.h
#include hsmmc.h
+#define OMAP_ZOOM_WLAN_PMENA_GPIO (101)
+
/* Zoom2 has Qwerty keyboard*/
static int board_keymap[] = {
KEY(0, 0, KEY_E),
@@ -106,6 +109,10 @@ static struct regulator_consumer_supply zoom_vmmc2_supply
= {
.supply = vmmc,
};
+static struct regulator_consumer_supply zoom_vmmc3_supply = {
+ .supply = vmmc,
+};
+
/* VMMC1 for OMAP VDD_MMC1 (i/o) and MMC1 card */
static struct regulator_init_data zoom_vmmc1 = {
.constraints = {
@@ -151,6 +158,32 @@ static struct regulator_init_data zoom_vsim = {
.consumer_supplies = zoom_vsim_supply,
};
+static struct regulator_init_data zoom_vmmc3 = {
+ .constraints = {
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = zoom_vmmc3_supply,
+};
+
+static struct fixed_voltage_config zoom_vwlan = {
+ .supply_name = vwl1271,
+ .microvolts = 180, /* 1.8V */
+ .gpio = OMAP_ZOOM_WLAN_PMENA_GPIO,
+ .startup_delay = 7, /* 70msec */
+ .enable_high = 1,
+ .enabled_at_boot = 0,
+ .init_data = zoom_vmmc3,
+};
+
+static struct platform_device omap_vwlan_device = {
+ .name = reg-fixed-voltage,
+ .id = 1,
+ .dev = {
+ .platform_data = zoom_vwlan,
+ },
+};
+
static struct omap2_hsmmc_info mmc[] __initdata = {
{
.name = external,
@@ -280,6 +313,7 @@ static void enable_board_wakeup_source(void)
void __init zoom_peripherals_init(void)
{
omap_i2c_init();
+ platform_device_register(omap_vwlan_device);
usb_musb_init(musb_board_data);
enable_board_wakeup_source();
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 11/20] omap: hsmmc: support mmc3 regulator power control
Prepare for mmc3 regulator power control by splitting the power
control functions of mmc2 and mmc3, and expecting mmc3 to have
a single, dedicated, regulator support.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/mach-omap2/hsmmc.c | 10 --
drivers/mmc/host/omap_hsmmc.c | 67
2 files changed, 66 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 1ef54b0..5d3d789 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -174,7 +174,7 @@ static void omap4_hsmmc1_after_set_reg(struct device *dev,
int slot,
}
}
-static void hsmmc23_before_set_reg(struct device *dev, int slot,
+static void hsmmc2_before_set_reg(struct device *dev, int slot,
int power_on, int vdd)
{
struct omap_mmc_platform_data *mmc = dev-platform_data;
@@ -325,14 +325,16 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info
*controllers)
c-transceiver = 1;
if (c-transceiver c-wires 4)
c-wires = 4;
- /* FALLTHROUGH */
- case 3:
if (mmc-slots[0].features HSMMC_HAS_PBIAS) {
/* off-chip level shifting, or none */
- mmc-slots[0].before_set_reg =
hsmmc23_before_set_reg;
+ mmc-slots[0].before_set_reg =
hsmmc2_before_set_reg;
mmc-slots[0].after_set_reg = NULL;
}
break;
+ case 3:
+ mmc-slots[0].before_set_reg = NULL;
+ mmc-slots[0].after_set_reg = NULL;
+ break;
default:
pr_err(MMC%d configuration not supported!\n, c-mmc);
kfree(mmc);
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index b032828..4c5a669 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -258,7 +258,7 @@ static int omap_hsmmc_1_set_power(struct device *dev, int
slot, int power_on,
return ret;
}
-static int omap_hsmmc_23_set_power(struct device *dev, int slot, int power_on,
+static int omap_hsmmc_2_set_power(struct device *dev, int slot, int power_on,
int vdd)
{
struct omap_hsmmc_host *host =
@@ -309,6 +309,31 @@ static int omap_hsmmc_23_set_power(struct device *dev, int
slot, int power_on,
return ret;
}
+static int omap_hsmmc_3_set_power(struct device *dev, int slot, int power_on,
+ int vdd)
+{
+ struct omap_hsmmc_host *host =
+ platform_get_drvdata(to_platform_device(dev));
+ int ret = 0;
+
+ if (power_on) {
+ ret = mmc_regulator_set_ocr(host-vcc, vdd);
+ /* Enable interface voltage rail, if needed */
+ if (ret == 0 host-vcc) {
+ ret = regulator_enable(host-vcc);
+ if (ret 0)
+ ret = mmc_regulator_set_ocr(host-vcc, 0);
+ }
+ } else {
+ if (host-vcc)
+ ret = regulator_disable(host-vcc);
+ if (ret == 0)
+ ret = mmc_regulator_set_ocr(host-vcc, 0);
+ }
+
+ return ret;
+}
+
static int omap_hsmmc_1_set_sleep(struct device *dev, int slot, int sleep,
int vdd, int cardsleep)
{
@@ -319,7 +344,7 @@ static int omap_hsmmc_1_set_sleep(struct device *dev, int
slot, int sleep,
return regulator_set_mode(host-vcc, mode);
}
-static int omap_hsmmc_23_set_sleep(struct device *dev, int slot, int sleep,
+static int omap_hsmmc_2_set_sleep(struct device *dev, int slot, int sleep,
int vdd, int cardsleep)
{
struct omap_hsmmc_host *host =
@@ -358,6 +383,31 @@ static int omap_hsmmc_23_set_sleep(struct device *dev, int
slot, int sleep,
return regulator_enable(host-vcc_aux);
}
+static int omap_hsmmc_3_set_sleep(struct device *dev, int slot, int sleep,
+ int vdd, int cardsleep)
+{
+ struct omap_hsmmc_host *host =
+ platform_get_drvdata(to_platform_device(dev));
+ int err = 0;
+
+ /*
+* If we don't see a Vcc regulator, assume it's a fixed
+* voltage always-on regulator.
+*/
+ if (!host-vcc)
+ return 0;
+
+ if (cardsleep) {
+ /* VCC can be turned off if card is asleep */
+ if (sleep)
+ err = mmc_regulator_set_ocr(host-vcc, 0);
+ else
+ err = mmc_regulator_set_ocr(host-vcc, vdd);
+ }
+
+ return err;
+}
+
static int
[PATCH v2 13/20] omap: zoom: add mmc3/wl1271 device support
Add MMC3 support on ZOOM, which has the wl1271 device hardwired to.
The wl1271 is a 4-wire, 1.8V, embedded SDIO WLAN device with an
external IRQ line, and power-controlled by a GPIO-based fixed regulator.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/mach-omap2/board-zoom-peripherals.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index 2fc0f4a..3230801 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -17,6 +17,8 @@
#include linux/i2c/twl.h
#include linux/regulator/machine.h
#include linux/regulator/fixed.h
+#include linux/mmc/host.h
+#include linux/wl12xx.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -29,6 +31,7 @@
#include hsmmc.h
#define OMAP_ZOOM_WLAN_PMENA_GPIO (101)
+#define OMAP_ZOOM_WLAN_IRQ_GPIO(162)
/* Zoom2 has Qwerty keyboard*/
static int board_keymap[] = {
@@ -184,6 +187,12 @@ static struct platform_device omap_vwlan_device = {
},
};
+struct wl12xx_platform_data omap_zoom_wlan_data = {
+ .irq = OMAP_GPIO_IRQ(OMAP_ZOOM_WLAN_IRQ_GPIO),
+ /* ZOOM ref clock is 26 MHz */
+ .board_ref_clock = 1,
+};
+
static struct omap2_hsmmc_info mmc[] __initdata = {
{
.name = external,
@@ -201,6 +210,15 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
.nonremovable = true,
.power_saving = true,
},
+ {
+ .name = wl1271,
+ .mmc= 3,
+ .wires = 4,
+ .gpio_wp= -EINVAL,
+ .gpio_cd= -EINVAL,
+ .ocr_mask = MMC_VDD_165_195,
+ .priv_data = omap_zoom_wlan_data,
+ },
{} /* Terminator */
};
@@ -217,6 +235,7 @@ static int zoom_twl_gpio_setup(struct device *dev,
zoom_vmmc1_supply.dev = mmc[0].dev;
zoom_vsim_supply.dev = mmc[0].dev;
zoom_vmmc2_supply.dev = mmc[1].dev;
+ zoom_vmmc3_supply.dev = mmc[2].dev;
return 0;
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 12/20] omap: hsmmc: allow board-specific settings of private mmc data
Allow board-specific settings of private mmc data, in order to
allow embedded SDIO devices to communicate board-specific parameters
to the SDIO function driver (e.g., the external IRQ line of the wl1271).
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/mach-omap2/hsmmc.c |2 ++
arch/arm/mach-omap2/hsmmc.h |1 +
arch/arm/plat-omap/include/plat/mmc.h |2 ++
drivers/mmc/host/omap_hsmmc.c |2 ++
4 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 5d3d789..f06ddd2 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -284,6 +284,8 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info
*controllers)
if (c-vcc_aux_disable_is_sleep)
mmc-slots[0].vcc_aux_disable_is_sleep = 1;
+ mmc-slots[0].priv_data = c-priv_data;
+
/* NOTE: MMC slots should have a Vcc regulator set up.
* This may be from a TWL4030-family chip, another
* controllable regulator, or a fixed supply.
diff --git a/arch/arm/mach-omap2/hsmmc.h b/arch/arm/mach-omap2/hsmmc.h
index 36f0ba8..434a3ed 100644
--- a/arch/arm/mach-omap2/hsmmc.h
+++ b/arch/arm/mach-omap2/hsmmc.h
@@ -23,6 +23,7 @@ struct omap2_hsmmc_info {
int ocr_mask; /* temporary HACK */
/* Remux (pad configuation) when powering on/off */
void (*remux)(struct device *dev, int slot, int power_on);
+ void*priv_data; /* private data to SDIO function driver */
};
#if defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE)
diff --git a/arch/arm/plat-omap/include/plat/mmc.h
b/arch/arm/plat-omap/include/plat/mmc.h
index c835f1e..9db1617 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -140,6 +140,8 @@ struct omap_mmc_platform_data {
unsigned int ban_openended:1;
+ /* card private data that should be used by function driver */
+ void *priv_data;
} slots[OMAP_MMC_MAX_SLOTS];
};
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 4c5a669..4ac548e 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2157,6 +2157,8 @@ static int __init omap_hsmmc_probe(struct platform_device
*pdev)
if (mmc_slot(host).nonremovable)
mmc-caps |= MMC_CAP_NONREMOVABLE;
+ mmc_set_embedded_data(mmc, mmc_slot(host).priv_data);
+
omap_hsmmc_conf_bus_power(host);
/* Select DMA lines */
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 14/20] mmc: sdio: fully reconfigure oldcard on resume
On resume, let mmc_sdio_init_card go all the way, instead of skipping the reconfiguration of the card's speed and width. This is needed to ensure cards wake up with their clock reconfigured (otherwise it's kept low). This patch also removes the explicit bus width reconfiguration on resume, since now this is part of mmc_sdio_init_card. Signed-off-by: Ohad Ben-Cohen o...@wizery.com --- drivers/mmc/core/sdio.c |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c index b9dee28..645f173 100644 --- a/drivers/mmc/core/sdio.c +++ b/drivers/mmc/core/sdio.c @@ -344,7 +344,6 @@ static int mmc_sdio_init_card(struct mmc_host *host, u32 ocr, goto err; } card = oldcard; - return 0; } /* @@ -487,9 +486,6 @@ static int mmc_sdio_resume(struct mmc_host *host) mmc_claim_host(host); err = mmc_sdio_init_card(host, host-ocr, host-card, (host-pm_flags MMC_PM_KEEP_POWER)); - if (!err) - /* We may have switched to 1-bit mode during suspend. */ - err = sdio_enable_wide(host-card); if (!err host-sdio_irqs) mmc_signal_sdio_irq(host); mmc_release_host(host); -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 15/20] mmc: sdio: verify existence of resume handler
Before invoking a card's resume handler, verify one exists.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/mmc/core/sdio.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index 645f173..37739f5 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -504,7 +504,9 @@ static int mmc_sdio_resume(struct mmc_host *host)
struct sdio_func *func = host-card-sdio_func[i];
if (func sdio_func_present(func) func-dev.driver) {
const struct dev_pm_ops *pmops = func-dev.driver-pm;
- err = pmops-resume(func-dev);
+
+ if (pmops pmops-resume)
+ err = pmops-resume(func-dev);
}
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 16/20] mmc: introduce API to control the card's power
Introduce the sdio_claim_power/sdio_release_power API
(with correspoding mmc_claim_power/mmc_release_power)
that controls the power of the card. A reference count
scheme is employed, to allow SDIO function voting.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/mmc/core/bus.c|3 ++
drivers/mmc/core/core.c | 50 +
drivers/mmc/core/sdio.c |5
drivers/mmc/core/sdio_io.c| 50 +
include/linux/mmc/card.h |2 +
include/linux/mmc/host.h |2 +
include/linux/mmc/sdio_func.h |3 ++
7 files changed, 115 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c
index 49d9dca..33151d5 100644
--- a/drivers/mmc/core/bus.c
+++ b/drivers/mmc/core/bus.c
@@ -17,6 +17,7 @@
#include linux/mmc/card.h
#include linux/mmc/host.h
+#include asm/atomic.h
#include core.h
#include sdio_cis.h
@@ -207,6 +208,8 @@ struct mmc_card *mmc_alloc_card(struct mmc_host *host,
struct device_type *type)
card-host = host;
+ atomic_set(card-power_claims, 0);
+
device_initialize(card-dev);
card-dev.parent = mmc_classdev(host);
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 569e94d..ca5e3bf 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1334,6 +1334,56 @@ EXPORT_SYMBOL(mmc_resume_host);
#endif
+/**
+ * mmc_release_power - remove power from the card
+ * @host: mmc host
+ */
+int mmc_release_power(struct mmc_host *host)
+{
+ int err = 0;
+
+ mmc_bus_get(host);
+ if (host-bus_ops !host-bus_dead) {
+ if (host-bus_ops-suspend)
+ err = host-bus_ops-suspend(host);
+ /* it's ok not to have a suspend handler */
+ err = err == -ENOSYS ? 0 : err;
+ }
+ mmc_bus_put(host);
+
+ if (!err)
+ mmc_power_off(host);
+
+ return err;
+}
+EXPORT_SYMBOL_GPL(mmc_release_power);
+
+/*
+ * mmc_claim_power - power up card
+ * @host: mmc host
+ */
+int mmc_claim_power(struct mmc_host *host)
+{
+ int err = 0;
+
+ mmc_bus_get(host);
+
+ mmc_power_up(host);
+ mmc_select_voltage(host, host-ocr);
+
+ BUG_ON(!host-bus_ops-resume);
+ err = host-bus_ops-resume(host);
+ if (err) {
+ printk(KERN_WARNING %s: error %d during resume
+ (card was removed?)\n,
+ mmc_hostname(host), err);
+ }
+ mmc_bus_put(host);
+
+ return err;
+}
+EXPORT_SYMBOL_GPL(mmc_claim_power);
+
static int __init mmc_init(void)
{
int ret;
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index 37739f5..79e6fa1 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -15,6 +15,7 @@
#include linux/mmc/card.h
#include linux/mmc/sdio.h
#include linux/mmc/sdio_func.h
+#include asm/atomic.h
#include core.h
#include bus.h
@@ -72,6 +73,10 @@ static int sdio_init_func(struct mmc_card *card, unsigned
int fn)
card-sdio_func[fn - 1] = func;
+ /* For each SDIO function initialized, increase the power claim
+* reference count of the card */
+ atomic_inc(card-power_claims);
+
return 0;
fail:
diff --git a/drivers/mmc/core/sdio_io.c b/drivers/mmc/core/sdio_io.c
index 0f687cd..28ebc16 100644
--- a/drivers/mmc/core/sdio_io.c
+++ b/drivers/mmc/core/sdio_io.c
@@ -17,6 +17,56 @@
#include sdio_ops.h
/**
+ * sdio_release_power - allow to release power of a certain SDIO function
+ * @func: SDIO function that is accessed
+ *
+ * Indicate to the core SDIO layer that we're not requiring that the
+ * function remain powered. If all functions for the card are in the
+ * same no power state, then the host controller can remove power from
+ * the card. Note: the function driver must preserve hardware states if
+ * necessary.
+ */
+int sdio_release_power(struct sdio_func *func)
+{
+ int ret = 0;
+ BUG_ON(!func);
+ BUG_ON(!func-card);
+
+ if (atomic_dec_and_test(func-card-power_claims))
+ ret = mmc_release_power(func-card-host);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(sdio_release_power);
+
+/*
+ * sdio_claim_power - request power for a certain SDIO function
+ * @func: SDIO function that is accessed
+ *
+ * Indicate to the core SDIO layer that we want power back for this
+ * SDIO function. The power may or may not actually have been removed
+ * since last call to sdio_release_power(), so the function driver must
+ * not assume any preserved state at the hardware level and re-perform
+ * all the necessary hardware config. This function returns 0 when
+ * power is actually restored, or some error code if this cannot be
+ * achieved. One error reason might be that the card is
[PATCH v2 20/20] wireless: wl1271: call SDIO claim/release power API
call SDIO claim/release power API to turn the wl1271
power on and off
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/net/wireless/wl12xx/wl1271_sdio.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1271_sdio.c
b/drivers/net/wireless/wl12xx/wl1271_sdio.c
index 5967718..a7e9ace 100644
--- a/drivers/net/wireless/wl12xx/wl1271_sdio.c
+++ b/drivers/net/wireless/wl12xx/wl1271_sdio.c
@@ -152,11 +152,13 @@ static int wl1271_sdio_set_power(struct wl1271 *wl, bool
enable)
* alive.
*/
if (enable) {
+ sdio_claim_power(func);
sdio_claim_host(func);
sdio_enable_func(func);
} else {
sdio_disable_func(func);
sdio_release_host(func);
+ sdio_release_power(func);
}
return 0;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 18/20] mmc: sdio: enable a default power off mode of the card
Add support for an SDIO device to stay powered off even without
the presence of an SDIO function driver. A host should explicitly
ask for it by means of MMC_CAP_DONT_POWER_CARD, and the SDIO
function driver should know it needs to call sdio_claim_power
before accessing the device.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/mmc/core/sdio.c | 15 +--
include/linux/mmc/host.h |1 +
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index 5c0fbfa..164353f 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -80,8 +80,9 @@ static int sdio_init_func(struct mmc_card *card, unsigned int
fn)
return ret;
/* For each SDIO function initialized, increase the power claim
-* reference count of the card */
- atomic_inc(card-power_claims);
+* reference count of the card, unless explicitly requested not to */
+ if (!(card-host-caps MMC_CAP_DONT_POWER_CARD))
+ atomic_inc(card-power_claims);
return 0;
@@ -607,6 +608,16 @@ int mmc_attach_sdio(struct mmc_host *host, u32 ocr)
mmc_release_host(host);
/*
+* If power is not required for this card, power it off.
+* The sdio function will need to call sdio_claim_power.
+*/
+ if (!atomic_read(card-power_claims)) {
+ pr_info(%s: power is not claimed, releasing\n,
+ mmc_hostname(host));
+ mmc_release_power(host);
+ }
+
+ /*
* First add the card to the driver model...
*/
err = mmc_add_card(host-card);
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 3675d58..756cf38 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -155,6 +155,7 @@ struct mmc_host {
#define MMC_CAP_DISABLE(1 7)/* Can the host be
disabled */
#define MMC_CAP_NONREMOVABLE (1 8)/* Nonremovable e.g. eMMC */
#define MMC_CAP_WAIT_WHILE_BUSY(1 9)/* Waits while card is
busy */
+#define MMC_CAP_DONT_POWER_CARD(1 10) /* Keep the card
powered off */
mmc_pm_flag_t pm_caps;/* supported pm features */
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 19/20] omap: zoom: keep the MMC3 wl1271 device powered off
Keep the MMC3 wl1271 WLAN device powered off until its
SDIO function driver requests otherwise.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/mach-omap2/board-zoom-peripherals.c |1 +
arch/arm/mach-omap2/hsmmc.c |3 +++
arch/arm/mach-omap2/hsmmc.h |1 +
arch/arm/plat-omap/include/plat/mmc.h|3 +++
drivers/mmc/host/omap_hsmmc.c|3 +++
5 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index 3230801..3ab9125 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -217,6 +217,7 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
.gpio_wp= -EINVAL,
.gpio_cd= -EINVAL,
.ocr_mask = MMC_VDD_165_195,
+ .dont_power_card = true,
.priv_data = omap_zoom_wlan_data,
},
{} /* Terminator */
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index f06ddd2..24c4144 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -284,6 +284,9 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info
*controllers)
if (c-vcc_aux_disable_is_sleep)
mmc-slots[0].vcc_aux_disable_is_sleep = 1;
+ if (c-dont_power_card)
+ mmc-slots[0].dont_power_card = 1;
+
mmc-slots[0].priv_data = c-priv_data;
/* NOTE: MMC slots should have a Vcc regulator set up.
diff --git a/arch/arm/mach-omap2/hsmmc.h b/arch/arm/mach-omap2/hsmmc.h
index 434a3ed..e200786 100644
--- a/arch/arm/mach-omap2/hsmmc.h
+++ b/arch/arm/mach-omap2/hsmmc.h
@@ -23,6 +23,7 @@ struct omap2_hsmmc_info {
int ocr_mask; /* temporary HACK */
/* Remux (pad configuation) when powering on/off */
void (*remux)(struct device *dev, int slot, int power_on);
+ booldont_power_card;/* keep card power off at boot (default is n)*/
void*priv_data; /* private data to SDIO function driver */
};
diff --git a/arch/arm/plat-omap/include/plat/mmc.h
b/arch/arm/plat-omap/include/plat/mmc.h
index 9db1617..d042494 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -140,6 +140,9 @@ struct omap_mmc_platform_data {
unsigned int ban_openended:1;
+ /* keep this card powered off at boot (default is n) */
+ unsigned int dont_power_card:1;
+
/* card private data that should be used by function driver */
void *priv_data;
} slots[OMAP_MMC_MAX_SLOTS];
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 4ac548e..4fb6634 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2157,6 +2157,9 @@ static int __init omap_hsmmc_probe(struct platform_device
*pdev)
if (mmc_slot(host).nonremovable)
mmc-caps |= MMC_CAP_NONREMOVABLE;
+ if (mmc_slot(host).dont_power_card)
+ mmc-caps |= MMC_CAP_DONT_POWER_CARD;
+
mmc_set_embedded_data(mmc, mmc_slot(host).priv_data);
omap_hsmmc_conf_bus_power(host);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/20] sdio: add TI + wl1271 ids
Hi Ohad, Add SDIO IDs for TI and for TI's wl1271 wlan device. Signed-off-by: Ohad Ben-Cohen o...@wizery.com --- include/linux/mmc/sdio_ids.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/include/linux/mmc/sdio_ids.h b/include/linux/mmc/sdio_ids.h index 33b2ea0..0d313c6 100644 --- a/include/linux/mmc/sdio_ids.h +++ b/include/linux/mmc/sdio_ids.h @@ -43,4 +43,7 @@ #define SDIO_DEVICE_ID_SIANO_NOVA_A0 0x1100 #define SDIO_DEVICE_ID_SIANO_STELLAR 0x5347 +#define SDIO_VENDOR_ID_TI0x0097 +#define SDIO_DEVICE_ID_TI_WL1271 0x4076 + are we still doing this non-sense for no real reason. What is so wrong with keeping the IDs inside the driver code? Personally I don't even see a point for these ID defines at all. Just use the bare numbers in SDIO_DEVICE and put a comment above what kind of device this is. Regards Marcel -- 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 10/20] omap: zoom: add fixed regulator device for wlan
On Wed, Jul 21, 2010 at 08:33:44PM +0300, Ohad Ben-Cohen wrote:
+static struct regulator_consumer_supply zoom_vmmc3_supply = {
+ .supply = vmmc,
+};
This looks like a misconfiguration on the consumer - I'd strongly expect
the consumer to have a dev_name specified also with the name being in
terms of the consumer device.
--
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 1/3 v3] mm: iommu: An API to unify IOMMU, CPU and device memory management
* This is difficult to achieve without remapping kernel memory using L2 page tables, so we can unmap pages on 4K page granularity. That's going to increase TLB overhead and result in lower system performance as there'll be a greater number of MMU misses. * Given how the buffers in question can be on the orders of tens of MB (and I don't think they will ever be less than 1MB), would we be able to get the desired effect by unmapping and then remapping on a 1MB granularity (ie, L1 sections)? It seems to me like this should be sufficient, and would not require using L2 mappings. Thoughts? Thanks Steve Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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 19/20] omap: zoom: keep the MMC3 wl1271 device powered off
Ohad,
-Original Message-
From: Ohad Ben-Cohen [mailto:o...@wizery.com]
Sent: Wednesday, July 21, 2010 12:34 PM
To: linux-wirel...@vger.kernel.org; linux-...@vger.kernel.org;
linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org; li...@arm.linux.org.uk; Chikkature
Rajashekar, Madhusudhan; Luciano Coelho; a...@linux-foundation.org; San Mehat;
Roger Quadros; Tony Lindgren; Nicolas Pitre; Pandita, Vikram; Kalle Valo; Ohad
Ben-Cohen
Subject: [PATCH v2 19/20] omap: zoom: keep the MMC3 wl1271 device powered off
Keep the MMC3 wl1271 WLAN device powered off until its
SDIO function driver requests otherwise.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/mach-omap2/board-zoom-peripherals.c |1 +
arch/arm/mach-omap2/hsmmc.c |3 +++
arch/arm/mach-omap2/hsmmc.h |1 +
arch/arm/plat-omap/include/plat/mmc.h|3 +++
drivers/mmc/host/omap_hsmmc.c|3 +++
5 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index 3230801..3ab9125 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -217,6 +217,7 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
.gpio_wp= -EINVAL,
.gpio_cd= -EINVAL,
.ocr_mask = MMC_VDD_165_195,
+ .dont_power_card = true,
.priv_data = omap_zoom_wlan_data,
},
{} /* Terminator */
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index f06ddd2..24c4144 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -284,6 +284,9 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info
*controllers)
if (c-vcc_aux_disable_is_sleep)
mmc-slots[0].vcc_aux_disable_is_sleep = 1;
+ if (c-dont_power_card)
+ mmc-slots[0].dont_power_card = 1;
+
mmc-slots[0].priv_data = c-priv_data;
/* NOTE: MMC slots should have a Vcc regulator set up.
diff --git a/arch/arm/mach-omap2/hsmmc.h b/arch/arm/mach-omap2/hsmmc.h
index 434a3ed..e200786 100644
--- a/arch/arm/mach-omap2/hsmmc.h
+++ b/arch/arm/mach-omap2/hsmmc.h
@@ -23,6 +23,7 @@ struct omap2_hsmmc_info {
int ocr_mask; /* temporary HACK */
/* Remux (pad configuation) when powering on/off */
void (*remux)(struct device *dev, int slot, int power_on);
+ booldont_power_card;/* keep card power off at boot (default is n)*/
void*priv_data; /* private data to SDIO function driver */
};
diff --git a/arch/arm/plat-omap/include/plat/mmc.h
b/arch/arm/plat-omap/include/plat/mmc.h
index 9db1617..d042494 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -140,6 +140,9 @@ struct omap_mmc_platform_data {
unsigned int ban_openended:1;
+ /* keep this card powered off at boot (default is n) */
+ unsigned int dont_power_card:1;
+
/* card private data that should be used by function driver */
void *priv_data;
} slots[OMAP_MMC_MAX_SLOTS];
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 4ac548e..4fb6634 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2157,6 +2157,9 @@ static int __init omap_hsmmc_probe(struct platform_device
*pdev)
if (mmc_slot(host).nonremovable)
mmc-caps |= MMC_CAP_NONREMOVABLE;
+ if (mmc_slot(host).dont_power_card)
+ mmc-caps |= MMC_CAP_DONT_POWER_CARD;
+
mmc_set_embedded_data(mmc, mmc_slot(host).priv_data);
omap_hsmmc_conf_bus_power(host);
--
1.7.0.4
[Benzy Gabay] small comment: Please make sure that all 127x related changes are
not bounded only to MMC3.
On OMAP4 WLAN is used on MMC5.
--
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] OMAP2: OMAPFB: Fix invalid bpp for PAL and NTSC modes
omapfb_mode_to_timings() sets the bpp to 0 when bootarg omapfb.mode is set to
either pal or ntsc. This patch corrects this by setting the bpp to 24, as
would be done if omapdss_default_get_recommended_bpp() would be called
Signed-off-by: Maurus Cuelenaere mcuelena...@gmail.com
---
drivers/video/omap2/omapfb/omapfb-main.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
b/drivers/video/omap2/omapfb/omapfb-main.c
index 4b4506d..500458e 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -1968,11 +1968,11 @@ static int omapfb_mode_to_timings(const char *mode_str,
#ifdef CONFIG_OMAP2_DSS_VENC
if (strcmp(mode_str, pal) == 0) {
*timings = omap_dss_pal_timings;
- *bpp = 0;
+ *bpp = 24;
return 0;
} else if (strcmp(mode_str, ntsc) == 0) {
*timings = omap_dss_ntsc_timings;
- *bpp = 0;
+ *bpp = 24;
return 0;
}
#endif
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Question about armv7(cortex-a9) dcache initialization.
In the ARM Cortex-A9 TRM, I found a note in chapter 6.1 Note: You must invalidate the instruction cache, the data cache, and BTAC before using them. You are not required to invalidate the main TLB, even though it is recommended for safety reasons. This ensures compatibility with future revisions of the processor. But the kernel does.. ( __v7_setup in proc-v7.S ) clean invalidate before turning on the MMU, not just 'invalidate'. If dcache tagdata ram has garbage data when power up, I think some dirty data lines can be flushed into to L2 or L3 memory because kernel does clean. And It can pollute the memory. Is it possible in cortex-A9? 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: [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager
On Wed, Jul 14, 2010 at 10:59:43AM +0900, FUJITA Tomonori wrote: On Tue, 13 Jul 2010 10:02:23 +0100 Zach Pfeffer said this new VCM infrastructure can be useful for video4linux. However, I don't think we need 3,000-lines another abstraction layer to solve video4linux's issue nicely. Its only 3000 lines because I haven't converted the code to use function pointers. I can't find any reasonable reasons that we need to merge VCM; seems that the combination of the current APIs (or with some small extensions) can work for the issues that VCM tries to solve. Getting back to the point. There is no API that can handle large buffer allocation and sharing with low-level attribute control for virtual address spaces outside the CPU. At this point if you need to work with big buffers, 1 MB and 16 MB etc, and map those big buffers to non-CPU virtual spaces you need to explicitly carve them out and set up the mappings and sharing by hand. Its reasonable to have an API that can do this especially since IOMMUs are going to become more prevalent. The DMA API et al. take a CPU centric view of virtual space management, sharing has to be explicitly written and external virtual space management is left up to device driver writers. Given a system where each device has an IOMMU or a MMU the whole concept of a scatterlist goes away. The VCM API gets a jump on it. -- 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 1/3 v3] mm: iommu: An API to unify IOMMU, CPU and device memory management
On Tue, Jul 20, 2010 at 09:44:12PM -0400, Timothy Meade wrote: On Tue, Jul 20, 2010 at 8:44 PM, Zach Pfeffer zpfef...@codeaurora.org wrote: On Mon, Jul 19, 2010 at 05:21:35AM -0400, Tim HRM wrote: On Fri, Jul 16, 2010 at 8:01 PM, Larry Bassel lbas...@codeaurora.org wrote: On 16 Jul 10 08:58, Russell King - ARM Linux wrote: On Thu, Jul 15, 2010 at 08:48:36PM -0400, Tim HRM wrote: Interesting, since I seem to remember the MSM devices mostly conduct IO through regions of normal RAM, largely accomplished through ioremap() calls. Without more public domain documentation of the MSM chips and AMSS interfaces I wouldn't know how to avoid this, but I can imagine it creates a bit of urgency for Qualcomm developers as they attempt to upstream support for this most interesting SoC. As the patch has been out for RFC since early April on the linux-arm-kernel mailing list (Subject: [RFC] Prohibit ioremap() on kernel managed RAM), and no comments have come back from Qualcomm folk. We are investigating the impact of this change on us, and I will send out more detailed comments next week. The restriction on creation of multiple V:P mappings with differing attributes is also fairly hard to miss in the ARM architecture specification when reading the sections about caches. Larry Bassel -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. Hi Larry and Qualcomm people. I'm curious what your reason for introducing this new api (or adding to dma) is. ?Specifically how this would be used to make the memory mapping of the MSM chip dynamic in contrast to the fixed _PHYS defines in the Android and Codeaurora trees. The MSM has many integrated engines that allow offloading a variety of workloads. These engines have always addressed memory using physical addresses, because of this we had to reserve large (10's MB) buffers at boot. These buffers are never freed regardless of whether an engine is actually using them. As you can imagine, needing to reserve memory for all time on a device that doesn't have a lot of memory in the first place is not ideal because that memory could be used for other things, running apps, etc. To solve this problem we put IOMMUs in front of a lot of the engines. IOMMUs allow us to map physically discontiguous memory into a virtually contiguous address range. This means that we could ask the OS for 10 MB of pages and map all of these into our IOMMU space and the engine would still see a contiguous range. I see. Much like I suspected, this is used to replace the static regime of the earliest Android kernel. You mention placing IOMMUs in front of the A11 engines, you are involved in this architecture as an engineer or similar? I'm involved to the extent of designing and implementing VCM and, finding it useful for this class of problems, trying push it upstream. Is there a reason a cooperative approach using RPC or another mechanism is not used for memory reservation, this is something that can be accomplished fully on APPS side? It can be accomplished a few ways. At this point we let the application processor manage the buffers. Other cooperative approaches have been talked about. As you can see in the short, but voluminous cannon of MSM Linux support there is a degree of RPC used to communicate with other nodes in the system. As time progresses the cannon of code shows this usage going down. In reality, limitations in the hardware meant that we needed to map memory using larger mappings to minimize the number of TLB misses. This, plus the number of IOMMUs and the extreme use cases we needed to design for led us to a generic design. This generic design solved our problem and the general mapping problem. We thought other people, who had this same big-buffer interoperation problem would also appreciate a common API that was built with their needs in mind so we pushed our idea up. I'm also interested in how this ability to map memory regions as files for devices like KGSL/DRI or PMEM might work and why this is better suited to that purpose than existing methods, where this fits into camera preview and other issues that have been dealt with in these trees in novel ways (from my perspective). The file based approach was driven by Android's buffer passing scheme and the need to write userspace drivers for multimedia, etc... So the Android file backed approach is obiviated by GEM and other mechanisms? Aye. Thanks you for you help, Timothy Meade -tmzt #htc-linux (facebook.com/HTCLinux) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/3] OMAP: DSS2: Zorder enum in display.h
-Original Message-
From: Premi, Sanjeev
Sent: Wednesday, July 21, 2010 7:47 PM
To: Taneja, Archit; tomi.valkei...@nokia.com
Cc: linux-omap@vger.kernel.org; Semwal, Sumit; Nilofer,
Samreen; Taneja, Archit
Subject: RE: [PATCH 1/3] OMAP: DSS2: Zorder enum in display.h
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Archit Taneja
Sent: Monday, July 19, 2010 5:40 PM
To: tomi.valkei...@nokia.com
Cc: linux-omap@vger.kernel.org; Semwal, Sumit; Nilofer, Samreen;
Taneja, Archit
Subject: [PATCH 1/3] OMAP: DSS2: Zorder enum in display.h
From: Sumit Semwal sumit.sem...@ti.com
Add Zorder enum in display.h
Patches 1 and 2 in the series can easily be conbined into one.
Separating few line changes in header file from
implementation across 2 patches isn't useful.
[archit] We are introducing a new DSS feature for OMAP4 in every
patch series. In order to clearly explain the feature introduced,
the first patch of every series makes changes on in the display.h
header which is central to the DSS2 code.
If this is not a accepted norm or a strong enough reason to have a
separate small patch, I can rework these series, I would need more
comments from others though.
snap
+enum omap_overlay_zorder {
+ OMAP_DSS_OVL_ZORDER_0 = 0x0,
+ OMAP_DSS_OVL_ZORDER_1 = 0x1,
+ OMAP_DSS_OVL_ZORDER_2 = 0x2,
+ OMAP_DSS_OVL_ZORDER_3 = 0x3,
+};
Is _DSS_ really needed in these emums? considering that
enum itself doesn't contain _dss_ in its name.
[archit] I agree with this, but the present header is inconsistent
with the point you have made, there are other enums which don't have
_dss_ but have _DSS_ in its enum members. We should try to make
this uniform (unless there is a motive behind it).
~sanjeev
Regards,
Archit
--
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 1/3 v3] mm: iommu: An API to unify IOMMU, CPU and device memory management
On Mon, Jul 19, 2010 at 12:44:49AM -0700, Eric W. Biederman wrote: Zach Pfeffer zpfef...@codeaurora.org writes: On Thu, Jul 15, 2010 at 09:55:35AM +0100, Russell King - ARM Linux wrote: On Wed, Jul 14, 2010 at 06:29:58PM -0700, Zach Pfeffer wrote: The VCM ensures that all mappings that map a given physical buffer: IOMMU mappings, CPU mappings and one-to-one device mappings all map that buffer using the same (or compatible) attributes. At this point the only attribute that users can pass is CACHED. In the absence of CACHED all accesses go straight through to the physical memory. So what you're saying is that if I have a buffer in kernel space which I already have its virtual address, I can pass this to VCM and tell it !CACHED, and it'll setup another mapping which is not cached for me? Not quite. The existing mapping will be represented by a reservation from the prebuilt VCM of the VM. This reservation has been marked non-cached. Another reservation on a IOMMU VCM, also marked non-cached will be backed with the same physical memory. This is legal in ARM, allowing the vcm_back call to succeed. If you instead passed cached on the second mapping, the first mapping would be non-cached and the second would be cached. If the underlying architecture supported this than the vcm_back would go through. How does this compare with the x86 pat code? First, thanks for asking this question. I wasn't aware of the x86 pat code and I got to read about it. From my initial read the VCM differs in 2 ways: 1. The attributes are explicitly set on virtual address ranges. These reservations can then map physical memory with these attributes. 2. We explicitly allow multiple mappings (as long as the attributes are compatible). One such mapping may come from a IOMMU's virtual address space while another comes from the CPUs virtual address space. These mappings may exist at the same time. You are aware that multiple V:P mappings for the same physical page with different attributes are being outlawed with ARMv6 and ARMv7 due to speculative prefetching. The cache can be searched even for a mapping specified as 'normal, uncached' and you can get cache hits because the data has been speculatively loaded through a separate cached mapping of the same physical page. I didn't know that. Thanks for the heads up. FYI, during the next merge window, I will be pushing a patch which makes ioremap() of system RAM fail, which should be the last core code creator of mappings with different memory types. This behaviour has been outlawed (as unpredictable) in the architecture specification and does cause problems on some CPUs. That's fair enough, but it seems like it should only be outlawed for those processors on which it breaks. To my knowledge mismatch of mapping attributes is a problem on most cpus on every architecture. I don't see it making sense to encourage coding constructs that will fail in the strangest most difficult to debug ways. Yes it is a problem, as Russell has brought up, but there's something I probably haven't communicated well. I'll use the following example: There are 3 devices: A CPU, a decoder and a video output device. All 3 devices need to map the same 12 MB buffer at the same time. Once this buffer has served its purpose it gets freed and goes back into the pool of big buffers. When the same usage case exists again the buffer needs to get reallocated and the same devices need to map to it. This usage case does exist, not only for Qualcomm but for all of these SoC media engines that have started running Linux. The VCM API attempts to cover this case for the Linux kernel. -- 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 1/3 v3] mm: iommu: An API to unify IOMMU, CPU and device memory management
On Wed, Jul 21, 2010 at 10:44:37AM +0900, FUJITA Tomonori wrote: On Tue, 20 Jul 2010 15:20:01 -0700 Zach Pfeffer zpfef...@codeaurora.org wrote: I'm not saying that it's reasonable to pass (or even allocate) a 1MB buffer via the DMA API. But given a bunch of large chunks of memory, is there any API that can manage them (asked this on the other thread as well)? What is the problem about mapping a 1MB buffer with the DMA API? Possibly, an IOMMU can't find space for 1MB but it's not the problem of the DMA API. This goes to the nub of the issue. We need a lot of 1 MB physically contiguous chunks. The system is going to fragment and we'll never get our 12 1 MB chunks that we'll need, since the DMA API allocator uses the system pool it will never succeed. For this reason we reserve a pool of 1 MB chunks (and 16 MB, 64 KB etc...) to satisfy our requests. This same use case is seen on most embedded media engines that are getting built today. -- 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 1/3 v3] mm: iommu: An API to unify IOMMU, CPU and device memory management
On Wed, 21 Jul 2010 21:30:34 -0700 Zach Pfeffer zpfef...@codeaurora.org wrote: On Wed, Jul 21, 2010 at 10:44:37AM +0900, FUJITA Tomonori wrote: On Tue, 20 Jul 2010 15:20:01 -0700 Zach Pfeffer zpfef...@codeaurora.org wrote: I'm not saying that it's reasonable to pass (or even allocate) a 1MB buffer via the DMA API. But given a bunch of large chunks of memory, is there any API that can manage them (asked this on the other thread as well)? What is the problem about mapping a 1MB buffer with the DMA API? Possibly, an IOMMU can't find space for 1MB but it's not the problem of the DMA API. This goes to the nub of the issue. We need a lot of 1 MB physically contiguous chunks. The system is going to fragment and we'll never get our 12 1 MB chunks that we'll need, since the DMA API allocator uses the system pool it will never succeed. For this reason we reserve a pool of 1 MB chunks (and 16 MB, 64 KB etc...) to satisfy our requests. This same use case is seen on most embedded media engines that are getting built today. We don't need a new abstraction to reserve some memory. If you want pre-allocated memory pool per device (and share them with some), the DMA API can for coherent memory (see dma_alloc_from_coherent). You can extend the DMA API if necessary. -- 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 3/3] mm: iommu: The Virtual Contiguous Memory Manager
On Wed, 21 Jul 2010 20:50:26 -0700 Zach Pfeffer zpfef...@codeaurora.org wrote: On Wed, Jul 14, 2010 at 10:59:43AM +0900, FUJITA Tomonori wrote: On Tue, 13 Jul 2010 10:02:23 +0100 Zach Pfeffer said this new VCM infrastructure can be useful for video4linux. However, I don't think we need 3,000-lines another abstraction layer to solve video4linux's issue nicely. Its only 3000 lines because I haven't converted the code to use function pointers. The main point is adding a new abstraction that don't provide the huge benefit. -- 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
