RE: [PATCH v3 4/4] arm/dts: Add tps65217 regulator DT data to am335x-bone.dts
On Wed, Sep 05, 2012 at 19:59:54, Koen Kooi wrote: > > Op 5 sep. 2012, om 16:24 heeft Matt Porter het volgende > geschreven: > > > On Wed, Sep 05, 2012 at 03:29:30PM +0200, Koen Kooi wrote: > >> > >> Op 28 aug. 2012, om 07:34 heeft "AnilKumar, Chimata" > >> het volgende geschreven: > >> > >>> Hi Koen, > >>> > >>> On Fri, Aug 24, 2012 at 13:32:17, Koen Kooi wrote: > > Op 24 aug. 2012, om 09:56 heeft Koen Kooi > het volgende geschreven: > > > > > Op 24 aug. 2012, om 09:26 heeft "AnilKumar, Chimata" > > het volgende geschreven: > > > >> Hi Koen, > >> > >> On Fri, Aug 24, 2012 at 11:58:34, Koen Kooi wrote: > >>> > >>> Op 24 aug. 2012, om 07:50 heeft "AnilKumar, Chimata" > >>> het volgende geschreven: > >>> > Hi Koen, > > On Thu, Aug 23, 2012 at 19:43:48, Koen Kooi wrote: > > > > Op 21 aug. 2012, om 13:17 heeft AnilKumar Ch het > > volgende geschreven: > > > >> Add tps65217 regulator device tree data to AM335x-Bone by adding > >> regulator consumers with tightened constraints and regulator-name. > >> TPS65217 regulator handle can be obtained by using this regulator > >> name. > >> > >> This patch also add I2C node with I2C frequency and tps65217 PMIC > >> I2C slave address. > >> > >> Signed-off-by: AnilKumar Ch > > > > I tried this and the kernel immediately crashes on my beaglebone. > > Could you upload the complete git tree and .config you used to test > > this to somewhere public please? > > Use this repo to test on beaglebone > https://github.com/hvaibhav/am335x-linux/commits/am335x-upstream-staging-pinctrl > > This wiki talks about how to build and use? > https://github.com/hvaibhav/am335x-linux/wiki/How-To-Use-Upstream-Tree > > Note: Enable tps65217 regulator in kernel config. > >>> > >>> I used that repo and as a seperate test I rebased that to latest > >>> mainline, same thing: as soon as I turn on the TPS in the .config it > >>> crashes on boot. Is the pinctrl repo the *exact* repo you used to > >>> test the patches on beaglebone? > >> > >> I tested on latest mainline after merging to > >> am335x-upstream-staging-pinctrl (voltage also changing) > >> > >> Can you share your .config and uImage? > > > > Config: > > https://github.com/beagleboard/kernel/blob/beaglebone-3.6/patches/configs/beaglebone > > > >> My config details:- (After merge) > >> 1. omap2plus_defconfig > >> 2. Enable tps65217 MFD driver > >> 3. Enable tps65217 regulator driver > > > > > > I rebased onto latest mainline and refreshed the base patches from > > Vaibhav and I now get: > > > > [0.246796] tps65217 0-0024: TPS65217 ID 0xf version 1.1 > > > > So it boots! I don't know what made it break before, but it's working > > now :) > > *sigh* I'm an idiot: > > root@beaglebone:~# uname -a > Linux beaglebone 3.6.0-rc3-00103-gfd02083 #86 SMP Fri Aug 24 09:45:54 > CEST 2012 armv7l GNU/Linux > root@beaglebone:~# zcat /proc/config.gz | grep 217 > CONFIG_MFD_TPS65217=y > # CONFIG_REGULATOR_TPS65217 is not set > > Will retry with regulator driver actually turned on in a bit. > >>> > >>> Is it working after enabling the regulator? > >> > >> It took me a while to get back to this problem, but it still isn't working > >> for me. I did manage to get more info on the error: > >> > >> root@bone-mainline:~# insmod tps65217-regulator.ko > >> [ 32.754419] Unable to handle kernel NULL pointer dereference at virtual > >> address 00c8 > >> [ 32.763087] pgd = cea6 > >> [ 32.765969] [00c8] *pgd=8fbed831, *pte=, *ppte= > >> [ 32.772617] Internal error: Oops: 17 [#1] SMP THUMB2 > >> [ 32.777827] Modules linked in: tps65217_regulator(+) ip_tables x_tables > >> snd_soc_omap snd_soc_core regmap_spi snd_pcm snd_timer snd soundcore > >> snd_page_alloc ipv6 > >> [ 32.792976] CPU: 0Not tainted (3.6.0-rc4 #109) > >> [ 32.798106] PC is at regmap_read+0x8/0x38 > >> [ 32.802315] LR is at regulator_get_voltage_sel_regmap+0x15/0x38 > > > > I just got to this same point last night as I needed this working to > > test omap_hsmmc with edma dmaengine... > > > > The problem is that the tps65217-regulator driver is handing the wrong > > device to regulator_register() and it contains a null regmap. This patch > > passes in the the parent dev to fix it. Maybe I missed another patch > > that addresses this in a different way, such as the regulator devices > > being stuffed with the regmap devres? > > > > -Matt > > > > From 40d118bebc5eaf2a8df4f8b5e113b892a3210f96 Mon Sep 17 00:00:00 2001 > > From: Matt Porter > >
Re: [PATCHv2 1/4] mfd: smsc: Add support for smsc gpio io/keypad driver
On Wed, Sep 05, 2012 at 05:06:04PM +0530, Sourav Poddar wrote:
> +static struct regmap_config smsc_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .max_register = SMSC_MAX_REGISTER - 1;
That max_register setup looks very odd...
> + .cache_type = REGCACHE_COMPRESSED,
> +};
Are you sure the compressed type is sensible? It would normally only
make sense with a large number of closely packed registers but this
device has 8 bit register values.
> +#ifdef CONFIG_OF
> + of_property_read_u32(node, "clock", &smsc->clk);
> +#endif
> + ret = regmap_write(smsc->regmap, SMSC_CLK_CTRL, smsc->clk);
> + if (ret)
> + goto err;
What happens on non-DT systems?
> +static int smsc_i2c_remove(struct i2c_client *i2c)
> +{
> + return 0;
> +}
Remove empty functions, though it's rather surprising that there's
nothing at all to do here.. Normally an MFD would at least remove its
children.
--
To unsubscribe from this list: send the line "unsubscribe 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/6] ARM: OMAP2+: clean up PRCM sections of the Makefile
Clean up the PRCM sections of the Makefile; this saves a few lines. Signed-off-by: Paul Walmsley --- arch/arm/mach-omap2/Makefile | 35 ++- 1 file changed, 10 insertions(+), 25 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 89e0daf..eb203ec 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -88,67 +88,52 @@ obj-$(CONFIG_ARCH_OMAP4)+= cpuidle44xx.o endif # PRCM -omap-prcm-4-5-common = prcm.o cminst44xx.o cm44xx.o \ +obj-y += prcm.o prm_common.o +obj-$(CONFIG_ARCH_OMAP2) += cm2xxx_3xxx.o prm2xxx_3xxx.o +obj-$(CONFIG_ARCH_OMAP3) += cm2xxx_3xxx.o prm2xxx_3xxx.o +obj-$(CONFIG_ARCH_OMAP3) += vc3xxx_data.o vp3xxx_data.o +obj-$(CONFIG_SOC_AM33XX) += prm33xx.o cm33xx.o +omap-prcm-4-5-common = cminst44xx.o cm44xx.o prm44xx.o \ prcm_mpu44xx.o prminst44xx.o \ vc44xx_data.o vp44xx_data.o \ prm44xx.o -obj-y += prm_common.o -obj-$(CONFIG_ARCH_OMAP2) += prcm.o cm2xxx_3xxx.o prm2xxx_3xxx.o -obj-$(CONFIG_ARCH_OMAP3) += prcm.o cm2xxx_3xxx.o prm2xxx_3xxx.o -obj-$(CONFIG_ARCH_OMAP3) += vc3xxx_data.o vp3xxx_data.o -obj-$(CONFIG_SOC_AM33XX) += prcm.o prm33xx.o cm33xx.o -obj-$(CONFIG_ARCH_OMAP4) += $(omap-prcm-4-5-common) prm44xx.o +obj-$(CONFIG_ARCH_OMAP4) += $(omap-prcm-4-5-common) obj-$(CONFIG_SOC_OMAP5)+= $(omap-prcm-4-5-common) # OMAP voltage domains -voltagedomain-common := voltage.o vc.o vp.o -obj-$(CONFIG_ARCH_OMAP2) += $(voltagedomain-common) +obj-y += voltage.o vc.o vp.o obj-$(CONFIG_ARCH_OMAP2) += voltagedomains2xxx_data.o -obj-$(CONFIG_ARCH_OMAP3) += $(voltagedomain-common) obj-$(CONFIG_ARCH_OMAP3) += voltagedomains3xxx_data.o -obj-$(CONFIG_ARCH_OMAP4) += $(voltagedomain-common) obj-$(CONFIG_ARCH_OMAP4) += voltagedomains44xx_data.o -obj-$(CONFIG_SOC_AM33XX) += $(voltagedomain-common) obj-$(CONFIG_SOC_AM33XX) += voltagedomains33xx_data.o -obj-$(CONFIG_SOC_OMAP5)+= $(voltagedomain-common) # OMAP powerdomain framework -powerdomain-common += powerdomain.o powerdomain-common.o -obj-$(CONFIG_ARCH_OMAP2) += $(powerdomain-common) +obj-y += powerdomain.o powerdomain-common.o obj-$(CONFIG_ARCH_OMAP2) += powerdomains2xxx_data.o obj-$(CONFIG_ARCH_OMAP2) += powerdomain2xxx_3xxx.o obj-$(CONFIG_ARCH_OMAP2) += powerdomains2xxx_3xxx_data.o -obj-$(CONFIG_ARCH_OMAP3) += $(powerdomain-common) obj-$(CONFIG_ARCH_OMAP3) += powerdomain2xxx_3xxx.o obj-$(CONFIG_ARCH_OMAP3) += powerdomains3xxx_data.o obj-$(CONFIG_ARCH_OMAP3) += powerdomains2xxx_3xxx_data.o -obj-$(CONFIG_ARCH_OMAP4) += $(powerdomain-common) obj-$(CONFIG_ARCH_OMAP4) += powerdomain44xx.o obj-$(CONFIG_ARCH_OMAP4) += powerdomains44xx_data.o -obj-$(CONFIG_SOC_AM33XX) += $(powerdomain-common) obj-$(CONFIG_SOC_AM33XX) += powerdomain33xx.o obj-$(CONFIG_SOC_AM33XX) += powerdomains33xx_data.o -obj-$(CONFIG_SOC_OMAP5)+= $(powerdomain-common) obj-$(CONFIG_SOC_OMAP5)+= powerdomain44xx.o # PRCM clockdomain control -clockdomain-common += clockdomain.o -obj-$(CONFIG_ARCH_OMAP2) += $(clockdomain-common) +obj-y += clockdomain.o obj-$(CONFIG_ARCH_OMAP2) += clockdomain2xxx_3xxx.o obj-$(CONFIG_ARCH_OMAP2) += clockdomains2xxx_3xxx_data.o obj-$(CONFIG_SOC_OMAP2420) += clockdomains2420_data.o obj-$(CONFIG_SOC_OMAP2430) += clockdomains2430_data.o -obj-$(CONFIG_ARCH_OMAP3) += $(clockdomain-common) obj-$(CONFIG_ARCH_OMAP3) += clockdomain2xxx_3xxx.o obj-$(CONFIG_ARCH_OMAP3) += clockdomains2xxx_3xxx_data.o obj-$(CONFIG_ARCH_OMAP3) += clockdomains3xxx_data.o -obj-$(CONFIG_ARCH_OMAP4) += $(clockdomain-common) obj-$(CONFIG_ARCH_OMAP4) += clockdomain44xx.o obj-$(CONFIG_ARCH_OMAP4) += clockdomains44xx_data.o -obj-$(CONFIG_SOC_AM33XX) += $(clockdomain-common) obj-$(CONFIG_SOC_AM33XX) += clockdomain33xx.o obj-$(CONFIG_SOC_AM33XX) += clockdomains33xx_data.o -obj-$(CONFIG_SOC_OMAP5)+= $(clockdomain-common) obj-$(
[PATCH 5/6] ARM: OMAP2+: clean up OMAP clock Makefile sections
Clean up the OMAP clock code sections of the Makefile to save some lines of diff. Signed-off-by: Paul Walmsley --- arch/arm/mach-omap2/Makefile | 21 - 1 file changed, 8 insertions(+), 13 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index e9de8d2..89e0daf 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -6,9 +6,6 @@ obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer.o pm.o \ common.o gpio.o dma.o wd_timer.o display.o i2c.o hdq1w.o omap_hwmod.o -clock-common = clock.o clock_common_data.o \ - clkt_dpll.o clkt_clksel.o - # INTCPS IP block support - XXX should be moved to drivers/ obj-$(CONFIG_ARCH_OMAP2) += irq.o obj-$(CONFIG_ARCH_OMAP3) += irq.o @@ -155,24 +152,22 @@ obj-$(CONFIG_SOC_OMAP5) += $(clockdomain-common) obj-$(CONFIG_SOC_OMAP5)+= clockdomain44xx.o # Clock framework -obj-$(CONFIG_ARCH_OMAP2) += $(clock-common) clock2xxx.o -obj-$(CONFIG_ARCH_OMAP2) += clkt2xxx_sys.o -obj-$(CONFIG_ARCH_OMAP2) += clkt2xxx_dpllcore.o +obj-y += clock.o clock_common_data.o \ + clkt_dpll.o clkt_clksel.o +obj-$(CONFIG_ARCH_OMAP2) += clock2xxx.o +obj-$(CONFIG_ARCH_OMAP2) += clkt2xxx_dpllcore.o clkt2xxx_sys.o obj-$(CONFIG_ARCH_OMAP2) += clkt2xxx_virt_prcm_set.o obj-$(CONFIG_ARCH_OMAP2) += clkt2xxx_apll.o clkt2xxx_osc.o obj-$(CONFIG_ARCH_OMAP2) += clkt2xxx_dpll.o clkt_iclk.o obj-$(CONFIG_SOC_OMAP2420) += clock2420_data.o obj-$(CONFIG_SOC_OMAP2430) += clock2430.o clock2430_data.o -obj-$(CONFIG_ARCH_OMAP3) += $(clock-common) clock3xxx.o +obj-$(CONFIG_ARCH_OMAP3) += clock3xxx.o obj-$(CONFIG_ARCH_OMAP3) += clock34xx.o clkt34xx_dpll3m2.o -obj-$(CONFIG_ARCH_OMAP3) += clock3517.o clock36xx.o +obj-$(CONFIG_ARCH_OMAP3) += clock3517.o clock36xx.o clkt_iclk.o obj-$(CONFIG_ARCH_OMAP3) += dpll3xxx.o clock3xxx_data.o -obj-$(CONFIG_ARCH_OMAP3) += clkt_iclk.o -obj-$(CONFIG_ARCH_OMAP4) += $(clock-common) clock44xx_data.o +obj-$(CONFIG_ARCH_OMAP4) += clock44xx_data.o obj-$(CONFIG_ARCH_OMAP4) += dpll3xxx.o dpll44xx.o -obj-$(CONFIG_SOC_AM33XX) += $(clock-common) dpll3xxx.o -obj-$(CONFIG_SOC_AM33XX) += clock33xx_data.o -obj-$(CONFIG_SOC_OMAP5)+= $(clock-common) +obj-$(CONFIG_SOC_AM33XX) += dpll3xxx.o clock33xx_data.o obj-$(CONFIG_SOC_OMAP5)+= dpll3xxx.o dpll44xx.o # OMAP2 clock rate set data (old "OPP" data) -- To unsubscribe from this list: send the line "unsubscribe 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: OMAP2+: move MPU INTCPS, secure monitor, SDRC build directives in Makefile
Move MPU INTCPS (interrupt controller) and secure monitor code build directives to their own Makefile sections, for clarity. Coalesce SDRC-related Makefile directives into the SDRC Makefile section. Signed-off-by: Paul Walmsley --- arch/arm/mach-omap2/Makefile | 21 + 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index bdcf508..437ca322 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -6,23 +6,27 @@ obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer.o pm.o \ common.o gpio.o dma.o wd_timer.o display.o i2c.o hdq1w.o omap_hwmod.o -omap-2-3-common= irq.o clock-common = clock.o clock_common_data.o \ clkt_dpll.o clkt_clksel.o -secure-common = omap-smc.o omap-secure.o -obj-$(CONFIG_ARCH_OMAP2) += $(omap-2-3-common) -obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(secure-common) -obj-$(CONFIG_ARCH_OMAP4) += prm44xx.o $(secure-common) -obj-$(CONFIG_SOC_AM33XX) += irq.o -obj-$(CONFIG_SOC_OMAP5) += prm44xx.o $(secure-common) +# INTCPS IP block support - XXX should be moved to drivers/ +obj-$(CONFIG_ARCH_OMAP2) += irq.o +obj-$(CONFIG_ARCH_OMAP3) += irq.o +obj-$(CONFIG_SOC_AM33XX) += irq.o + +# Secure monitor API support +obj-$(CONFIG_ARCH_OMAP3) += omap-smc.o omap-secure.o +obj-$(CONFIG_ARCH_OMAP4) += omap-smc.o omap-secure.o +obj-$(CONFIG_SOC_OMAP5)+= omap-smc.o omap-secure.o + +obj-$(CONFIG_ARCH_OMAP4) += prm44xx.o +obj-$(CONFIG_SOC_OMAP5) += prm44xx.o ifneq ($(CONFIG_SND_OMAP_SOC_MCBSP),) obj-y += mcbsp.o endif obj-$(CONFIG_TWL4030_CORE) += omap_twl.o -obj-$(CONFIG_SOC_HAS_OMAP2_SDRC) += sdrc.o # SMP support ONLY available for OMAP4 @@ -56,6 +60,7 @@ obj-$(CONFIG_ARCH_OMAP4) += mux44xx.o # SMS/SDRC obj-$(CONFIG_ARCH_OMAP2) += sdrc2xxx.o # obj-$(CONFIG_ARCH_OMAP3) += sdrc3xxx.o +obj-$(CONFIG_SOC_HAS_OMAP2_SDRC) += sdrc.o # OPP table initialization ifeq ($(CONFIG_PM_OPP),y) -- To unsubscribe from this list: send the line "unsubscribe 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+: clean up OMAP4 PRM & sleep build directives in Makefile
The prm44xx.o and sleep44xx.o build directives belong with the other PRCM- and PM-related build sections in the Makefile; move them there. Signed-off-by: Paul Walmsley --- arch/arm/mach-omap2/Makefile | 18 +++--- 1 file changed, 7 insertions(+), 11 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 437ca322..e9de8d2 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -19,9 +19,6 @@ obj-$(CONFIG_ARCH_OMAP3) += omap-smc.o omap-secure.o obj-$(CONFIG_ARCH_OMAP4) += omap-smc.o omap-secure.o obj-$(CONFIG_SOC_OMAP5)+= omap-smc.o omap-secure.o -obj-$(CONFIG_ARCH_OMAP4) += prm44xx.o -obj-$(CONFIG_SOC_OMAP5) += prm44xx.o - ifneq ($(CONFIG_SND_OMAP_SOC_MCBSP),) obj-y += mcbsp.o endif @@ -32,10 +29,8 @@ obj-$(CONFIG_TWL4030_CORE) += omap_twl.o obj-$(CONFIG_SMP) += omap-smp.o omap-headsmp.o obj-$(CONFIG_HOTPLUG_CPU) += omap-hotplug.o -omap-4-5-common= omap4-common.o omap-wakeupgen.o \ - sleep44xx.o -obj-$(CONFIG_ARCH_OMAP4) += $(omap-4-5-common) -obj-$(CONFIG_SOC_OMAP5)+= $(omap-4-5-common) +obj-$(CONFIG_ARCH_OMAP4) += omap4-common.o omap-wakeupgen.o +obj-$(CONFIG_SOC_OMAP5)+= omap4-common.o omap-wakeupgen.o plus_sec := $(call as-instr,.arch_extension sec,+sec) AFLAGS_omap-headsmp.o :=-Wa,-march=armv7-a$(plus_sec) @@ -71,11 +66,11 @@ endif # Power Management ifeq ($(CONFIG_PM),y) -obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o -obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o +obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o sleep24xx.o obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o omap-mpuss-lowpower.o -obj-$(CONFIG_SOC_OMAP5)+= omap-mpuss-lowpower.o +obj-$(CONFIG_ARCH_OMAP4) += sleep44xx.o +obj-$(CONFIG_SOC_OMAP5)+= omap-mpuss-lowpower.o sleep44xx.o obj-$(CONFIG_PM_DEBUG) += pm-debug.o obj-$(CONFIG_POWER_AVS_OMAP) += sr_device.o @@ -98,7 +93,8 @@ endif # PRCM omap-prcm-4-5-common = prcm.o cminst44xx.o cm44xx.o \ prcm_mpu44xx.o prminst44xx.o \ - vc44xx_data.o vp44xx_data.o + vc44xx_data.o vp44xx_data.o \ + prm44xx.o obj-y += prm_common.o obj-$(CONFIG_ARCH_OMAP2) += prcm.o cm2xxx_3xxx.o prm2xxx_3xxx.o obj-$(CONFIG_ARCH_OMAP3) += prcm.o cm2xxx_3xxx.o prm2xxx_3xxx.o -- To unsubscribe from this list: send the line "unsubscribe 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: OMAP2+: clean up whitespace in Makefile
Convert spaces that should be tabs into tabs. Fix another minor formatting issue. Signed-off-by: Paul Walmsley --- arch/arm/mach-omap2/Makefile | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index f6a24b3..22ee340 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -23,7 +23,7 @@ ifneq ($(CONFIG_SND_OMAP_SOC_MCBSP),) obj-y += mcbsp.o endif -obj-$(CONFIG_TWL4030_CORE) += omap_twl.o +obj-$(CONFIG_TWL4030_CORE) += omap_twl.o obj-$(CONFIG_SOC_HAS_OMAP2_SDRC) += sdrc.o # SMP support ONLY available for OMAP4 @@ -76,7 +76,7 @@ obj-$(CONFIG_SOC_OMAP5) += omap-mpuss-lowpower.o obj-$(CONFIG_PM_DEBUG) += pm-debug.o obj-$(CONFIG_POWER_AVS_OMAP) += sr_device.o -obj-$(CONFIG_POWER_AVS_OMAP_CLASS3)+= smartreflex-class3.o +obj-$(CONFIG_POWER_AVS_OMAP_CLASS3)+= smartreflex-class3.o AFLAGS_sleep24xx.o :=-Wa,-march=armv6 AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a$(plus_sec) @@ -88,8 +88,8 @@ endif endif ifeq ($(CONFIG_CPU_IDLE),y) -obj-$(CONFIG_ARCH_OMAP3)+= cpuidle34xx.o -obj-$(CONFIG_ARCH_OMAP4)+= cpuidle44xx.o +obj-$(CONFIG_ARCH_OMAP3) += cpuidle34xx.o +obj-$(CONFIG_ARCH_OMAP4) += cpuidle44xx.o endif # PRCM @@ -113,7 +113,7 @@ obj-$(CONFIG_ARCH_OMAP3)+= voltagedomains3xxx_data.o obj-$(CONFIG_ARCH_OMAP4) += $(voltagedomain-common) obj-$(CONFIG_ARCH_OMAP4) += voltagedomains44xx_data.o obj-$(CONFIG_SOC_AM33XX) += $(voltagedomain-common) -obj-$(CONFIG_SOC_AM33XX)+= voltagedomains33xx_data.o +obj-$(CONFIG_SOC_AM33XX) += voltagedomains33xx_data.o obj-$(CONFIG_SOC_OMAP5)+= $(voltagedomain-common) # OMAP powerdomain framework @@ -229,10 +229,10 @@ obj-$(CONFIG_MACH_OMAP_H4)+= board-h4.o obj-$(CONFIG_MACH_OMAP_2430SDP)+= board-2430sdp.o obj-$(CONFIG_MACH_OMAP_APOLLON)+= board-apollon.o obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o -obj-$(CONFIG_MACH_DEVKIT8000) += board-devkit8000.o +obj-$(CONFIG_MACH_DEVKIT8000) += board-devkit8000.o obj-$(CONFIG_MACH_OMAP_LDP)+= board-ldp.o -obj-$(CONFIG_MACH_OMAP3530_LV_SOM) += board-omap3logic.o -obj-$(CONFIG_MACH_OMAP3_TORPEDO)+= board-omap3logic.o +obj-$(CONFIG_MACH_OMAP3530_LV_SOM) += board-omap3logic.o +obj-$(CONFIG_MACH_OMAP3_TORPEDO) += board-omap3logic.o obj-$(CONFIG_MACH_ENCORE) += board-omap3encore.o obj-$(CONFIG_MACH_OVERO) += board-overo.o obj-$(CONFIG_MACH_OMAP3EVM)+= board-omap3evm.o -- To unsubscribe from this list: send the line "unsubscribe 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+: clean up omap_hwmod.o build directives in Makefile
Move the omap_hwmod_common_data.o build directive down to the hwmod data Makefile section where it belongs. Move the omap_hwmod.o build directive to the top 'Common support' line, since we have no separate hwmod code Makefile section, and it's currently needed for all OMAP2+. Signed-off-by: Paul Walmsley --- arch/arm/mach-omap2/Makefile | 15 +++ 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 22ee340..bdcf508 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -4,20 +4,18 @@ # Common support obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer.o pm.o \ -common.o gpio.o dma.o wd_timer.o display.o i2c.o hdq1w.o +common.o gpio.o dma.o wd_timer.o display.o i2c.o hdq1w.o omap_hwmod.o omap-2-3-common= irq.o -hwmod-common = omap_hwmod.o \ - omap_hwmod_common_data.o clock-common = clock.o clock_common_data.o \ clkt_dpll.o clkt_clksel.o secure-common = omap-smc.o omap-secure.o -obj-$(CONFIG_ARCH_OMAP2) += $(omap-2-3-common) $(hwmod-common) -obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(hwmod-common) $(secure-common) -obj-$(CONFIG_ARCH_OMAP4) += prm44xx.o $(hwmod-common) $(secure-common) -obj-$(CONFIG_SOC_AM33XX) += irq.o $(hwmod-common) -obj-$(CONFIG_SOC_OMAP5) += prm44xx.o $(hwmod-common) $(secure-common) +obj-$(CONFIG_ARCH_OMAP2) += $(omap-2-3-common) +obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(secure-common) +obj-$(CONFIG_ARCH_OMAP4) += prm44xx.o $(secure-common) +obj-$(CONFIG_SOC_AM33XX) += irq.o +obj-$(CONFIG_SOC_OMAP5) += prm44xx.o $(secure-common) ifneq ($(CONFIG_SND_OMAP_SOC_MCBSP),) obj-y += mcbsp.o @@ -181,6 +179,7 @@ obj-$(CONFIG_SOC_OMAP2420) += opp2420_data.o obj-$(CONFIG_SOC_OMAP2430) += opp2430_data.o # hwmod data +obj-y += omap_hwmod_common_data.o obj-$(CONFIG_SOC_OMAP2420) += omap_hwmod_2xxx_ipblock_data.o obj-$(CONFIG_SOC_OMAP2420) += omap_hwmod_2xxx_3xxx_ipblock_data.o obj-$(CONFIG_SOC_OMAP2420) += omap_hwmod_2xxx_interconnect_data.o -- To unsubscribe from this list: send the line "unsubscribe 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: OMAP2+: clean up the Makefile
This series, intended for 3.7 cleanup, cleans up the Makefile in arch/arm/mach-omap2. It places PRCM-related lines in the PRCM sections, clock lines in the clock sections, etc.; and fixes some formatting and whitespace. This is meant to serve as a base for future cleanups to avoid conflicts as lines get removed. Boot and build test logs can be found at: http://www.pwsan.com/omap/testlogs/makefile_cleanup_3.7/20120905143119/ - Paul --- object size (delta in bytes from test_v3.6-rc4 (4cbe5a555fa58a79b6ecbb6c531b8bab0650778d)): textdata bss total kernel 0 0 0 0 2430_testconfig 0 0 0 0 5912osk_testconfig 0 0 0 0 am33xx_testconfig +8 0 0 +8 n800_b_testconfig +8 0 0 +8 n800_multi_omap2xxx +8 0 0 +8 n800_testconfig 0 0 0 0 omap1510_defconfig 0 0 0 0 omap1_defconfig +32 0 0 +32 omap2_4_testconfig +8 0 0 +8 omap2plus_defconfig +16 0 0 +16 omap2plus_no_pm -8 0 0 -8 omap3_4_testconfig -56 0 0 -56 omap3_testconfig 0 0 0 0 omap4_testconfig 0 0 0 0 rmk_omap3430_ldp_oldconfig 0 0 0 0 rmk_omap4430_sdp_oldconfig Paul Walmsley (6): ARM: OMAP2+: clean up whitespace in Makefile ARM: OMAP2+: clean up omap_hwmod.o build directives in Makefile ARM: OMAP2+: move MPU INTCPS, secure monitor, SDRC build directives in Makefile ARM: OMAP2+: clean up OMAP4 PRM & sleep build directives in Makefile ARM: OMAP2+: clean up OMAP clock Makefile sections ARM: OMAP2+: clean up PRCM sections of the Makefile arch/arm/mach-omap2/Makefile | 108 +- 1 file changed, 44 insertions(+), 64 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.6-rc4
Hi, On Sat, 8 Sep 2012, Andreas Müller wrote: > On Wed, Sep 5, 2012 at 5:44 PM, Paul Walmsley wrote: > > > > Here are some basic boot and power management test results for v3.6-rc4: > > > > http://www.pwsan.com/omap/testlogs/test_v3.6-rc4/20120904122415/ > > > > Some observations: > > > > * N800: panics during kernel init > > - This is caused by an MMC driver bug; fixed by "[PATCH] MMC: OMAP MSDI: > > fix broken PIO mode", available from here: > > http://www.spinics.net/lists/arm-kernel/msg190879.html > > > > * CM-T3517: L3 in-band error with USB OTG during boot > > - Cause unknown; longstanding issue; does not occur on the 3517EVM > > > > * 37xx EVM: CORE not entering dynamic off-idle > > - Cause unknown; dynamic retention-idle seems to work; system suspend to > > off works > > > > * 4430ES2 Panda: CORE, L4PER, L3INIT, TESLA, IVAHD not going idle > > - Cause unknown; may be partially due to McPDM reset problem > > > > (The objective in posting these is to determine what is and isn't working > > in the mainline releases, as well as to make it easier to determine what > > is fixed or is broken by subsequent series that use this as a base.) > > > I did not find that - maybe I missed something: Could you also store > the resulting configs of theses tests? Which one didn't you find? :-) The configs I use are available at git://git.pwsan.com/omap_kconfigs Before the builds, 'make oldnoconfig' is run. Please note that the format of this repo is experimental, subject to change, etc. etc. Probably I should include the configs in the build result trees... - Paul
Re: OMAP baseline test results for v3.6-rc4
On Wed, Sep 5, 2012 at 5:44 PM, Paul Walmsley wrote: > > Here are some basic boot and power management test results for v3.6-rc4: > > http://www.pwsan.com/omap/testlogs/test_v3.6-rc4/20120904122415/ > > Some observations: > > * N800: panics during kernel init > - This is caused by an MMC driver bug; fixed by "[PATCH] MMC: OMAP MSDI: > fix broken PIO mode", available from here: > http://www.spinics.net/lists/arm-kernel/msg190879.html > > * CM-T3517: L3 in-band error with USB OTG during boot > - Cause unknown; longstanding issue; does not occur on the 3517EVM > > * 37xx EVM: CORE not entering dynamic off-idle > - Cause unknown; dynamic retention-idle seems to work; system suspend to > off works > > * 4430ES2 Panda: CORE, L4PER, L3INIT, TESLA, IVAHD not going idle > - Cause unknown; may be partially due to McPDM reset problem > > (The objective in posting these is to determine what is and isn't working > in the mainline releases, as well as to make it easier to determine what > is fixed or is broken by subsequent series that use this as a base.) > I did not find that - maybe I missed something: Could you also store the resulting configs of theses tests? Andreas -- To unsubscribe from this list: send the line "unsubscribe 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] gpio/omap: fix possible memory leak in omap2_gpio_dev_init()
Tony Lindgren writes: > * Kevin Hilman [120907 15:07]: >> Wei Yongjun writes: >> >> > From: Wei Yongjun >> > >> > pdata and pdata->regs have been allocated in this function and >> > should be freed before leaving it, and in the other error handling >> > cases too. >> > >> > spatch with a semantic match is used to found this problem. >> > (http://coccinelle.lip6.fr/) >> > >> > Signed-off-by: Wei Yongjun >> >> Acked-by: Kevin Hilman >> >> Tony, can you pick this one up for fixes? > > Sure, is fixes-noncritical OK for this one? Yes. 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 0/5] arm: omap: debug-leds: few changes
* Felipe Balbi [120724 02:02]: > Hi Tony, > > here are a few changes for the debug-leds driver. This series tries to get the > driver closer to be moved away from arch/arm/plat-omap/ and under > drivers/leds. > There's only the dependency with now. > > I tried moving the needed definitions into the C file, but there's another > file > which uses the same structure (arch/arm/mach-omap1/leds-h2p2-debug.c) so I > left > it for another series. Ideally, omap1 would be using the same debug-leds > driver > for that purpose and we could drop the dependency on . > > BTW, patches were compile tested only due to the lack of an H4 board. > > Felipe Balbi (5): > arm: omap: debug-leds: drop machine_is_* checks > arm: omap: debug-leds: move initialization to debug-leds > arm: omap: debug-leds: add section annotation to probe > arm: omap: debug-leds: add a remove method > arm: omap: debug-leds: switch to resource_size() > > arch/arm/plat-omap/debug-leds.c | 37 +++-- > 1 file changed, 23 insertions(+), 14 deletions(-) Sorry for forgetting this series.. Found it after shrinking my inbox to a more readable size :) There are some good changes in linux-next that remove most of the debug-leds code. Maybe take a quick look what can be rebased on those to make it into a reald driver? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/8] ARM/dts: omap2: Add McBSP entries for OMAP2420 and OMAP2430 SoC
* Peter Ujfalusi [120905 04:59]:
> +
> + ocp {
> + mcbsp1: mcbsp@48074000 {
> + compatible = "ti,omap2420-mcbsp";
> + reg = <0x48074000 0xff>;
> + reg-names = "mpu";
> + interrupts = <59>, /* TX interrupt */
> + <60>; /* RX interrupt */
> + interrupt-names = "tx", "rx";
> + interrupt-parent = <&intc>;
> + ti,hwmods = "mcbsp1";
> + };
> +
> + mcbsp2: mcbsp@48076000 {
> + compatible = "ti,omap2420-mcbsp";
> + reg = <0x48076000 0xff>;
> + reg-names = "mpu";
> + interrupts = <62>, /* TX interrupt */
> + <63>; /* RX interrupt */
> + interrupt-names = "tx", "rx";
> + interrupt-parent = <&intc>;
> + ti,hwmods = "mcbsp2";
> + };
> + };
Hmm don't you need to specify the interrupt chip and offset for
the interrupts here?
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] gpio/omap: fix possible memory leak in omap2_gpio_dev_init()
* Kevin Hilman [120907 15:07]: > Wei Yongjun writes: > > > From: Wei Yongjun > > > > pdata and pdata->regs have been allocated in this function and > > should be freed before leaving it, and in the other error handling > > cases too. > > > > spatch with a semantic match is used to found this problem. > > (http://coccinelle.lip6.fr/) > > > > Signed-off-by: Wei Yongjun > > Acked-by: Kevin Hilman > > Tony, can you pick this one up for fixes? Sure, is fixes-noncritical OK for this one? Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/10] ARM: OMAP: Clean-up timer posted mode support
* Jon Hunter [120905 12:05]: > The dmtimer functions to read and write the dmtimer registers are currently > defined as follows ... > > static inline u32 __omap_dm_timer_read(struct omap_dm_timer *timer, u32 reg, > int posted); > static inline void __omap_dm_timer_write(struct omap_dm_timer *timer, > u32 reg, u32 val, int posted); > > The posted variable indicates if the timer is configured to use the posted > mode > when performing register accesses. The posted mode configuration of the > dmtimer > is stored in the omap_dm_timer structure that is also being passed to the > above > functions and therefore we do not need to pass the posted variable separately. > Therefore, simplify the above functions by removing the posted variable as an > argument as this is not necessary. I believe the reason for passing the posted flag was to optimize out some functions from the timer code as that's being run all the time. Care to check the assembly before and after this patch for the timer functions with objdump -d to make sure it does not add tons of bloat there? Thanks, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 0/3] GPMC driver conversion
* Afzal Mohammed [120905 05:37]: > Hi, > > Basic gpmc driver conversion series. Driver that is now created out of > gpmc code is a simple one, it handles tasks that were earlier executed > by gpmc_init. Now instead of relying on cpu_is_* checks, it obtains > resources and clk handle in the standard Linux way. The existing gpmc > interface works as was without this series. > > HWMOD patch also has been brought into this series back with v7 series > > As this creates only a basic driver, further gpmc driver work can be > based over this, while having a driver first in place. > > This series is based on l-o/testing-cleanup as on 5-Sep-12, > i.e. over commit, > > e3a5c14 ARM: OMAP1: Move SoC specific headers from plat to mach for omap1 > > per Tony's suggestion. > > It is available > @git://gitorious.org/x0148406-public/linux-kernel.git gpmc-drv-v8 Great, this all looks good to me. I suggest that on top of this we add minimal devicetree binding that does not even attempt to deal with the timings yet. Then once the minimal devicetree binding is in place, we can call the current GPMC timing functions using the compatible flags and auxdata in the gpmc.c driver. That way we get all the legacy boards booting with GPMC support for smsc911x etc, and can even remove some less used board-*.c files. Then we just add the generic GPMC timings when we're happy with those. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap fixes for v3.6-rc4
On Thu, Sep 06, 2012 at 08:57:40PM -0700, Tony Lindgren wrote: > The following changes since commit 4cbe5a555fa58a79b6ecbb6c531b8bab0650778d: > > Linux 3.6-rc4 (2012-09-01 10:39:58 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap > tags/omap-fixes-for-v3.6-rc4 > > for you to fetch changes up to 6ab019b62e0505289b26bd00d997dc7686192fa4: > > Merge tag 'omap-fixes-a-for-3.6rc' of > git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into fixes > (2012-09-05 10:09:31 -0700) Pulled, thanks! -Olof -- To unsubscribe from this list: send the line "unsubscribe 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] gpio/omap: fix possible memory leak in omap2_gpio_dev_init()
Wei Yongjun writes: > From: Wei Yongjun > > pdata and pdata->regs have been allocated in this function and > should be freed before leaving it, and in the other error handling > cases too. > > spatch with a semantic match is used to found this problem. > (http://coccinelle.lip6.fr/) > > Signed-off-by: Wei Yongjun Acked-by: Kevin Hilman Tony, can you pick this one up for fixes? 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 v2] leds: leds-gpio: adopt pinctrl support
On Fri, Sep 7, 2012 at 6:35 PM, Tony Lindgren wrote: > In the pure GPIO pins only case it could be all done in the GPIO controller, > but it's probably best to have the pins muxed by the drivers using them. Yes, that's an easier way to say the long unreadable thing I just posted ... > Some drivers doing runtime PM may need to dynamically toggle the pins > for idle mode to stop leakage, enable wakeup events for rx pins etc. > Probably no need for that in the gpio leds case, but it would be confusing > to have some pins claimed by the GPIO driver and some by the drivers > using the pins. True. drivers/tty/serial/amba-pl011.c provides a simple example. 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: [PATCHv2 1/2] mmc: omap_hsmmc: convert from IP timer to hrtimer
Venkatraman S writes: > omap hsmmc controller IP has a built in timer that can be programmed to > guard against unresponsive operations. But its range is very narrow, > and the maximum countable time is a few seconds. > > Card maintenance operations like BKOPS and MMC_ERASE and long > stream writes like packed command require timers of order of > several minutes, much beyond the capability of the IP timer. > So get rid of using the IP timer entirely and use kernel's hrtimer > functionality for guarding the device operations. > As part of this change, a workaround that disabled timeouts for > MMC_ERASE command is removed, and the arbitary timing of 100ms > is used only when the timeout is not explicitly specified by core. > > A trivial change to get rid of unnecessary dealiasing of host->data > in omap_hsmmc_do_irq is also included. > > Signed-off-by: Venkatraman S Dumb question: if the timers needed are on the order of minutes, why do you need to use high-resolution timers? I'm guessing the normal kernel-internal timers should suffice here (see http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] leds: leds-gpio: adopt pinctrl support
On Fri, Sep 7, 2012 at 6:00 PM, Domenico Andreoli wrote: > On Fri, Sep 07, 2012 at 02:30:59PM +, AnilKumar, Chimata wrote: >> How can gpio driver knows that leds-gpio driver require >> these 4 pins? > > because leds-gpio requests each gpio (specified in the DT against a specific > gpio controller) before assuming it is available? gpiolib then asks to > pinctrl if those pins are available for gpio and possibly reserve them > (configuring the mux, if necessary) for the device. So this is not an either-or situation but a both-and case. So all muxing and configuration of pins can be handled by the pinctrl handle, and that may require setting up a single pinctrl function for every single pin, and that list can get long. But it works fine. In that case you don't write your pinctrl driver to do anything special with the GPIO callbacks, leave the .gpio_request_enable(), .gpio_disable_free() and .gpio_set_direction() callbacks in the vtable undefined. If all you need to to is to multiplex the pins into GPIO mode, then the gpio_get() call on this driver *can* call through to pinctrl_request_gpio() which will in turn fall through to the above pinmux driver calls (.gpio_request_enable, etc). Likewise for pinctrl_free_gpio(), pinctrl_gpio_direction_input() and pinctrl_gpio_direction_output(). But that's as far as it goes! The GPIO abstraction cannot call through to e.g. set some specific biasing on the pins (pull up etc). Doing that would require us to reimplement every interface that pinctrl already has again in the GPIO layer, which is not a good idea. So the pinctrl handle can be used for such config, and it can also be used for multiplexing if that is desired - if not done by the fall through functions pinctrl_gpio_*(). You can use a combination of both too, Stephen patched pinctrl some time back so that a pin can be muxed for a certain function and used as GPIO at the same time, so these two are now orthogonal, it's a bit relaxed and gives some feeling of loss of control but was necessary for certain usecases. (For example we can snoop on a I2C pin using its corresponding GPIO registers in the U300...) There is some flexibility here, I hope it's not too confusing :-/ 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] perf: Use pre-empt safe cpu_get/put insted of smp_processor_id
Roger Quadros writes:
> Hi Jean,
>
> My bad, I didn't follow up with this. My guess is that it has not been
> picked up. Tony, Kevin?
>
Wasn't picked up by me (but should've been, sorry.) Care to refresh
against v3.6-rc4 and resend?
Thanks,
Kevin
>
> On 09/06/2012 09:59 PM, Jean Pihet wrote:
>> Fixed Paul's email address
>>
>> On Thu, Sep 6, 2012 at 8:56 PM, Jean Pihet wrote:
>>> Hi Roger,
>>>
>>> On Fri, Aug 10, 2012 at 4:05 PM, Roger Quadros wrote:
gets rid of below messages with CONFIG_DEBUG_PREEMPT enabled
[ 28.832916] debug_smp_processor_id: 18 callbacks suppressed
[ 28.832946] BUG: using smp_processor_id() in preemptible []
code: modprobe/1763
[ 28.841491] caller is pwrdm_set_next_pwrst+0x54/0x120
Signed-off-by: Roger Quadros
>>>
>>> What his the status of the patch? Has it been reviewed and taken in an
>>> integration tree? I cannot find anything about it in l-o and
>>> linux-next.
>>>
>>> I have some changes on-going in the OMAP PM code and I would like to
>>> know if $SUBJECT is applicable.
>>>
>>> Regards,
>>> Jean
>>>
---
arch/arm/mach-omap2/clock.c |9 ++---
arch/arm/mach-omap2/pm34xx.c | 12
arch/arm/mach-omap2/powerdomain.c |6 --
3 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index ea3f565..06747b6 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -285,7 +285,8 @@ void omap2_clk_disable(struct clk *clk)
pr_debug("clock: %s: disabling in hardware\n", clk->name);
if (clk->ops && clk->ops->disable) {
- trace_clock_disable(clk->name, 0, smp_processor_id());
+ trace_clock_disable(clk->name, 0, get_cpu());
+ put_cpu();
clk->ops->disable(clk);
}
@@ -339,7 +340,8 @@ int omap2_clk_enable(struct clk *clk)
}
if (clk->ops && clk->ops->enable) {
- trace_clock_enable(clk->name, 1, smp_processor_id());
+ trace_clock_enable(clk->name, 1, get_cpu());
+ put_cpu();
ret = clk->ops->enable(clk);
if (ret) {
WARN(1, "clock: %s: could not enable: %d\n",
@@ -380,7 +382,8 @@ int omap2_clk_set_rate(struct clk *clk, unsigned long
rate)
/* dpll_ck, core_ck, virt_prcm_set; plus all clksel clocks */
if (clk->set_rate) {
- trace_clock_set_rate(clk->name, rate, smp_processor_id());
+ trace_clock_set_rate(clk->name, rate, get_cpu());
+ put_cpu();
ret = clk->set_rate(clk, rate);
}
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index e4fc88c..81fec2e 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -357,18 +357,22 @@ void omap_sram_idle(void)
static void omap3_pm_idle(void)
{
+ unsigned cpu;
+
local_fiq_disable();
if (omap_irq_pending())
goto out;
- trace_power_start(POWER_CSTATE, 1, smp_processor_id());
- trace_cpu_idle(1, smp_processor_id());
+ cpu = get_cpu();
+ trace_power_start(POWER_CSTATE, 1, cpu);
+ trace_cpu_idle(1, cpu);
omap_sram_idle();
- trace_power_end(smp_processor_id());
- trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id());
+ trace_power_end(cpu);
+ trace_cpu_idle(PWR_EVENT_EXIT, cpu);
+ put_cpu();
out:
local_fiq_enable();
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 69b36e1..138bf86 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -169,7 +169,8 @@ static int _pwrdm_state_switch(struct powerdomain
*pwrdm, int flag)
((state & OMAP_POWERSTATE_MASK) <<
8) |
((prev & OMAP_POWERSTATE_MASK) <<
0));
trace_power_domain_target(pwrdm->name, trace_state,
- smp_processor_id());
+ get_cpu());
+ put_cpu();
}
break;
default:
@@ -491,7 +492,8 @@ int pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8
pwrst)
if (arch_pwrdm && arch_pwrdm->pwrdm_set_next_pwrst) {
/* Trace the pwrdm desired target state */
trace_power_domain_target
Re: [PATCHv4 4/8] ARM: OMAP3: add manual control for mpu / core pwrdm usecounting
Tero Kristo writes: > On Mon, 2012-08-06 at 12:14 +0200, Jean Pihet wrote: >> Hi Tero, >> >> On Mon, Jul 30, 2012 at 10:40 AM, Tero Kristo wrote: >> > On Fri, 2012-07-27 at 12:36 -0700, Kevin Hilman wrote: >> >> Tero Kristo writes: >> >> >> >> > mpu / core powerdomain usecounts are now statically increased >> >> > by 1 during MPU activity. This allows the domains to reflect >> >> > actual usage, and will allow the usecount to reach 0 just before >> >> > all CPUs are ready to idle. Proper powerdomain usecounts are >> >> > propageted to voltagedomain level also, and will allow vc >> >> > callbacks to be triggered at right point of time. >> >> > >> >> > Signed-off-by: Tero Kristo >> >> > Cc: Paul Walmsley >> >> > Cc: Kevin Hilman >> >> >> >> IMO, the idea is fine, but I'm not crazy about the implementation in >> >> powerdomain.c, which is meant for pwrdm generic code. In particular, >> >> I'm not crazy about the pwrdm lookups in powerdomain.c. >> >> >> >> Since pm.c already has references to mpu_pwrdm and core_pwrdm, why >> >> not just add the pwrdm_clkdm_enable/disable calls directly in pm.c >> > >> > I think this was how the patch was in some earlier rev but I thought I'd >> > try to be more clever with this. :) I can revert the implementation back >> > to this. >> Furthermore after the changes in pre/post transitions [1], some more >> checks will be needed to identify the transitions on the mpu and core >> power domains. >> >> [1] >> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=e055548953355b6e69c56f9e54388845b29b4e97 >> >> Regards, >> Jean > > Hi Kevin, > > What is the latest status regarding this one, seeing the patch mentioned > got reverted due to problems? Should I do some changes for this or not? No, using latest minline should be fine. > I can look at moving the code away from the generic powerdomain.c at > least, but is there anything else? Nothing else I can think of (but my vacation has purged my brain of most of the details here, so I may be forgetting something.) 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] leds: leds-gpio: adopt pinctrl support
* Linus Walleij [120907 14:40]: > On Thu, Sep 6, 2012 at 7:45 PM, Tony Lindgren wrote: > > >> > The warning should be pinctrl related as the pinctrl drivers may not be > >> > device tree based drivers. > >> > >> Exactly my concern. Also the warning shouldnt be present on systems where > >> pinctrl is disabled. > > > > But pinctrl_get_select() returns 0 in include/linux/pinctrl/consumer.h if > > CONFIG_PINCTRL is not selected, so no warning is produced AFAIK ;) > > This is correct, nothing to worry about. > > The one troublesome case is if a pinctrl driver is present but not > being used, then you might need to call pinctrl_provide_dummies(). Thanks that's good to know. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] leds: leds-gpio: adopt pinctrl support
On Thu, Sep 6, 2012 at 7:45 PM, Tony Lindgren wrote: >> > The warning should be pinctrl related as the pinctrl drivers may not be >> > device tree based drivers. >> >> Exactly my concern. Also the warning shouldnt be present on systems where >> pinctrl is disabled. > > But pinctrl_get_select() returns 0 in include/linux/pinctrl/consumer.h if > CONFIG_PINCTRL is not selected, so no warning is produced AFAIK ;) This is correct, nothing to worry about. The one troublesome case is if a pinctrl driver is present but not being used, then you might need to call pinctrl_provide_dummies(). 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 1/2] pinctrl: pinctrl-single: Make sure we do not change bits outside of mask
* Linus Walleij [120907 14:13]:
> On Thu, Sep 6, 2012 at 8:59 PM, Tony Lindgren wrote:
> > * Peter Ujfalusi [120905 02:02]:
> >> Use the pcs->fmask to make sure that the value is not changing (setting)
> >> bits in areas where it should not.
> >> To avoid situations like this:
> >>
> >> pmx_dummy: pinmux@4a100040 {
> >> compatible = "pinctrl-single";
> >> reg = <0x4a100040 0x0196>;
> >> #address-cells = <1>;
> >> #size-cells = <0>;
> >> pinctrl-single,register-width = <16>;
> >> pinctrl-single,function-mask = <0x00ff>;
> >> };
> >>
> >> &pmx_dummy {
> >> pinctrl-names = "default";
> >> pinctrl-0 = <&board_pins>;
> >>
> >> board_pins: pinmux_board_pins {
> >> pinctrl-single,pins = <
> >> 0x6c 0xf0f
> >> 0x6e 0x10f
> >> 0x70 0x23f
> >> 0x72 0xa5f
> >> >;
> >> };
> >> };
> >>
> >> Signed-off-by: Peter Ujfalusi
> >
> > Thanks this is a valid fix:
> >
> > Acked-by: Tony Lindgren
>
> Since nothing in v3.6 is using pinctrl-simple yet, it's not a regression
> right?
Right.
> So can you just group this with the other pinctrl things you are
> harvesting in the OMAP tree? I was going to push it for
> the v3.7 cycle otherwise.
You can take this for v3.7, the changes I have are just adding .dts
entries to use the driver. The driver related changes are being
merged by the related driver lists.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP GPIO - don't wake from suspend unless requested.
Hi Neil,
NeilBrown writes:
> On Thu, 6 Sep 2012 11:18:09 +0530 "Shilimkar, Santosh"
> wrote:
>
>> On Thu, Sep 6, 2012 at 8:35 AM, NeilBrown wrote:
>> > On Mon, 3 Sep 2012 22:59:06 -0700 "Shilimkar, Santosh"
>> > wrote:
>
>> >> After thinking bit more on this, the problem seems to be coming
>> >> mainly because the gpio device is runtime suspended bit early than
>> >> it should be. Similar issue seen with i2c driver as well. The i2c issue
>> >> was discussed with Rafael at LPC last week. The idea is to move
>> >> the pm_runtime_enable/disable() calls entirely up to the
>> >> _late/_early stage of device suspend/resume.
>> >> Will update this thread once I have further update.
>> >
>> > This won't be late enough. IRQCHIP_MASK_ON_SUSPEND takes effect after all
>> > the _late callbacks have been called.
>> > I, too, spoke to Rafael about this in San Diego. He seemed to agree with
>> > me
>> > that the interrupt needs to be masked in the ->suspend callback. any later
>> > is too late.
>> >
>> Thanks for information about your discussion. Will wait for the patch then.
>>
>> Regards
>> santosh
>
> I already sent a patch - that is what started this thread :-)
>
> I include it below.
> You said "The patch doesn't seems to be correct" but didn't expand on why.
> Do you still think it is not correct? I wouldn't be surprised if there is
> some case that it doesn't handle quite right, but it seems right to me.
>
> Thanks,
> NeilBrown
>
>
> From: NeilBrown
> Subject: [PATCH] OMAP GPIO - don't wake from suspend unless requested.
>
> Current kernel will wake from suspend on an event on any active
> GPIO even if enable_irq_wake() wasn't called.
>
> There are two reasons that the hardware wake-enable bit should be set:
>
> 1/ while non-suspended the CPU might go into a deep sleep (off_mode)
> in which the wake-enable bit is needed for an interrupt to be
> recognised.
> 2/ while suspended the GPIO interrupt should wake from suspend if and
>only if irq_wake as been enabled.
>
> The code currently doesn't keep these two reasons separate so they get
> confused and sometimes the wakeup flags is set incorrectly.
>
> This patch reverts:
> commit 9c4ed9e6c01e7a8bd9079da8267e1f03cb4761fc
> gpio/omap: remove suspend/resume callbacks
> and
> commit 0aa2727399c0b78225021413022c164cb99fbc5e
> gpio/omap: remove suspend_wakeup field from struct gpio_bank
>
> and makes some minor changes so that we have separate flags for "GPIO
> should wake from deep idle" and "GPIO should wake from suspend".
>
> With this patch, the GPIO from my touch screen doesn't wake my device
> any more, which is what I want.
I think the direction is right here. We never should've separated the
handling of idle vs suspend wakeups. However, I have a few
questions/doubts below...
> Cc: Kevin Hilman
> Cc: Tony Lindgren
> Cc: Santosh Shilimkar
> Cc: Cousson Benoit
> Cc: Grant Likely
> Cc: Tarun Kanti DebBarma
> Cc: Felipe Balbi
> Cc: Govindraj.R
>
> Signed-off-by: NeilBrown
>
> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> index 4fbc208..fdbad70 100644
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -57,6 +57,7 @@ struct gpio_bank {
> u16 irq;
> int irq_base;
> struct irq_domain *domain;
> + u32 suspend_wakeup;
> u32 non_wakeup_gpios;
> u32 enabled_non_wakeup_gpios;
> struct gpio_regs context;
> @@ -522,11 +523,12 @@ static int _set_gpio_wakeup(struct gpio_bank *bank, int
> gpio, int enable)
>
> spin_lock_irqsave(&bank->lock, flags);
> if (enable)
> - bank->context.wake_en |= gpio_bit;
> + bank->suspend_wakeup |= gpio_bit;
> else
> - bank->context.wake_en &= ~gpio_bit;
> + bank->suspend_wakeup &= ~gpio_bit;
>
> - __raw_writel(bank->context.wake_en, bank->base + bank->regs->wkup_en);
> + if (!bank->loses_context)
> + __raw_writel(bank->suspend_wakeup, bank->base +
> bank->regs->wkup_en);
This doesn't look right for bank 1 (the only one that doesn't lose
context.) If I'm not mistaken, this will overrides the idle wake_en
settings (from context.wake_en), will disable GPIO IRQ triggering for
any of the non IRQ wake-enabled GPIO IRQs in this bank...
> spin_unlock_irqrestore(&bank->lock, flags);
>
> return 0;
> @@ -1157,6 +1159,51 @@ static int __devinit omap_gpio_probe(struct
> platform_device *pdev)
> #ifdef CONFIG_ARCH_OMAP2PLUS
>
> #if defined(CONFIG_PM_RUNTIME)
> +
> +#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;
... probably, we just need to drop the bank->loses_context check here,
so the late writing of bank->suspend_
Re: [PATCH v2] leds: leds-gpio: adopt pinctrl support
On Sat, Sep 1, 2012 at 10:16 AM, AnilKumar Ch wrote: > Adopt pinctrl support to leds-gpio driver based on leds-gpio > device pointer, pinctrl driver configure SoC pins to GPIO > mode according to definitions provided in .dts file. > > Signed-off-by: AnilKumar Ch Looks good from a pinctrl point of view! Reviewed-by: Linus Walleij 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: [RFC RESEND 1/4] arm/dts: OMAP: Add timer nodes
On 09/07/2012 03:56 PM, Tony Lindgren wrote: > * Jon Hunter [120907 13:27]: >> Hi Tony, >> >> On 08/30/2012 03:14 PM, Tony Lindgren wrote: >>> * Jon Hunter [120816 08:05]: On 08/15/2012 04:11 AM, Vaibhav Hiremath wrote: > > Did we get conclude on this? I haven't got anything further on this > thread, this may block baseport support for the new devices in omap2 > family, like AM33xx and OMAP5. Sorry I have been out of the office. However, no update on this so far. I need to check with Tony if he has any preference for handling this. I will follow-up with him and keep you posted. >>> >>> Jon please repost these without the RFC in the subject line >>> assuming the pending comments have been addressed so people >>> can ack them. >> >> I have been working on updating this series to request timer by their >> capabilities and avoid using a device ID altogether. In the updated >> series using device IDs to request a timer will still work as it does >> today, but not when you boot with DT. I have something working now that >> is booting fine on omap4 with and without DT [1]. However, I need to do >> more thorough testing of the timers in general, probably next week. >> >> Once I have completed my testing I would like to post for review. >> However, since posting the original series I have been working on some >> needed timer fixes/clean-up which I posted this week [2] for review. >> Ideally I should rebase my DT timer work on my timer fixes series but >> wanted to see what you thought first. > > Yeah those all look good to me. Want to do a git branch against > v3.6-rc4 for those once the comments are dealt with so I can pull > it in for testing to start with? The fixes series should already be based on top of 3.6-rc4 but will update based upon comments. The only outstanding comment on those were the implementation of the __omap_dm_timer_populate_errata() function. Not sure if you have any comments. Vaibhav and myself are not completely happy with it. I proposed something else but no feedback on that yet. Cheers Jon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] pinctrl: pinctrl-single: Make sure we do not change bits outside of mask
On Thu, Sep 6, 2012 at 8:59 PM, Tony Lindgren wrote:
> * Peter Ujfalusi [120905 02:02]:
>> Use the pcs->fmask to make sure that the value is not changing (setting)
>> bits in areas where it should not.
>> To avoid situations like this:
>>
>> pmx_dummy: pinmux@4a100040 {
>> compatible = "pinctrl-single";
>> reg = <0x4a100040 0x0196>;
>> #address-cells = <1>;
>> #size-cells = <0>;
>> pinctrl-single,register-width = <16>;
>> pinctrl-single,function-mask = <0x00ff>;
>> };
>>
>> &pmx_dummy {
>> pinctrl-names = "default";
>> pinctrl-0 = <&board_pins>;
>>
>> board_pins: pinmux_board_pins {
>> pinctrl-single,pins = <
>> 0x6c 0xf0f
>> 0x6e 0x10f
>> 0x70 0x23f
>> 0x72 0xa5f
>> >;
>> };
>> };
>>
>> Signed-off-by: Peter Ujfalusi
>
> Thanks this is a valid fix:
>
> Acked-by: Tony Lindgren
Since nothing in v3.6 is using pinctrl-simple yet, it's not a regression
right?
So can you just group this with the other pinctrl things you are
harvesting in the OMAP tree? I was going to push it for
the v3.7 cycle otherwise.
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 v9] can: c_can: Add runtime PM support to Bosch C_CAN/D_CAN controller
"AnilKumar, Chimata" writes:
> Hi Kevin,
>
> On Fri, Sep 07, 2012 at 05:07:56, Kevin Hilman wrote:
>> AnilKumar Ch writes:
>>
>> > Add Runtime PM support to C_CAN/D_CAN controller. The runtime PM
>> > APIs control clocks for C_CAN/D_CAN IP and prevent access to the
>> > register of C_CAN/D_CAN IP when clock is turned off.
>> >
>> > Signed-off-by: AnilKumar Ch
>>
>> I'm not familar with the CAN specifics here, but some comments on the
>> runtime PM implementation.
>
> Thanks for the comments.
>
>>
>> > ---
>> > This patch has been tested on AM335X EVM. Due to lack of hardware
>> > I am not able to test c_can functionality. I appreciate if anyone
>> > can test c_can functionality with this patch.
>> >
>> > This patch is based on "can-next/master"
>> >
>> > Changes from v8:
>> >- corrected the return path sequence in c_can_probe()
>> >
>> > Changes from v7:
>> >- Incorporated Marc's comments on v7
>> > * changed device pointer to c_can_priv pointer
>> >
>> > Changes from v6:
>> >- Incorporated Marc's comments on v6
>> > * changed dev pointer to priv
>> > * removed platform_device.h include from c_can.c
>> >
>> > Changes from v5:
>> >- Incorporated Marc's comments on v5
>> > * changed runtime pm calls in c_can driver to handle
>> >the drivers which are not using platform drivers.
>> > * added device pointer protection in c_can driver if
>> >not passed from platform/pci driver.
>> >
>> > Changes from v4:
>> >- Incorporated Vaibhav H review comments on v4.
>> > * Moved pm_runtime put/get_sync calls to appropriate positions.
>> >- This patch is from "Add DT support to C_CAN/D_CAN controller"
>> > patch series. Rest of the patches in this series were applied
>> > so this v5 contains only this patch.
>> >
>> > drivers/net/can/c_can/c_can.c | 24 +++-
>> > drivers/net/can/c_can/c_can.h |1 +
>> > drivers/net/can/c_can/c_can_platform.c | 11 +--
>> > 3 files changed, 33 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
>> > index 4c538e3..966d318 100644
>> > --- a/drivers/net/can/c_can/c_can.c
>> > +++ b/drivers/net/can/c_can/c_can.c
>> > @@ -34,6 +34,7 @@
>> > #include
>> > #include
>> > #include
>> > +#include
>> >
>> > #include
>> > #include
>> > @@ -201,6 +202,18 @@ static const struct can_bittiming_const
>> > c_can_bittiming_const = {
>> >.brp_inc = 1,
>> > };
>> >
>> > +static inline void c_can_pm_runtime_get_sync(struct c_can_priv *priv)
>> > +{
>> > + if (priv->device)
>> > + pm_runtime_get_sync(priv->device);
>> > +}
>> > +
>> > +static inline void c_can_pm_runtime_put_sync(struct c_can_priv *priv)
>> > +{
>> > + if (priv->device)
>> > + pm_runtime_put_sync(priv->device);
>> > +}
>>
>> IMO, these extra helpers are rather unsightly, and should not be needed.
>> The driver should just be directly doing get_sync/put_sync. If
>> priv->device isn't presnt, then runtime PM should just never be enabled.
>>
>
> In case of c_can driver we have two drivers one is generic c_can.c driver,
> provides the basic functionality of CAN. Another two drivers c_can_platform.c
> and c_can_pci.c, which uses core c_can.c driver by exporting some platform
> specific ops like read/write.
>
> priv->device pointer is passed from c_can_platform.c by this means
> "priv->device = &pdev->dev;" (see below) but not for c_can_pci.c
>
> The purpose of check here is for *_pci.c driver which do not have runtime pm
> implemented yet so we should do and get_sync/put_sync. In case of *_pci.c
> driver there is no pm_runtime_enable/disable once that is implemented then
> this check will be removed.
Then you should probably move the pm_runtime_enable/disable into the
common code (where the get_sync/put_sync) are. Then you could simply
avoid the pm_runtime_enable() if there is no priv->device.
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: [RFC RESEND 1/4] arm/dts: OMAP: Add timer nodes
* Jon Hunter [120907 13:27]: > Hi Tony, > > On 08/30/2012 03:14 PM, Tony Lindgren wrote: > > * Jon Hunter [120816 08:05]: > >> On 08/15/2012 04:11 AM, Vaibhav Hiremath wrote: > >>> > >>> Did we get conclude on this? I haven't got anything further on this > >>> thread, this may block baseport support for the new devices in omap2 > >>> family, like AM33xx and OMAP5. > >> > >> Sorry I have been out of the office. However, no update on this so far. > >> I need to check with Tony if he has any preference for handling this. I > >> will follow-up with him and keep you posted. > > > > Jon please repost these without the RFC in the subject line > > assuming the pending comments have been addressed so people > > can ack them. > > I have been working on updating this series to request timer by their > capabilities and avoid using a device ID altogether. In the updated > series using device IDs to request a timer will still work as it does > today, but not when you boot with DT. I have something working now that > is booting fine on omap4 with and without DT [1]. However, I need to do > more thorough testing of the timers in general, probably next week. > > Once I have completed my testing I would like to post for review. > However, since posting the original series I have been working on some > needed timer fixes/clean-up which I posted this week [2] for review. > Ideally I should rebase my DT timer work on my timer fixes series but > wanted to see what you thought first. Yeah those all look good to me. Want to do a git branch against v3.6-rc4 for those once the comments are dealt with so I can pull it in for testing to start with? Regards, Tony > Cheers > Jon > > [1] https://github.com/jonhunter/linux/tree/dev-dt-timer > [2] http://marc.info/?l=linux-omap&m=134687188921835&w=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 v4 00/21] OMAP UART Patches
Felipe Balbi writes: > Hi, > > On Thu, Sep 06, 2012 at 03:44:13PM -0700, Kevin Hilman wrote: >> Felipe Balbi writes: >> >> > Hi guys, >> > >> > here's v4 of the omap uart patchset. No changes other than a rebase on top >> > of >> > Greg's tty-next branch and Tony's Acked-by being added to a couple patches >> > >> > Note: I'm resending the series with Vikram's Software Flow Control fix >> > anyway >> > as it can just be ignored if it's decided it needs to go into this merge >> > window. >> >> Sorry to be late to the party... just getting back from some time off. >> >> I'm assuming that this was not tested with PM, so decided I better do it > > you assumed wrong. See the previous versions of the series and you'll > see I mention all the basic pm testing I did. My apologies for not reading the previous versions. I don't think it's unusual that a reviewer should expect everything he to know about a series (including how it was tested) is in the cover letter or in the changelogs of the latest series. I don't expect to have to look through all the previous versions for this kind of info. Since I wasn't around to review/test the earlier versions, I just looked at the latest (v4) and didn't see any mention of testing of any sort in the cover letter. Looking back at the previous cover letters, I don't see any description of the PM testing either. I only see it was tested on pandaboard. Since mainline doesn't have full PM support for OMAP4, testing on panda doesn't really test UART PM at all. Could you please point me to the descriptions in earlier mails of how you did PM testing, and on what platforms? In addition, IMO, if this was only tested on Panda (as suggested by earlier cover letters), it really should not have been merged until it got some broader testing. >> myself seeing that Greg is has already merge it. To test, I merged >> Greg's tty-next branch with v3.6-rc4 and did some PM testing. >> >> The bad news is that it doesn't even compile (see reply to [PATCH v4 >> 20/21]). > > yeah, that was an automerge issue when rebasing on greg's tty-next > branch, plus me assuming omap serial was already enabled on my .config > and not checking the compile output. Sent a patch now. As I reported in my reply to [PATCH v4 20/21], that patch also had another problem where it introduced a new (but unused) field. Maybe another rebase problem? I see the same problem in v3 and v4. >> Also, there is a big WARNING on boot[1], which seems to be triggered by >> a new check added for v3.6-rc3[2]. This appears to be introduced by >> $SUBJECT series, because I don't see it on vanilla v3.6-rc4. [...] > This doesn't seem to be caused by $SUBJECT at all. See that we are > calling uart_add_one_port() which will call tty_port_register_device() > which, in turn, will call tty_port_link_device() and that will set > driver->ports[index] correctly. > > Have you checked if this doesn't happen without my series before waving > your blame hammer ? FWIW, that part of the code wasn't change by > $SUBJECT at all. Whoa. This was only test report. No need to get personal. All I said is that it "seemed" to introduced by $SUBJECT series. Hardly waiving "blame hammer." And yes, I did check without your series. As I reported above, the warning didn't exist with v3.6-rc4, and it did with yesterday's tty-next branch. The WARNING pointed a finger at ttyO (omap-serial) so I assumed it was in $SUBJECT series. Testing with todays tty-next, the problem is gone. The patch 'tty_register_device_attr updated for tty-next'[1] seems to have made the problem go away. So it's now clear that it wasn't introduced by $SUBJECT series. My bad. Yesterday, it wasn't that obvious, so I made an assumption in order to report a problem uncovered in my testing in the hopes that it would be helpful to you in fixing a potential problem. My assumption was wrong, I was wrong. I'm wrong a lot, and I'm OK with that. The bug was elsewhere, and is already fixed. My apologies if it seemed like I was blaming you. Kevin [1] Author: Tomas Hlavacek 2012-09-06 14:17:47 Committer: Greg Kroah-Hartman 2012-09-06 14:40:18 Parent: 6915c0e487c822e2436683e14302c0b8a6155cc7 (tty: uartclk value from serial_core exposed to sysfs) Child: e36851d0fa94b0f7802b3cc80406dbd3ef4f2f16 (serial: omap: fix compile breakage) Branch: tmp/uart-test-2 Follows: v3.6-rc3 Precedes: tty_register_device_attr updated for tty-next Added tty_device_create_release() and bound to dev->release in tty_register_device_attr(). Added tty_port_register_device_attr() and used in uart_add_one_port() instead of tty_register_device_attr(). Signed-off-by: Tomas Hlavacek Signed-off-by: Greg Kroah-Hartman -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC RESEND 1/4] arm/dts: OMAP: Add timer nodes
Hi Tony, On 08/30/2012 03:14 PM, Tony Lindgren wrote: > * Jon Hunter [120816 08:05]: >> On 08/15/2012 04:11 AM, Vaibhav Hiremath wrote: >>> >>> Did we get conclude on this? I haven't got anything further on this >>> thread, this may block baseport support for the new devices in omap2 >>> family, like AM33xx and OMAP5. >> >> Sorry I have been out of the office. However, no update on this so far. >> I need to check with Tony if he has any preference for handling this. I >> will follow-up with him and keep you posted. > > Jon please repost these without the RFC in the subject line > assuming the pending comments have been addressed so people > can ack them. I have been working on updating this series to request timer by their capabilities and avoid using a device ID altogether. In the updated series using device IDs to request a timer will still work as it does today, but not when you boot with DT. I have something working now that is booting fine on omap4 with and without DT [1]. However, I need to do more thorough testing of the timers in general, probably next week. Once I have completed my testing I would like to post for review. However, since posting the original series I have been working on some needed timer fixes/clean-up which I posted this week [2] for review. Ideally I should rebase my DT timer work on my timer fixes series but wanted to see what you thought first. Cheers Jon [1] https://github.com/jonhunter/linux/tree/dev-dt-timer [2] http://marc.info/?l=linux-omap&m=134687188921835&w=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] watchdog: omap_wdt: convert to new watchdog core
On Fri, Sep 07, 2012 at 06:51:43PM +0300, Aaro Koskinen wrote: > Thanks for the report! I'll look into this and test with other > Nokia boards. I tested the patch only with N800 and v3.6-rc4 > (4cbe5a555fa58a79b6ecbb6c531b8bab0650778d) and did not see any issues > with normal use cases (boot, watchdog open, feeding, watchdog close). > I forgot to test on another hw but will try to do in coming days. Anyway I'm happy to test your patch again if you spot something so you could cc also me for retesting. -- Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC PATCH] ARM: OMAP2+: omap-device: Do not overwrite resources allocated by OF layer
On Fri, Sep 07, 2012 at 23:17:37, Cousson, Benoit wrote:
> Hi Vaibhav,
>
> The following patch is hacing some checkpatch issues.
>
> CHECK: Alignment should match open parenthesis
> #169: FILE: arch/arm/plat-omap/omap_device.c:591:
> + dev_dbg(&pdev->dev, "%s(): resources already allocated
> %d\n",
> + __func__, res_count);
>
> CHECK: Alignment should match open parenthesis
> #171: FILE: arch/arm/plat-omap/omap_device.c:593:
> + memcpy(res, pdev->resource,
> + sizeof(struct resource) * pdev->num_resources);
>
> CHECK: Alignment should match open parenthesis
> #173: FILE: arch/arm/plat-omap/omap_device.c:595:
> + omap_device_fill_dma_resources(od,
> + &res[pdev->num_resources]);
>
> CHECK: Alignment should match open parenthesis
> #176: FILE: arch/arm/plat-omap/omap_device.c:598:
> + dev_dbg(&pdev->dev, "%s(): using resources from hwmod
> %d\n",
> + __func__, res_count);
>
> total: 0 errors, 0 warnings, 4 checks, 130 lines checked
>
>
> Since I was in a nice mood, because the week-end is almost there, I fixed
> them myself.
>
My bad...I usually do check for checkpatch.pl and sparse warnings, not sure
how did I miss this one. I will be more careful here onwards.
> Please note that I had to rename the API becasue it was way too long to do a
> proper alignement.
>
> omap_device_fill_dma_resources -> _od_fill_dma_resources
>
> In fact I realized that some private APIs should probably be renamed as well
> like that for
> consistency.
>
> Just let me know if you have any issue with that version.
>
Looks ok to me.
Thanks,
Vaibhav
> Regards,
> Benoit
>
> ---
> From b82b04e8eb27abe0cfe9cd7bf4fee8bb1bb9b013 Mon Sep 17 00:00:00 2001
> From: Vaibhav Hiremath
> Date: Wed, 29 Aug 2012 15:18:11 +0530
> Subject: [PATCH] ARM: OMAP: omap_device: Do not overwrite resources allocated
> by OF layer
>
> With the new devices (like, AM33XX and OMAP5) we now only support
> DT boot mode of operation and now it is the time to start killing
> slowly the dependency on hwmod, so with this patch, we are starting
> with device resources.
> The idea here is implemented considering to both boot modes -
> - DT boot mode
> OF framework will construct the resource structure (currently
> does for MEM & IRQ resource) and we should respect/use these
> resources, killing hwmod dependency.
> If pdev->num_resources > 0, we assume that MEM & IRQ resources
> have been allocated by OF layer already (through DTB).
>
> Once DMA resource is available from OF layer, we should
> kill filling any resources from hwmod.
>
> - Non-DT boot mode
> Here, pdev->num_resources = 0, and we should get all the
> resources from hwmod (following existing steps)
>
> Signed-off-by: Vaibhav Hiremath
> Cc: Tony Lindgren
> Cc: Paul Walmsley
> Cc: Kevin Hilman
> [b-cous...@ti.com: Fix some checkpatch CHECK issues]
> Signed-off-by: Benoit Cousson
> ---
> arch/arm/mach-omap2/omap_hwmod.c | 27 ++
> arch/arm/plat-omap/include/plat/omap_hwmod.h |1 +
> arch/arm/plat-omap/omap_device.c | 71 +
> 3 files changed, 87 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c
> b/arch/arm/mach-omap2/omap_hwmod.c
> index 6ca8e51..7768804 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -3158,6 +3158,33 @@ int omap_hwmod_fill_resources(struct omap_hwmod *oh,
> struct resource *res)
> }
>
> /**
> + * omap_hwmod_fill_dma_resources - fill struct resource array with dma data
> + * @oh: struct omap_hwmod *
> + * @res: pointer to the array of struct resource to fill
> + *
> + * Fill the struct resource array @res with dma resource data from the
> + * omap_hwmod @oh. Intended to be called by code that registers
> + * omap_devices. See also omap_hwmod_count_resources(). Returns the
> + * number of array elements filled.
> + */
> +int omap_hwmod_fill_dma_resources(struct omap_hwmod *oh, struct resource
> *res)
> +{
> + int i, sdma_reqs_cnt;
> + int r = 0;
> +
> + sdma_reqs_cnt = _count_sdma_reqs(oh);
> + for (i = 0; i < sdma_reqs_cnt; i++) {
> + (res + r)->name = (oh->sdma_reqs + i)->name;
> + (res + r)->start = (oh->sdma_reqs + i)->dma_req;
> + (res + r)->end = (oh->sdma_reqs + i)->dma_req;
> + (res + r)->flags = IORESOURCE_DMA;
> + r++;
> + }
> +
> + return r;
> +}
> +
> +/**
> * omap_hwmod_get_resource_byname - fetch IP block integration data by name
> * @oh: struct omap_hwmod * to operate on
> * @type: one of the IORESOURCE_* constants from include/linux/ioport.h
> diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
> b/arch/arm/plat-omap/include/plat/omap_hwmod.h
> i
Re: [PATCH] serial: omap: Request pins using pinctrl framework
* Tony Lindgren [120907 11:00]:
> Request pins using pinctrl framework. Only show a warning
> on error as some boards set the pins in the bootloader
> even if CONFIG_PINCTRL is enabled.
>
> Signed-off-by: Tony Lindgren
>
> ---
>
> Note that this has only so far been tested with the legacy
> non-devicetree boot as devicetree boot now has a regression
> issue with omap-serial.
Now also tested with devicetree case on top tty-next +
Felipe's "[PATCH] serial: omap: fix DeviceTree boot.
Tony
> --- a/drivers/tty/serial/omap-serial.c
> +++ b/drivers/tty/serial/omap-serial.c
> @@ -40,6 +40,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -108,6 +109,7 @@ struct uart_omap_port {
> u32 latency;
> u32 calc_latency;
> struct work_struct qos_work;
> + struct pinctrl *pins;
> };
>
> #define to_uart_omap_port(p) ((container_of((p), struct uart_omap_port,
> port)))
> @@ -1371,6 +1373,13 @@ static int __devinit serial_omap_probe(struct
> platform_device *pdev)
> goto err_port_line;
> }
>
> + up->pins = devm_pinctrl_get_select_default(&pdev->dev);
> + if (IS_ERR(up->pins)) {
> + dev_warn(&pdev->dev, "did not get pins for uart%i error: %li\n",
> + up->port.line, PTR_ERR(up->pins));
> + up->pins = NULL;
> + }
> +
> sprintf(up->name, "OMAP UART%d", up->port.line);
> up->port.mapbase = mem->start;
> up->port.membase = devm_ioremap(&pdev->dev, mem->start,
> --
> To unsubscribe from this list: send the line "unsubscribe 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] serial: omap: fix DeviceTree boot
* Felipe Balbi [120907 11:15]: > OMAP Architecture code, passes a few function > pointers for UART driver to use in order to > properly implement Power Management and Wakeup > capabilities. > > The problem is that those function pointers, > which are passed (ab)using platform_data on > non-DT kernels, can't be passed down to drivers > through DT. > > commit e5b57c0 (serial: omap: define helpers > for pdata function pointers) failed to take DT > kernels into consideration and caused a regression > to DT kernel boot. > > Fix that by (re-)adding a check for valid pdata > pointer together with valid pdata->$FUNCTION > pointer. > > Reported-by: Tony Lindgren > Signed-off-by: Felipe Balbi > --- > > Tony, does this solve the issue ? Yes thanks console works again now: Tested-by: Tony Lindgren -- To unsubscribe from this list: send the line "unsubscribe 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] serial: omap: fix DeviceTree boot
OMAP Architecture code, passes a few function
pointers for UART driver to use in order to
properly implement Power Management and Wakeup
capabilities.
The problem is that those function pointers,
which are passed (ab)using platform_data on
non-DT kernels, can't be passed down to drivers
through DT.
commit e5b57c0 (serial: omap: define helpers
for pdata function pointers) failed to take DT
kernels into consideration and caused a regression
to DT kernel boot.
Fix that by (re-)adding a check for valid pdata
pointer together with valid pdata->$FUNCTION
pointer.
Reported-by: Tony Lindgren
Signed-off-by: Felipe Balbi
---
Tony, does this solve the issue ?
drivers/tty/serial/omap-serial.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 0a6e78e..743e8e1 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -143,7 +143,7 @@ static int serial_omap_get_context_loss_count(struct
uart_omap_port *up)
{
struct omap_uart_port_info *pdata = up->dev->platform_data;
- if (!pdata->get_context_loss_count)
+ if (!pdata || !pdata->get_context_loss_count)
return 0;
return pdata->get_context_loss_count(up->dev);
@@ -153,24 +153,30 @@ static void serial_omap_set_forceidle(struct
uart_omap_port *up)
{
struct omap_uart_port_info *pdata = up->dev->platform_data;
- if (pdata->set_forceidle)
- pdata->set_forceidle(up->dev);
+ if (!pdata || !pdata->set_forceidle)
+ return;
+
+ pdata->set_forceidle(up->dev);
}
static void serial_omap_set_noidle(struct uart_omap_port *up)
{
struct omap_uart_port_info *pdata = up->dev->platform_data;
- if (pdata->set_noidle)
- pdata->set_noidle(up->dev);
+ if (!pdata || !pdata->set_noidle)
+ return;
+
+ pdata->set_noidle(up->dev);
}
static void serial_omap_enable_wakeup(struct uart_omap_port *up, bool enable)
{
struct omap_uart_port_info *pdata = up->dev->platform_data;
- if (pdata->enable_wakeup)
- pdata->enable_wakeup(up->dev, enable);
+ if (!pdata || !pdata->enable_wakeup)
+ return;
+
+ pdata->enable_wakeup(up->dev, enable);
}
/*
--
1.7.12.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] ARM: OMAP2+: omap-device: Do not overwrite resources allocated by OF layer
Hi Vaibhav,
The following patch is having some checkpatch issues.
CHECK: Alignment should match open parenthesis
#169: FILE: arch/arm/plat-omap/omap_device.c:591:
+ dev_dbg(&pdev->dev, "%s(): resources already allocated
%d\n",
+ __func__, res_count);
CHECK: Alignment should match open parenthesis
#171: FILE: arch/arm/plat-omap/omap_device.c:593:
+ memcpy(res, pdev->resource,
+ sizeof(struct resource) * pdev->num_resources);
CHECK: Alignment should match open parenthesis
#173: FILE: arch/arm/plat-omap/omap_device.c:595:
+ omap_device_fill_dma_resources(od,
+ &res[pdev->num_resources]);
CHECK: Alignment should match open parenthesis
#176: FILE: arch/arm/plat-omap/omap_device.c:598:
+ dev_dbg(&pdev->dev, "%s(): using resources from hwmod
%d\n",
+ __func__, res_count);
total: 0 errors, 0 warnings, 4 checks, 130 lines checked
Since I was in a nice mood, because the week-end is almost there, I
fixed them myself.
Please note that I had to rename the API becasue it was way too long to
do a proper alignement.
omap_device_fill_dma_resources -> _od_fill_dma_resources
In fact I realized that some private APIs should probably be renamed as
well like that for
consistency.
Just let me know if you have any issue with that version.
Regards,
Benoit
---
>From b82b04e8eb27abe0cfe9cd7bf4fee8bb1bb9b013 Mon Sep 17 00:00:00 2001
From: Vaibhav Hiremath
Date: Wed, 29 Aug 2012 15:18:11 +0530
Subject: [PATCH] ARM: OMAP: omap_device: Do not overwrite resources
allocated by OF layer
With the new devices (like, AM33XX and OMAP5) we now only support
DT boot mode of operation and now it is the time to start killing
slowly the dependency on hwmod, so with this patch, we are starting
with device resources.
The idea here is implemented considering to both boot modes -
- DT boot mode
OF framework will construct the resource structure (currently
does for MEM & IRQ resource) and we should respect/use these
resources, killing hwmod dependency.
If pdev->num_resources > 0, we assume that MEM & IRQ resources
have been allocated by OF layer already (through DTB).
Once DMA resource is available from OF layer, we should
kill filling any resources from hwmod.
- Non-DT boot mode
Here, pdev->num_resources = 0, and we should get all the
resources from hwmod (following existing steps)
Signed-off-by: Vaibhav Hiremath
Cc: Tony Lindgren
Cc: Paul Walmsley
Cc: Kevin Hilman
[b-cous...@ti.com: Fix some checkpatch CHECK issues]
Signed-off-by: Benoit Cousson
---
arch/arm/mach-omap2/omap_hwmod.c | 27 ++
arch/arm/plat-omap/include/plat/omap_hwmod.h |1 +
arch/arm/plat-omap/omap_device.c | 71
+
3 files changed, 87 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index 6ca8e51..7768804 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -3158,6 +3158,33 @@ int omap_hwmod_fill_resources(struct omap_hwmod
*oh, struct resource *res)
}
/**
+ * omap_hwmod_fill_dma_resources - fill struct resource array with dma data
+ * @oh: struct omap_hwmod *
+ * @res: pointer to the array of struct resource to fill
+ *
+ * Fill the struct resource array @res with dma resource data from the
+ * omap_hwmod @oh. Intended to be called by code that registers
+ * omap_devices. See also omap_hwmod_count_resources(). Returns the
+ * number of array elements filled.
+ */
+int omap_hwmod_fill_dma_resources(struct omap_hwmod *oh, struct
resource *res)
+{
+ int i, sdma_reqs_cnt;
+ int r = 0;
+
+ sdma_reqs_cnt = _count_sdma_reqs(oh);
+ for (i = 0; i < sdma_reqs_cnt; i++) {
+ (res + r)->name = (oh->sdma_reqs + i)->name;
+ (res + r)->start = (oh->sdma_reqs + i)->dma_req;
+ (res + r)->end = (oh->sdma_reqs + i)->dma_req;
+ (res + r)->flags = IORESOURCE_DMA;
+ r++;
+ }
+
+ return r;
+}
+
+/**
* omap_hwmod_get_resource_byname - fetch IP block integration data by name
* @oh: struct omap_hwmod * to operate on
* @type: one of the IORESOURCE_* constants from include/linux/ioport.h
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 6132972..5857b9c 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -615,6 +615,7 @@ int omap_hwmod_softreset(struct omap_hwmod *oh);
int omap_hwmod_count_resources(struct omap_hwmod *oh);
int omap_hwmod_fill_resources(struct omap_hwmod *oh, struct resource *res);
+int omap_hwmod_fill_dma_resources(struct omap_hwmod *oh, struct
resource *res);
int omap_hwmod_get_resource_byname(struct omap
Re: [PATCH 5/5] omap-serial: Request pins using pinctrl framework
* Tony Lindgren [120907 10:29]: > * AnilKumar, Chimata [120906 20:27]: > > > @@ -1570,6 +1578,8 @@ static int serial_omap_remove(struct > > > platform_device *dev) > > > pm_runtime_disable(&up->pdev->dev); > > > uart_remove_one_port(&serial_omap_reg, &up->port); > > > pm_qos_remove_request(&up->pm_qos_request); > > > + if (up->pins) > > > + pinctrl_put(up->pins); > > > > I think this can be removed if we use devm_pinctrl_get_select_default() > > above. > > Yeah will do, I was initially thinking that would cause issues remuxing > pins back to safe mode on unload, but we can still do that in > serial_omap_remove(). Sent now as a separate patch with subject "[PATCH] serial: omap: Request pins using pinctrl framework". Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drm/omap: add more new timings fields
From: Rob Clark Without these, DVI is broken. Signed-off-by: Rob Clark --- Greg, it looks like the omapdss changes which added these fields, as well as the interlaced field, where merged in Linux 3.5-rc5. So I think both this and the 'update for interlaced' patch are needed for both 3.6 and 3.5. drivers/staging/omapdrm/omap_connector.c | 24 1 file changed, 24 insertions(+) diff --git a/drivers/staging/omapdrm/omap_connector.c b/drivers/staging/omapdrm/omap_connector.c index 5f4a89b..55e9c86 100644 --- a/drivers/staging/omapdrm/omap_connector.c +++ b/drivers/staging/omapdrm/omap_connector.c @@ -52,6 +52,16 @@ static inline void copy_timings_omap_to_drm(struct drm_display_mode *mode, if (timings->interlace) mode->flags |= DRM_MODE_FLAG_INTERLACE; + + if (timings->hsync_level == OMAPDSS_SIG_ACTIVE_HIGH) + mode->flags |= DRM_MODE_FLAG_PHSYNC; + else + mode->flags |= DRM_MODE_FLAG_NHSYNC; + + if (timings->vsync_level == OMAPDSS_SIG_ACTIVE_HIGH) + mode->flags |= DRM_MODE_FLAG_PVSYNC; + else + mode->flags |= DRM_MODE_FLAG_NVSYNC; } static inline void copy_timings_drm_to_omap(struct omap_video_timings *timings, @@ -70,6 +80,20 @@ static inline void copy_timings_drm_to_omap(struct omap_video_timings *timings, timings->vbp = mode->vtotal - mode->vsync_end; timings->interlace = !!(mode->flags & DRM_MODE_FLAG_INTERLACE); + + if (mode->flags & DRM_MODE_FLAG_PHSYNC) + timings->hsync_level = OMAPDSS_SIG_ACTIVE_HIGH; + else + timings->hsync_level = OMAPDSS_SIG_ACTIVE_LOW; + + if (mode->flags & DRM_MODE_FLAG_PVSYNC) + timings->vsync_level = OMAPDSS_SIG_ACTIVE_HIGH; + else + timings->vsync_level = OMAPDSS_SIG_ACTIVE_LOW; + + timings->data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE; + timings->de_level = OMAPDSS_SIG_ACTIVE_HIGH; + timings->sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES; } static void omap_connector_dpms(struct drm_connector *connector, int mode) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] serial: omap: Request pins using pinctrl framework
Request pins using pinctrl framework. Only show a warning
on error as some boards set the pins in the bootloader
even if CONFIG_PINCTRL is enabled.
Signed-off-by: Tony Lindgren
---
Note that this has only so far been tested with the legacy
non-devicetree boot as devicetree boot now has a regression
issue with omap-serial.
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#include
@@ -108,6 +109,7 @@ struct uart_omap_port {
u32 latency;
u32 calc_latency;
struct work_struct qos_work;
+ struct pinctrl *pins;
};
#define to_uart_omap_port(p) ((container_of((p), struct uart_omap_port,
port)))
@@ -1371,6 +1373,13 @@ static int __devinit serial_omap_probe(struct
platform_device *pdev)
goto err_port_line;
}
+ up->pins = devm_pinctrl_get_select_default(&pdev->dev);
+ if (IS_ERR(up->pins)) {
+ dev_warn(&pdev->dev, "did not get pins for uart%i error: %li\n",
+up->port.line, PTR_ERR(up->pins));
+ up->pins = NULL;
+ }
+
sprintf(up->name, "OMAP UART%d", up->port.line);
up->port.mapbase = mem->start;
up->port.membase = devm_ioremap(&pdev->dev, mem->start,
--
To unsubscribe from this list: send the line "unsubscribe 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] serial: omap: fix compile breakage
* Greg KH [120907 08:43]: > On Fri, Sep 07, 2012 at 06:34:19PM +0300, Felipe Balbi wrote: > > when rebasing patches on top of Greg's tty-next, > > it looks like automerge broke a few things which > > I didn't catch (for whatever reason I didn't > > have OMAP Serial enabled on .config) so I ended > > up breaking the build on Greg's tty-next branch. > > > > Fix the breakage by re-adding the three missing > > members on struct uart_omap_port. > > > > Reported-by: Tony Lindgren > > Signed-off-by: Felipe Balbi > > --- > > > > Hi Greg, > > > > I just fetched your tree again and rebased again just to > > make sure. Everything is fine here, let me know if it > > still applies with fuzz. > > That worked, thanks. Something is still wrong with omap-serial in tty-next. It now compiles and works for the legacy non-devicetree case, but with device tree booting there's now regression during boot: [5.200836] Freeing init memory: 332K [6.881744] Unable to handle kernel NULL pointer dereference at virtual address 0030 [6.890258] pgd = ee664000 [6.893096] [0030] *pgd=ae64f831, *pte=, *ppte= [6.899688] Internal error: Oops: 17 [#1] SMP ARM [6.904632] Modules linked in: [6.907836] CPU: 1Not tainted (3.6.0-rc4-00207-gc893c8c-dirty #485) [6.914916] PC is at serial_omap_start_tx+0x60/0x98 [6.920043] LR is at serial_omap_start_tx+0x44/0x98 [6.925140] pc : []lr : []psr: 6193 [6.925140] sp : ee661e80 ip : 0060 fp : a113 [6.937194] r10: ef3c0010 r9 : ee798800 r8 : 0072 [6.942687] r7 : ef3d7472 r6 : 0002 r5 : 0007 r4 : ef3c0010 [6.949523] r3 : r2 : 0004 r1 : 0007 r0 : ef0da008 [6.956390] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user [6.963958] Control: 10c53c7d Table: ae66404a DAC: 0015 [6.970001] Process modprobe (pid: 715, stack limit = 0xee6602f8) [6.976379] Stack: (0xee661e80 to 0xee662000) [6.980957] 1e80: ee798800 ef3c0010 2113 c030fcb4 ef3eead0 c0310544 [6.989562] 1ea0: ef3eead0 ee798800 0fff 0073 ee798d94 ef3d7400 ee66 ee7989b8 [6.998138] 1ec0: ef3d7400 c02fa090 0073 ef3d7400 ee798800 ee798800 ef0ccdc0 c02fb8e4 [7.006713] 1ee0: beaa07bc ee798a2c beaa07bc ef38aa00 c00778a0 ee798a4c ee798a4c [7.015319] 1f00: ee798d4c ef0ccdc0 0073 0073 ee798800 b6f19000 ee66 0400 [7.023895] 1f20: c02f775c c02fb7a8 ef1f6840 ee661f80 ef0ccdc0 ef0ccdc0 [7.032470] 1f40: 0073 b6f19000 ee661f80 0073 ee66 beaa07bc c010b580 [7.041046] 1f60: ef38aa00 0001 ef0ccdc0 b6f19000 0073 c010b6e4 [7.049652] 1f80: beaa0888 0073 beaa0888 0073 0004 [7.058227] 1fa0: c0014308 c0014160 0073 beaa0888 b6f19000 0073 [7.066802] 1fc0: 0073 beaa0888 0073 0004 b6f19000 b6ee271d beaa07bc [7.075408] 1fe0: beaa01c0 b6e2c874 b6e8015c 6110 aaea [7.083984] [] (serial_omap_start_tx+0x60/0x98) from [] (uart_start+0x68/0x6c) [7.093414] [] (uart_start+0x68/0x6c) from [] (uart_write+0xcc/0xf4) [7.101928] [] (uart_write+0xcc/0xf4) from [] (process_output_block+0xc0/0x17c) [7.111419] [] (process_output_block+0xc0/0x17c) from [] (n_tty_write+0x13c/0x2ac) [7.121215] [] (n_tty_write+0x13c/0x2ac) from [] (tty_write+0x13c/0x228) [7.130065] [] (tty_write+0x13c/0x228) from [] (vfs_write+0xb0/0x144) [7.138671] [] (vfs_write+0xb0/0x144) from [] (sys_write+0x40/0x70) [7.147094] [] (sys_write+0x40/0x70) from [] (ret_fast_syscall+0x0/0x3c) [7.155944] Code: e6ff1075 e18310b2 e5940180 e5903084 (e5933030) [7.162353] ---[ end trace 8cfe94e3de797bda ]--- -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] ARM: OMAP2+: omap-device: Do not overwrite resources allocated by OF layer
Hi Vaibhav,
The following patch is hacing some checkpatch issues.
CHECK: Alignment should match open parenthesis
#169: FILE: arch/arm/plat-omap/omap_device.c:591:
+ dev_dbg(&pdev->dev, "%s(): resources already allocated
%d\n",
+ __func__, res_count);
CHECK: Alignment should match open parenthesis
#171: FILE: arch/arm/plat-omap/omap_device.c:593:
+ memcpy(res, pdev->resource,
+ sizeof(struct resource) * pdev->num_resources);
CHECK: Alignment should match open parenthesis
#173: FILE: arch/arm/plat-omap/omap_device.c:595:
+ omap_device_fill_dma_resources(od,
+ &res[pdev->num_resources]);
CHECK: Alignment should match open parenthesis
#176: FILE: arch/arm/plat-omap/omap_device.c:598:
+ dev_dbg(&pdev->dev, "%s(): using resources from hwmod
%d\n",
+ __func__, res_count);
total: 0 errors, 0 warnings, 4 checks, 130 lines checked
Since I was in a nice mood, because the week-end is almost there, I fixed them
myself.
Please note that I had to rename the API becasue it was way too long to do a
proper alignement.
omap_device_fill_dma_resources -> _od_fill_dma_resources
In fact I realized that some private APIs should probably be renamed as well
like that for
consistency.
Just let me know if you have any issue with that version.
Regards,
Benoit
---
>From b82b04e8eb27abe0cfe9cd7bf4fee8bb1bb9b013 Mon Sep 17 00:00:00 2001
From: Vaibhav Hiremath
Date: Wed, 29 Aug 2012 15:18:11 +0530
Subject: [PATCH] ARM: OMAP: omap_device: Do not overwrite resources allocated
by OF layer
With the new devices (like, AM33XX and OMAP5) we now only support
DT boot mode of operation and now it is the time to start killing
slowly the dependency on hwmod, so with this patch, we are starting
with device resources.
The idea here is implemented considering to both boot modes -
- DT boot mode
OF framework will construct the resource structure (currently
does for MEM & IRQ resource) and we should respect/use these
resources, killing hwmod dependency.
If pdev->num_resources > 0, we assume that MEM & IRQ resources
have been allocated by OF layer already (through DTB).
Once DMA resource is available from OF layer, we should
kill filling any resources from hwmod.
- Non-DT boot mode
Here, pdev->num_resources = 0, and we should get all the
resources from hwmod (following existing steps)
Signed-off-by: Vaibhav Hiremath
Cc: Tony Lindgren
Cc: Paul Walmsley
Cc: Kevin Hilman
[b-cous...@ti.com: Fix some checkpatch CHECK issues]
Signed-off-by: Benoit Cousson
---
arch/arm/mach-omap2/omap_hwmod.c | 27 ++
arch/arm/plat-omap/include/plat/omap_hwmod.h |1 +
arch/arm/plat-omap/omap_device.c | 71 +
3 files changed, 87 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 6ca8e51..7768804 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -3158,6 +3158,33 @@ int omap_hwmod_fill_resources(struct omap_hwmod *oh,
struct resource *res)
}
/**
+ * omap_hwmod_fill_dma_resources - fill struct resource array with dma data
+ * @oh: struct omap_hwmod *
+ * @res: pointer to the array of struct resource to fill
+ *
+ * Fill the struct resource array @res with dma resource data from the
+ * omap_hwmod @oh. Intended to be called by code that registers
+ * omap_devices. See also omap_hwmod_count_resources(). Returns the
+ * number of array elements filled.
+ */
+int omap_hwmod_fill_dma_resources(struct omap_hwmod *oh, struct resource *res)
+{
+ int i, sdma_reqs_cnt;
+ int r = 0;
+
+ sdma_reqs_cnt = _count_sdma_reqs(oh);
+ for (i = 0; i < sdma_reqs_cnt; i++) {
+ (res + r)->name = (oh->sdma_reqs + i)->name;
+ (res + r)->start = (oh->sdma_reqs + i)->dma_req;
+ (res + r)->end = (oh->sdma_reqs + i)->dma_req;
+ (res + r)->flags = IORESOURCE_DMA;
+ r++;
+ }
+
+ return r;
+}
+
+/**
* omap_hwmod_get_resource_byname - fetch IP block integration data by name
* @oh: struct omap_hwmod * to operate on
* @type: one of the IORESOURCE_* constants from include/linux/ioport.h
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 6132972..5857b9c 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -615,6 +615,7 @@ int omap_hwmod_softreset(struct omap_hwmod *oh);
int omap_hwmod_count_resources(struct omap_hwmod *oh);
int omap_hwmod_fill_resources(struct omap_hwmod *oh, struct resource *res);
+int omap_hwmod_fill_dma_resources(struct omap_hwmod *oh, struct resource *res);
int omap_hwmod_get_resource_byname(s
Re: [PATCH] ARM: dts: OMAP4: Add reg and interrupts for every nodes
On 09/07/2012 07:23 PM, Felipe Balbi wrote: > Hi, > > On Fri, Sep 07, 2012 at 05:25:24PM +0200, Benoit Cousson wrote: >> Thanks to Vaibhav omap_device fix >> (ARM: OMAP: omap_device: Fix up resource names when booted with devicetre), >> we can now specify reg and interrupts using standard device tree >> attributes. >> >> Update the OMAP4 dtsi file with missing reg and interrupts attributes. >> >> Signed-off-by: Benoit Cousson >> Cc: Santosh Shilimkar >> Cc: Tony Lindgren >> Cc: Felipe Balbi >> --- >> >> Hi Tony, >> >> This is the first step toward reduction of the hwmod data inside mach-omap2. >> OMAP2/3/4 data still need to be there for legacy boards, but it will allow >> OMAP5/AM33XX pure DT board to reduce the amount of data provided by hwmod. >> >> DMA is still missing, but I hope that the discussion that happened during >> LPC will fixed that soon. > > Very nice work. Do you already have a way on omap_device creation to use > DT data instead of hwmod's ? No, not yet. This will require a change in the way omap_hwmod / omap_device are created and thus it will need some more work. And then, the only way to get rid of the data for OMAP4 at least is to have a pure DT boot without anymore legacy boards... and we are still not yet there :-( Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] gpio/twl4030: get platform data from device tree
Hi Florian,
I've just noticed that this patch is reporting some CHECK issues.
d1f5052 - gpio/twl4030: get platform data from device tree
CHECK: Alignment should match open parenthesis
#66: FILE: drivers/gpio/gpio-twl4030.c:412:
+ of_property_read_u32(dev->of_node, "ti,debounce",
+ &omap_twl_info->debounce);
CHECK: Alignment should match open parenthesis
#68: FILE: drivers/gpio/gpio-twl4030.c:414:
+ of_property_read_u32(dev->of_node, "ti,mmc-cd",
+ (u32 *)&omap_twl_info->mmc_cd);
CHECK: Alignment should match open parenthesis
#70: FILE: drivers/gpio/gpio-twl4030.c:416:
+ of_property_read_u32(dev->of_node, "ti,pullups",
+ &omap_twl_info->pullups);
CHECK: Alignment should match open parenthesis
#72: FILE: drivers/gpio/gpio-twl4030.c:418:
+ of_property_read_u32(dev->of_node, "ti,pulldowns",
+ &omap_twl_info->pulldowns);
CHECK: Alignment should match open parenthesis
+ pdata->pullups, pdata->pulldowns,
CHECK: Alignment should match open parenthesis
#139: FILE: drivers/gpio/gpio-twl4030.c:479:
+ dev_dbg(&pdev->dev, "debounce %.03x %.01x --> %d\n",
+ pdata->debounce, pdata->mmc_cd,
total: 0 errors, 0 warnings, 6 checks, 118 lines checked
I fixed them since it was trivial, but next time you should ensure that the
patch pass checkpatch before posting.
Just let me know if you have any issue with the following update.
Regards,
Benoit
---
>From f74ce8fb849e9f9c54a494cff5fc30d53ca4e963 Mon Sep 17 00:00:00 2001
From: Florian Vaussard
Date: Wed, 5 Sep 2012 09:46:25 +0200
Subject: [PATCH] gpio/twl4030: get platform data from device tree
Adds a number of missing device tree properties for
twl4030/gpio, and update bindings:
- "ti,use-leds" -> .use_leds
- "ti,debounce" -> .debounce
- "ti,mmc-cd"-> .mmc_cd
- "ti,pullups" -> .pullups
- "ti,pulldowns" -> .pulldowns
Signed-off-by: Florian Vaussard
Acked-by: Linus Walleij
Acked-by: Vaibhav Hiremath
[b-cous...@ti.com: Fix some checkpatch CHECK issues]
Signed-off-by: Benoit Cousson
---
.../devicetree/bindings/gpio/gpio-twl4030.txt |6 ++
drivers/gpio/gpio-twl4030.c| 82 +---
2 files changed, 61 insertions(+), 27 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-twl4030.txt
b/Documentation/devicetree/bindings/gpio/gpio-twl4030.txt
index 16695d9..66788fd 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-twl4030.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-twl4030.txt
@@ -11,6 +11,11 @@ Required properties:
- interrupt-controller: Mark the device node as an interrupt controller
The first cell is the GPIO number.
The second cell is not used.
+- ti,use-leds : Enables LEDA and LEDB outputs if set
+- ti,debounce : if n-th bit is set, debounces GPIO-n
+- ti,mmc-cd : if n-th bit is set, GPIO-n controls VMMC(n+1)
+- ti,pullups : if n-th bit is set, set a pullup on GPIO-n
+- ti,pulldowns : if n-th bit is set, set a pulldown on GPIO-n
Example:
@@ -20,4 +25,5 @@ twl_gpio: gpio {
gpio-controller;
#interrupt-cells = <2>;
interrupt-controller;
+ti,use-leds;
};
diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c
index 94256fe..f923252 100644
--- a/drivers/gpio/gpio-twl4030.c
+++ b/drivers/gpio/gpio-twl4030.c
@@ -395,6 +395,31 @@ static int __devinit gpio_twl4030_debounce(u32 debounce,
u8 mmc_cd)
static int gpio_twl4030_remove(struct platform_device *pdev);
+static struct twl4030_gpio_platform_data *of_gpio_twl4030(struct device *dev)
+{
+ struct twl4030_gpio_platform_data *omap_twl_info;
+
+ omap_twl_info = devm_kzalloc(dev, sizeof(*omap_twl_info), GFP_KERNEL);
+ if (!omap_twl_info)
+ return NULL;
+
+ omap_twl_info->gpio_base = -1;
+
+ omap_twl_info->use_leds = of_property_read_bool(dev->of_node,
+ "ti,use-leds");
+
+ of_property_read_u32(dev->of_node, "ti,debounce",
+&omap_twl_info->debounce);
+ of_property_read_u32(dev->of_node, "ti,mmc-cd",
+(u32 *)&omap_twl_info->mmc_cd);
+ of_property_read_u32(dev->of_node, "ti,pullups",
+&omap_twl_info->pullups);
+ of_property_read_u32(dev->of_node, "ti,pulldowns",
+&omap_twl_info->pulldowns);
+
+ return omap_twl_info;
+}
+
static int __devinit gpio_twl4030_probe(struct platform_device *pdev)
{
struct twl4030_gpio_platform_data *pdata = pdev->dev.platform_data;
@@ -423,39 +448,42 @@ static int __devinit gpio_twl4030_probe(struct
platform_device *pdev)
twl4030_gpio_irq_base = irq_base;
no_irqs:
- twl_gpiochip.base = -1;
twl_gpiochip.ngpio = TWL4030_GPIO_MAX;
twl_gpiochip.dev = &pdev->dev;
- if (pdata) {
-
Re: [PATCH] ARM: dts: OMAP4: Add reg and interrupts for every nodes
* Felipe Balbi [120907 10:30]: > Hi, > > On Fri, Sep 07, 2012 at 10:06:22AM -0700, Tony Lindgren wrote: > > * Benoit Cousson [120907 08:26]: > > > Thanks to Vaibhav omap_device fix > > > (ARM: OMAP: omap_device: Fix up resource names when booted with > > > devicetre), > > > we can now specify reg and interrupts using standard device tree > > > attributes. > > > > > > Update the OMAP4 dtsi file with missing reg and interrupts attributes. > > > > > > Signed-off-by: Benoit Cousson > > > Cc: Santosh Shilimkar > > > Cc: Tony Lindgren > > > Cc: Felipe Balbi > > > --- > > > > > > Hi Tony, > > > > > > This is the first step toward reduction of the hwmod data inside > > > mach-omap2. > > > OMAP2/3/4 data still need to be there for legacy boards, but it will allow > > > OMAP5/AM33XX pure DT board to reduce the amount of data provided by hwmod. > > > > That's good to hear, that should cut down the data by some hundreds of > > lines :) > > more than you think, I guess :-) Very cool, we're only two board files away from making omap4 data shrink by: omap_hwmod_44xx_data.c | 1432 - But basically no need to merge similar data at all for am33xx and omap5. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: OMAP4: Add reg and interrupts for every nodes
Hi, On Fri, Sep 07, 2012 at 05:25:24PM +0200, Benoit Cousson wrote: > Thanks to Vaibhav omap_device fix > (ARM: OMAP: omap_device: Fix up resource names when booted with devicetre), > we can now specify reg and interrupts using standard device tree > attributes. > > Update the OMAP4 dtsi file with missing reg and interrupts attributes. > > Signed-off-by: Benoit Cousson > Cc: Santosh Shilimkar > Cc: Tony Lindgren > Cc: Felipe Balbi > --- > > Hi Tony, > > This is the first step toward reduction of the hwmod data inside mach-omap2. > OMAP2/3/4 data still need to be there for legacy boards, but it will allow > OMAP5/AM33XX pure DT board to reduce the amount of data provided by hwmod. > > DMA is still missing, but I hope that the discussion that happened during > LPC will fixed that soon. Very nice work. Do you already have a way on omap_device creation to use DT data instead of hwmod's ? cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH 5/5] omap-serial: Request pins using pinctrl framework
* AnilKumar, Chimata [120906 20:27]:
> Hi Tony,
>
> On Fri, Sep 07, 2012 at 00:28:32, Tony Lindgren wrote:
> > Request pins using pinctrl framework. Only show a warning
> > on error as some boards set the pins in the bootloader
> > even if CONFIG_PINCTRL is enabled.
> >
> > Cc: linux-ser...@vger.kernel.org
> > Cc: Greg Kroah-Hartman
> > Signed-off-by: Tony Lindgren
> > ---
> > arch/arm/plat-omap/include/plat/omap-serial.h |1 +
> > drivers/tty/serial/omap-serial.c | 10 ++
> > 2 files changed, 11 insertions(+)
> >
> > diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
> > b/arch/arm/plat-omap/include/plat/omap-serial.h
> > index 1a52725..0f4de14 100644
> > --- a/arch/arm/plat-omap/include/plat/omap-serial.h
> > +++ b/arch/arm/plat-omap/include/plat/omap-serial.h
> > @@ -106,6 +106,7 @@ struct uart_omap_port {
> > struct uart_portport;
> > struct uart_omap_dmauart_dma;
> > struct platform_device *pdev;
> > + struct pinctrl *pins;
> >
> > unsigned char ier;
> > unsigned char lcr;
> > diff --git a/drivers/tty/serial/omap-serial.c
> > b/drivers/tty/serial/omap-serial.c
> > index d3cda0c..068e88c 100644
> > --- a/drivers/tty/serial/omap-serial.c
> > +++ b/drivers/tty/serial/omap-serial.c
> > @@ -39,6 +39,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include
> > #include
> > @@ -1492,6 +1493,13 @@ static int serial_omap_probe(struct platform_device
> > *pdev)
> > goto err_port_line;
> > }
> >
> > + up->pins = pinctrl_get_select_default(&pdev->dev);
> > + if (IS_ERR(up->pins)) {
> > + dev_warn(&pdev->dev, "did not get pins for uart%i error: %li\n",
> > +up->port.line, PTR_ERR(up->pins));
> > + up->pins = NULL;
> > + }
> > +
> > sprintf(up->name, "OMAP UART%d", up->port.line);
> > up->port.mapbase = mem->start;
> > up->port.membase = devm_ioremap(&pdev->dev, mem->start,
> > @@ -1570,6 +1578,8 @@ static int serial_omap_remove(struct platform_device
> > *dev)
> > pm_runtime_disable(&up->pdev->dev);
> > uart_remove_one_port(&serial_omap_reg, &up->port);
> > pm_qos_remove_request(&up->pm_qos_request);
> > + if (up->pins)
> > + pinctrl_put(up->pins);
>
> I think this can be removed if we use devm_pinctrl_get_select_default()
> above.
Yeah will do, I was initially thinking that would cause issues remuxing
pins back to safe mode on unload, but we can still do that in
serial_omap_remove().
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: OMAP4: Add reg and interrupts for every nodes
* Benoit Cousson [120907 08:26]: > Thanks to Vaibhav omap_device fix > (ARM: OMAP: omap_device: Fix up resource names when booted with devicetre), > we can now specify reg and interrupts using standard device tree > attributes. > > Update the OMAP4 dtsi file with missing reg and interrupts attributes. > > Signed-off-by: Benoit Cousson > Cc: Santosh Shilimkar > Cc: Tony Lindgren > Cc: Felipe Balbi > --- > > Hi Tony, > > This is the first step toward reduction of the hwmod data inside mach-omap2. > OMAP2/3/4 data still need to be there for legacy boards, but it will allow > OMAP5/AM33XX pure DT board to reduce the amount of data provided by hwmod. That's good to hear, that should cut down the data by some hundreds of lines :) > DMA is still missing, but I hope that the discussion that happened during > LPC will fixed that soon. Yeah and that can be added when the binding is available. The drivers should work with and without DMA as the channels can run out. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/3] arm/dts: Add device tree data for AM33XX devices
* Benoit Cousson [120907 01:38]: > Hi Anil, > > On 09/07/2012 07:30 AM, AnilKumar, Chimata wrote: > > On Thu, Sep 06, 2012 at 15:08:21, AnilKumar, Chimata wrote: > >> Add pinctrl and d_can device tree data to AM33XX family of devices. > >> First two patches add support for pinctrl DT data and third one > >> adds dcan DT data. > >> > >> Reason behind combining these patches is to apply cleanly on > >> linux-omap tree, because these are sequential patches. > >>Yes, > >> These patches were tested on AM335x-Bone, AM335x-EVM and based > >> on linux-omap:master with this patch > >> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg74393.html > >> > > > > If there are no changes in this patch series ACK from > > reviewers (esp. Tony, koen and Marc) will help. > > Yes, indeed. The series looks good to me, but it will be nice to get > some acks from people who commented previous revision. Acked two of them, but there's still some gpio-leds.c discussion going on that should be resolved first. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 2/3] arm/dts: AM33XX: Configure pinmuxs for user leds control on Bone
* Koen Kooi [120907 01:46]:
>
> Op 6 sep. 2012, om 11:38 heeft AnilKumar Ch het volgende
> geschreven:
>
> > Adds GPIO pinctrl nodes to am3358_pinmux master node to control
> > user leds (USR0, USR1, USR2 and USR3) present on BeagleBone.
> >
> > [k...@dominion.thruhere.net: led0, led1 suggested by koen]
> > Signed-off-by: AnilKumar Ch
>
> Acked-by: Koen Kooi
This one still has the discussion going on about if GPIO pins
should be muxed by the GPIO controller in the "GPIO only" case
for gpio leds driver. But other than that:
Acked-by: Tony Lindgren
>
> > ---
> > arch/arm/boot/dts/am335x-bone.dts | 43
> > +
> > 1 file changed, 43 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/am335x-bone.dts
> > b/arch/arm/boot/dts/am335x-bone.dts
> > index c634f87..b0a7409 100644
> > --- a/arch/arm/boot/dts/am335x-bone.dts
> > +++ b/arch/arm/boot/dts/am335x-bone.dts
> > @@ -18,11 +18,54 @@
> > reg = <0x8000 0x1000>; /* 256 MB */
> > };
> >
> > + am33xx_pinmux: pinmux@44e10800 {
> > + userled_pins: pinmux_userled_pins {
> > + pinctrl-single,pins = <
> > + 0x54 0x7/* gpmc_a5.gpio1_21, OUTPUT |
> > MODE7 */
> > + 0x58 0x17 /* gpmc_a6.gpio1_22,
> > OUTPUT_PULLUP | MODE7 */
> > + 0x5c 0x7/* gpmc_a7.gpio1_23, OUTPUT |
> > MODE7 */
> > + 0x60 0x17 /* gpmc_a8.gpio1_24,
> > OUTPUT_PULLUP | MODE7 */
> > + >;
> > + };
> > + };
> > +
> > ocp {
> > uart1: serial@44e09000 {
> > status = "okay";
> > };
> >
> > + leds {
> > + compatible = "gpio-leds";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&userled_pins>;
> > +
> > + heartbeat {
> > + label = "beaglebone:green:usr0";
> > + gpios = <&gpio2 21 0>;
> > + linux,default-trigger = "heartbeat";
> > + default-state = "off";
> > + };
> > +
> > + mmc {
> > + label = "beaglebone:green:usr1";
> > + gpios = <&gpio2 22 0>;
> > + linux,default-trigger = "mmc0";
> > + default-state = "off";
> > + };
> > +
> > + led2 {
> > + label = "beaglebone:green:usr2";
> > + gpios = <&gpio2 23 0>;
> > + default-state = "off";
> > + };
> > +
> > + led3 {
> > + label = "beaglebone:green:usr3";
> > + gpios = <&gpio2 24 0>;
> > + default-state = "off";
> > + };
> > + };
> > +
> > i2c1: i2c@44e0b000 {
> > status = "okay";
> > clock-frequency = <40>;
> > --
> > 1.7.9.5
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>
--
To unsubscribe from this list: send the line "unsubscribe 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] OMAPDSS: Misc improvements
On Fri, 2012-09-07 at 09:22 -0700, Tony Lindgren wrote: > * Tomi Valkeinen [120907 03:16]: > > On Thu, 2012-09-06 at 13:13 -0700, Tony Lindgren wrote: > > > * Tomi Valkeinen [120904 00:23]: > > > > Hi Tony, > > > > > > > > Can you check the arch/arm patches below, and suggest how you'd like to > > > > go forward with them? > > > > > > Acked them, then as soon as we have the initial immutable header > > > move branch available, you should merge with that to avoid > > > merge conflicts in upstream. > > > > Thanks, but you missed the first patch "[PATCH 1/8] OMAPDSS: HDMI: Move > > GPIO handling to HDMI driver". > > Oops sorry, that's a nice one, acked that too. BTW, do you have any > platform code callbacks remaining for DSS? Yes, for quite many boards: $ git grep platform_enable arch/arm/mach-omap2/|wc -l 17 Some of those are trivial, I just need to move the panel's reset gpio handling to the panel driver. But some fiddle around with board specific gpios that do not belong to the panel driver. Also some board files contain backlight handling. Those are for panel drivers, then there's also callbacks for the omapdss driver itself. get_context_loss_count, set_min_bus_tput, and dsi pin enable/disable. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH v7 1/3] arm/dts: AM33XX: Add basic pinctrl device tree data
* AnilKumar Ch [120906 02:39]:
> Adds basic pinctrl device tree data for AM33XX family of devices.
> This patch is based on the pinctrl-single driver.
>
> Signed-off-by: AnilKumar Ch
Assuming Benoit will queue this series:
Acked-by: Tony Lindgren
> ---
> arch/arm/boot/dts/am33xx.dtsi |9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index be43511..58cffb7 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -40,6 +40,15 @@
> };
> };
>
> + am33xx_pinmux: pinmux@44e10800 {
> + compatible = "pinctrl-single";
> + reg = <0x44e10800 0x0238>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + pinctrl-single,register-width = <32>;
> + pinctrl-single,function-mask = <0x7f>;
> + };
> +
> /*
>* XXX: Use a flat representation of the AM33XX interconnect.
>* The real AM33XX interconnect network is quite complex.Since
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] pinctrl: pinctrl-single: Add pinctrl-single,bits type of mux
* Peter Ujfalusi [120907 08:13]:
> On 09/06/2012 10:10 PM, Tony Lindgren wrote:
> >
> > Is it now safe to assume that we always have width of three if
> > pinctrl-single,bits is specified? The reason I'm asking is..
> >
> >> @@ -657,18 +664,29 @@ static int pcs_parse_one_pinctrl_entry(struct
> >> pcs_device *pcs,
> >> {
> >>struct pcs_func_vals *vals;
> >>const __be32 *mux;
> >> - int size, rows, *pins, index = 0, found = 0, res = -ENOMEM;
> >> + int size, params, rows, *pins, index = 0, found = 0, res = -ENOMEM;
> >>struct pcs_function *function;
> >>
> >> - mux = of_get_property(np, PCS_MUX_NAME, &size);
> >> - if ((!mux) || (size < sizeof(*mux) * 2)) {
> >> - dev_err(pcs->dev, "bad data for mux %s\n",
> >> - np->name);
> >> + mux = of_get_property(np, PCS_MUX_PINS_NAME, &size);
> >> + if (mux) {
> >> + params = 2;
> >> + } else {
> >> + mux = of_get_property(np, PCS_MUX_BITS_NAME, &size);
> >> + if (!mux) {
> >> + dev_err(pcs->dev, "no valid property for %s\n",
> >> + np->name);
> >> + return -EINVAL;
> >> + }
> >> + params = 3;
> >> + }
> >
> > ..because here we could assume the default value for params is 2
> > if pinctrl-single,pins is specified, and otherwise params is 3
> > if pinctrl-single,bits is specified for the controller. That would
> > avoid querying a potentially non-exiting property for each entry.
> >
> >> @@ -686,6 +704,10 @@ static int pcs_parse_one_pinctrl_entry(struct
> >> pcs_device *pcs,
> >>val = be32_to_cpup(mux + index++);
> >>vals[found].reg = pcs->base + offset;
> >>vals[found].val = val;
> >> + if (params == 3) {
> >> + val = be32_to_cpup(mux + index++);
> >> + vals[found].mask = val;
> >> + }
> >>
> >>pin = pcs_get_pin_by_offset(pcs, offset);
> >>if (pin < 0) {
> >
> > Here params too would be then set during probe already.
>
> I'm afraid you lost me here...
> We only know if the user specified the mux configuration with
> pinctrl-single,pins or pinctrl-single,bits in this function.
Sorry right, yeah we don't know that at probe time currently.
I'd like to have something that specifies the controller type so
we don't need to mix two types of controllers and test for
non-existing properties when parsing the pins.
How about we require something specified for the pinctrl driver
in the "one-bit-per-mux" case like pinctrl-single,bit-per-mux?
And then in the pinctrl-single probe we set params = 3 if
pinctrl-single,bit-per-mux is specified. And if no
pinctrl-single,bit-per-mux is specified then set params = 2.
That way pcs_parse_one_pinctrl_entry() can just test for params.
Sorry I don't have a better name in mind than bit-per-mux..
> One thing I could do to make the code a bit better to look at is:
> int params = 2;
>
> mux = of_get_property(np, PCS_MUX_PINS_NAME, &size);
> if (!mux) {
> mux = of_get_property(np, PCS_MUX_BITS_NAME, &size);
> if (!mux) {
> dev_err(pcs->dev, "no valid property for %s\n",
> np->name);
> return -EINVAL;
> }
> params = 3;
> }
>
> This might make the code a bit more compact but at the same time one might
> need to spend few more seconds to understand it.
Yes well there's no need to do of_get_property second guessing
if we already know params from the pinctrl-single.c probe time.
I think we're safe to assume that we don't need to mix parsing
two different types of configuration for the same controller
as they can always be set up as separate controllers.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] leds: leds-gpio: adopt pinctrl support
* Domenico Andreoli [120907 09:01]: > > So is this the preferred way to attach gpio users to gpio provides in DT > whenever gpios are muxed? > > I would well see these info hidden in the gpio controller so, at least > for gpios, no magic numbers would be required in the DT (except the gpio > number relative to the owning controller). In the pure GPIO pins only case it could be all done in the GPIO controller, but it's probably best to have the pins muxed by the drivers using them. Some drivers doing runtime PM may need to dynamically toggle the pins for idle mode to stop leakage, enable wakeup events for rx pins etc. Probably no need for that in the gpio leds case, but it would be confusing to have some pins claimed by the GPIO driver and some by the drivers using the pins. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] OMAPDSS: Misc improvements
* Tomi Valkeinen [120907 03:16]: > On Thu, 2012-09-06 at 13:13 -0700, Tony Lindgren wrote: > > * Tomi Valkeinen [120904 00:23]: > > > Hi Tony, > > > > > > Can you check the arch/arm patches below, and suggest how you'd like to > > > go forward with them? > > > > Acked them, then as soon as we have the initial immutable header > > move branch available, you should merge with that to avoid > > merge conflicts in upstream. > > Thanks, but you missed the first patch "[PATCH 1/8] OMAPDSS: HDMI: Move > GPIO handling to HDMI driver". Oops sorry, that's a nice one, acked that too. BTW, do you have any platform code callbacks remaining for DSS? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8] OMAPDSS: HDMI: Move GPIO handling to HDMI driver
* Tomi Valkeinen [120823 06:46]: > We currently manage HDMI GPIOs in the board files via > platform_enable/disable calls. This won't work with device tree, and in > any case the correct place to manage the GPIOs is in the HDMI driver. > > This patch moves the handling of the GPIOs to the HDMI driver. The GPIO > handling is moved to the common hdmi.c file, and this probably needs to > be revisited when adding OMAP5 HDMI support to see if the GPIO handling > needs to be moved to IP specific files. > > Signed-off-by: Tomi Valkeinen > Cc: Tony Lindgren This too looks safe to merge via fb tree: Acked-by: Tony Lindgren -- To unsubscribe from this list: send the line "unsubscribe 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] leds: leds-gpio: adopt pinctrl support
On Fri, Sep 7, 2012 at 3:59 PM, AnilKumar, Chimata wrote: > On Fri, Sep 07, 2012 at 05:39:35, Marek Vasut wrote: >> Dear Tony Lindgren, >> >> > * Marek Vasut [120905 19:05]: >> > > Hi Tony, >> > > >> > > > * Marek Vasut [120904 20:13]: >> > > > > Dear Bryan Wu, >> > > > > >> > > > > > On Sat, Sep 1, 2012 at 4:16 PM, AnilKumar Ch >> > > > > > wrote: >> > > > > > > Adopt pinctrl support to leds-gpio driver based on leds-gpio >> > > > > > > device pointer, pinctrl driver configure SoC pins to GPIO >> > > > > > > mode according to definitions provided in .dts file. >> > > > > > >> > > > > > Thanks for this, actually Marek Vasut submitted a similar patch >> > > > > > before. I'm pretty fine with this patch. >> > > > > >> > > > > Thanks for submitting this actually ... I didn't have time to >> > > > > properly investigate this. >> > > > > >> > > > > > But without proper DT setting, it will also give us warning I >> > > > > > think. or we can provide some dummy functions as a temp solution >> > > > > > as Shawn pointed out before. >> > > > > >> > > > > But this driver is also used on hardware that's not yet coverted to >> > > > > DT, so I'd say dev_warn() if CONFIG_OF is enabled and otherwise >> > > > > simply go on ? Actually, can we not skip whole this pinctrl thing if >> > > > > CONFIG_OF is disabled? Actually (2), what's the relationship between >> > > > > OF and pinctrl? >> > > > >> > > > The warning should be pinctrl related as the pinctrl drivers may not be >> > > > device tree based drivers. >> > > >> > > Exactly my concern. Also the warning shouldnt be present on systems where >> > > pinctrl is disabled. >> > >> > But pinctrl_get_select() returns 0 in include/linux/pinctrl/consumer.h if >> > CONFIG_PINCTRL is not selected, so no warning is produced AFAIK ;) >> >> Oh all right then. >> > > Bryan, > > If this patch looks fine, can you queue this for 3.7? > I've applied this to my for-next branch. Thanks, -Bryan -- To unsubscribe from this list: send the line "unsubscribe 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] leds: leds-gpio: adopt pinctrl support
On Fri, Sep 07, 2012 at 02:30:59PM +, AnilKumar, Chimata wrote:
> On Fri, Sep 07, 2012 at 16:32:51, Domenico Andreoli wrote:
> > On Fri, Sep 07, 2012 at 09:10:50AM +, AnilKumar, Chimata wrote:
> > > On Fri, Sep 07, 2012 at 14:18:39, Domenico Andreoli wrote:
> > > > On Sat, Sep 1, 2012 at 10:16 AM, AnilKumar Ch wrote:
> > > > > Adopt pinctrl support to leds-gpio driver based on leds-gpio
> > > > > device pointer, pinctrl driver configure SoC pins to GPIO
> > > > > mode according to definitions provided in .dts file.
> > > >
> > > > Shouldn't be the interaction with the pinctrl layer left to gpiolib?
> > > >
> > >
> > > No, these gpio's are configured specifically for user leds.
> >
> > So there are some special pad configs to make the leds work which are not
> > only muxing and direction setting? Because I expect these to be managed
> > privately between gpiolib and pinctrl but now I'm not sure any more,
> > I'll look the code.
>
> How can gpio driver knows that leds-gpio driver require
> these 4 pins?
because leds-gpio requests each gpio (specified in the DT against a specific
gpio controller) before assuming it is available? gpiolib then asks to
pinctrl if those pins are available for gpio and possibly reserve them
(configuring the mux, if necessary) for the device.
But this idea does not correspond to the code, so I must have filled in
the blanks of something I didn't fully understand.
> > > So, leds-gpio driver should have this call, because these gpio
> > > pins are used by leds-gpio driver.
> > >
> > > + am33xx_pinmux: pinmux@44e10800 {
> > > + userled_pins: pinmux_userled_pins {
> > > + pinctrl-single,pins = <
> > > + 0x54 0x7
> > > + 0x58 0x17
> > > + 0x5c 0x7
> > > + 0x60 0x17
> > > + >;
> > > + };
> > > + };
> > > +
> > >
> > > [...]
> > >
> > > + leds {
> > > + compatible = "gpio-leds";
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&userled_pins>;
> > >
> >
> > I'm surprised to not see any gpio controller (ala irq) involved.
>
> GPIO controller data will be in GPIO node, should not be here.
So is this the preferred way to attach gpio users to gpio provides in DT
whenever gpios are muxed?
I would well see these info hidden in the gpio controller so, at least
for gpios, no magic numbers would be required in the DT (except the gpio
number relative to the owning controller).
> > > Lets take gpio-keypad driver, in that case we have to configure
> > > pins as INPUT mode (generic gpio driver might not know what
> > > the end usecase is) and this leds case we configure as OUTPUT
> > > mode.
> >
> > gpio direction is modeled by gpiolib so, if no other out-of-gpiolib
> > capabilities are required for that led gpio, there is no need to directly
> > use pinctrl.
> >
>
> Here leds-gpio driver requirement is to set mux configuration of
> those 4 pins to GPIO mode (mode 7) as well direction OUTPUT/INPUT.
Direction info is passed to gpiolib in the exact instant
gpio_set_direction_*() is invoked.
> Set mux mode to 7 (GPIO usage) should be from led driver, because
> this driver have the requirement.
This GPIO mode value is known to the pinctrl driver, actually it's _specific_
for that driver. So the only info pinctrl would really need to know is which
pin is requested to be used as GPIO, something that gpiolib already manages.
So I really don't see why the gpiolib could not be (I've understood it isn't)
the one-stop for GPIO users. Of course direct pinctrl configuration would be
required for all those specific gpio parameters not modeled by the gpiolib
(like debounce times, etc).
cheers,
Domenico
--
To unsubscribe from this list: send the line "unsubscribe 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] watchdog: omap_wdt: convert to new watchdog core
On Fri, Sep 07, 2012 at 04:31:07PM +0300, Jarkko Nikula wrote: > On Tue, Sep 04, 2012 at 05:41:24PM +0300, Aaro Koskinen wrote: > > Convert omap_wdt to new watchdog core. On OMAP boards, there are usually > > multiple watchdogs. Since the new watchdog core supports multiple > > watchdogs, all watchdog drivers used on OMAP should be converted. > > > > The legacy watchdog device node is still created, so this should not > > break existing users. > > > > Signed-off-by: Aaro Koskinen > > --- > > drivers/watchdog/Kconfig|1 + > > drivers/watchdog/omap_wdt.c | 268 > > ++- > > 2 files changed, 115 insertions(+), 154 deletions(-) > > > Am I missing some extra patch but this causes a crash on top of v3.6-rc4 > commit eeea3ac? > > Crash happens in omap_wdt.c:99 on Nokia N9. Thanks for the report! I'll look into this and test with other Nokia boards. I tested the patch only with N800 and v3.6-rc4 (4cbe5a555fa58a79b6ecbb6c531b8bab0650778d) and did not see any issues with normal use cases (boot, watchdog open, feeding, watchdog close). A. -- To unsubscribe from this list: send the line "unsubscribe 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/5] arm/dts: Add omap36xx.dtsi file and rename omap3-beagle to omap3-beagle-xm
Hi Tony,
On 09/06/2012 08:58 PM, Tony Lindgren wrote:
> The extra serial port is not available on 34xx. And the current
> omap3-beagle.dts file is for omap3-beagle-xm.dts as it lists 512MB
> of memory.
Indeed, my Beagle is in fact a xM :-)
It is too bad that we do have to duplicate the DTS file for all the board
variants. Peter already did that for pandaES and at that time I was wondering
if this was needed or not.
That being said, I'm not sure we have any good way to handle two boards using
the same DTS. It means that will we will have to rely on the bootloader now to
select the proper DTB.
Please not that's I'm queuing a bunch of OMAP2/3/4/5/AM33XX for you, so you
might have to rebase that one on top.
The branch is there.
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
for_3.7/dts
I'm still waiting for a couple of AM33xx pinmux patches from Anil that should
re acked by some folks who know that (like you :-)).
I'll send you the pull request next week.
Regards,
Benoit
> Please somebody submit a new omap3-beagle.dts for the original 34xx
> BeagleBoard after testing it properly.
>
> Cc: Benoit Cousson
> Cc: devicetree-disc...@lists.ozlabs.org
> Signed-off-by: Tony Lindgren
> ---
> arch/arm/boot/dts/omap3-beagle-xm.dts |6 +++---
> arch/arm/boot/dts/omap3.dtsi |7 ---
> arch/arm/boot/dts/omap36xx.dtsi | 25 +
> arch/arm/mach-omap2/Makefile.boot |2 +-
> 4 files changed, 29 insertions(+), 11 deletions(-)
> rename arch/arm/boot/dts/{omap3-beagle.dts => omap3-beagle-xm.dts} (89%)
> create mode 100644 arch/arm/boot/dts/omap36xx.dtsi
>
> diff --git a/arch/arm/boot/dts/omap3-beagle.dts
> b/arch/arm/boot/dts/omap3-beagle-xm.dts
> similarity index 89%
> rename from arch/arm/boot/dts/omap3-beagle.dts
> rename to arch/arm/boot/dts/omap3-beagle-xm.dts
> index e60cba0..df6d485 100644
> --- a/arch/arm/boot/dts/omap3-beagle.dts
> +++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
> @@ -7,11 +7,11 @@
> */
> /dts-v1/;
>
> -/include/ "omap3.dtsi"
> +/include/ "omap36xx.dtsi"
>
> / {
> - model = "TI OMAP3 BeagleBoard";
> - compatible = "ti,omap3-beagle", "ti,omap3";
> + model = "TI OMAP3 BeagleBoard xM";
> + compatible = "ti,omap3-beagle-xm, ti,omap3-beagle", "ti,omap3";
>
> memory {
> device_type = "memory";
> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
> index 8109471..9965ed6 100644
> --- a/arch/arm/boot/dts/omap3.dtsi
> +++ b/arch/arm/boot/dts/omap3.dtsi
> @@ -17,7 +17,6 @@
> serial0 = &uart1;
> serial1 = &uart2;
> serial2 = &uart3;
> - serial3 = &uart4;
> };
>
> cpus {
> @@ -141,12 +140,6 @@
> clock-frequency = <4800>;
> };
>
> - uart4: serial@49042000 {
> - compatible = "ti,omap3-uart";
> - ti,hwmods = "uart4";
> - clock-frequency = <4800>;
> - };
> -
> i2c1: i2c@4807 {
> compatible = "ti,omap3-i2c";
> #address-cells = <1>;
> diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
> new file mode 100644
> index 000..96bf028
> --- /dev/null
> +++ b/arch/arm/boot/dts/omap36xx.dtsi
> @@ -0,0 +1,25 @@
> +/*
> + * Device Tree Source for OMAP3 SoC
> + *
> + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2. This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +
> +/include/ "omap3.dtsi"
> +
> +/ {
> + aliases {
> + serial3 = &uart4;
> + };
> +
> + ocp {
> + uart4: serial@49042000 {
> + compatible = "ti,omap3-uart";
> + ti,hwmods = "uart4";
> + clock-frequency = <4800>;
> + };
> + };
> +};
> diff --git a/arch/arm/mach-omap2/Makefile.boot
> b/arch/arm/mach-omap2/Makefile.boot
> index 6cf1c2d..0e602b7 100644
> --- a/arch/arm/mach-omap2/Makefile.boot
> +++ b/arch/arm/mach-omap2/Makefile.boot
> @@ -3,7 +3,7 @@ params_phys-y := 0x8100
> initrd_phys-y:= 0x8080
>
> dtb-$(CONFIG_SOC_OMAP2420) += omap2420-h4.dtb
> -dtb-$(CONFIG_ARCH_OMAP3) += omap3-beagle.dtb omap3-evm.dtb
> +dtb-$(CONFIG_ARCH_OMAP3) += omap3-beagle-xm.dtb omap3-evm.dtb
> dtb-$(CONFIG_ARCH_OMAP4) += omap4-panda.dtb omap4-pandaES.dtb
> dtb-$(CONFIG_ARCH_OMAP4) += omap4-var_som.dtb omap4-sdp.dtb
> dtb-$(CONFIG_SOC_OMAP5) += omap5-evm.dtb
>
--
To unsubscribe from this list: send the line "unsubscribe 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] serial: omap: fix compile breakage
On Fri, Sep 07, 2012 at 06:34:19PM +0300, Felipe Balbi wrote: > when rebasing patches on top of Greg's tty-next, > it looks like automerge broke a few things which > I didn't catch (for whatever reason I didn't > have OMAP Serial enabled on .config) so I ended > up breaking the build on Greg's tty-next branch. > > Fix the breakage by re-adding the three missing > members on struct uart_omap_port. > > Reported-by: Tony Lindgren > Signed-off-by: Felipe Balbi > --- > > Hi Greg, > > I just fetched your tree again and rebased again just to > make sure. Everything is fine here, let me know if it > still applies with fuzz. That worked, thanks. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] serial: omap: fix compile breakage
when rebasing patches on top of Greg's tty-next,
it looks like automerge broke a few things which
I didn't catch (for whatever reason I didn't
have OMAP Serial enabled on .config) so I ended
up breaking the build on Greg's tty-next branch.
Fix the breakage by re-adding the three missing
members on struct uart_omap_port.
Reported-by: Tony Lindgren
Signed-off-by: Felipe Balbi
---
Hi Greg,
I just fetched your tree again and rebased again just to
make sure. Everything is fine here, let me know if it
still applies with fuzz.
cheers
arch/arm/plat-omap/include/plat/omap-serial.h | 4
drivers/tty/serial/omap-serial.c | 4
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index 3c9fd3e..a531149 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -105,8 +105,4 @@ struct uart_omap_dma {
unsigned intrx_timeout;
};
-
- int DTR_gpio;
- int DTR_inverted;
- int DTR_active;
#endif /* __OMAP_SERIAL_H__ */
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index cfd2094..0a6e78e 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -100,6 +100,10 @@ struct uart_omap_port {
u8 wakeups_enabled;
unsigned intirq_pending:1;
+ int DTR_gpio;
+ int DTR_inverted;
+ int DTR_active;
+
struct pm_qos_request pm_qos_request;
u32 latency;
u32 calc_latency;
--
1.7.12.rc3
--
To unsubscribe from this list: send the line "unsubscribe 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] serial: omap: fix compile breakage
On Fri, Sep 07, 2012 at 08:25:31AM +0300, Felipe Balbi wrote: > when rebasing patches on top of Greg's tty-next, > it looks like automerge broke a few things which > I didn't catch (for whatever reason I didn't > have OMAP Serial enabled on .config) so I ended > up breaking the build on Greg's tty-next branch. > > Fix the breakage by re-adding the three missing > members on struct uart_omap_port. > > Reported-by: Tony Lindgren > Signed-off-by: Felipe Balbi > --- > > Changes since v1: > . remove the fields from > > arch/arm/plat-omap/include/plat/omap-serial.h | 4 > drivers/tty/serial/omap-serial.c | 4 > 2 files changed, 4 insertions(+), 4 deletions(-) This applies with fuzz, what tree did you make it against? patching file arch/arm/plat-omap/include/plat/omap-serial.h Hunk #1 succeeded at 105 with fuzz 1 (offset 26 lines). patching file drivers/tty/serial/omap-serial.c Hunk #1 succeeded at 100 (offset -23 lines). Should I still apply it? greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: OMAP4: Add reg and interrupts for every nodes
Thanks to Vaibhav omap_device fix
(ARM: OMAP: omap_device: Fix up resource names when booted with devicetre),
we can now specify reg and interrupts using standard device tree
attributes.
Update the OMAP4 dtsi file with missing reg and interrupts attributes.
Signed-off-by: Benoit Cousson
Cc: Santosh Shilimkar
Cc: Tony Lindgren
Cc: Felipe Balbi
---
Hi Tony,
This is the first step toward reduction of the hwmod data inside mach-omap2.
OMAP2/3/4 data still need to be there for legacy boards, but it will allow
OMAP5/AM33XX pure DT board to reduce the amount of data provided by hwmod.
DMA is still missing, but I hope that the discussion that happened during
LPC will fixed that soon.
Regards,
Benoit
arch/arm/boot/dts/omap4.dtsi | 55 ++
1 files changed, 55 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 9f851df..75095e3 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -97,6 +97,8 @@
gpio1: gpio@4a31 {
compatible = "ti,omap4-gpio";
+ reg = <0x4a31 0x200>;
+ interrupts = <0 29 0x4>;
ti,hwmods = "gpio1";
gpio-controller;
#gpio-cells = <2>;
@@ -106,6 +108,8 @@
gpio2: gpio@48055000 {
compatible = "ti,omap4-gpio";
+ reg = <0x48055000 0x200>;
+ interrupts = <0 30 0x4>;
ti,hwmods = "gpio2";
gpio-controller;
#gpio-cells = <2>;
@@ -115,6 +119,8 @@
gpio3: gpio@48057000 {
compatible = "ti,omap4-gpio";
+ reg = <0x48057000 0x200>;
+ interrupts = <0 31 0x4>;
ti,hwmods = "gpio3";
gpio-controller;
#gpio-cells = <2>;
@@ -124,6 +130,8 @@
gpio4: gpio@48059000 {
compatible = "ti,omap4-gpio";
+ reg = <0x48059000 0x200>;
+ interrupts = <0 32 0x4>;
ti,hwmods = "gpio4";
gpio-controller;
#gpio-cells = <2>;
@@ -133,6 +141,8 @@
gpio5: gpio@4805b000 {
compatible = "ti,omap4-gpio";
+ reg = <0x4805b000 0x200>;
+ interrupts = <0 33 0x4>;
ti,hwmods = "gpio5";
gpio-controller;
#gpio-cells = <2>;
@@ -142,6 +152,8 @@
gpio6: gpio@4805d000 {
compatible = "ti,omap4-gpio";
+ reg = <0x4805d000 0x200>;
+ interrupts = <0 34 0x4>;
ti,hwmods = "gpio6";
gpio-controller;
#gpio-cells = <2>;
@@ -151,30 +163,40 @@
uart1: serial@4806a000 {
compatible = "ti,omap4-uart";
+ reg = <0x4806a000 0x100>;
+ interrupts = <0 72 0x4>;
ti,hwmods = "uart1";
clock-frequency = <4800>;
};
uart2: serial@4806c000 {
compatible = "ti,omap4-uart";
+ reg = <0x4806c000 0x100>;
+ interrupts = <0 73 0x4>;
ti,hwmods = "uart2";
clock-frequency = <4800>;
};
uart3: serial@4802 {
compatible = "ti,omap4-uart";
+ reg = <0x4802 0x100>;
+ interrupts = <0 74 0x4>;
ti,hwmods = "uart3";
clock-frequency = <4800>;
};
uart4: serial@4806e000 {
compatible = "ti,omap4-uart";
+ reg = <0x4806e000 0x100>;
+ interrupts = <0 70 0x4>;
ti,hwmods = "uart4";
clock-frequency = <4800>;
};
i2c1: i2c@4807 {
compatible = "ti,omap4-i2c";
+ reg = <0x4807 0x100>;
+ interrupts = <0 56 0x4>;
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "i2c1";
@@ -182,6 +204,8 @@
i2c2: i2c@48072000 {
compatible = "ti,omap4-i2c";
+ reg = <0x48072000 0x100>;
+ interrupts = <0 57 0x4>;
#address-cells = <1>;
#size-cells = <0>;
Re: [PATCH 2/2] pinctrl: pinctrl-single: Add pinctrl-single,bits type of mux
Hi Tony,
On 09/06/2012 10:10 PM, Tony Lindgren wrote:
> Hi Peter,
>
> * Peter Ujfalusi [120905 02:02]:
>> With pinctrl-single,bits it is possible to update just part of the register
>> within the pinctrl-single,function-mask area.
>> This is useful when one register configures mmore than one pin's mux.
>
> You have a typo here: ^
Oh, I'll fix this up.
>> --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
>> +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
>> @@ -31,6 +31,15 @@ device pinctrl register, and 0x118 contains the desired
>> value of the
>> pinctrl register. See the device example and static board pins example
>> below for more information.
>>
>> +In case when one register changes more than one pin's mux the
>> +pinctrl-single,bits can be used which takes three parameters:
>> +
>> +pinctrl-single,bits = <0xdc 0x18, 0xff>;
>> +
>> +Where 0xdc is the offset from the pinctrl register base address for the
>> +device pinctrl register, 0x18 is the desired value, and 0xff is the sub
>> mask to
>> +be used when applying this change to the register.
>> +
>
> Is it now safe to assume that we always have width of three if
> pinctrl-single,bits is specified? The reason I'm asking is..
>
>> @@ -657,18 +664,29 @@ static int pcs_parse_one_pinctrl_entry(struct
>> pcs_device *pcs,
>> {
>> struct pcs_func_vals *vals;
>> const __be32 *mux;
>> -int size, rows, *pins, index = 0, found = 0, res = -ENOMEM;
>> +int size, params, rows, *pins, index = 0, found = 0, res = -ENOMEM;
>> struct pcs_function *function;
>>
>> -mux = of_get_property(np, PCS_MUX_NAME, &size);
>> -if ((!mux) || (size < sizeof(*mux) * 2)) {
>> -dev_err(pcs->dev, "bad data for mux %s\n",
>> -np->name);
>> +mux = of_get_property(np, PCS_MUX_PINS_NAME, &size);
>> +if (mux) {
>> +params = 2;
>> +} else {
>> +mux = of_get_property(np, PCS_MUX_BITS_NAME, &size);
>> +if (!mux) {
>> +dev_err(pcs->dev, "no valid property for %s\n",
>> +np->name);
>> +return -EINVAL;
>> +}
>> +params = 3;
>> +}
>
> ..because here we could assume the default value for params is 2
> if pinctrl-single,pins is specified, and otherwise params is 3
> if pinctrl-single,bits is specified for the controller. That would
> avoid querying a potentially non-exiting property for each entry.
>
>> @@ -686,6 +704,10 @@ static int pcs_parse_one_pinctrl_entry(struct
>> pcs_device *pcs,
>> val = be32_to_cpup(mux + index++);
>> vals[found].reg = pcs->base + offset;
>> vals[found].val = val;
>> +if (params == 3) {
>> +val = be32_to_cpup(mux + index++);
>> +vals[found].mask = val;
>> +}
>>
>> pin = pcs_get_pin_by_offset(pcs, offset);
>> if (pin < 0) {
>
> Here params too would be then set during probe already.
I'm afraid you lost me here...
We only know if the user specified the mux configuration with
pinctrl-single,pins or pinctrl-single,bits in this function.
One thing I could do to make the code a bit better to look at is:
int params = 2;
mux = of_get_property(np, PCS_MUX_PINS_NAME, &size);
if (!mux) {
mux = of_get_property(np, PCS_MUX_BITS_NAME, &size);
if (!mux) {
dev_err(pcs->dev, "no valid property for %s\n",
np->name);
return -EINVAL;
}
params = 3;
}
This might make the code a bit more compact but at the same time one might
need to spend few more seconds to understand it.
Regards,
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: [RFC PATCH] OMAPDSS: DISPC: Fix IRQ unregister race
Hi, On Thursday 06 September 2012 16:36:54 Tomi Valkeinen wrote: > Hi, > > On Sun, 2012-09-02 at 22:12 +0300, Dimitar Dimitrov wrote: > > Very rare kernel crashes are reported on a custom OMAP4 board. Kernel > > panics due to corrupted completion structure while executing > > > > dispc_irq_wait_handler(). Excerpt from kernel log: > > Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMP > > Unable to handle kernel paging request at virtual address 00400130 > > ... > > PC is at 0xebf205bc > > LR is at __wake_up_common+0x54/0x94 > > ... > > (__wake_up_common+0x0/0x94) > > (complete+0x0/0x60) > > (dispc_irq_wait_handler.36902+0x0/0x14) > > (omap_dispc_irq_handler+0x0/0x354) > > (handle_irq_event_percpu+0x0/0x188) > > (handle_irq_event+0x0/0x64) > > (handle_fasteoi_irq+0x0/0x10c) > > (generic_handle_irq+0x0/0x48) > > (asm_do_IRQ+0x0/0xc0) > > > > DISPC IRQ executes callbacks with dispc.irq_lock released. Hence > > unregister_isr() and DISPC IRQ might be running in parallel on different > > CPUs. So there is a chance that a callback is executed even though it > > has been unregistered. As omap_dispc_wait_for_irq_timeout() declares a > > completion on stack, the dispc_irq_wait_handler() callback might try to > > access a completion structure that is invalid. This leads to crashes and > > hangs. > > > > Solution is to divide unregister calls into two sets: > > 1. Non-strict unregistering of callbacks. Callbacks could safely be > > > > executed after unregistering them. This is the case with unregister > > calls from the IRQ handler itself. > > > > 2. Strict (synchronized) unregistering. Callbacks are not allowed > > > > after unregistering. This is the case with completion waiting. > > > > The above solution should satisfy one of the original intentions of the > > driver: callbacks should be able to unregister themselves. > > I think it'd be better to create a new function for the nosync version, > and keep the old name for the sync version. The reason for this is to > minimize the amount of changes, as I think this one needs to be applied > to stable kernel trees also. My intention was to force all callers to pick sides. In case of rebase issues we get link errors instead of rare and subtle run-time races. Still, if you think we should leave the old name untouched then I'll change my patch. > > Also, I think we need similar one for dsi.c, as it has the same kind of > irq handling. But with a quick glance only sync version is needed there. Thanks, I missed that. I'll try to fix and send again. > > However, I'm not quite sure about this approach. The fix makes sense, > but it makes me think if the irq handling is designed the wrong way. > > While debugging and fixing this, did you think some other irq handling > approach would be saner? I tried but could not come up with better approach. The main difficulty is that there are two contradicting requirements: 1. Some callbacks unregister other callbacks, including themselves, from DISPC IRQ context. 2. Some functions expect that once a callback is unregistered it is never executed. Hence it is natural to split callers into two sets. I'm open for suggestions. > > Tomi Thanks, Dimitar -- To unsubscribe from this list: send the line "unsubscribe 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] leds: leds-gpio: adopt pinctrl support
On Fri, Sep 07, 2012 at 16:32:51, Domenico Andreoli wrote:
> On Fri, Sep 07, 2012 at 09:10:50AM +, AnilKumar, Chimata wrote:
> > Hi Domenico,
>
> Hi,
>
> > On Fri, Sep 07, 2012 at 14:18:39, Domenico Andreoli wrote:
> > > On Sat, Sep 1, 2012 at 10:16 AM, AnilKumar Ch wrote:
> > > > Adopt pinctrl support to leds-gpio driver based on leds-gpio
> > > > device pointer, pinctrl driver configure SoC pins to GPIO
> > > > mode according to definitions provided in .dts file.
> > >
> > > Shouldn't be the interaction with the pinctrl layer left to gpiolib?
> > >
> >
> > No, these gpio's are configured specifically for user leds.
>
> So there are some special pad configs to make the leds work which are not
> only muxing and direction setting? Because I expect these to be managed
> privately between gpiolib and pinctrl but now I'm not sure any more,
> I'll look the code.
How can gpio driver knows that leds-gpio driver require
these 4 pins?
>
> > So, leds-gpio driver should have this call, because these gpio
> > pins are used by leds-gpio driver.
> >
> > + am33xx_pinmux: pinmux@44e10800 {
> > + userled_pins: pinmux_userled_pins {
> > + pinctrl-single,pins = <
> > + 0x54 0x7
> > + 0x58 0x17
> > + 0x5c 0x7
> > + 0x60 0x17
> > + >;
> > + };
> > + };
> > +
> >
> > [...]
> >
> > + leds {
> > + compatible = "gpio-leds";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&userled_pins>;
> >
>
> I'm surprised to not see any gpio controller (ala irq) involved.
GPIO controller data will be in GPIO node, should not be here.
>
> > Lets take gpio-keypad driver, in that case we have to configure
> > pins as INPUT mode (generic gpio driver might not know what
> > the end usecase is) and this leds case we configure as OUTPUT
> > mode.
>
> gpio direction is modeled by gpiolib so, if no other out-of-gpiolib
> capabilities are required for that led gpio, there is no need to directly
> use pinctrl.
>
Here leds-gpio driver requirement is to set mux configuration of
those 4 pins to GPIO mode (mode 7) as well direction OUTPUT/INPUT.
Set mux mode to 7 (GPIO usage) should be from led driver, because
this driver have the requirement.
Thanks
AnilKumar
--
To unsubscribe from this list: send the line "unsubscribe 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] watchdog: omap_wdt: convert to new watchdog core
Hi On Tue, Sep 04, 2012 at 05:41:24PM +0300, Aaro Koskinen wrote: > Convert omap_wdt to new watchdog core. On OMAP boards, there are usually > multiple watchdogs. Since the new watchdog core supports multiple > watchdogs, all watchdog drivers used on OMAP should be converted. > > The legacy watchdog device node is still created, so this should not > break existing users. > > Signed-off-by: Aaro Koskinen > --- > drivers/watchdog/Kconfig|1 + > drivers/watchdog/omap_wdt.c | 268 > ++- > 2 files changed, 115 insertions(+), 154 deletions(-) > Am I missing some extra patch but this causes a crash on top of v3.6-rc4 commit eeea3ac? Crash happens in omap_wdt.c:99 on Nokia N9. -- Jarkko -- To unsubscribe from this list: send the line "unsubscribe 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 08/14] Input: twl4030-vibra: Support for DT booted kernel
Hi Dmitry, On 09/06/2012 07:19 PM, Dmitry Torokhov wrote: > In patch 6 you added a stub for of_find_node_by_name(), so do you really > need this #ifdef? True. I'll resend the series since I left the #ifdef also in other patch. > Otherwise it looks good. > > Acked-by: Dmitry Torokhov Thank you, Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] arm/dts: AM33XX: Add SPI device tree data
On Thu, Sep 06, 2012 at 12:30:15PM +0530, Philip, Avinash wrote:
> Add McSPI data node to AM33XX device tree file. The McSPI module (and so
> as the driver) is reused from OMAP4.
>
> Signed-off-by: Philip, Avinash
> ---
> Resenting patch because ARM & OMAP mailing list was not copied.
>
> :100644 100644 bb31bff... 6b469bd... March/arm/boot/dts/am33xx.dtsi
> arch/arm/boot/dts/am33xx.dtsi | 25 +
> 1 files changed, 25 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index bb31bff..6b469bd 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -210,5 +210,30 @@
> interrupt-parent = <&intc>;
> interrupts = <91>;
> };
> +
> + spi0: spi@4803 {
> + compatible = "ti,omap4-mcspi";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x483 0x400>;
Please fix this typo, should be 0x4803.
With the typo fixed, it's working on bone for me:
Tested-by: Matt Porter
-Matt
--
To unsubscribe from this list: send the line "unsubscribe 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/17] OMAPDSS: clean up dss_mgr_set_timings
On Friday 07 September 2012 03:41 PM, Tomi Valkeinen wrote:
On Wed, 2012-09-05 at 11:25 +0300, Tomi Valkeinen wrote:
dss_mgr_set_timings() can only be called when the output is not active.
This means that most of the code in the function is extra, as there's no
need to write the values to registers, etc, because that will be handled
when the output will be enabled.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/apply.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index 53629dd..1b49019 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -1314,21 +1314,19 @@ void dss_mgr_set_timings(struct omap_overlay_manager
*mgr,
const struct omap_video_timings *timings)
{
unsigned long flags;
-
- mutex_lock(&apply_lock);
+ struct mgr_priv_data *mp = get_mgr_priv(mgr);
spin_lock_irqsave(&data_lock, flags);
- dss_apply_mgr_timings(mgr, timings);
-
- dss_write_regs();
- dss_set_go_bits();
+ if (mp->enabled) {
+ DSSERR("cannot set timings for %s: manager needs to be
disabled\n",
+ mgr->name);
+ goto out;
+ }
There was a problem with this one. When using manual update display, we
call set_timings before each update, and the mgr is enabled at that
time.
I'll fix this by changing the check from mp->enabled to mp->updating.
That flag tells if the DISPC channel is actually enabled or not. Enabled
flag just tells that the channel is being reserved, although for auto
update displays that also implies "updating".
But do you see any reason to call set_timings before each update? It was
required when we have partial update support, but now we support only
full screen updates, so isn't it enough to set the timings just once
when configuring?
I think we put it there for rotation. We may need to swap manager width
and height before an update.
Archit
--
To unsubscribe from this list: send the line "unsubscribe 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: Perf doesn't support coresight or it doesn't read the PMU registers on Pandaboard Rev.A2
On Fri, Sep 7, 2012 at 1:07 PM, Vanni Genua wrote: > > > Hi there, > I'm testing a Pandaboard (OMAP4430, ARMv7) with Linux kernel 3.0.27-rt46 > installed on it. > The following instruction is not working due to unsupported cache-misses > event. > #perf stat -e cache-misses echo "Hello" > Performance counter stats for 'echo "Hello" ': > > cache-misses > >0.007507575 seconds time elapsed > > How to solve this problem? > Is there any patch for Perf o Linux kernel? You are missing some patches which recently got sorted out to get PMU event work on OMAP. Patches are against the latest tree, you can find on Jon's tree [1] They are against Linux 3.6-rc2, so you may have to back-port them to get counters working on 3.0.X kernel. Regards Santosh [1] https://github.com/jonhunter/linux/tree/dev-pmu -- To unsubscribe from this list: send the line "unsubscribe 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] leds: leds-gpio: adopt pinctrl support
On Fri, Sep 07, 2012 at 09:10:50AM +, AnilKumar, Chimata wrote:
> Hi Domenico,
Hi,
> On Fri, Sep 07, 2012 at 14:18:39, Domenico Andreoli wrote:
> > On Sat, Sep 1, 2012 at 10:16 AM, AnilKumar Ch wrote:
> > > Adopt pinctrl support to leds-gpio driver based on leds-gpio
> > > device pointer, pinctrl driver configure SoC pins to GPIO
> > > mode according to definitions provided in .dts file.
> >
> > Shouldn't be the interaction with the pinctrl layer left to gpiolib?
> >
>
> No, these gpio's are configured specifically for user leds.
So there are some special pad configs to make the leds work which are not
only muxing and direction setting? Because I expect these to be managed
privately between gpiolib and pinctrl but now I'm not sure any more,
I'll look the code.
> So, leds-gpio driver should have this call, because these gpio
> pins are used by leds-gpio driver.
>
> + am33xx_pinmux: pinmux@44e10800 {
> + userled_pins: pinmux_userled_pins {
> + pinctrl-single,pins = <
> + 0x54 0x7
> + 0x58 0x17
> + 0x5c 0x7
> + 0x60 0x17
> + >;
> + };
> + };
> +
>
> [...]
>
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <&userled_pins>;
>
I'm surprised to not see any gpio controller (ala irq) involved.
> Lets take gpio-keypad driver, in that case we have to configure
> pins as INPUT mode (generic gpio driver might not know what
> the end usecase is) and this leds case we configure as OUTPUT
> mode.
gpio direction is modeled by gpiolib so, if no other out-of-gpiolib
capabilities are required for that led gpio, there is no need to directly
use pinctrl.
maybe I've just got it wrong. sorry.
thanks,
Domenico
--
To unsubscribe from this list: send the line "unsubscribe 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: Converting OMAP's custom vram allocator
On Fri, 2012-09-07 at 07:55 +0200, Marek Szyprowski wrote: > Hello, > > On Wednesday, September 05, 2012 12:09 PM Tomi Valkeinen wrote: > > > OMAP has a custom video ram allocator, which I'd like to remove and use > > the standard dma allocation functions. > > > > There are two problems for which I'd like to hear suggestions or > > comments: > > > > First one is that the dma_alloc_* functions map the allocated memory for > > cpu use. In many cases with OMAP DSS (display subsystem) this is not > > needed: the memory may be written only by the SGX or the DSP, and it's > > only read by the DSS, so it's never touched by the CPU. > > > > This is even more true when using VRFB on omap3 (and probably TILER on > > omap4) for rotation, as VRFB hides the actual memory and offers rotated > > views. In this case the backend memory is never accessed by anyone else > > than VRFB. > > > > Is there a way to allocate the memory without creating a mapping? While > > it won't break anything as such, the allocated areas can be quite large > > thus causing large areas of the kernel's memory space to be needlessly > > reserved. > > Please check commits d5724f172fd1 and 955c757e090 merged to v3.6-rc1. > Support for this attribute is now only available in IOMMU-aware > dma-mapping implementation, but I plan to add it also to standard linear > ARM dma-mapping implementation based on alloc_pages_exact(). Ok, good to know. Do you have any guestimate when the non-iommu version could end up in the mainline? Any chance for 3.7? I volunteer for testing if needed =). > Some not-well-documented example can be found here: > https://patchwork.kernel.org/patch/1323591/ (at the bottom). > > You probably might need to add your own custom dma_map_ops set of functions > for TILER device, but I'm not really sure if I get right what does that > device do and what will be the use cases for it. I think we have three different cases how we need to manage the memory used for video on OMAP. 1) Conventional case, without VRFB/TILER. We need large contiguous areas. I think we usually want both normal kernel and userspace mapping in this case, although some use cases could not need those. 2) VRFB (omap3). In this case we need large contigous area, which is given to the VRFB hardware to be used as a storage. This area is never mapped. VRFB offers four rotated "views" (i.e. memory areas), which give a 0/90/180/270 degree view of the same image, and we will create mapping of these views with ioremap. The actual data is stored in the memory by VRFB in a proprietary format. 3) TILER (omap4). I'm not too familiar with TILER, but afaik it's kinda like a better version of VRFB. In this case we don't need contiguous memory, but like VRFB, we never create mapping for the memory. (Rob, correct me if I'm wrong). I think we can manage all of those with dma_alloc_attrs(), even though contiguous area is not really needed for TILER. So, if I define DMA_ATTR_NO_KERNEL_MAPPING, there's no point in defining DMA_ATTR_WRITE_COMBINE at the same time, right? Can I still create the kernel mapping for the allocated memory later, yielding the same result as if I would've omitted DMA_ATTR_NO_KERNEL_MAPPING? > > The second case is passing a framebuffer address from the bootloader to > > the kernel. Often with mobile devices the bootloader will initialize the > > display hardware, showing a company logo or such. To keep the image on > > the screen when kernel starts we need to reserve the same physical > > memory area early at boot, and use that for the framebuffer. > > > > I'm not sure if there's any actual problem with this one, presuming > > there is a solution for the first case. Somehow the memory is reserved > > at early boot time, and this is passed to the fb driver. But can the > > memory be managed the same way as in normal case (for example freeing > > it), or does it need to be handled as a special case? > > The only solution I see here is to use custom coherent memory pool for the > framebuffer device and setup it starting from the physical address of the > framebuffer configured by bootloader. See dma_declare_coherent() function. > Some usage example on ARM architecture can be found in > arch/arm/plat-samsung/s5p-dev-mfc.c > > The other possibility is to enable Contiguous Memory Allocator and define > a custom contiguous memory area for framebuffer device at the same > physical address as configured by bootloader: > http://git.linaro.org/gitweb?p=people/mszyprowski/linux-archive.git;a=commitdiff;h=f8ff4f99cfa4f67e09a3c948e007e82a0c21434a > > Feel free to comment both possibilities, maybe we can work out something > better for solving this quite common use case. I think CMA is definitely the way to go. But I'm not quite sure how it should be used in this case. I understand how to reserve the memory area at boot time, as the patch in your link shows, but how should the driver get the memory? Normally the driver would just use dma_alloc_*, and
Re: [PATCH 0/8] OMAPDSS: Misc improvements
On Thu, 2012-09-06 at 13:13 -0700, Tony Lindgren wrote: > * Tomi Valkeinen [120904 00:23]: > > Hi Tony, > > > > Can you check the arch/arm patches below, and suggest how you'd like to > > go forward with them? > > Acked them, then as soon as we have the initial immutable header > move branch available, you should merge with that to avoid > merge conflicts in upstream. Thanks, but you missed the first patch "[PATCH 1/8] OMAPDSS: HDMI: Move GPIO handling to HDMI driver". Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH 12/17] OMAPDSS: clean up dss_mgr_set_timings
On Wed, 2012-09-05 at 11:25 +0300, Tomi Valkeinen wrote:
> dss_mgr_set_timings() can only be called when the output is not active.
> This means that most of the code in the function is extra, as there's no
> need to write the values to registers, etc, because that will be handled
> when the output will be enabled.
>
> Signed-off-by: Tomi Valkeinen
> ---
> drivers/video/omap2/dss/apply.c | 18 --
> 1 file changed, 8 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
> index 53629dd..1b49019 100644
> --- a/drivers/video/omap2/dss/apply.c
> +++ b/drivers/video/omap2/dss/apply.c
> @@ -1314,21 +1314,19 @@ void dss_mgr_set_timings(struct omap_overlay_manager
> *mgr,
> const struct omap_video_timings *timings)
> {
> unsigned long flags;
> -
> - mutex_lock(&apply_lock);
> + struct mgr_priv_data *mp = get_mgr_priv(mgr);
>
> spin_lock_irqsave(&data_lock, flags);
>
> - dss_apply_mgr_timings(mgr, timings);
> -
> - dss_write_regs();
> - dss_set_go_bits();
> + if (mp->enabled) {
> + DSSERR("cannot set timings for %s: manager needs to be
> disabled\n",
> + mgr->name);
> + goto out;
> + }
There was a problem with this one. When using manual update display, we
call set_timings before each update, and the mgr is enabled at that
time.
I'll fix this by changing the check from mp->enabled to mp->updating.
That flag tells if the DISPC channel is actually enabled or not. Enabled
flag just tells that the channel is being reserved, although for auto
update displays that also implies "updating".
But do you see any reason to call set_timings before each update? It was
required when we have partial update support, but now we support only
full screen updates, so isn't it enough to set the timings just once
when configuring?
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCHv4 4/8] ARM: OMAP3: add manual control for mpu / core pwrdm usecounting
On Mon, 2012-08-06 at 12:14 +0200, Jean Pihet wrote: > Hi Tero, > > On Mon, Jul 30, 2012 at 10:40 AM, Tero Kristo wrote: > > On Fri, 2012-07-27 at 12:36 -0700, Kevin Hilman wrote: > >> Tero Kristo writes: > >> > >> > mpu / core powerdomain usecounts are now statically increased > >> > by 1 during MPU activity. This allows the domains to reflect > >> > actual usage, and will allow the usecount to reach 0 just before > >> > all CPUs are ready to idle. Proper powerdomain usecounts are > >> > propageted to voltagedomain level also, and will allow vc > >> > callbacks to be triggered at right point of time. > >> > > >> > Signed-off-by: Tero Kristo > >> > Cc: Paul Walmsley > >> > Cc: Kevin Hilman > >> > >> IMO, the idea is fine, but I'm not crazy about the implementation in > >> powerdomain.c, which is meant for pwrdm generic code. In particular, > >> I'm not crazy about the pwrdm lookups in powerdomain.c. > >> > >> Since pm.c already has references to mpu_pwrdm and core_pwrdm, why > >> not just add the pwrdm_clkdm_enable/disable calls directly in pm.c > > > > I think this was how the patch was in some earlier rev but I thought I'd > > try to be more clever with this. :) I can revert the implementation back > > to this. > Furthermore after the changes in pre/post transitions [1], some more > checks will be needed to identify the transitions on the mpu and core > power domains. > > [1] > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=e055548953355b6e69c56f9e54388845b29b4e97 > > Regards, > Jean Hi Kevin, What is the latest status regarding this one, seeing the patch mentioned got reverted due to problems? Should I do some changes for this or not? I can look at moving the code away from the generic powerdomain.c at least, but is there anything else? -Tero > > > > >> Also, the changelog should be a bit more specific about why CORE > >> powerdomain is also handled here when most of the code only talks about > >> the CPU. > > > > Yea, I'll add some beef to this also. > > > > -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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 2/8] ARM: OMAP3+: voltage/pwrdm/clkdm/clock add recursive usecount tracking
On Mon, 2012-08-06 at 16:31 -0700, Kevin Hilman wrote:
> Tero Kristo writes:
>
> > This patch fixes the usecount tracking for omap3+, previously the
> > usecount numbers were rather bogus and were not really useful for
> > any purpose. Now usecount numbers track the number of really active
> > clients on each domain. This patch also adds support for usecount
> > tracking on powerdomain level and autoidle flag for clocks that
> > are hardware controlled and should be skipped in usecount
> > calculations.
> >
> > Signed-off-by: Tero Kristo
> > Cc: Paul Walmsley
> > Cc: Kevin Hilman
>
> [...]
>
> > /* Clock control for DPLL outputs */
> > diff --git a/arch/arm/mach-omap2/powerdomain.c
> > b/arch/arm/mach-omap2/powerdomain.c
> > index 9611490..68bdf36 100644
> > --- a/arch/arm/mach-omap2/powerdomain.c
> > +++ b/arch/arm/mach-omap2/powerdomain.c
> > @@ -981,6 +981,41 @@ int pwrdm_state_switch(struct powerdomain *pwrdm)
> > return ret;
> > }
> >
> > +/**
> > + * pwrdm_clkdm_enable - increment powerdomain usecount
> > + * @pwrdm: struct powerdomain *
> > + *
> > + * Increases the usecount for a powerdomain. Called from clockdomain
> > + * code once a clockdomain's usecount reaches zero, i.e. it is ready
> > + * to idle.
> > + */
>
> I think the comment here is wrong.
>
> > +void pwrdm_clkdm_enable(struct powerdomain *pwrdm)
> > +{
> > + if (!pwrdm)
> > + return;
> > +
> > + atomic_inc(&pwrdm->usecount);
> > +}
> > +
> > +/**
> > + * pwrdm_clkdm_disable - decrease powerdomain usecount
> > + * @pwrdm: struct powerdomain *
> > + *
> > + * Decreases the usecount for a powerdomain. Called from clockdomain
> > + * code once a clockdomain becomes active.
> > + */
>
> Looks like these two comments need to be swapped?
Ooops, that is true yes. Again my laziness in writing proper comments
bites me.
-Tero
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] leds: leds-gpio: adopt pinctrl support
Hi Domenico,
On Fri, Sep 07, 2012 at 14:18:39, Domenico Andreoli wrote:
> On Sat, Sep 1, 2012 at 10:16 AM, AnilKumar Ch wrote:
> > Adopt pinctrl support to leds-gpio driver based on leds-gpio
> > device pointer, pinctrl driver configure SoC pins to GPIO
> > mode according to definitions provided in .dts file.
>
> Shouldn't be the interaction with the pinctrl layer left to gpiolib?
>
No, these gpio's are configured specifically for user leds.
So, leds-gpio driver should have this call, because these gpio
pins are used by leds-gpio driver.
+ am33xx_pinmux: pinmux@44e10800 {
+ userled_pins: pinmux_userled_pins {
+ pinctrl-single,pins = <
+ 0x54 0x7
+ 0x58 0x17
+ 0x5c 0x7
+ 0x60 0x17
+ >;
+ };
+ };
+
[...]
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&userled_pins>;
This devm_pinctrl_get_select_default() call in leds-gpio driver
will internally take userled_pins node and configure those pins
according to the above definitions.
Lets take gpio-keypad driver, in that case we have to configure
pins as INPUT mode (generic gpio driver might not know what
the end usecase is) and this leds case we configure as OUTPUT
mode.
Thanks
AnilKumar
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] arm: omap: hwmod: make *phy_48m* as the main_clk of ocp2scp
Made *ocp2scp_usb_phy_phy_48m* as the main_clk for ocp2scp.
Since this ocp2scp module does not have any fck but does have a
single opt_clock, it is added as the main_clk for ocp2scp. Also
removed phy_48m as the optional clock since it is now made as the
main clock. By this the driver need not enable/disable phy_48m clk
separately and runtime_get/runtime_put will take care of that.
Cc: Benoît Cousson
Reviewed-by: Felipe Balbi
Signed-off-by: Kishon Vijay Abraham I
---
Changes for v1:
Amend the comment section with benefit for the driver because of this patch.
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 242aee4..e8e5405 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2503,14 +2503,11 @@ static struct omap_hwmod_class
omap44xx_ocp2scp_hwmod_class = {
};
/* ocp2scp_usb_phy */
-static struct omap_hwmod_opt_clk ocp2scp_usb_phy_opt_clks[] = {
- { .role = "phy_48m", .clk = "ocp2scp_usb_phy_phy_48m" },
-};
-
static struct omap_hwmod omap44xx_ocp2scp_usb_phy_hwmod = {
.name = "ocp2scp_usb_phy",
.class = &omap44xx_ocp2scp_hwmod_class,
.clkdm_name = "l3_init_clkdm",
+ .main_clk = "ocp2scp_usb_phy_phy_48m",
.prcm = {
.omap4 = {
.clkctrl_offs =
OMAP4_CM_L3INIT_USBPHYOCP2SCP_CLKCTRL_OFFSET,
@@ -2518,8 +2515,6 @@ static struct omap_hwmod omap44xx_ocp2scp_usb_phy_hwmod =
{
.modulemode = MODULEMODE_HWCTRL,
},
},
- .opt_clks = ocp2scp_usb_phy_opt_clks,
- .opt_clks_cnt = ARRAY_SIZE(ocp2scp_usb_phy_opt_clks),
};
/*
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/2] gpio-twl4030: add new device tree properties
On 09/06/2012 10:51 PM, Tony Lindgren wrote: > * Benoit Cousson [120905 07:42]: >> Hi Florian, >> >> On 09/05/2012 09:46 AM, Florian Vaussard wrote: >>> Hello, >>> >>> A number of platform data are missing when using twl4030/gpio from a >>> device tree. This patchset adds the missing properties, updates the >>> documentation with the new bindings, and updates existing device trees. >>> It mainly enables LEDA and LEDB outputs, as well as pullups / >>> pulldowns on GPIOs. >>> >>> The 1st patch changes the device driver and updates the documentation. >>> The 2nd patch updates the device trees for BeagleBoard and omap3-evm. >>> >>> Changes since v1: >>> - Patches on driver and documentation merged into the same patch >>> - Put device trees' values in hexadecimal >>> - Handle bool property using of_property_read_bool() >>> - Prefix the patches with the correct convention >> >> Thanks for the update. >> >>> Tested on Gumstix Overo. V1 was tested on omap3-evm by Vaibhav Hiremath. >> >> I've just tested it on beagle xM. I can play with D12 led using: >> >> echo 255 > /sys/class/leds/beagleboard\:\:pmu_stat/brightness >> >> Tested-by: Benoit Cousson >> >> >>> BTW: who will merge this? >> >> Since Linus already acked it, Tony can merge it. >> >> >> Tony, >> >> I can add that series in my DTS series for 3.7 if you want. > > Yes please do thanks. On top of that series, I realized that beagle was missing the other LEDs. So I've just posted the support for the two missing ones. [PATCH] ARM: dts: omap3-beagle: Add heartbeat and mmc LEDs support Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: omap3-beagle: Add heartbeat and mmc LEDs support
Add the support for D6 and D7 LEDs on Beagle board.
- D6 will be used for heartbeat
- D7 will be used for mmc0
Signed-off-by: Benoit Cousson
---
It is based on top of the LEDB support added by Florian.
Regards,
Benoit
arch/arm/boot/dts/omap3-beagle.dts | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index 3fe35c2..ca46fb2 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -24,6 +24,18 @@
label = "beagleboard::pmu_stat";
gpios = <&twl_gpio 19 0>; /* LEDB */
};
+
+ heartbeat {
+ label = "beagleboard::usr0";
+ gpios = <&gpio5 22 0>; /* 150 -> D6 LED */
+ linux,default-trigger = "heartbeat";
+ };
+
+ mmc {
+ label = "beagleboard::usr1";
+ gpios = <&gpio5 21 0>; /* 149 -> D7 LED */
+ linux,default-trigger = "mmc0";
+ };
};
};
--
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 v2] leds: leds-gpio: adopt pinctrl support
On Sat, Sep 1, 2012 at 10:16 AM, AnilKumar Ch wrote: > Adopt pinctrl support to leds-gpio driver based on leds-gpio > device pointer, pinctrl driver configure SoC pins to GPIO > mode according to definitions provided in .dts file. Shouldn't be the interaction with the pinctrl layer left to gpiolib? Cheers, Domenico -- To unsubscribe from this list: send the line "unsubscribe 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 v7 2/3] arm/dts: AM33XX: Configure pinmuxs for user leds control on Bone
Op 6 sep. 2012, om 11:38 heeft AnilKumar Ch het volgende
geschreven:
> Adds GPIO pinctrl nodes to am3358_pinmux master node to control
> user leds (USR0, USR1, USR2 and USR3) present on BeagleBone.
>
> [k...@dominion.thruhere.net: led0, led1 suggested by koen]
> Signed-off-by: AnilKumar Ch
Acked-by: Koen Kooi
> ---
> arch/arm/boot/dts/am335x-bone.dts | 43 +
> 1 file changed, 43 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am335x-bone.dts
> b/arch/arm/boot/dts/am335x-bone.dts
> index c634f87..b0a7409 100644
> --- a/arch/arm/boot/dts/am335x-bone.dts
> +++ b/arch/arm/boot/dts/am335x-bone.dts
> @@ -18,11 +18,54 @@
> reg = <0x8000 0x1000>; /* 256 MB */
> };
>
> + am33xx_pinmux: pinmux@44e10800 {
> + userled_pins: pinmux_userled_pins {
> + pinctrl-single,pins = <
> + 0x54 0x7/* gpmc_a5.gpio1_21, OUTPUT |
> MODE7 */
> + 0x58 0x17 /* gpmc_a6.gpio1_22,
> OUTPUT_PULLUP | MODE7 */
> + 0x5c 0x7/* gpmc_a7.gpio1_23, OUTPUT |
> MODE7 */
> + 0x60 0x17 /* gpmc_a8.gpio1_24,
> OUTPUT_PULLUP | MODE7 */
> + >;
> + };
> + };
> +
> ocp {
> uart1: serial@44e09000 {
> status = "okay";
> };
>
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <&userled_pins>;
> +
> + heartbeat {
> + label = "beaglebone:green:usr0";
> + gpios = <&gpio2 21 0>;
> + linux,default-trigger = "heartbeat";
> + default-state = "off";
> + };
> +
> + mmc {
> + label = "beaglebone:green:usr1";
> + gpios = <&gpio2 22 0>;
> + linux,default-trigger = "mmc0";
> + default-state = "off";
> + };
> +
> + led2 {
> + label = "beaglebone:green:usr2";
> + gpios = <&gpio2 23 0>;
> + default-state = "off";
> + };
> +
> + led3 {
> + label = "beaglebone:green:usr3";
> + gpios = <&gpio2 24 0>;
> + default-state = "off";
> + };
> + };
> +
> i2c1: i2c@44e0b000 {
> status = "okay";
> clock-frequency = <40>;
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe 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 1/8] ARM/dts: OMAP2: Add McBSP entries for OMAP2420 and OMAP2430 SoC
Hi Anil, On 09/07/2012 07:45 AM, AnilKumar, Chimata wrote: > On Wed, Sep 05, 2012 at 20:11:11, Hiremath, Vaibhav wrote: >> On Wed, Sep 05, 2012 at 19:01:55, Cousson, Benoit wrote: >>> Hi Vaibhav, >>> >>> On 09/05/2012 11:15 AM, Hiremath, Vaibhav wrote: On Wed, Sep 05, 2012 at 13:53:58, Ujfalusi, Peter wrote: > Hi, > > On 09/05/2012 09:11 AM, Hiremath, Vaibhav wrote: >>> Not yet, but we discussed that with Peter and since he does have these >>> patches for DT, he'll be able to test your series with the McBSP >>> changes. >>> >> >> Great. > > With his series and your patch for omap-hwmod audio was probing and > working on > OMAP3/4/5 without issues. > Peter, Care to provide your Tested-By?? Benoit, Can we merge this patch now? >>> >>> Yes, I'll include it in the pull request along with DTS patches. >>> >>> I've just tested it as well on OMAP4 by hacking the DTS for GPIO. >>> I'll try to update at least all the OMAP4 IPs as well with the proper >>> DTS resources for 3.7. >>> >> >> Thanks Benoit, >> >> There are other patches which are pending, >> >> arm/dts: AM33XX: Convert all hex numbers to lower-case >> https://patchwork.kernel.org/patch/1377351/ >> arm/dts: AM33XX: Specify reg and interrupt property for all nodes >> https://patchwork.kernel.org/patch/1377361/ >> > > Few more DT patches which are pending > > arm/dts: AM33XX: Add basic pinctrl device tree data > http://www.spinics.net/lists/linux-omap/msg76684.html > arm/dts: AM33XX: Configure pinmuxs for user leds control on Bone > http://www.spinics.net/lists/linux-omap/msg76682.html > arm/dts: AM33XX: Add D_CAN device tree data > http://www.spinics.net/lists/linux-omap/msg76683.html These ones still need some acks, but looks fine to me. Can you rebase them on top of the branch that already contains some AM33xx patches from Vaibhav: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.7/dts While you are rebasing, could you as well change the subject to use "ARM: dts: " prefix. It looks like everybody is using that convention now beside OMAP :-( Thanks, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/3] arm/dts: Add device tree data for AM33XX devices
Hi Anil, On 09/07/2012 07:30 AM, AnilKumar, Chimata wrote: > On Thu, Sep 06, 2012 at 15:08:21, AnilKumar, Chimata wrote: >> Add pinctrl and d_can device tree data to AM33XX family of devices. >> First two patches add support for pinctrl DT data and third one >> adds dcan DT data. >> >> Reason behind combining these patches is to apply cleanly on >> linux-omap tree, because these are sequential patches. >>Yes, >> These patches were tested on AM335x-Bone, AM335x-EVM and based >> on linux-omap:master with this patch >> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg74393.html >> > > If there are no changes in this patch series ACK from > reviewers (esp. Tony, koen and Marc) will help. Yes, indeed. The series looks good to me, but it will be nice to get some acks from people who commented previous revision. Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 4/4] can: c_can: Add d_can suspend resume support
On Wed, Sep 05, 2012 at 16:42:44, AnilKumar, Chimata wrote:
> Adds suspend resume support to DCAN driver which enables
> DCAN power down mode bit (PDR). Then DCAN will ack the local
> power-down mode by setting PDA bit in STATUS register.
>
Marc,
I missed out this patch, I will remove raminit calls from this
patch and submit new version. But I will test using RAMINIT.
Thanks
AnilKumar
> Signed-off-by: AnilKumar Ch
> ---
> drivers/net/can/c_can/c_can.c | 82
>
> drivers/net/can/c_can/c_can.h |8
> drivers/net/can/c_can/c_can_platform.c | 62
> 3 files changed, 152 insertions(+)
>
> diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
> index c175410..c601136 100644
> --- a/drivers/net/can/c_can/c_can.c
> +++ b/drivers/net/can/c_can/c_can.c
> @@ -46,6 +46,9 @@
> #define IF_ENUM_REG_LEN 11
> #define C_CAN_IFACE(reg, iface) (C_CAN_IF1_##reg + (iface) *
> IF_ENUM_REG_LEN)
>
> +/* control extension register D_CAN specific */
> +#define CONTROL_EX_PDR BIT(8)
> +
> /* control register */
> #define CONTROL_TEST BIT(7)
> #define CONTROL_CCE BIT(6)
> @@ -65,6 +68,7 @@
> #define TEST_BASIC BIT(2)
>
> /* status register */
> +#define STATUS_PDA BIT(10)
> #define STATUS_BOFF BIT(7)
> #define STATUS_EWARN BIT(6)
> #define STATUS_EPASS BIT(5)
> @@ -164,6 +168,9 @@
> /* minimum timeout for checking BUSY status */
> #define MIN_TIMEOUT_VALUE6
>
> +/* Wait for ~1 sec for INIT bit */
> +#define INIT_WAIT_MS 1000
> +
> /* napi related */
> #define C_CAN_NAPI_WEIGHTC_CAN_MSG_OBJ_RX_NUM
>
> @@ -1154,6 +1161,81 @@ struct net_device *alloc_c_can_dev(void)
> }
> EXPORT_SYMBOL_GPL(alloc_c_can_dev);
>
> +#ifdef CONFIG_PM
> +int c_can_power_down(struct net_device *dev)
> +{
> + u32 val;
> + unsigned long time_out;
> + struct c_can_priv *priv = netdev_priv(dev);
> +
> + if (!(dev->flags & IFF_UP))
> + return 0;
> +
> + BUG_ON(priv->type != BOSCH_D_CAN);
> +
> + /* set PDR value so the device goes to power down mode */
> + val = priv->read_reg(priv, C_CAN_CTRL_EX_REG);
> + val |= CONTROL_EX_PDR;
> + priv->write_reg(priv, C_CAN_CTRL_EX_REG, val);
> +
> + /* Wait for the PDA bit to get set */
> + time_out = jiffies + msecs_to_jiffies(INIT_WAIT_MS);
> + while (!(priv->read_reg(priv, C_CAN_STS_REG) & STATUS_PDA) &&
> + time_after(time_out, jiffies))
> + cpu_relax();
> +
> + if (time_after(jiffies, time_out))
> + return -ETIMEDOUT;
> +
> + c_can_stop(dev);
> +
> + /* De-initialize DCAN RAM */
> + c_can_reset_ram(priv, false);
> + c_can_pm_runtime_put_sync(priv);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(c_can_power_down);
> +
> +int c_can_power_up(struct net_device *dev)
> +{
> + u32 val;
> + unsigned long time_out;
> + struct c_can_priv *priv = netdev_priv(dev);
> +
> + if (!(dev->flags & IFF_UP))
> + return 0;
> +
> + BUG_ON(priv->type != BOSCH_D_CAN);
> +
> + c_can_pm_runtime_get_sync(priv);
> + /* Initialize DCAN RAM */
> + c_can_reset_ram(priv, true);
> +
> + /* Clear PDR and INIT bits */
> + val = priv->read_reg(priv, C_CAN_CTRL_EX_REG);
> + val &= ~CONTROL_EX_PDR;
> + priv->write_reg(priv, C_CAN_CTRL_EX_REG, val);
> + val = priv->read_reg(priv, C_CAN_CTRL_REG);
> + val &= ~CONTROL_INIT;
> + priv->write_reg(priv, C_CAN_CTRL_REG, val);
> +
> + /* Wait for the PDA bit to get clear */
> + time_out = jiffies + msecs_to_jiffies(INIT_WAIT_MS);
> + while ((priv->read_reg(priv, C_CAN_STS_REG) & STATUS_PDA) &&
> + time_after(time_out, jiffies))
> + cpu_relax();
> +
> + if (time_after(jiffies, time_out))
> + return -ETIMEDOUT;
> +
> + c_can_start(dev);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(c_can_power_up);
> +#endif
> +
> void free_c_can_dev(struct net_device *dev)
> {
> free_candev(dev);
> diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
> index 5f6339c..ca149eb 100644
> --- a/drivers/net/can/c_can/c_can.h
> +++ b/drivers/net/can/c_can/c_can.h
> @@ -24,6 +24,7 @@
>
> enum reg {
> C_CAN_CTRL_REG = 0,
> + C_CAN_CTRL_EX_REG,
> C_CAN_STS_REG,
> C_CAN_ERR_CNT_REG,
> C_CAN_BTR_REG,
> @@ -104,6 +105,7 @@ static const u16 reg_map_c_can[] = {
>
> static const u16 reg_map_d_can[] = {
> [C_CAN_CTRL_REG]= 0x00,
> + [C_CAN_CTRL_EX_REG] = 0x02,
> [C_CAN_STS_REG] = 0x04,
> [C_CAN_ERR_CNT_REG] = 0x08,
> [C_CAN_BTR_REG] = 0x0C,
> @@ -166,6 +168,7 @@ struct c_can_priv {
> unsigned int tx_echo;
> void *priv; /* for board-specific data */
> u16 irqstatus;
> + enum c_
Re: [PATCH v2] leds: leds-gpio: adopt pinctrl support
Dear AnilKumar, Chimata, > On Fri, Sep 07, 2012 at 05:39:35, Marek Vasut wrote: > > Dear Tony Lindgren, > > > > > * Marek Vasut [120905 19:05]: > > > > Hi Tony, > > > > > > > > > * Marek Vasut [120904 20:13]: > > > > > > Dear Bryan Wu, > > > > > > > > > > > > > On Sat, Sep 1, 2012 at 4:16 PM, AnilKumar Ch wrote: > > > > > > > > Adopt pinctrl support to leds-gpio driver based on leds-gpio > > > > > > > > device pointer, pinctrl driver configure SoC pins to GPIO > > > > > > > > mode according to definitions provided in .dts file. > > > > > > > > > > > > > > Thanks for this, actually Marek Vasut submitted a similar patch > > > > > > > before. I'm pretty fine with this patch. > > > > > > > > > > > > Thanks for submitting this actually ... I didn't have time to > > > > > > properly investigate this. > > > > > > > > > > > > > But without proper DT setting, it will also give us warning I > > > > > > > think. or we can provide some dummy functions as a temp > > > > > > > solution as Shawn pointed out before. > > > > > > > > > > > > But this driver is also used on hardware that's not yet coverted > > > > > > to DT, so I'd say dev_warn() if CONFIG_OF is enabled and > > > > > > otherwise simply go on ? Actually, can we not skip whole this > > > > > > pinctrl thing if CONFIG_OF is disabled? Actually (2), what's the > > > > > > relationship between OF and pinctrl? > > > > > > > > > > The warning should be pinctrl related as the pinctrl drivers may > > > > > not be device tree based drivers. > > > > > > > > Exactly my concern. Also the warning shouldnt be present on systems > > > > where pinctrl is disabled. > > > > > > But pinctrl_get_select() returns 0 in include/linux/pinctrl/consumer.h > > > if CONFIG_PINCTRL is not selected, so no warning is produced AFAIK ;) > > > > Oh all right then. > > Bryan, > > If this patch looks fine, can you queue this for 3.7? Looks good to me. > Thanks > AnilKumar Best regards, Marek Vasut -- To unsubscribe from this list: send the line "unsubscribe 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/5] arm/dts: Add pinctrl driver entries for omap2/3/4
On Thu, Sep 6, 2012 at 8:58 PM, Tony Lindgren wrote: > Add pinctrl driver entries for omap2+. These all use > the generic pinctrl-single driver for the padconf > registers. > > Note that as 2420 and 2430 have different padmux > registers, we now need to include omap2420.dtsi from > omap2420-h4.dts. > > Cc: Linus Walleij > Cc: devicetree-disc...@lists.ozlabs.org > Signed-off-by: Tony Lindgren FWIW: Acked-by: Linus Walleij 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 v2] leds: leds-gpio: adopt pinctrl support
On Fri, Sep 07, 2012 at 05:39:35, Marek Vasut wrote: > Dear Tony Lindgren, > > > * Marek Vasut [120905 19:05]: > > > Hi Tony, > > > > > > > * Marek Vasut [120904 20:13]: > > > > > Dear Bryan Wu, > > > > > > > > > > > On Sat, Sep 1, 2012 at 4:16 PM, AnilKumar Ch > > > > > > wrote: > > > > > > > Adopt pinctrl support to leds-gpio driver based on leds-gpio > > > > > > > device pointer, pinctrl driver configure SoC pins to GPIO > > > > > > > mode according to definitions provided in .dts file. > > > > > > > > > > > > Thanks for this, actually Marek Vasut submitted a similar patch > > > > > > before. I'm pretty fine with this patch. > > > > > > > > > > Thanks for submitting this actually ... I didn't have time to > > > > > properly investigate this. > > > > > > > > > > > But without proper DT setting, it will also give us warning I > > > > > > think. or we can provide some dummy functions as a temp solution > > > > > > as Shawn pointed out before. > > > > > > > > > > But this driver is also used on hardware that's not yet coverted to > > > > > DT, so I'd say dev_warn() if CONFIG_OF is enabled and otherwise > > > > > simply go on ? Actually, can we not skip whole this pinctrl thing if > > > > > CONFIG_OF is disabled? Actually (2), what's the relationship between > > > > > OF and pinctrl? > > > > > > > > The warning should be pinctrl related as the pinctrl drivers may not be > > > > device tree based drivers. > > > > > > Exactly my concern. Also the warning shouldnt be present on systems where > > > pinctrl is disabled. > > > > But pinctrl_get_select() returns 0 in include/linux/pinctrl/consumer.h if > > CONFIG_PINCTRL is not selected, so no warning is produced AFAIK ;) > > Oh all right then. > Bryan, If this patch looks fine, can you queue this for 3.7? Thanks AnilKumar -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
