* [PATCH] pinctrl: at91: Staticize non-exported symbols
From: Linus Walleij @ 2012-11-05 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352121830.14769.2.camel@phoenix>
On Mon, Nov 5, 2012 at 2:23 PM, Axel Lin <axel.lin@ingics.com> wrote:
> Signed-off-by: Axel Lin <axel.lin@ingics.com>
Merged to my AT91 branch, unless Jean-Christophe says something...
Thanks!
Linus Walleij
^ permalink raw reply
* [PATCH] ARM: decompressor: clear SCTLR.A bit for v7 cores
From: Johannes Stezenbach @ 2012-11-05 13:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121105130255.GD2005@linaro.org>
On Mon, Nov 05, 2012 at 01:02:55PM +0000, Dave Martin wrote:
> On Mon, Nov 05, 2012 at 11:13:46AM +0000, Russell King - ARM Linux wrote:
> > On Mon, Nov 05, 2012 at 10:48:50AM +0000, Dave Martin wrote:
> > > For v7, we should definitely use -munaligned-access where available
> > > (unless it's the default?)
> >
> > No such option on my compiler - according to the manual I have, the only
> > option there is starting -munaligned is on SPARC for -munaligned-doubles.
>
> OK, I guess that's something backported into the Linaro toolchain I'm
> currently using then. But it seems a good idea to use this if available,
> because it allows the compiler to generate better code in some situations,
> especially for packed struct access.
>
> > However, I believe GCC does believe that unaligned accesses are fine on
> > V6 and above.
>
> Possibly, but I've never seen it use them deliberately, prior to the
> -munaligned-access support.
http://gcc.gnu.org/gcc-4.7/changes.html says -munaligned-access is
enabled by default.
I haven't had a chance to try gcc-4.7 yet, but gcc-4.6+linaro
has the option but fails to generate the expected code for ARMv6
while it works for ARMv7. However it does
#define __ARM_FEATURE_UNALIGNED 1
and
.eabi_attribute 34, 1
This seems to be the commit which introduced unaligned support in gcc:
http://repo.or.cz/w/official-gcc.git/commitdiff/eb04cafba3a6f1eddbdb5ec031d8a7074930d5b9
I cannot figure out why this works for v7 but not for v6.
(I used gcc-4.6.4 20121001 (prerelease) toolchain built with crosstool-NG.)
Johannes
^ permalink raw reply
* [PATCH] pinctrl: sirf: Staticize non-exported symbol
From: Axel Lin @ 2012-11-05 13:44 UTC (permalink / raw)
To: linux-arm-kernel
Staticize sirfsoc_gpio_irq_map() function.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
---
drivers/pinctrl/pinctrl-sirf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-sirf.c b/drivers/pinctrl/pinctrl-sirf.c
index 9ecacf3..e3b2c53 100644
--- a/drivers/pinctrl/pinctrl-sirf.c
+++ b/drivers/pinctrl/pinctrl-sirf.c
@@ -1621,8 +1621,8 @@ static void sirfsoc_gpio_set_value(struct gpio_chip *chip, unsigned offset,
spin_unlock_irqrestore(&bank->lock, flags);
}
-int sirfsoc_gpio_irq_map(struct irq_domain *d, unsigned int irq,
- irq_hw_number_t hwirq)
+static int sirfsoc_gpio_irq_map(struct irq_domain *d, unsigned int irq,
+ irq_hw_number_t hwirq)
{
struct sirfsoc_gpio_bank *bank = d->host_data;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 00/10] ARM: dts: AM33XX: Add device tree data
From: AnilKumar, Chimata @ 2012-11-05 13:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352112350-13398-1-git-send-email-anilkumar@ti.com>
On Mon, Nov 05, 2012 at 16:15:40, AnilKumar, Chimata wrote:
> Add device tree date for GPIO based various drivers matrix keypad,
> volume keys, push buttons and use leds accross three AM33XX devices
> viz EVM, BeagleBone and Starter Kit.
>
> To make it functional this series also adds pinctrl data for all
> the GPIOs used by various drivers. In this series only default state
> pinmux/conf settings are added because of sleep/idle state pinctrl
> values are not available.
>
> These patches are based on linux-omap-dt:for_3.8/dts tree and these
My bad, small correction in this statement, these patches apply cleanly
on linux-omap-dt:for_3.8/dts tree with the below two patches.
http://www.spinics.net/lists/arm-kernel/msg204872.html
http://www.spinics.net/lists/arm-kernel/msg204873.html
Thanks
AnilKumar
> were tested on am33xx devices according to added functionality.
>
> AnilKumar Ch (10):
> ARM: dts: AM33XX: Add pinmux configuration for matrix keypad to EVM
> ARM: dts: AM33XX: Add matrix keypad device tree data to am335x-evm
> ARM: dts: AM33XX: Add pinmux configuration for volume-keys to EVM
> ARM: dts: AM33XX: Add volume-keys device tree data to am335x-evm
> ARM: dts: AM33XX: Add pinmux configuration for user-leds to BONE
> ARM: dts: AM33XX: Add user-leds device tree data to am335x-bone
> ARM: dts: AM33XX: Add pinmux configuration for gpio-leds to EVMSK
> ARM: dts: AM33XX: Add user-leds device tree data to am335x-evmsk
> ARM: dts: AM33XX: Add pinmux configuration for gpio-keys to EVMSK
> ARM: dts: AM33XX: Add push-buttons device tree data to am335x-evmsk
>
> arch/arm/boot/dts/am335x-bone.dts | 44 +++++++++++++++++++
> arch/arm/boot/dts/am335x-evm.dts | 63 +++++++++++++++++++++++++++
> arch/arm/boot/dts/am335x-evmsk.dts | 84 ++++++++++++++++++++++++++++++++++++
> 3 files changed, 191 insertions(+)
>
> --
> 1.7.9.5
>
>
^ permalink raw reply
* scheduler clock for MXS [Was: Re: Wakeup latency measured with SCHED_TRACER depends on HZ]
From: Shawn Guo @ 2012-11-05 13:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50978370.9060001@meduna.org>
On Mon, Nov 05, 2012 at 10:14:24AM +0100, Stanislav Meduna wrote:
> On 05.11.2012 03:57, Shawn Guo wrote:
>
> >> The patch in attach fixes this. I can only test the MX28 part -
> >> I don't have any timrot_is_v1() (MX23) hardware and I don't
> >> know whether a source that wraps after ~2 seconds is OK at all.
> >
> > From my quick testing on imx23 with printk timestamp, it's not OK,
> > so we may need to leave imx23 out there.
>
I should say it's practically not OK since it wraps in such a short
period. But it actually works as expected.
> Hmm, does it wrap after 2 seconds?
Yes, it does wrap after ~2 seconds.
> From my grepping and googling
> the code should now adapt itself, the hardcoded limit is gone...
> What does the dmesg line such as
>
> sched_clock: 32 bits at 32kHz, resolution 31250ns,
> wraps every 134217727ms
>
> output on that hardware?
>
Yes, something like:
sched_clock: 16 bits at 32kHz, resolution 31250ns, wraps every 2047ms
Shawn
^ permalink raw reply
* [PATCH] ARM: decompressor: clear SCTLR.A bit for v7 cores
From: Rob Herring @ 2012-11-05 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121105111346.GF28327@n2100.arm.linux.org.uk>
On 11/05/2012 05:13 AM, Russell King - ARM Linux wrote:
> On Mon, Nov 05, 2012 at 10:48:50AM +0000, Dave Martin wrote:
>> On Thu, Oct 25, 2012 at 05:08:16PM +0200, Johannes Stezenbach wrote:
>>> On Thu, Oct 25, 2012 at 09:25:06AM -0500, Rob Herring wrote:
>>>> On 10/25/2012 09:16 AM, Johannes Stezenbach wrote:
>>>>> On Thu, Oct 25, 2012 at 07:41:45AM -0500, Rob Herring wrote:
>>>>>> On 10/25/2012 04:34 AM, Johannes Stezenbach wrote:
>>>>>>> On Thu, Oct 11, 2012 at 07:43:22AM -0500, Rob Herring wrote:
>>>>>>>
>>>>>>>> While v6 can support unaligned accesses, it is optional and current
>>>>>>>> compilers won't emit unaligned accesses. So we don't clear the A bit for
>>>>>>>> v6.
>>>>>>>
>>>>>>> not true according to the gcc changes page
>>>>>>
>>>>>> What are you going to believe: documentation or what the compiler
>>>>>> emitted? At least for ubuntu/linaro 4.6.3 which has the unaligned access
>>>>>> support backported and 4.7.2, unaligned accesses are emitted for v7
>>>>>> only. I guess default here means it is the default unless you change the
>>>>>> default in your build of gcc.
>>>>>
>>>>> Since ARMv6 can handle unaligned access in the same way as ARMv7
>>>>> it seems a clear bug in gcc which might hopefully get fixed.
>>>>> Thus in this case I think it is reasonable to follow the
>>>>> gcc documentation, otherwise the code would break for ARMv6
>>>>> when gcc gets fixed.
>>>>
>>>> But the compiler can't assume the state of the U bit. I think it is
>>>> still legal on v6 to not support unaligned accesses, but on v7 it is
>>>> required. All the standard v6 ARM cores support it, but I'm not sure
>>>> about custom cores or if there are SOCs with buses that don't support
>>>> unaligned accesses properly.
>>>
>>> Well, I read the "...since Linux version 2.6.28" comment
>>> in the gcc changes page in the way that they assume the
>>> U-bit is set. (Although I'm not sure it really is???)
>>
>> Actually, the kernel checks the arch version and the U bit on boot,
>> and chooses the appropriate setting for the A bit depending on the
>> result. (See arch/arm/mm/alignment.c:alignment_init().)
>
> That is in the kernel itself, _after_ the decompressor has run. It is
> not relevant to any discussion about the decompressor.
>
>> Currently, we depend on the CPU reset behaviour or firmware/
>> bootloader to set the U bit for v6, but the behaviour should be
>> correct either way, though unaligned accesses will obviously
>> perform (much) better with U=1.
>
> Will someone _PLEASE_ address my initial comments against this patch
> in light of the fact that it's now been proven _NOT_ to be just a V7
> issue, rather than everyone seemingly buring their heads in the sand
> over this.
I tried adding -munaligned-accesses on a v6 build and still get byte
accesses rather than unaligned word accesses. So this does seem to be a
v7 only issue based on what gcc will currently produce. Copying Michael
Hope who can hopefully provide some insight on why v6 unaligned accesses
are not enabled.
> The fact is, unaligned accesses in the decompressor are *undefined* at
> present.
>
>> For v7, we should definitely use -munaligned-access where available
>> (unless it's the default?)
>
> No such option on my compiler - according to the manual I have, the only
> option there is starting -munaligned is on SPARC for -munaligned-doubles.
It's only added in 4.7 and backported to Linaro 4.6.3.
Rob
> However, I believe GCC does believe that unaligned accesses are fine on
> V6 and above.
>
^ permalink raw reply
* [PATCH 1/2] leds: Add generic support for memory mapped LEDs
From: Jon Medhurst (Tixy) @ 2012-11-05 13:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352120159.10947.3.camel@hornet>
On Mon, 2012-11-05 at 12:55 +0000, Pawel Moll wrote:
> On Mon, 2012-11-05 at 09:39 +0000, Jon Medhurst (Tixy) wrote:
> > > +static void mmio_led_brightness_set(struct led_classdev *cdev,
> > > + enum led_brightness brightness)
> > > +{
> > > + struct mmio_led *led = container_of(cdev, struct mmio_led, cdev);
> > > + unsigned long uninitialized_var(flags);
> >
> > uninitialized_var seems to be a bit contentious, Linus Torvalds had a
> > recent complaint about it which prompted Ingo to post a patch proposing
> > to removing it: https://patchwork.kernel.org/patch/1655621/ So perhaps
> > best to avoid using it ;-).
> >
> > In this case, you could possibly keep gcc quite with something like:
> >
> > spinlock_t *lock = led->lock;
> >
> > and then use the local variable 'lock' everywhere instead of led->lock.
> > Or just keep it simple an initialise flags to 0 instead.
>
> Yeah, = 0 will do...
>
> > > + if (!pdata)
> > > + return -EINVAL;
> > > +
> > > + if (pdata->reg_size != 8 && pdata->reg_size != 16 &&
> > > + pdata->reg_size != 32)
> > > + return -EFAULT;
> >
> > Is EFAULT appropriate here? Why not EINVAL?
>
> Hm. To distinguish it from !pdata case I guess (and a 13 bit wide
> transaction sounds like a fault to me ;-), but I can be persuaded
> otherwise without much effort...
I was asking as much for my own education about use of error values as
anything else. The comments in errno-base.h are:
#define EINVAL 22 /* Invalid argument */
#define EFAULT 14 /* Bad address */
and from looking in the source tree it seems EFAULT is mostly used to
indicate a bad memory address passed from user-side to the kernel.
It's a trivial point so it's not worth wasting time on a long
discussion.
--
Tixy
^ permalink raw reply
* [PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu
From: Will Deacon @ 2012-11-05 14:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351545108-18954-2-git-send-email-gregory.clement@free-electrons.com>
Hi Gregory,
On Mon, Oct 29, 2012 at 09:11:44PM +0000, Gregory CLEMENT wrote:
> diff --git a/arch/arm/mach-mvebu/coherency.c b/arch/arm/mach-mvebu/coherency.c
> new file mode 100644
> index 0000000..69e130d
> --- /dev/null
> +++ b/arch/arm/mach-mvebu/coherency.c
> @@ -0,0 +1,89 @@
> +/*
> + * Coherency fabric (Aurora) support for Armada 370 and XP platforms.
> + *
> + * Copyright (C) 2012 Marvell
> + *
> + * Yehuda Yitschak <yehuday@marvell.com>
> + * Gregory Clement <gregory.clement@free-electrons.com>
> + * Thomas Petazzoni <thomas.petazzoni@free-electrons.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.
> + *
> + * The Armada 370 and Armada XP SOCs have a coherency fabric which is
> + * responsible for ensuring hardware coherency between all CPUs and between
> + * CPUs and I/O masters. This file initializes the coherency fabric and
> + * supplies basic routines for configuring and controlling hardware coherency
> + */
[...]
> +int set_cpu_coherent(unsigned int hw_cpu_id, int smp_group_id)
> +{
> + int reg;
> +
> + if (!coherency_base) {
> + pr_warn("Can't make CPU %d cache coherent.\n", hw_cpu_id);
> + pr_warn("Coherency fabric is not initialized\n");
> + return 1;
> + }
> +
> + /* Enable the CPU in coherency fabric */
> + reg = readl(coherency_base + COHERENCY_FABRIC_CTL_OFFSET);
> + reg |= 1 << (24 + hw_cpu_id);
> + writel(reg, coherency_base + COHERENCY_FABRIC_CTL_OFFSET);
> +
> + /* Add CPU to SMP group */
> + reg = readl(coherency_base + COHERENCY_FABRIC_CFG_OFFSET);
> + reg |= 1 << (16 + hw_cpu_id + (smp_group_id == 0 ? 8 : 0));
> + writel(reg, coherency_base + COHERENCY_FABRIC_CFG_OFFSET);
> +
> + return 0;
> +}
These writels may expand to code containing calls to outer_sync(), which
will attempt to take a spinlock for the aurora l2. Given that the CPU isn't
coherent, how does this play out with the exclusive store instruction in the
lock?
Will
^ permalink raw reply
* [PATCH V2 2/5] arm: mvebu: Added initial support for power managmement service unit
From: Will Deacon @ 2012-11-05 14:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351545108-18954-3-git-send-email-gregory.clement@free-electrons.com>
On Mon, Oct 29, 2012 at 09:11:45PM +0000, Gregory CLEMENT wrote:
> diff --git a/arch/arm/mach-mvebu/pmsu.c b/arch/arm/mach-mvebu/pmsu.c
> new file mode 100644
> index 0000000..cee020b
> --- /dev/null
> +++ b/arch/arm/mach-mvebu/pmsu.c
> @@ -0,0 +1,78 @@
> +/*
> + * Power Management Service Unit(PMSU) support for Armada 370/XP platforms.
> + *
> + * Copyright (C) 2012 Marvell
> + *
> + * Yehuda Yitschak <yehuday@marvell.com>
> + * Gregory Clement <gregory.clement@free-electrons.com>
> + * Thomas Petazzoni <thomas.petazzoni@free-electrons.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.
> + *
> + * The Armada 370 and Armada XP SOCs have a power management service
> + * unit which is responsible for powering down and waking up CPUs and
> + * other SOC units
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/of_address.h>
> +#include <linux/io.h>
> +#include <linux/smp.h>
> +#include <asm/smp_plat.h>
> +
> +static void __iomem *pmsu_mp_base;
> +static void __iomem *pmsu_reset_base;
> +
> +#define PMSU_BOOT_ADDR_REDIRECT_OFFSET(cpu) ((cpu * 0x100) + 0x24)
> +#define PMSU_RESET_CTL_OFFSET(cpu) (cpu * 0x8)
> +
> +static struct of_device_id of_pmsu_table[] = {
> + {.compatible = "marvell,armada-370-xp-pmsu"},
> + { /* end of list */ },
> +};
> +
> +#ifdef CONFIG_SMP
> +int armada_xp_boot_cpu(unsigned int cpu_id, void __iomem *boot_addr)
> +{
> + int reg, hw_cpu;
> +
> + if (!pmsu_mp_base || !pmsu_reset_base) {
> + pr_warn("Can't boot CPU. PMSU is uninitialized\n");
> + return 1;
> + }
> +
> + hw_cpu = cpu_logical_map(cpu_id);
> +
> + writel(virt_to_phys(boot_addr), pmsu_mp_base +
> + PMSU_BOOT_ADDR_REDIRECT_OFFSET(hw_cpu));
virt_to_phys on an __iomem * doesn't feel right to me...
> + /* Make sure value hits memory before reset */
> + dsb();
writel has barrier semantics -- you shouldn't need this dsb.
Will
^ permalink raw reply
* [PATCHv3 1/8] i2c: omap: Fix the revision register read
From: Felipe Balbi @ 2012-11-05 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352118223-3796-2-git-send-email-shubhrajyoti@ti.com>
On Mon, Nov 05, 2012 at 05:53:36PM +0530, Shubhrajyoti D wrote:
> The revision register on OMAP4 is a 16-bit lo and a 16-bit
> hi. Currently the driver reads only the lower 8-bits.
> Fix the same by preventing the truncating of the rev register
> for OMAP4.
>
> Also use the scheme bit ie bit-14 of the hi register to know if it
> is OMAP_I2C_IP_VERSION_2.
>
> On platforms previous to OMAP4 the offset 0x04 is IE register whose
> bit-14 reset value is 0, the code uses the same to its advantage.
>
> Also since the omap_i2c_read_reg uses reg_map_ip_* a raw_readw is done
> to fetch the revision register.
>
> The dev->regs is populated after reading the rev_hi. A NULL check
> has been added in the resume handler to prevent the access before
> the setting of the regs.
>
Reviewed-by: Felipe Balbi <balbi@ti.com>
> Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
> ---
> v3: Fix the comments.
>
> drivers/i2c/busses/i2c-omap.c | 61 ++++++++++++++++++++++++++++++++---------
> 1 files changed, 48 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index db31eae..5c6f538 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -49,9 +49,10 @@
> #define OMAP_I2C_OMAP1_REV_2 0x20
>
> /* I2C controller revisions present on specific hardware */
> -#define OMAP_I2C_REV_ON_2430 0x36
> -#define OMAP_I2C_REV_ON_3430_3530 0x3C
> -#define OMAP_I2C_REV_ON_3630_4430 0x40
> +#define OMAP_I2C_REV_ON_2430 0x00000036
> +#define OMAP_I2C_REV_ON_3430_3530 0x0000003C
> +#define OMAP_I2C_REV_ON_3630 0x00000040
> +#define OMAP_I2C_REV_ON_4430_PLUS 0x50400002
>
> /* timeout waiting for the controller to respond */
> #define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
> @@ -202,7 +203,7 @@ struct omap_i2c_dev {
> * fifo_size==0 implies no fifo
> * if set, should be trsh+1
> */
> - u8 rev;
> + u32 rev;
> unsigned b_hw:1; /* bad h/w fixes */
> unsigned receiver:1; /* true when we're in receiver mode */
> u16 iestate; /* Saved interrupt register */
> @@ -490,7 +491,7 @@ static void omap_i2c_resize_fifo(struct omap_i2c_dev *dev, u8 size, bool is_rx)
>
> omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, buf);
>
> - if (dev->rev < OMAP_I2C_REV_ON_3630_4430)
> + if (dev->rev < OMAP_I2C_REV_ON_3630)
> dev->b_hw = 1; /* Enable hardware fixes */
>
> /* calculate wakeup latency constraint for MPU */
> @@ -1052,6 +1053,16 @@ static const struct of_device_id omap_i2c_of_match[] = {
> MODULE_DEVICE_TABLE(of, omap_i2c_of_match);
> #endif
>
> +#define OMAP_I2C_SCHEME(rev) ((rev & 0xc000) >> 14)
> +
> +#define OMAP_I2C_REV_SCHEME_0_MAJOR(rev) (rev >> 4)
> +#define OMAP_I2C_REV_SCHEME_0_MINOR(rev) (rev & 0xf)
> +
> +#define OMAP_I2C_REV_SCHEME_1_MAJOR(rev) ((rev & 0x0700) >> 7)
> +#define OMAP_I2C_REV_SCHEME_1_MINOR(rev) (rev & 0x1f)
> +#define OMAP_I2C_SCHEME_0 0
> +#define OMAP_I2C_SCHEME_1 1
> +
> static int __devinit
> omap_i2c_probe(struct platform_device *pdev)
> {
> @@ -1064,6 +1075,8 @@ omap_i2c_probe(struct platform_device *pdev)
> const struct of_device_id *match;
> int irq;
> int r;
> + u32 rev;
> + u16 minor, major;
>
> /* NOTE: driver uses the static register mapping */
> mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> @@ -1117,11 +1130,6 @@ omap_i2c_probe(struct platform_device *pdev)
>
> dev->reg_shift = (dev->flags >> OMAP_I2C_FLAG_BUS_SHIFT__SHIFT) & 3;
>
> - if (dev->dtrev == OMAP_I2C_IP_VERSION_2)
> - dev->regs = (u8 *)reg_map_ip_v2;
> - else
> - dev->regs = (u8 *)reg_map_ip_v1;
> -
> pm_runtime_enable(dev->dev);
> pm_runtime_set_autosuspend_delay(dev->dev, OMAP_I2C_PM_TIMEOUT);
> pm_runtime_use_autosuspend(dev->dev);
> @@ -1130,7 +1138,31 @@ omap_i2c_probe(struct platform_device *pdev)
> if (IS_ERR_VALUE(r))
> goto err_free_mem;
>
> - dev->rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) & 0xff;
> + /*
> + * Read the Rev hi bit-[15:14] ie scheme this is 1 indicates ver2.
> + * On omap1/3/2 Offset 4 is IE Reg the bit [15:14] is 0 at reset.
> + * Also since the omap_i2c_read_reg uses reg_map_ip_* a
> + * raw_readw is done.
> + */
> + rev = __raw_readw(dev->base + 0x04);
> +
> + switch (OMAP_I2C_SCHEME(rev)) {
> + case OMAP_I2C_SCHEME_0:
> + dev->regs = (u8 *)reg_map_ip_v1;
> + dev->rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG);
> + minor = OMAP_I2C_REV_SCHEME_0_MAJOR(dev->rev);
> + major = OMAP_I2C_REV_SCHEME_0_MAJOR(dev->rev);
> + break;
> + case OMAP_I2C_SCHEME_1:
> + /* FALLTHROUGH */
> + default:
> + dev->regs = (u8 *)reg_map_ip_v2;
> + rev = (rev << 16) |
> + omap_i2c_read_reg(dev, OMAP_I2C_IP_V2_REVNB_LO);
> + minor = OMAP_I2C_REV_SCHEME_1_MINOR(rev);
> + major = OMAP_I2C_REV_SCHEME_1_MAJOR(rev);
> + dev->rev = rev;
> + }
>
> dev->errata = 0;
>
> @@ -1155,7 +1187,7 @@ omap_i2c_probe(struct platform_device *pdev)
>
> dev->fifo_size = (dev->fifo_size / 2);
>
> - if (dev->rev < OMAP_I2C_REV_ON_3630_4430)
> + if (dev->rev < OMAP_I2C_REV_ON_3630)
> dev->b_hw = 1; /* Enable hardware fixes */
>
> /* calculate wakeup latency constraint for MPU */
> @@ -1198,7 +1230,7 @@ omap_i2c_probe(struct platform_device *pdev)
> }
>
> dev_info(dev->dev, "bus %d rev%d.%d.%d at %d kHz\n", adap->nr,
> - dev->dtrev, dev->rev >> 4, dev->rev & 0xf, dev->speed);
> + dev->dtrev, major, minor, dev->speed);
>
> of_i2c_register_devices(adap);
>
> @@ -1264,6 +1296,9 @@ static int omap_i2c_runtime_resume(struct device *dev)
> struct platform_device *pdev = to_platform_device(dev);
> struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
>
> + if (!_dev->regs)
> + return 0;
> +
> if (_dev->flags & OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
> omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
> omap_i2c_write_reg(_dev, OMAP_I2C_PSC_REG, _dev->pscstate);
> --
> 1.7.5.4
>
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121105/5fb1ba74/attachment-0001.sig>
^ permalink raw reply
* [PATCHv3 3/8] i2c: omap: remove the dtrev
From: Felipe Balbi @ 2012-11-05 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352118223-3796-4-git-send-email-shubhrajyoti@ti.com>
On Mon, Nov 05, 2012 at 05:53:38PM +0530, Shubhrajyoti D wrote:
> The dtrev is used only for the comments. Remove the same and use
> the scheme instead to know if it is version2.
>
> Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>
> ---
> v3: remove the scheme from the commments.
> todo: remove the dtrev from hwmod etc.
>
> drivers/i2c/busses/i2c-omap.c | 12 +++++-------
> 1 files changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index 737d843..5f0c06c 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -191,7 +191,6 @@ struct omap_i2c_dev {
> u32 latency; /* maximum MPU wkup latency */
> struct pm_qos_request pm_qos_request;
> u32 speed; /* Speed of bus in kHz */
> - u32 dtrev; /* extra revision from DT */
> u32 flags;
> u16 cmd_err;
> u8 *buf;
> @@ -1076,7 +1075,7 @@ omap_i2c_probe(struct platform_device *pdev)
> int irq;
> int r;
> u32 rev;
> - u16 minor, major;
> + u16 minor, major, scheme;
>
> /* NOTE: driver uses the static register mapping */
> mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> @@ -1108,7 +1107,6 @@ omap_i2c_probe(struct platform_device *pdev)
> u32 freq = 100000; /* default to 100000 Hz */
>
> pdata = match->data;
> - dev->dtrev = pdata->rev;
> dev->flags = pdata->flags;
>
> of_property_read_u32(node, "clock-frequency", &freq);
> @@ -1117,7 +1115,6 @@ omap_i2c_probe(struct platform_device *pdev)
> } else if (pdata != NULL) {
> dev->speed = pdata->clkrate;
> dev->flags = pdata->flags;
> - dev->dtrev = pdata->rev;
> }
>
> dev->dev = &pdev->dev;
> @@ -1146,7 +1143,8 @@ omap_i2c_probe(struct platform_device *pdev)
> */
> rev = __raw_readw(dev->base + 0x04);
>
> - switch (OMAP_I2C_SCHEME(rev)) {
> + scheme = OMAP_I2C_SCHEME(rev);
> + switch (scheme) {
> case OMAP_I2C_SCHEME_0:
> dev->regs = (u8 *)reg_map_ip_v1;
> dev->rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG);
> @@ -1230,8 +1228,8 @@ omap_i2c_probe(struct platform_device *pdev)
> goto err_unuse_clocks;
> }
>
> - dev_info(dev->dev, "bus %d rev%d.%d.%d at %d kHz\n", adap->nr,
> - dev->dtrev, major, minor, dev->speed);
> + dev_info(dev->dev, "bus %d rev%d.%d at %d kHz\n", adap->nr,
> + major, minor, dev->speed);
>
> of_i2c_register_devices(adap);
>
> --
> 1.7.5.4
>
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121105/e4644380/attachment-0001.sig>
^ permalink raw reply
* [PATCHv3 8/8] i2c: omap: cleanup the sysc write
From: Felipe Balbi @ 2012-11-05 14:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352118223-3796-9-git-send-email-shubhrajyoti@ti.com>
Hi,
On Mon, Nov 05, 2012 at 05:53:43PM +0530, Shubhrajyoti D wrote:
> Currently after the reset the sysc is written with hardcoded values.
> The patch reads the sysc register and writes back the same value
> after reset.
>
> - Some unnecessary rev checks can be optimised.
> - Also due to whatever reason the hwmod flags are changed
> we will not reset the values.
> - In some of the cases the minor values of the 2430 register
> is different(0x37) in that case the autoidle setting may be missed.
>
> Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
> ---
> drivers/i2c/busses/i2c-omap.c | 20 +++++---------------
> 1 files changed, 5 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index 25f1564..a09acdc 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -302,7 +302,11 @@ static void __omap_i2c_init(struct omap_i2c_dev *dev)
> static int omap_i2c_reset(struct omap_i2c_dev *dev)
> {
> unsigned long timeout;
> + u16 sysc;
> +
> if (dev->rev >= OMAP_I2C_OMAP1_REV_2) {
> + sysc = omap_i2c_read_reg(dev, OMAP_I2C_SYSC_REG);
> +
> /* Disable I2C controller before soft reset */
> omap_i2c_write_reg(dev, OMAP_I2C_CON_REG,
> omap_i2c_read_reg(dev, OMAP_I2C_CON_REG) &
> @@ -324,22 +328,8 @@ static int omap_i2c_reset(struct omap_i2c_dev *dev)
> }
>
> /* SYSC register is cleared by the reset; rewrite it */
> - if (dev->rev == OMAP_I2C_REV_ON_2430) {
> -
> - omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG,
> - SYSC_AUTOIDLE_MASK);
> + omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, sysc);
>
> - } else if (dev->rev >= OMAP_I2C_REV_ON_3430_3530) {
> - dev->syscstate = SYSC_AUTOIDLE_MASK;
> - dev->syscstate |= SYSC_ENAWAKEUP_MASK;
> - dev->syscstate |= (SYSC_IDLEMODE_SMART <<
> - __ffs(SYSC_SIDLEMODE_MASK));
> - dev->syscstate |= (SYSC_CLOCKACTIVITY_FCLK <<
> - __ffs(SYSC_CLOCKACTIVITY_MASK));
> -
> - omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG,
> - dev->syscstate);
> - }
not sure if this will work. What about the first time you call reset() ?
won't SYSC just contain the reset values ?
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121105/bf96166c/attachment.sig>
^ permalink raw reply
* [PATCHv3 8/8] i2c: omap: cleanup the sysc write
From: Shubhrajyoti @ 2012-11-05 14:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121105141442.GD4815@arwen.pp.htv.fi>
On Monday 05 November 2012 07:44 PM, Felipe Balbi wrote:
>> - dev->syscstate);
>> > - }
> not sure if this will work. What about the first time you call reset() ?
> won't SYSC just contain the reset values ?
No actually the hwmod sets the value.
^ permalink raw reply
* [PATCHv3 8/8] i2c: omap: cleanup the sysc write
From: Felipe Balbi @ 2012-11-05 14:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5097CBF1.6060108@ti.com>
Hi,
On Mon, Nov 05, 2012 at 07:53:45PM +0530, Shubhrajyoti wrote:
> On Monday 05 November 2012 07:44 PM, Felipe Balbi wrote:
> >> - dev->syscstate);
> >> > - }
> > not sure if this will work. What about the first time you call reset() ?
> > won't SYSC just contain the reset values ?
> No actually the hwmod sets the value.
ahaaa, ok good. Let's get an Ack from Benoit, then.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121105/43559f90/attachment.sig>
^ permalink raw reply
* [PATCH 1/2] ASoC: Ux500: Fixup use of clocks
From: Ulf Hansson @ 2012-11-05 14:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121022133003.GF4477@opensource.wolfsonmicro.com>
On 22 October 2012 15:30, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Mon, Oct 22, 2012 at 02:32:04PM +0200, Ulf Hansson wrote:
>> From: Ulf Hansson <ulf.hansson@linaro.org>
>>
>> Make sure clocks are being prepared and unprepared as well
>> as enabled and disabled.
>
> Applied, thanks.
I can not find this patch on any "next-tree" yet. Same goes for:
"[PATCH 2/2] ASoC: Ux500: Control apb clock".
Maybe I should be more patient, but thought it make sense to send a
ping on this. :-)
Kind regards
Ulf Hansson
^ permalink raw reply
* [PATCH] ARM: Exynos: remove unused init_uarts callback for exynos4x12 platforms
From: Thomas Abraham @ 2012-11-05 14:32 UTC (permalink / raw)
To: linux-arm-kernel
All the Exynos4x12 based platforms use only device tree based boot. So remove
the unused 'init_uarts' callback from exynos cpu_ids table.
Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
---
arch/arm/mach-exynos/common.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 56844d1..ce91cba 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -78,7 +78,6 @@ static struct cpu_table cpu_ids[] __initdata = {
.idmask = EXYNOS4_CPU_MASK,
.map_io = exynos4_map_io,
.init_clocks = exynos4_init_clocks,
- .init_uarts = exynos_init_uarts,
.init = exynos_init,
.name = name_exynos4212,
}, {
@@ -86,7 +85,6 @@ static struct cpu_table cpu_ids[] __initdata = {
.idmask = EXYNOS4_CPU_MASK,
.map_io = exynos4_map_io,
.init_clocks = exynos4_init_clocks,
- .init_uarts = exynos_init_uarts,
.init = exynos_init,
.name = name_exynos4412,
}, {
--
1.6.6.rc2
^ permalink raw reply related
* vexpress issues in next-20121029
From: Pawel Moll @ 2012-11-05 14:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121105094511.GE28327@n2100.arm.linux.org.uk>
On Mon, 2012-11-05 at 09:45 +0000, Russell King - ARM Linux wrote:
> On Mon, Nov 05, 2012 at 09:35:32AM +0000, Russell King - ARM Linux wrote:
> > On Tue, Oct 30, 2012 at 04:16:59PM +0000, Pawel Moll wrote:
> > > There was a glitch between clk-next and arm-soc - it should be fine
> > > starting with next-20121030.
> >
> > The problem is still there - my builds of my tree plus arm-soc are
> > continuing to fail with:
> >
> > arch/arm/mach-vexpress/built-in.o: In function `v2m_timer_init':
> > reset.c:(.init.text+0xe0): undefined reference to `vexpress_clk_init'
> > arch/arm/mach-vexpress/built-in.o: In function `v2m_dt_timer_init':
> > reset.c:(.init.text+0x114): undefined reference to `vexpress_clk_of_init'
> >
> > My guess is you have a dependency between the clk-next tree and arm-soc
> > which you haven't told the arm-soc people about.
>
> Oh, and the above seems to affect all my kautobuilds for any ARM Ltd
> development platform - it's not just vexpress which is affected by this
> anymore.
I've just successfully built defconfigs for vexpress, versatile and
realview with next-20121105 so I guess Arnd simply didn't have time last
week (the Connect event) to sort out the arm-soc tree...
Arnd, will you pull the vexpress-clk-soc (containing, as you suggested,
the soc stuff rebased on top of the clk branch) or do you want me to do
something else?
Thanks!
Pawe?
^ permalink raw reply
* [PATCH 2/8] ARM: zynq: move ttc timer code to drivers/clocksource
From: Rob Herring @ 2012-11-05 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHTX3d++0fGSw7GQHcc-S1X1Qh-rfekpr-E8Jkg2_vFqdCFFTg@mail.gmail.com>
On 11/05/2012 05:22 AM, Michal Simek wrote:
> 2012/10/29 Josh Cartwright <josh.cartwright@ni.com>:
>> Suggested cleanup by Arnd Bergmann. Move the ttc timer.c code to
>> drivers/clocksource, and out of the mach-zynq directory.
>>
>> The common.h (which only held the timer declaration) was renamed to
>> xilinx_ttc.h and moved into include/linux.
>>
>> Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>
>> Cc: Arnd Bergmann <arnd@arndb.de>
>> ---
>> arch/arm/mach-zynq/Makefile | 2 +-
>> arch/arm/mach-zynq/common.c | 2 +-
>> drivers/clocksource/Makefile | 1 +
>> arch/arm/mach-zynq/timer.c => drivers/clocksource/xilinx_ttc.c | 1 -
>> arch/arm/mach-zynq/common.h => include/linux/xilinx_ttc.h | 4 ++--
>> 5 files changed, 5 insertions(+), 5 deletions(-)
>> rename arch/arm/mach-zynq/timer.c => drivers/clocksource/xilinx_ttc.c (99%)
>> rename arch/arm/mach-zynq/common.h => include/linux/xilinx_ttc.h (91%)
>
> Not going to apply this patch till there is clean way how to move all
> drivers there.
> Especially I don't like to add xilinx_ttc.h to include/linux folder.
>
A cleaner way is how we are doing irqchips [1]. This needs a single
function (or one each for clksrc and clkevt) that has a DT match list of
all known timers and calls their init function. It should be a bit
simpler than irqchips init function because you don't need to worry
about hierarchy init ordering. That doesn't solve non-DT though and if
there are any extra functions like we have with irqchips, you still need
the header in include/linux.
Rob
[1] http://www.spinics.net/lists/arm-kernel/msg203687.html
^ permalink raw reply
* [PATCH 13/15] ARM: DTS: AM33XX: Add nodes for OCMCRAM and Mailbox
From: Santosh Shilimkar @ 2012-11-05 14:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <B5906170F1614E41A8A28DE3B8D121433EBFFD0A@DBDE01.ent.ti.com>
On Sunday 04 November 2012 08:56 PM, Bedia, Vaibhav wrote:
> On Sat, Nov 03, 2012 at 21:24:14, Shilimkar, Santosh wrote:
>> On Friday 02 November 2012 06:02 PM, Vaibhav Bedia wrote:
>>> Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
>>> ---
>>> arch/arm/boot/dts/am33xx.dtsi | 11 +++++++++++
>>> 1 files changed, 11 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
>>> index bb31bff..e2cbf24 100644
>>> --- a/arch/arm/boot/dts/am33xx.dtsi
>>> +++ b/arch/arm/boot/dts/am33xx.dtsi
>>> @@ -210,5 +210,16 @@
>>> interrupt-parent = <&intc>;
>>> interrupts = <91>;
>>> };
>>> +
>>> + ocmcram: ocmcram at 40300000 {
>>> + compatible = "ti,ocmcram";
>>> + ti,hwmods = "ocmcram";
>>> + ti,no_idle_on_suspend;
>>> + };
>> Whats the intention behind adding OCMRAM ?
>> Sorry if I missed any comments from the cover letter ?
>>
>
> We need a mechanism to ensure that the clock to OCMC is kept running
> during boot and that it doesn't get disabled as part of the suspend
> sequence. Since the hwmod data for OCMC is already present and we have
> the no_idle_on_suspend flag for hwmod entries we get the desired behavior.
>
On OMAP the OCMC RAM is always clocked and doesn't need any special
clock enable. CM_L3_2_OCMC_RAM_CLKCTRL module mode field is read only.
Isn't it same on AMXX ?
> This could also have been done via the clock tree but looks like we
> want to avoid adding leaf nodes in the clock data, hence the hwmod +
> DT approach.
>
Sure. I was just trying to see why AMXX is different with OMAP here.
Regards
Santosh
^ permalink raw reply
* [PATCH 12/15] ARM: OMAP: timer: Add suspend-resume callbacks for clockevent device
From: Santosh Shilimkar @ 2012-11-05 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <B5906170F1614E41A8A28DE3B8D121433EBFFD03@DBDE01.ent.ti.com>
On Sunday 04 November 2012 08:55 PM, Bedia, Vaibhav wrote:
> Hi Santosh,
>
> On Sat, Nov 03, 2012 at 21:22:04, Shilimkar, Santosh wrote:
>> On Friday 02 November 2012 06:02 PM, Vaibhav Bedia wrote:
>>> From: Vaibhav Hiremath <hvaibhav@ti.com>
>>>
>>> The current OMAP timer code registers two timers -
>>> one as clocksource and one as clockevent.
>> Actually OMAP also uses only one timer. The clocksource
>> is taken care by 32K syntimer till OMAP4 and by realtime
>> counter on OMAP5. There is a clocksource registration of
>> timer is available but that is not being used in systems.
>>
>
> Yes, I guess the changelog should mention that AM33xx does not
> have the 32k synctimer. I'll also add in the OMAP details that
> you pointed out so that all the details get captured.
>
>>> AM33XX has only one usable timer in the WKUP domain
>>> so one of the timers needs suspend-resume support
>>> to restore the configuration to pre-suspend state.
>>>
>>> commit adc78e6 (timekeeping: Add suspend and resume
>>> of clock event devices) introduced .suspend and .resume
>>> callbacks for clock event devices. Leverages these
>>> callbacks to have AM33XX clockevent timer which is
>>> in not in WKUP domain to behave properly across system
>>> suspend.
>>>
>> So you use WKUP domain timer for clocksource and PER
>> domain one for clock-event ?
>
> Yes, that's correct.
>
>>
>>
>>> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
>>> Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
>>> ---
>>> arch/arm/mach-omap2/timer.c | 31 +++++++++++++++++++++++++++++++
>>> 1 files changed, 31 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
>>> index 6584ee0..e8781fd 100644
>>> --- a/arch/arm/mach-omap2/timer.c
>>> +++ b/arch/arm/mach-omap2/timer.c
>>> @@ -135,6 +135,35 @@ static void omap2_gp_timer_set_mode(enum clock_event_mode mode,
>>> }
>>> }
>>>
>>> +static void omap_clkevt_suspend(struct clock_event_device *unused)
>>> +{
>>> + char name[10];
>>> + struct omap_hwmod *oh;
>>> +
>>> + sprintf(name, "timer%d", 2);
>>> + oh = omap_hwmod_lookup(name);
>>> + if (!oh)
>>> + return;
>>
>> You can move all the look up stuff in init code and then
>> suspend resume hooks will be cleaner.
>
> Will do. Kevin also pointed this out.
>
>>> +
>>> + omap_hwmod_idle(oh);
>>> +}
>>> +
>>> +static void omap_clkevt_resume(struct clock_event_device *unused)
>>> +{
>>> + char name[10];
>>> + struct omap_hwmod *oh;
>>> +
>>> + sprintf(name, "timer%d", 2);
>>> + oh = omap_hwmod_lookup(name);
>>> + if (!oh)
>>> + return;
>>> +
>>> + omap_hwmod_enable(oh);
>>> + __omap_dm_timer_load_start(&clkev,
>>> + OMAP_TIMER_CTRL_ST | OMAP_TIMER_CTRL_AR, 0, 1);
>>> + __omap_dm_timer_int_enable(&clkev, OMAP_TIMER_INT_OVERFLOW);
>>> +}
>>> +
>> OK. So since your clk_event stops when PER idles, how do you plan
>> to support the SOC idle. For CPUIDLE path, you need your clock-event
>> to wakeup the system based on next timer expiry. So you need your
>> clock event to be active. Indirectly, you can't let PER idle which
>> leads npo CORE idle->SOC idle.
>>
>> How do you plan to address this ? Os is SOC idle is not suppose
>> to be added for AMXXX ?
>>
>
> We can't really have SOC idle on AM33xx or at least that's what I think.
> The deepest that we should be able to support is MPU off with external
> memory in self-refresh mode. I mentioned the reasons for that in the
> reply to Kevin [1]. If there's any another approach that we could take
> that would be great to know.
>
Thanks for information.
Regards
Santosh
^ permalink raw reply
* [PATCH 13/15] ARM: DTS: AM33XX: Add nodes for OCMCRAM and Mailbox
From: Santosh Shilimkar @ 2012-11-05 14:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <B5906170F1614E41A8A28DE3B8D121433EBFFD0A@DBDE01.ent.ti.com>
On Sunday 04 November 2012 08:56 PM, Bedia, Vaibhav wrote:
> On Sat, Nov 03, 2012 at 21:24:14, Shilimkar, Santosh wrote:
>> On Friday 02 November 2012 06:02 PM, Vaibhav Bedia wrote:
>>> Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
>>> ---
>>> arch/arm/boot/dts/am33xx.dtsi | 11 +++++++++++
>>> 1 files changed, 11 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
>>> index bb31bff..e2cbf24 100644
>>> --- a/arch/arm/boot/dts/am33xx.dtsi
>>> +++ b/arch/arm/boot/dts/am33xx.dtsi
>>> @@ -210,5 +210,16 @@
>>> interrupt-parent = <&intc>;
>>> interrupts = <91>;
>>> };
>>> +
>>> + ocmcram: ocmcram at 40300000 {
>>> + compatible = "ti,ocmcram";
>>> + ti,hwmods = "ocmcram";
>>> + ti,no_idle_on_suspend;
>>> + };
>> Whats the intention behind adding OCMRAM ?
>> Sorry if I missed any comments from the cover letter ?
>>
>
> We need a mechanism to ensure that the clock to OCMC is kept running
> during boot and that it doesn't get disabled as part of the suspend
> sequence. Since the hwmod data for OCMC is already present and we have
> the no_idle_on_suspend flag for hwmod entries we get the desired behavior.
>
> This could also have been done via the clock tree but looks like we
> want to avoid adding leaf nodes in the clock data, hence the hwmod +
> DT approach.
>
OK. I was just comparing the OCMC RAM on OMAP which is always
clocked and hence didn't need any of the above.
Regards
Santosh
^ permalink raw reply
* [PATCH 01/15] ARM: OMAP2+: mailbox: Add an API for flushing the FIFO
From: Santosh Shilimkar @ 2012-11-05 14:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <B5906170F1614E41A8A28DE3B8D121433EBFFD12@DBDE01.ent.ti.com>
On Sunday 04 November 2012 08:56 PM, Bedia, Vaibhav wrote:
> On Sat, Nov 03, 2012 at 21:33:47, Shilimkar, Santosh wrote:
> [...]
>
>>> +static int omap2_mbox_fifo_needs_flush(struct omap_mbox *mbox)
>>> +{
>>> + struct omap_mbox2_fifo *fifo =
>>> + &((struct omap_mbox2_priv *)mbox->priv)->tx_fifo;
>> type casting is generally avoided in linux code.
>
> I was just trying to be consistent with the rest of the mailbox FIFO
> related code :)
>
> Will see how to get rid of these globally in the next version.
>
>>> + return mbox_read_reg(fifo->msg_stat);
>>> +}
>>> +
>>> +static mbox_msg_t omap2_mbox_fifo_readback(struct omap_mbox *mbox)
>>> +{
>>> + struct omap_mbox2_fifo *fifo =
>>> + &((struct omap_mbox2_priv *)mbox->priv)->tx_fifo;
>>> + return (mbox_msg_t) mbox_read_reg(fifo->msg);
>> same here.
>
> Ok.
>
>>> +}
>>> +
>>> /* Mailbox IRQ handle functions */
>>> static void omap2_mbox_enable_irq(struct omap_mbox *mbox,
>>> omap_mbox_type_t irq)
>>> @@ -205,19 +219,21 @@ static void omap2_mbox_restore_ctx(struct omap_mbox *mbox)
>>> }
>>>
>>> static struct omap_mbox_ops omap2_mbox_ops = {
>>> - .type = OMAP_MBOX_TYPE2,
>>> - .startup = omap2_mbox_startup,
>>> - .shutdown = omap2_mbox_shutdown,
>>> - .fifo_read = omap2_mbox_fifo_read,
>>> - .fifo_write = omap2_mbox_fifo_write,
>>> - .fifo_empty = omap2_mbox_fifo_empty,
>>> - .fifo_full = omap2_mbox_fifo_full,
>>> - .enable_irq = omap2_mbox_enable_irq,
>>> - .disable_irq = omap2_mbox_disable_irq,
>>> - .ack_irq = omap2_mbox_ack_irq,
>>> - .is_irq = omap2_mbox_is_irq,
>>> - .save_ctx = omap2_mbox_save_ctx,
>>> - .restore_ctx = omap2_mbox_restore_ctx,
>>> + .type = OMAP_MBOX_TYPE2,
>>> + .startup = omap2_mbox_startup,
>>> + .shutdown = omap2_mbox_shutdown,
>>> + .fifo_read = omap2_mbox_fifo_read,
>>> + .fifo_write = omap2_mbox_fifo_write,
>>> + .fifo_empty = omap2_mbox_fifo_empty,
>>> + .fifo_full = omap2_mbox_fifo_full,
>>> + .fifo_needs_flush = omap2_mbox_fifo_needs_flush,
>>> + .fifo_readback = omap2_mbox_fifo_readback,
>>> + .enable_irq = omap2_mbox_enable_irq,
>>> + .disable_irq = omap2_mbox_disable_irq,
>>> + .ack_irq = omap2_mbox_ack_irq,
>>> + .is_irq = omap2_mbox_is_irq,
>>> + .save_ctx = omap2_mbox_save_ctx,
>>> + .restore_ctx = omap2_mbox_restore_ctx,
>> You should do the indentation fix in another patch.
>>
>
> Ok will split it up.
>
>>> };
>>>
>>> /*
>>> diff --git a/arch/arm/plat-omap/include/plat/mailbox.h b/arch/arm/plat-omap/include/plat/mailbox.h
>>> index cc3921e..e136529 100644
>>> --- a/arch/arm/plat-omap/include/plat/mailbox.h
>>> +++ b/arch/arm/plat-omap/include/plat/mailbox.h
>>> @@ -29,6 +29,8 @@ struct omap_mbox_ops {
>>> void (*fifo_write)(struct omap_mbox *mbox, mbox_msg_t msg);
>>> int (*fifo_empty)(struct omap_mbox *mbox);
>>> int (*fifo_full)(struct omap_mbox *mbox);
>>> + int (*fifo_needs_flush)(struct omap_mbox *mbox);
>>> + mbox_msg_t (*fifo_readback)(struct omap_mbox *mbox);
>> Do you think passing the msg structure as an argument and letting the
>> function populate it will be better instead of returning the msg
>> structure ? No strong opinion since from read_foo() point of view
>> what you have done might be right thing. In either case, please
>> get rid of typecasting.
>>
>
> Passing the msg structure looks fine. Will do that in the next version.
>
OK
Regards
Santosh
^ permalink raw reply
* [PATCH 02/15] ARM: OMAP2+: mailbox: Add support for AM33XX
From: Santosh Shilimkar @ 2012-11-05 15:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <B5906170F1614E41A8A28DE3B8D121433EBFFD1A@DBDE01.ent.ti.com>
On Sunday 04 November 2012 08:56 PM, Bedia, Vaibhav wrote:
> On Sat, Nov 03, 2012 at 21:40:37, Shilimkar, Santosh wrote:
> [...]
>
>>> +#if defined(CONFIG_SOC_AM33XX)
>>> + else if (soc_is_am33xx()) {
>>> + list = am33xx_mboxes;
>>> +
>>> + list[0]->irq = platform_get_irq(pdev, 0);
>>> + }
>>> +#endif
>> #ifdef in middle of the function looks really ugly. But I can't complain
>> just for your patch because looks like rest of the mailbox code is
>> flooded with #ifdeffery.
>>
>> Mailbox needs cleanup. and probably can be moved out of
>> arch/arm/*omap*/ to some driver directory.
>>
>
> Tony pointed out that the movement to drivers directory
> is underway [1]. Getting rid of the #ifdeffery could be next.
>
Thanks for the pointer. Nice to see mailbox is getting moved
to drivers directory.
Regards
Santosh
^ permalink raw reply
* [PATCH v3 04/11] clk: davinci - add pll divider clock driver
From: Murali Karicheri @ 2012-11-05 15:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50950820.3050505@ti.com>
On 11/03/2012 08:03 AM, Sekhar Nori wrote:
> On 11/2/2012 7:23 PM, Murali Karicheri wrote:
>> On 11/02/2012 07:33 AM, Sekhar Nori wrote:
>>> On 10/25/2012 9:41 PM, Murali Karicheri wrote:
>>>
>>>> pll dividers are present in the pll controller of DaVinci and Other
>>>> SoCs that re-uses the same hardware IP. This has a enable bit for
>>>> bypass the divider or enable the driver. This is a sub class of the
>>>> clk-divider clock checks the enable bit to calculare the rate and
>>>> invoke the recalculate() function of the clk-divider if enabled.
>>>>
>>>> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
>>>> ---
>>>> +/**
>>>> + * clk_register_davinci_plldiv - register function for DaVinci PLL
>>>> divider clk
>>>> + *
>>>> + * @dev: device ptr
>>>> + * @name: name of the clock
>>>> + * @parent_name: name of parent clock
>>>> + * @plldiv_data: ptr to pll divider data
>>>> + * @lock: ptr to spinlock passed to divider clock
>>>> + */
>>>> +struct clk *clk_register_davinci_plldiv(struct device *dev,
>>> Why do you need a dev pointer here and which device does it point to? In
>>> the only usage of this API in the series, you pass a NULL here. I should
>>> have probably asked this question on one of the earlier patches itself.
>>>
>> I did a grep in the drivers/clk directory. All of the platform drivers
>> are having the device ptr and all of them are called with NULL. I am not
>> sure what is the intent of this arg in the API. As per documentation of
> I just took a look at the mxs example you referenced below and it does
> not take a dev pointer.
>
> struct clk *mxs_clk_div(const char *name, const char *parent_name,
> void __iomem *reg, u8 shift, u8 width, u8 busy)
> {
>
>> the clk_register() API, the device ptr points to the device that is
>> registering this clk. So if a specific device driver ever has to
>> register a PLL div clk, this will be non NULL. In the normal use case,
>> clk is registered in a platform specific code and is always passed NULL.
>>
>> The platform/SoC specific clock initialization code will be using
>> davinci_plldiv_clk() that doesn't have a device ptr arg.
>> So this can be changed in future in sync with other drivers (assuming
>> this will get removed if unused), and changes
>> doesn't impact the platform code that initialize the clock. So IMO, we
>> should keep this arg so that it is in sync with other driver APIs.
> I think you should get rid of this unused arg and introduce it when you
> actually need it. That way we are clear about why we need it.
>
You are right. I will remove it and for other drivers.
>> + const char *name, const char *parent_name,
>> + struct clk_plldiv_data *plldiv_data,
>> + spinlock_t *lock)
>> +{
>> + struct clk_div *div;
>> + struct clk *clk;
>> + struct clk_init_data init;
>> +
>> + div = kzalloc(sizeof(*div), GFP_KERNEL);
>> + if (!div)
>> + return ERR_PTR(-ENOMEM);
>> +
>> + init.name = name;
>> + init.ops = &clk_div_ops;
>> + init.flags = plldiv_data->flags;
>> + init.parent_names = (parent_name ? &parent_name : NULL);
>> + init.num_parents = (parent_name ? 1 : 0);
>> +
>> + div->reg = plldiv_data->reg;
>> + div->en_id = plldiv_data->en_id;
>> +
>> + div->divider.reg = plldiv_data->reg;
>> + div->divider.shift = plldiv_data->shift;
>> + div->divider.width = plldiv_data->width;
>> + div->divider.flags = plldiv_data->divider_flags;
>> + div->divider.lock = lock;
>> + div->divider.hw.init = &init;
>> + div->ops = &clk_divider_ops;
>> +
>> + clk = clk_register(NULL, &div->divider.hw);
>>
>>> Shouldn't you be calling clk_register_divider() here which in turn will
>>> do clk_register()?
>> As stated in the top of the file, this is a subclass driver of clk-div
>> similar in line with mxs/clk-div.c. The
>> driver registers the clock instead of calling clk_register_divider() so
>> that it's ops function has a chance to do whatever it wants to do and
>> call the divider ops function after that.
> I see that now. I should have paid more attention.
>
> Regards,
> Sekhar
>
^ permalink raw reply
* [PATCH 0/8] mfd: Batch together MFD related patches
From: Lee Jones @ 2012-11-05 15:10 UTC (permalink / raw)
To: linux-arm-kernel
Hi Sam,
I know you've been busy giving NFC presentations at ELC, but ... :)
All these patches have been on the list in various other patch-sets
for some time and have been reviewed by some key people already. All
other patches from the patch-sets have been taken, so I thought I'd
batch these up for easy review/acceptance.
Documentation/devicetree/bindings/mfd/stmpe.txt | 25 ++++
drivers/mfd/ab8500-core.c | 98 ++++-----------
drivers/mfd/db8500-prcmu.c | 8 +-
drivers/mfd/stmpe.c | 151 ++++++++++++++++-------
include/linux/mfd/stmpe.h | 2 +
5 files changed, 160 insertions(+), 124 deletions(-)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox