Re: [PATCH 1/3] ARM: omap2+: set IRQCHIP_SKIP_SET_WAKE for INTC interrupts.
On Fri, Apr 27, 2012 at 2:09 AM, Kevin Hilman khil...@ti.com wrote: NeilBrown ne...@suse.de writes: [...] From 644742ddae59731bc10aacde94645d7c49ca5ecd Mon Sep 17 00:00:00 2001 From: NeilBrown ne...@suse.de Date: Wed, 25 Apr 2012 13:05:24 +1000 Subject: [PATCH] ARM: omap2+: set IRQCHIP_SKIP_SET_WAKE for INTC interrupts. Without an -irq_set_wake() method in an irq_chip, calls to enable_irq_wake() will fail. This also causes these interrupts to not be able to abort suspend (via check_wakeup_irqs() in late suspend.) Currently, we don't implement -irq_set_wake() for INTC interrupts because they default to be wakeup enabled by setting the GRPSEL bits in PM init. Even though there is no -irq_set_wake(), we want enable_irq_wake() to succeed so these interrupts can abort suspend when necessary. To fix, set IRQCHIP_SKIP_SET_WAKE flag for all the INTC interrupts which avoids trying to check irq_chip-irq_set_wake() and failing when it doesn't exist. Longer term, we need to implement -irq_set_wake() for the INTC which can manage the appropriate GRPSEL bits. Signed-off-by: NeilBrown ne...@suse.de [khil...@ti.com: rework changelog] Signed-off-by: Kevin Hilman khil...@ti.com --- Acked-by: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/10] OMAPDSS: HDMI: OMAP4: Remove CEA-861 audio infoframe and IEC-60958 enums
On Thu, 2012-04-26 at 20:32 -0500, Ricardo Neri wrote: On 04/24/2012 10:37 PM, Ricardo Neri wrote: Are the defines left in the hdmi_audio_i2s_config something that are IP specific? Are they even used? I'm just wondering why many of the defines are in sound headers, but some are left here. Some are specific to the OMAP4 HDMI IP, such as HDMI_AUDIO_I2S_SDx_EN. Some others refer to generic I2S concepts (such as I2S_SCK_EDGE_FALLING/RISING) but defines are used to configure registers and such configuration may be different in other hardware. The defines that this patch removes are values that are effectively transmitted to the sink and are clearly defined in the relevant standards. Anyways, I will look at it further to see if some of them can be removed as well. Also, the I2S is the same for most of the supported use-cases, if not all of them. Maybe I can remove the unused ones. I took at a second look at the hdmi_audio_i2s_config. As they are used to set IP-specific registers, I think they should be kept. Regarding the unused defines, they are not too many, do not do harm and let you know what other config values are available. I would like to keep them. What do you think? Sounds ok to me. I was just worried that there could be some kind of mixup as only parts of the hdmi_audio_i2s_config were removed. But if the rest are IP specific, I think it's fine. Tomi signature.asc Description: This is a digitally signed message part
RE: [PATCH-V4 4/4] ARM: OMAP3+: am33xx: Add powerdomain PRM support
On Fri, Apr 27, 2012 at 06:19:02, Hilman, Kevin wrote: Vaibhav Hiremath hvaib...@ti.com writes: As far as PRM/CM/PRCM modules are concerned, AM33XX device is different than OMAP3 and OMAP4 architectures; so we need to handle it separately. This patch adds support for, Powerdomain, Powerdomain data, PRM api's required for AM33XX device. And also, hooks up AM33XX powerdomain to existing OMAP framework. [...] @@ -1288,7 +1289,15 @@ static int _assert_hardreset(struct omap_hwmod *oh, const char *name) if (IS_ERR_VALUE(ret)) return ret; - if (cpu_is_omap24xx() || cpu_is_omap34xx()) + /* +* cpu_is_omap34xx() is true for am33xx device as well, so +* fist check for cpu_is_am33xx(). +*/ + if (cpu_is_am33xx()) + return am33xx_prm_assert_hardreset(ohri.rst_shift, + oh-clkdm-pwrdm.ptr-prcm_offs, + oh-prcm.omap4.rstctrl_offs); This still troubles me. I *really* don't like that we have a dependence on cpu_is* call ordering. This is very fragile and error prone. I also don't like all the cpu_is* checking currently in omap_hwmod.c (which is here before you added this) and have an idea on how to clean it up, I should have a patch by tomorrow for this. That should help adding am33xx support here without needing all the cpu_is* checking. That being said, I just did a simple experiment[1] to see why cpu_is_omap34xx() needs to be true for AM33xx in the first place. Based on my quick experiment, it does not appear to be needed. I think our lives will be much simpler if cpu_is_omap34xx() is not true for the AM335x family. Can you have a look at my test branch[1] and see what you think? I changed the omap_revision for AM335x so that cpu_is_omap34xx() is no longer true on this platform. Then, I only needed to fixup the SRAM init, and it boots just fine on my BeagleBone. I really think we need to go this route, because having cpu_is_omap34xx() true on AM335x is causing more headaches than it is solving problems. This will require you to rework a little bit these clock/power/voltage domain patches, but I belive it will greatly simplify the maintainability of the end result. Let me spend some time, and explore your changes; I think getting system to boot should not be only criteria here. But honestly, I fully agree with you that, we are creating more issue, adding more cpu_is_xxx() checks, with cpu_is_34xx() true for AM33xx. As I have done in the past initially, I recommend and vote for, 1. Creating separate family cpu_is_am33xx() for AM33xx device. OR 2. Bring it to omap44xx family, since prcm block is closer to omap4 and not with omap3. Also, Tony, I will let tony make a decision on this. By the time, Tony makes his decision, I will spend time to explore your (Kevin's below) branch. Thanks, Vaibhav Kevin [1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tmp/am335x-cpu-is-hacking -- 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/RFT 3/3] ARM: OMAP3: PM: cleanup cam_pwrdm leftovers
Looks good to me, acked.
-Tero
On Tue, 2012-04-24 at 07:23 -0700, Kevin Hilman wrote:
commit e7410cf7 (02fdb03e69699f26e1370d0e51593dbc8a4e5265) moved
mangement of cam_pwrdm to CPUidle but left some remnants behind,
namely the call to clkcm_allo_idle() for the clockdomains in the MPU
pwrdm. Remove these since they are not necessary and cause unwanted
latency in the idle path.
Cc: Tero Kristo Tero Kristo t-kri...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/pm34xx.c |4
1 file changed, 4 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 74a7f8c..66ff828 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -70,7 +70,6 @@ void (*omap3_do_wfi_sram)(void);
static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
static struct powerdomain *core_pwrdm, *per_pwrdm;
-static struct powerdomain *cam_pwrdm;
static void omap3_enable_io_chain(void)
{
@@ -395,8 +394,6 @@ void omap_sram_idle(void)
if (mpu_next_state PWRDM_POWER_ON)
pwrdm_post_transition(mpu_pwrdm);
-
- clkdm_allow_idle(mpu_pwrdm-pwrdm_clkdms[0]);
}
static void omap3_pm_idle(void)
@@ -759,7 +756,6 @@ static int __init omap3_pm_init(void)
neon_pwrdm = pwrdm_lookup(neon_pwrdm);
per_pwrdm = pwrdm_lookup(per_pwrdm);
core_pwrdm = pwrdm_lookup(core_pwrdm);
- cam_pwrdm = pwrdm_lookup(cam_pwrdm);
neon_clkdm = clkdm_lookup(neon_clkdm);
mpu_clkdm = clkdm_lookup(mpu_clkdm);
--
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 3/3] ARM: OMAP: Make OMAP clocksource source selection using kernel param
On Fri, Apr 27, 2012 at 02:13:10, Dill, Russ wrote: On Thu, Apr 26, 2012 at 11:33 AM, Kevin Hilman khil...@ti.com wrote: Vaibhav Hiremath hvaib...@ti.com writes: If so, please reply with your Tested-by. Tested-by: Russ Dill russ.d...@ti.com All three patches in series boot tested on: Beagleboard xM Beagleboard B4 Mistral AM37X-EVM Thanks Russ, helping me out in validating this. I have also tested it on AM37xEVM platform and can conform that this fixes the issue. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] gpio/omap: fix incorrect initialization of omap_gpio_mod_init
Breaking commit: ab985f0f7c2c0ef90b7c832f0c04f470dda0593d Initialization of irqenable, irqstatus registers is the common operation done in this function for all OMAP platforms, viz. OMAP1, OMAP2+. The latter _gpio_rmw()'s to irqenable register was overwriting the correctly programmed OMAP1 value at the beginning. As a result, even though it worked on OMAP2+ platforms it was breaking OMAP1 functionality. On close observation it is found that the first _gpio_rmw() which is supposedly done to take care of OMAP1 platform is generic enough and takes care of OMAP2+ platform as well. Therefore remove the latter _gpio_rmw() to irqenable as they are redundant now. Writing to ctrl and debounce_en registers for OMAP2+ platforms are modified to match the original(pre-cleanup) code where the registers are initialized with 0. In the cleanup series since we are using _gpio_rmw(reg, 0, 1), instead of __raw_writel(), we are just reading and writing the same values to ctrl and debounce_en. This is not an issue for debounce_en register because it has 0x0 as the default value. But in the case of ctrl register the default value is 0x2 (GATINGRATIO = 0x1) so that we end up writing 0x2 instead of intended 0 value. Therefore correcting it to _gpio_rmw(reg, l, 0), where l = 0x so that registers are initialized to 0. Also, changing the sequence and logic of initializing the irqstatus. Cc: sta...@vger.kernel.org Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Grant Likely grant.lik...@secretlab.ca Reported-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com --- Tested on OMAP2+ platforms and bootup test on OMAP1710. Janusz, Please help me in validating the patch on OMAP1 platform. drivers/gpio/gpio-omap.c |9 +++-- 1 files changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c index 1adc2ec..910fd14 100644 --- a/drivers/gpio/gpio-omap.c +++ b/drivers/gpio/gpio-omap.c @@ -964,19 +964,16 @@ static void omap_gpio_mod_init(struct gpio_bank *bank) return; } + _gpio_rmw(base, bank-regs-irqstatus, l, !bank-regs-irqenable_inv); _gpio_rmw(base, bank-regs-irqenable, l, bank-regs-irqenable_inv); - _gpio_rmw(base, bank-regs-irqstatus, l, - bank-regs-irqenable_inv == false); - _gpio_rmw(base, bank-regs-irqenable, l, bank-regs-debounce_en != 0); - _gpio_rmw(base, bank-regs-irqenable, l, bank-regs-ctrl != 0); if (bank-regs-debounce_en) - _gpio_rmw(base, bank-regs-debounce_en, 0, 1); + _gpio_rmw(base, bank-regs-debounce_en, l, 0); /* Save OE default value (0x) in the context */ bank-context.oe = __raw_readl(bank-base + bank-regs-direction); /* Initialize interface clk ungated, module enabled */ if (bank-regs-ctrl) - _gpio_rmw(base, bank-regs-ctrl, 0, 1); + _gpio_rmw(base, bank-regs-ctrl, l, 0); } static __devinit void -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain PRM support for AM33XX device
On Fri, Apr 27, 2012 at 00:35:25, Tony Lindgren wrote: * Hiremath, Vaibhav hvaib...@ti.com [120426 11:52]: Yes, they were accepted and were also available under linux-omap/soc2 branch for quite some time. Hmm sorry if I've dropped them accidentally. I tend to drop the branches after each merge window and purge my linux-omap mailbox too. I can understand, I will submit another version for this. I will be waiting for your comment and conformation on, which family AM33xx device should fall in? Please refer to the mail-chain - http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67275.html Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH-V3 2/3] ARM: OMAP3+: clockdomain33xx: Add clockdomain data and respective operations
On Fri, Apr 27, 2012 at 00:26:47, Paul Walmsley wrote:
On Thu, 26 Apr 2012, Hiremath, Vaibhav wrote:
On Thu, Apr 26, 2012 at 14:27:20, Paul Walmsley wrote:
(attribution lost)
I am thinking of separating clocktree patch (PATCH-V3 3/3) from this
series,
so that clockdomain stuff can get in independently, and clocktree
anyway
will follow them (it may take some time in review cycle).
Yes, I was thinking of doing this too. The only aspect that gave me
pause
is that the clockdomain changes are not 100% separate from the clock
tree.
So we may have to update the clockdomain data as the clock tree changes.
Why do you say that, clockdomain changes are not 100% separate from
clocktree? It is completely independent...
Clock enables and disables call clkdm_clk_{enable,disable}() which
undertakes the clockdomain enable sequence on the first clock enabled
inside the clockdomain, and the clockdomain disable sequence on the last
clock inside the clockdomain. The clockdomain is associated with the
clock via the struct clk .clkdm and .clkdm_name fields.
Paul,
struct clk will come into picture when we define clocktree
(clock33xx_data.c file), isn't it?
From clockdomain perspective, it is still independent and definite set of
clock domains as per device with respective api's required to control it.
Which clock falls down to which domain, is defined in clocktree
(clock33xx_data.c file), isn't it?
So yes, they are interconnected; particularly if the clkdiv32k MODULEMODE
clock is really needed.
Coming back to example of div32k clock, assuming this as a module with
MODULEMODE,
static struct clk clkdiv32k_ick = {
.name = clkdiv32k_ick,
.clkdm_name = clk_24mhz_clkdm,
.rate = 32768,
.parent = clk_24mhz,
.enable_reg = AM33XX_CM_PER_CLKDIV32K_CLKCTRL,
.enable_bit = AM33XX_MODULEMODE_SWCTRL,
.ops= clkops_omap2_dflt,
};
And we have separate domain for div32k clock.
static struct clockdomain clk_24mhz_am33xx_clkdm = {
.name = clk_24mhz_clkdm,
.pwrdm = { .name = per_pwrdm },
.cm_inst= AM33XX_CM_PER_MOD,
.prcm_partition = AM33XX_PRM_PARTITION,
.clkdm_offs = AM33XX_CM_PER_CLK_24MHZ_CLKSTCTRL_OFFSET,
.clktrctrl_mask = AM33XX_CLKTRCTRL_MASK,
.flags = (CLKDM_CAN_SWSUP | CLKDM_NO_AUTODEPS),
};
In any case, I believe we have to define this domain in
clockdomain_data, right?
Just FYI, I am about to initiate a mail-chain with design team, on your
questions on div32k. Hopefully I will have some input by Monday.
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: igep0020: Specify the VPLL2 regulator unconditionally
2012/4/23 Laurent Pinchart laurent.pinch...@ideasonboard.com:
The supply is connected to the DSS DO-D5 pins and is thus needed for
both serial and parallel display interfaces on the igep0030 as well as
the igep0020.
If the igep0030 module isn't connected to a display, no DSI or DPI
display will be specified in board code, and the DSS driver won't enable
to VPLL2 regulator anyway.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
arch/arm/mach-omap2/board-igep0020.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index a59ace0..242cdff 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -539,7 +539,10 @@ static void __init igep_i2c_init(void)
{
int ret;
- omap3_pmic_get_config(igep_twldata, TWL_COMMON_PDATA_USB, 0);
+ omap3_pmic_get_config(igep_twldata, TWL_COMMON_PDATA_USB,
+ TWL_COMMON_REGULATOR_VPLL2);
+ igep_twldata.vpll2-constraints.apply_uV = true;
+ igep_twldata.vpll2-constraints.name = VDVI;
if (machine_is_igep0020()) {
/*
@@ -553,10 +556,7 @@ static void __init igep_i2c_init(void)
igep_twldata.keypad = igep2_keypad_pdata;
/* Get common pmic data */
- omap3_pmic_get_config(igep_twldata, TWL_COMMON_PDATA_AUDIO,
- TWL_COMMON_REGULATOR_VPLL2);
- igep_twldata.vpll2-constraints.apply_uV = true;
- igep_twldata.vpll2-constraints.name = VDVI;
+ omap3_pmic_get_config(igep_twldata, TWL_COMMON_PDATA_AUDIO,
0);
}
omap3_pmic_init(twl4030, igep_twldata);
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Seems good to me.
Tony, as this is a fix ,may be included ?
Acked-by: Enric Balletbo i Serra eballe...@gmail.com
Tested-by: Enric Balletbo i Serra eballe...@gmail.com
Cheers,
Enric
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH 1/2] ARM: OMAP2+: nand: Make board_onenand_init() visible to board code
On Wed, Apr 25, 2012 at 9:59 AM, Enric Balletbò i Serra
eballe...@gmail.com wrote:
2012/4/4 Javier Martinez Canillas jav...@dowhile0.org:
board_onenand_init() and board_nand_init() initialization functions are
used to initialize OneNAND and NAND memories respectively. But only
board_nand_init() was visible to be used from board code. This patch makes
possible to initialize a OneNAND flash memory within platform code.
Signed-off-by: Javier Martinez Canillas jav...@dowhile0.org
---
arch/arm/mach-omap2/board-flash.c | 4 ++--
arch/arm/mach-omap2/board-flash.h | 11 +++
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index 0349fd2..70a81f9 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -87,7 +87,7 @@ static struct omap_onenand_platform_data
board_onenand_data = {
.dma_channel = -1, /* disable DMA in OMAP OneNAND driver */
};
-static void
+void
__init board_onenand_init(struct mtd_partition *onenand_parts,
u8 nr_parts, u8 cs)
{
@@ -98,7 +98,7 @@ __init board_onenand_init(struct mtd_partition
*onenand_parts,
gpmc_onenand_init(board_onenand_data);
}
#else
-static void
+void
__init board_onenand_init(struct mtd_partition *nor_parts, u8 nr_parts, u8
cs)
{
}
diff --git a/arch/arm/mach-omap2/board-flash.h
b/arch/arm/mach-omap2/board-flash.h
index d25503a..c44b70d 100644
--- a/arch/arm/mach-omap2/board-flash.h
+++ b/arch/arm/mach-omap2/board-flash.h
@@ -47,3 +47,14 @@ static inline void board_nand_init(struct mtd_partition
*nand_parts,
{
}
#endif
+
+#if defined(CONFIG_MTD_ONENAND_OMAP2) || \
+ defined(CONFIG_MTD_ONENAND_OMAP2_MODULE)
+extern void board_onenand_init(struct mtd_partition *nand_parts,
+ u8 nr_parts, u8 cs);
+#else
+static inline void board_onenand_init(struct mtd_partition *nand_parts,
+ u8 nr_parts, u8 cs)
+{
+}
+#endif
--
1.7.7.6
Seems good to me.
Tony, as this is a fix ,may be included ?
Acked-by: Enric Balletbo i Serra eballe...@gmail.com
Tested-by: Enric Balletbo i Serra eballe...@gmail.com
Cheers,
Enric
Hi Tony, Russel:
This patch is a requirement for patch:
[RESEND PATCH 2/2] OMAP3: igep0020: Add support for Micron NAND Flash
storage memory
which is really important since newer IGEPv2 boards have changed their
flash memory from OneNAND to NAND.
This patch-set is necessary to make the board work, otherwise it
doesn't even boot.
Could we please include these patches?
Thanks a lot and best regards,
Javier
--
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 3/3] ARM: OMAP3+: clock33xx: Add AM33XX clock tree data
On Thu, Apr 26, 2012 at 14:19:28, Paul Walmsley wrote: Hello Vaibhav, looking at Table 1-1 Device Features of SPRUH73D, it seems that some AM33xx family chips come with some features disabled, such as the PRU-ICSS, the SGX, Ethernet, or USB. How will this affect the clock tree? For example, is it correct for us to include the PRU-ICSS clock control on a clock tree that is booted on an AM3352 or an AM3354? I thought of this, but if you look at the existing way of handling such Si version based clock registration is supported by cpu_clkflg, like CK_3XXX, CK_AM35XX, etc... During my baseport patch submission, Tony had removed CK_AM33XX flag while merging them. I believe, we are trying to get rid of these flags, and that's where Tony had removed them form my baseport patch. I was not sure on how to handle this, so I decided to continue with full chip support (AM3358 and AM3359). Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP3: Fix CM register bit masks
The register bits for MPU_CLK_SRC and IVA2_CLK_SRC in CM_CLKSEL1_PLL register are 3 bits wide. Fix the MASK definition accordingly. Signed-off-by: Rajendra Nayak rna...@ti.com --- arch/arm/mach-omap2/cm-regbits-34xx.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h b/arch/arm/mach-omap2/cm-regbits-34xx.h index b912759..8083a8c 100644 --- a/arch/arm/mach-omap2/cm-regbits-34xx.h +++ b/arch/arm/mach-omap2/cm-regbits-34xx.h @@ -79,7 +79,7 @@ /* CM_CLKSEL1_PLL_IVA2 */ #define OMAP3430_IVA2_CLK_SRC_SHIFT19 -#define OMAP3430_IVA2_CLK_SRC_MASK (0x3 19) +#define OMAP3430_IVA2_CLK_SRC_MASK (0x7 19) #define OMAP3430_IVA2_DPLL_MULT_SHIFT 8 #define OMAP3430_IVA2_DPLL_MULT_MASK (0x7ff 8) #define OMAP3430_IVA2_DPLL_DIV_SHIFT 0 @@ -124,7 +124,7 @@ /* CM_CLKSEL1_PLL_MPU */ #define OMAP3430_MPU_CLK_SRC_SHIFT 19 -#define OMAP3430_MPU_CLK_SRC_MASK (0x3 19) +#define OMAP3430_MPU_CLK_SRC_MASK (0x7 19) #define OMAP3430_MPU_DPLL_MULT_SHIFT 8 #define OMAP3430_MPU_DPLL_MULT_MASK(0x7ff 8) #define OMAP3430_MPU_DPLL_DIV_SHIFT0 -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 1/7] ddr: add LPDDR2 data from JESD209-2
From: Aneesh V ane...@ti.com add LPDDR2 data from the JEDEC spec JESD209-2. The data includes: 1. Addressing information for LPDDR2 memories of different densities and types(S2/S4) 2. AC timing data. This data will useful for memory controller device drivers. Right now this is used by the TI EMIF SDRAM controller driver. Signed-off-by: Aneesh V ane...@ti.com Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com Reviewed-by: Benoit Cousson b-cous...@ti.com [santosh.shilim...@ti.com: Moved to drivers/memory from drivers/misc] Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Tested-by: Lokesh Vutla lokeshvu...@ti.com Cc: Greg KH g...@kroah.com --- include/memory/jedec_ddr.h | 175 lib/Kconfig|8 ++ lib/Makefile |2 + lib/jedec_ddr_data.c | 135 ++ 4 files changed, 320 insertions(+), 0 deletions(-) create mode 100644 include/memory/jedec_ddr.h create mode 100644 lib/jedec_ddr_data.c diff --git a/include/memory/jedec_ddr.h b/include/memory/jedec_ddr.h new file mode 100644 index 000..ddad0f8 --- /dev/null +++ b/include/memory/jedec_ddr.h @@ -0,0 +1,175 @@ +/* + * Definitions for DDR memories based on JEDEC specs + * + * Copyright (C) 2012 Texas Instruments, Inc. + * + * Aneesh V ane...@ti.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ +#ifndef __LINUX_JEDEC_DDR_H +#define __LINUX_JEDEC_DDR_H + +#include linux/types.h + +/* DDR Densities */ +#define DDR_DENSITY_64Mb 1 +#define DDR_DENSITY_128Mb 2 +#define DDR_DENSITY_256Mb 3 +#define DDR_DENSITY_512Mb 4 +#define DDR_DENSITY_1Gb5 +#define DDR_DENSITY_2Gb6 +#define DDR_DENSITY_4Gb7 +#define DDR_DENSITY_8Gb8 +#define DDR_DENSITY_16Gb 9 +#define DDR_DENSITY_32Gb 10 + +/* DDR type */ +#define DDR_TYPE_DDR2 1 +#define DDR_TYPE_DDR3 2 +#define DDR_TYPE_LPDDR2_S4 3 +#define DDR_TYPE_LPDDR2_S2 4 +#define DDR_TYPE_LPDDR2_NVM5 + +/* DDR IO width */ +#define DDR_IO_WIDTH_4 1 +#define DDR_IO_WIDTH_8 2 +#define DDR_IO_WIDTH_163 +#define DDR_IO_WIDTH_324 + +/* Number of Row bits */ +#define R9 9 +#define R1010 +#define R1111 +#define R1212 +#define R1313 +#define R1414 +#define R1515 +#define R1616 + +/* Number of Column bits */ +#define C7 7 +#define C8 8 +#define C9 9 +#define C1010 +#define C1111 +#define C1212 + +/* Number of Banks */ +#define B1 0 +#define B2 1 +#define B4 2 +#define B8 3 + +/* Refresh rate in nano-seconds */ +#define T_REFI_15_615600 +#define T_REFI_7_8 7800 +#define T_REFI_3_9 3900 + +/* tRFC values */ +#define T_RFC_90 9 +#define T_RFC_110 11 +#define T_RFC_130 13 +#define T_RFC_160 16 +#define T_RFC_210 21 +#define T_RFC_300 30 +#define T_RFC_350 35 + +/* Mode register numbers */ +#define DDR_MR00 +#define DDR_MR11 +#define DDR_MR22 +#define DDR_MR33 +#define DDR_MR44 +#define DDR_MR55 +#define DDR_MR66 +#define DDR_MR77 +#define DDR_MR88 +#define DDR_MR99 +#define DDR_MR10 10 +#define DDR_MR11 11 +#define DDR_MR16 16 +#define DDR_MR17 17 +#define DDR_MR18 18 + +/* + * LPDDR2 related defines + */ + +/* MR4 register fields */ +#define MR4_SDRAM_REF_RATE_SHIFT 0 +#define MR4_SDRAM_REF_RATE_MASK7 +#define MR4_TUF_SHIFT 7 +#define MR4_TUF_MASK (1 7) + +/* MR4 SDRAM Refresh Rate field values */ +#define SDRAM_TEMP_NOMINAL 0x3 +#define SDRAM_TEMP_RESERVED_4 0x4 +#define SDRAM_TEMP_HIGH_DERATE_REFRESH 0x5 +#define SDRAM_TEMP_HIGH_DERATE_REFRESH_AND_TIMINGS 0x6 +#define SDRAM_TEMP_VERY_HIGH_SHUTDOWN 0x7 + +#define NUM_DDR_ADDR_TABLE_ENTRIES 11 +#define NUM_DDR_TIMING_TABLE_ENTRIES 4 + +/* Structure for DDR addressing info from the
[PATCH v5 0/7] Add TI EMIF SDRAM controller driver
Add a driver for the EMIF SDRAM controller used in Texas Instrument SoCs EMIF is an SDRAM controller that supports, based on its revision, one or more of LPDDR2/DDR2/DDR3 protocols.This driver adds support for LPDDR2. The driver supports the following features: - Calculates the DDR AC timing parameters to be set in EMIF registers using data from the device data-sheets and based on the DDR frequency. If data from data-sheets is not available default timing values from the JEDEC spec are used. These will be safe, but not necessarily optimal - API for changing timings during DVFS or at boot-up - Temperature alert configuration and handling of temperature alerts, if any for LPDDR2 devices * temperature alert is based on periodic polling of MR4 mode register in DDR devices automatically performed by hardware * timings are de-rated and brought back to nominal when temperature raises and falls respectively - Cache of calculated register values to avoid re-calculating them The driver will need some minor updates when it is eventually integrated with Dynamic Voltage and Frequency Scaling (DVFS). This can not be done now as DVFS support is not available in the mainline yet. Discussions with Santosh Shilimkar santosh.shilim...@ti.com were immensely helpful in shaping up the interfaces. Vibhore Vardhan vvard...@gmail.com did the initial code snippet for thermal handling. Testing: - The driver is tested on OMAP4430 SDP. - The driver in a slightly adapted form is also tested on OMAP5. - Since mainline kernel doesn't have DVFS support yet, testing was done using a test module. - Temperature alert handling was tested with simulated interrupts and faked temperature values as testing all cases in real-life scenarios is difficult. - Tested the driver as a module Cc: Greg KH g...@kroah.com v5: - Moved the EMIF driver to drivers/memory as per discussion thread [2] v4: - Converted instances of EXPORT_SYMBOL to EXPORT_SYMBOL_GPL - Removed un-necessary #ifndef __ASSEMBLY__' - Minor formatting fix v2: - Fixed a bug found in the implementation of errata i728 workaround - Fixed the value of frequency printed in debugfs - Dropped the hwmod patch as Paul has already posted a a hwmod series [1] that adds hwmod for EMIF - Converted instances of __init to __init_or_module Regards Santosh [1] http://thread.gmane.org/gmane.linux.ports.arm.omap/72855 [2] https://lkml.org/lkml/2012/4/12/173 Aneesh V (7): ddr: add LPDDR2 data from JESD209-2 memory: emif: add register definitions for EMIF memory: emif: add basic infrastructure for EMIF driver memory: emif: handle frequency and voltage change events memory: emif: add interrupt and temperature handling memory: emif: add one-time settings memory: emif: add debugfs entries for emif Documentation/memory-devices/ti-emif.txt | 57 + drivers/Kconfig |4 + drivers/Makefile |3 + drivers/memory/Kconfig | 22 + drivers/memory/Makefile |5 + drivers/memory/emif.c| 1670 ++ drivers/memory/emif.h| 589 +++ include/linux/platform_data/emif_plat.h | 128 +++ include/memory/jedec_ddr.h | 175 lib/Kconfig |8 + lib/Makefile |2 + lib/jedec_ddr_data.c | 135 +++ 12 files changed, 2798 insertions(+), 0 deletions(-) create mode 100644 Documentation/memory-devices/ti-emif.txt create mode 100644 drivers/memory/Kconfig create mode 100644 drivers/memory/Makefile create mode 100644 drivers/memory/emif.c create mode 100644 drivers/memory/emif.h create mode 100644 include/linux/platform_data/emif_plat.h create mode 100644 include/memory/jedec_ddr.h create mode 100644 lib/jedec_ddr_data.c -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 6/7] memory: emif: add one-time settings
From: Aneesh V ane...@ti.com
Add settings that are not dependent on frequency
or any other transient parameters. This includes
- power managment control init
- impedence calibration control
- frequency independent phy configuration registers
- initialization of temperature polling
Signed-off-by: Aneesh V ane...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Reviewed-by: Benoit Cousson b-cous...@ti.com
[santosh.shilim...@ti.com: Moved to drivers/memory from drivers/misc]
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Tested-by: Lokesh Vutla lokeshvu...@ti.com
Cc: Greg KH g...@kroah.com
---
drivers/memory/emif.c | 148 +
1 files changed, 148 insertions(+), 0 deletions(-)
diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c
index a8dcf35..3dfffbb 100644
--- a/drivers/memory/emif.c
+++ b/drivers/memory/emif.c
@@ -78,6 +78,24 @@ static void set_ddr_clk_period(u32 freq)
}
/*
+ * Get bus width used by EMIF. Note that this may be different from the
+ * bus width of the DDR devices used. For instance two 16-bit DDR devices
+ * may be connected to a given CS of EMIF. In this case bus width as far
+ * as EMIF is concerned is 32, where as the DDR bus width is 16 bits.
+ */
+static u32 get_emif_bus_width(struct emif_data *emif)
+{
+ u32 width;
+ void __iomem*base = emif-base;
+
+ width = (readl(base + EMIF_SDRAM_CONFIG) NARROW_MODE_MASK)
+NARROW_MODE_SHIFT;
+ width = width == 0 ? 32 : 16;
+
+ return width;
+}
+
+/*
* Get the CL from SDRAM_CONFIG register
*/
static u32 get_cl(struct emif_data *emif)
@@ -372,6 +390,70 @@ static u32 get_sdram_tim_3_shdw(const struct
lpddr2_timings *timings,
return tim3;
}
+static u32 get_zq_config_reg(const struct lpddr2_addressing *addressing,
+ bool cs1_used, bool cal_resistors_per_cs)
+{
+ u32 zq = 0, val = 0;
+
+ val = EMIF_ZQCS_INTERVAL_US * 1000 / addressing-tREFI_ns;
+ zq |= val ZQ_REFINTERVAL_SHIFT;
+
+ val = DIV_ROUND_UP(T_ZQCL_DEFAULT_NS, T_ZQCS_DEFAULT_NS) - 1;
+ zq |= val ZQ_ZQCL_MULT_SHIFT;
+
+ val = DIV_ROUND_UP(T_ZQINIT_DEFAULT_NS, T_ZQCL_DEFAULT_NS) - 1;
+ zq |= val ZQ_ZQINIT_MULT_SHIFT;
+
+ zq |= ZQ_SFEXITEN_ENABLE ZQ_SFEXITEN_SHIFT;
+
+ if (cal_resistors_per_cs)
+ zq |= ZQ_DUALCALEN_ENABLE ZQ_DUALCALEN_SHIFT;
+ else
+ zq |= ZQ_DUALCALEN_DISABLE ZQ_DUALCALEN_SHIFT;
+
+ zq |= ZQ_CS0EN_MASK; /* CS0 is used for sure */
+
+ val = cs1_used ? 1 : 0;
+ zq |= val ZQ_CS1EN_SHIFT;
+
+ return zq;
+}
+
+static u32 get_temp_alert_config(const struct lpddr2_addressing *addressing,
+ const struct emif_custom_configs *custom_configs, bool cs1_used,
+ u32 sdram_io_width, u32 emif_bus_width)
+{
+ u32 alert = 0, interval, devcnt;
+
+ if (custom_configs (custom_configs-mask
+ EMIF_CUSTOM_CONFIG_TEMP_ALERT_POLL_INTERVAL))
+ interval = custom_configs-temp_alert_poll_interval_ms;
+ else
+ interval = TEMP_ALERT_POLL_INTERVAL_DEFAULT_MS;
+
+ interval *= 100;/* Convert to ns */
+ interval /= addressing-tREFI_ns; /* Convert to refresh cycles */
+ alert |= (interval TA_REFINTERVAL_SHIFT);
+
+ /*
+* sdram_io_width is in 'log2(x) - 1' form. Convert emif_bus_width
+* also to this form and subtract to get TA_DEVCNT, which is
+* in log2(x) form.
+*/
+ emif_bus_width = __fls(emif_bus_width) - 1;
+ devcnt = emif_bus_width - sdram_io_width;
+ alert |= devcnt TA_DEVCNT_SHIFT;
+
+ /* DEVWDT is in 'log2(x) - 3' form */
+ alert |= (sdram_io_width - 2) TA_DEVWDT_SHIFT;
+
+ alert |= 1 TA_SFEXITEN_SHIFT;
+ alert |= 1 TA_CS0EN_SHIFT;
+ alert |= (cs1_used ? 1 : 0) TA_CS1EN_SHIFT;
+
+ return alert;
+}
+
static u32 get_read_idle_ctrl_shdw(u8 volt_ramp)
{
u32 idle = 0, val = 0;
@@ -815,6 +897,71 @@ static int __init_or_module setup_interrupts(struct
emif_data *emif, u32 irq)
}
+static void __init_or_module emif_onetime_settings(struct emif_data *emif)
+{
+ u32 pwr_mgmt_ctrl, zq, temp_alert_cfg;
+ void __iomem*base = emif-base;
+ const struct lpddr2_addressing *addressing;
+ const struct ddr_device_info*device_info;
+
+ device_info = emif-plat_data-device_info;
+ addressing = get_addressing_table(device_info);
+
+ /*
+* Init power management settings
+* We don't know the frequency yet. Use a high frequency
+* value for a conservative timeout setting
+*/
+ pwr_mgmt_ctrl = get_pwr_mgmt_ctrl(10, emif,
+ emif-plat_data-ip_rev);
+ emif-lpmode = (pwr_mgmt_ctrl LP_MODE_MASK) LP_MODE_SHIFT;
[PATCH v5 7/7] memory: emif: add debugfs entries for emif
From: Aneesh V ane...@ti.com
Add debug entries for:
1. calculated registers per frequency
2. last polled value of MR4(temperature level
of LPDDR2 memory)
Signed-off-by: Aneesh V ane...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Reviewed-by: Benoit Cousson b-cous...@ti.com
[santosh.shilim...@ti.com: Moved to drivers/memory from drivers/misc]
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Tested-by: Lokesh Vutla lokeshvu...@ti.com
Cc: Greg KH g...@kroah.com
---
drivers/memory/emif.c | 138 +
1 files changed, 138 insertions(+), 0 deletions(-)
diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c
index 3dfffbb..33a4396 100644
--- a/drivers/memory/emif.c
+++ b/drivers/memory/emif.c
@@ -18,6 +18,7 @@
#include linux/platform_device.h
#include linux/interrupt.h
#include linux/slab.h
+#include linux/debugfs.h
#include linux/seq_file.h
#include linux/module.h
#include linux/list.h
@@ -47,6 +48,7 @@
* frequency change (i.e. corresponding to the
* frequency in effect at the moment)
* @plat_data: Pointer to saved platform data.
+ * @debugfs_root: dentry to the root folder for EMIF in debugfs
*/
struct emif_data {
u8 duplicate;
@@ -60,6 +62,7 @@ struct emif_data {
struct emif_regs*regs_cache[EMIF_MAX_NUM_FREQUENCIES];
struct emif_regs*curr_regs;
struct emif_platform_data *plat_data;
+ struct dentry *debugfs_root;
};
static struct emif_data *emif1;
@@ -68,6 +71,130 @@ static unsigned longirq_state;
static u32 t_ck; /* DDR clock period in ps */
static LIST_HEAD(device_list);
+static void do_emif_regdump_show(struct seq_file *s, struct emif_data *emif,
+ struct emif_regs *regs)
+{
+ u32 type = emif-plat_data-device_info-type;
+ u32 ip_rev = emif-plat_data-ip_rev;
+
+ seq_printf(s, EMIF register cache dump for %dMHz\n,
+ regs-freq/100);
+
+ seq_printf(s, ref_ctrl_shdw\t: 0x%08x\n, regs-ref_ctrl_shdw);
+ seq_printf(s, sdram_tim1_shdw\t: 0x%08x\n, regs-sdram_tim1_shdw);
+ seq_printf(s, sdram_tim2_shdw\t: 0x%08x\n, regs-sdram_tim2_shdw);
+ seq_printf(s, sdram_tim3_shdw\t: 0x%08x\n, regs-sdram_tim3_shdw);
+
+ if (ip_rev == EMIF_4D) {
+ seq_printf(s, read_idle_ctrl_shdw_normal\t: 0x%08x\n,
+ regs-read_idle_ctrl_shdw_normal);
+ seq_printf(s, read_idle_ctrl_shdw_volt_ramp\t: 0x%08x\n,
+ regs-read_idle_ctrl_shdw_volt_ramp);
+ } else if (ip_rev == EMIF_4D5) {
+ seq_printf(s, dll_calib_ctrl_shdw_normal\t: 0x%08x\n,
+ regs-dll_calib_ctrl_shdw_normal);
+ seq_printf(s, dll_calib_ctrl_shdw_volt_ramp\t: 0x%08x\n,
+ regs-dll_calib_ctrl_shdw_volt_ramp);
+ }
+
+ if (type == DDR_TYPE_LPDDR2_S2 || type == DDR_TYPE_LPDDR2_S4) {
+ seq_printf(s, ref_ctrl_shdw_derated\t: 0x%08x\n,
+ regs-ref_ctrl_shdw_derated);
+ seq_printf(s, sdram_tim1_shdw_derated\t: 0x%08x\n,
+ regs-sdram_tim1_shdw_derated);
+ seq_printf(s, sdram_tim3_shdw_derated\t: 0x%08x\n,
+ regs-sdram_tim3_shdw_derated);
+ }
+}
+
+static int emif_regdump_show(struct seq_file *s, void *unused)
+{
+ struct emif_data*emif = s-private;
+ struct emif_regs**regs_cache;
+ int i;
+
+ if (emif-duplicate)
+ regs_cache = emif1-regs_cache;
+ else
+ regs_cache = emif-regs_cache;
+
+ for (i = 0; i EMIF_MAX_NUM_FREQUENCIES regs_cache[i]; i++) {
+ do_emif_regdump_show(s, emif, regs_cache[i]);
+ seq_printf(s, \n);
+ }
+
+ return 0;
+}
+
+static int emif_regdump_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, emif_regdump_show, inode-i_private);
+}
+
+static const struct file_operations emif_regdump_fops = {
+ .open = emif_regdump_open,
+ .read = seq_read,
+ .release= single_release,
+};
+
+static int emif_mr4_show(struct seq_file *s, void *unused)
+{
+ struct emif_data *emif = s-private;
+
+ seq_printf(s, MR4=%d\n, emif-temperature_level);
+ return 0;
+}
+
+static int emif_mr4_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, emif_mr4_show, inode-i_private);
+}
+
+static const struct file_operations emif_mr4_fops = {
+ .open = emif_mr4_open,
+ .read = seq_read,
+ .release= single_release,
+};
+
+static int __init_or_module
[PATCH v5 4/7] memory: emif: handle frequency and voltage change events
From: Aneesh V ane...@ti.com
Change SDRAM timings and other settings as necessary
on voltage and frequency changes. We calculate these
register settings based on data from the device data
sheet and inputs such a frequency, voltage state(stable
or ramping), temperature level etc.
TODO: frequency and voltage change handling needs to
be integrated with clock framework and regulator
framework respectively. This is not done today
due to missing pieces in the kernel.
Signed-off-by: Aneesh V ane...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Reviewed-by: Benoit Cousson b-cous...@ti.com
[santosh.shilim...@ti.com: Moved to drivers/memory from drivers/misc]
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Tested-by: Lokesh Vutla lokeshvu...@ti.com
Cc: Greg KH g...@kroah.com
---
drivers/memory/emif.c | 894 -
drivers/memory/emif.h | 130 +++-
2 files changed, 1020 insertions(+), 4 deletions(-)
diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c
index 7486d7e..bd116eb 100644
--- a/drivers/memory/emif.c
+++ b/drivers/memory/emif.c
@@ -21,6 +21,7 @@
#include linux/seq_file.h
#include linux/module.h
#include linux/list.h
+#include linux/spinlock.h
#include memory/jedec_ddr.h
#include emif.h
@@ -37,20 +38,595 @@
* @node: node in the device list
* @base: base address of memory-mapped IO registers.
* @dev: device pointer.
+ * @addressing table with addressing information from the spec
+ * @regs_cache:An array of 'struct emif_regs' that
stores
+ * calculated register values for different
+ * frequencies, to avoid re-calculating them on
+ * each DVFS transition.
+ * @curr_regs: The set of register values used in the last
+ * frequency change (i.e. corresponding to the
+ * frequency in effect at the moment)
* @plat_data: Pointer to saved platform data.
*/
struct emif_data {
u8 duplicate;
u8 temperature_level;
+ u8 lpmode;
struct list_headnode;
+ unsigned long irq_state;
void __iomem*base;
struct device *dev;
+ const struct lpddr2_addressing *addressing;
+ struct emif_regs*regs_cache[EMIF_MAX_NUM_FREQUENCIES];
+ struct emif_regs*curr_regs;
struct emif_platform_data *plat_data;
};
static struct emif_data *emif1;
+static spinlock_t emif_lock;
+static unsigned long irq_state;
+static u32 t_ck; /* DDR clock period in ps */
static LIST_HEAD(device_list);
+/*
+ * Calculate the period of DDR clock from frequency value
+ */
+static void set_ddr_clk_period(u32 freq)
+{
+ /* Divide 10^12 by frequency to get period in ps */
+ t_ck = (u32)DIV_ROUND_UP_ULL(1ull, freq);
+}
+
+/*
+ * Get the CL from SDRAM_CONFIG register
+ */
+static u32 get_cl(struct emif_data *emif)
+{
+ u32 cl;
+ void __iomem*base = emif-base;
+
+ cl = (readl(base + EMIF_SDRAM_CONFIG) CL_MASK) CL_SHIFT;
+
+ return cl;
+}
+
+static void set_lpmode(struct emif_data *emif, u8 lpmode)
+{
+ u32 temp;
+ void __iomem *base = emif-base;
+
+ temp = readl(base + EMIF_POWER_MANAGEMENT_CONTROL);
+ temp = ~LP_MODE_MASK;
+ temp |= (lpmode LP_MODE_SHIFT);
+ writel(temp, base + EMIF_POWER_MANAGEMENT_CONTROL);
+}
+
+static void do_freq_update(void)
+{
+ struct emif_data *emif;
+
+ /*
+* Workaround for errata i728: Disable LPMODE during FREQ_UPDATE
+*
+* i728 DESCRIPTION:
+* The EMIF automatically puts the SDRAM into self-refresh mode
+* after the EMIF has not performed accesses during
+* EMIF_PWR_MGMT_CTRL[7:4] REG_SR_TIM number of DDR clock cycles
+* and the EMIF_PWR_MGMT_CTRL[10:8] REG_LP_MODE bit field is set
+* to 0x2. If during a small window the following three events
+* occur:
+* - The SR_TIMING counter expires
+* - And frequency change is requested
+* - And OCP access is requested
+* Then it causes instable clock on the DDR interface.
+*
+* WORKAROUND
+* To avoid the occurrence of the three events, the workaround
+* is to disable the self-refresh when requesting a frequency
+* change. Before requesting a frequency change the software must
+* program EMIF_PWR_MGMT_CTRL[10:8] REG_LP_MODE to 0x0. When the
+* frequency change has been done, the software can reprogram
+* EMIF_PWR_MGMT_CTRL[10:8] REG_LP_MODE to 0x2
+*/
+
[PATCH v5 5/7] memory: emif: add interrupt and temperature handling
From: Aneesh V ane...@ti.com
Add an ISR for EMIF that:
1. reports details of access errors
2. takes action on thermal events
Also clear all interrupts on shut-down. Pending IRQs
may casue problems during warm-reset.
Temperature handling:
EMIF can be configured to poll the temperature level
of an LPDDR2 device from the MR4 mode register in the
device. EMIF generates an interrupt whenever it identifies
a temperature level change between two consecutive pollings.
Some of the timing parameters need to be de-rated at high
temperatures. The interrupt handler takes care of doing
this and also takes care of going back to nominal settings
when temperature falls back to nominal levels.
Signed-off-by: Aneesh V ane...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Reviewed-by: Benoit Cousson b-cous...@ti.com
[santosh.shilim...@ti.com: Moved to drivers/memory from drivers/misc]
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Greg KH g...@kroah.com
---
drivers/memory/emif.c | 211 -
1 files changed, 209 insertions(+), 2 deletions(-)
diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c
index bd116eb..a8dcf35 100644
--- a/drivers/memory/emif.c
+++ b/drivers/memory/emif.c
@@ -545,6 +545,42 @@ static u32 get_pwr_mgmt_ctrl(u32 freq, struct emif_data
*emif, u32 ip_rev)
}
/*
+ * Get the temperature level of the EMIF instance:
+ * Reads the MR4 register of attached SDRAM parts to find out the temperature
+ * level. If there are two parts attached(one on each CS), then the temperature
+ * level for the EMIF instance is the higher of the two temperatures.
+ */
+static void get_temperature_level(struct emif_data *emif)
+{
+ u32 temp, temperature_level;
+ void __iomem*base;
+
+ base = emif-base;
+
+ /* Read mode register 4 */
+ writel(DDR_MR4, base + EMIF_LPDDR2_MODE_REG_CONFIG);
+ temperature_level = readl(base + EMIF_LPDDR2_MODE_REG_DATA);
+ temperature_level = (temperature_level MR4_SDRAM_REF_RATE_MASK)
+ MR4_SDRAM_REF_RATE_SHIFT;
+
+ if (emif-plat_data-device_info-cs1_used) {
+ writel(DDR_MR4 | CS_MASK, base + EMIF_LPDDR2_MODE_REG_CONFIG);
+ temp = readl(base + EMIF_LPDDR2_MODE_REG_DATA);
+ temp = (temp MR4_SDRAM_REF_RATE_MASK)
+MR4_SDRAM_REF_RATE_SHIFT;
+ temperature_level = max(temp, temperature_level);
+ }
+
+ /* treat everything less than nominal(3) in MR4 as nominal */
+ if (unlikely(temperature_level SDRAM_TEMP_NOMINAL))
+ temperature_level = SDRAM_TEMP_NOMINAL;
+
+ /* if we get reserved value in MR4 persist with the existing value */
+ if (likely(temperature_level != SDRAM_TEMP_RESERVED_4))
+ emif-temperature_level = temperature_level;
+}
+
+/*
* Program EMIF shadow registers that are not dependent on temperature
* or voltage
*/
@@ -627,6 +663,158 @@ out:
writel(ref_ctrl, base + EMIF_SDRAM_REFRESH_CTRL_SHDW);
}
+static irqreturn_t handle_temp_alert(void __iomem *base, struct emif_data
*emif)
+{
+ u32 old_temp_level;
+ irqreturn_t ret = IRQ_HANDLED;
+
+ spin_lock_irqsave(emif_lock, irq_state);
+ old_temp_level = emif-temperature_level;
+ get_temperature_level(emif);
+
+ if (unlikely(emif-temperature_level == old_temp_level)) {
+ goto out;
+ } else if (!emif-curr_regs) {
+ dev_err(emif-dev, temperature alert before registers are
calculated, not de-rating timings\n);
+ goto out;
+ }
+
+ if (emif-temperature_level old_temp_level ||
+ emif-temperature_level == SDRAM_TEMP_VERY_HIGH_SHUTDOWN) {
+ /*
+* Temperature coming down - defer handling to thread OR
+* Temperature far too high - do kernel_power_off() from
+* thread context
+*/
+ ret = IRQ_WAKE_THREAD;
+ } else {
+ /* Temperature is going up - handle immediately */
+ setup_temperature_sensitive_regs(emif, emif-curr_regs);
+ do_freq_update();
+ }
+
+out:
+ spin_unlock_irqrestore(emif_lock, irq_state);
+ return ret;
+}
+
+static irqreturn_t emif_interrupt_handler(int irq, void *dev_id)
+{
+ u32 interrupts;
+ struct emif_data*emif = dev_id;
+ void __iomem*base = emif-base;
+ struct device *dev = emif-dev;
+ irqreturn_t ret = IRQ_HANDLED;
+
+ /* Save the status and clear it */
+ interrupts = readl(base + EMIF_SYSTEM_OCP_INTERRUPT_STATUS);
+ writel(interrupts, base + EMIF_SYSTEM_OCP_INTERRUPT_STATUS);
+
+ /*
+* Handle temperature alert
+* Temperature alert should be same for all ports
+* So,
[PATCH v5 2/7] memory: emif: add register definitions for EMIF
From: Aneesh V ane...@ti.com Add register offsets and bit field definitions for EMIF module in TI SoCs Signed-off-by: Aneesh V ane...@ti.com Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com Reviewed-by: Benoit Cousson b-cous...@ti.com [santosh.shilim...@ti.com: Moved to drivers/memory from drivers/misc] Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Tested-by: Lokesh Vutla lokeshvu...@ti.com Cc: Greg KH g...@kroah.com --- drivers/memory/emif.h | 454 + 1 files changed, 454 insertions(+), 0 deletions(-) create mode 100644 drivers/memory/emif.h diff --git a/drivers/memory/emif.h b/drivers/memory/emif.h new file mode 100644 index 000..44b97df --- /dev/null +++ b/drivers/memory/emif.h @@ -0,0 +1,454 @@ +/* + * Defines for the EMIF driver + * + * Copyright (C) 2012 Texas Instruments, Inc. + * + * Benoit Cousson (b-cous...@ti.com) + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ +#ifndef __EMIF_H +#define __EMIF_H + +/* Registers offset */ +#define EMIF_MODULE_ID_AND_REVISION0x +#define EMIF_STATUS0x0004 +#define EMIF_SDRAM_CONFIG 0x0008 +#define EMIF_SDRAM_CONFIG_20x000c +#define EMIF_SDRAM_REFRESH_CONTROL 0x0010 +#define EMIF_SDRAM_REFRESH_CTRL_SHDW 0x0014 +#define EMIF_SDRAM_TIMING_10x0018 +#define EMIF_SDRAM_TIMING_1_SHDW 0x001c +#define EMIF_SDRAM_TIMING_20x0020 +#define EMIF_SDRAM_TIMING_2_SHDW 0x0024 +#define EMIF_SDRAM_TIMING_30x0028 +#define EMIF_SDRAM_TIMING_3_SHDW 0x002c +#define EMIF_LPDDR2_NVM_TIMING 0x0030 +#define EMIF_LPDDR2_NVM_TIMING_SHDW0x0034 +#define EMIF_POWER_MANAGEMENT_CONTROL 0x0038 +#define EMIF_POWER_MANAGEMENT_CTRL_SHDW0x003c +#define EMIF_LPDDR2_MODE_REG_DATA 0x0040 +#define EMIF_LPDDR2_MODE_REG_CONFIG0x0050 +#define EMIF_OCP_CONFIG0x0054 +#define EMIF_OCP_CONFIG_VALUE_10x0058 +#define EMIF_OCP_CONFIG_VALUE_20x005c +#define EMIF_IODFT_TEST_LOGIC_GLOBAL_CONTROL 0x0060 +#define EMIF_IODFT_TEST_LOGIC_CTRL_MISR_RESULT 0x0064 +#define EMIF_IODFT_TEST_LOGIC_ADDRESS_MISR_RESULT 0x0068 +#define EMIF_IODFT_TEST_LOGIC_DATA_MISR_RESULT_1 0x006c +#define EMIF_IODFT_TEST_LOGIC_DATA_MISR_RESULT_2 0x0070 +#define EMIF_IODFT_TEST_LOGIC_DATA_MISR_RESULT_3 0x0074 +#define EMIF_PERFORMANCE_COUNTER_1 0x0080 +#define EMIF_PERFORMANCE_COUNTER_2 0x0084 +#define EMIF_PERFORMANCE_COUNTER_CONFIG0x0088 +#define EMIF_PERFORMANCE_COUNTER_MASTER_REGION_SELECT 0x008c +#define EMIF_PERFORMANCE_COUNTER_TIME 0x0090 +#define EMIF_MISC_REG 0x0094 +#define EMIF_DLL_CALIB_CTRL0x0098 +#define EMIF_DLL_CALIB_CTRL_SHDW 0x009c +#define EMIF_END_OF_INTERRUPT 0x00a0 +#define EMIF_SYSTEM_OCP_INTERRUPT_RAW_STATUS 0x00a4 +#define EMIF_LL_OCP_INTERRUPT_RAW_STATUS 0x00a8 +#define EMIF_SYSTEM_OCP_INTERRUPT_STATUS 0x00ac +#define EMIF_LL_OCP_INTERRUPT_STATUS 0x00b0 +#define EMIF_SYSTEM_OCP_INTERRUPT_ENABLE_SET 0x00b4 +#define EMIF_LL_OCP_INTERRUPT_ENABLE_SET 0x00b8 +#define EMIF_SYSTEM_OCP_INTERRUPT_ENABLE_CLEAR 0x00bc +#define EMIF_LL_OCP_INTERRUPT_ENABLE_CLEAR 0x00c0 +#define EMIF_SDRAM_OUTPUT_IMPEDANCE_CALIBRATION_CONFIG 0x00c8 +#define EMIF_TEMPERATURE_ALERT_CONFIG 0x00cc +#define EMIF_OCP_ERROR_LOG 0x00d0 +#define EMIF_READ_WRITE_LEVELING_RAMP_WINDOW 0x00d4 +#define EMIF_READ_WRITE_LEVELING_RAMP_CONTROL 0x00d8 +#define EMIF_READ_WRITE_LEVELING_CONTROL 0x00dc +#define EMIF_DDR_PHY_CTRL_10x00e4 +#define EMIF_DDR_PHY_CTRL_1_SHDW 0x00e8 +#define EMIF_DDR_PHY_CTRL_20x00ec +#define EMIF_PRIORITY_TO_CLASS_OF_SERVICE_MAPPING 0x0100 +#define EMIF_CONNECTION_ID_TO_CLASS_OF_SERVICE_1_MAPPING 0x0104 +#define EMIF_CONNECTION_ID_TO_CLASS_OF_SERVICE_2_MAPPING 0x0108 +#define EMIF_READ_WRITE_EXECUTION_THRESHOLD0x0120 +#define EMIF_COS_CONFIG0x0124 +#define EMIF_PHY_STATUS_1 0x0140 +#define EMIF_PHY_STATUS_2
[PATCH v5 3/7] memory: emif: add basic infrastructure for EMIF driver
From: Aneesh V ane...@ti.com EMIF is an SDRAM controller used in various Texas Instruments SoCs. EMIF supports, based on its revision, one or more of LPDDR2/DDR2/DDR3 protocols. Add the basic infrastructure for EMIF driver that includes driver registration, probe, parsing of platform data etc. Signed-off-by: Aneesh V ane...@ti.com Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com Reviewed-by: Benoit Cousson b-cous...@ti.com [santosh.shilim...@ti.com: Moved to drivers/memory from drivers/misc] Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Tested-by: Lokesh Vutla lokeshvu...@ti.com Cc: Greg KH g...@kroah.com --- Documentation/memory-devices/ti-emif.txt | 57 ++ drivers/Kconfig |4 + drivers/Makefile |3 + drivers/memory/Kconfig | 22 +++ drivers/memory/Makefile |5 + drivers/memory/emif.c| 289 ++ drivers/memory/emif.h|7 + include/linux/platform_data/emif_plat.h | 128 + 8 files changed, 515 insertions(+), 0 deletions(-) create mode 100644 Documentation/memory-devices/ti-emif.txt create mode 100644 drivers/memory/Kconfig create mode 100644 drivers/memory/Makefile create mode 100644 drivers/memory/emif.c create mode 100644 include/linux/platform_data/emif_plat.h diff --git a/Documentation/memory-devices/ti-emif.txt b/Documentation/memory-devices/ti-emif.txt new file mode 100644 index 000..f4ad9a7 --- /dev/null +++ b/Documentation/memory-devices/ti-emif.txt @@ -0,0 +1,57 @@ +TI EMIF SDRAM Controller Driver: + +Author + +Aneesh V ane...@ti.com + +Location + +driver/memory/emif.c + +Supported SoCs: +=== +TI OMAP44xx +TI OMAP54xx + +Menuconfig option: +== +Device Drivers + Memory devices + Texas Instruments EMIF driver + +Description +=== +This driver is for the EMIF module available in Texas Instruments +SoCs. EMIF is an SDRAM controller that, based on its revision, +supports one or more of DDR2, DDR3, and LPDDR2 SDRAM protocols. +This driver takes care of only LPDDR2 memories presently. The +functions of the driver includes re-configuring AC timing +parameters and other settings during frequency, voltage and +temperature changes + +Platform Data (see include/linux/platform_data/emif_plat.h): += +DDR device details and other board dependent and SoC dependent +information can be passed through platform data (struct emif_platform_data) +- DDR device details: 'struct ddr_device_info' +- Device AC timings: 'struct lpddr2_timings' and 'struct lpddr2_min_tck' +- Custom configurations: customizable policy options through + 'struct emif_custom_configs' +- IP revision +- PHY type + +Interface to the external world: + +EMIF driver registers notifiers for voltage and frequency changes +affecting EMIF and takes appropriate actions when these are invoked. +- freq_pre_notify_handling() +- freq_post_notify_handling() +- volt_notify_handling() + +Debugfs + +The driver creates two debugfs entries per device. +- regcache_dump : dump of register values calculated and saved for all + frequencies used so far. +- mr4 : last polled value of MR4 register in the LPDDR2 device. MR4 + indicates the current temperature level of the device. diff --git a/drivers/Kconfig b/drivers/Kconfig index d236aef..b0e0629 100644 --- a/drivers/Kconfig +++ b/drivers/Kconfig @@ -140,4 +140,8 @@ source drivers/virt/Kconfig source drivers/devfreq/Kconfig +# memory + +source drivers/memory/Kconfig + endmenu diff --git a/drivers/Makefile b/drivers/Makefile index 95952c8..9cc81ee 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -134,3 +134,6 @@ obj-$(CONFIG_VIRT_DRIVERS) += virt/ obj-$(CONFIG_HYPERV) += hv/ obj-$(CONFIG_PM_DEVFREQ) += devfreq/ + +# Memory drivers +obj-$(CONFIG_MEMORY) += memory/ diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig new file mode 100644 index 000..b08327c --- /dev/null +++ b/drivers/memory/Kconfig @@ -0,0 +1,22 @@ +# +# Memory devices +# + +menuconfig MEMORY + bool Memory Controller drivers + +if MEMORY + +config TI_EMIF + tristate Texas Instruments EMIF driver + select DDR + help + This driver is for the EMIF module available in Texas Instruments + SoCs. EMIF is an SDRAM controller that, based on its revision, + supports one or more of DDR2, DDR3, and LPDDR2 SDRAM protocols. + This driver takes care of only LPDDR2 memories presently. The + functions of the driver includes re-configuring AC timing + parameters and other settings during frequency, voltage and + temperature changes + +endif diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile new file mode 100644 index
Re: [PATCH v4 0/7] Add TI EMIF SDRAM controller driver
Greg, On Monday 23 April 2012 08:14 PM, Shilimkar, Santosh wrote: On Mon, Apr 23, 2012 at 7:57 PM, Greg KH g...@kroah.com wrote: On Mon, Apr 23, 2012 at 04:34:46PM +0530, Shilimkar, Santosh wrote: Afzal, On Mon, Apr 23, 2012 at 4:26 PM, Mohammed, Afzal af...@ti.com wrote: Hi Aneesh, On Fri, Apr 13, 2012 at 01:28:55, V, Aneesh wrote: Thanks. I will wait for your review then. Once I have your comments I will re-work and submit in the new directory structure proposed. Do you have a plan on submitting EMIF driver in the new proposed (drivers/memory) directory. Or shall I submit GPMC driver by creating the new memory directory. Greg mentioned that he plans to do a review of EMIF driver. We were waiting for his comments before sending the updated series. No, don't wait for me, please resend, I was waiting for you :) Thanks Greg !! Will start working on updating the patch set and post it on list. Have posted the updated version [1] as per discussion on this thread. Regards Santosh [1] http://www.spinics.net/lists/arm-kernel/msg171869.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: OMAP3EVM not booting on l-o master
On Tue, 2012-04-24 at 10:07 -0700, Kevin Hilman wrote: Hi Tero, Tero Kristo t-kri...@ti.com writes: On Fri, 2012-04-06 at 07:52 +, Mohammed, Afzal wrote: Hi Paul, On Fri, Apr 06, 2012 at 12:43:06, Paul Walmsley wrote: Perhaps you might be willing to add some debugging to omap_mux_late_init() to find out what part of that function is causing it to hang? It is getting hung as interrupt handler omap_hwmod_mux_handle_irq is being repeatedly called. Hi Afzal, can you try the attached patch with this branch and omap3evm board? I don't have the board myself so I can't test it myself (I tested this with omap3beagle and it works with that one.) Thanks for digging into this problem and coming up with a proposed solution. Some questions below... -Tero From 26733dd988ccc9e72355a39e01b2d6e9215a892d Mon Sep 17 00:00:00 2001 From: Tero Kristo t-kri...@ti.com Date: Mon, 23 Apr 2012 12:14:46 +0300 Subject: [PATCH] ARM: OMAP3: PM: move wakeup event ack to hwmod_io handler PRCM IO interrupts are handled with a shared interrupt handler logic. Currently hwmod_io is processing the actual event, but the acking of the IO wakeups is done from the PM code with a separate handler. If a wakeup event is detected during init before the PM code is in place, the interrupt handler can hang in an infinite loop. Fix this by removing the pm_io handler, and calling its functionality from within the hwmod_io handler. This fix applies only to OMAP3, as OMAP4 does not have similar wakeup handling logic. Signed-off-by: Tero Kristo t-kri...@ti.com Doesn't this mean that even on a !PM kernel that IO events might still be firing for nothing? I actually disabled the IO handler in !PM kernel, as I thought this would be a problem there. Seems like it would be better to ensure that these interrupts are just disabled until the PM core initializes and can enable them. I thought about this but I couldn't figure out a clean way to do this. If I do irq_request, it automatically enables the interrupt, and if there is an interrupt pending it will fire immediately and get stuck. I can of course do some really nasty hackery for disabling all interrupts when requesting it and then manually disabling it before enabling interrupts again... but this does not look too nice imo. -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Build error: undefined reference to `snd_soc_unregister_codec'
When building ALSA as modules: drivers/built-in.o: In function `omapdss_hdmihw_remove': omap_hwspinlock.c:(.text+0x23da8): undefined reference to `snd_soc_unregister_codec' drivers/built-in.o: In function `omapdss_hdmihw_probe': omap_hwspinlock.c:(.text+0x24248): undefined reference to `snd_soc_register_codec' (the filename is inaccurate). This happens because drivers/video/omap2/dss/hdmi.c is built-in and uses ASoC services, but ASoC and ALSA are modular. -- 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
Audio support on OMAP 3430LDP or 4430SDP boards
Can someone please hint on what audio is supported on these two OMAP boards? From what I can tell, the answer is either nothing or hdmi, both of which are useless to me if someone wants me to convert the OMAP ASoC driver to DMA engine. From what I can see on the 4430SDP, there's a 3.5mm headset jack, microphones and speakers on the board, so the board does have audio hardware. However, it seems (as, I'm afraid to say, seems to be pretty much standard practice with OMAP) there's a total lack of software support in mainline. This kind'a prevents me testing changes to the DMA support for OMAP ASoC... What can be done to remedy this situation? Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/8] gpio/omap: remaining cleanups and fix
Here are the remaining cleanup patches. There are broadly
two categories of cleanups.
Cat-1: Those missed while introducing new feature like SPARSE_IRQ
handling and DT support; use edge/level handlers from
generic IRQ framework.
Cat-2: Removal of redundant fields from struct gpio_bank{} as a
result of they being already covered by members within
context field of struct gpio_bank{}.
Reference: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Commit: 66f75a5d028beaf67c931435fdc3e7823125730c (Linux 3.4-rc4)
Series is available for reference here:
git://gitorious.org/~tarunkanti/omap-sw-develoment/tarunkantis-linux-omap-dev.git
for_3.5/gpio_more_cleanup_fixes
Test info:
OMAP2+ platforms: OMAP2430SDP, OMAP3430SDP, OMAP4430SDP
OMAP1: Bootup test on OMAP1710SDP.
Cc: Kevin Hilman khil...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Cousson, Benoit b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Tarun Kanti DebBarma (8):
gpio/omap: remove virtual_irq_start variable
gpio/omap: remove saved_fallingdetect, saved_risingdetect
gpio/omap: remove suspend_wakeup field from struct gpio_bank
gpio/omap: remove saved_wakeup field from struct gpio_bank
gpio/omap: remove retrigger variable in gpio_irq_handler
gpio/omap: remove suspend/resume callbacks
gpio/omap: remove cpu_is_omap() checks from *_runtime_resume()
gpio/omap: fix missing check in *_runtime_suspend()
arch/arm/mach-omap1/gpio15xx.c |2 -
arch/arm/mach-omap1/gpio16xx.c |5 --
arch/arm/mach-omap1/gpio7xx.c |7 --
arch/arm/mach-omap2/gpio.c |3 +-
arch/arm/plat-omap/include/plat/gpio.h |3 +-
drivers/gpio/gpio-omap.c | 103 +++-
6 files changed, 27 insertions(+), 96 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/8] gpio/omap: fix missing check in *_runtime_suspend()
We do checking for bank-enabled_non_wakeup_gpios in order
to skip redundant operations. Somehow, the check got missed
while doing the cleanup series.
Just to make sure that we do context restore correctly in
*_runtime_resume(), the bank-workaround_enabled check is
moved after context restore. Otherwise, it would prevent
context restore when bank-enabled_non_wakeup_gpios is 0.
Cc: Kevin Hilman khil...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Cousson, Benoit b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
drivers/gpio/gpio-omap.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index d238f84..59a4af1 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1160,6 +1160,9 @@ static int omap_gpio_runtime_suspend(struct device *dev)
spin_lock_irqsave(bank-lock, flags);
+ if (!bank-enabled_non_wakeup_gpios)
+ goto update_gpio_context_count;
+
/*
* Only edges can generate a wakeup event to the PRCM.
*
@@ -1235,11 +1238,6 @@ static int omap_gpio_runtime_resume(struct device *dev)
__raw_writel(bank-context.risingdetect,
bank-base + bank-regs-risingdetect);
- if (!bank-workaround_enabled) {
- spin_unlock_irqrestore(bank-lock, flags);
- return 0;
- }
-
if (bank-get_context_loss_count) {
context_lost_cnt_after =
bank-get_context_loss_count(bank-dev);
@@ -1252,6 +1250,11 @@ static int omap_gpio_runtime_resume(struct device *dev)
}
}
+ if (!bank-workaround_enabled) {
+ spin_unlock_irqrestore(bank-lock, flags);
+ return 0;
+ }
+
__raw_writel(bank-context.fallingdetect,
bank-base + bank-regs-fallingdetect);
__raw_writel(bank-context.risingdetect,
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/8] gpio/omap: remove cpu_is_omapxxxx() checks from *_runtime_resume()
Add register offsets for GPIO_IRQSTATUS_RAW_0, GPIO_IRQSTATUS_RAW_0
which are present on OMAP4+ processors. Now we can distinguish
conditions applicable to OMAP4,5 and those specific to OMAP24xx
and OMAP3xxx.
Cc: Kevin Hilman khil...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Cousson, Benoit b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
arch/arm/mach-omap2/gpio.c |2 ++
arch/arm/plat-omap/include/plat/gpio.h |2 ++
drivers/gpio/gpio-omap.c |4 ++--
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/mach-omap2/gpio.c
index 86f91a6..a144e22 100644
--- a/arch/arm/mach-omap2/gpio.c
+++ b/arch/arm/mach-omap2/gpio.c
@@ -101,6 +101,8 @@ static int __init omap2_gpio_dev_init(struct omap_hwmod
*oh, void *unused)
pdata-regs-dataout = OMAP4_GPIO_DATAOUT;
pdata-regs-set_dataout = OMAP4_GPIO_SETDATAOUT;
pdata-regs-clr_dataout = OMAP4_GPIO_CLEARDATAOUT;
+ pdata-regs-irqstatus_raw0 = OMAP4_GPIO_IRQSTATUSRAW0;
+ pdata-regs-irqstatus_raw1 = OMAP4_GPIO_IRQSTATUSRAW1;
pdata-regs-irqstatus = OMAP4_GPIO_IRQSTATUS0;
pdata-regs-irqstatus2 = OMAP4_GPIO_IRQSTATUS1;
pdata-regs-irqenable = OMAP4_GPIO_IRQSTATUSSET0;
diff --git a/arch/arm/plat-omap/include/plat/gpio.h
b/arch/arm/plat-omap/include/plat/gpio.h
index d903e7d..50fb7cc 100644
--- a/arch/arm/plat-omap/include/plat/gpio.h
+++ b/arch/arm/plat-omap/include/plat/gpio.h
@@ -172,6 +172,8 @@ struct omap_gpio_reg_offs {
u16 clr_dataout;
u16 irqstatus;
u16 irqstatus2;
+ u16 irqstatus_raw0;
+ u16 irqstatus_raw1;
u16 irqenable;
u16 irqenable2;
u16 set_irqenable;
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index ae62c62..d238f84 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1289,14 +1289,14 @@ static int omap_gpio_runtime_resume(struct device *dev)
old0 = __raw_readl(bank-base + bank-regs-leveldetect0);
old1 = __raw_readl(bank-base + bank-regs-leveldetect1);
- if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
+ if (!bank-regs-irqstatus_raw0) {
__raw_writel(old0 | gen, bank-base +
bank-regs-leveldetect0);
__raw_writel(old1 | gen, bank-base +
bank-regs-leveldetect1);
}
- if (cpu_is_omap44xx()) {
+ if (bank-regs-irqstatus_raw0) {
__raw_writel(old0 | l, bank-base +
bank-regs-leveldetect0);
__raw_writel(old1 | l, bank-base +
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/8] gpio/omap: remove suspend/resume callbacks
Both omap_gpio_suspend() and omap_gpio_resume() does programming
of wakeup_en register.
_gpio_rmw(base, bank-regs-wkup_en, 0x, 0);
_gpio_rmw(base, bank-regs-wkup_en, bank-context.wake_en, 1);
This is redundant in omap_gpio_suspend() because wakeup_en
register automatically gets initialized in _set_gpio_wakeup()
and set_gpio_trigger() while being called either from
chip.irq_set_wake() or chip.irq_set_type().
This is also redundant in omap_gpio_resume() because wakeup_en
register is programmed in omap_gpio_restore_context() called
which is called from runtime resume callback.
Cc: Kevin Hilman khil...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Cousson, Benoit b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
drivers/gpio/gpio-omap.c | 47 --
1 files changed, 0 insertions(+), 47 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 7533564..ae62c62 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1147,50 +1147,6 @@ static int __devinit omap_gpio_probe(struct
platform_device *pdev)
#ifdef CONFIG_ARCH_OMAP2PLUS
-#if defined(CONFIG_PM_SLEEP)
-static int omap_gpio_suspend(struct device *dev)
-{
- struct platform_device *pdev = to_platform_device(dev);
- struct gpio_bank *bank = platform_get_drvdata(pdev);
- void __iomem *base = bank-base;
- unsigned long flags;
-
- if (!bank-mod_usage || !bank-loses_context)
- return 0;
-
- if (!bank-regs-wkup_en || !bank-context.wake_en)
- return 0;
-
- spin_lock_irqsave(bank-lock, flags);
- _gpio_rmw(base, bank-regs-wkup_en, 0x, 0);
- _gpio_rmw(base, bank-regs-wkup_en, bank-context.wake_en, 1);
- spin_unlock_irqrestore(bank-lock, flags);
-
- return 0;
-}
-
-static int omap_gpio_resume(struct device *dev)
-{
- struct platform_device *pdev = to_platform_device(dev);
- struct gpio_bank *bank = platform_get_drvdata(pdev);
- void __iomem *base = bank-base;
- unsigned long flags;
-
- if (!bank-mod_usage || !bank-loses_context)
- return 0;
-
- if (!bank-regs-wkup_en || !bank-context.wake_en)
- return 0;
-
- spin_lock_irqsave(bank-lock, flags);
- _gpio_rmw(base, bank-regs-wkup_en, 0x, 0);
- _gpio_rmw(base, bank-regs-wkup_en, bank-context.wake_en, 1);
- spin_unlock_irqrestore(bank-lock, flags);
-
- return 0;
-}
-#endif /* CONFIG_PM_SLEEP */
-
#if defined(CONFIG_PM_RUNTIME)
static void omap_gpio_restore_context(struct gpio_bank *bank);
@@ -1419,14 +1375,11 @@ static void omap_gpio_restore_context(struct gpio_bank
*bank)
}
#endif /* CONFIG_PM_RUNTIME */
#else
-#define omap_gpio_suspend NULL
-#define omap_gpio_resume NULL
#define omap_gpio_runtime_suspend NULL
#define omap_gpio_runtime_resume NULL
#endif
static const struct dev_pm_ops gpio_pm_ops = {
- SET_SYSTEM_SLEEP_PM_OPS(omap_gpio_suspend, omap_gpio_resume)
SET_RUNTIME_PM_OPS(omap_gpio_runtime_suspend, omap_gpio_runtime_resume,
NULL)
};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/8] gpio/omap: remove suspend_wakeup field from struct gpio_bank
Since we already have bank-context.wake_en to keep track
of gpios which are wakeup enabled, there is no need to have
this field any more.
Cc: Kevin Hilman khil...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Cousson, Benoit b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
drivers/gpio/gpio-omap.c | 13 ++---
1 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 1751f89..7b00256 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -57,7 +57,6 @@ struct gpio_bank {
u16 irq;
int irq_base;
struct irq_domain *domain;
- u32 suspend_wakeup;
u32 saved_wakeup;
u32 non_wakeup_gpios;
u32 enabled_non_wakeup_gpios;
@@ -514,11 +513,11 @@ static int _set_gpio_wakeup(struct gpio_bank *bank, int
gpio, int enable)
spin_lock_irqsave(bank-lock, flags);
if (enable)
- bank-suspend_wakeup |= gpio_bit;
+ bank-context.wake_en |= gpio_bit;
else
- bank-suspend_wakeup = ~gpio_bit;
+ bank-context.wake_en = ~gpio_bit;
- __raw_writel(bank-suspend_wakeup, bank-base + bank-regs-wkup_en);
+ __raw_writel(bank-context.wake_en, bank-base + bank-regs-wkup_en);
spin_unlock_irqrestore(bank-lock, flags);
return 0;
@@ -788,7 +787,7 @@ static int omap_mpuio_suspend_noirq(struct device *dev)
spin_lock_irqsave(bank-lock, flags);
bank-saved_wakeup = __raw_readl(mask_reg);
- __raw_writel(0x ~bank-suspend_wakeup, mask_reg);
+ __raw_writel(0x ~bank-context.wake_en, mask_reg);
spin_unlock_irqrestore(bank-lock, flags);
return 0;
@@ -1165,7 +1164,7 @@ static int omap_gpio_suspend(struct device *dev)
if (!bank-mod_usage || !bank-loses_context)
return 0;
- if (!bank-regs-wkup_en || !bank-suspend_wakeup)
+ if (!bank-regs-wkup_en || !bank-context.wake_en)
return 0;
wakeup_enable = bank-base + bank-regs-wkup_en;
@@ -1173,7 +1172,7 @@ static int omap_gpio_suspend(struct device *dev)
spin_lock_irqsave(bank-lock, flags);
bank-saved_wakeup = __raw_readl(wakeup_enable);
_gpio_rmw(base, bank-regs-wkup_en, 0x, 0);
- _gpio_rmw(base, bank-regs-wkup_en, bank-suspend_wakeup, 1);
+ _gpio_rmw(base, bank-regs-wkup_en, bank-context.wake_en, 1);
spin_unlock_irqrestore(bank-lock, flags);
return 0;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/8] gpio/omap: remove retrigger variable in gpio_irq_handler
commit 672e302e3c (ARM: OMAP: use edge/level handlers from generic IRQ framework) removed retrigger support in favor of using generic IRQ framework. This patch cleans up some unused remnants of that removal. Cc: Kevin Hilman khil...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Cousson, Benoit b-cous...@ti.com Cc: Grant Likely grant.lik...@secretlab.ca Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Felipe Balbi ba...@ti.com --- drivers/gpio/gpio-omap.c |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c index cb9f6d9..7533564 100644 --- a/drivers/gpio/gpio-omap.c +++ b/drivers/gpio/gpio-omap.c @@ -636,7 +636,6 @@ static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc) u32 isr; unsigned int gpio_irq, gpio_index; struct gpio_bank *bank; - u32 retrigger = 0; int unmasked = 0; struct irq_chip *chip = irq_desc_get_chip(desc); @@ -673,8 +672,6 @@ static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc) chained_irq_exit(chip, desc); } - isr |= retrigger; - retrigger = 0; if (!isr) break; -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/8] gpio/omap: remove virtual_irq_start variable
This cleanup got missed while implementing following:
25db711 gpio/omap: Fix IRQ handling for SPARSE_IRQ
384ebe1 gpio/omap: Add DT support to GPIO driver
Cc: Kevin Hilman khil...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Cousson, Benoit b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
arch/arm/mach-omap1/gpio15xx.c |2 --
arch/arm/mach-omap1/gpio16xx.c |5 -
arch/arm/mach-omap1/gpio7xx.c |7 ---
arch/arm/mach-omap2/gpio.c |1 -
arch/arm/plat-omap/include/plat/gpio.h |1 -
5 files changed, 0 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap1/gpio15xx.c b/arch/arm/mach-omap1/gpio15xx.c
index 634903e..ebef15e 100644
--- a/arch/arm/mach-omap1/gpio15xx.c
+++ b/arch/arm/mach-omap1/gpio15xx.c
@@ -46,7 +46,6 @@ static struct omap_gpio_reg_offs omap15xx_mpuio_regs = {
};
static struct __initdata omap_gpio_platform_data omap15xx_mpu_gpio_config = {
- .virtual_irq_start = IH_MPUIO_BASE,
.is_mpuio = true,
.bank_width = 16,
.bank_stride= 1,
@@ -89,7 +88,6 @@ static struct omap_gpio_reg_offs omap15xx_gpio_regs = {
};
static struct __initdata omap_gpio_platform_data omap15xx_gpio_config = {
- .virtual_irq_start = IH_GPIO_BASE,
.bank_width = 16,
.regs = omap15xx_gpio_regs,
};
diff --git a/arch/arm/mach-omap1/gpio16xx.c b/arch/arm/mach-omap1/gpio16xx.c
index 1fb3b9a..2a48cd2 100644
--- a/arch/arm/mach-omap1/gpio16xx.c
+++ b/arch/arm/mach-omap1/gpio16xx.c
@@ -52,7 +52,6 @@ static struct omap_gpio_reg_offs omap16xx_mpuio_regs = {
};
static struct __initdata omap_gpio_platform_data omap16xx_mpu_gpio_config = {
- .virtual_irq_start = IH_MPUIO_BASE,
.is_mpuio = true,
.bank_width = 16,
.bank_stride= 1,
@@ -99,7 +98,6 @@ static struct omap_gpio_reg_offs omap16xx_gpio_regs = {
};
static struct __initdata omap_gpio_platform_data omap16xx_gpio1_config = {
- .virtual_irq_start = IH_GPIO_BASE,
.bank_width = 16,
.regs = omap16xx_gpio_regs,
};
@@ -128,7 +126,6 @@ static struct __initdata resource
omap16xx_gpio2_resources[] = {
};
static struct __initdata omap_gpio_platform_data omap16xx_gpio2_config = {
- .virtual_irq_start = IH_GPIO_BASE + 16,
.bank_width = 16,
.regs = omap16xx_gpio_regs,
};
@@ -157,7 +154,6 @@ static struct __initdata resource
omap16xx_gpio3_resources[] = {
};
static struct __initdata omap_gpio_platform_data omap16xx_gpio3_config = {
- .virtual_irq_start = IH_GPIO_BASE + 32,
.bank_width = 16,
.regs = omap16xx_gpio_regs,
};
@@ -186,7 +182,6 @@ static struct __initdata resource
omap16xx_gpio4_resources[] = {
};
static struct __initdata omap_gpio_platform_data omap16xx_gpio4_config = {
- .virtual_irq_start = IH_GPIO_BASE + 48,
.bank_width = 16,
.regs = omap16xx_gpio_regs,
};
diff --git a/arch/arm/mach-omap1/gpio7xx.c b/arch/arm/mach-omap1/gpio7xx.c
index 4771d6b..acf12b7 100644
--- a/arch/arm/mach-omap1/gpio7xx.c
+++ b/arch/arm/mach-omap1/gpio7xx.c
@@ -51,7 +51,6 @@ static struct omap_gpio_reg_offs omap7xx_mpuio_regs = {
};
static struct __initdata omap_gpio_platform_data omap7xx_mpu_gpio_config = {
- .virtual_irq_start = IH_MPUIO_BASE,
.is_mpuio = true,
.bank_width = 16,
.bank_stride= 2,
@@ -93,7 +92,6 @@ static struct omap_gpio_reg_offs omap7xx_gpio_regs = {
};
static struct __initdata omap_gpio_platform_data omap7xx_gpio1_config = {
- .virtual_irq_start = IH_GPIO_BASE,
.bank_width = 32,
.regs = omap7xx_gpio_regs,
};
@@ -122,7 +120,6 @@ static struct __initdata resource omap7xx_gpio2_resources[]
= {
};
static struct __initdata omap_gpio_platform_data omap7xx_gpio2_config = {
- .virtual_irq_start = IH_GPIO_BASE + 32,
.bank_width = 32,
.regs = omap7xx_gpio_regs,
};
@@ -151,7 +148,6 @@ static struct __initdata resource omap7xx_gpio3_resources[]
= {
};
static struct __initdata omap_gpio_platform_data omap7xx_gpio3_config = {
- .virtual_irq_start = IH_GPIO_BASE + 64,
.bank_width = 32,
.regs = omap7xx_gpio_regs,
};
@@ -180,7 +176,6 @@ static struct __initdata resource omap7xx_gpio4_resources[]
= {
};
static struct __initdata omap_gpio_platform_data omap7xx_gpio4_config = {
- .virtual_irq_start = IH_GPIO_BASE + 96,
.bank_width = 32,
.regs =
[PATCH 4/8] gpio/omap: remove saved_wakeup field from struct gpio_bank
There is no more need to have saved_wakeup because bank-context.wake_en
already holds that value. So getting rid of read/write operation associated
with this field.
Cc: Kevin Hilman khil...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Cousson, Benoit b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
drivers/gpio/gpio-omap.c | 12 +++-
1 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 7b00256..cb9f6d9 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -57,7 +57,6 @@ struct gpio_bank {
u16 irq;
int irq_base;
struct irq_domain *domain;
- u32 saved_wakeup;
u32 non_wakeup_gpios;
u32 enabled_non_wakeup_gpios;
struct gpio_regs context;
@@ -786,7 +785,6 @@ static int omap_mpuio_suspend_noirq(struct device *dev)
unsigned long flags;
spin_lock_irqsave(bank-lock, flags);
- bank-saved_wakeup = __raw_readl(mask_reg);
__raw_writel(0x ~bank-context.wake_en, mask_reg);
spin_unlock_irqrestore(bank-lock, flags);
@@ -802,7 +800,7 @@ static int omap_mpuio_resume_noirq(struct device *dev)
unsigned long flags;
spin_lock_irqsave(bank-lock, flags);
- __raw_writel(bank-saved_wakeup, mask_reg);
+ __raw_writel(bank-context.wake_en, mask_reg);
spin_unlock_irqrestore(bank-lock, flags);
return 0;
@@ -1158,7 +1156,6 @@ static int omap_gpio_suspend(struct device *dev)
struct platform_device *pdev = to_platform_device(dev);
struct gpio_bank *bank = platform_get_drvdata(pdev);
void __iomem *base = bank-base;
- void __iomem *wakeup_enable;
unsigned long flags;
if (!bank-mod_usage || !bank-loses_context)
@@ -1167,10 +1164,7 @@ static int omap_gpio_suspend(struct device *dev)
if (!bank-regs-wkup_en || !bank-context.wake_en)
return 0;
- wakeup_enable = bank-base + bank-regs-wkup_en;
-
spin_lock_irqsave(bank-lock, flags);
- bank-saved_wakeup = __raw_readl(wakeup_enable);
_gpio_rmw(base, bank-regs-wkup_en, 0x, 0);
_gpio_rmw(base, bank-regs-wkup_en, bank-context.wake_en, 1);
spin_unlock_irqrestore(bank-lock, flags);
@@ -1188,12 +1182,12 @@ static int omap_gpio_resume(struct device *dev)
if (!bank-mod_usage || !bank-loses_context)
return 0;
- if (!bank-regs-wkup_en || !bank-saved_wakeup)
+ if (!bank-regs-wkup_en || !bank-context.wake_en)
return 0;
spin_lock_irqsave(bank-lock, flags);
_gpio_rmw(base, bank-regs-wkup_en, 0x, 0);
- _gpio_rmw(base, bank-regs-wkup_en, bank-saved_wakeup, 1);
+ _gpio_rmw(base, bank-regs-wkup_en, bank-context.wake_en, 1);
spin_unlock_irqrestore(bank-lock, flags);
return 0;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/8] gpio/omap: remove saved_fallingdetect, saved_risingdetect
Since we already have context.fallingdetect and context.risingdetect
there is no more need to have these additional fields. Also, getting
rid of extra reads associated with them.
Cc: Kevin Hilman khil...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Cousson, Benoit b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
drivers/gpio/gpio-omap.c | 19 ---
1 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 1adc2ec..1751f89 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -63,8 +63,6 @@ struct gpio_bank {
u32 enabled_non_wakeup_gpios;
struct gpio_regs context;
u32 saved_datain;
- u32 saved_fallingdetect;
- u32 saved_risingdetect;
u32 level_mask;
u32 toggle_mask;
spinlock_t lock;
@@ -1247,11 +1245,9 @@ static int omap_gpio_runtime_suspend(struct device *dev)
*/
bank-saved_datain = __raw_readl(bank-base +
bank-regs-datain);
- l1 = __raw_readl(bank-base + bank-regs-fallingdetect);
- l2 = __raw_readl(bank-base + bank-regs-risingdetect);
+ l1 = bank-context.fallingdetect;
+ l2 = bank-context.risingdetect;
- bank-saved_fallingdetect = l1;
- bank-saved_risingdetect = l2;
l1 = ~bank-enabled_non_wakeup_gpios;
l2 = ~bank-enabled_non_wakeup_gpios;
@@ -1310,9 +1306,9 @@ static int omap_gpio_runtime_resume(struct device *dev)
}
}
- __raw_writel(bank-saved_fallingdetect,
+ __raw_writel(bank-context.fallingdetect,
bank-base + bank-regs-fallingdetect);
- __raw_writel(bank-saved_risingdetect,
+ __raw_writel(bank-context.risingdetect,
bank-base + bank-regs-risingdetect);
l = __raw_readl(bank-base + bank-regs-datain);
@@ -1329,14 +1325,15 @@ static int omap_gpio_runtime_resume(struct device *dev)
* No need to generate IRQs for the rising edge for gpio IRQs
* configured with falling edge only; and vice versa.
*/
- gen0 = l bank-saved_fallingdetect;
+ gen0 = l bank-context.fallingdetect;
gen0 = bank-saved_datain;
- gen1 = l bank-saved_risingdetect;
+ gen1 = l bank-context.risingdetect;
gen1 = ~(bank-saved_datain);
/* FIXME: Consider GPIO IRQs with level detections properly! */
- gen = l (~(bank-saved_fallingdetect) ~(bank-saved_risingdetect));
+ gen = l (~(bank-context.fallingdetect)
+~(bank-context.risingdetect));
/* Consider all GPIO IRQs needed to be updated */
gen |= gen0 | gen1;
--
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: Audio support on OMAP 3430LDP or 4430SDP boards
+ Peter and Liam to comment On Fri, Apr 27, 2012 at 7:28 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: Can someone please hint on what audio is supported on these two OMAP boards? From what I can tell, the answer is either nothing or hdmi, both of which are useless to me if someone wants me to convert the OMAP ASoC driver to DMA engine. From what I can see on the 4430SDP, there's a 3.5mm headset jack, microphones and speakers on the board, so the board does have audio hardware. However, it seems (as, I'm afraid to say, seems to be pretty much standard practice with OMAP) there's a total lack of software support in mainline. This kind'a prevents me testing changes to the DMA support for OMAP ASoC... What can be done to remedy this situation? Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Audio support on OMAP 3430LDP or 4430SDP boards
On Fri, 2012-04-27 at 19:45 +0530, Shilimkar, Santosh wrote: + Peter and Liam to comment On Fri, Apr 27, 2012 at 7:28 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: Can someone please hint on what audio is supported on these two OMAP boards? From what I can tell, the answer is either nothing or hdmi, both of which are useless to me if someone wants me to convert the OMAP ASoC driver to DMA engine. From what I can see on the 4430SDP, there's a 3.5mm headset jack, microphones and speakers on the board, so the board does have audio hardware. However, it seems (as, I'm afraid to say, seems to be pretty much standard practice with OMAP) there's a total lack of software support in mainline. This kind'a prevents me testing changes to the DMA support for OMAP ASoC... What can be done to remedy this situation? Peter now has has the final patches for Legacy mode (i.e. without ABE) now upstream in 3.4-rc. Legacy mode gives a direct SDMA - McPDM - twl6040 audio path so would be a good starting point for DMA testing. Regards Liam -- 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: Audio support on OMAP 3430LDP or 4430SDP boards
On Fri, Apr 27, 2012 at 03:56:42PM +0100, Liam Girdwood wrote: On Fri, 2012-04-27 at 19:45 +0530, Shilimkar, Santosh wrote: + Peter and Liam to comment On Fri, Apr 27, 2012 at 7:28 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: Can someone please hint on what audio is supported on these two OMAP boards? From what I can tell, the answer is either nothing or hdmi, both of which are useless to me if someone wants me to convert the OMAP ASoC driver to DMA engine. From what I can see on the 4430SDP, there's a 3.5mm headset jack, microphones and speakers on the board, so the board does have audio hardware. However, it seems (as, I'm afraid to say, seems to be pretty much standard practice with OMAP) there's a total lack of software support in mainline. This kind'a prevents me testing changes to the DMA support for OMAP ASoC... What can be done to remedy this situation? Peter now has has the final patches for Legacy mode (i.e. without ABE) now upstream in 3.4-rc. Legacy mode gives a direct SDMA - McPDM - twl6040 audio path so would be a good starting point for DMA testing. Sorry, what's ABE? Association of Business Executives? Association of Building Engineers? I had noticed that there's sound/soc/omap/snd-soc-omap-abe-twl6040.ko which needs a bunch of other modules, but even this doesn't cause any cards to show up. So, I'm guessing that the real answer to my problem is that there is no functional audio support on any OMAP board I have, and, therefore, I am unable to continue with the work which TI would like me to do. That's great. That's really bloody well great. I'm going to leave this in Santosh's hands to deal with, and arrange to get more complete and functional board support for any board that TI send me into mainline - for example, I _still_ don't have any working video output on the 4430SDP board. Utter crap. In fact, the only things that do work on the 4430SDP are serial and network. At least the 3430LDP has video output on its LCD. When will support for OMAP based platforms become a reasonable reality? When will people stop pissing around with utterly shit incomplete board support? I'm shelving further OMAP work until board support for these targets improves to a state where a reasonable amount of the platform is supported. Until that time I'm not wasting any more of my time trying to work out what I can do to assist OMAP along. -- 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: Build error: undefined reference to `snd_soc_unregister_codec'
Hi Rusell, On 04/27/2012 08:28 AM, Russell King - ARM Linux wrote: When building ALSA as modules: drivers/built-in.o: In function `omapdss_hdmihw_remove': omap_hwspinlock.c:(.text+0x23da8): undefined reference to `snd_soc_unregister_codec' drivers/built-in.o: In function `omapdss_hdmihw_probe': omap_hwspinlock.c:(.text+0x24248): undefined reference to `snd_soc_register_codec' (the filename is inaccurate). This happens because drivers/video/omap2/dss/hdmi.c is built-in and uses ASoC services, but ASoC and ALSA are modular. As you mention, this happens because the ASoC HDMI codec is embeeded in the DSS driver. There is a set of patches currently under discussion to decouple the ASoC HDMI codec from DSS[1]. This will fix the issue. BR, [1]http://www.spinics.net/lists/linux-omap/msg67307.html Ricardo -- 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: Audio support on OMAP 3430LDP or 4430SDP boards
Hi Russell, On Fri, Apr 27, 2012 at 4:58 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: Can someone please hint on what audio is supported on these two OMAP boards? From what I can tell, the answer is either nothing or hdmi, both of which are useless to me if someone wants me to convert the OMAP ASoC driver to DMA engine. From what I can see on the 4430SDP, there's a 3.5mm headset jack, microphones and speakers on the board, so the board does have audio hardware. However, it seems (as, I'm afraid to say, seems to be pretty much standard practice with OMAP) there's a total lack of software support in mainline. 3.4-rc have audio support for SDP4430/Blaze, PandaBoard4430, PandaBoardES (4460). OMAP3 support is there for a long time, not sure about 3430LDP, but the omap3-SDP, BeagleBoards, Nokia n900, Pandora have at least ASoC machine driver. This kind'a prevents me testing changes to the DMA support for OMAP ASoC... The ASoC driver for DMA: sound/soc/omap/omap-pcm.c We also have dma engine support in the ASoC core: sound/soc/soc-dmaengine-pcm.c It provides some level of abstraction for us to use DMA engine with audio. -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Audio support on OMAP 3430LDP or 4430SDP boards
On Fri, Apr 27, 2012 at 06:53:39PM +0300, Ujfalusi, Peter wrote: Hi Russell, On Fri, Apr 27, 2012 at 4:58 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: Can someone please hint on what audio is supported on these two OMAP boards? From what I can tell, the answer is either nothing or hdmi, both of which are useless to me if someone wants me to convert the OMAP ASoC driver to DMA engine. From what I can see on the 4430SDP, there's a 3.5mm headset jack, microphones and speakers on the board, so the board does have audio hardware. However, it seems (as, I'm afraid to say, seems to be pretty much standard practice with OMAP) there's a total lack of software support in mainline. 3.4-rc have audio support for SDP4430/Blaze, PandaBoard4430, PandaBoardES (4460). OMAP3 support is there for a long time, not sure about 3430LDP, but the omap3-SDP, BeagleBoards, Nokia n900, Pandora have at least ASoC machine driver. Right, so the only platform I have out of that (as I said above) is SDP4430. And as I've already said, it does *not* appear to support any audio of any kind: root@omap-4430sdp:~# insmod snd-soc-twl6040.ko root@omap-4430sdp:~# insmod snd-soc-omap.ko root@omap-4430sdp:~# insmod snd-soc-omap-mcpdm.ko root@omap-4430sdp:~# insmod snd-soc-omap-abe-twl6040.ko root@omap-4430sdp:~# cat /proc/asound/cards --- no soundcards --- and that's with HDMI audio via DSS enabled. So, it does *NOT* appear to support any kind of audio. (If it does, software support for it is broken when built as modules.) How do I get audio support working on this platform? -- 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: Audio support on OMAP 3430LDP or 4430SDP boards
On Fri, Apr 27, 2012 at 7:04 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: Right, so the only platform I have out of that (as I said above) is SDP4430. And as I've already said, it does *not* appear to support any audio of any kind: root@omap-4430sdp:~# insmod snd-soc-twl6040.ko root@omap-4430sdp:~# insmod snd-soc-omap.ko root@omap-4430sdp:~# insmod snd-soc-omap-mcpdm.ko root@omap-4430sdp:~# insmod snd-soc-omap-abe-twl6040.ko root@omap-4430sdp:~# cat /proc/asound/cards --- no soundcards --- You need to load the DMIC driver as well: insmod snd-soc-omap-dmic.ko So, it does *NOT* appear to support any kind of audio. (If it does, software support for it is broken when built as modules.) Audio should work as built in and as modules. -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Audio support on OMAP 3430LDP or 4430SDP boards
On Fri, Apr 27, 2012 at 07:32:42PM +0300, Ujfalusi, Peter wrote: On Fri, Apr 27, 2012 at 7:04 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: Right, so the only platform I have out of that (as I said above) is SDP4430. And as I've already said, it does *not* appear to support any audio of any kind: root@omap-4430sdp:~# insmod snd-soc-twl6040.ko root@omap-4430sdp:~# insmod snd-soc-omap.ko root@omap-4430sdp:~# insmod snd-soc-omap-mcpdm.ko root@omap-4430sdp:~# insmod snd-soc-omap-abe-twl6040.ko root@omap-4430sdp:~# cat /proc/asound/cards --- no soundcards --- You need to load the DMIC driver as well: insmod snd-soc-omap-dmic.ko You must be joking... root@omap-4430sdp:~# insmod snd-soc-twl6040.ko root@omap-4430sdp:~# insmod snd-soc-omap.ko root@omap-4430sdp:~# insmod snd-soc-omap-mcpdm.ko root@omap-4430sdp:~# insmod snd-soc-omap-abe-twl6040.ko root@omap-4430sdp:~# insmod snd-soc-omap-dmic.ko root@omap-4430sdp:~# cat /proc/asound/cards --- no soundcards --- And... root@omap-4430sdp:~# rmmod snd_soc_omap_abe_twl6040 root@omap-4430sdp:~# insmod snd-soc-omap-abe-twl6040.ko omap-abe-twl6040 omap-abe-twl6040: ASoC: Failed to create card debugfs directory root@omap-4430sdp:~# cat /sys/kernel/debug/asoc/SDP4430/dapm_pop_time Unable to handle kernel paging request at virtual address bf011e7c pgd = def1c000 [bf011e7c] *pgd=9f511811, *pte=, *ppte= Internal error: Oops: 7 [#1] SMP ARM Modules linked in: snd_soc_omap_abe_twl6040 snd_soc_omap_dmic snd_soc_omap_mcpdm snd_soc_twl6040 snd_soc_omap [last unloaded: snd_soc_omap_abe_twl6040] CPU: 1Not tainted (3.4.0-rc3+ #380) PC is at debugfs_u32_get+0xc/0x20 LR is at simple_attr_read+0x70/0xc4 pc : [c015fda0]lr : [c00d65e0]psr: 6113 sp : df4f3ef8 ip : df4f3f08 fp : df4f3f04 r10: 1000 r9 : df4f2000 r8 : be8b5be0 r7 : df53e440 r6 : df4f3f70 r5 : df53e400 r4 : r3 : r2 : r1 : df4f3f10 r0 : bf011e7c Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 9ef1c04a DAC: 0015 Process cat (pid: 1494, stack limit = 0xdf4f22f0) Stack: (0xdf4f3ef8 to 0xdf4f4000) 3ee0: df4f3f3c df4f3f08 3f00: c00d65e0 c015fda0 0001 df532f08 df4f3f44 df4f3f20 df532f00 1000 3f20: be8b5be0 df4f3f70 1000 df4f3f6c df4f3f40 c00b59a4 c00d657c 3f40: df4f2000 def5e000 df4f3f94 df532f00 be8b5be0 1000 3f60: df4f3fa4 df4f3f70 c00b5af4 c00b58fc be8b6ef1 3f80: c0014068 b6fe7880 0003 be8b5be0 0003 c0014068 df4f3fa8 3fa0: c0013ec0 c00b5abc b6fe7880 0003 0003 be8b5be0 1000 00098728 3fc0: b6fe7880 0003 be8b5be0 0003 0003 be8b5bd4 3fe0: 1000 be8b5bc0 00013140 b6e8da2c 6110 0003 4ddc5d55 75f55179 Backtrace: [c015fd94] (debugfs_u32_get+0x0/0x20) from [c00d65e0] (simple_attr_read+0x70/0xc4) [c00d6570] (simple_attr_read+0x0/0xc4) from [c00b59a4] (vfs_read+0xb4/0x140) [c00b58f0] (vfs_read+0x0/0x140) from [c00b5af4] (sys_read+0x44/0x70) r8:1000 r7:be8b5be0 r6:df532f00 r5: r4: [c00b5ab0] (sys_read+0x0/0x70) from [c0013ec0] (ret_fast_syscall+0x0/0x30) r8:c0014068 r7:0003 r6:be8b5be0 r5:0003 r4:b6fe7880 Code: e89da800 e1a0c00d e92dd800 e24cb004 (e5903000) ---[ end trace ba2e3db072bb311d ]--- Segmentation fault root@omap-4430sdp:~# That seems to be because of an error in the ASoC design. ASoC only tears down the resources after a card has been fully instantiated. If it's been partially instantiated, let's not bother and leave everything registered with all the various subsystems... Sorry, I'm shelving this until someone reports that OMAP has some meaningful working audio support. At the moment, I'm entirely unconvinced that any of this stuff has been tested as working. -- 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: Audio support on OMAP 3430LDP or 4430SDP boards
On Fri, Apr 27, 2012 at 7:50 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: You need to load the DMIC driver as well: insmod snd-soc-omap-dmic.ko You must be joking... Well SDP4430/Blaze have the following setup: twl6040 via McPDM digital microphones via DMIC So I would: root@omap-4430sdp:~# insmod snd-soc-twl6040.ko root@omap-4430sdp:~# insmod snd-soc-omap.ko root@omap-4430sdp:~# insmod snd-soc-omap-mcpdm.ko root@omap-4430sdp:~# insmod snd-soc-omap-dmic.ko root@omap-4430sdp:~# insmod snd-soc-dmic.ko root@omap-4430sdp:~# insmod snd-soc-omap-abe-twl6040.ko Does this works for you? Or make modules_install depmod -a modprobe snd-soc-omap-abe-twl6040 -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Audio support on OMAP 3430LDP or 4430SDP boards
On Fri, Apr 27, 2012 at 08:04:52PM +0300, Ujfalusi, Peter wrote: On Fri, Apr 27, 2012 at 7:50 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: You need to load the DMIC driver as well: insmod snd-soc-omap-dmic.ko You must be joking... Well SDP4430/Blaze have the following setup: twl6040 via McPDM digital microphones via DMIC So I would: root@omap-4430sdp:~# insmod snd-soc-twl6040.ko root@omap-4430sdp:~# insmod snd-soc-omap.ko root@omap-4430sdp:~# insmod snd-soc-omap-mcpdm.ko root@omap-4430sdp:~# insmod snd-soc-omap-dmic.ko root@omap-4430sdp:~# insmod snd-soc-dmic.ko root@omap-4430sdp:~# insmod snd-soc-omap-abe-twl6040.ko Does this works for you? root@omap-4430sdp:~# lsmod Module Size Used by snd_soc_dmic1492 0 snd_soc_omap4_hdmi 1724 0 snd_soc_omap_hdmi 1536 0 snd_soc_omap_abe_twl6040 4867 0 snd_soc_omap_dmic 4248 0 snd_soc_omap_mcpdm 3077 1 snd_soc_omap_abe_twl6040 snd_soc_omap2987 0 snd_soc_twl604018601 1 snd_soc_omap_abe_twl6040 root@omap-4430sdp:~# cat /proc/asound/cards --- no soundcards --- root@omap-4430sdp:~# grep . /sys/kernel/debug/asoc/* /sys/kernel/debug/asoc/codecs:dmic-codec /sys/kernel/debug/asoc/codecs:snd-soc-dummy /sys/kernel/debug/asoc/codecs:omapdss_hdmi /sys/kernel/debug/asoc/dais:dmic-hifi /sys/kernel/debug/asoc/dais:omap-dmic /sys/kernel/debug/asoc/dais:omap-mcpdm /sys/kernel/debug/asoc/dais:snd-soc-dummy-dai /sys/kernel/debug/asoc/dais:hdmi-audio-codec /sys/kernel/debug/asoc/platforms:omap-pcm-audio /sys/kernel/debug/asoc/platforms:snd-soc-dummy So the answer is... no. Or make modules_install depmod -a modprobe snd-soc-omap-abe-twl6040 That's not going to help one bit, as the only two modules that snd-soc-omap-abe-twl6040 depends on are snd-soc-omap-mcpdm and snd-soc-twl6040. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/12] spi: omap2-mcspi: add DMA engine support
On Mon, 23 Apr 2012 17:07:32 +0100, Russell King rmk+ker...@arm.linux.org.uk
wrote:
Add DMA engine support to the OMAP SPI driver. This supplements the
private DMA API implementation contained within this driver, and the
driver can be independently switched at build time between using DMA
engine and the private DMA API for the transmit and receive sides.
Tested-by: Shubhrajyoti shubhrajy...@ti.com
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/spi/spi-omap2-mcspi.c | 184
++---
1 files changed, 152 insertions(+), 32 deletions(-)
This patch and the next one appear to be part of a larger series.
Feel free to take them through whatever tree you need to.
Acked-by: Grant Likely grant.lik...@secretlab.ca (for both)
g.
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index bb9274c..b2461d7 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -20,6 +20,8 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
*/
+#define USE_DMA_ENGINE_RX
+#define USE_DMA_ENGINE_TX
#include linux/kernel.h
#include linux/init.h
@@ -28,6 +30,7 @@
#include linux/device.h
#include linux/delay.h
#include linux/dma-mapping.h
+#include linux/dmaengine.h
#include linux/platform_device.h
#include linux/err.h
#include linux/clk.h
@@ -95,6 +98,8 @@
/* We have 2 DMA channels per CS, one for RX and one for TX */
struct omap2_mcspi_dma {
+ struct dma_chan *dma_tx;
+ struct dma_chan *dma_rx;
int dma_tx_channel;
int dma_rx_channel;
@@ -290,6 +295,30 @@ static int mcspi_wait_for_reg_bit(void __iomem *reg,
unsigned long bit)
return 0;
}
+static void omap2_mcspi_rx_callback(void *data)
+{
+ struct spi_device *spi = data;
+ struct omap2_mcspi *mcspi = spi_master_get_devdata(spi-master);
+ struct omap2_mcspi_dma *mcspi_dma =
mcspi-dma_channels[spi-chip_select];
+
+ complete(mcspi_dma-dma_rx_completion);
+
+ /* We must disable the DMA RX request */
+ omap2_mcspi_set_dma_req(spi, 1, 0);
+}
+
+static void omap2_mcspi_tx_callback(void *data)
+{
+ struct spi_device *spi = data;
+ struct omap2_mcspi *mcspi = spi_master_get_devdata(spi-master);
+ struct omap2_mcspi_dma *mcspi_dma =
mcspi-dma_channels[spi-chip_select];
+
+ complete(mcspi_dma-dma_tx_completion);
+
+ /* We must disable the DMA TX request */
+ omap2_mcspi_set_dma_req(spi, 0, 0);
+}
+
static unsigned
omap2_mcspi_txrx_dma(struct spi_device *spi, struct spi_transfer *xfer)
{
@@ -304,6 +333,9 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct
spi_transfer *xfer)
u8 * rx;
const u8* tx;
void __iomem*chstat_reg;
+ struct dma_slave_config cfg;
+ enum dma_slave_buswidth width;
+ unsigned es;
mcspi = spi_master_get_devdata(spi-master);
mcspi_dma = mcspi-dma_channels[spi-chip_select];
@@ -311,6 +343,71 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct
spi_transfer *xfer)
chstat_reg = cs-base + OMAP2_MCSPI_CHSTAT0;
+ if (cs-word_len = 8) {
+ width = DMA_SLAVE_BUSWIDTH_1_BYTE;
+ es = 1;
+ } else if (cs-word_len = 16) {
+ width = DMA_SLAVE_BUSWIDTH_2_BYTES;
+ es = 2;
+ } else {
+ width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+ es = 4;
+ }
+
+ memset(cfg, 0, sizeof(cfg));
+ cfg.src_addr = cs-phys + OMAP2_MCSPI_RX0;
+ cfg.dst_addr = cs-phys + OMAP2_MCSPI_TX0;
+ cfg.src_addr_width = width;
+ cfg.dst_addr_width = width;
+ cfg.src_maxburst = 1;
+ cfg.dst_maxburst = 1;
+
+ if (xfer-tx_buf mcspi_dma-dma_tx) {
+ struct dma_async_tx_descriptor *tx;
+ struct scatterlist sg;
+
+ dmaengine_slave_config(mcspi_dma-dma_tx, cfg);
+
+ sg_init_table(sg, 1);
+ sg_dma_address(sg) = xfer-tx_dma;
+ sg_dma_len(sg) = xfer-len;
+
+ tx = dmaengine_prep_slave_sg(mcspi_dma-dma_tx, sg, 1,
+ DMA_MEM_TO_DEV, DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+ if (tx) {
+ tx-callback = omap2_mcspi_tx_callback;
+ tx-callback_param = spi;
+ dmaengine_submit(tx);
+ } else {
+ /* FIXME: fall back to PIO? */
+ }
+ }
+
+ if (xfer-rx_buf mcspi_dma-dma_rx) {
+ struct dma_async_tx_descriptor *tx;
+ struct scatterlist sg;
+ size_t len = xfer-len - es;
+
+ dmaengine_slave_config(mcspi_dma-dma_rx, cfg);
+
+ if (l OMAP2_MCSPI_CHCONF_TURBO)
+ len -= es;
+
+ sg_init_table(sg, 1);
+ sg_dma_address(sg) = xfer-rx_dma;
+
Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
On Fri, Apr 27, 2012 at 11:09:10AM +0530, J, KEERTHY wrote: Devfreq and cpufreq are related to dynamic frequency/voltage switching between pre defined Operating Performance Points or the OPPs. Every OPP being a voltage/frequency pair. Smartreflex is a different power management technique. But presumably these things should integrate somehow - for example, should devfreq and cpufreq be providing inputs into what AVS is doing, and if so how? signature.asc Description: Digital signature
Re: Audio support on OMAP 3430LDP or 4430SDP boards
On Fri, Apr 27, 2012 at 8:19 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: root@omap-4430sdp:~# lsmod Module Size Used by snd_soc_dmic 1492 0 snd_soc_omap4_hdmi 1724 0 snd_soc_omap_hdmi 1536 0 snd_soc_omap_abe_twl6040 4867 0 snd_soc_omap_dmic 4248 0 snd_soc_omap_mcpdm 3077 1 snd_soc_omap_abe_twl6040 snd_soc_omap 2987 0 snd_soc_twl6040 18601 1 snd_soc_omap_abe_twl6040 root@omap-4430sdp:~# cat /proc/asound/cards --- no soundcards --- root@omap-4430sdp:~# grep . /sys/kernel/debug/asoc/* /sys/kernel/debug/asoc/codecs:dmic-codec /sys/kernel/debug/asoc/codecs:snd-soc-dummy /sys/kernel/debug/asoc/codecs:omapdss_hdmi the twl6040 codec is missing. /sys/kernel/debug/asoc/dais:dmic-hifi /sys/kernel/debug/asoc/dais:omap-dmic /sys/kernel/debug/asoc/dais:omap-mcpdm /sys/kernel/debug/asoc/dais:snd-soc-dummy-dai /sys/kernel/debug/asoc/dais:hdmi-audio-codec as well the dai for the twl6040. /sys/kernel/debug/asoc/platforms:omap-pcm-audio /sys/kernel/debug/asoc/platforms:snd-soc-dummy So the answer is... no. Hrm. I don't think you can build the twl6040 MFD core driver as a module. Do you have CONFIG_TWL6040_CORE=y ? We have MFD for twl6040 since it provides audio and vibra functionality as well. Can you check if you have this commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=8eaeb9393397be8eb700ab38a69c450975463b77 This is the second patch to separate the twl6040 from twl-core. If you are missing this patch twl6040 will not probe (twl core will not register the audio if we have twl6030). -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Audio support on OMAP 3430LDP or 4430SDP boards
On Fri, Apr 27, 2012 at 09:14:23PM +0300, Ujfalusi, Peter wrote: On Fri, Apr 27, 2012 at 8:19 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: root@omap-4430sdp:~# lsmod Module Size Used by snd_soc_dmic 1492 0 snd_soc_omap4_hdmi 1724 0 snd_soc_omap_hdmi 1536 0 snd_soc_omap_abe_twl6040 4867 0 snd_soc_omap_dmic 4248 0 snd_soc_omap_mcpdm 3077 1 snd_soc_omap_abe_twl6040 snd_soc_omap 2987 0 snd_soc_twl6040 18601 1 snd_soc_omap_abe_twl6040 root@omap-4430sdp:~# cat /proc/asound/cards --- no soundcards --- root@omap-4430sdp:~# grep . /sys/kernel/debug/asoc/* /sys/kernel/debug/asoc/codecs:dmic-codec /sys/kernel/debug/asoc/codecs:snd-soc-dummy /sys/kernel/debug/asoc/codecs:omapdss_hdmi the twl6040 codec is missing. /sys/kernel/debug/asoc/dais:dmic-hifi /sys/kernel/debug/asoc/dais:omap-dmic /sys/kernel/debug/asoc/dais:omap-mcpdm /sys/kernel/debug/asoc/dais:snd-soc-dummy-dai /sys/kernel/debug/asoc/dais:hdmi-audio-codec as well the dai for the twl6040. /sys/kernel/debug/asoc/platforms:omap-pcm-audio /sys/kernel/debug/asoc/platforms:snd-soc-dummy So the answer is... no. Hrm. I don't think you can build the twl6040 MFD core driver as a module. Do you have CONFIG_TWL6040_CORE=y ? We have MFD for twl6040 since it provides audio and vibra functionality as well. CONFIG_TWL6040_CORE=y Can you check if you have this commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=8eaeb9393397be8eb700ab38a69c450975463b77 I don't have that in the branch I'm building because I started the DMA engine work against v3.4-rc3. This is the second patch to separate the twl6040 from twl-core. If you are missing this patch twl6040 will not probe (twl core will not register the audio if we have twl6030). So it sounds like if I rebase stuff forward to -rc4, it should start working? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/12] dmaengine: split out virtual channel DMA support from sa11x0 driver
On Mon, Apr 23, 2012 at 6:04 PM, Russell King rmk+ker...@arm.linux.org.uk wrote: Split the virtual slave channel DMA support from the sa11x0 driver so this code can be shared with other slave DMA engine drivers. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk I really like the direction of this thing. Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- 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 05/12] mmc: omap_hsmmc: add DMA engine support
On Mon, Apr 23, 2012 at 6:05 PM, Russell King
rmk+ker...@arm.linux.org.uk wrote:
Add DMA engine support to the OMAP HSMMC driver. This supplements the
private DMA API implementation contained within this driver, and the
driver can be switched at build time between using DMA engine and the
private DMA API.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
Great,
+#if 1
+ sig = host-dma_line_rx;
+ host-rx_chan = dma_request_channel(mask, omap_dma_filter_fn,
sig);
+ if (!host-rx_chan) {
+ dev_warn(mmc_dev(host-mmc), unable to obtain RX DMA
engine channel %u\n, sig);
+ }
+#endif
+#if 1
+ sig = host-dma_line_tx;
+ host-tx_chan = dma_request_channel(mask, omap_dma_filter_fn,
sig);
+ if (!host-tx_chan) {
+ dev_warn(mmc_dev(host-mmc), unable to obtain TX DMA
engine channel %u\n, sig);
+ }
+#endif
Are these development artifacts?
Apart from that:
Acked-by: Linus Walleij linus.wall...@linaro.org
Yours,
Linus Walleij
--
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 05/12] mmc: omap_hsmmc: add DMA engine support
On Fri, Apr 27, 2012 at 09:00:22PM +0200, Linus Walleij wrote:
On Mon, Apr 23, 2012 at 6:05 PM, Russell King
rmk+ker...@arm.linux.org.uk wrote:
Add DMA engine support to the OMAP HSMMC driver. This supplements the
private DMA API implementation contained within this driver, and the
driver can be switched at build time between using DMA engine and the
private DMA API.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
Great,
+#if 1
+ sig = host-dma_line_rx;
+ host-rx_chan = dma_request_channel(mask,
omap_dma_filter_fn, sig);
+ if (!host-rx_chan) {
+ dev_warn(mmc_dev(host-mmc), unable to obtain RX
DMA engine channel %u\n, sig);
+ }
+#endif
+#if 1
+ sig = host-dma_line_tx;
+ host-tx_chan = dma_request_channel(mask,
omap_dma_filter_fn, sig);
+ if (!host-tx_chan) {
+ dev_warn(mmc_dev(host-mmc), unable to obtain TX
DMA engine channel %u\n, sig);
+ }
+#endif
Are these development artifacts?
Read the commit message. ;)
They're there (and removed by the next patch) so that the driver can
be easily switched between DMA engine and the private DMA API. Simply
change the relevant #if to zero at build time.
I don't think it warrants config symbols or trying to do it via module
params as its just a stepping stone through the process.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] gpio/omap: remaining cleanups and fix
On Fri, 27 Apr 2012 19:43:30 +0530, Tarun Kanti DebBarma tarun.ka...@ti.com
wrote:
Here are the remaining cleanup patches. There are broadly
two categories of cleanups.
Cat-1: Those missed while introducing new feature like SPARSE_IRQ
handling and DT support; use edge/level handlers from
generic IRQ framework.
Cat-2: Removal of redundant fields from struct gpio_bank{} as a
result of they being already covered by members within
context field of struct gpio_bank{}.
Reference:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Commit: 66f75a5d028beaf67c931435fdc3e7823125730c (Linux 3.4-rc4)
Series is available for reference here:
git://gitorious.org/~tarunkanti/omap-sw-develoment/tarunkantis-linux-omap-dev.git
for_3.5/gpio_more_cleanup_fixes
Test info:
OMAP2+ platforms: OMAP2430SDP, OMAP3430SDP, OMAP4430SDP
OMAP1: Bootup test on OMAP1710SDP.
Cc: Kevin Hilman khil...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Cousson, Benoit b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Tarun Kanti DebBarma (8):
gpio/omap: remove virtual_irq_start variable
gpio/omap: remove saved_fallingdetect, saved_risingdetect
gpio/omap: remove suspend_wakeup field from struct gpio_bank
gpio/omap: remove saved_wakeup field from struct gpio_bank
gpio/omap: remove retrigger variable in gpio_irq_handler
gpio/omap: remove suspend/resume callbacks
gpio/omap: remove cpu_is_omap() checks from *_runtime_resume()
gpio/omap: fix missing check in *_runtime_suspend()
The changes look fine to me. Which branch should this series be
merged through? It can either go via arm-soc or my gpio/next branch.
g.
--
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: Audio support on OMAP 3430LDP or 4430SDP boards
Hi Russell, On Fri, Apr 27, 2012 at 9:31 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: Can you check if you have this commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=8eaeb9393397be8eb700ab38a69c450975463b77 I don't have that in the branch I'm building because I started the DMA engine work against v3.4-rc3. This is the second patch to separate the twl6040 from twl-core. If you are missing this patch twl6040 will not probe (twl core will not register the audio if we have twl6030). So it sounds like if I rebase stuff forward to -rc4, it should start working? Yes, it should. Unfortunately the two patch went separately to avoid merge issues. You will need to configure the Headset path to be able to hear the audio. I can send my .aconf if you are interested. -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Audio support on OMAP 3430LDP or 4430SDP boards
On Fri, Apr 27, 2012 at 07:31:16PM +0100, Russell King - ARM Linux wrote: I don't have that in the branch I'm building because I started the DMA engine work against v3.4-rc3. This is the second patch to separate the twl6040 from twl-core. If you are missing this patch twl6040 will not probe (twl core will not register the audio if we have twl6030). So it sounds like if I rebase stuff forward to -rc4, it should start working? Right, so that was the problem. Why not say in the first place that it required -rc4 instead of just saying that it was in v3.4-rc ? It's taken severeal frustrating hours to get to this point... But.. if I repeatedly aplay /dev/zero, I get randomly spat out on the console: omap_hwmod: mcpdm: _wait_target_disable failed If I play a raw PCM audio file with aplay (44.1kHz s16le 2ch), I get several of these from time to time: DMA synchronization event drop occurred with device 66 and the 'noise' from the small loudspeakers is just about recognizable - but is not what I was expecting (it's slow, plus it sounds on those small speakers that it's horribly distorted.) I can't get the headset jack working to be able to play it through a decent sound system, through which I'll be able to actually _hear_ what the corruption is. I've tried fiddling with everything in alsamixer, including turning on the vibras in the hope of some kind of output (at least that does spin the motors.) Timing the playback shows that something is very definitely not right: On the laptop: rmk@rmk-PC:[linux-rmk]:2154 time aplay -f s16_le -c 2 -r 44100 NYG.s16.2.le Playing raw data 'NYG.s16.2.le' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo real4m56.911s user0m0.287s sys 0m0.571s rmk@rmk-PC:[linux-rmk]:2155 md5sum NYG.s16.2.le 291d33b87e8d60556fd461216291889f NYG.s16.2.le On the SDP4430: root@omap-4430sdp:~# time aplay -f s16_le -c 2 -r 44100 NYG.s16.2.le Playing raw data 'NYG.s16.2.le' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo real5m 53.67s user0m 3.17s sys 0m 0.29s root@omap-4430sdp:~# md5sum NYG.s16.2.le 291d33b87e8d60556fd461216291889f NYG.s16.2.le I notice that aplay is having to upconvert the audio to 96kHz 32 bit, so that could be an ALSA library problem. Any ideas? -- 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/6] ARM: OMAP2+: hwmod: use init-time function ptrs for enable/disable module
The enable/disable module functions are specific to SoCs with
OMAP4-class PRCM. Rather than use cpu_is* checks at runtime inside
the enable/disable module functions, use cpu_is at init time to
initialize function pointers only for SoCs that need them.
NOTE: the cpu_is* check for _enable_module was different than
the one for _disable_module, and this patch uses
cpu_is_omap44xx() for both.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 22 +++---
arch/arm/plat-omap/include/plat/omap_hwmod.h |3 +++
2 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 939032a..a978350 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -779,10 +779,6 @@ static void _disable_optional_clocks(struct omap_hwmod *oh)
*/
static void _omap4_enable_module(struct omap_hwmod *oh)
{
- /* The module mode does not exist prior OMAP4 */
- if (cpu_is_omap24xx() || cpu_is_omap34xx())
- return;
-
if (!oh-clkdm || !oh-prcm.omap4.modulemode)
return;
@@ -1571,10 +1567,6 @@ static int _omap4_disable_module(struct omap_hwmod *oh)
{
int v;
- /* The module mode does not exist prior OMAP4 */
- if (!cpu_is_omap44xx())
- return -EINVAL;
-
if (!oh-clkdm || !oh-prcm.omap4.modulemode)
return -EINVAL;
@@ -1814,7 +1806,8 @@ static int _enable(struct omap_hwmod *oh)
}
_enable_clocks(oh);
- _omap4_enable_module(oh);
+ if (oh-enable_module)
+ oh-enable_module(oh);
r = _wait_target_ready(oh);
if (!r) {
@@ -1870,7 +1863,8 @@ static int _idle(struct omap_hwmod *oh)
_idle_sysc(oh);
_del_initiator_dep(oh, mpu_oh);
- _omap4_disable_module(oh);
+ if (oh-disable_module)
+ oh-disable_module(oh);
/*
* The module must be in idle mode before disabling any parents
@@ -1975,7 +1969,8 @@ static int _shutdown(struct omap_hwmod *oh)
if (oh-_state == _HWMOD_STATE_ENABLED) {
_del_initiator_dep(oh, mpu_oh);
/* XXX what about the other system initiators here? dma, dsp */
- _omap4_disable_module(oh);
+ if (oh-disable_module)
+ oh-disable_module(oh);
_disable_clocks(oh);
if (oh-clkdm)
clkdm_hwmod_disable(oh-clkdm, oh);
@@ -2063,6 +2058,11 @@ static int __init _init(struct omap_hwmod *oh, void
*data)
return -EINVAL;
}
+ if (cpu_is_omap44xx()) {
+ oh-enable_module = _omap4_enable_module;
+ oh-disable_module = _omap4_disable_module;
+ }
+
oh-_state = _HWMOD_STATE_INITIALIZED;
return 0;
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 14dde32..0dbe8cf 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -564,6 +564,9 @@ struct omap_hwmod {
u8 _int_flags;
u8 _state;
u8 _postsetup_state;
+
+ void (*enable_module)(struct omap_hwmod *oh);
+ int (*disable_module)(struct omap_hwmod *oh);
};
struct omap_hwmod *omap_hwmod_lookup(const char *name);
--
1.7.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/6] ARM: OMAP: hwmod: remove runtime cpu_is checking
This series attempts to remove all the runtime cpu_is* checking in omap_hwmod.c in favor of using function pointers initialized at init time. This series was motivated by the addition of support for the AM335x series which was done by adding several more cpu_is* checks, and provided the proverbial straw that broke the camel's back. In addition to the cleanup, this provides a much cleaner way of adding additional SoC support since it no longer requires adding additional runtime cpu_is* checks. Boot tested on OMAP3530/Overo and OMAP4430/Panda. Kevin Hilman (6): ARM: OMAP4: hwmod: rename _enable_module to _omap4_enable_module() ARM: OMAP2+: hwmod: use init-time function ptrs for enable/disable module ARM: OMAP4: hwmod: drop extra cpu_is check from _wait_target_disable() ARM: OMAP2+: hwmod: use init-time function pointer for wait_target_ready ARM: OMAP2+: hwmod: use init-time function pointer for hardreset ARM: OMAP2+: hwmod: use init-time function pointer for _init_clkdm arch/arm/mach-omap2/omap_hwmod.c | 192 +++--- arch/arm/plat-omap/include/plat/omap_hwmod.h | 11 ++ 2 files changed, 126 insertions(+), 77 deletions(-) -- 1.7.9.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] ARM: OMAP2+: hwmod: use init-time function pointer for wait_target_ready
Rather than using cpu_is* checking at runtime, initialize an SoC specific
function pointer for wait_target_ready().
While here, downgrade the BUG() to a WARN_ON() so it gives a noisy
warning instead of causing a kernel panic.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 43 --
arch/arm/plat-omap/include/plat/omap_hwmod.h |1 +
2 files changed, 27 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 3641b0a..6dd454d 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1341,6 +1341,24 @@ static int _init_clocks(struct omap_hwmod *oh, void
*data)
return ret;
}
+static int omap2_wait_module_ready(struct omap_hwmod *oh)
+{
+ return omap2_cm_wait_module_ready(oh-prcm.omap2.module_offs,
+ oh-prcm.omap2.idlest_reg_id,
+ oh-prcm.omap2.idlest_idle_bit);
+}
+
+static int omap4_wait_module_ready(struct omap_hwmod *oh)
+{
+ if (!oh-clkdm)
+ return -EINVAL;
+
+ return omap4_cminst_wait_module_ready(oh-clkdm-prcm_partition,
+ oh-clkdm-cm_inst,
+ oh-clkdm-clkdm_offs,
+ oh-prcm.omap4.clkctrl_offs);
+}
+
/**
* _wait_target_ready - wait for a module to leave slave idle
* @oh: struct omap_hwmod *
@@ -1353,7 +1371,7 @@ static int _init_clocks(struct omap_hwmod *oh, void *data)
static int _wait_target_ready(struct omap_hwmod *oh)
{
struct omap_hwmod_ocp_if *os;
- int ret;
+ int ret = -EINVAL;
if (!oh)
return -EINVAL;
@@ -1369,21 +1387,9 @@ static int _wait_target_ready(struct omap_hwmod *oh)
/* XXX check clock enable states */
- if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
- ret = omap2_cm_wait_module_ready(oh-prcm.omap2.module_offs,
-oh-prcm.omap2.idlest_reg_id,
-
oh-prcm.omap2.idlest_idle_bit);
- } else if (cpu_is_omap44xx()) {
- if (!oh-clkdm)
- return -EINVAL;
-
- ret = omap4_cminst_wait_module_ready(oh-clkdm-prcm_partition,
-oh-clkdm-cm_inst,
-oh-clkdm-clkdm_offs,
-
oh-prcm.omap4.clkctrl_offs);
- } else {
- BUG();
- };
+ WARN_ON(!oh-wait_module_ready);
+ if (oh-wait_module_ready)
+ ret = oh-wait_module_ready(oh);
return ret;
}
@@ -2055,9 +2061,12 @@ static int __init _init(struct omap_hwmod *oh, void
*data)
return -EINVAL;
}
- if (cpu_is_omap44xx()) {
+ if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
+ oh-wait_module_ready = omap2_wait_module_ready;
+ } else if (cpu_is_omap44xx()) {
oh-enable_module = _omap4_enable_module;
oh-disable_module = _omap4_disable_module;
+ oh-wait_module_ready = omap4_wait_module_ready;
}
oh-_state = _HWMOD_STATE_INITIALIZED;
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 0dbe8cf..329ede5 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -567,6 +567,7 @@ struct omap_hwmod {
void (*enable_module)(struct omap_hwmod *oh);
int (*disable_module)(struct omap_hwmod *oh);
+ int (*wait_module_ready)(struct omap_hwmod *oh);
};
struct omap_hwmod *omap_hwmod_lookup(const char *name);
--
1.7.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] ARM: OMAP4: hwmod: rename _enable_module to _omap4_enable_module()
_enable_module is specific to OMAP4-class SoCs, so rename it to
be consistend with the corresponding _omap4_disable_module.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index bf86f7e..939032a 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -771,13 +771,13 @@ static void _disable_optional_clocks(struct omap_hwmod
*oh)
}
/**
- * _enable_module - enable CLKCTRL modulemode on OMAP4
+ * _omap4_enable_module - enable CLKCTRL modulemode on OMAP4
* @oh: struct omap_hwmod *
*
* Enables the PRCM module mode related to the hwmod @oh.
* No return value.
*/
-static void _enable_module(struct omap_hwmod *oh)
+static void _omap4_enable_module(struct omap_hwmod *oh)
{
/* The module mode does not exist prior OMAP4 */
if (cpu_is_omap24xx() || cpu_is_omap34xx())
@@ -786,8 +786,8 @@ static void _enable_module(struct omap_hwmod *oh)
if (!oh-clkdm || !oh-prcm.omap4.modulemode)
return;
- pr_debug(omap_hwmod: %s: _enable_module: %d\n,
-oh-name, oh-prcm.omap4.modulemode);
+ pr_debug(omap_hwmod: %s: %s: %d\n,
+oh-name, __func__, oh-prcm.omap4.modulemode);
omap4_cminst_module_enable(oh-prcm.omap4.modulemode,
oh-clkdm-prcm_partition,
@@ -1814,7 +1814,7 @@ static int _enable(struct omap_hwmod *oh)
}
_enable_clocks(oh);
- _enable_module(oh);
+ _omap4_enable_module(oh);
r = _wait_target_ready(oh);
if (!r) {
--
1.7.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/6] ARM: OMAP2+: hwmod: use init-time function pointer for hardreset
Rather than using cpu_is* checking at runtime, initialize SoC specific
function pointers for the various hard reset functions at init time.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 111 +-
arch/arm/plat-omap/include/plat/omap_hwmod.h |6 ++
2 files changed, 78 insertions(+), 39 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 6dd454d..6b08f19 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1424,6 +1424,59 @@ static u8 _lookup_hardreset(struct omap_hwmod *oh, const
char *name,
return -ENOENT;
}
+static int omap2_assert_hardreset(struct omap_hwmod *oh,
+ struct omap_hwmod_rst_info *ohri)
+{
+ return omap2_prm_assert_hardreset(oh-prcm.omap2.module_offs,
+ ohri-rst_shift);
+}
+
+static int omap2_deassert_hardreset(struct omap_hwmod *oh,
+ struct omap_hwmod_rst_info *ohri)
+{
+ return omap2_prm_deassert_hardreset(oh-prcm.omap2.module_offs,
+ ohri-rst_shift,
+ ohri-st_shift);
+}
+
+static int omap2_is_hardreset_asserted(struct omap_hwmod *oh,
+ struct omap_hwmod_rst_info *ohri)
+{
+ return omap2_prm_is_hardreset_asserted(oh-prcm.omap2.module_offs,
+ ohri-st_shift);
+}
+
+static int omap4_assert_hardreset(struct omap_hwmod *oh,
+ struct omap_hwmod_rst_info *ohri)
+
+{
+ return omap4_prminst_assert_hardreset(ohri-rst_shift,
+ oh-clkdm-pwrdm.ptr-prcm_partition,
+ oh-clkdm-pwrdm.ptr-prcm_offs,
+ oh-prcm.omap4.rstctrl_offs);
+}
+
+static int omap4_deassert_hardreset(struct omap_hwmod *oh,
+ struct omap_hwmod_rst_info *ohri)
+{
+ if (ohri-st_shift)
+ pr_err(omap_hwmod: %s: %s: hwmod data error: OMAP4 does not
support st_shift\n,
+ oh-name, ohri-name);
+ return omap4_prminst_deassert_hardreset(ohri-rst_shift,
+ oh-clkdm-pwrdm.ptr-prcm_partition,
+ oh-clkdm-pwrdm.ptr-prcm_offs,
+ oh-prcm.omap4.rstctrl_offs);
+}
+
+static int omap4_is_hardreset_asserted(struct omap_hwmod *oh,
+ struct omap_hwmod_rst_info *ohri)
+{
+ return omap4_prminst_is_hardreset_asserted(ohri-rst_shift,
+ oh-clkdm-pwrdm.ptr-prcm_partition,
+ oh-clkdm-pwrdm.ptr-prcm_offs,
+ oh-prcm.omap4.rstctrl_offs);
+}
+
/**
* _assert_hardreset - assert the HW reset line of submodules
* contained in the hwmod module.
@@ -1437,7 +1490,7 @@ static u8 _lookup_hardreset(struct omap_hwmod *oh, const
char *name,
static int _assert_hardreset(struct omap_hwmod *oh, const char *name)
{
struct omap_hwmod_rst_info ohri;
- u8 ret;
+ u8 ret = -EINVAL;
if (!oh)
return -EINVAL;
@@ -1446,16 +1499,10 @@ static int _assert_hardreset(struct omap_hwmod *oh,
const char *name)
if (IS_ERR_VALUE(ret))
return ret;
- if (cpu_is_omap24xx() || cpu_is_omap34xx())
- return omap2_prm_assert_hardreset(oh-prcm.omap2.module_offs,
- ohri.rst_shift);
- else if (cpu_is_omap44xx())
- return omap4_prminst_assert_hardreset(ohri.rst_shift,
- oh-clkdm-pwrdm.ptr-prcm_partition,
- oh-clkdm-pwrdm.ptr-prcm_offs,
- oh-prcm.omap4.rstctrl_offs);
- else
- return -EINVAL;
+ if (oh-assert_hardreset)
+ ret = oh-assert_hardreset(oh, ohri);
+
+ return ret;
}
/**
@@ -1471,7 +1518,7 @@ static int _assert_hardreset(struct omap_hwmod *oh, const
char *name)
static int _deassert_hardreset(struct omap_hwmod *oh, const char *name)
{
struct omap_hwmod_rst_info ohri;
- int ret;
+ int ret = -EINVAL;
if (!oh)
return -EINVAL;
@@ -1480,21 +1527,8 @@ static int _deassert_hardreset(struct omap_hwmod *oh,
const char *name)
if (IS_ERR_VALUE(ret))
return ret;
- if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
- ret = omap2_prm_deassert_hardreset(oh-prcm.omap2.module_offs,
- ohri.rst_shift,
- ohri.st_shift);
- } else if (cpu_is_omap44xx()) {
- if (ohri.st_shift)
- pr_err(omap_hwmod: %s: %s: hwmod data
[PATCH 6/6] ARM: OMAP2+: hwmod: use init-time function pointer for _init_clkdm
Rather than use runtime cpu_is* checking inside _init_clkdm, initialize
SoC specific function pointer at init time.
Note that initializing the function pointer oh-init_clkdm pointer
must be done before _init_clocks() is called because it is used there.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 19 +--
arch/arm/plat-omap/include/plat/omap_hwmod.h |1 +
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 6b08f19..e7d95e6 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1288,9 +1288,6 @@ static struct omap_hwmod *_lookup(const char *name)
*/
static int _init_clkdm(struct omap_hwmod *oh)
{
- if (cpu_is_omap24xx() || cpu_is_omap34xx())
- return 0;
-
if (!oh-clkdm_name) {
pr_warning(omap_hwmod: %s: no clkdm_name\n, oh-name);
return -EINVAL;
@@ -1331,7 +1328,8 @@ static int _init_clocks(struct omap_hwmod *oh, void *data)
ret |= _init_main_clk(oh);
ret |= _init_interface_clks(oh);
ret |= _init_opt_clks(oh);
- ret |= _init_clkdm(oh);
+ if (oh-init_clkdm)
+ ret |= oh-init_clkdm(oh);
if (!ret)
oh-_state = _HWMOD_STATE_CLKS_INITED;
@@ -2082,12 +2080,6 @@ static int __init _init(struct omap_hwmod *oh, void
*data)
_init_mpu_rt_base(oh, NULL);
- r = _init_clocks(oh, NULL);
- if (IS_ERR_VALUE(r)) {
- WARN(1, omap_hwmod: %s: couldn't init clocks\n, oh-name);
- return -EINVAL;
- }
-
if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
oh-wait_module_ready = omap2_wait_module_ready;
oh-assert_hardreset = omap2_assert_hardreset;
@@ -2100,6 +2092,13 @@ static int __init _init(struct omap_hwmod *oh, void
*data)
oh-assert_hardreset = omap4_assert_hardreset;
oh-deassert_hardreset = omap4_deassert_hardreset;
oh-is_hardreset_asserted = omap4_is_hardreset_asserted;
+ oh-init_clkdm = _init_clkdm;
+ }
+
+ r = _init_clocks(oh, NULL);
+ if (IS_ERR_VALUE(r)) {
+ WARN(1, omap_hwmod: %s: couldn't init clocks\n, oh-name);
+ return -EINVAL;
}
oh-_state = _HWMOD_STATE_INITIALIZED;
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 4f512b6..6c10e08 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -574,6 +574,7 @@ struct omap_hwmod {
struct omap_hwmod_rst_info *ohri);
int (*is_hardreset_asserted)(struct omap_hwmod *oh,
struct omap_hwmod_rst_info *ohri);
+ int (*init_clkdm)(struct omap_hwmod *oh);
};
struct omap_hwmod *omap_hwmod_lookup(const char *name);
--
1.7.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] ARM: OMAP4: hwmod: drop extra cpu_is check from _wait_target_disable()
_omap4_wait_target_disable() is called only from inside _omap4_disable_module()
which is already protected by SoC specific checks. Remove the cpu_is check
here.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index a978350..3641b0a 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -803,9 +803,6 @@ static void _omap4_enable_module(struct omap_hwmod *oh)
*/
static int _omap4_wait_target_disable(struct omap_hwmod *oh)
{
- if (!cpu_is_omap44xx())
- return 0;
-
if (!oh)
return -EINVAL;
--
1.7.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFT 3/3] ARM: OMAP3: PM: cleanup cam_pwrdm leftovers
Tero Kristo t-kri...@ti.com writes:
Looks good to me, acked.
Thanks.
Kevin
On Tue, 2012-04-24 at 07:23 -0700, Kevin Hilman wrote:
commit e7410cf7 (02fdb03e69699f26e1370d0e51593dbc8a4e5265) moved
mangement of cam_pwrdm to CPUidle but left some remnants behind,
namely the call to clkcm_allo_idle() for the clockdomains in the MPU
pwrdm. Remove these since they are not necessary and cause unwanted
latency in the idle path.
Cc: Tero Kristo Tero Kristo t-kri...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/pm34xx.c |4
1 file changed, 4 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 74a7f8c..66ff828 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -70,7 +70,6 @@ void (*omap3_do_wfi_sram)(void);
static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
static struct powerdomain *core_pwrdm, *per_pwrdm;
-static struct powerdomain *cam_pwrdm;
static void omap3_enable_io_chain(void)
{
@@ -395,8 +394,6 @@ void omap_sram_idle(void)
if (mpu_next_state PWRDM_POWER_ON)
pwrdm_post_transition(mpu_pwrdm);
-
-clkdm_allow_idle(mpu_pwrdm-pwrdm_clkdms[0]);
}
static void omap3_pm_idle(void)
@@ -759,7 +756,6 @@ static int __init omap3_pm_init(void)
neon_pwrdm = pwrdm_lookup(neon_pwrdm);
per_pwrdm = pwrdm_lookup(per_pwrdm);
core_pwrdm = pwrdm_lookup(core_pwrdm);
-cam_pwrdm = pwrdm_lookup(cam_pwrdm);
neon_clkdm = clkdm_lookup(neon_clkdm);
mpu_clkdm = clkdm_lookup(mpu_clkdm);
--
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 12/12] Add removal of old OMAP private DMA implementation to feature removal
On Mon, Apr 23, 2012 at 6:08 PM, Russell King rmk+ker...@arm.linux.org.uk wrote: Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- Documentation/feature-removal-schedule.txt | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-) Your effort on this is much appreciated. Acked-by: Linus Walleij linus.wall...@linaro.org Thanks, Linus Walleij -- 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 05/12] mmc: omap_hsmmc: add DMA engine support
On Fri, Apr 27, 2012 at 9:03 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Fri, Apr 27, 2012 at 09:00:22PM +0200, Linus Walleij wrote: Are these development artifacts? Read the commit message. ;) They're there (and removed by the next patch) so that the driver can be easily switched between DMA engine and the private DMA API. Simply change the relevant #if to zero at build time. Yeah I saw now when reading through the series... The whole thing looks very good, since I'm not that into OMAP stuff I'm trying now to glance over the dmaengine semantics part that I understand a bit atleast. Thanks, Linus Walleij -- 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/8] dmaengine: amba-pl08x: ensure physical channels are properly held
On Wed, Apr 18, 2012 at 12:19 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: Oops, this patch wasn't supposed to be part of this set... ...however it gives me the impression that you have a patch set cooking to also switch PL08x over to the virtual channel mechanism which is really appetizing to see :-) Yours, Linus Walleij -- 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 4/4] ARM: OMAP3+: am33xx: Add powerdomain PRM support
Kevin Hilman khil...@ti.com writes: [...] I also don't like all the cpu_is* checking currently in omap_hwmod.c (which is here before you added this) and have an idea on how to clean it up, I should have a patch by tomorrow for this. That should help adding am33xx support here without needing all the cpu_is* checking. Series just posted: http://marc.info/?l=linux-omapm=133555727831379w=2 Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
Hi Mark, Mark Brown broo...@opensource.wolfsonmicro.com writes: On Fri, Apr 27, 2012 at 11:09:10AM +0530, J, KEERTHY wrote: Devfreq and cpufreq are related to dynamic frequency/voltage switching between pre defined Operating Performance Points or the OPPs. Every OPP being a voltage/frequency pair. Smartreflex is a different power management technique. But presumably these things should integrate somehow - for example, should devfreq and cpufreq be providing inputs into what AVS is doing, and if so how? The way it is currently designed, cpufreq/devfreq/regulator layers don't need to know about AVS. The higher-level layers only know about the nominal voltage. AVS hardware does automatic, adaptive, micro-adjustments around that nominal voltage, and these micro-adjustments are managed by the AVS hardware sending commands to the PMIC. (specifically, on OMAP, the AVS sensors provide inputs to the voltage processor (VP) which provide inputs to the voltage controller (VC) which sends commands to the PMIC[1].) The driver proposed here is primarily for initializing the various parameters/sensitivity/etc. of the AVS hardware, but the actual voltage adjustments are done in hardware by VC/VP. The only thing the higher-level layers might potentially need to do to enable/disable AVS around transitions (e.g. when changing OPP, AVS is disabled before changing OPP and only re-enabled when the new nominal voltage has been acheived.) On OMAP, we handle this inside the OMAP-specific voltage layer which is called by the regulator framework, so even the regulators do not need any knowledge of AVS. Kevin [1] Figure 3-76 in OMAP4430 ES2.1 Public TRM vAD provides a detailed diagram: http://www.ti.com/pdfs/wtbu/OMAP4430_ES2.x_PUBLIC_TRM_vAD.zip -- 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 05/12] arm: omap3: am35x: Add PWROFF feature
Mark A. Greer mgr...@animalcreek.com writes:
On Wed, Apr 11, 2012 at 03:46:20PM -0700, Kevin Hilman wrote:
Hi Mark,
Hi Kevin.
Mark A. Greer mgr...@animalcreek.com writes:
From: Mark A. Greer mgr...@animalcreek.com
Typical OMAP3 SoCs have four power domain states: ON,
INACTIVE, RETENTION, and OFF. The am35x family of SoCs
has only two states: ON and INACTIVE. To distinguish which
set of states the current device has, add the 'OMAP3_HAS_PWROFF'
feature. When that feature/bit is set, the device supports the
RETENTION and OFF states; otherwise, it doesn't.
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
Paul has mentioned this already, but the same applies here: We shouldn't
be using SoC-global feature flag for this. We already have per-pwrdm
flags that indicate what states a given powerdomain suports (see .pwrsts
field.)
Wherever we have blind writes to next powerstates that assume support
for RET/OFF is present, those should probably use a helper function from
the powerdomain code that checks if that state is even supported.
How about something like the patch below?
Note: its not well tested; just RFC.
Yes, your proposed patch looks right to me.
I guess it's up to Paul Jean to see if they'd rather see this build on
top of the Jean's functional power state work, or take this as a
standalone fix.
Kevin
Jean's work on functional powerstates will probably help here if you
really need to support INACTIVE. However, Paul may be right in that you
might just start with supporing ON only, and validate that module-level
wakups acutally work.
Yes, I think INACTIVE is a red herring so I'm going to stick with k.o
master branch for now (IOW, not base on Jean's patches). If you still
want me to base on his patches, just let me know.
Mark
--
From 32c54adb15c76396aeec809d38de4dde936b1e66 Mon Sep 17 00:00:00 2001
From: Mark A. Greer mgr...@animalcreek.com
Date: Mon, 23 Apr 2012 17:48:06 -0700
Subject: [PATCH] arm: omap: Use only valid power domain states
Some parts of the OMAP code assume that all power
domains support certain states (e.g., RET OFF).
This isn't always true (e.g., the am35x family of
SoC's) so those assumptions need to be removed.
Remove those assumptions by looking up the deepest
state that a power domain can be in whereever its
being blindly set. The 'max()' of the deepest
state and what the code formerly wanted to set it
to, is the correct state. If the code formerly
wanted to set it to PWRDM_POWER_OFF, then the
deepest possible state will be used (i.e., no
need to perform the 'max()').
The code still assumes that ON is a valid state.
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
arch/arm/mach-omap2/cpuidle34xx.c | 14 ++
arch/arm/mach-omap2/pm34xx.c | 15 +--
arch/arm/mach-omap2/powerdomain.c | 25 +
arch/arm/mach-omap2/powerdomain.h |2 ++
4 files changed, 46 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 5358664..60aa0c3 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -175,19 +175,25 @@ static int next_valid_state(struct cpuidle_device *dev,
struct cpuidle_state_usage *curr_usage = dev-states_usage[index];
struct cpuidle_state *curr = drv-states[index];
struct omap3_idle_statedata *cx = cpuidle_get_statedata(curr_usage);
- u32 mpu_deepest_state = PWRDM_POWER_RET;
- u32 core_deepest_state = PWRDM_POWER_RET;
+ u32 mpu_deepest_state, mpu_deepest_possible;
+ u32 core_deepest_state, core_deepest_possible;
int next_index = -1;
+ mpu_deepest_possible = pwrdm_get_deepest_state(mpu_pd);
+ mpu_deepest_state = max(mpu_deepest_possible, (u32)PWRDM_POWER_RET);
+
+ core_deepest_possible = pwrdm_get_deepest_state(core_pd);
+ core_deepest_state = max(core_deepest_possible, (u32)PWRDM_POWER_RET);
+
if (enable_off_mode) {
- mpu_deepest_state = PWRDM_POWER_OFF;
+ mpu_deepest_state = mpu_deepest_possible;
/*
* Erratum i583: valable for ES rev Es1.2 on 3630.
* CORE OFF mode is not supported in a stable form, restrict
* instead the CORE state to RET.
*/
if (!IS_PM34XX_ERRATUM(PM_SDRC_WAKEUP_ERRATUM_i583))
- core_deepest_state = PWRDM_POWER_OFF;
+ core_deepest_state = core_deepest_possible;
}
/* Check if current state is valid */
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index ec92676..7737bfb 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -614,12 +614,11 @@ void omap3_pm_off_mode_enable(int enable)
struct power_state *pwrst;
u32 state;
- if (enable)
- state = PWRDM_POWER_OFF;
Re: [PATCH 03/12] arm: omap3: Only sleep in cpuidle driver if I/O wake-ups work
Mark A. Greer mgr...@animalcreek.com writes: On Tue, Apr 24, 2012 at 01:51:05PM -0700, Mark A. Greer wrote: On Wed, Apr 11, 2012 at 03:37:47PM -0600, Paul Walmsley wrote: Hi Hi Paul, Kevin. On Wed, 11 Apr 2012, Mark A. Greer wrote: From: Mark A. Greer mgr...@animalcreek.com Currently, the OMAP3 cpuidle driver calls omap3_enter_idle() which calls omap_sram_idle(). omap_sram_idle() eventually causes a 'wfi' instruction to be executed effectively putting the system to sleep. It is assumed that an I/O wake-up event will occur to wake the system up again. This doesn't work on systems that don't support I/O wake-ups (indicated by omap3_has_io_wakeup() returning false). To handle this, follow the same path in omap3_enter_idle() that would be followed if an interrupt were pending. I don't quite understand this patch. Are you saying that AM3517/3505 can't wake from WFI? That would seem odd. There are other sources of wakeup on the system other than I/O wakeup. I/O wakeup only applies to wakeups from the I/O pads when the chip is in RETENTION or OFF. And as I understand it, neither of those apply to AM3517/3505? Even if I/O wakeups aren't supported, many of the IP blocks on the system should be able to cause the ARM to exit WFI by asserting their SWAKEUP lines and raising their interrupt lines. I have changed the code to keep everything in the ON state and use cpu_do_idle()--basically a wfi, cpu_v7_do_idle() in this case--and everything works well (except networking, see below) when using an mmc-based rootfs. The issue is with the emac--it can't wake the system up unless there is an irq from the PHY to a wakeup-enabled GPIO (confirmed by h/w engr). So, when using networking or using an nfs-based rootfs, there are all kinds of timeouts, etc. Basically, doing a wfi (i.e., pm_idle or cpuidle) and expecting the emac to wake the system back up won't work. How would you like me to proceed (to avoid the wfi in pm_idle cpuidle)? Just thinking out loud... We could chose whether pm_idle cpuidle issue a wfi based on whether there is a davinci-emac present. The issue with that is that someday there may be another SoC that has a davinci-emac that can wake up the system. I know cpu_is_xxx() is frowned upon but this does seem like a proper usage of it--the deciding factor really is whether its an am35x or not (and CONFIG_TI_DAVINCI_EMAC is enabled). The presence of the davinci_emac is probably overkill, avoiding WFI should really only be done when the davinci_emac is *active*. e.g. using an am35x with an EMAC *present*, but not in use because there's an MMC rootfs for example. If there's a good way to detect an in-use davinci_emac, then disable_hlt() can be used to avoid WFI. When the davinci_emac is not in use (e.g. module unloaded etc.) then enable_hlt() can be used to (re)allow WFI. 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 v2] arm: omap3: am35x: Fix clockdomain dependencies
On Thu, Apr 26, 2012 at 04:56:39PM -0600, Paul Walmsley wrote: On Thu, 19 Apr 2012, Mark A. Greer wrote: From: Mark A. Greer mgr...@animalcreek.com The am35x family of SoCs do not have an IVA so a parallel set of clockdomain dependencies are required that are simililar to OMAP3 but without any IVA dependencies. Signed-off-by: Mark A. Greer mgr...@animalcreek.com Thanks, queued for 3.5. Thanks Paul. FYI, I have a version rebased on top of Kevin's recent patch series that renames OMAP3517 to AM35XX (among other things), ARM: OMAP: remove IP checks from SoC family detection. Would you like that one instead? Mark -- -- 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: omap3: Only access IVA if one exists
Mark A. Greer mgr...@animalcreek.com writes: From: Mark A. Greer mgr...@animalcreek.com prcm_setup_regs() blindly accesses IVA bits in the PRM and calls omap3_iva_idle() which does more IVA related register accesses. Only do this if the IVA hardware actually exists. Signed-off-by: Mark A. Greer mgr...@animalcreek.com Thanks, queuing for v3.5 (branch: for_3.5/cleanup/pm) Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: omap3: am35x: Don't mark missing features as present
Mark A. Greer mgr...@animalcreek.com writes: From: Mark A. Greer mgr...@animalcreek.com The Chip Identification register on the am35x family of SoCs has bits 12, 7:5, and 3:2 marked as reserved and are read as zeroes. Unfortunately, on other omap SoCs, a 0 bit means a feature is Full Use so the OMAP3_CHECK_FEATURE() macro called by omap3_check_features() will incorrectly interpret those zeroes to mean that a feature is present even though it isn't. To fix that, the feature bits that are incorrectly set (namely, OMAP3_HAS_IVA and OMAP3_HAS_ISP) need to be cleared after all of the calls to OMAP3_CHECK_FEATURE() in omap3_check_features() are made. Signed-off-by: Mark A. Greer mgr...@animalcreek.com --- arch/arm/mach-omap2/id.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c index 0e79b7b..9736049 100644 --- a/arch/arm/mach-omap2/id.c +++ b/arch/arm/mach-omap2/id.c @@ -248,6 +248,17 @@ void __init omap3xxx_check_features(void) omap_features |= OMAP3_HAS_SDRC; /* + * am35x fixups: + * - The am35x Chip ID register has bits 12, 7:5, and 3:2 marked as + * reserved and therefore return 0 when read. Unfortunately, + * OMAP3_CHECK_FEATURE() will interpret some of those zeroes to + * mean that a feature is present even though it isn't so clear + * the incorrectly set feature bits. + */ + if (cpu_is_omap3505() || cpu_is_omap3517()) + omap_features = ~(OMAP3_HAS_IVA | OMAP3_HAS_ISP); I just sent a series that removes these cpu_is macros: http://marc.info/?l=linux-omapm=133548306205953w=2 It looks like I can just replace the above with 'if (cpu_is_am35xx()', correct? Since you have various AM35x devices, could you could give my series a spin and make this change? If it works, and acked-by/tested-by on my series would be appreciated as well. Thanks, Kevin + /* * TODO: Get additional info (where applicable) * e.g. Size of L2 cache. */ -- 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: omap3: am35x: Don't mark missing features as present
On Fri, Apr 27, 2012 at 02:21:59PM -0700, Kevin Hilman wrote: Mark A. Greer mgr...@animalcreek.com writes: From: Mark A. Greer mgr...@animalcreek.com The Chip Identification register on the am35x family of SoCs has bits 12, 7:5, and 3:2 marked as reserved and are read as zeroes. Unfortunately, on other omap SoCs, a 0 bit means a feature is Full Use so the OMAP3_CHECK_FEATURE() macro called by omap3_check_features() will incorrectly interpret those zeroes to mean that a feature is present even though it isn't. To fix that, the feature bits that are incorrectly set (namely, OMAP3_HAS_IVA and OMAP3_HAS_ISP) need to be cleared after all of the calls to OMAP3_CHECK_FEATURE() in omap3_check_features() are made. Signed-off-by: Mark A. Greer mgr...@animalcreek.com --- arch/arm/mach-omap2/id.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c index 0e79b7b..9736049 100644 --- a/arch/arm/mach-omap2/id.c +++ b/arch/arm/mach-omap2/id.c @@ -248,6 +248,17 @@ void __init omap3xxx_check_features(void) omap_features |= OMAP3_HAS_SDRC; /* +* am35x fixups: +* - The am35x Chip ID register has bits 12, 7:5, and 3:2 marked as +* reserved and therefore return 0 when read. Unfortunately, +* OMAP3_CHECK_FEATURE() will interpret some of those zeroes to +* mean that a feature is present even though it isn't so clear +* the incorrectly set feature bits. +*/ + if (cpu_is_omap3505() || cpu_is_omap3517()) + omap_features = ~(OMAP3_HAS_IVA | OMAP3_HAS_ISP); I just sent a series that removes these cpu_is macros: http://marc.info/?l=linux-omapm=133548306205953w=2 It looks like I can just replace the above with 'if (cpu_is_am35xx()', correct? Yes. Since you have various AM35x devices, could you could give my series a spin and make this change? If it works, and acked-by/tested-by on my series would be appreciated as well. Sure. I already have them ported to your series. I have to leave early today but I'll test them get them to you on Monday. Sorry for the delay. Mark -- 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 v9 11/25] gpio/omap: cleanup omap_gpio_mod_init function
DebBarma, Tarun Kanti tarun.ka...@ti.com writes: On Wed, Apr 25, 2012 at 7:15 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: [...] Correction. Don't email your patch in any way to the stable folk _before_ it has been taken into Linus' tree. However, you _may_ add in the patch attributations a Cc: sta...@vger.kernel.org tag if you want the stable folk to automatically pick up your patch when it _does_ end up in Linus' tree. But... make sure that git send-email or whatever doesn't automatically add that to the recipients for the emailed patch. If you send the stable people a patch before its in mainline, you'll get a whinge telling you to read Documentation/stable_kernel_rules.txt Alright, I will add Cc: sta...@vger.kernel.org tag in the patch. If you do that, be sure to use --suppress-cc=bodycc when you send it with git-send-email. 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 2/8] dmaengine: amba-pl08x: ensure physical channels are properly held
On Fri, Apr 27, 2012 at 10:38:08PM +0200, Linus Walleij wrote: On Wed, Apr 18, 2012 at 12:19 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: Oops, this patch wasn't supposed to be part of this set... ...however it gives me the impression that you have a patch set cooking to also switch PL08x over to the virtual channel mechanism which is really appetizing to see :-) Actually, that doesn't exist yet. This was a patch I'd had floating around, but I don't think its needed in any way - I mis-analysed the code and created the 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 03/12] arm: omap3: Only sleep in cpuidle driver if I/O wake-ups work
On Fri, Apr 27, 2012 at 02:12:12PM -0700, Kevin Hilman wrote: Mark A. Greer mgr...@animalcreek.com writes: On Tue, Apr 24, 2012 at 01:51:05PM -0700, Mark A. Greer wrote: We could chose whether pm_idle cpuidle issue a wfi based on whether there is a davinci-emac present. The issue with that is that someday there may be another SoC that has a davinci-emac that can wake up the system. I know cpu_is_xxx() is frowned upon but this does seem like a proper usage of it--the deciding factor really is whether its an am35x or not (and CONFIG_TI_DAVINCI_EMAC is enabled). The presence of the davinci_emac is probably overkill, avoiding WFI should really only be done when the davinci_emac is *active*. e.g. using an am35x with an EMAC *present*, but not in use because there's an MMC rootfs for example. If there's a good way to detect an in-use davinci_emac, then disable_hlt() can be used to avoid WFI. When the davinci_emac is not in use (e.g. module unloaded etc.) then enable_hlt() can be used to (re)allow WFI. Good idea. I'll see what I can do. Mark -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] gpio/omap: remaining cleanups and fix
Grant Likely grant.lik...@secretlab.ca writes:
On Fri, 27 Apr 2012 19:43:30 +0530, Tarun Kanti DebBarma tarun.ka...@ti.com
wrote:
Here are the remaining cleanup patches. There are broadly
two categories of cleanups.
Cat-1: Those missed while introducing new feature like SPARSE_IRQ
handling and DT support; use edge/level handlers from
generic IRQ framework.
Cat-2: Removal of redundant fields from struct gpio_bank{} as a
result of they being already covered by members within
context field of struct gpio_bank{}.
Reference:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Commit: 66f75a5d028beaf67c931435fdc3e7823125730c (Linux 3.4-rc4)
Series is available for reference here:
git://gitorious.org/~tarunkanti/omap-sw-develoment/tarunkantis-linux-omap-dev.git
for_3.5/gpio_more_cleanup_fixes
Test info:
OMAP2+ platforms: OMAP2430SDP, OMAP3430SDP, OMAP4430SDP
OMAP1: Bootup test on OMAP1710SDP.
Cc: Kevin Hilman khil...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Cousson, Benoit b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Tarun Kanti DebBarma (8):
gpio/omap: remove virtual_irq_start variable
gpio/omap: remove saved_fallingdetect, saved_risingdetect
gpio/omap: remove suspend_wakeup field from struct gpio_bank
gpio/omap: remove saved_wakeup field from struct gpio_bank
gpio/omap: remove retrigger variable in gpio_irq_handler
gpio/omap: remove suspend/resume callbacks
gpio/omap: remove cpu_is_omap() checks from *_runtime_resume()
gpio/omap: fix missing check in *_runtime_suspend()
The changes look fine to me. Which branch should this series be
merged through? It can either go via arm-soc or my gpio/next branch.
This needs a little more review/testing on OMAP.
Expect a pull request from me when it's ready and you can take it
through gpio/nex.
Thanks,
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: omap2+: set IRQCHIP_SKIP_SET_WAKE for INTC interrupts.
NeilBrown ne...@suse.de writes: On Thu, 26 Apr 2012 13:39:07 -0700 Kevin Hilman khil...@ti.com wrote: NeilBrown ne...@suse.de writes: All interrupts can wake-from-sleep (I think) so it should be permissible to call enable_irq_wake(). Setting this flag allows that. It is needed because without this, an interrupt which is delivered during late suspend will get ignored but will not cause suspend to abort. If enable_irq_wake() is called and succeeds, check_wakuep_irqs() will abort the suspend if the interrupt has fired. Signed-off-by: NeilBrown ne...@suse.de The name of this flag and the effect of setting it are somewhat confusing (e.g. why does skipping set_wake suddenly make wakeups work.) So I tried to make it clearer with a reworking of the changelog (below.) If I understood this correctly, and if you're OK with the updated changelog, I'll queue this up for v3.5. I'm very OK with your updated changelog - thanks. Filling in various bits that I didn't know and clarifies the rest :-) Great, thanks. Adding ack from Santosh (thanks!) and queuing for v3.5[1] Kevin [1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_3.5/pm-misc -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] gpio/omap: remaining cleanups and fix
On Fri, Apr 27, 2012 at 3:57 PM, Kevin Hilman khil...@ti.com wrote:
Grant Likely grant.lik...@secretlab.ca writes:
On Fri, 27 Apr 2012 19:43:30 +0530, Tarun Kanti DebBarma
tarun.ka...@ti.com wrote:
Here are the remaining cleanup patches. There are broadly
two categories of cleanups.
Cat-1: Those missed while introducing new feature like SPARSE_IRQ
handling and DT support; use edge/level handlers from
generic IRQ framework.
Cat-2: Removal of redundant fields from struct gpio_bank{} as a
result of they being already covered by members within
context field of struct gpio_bank{}.
Reference:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Commit: 66f75a5d028beaf67c931435fdc3e7823125730c (Linux 3.4-rc4)
Series is available for reference here:
git://gitorious.org/~tarunkanti/omap-sw-develoment/tarunkantis-linux-omap-dev.git
for_3.5/gpio_more_cleanup_fixes
Test info:
OMAP2+ platforms: OMAP2430SDP, OMAP3430SDP, OMAP4430SDP
OMAP1: Bootup test on OMAP1710SDP.
Cc: Kevin Hilman khil...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Cousson, Benoit b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Tarun Kanti DebBarma (8):
gpio/omap: remove virtual_irq_start variable
gpio/omap: remove saved_fallingdetect, saved_risingdetect
gpio/omap: remove suspend_wakeup field from struct gpio_bank
gpio/omap: remove saved_wakeup field from struct gpio_bank
gpio/omap: remove retrigger variable in gpio_irq_handler
gpio/omap: remove suspend/resume callbacks
gpio/omap: remove cpu_is_omap() checks from *_runtime_resume()
gpio/omap: fix missing check in *_runtime_suspend()
The changes look fine to me. Which branch should this series be
merged through? It can either go via arm-soc or my gpio/next branch.
This needs a little more review/testing on OMAP.
Expect a pull request from me when it's ready and you can take it
through gpio/nex.
Okay.
g.
--
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/RFT 0/8] ARM: OMAP: remove IP checks from SoC family detection
On Thu, Apr 26, 2012 at 04:29:45PM -0700, Kevin Hilman wrote: Hi Kevin. This is a rebased version of this series which is ready for broader testing. I'd especially appreciate testing from those of you with AM35x platforms. Currently, our SoC detection is based on SoC family detection (using die ID) and the presence of specific IP blocks (or feature.) This series begins the separation of the SoC family detection and specific IP detection by completely removing IP detection from the SoC family detection (cpu_is_*.) Applies on top of v3.4-rc4, boot tested on AM3517 EVM. Your series applied and booted without issue until the point that pm_idle is called. At that point it hung because its doing a wfi and not getting an interrupt to wake up back up. That's expected behaviour so your patches are good (IMHO) but I need to finish and submit a new version of my patches to fix that issue. I tested using an nfs-mounted and mmc-mounted rootfs (and CONFIG_TI_DAVINCI_EMAC=y). Mark -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gpio/omap: fix incorrect initialization of omap_gpio_mod_init
Tarun Kanti DebBarma tarun.ka...@ti.com writes: Breaking commit: ab985f0f7c2c0ef90b7c832f0c04f470dda0593d Initialization of irqenable, irqstatus registers is the common operation done in this function for all OMAP platforms, viz. OMAP1, OMAP2+. The latter _gpio_rmw()'s to irqenable register was overwriting the correctly programmed OMAP1 value at the beginning. As a result, even though it worked on OMAP2+ platforms it was breaking OMAP1 functionality. On close observation it is found that the first _gpio_rmw() which is supposedly done to take care of OMAP1 platform is generic enough and takes care of OMAP2+ platform as well. Therefore remove the latter _gpio_rmw() to irqenable as they are redundant now. Writing to ctrl and debounce_en registers for OMAP2+ platforms are modified to match the original(pre-cleanup) code where the registers are initialized with 0. In the cleanup series since we are using _gpio_rmw(reg, 0, 1), instead of __raw_writel(), we are just reading and writing the same values to ctrl and debounce_en. This is not an issue for debounce_en register because it has 0x0 as the default value. But in the case of ctrl register the default value is 0x2 (GATINGRATIO = 0x1) so that we end up writing 0x2 instead of intended 0 value. Therefore correcting it to _gpio_rmw(reg, l, 0), where l = 0x so that registers are initialized to 0. Also, changing the sequence and logic of initializing the irqstatus. Cc: sta...@vger.kernel.org Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Grant Likely grant.lik...@secretlab.ca Reported-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com --- Tested on OMAP2+ platforms and bootup test on OMAP1710. Janusz, Please help me in validating the patch on OMAP1 platform. drivers/gpio/gpio-omap.c |9 +++-- 1 files changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c index 1adc2ec..910fd14 100644 --- a/drivers/gpio/gpio-omap.c +++ b/drivers/gpio/gpio-omap.c @@ -964,19 +964,16 @@ static void omap_gpio_mod_init(struct gpio_bank *bank) return; } + _gpio_rmw(base, bank-regs-irqstatus, l, !bank-regs-irqenable_inv); _gpio_rmw(base, bank-regs-irqenable, l, bank-regs-irqenable_inv); - _gpio_rmw(base, bank-regs-irqstatus, l, - bank-regs-irqenable_inv == false); Not sure I follow this change. It seems the ending value in irqstatus will be the same, but it was just moved before irqenable. You mention changing this order in the changelog, but do not mention why. - _gpio_rmw(base, bank-regs-irqenable, l, bank-regs-debounce_en != 0); - _gpio_rmw(base, bank-regs-irqenable, l, bank-regs-ctrl != 0); Why were these here in the first place? The changelog is not very clear about *why* these can be removed. if (bank-regs-debounce_en) - _gpio_rmw(base, bank-regs-debounce_en, 0, 1); + _gpio_rmw(base, bank-regs-debounce_en, l, 0); Why the read/modify/write? Why not just go back to the __raw_write? /* Save OE default value (0x) in the context */ bank-context.oe = __raw_readl(bank-base + bank-regs-direction); /* Initialize interface clk ungated, module enabled */ if (bank-regs-ctrl) - _gpio_rmw(base, bank-regs-ctrl, 0, 1); + _gpio_rmw(base, bank-regs-ctrl, l, 0); same question. } static __devinit void 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/RFT 0/8] ARM: OMAP: remove IP checks from SoC family detection
Mark A. Greer mgr...@animalcreek.com writes: On Thu, Apr 26, 2012 at 04:29:45PM -0700, Kevin Hilman wrote: Hi Kevin. This is a rebased version of this series which is ready for broader testing. I'd especially appreciate testing from those of you with AM35x platforms. Currently, our SoC detection is based on SoC family detection (using die ID) and the presence of specific IP blocks (or feature.) This series begins the separation of the SoC family detection and specific IP detection by completely removing IP detection from the SoC family detection (cpu_is_*.) Applies on top of v3.4-rc4, boot tested on AM3517 EVM. Your series applied and booted without issue until the point that pm_idle is called. At that point it hung because its doing a wfi and not getting an interrupt to wake up back up. That's expected behaviour so your patches are good (IMHO) but I need to finish and submit a new version of my patches to fix that issue. For the benefit of others wanting to test this: You have to use 'nohlt' on the cmdline on AM35x in order to avoid WFI and the wakeup problems that are still being worked on. 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: OMAP3EVM not booting on l-o master
Tero Kristo t-kri...@ti.com writes:
On Tue, 2012-04-24 at 10:07 -0700, Kevin Hilman wrote:
[...]
From 26733dd988ccc9e72355a39e01b2d6e9215a892d Mon Sep 17 00:00:00 2001
From: Tero Kristo t-kri...@ti.com
Date: Mon, 23 Apr 2012 12:14:46 +0300
Subject: [PATCH] ARM: OMAP3: PM: move wakeup event ack to hwmod_io handler
PRCM IO interrupts are handled with a shared interrupt handler logic.
Currently hwmod_io is processing the actual event, but the acking
of the IO wakeups is done from the PM code with a separate handler.
If a wakeup event is detected during init before the PM code is in
place, the interrupt handler can hang in an infinite loop. Fix this
by removing the pm_io handler, and calling its functionality from
within the hwmod_io handler. This fix applies only to OMAP3, as
OMAP4 does not have similar wakeup handling logic.
Signed-off-by: Tero Kristo t-kri...@ti.com
Doesn't this mean that even on a !PM kernel that IO events might still
be firing for nothing?
I actually disabled the IO handler in !PM kernel, as I thought this
would be a problem there.
OK
Seems like it would be better to ensure that these interrupts are just
disabled until the PM core initializes and can enable them.
I thought about this but I couldn't figure out a clean way to do this.
If I do irq_request, it automatically enables the interrupt, and if
there is an interrupt pending it will fire immediately and get stuck.
hmm, I thought there was a flag for disabling the auto-enable feature...
/me looks
Yup, from linux/irq.h
* IRQ_NOAUTOEN - Interrupt is not automatically enabled in
*request/setup_irq()
With that, we can just set all the PRCM IRQs to be disabled until
explicitly enabled using enable_irq(). The following patch (only boot
tested on OMAP3530/Overo and OMAP4430/Panda) should take care of it.
Do you think that should solve this problem?
Afzal, care to test the patch below to see if it fixes your boot problem
on OMAP3EVM with the IO chain series?
Thanks,
Kevin
From: Kevin Hilman khil...@ti.com
Date: Fri, 27 Apr 2012 16:05:51 -0700
Subject: [PATCH] ARM: OMAP2+: PM: leave PRCM interrupts disabled until
explicitly enabled.
By default, request_irq() will auto-enable the requested IRQ.
For PRCM interrupts, we want to avoid that until the PM core code is
fully ready to handle the interrupts. This is particularily true for
IO pad interrupts, which are shared between the hwmod core and the PRM
core. This is also important for !PM kernels where we don't need
any PRCM interrupts firing at all.
In order to avoid PRCM interrupts until ready, set the IRQ_NOAUTOEN
flag for the PRCM chained handler which means PRCM interrupts will
remain disabled after request_irq().
Then, explicitly enable the PRCM interrupts after the request_irq() in
the PM core (but not in the hwmod core.)
Cc: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/pm34xx.c |2 ++
arch/arm/mach-omap2/prm_common.c |3 ++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 66ff828..ba17813 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -722,6 +722,7 @@ static int __init omap3_pm_init(void)
ret = request_irq(omap_prcm_event_to_irq(wkup),
_prcm_int_handle_wakeup, IRQF_NO_SUSPEND, pm_wkup, NULL);
+ enable_irq(omap_prcm_event_to_irq(wkup));
if (ret) {
pr_err(pm: Failed to request pm_wkup irq\n);
@@ -732,6 +733,7 @@ static int __init omap3_pm_init(void)
ret = request_irq(omap_prcm_event_to_irq(io),
_prcm_int_handle_io, IRQF_SHARED | IRQF_NO_SUSPEND, pm_io,
omap3_pm_init);
+ enable_irq(omap_prcm_event_to_irq(io));
if (ret) {
pr_err(pm: Failed to request pm_io irq\n);
diff --git a/arch/arm/mach-omap2/prm_common.c b/arch/arm/mach-omap2/prm_common.c
index d28f848..c805775 100644
--- a/arch/arm/mach-omap2/prm_common.c
+++ b/arch/arm/mach-omap2/prm_common.c
@@ -307,7 +307,8 @@ int omap_prcm_register_chain_handler(struct
omap_prcm_irq_setup *irq_setup)
ct-regs.ack = irq_setup-ack + i * 4;
ct-regs.mask = irq_setup-mask + i * 4;
- irq_setup_generic_chip(gc, mask[i], 0, IRQ_NOREQUEST, 0);
+ irq_setup_generic_chip(gc, mask[i], 0, IRQ_NOREQUEST,
+ IRQ_NOAUTOEN);
prcm_irq_chips[i] = gc;
}
--
1.7.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH-V3 3/3] ARM: OMAP3+: clock33xx: Add AM33XX clock tree data
On Fri, 27 Apr 2012, Hiremath, Vaibhav wrote: On Thu, Apr 26, 2012 at 14:19:28, Paul Walmsley wrote: looking at Table 1-1 Device Features of SPRUH73D, it seems that some AM33xx family chips come with some features disabled, such as the PRU-ICSS, the SGX, Ethernet, or USB. How will this affect the clock tree? For example, is it correct for us to include the PRU-ICSS clock control on a clock tree that is booted on an AM3352 or an AM3354? I thought of this, but if you look at the existing way of handling such Si version based clock registration is supported by cpu_clkflg, like CK_3XXX, CK_AM35XX, etc... During my baseport patch submission, Tony had removed CK_AM33XX flag while merging them. I believe, we are trying to get rid of these flags, and that's where Tony had removed them form my baseport patch. I was not sure on how to handle this, so I decided to continue with full chip support (AM3358 and AM3359). Okay, no problem. Sounds like we should start with full support and then remove clocks later if they cause problems on the lower-end devices. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: control: Add AM33XX control reg sec clkctrl offset
Hi Vaibhav On Wed, 21 Mar 2012, Vaibhav Hiremath wrote: Define AM33XX control register, in order to allow access to control register address space, also add CONTROL_SEC_CLK_CTRL register offset; both are required in clock tree data, for wdt0 and timer0 clock source select configuration. CONTROL.SEC_CLK_CTRL register is provided to select/configure clock input for WDT0 and TIMER0. This patch has been updated so it builds, and also updated to add some AM33XX macros needed for the clock tree and to fix some control.h whitespace problems; updated version below. Could you please take a quick look and see if it is okay with you? - Paul From: Vaibhav Hiremath hvaib...@ti.com Date: Thu, 19 Apr 2012 15:15:37 -0600 Subject: [PATCH] ARM: OMAP2+: control: Add AM33XX control reg sec clkctrl offset Define AM33XX control register, in order to allow access to control register address space, also add CONTROL_SEC_CLK_CTRL register offset; both are required in clock tree data, for wdt0 and timer0 clock source select configuration. CONTROL.SEC_CLK_CTRL register is provided to select/configure clock input for WDT0 and TIMER0. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Tony Lindgren t...@atomide.com [p...@pwsan.com: added include of plat/am33xx.h to fix build break; added AM33XX_CONTROL_STATUS bitfields that will be needed for the clock tree; fixed some control.h whitespace problems while here] Signed-off-by: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/control.h | 39 +++ 1 file changed, 23 insertions(+), 16 deletions(-) diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h index a406fd0..c43f03c 100644 --- a/arch/arm/mach-omap2/control.h +++ b/arch/arm/mach-omap2/control.h @@ -21,6 +21,8 @@ #include mach/ctrl_module_pad_core_44xx.h #include mach/ctrl_module_pad_wkup_44xx.h +#include plat/am33xx.h + #ifndef __ASSEMBLY__ #define OMAP242X_CTRL_REGADDR(reg) \ OMAP2_L4_IO_ADDRESS(OMAP242X_CTRL_BASE + (reg)) @@ -28,6 +30,8 @@ OMAP2_L4_IO_ADDRESS(OMAP243X_CTRL_BASE + (reg)) #define OMAP343X_CTRL_REGADDR(reg) \ OMAP2_L4_IO_ADDRESS(OMAP343X_CTRL_BASE + (reg)) +#define AM33XX_CTRL_REGADDR(reg) \ + AM33XX_L4_WK_IO_ADDRESS(AM33XX_SCM_BASE + (reg)) #else #define OMAP242X_CTRL_REGADDR(reg) \ OMAP2_L4_IO_ADDRESS(OMAP242X_CTRL_BASE + (reg)) @@ -35,6 +39,8 @@ OMAP2_L4_IO_ADDRESS(OMAP243X_CTRL_BASE + (reg)) #define OMAP343X_CTRL_REGADDR(reg) \ OMAP2_L4_IO_ADDRESS(OMAP343X_CTRL_BASE + (reg)) +#define AM33XX_CTRL_REGADDR(reg) \ + AM33XX_L4_WK_IO_ADDRESS(AM33XX_SCM_BASE + (reg)) #endif /* __ASSEMBLY__ */ /* @@ -312,15 +318,15 @@ OMAP343X_SCRATCHPAD + reg) /* AM35XX_CONTROL_IPSS_CLK_CTRL bits */ -#define AM35XX_USBOTG_VBUSP_CLK_SHIFT 0 -#define AM35XX_CPGMAC_VBUSP_CLK_SHIFT 1 -#define AM35XX_VPFE_VBUSP_CLK_SHIFT 2 -#define AM35XX_HECC_VBUSP_CLK_SHIFT 3 -#define AM35XX_USBOTG_FCLK_SHIFT8 -#define AM35XX_CPGMAC_FCLK_SHIFT9 -#define AM35XX_VPFE_FCLK_SHIFT 10 - -/*AM35XX CONTROL_LVL_INTR_CLEAR bits*/ +#define AM35XX_USBOTG_VBUSP_CLK_SHIFT 0 +#define AM35XX_CPGMAC_VBUSP_CLK_SHIFT 1 +#define AM35XX_VPFE_VBUSP_CLK_SHIFT2 +#define AM35XX_HECC_VBUSP_CLK_SHIFT3 +#define AM35XX_USBOTG_FCLK_SHIFT 8 +#define AM35XX_CPGMAC_FCLK_SHIFT 9 +#define AM35XX_VPFE_FCLK_SHIFT 10 + +/* AM35XX CONTROL_LVL_INTR_CLEAR bits */ #define AM35XX_CPGMAC_C0_MISC_PULSE_CLRBIT(0) #define AM35XX_CPGMAC_C0_RX_PULSE_CLR BIT(1) #define AM35XX_CPGMAC_C0_RX_THRESH_CLR BIT(2) @@ -330,21 +336,22 @@ #define AM35XX_VPFE_CCDC_VD1_INT_CLR BIT(6) #define AM35XX_VPFE_CCDC_VD2_INT_CLR BIT(7) -/*AM35XX CONTROL_IP_SW_RESET bits*/ +/* AM35XX CONTROL_IP_SW_RESET bits */ #define AM35XX_USBOTGSS_SW_RST BIT(0) #define AM35XX_CPGMACSS_SW_RST BIT(1) #define AM35XX_VPFE_VBUSP_SW_RST BIT(2) #define AM35XX_HECC_SW_RST BIT(3) #define AM35XX_VPFE_PCLK_SW_RSTBIT(4) -/* - * CONTROL AM33XX STATUS register - */ +/* AM33XX CONTROL_STATUS register */ #define AM33XX_CONTROL_STATUS 0x040 +#define AM33XX_CONTROL_SEC_CLK_CTRL0x1bc -/* - * CONTROL OMAP STATUS register to identify OMAP3 features - */ +/* AM33XX CONTROL_STATUS bitfields (partial) */ +#define AM33XX_CONTROL_STATUS_SYSBOOT1_SHIFT 22 +#define AM33XX_CONTROL_STATUS_SYSBOOT1_MASK(0x3 22) + +/* CONTROL OMAP STATUS register to identify OMAP3 features */ #define OMAP3_CONTROL_OMAP_STATUS 0x044c #define OMAP3_SGX_SHIFT
Re: [PATCH-V4 1/4] ARM: OMAP3+: am33xx: Add voltage domain data
Hi Vaibhav, Kevin, On Fri, 30 Mar 2012, Vaibhav Hiremath wrote: Currently dummy voltage domain data is being created in order to succeed boot process, nothing has been done w.r.t actual hardware (voltage control). Also, hook up the AM33XX voltage domain to OMAP framework. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Afzal Mohammed af...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Rajendra Nayak rna...@ti.com Looks okay to me. Kevin, you want to ack this one and I will queue it? Either that, or if you want to take it, I will ack it. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: hwmod: Add new sysc_type3 into omap_hwmod required for am33xx
On Fri, 17 Feb 2012, Vaibhav Hiremath wrote: In case of AM33xx family of devices (like cpsw) have different sysc bit field offsets defined, sysc_type3: | 3 2 | 10 | | STDBYMODE | IDLEMODE | So introduce new sysc_type3 in omap_hwmod common data. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com Thanks, queued for 3.5. - 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
[RESEND PATCH 1/2] ARM: add cpufreq transiton notifier to adjust loops_per_jiffy for smp
If CONFIG_SMP, cpufreq skips loops_per_jiffy update, because different
arch has different per-cpu loops_per_jiffy definition.
Signed-off-by: Richard Zhao richard.z...@freescale.com
Acked-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/kernel/smp.c | 54 +
1 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index addbbe8..33af711 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -25,6 +25,7 @@
#include linux/percpu.h
#include linux/clockchips.h
#include linux/completion.h
+#include linux/cpufreq.h
#include linux/atomic.h
#include asm/cacheflush.h
@@ -604,3 +605,56 @@ int setup_profiling_timer(unsigned int multiplier)
{
return -EINVAL;
}
+
+#ifdef CONFIG_CPU_FREQ
+
+static DEFINE_PER_CPU(unsigned long, l_p_j_ref);
+static DEFINE_PER_CPU(unsigned long, l_p_j_ref_freq);
+static unsigned long global_l_p_j_ref;
+static unsigned long global_l_p_j_ref_freq;
+
+static int cpufreq_callback(struct notifier_block *nb,
+ unsigned long val, void *data)
+{
+ struct cpufreq_freqs *freq = data;
+ int cpu = freq-cpu;
+
+ if (freq-flags CPUFREQ_CONST_LOOPS)
+ return NOTIFY_OK;
+
+ if (!per_cpu(l_p_j_ref, cpu)) {
+ per_cpu(l_p_j_ref, cpu) =
+ per_cpu(cpu_data, cpu).loops_per_jiffy;
+ per_cpu(l_p_j_ref_freq, cpu) = freq-old;
+ if (!global_l_p_j_ref) {
+ global_l_p_j_ref = loops_per_jiffy;
+ global_l_p_j_ref_freq = freq-old;
+ }
+ }
+
+ if ((val == CPUFREQ_PRECHANGE freq-old freq-new) ||
+ (val == CPUFREQ_POSTCHANGE freq-old freq-new) ||
+ (val == CPUFREQ_RESUMECHANGE || val == CPUFREQ_SUSPENDCHANGE)) {
+ loops_per_jiffy = cpufreq_scale(global_l_p_j_ref,
+ global_l_p_j_ref_freq,
+ freq-new);
+ per_cpu(cpu_data, cpu).loops_per_jiffy =
+ cpufreq_scale(per_cpu(l_p_j_ref, cpu),
+ per_cpu(l_p_j_ref_freq, cpu),
+ freq-new);
+ }
+ return NOTIFY_OK;
+}
+
+static struct notifier_block cpufreq_notifier = {
+ .notifier_call = cpufreq_callback,
+};
+
+static int __init register_cpufreq_notifier(void)
+{
+ return cpufreq_register_notifier(cpufreq_notifier,
+ CPUFREQ_TRANSITION_NOTIFIER);
+}
+core_initcall(register_cpufreq_notifier);
+
+#endif
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND PATCH 2/2] cpufreq: OMAP: remove loops_per_jiffy recalculate for smp
arm registered cpufreq transition notifier to recalculate it.
Signed-off-by: Richard Zhao richard.z...@freescale.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
drivers/cpufreq/omap-cpufreq.c | 35 ---
1 files changed, 0 insertions(+), 35 deletions(-)
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 17fa04d..83a78ad 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -40,16 +40,6 @@
/* OPP tolerance in percentage */
#defineOPP_TOLERANCE 4
-#ifdef CONFIG_SMP
-struct lpj_info {
- unsigned long ref;
- unsigned intfreq;
-};
-
-static DEFINE_PER_CPU(struct lpj_info, lpj_ref);
-static struct lpj_info global_lpj_ref;
-#endif
-
static struct cpufreq_frequency_table *freq_table;
static atomic_t freq_table_users = ATOMIC_INIT(0);
static struct clk *mpu_clk;
@@ -161,31 +151,6 @@ static int omap_target(struct cpufreq_policy *policy,
}
freqs.new = omap_getspeed(policy-cpu);
-#ifdef CONFIG_SMP
- /*
-* Note that loops_per_jiffy is not updated on SMP systems in
-* cpufreq driver. So, update the per-CPU loops_per_jiffy value
-* on frequency transition. We need to update all dependent CPUs.
-*/
- for_each_cpu(i, policy-cpus) {
- struct lpj_info *lpj = per_cpu(lpj_ref, i);
- if (!lpj-freq) {
- lpj-ref = per_cpu(cpu_data, i).loops_per_jiffy;
- lpj-freq = freqs.old;
- }
-
- per_cpu(cpu_data, i).loops_per_jiffy =
- cpufreq_scale(lpj-ref, lpj-freq, freqs.new);
- }
-
- /* And don't forget to adjust the global one */
- if (!global_lpj_ref.freq) {
- global_lpj_ref.ref = loops_per_jiffy;
- global_lpj_ref.freq = freqs.old;
- }
- loops_per_jiffy = cpufreq_scale(global_lpj_ref.ref, global_lpj_ref.freq,
- freqs.new);
-#endif
done:
/* notifiers */
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
