* [PATCH v4] of: add functions to count number of elements in a property
From: Heiko Stübner @ 2014-02-04 18:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140204173034.2D899C4050F@trevor.secretlab.ca>
Hi Grant,
On Tuesday, 4. February 2014 17:30:34 Grant Likely wrote:
> On Sat, 18 Jan 2014 09:07:30 -0600, Rob Herring <robherring2@gmail.com>
wrote:
> > On Sat, Jan 18, 2014 at 6:02 AM, Heiko St??bner <heiko@sntech.de> wrote:
> > > The need to know the number of array elements in a property is
> > > a common pattern. To prevent duplication of open-coded implementations
> > > add a helper static function that also centralises strict sanity
> > > checking and DTB format details, as well as a set of wrapper functions
> > > for u8, u16, u32 and u64.
> > >
> > > Suggested-by: Mark Rutland <mark.rutland@arm.com>
> > > Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> > > ---
> >
> > Looks good. Do you plan to convert some users to use this?
>
> I'll take that as an acked-by. Merged, thanks.
before you taking this patch, I was planning on simply sending this as part of
my rockchip-smp series - as I'm currently the only user of it :-) .
This going through your tree is most likely the better way, but now I need it
to somehow make its way into arm-soc too ... I guess some sort of stable
branch arm-soc could pull?
Thanks
Heiko
^ permalink raw reply
* [ath9k-devel] [PATCH 1/3] ath9k: Fix build error on ARM
From: Arnd Bergmann @ 2014-02-04 18:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391531796.2538.21.camel@joe-AO722>
On Tuesday 04 February 2014 08:36:36 Joe Perches wrote:
> On Tue, 2014-02-04 at 08:03 +0100, Holger Schurig wrote:
> > Joe, look in linux/arch/arm/include/asm/delay.h. The macro udelay
> > cannot handle large values because of lost-of-precision.
> >
> > IMHO udelay on ARM is broken, because it also cannot work with fast
> > ARM processors (where bogomips >= 3355, which is in sight now). It's
> > just not broken enought that someone did something against it ... so
> > the current kludge is good enought.
>
> Maybe something like this would be better?
>
I actually like the fact that we get link errors for insane 'udelay'
times. In most cases it's a driver bug because we shouldn't keep
the CPU busy for an eternity in the kernel (and call msleep() instead).
For the rare cases where mdelay makes sense, we also want to add
a comment to the code explaining why msleep cannot be used.
Arnd
^ permalink raw reply
* Weird sched_clock behaviour during boot with -rc1
From: Will Deacon @ 2014-02-04 18:36 UTC (permalink / raw)
To: linux-arm-kernel
Hi guys,
Booting -rc1 on my TC2 gives the following strange entries in the dmesg:
Uncompressing Linux... done, booting the kernel.
[ 0.000000] Booting Linux on physical CPU 0x0
[...]
[ 0.000000] HighMem zone: 329728 pages, LIFO batch:31
[ 7.789662] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956969942ns
[ 0.000129] PERCPU: Embedded 9 pages/cpu @ee7bd000 s12800 r8192 d15872 u36864
[...]
[ 0.868297] NR_IRQS:16 nr_irqs:16 16
[ 0.886350] Architected cp15 timer(s) running at 24.00MHz (phys).
[ 2915.164998] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 2863311519744ns
[ 0.000002] Switching to timer-based delay loop
[ 0.014249] Console: colour dummy device 80x30
so it looks like something whacky goes on during sched_clock registration.
Sure enough, we're doing a pr_info in-between updating cs.* and calling
update_sched_clock(), so moving the print sorts things out (diff below).
What I can't figure out is why this has suddenly started happening with
3.14. Any ideas?
Cheers,
Will
--->8
diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
index 0abb36464281..f3de5d113afc 100644
--- a/kernel/time/sched_clock.c
+++ b/kernel/time/sched_clock.c
@@ -147,9 +147,6 @@ void __init sched_clock_register(u64 (*read)(void), int bits,
/* calculate the ns resolution of this counter */
res = cyc_to_ns(1ULL, cd.mult, cd.shift);
- pr_info("sched_clock: %u bits at %lu%cHz, resolution %lluns, wraps every %lluns\n",
- bits, r, r_unit, res, wrap);
-
update_sched_clock();
/*
@@ -161,6 +158,9 @@ void __init sched_clock_register(u64 (*read)(void), int bits,
if (irqtime > 0 || (irqtime == -1 && rate >= 1000000))
enable_sched_clock_irqtime();
+ pr_info("sched_clock: %u bits at %lu%cHz, resolution %lluns, wraps every %lluns\n",
+ bits, r, r_unit, res, wrap);
+
pr_debug("Registered %pF as sched_clock source\n", read);
}
^ permalink raw reply related
* [PATCH] arm64: Add architecture support for PCI
From: Arnd Bergmann @ 2014-02-04 18:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140204181514.GA25695@obsidianresearch.com>
On Tuesday 04 February 2014 11:15:14 Jason Gunthorpe wrote:
> On Tue, Feb 04, 2014 at 10:44:52AM +0100, Arnd Bergmann wrote:
>
> > Now I want to integrate the EHCI into my SoC and not waste one
> > of my precious PCIe root ports, so I have to create another PCI
> > domain with its own ECAM compliant config space to put it into.
> > Fortunately SBSA lets me add an arbitrary number of PCI domains,
> > as long as they are all strictly compliant. To software it will
>
> Just to touch on this for others who might be reading..
>
> IMHO any simple SOC that requires multiple domains is *broken*. A
> single domain covers all reasonable needs until you get up to
> mega-scale NUMA systems, encouraging people to design with multiple
> domains only complicates the kernel :(
Well, the way I see it, we already have support for arbitrary
PCI domains in the kernel, and that works fine, so we can just
as well use it. That way we don't have to partition the available
256 buses among the host bridges, and anything that needs a separate
PCI config space can live in its own world. Quite often when you
have multiple PCI hosts, they actually have different ways to
get at the config space and don't even share the same driver.
On x86, any kind of HT/PCI/PCIe/PCI-x bridge is stuffed into a
single domain so they can support OSs that only know the
traditional config space access methods, but I don't see
any real advantage to that for other architectures.
> SOC internal peripherals should all show up in the bus 0 config space
> of the only domain and SOC PCI-E physical ports should show up on bus
> 0 as PCI-PCI bridges. This is all covered in the PCI-E specs regarding
> the root complex.
>
> Generally I would expect the internal peripherals to still be
> internally connected with AXI, but also connected through the ECAM
> space for configuration, control, power management and address
> assignment.
That would of course be very nice from a software perspective,
but I think that is much less likely for any practical
implementation.
> > 2. all address windows are set up by the boot loader, we only
> > need to know the location (IMHO this should be the
> > preferred way to do things regardless of SBSA).
>
> Linux does a full address map re-assignment on boot, IIRC. You need
> more magics to inhibit that if your BAR's and bridge windows don't
> work.
>
> Hot plug is a whole other thing..
I meant the I/O and memory space windows of the host bridge here,
which typically don't get reassigned (except on mvebu). For the
device resources, there is a per-host PCI_REASSIGN_ALL_RSRC
flag and pcibios_assign_all_busses() function that we typically
set on embedded systems where we don't trust the boot loader
to set this up correctly, or at all.
On server systems, I would expect to have the firmware assign
all resources and the kernel to leave them alone. On sparc
and powerpc servers, there is even a third method, which
is to trust firmware to put the correct resources for each
device into DT, overriding what is written in the BAR.
> > it's possible that the designware based ones get point 4 right.
>
> The designware one's also appear to be re-purposed end point cores, so
> their config handling is somewhat bonkers. Tegra got theirs sort of
> close because they re-used knowledge/IP from their x86 south bridges -
> but even then they didn't really implement ECAM properly for an ARM
> environment.
>
> Since config space is where everyone to date has fallen down, I think
> the SBSA would have been wise to list dword by dword what a typical
> ECAM config space should look like.
I absolutely agree.
Arnd
^ permalink raw reply
* [PATCH] dma: mv_xor: Silence a bunch of LPAE-related warnings
From: Olof Johansson @ 2014-02-04 18:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140204170019.GI8533@titan.lakedaemon.net>
On Tue, Feb 4, 2014 at 9:00 AM, Jason Cooper <jason@lakedaemon.net> wrote:
> On Tue, Feb 04, 2014 at 10:53:29AM +0530, Vinod Koul wrote:
>> On Mon, Feb 03, 2014 at 05:13:23PM -0800, Olof Johansson wrote:
>> > Enabling some of the mvebu platforms in the multiplatform config for ARM
>> > enabled these drivers, which also triggered a bunch of warnings when LPAE
>> > is enabled (thus making phys_addr_t 64-bit).
>> >
>> > Most changes are switching printk formats, but also a bit of changes to what
>> > used to be array-based pointer arithmetic that could just be done with the
>> > address types instead.
>> >
>> > The warnings were:
>> >
>> > drivers/dma/mv_xor.c: In function 'mv_xor_tx_submit':
>> > drivers/dma/mv_xor.c:500:3: warning: format '%x' expects argument of type
>> > 'unsigned int', but argument 4 has type 'dma_addr_t' [-Wformat]
>> > drivers/dma/mv_xor.c: In function 'mv_xor_alloc_chan_resources':
>> > drivers/dma/mv_xor.c:553:13: warning: cast to pointer from integer of
>> > different size [-Wint-to-pointer-cast]
>> > drivers/dma/mv_xor.c:555:4: warning: cast from pointer to integer of
>> > different size [-Wpointer-to-int-cast]
>> > drivers/dma/mv_xor.c: In function 'mv_xor_prep_dma_memcpy':
>> > drivers/dma/mv_xor.c:584:2: warning: format '%x' expects argument of type
>> > 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat]
>> > drivers/dma/mv_xor.c:584:2: warning: format '%x' expects argument of type
>> > 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat]
>> > drivers/dma/mv_xor.c: In function 'mv_xor_prep_dma_xor':
>> > drivers/dma/mv_xor.c:628:2: warning: format '%u' expects argument of type
>> > 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat]
>> >
>> > Signed-off-by: Olof Johansson <olof@lixom.net>
>> Acked-by: Vinod Koul <vinod.koul@intel.com>
>
> Olof, would you like me to queue it up? Or do you want to take it
> directly?
>
> Acked-by: Jason Cooper <jason@lakedaemon.net>
I'm confused. I sent the patch to the drivers/dma maintainers and they
just acked it without asking me to pick it up myself.
Vinod, did you ack it for me to pick it up, or for some other reason?
If you don't want to take it through your tree I'll be happy to take
it through arm-soc, just looking to clarify.
(Jason, I can apply it directly)
-Olof
^ permalink raw reply
* [PATCH 2/2] arm64: vdso: update wtm fields for CLOCK_MONOTONIC_COARSE
From: Will Deacon @ 2014-02-04 18:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391456932-17815-3-git-send-email-nathan_lynch@mentor.com>
On Mon, Feb 03, 2014 at 07:48:52PM +0000, Nathan Lynch wrote:
> Update wall-to-monotonic fields in the VDSO data page
> unconditionally. These are used to service CLOCK_MONOTONIC_COARSE,
> which is not guarded by use_syscall.
>
> Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Will
^ permalink raw reply
* [PATCH 1/2] arm64: vdso: fix coarse clock handling
From: Will Deacon @ 2014-02-04 18:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391456932-17815-2-git-send-email-nathan_lynch@mentor.com>
Hi Nathan,
Thanks for the patch!
On Mon, Feb 03, 2014 at 07:48:51PM +0000, Nathan Lynch wrote:
> When __kernel_clock_gettime is called with a CLOCK_MONOTONIC_COARSE or
> CLOCK_REALTIME_COARSE clock id, it returns incorrectly to whatever the
> caller has placed in x2. Fix this by saving x30/LR to x2
> unconditionally.
>
> Also: the tv_nsec field in the result is shifted by the value in x12.
> In the high-precision case x12 is cs_shift from the data page, but
> for coarse clocks x12 is uninitialized. Fix this by setting x12 to 0
> once we know we are dealing with a coarse clock.
How are you managing to see these failures? It's clear that our LTP testing
isn't hitting this path...
> Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com>
> ---
> arch/arm64/kernel/vdso/gettimeofday.S | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/kernel/vdso/gettimeofday.S b/arch/arm64/kernel/vdso/gettimeofday.S
> index f0a6d10b5211..6c37ae4a70c0 100644
> --- a/arch/arm64/kernel/vdso/gettimeofday.S
> +++ b/arch/arm64/kernel/vdso/gettimeofday.S
> @@ -88,13 +88,13 @@ ENDPROC(__kernel_gettimeofday)
> /* int __kernel_clock_gettime(clockid_t clock_id, struct timespec *tp); */
> ENTRY(__kernel_clock_gettime)
> .cfi_startproc
> + mov x2, x30
> + .cfi_register x30, x2
> +
> cmp w0, #CLOCK_REALTIME
> ccmp w0, #CLOCK_MONOTONIC, #0x4, ne
> b.ne 2f
>
> - mov x2, x30
> - .cfi_register x30, x2
> -
Could we avoid the redundant moves by instead doing this around the bl
__do_get_tspec?
> /* Get kernel timespec. */
> adr vdso_data, _vdso_data
> 1: seqcnt_acquire
> @@ -118,6 +118,9 @@ ENTRY(__kernel_clock_gettime)
> ccmp w0, #CLOCK_MONOTONIC_COARSE, #0x4, ne
> b.ne 8f
>
> + /* Set shift to 0 for coarse clocks */
> + mov x12, #0
Worth mentioning that xtime_coarse_nsec is pre-shifted for us, rather than
shifting not actually being required.
Also, rather than shift by #0, can we move the lsl instruction immediately
before the b 4f earlier on?
Will
^ permalink raw reply
* Extending OPP bindings
From: Mark Brown @ 2014-02-04 18:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F12AE7.904@ti.com>
On Tue, Feb 04, 2014 at 12:01:11PM -0600, Nishanth Menon wrote:
> As long as the key to the data sets are all the same (frequency),
> information in data set #0 is maintained. It would be in our common
> long term interest to maintain the split.
You're assuming that the frequency is a unique key here. That may not
be the case, for example two OPPs might have the same CPU clock
(assuming that's the frequency you're referring to) but different bus
clocking and of course the CPUs or CPU clusters might be individually
scalable (this is common in big.LITTLE designs I think).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140204/8dd2600f/attachment.sig>
^ permalink raw reply
* [PATCH] regulator: core: Make regulator object reflect configured voltage
From: Mark Brown @ 2014-02-04 18:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJAp7OjCnJ=P9Gi20=D9gybREiSaqd1CaQ0K=9fGbCzU1gTFLw@mail.gmail.com>
On Tue, Feb 04, 2014 at 10:02:14AM -0800, Bjorn Andersson wrote:
> On Tue, Feb 4, 2014 at 3:05 AM, Mark Brown <broonie@kernel.org> wrote:
> > Why not do this at the time we apply the voltage? That would seem to be
> > more robust, doing it in a separate place means that we might update one
> > bit of code and not the other or might change the execution path so that
> > one gets run and the other doesn't.
> I do share your concerns about having this logic mirrored here is
> risky, unfortunately the regulator object is created upon request from
> a consumer; so it is not available when regulator_register() calls
> set_machine_constraints().
Oh, hang on - that's what you mean by a regulator object... I don't
think this fixes the problem you think it does. What is the actual
problem you're trying to fix here? The min_uV and max_uV on a consumer
struct are supposed to be the request from that consumer, they should
only be set if the consumer actually made a request for a voltage range.
> An alternative is to drop the conditional setting of
> REGULATOR_CHANGE_VOLTAGE from of_regulator.c and force the regulator
> drivers to set this flag explicitly; to avoid the difference in
> behavior depending on configuration.
Why would having each individual driver open code things help?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140204/9e18bf84/attachment.sig>
^ permalink raw reply
* [PATCH 3/3] clk: shmobile: handle multiple parent clocks for cpg clocks
From: William Towle @ 2014-02-04 18:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391537858-28593-1-git-send-email-william.towle@codethink.co.uk>
The current action on registering the cpg_clocks is to have
them all registered with a single parent clock. This is not
the correct action, as some of the clocks such as the SDHI
and QSPI are actually parented to PLL1 or PLL1/2.
This also requires a change to the device-tree files to make
sure that appropriate parent clocks are assigned.
[ben.dooks at codethink.co.uk: updated patch description]
Signed-off-by: William Towle <william.towle@codethink.co.uk>
Reviewed-by: Ben Dooks <ben.dooks@codethink.co.uk>
---
drivers/clk/shmobile/clk-rcar-gen2.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/shmobile/clk-rcar-gen2.c b/drivers/clk/shmobile/clk-rcar-gen2.c
index df4a1e6..57bc2e4 100644
--- a/drivers/clk/shmobile/clk-rcar-gen2.c
+++ b/drivers/clk/shmobile/clk-rcar-gen2.c
@@ -185,7 +185,7 @@ static u32 cpg_mode __initdata;
static struct clk * __init
rcar_gen2_cpg_register_clock(struct device_node *np, struct rcar_gen2_cpg *cpg,
const struct cpg_pll_config *config,
- const char *name)
+ const char *name, int index)
{
const struct clk_div_table *table = NULL;
const char *parent_name = "main";
@@ -193,8 +193,13 @@ rcar_gen2_cpg_register_clock(struct device_node *np, struct rcar_gen2_cpg *cpg,
unsigned int mult = 1;
unsigned int div = 1;
+ parent_name = of_clk_get_parent_name(np, index);
+ if (!parent_name) {
+ pr_err("no parent set for clocks array\n");
+ return ERR_PTR(-ENOENT);
+ }
+
if (!strcmp(name, "main")) {
- parent_name = of_clk_get_parent_name(np, 0);
div = config->extal_div;
} else if (!strcmp(name, "pll0")) {
/* PLL0 is a configurable multiplier clock. Register it as a
@@ -279,7 +284,7 @@ static void __init rcar_gen2_cpg_clocks_init(struct device_node *np)
of_property_read_string_index(np, "clock-output-names", i,
&name);
- clk = rcar_gen2_cpg_register_clock(np, cpg, config, name);
+ clk = rcar_gen2_cpg_register_clock(np, cpg, config, name, i);
if (IS_ERR(clk))
pr_err("%s: failed to register %s %s clock (%ld)\n",
__func__, np->name, name, PTR_ERR(clk));
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/3] ARM: shmobile: r8a7790: specify multiple parents for cpg_clks
From: William Towle @ 2014-02-04 18:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391537858-28593-1-git-send-email-william.towle@codethink.co.uk>
The current drivers/clk/shmobile/clk-rcar-gen2.c uses the
extal_clk reference for the parent of all the clocks that
it registers. However the lb, qspi, sdh, sd0 and sd1 clocks
are all parented to either pll1 or pll1_div2 which means
that the clock rates are incorrect.
This is part of the fix that corrects the SDHI0 clock
rate error where it reports 1MHz instead of 97.5:
sh_mobile_sdhi ee100000.sd: mmc0 base at 0xee100000 clock rate 1 MHz
Notes:
- May require cross-merge with clk-rcar-gen2.c fix
- Also not clear which clock "z" is to fix it.
[ben.dooks at codethink.co.uk: updated patch description]
Signed-off-by: William Towle <william.towle@codethink.co.uk>
Reviewed-by: Ben Dooks <ben.dooks@codethink.co.uk>
---
arch/arm/boot/dts/r8a7790.dtsi | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index ff55c6e..242e6e2 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -446,7 +446,13 @@
compatible = "renesas,r8a7790-cpg-clocks",
"renesas,rcar-gen2-cpg-clocks";
reg = <0 0xe6150000 0 0x1000>;
- clocks = <&extal_clk>;
+ clocks = <&extal_clk>, <&extal_clk>, <&extal_clk>, <&extal_clk>,
+ <&cpg_clocks R8A7790_CLK_PLL1>,
+ <&pll1_div2_clk>,
+ <&cpg_clocks R8A7790_CLK_PLL1>,
+ <&cpg_clocks R8A7790_CLK_PLL1>,
+ <&cpg_clocks R8A7790_CLK_PLL1>
+ /* not known for "z" ...,<> */;
#clock-cells = <1>;
clock-output-names = "main", "pll0", "pll1", "pll3",
"lb", "qspi", "sdh", "sd0", "sd1",
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/3] clk: rcar-h2: fix sd0/sd1 divisor table
From: William Towle @ 2014-02-04 18:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391537858-28593-1-git-send-email-william.towle@codethink.co.uk>
The clk_div_table for cpg_sd01_div_table[] concurs with the manual
but not with values found in the device itself (which are also the
same as the ones in arch/arm/mach-shmobile/clock-r8a7790.c).
Update the clk-rcar-gen2.c driver to have the same table as the one
used by the mach-shmobile driver which work once further issues are
fixed in the clk-rcar-gen2.c driver.
Part of the fix for the following error where the driver reports the
output as 1MHz but is really 97.5MHz:
sh_mobile_sdhi ee100000.sd: mmc0 base at 0xee100000 clock rate 1 MHz
[ben.dooks at codethink.co.uk: updated patch description]
Signed-off-by: William Towle <william.towle@codethink.co.uk>
Reviewed-by: Ben Dooks <ben.dooks@codethink.co.uk>
---
drivers/clk/shmobile/clk-rcar-gen2.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/clk/shmobile/clk-rcar-gen2.c b/drivers/clk/shmobile/clk-rcar-gen2.c
index a59ec21..df4a1e6 100644
--- a/drivers/clk/shmobile/clk-rcar-gen2.c
+++ b/drivers/clk/shmobile/clk-rcar-gen2.c
@@ -170,6 +170,8 @@ static const struct clk_div_table cpg_sdh_div_table[] = {
};
static const struct clk_div_table cpg_sd01_div_table[] = {
+ { 0, 2 }, { 1, 3 }, { 2, 4 }, { 3, 6 },
+ { 4, 8 },
{ 5, 12 }, { 6, 16 }, { 7, 18 }, { 8, 24 },
{ 10, 36 }, { 11, 48 }, { 12, 10 }, { 0, 0 },
};
--
1.7.10.4
^ permalink raw reply related
* Clock divisor/parent settings changes
From: William Towle @ 2014-02-04 18:17 UTC (permalink / raw)
To: linux-arm-kernel
Patches (3x) to ensure we see:
sh_mobile_sdhi ee100000.sd: mmc0 base at 0xee100000 clock rate 97 MHz
sh_mobile_sdhi ee140000.sd: mmc1 base at 0xee140000 clock rate 48 MHz
Attached:
[PATCH 1/3] clk: rcar-h2: fix sd0/sd1 divisor table
[PATCH 2/3] ARM: shmobile: r8a7790: specify multiple parents for
[PATCH 3/3] clk: shmobile: handle multiple parent clocks for cpg
^ permalink raw reply
* [PATCH] arm64: Add architecture support for PCI
From: Jason Gunthorpe @ 2014-02-04 18:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <13031998.NR888KZWhk@wuerfel>
On Tue, Feb 04, 2014 at 10:44:52AM +0100, Arnd Bergmann wrote:
> Now I want to integrate the EHCI into my SoC and not waste one
> of my precious PCIe root ports, so I have to create another PCI
> domain with its own ECAM compliant config space to put it into.
> Fortunately SBSA lets me add an arbitrary number of PCI domains,
> as long as they are all strictly compliant. To software it will
Just to touch on this for others who might be reading..
IMHO any simple SOC that requires multiple domains is *broken*. A
single domain covers all reasonable needs until you get up to
mega-scale NUMA systems, encouraging people to design with multiple
domains only complicates the kernel :(
SOC internal peripherals should all show up in the bus 0 config space
of the only domain and SOC PCI-E physical ports should show up on bus
0 as PCI-PCI bridges. This is all covered in the PCI-E specs regarding
the root complex.
Generally I would expect the internal peripherals to still be
internally connected with AXI, but also connected through the ECAM
space for configuration, control, power management and address
assignment.
> 2. all address windows are set up by the boot loader, we only
> need to know the location (IMHO this should be the
> preferred way to do things regardless of SBSA).
Linux does a full address map re-assignment on boot, IIRC. You need
more magics to inhibit that if your BAR's and bridge windows don't
work.
Hot plug is a whole other thing..
> it's possible that the designware based ones get point 4 right.
The designware one's also appear to be re-purposed end point cores, so
their config handling is somewhat bonkers. Tegra got theirs sort of
close because they re-used knowledge/IP from their x86 south bridges -
but even then they didn't really implement ECAM properly for an ARM
environment.
Since config space is where everyone to date has fallen down, I think
the SBSA would have been wise to list dword by dword what a typical
ECAM config space should look like.
Jason
^ permalink raw reply
* [PATCH v3 3/5] ASoC: tda998x: add DT documentation of the tda998x CODEC
From: Mark Brown @ 2014-02-04 18:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8e4231b7a55802f58a14dd07ac5cd8b0babb1dce.1391274628.git.moinejf@free.fr>
On Sat, Feb 01, 2014 at 05:48:49PM +0100, Jean-Francois Moine wrote:
> + - compatible: must be "nxp,tda998x-codec".
It's not clear to me why there's a separate compatible here - as far as
I can see this can only appear as part of one of these devices and
there's no addressing or other information that'd account for chip
variation so I'd not expect to need to bind this independently of the
parent.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140204/fbac5b49/attachment.sig>
^ permalink raw reply
* [PATCH v3 5/5] ASoC: tda998x: adjust the audio CTS_N pre-divider from audio format
From: Mark Brown @ 2014-02-04 18:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <df65a2de7d4afc2471846c02b73e8bbdc4f9a743.1391274628.git.moinejf@free.fr>
On Thu, Jan 30, 2014 at 12:08:06PM +0100, Jean-Francois Moine wrote:
> - if (format == p->audio_format) {
> + if (format == p->audio_format &&
> + params_format(params) == priv->audio_sample_format) {
> reg_write(priv, REG_ENA_AP, p->audio_cfg);
> return;
I find the above confusing and probably deserving of a comment
explaining the logic. I think it's trying to skip noop configuration
updates?
> }
> p->audio_format = format;
> + priv->audio_sample_format = params_format(params);
You should be using params_width() for the number of bits per sample.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140204/2983dfe7/attachment.sig>
^ permalink raw reply
* [PATCH v3 4/5] ASoC: tda998x: adjust the audio hw parameters from EDID
From: Mark Brown @ 2014-02-04 18:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1b15025671d9099863a3091346536e45891e4a26.1391274628.git.moinejf@free.fr>
On Mon, Jan 27, 2014 at 09:48:54AM +0100, Jean-Francois Moine wrote:
> + /* change the snd_soc_pcm_stream values of the driver */
> + stream->rates = rate_mask;
> + stream->channels_max = max_channels;
> + stream->formats = formats;
> + /* copy the DAI driver to a writable area */
> + dai_drv = devm_kzalloc(&pdev->dev, sizeof(tda998x_dai), GFP_KERNEL);
> + if (!dai_drv)
> + return -ENOMEM;
> + memcpy(dai_drv, tda998x_dai, sizeof(tda998x_dai));
> +
The code should be doing this by setting constraints based on the
current setup rather than by editing the data structure - the expecation
is very much that the data won't change so this prevents surprises with
future work on the core.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140204/b5f17dd6/attachment.sig>
^ permalink raw reply
* [PATCH] regulator: core: Make regulator object reflect configured voltage
From: Bjorn Andersson @ 2014-02-04 18:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140204110531.GR22609@sirena.org.uk>
On Tue, Feb 4, 2014 at 3:05 AM, Mark Brown <broonie@kernel.org> wrote:
> On Mon, Feb 03, 2014 at 09:54:28PM -0800, Bjorn Andersson wrote:
>
>> + /*
>> + * Make the regulator reflect the configured voltage selected in
>> + * machine_constraints_voltage()
>> + */
>> + if (rdev->constraints->apply_uV &&
>> + rdev->constraints->min_uV == rdev->constraints->max_uV) {
>> + regulator->min_uV = rdev->constraints->min_uV;
>> + regulator->max_uV = rdev->constraints->min_uV;
>> + }
>> +
>
> Why not do this at the time we apply the voltage? That would seem to be
> more robust, doing it in a separate place means that we might update one
> bit of code and not the other or might change the execution path so that
> one gets run and the other doesn't.
I do share your concerns about having this logic mirrored here is
risky, unfortunately the regulator object is created upon request from
a consumer; so it is not available when regulator_register() calls
set_machine_constraints().
An alternative is to drop the conditional setting of
REGULATOR_CHANGE_VOLTAGE from of_regulator.c and force the regulator
drivers to set this flag explicitly; to avoid the difference in
behavior depending on configuration.
Regards,
Bjorn
^ permalink raw reply
* Extending OPP bindings
From: Nishanth Menon @ 2014-02-04 18:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140131180929.GH2616@e102568-lin.cambridge.arm.com>
On 01/31/2014 12:09 PM, Lorenzo Pieralisi wrote:
> Hi Rob,
>
> thanks for having a look.
>
> On Fri, Jan 31, 2014 at 05:17:51PM +0000, Rob Herring wrote:
>> On Fri, Jan 31, 2014 at 6:46 AM, Lorenzo Pieralisi
>> <lorenzo.pieralisi@arm.com> wrote:
>>> Hi Nishanth,
>>>
>>> On Fri, Jan 31, 2014 at 12:43:54AM +0000, Nishanth Menon wrote:
>>>> Hi Sudeep,
>>>>
>>>> On 01/30/2014 07:43 AM, Sudeep Holla wrote:
>>>>
>>>>>
>>>>> I am looking into a couple shortcomings in the current OPP bindings and
>>>>> how to address them. Feel free to add to the list if you think of any more
>>>>> issues that needs to be addressed or if and how any problem mentioned below
>>>>> can be handled with the existing bindings.
>>>>>
>>>>> 1. indexing: currently there are no indices in the operating-points.
>>>> indexing is based on frequency which is why the accessors use
>>>> frequency to pull out the OPP data.
>>>>
>>>> indexing is a horrible idea - on platforms where OPP may be disabled
>>>> or enabled for various reasons(see arch/arm/mach-imx/mach-imx6q.c,
>>>> arch/arm/mach-omap2/board-omap3beagle.c etc) - the indexing you see in
>>>> dts is just a myth that may not exist once the nodes are loaded and
>>>> operated upon depending on SoC variations (example efuse describing
>>>> which OPPs can be used and which not).
>>>
>>> I do not understand why. As long as a mapping from DT to data structures
>>> in the kernel is done at boot, I can see how by indexing device nodes
>>> can refer to specific OPPs. If they are disabled, amen, as long as we
>>> can point at specific operating points that should be ok.
>>>
>>> Indexing does not mean that the index in the DT is the same as the one
>>> allocated by the OS. Indexing is there to point at specific OPPs from
>>> different DT nodes, a good example are clock bindings and that's exactly
>>> how they work.
>>
>> That is not a good comparison. With clocks, you are describing which
>> physical signal coming out of a hardware block much like interrupts.
>> Granted the h/w is not typically documented that way for clocks
>> although the numbering could correspond to register bit locations as
>> interrupt numbers do. With OPP indexes, they are a totally made up
>> software construct.
>
> Well ok, it might be, what I know is that current OPPs do not allow
> other nodes to reference their properties properly, I am not sure that adding
> an index make things worse, actually they are already broken as they are.
Let me look at this in two parts:
A: In kernel data representation:
If I were to use analogy of OPP library to database, A data base needs
a key to pick out data stored inside it -> the key in opp definition
as it stands right now is frequency. you can pick up any of the data
based on that key. proposal for using index into that table adds no
real value here.
Now, we can represent OPP data in many different forms. consider two
other properties per OPP (propx and propy)
data set #0:
+------------+------------+---------+-------------+
| freq | voltage | propx | propy |
+-------------------------------------------------+
| Fa | Va | PXa | PYa |
| Fb | Vb | PXb | PYb |
| Fc | Vc | PXc | PYc |
| Fd | Vd | PXd | PYd |
+------------+------------+---------+-------------+
Can then be represented as:
in opp library, considering it to be the least common denominator:
(data set #1)
+------------+------------+
| freq | voltage |
+--------------------------
| Fa | Va |
| Fb | Vb |
| Fc | Vc |
| Fd | Vd |
+------------+------------+
where ever propx makes sense. (data set #2)
+------------+---------+
| freq | propx |
+-----------------------
| Fa | PXa |
| Fb | PXb |
| Fc | PXc |
| Fd | PXd |
+------------+---------+
where ever propy makes sense (data set #3)
+------------+-------------+
| freq | propy |
+--------------------------+
| Fa | PYa |
| Fb | PYb |
| Fc | PYc |
| Fd | PYd |
+------------+-------------+
If my memory serves me right, in database terminology, this'd be first
normal form.
This also allows for data set #2 and #3 to modify or add a data set #4
with a propz at a later point in time without impacting set #1-3.
propx,y,z can be anything - efuse bits, cpuidle c state definition, etc..
As long as the key to the data sets are all the same (frequency),
information in data set #0 is maintained. It would be in our common
long term interest to maintain the split.
>> Perhaps OPPs should be nodes so new fields can be added easily and
>> then you have a phandle for each OPP.
>
> Yeah, but the end result is the same, it has more to do with how to
> express dependencies with DT than the question on whether to use a phandle
> or an index. If we have to add phandles so be it, it is still just a way
> to reference properties for me.
B) Device tree representation of an OPP:
Here we have a ton of flexibility- I love the idea of representing
each OPP as a phandle - However, a phandle has been traditionally
meant to represent a device, I might be wrong, but i am not sure if we
have a precedence where phandle represents a property.
Having each OPP as a phandle does provide a lots of representation,
extensibility and reuse opportunity. but the same phandle will have to
be parsed by different drivers to pull out relevant data.
However when Sudeep introduced phandle approach, we did debate it's
representation and appropriate topology. if we can consider OPP as
it's own phandle and operating-points a list of OPP phandles, the pain
that we face in various driver usage can be simplified.
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH] arm64: Align CMA sizes to PAGE_SIZE
From: Catalin Marinas @ 2014-02-04 18:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391214234-23526-1-git-send-email-lauraa@codeaurora.org>
On Sat, Feb 01, 2014 at 12:23:54AM +0000, Laura Abbott wrote:
> dma_alloc_from_contiguous takes number of pages for a size.
> Align up the dma size passed in to page size to avoid truncation
> and allocation failures on sizes less than PAGE_SIZE.
>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
> ---
> arch/arm64/mm/dma-mapping.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
> index 864b256..be2696e 100644
> --- a/arch/arm64/mm/dma-mapping.c
> +++ b/arch/arm64/mm/dma-mapping.c
> @@ -44,6 +44,8 @@ static void *arm64_swiotlb_alloc_coherent(struct device *dev, size_t size,
> flags |= GFP_DMA32;
> if (IS_ENABLED(CONFIG_CMA)) {
> unsigned long pfn;
> +
> + size = PAGE_ALIGN(size);
> pfn = dma_alloc_from_contiguous(dev, size >> PAGE_SHIFT,
> get_order(size));
The patch looks ok, but it doesn't apply. In my kernel (3.14-rc1),
dma_alloc_from_contiguous returns a struct page.
Thanks.
--
Catalin
^ permalink raw reply
* [PATCH v3 2/5] ASoC: tda998x: add a codec driver for the TDA998x
From: Mark Brown @ 2014-02-04 17:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140204181605.5b837a70@armhf>
On Tue, Feb 04, 2014 at 06:16:05PM +0100, Jean-Francois Moine wrote:
> Mark Brown <broonie@kernel.org> wrote:
> > > + /* load the optional CODEC */
> > > + of_platform_populate(np, NULL, NULL, &client->dev);
> > Why is this using of_platform_populate()? That's a very odd way of
> > doing things.
> The i2c does not populate the subnodes in the DT. I did not find why,
> but, what is sure is that if of_platform_populate() is not called, the
> tda CODEC module is not loaded.
You shouldn't be representing this as a separate node in the DT unless
there really is a distinct and reusable IP, otherwise you're putting
Linux implementation details in there. Describe the hardware, not the
implemementation.
> You may find an other example in drivers/mfd/twl-core.c.
The TWL drivers aren't always a shining example of how to do things -
they were one of the earliest MFDs so there's warts in there.
> > > +config SND_SOC_TDA998X
> > > + tristate
> > > + depends on OF
> > > + default y if DRM_I2C_NXP_TDA998X=y
> > > + default m if DRM_I2C_NXP_TDA998X=m
> > Make this visible if it can be selected from DT so it can be used with
> > generic cards.
> I don't understand. The tda CODEC can only be used with the TDA998x I2C
> driver. It might have been included in the tda998x source as well.
You shouldn't have the default settings there at all, that's not the
normal idiom for MFDs. I'd also not expect to have to build the CODEC
driver just because I built the DRM component.
> Now, the CODEC is declared inside the tda998x as a node child. But, in
> a bad DT, the tda CODEC could be declared anywhere, even inside a other
> DRM I2C slave encoder, in which case, bad things would happen...
So, part of the problem here is that this is being explicitly declared
in the DT leading to more sources for error.
> > What does this actually do? No information is being passed in to the
> > core function here, not even any information on if it's starting or
> > stopping. Looking at the rest of the code I can't help thinking it
> > might be clearer to inline this possibly with a lookup helper, the code
> > is very small and the lack of parameters makes it hard to follow.
> I thought it was simple enough. The function tda_start_stop() is called
> from 2 places:
It's not at all obvious - _audio_update() isn't a terribly descriptive
name, just looking at that function by itself I had no idea what it was
supposed to be doing.
> - on audio start in tda_startup with the audio type (DAI id)
> priv->dai_id = dai->id;
> - on audio stop with a null audio type
> priv->dai_id = 0; /* streaming stop */
> On stream start, the DAI id is never null, as explained in the patch 1:
> The audio format values in the encoder configuration interface are
> changed to non null values so that the value 0 is used in the audio
> function to indicate that audio streaming is stopped.
> and on streaming stop the port is not meaningful.
> I will add a null item in the enum (AFMT_NO_AUDIO).
So we can't use both streams simultaneously then? That's a bit sad.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140204/037aca8f/attachment.sig>
^ permalink raw reply
* [alsa-devel] [PATCH v3 2/5] ASoC: tda998x: add a codec driver for the TDA998x
From: Mark Brown @ 2014-02-04 17:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F0ECF2.9070102@metafoo.de>
On Tue, Feb 04, 2014 at 02:36:50PM +0100, Lars-Peter Clausen wrote:
> On 02/04/2014 02:30 PM, Mark Brown wrote:
> >>+static const struct snd_soc_dapm_route tda_routes[] = {
> >>+ { "hdmi-out", NULL, "HDMI I2S Playback" },
> >>+ { "hdmi-out", NULL, "HDMI SPDIF Playback" },
> >>+};
> >S/PDIF.
> Won't this cause issues with the debugfs widget entries? It's
> fixable by escaping it (replace it by a dash or something) in the
> debugfs widget filename, but I don't think we do this right now.
Oh, bother, so it will.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140204/bf5057df/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: at91: add Atmel's SAMA5D3 Xplained board
From: Nicolas Ferre @ 2014-02-04 17:42 UTC (permalink / raw)
To: linux-arm-kernel
Add DT file for new SAMA5D3 Xpained board.
This board is based on Atmel's SAMA5D36 Cortex-A5 SoC.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
arch/arm/boot/dts/at91-sama5d3_xplained.dts | 233 ++++++++++++++++++++++++++++
1 file changed, 233 insertions(+)
create mode 100644 arch/arm/boot/dts/at91-sama5d3_xplained.dts
diff --git a/arch/arm/boot/dts/at91-sama5d3_xplained.dts b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
new file mode 100644
index 000000000000..fb1349ca60a4
--- /dev/null
+++ b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
@@ -0,0 +1,233 @@
+/*
+ * at91-sama5d3_xplained.dts - Device Tree file for the SAMA5D3 Xplained board
+ *
+ * Copyright (C) 2014 Atmel,
+ * 2014 Nicolas Ferre <nicolas.ferre@atmel.com>
+ *
+ * Licensed under GPLv2 or later.
+ */
+/dts-v1/;
+#include "sama5d36.dtsi"
+
+/ {
+ model = "SAMA5D3 Xplained";
+ compatible = "atmel,sama5d3-xplained", "atmel,sama5d3", "atmel,sama5";
+
+ chosen {
+ bootargs = "console=ttyS0,115200";
+ };
+
+ memory {
+ reg = <0x20000000 0x10000000>;
+ };
+
+ ahb {
+ apb {
+ mmc0: mmc at f0000000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mmc0_clk_cmd_dat0 &pinctrl_mmc0_dat1_3 &pinctrl_mmc0_dat4_7 &pinctrl_mmc0_cd>;
+ status = "okay";
+ slot at 0 {
+ reg = <0>;
+ bus-width = <8>;
+ cd-gpios = <&pioE 0 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ spi0: spi at f0004000 {
+ cs-gpios = <&pioD 13 0>, <0>, <0>, <0>;
+ status = "okay";
+ };
+
+ can0: can at f000c000 {
+ status = "okay";
+ };
+
+ i2c0: i2c at f0014000 {
+ status = "okay";
+ };
+
+ i2c1: i2c at f0018000 {
+ status = "okay";
+ };
+
+ macb0: ethernet at f0028000 {
+ phy-mode = "rgmii";
+ status = "okay";
+ };
+
+ usart0: serial at f001c000 {
+ status = "okay";
+ };
+
+ usart1: serial at f0020000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usart1 &pinctrl_usart1_rts_cts>;
+ status = "okay";
+ };
+
+ uart0: serial at f0024000 {
+ status = "okay";
+ };
+
+ mmc1: mmc at f8000000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mmc1_clk_cmd_dat0 &pinctrl_mmc1_dat1_3 &pinctrl_mmc1_cd>;
+ status = "okay";
+ slot at 0 {
+ reg = <0>;
+ bus-width = <4>;
+ cd-gpios = <&pioE 1 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ spi1: spi at f8008000 {
+ cs-gpios = <&pioC 25 0>, <0>, <0>, <&pioD 16 0>;
+ status = "okay";
+ };
+
+ adc0: adc at f8018000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ &pinctrl_adc0_adtrg
+ &pinctrl_adc0_ad0
+ &pinctrl_adc0_ad1
+ &pinctrl_adc0_ad2
+ &pinctrl_adc0_ad3
+ &pinctrl_adc0_ad4
+ &pinctrl_adc0_ad5
+ &pinctrl_adc0_ad6
+ &pinctrl_adc0_ad7
+ &pinctrl_adc0_ad8
+ &pinctrl_adc0_ad9
+ >;
+ status = "okay";
+ };
+
+ i2c2: i2c at f801c000 {
+ dmas = <0>, <0>; /* Do not use DMA for i2c2 */
+ status = "okay";
+ };
+
+ macb1: ethernet at f802c000 {
+ phy-mode = "rmii";
+ status = "okay";
+ };
+
+ dbgu: serial at ffffee00 {
+ status = "okay";
+ };
+
+ pinctrl at fffff200 {
+ board {
+ pinctrl_mmc0_cd: mmc0_cd {
+ atmel,pins =
+ <AT91_PIOE 0 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>;
+ };
+
+ pinctrl_mmc1_cd: mmc1_cd {
+ atmel,pins =
+ <AT91_PIOE 1 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>;
+ };
+
+ pinctrl_usba_vbus: usba_vbus {
+ atmel,pins =
+ <AT91_PIOE 9 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>; /* PE9, conflicts with A9 */
+ };
+ };
+ };
+
+ pmc: pmc at fffffc00 {
+ main: mainck {
+ clock-frequency = <12000000>;
+ };
+ };
+ };
+
+ nand0: nand at 60000000 {
+ nand-bus-width = <8>;
+ nand-ecc-mode = "hw";
+ atmel,has-pmecc;
+ atmel,pmecc-cap = <4>;
+ atmel,pmecc-sector-size = <512>;
+ nand-on-flash-bbt;
+ status = "okay";
+
+ at91bootstrap at 0 {
+ label = "at91bootstrap";
+ reg = <0x0 0x40000>;
+ };
+
+ bootloader at 40000 {
+ label = "bootloader";
+ reg = <0x40000 0x80000>;
+ };
+
+ bootloaderenv at c0000 {
+ label = "bootloader env";
+ reg = <0xc0000 0xc0000>;
+ };
+
+ dtb at 180000 {
+ label = "device tree";
+ reg = <0x180000 0x80000>;
+ };
+
+ kernel at 200000 {
+ label = "kernel";
+ reg = <0x200000 0x600000>;
+ };
+
+ rootfs at 800000 {
+ label = "rootfs";
+ reg = <0x800000 0x0f800000>;
+ };
+ };
+
+ usb0: gadget at 00500000 {
+ atmel,vbus-gpio = <&pioE 9 GPIO_ACTIVE_HIGH>; /* PE9, conflicts with A9 */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usba_vbus>;
+ status = "okay";
+ };
+
+ usb1: ohci at 00600000 {
+ num-ports = <3>;
+ atmel,vbus-gpio = <0
+ &pioE 3 GPIO_ACTIVE_LOW
+ &pioE 4 GPIO_ACTIVE_LOW
+ >;
+ status = "okay";
+ };
+
+ usb2: ehci at 00700000 {
+ status = "okay";
+ };
+ };
+
+ gpio_keys {
+ compatible = "gpio-keys";
+
+ bp3 {
+ label = "PB_USER";
+ gpios = <&pioE 29 GPIO_ACTIVE_LOW>;
+ linux,code = <0x104>;
+ gpio-key,wakeup;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ d2 {
+ label = "d2";
+ gpios = <&pioE 23 GPIO_ACTIVE_LOW>; /* PE23, conflicts with A23, CTS2 */
+ linux,default-trigger = "heartbeat";
+ };
+
+ d3 {
+ label = "d3";
+ gpios = <&pioE 24 GPIO_ACTIVE_HIGH>;
+ };
+ };
+};
--
1.8.2.2
^ permalink raw reply related
* [PATCH 00/11] ARM: shmobile: RSPI RZ and QSPI SoC and board integration
From: Mark Brown @ 2014-02-04 17:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391527445-14881-1-git-send-email-geert@linux-m68k.org>
On Tue, Feb 04, 2014 at 04:23:54PM +0100, Geert Uytterhoeven wrote:
> Hi Simon, Magnus,
>
> This patch series contains SoC and board integration for
> 1. RSPI in the r7s72100 aka RZ/A1H SoC on the Genmai reference board,
> 2. QSPI in the r8a7791 aka R-Car M2 SoC on the Koelsch reference board.
> It was rebased on top of renesas-devel-v3.14-rc1-20140204.
Can you please stop CCing arch/arm only patch serieses like this to the
SPI list - they just mean I have to go through patchwork and mark them
as not applicable.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140204/cd832b70/attachment.sig>
^ permalink raw reply
* [PATCH v2 08/11] of: Increase MAX_PHANDLE_ARGS
From: Grant Likely @ 2014-02-04 17:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140117110830.GW3471@alberich>
On Fri, 17 Jan 2014 12:08:30 +0100, Andreas Herrmann <andreas.herrmann@calxeda.com> wrote:
>
> arm-smmu driver uses of_parse_phandle_with_args when parsing DT
> information to determine stream IDs for a master device.
> Thus the number of stream IDs per master device is bound by
> MAX_PHANDLE_ARGS.
>
> To support Calxeda ECX-2000 hardware arm-smmu driver requires a
> slightly higher value for MAX_PHANDLE_ARGS as this hardware has 10
> stream IDs for one master device.
>
> Increasing it to 16 seems a reasonable choice.
>
> Cc: Grant Likely <grant.likely@linaro.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: devicetree at vger.kernel.org
> Cc: Andreas Herrmann <herrmann.der.user@googlemail.com>
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Andreas Herrmann <andreas.herrmann@calxeda.com>
I've merged this one, but I'm not excited about making it any larger
because this structure lives on the stack most of the time.
g.
^ 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