* [PATCH v4 0/8] Device Tree support for the at91sam9261ek
From: Thomas Petazzoni @ 2014-02-12 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52FB5795.9020708@free-electrons.com>
Dear Gregory CLEMENT,
On Wed, 12 Feb 2014 12:14:29 +0100, Gregory CLEMENT wrote:
> For dm9000 the issue is (again) related to an ordering problem:
> the Ethernet need an interrupt provided by the gpio driver. Unfortunately,
> the gpio driver initialization is called after the dm900 driver
> initialization.
And -EPROBE_DEFER doesn't solve this problem?
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 1/4] arm64: topology: Implement basic CPU topology support
From: Mark Brown @ 2014-02-12 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140212102716.GE29702@arm.com>
On Wed, Feb 12, 2014 at 10:27:16AM +0000, Catalin Marinas wrote:
> On Wed, Feb 12, 2014 at 08:04:54AM +0000, Vincent Guittot wrote:
> > The fields will be used to construct topology so we must ensure their
> > visibility
> I wonder whether you need spinlocks around the topology updating code.
It certainly feels a lot safer to have them; if we can't convince
ourselves that the code is safe without them then there's very little
cost in having them so we may as well err on the side of doing that -
does that seem reasonable?
-------------- 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/20140212/a4dd9428/attachment.sig>
^ permalink raw reply
* [PATCH 00/12] Versatile Express updates
From: Pawel Moll @ 2014-02-12 12:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2782419.lfJiZZjaFg@wuerfel>
On Tue, 2014-02-11 at 19:28 +0000, Arnd Bergmann wrote:
> On Tuesday 11 February 2014 17:10:24 Pawel Moll wrote:
> > This series is a set of updates following the infrastructure
> > rework and depends on it. It will be finally posted once
> > the main series is merged. For the time being I would really
> > appreciate feedback and/or (n)acks...
>
> I haven't read the patches yet, but on a general level, do
> you think this code can be (or should) be shared with
> mach-versatile and mach-realview?
Haven't worked with the old ones too much, I just had a look at a couple
of TRMs... The sysregs look similar, don't they? Deceitfully
similar... ;-)
Let me start from the VE side and classify the registers into functional
groups, looking at them from a MFD cells point of view:
- general ID registers like SYS_ID, SYS_MISC, SYS_PROCIDx - either not
really useful for drivers or different bitmasks if needed (eg. the
MASTERSITE bit in SYS_MISC); in other words - good candidates for syscon
if at all interesting
- de-facto GPIO registers like SYS_LED, SYS_MCI, SYS_FLASH - easily
covered via "basic-mmio-gpio" driver; can be simply exposed in the tree
as subnodes
- flags (SYS_*FLAGS*) - used pretty much only for SMP booting; that's
where, I believe, we could unify and move the DT-based operations into
plat_versatile; it is too early for the device model though, so out of
the sysreg driver scope, really (even if the code lives here for now)
- counters (SYS_100HZ, SYS_24MHZ) - the 24MHz one is used on some of the
platforms as a sched clock source; in the fourth patch of the second
series I moved it out into drivers/clocksource - it could be easily
generalised and used across more platforms, but again - it's early code,
so out of sysreg driver scope
- system configuration (SYS_CFG*) - that's the main difference between
VE and its predecessors; the older seem to provide separate system
registers to control infrastructure like clocks etc. (eg. SYS_OSC* on
the realview boards), while here we have the (whatever you call it ;-)
config bus
- other registers that are currently not used at all, but most of them
differ either in naming (and location) or in offset.
All this leads, I believe, to conclusion that they definitely deserve
different compatible values. Therefore they would also require different
mfdcells definitions. Of course we could have more than one in a single
file and pick one via matching table but:
1. There is always that little "extra" (like the master site
configuration on VE, which doesn't happen on the previous ones)
2. I'd rather not to have the non-VE stuff in arm64 kernel.
So, to summarize, I think we need separate files for at least main
families of the sysreg drivers (I didn't spent enough time on this to be
able to find commonalities and differences inside realview and versatile
families), but try to share as much as possible of the "functional"
drivers (with the sched clock and the smp operations being the most
obvious candidates).
> One of the things on my (mid-term) to-do list is to completely
> convert those two platforms over to being entirely DT based
> and having no board specific code so we can actually delete
> the directories along with mach-vexpress
And I sympathise with this goal :-) (interestingly Olof in the past
expressed strong and opposite opinion in the subject ;-)
If you have a look at the last patch of the second series, you'll find
that what's left in the VEXPRESS_DT machine are smp operations and
l2x0_of_init. Then, assuming that we finally get some answer to the CLCD
problem (latest in this subject happened here:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/268037 - I really
lost all hopes for CDF getting anywhere...) removal of the non-DT code
is a matter of a single patch (and a massive negative stat :-). From
there there's only a bunch of PM-related files in arch/arm/mach-vexpress
that I guess could be moved somewhere else (that's what Olof didn't
really like).
Pawel
^ permalink raw reply
* [PATCH] ARM: dts: imx6qdl-sabresd: Do not place regulator nodes under simple-bus
From: Shawn Guo @ 2014-02-12 12:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140212095450.GB21992@e106331-lin.cambridge.arm.com>
On Wed, Feb 12, 2014 at 09:54:50AM +0000, Mark Rutland wrote:
> > I take it as an unnecessary churn, unless I see the consensus from most
> > of DT maintainers and arm-soc folks that we should make this change.
> > And see comment below ...
>
> My concern is that the simple-bus is being used in a nonsensical way,
> with a meaningless address space and reg values on children. While this
> currently works it is not correct, and it's not even necessary. I would
> like to limit the misuse of these constructs so as to prevent others
> from making the same mistakes.
Unfortunately, it's already been used quite widely. This is not IMX
specific, and you can grep arch/arm/boot/dts to get the idea. I'm not
sure if it's worth the churn to 'fix' it. In these days, arm-soc folks
are quite sensitive to the number of IMX patches and change sets. 50
LOC change for one board dts, and we now have ~70 files for IMX. That's
why I would like to get the agreement from arm-soc folks that we should
really make such change.
>
> >
> > >
> > > arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 51 ++++++++++++++--------------------
> > > 1 file changed, 21 insertions(+), 30 deletions(-)
> > >
> > > diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> > > index 0d816d3..d7df5b2 100644
> > > --- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> > > +++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> > > @@ -18,38 +18,29 @@
> > > reg = <0x10000000 0x40000000>;
> > > };
> > >
> > > - regulators {
> > > - compatible = "simple-bus";
> > > - #address-cells = <1>;
> > > - #size-cells = <0>;
> > > -
> > > - reg_usb_otg_vbus: regulator at 0 {
> > > - compatible = "regulator-fixed";
> > > - reg = <0>;
> > > - regulator-name = "usb_otg_vbus";
> > > - regulator-min-microvolt = <5000000>;
> > > - regulator-max-microvolt = <5000000>;
> > > - gpio = <&gpio3 22 0>;
> > > - enable-active-high;
> > > - };
> > > + reg_usb_otg_vbus: regulator at 0 {
> >
> > nodename at num should only be used for nodes that have 'reg' property.
> > Why are you dropping 'reg' property here? Right, it does not compile if
> > you do not drop it. You can take it as a reason of why I endorse
> > simple-bus regulators container.
>
> I don't think the logical jump from "it does not compile" to "I endorse
> simple-bus regulators container" makes any sense. They're two separate
> issues.
You're right :)
>
> The unit-addresses and reg values can be dropped. They are not in the
> regulator-fixed binding, and were never necessary. All that's necessary
> is a unique name, and unit-addresses (which required a reg) were misused
> to provide uniqueness. With that fixed, this will compile.
IIRC, ePAPR recommends to use generic node name and have
unit-addresses for uniqueness. That's why I sent patch [1] to follow
the way that tegra and other platforms names them. Now you're
suggesting to go back?
Shawn
[1] http://www.spinics.net/lists/arm-kernel/msg284474.html
^ permalink raw reply
* [PATCH] arm64: smp: Add a memory barrier before we start secondary cores
From: Will Deacon @ 2014-02-12 12:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392205594-29186-1-git-send-email-broonie@kernel.org>
On Wed, Feb 12, 2014 at 11:46:34AM +0000, Mark Brown wrote:
> From: Mark Brown <broonie@linaro.org>
>
> Ensure that memory writes will be visible to the newly started core by
> inserting a write barrier prior to starting. This adds robustness against
> possible incomplete synchronisation of state.
This is very vague. I still don't understand what this is being used for.
> Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Mark Brown <broonie@linaro.org>
> ---
> arch/arm64/kernel/smp.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index 9660750f34ba..f5520d8fafab 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -160,6 +160,11 @@ asmlinkage void secondary_start_kernel(void)
> smp_store_cpu_info(cpu);
>
> /*
> + * Ensure memory writes are visible before we start.
> + */
> + smp_wmb();
> +
> + /*
> * OK, now it's safe to let the boot CPU continue. Wait for
> * the CPU migration code to notice that the CPU is online
> * before we continue.
So right after this comment we complete(&cpu_running), which implies a write
barrier if we wake somebody up. The secondary coming up should be waiting on
that completion, so *that* is how synchronisation is achieved.
Without a concrete example of precisely why this is required, I'm not at all
happy taking patches adding random memory barriers.
Will
^ permalink raw reply
* [PATCH RFC v2 00/35] Second preview of imx-drm cleanup series
From: Christian Gmeiner @ 2014-02-12 12:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5A=4NS3J365+JQMnyNSfwdiPqTy4gDwNcwV2_ECySTBQg@mail.gmail.com>
2014-02-12 12:53 GMT+01:00 Fabio Estevam <festevam@gmail.com>:
> On Mon, Feb 10, 2014 at 10:28 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> This is the latest revision of my series cleaning up imx-drm and
>> hopefully getting it ready to be moved out of drivers/staging.
>> This series is updated to v3.14-rc2.
>>
>> Since the last round of patches were posted, the component support
>> has been merged into mainline, and thus dropped from this series.
>> Greg has taken the first three patches and merged them into his
>> linux-next tree - however, I include them here for completness.
>>
>> Most of the comments from last time still apply, and I'll look at
>> incorporating some of the other patches that were posted in the
>> coming week.
>>
>> If I can have some acks for this, I'll start sending some of it to
>> Greg - I'd like to at least get the five or six initial imx-hdmi
>> patches to Greg and queued up for the next merge window sooner
>> rather than later, preferably getting most of this ready for that
>> window too.
>
> Series looks good:
>
> Reviewed-by: Fabio Estevam <fabio.estevam@freescale.com>
>
> Patch 04/35 will not be needed in the final submission, as there is
> already a fix for the build issue in Greg's tree.
>
I am the only one who does not get the whole series?
Even here ony a handfull of patches are listed:
http://www.spinics.net/lists/arm-kernel/threads.html#306292
--
Christian Gmeiner, MSc
https://soundcloud.com/christian-gmeiner
^ permalink raw reply
* [PATCH 09/12] hwmon: vexpress: Use devm helper for hwmon device registration
From: Pawel Moll @ 2014-02-12 11:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392206196.848.18.camel@hornet>
On Wed, 2014-02-12 at 11:56 +0000, Pawel Moll wrote:
> > Third, I noticed that the 'label' attribute is always created but returns
> > -ENOENT if there is no label. A much better implementation would be to use
> > .is_visible and not create the label attribute if its devicetree entry
> > does not exist. I don't know how libsensors reacts to -ENOENT on a read,
> > but no matter how it does react, it is pretty much undefined.
> > Again, that should be handled in a separate patch.
Missed that one - will do as well.
Pawel
^ permalink raw reply
* [PATCH 02/12] power/reset: vexpress: Use udelay instead of timers
From: Pawel Moll @ 2014-02-12 11:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201402112159.16758.arnd@arndb.de>
On Tue, 2014-02-11 at 20:59 +0000, Arnd Bergmann wrote:
> On Tuesday 11 February 2014, Pawel Moll wrote:
> > At this stage of system shutdown procedure the jiffies may
> > not be updated anymore, so just use udelay instead.
>
> comment doesn't match code: s/udelay/mdelay/
>
> > + mdelay(1000);
> > }
Uh, right. Well spotted. Will fix.
Pawel
^ permalink raw reply
* [PATCH 09/12] hwmon: vexpress: Use devm helper for hwmon device registration
From: Pawel Moll @ 2014-02-12 11:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140212024904.GA19352@roeck-us.net>
On Wed, 2014-02-12 at 02:49 +0000, Guenter Roeck wrote:
> On Tue, Feb 11, 2014 at 05:10:33PM +0000, Pawel Moll wrote:
> > Use devm_hwmon_device_register_with_groups instead of
> > the old-style manual attributes and hwmon device registration.
> >
>
> [ ... ]
>
> > static int vexpress_hwmon_probe(struct platform_device *pdev)
> > {
> > - int err;
> > const struct of_device_id *match;
> > struct vexpress_hwmon_data *data;
> > + const char *name;
> > + const struct attribute_group **groups;
> >
> > data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
> > if (!data)
> > @@ -176,42 +151,19 @@ static int vexpress_hwmon_probe(struct platform_device *pdev)
> > return -ENODEV;
> >
>
> There is a leftover platform_set_drvdata() above which you can remove;
> attributes are now attached to the hwmon device and no longer
> to the platform device.
Right, missed this fact. Will remove.
BTW. It's cool that the attributes live in the class device now. You
probably don't remember, but in the very first version of the driver I
was trying to get this point with some tricks that weren't taken
nicely ;-)
> > - match = of_match_device(vexpress_hwmon_of_match, &pdev->dev);
> > - sysfs_remove_group(&pdev->dev.kobj, match->data);
> > + name = of_get_property(pdev->dev.of_node, "compatible", NULL);
>
> Couple of problems, two of which escaped me earlier.
> First, can of_get_property ever return NULL ? I think not, just wondering.
Generally it can, but not in this particular case, no. The device
wouldn't get bound to the driver if it lacked the "compatible" property.
> Second is a real problem. You have a '-' in the compatible property which is
> illegal for the 'name' attribute in hwmon devices. It messes up libsensors
> and thus every application using it. Not sure what a good fix (or name)
> would be; simplest might be to copy the name string and replace it with '_'.
> Sorry for not noticing this earlier; it might actually make sense to submit
> a separate patch to address this so we can apply it to the current kernel
> and if necessary patch it into earlier kernels.
Ok, will do. Either with s/-/_/ or with a name lookup table.
Interestingly enough I never observed any problem with libsensors (3.3.2
was the one I used) on my board...
> Third, I noticed that the 'label' attribute is always created but returns
> -ENOENT if there is no label. A much better implementation would be to use
> .is_visible and not create the label attribute if its devicetree entry
> does not exist. I don't know how libsensors reacts to -ENOENT on a read,
> but no matter how it does react, it is pretty much undefined.
> Again, that should be handled in a separate patch.
> I agree with Arnd that it would be nice to get rid of the local macro,
> but I won't mandate that.
I actually prefer to have the structures unfolded, but was just trying
to mimic the trend in other hwmon drivers. No problem - will change this
gladly.
Pawel
^ permalink raw reply
* [PATCH RFC v2 00/35] Second preview of imx-drm cleanup series
From: Fabio Estevam @ 2014-02-12 11:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140210122802.GS26684@n2100.arm.linux.org.uk>
On Mon, Feb 10, 2014 at 10:28 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> This is the latest revision of my series cleaning up imx-drm and
> hopefully getting it ready to be moved out of drivers/staging.
> This series is updated to v3.14-rc2.
>
> Since the last round of patches were posted, the component support
> has been merged into mainline, and thus dropped from this series.
> Greg has taken the first three patches and merged them into his
> linux-next tree - however, I include them here for completness.
>
> Most of the comments from last time still apply, and I'll look at
> incorporating some of the other patches that were posted in the
> coming week.
>
> If I can have some acks for this, I'll start sending some of it to
> Greg - I'd like to at least get the five or six initial imx-hdmi
> patches to Greg and queued up for the next merge window sooner
> rather than later, preferably getting most of this ready for that
> window too.
Series looks good:
Reviewed-by: Fabio Estevam <fabio.estevam@freescale.com>
Patch 04/35 will not be needed in the final submission, as there is
already a fix for the build issue in Greg's tree.
Regards,
Fabio Estevam
^ permalink raw reply
* [RFC/PATCH 0/3] Add devicetree scanning for randomness
From: Arnd Bergmann @ 2014-02-12 11:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392168805-14200-1-git-send-email-lauraa@codeaurora.org>
On Wednesday 12 February 2014, Laura Abbott wrote:
> This is an RFC to seed the random number pool earlier when using devicetree.
> The big issue this is trying to solve is the fact that the stack canary for
> ARM tends to be the same across bootups of the same device. This is because
> the random number pools do not get initialized until after the canary has
> been set up. The canary can be moved later, but in general there is still
> no way to reliably get random numbers early for other features (e.g. vector
> randomization).
Implementation-wise this looks reasonable, and it obviously addresses a
very real problem.
> The goal here is to allow devices to add to the random pools via
> add_device_randomness or some other method of their chosing at FDT time.
> I realize that ARCH_RANDOM is already available but this didn't work because
> 1) ARCH_RANDOM is not multi-platform compatible without added
> infrastructure to ARM
That could certainly be done, but I agree that a more generic
approach like you did is nicer. One thing that might be useful
would be to wire up your OF_RANDOM infrastructure as a generic
implementation of ARCH_RANDOM, and merge your header file into
include/asm-generic/archrandom.h, with an added way to call
arch_get_random_long() for the devices you add.
> The big reason to skip ARCH_RANDOM though is that the random number generation
> we have would be reasonable if only seeded earlier.
Yes, makes sense.
I also wonder if we should add a 'trivial' implementation that just
reads a DT property full of random numbers to use as either an initial
seed, or to feed into arch_get_random_long(). This would allow the
boot loader to pass any entropy it has already gathered into the kernel,
but leaves the danger that people might pass static not-so-random data
through a precompiled dtb file ;-). If we get the boot loaders to be
smart enough, doing only this would be a much simpler kernel implementation
than your suggestion, but I'm not sure how far I want to trust boot loaders.
Another possibilitiy is to mix in the any contents of a "local-mac-address"
property into the entropy at early DT probing, which would still be
deterministic for a given machine and should not count as entropty,
but at least give each machine with this property a unique seed in the
absence of any other entropy source.
Arnd
^ permalink raw reply
* [PATCH 0/3] arm64: Use pte manipulation functions for THP
From: Steve Capper @ 2014-02-12 11:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140212102112.GE13441@mudshark.cambridge.arm.com>
On Wed, Feb 12, 2014 at 10:21:12AM +0000, Will Deacon wrote:
> On Wed, Feb 12, 2014 at 10:16:02AM +0000, Catalin Marinas wrote:
> > On Wed, Feb 12, 2014 at 10:07:37AM +0000, Will Deacon wrote:
> > > On Wed, Feb 12, 2014 at 09:43:39AM +0000, Steve Capper wrote:
> > > > On Thu, Feb 06, 2014 at 02:16:08PM +0000, Steve Capper wrote:
> > > > > This series replaces the Transparent HugePage pmd manipulation
> > > > > functions with calls to the standard pte functions. This allows the THP
> > > > > code to take advantage of the new PTE_WRITE logic, and provides better
> > > > > parity with the HugeTLB code (which already uses the pte functions).
> > > > >
> > > > > Testing was done on the Fast Model with LTP THP tests, and the 3.14-rc1
> > > > > kernel was used.
> > > >
> > > > Does this series look reasonable?
> > >
> > > I was waiting for the corresponding arch/arm/ changes.
> >
> > The arch/arm/ code doesn't have the PTE_WRITE changes. It's a bit more
> > work here because of the classic MMU (but I hope Steve will get there ;).
>
> Indeed, but I'm wary of divergence in the mm code between the two
> architectures and I'd much rather we try to keep them in sync, rather than
> improve/bug fix in one before porting the whole lot over.
I do think we need the same behaviour for 3-level code on ARM and for
ARM64.
The PTE_WRITE changes for ARM64 allow one to distinguish between
writable clean ptes and read only ptes which fixes a very subtle
problem with huge pages (and maybe some other problems). This problem
is still present in the ARM 3-level code.
The ARM 2-level code stores a separate linux/hardware pte and it is
possible to distinguish between writable clean ptes and read only ptes.
For ARM, I would like to split out some of the pte logic and page
permissions from pgtable.h into pgtable-[23]level.h. Then introduce
PTE_WRITE for the 3-level code on ARM.
Russell,
I have noticed the following for ARM:
36bb94b ARM: pgtable: provide RDONLY page table bit rather than WRITE bit
Are you happy for me to re-introduce PTE_WRITE for the 3-level code
only, and keep L_PTE_RDONLY for the 2-level code?
Thanks,
--
Steve
^ permalink raw reply
* [PATCH] ARM: shmobile: set proper DMA masks for Ether devices
From: Ben Dooks @ 2014-02-12 11:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201402120255.25037.sergei.shtylyov@cogentembedded.com>
On 11/02/14 23:55, Sergei Shtylyov wrote:
> Ether MAC is a DMA-capable device and so should have 'dev.dma_mask' and
> 'dev.coherent_dma_mask' fields set properly, to reflect 32-bit DMA addressing
> ability. Currently, the code works without DMA masks but in the future, when
> support for NETIF_F_HIGHDMA & NETIF_F_SG would be added to the 'sh_eth' driver,
> the DMA masks should start to matter...
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Hi, do you have a git branch available with all the changes for getting
ethernet working on rcar please?
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply
* [PATCH 4/7] spi: pl022: attempt to get sspclk by name
From: Mark Rutland @ 2014-02-12 11:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201402121221.51233.arnd@arndb.de>
On Wed, Feb 12, 2014 at 11:21:50AM +0000, Arnd Bergmann wrote:
> On Wednesday 12 February 2014, Mark Rutland wrote:
> > To me it feels odd to require the last clock in the list (apb_pclk) to
> > be named, and the rest to be in a particular order. For the dt case it
> > seems saner to add new clocks with names as it allows arbitrary subsets
> > of clocks to be wired up and described (though obviously in this case a
> > missing sspclk would be problematic).
>
> Yes, good point about the missing clocks, and I also agree mixing ordered
> and named clocks in one device is rather odd and can lead to trouble.
>
> I guess there isn't really a good way out here, and I certainly won't
> ask for it to be done one way or the other if someone else has a
> good argument which way it should be implemented.
Having thought about it, all dts that for the ssp_pclk must have some
name for the sspclk (though the specific name is arbitrary). I could get
the driver to try each of those before falling back to the index
(perhaps with a helper that takes a list of known aliases), so all
existing dts (that we are aware of) would work with the clock requested
by name.
I assume that for the non-dt case it's possible to name clock inputs to
a device without the clock being associated with the name globally? If
so we could get rid of the index usage entirely in this case.
Does that sound workable?
Thanks,
Mark.
^ permalink raw reply
* [PATCH] arm64: smp: Add a memory barrier before we start secondary cores
From: Mark Brown @ 2014-02-12 11:46 UTC (permalink / raw)
To: linux-arm-kernel
From: Mark Brown <broonie@linaro.org>
Ensure that memory writes will be visible to the newly started core by
inserting a write barrier prior to starting. This adds robustness against
possible incomplete synchronisation of state.
Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
---
arch/arm64/kernel/smp.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 9660750f34ba..f5520d8fafab 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -160,6 +160,11 @@ asmlinkage void secondary_start_kernel(void)
smp_store_cpu_info(cpu);
/*
+ * Ensure memory writes are visible before we start.
+ */
+ smp_wmb();
+
+ /*
* OK, now it's safe to let the boot CPU continue. Wait for
* the CPU migration code to notice that the CPU is online
* before we continue.
--
1.9.0.rc3
^ permalink raw reply related
* [PATCH 07/12] mfd: syscon: Consider platform data a regmap config name
From: Pawel Moll @ 2014-02-12 11:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392204460.1197803@f433.i.mail.ru>
On Wed, 2014-02-12 at 11:27 +0000, Alexander Shiyan wrote:
> Yeah, I gave up the idea to use the syscon_ids[] to separate devices for
> non-DT case.
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/mfd/syscon.c?id=5104d2656d4874c51868dc7182016e9501ec99ca
> Instead, I use a hard definition for pdev->id, so that the names of
> syscon-devices are different and can be obtained from the driver
> it uses with syscon_regmap_lookup_by_pdevname().
It is a sort-of-solution (I personally dislike magic numbers, but this
is a separate discussion) for a completely-non-DT case, where you can
guarantee limited number of syscon devices.
In my case I have a DT system, where some of the MFD devices *may*
register syscon cells... No way to enforce ordering.
> I understand this topic correct?
The main idea here is to attach a meaningful label to the syscon
regmaps. My example:
/ # ls -d1 /sys/kernel/debug/regmap/syscon.*
/sys/kernel/debug/regmap/syscon.0.auto
/sys/kernel/debug/regmap/syscon.4.auto
/sys/kernel/debug/regmap/syscon.5.auto
vs
/ # ls -d /sys/kernel/debug/regmap/syscon.*
/sys/kernel/debug/regmap/syscon.0.auto-sys_id
/sys/kernel/debug/regmap/syscon.4.auto-sys_misc
/sys/kernel/debug/regmap/syscon.5.auto-sys_procid
Of course one could also define syscon_regmap_lookup_by_label() (I don't
really need it right now so didn't go that way)
Pawel
^ permalink raw reply
* [PATCH] MTD: atmel_nand: POI fall back is not an issue: change log level
From: Alexandre Belloni @ 2014-02-12 11:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392204414-20700-1-git-send-email-nicolas.ferre@atmel.com>
Small nitpick, subject should read PIO, not POI.
On 12/02/2014 at 12:26:54 +0100, Nicolas Ferre wrote :
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> drivers/mtd/nand/atmel_nand.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
> index c36e9b84487c..8d210f8a072d 100644
> --- a/drivers/mtd/nand/atmel_nand.c
> +++ b/drivers/mtd/nand/atmel_nand.c
> @@ -430,7 +430,7 @@ err_dma:
> dma_unmap_single(dma_dev->dev, phys_addr, len, dir);
> err_buf:
> if (err != 0)
> - dev_warn(host->dev, "Fall back to CPU I/O\n");
> + dev_dbg(host->dev, "Fall back to CPU I/O\n");
> return err;
> }
>
> --
> 1.8.2.2
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board
From: Marc Zyngier @ 2014-02-12 11:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140212112946.GD21992@e106331-lin.cambridge.arm.com>
On 12/02/14 11:29, Mark Rutland wrote:
>>>> + gic: interrupt-controller at 1C000000 {
>>>> + compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic";
>>>
>>> This looks incorrect -- you should at the very least have a more
>>> specific one than a15-gic? Marc?
>>
>> "arm,cortex-a9-gic" is definitely wrong (the A9 GIC doesn't have the
>> virt extensions). This binding matches what the A15 GIC has, so
>> "arm,cortex-a15-gic" is probably fine. Main issue here is that the GICv2
>> driver has no compatible string for anything else.
>>
>> Should we define something more generic (like "arm,gic-v2")? Or carry on
>> adding more compatible strings?
>
> It's been proposed repeatedly, and it probably makes sense to add the
> generic versions to the driver, and allow for more specific ones in the
> binding which DTs can use. That way we don't get an explosion of strings
> in the driver, but if we need to handle any particular GIC specially in
> future we can do so.
>
> I guess for Linux we'd want to add "arm,gic-v1" and "arm,gic-v2" to the
> driver. We could just add "arm,gic-v1" and expect it later in the
> compatible list if v2 is a strict superset of v1; I think it is but I'm
> not a GIC expert.
Sounds good to me.
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH RFC v3 3/3] Documentation: arm: define DT idle states bindings
From: Amit Kachhap @ 2014-02-12 11:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392128273-8614-4-git-send-email-lorenzo.pieralisi@arm.com>
Hi Lorenzo,
This patch series looks nice and explains the ARM C state DT bindings clearly.
Couples of thoughts below.
On 2/11/14, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
> ARM based platforms implement a variety of power management schemes that
> allow processors to enter idle states at run-time.
> The parameters defining these idle states vary on a per-platform basis
> forcing
> the OS to hardcode the state parameters in platform specific static tables
> whose size grows as the number of platforms supported in the kernel
> increases
> and hampers device drivers standardization.
>
> Therefore, this patch aims at standardizing idle state device tree bindings
> for
> ARM platforms. Bindings define idle state parameters inclusive of entry
> methods
> and state latencies, to allow operating systems to retrieve the
> configuration
> entries from the device tree and initialize the related power management
> drivers, paving the way for common code in the kernel to deal with idle
> states and removing the need for static data in current and previous kernel
> versions.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> ---
> Documentation/devicetree/bindings/arm/cpus.txt | 10 +
> Documentation/devicetree/bindings/arm/idle-states.txt | 690 ++++++++++
> 2 files changed, 700 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt
> b/Documentation/devicetree/bindings/arm/cpus.txt
> index 9130435..fb7f008 100644
> --- a/Documentation/devicetree/bindings/arm/cpus.txt
> +++ b/Documentation/devicetree/bindings/arm/cpus.txt
> @@ -191,6 +191,13 @@ nodes to be present and contain the properties
> described below.
> property identifying a 64-bit zero-initialised
> memory location.
>
> + - cpu-idle-states
> + Usage: Optional
> + Value type: <prop-encoded-array>
> + Definition:
> + # List of phandles to cpu idle state nodes supported
> + by this cpu [1].
> +
> Example 1 (dual-cluster big.LITTLE system 32-bit):
>
> cpus {
> @@ -382,3 +389,6 @@ cpus {
> cpu-release-addr = <0 0x20000000>;
> };
> };
> +
> +[1] ARM Linux kernel documentation - idle state bindings
> + Documentation/devicetree/bindings/arm/idle-states.txt
> diff --git a/Documentation/devicetree/bindings/arm/idle-states.txt
> b/Documentation/devicetree/bindings/arm/idle-states.txt
> new file mode 100644
> index 0000000..f155e70
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/idle-states.txt
> @@ -0,0 +1,690 @@
> +==========================================
> +ARM idle states binding description
> +==========================================
> +
> +==========================================
> +1 - Introduction
> +==========================================
> +
> +ARM systems contain HW capable of managing power consumption dynamically,
> +where cores can be put in different low-power states (ranging from simple
> +wfi to power gating) according to OSPM policies. The CPU states
> representing
> +the range of dynamic idle states that a processor can enter at run-time,
> can be
> +specified through device tree bindings representing the parameters
> required
> +to enter/exit specific idle states on a given processor.
> +
> +According to the Server Base System Architecture document (SBSA, [3]), the
> +power states an ARM CPU can be put into are identified by the following
> list:
> +
> +1 - Running
> +2 - Idle_standby
> +3 - Idle_retention
> +4 - Sleep
> +5 - Off
> +
> +ARM platforms implement the power states specified in the SBSA through
> power
> +management schemes that allow an OS PM implementation to put the processor
> in
> +different idle states (which include states 1 to 4 above; "off" state is
> not
> +an idle state since it does not have wake-up capabilities, hence it is not
> +considered in this document).
> +
> +Idle state parameters (eg entry latency) are platform specific and need to
> be
> +characterized with bindings that provide the required information to OSPM
> +code so that it can build the required tables and use them at runtime.
> +
> +The device tree binding definition for ARM idle states is the subject of
> this
> +document.
> +
> +===========================================
> +2 - cpu-idle-states node
> +===========================================
> +
> +ARM processor idle states are defined within the cpu-idle-states node,
> which is
> +a direct child of the cpus node and provides a container where the
> processor
> +states, defined as device tree nodes, are listed.
> +
> +- cpu-idle-states node
> +
> + Usage: Optional - On ARM systems, is a container of processor idle
> + states nodes. If the system does not provide CPU
> + power management capabilities or the processor just
> + supports idle_standby a cpu-idle-states node is not
> + required.
> +
> + Description: cpu-idle-states node is a container node, where its
> + subnodes describe the CPU idle states.
> +
> + Node name must be "cpu-idle-states".
> +
> + The cpu-idle-states node's parent node must be the cpus node.
> +
> + The cpu-idle-states node's child nodes can be:
> +
> + - one or more state nodes
> +
> + Any other configuration is considered invalid.
> +
> +The nodes describing the idle states (state) can only be defined within
> the
> +cpu-idle-states node.
> +
> +Any other configuration is consider invalid and therefore must be ignored.
> +
> +===========================================
> +2 - state node
> +===========================================
> +
> +A state node represents an idle state description and must be defined as
> +follows:
> +
> +- state node
> +
> + Description: must be child of either the cpu-idle-states node or
> + a state node.
> +
> + The state node name shall be "stateN", where N = {0, 1, ...} is
> + the node number; state nodes which are siblings within a single common
> + parent node must be given a unique and sequential N value, starting
> + from 0.
> +
> + A state node can contain state child nodes. A state node with
> + children represents a hierarchical state, which is a superset of
> + the child states. Hierarchical states require all CPUs on which
> + they are valid to request the state in order for it to be entered.
> +
> + A state node defines the following properties:
> +
> + - compatible
> + Usage: Required
> + Value type: <stringlist>
> + Definition: Must be "arm,cpu-idle-state".
> +
> + - index
> + Usage: Required
> + Value type: <u32>
> + Definition: It represents an idle state index, starting from 2.
> + Index 0 represents the processor state "running"
> + and index 1 represents processor mode
> + "idle_standby", entered by executing a wfi
> + instruction (SBSA,[3]); indexes 0 and 1 are
> + standard ARM states that need not be described.
> +
> + - entry-method
> + Usage: Required
> + Value type: <stringlist>
> + Definition: Describes the method by which a CPU enters the
> + idle state. This property is required and must be
> + one of:
> +
> + - "arm,psci-cpu-suspend"
> + ARM PSCI firmware interface, CPU suspend
> + method[2].
> +
> + - "[vendor],[method]"
> + An implementation dependent string with
> + format "vendor,method", where vendor is a string
> + denoting the name of the manufacturer and
> + method is a string specifying the mechanism
> + used to enter the idle state.
> +
> + - power-state
> + Usage: See definition.
> + Value type: <u32>
> + Definition: Depends on the entry-method property value.
> + If entry-method is "arm,psci-cpu-suspend":
> + # Property is required and represents
> + psci-power-state parameter. Please refer to
> + [2] for PSCI bindings definition.
> +
> + - entry-latency
> + Usage: Required
> + Value type: <prop-encoded-array>
> + Definition: u32 value representing worst case latency
> + in microseconds required to enter the idle state.
I liked your V2 version of OPP based latency more. However in this way
also latency supplied can correspond to max OPP and based on the
current OPP, the cpuidle driver can compute the new latency
proportionately. In case of frequency this can be linear but may not
be linear for residency.
> +
> + - exit-latency
> + Usage: Required
> + Value type: <prop-encoded-array>
> + Definition: u32 value representing worst case latency
> + in microseconds required to exit the idle state.
> +
> + - min-residency
> + Usage: Required
> + Value type: <prop-encoded-array>
> + Definition: u32 value representing time in microseconds
> + required for the CPU to be in the idle state to
> + make up for the dynamic power consumed to
> + enter/exit the idle state in order to break even
> + in terms of power consumption compared to idle
> + state index 1 (idle_standby).
> +
> + - power-domains
> + Usage: Optional
> + Value type: <prop-encoded-array>
> + Definition: List of power domain specifiers ([1]) describing
> + the power domains that are affected by the idle
> + state entry.
I can see power-domains used in 2 places. First in C state definitions
and second in cpu node cache descriptions. I am not sure but if
possible than this can be put in one place.
> +
> + - cache-state-retained
> + Usage: See definition
> + Value type: <none>
> + Definition: if present cache memory is retained on power down,
> + otherwise it is lost.
Can the DT bindings support both retained and non-retained with
different C states? The example shown does not use the retained flag.
I guess than many combinations are possible.
Processor retained, cache non-retained = C state 2
Processor non retained , cache retained = C state 3
Processor non retained, cache non retained = C state 4
> +
> + - processor-state-retained
> + Usage: See definition
> + Value type: <none>
> + Definition: if present CPU processor logic is retained on
> + power down, otherwise it is lost.
> +
> +===========================================
> +3 - Examples
> +===========================================
> +
> +Example 1 (ARM 64-bit, 16-cpu system):
> +
> +pd_clusters: power-domain-clusters at 80002000 {
> + compatible = "arm,power-controller";
> + reg = <0x0 0x80002000 0x0 0x1000>;
> + #power-domain-cells = <1>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + pd_cores: power-domain-cores at 80000000 {
> + compatible = "arm,power-controller";
> + reg = <0x0 0x80000000 0x0 0x1000>;
> + #power-domain-cells = <1>;
> + };
> +};
> +
> +cpus {
> + #size-cells = <0>;
> + #address-cells = <2>;
> +
> + cpu-idle-states {
> +
> + STATE0: state0 {
> + compatible = "arm,cpu-idle-state";
> + index = <3>;
> + entry-method = "arm,psci-cpu-suspend";
> + psci-power-state = <0x1010000>;
> + entry-latency = <500>;
> + exit-latency = <1000>;
> + min-residency = <2500>;
> + power-domains = <&pd_clusters 0>;
> + STATE0_1: state0 {
> + compatible = "arm,cpu-idle-state";
> + index = <2>;
> + entry-method = "arm,psci-cpu-suspend";
> + psci-power-state = <0x0010000>;
> + entry-latency = <200>;
> + exit-latency = <400>;
> + min-residency = <300>;
> + power-domains = <&pd_cores 0>,
> + <&pd_cores 1>,
> + <&pd_cores 2>,
> + <&pd_cores 3>,
> + <&pd_cores 4>,
> + <&pd_cores 5>,
> + <&pd_cores 6>,
> + <&pd_cores 7>;
> + };
> + };
> +
> + STATE1: state1 {
> + compatible = "arm,cpu-idle-state";
> + index = <3>;
> + entry-method = "arm,psci-cpu-suspend";
> + psci-power-state = <0x1010000>;
> + entry-latency = <1000>;
> + exit-latency = <3000>;
> + min-residency = <6500>;
> + power-domains = <&pd_clusters 1>;
> + STATE1_0: state0 {
> + compatible = "arm,cpu-idle-state";
> + index = <2>;
> + entry-method = "arm,psci-cpu-suspend";
> + psci-power-state = <0x0010000>;
> + entry-latency = <200>;
> + exit-latency = <400>;
> + min-residency = <500>;
> + power-domains = <&pd_cores 8>,
> + <&pd_cores 9>,
> + <&pd_cores 10>,
> + <&pd_cores 11>,
> + <&pd_cores 12>,
> + <&pd_cores 13>,
> + <&pd_cores 14>,
> + <&pd_cores 15>;
> + };
> + };
> + };
> +
> + CPU0: cpu at 0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a57";
> + reg = <0x0 0x0>;
> + enable-method = "psci";
> + next-level-cache = <&L1_0>;
> + cpu-idle-states = <&STATE0_1 &STATE0>;
> + L1_0: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_0>;
> + power-domain = <&pd_cores 0>;
> + };
> + L2_0: l2-cache {
> + compatible = "arm,arch-cache";
> + power-domain = <&pd_clusters 0>;
> + };
> + };
> +
> + CPU1: cpu at 1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a57";
> + reg = <0x0 0x1>;
> + enable-method = "psci";
> + next-level-cache = <&L1_1>;
> + cpu-idle-states = <&STATE0_1 &STATE0>;
> + L1_1: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_0>;
> + power-domain = <&pd_cores 1>;
> + };
> + };
> +
> + CPU2: cpu at 100 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a57";
> + reg = <0x0 0x100>;
> + enable-method = "psci";
> + next-level-cache = <&L1_2>;
> + cpu-idle-states = <&STATE0_1 &STATE0>;
> + L1_2: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_0>;
> + power-domain = <&pd_cores 2>;
> + };
> + };
> +
> + CPU3: cpu at 101 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a57";
> + reg = <0x0 0x101>;
> + enable-method = "psci";
> + next-level-cache = <&L1_3>;
> + cpu-idle-states = <&STATE0_1 &STATE0>;
> + L1_3: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_0>;
> + power-domain = <&pd_cores 3>;
> + };
> + };
> +
> + CPU4: cpu at 10000 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a57";
> + reg = <0x0 0x10000>;
> + enable-method = "psci";
> + next-level-cache = <&L1_4>;
> + cpu-idle-states = <&STATE0_1 &STATE0>;
> + L1_4: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_0>;
> + power-domain = <&pd_cores 4>;
> + };
> + };
> +
> + CPU5: cpu at 10001 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a57";
> + reg = <0x0 0x10001>;
> + enable-method = "psci";
> + next-level-cache = <&L1_5>;
> + cpu-idle-states = <&STATE0_1 &STATE0>;
> + L1_5: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_0>;
> + power-domain = <&pd_cores 5>;
> + };
> + };
> +
> + CPU6: cpu at 10100 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a57";
> + reg = <0x0 0x10100>;
> + enable-method = "psci";
> + next-level-cache = <&L1_6>;
> + cpu-idle-states = <&STATE0_1 &STATE0>;
> + L1_6: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_0>;
> + power-domain = <&pd_cores 6>;
> + };
> + };
> +
> + CPU7: cpu at 10101 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a57";
> + reg = <0x0 0x10101>;
> + enable-method = "psci";
> + next-level-cache = <&L1_7>;
> + cpu-idle-states = <&STATE0_1 &STATE0>;
> + L1_7: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_0>;
> + power-domain = <&pd_cores 7>;
> + };
> + };
> +
> + CPU8: cpu at 100000000 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x1 0x0>;
> + enable-method = "psci";
> + next-level-cache = <&L1_8>;
> + cpu-idle-states = <&STATE1_0 &STATE1>;
> + L1_8: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_1>;
> + power-domain = <&pd_cores 8>;
> + };
> + L2_1: l2-cache {
> + compatible = "arm,arch-cache";
> + power-domain = <&pd_clusters 1>;
> + };
> + };
> +
> + CPU9: cpu at 100000001 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x1 0x1>;
> + enable-method = "psci";
> + next-level-cache = <&L1_9>;
> + cpu-idle-states = <&STATE1_0 &STATE1>;
> + L1_9: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_1>;
> + power-domain = <&pd_cores 9>;
> + };
> + };
> +
> + CPU10: cpu at 100000100 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x1 0x100>;
> + enable-method = "psci";
> + next-level-cache = <&L1_10>;
> + cpu-idle-states = <&STATE1_0 &STATE1>;
> + L1_10: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_1>;
> + power-domain = <&pd_cores 10>;
> + };
> + };
> +
> + CPU11: cpu at 100000101 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x1 0x101>;
> + enable-method = "psci";
> + next-level-cache = <&L1_11>;
> + cpu-idle-states = <&STATE1_0 &STATE1>;
> + L1_11: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_1>;
> + power-domain = <&pd_cores 11>;
> + };
> + };
> +
> + CPU12: cpu at 100010000 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x1 0x10000>;
> + enable-method = "psci";
> + next-level-cache = <&L1_12>;
> + cpu-idle-states = <&STATE1_0 &STATE1>;
> + L1_12: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_1>;
> + power-domain = <&pd_cores 12>;
> + };
> + };
> +
> + CPU13: cpu at 100010001 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x1 0x10001>;
> + enable-method = "psci";
> + next-level-cache = <&L1_13>;
> + cpu-idle-states = <&STATE1_0 &STATE1>;
> + L1_13: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_1>;
> + power-domain = <&pd_cores 13>;
> + };
> + };
> +
> + CPU14: cpu at 100010100 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x1 0x10100>;
> + enable-method = "psci";
> + next-level-cache = <&L1_14>;
> + cpu-idle-states = <&STATE1_0 &STATE1>;
> + L1_14: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_1>;
> + power-domain = <&pd_cores 14>;
> + };
> + };
> +
> + CPU15: cpu at 100010101 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x1 0x10101>;
> + enable-method = "psci";
> + next-level-cache = <&L1_15>;
> + cpu-idle-states = <&STATE1_0 &STATE1>;
> + L1_15: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_1>;
> + power-domain = <&pd_cores 15>;
> + };
> + };
> +};
> +
> +Example 2 (ARM 32-bit, 8-cpu system, two clusters):
> +
> +pd_clusters: power-domain-clusters at 80002000 {
> + compatible = "arm,power-controller";
> + reg = <0x80002000 0x1000>;
> + #power-domain-cells = <1>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + pd_cores: power-domain-cores at 80000000 {
> + compatible = "arm,power-controller";
> + reg = <0x80000000 0x1000>;
> + #power-domain-cells = <1>;
> + };
> +};
> +
> +cpus {
> + #size-cells = <0>;
> + #address-cells = <1>;
> +
> + cpu-idle-states {
> +
> + STATE0: state0 {
> + compatible = "arm,cpu-idle-state";
> + index = <3>;
> + entry-method = "psci";
> + psci-power-state = <0x1010000>;
> + entry-latency = <1000>;
> + exit-latency = <1500>;
> + min-residency = <1500>;
> + power-domains = <&pd_clusters 0>;
> + STATE0_1: state0 {
> + compatible = "arm,cpu-idle-state";
> + index = <2>;
> + entry-method = "psci";
> + psci-power-state = <0x0010000>;
> + entry-latency = <400>;
> + exit-latency = <500>;
> + min-residency = <300>;
> + power-domains = <&pd_cores 0>,
> + <&pd_cores 1>,
> + <&pd_cores 2>,
> + <&pd_cores 3>;
> + };
> + };
> +
> + STATE1: state1 {
> + compatible = "arm,cpu-idle-state";
> + index = <3>;
> + entry-method = "psci";
> + psci-power-state = <0x1010000>;
> + entry-latency = <800>;
> + exit-latency = <2000>;
> + min-residency = <6500>;
> + power-domains = <&pd_clusters 1>;
> + STATE1_0: state0 {
> + compatible = "arm,cpu-idle-state";
> + index = <2>;
> + entry-method = "psci";
> + psci-power-state = <0x0010000>;
> + entry-latency = <300>;
> + exit-latency = <500>;
> + min-residency = <500>;
> + power-domains = <&pd_cores 4>,
> + <&pd_cores 5>,
> + <&pd_cores 6>,
> + <&pd_cores 7>;
> + };
> + };
> + };
> +
> + CPU0: cpu at 0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a15";
> + reg = <0x0>;
> + next-level-cache = <&L1_0>;
> + cpu-idle-states = <&STATE0_1 &STATE0>;
> + L1_0: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_0>;
> + power-domain = <&pd_cores 0>;
> + };
> + L2_0: l2-cache {
> + compatible = "arm,arch-cache";
> + power-domain = <&pd_clusters 0>;
> + };
> + };
> +
> + CPU1: cpu at 1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a15";
> + reg = <0x1>;
> + next-level-cache = <&L1_1>;
> + cpu-idle-states = <&STATE0_1 &STATE0>;
> + L1_1: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_0>;
> + power-domain = <&pd_cores 1>;
> + };
> + };
> +
> + CPU2: cpu at 2 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a15";
> + reg = <0x2>;
> + next-level-cache = <&L1_2>;
> + cpu-idle-states = <&STATE0_1 &STATE0>;
> + L1_2: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_0>;
> + power-domain = <&pd_cores 2>;
> + };
> + };
> +
> + CPU3: cpu at 3 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a15";
> + reg = <0x3>;
> + next-level-cache = <&L1_3>;
> + cpu-idle-states = <&STATE0_1 &STATE0>;
> + L1_3: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_0>;
> + power-domain = <&pd_cores 3>;
> + };
> + };
> +
> + CPU4: cpu at 100 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <0x100>;
> + next-level-cache = <&L1_4>;
> + cpu-idle-states = <&STATE1_0 &STATE1>;
> + L1_4: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_1>;
> + power-domain = <&pd_cores 4>;
> + };
> + L2_1: l2-cache {
> + compatible = "arm,arch-cache";
> + power-domain = <&pd_clusters 1>;
> + };
> + };
> +
> + CPU5: cpu at 101 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <0x101>;
> + next-level-cache = <&L1_5>;
> + cpu-idle-states = <&STATE1_0 &STATE1>;
> + L1_5: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_1>;
> + power-domain = <&pd_cores 5>;
> + };
> + };
> +
> + CPU6: cpu at 102 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <0x102>;
> + next-level-cache = <&L1_6>;
> + cpu-idle-states = <&STATE1_0 &STATE1>;
> + L1_6: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_1>;
> + power-domain = <&pd_cores 6>;
> + };
> + };
> +
> + CPU7: cpu at 103 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <0x103>;
> + next-level-cache = <&L1_7>;
> + cpu-idle-states = <&STATE1_0 &STATE1>;
> + L1_7: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_1>;
> + power-domain = <&pd_cores 7>;
> + };
> + };
> +};
> +
> +===========================================
> +4 - References
> +===========================================
> +
> +[1] ARM Linux Kernel documentation - power domain bindings
> + Documentation/devicetree/bindings/power/power_domain.txt
> +
> +[2] ARM Linux Kernel documentation - PSCI bindings
> + Documentation/devicetree/bindings/arm/psci.txt
> +
> +[3] ARM Server Base System Architecture (SBSA)
> + http://infocenter.arm.com/help/index.jsp
> --
> 1.8.4
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH] perf: ARM64: wire up perf_regs and unwind support
From: Will Deacon @ 2014-02-12 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140212112744.GA10517@gmail.com>
On Wed, Feb 12, 2014 at 11:27:44AM +0000, Ingo Molnar wrote:
> * Will Deacon <will.deacon@arm.com> wrote:
> > This needs to go via the perf tree to avoid a repeat of the mess last time.
>
> If the tooling bits are fine with Arnaldo then I have no objections
> either - once all the bits are acked please send a single series with
> all 4(?) patches in it, for tip:perf/core inclusion.
I think it's just 1 patch -- the other 3 are under arch/arm64, so it would
be easier to take those via the arm64 tree and deal with any conflicts
there.
Will
^ permalink raw reply
* [PATCH] ARM: at91/DT: add NAND + DMA property
From: Boris BREZILLON @ 2014-02-12 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392203183-9851-1-git-send-email-nicolas.ferre@atmel.com>
On 12/02/2014 12:06, Nicolas Ferre wrote:
> Add the "atmel,nand-has-dma" property to NAND node for SoC that
> can use the DMA to perform NAND accesses.
> Use of this property was added in 1b7192658a08f70df0f290634fd7cd2ecb629fc9
> (mtd: atmel_nand: add a new dt binding item for nand dma support).
>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Boris BREZILLON <b.brezillon@overkiz.com>
> ---
> arch/arm/boot/dts/at91sam9g45.dtsi | 1 +
> arch/arm/boot/dts/at91sam9n12.dtsi | 1 +
> arch/arm/boot/dts/at91sam9x5.dtsi | 1 +
> arch/arm/boot/dts/sama5d3.dtsi | 1 +
> 4 files changed, 4 insertions(+)
>
> diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi b/arch/arm/boot/dts/at91sam9g45.dtsi
> index cbcc058b26b4..9b6683f252cf 100644
> --- a/arch/arm/boot/dts/at91sam9g45.dtsi
> +++ b/arch/arm/boot/dts/at91sam9g45.dtsi
> @@ -817,6 +817,7 @@
> >;
> atmel,nand-addr-offset = <21>;
> atmel,nand-cmd-offset = <22>;
> + atmel,nand-has-dma;
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_nand>;
> gpios = <&pioC 8 GPIO_ACTIVE_HIGH
> diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi b/arch/arm/boot/dts/at91sam9n12.dtsi
> index 394e6ce2afb7..9f04808fc697 100644
> --- a/arch/arm/boot/dts/at91sam9n12.dtsi
> +++ b/arch/arm/boot/dts/at91sam9n12.dtsi
> @@ -570,6 +570,7 @@
> atmel,pmecc-lookup-table-offset = <0x0 0x8000>;
> atmel,nand-addr-offset = <21>;
> atmel,nand-cmd-offset = <22>;
> + atmel,nand-has-dma;
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_nand>;
> gpios = <&pioD 5 GPIO_ACTIVE_HIGH
> diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi b/arch/arm/boot/dts/at91sam9x5.dtsi
> index 174219de92fa..67e32067eb25 100644
> --- a/arch/arm/boot/dts/at91sam9x5.dtsi
> +++ b/arch/arm/boot/dts/at91sam9x5.dtsi
> @@ -790,6 +790,7 @@
> atmel,pmecc-lookup-table-offset = <0x0 0x8000>;
> atmel,nand-addr-offset = <21>;
> atmel,nand-cmd-offset = <22>;
> + atmel,nand-has-dma;
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_nand>;
> gpios = <&pioD 5 GPIO_ACTIVE_HIGH
> diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
> index 3d5faf85f51b..d075c5326ce7 100644
> --- a/arch/arm/boot/dts/sama5d3.dtsi
> +++ b/arch/arm/boot/dts/sama5d3.dtsi
> @@ -1256,6 +1256,7 @@
> interrupts = <5 IRQ_TYPE_LEVEL_HIGH 6>;
> atmel,nand-addr-offset = <21>;
> atmel,nand-cmd-offset = <22>;
> + atmel,nand-has-dma;
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_nand0_ale_cle>;
> atmel,pmecc-lookup-table-offset = <0x0 0x8000>;
^ permalink raw reply
* [PATCH 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board
From: Mark Rutland @ 2014-02-12 11:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52FB575F.3070104@arm.com>
> >> + gic: interrupt-controller at 1C000000 {
> >> + compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic";
> >
> > This looks incorrect -- you should at the very least have a more
> > specific one than a15-gic? Marc?
>
> "arm,cortex-a9-gic" is definitely wrong (the A9 GIC doesn't have the
> virt extensions). This binding matches what the A15 GIC has, so
> "arm,cortex-a15-gic" is probably fine. Main issue here is that the GICv2
> driver has no compatible string for anything else.
>
> Should we define something more generic (like "arm,gic-v2")? Or carry on
> adding more compatible strings?
It's been proposed repeatedly, and it probably makes sense to add the
generic versions to the driver, and allow for more specific ones in the
binding which DTs can use. That way we don't get an explosion of strings
in the driver, but if we need to handle any particular GIC specially in
future we can do so.
I guess for Linux we'd want to add "arm,gic-v1" and "arm,gic-v2" to the
driver. We could just add "arm,gic-v1" and expect it later in the
compatible list if v2 is a strict superset of v1; I think it is but I'm
not a GIC expert.
Thanks,
Mark.
^ permalink raw reply
* [PATCH] perf: ARM64: wire up perf_regs and unwind support
From: Ingo Molnar @ 2014-02-12 11:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140212101011.GC13441@mudshark.cambridge.arm.com>
* Will Deacon <will.deacon@arm.com> wrote:
> On Wed, Feb 12, 2014 at 08:46:38AM +0000, Jean Pihet wrote:
> > Hi Arnaldo, Will,
> >
> > Ping on this patch.
>
> This needs to go via the perf tree to avoid a repeat of the mess last time.
If the tooling bits are fine with Arnaldo then I have no objections
either - once all the bits are acked please send a single series with
all 4(?) patches in it, for tip:perf/core inclusion.
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH 07/12] mfd: syscon: Consider platform data a regmap config name
From: Alexander Shiyan @ 2014-02-12 11:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392203209.3380.57.camel@hornet>
?????, 12 ??????? 2014, 11:06 UTC ?? Pawel Moll <pawel.moll@arm.com>:
> On Wed, 2014-02-12 at 08:26 +0000, Lee Jones wrote:
> > > > Use the device platform data as a regmap config
> > > > name. This is particularly useful in the regmap
> > > > debugfs when there is more than one syscon device
> > > > registered, to distinguish the register blocks.
> > > >
> > > > Cc: Samuel Ortiz <sameo@linux.intel.com>
> > > > Cc: Lee Jones <lee.jones@linaro.org>
> > > > Signed-off-by: Pawel Moll <pawel.moll@arm.com>
> > > > ---
> > > ...
> > > > syscon_regmap_config.max_register = res->end - res->start - 3;
> > > > + syscon_regmap_config.name = dev_get_platdata(&pdev->dev);
> > >
> > > Is dev_name(&pdev->dev) can be used for such purpose?
> >
> > Yes of course.
> >
> > Either use the automatically generated name or over-ride with
> > dev->init_name prior to registration or call dev_set_name()
> > manually. Then retrieve with Alexander's suggestion.
> >
> > Is there any technical reason why this is not possible with your
> > implementation?
>
> Hold on, guys. Let me just point out that we're talking "non-DT"
> platform devices here (either statically defined struct
> platform_device-s or - my case - the MFD cells).
>
> In this case device/driver matching relies completely on device name.
> Either the pdev->name must be identical (strcmp) to pdrv->name, or the
> pdev->name must be identical (strcmp again) to one of the pdev->id_table
> entries. See platform_match() in driver/base/platform.c for more
> details.
>
> Therefore the dev_name(&pdev->dev) on a non-DT-originating sysconf
> devince will always return "sysconf.*", unless you're ready to maintain
> a growing syscon_ids[] list. If so, I will have to add three entries
> there ("sys_id", "sys_misc" and "sys_procid"). I hope you are not
> seriously considering this idea :-) After all that's what the
> platform_data was invented for.
Yeah, I gave up the idea to use the syscon_ids[] to separate devices for
non-DT case.
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/mfd/syscon.c?id=5104d2656d4874c51868dc7182016e9501ec99ca
Instead, I use a hard definition for pdev->id, so that the names of
syscon-devices are different and can be obtained from the driver
it uses with syscon_regmap_lookup_by_pdevname().
I understand this topic correct?
---
^ permalink raw reply
* [PATCH] MTD: atmel_nand: POI fall back is not an issue: change log level
From: Nicolas Ferre @ 2014-02-12 11:26 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
drivers/mtd/nand/atmel_nand.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index c36e9b84487c..8d210f8a072d 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -430,7 +430,7 @@ err_dma:
dma_unmap_single(dma_dev->dev, phys_addr, len, dir);
err_buf:
if (err != 0)
- dev_warn(host->dev, "Fall back to CPU I/O\n");
+ dev_dbg(host->dev, "Fall back to CPU I/O\n");
return err;
}
--
1.8.2.2
^ permalink raw reply related
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