* [PATCH] arm: document "mach-virt" platform.
From: Ian Campbell @ 2014-01-30 17:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52EA8AD3.8080904@arm.com>
On Thu, 2014-01-30 at 17:24 +0000, Marc Zyngier wrote:
> >> I'm afraid I disagree with most of the above. The whole point of
> >> mach-virt is to provide a shell for DT platforms. None of this hardware
> >> is mandated. Instead, all the necessary information should be described
> >> in DT.
> >
> > "Add support for the smallest, dumbest possible platform, to be
> > used as a guest for KVM or other hypervisors.
> >
> > It only mandates a GIC and architected timers"
> >
> > (your original commit message :-P)
>
> Right. 1984, here we come. I'll disappear for a while, rewriting the
> history. More seriously, that was just me scheming to get it merged,
> hiding my cunning plan for mach-virt world domination!
:-)
> >> Actually, mach-virt doesn't really stand for Virtual Machine. It stands
> >> for virtual mach-* directory! Eventually, mach-virt should become the
> >> default platform, the one we use when we don't match anything else in
> >> the kernel
> >
> > I can word it more like that for sure, along with the alternative
> > wording suggested by Christopher/Stefano to clarify the intent that
> > everything comes from DTB and removal of the specific requirements for
> > GIC/timer/PSCI I think that suit the (new) intention better?
>
> Yes, please! :-)
OK, I'll come up with an updated version.
Cheers,
Ian.
^ permalink raw reply
* [PATCH] arm: document "mach-virt" platform.
From: Arnd Bergmann @ 2014-01-30 17:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391098262-15944-1-git-send-email-ian.campbell@citrix.com>
On Thursday 30 January 2014, Ian Campbell wrote:
> mach-virt has existed for a while but it is not written down what it actually
> consists of. Although it seems a bit unusual to document a binding for an
> entire platform since mach-virt is entirely virtual it is helpful to have
> something to refer to in the absence of a single concrete implementation.
>
> I've done my best to capture the requirements based on the git log and my
> memory/understanding.
>
> While here remove the xenvm dts example, the Xen tools will now build a
> suitable mach-virt compatible dts when launching the guest.
It might be worth noting in the changeset comment that the 'compatible'
string is actually no longer needed on newer kernels: All the members
of the machine descriptor are now the defaults (we should remove the
virt_init() function as well), and the fallback machine descriptor should
work just fine if any other string gets passed.
Arnd
^ permalink raw reply
* [PATCH v2 1/6] idle: move the cpuidle entry point to the generic idle loop
From: Daniel Lezcano @ 2014-01-30 17:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.11.1401301056180.1652@knanqh.ubzr>
On 01/30/2014 05:07 PM, Nicolas Pitre wrote:
> On Thu, 30 Jan 2014, Daniel Lezcano wrote:
>
>> On 01/30/2014 06:28 AM, Nicolas Pitre wrote:
>>> On Thu, 30 Jan 2014, Preeti U Murthy wrote:
>>>
>>>> Hi Nicolas,
>>>>
>>>> On 01/30/2014 02:01 AM, Nicolas Pitre wrote:
>>>>> On Wed, 29 Jan 2014, Nicolas Pitre wrote:
>>>>>
>>>>>> In order to integrate cpuidle with the scheduler, we must have a
>>>>>> better
>>>>>> proximity in the core code with what cpuidle is doing and not delegate
>>>>>> such interaction to arch code.
>>>>>>
>>>>>> Architectures implementing arch_cpu_idle() should simply enter
>>>>>> a cheap idle mode in the absence of a proper cpuidle driver.
>>>>>>
>>>>>> Signed-off-by: Nicolas Pitre <nico@linaro.org>
>>>>>> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>>>>>
>>>>> As mentioned in my reply to Olof's comment on patch #5/6, here's a new
>>>>> version of this patch adding the safety local_irq_enable() to the core
>>>>> code.
>>>>>
>>>>> ----- >8
>>>>>
>>>>> From: Nicolas Pitre <nicolas.pitre@linaro.org>
>>>>> Subject: idle: move the cpuidle entry point to the generic idle loop
>>>>>
>>>>> In order to integrate cpuidle with the scheduler, we must have a better
>>>>> proximity in the core code with what cpuidle is doing and not delegate
>>>>> such interaction to arch code.
>>>>>
>>>>> Architectures implementing arch_cpu_idle() should simply enter
>>>>> a cheap idle mode in the absence of a proper cpuidle driver.
>>>>>
>>>>> In both cases i.e. whether it is a cpuidle driver or the default
>>>>> arch_cpu_idle(), the calling convention expects IRQs to be disabled
>>>>> on entry and enabled on exit. There is a warning in place already but
>>>>> let's add a forced IRQ enable here as well. This will allow for
>>>>> removing the forced IRQ enable some implementations do locally and
>>>>
>>>> Why would this patch allow for removing the forced IRQ enable that are
>>>> being done on some archs in arch_cpu_idle()? Isn't this patch expecting
>>>> the default arch_cpu_idle() to have re-enabled the interrupts after
>>>> exiting from the default idle state? Its supposed to only catch faulty
>>>> cpuidle drivers that haven't enabled IRQs on exit from idle state but
>>>> are expected to have done so, isn't it?
>>>
>>> Exact. However x86 currently does this:
>>>
>>> if (cpuidle_idle_call())
>>> x86_idle();
>>> else
>>> local_irq_enable();
>>>
>>> So whenever cpuidle_idle_call() is successful then IRQs are
>>> unconditionally enabled whether or not the underlying cpuidle driver has
>>> properly done it or not. And the reason is that some of the x86 cpuidle
>>> do fail to enable IRQs before returning.
>>>
>>> So the idea is to get rid of this unconditional IRQ enabling and let the
>>> core issue a warning instead (as well as enabling IRQs to allow the
>>> system to run).
>>
>> But what I don't get with your comment is the local_irq_enable is done from
>> the cpuidle common framework in 'cpuidle_enter_state' it is not done from the
>> arch specific backend cpuidle driver.
>
> Oh well... This certainly means we'll have to clean this mess as some
> drivers do it on their own while some others don't. Some drivers also
> loop on !need_resched() while some others simply return on the first
> interrupt.
Ok, I think the mess is coming from 'default_idle' which does not
re-enable the local_irq but used from different places like
amd_e400_idle and apm_cpu_idle.
void default_idle(void)
{
trace_cpu_idle_rcuidle(1, smp_processor_id());
safe_halt();
trace_cpu_idle_rcuidle(PWR_EVENT_EXIT, smp_processor_id());
}
Considering the system configured without cpuidle because this one
*always* enable the local irq, we have the different cases:
x86_idle = default_idle();
==> local_irq_enable is missing
x86_idle = amd_e400_idle();
==> it calls local_irq_disable(); but in the idle loop context where the
local irqs are already disabled.
==> if amd_e400_c1e_detected is true, the local_irq are enabled
==> otherwise no
==> default_idle is called from there and does not enable local_irqs
>> So the code above could be:
>>
>> if (cpuidle_idle_call())
>> x86_idle();
>>
>> without the else section, this local_irq_enable is pointless. Or may be I
>> missed something ?
>
> A later patch removes it anyway. But if it is really necessary to
> enable interrupts then the core will do it but with a warning now.
This WARN should disappear. It was there because it was up to the
backend cpuidle driver to enable the irq. But in the meantime, that was
consolidated into a single place in the cpuidle framework so no need to
try to catch errors.
What about (based on this patchset).
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 4505e2a..2d60cbb 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -299,6 +299,7 @@ void arch_cpu_idle_dead(void)
void arch_cpu_idle(void)
{
x86_idle();
+ local_irq_enable();
}
/*
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply related
* [PATCH] arm: document "mach-virt" platform.
From: Marc Zyngier @ 2014-01-30 17:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391102475.9495.44.camel@kazak.uk.xensource.com>
On 30/01/14 17:21, Ian Campbell wrote:
> On Thu, 2014-01-30 at 17:13 +0000, Marc Zyngier wrote:
>> Hi Ian,
>>
>> On 30/01/14 16:11, Ian Campbell wrote:
>>> mach-virt has existed for a while but it is not written down what it actually
>>> consists of. Although it seems a bit unusual to document a binding for an
>>> entire platform since mach-virt is entirely virtual it is helpful to have
>>> something to refer to in the absence of a single concrete implementation.
>>>
>>> I've done my best to capture the requirements based on the git log and my
>>> memory/understanding.
>>>
>>> While here remove the xenvm dts example, the Xen tools will now build a
>>> suitable mach-virt compatible dts when launching the guest.
>>>
>>> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>>> Cc: Rob Herring <robh+dt@kernel.org>
>>> Cc: Pawel Moll <pawel.moll@arm.com>
>>> Cc: Mark Rutland <mark.rutland@arm.com>
>>> Cc: Kumar Gala <galak@codeaurora.org>
>>> Cc: Olof Johansson <olof@lixom.net>
>>> Cc: Arnd Bergmann <arnd@arndb.de>
>>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>>> Cc: Will Deacon <will.deacon@arm.com>
>>> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>> Cc: devicetree at vger.kernel.org
>>> Cc: linux-kernel at vger.kernel.org
>>> Cc: linux-arm-kernel at lists.infradead.org
>>> ---
>>> I'm not sure which tree this sort of thing should go though, sorry for the
>>> huge Cc.
>>> ---
>>> .../devicetree/bindings/arm/mach-virt.txt | 32 ++++++++
>>> arch/arm/boot/dts/xenvm-4.2.dts | 81 --------------------
>>> 2 files changed, 32 insertions(+), 81 deletions(-)
>>> create mode 100644 Documentation/devicetree/bindings/arm/mach-virt.txt
>>> delete mode 100644 arch/arm/boot/dts/xenvm-4.2.dts
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/mach-virt.txt b/Documentation/devicetree/bindings/arm/mach-virt.txt
>>> new file mode 100644
>>> index 0000000..562bcda
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/arm/mach-virt.txt
>>> @@ -0,0 +1,32 @@
>>> +* Mach-virt "Dummy Virtual Machine" platform
>>> +
>>> +"mach-virt" is the smallest, dumbest platform possible, to be used as
>>> +a guest for Xen, KVM and other hypervisors. It has no
>>> +properties/functionality of its own and is driven entirely by device
>>> +tree.
>>> +
>>> +This document defines the requirements for such a platform.
>>> +
>>> +* Required properties:
>>> +
>>> +- compatible: should be one of:
>>> + "linux,dummy-virt"
>>> + "xen,xenvm"
>>> +
>>> +In addition to the standard nodes (chosen, cpus, memory etc) the
>>> +platform is required to provide certain other basic functionality
>>> +which must be described in the device tree:
>>> +
>>> + The platform must provide an ARM Generic Interrupt Controller
>>> + (GIC), defined in Documentation/devicetree/bindings/arm/gic.txt.
>>> +
>>> + The platform must provide ARM architected timer, defined in
>>> + Documentation/devicetree/bindings/arm/arch_timer.txt.
>>> +
>>> + If the platform is SMP then it must provide the Power State
>>> + Coordination Interface (PSCI) described in
>>> + Documentation/devicetree/bindings/arm/psci.txt.
>>
>> I'm afraid I disagree with most of the above. The whole point of
>> mach-virt is to provide a shell for DT platforms. None of this hardware
>> is mandated. Instead, all the necessary information should be described
>> in DT.
>
> "Add support for the smallest, dumbest possible platform, to be
> used as a guest for KVM or other hypervisors.
>
> It only mandates a GIC and architected timers"
>
> (your original commit message :-P)
Right. 1984, here we come. I'll disappear for a while, rewriting the
history. More seriously, that was just me scheming to get it merged,
hiding my cunning plan for mach-virt world domination!
>> Actually, mach-virt doesn't really stand for Virtual Machine. It stands
>> for virtual mach-* directory! Eventually, mach-virt should become the
>> default platform, the one we use when we don't match anything else in
>> the kernel
>
> I can word it more like that for sure, along with the alternative
> wording suggested by Christopher/Stefano to clarify the intent that
> everything comes from DTB and removal of the specific requirements for
> GIC/timer/PSCI I think that suit the (new) intention better?
Yes, please! :-)
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] arm: document "mach-virt" platform.
From: Ian Campbell @ 2014-01-30 17:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52EA8853.8080709@arm.com>
On Thu, 2014-01-30 at 17:13 +0000, Marc Zyngier wrote:
> Hi Ian,
>
> On 30/01/14 16:11, Ian Campbell wrote:
> > mach-virt has existed for a while but it is not written down what it actually
> > consists of. Although it seems a bit unusual to document a binding for an
> > entire platform since mach-virt is entirely virtual it is helpful to have
> > something to refer to in the absence of a single concrete implementation.
> >
> > I've done my best to capture the requirements based on the git log and my
> > memory/understanding.
> >
> > While here remove the xenvm dts example, the Xen tools will now build a
> > suitable mach-virt compatible dts when launching the guest.
> >
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: Pawel Moll <pawel.moll@arm.com>
> > Cc: Mark Rutland <mark.rutland@arm.com>
> > Cc: Kumar Gala <galak@codeaurora.org>
> > Cc: Olof Johansson <olof@lixom.net>
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Cc: Marc Zyngier <marc.zyngier@arm.com>
> > Cc: Will Deacon <will.deacon@arm.com>
> > Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Cc: devicetree at vger.kernel.org
> > Cc: linux-kernel at vger.kernel.org
> > Cc: linux-arm-kernel at lists.infradead.org
> > ---
> > I'm not sure which tree this sort of thing should go though, sorry for the
> > huge Cc.
> > ---
> > .../devicetree/bindings/arm/mach-virt.txt | 32 ++++++++
> > arch/arm/boot/dts/xenvm-4.2.dts | 81 --------------------
> > 2 files changed, 32 insertions(+), 81 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/arm/mach-virt.txt
> > delete mode 100644 arch/arm/boot/dts/xenvm-4.2.dts
> >
> > diff --git a/Documentation/devicetree/bindings/arm/mach-virt.txt b/Documentation/devicetree/bindings/arm/mach-virt.txt
> > new file mode 100644
> > index 0000000..562bcda
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/mach-virt.txt
> > @@ -0,0 +1,32 @@
> > +* Mach-virt "Dummy Virtual Machine" platform
> > +
> > +"mach-virt" is the smallest, dumbest platform possible, to be used as
> > +a guest for Xen, KVM and other hypervisors. It has no
> > +properties/functionality of its own and is driven entirely by device
> > +tree.
> > +
> > +This document defines the requirements for such a platform.
> > +
> > +* Required properties:
> > +
> > +- compatible: should be one of:
> > + "linux,dummy-virt"
> > + "xen,xenvm"
> > +
> > +In addition to the standard nodes (chosen, cpus, memory etc) the
> > +platform is required to provide certain other basic functionality
> > +which must be described in the device tree:
> > +
> > + The platform must provide an ARM Generic Interrupt Controller
> > + (GIC), defined in Documentation/devicetree/bindings/arm/gic.txt.
> > +
> > + The platform must provide ARM architected timer, defined in
> > + Documentation/devicetree/bindings/arm/arch_timer.txt.
> > +
> > + If the platform is SMP then it must provide the Power State
> > + Coordination Interface (PSCI) described in
> > + Documentation/devicetree/bindings/arm/psci.txt.
>
> I'm afraid I disagree with most of the above. The whole point of
> mach-virt is to provide a shell for DT platforms. None of this hardware
> is mandated. Instead, all the necessary information should be described
> in DT.
"Add support for the smallest, dumbest possible platform, to be
used as a guest for KVM or other hypervisors.
It only mandates a GIC and architected timers"
(your original commit message :-P)
> Actually, mach-virt doesn't really stand for Virtual Machine. It stands
> for virtual mach-* directory! Eventually, mach-virt should become the
> default platform, the one we use when we don't match anything else in
> the kernel
I can word it more like that for sure, along with the alternative
wording suggested by Christopher/Stefano to clarify the intent that
everything comes from DTB and removal of the specific requirements for
GIC/timer/PSCI I think that suit the (new) intention better?
> What you've described here are requirements for a hypervisor like Xen or
> KVM. mach-virt itself shouldn't have any of that.
>
> Cheers,
>
> M.
^ permalink raw reply
* [PATCH] arm: document "mach-virt" platform.
From: Ian Campbell @ 2014-01-30 17:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52EA83D6.9050506@codeaurora.org>
On Thu, 2014-01-30 at 11:54 -0500, Christopher Covington wrote:
> > +++ b/Documentation/devicetree/bindings/arm/mach-virt.txt
> > @@ -0,0 +1,32 @@
> > +* Mach-virt "Dummy Virtual Machine" platform
> > +
> > +"mach-virt" is the smallest, dumbest platform possible, to be used as
> > +a guest for Xen, KVM and other hypervisors.
>
> The platform is also useful to, and used by, simulators like QEMU in TCG mode.
I can mention this, although I don't think the list needs to be
exhaustive.
It has no
> > +properties/functionality of its own and is driven entirely by device
> > +tree.
>
> I find this wording confusing. I read it as saying the platform has no
> properties or functionality. Perhaps you could phrase it slightly differently,
> such as having no properties or functionality beyond what's described in the
> device tree.
Yes, this is what I was trying to say, I'll update with something along
those lines.
> > +The platform may also provide hypervisor specific functionality
> > +(e.g. PV I/O), if it does so then this functionality must be
> > +discoverable (directly or indirectly) via device tree.
>
> I think it would be informative to provide pointers here to commonly used
> paravirtualized devices, especially VirtIO PCI/MMIO.
Under what criteria would something be eligible/appropriate to be
listed? I was trying to avoid "advocating" any particular type of PV
devices. We already have something of a problem with people incorrectly
assuming that mach-virt == virtio, which is not the case.
If we did want to include an explicit list here at a minimum I would
also want to include the Xen PV devices as well and surely there would
be others which ought to be included too.
Ian.
^ permalink raw reply
* [PATCH 7/7] ARM: mvebu: enable audio options in mvebu_defconfig
From: Thomas Petazzoni @ 2014-01-30 17:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391102051-5319-1-git-send-email-thomas.petazzoni@free-electrons.com>
Since at least the Armada 370 SoC has audio support, it makes sense to
enable the corresponding kernel configuration options in
mvebu_defconfig.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
arch/arm/configs/mvebu_defconfig | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig
index 594d706..e481f01 100644
--- a/arch/arm/configs/mvebu_defconfig
+++ b/arch/arm/configs/mvebu_defconfig
@@ -60,6 +60,11 @@ CONFIG_GPIOLIB=y
CONFIG_GPIO_SYSFS=y
CONFIG_THERMAL=y
CONFIG_ARMADA_THERMAL=y
+CONFIG_SOUND=y
+CONFIG_SND=y
+CONFIG_SND_SOC=y
+CONFIG_SND_KIRKWOOD_SOC=y
+CONFIG_SND_KIRKWOOD_SOC_ARMADA370_DB=y
CONFIG_USB_SUPPORT=y
CONFIG_USB=y
CONFIG_USB_EHCI_HCD=y
--
1.8.3.2
^ permalink raw reply related
* [PATCH 6/7] ARM: mvebu: add audio support to Armada 370 DB
From: Thomas Petazzoni @ 2014-01-30 17:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391102051-5319-1-git-send-email-thomas.petazzoni@free-electrons.com>
This commit adds the necessary Device Tree informations to enable
audio support on the Armada 370 DB platform. In details it:
* Instantiates the CS42L51 audio codec on the I2C0 bus, and
configures this bus with the appropriate pin-muxing configuration.
* Enables the I2S audio controller, and configures it with the
appropriate pin-muxing configuration.
* Through hog pins, ensures that the other pins possibly used for I2S
are muxed with another function than I2S.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
arch/arm/boot/dts/armada-370-db.dts | 46 +++++++++++++++++++++++++++++++++++++
1 file changed, 46 insertions(+)
diff --git a/arch/arm/boot/dts/armada-370-db.dts b/arch/arm/boot/dts/armada-370-db.dts
index 08a56bc..bc305d7 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -64,6 +64,22 @@
phy-mode = "rgmii-id";
};
+ i2c at 11000 {
+ pinctrl-0 = <&i2c0_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ audio-codec at 4a {
+ compatible = "cirrus,cs42l51";
+ reg = <0x4a>;
+ };
+ };
+
+ audio-controller at 30000 {
+ pinctrl-0 = <&i2s_pins2>;
+ pinctrl-names = "default";
+ status = "okay";
+ };
+
mvsdio at d4000 {
pinctrl-0 = <&sdio_pins1>;
pinctrl-names = "default";
@@ -80,6 +96,30 @@
broken-cd;
};
+ pinctrl {
+ /*
+ * These pins might be muxed as I2S by
+ * the bootloader, but it conflicts
+ * with the real I2S pins that are
+ * muxed using i2s_pins. We must mux
+ * those pins to a function other than
+ * I2S.
+ */
+ pinctrl-0 = <&hog_pins1 &hog_pins2>;
+ pinctrl-names = "default";
+
+ hog_pins1: hog-pins1 {
+ marvell,pins = "mpp6", "mpp8", "mpp10",
+ "mpp12", "mpp13";
+ marvell,function = "gpio";
+ };
+
+ hog_pins2: hog-pins2 {
+ marvell,pins = "mpp5", "mpp7", "mpp9";
+ marvell,function = "gpo";
+ };
+ };
+
usb at 50000 {
status = "okay";
};
@@ -112,10 +152,16 @@
/* Port 0, Lane 0 */
status = "okay";
};
+
pcie at 2,0 {
/* Port 1, Lane 0 */
status = "okay";
};
};
};
+
+ sound {
+ compatible = "marvell,a370db-audio";
+ status = "okay";
+ };
};
--
1.8.3.2
^ permalink raw reply related
* [PATCH 5/7] ARM: mvebu: add I2C0 muxing option for Armada 370 SoC
From: Thomas Petazzoni @ 2014-01-30 17:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391102051-5319-1-git-send-email-thomas.petazzoni@free-electrons.com>
This commit adds a pin-muxing configuration for the I2C0 bus of the
Armada 370, which is used on the Armada 370 DB platform to interface
with the CS42L51 audio codec.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
arch/arm/boot/dts/armada-370.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index d3bb66a..ef3cc22 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -129,6 +129,11 @@
marvell,function = "sd0";
};
+ i2c0_pins: i2c0-pins {
+ marvell,pins = "mpp2", "mpp3";
+ marvell,function = "i2c0";
+ };
+
i2s_pins1: i2s-pins1 {
marvell,pins = "mpp5", "mpp6", "mpp7",
"mpp8", "mpp9", "mpp10",
--
1.8.3.2
^ permalink raw reply related
* [PATCH 4/7] ARM: mvebu: add audio I2S controller to Armada 370 Device Tree
From: Thomas Petazzoni @ 2014-01-30 17:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391102051-5319-1-git-send-email-thomas.petazzoni@free-electrons.com>
The Armada 370 SoC has an I2S audio controller. This commit adds the
description of this controller to the Device Tree describing this SoC,
as well as two possible muxing configurations for the I2S bus pins.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
arch/arm/boot/dts/armada-370.dtsi | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index 7a4b82e..d3bb66a 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -128,6 +128,20 @@
"mpp51", "mpp52", "mpp53";
marvell,function = "sd0";
};
+
+ i2s_pins1: i2s-pins1 {
+ marvell,pins = "mpp5", "mpp6", "mpp7",
+ "mpp8", "mpp9", "mpp10",
+ "mpp12", "mpp13";
+ marvell,function = "audio";
+ };
+
+ i2s_pins2: i2s-pins2 {
+ marvell,pins = "mpp49", "mpp47", "mpp50",
+ "mpp59", "mpp57", "mpp61",
+ "mpp62", "mpp60", "mpp58";
+ marvell,function = "audio";
+ };
};
gpio0: gpio at 18100 {
@@ -241,6 +255,16 @@
0x18304 0x4>;
status = "okay";
};
+
+ audio-controller at 30000 {
+ compatible = "marvell,armada370-audio";
+ reg = <0x30000 0x4000>;
+ interrupts = <93>;
+ clocks = <&gateclk 0>;
+ clock-names = "internal";
+ status = "disabled";
+ };
+
};
};
};
--
1.8.3.2
^ permalink raw reply related
* [PATCH 3/7] sound: soc: add ASoC board driver for Armada 370 DB
From: Thomas Petazzoni @ 2014-01-30 17:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391102051-5319-1-git-send-email-thomas.petazzoni@free-electrons.com>
This commit adds a simple ASoC board driver fo the Armada 370
Development Board, which connects the audio unit of the Armada 370 SoC
to the I2C-based CS42L51.
For now, only the analog audio input and output through the CS42L51
are supported, but in the near future, digital audio input and output
support will be added through SPDIF.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
sound/soc/kirkwood/Kconfig | 8 +++
sound/soc/kirkwood/Makefile | 2 +
sound/soc/kirkwood/armada-370-db.c | 144 +++++++++++++++++++++++++++++++++++++
3 files changed, 154 insertions(+)
create mode 100644 sound/soc/kirkwood/armada-370-db.c
diff --git a/sound/soc/kirkwood/Kconfig b/sound/soc/kirkwood/Kconfig
index 764a0ef..2dc3ecf 100644
--- a/sound/soc/kirkwood/Kconfig
+++ b/sound/soc/kirkwood/Kconfig
@@ -6,6 +6,14 @@ config SND_KIRKWOOD_SOC
the Kirkwood I2S interface. You will also need to select the
audio interfaces to support below.
+config SND_KIRKWOOD_SOC_ARMADA370_DB
+ tristate "SoC Audio support for Armada 370 DB"
+ depends on SND_KIRKWOOD_SOC && (ARCH_MVEBU || COMPILE_TEST) && I2C
+ select SND_SOC_CS42L51
+ help
+ Say Y if you want to add support for SoC audio on
+ the Armada 370 Development Board.
+
config SND_KIRKWOOD_SOC_OPENRD
tristate "SoC Audio support for Kirkwood Openrd Client"
depends on SND_KIRKWOOD_SOC && (MACH_OPENRD_CLIENT || MACH_OPENRD_ULTIMATE || COMPILE_TEST)
diff --git a/sound/soc/kirkwood/Makefile b/sound/soc/kirkwood/Makefile
index 9e78138..7c1d8fe 100644
--- a/sound/soc/kirkwood/Makefile
+++ b/sound/soc/kirkwood/Makefile
@@ -4,6 +4,8 @@ obj-$(CONFIG_SND_KIRKWOOD_SOC) += snd-soc-kirkwood.o
snd-soc-openrd-objs := kirkwood-openrd.o
snd-soc-t5325-objs := kirkwood-t5325.o
+snd-soc-armada-370-db-objs := armada-370-db.o
+obj-$(CONFIG_SND_KIRKWOOD_SOC_ARMADA370_DB) += snd-soc-armada-370-db.o
obj-$(CONFIG_SND_KIRKWOOD_SOC_OPENRD) += snd-soc-openrd.o
obj-$(CONFIG_SND_KIRKWOOD_SOC_T5325) += snd-soc-t5325.o
diff --git a/sound/soc/kirkwood/armada-370-db.c b/sound/soc/kirkwood/armada-370-db.c
new file mode 100644
index 0000000..d5d8388
--- /dev/null
+++ b/sound/soc/kirkwood/armada-370-db.c
@@ -0,0 +1,144 @@
+/*
+ * Copyright (C) 2014 Marvell
+ *
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ */
+
+#include <linux/module.h>
+#include <linux/moduleparam.h>
+#include <linux/interrupt.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <sound/soc.h>
+#include <linux/of.h>
+#include <linux/platform_data/asoc-kirkwood.h>
+#include "../codecs/cs42l51.h"
+
+static int a370db_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params)
+{
+ struct snd_soc_pcm_runtime *rtd = substream->private_data;
+ struct snd_soc_dai *codec_dai = rtd->codec_dai;
+ struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
+ int ret;
+ unsigned int freq, fmt;
+
+ fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_CBS_CFS;
+ ret = snd_soc_dai_set_fmt(cpu_dai, fmt);
+ if (ret < 0)
+ return ret;
+
+ ret = snd_soc_dai_set_fmt(codec_dai, fmt);
+ if (ret < 0)
+ return ret;
+
+ switch (params_rate(params)) {
+ default:
+ case 44100:
+ freq = 11289600;
+ break;
+ case 48000:
+ freq = 12288000;
+ break;
+ case 96000:
+ freq = 24576000;
+ break;
+ }
+
+ return snd_soc_dai_set_sysclk(codec_dai, 0, freq, SND_SOC_CLOCK_IN);
+}
+
+static struct snd_soc_ops a370db_ops = {
+ .hw_params = a370db_hw_params,
+};
+
+static const struct snd_soc_dapm_widget a370db_dapm_widgets[] = {
+ SND_SOC_DAPM_HP("Out Jack", NULL),
+ SND_SOC_DAPM_LINE("In Jack", NULL),
+};
+
+static const struct snd_soc_dapm_route a370db_route[] = {
+ { "Out Jack", NULL, "HPL" },
+ { "Out Jack", NULL, "HPR" },
+ { "AIN1L", NULL, "In Jack" },
+ { "AIN1L", NULL, "In Jack" },
+};
+
+static int a370db_dai_init(struct snd_soc_pcm_runtime *rtd)
+{
+ struct snd_soc_codec *codec = rtd->codec;
+ struct snd_soc_dapm_context *dapm = &codec->dapm;
+
+ snd_soc_dapm_enable_pin(dapm, "Out Jack");
+ snd_soc_dapm_enable_pin(dapm, "In Jack");
+
+ return 0;
+}
+
+static struct snd_soc_dai_link a370db_dai[] = {
+{
+ .name = "CS42L51",
+ .stream_name = "CS42L51 HiFi",
+ .cpu_dai_name = "i2s",
+ .platform_name = "d0030000.audio-controller",
+ .codec_dai_name = "cs42l51-hifi",
+ .codec_name = "cs42l51-codec.0-004a",
+ .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_CBS_CFS,
+ .ops = &a370db_ops,
+ .init = a370db_dai_init,
+},
+};
+
+static struct snd_soc_card a370db = {
+ .name = "a370db",
+ .owner = THIS_MODULE,
+ .dai_link = a370db_dai,
+ .num_links = ARRAY_SIZE(a370db_dai),
+ .dapm_widgets = a370db_dapm_widgets,
+ .num_dapm_widgets = ARRAY_SIZE(a370db_dapm_widgets),
+ .dapm_routes = a370db_route,
+ .num_dapm_routes = ARRAY_SIZE(a370db_route),
+};
+
+static int a370db_probe(struct platform_device *pdev)
+{
+ struct snd_soc_card *card = &a370db;
+ int ret;
+
+ card->dev = &pdev->dev;
+
+ return snd_soc_register_card(card);
+}
+
+static int a370db_remove(struct platform_device *pdev)
+{
+ struct snd_soc_card *card = platform_get_drvdata(pdev);
+ return snd_soc_unregister_card(card);
+}
+
+static const struct of_device_id a370db_dt_ids[] = {
+ { .compatible = "marvell,a370db-audio" },
+ { },
+};
+
+static struct platform_driver a370db_driver = {
+ .driver = {
+ .name = "a370db-audio",
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(a370db_dt_ids),
+ },
+ .probe = a370db_probe,
+ .remove = a370db_remove,
+};
+
+module_platform_driver(a370db_driver);
+
+MODULE_AUTHOR("Thomas Petazzoni <thomas.petazzoni@free-electrons.com>");
+MODULE_DESCRIPTION("ALSA SoC a370db audio client");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:a370db-audio");
--
1.8.3.2
^ permalink raw reply related
* [PATCH 2/7] sound: soc: enable Kirkwood driver for mvebu platforms
From: Thomas Petazzoni @ 2014-01-30 17:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391102051-5319-1-git-send-email-thomas.petazzoni@free-electrons.com>
The audio unit found in the Armada 370 SoC is similar to the one used
in the Marvell Kirkwood and Marvell Dove SoCs. Therefore, this commit
allows the Kirkwood audio driver to be built on mvebu platforms, and
adds an additional compatible string to identify the Armada 370
variant of the audio unit.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
Documentation/devicetree/bindings/sound/mvebu-audio.txt | 1 +
sound/soc/kirkwood/Kconfig | 2 +-
sound/soc/kirkwood/kirkwood-i2s.c | 1 +
3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/sound/mvebu-audio.txt b/Documentation/devicetree/bindings/sound/mvebu-audio.txt
index f0062c5..cb8c07c 100644
--- a/Documentation/devicetree/bindings/sound/mvebu-audio.txt
+++ b/Documentation/devicetree/bindings/sound/mvebu-audio.txt
@@ -5,6 +5,7 @@ Required properties:
- compatible:
"marvell,kirkwood-audio" for Kirkwood platforms
"marvell,dove-audio" for Dove platforms
+ "marvell,armada370-audio" for Armada 370 platforms
- reg: physical base address of the controller and length of memory mapped
region.
diff --git a/sound/soc/kirkwood/Kconfig b/sound/soc/kirkwood/Kconfig
index 78ed4a4..764a0ef 100644
--- a/sound/soc/kirkwood/Kconfig
+++ b/sound/soc/kirkwood/Kconfig
@@ -1,6 +1,6 @@
config SND_KIRKWOOD_SOC
tristate "SoC Audio for the Marvell Kirkwood and Dove chips"
- depends on ARCH_KIRKWOOD || ARCH_DOVE || COMPILE_TEST
+ depends on ARCH_KIRKWOOD || ARCH_DOVE || ARCH_MVEBU || COMPILE_TEST
help
Say Y or M if you want to add support for codecs attached to
the Kirkwood I2S interface. You will also need to select the
diff --git a/sound/soc/kirkwood/kirkwood-i2s.c b/sound/soc/kirkwood/kirkwood-i2s.c
index 3920a5e..9f84222 100644
--- a/sound/soc/kirkwood/kirkwood-i2s.c
+++ b/sound/soc/kirkwood/kirkwood-i2s.c
@@ -633,6 +633,7 @@ static int kirkwood_i2s_dev_remove(struct platform_device *pdev)
static struct of_device_id mvebu_audio_of_match[] = {
{ .compatible = "marvell,kirkwood-audio" },
{ .compatible = "marvell,dove-audio" },
+ { .compatible = "marvell,armada370-audio" },
{ }
};
MODULE_DEVICE_TABLE(of, mvebu_audio_of_match);
--
1.8.3.2
^ permalink raw reply related
* [PATCH 1/7] sound: codec: add Device Tree binding to cs42l51
From: Thomas Petazzoni @ 2014-01-30 17:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391102051-5319-1-git-send-email-thomas.petazzoni@free-electrons.com>
This commit adds a trivial Device Tree binding to the I2C-based
cs42l51 sound codec, so that it can be used from Device Tree based
platforms.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
Documentation/devicetree/bindings/i2c/trivial-devices.txt | 1 +
sound/soc/codecs/cs42l51.c | 7 +++++++
2 files changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
index b1cb341..041e560 100644
--- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
@@ -17,6 +17,7 @@ at,24c08 i2c serial eeprom (24cxx)
atmel,24c02 i2c serial eeprom (24cxx)
atmel,at97sc3204t i2c trusted platform module (TPM)
catalyst,24c32 i2c serial eeprom
+cirrus,cs42l51 Cirrus Logic CS42L51 audio codec
dallas,ds1307 64 x 8, Serial, I2C Real-Time Clock
dallas,ds1338 I2C RTC with 56-Byte NV RAM
dallas,ds1339 I2C Serial Real-Time Clock
diff --git a/sound/soc/codecs/cs42l51.c b/sound/soc/codecs/cs42l51.c
index 1e0fa3b..4a7a733 100644
--- a/sound/soc/codecs/cs42l51.c
+++ b/sound/soc/codecs/cs42l51.c
@@ -604,10 +604,17 @@ static const struct i2c_device_id cs42l51_id[] = {
};
MODULE_DEVICE_TABLE(i2c, cs42l51_id);
+static const struct of_device_id cs42l51_of_match[] = {
+ { .compatible = "cirrus,cs42l51", },
+ { }
+};
+MODULE_DEVICE_TABLE(of, cs42l51_of_match);
+
static struct i2c_driver cs42l51_i2c_driver = {
.driver = {
.name = "cs42l51-codec",
.owner = THIS_MODULE,
+ .of_match_table = cs42l51_of_match,
},
.id_table = cs42l51_id,
.probe = cs42l51_i2c_probe,
--
1.8.3.2
^ permalink raw reply related
* [PATCH 0/7] Audio support for Armada 370 DB
From: Thomas Petazzoni @ 2014-01-30 17:14 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
This series of patches enable audio support on the Marvell Armada 370
Development Board. Since both the I2S controller on the SoC side and
the I2C audio codec are already supported by the kernel, the amount of
work is fairly limited.
Also, since the DT bindings that allows to replace the ASoC board
driver are still being ironed out, I'm proposing to add an old-style
ASoC board driver for now.
This set of patches only provide support for the analog output and
input, I am waiting for the optical cable to arrive to get the digital
input and output to work.
Patches 1 to 3 are to be taken by the ASoC maintainer, while patches 4
to 7 are to be taken by the mvebu maintainers.
Note that the audio support for Armada 370 also needs a fix to the
CS42L51, which is being discussed with the author of the change that
apparently introduced the problem (see discussion at
http://mailman.alsa-project.org/pipermail/alsa-devel/2014-January/071916.html).
Thanks,
Thomas
Thomas Petazzoni (7):
sound: codec: add Device Tree binding to cs42l51
sound: soc: enable Kirkwood driver for mvebu platforms
sound: soc: add ASoC board driver for Armada 370 DB
ARM: mvebu: add audio I2S controller to Armada 370 Device Tree
ARM: mvebu: add I2C0 muxing option for Armada 370 SoC
ARM: mvebu: add audio support to Armada 370 DB
ARM: mvebu: enable audio options in mvebu_defconfig
.../devicetree/bindings/i2c/trivial-devices.txt | 1 +
.../devicetree/bindings/sound/mvebu-audio.txt | 1 +
arch/arm/boot/dts/armada-370-db.dts | 46 +++++++
arch/arm/boot/dts/armada-370.dtsi | 29 +++++
arch/arm/configs/mvebu_defconfig | 5 +
sound/soc/codecs/cs42l51.c | 7 +
sound/soc/kirkwood/Kconfig | 10 +-
sound/soc/kirkwood/Makefile | 2 +
sound/soc/kirkwood/armada-370-db.c | 144 +++++++++++++++++++++
sound/soc/kirkwood/kirkwood-i2s.c | 1 +
10 files changed, 245 insertions(+), 1 deletion(-)
create mode 100644 sound/soc/kirkwood/armada-370-db.c
--
1.8.3.2
^ permalink raw reply
* [PATCH] arm: document "mach-virt" platform.
From: Marc Zyngier @ 2014-01-30 17:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391098262-15944-1-git-send-email-ian.campbell@citrix.com>
Hi Ian,
On 30/01/14 16:11, Ian Campbell wrote:
> mach-virt has existed for a while but it is not written down what it actually
> consists of. Although it seems a bit unusual to document a binding for an
> entire platform since mach-virt is entirely virtual it is helpful to have
> something to refer to in the absence of a single concrete implementation.
>
> I've done my best to capture the requirements based on the git log and my
> memory/understanding.
>
> While here remove the xenvm dts example, the Xen tools will now build a
> suitable mach-virt compatible dts when launching the guest.
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Kumar Gala <galak@codeaurora.org>
> Cc: Olof Johansson <olof@lixom.net>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: devicetree at vger.kernel.org
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> ---
> I'm not sure which tree this sort of thing should go though, sorry for the
> huge Cc.
> ---
> .../devicetree/bindings/arm/mach-virt.txt | 32 ++++++++
> arch/arm/boot/dts/xenvm-4.2.dts | 81 --------------------
> 2 files changed, 32 insertions(+), 81 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arm/mach-virt.txt
> delete mode 100644 arch/arm/boot/dts/xenvm-4.2.dts
>
> diff --git a/Documentation/devicetree/bindings/arm/mach-virt.txt b/Documentation/devicetree/bindings/arm/mach-virt.txt
> new file mode 100644
> index 0000000..562bcda
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/mach-virt.txt
> @@ -0,0 +1,32 @@
> +* Mach-virt "Dummy Virtual Machine" platform
> +
> +"mach-virt" is the smallest, dumbest platform possible, to be used as
> +a guest for Xen, KVM and other hypervisors. It has no
> +properties/functionality of its own and is driven entirely by device
> +tree.
> +
> +This document defines the requirements for such a platform.
> +
> +* Required properties:
> +
> +- compatible: should be one of:
> + "linux,dummy-virt"
> + "xen,xenvm"
> +
> +In addition to the standard nodes (chosen, cpus, memory etc) the
> +platform is required to provide certain other basic functionality
> +which must be described in the device tree:
> +
> + The platform must provide an ARM Generic Interrupt Controller
> + (GIC), defined in Documentation/devicetree/bindings/arm/gic.txt.
> +
> + The platform must provide ARM architected timer, defined in
> + Documentation/devicetree/bindings/arm/arch_timer.txt.
> +
> + If the platform is SMP then it must provide the Power State
> + Coordination Interface (PSCI) described in
> + Documentation/devicetree/bindings/arm/psci.txt.
I'm afraid I disagree with most of the above. The whole point of
mach-virt is to provide a shell for DT platforms. None of this hardware
is mandated. Instead, all the necessary information should be described
in DT.
Actually, mach-virt doesn't really stand for Virtual Machine. It stands
for virtual mach-* directory! Eventually, mach-virt should become the
default platform, the one we use when we don't match anything else in
the kernel
What you've described here are requirements for a hypervisor like Xen or
KVM. mach-virt itself shouldn't have any of that.
Cheers,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] arm: document "mach-virt" platform.
From: Stefano Stabellini @ 2014-01-30 17:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52EA83D6.9050506@codeaurora.org>
On Thu, 30 Jan 2014, Christopher Covington wrote:
> Hi Ian,
>
> On 01/30/2014 11:11 AM, Ian Campbell wrote:
> > mach-virt has existed for a while but it is not written down what it actually
> > consists of. Although it seems a bit unusual to document a binding for an
> > entire platform since mach-virt is entirely virtual it is helpful to have
> > something to refer to in the absence of a single concrete implementation.
> >
> > I've done my best to capture the requirements based on the git log and my
> > memory/understanding.
> >
> > While here remove the xenvm dts example, the Xen tools will now build a
> > suitable mach-virt compatible dts when launching the guest.
>
> [...]
>
> > +++ b/Documentation/devicetree/bindings/arm/mach-virt.txt
> > @@ -0,0 +1,32 @@
> > +* Mach-virt "Dummy Virtual Machine" platform
> > +
> > +"mach-virt" is the smallest, dumbest platform possible, to be used as
> > +a guest for Xen, KVM and other hypervisors.
>
> The platform is also useful to, and used by, simulators like QEMU in TCG mode.
>
> > It has no
> > +properties/functionality of its own and is driven entirely by device
> > +tree.
>
> I find this wording confusing. I read it as saying the platform has no
> properties or functionality. Perhaps you could phrase it slightly differently,
> such as having no properties or functionality beyond what's described in the
> device tree.
Right, something like making no assumptions on the presence of devices
or hardware interfaces beyond what is described on device tree.
> > +This document defines the requirements for such a platform.
> > +
> > +* Required properties:
> > +
> > +- compatible: should be one of:
> > + "linux,dummy-virt"
> > + "xen,xenvm"
> > +
> > +In addition to the standard nodes (chosen, cpus, memory etc) the
> > +platform is required to provide certain other basic functionality
> > +which must be described in the device tree:
> > +
> > + The platform must provide an ARM Generic Interrupt Controller
> > + (GIC), defined in Documentation/devicetree/bindings/arm/gic.txt.
> > +
> > + The platform must provide ARM architected timer, defined in
> > + Documentation/devicetree/bindings/arm/arch_timer.txt.
> > +
> > + If the platform is SMP then it must provide the Power State
> > + Coordination Interface (PSCI) described in
> > + Documentation/devicetree/bindings/arm/psci.txt.
> > +
> > +The platform may also provide hypervisor specific functionality
> > +(e.g. PV I/O), if it does so then this functionality must be
> > +discoverable (directly or indirectly) via device tree.
>
> I think it would be informative to provide pointers here to commonly used
> paravirtualized devices, especially VirtIO PCI/MMIO.
In that case I would appreciate a link to the Xen hypervisor node:
Documentation/devicetree/bindings/arm/xen.txt
^ permalink raw reply
* [PATCH] ARM: keystone: dts: disable "msmcsram" clock
From: Ivan Khoronzhuk @ 2014-01-30 17:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52EA6228.8030008@ti.com>
Thanks, I will send v2
On 01/30/2014 04:31 PM, Santosh Shilimkar wrote:
> On Thursday 30 January 2014 08:58 AM, Ivan Khoronzhuk wrote:
>> Ok. I will delete node for this clock from DT and send v1
>>
> Sorry for the html reply first of all. That node should never have
> been actually added since the clock is not suppose to be touched even
> in low power states. Change log should say something like this ...
>
> "MSMC is the coherency interconnect and all the coherent masters are
> connected to it including devices which are not under Linux OS control.
> MSMC clock should not be toched even in low power states."
>
> So drop the clock node o.w without 'clk_ignore_unused' will disable
> the clock leading to system stall.
>
> I wil try get these in rc's since its a bug fix
>
> Regards,
> Santosh
>
>
>
^ permalink raw reply
* [PATCH] clk: keystone: gate: fix clk_init_data initialization
From: Ivan Khoronzhuk @ 2014-01-30 16:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52EA627E.8060801@ti.com>
Ok
On 01/30/2014 04:32 PM, Santosh Shilimkar wrote:
> On Thursday 30 January 2014 08:49 AM, Ivan Khoronzhuk wrote:
>> Yes. As result the clk->flag field contains garbage. In my case it leads
>> that flag CLK_IGNORE_UNUSED is set for most of clocks. As result a bunch
>> of unused clocks cannot be disabled.
>>
> Can you please update the change log with above information.
>
>> On 01/30/2014 03:26 PM, Shilimkar, Santosh wrote:
>>> Can u capture the issue withiout this fix?
>>>
>>> Sent from my Android phone using TouchDown (www.nitrodesk.com)
>>>
>>> -----Original Message-----
>>> *From:* Khoronzhuk, Ivan [ivan.khoronzhuk at ti.com]
>>> *Received:* Thursday, 30 Jan 2014, 6:37am
>>> *To:* Shilimkar, Santosh [santosh.shilimkar at ti.com]
>>> *CC:* mturquette at linaro.org [mturquette at linaro.org];
>>> linux-arm-kernel at lists.infradead.org [linux-arm-kernel at lists.infradead.org];
>>> linux-kernel at vger.kernel.org [linux-kernel at vger.kernel.org]; Khoronzhuk, Ivan
>>> [ivan.khoronzhuk at ti.com]
>>> *Subject:* [PATCH] clk: keystone: gate: fix clk_init_data initialization
>>>
>>> In clk_register_psc() function clk_init_data struct is allocated
>>> in the stack. All members of this struct should be initialized
>>> before using otherwise it will contain garbage. So initialize flags
>>> in this structure too.
>>>
>>> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
>>> ---
>>> drivers/clk/keystone/gate.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/clk/keystone/gate.c b/drivers/clk/keystone/gate.c
>>> index 17a5983..86f1e36 100644
>>> --- a/drivers/clk/keystone/gate.c
>>> +++ b/drivers/clk/keystone/gate.c
>>> @@ -179,6 +179,7 @@ static struct clk *clk_register_psc(struct device *dev,
>>>
>>> init.name = name;
>>> init.ops = &clk_psc_ops;
>>> + init.flags = 0;
>>> init.parent_names = (parent_name ? &parent_name : NULL);
>>> init.num_parents = (parent_name ? 1 : 0);
>>>
>>> --
>>> 1.8.3.2
>>>
^ permalink raw reply
* [PATCH] arm: document "mach-virt" platform.
From: Christopher Covington @ 2014-01-30 16:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391098262-15944-1-git-send-email-ian.campbell@citrix.com>
Hi Ian,
On 01/30/2014 11:11 AM, Ian Campbell wrote:
> mach-virt has existed for a while but it is not written down what it actually
> consists of. Although it seems a bit unusual to document a binding for an
> entire platform since mach-virt is entirely virtual it is helpful to have
> something to refer to in the absence of a single concrete implementation.
>
> I've done my best to capture the requirements based on the git log and my
> memory/understanding.
>
> While here remove the xenvm dts example, the Xen tools will now build a
> suitable mach-virt compatible dts when launching the guest.
[...]
> +++ b/Documentation/devicetree/bindings/arm/mach-virt.txt
> @@ -0,0 +1,32 @@
> +* Mach-virt "Dummy Virtual Machine" platform
> +
> +"mach-virt" is the smallest, dumbest platform possible, to be used as
> +a guest for Xen, KVM and other hypervisors.
The platform is also useful to, and used by, simulators like QEMU in TCG mode.
> It has no
> +properties/functionality of its own and is driven entirely by device
> +tree.
I find this wording confusing. I read it as saying the platform has no
properties or functionality. Perhaps you could phrase it slightly differently,
such as having no properties or functionality beyond what's described in the
device tree.
> +This document defines the requirements for such a platform.
> +
> +* Required properties:
> +
> +- compatible: should be one of:
> + "linux,dummy-virt"
> + "xen,xenvm"
> +
> +In addition to the standard nodes (chosen, cpus, memory etc) the
> +platform is required to provide certain other basic functionality
> +which must be described in the device tree:
> +
> + The platform must provide an ARM Generic Interrupt Controller
> + (GIC), defined in Documentation/devicetree/bindings/arm/gic.txt.
> +
> + The platform must provide ARM architected timer, defined in
> + Documentation/devicetree/bindings/arm/arch_timer.txt.
> +
> + If the platform is SMP then it must provide the Power State
> + Coordination Interface (PSCI) described in
> + Documentation/devicetree/bindings/arm/psci.txt.
> +
> +The platform may also provide hypervisor specific functionality
> +(e.g. PV I/O), if it does so then this functionality must be
> +discoverable (directly or indirectly) via device tree.
I think it would be informative to provide pointers here to commonly used
paravirtualized devices, especially VirtIO PCI/MMIO.
Thanks,
Christopher
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.
^ permalink raw reply
* [PATCH v2 6/6] cpu/idle.c: move to sched/idle.c
From: Peter Zijlstra @ 2014-01-30 16:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391100076.2422.56.camel@joe-AO722>
On Thu, Jan 30, 2014 at 08:41:16AM -0800, Joe Perches wrote:
> Perhaps you could use a newer version of patch
>
> GNU patch version 2.7 released
Yeah, I know about that, I'll wait until its common in all distros,
updating all machines I use by hand is just painful.
^ permalink raw reply
* [PATCH v2 6/6] cpu/idle.c: move to sched/idle.c
From: Joe Perches @ 2014-01-30 16:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140130162753.GF5002@laptop.programming.kicks-ass.net>
On Thu, 2014-01-30 at 17:27 +0100, Peter Zijlstra wrote:
> On Thu, Jan 30, 2014 at 11:03:31AM -0500, Nicolas Pitre wrote:
> > > This is not a valid patch for PATCH(1). Please try again.
> >
> > Don't you use git? ;-)
>
> Nah, git and me don't get along well.
Perhaps you could use a newer version of patch
http://savannah.gnu.org/forum/forum.php?forum_id=7361
GNU patch version 2.7 released
Item posted by Andreas Gruenbacher <agruen> on Wed 12 Sep 2012 02:18:14
PM UTC.
I am pleased to announce that version 2.7 of GNU patch has been
released. The following significant changes have happened since the last
stable release in December 2009:
* Support for most features of the "diff --git" format, including
renames and copies, permission changes, and symlink diffs.
Binary diffs are not supported yet; patch will complain and skip
them.
^ permalink raw reply
* [PATCH v2 6/6] cpu/idle.c: move to sched/idle.c
From: Peter Zijlstra @ 2014-01-30 16:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.11.1401301102210.1652@knanqh.ubzr>
On Thu, Jan 30, 2014 at 11:03:31AM -0500, Nicolas Pitre wrote:
> > This is not a valid patch for PATCH(1). Please try again.
>
> Don't you use git? ;-)
Nah, git and me don't get along well.
> Here's a plain patch:
Thanks!
^ permalink raw reply
* [PATCH] fix compilation of imx-hdmi
From: Fabio Estevam @ 2014-01-30 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140130161347.GD15937@n2100.arm.linux.org.uk>
On 01/30/2014 02:13 PM, Russell King - ARM Linux wrote:
> imx-hdmi creates a hdmi_colorimetry enum. This is also defined by
> include/linux/hdmi.h, which gets included now via DRM headers since
> 985e5dc207e133 (drm/edid: Populate picture aspect ratio for CEA modes).
> This leads to the compiler complaining:
>
> drivers/staging/imx-drm/imx-hdmi.c:58:6: error: nested redefinition of 'enum hdmi_colorimetry'
> drivers/staging/imx-drm/imx-hdmi.c:58:6: error: redeclaration of 'enum hdmi_colorimetry'
> include/linux/hdmi.h:48:6: note: originally defined here
>
> Fix it by using the one in linux/hdmi.h
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Sachin has also sent the same fix:
http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2014-January/045167.html
Regards,
Fabio Estevam
^ permalink raw reply
* [RFC] ARM Generic Timer + Interaction with WFI on Cortex-A15
From: Lorenzo Pieralisi @ 2014-01-30 16:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52947FFA.90504@gmail.com>
Hi Marc,
On Tue, Nov 26, 2013 at 11:03:22AM +0000, Marc C wrote:
> Hi Lorenzo,
>
> > So what's the problem then ? Just avoid adding CPUIDLE_FLAG_TIMER_STOP
> > to the C-state flags and you are all set, or I am missing something
> > here ?
>
> The C3STOP flag prevents the kernel from using the timer as a
> high-resolution clock source. There are some patches that remove the
> C3STOP flag [1] in order for the timer to function for use with hrtimer.
> I think something similar could be manageable as a DT property on the
> armv7-timer binding.
>
> > Yes I do object. Timer binding is global in the DT and do not want to
> > override the flag for all local timers when, as I mentioned, A15
> > behaviour is just an exception. If you really need that, please write
> > an idle driver that does not enter broadcast mode on C-state entry
> > (see above).
>
> So what you're saying is that you'll outright disapprove of any patch
> that would otherwise help ensure the kernel would run on any/all
> variations of armv7-timer? I would imagine that we'd want things to be
> more inclusive, and since there are quite a few SoCs with the timer that
> behave in this manner.
>
> I'm not trying to be a thorn in your side. I just want to make sure
> everyone that has an implementation similar to ours is covered, too.
I though about this and I think the only clean way to implement this
would be to add a power domain property to the arch timers. The problem
I am having is that this should not break existing platforms, so
basically we need to understand what the power-domain property would
mean on a system like yours with no power management. We might add
an always-on power domain and attach the arch timer to that, it seems
lots of churn for not much to me.
Adding a property like "state-retained" is not nice either because this
would solve the problem for arch timer but that does not represent a
generic solution.
Thoughts appreciated.
Thanks,
Lorenzo
^ permalink raw reply
* [PATCH] fix compilation of imx-hdmi
From: Russell King - ARM Linux @ 2014-01-30 16:13 UTC (permalink / raw)
To: linux-arm-kernel
imx-hdmi creates a hdmi_colorimetry enum. This is also defined by
include/linux/hdmi.h, which gets included now via DRM headers since
985e5dc207e133 (drm/edid: Populate picture aspect ratio for CEA modes).
This leads to the compiler complaining:
drivers/staging/imx-drm/imx-hdmi.c:58:6: error: nested redefinition of 'enum hdmi_colorimetry'
drivers/staging/imx-drm/imx-hdmi.c:58:6: error: redeclaration of 'enum hdmi_colorimetry'
include/linux/hdmi.h:48:6: note: originally defined here
Fix it by using the one in linux/hdmi.h
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
drivers/staging/imx-drm/imx-hdmi.c | 17 ++++++-----------
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/imx-drm/imx-hdmi.c b/drivers/staging/imx-drm/imx-hdmi.c
index d358d89e11c4..74d635fcb3d5 100644
--- a/drivers/staging/imx-drm/imx-hdmi.c
+++ b/drivers/staging/imx-drm/imx-hdmi.c
@@ -55,11 +55,6 @@ enum hdmi_datamap {
YCbCr422_12B = 0x12,
};
-enum hdmi_colorimetry {
- ITU601,
- ITU709,
-};
-
enum imx_hdmi_devtype {
IMX6Q_HDMI,
IMX6DL_HDMI,
@@ -475,12 +470,12 @@ static void imx_hdmi_update_csc_coeffs(struct imx_hdmi *hdmi)
if (is_color_space_conversion(hdmi)) {
if (hdmi->hdmi_data.enc_out_format == RGB) {
- if (hdmi->hdmi_data.colorimetry == ITU601)
+ if (hdmi->hdmi_data.colorimetry == HDMI_COLORIMETRY_ITU_601)
csc_coeff = &csc_coeff_rgb_out_eitu601;
else
csc_coeff = &csc_coeff_rgb_out_eitu709;
} else if (hdmi->hdmi_data.enc_in_format == RGB) {
- if (hdmi->hdmi_data.colorimetry == ITU601)
+ if (hdmi->hdmi_data.colorimetry == HDMI_COLORIMETRY_ITU_601)
csc_coeff = &csc_coeff_rgb_in_eitu601;
else
csc_coeff = &csc_coeff_rgb_in_eitu709;
@@ -1009,14 +1004,14 @@ static void hdmi_config_AVI(struct imx_hdmi *hdmi)
/* Set up colorimetry */
if (hdmi->hdmi_data.enc_out_format == XVYCC444) {
colorimetry = HDMI_FC_AVICONF1_COLORIMETRY_EXTENDED_INFO;
- if (hdmi->hdmi_data.colorimetry == ITU601)
+ if (hdmi->hdmi_data.colorimetry == HDMI_COLORIMETRY_ITU_601)
ext_colorimetry =
HDMI_FC_AVICONF2_EXT_COLORIMETRY_XVYCC601;
else /* hdmi->hdmi_data.colorimetry == ITU709 */
ext_colorimetry =
HDMI_FC_AVICONF2_EXT_COLORIMETRY_XVYCC709;
} else if (hdmi->hdmi_data.enc_out_format != RGB) {
- if (hdmi->hdmi_data.colorimetry == ITU601)
+ if (hdmi->hdmi_data.colorimetry == HDMI_COLORIMETRY_ITU_601)
colorimetry = HDMI_FC_AVICONF1_COLORIMETRY_SMPTE;
else /* hdmi->hdmi_data.colorimetry == ITU709 */
colorimetry = HDMI_FC_AVICONF1_COLORIMETRY_ITUR;
@@ -1247,9 +1242,9 @@ static int imx_hdmi_setup(struct imx_hdmi *hdmi, struct drm_display_mode *mode)
(hdmi->vic == 21) || (hdmi->vic == 22) ||
(hdmi->vic == 2) || (hdmi->vic == 3) ||
(hdmi->vic == 17) || (hdmi->vic == 18))
- hdmi->hdmi_data.colorimetry = ITU601;
+ hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_601;
else
- hdmi->hdmi_data.colorimetry = ITU709;
+ hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_709;
if ((hdmi->vic == 10) || (hdmi->vic == 11) ||
(hdmi->vic == 12) || (hdmi->vic == 13) ||
--
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 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