Re: [PATCHv3 1/4] ARM: OMAP4: suspend: Program all domains to retention
On Mon, 2012-03-05 at 16:33 -0800, Kevin Hilman wrote: Tero Kristo t-kri...@ti.com writes: From: Rajendra Nayak rna...@ti.com Remove the FIXME's in the suspend sequence since we now intend to support system level RET support. Signed-off-by: Rajendra Nayak rna...@ti.com Signed-off-by: Tero Kristo t-kri...@ti.com Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com So this is the only patch in this series that is still needed. However... It doesn't seem like this all by itself is ready for mainline as we'll suddenly start putting all powerdomains in retention without any additional support. I guess at a minimum it needs working IO wakeup support from the IO daisy chain series. Are there other dependencies here? Only IO chain is needed for wakeup capability. Actually even with the current mainline kernel, I am unable to wake-up the device from MPU retention, as there are no wakeup sources. So this patch doesn't really change the behavior to worse even without any additional patches. :) But yea, good to wait until IO chain is in. The other dependencies are that the stuff handled by patches 2,3 and 4 have to be handled somehow: -patch2: must be in (this patch is queued by Paul) -patch3: will be taken care of by Paul's pwrdm fixes (I guess this is queued by Paul himself already) -patch4: OMAP interrupt count must be increased (this is handled by Benoit's patch, which is queued by Tony) -Tero If not, I can queue this when Paul is ready to merge the IO wakeup stuff. Kevin --- arch/arm/mach-omap2/pm44xx.c |6 -- 1 files changed, 0 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c index c264ef7..1ab30a3 100644 --- a/arch/arm/mach-omap2/pm44xx.c +++ b/arch/arm/mach-omap2/pm44xx.c @@ -151,12 +151,6 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused) if (!strncmp(pwrdm-name, cpu, 3)) return 0; - /* -* FIXME: Remove this check when core retention is supported -* Only MPUSS power domain is added in the list. -*/ - if (strcmp(pwrdm-name, mpu_pwrdm)) - return 0; pwrst = kmalloc(sizeof(struct power_state), GFP_ATOMIC); if (!pwrst) -- 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: [PATCHv4 2/6] ARM: OMAP3 PM: Move IO Daisychain function to omap3 prm file
On Tue, 2012-03-06 at 11:30 +0530, Rajendra Nayak wrote:
On Tuesday 06 March 2012 11:14 AM, Nishanth Menon wrote:
On 17:17-20120302, Tero Kristo wrote:
From: Vishwanath BSvishwanath...@ti.com
Since IO Daisychain modifies only PRM registers, it makes sense to move
it to PRM File. Also changed the timeout value for IO chain enable to
100us and added a wait for status disable at the end.
[...]
+/*
+ * Maximum time(us) it takes to output the signal WUCLKOUT of the last
pad of
+ * the I/O ring after asserting WUCLKIN high
+ */
+#define MAX_IOPAD_LATCH_TIME 100
+
+/* OMAP3 Daisychain enable sequence */
+void omap3_trigger_io_chain(void)
+{
+ int i = 0;
+
+ omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
+ PM_WKEN);
+ /* Do a readback to assure write has been done */
+ omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN);
+
+ omap_test_timeout(((omap2_prm_read_mod_reg(WKUP_MOD, PM_WKST)
+ OMAP3430_ST_IO_CHAIN_MASK) == 1),
umm
arch/arm/mach-omap2/prm-regbits-34xx.h:#define OMAP3430_ST_IO_CHAIN_MASK
(1 16)
(reg (1 16)) == 1
will ever be true?
good catch. Its should actually be '((reg (1 16)) 16) == 1'
This is fixed in the omap4_trigger_io() function, looks like is missed
here.
I'll fix this for next version.
-Tero
--
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: [PATCHv3 1/4] ARM: OMAP4: suspend: Program all domains to retention
On Tuesday 06 March 2012 02:01 PM, Tero Kristo wrote: On Mon, 2012-03-05 at 16:33 -0800, Kevin Hilman wrote: Tero Kristot-kri...@ti.com writes: From: Rajendra Nayakrna...@ti.com Remove the FIXME's in the suspend sequence since we now intend to support system level RET support. Signed-off-by: Rajendra Nayakrna...@ti.com Signed-off-by: Tero Kristot-kri...@ti.com Reviewed-by: Santosh Shilimkarsantosh.shilim...@ti.com So this is the only patch in this series that is still needed. However... It doesn't seem like this all by itself is ready for mainline as we'll suddenly start putting all powerdomains in retention without any additional support. I guess at a minimum it needs working IO wakeup support from the IO daisy chain series. Are there other dependencies here? Only IO chain is needed for wakeup capability. Actually even with the current mainline kernel, I am unable to wake-up the device from MPU retention, as there are no wakeup sources. So this patch doesn't really Why?, doesn't debug console wakeup work? change the behavior to worse even without any additional patches. :) But yea, good to wait until IO chain is in. IO chain, according to documentation :) should be needed only if you hit OSWR or OFF, async wakeups should be functional as long as you only hit CSWR. The other dependencies are that the stuff handled by patches 2,3 and 4 have to be handled somehow: -patch2: must be in (this patch is queued by Paul) -patch3: will be taken care of by Paul's pwrdm fixes (I guess this is queued by Paul himself already) -patch4: OMAP interrupt count must be increased (this is handled by Benoit's patch, which is queued by Tony) -Tero If not, I can queue this when Paul is ready to merge the IO wakeup stuff. Kevin --- arch/arm/mach-omap2/pm44xx.c |6 -- 1 files changed, 0 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c index c264ef7..1ab30a3 100644 --- a/arch/arm/mach-omap2/pm44xx.c +++ b/arch/arm/mach-omap2/pm44xx.c @@ -151,12 +151,6 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused) if (!strncmp(pwrdm-name, cpu, 3)) return 0; - /* -* FIXME: Remove this check when core retention is supported -* Only MPUSS power domain is added in the list. -*/ - if (strcmp(pwrdm-name, mpu_pwrdm)) - return 0; pwrst = kmalloc(sizeof(struct power_state), GFP_ATOMIC); if (!pwrst) -- 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: [PATCHv4 4/6] ARM: OMAP3+: PRM: Enable IO wake up
On Tue, 2012-03-06 at 10:26 +0530, Rajendra Nayak wrote: On Tuesday 06 March 2012 10:20 AM, Rajendra Nayak wrote: On Tuesday 06 March 2012 09:51 AM, Paul Walmsley wrote: added Rajendra, Nilesh, Vishwa, Mohan Hi On Fri, 2 Mar 2012, Tero Kristo wrote: Enable IO Wake up for OMAP3/4 as part of PRM Init. Currently this has been managed in cpuidle path which is not the right place. Subsequent patch will remove IO Daisy chain handling in cpuidle path once daisy chain is handled as part of hwmod mux. This patch also moves the OMAP4 IO wakeup enable code from the trigger function to init time setup. Signed-off-by: Tero Kristot-kri...@ti.com Should we keep the I/O wakeups enabled all the time? Seems like that could result in at least one spurious wake-up event -- and thus a PRCM interrupt -- for each I/O pad that has WAKEUPENABLE set. Seems like these interrupts could recur every time the I/O chain is reset. And that the I/O chain is now reset in every hwmod idle and enable operation for an IP block that contains dynamic mux data? Thinking about the problem naïvely... maybe you all can think through this with me: Consider an IP block 'A' that has a signal (like the UART rx_irrx signal) that's mux'ed to a pad with WAKEUPENABLE set. (Some examples of 'A' might include a UART, a GPIO, or a McBSP.) Shouldn't we enable I/O wakeups (by setting EN_IO/GLOBAL_WUEN) only immediately before the powerdomain containing IP block 'A' is going to transition into RETENTION or OFF? Hi Paul, I completely agree with your observations and we knew we would have additional wakeups with this design. Like I mentioned in the other thread, we went ahead with this approach knowing we need to optimize with some kind of powerdomain level usecounting in the future, because it didn't exist back then when we did it this way. But now that we already have it, maybe we can fix this and do it such that we completely avoid an additional wakeup interrupt. If we do that, then we can avoid needlessly resetting the I/O chain when a powerdomain is not going to go into a low-power state. I haven't measured the time it takes for the I/O chain to be reset. Maybe one of you have. But that 100 microsecond timeout that was specified in two of the other patches in this series has me a little worried. I haven't profiled it myself but I am guessing the delay isn't much. Having said that, I do agree with you that, however small the delay, we end up doing needless IO trigger when the powerdomain isn't really entering a low power state. I did some measurements on this a while back and the delay was around a few microseconds. I can redo this while doing version 5. -Tero The 100us comes from the fact that there is no documentation on the exact delay, so went around asking whats the *real worst case* delay, and we got an answer, 100us should be really big enough :) regards, Rajendra - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 5/6] ARM: OMAP3PLUS PM: Add IO Daisychain support via hwmod mux
On Tue, 2012-03-06 at 09:51 +0530, Rajendra Nayak wrote:
Hi Paul,
On Tuesday 06 March 2012 09:32 AM, Paul Walmsley wrote:
Hi
a few comments:
On Fri, 2 Mar 2012, Tero Kristo wrote:
From: Vishwanath BSvishwanath...@ti.com
IO Daisychain feature has to be triggered whenever there is a change in
device's mux configuration (See section 3.9.4 in OMAP4 Public TRM vP).
Now devices can idle independent of the powerdomain, there can be a
window where device is idled and corresponding powerdomain can be
ON/INACTIVE state. In such situations, since both module wake up is
enabled at padlevel as well as io daisychain sequence is triggered,
there will be 2 PRCM interrupts (Module async wake up via swakeup and
IO Pad interrupt). But as PRCM Interrupt handler clears the Module
Padlevel WKST bit in the first interrupt, module specific interrupt
handler will not triggered for the second time
Also look at detailed explanation given by Rajendra at
http://www.spinics.net/lists/linux-serial/msg04480.html
Signed-off-by: Vishwanath BSvishwanath...@ti.com
Signed-off-by: Tero Kristot-kri...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c |9 +++--
arch/arm/mach-omap2/pm.c | 15 +++
arch/arm/mach-omap2/pm.h |1 +
3 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index 5192cab..56adbfb 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
...
@@ -1535,8 +1536,10 @@ static int _enable(struct omap_hwmod *oh)
/* Mux pins for device runtime if populated */
if (oh-mux (!oh-mux-enabled ||
((oh-_state == _HWMOD_STATE_IDLE)
- oh-mux-pads_dynamic)))
+ oh-mux-pads_dynamic))) {
omap_hwmod_mux(oh-mux, _HWMOD_STATE_ENABLED);
+ omap_trigger_io_chain();
Looks racy: if two hwmods with dynamic mux entries go idle at the same
time, or one goes idle while another one is enabled, won't the calls to
omap_trigger_io_chain() race? Locking is per-hwmod and there's no locking
in omap_trigger_io_chain() or the functions it calls.
I agree, this needs locking to avoid races.
I'll add one for v5.
Also, won't this result in needless resets of the I/O chain? Seems like
we'd only need to do this when the next power state of the enclosing
powerdomain will enter either RETENTION or OFF. And even then, it
presumably should only happen when the last active device in that
powerdomain is going idle?
Yes, the module async wakeups will work as long as the power domain
enclosing the module is not in OSWR or OFF, so ideally this trigger
should happen only when all modules in the given powerdomain are
disabled and we plan to program the Powerdomain down to OSWR or
OFF state. With what we are doing today we end up with periods when we
have multiple wakeups (a module wakeup as well as an IO wakeup).
The last we discussed this with Kevin, there wasn't a better place where
we could trigger this, with no usecounting at powerdomain level you
didn't know when the last active device in the powerdomain was going
idle.
But now with Tero's series which adds usecounting at power/voltage
domain level, maybe its possible, but I need to look more.
Do you already have an idea on where this would fit better, so we
avoid this multiple wakeup scenario?
This should be easy, we can add a hook at the pwrdm_clkdm_enable /
disable calls to check against idle / active states. However, seeing the
acceptance status for the usecounting series, we probably have to just
go ahead with the extra latency involved iochain series and make
optimizations later once the usecounting can be accepted.
Speaking of the usecounting series, Paul, did you have any time to look
at it? Also, there are still some issues seen by Kevin on that series
with omap3430 which I am unable to reproduce (I posted a couple of trial
patches for taking care of that but don't know how they behave.)
-Tero
--
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: [PATCHv3 1/4] ARM: OMAP4: suspend: Program all domains to retention
On Tue, 2012-03-06 at 14:13 +0530, Rajendra Nayak wrote: On Tuesday 06 March 2012 02:01 PM, Tero Kristo wrote: On Mon, 2012-03-05 at 16:33 -0800, Kevin Hilman wrote: Tero Kristot-kri...@ti.com writes: From: Rajendra Nayakrna...@ti.com Remove the FIXME's in the suspend sequence since we now intend to support system level RET support. Signed-off-by: Rajendra Nayakrna...@ti.com Signed-off-by: Tero Kristot-kri...@ti.com Reviewed-by: Santosh Shilimkarsantosh.shilim...@ti.com So this is the only patch in this series that is still needed. However... It doesn't seem like this all by itself is ready for mainline as we'll suddenly start putting all powerdomains in retention without any additional support. I guess at a minimum it needs working IO wakeup support from the IO daisy chain series. Are there other dependencies here? Only IO chain is needed for wakeup capability. Actually even with the current mainline kernel, I am unable to wake-up the device from MPU retention, as there are no wakeup sources. So this patch doesn't really Why?, doesn't debug console wakeup work? At least I couldn't get it to work. I tried with no_console_suspend kernel param to no avail. Don't know if I was missing something else. -Tero change the behavior to worse even without any additional patches. :) But yea, good to wait until IO chain is in. IO chain, according to documentation :) should be needed only if you hit OSWR or OFF, async wakeups should be functional as long as you only hit CSWR. The other dependencies are that the stuff handled by patches 2,3 and 4 have to be handled somehow: -patch2: must be in (this patch is queued by Paul) -patch3: will be taken care of by Paul's pwrdm fixes (I guess this is queued by Paul himself already) -patch4: OMAP interrupt count must be increased (this is handled by Benoit's patch, which is queued by Tony) -Tero If not, I can queue this when Paul is ready to merge the IO wakeup stuff. Kevin --- arch/arm/mach-omap2/pm44xx.c |6 -- 1 files changed, 0 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c index c264ef7..1ab30a3 100644 --- a/arch/arm/mach-omap2/pm44xx.c +++ b/arch/arm/mach-omap2/pm44xx.c @@ -151,12 +151,6 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused) if (!strncmp(pwrdm-name, cpu, 3)) return 0; - /* - * FIXME: Remove this check when core retention is supported - * Only MPUSS power domain is added in the list. - */ - if (strcmp(pwrdm-name, mpu_pwrdm)) - return 0; pwrst = kmalloc(sizeof(struct power_state), GFP_ATOMIC); if (!pwrst) -- 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: [PATCHv3 1/4] ARM: OMAP4: suspend: Program all domains to retention
On Tuesday 06 March 2012 02:24 PM, Tero Kristo wrote: On Tue, 2012-03-06 at 14:13 +0530, Rajendra Nayak wrote: On Tuesday 06 March 2012 02:01 PM, Tero Kristo wrote: On Mon, 2012-03-05 at 16:33 -0800, Kevin Hilman wrote: Tero Kristot-kri...@ti.com writes: From: Rajendra Nayakrna...@ti.com Remove the FIXME's in the suspend sequence since we now intend to support system level RET support. Signed-off-by: Rajendra Nayakrna...@ti.com Signed-off-by: Tero Kristot-kri...@ti.com Reviewed-by: Santosh Shilimkarsantosh.shilim...@ti.com So this is the only patch in this series that is still needed. However... It doesn't seem like this all by itself is ready for mainline as we'll suddenly start putting all powerdomains in retention without any additional support. I guess at a minimum it needs working IO wakeup support from the IO daisy chain series. Are there other dependencies here? Only IO chain is needed for wakeup capability. Actually even with the current mainline kernel, I am unable to wake-up the device from MPU retention, as there are no wakeup sources. So this patch doesn't really Why?, doesn't debug console wakeup work? At least I couldn't get it to work. I tried with no_console_suspend kernel param to no avail. Don't know if I was missing something else. Did you try enabling wakeup for the debug console? echo enabled /sys/devices/platform/omap/omap_uart.2/tty/ttyO2/power/wakeup -Tero change the behavior to worse even without any additional patches. :) But yea, good to wait until IO chain is in. IO chain, according to documentation :) should be needed only if you hit OSWR or OFF, async wakeups should be functional as long as you only hit CSWR. The other dependencies are that the stuff handled by patches 2,3 and 4 have to be handled somehow: -patch2: must be in (this patch is queued by Paul) -patch3: will be taken care of by Paul's pwrdm fixes (I guess this is queued by Paul himself already) -patch4: OMAP interrupt count must be increased (this is handled by Benoit's patch, which is queued by Tony) -Tero If not, I can queue this when Paul is ready to merge the IO wakeup stuff. Kevin --- arch/arm/mach-omap2/pm44xx.c |6 -- 1 files changed, 0 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c index c264ef7..1ab30a3 100644 --- a/arch/arm/mach-omap2/pm44xx.c +++ b/arch/arm/mach-omap2/pm44xx.c @@ -151,12 +151,6 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused) if (!strncmp(pwrdm-name, cpu, 3)) return 0; - /* -* FIXME: Remove this check when core retention is supported -* Only MPUSS power domain is added in the list. -*/ - if (strcmp(pwrdm-name, mpu_pwrdm)) - return 0; pwrst = kmalloc(sizeof(struct power_state), GFP_ATOMIC); if (!pwrst) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP4: clock: Add aliases for McBSP fclk clocks
CLKS signal for McBSP ports can be selected from internal (PRCM) or external
(ABE_CLKS pin) source.
To be able to use existing code we need to create clock aliases consistent
among OMAP2/3/4.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Hi,
this patch should fix the clock reparenting on OMAP4 for McBSP ports.
Regards,
Peter
arch/arm/mach-omap2/clock44xx_data.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 08e86d7..7e76ac3 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3120,6 +3120,10 @@ static struct clk auxclkreq5_ck = {
static struct omap_clk omap44xx_clks[] = {
CLK(NULL, extalt_clkin_ck, extalt_clkin_ck,
CK_443X),
CLK(NULL, pad_clks_ck, pad_clks_ck,
CK_443X),
+ CLK(omap-mcbsp.1, pad_fck, pad_clks_ck,
CK_443X),
+ CLK(omap-mcbsp.2, pad_fck, pad_clks_ck,
CK_443X),
+ CLK(omap-mcbsp.3, pad_fck, pad_clks_ck,
CK_443X),
+ CLK(omap-mcbsp.4, pad_fck, pad_clks_ck,
CK_443X),
CLK(NULL, pad_slimbus_core_clks_ck,
pad_slimbus_core_clks_ck, CK_443X),
CLK(NULL, secure_32k_clk_src_ck,secure_32k_clk_src_ck,
CK_443X),
CLK(NULL, slimbus_clk, slimbus_clk,
CK_443X),
@@ -3254,12 +3258,16 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, mcasp_sync_mux_ck,mcasp_sync_mux_ck,
CK_443X),
CLK(NULL, mcasp_fck,mcasp_fck,
CK_443X),
CLK(NULL, mcbsp1_sync_mux_ck, mcbsp1_sync_mux_ck,
CK_443X),
+ CLK(omap-mcbsp.1, prcm_fck, mcbsp1_sync_mux_ck,
CK_443X),
CLK(NULL, mcbsp1_fck, mcbsp1_fck,
CK_443X),
CLK(NULL, mcbsp2_sync_mux_ck, mcbsp2_sync_mux_ck,
CK_443X),
+ CLK(omap-mcbsp.2, prcm_fck, mcbsp2_sync_mux_ck,
CK_443X),
CLK(NULL, mcbsp2_fck, mcbsp2_fck,
CK_443X),
CLK(NULL, mcbsp3_sync_mux_ck, mcbsp3_sync_mux_ck,
CK_443X),
+ CLK(omap-mcbsp.3, prcm_fck, mcbsp3_sync_mux_ck,
CK_443X),
CLK(NULL, mcbsp3_fck, mcbsp3_fck,
CK_443X),
CLK(NULL, mcbsp4_sync_mux_ck, mcbsp4_sync_mux_ck,
CK_443X),
+ CLK(omap-mcbsp.4, prcm_fck, mcbsp4_sync_mux_ck,
CK_443X),
CLK(NULL, mcbsp4_fck, mcbsp4_fck,
CK_443X),
CLK(NULL, mcpdm_fck,mcpdm_fck,
CK_443X),
CLK(NULL, mcspi1_fck, mcspi1_fck,
CK_443X),
--
1.7.8.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap3_beagle: Init only uart3 used for console
On Mon, Mar 5, 2012 at 7:36 PM, Koen Kooi k...@dominion.thruhere.net wrote: Op 5 mrt. 2012, om 12:12 heeft Govindraj.R het volgende geschreven: From: Govindraj.R govindraj.r...@ti.com On beagle some of uart mux lines are used for other purpose so init only uart3. Uart2 rx line clashes with gpio_147 used for usb ehci phy reset. Initializing uart2 pad_mux lines can break ehci module on beagle xm. (gpio_147 is available on uart2_rx in mode4 reference mux34xx.c - uart2_rx.gpio_147) That's only on xM revision C, right? Applicable to all beagle boards having external usb hub (USB2HS_nRST will require uart2_rx.gpio_147) Beagle Rev Ax/Bx doesn't seem to have external hub module so not applicable for those boards Will modify and post a new patch. -- Thanks, Govindraj.R -- 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_beagle: init uart2 for beagle rev AX/BX only
From: Govindraj.R govindraj.r...@ti.com
All beagle boards rev AX/BX have external usb hubs connected to ehci
interface, external hub/peripheral uses a nreset sequence for which
uart2_rx.gpio_147 pin in mux mode4(USB2HS_nRST) is used on all beagle
boards expect rev Ax/BX.
(Reference to all beagle boards rev schematics:
http://beagleboard.org/hardware/design)
Initialising uart2 will lead to serial init taking over uart2_rx pin
so init uart2_rx pin mux only for Beagle AX/BX rev boards.
Dont init uart2 for all other boards allowing usb_ehci functionality.
To initialise individual uart port by id utilise and modify the existing
available func. omap_serial_board_init.
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@ti.com
Cc: Koen Kooi k...@dominion.thruhere.net
Tested-by: Peter Ujfalusi peter.ujfal...@ti.com
Tested-by: Robert Nelson robertcnel...@gmail.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/board-omap3beagle.c |6 +++-
arch/arm/mach-omap2/serial.c | 41 -
arch/arm/plat-omap/include/plat/serial.h |3 +-
3 files changed, 30 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 7ffcd28..19d6fb5 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -126,6 +126,7 @@ static void __init omap3_beagle_init_rev(void)
beagle_config.mmc1_gpio_wp = 29;
beagle_config.reset_gpio = 170;
beagle_config.usr_button_gpio = 7;
+ omap_serial_board_init(NULL, 1);
break;
case 6:
printk(KERN_INFO OMAP3 Beagle Rev: C1/C2/C3\n);
@@ -528,7 +529,10 @@ static void __init omap3_beagle_init(void)
platform_add_devices(omap3_beagle_devices,
ARRAY_SIZE(omap3_beagle_devices));
omap_display_init(beagle_dss_data);
- omap_serial_init();
+ omap_serial_board_init(NULL, 0);
+ omap_serial_board_init(NULL, 2);
+ omap_serial_board_init(NULL, 3);
+
omap_sdrc_init(mt46h32m32lf6_sdrc_params,
mt46h32m32lf6_sdrc_params);
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index f590afc..e7c0462 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -393,30 +393,32 @@ void __init omap_serial_init_port(struct omap_board_data
*bdata,
/**
* omap_serial_board_init() - initialize all supported serial ports
* @info: platform specific data pointer
+ * @port_id: uart port number to be initialised
*
- * Initializes all available UARTs as serial ports. Platforms
+ * Initializes individual UARTs as serial ports. Platforms
* can call this function when they want to have default behaviour
- * for serial ports (e.g initialize them all as serial ports).
+ * for serial ports (e.g initialize individual serial ports based on port id).
*/
-void __init omap_serial_board_init(struct omap_uart_port_info *info)
+void __init omap_serial_board_init(struct omap_uart_port_info *info, u8
port_id)
{
struct omap_uart_state *uart;
struct omap_board_data bdata;
- list_for_each_entry(uart, uart_list, node) {
- bdata.id = uart-num;
- bdata.flags = 0;
- bdata.pads = NULL;
- bdata.pads_cnt = 0;
-
- if (cpu_is_omap44xx() || cpu_is_omap34xx())
- omap_serial_fill_default_pads(bdata);
-
- if (!info)
- omap_serial_init_port(bdata, NULL);
- else
- omap_serial_init_port(bdata, info[uart-num]);
- }
+ list_for_each_entry(uart, uart_list, node)
+ if (uart-num == port_id) {
+ bdata.id = uart-num;
+ bdata.flags = 0;
+ bdata.pads = NULL;
+ bdata.pads_cnt = 0;
+
+ if (!cpu_is_omap24xx())
+ omap_serial_fill_default_pads(bdata);
+
+ if (!info)
+ omap_serial_init_port(bdata, NULL);
+ else
+ omap_serial_init_port(bdata, info);
+ }
}
/**
@@ -428,5 +430,8 @@ void __init omap_serial_board_init(struct
omap_uart_port_info *info)
*/
void __init omap_serial_init(void)
{
- omap_serial_board_init(NULL);
+ struct omap_uart_state *uart;
+
+ list_for_each_entry(uart, uart_list, node)
+ omap_serial_board_init(NULL, uart-num);
}
diff --git a/arch/arm/plat-omap/include/plat/serial.h
b/arch/arm/plat-omap/include/plat/serial.h
index 198d1e6..043b251 100644
--- a/arch/arm/plat-omap/include/plat/serial.h
+++ b/arch/arm/plat-omap/include/plat/serial.h
@@ -111,7 +111,8 @@ struct omap_uart_port_info;
extern void
Re: [PATCH] omap3_beagle: Init only uart3 used for console
Op 6 mrt. 2012, om 10:03 heeft Raja, Govindraj het volgende geschreven: On Mon, Mar 5, 2012 at 7:36 PM, Koen Kooi k...@dominion.thruhere.net wrote: Op 5 mrt. 2012, om 12:12 heeft Govindraj.R het volgende geschreven: From: Govindraj.R govindraj.r...@ti.com On beagle some of uart mux lines are used for other purpose so init only uart3. Uart2 rx line clashes with gpio_147 used for usb ehci phy reset. Initializing uart2 pad_mux lines can break ehci module on beagle xm. (gpio_147 is available on uart2_rx in mode4 reference mux34xx.c - uart2_rx.gpio_147) That's only on xM revision C, right? Applicable to all beagle boards having external usb hub (USB2HS_nRST will require uart2_rx.gpio_147) My apologies, I was confusing it with the DVI reset GPIO (which changed in between revisions) and the polarity of the USB pin (which changed during xM A - C). regards, Koen-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap3_beagle: Init only uart3 used for console
On Tue, Mar 6, 2012 at 1:30 AM, Kevin Hilman khil...@ti.com wrote: Govindraj.R govindraj.r...@ti.com writes: From: Govindraj.R govindraj.r...@ti.com On beagle some of uart mux lines are used for other purpose so init only uart3. OK, but you should also be clear that this patch is effectively disabling all UARTS (except UART3) by defatul, which I'm not sure all Beagle users will be happy about. Okay, I have posted new version of the patch [PATCH] omap3_beagle: init uart2 for beagle rev AX/BX only which initialises uart1/3/4 on all beagle boards and uart2 init is done for only beagle rev ax/bx which doesn't seem to have external usb module. Uart2 rx line clashes with gpio_147 used for usb ehci phy reset. Initializing uart2 pad_mux lines can break ehci module on beagle xm. (gpio_147 is available on uart2_rx in mode4 reference mux34xx.c - uart2_rx.gpio_147) As Koen mentioned, this conflict only exists on certain boards, so you should be clear that this is just an example. conflict exists all beagle rev's expect rev ax/bx. -- Thanks, Govindraj.R -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap3_beagle: Init only uart3 used for console
On Tue, Mar 6, 2012 at 2:21 AM, Tony Lindgren t...@atomide.com wrote: * Kevin Hilman khil...@ti.com [120305 11:28]: Govindraj.R govindraj.r...@ti.com writes: From: Govindraj.R govindraj.r...@ti.com On beagle some of uart mux lines are used for other purpose so init only uart3. OK, but you should also be clear that this patch is effectively disabling all UARTS (except UART3) by defatul, which I'm not sure all Beagle users will be happy about. Uart2 rx line clashes with gpio_147 used for usb ehci phy reset. Initializing uart2 pad_mux lines can break ehci module on beagle xm. (gpio_147 is available on uart2_rx in mode4 reference mux34xx.c - uart2_rx.gpio_147) As Koen mentioned, this conflict only exists on certain boards, so you should be clear that this is just an example. OK, thanks for the comments. Also it's a bit clear if this really is safe to do on all beagles. I have clarified the same in reply to Kevin Hilman and Koen Kooi in the same thread. Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@ti.com Tested-by: Peter Ujfalusi peter.ujfal...@ti.com Tested-by: Robert Nelson robertcnel...@gmail.com Signed-off-by: Govindraj.R govindraj.r...@ti.com [...] + +static inline void board_serial_init(void) Should be __init [...] +static inline void board_serial_init(void) here too. ..so dropping the patch for now until these are fixed and we have some tested-bys for non-xm beagles too. Okay fine, I have new version of the patch [PATCH] omap3_beagle: init uart2 for beagle rev AX/BX only This patch shouldn't have any impact and should work on beagles. -- Thanks, Govindraj.R -- 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: Ethernet problems on AM3517, possible regression?
Hi, On 03/05/12 19:32, CF Adad wrote: Hi Igor, Thanks for your reply! So are both ports working on the CM-T3517 simultaneously now? Well, you need to apply all the patches I've sent you. Looking at the latest board file for the CM-T3517 (arch/arm/mach-omap2/board-cm-t3517.c), I don't see either the SMSC or the EMAC ports being initialized. Has that initialization code been moved somewhere else in the kernel? Again, you need to apply the patches I've sent you. Regarding the patches: I had actually seen those (in the previous version #2 I believe), and applied them to our kernel. v3 is slightly different and you need the patch for the board file. You need also the patches I've sent you privately. If you take a look at my board file below, you'll notice I defined a USE_ALT__EMAC_ETH definition that causes the separate EMAC file (created by those patches) to be used. I've tried both the old and the new (separate file) way of doing this. Our EMAC does work fine, as does our SMSC, except our SMSC does not store a MAC address. They just do not work together. One or the other must be disabled (commented out of the code) or neither work. The patch I've sent you solves exactly that... It appears to me that the problem with running both is the mdio id setting. Perhaps they're both demanding the same slot or something? Yes, there were several changes made to MDIO framework and how the whole thing is handled. -- 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: [PATCHv3 1/4] ARM: OMAP4: suspend: Program all domains to retention
On Tue, 2012-03-06 at 14:29 +0530, Rajendra Nayak wrote: On Tuesday 06 March 2012 02:24 PM, Tero Kristo wrote: On Tue, 2012-03-06 at 14:13 +0530, Rajendra Nayak wrote: On Tuesday 06 March 2012 02:01 PM, Tero Kristo wrote: On Mon, 2012-03-05 at 16:33 -0800, Kevin Hilman wrote: Tero Kristot-kri...@ti.com writes: From: Rajendra Nayakrna...@ti.com Remove the FIXME's in the suspend sequence since we now intend to support system level RET support. Signed-off-by: Rajendra Nayakrna...@ti.com Signed-off-by: Tero Kristot-kri...@ti.com Reviewed-by: Santosh Shilimkarsantosh.shilim...@ti.com So this is the only patch in this series that is still needed. However... It doesn't seem like this all by itself is ready for mainline as we'll suddenly start putting all powerdomains in retention without any additional support. I guess at a minimum it needs working IO wakeup support from the IO daisy chain series. Are there other dependencies here? Only IO chain is needed for wakeup capability. Actually even with the current mainline kernel, I am unable to wake-up the device from MPU retention, as there are no wakeup sources. So this patch doesn't really Why?, doesn't debug console wakeup work? At least I couldn't get it to work. I tried with no_console_suspend kernel param to no avail. Don't know if I was missing something else. Did you try enabling wakeup for the debug console? echo enabled /sys/devices/platform/omap/omap_uart.2/tty/ttyO2/power/wakeup I think not, however I wonder why the wakeups are not enabled by default if this helps? -Tero change the behavior to worse even without any additional patches. :) But yea, good to wait until IO chain is in. IO chain, according to documentation :) should be needed only if you hit OSWR or OFF, async wakeups should be functional as long as you only hit CSWR. The other dependencies are that the stuff handled by patches 2,3 and 4 have to be handled somehow: -patch2: must be in (this patch is queued by Paul) -patch3: will be taken care of by Paul's pwrdm fixes (I guess this is queued by Paul himself already) -patch4: OMAP interrupt count must be increased (this is handled by Benoit's patch, which is queued by Tony) -Tero If not, I can queue this when Paul is ready to merge the IO wakeup stuff. Kevin --- arch/arm/mach-omap2/pm44xx.c |6 -- 1 files changed, 0 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c index c264ef7..1ab30a3 100644 --- a/arch/arm/mach-omap2/pm44xx.c +++ b/arch/arm/mach-omap2/pm44xx.c @@ -151,12 +151,6 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused) if (!strncmp(pwrdm-name, cpu, 3)) return 0; - /* -* FIXME: Remove this check when core retention is supported -* Only MPUSS power domain is added in the list. -*/ - if (strcmp(pwrdm-name, mpu_pwrdm)) - return 0; pwrst = kmalloc(sizeof(struct power_state), GFP_ATOMIC); if (!pwrst) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] OMAP: UART: Enable tx wakeup bit in wer
On Tue, Mar 6, 2012 at 1:53 AM, Paul Walmsley p...@pwsan.com wrote:
Hello Govindraj
Do you intend to update and repost this serial patch? Or should someone
else deal with it? It would be good to get support for this additional
wakeup bit.
Thanks for reminding.
(I had got preempted with other activities, apologies for the delay)
I see two ways of adding this tx wake-up flag.
1.) passing a feature flag from pdata and populating the feature value to wer.
2.) Duplicating the uart1/2/3 hwmod for omap3430 without dev attrib
and uart1/2/3/4
hwmod for omap3630 with dev attribs.
Approach-2 adds unnecessary code duplication in hwmod file with and without
dev_attribs, So right now here is the patch to follow approach [1],
If its strongly recommended to use approach-2 will add it.
(My concern is the diffstat it might produce with approach-2)
--
Thanks,
Govindraj.R
[1]:
From 867dfa7328b4219be259a204555a6baae82ec4df Mon Sep 17 00:00:00 2001
From: Govindraj.R govindraj.r...@ti.com
Date: Tue, 6 Mar 2012 15:04:47 +0530
Subject: [PATCH] OMAP: UART: enable tx wake up capability for 3630 above socs
From omap3630 above UART wer(wakeup enable reg) has TX
wakeup capability, enable the tx wakeup bit by passing
the required feature flag from pdata.
Also add missing wer reg restore from context restore function.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c |3 +++
arch/arm/plat-omap/include/plat/omap-serial.h |7 +++
drivers/tty/serial/omap-serial.c |8 +++-
3 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index f590afc..eb43996 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -357,6 +357,9 @@ void __init omap_serial_init_port(struct
omap_board_data *bdata,
omap_up.dma_rx_poll_rate = info-dma_rx_poll_rate;
omap_up.autosuspend_timeout = info-autosuspend_timeout;
+ if (!cpu_is_omap24xx() !cpu_is_omap3430())
+ omap_up.has_feature = UART_FEATURE_TX_WAKEUP_EN;
+
/* Enable the MDR1 Errata i202 for OMAP2430/3xxx/44xx */
if (!cpu_is_omap2420() !cpu_is_ti816x())
omap_up.errata |= UART_ERRATA_i202_MDR1_ACCESS;
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index 9ff..b4f42dc 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -61,6 +61,11 @@
#define UART_ERRATA_i202_MDR1_ACCESS BIT(0)
#define UART_ERRATA_i291_DMA_FORCEIDLE BIT(1)
+#define OMAP_UART_TX_WAKEUP_EN BIT(7)
+
+/* Feature flags */
+#define UART_FEATURE_TX_WAKEUP_EN BIT(0)
+
struct omap_uart_port_info {
booldma_enabled;/* To specify DMA Mode */
unsigned intuartclk;/* UART clock rate */
@@ -70,6 +75,7 @@ struct omap_uart_port_info {
unsigned intdma_rx_timeout;
unsigned intautosuspend_timeout;
unsigned intdma_rx_poll_rate;
+ unsigned inthas_feature;
int (*get_context_loss_count)(struct device *);
void (*set_forceidle)(struct platform_device *);
@@ -117,6 +123,7 @@ struct uart_omap_port {
unsigned char dlh;
unsigned char mdr1;
unsigned char scr;
+ unsigned char wer;
int use_dma;
/*
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index f809041..5d7330f 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -577,8 +577,10 @@ static int serial_omap_startup(struct uart_port *port)
up-ier = UART_IER_RLSI | UART_IER_RDI;
serial_out(up, UART_IER, up-ier);
+ up-wer |= OMAP_UART_WER_MOD_WKUP;
+
/* Enable module level wake up */
- serial_out(up, UART_OMAP_WER, OMAP_UART_WER_MOD_WKUP);
+ serial_out(up, UART_OMAP_WER, up-wer);
pm_runtime_mark_last_busy(up-pdev-dev);
pm_runtime_put_autosuspend(up-pdev-dev);
@@ -1444,6 +1446,8 @@ static int serial_omap_probe(struct platform_device *pdev)
}
up-uart_dma.uart_base = mem-start;
up-errata = omap_up_info-errata;
+ if (omap_up_info-has_feature UART_FEATURE_TX_WAKEUP_EN)
+ up-wer |= OMAP_UART_TX_WAKEUP_EN;
if (omap_up_info-dma_enabled) {
up-uart_dma.uart_dma_tx = dma_tx-start;
@@ -1569,6 +1573,8 @@ static void serial_omap_restore_context(struct
uart_omap_port *up)
serial_omap_mdr1_errataset(up, up-mdr1);
else
serial_out(up, UART_OMAP_MDR1, up-mdr1);
+
+ serial_out(up, UART_OMAP_WER, up-wer);
}
static int serial_omap_runtime_suspend(struct device *dev)
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap
Re: [PATCH RFC] spi/omap: Trivial cleanup
Hi Shubhro, On 2/29/2012 3:04 PM, Shubhrajyoti D wrote: The context is stored directly inside drvdata structure post [f887876 spi/omap: Remove bus_num usage for instance index]. Remove the OMAP2_MCSPI_MAX_CTRL macro as it is not needed anymore. Cc: Benoit Coussonb-cous...@ti.com Signed-off-by: Shubhrajyoti Dshubhrajy...@ti.com Thanks for that extra cleanup, I missed it. Acked-by: Benoit Cousson b-cous...@ti.com --- Applies on Benoit's for_3.4/dt_spi_eth drivers/spi/spi-omap2-mcspi.c |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c index d1eb26c..3526281 100644 --- a/drivers/spi/spi-omap2-mcspi.c +++ b/drivers/spi/spi-omap2-mcspi.c @@ -45,9 +45,6 @@ #define OMAP2_MCSPI_MAX_FREQ 4800 -/* OMAP2 has 3 SPI controllers, while OMAP3 has 4 */ -#define OMAP2_MCSPI_MAX_CTRL 4 - I guess it can be included in the spi/omap: Remove bus_num usage for instance index? Is that OK for you? Thanks, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] arm: fix compile error in mach-omap2/board-omap4panda.c
Hi,
On 03/06/2012 12:41 AM, Paul Gortmaker wrote:
The commit 3c90c98a1ebbb08d95700ce8a3b7bce6286607bd (linux-next)
OMAP4: omap4panda: Enable audio support
introduced population of a new struct, but chose the wrong (but
similarly named) struct that has none of the named fields.
Change it to the struct with those fields, to fix:
arch/arm/mach-omap2/board-omap4panda.c:284: error: unknown field
'hs_left_step' specified in initializer
arch/arm/mach-omap2/board-omap4panda.c:285: error: unknown field
'hs_right_step' specified in initializer
arch/arm/mach-omap2/board-omap4panda.c:286: error: unknown field
'hf_left_step' specified in initializer
arch/arm/mach-omap2/board-omap4panda.c:287: error: unknown field
'hf_right_step' specified in initializer
arch/arm/mach-omap2/board-omap4panda.c:287: warning: large integer implicitly
truncated to unsigned type
Yes, I have also noticed it.
This is because part of the twl6040 i2c conversion series has been taken
by Samuel.
He will stop carrying it further (I hope), and we are going to have a
bit different series going via audio.
Samuel did not took the panda part of the patches since it had some
other dependencies coming via audio tree.
The thing is that the panda audio support is coming via ASoC to
linux-next, so Samuel could not take the patch addressing this breakage
(mfd tree does not have the needed patches).
I'm not sure where we could apply this patch in the first place since
mfd does not have the panda audio support patches, and currently the
ASoC does not have the twl6040 i2c conversion patches either...
Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com
CC: Peter Ujfalusi peter.ujfal...@ti.com
CC: Santosh Shilimkar santosh.shilim...@ti.com
CC: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-omap4panda.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index c1a852d..e919153 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -279,7 +279,7 @@ static int __init omap4_twl6030_hsmmc_init(struct
omap2_hsmmc_info *controllers)
return 0;
}
-static struct twl4030_codec_data twl6040_codec = {
+static struct twl6040_codec_data twl6040_codec = {
/* single-step ramp for headset and handsfree */
.hs_left_step = 0x0f,
.hs_right_step = 0x0f,
--
Péter
--
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 3/3] arm: more fallout from i2c conversions in board-omap4panda.c
Hi,
On 03/06/2012 12:41 AM, Paul Gortmaker wrote:
Commit ded0df8510778a03a2f182a0cbfe3c25788e8852 (linux-next)
mfd: Convert twl6040 to an i2c driver, and separate it from twl core
appears to have done an incomplete conversion on the board-omap4panda.c
file, leaving it with more build failures. Comparing the changes that
were done for board-4430sdp.c it is possible for me to whack it with a
stick until it stops twitching, but someone who really understands this
code needs to take a look at the conversion, and check it is done
completely and in a way that will actually work on hardware.
This is true.
I'm sending a revert series for the twl6040 patches causing this
breakage for Samuel.
The same feature will go via audio tree because the dependencies are
queued in that feature tree.
--
Péter
PS: this might fix the compile breakage with omap2_defconfig, but the
audio will not work if you enable the support for it on OMAP4.
Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com
CC: Peter Ujfalusi peter.ujfal...@ti.com
CC: Mark Brown broo...@opensource.wolfsonicro.com
CC: Samuel Ortiz sa...@linux.intel.com
---
arch/arm/mach-omap2/board-omap4panda.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index e919153..16a1814 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -287,16 +287,15 @@ static struct twl6040_codec_data twl6040_codec = {
.hf_right_step = 0x1d,
};
-static struct twl4030_audio_data twl6040_audio = {
+static struct twl6040_platform_data twl6040_data = {
.codec = twl6040_codec,
.audpwron_gpio = 127,
- .naudint_irq= OMAP44XX_IRQ_SYS_2N,
.irq_base = TWL6040_CODEC_IRQ_BASE,
};
/* Panda board uses the common PMIC configuration */
static struct twl4030_platform_data omap4_panda_twldata = {
- .audio = twl6040_audio,
+ /*.audio = twl6040_audio, */
};
/*
--
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/5] MFD: Reverting twl6040 patches going for 3.4
Hello Samuel, this series reverts the twl6040 related patches aimed for 3.4 merge window from MFD for-next branch. As we already discussed the relevant patches will be going through audio since we have some dependencies going via that route. With this series we also fix the build breakage with omap2plus_defconfig, and also we can make sure that the OMAP4 audio is working in linux-next. Could you apply this series so we can push forward these changes via audio? Thank you, Peter --- Peter Ujfalusi (5): Revert mfd/Input/ASoC: twl6040 kconfig fixes Revert mfd: Add regulator support for twl6040 VIO, V2V1 supplies Revert ASoC: Remove twl6040 dependency on twl4030 from Kconfig Revert mfd: Convert twl6040 to an i2c driver, and separate it from twl core Revert mfd: Detach twl6040 from the pmic mfd driver arch/arm/mach-omap2/board-4430sdp.c| 12 ++-- arch/arm/mach-omap2/board-generic.c|2 +- arch/arm/mach-omap2/board-omap4panda.c |4 +- arch/arm/mach-omap2/twl-common.c | 37 +--- arch/arm/mach-omap2/twl-common.h | 10 ++- drivers/input/misc/Kconfig |3 +- drivers/input/misc/twl6040-vibra.c |4 +- drivers/mfd/Kconfig| 11 +-- drivers/mfd/twl-core.c | 58 +--- drivers/mfd/twl6040-core.c | 155 ++- include/linux/i2c/twl.h| 12 +++ include/linux/mfd/twl6040.h| 29 -- sound/soc/codecs/Kconfig |3 +- sound/soc/codecs/twl6040.c |3 +- 14 files changed, 116 insertions(+), 227 deletions(-) -- 1.7.8.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] Revert mfd/Input/ASoC: twl6040 kconfig fixes
This reverts commit a0afdbc2665bbad5ebc81a43b820e97f56ea0582. Reverting changes regarding to twl6040 in MFD tree since the patches will go via the audio tree. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- drivers/input/misc/Kconfig |2 +- drivers/mfd/Kconfig| 11 ++- sound/soc/codecs/Kconfig |3 ++- 3 files changed, 5 insertions(+), 11 deletions(-) diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig index 9450d4c..6a9ee24 100644 --- a/drivers/input/misc/Kconfig +++ b/drivers/input/misc/Kconfig @@ -368,7 +368,7 @@ config INPUT_TWL4030_VIBRA config INPUT_TWL6040_VIBRA tristate Support for TWL6040 Vibrator - depends on TWL6040_CORE + select TWL6040_CORE select INPUT_FF_MEMLESS help This option enables support for TWL6040 Vibrator Driver. diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index 14e1efa..880c69a 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -267,17 +267,10 @@ config TWL6030_PWM This is used to control charging LED brightness. config TWL6040_CORE - bool Support for TWL6040 audio codec - depends on I2C=y GENERIC_HARDIRQS + bool + depends on I2C GENERIC_HARDIRQS select MFD_CORE - select REGMAP_I2C default n - help - Say yes here if you want support for Texas Instruments TWL6040 audio - codec. - This driver provides common support for accessing the device, - additional drivers must be enabled in order to use the - functionality of the device (audio, vibra). config MFD_STMPE bool Support STMicroelectronics STMPE diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig index 6b4d86a..f1a1197 100644 --- a/sound/soc/codecs/Kconfig +++ b/sound/soc/codecs/Kconfig @@ -56,7 +56,7 @@ config SND_SOC_ALL_CODECS select SND_SOC_TPA6130A2 if I2C select SND_SOC_TLV320DAC33 if I2C select SND_SOC_TWL4030 if TWL4030_CORE - select SND_SOC_TWL6040 if TWL6040_CORE + select SND_SOC_TWL6040 if I2C select SND_SOC_UDA134X select SND_SOC_UDA1380 if I2C select SND_SOC_WL1273 if MFD_WL1273_CORE @@ -274,6 +274,7 @@ config SND_SOC_TWL4030 tristate config SND_SOC_TWL6040 + select TWL6040_CORE tristate config SND_SOC_UDA134X -- 1.7.8.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] Revert ASoC: Remove twl6040 dependency on twl4030 from Kconfig
This reverts commit 36229729d92f903a7311f1c040b33d5bab0af60b. Reverting changes regarding to twl6040 in MFD tree since the patches will go via the audio tree. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- sound/soc/codecs/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig index f1a1197..7c205e7 100644 --- a/sound/soc/codecs/Kconfig +++ b/sound/soc/codecs/Kconfig @@ -56,7 +56,7 @@ config SND_SOC_ALL_CODECS select SND_SOC_TPA6130A2 if I2C select SND_SOC_TLV320DAC33 if I2C select SND_SOC_TWL4030 if TWL4030_CORE - select SND_SOC_TWL6040 if I2C + select SND_SOC_TWL6040 if TWL4030_CORE select SND_SOC_UDA134X select SND_SOC_UDA1380 if I2C select SND_SOC_WL1273 if MFD_WL1273_CORE -- 1.7.8.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] Revert mfd: Add regulator support for twl6040 VIO, V2V1 supplies
This reverts commit c04eaf3db0589e7c9f13c992a871ae2b2eb73f4f.
Reverting changes regarding to twl6040 in MFD tree since the patches will go
via the audio tree.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/mfd/twl6040-core.c | 41 -
include/linux/mfd/twl6040.h |2 --
2 files changed, 4 insertions(+), 39 deletions(-)
diff --git a/drivers/mfd/twl6040-core.c b/drivers/mfd/twl6040-core.c
index 58c95b4..2d6beda 100644
--- a/drivers/mfd/twl6040-core.c
+++ b/drivers/mfd/twl6040-core.c
@@ -27,7 +27,6 @@
#include linux/types.h
#include linux/slab.h
#include linux/kernel.h
-#include linux/err.h
#include linux/platform_device.h
#include linux/gpio.h
#include linux/delay.h
@@ -36,10 +35,8 @@
#include linux/err.h
#include linux/mfd/core.h
#include linux/mfd/twl6040.h
-#include linux/regulator/consumer.h
#define VIBRACTRL_MEMBER(reg) ((reg == TWL6040_REG_VIBCTLL) ? 0 : 1)
-#define TWL6040_NUM_SUPPLIES (2)
int twl6040_reg_read(struct twl6040 *twl6040, unsigned int reg)
{
@@ -527,14 +524,6 @@ static int __devinit twl6040_probe(struct i2c_client
*client,
goto err;
}
- twl6040-supplies = devm_kzalloc(client-dev,
-sizeof(struct regulator_bulk_data) *
-TWL6040_NUM_SUPPLIES, GFP_KERNEL);
- if (!twl6040-supplies) {
- ret = -ENOMEM;
- goto err;
- }
-
twl6040-regmap = regmap_init_i2c(client, twl6040_regmap_config);
if (IS_ERR(twl6040-regmap)) {
ret = PTR_ERR(twl6040-regmap);
@@ -543,21 +532,6 @@ static int __devinit twl6040_probe(struct i2c_client
*client,
i2c_set_clientdata(client, twl6040);
- twl6040-supplies[0].supply = vio;
- twl6040-supplies[1].supply = v2v1;
- ret = regulator_bulk_get(client-dev, TWL6040_NUM_SUPPLIES,
-twl6040-supplies);
- if (ret != 0) {
- dev_err(client-dev, Failed to get supplies: %d\n, ret);
- goto regulator_get_err;
- }
-
- ret = regulator_bulk_enable(TWL6040_NUM_SUPPLIES, twl6040-supplies);
- if (ret != 0) {
- dev_err(client-dev, Failed to enable supplies: %d\n, ret);
- goto power_err;
- }
-
twl6040-dev = client-dev;
twl6040-irq = client-irq;
twl6040-irq_base = pdata-irq_base;
@@ -578,13 +552,13 @@ static int __devinit twl6040_probe(struct i2c_client
*client,
ret = gpio_request_one(twl6040-audpwron, GPIOF_OUT_INIT_LOW,
audpwron);
if (ret)
- goto gpio_err;
+ goto gpio1_err;
}
/* codec interrupt */
ret = twl6040_irq_init(twl6040);
if (ret)
- goto irq_init_err;
+ goto gpio2_err;
ret = request_threaded_irq(twl6040-irq_base + TWL6040_IRQ_READY,
NULL, twl6040_naudint_handler, 0,
@@ -644,14 +618,10 @@ mfd_err:
free_irq(twl6040-irq_base + TWL6040_IRQ_READY, twl6040);
irq_err:
twl6040_irq_exit(twl6040);
-irq_init_err:
+gpio2_err:
if (gpio_is_valid(twl6040-audpwron))
gpio_free(twl6040-audpwron);
-gpio_err:
- regulator_bulk_disable(TWL6040_NUM_SUPPLIES, twl6040-supplies);
-power_err:
- regulator_bulk_free(TWL6040_NUM_SUPPLIES, twl6040-supplies);
-regulator_get_err:
+gpio1_err:
i2c_set_clientdata(client, NULL);
regmap_exit(twl6040-regmap);
err:
@@ -675,9 +645,6 @@ static int __devexit twl6040_remove(struct i2c_client
*client)
i2c_set_clientdata(client, NULL);
regmap_exit(twl6040-regmap);
- regulator_bulk_disable(TWL6040_NUM_SUPPLIES, twl6040-supplies);
- regulator_bulk_free(TWL6040_NUM_SUPPLIES, twl6040-supplies);
-
return 0;
}
diff --git a/include/linux/mfd/twl6040.h b/include/linux/mfd/twl6040.h
index bf3931e..b15b5f0 100644
--- a/include/linux/mfd/twl6040.h
+++ b/include/linux/mfd/twl6040.h
@@ -199,12 +199,10 @@ struct twl6040_platform_data {
};
struct regmap;
-struct regulator_bulk_data;
struct twl6040 {
struct device *dev;
struct regmap *regmap;
- struct regulator_bulk_data *supplies; /* supplies for vio, v2v1 */
struct mutex mutex;
struct mutex io_mutex;
struct mutex irq_mutex;
--
1.7.8.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] Revert mfd: Convert twl6040 to an i2c driver, and separate it from twl core
This reverts commit ded0df8510778a03a2f182a0cbfe3c25788e8852.
Reverting changes regarding to twl6040 in MFD tree since the patches will go
via the audio tree.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c| 12 ++--
arch/arm/mach-omap2/board-generic.c|2 +-
arch/arm/mach-omap2/board-omap4panda.c |4 +-
arch/arm/mach-omap2/twl-common.c | 37 ++-
arch/arm/mach-omap2/twl-common.h | 10 ++-
drivers/input/misc/Kconfig |1 +
drivers/input/misc/twl6040-vibra.c |4 +-
drivers/mfd/Kconfig|2 +-
drivers/mfd/twl6040-core.c | 114 +---
include/linux/i2c/twl.h| 12
include/linux/mfd/twl6040.h| 27
sound/soc/codecs/twl6040.c |3 +-
12 files changed, 83 insertions(+), 145 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 474bcf3..4e90715 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -20,7 +20,6 @@
#include linux/usb/otg.h
#include linux/spi/spi.h
#include linux/i2c/twl.h
-#include linux/mfd/twl6040.h
#include linux/gpio_keys.h
#include linux/regulator/machine.h
#include linux/regulator/fixed.h
@@ -527,7 +526,7 @@ static struct regulator_init_data sdp4430_vusim = {
},
};
-static struct twl6040_codec_data twl6040_codec = {
+static struct twl4030_codec_data twl6040_codec = {
/* single-step ramp for headset and handsfree */
.hs_left_step = 0x0f,
.hs_right_step = 0x0f,
@@ -535,7 +534,7 @@ static struct twl6040_codec_data twl6040_codec = {
.hf_right_step = 0x1d,
};
-static struct twl6040_vibra_data twl6040_vibra = {
+static struct twl4030_vibra_data twl6040_vibra = {
.vibldrv_res = 8,
.vibrdrv_res = 3,
.viblmotor_res = 10,
@@ -544,14 +543,16 @@ static struct twl6040_vibra_data twl6040_vibra = {
.vddvibr_uV = 0,/* fixed volt supply - VBAT */
};
-static struct twl6040_platform_data twl6040_data = {
+static struct twl4030_audio_data twl6040_audio = {
.codec = twl6040_codec,
.vibra = twl6040_vibra,
.audpwron_gpio = 127,
+ .naudint_irq= OMAP44XX_IRQ_SYS_2N,
.irq_base = TWL6040_CODEC_IRQ_BASE,
};
static struct twl4030_platform_data sdp4430_twldata = {
+ .audio = twl6040_audio,
/* Regulators */
.vusim = sdp4430_vusim,
.vaux1 = sdp4430_vaux1,
@@ -582,8 +583,7 @@ static int __init omap4_i2c_init(void)
TWL_COMMON_REGULATOR_VCXIO |
TWL_COMMON_REGULATOR_VUSB |
TWL_COMMON_REGULATOR_CLK32KG);
- omap4_pmic_init(twl6030, sdp4430_twldata,
- twl6040_data, OMAP44XX_IRQ_SYS_2N);
+ omap4_pmic_init(twl6030, sdp4430_twldata);
omap_register_i2c_bus(2, 400, NULL, 0);
omap_register_i2c_bus(3, 400, sdp4430_i2c_3_boardinfo,
ARRAY_SIZE(sdp4430_i2c_3_boardinfo));
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 42f6a27..ad49762 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -36,7 +36,7 @@ static struct twl4030_platform_data sdp4430_twldata = {
static void __init omap4_i2c_init(void)
{
- omap4_pmic_init(twl6030, sdp4430_twldata, NULL, 0);
+ omap4_pmic_init(twl6030, sdp4430_twldata);
}
#endif
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index c39d6d5..28fc271 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -25,7 +25,6 @@
#include linux/gpio.h
#include linux/usb/otg.h
#include linux/i2c/twl.h
-#include linux/mfd/twl6040.h
#include linux/regulator/machine.h
#include linux/regulator/fixed.h
#include linux/wl12xx.h
@@ -278,8 +277,7 @@ static int __init omap4_panda_i2c_init(void)
TWL_COMMON_REGULATOR_VCXIO |
TWL_COMMON_REGULATOR_VUSB |
TWL_COMMON_REGULATOR_CLK32KG);
- omap4_pmic_init(twl6030, omap4_panda_twldata,
- twl6040_data, OMAP44XX_IRQ_SYS_2N);
+ omap4_pmic_init(twl6030, omap4_panda_twldata);
omap_register_i2c_bus(2, 400, NULL, 0);
/*
* Bus 3 is attached to the DVI port where devices like the pico DLP
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index bc03154..10b20c6 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -37,16 +37,6 @@ static struct i2c_board_info __initdata pmic_i2c_board_info
= {
.flags = I2C_CLIENT_WAKE,
};
-static struct i2c_board_info __initdata omap4_i2c1_board_info[] = {
- {
-
[PATCH 5/5] Revert mfd: Detach twl6040 from the pmic mfd driver
This reverts commit 49976f5f8ec350ee0e1191237bb06325840ae5d9.
Reverting changes regarding to twl6040 in MFD tree since the patches will go
via the audio tree.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/mfd/twl-core.c | 58 ---
1 files changed, 25 insertions(+), 33 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index 6c236d0..c1e4f1a 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -115,8 +115,8 @@
#define twl_has_watchdog()false
#endif
-#if defined(CONFIG_MFD_TWL4030_AUDIO) || \
- defined(CONFIG_MFD_TWL4030_AUDIO_MODULE)
+#if defined(CONFIG_MFD_TWL4030_AUDIO) ||
defined(CONFIG_MFD_TWL4030_AUDIO_MODULE) ||\
+ defined(CONFIG_TWL6040_CORE) || defined(CONFIG_TWL6040_CORE_MODULE)
#define twl_has_codec()true
#else
#define twl_has_codec()false
@@ -146,7 +146,6 @@
#define SUB_CHIP_ID1 1
#define SUB_CHIP_ID2 2
#define SUB_CHIP_ID3 3
-#define SUB_CHIP_ID_INVAL 0xff
#define TWL_MODULE_LAST TWL4030_MODULE_LAST
@@ -318,7 +317,7 @@ static struct twl_mapping twl6030_map[] = {
* so they continue to match the order in this table.
*/
{ SUB_CHIP_ID1, TWL6030_BASEADD_USB },
- { SUB_CHIP_ID_INVAL, TWL6030_BASEADD_AUDIO },
+ { SUB_CHIP_ID3, TWL6030_BASEADD_AUDIO },
{ SUB_CHIP_ID2, TWL6030_BASEADD_DIEID },
{ SUB_CHIP_ID2, TWL6030_BASEADD_RSV },
{ SUB_CHIP_ID1, TWL6030_BASEADD_PIH },
@@ -380,11 +379,6 @@ int twl_i2c_write(u8 mod_no, u8 *value, u8 reg, unsigned
num_bytes)
return -EPERM;
}
sid = twl_map[mod_no].sid;
- if (unlikely(sid == SUB_CHIP_ID_INVAL)) {
- pr_err(%s: module %d is not part of the pmic\n,
- DRIVER_NAME, mod_no);
- return -EINVAL;
- }
twl = twl_modules[sid];
mutex_lock(twl-xfer_lock);
@@ -442,11 +436,6 @@ int twl_i2c_read(u8 mod_no, u8 *value, u8 reg, unsigned
num_bytes)
return -EPERM;
}
sid = twl_map[mod_no].sid;
- if (unlikely(sid == SUB_CHIP_ID_INVAL)) {
- pr_err(%s: module %d is not part of the pmic\n,
- DRIVER_NAME, mod_no);
- return -EINVAL;
- }
twl = twl_modules[sid];
mutex_lock(twl-xfer_lock);
@@ -847,6 +836,15 @@ add_children(struct twl4030_platform_data *pdata, unsigned
long features)
return PTR_ERR(child);
}
+ if (twl_has_codec() pdata-audio twl_class_is_6030()) {
+ sub_chip_id = twl_map[TWL_MODULE_AUDIO_VOICE].sid;
+ child = add_child(sub_chip_id, twl6040,
+ pdata-audio, sizeof(*pdata-audio),
+ false, 0, 0);
+ if (IS_ERR(child))
+ return PTR_ERR(child);
+ }
+
/* twl4030 regulators */
if (twl_has_regulator() twl_class_is_4030()) {
child = add_regulator(TWL4030_REG_VPLL1, pdata-vpll1,
@@ -1167,21 +1165,18 @@ int twl6030_exit_irq(void);
static int twl_remove(struct i2c_client *client)
{
- unsigned i, num_slaves;
+ unsigned i;
int status;
- if (twl_class_is_4030()) {
+ if (twl_class_is_4030())
status = twl4030_exit_irq();
- num_slaves = TWL_NUM_SLAVES;
- } else {
+ else
status = twl6030_exit_irq();
- num_slaves = TWL_NUM_SLAVES - 1;
- }
if (status 0)
return status;
- for (i = 0; i num_slaves; i++) {
+ for (i = 0; i TWL_NUM_SLAVES; i++) {
struct twl_client *twl = twl_modules[i];
if (twl-client twl-client != client)
@@ -1197,7 +1192,7 @@ static int __devinit
twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
{
int status;
- unsignedi, num_slaves;
+ unsignedi;
struct twl4030_platform_data*pdata = client-dev.platform_data;
struct device_node *node = client-dev.of_node;
u8 temp;
@@ -1251,17 +1246,7 @@ twl_probe(struct i2c_client *client, const struct
i2c_device_id *id)
return -EBUSY;
}
- if ((id-driver_data) TWL6030_CLASS) {
- twl_id = TWL6030_CLASS_ID;
- twl_map = twl6030_map[0];
- num_slaves = TWL_NUM_SLAVES - 1;
- } else {
- twl_id = TWL4030_CLASS_ID;
- twl_map = twl4030_map[0];
- num_slaves = TWL_NUM_SLAVES;
- }
-
- for (i = 0; i num_slaves; i++) {
+ for (i = 0; i TWL_NUM_SLAVES; i++) {
struct twl_client *twl = twl_modules[i];
twl-address = client-addr + i;
@@ -1280,6 +1265,13 @@ twl_probe(struct i2c_client *client, const
RE: [PATCH] mmc: omap_hsmmc: set dto to 14 for all devices
Ping on this patch. I have not seen any response on the list but if I have
missed something please let me know.
-Original Message-
From: Maupin, Chase
Sent: Thursday, March 01, 2012 11:26 AM
To: linux-omap@vger.kernel.org; linux-...@vger.kernel.org
Cc: Maupin, Chase
Subject: [PATCH] mmc: omap_hsmmc: set dto to 14 for all devices
* With certain SD cards timeouts like the following have been seen
due to an improper calculation of the dto value:
mmcblk0: error -110 transferring data, sector 4126233, nr 8,
card status 0xc00
* By removing the dto calculation and setting the timeout value
to the maximum specified by the SD card specification part A2
section 2.2.15 these timeouts can be avoided.
* This change has been used by beagleboard users as well as the
Texas Instruments SDK without a negative impact.
* There are multiple discussion threads about this but the most
relevant ones are:
* http://talk.maemo.org/showthread.php?p=1000707#post1000707
* http://www.mail-archive.com/linux-
o...@vger.kernel.org/msg42213.html
* Original proposal for this fix was done by Sukumar Ghoral of
Texas Instruments
* Tested using a Texas Instruments AM335x EVM
Signed-off-by: Chase Maupin chase.mau...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 30 +
-
1 files changed, 5 insertions(+), 25 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c
b/drivers/mmc/host/omap_hsmmc.c
index fd0c661..afd7292 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1481,11 +1481,8 @@ static int
omap_hsmmc_start_dma_transfer(struct omap_hsmmc_host *host,
return 0;
}
-static void set_data_timeout(struct omap_hsmmc_host *host,
- unsigned int timeout_ns,
- unsigned int timeout_clks)
+static void set_data_timeout(struct omap_hsmmc_host *host)
{
- unsigned int timeout, cycle_ns;
uint32_t reg, clkd, dto = 0;
reg = OMAP_HSMMC_READ(host-base, SYSCTL);
@@ -1493,25 +1490,8 @@ static void set_data_timeout(struct
omap_hsmmc_host *host,
if (clkd == 0)
clkd = 1;
- cycle_ns = 10 / (clk_get_rate(host-fclk) / clkd);
- timeout = timeout_ns / cycle_ns;
- timeout += timeout_clks;
- if (timeout) {
- while ((timeout 0x8000) == 0) {
- dto += 1;
- timeout = 1;
- }
- dto = 31 - dto;
- timeout = 1;
- if (timeout dto)
- dto += 1;
- if (dto = 13)
- dto -= 13;
- else
- dto = 0;
- if (dto 14)
- dto = 14;
- }
+/* Use the maximum timeout value allowed in the standard of 14
or 0xE */
+ dto = 14;
reg = ~DTO_MASK;
reg |= dto DTO_SHIFT;
@@ -1534,13 +1514,13 @@ omap_hsmmc_prepare_data(struct
omap_hsmmc_host *host, struct mmc_request *req)
* busy signal.
*/
if (req-cmd-flags MMC_RSP_BUSY)
- set_data_timeout(host, 1U, 0);
+ set_data_timeout(host);
return 0;
}
OMAP_HSMMC_WRITE(host-base, BLK, (req-data-blksz)
| (req-data-blocks 16));
- set_data_timeout(host, req-data-timeout_ns, req-data-
timeout_clks);
+ set_data_timeout(host);
if (host-use_dma) {
ret = omap_hsmmc_start_dma_transfer(host, req);
--
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 RFC] spi/omap: Trivial cleanup
On Tuesday 06 March 2012 03:46 PM, Cousson, Benoit wrote: Hi Shubhro, On 2/29/2012 3:04 PM, Shubhrajyoti D wrote: The context is stored directly inside drvdata structure post [f887876 spi/omap: Remove bus_num usage for instance index]. Remove the OMAP2_MCSPI_MAX_CTRL macro as it is not needed anymore. Cc: Benoit Coussonb-cous...@ti.com Signed-off-by: Shubhrajyoti Dshubhrajy...@ti.com Thanks for that extra cleanup, I missed it. Acked-by: Benoit Cousson b-cous...@ti.com --- Applies on Benoit's for_3.4/dt_spi_eth drivers/spi/spi-omap2-mcspi.c |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c index d1eb26c..3526281 100644 --- a/drivers/spi/spi-omap2-mcspi.c +++ b/drivers/spi/spi-omap2-mcspi.c @@ -45,9 +45,6 @@ #define OMAP2_MCSPI_MAX_FREQ4800 -/* OMAP2 has 3 SPI controllers, while OMAP3 has 4 */ -#define OMAP2_MCSPI_MAX_CTRL 4 - I guess it can be included in the spi/omap: Remove bus_num usage for instance index? Is that OK for you? Yes, sure. Thanks, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap2+: add drm device
On Mon, 2012-03-05 at 10:54 -0600, Rob Clark wrote:
From: Andy Gross andy.gr...@ti.com
Register OMAP DRM/KMS platform device, and reserve a CMA region for
the device to use for buffer allocation. DMM is split into a
separate device using hwmod.
Signed-off-by: Andy Gross andy.gr...@ti.com
Signed-off-by: Rob Clark r...@ti.com
---
arch/arm/plat-omap/Makefile |2 +-
arch/arm/plat-omap/common.c |3 +-
arch/arm/plat-omap/drm.c | 83
+
arch/arm/plat-omap/include/plat/drm.h | 64 +
4 files changed, 150 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/plat-omap/drm.c
create mode 100644 arch/arm/plat-omap/include/plat/drm.h
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 9a58461..b86e6cb 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -4,7 +4,7 @@
# Common support
obj-y := common.o sram.o clock.o devices.o dma.o mux.o \
- usb.o fb.o counter_32k.o
+ usb.o fb.o counter_32k.o drm.o
obj-m :=
obj-n :=
obj- :=
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index 06383b5..0d87dab 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -21,10 +21,10 @@
#include plat/board.h
#include plat/vram.h
#include plat/dsp.h
+#include plat/drm.h
#include plat/omap-secure.h
-
#define NO_LENGTH_CHECK 0x
struct omap_board_config_kernel *omap_board_config __initdata;
@@ -65,6 +65,7 @@ const void *__init omap_get_var_config(u16 tag, size_t *len)
void __init omap_reserve(void)
{
+ omapdrm_reserve_vram();
omapfb_reserve_sdram_memblock();
omap_vram_reserve_sdram_memblock();
omap_dsp_reserve_sdram_memblock();
diff --git a/arch/arm/plat-omap/drm.c b/arch/arm/plat-omap/drm.c
As Tony said, mach-omap2 is probably a better place. fb.c is in
plat-omap because it supports both OMAP1 and OMAP2+.
new file mode 100644
index 000..28279df
--- /dev/null
+++ b/arch/arm/plat-omap/drm.c
@@ -0,0 +1,83 @@
+/*
+ * DRM/KMS device registration for TI OMAP platforms
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Rob Clark rob.cl...@linaro.org
+ *
+ * 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, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/mm.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/dma-mapping.h
+#ifdef CONFIG_CMA
+# include linux/dma-contiguous.h
+#endif
+
+#include plat/omap_device.h
+#include plat/omap_hwmod.h
+
+#include plat/drm.h
+
+#if defined(CONFIG_DRM_OMAP) || (CONFIG_DRM_OMAP_MODULE)
+
+static struct omap_drm_platform_data omapdrm_platdata;
+
+static struct platform_device omap_drm_device = {
+ .dev = {
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ .platform_data = omapdrm_platdata,
+ },
+ .name = omapdrm,
+ .id = 0,
Can there be more than one omapdrm device? I guess not. If so, the id
should be -1.
+};
+
+static int __init omap_init_gpu(void)
+{
+ struct omap_hwmod *oh = NULL;
+ struct platform_device *pdev;
+
+ /* lookup and populate the DMM information, if present - OMAP4+ */
+ oh = omap_hwmod_lookup(dmm);
+
+ if (oh) {
+ pdev = omap_device_build(oh-name, -1, oh, NULL, 0, NULL, 0,
+ false);
+ WARN(IS_ERR(pdev), Could not build omap_device for %s\n,
+ oh-name);
+ }
+
+ return platform_device_register(omap_drm_device);
+
+}
The function is called omap_init_gpu(), but it doesn't do anything
related to the gpu... And aren't DMM and DRM totally separate things,
why are they bunched together like that?
+arch_initcall(omap_init_gpu);
+
+void omapdrm_reserve_vram(void)
+{
+#ifdef CONFIG_CMA
+ /*
+ * Create private 32MiB contiguous memory area for omapdrm.0 device
+ * TODO revisit size.. if uc/wc buffers are allocated from CMA pages
+ * then the amount of memory we need goes up..
+ */
+ dma_declare_contiguous(omap_drm_device.dev, 32 * SZ_1M, 0, 0);
What does this actually do? Does it reserve the memory, i.e. it's not
usable for others? If so, shouldn't there be a way for the user to
configure it?
+#else
Re: [PATCH] omap2+: add drm device
On Tue, Mar 6, 2012 at 7:26 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Mon, 2012-03-05 at 10:54 -0600, Rob Clark wrote:
From: Andy Gross andy.gr...@ti.com
Register OMAP DRM/KMS platform device, and reserve a CMA region for
the device to use for buffer allocation. DMM is split into a
separate device using hwmod.
Signed-off-by: Andy Gross andy.gr...@ti.com
Signed-off-by: Rob Clark r...@ti.com
---
arch/arm/plat-omap/Makefile | 2 +-
arch/arm/plat-omap/common.c | 3 +-
arch/arm/plat-omap/drm.c | 83
+
arch/arm/plat-omap/include/plat/drm.h | 64 +
4 files changed, 150 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/plat-omap/drm.c
create mode 100644 arch/arm/plat-omap/include/plat/drm.h
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 9a58461..b86e6cb 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -4,7 +4,7 @@
# Common support
obj-y := common.o sram.o clock.o devices.o dma.o mux.o \
- usb.o fb.o counter_32k.o
+ usb.o fb.o counter_32k.o drm.o
obj-m :=
obj-n :=
obj- :=
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index 06383b5..0d87dab 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -21,10 +21,10 @@
#include plat/board.h
#include plat/vram.h
#include plat/dsp.h
+#include plat/drm.h
#include plat/omap-secure.h
-
#define NO_LENGTH_CHECK 0x
struct omap_board_config_kernel *omap_board_config __initdata;
@@ -65,6 +65,7 @@ const void *__init omap_get_var_config(u16 tag, size_t
*len)
void __init omap_reserve(void)
{
+ omapdrm_reserve_vram();
omapfb_reserve_sdram_memblock();
omap_vram_reserve_sdram_memblock();
omap_dsp_reserve_sdram_memblock();
diff --git a/arch/arm/plat-omap/drm.c b/arch/arm/plat-omap/drm.c
As Tony said, mach-omap2 is probably a better place. fb.c is in
plat-omap because it supports both OMAP1 and OMAP2+.
new file mode 100644
index 000..28279df
--- /dev/null
+++ b/arch/arm/plat-omap/drm.c
@@ -0,0 +1,83 @@
+/*
+ * DRM/KMS device registration for TI OMAP platforms
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Rob Clark rob.cl...@linaro.org
+ *
+ * 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, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/mm.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/dma-mapping.h
+#ifdef CONFIG_CMA
+# include linux/dma-contiguous.h
+#endif
+
+#include plat/omap_device.h
+#include plat/omap_hwmod.h
+
+#include plat/drm.h
+
+#if defined(CONFIG_DRM_OMAP) || (CONFIG_DRM_OMAP_MODULE)
+
+static struct omap_drm_platform_data omapdrm_platdata;
+
+static struct platform_device omap_drm_device = {
+ .dev = {
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ .platform_data = omapdrm_platdata,
+ },
+ .name = omapdrm,
+ .id = 0,
Can there be more than one omapdrm device? I guess not. If so, the id
should be -1.
in the past, we have used multiple devices (using the platform-data to
divide up the dss resources), although this was sort of a
special-case. But in theory you could have multiple. (Think of a
multi-seat scenario, where multiple compositors need to run and each
need to be drm-master of their own device to do mode-setting on their
corresponding display.)
I think if we use .id = -1, then we'd end up with a funny looking
bus-id for the device: platform:omapdrm:-1
+};
+
+static int __init omap_init_gpu(void)
+{
+ struct omap_hwmod *oh = NULL;
+ struct platform_device *pdev;
+
+ /* lookup and populate the DMM information, if present - OMAP4+ */
+ oh = omap_hwmod_lookup(dmm);
+
+ if (oh) {
+ pdev = omap_device_build(oh-name, -1, oh, NULL, 0, NULL, 0,
+ false);
+ WARN(IS_ERR(pdev), Could not build omap_device for %s\n,
+ oh-name);
+ }
+
+ return platform_device_register(omap_drm_device);
+
+}
The function is called omap_init_gpu(), but it doesn't do anything
related to the gpu... And aren't DMM and DRM totally separate things,
why are they bunched together like that?
only
Re: [PATCHv4 4/6] ARM: OMAP3+: PRM: Enable IO wake up
On Tue, 2012-03-06 at 10:26 +0530, Rajendra Nayak wrote: On Tuesday 06 March 2012 10:20 AM, Rajendra Nayak wrote: On Tuesday 06 March 2012 09:51 AM, Paul Walmsley wrote: added Rajendra, Nilesh, Vishwa, Mohan Hi On Fri, 2 Mar 2012, Tero Kristo wrote: Enable IO Wake up for OMAP3/4 as part of PRM Init. Currently this has been managed in cpuidle path which is not the right place. Subsequent patch will remove IO Daisy chain handling in cpuidle path once daisy chain is handled as part of hwmod mux. This patch also moves the OMAP4 IO wakeup enable code from the trigger function to init time setup. Signed-off-by: Tero Kristot-kri...@ti.com Should we keep the I/O wakeups enabled all the time? Seems like that could result in at least one spurious wake-up event -- and thus a PRCM interrupt -- for each I/O pad that has WAKEUPENABLE set. Seems like these interrupts could recur every time the I/O chain is reset. And that the I/O chain is now reset in every hwmod idle and enable operation for an IP block that contains dynamic mux data? Thinking about the problem naïvely... maybe you all can think through this with me: Consider an IP block 'A' that has a signal (like the UART rx_irrx signal) that's mux'ed to a pad with WAKEUPENABLE set. (Some examples of 'A' might include a UART, a GPIO, or a McBSP.) Shouldn't we enable I/O wakeups (by setting EN_IO/GLOBAL_WUEN) only immediately before the powerdomain containing IP block 'A' is going to transition into RETENTION or OFF? Hi Paul, I completely agree with your observations and we knew we would have additional wakeups with this design. Like I mentioned in the other thread, we went ahead with this approach knowing we need to optimize with some kind of powerdomain level usecounting in the future, because it didn't exist back then when we did it this way. But now that we already have it, maybe we can fix this and do it such that we completely avoid an additional wakeup interrupt. If we do that, then we can avoid needlessly resetting the I/O chain when a powerdomain is not going to go into a low-power state. I haven't measured the time it takes for the I/O chain to be reset. Maybe one of you have. But that 100 microsecond timeout that was specified in two of the other patches in this series has me a little worried. I haven't profiled it myself but I am guessing the delay isn't much. Having said that, I do agree with you that, however small the delay, we end up doing needless IO trigger when the powerdomain isn't really entering a low power state. After some measurements (used ARM performance counters for this), it looks like omap4 takes between 2...4us for the IO chain trigger. omap3 takes 7...8us, most of which appears to be delay caused by interconnect, the poll loops don't actually have time to do anything. Speaking of which, the trigger function was pretty broken for omap3 on this set, I noticed that while doing the profiling. The fixed one takes this time, I'll post a new version of the whole set shortly. -Tero The 100us comes from the fact that there is no documentation on the exact delay, so went around asking whats the *real worst case* delay, and we got an answer, 100us should be really big enough :) regards, Rajendra - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap2+: add drm device
On Tue, 2012-03-06 at 08:01 -0600, Rob Clark wrote:
On Tue, Mar 6, 2012 at 7:26 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
Can there be more than one omapdrm device? I guess not. If so, the id
should be -1.
in the past, we have used multiple devices (using the platform-data to
divide up the dss resources), although this was sort of a
special-case. But in theory you could have multiple. (Think of a
multi-seat scenario, where multiple compositors need to run and each
need to be drm-master of their own device to do mode-setting on their
corresponding display.)
I think if we use .id = -1, then we'd end up with a funny looking
bus-id for the device: platform:omapdrm:-1
I don't know about that, but it's the way platform devices are meant to
be used if there can be only one instance. If the case where there are
multiple omapdrm devices is rather theoretical, or only used for certain
debugging scenarios or such, I think having the id as -1 in the mainline
is cleaner.
+};
+
+static int __init omap_init_gpu(void)
+{
+ struct omap_hwmod *oh = NULL;
+ struct platform_device *pdev;
+
+ /* lookup and populate the DMM information, if present - OMAP4+ */
+ oh = omap_hwmod_lookup(dmm);
+
+ if (oh) {
+ pdev = omap_device_build(oh-name, -1, oh, NULL, 0, NULL, 0,
+ false);
+ WARN(IS_ERR(pdev), Could not build omap_device for %s\n,
+ oh-name);
+ }
+
+ return platform_device_register(omap_drm_device);
+
+}
The function is called omap_init_gpu(), but it doesn't do anything
related to the gpu... And aren't DMM and DRM totally separate things,
why are they bunched together like that?
only legacy.. product branches also have sgx initialization here. But
I can change that to omap_init_drm()
DMM is managed by the drm driver (and exposed to userspace as drm/gem
buffers, shared with other devices via dma-buf, etc). It is only
split out to a separate device to play along with hwmod.
I have to say I don't know much about DMM, but my understanding is that
DMM is a bigger entity, of which TILER is only a small part, and DMM
manages all memory accesses.
Can there be other users for the DMM than DRM? I know there could be
other users for the TILER, and I know you want to combine that with the
DRM driver, but I'm wondering about the other parts of DMM than the
TILER.
Somehow having a DMM driver inside omapdrm sounds strange.
+arch_initcall(omap_init_gpu);
+
+void omapdrm_reserve_vram(void)
+{
+#ifdef CONFIG_CMA
+ /*
+ * Create private 32MiB contiguous memory area for omapdrm.0 device
+ * TODO revisit size.. if uc/wc buffers are allocated from CMA pages
+ * then the amount of memory we need goes up..
+ */
+ dma_declare_contiguous(omap_drm_device.dev, 32 * SZ_1M, 0, 0);
What does this actually do? Does it reserve the memory, i.e. it's not
usable for others? If so, shouldn't there be a way for the user to
configure it?
It can be re-used by others.. see http://lwn.net/Articles/479297/
The link didn't tell much. I looked at the patches, and
dma_declare_contiguous allocates the memory with memblock_alloc. So is
that allocated memory available for any users? If so, why does the
function want a device pointer as an argument...
Is the memory available for normal kmalloc, or only available via the
CMA functions? Surely there must be some downside to the above? =) And
if so, it should be configurable. You could have a board with no display
at all, and you probably don't want to have 32MB allocated for DRM in
that case.
Tomi
signature.asc
Description: This is a digitally signed message part
Re: OMAP totally fucked?
On 3/3/2012 10:21 PM, Tony Lindgren wrote: * Russell King - ARM Linuxli...@arm.linux.org.uk [120303 12:20]: On Sat, Mar 03, 2012 at 12:34:48PM -0800, Tony Lindgren wrote: * Tony Lindgrent...@atomide.com [120303 11:56]: * Tony Lindgrent...@atomide.com [120303 11:29]: * Russell King - ARM Linuxli...@arm.linux.org.uk [120303 10:57]: Even with the full config, making oldconfig I get: OMAP2420 support (SOC_OMAP2420) [Y/n] (NEW) OMAP2430 support (SOC_OMAP2430) [Y/n] (NEW) OMAP3430 support (SOC_OMAP3430) [Y/n] (NEW) TI81XX support (SOC_OMAPTI81XX) [Y/n] (NEW) AM33XX support (SOC_OMAPAM33XX) [Y/n] (NEW) OMAP44XX support (SOC_OMAP44XX) [Y/n] (NEW) May I remind you of this mail from Linus: https://lkml.org/lkml/2012/1/6/354 So really this is a rather horrid mess. Hmm yes. Sounds like we need to remove the defaults and instead add them to omap2plus_defconfig. I'll do a patch to fix that. How about the following patch after we revert commit 72b026a4? That still leaves the randconfig not necessarily selecting any of ARCH_OMAP2/3/4 issue, but that can be dealt separately later on. Grr, need to look at it more.. Now it leaves out ARCH_OMAP2/3/4 when doing a make oldconfig with some existing .config file. There's also something else wrong: * * OMAP Core Type * OMAP2420 support (SOC_OMAP2420) [Y/n] (NEW) n OMAP2430 support (SOC_OMAP2430) [Y/n] (NEW) n OMAP3430 support (SOC_OMAP3430) [Y/n] (NEW) n TI81XX support (SOC_OMAPTI81XX) [Y/n] (NEW) n AM33XX support (SOC_OMAPAM33XX) [Y/n] (NEW) n OMAP44XX support (SOC_OMAP44XX) [Y/n] (NEW) n * * OMAP Board Type * Generic OMAP2+ board (MACH_OMAP_GENERIC) [Y/?] y OMAP3 debugging peripherals (OMAP3_EMU) [N/y/?] (NEW) Enable SDRC AC timing register changes (OMAP3_SDRC_AC_TIMING) [N/y/?] (NEW) Shouldn't the last two options depend on OMAP3 stuff? Yes it should. Looks like the default n there can go too. I think the best solution is to have the board select the omap type. From user point of view there's really no need to have separate menu for selecting the omap type, selecting just the board is a bit more intuitive. Anyways, we should revert commit 72b026a4 because of the breakage it causes. And why do we have: config ARCH_OMAP2PLUS select USE_OF Do we really _need_ OF, or is it just irqdomain that's required? Let's check, maybe the irqdomain is still enough here except for MACH_OMAP_GENERIC to here. Eventually we'll be needing OF, but that's still few merge cycles away. We added that to avoid cluttering the drivers with a bunch of #ifdef CONFIG_OF as proposed by Grant and Rob... and most drivers adaptation were done having that assumption. So if we removed that today, it will be like removing the IRQDOMAIN define during the last merge window, it will break when the drivers DT adaptation will be pulled. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP totally fucked?
On Tue, Mar 06, 2012 at 03:58:34PM +0100, Cousson, Benoit wrote: We added that to avoid cluttering the drivers with a bunch of #ifdef CONFIG_OF as proposed by Grant and Rob... and most drivers adaptation were done having that assumption. So if we removed that today, it will be like removing the IRQDOMAIN define during the last merge window, it will break when the drivers DT adaptation will be pulled. But aren't the OF interfaces stubbed out in linux/of.h when DT support is disabled? Or are you saying that we're heading for a situation where _existing_ drivers stop working when OF isn't enabled? -- 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
[PATCHv5 0/6] ARM: OMAP3+: IO daisy chain support fixes
Hi, Changes compared to previous version: - patch2: * fixed the timeout for waiting for ST_IO_CHAIN == 1 * added clear for ST_IO_CHAIN bit (as per spec + implementation in patch 1) * replaced the timeout at the end of function with a simple register readback (timing out on a register value that we are clearing does not make that much sense, the bit is cleared the very first time CPU manages to read it) - patch5: * added spinlock for protecting io_chain_trigger operation Tested on omap3 beagle + omap4 blaze. Also did measurements for the cost of IO chain trigger operation with ARM performance counters: - omap3 approx 7...8us - omap4 approx 2...4us -Tero -- 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
[PATCHv5 2/6] ARM: OMAP3 PM: Move IO Daisychain function to omap3 prm file
From: Vishwanath BS vishwanath...@ti.com
Since IO Daisychain modifies only PRM registers, it makes sense to move
it to PRM File. Also changed the timeout value for IO chain enable to
100us and added a wait for status disable at the end.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/pm34xx.c | 30 +
arch/arm/mach-omap2/prm2xxx_3xxx.c | 37
arch/arm/mach-omap2/prm2xxx_3xxx.h | 14 +
3 files changed, 52 insertions(+), 29 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index b0821a8..e97ec3f 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -85,34 +85,6 @@ static inline void omap3_per_restore_context(void)
omap_gpio_restore_context();
}
-static void omap3_enable_io_chain(void)
-{
- int timeout = 0;
-
- omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
- PM_WKEN);
- /* Do a readback to assure write has been done */
- omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN);
-
- while (!(omap2_prm_read_mod_reg(WKUP_MOD, PM_WKST)
-OMAP3430_ST_IO_CHAIN_MASK)) {
- timeout++;
- if (timeout 1000) {
- pr_err(Wake up daisy chain activation failed.\n);
- return;
- }
- }
- omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
- PM_WKEN);
-
-}
-
-static void omap3_disable_io_chain(void)
-{
- omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
-PM_WKEN);
-}
-
static void omap3_core_save_context(void)
{
omap3_ctrl_save_padconf();
@@ -324,7 +296,7 @@ void omap_sram_idle(void)
core_next_state PWRDM_POWER_ON)) {
omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD,
PM_WKEN);
if (omap3_has_io_chain_ctrl())
- omap3_enable_io_chain();
+ omap3_trigger_io_chain();
}
pwrdm_pre_transition();
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.c
b/arch/arm/mach-omap2/prm2xxx_3xxx.c
index 9ce7654..2f45b96 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.c
@@ -301,6 +301,43 @@ void omap3xxx_prm_restore_irqen(u32 *saved_mask)
OMAP3_PRM_IRQENABLE_MPU_OFFSET);
}
+/*
+ * Maximum time(us) it takes to output the signal WUCLKOUT of the last pad of
+ * the I/O ring after asserting WUCLKIN high
+ */
+#define MAX_IOPAD_LATCH_TIME 100
+
+/* OMAP3 Daisychain enable sequence */
+void omap3_trigger_io_chain(void)
+{
+ int i = 0;
+
+ omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
+ PM_WKEN);
+ /* Do a readback to assure write has been done */
+ omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN);
+
+ omap_test_timeout(omap2_prm_read_mod_reg(WKUP_MOD, PM_WKST)
+ OMAP3430_ST_IO_CHAIN_MASK,
+ MAX_IOPAD_LATCH_TIME, i);
+
+ omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
+PM_WKEN);
+
+ omap2_prm_set_mod_reg_bits(OMAP3430_ST_IO_CHAIN_MASK, WKUP_MOD,
+PM_WKST);
+
+ omap2_prm_read_mod_reg(WKUP_MOD, PM_WKST);
+}
+
+/* OMAP3 Daisychain disable sequence */
+void omap3_disable_io_chain(void)
+{
+ if (omap_rev() = OMAP3430_REV_ES3_1)
+ omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK,
+WKUP_MOD, PM_WKEN);
+}
+
static int __init omap3xxx_prcm_init(void)
{
if (cpu_is_omap34xx())
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.h
b/arch/arm/mach-omap2/prm2xxx_3xxx.h
index 70ac2a1..15973aa 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.h
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.h
@@ -289,6 +289,18 @@ static inline int omap2_prm_deassert_hardreset(s16
prm_mod, u8 rst_shift,
not suppose to be used on omap4\n);
return 0;
}
+static inline void omap3_trigger_io_chain(void)
+{
+ WARN(1, prm: omap2xxx/omap3xxx specific function and
+ not suppose to be used on omap4\n);
+ return 0;
+}
+static inline void omap3_disable_io_chain(void)
+{
+ WARN(1, prm: omap2xxx/omap3xxx specific function and
+ not suppose to be used on omap4\n);
+ return 0;
+}
#else
/* Power/reset management domain register get/set */
extern u32 omap2_prm_read_mod_reg(s16 module, u16 idx);
@@ -302,6 +314,8 @@ extern u32 omap2_prm_read_mod_bits_shift(s16 domain, s16
idx, u32 mask);
extern int omap2_prm_is_hardreset_asserted(s16 prm_mod, u8 shift);
extern int omap2_prm_assert_hardreset(s16 prm_mod, u8 shift);
extern int
[PATCHv5 3/6] ARM: OMAP4 PM: Add IO Daisychain support
From: Rajendra Nayak rna...@ti.com
IO daisychain is a mechanism that allows individual IO pads to generate
wakeup events on their own based on a switch of an input signal level.
This allows the hardware module behind the pad to be powered down, but
still have device level capability to detect IO events, and once this
happens the module can be powered back up to resume IO. See section
3.9.4 in OMAP4430 Public TRM for details.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/prm44xx.c | 41 +
arch/arm/mach-omap2/prm44xx.h |1 +
2 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index a37bfd4..caa5e0f 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -231,6 +231,47 @@ void omap44xx_prm_restore_irqen(u32 *saved_mask)
OMAP4_PRM_IRQENABLE_MPU_2_OFFSET);
}
+/*
+ * Maximum time(us) it takes to output the signal WUCLKOUT of the last pad of
+ * the I/O ring after asserting WUCLKIN high
+ */
+#define MAX_IOPAD_LATCH_TIME 100
+
+/* OMAP4 IO Daisychain trigger sequence */
+void omap4_trigger_io_chain(void)
+{
+ int i = 0;
+
+ /* Enable GLOBAL_WUEN */
+ if (!(omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
+ OMAP4_PRM_IO_PMCTRL_OFFSET) OMAP4430_GLOBAL_WUEN_MASK))
+ omap4_prm_rmw_inst_reg_bits(OMAP4430_GLOBAL_WUEN_MASK,
+ OMAP4430_GLOBAL_WUEN_MASK, OMAP4430_PRM_DEVICE_INST,
+ OMAP4_PRM_IO_PMCTRL_OFFSET);
+
+ /* Trigger WUCLKIN enable */
+ omap4_prm_rmw_inst_reg_bits(OMAP4430_WUCLK_CTRL_MASK,
+ OMAP4430_WUCLK_CTRL_MASK, OMAP4430_PRM_DEVICE_INST,
+ OMAP4_PRM_IO_PMCTRL_OFFSET);
+ omap_test_timeout(
+ (((omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
+ OMAP4_PRM_IO_PMCTRL_OFFSET)
+ OMAP4430_WUCLK_STATUS_MASK)
+ OMAP4430_WUCLK_STATUS_SHIFT) == 1),
+ MAX_IOPAD_LATCH_TIME, i);
+
+ /* Trigger WUCLKIN disable */
+ omap4_prm_rmw_inst_reg_bits(OMAP4430_WUCLK_CTRL_MASK, 0x0,
+ OMAP4430_PRM_DEVICE_INST, OMAP4_PRM_IO_PMCTRL_OFFSET);
+ omap_test_timeout(
+ (((omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
+ OMAP4_PRM_IO_PMCTRL_OFFSET)
+ OMAP4430_WUCLK_STATUS_MASK)
+ OMAP4430_WUCLK_STATUS_SHIFT) == 0),
+ MAX_IOPAD_LATCH_TIME, i);
+ return;
+}
+
static int __init omap4xxx_prcm_init(void)
{
if (cpu_is_omap44xx())
diff --git a/arch/arm/mach-omap2/prm44xx.h b/arch/arm/mach-omap2/prm44xx.h
index 7978092..54a057e 100644
--- a/arch/arm/mach-omap2/prm44xx.h
+++ b/arch/arm/mach-omap2/prm44xx.h
@@ -762,6 +762,7 @@ void omap4_prm_vp_clear_txdone(u8 vp_id);
extern u32 omap4_prm_vcvp_read(u8 offset);
extern void omap4_prm_vcvp_write(u32 val, u8 offset);
extern u32 omap4_prm_vcvp_rmw(u32 mask, u32 bits, u8 offset);
+extern void omap4_trigger_io_chain(void);
/* PRM interrupt-related functions */
extern void omap44xx_prm_read_pending_irqs(unsigned long *events);
--
1.7.4.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
[PATCHv5 1/6] ARM: OMAP3 PM: correct enable/disable of daisy io chain
From: Mohan V moh...@ti.com
Currently the enabling and disabling of IO Daisy chain is not
according to the TRM. The below steps are followed to enable/
disable the IO chain according to the Sec 3.5.7.2.2
I/O Wake-Up Mechanism in OMAP3630 Public TRM[1].
Steps to enable IO chain:
[a] Set PM_WKEN_WKUP.EN_IO bit
[b] Set the PM_WKEN_WKUP.EN_IO_CHAIN bit
[c] Poll for PM_WKST_WKUP.ST_IO_CHAIN.
[d] When ST_IO_CHAIN bit set to 1, clear PM_WKEN_WKUP.EN_IO_CHAIN
[e] Clear ST_IO_CHAIN bit.
Steps to disable IO chain:
[a] Clear PM_WKEN_WKUP.EN_IO_CHAIN bit
[b] Clear PM_WKEN_WKUP.EN_IO bit
[c] Clear PM_WKST_WKUP.ST_IO bit by writing 1 to it.
Step [e] [c] in each case can be skipped, as these are handled
by the PRCM interrupt handler later.
[1] http://focus.ti.com/pdfs/wtbu/OMAP36xx_ES1.x_PUBLIC_TRM_vV.zip
Signed-off-by: Mohan V moh...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Reviewed-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/pm34xx.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index fc69875..b0821a8 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -94,16 +94,17 @@ static void omap3_enable_io_chain(void)
/* Do a readback to assure write has been done */
omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN);
- while (!(omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN)
+ while (!(omap2_prm_read_mod_reg(WKUP_MOD, PM_WKST)
OMAP3430_ST_IO_CHAIN_MASK)) {
timeout++;
if (timeout 1000) {
pr_err(Wake up daisy chain activation failed.\n);
return;
}
- omap2_prm_set_mod_reg_bits(OMAP3430_ST_IO_CHAIN_MASK,
- WKUP_MOD, PM_WKEN);
}
+ omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
+ PM_WKEN);
+
}
static void omap3_disable_io_chain(void)
--
1.7.4.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
[PATCHv5 4/6] ARM: OMAP3+: PRM: Enable IO wake up
Enable IO Wake up for OMAP3/4 as part of PRM Init. Currently this has been
managed in cpuidle path which is not the right place. Subsequent patch
will remove IO Daisy chain handling in cpuidle path once daisy chain is
handled as part of hwmod mux. This patch also moves the OMAP4 IO wakeup
enable code from the trigger function to init time setup.
Signed-off-by: Tero Kristo t-kri...@ti.com
Reviewed-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/prm2xxx_3xxx.c | 11 ++-
arch/arm/mach-omap2/prm44xx.c | 18 ++
2 files changed, 20 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.c
b/arch/arm/mach-omap2/prm2xxx_3xxx.c
index 2f45b96..f0179f6 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.c
@@ -338,10 +338,19 @@ void omap3_disable_io_chain(void)
WKUP_MOD, PM_WKEN);
}
+static void __init omap3_enable_io_wakeup(void)
+{
+ if (omap3_has_io_wakeup())
+ omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD,
+ PM_WKEN);
+}
+
static int __init omap3xxx_prcm_init(void)
{
- if (cpu_is_omap34xx())
+ if (cpu_is_omap34xx()) {
+ omap3_enable_io_wakeup();
return omap_prcm_register_chain_handler(omap3_prcm_irq_setup);
+ }
return 0;
}
subsys_initcall(omap3xxx_prcm_init);
diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index caa5e0f..4ce6f08 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -242,13 +242,6 @@ void omap4_trigger_io_chain(void)
{
int i = 0;
- /* Enable GLOBAL_WUEN */
- if (!(omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
- OMAP4_PRM_IO_PMCTRL_OFFSET) OMAP4430_GLOBAL_WUEN_MASK))
- omap4_prm_rmw_inst_reg_bits(OMAP4430_GLOBAL_WUEN_MASK,
- OMAP4430_GLOBAL_WUEN_MASK, OMAP4430_PRM_DEVICE_INST,
- OMAP4_PRM_IO_PMCTRL_OFFSET);
-
/* Trigger WUCLKIN enable */
omap4_prm_rmw_inst_reg_bits(OMAP4430_WUCLK_CTRL_MASK,
OMAP4430_WUCLK_CTRL_MASK, OMAP4430_PRM_DEVICE_INST,
@@ -272,10 +265,19 @@ void omap4_trigger_io_chain(void)
return;
}
+static void __init omap4_enable_io_wakeup(void)
+{
+ omap4_prm_rmw_inst_reg_bits(OMAP4430_GLOBAL_WUEN_MASK,
+ OMAP4430_GLOBAL_WUEN_MASK, OMAP4430_PRM_DEVICE_INST,
+ OMAP4_PRM_IO_PMCTRL_OFFSET);
+}
+
static int __init omap4xxx_prcm_init(void)
{
- if (cpu_is_omap44xx())
+ if (cpu_is_omap44xx()) {
+ omap4_enable_io_wakeup();
return omap_prcm_register_chain_handler(omap4_prcm_irq_setup);
+ }
return 0;
}
subsys_initcall(omap4xxx_prcm_init);
--
1.7.4.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
[PATCHv5 6/6] ARM: OMAP3 PM: Remove IO Daisychain control from cpuidle
From: Vishwanath BS vishwanath...@ti.com
As IO Daisy chain sequence is triggered via hwmod mux, there is no need to
control it from cpuidle path for OMAP3.
Also as omap3_disable_io_chain is no longer being used, just remove the
function.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Signed-off-by: Tero Kristo t-kri...@ti.com
Reviewed-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/pm34xx.c | 17 -
arch/arm/mach-omap2/prm2xxx_3xxx.c |8
arch/arm/mach-omap2/prm2xxx_3xxx.h |7 ---
3 files changed, 0 insertions(+), 32 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index e97ec3f..ed12bb4 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -291,13 +291,6 @@ void omap_sram_idle(void)
/* Enable IO-PAD and IO-CHAIN wakeups */
per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
- if (omap3_has_io_wakeup()
- (per_next_state PWRDM_POWER_ON ||
-core_next_state PWRDM_POWER_ON)) {
- omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD,
PM_WKEN);
- if (omap3_has_io_chain_ctrl())
- omap3_trigger_io_chain();
- }
pwrdm_pre_transition();
@@ -376,16 +369,6 @@ void omap_sram_idle(void)
omap3_per_restore_context();
}
- /* Disable IO-PAD and IO-CHAIN wakeup */
- if (omap3_has_io_wakeup()
- (per_next_state PWRDM_POWER_ON ||
-core_next_state PWRDM_POWER_ON)) {
- omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD,
-PM_WKEN);
- if (omap3_has_io_chain_ctrl())
- omap3_disable_io_chain();
- }
-
clkdm_allow_idle(mpu_pwrdm-pwrdm_clkdms[0]);
}
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.c
b/arch/arm/mach-omap2/prm2xxx_3xxx.c
index f0179f6..b8962fe 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.c
@@ -330,14 +330,6 @@ void omap3_trigger_io_chain(void)
omap2_prm_read_mod_reg(WKUP_MOD, PM_WKST);
}
-/* OMAP3 Daisychain disable sequence */
-void omap3_disable_io_chain(void)
-{
- if (omap_rev() = OMAP3430_REV_ES3_1)
- omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK,
-WKUP_MOD, PM_WKEN);
-}
-
static void __init omap3_enable_io_wakeup(void)
{
if (omap3_has_io_wakeup())
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.h
b/arch/arm/mach-omap2/prm2xxx_3xxx.h
index 15973aa..391b844 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.h
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.h
@@ -295,12 +295,6 @@ static inline void omap3_trigger_io_chain(void)
not suppose to be used on omap4\n);
return 0;
}
-static inline void omap3_disable_io_chain(void)
-{
- WARN(1, prm: omap2xxx/omap3xxx specific function and
- not suppose to be used on omap4\n);
- return 0;
-}
#else
/* Power/reset management domain register get/set */
extern u32 omap2_prm_read_mod_reg(s16 module, u16 idx);
@@ -315,7 +309,6 @@ extern int omap2_prm_is_hardreset_asserted(s16 prm_mod, u8
shift);
extern int omap2_prm_assert_hardreset(s16 prm_mod, u8 shift);
extern int omap2_prm_deassert_hardreset(s16 prm_mod, u8 rst_shift, u8
st_shift);
extern void omap3_trigger_io_chain(void);
-extern void omap3_disable_io_chain(void);
/* OMAP3-specific VP functions */
u32 omap3_prm_vp_check_txdone(u8 vp_id);
--
1.7.4.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
[PATCHv5 5/6] ARM: OMAP3PLUS PM: Add IO Daisychain support via hwmod mux
From: Vishwanath BS vishwanath...@ti.com
IO Daisychain feature has to be triggered whenever there is a change in
device's mux configuration (See section 3.9.4 in OMAP4 Public TRM vP).
Now devices can idle independent of the powerdomain, there can be a
window where device is idled and corresponding powerdomain can be
ON/INACTIVE state. In such situations, since both module wake up is
enabled at padlevel as well as io daisychain sequence is triggered,
there will be 2 PRCM interrupts (Module async wake up via swakeup and
IO Pad interrupt). But as PRCM Interrupt handler clears the Module
Padlevel WKST bit in the first interrupt, module specific interrupt
handler will not triggered for the second time
Also look at detailed explanation given by Rajendra at
http://www.spinics.net/lists/linux-serial/msg04480.html
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c |9 +++--
arch/arm/mach-omap2/pm.c | 21 +
arch/arm/mach-omap2/pm.h |1 +
3 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 5192cab..56adbfb 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -152,6 +152,7 @@
#include prm44xx.h
#include prminst44xx.h
#include mux.h
+#include pm.h
/* Maximum microseconds to wait for OMAP module to softreset */
#define MAX_MODULE_SOFTRESET_WAIT 1
@@ -1535,8 +1536,10 @@ static int _enable(struct omap_hwmod *oh)
/* Mux pins for device runtime if populated */
if (oh-mux (!oh-mux-enabled ||
((oh-_state == _HWMOD_STATE_IDLE)
-oh-mux-pads_dynamic)))
+oh-mux-pads_dynamic))) {
omap_hwmod_mux(oh-mux, _HWMOD_STATE_ENABLED);
+ omap_trigger_io_chain();
+ }
_add_initiator_dep(oh, mpu_oh);
@@ -1622,8 +1625,10 @@ static int _idle(struct omap_hwmod *oh)
clkdm_hwmod_disable(oh-clkdm, oh);
/* Mux pins for device idle if populated */
- if (oh-mux oh-mux-pads_dynamic)
+ if (oh-mux oh-mux-pads_dynamic) {
omap_hwmod_mux(oh-mux, _HWMOD_STATE_IDLE);
+ omap_trigger_io_chain();
+ }
oh-_state = _HWMOD_STATE_IDLE;
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 1881fe9..b7ac0f4 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -25,8 +25,12 @@
#include clockdomain.h
#include pm.h
#include twl-common.h
+#include prm2xxx_3xxx.h
+#include prm44xx.h
static struct omap_device_pm_latency *pm_lats;
+static void (*io_chain_trigger_func) (void);
+static DEFINE_SPINLOCK(io_chain_lock);
static int _init_omap_device(char *name)
{
@@ -64,6 +68,17 @@ static void omap2_init_processor_devices(void)
}
}
+void omap_trigger_io_chain(void)
+{
+ unsigned long flags;
+
+ if (io_chain_trigger_func) {
+ spin_lock_irqsave(io_chain_lock, flags);
+ io_chain_trigger_func();
+ spin_unlock_irqrestore(io_chain_lock, flags);
+ }
+}
+
/* Types of sleep_switch used in omap_set_pwrdm_state */
#define FORCEWAKEUP_SWITCH 0
#define LOWPOWERSTATE_SWITCH 1
@@ -221,6 +236,12 @@ static int __init omap2_common_pm_init(void)
omap2_init_processor_devices();
omap_pm_if_init();
+ if (cpu_is_omap34xx() omap3_has_io_chain_ctrl())
+ io_chain_trigger_func = omap3_trigger_io_chain;
+
+ if (cpu_is_omap44xx())
+ io_chain_trigger_func = omap4_trigger_io_chain;
+
return 0;
}
postcore_initcall(omap2_common_pm_init);
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index b737b11..f9dac40 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -22,6 +22,7 @@ extern int omap3_can_sleep(void);
extern int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
extern int omap3_idle_init(void);
extern int omap4_idle_init(void);
+extern void omap_trigger_io_chain(void);
#if defined(CONFIG_PM_OPP)
extern int omap3_opp_init(void);
--
1.7.4.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] omap2+: add drm device
On Tue, Mar 6, 2012 at 8:35 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Tue, 2012-03-06 at 08:01 -0600, Rob Clark wrote:
On Tue, Mar 6, 2012 at 7:26 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
Can there be more than one omapdrm device? I guess not. If so, the id
should be -1.
in the past, we have used multiple devices (using the platform-data to
divide up the dss resources), although this was sort of a
special-case. But in theory you could have multiple. (Think of a
multi-seat scenario, where multiple compositors need to run and each
need to be drm-master of their own device to do mode-setting on their
corresponding display.)
I think if we use .id = -1, then we'd end up with a funny looking
bus-id for the device: platform:omapdrm:-1
I don't know about that, but it's the way platform devices are meant to
be used if there can be only one instance. If the case where there are
multiple omapdrm devices is rather theoretical, or only used for certain
debugging scenarios or such, I think having the id as -1 in the mainline
is cleaner.
well, I don't care much one way or another, but need to check if there
is a small patch needed in drm core code that generates the bus-id for
.id = -1..
+};
+
+static int __init omap_init_gpu(void)
+{
+ struct omap_hwmod *oh = NULL;
+ struct platform_device *pdev;
+
+ /* lookup and populate the DMM information, if present - OMAP4+ */
+ oh = omap_hwmod_lookup(dmm);
+
+ if (oh) {
+ pdev = omap_device_build(oh-name, -1, oh, NULL, 0, NULL, 0,
+ false);
+ WARN(IS_ERR(pdev), Could not build omap_device for %s\n,
+ oh-name);
+ }
+
+ return platform_device_register(omap_drm_device);
+
+}
The function is called omap_init_gpu(), but it doesn't do anything
related to the gpu... And aren't DMM and DRM totally separate things,
why are they bunched together like that?
only legacy.. product branches also have sgx initialization here. But
I can change that to omap_init_drm()
DMM is managed by the drm driver (and exposed to userspace as drm/gem
buffers, shared with other devices via dma-buf, etc). It is only
split out to a separate device to play along with hwmod.
I have to say I don't know much about DMM, but my understanding is that
DMM is a bigger entity, of which TILER is only a small part, and DMM
manages all memory accesses.
when most people refer to TILER they actually refer to DMM..
DMM is the piece which is basically a GART, it is what omapdrm is
programming and managing.
Can there be other users for the DMM than DRM? I know there could be
other users for the TILER, and I know you want to combine that with the
DRM driver, but I'm wondering about the other parts of DMM than the
TILER.
yes, clearly there are other users.. we pass gem buffers allocated
from omapdrm to (for example, video decoder). But it is omapdrm which
is managing the allocation, keeping track of which buffers are pinned
and which can be evicted, dealing with the complications of userspace
mmap'ing of tiled buffers, etc. That stuff you don't want littered
throughout the kernel.
Somehow having a DMM driver inside omapdrm sounds strange.
+arch_initcall(omap_init_gpu);
+
+void omapdrm_reserve_vram(void)
+{
+#ifdef CONFIG_CMA
+ /*
+ * Create private 32MiB contiguous memory area for omapdrm.0 device
+ * TODO revisit size.. if uc/wc buffers are allocated from CMA pages
+ * then the amount of memory we need goes up..
+ */
+ dma_declare_contiguous(omap_drm_device.dev, 32 * SZ_1M, 0, 0);
What does this actually do? Does it reserve the memory, i.e. it's not
usable for others? If so, shouldn't there be a way for the user to
configure it?
It can be re-used by others.. see http://lwn.net/Articles/479297/
The link didn't tell much. I looked at the patches, and
dma_declare_contiguous allocates the memory with memblock_alloc. So is
that allocated memory available for any users? If so, why does the
function want a device pointer as an argument...
Is the memory available for normal kmalloc, or only available via the
CMA functions? Surely there must be some downside to the above? =) And
if so, it should be configurable. You could have a board with no display
at all, and you probably don't want to have 32MB allocated for DRM in
that case.
Basically the short version is memory from a CMA carveout can be
re-used for unpinnable memory. Not kmalloc, but it can be used for
anon userspace pages, for example. Userspace needs memory too.
BR,
-R
Tomi
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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
Re: OMAP totally fucked?
On 03/03/2012 08:04 PM, Tony Lindgren wrote: Then looks like there's a mismerge with ASoC. And ASoC patch [PATCH v3 2/3] MFD: twl6040: Convert to i2c driver, and separate it from twl core that produces another build error. Looks like we also have a new section warning with ASoC changes: WARNING: arch/arm/mach-omap2/built-in.o(.text+0x14504): Section mismatch in reference from the function omap4_pmic_init() to th The function omap4_pmic_init() references the (unknown reference) __initdata (unknown). This is often because omap4_pmic_init lacks a __initdata annotation or the annotation of (unknown) is wrong. Peter, care to look if below is right resolve for the mismerge? Also can you please also fix the new section warning? I have sent a revert series (you were on the CC) to Samuel regarding to this series going via the MFD tree. I have the corrected series waiting for the event Samuel applies the reverts on his for-next branch, so we can queue the fixed patches via ASoC. -- Péter -- 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: OMAP totally fucked?
On Tuesday 06 March 2012, Russell King - ARM Linux wrote: On Tue, Mar 06, 2012 at 03:58:34PM +0100, Cousson, Benoit wrote: We added that to avoid cluttering the drivers with a bunch of #ifdef CONFIG_OF as proposed by Grant and Rob... and most drivers adaptation were done having that assumption. So if we removed that today, it will be like removing the IRQDOMAIN define during the last merge window, it will break when the drivers DT adaptation will be pulled. But aren't the OF interfaces stubbed out in linux/of.h when DT support is disabled? Or are you saying that we're heading for a situation where existing drivers stop working when OF isn't enabled? Most of the interfaces are stubbed out, but not all. I guess it would be nice to add stubs for the remaining ones, too. More consistent as well. Arnd -- 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: [PATCHv5 2/6] ARM: OMAP3 PM: Move IO Daisychain function to omap3 prm file
On 17:11-20120306, Tero Kristo wrote:
From: Vishwanath BS vishwanath...@ti.com
Since IO Daisychain modifies only PRM registers, it makes sense to move
it to PRM File. Also changed the timeout value for IO chain enable to
100us and added a wait for status disable at the end.
[...]
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.c
b/arch/arm/mach-omap2/prm2xxx_3xxx.c
index 9ce7654..2f45b96 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.c
@@ -301,6 +301,43 @@ void omap3xxx_prm_restore_irqen(u32 *saved_mask)
OMAP3_PRM_IRQENABLE_MPU_OFFSET);
}
+/*
+ * Maximum time(us) it takes to output the signal WUCLKOUT of the last pad of
+ * the I/O ring after asserting WUCLKIN high
+ */
+#define MAX_IOPAD_LATCH_TIME 100
+
+/* OMAP3 Daisychain enable sequence */
+void omap3_trigger_io_chain(void)
+{
+ int i = 0;
+
+ omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
+PM_WKEN);
+ /* Do a readback to assure write has been done */
+ omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN);
+
+ omap_test_timeout(omap2_prm_read_mod_reg(WKUP_MOD, PM_WKST)
+ OMAP3430_ST_IO_CHAIN_MASK,
+ MAX_IOPAD_LATCH_TIME, i);
probably a nitpick, but would'nt you like to keep the OMAP3 and OMAP4
style consistent?
+
+ omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
+ PM_WKEN);
+
+ omap2_prm_set_mod_reg_bits(OMAP3430_ST_IO_CHAIN_MASK, WKUP_MOD,
+ PM_WKST);
+
+ omap2_prm_read_mod_reg(WKUP_MOD, PM_WKST);
in the previous iteration it had:
omap_test_timeout(((omap2_prm_read_mod_reg(WKUP_MOD, PM_WKST)
OMAP3430_ST_IO_CHAIN_MASK) == 0),
MAX_IOPAD_LATCH_TIME,
i);
gone now?
--
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: [PATCHv5 2/6] ARM: OMAP3 PM: Move IO Daisychain function to omap3 prm file
On Tue, 2012-03-06 at 09:57 -0600, Nishanth Menon wrote:
On 17:11-20120306, Tero Kristo wrote:
From: Vishwanath BS vishwanath...@ti.com
Since IO Daisychain modifies only PRM registers, it makes sense to move
it to PRM File. Also changed the timeout value for IO chain enable to
100us and added a wait for status disable at the end.
[...]
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.c
b/arch/arm/mach-omap2/prm2xxx_3xxx.c
index 9ce7654..2f45b96 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.c
@@ -301,6 +301,43 @@ void omap3xxx_prm_restore_irqen(u32 *saved_mask)
OMAP3_PRM_IRQENABLE_MPU_OFFSET);
}
+/*
+ * Maximum time(us) it takes to output the signal WUCLKOUT of the last pad
of
+ * the I/O ring after asserting WUCLKIN high
+ */
+#define MAX_IOPAD_LATCH_TIME 100
+
+/* OMAP3 Daisychain enable sequence */
+void omap3_trigger_io_chain(void)
+{
+ int i = 0;
+
+ omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
+ PM_WKEN);
+ /* Do a readback to assure write has been done */
+ omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN);
+
+ omap_test_timeout(omap2_prm_read_mod_reg(WKUP_MOD, PM_WKST)
+ OMAP3430_ST_IO_CHAIN_MASK,
+ MAX_IOPAD_LATCH_TIME, i);
probably a nitpick, but would'nt you like to keep the OMAP3 and OMAP4
style consistent?
+
+ omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
+PM_WKEN);
+
+ omap2_prm_set_mod_reg_bits(OMAP3430_ST_IO_CHAIN_MASK, WKUP_MOD,
+PM_WKST);
+
+ omap2_prm_read_mod_reg(WKUP_MOD, PM_WKST);
in the previous iteration it had:
omap_test_timeout(((omap2_prm_read_mod_reg(WKUP_MOD, PM_WKST)
OMAP3430_ST_IO_CHAIN_MASK) == 0),
MAX_IOPAD_LATCH_TIME,
i);
gone now?
Yea, according to TRM this is not what should be done on omap3,
apparently one of the comments I received was in error for one of the
previous versions. Also, the implementation in patch 1 is closer to what
is here now.
-Tero
--
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: Latest OMAP4 build errors
On Tue, Feb 28, 2012 at 12:11:37PM +0200, Ohad Ben-Cohen wrote: On Tue, Feb 28, 2012 at 12:01 PM, Arnd Bergmann a...@arndb.de wrote: I think 'depends' would be better here, because selecting IOMMU_SUPPORT has other side-effects that a user might not want. It's just as likely that someone wants to disable IOMMU_SUPPORT and needs to find OMAP_REMOTEPROC as wanting to enable OMAP_REMOTEPROC and having to find IOMMU_SUPPORT. In most cases, the defconfig should just set both. Ok, 'depends on' it is. We're a week on, which means I now have a full set of 7 builds on the website for OMAP4430 all of which have failed in part due to this as yet unresolved problem. What's happening to get it fixed and those fixes into whatever tree is necessary for them (presumably arm-soc)? -- 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: Latest OMAP4 build errors
On Tuesday 06 March 2012, Russell King - ARM Linux wrote: On Tue, Feb 28, 2012 at 12:11:37PM +0200, Ohad Ben-Cohen wrote: On Tue, Feb 28, 2012 at 12:01 PM, Arnd Bergmann a...@arndb.de wrote: I think 'depends' would be better here, because selecting IOMMU_SUPPORT has other side-effects that a user might not want. It's just as likely that someone wants to disable IOMMU_SUPPORT and needs to find OMAP_REMOTEPROC as wanting to enable OMAP_REMOTEPROC and having to find IOMMU_SUPPORT. In most cases, the defconfig should just set both. Ok, 'depends on' it is. We're a week on, which means I now have a full set of 7 builds on the website for OMAP4430 all of which have failed in part due to this as yet unresolved problem. What's happening to get it fixed and those fixes into whatever tree is necessary for them (presumably arm-soc)? Ohad has sent a series of patches for review and there were no comments on those. The fix was part of it as far as I remember. I'm still waiting for a pull request from Ohad. Arnd -- 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: Latest OMAP4 build errors
On Tue, Mar 6, 2012 at 7:01 PM, Arnd Bergmann a...@arndb.de wrote: Ohad has sent a series of patches for review and there were no comments on those. The fix was part of it as far as I remember. I'm still waiting for a pull request from Ohad. Yes, sorry for not sending the pull yet. I should have sent this fix asap, and only wait for comments on the rest of the patches. Will send the pull request today. Thanks, Ohad. -- 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] MFD: Reverting twl6040 patches going for 3.4
Hi Peter, On Tue, Mar 06, 2012 at 02:35:11PM +0200, Peter Ujfalusi wrote: Hello Samuel, this series reverts the twl6040 related patches aimed for 3.4 merge window from MFD for-next branch. As we already discussed the relevant patches will be going through audio since we have some dependencies going via that route. I removed all 5 patches from my for-next branch. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- 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
[GIT PULL] fixing and cleaning up rpmsg/remoteproc for 3.4
Hi Arnd,
Please pull:
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git
rpmsg-fixes-and-more-for-3.4
To get a few rpmsg/remoteproc fixes, cleanups and some generalization
work for 3.4.
Again, I should have sent the Kconfig patch earlier in a separate pull
request. Sorry about that.
Thanks!
Ohad.
The following changes since commit e12bc14b88d44e5c1456dccb59ff58103f6c6edc:
remoteproc: s/big switch/lookup table/ (2012-02-22 18:28:49 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git
rpmsg-fixes-and-more-for-3.4
for you to fetch changes up to 1e3e2c7c46b2e6e90f3a26ba9be6326c00ca31e4:
remoteproc: cleanup resource table parsing paths (2012-03-06 19:14:44 +0200)
Fixing and cleaning up several remoteproc and rpmsg issues.
In addition, remoteproc's resource table is converted to a collection
of type-value members, instead of a rigid array of homogeneous structs.
This enables remoteproc to support registration of generic virtio devices,
and not only a single VIRTIO_ID_RPMSG virtio device.
But perhaps more importantly, the resource table overhaul makes it possible
to easily extend it in the future without breaking older images (simply by
defining a new member type, while continuing to support older types).
Mark Asselstine (1):
rpmsg: fix build warning when dma_addr_t is 64-bit
Ohad Ben-Cohen (12):
remoteproc: make sure we're parsing a 32bit firmware
remoteproc/omap: two Kconfig fixes
rpmsg: fix name service endpoint leak
rpmsg: validate incoming message length before propagating
rpmsg: fix published buffer length in rpmsg_recv_done
remoteproc: resource table overhaul
remoteproc: remoteproc_rpmsg - remoteproc_virtio
remoteproc: safer boot/shutdown order
remoteproc: remove the single rpmsg vdev limitation
remoteproc/omap: remove the mbox_callback limitation
remoteproc: remove the hardcoded vring alignment
remoteproc: cleanup resource table parsing paths
Documentation/remoteproc.txt | 136 +++---
drivers/remoteproc/Kconfig |3 +-
drivers/remoteproc/Makefile|2 +-
drivers/remoteproc/omap_remoteproc.c | 11 +-
drivers/remoteproc/remoteproc_core.c | 532
drivers/remoteproc/remoteproc_internal.h |6 +-
.../{remoteproc_rpmsg.c = remoteproc_virtio.c}| 162 +++
drivers/rpmsg/virtio_rpmsg_bus.c | 46 ++-
include/linux/remoteproc.h | 339 ++---
9 files changed, 793 insertions(+), 444 deletions(-)
rename drivers/remoteproc/{remoteproc_rpmsg.c = remoteproc_virtio.c} (65%)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP1: Fix section mismatch for omap1_init_early()
Fix the following warning:
WARNING: vmlinux.o(.text+0x1286c): Section mismatch in reference
from the function omap1_init_early() to the function .init.text:omap1_clk_init()
The function omap1_init_early() references
the function __init omap1_clk_init().
This is often because omap1_init_early lacks a __init
annotation or the annotation of omap1_clk_init is wrong.
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/arch/arm/mach-omap1/io.c
+++ b/arch/arm/mach-omap1/io.c
@@ -118,7 +118,7 @@ void __init omap16xx_map_io(void)
/*
* Common low-level hardware init for omap1.
*/
-void omap1_init_early(void)
+void __init omap1_init_early(void)
{
omap_check_revision();
--
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+: PM: VP: fix integer truncation error
From: Yuan Jiangli jly...@motorola.com commit 2f34ce81b8c05c900e45bd88595cc154f7bb5957 (OMAP3: PM: Adding voltage driver support.) introduced runtime computation of waittime to handle all potential sys clocks available. In the voltage processor, the SPMSUpdateWait is calculated based on the slew rate and the voltage step (SMPSUpdateWait = slew rate * Voltage Step). After the voltage processor receives the SMPS_Ack signal, the Voltage Controller will wait for SMPSUpdateWait clock cycles for the voltage to settle to the new value. For all practical purposes, the waittime parameter is the OMAP hardware translation of what the slew rate on the PMIC is. As an example, with TPS62361 on OMAP4460, step_size = 1 slew_rate = 32000 sys_clk_rate = 38400 Our current computation results in the following: = ((step_size / slew_rate) * sys_clk_rate) / 1000 = ((1 / 32000) * 38400 / 1000 = 0 Fix the same using DIV_ROUND_UP as an extra wait clock cycle is better than lesser clock cycle. For the above example, this translates to: = (1 * 38400) / (1000 * 32000) = 12 Change-Id: I0ee22e60555e1cfd6cc3dea7ee44d0584ce182b6 Acked-by: Jon Hunter jon-hun...@ti.com [n...@ti.com: slightly better implementation] Signed-off-by: Nishanth Menon n...@ti.com Signed-off-by: Yuan Jiangli jly...@motorola.com --- arch/arm/mach-omap2/vp.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c index 0df8882..f95c1ba 100644 --- a/arch/arm/mach-omap2/vp.c +++ b/arch/arm/mach-omap2/vp.c @@ -61,8 +61,8 @@ void __init omap_vp_init(struct voltagedomain *voltdm) vddmin = voltdm-pmic-vp_vddmin; vddmax = voltdm-pmic-vp_vddmax; - waittime = ((voltdm-pmic-step_size / voltdm-pmic-slew_rate) * - sys_clk_rate) / 1000; + waittime = DIV_ROUND_UP(voltdm-pmic-step_size * sys_clk_rate, + 1000 * voltdm-pmic-slew_rate); vstepmin = voltdm-pmic-vp_vstepmin; vstepmax = voltdm-pmic-vp_vstepmax; -- 1.7.5.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] OMAP3+: PM: VP: fix integer truncation error
On Tue, Mar 6, 2012 at 7:32 PM, Nishanth Menon n...@ti.com wrote: From: Yuan Jiangli jly...@motorola.com commit 2f34ce81b8c05c900e45bd88595cc154f7bb5957 (OMAP3: PM: Adding voltage driver support.) introduced runtime computation of waittime to handle all potential sys clocks available. In the voltage processor, the SPMSUpdateWait is calculated based on the slew rate and the voltage step (SMPSUpdateWait = slew rate * Voltage Step). After the voltage processor receives the SMPS_Ack signal, the Voltage Controller will wait for SMPSUpdateWait clock cycles for the voltage to settle to the new value. For all practical purposes, the waittime parameter is the OMAP hardware translation of what the slew rate on the PMIC is. As an example, with TPS62361 on OMAP4460, step_size = 1 slew_rate = 32000 sys_clk_rate = 38400 Our current computation results in the following: = ((step_size / slew_rate) * sys_clk_rate) / 1000 = ((1 / 32000) * 38400 / 1000 = 0 Fix the same using DIV_ROUND_UP as an extra wait clock cycle is better than lesser clock cycle. For the above example, this translates to: = (1 * 38400) / (1000 * 32000) = 12 Change-Id: I0ee22e60555e1cfd6cc3dea7ee44d0584ce182b6 You don't need above gerrit change id in commit message. Regardas Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3+: PM: VP: fix integer truncation error
On Tue, Mar 6, 2012 at 12:36, Shilimkar, Santosh santosh.shilim...@ti.com wrote: Change-Id: I0ee22e60555e1cfd6cc3dea7ee44d0584ce182b6 You don't need above gerrit change id in commit message. yow.. thanks for catching it, my bad.. thought i fixed it.. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2] OMAP3+: PM: VP: fix integer truncation error
From: Yuan Jiangli jly...@motorola.com commit 2f34ce81b8c05c900e45bd88595cc154f7bb5957 (OMAP3: PM: Adding voltage driver support.) introduced runtime computation of waittime to handle all potential sys clocks available. In the voltage processor, the SPMSUpdateWait is calculated based on the slew rate and the voltage step (SMPSUpdateWait = slew rate * Voltage Step). After the voltage processor receives the SMPS_Ack signal, the Voltage Controller will wait for SMPSUpdateWait clock cycles for the voltage to settle to the new value. For all practical purposes, the waittime parameter is the OMAP hardware translation of what the slew rate on the PMIC is. As an example, with TPS62361 on OMAP4460, step_size = 1 slew_rate = 32000 sys_clk_rate = 38400 Our current computation results in the following: = ((step_size / slew_rate) * sys_clk_rate) / 1000 = ((1 / 32000) * 38400 / 1000 = 0 Fix the same using DIV_ROUND_UP as an extra wait clock cycle is better than lesser clock cycle. For the above example, this translates to: = (1 * 38400) / (1000 * 32000) = 12 Acked-by: Jon Hunter jon-hun...@ti.com [n...@ti.com: slightly better implementation] Signed-off-by: Nishanth Menon n...@ti.com Signed-off-by: Yuan Jiangli jly...@motorola.com --- arch/arm/mach-omap2/vp.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c index 0df8882..f95c1ba 100644 --- a/arch/arm/mach-omap2/vp.c +++ b/arch/arm/mach-omap2/vp.c @@ -61,8 +61,8 @@ void __init omap_vp_init(struct voltagedomain *voltdm) vddmin = voltdm-pmic-vp_vddmin; vddmax = voltdm-pmic-vp_vddmax; - waittime = ((voltdm-pmic-step_size / voltdm-pmic-slew_rate) * - sys_clk_rate) / 1000; + waittime = DIV_ROUND_UP(voltdm-pmic-step_size * sys_clk_rate, + 1000 * voltdm-pmic-slew_rate); vstepmin = voltdm-pmic-vp_vstepmin; vstepmax = voltdm-pmic-vp_vstepmax; -- 1.7.5.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] ARM: OMAP2: Fix section warning for n8x0 when CONFIG_MMC_OMAP is not set
Otherwise we get:
arch/arm/mach-omap2/board-n8x0.c:39:12: warning:
'slot1_cover_open' defined but not used [-Wunused-variable]
arch/arm/mach-omap2/board-n8x0.c:40:12: warning:
'slot2_cover_open' defined but not used [-Wunused-variable]
arch/arm/mach-omap2/board-n8x0.c:41:23: warning:
'mmc_device' defined but not used [-Wunused-variable]
Reported-by: Russell King li...@arm.linux.org.uk
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -36,10 +36,6 @@
#include mux.h
-static int slot1_cover_open;
-static int slot2_cover_open;
-static struct device *mmc_device;
-
#define TUSB6010_ASYNC_CS 1
#define TUSB6010_SYNC_CS 4
#define TUSB6010_GPIO_INT 58
@@ -211,6 +207,10 @@ static struct omap_onenand_platform_data
board_onenand_data[] = {
#define N810_EMMC_VSD_GPIO 23
#define N810_EMMC_VIO_GPIO 9
+static int slot1_cover_open;
+static int slot2_cover_open;
+static struct device *mmc_device;
+
static int n8x0_mmc_switch_slot(struct device *dev, int slot)
{
#ifdef CONFIG_MMC_DEBUG
--
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: OMAP totally fucked?
Russell King - ARM Linux li...@arm.linux.org.uk writes:
On Sat, Mar 03, 2012 at 01:05:21PM -0800, Tony Lindgren wrote:
* Arnd Bergmann a...@arndb.de [120303 09:57]:
On Saturday 03 March 2012, Tony Lindgren wrote:
Well 85631d2 builds fine, looks like now some more includes of
plat/hardware.h are now needed.Have not yet tracked down which
commit triggers the build errors. Eventually those should become
local headers too..
I've tried building arm-soc/for-next and rmk/for-next, they are both
fine, just merging the two gives me the same build errors that Russell
saw.
Adding plat/hardware.h in all files that break solves the problems,
aside from the iommu dependency for rpmsg for which Ohad has provided
a fix already that I should pull.
Here's a patch for you to the cleanup branch to fix the hardware.h
build errors.
Right, with this applied, things are better:
1. omap3430ldp allnoconfig is the first build without warnings, congrats.
2. omap4430sdp allnoconfig has a bunch of new section mismatch warnings,
a couple of compiler warnings, and builds:
WARNING: arch/arm/mach-omap2/built-in.o(.text+0x183c): Section mismatch in
reference from the function omap2_init_processor_devices() to the function
.init.text:_init_omap_device()
The function omap2_init_processor_devices() references
the function __init _init_omap_device().
This is often because omap2_init_processor_devices lacks a __init
annotation or the annotation of _init_omap_device is wrong.
Below is a fix for this one.
My compiler (gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3)) was
inlining these so I wasn't seeing this warning. I had to make
omap2_init_processor_devices() static to make the warning appear.
Anyways, fix is trivial, patch below.
Kevin
From d8d4a0917c731a5fd846cd846296e2b8a5f2348d Mon Sep 17 00:00:00 2001
From: Kevin Hilman khil...@ti.com
Date: Tue, 6 Mar 2012 11:38:01 -0800
Subject: [PATCH] ARM: OMAP2+: PM: fix section mismatch with
omap2_init_processor_devices()
Fix the below warning by making omap2_init_processor_devices() __init.
It is called by an __init function and calls only __init functions, so
it should also be init.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0x183c): Section mismatch in
reference from the function omap2_init_processor_devices() to the function
.init.text:_init_omap_device()
The function omap2_init_processor_devices() references
the function __init _init_omap_device().
This is often because omap2_init_processor_devices lacks a __init
annotation or the annotation of _init_omap_device is wrong.
Reported-by: Russell King rmk+ker...@arm.linux.org.uk
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/pm.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 1881fe9..d00c39e 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -49,7 +49,7 @@ static int _init_omap_device(char *name)
/*
* Build omap_devices for processors and bus.
*/
-static void omap2_init_processor_devices(void)
+static void __init omap2_init_processor_devices(void)
{
_init_omap_device(mpu);
if (omap3_has_iva())
--
1.7.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP2+: Fix omap24xx_io_desc warning if SoC subtypes are not selected
Otherwise we get the following warning:
arch/arm/mach-omap2/io.c:53:24: warning:
'omap24xx_io_desc' defined but not used [-Wunused-variable]
Reported-by: Russell King li...@arm.linux.org.uk
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -49,7 +49,7 @@
* default mapping provided here.
*/
-#ifdef CONFIG_ARCH_OMAP2
+#if defined(CONFIG_SOC_OMAP2420) || defined(CONFIG_SOC_OMAP2430)
static struct map_desc omap24xx_io_desc[] __initdata = {
{
.virtual= L3_24XX_VIRT,
--
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: OMAP totally fucked?
* Kevin Hilman khil...@ti.com [120306 11:13]: Russell King - ARM Linux li...@arm.linux.org.uk writes: WARNING: arch/arm/mach-omap2/built-in.o(.text+0x183c): Section mismatch in reference from the function omap2_init_processor_devices() to the function .init.text:_init_omap_device() The function omap2_init_processor_devices() references the function __init _init_omap_device(). This is often because omap2_init_processor_devices lacks a __init annotation or the annotation of _init_omap_device is wrong. Below is a fix for this one. My compiler (gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3)) was inlining these so I wasn't seeing this warning. I had to make omap2_init_processor_devices() static to make the warning appear. Anyways, fix is trivial, patch below. Thanks, I'll add that to fixes-non-critical-part2. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP totally fucked?
* Peter Ujfalusi peter.ujfal...@ti.com [120306 06:57]: On 03/03/2012 08:04 PM, Tony Lindgren wrote: Then looks like there's a mismerge with ASoC. And ASoC patch [PATCH v3 2/3] MFD: twl6040: Convert to i2c driver, and separate it from twl core that produces another build error. Looks like we also have a new section warning with ASoC changes: WARNING: arch/arm/mach-omap2/built-in.o(.text+0x14504): Section mismatch in reference from the function omap4_pmic_init() to th The function omap4_pmic_init() references the (unknown reference) __initdata (unknown). This is often because omap4_pmic_init lacks a __initdata annotation or the annotation of (unknown) is wrong. Peter, care to look if below is right resolve for the mismerge? Also can you please also fix the new section warning? I have sent a revert series (you were on the CC) to Samuel regarding to this series going via the MFD tree. I have the corrected series waiting for the event Samuel applies the reverts on his for-next branch, so we can queue the fixed patches via ASoC. OK thanks! Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP totally fucked?
Russell King - ARM Linux li...@arm.linux.org.uk writes:
On Sat, Mar 03, 2012 at 01:05:21PM -0800, Tony Lindgren wrote:
* Arnd Bergmann a...@arndb.de [120303 09:57]:
On Saturday 03 March 2012, Tony Lindgren wrote:
Well 85631d2 builds fine, looks like now some more includes of
plat/hardware.h are now needed.Have not yet tracked down which
commit triggers the build errors. Eventually those should become
local headers too..
I've tried building arm-soc/for-next and rmk/for-next, they are both
fine, just merging the two gives me the same build errors that Russell
saw.
Adding plat/hardware.h in all files that break solves the problems,
aside from the iommu dependency for rpmsg for which Ohad has provided
a fix already that I should pull.
Here's a patch for you to the cleanup branch to fix the hardware.h
build errors.
Right, with this applied, things are better:
1. omap3430ldp allnoconfig is the first build without warnings, congrats.
2. omap4430sdp allnoconfig has a bunch of new section mismatch warnings,
a couple of compiler warnings, and builds:
WARNING: arch/arm/mach-omap2/built-in.o(.text+0x183c): Section mismatch in
reference from the function omap2_init_processor_devices() to the function
.init.text:_init_omap_device()
The function omap2_init_processor_devices() references
the function __init _init_omap_device().
This is often because omap2_init_processor_devices lacks a __init
annotation or the annotation of _init_omap_device is wrong.
arch/arm/mach-omap2/io.c:51: warning: 'omap24xx_io_desc' defined but not used
arch/arm/mach-omap2/omap-wakeupgen.c:181: warning: 'wakeupgen_irqmask_all'
defined but not used
And here's a fix for the wakeupgen one.
Kevin
From 9f6b1ac3b6012fdb2001dbec14ac3d72d81b50d8 Mon Sep 17 00:00:00 2001
From: Kevin Hilman khil...@ti.com
Date: Tue, 6 Mar 2012 12:00:25 -0800
Subject: [PATCH] ARM: OMAP2+: PM: fix wakeupgen warning when hotplug disabled
When CONFIG_HOTPLUG_CPU=n, there are unused functions in wakeupgen:
arch/arm/mach-omap2/omap-wakeupgen.c:181: warning: 'wakeupgen_irqmask_all'
defined but not used
Fix this by moving all the functions only used when CONFIG_HOTPLUG_CPU=y
together and wrapping in an #ifdef.
No functional changes.
Reported-by: Russell King rmk+ker...@arm.linux.org.uk
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/omap-wakeupgen.c | 53 ++
1 file changed, 28 insertions(+), 25 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c
b/arch/arm/mach-omap2/omap-wakeupgen.c
index d3d8971..42cd7fb 100644
--- a/arch/arm/mach-omap2/omap-wakeupgen.c
+++ b/arch/arm/mach-omap2/omap-wakeupgen.c
@@ -43,7 +43,6 @@
static void __iomem *wakeupgen_base;
static void __iomem *sar_base;
-static DEFINE_PER_CPU(u32 [NR_REG_BANKS], irqmasks);
static DEFINE_SPINLOCK(wakeupgen_lock);
static unsigned int irq_target_cpu[NR_IRQS];
@@ -67,14 +66,6 @@ static inline void sar_writel(u32 val, u32 offset, u8 idx)
__raw_writel(val, sar_base + offset + (idx * 4));
}
-static void _wakeupgen_set_all(unsigned int cpu, unsigned int reg)
-{
- u8 i;
-
- for (i = 0; i NR_REG_BANKS; i++)
- wakeupgen_writel(reg, i, cpu);
-}
-
static inline int _wakeupgen_get_irq_info(u32 irq, u32 *bit_posn, u8
*reg_index)
{
unsigned int spi_irq;
@@ -130,22 +121,6 @@ static void _wakeupgen_set(unsigned int irq, unsigned int
cpu)
wakeupgen_writel(val, i, cpu);
}
-static void _wakeupgen_save_masks(unsigned int cpu)
-{
- u8 i;
-
- for (i = 0; i NR_REG_BANKS; i++)
- per_cpu(irqmasks, cpu)[i] = wakeupgen_readl(i, cpu);
-}
-
-static void _wakeupgen_restore_masks(unsigned int cpu)
-{
- u8 i;
-
- for (i = 0; i NR_REG_BANKS; i++)
- wakeupgen_writel(per_cpu(irqmasks, cpu)[i], i, cpu);
-}
-
/*
* Architecture specific Mask extension
*/
@@ -170,6 +145,33 @@ static void wakeupgen_unmask(struct irq_data *d)
spin_unlock_irqrestore(wakeupgen_lock, flags);
}
+#ifdef CONFIG_HOTPLUG_CPU
+static DEFINE_PER_CPU(u32 [NR_REG_BANKS], irqmasks);
+
+static void _wakeupgen_save_masks(unsigned int cpu)
+{
+ u8 i;
+
+ for (i = 0; i NR_REG_BANKS; i++)
+ per_cpu(irqmasks, cpu)[i] = wakeupgen_readl(i, cpu);
+}
+
+static void _wakeupgen_restore_masks(unsigned int cpu)
+{
+ u8 i;
+
+ for (i = 0; i NR_REG_BANKS; i++)
+ wakeupgen_writel(per_cpu(irqmasks, cpu)[i], i, cpu);
+}
+
+static void _wakeupgen_set_all(unsigned int cpu, unsigned int reg)
+{
+ u8 i;
+
+ for (i = 0; i NR_REG_BANKS; i++)
+ wakeupgen_writel(reg, i, cpu);
+}
+
/*
* Mask or unmask all interrupts on given CPU.
* 0 = Mask all interrupts on the 'cpu'
@@ -191,6 +193,7 @@ static void wakeupgen_irqmask_all(unsigned int cpu,
unsigned int set)
}
spin_unlock_irqrestore(wakeupgen_lock, flags);
}
+#endif
#ifdef CONFIG_CPU_PM
Re: OMAP totally fucked?
* Kevin Hilman khil...@ti.com [120306 11:43]: Russell King - ARM Linux li...@arm.linux.org.uk writes: arch/arm/mach-omap2/io.c:51: warning: 'omap24xx_io_desc' defined but not used arch/arm/mach-omap2/omap-wakeupgen.c:181: warning: 'wakeupgen_irqmask_all' defined but not used And here's a fix for the wakeupgen one. Thanks, applying into fixes-non-critical-part2. Also posted a fix for the omap24xx_io_desc warning. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] gpio/omap: Fix section warning for omap_mpuio_alloc_gc()
From: Tony Lindgren t...@atomide.com
Date: Mon, 5 Mar 2012 15:32:38 -0800
Subject: [PATCH] gpio/omap: Fix section warning for omap_mpuio_alloc_gc()
Make omap_mpuio_alloc_gc() __devinit as omap_gpio_chip_init()
is __devinit. Otherwise we get:
WARNING: vmlinux.o(.devinit.text+0xa10): Section mismatch in reference
from the function omap_gpio_chip_init() to the function
.init.text:omap_mpuio_alloc_gc()
The function __devinit omap_gpio_chip_init() references
a function __init omap_mpuio_alloc_gc().
If omap_mpuio_alloc_gc is only used by omap_gpio_chip_init then
annotate omap_mpuio_alloc_gc with a matching annotation.
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1081,7 +1081,7 @@ static void omap_gpio_mod_init(struct gpio_bank *bank,
int id)
}
}
-static __init void
+static __devinit void
omap_mpuio_alloc_gc(struct gpio_bank *bank, unsigned int irq_start,
unsigned int num)
{
--
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: OMAP: WiLink platform data for the PandaBoard
Hi,
* Mircea Gherzan mgher...@gmail.com [120305 16:15]:
The uim deamon requires sysfs entries that are filled in using
this platform data.
Signed-off-by: Mircea Gherzan mgher...@gmail.com
---
arch/arm/mach-omap2/board-omap4panda.c | 23 +--
include/linux/ti_wilink_st.h |2 ++
2 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index b1d74d6..37b437f 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -27,6 +27,7 @@
#include linux/i2c/twl.h
#include linux/regulator/machine.h
#include linux/regulator/fixed.h
+#include linux/ti_wilink_st.h
#include linux/wl12xx.h
#include mach/hardware.h
@@ -56,15 +57,29 @@
#define HDMI_GPIO_HPD 63 /* Hotplug detect */
/* wl127x BT, FM, GPS connectivity chip */
-static int wl1271_gpios[] = {46, -1, -1};
+static struct ti_st_plat_data wilink_platform_data = {
+.nshutdown_gpio = 46,
+.dev_name= /dev/ttyO1,
+.flow_cntrl = 1,
+.baud_rate = 300,
+ .chip_enable= NULL,
+.suspend = NULL,
+.resume = NULL,
+};
+
Please use tabs above before .xxx instead of spaces.
+static struct platform_device btwilink_device = {
+ .name = btwilink,
+ .id = -1,
+};
+
static struct gpio_led gpio_leds[] = {
{
.name = pandaboard::status1,
@@ -91,10 +106,6 @@ static struct platform_device leds_gpio = {
},
};
-static struct platform_device btwilink_device = {
- .name = btwilink,
- .id = -1,
-};
This change is probably not needed, right?
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap3_beagle: init uart2 for beagle rev AX/BX only
* Govindraj.R govindraj.r...@ti.com [120306 00:34]:
From: Govindraj.R govindraj.r...@ti.com
All beagle boards rev AX/BX have external usb hubs connected to ehci
interface, external hub/peripheral uses a nreset sequence for which
uart2_rx.gpio_147 pin in mux mode4(USB2HS_nRST) is used on all beagle
boards expect rev Ax/BX.
(Reference to all beagle boards rev schematics:
http://beagleboard.org/hardware/design)
Initialising uart2 will lead to serial init taking over uart2_rx pin
so init uart2_rx pin mux only for Beagle AX/BX rev boards.
Dont init uart2 for all other boards allowing usb_ehci functionality.
To initialise individual uart port by id utilise and modify the existing
available func. omap_serial_board_init.
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@ti.com
Cc: Koen Kooi k...@dominion.thruhere.net
Tested-by: Peter Ujfalusi peter.ujfal...@ti.com
Tested-by: Robert Nelson robertcnel...@gmail.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
Can somebody please test this on non-xm beagle too and
reply with a Tested-by?
Thanks,
Tony
---
arch/arm/mach-omap2/board-omap3beagle.c |6 +++-
arch/arm/mach-omap2/serial.c | 41 -
arch/arm/plat-omap/include/plat/serial.h |3 +-
3 files changed, 30 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 7ffcd28..19d6fb5 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -126,6 +126,7 @@ static void __init omap3_beagle_init_rev(void)
beagle_config.mmc1_gpio_wp = 29;
beagle_config.reset_gpio = 170;
beagle_config.usr_button_gpio = 7;
+ omap_serial_board_init(NULL, 1);
break;
case 6:
printk(KERN_INFO OMAP3 Beagle Rev: C1/C2/C3\n);
@@ -528,7 +529,10 @@ static void __init omap3_beagle_init(void)
platform_add_devices(omap3_beagle_devices,
ARRAY_SIZE(omap3_beagle_devices));
omap_display_init(beagle_dss_data);
- omap_serial_init();
+ omap_serial_board_init(NULL, 0);
+ omap_serial_board_init(NULL, 2);
+ omap_serial_board_init(NULL, 3);
+
omap_sdrc_init(mt46h32m32lf6_sdrc_params,
mt46h32m32lf6_sdrc_params);
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index f590afc..e7c0462 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -393,30 +393,32 @@ void __init omap_serial_init_port(struct
omap_board_data *bdata,
/**
* omap_serial_board_init() - initialize all supported serial ports
* @info: platform specific data pointer
+ * @port_id: uart port number to be initialised
*
- * Initializes all available UARTs as serial ports. Platforms
+ * Initializes individual UARTs as serial ports. Platforms
* can call this function when they want to have default behaviour
- * for serial ports (e.g initialize them all as serial ports).
+ * for serial ports (e.g initialize individual serial ports based on port
id).
*/
-void __init omap_serial_board_init(struct omap_uart_port_info *info)
+void __init omap_serial_board_init(struct omap_uart_port_info *info, u8
port_id)
{
struct omap_uart_state *uart;
struct omap_board_data bdata;
- list_for_each_entry(uart, uart_list, node) {
- bdata.id = uart-num;
- bdata.flags = 0;
- bdata.pads = NULL;
- bdata.pads_cnt = 0;
-
- if (cpu_is_omap44xx() || cpu_is_omap34xx())
- omap_serial_fill_default_pads(bdata);
-
- if (!info)
- omap_serial_init_port(bdata, NULL);
- else
- omap_serial_init_port(bdata, info[uart-num]);
- }
+ list_for_each_entry(uart, uart_list, node)
+ if (uart-num == port_id) {
+ bdata.id = uart-num;
+ bdata.flags = 0;
+ bdata.pads = NULL;
+ bdata.pads_cnt = 0;
+
+ if (!cpu_is_omap24xx())
+ omap_serial_fill_default_pads(bdata);
+
+ if (!info)
+ omap_serial_init_port(bdata, NULL);
+ else
+ omap_serial_init_port(bdata, info);
+ }
}
/**
@@ -428,5 +430,8 @@ void __init omap_serial_board_init(struct
omap_uart_port_info *info)
*/
void __init omap_serial_init(void)
{
- omap_serial_board_init(NULL);
+ struct omap_uart_state *uart;
+
+ list_for_each_entry(uart, uart_list, node)
+ omap_serial_board_init(NULL, uart-num);
}
diff --git a/arch/arm/plat-omap/include/plat/serial.h
b/arch/arm/plat-omap/include/plat/serial.h
index 198d1e6..043b251
[PATCH v2] ARM: OMAP: WiLink platform data for the PandaBoard
The uim deamon requires sysfs entries that are filled in using
this platform data.
Signed-off-by: Mircea Gherzan mgher...@gmail.com
---
arch/arm/mach-omap2/board-omap4panda.c | 14 --
include/linux/ti_wilink_st.h |2 ++
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index b1d74d6..339e781 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -27,6 +27,7 @@
#include linux/i2c/twl.h
#include linux/regulator/machine.h
#include linux/regulator/fixed.h
+#include linux/ti_wilink_st.h
#include linux/wl12xx.h
#include mach/hardware.h
@@ -56,12 +57,21 @@
#define HDMI_GPIO_HPD 63 /* Hotplug detect */
/* wl127x BT, FM, GPS connectivity chip */
-static int wl1271_gpios[] = {46, -1, -1};
+static struct ti_st_plat_data wilink_platform_data = {
+ .nshutdown_gpio = 46,
+ .dev_name = /dev/ttyO1,
+ .flow_cntrl = 1,
+ .baud_rate = 300,
+ .chip_enable= NULL,
+ .suspend= NULL,
+ .resume = NULL,
+};
+
static struct platform_device wl1271_device = {
.name = kim,
.id = -1,
.dev= {
- .platform_data = wl1271_gpios,
+ .platform_data = wilink_platform_data,
},
};
diff --git a/include/linux/ti_wilink_st.h b/include/linux/ti_wilink_st.h
index 2ef4385..3ca0269 100644
--- a/include/linux/ti_wilink_st.h
+++ b/include/linux/ti_wilink_st.h
@@ -25,6 +25,8 @@
#ifndef TI_WILINK_ST_H
#define TI_WILINK_ST_H
+#include linux/skbuff.h
+
/**
* enum proto-type - The protocol on WiLink chips which share a
* common physical interface like UART.
--
1.7.9.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] gpio/omap: Fix section warning for omap_mpuio_alloc_gc()
Tony Lindgren t...@atomide.com writes:
From: Tony Lindgren t...@atomide.com
Date: Mon, 5 Mar 2012 15:32:38 -0800
Subject: [PATCH] gpio/omap: Fix section warning for omap_mpuio_alloc_gc()
Make omap_mpuio_alloc_gc() __devinit as omap_gpio_chip_init()
is __devinit. Otherwise we get:
WARNING: vmlinux.o(.devinit.text+0xa10): Section mismatch in reference
from the function omap_gpio_chip_init() to the function
.init.text:omap_mpuio_alloc_gc()
The function __devinit omap_gpio_chip_init() references
a function __init omap_mpuio_alloc_gc().
If omap_mpuio_alloc_gc is only used by omap_gpio_chip_init then
annotate omap_mpuio_alloc_gc with a matching annotation.
Signed-off-by: Tony Lindgren t...@atomide.com
Acked-by: Kevin Hilman khil...@ti.com
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1081,7 +1081,7 @@ static void omap_gpio_mod_init(struct gpio_bank *bank,
int id)
}
}
-static __init void
+static __devinit void
omap_mpuio_alloc_gc(struct gpio_bank *bank, unsigned int irq_start,
unsigned int num)
{
--
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 V2] OMAP3+: PM: VP: fix integer truncation error
Nishanth Menon n...@ti.com writes: From: Yuan Jiangli jly...@motorola.com commit 2f34ce81b8c05c900e45bd88595cc154f7bb5957 (OMAP3: PM: Adding voltage driver support.) introduced runtime computation of waittime to handle all potential sys clocks available. In the voltage processor, the SPMSUpdateWait is calculated based on the slew rate and the voltage step (SMPSUpdateWait = slew rate * Voltage Step). After the voltage processor receives the SMPS_Ack signal, the Voltage Controller will wait for SMPSUpdateWait clock cycles for the voltage to settle to the new value. For all practical purposes, the waittime parameter is the OMAP hardware translation of what the slew rate on the PMIC is. As an example, with TPS62361 on OMAP4460, step_size = 1 slew_rate = 32000 sys_clk_rate = 38400 Our current computation results in the following: = ((step_size / slew_rate) * sys_clk_rate) / 1000 = ((1 / 32000) * 38400 / 1000 = 0 Fix the same using DIV_ROUND_UP as an extra wait clock cycle is better than lesser clock cycle. For the above example, this translates to: = (1 * 38400) / (1000 * 32000) = 12 Acked-by: Jon Hunter jon-hun...@ti.com [n...@ti.com: slightly better implementation] Signed-off-by: Nishanth Menon n...@ti.com Signed-off-by: Yuan Jiangli jly...@motorola.com Acked-by: Kevin Hilman khil...@ti.com Tony, I don't have any more PM fixes for this cycle, so feel free to add this to fixes-non-critical-part2. This is an important fix, but since we're not doing active voltage scaling in mainline today, I don't think it's 3.3 material. Kevin --- arch/arm/mach-omap2/vp.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c index 0df8882..f95c1ba 100644 --- a/arch/arm/mach-omap2/vp.c +++ b/arch/arm/mach-omap2/vp.c @@ -61,8 +61,8 @@ void __init omap_vp_init(struct voltagedomain *voltdm) vddmin = voltdm-pmic-vp_vddmin; vddmax = voltdm-pmic-vp_vddmax; - waittime = ((voltdm-pmic-step_size / voltdm-pmic-slew_rate) * - sys_clk_rate) / 1000; + waittime = DIV_ROUND_UP(voltdm-pmic-step_size * sys_clk_rate, + 1000 * voltdm-pmic-slew_rate); vstepmin = voltdm-pmic-vp_vstepmin; vstepmax = voltdm-pmic-vp_vstepmax; -- 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] OMAP3+: PM: VP: fix integer truncation error
* Kevin Hilman khil...@ti.com [120306 15:33]: Nishanth Menon n...@ti.com writes: From: Yuan Jiangli jly...@motorola.com commit 2f34ce81b8c05c900e45bd88595cc154f7bb5957 (OMAP3: PM: Adding voltage driver support.) introduced runtime computation of waittime to handle all potential sys clocks available. In the voltage processor, the SPMSUpdateWait is calculated based on the slew rate and the voltage step (SMPSUpdateWait = slew rate * Voltage Step). After the voltage processor receives the SMPS_Ack signal, the Voltage Controller will wait for SMPSUpdateWait clock cycles for the voltage to settle to the new value. For all practical purposes, the waittime parameter is the OMAP hardware translation of what the slew rate on the PMIC is. As an example, with TPS62361 on OMAP4460, step_size = 1 slew_rate = 32000 sys_clk_rate = 38400 Our current computation results in the following: = ((step_size / slew_rate) * sys_clk_rate) / 1000 = ((1 / 32000) * 38400 / 1000 = 0 Fix the same using DIV_ROUND_UP as an extra wait clock cycle is better than lesser clock cycle. For the above example, this translates to: = (1 * 38400) / (1000 * 32000) = 12 Acked-by: Jon Hunter jon-hun...@ti.com [n...@ti.com: slightly better implementation] Signed-off-by: Nishanth Menon n...@ti.com Signed-off-by: Yuan Jiangli jly...@motorola.com Acked-by: Kevin Hilman khil...@ti.com Tony, I don't have any more PM fixes for this cycle, so feel free to add this to fixes-non-critical-part2. This is an important fix, but since we're not doing active voltage scaling in mainline today, I don't think it's 3.3 material. OK, adding. Thanks, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] ARM: OMAP: UART: cleanups for v3.4
Tony, Here are a couple minor cleanups in the serial init code for v3.4. Kevin The following changes since commit b01543dfe67bb1d191998e90d20534dc354de059: Linux 3.3-rc4 (2012-02-18 15:53:33 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_3.4/cleanup/uart for you to fetch changes up to 7cb034f8179dfc2889c1f2341566ee68f648a324: ARM: OMAP2+: remove some orphan function declarations. (2012-02-21 11:13:11 -0800) NeilBrown (2): ARM: OMAP2+: UART: remove unused fields in omap_uart_state. ARM: OMAP2+: remove some orphan function declarations. arch/arm/mach-omap2/pm.h |1 - arch/arm/mach-omap2/serial.c |4 arch/arm/plat-omap/include/plat/serial.h |1 - 3 files changed, 6 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] ARM: OMAP2+: gpmc-smsc911x: only register regulator for first instance
commit e4b0b2cbbb (ARM: OMAP2+: gpmc-smsc911x: add required smsc911x
regulators) added regulators which are registered during
gpmc_smsc911x_init(). However, some platforms (OMAP3/Overo) have more
than one instance of the SMSC911x and result in attempting to register
the same regulator more than once which causes a panic().
Fix this by only registering the regulator when the platform_data id
field is zero, indicating its the first instance.
Cc: Matt Porter mpor...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
Fix needed for v3.3.
Applies on top of Tony's fixes branch.
arch/arm/mach-omap2/gpmc-smsc911x.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c
b/arch/arm/mach-omap2/gpmc-smsc911x.c
index bbb870c..4d6f1c6 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.c
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
@@ -101,10 +101,13 @@ void __init gpmc_smsc911x_init(struct
omap_smsc911x_platform_data *board_data)
gpmc_cfg = board_data;
- ret = platform_device_register(gpmc_smsc911x_regulator);
- if (ret 0) {
- pr_err(Unable to register smsc911x regulators: %d\n, ret);
- return;
+ if (!gpmc_cfg) {
+ ret = platform_device_register(gpmc_smsc911x_regulator);
+ if (ret 0) {
+ pr_err(Unable to register smsc911x regulators: %d\n,
+ ret);
+ return;
+ }
}
if (gpmc_cs_request(gpmc_cfg-cs, SZ_16M, cs_mem_base) 0) {
--
1.7.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap3_beagle: init uart2 for beagle rev AX/BX only
On Tue, Mar 6, 2012 at 3:38 PM, Tony Lindgren t...@atomide.com wrote: * Govindraj.R govindraj.r...@ti.com [120306 00:34]: From: Govindraj.R govindraj.r...@ti.com All beagle boards rev AX/BX have external usb hubs connected to ehci interface, external hub/peripheral uses a nreset sequence for which uart2_rx.gpio_147 pin in mux mode4(USB2HS_nRST) is used on all beagle boards expect rev Ax/BX. (Reference to all beagle boards rev schematics: http://beagleboard.org/hardware/design) Initialising uart2 will lead to serial init taking over uart2_rx pin so init uart2_rx pin mux only for Beagle AX/BX rev boards. Dont init uart2 for all other boards allowing usb_ehci functionality. To initialise individual uart port by id utilise and modify the existing available func. omap_serial_board_init. Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@ti.com Cc: Koen Kooi k...@dominion.thruhere.net Tested-by: Peter Ujfalusi peter.ujfal...@ti.com Tested-by: Robert Nelson robertcnel...@gmail.com Signed-off-by: Govindraj.R govindraj.r...@ti.com Can somebody please test this on non-xm beagle too and reply with a Tested-by? Here's an update for my: Tested-by: Robert Nelson robertcnel...@gmail.com Just tested with one of my Beagle C4's, (and re-verified the new patch on a xM B) using usb flash drives on the ehci port... beagle c4: v3.2.9 Bus 001 Device 002: ID 0457:0151 Silicon Integrated Systems Corp. Super Flash 1GB / GXT 64MB Flash Drive v3.3-rc6: ehci broken v3.3-rc6 + this patch: Bus 001 Device 002: ID 0457:0151 Silicon Integrated Systems Corp. Super Flash 1GB / GXT 64MB Flash Driv beagle xM B: v3.2.9 Bus 001 Device 004: ID 1977:0824 T-Logic v3.3-rc6: ehci broken v3.3-rc6 + this patch: Bus 001 Device 004: ID 1977:0824 T-Logic Regards, -- Robert Nelson http://www.rcn-ee.com/ -- 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: OMAP2+: gpmc-smsc911x: only register regulator for first instance
* Kevin Hilman khil...@ti.com [120306 16:07]:
commit e4b0b2cbbb (ARM: OMAP2+: gpmc-smsc911x: add required smsc911x
regulators) added regulators which are registered during
gpmc_smsc911x_init(). However, some platforms (OMAP3/Overo) have more
than one instance of the SMSC911x and result in attempting to register
the same regulator more than once which causes a panic().
Fix this by only registering the regulator when the platform_data id
field is zero, indicating its the first instance.
Cc: Matt Porter mpor...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
Fix needed for v3.3.
Applies on top of Tony's fixes branch.
arch/arm/mach-omap2/gpmc-smsc911x.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c
b/arch/arm/mach-omap2/gpmc-smsc911x.c
index bbb870c..4d6f1c6 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.c
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
@@ -101,10 +101,13 @@ void __init gpmc_smsc911x_init(struct
omap_smsc911x_platform_data *board_data)
gpmc_cfg = board_data;
- ret = platform_device_register(gpmc_smsc911x_regulator);
- if (ret 0) {
- pr_err(Unable to register smsc911x regulators: %d\n, ret);
- return;
+ if (!gpmc_cfg) {
Shouldn't this be !gpmc_cfg-id instead..
+ ret = platform_device_register(gpmc_smsc911x_regulator);
+ if (ret 0) {
+ pr_err(Unable to register smsc911x regulators: %d\n,
+ret);
+ return;
+ }
}
if (gpmc_cs_request(gpmc_cfg-cs, SZ_16M, cs_mem_base) 0) {
..because we have gpmc_cfg always passed to gpmc_smsc911x_init().
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: gpmc-smsc911x: only register regulator for first instance
Tony Lindgren t...@atomide.com writes:
* Kevin Hilman khil...@ti.com [120306 16:07]:
commit e4b0b2cbbb (ARM: OMAP2+: gpmc-smsc911x: add required smsc911x
regulators) added regulators which are registered during
gpmc_smsc911x_init(). However, some platforms (OMAP3/Overo) have more
than one instance of the SMSC911x and result in attempting to register
the same regulator more than once which causes a panic().
Fix this by only registering the regulator when the platform_data id
field is zero, indicating its the first instance.
Cc: Matt Porter mpor...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
Fix needed for v3.3.
Applies on top of Tony's fixes branch.
arch/arm/mach-omap2/gpmc-smsc911x.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c
b/arch/arm/mach-omap2/gpmc-smsc911x.c
index bbb870c..4d6f1c6 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.c
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
@@ -101,10 +101,13 @@ void __init gpmc_smsc911x_init(struct
omap_smsc911x_platform_data *board_data)
gpmc_cfg = board_data;
-ret = platform_device_register(gpmc_smsc911x_regulator);
-if (ret 0) {
-pr_err(Unable to register smsc911x regulators: %d\n, ret);
-return;
+if (!gpmc_cfg) {
Shouldn't this be !gpmc_cfg-id instead..
doh, of course. Updated patch below.
Kevin
From 3c17a6fe6fdcc5e4e33f174c2b0982d71e759cf1 Mon Sep 17 00:00:00 2001
From: Kevin Hilman khil...@ti.com
Date: Thu, 1 Mar 2012 12:30:42 -0800
Subject: [PATCH] ARM: OMAP2+: gpmc-smsc911x: only register regulator for
first instance
commit e4b0b2cbbb (ARM: OMAP2+: gpmc-smsc911x: add required smsc911x
regulators) added regulators which are registered during
gpmc_smsc911x_init(). However, some platforms (OMAP3/Overo) have more
than one instance of the SMSC911x and result in attempting to register
the same regulator more than once which causes a panic().
Fix this by only registering the regulator when the platform_data id
field is zero, indicating its the first instance.
Cc: Matt Porter mpor...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/gpmc-smsc911x.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c
b/arch/arm/mach-omap2/gpmc-smsc911x.c
index bbb870c..5e5880d 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.c
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
@@ -101,10 +101,13 @@ void __init gpmc_smsc911x_init(struct
omap_smsc911x_platform_data *board_data)
gpmc_cfg = board_data;
- ret = platform_device_register(gpmc_smsc911x_regulator);
- if (ret 0) {
- pr_err(Unable to register smsc911x regulators: %d\n, ret);
- return;
+ if (!gpmc_cfg-id) {
+ ret = platform_device_register(gpmc_smsc911x_regulator);
+ if (ret 0) {
+ pr_err(Unable to register smsc911x regulators: %d\n,
+ ret);
+ return;
+ }
}
if (gpmc_cs_request(gpmc_cfg-cs, SZ_16M, cs_mem_base) 0) {
--
1.7.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: gpmc-smsc911x: only register regulator for first instance
* Kevin Hilman khil...@ti.com [120306 17:07]:
Tony Lindgren t...@atomide.com writes:
* Kevin Hilman khil...@ti.com [120306 16:07]:
commit e4b0b2cbbb (ARM: OMAP2+: gpmc-smsc911x: add required smsc911x
regulators) added regulators which are registered during
gpmc_smsc911x_init(). However, some platforms (OMAP3/Overo) have more
than one instance of the SMSC911x and result in attempting to register
the same regulator more than once which causes a panic().
Fix this by only registering the regulator when the platform_data id
field is zero, indicating its the first instance.
Cc: Matt Porter mpor...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
Fix needed for v3.3.
Applies on top of Tony's fixes branch.
arch/arm/mach-omap2/gpmc-smsc911x.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c
b/arch/arm/mach-omap2/gpmc-smsc911x.c
index bbb870c..4d6f1c6 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.c
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
@@ -101,10 +101,13 @@ void __init gpmc_smsc911x_init(struct
omap_smsc911x_platform_data *board_data)
gpmc_cfg = board_data;
- ret = platform_device_register(gpmc_smsc911x_regulator);
- if (ret 0) {
- pr_err(Unable to register smsc911x regulators: %d\n, ret);
- return;
+ if (!gpmc_cfg) {
Shouldn't this be !gpmc_cfg-id instead..
doh, of course. Updated patch below.
Thanks, applying into fixes.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Hi Will, On Fri, Jan 27, 2012 at 11:54 PM, Will Deacon will.dea...@arm.com wrote: Ok. Note that on ARM the PMU generates a standard IRQ (i.e. not an NMI) so you may miss samples if they occur during critical kernel sections (and if you look at a profile, spin_unlock_irqrestore will be quite high). Also looks no any irq handler functions can be observed at a profile even though they may be run at a very high frequency. So could we configure ARM PMU interrupt as FIQ to address the above issues? thanks -- Ming Lei -- 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
[RFC PATCH] cpuidle: avoid unnecessary expensive governor processing
There a few cases when a platform's cpuidle_device will only have one
cpuidle state. e.g., when a single idle state system uses cpuidle
to provide sysfs staticstics for profiling (powertop, etc). This can
also be the case for coupled smp system implementations that keep
all but one cpuidle_device at a state_count of 1, but they still want
to export idle statistics for these states using cpuidle.
Signed-off-by: Robert Lee rob@linaro.org
---
drivers/cpuidle/governors/ladder.c |7 +--
drivers/cpuidle/governors/menu.c |7 +--
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/cpuidle/governors/ladder.c
b/drivers/cpuidle/governors/ladder.c
index b6a09ea..13abdba 100644
--- a/drivers/cpuidle/governors/ladder.c
+++ b/drivers/cpuidle/governors/ladder.c
@@ -71,8 +71,11 @@ static int ladder_select_state(struct cpuidle_driver *drv,
int last_residency, last_idx = ldev-last_state_idx;
int latency_req = pm_qos_request(PM_QOS_CPU_DMA_LATENCY);
- /* Special case when user has set very strict latency requirement */
- if (unlikely(latency_req == 0)) {
+ /*
+* Special case when user has set very strict latency requirement or
+* there is currently only one state for this device.
+*/
+ if ((latency_req == 0) || (dev-state_count == 1)) {
ladder_do_selection(ldev, last_idx, 0);
return 0;
}
diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
index ad09526..80eb606 100644
--- a/drivers/cpuidle/governors/menu.c
+++ b/drivers/cpuidle/governors/menu.c
@@ -249,8 +249,11 @@ static int menu_select(struct cpuidle_driver *drv, struct
cpuidle_device *dev)
data-last_state_idx = 0;
data-exit_us = 0;
- /* Special case when user has set very strict latency requirement */
- if (unlikely(latency_req == 0))
+ /*
+* Special case when user has set very strict latency requirement or
+* there is currently only one state for this device.
+*/
+ if ((latency_req == 0) || (dev-state_count == 1))
return 0;
/* determine the expected residency time, round up */
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] OMAP: UART: Enable tx wakeup bit in wer
Hi On Tue, 6 Mar 2012, Raja, Govindraj wrote: I see two ways of adding this tx wake-up flag. 1.) passing a feature flag from pdata and populating the feature value to wer. 2.) Duplicating the uart1/2/3 hwmod for omap3430 without dev attrib and uart1/2/3/4 hwmod for omap3630 with dev attribs. Approach-2 adds unnecessary code duplication in hwmod file with and without dev_attribs, So right now here is the patch to follow approach [1], If its strongly recommended to use approach-2 will add it. (My concern is the diffstat it might produce with approach-2) Both 1 and 2 are needed. The current way that errata are handled in arch/arm/mach-omap2/serial.c needs to be changed. Those should be flags that are passed from hwmod dev_attr data. The presence of the TX wakeup bit should simply be another dev_attr flag. These flags should be passed to the driver via the omap_up.errata field for the time being. The exception to this is if the IP block's revision register was changed when TX wakeups became possible. If that's the case, then that mechanism can be used in lieu of dev_attr and platform_data in this situation. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
