* [PATCHv2 5/7] ARM: OMAP3PLUS PM: Add IO Daisychain support via hwmod mux
From: Vishwanath BS @ 2011-10-07 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318009671-12813-1-git-send-email-vishwanath.bs@ti.com>
IO Daisychain feature has to be triggered whenever there is a change in
device's mux configuration (See section 3.9.4 in OMAP4 Public TRM vP).
Now devices can idle independent of the powerdomain, there can be a window where device
is idled and corresponding powerdomain can be ON/INACTIVE state. In such situations,
since both module wake up is enabled at padlevel as well as io daisychain sequence is
triggered, there will be 2 PRCM interrupts (Module async wake up via swakeup and IO Pad
interrupt). But as PRCM Interrupt handler clears the Module Padlevel WKST bit in the
first interrupt, module specific interrupt handler will not triggered for the second time
Also look at detailed explanation given by Rajendra at
http://www.spinics.net/lists/linux-serial/msg04480.html
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
---
This has been tested on OMAP3 using Chain Handler + UART Runtime patches [1]. Special
thanks to GOvind for testing and confirming this behaviour on UART3.
[1]: git://gitorious.org/runtime_3-0/runtime_3-0.git v6_uart_runtime
arch/arm/mach-omap2/omap_hwmod.c | 9 +++++++--
arch/arm/mach-omap2/pm.c | 11 +++++++++++
arch/arm/mach-omap2/pm.h | 1 +
3 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 84cc0bd..070f3f5 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -151,6 +151,7 @@
#include "prm44xx.h"
#include "prminst44xx.h"
#include "mux.h"
+#include "pm.h"
/* Maximum microseconds to wait for OMAP module to softreset */
#define MAX_MODULE_SOFTRESET_WAIT 10000
@@ -1462,8 +1463,10 @@ static int _enable(struct omap_hwmod *oh)
/* Mux pins for device runtime if populated */
if (oh->mux && (!oh->mux->enabled ||
((oh->_state == _HWMOD_STATE_IDLE) &&
- oh->mux->pads_dynamic)))
+ oh->mux->pads_dynamic))) {
omap_hwmod_mux(oh->mux, _HWMOD_STATE_ENABLED);
+ omap_trigger_wuclk_ctrl();
+ }
_add_initiator_dep(oh, mpu_oh);
@@ -1553,8 +1556,10 @@ static int _idle(struct omap_hwmod *oh)
clkdm_hwmod_disable(oh->clkdm, oh);
/* Mux pins for device idle if populated */
- if (oh->mux && oh->mux->pads_dynamic)
+ if (oh->mux && oh->mux->pads_dynamic) {
omap_hwmod_mux(oh->mux, _HWMOD_STATE_IDLE);
+ omap_trigger_wuclk_ctrl();
+ }
oh->_state = _HWMOD_STATE_IDLE;
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 472bf22..79be7af 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -23,6 +23,8 @@
#include "powerdomain.h"
#include "clockdomain.h"
#include "pm.h"
+#include "prm2xxx_3xxx.h"
+#include "prm44xx.h"
static struct omap_device_pm_latency *pm_lats;
@@ -95,6 +97,15 @@ static void omap2_init_processor_devices(void)
}
}
+void omap_trigger_wuclk_ctrl(void)
+{
+ if (cpu_is_omap34xx())
+ omap3_trigger_wuclk_ctrl();
+
+ if (cpu_is_omap44xx())
+ omap4_trigger_wuclk_ctrl();
+}
+
/* Types of sleep_switch used in omap_set_pwrdm_state */
#define FORCEWAKEUP_SWITCH 0
#define LOWPOWERSTATE_SWITCH 1
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 4e166ad..05c2da2 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -21,6 +21,7 @@ extern void omap_sram_idle(void);
extern int omap3_can_sleep(void);
extern int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
extern int omap3_idle_init(void);
+void omap_trigger_wuclk_ctrl(void);
#if defined(CONFIG_PM_OPP)
extern int omap3_opp_init(void);
--
1.7.0.4
^ permalink raw reply related
* [PATCHv2 6/7] ARM: OMAP3 PM: Remove IO Daisychain control from cpuidle
From: Vishwanath BS @ 2011-10-07 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318009671-12813-1-git-send-email-vishwanath.bs@ti.com>
As IO Daisy chain sequence is triggered via hwmod mux, there is no need to
control it from cpuidle path for OMAP3.
Also as omap3_disable_io_chain is no longer being used, just remove the function.
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
---
arch/arm/mach-omap2/pm34xx.c | 15 ---------------
arch/arm/mach-omap2/prm2xxx_3xxx.c | 8 --------
2 files changed, 0 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index c282552..ea78d72 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -341,12 +341,6 @@ void omap_sram_idle(void)
/* Enable IO-PAD and IO-CHAIN wakeups */
per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
- if (omap3_has_io_wakeup() &&
- (per_next_state < PWRDM_POWER_ON ||
- core_next_state < PWRDM_POWER_ON)) {
- omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD, PM_WKEN);
- omap3_trigger_wuclk_ctrl();
- }
/* Block console output in case it is on one of the OMAP UARTs */
if (!is_suspending())
@@ -438,15 +432,6 @@ void omap_sram_idle(void)
console_unlock();
console_still_active:
- /* Disable IO-PAD and IO-CHAIN wakeup */
- if (omap3_has_io_wakeup() &&
- (per_next_state < PWRDM_POWER_ON ||
- core_next_state < PWRDM_POWER_ON)) {
- omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD,
- PM_WKEN);
- omap3_disable_io_chain();
- }
-
pwrdm_post_transition();
clkdm_allow_idle(mpu_pwrdm->pwrdm_clkdms[0]);
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.c b/arch/arm/mach-omap2/prm2xxx_3xxx.c
index 915d726..0c70bc4 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.c
@@ -183,11 +183,3 @@ void omap3_trigger_wuclk_ctrl(void)
PM_WKEN);
}
}
-
-/* OMAP3 Daisychain disable sequence */
-void omap3_disable_io_chain(void)
-{
- if (omap_rev() >= OMAP3430_REV_ES3_1)
- omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
- PM_WKEN);
-}
--
1.7.0.4
^ permalink raw reply related
* [PATCHv2 7/7] ARM: OMAP3 PM: Enable IO Daisychain for supported chips
From: Vishwanath BS @ 2011-10-07 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318009671-12813-1-git-send-email-vishwanath.bs@ti.com>
IO Daisychain has to be enabled only if the corresponding omap has
io wake up capability.
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
---
arch/arm/mach-omap2/prm2xxx_3xxx.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.c b/arch/arm/mach-omap2/prm2xxx_3xxx.c
index 0c70bc4..9a92fef 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.c
@@ -168,7 +168,7 @@ void omap3_trigger_wuclk_ctrl(void)
{
int i = 0;
- if (omap_rev() >= OMAP3430_REV_ES3_1) {
+ if ((omap_rev() >= OMAP3430_REV_ES3_1) && omap3_has_io_wakeup()) {
omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
PM_WKEN);
/* Do a readback to assure write has been done */
--
1.7.0.4
^ permalink raw reply related
* ARM SoC tree: OMAP PM dependency on tip irq/core
From: Kevin Hilman @ 2011-10-07 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201110071804.11494.arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> writes:
> On Thursday 06 October 2011, Tony Lindgren wrote:
>> * Rob Herring <robherring2@gmail.com> [111001 13:21]:
>> > On 09/30/2011 05:29 PM, Kevin Hilman wrote:
>> > > Hi Arnd,
>> > >
>> > > Kevin Hilman <khilman@ti.com> writes:
>> > >
>> > >> The upcoming OMAP4 PM series from Santosh[1] that we're planning to
>> > >> queue for v3.2 has a dependency[2] on a patch currently queued for v3.2
>> > >> in the irq/core branch of Thomas' tip tree[3].
>> > >>
>> > >> In the past, I noticed you merged external trees like this to solve
>> > >> dependencies.
>> > >>
>> > >> Could you pull the irq/core branch into your tree to meet this
>> > >> dependency?
>> > >
>> > > On second thought, since Santosh's branch is the only one with this
>> > > dependency (and we also have a dependency on Russell's devel-stable)
>> > > I'll just build up a branch for Santosh's series that includes
>> > > rmk/devel-stable and tglx/irq-core.
>> > >
>> >
>> > Any new platforms will have a dependency on rmk/devel-stable with the
>> > mach header clean-up. I'll probably have a dependency on tglx's tree as
>> > well.
>>
>> Sounds like Arnd should pull this into some branch then.
>
> I've pulled in rmk/devel-stable as a dependency now, thanks for
> reminding me of that.
>
> Thomas, where should I get the irq-core branch (or whichever
> I should wait for) to pull in as another dependency. Is that
> branch one that never gets rebased?
git://tesla.tglx.de/git/linux-2.6-tip irq/core
I asked Thomas about this earlier when I was going to build up the
dependencies myself, and he said it won't be rebased.
Kevin
^ permalink raw reply
* [GIT PULL] Samsung devel-2 for v3.2
From: Arnd Bergmann @ 2011-10-07 17:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <005801cc817c$5d42f9e0$17c8eda0$%kim@samsung.com>
On Monday 03 October 2011, Kukjin Kim wrote:
> Mark Brown wrote:
> >
> > On Sun, Oct 02, 2011 at 06:25:36PM +0900, Kukjin Kim wrote:
> >
> > > gpio/samsung: gpio-samsung.c to support Samsung GPIOs
> >
> > As I reported the other day this change breaks the boot early on on the
> > Cragganmore S3C6410 based systems (I've not actually fired up my
> > SMDK6410 but I suspect it may have issues too). I did make some brief
> > attempts to debug but as there's no console output at all and the diff
> > is rather large it's not easy to see what's gone wrong.
>
> Hmm, I thought it has no problem when I saw Thomas Abraham's 'serial:
> samsung' patches because he said it works fine with my for-next plus his
> patches on SMDK6410...Anyway, I need to sort it out.
>
> Arnd, please hold this on, will request again soon.
Any update on this?
Note that in general, I would prefer to get more separate pull
requests for the individual feature branches that you use internally
than having it all in one devel branch.
Time is running out before the merge window, so I'm not asking you
to change it again. I will pull it when you send it, but if you
have trouble with some specific parts of this, you can also send
me pull requests for the parts that are good.
Arnd
^ permalink raw reply
* [PATCH v7 0/3] Add support for tegra2 based ventana board
From: Stephen Warren @ 2011-10-07 18:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317647918-22694-1-git-send-email-pdeschrijver@nvidia.com>
Peter De Schrijver wrote at Monday, October 03, 2011 7:19 AM:
> This patch set adds support for the tegra2 based ventana development board.
>
> Boot tested on ventana.
With minor changes to the command-line in tegra-ventana.dts, to put the
root fs on an SD card, and using mainline U-Boot with the Ventana patch
series I wrote,
Tested-by: Stephen Warren <swarren@nvidia.com>
I have a couple of queries in patch 3 that I'll post separately.
--
nvpublic
^ permalink raw reply
* [GIT PULL] Samsung board-2 for v3.2
From: Arnd Bergmann @ 2011-10-07 18:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <019b01cc8298$846170c0$8d245240$%kim@samsung.com>
On Tuesday 04 October 2011, Kukjin Kim wrote:
> This is a second Samsung board stuff for v3.2 and includes new board,
> SMDK4412.
>
> Please pull from:
> git://github.com/kgene/linux-samsung.git next-samsung-board-2
>
> As a note, since supporting SMDK4412 needs previous next-samsung-board
> branch so this is based on next-samsung-board which has been already merged
> into arm-soc and this includes converting boot_params to atag_offset for
> adding/changing boards in this time.
>
> If any problems, please let me know.
>
> One more as a note, the next-samsung-devel and next-samsung-devel-2 will be
> sent to you soon after testing ;)
>
Pulled, thanks!
Arnd
^ permalink raw reply
* [PATCH v7 3/3] arm/tegra: device tree support for ventana board
From: Stephen Warren @ 2011-10-07 18:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317647918-22694-4-git-send-email-pdeschrijver@nvidia.com>
Peter De Schrijver wrote at Monday, October 03, 2011 7:19 AM:
...
> diff --git a/arch/arm/boot/dts/tegra-ventana.dts b/arch/arm/boot/dts/tegra-ventana.dts
...
> + chosen {
> + bootargs = "vmalloc=192M video=tegrafb console=ttyS0,115200n8 root=/dev/ram rdinit=/sbin/init";
It might be nice to make this identical to what Harmony and Seaboard have here.
Still, it doesn't matter a lot, since I (and I imagine most people) have
to edit this command-line to point at the correct partition for my disks
anyway; eventually, U-Boot should be providing/re-writing this property
too.
...
> diff --git a/arch/arm/mach-tegra/board-dt.c b/arch/arm/mach-tegra/board-dt.c
...
> - if (of_machine_is_compatible("nvidia,harmony"))
> - harmony_pinmux_init();
> - else if (of_machine_is_compatible("nvidia,seaboard"))
> - seaboard_pinmux_init();
> + for (i = 0; i < ARRAY_SIZE(pinmux_configs); i++) {
> + if (of_machine_is_compatible(pinmux_configs[i].machine)) {
> + pinmux_configs[i].init();
> + break;
> + }
> + }
> +
> + if (i == ARRAY_SIZE(pinmux_configs))
> + printk(KERN_WARNING "Unknown platform! Pinmuxing not initialized\n");
Should that be WARN() instead of printk?
--
nvpublic
^ permalink raw reply
* [GIT PULL] Samsung cleanup-2 for v3.2
From: Arnd Bergmann @ 2011-10-07 18:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <019a01cc8298$823f7b20$86be7160$%kim@samsung.com>
On Tuesday 04 October 2011, Kukjin Kim wrote:
> This is second cleanup for Samsung stuff for v3.2 and includes cleanup
> header files in plat-s3c24xx and plat-s5p to merge into one plat-samsung
> directory.
>
> Please pull from:
> git://github.com/kgene/linux-samsung.git next-samsung-cleanup-2
>
> And this is based on previous Samsung cleanup branch, next-samsung-cleanup
> which has been merged in arm-soc because of dependency.
>
> If any problems, please let me know.
>
Looks good to me. I think this should go into 3.2 very late during the merge
window since it moves around a lot of files that might be touched by other
patches, and I don't want to break a lot of that stuff, so I'm putting
it into a separate next/cleanup2 branch, ok?
Arnd
^ permalink raw reply
* [PATCH 1/4] ARM: Add __arm_ioremap_exec for mapping external memory as MT_MEMORY
From: Tony Lindgren @ 2011-10-07 18:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E8F395B.9070203@ti.com>
* Santosh Shilimkar <santosh.shilimkar@ti.com> [111007 10:05]:
>
> I initially tried some thing similar but the issue was GP and
> HS devices. SRAM_PA isn't same on GP and EMU device and hence
> did that dynamically. One way is I can make GP and HS
> device SRAM_PA same for OMAP4 (Will loose 16 KB of
> SRAM on OMAP4 GP). It's ok to loose that 16 KB SRAM
> for OMAP4 with errata enabled.
Oh yeah, the beginning is different too, I forgot that.
> Below change works on both GP and HS device
> If you are OK with it, I can update errata patch accordingly.
OK to me to loose 16KB when the errata is enabled. That can
be fixed later on for example by passing the SRAM area from
device tree.
I assume now you can add the mapping to io.c instead? If so,
then it's easier to apply the patches whatever way makes more
sense.
Regards,
Tony
> diff --git a/arch/arm/plat-omap/include/plat/sram.h
> b/arch/arm/plat-omap/include/plat/sram.h
> index f500fc3..111b1a8 100644
> --- a/arch/arm/plat-omap/include/plat/sram.h
> +++ b/arch/arm/plat-omap/include/plat/sram.h
> @@ -95,6 +95,11 @@ static inline void omap_push_sram_idle(void) {}
> */
> #define OMAP2_SRAM_PA 0x40200000
> #define OMAP3_SRAM_PA 0x40200000
> +#ifdef CONFIG_OMAP4_ERRATA_I688
> +#define OMAP4_SRAM_PA 0x40304000
> +#else
> #define OMAP4_SRAM_PA 0x40300000
> +#endif
> +#define OMAP4_SRAM_VA 0xfe404000
>
> #endif
> diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
> index 363c91e..cdd303f 100644
> --- a/arch/arm/plat-omap/sram.c
> +++ b/arch/arm/plat-omap/sram.c
> @@ -48,9 +48,13 @@
> #define OMAP3_SRAM_VA 0xfe400000
> #define OMAP3_SRAM_PUB_PA (OMAP3_SRAM_PA + 0x8000)
> #define OMAP3_SRAM_PUB_VA (OMAP3_SRAM_VA + 0x8000)
> -#define OMAP4_SRAM_VA 0xfe400000
> +#ifdef CONFIG_OMAP4_ERRATA_I688
> +#define OMAP4_SRAM_PUB_PA OMAP4_SRAM_PA
> +#define OMAP4_SRAM_PUB_VA OMAP4_SRAM_VA
> +#else
> #define OMAP4_SRAM_PUB_PA (OMAP4_SRAM_PA + 0x4000)
> #define OMAP4_SRAM_PUB_VA (OMAP4_SRAM_VA + 0x4000)
> +#endif
>
> #if defined(CONFIG_ARCH_OMAP2PLUS)
> #define SRAM_BOOTLOADER_SZ 0x00
> @@ -203,6 +207,11 @@ static void __init omap_map_sram(void)
> if (omap_sram_size == 0)
> return;
>
> +#ifdef CONFIG_OMAP4_ERRATA_I688
> + omap_sram_base += PAGE_SIZE;
> + omap_sram_start += PAGE_SIZE;
> + omap_sram_size -= SZ_16K;
> +#endif
> if (cpu_is_omap34xx()) {
> /*
> * SRAM must be marked as non-cached on OMAP3 since the
>
> Regards
> Santosh
^ permalink raw reply
* [PATCH 1/4] ARM: Add __arm_ioremap_exec for mapping external memory as MT_MEMORY
From: Santosh Shilimkar @ 2011-10-07 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111007181621.GJ6324@atomide.com>
On Friday 07 October 2011 11:46 PM, Tony Lindgren wrote:
> * Santosh Shilimkar <santosh.shilimkar@ti.com> [111007 10:05]:
>>
>> I initially tried some thing similar but the issue was GP and
>> HS devices. SRAM_PA isn't same on GP and EMU device and hence
>> did that dynamically. One way is I can make GP and HS
>> device SRAM_PA same for OMAP4 (Will loose 16 KB of
>> SRAM on OMAP4 GP). It's ok to loose that 16 KB SRAM
>> for OMAP4 with errata enabled.
>
> Oh yeah, the beginning is different too, I forgot that.
>
>> Below change works on both GP and HS device
>> If you are OK with it, I can update errata patch accordingly.
>
> OK to me to loose 16KB when the errata is enabled. That can
> be fixed later on for example by passing the SRAM area from
> device tree.
>
Yep.
> I assume now you can add the mapping to io.c instead? If so,
> then it's easier to apply the patches whatever way makes more
> sense.
>
io.c change I took as you suggested. The below change on top
of it. I just updated PM branch with this change.
Thanks for the tip. The errata code looks bit more clean
now. :)
Regards
Santosh
^ permalink raw reply
* [PATCH 1/4] ARM: Add __arm_ioremap_exec for mapping external memory as MT_MEMORY
From: Tony Lindgren @ 2011-10-07 18:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E8F42D4.7030502@ti.com>
* Santosh Shilimkar <santosh.shilimkar@ti.com> [111007 10:46]:
> On Friday 07 October 2011 11:46 PM, Tony Lindgren wrote:
>
> > I assume now you can add the mapping to io.c instead? If so,
> > then it's easier to apply the patches whatever way makes more
> > sense.
> >
> io.c change I took as you suggested. The below change on top
> of it. I just updated PM branch with this change.
>
> Thanks for the tip. The errata code looks bit more clean
> now. :)
OK thanks!
Tony
^ permalink raw reply
* [PATCHv2] hw_random: add driver for atmel true hardware random number generator
From: Herbert Xu @ 2011-10-07 18:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E8ECC15.10704@atmel.com>
On Fri, Oct 07, 2011 at 11:53:25AM +0200, Nicolas Ferre wrote:
> On 10/06/2011 07:56 PM, Peter Korsgaard :
> > For the IP block on 9g45/9g46/9m10/9m11.
> >
> > Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
>
> Thanks, I am delighted to see this driver!
>
> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>
> Herbert,
> I will handle the board specific part but should the driver part go
> through the Crypto API tree?
> Will you expect that I resend the patch with Jamie's and my signatures?
Feel free to add it through your tree.
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* ARM SoC tree: OMAP PM dependency on tip irq/core
From: Arnd Bergmann @ 2011-10-07 18:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87d3e8lmhp.fsf@ti.com>
On Friday 07 October 2011, Kevin Hilman wrote:
> > I've pulled in rmk/devel-stable as a dependency now, thanks for
> > reminding me of that.
> >
> > Thomas, where should I get the irq-core branch (or whichever
> > I should wait for) to pull in as another dependency. Is that
> > branch one that never gets rebased?
>
> git://tesla.tglx.de/git/linux-2.6-tip irq/core
>
> I asked Thomas about this earlier when I was going to build up the
> dependencies myself, and he said it won't be rebased.
Ok, thanks for the info.
I think I've now also come up with a workflow for tracking the dependencies:
I have a depends/xxx branch for each other branch that I need to wait for
getting merged first. When I want to send a pull request, I first check
all the depends/* branches using 'git branch --merged next/xxx |
grep depends' to see what the dependencies are, and 'git branch --merged
torvalds/master | grep depends' to see if they are already merged upstream.
When a dependency is already merged, I can remove its tracking branch
from the arm-soc tree.
Arnd
^ permalink raw reply
* ARM SoC tree: OMAP PM dependency on tip irq/core
From: Thomas Gleixner @ 2011-10-07 18:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201110072053.41594.arnd@arndb.de>
On Fri, 7 Oct 2011, Arnd Bergmann wrote:
> On Friday 07 October 2011, Kevin Hilman wrote:
> > > I've pulled in rmk/devel-stable as a dependency now, thanks for
> > > reminding me of that.
> > >
> > > Thomas, where should I get the irq-core branch (or whichever
> > > I should wait for) to pull in as another dependency. Is that
> > > branch one that never gets rebased?
> >
> > git://tesla.tglx.de/git/linux-2.6-tip irq/core
> >
> > I asked Thomas about this earlier when I was going to build up the
> > dependencies myself, and he said it won't be rebased.
>
> Ok, thanks for the info.
>
> I think I've now also come up with a workflow for tracking the dependencies:
> I have a depends/xxx branch for each other branch that I need to wait for
> getting merged first. When I want to send a pull request, I first check
> all the depends/* branches using 'git branch --merged next/xxx |
> grep depends' to see what the dependencies are, and 'git branch --merged
> torvalds/master | grep depends' to see if they are already merged upstream.
> When a dependency is already merged, I can remove its tracking branch
> from the arm-soc tree.
For your internal dependecies, yes. But for irq/core you don't have to
wait. You just need to tell Linus in the pull request that you pulled
my branch with my ack as it contains modifications which are
prerequisite for arm/whatever.
When I send my pull request later, then this wont do any damage as
Linus has the commits already. Same the other way round. We do that
all the time, otherwise pull dependencies would be a nightmare.
Thanks,
tglx
^ permalink raw reply
* [PATCH] ARM: mmp: map sram as MT_MEMORY rather than MT_DEVICE
From: Tony Lindgren @ 2011-10-07 19:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110822191335.3dbe99b9@debxo>
* Andres Salomon <dilinger@queued.net> [110822 18:40]:
> On Tue, 23 Aug 2011 01:07:55 +0100
> Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> [...]
> > > @@ -87,7 +88,8 @@ static int __devinit sram_probe(struct
> > > platform_device *pdev)
> > > info->sram_phys = (phys_addr_t)res->start;
> > > info->sram_size = resource_size(res);
> > > - info->sram_virt = ioremap(info->sram_phys,
> > > info->sram_size);
> > > + info->sram_virt = __arm_ioremap(info->sram_phys,
> > > info->sram_size,
> > > + MT_MEMORY);
> >
> > Not a good idea fiddling about under the covers like that. The reason
> > that MT_MEMORY is not in asm/io.h is to stop it being used like this -
> > MT_MEMORY etc are not meant for general purpose use.
> >
> > It needs to be looked at properly rather than working behind the APIs,
> > and making my life a misery by doing so, preventing me from making
> > changes where necessary by this kind of back-door use.
> >
> > I guess we need a new ioremap_xxx() variant to cope with this.
>
> Something like ioremap_exec()? I have no idea what the related MT_
> entry would be (as someone who's new to the ARM world, it's not
> entirely clear what the semantic distinctions are between the various
> MT_ entries).
Andres, care to ack this patch:
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7126/1
Looks like that should do what you want. And after the related
SRAM/map_io fixes for omap, it really seems that we could have
a generic SRAM driver..
Regards,
Tony
^ permalink raw reply
* [PATCH 1/3] ARM: mmp: add sram allocator
From: Tony Lindgren @ 2011-10-07 19:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAN1soZwz4Wj+rAqnLBGRqY0N2keFgxGYJw8sKEzsssjhLn-gSw@mail.gmail.com>
* Haojian Zhuang <haojian.zhuang@gmail.com> [110815 01:57]:
> On Mon, Aug 15, 2011 at 5:09 PM, Jean-Christophe PLAGNIOL-VILLARD
> <plagnioj@jcrosoft.com> wrote:
> > On 10:59 Mon 15 Aug ? ? , Arnd Bergmann wrote:
> >> On Monday 15 August 2011 11:09:52 Leo Yan wrote:
> >> > On mmp platform, there have two sram banks:
> >> > audio sram and internal sram. The audio sram is mainly for audio;
> >> > the internal sram is for video, wtm and power management.
> >> > So add the sram allocator using genalloc to manage them.
> >> >
> >> > Every sram bank will register its own platform device
> >> > info, after the sram allocator create the generic pool
> >> > for the sram bank, the user module can use the pool's
> >> > name to get the pool handler; then it can use the handler
> >> > to alloc/free memory with genalloc APIs.
> >> >
> >> > Signed-off-by: Leo Yan <leoy@marvell.com>
> >> > ---
> >> > ?arch/arm/Kconfig ? ? ? ? ? ? ? ? ? ? ?| ? ?1 +
> >> > ?arch/arm/mach-mmp/Makefile ? ? ? ? ? ?| ? ?2 +-
> >> > ?arch/arm/mach-mmp/include/mach/sram.h | ? 35 +++++++
> >> > ?arch/arm/mach-mmp/sram.c ? ? ? ? ? ? ?| ?168 +++++++++++++++++++++++++++++++++
> >> > ?4 files changed, 205 insertions(+), 1 deletions(-)
> >> > ?create mode 100644 arch/arm/mach-mmp/include/mach/sram.h
> >> > ?create mode 100644 arch/arm/mach-mmp/sram.c
> >>
> >> Some time ago, there was talk of merging the existing sram drivers
> >> and creating a common driver that is easy to hook into.
> >>
> >> What has happened with that? My feeling is that we should stop adding
> >> more drivers like this in the platform code but rather put an
> >> authoritative copy into arch/arm/mm/ or even the top-level mm/ directory
> >> and change over the existing drivers to hook into that one.
> > no need anymore I send patch to add the support of phys/virt to genalloc so
> > now we just have to use it
> >
> > Best Regards,
> > J.
> >
> Exactly, and Russel already gave up on original patch. genpool is already a
> common driver.
Yeah but it seems that we can make arch/arm/mach-mmp/sram.c posted
in this thread a generic driver instead.
Regards,
Tony
^ permalink raw reply
* [PATCH 1/4] mmc: mmci: Bugfix in pio read for small packets
From: Russell King - ARM Linux @ 2011-10-07 19:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E8F00E4.5010702@stericsson.com>
On Fri, Oct 07, 2011 at 03:38:44PM +0200, Ulf Hansson wrote:
> In this hot path we already do a read of the FIFOCNT register for every
> loop in pio_read, won't this sometimes cause caches to flush and
> similar, thus cost quite a lot - at least a lot more than executing a
> switch/if sentence like Stefan added? Or do I miss something?
The read of FIFOCNT just reads the counter and does nothing more. Why
do you think it causes a cache flush, and what cache do you think would
be flushed?
> I were also thinking of a possible optimization of minimizing the total
> numbers of reads of the FIFOCNT register in pio_read. Basically we can
> make use of the RXFIFOHALFFULL irq/status to know when there is a
> "burst" available in the FIFO. Do you think this will be feasible for
> the ARM MMCI Pl18x IP as well? I mean the consequence of using
> RXFIFOHALFFULL will be less numbers of IRQ raised and then when reading
> data from the FIFO it will be done in larger chunks.
We read the FIFOCNT register to allow us to empty as much data from the
FIFO as we possibly can at each interrupt. We know that it's going to
be at least half full at that time because that's the interrupt which is
triggering us to do the read (except for the final few words). What we
want to do is not just read half the FIFO, but everything that it
contains. Hence why we read FIFOCNT.
> We could make use of the "likely" makro to make compiler optimizations
> of the code, is that a way forward do you think?
That only helps if you look at the assembled code and inspect what the
compiler is doing. If it's already correctly guessing the best paths,
then the likely macro does nothing for you.
But first, you need to fix your code so you're only reading 32-bit
quantities from the FIFO register.
^ permalink raw reply
* [GIT PULL] omap fixes for -rc series and merge window
From: Arnd Bergmann @ 2011-10-07 19:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111003185237.GI6324@atomide.com>
On Monday 03 October 2011, Tony Lindgren wrote:
> Please pull omap fixes from:
>
> git://github.com/tmlind/linux.git fixes
>
> Out of these the first three commits would be nice to get
> into the -rc series with the first two causing boot issues
> and the musb fixing an ugly warning.
>
> Note however the recent commit message update on the third patch.
> I added Bjarne's SOB to the third patch because of the earlier
> reference.
>
> The last two are mostly cosmetic and not so urgent.
Hi Tony,
I've pulled them all into the fixes branch for now, but I'm not sure
if I still want to send another pull request. If I do, I'll have to
rebase that branch and put some into the next/fixes branch instead
as I already have patches that I don't want to send for 3.1 any
more. Are the patches all fixes against 3.1 only or do some of them
also apply to older releases?
Arnd
^ permalink raw reply
* [GIT PULL] Samsung devel-2 for v3.2
From: Mark Brown @ 2011-10-07 19:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201110071956.12034.arnd@arndb.de>
On Fri, Oct 07, 2011 at 07:56:11PM +0200, Arnd Bergmann wrote:
> On Monday 03 October 2011, Kukjin Kim wrote:
> > Mark Brown wrote:
> > > As I reported the other day this change breaks the boot early on on the
> > > Cragganmore S3C6410 based systems (I've not actually fired up my
> > > SMDK6410 but I suspect it may have issues too). I did make some brief
> > Hmm, I thought it has no problem when I saw Thomas Abraham's 'serial:
> > samsung' patches because he said it works fine with my for-next plus his
> > patches on SMDK6410...Anyway, I need to sort it out.
> > Arnd, please hold this on, will request again soon.
> Any update on this?
We've got a lot closer to working out what's wrong (and got useful
logging) but not nailed it down yet. Kukjin has confirmed that he can
see what's likely the same issue on his systems. My suggestion is that
we go ahead with the pull request for now and then fix incrementally,
there's a relatively small set of systems affected. If it gets to more
than a couple of -rcs we know which patches are problematic and so can
always revert.
^ permalink raw reply
* [PATCH v3] omap: dmtimer: convert printk to pr_err
From: Russell King - ARM Linux @ 2011-10-07 19:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318009239.1644.38.camel@Joe-Laptop>
On Fri, Oct 07, 2011 at 10:40:39AM -0700, Joe Perches wrote:
> At some point in the next couple of years, I want
> to convert all of, or as many as possible of, the
> remaining printk uses to pr_<level>.
If the idea is also to get rid of printk() too (which IMHO would be a
good thing as it kills off the constant need to continually patch for
missing KERN_ prefixes) then that's a good reason (provided Linus
accepts the idea.) At that point having such patches as part of a
progressive series of patches also makes sense.
Doing it piecemeal when we've already had frequent complaints from
Linus about useless churn with no apparant reasoning behind it doesn't
help relieve us of those accusations.
^ permalink raw reply
* [GIT PULL] omap fixes for -rc series and merge window
From: Tony Lindgren @ 2011-10-07 19:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201110072111.35418.arnd@arndb.de>
* Arnd Bergmann <arnd@arndb.de> [111007 11:37]:
> On Monday 03 October 2011, Tony Lindgren wrote:
> > Please pull omap fixes from:
> >
> > git://github.com/tmlind/linux.git fixes
> >
> > Out of these the first three commits would be nice to get
> > into the -rc series with the first two causing boot issues
> > and the musb fixing an ugly warning.
> >
> > Note however the recent commit message update on the third patch.
> > I added Bjarne's SOB to the third patch because of the earlier
> > reference.
> >
> > The last two are mostly cosmetic and not so urgent.
>
> Hi Tony,
>
> I've pulled them all into the fixes branch for now, but I'm not sure
> if I still want to send another pull request. If I do, I'll have to
> rebase that branch and put some into the next/fixes branch instead
> as I already have patches that I don't want to send for 3.1 any
> more. Are the patches all fixes against 3.1 only or do some of them
> also apply to older releases?
Thanks. Well we can certainly manage if the first three commits did
not make it in during the -rc cycle. But assuming that we had valid
fixes, you could just do something like this too:
$ git checkout -b omap/fixes-for-rc
$ git reset --hard b8e111a74d281b70e88bd67fec48cfda4f9bdce2
...
Then merge all the -rc fixes for various ARM platforms with:
$ git checkout fixes-for-rc
$ git reset --hard v3.1-rc9
$ git merge omap/fixes-for-rc soc foo/fixes-for-rc bar/fixes-for-rc
And then no rebasing is needed. Of course I could also set up
a separate fixes-for-rc for that if you prefrer that :)
Regards,
Tony
^ permalink raw reply
* [PATCH 1/5 v4] ARM Realview PCIX map include file changes
From: Russell King - ARM Linux @ 2011-10-07 19:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111007142723.19554.88566.stgit@e102602-lin.cambridge.arm.com>
On Fri, Oct 07, 2011 at 03:27:47PM +0100, Colin Tuckley wrote:
> -#define IO_SPACE_LIMIT 0xffffffff
> +#include <asm/mach-types.h>
> +#include <mach/hardware.h>
> +
> +#define IO_SPACE_LIMIT 0x0000ffff
Does this in asm/io.h:
#ifndef IO_SPACE_LIMIT
#if defined(CONFIG_PCMCIA_SOC_COMMON) || defined(CONFIG_PCMCIA_SOC_COMMON_MODULE)
#define IO_SPACE_LIMIT ((resource_size_t)0xffffffff)
#elif defined(CONFIG_PCI) || defined(CONFIG_ISA) || defined(CONFIG_PCCARD)
#define IO_SPACE_LIMIT ((resource_size_t)0xffff)
#else
#define IO_SPACE_LIMIT ((resource_size_t)0)
#endif
#endif
not work here for some reason? I think as PCMCIA_SOC_COMMON would not be
defined, but CONFIG_PCI would be, it'd give the correct answer. Please
confirm.
^ permalink raw reply
* [PATCH] OMAP2+: clock: use clock's recalc in DPLL handling
From: Turquette, Mike @ 2011-10-07 19:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1110070104260.4611@utopia.booyaka.com>
On Fri, Oct 7, 2011 at 12:07 AM, Paul Walmsley <paul@pwsan.com> wrote:
> On Thu, 29 Sep 2011, Mike Turquette wrote:
>
>> Not all DPLLs are identical; some require special consideration such as
>> OMAP4's ABE DPLL, which can have an additional 4x multiplier added to
>> it's clock rate based on programming the REGM4XEN bit in it's CLKMODE
>> register.
>>
>> Unfortunately the clock framework makes a few assumptions that all DPLLs
>> can have their rates calculated the same way which has led to incorrect
>> rates for OMAP4's DPLL_ABE in some cases. ?This patch fixes the same by
>> replacing explicit calls to omap2_dpll_get_rate with clk->recalc if
>> .recalc is populated for a clock. ?If .recalc is NULL then fall back to
>> omap2_dpll_get_rate.
>>
>> Reported-by: Misael Lopez Cruz <misael.lopez@ti.com>
>> Signed-off-by: Mike Turquette <mturquette@ti.com>
>
> I've merged this patch with Jon's "ARM: OMAP3+: dpll: use DPLLs recalc
> function instead of omap2_get_dpll_rate" patch, which does almost exactly
> the same thing, just without the conditionals on clk->recalc. ?Updated
> patch below. ?Please let me know if you think I should change anything
> about the changelog.
Heh, I hadn't realized we had overlapping patches like that. Looks fine to me.
Regards,
Mike
> - Paul
>
> From: Jon Hunter <jon-hunter@ti.com>
> Date: Fri, 7 Oct 2011 00:53:01 -0600
> Subject: [PATCH] ARM: OMAP3+: dpll: use DPLLs recalc function instead of
> ?omap2_get_dpll_rate
>
> This is a continuation of Mike Turquette's patch "OMAP3+: use
> DPLL's round_rate when setting rate".
>
> omap3_noncore_dpll_set_rate() and omap3_noncore_dpll_enable() call
> omap2_get_dpll_rate() explicitly. It may be necessary for some
> DPLLs to use a different function and so use the DPLLs recalc()
> function pointer instead.
>
> An example is the DPLL_ABE on OMAP4 which can have a 4X multiplier
> in addition to the usual MN multipler and dividers and therefore
> uses a different round_rate and recalc function.
>
> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
> Cc: Mike Turquette <mturquette@ti.com>
> Cc: Misael Lopez Cruz <misael.lopez@ti.com>
> [paul at pwsan.com: merged this patch with Mike's "use clock's recalc in DPLL
> ?handling" patch; also reported by Misael]
> Signed-off-by: Paul Walmsley <paul@pwsan.com>
> ---
> ?arch/arm/mach-omap2/dpll3xxx.c | ? ?7 +++++--
> ?1 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
> index 73a1595..fc56745 100644
> --- a/arch/arm/mach-omap2/dpll3xxx.c
> +++ b/arch/arm/mach-omap2/dpll3xxx.c
> @@ -390,7 +390,8 @@ int omap3_noncore_dpll_enable(struct clk *clk)
> ? ? ? ? * propagating?
> ? ? ? ? */
> ? ? ? ?if (!r)
> - ? ? ? ? ? ? ? clk->rate = omap2_get_dpll_rate(clk);
> + ? ? ? ? ? ? ? clk->rate = (clk->recalc) ? clk->recalc(clk) :
> + ? ? ? ? ? ? ? ? ? ? ? omap2_get_dpll_rate(clk);
>
> ? ? ? ?return r;
> ?}
> @@ -424,6 +425,7 @@ void omap3_noncore_dpll_disable(struct clk *clk)
> ?int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned long rate)
> ?{
> ? ? ? ?struct clk *new_parent = NULL;
> + ? ? ? unsigned long hw_rate;
> ? ? ? ?u16 freqsel = 0;
> ? ? ? ?struct dpll_data *dd;
> ? ? ? ?int ret;
> @@ -435,7 +437,8 @@ int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned long rate)
> ? ? ? ?if (!dd)
> ? ? ? ? ? ? ? ?return -EINVAL;
>
> - ? ? ? if (rate == omap2_get_dpll_rate(clk))
> + ? ? ? hw_rate = (clk->recalc) ? clk->recalc(clk) : omap2_get_dpll_rate(clk);
> + ? ? ? if (rate == hw_rate)
> ? ? ? ? ? ? ? ?return 0;
>
> ? ? ? ?/*
> --
> 1.7.6.3
>
>
^ permalink raw reply
* [PATCH 0/7] Repost of omap SRAM map_io changes
From: Tony Lindgren @ 2011-10-07 19:45 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
Here's a repost of the original patches with minimal changes
to fix some compile warnings and with the acks added.
There's also one new patch to warn about trying to use the
omap_ioremap too early that's good to have for some sanity
checks.
These patches are against the dt branch in linux-omap tree
because of dependencies to earlier cleanup.
Regards,
Tony
---
Tony Lindgren (7):
ARM: Add __arm_ioremap_exec for mapping external memory as MT_MEMORY
ARM: OMAP1: Use generic map_io, init_early and init_irq
ARM: OMAP: Avoid cpu_is_omapxxxx usage until map_io is done
ARM: OMAP: Remove calls to SRAM allocations for framebuffer
ARM: OMAP: Map SRAM later on with ioremap_exec()
ARM: OMAP: Move set_globals initialization to happen in init_early
ARM: OMAP: Warn if omap_ioremap is called before SoC detection
arch/arm/include/asm/io.h | 1
arch/arm/mach-omap1/board-ams-delta.c | 16 +---
arch/arm/mach-omap1/board-fsample.c | 76 +++++++++---------
arch/arm/mach-omap1/board-generic.c | 16 +---
arch/arm/mach-omap1/board-h2.c | 16 +---
arch/arm/mach-omap1/board-h3.c | 16 +---
arch/arm/mach-omap1/board-htcherald.c | 12 +--
arch/arm/mach-omap1/board-innovator.c | 36 ++++-----
arch/arm/mach-omap1/board-nokia770.c | 34 +++-----
arch/arm/mach-omap1/board-osk.c | 16 +---
arch/arm/mach-omap1/board-palmte.c | 16 +---
arch/arm/mach-omap1/board-palmtt.c | 16 +---
arch/arm/mach-omap1/board-palmz71.c | 18 +---
arch/arm/mach-omap1/board-perseus2.c | 75 +++++++++---------
arch/arm/mach-omap1/board-sx1.c | 17 +---
arch/arm/mach-omap1/board-voiceblue.c | 16 +---
arch/arm/mach-omap1/devices.c | 3 +
arch/arm/mach-omap1/io.c | 57 ++++++-------
arch/arm/mach-omap2/board-omap3beagle.c | 7 --
arch/arm/mach-omap2/board-ti8168evm.c | 1
arch/arm/mach-omap2/common.c | 50 +++++-------
arch/arm/mach-omap2/control.c | 14 +--
arch/arm/mach-omap2/io.c | 127 +++++++++++++++---------------
arch/arm/mach-omap2/io.h | 7 --
arch/arm/mach-omap2/omap-smp.c | 7 +-
arch/arm/mach-omap2/prcm.c | 19 +---
arch/arm/mach-omap2/sdrc.c | 13 +--
arch/arm/mm/ioremap.c | 21 +++++
arch/arm/plat-omap/include/plat/common.h | 17 ++--
arch/arm/plat-omap/include/plat/io.h | 29 ++++++-
arch/arm/plat-omap/io.c | 10 ++
arch/arm/plat-omap/sram.c | 85 +++++---------------
32 files changed, 356 insertions(+), 508 deletions(-)
--
Signature
^ 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