Re: [PATCH v4 1/4] omap4 hsmmc: Adding card detect support for MMC1
Ping !!
On Wed, Sep 29, 2010 at 4:11 PM, kishore kadiyala
wrote:
> Gentle Reminder !
>
> Regards,
> Kishore
>
> On Tue, Sep 28, 2010 at 12:22 PM, kishore kadiyala
> wrote:
>> Hi Samuel,
>>
>> Could you please review this patch which touches mfd/twl6030-irq.c for
>> card detect support
>> of MMC1 controller on OMAP4.
>>
>> Regards,
>> Kishore
>>
>> On Mon, Sep 27, 2010 at 1:25 PM, kishore kadiyala
>> wrote:
>>> Cc: Samuel Ortiz
>>>
>>> On Fri, Sep 24, 2010 at 10:43 PM, kishore kadiyala
>>> wrote:
Adding card detect callback function and card detect configuration
function for MMC1 Controller on OMAP4.
Card detect configuration function does initial configuration of the
MMC Control & PullUp-PullDown registers of Phoenix.
For MMC1 Controller, card detect interrupt source is
twl6030 which is non-gpio. The card detect call back function provides
card present/absent status by reading MMC Control register present
on twl6030.
Since OMAP4 doesn't use any GPIO line as used in OMAP3 for card detect,
the suspend/resume initialization which was done in omap_hsmmc_gpio_init
previously is moved to the probe thus making it generic for both OMAP3 &
OMAP4.
Cc: Tony Lindgren
Cc: Andrew Morton
Cc: Madhusudhan Chikkature
Cc: Adrian Hunter
Signed-off-by: Kishore Kadiyala
---
arch/arm/mach-omap2/board-4430sdp.c | 7 +++-
drivers/mfd/twl6030-irq.c | 73
+++
drivers/mmc/host/omap_hsmmc.c | 4 +-
include/linux/i2c/twl.h | 31 +++
4 files changed, 112 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 9447644..a49f285 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -227,9 +227,14 @@ static int omap4_twl6030_hsmmc_late_init(struct
device *dev)
struct omap_mmc_platform_data *pdata = dev->platform_data;
/* Setting MMC1 Card detect Irq */
- if (pdev->id == 0)
+ if (pdev->id == 0) {
+ ret = twl6030_mmc_card_detect_config();
+ if (ret)
+ pr_err("Failed configuring MMC1 card detect\n");
pdata->slots[0].card_detect_irq = TWL6030_IRQ_BASE +
MMCDETECT_INTR_OFFSET;
+ pdata->slots[0].card_detect = twl6030_mmc_card_detect;
+ }
return ret;
}
diff --git a/drivers/mfd/twl6030-irq.c b/drivers/mfd/twl6030-irq.c
index 10bf228..2d3bb82 100644
--- a/drivers/mfd/twl6030-irq.c
+++ b/drivers/mfd/twl6030-irq.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
/*
* TWL6030 (unlike its predecessors, which had two level interrupt
handling)
@@ -223,6 +224,78 @@ int twl6030_interrupt_mask(u8 bit_mask, u8 offset)
}
EXPORT_SYMBOL(twl6030_interrupt_mask);
+int twl6030_mmc_card_detect_config(void)
+{
+ int ret;
+ u8 reg_val = 0;
+
+ /* Unmasking the Card detect Interrupt line for MMC1 from Phoenix
*/
+ twl6030_interrupt_unmask(TWL6030_MMCDETECT_INT_MASK,
+ REG_INT_MSK_LINE_B);
+ twl6030_interrupt_unmask(TWL6030_MMCDETECT_INT_MASK,
+ REG_INT_MSK_STS_B);
+ /*
+ * Intially Configuring MMC_CTRL for receving interrupts &
+ * Card status on TWL6030 for MMC1
+ */
+ ret = twl_i2c_read_u8(TWL6030_MODULE_ID0, ®_val,
TWL6030_MMCCTRL);
+ if (ret < 0) {
+ pr_err("twl6030: Failed to read MMCCTRL, error %d\n", ret);
+ return ret;
+ }
+ reg_val &= ~VMMC_AUTO_OFF;
+ reg_val |= SW_FC;
+ ret = twl_i2c_write_u8(TWL6030_MODULE_ID0, reg_val,
TWL6030_MMCCTRL);
+ if (ret < 0) {
+ pr_err("twl6030: Failed to write MMCCTRL, error %d\n",
ret);
+ return ret;
+ }
+
+ /* Configuring PullUp-PullDown register */
+ ret = twl_i2c_read_u8(TWL6030_MODULE_ID0, ®_val,
+ TWL6030_CFG_INPUT_PUPD3);
+ if (ret < 0) {
+ pr_err("twl6030: Failed to read CFG_INPUT_PUPD3, error
%d\n",
+
ret);
+ return ret;
+ }
+ reg_val &= ~(MMC_PU | MMC_PD);
+ ret = twl_i2c_write_u8(TWL6030_MODULE_ID0, reg_val,
+ T
Re: [PATCH 2/3 v5] musb: add musb support for AM35x
On Fri, Oct 01, 2010 at 01:33:49AM -0500, Gupta, Ajay Kumar wrote: Hi, [...] >>I couldn't fetch your gitorious tree so I just applied 14 patch set >>Manually on my branch. >> >>Anyways I will look into it and send the refreshed patch shortly. > >gitorious must be trying to make me look bad :-p > >Works like a charm here. Will try on a different laptop fine on another laptop too. Maybe you need to check your .git/config the correct address is git://gitorious.org/usb/usb.git I am using same address (http one) but fetch always fails while getting Index pack, 484a70e99b430800a9d93198bae32df155aecfc9 try to get it via git instead of http. -- balbi -- 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/2] omap: dma: Fix buffering disable bit setting for omap24xx
From: Jarkko Nikula An errata workaround for omap24xx is not setting the buffering disable bit 25 what is the purpose but channel enable bit 7 instead. Background for this fix is the DMA stalling issue with ASoC omap-mcbsp driver. Peter Ujfalusi has found an issue in recording that the DMA stall could happen if there were a buffer overrun detected by ALSA and the DMA was stopped and restarted due that. This problem is known to occur on both OMAP2420 and OMAP3. It can recover on OMAP3 after dma free, dma request and reconfiguration cycle. However, on OMAP2420 it seems that only way to recover is a reset. Problem was not visible before the commit c12abc0. That commit changed that the McBSP transmitter/receiver is released from reset only when needed. That is, only enabled McBSP transmitter without transmission was able to prevent this DMA stall problem in receiving side and underlying problem did not show up until now. McBSP transmitter itself seems to no be reason since DMA stall does not recover by enabling the transmission after stall. Debugging showed that there were a DMA write active during DMA stop time and it never completed even when restarting the DMA. Experimenting showed that the DMA buffering disable bit could be used to avoid stalling when using source synchronized transfers. However that could have performance hit and OMAP3 TRM states that buffering disable is not allowed for destination synchronized transfers so subsequent patch will implement a method to complete DMA writes when stopping. This patch is based on assumtion that complete lock-up on OMAP2420 is different but related problem. I don't have access to OMAP2420 errata but I believe this old workaround here is put for a reason but unfortunately a wrong bit was typed and problem showed up only now. Signed-off-by: Jarkko Nikula Signed-off-by: Peter Ujfalusi --- arch/arm/plat-omap/dma.c |2 +- arch/arm/plat-omap/include/plat/dma.h |1 + 2 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c index ec7eddf..7115884 100644 --- a/arch/arm/plat-omap/dma.c +++ b/arch/arm/plat-omap/dma.c @@ -1000,7 +1000,7 @@ void omap_start_dma(int lch) * This will always fail on ES1.0 */ if (cpu_is_omap24xx()) - l |= OMAP_DMA_CCR_EN; + l |= OMAP_DMA_CCR_BUFFERING_DISABLE; l |= OMAP_DMA_CCR_EN; dma_write(l, CCR(lch)); diff --git a/arch/arm/plat-omap/include/plat/dma.h b/arch/arm/plat-omap/include/plat/dma.h index af3a039..776ba44 100644 --- a/arch/arm/plat-omap/include/plat/dma.h +++ b/arch/arm/plat-omap/include/plat/dma.h @@ -335,6 +335,7 @@ #define OMAP2_DMA_MISALIGNED_ERR_IRQ (1 << 11) #define OMAP_DMA_CCR_EN(1 << 7) +#define OMAP_DMA_CCR_BUFFERING_DISABLE (1 << 25) #define OMAP_DMA_DATA_TYPE_S8 0x00 #define OMAP_DMA_DATA_TYPE_S16 0x01 -- 1.7.3 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] OMAP2/3: DMA: FIFO drain errata fixes
Hello, The following series fixes the sDMA FIFO drain issue present for OMAP2 and OMAP3, and covered by an errata. For OMAP2 the omap_start_dma had a comment about this errata, but the workaround configured wrong bit (CCR_EN instead of the correct BUFFERING_DISABLE bit). The first patch from Jarkko Nikula fixes this. For OMAP3 the suggestion is to set sDMA to NoStandby before disabling the channel, and wait for the drain to finish, than configure sDMA to SmartStandby again. The second patch implements this workaround for OMAP3. The FIFO drain problem can be reproduced on both OMAP2 and OMAP3 while using audio (capture case): Either introduce load to the CPU: nice -19 arecord -D hw:0 -M -B 1 -F 5000 -f dat > /dev/null & \ dd if=/dev/urandom of=/dev/null or suspending the arecord, and resuming it: arecord -D hw:0 -M -B 1 -F 5000 -f dat > /dev/null CTRL+Z; fg; CTRL+Z; fg; ... On OMAP2 we can not recover from this problem. The board has to be rebooted, while OMAP3 can be recovered by reseting the sDMA channel, or introducing unrelated sDMA activity (which takes sDMA out from Standby - but this is not working all the time). PS: the same errata might exist for OMAP4, but we are not able to verify it. --- Jarkko Nikula (1): omap: dma: Fix buffering disable bit setting for omap24xx Peter Ujfalusi (1): OMAP3: DMA: Errata: sDMA FIFO draining does not finish arch/arm/plat-omap/dma.c | 37 ++-- arch/arm/plat-omap/include/plat/dma.h |4 +++ 2 files changed, 38 insertions(+), 3 deletions(-) -- 1.7.3 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] OMAP3: DMA: Errata: sDMA FIFO draining does not finish
Implement the suggested workaround for OMAP3 regarding to sDMA draining
issue, when the channel is disabled on the fly.
This errata affects the following configuration:
sDMA transfer is source synchronized
Buffering is enabled
SmartStandby is selected.
The issue can be easily reproduced by creating overrun situation while
recording audio.
Either introduce load to the CPU:
nice -19 arecord -D hw:0 -M -B 1 -F 5000 -f dat > /dev/null & \
dd if=/dev/urandom of=/dev/null
or suspending the arecord, and resuming it:
arecord -D hw:0 -M -B 1 -F 5000 -f dat > /dev/null
CTRL+Z; fg; CTRL+Z; fg; ...
In case of overrun audio stops DMA, and restarts it (without reseting
the sDMA channel). When we hit this errata in stop case (sDMA drain did
not complete), at the coming start the sDMA will not going to be
operational (it is still draining).
This leads to DMA stall condition.
On OMAP3 we can recover with sDMA channel reset, it has been observed
that by introducing unrelated sDMA activity might also help (reading
from MMC for example).
The same errata exists for OMAP2, where the suggestion is to disable the
buffering to avoid this type of error.
On OMAP3 the suggestion is to set sDMA to NoStandby before disabling
the channel, and wait for the drain to finish, than configure sDMA to
SmartStandby again.
Signed-off-by: Peter Ujfalusi
---
arch/arm/plat-omap/dma.c | 35 +++-
arch/arm/plat-omap/include/plat/dma.h |3 ++
2 files changed, 36 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 7115884..590cb47 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1018,8 +1019,38 @@ void omap_stop_dma(int lch)
dma_write(0, CICR(lch));
l = dma_read(CCR(lch));
- l &= ~OMAP_DMA_CCR_EN;
- dma_write(l, CCR(lch));
+ /* OMAP3 Errata: sDMA FIFO draining does not finish */
+ if (cpu_is_omap34xx() && (l & OMAP_DMA_CCR_SEL_SRC_DST_SYNC)) {
+ int i = 0;
+ u32 sys_cf;
+
+ /* Configure No-Standby */
+ l = sys_cf = dma_read(OCP_SYSCONFIG);
+ l &= ~DMA_SYSCONFIG_MIDLEMODE_MASK;
+ l |= DMA_SYSCONFIG_MIDLEMODE(DMA_IDLEMODE_NO_IDLE);
+ dma_write(l , OCP_SYSCONFIG);
+
+ l = dma_read(CCR(lch));
+ l &= ~OMAP_DMA_CCR_EN;
+ dma_write(l, CCR(lch));
+
+ /* Wait for sDMA FIFO drain */
+ l = dma_read(CCR(lch));
+ while (i < 100 && (l & (OMAP_DMA_CCR_RD_ACTIVE |
+ OMAP_DMA_CCR_WR_ACTIVE))) {
+ udelay(5);
+ i++;
+ l = dma_read(CCR(lch));
+ }
+ if (i >= 100)
+ printk(KERN_ERR "DMA drain did not completed on "
+ "lch %d\n", lch);
+ /* Restore OCP_SYSCONFIG */
+ dma_write(sys_cf, OCP_SYSCONFIG);
+ } else {
+ l &= ~OMAP_DMA_CCR_EN;
+ dma_write(l, CCR(lch));
+ }
if (!omap_dma_in_1510_mode() && dma_chan[lch].next_lch != -1) {
int next_lch, cur_lch = lch;
diff --git a/arch/arm/plat-omap/include/plat/dma.h
b/arch/arm/plat-omap/include/plat/dma.h
index 776ba44..cf66f85 100644
--- a/arch/arm/plat-omap/include/plat/dma.h
+++ b/arch/arm/plat-omap/include/plat/dma.h
@@ -335,6 +335,9 @@
#define OMAP2_DMA_MISALIGNED_ERR_IRQ (1 << 11)
#define OMAP_DMA_CCR_EN(1 << 7)
+#define OMAP_DMA_CCR_RD_ACTIVE (1 << 9)
+#define OMAP_DMA_CCR_WR_ACTIVE (1 << 10)
+#define OMAP_DMA_CCR_SEL_SRC_DST_SYNC (1 << 24)
#define OMAP_DMA_CCR_BUFFERING_DISABLE (1 << 25)
#define OMAP_DMA_DATA_TYPE_S8 0x00
--
1.7.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/3 v5] musb: add musb support for AM35x
Hi, [...] > >>I couldn't fetch your gitorious tree so I just applied 14 patch set > >>Manually on my branch. > >> > >>Anyways I will look into it and send the refreshed patch shortly. > > > >gitorious must be trying to make me look bad :-p > > > >Works like a charm here. Will try on a different laptop > > fine on another laptop too. Maybe you need to check your .git/config > > the correct address is git://gitorious.org/usb/usb.git I am using same address (http one) but fetch always fails while getting Index pack, 484a70e99b430800a9d93198bae32df155aecfc9 Retrying.. -Ajay > > -- > balbi -- 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 v5] musb: add musb support for AM35x
On Fri, Oct 01, 2010 at 01:23:18AM -0500, Balbi, Felipe wrote: On Fri, Oct 01, 2010 at 01:21:33AM -0500, Gupta, Ajay Kumar wrote: Hi, On Thu, Sep 30, 2010 at 12:19:08AM -0500, Gupta, Ajay Kumar wrote: >AM35x has musb interface and uses CPPI4.1 DMA engine. >Current patch supports only PIO mode. DMA support can be >added later once basic CPPI4.1 DMA patch is accepted. > >Also added USB_MUSB_AM35X which is required to differentiate musb ips >between OMAP3x and AM35x. This config would be used to for below >purposes, >- Select am35x.c instead of omap2430.c for compilation > at drivers/usb/musb directory. Please note there are > significant differneces in these two files as musb ip > in quite different on AM35x. >- Select workaround codes applicable for AM35x musb issues. > one such workaround is for bytewise read issue on AM35x. > >Signed-off-by: Ajay Kumar Gupta this one doesn't apply of top of my musb-2.6.37 branch. [...] could you refresh and resend this one ?? I couldn't fetch your gitorious tree so I just applied 14 patch set Manually on my branch. Anyways I will look into it and send the refreshed patch shortly. gitorious must be trying to make me look bad :-p Works like a charm here. Will try on a different laptop fine on another laptop too. Maybe you need to check your .git/config the correct address is git://gitorious.org/usb/usb.git -- balbi -- 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 v5] musb: add musb support for AM35x
On Fri, Oct 01, 2010 at 01:21:33AM -0500, Gupta, Ajay Kumar wrote: Hi, On Thu, Sep 30, 2010 at 12:19:08AM -0500, Gupta, Ajay Kumar wrote: >AM35x has musb interface and uses CPPI4.1 DMA engine. >Current patch supports only PIO mode. DMA support can be >added later once basic CPPI4.1 DMA patch is accepted. > >Also added USB_MUSB_AM35X which is required to differentiate musb ips >between OMAP3x and AM35x. This config would be used to for below >purposes, >- Select am35x.c instead of omap2430.c for compilation > at drivers/usb/musb directory. Please note there are > significant differneces in these two files as musb ip > in quite different on AM35x. >- Select workaround codes applicable for AM35x musb issues. > one such workaround is for bytewise read issue on AM35x. > >Signed-off-by: Ajay Kumar Gupta this one doesn't apply of top of my musb-2.6.37 branch. [...] could you refresh and resend this one ?? I couldn't fetch your gitorious tree so I just applied 14 patch set Manually on my branch. Anyways I will look into it and send the refreshed patch shortly. gitorious must be trying to make me look bad :-p Works like a charm here. Will try on a different laptop -- balbi -- 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 v5] musb: add musb support for AM35x
Hi, > On Thu, Sep 30, 2010 at 12:19:08AM -0500, Gupta, Ajay Kumar wrote: > >AM35x has musb interface and uses CPPI4.1 DMA engine. > >Current patch supports only PIO mode. DMA support can be > >added later once basic CPPI4.1 DMA patch is accepted. > > > >Also added USB_MUSB_AM35X which is required to differentiate musb ips > >between OMAP3x and AM35x. This config would be used to for below > >purposes, > >- Select am35x.c instead of omap2430.c for compilation > > at drivers/usb/musb directory. Please note there are > > significant differneces in these two files as musb ip > > in quite different on AM35x. > >- Select workaround codes applicable for AM35x musb issues. > > one such workaround is for bytewise read issue on AM35x. > > > >Signed-off-by: Ajay Kumar Gupta > > this one doesn't apply of top of my musb-2.6.37 branch. [...] > could you refresh and resend this one ?? I couldn't fetch your gitorious tree so I just applied 14 patch set Manually on my branch. Anyways I will look into it and send the refreshed patch shortly. Thanks, Ajay > [...] -- 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 v5] AM35x: Add musb support
Hi,
> On Thu, Sep 30, 2010 at 12:19:07AM -0500, Gupta, Ajay Kumar wrote:
> >AM35x has musb interface (version 1.8) and uses CPPI41 DMA engine.
> >It has USB phy built inside the IP itself.
> >
> >Signed-off-by: Ajay Kumar Gupta
>
> besides the one small question below:
>
> Acked-by: Felipe Balbi
>
> (note that I don't have that board to fully test this patch)
>
> >+static struct omap_musb_board_data musb_board_data = {
> >+.interface_type = MUSB_INTERFACE_ULPI,
> >+.mode = MUSB_OTG,
> >+.power = 500,
> can this board really source 500mA ??
Yes, it supports upto 500mA same as OMAP3EVM (Rev-G).
-Ajay
>
> --
> balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP: Fix compilation warnings
From: Pramod Gurav
---
arch/arm/mach-omap2/board-omap4panda.c |2 --
arch/arm/mach-omap2/mux.c |2 +-
arch/arm/plat-omap/gpio.c |4 ++--
3 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index c03d1d5..96f5bbb 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -274,8 +274,6 @@ static int __init omap4_panda_i2c_init(void)
}
static void __init omap4_panda_init(void)
{
- int status;
-
omap4_panda_i2c_init();
omap_serial_init();
omap4_twl6030_hsmmc_init(mmc);
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index ab403b2..6c2f8f0 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -87,7 +87,7 @@ static char *omap_mux_options;
int __init omap_mux_init_gpio(int gpio, int val)
{
struct omap_mux_entry *e;
- struct omap_mux *gpio_mux;
+ struct omap_mux *gpio_mux = NULL;
u16 old_mode;
u16 mux_mode;
int found = 0;
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index f6c03a7..22f175f 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -2223,7 +2223,7 @@ void omap2_gpio_prepare_for_idle(int power_state)
for (i = min; i < gpio_bank_count; i++) {
struct gpio_bank *bank = &gpio_bank[i];
- u32 l1, l2;
+ u32 l1 = 0, l2 = 0;
int j;
for (j = 0; j < hweight_long(bank->dbck_enable_mask); j++)
@@ -2291,7 +2291,7 @@ void omap2_gpio_resume_after_idle(void)
min = 1;
for (i = min; i < gpio_bank_count; i++) {
struct gpio_bank *bank = &gpio_bank[i];
- u32 l, gen, gen0, gen1;
+ u32 l = 0, gen, gen0, gen1;
int j;
for (j = 0; j < hweight_long(bank->dbck_enable_mask); j++)
--
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: [omap3] Nand flash initialisation error
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of GERBER Patrick
> Sent: Wednesday, September 29, 2010 7:35 PM
> To: GERBER Patrick; linux-omap@vger.kernel.org
> Subject: RE : [omap3] Nand flash initialisation error
>
> In complement to my previous mail I have found that if I only add a call
> to gpmc_cs_request the info->phys_base is well initialized.
> So I could after call the platform_device_register as usual.
[Ghorai] I am agree with your. You can -
408 //if (platform_device_register(&omap3beagle_nand_device) < 0)
409 if (gpmc_nand_init(&omap3beagle_nand_data) < 0)
>
> Anyway I still have the bogus (but working) detection of the flash:
>
> NAND device: Manufacturer ID: 0x2c, Chip ID: 0xba (Micron omap2-nand.0)
> NAND bus width 8 instead 16 bit
> No NAND device found.
> NAND device: Manufacturer ID: 0x2c, Chip ID: 0xba (Micron NAND 256MiB 1,8V
> 16-bit)
>
> Any idea ?
[Ghorai] This is ok .. because _probe is common for all omap board. And they
have different NAND in different platform; and its check for any 8x nand preset
and followed by check if any 16x device preset. And code as followes.
877 static int __devinit omap_nand_probe(struct platform_device *pdev)
..
998 if (nand_scan(&info->mtd, 1)) {
999 info->nand.options ^= NAND_BUSWIDTH_16;
1000 if (nand_scan(&info->mtd, 1)) {
>
[Ghorai] Are you still facing any issue other then this detection log?
>
> De : linux-omap-ow...@vger.kernel.org [linux-omap-ow...@vger.kernel.org]
> de la part de GERBER Patrick [patrick.ger...@heig-vd.ch]
> Date d'envoi : mercredi, 29. septembre 2010 14:05
> À : linux-omap@vger.kernel.org
> Objet : [omap3] Nand flash initialisation error
>
> Hello,
>
> I am using 2.6.34.5 vanilla kernel on a gumstix over Fire using OMAP3530.
> I have some problems wit the nand flash (the chip on the top of the OMAP).
> The MTD partition is not created.
>
> When booting the board code is well detecting a Nand on CS0 and call the
> platform_device_register.
> The omap_nand_probe() fail with -16 (EBUSY) after calling
> request_mem_region() with 0 as a base address.
> So the info->phys_base is not initialized.
>
> After looking in older kernel I have tried to add a call
> gpmc_nand_init(&overo_nand_data) in my board code instead of the call to
> platform_device_register.
> With this addition the Flash is well detected and the mtd partition
> created.
> But there is some errors due to misconfiguration of the flash (bus width,
> detecting twice, ...). Of course my platform_device structure is not used
> because I have to pass only the omap_nand_platform_data struct to
> gpmc_nand_init().
>
> (the ## prefixed lines are personal debug addition)
>
> ...
> Found NAND on CS0
> ## gpmc_baseaddr 0xfe00, gpmc_cs_baseaddr 0xfe60
> Registering NAND on CS0
> ...
> omap2-nand driver initializing
> ## omap_nand_probe
> NAND device: Manufacturer ID: 0x2c, Chip ID: 0xba (Micron omap2-nand.0)
> NAND bus width 8 instead 16 bit
> No NAND device found.
> NAND device: Manufacturer ID: 0x2c, Chip ID: 0xba (Micron NAND 256MiB 1,8V
> 16-bit)
> cmdlinepart partition parsing not available
> Creating 5 MTD partitions on "omap2-nand.0":
> ...
>
>
> I have looked on other board initialization (beagle, igep, ...) and the
> code seems pretty similar.
> I would like to know if the call to gpmc_nand_init() is still necessary
> and why the detection is so hesitant ?
> I'd rather use the platform_device_register() but I dont understand why
> the info->phys_base is 0 ?!?
>
> Thanks in advance for any help.
>
> Patrick--
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3 v5] musb: add musb support for AM35x
On Thu, Sep 30, 2010 at 12:19:08AM -0500, Gupta, Ajay Kumar wrote: AM35x has musb interface and uses CPPI4.1 DMA engine. Current patch supports only PIO mode. DMA support can be added later once basic CPPI4.1 DMA patch is accepted. Also added USB_MUSB_AM35X which is required to differentiate musb ips between OMAP3x and AM35x. This config would be used to for below purposes, - Select am35x.c instead of omap2430.c for compilation at drivers/usb/musb directory. Please note there are significant differneces in these two files as musb ip in quite different on AM35x. - Select workaround codes applicable for AM35x musb issues. one such workaround is for bytewise read issue on AM35x. Signed-off-by: Ajay Kumar Gupta this one doesn't apply of top of my musb-2.6.37 branch. patching file drivers/usb/musb/Kconfig Hunk #1 succeeded at 60 with fuzz 2. Hunk #2 FAILED at 158. 1 out of 2 hunks FAILED -- saving rejects to file drivers/usb/musb/Kconfig.rej patching file drivers/usb/musb/Makefile Hunk #1 FAILED at 23. 1 out of 1 hunk FAILED -- saving rejects to file drivers/usb/musb/Makefile.rej patching file drivers/usb/musb/am35x.c patching file drivers/usb/musb/musb_core.h Hunk #1 FAILED at 330. 1 out of 1 hunk FAILED -- saving rejects to file drivers/usb/musb/musb_core.h.rej could you refresh and resend this one ?? -- balbi -- 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 v5] AM35x: Add musb support
Hi,
On Thu, Sep 30, 2010 at 12:19:07AM -0500, Gupta, Ajay Kumar wrote:
AM35x has musb interface (version 1.8) and uses CPPI41 DMA engine.
It has USB phy built inside the IP itself.
Signed-off-by: Ajay Kumar Gupta
besides the one small question below:
Acked-by: Felipe Balbi
(note that I don't have that board to fully test this patch)
+static struct omap_musb_board_data musb_board_data = {
+ .interface_type = MUSB_INTERFACE_ULPI,
+ .mode = MUSB_OTG,
+ .power = 500,
can this board really source 500mA ??
--
balbi
--
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 6/17] dmtimer: add omap44xx hwmod database
> -Original Message- > To: DebBarma, Tarun Kanti > Cc: linux-omap@vger.kernel.org; Gopinath, Thara; Basak, > Partha; Paul Walmsley; Kevin Hilman; Tony Lindgren > Subject: Re: [PATCHv3 6/17] dmtimer: add omap44xx hwmod database <> > > --- > > arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 660 > > > 1 files changed, 660 insertions(+), 0 deletions(-) > > > > diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c > b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c > > index e20b0ee..28d65e9 100644 > > --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c > > +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c > > @@ -23,6 +23,8 @@ > > #include > > #include > > > > +#include > > +#include Why omap_device.h is required in hwmod database? -V Charulatha > > #include "omap_hwmod_common_data.h" > > > > #include "cm.h" <> -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v6 8/8] Input: omap4 - pm runtime
Abraham, > -Original Message- > To: Arce, Abraham > Cc: linux-in...@vger.kernel.org; linux-omap@vger.kernel.org > Subject: Re: [PATCH v6 8/8] Input: omap4 - pm runtime > > Abraham Arce writes: > > > Enable pm runtime in driver > > So power is enabled on probe and cut on _remove(). Did you consider > doing any more fine grained PM for this device? For example, cutting > power after some inactivity timer and re-enabling on a > keypress/interrupt? > > Kevin > > > > > Reviewed-by: Basak, Partha > > Signed-off-by: Abraham Arce > > --- > > drivers/input/keyboard/omap4-keypad.c |7 +++ > > 1 files changed, 7 insertions(+), 0 deletions(-) > > > > diff --git a/drivers/input/keyboard/omap4-keypad.c > b/drivers/input/keyboard/omap4-keypad.c > > index 45bd097..ed47e9a 100644 > > --- a/drivers/input/keyboard/omap4-keypad.c > > +++ b/drivers/input/keyboard/omap4-keypad.c > > @@ -29,6 +29,7 @@ > > #include > > #include > > #include > > +#include > > > > #include > > > > @@ -239,6 +240,9 @@ static int __devinit > omap4_keypad_probe(struct platform_device *pdev) > > matrix_keypad_build_keymap(pdata->keymap_data, row_shift, > > input_dev->keycode, input_dev->keybit); > > > > + pm_runtime_enable(&pdev->dev); > > + pm_runtime_get_sync(&pdev->dev); In patch 1, kbd is included in the hwmods list. Hence kbd would be reset during init and clocks would be disabled. Probe is not doing any clock enable before accessing the kbd registers. Later, only in this patch, pm_runtime_get_sync() is being done. Ideally, once the kbd is included in the hwmod list, clock_enable() shall be used before accessing kbd registers and later in this patch pm_runtime_get_sync() shall be used while removing usage of clk_enable(). -V Charulatha > > + > > omap4_keypad_config(keypad_data); > > > > error = request_irq(keypad_data->irq, omap4_keypad_interrupt, > > @@ -277,6 +281,9 @@ static int __devexit > omap4_keypad_remove(struct platform_device *pdev) > > struct omap4_keypad *keypad_data = platform_get_drvdata(pdev); > > struct resource *res; > > > > + pm_runtime_put_sync(&pdev->dev); > > + pm_runtime_disable(&pdev->dev); > > + > > free_irq(keypad_data->irq, keypad_data); > > input_unregister_device(keypad_data->input); -- 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/17] OMAP2/3/4:dmtimer:add device names to flck nodes
Benoit, <> > > > > This patch adds device name info to OMAP2 dmtimer fclk nodes so > > You should avoid using "that patch" in a changelog, since we already > know it is a patch. > > You can read 4.c in "The perfect patch" from Andrew Morton: > http://userweb.kernel.org/~akpm/stuff/tpp.txt > Referring to 6.b section in the above link, is it a bad idea to have a cover-letter? Should we better include the content of introductory email in patch 1 of any patch series? <> -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap: Keep nwires for omap1 and 2420 MMC controller (Re: [PATCH] omap mmc: extended to pass host capabilities from board file)
> -Original Message-
> From: Tony Lindgren [mailto:t...@atomide.com]
> Sent: Friday, October 01, 2010 12:08 AM
> To: Ghorai, Sukumar
> Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org
> Subject: [PATCH] omap: Keep nwires for omap1 and 2420 MMC controller (Re:
> [PATCH] omap mmc: extended to pass host capabilities from board file)
>
> * Tony Lindgren [100923 16:00]:
> > * Sukumar Ghorai [100915 07:41]:
> > > wires variable is renamed, extended and this single variable to be
> used to
> > > pass the platform capabilities, e.g DDR mode. Also removed the
> hardcoded
> > > value was using as bus-width.
> >
> > This looks like a nice clean-up, I'll queue this via the omap
> > patches.
>
> And of course this patch breaks all of mach-omap1 and omap2420.
>
> Sukumar, your patch modified also drivers/mmc/host/omap.c and board-n8x0.c
> to use caps instead of nwires. When you do things like that you absolutely
> _must_test_your_changes_ before sending out any patches.
>
> Planning on merging the following fix.
>
> Tony
>
> From: Tony Lindgren
> Date: Thu, 30 Sep 2010 10:25:46 -0700
> Subject: [PATCH] Subject: [PATCH] omap: Keep nwires for omap1 and 2420 MMC
> controller
>
> A patch from Sukumar Ghorai changed the
> nwires to use caps instead. However, nwires is still
> needed for the earlier controller.
>
> Signed-off-by: Tony Lindgren
>
> diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-
> n8x0.c
> index abd7e77..6bd9d9a 100644
> --- a/arch/arm/mach-omap2/board-n8x0.c
> +++ b/arch/arm/mach-omap2/board-n8x0.c
> @@ -488,7 +488,7 @@ static struct omap_mmc_platform_data mmc1_data = {
> .max_freq = 2400,
> .dma_mask = 0x,
> .slots[0] = {
> - .caps = MMC_CAP_4_BIT_DATA,
> + .wires = 4,
> .set_power = n8x0_mmc_set_power,
> .set_bus_mode = n8x0_mmc_set_bus_mode,
> .get_cover_state= n8x0_mmc_get_cover_state,
> diff --git a/arch/arm/plat-omap/include/plat/mmc.h b/arch/arm/plat-
> omap/include/plat/mmc.h
> index 4f819fc..bc85010 100644
> --- a/arch/arm/plat-omap/include/plat/mmc.h
> +++ b/arch/arm/plat-omap/include/plat/mmc.h
> @@ -73,9 +73,16 @@ struct omap_mmc_platform_data {
>
> struct omap_mmc_slot_data {
>
> - /* 4/8 wires and any additional host capabilities
> - * need to OR'd all capabilities (ref. linux/mmc/host.h) */
> - u32 caps;
> + /*
> + * 4/8 wires and any additional host capabilities
> + * need to OR'd all capabilities (ref. linux/mmc/host.h)
> + */
> +#if defined(CONFIG_ARCH_OMAP1) || defined(CONFIG_ARCH_OMAP2420)
> + u8 wires; /* Used for the MMC driver on omap1 and 2420 */
> +#endif
> +#ifdef CONFIG_ARCH_OMAP2PLUS
> + u32 caps; /* Used for the MMC driver on 2430 and later */
> +#endif
>
> /*
>* nomux means "standard" muxing is wrong on this board, and
> diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
> index a9d62cf..d98ddcf 100644
> --- a/drivers/mmc/host/omap.c
> +++ b/drivers/mmc/host/omap.c
> @@ -1317,7 +1317,7 @@ static int __init mmc_omap_new_slot(struct
> mmc_omap_host *host, int id)
> host->slots[id] = slot;
>
> mmc->caps = 0;
> - if (host->pdata->slots[id].caps & MMC_CAP_8_BIT_DATA)
> + if (host->pdata->slots[id].wires >= 4)
> mmc->caps |= MMC_CAP_4_BIT_DATA;
>
> mmc->ops = &mmc_omap_ops;
[Ghorai] thanks.. I am agreeing with you;
Acked-by: Sukumar Ghorai
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] scatterlist: define SG chain for arm architecture
Please discard this patch, it should have sent to linux-arm list. Regards, Fernando. > > > From: Guzman Lugo, Fernando > Sent: Thursday, September 30, 2010 10:22 PM > To: t...@atomide.com > Cc: hiroshi.d...@nokia.com; linux-ker...@vger.kernel.org; linux-o...@vger.ke > rnel.org; Guzman Lugo, Fernando > Subject: [PATCH] scatterlist: define SG chain for arm architecture > > Define SG chain for ARM architecture in order to work > with big buffers. This patch is needed in order to > iovmm users can pass a big buffer to map it and ARM > architecture has not issues using SG chain. > > This change was suggested by FUJITA Tomonori. > > Signed-off-by: Fernando Guzman Lugo > --- > arch/arm/include/asm/scatterlist.h |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/include/asm/scatterlist.h b/arch/arm/include/asm/scatt > erlist.h > index 2f87870..3de0a0b 100644 > --- a/arch/arm/include/asm/scatterlist.h > +++ b/arch/arm/include/asm/scatterlist.h > @@ -5,4 +5,6 @@ > #include > #include > > +#define ARCH_HAS_SG_CHAIN > + > #endif /* _ASMARM_SCATTERLIST_H */ > -- > 1.6.3.3 > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] scatterlist: define SG chain for arm architecture
Define SG chain for ARM architecture in order to work with big buffers. This patch is needed in order to iovmm users can pass a big buffer to map it and ARM architecture has not issues using SG chain. This change was suggested by FUJITA Tomonori. Signed-off-by: Fernando Guzman Lugo --- arch/arm/include/asm/scatterlist.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/include/asm/scatterlist.h b/arch/arm/include/asm/scatterlist.h index 2f87870..3de0a0b 100644 --- a/arch/arm/include/asm/scatterlist.h +++ b/arch/arm/include/asm/scatterlist.h @@ -5,4 +5,6 @@ #include #include +#define ARCH_HAS_SG_CHAIN + #endif /* _ASMARM_SCATTERLIST_H */ -- 1.6.3.3 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] iovmm: fixes for iovmm module
This patches are needed in order to tidspbridge can use iovmm with no issues. Fernando Guzman Lugo (4): iommu: remove CONFIG_MPU_BRIDGE_IOMMU iovmm: fix roundup for next area and end check for the last area iovmm: add superpages support to fixed da address iovmm: replace __iounmap with omap_iounmap arch/arm/mach-omap2/omap-iommu.c |2 - arch/arm/plat-omap/iovmm.c | 69 ++--- 2 files changed, 41 insertions(+), 30 deletions(-) mode change 100644 => 100755 arch/arm/plat-omap/iovmm.c -- 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] iovmm: add superpages support to fixed da address
This patch adds superpages support to fixed ad address
inside iommu_kmap function.
Signed-off-by: Fernando Guzman Lugo
---
arch/arm/plat-omap/iovmm.c | 61 ++-
1 files changed, 37 insertions(+), 24 deletions(-)
diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
index fc6b109..e7ffec8 100644
--- a/arch/arm/plat-omap/iovmm.c
+++ b/arch/arm/plat-omap/iovmm.c
@@ -87,27 +87,37 @@ static size_t sgtable_len(const struct sg_table *sgt)
}
#define sgtable_ok(x) (!!sgtable_len(x))
+
+static unsigned max_alignment(u32 addr)
+{
+ int i;
+ unsigned pagesize[] = { SZ_16M, SZ_1M, SZ_64K, SZ_4K, };
+ for (i = 0; i < ARRAY_SIZE(pagesize) && addr & (pagesize[i] - 1); i++)
+ ;
+ return (i < ARRAY_SIZE(pagesize)) ? pagesize[i] : 0;
+}
+
+
/*
* calculate the optimal number sg elements from total bytes based on
* iommu superpages
*/
-static unsigned int sgtable_nents(size_t bytes)
+static unsigned int sgtable_nents(size_t bytes, u32 da, u32 pa)
{
- int i;
- unsigned int nr_entries;
- const unsigned long pagesize[] = { SZ_16M, SZ_1M, SZ_64K, SZ_4K, };
+ unsigned int nr_entries = 0, ent_sz;
if (!IS_ALIGNED(bytes, PAGE_SIZE)) {
pr_err("%s: wrong size %08x\n", __func__, bytes);
return 0;
}
- nr_entries = 0;
- for (i = 0; i < ARRAY_SIZE(pagesize); i++) {
- if (bytes >= pagesize[i]) {
- nr_entries += (bytes / pagesize[i]);
- bytes %= pagesize[i];
- }
+ while (bytes) {
+ ent_sz = max_alignment(da | pa);
+ ent_sz = min(ent_sz, (unsigned)iopgsz_max(bytes));
+ nr_entries++;
+ da += ent_sz;
+ pa += ent_sz;
+ bytes -= ent_sz;
}
BUG_ON(bytes);
@@ -115,7 +125,8 @@ static unsigned int sgtable_nents(size_t bytes)
}
/* allocate and initialize sg_table header(a kind of 'superblock') */
-static struct sg_table *sgtable_alloc(const size_t bytes, u32 flags)
+static struct sg_table *sgtable_alloc(const size_t bytes, u32 flags,
+ u32 da, u32 pa)
{
unsigned int nr_entries;
int err;
@@ -127,9 +138,8 @@ static struct sg_table *sgtable_alloc(const size_t bytes,
u32 flags)
if (!IS_ALIGNED(bytes, PAGE_SIZE))
return ERR_PTR(-EINVAL);
- /* FIXME: IOVMF_DA_FIXED should support 'superpages' */
- if ((flags & IOVMF_LINEAR) && (flags & IOVMF_DA_ANON)) {
- nr_entries = sgtable_nents(bytes);
+ if (flags & IOVMF_LINEAR) {
+ nr_entries = sgtable_nents(bytes, da, pa);
if (!nr_entries)
return ERR_PTR(-EINVAL);
} else
@@ -409,7 +419,8 @@ static inline void sgtable_drain_vmalloc(struct sg_table
*sgt)
BUG_ON(!sgt);
}
-static void sgtable_fill_kmalloc(struct sg_table *sgt, u32 pa, size_t len)
+static void sgtable_fill_kmalloc(struct sg_table *sgt, u32 pa, u32 da,
+ size_t len)
{
unsigned int i;
struct scatterlist *sg;
@@ -420,7 +431,8 @@ static void sgtable_fill_kmalloc(struct sg_table *sgt, u32
pa, size_t len)
for_each_sg(sgt->sgl, sg, sgt->nents, i) {
size_t bytes;
- bytes = iopgsz_max(len);
+ bytes = max_alignment(da | pa);
+ bytes = min(bytes, (size_t)iopgsz_max(len));
BUG_ON(!iopgsz_ok(bytes));
@@ -429,6 +441,7 @@ static void sgtable_fill_kmalloc(struct sg_table *sgt, u32
pa, size_t len)
* 'pa' is cotinuous(linear).
*/
pa += bytes;
+ da += bytes;
len -= bytes;
}
BUG_ON(len);
@@ -695,18 +708,18 @@ u32 iommu_vmalloc(struct iommu *obj, u32 da, size_t
bytes, u32 flags)
if (!va)
return -ENOMEM;
- sgt = sgtable_alloc(bytes, flags);
+ flags &= IOVMF_HW_MASK;
+ flags |= IOVMF_DISCONT;
+ flags |= IOVMF_ALLOC;
+ flags |= (da ? IOVMF_DA_FIXED : IOVMF_DA_ANON);
+
+ sgt = sgtable_alloc(bytes, flags, da, 0);
if (IS_ERR(sgt)) {
da = PTR_ERR(sgt);
goto err_sgt_alloc;
}
sgtable_fill_vmalloc(sgt, va);
- flags &= IOVMF_HW_MASK;
- flags |= IOVMF_DISCONT;
- flags |= IOVMF_ALLOC;
- flags |= (da ? IOVMF_DA_FIXED : IOVMF_DA_ANON);
-
da = __iommu_vmap(obj, da, sgt, va, bytes, flags);
if (IS_ERR_VALUE(da))
goto err_iommu_vmap;
@@ -746,11 +759,11 @@ static u32 __iommu_kmap(struct iommu *obj, u32 da, u32
pa, void *va,
{
struct sg_table *sgt;
- sgt = sgtable_alloc(bytes, flags);
+ sgt = sgtable_alloc(bytes, flags, da, pa);
if (IS_ERR(sgt))
[PATCH 1/4] iommu: remove CONFIG_MPU_BRIDGE_IOMMU
remove CONFIG_MPU_BRIDGE_IOMMU in order to create iommu_device
for iva2.
Signed-off-by: Fernando Guzman Lugo
---
arch/arm/mach-omap2/omap-iommu.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index f5a1aad..bb8c01d 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -35,7 +35,6 @@ static struct iommu_device omap3_devices[] = {
.clk_name = "cam_ick",
},
},
-#if defined(CONFIG_MPU_BRIDGE_IOMMU)
{
.base = 0x5d00,
.irq = 28,
@@ -45,7 +44,6 @@ static struct iommu_device omap3_devices[] = {
.clk_name = "iva2_ck",
},
},
-#endif
};
#define NR_OMAP3_IOMMU_DEVICES ARRAY_SIZE(omap3_devices)
static struct platform_device *omap3_iommu_pdev[NR_OMAP3_IOMMU_DEVICES];
--
1.6.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] iovmm: replace __iounmap with omap_iounmap
Omap platform is omap_iounmap function. Signed-off-by: Fernando Guzman Lugo --- arch/arm/plat-omap/iovmm.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) mode change 100644 => 100755 arch/arm/plat-omap/iovmm.c diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c old mode 100644 new mode 100755 index e7ffec8..326776d --- a/arch/arm/plat-omap/iovmm.c +++ b/arch/arm/plat-omap/iovmm.c @@ -824,7 +824,7 @@ void iommu_kunmap(struct iommu *obj, u32 da) struct sg_table *sgt; typedef void (*func_t)(const void *); - sgt = unmap_vm_area(obj, da, (func_t)__iounmap, + sgt = unmap_vm_area(obj, da, (func_t)omap_iounmap, IOVMF_LINEAR | IOVMF_MMIO); if (!sgt) dev_dbg(obj->dev, "%s: No sgt\n", __func__); -- 1.6.3.3 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] iovmm: fix roundup for next area and end check for the last area
As da_end does not belongs to the area the roundup should
be done to da_end and not to da_end + 1.
Also the end check for the last area should be
ULONG_MAX - start + 1 >= bytes.
Signed-off-by: Fernando Guzman Lugo
---
arch/arm/plat-omap/iovmm.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
index 24ca9c4..fc6b109 100644
--- a/arch/arm/plat-omap/iovmm.c
+++ b/arch/arm/plat-omap/iovmm.c
@@ -289,19 +289,19 @@ static struct iovm_struct *alloc_iovm_area(struct iommu
*obj, u32 da,
prev_end = 0;
list_for_each_entry(tmp, &obj->mmap, list) {
- if (prev_end >= start)
+ if (prev_end > start)
break;
if (start + bytes <= tmp->da_start)
goto found;
if (flags & IOVMF_DA_ANON)
- start = roundup(tmp->da_end + 1, alignement);
+ start = roundup(tmp->da_end, alignement);
prev_end = tmp->da_end;
}
- if ((start > prev_end) && (ULONG_MAX - start >= bytes))
+ if ((start >= prev_end) && (ULONG_MAX - start + 1 >= bytes))
goto found;
dev_dbg(obj->dev, "%s: no space to fit %08x(%x) flags: %08x\n",
--
1.6.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 11/11] staging: tidspbridge - remove dmm custom module
Dmm custom module is not needed anymore.
Signed-off-by: Fernando Guzman Lugo
---
drivers/staging/tidspbridge/Makefile |2 +-
drivers/staging/tidspbridge/core/tiomap3430.c |1 -
.../staging/tidspbridge/include/dspbridge/dev.h| 24 -
.../staging/tidspbridge/include/dspbridge/dmm.h| 75 ---
.../staging/tidspbridge/include/dspbridge/drv.h|6 -
drivers/staging/tidspbridge/pmgr/dev.c | 61 +---
drivers/staging/tidspbridge/pmgr/dmm.c | 533
drivers/staging/tidspbridge/rmgr/node.c| 28 +-
drivers/staging/tidspbridge/rmgr/proc.c| 23 -
9 files changed, 6 insertions(+), 747 deletions(-)
delete mode 100644 drivers/staging/tidspbridge/include/dspbridge/dmm.h
delete mode 100644 drivers/staging/tidspbridge/pmgr/dmm.c
diff --git a/drivers/staging/tidspbridge/Makefile
b/drivers/staging/tidspbridge/Makefile
index bd36651..7c122fa 100644
--- a/drivers/staging/tidspbridge/Makefile
+++ b/drivers/staging/tidspbridge/Makefile
@@ -5,7 +5,7 @@ libcore = core/chnl_sm.o core/msg_sm.o core/io_sm.o
core/tiomap3430.o \
core/tiomap3430_pwr.o core/tiomap_io.o core/dsp-mmu.o \
core/ue_deh.o core/wdt.o core/dsp-clock.o core/sync.o
libpmgr = pmgr/chnl.o pmgr/io.o pmgr/msg.o pmgr/cod.o pmgr/dev.o pmgr/dspapi.o
\
- pmgr/dmm.o pmgr/cmm.o pmgr/dbll.o
+ pmgr/cmm.o pmgr/dbll.o
librmgr = rmgr/dbdcd.o rmgr/disp.o rmgr/drv.o rmgr/mgr.o rmgr/node.o \
rmgr/proc.o rmgr/pwr.o rmgr/rmm.o rmgr/strm.o rmgr/dspdrv.o \
rmgr/nldr.o rmgr/drv_interface.o
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c
b/drivers/staging/tidspbridge/core/tiomap3430.c
index f890a0e..0e3558a 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -45,7 +45,6 @@
/* --- Platform Manager */
#include
#include
-#include
#include
/* --- Local */
diff --git a/drivers/staging/tidspbridge/include/dspbridge/dev.h
b/drivers/staging/tidspbridge/include/dspbridge/dev.h
index 357458f..9bdd48f 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/dev.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/dev.h
@@ -27,7 +27,6 @@
#include
#include
#include
-#include
#include
/* --- This */
@@ -234,29 +233,6 @@ extern int dev_get_cmm_mgr(struct dev_object *hdev_obj,
struct cmm_object **mgr);
/*
- * dev_get_dmm_mgr
- * Purpose:
- * Retrieve the handle to the dynamic memory manager created for this
- * device.
- * Parameters:
- * hdev_obj: Handle to device object created with
- * dev_create_device().
- * *mgr: Ptr to location to store handle.
- * Returns:
- * 0:Success.
- * -EFAULT:Invalid hdev_obj.
- * Requires:
- * mgr != NULL.
- * DEV Initialized.
- * Ensures:
- * 0:*mgr contains a handle to a channel manager object,
- * or NULL.
- * else: *mgr is NULL.
- */
-extern int dev_get_dmm_mgr(struct dev_object *hdev_obj,
- struct dmm_object **mgr);
-
-/*
* dev_get_cod_mgr
* Purpose:
* Retrieve the COD manager create for this device.
diff --git a/drivers/staging/tidspbridge/include/dspbridge/dmm.h
b/drivers/staging/tidspbridge/include/dspbridge/dmm.h
deleted file mode 100644
index 6c58335..000
--- a/drivers/staging/tidspbridge/include/dspbridge/dmm.h
+++ /dev/null
@@ -1,75 +0,0 @@
-/*
- * dmm.h
- *
- * DSP-BIOS Bridge driver support functions for TI OMAP processors.
- *
- * The Dynamic Memory Mapping(DMM) module manages the DSP Virtual address
- * space that can be directly mapped to any MPU buffer or memory region.
- *
- * Copyright (C) 2005-2006 Texas Instruments, Inc.
- *
- * This package 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 PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
- * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
- * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
- */
-
-#ifndef DMM_
-#define DMM_
-
-#include
-
-struct dmm_object;
-
-/* DMM attributes used in dmm_create() */
-struct dmm_mgrattrs {
- u32 reserved;
-};
-
-#define DMMPOOLSIZE 0x400
-
-/*
- * dmm_get_handle
- * Purpose:
- * Return the dynamic memory manager object for this device.
- * This is typically called from the client process.
- */
-
-extern int dmm_get_handle(void *hprocessor,
-struct dmm_object **dmm_manager);
-
-extern int dmm_reserve_memory(struct dmm_object *dmm_mgr,
-
[PATCHv2 01/11] staging: tidspbridge: replace iommu custom for opensource implementation
Now the tidspbridge uses the API's from
iovmm module.
Signed-off-by: Fernando Guzman Lugo
---
drivers/staging/tidspbridge/core/_tiomap.h |4 +-
drivers/staging/tidspbridge/core/io_sm.c | 121 ++
drivers/staging/tidspbridge/core/tiomap3430.c | 522
drivers/staging/tidspbridge/core/ue_deh.c |8 -
.../tidspbridge/include/dspbridge/dspdefs.h|2 +-
drivers/staging/tidspbridge/rmgr/proc.c|2 +-
6 files changed, 138 insertions(+), 521 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/_tiomap.h
b/drivers/staging/tidspbridge/core/_tiomap.h
index 1c1f157..a42c393 100644
--- a/drivers/staging/tidspbridge/core/_tiomap.h
+++ b/drivers/staging/tidspbridge/core/_tiomap.h
@@ -23,6 +23,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include /* for bridge_ioctl_extproc defn */
@@ -328,7 +330,7 @@ struct bridge_dev_context {
u32 dw_internal_size; /* Internal memory size */
struct omap_mbox *mbox; /* Mail box handle */
-
+ struct iommu *dsp_mmu; /* iommu for iva2 handler */
struct cfg_hostres *resources; /* Host Resources */
/*
diff --git a/drivers/staging/tidspbridge/core/io_sm.c
b/drivers/staging/tidspbridge/core/io_sm.c
index 5718645..842b8db 100644
--- a/drivers/staging/tidspbridge/core/io_sm.c
+++ b/drivers/staging/tidspbridge/core/io_sm.c
@@ -291,6 +291,7 @@ int bridge_io_on_loaded(struct io_mgr *hio_mgr)
struct cod_manager *cod_man;
struct chnl_mgr *hchnl_mgr;
struct msg_mgr *hmsg_mgr;
+ struct iommu *mmu;
u32 ul_shm_base;
u32 ul_shm_base_offset;
u32 ul_shm_limit;
@@ -313,7 +314,6 @@ int bridge_io_on_loaded(struct io_mgr *hio_mgr)
struct bridge_ioctl_extproc ae_proc[BRDIOCTL_NUMOFMMUTLB];
struct cfg_hostres *host_res;
struct bridge_dev_context *pbridge_context;
- u32 map_attrs;
u32 shm0_end;
u32 ul_dyn_ext_base;
u32 ul_seg1_size = 0;
@@ -337,6 +337,20 @@ int bridge_io_on_loaded(struct io_mgr *hio_mgr)
status = -EFAULT;
goto func_end;
}
+ mmu = pbridge_context->dsp_mmu;
+
+ if (mmu)
+ iommu_put(mmu);
+ mmu = iommu_get("iva2");
+
+ if (IS_ERR_OR_NULL(mmu)) {
+ dev_err(bridge, "iommu_get failed!\n");
+ pbridge_context->dsp_mmu = NULL;
+ status = -EFAULT;
+ goto func_end;
+ }
+ pbridge_context->dsp_mmu = mmu;
+
status = dev_get_cod_mgr(hio_mgr->hdev_obj, &cod_man);
if (!cod_man) {
status = -EFAULT;
@@ -476,55 +490,16 @@ int bridge_io_on_loaded(struct io_mgr *hio_mgr)
gpp_va_curr = ul_gpp_va;
num_bytes = ul_seg1_size;
- /*
-* Try to fit into TLB entries. If not possible, push them to page
-* tables. It is quite possible that if sections are not on
-* bigger page boundary, we may end up making several small pages.
-* So, push them onto page tables, if that is the case.
-*/
- map_attrs = 0x;
- map_attrs = DSP_MAPLITTLEENDIAN;
- map_attrs |= DSP_MAPPHYSICALADDR;
- map_attrs |= DSP_MAPELEMSIZE32;
- map_attrs |= DSP_MAPDONOTLOCK;
-
- while (num_bytes) {
- /*
-* To find the max. page size with which both PA & VA are
-* aligned.
-*/
- all_bits = pa_curr | va_curr;
- dev_dbg(bridge, "all_bits %x, pa_curr %x, va_curr %x, "
- "num_bytes %x\n", all_bits, pa_curr, va_curr,
- num_bytes);
- for (i = 0; i < 4; i++) {
- if ((num_bytes >= page_size[i]) && ((all_bits &
-(page_size[i] -
- 1)) == 0)) {
- status =
- hio_mgr->intf_fxns->
- pfn_brd_mem_map(hio_mgr->hbridge_context,
- pa_curr, va_curr,
- page_size[i], map_attrs,
- NULL);
- if (status)
- goto func_end;
- pa_curr += page_size[i];
- va_curr += page_size[i];
- gpp_va_curr += page_size[i];
- num_bytes -= page_size[i];
- /*
-* Don't try smaller sizes. Hopefully we have
-* reached an address aligned to a bigger page
-* size.
-
[PATCHv2 04/11] staging: tidspbridge - remove custom mmu code from tiomap3430.c
This patch removes all the custom mmu code remaining in
tiomap3430.c which is not needed anymore.
Signed-off-by: Fernando Guzman Lugo
---
drivers/staging/tidspbridge/core/_tiomap.h|2 -
drivers/staging/tidspbridge/core/tiomap3430.c | 425 -
2 files changed, 0 insertions(+), 427 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/_tiomap.h
b/drivers/staging/tidspbridge/core/_tiomap.h
index 8777492..394a64a 100644
--- a/drivers/staging/tidspbridge/core/_tiomap.h
+++ b/drivers/staging/tidspbridge/core/_tiomap.h
@@ -330,7 +330,6 @@ struct bridge_dev_context {
*/
u32 dw_dsp_ext_base_addr; /* See the comment above */
u32 dw_api_reg_base;/* API mem map'd registers */
- void __iomem *dw_dsp_mmu_base; /* DSP MMU Mapped registers */
u32 dw_api_clk_base;/* CLK Registers */
u32 dw_dsp_clk_m2_base; /* DSP Clock Module m2 */
u32 dw_public_rhea; /* Pub Rhea */
@@ -356,7 +355,6 @@ struct bridge_dev_context {
/* TC Settings */
bool tc_word_swap_on; /* Traffic Controller Word Swap */
- struct pg_table_attrs *pt_attrs;
u32 dsp_per_clks;
};
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c
b/drivers/staging/tidspbridge/core/tiomap3430.c
index 8825700..f99cc24 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -102,56 +102,8 @@ static int bridge_dev_create(struct bridge_dev_context
static int bridge_dev_ctrl(struct bridge_dev_context *dev_context,
u32 dw_cmd, void *pargs);
static int bridge_dev_destroy(struct bridge_dev_context *dev_ctxt);
-static int pte_update(struct bridge_dev_context *dev_ctxt, u32 pa,
-u32 va, u32 size,
-struct hw_mmu_map_attrs_t *map_attrs);
-static int pte_set(struct pg_table_attrs *pt, u32 pa, u32 va,
- u32 size, struct hw_mmu_map_attrs_t *attrs);
-static int mem_map_vmalloc(struct bridge_dev_context *dev_context,
- u32 ul_mpu_addr, u32 virt_addr,
- u32 ul_num_bytes,
- struct hw_mmu_map_attrs_t *hw_attrs);
-
bool wait_for_start(struct bridge_dev_context *dev_context, u32 dw_sync_addr);
-/* --- Globals */
-
-/* Attributes of L2 page tables for DSP MMU */
-struct page_info {
- u32 num_entries;/* Number of valid PTEs in the L2 PT */
-};
-
-/* Attributes used to manage the DSP MMU page tables */
-struct pg_table_attrs {
- spinlock_t pg_lock; /* Critical section object handle */
-
- u32 l1_base_pa; /* Physical address of the L1 PT */
- u32 l1_base_va; /* Virtual address of the L1 PT */
- u32 l1_size;/* Size of the L1 PT */
- u32 l1_tbl_alloc_pa;
- /* Physical address of Allocated mem for L1 table. May not be aligned */
- u32 l1_tbl_alloc_va;
- /* Virtual address of Allocated mem for L1 table. May not be aligned */
- u32 l1_tbl_alloc_sz;
- /* Size of consistent memory allocated for L1 table.
-* May not be aligned */
-
- u32 l2_base_pa; /* Physical address of the L2 PT */
- u32 l2_base_va; /* Virtual address of the L2 PT */
- u32 l2_size;/* Size of the L2 PT */
- u32 l2_tbl_alloc_pa;
- /* Physical address of Allocated mem for L2 table. May not be aligned */
- u32 l2_tbl_alloc_va;
- /* Virtual address of Allocated mem for L2 table. May not be aligned */
- u32 l2_tbl_alloc_sz;
- /* Size of consistent memory allocated for L2 table.
-* May not be aligned */
-
- u32 l2_num_pages; /* Number of allocated L2 PT */
- /* Array [l2_num_pages] of L2 PT info structs */
- struct page_info *pg_info;
-};
-
/*
* This Bridge driver's function interface table.
*/
@@ -200,27 +152,6 @@ static struct bridge_drv_interface drv_interface_fxns = {
bridge_msg_set_queue_id,
};
-static inline void flush_all(struct bridge_dev_context *dev_context)
-{
- if (dev_context->dw_brd_state == BRD_DSP_HIBERNATION ||
- dev_context->dw_brd_state == BRD_HIBERNATION)
- wake_dsp(dev_context, NULL);
-
- hw_mmu_tlb_flush_all(dev_context->dw_dsp_mmu_base);
-}
-
-static void bad_page_dump(u32 pa, struct page *pg)
-{
- pr_emerg("DSPBRIDGE: MAP function: COUNT 0 FOR PA 0x%x\n", pa);
- pr_emerg("Bad page state in process '%s'\n"
-"page:%p flags:0x%0*lx mapping:%p mapcount:%d count:%d\n"
-"Backtrace:\n",
-current->comm, pg, (int)(2 * sizeof(unsigned long)),
-(unsigned long)pg->flags, pg->mapping,
-page_mapcount(pg), page_count(pg));
- dump_stack();
-}
-
/*
* bridge_drv_entry
* purpose:
@@ -626,
[PATCHv2 07/11] staging: tidspbridge - move all iommu related code to a new file
Create dsp-mmu module and moves all the iommu code related to
this module.
Signed-off-by: Fernando Guzman Lugo
---
drivers/staging/tidspbridge/Makefile |2 +-
drivers/staging/tidspbridge/core/_deh.h|3 -
drivers/staging/tidspbridge/core/_tiomap.h | 27 +--
drivers/staging/tidspbridge/core/dsp-mmu.c | 316
drivers/staging/tidspbridge/core/tiomap3430.c | 178 +---
drivers/staging/tidspbridge/core/ue_deh.c | 86 +--
.../tidspbridge/include/dspbridge/dsp-mmu.h| 67
7 files changed, 390 insertions(+), 289 deletions(-)
create mode 100644 drivers/staging/tidspbridge/core/dsp-mmu.c
create mode 100644 drivers/staging/tidspbridge/include/dspbridge/dsp-mmu.h
diff --git a/drivers/staging/tidspbridge/Makefile
b/drivers/staging/tidspbridge/Makefile
index e09547d..bd36651 100644
--- a/drivers/staging/tidspbridge/Makefile
+++ b/drivers/staging/tidspbridge/Makefile
@@ -2,7 +2,7 @@ obj-$(CONFIG_TIDSPBRIDGE) += bridgedriver.o
libgen = gen/gb.o gen/gs.o gen/gh.o gen/uuidutil.o
libcore = core/chnl_sm.o core/msg_sm.o core/io_sm.o core/tiomap3430.o \
- core/tiomap3430_pwr.o core/tiomap_io.o \
+ core/tiomap3430_pwr.o core/tiomap_io.o core/dsp-mmu.o \
core/ue_deh.o core/wdt.o core/dsp-clock.o core/sync.o
libpmgr = pmgr/chnl.o pmgr/io.o pmgr/msg.o pmgr/cod.o pmgr/dev.o pmgr/dspapi.o
\
pmgr/dmm.o pmgr/cmm.o pmgr/dbll.o
diff --git a/drivers/staging/tidspbridge/core/_deh.h
b/drivers/staging/tidspbridge/core/_deh.h
index f1254f0..8ae2633 100644
--- a/drivers/staging/tidspbridge/core/_deh.h
+++ b/drivers/staging/tidspbridge/core/_deh.h
@@ -27,9 +27,6 @@
struct deh_mgr {
struct bridge_dev_context *hbridge_context; /* Bridge context. */
struct ntfy_object *ntfy_obj; /* NTFY object */
-
- /* MMU Fault DPC */
- struct tasklet_struct dpc_tasklet;
};
int mmu_fault_isr(struct iommu *mmu);
diff --git a/drivers/staging/tidspbridge/core/_tiomap.h
b/drivers/staging/tidspbridge/core/_tiomap.h
index cd7ff88..e0a801c 100644
--- a/drivers/staging/tidspbridge/core/_tiomap.h
+++ b/drivers/staging/tidspbridge/core/_tiomap.h
@@ -23,8 +23,7 @@
#include
#include
#include
-#include
-#include
+#include
#include
#include /* for bridge_ioctl_extproc defn */
#include
@@ -380,28 +379,4 @@ extern s32 dsp_debug;
*/
int sm_interrupt_dsp(struct bridge_dev_context *dev_context, u16 mb_val);
-/**
- * user_to_dsp_map() - maps user to dsp virtual address
- * @mmu: Pointer to iommu handle.
- * @uva: Virtual user space address.
- * @da DSP address
- * @size Buffer size to map.
- * @usr_pgsstruct page array pointer where the user pages will be stored
- *
- * This function maps a user space buffer into DSP virtual address.
- *
- */
-u32 user_to_dsp_map(struct iommu *mmu, u32 uva, u32 da, u32 size,
- struct page **usr_pgs);
-
-/**
- * user_to_dsp_unmap() - unmaps DSP virtual buffer.
- * @mmu: Pointer to iommu handle.
- * @da DSP address
- *
- * This function unmaps a user space buffer into DSP virtual address.
- *
- */
-int user_to_dsp_unmap(struct iommu *mmu, u32 da);
-
#endif /* _TIOMAP_ */
diff --git a/drivers/staging/tidspbridge/core/dsp-mmu.c
b/drivers/staging/tidspbridge/core/dsp-mmu.c
new file mode 100644
index 000..3c978f9
--- /dev/null
+++ b/drivers/staging/tidspbridge/core/dsp-mmu.c
@@ -0,0 +1,316 @@
+/*
+ * dsp-mmu.c
+ *
+ * DSP-BIOS Bridge driver support functions for TI OMAP processors.
+ *
+ * DSP iommu.
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ *
+ * This package 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 PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
+ * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "_tiomap.h"
+
+#include
+
+#define MMU_CNTL_TWL_EN(1 << 2)
+
+static struct tasklet_struct mmu_tasklet;
+
+#ifdef CONFIG_TIDSPBRIDGE_BACKTRACE
+static void mmu_fault_print_stack(struct bridge_dev_context *dev_context)
+{
+ void *dummy_addr;
+ u32 fa, tmp;
+ struct iotlb_entry e;
+ struct iommu *mmu = dev_context->dsp_mmu;
+ dummy_addr = (void *)__get_free_page(GFP_ATOMIC);
+
+ /*
+* Before acking the MMU fault, let's make sure MMU can only
+* access entry #0. Then add a new entry so that the DSP OS
+* can continue in order to dump the stack.
+*/
+ tmp = iommu_read_reg(mmu, MMU_CNTL);
+ tmp &= ~MMU_CNTL_TWL_EN;
+ iommu_write_reg(mmu, tmp, MMU_CNTL);
+ fa = iom
[PATCHv2 02/11] staging: tidspbridge - move shared memory iommu maps to tiomap3430.c
Now iommu maps of shared memory segments are done in
bridge_brd_start and unmaped in bridge_brd_stop.
Signed-off-by: Fernando Guzman Lugo
---
drivers/staging/tidspbridge/core/_tiomap.h| 13 +++
drivers/staging/tidspbridge/core/io_sm.c | 125 +++
drivers/staging/tidspbridge/core/tiomap3430.c | 136 +++-
drivers/staging/tidspbridge/core/tiomap_io.c | 12 +-
4 files changed, 139 insertions(+), 147 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/_tiomap.h
b/drivers/staging/tidspbridge/core/_tiomap.h
index a42c393..c1bf95d 100644
--- a/drivers/staging/tidspbridge/core/_tiomap.h
+++ b/drivers/staging/tidspbridge/core/_tiomap.h
@@ -308,6 +308,18 @@ static const struct bpwr_clk_t bpwr_clks[] = {
#define CLEAR_BIT_INDEX(reg, index) (reg &= ~(1 << (index)))
+struct shm_segs {
+ u32 seg0_da;
+ u32 seg0_pa;
+ u32 seg0_va;
+ u32 seg0_size;
+ u32 seg1_da;
+ u32 seg1_pa;
+ u32 seg1_va;
+ u32 seg1_size;
+};
+
+
/* This Bridge driver's device context: */
struct bridge_dev_context {
struct dev_object *hdev_obj;/* Handle to Bridge device object. */
@@ -331,6 +343,7 @@ struct bridge_dev_context {
struct omap_mbox *mbox; /* Mail box handle */
struct iommu *dsp_mmu; /* iommu for iva2 handler */
+ struct shm_segs sh_s;
struct cfg_hostres *resources; /* Host Resources */
/*
diff --git a/drivers/staging/tidspbridge/core/io_sm.c
b/drivers/staging/tidspbridge/core/io_sm.c
index 842b8db..56856ad 100644
--- a/drivers/staging/tidspbridge/core/io_sm.c
+++ b/drivers/staging/tidspbridge/core/io_sm.c
@@ -291,7 +291,7 @@ int bridge_io_on_loaded(struct io_mgr *hio_mgr)
struct cod_manager *cod_man;
struct chnl_mgr *hchnl_mgr;
struct msg_mgr *hmsg_mgr;
- struct iommu *mmu;
+ struct shm_segs *sm_sg;
u32 ul_shm_base;
u32 ul_shm_base_offset;
u32 ul_shm_limit;
@@ -317,14 +317,6 @@ int bridge_io_on_loaded(struct io_mgr *hio_mgr)
u32 shm0_end;
u32 ul_dyn_ext_base;
u32 ul_seg1_size = 0;
- u32 pa_curr = 0;
- u32 va_curr = 0;
- u32 gpp_va_curr = 0;
- u32 num_bytes = 0;
- u32 all_bits = 0;
- u32 page_size[] = { HW_PAGE_SIZE16MB, HW_PAGE_SIZE1MB,
- HW_PAGE_SIZE64KB, HW_PAGE_SIZE4KB
- };
status = dev_get_bridge_context(hio_mgr->hdev_obj, &pbridge_context);
if (!pbridge_context) {
@@ -337,19 +329,7 @@ int bridge_io_on_loaded(struct io_mgr *hio_mgr)
status = -EFAULT;
goto func_end;
}
- mmu = pbridge_context->dsp_mmu;
-
- if (mmu)
- iommu_put(mmu);
- mmu = iommu_get("iva2");
-
- if (IS_ERR_OR_NULL(mmu)) {
- dev_err(bridge, "iommu_get failed!\n");
- pbridge_context->dsp_mmu = NULL;
- status = -EFAULT;
- goto func_end;
- }
- pbridge_context->dsp_mmu = mmu;
+ sm_sg = &pbridge_context->sh_s;
status = dev_get_cod_mgr(hio_mgr->hdev_obj, &cod_man);
if (!cod_man) {
@@ -485,74 +465,14 @@ int bridge_io_on_loaded(struct io_mgr *hio_mgr)
if (status)
goto func_end;
- pa_curr = ul_gpp_pa;
- va_curr = ul_dyn_ext_base * hio_mgr->word_size;
- gpp_va_curr = ul_gpp_va;
- num_bytes = ul_seg1_size;
-
- va_curr = iommu_kmap(mmu, va_curr, pa_curr, num_bytes,
- IOVMF_ENDIAN_LITTLE | IOVMF_ELSZ_32);
- if (IS_ERR_VALUE(va_curr)) {
- status = (int)va_curr;
- goto func_end;
- }
-
- pa_curr += ul_pad_size + num_bytes;
- va_curr += ul_pad_size + num_bytes;
- gpp_va_curr += ul_pad_size + num_bytes;
-
- /* Configure the TLB entries for the next cacheable segment */
- num_bytes = ul_seg_size;
- va_curr = ul_dsp_va * hio_mgr->word_size;
- while (num_bytes) {
- /*
-* To find the max. page size with which both PA & VA are
-* aligned.
-*/
- all_bits = pa_curr | va_curr;
- dev_dbg(bridge, "all_bits for Seg1 %x, pa_curr %x, "
- "va_curr %x, num_bytes %x\n", all_bits, pa_curr,
- va_curr, num_bytes);
- for (i = 0; i < 4; i++) {
- if (!(num_bytes >= page_size[i]) ||
- !((all_bits & (page_size[i] - 1)) == 0))
- continue;
- if (ndx < MAX_LOCK_TLB_ENTRIES) {
- /*
-* This is the physical address written to
-* DSP MMU.
-*/
- ae_proc[ndx].ul_gpp_pa = pa_curr;
- /*
-
[PATCHv2 05/11] staging: tidspbridge - fix mmufault support
With changes for iommu migration mmufault report and dsp track
dump is broken, this patch fixes that.
Signed-off-by: Fernando Guzman Lugo
---
drivers/staging/tidspbridge/core/_deh.h |2 +
drivers/staging/tidspbridge/core/tiomap3430.c |2 +
drivers/staging/tidspbridge/core/ue_deh.c | 93 ++---
3 files changed, 40 insertions(+), 57 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/_deh.h
b/drivers/staging/tidspbridge/core/_deh.h
index 16723cd..f1254f0 100644
--- a/drivers/staging/tidspbridge/core/_deh.h
+++ b/drivers/staging/tidspbridge/core/_deh.h
@@ -32,4 +32,6 @@ struct deh_mgr {
struct tasklet_struct dpc_tasklet;
};
+int mmu_fault_isr(struct iommu *mmu);
+
#endif /* _DEH_ */
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c
b/drivers/staging/tidspbridge/core/tiomap3430.c
index f99cc24..55ea265 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -56,6 +56,7 @@
#include "_tiomap.h"
#include "_tiomap_pwr.h"
#include "tiomap_io.h"
+#include "_deh.h"
/* Offset in shared mem to write to in order to synchronize start with DSP */
#define SHMSYNCOFFSET 4/* GPP byte offset */
@@ -365,6 +366,7 @@ static int bridge_brd_start(struct bridge_dev_context
*dev_ctxt,
}
if (!status) {
dev_context->dsp_mmu = mmu;
+ mmu->isr = mmu_fault_isr;
sm_sg = &dev_context->sh_s;
sg0_da = iommu_kmap(mmu, sm_sg->seg0_da, sm_sg->seg0_pa,
sm_sg->seg0_size, IOVMF_ENDIAN_LITTLE | IOVMF_ELSZ_32);
diff --git a/drivers/staging/tidspbridge/core/ue_deh.c
b/drivers/staging/tidspbridge/core/ue_deh.c
index 14f3191..2e1ac89 100644
--- a/drivers/staging/tidspbridge/core/ue_deh.c
+++ b/drivers/staging/tidspbridge/core/ue_deh.c
@@ -31,7 +31,7 @@
#include
#include
-static u32 fault_addr;
+#define MMU_CNTL_TWL_EN(1 << 2)
static void mmu_fault_dpc(unsigned long data)
{
@@ -43,43 +43,18 @@ static void mmu_fault_dpc(unsigned long data)
bridge_deh_notify(deh, DSP_MMUFAULT, 0);
}
-static irqreturn_t mmu_fault_isr(int irq, void *data)
+int mmu_fault_isr(struct iommu *mmu)
{
- struct deh_mgr *deh = data;
- struct cfg_hostres *resources;
- u32 event;
+ struct deh_mgr *dm;
- if (!deh)
- return IRQ_HANDLED;
+ dev_get_deh_mgr(dev_get_first(), &dm);
- resources = deh->hbridge_context->resources;
- if (!resources) {
- dev_dbg(bridge, "%s: Failed to get Host Resources\n",
- __func__);
- return IRQ_HANDLED;
- }
+ if (!dm)
+ return -EPERM;
- hw_mmu_event_status(resources->dw_dmmu_base, &event);
- if (event == HW_MMU_TRANSLATION_FAULT) {
- hw_mmu_fault_addr_read(resources->dw_dmmu_base, &fault_addr);
- dev_dbg(bridge, "%s: event=0x%x, fault_addr=0x%x\n", __func__,
- event, fault_addr);
- /*
-* Schedule a DPC directly. In the future, it may be
-* necessary to check if DSP MMU fault is intended for
-* Bridge.
-*/
- tasklet_schedule(&deh->dpc_tasklet);
-
- /* Disable the MMU events, else once we clear it will
-* start to raise INTs again */
- hw_mmu_event_disable(resources->dw_dmmu_base,
- HW_MMU_TRANSLATION_FAULT);
- } else {
- hw_mmu_event_disable(resources->dw_dmmu_base,
- HW_MMU_ALL_INTERRUPTS);
- }
- return IRQ_HANDLED;
+ iommu_write_reg(mmu, 0, MMU_IRQENABLE);
+ tasklet_schedule(&dm->dpc_tasklet);
+ return 0;
}
int bridge_deh_create(struct deh_mgr **ret_deh,
@@ -161,42 +136,45 @@ int bridge_deh_register_notify(struct deh_mgr *deh, u32
event_mask,
#ifdef CONFIG_TIDSPBRIDGE_BACKTRACE
static void mmu_fault_print_stack(struct bridge_dev_context *dev_context)
{
- struct cfg_hostres *resources;
- struct hw_mmu_map_attrs_t map_attrs = {
- .endianism = HW_LITTLE_ENDIAN,
- .element_size = HW_ELEM_SIZE16BIT,
- .mixed_size = HW_MMU_CPUES,
- };
- void *dummy_va_addr;
-
- resources = dev_context->resources;
- dummy_va_addr = (void*)__get_free_page(GFP_ATOMIC);
+ void *dummy_addr;
+ u32 fa, tmp;
+ struct iotlb_entry e;
+ struct iommu *mmu = dev_context->dsp_mmu;
+ dummy_addr = (void *)__get_free_page(GFP_ATOMIC);
/*
* Before acking the MMU fault, let's make sure MMU can only
* access entry #0. Then add a new entry so that the DSP OS
* can continue in order to dump the stack.
*/
- hw_mmu_twl_disable(resources->dw_dmmu_base);
- hw_mmu_tlb_flush_all(resource
[PATCHv2 06/11] staging: tidspbrge - remove hw directory
hw directory was only being used for custom iommu implementation APIs, so after the iommu module migration this directory is not needed anymore. Signed-off-by: Fernando Guzman Lugo --- drivers/staging/tidspbridge/Makefile |3 +- drivers/staging/tidspbridge/core/_tiomap.h |1 - drivers/staging/tidspbridge/core/io_sm.c |4 - drivers/staging/tidspbridge/core/tiomap3430.c |4 - drivers/staging/tidspbridge/core/tiomap3430_pwr.c |4 - drivers/staging/tidspbridge/core/tiomap_io.c |2 +- drivers/staging/tidspbridge/hw/EasiGlobal.h| 41 -- drivers/staging/tidspbridge/hw/MMUAccInt.h | 76 --- drivers/staging/tidspbridge/hw/MMURegAcM.h | 225 drivers/staging/tidspbridge/hw/hw_defs.h | 58 -- drivers/staging/tidspbridge/hw/hw_mmu.c| 562 drivers/staging/tidspbridge/hw/hw_mmu.h| 163 -- .../tidspbridge/include/dspbridge/dspioctl.h |7 - 13 files changed, 2 insertions(+), 1148 deletions(-) delete mode 100644 drivers/staging/tidspbridge/hw/EasiGlobal.h delete mode 100644 drivers/staging/tidspbridge/hw/MMUAccInt.h delete mode 100644 drivers/staging/tidspbridge/hw/MMURegAcM.h delete mode 100644 drivers/staging/tidspbridge/hw/hw_defs.h delete mode 100644 drivers/staging/tidspbridge/hw/hw_mmu.c delete mode 100644 drivers/staging/tidspbridge/hw/hw_mmu.h diff --git a/drivers/staging/tidspbridge/Makefile b/drivers/staging/tidspbridge/Makefile index 8082d5c..e09547d 100644 --- a/drivers/staging/tidspbridge/Makefile +++ b/drivers/staging/tidspbridge/Makefile @@ -11,10 +11,9 @@ librmgr = rmgr/dbdcd.o rmgr/disp.o rmgr/drv.o rmgr/mgr.o rmgr/node.o \ rmgr/nldr.o rmgr/drv_interface.o libdload = dynload/cload.o dynload/getsection.o dynload/reloc.o \ dynload/tramp.o -libhw = hw/hw_mmu.o bridgedriver-objs = $(libgen) $(libservices) $(libcore) $(libpmgr) $(librmgr) \ - $(libdload) $(libhw) + $(libdload) #Machine dependent ccflags-y += -D_TI_ -D_DB_TIOMAP -DTMS32060 \ diff --git a/drivers/staging/tidspbridge/core/_tiomap.h b/drivers/staging/tidspbridge/core/_tiomap.h index 394a64a..cd7ff88 100644 --- a/drivers/staging/tidspbridge/core/_tiomap.h +++ b/drivers/staging/tidspbridge/core/_tiomap.h @@ -26,7 +26,6 @@ #include #include #include -#include #include /* for bridge_ioctl_extproc defn */ #include #include diff --git a/drivers/staging/tidspbridge/core/io_sm.c b/drivers/staging/tidspbridge/core/io_sm.c index 56856ad..194bada 100644 --- a/drivers/staging/tidspbridge/core/io_sm.c +++ b/drivers/staging/tidspbridge/core/io_sm.c @@ -39,10 +39,6 @@ #include #include -/* Hardware Abstraction Layer */ -#include -#include - /* Bridge Driver */ #include #include diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c b/drivers/staging/tidspbridge/core/tiomap3430.c index 55ea265..58118aa 100644 --- a/drivers/staging/tidspbridge/core/tiomap3430.c +++ b/drivers/staging/tidspbridge/core/tiomap3430.c @@ -33,10 +33,6 @@ #include #include -/* Hardware Abstraction Layer */ -#include -#include - /* --- Link Driver */ #include #include diff --git a/drivers/staging/tidspbridge/core/tiomap3430_pwr.c b/drivers/staging/tidspbridge/core/tiomap3430_pwr.c index b9d0753..e29b969 100644 --- a/drivers/staging/tidspbridge/core/tiomap3430_pwr.c +++ b/drivers/staging/tidspbridge/core/tiomap3430_pwr.c @@ -29,10 +29,6 @@ #include #include -/* Hardware Abstraction Layer */ -#include -#include - #include /* --- Bridge Driver */ diff --git a/drivers/staging/tidspbridge/core/tiomap_io.c b/drivers/staging/tidspbridge/core/tiomap_io.c index 1300bd3..63d46bc 100644 --- a/drivers/staging/tidspbridge/core/tiomap_io.c +++ b/drivers/staging/tidspbridge/core/tiomap_io.c @@ -141,7 +141,7 @@ int read_ext_dsp_data(struct bridge_dev_context *dev_ctxt, ul_shm_base_virt - ul_tlb_base_virt; ul_shm_offset_virt += PG_ALIGN_HIGH(ul_ext_end - ul_dyn_ext_base + - 1, HW_PAGE_SIZE64KB); + 1, PAGE_SIZE * 16); dw_ext_prog_virt_mem -= ul_shm_offset_virt; dw_ext_prog_virt_mem += (ul_ext_base - ul_dyn_ext_base); diff --git a/drivers/staging/tidspbridge/hw/EasiGlobal.h b/drivers/staging/tidspbridge/hw/EasiGlobal.h deleted file mode 100644 index e48d7f6..000 --- a/drivers/staging/tidspbridge/hw/EasiGlobal.h +++ /dev/null @@ -1,41 +0,0 @@ -/* - * EasiGlobal.h - * - * DSP-BIOS Bridge driver support functions for TI OMAP processors. -
[PATCHv2 10/11] staging: tidspbridge - deprecate reserve/unreserve_memory funtions
Now what iommu memory usage is kept track by iommu module
the functions reserve/unreserve_memory are not needed anymore.
Signed-off-by: Fernando Guzman Lugo
---
.../staging/tidspbridge/include/dspbridge/proc.h | 46
drivers/staging/tidspbridge/pmgr/dspapi.c | 34 +-
drivers/staging/tidspbridge/rmgr/node.c| 20 +
drivers/staging/tidspbridge/rmgr/proc.c| 114 ++--
4 files changed, 17 insertions(+), 197 deletions(-)
diff --git a/drivers/staging/tidspbridge/include/dspbridge/proc.h
b/drivers/staging/tidspbridge/include/dspbridge/proc.h
index 5e09fd1..2d12aab 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/proc.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/proc.h
@@ -551,29 +551,6 @@ extern int proc_map(void *hprocessor,
struct process_context *pr_ctxt);
/*
- * proc_reserve_memory
- * Purpose:
- * Reserve a virtually contiguous region of DSP address space.
- * Parameters:
- * hprocessor : The processor handle.
- * ul_size : Size of the address space to reserve.
- * pp_rsv_addr : Ptr to DSP side reserved u8 address.
- * Returns:
- * 0 : Success.
- * -EFAULT : Invalid processor handle.
- * -EPERM : General failure.
- * -ENOMEM : Cannot reserve chunk of this size.
- * Requires:
- * pp_rsv_addr is not NULL
- * PROC Initialized.
- * Ensures:
- * Details:
- */
-extern int proc_reserve_memory(void *hprocessor,
- u32 ul_size, void **pp_rsv_addr,
- struct process_context *pr_ctxt);
-
-/*
* proc_un_map
* Purpose:
* Removes a MPU buffer mapping from the DSP address space.
@@ -595,27 +572,4 @@ extern int proc_reserve_memory(void *hprocessor,
extern int proc_un_map(void *hprocessor, void *map_addr,
struct process_context *pr_ctxt);
-/*
- * proc_un_reserve_memory
- * Purpose:
- * Frees a previously reserved region of DSP address space.
- * Parameters:
- * hprocessor : The processor handle.
- * prsv_addr : Ptr to DSP side reservedBYTE address.
- * Returns:
- * 0 : Success.
- * -EFAULT : Invalid processor handle.
- * -EPERM : General failure.
- * -ENOENT : Cannot find a reserved region starting with this
- * : address.
- * Requires:
- * prsv_addr is not NULL
- * PROC Initialized.
- * Ensures:
- * Details:
- */
-extern int proc_un_reserve_memory(void *hprocessor,
-void *prsv_addr,
-struct process_context *pr_ctxt);
-
#endif /* PROC_ */
diff --git a/drivers/staging/tidspbridge/pmgr/dspapi.c
b/drivers/staging/tidspbridge/pmgr/dspapi.c
index faf8304..0187c47 100644
--- a/drivers/staging/tidspbridge/pmgr/dspapi.c
+++ b/drivers/staging/tidspbridge/pmgr/dspapi.c
@@ -989,27 +989,10 @@ u32 procwrap_register_notify(union trapped_args *args,
void *pr_ctxt)
/*
* procwrap_reserve_memory
*/
-u32 procwrap_reserve_memory(union trapped_args *args, void *pr_ctxt)
+u32 __deprecated procwrap_reserve_memory(union trapped_args *args,
+ void *pr_ctxt)
{
- int status;
- void *prsv_addr;
- void *hprocessor = ((struct process_context *)pr_ctxt)->hprocessor;
-
- if ((args->args_proc_rsvmem.ul_size <= 0) ||
- (args->args_proc_rsvmem.ul_size & (PG_SIZE4K - 1)) != 0)
- return -EINVAL;
-
- status = proc_reserve_memory(hprocessor,
-args->args_proc_rsvmem.ul_size, &prsv_addr,
-pr_ctxt);
- if (!status) {
- if (put_user(prsv_addr, args->args_proc_rsvmem.pp_rsv_addr)) {
- status = -EINVAL;
- proc_un_reserve_memory(args->args_proc_rsvmem.
- hprocessor, prsv_addr, pr_ctxt);
- }
- }
- return status;
+ return 0;
}
/*
@@ -1038,15 +1021,10 @@ u32 procwrap_un_map(union trapped_args *args, void
*pr_ctxt)
/*
* procwrap_un_reserve_memory
*/
-u32 procwrap_un_reserve_memory(union trapped_args *args, void *pr_ctxt)
+u32 __deprecated procwrap_un_reserve_memory(union trapped_args *args,
+ void *pr_ctxt)
{
- int status;
- void *hprocessor = ((struct process_context *)pr_ctxt)->hprocessor;
-
- status = proc_un_reserve_memory(hprocessor,
- args->args_proc_unrsvmem.prsv_addr,
- pr_ctxt);
- return status;
+ return 0;
}
/*
diff --git a/drivers/staging/tidspbri
[PATCHv2 09/11] staging: tidspbridge - remove reserved memory clean up
Now iommv module keeps track of iommu memory used,
we do not need resource cleanup for reserved
memories anymore.
Signed-off-by: Fernando Guzman Lugo
---
.../staging/tidspbridge/include/dspbridge/drv.h|4 --
drivers/staging/tidspbridge/rmgr/drv.c | 11 --
drivers/staging/tidspbridge/rmgr/drv_interface.c |2 -
drivers/staging/tidspbridge/rmgr/proc.c| 36
4 files changed, 0 insertions(+), 53 deletions(-)
diff --git a/drivers/staging/tidspbridge/include/dspbridge/drv.h
b/drivers/staging/tidspbridge/include/dspbridge/drv.h
index c1f363e..427f38b 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/drv.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/drv.h
@@ -165,10 +165,6 @@ struct process_context {
struct list_head dmm_map_list;
spinlock_t dmm_map_lock;
- /* DMM reserved memory resources */
- struct list_head dmm_rsv_list;
- spinlock_t dmm_rsv_lock;
-
/* DSP Heap resources */
struct dspheap_res_object *pdspheap_list;
diff --git a/drivers/staging/tidspbridge/rmgr/drv.c
b/drivers/staging/tidspbridge/rmgr/drv.c
index 0c857b9..91cc168 100644
--- a/drivers/staging/tidspbridge/rmgr/drv.c
+++ b/drivers/staging/tidspbridge/rmgr/drv.c
@@ -146,7 +146,6 @@ int drv_remove_all_dmm_res_elements(void *process_ctxt)
struct process_context *ctxt = (struct process_context *)process_ctxt;
int status = 0;
struct dmm_map_object *temp_map, *map_obj;
- struct dmm_rsv_object *temp_rsv, *rsv_obj;
/* Free DMM mapped memory resources */
list_for_each_entry_safe(map_obj, temp_map, &ctxt->dmm_map_list, link) {
@@ -156,16 +155,6 @@ int drv_remove_all_dmm_res_elements(void *process_ctxt)
pr_err("%s: proc_un_map failed!"
" status = 0x%xn", __func__, status);
}
-
- /* Free DMM reserved memory resources */
- list_for_each_entry_safe(rsv_obj, temp_rsv, &ctxt->dmm_rsv_list, link) {
- status = proc_un_reserve_memory(ctxt->hprocessor, (void *)
- rsv_obj->dsp_reserved_addr,
- ctxt);
- if (status)
- pr_err("%s: proc_un_reserve_memory failed!"
- " status = 0x%xn", __func__, status);
- }
return status;
}
diff --git a/drivers/staging/tidspbridge/rmgr/drv_interface.c
b/drivers/staging/tidspbridge/rmgr/drv_interface.c
index 4c0b9ee..f9a1e0b 100644
--- a/drivers/staging/tidspbridge/rmgr/drv_interface.c
+++ b/drivers/staging/tidspbridge/rmgr/drv_interface.c
@@ -507,8 +507,6 @@ static int bridge_open(struct inode *ip, struct file *filp)
pr_ctxt->res_state = PROC_RES_ALLOCATED;
spin_lock_init(&pr_ctxt->dmm_map_lock);
INIT_LIST_HEAD(&pr_ctxt->dmm_map_list);
- spin_lock_init(&pr_ctxt->dmm_rsv_lock);
- INIT_LIST_HEAD(&pr_ctxt->dmm_rsv_list);
pr_ctxt->node_id = kzalloc(sizeof(struct idr), GFP_KERNEL);
if (pr_ctxt->node_id) {
diff --git a/drivers/staging/tidspbridge/rmgr/proc.c
b/drivers/staging/tidspbridge/rmgr/proc.c
index 59c946b..e5fec57 100644
--- a/drivers/staging/tidspbridge/rmgr/proc.c
+++ b/drivers/staging/tidspbridge/rmgr/proc.c
@@ -1515,7 +1515,6 @@ int proc_reserve_memory(void *hprocessor, u32 ul_size,
struct dmm_object *dmm_mgr;
int status = 0;
struct proc_object *p_proc_object = (struct proc_object *)hprocessor;
- struct dmm_rsv_object *rsv_obj;
if (!p_proc_object) {
status = -EFAULT;
@@ -1529,22 +1528,6 @@ int proc_reserve_memory(void *hprocessor, u32 ul_size,
}
status = dmm_reserve_memory(dmm_mgr, ul_size, (u32 *) pp_rsv_addr);
- if (status != 0)
- goto func_end;
-
- /*
-* A successful reserve should be followed by insertion of rsv_obj
-* into dmm_rsv_list, so that reserved memory resource tracking
-* remains uptodate
-*/
- rsv_obj = kmalloc(sizeof(struct dmm_rsv_object), GFP_KERNEL);
- if (rsv_obj) {
- rsv_obj->dsp_reserved_addr = (u32) *pp_rsv_addr;
- spin_lock(&pr_ctxt->dmm_rsv_lock);
- list_add(&rsv_obj->link, &pr_ctxt->dmm_rsv_list);
- spin_unlock(&pr_ctxt->dmm_rsv_lock);
- }
-
func_end:
dev_dbg(bridge, "%s: hprocessor: 0x%p ul_size: 0x%x pp_rsv_addr: 0x%p "
"status 0x%x\n", __func__, hprocessor,
@@ -1756,7 +1739,6 @@ int proc_un_reserve_memory(void *hprocessor, void
*prsv_addr,
struct dmm_object *dmm_mgr;
int status = 0;
struct proc_object *p_proc_object = (struct proc_object *)hprocessor;
- struct dmm_rsv_object *rsv_obj;
if (!p_proc_object) {
status = -EFAULT;
@@ -1770,24 +1752,6 @@ int proc_un_reserve_me
[PATCHv2 08/11] staging: tidspbridge: remove dw_dmmu_base from cfg_hostres struct
We don't need to map iva2 iommu register base address
anymore.
Signed-off-by: Fernando Guzman Lugo
---
drivers/staging/tidspbridge/core/tiomap3430.c |3 ---
drivers/staging/tidspbridge/core/tiomap_io.c |3 +--
.../tidspbridge/include/dspbridge/cfgdefs.h|1 -
drivers/staging/tidspbridge/rmgr/drv.c |4
4 files changed, 1 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c
b/drivers/staging/tidspbridge/core/tiomap3430.c
index 789cc5e..f890a0e 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -830,8 +830,6 @@ static int bridge_dev_destroy(struct bridge_dev_context
*dev_ctxt)
iounmap((void *)host_res->dw_mem_base[3]);
if (host_res->dw_mem_base[4])
iounmap((void *)host_res->dw_mem_base[4]);
- if (host_res->dw_dmmu_base)
- iounmap(host_res->dw_dmmu_base);
if (host_res->dw_per_base)
iounmap(host_res->dw_per_base);
if (host_res->dw_per_pm_base)
@@ -845,7 +843,6 @@ static int bridge_dev_destroy(struct bridge_dev_context
*dev_ctxt)
host_res->dw_mem_base[2] = (u32) NULL;
host_res->dw_mem_base[3] = (u32) NULL;
host_res->dw_mem_base[4] = (u32) NULL;
- host_res->dw_dmmu_base = NULL;
host_res->dw_sys_ctrl_base = NULL;
kfree(host_res);
diff --git a/drivers/staging/tidspbridge/core/tiomap_io.c
b/drivers/staging/tidspbridge/core/tiomap_io.c
index 63d46bc..81a5401 100644
--- a/drivers/staging/tidspbridge/core/tiomap_io.c
+++ b/drivers/staging/tidspbridge/core/tiomap_io.c
@@ -391,7 +391,6 @@ int sm_interrupt_dsp(struct bridge_dev_context
*dev_context, u16 mb_val)
omap_dspbridge_dev->dev.platform_data;
struct cfg_hostres *resources = dev_context->resources;
int status = 0;
- u32 temp;
if (!dev_context->mbox)
return 0;
@@ -435,7 +434,7 @@ int sm_interrupt_dsp(struct bridge_dev_context
*dev_context, u16 mb_val)
omap_mbox_restore_ctx(dev_context->mbox);
/* Access MMU SYS CONFIG register to generate a short wakeup */
- temp = readl(resources->dw_dmmu_base + 0x10);
+ iommu_read_reg(dev_context->dsp_mmu, MMU_SYSCONFIG);
dev_context->dw_brd_state = BRD_RUNNING;
} else if (dev_context->dw_brd_state == BRD_RETENTION) {
diff --git a/drivers/staging/tidspbridge/include/dspbridge/cfgdefs.h
b/drivers/staging/tidspbridge/include/dspbridge/cfgdefs.h
index 38122db..dfb55cc 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/cfgdefs.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/cfgdefs.h
@@ -68,7 +68,6 @@ struct cfg_hostres {
void __iomem *dw_per_base;
u32 dw_per_pm_base;
u32 dw_core_pm_base;
- void __iomem *dw_dmmu_base;
void __iomem *dw_sys_ctrl_base;
};
diff --git a/drivers/staging/tidspbridge/rmgr/drv.c
b/drivers/staging/tidspbridge/rmgr/drv.c
index 81b1b90..0c857b9 100644
--- a/drivers/staging/tidspbridge/rmgr/drv.c
+++ b/drivers/staging/tidspbridge/rmgr/drv.c
@@ -743,7 +743,6 @@ static int request_bridge_resources(struct cfg_hostres *res)
host_res->dw_sys_ctrl_base = ioremap(OMAP_SYSC_BASE, OMAP_SYSC_SIZE);
dev_dbg(bridge, "dw_mem_base[0] 0x%x\n", host_res->dw_mem_base[0]);
dev_dbg(bridge, "dw_mem_base[3] 0x%x\n", host_res->dw_mem_base[3]);
- dev_dbg(bridge, "dw_dmmu_base %p\n", host_res->dw_dmmu_base);
/* for 24xx base port is not mapping the mamory for DSP
* internal memory TODO Do a ioremap here */
@@ -797,8 +796,6 @@ int drv_request_bridge_res_dsp(void **phost_resources)
OMAP_PER_PRM_SIZE);
host_res->dw_core_pm_base = (u32) ioremap(OMAP_CORE_PRM_BASE,
OMAP_CORE_PRM_SIZE);
- host_res->dw_dmmu_base = ioremap(OMAP_DMMU_BASE,
-OMAP_DMMU_SIZE);
dev_dbg(bridge, "dw_mem_base[0] 0x%x\n",
host_res->dw_mem_base[0]);
@@ -810,7 +807,6 @@ int drv_request_bridge_res_dsp(void **phost_resources)
host_res->dw_mem_base[3]);
dev_dbg(bridge, "dw_mem_base[4] 0x%x\n",
host_res->dw_mem_base[4]);
- dev_dbg(bridge, "dw_dmmu_base %p\n", host_res->dw_dmmu_base);
shm_size = drv_datap->shm_size;
if (shm_size >= 0x1) {
--
1.6.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 00/11] staging tidspbridge: iommu migration
This set of patches remove the dspbridge custom mmu implementation and use iommu module instead. Version2: - Comments from FUJITA Tomonori and previous patch "tidspbridge: add map support for big buffers" was removed and instead a patch to define ARCH_HAS_SG_CHAIN in arm architecture will be sent. - Rebase to the latest tidspbridge. Fernando Guzman Lugo (11): staging: tidspbridge: replace iommu custom for opensource implementation staging: tidspbridge - move shared memory iommu maps to tiomap3430.c staging: tidspbridge - rename bridge_brd_mem_map/unmap to a proper name staging: tidspbridge - remove custom mmu code from tiomap3430.c staging: tidspbridge - fix mmufault support staging: tidspbrge - remove hw directory staging: tidspbridge - move all iommu related code to a new file staging: tidspbridge: remove dw_dmmu_base from cfg_hostres struct staging: tidspbridge - remove reserved memory clean up staging: tidspbridge - deprecate reserve/unreserve_memory funtions staging: tidspbridge - remove dmm custom module drivers/staging/tidspbridge/Makefile |7 +- drivers/staging/tidspbridge/core/_deh.h|5 +- drivers/staging/tidspbridge/core/_tiomap.h | 19 +- drivers/staging/tidspbridge/core/dsp-mmu.c | 316 ++ drivers/staging/tidspbridge/core/io_sm.c | 180 +--- drivers/staging/tidspbridge/core/tiomap3430.c | 1070 ++-- drivers/staging/tidspbridge/core/tiomap3430_pwr.c |4 - drivers/staging/tidspbridge/core/tiomap_io.c | 17 +- drivers/staging/tidspbridge/core/ue_deh.c | 115 +--- drivers/staging/tidspbridge/hw/EasiGlobal.h| 41 - drivers/staging/tidspbridge/hw/MMUAccInt.h | 76 -- drivers/staging/tidspbridge/hw/MMURegAcM.h | 225 drivers/staging/tidspbridge/hw/hw_defs.h | 58 -- drivers/staging/tidspbridge/hw/hw_mmu.c| 562 -- drivers/staging/tidspbridge/hw/hw_mmu.h| 163 --- .../tidspbridge/include/dspbridge/cfgdefs.h|1 - .../staging/tidspbridge/include/dspbridge/dev.h| 24 - .../staging/tidspbridge/include/dspbridge/dmm.h| 75 -- .../staging/tidspbridge/include/dspbridge/drv.h| 10 - .../tidspbridge/include/dspbridge/dsp-mmu.h| 67 ++ .../tidspbridge/include/dspbridge/dspdefs.h| 44 - .../tidspbridge/include/dspbridge/dspioctl.h |7 - .../staging/tidspbridge/include/dspbridge/proc.h | 46 - drivers/staging/tidspbridge/pmgr/dev.c | 63 +-- drivers/staging/tidspbridge/pmgr/dmm.c | 533 -- drivers/staging/tidspbridge/pmgr/dspapi.c | 34 +- drivers/staging/tidspbridge/rmgr/drv.c | 15 - drivers/staging/tidspbridge/rmgr/drv_interface.c |2 - drivers/staging/tidspbridge/rmgr/node.c| 48 +- drivers/staging/tidspbridge/rmgr/proc.c| 197 + 30 files changed, 568 insertions(+), 3456 deletions(-) create mode 100644 drivers/staging/tidspbridge/core/dsp-mmu.c delete mode 100644 drivers/staging/tidspbridge/hw/EasiGlobal.h delete mode 100644 drivers/staging/tidspbridge/hw/MMUAccInt.h delete mode 100644 drivers/staging/tidspbridge/hw/MMURegAcM.h delete mode 100644 drivers/staging/tidspbridge/hw/hw_defs.h delete mode 100644 drivers/staging/tidspbridge/hw/hw_mmu.c delete mode 100644 drivers/staging/tidspbridge/hw/hw_mmu.h delete mode 100644 drivers/staging/tidspbridge/include/dspbridge/dmm.h create mode 100644 drivers/staging/tidspbridge/include/dspbridge/dsp-mmu.h delete mode 100644 drivers/staging/tidspbridge/pmgr/dmm.c -- 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
[PATCHv2 03/11] staging: tidspbridge - rename bridge_brd_mem_map/unmap to a proper name
Now these functions only map user space addresses to dsp virtual
addresses, so now the functions have a more meaningful name.
Also now user_to_dsp_map returns the mapped address.
Signed-off-by: Fernando Guzman Lugo
---
drivers/staging/tidspbridge/core/_tiomap.h | 24 +++
drivers/staging/tidspbridge/core/tiomap3430.c | 153 ++--
.../tidspbridge/include/dspbridge/dspdefs.h| 44 --
drivers/staging/tidspbridge/pmgr/dev.c |2 -
drivers/staging/tidspbridge/rmgr/proc.c| 34 +++--
5 files changed, 116 insertions(+), 141 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/_tiomap.h
b/drivers/staging/tidspbridge/core/_tiomap.h
index c1bf95d..8777492 100644
--- a/drivers/staging/tidspbridge/core/_tiomap.h
+++ b/drivers/staging/tidspbridge/core/_tiomap.h
@@ -383,4 +383,28 @@ extern s32 dsp_debug;
*/
int sm_interrupt_dsp(struct bridge_dev_context *dev_context, u16 mb_val);
+/**
+ * user_to_dsp_map() - maps user to dsp virtual address
+ * @mmu: Pointer to iommu handle.
+ * @uva: Virtual user space address.
+ * @da DSP address
+ * @size Buffer size to map.
+ * @usr_pgsstruct page array pointer where the user pages will be stored
+ *
+ * This function maps a user space buffer into DSP virtual address.
+ *
+ */
+u32 user_to_dsp_map(struct iommu *mmu, u32 uva, u32 da, u32 size,
+ struct page **usr_pgs);
+
+/**
+ * user_to_dsp_unmap() - unmaps DSP virtual buffer.
+ * @mmu: Pointer to iommu handle.
+ * @da DSP address
+ *
+ * This function unmaps a user space buffer into DSP virtual address.
+ *
+ */
+int user_to_dsp_unmap(struct iommu *mmu, u32 da);
+
#endif /* _TIOMAP_ */
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c
b/drivers/staging/tidspbridge/core/tiomap3430.c
index 721116b..8825700 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -95,12 +95,6 @@ static int bridge_brd_mem_copy(struct bridge_dev_context
*dev_ctxt,
static int bridge_brd_mem_write(struct bridge_dev_context *dev_ctxt,
u8 *host_buff, u32 dsp_addr,
u32 ul_num_bytes, u32 mem_type);
-static int bridge_brd_mem_map(struct bridge_dev_context *dev_ctxt,
- u32 ul_mpu_addr, u32 virt_addr,
- u32 ul_num_bytes, u32 ul_map_attr,
- struct page **mapped_pages);
-static int bridge_brd_mem_un_map(struct bridge_dev_context *dev_ctxt,
-u32 da);
static int bridge_dev_create(struct bridge_dev_context
**dev_cntxt,
struct dev_object *hdev_obj,
@@ -108,9 +102,6 @@ static int bridge_dev_create(struct bridge_dev_context
static int bridge_dev_ctrl(struct bridge_dev_context *dev_context,
u32 dw_cmd, void *pargs);
static int bridge_dev_destroy(struct bridge_dev_context *dev_ctxt);
-static int get_io_pages(struct mm_struct *mm, u32 uva, unsigned pages,
- struct page **usr_pgs);
-static u32 user_va2_pa(struct mm_struct *mm, u32 address);
static int pte_update(struct bridge_dev_context *dev_ctxt, u32 pa,
u32 va, u32 size,
struct hw_mmu_map_attrs_t *map_attrs);
@@ -180,8 +171,6 @@ static struct bridge_drv_interface drv_interface_fxns = {
bridge_brd_set_state,
bridge_brd_mem_copy,
bridge_brd_mem_write,
- bridge_brd_mem_map,
- bridge_brd_mem_un_map,
/* The following CHNL functions are provided by chnl_io.lib: */
bridge_chnl_create,
bridge_chnl_destroy,
@@ -1151,22 +1140,77 @@ static int bridge_brd_mem_write(struct
bridge_dev_context *dev_ctxt,
}
/*
- * bridge_brd_mem_map
- * This function maps MPU buffer to the DSP address space. It performs
- * linear to physical address translation if required. It translates each
- * page since linear addresses can be physically non-contiguous
- * All address & size arguments are assumed to be page aligned (in proc.c)
+ * user_va2_pa
+ * Purpose:
+ * This function walks through the page tables to convert a userland
+ * virtual address to physical address
+ */
+static u32 user_va2_pa(struct mm_struct *mm, u32 address)
+{
+ pgd_t *pgd;
+ pmd_t *pmd;
+ pte_t *ptep, pte;
+
+ pgd = pgd_offset(mm, address);
+ if (!(pgd_none(*pgd) || pgd_bad(*pgd))) {
+ pmd = pmd_offset(pgd, address);
+ if (!(pmd_none(*pmd) || pmd_bad(*pmd))) {
+ ptep = pte_offset_map(pmd, address);
+ if (ptep) {
+ pte = *ptep;
+
[GIT PULL] Couple of omap fixes
Hi Linus, Please pull two omap fixes from: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-fixes-for-linus Regards, Tony The following changes since commit 899611ee7d373e5eeda08e9a8632684e1ebbbf00: Linux 2.6.36-rc6 (2010-09-28 18:01:22 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-fixes-for-linus Scott Ellis (1): omap: McBSP: tx_irq_completion used in rx_irq_handler Tony Lindgren (1): omap: Fix compile dependency to LEDS_CLASS arch/arm/plat-omap/Kconfig |2 +- arch/arm/plat-omap/mcbsp.c |2 +- 2 files changed, 2 insertions(+), 2 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
Re: [PATCH] PM: add synchronous runtime interface for interrupt handlers
On Thursday, September 30, 2010, Alan Stern wrote:
> On Thu, 30 Sep 2010, Rafael J. Wysocki wrote:
>
> > > --- usb-2.6.orig/include/linux/pm.h
> > > +++ usb-2.6/include/linux/pm.h
> > > @@ -485,6 +485,7 @@ struct dev_pm_info {
> > > unsigned intrun_wake:1;
> > > unsigned intruntime_auto:1;
> > > unsigned intno_callbacks:1;
> > > + unsigned intcallbacks_in_irq:1;
> >
> > I kind of don't like this name. What about irq_safe ?
>
> Sure, that's a better name.
>
> > > --- usb-2.6.orig/include/linux/pm_runtime.h
> > > +++ usb-2.6/include/linux/pm_runtime.h
> > > @@ -21,6 +21,7 @@
> > > #define RPM_GET_PUT 0x04/* Increment/decrement the
> > > usage_count */
> > > #define RPM_AUTO 0x08/* Use autosuspend_delay */
> > > +#define RPM_IRQ 0x10/* Don't enable interrupts */
> > >
> > > #ifdef CONFIG_PM_RUNTIME
> > >
> > > @@ -40,6 +41,7 @@ extern int pm_generic_runtime_idle(struc
> > > extern int pm_generic_runtime_suspend(struct device *dev);
> > > extern int pm_generic_runtime_resume(struct device *dev);
> > > extern void pm_runtime_no_callbacks(struct device *dev);
> > > +extern void pm_runtime_callbacks_in_irq(struct device *dev);
> >
> > Perhaps this one can be called pm_runtime_irq_safe() in analogy to the
> > struct
> > member?
>
> Yes.
>
> > Hmm. This looks rather complicated. I don't really feel good about this
> > change. It seems to me that it might be better to actually implement
> > the _irq() helpers from scratch. I think I'll try to do that.
>
> That might work out better, but there will be a substantial amount of
> code duplication. Try it and see how it turns out.
I think you're right, but I'm not sure yet.
> > Overall, it looks like there's some overlap between RPM_IRQ and
> > power.callbacks_in_irq, where the latter may influence the behavior of the
> > helpers even if RPM_IRQ is unset.
>
> Exactly. That was intentional.
>
> > I think we should return error code if RPM_IRQ is used, but
> > power.callbacks_in_irq is not set.
>
> The patch does that.
>
> > If RPM_IRQ is not set, but
> > power.callbacks_in_irq is set, we should fall back to the normal behavior
> > (ie. do not avoid sleeping).
>
> By "do not avoid sleeping", do you mean that
>
> (1) the helper functions should be allowed to sleep, or
>
> (2) the callbacks should be invoked with interrupts enabled?
>
> The patch already does (1). By contrast, (2) isn't safe. It means
> there is a risk of having one thread do a busy-wait with interrupts
> disabled, waiting for another thread that can sleep.
In my opinion the _irq operations should really be one-shot, without
any looping, waking up parents etc. I mean, if the parent is not RPM_ACTIVE,
the _irq resume should immediately fail and analogously for the _irq
suspend. And so on. As simple as reasonably possible.
> > That's why I think it's better to change the name of power.callbacks_in_irq
> > to power.irq_safe.
> >
> > Also I think we should refuse to set power.callbacks_in_irq for a device
> > whose partent (1) doesn't have power.callbacks_in_irq and (2) doesn't
> > have power.ignore_children set , and (3) doesn't have power.disable_depth >
> > 0.
> > Then, once we've set power.callbacks_in_irq for a device, we should take
> > this into consideration when trying to change the parent's settings.
>
> That's not a bad idea, but I don't know if it's necessary in practice.
> With the current patch, if you violate this condition you will simply
> encounter an error when the PM core refuses to resume a sleeping
> parent. Maybe we should allow violations and the resulting refusals
> but print a warning message in the system log.
Yes, see above. I think printing a message in case a suspended parent
prevented an _irq resume from happening, for example, is a good idea.
> > There probably is more subtelties like this, but I can't see them at the
> > moment.
>
> There are some subtle aspects related to the interplay between idle and
> the other callbacks. In principle, the idle and suspend callbacks
> doesn't need to have interrupts disabled -- we don't care if interrupt
> handlers can't do synchronous suspends; they only need synchronous
> resumes. But I wanted to keep things simple, so I treated all the
> callbacks the same.
OK
> Going further, I'm still a little dubious about the whole point of
> having idle notifications at all. I don't see why the PM core can't
> notify a subsystem that a device is idle just by calling the
> runtime_suspend routine.
Well, calling _idle is like saying "I think this device may be idle, please
consider suspending it", while calling _suspend is like saying "suspend
this device unless you can't". I think that's enough of a difference to
have separate _idle.
> The routine doesn't have to suspend if it
> doesn't want to, and it can always schedule a delayed suspe
Re: [PATCH] [OMAP] HTCHERALD: MMC, I2C, HTCPLD, SPI, TSC2046
* Tony Lindgren [100930 12:07]:
> * Michał Mirosław [100930 11:57]:
> > 2010/9/30 Tony Lindgren :
> > > * Cory Maccarrone [100930 11:34]:
> > >> > Looks like also board-sx1-mmc.c and board-h[23]-mmc.c have the
> > >> > same spotty voltage range.
> > >> > Cory, care to do a patch that fixes it for all of them?
> > >> Yeah, I can do that. I'll resubmit this patch too with the fixed up
> > >> ranges.
> > > Turns out I already did it :) Care to test/ack this one?
> >
> > [...]
> > > diff --git a/arch/arm/mach-omap1/board-sx1-mmc.c
> > > b/arch/arm/mach-omap1/board-sx1-mmc.c
> > > index 5b33ae8..be5a365 100644
> > > --- a/arch/arm/mach-omap1/board-sx1-mmc.c
> > > +++ b/arch/arm/mach-omap1/board-sx1-mmc.c
> > > @@ -44,7 +44,8 @@ static struct omap_mmc_platform_data mmc1_data = {
> > > .nr_slots = 1,
> > > .slots[0] = {
> > > .set_power = mmc_set_power,
> > > - .ocr_mask = MMC_VDD_28_29 | MMC_VDD_30_31 |
> > > + .ocr_mask = MMC_VDD_28_29 | MMC_VDD_29_30 |
> > > + MMC_VDD_30_31 | MMC_VDD_31_32 |
> > > MMC_VDD_32_33 | MMC_VDD_33_34,
> > > .name = "mmcblk",
> > > },
> > [...]
> >
> > Al least this one seems wrong (haven't checked others) as the
> > mmc_set_power() ignores vdd parameter. This suggests that the board
> > supports only one particular voltage, not the whole range.
>
> Hmm yeah good catch. With the external power it's board specific.
Most likely they all support only 3.3V cards except for n8x0. Not changing
the n8x0 for what voltages it handles although it may be missing the
MMC_VDD_27_28 voltage. Here's the updated patch.
Regards,
Tony
From: Tony Lindgren
Subject: [PATCH] omap: Fix spotty MMC voltages
As noted by Michał Mirosław , the voltages should
cover the supported voltage range, or support only one voltage.
As all these boards are using a GPIO to enable the power, chances
are that only 3.3V cards are supported on these boards.
Reported-by: Michał Mirosław
Signed-off-by: Tony Lindgren
diff --git a/arch/arm/mach-omap1/board-h2-mmc.c
b/arch/arm/mach-omap1/board-h2-mmc.c
index b30c499..f2fc43d 100644
--- a/arch/arm/mach-omap1/board-h2-mmc.c
+++ b/arch/arm/mach-omap1/board-h2-mmc.c
@@ -58,8 +58,7 @@ static struct omap_mmc_platform_data mmc1_data = {
.dma_mask = 0x,
.slots[0] = {
.set_power = mmc_set_power,
- .ocr_mask = MMC_VDD_28_29 | MMC_VDD_30_31 |
- MMC_VDD_32_33 | MMC_VDD_33_34,
+ .ocr_mask = MMC_VDD_32_33 | MMC_VDD_33_34,
.name = "mmcblk",
},
};
diff --git a/arch/arm/mach-omap1/board-h3-mmc.c
b/arch/arm/mach-omap1/board-h3-mmc.c
index 54b0f06..2098525 100644
--- a/arch/arm/mach-omap1/board-h3-mmc.c
+++ b/arch/arm/mach-omap1/board-h3-mmc.c
@@ -40,8 +40,7 @@ static struct omap_mmc_platform_data mmc1_data = {
.dma_mask = 0x,
.slots[0] = {
.set_power = mmc_set_power,
- .ocr_mask = MMC_VDD_28_29 | MMC_VDD_30_31 |
- MMC_VDD_32_33 | MMC_VDD_33_34,
+ .ocr_mask = MMC_VDD_32_33 | MMC_VDD_33_34,
.name = "mmcblk",
},
};
diff --git a/arch/arm/mach-omap1/board-htcherald.c
b/arch/arm/mach-omap1/board-htcherald.c
index 7ea75c1..88c97e2 100644
--- a/arch/arm/mach-omap1/board-htcherald.c
+++ b/arch/arm/mach-omap1/board-htcherald.c
@@ -410,8 +410,7 @@ static struct omap_mmc_platform_data htc_mmc1_data = {
.nr_slots = 1,
.switch_slot= NULL,
.slots[0] = {
- .ocr_mask = MMC_VDD_28_29 | MMC_VDD_30_31 |
- MMC_VDD_32_33 | MMC_VDD_33_34,
+ .ocr_mask = MMC_VDD_32_33 | MMC_VDD_33_34,
.name = "mmcblk",
.nomux = 1,
.wires = 4,
diff --git a/arch/arm/mach-omap1/board-sx1-mmc.c
b/arch/arm/mach-omap1/board-sx1-mmc.c
index 5b33ae8..e8ddd86 100644
--- a/arch/arm/mach-omap1/board-sx1-mmc.c
+++ b/arch/arm/mach-omap1/board-sx1-mmc.c
@@ -44,8 +44,7 @@ static struct omap_mmc_platform_data mmc1_data = {
.nr_slots = 1,
.slots[0] = {
.set_power = mmc_set_power,
- .ocr_mask = MMC_VDD_28_29 | MMC_VDD_30_31 |
- MMC_VDD_32_33 | MMC_VDD_33_34,
+ .ocr_mask = MMC_VDD_32_33 | MMC_VDD_33_34,
.name
Re: [PATCH] PM: add synchronous runtime interface for interrupt handlers
On Thursday, September 30, 2010, Alan Stern wrote:
> This patch (as1431) adds a synchronous runtime-PM interface suitable
> for use in interrupt handlers. Four new helper functions are defined:
>
> pm_runtime_suspend_irq(), pm_runtime_resume_irq(),
> pm_runtime_get_sync_irq(), pm_runtime_put_sync_irq(),
>
> together with pm_runtime_callbacks_in_irq(), which subsystems use to
> tell the PM core that the runtime callbacks should be invoked with
> interrupts disabled.
BTW, I like some changes made by your patch that aren't really related to
the issue at hand, so I think the patch below can be applied regardless of
the other changes, unless I made a mistake I can see now.
Thanks,
Rafael
---
drivers/base/power/runtime.c | 123 +--
1 file changed, 51 insertions(+), 72 deletions(-)
Index: linux-2.6/drivers/base/power/runtime.c
===
--- linux-2.6.orig/drivers/base/power/runtime.c
+++ linux-2.6/drivers/base/power/runtime.c
@@ -153,6 +153,27 @@ static int rpm_check_suspend_allowed(str
return retval;
}
+/**
+ * rpm_callback - Run a given runtime PM callback for a given device.
+ * @cb: Runtime PM callback to run.
+ * @dev: Device to run the callback for.
+ */
+static int rpm_callback(int (*cb)(struct device *), struct device *dev)
+ __releases(&dev->power.lock) __acquires(&dev->power.lock)
+{
+ int retval;
+
+ if (!cb)
+ return -ENOSYS;
+
+ spin_unlock_irq(&dev->power.lock);
+
+ retval = cb(dev);
+
+ spin_lock_irq(&dev->power.lock);
+
+ return retval;
+}
/**
* rpm_idle - Notify device bus type if the device can be suspended.
@@ -167,8 +188,8 @@ static int rpm_check_suspend_allowed(str
* This function must be called under dev->power.lock with interrupts disabled.
*/
static int rpm_idle(struct device *dev, int rpmflags)
- __releases(&dev->power.lock) __acquires(&dev->power.lock)
{
+ int (*callback)(struct device *);
int retval;
retval = rpm_check_suspend_allowed(dev);
@@ -214,26 +235,16 @@ static int rpm_idle(struct device *dev,
dev->power.idle_notification = true;
- if (dev->bus && dev->bus->pm && dev->bus->pm->runtime_idle) {
- spin_unlock_irq(&dev->power.lock);
-
- dev->bus->pm->runtime_idle(dev);
-
- spin_lock_irq(&dev->power.lock);
- } else if (dev->type && dev->type->pm && dev->type->pm->runtime_idle) {
- spin_unlock_irq(&dev->power.lock);
-
- dev->type->pm->runtime_idle(dev);
-
- spin_lock_irq(&dev->power.lock);
- } else if (dev->class && dev->class->pm
- && dev->class->pm->runtime_idle) {
- spin_unlock_irq(&dev->power.lock);
+ if (dev->bus && dev->bus->pm && dev->bus->pm->runtime_idle)
+ callback = dev->bus->pm->runtime_idle;
+ else if (dev->type && dev->type->pm && dev->type->pm->runtime_idle)
+ callback = dev->type->pm->runtime_idle;
+ else if (dev->class && dev->class->pm)
+ callback = dev->class->pm->runtime_idle;
+ else
+ callback = NULL;
- dev->class->pm->runtime_idle(dev);
-
- spin_lock_irq(&dev->power.lock);
- }
+ rpm_callback(callback, dev);
dev->power.idle_notification = false;
wake_up_all(&dev->power.wait_queue);
@@ -261,6 +272,7 @@ static int rpm_idle(struct device *dev,
static int rpm_suspend(struct device *dev, int rpmflags)
__releases(&dev->power.lock) __acquires(&dev->power.lock)
{
+ int (*callback)(struct device *);
struct device *parent = NULL;
bool notify = false;
int retval;
@@ -351,33 +363,16 @@ static int rpm_suspend(struct device *de
__update_runtime_status(dev, RPM_SUSPENDING);
- if (dev->bus && dev->bus->pm && dev->bus->pm->runtime_suspend) {
- spin_unlock_irq(&dev->power.lock);
-
- retval = dev->bus->pm->runtime_suspend(dev);
-
- spin_lock_irq(&dev->power.lock);
- dev->power.runtime_error = retval;
- } else if (dev->type && dev->type->pm
- && dev->type->pm->runtime_suspend) {
- spin_unlock_irq(&dev->power.lock);
-
- retval = dev->type->pm->runtime_suspend(dev);
-
- spin_lock_irq(&dev->power.lock);
- dev->power.runtime_error = retval;
- } else if (dev->class && dev->class->pm
- && dev->class->pm->runtime_suspend) {
- spin_unlock_irq(&dev->power.lock);
-
- retval = dev->class->pm->runtime_suspend(dev);
-
- spin_lock_irq(&dev->power.lock);
- dev->power.runtime_error = retval;
- } else {
- retval = -ENOSYS;
- }
+ if (dev->bus && dev->bus->pm && dev->bus->pm->runtime_suspend)
+ callback =
Re: [PATCHv3 11/17] dmtimer: early boot infrastructure
On 9/21/2010 10:54 AM, DebBarma, Tarun Kanti wrote:
During dmtimer early init, when device model is not up yet and dmtimer
devices are not yet registered, the initialization routine is unable
to read clock sources supported by the dmtimers using clk_get() because
it searches the list using device names. This problem is overcome by
assigning timer device names to the .init_name field. The advantage is
that there is one common set of routines for clock access routines for
early init and normal access.
This patch also modifies the name of millisecond timers (1,2,10) on
OMAP3 and OMAP4 from"timer_1ms" to "timer". This means all timers
typo
So here is the change that is mentioned already in the code 6 patches
before...
You don't have to split that in 2 patches. You can introduce the new
name in the first hwmod data patch since that will not impact your code.
Moreover that will avoid discrepancies between the comments in the code
and the code.
now have common name. This is to allow any one of the available timers
as an early timer instead of restricting it just to millisecond timers.
The hwmod routine which searches by class name can now search and find
all timers for initialization and bind to device model during early init.
Signed-off-by: Tarun Kanti DebBarma
Cc: Cousson, Benoit
Cc: Paul Walmsley
Cc: Kevin Hilman
Cc: Tony Lindgren
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 91
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 91
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 86 ++-
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 86 ++-
4 files changed, 352 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index b3dd8ac..fc761a5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -177,6 +177,85 @@ static struct omap_hwmod_class omap2420_timer_hwmod_class
= {
.rev = OMAP_TIMER_IP_VERSION_1,
};
+/*
+ * during dmtimer early init, when device model is not up yet and dmtimer
+ * devices are not yet registered, the initialization routine is unable
+ * to read clock sources supported by the dmtimers using clk_get() because
+ * it searches the list using device names. this problem is overcome by
+ * assigning timer device names to the .init_name field.
+ */
+static struct omap_device timer1_init_name = {
+ .pdev = {
+ .dev = { .init_name = "dmtimer.0" },
And here is the reason why you added an include to omap_device.h 8
patches ago.
You should not do that, at all. hwmod is about SOC HW information only.
It will be use by omap_device, but it does not have to know anything
about the layer above it.
Moreover, in that case, you can easily extract the device name using the
hwmod name, so you can build these devices dynamically and only if
needed at init time.
+ },
+};
+
+static struct omap_device timer2_init_name = {
+ .pdev = {
+ .dev = { .init_name = "dmtimer.1" },
+ },
+};
+
+static struct omap_device timer3_init_name = {
+ .pdev = {
+ .dev = { .init_name = "dmtimer.2" },
+ },
+};
+
+static struct omap_device timer4_init_name = {
+ .pdev = {
+ .dev = { .init_name = "dmtimer.3" },
+ },
+};
+
+static struct omap_device timer5_init_name = {
+ .pdev = {
+ .dev = { .init_name = "dmtimer.4" },
+ },
+};
+
+static struct omap_device timer6_init_name = {
+ .pdev = {
+ .dev = { .init_name = "dmtimer.5" },
+ },
+};
+
+static struct omap_device timer7_init_name = {
+ .pdev = {
+ .dev = { .init_name = "dmtimer.6" },
+ },
+};
+
+static struct omap_device timer8_init_name = {
+ .pdev = {
+ .dev = { .init_name = "dmtimer.7" },
+ },
+};
+
+static struct omap_device timer9_init_name = {
+ .pdev = {
+ .dev = { .init_name = "dmtimer.8" },
+ },
+};
+
+static struct omap_device timer10_init_name = {
+ .pdev = {
+ .dev = { .init_name = "dmtimer.9" },
+ },
+};
+
+static struct omap_device timer11_init_name = {
+ .pdev = {
+ .dev = { .init_name = "dmtimer.10" },
+ },
+};
+
+static struct omap_device timer12_init_name = {
+ .pdev = {
+ .dev = { .init_name = "dmtimer.11" },
+ },
+};
+
/* timer1 */
static struct omap_hwmod omap2420_timer1_hwmod;
static struct omap_hwmod_irq_info omap2420_timer1_mpu_irqs[] = {
@@ -223,6 +302,7 @@ static struct omap_hwmod omap2420_timer1_hwmod = {
.slaves = omap2420_timer1_slaves,
.slaves_cnt = ARRAY_SIZE(omap2420_timer1_slaves),
.class =&omap2420_timer_hwmod_class,
+ .od =&timer1_init_name,
And don't do that either... this is internal pointer pop
Re: [PATCH] PM: add synchronous runtime interface for interrupt handlers
On Thu, 30 Sep 2010, Rafael J. Wysocki wrote:
> > --- usb-2.6.orig/include/linux/pm.h
> > +++ usb-2.6/include/linux/pm.h
> > @@ -485,6 +485,7 @@ struct dev_pm_info {
> > unsigned intrun_wake:1;
> > unsigned intruntime_auto:1;
> > unsigned intno_callbacks:1;
> > + unsigned intcallbacks_in_irq:1;
>
> I kind of don't like this name. What about irq_safe ?
Sure, that's a better name.
> > --- usb-2.6.orig/include/linux/pm_runtime.h
> > +++ usb-2.6/include/linux/pm_runtime.h
> > @@ -21,6 +21,7 @@
> > #define RPM_GET_PUT0x04/* Increment/decrement the
> > usage_count */
> > #define RPM_AUTO 0x08/* Use autosuspend_delay */
> > +#define RPM_IRQ0x10/* Don't enable interrupts */
> >
> > #ifdef CONFIG_PM_RUNTIME
> >
> > @@ -40,6 +41,7 @@ extern int pm_generic_runtime_idle(struc
> > extern int pm_generic_runtime_suspend(struct device *dev);
> > extern int pm_generic_runtime_resume(struct device *dev);
> > extern void pm_runtime_no_callbacks(struct device *dev);
> > +extern void pm_runtime_callbacks_in_irq(struct device *dev);
>
> Perhaps this one can be called pm_runtime_irq_safe() in analogy to the struct
> member?
Yes.
> Hmm. This looks rather complicated. I don't really feel good about this
> change. It seems to me that it might be better to actually implement
> the _irq() helpers from scratch. I think I'll try to do that.
That might work out better, but there will be a substantial amount of
code duplication. Try it and see how it turns out.
> Overall, it looks like there's some overlap between RPM_IRQ and
> power.callbacks_in_irq, where the latter may influence the behavior of the
> helpers even if RPM_IRQ is unset.
Exactly. That was intentional.
> I think we should return error code if RPM_IRQ is used, but
> power.callbacks_in_irq is not set.
The patch does that.
> If RPM_IRQ is not set, but
> power.callbacks_in_irq is set, we should fall back to the normal behavior
> (ie. do not avoid sleeping).
By "do not avoid sleeping", do you mean that
(1) the helper functions should be allowed to sleep, or
(2) the callbacks should be invoked with interrupts enabled?
The patch already does (1). By contrast, (2) isn't safe. It means
there is a risk of having one thread do a busy-wait with interrupts
disabled, waiting for another thread that can sleep.
> That's why I think it's better to change the name of power.callbacks_in_irq
> to power.irq_safe.
>
> Also I think we should refuse to set power.callbacks_in_irq for a device
> whose partent (1) doesn't have power.callbacks_in_irq and (2) doesn't
> have power.ignore_children set , and (3) doesn't have power.disable_depth > 0.
> Then, once we've set power.callbacks_in_irq for a device, we should take
> this into consideration when trying to change the parent's settings.
That's not a bad idea, but I don't know if it's necessary in practice.
With the current patch, if you violate this condition you will simply
encounter an error when the PM core refuses to resume a sleeping
parent. Maybe we should allow violations and the resulting refusals
but print a warning message in the system log.
> There probably is more subtelties like this, but I can't see them at the
> moment.
There are some subtle aspects related to the interplay between idle and
the other callbacks. In principle, the idle and suspend callbacks
doesn't need to have interrupts disabled -- we don't care if interrupt
handlers can't do synchronous suspends; they only need synchronous
resumes. But I wanted to keep things simple, so I treated all the
callbacks the same.
Going further, I'm still a little dubious about the whole point of
having idle notifications at all. I don't see why the PM core can't
notify a subsystem that a device is idle just by calling the
runtime_suspend routine. The routine doesn't have to suspend if it
doesn't want to, and it can always schedule a delayed suspend or an
autosuspend. Maybe you know of a use case where having explicit idle
notifications really does help, but I can't think of any.
One more thing: I'm not sure we really need the "notify" variable in
rpm_suspend. When a suspend callback fails, it means the device is in
use. Whatever is using the device should then be responsible for
sending its own idle notification when it is finished; we shouldn't
need to send a notification as soon as the suspend callback fails.
Also, this can theoretically lead to nasty loops. Suspend callback
fails, idle notification gets sent, the runtime_idle routine tries to
do another pm_runtime_suspend, rinse and repeat... This is made even
worse by the fact that the rpm_idle call after a failed suspend isn't
asynchronous -- you could overflow the kernel's stack. Relying on the
driver to be properly written doesn't help: The device could become
busy when each suspend is about to beg
Re: [PATCHv3 6/17] dmtimer: add omap44xx hwmod database
All the comments of the previous patch are applicable here too.
+ some more...
On 9/21/2010 10:53 AM, DebBarma, Tarun Kanti wrote:
From: Thara Gopinath
I wrote the original patch for the OMAP4 hwmod data, so I should still
be the author.
You should add as well a reference to the original patch.
This patch adds hwmod database for OMAP44xx.
In the hwmod class definition .rev field is
initialized with timer ip version to distinguish
the timers in different OMAP platforms.
Then I should have my signed-off-by here.
Signed-off-by: Partha Basak
Signed-off-by: Thara Gopinath
Signed-off-by: Tarun Kanti DebBarma
Cc: Cousson, Benoit
Cc: Paul Walmsley
Cc: Kevin Hilman
Cc: Tony Lindgren
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 660
1 files changed, 660 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index e20b0ee..28d65e9 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -23,6 +23,8 @@
#include
#include
+#include
+#include
#include "omap_hwmod_common_data.h"
#include "cm.h"
@@ -452,6 +454,651 @@ static struct omap_hwmod omap44xx_mpu_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
+/*
+ * 'timer' class
+ * general purpose timer module with accurate 1ms tick
+ * This class contains several variants: ['timer_1ms', 'timer']
+ */
+static char *timer_clk_src_names[] = {
+ "sys_clkin_ck",
+ "sys_32k_ck",
+ NULL,
+};
+
+static char *timer_clk_src_names_abe[] = {
+ "syc_clk_div_ck",
+ "sys_32k_ck",
+ NULL,
+};
Nothing new here, but that extra complexity added by the different ABE
sys_clk does show that we have to find a better way to select the source
clock.
+
+static struct omap_timer_dev_attr timer_dev_attr = {
+ .clk_names = timer_clk_src_names,
+};
+
+static struct omap_timer_dev_attr timer_dev_attr_abe = {
+ .clk_names = timer_clk_src_names_abe,
+};
+
+static struct omap_hwmod_class_sysconfig omap44xx_timer_1ms_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE |
+ SYSS_MISSING),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields=&omap_hwmod_sysc_type1,
+};
+
+/*
+ * during early boot when device model is not fully up and running
+ * any one of the dmtimers could be used by gmtimer implementation
+ * to provide system ticks. in order to enable hwmod api to search
+ * all the dmtimers irrespective of the class (ms and non-ms) it
+ * belongs the .name field is assigned a uniform name 'timer'.
+ */
+static struct omap_hwmod_class omap44xx_timer_1ms_hwmod_class = {
+ .name = "timer_1ms",
+ .sysc =&omap44xx_timer_1ms_sysc,
+ .rev = OMAP_TIMER_IP_VERSION_1,
+};
+
+static struct omap_hwmod_class_sysconfig omap44xx_timer_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_EMUFREE |
+ SYSC_HAS_SOFTRESET | SYSS_MISSING),
The reset status flag is still missing, but in that case it should be
the SYSC_HAS_RESET_STATUS flag.
Regards,
Benoit
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields=&omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap44xx_timer_hwmod_class = {
+ .name = "timer",
+ .sysc =&omap44xx_timer_sysc,
+ .rev = OMAP_TIMER_IP_VERSION_2,
+};
+
+/* timer1 */
+static struct omap_hwmod omap44xx_timer1_hwmod;
+static struct omap_hwmod_irq_info omap44xx_timer1_irqs[] = {
+ { .irq = 37 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_timer1_addrs[] = {
+ {
+ .pa_start = 0x4a318000,
+ .pa_end = 0x4a31807f,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_wkup -> timer1 */
+static struct omap_hwmod_ocp_if omap44xx_l4_wkup__timer1 = {
+ .master =&omap44xx_l4_wkup_hwmod,
+ .slave =&omap44xx_timer1_hwmod,
+ .clk= "l4_wkup_clk_mux_ck",
+ .addr = omap44xx_timer1_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_timer1_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* timer1 slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_timer1_slaves[] = {
+&omap44xx_l4_wkup__timer1,
+};
+
+static struct omap_hwmod omap44xx_timer1_hwmod = {
+ .name = "timer1",
+ .class =&omap44xx_timer_1ms_hwmod_class,
+ .mpu_irqs = omap44xx_timer1_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_timer1_irqs),
+ .main_clk
Re: [PATCHv3 5/17] dmtimer: add omap3xxx hwmod database
All the comments of the previous patch are applicable here too.
+ some more...
On 9/21/2010 10:52 AM, DebBarma, Tarun Kanti wrote:
From: Thara Gopinath
This patch adds hwmod database for OMAP3xxx.
In the hwmod class definition .rev field is
initialized with timer ip version to distinguish
the timers in different OMAP platforms.
Signed-off-by: Partha Basak
Signed-off-by: Thara Gopinath
Signed-off-by: Tarun Kanti DebBarma
Cc: Cousson, Benoit
Cc: Paul Walmsley
Cc: Kevin Hilman
Cc: Tony Lindgren
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 705
1 files changed, 705 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 5d8eb58..70446d7 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -18,6 +18,8 @@
#include
#include
+#include
+#include
#include "omap_hwmod_common_data.h"
#include "prm-regbits-34xx.h"
@@ -100,6 +102,176 @@ static struct omap_hwmod_ocp_if
*omap3xxx_l4_core_masters[] = {
&omap3xxx_l4_core__l4_wkup,
};
+/* timer dev_attr definition */
+static char *timer_clk_src_names[] = {
+ "sys_ck",
+ "omap_32k_fck",
+ NULL,
+};
+
+static struct omap_timer_dev_attr timer_dev_attr = {
+ .clk_names = timer_clk_src_names,
+};
+
+/* timer class */
+static struct omap_hwmod_class_sysconfig omap3xxx_timer_1ms_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields=&omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap3xxx_timer_1ms_hwmod_class = {
+ .name = "timer_1ms",
+ .sysc =&omap3xxx_timer_1ms_sysc,
+ .rev = OMAP_TIMER_IP_VERSION_1,
+};
+
+
+static struct omap_hwmod_class_sysconfig omap3xxx_timer_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_ENAWAKEUP |
+ SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields=&omap_hwmod_sysc_type2,
+};
+
+/*
+ * during early boot when device model is not fully up and running
+ * any one of the dmtimers could be used by gmtimer implementation
+ * to provide system ticks. in order to enable hwmod api to search
+ * all the dmtimers irrespective of the class (ms and non-ms) it
+ * belongs the .name field is assigned a uniform name 'timer'.
+ */
So why is the previous one still named timer_1ms?
+static struct omap_hwmod_class omap3xxx_timer_1ms_hwmod_class = {
+ .name = "timer_1ms",
I didn't like that change at first time, but then I realized that this
is probably the best way to express the common part in 2 slightly
different IPs that will belong to the same driver.
But now, I do not understand how it can work, since you didn't change
the name???
Benoit
+static struct omap_hwmod_class omap3xxx_timer_hwmod_class = {
+ .name = "timer",
+ .sysc =&omap3xxx_timer_sysc,
+ .rev = OMAP_TIMER_IP_VERSION_1,
+};
+
+
+/* timer10 */
+static struct omap_hwmod omap3xxx_timer10_hwmod;
+static struct omap_hwmod_irq_info omap3xxx_timer10_mpu_irqs[] = {
+ { .irq = INT_24XX_GPTIMER10, },
+};
+
+static struct omap_hwmod_addr_space omap3xxx_timer10_addrs[] = {
+ {
+ .pa_start = 0x48086000,
+ .pa_end = 0x48086000 + SZ_1K - 1,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_core -> timer10 */
+static struct omap_hwmod_ocp_if omap3xxx_l4_core__timer10 = {
+ .master =&omap3xxx_l4_core_hwmod,
+ .slave =&omap3xxx_timer10_hwmod,
+ .clk= "gpt10_ick",
+ .addr = omap3xxx_timer10_addrs,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_timer10_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* timer10 master port */
+static struct omap_hwmod_ocp_if *omap3xxx_timer10_masters[] = {
+&omap3xxx_l4_core__timer10,
+};
+
+/* timer10 slave port */
+static struct omap_hwmod_ocp_if *omap3xxx_timer10_slaves[] = {
+&omap3xxx_l4_core__timer10,
+};
+
+/* timer10 hwmod */
+static struct omap_hwmod omap3xxx_timer10_hwmod = {
+ .name = "timer10",
+ .mpu_irqs = omap3xxx_timer10_mpu_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap3xxx_timer10_mpu_irqs),
+ .main_clk = "gpt10_fck",
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP24XX_EN_GPT10_SHIFT,
+ .
Re: [PATCHv3 4/17] dmtimer: add omap2430 hwmod database
All the comments of the previous patch are applicable here too.
+ a new one that I forgot in previous patches...
On 9/21/2010 10:52 AM, DebBarma, Tarun Kanti wrote:
From: Thara Gopinath
This patch adds hwmod database for OMAP2430.
In the hwmod class definition .rev field is
initialized with timer ip version to distinguish
the timers in different OMAP platforms.
Signed-off-by: Partha Basak
Signed-off-by: Thara Gopinath
Signed-off-by: Tarun Kanti DebBarma
The order of the sign-off does matter. The original author should be the
first, and then next contributor will follow with potentially a small
explanation of what he did on top of the original author, if that does
make apply.
Benoit
Cc: Cousson, Benoit
Cc: Paul Walmsley
Cc: Kevin Hilman
Cc: Tony Lindgren
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 620
1 files changed, 620 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 4526628..4b43fb9 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -16,6 +16,8 @@
#include
#include
+#include
+#include
#include "omap_hwmod_common_data.h"
#include "prm-regbits-24xx.h"
@@ -127,6 +129,612 @@ static struct omap_hwmod_ocp_if *omap2430_mpu_masters[] =
{
&omap2430_mpu__l3_main,
};
+/* Timer Common */
+static char *timer_clk_src_names[] = {
+ "sys_ck",
+ "func_32k_ck",
+ "alt_ck",
+ NULL
+};
+
+static struct omap_timer_dev_attr timer_dev_attr = {
+ .clk_names = timer_clk_src_names,
+};
+
+static struct omap_hwmod_class_sysconfig omap2430_timer_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields=&omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2430_timer_hwmod_class = {
+ .name = "timer",
+ .sysc =&omap2430_timer_sysc,
+ .rev = OMAP_TIMER_IP_VERSION_1,
+};
+
+
+/* timer1 */
+static struct omap_hwmod omap2430_timer1_hwmod;
+static struct omap_hwmod_irq_info omap2430_timer1_mpu_irqs[] = {
+ { .irq = INT_24XX_GPTIMER1, },
+};
+
+static struct omap_hwmod_addr_space omap2430_timer1_addrs[] = {
+ {
+ .pa_start = 0x49018000,
+ .pa_end = 0x49018000 + SZ_1K - 1,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_wkup -> timer1 */
+static struct omap_hwmod_ocp_if omap2430_l4_wkup__timer1 = {
+ .master =&omap2430_l4_wkup_hwmod,
+ .slave =&omap2430_timer1_hwmod,
+ .clk= "gpt1_ick",
+ .addr = omap2430_timer1_addrs,
+ .addr_cnt = ARRAY_SIZE(omap2430_timer1_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* timer1 slave port */
+static struct omap_hwmod_ocp_if *omap2430_timer1_slaves[] = {
+&omap2430_l4_wkup__timer1,
+};
+
+/* timer1 hwmod */
+static struct omap_hwmod omap2430_timer1_hwmod = {
+ .name = "timer1",
+ .mpu_irqs = omap2430_timer1_mpu_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap2430_timer1_mpu_irqs),
+ .main_clk = "gpt1_fck",
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP24XX_EN_GPT1_SHIFT,
+ .module_offs = WKUP_MOD,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP24XX_EN_GPT1_SHIFT,
+ },
+ },
+ .dev_attr =&timer_dev_attr,
+ .slaves = omap2430_timer1_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap2430_timer1_slaves),
+ .class =&omap2430_timer_hwmod_class,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430)
+};
+
+
+/* timer2 */
+static struct omap_hwmod omap2430_timer2_hwmod;
+static struct omap_hwmod_irq_info omap2430_timer2_mpu_irqs[] = {
+ { .irq = INT_24XX_GPTIMER2, },
+};
+
+static struct omap_hwmod_addr_space omap2430_timer2_addrs[] = {
+ {
+ .pa_start = 0x4802a000,
+ .pa_end = 0x4802a000 + SZ_1K - 1,
+ .flags = ADDR_TYPE_RT
+ },
+};
+/* l4_core -> timer2 */
+static struct omap_hwmod_ocp_if omap2430_l4_core__timer2 = {
+ .master =&omap2430_l4_core_hwmod,
+ .slave =&omap2430_timer2_hwmod,
+ .clk= "gpt2_ick",
+ .addr = omap2430_timer2_addrs,
+ .addr_cnt = ARRAY_SIZE(omap2430_timer2_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+/* timer2 slave port */
+static struct omap_hwmod_ocp_if *omap2430_tim
Re: [PATCHv3 3/17] dmtimer: add omap2420 hwmod database
On 9/21/2010 10:51 AM, DebBarma, Tarun Kanti wrote:
From: Thara Gopinath
This patch adds hwmod database for OMAP2420.
Same comment: no patch in a a patch changelog...
In the hwmod class definition .rev field is
initialized with timer ip version to distinguish
the timers in different OMAP platforms.
Signed-off-by: Partha Basak
Signed-off-by: Thara Gopinath
Signed-off-by: Tarun Kanti DebBarma
Cc: Cousson, Benoit
Cc: Paul Walmsley
Cc: Kevin Hilman
Cc: Tony Lindgren
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 622
1 files changed, 622 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 3cc768e..6003c2e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -16,6 +16,8 @@
#include
#include
+#include
+#include
Why do you need omap_device.h here? This is probably wrong, you should
not have any dependency from hwmod HW to omap_device which is the upper
layer.
#include "omap_hwmod_common_data.h"
#include "prm-regbits-24xx.h"
@@ -121,6 +123,614 @@ static struct omap_hwmod omap2420_l4_wkup_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
.flags = HWMOD_NO_IDLEST,
};
+/* Timer Common */
+static char *timer_clk_src_names[] = {
+ "sys_ck",
+ "func_32k_ck",
+ "alt_ck",
+ NULL,
+};
I have an issue with that, because this is a pure duplication of the
clock_sel information already contained in the clock data:
static const struct clksel omap24xx_gpt_clksel[] = {
{ .parent = &func_32k_ck, .rates = gpt_32k_rates },
{ .parent = &sys_ck, .rates = gpt_sys_rates },
{ .parent = &alt_ck, .rates = gpt_alt_rates },
{ .parent = NULL },
};
And duplicating the same information somewhere else is most of the time
a bad idea.
That being said... I don't really know how to handle that properly :-)
We have to find a better way to select the proper source clock in a soc
independent way.
Maybe Paul will have some idea?
+
+static struct omap_timer_dev_attr timer_dev_attr = {
+ .clk_names = timer_clk_src_names,
+};
+
+static struct omap_hwmod_class_sysconfig omap2420_timer_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_AUTOIDLE),
Don't you have reset status in the timer? You are probably missing the
new SYSS_HAS_RESET_STATUS flag.
Regards,
Benoit
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields=&omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2420_timer_hwmod_class = {
+ .name = "timer",
+ .sysc =&omap2420_timer_sysc,
+ .rev = OMAP_TIMER_IP_VERSION_1,
+};
+
+/* timer1 */
+static struct omap_hwmod omap2420_timer1_hwmod;
+static struct omap_hwmod_irq_info omap2420_timer1_mpu_irqs[] = {
+ { .irq = INT_24XX_GPTIMER1, },
+};
+
+static struct omap_hwmod_addr_space omap2420_timer1_addrs[] = {
+ {
+ .pa_start = 0x48028000,
+ .pa_end = 0x48028000 + SZ_1K - 1,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_wkup -> timer1 */
+static struct omap_hwmod_ocp_if omap2420_l4_wkup__timer1 = {
+ .master =&omap2420_l4_wkup_hwmod,
+ .slave =&omap2420_timer1_hwmod,
+ .clk= "gpt1_ick",
+ .addr = omap2420_timer1_addrs,
+ .addr_cnt = ARRAY_SIZE(omap2420_timer1_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+/* timer1 slave port */
+static struct omap_hwmod_ocp_if *omap2420_timer1_slaves[] = {
+&omap2420_l4_wkup__timer1,
+};
+/* timer1 hwmod */
+static struct omap_hwmod omap2420_timer1_hwmod = {
+ .name = "timer1",
+ .mpu_irqs = omap2420_timer1_mpu_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap2420_timer1_mpu_irqs),
+ .main_clk = "gpt1_fck",
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP24XX_EN_GPT1_SHIFT,
+ .module_offs = WKUP_MOD,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP24XX_EN_GPT1_SHIFT,
+ },
+ },
+ .dev_attr =&timer_dev_attr,
+ .slaves = omap2420_timer1_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap2420_timer1_slaves),
+ .class =&omap2420_timer_hwmod_class,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420)
+};
+
+
+/* timer2 */
+static struct omap_hwmod omap2420_timer2_hwmod;
+static struct omap_hwmod_irq_info omap2420_timer2_mpu_irqs[] = {
+ { .irq = INT_24XX_GPTIM
Re: [PATCH V2] OMAP4 ES2: HSMMC soft reset change
* Madhusudhan Chikkature [100928 17:37]: > The omap4 es2 hsmmc has a updated soft reset logic.After the > reset is issued monitor a 0->1 transition first. The reset of > CMD or DATA lines is complete only after a 0->1->0 transition > of SRC or SRD bits. Thanks for updating this. I'll queue it for the upcoming merge window. 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: [PATCHv3 2/17] dmtimer: infrastructure to support hwmod
On 9/21/2010 10:51 AM, DebBarma, Tarun Kanti wrote:
This patch introduces data structures and new fields on
existing data structures to support dmtimer conversion
to platform driver and support hwmod database for the diferent
OMAP platforms.
Signed-off-by: Tarun Kanti DebBarma
Signed-off-by: Partha Basak
Signed-off-by: Thara Gopinath
Cc: Cousson, Benoit
Cc: Paul Walmsley
Cc: Kevin Hilman
Cc: Tony Lindgren
---
arch/arm/mach-omap2/dmtimer.h | 25 +
arch/arm/plat-omap/dmtimer.c |9 ++
arch/arm/plat-omap/include/plat/dmtimer.h | 42 +
3 files changed, 76 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/dmtimer.h
diff --git a/arch/arm/mach-omap2/dmtimer.h b/arch/arm/mach-omap2/dmtimer.h
new file mode 100644
index 000..3355725
--- /dev/null
+++ b/arch/arm/mach-omap2/dmtimer.h
@@ -0,0 +1,25 @@
+/**
+ * linux/arch/arm/mach-omap2/dmtimer.h
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ * Thara Gopinath
+ * Tarun Kanti DebBarma
+ *
+ * OMAP2 Dual-Mode Timers
+ * 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.
+ */
+
+#ifndef __ASM_ARCH_DMTIMER_H
+#define __ASM_ARCH_DMTIMER_H
+
+/*
+ * dmtimer is required during early part of boot sequence even before
+ * device model and pm_runtime if fully up and running. this function
+ * provides hook to omap2_init_common_hw() which is triggered from
+ * start_kernel()->init_irq() of kernel initalization sequence.
typo
+ */
+void __init omap2_dm_timer_early_init(void);
+
+#endif
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 44bafda..a7b1679 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -10,6 +10,12 @@
* Copyright (C) 2009 Texas Instruments
* Added OMAP4 support - Santosh Shilimkar
*
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ * Thara Gopinath
+ * Tarun Kanti DebBarma
+ * - hwmod support
+ * - omap4 support
You should try to have a much more uniform history with the previous one
from Santosh.
The funny thing is that Santosh added the omap4 support in 2009 and you
did the same in 2010:-)
+ *
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
* Free Software Foundation; either version 2 of the License, or (at your
@@ -151,6 +157,8 @@
(_OMAP_TIMER_TICK_INT_MASK_COUNT_OFFSET | (WP_TOWR<< WPSHIFT))
struct omap_dm_timer {
+ int id;
+ unsigned long fclk_rate;
unsigned long phys_base;
int irq;
#ifdef CONFIG_ARCH_OMAP2PLUS
@@ -160,6 +168,7 @@ struct omap_dm_timer {
unsigned reserved:1;
unsigned enabled:1;
unsigned posted:1;
+ struct platform_device *pdev;
};
static int dm_timer_count;
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h
b/arch/arm/plat-omap/include/plat/dmtimer.h
index 20f1054..3ec17c5 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -29,6 +29,8 @@
#ifndef __ASM_ARCH_DMTIMER_H
#define __ASM_ARCH_DMTIMER_H
+#include
+
/* clock sources */
#define OMAP_TIMER_SRC_SYS_CLK0x00
#define OMAP_TIMER_SRC_32_KHZ 0x01
@@ -44,9 +46,49 @@
#define OMAP_TIMER_TRIGGER_OVERFLOW 0x01
#define OMAP_TIMER_TRIGGER_OVERFLOW_AND_COMPARE 0x02
+/* timer ip constants */
+#define OMAP_TIMER_IP_VERSION_10x1 /* OMAP1/2/3 timers
*/
OMAP4 1ms timers are still v1, only the regular ones are in v2.
+#define OMAP_TIMER_IP_VERSION_20x2 /* OMAP4 timers */
+
+/*
+ * number of clock sources supported in the current platform.
+ * for the time being keeping it to 6 just to accomodate future.
typo
+ * expansion. currently, only upto a maximum of 3 clock sources
typo
+ * supported on OMAP4.
+ */
+#define NR_CLK_SOURCES 3
Is that 6 or 3?
+
+
+/**
+ * omap_timer_dev_attr - timer device attribute
+ *
+ * current implementation contains array of clock source names supported
+ * by different timers. for example, in the case of OMAP4, timer[5-8]
+ * supports different set of input clock sources as compared to the rest.
+ * these array of clock names are used during timer initialization to
+ * parse through timer list and obtain their corresponding struct clk*.
+ * this is subsequently used for changing the timer input clock sources
+ * by client drivers.
+ */
+struct omap_timer_dev_attr {
+ char **clk_names;
+ u32 *reg_map;
I'll comment that in the hwmod data patches, but neither the reg_map nor
the clk_name should be there.
Benoit
+};
+
struct omap_dm_timer;
struct clk;
+struct dmtimer_platform_data {
+ int (*set_timer_src)
+ (struct platform_
Re: [PATCHv3 1/17] OMAP2/3/4:dmtimer:add device names to flck nodes
On 9/21/2010 10:51 AM, DebBarma, Tarun Kanti wrote:
From: Thara Gopinath
This patch adds device name info to OMAP2 dmtimer fclk nodes so
You should avoid using "that patch" in a changelog, since we already
know it is a patch.
You can read 4.c in "The perfect patch" from Andrew Morton:
http://userweb.kernel.org/~akpm/stuff/tpp.txt
that the fclk nodes can be retrieved by doing a clk_get with the
corresponding device pointers.
...or device name.
Signed-off-by: Partha Basak
Signed-off-by: Thara Gopinath
Signed-off-by: Tarun Kanti DebBarma
Cc: Cousson, Benoit
Cc: Paul Walmsley
Cc: Kevin Hilman
Cc: Tony Lindgren
---
arch/arm/mach-omap2/clock2420_data.c | 26 +++---
arch/arm/mach-omap2/clock2430_data.c | 26 +++---
arch/arm/mach-omap2/clock3xxx_data.c | 26 +++---
arch/arm/mach-omap2/clock44xx_data.c | 24 ++--
4 files changed, 59 insertions(+), 43 deletions(-)
diff --git a/arch/arm/mach-omap2/clock2420_data.c
b/arch/arm/mach-omap2/clock2420_data.c
index 37d65d6..6378e6d 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -1765,29 +1765,33 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL, "virt_prcm_set",&virt_prcm_set, CK_242X),
/* general l4 interface ck, multi-parent functional clk */
CLK(NULL, "gpt1_ick", &gpt1_ick, CK_242X),
+ /*
+* gpt1 will be modified in subsequent patch when dmtimers
+* will be fully converted to platform device
+*/
CLK(NULL, "gpt1_fck", &gpt1_fck, CK_242X),
CLK(NULL, "gpt2_ick", &gpt2_ick, CK_242X),
- CLK(NULL, "gpt2_fck", &gpt2_fck, CK_242X),
+ CLK("dmtimer.1", "fck",&gpt2_fck, CK_242X),
That comment is not necessarily only for you, but do we have to start
device id at 0?
I think it is really confusing to name the famous gptimer1 device with
"dmtimer.0".
From that list it looks like this is not even consistent across IPs.
McBSP start at 1 for example.
Since we are in the name discussion, I'd like as well to potentially
stop using the dmtimer / gptimer confusing naming convention, and
replace that with a simple name "timer". Or potentially "omap_timer".
Dual Mode timer does not mean at lot and General Purpose timer is not
that better.
We already started that discussion with Kevin some time ago but didn't
really conclude.
Tony, Paul and Kevin,
Do you have any opinion on that subject?
Regards,
Benoit
CLK(NULL, "gpt3_ick", &gpt3_ick, CK_242X),
- CLK(NULL, "gpt3_fck", &gpt3_fck, CK_242X),
+ CLK("dmtimer.2", "fck",&gpt3_fck, CK_242X),
CLK(NULL, "gpt4_ick", &gpt4_ick, CK_242X),
- CLK(NULL, "gpt4_fck", &gpt4_fck, CK_242X),
+ CLK("dmtimer.3", "fck",&gpt4_fck, CK_242X),
CLK(NULL, "gpt5_ick", &gpt5_ick, CK_242X),
- CLK(NULL, "gpt5_fck", &gpt5_fck, CK_242X),
+ CLK("dmtimer.4", "fck",&gpt5_fck, CK_242X),
CLK(NULL, "gpt6_ick", &gpt6_ick, CK_242X),
- CLK(NULL, "gpt6_fck", &gpt6_fck, CK_242X),
+ CLK("dmtimer.5", "fck",&gpt6_fck, CK_242X),
CLK(NULL, "gpt7_ick", &gpt7_ick, CK_242X),
- CLK(NULL, "gpt7_fck", &gpt7_fck, CK_242X),
+ CLK("dmtimer.6", "fck",&gpt7_fck, CK_242X),
CLK(NULL, "gpt8_ick", &gpt8_ick, CK_242X),
- CLK(NULL, "gpt8_fck", &gpt8_fck, CK_242X),
+ CLK("dmtimer.7", "fck",&gpt8_fck, CK_242X),
CLK(NULL, "gpt9_ick", &gpt9_ick, CK_242X),
- CLK(NULL, "gpt9_fck", &gpt9_fck, CK_242X),
+ CLK("dmtimer.8", "fck",&gpt9_fck, CK_242X),
CLK(NULL, "gpt10_ick", &gpt10_ick, CK_242X),
- CLK(NULL, "gpt10_fck", &gpt10_fck, CK_242X),
+ CLK("dmtimer.9", "fck",&gpt10_fck, CK_242X),
CLK(NULL, "gpt11_ick", &gpt11_ick, CK_242X),
- CLK(NULL, "gpt11_fck", &gpt11_fck, CK_242X),
+ CLK("dmtimer.10", "fck",&gpt11_fck, CK_242X),
CLK(NULL, "gpt12_ick", &gpt12_ick, CK_242X),
- CLK(NULL, "gpt12_fck", &gpt12_fck, CK_242X),
+ CLK("dmtimer.11", "fck",&gpt12_fck, CK_242X),
CLK("omap-mcbsp.1", "ick", &mcbsp1_ick,CK_242X),
CLK("omap-mcbsp.1", "fck", &mcbsp1_fck,CK_242X),
CLK("omap-mcbsp.2", "ick", &mcbsp2_ick,CK_242X),
diff --git a/arch/arm/mach-omap2/clock2430_data.c
b/arch/arm/mach-omap2/clock2430_data.c
index b33118f..ae9b44e 100644
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -1851,29 +1851,33 @@ static struct omap_clk omap2430_clks[] = {
CLK(NULL, "virt_prcm_set",&virt_prcm_set, CK_243X),
/* general l4
Re: [PATCH] PM: add synchronous runtime interface for interrupt handlers
Hi,
On Thursday, September 30, 2010, Alan Stern wrote:
> This patch (as1431) adds a synchronous runtime-PM interface suitable
> for use in interrupt handlers. Four new helper functions are defined:
>
> pm_runtime_suspend_irq(), pm_runtime_resume_irq(),
> pm_runtime_get_sync_irq(), pm_runtime_put_sync_irq(),
>
> together with pm_runtime_callbacks_in_irq(), which subsystems use to
> tell the PM core that the runtime callbacks should be invoked with
> interrupts disabled.
>
> Signed-off-by: Alan Stern
>
> ---
>
> In the end it turned out that a new RPM_IRQ call flag was needed along
> with the callbacks_in_irq flag in dev_pm_info. The latter is required
> for the reasons I explained before, and RPM_IRQ tells the core whether
> or not it must leave interrupts disabled while waiting for a concurrent
> state change.
>
> Kevin, this should be good enough to satisfy all your needs. How does
> it look?
>
> Alan Stern
>
>
> Index: usb-2.6/include/linux/pm.h
> ===
> --- usb-2.6.orig/include/linux/pm.h
> +++ usb-2.6/include/linux/pm.h
> @@ -485,6 +485,7 @@ struct dev_pm_info {
> unsigned intrun_wake:1;
> unsigned intruntime_auto:1;
> unsigned intno_callbacks:1;
> + unsigned intcallbacks_in_irq:1;
I kind of don't like this name. What about irq_safe ?
> unsigned intuse_autosuspend:1;
> unsigned inttimer_autosuspends:1;
> enum rpm_requestrequest;
> Index: usb-2.6/include/linux/pm_runtime.h
> ===
> --- usb-2.6.orig/include/linux/pm_runtime.h
> +++ usb-2.6/include/linux/pm_runtime.h
> @@ -21,6 +21,7 @@
> #define RPM_GET_PUT 0x04/* Increment/decrement the
> usage_count */
> #define RPM_AUTO 0x08/* Use autosuspend_delay */
> +#define RPM_IRQ 0x10/* Don't enable interrupts */
>
> #ifdef CONFIG_PM_RUNTIME
>
> @@ -40,6 +41,7 @@ extern int pm_generic_runtime_idle(struc
> extern int pm_generic_runtime_suspend(struct device *dev);
> extern int pm_generic_runtime_resume(struct device *dev);
> extern void pm_runtime_no_callbacks(struct device *dev);
> +extern void pm_runtime_callbacks_in_irq(struct device *dev);
Perhaps this one can be called pm_runtime_irq_safe() in analogy to the struct
member?
> extern void __pm_runtime_use_autosuspend(struct device *dev, bool use);
> extern void pm_runtime_set_autosuspend_delay(struct device *dev, int delay);
> extern unsigned long pm_runtime_autosuspend_expiration(struct device *dev);
> @@ -123,6 +125,7 @@ static inline int pm_generic_runtime_idl
> static inline int pm_generic_runtime_suspend(struct device *dev) { return 0;
> }
> static inline int pm_generic_runtime_resume(struct device *dev) { return 0; }
> static inline void pm_runtime_no_callbacks(struct device *dev) {}
> +static inline void pm_runtime_callbacks_in_irq(struct device *dev) {}
>
> static inline void pm_runtime_mark_last_busy(struct device *dev) {}
> static inline void __pm_runtime_use_autosuspend(struct device *dev,
> @@ -144,6 +147,11 @@ static inline int pm_runtime_suspend(str
> return __pm_runtime_suspend(dev, 0);
> }
>
> +static inline int pm_runtime_suspend_irq(struct device *dev)
> +{
> + return __pm_runtime_suspend(dev, RPM_IRQ);
> +}
> +
> static inline int pm_runtime_autosuspend(struct device *dev)
> {
> return __pm_runtime_suspend(dev, RPM_AUTO);
> @@ -154,6 +162,11 @@ static inline int pm_runtime_resume(stru
> return __pm_runtime_resume(dev, 0);
> }
>
> +static inline int pm_runtime_resume_irq(struct device *dev)
> +{
> + return __pm_runtime_resume(dev, RPM_IRQ);
> +}
> +
> static inline int pm_request_idle(struct device *dev)
> {
> return __pm_runtime_idle(dev, RPM_ASYNC);
> @@ -179,6 +192,11 @@ static inline int pm_runtime_get_sync(st
> return __pm_runtime_resume(dev, RPM_GET_PUT);
> }
>
> +static inline int pm_runtime_get_sync_irq(struct device *dev)
> +{
> + return __pm_runtime_resume(dev, RPM_GET_PUT | RPM_IRQ);
> +}
> +
> static inline int pm_runtime_put(struct device *dev)
> {
> return __pm_runtime_idle(dev, RPM_GET_PUT | RPM_ASYNC);
> @@ -195,6 +213,11 @@ static inline int pm_runtime_put_sync(st
> return __pm_runtime_idle(dev, RPM_GET_PUT);
> }
>
> +static inline int pm_runtime_put_sync_irq(struct device *dev)
> +{
> + return __pm_runtime_idle(dev, RPM_GET_PUT | RPM_IRQ);
> +}
> +
> static inline int pm_runtime_put_sync_autosuspend(struct device *dev)
> {
> return __pm_runtime_suspend(dev, RPM_GET_PUT | RPM_AUTO);
> Index: usb-2.6/drivers/base/power/runtime.c
> ===
> --- usb-2.6.orig/drivers/base/power/runtime.c
> +++ usb-2.6/drivers/base/power/runtime.c
> @@ -170,10 +170,1
Re: [PATCHv3 0/17] OMAP dmtimer hwmod
Hi Tarun,
On 9/21/2010 10:50 AM, Tarun Kanti DebBarma wrote:
This patch series implements dmtimer hwmod.
Maybe the description should be a little bit more detailed:
Something like "Adapt dmtimer code to platform_driver using omap_device
/ omap_hwmod abstraction"
Benoit
Version 3
*
(1) multi-line comment error correction
(2) provision to allow any of the available dmtimers as early timers
instead of restricting them to millisecond timers only.
(3) in 'struct omap_dmtimer{}' is_initialized flag is redundant and
so must be removed. if the element is found in the list it is already
initialized.
(4) remove 'found' flag in omap_dm_timer_request() and
omap_dm_timer_request_specific() functions.
this is not needed with alternate implementation.
(5) use .init_name to initialize device names so that it can be identified
during early boot as well. This is to avoid duplicate functions for clock
manipulations during early boot and later.
(6) remove redundant functions from mach-omap2 which are created just to
call pm functions like: pm_runtime_get_sync(),pm_runtime_put_sync(),..
and instead call them directly from plat-omap function api's.
(7) timer clock source names made part of hwmod database. source_clock[]
of type 'struct clk' is made part of platform data.
(8) clockactivity field initialized in hwmod database to preserve fclk
during idle. code which manipulate OCP config removed since they are
already taken care by hwmod framework.
(9) omap2_dm_timer_set_src() is optimized. Clock enable/disbale routines
moved to plat-omap layer and simplfied to the level so as not to sacrifice
intended functionality.
NOTE: During early boot clock management was requested to be placed upon
client drivers responsibility. this has not been done keeping in mind
that it would entail (i) multiple modifications of client drivers (ii) it
would violate the purpose of having a framework (open to debate).
(10) dmtimer register maps moved to hwmod database
Baseline
origin/pm-core
Test info
*
OMAP4430SDP
OMAP3630SDP
OMAP3430SDP
OMAP2430SDP
OMAP1710SDP(Bootup)
Tarun Kanti DebBarma (17):
OMAP2/3/4:dmtimer:add device names to flck nodes
dmtimer: infrastructure to support hwmod
dmtimer: add omap2420 hwmod database
dmtimer: add omap2430 hwmod database
dmtimer: add omap3xxx hwmod database
dmtimer: add omap44xx hwmod database
dmtimer: use list instead of static array
dmtimer: register mappings moved to hwmod database
OMAP: dmtimer platform driver
OMAP1: dmtimer conversion to platform devices
dmtimer: early boot infrastructure
OMAP2/3/4: dmtimers: convert to platform devices
dmtimer: switch-over to platform device driver with hwmod
dmtimer pm_runtime support
dmtimer: OMAP4 specific change in plat-omap
dmtimer: clean redundant code
dmtimer: remove OCP config code from plat-omap
arch/arm/mach-omap1/Makefile |2 +-
arch/arm/mach-omap1/dmtimer.c | 174 ++
arch/arm/mach-omap2/Makefile |2 +-
arch/arm/mach-omap2/clock2420_data.c | 24 +-
arch/arm/mach-omap2/clock2430_data.c | 24 +-
arch/arm/mach-omap2/clock3xxx_data.c | 24 +-
arch/arm/mach-omap2/clock44xx_data.c | 22 +-
arch/arm/mach-omap2/dmtimer.c | 288 ++
arch/arm/mach-omap2/dmtimer.h | 25 +
arch/arm/mach-omap2/io.c |2 +
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 739 +
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 737 +
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 815
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 796 +++
arch/arm/mach-omap2/timer-gp.c |1 -
arch/arm/plat-omap/dmtimer.c | 679 +++
arch/arm/plat-omap/include/plat/dmtimer.h | 80 +++
17 files changed, 4030 insertions(+), 404 deletions(-)
create mode 100644 arch/arm/mach-omap1/dmtimer.c
create mode 100644 arch/arm/mach-omap2/dmtimer.c
create mode 100644 arch/arm/mach-omap2/dmtimer.h
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [OMAP] HTCHERALD: MMC, I2C, HTCPLD, SPI, TSC2046
* Michał Mirosław [100930 11:57]:
> 2010/9/30 Tony Lindgren :
> > * Cory Maccarrone [100930 11:34]:
> >> > Looks like also board-sx1-mmc.c and board-h[23]-mmc.c have the
> >> > same spotty voltage range.
> >> > Cory, care to do a patch that fixes it for all of them?
> >> Yeah, I can do that. I'll resubmit this patch too with the fixed up
> >> ranges.
> > Turns out I already did it :) Care to test/ack this one?
>
> [...]
> > diff --git a/arch/arm/mach-omap1/board-sx1-mmc.c
> > b/arch/arm/mach-omap1/board-sx1-mmc.c
> > index 5b33ae8..be5a365 100644
> > --- a/arch/arm/mach-omap1/board-sx1-mmc.c
> > +++ b/arch/arm/mach-omap1/board-sx1-mmc.c
> > @@ -44,7 +44,8 @@ static struct omap_mmc_platform_data mmc1_data = {
> > .nr_slots = 1,
> > .slots[0] = {
> > .set_power = mmc_set_power,
> > - .ocr_mask = MMC_VDD_28_29 | MMC_VDD_30_31 |
> > + .ocr_mask = MMC_VDD_28_29 | MMC_VDD_29_30 |
> > + MMC_VDD_30_31 | MMC_VDD_31_32 |
> > MMC_VDD_32_33 | MMC_VDD_33_34,
> > .name = "mmcblk",
> > },
> [...]
>
> Al least this one seems wrong (haven't checked others) as the
> mmc_set_power() ignores vdd parameter. This suggests that the board
> supports only one particular voltage, not the whole range.
Hmm yeah good catch. With the external power it's board specific.
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [OMAP] HTCHERALD: MMC, I2C, HTCPLD, SPI, TSC2046
2010/9/30 Tony Lindgren :
> * Cory Maccarrone [100930 11:34]:
>> > Looks like also board-sx1-mmc.c and board-h[23]-mmc.c have the
>> > same spotty voltage range.
>> > Cory, care to do a patch that fixes it for all of them?
>> Yeah, I can do that. I'll resubmit this patch too with the fixed up ranges.
> Turns out I already did it :) Care to test/ack this one?
[...]
> diff --git a/arch/arm/mach-omap1/board-sx1-mmc.c
> b/arch/arm/mach-omap1/board-sx1-mmc.c
> index 5b33ae8..be5a365 100644
> --- a/arch/arm/mach-omap1/board-sx1-mmc.c
> +++ b/arch/arm/mach-omap1/board-sx1-mmc.c
> @@ -44,7 +44,8 @@ static struct omap_mmc_platform_data mmc1_data = {
> .nr_slots = 1,
> .slots[0] = {
> .set_power = mmc_set_power,
> - .ocr_mask = MMC_VDD_28_29 | MMC_VDD_30_31 |
> + .ocr_mask = MMC_VDD_28_29 | MMC_VDD_29_30 |
> + MMC_VDD_30_31 | MMC_VDD_31_32 |
> MMC_VDD_32_33 | MMC_VDD_33_34,
> .name = "mmcblk",
> },
[...]
Al least this one seems wrong (haven't checked others) as the
mmc_set_power() ignores vdd parameter. This suggests that the board
supports only one particular voltage, not the whole range.
Best Regards,
Michał Mirosław
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [OMAP] HTCHERALD: MMC, I2C, HTCPLD, SPI, TSC2046
On Thu, Sep 30, 2010 at 11:48 AM, Tony Lindgren wrote:
> * Cory Maccarrone [100930 11:34]:
>> >
>> > Looks like also board-sx1-mmc.c and board-h[23]-mmc.c have the
>> > same spotty voltage range.
>> >
>> > Cory, care to do a patch that fixes it for all of them?
>> >
>>
>> Yeah, I can do that. I'll resubmit this patch too with the fixed up ranges.
>
> Turns out I already did it :) Care to test/ack this one?
>
> Tony
>
> From: Tony Lindgren
> Date: Thu, 30 Sep 2010 11:40:56 -0700
> Subject: [PATCH] omap: Fix spotty MMC voltages
>
> As noted by Michał Mirosław , the voltages should
> cover the supported voltage range instead of missing some values
> within the range.
>
> Reported-by: Michał Mirosław
> Signed-off-by: Tony Lindgren
>
> diff --git a/arch/arm/mach-omap1/board-h2-mmc.c
> b/arch/arm/mach-omap1/board-h2-mmc.c
> index b30c499..50d9032 100644
> --- a/arch/arm/mach-omap1/board-h2-mmc.c
> +++ b/arch/arm/mach-omap1/board-h2-mmc.c
> @@ -58,7 +58,8 @@ static struct omap_mmc_platform_data mmc1_data = {
> .dma_mask = 0x,
> .slots[0] = {
> .set_power = mmc_set_power,
> - .ocr_mask = MMC_VDD_28_29 | MMC_VDD_30_31 |
> + .ocr_mask = MMC_VDD_28_29 | MMC_VDD_29_30 |
> + MMC_VDD_30_31 | MMC_VDD_31_32 |
> MMC_VDD_32_33 | MMC_VDD_33_34,
> .name = "mmcblk",
> },
> diff --git a/arch/arm/mach-omap1/board-h3-mmc.c
> b/arch/arm/mach-omap1/board-h3-mmc.c
> index 54b0f06..9f073bf 100644
> --- a/arch/arm/mach-omap1/board-h3-mmc.c
> +++ b/arch/arm/mach-omap1/board-h3-mmc.c
> @@ -40,7 +40,8 @@ static struct omap_mmc_platform_data mmc1_data = {
> .dma_mask = 0x,
> .slots[0] = {
> .set_power = mmc_set_power,
> - .ocr_mask = MMC_VDD_28_29 | MMC_VDD_30_31 |
> + .ocr_mask = MMC_VDD_28_29 | MMC_VDD_29_30 |
> + MMC_VDD_30_31 | MMC_VDD_31_32 |
> MMC_VDD_32_33 | MMC_VDD_33_34,
> .name = "mmcblk",
> },
> diff --git a/arch/arm/mach-omap1/board-htcherald.c
> b/arch/arm/mach-omap1/board-htcherald.c
> index 7ea75c1..909fdeb 100644
> --- a/arch/arm/mach-omap1/board-htcherald.c
> +++ b/arch/arm/mach-omap1/board-htcherald.c
> @@ -410,7 +410,8 @@ static struct omap_mmc_platform_data htc_mmc1_data = {
> .nr_slots = 1,
> .switch_slot = NULL,
> .slots[0] = {
> - .ocr_mask = MMC_VDD_28_29 | MMC_VDD_30_31 |
> + .ocr_mask = MMC_VDD_28_29 | MMC_VDD_29_30 |
> + MMC_VDD_30_31 | MMC_VDD_31_32 |
> MMC_VDD_32_33 | MMC_VDD_33_34,
> .name = "mmcblk",
> .nomux = 1,
> diff --git a/arch/arm/mach-omap1/board-sx1-mmc.c
> b/arch/arm/mach-omap1/board-sx1-mmc.c
> index 5b33ae8..be5a365 100644
> --- a/arch/arm/mach-omap1/board-sx1-mmc.c
> +++ b/arch/arm/mach-omap1/board-sx1-mmc.c
> @@ -44,7 +44,8 @@ static struct omap_mmc_platform_data mmc1_data = {
> .nr_slots = 1,
> .slots[0] = {
> .set_power = mmc_set_power,
> - .ocr_mask = MMC_VDD_28_29 | MMC_VDD_30_31 |
> + .ocr_mask = MMC_VDD_28_29 | MMC_VDD_29_30 |
> + MMC_VDD_30_31 | MMC_VDD_31_32 |
> MMC_VDD_32_33 | MMC_VDD_33_34,
> .name = "mmcblk",
> },
> diff --git a/arch/arm/mach-omap2/board-n8x0.c
> b/arch/arm/mach-omap2/board-n8x0.c
> index 7a93bd5..abd7e77 100644
> --- a/arch/arm/mach-omap2/board-n8x0.c
> +++ b/arch/arm/mach-omap2/board-n8x0.c
> @@ -493,7 +493,8 @@ static struct omap_mmc_platform_data mmc1_data = {
> .set_bus_mode = n8x0_mmc_set_bus_mode,
> .get_cover_state = n8x0_mmc_get_cover_state,
> .ocr_mask = MMC_VDD_165_195 | MMC_VDD_30_31 |
> - MMC_VDD_32_33 |
> MMC_VDD_33_34,
> + MMC_VDD_31_32 | MMC_VDD_32_33
> |
> + MMC_VDD_33_34,
> .name = "internal",
> },
> .slots[1] = {
>
Sure thing, hopefully in the next day or two. :)
- Cory
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj"��!�i
Re: [PATCH] [OMAP] HTCHERALD: MMC, I2C, HTCPLD, SPI, TSC2046
* Cory Maccarrone [100930 11:34]:
> >
> > Looks like also board-sx1-mmc.c and board-h[23]-mmc.c have the
> > same spotty voltage range.
> >
> > Cory, care to do a patch that fixes it for all of them?
> >
>
> Yeah, I can do that. I'll resubmit this patch too with the fixed up ranges.
Turns out I already did it :) Care to test/ack this one?
Tony
From: Tony Lindgren
Date: Thu, 30 Sep 2010 11:40:56 -0700
Subject: [PATCH] omap: Fix spotty MMC voltages
As noted by Michał Mirosław , the voltages should
cover the supported voltage range instead of missing some values
within the range.
Reported-by: Michał Mirosław
Signed-off-by: Tony Lindgren
diff --git a/arch/arm/mach-omap1/board-h2-mmc.c
b/arch/arm/mach-omap1/board-h2-mmc.c
index b30c499..50d9032 100644
--- a/arch/arm/mach-omap1/board-h2-mmc.c
+++ b/arch/arm/mach-omap1/board-h2-mmc.c
@@ -58,7 +58,8 @@ static struct omap_mmc_platform_data mmc1_data = {
.dma_mask = 0x,
.slots[0] = {
.set_power = mmc_set_power,
- .ocr_mask = MMC_VDD_28_29 | MMC_VDD_30_31 |
+ .ocr_mask = MMC_VDD_28_29 | MMC_VDD_29_30 |
+ MMC_VDD_30_31 | MMC_VDD_31_32 |
MMC_VDD_32_33 | MMC_VDD_33_34,
.name = "mmcblk",
},
diff --git a/arch/arm/mach-omap1/board-h3-mmc.c
b/arch/arm/mach-omap1/board-h3-mmc.c
index 54b0f06..9f073bf 100644
--- a/arch/arm/mach-omap1/board-h3-mmc.c
+++ b/arch/arm/mach-omap1/board-h3-mmc.c
@@ -40,7 +40,8 @@ static struct omap_mmc_platform_data mmc1_data = {
.dma_mask = 0x,
.slots[0] = {
.set_power = mmc_set_power,
- .ocr_mask = MMC_VDD_28_29 | MMC_VDD_30_31 |
+ .ocr_mask = MMC_VDD_28_29 | MMC_VDD_29_30 |
+ MMC_VDD_30_31 | MMC_VDD_31_32 |
MMC_VDD_32_33 | MMC_VDD_33_34,
.name = "mmcblk",
},
diff --git a/arch/arm/mach-omap1/board-htcherald.c
b/arch/arm/mach-omap1/board-htcherald.c
index 7ea75c1..909fdeb 100644
--- a/arch/arm/mach-omap1/board-htcherald.c
+++ b/arch/arm/mach-omap1/board-htcherald.c
@@ -410,7 +410,8 @@ static struct omap_mmc_platform_data htc_mmc1_data = {
.nr_slots = 1,
.switch_slot= NULL,
.slots[0] = {
- .ocr_mask = MMC_VDD_28_29 | MMC_VDD_30_31 |
+ .ocr_mask = MMC_VDD_28_29 | MMC_VDD_29_30 |
+ MMC_VDD_30_31 | MMC_VDD_31_32 |
MMC_VDD_32_33 | MMC_VDD_33_34,
.name = "mmcblk",
.nomux = 1,
diff --git a/arch/arm/mach-omap1/board-sx1-mmc.c
b/arch/arm/mach-omap1/board-sx1-mmc.c
index 5b33ae8..be5a365 100644
--- a/arch/arm/mach-omap1/board-sx1-mmc.c
+++ b/arch/arm/mach-omap1/board-sx1-mmc.c
@@ -44,7 +44,8 @@ static struct omap_mmc_platform_data mmc1_data = {
.nr_slots = 1,
.slots[0] = {
.set_power = mmc_set_power,
- .ocr_mask = MMC_VDD_28_29 | MMC_VDD_30_31 |
+ .ocr_mask = MMC_VDD_28_29 | MMC_VDD_29_30 |
+ MMC_VDD_30_31 | MMC_VDD_31_32 |
MMC_VDD_32_33 | MMC_VDD_33_34,
.name = "mmcblk",
},
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index 7a93bd5..abd7e77 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -493,7 +493,8 @@ static struct omap_mmc_platform_data mmc1_data = {
.set_bus_mode = n8x0_mmc_set_bus_mode,
.get_cover_state= n8x0_mmc_get_cover_state,
.ocr_mask = MMC_VDD_165_195 | MMC_VDD_30_31 |
- MMC_VDD_32_33 | MMC_VDD_33_34,
+ MMC_VDD_31_32 | MMC_VDD_32_33 |
+ MMC_VDD_33_34,
.name = "internal",
},
.slots[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
[PATCH 1/3] OMAP1: Add support for SoC camera interface
From: Janusz Krzysztofik
This patch adds a definition of the OMAP1 camera interface platform device,
and a function that allows for providing a board specific platform data.
The device will be used with the upcoming OMAP1 SoC camera interface driver.
Signed-off-by: Janusz Krzysztofik
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap1/devices.c | 43 +
arch/arm/mach-omap1/include/mach/camera.h | 11 +++
2 files changed, 54 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap1/include/mach/camera.h
diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
index aa07256..2c9a030 100644
--- a/arch/arm/mach-omap1/devices.c
+++ b/arch/arm/mach-omap1/devices.c
@@ -9,6 +9,7 @@
* (at your option) any later version.
*/
+#include
#include
#include
#include
@@ -191,6 +192,48 @@ static inline void omap_init_spi100k(void)
}
#endif
+
+#define OMAP1_CAMERA_BASE 0xfffb6800
+#define OMAP1_CAMERA_IOSIZE0x1c
+
+static struct resource omap1_camera_resources[] = {
+ [0] = {
+ .start = OMAP1_CAMERA_BASE,
+ .end= OMAP1_CAMERA_BASE + OMAP1_CAMERA_IOSIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = INT_CAMERA,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static u64 omap1_camera_dma_mask = DMA_BIT_MASK(32);
+
+static struct platform_device omap1_camera_device = {
+ .name = "omap1-camera",
+ .id = 0, /* This is used to put cameras on this interface */
+ .dev= {
+ .dma_mask = &omap1_camera_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+ .num_resources = ARRAY_SIZE(omap1_camera_resources),
+ .resource = omap1_camera_resources,
+};
+
+void __init omap1_camera_init(void *info)
+{
+ struct platform_device *dev = &omap1_camera_device;
+ int ret;
+
+ dev->dev.platform_data = info;
+
+ ret = platform_device_register(dev);
+ if (ret)
+ dev_err(&dev->dev, "unable to register device: %d\n", ret);
+}
+
+
/*-*/
static inline void omap_init_sti(void) {}
diff --git a/arch/arm/mach-omap1/include/mach/camera.h
b/arch/arm/mach-omap1/include/mach/camera.h
new file mode 100644
index 000..fd54b45
--- /dev/null
+++ b/arch/arm/mach-omap1/include/mach/camera.h
@@ -0,0 +1,11 @@
+#ifndef __ASM_ARCH_CAMERA_H_
+#define __ASM_ARCH_CAMERA_H_
+
+void omap1_camera_init(void *);
+
+static inline void omap1_set_camera_info(struct omap1_cam_platform_data *info)
+{
+ omap1_camera_init(info);
+}
+
+#endif /* __ASM_ARCH_CAMERA_H_ */
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] OMAP1: Amstrad Delta: add support for camera
From: Janusz Krzysztofik
This patch adds configuration data and initialization code required for camera
support to the Amstrad Delta board.
Three devices are declared: SoC camera, OMAP1 camera interface and OV6650
sensor.
Default 12MHz clock has been selected for driving the sensor. Pixel clock has
been limited to get reasonable frame rates, not exceeding the board
capabilities. Since both devices (interface and sensor) support both pixel
clock polarities, decision on polarity selection has been left to drivers.
Interface GPIO line has been found not functional, thus not configured.
Signed-off-by: Janusz Krzysztofik
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap1/board-ams-delta.c | 45 +
1 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index 41992ab..12f7f60 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -19,6 +19,8 @@
#include
#include
+#include
+
#include
#include
#include
@@ -32,6 +34,7 @@
#include
#include
#include
+#include
#include
@@ -213,10 +216,37 @@ static struct platform_device ams_delta_led_device = {
.id = -1
};
+static struct i2c_board_info ams_delta_camera_board_info[] = {
+ {
+ I2C_BOARD_INFO("ov6650", 0x60),
+ },
+};
+
+static struct soc_camera_link __initdata ams_delta_iclink = {
+ .bus_id = 0,/* OMAP1 SoC camera bus */
+ .i2c_adapter_id = 1,
+ .board_info = &ams_delta_camera_board_info[0],
+ .module_name= "ov6650",
+};
+
+static struct platform_device ams_delta_camera_device = {
+ .name = "soc-camera-pdrv",
+ .id = 0,
+ .dev= {
+ .platform_data = &ams_delta_iclink,
+ },
+};
+
+static struct omap1_cam_platform_data ams_delta_camera_platform_data = {
+ .camexclk_khz = 12000,/* default 12MHz clock, no extra DPLL */
+ .lclk_khz_max = 1334, /* results in 5fps CIF, 10fps QCIF */
+};
+
static struct platform_device *ams_delta_devices[] __initdata = {
&ams_delta_kp_device,
&ams_delta_lcd_device,
&ams_delta_led_device,
+ &ams_delta_camera_device,
};
static void __init ams_delta_init(void)
@@ -225,6 +255,20 @@ static void __init ams_delta_init(void)
omap_cfg_reg(UART1_TX);
omap_cfg_reg(UART1_RTS);
+ /* parallel camera interface */
+ omap_cfg_reg(H19_1610_CAM_EXCLK);
+ omap_cfg_reg(J15_1610_CAM_LCLK);
+ omap_cfg_reg(L18_1610_CAM_VS);
+ omap_cfg_reg(L15_1610_CAM_HS);
+ omap_cfg_reg(L19_1610_CAM_D0);
+ omap_cfg_reg(K14_1610_CAM_D1);
+ omap_cfg_reg(K15_1610_CAM_D2);
+ omap_cfg_reg(K19_1610_CAM_D3);
+ omap_cfg_reg(K18_1610_CAM_D4);
+ omap_cfg_reg(J14_1610_CAM_D5);
+ omap_cfg_reg(J19_1610_CAM_D6);
+ omap_cfg_reg(J18_1610_CAM_D7);
+
iotable_init(ams_delta_io_desc, ARRAY_SIZE(ams_delta_io_desc));
omap_board_config = ams_delta_config;
@@ -236,6 +280,7 @@ static void __init ams_delta_init(void)
ams_delta_latch2_write(~0, 0);
omap1_usb_init(&ams_delta_usb_config);
+ omap1_set_camera_info(&ams_delta_camera_platform_data);
platform_add_devices(ams_delta_devices, ARRAY_SIZE(ams_delta_devices));
#ifdef CONFIG_AMS_DELTA_FIQ
--
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/3] OMAP1: Amstrad Delta: add camera controlled LEDS trigger
From: Janusz Krzysztofik
This patch extends the Amstrad Delta camera support with LEDS trigger that can
be used for automatic control of the on-board camera LED. The led turns on
automatically on camera device open and turns off on camera device close.
Signed-off-by: Janusz Krzysztofik
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap1/board-ams-delta.c | 24
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index 12f7f60..248e8bb 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
@@ -222,11 +223,30 @@ static struct i2c_board_info
ams_delta_camera_board_info[] = {
},
};
+#ifdef CONFIG_LEDS_TRIGGERS
+DEFINE_LED_TRIGGER(ams_delta_camera_led_trigger);
+
+static int ams_delta_camera_power(struct device *dev, int power)
+{
+ /*
+* turn on camera LED
+*/
+ if (power)
+ led_trigger_event(ams_delta_camera_led_trigger, LED_FULL);
+ else
+ led_trigger_event(ams_delta_camera_led_trigger, LED_OFF);
+ return 0;
+}
+#else
+#define ams_delta_camera_power NULL
+#endif
+
static struct soc_camera_link __initdata ams_delta_iclink = {
.bus_id = 0,/* OMAP1 SoC camera bus */
.i2c_adapter_id = 1,
.board_info = &ams_delta_camera_board_info[0],
.module_name= "ov6650",
+ .power = ams_delta_camera_power,
};
static struct platform_device ams_delta_camera_device = {
@@ -281,6 +301,10 @@ static void __init ams_delta_init(void)
omap1_usb_init(&ams_delta_usb_config);
omap1_set_camera_info(&ams_delta_camera_platform_data);
+#ifdef CONFIG_LEDS_TRIGGERS
+ led_trigger_register_simple("ams_delta_camera",
+ &ams_delta_camera_led_trigger);
+#endif
platform_add_devices(ams_delta_devices, ARRAY_SIZE(ams_delta_devices));
#ifdef CONFIG_AMS_DELTA_FIQ
--
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/3] Few omap1 patches for v2.6.37 merge window
Hi all, Here are some omap1 related patches I've picked up for the upcoming merge window. Regards, Tony --- Janusz Krzysztofik (3): OMAP1: Add support for SoC camera interface OMAP1: Amstrad Delta: add support for camera OMAP1: Amstrad Delta: add camera controlled LEDS trigger arch/arm/mach-omap1/board-ams-delta.c | 69 + arch/arm/mach-omap1/devices.c | 43 ++ arch/arm/mach-omap1/include/mach/camera.h | 11 + 3 files changed, 123 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap1/include/mach/camera.h -- Signature -- 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] staging: tidspbridge: disable all peripherals at bridge_brd_stop
DSP Bridge needs to disable the peripheral clocks when switches to BRD_STOPPED since that would prevent the domain to enter in OFF state. Signed-off-by: Ernesto Ramos Signed-off-by: Omar Ramirez Luna --- drivers/staging/tidspbridge/core/tiomap3430.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c b/drivers/staging/tidspbridge/core/tiomap3430.c index f1e59e8..e32e98a 100644 --- a/drivers/staging/tidspbridge/core/tiomap3430.c +++ b/drivers/staging/tidspbridge/core/tiomap3430.c @@ -625,7 +625,6 @@ static int bridge_brd_stop(struct bridge_dev_context *dev_ctxt) struct bridge_dev_context *dev_context = dev_ctxt; struct pg_table_attrs *pt_attrs; u32 dsp_pwr_state; - int clk_status; struct dspbridge_platform_data *pdata = omap_dspbridge_dev->dev.platform_data; @@ -679,7 +678,8 @@ static int bridge_brd_stop(struct bridge_dev_context *dev_ctxt) (*pdata->dsp_prm_write)(OMAP3430_RST1_IVA2_MASK | OMAP3430_RST2_IVA2_MASK | OMAP3430_RST3_IVA2_MASK, OMAP3430_IVA2_MOD, OMAP2_RM_RSTCTRL); - clk_status = dsp_clk_disable(DSP_CLK_IVA2); + dsp_clock_disable_all(dev_context->dsp_per_clks); + dsp_clk_disable(DSP_CLK_IVA2); return status; } -- 1.5.4.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] [OMAP] HTCHERALD: MMC, I2C, HTCPLD, SPI, TSC2046
2010/9/24 Tony Lindgren :
> * Michał Mirosław [100924 09:03]:
>> W dniu 24 września 2010 17:38 użytkownik Cory Maccarrone
>> napisał:
>> > 2010/9/24 Michał Mirosław :
>> >> 2010/8/18 Cory Maccarrone :
>> >>> This change adds in MMC and I2C support to the HTC Herald board, as well
>> >>> as adding the HTCPLD driver for the PLD used on this phone. It also
>> >>> adds in the gpio-keys entries for the front directional keys and
>> >>> selector and the cursor keys on the slide-out keyboard, and gpio-leds
>> >>> support for the LEDs attached to the htcpld.
>> >>>
>> >>> Additionally, SPI bus support (using the spi100k driver) and
>> >>> touchscreen support (using the ads7846 driver) were added.
>> >>>
>> >>> Signed-off-by: Cory Maccarrone
>> >>> ---
>> >> [...]
>> >>> +/* MMC Card */
>> >>> +#if defined(CONFIG_MMC_OMAP) || defined(CONFIG_MMC_OMAP_MODULE)
>> >>> +static struct omap_mmc_platform_data htc_mmc1_data = {
>> >>> + .nr_slots = 1,
>> >>> + .switch_slot = NULL,
>> >>> + .slots[0] = {
>> >>> + .ocr_mask = MMC_VDD_28_29 | MMC_VDD_30_31 |
>> >>> + MMC_VDD_32_33 | MMC_VDD_33_34,
>> >>> + .name = "mmcblk",
>> >>> + .nomux = 1,
>> >>> + .wires = 4,
>> >>> + .switch_pin = -1,
>> >>> + },
>> >>> +};
>> >> [...]
>> >> What voltages can this MMC controller provide? That's a rather unusual
>> >> OCR mask.
>> > Not really sure, I wasn't the one who first came up with that mask.
>> > All I know is that it seems to work, and not just for my device, but
>> > lots of other HTC OMAP850 devices we've tried it on too.
>> >
>> > I'm interested though, what in particular makes it unusual?
>>
>> It specifies, that device supports voltage ranges:
>> 2.8V - 2.9V, 3.0V - 3.1V, 3.2V - 3.4V
>> (so: 2.9V - 3.0V and 3.1V - 3.2V are not available).
>> Are there really 2.8V, 3.0V, 3.3V VDDs settable?
>>
>> If the host supports only VDD = 3.3V for example, then correct OCR
>> mask would be: MMC_VDD_32_33 | MMC_VDD_33_34 (or just one flag).
>
> Looks like also board-sx1-mmc.c and board-h[23]-mmc.c have the
> same spotty voltage range.
>
> Cory, care to do a patch that fixes it for all of them?
>
Yeah, I can do that. I'll resubmit this patch too with the fixed up ranges.
- Cory
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap: Keep nwires for omap1 and 2420 MMC controller (Re: [PATCH] omap mmc: extended to pass host capabilities from board file)
* Tony Lindgren [100923 16:00]:
> * Sukumar Ghorai [100915 07:41]:
> > wires variable is renamed, extended and this single variable to be used to
> > pass the platform capabilities, e.g DDR mode. Also removed the hardcoded
> > value was using as bus-width.
>
> This looks like a nice clean-up, I'll queue this via the omap
> patches.
And of course this patch breaks all of mach-omap1 and omap2420.
Sukumar, your patch modified also drivers/mmc/host/omap.c and board-n8x0.c
to use caps instead of nwires. When you do things like that you absolutely
_must_test_your_changes_ before sending out any patches.
Planning on merging the following fix.
Tony
From: Tony Lindgren
Date: Thu, 30 Sep 2010 10:25:46 -0700
Subject: [PATCH] Subject: [PATCH] omap: Keep nwires for omap1 and 2420 MMC
controller
A patch from Sukumar Ghorai changed the
nwires to use caps instead. However, nwires is still
needed for the earlier controller.
Signed-off-by: Tony Lindgren
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index abd7e77..6bd9d9a 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -488,7 +488,7 @@ static struct omap_mmc_platform_data mmc1_data = {
.max_freq = 2400,
.dma_mask = 0x,
.slots[0] = {
- .caps = MMC_CAP_4_BIT_DATA,
+ .wires = 4,
.set_power = n8x0_mmc_set_power,
.set_bus_mode = n8x0_mmc_set_bus_mode,
.get_cover_state= n8x0_mmc_get_cover_state,
diff --git a/arch/arm/plat-omap/include/plat/mmc.h
b/arch/arm/plat-omap/include/plat/mmc.h
index 4f819fc..bc85010 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -73,9 +73,16 @@ struct omap_mmc_platform_data {
struct omap_mmc_slot_data {
- /* 4/8 wires and any additional host capabilities
-* need to OR'd all capabilities (ref. linux/mmc/host.h) */
- u32 caps;
+ /*
+* 4/8 wires and any additional host capabilities
+* need to OR'd all capabilities (ref. linux/mmc/host.h)
+*/
+#if defined(CONFIG_ARCH_OMAP1) || defined(CONFIG_ARCH_OMAP2420)
+ u8 wires; /* Used for the MMC driver on omap1 and 2420 */
+#endif
+#ifdef CONFIG_ARCH_OMAP2PLUS
+ u32 caps; /* Used for the MMC driver on 2430 and later */
+#endif
/*
* nomux means "standard" muxing is wrong on this board, and
diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index a9d62cf..d98ddcf 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -1317,7 +1317,7 @@ static int __init mmc_omap_new_slot(struct mmc_omap_host
*host, int id)
host->slots[id] = slot;
mmc->caps = 0;
- if (host->pdata->slots[id].caps & MMC_CAP_8_BIT_DATA)
+ if (host->pdata->slots[id].wires >= 4)
mmc->caps |= MMC_CAP_4_BIT_DATA;
mmc->ops = &mmc_omap_ops;
--
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] staging:ti dspbridge: Replace find_lcm with lcm kernel func
Resendig this patch since it was missed in the last merge...
Remove find_lcm within nldr.c and use standard
kernel function lcm().
Signed-off-by: Ernesto Ramos
Signed-off-by: Omar Ramirez Luna
---
drivers/staging/tidspbridge/rmgr/nldr.c | 17 ++---
1 files changed, 2 insertions(+), 15 deletions(-)
diff --git a/drivers/staging/tidspbridge/rmgr/nldr.c
b/drivers/staging/tidspbridge/rmgr/nldr.c
index d8f4eeb..a6ae007 100644
--- a/drivers/staging/tidspbridge/rmgr/nldr.c
+++ b/drivers/staging/tidspbridge/rmgr/nldr.c
@@ -35,7 +35,7 @@
#include
#include
-#include
+#include
/* Name of section containing dynamic load mem */
#define DYNMEMSECT ".dspbridge_mem"
@@ -304,7 +304,6 @@ static void unload_ovly(struct nldr_nodeobject
*nldr_node_obj,
enum nldr_phase phase);
static bool find_in_persistent_lib_array(struct nldr_nodeobject *nldr_node_obj,
struct dbll_library_obj *lib);
-static u32 find_lcm(u32 a, u32 b);
/*
* nldr_allocate
@@ -1637,7 +1636,7 @@ static int remote_alloc(void **ref, u16 mem_sect, u32
size,
(size + nldr_obj->us_dsp_word_size -
1) / nldr_obj->us_dsp_word_size;
/* Modify memory 'align' to account for DSP cache line size */
- align = find_lcm(GEM_CACHE_LINE_SIZE, align);
+ align = lcm(GEM_CACHE_LINE_SIZE, align);
dev_dbg(bridge, "%s: memory align to 0x%x\n", __func__, align);
if (segmnt_id != -1) {
rmm_addr_obj->segid = segmnt_id;
@@ -1880,18 +1879,6 @@ static bool find_in_persistent_lib_array(struct
nldr_nodeobject *nldr_node_obj,
return false;
}
-/*
- * Find LCM (Least Common Multiplier ===
- */
-static u32 find_lcm(u32 a, u32 b)
-{
- u32 ret;
-
- ret = a * b / gcd(a, b);
-
- return ret;
-}
-
#ifdef CONFIG_TIDSPBRIDGE_BACKTRACE
/**
* nldr_find_addr() - Find the closest symbol to the given address based on
--
1.5.4.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] staging:ti dspbridge: remove cmm_xlator_delete wrapper
Resending this patch since it was missed in the last merge...
Remove unnecessary cmm_xlator_delete function and use
kfree() kernel function directly.
Signed-off-by: Ernesto Ramos
Signed-off-by: Omar Ramirez Luna
---
.../staging/tidspbridge/include/dspbridge/cmm.h| 19 ---
drivers/staging/tidspbridge/pmgr/cmm.c | 17 -
drivers/staging/tidspbridge/rmgr/node.c|9 ++---
drivers/staging/tidspbridge/rmgr/strm.c| 11 ++-
4 files changed, 4 insertions(+), 52 deletions(-)
diff --git a/drivers/staging/tidspbridge/include/dspbridge/cmm.h
b/drivers/staging/tidspbridge/include/dspbridge/cmm.h
index a921f1b..6ad313f 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/cmm.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/cmm.h
@@ -300,25 +300,6 @@ extern int cmm_xlator_create(struct cmm_xlatorobject
**xlator,
struct cmm_xlatorattrs *xlator_attrs);
/*
- * cmm_xlator_delete
- * Purpose:
- * Delete translator resources
- * Parameters:
- * xlator:handle to translator.
- * force: force = TRUE will free XLators SM buffers/dscriptrs.
- * Returns:
- * 0:Success.
- * -EFAULT:Bad translator handle.
- * -EPERM: Unable to free translator resources.
- * Requires:
- * refs > 0
- * Ensures:
- *
- */
-extern int cmm_xlator_delete(struct cmm_xlatorobject *xlator,
- bool force);
-
-/*
* cmm_xlator_free_buf
* Purpose:
* Free SM buffer and descriptor.
diff --git a/drivers/staging/tidspbridge/pmgr/cmm.c
b/drivers/staging/tidspbridge/pmgr/cmm.c
index e3f77bd..93a7c4f 100644
--- a/drivers/staging/tidspbridge/pmgr/cmm.c
+++ b/drivers/staging/tidspbridge/pmgr/cmm.c
@@ -968,23 +968,6 @@ int cmm_xlator_create(struct cmm_xlatorobject **xlator,
}
/*
- * cmm_xlator_delete
- * Purpose:
- * Free the Xlator resources.
- * VM gets freed later.
- */
-int cmm_xlator_delete(struct cmm_xlatorobject *xlator, bool force)
-{
- struct cmm_xlator *xlator_obj = (struct cmm_xlator *)xlator;
-
- DBC_REQUIRE(refs > 0);
-
- kfree(xlator_obj);
-
- return 0;
-}
-
-/*
* cmm_xlator_alloc_buf
*/
void *cmm_xlator_alloc_buf(struct cmm_xlatorobject *xlator, void *va_buf,
diff --git a/drivers/staging/tidspbridge/rmgr/node.c
b/drivers/staging/tidspbridge/rmgr/node.c
index 84882dc..1562f3c 100644
--- a/drivers/staging/tidspbridge/rmgr/node.c
+++ b/drivers/staging/tidspbridge/rmgr/node.c
@@ -2505,7 +2505,6 @@ static void delete_node(struct node_object *hnode,
struct process_context *pr_ctxt)
{
struct node_mgr *hnode_mgr;
- struct cmm_xlatorobject *xlator;
struct bridge_drv_interface *intf_fxns;
u32 i;
enum node_type node_type;
@@ -2523,7 +2522,7 @@ static void delete_node(struct node_object *hnode,
hnode_mgr = hnode->hnode_mgr;
if (!hnode_mgr)
goto func_end;
- xlator = hnode->xlator;
+
node_type = node_get_type(hnode);
if (node_type != NODE_DEVICE) {
node_msg_args = hnode->create_args.asa.node_msg_args;
@@ -2619,11 +2618,7 @@ static void delete_node(struct node_object *hnode,
hnode->dcd_props.obj_data.node_obj.pstr_i_alg_name = NULL;
/* Free all SM address translator resources */
- if (xlator) {
- (void)cmm_xlator_delete(xlator, true); /* force free */
- xlator = NULL;
- }
-
+ kfree(hnode->xlator);
kfree(hnode->nldr_node_obj);
hnode->nldr_node_obj = NULL;
hnode->hnode_mgr = NULL;
diff --git a/drivers/staging/tidspbridge/rmgr/strm.c
b/drivers/staging/tidspbridge/rmgr/strm.c
index f4986b7..2e42714 100644
--- a/drivers/staging/tidspbridge/rmgr/strm.c
+++ b/drivers/staging/tidspbridge/rmgr/strm.c
@@ -834,16 +834,9 @@ static int delete_strm(struct strm_object *stream_obj)
* is invalid. */
status = (*intf_fxns->pfn_chnl_close)
(stream_obj->chnl_obj);
- /* Free all SM address translator resources */
- if (!status) {
- if (stream_obj->xlator) {
- /* force free */
- (void)cmm_xlator_delete(stream_obj->
- xlator,
- true);
- }
- }
}
+ /* Free all SM address translator resources */
+ kfree(stream_obj->xlator);
kfree(stream_obj);
} else {
status = -EFAULT;
--
1.5.4.5
--
To unsubscribe from this list: send
[PATCH] PM: add synchronous runtime interface for interrupt handlers
This patch (as1431) adds a synchronous runtime-PM interface suitable
for use in interrupt handlers. Four new helper functions are defined:
pm_runtime_suspend_irq(), pm_runtime_resume_irq(),
pm_runtime_get_sync_irq(), pm_runtime_put_sync_irq(),
together with pm_runtime_callbacks_in_irq(), which subsystems use to
tell the PM core that the runtime callbacks should be invoked with
interrupts disabled.
Signed-off-by: Alan Stern
---
In the end it turned out that a new RPM_IRQ call flag was needed along
with the callbacks_in_irq flag in dev_pm_info. The latter is required
for the reasons I explained before, and RPM_IRQ tells the core whether
or not it must leave interrupts disabled while waiting for a concurrent
state change.
Kevin, this should be good enough to satisfy all your needs. How does
it look?
Alan Stern
Index: usb-2.6/include/linux/pm.h
===
--- usb-2.6.orig/include/linux/pm.h
+++ usb-2.6/include/linux/pm.h
@@ -485,6 +485,7 @@ struct dev_pm_info {
unsigned intrun_wake:1;
unsigned intruntime_auto:1;
unsigned intno_callbacks:1;
+ unsigned intcallbacks_in_irq:1;
unsigned intuse_autosuspend:1;
unsigned inttimer_autosuspends:1;
enum rpm_requestrequest;
Index: usb-2.6/include/linux/pm_runtime.h
===
--- usb-2.6.orig/include/linux/pm_runtime.h
+++ usb-2.6/include/linux/pm_runtime.h
@@ -21,6 +21,7 @@
#define RPM_GET_PUT0x04/* Increment/decrement the
usage_count */
#define RPM_AUTO 0x08/* Use autosuspend_delay */
+#define RPM_IRQ0x10/* Don't enable interrupts */
#ifdef CONFIG_PM_RUNTIME
@@ -40,6 +41,7 @@ extern int pm_generic_runtime_idle(struc
extern int pm_generic_runtime_suspend(struct device *dev);
extern int pm_generic_runtime_resume(struct device *dev);
extern void pm_runtime_no_callbacks(struct device *dev);
+extern void pm_runtime_callbacks_in_irq(struct device *dev);
extern void __pm_runtime_use_autosuspend(struct device *dev, bool use);
extern void pm_runtime_set_autosuspend_delay(struct device *dev, int delay);
extern unsigned long pm_runtime_autosuspend_expiration(struct device *dev);
@@ -123,6 +125,7 @@ static inline int pm_generic_runtime_idl
static inline int pm_generic_runtime_suspend(struct device *dev) { return 0; }
static inline int pm_generic_runtime_resume(struct device *dev) { return 0; }
static inline void pm_runtime_no_callbacks(struct device *dev) {}
+static inline void pm_runtime_callbacks_in_irq(struct device *dev) {}
static inline void pm_runtime_mark_last_busy(struct device *dev) {}
static inline void __pm_runtime_use_autosuspend(struct device *dev,
@@ -144,6 +147,11 @@ static inline int pm_runtime_suspend(str
return __pm_runtime_suspend(dev, 0);
}
+static inline int pm_runtime_suspend_irq(struct device *dev)
+{
+ return __pm_runtime_suspend(dev, RPM_IRQ);
+}
+
static inline int pm_runtime_autosuspend(struct device *dev)
{
return __pm_runtime_suspend(dev, RPM_AUTO);
@@ -154,6 +162,11 @@ static inline int pm_runtime_resume(stru
return __pm_runtime_resume(dev, 0);
}
+static inline int pm_runtime_resume_irq(struct device *dev)
+{
+ return __pm_runtime_resume(dev, RPM_IRQ);
+}
+
static inline int pm_request_idle(struct device *dev)
{
return __pm_runtime_idle(dev, RPM_ASYNC);
@@ -179,6 +192,11 @@ static inline int pm_runtime_get_sync(st
return __pm_runtime_resume(dev, RPM_GET_PUT);
}
+static inline int pm_runtime_get_sync_irq(struct device *dev)
+{
+ return __pm_runtime_resume(dev, RPM_GET_PUT | RPM_IRQ);
+}
+
static inline int pm_runtime_put(struct device *dev)
{
return __pm_runtime_idle(dev, RPM_GET_PUT | RPM_ASYNC);
@@ -195,6 +213,11 @@ static inline int pm_runtime_put_sync(st
return __pm_runtime_idle(dev, RPM_GET_PUT);
}
+static inline int pm_runtime_put_sync_irq(struct device *dev)
+{
+ return __pm_runtime_idle(dev, RPM_GET_PUT | RPM_IRQ);
+}
+
static inline int pm_runtime_put_sync_autosuspend(struct device *dev)
{
return __pm_runtime_suspend(dev, RPM_GET_PUT | RPM_AUTO);
Index: usb-2.6/drivers/base/power/runtime.c
===
--- usb-2.6.orig/drivers/base/power/runtime.c
+++ usb-2.6/drivers/base/power/runtime.c
@@ -170,10 +170,13 @@ static int rpm_idle(struct device *dev,
__releases(&dev->power.lock) __acquires(&dev->power.lock)
{
int retval;
+ int (*func)(struct device *dev);
retval = rpm_check_suspend_allowed(dev);
if (retval < 0)
; /* Conditions are wrong. */
+ else if ((rpmflags & RPM_IRQ) && !dev->power.callbacks_in_irq)
+ re
Re: [PATCH] ARM: add cpu_idle_wait() to support CPUidle on SMP systems.
On Thu, Sep 30, 2010 at 10:07 AM, Kevin Hilman wrote: > Russell, > > Kevin Hilman writes: > >> In order for CPUidle to work on SMP systems, an implementation of >> cpu_idle_wait() is needed. >> >> This patch duplicates the x86 implementation of cpu_idle_wait() for >> ARM. >> >> Signed-off-by: Kevin Hilman > > Are you OK with this for the patch system for 2.6.37? Tested-by: Colin Cross CPUidle works on Tegra2 with this patch. -- 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 02/11] OMAP3: PM: Adding voltage driver support for OMAP3
Hi Benoît, Thara, On Wed, 29 Sep 2010, Kevin Hilman wrote: > Also, I'm still seeing this on boot: > > omap_hwmod: sr1_fck: missing clockdomain for sr1_fck. > omap_hwmod: sr2_fck: missing clockdomain for sr2_fck. > > We need a final solution for this problem as a prerequisite for this > series as well. I guess we need to figure out the appropriate clockdomains for sr1_fck and sr2_fck. Probably the strictly correct thing to do, vis-a-vis the hardware, is to place them into their own SmartReflex clockdomain/powerdomain. But the PRCM doesn't export separate control registers for those, and as I understand it, that clockdomain/powerdomain follows the CORE clockdomains/powerdomain. Another option would be to place them into the WKUP clockdomain. The source of these functional clocks in SR_ALWON_FCLK which in turn is generated by the PRM from SYS_CLK. But that won't increment the CORE clockdomains' use-counter when the SR functional clocks are running, which seems desirable if the SmartReflex clockdomain/powerdomain really does follow CORE. So it seems to me that the best thing to do might be to place these clocks into the CORE_L4 clockdomain. But perhaps you might have a different view? regards, - Paul
Re: [PATCH] staging: tidspbridge: disable all peripherals at bridge_brd_stop
On Fri, Sep 24, 2010 at 04:02:03PM -0500, Ernesto Ramos wrote: > DSP Bridge needs to disable the peripheral clocks when switches to > BRD_STOPPED since that would prevent the domain to enter in OFF state. > > Signed-off-by: Ernesto Ramos > Signed-off-by: Omar Ramirez Luna This patch doesn't apply to the latest linux-next tree, what did you make it against? Care to fix it up and resend it? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP2PLUS: WDT: Fix: Disable WDT after reset during init
"Shilimkar, Santosh" writes: >> -Original Message- >> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- >> ow...@vger.kernel.org] On Behalf Of Varadarajan, Charulatha >> Sent: Thursday, September 30, 2010 9:25 PM >> To: Tony Lindgren; Cousson, Benoit >> Cc: Kevin Hilman; Menon, Nishanth; w...@iguana.be; linux- >> o...@vger.kernel.org; linux-watch...@vger.kernel.org; linux-arm- >> ker...@lists.infradead.org; p...@pwsan.com; Nayak, Rajendra; Basak, Partha >> Subject: RE: [PATCH] OMAP2PLUS: WDT: Fix: Disable WDT after reset during >> init >> >> Tony/ Benoit, >> >> > > >> > > I think that disabling it should be done only if the CONFIG_OMAP_WDT >> > > is not set. >> > >> > How about disabling is done always unless CONFIG_WATCHDOG_NOWAYOUT >> > is set? >> >> As given in the patch description, this patch does a disable of watchdog >> timer, during init, to avoid the system rebooting that happens due to >> enabling of watchdog timer after a reset of the module (during hwmod init). >> >> According to the default WDT registers values, the system reboot would >> happen in ~10s if watchdog is enabled with default values. Hence, after >> a WDT module reset during init, the watchdog has to be disabled within 10s >> otherwise the system will keep rebooting. >> >> Hence irrespective of CONFIG_WATCHDOG_NOWAYOUT/ CONFIG_OMAP_WDT, >> the watchdog timer needs to be disabled after a WDT reset has happened. >> > One more option is to avoid the software reset using the CONFIG_OMAP_WDT > flag. Something like below. This was already proposed by Charu, and rejected. Doing this means we have a dependency on particular bootloader init, and we'd like to get rid of *all* assumptions about what the bootloader does (or does not do.) 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] OMAP2PLUS: WDT: Fix: Disable WDT after reset during init
>> Tony/ Benoit, >> I think that disabling it should be done only if the CONFIG_OMAP_WDT is not set. >>> >>> How about disabling is done always unless CONFIG_WATCHDOG_NOWAYOUT >>> is set? >> >> As given in the patch description, this patch does a disable of watchdog >> timer, during init, to avoid the system rebooting that happens due to >> enabling of watchdog timer after a reset of the module (during hwmod init). >> >> According to the default WDT registers values, the system reboot would >> happen in ~10s if watchdog is enabled with default values. Hence, after >> a WDT module reset during init, the watchdog has to be disabled within 10s >> otherwise the system will keep rebooting. >> >> Hence irrespective of CONFIG_WATCHDOG_NOWAYOUT/ CONFIG_OMAP_WDT, >> the watchdog timer needs to be disabled after a WDT reset has happened. > > No, not necessarily, this is the whole point about a watchdog, you need > just need to ping it to prove that the system is alive. > Agreed > In case you didn't notice, every watchdogs are started during a cold > reset since OMAP1610. Even Phoenix contains a watchdog that is started > by default. > This is by construction... and this is done like that for a good reason. Yes. > So stopping a watchdog just after the reset in a bootloader is not > necessarily the behavior that user of a watchdog are expecting, > otherwise it will not be started by default at boot time. But, how do we handle this? enable INIT_NO_RESET flag? > > In your description, it looks like this behavior is a HW bug that we > have to fix... Sorry if it sounded like that. > It is just the way it is supposed to work. Yes. That's correct 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: [PATCH] ARM: add cpu_idle_wait() to support CPUidle on SMP systems.
Russell,
Kevin Hilman writes:
> In order for CPUidle to work on SMP systems, an implementation of
> cpu_idle_wait() is needed.
>
> This patch duplicates the x86 implementation of cpu_idle_wait() for
> ARM.
>
> Signed-off-by: Kevin Hilman
Are you OK with this for the patch system for 2.6.37?
Kevin
> ---
> arch/arm/Kconfig |3 +++
> arch/arm/include/asm/system.h |2 ++
> arch/arm/kernel/process.c | 19 +++
> 3 files changed, 24 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 553b7cf..10ce6dc 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -145,6 +145,9 @@ config ARCH_HAS_CPUFREQ
> and that the relevant menu configurations are displayed for
> it.
>
> +config ARCH_HAS_CPU_IDLE_WAIT
> + def_bool y
> +
> config GENERIC_HWEIGHT
> bool
> default y
> diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
> index 8ba1ccf..48e360c 100644
> --- a/arch/arm/include/asm/system.h
> +++ b/arch/arm/include/asm/system.h
> @@ -325,6 +325,8 @@ static inline unsigned long __xchg(unsigned long x,
> volatile void *ptr, int size
> extern void disable_hlt(void);
> extern void enable_hlt(void);
>
> +void cpu_idle_wait(void);
> +
> #include
>
> #if __LINUX_ARM_ARCH__ < 6
> diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
> index 401e38b..23def52 100644
> --- a/arch/arm/kernel/process.c
> +++ b/arch/arm/kernel/process.c
> @@ -135,6 +135,25 @@ EXPORT_SYMBOL(pm_power_off);
> void (*arm_pm_restart)(char str, const char *cmd) = arm_machine_restart;
> EXPORT_SYMBOL_GPL(arm_pm_restart);
>
> +static void do_nothing(void *unused)
> +{
> +}
> +
> +/*
> + * cpu_idle_wait - Used to ensure that all the CPUs discard old value of
> + * pm_idle and update to new pm_idle value. Required while changing pm_idle
> + * handler on SMP systems.
> + *
> + * Caller must have changed pm_idle to the new value before the call. Old
> + * pm_idle value will not be used by any CPU after the return of this
> function.
> + */
> +void cpu_idle_wait(void)
> +{
> + smp_mb();
> + /* kick all the CPUs so that they exit out of pm_idle */
> + smp_call_function(do_nothing, NULL, 1);
> +}
> +EXPORT_SYMBOL_GPL(cpu_idle_wait);
>
> /*
> * This is our default idle handler. We need to disable
--
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] OMAP2PLUS: WDT: Fix: Disable WDT after reset during init
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Varadarajan, Charulatha
> Sent: Thursday, September 30, 2010 9:25 PM
> To: Tony Lindgren; Cousson, Benoit
> Cc: Kevin Hilman; Menon, Nishanth; w...@iguana.be; linux-
> o...@vger.kernel.org; linux-watch...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; p...@pwsan.com; Nayak, Rajendra; Basak, Partha
> Subject: RE: [PATCH] OMAP2PLUS: WDT: Fix: Disable WDT after reset during
> init
>
> Tony/ Benoit,
>
> > >
> > > I think that disabling it should be done only if the CONFIG_OMAP_WDT
> > > is not set.
> >
> > How about disabling is done always unless CONFIG_WATCHDOG_NOWAYOUT
> > is set?
>
> As given in the patch description, this patch does a disable of watchdog
> timer, during init, to avoid the system rebooting that happens due to
> enabling of watchdog timer after a reset of the module (during hwmod init).
>
> According to the default WDT registers values, the system reboot would
> happen in ~10s if watchdog is enabled with default values. Hence, after
> a WDT module reset during init, the watchdog has to be disabled within 10s
> otherwise the system will keep rebooting.
>
> Hence irrespective of CONFIG_WATCHDOG_NOWAYOUT/ CONFIG_OMAP_WDT,
> the watchdog timer needs to be disabled after a WDT reset has happened.
>
One more option is to avoid the software reset using the CONFIG_OMAP_WDT
flag. Something like below.
--
static struct omap_hwmod omap44xx_wd_timer2_hwmod = {
.name = "wd_timer2",
.class = &omap44xx_wd_timer_hwmod_class,
.mpu_irqs = omap44xx_wd_timer2_irqs,
+ #ifndef CONFIG_OMAP_WDT,
+ .flags= HWMOD_INIT_NO_RESET,
+ #endif
.mpu_irqs_cnt = ARRAY_SIZE(omap44xx_wd_timer2_irqs),
.main_clk = "wd_timer2_fck",
.prcm = {
.omap4 = {
.clkctrl_reg = OMAP4430_CM_WKUP_WDT2_CLKCTRL,
},
},
.slaves = omap44xx_wd_timer2_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_wd_timer2_slaves),
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
Regards,
Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP2PLUS: WDT: Fix: Disable WDT after reset during init
On 9/30/2010 5:55 PM, Varadarajan, Charulatha wrote: Tony/ Benoit, I think that disabling it should be done only if the CONFIG_OMAP_WDT is not set. How about disabling is done always unless CONFIG_WATCHDOG_NOWAYOUT is set? As given in the patch description, this patch does a disable of watchdog timer, during init, to avoid the system rebooting that happens due to enabling of watchdog timer after a reset of the module (during hwmod init). According to the default WDT registers values, the system reboot would happen in ~10s if watchdog is enabled with default values. Hence, after a WDT module reset during init, the watchdog has to be disabled within 10s otherwise the system will keep rebooting. Hence irrespective of CONFIG_WATCHDOG_NOWAYOUT/ CONFIG_OMAP_WDT, the watchdog timer needs to be disabled after a WDT reset has happened. No, not necessarily, this is the whole point about a watchdog, you need just need to ping it to prove that the system is alive. In case you didn't notice, every watchdogs are started during a cold reset since OMAP1610. Even Phoenix contains a watchdog that is started by default. This is by construction... and this is done like that for a good reason. So stopping a watchdog just after the reset in a bootloader is not necessarily the behavior that user of a watchdog are expecting, otherwise it will not be started by default at boot time. In your description, it looks like this behavior is a HW bug that we have to fix... It is just the way it is supposed to work. Regards, Benoit Later on, the watchdog timer probe would be called (if CONFIG_OMAP_WDT is defined) which takes care of doing the regular the watchdog timer settings. After this, normal operations like open, close, ioctl operations are supported (if CONFIG_OMAP_WDT is defined). Based on CONFIG_WATCHDOG_NOWAYOUT definition, disabling the watchdog may/may not be supported. Hence omap2_disable_wdt() introduced in this patch is not going to affect the watchdog operations in anyway execpt that it is fixing the reboot issue observed due to a watchdog timer reset. And this has to be done irrespective of any OMAP watchdog timer related flags. I guess, omap_wdt_disable() call during the WDT probe might be due to similar reasons. That way product kernels can set CONFIG_WATCHDOG_NOWAYOUT and for the rest of us we can let fsck run the standard Linux way. 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] OMAP2PLUS: WDT: Fix: Disable WDT after reset during init
* Paul Walmsley [100930 09:34]:
> Hello Charu,
>
> On Thu, 30 Sep 2010, Varadarajan, Charulatha wrote:
>
> > > > diff --git a/arch/arm/mach-omap2/devices.c
> > > > b/arch/arm/mach-omap2/devices.c
> > > > index 8e2f0aa..9f44fc6 100644
> > > > --- a/arch/arm/mach-omap2/devices.c
> > > > +++ b/arch/arm/mach-omap2/devices.c
> > > > +
> > > > +static void __init omap_disable_wdt(void)
> > > > +{
> > > > + if (cpu_class_is_omap2())
> > >
> > > This code is already in mach-omap2/devices.c, so that test should be
> > > useless.
> >
> > I do not see a cpu_class_is_omap2() check in omap2_init_devices(). Please
> > point out where this check is done while/before calling omap_disable_wdt()?
>
> It's implicit, due to the directory arch/arm/mach-omap2/ -- code in that
> directory is only built for OMAP2+ systems -- and right now there are no
> plans for OMAP1+ multi-arch booting. So it's safe to assume that any code
> in arch/arm/mach-omap2 will only run on OMAP2+ boards.
That might change pretty fast though. There are already experimental patches
to build in multiple ARM archs into a single kernel binary.
So we should already have these checks in place to avoid the initcalls running
on other ARM archs.
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] OMAP2PLUS: WDT: Fix: Disable WDT after reset during init
On 9/30/2010 6:32 PM, Varadarajan, Charulatha wrote:
Benoit,
<>
With OMAP2PLUS watchdog implemented in hwmod fw way, the
module is reset during init.
In that case hwmod fw just highlighted the real behavior that was hidden
so far by the X-loader.
Yes.
You should as well add a link to the email thread with Kevin that raised
the issue.
Okay.
<>
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 8e2f0aa..9f44fc6 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -916,11 +916,55 @@ static inline void omap_init_vout(void) {}
/*-*/
+/*
+ * WDT mdoule is reset during init which enables the watchdog.
typo: module
Okay will correct it.
The real explanation is that you should not assume anything from the
boot loader at that time, so always stop the wdt.
It is not an assumption from bootloader. After the WDT reset, the
WDT is enabled and the reset values of WDT registers makes the system to
reboot (in ~10s) as WDT is enabled.
The implicit assumption in the previous code is that the bootloader
already stopped it. That exactly for that reason that hwmod is reseting
every IPs, because we don't have a clue about what X-loader / u-boot can
do between a cold-reset and the kernel boot.
+ * Hence it is required to disable the watchdog after the WDT reset
+ * during init. Otherwise the system would reboot as per the default
+ * watchdog timer registers settings.
+ */
+#define OMAP_WDT_WPS (0x34)
+#define OMAP_WDT_SPR (0x48)
+
+static int omap2_disable_wdt(struct omap_hwmod *oh, void *user)
You should call it unused if the parameter is not used.
Okay.
+{
+ void __iomem *base;
+
+ if (!oh)
+ pr_err("Could not look up wdtimer_hwmod\n");
+
+ base = oh->_mpu_rt_va;
Paul added an hwmod API to get that va (something like *_get_mpu_rt_va).
Okay. Will use that.
+
+ /* Enable the clocks before accessing the WDT registers */
+ omap_hwmod_enable(oh);
The enable can fail, so you should check the return value.
Okay.
+
+ /* sequence required to disable watchdog */
+ __raw_writel(0x, base + OMAP_WDT_SPR); /* TIMER_MODE */
+ while (__raw_readl(base + OMAP_WDT_WPS)& 0x10)
+ cpu_relax();
+
+ __raw_writel(0x, base + OMAP_WDT_SPR); /* TIMER_MODE */
+ while (__raw_readl(base + OMAP_WDT_WPS)& 0x10)
+ cpu_relax();
+
+ omap_hwmod_idle(oh);
+
+ return 0;
+}
+
+static void __init omap_disable_wdt(void)
+{
+ if (cpu_class_is_omap2())
This code is already in mach-omap2/devices.c, so that test should be
useless.
I do not see a cpu_class_is_omap2() check in omap2_init_devices(). Please
point out where this check is done while/before calling omap_disable_wdt()?
And Paul has just answered that one...
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] OMAP2PLUS: WDT: Fix: Disable WDT after reset during init
Hello Charu,
On Thu, 30 Sep 2010, Varadarajan, Charulatha wrote:
> > > diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> > > index 8e2f0aa..9f44fc6 100644
> > > --- a/arch/arm/mach-omap2/devices.c
> > > +++ b/arch/arm/mach-omap2/devices.c
> > > +
> > > +static void __init omap_disable_wdt(void)
> > > +{
> > > + if (cpu_class_is_omap2())
> >
> > This code is already in mach-omap2/devices.c, so that test should be
> > useless.
>
> I do not see a cpu_class_is_omap2() check in omap2_init_devices(). Please
> point out where this check is done while/before calling omap_disable_wdt()?
It's implicit, due to the directory arch/arm/mach-omap2/ -- code in that
directory is only built for OMAP2+ systems -- and right now there are no
plans for OMAP1+ multi-arch booting. So it's safe to assume that any code
in arch/arm/mach-omap2 will only run on OMAP2+ boards.
- 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] OMAP2PLUS: WDT: Fix: Disable WDT after reset during init
Kevin, > "Varadarajan, Charulatha" writes: > <> > > With OMAP2PLUS watchdog implemented in hwmod fw way, the > > module is reset during init. > > Please drop this sentence, as it's not directly related to hwmod, but > related to hardware reset, and was previously masked by most bootloaders. > Okay, will modify accordingly. > > After a watchdog timer module reset, the WDTs are enabled. The > > default time for a system reset after a watchdog module reset > > is ~10s as per the default value of the WDT registers. Hence > > the system would be reset after 10s, if watchdog is not disabled > > within 10s. > > > > This patch fixes the above issue by disabling the watchdog timer > > after reset during initialization of devices. > > Should also describe what happends if/when the watchdog driver is > loaded. Okay. Will add it to the description. > > Kevin > > > Signed-off-by: Charulatha V > > Reported-by: Kevin Hilman <>-- 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] OMAP2PLUS: WDT: Fix: Disable WDT after reset during init
Benoit,
<>
> > With OMAP2PLUS watchdog implemented in hwmod fw way, the
> > module is reset during init.
>
> In that case hwmod fw just highlighted the real behavior that was hidden
> so far by the X-loader.
Yes.
>
> You should as well add a link to the email thread with Kevin that raised
> the issue.
Okay.
<>
> > diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> > index 8e2f0aa..9f44fc6 100644
> > --- a/arch/arm/mach-omap2/devices.c
> > +++ b/arch/arm/mach-omap2/devices.c
> > @@ -916,11 +916,55 @@ static inline void omap_init_vout(void) {}
> >
> >
> > /*-*/
> >
> > +/*
> > + * WDT mdoule is reset during init which enables the watchdog.
>
> typo: module
Okay will correct it.
>
> The real explanation is that you should not assume anything from the
> boot loader at that time, so always stop the wdt.
It is not an assumption from bootloader. After the WDT reset, the
WDT is enabled and the reset values of WDT registers makes the system to
reboot (in ~10s) as WDT is enabled.
>
> > + * Hence it is required to disable the watchdog after the WDT reset
> > + * during init. Otherwise the system would reboot as per the default
> > + * watchdog timer registers settings.
> > + */
> > +#define OMAP_WDT_WPS (0x34)
> > +#define OMAP_WDT_SPR (0x48)
> > +
> > +static int omap2_disable_wdt(struct omap_hwmod *oh, void *user)
>
> You should call it unused if the parameter is not used.
Okay.
>
> > +{
> > + void __iomem *base;
> > +
> > + if (!oh)
> > + pr_err("Could not look up wdtimer_hwmod\n");
> > +
> > + base = oh->_mpu_rt_va;
>
> Paul added an hwmod API to get that va (something like *_get_mpu_rt_va).
Okay. Will use that.
>
> > +
> > + /* Enable the clocks before accessing the WDT registers */
> > + omap_hwmod_enable(oh);
>
> The enable can fail, so you should check the return value.
Okay.
>
> > +
> > + /* sequence required to disable watchdog */
> > + __raw_writel(0x, base + OMAP_WDT_SPR); /* TIMER_MODE */
> > + while (__raw_readl(base + OMAP_WDT_WPS)& 0x10)
> > + cpu_relax();
> > +
> > + __raw_writel(0x, base + OMAP_WDT_SPR); /* TIMER_MODE */
> > + while (__raw_readl(base + OMAP_WDT_WPS)& 0x10)
> > + cpu_relax();
> > +
> > + omap_hwmod_idle(oh);
> > +
> > + return 0;
> > +}
> > +
> > +static void __init omap_disable_wdt(void)
> > +{
> > + if (cpu_class_is_omap2())
>
> This code is already in mach-omap2/devices.c, so that test should be
> useless.
I do not see a cpu_class_is_omap2() check in omap2_init_devices(). Please
point out where this check is done while/before calling omap_disable_wdt()?
>
>
<>
--
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] OMAP2PLUS: WDT: Fix: Disable WDT after reset during init
Tony/ Benoit, > > > > I think that disabling it should be done only if the CONFIG_OMAP_WDT > > is not set. > > How about disabling is done always unless CONFIG_WATCHDOG_NOWAYOUT > is set? As given in the patch description, this patch does a disable of watchdog timer, during init, to avoid the system rebooting that happens due to enabling of watchdog timer after a reset of the module (during hwmod init). According to the default WDT registers values, the system reboot would happen in ~10s if watchdog is enabled with default values. Hence, after a WDT module reset during init, the watchdog has to be disabled within 10s otherwise the system will keep rebooting. Hence irrespective of CONFIG_WATCHDOG_NOWAYOUT/ CONFIG_OMAP_WDT, the watchdog timer needs to be disabled after a WDT reset has happened. Later on, the watchdog timer probe would be called (if CONFIG_OMAP_WDT is defined) which takes care of doing the regular the watchdog timer settings. After this, normal operations like open, close, ioctl operations are supported (if CONFIG_OMAP_WDT is defined). Based on CONFIG_WATCHDOG_NOWAYOUT definition, disabling the watchdog may/may not be supported. Hence omap2_disable_wdt() introduced in this patch is not going to affect the watchdog operations in anyway execpt that it is fixing the reboot issue observed due to a watchdog timer reset. And this has to be done irrespective of any OMAP watchdog timer related flags. I guess, omap_wdt_disable() call during the WDT probe might be due to similar reasons. > That way product kernels can set CONFIG_WATCHDOG_NOWAYOUT > and for the rest of us we can let fsck run the standard Linux way. > > Tony-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
* Kevin Hilman [100930 07:31]: > > What config are you using to get a small enough kernel to boot on your > n810? nolo on my n810 only accepts a maximum size kernel of 2097152 > bytes. :( I guess the options there are to leave out tons of boards and some other omaps, or to use kexec to get around that limit. 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 v4] power_supply: Add driver for TWL4030/TPS65950 BCI charger
On Tue, Sep 28, 2010 at 04:33:45PM +0300, Felipe Balbi wrote: [...] > >>>Hm you are probably talking about TWL5031, which has redesigned > >>>charger block that is named BCC. TWL4030 charger is different, called > >>>BCI and requires software charger detection from what I see in it's > >>>TRM. > >> > >>ok, might be that I got confused. Then it's ok the way it is. So we need > >>other means to detect the charger :-p > > > >May we consider this as a minor issue that can be improved later? > > Sure, it's fine. > > >If so, I would like to apply it, but I'll wait a day or two for > >Reviewed-by or Acked-by tags to give the proper credits. > > Here you go. > > Acked-by: Felipe Balbi Applied, thanks everyone! -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
Kevin Hilman writes: > Tony Lindgren writes: > >> * Kevin Hilman [100929 15:15]: >>> Tony Lindgren writes: >>> >>> > * Kevin Hilman [100928 11:25]: >>> >> Tony, >>> >> >>> >> The following pull request will bring hwmod driver conversions for >>> >> watchdog, UART and i2c drivers. It is based on your omap-for-linus >>> >> branch. >>> >> >>> >> The i2c driver is waiting for final signoff/ack from the upstream >>> >> subsystem maintainers, but are otherwise ready to go for broader >>> >> testing. After I get the final ack, I will update the branch for a >>> >> final pull. >>> >> >>> >> In the meantime, I'd like to get them into l-o master (or omap-testing) >>> >> for broader testing. >>> > >>> > Tried pulling it but I'm getting tons of these errors on omap2: >>> >>> Tony, >>> >>> Can you pull the latest version of my pm-hwmods branch from: >>> ssh://master.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git >>> pm-hwmods >>> >>> This version has the updated patch from Rajendra for i2c as well as some >>> UART3 fixes for a problem he noticed on 2430 as well. >> >> Getting closer.. Now 2430sdp boots OK. But on N800 (2420) I get the following >> very early on: > >> ... >> [0.00] Calibrating delay loop... 318.27 BogoMIPS (lpj=1245184) >> [0.00] pid_max: default: 32768 minimum: 301 >> [0.00] Security Framework initialized >> [0.00] Mount-cache hash table entries: 512 >> [0.00] CPU: Testing write buffer coherency: ok >> [0.00] Unhandled fault: imprecise external abort (0xc06) at >> 0x >> [0.00] Internal error: : c06 [#1] SMP >> [0.00] last sysfs file: >> [0.00] Modules linked in: >> [0.00] CPU: 0Not tainted (2.6.36-rc6-08801-g332f930 #395) >> [0.00] PC is at kernel_thread_helper+0x0/0x14 >> [0.00] LR is at kernel_thread_helper+0x0/0x14 >> [0.00] pc : []lr : []psr: 0093 >> [0.00] sp : c7825ff8 ip : fp : >> [0.00] r10: r9 : r8 : >> [0.00] r7 : 0013 r6 : c004cca8 r5 : c00a4dc0 r4 : >> [0.00] r3 : r2 : r1 : r0 : >> [0.00] Flags: nzcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment >> kernel >> [0.00] Control: 00c5387f Table: 80004000 DAC: 0017 >> [0.00] Process swapper (pid: 2, stack limit = 0xc78242f8) >> [0.00] Stack: (0xc7825ff8 to 0xc7826000) >> [0.00] 5fe0: >> >> [0.00] [] (kernel_thread_helper+0x0/0x14) from >> [] (0x) >> [0.00] Code: c04d9ba8 c04de459 c05ca0a0 c04caf13 (eb01ac97) >> [0.00] ---[ end trace 1b75b31a2719ed1c ]--- >> > > Hmm, this fault is very early and long before any PM code has > initialzed. I suspect this happens with the master branch too ?? I've reproduced this now, and it doesn't happen on the master branch and only happens after merge pm-hwmods. Debugging 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] OMAP2PLUS: WDT: Fix: Disable WDT after reset during init
* Cousson, Benoit [100930 07:04]: > > I think that disabling it should be done only if the CONFIG_OMAP_WDT > is not set. How about disabling is done always unless CONFIG_WATCHDOG_NOWAYOUT is set? That way product kernels can set CONFIG_WATCHDOG_NOWAYOUT and for the rest of us we can let fsck run the standard Linux way. 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] OMAP2PLUS: WDT: Fix: Disable WDT after reset during init
"Cousson, Benoit" writes: > On 9/30/2010 3:55 PM, Kevin Hilman wrote: >> "Cousson, Benoit" writes: >> >>> Hi Charu, >>> >>> On 9/30/2010 10:11 AM, Varadarajan, Charulatha wrote: With OMAP2PLUS watchdog implemented in hwmod fw way, the module is reset during init. >>> >>> In that case hwmod fw just highlighted the real behavior that was >>> hidden so far by the X-loader. >>> >>> You should as well add a link to the email thread with Kevin that >>> raised the issue. >>> After a watchdog timer module reset, the WDTs are enabled. The default time for a system reset after a watchdog module reset is ~10s as per the default value of the WDT registers. Hence the system would be reset after 10s, if watchdog is not disabled within 10s. This patch fixes the above issue by disabling the watchdog timer after reset during initialization of devices. >>> >>> I'm still wondering as well what is the expected behavior of the >>> watchdog in a real product. If it is started by default at boot time, >>> this is probably for a good reason (or maybe not...). >>> >>> So, disabling it all the time is maybe not the best solution. >> >> I'm not sure what the other options are. If you don't have a watchdog >> driver, and the watchdog is armed, it will reboot the system. >> >> The approach in this patch is just to continue the behavior that all >> bootloaders currently do, but make it explicit in the kernel. > > Yes, because we are not a building a product, and for us watchdog is a > pain. But I'm not sure that a real product will disable that at all > during the boot process. Maybe not. But wouldn't a product just ensure the real watchdog driver is loaded? Or more likely, in addition to the hundreds of other out-of-tree patches, they would just remove $SUBJECT patch. ;) > I think that disabling it should be done only if the CONFIG_OMAP_WDT > is not set. That's not easy either, as the watchdog driver can be built as a module, and may (or may not) be loaded some unknown time from the kernel boot, resulting in a likely Kevin > But since I don't have a clue about a product can use that, it will be > good to have such inputs to understand the usecase. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
Tony Lindgren writes: > * Kevin Hilman [100929 15:15]: >> Tony Lindgren writes: >> >> > * Kevin Hilman [100928 11:25]: >> >> Tony, >> >> >> >> The following pull request will bring hwmod driver conversions for >> >> watchdog, UART and i2c drivers. It is based on your omap-for-linus >> >> branch. >> >> >> >> The i2c driver is waiting for final signoff/ack from the upstream >> >> subsystem maintainers, but are otherwise ready to go for broader >> >> testing. After I get the final ack, I will update the branch for a >> >> final pull. >> >> >> >> In the meantime, I'd like to get them into l-o master (or omap-testing) >> >> for broader testing. >> > >> > Tried pulling it but I'm getting tons of these errors on omap2: >> >> Tony, >> >> Can you pull the latest version of my pm-hwmods branch from: >> ssh://master.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git >> pm-hwmods >> >> This version has the updated patch from Rajendra for i2c as well as some >> UART3 fixes for a problem he noticed on 2430 as well. > > Getting closer.. Now 2430sdp boots OK. But on N800 (2420) I get the following > very early on: > ... > [0.00] Calibrating delay loop... 318.27 BogoMIPS (lpj=1245184) > [0.00] pid_max: default: 32768 minimum: 301 > [0.00] Security Framework initialized > [0.00] Mount-cache hash table entries: 512 > [0.00] CPU: Testing write buffer coherency: ok > [0.00] Unhandled fault: imprecise external abort (0xc06) at 0x > [0.00] Internal error: : c06 [#1] SMP > [0.00] last sysfs file: > [0.00] Modules linked in: > [0.00] CPU: 0Not tainted (2.6.36-rc6-08801-g332f930 #395) > [0.00] PC is at kernel_thread_helper+0x0/0x14 > [0.00] LR is at kernel_thread_helper+0x0/0x14 > [0.00] pc : []lr : []psr: 0093 > [0.00] sp : c7825ff8 ip : fp : > [0.00] r10: r9 : r8 : > [0.00] r7 : 0013 r6 : c004cca8 r5 : c00a4dc0 r4 : > [0.00] r3 : r2 : r1 : r0 : > [0.00] Flags: nzcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment > kernel > [0.00] Control: 00c5387f Table: 80004000 DAC: 0017 > [0.00] Process swapper (pid: 2, stack limit = 0xc78242f8) > [0.00] Stack: (0xc7825ff8 to 0xc7826000) > [0.00] 5fe0: > > [0.00] [] (kernel_thread_helper+0x0/0x14) from [] > (0x) > [0.00] Code: c04d9ba8 c04de459 c05ca0a0 c04caf13 (eb01ac97) > [0.00] ---[ end trace 1b75b31a2719ed1c ]--- > Hmm, this fault is very early and long before any PM code has initialzed. I suspect this happens with the master branch too ?? What config are you using to get a small enough kernel to boot on your n810? nolo on my n810 only accepts a maximum size kernel of 2097152 bytes. :( > Then trying to build for omap1 OSK fails with: phew, guess I'm off the hook on that one. 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: [Beagleboard] linux-omap-pm -- cpufreq query
Thanks Kevin. Just to confirm, is there any version/branch beyond pm-2.6.34 that has cpufreq functional for omap3? -hari On Thu, Sep 30, 2010 at 8:48 AM, Kevin Hilman wrote: > Haribabu Narayanan writes: > >> Till recently I was working with Angstrom environment for >> beagleboard (with a linux-omap-pm 2.6.29 kernel) and had to migrate >> to the latest kernel version possible that is supported by >> linux-omap-pm branch for non-omap related reasons. I am sticking to >> linux-omap-pm instead of linux-omap or linux mainlines chiefly because >> I need cpufreq related functionalities. >> >> I was happily using the latest head from linux-omap-pm when I >> realised that there are no frequency transitions that are occurring >> now when I initiate requests through sys-fs writes. I found out that >> OMAP_PM_SRF is no longer supported (which was being used earlier on >> for helping with cpufreq changes). >> >> Is it that one cannot do cpufreq related changes with the >> current(+/-) linux-omap-pm kernel? > > That is correct. > >> I checked linux-omap-pm's head/cpufreq branch for example and it >> contains only OMAP_PM_NONE and OMAP_PM_NOOP in plat-omap/Kconfig. Are >> there any changes I can make so that I can get back cpufreq >> functionality. > > The kernel parts that enable DVFS (including SmartReflex, voltage layer > etc.) are being rewritten and are under review and test currently. > The best way to help would be to contribute to that development and or > test these series from Thara. > >> If yes, is there an general idea as to when this will >> be available with linux-omap-pm head ? > > When it's ready. ;) > > This is not a commitment, but I suspect we will have this into mainline > during the 2.6.38 merge window. > > 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: Compilation: omap-for-linus omap2plus error
"Shilimkar, Santosh" writes: >> > Is there any patch missing in omap-for-linus branch? Short version: Yes, there are several and the dependencies are taken care of in the master branch. Long version: There are several changes that are going upstream for 2.6.37 that are going through other trees (driver core, runtime PM core, i2c core, etc.) In my tree, I keep these in my pm-backports branch, and for Tony's tree, he has cherry-picked them into the omap-testing branch so they are included in l-o master until the merge window opens. So, even if you cherry pick the one patch, you may not have compile time problems but you will have other runtime problems due to other dependencies. So I strongly recommend just using l-o master. 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] OMAP2PLUS: WDT: Fix: Disable WDT after reset during init
On 9/30/2010 3:55 PM, Kevin Hilman wrote:
"Cousson, Benoit" writes:
Hi Charu,
On 9/30/2010 10:11 AM, Varadarajan, Charulatha wrote:
With OMAP2PLUS watchdog implemented in hwmod fw way, the
module is reset during init.
In that case hwmod fw just highlighted the real behavior that was
hidden so far by the X-loader.
You should as well add a link to the email thread with Kevin that
raised the issue.
After a watchdog timer module reset, the WDTs are enabled. The
default time for a system reset after a watchdog module reset
is ~10s as per the default value of the WDT registers. Hence
the system would be reset after 10s, if watchdog is not disabled
within 10s.
This patch fixes the above issue by disabling the watchdog timer
after reset during initialization of devices.
I'm still wondering as well what is the expected behavior of the
watchdog in a real product. If it is started by default at boot time,
this is probably for a good reason (or maybe not...).
So, disabling it all the time is maybe not the best solution.
I'm not sure what the other options are. If you don't have a watchdog
driver, and the watchdog is armed, it will reboot the system.
The approach in this patch is just to continue the behavior that all
bootloaders currently do, but make it explicit in the kernel.
Yes, because we are not a building a product, and for us watchdog is a
pain. But I'm not sure that a real product will disable that at all
during the boot process.
I think that disabling it should be done only if the CONFIG_OMAP_WDT is
not set.
But since I don't have a clue about a product can use that, it will be
good to have such inputs to understand the usecase.
Benoit
Kevin
Nishanth (M),
Do you have an idea on that topic?
Signed-off-by: Charulatha V
Reported-by: Kevin Hilman
---
This patch is dependent on the below patch series (wdt hwmod) and
is created on top of pm-core branch.
http://www.spinics.net/lists/linux-omap/msg37043.html
arch/arm/mach-omap2/devices.c | 44
+
1 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 8e2f0aa..9f44fc6 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -916,11 +916,55 @@ static inline void omap_init_vout(void) {}
/*-*/
+/*
+ * WDT mdoule is reset during init which enables the watchdog.
typo: module
The real explanation is that you should not assume anything from the
boot loader at that time, so always stop the wdt.
+ * Hence it is required to disable the watchdog after the WDT reset
+ * during init. Otherwise the system would reboot as per the default
+ * watchdog timer registers settings.
+ */
+#define OMAP_WDT_WPS (0x34)
+#define OMAP_WDT_SPR (0x48)
+
+static int omap2_disable_wdt(struct omap_hwmod *oh, void *user)
You should call it unused if the parameter is not used.
+{
+ void __iomem *base;
+
+ if (!oh)
+ pr_err("Could not look up wdtimer_hwmod\n");
+
+ base = oh->_mpu_rt_va;
Paul added an hwmod API to get that va (something like *_get_mpu_rt_va).
+
+ /* Enable the clocks before accessing the WDT registers */
+ omap_hwmod_enable(oh);
The enable can fail, so you should check the return value.
+
+ /* sequence required to disable watchdog */
+ __raw_writel(0x, base + OMAP_WDT_SPR); /* TIMER_MODE */
+ while (__raw_readl(base + OMAP_WDT_WPS)& 0x10)
+ cpu_relax();
+
+ __raw_writel(0x, base + OMAP_WDT_SPR); /* TIMER_MODE */
+ while (__raw_readl(base + OMAP_WDT_WPS)& 0x10)
+ cpu_relax();
+
+ omap_hwmod_idle(oh);
+
+ return 0;
+}
+
+static void __init omap_disable_wdt(void)
+{
+ if (cpu_class_is_omap2())
This code is already in mach-omap2/devices.c, so that test should be
useless.
Regards,
Benoit
+ omap_hwmod_for_each_by_class("wd_timer",
+ omap2_disable_wdt, NULL);
+ return;
+}
+
static int __init omap2_init_devices(void)
{
/* please keep these calls, and their implementations above,
* in alphabetical order so they're easier to sort through.
*/
+ omap_disable_wdt();
omap_hsmmc_reset();
omap_init_camera();
omap_init_mbox();
--
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: Compilation: omap-for-linus omap2plus error
2010/9/30 Abraham Arce : > Hi, > > Is there any patch missing in omap-for-linus branch? > > CC arch/arm/mach-omap2/pm_bus.o > arch/arm/mach-omap2/pm_bus.c: In function 'omap_pm_runtime_init': > arch/arm/mach-omap2/pm_bus.c:64: error: implicit declaration of function > 'platform_bus_get_pm_ops' > arch/arm/mach-omap2/pm_bus.c:64: warning: assignment makes pointer from > integer without a cast > arch/arm/mach-omap2/pm_bus.c:81: error: implicit declaration of function > 'platform_bus_set_pm_ops' > make[1]: *** [arch/arm/mach-omap2/pm_bus.o] Error 1 > make: *** [arch/arm/mach-omap2] Error 2 This issue also exists in pm-hwmods branch. -- Lei Ming -- 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] OMAP2PLUS: WDT: Fix: Disable WDT after reset during init
"Varadarajan, Charulatha" writes:
> With OMAP2PLUS watchdog implemented in hwmod fw way, the
> module is reset during init.
Please drop this sentence, as it's not directly related to hwmod, but
related to hardware reset, and was previously masked by most bootloaders.
> After a watchdog timer module reset, the WDTs are enabled. The
> default time for a system reset after a watchdog module reset
> is ~10s as per the default value of the WDT registers. Hence
> the system would be reset after 10s, if watchdog is not disabled
> within 10s.
>
> This patch fixes the above issue by disabling the watchdog timer
> after reset during initialization of devices.
Should also describe what happends if/when the watchdog driver is
loaded.
Kevin
> Signed-off-by: Charulatha V
> Reported-by: Kevin Hilman
> ---
> This patch is dependent on the below patch series (wdt hwmod) and
> is created on top of pm-core branch.
> http://www.spinics.net/lists/linux-omap/msg37043.html
>
> arch/arm/mach-omap2/devices.c | 44
> +
> 1 files changed, 44 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> index 8e2f0aa..9f44fc6 100644
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@ -916,11 +916,55 @@ static inline void omap_init_vout(void) {}
>
> /*-*/
>
> +/*
> + * WDT mdoule is reset during init which enables the watchdog.
> + * Hence it is required to disable the watchdog after the WDT reset
> + * during init. Otherwise the system would reboot as per the default
> + * watchdog timer registers settings.
> + */
> +#define OMAP_WDT_WPS (0x34)
> +#define OMAP_WDT_SPR (0x48)
> +
> +static int omap2_disable_wdt(struct omap_hwmod *oh, void *user)
> +{
> + void __iomem *base;
> +
> + if (!oh)
> + pr_err("Could not look up wdtimer_hwmod\n");
> +
> + base = oh->_mpu_rt_va;
> +
> + /* Enable the clocks before accessing the WDT registers */
> + omap_hwmod_enable(oh);
> +
> + /* sequence required to disable watchdog */
> + __raw_writel(0x, base + OMAP_WDT_SPR); /* TIMER_MODE */
> + while (__raw_readl(base + OMAP_WDT_WPS) & 0x10)
> + cpu_relax();
> +
> + __raw_writel(0x, base + OMAP_WDT_SPR); /* TIMER_MODE */
> + while (__raw_readl(base + OMAP_WDT_WPS) & 0x10)
> + cpu_relax();
> +
> + omap_hwmod_idle(oh);
> +
> + return 0;
> +}
> +
> +static void __init omap_disable_wdt(void)
> +{
> + if (cpu_class_is_omap2())
> + omap_hwmod_for_each_by_class("wd_timer",
> + omap2_disable_wdt, NULL);
> + return;
> +}
> +
> static int __init omap2_init_devices(void)
> {
> /* please keep these calls, and their implementations above,
>* in alphabetical order so they're easier to sort through.
>*/
> + omap_disable_wdt();
> omap_hsmmc_reset();
> omap_init_camera();
> omap_init_mbox();
--
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] OMAP2PLUS: WDT: Fix: Disable WDT after reset during init
"Cousson, Benoit" writes:
> Hi Charu,
>
> On 9/30/2010 10:11 AM, Varadarajan, Charulatha wrote:
>> With OMAP2PLUS watchdog implemented in hwmod fw way, the
>> module is reset during init.
>
> In that case hwmod fw just highlighted the real behavior that was
> hidden so far by the X-loader.
>
> You should as well add a link to the email thread with Kevin that
> raised the issue.
>
>> After a watchdog timer module reset, the WDTs are enabled. The
>> default time for a system reset after a watchdog module reset
>> is ~10s as per the default value of the WDT registers. Hence
>> the system would be reset after 10s, if watchdog is not disabled
>> within 10s.
>>
>> This patch fixes the above issue by disabling the watchdog timer
>> after reset during initialization of devices.
>
> I'm still wondering as well what is the expected behavior of the
> watchdog in a real product. If it is started by default at boot time,
> this is probably for a good reason (or maybe not...).
>
> So, disabling it all the time is maybe not the best solution.
I'm not sure what the other options are. If you don't have a watchdog
driver, and the watchdog is armed, it will reboot the system.
The approach in this patch is just to continue the behavior that all
bootloaders currently do, but make it explicit in the kernel.
Kevin
> Nishanth (M),
> Do you have an idea on that topic?
>
>>
>> Signed-off-by: Charulatha V
>> Reported-by: Kevin Hilman
>> ---
>> This patch is dependent on the below patch series (wdt hwmod) and
>> is created on top of pm-core branch.
>> http://www.spinics.net/lists/linux-omap/msg37043.html
>>
>> arch/arm/mach-omap2/devices.c | 44
>> +
>> 1 files changed, 44 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
>> index 8e2f0aa..9f44fc6 100644
>> --- a/arch/arm/mach-omap2/devices.c
>> +++ b/arch/arm/mach-omap2/devices.c
>> @@ -916,11 +916,55 @@ static inline void omap_init_vout(void) {}
>>
>>
>> /*-*/
>>
>> +/*
>> + * WDT mdoule is reset during init which enables the watchdog.
>
> typo: module
>
> The real explanation is that you should not assume anything from the
> boot loader at that time, so always stop the wdt.
>
>> + * Hence it is required to disable the watchdog after the WDT reset
>> + * during init. Otherwise the system would reboot as per the default
>> + * watchdog timer registers settings.
>> + */
>> +#define OMAP_WDT_WPS(0x34)
>> +#define OMAP_WDT_SPR(0x48)
>> +
>> +static int omap2_disable_wdt(struct omap_hwmod *oh, void *user)
>
> You should call it unused if the parameter is not used.
>
>> +{
>> +void __iomem *base;
>> +
>> +if (!oh)
>> +pr_err("Could not look up wdtimer_hwmod\n");
>> +
>> +base = oh->_mpu_rt_va;
>
> Paul added an hwmod API to get that va (something like *_get_mpu_rt_va).
>
>> +
>> +/* Enable the clocks before accessing the WDT registers */
>> +omap_hwmod_enable(oh);
>
> The enable can fail, so you should check the return value.
>
>> +
>> +/* sequence required to disable watchdog */
>> +__raw_writel(0x, base + OMAP_WDT_SPR); /* TIMER_MODE */
>> +while (__raw_readl(base + OMAP_WDT_WPS)& 0x10)
>> +cpu_relax();
>> +
>> +__raw_writel(0x, base + OMAP_WDT_SPR); /* TIMER_MODE */
>> +while (__raw_readl(base + OMAP_WDT_WPS)& 0x10)
>> +cpu_relax();
>> +
>> +omap_hwmod_idle(oh);
>> +
>> +return 0;
>> +}
>> +
>> +static void __init omap_disable_wdt(void)
>> +{
>> +if (cpu_class_is_omap2())
>
> This code is already in mach-omap2/devices.c, so that test should be
> useless.
>
> Regards,
> Benoit
>
>> +omap_hwmod_for_each_by_class("wd_timer",
>> +omap2_disable_wdt, NULL);
>> +return;
>> +}
>> +
>> static int __init omap2_init_devices(void)
>> {
>> /* please keep these calls, and their implementations above,
>> * in alphabetical order so they're easier to sort through.
>> */
>> +omap_disable_wdt();
>> omap_hsmmc_reset();
>> omap_init_camera();
>> omap_init_mbox();
--
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 v6 8/8] Input: omap4 - pm runtime
Abraham Arce writes: > Enable pm runtime in driver So power is enabled on probe and cut on _remove(). Did you consider doing any more fine grained PM for this device? For example, cutting power after some inactivity timer and re-enabling on a keypress/interrupt? Kevin > Reviewed-by: Basak, Partha > Signed-off-by: Abraham Arce > --- > drivers/input/keyboard/omap4-keypad.c |7 +++ > 1 files changed, 7 insertions(+), 0 deletions(-) > > diff --git a/drivers/input/keyboard/omap4-keypad.c > b/drivers/input/keyboard/omap4-keypad.c > index 45bd097..ed47e9a 100644 > --- a/drivers/input/keyboard/omap4-keypad.c > +++ b/drivers/input/keyboard/omap4-keypad.c > @@ -29,6 +29,7 @@ > #include > #include > #include > +#include > > #include > > @@ -239,6 +240,9 @@ static int __devinit omap4_keypad_probe(struct > platform_device *pdev) > matrix_keypad_build_keymap(pdata->keymap_data, row_shift, > input_dev->keycode, input_dev->keybit); > > + pm_runtime_enable(&pdev->dev); > + pm_runtime_get_sync(&pdev->dev); > + > omap4_keypad_config(keypad_data); > > error = request_irq(keypad_data->irq, omap4_keypad_interrupt, > @@ -277,6 +281,9 @@ static int __devexit omap4_keypad_remove(struct > platform_device *pdev) > struct omap4_keypad *keypad_data = platform_get_drvdata(pdev); > struct resource *res; > > + pm_runtime_put_sync(&pdev->dev); > + pm_runtime_disable(&pdev->dev); > + > free_irq(keypad_data->irq, keypad_data); > input_unregister_device(keypad_data->input); -- 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: [Beagleboard] linux-omap-pm -- cpufreq query
Haribabu Narayanan writes: > Till recently I was working with Angstrom environment for > beagleboard (with a linux-omap-pm 2.6.29 kernel) and had to migrate > to the latest kernel version possible that is supported by > linux-omap-pm branch for non-omap related reasons. I am sticking to > linux-omap-pm instead of linux-omap or linux mainlines chiefly because > I need cpufreq related functionalities. > > I was happily using the latest head from linux-omap-pm when I > realised that there are no frequency transitions that are occurring > now when I initiate requests through sys-fs writes. I found out that > OMAP_PM_SRF is no longer supported (which was being used earlier on > for helping with cpufreq changes). > > Is it that one cannot do cpufreq related changes with the > current(+/-) linux-omap-pm kernel? That is correct. > I checked linux-omap-pm's head/cpufreq branch for example and it > contains only OMAP_PM_NONE and OMAP_PM_NOOP in plat-omap/Kconfig. Are > there any changes I can make so that I can get back cpufreq > functionality. The kernel parts that enable DVFS (including SmartReflex, voltage layer etc.) are being rewritten and are under review and test currently. The best way to help would be to contribute to that development and or test these series from Thara. > If yes, is there an general idea as to when this will > be available with linux-omap-pm head ? When it's ready. ;) This is not a commitment, but I suspect we will have this into mainline during the 2.6.38 merge window. 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
[PATCH v3] SoC Camera: add driver for OMAP1 camera interface
This is a V4L2 driver for TI OMAP1 SoC camera interface. Both videobuf-dma versions are supported, contig and sg, selectable with a module option. The former uses less processing power, but often fails to allocate contignuous buffer memory. The latter is free of this problem, but generates tens of DMA interrupts per frame. If contig memory allocation ever fails, the driver falls back to sg automatically on next open, but still can be switched back to contig manually. Both paths work stable for me, even under heavy load, on my OMAP1510 based Amstrad Delta videophone, that is the oldest, least powerfull OMAP1 implementation. The interface generally works in pass-through mode. Since input data byte endianess can be swapped, it provides up to two v4l2 pixel formats per each of several soc_mbus formats that have their swapped endian counterparts. Boards using this driver can provide it with the following platform data: - if and what freqency clock is expected by an on-board camera sensor, - what is the maximum pixel clock that should be accepted from the sensor, - what is the polarity of the sensor provided pixel clock, - if the interface GPIO line is connected to a sensor reset/powerdown input and what is the input polarity. Created and tested against linux-2.6.36-rc5 on Amstrad Delta. Signed-off-by: Janusz Krzysztofik --- Guennadi, Since 2.6.36-rc6 is out, I've decided to submit the driver, no longer trying to make it still better or waiting for more comments, in hope it's still not too late for it to be merged during the upcomming window. The redefined set_fmt and set_crop operations work for me as expected with the last version (v3) of my ov6650 sensor driver. There are still two SG mode specific corner cases to be corrected, previously not detected because of poor sensor driver functionality: 1) frame size not exceeding one page, resulting in "unexpected end of frame" message and capture restart every frame, and 2) last sgbuf lenght less than bytes_per_line, resulting in unstable picture. I'm going to address those two with fixes. Thanks, Janusz v2->v3 changes: requested, suggested or inspired by Guennadi Liakhovetski (thanks again!): - compare enum variable against one of enum values instead of relaying on the fact that a possible value can be either 0 or not 0, - put an argument inside parenthesis in a macro definition, - CONTIG and SG are not good enough names to be defined in a header under include/..., - still better explain why suspend capture if pcdev->ready is NULL on buffer completion, - ephasize the fact and explain why not fetch new buffer from the queue immediately, rather do it only when a next DMA interrupt occures, - use more correct English wording in a few cases, - explain why not yet call videobuf_done() right after the end of current sglist is detected, but only on next DMA interrupt, - don't split strings, even on print format specifier boudries, - v2 updated subdev_call_with_sense() macro return value was no longer stored in a variable which was still examined next, - don't store 1 in a bool variable, use "true" instead, - allocate register cache dynamically based on platform resource size instead of sizing it staticaly with a predefined OMAP1_CAMERA_IOSIZE macro; move this macro out of the , suggested by Ralph Corderoy (thanks again!): - a few hex print formats still not optimal, other: - correct a few typos still found, - if a block consisting of a single command contains a comment as well, it should be enclosed in braces, - make the driver less noisy by lowering down levels of a fwe more messages, - is_dma_aligned() and dma_align() results can depend on vb_mode istead of always assuming CONTIG mode as a worth case, - redefine set_crop and set_fmt algorithms to better follow the v4l2 model, drop a few no longer used helper functions, create a new one, set_mbus_format(), from the new code common to both operations. v1->v2 changes: requested by Guennadi Liakhovetski (thanks!): - first try contig, and if it fails - fall back to sg; invalidates next two, - invalidated: Kconfig: VIDEO_OMAP1_SG: not need "if", the "depends on" should suffice, - invalidated: include both and headers, - extensively document buffer manipulations, better yet clean it up, - a copyright / licence header was missing form a header file, - need to #include if using BIT() macro, - don't need macros representing frequencies - use numbers directly, - add a few missing "static" qualifiers, - use u32 type for register content handling, - some cached registers were unnecessarily read from the hardware directly, - use true/false constants instead of 0/1 for booleans, - avoid assigning variables inside other constructs, - don't need to test if RAZ_FIFO is cleared, - no need to split "\n" to a new line, don't worry about > 80 characters, - don't increment field_count in case of a VIDEOBUF_ERROR, - adjust mbus format codes to the new names, - m
RE: [PATCH 9/9 v3] usb : musb: Offmode fix for idle path
>-Original Message- >From: Kevin Hilman [mailto:khil...@deeprootsystems.com] >Sent: Tuesday, September 28, 2010 9:14 PM >To: Kalliguddi, Hema >Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org; >Mankad, Maulik Ojas; Balbi, Felipe; Tony Lindgren; Cousson, >Benoit; Paul Walmsley >Subject: Re: [PATCH 9/9 v3] usb : musb: Offmode fix for idle path > >"Kalliguddi, Hema" writes: > >>>-Original Message- >>>From: Kevin Hilman [mailto:khil...@deeprootsystems.com] >>>Sent: Tuesday, September 28, 2010 12:27 AM >>>To: Kalliguddi, Hema >>>Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org; >>>Mankad, Maulik Ojas; Balbi, Felipe; Tony Lindgren; Cousson, >>>Benoit; Paul Walmsley >>>Subject: Re: [PATCH 9/9 v3] usb : musb: Offmode fix for idle path >>> >>>"Kalliguddi, Hema" writes: >>> >-Original Message- >From: Kevin Hilman [mailto:khil...@deeprootsystems.com] >Sent: Saturday, September 25, 2010 1:12 AM >To: Kalliguddi, Hema >Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org; >Mankad, Maulik Ojas; Balbi, Felipe; Tony Lindgren; Cousson, >Benoit; Paul Walmsley >Subject: Re: [PATCH 9/9 v3] usb : musb: Offmode fix for idle path > >Hema HK writes: > >> With OMAP core-off support musb was not functional as >context was getting >> lost after wakeup from core-off. > >This should be a separate patch. > Let me give the description of the musb offmode support in >>>the idle path. >>> >>>The detail you provided below is very good, and this is the level of >>>detail that needs to go into the changelogs. >>> With the current mainline code, offmode in the idle path is >>>not supported with usb. When the core hits off and wakes up the musb will not be >functional. This patch is to support the musb functionality with offmode >>>enabled in the idle path. >>> >>>OK, what about the PM branch. I was under the impression >that offmode >>>was working fine in the PM branch. >>> >> In current PM branch, the core hits retention and off mode >without usb drive loaded. >> Once after loading the musb driver it may not retention/off >also as the driver is >> configuring musb in smart idle/standby. Even if it hits >retention/off as it might >> work sometimes,MUSB is not functional.because there is no >context save/restore >> done in the driver. >> >>>And, looking at the PM branch, the only thing done in the >idle path is >>>the disable of autoidle upon wakeup. Everything else (context >>>save/restore etc.) is done in the driver. >>> >> No.There is no context save/restore done in the driver today. > >There is, just not in the idle path as you pointed out. > >The point of all this is that the changelog and documentation is not >clear (at least to me) about all these details save/restore in idle, or >in suspend/resume etc., and why the result is different (or needs to be >different) from the current code. > There is no difference in the settings or the result in the idle path or global suspend/resume path. GLOBAL SUSPEND/RESUME: - In the current PM line, musb is configured to force idle and forcestandby mode by default when the device is registered. When there is no driver loaded, theere is no issue, core hits retention/offmode. When the musb driver is loaded, it configures it into smart idle/standby mode. So when pm_ops .suspend/resume apis are called during global suspend/resume, context save/restore and clock disable/enable is happening, the observation is that sometimes, the core hits retention/offmode, but not consistently. The recomandation from the ip team to configure it to force idle/standby mode when device is not used. For the global suspend/resume, this is being achieved by setting the oh flags (HWMOD_SWSUP_SIDLE and HWMOD_SWSUP_MSTANDBY)in the hwmod data structure for OMAP2 OMAP3 and OMAP4.Description of why these flags are needed are mentioned in the respective patches. By calling runtime put_sync and get_sync apis in the driver pm_ops .suspend/resume will configure the musb in the required mode and save/restore the context is taken care in the runtime_suspend/resume hooks. This change is done in the [PATCH 8/9 v3] usb : musb: Using runtime pm apis for musb. IDLE PATH RRETENTION/OFFMODE SUPPORT: - The current pm line musb is not functional when the core hits offmode and wakesup. This patch is to support offmode/retention with musb functional. This patch has only the required changes for supporting the musb with with idle path offmode. This patch is only for supporting offmode with musb in the idle path. No other changes as part of this patch. Below are the requirements to support retention and offmode >>>of OMAP in idle path with usb enabled During idle and when there is no activity on the bus: 1.Since there is no hardware context save/restore supported >>>in OMAP for musb, software has to save the c
Re: [PATCH] OMAP4: Extend clock data.
Hi Thara,
Here is the full email...
On 9/30/2010 10:57 AM, Paul Walmsley wrote:
Hello Thara,
On Thu, 30 Sep 2010, Thara Gopinath wrote:
This patch extends the OMAP4 clock data to include
various x2 clock nodes as the clock framework
skips a *2 whie calculating the dpll locked frequency.
Signed-off-by: Thara Gopinath
Acked-by: Kevin Hilman
---
Currently the framework is extended to include x2 nodes
only for a few clocks critical for OMAP4 DVFS. This
exercise needs to be done for most of the other post divider
clocks as and when necessary.
Benoît and I have been discussing this - I think we should probably fix
this problem for all of the DPLLs and HSDIVIDERs in one patch. I'll let
Benoît comment further, but I think the current plan will be to generate a
CLKOUTX2 node after the DPLLs, and then to use that as the parent for
the various HSDIVIDERs that use that X2 output.
Here is the way it should look for my point of view in order to be
closer to the HW implementation:
+-> /2 -> M2
|
+-> M2x2 -+--->
|
DPLL ---> DPLLx2 -+-> M3 (should be M3x2)
|
+-> M4 (should be M4x2)
|
+-> M5 (should be M5x2)
|
+-> M6 (should be M6x2)
|
+-> M7 (should be M7x2)
All DPLL, except the USB one, will use the same pattern. Only the number
of HS dividers will change.
For information, here is an extract from the ES1 DB. The HS name is
indeed not very consistent.
There is no x2 in the HS dividers name whereas it should.
'dpll_abe': {
'outputs': {
'm2': 'dpll_abe_m2',
'm2x2': 'dpll_abe_m2x2',
'm3': 'dpll_abe_m3'},
'dpll_core': {
'outputs': {
'm2': 'dpll_core_m2',
'm3': 'dpll_core_m3',
'm4': 'dpll_core_m4',
'm5': 'dpll_core_m5',
'm6': 'dpll_core_m6',
'm7': 'dpll_core_m7'},
'dpll_iva': {
'outputs': {
'm4': 'dpll_iva_m4',
'm5': 'dpll_iva_m5'},
'dpll_mpu': {
'outputs': {
'm2': 'dpll_mpu_m2'},
'dpll_per': {
'outputs': {
'm2': 'dpll_per_m2',
'm2x2': 'dpll_per_m2x2',
'm3': 'dpll_per_m3',
'm4': 'dpll_per_m4',
'm5': 'dpll_per_m5',
'm6': 'dpll_per_m6',
'm7': 'dpll_per_m7'},
'dpll_unipro': {
'outputs': {
'm2x2': 'dpll_unipro_m2x2'},
'dpll_usb': {
'outputs': {
'clkdcoldo': 'dpll_usb_clkdcoldo',
'm2': 'dpll_usb_m2'},
So we should probably rename all the m3..m7 with m3x2..m7x2 name.
Also, I think we should make this change in a consistent way with regards
to what the autogeneration scripts should generate. This way, we won't
have to redo it later and cause unnecessary patch noise.
Perhaps you can help Benoît update the autogeneration scripts for the
above changes?
You can ask Rajendra if you need some detail about the tools.
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: [PATCH] OMAP4: Extend clock data.
On 9/30/2010 11:16 AM, Cousson, Benoit wrote: Hi Thara, On 9/30/2010 10:57 AM, Paul Walmsley wrote: Hello Thara, On Thu, 30 Sep 2010, Thara Gopinath wrote: This patch extends the OMAP4 clock data to include various x2 clock nodes as the clock framework skips a *2 whie calculating the dpll locked frequency. Signed-off-by: Thara Gopinath Acked-by: Kevin Hilman --- Currently the framework is extended to include x2 nodes only for a few clocks critical for OMAP4 DVFS. This exercise needs to be done for most of the other post divider clocks as and when necessary. Benoît and I have been discussing this - I think we should probably fix this problem for all of the DPLLs and HSDIVIDERs in one patch. I'll let Benoît comment further, but I think the current plan will be to generate a CLKOUTX2 node after the DPLLs, and then to use that as the parent for the various HSDIVIDERs that use that X2 output. Here is That's a nice cliffhanger, isn't it? You'll have the remaining part in a next episode... Benoit Also, I think we should make this change in a consistent way with regards to what the autogeneration scripts should generate. This way, we won't have to redo it later and cause unnecessary patch noise. Perhaps you can help Benoît update the autogeneration scripts for the above changes? - 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP4: Extend clock data.
Hi Thara, On 9/30/2010 10:57 AM, Paul Walmsley wrote: Hello Thara, On Thu, 30 Sep 2010, Thara Gopinath wrote: This patch extends the OMAP4 clock data to include various x2 clock nodes as the clock framework skips a *2 whie calculating the dpll locked frequency. Signed-off-by: Thara Gopinath Acked-by: Kevin Hilman --- Currently the framework is extended to include x2 nodes only for a few clocks critical for OMAP4 DVFS. This exercise needs to be done for most of the other post divider clocks as and when necessary. Benoît and I have been discussing this - I think we should probably fix this problem for all of the DPLLs and HSDIVIDERs in one patch. I'll let Benoît comment further, but I think the current plan will be to generate a CLKOUTX2 node after the DPLLs, and then to use that as the parent for the various HSDIVIDERs that use that X2 output. Here is Also, I think we should make this change in a consistent way with regards to what the autogeneration scripts should generate. This way, we won't have to redo it later and cause unnecessary patch noise. Perhaps you can help Benoît update the autogeneration scripts for the above changes? - 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] OMAP2PLUS: WDT: Fix: Disable WDT after reset during init
Hi Charu,
On 9/30/2010 10:11 AM, Varadarajan, Charulatha wrote:
With OMAP2PLUS watchdog implemented in hwmod fw way, the
module is reset during init.
In that case hwmod fw just highlighted the real behavior that was hidden
so far by the X-loader.
You should as well add a link to the email thread with Kevin that raised
the issue.
After a watchdog timer module reset, the WDTs are enabled. The
default time for a system reset after a watchdog module reset
is ~10s as per the default value of the WDT registers. Hence
the system would be reset after 10s, if watchdog is not disabled
within 10s.
This patch fixes the above issue by disabling the watchdog timer
after reset during initialization of devices.
I'm still wondering as well what is the expected behavior of the
watchdog in a real product. If it is started by default at boot time,
this is probably for a good reason (or maybe not...).
So, disabling it all the time is maybe not the best solution.
Nishanth (M),
Do you have an idea on that topic?
Signed-off-by: Charulatha V
Reported-by: Kevin Hilman
---
This patch is dependent on the below patch series (wdt hwmod) and
is created on top of pm-core branch.
http://www.spinics.net/lists/linux-omap/msg37043.html
arch/arm/mach-omap2/devices.c | 44 +
1 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 8e2f0aa..9f44fc6 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -916,11 +916,55 @@ static inline void omap_init_vout(void) {}
/*-*/
+/*
+ * WDT mdoule is reset during init which enables the watchdog.
typo: module
The real explanation is that you should not assume anything from the
boot loader at that time, so always stop the wdt.
+ * Hence it is required to disable the watchdog after the WDT reset
+ * during init. Otherwise the system would reboot as per the default
+ * watchdog timer registers settings.
+ */
+#define OMAP_WDT_WPS (0x34)
+#define OMAP_WDT_SPR (0x48)
+
+static int omap2_disable_wdt(struct omap_hwmod *oh, void *user)
You should call it unused if the parameter is not used.
+{
+ void __iomem *base;
+
+ if (!oh)
+ pr_err("Could not look up wdtimer_hwmod\n");
+
+ base = oh->_mpu_rt_va;
Paul added an hwmod API to get that va (something like *_get_mpu_rt_va).
+
+ /* Enable the clocks before accessing the WDT registers */
+ omap_hwmod_enable(oh);
The enable can fail, so you should check the return value.
+
+ /* sequence required to disable watchdog */
+ __raw_writel(0x, base + OMAP_WDT_SPR); /* TIMER_MODE */
+ while (__raw_readl(base + OMAP_WDT_WPS)& 0x10)
+ cpu_relax();
+
+ __raw_writel(0x, base + OMAP_WDT_SPR); /* TIMER_MODE */
+ while (__raw_readl(base + OMAP_WDT_WPS)& 0x10)
+ cpu_relax();
+
+ omap_hwmod_idle(oh);
+
+ return 0;
+}
+
+static void __init omap_disable_wdt(void)
+{
+ if (cpu_class_is_omap2())
This code is already in mach-omap2/devices.c, so that test should be
useless.
Regards,
Benoit
+ omap_hwmod_for_each_by_class("wd_timer",
+ omap2_disable_wdt, NULL);
+ return;
+}
+
static int __init omap2_init_devices(void)
{
/* please keep these calls, and their implementations above,
* in alphabetical order so they're easier to sort through.
*/
+ omap_disable_wdt();
omap_hsmmc_reset();
omap_init_camera();
omap_init_mbox();
--
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
