* [PATCH RFC 4/6] net: rfkill: gpio: add device tree support
From: Mika Westerberg @ 2014-01-21 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAVeFuKFfAvSPYLmvWV5jjT-peZFJ8sJ2bbh4F=JAYoWLhjZpA@mail.gmail.com>
On Tue, Jan 21, 2014 at 11:53:13PM +0900, Alexandre Courbot wrote:
> > I think a unified kernel API makes more sense for some subsystems than
> > others, and it depends a bit on the rate of adoption of APCI for drivers
> > that already have a DT binding (or vice versa, if that happens).
> >
> > GPIO might actually be in the first category since it's commonly used
> > for off-chip components that will get shared across ARM and x86 (as
> > well as everything else), while a common kernel API would be less
> > important for things that are internal to an SoC where Intel is the
> > only company needing ACPI support.
>
> I am afraid I don't have a good enough view of the ACPI landscape to
> understand how often drivers might be reused on both ACPI and DT. But
> I suppose nothing speaks against that, technically speaking. Maybe
> Mika would have comments to make here?
Well, we try to reuse existing drivers whenever possible. As an example
Intel LPSS devices (that exists on Haswell and Baytrail) are mostly
existing drivers from ARM world.
I would say that GPIO is one of such things where we would like to have an
unified interface definitely.
^ permalink raw reply
* [PATCH RFC v2 2/2] Documentation: arm: define DT C-states bindings
From: Lorenzo Pieralisi @ 2014-01-21 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAP245DXdFS5FEkrDvSw07aDDuZDqFPZXF=CoBLPrBB4JuYE8cQ@mail.gmail.com>
Hi Amit,
On Tue, Jan 21, 2014 at 02:35:11PM +0000, Amit Kucheria wrote:
> Hi Lorenzo,
>
> On Mon, Jan 20, 2014 at 11:17 PM, Lorenzo Pieralisi
> <lorenzo.pieralisi@arm.com> wrote:
> > ARM based platforms implement a variety of power management schemes that
> > allow processors to enter at run-time low-power states, aka C-states
> > in ACPI jargon. The parameters defining these C-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 C-state device tree bindings for
> > ARM platforms. Bindings define C-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 power 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/c-states.txt | 774 +++++++++++++++++++++
> > Documentation/devicetree/bindings/arm/cpus.txt | 10 +
> > 2 files changed, 784 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/arm/c-states.txt
> >
> > diff --git a/Documentation/devicetree/bindings/arm/c-states.txt b/Documentation/devicetree/bindings/arm/c-states.txt
>
> s/c-states/idle-states?
>
> While C-states are widely used when talking about idle-states as
> you've noted, idle-states are still the correct generic term for them.
C-states on ACPI are processor power states, I think we can keep the
same nomenclature. I do not mind changing it though, more comments
below.
> > new file mode 100644
> > index 0000000..0b5617b
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/c-states.txt
> > @@ -0,0 +1,774 @@
> > +==========================================
> > +ARM C-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. Borrowing concepts
> > +from the ACPI specification[1], the CPU states representing the range of
> > +dynamic states that a processor can enter at run-time, aka C-state, can be
> > +specified through device tree bindings representing the parameters required to
> > +enter/exit specific C-states on a given processor.
> > +
> > +The state an ARM CPU can be put into is loosely identified by one of the
> > +following operating modes:
> > +
> > +- Running:
> > + # Processor core is executing instructions
> > +
> > +- Wait for Interrupt:
> > + # An ARM processor enters wait for interrupt (WFI) low power
> > + state by executing a wfi instruction. When a processor enters
> > + wfi state it disables most of the clocks while keeping the processor
> > + powered up. This state is standard on all ARM processors and it is
> > + defined as C1 in the remainder of this document.
> > +
> > +- Dormant:
> > + # Dormant mode is entered by executing wfi instructions and by sending
> > + platform specific commands to the platform power controller (coupled
> > + with processor specific SW/HW control sequences).
> > + In dormant mode, most of the processor control and debug logic is
> > + powered up but cache RAM can be put in retention state, providing
> > + additional power savings.
> > +
> > +- Sleep:
> > + # Sleep mode is entered by executing the wfi instruction and by sending
> > + platform specific commands to the platform power controller (coupled
> > + with processor specific SW/HW control sequences). In sleep mode, a
> > + processor and its caches are shutdown, the entire processor state is
> > + lost.
> > +
> > +Building on top of the previous processor modes, ARM platforms implement power
>
> Nitpick: s/previous/above
Ok.
> > +management schemes that allow an OS PM implementation to put the processor in
> > +different CPU states (C-states). C-states parameters (eg 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 C-states is the subject of this
> > +document.
> > +
> > +===========================================
> > +2 - cpu-power-states node
> > +===========================================
> > +
> > +ARM processor C-states are defined within the cpu-power-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-power-states node
>
> What do you think of s/cpu-power-states/cpu-idle-states?
>
> CPU Power management is more than just idle. Unless you have plans to
> add more properties to the cpu-power-states node later.
Ok, if by saying that CPU power management is more than just idle you
also mean managing power while processor is running (ie DVFS) I think
you have a point. Again, I do not mind changing it, keeping in mind that
names stick so if we think we require more info from these bindings,
and that's probably the case, we'd better stick to the current naming
scheme.
[...]
> > + - latency
> > + Usage: Required
> > + Value type: <prop-encoded-array>
> > + Definition: List of u32 values representing worst case latency
> > + in microseconds required to enter and exit the
> > + C-state, one value per OPP [2]. The list should
> > + be specified in the same order as the operating
> > + points property list of the cpu this state is
> > + valid on.
> > + If no OPP bindings are present, the latency value
> > + is associated with the current OPP of CPUs in the
> > + system.
>
> DT-newbie here. What would happen if a vendor does not characterise
> the latency at each OPP? IOW, the table only contains latency values
> for a subset of the OPPs.
The bindings are explicit, so the kernel will barf. Adding a LUT to map
latencies to OPPs make me cringe, so I would not change the current
bindings.
> > + - min-residency
> > + Usage: Required
> > + Value type: <prop-encoded-array>
> > + Definition: List of u32 values representing time in
> > + microseconds required for the CPU to be in
> > + the C-state to make up for the dynamic power
> > + consumed to enter/exit the C-state in order to
> > + break even in terms of power consumption compared
> > + to C1 state (wfi), one value per-OPP [2].
> > + This parameter depends on the operating conditions
> > + (HW state) and must assume worst case scenario.
> > + The list should be specified in the same order as
> > + the operating points property list of the cpu this
> > + state is valid on.
> > + If no OPP bindings are present the min-residency
> > + value is associated with the current OPP of CPUs
> > + in the system.
>
> Same question as latency above.
Same opinion, I am not keen on adding further complexity, after all if
some operating points are not characterized either they should be
disabled or people do not care, hence they can add estimated values just
as well to the respective latencies in the DT.
> > +
> > +===========================================
> > +3 - Examples
> > +===========================================
> > +
> > +Example 1 (ARM 64-bit, 16-cpu system, two clusters of clusters):
>
>
> ^^^^^^^^^^^^^
> clusters of cpus?
Well I took it from an example where topology was clusters of clusters
but I removed the topology node and honestly it does not add anything to
the discussion so I will reword it.
Thanks for having a look,
Lorenzo
^ permalink raw reply
* [PATCH v2 0/5] arm64: advertise availability of CRC and crypto instructions
From: Catalin Marinas @ 2014-01-21 15:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.11.1401201427090.1652@knanqh.ubzr>
On Mon, Jan 20, 2014 at 07:42:36PM +0000, Nicolas Pitre wrote:
> On Mon, 20 Jan 2014, Ard Biesheuvel wrote:
> > Quoting Russell:
> >
> > On 18 December 2013 12:42, Russell King - ARM Linux
> > <linux@arm.linux.org.uk> wrote:
> > > The point is that they'll never appear on an ARMv7 implementation because
> > > they're not part of the ARMv7 architecture. I see no point in needlessly
> > > polluting ARM32 with ARM64 stuff - in exactly the same way that you see
> > > no point in polluting ARM64 with ARM32 stuff.
> > >
> > > So, frankly, find a different way to this. We don't need to needlessly
> > > waste HWCAP bits on ARM32.
> >
> > So my idea was to use HWCAP2 bits instead ...
[...]
> You also decided to put the new crypto bits into HWCAP2. I have no
> actual objection with that either.
>
> What makes me wonder is Catalin's affirmation about putting those new
> bits into HWCAP2 making future extensions possible with old glibc
> versions that don't have knowledge about HWCAP2. That is what I don't
> get the pertinence of.
I was looking for a justification for not touching HWCAP and instead
going directly to HWCAP2. Some user application compiled against an old
glibc could still access HWCAP via getauxval() but not HWCAP2. So that's
not for old glibc using new HWCAP bits itself.
A recent example is the HWCAP_EVSTRM which is ARMv7 only, some
application could implement some user space polling using WFE (I think
I've heard about smarter user locking in PostgreSQL). We may get other
ARMv7 ideas in the future or CPU implementations with features not
covered by the ARM ARM.
But if we decide to keep ARMv8 bits in HWCAP2, it's fine by me, I
already acked these patches. It's up to Russell whether he wants to take
them in this form or not.
--
Catalin
^ permalink raw reply
* [PATCH RFC 4/6] net: rfkill: gpio: add device tree support
From: Alexandre Courbot @ 2014-01-21 14:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201401211335.16885.arnd@arndb.de>
On Tue, Jan 21, 2014 at 9:35 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 21 January 2014, Linus Walleij wrote:
>> On Tue, Jan 21, 2014 at 4:11 AM, Alexandre Courbot <gnurou@gmail.com> wrote:
>> > On Sat, Jan 18, 2014 at 8:11 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
>> >
>> > I agree that's how it should be be done with the current API if your
>> > driver can obtain GPIOs from both ACPI and DT. This is a potential
>> > issue, as drivers are not supposed to make assumptions about who is
>> > going to be their GPIO provider. Let's say you started a driver with
>> > only DT in mind, and used gpio_get(dev, con_id) to get your GPIOs. DT
>> > bindings are thus of the form "con_id-gpio = <phandle>", and set in
>> > stone. Then later, someone wants to use your driver with ACPI. How do
>> > you handle that gracefully?
>>
>> Short answer is you can't. You have to pour backward-compatibility
>> code into the driver first checking for that property and then falling
>> back to the new binding if it doesn't exist.
>
> With the ACPI named properties extension, it should be possible to have
> something akin to a "gpio-names" list that can be attached to an indexed
> array of gpio descriptors. I assume that Intel is going to need this
> for named irqs, clocks, regulators, dmas as well, so I think it will
> eventually get there. It's not something that can be done today though,
> or that is standardized in APCI-5.0.
Good to know. I'm not sure this would help with the named GPIO
resolution issue however. I assume that contrary to DT we will have no
control over the naming of ACPI-defined GPIOs, and thus there is
little chance that a GPIO serving a function will end up having the
same name as the one we chose for the DT binding...
>
> My guess is that named GPIOs are going to make more sense on x86 embedded
> than on arm64 server.
>
>> > I'm starting to wonder, now that ACPI is a first-class GPIO provider,
>> > whether we should not start to encourage the deprecation of the
>> > "con_id-gpio = <phandle>" binding form in DT and only use a single
>> > indexed GPIO property per device.
>>
>> You have a valid point.
>
> Independent of ACPI, I prefer indexed "gpios" properties over "con_id-gpio"
> properties anyway, because it's more consistent with some of the other
> subsystems. I don't have an opinion though on whether we should also
> allow a "gpios"/"gpio-names" pair, or whether we should keep the indexed
> "gpios" list for the anonymous case.
>
>> > The con_id parameter would then only
>> > be used as a label, which would also have the nice side-effect that
>> > all GPIOs used for a given function will be reported under the same
>> > name no matter what the GPIO provider is.
>>
>> As discussed earlier in this thread I'm not sure the con_id is
>> suitable for labelling GPIOs. It'd be better to have a proper name
>> specified in DT/ACPI instead.
>
> +1
I wonder why you guys prefer to have the name defined in the GPIO
mapping. Having the driver decide the label makes it easier to look up
which GPIO does what in debugfs, whereas nothing prevents people to
name GPIOs whatever inadequate name they want in the device DT node.
What am I overlooking here?
>
>> > From an aesthetic point of view, I definitely prefer using con_id to
>> > identify GPIOs instead of indexes, but I don't see how we can make it
>> > play nice with ACPI. Thoughts?
>>
>> Let's ask the DT maintainers...
>>
>> I'm a bit sceptic to the whole ACPI-DT-API-should-be-unified
>> just-one-function-call business, as this was just a very simple example
>> of what can happen to something as simple as
>> devm_gpiod_get[_index]().
>
> I think a unified kernel API makes more sense for some subsystems than
> others, and it depends a bit on the rate of adoption of APCI for drivers
> that already have a DT binding (or vice versa, if that happens).
>
> GPIO might actually be in the first category since it's commonly used
> for off-chip components that will get shared across ARM and x86 (as
> well as everything else), while a common kernel API would be less
> important for things that are internal to an SoC where Intel is the
> only company needing ACPI support.
I am afraid I don't have a good enough view of the ACPI landscape to
understand how often drivers might be reused on both ACPI and DT. But
I suppose nothing speaks against that, technically speaking. Maybe
Mika would have comments to make here?
The good (or bad, rather) thing about DT is that we can do whatever we
please with the new bindings: decide which name or which index
(doesn't matter here) a GPIO should have. However we don't have this
control over ACPI, where nothing guarantees that the same index will
be used for the same GPIO function. And there goes our unified GPIO
mapping. Workarounds would imply additional layers of mapping, or
using different probe functions depending on whether we rely on DT or
ACPI (I don't want to imagine there will be systems that use *both*).
Considering that we already have drivers using that trick (e.g. to
choose between SPI or I2C), the latter might be acceptable.
Alex.
^ permalink raw reply
* [PATCH 1/2] usb: dwc3: core: continue probing if usb phy library returns -ENODEV/-ENXIO
From: Felipe Balbi @ 2014-01-21 14:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390299099-14764-1-git-send-email-kishon@ti.com>
On Tue, Jan 21, 2014 at 03:41:38PM +0530, Kishon Vijay Abraham I wrote:
> Since PHYs for dwc3 is optional (not all SoCs that have DWC3 use PHYs),
> do not return from probe if the USB PHY library returns -ENODEV as that
this isn't correct, they all have PHYs, some of them might not be
controllable.
> indicates the platform does not have PHY.
not really, that indicates the current platform tried to grab a PHY and
the PHY doesn't exist. If there's anybody with a non-controllable PHY
and someone gives me a really good reason for not using the generic
no-op PHY, then we should add a flag and we could:
if (!likely(dwc->flags & DWC3_USB2PHY_DRIVER_NOT_NEEDED))
dwc3_grab_phys(dwc);
But I really want to see the argument against using no-op. As far as I
could see, everybody needs a PHY driver one way or another, some
platforms just haven't sent any PHY driver upstream and have their own
hacked up solution to avoid using the PHY layer.
Your commit log really needs quite some extra work. What are you trying
to achieve ? Is this related to AM437x which doesn't have a USB3 PHY due
to the way the HW was wired up ? If so, please mention it. Explain how
AM437x HW was wired up, why it lacks a USB3 PHY and why we should
support it the way you want.
That sort of detail needs to be clear in the commit log, specially
considering the peculiar nature of AM43xx which uses a USB3 IP in
USB2-only mode, that needs to be documented in the commit log :-)
cheers
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140121/f38c6525/attachment.sig>
^ permalink raw reply
* [PATCH RFC v2 1/2] Documentation: arm: add cache DT bindings
From: Lorenzo Pieralisi @ 2014-01-21 14:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140121114845.GA2598@e103592.cambridge.arm.com>
On Tue, Jan 21, 2014 at 11:49:01AM +0000, Dave Martin wrote:
> On Mon, Jan 20, 2014 at 05:47:58PM +0000, Lorenzo Pieralisi wrote:
> > On ARM systems the cache topology cannot be probed at runtime, in
> > particular, it is impossible to probe which CPUs share a given cache
> > level. Power management software requires this knowledge to implement
> > optimized power down sequences, hence this patch adds a document that
> > defines the DT cache bindings for ARM systems. The bindings are compliant
> > with ePAPR (PowerPC bindings), even though most of the cache nodes
> > properties requirements are overriden, because caches geometry for
> > architected caches is probeable on ARM systems. This patch also adds
> > properties that are specific to ARM architected caches to the existing ones
> > defined in the ePAPR v1.1, as bindings extensions.
> >
> > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > ---
> > Documentation/devicetree/bindings/arm/cache.txt | 187 ++++++++++++++++++++++++
> > 1 file changed, 187 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/arm/cache.txt
> >
> > diff --git a/Documentation/devicetree/bindings/arm/cache.txt b/Documentation/devicetree/bindings/arm/cache.txt
> > new file mode 100644
> > index 0000000..b27cedf
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/cache.txt
> > @@ -0,0 +1,187 @@
> > +==========================================
> > +ARM processors cache binding description
> > +==========================================
> > +
> > +Device tree bindings for ARM processor caches adhere to the cache bindings
> > +described in [3], in section 3.8 for multi-level and shared caches.
> > +On ARM based systems most of the cache properties related to cache
> > +geometry are probeable in HW, hence, unless otherwise stated, the properties
> > +defined in ePAPR for multi-level and shared caches are to be considered
> > +optional by default.
>
> This point should be highlighted for discussion.
>
> I do have a worry that because the kernel won't normally use this
> information, by default it will get pasted between .dts files, won't get
> tested and will be wrong rather often. It also violates the DT principle
> that probeable information should not be present in the DT -- ePAPR
> obviously envisages systems where cache geometry information is not
> probeable, but that's not the case for architected caches on ARM, except
> in rare cases where the CLIDR is wrong.
>
> But deviating needlessly from ePAPR is arguably a bad thing too.
>
>
> There is one good argument in favour of making these properties
> mandatory: it gives people a way to get (possibly wrong or unvalidated)
> information about cache geometry and topology into userspace without the
> kernel having to care. This remains a contraversial issue though.
>
I am not sure it is a good argument, and to be honest there are already
properties in the DT that we do not validate but still are exposed to
users (eg cpu nodes compatible strings). I'd rather forbid all cache
geometry DT properties on ARM.
> If we decide to allow or mandate these properties, the kernel should
> validate them for consistency with the hardware and BUG() on boot if they
> are inconsistent. This is the correct approach until/unless the kernel
> grows a proper mechanism for using this info from the DT.
I think we should forbid them, so that, if people cut'n'paste those
properties into DT, those properties are to be considered outright junk.
A wrong CLIDR is a HW bug, and should be fixed as an errata, not through DT.
> > +On ARM, caches are either architected (directly controlled by the processor
> > +through coprocessor instructions and tightly coupled with the processor
> > +implementation) or unarchitected (controlled through a memory mapped
> > +interface, implemented as a stand-alone IP external to the processor
> > +implementation).
> > +
> > +This document provides the device tree bindings for ARM architected caches.
> > +
> > +- ARM architected cache node
> > +
> > + Description: must be a direct child of the cpu node. A system
>
>
> For this paragraph as a whole:
>
> Can we break this paragraph up, and move the background information (e.g.
> description of the ARM Architecture) outside?
>
> It's long and hard to read at present.
Yes, I noticed too.
> I think we only need the fundamental rules, which are basically that
> the next-level-cache properties must be consistent with the hardware
> cache topology. We could try to be more precise, but ePAPR is pretty
> vague too.
I agree.
> > + can contain multiple architected cache nodes per cpu node,
> > + linked through the next-level-cache phandle. The
> > + next-level-cache property in the cpu node points to
> > + the first level of architected cache for the CPU.
> > + The next-level-cache property in architected cache nodes
> > + points to the respective next level of caching in the
> > + hierarchy. An architected cache node with an empty or
> > + missing next-level-cache property represents the last
> > + architected cache level for the CPU.
> > + On ARM v7 and v8 architectures, the order in which cache
> > + nodes are linked through the next-level-cache phandle must
> > + follow the ordering specified in the processors CLIDR (v7)
>
> We shouldn't describe the ARM Architecture in the binding. That's
> background information that could move outside.
Ok, I will try to reword it.
> > + and CLIDR_EL1 (v8) registers, as described in [1][2],
> > + implying that a cache node pointed at by a
> > + next-level-cache phandle must correspond to a level
> > + defined in CLIDR (v7) and CLIDR_EL1 (v8) greater than the
> > + one the cache node containing the next-level-cache
> > + phandle corresponds to.
> > +
> > + Since on ARM most of the cache properties are probeable in HW the
> > + properties described in [3] - section 3.8 multi-level and shared
> > + caches - shall be considered optional, with the following properties
> > + updates, specific for the ARM architected cache node.
> > +
> > + - compatible
> > + Usage: Required
> > + Value type: <string>
> > + Definition: value shall be "arm,arch-cache".
> > +
> > + - interrupts
> > + Usage: Optional
> > + Value type: See definition
> > + Definition: standard device tree property [3] that defines
> > + the interrupt line associated with the cache.
> > + The property can be accompanied by an
> > + interrupt-names property, as described in [4].
>
> Do ARM Architectured caches ever have interrupts? (Just my ignorance
> here.)
I added the property in preparation for Stephen's bindings on krait, but
since those caches are not architected caches, I was a bit overzealous.
Certainly it is a bit of a shame to redefine another binding for caches
on krait that basically have the SAME properties, and just add interrupts.
Thoughts appreciated.
> > + - power-domain
> > + Usage: Optional
> > + Value type: phandle
> > + Definition: A phandle and power domain specifier as defined by
> > + bindings of power controller specified by the
> > + phandle [5].
> > +
> > +Example(dual-cluster big.LITTLE system 32-bit)
> > +
> > + cpus {
> > + #size-cells = <0>;
> > + #address-cells = <1>;
> > +
> > + cpu at 0 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a15";
> > + reg = <0x0>;
> > + next-level-cache = <&L1_0>;
>
> ePAPR puts the L1 cache properties in the cpu node directly;
> there's no "L1" node as such. That geometry description is also
> mandated by ePAPR.
I mentioned that all cache properties from ePAPR should be considered
optional. Now I will probably forbid them :)
> The ARM Architecture does not force a CPU to have any non-shared
> first level(s) of cache, and ePAPR does not permit next-level-cache
> to point to a cpu node, so there are possible ARM Architecture
> implementations that cannot be described without violating ePAPR.
> However, for practical reasons, such systems are unlikely -- I don't
> know if any exist today.
>
> We should decide whether to deviate explicitly from ePAPR on this
> point (your examples provide on way), or whether to follow ePAPR and
> bodge things later for L1-less systems if they appear.
I defined the way it is so that I can always distinguish between a CPU
and its L1, that for power domain reasons, through phandles.
I might want to define a L1 that is retained and a CPU that loses context, if
I lump them together I need to cook up something else to distinguish them.
I think the way I defined it is cleaner, opinions appreciated.
Thanks for the review,
Lorenzo
^ permalink raw reply
* [PATCH v3 04/15] watchdog: orion: Handle IRQ
From: Ezequiel Garcia @ 2014-01-21 14:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52DE84A6.6090909@roeck-us.net>
On Tue, Jan 21, 2014 at 06:31:02AM -0800, Guenter Roeck wrote:
> On 01/21/2014 05:26 AM, Ezequiel Garcia wrote:
> > DT-enabled where an irqchip driver for the brigde interrupt controller is
> > available can handle the watchdog IRQ properly. Therefore, we request
> > the interruption and add a dummy handler that merely calls panic().
> >
> > This is done in order to have an initial 'ack' of the interruption,
> > which clears the watchdog state.
> >
> > Furthermore, since some platforms don't have such IRQ, this commit
> > makes the interruption specification optional.
> >
> > Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
> > ---
> > .../devicetree/bindings/watchdog/marvel.txt | 2 ++
> > drivers/watchdog/orion_wdt.c | 22 +++++++++++++++++++++-
> > 2 files changed, 23 insertions(+), 1 deletion(-)
> >
>
> [ ... ]
>
> > static int orion_wdt_probe(struct platform_device *pdev)
> > {
> > struct resource *res;
> > - int ret;
> > + int ret, irq;
> >
> > clk = devm_clk_get(&pdev->dev, NULL);
> > if (IS_ERR(clk)) {
> > @@ -131,6 +138,19 @@ static int orion_wdt_probe(struct platform_device *pdev)
> > if (!wdt_reg)
> > return -ENOMEM;
> >
> > + irq = platform_get_irq(pdev, 0);
> > + if (irq > 0) {
>
> 0 is a valid interrupt number, and platform_get_irq returns an error code on errors.
> Should be >= 0.
>
Yes, indeed. I'll wait to see if there's any other feedback and then send a v4.
Thanks a lot!
--
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH RFC v2 2/2] Documentation: arm: define DT C-states bindings
From: Amit Kucheria @ 2014-01-21 14:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140121133148.GB28801@e102568-lin.cambridge.arm.com>
Hi Lorenzo,
On Mon, Jan 20, 2014 at 11:17 PM, Lorenzo Pieralisi
<lorenzo.pieralisi@arm.com> wrote:
> ARM based platforms implement a variety of power management schemes that
> allow processors to enter at run-time low-power states, aka C-states
> in ACPI jargon. The parameters defining these C-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 C-state device tree bindings for
> ARM platforms. Bindings define C-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 power 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/c-states.txt | 774 +++++++++++++++++++++
> Documentation/devicetree/bindings/arm/cpus.txt | 10 +
> 2 files changed, 784 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/c-states.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/c-states.txt b/Documentation/devicetree/bindings/arm/c-states.txt
s/c-states/idle-states?
While C-states are widely used when talking about idle-states as
you've noted, idle-states are still the correct generic term for them.
> new file mode 100644
> index 0000000..0b5617b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/c-states.txt
> @@ -0,0 +1,774 @@
> +==========================================
> +ARM C-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. Borrowing concepts
> +from the ACPI specification[1], the CPU states representing the range of
> +dynamic states that a processor can enter at run-time, aka C-state, can be
> +specified through device tree bindings representing the parameters required to
> +enter/exit specific C-states on a given processor.
> +
> +The state an ARM CPU can be put into is loosely identified by one of the
> +following operating modes:
> +
> +- Running:
> + # Processor core is executing instructions
> +
> +- Wait for Interrupt:
> + # An ARM processor enters wait for interrupt (WFI) low power
> + state by executing a wfi instruction. When a processor enters
> + wfi state it disables most of the clocks while keeping the processor
> + powered up. This state is standard on all ARM processors and it is
> + defined as C1 in the remainder of this document.
> +
> +- Dormant:
> + # Dormant mode is entered by executing wfi instructions and by sending
> + platform specific commands to the platform power controller (coupled
> + with processor specific SW/HW control sequences).
> + In dormant mode, most of the processor control and debug logic is
> + powered up but cache RAM can be put in retention state, providing
> + additional power savings.
> +
> +- Sleep:
> + # Sleep mode is entered by executing the wfi instruction and by sending
> + platform specific commands to the platform power controller (coupled
> + with processor specific SW/HW control sequences). In sleep mode, a
> + processor and its caches are shutdown, the entire processor state is
> + lost.
> +
> +Building on top of the previous processor modes, ARM platforms implement power
Nitpick: s/previous/above
> +management schemes that allow an OS PM implementation to put the processor in
> +different CPU states (C-states). C-states parameters (eg 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 C-states is the subject of this
> +document.
> +
> +===========================================
> +2 - cpu-power-states node
> +===========================================
> +
> +ARM processor C-states are defined within the cpu-power-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-power-states node
What do you think of s/cpu-power-states/cpu-idle-states?
CPU Power management is more than just idle. Unless you have plans to
add more properties to the cpu-power-states node later.
> +
> + Usage: Optional - On ARM systems, is a container of processor C-state
> + nodes. If the system does not provide CPU power
> + management capabilities or the processor just
> + supports WFI (C1 state) a cpu-power-states node is
> + not required.
> +
> + Description: cpu-power-states node is a container node, where its
> + subnodes describe the CPU low-power C-states.
> +
> + Node name must be "cpu-power-states".
> +
> + The cpu-power-states node's parent node must be cpus node.
> +
> + The cpu-power-states node's child nodes can be:
> +
> + - one or more state nodes
> +
> + Any other configuration is considered invalid.
> +
> +The nodes describing the C-states (state) can only be defined within the
> +cpu-power-states node.
> +
> +Any other configuration is consider invalid and therefore must be ignored.
> +
> +===========================================
> +2 - state node
> +===========================================
> +
> +A state node represents a C-state description and must be defined as follows:
> +
> +- state node
> +
> + Description: must be child of either the cpu-power-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. Child nodes inherit
> + properties from the parent state nodes that work as state
> + properties aggregators (ie contain properties valid on all state
> + nodes children).
> +
> + A state node defines the following properties (either explicitly
> + or by inheriting them from a parent node):
> +
> + - compatible
> + Usage: Required
> + Value type: <stringlist>
> + Definition: Must be "arm,cpu-power-state".
> +
> + - index
> + Usage: Required
> + Value type: <u32>
> + Definition: It represents C-state index, starting from 2 (index
> + 0 represents the processor state "running" and
> + index 1 represents processor mode "WFI"; indexes 0
> + and 1 are standard ARM states that need not be
> + described).
> +
> + - power-domain
> + Usage: Required
> + Value type: <prop-encoded-array>
> + Definition: List of phandle and power domain specifiers
> + as defined by bindings of power controller
> + specified by the phandle [3]. It represents the
> + power domains associated with the C-state. The
> + power domains list can be used by OSPM to
> + retrieve the devices belonging to the power
> + domains and carry out corresponding actions to
> + preserve functionality across power cycles
> + (ie context save/restore, cache flushing).
> +
> + - entry-method
> + Usage: Required
> + Value type: <stringlist>
> + Definition: Describes the method by which a CPU enters the
> + C-state. This property is required and must be one
> + of:
> +
> + - "psci"
> + ARM Standard firmware interface
> +
> + - "[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 C-state.
> +
> + - psci-power-state
> + Usage: Required if entry-method property value is set to
> + "psci".
> + Value type: <u32>
> + Definition: power_state parameter to pass to the PSCI
> + suspend call to enter the C-state.
> +
> + - latency
> + Usage: Required
> + Value type: <prop-encoded-array>
> + Definition: List of u32 values representing worst case latency
> + in microseconds required to enter and exit the
> + C-state, one value per OPP [2]. The list should
> + be specified in the same order as the operating
> + points property list of the cpu this state is
> + valid on.
> + If no OPP bindings are present, the latency value
> + is associated with the current OPP of CPUs in the
> + system.
DT-newbie here. What would happen if a vendor does not characterise
the latency at each OPP? IOW, the table only contains latency values
for a subset of the OPPs.
> +
> + - min-residency
> + Usage: Required
> + Value type: <prop-encoded-array>
> + Definition: List of u32 values representing time in
> + microseconds required for the CPU to be in
> + the C-state to make up for the dynamic power
> + consumed to enter/exit the C-state in order to
> + break even in terms of power consumption compared
> + to C1 state (wfi), one value per-OPP [2].
> + This parameter depends on the operating conditions
> + (HW state) and must assume worst case scenario.
> + The list should be specified in the same order as
> + the operating points property list of the cpu this
> + state is valid on.
> + If no OPP bindings are present the min-residency
> + value is associated with the current OPP of CPUs
> + in the system.
Same question as latency above.
> +
> +===========================================
> +3 - Examples
> +===========================================
> +
> +Example 1 (ARM 64-bit, 16-cpu system, two clusters of clusters):
^^^^^^^^^^^^^
clusters of cpus?
> +
> +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>;
> + };
> +};
> +
<snip>
^ permalink raw reply
* [PATCH v3 04/15] watchdog: orion: Handle IRQ
From: Guenter Roeck @ 2014-01-21 14:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390310774-20781-5-git-send-email-ezequiel.garcia@free-electrons.com>
On 01/21/2014 05:26 AM, Ezequiel Garcia wrote:
> DT-enabled where an irqchip driver for the brigde interrupt controller is
> available can handle the watchdog IRQ properly. Therefore, we request
> the interruption and add a dummy handler that merely calls panic().
>
> This is done in order to have an initial 'ack' of the interruption,
> which clears the watchdog state.
>
> Furthermore, since some platforms don't have such IRQ, this commit
> makes the interruption specification optional.
>
> Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
> ---
> .../devicetree/bindings/watchdog/marvel.txt | 2 ++
> drivers/watchdog/orion_wdt.c | 22 +++++++++++++++++++++-
> 2 files changed, 23 insertions(+), 1 deletion(-)
>
[ ... ]
> static int orion_wdt_probe(struct platform_device *pdev)
> {
> struct resource *res;
> - int ret;
> + int ret, irq;
>
> clk = devm_clk_get(&pdev->dev, NULL);
> if (IS_ERR(clk)) {
> @@ -131,6 +138,19 @@ static int orion_wdt_probe(struct platform_device *pdev)
> if (!wdt_reg)
> return -ENOMEM;
>
> + irq = platform_get_irq(pdev, 0);
> + if (irq > 0) {
0 is a valid interrupt number, and platform_get_irq returns an error code on errors.
Should be >= 0.
Guenter
^ permalink raw reply
* [RFC PATCH 2/3] arm64: KVM: trap VM system registers until MMU and caches are ON
From: Marc Zyngier @ 2014-01-21 14:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAHg+Hh2O+njMvU5pWvkNwSWoRiBv9Bd9o1C9kbtG5bGxJsvoQ@mail.gmail.com>
Hi Pranav,
On 21/01/14 12:17, Pranavkumar Sawargaonkar wrote:
> Hi Marc,
>
> On 20 January 2014 22:00, Anup Patel <anup@brainfault.org> wrote:
>> Hi Marc,
>>
>> On Mon, Jan 20, 2014 at 7:11 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
>>> Hi Anup,
>>>
>>> On 20/01/14 12:00, Anup Patel wrote:
>>>> On Fri, Jan 17, 2014 at 8:33 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
>>>>> In order to be able to detect the point where the guest enables
>>>>> its MMU and caches, trap all the VM related system registers.
>>>>>
>>>>> Once we see the guest enabling both the MMU and the caches, we
>>>>> can go back to a saner mode of operation, which is to leave these
>>>>> registers in complete control of the guest.
>>>>>
>>>>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>>>>> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
>>>>> ---
>>>>> arch/arm64/include/asm/kvm_arm.h | 3 ++-
>>>>> arch/arm64/kvm/sys_regs.c | 58 ++++++++++++++++++++++++++++++++--------
>>>>> 2 files changed, 49 insertions(+), 12 deletions(-)
>>>>>
>>>>> diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
>>>>> index c98ef47..fd0a651 100644
>>>>> --- a/arch/arm64/include/asm/kvm_arm.h
>>>>> +++ b/arch/arm64/include/asm/kvm_arm.h
>>>>> @@ -62,6 +62,7 @@
>>>>> * RW: 64bit by default, can be overriden for 32bit VMs
>>>>> * TAC: Trap ACTLR
>>>>> * TSC: Trap SMC
>>>>> + * TVM: Trap VM ops (until M+C set in SCTLR_EL1)
>>>>> * TSW: Trap cache operations by set/way
>>>>> * TWE: Trap WFE
>>>>> * TWI: Trap WFI
>>>>> @@ -74,7 +75,7 @@
>>>>> * SWIO: Turn set/way invalidates into set/way clean+invalidate
>>>>> */
>>>>> #define HCR_GUEST_FLAGS (HCR_TSC | HCR_TSW | HCR_TWE | HCR_TWI | HCR_VM | \
>>>>> - HCR_BSU_IS | HCR_FB | HCR_TAC | \
>>>>> + HCR_TVM | HCR_BSU_IS | HCR_FB | HCR_TAC | \
>>>>> HCR_AMO | HCR_IMO | HCR_FMO | \
>>>>> HCR_SWIO | HCR_TIDCP | HCR_RW)
>>>>> #define HCR_VIRT_EXCP_MASK (HCR_VA | HCR_VI | HCR_VF)
>>>>> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
>>>>> index 02e9d09..5e92b9e 100644
>>>>> --- a/arch/arm64/kvm/sys_regs.c
>>>>> +++ b/arch/arm64/kvm/sys_regs.c
>>>>> @@ -121,6 +121,42 @@ done:
>>>>> }
>>>>>
>>>>> /*
>>>>> + * Generic accessor for VM registers. Only called as long as HCR_TVM
>>>>> + * is set.
>>>>> + */
>>>>> +static bool access_vm_reg(struct kvm_vcpu *vcpu,
>>>>> + const struct sys_reg_params *p,
>>>>> + const struct sys_reg_desc *r)
>>>>> +{
>>>>> + BUG_ON(!p->is_write);
>>>>> +
>>>>> + vcpu_sys_reg(vcpu, r->reg) = *vcpu_reg(vcpu, p->Rt);
>>>>> + return true;
>>>>> +}
>>>>> +
>>>>> +/*
>>>>> + * SCTLR_EL1 accessor. Only called as long as HCR_TVM is set. If the
>>>>> + * guest enables the MMU, we stop trapping the VM sys_regs and leave
>>>>> + * it in complete control of the caches.
>>>>> + */
>>>>> +static bool access_sctlr_el1(struct kvm_vcpu *vcpu,
>>>>> + const struct sys_reg_params *p,
>>>>> + const struct sys_reg_desc *r)
>>>>> +{
>>>>> + unsigned long val;
>>>>> +
>>>>> + BUG_ON(!p->is_write);
>>>>> +
>>>>> + val = *vcpu_reg(vcpu, p->Rt);
>>>>> + vcpu_sys_reg(vcpu, r->reg) = val;
>>>>> +
>>>>> + if ((val & (0b101)) == 0b101) /* MMU+Caches enabled? */
>>>>> + vcpu->arch.hcr_el2 &= ~HCR_TVM;
>>>>> +
>>>>> + return true;
>>>>> +}
>>>>> +
>>>>> +/*
>>>>> * We could trap ID_DFR0 and tell the guest we don't support performance
>>>>> * monitoring. Unfortunately the patch to make the kernel check ID_DFR0 was
>>>>> * NAKed, so it will read the PMCR anyway.
>>>>> @@ -185,32 +221,32 @@ static const struct sys_reg_desc sys_reg_descs[] = {
>>>>> NULL, reset_mpidr, MPIDR_EL1 },
>>>>> /* SCTLR_EL1 */
>>>>> { Op0(0b11), Op1(0b000), CRn(0b0001), CRm(0b0000), Op2(0b000),
>>>>> - NULL, reset_val, SCTLR_EL1, 0x00C50078 },
>>>>> + access_sctlr_el1, reset_val, SCTLR_EL1, 0x00C50078 },
>>>>
>>>> This patch in its current form breaks Aarch32 VMs on Foundation v8 Model
>>>> because encoding for Aarch64 VM registers we get Op0=0b11 and for Aarch32
>>>> VM registers we get Op0=0b00 when trapped.
>>>>
>>>> Either its a Foundation v8 Model bug or we need to add more enteries in
>>>> sys_reg_desc[] for Aarch32 VM registers with Op0=0b00.
>>>
>>> That's a good point. But Op0 isn't defined for AArch32, the value is
>>> simply hardcoded in kvm_handle_cp15_32/kvm_handle_cp15_64, which is
>>> obviously horribly broken.
>>>
>>> I'll work on a fix for that, thanks noticing it.
>>>
>>> Does this series otherwise fix your L3 cache issue (assuming you stick
>>> to 64bit guests)?
>>
>> Just started trying your patches today.
>> First tried on Foundation v8 Model.
>> Next we will try on X-Gene.
>>
>> Me or Pranav will soon provide more feedback in this regard.
>>
>
> Tested this patch with kvmtool on xgene, works fine !!
Excellent, thanks for testing. I'll repost a new patch series with the
32bit stuff later today or tomorrow.
Cheers,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v2] dma: imx-sdma: clarify firmare not found warning
From: Russell King - ARM Linux @ 2014-01-21 14:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140121143656.3c0b96c0@ipc1.ka-ro>
On Tue, Jan 21, 2014 at 02:36:56PM +0100, Lothar Wa?mann wrote:
> Hi,
>
> Russell King - ARM Linux wrote:
> > On Tue, Jan 21, 2014 at 12:52:00PM +0100, Lothar Wa?mann wrote:
> > > Hi,
> > >
> > > Russell King - ARM Linux wrote:
> > > > On Tue, Jan 21, 2014 at 07:59:22AM +0100, Lothar Wa?mann wrote:
> > > > > The file is automatically removed after the timeout has expired (or
> > > > > the frimware has been loaded).
> > > > > Thus you must check for it within the timeout period during boot.
> > > >
> > > > ... which is impossible if imx-sdma is built into the kernel - it
> > > > expires while the initramfs has only just started running, giving a
> > > > very narrow window for userspace to load firmware.
> > > >
> > > It works for me, but I'm not using initramfs.
> >
> > You can take my email as a report of "it doesn't work for everyone." The
> > *only* way I can get firmware to load is to build imx-sdma as a module.
> > Building it in is a hopeless case here.
> >
> You could change the timeout from your initramfs as soon as sysfs has
> been mounted by writing the number of seconds to
> /sys/class/firmware/timeout. A timeout of '0' means 'wait forever' which
> should be long enough for any boot case. ;)
Err, no. Let's walk through the code, shall we?
imx-sdma calls request_firmware_nowait() for the firmware.
request_firmware_nowait() allocates a work structure, saves all the
details, puts it on a queue, and triggers a workqueue to process this.
When the work structure is dequeued, request_firmware_work_func() is
called. This calls _request_firmware() with the appropriate parameters,
including nowait = true.
_request_firmware() reads the timeout, and then calls
usermodehelper_read_lock_wait() with it. (Once this has happened,
changing the timeout has no effect.) This waits for the requisit amount
of time for usermodehelper_disabled.
Once that happens, fw_get_filesystem_firmware() is called by
_request_firmware(), which attempts to read the file from the mounted
filesystem.
If that fails, the kernel falls back to fw_load_from_user_helper()
to invoke a usermode helper to load the firmware.
This creates a file in /sys/class/firmware, and issues a uevent, sets
a timeout using the timeout value read above, and waits either for the
request to be satisfied or a timeout to happen.
So... increasing the timeout can _only_ have an effect if it is done
before the request is created - which, if imx-sdma is built into the
kernel will be impossible to achieve.
What I suspect is happening is that ubuntu's initramfs doesn't contain
the firmware, but it unblocks the user helper (since it contains and
runs udev) which also fails to find the firmware - and there's no
provision for the firmware to be included in ubuntu's initramfs.
So, let's go back to the point I've been making. If you build imx-sdma
into the kernel, there are situations where it is impossible to load
replacement firmware, because the attempt to load firmware expires long
before there is any chance for it to be loaded.
Maybe you don't personally care about ubuntu. Good for you, that's your
personal choice. That has absolutely no bearing on this issue though.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH v4 2/2] usb: dwc3: adapt dwc3 core to use Generic PHY Framework
From: Roger Quadros @ 2014-01-21 14:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390299099-14764-2-git-send-email-kishon@ti.com>
Hi Kishon,
On 01/21/2014 12:11 PM, Kishon Vijay Abraham I wrote:
> Adapted dwc3 core to use the Generic PHY Framework. So for init, exit,
> power_on and power_off the following APIs are used phy_init(), phy_exit(),
> phy_power_on() and phy_power_off().
>
> However using the old USB phy library wont be removed till the PHYs of all
> other SoC's using dwc3 core is adapted to the Generic PHY Framework.
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> Changes from v3:
> * avoided using quirks
>
> Documentation/devicetree/bindings/usb/dwc3.txt | 6 ++-
> drivers/usb/dwc3/core.c | 60 ++++++++++++++++++++++++
> drivers/usb/dwc3/core.h | 7 +++
> 3 files changed, 71 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt
> index e807635..471366d 100644
> --- a/Documentation/devicetree/bindings/usb/dwc3.txt
> +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
> @@ -6,11 +6,13 @@ Required properties:
> - compatible: must be "snps,dwc3"
> - reg : Address and length of the register set for the device
> - interrupts: Interrupts used by the dwc3 controller.
> +
> +Optional properties:
> - usb-phy : array of phandle for the PHY device. The first element
> in the array is expected to be a handle to the USB2/HS PHY and
> the second element is expected to be a handle to the USB3/SS PHY
> -
> -Optional properties:
> + - phys: from the *Generic PHY* bindings
> + - phy-names: from the *Generic PHY* bindings
> - tx-fifo-resize: determines if the FIFO *has* to be reallocated.
>
> This is usually a subnode to DWC3 glue to which it is connected.
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index e009d4e..036d589 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -82,6 +82,11 @@ static void dwc3_core_soft_reset(struct dwc3 *dwc)
>
> usb_phy_init(dwc->usb2_phy);
> usb_phy_init(dwc->usb3_phy);
> + if (dwc->usb2_generic_phy)
> + phy_init(dwc->usb2_generic_phy);
What if phy_init() fails? You need to report and fail. Same applies for all PHY apis in this patch.
> + if (dwc->usb3_generic_phy)
> + phy_init(dwc->usb3_generic_phy);
> +
> mdelay(100);
>
> /* Clear USB3 PHY reset */
> @@ -343,6 +348,11 @@ static void dwc3_core_exit(struct dwc3 *dwc)
> {
> usb_phy_shutdown(dwc->usb2_phy);
> usb_phy_shutdown(dwc->usb3_phy);
> + if (dwc->usb2_generic_phy)
> + phy_exit(dwc->usb2_generic_phy);
> + if (dwc->usb3_generic_phy)
> + phy_exit(dwc->usb3_generic_phy);
> +
> }
>
> #define DWC3_ALIGN_MASK (16 - 1)
> @@ -433,6 +443,32 @@ static int dwc3_probe(struct platform_device *pdev)
> }
> }
>
> + dwc->usb2_generic_phy = devm_phy_get(dev, "usb2-phy");
> + if (IS_ERR(dwc->usb2_generic_phy)) {
> + ret = PTR_ERR(dwc->usb2_generic_phy);
> + if (ret == -ENOSYS || ret == -ENODEV) {
> + dwc->usb2_generic_phy = NULL;
> + } else if (ret == -EPROBE_DEFER) {
> + return ret;
> + } else {
> + dev_err(dev, "no usb2 phy configured\n");
> + return ret;
> + }
> + }
> +
> + dwc->usb3_generic_phy = devm_phy_get(dev, "usb3-phy");
> + if (IS_ERR(dwc->usb3_generic_phy)) {
> + ret = PTR_ERR(dwc->usb3_generic_phy);
> + if (ret == -ENOSYS || ret == -ENODEV) {
> + dwc->usb3_generic_phy = NULL;
> + } else if (ret == -EPROBE_DEFER) {
> + return ret;
> + } else {
> + dev_err(dev, "no usb3 phy configured\n");
> + return ret;
> + }
> + }
> +
> dwc->xhci_resources[0].start = res->start;
> dwc->xhci_resources[0].end = dwc->xhci_resources[0].start +
> DWC3_XHCI_REGS_END;
> @@ -482,6 +518,11 @@ static int dwc3_probe(struct platform_device *pdev)
> usb_phy_set_suspend(dwc->usb2_phy, 0);
> usb_phy_set_suspend(dwc->usb3_phy, 0);
>
> + if (dwc->usb2_generic_phy)
> + phy_power_on(dwc->usb2_generic_phy);
> + if (dwc->usb3_generic_phy)
> + phy_power_on(dwc->usb3_generic_phy);
> +
Is it OK to power on the phy before phy_init()?
I suggest to move phy_init() from core_soft_reset() to here, just before phy_power_on().
> ret = dwc3_event_buffers_setup(dwc);
> if (ret) {
> dev_err(dwc->dev, "failed to setup event buffers\n");
> @@ -565,6 +606,10 @@ err2:
> err1:
> usb_phy_set_suspend(dwc->usb2_phy, 1);
> usb_phy_set_suspend(dwc->usb3_phy, 1);
> + if (dwc->usb2_generic_phy)
> + phy_power_off(dwc->usb2_generic_phy);
> + if (dwc->usb3_generic_phy)
> + phy_power_off(dwc->usb3_generic_phy);
> dwc3_core_exit(dwc);
>
> err0:
> @@ -580,6 +625,11 @@ static int dwc3_remove(struct platform_device *pdev)
> usb_phy_set_suspend(dwc->usb2_phy, 1);
> usb_phy_set_suspend(dwc->usb3_phy, 1);
>
> + if (dwc->usb2_generic_phy)
> + phy_power_off(dwc->usb2_generic_phy);
> + if (dwc->usb3_generic_phy)
> + phy_power_off(dwc->usb3_generic_phy);
> +
> pm_runtime_put_sync(&pdev->dev);
> pm_runtime_disable(&pdev->dev);
>
> @@ -677,6 +727,11 @@ static int dwc3_suspend(struct device *dev)
> usb_phy_shutdown(dwc->usb3_phy);
> usb_phy_shutdown(dwc->usb2_phy);
>
> + if (dwc->usb2_generic_phy)
> + phy_exit(dwc->usb2_generic_phy);
> + if (dwc->usb3_generic_phy)
> + phy_exit(dwc->usb3_generic_phy);
> +
> return 0;
> }
>
> @@ -688,6 +743,11 @@ static int dwc3_resume(struct device *dev)
> usb_phy_init(dwc->usb3_phy);
> usb_phy_init(dwc->usb2_phy);
>
> + if (dwc->usb2_generic_phy)
> + phy_init(dwc->usb2_generic_phy);
> + if (dwc->usb3_generic_phy)
> + phy_init(dwc->usb3_generic_phy);
> +
> spin_lock_irqsave(&dwc->lock, flags);
>
> dwc3_writel(dwc->regs, DWC3_GCTL, dwc->gctl);
cheers,
-roger
^ permalink raw reply
* [PATCH 1/2] usb: dwc3: core: continue probing if usb phy library returns -ENODEV/-ENXIO
From: Roger Quadros @ 2014-01-21 13:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390299099-14764-1-git-send-email-kishon@ti.com>
On 01/21/2014 12:11 PM, Kishon Vijay Abraham I wrote:
> Since PHYs for dwc3 is optional (not all SoCs that have DWC3 use PHYs),
> do not return from probe if the USB PHY library returns -ENODEV as that
> indicates the platform does not have PHY.
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Roger Quadros <rogerq@ti.com>
cheers,
-roger
> ---
> drivers/usb/dwc3/core.c | 34 ++++++++++++++--------------------
> 1 file changed, 14 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index a49217a..e009d4e 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -411,32 +411,26 @@ static int dwc3_probe(struct platform_device *pdev)
>
> if (IS_ERR(dwc->usb2_phy)) {
> ret = PTR_ERR(dwc->usb2_phy);
> -
> - /*
> - * if -ENXIO is returned, it means PHY layer wasn't
> - * enabled, so it makes no sense to return -EPROBE_DEFER
> - * in that case, since no PHY driver will ever probe.
> - */
> - if (ret == -ENXIO)
> + if (ret == -ENXIO || ret == -ENODEV) {
> + dwc->usb2_phy = NULL;
> + } else if (ret == -EPROBE_DEFER) {
> return ret;
> -
> - dev_err(dev, "no usb2 phy configured\n");
> - return -EPROBE_DEFER;
> + } else {
> + dev_err(dev, "no usb2 phy configured\n");
> + return ret;
> + }
> }
>
> if (IS_ERR(dwc->usb3_phy)) {
> ret = PTR_ERR(dwc->usb3_phy);
> -
> - /*
> - * if -ENXIO is returned, it means PHY layer wasn't
> - * enabled, so it makes no sense to return -EPROBE_DEFER
> - * in that case, since no PHY driver will ever probe.
> - */
> - if (ret == -ENXIO)
> + if (ret == -ENXIO || ret == -ENODEV) {
> + dwc->usb3_phy = NULL;
> + } else if (ret == -EPROBE_DEFER) {
> return ret;
> -
> - dev_err(dev, "no usb3 phy configured\n");
> - return -EPROBE_DEFER;
> + } else {
> + dev_err(dev, "no usb3 phy configured\n");
> + return ret;
> + }
> }
>
> dwc->xhci_resources[0].start = res->start;
>
^ permalink raw reply
* [PATCH v3 3/7] net: moxa: connect to PHY
From: Jonas Jensen @ 2014-01-21 13:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqKs-snsRaD1JQRVUrg+WBDd9cYxPhtfKf9m5HeJ6df3Pw@mail.gmail.com>
The kernel now has a MDIO bus driver and a phy_driver (RTL8201CP),
connect to this PHY using OF.
Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com>
---
Notes:
Thanks for reviewing,
This time I'll avoid sending out the entire set, attaching it here
directly to my reply.
Because the DT example is directly imported from files in arch/arm/
those must be updated too. I'll submit those in a separate fixup patch.
Changes since v3:
1. drop device_type property from DT example
2. replace "mac@" with "ethernet@" in DT example
Applies to next-20140121
.../devicetree/bindings/net/moxa,moxart-mac.txt | 49 +++++++++++-
drivers/net/ethernet/moxa/moxart_ether.c | 92 +++++++++++++++++++++-
drivers/net/ethernet/moxa/moxart_ether.h | 2 +
3 files changed, 138 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/moxa,moxart-mac.txt b/Documentation/devicetree/bindings/net/moxa,moxart-mac.txt
index 583418b..36d5185 100644
--- a/Documentation/devicetree/bindings/net/moxa,moxart-mac.txt
+++ b/Documentation/devicetree/bindings/net/moxa,moxart-mac.txt
@@ -1,21 +1,62 @@
MOXA ART Ethernet Controller
+Integrated MDIO bus node:
+
+- compatible: "moxa,moxart-mdio"
+- Inherits from MDIO bus node binding[1]
+
+[1] Documentation/devicetree/bindings/net/phy.txt
+
+
+Ethernet node:
+
Required properties:
- compatible : Must be "moxa,moxart-mac"
- reg : Should contain register location and length
- interrupts : Should contain the mac interrupt number
+Optional Properties:
+
+- phy-handle : the phandle to a PHY node
+
+
Example:
- mac0: mac at 90900000 {
+ mdio0: mdio at 90900090 {
+ compatible = "moxa,moxart-mdio";
+ reg = <0x90900090 0x8>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy0: ethernet-phy at 1 {
+ compatible = "moxa,moxart-rtl8201cp", "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ };
+ };
+
+ mdio1: mdio at 92000090 {
+ compatible = "moxa,moxart-mdio";
+ reg = <0x92000090 0x8>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy1: ethernet-phy at 1 {
+ compatible = "moxa,moxart-rtl8201cp", "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ };
+ };
+
+ mac0: ethernet at 90900000 {
compatible = "moxa,moxart-mac";
- reg = <0x90900000 0x100>;
+ reg = <0x90900000 0x90>;
interrupts = <25 0>;
+ phy-handle = <ðphy0>;
};
- mac1: mac at 92000000 {
+ mac1: ethernet at 92000000 {
compatible = "moxa,moxart-mac";
- reg = <0x92000000 0x100>;
+ reg = <0x92000000 0x90>;
interrupts = <27 0>;
+ phy-handle = <ðphy1>;
};
diff --git a/drivers/net/ethernet/moxa/moxart_ether.c b/drivers/net/ethernet/moxa/moxart_ether.c
index 17c9f0e..c19bff2 100644
--- a/drivers/net/ethernet/moxa/moxart_ether.c
+++ b/drivers/net/ethernet/moxa/moxart_ether.c
@@ -25,6 +25,9 @@
#include <linux/of_irq.h>
#include <linux/crc32.h>
#include <linux/crc32c.h>
+#include <linux/phy.h>
+#include <linux/of_mdio.h>
+#include <linux/of_net.h>
#include "moxart_ether.h"
@@ -60,6 +63,16 @@ static int moxart_set_mac_address(struct net_device *ndev, void *addr)
return 0;
}
+static int moxart_do_ioctl(struct net_device *ndev, struct ifreq *ir, int cmd)
+{
+ struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+
+ if (!netif_running(ndev))
+ return -EINVAL;
+
+ return phy_mii_ioctl(priv->phy_dev, ir, cmd);
+}
+
static void moxart_mac_free_memory(struct net_device *ndev)
{
struct moxart_mac_priv_t *priv = netdev_priv(ndev);
@@ -109,6 +122,19 @@ static void moxart_mac_enable(struct net_device *ndev)
writel(priv->reg_maccr, priv->base + REG_MAC_CTRL);
}
+static void moxart_mac_update_duplex(struct net_device *ndev)
+{
+ struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+
+ priv->reg_maccr &= ~(FULLDUP | ENRX_IN_HALFTX);
+ if (priv->duplex)
+ priv->reg_maccr |= FULLDUP;
+ else
+ priv->reg_maccr |= ENRX_IN_HALFTX;
+
+ writel(priv->reg_maccr, priv->base + REG_MAC_CTRL);
+}
+
static void moxart_mac_setup_desc_ring(struct net_device *ndev)
{
struct moxart_mac_priv_t *priv = netdev_priv(ndev);
@@ -168,6 +194,9 @@ static int moxart_mac_open(struct net_device *ndev)
moxart_update_mac_address(ndev);
moxart_mac_setup_desc_ring(ndev);
moxart_mac_enable(ndev);
+
+ phy_start(priv->phy_dev);
+
netif_start_queue(ndev);
netdev_dbg(ndev, "%s: IMR=0x%x, MACCR=0x%x\n",
@@ -183,6 +212,8 @@ static int moxart_mac_stop(struct net_device *ndev)
napi_disable(&priv->napi);
+ phy_stop(priv->phy_dev);
+
netif_stop_queue(ndev);
/* disable all interrupts */
@@ -435,12 +466,49 @@ static struct net_device_ops moxart_netdev_ops = {
.ndo_set_mac_address = moxart_set_mac_address,
.ndo_validate_addr = eth_validate_addr,
.ndo_change_mtu = eth_change_mtu,
+ .ndo_do_ioctl = moxart_do_ioctl,
};
+static void moxart_adjust_link(struct net_device *ndev)
+{
+ struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+ unsigned long flags;
+ int status_change = 0;
+
+ if (priv->phy_dev->link) {
+ if (priv->speed != priv->phy_dev->speed) {
+ priv->speed = priv->phy_dev->speed;
+ status_change = 1;
+ }
+
+ if (priv->duplex != priv->phy_dev->duplex) {
+ spin_lock_irqsave(&priv->txlock, flags);
+
+ priv->duplex = priv->phy_dev->duplex;
+ moxart_mac_update_duplex(ndev);
+
+ spin_unlock_irqrestore(&priv->txlock, flags);
+ status_change = 1;
+ }
+ }
+
+ if (priv->link != priv->phy_dev->link) {
+ if (!priv->phy_dev->link) {
+ priv->speed = 0;
+ priv->duplex = -1;
+ }
+ priv->link = priv->phy_dev->link;
+ status_change = 1;
+ }
+
+ if (status_change)
+ phy_print_status(priv->phy_dev);
+}
+
static int moxart_mac_probe(struct platform_device *pdev)
{
struct device *p_dev = &pdev->dev;
- struct device_node *node = p_dev->of_node;
+ struct device_node *node = p_dev->of_node, *phy_node;
struct net_device *ndev;
struct moxart_mac_priv_t *priv;
struct resource *res;
@@ -461,6 +529,28 @@ static int moxart_mac_probe(struct platform_device *pdev)
priv = netdev_priv(ndev);
priv->ndev = ndev;
+ priv->link = 0;
+ priv->speed = 0;
+ priv->duplex = -1;
+
+ phy_node = of_parse_phandle(node, "phy-handle", 0);
+ if (!phy_node) {
+ dev_err(p_dev, "of_parse_phandle failed\n");
+ ret = -ENODEV;
+ goto init_fail;
+ }
+
+ if (phy_node) {
+ priv->phy_dev = of_phy_connect(priv->ndev, phy_node,
+ &moxart_adjust_link,
+ 0, of_get_phy_mode(node));
+ if (!priv->phy_dev) {
+ dev_err(p_dev, "of_phy_connect failed\n");
+ ret = -ENODEV;
+ goto init_fail;
+ }
+ }
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
ndev->base_addr = res->start;
priv->base = devm_ioremap_resource(p_dev, res);
diff --git a/drivers/net/ethernet/moxa/moxart_ether.h b/drivers/net/ethernet/moxa/moxart_ether.h
index 2be9280..b8877bf 100644
--- a/drivers/net/ethernet/moxa/moxart_ether.h
+++ b/drivers/net/ethernet/moxa/moxart_ether.h
@@ -297,6 +297,8 @@ struct moxart_mac_priv_t {
unsigned int reg_imr;
struct napi_struct napi;
struct net_device *ndev;
+ struct phy_device *phy_dev;
+ int speed, duplex, link;
dma_addr_t rx_base;
dma_addr_t rx_mapping[RX_DESC_NUM];
--
1.8.2.1
^ permalink raw reply related
* [PATCH v4 3/4] ARM: pinctrl: Add Broadcom Capri pinctrl driver
From: Matt Porter @ 2014-01-21 13:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYAANtY=9QtDnYNZLSrF09nTWUH4nK5oJ7mzznS+_=bHA@mail.gmail.com>
On Mon, Jan 20, 2014 at 09:16:24AM +0100, Linus Walleij wrote:
> On Sat, Jan 18, 2014 at 3:56 AM, Matt Porter <mporter@linaro.org> wrote:
>
> > I wonder if Linus would accept a rename at this point (too late for 3.14
> > presumably, but for 3.15) of s/capri/bcm281xx throughout, bcm11351 for
> > the compatible string, as we have for the machine compatible, and also
> > BCM281XX for the Kconfig option.
>
> Yes, if there is some consensus that this is what we want to do.
>
> I can certainly merge that during the 3.14-rc phase for that matter.
Ok, sounds great, thanks.
-Matt
^ permalink raw reply
* [PATCH v4] arm: remove !CPU_V6 and !GENERIC_ATOMIC64 build dependencies for XEN
From: Stefano Stabellini @ 2014-01-21 13:44 UTC (permalink / raw)
To: linux-arm-kernel
Remove !GENERIC_ATOMIC64 build dependency:
- introduce xen_atomic64_xchg
- use it to implement xchg_xen_ulong
Remove !CPU_V6 build dependency:
- introduce __cmpxchg8 and __cmpxchg16, compiled even ifdef
CONFIG_CPU_V6
- implement sync_cmpxchg using __cmpxchg8 and __cmpxchg16
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: arnd at arndb.de
CC: linux at arm.linux.org.uk
CC: will.deacon at arm.com
CC: catalin.marinas at arm.com
CC: linux-arm-kernel at lists.infradead.org
CC: linux-kernel at vger.kernel.org
CC: xen-devel at lists.xenproject.org
---
Changes in v4:
- avoid moving and renaming atomic64_xchg
- introduce xen_atomic64_xchg
- fix asm comment in __cmpxchg8 and __cmpxchg16.
---
arch/arm/Kconfig | 3 +-
arch/arm/include/asm/cmpxchg.h | 60 ++++++++++++++++++++++++------------
arch/arm/include/asm/sync_bitops.h | 24 ++++++++++++++-
arch/arm/include/asm/xen/events.h | 32 ++++++++++++++++++-
4 files changed, 95 insertions(+), 24 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index c1f1a7e..ae54ae0 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1881,8 +1881,7 @@ config XEN_DOM0
config XEN
bool "Xen guest support on ARM (EXPERIMENTAL)"
depends on ARM && AEABI && OF
- depends on CPU_V7 && !CPU_V6
- depends on !GENERIC_ATOMIC64
+ depends on CPU_V7
select ARM_PSCI
select SWIOTLB_XEN
help
diff --git a/arch/arm/include/asm/cmpxchg.h b/arch/arm/include/asm/cmpxchg.h
index df2fbba..a17cff1 100644
--- a/arch/arm/include/asm/cmpxchg.h
+++ b/arch/arm/include/asm/cmpxchg.h
@@ -133,6 +133,44 @@ extern void __bad_cmpxchg(volatile void *ptr, int size);
* cmpxchg only support 32-bits operands on ARMv6.
*/
+static inline unsigned long __cmpxchg8(volatile void *ptr, unsigned long old,
+ unsigned long new)
+{
+ unsigned long oldval, res;
+
+ do {
+ asm volatile("@ __cmpxchg8\n"
+ " ldrexb %1, [%2]\n"
+ " mov %0, #0\n"
+ " teq %1, %3\n"
+ " strexbeq %0, %4, [%2]\n"
+ : "=&r" (res), "=&r" (oldval)
+ : "r" (ptr), "Ir" (old), "r" (new)
+ : "memory", "cc");
+ } while (res);
+
+ return oldval;
+}
+
+static inline unsigned long __cmpxchg16(volatile void *ptr, unsigned long old,
+ unsigned long new)
+{
+ unsigned long oldval, res;
+
+ do {
+ asm volatile("@ __cmpxchg16\n"
+ " ldrexh %1, [%2]\n"
+ " mov %0, #0\n"
+ " teq %1, %3\n"
+ " strexheq %0, %4, [%2]\n"
+ : "=&r" (res), "=&r" (oldval)
+ : "r" (ptr), "Ir" (old), "r" (new)
+ : "memory", "cc");
+ } while (res);
+
+ return oldval;
+}
+
static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
unsigned long new, int size)
{
@@ -141,28 +179,10 @@ static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
switch (size) {
#ifndef CONFIG_CPU_V6 /* min ARCH >= ARMv6K */
case 1:
- do {
- asm volatile("@ __cmpxchg1\n"
- " ldrexb %1, [%2]\n"
- " mov %0, #0\n"
- " teq %1, %3\n"
- " strexbeq %0, %4, [%2]\n"
- : "=&r" (res), "=&r" (oldval)
- : "r" (ptr), "Ir" (old), "r" (new)
- : "memory", "cc");
- } while (res);
+ oldval = __cmpxchg8(ptr, old, new);
break;
case 2:
- do {
- asm volatile("@ __cmpxchg1\n"
- " ldrexh %1, [%2]\n"
- " mov %0, #0\n"
- " teq %1, %3\n"
- " strexheq %0, %4, [%2]\n"
- : "=&r" (res), "=&r" (oldval)
- : "r" (ptr), "Ir" (old), "r" (new)
- : "memory", "cc");
- } while (res);
+ oldval = __cmpxchg16(ptr, old, new);
break;
#endif
case 4:
diff --git a/arch/arm/include/asm/sync_bitops.h b/arch/arm/include/asm/sync_bitops.h
index 63479ee..942659a 100644
--- a/arch/arm/include/asm/sync_bitops.h
+++ b/arch/arm/include/asm/sync_bitops.h
@@ -21,7 +21,29 @@
#define sync_test_and_clear_bit(nr, p) _test_and_clear_bit(nr, p)
#define sync_test_and_change_bit(nr, p) _test_and_change_bit(nr, p)
#define sync_test_bit(nr, addr) test_bit(nr, addr)
-#define sync_cmpxchg cmpxchg
+static inline unsigned long sync_cmpxchg(volatile void *ptr,
+ unsigned long old,
+ unsigned long new)
+{
+ unsigned long oldval;
+ int size = sizeof(*(ptr));
+
+ smp_mb();
+ switch (size) {
+ case 1:
+ oldval = __cmpxchg8(ptr, old, new);
+ break;
+ case 2:
+ oldval = __cmpxchg16(ptr, old, new);
+ break;
+ default:
+ oldval = __cmpxchg(ptr, old, new, size);
+ break;
+ }
+ smp_mb();
+
+ return oldval;
+}
#endif
diff --git a/arch/arm/include/asm/xen/events.h b/arch/arm/include/asm/xen/events.h
index 8b1f37b..2032ee6 100644
--- a/arch/arm/include/asm/xen/events.h
+++ b/arch/arm/include/asm/xen/events.h
@@ -16,7 +16,37 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
return raw_irqs_disabled_flags(regs->ARM_cpsr);
}
-#define xchg_xen_ulong(ptr, val) atomic64_xchg(container_of((ptr), \
+#ifdef CONFIG_GENERIC_ATOMIC64
+/* if CONFIG_GENERIC_ATOMIC64 is defined we cannot use the generic
+ * atomic64_xchg function because it is implemented using spin locks.
+ * Here we need proper atomic instructions to read and write memory
+ * shared with the hypervisor.
+ */
+static inline u64 xen_atomic64_xchg(atomic64_t *ptr, u64 new)
+{
+ u64 result;
+ unsigned long tmp;
+
+ smp_mb();
+
+ __asm__ __volatile__("@ xen_atomic64_xchg\n"
+"1: ldrexd %0, %H0, [%3]\n"
+" strexd %1, %4, %H4, [%3]\n"
+" teq %1, #0\n"
+" bne 1b"
+ : "=&r" (result), "=&r" (tmp), "+Qo" (ptr->counter)
+ : "r" (&ptr->counter), "r" (new)
+ : "cc");
+
+ smp_mb();
+
+ return result;
+}
+#else
+#define xen_atomic64_xchg atomic64_xchg
+#endif
+
+#define xchg_xen_ulong(ptr, val) xen_atomic64_xchg(container_of((ptr), \
atomic64_t, \
counter), (val))
--
1.7.10.4
^ permalink raw reply related
* [PATCH v2] dma: imx-sdma: clarify firmare not found warning
From: Lothar Waßmann @ 2014-01-21 13:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140121115706.GT15937@n2100.arm.linux.org.uk>
Hi,
Russell King - ARM Linux wrote:
> On Tue, Jan 21, 2014 at 12:52:00PM +0100, Lothar Wa?mann wrote:
> > Hi,
> >
> > Russell King - ARM Linux wrote:
> > > On Tue, Jan 21, 2014 at 07:59:22AM +0100, Lothar Wa?mann wrote:
> > > > The file is automatically removed after the timeout has expired (or
> > > > the frimware has been loaded).
> > > > Thus you must check for it within the timeout period during boot.
> > >
> > > ... which is impossible if imx-sdma is built into the kernel - it
> > > expires while the initramfs has only just started running, giving a
> > > very narrow window for userspace to load firmware.
> > >
> > It works for me, but I'm not using initramfs.
>
> You can take my email as a report of "it doesn't work for everyone." The
> *only* way I can get firmware to load is to build imx-sdma as a module.
> Building it in is a hopeless case here.
>
You could change the timeout from your initramfs as soon as sysfs has
been mounted by writing the number of seconds to
/sys/class/firmware/timeout. A timeout of '0' means 'wait forever' which
should be long enough for any boot case. ;)
Lothar Wa?mann
--
___________________________________________________________
Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | info at karo-electronics.de
___________________________________________________________
^ permalink raw reply
* [patch] drm/exynos: potential use after free in exynos_drm_open()
From: Dan Carpenter @ 2014-01-21 13:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52DE6B8B.6080304@bfs.de>
On Tue, Jan 21, 2014 at 01:43:55PM +0100, walter harms wrote:
>
> i have just noticed: The function already exits
>
> 194 static void exynos_drm_postclose(struct drm_device *dev, struct drm_file *file)
> 195 {
> 196 if (!file->driver_priv)
> 197 return;
> 198
> 199 kfree(file->driver_priv);
> 200 file->driver_priv = NULL;
> 201 }
The function is different in the current code. I glanced through
drm_open_helper() and I don't see that file->driver_priv to NULL is
needed anyway...
regards,
dan carpenter
^ permalink raw reply
* [PATCH 1/4 v3] mfd: tc3589x: Add device tree bindings
From: Linus Walleij @ 2014-01-21 13:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1384265558-10521-1-git-send-email-linus.walleij@linaro.org>
On Tue, Nov 12, 2013 at 3:12 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> This defines the device tree bindings for the Toshiba TC3589x
> series of multi-purpose expanders. Only the stuff I can test
> is defined: GPIO and keypad. Others may implement more
> subdevices further down the road.
>
> This is to complement
> commit a435ae1d51e2f18414f2a87219fdbe068231e692
> "mfd: Enable the tc3589x for Device Tree" which left off
> the definition of the device tree bindings.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ChangeLog v2->v3:
> - Fix the keys/rows bindings to be u32 rather than
> /bits/ 8, inconsistency noted by Mark Rutland.
> ChangeLog v1->v2:
> - Include a verbose example in the DT bindings.
> - Explain why this is a stand-alone bindings patch.
So will this since Nov 12 uncommented-upon patch be merged or
do you want me to do some change?
There was some back-and-forth regarding the (existing, already
in use) linux-specific input bindings but the only thing I can
see is some back and forth leaning toward just letting these
be used.
I am happy to change this in whatever way but no directions
for two months....
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 4/5 v3] input: tc3589x-keypad: support probing from device tree
From: Linus Walleij @ 2014-01-21 13:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZW-Nay-wOywq4SG1bwQf_+J4tqYuS=tQmzTHOtBskGVw@mail.gmail.com>
On Tue, Jan 21, 2014 at 2:28 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Tue, Nov 26, 2013 at 3:34 AM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
>> On Tue, Nov 12, 2013 at 04:31:01PM +0100, Linus Walleij wrote:
>>> irq = platform_get_irq(pdev, 0);
>>> --
>>
>> Don't you also want to add MODULE_DEVICE_TABLE entry?
>
> Probably, but that'd be a separate subject though, I think?
> I'll make a patch for this so you get something you can
> actually merge.
No, wait, this driver only matches on driver name, it has no
match table of any kind. This is typical for MFD-spun cells
if they don't need additional info from the compat match.
I think it only needs the MODULE_ALIAS() it already
has.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH RFC v2 2/2] Documentation: arm: define DT C-states bindings
From: Lorenzo Pieralisi @ 2014-01-21 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKfTPtAbYXuis1bfyDLiHRaYwosre3RAG+iNQSz-y+cWfc3uQA@mail.gmail.com>
On Tue, Jan 21, 2014 at 11:16:46AM +0000, Vincent Guittot wrote:
[...]
> > +- Dormant:
> > + # Dormant mode is entered by executing wfi instructions and by sending
> > + platform specific commands to the platform power controller (coupled
> > + with processor specific SW/HW control sequences).
> > + In dormant mode, most of the processor control and debug logic is
> > + powered up but cache RAM can be put in retention state, providing
>
> Base on your description, it's not clear for me what is on, what is
> lost and what is power down ?
Sorry, typo, "powered down", not powered up.
> My understand of the dormant mode that you described above is : the
> cache is preserved (and especially the cache RAM) but the processor
> state is lost (registers ...). Do I understand correctly ?
Yes.
> What about retention mode where the contents of processor and cache
> are preserved but the power consumption is reduced ? it can be seen as
> a special wfi mode which need specific SW/HW control sequences but i'm
> not sure to understand how to describe such state with your proposal.
True, and I omitted that on purpose so that it can be debated and to
keep it simple (well, so to speak) thanks for pointing that out.
The bindings allow a C-state to link to a power domain. Each device can
link itself to a power domain. Hence at least now we know what devices
are affected by a C-state (and by device I also mean arch timers, PMUs,
GIC, etc).
Now, retention vs. off. In theory we could link a device to a C-state
and define what mode would be that device on C-state entry, but honestly
it starts becoming looooots of data in the DT.
For instance, we could define for every device the max C-state index allowed
for the device context to be powered-up (or retained).
Or, find a way to describe it through the power domain specifier:
cache {
power-domain = <&foo 0 &foo 1>:
power-state = <1 0>;
};
which means that for the pair <&foo 0> cache is retained (1 == retained,
0 == lost) and for power domain <&foo 1> cache is lost.
I have no complete answer, certainly this adds complexity (but it is a very
complex problem, so..) and it is a bit horrible, ideas welcome.
[...]
> > + - psci-power-state
> > + Usage: Required if entry-method property value is set to
> > + "psci".
> > + Value type: <u32>
> > + Definition: power_state parameter to pass to the PSCI
> > + suspend call to enter the C-state.
>
> Why psci has got a dedicated field and not vendor methods ? can't you
> make that more generic ?
If anyone provides me with an example usage why not, for now I know I
need that parameter for PSCI, I can call it differently, define it for PSCI
and leave it as optional for other methods.
Thanks,
Lorenzo
^ permalink raw reply
* [PATCH 4/5 v3] input: tc3589x-keypad: support probing from device tree
From: Linus Walleij @ 2014-01-21 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20131126023431.GC31517@core.coreip.homeip.net>
On Tue, Nov 26, 2013 at 3:34 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Tue, Nov 12, 2013 at 04:31:01PM +0100, Linus Walleij wrote:
>> Implement device tree probing for the tc3589x keypad driver.
>> This is modeled on the STMPE keypad driver and tested on the
>> Ux500 TVK1281618 UIB.
>>
>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>> ---
>> ChangeLog v2->v3:
>> - Use two local u32 variables to avoid weirdness in u8 casting
>> of the resulting values to the pointers.
>> ChangeLog v1->v2:
>> - Fix rows/columns binding to read two u32's insead of two
>> u8 /bits/ as noted by Mark Rutland.
>> ---
>> drivers/input/keyboard/tc3589x-keypad.c | 66 ++++++++++++++++++++++++++++++++-
>> 1 file changed, 64 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/input/keyboard/tc3589x-keypad.c b/drivers/input/keyboard/tc3589x-keypad.c
>> index 208de7cbb7fa..7f36e7addb86 100644
>> --- a/drivers/input/keyboard/tc3589x-keypad.c
>> +++ b/drivers/input/keyboard/tc3589x-keypad.c
>> @@ -297,6 +297,65 @@ static void tc3589x_keypad_close(struct input_dev *input)
>> tc3589x_keypad_disable(keypad);
>> }
>>
>> +#ifdef CONFIG_OF
>> +static const struct tc3589x_keypad_platform_data *
>> +tc3589x_keypad_of_probe(struct device *dev)
>> +{
>> + struct device_node *np = dev->of_node;
>> + struct tc3589x_keypad_platform_data *plat;
>> + u32 cols, rows;
>> + u32 debounce_ms;
>> + int proplen;
>> +
>> + if (!np)
>> + return ERR_PTR(-ENODEV);
>> +
>> + plat = devm_kzalloc(dev, sizeof(*plat), GFP_KERNEL);
>> + if (!plat)
>> + return ERR_PTR(-ENOMEM);
>> +
>> + of_property_read_u32(np, "keypad,num-columns", &cols);
>> + of_property_read_u32(np, "keypad,num-rows", &rows);
>> + plat->kcol = (u8) cols;
>> + plat->krow = (u8) rows;
>> + if (!plat->krow || !plat->kcol ||
>> + plat->krow > TC_KPD_ROWS || plat->kcol > TC_KPD_COLUMNS) {
>> + dev_err(dev,
>> + "keypad columns/rows not properly specified (%ux%u)\n",
>> + plat->kcol, plat->krow);
>> + return ERR_PTR(-EINVAL);
>> + }
>> +
>> + if (!of_get_property(np, "linux,keymap", &proplen)) {
>> + dev_err(dev, "property linux,keymap not found\n");
>> + return ERR_PTR(-ENOENT);
>> + }
>> +
>> + plat->no_autorepeat = of_property_read_bool(np, "linux,no-autorepeat");
>
> So, have DT overlords settled on the autorepeat property?
Yeah, what is happening here? Shall we delay this patch set perpetually
due to inability to get some clear indication on this, or shall we just merge
it?
>> irq = platform_get_irq(pdev, 0);
>> --
>
> Don't you also want to add MODULE_DEVICE_TABLE entry?
Probably, but that'd be a separate subject though, I think?
I'll make a patch for this so you get something you can
actually merge.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v3 15/15] ARM: mvebu: Enable watchdog support in defconfig
From: Ezequiel Garcia @ 2014-01-21 13:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390310774-20781-1-git-send-email-ezequiel.garcia@free-electrons.com>
Now that we have proper support for Armada 370/XP watchdog
let's enable it in the defconfig.
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
arch/arm/configs/mvebu_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig
index 594d706..84ec924 100644
--- a/arch/arm/configs/mvebu_defconfig
+++ b/arch/arm/configs/mvebu_defconfig
@@ -60,6 +60,8 @@ CONFIG_GPIOLIB=y
CONFIG_GPIO_SYSFS=y
CONFIG_THERMAL=y
CONFIG_ARMADA_THERMAL=y
+CONFIG_WATCHDOG=y
+CONFIG_ORION_WATCHDOG=y
CONFIG_USB_SUPPORT=y
CONFIG_USB=y
CONFIG_USB_EHCI_HCD=y
--
1.8.1.5
^ permalink raw reply related
* [PATCH v3 14/15] watchdog: orion: Enable the build on ARCH_MVEBU
From: Ezequiel Garcia @ 2014-01-21 13:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390310774-20781-1-git-send-email-ezequiel.garcia@free-electrons.com>
After adding support for Armada 370/XP SoC let's enable the build on
these platforms.
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
drivers/watchdog/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 5be6e91..8b79012 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -282,7 +282,7 @@ config DAVINCI_WATCHDOG
config ORION_WATCHDOG
tristate "Orion watchdog"
- depends on ARCH_ORION5X || ARCH_KIRKWOOD || ARCH_DOVE
+ depends on ARCH_ORION5X || ARCH_KIRKWOOD || ARCH_DOVE || ARCH_MVEBU
select WATCHDOG_CORE
help
Say Y here if to include support for the watchdog timer
--
1.8.1.5
^ permalink raw reply related
* [PATCH v3 13/15] ARM: kirkwood: Add RSTOUT 'reg' entry to devicetree
From: Ezequiel Garcia @ 2014-01-21 13:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390310774-20781-1-git-send-email-ezequiel.garcia@free-electrons.com>
In order to support multiplatform builds the watchdog devicetree binding
was modified and now the 'reg' property is specified to need two
entries. This commit adds the second entry as-per the new specification.
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
arch/arm/boot/dts/kirkwood.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
index 8b73c80..80a56b0 100644
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -165,7 +165,7 @@
wdt: watchdog-timer at 20300 {
compatible = "marvell,orion-wdt";
- reg = <0x20300 0x28>;
+ reg = <0x20300 0x28>, <0x20108 0x4>;
interrupt-parent = <&bridge_intc>;
interrupts = <3>;
clocks = <&gate_clk 7>;
--
1.8.1.5
^ 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