* [PATCH 3/3] ARM: gic: add OF based initialization
From: Jamie Iles @ 2011-09-26 22:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316550244-3655-4-git-send-email-robherring2@gmail.com>
Hi Rob,
Apologies for the noise! One minor comment below.
Jamie
On Tue, Sep 20, 2011 at 03:24:04PM -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>
> ---
[...]
> diff --git a/arch/arm/include/asm/hardware/gic.h b/arch/arm/include/asm/hardware/gic.h
> index 435d3f8..2862d0e 100644
> --- a/arch/arm/include/asm/hardware/gic.h
> +++ b/arch/arm/include/asm/hardware/gic.h
> @@ -33,10 +33,21 @@
> #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;
>
> void gic_init(unsigned int, unsigned int, void __iomem *, void __iomem *);
> +#ifdef CONFIG_OF
> +int gic_of_init(struct device_node *node, struct device_node *parent);
> +#else
> +static inline void gic_of_init(struct device_node *node,
> + struct device_node *parent)
This should return int?
> +{
> + return -ENODEV;
> +}
> +#endif
^ permalink raw reply
* [GIT PULL] I2C: OMAP: misc. cleanup for v3.2
From: Kevin Hilman @ 2011-09-26 22:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E669F36.2070008@ti.com>
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?
>
> Since master.kernel.org is still down, I pushed a (backup) copy of these
> branches to my gitorious repo[1]. It should pull cleanly into what
> you've already pulled since this branch is based on my for_3.2/i2c-fixes
> which you've already pulled.
>
> Thanks,
>
> Kevin
>
>
> [1] git://gitorious.org/khilman/linux-omap-pm.git
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2 0/6] OMAP: omap_device cleanup before device-tree integration
From: Kevin Hilman @ 2011-09-26 22:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1314973520-3585-1-git-send-email-b-cousson@ti.com>
Hi Benoit,
Benoit Cousson <b-cousson@ti.com> writes:
> Hi Kevin,
>
> Here are a couple of cleanups on top of your (old) for_3.2/omap_device branch
> rebased on top of -rc4 + Tony's cleanup patches.
>
> Since I cannot pull your latest version, I repost the whole series.
I have a (temporary) tree at git://github.com/khilman/linux-omap-pm.git.
Please base the updated series on my for_3.2/omap_device branch there.
Other than the minor API name, this series looks good and I'll add
to my omap_device queue for v3.2.
Thanks,
Kevin
> patches are available here:
> git://gitorious.org/omap-pm/linux.git for_3.2/1_omap_device_cleanup
>
> It is tested on OMAP4 SDP, Panda and Beagle-xM (Yeah, I found one...).
>
> Regards,
> Benoit
>
>
> Changes since v1: http://www.spinics.net/lists/linux-omap/msg55801.html
> - Update the 2 patches from Nishanth based on Kevin's comment and merge
> them into one patch.
>
>
> Benoit Cousson (5):
> OMAP3: beagle-board: Use the omap_hwmod_name_get_dev API
> OMAP2+: pm: Use hwmod name instead of dev pointer
> OMAP2+: pm: Remove static devices variable for mpu, dsp, iva and l3 PM
> OMAP: omap_device: Create a default omap_device_pm_latency
> OMAP2+: devices: Remove all omap_device_pm_latency structures
>
> Nishanth Menon (1):
> OMAP: omap_device: Add omap_hwmod_name_get_dev
>
> arch/arm/mach-omap2/board-omap3beagle.c | 4 +-
> arch/arm/mach-omap2/devices.c | 46 ++---------------
> arch/arm/mach-omap2/display.c | 11 +----
> arch/arm/mach-omap2/dma.c | 11 +----
> arch/arm/mach-omap2/gpio.c | 12 +----
> arch/arm/mach-omap2/hsmmc.c | 18 +------
> arch/arm/mach-omap2/hwspinlock.c | 12 +----
> arch/arm/mach-omap2/mcbsp.c | 11 +----
> arch/arm/mach-omap2/pm.c | 69 ++++++++-----------------
> arch/arm/mach-omap2/serial.c | 25 +---------
> arch/arm/mach-omap2/sr_device.c | 11 +----
> arch/arm/mach-omap2/usb-musb.c | 11 +----
> arch/arm/plat-omap/i2c.c | 10 +---
> arch/arm/plat-omap/include/plat/omap_device.h | 10 ++++
> arch/arm/plat-omap/omap_device.c | 49 +++++++++++++++++-
> 15 files changed, 95 insertions(+), 215 deletions(-)
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2 4/7] clk: Add simple gated clock
From: Turquette, Mike @ 2011-09-26 22:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110926193733.GC9194@gallagher>
On Mon, Sep 26, 2011 at 12:37 PM, Jamie Iles <jamie@jamieiles.com> wrote:
> On Mon, Sep 26, 2011 at 02:10:32PM -0500, Rob Herring wrote:
>> On 09/26/2011 01:40 PM, Jamie Iles wrote:
>> > On Mon, Sep 26, 2011 at 01:33:08PM -0500, Rob Herring wrote:
>> >>> +static void clk_gate_set_bit(struct clk_hw *clk)
>> >>> +{
>> >>> + struct clk_gate *gate = to_clk_gate(clk);
>> >>> + u32 reg;
>> >>> +
>> >>> + reg = __raw_readl(gate->reg);
>> >>> + reg |= BIT(gate->bit_idx);
>> >>> + __raw_writel(reg, gate->reg);
>> >>
>> >> Don't these read-mod-writes need a spinlock around it?
>> >>
>> >> It's possible to have an enable bits and dividers in the same register.
>> >> If you did a set_rate and while doing an enable/disable, there would be
>> >> a problem. Also, it may be 2 different clocks in the same register, so
>> >> the spinlock needs to be shared and not per clock.
>> >
>> > Well the prepare lock will be held here and I believe that would be
>> > sufficient.
>>
>> No, the enable spinlock is protecting enable/disable. But set_rate is
>> protected by the prepare mutex. So you clearly don't need locking if you
>> have a register of only 1 bit enables. If you have a register accessed
>> by both enable/disable and prepare/unprepare/set_rate, then you need
>> some protection.
>
> OK fair point, but I would guess that if you had a clock like this then
> you probably wouldn't use this simple gated clock would you? ?(speaking
> from my world where we have quite simple clocks ;-))
I think it is a safe assumption that if a register controls both
enable/disable and some programmable divider then,
1) those controls are probably for the same clock
2) that clock won't be using the cookie-cutter gated-clock
implementation anyways
Rob, do you feel these assumptions are OK and locking can remain the
same in this patch?
Regards,
Mike
> Jamie
>
^ permalink raw reply
* Pull request: removal of most instances of mach/memory.h
From: Russell King - ARM Linux @ 2011-09-26 22:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1109261514330.2718@xanadu.home>
On Mon, Sep 26, 2011 at 04:00:11PM -0400, Nicolas Pitre wrote:
> On Mon, 26 Sep 2011, Russell King - ARM Linux wrote:
>
> > On Mon, Sep 26, 2011 at 10:33:28AM -0400, Nicolas Pitre wrote:
> > > ARM: mach-ep93xx: remove mach/memory.h and Kconfig selection of SDRAM bank
> >
> > Are you planning to totally kill off ZBOOT_ROM too? Because removing
> > the zreladdr stuff is doing exactly that.
>
> It looks like ZBOOT_ROM is not used on that platform at all. However,
> the ability to have a single defconfig and binary for the whole platform
> is something that the mach-ep93xx maintainers are looking for. Having
> ZBOOT_ROM depend on and use CONFIG_PHYS_OFFSET would probably makes
> sense eventually.
You miss the point. Removing zreladdr actively _prevents_ anyone from
then choosing to build a kernel with ZBOOT_ROM enabled targetted for one
platform if that's what they want, because the decompressor then loses
the information it needs to properly locate the kernel.
> > This also gives additional merge conflicts elsewhere, and while git
> > rerere makes some of them easy, the quantity is going to be a right
> > pain to deal with on a repeated basis.
>
> Again, I'm perfectly willing to use a different base for this series and
> fix the conflicts myself if you give me one.
That's difficult when there are a number of unstable branches involved.
^ permalink raw reply
* Pull request: removal of most instances of mach/memory.h
From: Russell King - ARM Linux @ 2011-09-26 22:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1109261606210.2718@xanadu.home>
On Mon, Sep 26, 2011 at 04:10:03PM -0400, Nicolas Pitre wrote:
> On Mon, 26 Sep 2011, Nicolas Pitre wrote:
>
> > On Mon, 26 Sep 2011, Russell King - ARM Linux wrote:
> >
> > > This also gives additional merge conflicts elsewhere, and while git
> > > rerere makes some of them easy, the quantity is going to be a right
> > > pain to deal with on a repeated basis.
> >
> > Again, I'm perfectly willing to use a different base for this series and
> > fix the conflicts myself if you give me one.
>
> Nevermind, I see that you merged it anyway.
>
> You may consider the rerere.autoupdate config option if you want Git to
> automatically pick the conflict resolution without you manually
> confirming them all the time.
rerere doesn't deal with modified/deleted conflicts though.
^ permalink raw reply
* [PATCH v3 0/2] OMAP: omap_device: Add a method to build an omap_device from a DT node
From: Kevin Hilman @ 2011-09-26 22:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316724745-24896-1-git-send-email-b-cousson@ti.com>
Hi Benoit,
Benoit Cousson <b-cousson@ti.com> writes:
> This is the updated version of the initial series that introduced a
> notifier in order to create an omap_device from a platform_device bound
> to DT node as suggested by Grant.
This series looks good to me.
Barring any final comments (Grant?), I'll be queueing this for 3.2 in my
omap_device queue on top of your previous cleanup series.
Kevin
^ permalink raw reply
* [RFC 2/5] ARM: OMAP: omap_device: add a method to set iommu private archdata
From: Kevin Hilman @ 2011-09-26 22:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316948337-7924-3-git-send-email-ohad@wizery.com>
Hi Ohad,
Ohad Ben-Cohen <ohad@wizery.com> writes:
> Make it possible to set an iommu private archdata before a newly-created
> omap device is registered.
>
> Binding iommu client devices with their respective iommu data this way
> is needed so the generic IOMMU API can later be used without employing
> any omap-specific IOMMU plumbing.
>
> This patch just crudely adds an omap_device_build_ss_ext() method which
> accepts an iommu private data, but we may actually want to do something
> more generic here: e.g., split the omap_device_build API to alloc+add
> methods, so users can just manipulate the device as needed before it is
> registered (very much like we can do with plain devices).
Yes indeed.
Benoit did just this in preparation for DT.
http://marc.info/?l=linux-omap&m=131672480111927&w=2
Will that meet your needs?
Kevin
^ permalink raw reply
* [PATCH v7 00/26] gpio/omap: driver cleanup and fixes
From: Kevin Hilman @ 2011-09-26 22:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAC83ZvLcq+N_LL4AD=r4hZxPeQtrAEvR7MzoANtNmQBNR7AqGw@mail.gmail.com>
"DebBarma, Tarun Kanti" <tarun.kanti@ti.com> writes:
> [...]
>>> - Added the debounce clock fix in the end.
>>
>> Thanks. ?Glad you found and fixed it.
>>
>> Rather than add this patch as a fix at the end, I prefer if the problem
>> is fixed in the original patches that added/created the problem.
> Sure. I will put the changes in respective patches.
Also, when you rebase, please be sure to add the Acked-by from Tony
to the various patches he ack'd.
Thanks,
Kevin
^ permalink raw reply
* Pull request: removal of most instances of mach/memory.h
From: Nicolas Pitre @ 2011-09-26 23:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110926223810.GA23680@n2100.arm.linux.org.uk>
On Mon, 26 Sep 2011, Russell King - ARM Linux wrote:
> On Mon, Sep 26, 2011 at 04:00:11PM -0400, Nicolas Pitre wrote:
> > On Mon, 26 Sep 2011, Russell King - ARM Linux wrote:
> >
> > > On Mon, Sep 26, 2011 at 10:33:28AM -0400, Nicolas Pitre wrote:
> > > > ARM: mach-ep93xx: remove mach/memory.h and Kconfig selection of SDRAM bank
> > >
> > > Are you planning to totally kill off ZBOOT_ROM too? Because removing
> > > the zreladdr stuff is doing exactly that.
> >
> > It looks like ZBOOT_ROM is not used on that platform at all. However,
> > the ability to have a single defconfig and binary for the whole platform
> > is something that the mach-ep93xx maintainers are looking for. Having
> > ZBOOT_ROM depend on and use CONFIG_PHYS_OFFSET would probably makes
> > sense eventually.
>
> You miss the point. Removing zreladdr actively _prevents_ anyone from
> then choosing to build a kernel with ZBOOT_ROM enabled targetted for one
> platform if that's what they want, because the decompressor then loses
> the information it needs to properly locate the kernel.
Sure. My point is that ZBOOT_ROM should eventually be coupled with
CONFIG_PHYS_OFFSET to derive the zreladdr value. Like for XIP_KERNEL,
there is no real point having ZBOOT_ROM when ARM_PATCH_PHYS_VIRT is set,
and when not set we have the equivalent zreladdr information elsewhere
already.
Nicolas
^ permalink raw reply
* Pull request: removal of most instances of mach/memory.h
From: Nicolas Pitre @ 2011-09-26 23:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110926223839.GB23680@n2100.arm.linux.org.uk>
On Mon, 26 Sep 2011, Russell King - ARM Linux wrote:
> On Mon, Sep 26, 2011 at 04:10:03PM -0400, Nicolas Pitre wrote:
> > On Mon, 26 Sep 2011, Nicolas Pitre wrote:
> >
> > > On Mon, 26 Sep 2011, Russell King - ARM Linux wrote:
> > >
> > > > This also gives additional merge conflicts elsewhere, and while git
> > > > rerere makes some of them easy, the quantity is going to be a right
> > > > pain to deal with on a repeated basis.
> > >
> > > Again, I'm perfectly willing to use a different base for this series and
> > > fix the conflicts myself if you give me one.
> >
> > Nevermind, I see that you merged it anyway.
> >
> > You may consider the rerere.autoupdate config option if you want Git to
> > automatically pick the conflict resolution without you manually
> > confirming them all the time.
>
> rerere doesn't deal with modified/deleted conflicts though.
True. That can be considered a limitation worth fixing.
Nicolas
^ permalink raw reply
* [PATCH v7 00/26] gpio/omap: driver cleanup and fixes
From: Kevin Hilman @ 2011-09-26 23:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAC83ZvLfCOjKja1rZ6GB4bmn_KrcjitTJZJsa5jy01QVj2OXXw@mail.gmail.com>
"DebBarma, Tarun Kanti" <tarun.kanti@ti.com> writes:
[...]
> As pointed out by Kevin, debounce clock was not getting disabled.
> In my testing I was somehow grepping CORE power domain instead
> of PER power domain and hence missed it. The fix for the debounce
> clock issue is at the end of the email.
>
> - Have re-based the for_3.2/gpio-cleanup branch against 3.1-rc6.
> - Dropped [PATCH 26/26] gpio/omap: add dbclk aliases for all gpio modules
> as suggested by Kevin since it's already taken care by hwmod.
> - Added the debounce clock fix in the end.
That debounce fix definitely makes things look better, but it's not
solving the problem...
> With above, PER is hitting low power state in Suspend and Idle path.
>
> Have pushed a branch at below URL with mentioned changes.
> git://gitorious.org/omap-sw-develoment/linux-omap-dev.git
> for_3.2/kevin/gpio-cleanup
I tested your branch on my 3430/n900 and PER is still not hitting
retention. Setting all debounce values in the board file to zero using
the patch below[1] makes PER hit retention again.
Assuming you don't have an n900 to test with, I suggest you just copy
the GPIO keys init from board-rx51-peripherals.c (or some of it) into
the board file you are testing with.
The problem is most likely be related to having more than one GPIO in a
bank with debounce enabled, or more than one bank with GPIOs enabled and
your current test is not be catching it.
Kevin
[1]
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 5a886cd..1853194 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -207,7 +207,7 @@ static void __init rx51_charger_init(void)
#define RX51_GPIO_LOCK_BUTTON 113
#define RX51_GPIO_PROXIMITY 89
-#define RX51_GPIO_DEBOUNCE_TIMEOUT 10
+#define RX51_GPIO_DEBOUNCE_TIMEOUT 0
static struct gpio_keys_button rx51_gpio_keys[] = {
{
^ permalink raw reply related
* [PATCH 01/11] OMAP2+: Add SoC specific map_io functions
From: Tony Lindgren @ 2011-09-26 23:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110923230049.GC6324@atomide.com>
* Tony Lindgren <tony@atomide.com> [110923 15:27]:
> * Benoit Cousson <b-cousson@ti.com> [110923 12:50]:
> > Add SoC specific map_io function to be used by the generic DT
> > board file. This is an intermediate step before having some
> > generic DT aware map_io function.
>
> Thanks, I'll apply this into cleanup branch and with the related
> conversion of board files.
Following replies contain the two related patches.
Tony
^ permalink raw reply
* [PATCH v7 04/26] gpio/omap: fix pwrdm_post_transition call sequence
From: Kevin Hilman @ 2011-09-26 23:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315918979-26173-5-git-send-email-tarun.kanti@ti.com>
Tarun Kanti DebBarma <tarun.kanti@ti.com> writes:
> From: Charulatha V <charu@ti.com>
>
> The context lost count is modified in omap_sram_idle() path when
> pwrdm_post_transition() is called. But pwrdm_post_transition() is called
> only after omap_gpio_resume_after_idle() is called. Correct this so that
> context lost count is modified before calling omap_gpio_resume_after_idle().
>
> This would be useful when OMAP GPIO save/restore context is called by
> the OMAP GPIO driver itself.
>
> Signed-off-by: Charulatha V <charu@ti.com>
> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
This one isn't directly related to the GPIO cleanup, so I'll pull it out
and add it to my PM cleanup queue for v3.2, adding Tony's ack.
I'll also change the subject prefix to: ARM: OMAP3: PM: ...
Kevin
> ---
> arch/arm/mach-omap2/pm34xx.c | 7 ++++---
> 1 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index 7255d9b..1915050 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -363,7 +363,6 @@ void omap_sram_idle(void)
> printk(KERN_ERR "Invalid mpu state in sram_idle\n");
> return;
> }
> - pwrdm_pre_transition();
>
> /* NEON control */
> if (pwrdm_read_pwrst(neon_pwrdm) == PWRDM_POWER_ON)
> @@ -386,6 +385,8 @@ void omap_sram_idle(void)
> if (!console_trylock())
> goto console_still_active;
>
> + pwrdm_pre_transition();
> +
> /* PER */
> if (per_next_state < PWRDM_POWER_ON) {
> per_going_off = (per_next_state == PWRDM_POWER_OFF) ? 1 : 0;
> @@ -455,6 +456,8 @@ void omap_sram_idle(void)
> }
> omap3_intc_resume_idle();
>
> + pwrdm_post_transition();
> +
> /* PER */
> if (per_next_state < PWRDM_POWER_ON) {
> per_prev_state = pwrdm_read_prev_pwrst(per_pwrdm);
> @@ -478,8 +481,6 @@ console_still_active:
> omap3_disable_io_chain();
> }
>
> - pwrdm_post_transition();
> -
> clkdm_allow_idle(mpu_pwrdm->pwrdm_clkdms[0]);
> }
^ permalink raw reply
* [PATCH] ARM: OMAP2+: Use SoC specifc map_io
From: Tony Lindgren @ 2011-09-26 23:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110926231516.GI6324@atomide.com>
There's no longer any need for the board specific
map_io.
Signed-off-by: Tony Lindgren <tony@atomide.com>
diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-omap2/board-2430sdp.c
index 618216c..45dafe2 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -243,17 +243,11 @@ static void __init omap_2430sdp_init(void)
"Secondary LCD backlight");
}
-static void __init omap_2430sdp_map_io(void)
-{
- omap2_set_globals_243x();
- omap243x_map_common_io();
-}
-
MACHINE_START(OMAP_2430SDP, "OMAP2430 sdp2430 board")
/* Maintainer: Syed Khasim - Texas Instruments Inc */
.boot_params = 0x80000100,
.reserve = omap_reserve,
- .map_io = omap_2430sdp_map_io,
+ .map_io = omap243x_map_io,
.init_early = omap2430_init_early,
.init_irq = omap2_init_irq,
.init_machine = omap_2430sdp_init,
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
index ab19d30..44a3e2c 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -825,17 +825,11 @@ static void __init omap_4430sdp_init(void)
omap_4430sdp_display_init();
}
-static void __init omap_4430sdp_map_io(void)
-{
- omap2_set_globals_443x();
- omap44xx_map_common_io();
-}
-
MACHINE_START(OMAP_4430SDP, "OMAP4430 4430SDP board")
/* Maintainer: Santosh Shilimkar - Texas Instruments Inc */
.boot_params = 0x80000100,
.reserve = omap_reserve,
- .map_io = omap_4430sdp_map_io,
+ .map_io = omap4_map_io,
.init_early = omap4430_init_early,
.init_irq = gic_init_irq,
.init_machine = omap_4430sdp_init,
diff --git a/arch/arm/mach-omap2/board-apollon.c b/arch/arm/mach-omap2/board-apollon.c
index cf546f8..8528436 100644
--- a/arch/arm/mach-omap2/board-apollon.c
+++ b/arch/arm/mach-omap2/board-apollon.c
@@ -337,17 +337,11 @@ static void __init omap_apollon_init(void)
omap_sdrc_init(NULL, NULL);
}
-static void __init omap_apollon_map_io(void)
-{
- omap2_set_globals_242x();
- omap242x_map_common_io();
-}
-
MACHINE_START(OMAP_APOLLON, "OMAP24xx Apollon")
/* Maintainer: Kyungmin Park <kyungmin.park@samsung.com> */
.boot_params = 0x80000100,
.reserve = omap_reserve,
- .map_io = omap_apollon_map_io,
+ .map_io = omap242x_map_io,
.init_early = omap2420_init_early,
.init_irq = omap2_init_irq,
.init_machine = omap_apollon_init,
diff --git a/arch/arm/mach-omap2/board-h4.c b/arch/arm/mach-omap2/board-h4.c
index 948fde0..fcc5107 100644
--- a/arch/arm/mach-omap2/board-h4.c
+++ b/arch/arm/mach-omap2/board-h4.c
@@ -369,17 +369,11 @@ static void __init omap_h4_init(void)
h4_init_flash();
}
-static void __init omap_h4_map_io(void)
-{
- omap2_set_globals_242x();
- omap242x_map_common_io();
-}
-
MACHINE_START(OMAP_H4, "OMAP2420 H4 board")
/* Maintainer: Paul Mundt <paul.mundt@nokia.com> */
.boot_params = 0x80000100,
.reserve = omap_reserve,
- .map_io = omap_h4_map_io,
+ .map_io = omap242x_map_io,
.init_early = omap2420_init_early,
.init_irq = omap_h4_init_irq,
.init_machine = omap_h4_init,
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index 77a4e19..d1f4a02 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -616,12 +616,6 @@ static struct i2c_board_info n810_i2c_board_info_2[] __initdata = {
},
};
-static void __init n8x0_map_io(void)
-{
- omap2_set_globals_242x();
- omap242x_map_common_io();
-}
-
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
/* I2S codec port pins for McBSP block */
@@ -692,7 +686,7 @@ static void __init n8x0_init_machine(void)
MACHINE_START(NOKIA_N800, "Nokia N800")
.boot_params = 0x80000100,
.reserve = omap_reserve,
- .map_io = n8x0_map_io,
+ .map_io = omap242x_map_io,
.init_early = omap2420_init_early,
.init_irq = omap2_init_irq,
.init_machine = n8x0_init_machine,
@@ -702,7 +696,7 @@ MACHINE_END
MACHINE_START(NOKIA_N810, "Nokia N810")
.boot_params = 0x80000100,
.reserve = omap_reserve,
- .map_io = n8x0_map_io,
+ .map_io = omap242x_map_io,
.init_early = omap2420_init_early,
.init_irq = omap2_init_irq,
.init_machine = n8x0_init_machine,
@@ -712,7 +706,7 @@ MACHINE_END
MACHINE_START(NOKIA_N810_WIMAX, "Nokia N810 WiMAX")
.boot_params = 0x80000100,
.reserve = omap_reserve,
- .map_io = n8x0_map_io,
+ .map_io = omap242x_map_io,
.init_early = omap2420_init_early,
.init_irq = omap2_init_irq,
.init_machine = n8x0_init_machine,
diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c
index 1bce765..e269290 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -570,17 +570,11 @@ static void __init omap4_panda_init(void)
omap4_panda_display_init();
}
-static void __init omap4_panda_map_io(void)
-{
- omap2_set_globals_443x();
- omap44xx_map_common_io();
-}
-
MACHINE_START(OMAP4_PANDA, "OMAP4 Panda board")
/* Maintainer: David Anders - Texas Instruments Inc */
.boot_params = 0x80000100,
.reserve = omap_reserve,
- .map_io = omap4_panda_map_io,
+ .map_io = omap4_map_io,
.init_early = omap4430_init_early,
.init_irq = gic_init_irq,
.init_machine = omap4_panda_init,
diff --git a/arch/arm/mach-omap2/board-rm680.c b/arch/arm/mach-omap2/board-rm680.c
index a3182e8..a98db61 100644
--- a/arch/arm/mach-omap2/board-rm680.c
+++ b/arch/arm/mach-omap2/board-rm680.c
@@ -143,16 +143,10 @@ static void __init rm680_init(void)
rm680_peripherals_init();
}
-static void __init rm680_map_io(void)
-{
- omap2_set_globals_3xxx();
- omap34xx_map_common_io();
-}
-
MACHINE_START(NOKIA_RM680, "Nokia RM-680 board")
.boot_params = 0x80000100,
.reserve = omap_reserve,
- .map_io = rm680_map_io,
+ .map_io = omap3_map_io,
.init_early = omap3630_init_early,
.init_irq = omap3_init_irq,
.init_machine = rm680_init,
diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c
index 32a79e2..8677a06 100644
--- a/arch/arm/mach-omap2/board-rx51.c
+++ b/arch/arm/mach-omap2/board-rx51.c
@@ -139,12 +139,6 @@ static void __init rx51_init(void)
platform_device_register(&leds_gpio);
}
-static void __init rx51_map_io(void)
-{
- omap2_set_globals_3xxx();
- omap34xx_map_common_io();
-}
-
static void __init rx51_reserve(void)
{
rx51_video_mem_init();
@@ -155,7 +149,7 @@ MACHINE_START(NOKIA_RX51, "Nokia RX-51 board")
/* Maintainer: Lauri Leukkunen <lauri.leukkunen@nokia.com> */
.boot_params = 0x80000100,
.reserve = rx51_reserve,
- .map_io = rx51_map_io,
+ .map_io = omap3_map_io,
.init_early = omap3430_init_early,
.init_irq = omap3_init_irq,
.init_machine = rx51_init,
^ permalink raw reply related
* Pull request: removal of most instances of mach/memory.h
From: Russell King - ARM Linux @ 2011-09-26 23:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1109261852530.2718@xanadu.home>
On Mon, Sep 26, 2011 at 07:01:22PM -0400, Nicolas Pitre wrote:
> On Mon, 26 Sep 2011, Russell King - ARM Linux wrote:
>
> > On Mon, Sep 26, 2011 at 04:00:11PM -0400, Nicolas Pitre wrote:
> > > On Mon, 26 Sep 2011, Russell King - ARM Linux wrote:
> > >
> > > > On Mon, Sep 26, 2011 at 10:33:28AM -0400, Nicolas Pitre wrote:
> > > > > ARM: mach-ep93xx: remove mach/memory.h and Kconfig selection of SDRAM bank
> > > >
> > > > Are you planning to totally kill off ZBOOT_ROM too? Because removing
> > > > the zreladdr stuff is doing exactly that.
> > >
> > > It looks like ZBOOT_ROM is not used on that platform at all. However,
> > > the ability to have a single defconfig and binary for the whole platform
> > > is something that the mach-ep93xx maintainers are looking for. Having
> > > ZBOOT_ROM depend on and use CONFIG_PHYS_OFFSET would probably makes
> > > sense eventually.
> >
> > You miss the point. Removing zreladdr actively _prevents_ anyone from
> > then choosing to build a kernel with ZBOOT_ROM enabled targetted for one
> > platform if that's what they want, because the decompressor then loses
> > the information it needs to properly locate the kernel.
>
> Sure. My point is that ZBOOT_ROM should eventually be coupled with
> CONFIG_PHYS_OFFSET to derive the zreladdr value. Like for XIP_KERNEL,
> there is no real point having ZBOOT_ROM when ARM_PATCH_PHYS_VIRT is set,
> and when not set we have the equivalent zreladdr information elsewhere
> already.
I strongly disagree on a technical point - ARM_PATCH_PHYS_VIRT and
ZBOOT_ROM are entirely separate options _technically_ - there is no
inter-dependence between them. ZBOOT_ROM just needs to know where
to place the decompressed image, and once it knows that, the kernel
can discover the P:V translation all by itself.
Moreover, PHYS_OFFSET does *not* define where the kernel ends up.
Remember that we sometimes place the kernel 1MB + 32K into the
physical memory space - you can't encode that into CONFIG_PHYS_OFFSET
and hope that both PHYS_OFFSET and zreladdr end up at the right place.
So this is argument is actually highly flawed technically. You're
trying to combine two things which are actually different.
Or are we now in the business of breaking old platforms?
^ permalink raw reply
* [PATCH] ARM: OMAP2+: Remove custom init_irq for remaining boards
From: Tony Lindgren @ 2011-09-26 23:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110926231646.GJ6324@atomide.com>
With SoC specific timers, board specific init_irq is
no longer needed. Earlier this was still needed to
initialize the gptimer12 on Beagle based boards.
Also convert board-h4.c to use omap2_init_irq accidentally
did not get converted earlier.
Signed-off-by: Tony Lindgren <tony@atomide.com>
diff --git a/arch/arm/mach-omap2/board-devkit8000.c b/arch/arm/mach-omap2/board-devkit8000.c
index 4b1f6c6..059b74d 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -397,11 +397,6 @@ static struct platform_device keys_gpio = {
},
};
-static void __init devkit8000_init_irq(void)
-{
- omap3_init_irq();
-}
-
#define OMAP_DM9000_BASE 0x2c000000
static struct resource omap_dm9000_resources[] = {
@@ -665,7 +660,7 @@ MACHINE_START(DEVKIT8000, "OMAP3 Devkit8000")
.reserve = omap_reserve,
.map_io = omap3_map_io,
.init_early = omap35xx_init_early,
- .init_irq = devkit8000_init_irq,
+ .init_irq = omap3_init_irq,
.init_machine = devkit8000_init,
.timer = &omap3_secure_timer,
MACHINE_END
diff --git a/arch/arm/mach-omap2/board-h4.c b/arch/arm/mach-omap2/board-h4.c
index fcc5107..8486142 100644
--- a/arch/arm/mach-omap2/board-h4.c
+++ b/arch/arm/mach-omap2/board-h4.c
@@ -290,11 +290,6 @@ static struct omap_board_config_kernel h4_config[] __initdata = {
{ OMAP_TAG_LCD, &h4_lcd_config },
};
-static void __init omap_h4_init_irq(void)
-{
- omap2_init_irq();
-}
-
static struct at24_platform_data m24c01 = {
.byte_len = SZ_1K / 8,
.page_size = 16,
@@ -375,7 +370,7 @@ MACHINE_START(OMAP_H4, "OMAP2420 H4 board")
.reserve = omap_reserve,
.map_io = omap242x_map_io,
.init_early = omap2420_init_early,
- .init_irq = omap_h4_init_irq,
+ .init_irq = omap2_init_irq,
.init_machine = omap_h4_init,
.timer = &omap2_timer,
MACHINE_END
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index ce3234d..e085371 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -449,11 +449,6 @@ static void __init omap3_beagle_init_early(void)
omap2_init_common_infrastructure();
}
-static void __init omap3_beagle_init_irq(void)
-{
- omap3_init_irq();
-}
-
static struct platform_device *omap3_beagle_devices[] __initdata = {
&leds_gpio,
&keys_gpio,
@@ -561,7 +556,7 @@ MACHINE_START(OMAP3_BEAGLE, "OMAP3 Beagle Board")
.reserve = omap_reserve,
.map_io = omap3_map_io,
.init_early = omap3_beagle_init_early,
- .init_irq = omap3_beagle_init_irq,
+ .init_irq = omap3_init_irq,
.init_machine = omap3_beagle_init,
.timer = &omap3_secure_timer,
MACHINE_END
diff --git a/arch/arm/mach-omap2/board-omap3stalker.c b/arch/arm/mach-omap2/board-omap3stalker.c
index 807c274..fa58a0f 100644
--- a/arch/arm/mach-omap2/board-omap3stalker.c
+++ b/arch/arm/mach-omap2/board-omap3stalker.c
@@ -428,11 +428,6 @@ static int __init omap3_stalker_i2c_init(void)
static struct omap_board_config_kernel omap3_stalker_config[] __initdata = {
};
-static void __init omap3_stalker_init_irq(void)
-{
- omap3_init_irq();
-}
-
static struct platform_device *omap3_stalker_devices[] __initdata = {
&keys_gpio,
};
@@ -492,7 +487,7 @@ MACHINE_START(SBC3530, "OMAP3 STALKER")
.boot_params = 0x80000100,
.map_io = omap3_map_io,
.init_early = omap35xx_init_early,
- .init_irq = omap3_stalker_init_irq,
+ .init_irq = omap3_init_irq,
.init_machine = omap3_stalker_init,
.timer = &omap3_secure_timer,
MACHINE_END
diff --git a/arch/arm/mach-omap2/board-omap3touchbook.c b/arch/arm/mach-omap2/board-omap3touchbook.c
index f7f1809..05488fb 100644
--- a/arch/arm/mach-omap2/board-omap3touchbook.c
+++ b/arch/arm/mach-omap2/board-omap3touchbook.c
@@ -326,11 +326,6 @@ static struct omap_board_mux board_mux[] __initdata = {
};
#endif
-static void __init omap3_touchbook_init_irq(void)
-{
- omap3_init_irq();
-}
-
static struct platform_device *omap3_touchbook_devices[] __initdata = {
&omap3_touchbook_lcd_device,
&leds_gpio,
@@ -403,7 +398,7 @@ MACHINE_START(TOUCHBOOK, "OMAP3 touchbook Board")
.reserve = omap_reserve,
.map_io = omap3_map_io,
.init_early = omap3430_init_early,
- .init_irq = omap3_touchbook_init_irq,
+ .init_irq = omap3_init_irq,
.init_machine = omap3_touchbook_init,
.timer = &omap3_secure_timer,
MACHINE_END
^ permalink raw reply related
* [GIT PULL] Samsung Fixes for v3.1
From: Kukjin Kim @ 2011-09-26 23:22 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
This is Samsung fixes for v3.1
Please pull from:
git://github.com/kgene/linux-samsung.git samsung-fixes-3
These things are needed for v3.1 and if any problems, please let me know.
Arnd, since v3.1 is now close at hand, I'm sending this to Linus...
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
The following changes since commit d93dc5c4478c1fd5de85a3e8aece9aad7bbae044:
Linux 3.1-rc7 (2011-09-21 16:58:15 -0700)
are available in the git repository at:
git://github.com/kgene/linux-samsung.git samsung-fixes-3
Heiko Stuebner (1):
ARM: S3C2443: Fix bit-reset in setrate of clk_armdiv
Marek Szyprowski (1):
ARM: S5P: fix incorrect loop iterator usage on gpio-interrupt
Sylwester Nawrocki (2):
ARM: S5PV210: Rename sclk_cam clocks for FIMC media driver
ARM: EXYNOS4: Rename sclk_cam clocks for FIMC driver
arch/arm/mach-exynos4/clock.c | 6 ++----
arch/arm/mach-s3c2443/clock.c | 2 +-
arch/arm/mach-s5pv210/clock.c | 6 ++----
arch/arm/plat-s5p/irq-gpioint.c | 9 +++++----
4 files changed, 10 insertions(+), 13 deletions(-)
^ permalink raw reply
* [PATCH v3 1/2] ARM: EXYNOS4: Add TVOUT support for SMDKV310
From: Kukjin Kim @ 2011-09-26 23:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316670876-1636-1-git-send-email-hatim.rv@samsung.com>
Hatim Ali wrote:
>
> Add support for TVOUT on SMDKV310 board.
>
> Signed-off-by: Hatim Ali <hatim.rv@samsung.com>
> ---
> Changes since v2:
> Incorporated review comments by Tomasz Stanislawski & Sylwester Nawrocki.
> - Used gpio_request_one to request for gpio line.
> - Added WARN_ON to check gpio_request is successful.
>
> Changes since v1:
> Incorporated changes as suggested by Tomasz Stanislawski
> - Added GPIO settings for hot-plug detection.
> - Added setting hdmi and mixer's parent for TV power domain.
>
> arch/arm/mach-exynos4/Kconfig | 2 ++
> arch/arm/mach-exynos4/mach-smdkv310.c | 18 ++++++++++++++++++
> 2 files changed, 20 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
> index 690bf6f..2857ab0 100644
> --- a/arch/arm/mach-exynos4/Kconfig
> +++ b/arch/arm/mach-exynos4/Kconfig
> @@ -139,7 +139,9 @@ config MACH_SMDKV310
> select S3C_DEV_RTC
> select S3C_DEV_WDT
> select S3C_DEV_I2C1
> + select S5P_DEV_I2C_HDMIPHY
> select S5P_DEV_MFC
> + select S5P_DEV_TV
> select S3C_DEV_HSMMC
> select S3C_DEV_HSMMC1
> select S3C_DEV_HSMMC2
> diff --git a/arch/arm/mach-exynos4/mach-smdkv310.c b/arch/arm/mach-
> exynos4/mach-smdkv310.c
> index 5f62b2b..fa3f9d7 100644
> --- a/arch/arm/mach-exynos4/mach-smdkv310.c
> +++ b/arch/arm/mach-exynos4/mach-smdkv310.c
> @@ -173,6 +173,7 @@ static struct platform_device *smdkv310_devices[]
> __initdata = {
> &s3c_device_hsmmc2,
> &s3c_device_hsmmc3,
> &s3c_device_i2c1,
> + &s5p_device_i2c_hdmiphy,
> &s3c_device_rtc,
> &s3c_device_wdt,
> &exynos4_device_ac97,
> @@ -194,6 +195,8 @@ static struct platform_device *smdkv310_devices[]
> __initdata = {
> &samsung_asoc_idma,
> &smdkv310_smsc911x,
> &exynos4_device_ahci,
> + &s5p_device_hdmi,
> + &s5p_device_mixer,
> };
>
> static void __init smdkv310_smsc911x_init(void)
> @@ -230,6 +233,18 @@ static struct platform_pwm_backlight_data
> smdkv310_bl_data = {
> .pwm_period_ns = 1000,
> };
>
> +static void s5p_tv_setup(void)
> +{
> + /* direct HPD to HDMI chip */
> + WARN_ON(gpio_request_one(EXYNOS4_GPX3(7),GPIOF_IN, "hpd-
> plug"));
ERROR: space required after that ',' (ctx:VxV)
#64: FILE: arch/arm/mach-exynos4/mach-smdkv310.c:239:
+ WARN_ON(gpio_request_one(EXYNOS4_GPX3(7),GPIOF_IN, "hpd-plug"));
Hmm...
OK, applied even though I don't think we really need to add WARN_ON here
because the board manager already knows the gpio pin is used for it.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
> + s3c_gpio_cfgpin(EXYNOS4_GPX3(7), S3C_GPIO_SFN(0x3));
> + s3c_gpio_setpull(EXYNOS4_GPX3(7), S3C_GPIO_PULL_NONE);
> +
> + /* setup dependencies between TV devices */
> + s5p_device_hdmi.dev.parent = &exynos4_device_pd[PD_TV].dev;
> + s5p_device_mixer.dev.parent = &exynos4_device_pd[PD_TV].dev;
> +}
> +
> static void __init smdkv310_map_io(void)
> {
> s5p_init_io(NULL, 0, S5P_VA_CHIPID);
> @@ -254,6 +269,9 @@ static void __init smdkv310_machine_init(void)
> s3c_sdhci2_set_platdata(&smdkv310_hsmmc2_pdata);
> s3c_sdhci3_set_platdata(&smdkv310_hsmmc3_pdata);
>
> + s5p_tv_setup();
> + s5p_i2c_hdmiphy_set_platdata(NULL);
> +
> samsung_keypad_set_platdata(&smdkv310_keypad_data);
>
> samsung_bl_set(&smdkv310_bl_gpio_info, &smdkv310_bl_data);
> --
> 1.7.2.3
^ permalink raw reply
* [PATCH v7 05/26] gpio/omap: handle save/restore context in GPIO driver
From: Kevin Hilman @ 2011-09-26 23:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315918979-26173-6-git-send-email-tarun.kanti@ti.com>
Tarun Kanti DebBarma <tarun.kanti@ti.com> writes:
> From: Charulatha V <charu@ti.com>
>
> Modify omap_gpio_prepare_for_idle() & omap_gpio_resume_after_idle() functions
> to handle save context & restore context respectively in the OMAP GPIO driver
> itself instead of calling these functions from pm specific files.
> For this, in gpio_prepare_for_idle(), call *_get_context_loss_count() and in
> gpio_resume_after_idle() call it again. If the count is different, do restore
> context. The workaround_enabled flag is no more required and is removed.
>
> Signed-off-by: Charulatha V <charu@ti.com>
> Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com>
> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[...]
> diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/mach-omap2/gpio.c
> index 9f3a007..6c6b1a7 100644
> --- a/arch/arm/mach-omap2/gpio.c
> +++ b/arch/arm/mach-omap2/gpio.c
> @@ -23,6 +23,7 @@
>
> #include <plat/omap_hwmod.h>
> #include <plat/omap_device.h>
> +#include <plat/omap-pm.h>
>
> #include "powerdomain.h"
>
> @@ -63,7 +64,9 @@ static int omap2_gpio_dev_init(struct omap_hwmod *oh, void *unused)
> pdata->bank_width = dev_attr->bank_width;
> pdata->dbck_flag = dev_attr->dbck_flag;
> pdata->virtual_irq_start = IH_GPIO_BASE + 32 * (id - 1);
> -
> +#ifdef CONFIG_PM
> + pdata->get_context_loss_count = omap_pm_get_dev_context_loss_count;
> +#endif
no #ifdef please (c.f. "#ifdefs are ugly" in
Documentation/SubmittingPatches)
In this case, the existence of this API isn't dependent on CONFIG_PM, so
the #ifdef isn't right.
Kevin
^ permalink raw reply
* [PATCH 1/7] SPI: S3C64XX: Use bus clocks created using clkdev
From: Kukjin Kim @ 2011-09-26 23:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110923231233.GE24631@ponder.secretlab.ca>
Grant Likely wrote:
>
> On Fri, Sep 23, 2011 at 05:23:41PM +0530, Padmavathi Venna wrote:
> > This patch modifies the driver to stop depending on the
> > clock names being passed from platform and switch over
> > to lookup clocks generic names using clkdev
> >
> > Signed-off-by: Padmavathi Venna <padma.v@samsung.com>
>
> Looks okay to me.
>
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
>
> This series I imagine should go in via the arm-soc tree.
>
OK, if others ok to me, I will pick up this series so that it will be sent
to upstream via arm-soc.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
>
> > ---
> > drivers/spi/spi-s3c64xx.c | 14 +++++---------
> > 1 files changed, 5 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
> > index 019a716..dcf7e10 100644
> > --- a/drivers/spi/spi-s3c64xx.c
> > +++ b/drivers/spi/spi-s3c64xx.c
> > @@ -971,6 +971,7 @@ static int __init s3c64xx_spi_probe(struct
> platform_device *pdev)
> > struct s3c64xx_spi_info *sci;
> > struct spi_master *master;
> > int ret;
> > + char clk_name[16];
> >
> > if (pdev->id < 0) {
> > dev_err(&pdev->dev,
> > @@ -984,11 +985,6 @@ static int __init s3c64xx_spi_probe(struct
> platform_device *pdev)
> > }
> >
> > sci = pdev->dev.platform_data;
> > - if (!sci->src_clk_name) {
> > - dev_err(&pdev->dev,
> > - "Board init must call s3c64xx_spi_set_info()\n");
> > - return -EINVAL;
> > - }
> >
> > /* Check for availability of necessary resource */
> >
> > @@ -1073,17 +1069,17 @@ static int __init s3c64xx_spi_probe(struct
> platform_device *pdev)
> > goto err4;
> > }
> >
> > - sdd->src_clk = clk_get(&pdev->dev, sci->src_clk_name);
> > + sprintf(clk_name, "spi_busclk%d", sci->src_clk_nr);
> > + sdd->src_clk = clk_get(&pdev->dev, clk_name);
> > if (IS_ERR(sdd->src_clk)) {
> > dev_err(&pdev->dev,
> > - "Unable to acquire clock '%s'\n",
sci->src_clk_name);
> > + "Unable to acquire clock '%s'\n", clk_name);
> > ret = PTR_ERR(sdd->src_clk);
> > goto err5;
> > }
> >
> > if (clk_enable(sdd->src_clk)) {
> > - dev_err(&pdev->dev, "Couldn't enable clock '%s'\n",
> > - sci->src_clk_name);
> > + dev_err(&pdev->dev, "Couldn't enable clock '%s'\n",
clk_name);
> > ret = -EBUSY;
> > goto err6;
> > }
> > --
> > 1.7.4.4
> >
^ permalink raw reply
* Pull request: removal of most instances of mach/memory.h
From: Russell King - ARM Linux @ 2011-09-26 23:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1109261901550.2718@xanadu.home>
On Mon, Sep 26, 2011 at 07:03:12PM -0400, Nicolas Pitre wrote:
> On Mon, 26 Sep 2011, Russell King - ARM Linux wrote:
>
> > On Mon, Sep 26, 2011 at 04:10:03PM -0400, Nicolas Pitre wrote:
> > > On Mon, 26 Sep 2011, Nicolas Pitre wrote:
> > >
> > > > On Mon, 26 Sep 2011, Russell King - ARM Linux wrote:
> > > >
> > > > > This also gives additional merge conflicts elsewhere, and while git
> > > > > rerere makes some of them easy, the quantity is going to be a right
> > > > > pain to deal with on a repeated basis.
> > > >
> > > > Again, I'm perfectly willing to use a different base for this series and
> > > > fix the conflicts myself if you give me one.
> > >
> > > Nevermind, I see that you merged it anyway.
> > >
> > > You may consider the rerere.autoupdate config option if you want Git to
> > > automatically pick the conflict resolution without you manually
> > > confirming them all the time.
> >
> > rerere doesn't deal with modified/deleted conflicts though.
>
> True. That can be considered a limitation worth fixing.
Well. Now I'm not impressed, having investigated the reason behind
some of these conflicts.
The reason I'm getting the modify/delete conflict is because you've
made the same change to arch/arm/mach-prima2/include/mach/memory.h
as the one which you already submitted to me.
commit e922fe6625fb4700f041e5984ba6c09a1cadae65
Author: Nicolas Pitre <nicolas.pitre@linaro.org>
AuthorDate: Wed Sep 21 20:52:40 2011 +0100
Commit: Russell King <rmk+kernel@arm.linux.org.uk>
CommitDate: Mon Sep 26 12:31:09 2011 +0100
ARM: 7093/1: mach-prima2: move ARM_DMA_ZONE_SIZE to mdesc->dma_zone_size
The branch that contained the ARM_DMA_ZONE_SIZE removal missed prima2.
Original comment:
Restrict DMA-able region to workaround silicon limitation.
The limitation restricts buffers available for DMA to SD/MMC
hardware to be below 256MB.
Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
vs
commit 98b0124f0e2b88ec74cbd9345cf6195e527ce251
Author: Nicolas Pitre <nicolas.pitre@linaro.org>
AuthorDate: Fri Sep 2 21:05:10 2011 -0400
Commit: Nicolas Pitre <nico@fluxnic.net>
CommitDate: Tue Sep 6 17:25:54 2011 -0400
ARM: mach-prima2: move ARM_DMA_ZONE_SIZE to mdesc->dma_zone_size
Original comment:
Restrict DMA-able region to workaround silicon limitation.
The limitation restricts buffers available for DMA to SD/MMC
hardware to be below 256MB.
Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
I've no idea why you submitted this change to me if you'd already merged
it into your own tree - this is total madness and is just making more
work for me with no reason.
A little more discipline and communication (such as asking me to drop
the duplicate commit _first_) would be nice.
^ permalink raw reply
* [PATCH v2 4/7] clk: Add simple gated clock
From: Rob Herring @ 2011-09-26 23:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJOA=zMA8q-acr=BGWrpC9iLSR3E8Y0ybH4sZ=FOn54zQ7TJKw@mail.gmail.com>
On 09/26/2011 05:37 PM, Turquette, Mike wrote:
> On Mon, Sep 26, 2011 at 12:37 PM, Jamie Iles <jamie@jamieiles.com> wrote:
>> On Mon, Sep 26, 2011 at 02:10:32PM -0500, Rob Herring wrote:
>>> On 09/26/2011 01:40 PM, Jamie Iles wrote:
>>>> On Mon, Sep 26, 2011 at 01:33:08PM -0500, Rob Herring wrote:
>>>>>> +static void clk_gate_set_bit(struct clk_hw *clk)
>>>>>> +{
>>>>>> + struct clk_gate *gate = to_clk_gate(clk);
>>>>>> + u32 reg;
>>>>>> +
>>>>>> + reg = __raw_readl(gate->reg);
>>>>>> + reg |= BIT(gate->bit_idx);
>>>>>> + __raw_writel(reg, gate->reg);
>>>>>
>>>>> Don't these read-mod-writes need a spinlock around it?
>>>>>
>>>>> It's possible to have an enable bits and dividers in the same register.
>>>>> If you did a set_rate and while doing an enable/disable, there would be
>>>>> a problem. Also, it may be 2 different clocks in the same register, so
>>>>> the spinlock needs to be shared and not per clock.
>>>>
>>>> Well the prepare lock will be held here and I believe that would be
>>>> sufficient.
>>>
>>> No, the enable spinlock is protecting enable/disable. But set_rate is
>>> protected by the prepare mutex. So you clearly don't need locking if you
>>> have a register of only 1 bit enables. If you have a register accessed
>>> by both enable/disable and prepare/unprepare/set_rate, then you need
>>> some protection.
>>
>> OK fair point, but I would guess that if you had a clock like this then
>> you probably wouldn't use this simple gated clock would you? (speaking
>> from my world where we have quite simple clocks ;-))
>
> I think it is a safe assumption that if a register controls both
> enable/disable and some programmable divider then,
>
> 1) those controls are probably for the same clock
> 2) that clock won't be using the cookie-cutter gated-clock
> implementation anyways
By definition of simple gated clock, the other bits have to be for
another clock. The restriction is that all the other bits can only be
clock gate bits.
>
> Rob, do you feel these assumptions are OK and locking can remain the
> same in this patch?
Perhaps it is rare enough that it is not worth it use generic code in
this case. If so, the documentation should be clear about this
constraint. It is not something anyone will have hit before because
everyone used a single global lock. Now with the api being split between
2 locks, this adds a new complexity.
I think the simple gated clock code should be usable for any clock
controlled by a single bit in a 32-bit register independent of other
things in that register.
One example is MX1 in (mach-imx/clock-imx1.c). The CSCR register has
single bit enable for clk16m while hclk and clk48m have dividers in that
register.
Rob
^ permalink raw reply
* Pull request: removal of most instances of mach/memory.h
From: Nicolas Pitre @ 2011-09-26 23:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110926231806.GC23680@n2100.arm.linux.org.uk>
On Tue, 27 Sep 2011, Russell King - ARM Linux wrote:
> On Mon, Sep 26, 2011 at 07:01:22PM -0400, Nicolas Pitre wrote:
> > On Mon, 26 Sep 2011, Russell King - ARM Linux wrote:
> >
> > > On Mon, Sep 26, 2011 at 04:00:11PM -0400, Nicolas Pitre wrote:
> > > > On Mon, 26 Sep 2011, Russell King - ARM Linux wrote:
> > > >
> > > > > On Mon, Sep 26, 2011 at 10:33:28AM -0400, Nicolas Pitre wrote:
> > > > > > ARM: mach-ep93xx: remove mach/memory.h and Kconfig selection of SDRAM bank
> > > > >
> > > > > Are you planning to totally kill off ZBOOT_ROM too? Because removing
> > > > > the zreladdr stuff is doing exactly that.
> > > >
> > > > It looks like ZBOOT_ROM is not used on that platform at all. However,
> > > > the ability to have a single defconfig and binary for the whole platform
> > > > is something that the mach-ep93xx maintainers are looking for. Having
> > > > ZBOOT_ROM depend on and use CONFIG_PHYS_OFFSET would probably makes
> > > > sense eventually.
> > >
> > > You miss the point. Removing zreladdr actively _prevents_ anyone from
> > > then choosing to build a kernel with ZBOOT_ROM enabled targetted for one
> > > platform if that's what they want, because the decompressor then loses
> > > the information it needs to properly locate the kernel.
> >
> > Sure. My point is that ZBOOT_ROM should eventually be coupled with
> > CONFIG_PHYS_OFFSET to derive the zreladdr value. Like for XIP_KERNEL,
> > there is no real point having ZBOOT_ROM when ARM_PATCH_PHYS_VIRT is set,
> > and when not set we have the equivalent zreladdr information elsewhere
> > already.
>
> I strongly disagree on a technical point - ARM_PATCH_PHYS_VIRT and
> ZBOOT_ROM are entirely separate options _technically_ - there is no
> inter-dependence between them. ZBOOT_ROM just needs to know where
> to place the decompressed image, and once it knows that, the kernel
> can discover the P:V translation all by itself.
What's the point having a discoverable P:V translation if you have to
specify the location of the decompressed image? Might as well compile
the kernel with PATCH_PHYS_VIRT turned off in that case.
> Moreover, PHYS_OFFSET does *not* define where the kernel ends up.
> Remember that we sometimes place the kernel 1MB + 32K into the
> physical memory space - you can't encode that into CONFIG_PHYS_OFFSET
> and hope that both PHYS_OFFSET and zreladdr end up at the right place.
Technically, zreladdr = PHYS_OFFSET + TEXT_OFFSET. Always been.
And TEXT_OFFSET is always constant. Some platforms have restrictions on
TEXT_OFFSET which is basically making it large enough. Most other
platforms don't care.
> So this is argument is actually highly flawed technically. You're
> trying to combine two things which are actually different.
I don't see why they have to be different.
Nicolas
^ permalink raw reply
* [PATCH resend 00/13] McBSP cleanup and generalization
From: Tony Lindgren @ 2011-09-26 23:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317023150-6730-1-git-send-email-jarkko.nikula@bitmer.com>
* Jarkko Nikula <jarkko.nikula@bitmer.com> [110926 00:12]:
> This is just resend of patches 2-14/14 I posted earlier:
>
> http://marc.info/?l=linux-omap&m=131480421332374&w=2
>
> Patch 1/14 is already in linux-omap, Acked-by from Peter added and I
> took freedom to thank Janusz by adding Tested-by line as he tested the
> set on OMAP1.
Thanks, I'll apply these into cleanup branch.
Regards,
Tony
^ 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