RE: [PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
On Fri, Apr 06, 2012 at 23:34:52, Tony Lindgren wrote:
* Hiremath, Vaibhav hvaib...@ti.com [120405 22:25]:
On Fri, Apr 06, 2012 at 03:03:01, Hilman, Kevin wrote:
What we need is only one-time selection at boot based on presence (or
not) of various timers. IOW, we still only ever need to call
setup_sched_clock() once based on which HW timers are available.
Why not just delay the setup_sched_clock() until the clocksource is
decided?
I think that's we're already doing for omap1 as 15xx does not
have the 32 KiHz timer and the CONFIG_OMAP_32K_TIMER is no longer
conflicting with the MPU timer.
No we are not delaying anything here, we still are calling
setup_sched_clock() function in timer-init() callback.
The call sequence for omap1 is,
struct sys_timer omap1_timer = {
.init = omap1_timer_init,
};
static void __init omap1_timer_init(void)
{
if (!omap_32k_timer_usable())
omap_mpu_timer_init();
}
omap_32k_timer_usable() is just return for omap730 omap15xx and fallback to
omap_mpu_timer_init(). For all other platforms, 32ksync timer init call
happens.
In both the cases, setup_sched_clock() is called.
I liked Santosh's idea in using command line argument clocksource= and
make decision based on this. I have implemented it and tried it on both
OMAP3EVM and beaglebone and it works great.
I have introduced something like this in mach-omap2/timer.c,
static int __init omap2_override_clocksource(char* str)
{
if (!str)
return 0;
/*
* For OMAP architecture, we only have two options
*- sync_32k (default)
*- gp timer
*/
if (!strcmp(str, gp timer))
use_gptimer_clksrc = true;
return 0;
}
early_param(clocksource, omap2_override_clocksource);
Sure a cmdline override is nice to have for user selection.
But we should also by default do the right thing based on what the
board wants in .timer entry.
I did not understand what exactly you are trying to point here.
I think we are doing exactly what board needs in .timer.
It solves all issues what we have been trying address.
I'm a bit confused.. Can you briefly summarize again what all
issues you're having? Just want to select a different clocksource
for beaglebone? If you don't have the 32 KiHz then that can't
be selected naturally?
Let me summarize it here again,
Currently, the timer code is using config option CONFIG_OMAP_32K_TIMER,
to choose between 32ksync counter and gptimer; it is compile time option.
If user wants to use gptimer for HR ticks, he must build the kernel without
CONFIG_OMAP_32K_TIMER option.
AM335x family of devices doesn't have 32ksync_counter available, only option
here is to use gptimer for kernel clocksource and clockevents.
So in order to support, multi-omap build including devices like AM335x, we
must get rid of this option CONFIG_OMAP_32K_TIMER, atleast from clocksource
registration perspective.
So that means, we need to have some mechanism to handle or detect available
clocksource runtime. Options would be,
- Use HWMOD to detect availability of 32ksync_counter, else fallback
to gptimer. [This was my original patch]
But this restricts the use of gptimer completely on omap architecture,
where we have 32ksync counter module.
- So the next solution is to still keep compile time option, so that user
will get to use gptimer atleast just changing the kernel config option.
But, still, this is going to be kernel rebuild.
- Next option came up was, register both the timers and override using
kernel parameter.
This will work only if, both the timers run at same rate/frequency; since
we have one more layer here setup_sched_clock(), which actually can be
called only once.
- Next option suggested by Santosh, is to use kernel parameter as in parse
it early, to make decision on if user wants to override default
clocksource (32ksync)
This is something will work for us and solves all above issues.
I have validated it on OMAP3EVM and it seems to be working for me without
any issues.
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
On Sat, Apr 07, 2012 at 02:48:47, Hilman, Kevin wrote:
Hiremath, Vaibhav hvaib...@ti.com writes:
[...]
I liked Santosh's idea in using command line argument clocksource= and
make decision based on this. I have implemented it and tried it on both
OMAP3EVM and beaglebone and it works great.
I have introduced something like this in mach-omap2/timer.c,
static int __init omap2_override_clocksource(char* str)
{
if (!str)
return 0;
/*
* For OMAP architecture, we only have two options
*- sync_32k (default)
*- gp timer
*/
if (!strcmp(str, gp timer))
use_gptimer_clksrc = true;
return 0;
}
early_param(clocksource, omap2_override_clocksource);
How does this interact with the existing clocksource cmdline parameter
already in kernel/time/clocksource.c? (c.f. boot_override_clocksource())
Not really, it doesn't interact with existing clocksource parameter
Already present in kernel/time/clocksource.c.
Both works independently...
IMO, this duplicates that functionality but less elegantly.
What should happen is to let clocksource selection happen normally
(based on presence or lack of HW, or cmdline override.) Once that has
happened, you can then setup_sched_clock() with parameters from querying
the clocksource itself.
After Russell's response, it is clear that we should not change the
clocksource dynamically, its not useful. So I do not see any benefits
following that feature (as of now).
We just need to make sure that, we detect our clocksource and call
setup_sched_clock() with appropriate rating.
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] mmc: omap_hsmmc: Additional cleanups / features
Hi Chris, As discussed previously [1], I've rebased the previous 2 patches that you decided to queue for 3.5, plus 2 additional cleanups. Best regards, Venkat. [1] http://marc.info/?l=linux-mmcm=16030703924w=2 The following changes since commit 3bdc9ba892d6a294d16e9e6e0c4041926aa3d58c: mmc: use really long write timeout to deal with crappy cards (2012-04-05 20:32:34 -0400) are available in the git repository at: git://github.com/svenkatr/linux.git mmc-omap_hsmmc-next for you to fetch changes up to 11c6cb1453f55b21e50fd891b3981a98a572d314: mmc: omap_hsmmc: Cleanup use of cpu_is_* for debounce_clock (2012-04-09 11:58:22 +0530) Balaji T K (2): mmc: omap_hsmmc: Enable Auto CMD12 mmc: omap_hsmmc: add DDR support to omap_hsmmc Rajendra Nayak (1): mmc: omap_hsmmc: Cleanup use of cpu_is_* for debounce_clock Venkatraman S (1): mmc: omap_hsmmc: use spinlock IRQ safe variant drivers/mmc/host/omap_hsmmc.c | 78 +--- 1 file changed, 45 insertions(+), 33 deletions(-) -- 1.7.10.rc2 -- 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 RESEND 1/4] mmc: omap_hsmmc: Enable Auto CMD12
From: Balaji T K balaj...@ti.com
Enable Auto-CMD12 for multi block read/write on HSMMC
Tested on OMAP4430, OMAP3430 and OMAP2430 SDP
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 5c2b1c1..1fcacb6 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -85,6 +85,7 @@
#define BRR_ENABLE (1 5)
#define DTO_ENABLE (1 20)
#define INIT_STREAM(1 1)
+#define ACEN_ACMD12(1 2)
#define DP_SELECT (1 21)
#define DDIR (1 4)
#define DMA_EN 0x1
@@ -115,6 +116,7 @@
#define OMAP_MMC_MAX_CLOCK 5200
#define DRIVER_NAMEomap_hsmmc
+#define AUTO_CMD12 (1 0)/* Auto CMD12 support */
/*
* One controller can have multiple slots, like on some omap boards using
* omap.c controller driver. Luckily this is not currently done on any known
@@ -175,6 +177,7 @@ struct omap_hsmmc_host {
int reqs_blocked;
int use_reg;
int req_in_progress;
+ unsigned intflags;
struct omap_hsmmc_next next_data;
struct omap_mmc_platform_data *pdata;
@@ -766,6 +769,8 @@ omap_hsmmc_start_command(struct omap_hsmmc_host *host,
struct mmc_command *cmd,
cmdtype = 0x3;
cmdreg = (cmd-opcode 24) | (resptype 16) | (cmdtype 22);
+ if ((host-flags AUTO_CMD12) mmc_op_multi(cmd-opcode))
+ cmdreg |= ACEN_ACMD12;
if (data) {
cmdreg |= DP_SELECT | MSBS | BCE;
@@ -837,11 +842,14 @@ omap_hsmmc_xfer_done(struct omap_hsmmc_host *host, struct
mmc_data *data)
else
data-bytes_xfered = 0;
- if (!data-stop) {
+ if (data-stop ((!(host-flags AUTO_CMD12)) || data-error)) {
+ omap_hsmmc_start_command(host, data-stop, NULL);
+ } else {
+ if (data-stop)
+ data-stop-resp[0] = OMAP_HSMMC_READ(host-base,
+ RSP76);
omap_hsmmc_request_done(host, data-mrq);
- return;
}
- omap_hsmmc_start_command(host, data-stop, NULL);
}
/*
@@ -1844,6 +1852,7 @@ static int __devinit omap_hsmmc_probe(struct
platform_device *pdev)
host-mapbase = res-start + pdata-reg_offset;
host-base = ioremap(host-mapbase, SZ_4K);
host-power_mode = MMC_POWER_OFF;
+ host-flags = AUTO_CMD12;
host-next_data.cookie = 1;
platform_set_drvdata(pdev, host);
--
1.7.10.rc2
--
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 RESEND 2/4] mmc: omap_hsmmc: add DDR support to omap_hsmmc
From: Balaji T K balaj...@ti.com
Add Dual data rate support for omap_hsmmc
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap_hsmmc.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 1fcacb6..9e701f3 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -92,6 +92,7 @@
#define MSBS (1 5)
#define BCE(1 1)
#define FOUR_BIT (1 1)
+#define DDR(1 19)
#define DW8(1 5)
#define CC 0x1
#define TC 0x02
@@ -523,6 +524,10 @@ static void omap_hsmmc_set_bus_width(struct
omap_hsmmc_host *host)
u32 con;
con = OMAP_HSMMC_READ(host-base, CON);
+ if (ios-timing == MMC_TIMING_UHS_DDR50)
+ con |= DDR; /* configure in DDR mode */
+ else
+ con = ~DDR;
switch (ios-bus_width) {
case MMC_BUS_WIDTH_8:
OMAP_HSMMC_WRITE(host-base, CON, con | DW8);
--
1.7.10.rc2
--
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/4] mmc: omap_hsmmc: use spinlock IRQ safe variant
Prevent possible races between HSMMC/DMA IRQs and next requests.
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 9e701f3..e8f296d 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -806,11 +806,12 @@ omap_hsmmc_get_dma_dir(struct omap_hsmmc_host *host,
struct mmc_data *data)
static void omap_hsmmc_request_done(struct omap_hsmmc_host *host, struct
mmc_request *mrq)
{
int dma_ch;
+ unsigned long flags;
- spin_lock(host-irq_lock);
+ spin_lock_irqsave(host-irq_lock, flags);
host-req_in_progress = 0;
dma_ch = host-dma_ch;
- spin_unlock(host-irq_lock);
+ spin_unlock_irqrestore(host-irq_lock, flags);
omap_hsmmc_disable_irq(host);
/* Do not complete the request if DMA is still in progress */
@@ -887,13 +888,14 @@ omap_hsmmc_cmd_done(struct omap_hsmmc_host *host, struct
mmc_command *cmd)
static void omap_hsmmc_dma_cleanup(struct omap_hsmmc_host *host, int errno)
{
int dma_ch;
+ unsigned long flags;
host-data-error = errno;
- spin_lock(host-irq_lock);
+ spin_lock_irqsave(host-irq_lock, flags);
dma_ch = host-dma_ch;
host-dma_ch = -1;
- spin_unlock(host-irq_lock);
+ spin_unlock_irqrestore(host-irq_lock, flags);
if (host-use_dma dma_ch != -1) {
dma_unmap_sg(mmc_dev(host-mmc), host-data-sg,
@@ -1247,6 +1249,7 @@ static void omap_hsmmc_dma_cb(int lch, u16 ch_status,
void *cb_data)
struct omap_hsmmc_host *host = cb_data;
struct mmc_data *data;
int dma_ch, req_in_progress;
+ unsigned long flags;
if (!(ch_status OMAP_DMA_BLOCK_IRQ)) {
dev_warn(mmc_dev(host-mmc), unexpected dma status %x\n,
@@ -1254,9 +1257,9 @@ static void omap_hsmmc_dma_cb(int lch, u16 ch_status,
void *cb_data)
return;
}
- spin_lock(host-irq_lock);
+ spin_lock_irqsave(host-irq_lock, flags);
if (host-dma_ch 0) {
- spin_unlock(host-irq_lock);
+ spin_unlock_irqrestore(host-irq_lock, flags);
return;
}
@@ -1266,7 +1269,7 @@ static void omap_hsmmc_dma_cb(int lch, u16 ch_status,
void *cb_data)
/* Fire up the next transfer. */
omap_hsmmc_config_dma_params(host, data,
data-sg + host-dma_sg_idx);
- spin_unlock(host-irq_lock);
+ spin_unlock_irqrestore(host-irq_lock, flags);
return;
}
@@ -1277,7 +1280,7 @@ static void omap_hsmmc_dma_cb(int lch, u16 ch_status,
void *cb_data)
req_in_progress = host-req_in_progress;
dma_ch = host-dma_ch;
host-dma_ch = -1;
- spin_unlock(host-irq_lock);
+ spin_unlock_irqrestore(host-irq_lock, flags);
omap_free_dma(dma_ch);
--
1.7.10.rc2
--
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/4] mmc: omap_hsmmc: Cleanup use of cpu_is_* for debounce_clock
From: Rajendra Nayak rna...@ti.com
There really does not seem to be a need to use cpu_is_*
check for getting the debounce clock as clkdev is
perfectly capable of handling situations when certain
clocks are only available on select platforms.
Also get rid of the 'got_dbclk' flag and instead use the
dbclk clock pointer to know if a valid debounce clock
exists for the platform.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 39 +--
1 file changed, 17 insertions(+), 22 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index e8f296d..ea8afcb 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -170,7 +170,6 @@ struct omap_hsmmc_host {
int use_dma, dma_ch;
int dma_line_tx, dma_line_rx;
int slot_id;
- int got_dbclk;
int response_busy;
int context_loss;
int vdd;
@@ -1097,7 +1096,7 @@ static int omap_hsmmc_switch_opcond(struct
omap_hsmmc_host *host, int vdd)
/* Disable the clocks */
pm_runtime_put_sync(host-dev);
- if (host-got_dbclk)
+ if (host-dbclk)
clk_disable(host-dbclk);
/* Turn the power off */
@@ -1108,7 +1107,7 @@ static int omap_hsmmc_switch_opcond(struct
omap_hsmmc_host *host, int vdd)
ret = mmc_slot(host).set_power(host-dev, host-slot_id, 1,
vdd);
pm_runtime_get_sync(host-dev);
- if (host-got_dbclk)
+ if (host-dbclk)
clk_enable(host-dbclk);
if (ret != 0)
@@ -1902,21 +1901,17 @@ static int __devinit omap_hsmmc_probe(struct
platform_device *pdev)
omap_hsmmc_context_save(host);
- if (cpu_is_omap2430()) {
- host-dbclk = clk_get(pdev-dev, mmchsdb_fck);
- /*
-* MMC can still work without debounce clock.
-*/
- if (IS_ERR(host-dbclk))
- dev_warn(mmc_dev(host-mmc),
- Failed to get debounce clock\n);
- else
- host-got_dbclk = 1;
-
- if (host-got_dbclk)
- if (clk_enable(host-dbclk) != 0)
- dev_dbg(mmc_dev(host-mmc), Enabling debounce
-clk failed\n);
+ host-dbclk = clk_get(pdev-dev, mmchsdb_fck);
+ /*
+* MMC can still work without debounce clock.
+*/
+ if (IS_ERR(host-dbclk)) {
+ dev_warn(mmc_dev(host-mmc), Failed to get debounce clk\n);
+ host-dbclk = NULL;
+ } else if (clk_enable(host-dbclk) != 0) {
+ dev_warn(mmc_dev(host-mmc), Failed to enable debounce clk\n);
+ clk_put(host-dbclk);
+ host-dbclk = NULL;
}
/* Since we do only SG emulation, we can have as many segs
@@ -2036,7 +2031,7 @@ err_irq:
pm_runtime_put_sync(host-dev);
pm_runtime_disable(host-dev);
clk_put(host-fclk);
- if (host-got_dbclk) {
+ if (host-dbclk) {
clk_disable(host-dbclk);
clk_put(host-dbclk);
}
@@ -2069,7 +2064,7 @@ static int __devexit omap_hsmmc_remove(struct
platform_device *pdev)
pm_runtime_put_sync(host-dev);
pm_runtime_disable(host-dev);
clk_put(host-fclk);
- if (host-got_dbclk) {
+ if (host-dbclk) {
clk_disable(host-dbclk);
clk_put(host-dbclk);
}
@@ -2127,7 +2122,7 @@ static int omap_hsmmc_suspend(struct device *dev)
OMAP_HSMMC_READ(host-base, HCTL) ~SDBP);
}
- if (host-got_dbclk)
+ if (host-dbclk)
clk_disable(host-dbclk);
err:
pm_runtime_put_sync(host-dev);
@@ -2148,7 +2143,7 @@ static int omap_hsmmc_resume(struct device *dev)
pm_runtime_get_sync(host-dev);
- if (host-got_dbclk)
+ if (host-dbclk)
clk_enable(host-dbclk);
if (!(host-mmc-pm_flags MMC_PM_KEEP_POWER))
--
1.7.10.rc2
--
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/3] OMAP4: CPUidle: Add coupled idle support
On Tuesday 03 April 2012 08:36 PM, Santosh Shilimkar wrote: On Tuesday 03 April 2012 10:34 AM, Kevin Hilman wrote: Hi Santosh, Santosh Shilimkar santosh.shilim...@ti.com writes: The series adds the coupled cpuidle support for OMAP4 based on the v2 series posted [1]. This makes OMAP4 to support SMP cpuidle and also removes the hard dependency of off-lining CPU1 to trigger deeper C-states. I have put together a branch which is based on 3.3 kernel with Len Browns next branch [2] which has time keeping and other cpuidle patches which will mostly get merged by 3.4-rc1 and rebased coupled idle series from [1]. Thanks for rebasing this. git://gitorious.org/omap-sw-develoment/linux-omap-dev.git for_3.5/omap4_coupled_cpuidle-rebase This branch by itself seems to work fine. However, when combining with other stuff that has merged for v3.4, it hangs during boot. I haven't yet isolated the problem, but it's easy to reproduce by combining your branch with v3.4-rc1: git checkout -b test/coupled-v3.4 v3.4-rc1 git merge -s recursive -X ours santosh/for_3.5/omap4_coupled_cpuidle-rebase [1] This hangs on boot, and it seems like a coupled state deadlock because commenting out the coupled states in the C-state creation of cpuidle44xx.c makes it boot just fine. I managed to reproduce the issue. Just to ensure that any OMAP changes have not introduced the regression I merged all Tony's pull request on my branch and tried it out. OMAP changes are fine and coupled idle continue to work. Started bisecting the commits. For bisect I have to create a series which is not dependent on Len's cpuidle updates. First round of bisect was not successful so tried one more time. Was very close to narrowing down on commit but then encountered set of commits where either CPUIDLE itself is broken(deeper C-states are not getting attempted) or I get softIRQ 08 pending error. The last bad commit in bisect was ... [8682df25ca9afd3aac30f2c72d00bd98de2118e8] Merge branch 'fortglx/3.4/rtc' of git://git.linaro.org/people/jstultz/linux into timers/core So far looks like, one of below series has introduced a race which is getting highlighted with coupled cpuidle patchset. 9b612fa Merge branch 'fortglx/3.4/clocksource' of git://git.linaro.org/people/jstultz/linux into timers/core 8682df2 Merge branch 'fortglx/3.4/rtc' of git://git.linaro.org/people/jstultz/linux into timers/core 97ac984 Merge branch 'fortglx/3.4/time' of git://git.linaro.org/people/jstultz/linux into timers/core Finally managed to crack down the issue. The broad-cast clock-event was remaining in shut-down mode and hence we were loosing the OS tick after entering to low power states. The cases where it use to work was mainly because of external interrupts like NFS etc. Have posted a patch [1] on LKML which fixes the issue. Waiting for feedback from Thomas on it. Have updated the git tree with patch [1] + 3.4-rc2 and same is available here[2] Regards Santosh [1] https://lkml.org/lkml/2012/4/9/13 [2] git://gitorious.org/omap-sw-develoment/linux-omap-dev.git for_3.5/coupled_cpuidle-rebase -- 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: OMAP: Revert ARM: OMAP: ctrl: Fix CONTROL_DSIPHY register fields
This reverts commit 46f8c3c7e95c0d30d95911e7975ddc4f93b3e237. The commit above swapped the DSI1_PPID and DSI2_PPID register fields in CONTROL_DSIPHY to be in sync with the newer public OMAP TRMs(after version V). With this commit, contention errors were reported on DSI lanes some OMAP4 SDPs. After probing the DSI lanes on OMAP4 SDP, it was seen that setting bits in the DSI2_PPID field was pulling up voltage on DSI1 lanes, and DSI1_PPID field was pulling up voltage on DSI2 lanes. This proves that the current version of OMAP4 TRM is incorrect, swap the position of register fields according to the older TRM versions as they were correct. Signed-off-by: Archit Taneja arc...@ti.com --- .../include/mach/ctrl_module_pad_core_44xx.h |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-omap2/include/mach/ctrl_module_pad_core_44xx.h b/arch/arm/mach-omap2/include/mach/ctrl_module_pad_core_44xx.h index 1e2d332..c88420d 100644 --- a/arch/arm/mach-omap2/include/mach/ctrl_module_pad_core_44xx.h +++ b/arch/arm/mach-omap2/include/mach/ctrl_module_pad_core_44xx.h @@ -941,10 +941,10 @@ #define OMAP4_DSI2_LANEENABLE_MASK (0x7 29) #define OMAP4_DSI1_LANEENABLE_SHIFT24 #define OMAP4_DSI1_LANEENABLE_MASK (0x1f 24) -#define OMAP4_DSI2_PIPD_SHIFT 19 -#define OMAP4_DSI2_PIPD_MASK (0x1f 19) -#define OMAP4_DSI1_PIPD_SHIFT 14 -#define OMAP4_DSI1_PIPD_MASK (0x1f 14) +#define OMAP4_DSI1_PIPD_SHIFT 19 +#define OMAP4_DSI1_PIPD_MASK (0x1f 19) +#define OMAP4_DSI2_PIPD_SHIFT 14 +#define OMAP4_DSI2_PIPD_MASK (0x1f 14) /* CONTROL_MCBSPLP */ #define OMAP4_ALBCTRLRX_FSX_SHIFT 31 -- 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: [RESEND PATCH] ARM :OMAP2+: UART: Remove some of uart default pads
Hi Tony,
On Fri, Apr 6, 2012 at 11:45 PM, Tony Lindgren t...@atomide.com wrote:
* Raja, Govindraj govindraj.r...@ti.com [120405 23:08]:
On Thu, Apr 5, 2012 at 10:28 PM, Tony Lindgren t...@atomide.com wrote:
Hmm I don't think any muxing was done automatically unless
omap_serial_init_port was being called with pins.
Muxing was happening even if we don't call omap_serial_init_port
rx pin was muxed for wakeup capability for all uart pins
OK, but that was only for the wake-up muxing? That sounds risky
too for some boards as the board may be using alternative uart
pins instead of the default ones.
omap_uart_idle_init = was populating padconf offset value for ech uart
which was used in omap_uart_enable/disable_wakeup functions.
This mechanism was keeping PM happening for all boards.
OK, that's safe if we also bail out for the cases where the default
uart pins are not muxed to serial functionality to start with.
So to summarize, the right fix is to:
1. Only do muxing of uarts from other modes to uart mode if
omap_serial_init_port is being called with the board specific
mux options for the port in question.
2. Bail out early in omap_serial_init for each port that does not
have it's default uart pins already muxed to uart functionality.
3. For the uart ports configured in #1 or #2 above, allow dynamic
remuxing of the wake-up capability but don't touch the others.
Thanks for the review and suggestions, here is the patch [1] to do the same.
I tested this patch on beagle-xm where uart pin mux was causing clash
with usb ehci hub gpio nrest pin, now with this patch smsc hub + ethernet
get enumerated.
--
Thanks,
Govindraj.R
[1]:
From 37850b9e80fc4dac050bff5b6dbb67c245be43cc Mon Sep 17 00:00:00 2001
From: Govindraj.R govindraj.r...@ti.com
Date: Mon, 9 Apr 2012 15:16:52 +0530
Subject: [PATCH] ARM: OMAP2+: UART: Fix usage of default uart pads.
The following commit:
(7496ba3 ARM: OMAP2+: UART: Add default mux for all uarts)
added default pads for all uarts. But not all boards tend to
use all uarts and most of unused uart pins are muxed for
other purpose. This commit breaks the modules which where trying
to use unused uart pins on their boards.
So check for the availability of uart pins before filling the pads
if both tx and rx are available as uart pins then use them for
filling as default pads where rx pin is muxed dynamically for
rx wakeup capability.
However the board file owners can use omap_serial_init_port
and pass mux data part of board data for board specific use cases.
Cc: Felipe Balbi ba...@ti.com
Cc: Kevin Hilman khil...@ti.com
Reported-by: Tony Lindgren t...@atomide.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/mux.c|2 +-
arch/arm/mach-omap2/mux.h| 10 +++
arch/arm/mach-omap2/serial.c | 158 --
3 files changed, 56 insertions(+), 114 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 65c3391..5334914 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -217,7 +217,7 @@ static int __init _omap_mux_get_by_name(struct
omap_mux_partition *partition,
return -ENODEV;
}
-static int __init
+int __init
omap_mux_get_by_name(const char *muxname,
struct omap_mux_partition **found_partition,
struct omap_mux **found_mux)
diff --git a/arch/arm/mach-omap2/mux.h b/arch/arm/mach-omap2/mux.h
index 69fe060..461b90d 100644
--- a/arch/arm/mach-omap2/mux.h
+++ b/arch/arm/mach-omap2/mux.h
@@ -225,8 +225,18 @@ omap_hwmod_mux_init(struct omap_device_pad
*bpads, int nr_pads);
*/
void omap_hwmod_mux(struct omap_hwmod_mux_info *hmux, u8 state);
+int omap_mux_get_by_name(const char *muxname,
+struct omap_mux_partition **found_partition,
+struct omap_mux **found_mux);
#else
+static inline int omap_mux_get_by_name(const char *muxname,
+struct omap_mux_partition **found_partition,
+struct omap_mux **found_mux)
+{
+ return 0;
+}
+
static inline int omap_mux_init_gpio(int gpio, int val)
{
return 0;
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 0cdd359..30a0f4e 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -120,127 +120,59 @@ static void omap_uart_set_smartidle(struct
platform_device *pdev) {}
#endif /* CONFIG_PM */
#ifdef CONFIG_OMAP_MUX
-static struct omap_device_pad default_uart1_pads[] __initdata = {
- {
- .name = uart1_cts.uart1_cts,
- .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
- },
- {
- .name = uart1_rts.uart1_rts,
- .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
- },
- {
- .name = uart1_tx.uart1_tx,
- .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
- },
- {
-
Re: Suspend broken on 3.3?
Hi Kevin / Paul, On Fri, Apr 6, 2012 at 7:51 PM, Kevin Hilman khil...@ti.com wrote: Paul Walmsley p...@pwsan.com writes: On Wed, 4 Apr 2012, Raja, Govindraj wrote: On Wed, Apr 4, 2012 at 8:26 PM, Paul Walmsley p...@pwsan.com wrote: On Mon, 2 Apr 2012, Raja, Govindraj wrote: As of now what I can think of is to update qos reqest to prevent MPU from transitioning in case of port activity if wakeup capability for port is disabled. Haven't been following this thread closely, but this doesn't seem right. Why would changing the UART driver's ability to wake from suspend via the sysfs file prevent the driver from using hardware wakeups to wake from dynamic idle? IIUC wakeup capability is needed in suspend path or in cpu idle path. once uart wakeup capability is disabled from sysfs the Module level wakeup from PM_WKEN1 reg on omap3 and pad wakeup from pin mux data given will be disabled.. As far as I know, that sysfs wakeup file is not meant to disable all module-level wakeup. Kevin can correct me if I'm wrong, but I think it's only supposed to control wakeup from suspend. In theory, sysfs control is meant for static suspend. ISTR though that we were using it for idle as well so there weren't unncessary UART wakeups from idle on UART activity that was not serial console. So incase of uart wakeups are disabled and uart tx/rx is requested can we prevent MPU from low power state. -- 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 0/4] mmc: omap_hsmmc: Additional cleanups / features
Hi Venkat, On Mon, Apr 09 2012, Venkatraman S wrote: Hi Chris, As discussed previously [1], I've rebased the previous 2 patches that you decided to queue for 3.5, plus 2 additional cleanups. Thanks very much -- pushed out to mmc-next for 3.5. - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- 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: Suspend broken on 3.3?
Raja, Govindraj govindraj.r...@ti.com writes: [...] So incase of uart wakeups are disabled and uart tx/rx is requested can we prevent MPU from low power state. I think that would be a mistake. The main point of disabling UART wakeups is to save power by preventing unwanted wakups on UARTs that don't need/want them. If we then leave MPU enabled because UART wakeups are disabled, that would defeat the power-saving goals of disabling wakeups in the first place. Presumably, if a user disables UART wakeups, it means either 1) that UART is not used or 2) performance is not critical. IMO, we simply need to ensure that the defaults are correct. When UARTs are initialized/enabled wakeups should be enabled by default. The user can then override this if desired, and will obviously see a performance impact. But that's what happens with wakeups disabled. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Suspend broken on 3.3?
cc linux-serial Hi On Mon, 9 Apr 2012, Kevin Hilman wrote: Presumably, if a user disables UART wakeups, it means either 1) that UART is not used #1 seems easy enough to handle without the use of power/wakeup. If there are no users of the TTY, then the driver can simply not configure hardware wakeups. or 2) performance is not critical. Can you think of a use-case for #2? IMO, we simply need to ensure that the defaults are correct. When UARTs are initialized/enabled wakeups should be enabled by default. The user can then override this if desired, and will obviously see a performance impact. But that's what happens with wakeups disabled. I don't understand why a user would ever want to disable dynamic wakeups on an in-use serial port via the sysfs power/wakeup file. (Disabling wakeups from suspend is a different matter, of course.) The OMAP UART driver needs hardware wakeups to function for FIFO drain wakeups, etc. So to me it really doesn't make sense to disable those types of wakeup events, ever. But maybe you know of some use-case that I don't? If the user just wants a transmit-only serial port, they could use the termios CREAD flag as Neil mentioned a few months ago, and the driver could disable wakeups on incoming RXD (modulo any active flow control of course). - 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] ARM: OMAP2+: PRM: fix compile for OMAP4-only build
On Thu, 5 Apr 2012, Kevin Hilman wrote: No objections. Thanks, I took a closer look at this issue over the weekend, and realized that I had misunderstood it. So, will take this patch as-is, as part of the io_chain_devel_3.5 series; thanks for the great changelog. Looking forward to dropping these old OMAP2/3 PRM stubs for OMAP4 soon, they've been around for too long :-( - 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: [RESEND PATCH] ARM :OMAP2+: UART: Remove some of uart default pads
Thanks for the review and suggestions, here is the patch [1] to do the same.
I tested this patch on beagle-xm where uart pin mux was causing clash
with usb ehci hub gpio nrest pin, now with this patch smsc hub + ethernet
get enumerated.
Morning. I tested this patch on both next and master on the xM and it
does work, however, I have some comments.
From 37850b9e80fc4dac050bff5b6dbb67c245be43cc Mon Sep 17 00:00:00 2001
From: Govindraj.R govindraj.r...@ti.com
Date: Mon, 9 Apr 2012 15:16:52 +0530
Subject: [PATCH] ARM: OMAP2+: UART: Fix usage of default uart pads.
The following commit:
(7496ba3 ARM: OMAP2+: UART: Add default mux for all uarts)
added default pads for all uarts. But not all boards tend to
use all uarts and most of unused uart pins are muxed for
other purpose. This commit breaks the modules which where trying
to use unused uart pins on their boards.
So check for the availability of uart pins before filling the pads
if both tx and rx are available as uart pins then use them for
filling as default pads where rx pin is muxed dynamically for
rx wakeup capability.
However the board file owners can use omap_serial_init_port
and pass mux data part of board data for board specific use cases.
Cc: Felipe Balbi ba...@ti.com
Cc: Kevin Hilman khil...@ti.com
Reported-by: Tony Lindgren t...@atomide.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/mux.c | 2 +-
arch/arm/mach-omap2/mux.h | 10 +++
arch/arm/mach-omap2/serial.c | 158
--
3 files changed, 56 insertions(+), 114 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 65c3391..5334914 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -217,7 +217,7 @@ static int __init _omap_mux_get_by_name(struct
omap_mux_partition *partition,
It seems your mailer might be eating your patchesWhat mailer are you using?
return -ENODEV;
}
-static int __init
+int __init
omap_mux_get_by_name(const char *muxname,
struct omap_mux_partition **found_partition,
struct omap_mux **found_mux)
diff --git a/arch/arm/mach-omap2/mux.h b/arch/arm/mach-omap2/mux.h
index 69fe060..461b90d 100644
--- a/arch/arm/mach-omap2/mux.h
+++ b/arch/arm/mach-omap2/mux.h
@@ -225,8 +225,18 @@ omap_hwmod_mux_init(struct omap_device_pad
*bpads, int nr_pads);
*/
void omap_hwmod_mux(struct omap_hwmod_mux_info *hmux, u8 state);
+int omap_mux_get_by_name(const char *muxname,
+ struct omap_mux_partition **found_partition,
+ struct omap_mux **found_mux);
#else
+static inline int omap_mux_get_by_name(const char *muxname,
+ struct omap_mux_partition **found_partition,
+ struct omap_mux **found_mux)
+{
+ return 0;
+}
+
static inline int omap_mux_init_gpio(int gpio, int val)
{
return 0;
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 0cdd359..30a0f4e 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -120,127 +120,59 @@ static void omap_uart_set_smartidle(struct
platform_device *pdev) {}
#endif /* CONFIG_PM */
#ifdef CONFIG_OMAP_MUX
-static struct omap_device_pad default_uart1_pads[] __initdata = {
- {
- .name = uart1_cts.uart1_cts,
- .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
- },
- {
- .name = uart1_rts.uart1_rts,
- .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
- },
- {
- .name = uart1_tx.uart1_tx,
- .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
- },
- {
- .name = uart1_rx.uart1_rx,
- .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
- .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
- .idle = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
- },
-};
-static struct omap_device_pad default_uart2_pads[] __initdata = {
- {
- .name = uart2_cts.uart2_cts,
- .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
- },
- {
- .name = uart2_rts.uart2_rts,
- .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
- },
- {
- .name = uart2_tx.uart2_tx,
- .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
- },
- {
- .name = uart2_rx.uart2_rx,
- .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
- .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
- .idle = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
- },
-};
-
-static struct omap_device_pad default_uart3_pads[] __initdata = {
- {
- .name = uart3_cts_rctx.uart3_cts_rctx,
- .enable =
Re: Suspend broken on 3.3?
Paul Walmsley p...@pwsan.com writes: [...] I don't understand why a user would ever want to disable dynamic wakeups on an in-use serial port via the sysfs power/wakeup file. (Disabling wakeups from suspend is a different matter, of course.) The OMAP UART driver needs hardware wakeups to function for FIFO drain wakeups, etc. So to me it really doesn't make sense to disable those types of wakeup events, ever. But maybe you know of some use-case that I don't? No, I don't have a use-case in mind. The more I try to remember why we added support to use the sysfs wakeup attribute to manage idle, the more I think we can probably drop it now. IIRC, it was added because on most boards we used to blindly initialize all the UARTs, including default wakeup settings (we still do this on many boards.) However, now that we have a real PM-aware driver for OMAP UARTs, this should all be handled from the driver itself, so the sysfs wakeup attribute should go back to only managing wakeups from suspend and wakeups during idle should always be on for in-use UARTs. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] omap1: mux: add missing include
* Aaro Koskinen aaro.koski...@iki.fi [120408 13:26]: Fix the following build breakage in v3.4-rc2: arch/arm/mach-omap1/mux.c:89:1: error: 'FUNC_MUX_CTRL_9' undeclared here (not in a function) arch/arm/mach-omap1/mux.c:89:1: error: 'PULL_DWN_CTRL_2' undeclared here (not in a function) arch/arm/mach-omap1/mux.c:93:1: error: 'FUNC_MUX_CTRL_C' undeclared here (not in a function) etc. Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi Acked-by: Jarkko Nikula jarkko.nik...@bitmer.com --- arch/arm/mach-omap1/mux.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap1/mux.c b/arch/arm/mach-omap1/mux.c index 087dba0..e9cc52d 100644 --- a/arch/arm/mach-omap1/mux.c +++ b/arch/arm/mach-omap1/mux.c @@ -27,6 +27,7 @@ #include linux/io.h #include linux/spinlock.h +#include mach/hardware.h #include plat/mux.h Thanks for the repost, looks like I missed this one earlier. Applying to fixes. 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: PM related performance degradation on OMAP3
Grazvydas Ignotas nota...@gmail.com writes: Hello, I'm DMA seeing performance loss related to CONFIG_PM on OMAP3. # CONFIG_PM is set: echo 3 /proc/sys/vm/drop_caches # file copy from NAND (using NAND driver in DMA mode) dd if=/mnt/tmp/a of=/dev/null bs=1M count=32 33554432 bytes (32.0MB) copied, 9.088714 seconds, 3.5MB/s # file read from SD (hsmmc uses DMA) dd if=/dev/mmcblk0 of=/dev/null bs=1M count=32 33554432 bytes (32.0MB) copied, 2.065460 seconds, 15.5MB/s # CONFIG_PM not set: # NAND dd if=/mnt/tmp/a of=/dev/null bs=1M count=32 33554432 bytes (32.0MB) copied, 5.653534 seconds, 5.7MB/s # SD dd if=/dev/mmcblk0 of=/dev/null bs=1M count=32 33554432 bytes (32.0MB) copied, 1.919007 seconds, 16.7MB/s While SD card performance loss is not that bad (~7%), NAND one is worrying (~39%). I've tried disabling/enabling CONFIG_CPU_IDLE, also cpuidle states over sysfs, it did not have any significant effect. Is there something else to try? Looks like we might need a PM QoS constraint when there is DMA activity in progress. You can try doing a pm_qos_add_request() for PM_QOS_CPU_DMA_LATENCY when DMA transfers are active and I suspect that will help. I'm guessing this is caused by CPU wakeup latency to service DMA interrupts? I've noticed that if I keep CPU busy, the loss is reduced almost completely. Yeah, that suggests a QoS constraint is what's needed here. Talking about cpuidle, what's the difference between C1 and C2 states? They look mostly the same. Except for clockdomains are not allowed to idle in C1 which results in much shorter wakeup latency. Then there is omap3_do_wfi, it seems to be unconditionally putting SDRC on self-refresh, would it make sense to just do wfi in higher power states, like OMAP4 seems to be doing? Not sure what you're referring to in OMAP4. There we do WFI in every idle state. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/9] ARM: OMAP2+: gpmc: driver conversion
Hi Afzal,
On 04/06/2012 01:52 AM, Mohammed, Afzal wrote:
Hi Jon,
On Fri, Apr 06, 2012 at 01:51:41, Hunter, Jon wrote:
+struct gpmc_irq{
+ unsignedirq;
+ u32 regval;
Are you using regval to indicate the bit-mask? If so, maybe call it
bitmask instead.
Yes, bitmask would be better.
+ switch (gpmc-irq[i].regval) {
+ case GPMC_IRQ_WAIT0EDGEDETECTION:
+ case GPMC_IRQ_WAIT1EDGEDETECTION:
+ case GPMC_IRQ_WAIT2EDGEDETECTION:
+ case GPMC_IRQ_WAIT3EDGEDETECTION:
+ val = __ffs(gpmc-irq[i].regval);
+ val -= __ffs(GPMC_IRQ_WAIT0EDGEDETECTION);
+ gpmc_cs_configure(cs-cs,
+ GPMC_CONFIG_WAITPIN, val);
Why is the configuration of the wait pin done here? It is possible to
use the wait pin may be used without enabling the interrupt.
Where do you handle allocating the wait pins to ensure two devices don't
attempt to use the same one? Like how the CS are managed.
Also, where you you configure the polarity of the wait pins? I would
have thought it would make sense to have the wait pin configured as part
of the cs configuration.
I will revisit waitpin configurations.
Ok.
+ for (i = 0, j = 0, cs = gdp-cs_data; i gdp-num_cs; cs++, i++) {
+ dev-gpmc_res[j] = gpmc_setup_cs_mem(cs, gdp, gpmc);
+ if (dev-gpmc_res[j++].flags IORESOURCE_MEM)
+ j += gpmc_setup_cs_irq(gpmc, gdp, cs,
+ dev-gpmc_res + j);
+ else {
+ dev_err(gpmc-dev, error: setup for %s\n, gdp-name);
+ devm_kfree(gpmc-dev, dev-gpmc_res);
+ dev-gpmc_res = NULL;
+ dev-num_gpmc_res = 0;
+ return -EINVAL;
+ }
}
This section of code is not straight-forward to read. I see what you are
doing, but I am wondering if this could be improved.
First of all, returning a structure from a function is making this code
harder to read. Per the CodingStyle document in the kernel, it is
preferred for a function to return success or failure if the function is
an action, like a setup.
Secondly, do you need to pass cs, gdp and gpmc to gpmc_setup_cs_mem()?
It appears that gdp and gpmc are only used for prints. You could
probably avoid passing gdp and move the print to outside this function.
This section will be modified to make it clearer.
Thanks.
+ if (gpmc-num_irq GPMC_NR_IRQ) {
+ dev_warn(gpmc-dev, Insufficient interrupts for device\n);
+ return -EINVAL;
+ } else if (gpmc-num_irq GPMC_NR_IRQ)
+ gpmc-num_irq = GPMC_NR_IRQ;
Hmmm ... why not just have ...
if (gpmc-num_irq != GPMC_NR_IRQ) {
dev_warn(...);
return -EINVAL;
}
This will cause irq setup to fail if num_irq GPMC_NR_IRQ, even though
irq setup could have been done w/o any problem, only because platform
indicated willingness to accommodate more number of interrupts than
actually required for this device.
Ok, so num_irqs represents OMAP_GPMC_NR_IRQS and we are making sure we
have enough IRQs allocated by the platform.
This also raises the question why bother passing num_irq if we always
want it to be GPMC_NR_IRQ? Why not always initialise them all driver?
Because num_irq (or available irqs for fictitious irq chip) is platform
specific.
Ok, so OMAP_GPMC_NR_IRQS is defined and will not vary from device to
device, so why pass this? Why not use it directly?
Furthermore, GPMC_NR_IRQ is defined as 6 which is correct for OMAP2/3
but not for OMAP4/5, it is 5. Therefore, we need to detect whether we
are using an OMAP2/3 or OMAP4+ and set num_irqs based upon this. This
could be done in the probe and we can avoid passing this.
So we could simplify this by configuring num_irqs in the probe function
and then just make sure num_irqs is less than OMAP_GPMC_NR_IRQS above.
+ res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ if (res == NULL)
+ dev_warn(gpmc-dev, Failed to get resource: irq\n);
+ else
+ gpmc-master_irq = res-start;
Why not return an error if the IRQ is not found? We don't know if anyone
will be trying to use them.
Why do you want to do that ?
Because this indicates a BUG :-)
If someone (say NAND) wants to work with irq, and if interrupt is not
available, NAND driver can fail, and suppose smsc911x ethernet is present
and he is not using gpmc irq, if we fail here, smsc911x also would
not work, which would have worked otherwise.
It is a different matter that even NAND setup will happen properly,
even if interrupt is not available, it is only when NAND is told to
work with IRQ, it fails,
Re: [PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
Hi Vaibhav, On 04/09/2012 01:19 AM, Hiremath, Vaibhav wrote: [...] Let me summarize it here again, Currently, the timer code is using config option CONFIG_OMAP_32K_TIMER, to choose between 32ksync counter and gptimer; it is compile time option. If user wants to use gptimer for HR ticks, he must build the kernel without CONFIG_OMAP_32K_TIMER option. AM335x family of devices doesn't have 32ksync_counter available, only option here is to use gptimer for kernel clocksource and clockevents. So in order to support, multi-omap build including devices like AM335x, we must get rid of this option CONFIG_OMAP_32K_TIMER, atleast from clocksource registration perspective. So that means, we need to have some mechanism to handle or detect available clocksource runtime. Options would be, - Use HWMOD to detect availability of 32ksync_counter, else fallback to gptimer. [This was my original patch] But this restricts the use of gptimer completely on omap architecture, where we have 32ksync counter module. True, but we would always want to use the 32k timer if CONFIG_PM is specified. So what I am saying is that if a device has a 32ksync timer and CONFIG_PM is defined, we always want to use the 32ksync timer and a gptimer should never be used. So we should/must restrict the use of a gptimer is CONFIG_PM is enabled for devices that have the 32ksync timer. - So the next solution is to still keep compile time option, so that user will get to use gptimer atleast just changing the kernel config option. But, still, this is going to be kernel rebuild. - Next option came up was, register both the timers and override using kernel parameter. This will work only if, both the timers run at same rate/frequency; since we have one more layer here setup_sched_clock(), which actually can be called only once. - Next option suggested by Santosh, is to use kernel parameter as in parse it early, to make decision on if user wants to override default clocksource (32ksync) This is something will work for us and solves all above issues. What happens if PM is enabled? Can you still override the default? I don't think this should be allowed for devices with a 32ksync timer. Jon -- 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: [RESEND PATCH] ARM :OMAP2+: UART: Remove some of uart default pads
* Russ Dill russ.d...@gmail.com [120409 09:59]:
From: Govindraj.R govindraj.r...@ti.com
Date: Mon, 9 Apr 2012 15:16:52 +0530
Subject: [PATCH] ARM: OMAP2+: UART: Fix usage of default uart pads.
-static int __init
+int __init
omap_mux_get_by_name(const char *muxname,
struct omap_mux_partition **found_partition,
struct omap_mux **found_mux)
This can now be one one line:
int __init omap_mux_get_by_name(const char *muxname,
...
+ u16 tx_mode, rx_mode;
+
+ tx_mode = omap_mux_read(tx_partition, tx_mux-reg_offset);
+ rx_mode = omap_mux_read(rx_partition, rx_mux-reg_offset);
+
+ if (!(rx_mode 0x07) !(tx_mode 0x07)) {
+ default_omap_uart_pads[0].name = rx_pad_name;
+ default_omap_uart_pads[0].flags =
+ OMAP_DEVICE_PAD_REMUX |
OMAP_DEVICE_PAD_WAKEUP;
+ default_omap_uart_pads[0].enable = OMAP_PIN_INPUT |
+
OMAP_MUX_MODE0;
+ default_omap_uart_pads[0].idle = OMAP_PIN_INPUT |
+
OMAP_MUX_MODE0;
+
+ default_omap_uart_pads[1].name = tx_pad_name;
+ default_omap_uart_pads[1].enable = OMAP_PIN_OUTPUT |
+
OMAP_MUX_MODE0;
+ bdata-pads = default_omap_uart_pads;
You are assigning this variable to a structure on the stack.
+ bdata-pads_cnt =
ARRAY_SIZE(default_omap_uart_pads);
Also, maybe make that into a separate function with comments added that
we check that the default pins are muxed to uart rx and tx mode to start
with. Otherwise it's a bit hard to figure out what's going on here.
Then please split it into two patches: First one removes all the unsafe
muxing, then the second one enables wake-up events for the ports already
in uart rx/tx mode.
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
shouldn't OMAP4 keypad depend on OMAP4?
from current mainline kernel source, drivers/input/keyboard/Kconfig ... snip ... config KEYBOARD_OMAP tristate TI OMAP keypad support depends on (ARCH_OMAP1 || ARCH_OMAP2) help Say Y here if you want to use the OMAP keypad. To compile this driver as a module, choose M here: the module will be called omap-keypad. config KEYBOARD_OMAP4 tristate TI OMAP4 keypad support help Say Y here if you want to use the OMAP4 keypad. To compile this driver as a module, choose M here: the module will be called omap4-keypad. ... snip ... shouldn't that second entry depend on whatever is equivalent to OMAP4, like the entry before it? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- 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 02/17][V2] ARM: OMAP4: cpuidle - Declare the states with the driver declaration
Daniel Lezcano daniel.lezc...@linaro.org writes:
The cpuidle API allows to declare statically the states in the driver
structure. Let's use it.
We do no longer need the fill_cstate function called at runtime and
by the way adding more instructions at boot time.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
Reviewed-by: Jean Pihet j-pi...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/cpuidle44xx.c | 57 +---
1 files changed, 33 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index ee0bc50..6d86b59 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -132,21 +132,39 @@ struct cpuidle_driver omap4_idle_driver = {
.name = omap4_idle,
.owner = THIS_MODULE,
.en_core_tk_irqen = 1,
+ .states = {
+ {
+ /* C1 - CPU0 ON + CPU1 ON + MPU ON */
+ .exit_latency = 2 + 2,
+ .target_residency = 5,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .enter = omap4_enter_idle,
+ .name = C1,
+ .desc = MPUSS ON
+ },
+ {
+/* C2 - CPU0 OFF + CPU1 OFF + MPU CSWR */
+ .exit_latency = 328 + 440,
+ .target_residency = 960,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .enter = omap4_enter_idle,
+ .name = C2,
+ .desc = MPUSS CSWR,
+ },
+ {
+ /* C3 - CPU0 OFF + CPU1 OFF + MPU OSWR */
+ .exit_latency = 460 + 518,
+ .target_residency = 1100,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .enter = omap4_enter_idle,
+ .name = C3,
+ .desc = MPUSS OSWR,
+ },
+ },
+ .state_count = OMAP4_NUM_STATES,
I think you can drop OMAP4_NUM_STATES here, and just use:
.state_count = ARRAY_SIZE(omap4_idle_driver.states),
Then drop OMAP4_NUM_STATES all together in patch 3.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/17][V2] ARM: OMAP4: cpuidle - fix static omap4_idle_data declaration
Daniel Lezcano daniel.lezc...@linaro.org writes:
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
Reviewed-by: Jean Pihet j-pi...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Missing changelog.
Kevin
---
arch/arm/mach-omap2/cpuidle44xx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index cdd7932..fb0f76e 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -33,7 +33,7 @@ struct omap4_idle_statedata {
#define OMAP4_NUM_STATES 3
-struct omap4_idle_statedata omap4_idle_data[OMAP4_NUM_STATES];
+static struct omap4_idle_statedata omap4_idle_data[OMAP4_NUM_STATES];
static struct powerdomain *mpu_pd, *cpu0_pd, *cpu1_pd;
/**
--
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 07/17][V2] ARM: OMAP4: cpuidle - remove omap4_idle_data initialization at boot time
Daniel Lezcano daniel.lezc...@linaro.org writes:
We initialized it at compile time, no need to do that at boot
time.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
Reviewed-by: Jean Pihet j-pi...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/cpuidle44xx.c | 26 +-
1 files changed, 1 insertions(+), 25 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index b82f9fe..b0dd220 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -33,7 +33,7 @@ struct omap4_idle_statedata {
#define OMAP4_NUM_STATES 3
-static struct omap4_idle_statedata omap4_idle_data[] = {
+static struct omap4_idle_statedata omap4_idle_data[OMAP4_NUM_STATES] = {
You removed OMAP4_NUM_STATES usage in patch 5, why add it back here?
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: sram: fix BUG in dpll code for !PM case
* Grazvydas Ignotas nota...@gmail.com [120406 14:56]: _omap3_sram_configure_core_dpll is called when SDRC is reprogrammed, which is done regardless of CONFIG_PM setting, so we always need it's setup code too. Without this, we hit a BUG() on OMAP3 when kernel is built without CONFIG_PM: Reprogramming SDRC clock to 33200 Hz [ cut here ] kernel BUG at arch/arm/plat-omap/sram.c:342! Internal error: Oops - BUG: 0 [#1] ARM ... [c001c694] (omap3_configure_core_dpll+0x68/0x6c) from [c001b2dc] (omap3_core_dpll_m2_set_rate+0x1) [c001b2dc] (omap3_core_dpll_m2_set_rate+0x138/0x1b0) from [c001a478] (omap2_clk_set_rate+0x14/0x2) [c001a478] (omap2_clk_set_rate+0x14/0x20) from [c001c9dc] (clk_set_rate+0x54/0x74) [c001c9dc] (clk_set_rate+0x54/0x74) from [c022b9c8] (omap_sdrc_init+0x70/0x90) [c022b9c8] (omap_sdrc_init+0x70/0x90) from [c022f178] (omap3pandora_init+0x11c/0x164) [c022f178] (omap3pandora_init+0x11c/0x164) from [c022849c] (customize_machine+0x20/0x28) [c022849c] (customize_machine+0x20/0x28) from [c0225810] (do_one_initcall+0xa0/0x16c) [c0225810] (do_one_initcall+0xa0/0x16c) from [c02259e0] (kernel_init+0x104/0x1ac) [c02259e0] (kernel_init+0x104/0x1ac) from [c0009cec] (kernel_thread_exit+0x0/0x8) Looks like this was caused by the added ifdef CONFIG_PM from commit 3231fc88 (OMAP3: PM: restore SRAM functions after off-mode). 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 06/17][V2] ARM: OMAP4: cpuidle - use the omap4_idle_data variable directly
Daniel Lezcano daniel.lezc...@linaro.org writes: We are storing the 'omap4_idle_data' in the private data field of the cpuidle device. As we are using this variable only in this file, that does not really make sense. Let's use the global variable directly instead dereferencing pointers in an idle critical loop. Did you notice a performance impact before this change? Also, that simplfies the code. possibly, but at the expense of clean abstractions which IMO helps readability. Unless there is a real performance hit here (which I doubt), I'd prefer to leave this as is. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: Revert ARM: OMAP: ctrl: Fix CONTROL_DSIPHY register fields
* Archit Taneja arc...@ti.com [120409 00:15]: This reverts commit 46f8c3c7e95c0d30d95911e7975ddc4f93b3e237. The commit above swapped the DSI1_PPID and DSI2_PPID register fields in CONTROL_DSIPHY to be in sync with the newer public OMAP TRMs(after version V). With this commit, contention errors were reported on DSI lanes some OMAP4 SDPs. After probing the DSI lanes on OMAP4 SDP, it was seen that setting bits in the DSI2_PPID field was pulling up voltage on DSI1 lanes, and DSI1_PPID field was pulling up voltage on DSI2 lanes. This proves that the current version of OMAP4 TRM is incorrect, swap the position of register fields according to the older TRM versions as they were correct. Signed-off-by: Archit Taneja arc...@ti.com Tomi, care to ack this one? Tony --- .../include/mach/ctrl_module_pad_core_44xx.h |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-omap2/include/mach/ctrl_module_pad_core_44xx.h b/arch/arm/mach-omap2/include/mach/ctrl_module_pad_core_44xx.h index 1e2d332..c88420d 100644 --- a/arch/arm/mach-omap2/include/mach/ctrl_module_pad_core_44xx.h +++ b/arch/arm/mach-omap2/include/mach/ctrl_module_pad_core_44xx.h @@ -941,10 +941,10 @@ #define OMAP4_DSI2_LANEENABLE_MASK (0x7 29) #define OMAP4_DSI1_LANEENABLE_SHIFT 24 #define OMAP4_DSI1_LANEENABLE_MASK (0x1f 24) -#define OMAP4_DSI2_PIPD_SHIFT19 -#define OMAP4_DSI2_PIPD_MASK (0x1f 19) -#define OMAP4_DSI1_PIPD_SHIFT14 -#define OMAP4_DSI1_PIPD_MASK (0x1f 14) +#define OMAP4_DSI1_PIPD_SHIFT19 +#define OMAP4_DSI1_PIPD_MASK (0x1f 19) +#define OMAP4_DSI2_PIPD_SHIFT14 +#define OMAP4_DSI2_PIPD_MASK (0x1f 14) /* CONTROL_MCBSPLP */ #define OMAP4_ALBCTRLRX_FSX_SHIFT31 -- 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 11/17][V2] ARM: OMAP3: cpuidle - remove cpuidle_params_table
Daniel Lezcano daniel.lezc...@linaro.org writes:
We do not longer need the ''cpuidle_params_table' array as
we defined the states in the driver and we checked they are
all valid.
We also remove the structure definition as it is no longer used.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
Reviewed-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/cpuidle34xx.c | 28 +++-
arch/arm/mach-omap2/pm.h | 12
2 files changed, 3 insertions(+), 37 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 3f46e45..cdf1b8f 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -38,36 +38,14 @@
#ifdef CONFIG_CPU_IDLE
-/*
- * The latencies/thresholds for various C states have
- * to be configured from the respective board files.
- * These are some default values (which might not provide
- * the best power savings) used on boards which do not
- * pass these details from the board file.
- */
-static struct cpuidle_params cpuidle_params_table[] = {
- /* C1 */
- {2 + 2, 5, 1},
- /* C2 */
- {10 + 10, 30, 1},
- /* C3 */
- {50 + 50, 300, 1},
- /* C4 */
- {1500 + 1800, 4000, 1},
- /* C5 */
- {2500 + 7500, 12000, 1},
- /* C6 */
- {3000 + 8500, 15000, 1},
- /* C7 */
- {1 + 3, 30, 1},
-};
-#define OMAP3_NUM_STATES ARRAY_SIZE(cpuidle_params_table)
-
/* Mach specific information to be recorded in the C-state driver_data */
struct omap3_idle_statedata {
u32 mpu_state;
u32 core_state;
};
+
+#define OMAP3_NUM_STATES 7
+
Similar comment as for OMAP4. You should be able to git rid of this all
together now.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/17][V2] ARM: OMAP3: cpuidle - remove the 'valid' field
Daniel Lezcano daniel.lezc...@linaro.org writes:
With the previous changes all the states are valid, except
the last state which can be handled by decreasing the number
of states.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
Reviewed-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/cpuidle34xx.c | 12 +++-
1 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 11a2c23..3f46e45 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -67,7 +67,6 @@ static struct cpuidle_params cpuidle_params_table[] = {
struct omap3_idle_statedata {
u32 mpu_state;
u32 core_state;
- u8 valid;
};
struct omap3_idle_statedata omap3_idle_data[OMAP3_NUM_STATES];
@@ -191,8 +190,7 @@ static int next_valid_state(struct cpuidle_device *dev,
}
/* Check if current state is valid */
- if ((cx-valid)
- (cx-mpu_state = mpu_deepest_state)
+ if ((cx-mpu_state = mpu_deepest_state)
(cx-core_state = core_deepest_state)) {
return index;
} else {
@@ -216,8 +214,7 @@ static int next_valid_state(struct cpuidle_device *dev,
idx--;
for (; idx = 0; idx--) {
cx = cpuidle_get_statedata(dev-states_usage[idx]);
- if ((cx-valid)
- (cx-mpu_state = mpu_deepest_state)
+ if ((cx-mpu_state = mpu_deepest_state)
(cx-core_state = core_deepest_state)) {
next_index = idx;
break;
@@ -371,7 +368,6 @@ static inline struct omap3_idle_statedata
*_fill_cstate_usage(
struct omap3_idle_statedata *cx = omap3_idle_data[idx];
struct cpuidle_state_usage *state_usage = dev-states_usage[idx];
- cx-valid = cpuidle_params_table[idx].valid;
cpuidle_set_statedata(state_usage, cx);
return cx;
@@ -399,7 +395,6 @@ int __init omap3_idle_init(void)
/* C1 . MPU WFI + Core active */
cx = _fill_cstate_usage(dev, 0);
- cx-valid = 1; /* C1 is always valid */
cx-mpu_state = PWRDM_POWER_ON;
cx-core_state = PWRDM_POWER_ON;
@@ -436,14 +431,13 @@ int __init omap3_idle_init(void)
* We disable C7 state as a result.
*/
if (IS_PM34XX_ERRATUM(PM_SDRC_WAKEUP_ERRATUM_i583)) {
- cx-valid = 0;
+ drv-state_count = OMAP3_NUM_STATES - 1;
pr_warn(%s: core off state C7 disabled due to i583\n,
__func__);
I'm not too particular about this one, but it might be cleaner to just
remove this check all together. This errata already has a check in
next_valid_state() so strictly speaking, it's not needed here.
Kevin
}
cx-mpu_state = PWRDM_POWER_OFF;
cx-core_state = PWRDM_POWER_OFF;
- drv-state_count = OMAP3_NUM_STATES;
cpuidle_register_driver(omap3_idle_driver);
if (cpuidle_register_device(dev)) {
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/17][V2] ARM: OMAP3/4 : cpuidle34xx and cpuidle44xx cleanups
Daniel Lezcano daniel.lezc...@linaro.org writes: This patchset makes some cleanup on these cpuidle drivers and consolidate the code across both architecture. Thanks for this really nice cleanup. I have some comments on specific patches, but here's some general comments: Some minor comments: First, please be sure all patches have a descriptive changelog. Yes, even simple ones need changelogs. In particular, maintainers are looking for the why of a patch, not just the what or how. Second, this series introduced a couple sparse warnings: /work/kernel/omap/pm/arch/arm/mach-omap2/cpuidle44xx.c:134:1: warning: symbol 'omap4_idle_dev' was not declared. Should it be static? /work/kernel/omap/pm/arch/arm/mach-omap2/cpuidle44xx.c:136:23: warning: symbol 'omap4_idle_driver' was not declared. Should it be static? Thanks, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: omap4: hsmmc: check for null pointer
* Balaji T K balaj...@ti.com [120403 06:47]:
platform_device pdev can be NULL if CONFIG_MMC_OMAP_HS is not set.
Add check for NULL pointer
Fixes the following boot crash seen with omap4sdp and omap4panda
when MMC is disabled.
Unable to handle kernel NULL pointer dereference at virtual address 008c
pgd = c0004000
[008c] *pgd=
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in:
CPU: 0Not tainted (3.4.0-rc1-05971-ga4dfa82 #4)
PC is at omap_4430sdp_init+0x184/0x410
LR is at device_add+0x1a0/0x664
Signed-off-by: Balaji T K balaj...@ti.com
Reported-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c|6 +-
arch/arm/mach-omap2/board-omap4panda.c |6 +-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index a39fc4b..1ce771d 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -526,8 +526,12 @@ static int __init omap4_twl6030_hsmmc_init(struct
omap2_hsmmc_info *controllers)
struct omap2_hsmmc_info *c;
omap_hsmmc_init(controllers);
- for (c = controllers; c-mmc; c++)
+ for (c = controllers; c-mmc; c++) {
+ /* pdev can be null if CONFIG_MMC_OMAP_HS is not set */
+ if (!c-pdev)
+ continue;
omap4_twl6030_hsmmc_set_late_init(c-pdev-dev);
+ }
return 0;
}
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index d8c0e89..104fd6d 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -278,8 +278,12 @@ static int __init omap4_twl6030_hsmmc_init(struct
omap2_hsmmc_info *controllers)
struct omap2_hsmmc_info *c;
omap_hsmmc_init(controllers);
- for (c = controllers; c-mmc; c++)
+ for (c = controllers; c-mmc; c++) {
+ /* pdev can be null if CONFIG_MMC_OMAP_HS is not set */
+ if (!c-pdev)
+ continue;
omap4_twl6030_hsmmc_set_late_init(c-pdev-dev);
+ }
return 0;
}
Uhh cut and paste duplicate code.. Let's get rid of that while at
it. Can you please update this so we have only one copy of
omap4_twl6030_hsmmc_init in some place, maybe in one of the
arch/arm/mach-omap2/*twl*.c files?
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: [PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
On Tue, Apr 10, 2012 at 01:48:22, Hunter, Jon wrote: Hi Vaibhav, On 04/09/2012 01:19 AM, Hiremath, Vaibhav wrote: [...] Let me summarize it here again, Currently, the timer code is using config option CONFIG_OMAP_32K_TIMER, to choose between 32ksync counter and gptimer; it is compile time option. If user wants to use gptimer for HR ticks, he must build the kernel without CONFIG_OMAP_32K_TIMER option. AM335x family of devices doesn't have 32ksync_counter available, only option here is to use gptimer for kernel clocksource and clockevents. So in order to support, multi-omap build including devices like AM335x, we must get rid of this option CONFIG_OMAP_32K_TIMER, atleast from clocksource registration perspective. So that means, we need to have some mechanism to handle or detect available clocksource runtime. Options would be, - Use HWMOD to detect availability of 32ksync_counter, else fallback to gptimer. [This was my original patch] But this restricts the use of gptimer completely on omap architecture, where we have 32ksync counter module. True, but we would always want to use the 32k timer if CONFIG_PM is specified. So what I am saying is that if a device has a 32ksync timer and CONFIG_PM is defined, we always want to use the 32ksync timer and a gptimer should never be used. So we should/must restrict the use of a gptimer is CONFIG_PM is enabled for devices that have the 32ksync timer. - So the next solution is to still keep compile time option, so that user will get to use gptimer atleast just changing the kernel config option. But, still, this is going to be kernel rebuild. - Next option came up was, register both the timers and override using kernel parameter. This will work only if, both the timers run at same rate/frequency; since we have one more layer here setup_sched_clock(), which actually can be called only once. - Next option suggested by Santosh, is to use kernel parameter as in parse it early, to make decision on if user wants to override default clocksource (32ksync) This is something will work for us and solves all above issues. What happens if PM is enabled? Can you still override the default? I don't think this should be allowed for devices with a 32ksync timer. If user is overriding it explicitly, that itself means he knows what he is doing here. I too much to ask for...and unnecessary thing or expectation from SW. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
