* [PATCH v2 6/7] clk: Add initial WM831x clock driver
From: Mark Brown @ 2011-10-04 20:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111004181818.GD2870@ponder.secretlab.ca>
On Tue, Oct 04, 2011 at 12:18:18PM -0600, Grant Likely wrote:
> On Mon, Sep 26, 2011 at 10:38:58AM +0100, Mark Brown wrote:
> > No, that's not helpful. The issue isn't the device probe code itself,
> > the issue is things like module unload not doing what they're supposed
> > to do and leaving the device lying around or something - there's rather
> > more going on than just the plain API call.
> Then lets fix the core code. I see this pattern show up again and
> again of extra boilerplate going around
> platform_driver_{register,unregister}(). That says to me that there
> either needs to be a new helper, or the core code needs to be made
> more verbose.
I'd go with the latter, it's pretty much the approach the subsystems I
help maintain have been taking. In fast paths it's a bit different but
in slow paths it tends to be helpful to know why things just fell over.
> In fact, I've been considering adding a macro for
> {platform,i2c,spi,...}_drivers that does all the module boilerplate
> for the common case of only registering a driver at init time.
> Something like:
> #define module_platform_driver(__driver) \
> int __driver##_init(void) \
> { \
> return platform_driver_register(&(__driver)); \
> } \
> module_init(__driver##_init); \
> void ##__driver##_exit(void) \
> { \
> platform_driver_unregister(&(__driver)); \
> } \
> module_exit(##__driver##_exit);
> It's not a lot of code, but I dislike how much boilerplate every
> single driver has to use if it doesn't do anything special.
Yeah, this sort of stuff would be helpful - there's quite a bit of
boilerplate you end up having to write to get drivers going.
^ permalink raw reply
* [PATCH 32/55] i2c: irq: Remove IRQF_DISABLED
From: Ben Dooks @ 2011-10-04 20:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316681962-8217-33-git-send-email-yong.zhang0@gmail.com>
On Thu, Sep 22, 2011 at 04:58:59PM +0800, Yong Zhang wrote:
> Since commit [e58aa3d2: genirq: Run irq handlers with interrupts disabled],
> We run all interrupt handlers with interrupts disabled
> and we even check and yell when an interrupt handler
> returns with interrupts enabled (see commit [b738a50a:
> genirq: Warn when handler enables interrupts]).
>
> So now this flag is a NOOP and can be removed.
ok, applied thanks.
--
Ben Dooks, ben at fluff.org, http://www.fluff.org/ben/
Large Hadron Colada: A large Pina Colada that makes the universe disappear.
^ permalink raw reply
* [PATCH v6 01/16] OMAP2+: hwmod: Add API to enable IO ring wakeup.
From: Kevin Hilman @ 2011-10-04 21:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E871883.4010207@ti.com>
Hi Rajendra,
Rajendra Nayak <rnayak@ti.com> writes:
> On Friday 30 September 2011 04:31 PM, Govindraj.R wrote:
>> Add API to enable IO pad wakeup capability based on mux dynamic pad and
>> wake_up enable flag available from hwmod_mux initialization.
>>
>> Use the wakeup_enable flag and enable wakeup capability
>> for the given pads. Wakeup capability will be enabled/disabled
>> during hwmod idle transition based on whether wakeup_flag is
>> set or cleared.
>>
>> Call the omap_hwmod_set_ioring_wakeup from hwmod_wakeup_enable/disable.
>>
>> Signed-off-by: Govindraj.R<govindraj.raja@ti.com>
>> ---
>> arch/arm/mach-omap2/omap_hwmod.c | 59 ++++++++++++++++++++++++++++++++++++++
>> 1 files changed, 59 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
>> index 84cc0bd..e751dd9 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod.c
>> @@ -2062,6 +2062,34 @@ static int __init omap_hwmod_setup_all(void)
>> core_initcall(omap_hwmod_setup_all);
>>
>> /**
>> + * omap_hwmod_set_ioring_wakeup - enable io pad wakeup flag.
>> + * @oh: struct omap_hwmod *
>> + * @set: bool value indicating to set or clear wakeup status.
>> + *
>> + * Set or Clear wakeup flag for the io_pad.
>> + */
>> +static int omap_hwmod_set_ioring_wakeup(struct omap_hwmod *oh, bool set_wake)
>> +{
>> + struct omap_device_pad *pad;
>> + int ret = -EINVAL, j;
>> +
>> + if (oh->mux&& oh->mux->enabled) {
>> + for (j = 0; j< oh->mux->nr_pads_dynamic; j++) {
>> + pad = oh->mux->pads_dynamic[j];
>> + if (pad->flags& OMAP_DEVICE_PAD_WAKEUP) {
>> + if (set_wake)
>> + pad->idle |= OMAP_WAKEUP_EN;
>> + else
>> + pad->idle&= ~OMAP_WAKEUP_EN;
>
> I think apart from enabling/disabling the IO wakeup's at the pad
> level, there is also a need to trigger the IO daisy chain control
> (Wu clock) by programming the PRCM.PM_WKEN_WKUP[16] EN_IO_CHAIN
> bit and waiting on the PRCM.PM_WKST_WKUP[16] ST_IO_CHAIN) bit,
> which is done by the omap3_enable/disable_io_chain function.
> This is still done in the cpuidle path, but it makes sense to
> move that over here, since it should be done every time a pad
> level wakeup is enabled or disabled.
So should it be done just here or also in the idle path? In general,
I'm certainly for moving things out of the idle path into the places
where they belong.
However, I don't get from the TRM description below that it should be
done every time a pad-level wake is enabled or disabled. Can you
clarify what part of the TRM description you mean?
All I understand is that it has to be done before PER domain
transisions.
Also, if this were to happen, are there side-effects of having the IO
daisy chain armed outside the idle path?
Kevin
> See section 3.5.7.2.2 I/O Wake-Up Mechanism of 36xx TRM revA.
>
> "The I/O wake-up scheme is enabled by triggering the I/O daisy chain
> control (Wu clock) by
> programming a dedicated register (PRCM.PM_WKEN_WKUP[16] EN_IO_CHAIN)
> in the PRCM module.Software must wait for the I/O daisy chain to
> complete before it transitions the PER domain to a
> nonfunctional state. This is done by polling a dedicated status bit in
> the PRCM module
> (PRCM.PM_WKST_WKUP[16] ST_IO_CHAIN). This status bit must be cleared
> by software when the bit is
> read to 1."
^ permalink raw reply
* [GIT PULL] I2C: OMAP: misc. cleanup for v3.2
From: Ben Dooks @ 2011-10-04 21:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E80FD1A.5040006@deeprootsystems.com>
On Mon, Sep 26, 2011 at 03:30:50PM -0700, Kevin Hilman wrote:
> ping
>
> On 09/06/2011 03:31 PM, Kevin Hilman wrote:
> >Hi Ben,
> >
> >On 08/23/2011 05:10 PM, Kevin Hilman wrote:
> >>Ben,
> >>
> >>Here's one more I2C cleanup series for v3.2.
> >>
> >>It applies on top of my for_3.2/i2c-fixes branch just submitted.
> >>
> >>Please pull into your tree for linux-next.
> >
> >I see you pulled the other two, can you pull this one as well?
I've tried, but it seems to note that everything is up to date.
Is this a suitable branch to pull onto latest so I can reset
my next tree?
--
Ben
^ permalink raw reply
* Please help with the OMAP static mapping mess
From: Nicolas Pitre @ 2011-10-04 21:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111003224411.GA19897@n2100.arm.linux.org.uk>
On Mon, 3 Oct 2011, Russell King - ARM Linux wrote:
> On Mon, Oct 03, 2011 at 06:09:57PM -0400, Nicolas Pitre wrote:
> > On Mon, 3 Oct 2011, Tony Lindgren wrote:
> > > Having the SRAM base address move around with different sizes also
> > > requires the SoC detection.. Otherwise we can end up mapping wrong
> > > size and end up trying to access secure SRAM that will hang the system.
> > >
> > > The way to fix it is to move SRAM init happen much later so we don't
> > > have to map it early. I guess now we could use ioremap for SRAM,
> > > although we may not want device attributes for the executable code?
> > > Got any suggestions here on how we should map SRAM later on?
> >
> > You can use a variant of ioremap() such as __arm_ioremap() which let you
> > specify the memory attribute.
>
> Just be aware that __arm_ioremap() always ends up with stuff in the
> kernel domain, but that's not what you end up with using create_mapping().
> So I'd prefer it if you didn't suggest that __arm_ioremap() should be used
> with types not listed in asm/io.h.
Well, here we're talking about MT_MEMORY and MT_MEMORY_NONCACHED, and
they are using DOMAIN_KERNEL already. So no difference there.
Which makes me think... with all those architectures intercepting
ioremap calls in order to provide an equivalent static mapping address,
they already get an unexpected domain given that static mappings are
mostly DOMAIN_IO and not DOMAIN_KERNEL as would result from an non
intercepted ioremap call.
Nicolas
^ permalink raw reply
* [PATCH 0/2] ARM: OMAP2+: timer fixes / cleanup
From: Benoit Cousson @ 2011-10-04 21:20 UTC (permalink / raw)
To: linux-arm-kernel
Hi Tony,
Here is the series to fix the warning and remove the redundant
latency structure that be removed since the timer runtime PM
adaptation was just pulled.
I was just able to test that on OMAP4.
Patches are based on Kevin's for_3.2/omap_device-2 branch
and are available here:
git://gitorious.org/omap-pm/linux.git for_3.2/timer_fixes
Regards,
Benoit
Benoit Cousson (2):
ARM: OMAP2+: clock data: Remove redundant timer clkdev
ARM: OMAP2+: timer: Remove omap_device_pm_latency
arch/arm/mach-omap2/clock2420_data.c | 12 ------------
arch/arm/mach-omap2/clock2430_data.c | 12 ------------
arch/arm/mach-omap2/clock3xxx_data.c | 12 ------------
arch/arm/mach-omap2/clock44xx_data.c | 11 -----------
arch/arm/mach-omap2/timer.c | 12 +-----------
5 files changed, 1 insertions(+), 58 deletions(-)
^ permalink raw reply
* [PATCH 1/2] ARM: OMAP2+: clock data: Remove redundant timer clkdev
From: Benoit Cousson @ 2011-10-04 21:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317763241-21422-1-git-send-email-b-cousson@ti.com>
The commit 318c3e15cd55c73a26ae22a65a8183655b3003f9
added some "fck" clock alias to timer devices that are
not needed anymore since hwmod framework will create
them automatically.
A warning was added to highlight and thus fix the redundancy.
[ 0.616424] omap_timer.1: alias fck already exists
[ 0.621948] omap_timer.2: alias fck already exists
[ 0.627380] omap_timer.3: alias fck already exists
[ 0.632781] omap_timer.4: alias fck already exists
[ 0.638214] omap_timer.5: alias fck already exists
[ 0.643615] omap_timer.6: alias fck already exists
[ 0.649078] omap_timer.7: alias fck already exists
[ 0.654479] omap_timer.8: alias fck already exists
[ 0.659881] omap_timer.9: alias fck already exists
[ 0.665283] omap_timer.10: alias fck already exists
[ 0.670776] omap_timer.11: alias fck already exists
Remove all the clkdev entries for timer fck alias.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Tarun Kanti DebBarma <tarun.kanti@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/clock2420_data.c | 12 ------------
arch/arm/mach-omap2/clock2430_data.c | 12 ------------
arch/arm/mach-omap2/clock3xxx_data.c | 12 ------------
arch/arm/mach-omap2/clock44xx_data.c | 11 -----------
4 files changed, 0 insertions(+), 47 deletions(-)
diff --git a/arch/arm/mach-omap2/clock2420_data.c b/arch/arm/mach-omap2/clock2420_data.c
index 14a6277..61ad385 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -1898,18 +1898,6 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL, "pka_ick", &pka_ick, CK_242X),
CLK(NULL, "usb_fck", &usb_fck, CK_242X),
CLK("musb-hdrc", "fck", &osc_ck, CK_242X),
- CLK("omap_timer.1", "fck", &gpt1_fck, CK_242X),
- CLK("omap_timer.2", "fck", &gpt2_fck, CK_242X),
- CLK("omap_timer.3", "fck", &gpt3_fck, CK_242X),
- CLK("omap_timer.4", "fck", &gpt4_fck, CK_242X),
- CLK("omap_timer.5", "fck", &gpt5_fck, CK_242X),
- CLK("omap_timer.6", "fck", &gpt6_fck, CK_242X),
- CLK("omap_timer.7", "fck", &gpt7_fck, CK_242X),
- CLK("omap_timer.8", "fck", &gpt8_fck, CK_242X),
- CLK("omap_timer.9", "fck", &gpt9_fck, CK_242X),
- CLK("omap_timer.10", "fck", &gpt10_fck, CK_242X),
- CLK("omap_timer.11", "fck", &gpt11_fck, CK_242X),
- CLK("omap_timer.12", "fck", &gpt12_fck, CK_242X),
CLK("omap_timer.1", "32k_ck", &func_32k_ck, CK_243X),
CLK("omap_timer.2", "32k_ck", &func_32k_ck, CK_243X),
CLK("omap_timer.3", "32k_ck", &func_32k_ck, CK_243X),
diff --git a/arch/arm/mach-omap2/clock2430_data.c b/arch/arm/mach-omap2/clock2430_data.c
index ea6717c..0cc1287 100644
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -1998,18 +1998,6 @@ static struct omap_clk omap2430_clks[] = {
CLK(NULL, "mdm_intc_ick", &mdm_intc_ick, CK_243X),
CLK("omap_hsmmc.0", "mmchsdb_fck", &mmchsdb1_fck, CK_243X),
CLK("omap_hsmmc.1", "mmchsdb_fck", &mmchsdb2_fck, CK_243X),
- CLK("omap_timer.1", "fck", &gpt1_fck, CK_243X),
- CLK("omap_timer.2", "fck", &gpt2_fck, CK_243X),
- CLK("omap_timer.3", "fck", &gpt3_fck, CK_243X),
- CLK("omap_timer.4", "fck", &gpt4_fck, CK_243X),
- CLK("omap_timer.5", "fck", &gpt5_fck, CK_243X),
- CLK("omap_timer.6", "fck", &gpt6_fck, CK_243X),
- CLK("omap_timer.7", "fck", &gpt7_fck, CK_243X),
- CLK("omap_timer.8", "fck", &gpt8_fck, CK_243X),
- CLK("omap_timer.9", "fck", &gpt9_fck, CK_243X),
- CLK("omap_timer.10", "fck", &gpt10_fck, CK_243X),
- CLK("omap_timer.11", "fck", &gpt11_fck, CK_243X),
- CLK("omap_timer.12", "fck", &gpt12_fck, CK_243X),
CLK("omap_timer.1", "32k_ck", &func_32k_ck, CK_243X),
CLK("omap_timer.2", "32k_ck", &func_32k_ck, CK_243X),
CLK("omap_timer.3", "32k_ck", &func_32k_ck, CK_243X),
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c b/arch/arm/mach-omap2/clock3xxx_data.c
index 65dd363..5d0064a 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3464,18 +3464,6 @@ static struct omap_clk omap3xxx_clks[] = {
CLK("musb-am35x", "fck", &hsotgusb_fck_am35xx, CK_AM35XX),
CLK(NULL, "hecc_ck", &hecc_ck, CK_AM35XX),
CLK(NULL, "uart4_ick", &uart4_ick_am35xx, CK_AM35XX),
- CLK("omap_timer.1", "fck", &gpt1_fck, CK_3XXX),
- CLK("omap_timer.2", "fck", &gpt2_fck, CK_3XXX),
- CLK("omap_timer.3", "fck", &gpt3_fck, CK_3XXX),
- CLK("omap_timer.4", "fck", &gpt4_fck, CK_3XXX),
- CLK("omap_timer.5", "fck", &gpt5_fck, CK_3XXX),
- CLK("omap_timer.6", "fck", &gpt6_fck, CK_3XXX),
- CLK("omap_timer.7", "fck", &gpt7_fck, CK_3XXX),
- CLK("omap_timer.8", "fck", &gpt8_fck, CK_3XXX),
- CLK("omap_timer.9", "fck", &gpt9_fck, CK_3XXX),
- CLK("omap_timer.10", "fck", &gpt10_fck, CK_3XXX),
- CLK("omap_timer.11", "fck", &gpt11_fck, CK_3XXX),
- CLK("omap_timer.12", "fck", &gpt12_fck, CK_3XXX),
CLK("omap_timer.1", "32k_ck", &omap_32k_fck, CK_3XXX),
CLK("omap_timer.2", "32k_ck", &omap_32k_fck, CK_3XXX),
CLK("omap_timer.3", "32k_ck", &omap_32k_fck, CK_3XXX),
diff --git a/arch/arm/mach-omap2/clock44xx_data.c b/arch/arm/mach-omap2/clock44xx_data.c
index 946bf04..f9c6425 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3363,17 +3363,6 @@ static struct omap_clk omap44xx_clks[] = {
CLK("usbhs-omap.0", "usbhost_ick", &dummy_ck, CK_443X),
CLK("usbhs-omap.0", "usbtll_fck", &dummy_ck, CK_443X),
CLK("omap_wdt", "ick", &dummy_ck, CK_443X),
- CLK("omap_timer.1", "fck", &timer1_fck, CK_443X),
- CLK("omap_timer.2", "fck", &timer2_fck, CK_443X),
- CLK("omap_timer.3", "fck", &timer3_fck, CK_443X),
- CLK("omap_timer.4", "fck", &timer4_fck, CK_443X),
- CLK("omap_timer.5", "fck", &timer5_fck, CK_443X),
- CLK("omap_timer.6", "fck", &timer6_fck, CK_443X),
- CLK("omap_timer.7", "fck", &timer7_fck, CK_443X),
- CLK("omap_timer.8", "fck", &timer8_fck, CK_443X),
- CLK("omap_timer.9", "fck", &timer9_fck, CK_443X),
- CLK("omap_timer.10", "fck", &timer10_fck, CK_443X),
- CLK("omap_timer.11", "fck", &timer11_fck, CK_443X),
CLK("omap_timer.1", "32k_ck", &sys_32k_ck, CK_443X),
CLK("omap_timer.2", "32k_ck", &sys_32k_ck, CK_443X),
CLK("omap_timer.3", "32k_ck", &sys_32k_ck, CK_443X),
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/2] ARM: OMAP2+: timer: Remove omap_device_pm_latency
From: Benoit Cousson @ 2011-10-04 21:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317763241-21422-1-git-send-email-b-cousson@ti.com>
Remove the structure since a default one is now available.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
---
arch/arm/mach-omap2/timer.c | 12 +-----------
1 files changed, 1 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index e49fc7b..037b0d7 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -408,14 +408,6 @@ static int omap2_dm_timer_set_src(struct platform_device *pdev, int source)
return ret;
}
-struct omap_device_pm_latency omap2_dmtimer_latency[] = {
- {
- .deactivate_func = omap_device_idle_hwmods,
- .activate_func = omap_device_enable_hwmods,
- .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
- },
-};
-
/**
* omap_timer_init - build and register timer device with an
* associated timer hwmod
@@ -477,9 +469,7 @@ static int __init omap_timer_init(struct omap_hwmod *oh, void *unused)
pdata->get_context_loss_count = omap_pm_get_dev_context_loss_count;
#endif
pdev = omap_device_build(name, id, oh, pdata, sizeof(*pdata),
- omap2_dmtimer_latency,
- ARRAY_SIZE(omap2_dmtimer_latency),
- 0);
+ NULL, 0, 0);
if (IS_ERR(pdev)) {
pr_err("%s: Can't build omap_device for %s: %s.\n",
--
1.7.0.4
^ permalink raw reply related
* Please help with the OMAP static mapping mess
From: Nicolas Pitre @ 2011-10-04 21:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E8AAFF9.3090600@ti.com>
On Tue, 4 Oct 2011, Santosh Shilimkar wrote:
> On Tuesday 04 October 2011 04:08 AM, Tony Lindgren wrote:
> > * Nicolas Pitre <nico@fluxnic.net> [111003 14:36]:
> >> On Mon, 3 Oct 2011, Tony Lindgren wrote:
> >>
> >>> Having the SRAM base address move around with different sizes also
> >>> requires the SoC detection.. Otherwise we can end up mapping wrong
> >>> size and end up trying to access secure SRAM that will hang the system.
> >>>
> >>> The way to fix it is to move SRAM init happen much later so we don't
> >>> have to map it early. I guess now we could use ioremap for SRAM,
> >>> although we may not want device attributes for the executable code?
> >>> Got any suggestions here on how we should map SRAM later on?
> >>
> >> You can use a variant of ioremap() such as __arm_ioremap() which let you
> >> specify the memory attribute.
> >
> > OK, I'll take a look at that.
> >
> I have tried __arm_ioremap_pfn() for some DDR mapping and it didn't
> work as expected. The mapping was not getting created.
Did you investigate why it wasn't created? Must have been a trivial
issue surely? But you have to wait until memory management is fully
initialized to call the real ioremap() though, which happens later
during the boot.
> Needless to say this can't be an IO memory. I later managed to get
> around with it by using iotable_init() though downside is I have to
> pick a static virtual address for the mapping.
You are using either MT_MEMORY or MT_MEMORY_NONCACHED in your map_desc
entry. So using e.g. __arm_ioremap(phys_addr, size, MT_MEMORY) should
give you what you need, given that this is called late enough of course.
> But I agree that SRAM mapping can be moved further down. We
> just need to ensure that it's ready before we initialise SDRC
> and PM code. SDRC reconfigure of DDR needs to be executed from
> SRAM and of-course the PM WFI routine. Today we do SDRC init early
> and that's the reason SRAM is mapped before that. So both of them
> needs to be moved down in the boot to make it work.
Note that it is best not to call iotable_init() outside of the
mdesc->map_io call path. So either you reshuffle the initialization
order so that the static mappings alre always in place before doing the
ioremap() trick, or you use __arm_ioremap() later on.
Nicolas
^ permalink raw reply
* [PATCH 0/2] ARM: OMAP2+: timer fixes / cleanup
From: Cousson, Benoit @ 2011-10-04 21:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317763241-21422-1-git-send-email-b-cousson@ti.com>
Hi Tarun,
On 10/4/2011 11:20 PM, Cousson, Benoit wrote:
> Hi Tony,
>
> Here is the series to fix the warning and remove the redundant
> latency structure that be removed since the timer runtime PM
> adaptation was just pulled.
>
> I was just able to test that on OMAP4.
It will be nice if you can test that on the other platforms.
In theory, if they are properly using hwmod that should work fine.
Thanks,
Benoit
>
> Patches are based on Kevin's for_3.2/omap_device-2 branch
> and are available here:
> git://gitorious.org/omap-pm/linux.git for_3.2/timer_fixes
>
> Regards,
> Benoit
>
>
> Benoit Cousson (2):
> ARM: OMAP2+: clock data: Remove redundant timer clkdev
> ARM: OMAP2+: timer: Remove omap_device_pm_latency
>
> arch/arm/mach-omap2/clock2420_data.c | 12 ------------
> arch/arm/mach-omap2/clock2430_data.c | 12 ------------
> arch/arm/mach-omap2/clock3xxx_data.c | 12 ------------
> arch/arm/mach-omap2/clock44xx_data.c | 11 -----------
> arch/arm/mach-omap2/timer.c | 12 +-----------
> 5 files changed, 1 insertions(+), 58 deletions(-)
>
^ permalink raw reply
* [RFC 2/5] ARM: OMAP: omap_device: add a method to set iommu private archdata
From: Cousson, Benoit @ 2011-10-04 21:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK=WgbYaEPBUz_J11+f+W+G9uUG3E6aQ-5=X9bj2nRhij-w-Sw@mail.gmail.com>
On 10/4/2011 9:54 PM, Ohad Ben-Cohen wrote:
> On Tue, Oct 4, 2011 at 8:15 PM, Kevin Hilman<khilman@ti.com> wrote:
>> The approach is OK with me, but I'm a bit torn about whether or not to
>> merge this since the need for this should go away when converting to DT.
>
> I guess it will still take some time until our boards are fully
> functional with DT, so I think we should regard this as an interim
> solution. Without this patch, a huge deal of code consolidation and
> generalization is gated (namely - generic iommu and dma api, and
> everything that depends on it, e.g. rpmsg/remoteproc).
>
>> Is anyone working on IOMMU DT description?
>
> Unless Benoit is, I'll happily pick this up.
Cool, a volunteer... You're in.
Thanks,
Benoit
^ permalink raw reply
* [PATCH v6 04/16] OMAP2+: UART: cleanup 8250 console driver support
From: Kevin Hilman @ 2011-10-04 21:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317380495-584-4-git-send-email-govindraj.raja@ti.com>
"Govindraj.R" <govindraj.raja@ti.com> writes:
> We had been using traditional 8250 driver as uart console driver
> prior to omap-serial driver. Since we have omap-serial driver
> in mainline kernel for some time now it has been used as default
> uart console driver on omap2+ platforms. Remove 8250 support for
> omap-uarts.
Nice to see the this disappearing.
> Serial_in and serial_out override for 8250 serial driver is also
> removed. Empty fifo read fix is already taken care with omap-serial
> driver with data ready bit check from LSR reg before reading RX fifo.
As stated in the previous review. Patches that move code/features
should have the removal and the add-back in the same patch. Doing so
makes it easy for reviewers to see whether it was simply moved, or if it
was modified when it was moved, etc.
> Also waiting for THRE(transmit hold reg empty) is done with wait_for_xmitr
> in omap-serial driver.
Again, remove it here in the patch that adds that support (the errata
patch I guess.)
> Remove headers that were necessary to support 8250 support
> and remove all config bindings done to keep 8250 backward compatibility
> while adding omap-serial driver. Remove omap_uart_reset needed for
> 8250 autoconf.
>
> Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
So basically, this patch should only remove the legacy 8250 support (as
the subject says) and everything else should be done in the other
relevant patches.
Kevin
^ permalink raw reply
* [PATCH] PM: HIBERNATION: add resume_wait param to support MMC-like devices as resume file
From: Rafael J. Wysocki @ 2011-10-04 22:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGsJ_4znTLmjd_qhgru_aOZPMEZc=dyXEQTqdsVGKr-GaryQsQ@mail.gmail.com>
On Thursday, September 29, 2011, Barry Song wrote:
> hi Valdis,
>
> 2011/9/29 <Valdis.Kletnieks@vt.edu>:
> > On Thu, 29 Sep 2011 02:29:08 PDT, Barry Song said:
> >
> >> This patch adds resumewait kernel param just like rootwait so
> >> that we have enough time to wait mmc ready. The differene is
> >> here we wait for resume partition but rootwait waits for rootfs
> >> partition.
> >
> > OK, seems a reasonable idea...
> >
> >> kernel/power/hibernate.c | 16 ++++++++++++++++
> >> 1 files changed, 16 insertions(+), 0 deletions(-)
> >
> > We have a __setup() parameter, this patch appears to be missing
> > a hunk for Documentation/kernel-parameters.txt?
> >
> > Fix that issue, and you can stick this on there:
> >
> > Reviewed-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>
>
> thanks. i'll add the document in v2.
I can't find the v2. Have you posted it already?
Rafael
^ permalink raw reply
* [PATCH v2] PM: HIBERNATION: add resume_wait param to support MMC-like devices as resume file
From: Rafael J. Wysocki @ 2011-10-04 22:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317309357-3871-1-git-send-email-21cnbao@gmail.com>
On Thursday, September 29, 2011, Barry Song wrote:
> From: Barry Song <baohua.song@csr.com>
>
> Some devices like mmc are async detected very slow. For example,
> drivers/mmc/host/sdhci.c launchs a 200ms delayed work to detect
> mmc partitions then add disk.
>
> we do have wait_for_device_probe and scsi_complete_async_scans
> before calling swsusp_check, but it is not enough to wait mmc.
>
> This patch adds resumewait kernel param just like rootwait so
> that we have enough time to wait mmc ready. The differene is
> here we wait for resume partition but rootwait waits for rootfs
> partition.
>
> This patch will make swsusp support many embedded products
> without scsi devices but devices like mmc.
>
> This was tested on one ARM platform with Frank Hofmann's patch.
>
> Signed-off-by: Barry Song <Baohua.Song@csr.com>
> Reviewed-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>
Sorry, I couldn't find the patch previously.
I only have one question. Namely, are there any systems that would
use resumewait and wouldn't use rootwait?
Rafael
> ---
> -v2:
> add document for the resumewait kernel parameter
>
> Documentation/kernel-parameters.txt | 4 ++++
> kernel/power/hibernate.c | 16 ++++++++++++++++
> 2 files changed, 20 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
> index 614d038..2aed0d2 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -2237,6 +2237,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
> in <PAGE_SIZE> units (needed only for swap files).
> See Documentation/power/swsusp-and-swap-files.txt
>
> + resumewait [HIBERNATION] Wait (indefinitely) for resume device to show up.
> + Useful for devices that are detected asynchronously
> + (e.g. USB and MMC devices).
> +
> hibernate= [HIBERNATION]
> noresume Don't check if there's a hibernation image
> present during boot.
> diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
> index 8f7b1db..9f4b4f3 100644
> --- a/kernel/power/hibernate.c
> +++ b/kernel/power/hibernate.c
> @@ -14,6 +14,7 @@
> #include <linux/reboot.h>
> #include <linux/string.h>
> #include <linux/device.h>
> +#include <linux/async.h>
> #include <linux/kmod.h>
> #include <linux/delay.h>
> #include <linux/fs.h>
> @@ -31,6 +32,7 @@
>
> static int nocompress = 0;
> static int noresume = 0;
> +static int resume_wait = 0;
> static char resume_file[256] = CONFIG_PM_STD_PARTITION;
> dev_t swsusp_resume_device;
> sector_t swsusp_resume_block;
> @@ -732,6 +734,13 @@ static int software_resume(void)
> * to wait for this to finish.
> */
> wait_for_device_probe();
> +
> + if (resume_wait) {
> + while ((swsusp_resume_device = name_to_dev_t(resume_file)) == 0)
> + msleep(10);
> + async_synchronize_full();
> + }
> +
> /*
> * We can't depend on SCSI devices being available after loading
> * one of their modules until scsi_complete_async_scans() is
> @@ -1060,7 +1069,14 @@ static int __init noresume_setup(char *str)
> return 1;
> }
>
> +static int __init resumewait_setup(char *str)
> +{
> + resume_wait = 1;
> + return 1;
> +}
> +
> __setup("noresume", noresume_setup);
> __setup("resume_offset=", resume_offset_setup);
> __setup("resume=", resume_setup);
> __setup("hibernate=", hibernate_setup);
> +__setup("resumewait", resumewait_setup);
>
^ permalink raw reply
* Please help with the OMAP static mapping mess
From: Russell King - ARM Linux @ 2011-10-04 22:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1110041528050.9106@xanadu.home>
On Tue, Oct 04, 2011 at 05:10:36PM -0400, Nicolas Pitre wrote:
> Which makes me think... with all those architectures intercepting
> ioremap calls in order to provide an equivalent static mapping address,
> they already get an unexpected domain given that static mappings are
> mostly DOMAIN_IO and not DOMAIN_KERNEL as would result from an non
> intercepted ioremap call.
That's a necessary evil - otherwise we have to separate out the
ioremap from vmalloc.
Incidentally, how are you dealing with the problem of a static mapping
setting up a L1 page table entry for DOMAIN_IO, and then a vmalloc
request coming in, overlapping that L1 page table?
If this memory then gets accessed with get_user() with set_fs(get_ds()),
the kernel will oops as we don't switch DOMAIN_IO memory on set_fs().
(I don't know if this happens in practice, but there's nothing to say
that it's illegal to do this.)
^ permalink raw reply
* [PATCH 2/9] regulator: helper routine to extract regulator_init_data
From: Russell King - ARM Linux @ 2011-10-04 23:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110927121003.GB4289@opensource.wolfsonmicro.com>
On Tue, Sep 27, 2011 at 01:10:04PM +0100, Mark Brown wrote:
> On Tue, Sep 27, 2011 at 03:42:45PM +0530, Rajendra Nayak wrote:
>
> > + init_data = devm_kzalloc(dev, sizeof(struct regulator_init_data),
> > + GFP_KERNEL);
> > + if (!init_data)
> > + return NULL; /* Out of memory? */
>
> This means that the init data will be kept around for the entire
> lifetime of the device rather than being discarded.
May I remind you that devm_* lifetime expires whenever the associated
driver is unbound, which can be much shorter than the lifetime of the
struct device.
It expires when any of the following occurs:
1. userspace asks the associated driver to be unbound
2. the driver is removed
3. any driver probe for this struct device fails
4. the struct device is unregistered.
So: don't use devm_* for anything other than stuff inside a driver being
associated with the struct device itself. Other uses are a bug waiting
to happen.
^ permalink raw reply
* Please help with the OMAP static mapping mess
From: Nicolas Pitre @ 2011-10-04 23:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111004225424.GA32102@n2100.arm.linux.org.uk>
On Tue, 4 Oct 2011, Russell King - ARM Linux wrote:
> On Tue, Oct 04, 2011 at 05:10:36PM -0400, Nicolas Pitre wrote:
> > Which makes me think... with all those architectures intercepting
> > ioremap calls in order to provide an equivalent static mapping address,
> > they already get an unexpected domain given that static mappings are
> > mostly DOMAIN_IO and not DOMAIN_KERNEL as would result from an non
> > intercepted ioremap call.
>
> That's a necessary evil - otherwise we have to separate out the
> ioremap from vmalloc.
>
> Incidentally, how are you dealing with the problem of a static mapping
> setting up a L1 page table entry for DOMAIN_IO, and then a vmalloc
> request coming in, overlapping that L1 page table?
>
> If this memory then gets accessed with get_user() with set_fs(get_ds()),
> the kernel will oops as we don't switch DOMAIN_IO memory on set_fs().
> (I don't know if this happens in practice, but there's nothing to say
> that it's illegal to do this.)
I suppose that didn't happen so far. Granted, moving the ioremap
optimization into core code for all machines will increase the
possibility for this to happen, even if still small.
With CPU_USE_DOMAINS not set, set_fs() is a no-op anyway, besides
addr_limit that is.
Is there a strong benefit in having static mappings being DOMAIN_IO
instead of DOMAIN_KERNEL?
Nicolas
^ permalink raw reply
* [PATCH v2 6/7] clk: Add initial WM831x clock driver
From: Grant Likely @ 2011-10-04 23:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111004205002.GA20296@opensource.wolfsonmicro.com>
On Tue, Oct 04, 2011 at 09:50:02PM +0100, Mark Brown wrote:
> On Tue, Oct 04, 2011 at 12:18:18PM -0600, Grant Likely wrote:
> > #define module_platform_driver(__driver) \
> > int __driver##_init(void) \
> > { \
> > return platform_driver_register(&(__driver)); \
> > } \
> > module_init(__driver##_init); \
> > void ##__driver##_exit(void) \
> > { \
> > platform_driver_unregister(&(__driver)); \
> > } \
> > module_exit(##__driver##_exit);
>
> > It's not a lot of code, but I dislike how much boilerplate every
> > single driver has to use if it doesn't do anything special.
>
> Yeah, this sort of stuff would be helpful - there's quite a bit of
> boilerplate you end up having to write to get drivers going.
Draft patch written, and posting to the list soon...
g.
^ permalink raw reply
* [PATCH V2 2/2] ARM: SAMSUNG: Cleanup resources by using macro
From: Kyungmin Park @ 2011-10-04 23:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201110041726.03056.arnd@arndb.de>
On Wed, Oct 5, 2011 at 12:26 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 04 October 2011, Kukjin Kim wrote:
>> > I think the string concatenation really just obfuscates the code, and
>> > it does not actually save much at all. When you replace
>> >
>> > + ? ? ? [0] = SAMSUNG_RES_MEM(S3C, WDT, SZ_1K),
>> > + ? ? ? [1] = SAMSUNG_RES_IRQ(WDT),
>> >
>> > with
>> >
>> > + ? ? ? [0] = DEFINE_RES_MEM(S3C_PA_WDT, SZ_1K),
>> > + ? ? ? [1] = DEFINE_RES_IRQ(IRQ_WDT),
>> >
>> > you need practically no extra space, but you gain the advantages that
>> >
>> > * Someone using grep for DEFINE_RES_MEM finds all memory resources without
>> > ? having to look up what your macros do an where they are used.
>> > * Someone using grep to look for S3C_PA_WDT finds the place where it is
>> used.
>> > * Someone reading the resource definition immediately knows what the
>> > ? macro does if familiar with other platforms using that macro.
>>
>> Yes, right. But I'm preparing to reduce the 'soc' part to consolidate some
>> duplicated resources and platform data after this and the new SAMSUNG_RES
>> macro will be used.
There are tools for source browsing e.g., ctags, cscope, grep, git
grep and so on.
If you create new SAMSUNG_RES, these tools can't find macro and
symbols properly.
Please use the existing macros for own purpose.
Thank you,
Kyungmin Park
>
> Hmm, can't you instead change the names of these constants to be
> always the same? That would let you use the regular DEFINE_RES_*
> definitions without having to introduce your own.
>
> ? ? ? ?Arnd
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [RFC PATCH v3] drivercore: Add driver probe deferral mechanism
From: Grant Likely @ 2011-10-04 23:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111004183516.GB8021@manju-desktop>
On Wed, Oct 05, 2011 at 12:05:16AM +0530, G, Manjunath Kondaiah wrote:
> On Tue, Oct 04, 2011 at 09:58:10AM -0600, Grant Likely wrote:
> > On Tue, Oct 4, 2011 at 8:51 AM, G, Manjunath Kondaiah <manjugk@ti.com> wrote:
> > > On Thu, Sep 22, 2011 at 12:51:23PM -0600, Grant Likely wrote:
> > >> Hi Manjunath,
> > >>
> > >> Here's the current state of the patch. ?The major think that needs to
> > >> be done is to convert it to use a separate workqueue as described in
> > >> the TODO above. ?It also needs some users adapted to it. ?One of the
> > >> gpio drivers would work; preferably one of the newer drivers that
> > >> doesn't have a lot of drivers depending on the early_initcall()
> > >> behaviour yet.
> > >
> > > I have tested this patch on omap3 beagle board by making:
> > > 1. omap-gpio driver init as late_initcall instead of postcore_initcall
> > > 2. mmc driver probe will request gpio through gpio_request and gpio driver
> > > returns -EDEFER_PROBE which in turn makes mmc driver to request deferral probe.
> > > 3. When deferral probe gets activated, it scans driver entries and it will not
> > > find any match for mmc driver probe.
> >
> > Looks like drivers/mmc/host/omap.c is using platform_driver_probe()
> > instead of platform_driver_register(). Add the probe hook to the
> > platform_driver structure and change it to call
> > platform_driver_register() and it should work. Don't forget to change
> > mmc_omap_probe from __init to __devinit.
>
> Yes. After changing it into platform_driver_register, I can see mmc probe is
> getting completed from deferred probe list. But, MMC upper layer will check
> probe and it waits for ever since probe_count is not getting incremented.
>
> Log:
>
> [ 1.807830] platform omap_hsmmc.0: Driver omap_hsmmc requests probe deferral
>
> ...
>
> [ 1.948760] omap_device: omap_gpio.0: new worst case activate latency 0:30517
> [ 1.959259] OMAP GPIO hardware version 2.5
>
> ...
>
> [ 2.000488] platform omap_hsmmc.0: Retrying from deferred list
> [ 2.008026] omap_device: omap_hsmmc.0: new worst case activate latency 0:244140
> [ 2.020080] input: gpio-keys as /devices/platform/gpio-keys/input/input1
> [ 2.035827] omap_hsmmc omap_hsmmc.0: Probe success...
> [ 2.042083] twl_rtc twl_rtc: setting system clock to 2000-01-01 01:06:35 UTC
> (946688795)
> [ 2.056030] Waiting for root device /dev/mmcblk0p2...
> [ 2.061492] driver_probe_done: probe_count = 0
> [ 2.168518] driver_probe_done: probe_count = 0
> [ 2.277832] driver_probe_done: probe_count = 0
> [ 2.387207] driver_probe_done: probe_count = 0
> [ 2.496582] driver_probe_done: probe_count = 0
>
> Waits for ever in init/do_mount.c:
> if ((ROOT_DEV == 0) && root_wait) {
> printk(KERN_INFO "Waiting for root device %s...\n",
> saved_root_name);
> while (driver_probe_done() != 0 ||
> (ROOT_DEV = name_to_dev_t(saved_root_name)) == 0)
> msleep(100);
> async_synchronize_full();
> }
Okay, it looks like the driver deferral workqueue needs to get kicked
off before the kernel starts waiting for the root filesystem. Check
the initcall level that is being used by do_mount, and make sure the
deferred probe starts before that...
Hmmm.... wait, that doesn't make sense because the probe is still
successful. What triggers the exit conditions in that while loop?
How would it be different from when the driver can probe successfully
without deferral?
g.
>
> -Manjunath
^ permalink raw reply
* [PATCH 1/3] irq: support domains with non-zero hwirq base
From: Grant Likely @ 2011-10-04 23:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317410880-24828-2-git-send-email-robherring2@gmail.com>
On Fri, Sep 30, 2011 at 02:27:58PM -0500, Rob Herring wrote:
> From: Rob Herring <rob.herring@calxeda.com>
>
> Interrupt controllers can have non-zero starting value for h/w irq numbers.
> Adding support in irq_domain allows the domain hwirq numbering to match
> the interrupt controllers' numbering.
>
> As this makes looping over irqs for a domain more complicated, add loop
> iterators to iterate over all hwirqs and irqs for a domain.
>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
> ---
> include/linux/irqdomain.h | 16 +++++++++++++++-
> kernel/irq/irqdomain.c | 12 ++++++------
> 2 files changed, 21 insertions(+), 7 deletions(-)
>
> diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
> index 3ad553e..c0026b6 100644
> --- a/include/linux/irqdomain.h
> +++ b/include/linux/irqdomain.h
> @@ -47,6 +47,7 @@ struct irq_domain_ops {
> * of the irq_domain is responsible for allocating the array of
> * irq_desc structures.
> * @nr_irq: Number of irqs managed by the irq domain
> + * @hwirq_base: Starting number for hwirqs managed by the irq domain
> * @ops: pointer to irq_domain methods
> * @priv: private data pointer for use by owner. Not touched by irq_domain
> * core code.
> @@ -57,6 +58,7 @@ struct irq_domain {
> struct list_head list;
> unsigned int irq_base;
> unsigned int nr_irq;
> + unsigned int hwirq_base;
> const struct irq_domain_ops *ops;
> void *priv;
> struct device_node *of_node;
> @@ -72,9 +74,21 @@ struct irq_domain {
> static inline unsigned int irq_domain_to_irq(struct irq_domain *d,
> unsigned long hwirq)
> {
> - return d->ops->to_irq ? d->ops->to_irq(d, hwirq) : d->irq_base + hwirq;
> + if (d->ops->to_irq)
> + return d->ops->to_irq(d, hwirq);
> + if (hwirq < d->hwirq_base)
> + return NO_IRQ;
NO_IRQ is probably not available on x86. Also, if this condition
is hit then something is definitely wrong. You should WARN() and
return 0.
Otherwise looks good and you can add my a-b:
Acked-by: Grant Likely <grant.likely@secretlab.ca>
^ permalink raw reply
* [PATCH 2/3] ARM: gic: add irq_domain support
From: Grant Likely @ 2011-10-04 23:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317410880-24828-3-git-send-email-robherring2@gmail.com>
On Fri, Sep 30, 2011 at 02:27:59PM -0500, Rob Herring wrote:
> From: Rob Herring <rob.herring@calxeda.com>
>
> Convert the gic interrupt controller to use irq domains in preparation
> for device-tree binding and MULTI_IRQ. This allows for translation between
> GIC interrupt IDs and Linux irq numbers.
>
> The meaning of irq_offset has changed. It now is just the number of skipped
> GIC interrupt IDs for the controller. It will be 16 for primary GIC and 32
> for secondary GICs.
>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
> ---
> arch/arm/common/Kconfig | 1 +
> arch/arm/common/gic.c | 81 ++++++++++++++++++++---------------
> arch/arm/include/asm/hardware/gic.h | 4 +-
> 3 files changed, 51 insertions(+), 35 deletions(-)
>
> diff --git a/arch/arm/common/Kconfig b/arch/arm/common/Kconfig
> index 4b71766..74df9ca 100644
> --- a/arch/arm/common/Kconfig
> +++ b/arch/arm/common/Kconfig
> @@ -1,4 +1,5 @@
> config ARM_GIC
> + select IRQ_DOMAIN
> bool
>
> config ARM_VIC
> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
> index 8b5be72..6fbe1db 100644
> --- a/arch/arm/common/gic.c
> +++ b/arch/arm/common/gic.c
> @@ -29,6 +29,7 @@
> #include <linux/cpu_pm.h>
> #include <linux/cpumask.h>
> #include <linux/io.h>
> +#include <linux/irqdomain.h>
>
> #include <asm/irq.h>
> #include <asm/mach/irq.h>
> @@ -72,8 +73,7 @@ static inline void __iomem *gic_cpu_base(struct irq_data *d)
>
> static inline unsigned int gic_irq(struct irq_data *d)
> {
> - struct gic_chip_data *gic_data = irq_data_get_irq_chip_data(d);
> - return d->irq - gic_data->irq_offset;
> + return d->hwirq;
> }
Nit: Personally, I'd just drop gic_irq() entirely and reference
d->hwirq directly. However, it isn't enough to withhold my a-b.
Acked-by: Grant Likely <grant.likely@secretlab.ca>
>
> /*
> @@ -81,7 +81,7 @@ static inline unsigned int gic_irq(struct irq_data *d)
> */
> static void gic_mask_irq(struct irq_data *d)
> {
> - u32 mask = 1 << (d->irq % 32);
> + u32 mask = 1 << (gic_irq(d) % 32);
>
> spin_lock(&irq_controller_lock);
> writel_relaxed(mask, gic_dist_base(d) + GIC_DIST_ENABLE_CLEAR + (gic_irq(d) / 32) * 4);
> @@ -92,7 +92,7 @@ static void gic_mask_irq(struct irq_data *d)
>
> static void gic_unmask_irq(struct irq_data *d)
> {
> - u32 mask = 1 << (d->irq % 32);
> + u32 mask = 1 << (gic_irq(d) % 32);
>
> spin_lock(&irq_controller_lock);
> if (gic_arch_extn.irq_unmask)
> @@ -173,7 +173,7 @@ static int gic_set_affinity(struct irq_data *d, const struct cpumask *mask_val,
> bool force)
> {
> void __iomem *reg = gic_dist_base(d) + GIC_DIST_TARGET + (gic_irq(d) & ~3);
> - unsigned int shift = (d->irq % 4) * 8;
> + unsigned int shift = (gic_irq(d) % 4) * 8;
> unsigned int cpu = cpumask_any_and(mask_val, cpu_online_mask);
> u32 val, mask, bit;
>
> @@ -224,7 +224,7 @@ static void gic_handle_cascade_irq(unsigned int irq, struct irq_desc *desc)
> if (gic_irq == 1023)
> goto out;
>
> - cascade_irq = gic_irq + chip_data->irq_offset;
> + cascade_irq = irq_domain_to_irq(&chip_data->domain, gic_irq);
> if (unlikely(gic_irq < 32 || gic_irq > 1020 || cascade_irq >= NR_IRQS))
> do_bad_IRQ(cascade_irq, desc);
> else
> @@ -256,10 +256,11 @@ void __init gic_cascade_irq(unsigned int gic_nr, unsigned int irq)
> irq_set_chained_handler(irq, gic_handle_cascade_irq);
> }
>
> -static void __init gic_dist_init(struct gic_chip_data *gic,
> - unsigned int irq_start)
> +static void __init gic_dist_init(struct gic_chip_data *gic)
> {
> - unsigned int gic_irqs, irq_limit, i;
> + unsigned int gic_irqs = gic->gic_irqs;
> + struct irq_domain *domain = &gic->domain;
> + unsigned int i, irq;
> u32 cpumask;
> void __iomem *base = gic->dist_base;
> u32 cpu = 0;
> @@ -275,17 +276,6 @@ static void __init gic_dist_init(struct gic_chip_data *gic,
> writel_relaxed(0, base + GIC_DIST_CTRL);
>
> /*
> - * Find out how many interrupts are supported.
> - * The GIC only supports up to 1020 interrupt sources.
> - */
> - gic_irqs = readl_relaxed(base + GIC_DIST_CTR) & 0x1f;
> - gic_irqs = (gic_irqs + 1) * 32;
> - if (gic_irqs > 1020)
> - gic_irqs = 1020;
> -
> - gic->gic_irqs = gic_irqs;
> -
> - /*
> * Set all global interrupts to be level triggered, active low.
> */
> for (i = 32; i < gic_irqs; i += 16)
> @@ -311,19 +301,12 @@ static void __init gic_dist_init(struct gic_chip_data *gic,
> writel_relaxed(0xffffffff, base + GIC_DIST_ENABLE_CLEAR + i * 4 / 32);
>
> /*
> - * Limit number of interrupts registered to the platform maximum
> - */
> - irq_limit = gic->irq_offset + gic_irqs;
> - if (WARN_ON(irq_limit > NR_IRQS))
> - irq_limit = NR_IRQS;
> -
> - /*
> * Setup the Linux IRQ subsystem.
> */
> - for (i = irq_start; i < irq_limit; i++) {
> - irq_set_chip_and_handler(i, &gic_chip, handle_fasteoi_irq);
> - irq_set_chip_data(i, gic);
> - set_irq_flags(i, IRQF_VALID | IRQF_PROBE);
> + irq_domain_for_each_irq(domain, i, irq) {
> + irq_set_chip_and_handler(irq, &gic_chip, handle_fasteoi_irq);
> + irq_set_chip_data(irq, gic);
> + set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
> }
>
> writel_relaxed(1, base + GIC_DIST_CTRL);
> @@ -535,23 +518,53 @@ static void __init gic_pm_init(struct gic_chip_data *gic)
> }
> #endif
>
> +const struct irq_domain_ops gic_irq_domain_ops = {
> +};
> +
> void __init gic_init(unsigned int gic_nr, unsigned int irq_start,
> void __iomem *dist_base, void __iomem *cpu_base)
> {
> struct gic_chip_data *gic;
> + struct irq_domain *domain;
> + int gic_irqs;
>
> BUG_ON(gic_nr >= MAX_GIC_NR);
>
> gic = &gic_data[gic_nr];
> + domain = &gic->domain;
> gic->dist_base = dist_base;
> gic->cpu_base = cpu_base;
> - gic->irq_offset = (irq_start - 1) & ~31;
>
> - if (gic_nr == 0)
> + /*
> + * For primary GICs, skip over SGIs.
> + * For secondary GICs, skip over PPIs, too.
> + */
> + if (gic_nr == 0) {
> gic_cpu_base_addr = cpu_base;
> + domain->hwirq_base = 16;
> + irq_start = (irq_start & ~31) + 16;
> + } else
> + domain->hwirq_base = 32;
> +
> + /*
> + * Find out how many interrupts are supported.
> + * The GIC only supports up to 1020 interrupt sources.
> + */
> + gic_irqs = readl_relaxed(dist_base + GIC_DIST_CTR) & 0x1f;
> + gic_irqs = (gic_irqs + 1) * 32;
> + if (gic_irqs > 1020)
> + gic_irqs = 1020;
> + gic->gic_irqs = gic_irqs;
> +
> + domain->nr_irq = gic_irqs - domain->hwirq_base;
> + domain->irq_base = irq_alloc_descs(-1, irq_start, domain->nr_irq,
> + numa_node_id());
> + domain->priv = gic;
> + domain->ops = &gic_irq_domain_ops;
> + irq_domain_add(domain);
>
> gic_chip.flags |= gic_arch_extn.flags;
> - gic_dist_init(gic, irq_start);
> + gic_dist_init(gic);
> gic_cpu_init(gic);
> gic_pm_init(gic);
> }
> diff --git a/arch/arm/include/asm/hardware/gic.h b/arch/arm/include/asm/hardware/gic.h
> index c562705..ade84a4 100644
> --- a/arch/arm/include/asm/hardware/gic.h
> +++ b/arch/arm/include/asm/hardware/gic.h
> @@ -33,6 +33,8 @@
> #define GIC_DIST_SOFTINT 0xf00
>
> #ifndef __ASSEMBLY__
> +#include <linux/irqdomain.h>
> +
> extern void __iomem *gic_cpu_base_addr;
> extern struct irq_chip gic_arch_extn;
>
> @@ -43,7 +45,6 @@ void gic_raise_softirq(const struct cpumask *mask, unsigned int irq);
> void gic_enable_ppi(unsigned int);
>
> struct gic_chip_data {
> - unsigned int irq_offset;
> void __iomem *dist_base;
> void __iomem *cpu_base;
> #ifdef CONFIG_CPU_PM
> @@ -53,6 +54,7 @@ struct gic_chip_data {
> u32 __percpu *saved_ppi_enable;
> u32 __percpu *saved_ppi_conf;
> #endif
> + struct irq_domain domain;
> unsigned int gic_irqs;
> };
> #endif
> --
> 1.7.5.4
>
^ permalink raw reply
* [PATCH 3/3] ARM: gic: add OF based initialization
From: Grant Likely @ 2011-10-04 23:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317410880-24828-4-git-send-email-robherring2@gmail.com>
On Fri, Sep 30, 2011 at 02:28:00PM -0500, Rob Herring wrote:
> From: Rob Herring <rob.herring@calxeda.com>
>
> This adds ARM gic interrupt controller initialization using device tree
> data.
>
> The initialization function is intended to be called by of_irq_init
> function like this:
>
> const static struct of_device_id irq_match[] = {
> { .compatible = "arm,cortex-a9-gic", .data = gic_of_init, },
> {}
> };
>
> static void __init init_irqs(void)
> {
> of_irq_init(irq_match);
> }
>
> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
I think this series is pretty much ready to be merged other than the
comment on patch 1. It should go through either rmk's patch system or
the arm-soc tree, but you'll need an ack from tglx first.
g.
> ---
> Documentation/devicetree/bindings/arm/gic.txt | 55 ++++++++++++++++++++++
> arch/arm/common/gic.c | 61 +++++++++++++++++++++++++
> arch/arm/include/asm/hardware/gic.h | 1 +
> 3 files changed, 117 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
> new file mode 100644
> index 0000000..52916b4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/gic.txt
> @@ -0,0 +1,55 @@
> +* ARM Generic Interrupt Controller
> +
> +ARM SMP cores are often associated with a GIC, providing per processor
> +interrupts (PPI), shared processor interrupts (SPI) and software
> +generated interrupts (SGI).
> +
> +Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
> +Secondary GICs are cascaded into the upward interrupt controller and do not
> +have PPIs or SGIs.
> +
> +Main node required properties:
> +
> +- compatible : should be one of:
> + "arm,cortex-a9-gic"
> + "arm,arm11mp-gic"
> +- interrupt-controller : Identifies the node as an interrupt controller
> +- #interrupt-cells : Specifies the number of cells needed to encode an
> + interrupt source. The type shall be a <u32> and the value shall be 3.
> +
> + The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
> + interrupts.
> +
> + The 2nd cell contains the interrupt number for the interrupt type.
> + SPI interrupts are in the range [0-987]. PPI interrupts are in the
> + range [0-15].
> +
> + The 3rd cell is the flags, encoded as follows:
> + bits[3:0] trigger type and level flags.
> + 1 = low-to-high edge triggered
> + 2 = high-to-low edge triggered
> + 4 = active high level-sensitive
> + 8 = active low level-sensitive
> + bits[15:8] PPI interrupt cpu mask. Each bit corresponds to each of
> + the 8 possible cpus attached to the GIC. A bit set to '1' indicated
> + the interrupt is wired to that CPU. Only valid for PPI interrupts.
> +
> +- reg : Specifies base physical address(s) and size of the GIC registers. The
> + first region is the GIC distributor register base and size. The 2nd region is
> + the GIC cpu interface register base and size.
> +
> +Optional
> +- interrupts : Interrupt source of the parent interrupt controller. Only
> + present on secondary GICs.
> +
> +Example:
> +
> + intc: interrupt-controller at fff11000 {
> + compatible = "arm,cortex-a9-gic";
> + #interrupt-cells = <3>;
> + #address-cells = <1>;
> + interrupt-controller;
> + reg = <0xfff11000 0x1000>,
> + <0xfff10100 0x100>;
> + };
> +
> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
> index 6fbe1db..3e67970 100644
> --- a/arch/arm/common/gic.c
> +++ b/arch/arm/common/gic.c
> @@ -29,6 +29,9 @@
> #include <linux/cpu_pm.h>
> #include <linux/cpumask.h>
> #include <linux/io.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> #include <linux/irqdomain.h>
>
> #include <asm/irq.h>
> @@ -518,7 +521,33 @@ static void __init gic_pm_init(struct gic_chip_data *gic)
> }
> #endif
>
> +#ifdef CONFIG_OF
> +static int gic_irq_domain_dt_translate(struct irq_domain *d,
> + struct device_node *controller,
> + const u32 *intspec, unsigned int intsize,
> + unsigned long *out_hwirq, unsigned int *out_type)
> +{
> + if (d->of_node != controller)
> + return -EINVAL;
> + if (intsize < 3)
> + return -EINVAL;
> +
> + /* Get the interrupt number and add 16 to skip over SGIs */
> + *out_hwirq = intspec[1] + 16;
> +
> + /* For SPIs, we need to add 16 more to get the GIC irq ID number */
> + if (!intspec[0])
> + *out_hwirq += 16;
> +
> + *out_type = intspec[2] & IRQ_TYPE_SENSE_MASK;
> + return 0;
> +}
> +#endif
> +
> const struct irq_domain_ops gic_irq_domain_ops = {
> +#ifdef CONFIG_OF
> + .dt_translate = gic_irq_domain_dt_translate,
> +#endif
> };
>
> void __init gic_init(unsigned int gic_nr, unsigned int irq_start,
> @@ -606,3 +635,35 @@ void gic_raise_softirq(const struct cpumask *mask, unsigned int irq)
> writel_relaxed(map << 16 | irq, gic_data[0].dist_base + GIC_DIST_SOFTINT);
> }
> #endif
> +
> +#ifdef CONFIG_OF
> +static int gic_cnt __initdata = 0;
> +
> +int __init gic_of_init(struct device_node *node, struct device_node *parent)
> +{
> + void __iomem *cpu_base;
> + void __iomem *dist_base;
> + int irq;
> + struct irq_domain *domain = &gic_data[gic_cnt].domain;
> +
> + if (WARN_ON(!node))
> + return -ENODEV;
> +
> + dist_base = of_iomap(node, 0);
> + WARN(!dist_base, "unable to map gic dist registers\n");
> +
> + cpu_base = of_iomap(node, 1);
> + WARN(!cpu_base, "unable to map gic cpu registers\n");
> +
> + domain->of_node = of_node_get(node);
> +
> + gic_init(gic_cnt, 16, dist_base, cpu_base);
> +
> + if (parent) {
> + irq = irq_of_parse_and_map(node, 0);
> + gic_cascade_irq(gic_cnt, irq);
> + }
> + gic_cnt++;
> + return 0;
> +}
> +#endif
> diff --git a/arch/arm/include/asm/hardware/gic.h b/arch/arm/include/asm/hardware/gic.h
> index ade84a4..1a776a1 100644
> --- a/arch/arm/include/asm/hardware/gic.h
> +++ b/arch/arm/include/asm/hardware/gic.h
> @@ -39,6 +39,7 @@ extern void __iomem *gic_cpu_base_addr;
> extern struct irq_chip gic_arch_extn;
>
> void gic_init(unsigned int, unsigned int, void __iomem *, void __iomem *);
> +int gic_of_init(struct device_node *node, struct device_node *parent);
> void gic_secondary_init(unsigned int);
> void gic_cascade_irq(unsigned int gic_nr, unsigned int irq);
> void gic_raise_softirq(const struct cpumask *mask, unsigned int irq);
> --
> 1.7.5.4
>
^ permalink raw reply
* [PATCH 2/9] regulator: helper routine to extract regulator_init_data
From: Grant Likely @ 2011-10-04 23:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111004230127.GB32102@n2100.arm.linux.org.uk>
On Wed, Oct 05, 2011 at 12:01:27AM +0100, Russell King - ARM Linux wrote:
> On Tue, Sep 27, 2011 at 01:10:04PM +0100, Mark Brown wrote:
> > On Tue, Sep 27, 2011 at 03:42:45PM +0530, Rajendra Nayak wrote:
> >
> > > + init_data = devm_kzalloc(dev, sizeof(struct regulator_init_data),
> > > + GFP_KERNEL);
> > > + if (!init_data)
> > > + return NULL; /* Out of memory? */
> >
> > This means that the init data will be kept around for the entire
> > lifetime of the device rather than being discarded.
>
> May I remind you that devm_* lifetime expires whenever the associated
> driver is unbound, which can be much shorter than the lifetime of the
> struct device.
>
> It expires when any of the following occurs:
> 1. userspace asks the associated driver to be unbound
> 2. the driver is removed
> 3. any driver probe for this struct device fails
> 4. the struct device is unregistered.
>
> So: don't use devm_* for anything other than stuff inside a driver being
> associated with the struct device itself. Other uses are a bug waiting
> to happen.
Yes, Russell is right. There were a number of places where I
suggested using devm_* in entirely the wrong places. Double check
anyplace where you've added devm_ calls.
g.
^ permalink raw reply
* Please help with the OMAP static mapping mess
From: Tony Lindgren @ 2011-10-05 0:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1110041900590.9106@xanadu.home>
* Nicolas Pitre <nico@fluxnic.net> [111004 15:47]:
> On Tue, 4 Oct 2011, Russell King - ARM Linux wrote:
>
> > On Tue, Oct 04, 2011 at 05:10:36PM -0400, Nicolas Pitre wrote:
> > > Which makes me think... with all those architectures intercepting
> > > ioremap calls in order to provide an equivalent static mapping address,
> > > they already get an unexpected domain given that static mappings are
> > > mostly DOMAIN_IO and not DOMAIN_KERNEL as would result from an non
> > > intercepted ioremap call.
> >
> > That's a necessary evil - otherwise we have to separate out the
> > ioremap from vmalloc.
> >
> > Incidentally, how are you dealing with the problem of a static mapping
> > setting up a L1 page table entry for DOMAIN_IO, and then a vmalloc
> > request coming in, overlapping that L1 page table?
> >
> > If this memory then gets accessed with get_user() with set_fs(get_ds()),
> > the kernel will oops as we don't switch DOMAIN_IO memory on set_fs().
> > (I don't know if this happens in practice, but there's nothing to say
> > that it's illegal to do this.)
>
> I suppose that didn't happen so far. Granted, moving the ioremap
> optimization into core code for all machines will increase the
> possibility for this to happen, even if still small.
>
> With CPU_USE_DOMAINS not set, set_fs() is a no-op anyway, besides
> addr_limit that is.
>
> Is there a strong benefit in having static mappings being DOMAIN_IO
> instead of DOMAIN_KERNEL?
In any case, I suggest we add the following __arm_ioremap_exec patch
and then sort out issues with it as they show up.
This allows further work on the common SRAM genalloc patches and generic
map_io patches.
Nico, I already have a series converting omap2+ to use the the patch
below, and it seems to be working just fine for SRAM. I'll post that
series separately shortly. Maybe take a look and see if that allows
you to do the generic map_io changes?
I still also need to convert omap1 too, but will do that a bit later.
Regards,
Tony
From: Tony Lindgren <tony@atomide.com>
Date: Tue, 4 Oct 2011 17:22:16 -0700
Subject: [PATCH] ARM: Add __arm_ioremap_exec for mapping external memory as MT_MEMORY
This allows mapping external memory such as SRAM for use.
This is needed for some small chunks of code, such as reprogramming
SDRAM memory source clocks that can't be executed in SDRAM. Other
use cases include some PM related code.
Signed-off-by: Tony Lindgren <tony@atomide.com>
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -80,6 +80,7 @@ extern void __iomem *__arm_ioremap_caller(unsigned long, size_t, unsigned int,
extern void __iomem *__arm_ioremap_pfn(unsigned long, unsigned long, size_t, unsigned int);
extern void __iomem *__arm_ioremap(unsigned long, size_t, unsigned int);
+extern void __iomem *__arm_ioremap_exec(unsigned long, size_t, int cached);
extern void __iounmap(volatile void __iomem *addr);
/*
--- a/arch/arm/mm/ioremap.c
+++ b/arch/arm/mm/ioremap.c
@@ -289,6 +289,28 @@ __arm_ioremap(unsigned long phys_addr, size_t size, unsigned int mtype)
}
EXPORT_SYMBOL(__arm_ioremap);
+/*
+ * Remap an arbitrary physical address space into the kernel virtual
+ * address space as memory. Needed when the kernel wants to execute
+ * code in external memory. This is needed for reprogramming source
+ * clocks that would affect normal memory for example. Please see
+ * CONFIG_GENERIC_ALLOCATOR for allocating external memory.
+ */
+void __iomem *
+__arm_ioremap_exec(unsigned long phys_addr, size_t size, int cached)
+{
+ unsigned int mtype;
+
+ if (cached)
+ mtype = MT_MEMORY;
+ else
+ mtype = MT_MEMORY_NONCACHED;
+
+ return __arm_ioremap_caller(phys_addr, size, mtype,
+ __builtin_return_address(0));
+}
+EXPORT_SYMBOL(__arm_ioremap_exec);
+
void __iounmap(volatile void __iomem *io_addr)
{
void *addr = (void *)(PAGE_MASK & (unsigned long)io_addr);
^ 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