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? 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 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] omap: hsmmc funtionality breaks when CONFIG_PM not define
-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. So if CONFIG_PM is not enable, then it should do simple clock disable/enable, and not via the power state machine. 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 http://vger.kernel.org/majordomo-info.html 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
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? 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 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 http://vger.kernel.org/majordomo-info.html Regards, Ghorai -- 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 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] omap: hsmmc funtionality breaks when CONFIG_PM not define
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? Because issue is iclk/fclk is quite depended on PRCM framework when we are using omap_hsmmc_ps_ops operation table. 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 http://vger.kernel.org/majordomo-info.html Regards, Ghorai -- 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 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] omap: hsmmc funtionality breaks when CONFIG_PM not define
-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.
2. static const struct mmc_host_ops omap_hsmmc_ps_ops = {
}
- this with CONFIG_PM, assumed.
a. And you feel we should remove #1
b. use omap_hsmmc_ps_ops default.
c. And it should work in all case?
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 http://vger.kernel.org/majordomo-info.html
Regards,
Ghorai
--
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 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
configuration warnings with omap_3630sdp_defconfig in 2.6.35-rc5
While trying to build omap_3630sdp_defconfig on Linus's 2.6.35-rc5, I get these warnings.. I understand these could be related to the recent defconfig changes. I will try to investigate; posted here to know if anyone has found a fix already.. -- scripts/kconfig/conf -s arch/arm/Kconfig can't copy type 0 warning: (USB_MUSB_HDRC_HCD USB_SUPPORT USB_MUSB_HDRC (USB_MUSB_HOST || USB_MUSB_OTG) USB_GADGET_MUSB_HDRC || USB_MUSB_OTG choice USB USB_GADGET PM EXPERIMENTAL) selects USB_OTG which has unmet direct dependencies (USB_GADGET_OMAP ARCH_OMAP_OTG USB_OHCI_HCD) warning: (USB_MUSB_HDRC_HCD USB_SUPPORT USB_MUSB_HDRC (USB_MUSB_HOST || USB_MUSB_OTG) USB_GADGET_MUSB_HDRC || USB_MUSB_OTG choice USB USB_GADGET PM EXPERIMENTAL) selects USB_OTG which has unmet direct dependencies (USB_GADGET_OMAP ARCH_OMAP_OTG USB_OHCI_HCD) -- Regards, Venkat. -- 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 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, but the F9, F10 and F11 key events are never reported. That might be because those keys are not wired up to anything though. All keys on the keyboard, as well as the F7 and F8 keys (volume up and down on the of the case) 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. -- 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
RE: [PATCH] omap: hsmmc funtionality breaks when CONFIG_PM not define
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?
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
Re: [PATCH] omap: hsmmc funtionality breaks when CONFIG_PM not define
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
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,
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)
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
DSS2: RFBI: how to make it work?
Hi, all!
I'm trying to rewrite my old driver to DSS2. The driver is for small
176x220 module attached over RFBI interface
on OMAP3525. It basically works with old kernel and drivers/video/omap/*.
I still can't make it work, so is it known which code is necessary to
initialize a panel? I tried
to compare APIs with old and new subsystems and can't see what I am doing wrong.
In original code, I just init rfbi and dispc, and then directly write
to panel (commands and their parameters).
The same code with new API does not seem to produce any results.
Display stays uninitialized,
so commands seem not to get to it.
The code:
...
static struct omap_video_timings panel_timings = {
.x_res = 176,
.y_res = 220,
};
static int panel_probe(struct omap_dss_device *dssdev)
{
int err;
struct rfbi_timings t;
pr_debug(%s\n, __func__);
dssdev-panel.config = OMAP_DSS_LCD_TFT |
OMAP_DSS_LCD_IVS | OMAP_DSS_LCD_IHS;
dssdev-panel.timings = panel_timings;
dssdev-phy.rfbi.channel = 0;
dssdev-ctrl.pixel_size = 24;
dssdev-phy.rfbi.data_lines = 8;
hx8340_dss = dssdev;
t.cs_on_time = 0;
t.we_on_time = t.cs_on_time + 0;
t.re_on_time = t.we_on_time + 0;
t.we_off_time = t.we_on_time + 15000;
t.re_off_time = t.we_off_time + 15000;
t.access_time = 0;
t.cs_off_time = t.we_off_time + 0;
t.we_cycle_time = t.cs_off_time + 1;
t.re_cycle_time = t.we_cycle_time + 15000;
t.cs_pulse_width = 41000;
dssdev-ctrl.rfbi_timings = t;
if (dssdev-platform_enable)
dssdev-platform_enable(dssdev);
.
return 0;
}
static void cmd_data(u8 cmd, u8 data)
{
omap_rfbi_write_command(cmd, 1);
omap_rfbi_write_data(data, 1);
}
static int panel_power_on(struct omap_dss_device *dssdev)
{
int err;
err = omapdss_rfbi_display_enable(dssdev);
if (err 0)
return err;
if (dssdev-platform_enable) {
err = dssdev-platform_enable(dssdev);
if (err)
return err;
}
cmd_data(0x18, 0x44);
cmd_data(0x1B, 0x44);
.
return 0;
}
static int panel_enable(struct omap_dss_device *dssdev)
{
panel_power_on(dssdev);
dssdev-state = OMAP_DSS_DISPLAY_ACTIVE;
return 0;
}
...
static void panel_get_timings(struct omap_dss_device *dssdev,
struct omap_video_timings *timings)
{
*timings = dssdev-panel.timings;
}
static int panel_check_timings(struct omap_dss_device *dssdev,
struct omap_video_timings *timings)
{
return 0;
}
struct omap_dss_driver hx8340_panel_driver = {
.probe = panel_probe,
.enable = panel_enable,
...
.get_timings= panel_get_timings,
.check_timings = panel_check_timings,
...
.driver = {
.name = custom-panel,
.owner = THIS_MODULE,
},
};
Any ideas on what is wrong with initialization?
Driver works with old susbystem, but it is very messed-up and requires
patching of subsystem itself.
I skip timer-based auto-update setup here, because I want to make
initialization work first and then move
to that portion later.
Thanks a lot,
S.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/5] omap:hwspinlock support-omap4
Santosh, Hari Kanigeri (1): omap:hwspinlocks-ensure the order of registration Simon Que (4): omap:hwmod-hwspinlock-enable omap:hwspinlock-define HWSPINLOCK base address I think you should fold patch 1/5 , 2/5 into patch 3/5. At least patch 2/5 o.w git-bisect will break Can you please explain why this would break ? Thank you, Best regards, Hari -- 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: Omap3 omap3_clk_lock_dpll5() problem
Adding debug to bootargs
( Kernel command line: mem=128M console=ttyS2,115200n8 noinitrd
root=/dev/mtdblock6 rw rootfstype=jffs2 debug
ip=192.168.90.101:192.168.90.230:192.168.90.1:255.255.255.0::eth0:on
mac=00:19:6f:cc:cc:dd )
doesn't change the output. Do I need a recompile with some kernel config params?
I found some CPU_FREQ_DEBUG , DEBUG_LL PM_DEBUG, OMAP_LL_DEBUG_NONE,
DEBUG_KERNEL , DEBUG_INFO which might be involved.
The frequencies the board is running are 12MHz crystal, 322MHz (or
166MHz core) and 600MHz MPU.
Sounds not unusual to me (maybe the 600MHz is not as standard as 550MHz).
I also found this in clock34xx_data.c
/* REVISIT: Not yet ready for OMAP3 */
#if 0
/* Check the MPU rate set by bootloader */
clkrate = omap2_get_dpll_rate_24xx(dpll_ck);
for (prcm = rate_table; prcm-mpu_speed; prcm++) {
if (!(prcm-flags cpu_mask))
continue;
if (prcm-xtal_speed != sys_ck.rate)
continue;
if (prcm-dpll_speed = clkrate)
break;
}
curr_prcm_set = prcm;
#endif
2010/7/16 Gadiyar, Anand gadi...@ti.com:
Thanks Anand,
I don't have any USB working on the board.
If this only for this USB - is it save to comment that out?
If you're not using EHCI/OHCI, it ought to be safe to comment
it out.
My best guess is that you are using some non-standard frequencies
and you've made changes to the code/bootloader that cause this
path to not be able to find a good value to program in the DPLL
configuration registers.
Quite possibly, this is also the cause of your other problems.
Can you explain what you are doing so we understand the issue
better?
- Anand
--
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
On Tuesday, July 20, 2010 04:06:08 am Laurent Pinchart wrote: Hi Dmitry, 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? 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. -- Dmitry -- 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 0/2] omap:mailbox-provide multiple readers support
This patch series provides the support for mutiple readers per mailbox instance. The first patch is mostly cleanup and the second patch consists of the changes to provide multiple readers support. Hari Kanigeri (2): omap:mailbox-make mailbox reference counter atomic omap:mailbox-provide multiple reader support arch/arm/plat-omap/include/plat/mailbox.h |6 ++- arch/arm/plat-omap/mailbox.c | 84 +++-- 2 files changed, 48 insertions(+), 42 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[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) {
+ mbox_queue_free(mbox-txq);
+ mbox_queue_free(mbox-rxq);
+ free_irq(mbox-irq, mbox);
+ }
if (likely(mbox-ops-shutdown)) {
if (atomic_dec_return(mbox_refcount) == 0)
@@ -314,7 +319,7 @@ static struct omap_mbox **find_mboxes(const char *name)
return p;
}
-struct omap_mbox *omap_mbox_get(const char *name)
+struct omap_mbox *omap_mbox_get(const char *name, struct notifier_block *nb)
{
struct omap_mbox *mbox;
int ret;
@@ -325,19 +330,21 @@ struct omap_mbox *omap_mbox_get(const char *name)
spin_unlock(mboxes_lock);
return ERR_PTR(-ENOENT);
}
-
spin_unlock(mboxes_lock);
ret = omap_mbox_startup(mbox);
if (ret)
return
Re: [RFC 1/3 v3] mm: iommu: An API to unify IOMMU, CPU and device memory management
On Tue, Jul 20, 2010 at 09:54:33PM +0100, Russell King - ARM Linux wrote: On Tue, Jul 20, 2010 at 01:45:17PM -0700, Zach Pfeffer wrote: You can also conflict in access permissions which can and do conflict (which are what multiple mappings are all about...some buffer can get some access, while others get different access). Access permissions don't conflict between mappings - each mapping has unique access permissions. Yes. Bad choice of words. The VCM API allows the same memory to be mapped as long as it makes sense and allows those attributes that can change to be specified. It could be the alternative, globally applicable approach, your looking for and request in your patch. I very much doubt it - there's virtually no call for creating an additional mapping of existing kernel memory with different permissions. The only time kernel memory gets remapped is with vmalloc(), where we want to create a virtually contiguous mapping from a collection of (possibly) non-contiguous pages. Such allocations are always created with R/W permissions. There are some cases where the vmalloc APIs are used to create mappings with different memory properties, but as already covered, this has become illegal with ARMv6 and v7 architectures. So no, VCM doesn't help because there's nothing that could be solved here. Creating read-only mappings is pointless, and creating mappings with different memory type, sharability or cache attributes is illegal. I don't think its pointless; it may have limited utility but things like read-only mappings can be useful. Without the VCM API (or something like it) there will just be a bunch of duplicated code that's basically doing ioremap. This code will probably fail to configure its mappings correctly, in which case your patch is a bad idea because it'll spawn bugs all over the place instead of at a know location. We could instead change ioremap to match the attributes of System RAM if that's what its mapping. And as I say, what is the point of creating another identical mapping to the one we already have? As you say probably not much. We do still have a problem (and other people have it as well) we need to map in large contiguous buffers with various attributes and point the kernel and various engines at them. This seems like something that would be globally useful. The feedback I've gotten is that we should just keep our usage private to our mach-msm branch. I've got a couple of questions: Do you think a global solution to this problem is appropriate? What would that solution need to look like, transparent huge pages? How should people change various mapping attributes for these large sections of memory? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] omap:mailbox-provide multiple reader support
Hi Hari,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Kanigeri, Hari
Sent: Tuesday, July 20, 2010 4:42 PM
To: Linux Omap; Tony Lindgren; Hiroshi DOYU
Cc: Ohad Ben-Cohen; Kanigeri, Hari
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) {
What happen if a thread is preempted by other thread which also uses the same
mailbox after doing the atomic_inc?
The second thread also will call atomic_inc_return and in this case the value
returned will be 2 and it will not initialize the mbox queues but it will
return success status, in this point the second thread will think it could get
the mailbox handle without any issue. However the first thread still can fail
and not initialize correctly the mailbox leading second thread to not work
properly or crash.
I think all the initialization should be protected and not just the use_count.
Please let me know what you think.
Regards,
Fernando.
+ 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
Re: [RFC 1/3 v3] mm: iommu: An API to unify IOMMU, CPU and device memory management
Russell- If a driver wants to allow a device to access memory (and cache coherency is off/not present for device addesses), the driver needs to remap that memory as non-cacheable. Suppose there exists a chunk of physically-contiguous memory (say, memory reserved for device use) that happened to be already mapped into the kernel as normal memory (cacheable, etc). One way to remap this memory is to use ioremap (and then never touch the original virtual mapping, which would now have conflicting attributes). I feel as if there should be a better way to remap memory for device access, either by altering the attributes on the original mapping, or removing the original mapping and creating a new one with attributes set to non-cacheable. Is there a better way to do this than calling ioremap() on that memory? Please advise. 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. On Mon, Jul 19, 2010 at 10:55:15AM -0700, Michael Bohan wrote: On 7/16/2010 12:58 AM, Russell King - ARM Linux wrote: 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. Would it be unreasonable to allow a map request to succeed if the requested attributes matched that of the preexisting mapping? What would be the point of creating such a mapping? -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm 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: [RFC 1/3 v3] mm: iommu: An API to unify IOMMU, CPU and device memory management
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. 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... -- 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
S u m m e r O f f e r
D e a r C u s t o m e r. A r g o s online store offer You the opportunity to become a cardholder of 'Argos Gold Card'.To find out more see below. Copy following link (without quotes) argos-goldcard.co.cc into your Internet browser and press 'Enter'. Note: do not reply to this message.Thank You. -- 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 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? 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? 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? 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
Winning Code (AQ11WWRZZA1)!!!
£1,000,000Pounds has been awarded to you in the U.K PROMO.send to this office the following: Names,,, Tel,, Age Address Occupation,, Country,,, Email: bnl.claimsdep...@btinternet.com Agent Name: Mr.Franck Smith Tel:+44-702-401-9768 -- 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
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. As you have pointed out, one of the issues is that allocation can fail. While technically VCMM allocations can fail as well, these allocations can be made from one or more memory pools that have been set aside specifically to be used by devices. Thus, the kernel's normal allocator will not encroach on the large physically-contiguous chunks (of size 1MB or even 16MB) that are not easy to get back, and would be forced to deal with increasing memory pressure in other ways. Additionally, some of the memory pools may have special properties, such as being part of on-chip memory with higher performance than regular memory, and some devices may have special requirements regarding what type or memory they need. The VCMM allocator solves the problem in a generic way by being able to deal with multiple memory pools and supporting prioritization schemes for which subset of the memory pools is to be used for each physical allocation. 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: [RFC 1/3 v3] mm: iommu: An API to unify IOMMU, CPU and device memory management
-Original Message- From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux-arm- kernel-boun...@lists.infradead.org] On Behalf Of Russell King - ARM Linux Sent: Wednesday, July 21, 2010 4:00 AM To: step...@codeaurora.org Cc: linux-a...@vger.kernel.org; dwal...@codeaurora.org; m...@csn.ul.ie; linux-arm-...@vger.kernel.org; linux-ker...@vger.kernel.org; FUJITA Tomonori; linux...@kvack.org; a...@firstfloor.org; Zach Pfeffer; Michael Bohan; Tim HRM; linux-omap@vger.kernel.org; linux-arm- ker...@lists.infradead.org; ebied...@xmission.com Subject: Re: [RFC 1/3 v3] mm: iommu: An API to unify IOMMU, CPU and device memory management On Tue, Jul 20, 2010 at 03:02:34PM -0700, step...@codeaurora.org wrote: Russell- If a driver wants to allow a device to access memory (and cache coherency is off/not present for device addesses), the driver needs to remap that memory as non-cacheable. If that memory is not part of the kernel's managed memory, then that's fine. But if it _is_ part of the kernel's managed memory, then it is not permitted by the ARM architecture specification to allow maps of the memory with differing [memory type, sharability, cache] attributes. Basically, if a driver wants to create these kinds of mappings, then they should expect the system to become unreliable and unpredictable. That's not something any sane person should be aiming to do. Suppose there exists a chunk of physically-contiguous memory (say, memory reserved for device use) that happened to be already mapped into the kernel as normal memory (cacheable, etc). One way to remap this memory is to use ioremap (and then never touch the original virtual mapping, which would now have conflicting attributes). This doesn't work, and is unpredictable on ARMv6 and ARMv7. Not touching the original mapping is _not_ _sufficient_ to guarantee that the mapping is not used. (We've seen problems on OMAP as a result of this.) Any mapping which exists can be speculatively prefetched by such CPUs at any time, which can lead it to be read into the cache. Then, your different attributes for your other mapping can cause problems if you hit one of these cache lines - and then you can have (possibly silent) data corruption. I feel as if there should be a better way to remap memory for device access, either by altering the attributes on the original mapping, or removing the original mapping and creating a new one with attributes set to non-cacheable. 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. However, one obvious case would be to use highmem-only pages for remapping - but you then have to ensure that those pages are never kmapped in any way, because those mappings will fall into the same unpredictable category that we're already trying to avoid. This may be possible, but you'll have to ensure that most of the system RAM is in highmem - which poses other problems (eg, if lowmem gets low.) Why can't we consider an option of removing the old mappings when we need to create new ones with different attributes as suggested by Catalin on similar thread previously. This will avoid the duplicate mapping with different attributes issue on newer ARMs. Is this something can't be worked out? Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
