* [PATCH V3 0/3] ARM: dts: omap5: EMIF and LPDDR2 device tree data
From: Benoit Cousson @ 2012-11-05 17:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352119972-13710-1-git-send-email-lokeshvutla@ti.com>
Hi Lokesh,
On 11/05/2012 01:52 PM, Lokesh Vutla wrote:
> This patch series adds Device tree data for the EMIF
> sdram controllers in OMAP5 and LPDDR2 memory devices
> in OMAP5-evm board.
>
> Testing:
> - Boot tested on OMAP5430 evm.
> - Built EMIF as a module.
>
> Changes from v2:
> * Rebased on top of
> git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.8/dts
> * Addressed few other comments from Benoit.
Thanks for this quick update.
I've just applied your series in my for_3.8/dts_part2 branch.
Regards,
Benoit
^ permalink raw reply
* [PATCH] ARM: decompressor: clear SCTLR.A bit for v7 cores
From: Nicolas Pitre @ 2012-11-05 17:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121105172624.GE2005@linaro.org>
On Mon, 5 Nov 2012, Dave Martin wrote:
> On Mon, Nov 05, 2012 at 11:13:51AM -0500, Nicolas Pitre wrote:
> > On Mon, 5 Nov 2012, Russell King - ARM Linux wrote:
> >
> > > On Mon, Nov 05, 2012 at 01:02:55PM +0000, Dave Martin wrote:
> > > > Why not allow unaligned accesses in the decompressor, though, both
> > > > for v6 and v7?
> > >
> > > EXACTLY.
> >
> > I have no objections to that. In fact, I made a remark to this effect
> > in my initial review of this patch. Whether or not gcc does take
> > advantage of this hardware ability in the end is orthogonal.
>
> For the sake of argument, here's how it might look.
>
> Currently, I make no attempt to restore the original state of the U bit.
> The A bit if forced later by the kernel during boot, after a short window
> during which we should only run low-level arch code and therefore where
> no unaligned accesses should happen.
>
> Does anyone think these issues are likely to be important?
>
> Cheers
> ---Dave
>
>
> >From 160a5576b53264951ff8164775146b2d4feddecb Mon Sep 17 00:00:00 2001
> From: Dave Martin <dave.martin@linaro.org>
> Date: Mon, 5 Nov 2012 16:34:57 +0000
> Subject: [PATCH] ARM: decompressor: Enable unaligned memory access for v6 and above
>
> Modern GCC can generate code which makes use of the CPU's native
> unaligned memory access capabilities. This is useful for the C
> decompressor implementations used for unpacking compressed kernels.
>
> This patch disables the alignment faults and enabled the v6
> unaligned access on CPUs which support these features (i.e., v6 and
> later), allowing full unaligned access support for C code in the
> decompressor.
>
> The decompressor C code must not be built to assume that unaligned
> access works if support for v5 or older platforms is included in
> the kernel.
I'd suggest here that the code must always use the get_unaligned and
put_unaligned accessors when dealing with unaligned pointers, regardless
of this patch. The compiler will optimize the access performed via
those accessors when possible.
> Signed-off-by: Dave Martin <dave.martin@linaro.org>
Acked-by: Nicolas Pitre <nico@linaro.org>
> ---
> Note: I have only build-tested this so far.
>
> arch/arm/boot/compressed/head.S | 12 +++++++++++-
> 1 files changed, 11 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
> index 90275f0..cfbb4c9 100644
> --- a/arch/arm/boot/compressed/head.S
> +++ b/arch/arm/boot/compressed/head.S
> @@ -652,6 +652,15 @@ __setup_mmu: sub r3, r4, #16384 @ Page directory size
> mov pc, lr
> ENDPROC(__setup_mmu)
>
> +@ Enable unaligned access on v6, to allow better code generation
> +@ for the decompressor C code:
> +__armv6_mmu_cache_on:
> + mrc p15, 0, r0, c1, c0, 0 @ read SCTLR
> + bic r0, r0, #2 @ A (no unaligned access fault)
> + orr r0, r0, #1 << 22 @ U (v6 unaligned access model)
> + mcr p15, 0, r0, c1, c0, 0 @ write SCTLR
> + b __armv4_mmu_cache_on
> +
> __arm926ejs_mmu_cache_on:
> #ifdef CONFIG_CPU_DCACHE_WRITETHROUGH
> mov r0, #4 @ put dcache in WT mode
> @@ -694,6 +703,7 @@ __armv7_mmu_cache_on:
> bic r0, r0, #1 << 28 @ clear SCTLR.TRE
> orr r0, r0, #0x5000 @ I-cache enable, RR cache replacement
> orr r0, r0, #0x003c @ write buffer
> + bic r0, r0, #2 @ A (no unaligned access fault)
> #ifdef CONFIG_MMU
> #ifdef CONFIG_CPU_ENDIAN_BE8
> orr r0, r0, #1 << 25 @ big-endian page tables
> @@ -914,7 +924,7 @@ proc_types:
>
> .word 0x0007b000 @ ARMv6
> .word 0x000ff000
> - W(b) __armv4_mmu_cache_on
> + W(b) __armv6_mmu_cache_on
> W(b) __armv4_mmu_cache_off
> W(b) __armv6_mmu_cache_flush
>
> --
> 1.7.4.1
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH v2] arm: mvebu: support for the PlatHome OpenBlocks AX3-4 board
From: Olof Johansson @ 2012-11-05 17:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351107203-31808-1-git-send-email-thomas.petazzoni@free-electrons.com>
On Wed, Oct 24, 2012 at 09:33:23PM +0200, Thomas Petazzoni wrote:
> + compatible = "plathome,openblocks-ax3-4", "marvell,armadaxp-mv78260", "marvell,armadaxp", "marvell,armada-370-xp";
[...]
> diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-mvebu/armada-370-xp.c
> index 49d7915..68f1483 100644
> --- a/arch/arm/mach-mvebu/armada-370-xp.c
> +++ b/arch/arm/mach-mvebu/armada-370-xp.c
> @@ -49,6 +49,7 @@ static void __init armada_370_xp_dt_init(void)
> static const char * const armada_370_xp_dt_board_dt_compat[] = {
> "marvell,a370-db",
> "marvell,axp-db",
> + "plathome,openblocks-ax3-4",
> NULL,
> };
Hi,
One of the big benefits of device trees is to, in a perfect world, having to avoid
adding new C code for a new board. It seems like this compatible array should
contain one of the more generic compatible fields instead, and you should then
have each board dts specify that as a fallback. It looks like you already list
those in the board dts file, so you're good at that end.
Would that work?
Also, I can't tell for sure but it seems like the list of compatibles in the
board dts go from specific to generic, i.e. if "marvell,armadaxp" is less
generic than "marvell,armada-370-xp".
-Olof
^ permalink raw reply
* vexpress issues in next-20121029
From: Arnd Bergmann @ 2012-11-05 17:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352135973.10947.23.camel@hornet>
On Monday 05 November 2012, Pawel Moll wrote:
> On Mon, 2012-11-05 at 16:47 +0000, Arnd Bergmann wrote:
> > I've just tried pulling in your branch again, but it appears unchanged:
> > The patches are still based on 807e45b328, which is a different commit
> > from bcd6f569e874 that is in Mike's tree. Please do as I asked you before
> > and rebase on top of the commit that you sent him,
>
> Ok, I think I got the idea now. Sorry about not catching up straight
> away...
>
> The following changes since commit bcd6f569e87471d7f104bd9497f0b516a3b12e32:
>
> clk: Common clocks implementation for Versatile Express (2012-10-29 11:08:03 -0700)
>
> are available in the git repository at:
>
> git://git.linaro.org/people/pawelmoll/linux.git vexpress-clk-soc
>
> for you to fetch changes up to 433683a66401adb0150792e725cc4f631c94de46:
Ok, thanks!
I've put it into the next/soc2 branch now, separate from the earlier next/soc
branch, since we now have a dependency on another branch.
> ARM: vexpress: Remove motherboard dependencies in the DTS files (2012-11-05 17:09:52 +0000)
>
> > and make sure that this is a commit that Mike never rebases.
>
> Uh. Mike, is your clk-next subject to rebases?
On a related note, there are other patches below this one now:
clk: Common clocks implementation for Versatile Express
clk: Versatile Express clock generators ("osc") driver
CLK: clk-twl6040: Initial clock driver for OMAP4+ McPDM fclk clock
clk: fix return value check in sirfsoc_of_clk_init()
clk: fix return value check in of_fixed_clk_setup()
clk: ux500: Update sdmmc clock to 100MHz for u8500
clk: ux500: Support prcmu ape opp voltage clock
mfd: dbx500: Export prmcu_request_ape_opp_100_voltage
clk: Don't return negative numbers for unsigned values with !clk
clk: Fix documentation typos
clk: Document .is_enabled op
clk: SPEAr: Vco-pll: Fix compilation warning
Mike, do you prefer us to wait for those to make it into v3.8-rc1 before
pushing the patches from Pawel, or can we just send the entire branch
along with the other changes?
FWIW, there is a way to avoid dependencies like this if the patches that
are required in two branches are based directly on an -rc release and
then merged into the two maintainer trees, rather than having one maintainer
tree pull in (part of) the history of another one.
Arnd
^ permalink raw reply
* [PATCH 04/15] ARM: OMAP2+: hwmod: Update the reset API for AM33XX
From: Bedia, Vaibhav @ 2012-11-05 17:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5097639C.7000800@ti.com>
On Mon, Nov 05, 2012 at 12:28:36, Hiremath, Vaibhav wrote:
[...]
> > - u32 mask = 1 << shift;
> > -
> > - /* Check the current status to avoid de-asserting the line twice */
> > - if (am33xx_prm_is_hardreset_asserted(shift, inst, rstctrl_offs) == 0)
> > - return -EEXIST;
>
> Any specific reason why you have removed this check?
During bootup the hardreset line is asserted, so wouldn't that check lead
to the function always returning without doing anything?
Regards,
Vaibhav
^ permalink raw reply
* [PATCH 06/15] ARM: OMAP2+: hwmod: Enable OCMCRAM registration in AM33XX
From: Bedia, Vaibhav @ 2012-11-05 17:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5097698F.1080609@ti.com>
On Mon, Nov 05, 2012 at 12:53:59, Hiremath, Vaibhav wrote:
>
> Can you cut-n-paste the ocmcram hwmod entry outside of #if and resubmit
> it again?
>
Ok. Will do that in the next version.
Regards,
Vaibhav
^ permalink raw reply
* [PATCH 13/15] ARM: DTS: AM33XX: Add nodes for OCMCRAM and Mailbox
From: Bedia, Vaibhav @ 2012-11-05 17:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5097D2D7.3090204@ti.com>
On Mon, Nov 05, 2012 at 20:23:11, Shilimkar, Santosh wrote:
[...]
> >
> On OMAP the OCMC RAM is always clocked and doesn't need any special
> clock enable. CM_L3_2_OCMC_RAM_CLKCTRL module mode field is read only.
> Isn't it same on AMXX ?
>
On AM33xx, OCMC RAM is in PER domain and the corresponding CLKCLTR module
mode fields are r/w. OCMC RAM needs to be disabled as part of the DeepSleep0
entry to let PER domain transition.
Regards,
Vaibhav
^ permalink raw reply
* [PATCH v3 0/6] DT support for AT91RM9200
From: Joachim Eastwood @ 2012-11-05 17:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121105072857.GL19021@game.jcrosoft.org>
On 5 November 2012 08:28, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
> On 18:55 Sun 04 Nov , Joachim Eastwood wrote:
>> On 4 November 2012 16:52, Jean-Christophe PLAGNIOL-VILLARD
>> <plagnioj@jcrosoft.com> wrote:
>> > On 19:31 Sun 28 Oct , Joachim Eastwood wrote:
>> >> Patch 1 is a fix for a build failure which can happen if board-dt is enabled when no AT91SAM machines are enabled.
>> >>
>> >> Patch 2 adds DT support to the AT91RM9200 system timer. Based on AT91 PIT patch by Jean-Christophe PLAGNIOL-VILLARD.
>> >>
>> >> Patch 3 adds clock lookups for DT.
>> >>
>> >> Patch 4 adds a new board for RM9200 DT support.
>> >>
>> >> Patch 5-6 adds the base devicetree for AT91RM9200 and support for AT91RM9200-EK board.
>> >>
>> >>
>> >> I don't have a AT91RM9200-EK to test on but I was able to boot at91rm9200ek.dts on my custom board using a >>initrd. As far as I can tell pinctrl, usart and ohci all work.
>> >
>> > After updating barebox to have the DT support I've tested it on rm9200ek with net support
>> >
>> > work fine
>>
>> Excellent.
>>
>> > It does not apply on my tree as I've a more patch but I'll manage the merge
>> > conflict
>>
>> Thanks for fixing it up Jean-Christophe.
> I'll also fix the usb device and add missing nor flash support and emac +
> pinctrl + defconfig
Very nice.
Please make the changes available via a git tree when it's ready.
regards
Joachim Eastwood
^ permalink raw reply
* [PATCH 11/15] ARM: OMAP: timer: Interchange clksrc and clkevt for AM33XX
From: Kevin Hilman @ 2012-11-05 18:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <B5906170F1614E41A8A28DE3B8D121433EBFEB57@DBDE01.ent.ti.com>
"Bedia, Vaibhav" <vaibhav.bedia@ti.com> writes:
> On Sat, Nov 03, 2012 at 18:34:30, Kevin Hilman wrote:
> [...]
>> >>
>> >> Doesn't this also mean that you won't get timer wakeups
>> >> in idle? Or are you keeping the domain where the clockevent is
>> >> on during idle?
>> >>
>> >
>> > The lowest idle state that we are targeting will have MPU powered
>> > off with external memory in self-refresh mode. Peripheral domain
>> > with the clockevent will be kept on.
>>
>> Is this a limitation of the hardware? or the software?
>>
>
> Well, making the lowest idle state same as the suspend state will
> require us to involve WKUP_M3 in the idle path and wakeup sources get
> limited to the IPs in the WKUP domain alone. There's no IO daisy
> chaining in AM33XX so that's one big difference compared to OMAP. The
> other potential problem is that the IPC mechanism that we have uses
> interrupts.
It can still interrupt the M3, it's only the interrupt back to the MPU
that is the issue, right? That being said, there's no reason it
couldn't use polling in the idle path, right?
> Assuming that the lowest idle state, say Cx, is the same as the
> suspend state, we'll need to communicate with the WKUP_M3 using
> interrupts once we decide to enter Cx. I am not sure if we can do
> something in the cpuidle implementation to work around the "interrupt
> for idle" problem.
>
> We could probably not wait for an ACK when we want to enter Cx,
why not?
Are the response times from the M3 really up to 500ms (guessing based on
the timeout you used in the suspend path.) That seems rather unlikely.
Hmm, but as I think about it. Why does the MPU need to wait for an ACK
at all? Why not just send the cmd and WFI?
> but the problem of limited wakeup sources remains. If we let the
> various drivers block the entry to Cx, since almost all the IPs are in
> the peripheral domain a system which uses anything other than UART and
> Timer in WKUP domain will probably never be able enter Cx.
Even so, I think the system needs to be designed to hit the same power
states in idle and suspend. Then, the states can be restricted based
wakeup capabilities as you described. This would be easy to do in the
runtime PM implementation for this device.
IMO, assuming that idle will not be useful from the begining is leading
down the path to poor design choices that will be much more difficult to
fixup down the road in order to add idle support later. We need to
design both idle and suspend at the same time.
Also, don't forget about GPIO0. Systems could easily be built such that
peripherals which want to wakeup but don't have native wakeup
capabilities could use a GPIO in bank 0 to wake the system.
Similarily, I2C0 is in WKUP, and brought out to capes, so some simple
designs with with I2C devices on a cape might be perfectly capable of
hitting deep power states in idle.
Kevin
^ permalink raw reply
* Building for MMU-less vexpress targets
From: Pawel Moll @ 2012-11-05 18:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121105173640.GR3351@mudshark.cambridge.arm.com>
On Mon, 2012-11-05 at 17:36 +0000, Will Deacon wrote:
> I'm inclined to add a dummy VEXPRESS entry to arm/Kconfig which depends on
> !ARCH_MULTIPLATFORM and just selects ARCH_VEXPRESS (with the if ARCH_MULTI_V7
> dependency dropped)
... depends on !ARCH_MULTIPLATFORM or maybe rather !MMU? (I assume you
want to add an extra dummy position in the choice section, where options
are mutually exclusive anyway?)
Pawe?
^ permalink raw reply
* [GIT PULL 1/3] omap plat header removal for v3.8 merge window, part2
From: Olof Johansson @ 2012-11-05 18:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508affc9.8f07320a.16f0.0ac0SMTPIN_ADDED@mx.google.com>
On Fri, Oct 26, 2012 at 02:23:39PM -0700, Tony Lindgren wrote:
> The following changes since commit 3e9a6321f9895eac9a3d241d3126e44021e7102b:
>
> Merge tag 'omap-for-v3.8/cleanup-headers-signed' into omap-for-v3.8/cleanup-headers-serial-take2 (2012-10-24 13:25:44 -0700)
>
> are available in the git repository at:
>
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.8/cleanup-headers-serial-take2-signed
>
> for you to fetch changes up to 3d82cbbb3aadb4f8a30e3f614e51be96574a0855:
>
> ARM: OMAP: Split plat/serial.h for omap1 and omap2+ (2012-10-24 13:34:31 -0700)
>
> ----------------------------------------------------------------
> These changes remove plat/serial.h usage for omap2+.
>
> Note that this branch is based on a tty commit 3e9a6321
> (tty/serial/8250: Make omap hardware workarounds local to 8250.h)
> merged with omap-for-v3.8/cleanup-headers-signed.
>
> The tty commit is needed to keep things compiling for omaps,
> and omap-for-v3.8/cleanup-headers-signed is needed to avoid
> multiple merge conflicts with the includes. I've verified
> with Greg KH that the tty commit above is immutable and OK
> to use as a base.
Thanks, pulled into next/headers, and I kept an explicit dependency on Greg's
tree as depends/tty so we can keep track of it.
-Olof
^ permalink raw reply
* vexpress issues in next-20121029
From: Pawel Moll @ 2012-11-05 18:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201211051752.08400.arnd@arndb.de>
On Mon, 2012-11-05 at 17:52 +0000, Arnd Bergmann wrote:
> Mike, do you prefer us to wait for those to make it into v3.8-rc1 before
> pushing the patches from Pawel, or can we just send the entire branch
> along with the other changes?
Or, maybe, you prefer to remove the vexpress patches from clk-next
completely (if it is to be rebased) and let them go only through
arm-soc? (just asking)
Pawe?
^ permalink raw reply
* Building for MMU-less vexpress targets
From: Will Deacon @ 2012-11-05 18:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352138600.10947.26.camel@hornet>
On Mon, Nov 05, 2012 at 06:03:20PM +0000, Pawel Moll wrote:
> On Mon, 2012-11-05 at 17:36 +0000, Will Deacon wrote:
> > I'm inclined to add a dummy VEXPRESS entry to arm/Kconfig which depends on
> > !ARCH_MULTIPLATFORM and just selects ARCH_VEXPRESS (with the if ARCH_MULTI_V7
> > dependency dropped)
>
> ... depends on !ARCH_MULTIPLATFORM or maybe rather !MMU? (I assume you
> want to add an extra dummy position in the choice section, where options
> are mutually exclusive anyway?)
Yeah, you could do something like the following but it just feels a bit
nasty:
Will
--->8
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 335e220..0561d87 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -305,6 +305,11 @@ config ARCH_REALVIEW
help
This enables support for ARM Ltd RealView boards.
+config ARCH_VEXPRESS_NOMMU
+ bool "ARM Ltd. Versatile Express family (nommu)"
+ depends on !MMU
+ select ARCH_VEXPRESS
+
config ARCH_VERSATILE
bool "ARM Ltd. Versatile family"
select ARCH_WANT_OPTIONAL_GPIOLIB
^ permalink raw reply related
* [PATCH v3 0/6] DT support for AT91RM9200
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-11-05 18:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGhQ9Vxek1Xju4ShRV0KZtE4gsg-KZjG=6n+B54ddEv-6v9yXA@mail.gmail.com>
On 18:59 Mon 05 Nov , Joachim Eastwood wrote:
> On 5 November 2012 08:28, Jean-Christophe PLAGNIOL-VILLARD
> <plagnioj@jcrosoft.com> wrote:
> > On 18:55 Sun 04 Nov , Joachim Eastwood wrote:
> >> On 4 November 2012 16:52, Jean-Christophe PLAGNIOL-VILLARD
> >> <plagnioj@jcrosoft.com> wrote:
> >> > On 19:31 Sun 28 Oct , Joachim Eastwood wrote:
> >> >> Patch 1 is a fix for a build failure which can happen if board-dt is enabled when no AT91SAM machines are enabled.
> >> >>
> >> >> Patch 2 adds DT support to the AT91RM9200 system timer. Based on AT91 PIT patch by Jean-Christophe PLAGNIOL-VILLARD.
> >> >>
> >> >> Patch 3 adds clock lookups for DT.
> >> >>
> >> >> Patch 4 adds a new board for RM9200 DT support.
> >> >>
> >> >> Patch 5-6 adds the base devicetree for AT91RM9200 and support for AT91RM9200-EK board.
> >> >>
> >> >>
> >> >> I don't have a AT91RM9200-EK to test on but I was able to boot at91rm9200ek.dts on my custom board using a >>initrd. As far as I can tell pinctrl, usart and ohci all work.
> >> >
> >> > After updating barebox to have the DT support I've tested it on rm9200ek with net support
> >> >
> >> > work fine
> >>
> >> Excellent.
> >>
> >> > It does not apply on my tree as I've a more patch but I'll manage the merge
> >> > conflict
> >>
> >> Thanks for fixing it up Jean-Christophe.
> > I'll also fix the usb device and add missing nor flash support and emac +
> > pinctrl + defconfig
>
> Very nice.
>
> Please make the changes available via a git tree when it's ready.
for at91 the official git is on github
I've to send some patch series
I'll put them in our next
Best Regards,
J.
^ permalink raw reply
* [PATCHv3 8/8] i2c: omap: cleanup the sysc write
From: Shubhrajyoti Datta @ 2012-11-05 18:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5097F642.9010803@ti.com>
On 11/5/12, Cousson, Benoit <b-cousson@ti.com> wrote:
> On 11/5/2012 3:25 PM, Felipe Balbi wrote:
>> Hi,
>>
>> On Mon, Nov 05, 2012 at 07:53:45PM +0530, Shubhrajyoti wrote:
>>> On Monday 05 November 2012 07:44 PM, Felipe Balbi wrote:
>>>>> - dev->syscstate);
>>>>>> - }
>>>> not sure if this will work. What about the first time you call reset()
>>>> ?
>>>> won't SYSC just contain the reset values ?
>>> No actually the hwmod sets the value.
>>
>> ahaaa, ok good. Let's get an Ack from Benoit, then.
>
> Well, in fact, I'm a little bit surprised that we still have to hack the
there was an attempt [1]
the pdata stuff may have issues with dt having to deal with more pdata [2]
> SYSC directly without using an omap_device API.
Paul was not happy with omap device api [3]
As far as the patch is concerned it is only getting rid of the hard coded flags
and the rev check.
> I know that we have to
> do some weird stuff for reseting that IP, but didn't we already exposed
> something to allow that?
>
> Regards,
> Benoit
[1] http://www.spinics.net/lists/linux-i2c/msg06810.html
[2] http://www.spinics.net/lists/linux-i2c/msg06937.html
[3] http://www.spinics.net/lists/linux-i2c/msg06943.html
^ permalink raw reply
* [GIT PULL 2/3] omap plat header removal for v3.8 merge window, part3
From: Olof Johansson @ 2012-11-05 18:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508aff60.4688e50a.0457.ffff898bSMTPIN_ADDED@mx.google.com>
On Fri, Oct 26, 2012 at 02:23:40PM -0700, Tony Lindgren wrote:
> The following changes since commit 3d82cbbb3aadb4f8a30e3f614e51be96574a0855:
>
> ARM: OMAP: Split plat/serial.h for omap1 and omap2+ (2012-10-24 13:34:31 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.8/cleanup-headers-part3-signed
>
> for you to fetch changes up to a0212796b58061a9716178d261f318925c246643:
>
> Merge tag 'omap-cleanup-fixes-a-for-3.8' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into omap-for-v3.8/cleanup-headers (2012-10-26 13:18:19 -0700)
>
> ----------------------------------------------------------------
>
> Here is the third set of plat header removal for omap2+.
>
> This is based on the following minimal topic branches
> coordinated with the related driver maintainers:
>
> omap-for-v3.8/cleanup-headers-usb
> omap-for-v3.8/cleanup-headers-menelaus
>
> In addition to that, there are few fixes to the previously
> merged patches that can show up with customized configs.
Thanks, I pulled in the two branches above as explicit dependencies, and
resolved the conflicts the same way you did.
New branches are:
depends/omap-cleanup-headers-menelaus
depends/omap-cleanup-headers-usb
omap/cleanup-headers-3
-Olof
^ permalink raw reply
* [PATCH v4 1/5] zynq: use GIC device tree bindings
From: Josh Cartwright @ 2012-11-05 18:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <60e4cbf9-52b4-4c02-8537-ecd3a7dbbf06@CO1EHSMHS020.ehs.local>
On Sat, Oct 27, 2012 at 03:20:59PM +0000, Michal Simek wrote:
> On Saturday, October 27, 2012 4:43 PM, Josh Cartwright wrote:
> > On Sat, Oct 27, 2012 at 02:06:45PM +0000, Michal Simek wrote:
> > [...]
> > > I am not big fan to use dtsi solution because dts can be simple
> > > generated directly From Xilinx design tool based on your hw design.
> > > That's why I can't see any benefit To have dtsi file.
> >
> > Can I ask you to reconsider?
>
> I am open to all solution which will help others. I am not definitely
> saying NO for this features I just haven't found a reason to support
> it.
>
> > We, for example, don't make any use of the Xilinx
> > dev tools to generate our device trees.
>
> Ok. How does your working flow looks like? I mean you don't get any
> information from hardware guys how does your hw design look like?
Our usecase may admittedly be a bit weird, because what logic is in the
PL is ultimately determined (and even implemented) by the end user and
is loaded at runtime. There is a lot of machinery to make that happen,
but the point is that I don't have sufficient knowledge upfront to
generate appropriate bindings for what's in the PL.
> > Having a dtsi allows for easy extension of the zynq-7000 platform
> > for our boards, without having to carry duplicate data.
>
> ok. I think that make sense if you send the next your series as RFC to
> see how exactly you would like to use it.
It seems like you caught a glimpse of this in my COMMON_CLK patchset. :)
> In my workflow we generate DTS directly from design tool which I
> expect your hw guys use because it is probably needed to generate
> boot.bin/fsbl/etc. Then there is one more additional step to setup
> device-tree bsp to generate DTS which directly fits to your HW design.
> If you have the same boards with different programmable logic I
> understand that you would like to share that PS part and then just add
> it that IPs in PL.
[..]
> From my point of view. You have to use design tools at least once to
> get bitstream and boot.bin with fsbl. Please correct me if I am wrong.
> In this step you can use device-tree BSP to generate DTS ( I doesn't
> need to be perfect with all attached devices on i2c,spi, phys, etc but
> it reflects your hardware). You will get it in some seconds and your
> dts has correct irq numbers/ip description, compatible strings,
> addresses, position in the system - if you use bus bridges, etc) and
> you can just directly use it and kernel will boot. If you need to do
> changes in dts by hand, you can of course do it.
I wouldn't be as opposed to device tree generation if the device tree
generator was in tree. Device tree bindings change, how would/could an
out-of-tree generator possibly handle changes in bindings? Would a user
target the generator at a specific version of the kernel? (An in tree
generator would also seem to necessitate a more formal specification
language for DT bindings).
It is odd to me that the use of a generator would be required to create
what is completely static data. What I'm referring to here is the
collection of peripherals on the zynq-7000 that are not in the PL. For
me, this requirement adds an unnecessary dependency on the Xilinx EDK
that I would like to avoid.
Would it make sense to limit what the device tree generator produces to
only what is in the PL? (Forgive my ignorance about this tool, I've
never used it.)
This could just be an extension of what I've started to do with the
COMMON_CLK patchset. A zynq board would be described using several
device tree snippets, one for the baked-in zynq-7000 peripheral set, one
for a generated description of what is in the PL, and one describing any
board-specific details (phy, etc). Something like below:
zynq-7000.dtsi : description of static zynq-7000 peripherals
/ {
amba : amba at 0 {
slcr: slcr at f8000000 {
clocks {
ps_clk : ps_clk {
compatible = "fixed-clock";
};
...
}
};
i2c0 : i2c0 at e0004000 {
compatible = "xlnx,i2cps";
...
};
eth0 : eth0 at e000b000 {
compatible = "xlnx,emacps";
...
};
};
};
zynq-zc702-pl.dtsi : generated description of what is in the PL
&amba {
/* PL IP generated descriptions here. */
};
zynq-zc702.dts : board-specific descriptions (osc freq, i2c, spi, phys, etc)
/include/ "zynq-7000.dtsi"
/include/ "zynq-zc702-pl.dtsi"
&ps_clk {
clock-frequency = <33333330>;
};
&i2c0 {
pca9548 at 74 {
...
reg = <0x74>;
...
};
};
ð0 {
phy at 7 {
compatible = "marvell,888e1116r";
...
reg = <0x7>;
};
};
Thoughts?
Thanks,
Josh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121105/261d059b/attachment-0001.sig>
^ permalink raw reply
* pxa27x_keypad status
From: Robert Jarzmik @ 2012-11-05 18:45 UTC (permalink / raw)
To: linux-arm-kernel
Hi guys,
Did you test out lately pxa27x_keypad driver ?
I just passed a single test on 3.7-rc4, and I have no events. Moreover, if I do
a "cat /proc/interrupts", the keypad interrupts number remains constant, even if
I press keys :
> 4: 6 SC pxa27x-keypad
Are keypad keys on PXA27x SoCs working for you ?
Cheers.
--
Robert
^ permalink raw reply
* pxa27x_keypad status
From: Vasily Khoruzhick @ 2012-11-05 18:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87fw4nvqfs.fsf@free.fr>
On Mon, Nov 5, 2012 at 9:45 PM, Robert Jarzmik <robert.jarzmik@free.fr> wrote:
> Hi guys,
>
> Did you test out lately pxa27x_keypad driver ?
> I just passed a single test on 3.7-rc4, and I have no events. Moreover, if I do
> a "cat /proc/interrupts", the keypad interrupts number remains constant, even if
> I press keys :
>> 4: 6 SC pxa27x-keypad
>
> Are keypad keys on PXA27x SoCs working for you ?
Hi Robert,
3.7-rc2 works for me except suspend/resume issue (does not work after resume)
I've just reverted 6ce34a5fb4955fac1eebe080e1c2784bc8710449 as
temporary workaround.
Regards
Vasily
^ permalink raw reply
* [GIT PULL 3/3] omap prcm cleanup for v3.8 merge window, part1
From: Olof Johansson @ 2012-11-05 18:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1TRrO0-00087R-UM@merlin.infradead.org>
On Fri, Oct 26, 2012 at 02:23:40PM -0700, Tony Lindgren wrote:
> The following changes since commit a0212796b58061a9716178d261f318925c246643:
>
> Merge tag 'omap-cleanup-fixes-a-for-3.8' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into omap-for-v3.8/cleanup-headers (2012-10-26 13:18:19 -0700)
>
> are available in the git repository at:
>
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.8/cleanup-prcm-part1-take2-signed
>
> for you to fetch changes up to 7fc54fd3084457c7f11b9e2e1e3fcd19a3badc33:
>
> Merge branch 'omap-for-v3.8/cleanup-headers' into omap-for-v3.8/cleanup-prcm (2012-10-26 13:32:22 -0700)
>
> ----------------------------------------------------------------
>
> From Paul Walmsley <paul@pwsan.com>:
>
> The first set of OMAP PRM/CM-related cleanup patches for 3.8.
> Prepares for the future move of the PRM/CM code to drivers/. Also
> includes some prcm.[ch] cleanup patches from the WDTIMER cleanup
> series that don't need external acks.
>
> ----------------------------------------------------------------
> Paul Walmsley (9):
> ARM: OMAP2+: PRM: remove PRM weak functions
> ARM: OMAP2+: PRM: split PRM functions into OMAP2, OMAP3-specific files
> ARM: OMAP2+: powerdomain/PRM: move the low-level powerdomain functions into PRM
> ARM: OMAP2+: CM/hwmod: split CM functions into OMAP2, OMAP3-specific files
> ARM: OMAP2/3: clockdomain/PRM/CM: move the low-level clockdomain functions into PRM/CM
> ARM: OMAP2+: PRM: prepare for use of prm_ll_data function pointers
> ARM: OMAP2+: CM: prepare for use of cm_ll_data function pointers
> ARM: OMAP1: create read_reset_sources() function (for initial use by watchdog)
> ARM: OMAP2+: PRM: create PRM reset source API for the watchdog timer driver
>
> Tony Lindgren (2):
> Merge tag 'omap-cleanup-a-for-3.8' of git://git.kernel.org/.../pjw/omap-pending into omap-for-v3.8/cleanup-prcm
> Merge branch 'omap-for-v3.8/cleanup-headers' into omap-for-v3.8/cleanup-prcm
Hi,
The history of this branch looks a little odd. Did you mean to merge in
cleanup-headers on top of Paul's branch in it? It seems to add no value -- all
that code is already in our branch and it resolves no conflicts, etc.
That being said, it causes no harm, and I've pulled it in as is.
-Olof
^ permalink raw reply
* [PATCH V4 REPOST] ARM: implement debug_ll_io_init()
From: Stephen Warren @ 2012-11-05 18:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMh84DVzwHd8z+fcLeSmcDoSm566MOXQYi2u7uX6S1t5Bg@mail.gmail.com>
On 11/05/2012 10:37 AM, Olof Johansson wrote:
> On Wed, Oct 31, 2012 at 10:21 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>
>> Arnd, Olof, could this patch be placed into a standalone topic branch in
>> arm-soc branch; I'd like to make use of this patch for both Tegra and
>> bcm2835 this cycle, and perhaps others might too. Thanks.
>
> Done, applied to single-patch branch devel/debug_ll_init. I'll bring
> that in at next/multiplatform as well.
Thanks very much. I've merged this into the Tegra tree.
^ permalink raw reply
* [PATCH V3 1/5] ARM: implement debug_ll_io_init()
From: Stephen Warren @ 2012-11-05 19:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350686507-3022-1-git-send-email-swarren@wwwdotorg.org>
On 10/19/2012 04:41 PM, Stephen Warren wrote:
> When using DEBUG_LL, the UART's (or other HW's) registers are mapped
> into early page tables based on the results of assembly macro addruart.
> Later, when the page tables are replaced, the same virtual address must
> remain valid. Historically, this has been ensured by using defines from
> <mach/iomap.h> in both the implementation of addruart, and the machine's
> .map_io() function. However, with the move to single zImage, we wish to
> remove <mach/iomap.h>. To enable this, the macro addruart may be used
> when constructing the late page tables too; addruart is exposed as a
> C function debug_ll_addr(), and used to set up the required mapping in
> debug_ll_io_init(), which may called on an opt-in basis from a machine's
> .map_io() function.
Patch 1 has been taken into arm-soc, and I've applied patches 2-5 to the
Tegra tree.
^ permalink raw reply
* Building for MMU-less vexpress targets
From: Arnd Bergmann @ 2012-11-05 19:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121105173640.GR3351@mudshark.cambridge.arm.com>
On Monday 05 November 2012, Will Deacon wrote:
> I was playing around with !CONFIG_MMU today and to my dismay noticed that
> you can't select ARCH_VEXPRESS without CONFIG_MMU=y! This is because
> ARCH_VEXPRESS is only selectable via ARCH_MULTI_V7, which depends on
> ARCH_MULTIPLATFORM which in turn depends on MMU.
>
> I'm inclined to add a dummy VEXPRESS entry to arm/Kconfig which depends on
> !ARCH_MULTIPLATFORM and just selects ARCH_VEXPRESS (with the if ARCH_MULTI_V7
> dependency dropped) but I wondered if you'd got any better ideas?
>
I don't actually remember what the reason for making ARCH_MULTIPLATFORM
depend on MMU was. Maybe it just works if you drop the dependency.
Presumably it's related to ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR not
working on NOMMU, but if that's the case, we could make it
ARCH_MULTIPLATFORM
bool "Allow multiple platforms to be selected"
select ARM_PATCH_PHYS_VIRT if !MMU
select AUTO_ZRELADDR if !MMU
but maybe those actually work without MMU as well. I have never looked too
closely at NOMMU configurations, every time I tried, they were broken in
combination with something else I wanted to enable.
Arnd
^ permalink raw reply
* [PATCH v3 07/11] ARM: davinci - restructure header files for common clock migration
From: Murali Karicheri @ 2012-11-05 19:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50967641.4090503@ti.com>
On 11/04/2012 09:05 AM, Sekhar Nori wrote:
>
> On 10/25/2012 9:41 PM, Murali Karicheri wrote:
>> pll.h is added to migrate some of the PLL controller defines for sleep.S.
>> psc.h is modified to keep only PSC modules definitions needed by sleep.S
>> after migrating to common clock. The definitions under
>> ifdef CONFIG_COMMON_CLK will be removed in a subsequent patch.
>> davinci_watchdog_reset prototype is moved to time.h as clock.h is
>> being obsoleted. sleep.S and pm.c is modified to include the new header
>> file replacements.
>>
>> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
>> ---
>> arch/arm/mach-davinci/devices.c | 2 ++
>> arch/arm/mach-davinci/include/mach/pll.h | 46 +++++++++++++++++++++++++++++
>> arch/arm/mach-davinci/include/mach/psc.h | 4 +++
>> arch/arm/mach-davinci/include/mach/time.h | 4 ++-
>> arch/arm/mach-davinci/pm.c | 4 +++
>> arch/arm/mach-davinci/sleep.S | 4 +++
>> 6 files changed, 63 insertions(+), 1 deletion(-)
>> create mode 100644 arch/arm/mach-davinci/include/mach/pll.h
> With this patch a _third_ copy of PLL definitions is created in kernel
> sources. The existing PLL definitions in clock.h inside mach-davinci
> should be moved to mach/pll.h and the pll.h you introduced inside
> drivers/clk in 5/11 should be removed (this patch should appear before
> 5/11).
>
> The biggest disadvantage of this approach is inclusion of mach/ includes
> in drivers/clk. But duplicating code is definitely not the fix for this.
> Anyway, mach/ includes are not uncommon in drivers/clk (they are all
> probably suffering from the same issue).
Sekhar,
I have replied to patch 5/11 that also refers to this. The main reason
we are not able to do this cleanly is the code in sleep.c and pm.c. That
is something related to Power management. Could you take a look and see
if you can do some clean up on this code? I believe It is more than just
moving the header files.
Murali
>
> $ grep -rl "include <mach/" drivers/clk/*
> drivers/clk/clk-u300.c
> drivers/clk/mmp/clk-pxa168.c
> drivers/clk/mmp/clk-mmp2.c
> drivers/clk/mmp/clk-pxa910.c
> drivers/clk/mxs/clk-imx23.c
> drivers/clk/mxs/clk-imx28.c
> drivers/clk/spear/spear6xx_clock.c
> drivers/clk/spear/spear3xx_clock.c
> drivers/clk/spear/spear1340_clock.c
> drivers/clk/spear/spear1310_clock.c
> drivers/clk/ux500/clk-prcc.c
> drivers/clk/versatile/clk-integrator.c
> drivers/clk/versatile/clk-realview.c
>
> pll.h can probably be moved to include/linux/clk/ to avoid this. Would
> like to hear from Mike on this before going ahead.
>
> Anyway, instead of just commenting, I though I will be more useful and
> went ahead and made some of the changes I have been talking about. I
> fixed the multiple PLL definitions issue, the build infrastructure issue
> and the commit ordering too.
>
> I pushed the patches I fixed to devel-common-clk branch of my git tree.
> It is build tested using davinci_all_defconfig but its not runtime tested.
>
> Can you start from here and provide me incremental changes on top of
> this? That way we can collaborate to finish this faster.
Thanks for offering some help. Yes I can provide you incremental patch.
But then could you also help me to squash/rebase and send patches to the
list for review?
> Thanks,
> Sekhar
>
^ permalink raw reply
* [PATCH 13/15] ARM: DTS: AM33XX: Add nodes for OCMCRAM and Mailbox
From: Kevin Hilman @ 2012-11-05 19:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <B5906170F1614E41A8A28DE3B8D121433EC0337B@DBDE01.ent.ti.com>
"Bedia, Vaibhav" <vaibhav.bedia@ti.com> writes:
> On Mon, Nov 05, 2012 at 20:23:11, Shilimkar, Santosh wrote:
> [...]
>> >
>> On OMAP the OCMC RAM is always clocked and doesn't need any special
>> clock enable. CM_L3_2_OCMC_RAM_CLKCTRL module mode field is read only.
>> Isn't it same on AMXX ?
>>
>
> On AM33xx, OCMC RAM is in PER domain and the corresponding CLKCLTR module
> mode fields are r/w. OCMC RAM needs to be disabled as part of the DeepSleep0
> entry to let PER domain transition.
After DeepSleep0, the ROM code is being given an address in OCMC RAM to
jump to. If OCMC RAM is disabled as part of suspend, this means that
OCMC RAM contents are maintained even though PER domain transitions?
If so, that needs to be more clearly documented.
Kevin
^ 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