* [PATCH 2/8] mfd: Prevent STMPE from abusing mfd_add_devices' irq_base parameter
From: Lee Jones @ 2012-11-05 15:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352128236-11554-1-git-send-email-lee.jones@linaro.org>
Originally IRQ incrementers were provided in some template resource
structures for keypad and touchscreen devices. These were passed as
IORESOURCE_IRQs to MFD core in the usual way. The true device IRQs
were instead added to the irq_base when mfd_add_devices was invoked.
This is clearly an abuse of the call, and does not scale when IRQ
Domains are brought into play. Before we can provide the STMPE with
its own IRQ Domain we must first fix this. This patche keeps most
of the driver's structure, keeping the template strategy. However,
instead of providing the IRQ as an increment to irq_base, we
dynamically populate the IORESOURCE_IRQ with the correct device IRQ.
Cc: Samuel Ortiz <sameo@linux.intel.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/mfd/stmpe.c | 25 +++++++++++++------------
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/mfd/stmpe.c b/drivers/mfd/stmpe.c
index c94f521..ad13cb0 100644
--- a/drivers/mfd/stmpe.c
+++ b/drivers/mfd/stmpe.c
@@ -310,14 +310,10 @@ static struct mfd_cell stmpe_gpio_cell_noirq = {
static struct resource stmpe_keypad_resources[] = {
{
.name = "KEYPAD",
- .start = 0,
- .end = 0,
.flags = IORESOURCE_IRQ,
},
{
.name = "KEYPAD_OVER",
- .start = 1,
- .end = 1,
.flags = IORESOURCE_IRQ,
},
};
@@ -397,14 +393,10 @@ static struct stmpe_variant_info stmpe801_noirq = {
static struct resource stmpe_ts_resources[] = {
{
.name = "TOUCH_DET",
- .start = 0,
- .end = 0,
.flags = IORESOURCE_IRQ,
},
{
.name = "FIFO_TH",
- .start = 1,
- .end = 1,
.flags = IORESOURCE_IRQ,
},
};
@@ -959,10 +951,10 @@ static int __devinit stmpe_chip_init(struct stmpe *stmpe)
}
static int __devinit stmpe_add_device(struct stmpe *stmpe,
- struct mfd_cell *cell, int irq)
+ struct mfd_cell *cell)
{
return mfd_add_devices(stmpe->dev, stmpe->pdata->id, cell, 1,
- NULL, stmpe->irq_base + irq, NULL);
+ NULL, stmpe->irq_base, NULL);
}
static int __devinit stmpe_devices_init(struct stmpe *stmpe)
@@ -970,7 +962,7 @@ static int __devinit stmpe_devices_init(struct stmpe *stmpe)
struct stmpe_variant_info *variant = stmpe->variant;
unsigned int platform_blocks = stmpe->pdata->blocks;
int ret = -EINVAL;
- int i;
+ int i, j;
for (i = 0; i < variant->num_blocks; i++) {
struct stmpe_variant_block *block = &variant->blocks[i];
@@ -978,8 +970,17 @@ static int __devinit stmpe_devices_init(struct stmpe *stmpe)
if (!(platform_blocks & block->block))
continue;
+ for (j = 0; j < block->cell->num_resources; j++) {
+ struct resource *res =
+ (struct resource *) &block->cell->resources[j];
+
+ /* Dynamically fill in a variant's IRQ. */
+ if (res->flags & IORESOURCE_IRQ)
+ res->start = res->end = block->irq + j;
+ }
+
platform_blocks &= ~block->block;
- ret = stmpe_add_device(stmpe, block->cell, block->irq);
+ ret = stmpe_add_device(stmpe, block->cell);
if (ret)
return ret;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/8] mfd: ab8500-core: Remove unused ab8500-gpio IRQ ranges
From: Lee Jones @ 2012-11-05 15:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352128236-11554-1-git-send-email-lee.jones@linaro.org>
The IRQ ranges provided in ab8500-core to be passed on to the
ab8500-gpio driver are not only redundant, but they are also
causing a warning in the boot log. These IRQ ranges, like any
other MFD related IRQ resource are passed though MFD core for
automatic conversion to virtual IRQs; however, MFD core does
not support IRQ mapping of IRQ ranges. Let's just remove them.
Cc: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/mfd/ab8500-core.c | 36 ------------------------------------
1 file changed, 36 deletions(-)
diff --git a/drivers/mfd/ab8500-core.c b/drivers/mfd/ab8500-core.c
index 1667c77..e7197fe 100644
--- a/drivers/mfd/ab8500-core.c
+++ b/drivers/mfd/ab8500-core.c
@@ -591,38 +591,6 @@ int ab8500_suspend(struct ab8500 *ab8500)
return 0;
}
-/* AB8500 GPIO Resources */
-static struct resource __devinitdata ab8500_gpio_resources[] = {
- {
- .name = "GPIO_INT6",
- .start = AB8500_INT_GPIO6R,
- .end = AB8500_INT_GPIO41F,
- .flags = IORESOURCE_IRQ,
- }
-};
-
-/* AB9540 GPIO Resources */
-static struct resource __devinitdata ab9540_gpio_resources[] = {
- {
- .name = "GPIO_INT6",
- .start = AB8500_INT_GPIO6R,
- .end = AB8500_INT_GPIO41F,
- .flags = IORESOURCE_IRQ,
- },
- {
- .name = "GPIO_INT14",
- .start = AB9540_INT_GPIO50R,
- .end = AB9540_INT_GPIO54R,
- .flags = IORESOURCE_IRQ,
- },
- {
- .name = "GPIO_INT15",
- .start = AB9540_INT_GPIO50F,
- .end = AB9540_INT_GPIO54F,
- .flags = IORESOURCE_IRQ,
- }
-};
-
static struct resource __devinitdata ab8500_gpadc_resources[] = {
{
.name = "HW_CONV_END",
@@ -1065,8 +1033,6 @@ static struct mfd_cell __devinitdata ab8500_devs[] = {
{
.name = "ab8500-gpio",
.of_compatible = "stericsson,ab8500-gpio",
- .num_resources = ARRAY_SIZE(ab8500_gpio_resources),
- .resources = ab8500_gpio_resources,
},
{
.name = "ab8500-usb",
@@ -1083,8 +1049,6 @@ static struct mfd_cell __devinitdata ab8500_devs[] = {
static struct mfd_cell __devinitdata ab9540_devs[] = {
{
.name = "ab8500-gpio",
- .num_resources = ARRAY_SIZE(ab9540_gpio_resources),
- .resources = ab9540_gpio_resources,
},
{
.name = "ab9540-usb",
--
1.7.9.5
^ permalink raw reply related
* [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
* [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 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 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 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 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: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 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
* 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] 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
* [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
* [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
* [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: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 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 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
* [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
* [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 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] 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
* 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 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
* [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
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