* [PATCH 4/4] ARM: dts: socfpga: Add second ethernet alias to VINING FPGA
From: Marek Vasut @ 2017-05-04 10:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170504102950.10667-1-marex@denx.de>
Add DT alias for the second ethernet present on mainboard rev 1.10.
Signed-off-by: Marek Vasut <marex@denx.de>
---
arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts b/arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts
index 9195f11dacdc..655fe87e272d 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts
@@ -69,6 +69,7 @@
* to be added to the gmac1 device tree blob.
*/
ethernet0 = &gmac1;
+ ethernet1 = &gmac0;
};
gpio-keys {
--
2.11.0
^ permalink raw reply related
* [PATCH 1/5] KVM: arm64: Allow creating the PMU without the in-kernel GIC
From: Christoffer Dall @ 2017-05-04 10:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b680335b-6407-f778-84c1-6565a46ae7d0@arm.com>
On Thu, May 04, 2017 at 11:16:57AM +0100, Marc Zyngier wrote:
> On 04/05/17 10:44, Christoffer Dall wrote:
> > On Thu, May 04, 2017 at 10:05:43AM +0100, Marc Zyngier wrote:
> >> On 04/05/17 09:38, Christoffer Dall wrote:
> >>> On Thu, May 04, 2017 at 09:28:50AM +0100, Marc Zyngier wrote:
> >>>> On 04/05/17 09:13, Christoffer Dall wrote:
> >>>>> On Thu, May 04, 2017 at 09:09:47AM +0100, Marc Zyngier wrote:
> >>>>>> On 03/05/17 19:32, Christoffer Dall wrote:
> >>>>>>> Since we got support for devices in userspace which allows reporting the
> >>>>>>> PMU overflow output status to userspace, we should actually allow
> >>>>>>> creating the PMU on systems without an in-kernel irqchip, which in turn
> >>>>>>> requires us to slightly clarify error codes for the ABI and move things
> >>>>>>> around for the initialization phase.
> >>>>>>>
> >>>>>>> Signed-off-by: Christoffer Dall <cdall@linaro.org>
> >>>>>>> ---
> >>>>>>> Documentation/virtual/kvm/devices/vcpu.txt | 16 +++++++++-------
> >>>>>>> virt/kvm/arm/pmu.c | 27 +++++++++++++++++----------
> >>>>>>> 2 files changed, 26 insertions(+), 17 deletions(-)
> >>>>>>>
> >>>>>>> diff --git a/Documentation/virtual/kvm/devices/vcpu.txt b/Documentation/virtual/kvm/devices/vcpu.txt
> >>>>>>> index 02f5068..352af6e 100644
> >>>>>>> --- a/Documentation/virtual/kvm/devices/vcpu.txt
> >>>>>>> +++ b/Documentation/virtual/kvm/devices/vcpu.txt
> >>>>>>> @@ -16,7 +16,9 @@ Parameters: in kvm_device_attr.addr the address for PMU overflow interrupt is a
> >>>>>>> Returns: -EBUSY: The PMU overflow interrupt is already set
> >>>>>>> -ENXIO: The overflow interrupt not set when attempting to get it
> >>>>>>> -ENODEV: PMUv3 not supported
> >>>>>>> - -EINVAL: Invalid PMU overflow interrupt number supplied
> >>>>>>> + -EINVAL: Invalid PMU overflow interrupt number supplied or
> >>>>>>> + trying to set the IRQ number without using an in-kernel
> >>>>>>> + irqchip.
> >>>>>>>
> >>>>>>> A value describing the PMUv3 (Performance Monitor Unit v3) overflow interrupt
> >>>>>>> number for this vcpu. This interrupt could be a PPI or SPI, but the interrupt
> >>>>>>> @@ -25,11 +27,11 @@ all vcpus, while as an SPI it must be a separate number per vcpu.
> >>>>>>>
> >>>>>>> 1.2 ATTRIBUTE: KVM_ARM_VCPU_PMU_V3_INIT
> >>>>>>> Parameters: no additional parameter in kvm_device_attr.addr
> >>>>>>> -Returns: -ENODEV: PMUv3 not supported
> >>>>>>> - -ENXIO: PMUv3 not properly configured as required prior to calling this
> >>>>>>> - attribute
> >>>>>>> +Returns: -ENODEV: PMUv3 not supported or GIC not initialized
> >>>>>>> + -ENXIO: PMUv3 not properly configured or in-kernel irqchip not
> >>>>>>> + conigured as required prior to calling this attribute
> >>>>>>> -EBUSY: PMUv3 already initialized
> >>>>>>>
> >>>>>>> -Request the initialization of the PMUv3. This must be done after creating the
> >>>>>>> -in-kernel irqchip. Creating a PMU with a userspace irqchip is currently not
> >>>>>>> -supported.
> >>>>>>> +Request the initialization of the PMUv3. If using the PMUv3 with an in-kernel
> >>>>>>> +virtual GIC implementation, this must be done after initializing the in-kernel
> >>>>>>> +irqchip.
> >>>>>>> diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
> >>>>>>> index 4b43e7f..f046b08 100644
> >>>>>>> --- a/virt/kvm/arm/pmu.c
> >>>>>>> +++ b/virt/kvm/arm/pmu.c
> >>>>>>> @@ -456,21 +456,25 @@ static int kvm_arm_pmu_v3_init(struct kvm_vcpu *vcpu)
> >>>>>>> if (!kvm_arm_support_pmu_v3())
> >>>>>>> return -ENODEV;
> >>>>>>>
> >>>>>>> - /*
> >>>>>>> - * We currently require an in-kernel VGIC to use the PMU emulation,
> >>>>>>> - * because we do not support forwarding PMU overflow interrupts to
> >>>>>>> - * userspace yet.
> >>>>>>> - */
> >>>>>>> - if (!irqchip_in_kernel(vcpu->kvm) || !vgic_initialized(vcpu->kvm))
> >>>>>>> - return -ENODEV;
> >>>>>>> -
> >>>>>>> - if (!test_bit(KVM_ARM_VCPU_PMU_V3, vcpu->arch.features) ||
> >>>>>>> - !kvm_arm_pmu_irq_initialized(vcpu))
> >>>>>>> + if (!test_bit(KVM_ARM_VCPU_PMU_V3, vcpu->arch.features))
> >>>>>>> return -ENXIO;
> >>>>>>>
> >>>>>>> if (kvm_arm_pmu_v3_ready(vcpu))
> >>>>>>> return -EBUSY;
> >>>>>>>
> >>>>>>> + if (irqchip_in_kernel(vcpu->kvm)) {
> >>>>>>> + /*
> >>>>>>> + * If using the PMU with an in-kernel virtual GIC
> >>>>>>> + * implementation, we require the GIC to be already
> >>>>>>> + * initialized when initializing the PMU.
> >>>>>>> + */
> >>>>>>> + if (!vgic_initialized(vcpu->kvm))
> >>>>>>> + return -ENODEV;
> >>>>>>> +
> >>>>>>> + if (!kvm_arm_pmu_irq_initialized(vcpu))
> >>>>>>> + return -ENXIO;
> >>>>>>> + }
> >>>>>>> +
> >>>>>>> kvm_pmu_vcpu_reset(vcpu);
> >>>>>>> vcpu->arch.pmu.ready = true;
> >>>>>>>
> >>>>>>> @@ -512,6 +516,9 @@ int kvm_arm_pmu_v3_set_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr)
> >>>>>>> int __user *uaddr = (int __user *)(long)attr->addr;
> >>>>>>> int irq;
> >>>>>>>
> >>>>>>> + if (!irqchip_in_kernel(vcpu->kvm))
> >>>>>>> + return -EINVAL;
> >>>>>>> +
> >>>>>>
> >>>>>> Shouldn't we fail the same way for {get,has}_attr? get_attr is going to
> >>>>>> generate a -ENXIO, and has_attr is going to lie about the availability
> >>>>>> of KVM_ARM_VCPU_PMU_V3_IRQ...
> >>>>>>
> >>>>>
> >>>>> Here's the text from api.txt:
> >>>>>
> >>>>> Tests whether a device supports a particular attribute. A successful
> >>>>> return indicates the attribute is implemented. It does not necessarily
> >>>>> indicate that the attribute can be read or written in the device's
> >>>>> current state. "addr" is ignored.
> >>>>>
> >>>>> My interpretation therefore is that QEMU can use this ioctl to figure
> >>>>> out if the feature is supported (sort of like a capability), but that
> >>>>> doesn't mean that the configuration of the VM is such that the attribute
> >>>>> can be get or set at that moment.
> >>>>>
> >>>>> For example, there will also alway be situations where you can get an
> >>>>> attr, but not set an attr, what should the has_attr return then?
> >>>>
> >>>> My issue here is that whether we can get/set the interrupt or not is not
> >>>> a function of the device itself, but of the way it is "wired". No matter
> >>>> what "the device's current state" is, we'll never be able to get/set the
> >>>> interrupt.
> >>>>
> >>>> I'd tend to err on the side of caution and return something that is
> >>>> unambiguous, be maybe I have too strict an interpretation of the API.
> >>>>
> >>>
> >>> Hmm, I see the has_attr as a method for userspace to discover "does this
> >>> kernel have this feature". If we make has_attr return a value depending
> >>> on the VM having an in-kernel gic or not, we implicitly require
> >>> userspace to create a VM with an in-kernel GIC to discover if this
> >>> kernel has that feature, and therefore also impose an ordering
> >>> requirement of figuring out the capabilities of the kernel (i.e. create
> >>> the GIC before checking this API).
> >>>
> >>> I think QEMU should be able to do:
> >>>
> >>> if (has_attr()) {
> >>> kvm_supports_set_timer_irq = true;
> >>> vtimer_irq = foo;
> >>> } else {
> >>> kvm_supports_set_timer_irq = false;
> >>> vtimer_irq = 27; /* default, we're stuck with it */
> >>> }
> >>>
> >>> create_board_definition();
> >>> create_dt();
> >>> create_acpi();
> >>>
> >>> /* do whatever */
> >>>
> >>> if (kvm_supports_set_timer_irq && kvm_irqchip_in_kernel()) {
> >>> kvm_arm_timer_set_irq(...);
> >>> }
> >>>
> >>> And all this should not be coupled to when we create the irqchip device.
> >>>
> >>> But I may be failing to see the case where the current implementation
> >>> creates a problem for userspace, in which case we should document the
> >>> ordering requirement.
> >>
> >> I'm not sure it would create any problem, at least not for the PMU
> >> (there is no working code that would have created a PMU without an irqchip).
> >>
> >> It is just that we have a slightly diverging interpretation of what
> >> has_attr means. You see it as "attribute that the device supports", and
> >> I see it as "attribute that the device supports in this configuration".
> >> I'm happy to use your semantics from now on.
> >
> > In either case, we should make sure this is clear in the ABI. I thought
> > that the "It does not necessarily indicate that the attribute can be
> > read or written in the device's current state." implied my
> > interpretation, but maybe I'm missing some subtlety there?
>
> Well, that's what I said above. The interrupt number is not a function
> of the device state, but one of the integration of that device in the
> system. The PMU itself is not concerned with an interrupt number, only
> the GIC is.
>
> > Do you think we should clarify the API?
>
> Not sure. I admit my interpretation is a bit borderline. If I was brave,
> I'd say that all the interrupt numbers should be a property of the GIC,
> and not of the device. But that ship has sailed a while ago, and I'm
> weak ;-).
>
> More seriously, I don't think this is likely to cause any issue.
>
ok, I'll leave it as is then.
> >
> > By the way, I now realize that we are not maintining the same
> > understanding between get/set_attr, which I really think we should, so
> > I'll add the following:
> >
> >
> > diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
> > index 9b3e3ea..0cf62b7 100644
> > --- a/virt/kvm/arm/pmu.c
> > +++ b/virt/kvm/arm/pmu.c
> > @@ -551,6 +551,9 @@ int kvm_arm_pmu_v3_get_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr)
> > int __user *uaddr = (int __user *)(long)attr->addr;
> > int irq;
> >
> > + if (!irqchip_in_kernel(vcpu->kvm))
> > + return -EINVAL;
> > +
> > if (!test_bit(KVM_ARM_VCPU_PMU_V3, vcpu->arch.features))
> > return -ENODEV;
> >
>
> Looks good to me.
>
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH 1/3] arm64: dts: ls1046a: support SD UHS-I and eMMC HS200 on RDB
From: Y.B. Lu @ 2017-05-04 10:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170503125659.GA24392@dragon>
Hi Shawn,
> -----Original Message-----
> From: Shawn Guo [mailto:shawnguo at kernel.org]
> Sent: Wednesday, May 03, 2017 8:57 PM
> To: Y.B. Lu
> Cc: linux-arm-kernel at lists.infradead.org; ulf.hansson at linaro.org; Catalin
> Marinas; Xiaobo Xie
> Subject: Re: [PATCH 1/3] arm64: dts: ls1046a: support SD UHS-I and eMMC
> HS200 on RDB
>
> On Fri, Apr 21, 2017 at 11:52:34AM +0800, Yangbo Lu wrote:
> > This patch is to enable SD UHS-I mode and eMMC HS200 mode on
> > LS1046ARDB in dts. Also, the eSDHC peripheral clock must be used
> > instead of platform clock to support these modes.
> >
> > Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
> > ---
> > arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts | 8 ++++++++
> > arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 4 ++--
> > 2 files changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
> > b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
> > index d1ccc00..08528c2 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
> > @@ -64,6 +64,14 @@
> > };
> > };
> >
> > +&esdhc {
> > + mmc-hs200-1_8v;
> > + sd-uhs-sdr104;
> > + sd-uhs-sdr50;
> > + sd-uhs-sdr25;
> > + sd-uhs-sdr12;
> > +};
> > +
>
> Please sort the node alphabetically.
[Lu Yangbo-B47093] Ok, I will do that.
>
> > &duart0 {
> > status = "okay";
> > };
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
> > b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
> > index f4b8b7e..f06f329 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
> > @@ -209,10 +209,10 @@
> > };
> >
> > esdhc: esdhc at 1560000 {
> > - compatible = "fsl,esdhc";
> > + compatible = "fsl,ls1046a-esdhc", "fsl,esdhc";
>
> I do not see "fsl,ls1046a-esdhc" is a documented compatible.
>
[Lu Yangbo-B47093] Ok, I will add a doc patch.
> Shawn
>
> > reg = <0x0 0x1560000 0x0 0x10000>;
> > interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
> > - clock-frequency = <0>;
> > + clocks = <&clockgen 2 1>;
> > voltage-ranges = <1800 1800 3300 3300>;
> > sdhci,auto-cmd12;
> > big-endian;
> > --
> > 2.1.0.27.g96db324
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 3/3] arm64: dts: ls1012a: add eSDHC nodes
From: Y.B. Lu @ 2017-05-04 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170503130545.GB24392@dragon>
Hi Shawn,
> -----Original Message-----
> From: Shawn Guo [mailto:shawnguo at kernel.org]
> Sent: Wednesday, May 03, 2017 9:06 PM
> To: Y.B. Lu
> Cc: linux-arm-kernel at lists.infradead.org; ulf.hansson at linaro.org; Catalin
> Marinas; Xiaobo Xie
> Subject: Re: [PATCH 3/3] arm64: dts: ls1012a: add eSDHC nodes
>
> On Fri, Apr 21, 2017 at 11:52:36AM +0800, Yangbo Lu wrote:
> > There are two eSDHC controllers in LS1012A. This patch is to add eSDHC
> > nodes for ls1012a dts. Also enable eSDHC for RDB/QDS boards.
> >
> > Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
> > ---
> > arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts | 8 ++++++++
> > arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts | 13 ++++++++++++
> > arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 25
> +++++++++++++++++++++++
> > 3 files changed, 46 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
> > b/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
> > index e2a93d5..a21a587 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
> > @@ -130,3 +130,11 @@
> > &sata {
> > status = "okay";
> > };
> > +
> > +&esdhc0 {
> > + status = "okay";
> > +};
> > +
> > +&esdhc1 {
> > + status = "okay";
> > +};
>
> Sort these labeled nodes alphabetically.
[Lu Yangbo-B47093] Ok, I will do that.
>
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
> > b/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
> > index ed77f6b..57669b0 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
> > @@ -61,3 +61,16 @@
> > &sata {
> > status = "okay";
> > };
> > +
> > +&esdhc0 {
> > + sd-uhs-sdr104;
> > + sd-uhs-sdr50;
> > + sd-uhs-sdr25;
> > + sd-uhs-sdr12;
> > + status = "okay";
> > +};
> > +
> > +&esdhc1 {
> > + mmc-hs200-1_8v;
> > + status = "okay";
> > +};
>
> Ditto
>
[Lu Yangbo-B47093] No problem.
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
> > b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
> > index b497ac1..e3a1943 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
> > @@ -302,6 +302,31 @@
> > };
> > };
> >
> > + esdhc0: esdhc at 1560000 {
>
> Sort the nodes in order of unit-address.
[Lu Yangbo-B47093] Ok, I will do that.
>
> > + compatible = "fsl,ls1012a-esdhc", "fsl,esdhc";
>
> Please document the compatible.
>
[Lu Yangbo-B47093] Ok, will add a patch for that
> Shawn
>
> > + reg = <0x0 0x1560000 0x0 0x10000>;
> > + interrupts = <0 62 0x4>;
> > + clocks = <&clockgen 4 0>;
> > + voltage-ranges = <1800 1800 3300 3300>;
> > + sdhci,auto-cmd12;
> > + big-endian;
> > + bus-width = <4>;
> > + status = "disabled";
> > + };
> > +
> > + esdhc1: esdhc at 1580000 {
> > + compatible = "fsl,ls1012a-esdhc", "fsl,esdhc";
> > + reg = <0x0 0x1580000 0x0 0x10000>;
> > + interrupts = <0 65 0x4>;
> > + clocks = <&clockgen 4 0>;
> > + voltage-ranges = <1800 1800 3300 3300>;
> > + sdhci,auto-cmd12;
> > + big-endian;
> > + broken-cd;
> > + bus-width = <4>;
> > + status = "disabled";
> > + };
> > +
> > i2c0: i2c at 2180000 {
> > compatible = "fsl,vf610-i2c";
> > #address-cells = <1>;
> > --
> > 2.1.0.27.g96db324
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [v2, 0/5] Add eSDHC UHS-I/HS200 mode support for ls1012a/ls1046a/ls208xa
From: Yangbo Lu @ 2017-05-04 10:48 UTC (permalink / raw)
To: linux-arm-kernel
This patchset is to add eSDHC UHS-I/HS200 mode support for ls1012a/ls1046a/ls208xa.
Also add eSDHC node for ls1088a. Because eSDHC is not a standard SD controller,
the specific speed mode support depends on board's peripheral circuit for eSDHC.
So, we have to add these speed modes support on board dts file.
In additon, these dts patches depends on esdhc driver patches which just had been merged
on mmc.git. Otherwise, the UHS-I SD card and eMMC HS200 card would fail to be initialized,
but other cards still could work fine.
https://patchwork.kernel.org/patch/9689875/
https://patchwork.kernel.org/patch/9689877/
https://patchwork.kernel.org/patch/9689879/
https://patchwork.kernel.org/patch/9689887/
https://patchwork.kernel.org/patch/9689885/
Yangbo Lu (5):
mmc: dt: add compatible into eSDHC required properties
arm64: dts: ls1046a: support SD UHS-I and eMMC HS200 on RDB
arm64: dts: ls208xa: support SD UHS-I on RDB and eMMC HS200 on QDS
arm64: dts: ls1012a: add eSDHC nodes
arm64: dts: ls1088a: add esdhc node
.../devicetree/bindings/mmc/fsl-esdhc.txt | 1 +
arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts | 8 +++++++
arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts | 13 +++++++++++
arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 25 ++++++++++++++++++++++
arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts | 8 +++++++
arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 4 ++--
arch/arm64/boot/dts/freescale/fsl-ls1088a-qds.dts | 4 ++++
arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts | 4 ++++
arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 12 +++++++++++
arch/arm64/boot/dts/freescale/fsl-ls208xa-qds.dtsi | 1 +
arch/arm64/boot/dts/freescale/fsl-ls208xa-rdb.dtsi | 4 ++++
arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 2 +-
12 files changed, 83 insertions(+), 3 deletions(-)
--
2.1.0.27.g96db324
^ permalink raw reply
* [v2, 1/5] mmc: dt: add compatible into eSDHC required properties
From: Yangbo Lu @ 2017-05-04 10:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493894940-47452-1-git-send-email-yangbo.lu@nxp.com>
This patch is to add compatible into eSDHC required properties.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
---
Changes for v2:
- Added this patch.
---
Documentation/devicetree/bindings/mmc/fsl-esdhc.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/mmc/fsl-esdhc.txt b/Documentation/devicetree/bindings/mmc/fsl-esdhc.txt
index dedfb02..b04b248 100644
--- a/Documentation/devicetree/bindings/mmc/fsl-esdhc.txt
+++ b/Documentation/devicetree/bindings/mmc/fsl-esdhc.txt
@@ -7,6 +7,7 @@ This file documents differences between the core properties described
by mmc.txt and the properties used by the sdhci-esdhc driver.
Required properties:
+ - compatible : should be "fsl,esdhc", or "fsl,<chip>-esdhc".
- interrupt-parent : interrupt source phandle.
- clock-frequency : specifies eSDHC base clock frequency.
--
2.1.0.27.g96db324
^ permalink raw reply related
* [v2, 2/5] arm64: dts: ls1046a: support SD UHS-I and eMMC HS200 on RDB
From: Yangbo Lu @ 2017-05-04 10:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493894940-47452-1-git-send-email-yangbo.lu@nxp.com>
This patch is to enable SD UHS-I mode and eMMC HS200 mode on
LS1046ARDB in dts. Also, the eSDHC peripheral clock must be used
instead of platform clock to support these modes.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
---
Changes for v2:
- Sorted the node.
---
arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts | 8 ++++++++
arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 4 ++--
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
index c5361e9..2d28726 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
@@ -72,6 +72,14 @@
status = "okay";
};
+&esdhc {
+ mmc-hs200-1_8v;
+ sd-uhs-sdr104;
+ sd-uhs-sdr50;
+ sd-uhs-sdr25;
+ sd-uhs-sdr12;
+};
+
&i2c0 {
status = "okay";
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index d67557f..46b7839 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -209,10 +209,10 @@
};
esdhc: esdhc at 1560000 {
- compatible = "fsl,esdhc";
+ compatible = "fsl,ls1046a-esdhc", "fsl,esdhc";
reg = <0x0 0x1560000 0x0 0x10000>;
interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
- clock-frequency = <0>;
+ clocks = <&clockgen 2 1>;
voltage-ranges = <1800 1800 3300 3300>;
sdhci,auto-cmd12;
big-endian;
--
2.1.0.27.g96db324
^ permalink raw reply related
* [v2, 3/5] arm64: dts: ls208xa: support SD UHS-I on RDB and eMMC HS200 on QDS
From: Yangbo Lu @ 2017-05-04 10:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493894940-47452-1-git-send-email-yangbo.lu@nxp.com>
This patch is to enable SD UHS-I mode on LS208xRDB and eMMC HS200
mode on LS208xQDS in dts. Also, the eSDHC peripheral clock must be
used instead of platform clock to support these modes.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
---
Changes for v2:
- None.
---
arch/arm64/boot/dts/freescale/fsl-ls208xa-qds.dtsi | 1 +
arch/arm64/boot/dts/freescale/fsl-ls208xa-rdb.dtsi | 4 ++++
arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 2 +-
3 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa-qds.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls208xa-qds.dtsi
index c4282d9..b237446 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa-qds.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa-qds.dtsi
@@ -46,6 +46,7 @@
*/
&esdhc {
+ mmc-hs200-1_8v;
status = "okay";
};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa-rdb.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls208xa-rdb.dtsi
index 9a1d0d2..29af54b 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa-rdb.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa-rdb.dtsi
@@ -46,6 +46,10 @@
*/
&esdhc {
+ sd-uhs-sdr104;
+ sd-uhs-sdr50;
+ sd-uhs-sdr25;
+ sd-uhs-sdr12;
status = "okay";
};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
index 6e531b9..94cdd30 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
@@ -472,7 +472,7 @@
compatible = "fsl,ls2080a-esdhc", "fsl,esdhc";
reg = <0x0 0x2140000 0x0 0x10000>;
interrupts = <0 28 0x4>; /* Level high type */
- clock-frequency = <0>; /* Updated by bootloader */
+ clocks = <&clockgen 4 1>;
voltage-ranges = <1800 1800 3300 3300>;
sdhci,auto-cmd12;
little-endian;
--
2.1.0.27.g96db324
^ permalink raw reply related
* [v2, 4/5] arm64: dts: ls1012a: add eSDHC nodes
From: Yangbo Lu @ 2017-05-04 10:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493894940-47452-1-git-send-email-yangbo.lu@nxp.com>
There are two eSDHC controllers in LS1012A. This patch is to add
eSDHC nodes for ls1012a dts. Also enable eSDHC for RDB/QDS boards.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
---
Changes for v2:
- Sorted the node.
---
arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts | 8 ++++++++
arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts | 13 ++++++++++++
arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 25 +++++++++++++++++++++++
3 files changed, 46 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts b/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
index 40ef468..8c013b5 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
@@ -97,6 +97,14 @@
status = "okay";
};
+&esdhc0 {
+ status = "okay";
+};
+
+&esdhc1 {
+ status = "okay";
+};
+
&i2c0 {
status = "okay";
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
index 65d4313..c1a119e 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
@@ -54,6 +54,19 @@
status = "okay";
};
+&esdhc0 {
+ sd-uhs-sdr104;
+ sd-uhs-sdr50;
+ sd-uhs-sdr25;
+ sd-uhs-sdr12;
+ status = "okay";
+};
+
+&esdhc1 {
+ mmc-hs200-1_8v;
+ status = "okay";
+};
+
&i2c0 {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
index ae47156..9a2ccd8 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
@@ -117,12 +117,37 @@
#size-cells = <2>;
ranges;
+ esdhc0: esdhc at 1560000 {
+ compatible = "fsl,ls1012a-esdhc", "fsl,esdhc";
+ reg = <0x0 0x1560000 0x0 0x10000>;
+ interrupts = <0 62 0x4>;
+ clocks = <&clockgen 4 0>;
+ voltage-ranges = <1800 1800 3300 3300>;
+ sdhci,auto-cmd12;
+ big-endian;
+ bus-width = <4>;
+ status = "disabled";
+ };
+
scfg: scfg at 1570000 {
compatible = "fsl,ls1012a-scfg", "syscon";
reg = <0x0 0x1570000 0x0 0x10000>;
big-endian;
};
+ esdhc1: esdhc at 1580000 {
+ compatible = "fsl,ls1012a-esdhc", "fsl,esdhc";
+ reg = <0x0 0x1580000 0x0 0x10000>;
+ interrupts = <0 65 0x4>;
+ clocks = <&clockgen 4 0>;
+ voltage-ranges = <1800 1800 3300 3300>;
+ sdhci,auto-cmd12;
+ big-endian;
+ broken-cd;
+ bus-width = <4>;
+ status = "disabled";
+ };
+
crypto: crypto at 1700000 {
compatible = "fsl,sec-v5.4", "fsl,sec-v5.0",
"fsl,sec-v4.0";
--
2.1.0.27.g96db324
^ permalink raw reply related
* [v2, 5/5] arm64: dts: ls1088a: add esdhc node
From: Yangbo Lu @ 2017-05-04 10:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493894940-47452-1-git-send-email-yangbo.lu@nxp.com>
Add esdhc node for ls1088a and enable it on both RDB and QDS boards.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
---
Changes for v2:
- Sorted the node.
---
arch/arm64/boot/dts/freescale/fsl-ls1088a-qds.dts | 4 ++++
arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts | 4 ++++
arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 12 ++++++++++++
3 files changed, 20 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a-qds.dts b/arch/arm64/boot/dts/freescale/fsl-ls1088a-qds.dts
index 8c3cae5..ff21055 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a-qds.dts
@@ -118,6 +118,10 @@
status = "okay";
};
+&esdhc {
+ status = "okay";
+};
+
&sata {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
index 8a04fbb..ab62ef6 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
@@ -102,6 +102,10 @@
status = "okay";
};
+&esdhc {
+ status = "okay";
+};
+
&sata {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
index 2946fd7..10b5775 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
@@ -263,6 +263,18 @@
status = "disabled";
};
+ esdhc: esdhc at 2140000 {
+ compatible = "fsl,ls1088a-esdhc", "fsl,esdhc";
+ reg = <0x0 0x2140000 0x0 0x10000>;
+ interrupts = <0 28 0x4>; /* Level high type */
+ clock-frequency = <0>;
+ voltage-ranges = <1800 1800 3300 3300>;
+ sdhci,auto-cmd12;
+ little-endian;
+ bus-width = <4>;
+ status = "disabled";
+ };
+
sata: sata at 3200000 {
compatible = "fsl,ls1088a-ahci", "fsl,ls1043a-ahci";
reg = <0x0 0x3200000 0x0 0x10000>;
--
2.1.0.27.g96db324
^ permalink raw reply related
* [PATCH 5/5] KVM: arm/arm64: Allow setting the timer IRQ numbers from userspace
From: Marc Zyngier @ 2017-05-04 10:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170504095918.GJ5923@cbox>
On 04/05/17 10:59, Christoffer Dall wrote:
> On Thu, May 04, 2017 at 10:34:32AM +0100, Marc Zyngier wrote:
>> On 03/05/17 19:33, Christoffer Dall wrote:
>>> First we define an ABI using the vcpu devices that lets userspace set
>>> the interrupt numbers for the various timers on both the 32-bit and
>>> 64-bit KVM/ARM implementations.
>>>
>>> Second, we add the definitions for the groups and attributes introduced
>>> by the above ABI. (We add the PMU define on the 32-bit side as well for
>>> symmetry and it may get used some day.)
>>>
>>> Third, we set up the arch-specific vcpu device operation handlers to
>>> call into the timer code for anything related to the
>>> KVM_ARM_VCPU_TIMER_CTRL group.
>>>
>>> Fourth, we implement support for getting and setting the timer interrupt
>>> numbers using the above defined ABI in the arch timer code.
>>>
>>> Fifth, we introduce error checking upon enabling the arch timer (which
>>> is called when first running a VCPU) to check that all VCPUs are
>>> configured to use the same PPI for the timer (as mandated by the
>>> architecture) and that the virtual and physical timers are not
>>> configured to use the same IRQ number.
>>>
>>> Signed-off-by: Christoffer Dall <cdall@linaro.org>
>>> ---
>>> Documentation/virtual/kvm/devices/vcpu.txt | 25 +++++++
>>> arch/arm/include/uapi/asm/kvm.h | 8 +++
>>> arch/arm/kvm/guest.c | 9 +++
>>> arch/arm64/include/uapi/asm/kvm.h | 3 +
>>> arch/arm64/kvm/guest.c | 9 +++
>>> include/kvm/arm_arch_timer.h | 4 ++
>>> virt/kvm/arm/arch_timer.c | 104 +++++++++++++++++++++++++++++
>>> 7 files changed, 162 insertions(+)
>>>
>>> diff --git a/Documentation/virtual/kvm/devices/vcpu.txt b/Documentation/virtual/kvm/devices/vcpu.txt
>>> index 352af6e..013e3f1 100644
>>> --- a/Documentation/virtual/kvm/devices/vcpu.txt
>>> +++ b/Documentation/virtual/kvm/devices/vcpu.txt
>>> @@ -35,3 +35,28 @@ Returns: -ENODEV: PMUv3 not supported or GIC not initialized
>>> Request the initialization of the PMUv3. If using the PMUv3 with an in-kernel
>>> virtual GIC implementation, this must be done after initializing the in-kernel
>>> irqchip.
>>> +
>>> +
>>> +2. GROUP: KVM_ARM_VCPU_TIMER_CTRL
>>> +Architectures: ARM,ARM64
>>> +
>>> +2.1. ATTRIBUTE: KVM_ARM_VCPU_TIMER_IRQ_VTIMER
>>> +2.2. ATTRIBUTE: KVM_ARM_VCPU_TIMER_IRQ_PTIMER
>>> +Parameters: in kvm_device_attr.addr the address for the timer interrupt is a
>>> + pointer to an int
>>> +Returns: -EINVAL: Invalid timer interrupt number
>>> + -EBUSY: One or more VCPUs has already run
>>> +
>>> +A value describing the architected timer interrupt number when connected to an
>>> +in-kernel virtual GIC. These must be a PPI (16 <= intid < 32). If an
>>> +attribute is not set, a default value is applied (see below).
>>> +
>>> +KVM_ARM_VCPU_TIMER_IRQ_VTIMER: The EL1 virtual timer intid (default: 27)
>>> +KVM_ARM_VCPU_TIMER_IRQ_PTIMER: The EL1 physical timer intid (default: 30)
>>
>> uber nit: my reading of the code is that the default is set at VCPU
>> creation time. So setting the attribute overrides the default, not that
>> the default is applied if no attribute is set (i.e. there is always a
>> valid value).
>>
>
> uh, right, I don't see the distinction though, so not sure how to
> correct the text.
>
> Would "Setting the attribute overrides the default values (see below)."
> work instead?
Looks good to me.
[...]
>>
>> Another issue that just popped in my head: how do we ensure that we
>> don't clash between the PMU and the timers? Yes, that's a foolish thing
>> to do, but that's no different from avoiding the same interrupt on the
>> timers...
>>
> Argh, good point.
>
> So actually, nothing *really bad* happens from using the same IRQ number
> except that the VM gets confused. However, it's living life dangerously
> because we use the HW bit for the vtimer, so we if ever start using it
> for other timers or the PMU, then you could end up in a situation where
> you unmap the phys mapping on behalf of another device, and the physical
> interrupt could be left in an active state.
>
> On the other hand, the vtimer currently belongs only to VMs and we set
> the required physical active state before entering the VM, so maybe it
> doesn't matter.
So far, we always assume that there is never more than a single source
per interrupt. We'll end-up with weird behaviours because our line_level
field is not an OR of the various inputs, but a direct assignment
(device A and B raise the line, then A drops it -> B's interrupt is gone).
I think that only the guest will be confused by it, but accepting it may
be interpreted as "this should work correctly". Would documenting that
it is a bad idea be enough?
> Should we just forego these checks and let the user shoot itself in the
> foot if he/she wants to?
If the documentation is enough, why not. Otherwise, we need some form of
allocator. Boring. ;-)
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 0/3] Add eSDHC UHS-I/HS200 mode support for ls1012a/ls1046a/ls208xa
From: Y.B. Lu @ 2017-05-04 10:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170503131408.GC24392@dragon>
Hi Shawn,
> -----Original Message-----
> From: Shawn Guo [mailto:shawnguo at kernel.org]
> Sent: Wednesday, May 03, 2017 9:14 PM
> To: Y.B. Lu
> Cc: linux-arm-kernel at lists.infradead.org; ulf.hansson at linaro.org; Catalin
> Marinas; Xiaobo Xie
> Subject: Re: [PATCH 0/3] Add eSDHC UHS-I/HS200 mode support for
> ls1012a/ls1046a/ls208xa
>
> On Fri, Apr 21, 2017 at 11:52:33AM +0800, Yangbo Lu wrote:
> > This patch is to add eSDHC UHS-I/HS200 mode support for
> ls1012a/ls1046a/ls208xa.
> > Because eSDHC is not a standard SD controller, the specific speed mode
> > support depends on board's peripheral circuit for eSDHC. So, we have
> > to add these speed modes support on board dts file.
> >
> > In additon, these dts patches depends on esdhc driver patches which
> > just had been merged on mmc.git. Otherwise, the UHS-I SD card and eMMC
> > HS200 card would fail to be initialized, but other cards still could
> work fine.
>
> So it sounds like just a new feature development which doesn't cause any
> regression, even if driver and dts changes are merged independently.
> For such case, we can just merge patches in their natural path separately.
>
[Lu Yangbo-B47093] The dts patches affect cards which support uhs-i/hs200 modes.
Without driver patches, these card couldn't work. But they work on high speed mode on your current kernel.
Other legacy high speed cards always work fine.
I think it's ok to apply them now(affect uhs-i/hs200 cards, but legacy high speed cards work), or wait for driver patches pulled.
Thanks :)
> Shawn
^ permalink raw reply
* [PATCH] arm64: dts: ls1088a: add esdhc node
From: Y.B. Lu @ 2017-05-04 10:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170503140043.GH18578@dragon>
> -----Original Message-----
> From: Shawn Guo [mailto:shawnguo at kernel.org]
> Sent: Wednesday, May 03, 2017 10:01 PM
> To: Y.B. Lu
> Cc: linux-arm-kernel at lists.infradead.org; Catalin Marinas; Harninder Rai;
> Xiaobo Xie
> Subject: Re: [PATCH] arm64: dts: ls1088a: add esdhc node
>
> On Thu, Apr 27, 2017 at 01:31:50PM +0800, Yangbo Lu wrote:
> > Add esdhc node for ls1088a and enable it on both RDB and QDS boards.
> >
> > Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
>
> It seems that the comments I put on '[PATCH 3/3] arm64: dts: ls1012a:
> add eSDHC nodes' applies to this one as well.
>
[Lu Yangbo-B47093] Ok, I will modify it. And I will add this patch in eSDHC dts patchset also with another doc patch.
Thanks.
> Shawn
^ permalink raw reply
* [PATCH 3/4] ARM: perf: Allow the use of the PMUv3 driver on 32bit ARM
From: Vladimir Murzin @ 2017-05-04 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170324121529.22603-4-marc.zyngier@arm.com>
Hi Marc,
On 24/03/17 12:15, Marc Zyngier wrote:
> The only thing stopping the PMUv3 driver from compiling on 32bit
> is the lack of defined system registers names. This is easily
> solved by providing the sysreg accessors and updating the Kconfig entry.
>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> arch/arm/include/asm/arm_pmuv3.h | 115 +++++++++++++++++++++++++++++++++++++++
> drivers/perf/Kconfig | 4 +-
> 2 files changed, 117 insertions(+), 2 deletions(-)
> create mode 100644 arch/arm/include/asm/arm_pmuv3.h
>
> diff --git a/arch/arm/include/asm/arm_pmuv3.h b/arch/arm/include/asm/arm_pmuv3.h
> new file mode 100644
> index 000000000000..df14de3d7bdf
> --- /dev/null
> +++ b/arch/arm/include/asm/arm_pmuv3.h
> @@ -0,0 +1,115 @@
> +/*
> + * Copyright (C) 2012 ARM Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#ifndef __ASM_PMUV3_H
> +#define __ASM_PMUV3_H
> +
> +#include <asm/cp15.h>
> +
> +#define pmcr __ACCESS_CP15(c9, 0, c12, 0)
> +#define pmselr __ACCESS_CP15(c9, 0, c12, 5)
> +#define pmccntr __ACCESS_CP15_64(0, c9)
> +#define pmxevcntr __ACCESS_CP15(c9, 0, c13, 2)
> +#define pmxevtyper __ACCESS_CP15(c9, 0, c13, 1)
> +#define pmcntenset __ACCESS_CP15(c9, 0, c12, 1)
> +#define pmcntenclr __ACCESS_CP15(c9, 0, c12, 2)
> +#define pmintenset __ACCESS_CP15(c9, 0, c12, 1)
Encoding is not right here
To access the PMINTENSET:
MRC p15,0,<Rt>,c9,c14,1 ; Read PMINTENSET into Rt
MCR p15,0,<Rt>,c9,c14,1 ; Write Rt to PMINTENSET
> +#define pmintenclr __ACCESS_CP15(c9, 0, c12, 2)
Ditto
To access the PMINTENCLR:
MRC p15,0,<Rt>,c9,c14,2 ; Read PMINTENCLR into Rt
MCR p15,0,<Rt>,c9,c14,2 ; Write Rt to PMINTENCLR
> +#define pmovsclr __ACCESS_CP15(c9, 0, c12, 3)
Nit: in 32-bit world it is named as PMOVSR.
> +#define pmceid0 __ACCESS_CP15(c9, 0, c12, 6)
> +#define pmceid1 __ACCESS_CP15(c9, 0, c12, 7)
Can all these defines be done in uppercase to be in align with existent users
of __ACCESS_CP15() macro?
Thanks
Vladimir
^ permalink raw reply
* [PATCH 5/5] KVM: arm/arm64: Allow setting the timer IRQ numbers from userspace
From: Christoffer Dall @ 2017-05-04 11:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <79ec69f2-d727-46ec-b1d5-4c535a904e63@arm.com>
On Thu, May 04, 2017 at 11:54:06AM +0100, Marc Zyngier wrote:
> On 04/05/17 10:59, Christoffer Dall wrote:
> > On Thu, May 04, 2017 at 10:34:32AM +0100, Marc Zyngier wrote:
> >> On 03/05/17 19:33, Christoffer Dall wrote:
> >>> First we define an ABI using the vcpu devices that lets userspace set
> >>> the interrupt numbers for the various timers on both the 32-bit and
> >>> 64-bit KVM/ARM implementations.
> >>>
> >>> Second, we add the definitions for the groups and attributes introduced
> >>> by the above ABI. (We add the PMU define on the 32-bit side as well for
> >>> symmetry and it may get used some day.)
> >>>
> >>> Third, we set up the arch-specific vcpu device operation handlers to
> >>> call into the timer code for anything related to the
> >>> KVM_ARM_VCPU_TIMER_CTRL group.
> >>>
> >>> Fourth, we implement support for getting and setting the timer interrupt
> >>> numbers using the above defined ABI in the arch timer code.
> >>>
> >>> Fifth, we introduce error checking upon enabling the arch timer (which
> >>> is called when first running a VCPU) to check that all VCPUs are
> >>> configured to use the same PPI for the timer (as mandated by the
> >>> architecture) and that the virtual and physical timers are not
> >>> configured to use the same IRQ number.
> >>>
> >>> Signed-off-by: Christoffer Dall <cdall@linaro.org>
> >>> ---
> >>> Documentation/virtual/kvm/devices/vcpu.txt | 25 +++++++
> >>> arch/arm/include/uapi/asm/kvm.h | 8 +++
> >>> arch/arm/kvm/guest.c | 9 +++
> >>> arch/arm64/include/uapi/asm/kvm.h | 3 +
> >>> arch/arm64/kvm/guest.c | 9 +++
> >>> include/kvm/arm_arch_timer.h | 4 ++
> >>> virt/kvm/arm/arch_timer.c | 104 +++++++++++++++++++++++++++++
> >>> 7 files changed, 162 insertions(+)
> >>>
> >>> diff --git a/Documentation/virtual/kvm/devices/vcpu.txt b/Documentation/virtual/kvm/devices/vcpu.txt
> >>> index 352af6e..013e3f1 100644
> >>> --- a/Documentation/virtual/kvm/devices/vcpu.txt
> >>> +++ b/Documentation/virtual/kvm/devices/vcpu.txt
> >>> @@ -35,3 +35,28 @@ Returns: -ENODEV: PMUv3 not supported or GIC not initialized
> >>> Request the initialization of the PMUv3. If using the PMUv3 with an in-kernel
> >>> virtual GIC implementation, this must be done after initializing the in-kernel
> >>> irqchip.
> >>> +
> >>> +
> >>> +2. GROUP: KVM_ARM_VCPU_TIMER_CTRL
> >>> +Architectures: ARM,ARM64
> >>> +
> >>> +2.1. ATTRIBUTE: KVM_ARM_VCPU_TIMER_IRQ_VTIMER
> >>> +2.2. ATTRIBUTE: KVM_ARM_VCPU_TIMER_IRQ_PTIMER
> >>> +Parameters: in kvm_device_attr.addr the address for the timer interrupt is a
> >>> + pointer to an int
> >>> +Returns: -EINVAL: Invalid timer interrupt number
> >>> + -EBUSY: One or more VCPUs has already run
> >>> +
> >>> +A value describing the architected timer interrupt number when connected to an
> >>> +in-kernel virtual GIC. These must be a PPI (16 <= intid < 32). If an
> >>> +attribute is not set, a default value is applied (see below).
> >>> +
> >>> +KVM_ARM_VCPU_TIMER_IRQ_VTIMER: The EL1 virtual timer intid (default: 27)
> >>> +KVM_ARM_VCPU_TIMER_IRQ_PTIMER: The EL1 physical timer intid (default: 30)
> >>
> >> uber nit: my reading of the code is that the default is set at VCPU
> >> creation time. So setting the attribute overrides the default, not that
> >> the default is applied if no attribute is set (i.e. there is always a
> >> valid value).
> >>
> >
> > uh, right, I don't see the distinction though, so not sure how to
> > correct the text.
> >
> > Would "Setting the attribute overrides the default values (see below)."
> > work instead?
>
> Looks good to me.
>
> [...]
>
> >>
> >> Another issue that just popped in my head: how do we ensure that we
> >> don't clash between the PMU and the timers? Yes, that's a foolish thing
> >> to do, but that's no different from avoiding the same interrupt on the
> >> timers...
> >>
> > Argh, good point.
> >
> > So actually, nothing *really bad* happens from using the same IRQ number
> > except that the VM gets confused. However, it's living life dangerously
> > because we use the HW bit for the vtimer, so we if ever start using it
> > for other timers or the PMU, then you could end up in a situation where
> > you unmap the phys mapping on behalf of another device, and the physical
> > interrupt could be left in an active state.
> >
> > On the other hand, the vtimer currently belongs only to VMs and we set
> > the required physical active state before entering the VM, so maybe it
> > doesn't matter.
>
> So far, we always assume that there is never more than a single source
> per interrupt. We'll end-up with weird behaviours because our line_level
> field is not an OR of the various inputs, but a direct assignment
> (device A and B raise the line, then A drops it -> B's interrupt is gone).
>
> I think that only the guest will be confused by it, but accepting it may
> be interpreted as "this should work correctly". Would documenting that
> it is a bad idea be enough?
>
> > Should we just forego these checks and let the user shoot itself in the
> > foot if he/she wants to?
>
> If the documentation is enough, why not. Otherwise, we need some form of
> allocator. Boring. ;-)
>
Well, it's not that bad really (untested):
diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
index 1541f5d..122f9d3 100644
--- a/include/kvm/arm_vgic.h
+++ b/include/kvm/arm_vgic.h
@@ -121,6 +121,9 @@ struct vgic_irq {
u8 source; /* GICv2 SGIs only */
u8 priority;
enum vgic_irq_config config; /* Level or edge */
+
+ void *owner; /* Opaque pointer to reserve an interrupt
+ for in-kernel devices. */
};
struct vgic_register_region;
diff --git a/virt/kvm/arm/vgic/vgic.c b/virt/kvm/arm/vgic/vgic.c
index 3d0979c..7561d2d 100644
--- a/virt/kvm/arm/vgic/vgic.c
+++ b/virt/kvm/arm/vgic/vgic.c
@@ -429,6 +429,42 @@ int kvm_vgic_unmap_phys_irq(struct kvm_vcpu *vcpu, unsigned int virt_irq)
}
/**
+ * kvm_vgic_set_owner - Set the owner of an interrupt for a VM
+ *
+ * @kvm: Pointer to the VM structure
+ * @intid: The virtual INTID identifying the interrupt (PPI or SPI)
+ * @owner: Opaque pointer to the owner
+ *
+ * Returns 0 if intid is not already used by another in-kernel device and the
+ * owner is set, otherwise returns an error code.
+ *
+ * We only set the owner for VCPU 0 for PPIs.
+ */
+int kvm_vgic_set_owner(struct kvm *kvm, unsigned int intid, void *owner)
+{
+ struct vgic_irq *irq;
+ struct kvm_vcpu *vcpu = kvm_get_vcpu(kvm, 0);
+ int ret = 0;
+
+ if (!vgic_initialized(kvm))
+ return -EAGAIN;
+
+ /* SGIs and LPIs cannot be wired up to any device */
+ if (!irq_is_ppi(intid) && !vgic_valid_spi(kvm, intid))
+ return -EINVAL;
+
+ irq = vgic_get_irq(kvm, vcpu, intid);
+ spin_lock(&irq->irq_lock);
+ if (irq->owner && irq->owner != owner)
+ ret = -EEXIST;
+ else
+ irq->owner = owner;
+ spin_unlock(&irq->irq_lock);
+
+ return ret;
+}
+
+/**
* vgic_prune_ap_list - Remove non-relevant interrupts from the list
*
* @vcpu: The VCPU pointer
The problem is that it doesn't help that much, because userspace can
still change the level of an IRQ which is connected to an in-kernel
device, unless we also introduce checking the owner field in the
injection path.
I don't see it blowing up the host with/without an allocator, so I'm
fine with documentation, but I can also include the above.
Thoughts?
Thanks,
-Christoffer
^ permalink raw reply related
* [PATCH] arm64: Fix the DMA mmap and get_sgtable API with DMA_ATTR_FORCE_CONTIGUOUS
From: Robin Murphy @ 2017-05-04 11:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493143232-2245-1-git-send-email-catalin.marinas@arm.com>
On 25/04/17 19:00, Catalin Marinas wrote:
> While honouring the DMA_ATTR_FORCE_CONTIGUOUS on arm64 (commit
> 44176bb38fa4: "arm64: Add support for DMA_ATTR_FORCE_CONTIGUOUS to
> IOMMU"), the existing uses of dma_mmap_attrs() and dma_get_sgtable()
> have been broken by passing a physically contiguous vm_struct with an
> invalid pages pointer through the common iommu API.
>
> Since the coherent allocation with DMA_ATTR_FORCE_CONTIGUOUS uses CMA,
> this patch simply reuses the existing swiotlb logic for mmap and
> get_sgtable.
>
> Note that the current implementation of get_sgtable (both swiotlb and
> iommu) is broken if dma_declare_coherent_memory() is used since such
> memory does not have a corresponding struct page. To be addressed in a
> separate patch.
>
> Fixes: 44176bb38fa4 ("arm64: Add support for DMA_ATTR_FORCE_CONTIGUOUS to IOMMU")
> Reported-by: Andrzej Hajda <a.hajda@samsung.com>
> Cc: Andrzej Hajda <a.hajda@samsung.com>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> ---
>
> Here's my attempt of fixing this, though I'd like to wait for Robin's review
> (who's currently on holiday until next week).
>
> Not tested.
The general approach is sound, and I can't see anything that looks
obviously wrong with the implementation, although I have no easy way of
testing it either:
Acked-by: Robin Murphy <robin.murphy@arm.com>
As for all the other failings of get_sgtable, it seems those have been
wrong from its inception, so can't be particularly critical as they're
presumably not being hit in practice - if this fixes all the actual
regressions I'd be inclined to leave it at that until the dma_buf folks
can cook up a suitable replacement for the whole mess.
Robin.
> arch/arm64/mm/dma-mapping.c | 65 ++++++++++++++++++++++++++++++++++-----------
> 1 file changed, 49 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
> index f7b54019ef55..c9e53dec3695 100644
> --- a/arch/arm64/mm/dma-mapping.c
> +++ b/arch/arm64/mm/dma-mapping.c
> @@ -308,24 +308,15 @@ static void __swiotlb_sync_sg_for_device(struct device *dev,
> sg->length, dir);
> }
>
> -static int __swiotlb_mmap(struct device *dev,
> - struct vm_area_struct *vma,
> - void *cpu_addr, dma_addr_t dma_addr, size_t size,
> - unsigned long attrs)
> +static int __swiotlb_mmap_pfn(struct vm_area_struct *vma,
> + unsigned long pfn, size_t size)
> {
> int ret = -ENXIO;
> unsigned long nr_vma_pages = (vma->vm_end - vma->vm_start) >>
> PAGE_SHIFT;
> unsigned long nr_pages = PAGE_ALIGN(size) >> PAGE_SHIFT;
> - unsigned long pfn = dma_to_phys(dev, dma_addr) >> PAGE_SHIFT;
> unsigned long off = vma->vm_pgoff;
>
> - vma->vm_page_prot = __get_dma_pgprot(attrs, vma->vm_page_prot,
> - is_device_dma_coherent(dev));
> -
> - if (dma_mmap_from_coherent(dev, vma, cpu_addr, size, &ret))
> - return ret;
> -
> if (off < nr_pages && nr_vma_pages <= (nr_pages - off)) {
> ret = remap_pfn_range(vma, vma->vm_start,
> pfn + off,
> @@ -336,19 +327,43 @@ static int __swiotlb_mmap(struct device *dev,
> return ret;
> }
>
> -static int __swiotlb_get_sgtable(struct device *dev, struct sg_table *sgt,
> - void *cpu_addr, dma_addr_t handle, size_t size,
> - unsigned long attrs)
> +static int __swiotlb_mmap(struct device *dev,
> + struct vm_area_struct *vma,
> + void *cpu_addr, dma_addr_t dma_addr, size_t size,
> + unsigned long attrs)
> +{
> + int ret;
> + unsigned long pfn = dma_to_phys(dev, dma_addr) >> PAGE_SHIFT;
> +
> + vma->vm_page_prot = __get_dma_pgprot(attrs, vma->vm_page_prot,
> + is_device_dma_coherent(dev));
> +
> + if (dma_mmap_from_coherent(dev, vma, cpu_addr, size, &ret))
> + return ret;
> +
> + return __swiotlb_mmap_pfn(vma, pfn, size);
> +}
> +
> +static int __swiotlb_get_sgtable_page(struct sg_table *sgt,
> + struct page *page, size_t size)
> {
> int ret = sg_alloc_table(sgt, 1, GFP_KERNEL);
>
> if (!ret)
> - sg_set_page(sgt->sgl, phys_to_page(dma_to_phys(dev, handle)),
> - PAGE_ALIGN(size), 0);
> + sg_set_page(sgt->sgl, page, PAGE_ALIGN(size), 0);
>
> return ret;
> }
>
> +static int __swiotlb_get_sgtable(struct device *dev, struct sg_table *sgt,
> + void *cpu_addr, dma_addr_t handle, size_t size,
> + unsigned long attrs)
> +{
> + struct page *page = phys_to_page(dma_to_phys(dev, handle));
> +
> + return __swiotlb_get_sgtable_page(sgt, page, size);
> +}
> +
> static int __swiotlb_dma_supported(struct device *hwdev, u64 mask)
> {
> if (swiotlb)
> @@ -703,6 +718,15 @@ static int __iommu_mmap_attrs(struct device *dev, struct vm_area_struct *vma,
> if (dma_mmap_from_coherent(dev, vma, cpu_addr, size, &ret))
> return ret;
>
> + if (attrs & DMA_ATTR_FORCE_CONTIGUOUS) {
> + /*
> + * DMA_ATTR_FORCE_CONTIGUOUS allocations are always remapped,
> + * hence in the vmalloc space.
> + */
> + unsigned long pfn = vmalloc_to_pfn(cpu_addr);
> + return __swiotlb_mmap_pfn(vma, pfn, size);
> + }
> +
> area = find_vm_area(cpu_addr);
> if (WARN_ON(!area || !area->pages))
> return -ENXIO;
> @@ -717,6 +741,15 @@ static int __iommu_get_sgtable(struct device *dev, struct sg_table *sgt,
> unsigned int count = PAGE_ALIGN(size) >> PAGE_SHIFT;
> struct vm_struct *area = find_vm_area(cpu_addr);
>
> + if (attrs & DMA_ATTR_FORCE_CONTIGUOUS) {
> + /*
> + * DMA_ATTR_FORCE_CONTIGUOUS allocations are always remapped,
> + * hence in the vmalloc space.
> + */
> + struct page *page = vmalloc_to_page(cpu_addr);
> + return __swiotlb_get_sgtable_page(sgt, page, size);
> + }
> +
> if (WARN_ON(!area || !area->pages))
> return -ENXIO;
>
>
^ permalink raw reply
* [PATCH 3/4] ARM: perf: Allow the use of the PMUv3 driver on 32bit ARM
From: Marc Zyngier @ 2017-05-04 11:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <74692e75-1cb7-21da-be83-7a315e9a84b6@arm.com>
On 04/05/17 12:00, Vladimir Murzin wrote:
> Hi Marc,
>
> On 24/03/17 12:15, Marc Zyngier wrote:
>> The only thing stopping the PMUv3 driver from compiling on 32bit
>> is the lack of defined system registers names. This is easily
>> solved by providing the sysreg accessors and updating the Kconfig entry.
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>> ---
>> arch/arm/include/asm/arm_pmuv3.h | 115 +++++++++++++++++++++++++++++++++++++++
>> drivers/perf/Kconfig | 4 +-
>> 2 files changed, 117 insertions(+), 2 deletions(-)
>> create mode 100644 arch/arm/include/asm/arm_pmuv3.h
>>
>> diff --git a/arch/arm/include/asm/arm_pmuv3.h b/arch/arm/include/asm/arm_pmuv3.h
>> new file mode 100644
>> index 000000000000..df14de3d7bdf
>> --- /dev/null
>> +++ b/arch/arm/include/asm/arm_pmuv3.h
>> @@ -0,0 +1,115 @@
>> +/*
>> + * Copyright (C) 2012 ARM Ltd.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#ifndef __ASM_PMUV3_H
>> +#define __ASM_PMUV3_H
>> +
>> +#include <asm/cp15.h>
>> +
>> +#define pmcr __ACCESS_CP15(c9, 0, c12, 0)
>> +#define pmselr __ACCESS_CP15(c9, 0, c12, 5)
>> +#define pmccntr __ACCESS_CP15_64(0, c9)
>> +#define pmxevcntr __ACCESS_CP15(c9, 0, c13, 2)
>> +#define pmxevtyper __ACCESS_CP15(c9, 0, c13, 1)
>> +#define pmcntenset __ACCESS_CP15(c9, 0, c12, 1)
>> +#define pmcntenclr __ACCESS_CP15(c9, 0, c12, 2)
>> +#define pmintenset __ACCESS_CP15(c9, 0, c12, 1)
>
> Encoding is not right here
>
> To access the PMINTENSET:
>
> MRC p15,0,<Rt>,c9,c14,1 ; Read PMINTENSET into Rt
>
> MCR p15,0,<Rt>,c9,c14,1 ; Write Rt to PMINTENSET
>
>
>> +#define pmintenclr __ACCESS_CP15(c9, 0, c12, 2)
>
> Ditto
>
> To access the PMINTENCLR:
>
> MRC p15,0,<Rt>,c9,c14,2 ; Read PMINTENCLR into Rt
>
> MCR p15,0,<Rt>,c9,c14,2 ; Write Rt to PMINTENCLR
Arghh, -ECOPYPASTE. Thanks for the heads up!
>
>
>> +#define pmovsclr __ACCESS_CP15(c9, 0, c12, 3)
>
> Nit: in 32-bit world it is named as PMOVSR.
>
>> +#define pmceid0 __ACCESS_CP15(c9, 0, c12, 6)
>> +#define pmceid1 __ACCESS_CP15(c9, 0, c12, 7)
>
> Can all these defines be done in uppercase to be in align with existent users
> of __ACCESS_CP15() macro?
Sure, that shouldn't be an issue.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v2 0/4] arm64: improve tagged pointer handling
From: Will Deacon @ 2017-05-04 11:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493825868-30872-1-git-send-email-kristina.martsenko@arm.com>
Hi Kristina,
On Wed, May 03, 2017 at 04:37:44PM +0100, Kristina Martsenko wrote:
> Here are some patches to fix a few issues related to tagged pointer
> handling.
These all look good to me, thanks:
Acked-by: Will Deacon <will.deacon@arm.com>
Catalin -- I think you can take these all as fixes, with CC stable too
(fixes: tags are already in place).
Cheers,
Will
^ permalink raw reply
* [PATCH 01/13] dt-bindings: add binding for the Allwinner DE2 CCU
From: Icenowy Zheng @ 2017-05-04 11:41 UTC (permalink / raw)
To: linux-arm-kernel
Allwinner "Display Engine 2.0" contains some clock controls in it.
In order to add them as clock drivers, we need a device tree binding.
Add the binding here.
Also add the device tree binding headers.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Acked-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/clock/sun8i-de2.txt | 30 ++++++++++++++++++++++
include/dt-bindings/clock/sun8i-de2.h | 18 +++++++++++++
include/dt-bindings/reset/sun8i-de2.h | 14 ++++++++++
3 files changed, 62 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/sun8i-de2.txt
create mode 100644 include/dt-bindings/clock/sun8i-de2.h
create mode 100644 include/dt-bindings/reset/sun8i-de2.h
diff --git a/Documentation/devicetree/bindings/clock/sun8i-de2.txt b/Documentation/devicetree/bindings/clock/sun8i-de2.txt
new file mode 100644
index 000000000000..d710c0111cd3
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/sun8i-de2.txt
@@ -0,0 +1,30 @@
+Allwinner Display Engine 2.0 Clock Control Binding
+--------------------------------------------------
+
+Required properties :
+- compatible: must contain one of the following compatibles:
+ - "allwinner,sun8i-a83t-de2-clk"
+ - "allwinner,sun50i-h5-de2-clk"
+
+- reg: Must contain the registers base address and length
+- clocks: phandle to the clocks feeding the display engine subsystem.
+ Three are needed:
+ - "mod": the display engine module clock
+ - "bus": the bus clock for the whole display engine subsystem
+- clock-names: Must contain the clock names described just above
+- resets: phandle to the reset control for the display engine subsystem.
+- #clock-cells : must contain 1
+- #reset-cells : must contain 1
+
+Example:
+de2_clocks: clock at 1000000 {
+ compatible = "allwinner,sun8i-a83t-de2-clk";
+ reg = <0x01000000 0x100000>;
+ clocks = <&ccu CLK_DE>,
+ <&ccu CLK_BUS_DE>;
+ clock-names = "mod",
+ "bus";
+ resets = <&ccu RST_BUS_DE>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+};
diff --git a/include/dt-bindings/clock/sun8i-de2.h b/include/dt-bindings/clock/sun8i-de2.h
new file mode 100644
index 000000000000..3bed63b524aa
--- /dev/null
+++ b/include/dt-bindings/clock/sun8i-de2.h
@@ -0,0 +1,18 @@
+/*
+ * Copyright (C) 2016 Icenowy Zheng <icenowy@aosc.io>
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+#ifndef _DT_BINDINGS_CLOCK_SUN8I_DE2_H_
+#define _DT_BINDINGS_CLOCK_SUN8I_DE2_H_
+
+#define CLK_BUS_MIXER0 0
+#define CLK_BUS_MIXER1 1
+#define CLK_BUS_WB 2
+
+#define CLK_MIXER0 6
+#define CLK_MIXER1 7
+#define CLK_WB 8
+
+#endif /* _DT_BINDINGS_CLOCK_SUN8I_DE2_H_ */
diff --git a/include/dt-bindings/reset/sun8i-de2.h b/include/dt-bindings/reset/sun8i-de2.h
new file mode 100644
index 000000000000..9526017432f0
--- /dev/null
+++ b/include/dt-bindings/reset/sun8i-de2.h
@@ -0,0 +1,14 @@
+/*
+ * Copyright (C) 2016 Icenowy Zheng <icenowy@aosc.io>
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+#ifndef _DT_BINDINGS_RESET_SUN8I_DE2_H_
+#define _DT_BINDINGS_RESET_SUN8I_DE2_H_
+
+#define RST_MIXER0 0
+#define RST_MIXER1 1
+#define RST_WB 2
+
+#endif /* _DT_BINDINGS_RESET_SUN8I_DE2_H_ */
--
2.12.2
^ permalink raw reply related
* [PATCH 02/13] clk: sunxi-ng: add support for DE2 CCU
From: Icenowy Zheng @ 2017-05-04 11:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170504114208.8524-1-icenowy@aosc.io>
The "Display Engine 2.0" in Allwinner newer SoCs contains a clock
management unit for its subunits, like the DE CCU in A80.
Add a sunxi-ng style driver for it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
drivers/clk/sunxi-ng/Kconfig | 5 +
drivers/clk/sunxi-ng/Makefile | 1 +
drivers/clk/sunxi-ng/ccu-sun8i-de2.c | 218 +++++++++++++++++++++++++++++++++++
drivers/clk/sunxi-ng/ccu-sun8i-de2.h | 28 +++++
4 files changed, 252 insertions(+)
create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-de2.c
create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-de2.h
diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-ng/Kconfig
index 64088e599404..2e4d804fbf61 100644
--- a/drivers/clk/sunxi-ng/Kconfig
+++ b/drivers/clk/sunxi-ng/Kconfig
@@ -140,6 +140,11 @@ config SUN8I_V3S_CCU
default MACH_SUN8I
depends on MACH_SUN8I || COMPILE_TEST
+config SUN8I_DE2_CCU
+ bool "Support for the Allwinner SoCs DE2 CCU"
+ select SUNXI_CCU_DIV
+ select SUNXI_CCU_GATE
+
config SUN9I_A80_CCU
bool "Support for the Allwinner A80 CCU"
select SUNXI_CCU_DIV
diff --git a/drivers/clk/sunxi-ng/Makefile b/drivers/clk/sunxi-ng/Makefile
index 0ec02fe14c50..be616279450e 100644
--- a/drivers/clk/sunxi-ng/Makefile
+++ b/drivers/clk/sunxi-ng/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_SUN8I_A23_CCU) += ccu-sun8i-a23.o
obj-$(CONFIG_SUN8I_A33_CCU) += ccu-sun8i-a33.o
obj-$(CONFIG_SUN8I_H3_CCU) += ccu-sun8i-h3.o
obj-$(CONFIG_SUN8I_V3S_CCU) += ccu-sun8i-v3s.o
+obj-$(CONFIG_SUN8I_DE2_CCU) += ccu-sun8i-de2.o
obj-$(CONFIG_SUN8I_R_CCU) += ccu-sun8i-r.o
obj-$(CONFIG_SUN9I_A80_CCU) += ccu-sun9i-a80.o
obj-$(CONFIG_SUN9I_A80_CCU) += ccu-sun9i-a80-de.o
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-de2.c b/drivers/clk/sunxi-ng/ccu-sun8i-de2.c
new file mode 100644
index 000000000000..adb2c344692a
--- /dev/null
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-de2.c
@@ -0,0 +1,218 @@
+/*
+ * Copyright (c) 2017 Icenowy Zheng <icenowy@aosc.io>
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/reset.h>
+
+#include "ccu_common.h"
+#include "ccu_div.h"
+#include "ccu_gate.h"
+#include "ccu_reset.h"
+
+#include "ccu-sun8i-de2.h"
+
+static SUNXI_CCU_GATE(bus_mixer0_clk, "bus-mixer0", "bus-de",
+ 0x04, BIT(0), 0);
+static SUNXI_CCU_GATE(bus_mixer1_clk, "bus-mixer1", "bus-de",
+ 0x04, BIT(1), 0);
+static SUNXI_CCU_GATE(bus_wb_clk, "bus-wb", "bus-de",
+ 0x04, BIT(2), 0);
+
+static SUNXI_CCU_GATE(mixer0_clk, "mixer0", "mixer0-div",
+ 0x00, BIT(0), CLK_SET_RATE_PARENT);
+static SUNXI_CCU_GATE(mixer1_clk, "mixer1", "mixer1-div",
+ 0x00, BIT(1), CLK_SET_RATE_PARENT);
+static SUNXI_CCU_GATE(wb_clk, "wb", "wb-div",
+ 0x00, BIT(2), CLK_SET_RATE_PARENT);
+
+static SUNXI_CCU_M(mixer0_div_clk, "mixer0-div", "de", 0x0c, 0, 4,
+ CLK_SET_RATE_PARENT);
+static SUNXI_CCU_M(mixer1_div_clk, "mixer1-div", "de", 0x0c, 4, 4,
+ CLK_SET_RATE_PARENT);
+static SUNXI_CCU_M(wb_div_clk, "wb-div", "de", 0x0c, 8, 4,
+ CLK_SET_RATE_PARENT);
+
+static struct ccu_common *sunxi_de2_clks[] = {
+ &mixer0_clk.common,
+ &mixer1_clk.common,
+ &wb_clk.common,
+
+ &bus_mixer0_clk.common,
+ &bus_mixer1_clk.common,
+ &bus_wb_clk.common,
+
+ &mixer0_div_clk.common,
+ &mixer1_div_clk.common,
+ &wb_div_clk.common,
+};
+
+static struct clk_hw_onecell_data sunxi_de2_hw_clks = {
+ .hws = {
+ [CLK_MIXER0] = &mixer0_clk.common.hw,
+ [CLK_MIXER1] = &mixer1_clk.common.hw,
+ [CLK_WB] = &wb_clk.common.hw,
+
+ [CLK_BUS_MIXER0] = &bus_mixer0_clk.common.hw,
+ [CLK_BUS_MIXER1] = &bus_mixer1_clk.common.hw,
+ [CLK_BUS_WB] = &bus_wb_clk.common.hw,
+
+ [CLK_MIXER0_DIV] = &mixer0_div_clk.common.hw,
+ [CLK_MIXER1_DIV] = &mixer1_div_clk.common.hw,
+ [CLK_WB_DIV] = &wb_div_clk.common.hw,
+ },
+ .num = CLK_NUMBER,
+};
+
+static struct ccu_reset_map sun8i_a83t_de2_resets[] = {
+ [RST_MIXER0] = { 0x08, BIT(0) },
+ /*
+ * For A83T, H3 and R40, mixer1 reset line is shared with wb, so
+ * only RST_WB is exported here.
+ */
+ [RST_WB] = { 0x08, BIT(2) },
+};
+
+static struct ccu_reset_map sun50i_a64_de2_resets[] = {
+ [RST_MIXER0] = { 0x08, BIT(0) },
+ [RST_MIXER1] = { 0x08, BIT(1) },
+ [RST_WB] = { 0x08, BIT(2) },
+};
+
+static const struct sunxi_ccu_desc sun8i_a83t_de2_clk_desc = {
+ .ccu_clks = sunxi_de2_clks,
+ .num_ccu_clks = ARRAY_SIZE(sunxi_de2_clks),
+
+ .hw_clks = &sunxi_de2_hw_clks,
+
+ .resets = sun8i_a83t_de2_resets,
+ .num_resets = ARRAY_SIZE(sun8i_a83t_de2_resets),
+};
+
+static const struct sunxi_ccu_desc sun50i_a64_de2_clk_desc = {
+ .ccu_clks = sunxi_de2_clks,
+ .num_ccu_clks = ARRAY_SIZE(sunxi_de2_clks),
+
+ .hw_clks = &sunxi_de2_hw_clks,
+
+ .resets = sun50i_a64_de2_resets,
+ .num_resets = ARRAY_SIZE(sun50i_a64_de2_resets),
+};
+
+static int sunxi_de2_clk_probe(struct platform_device *pdev)
+{
+ struct resource *res;
+ struct clk *bus_clk, *mod_clk;
+ struct reset_control *rstc;
+ void __iomem *reg;
+ const struct sunxi_ccu_desc *ccu_desc;
+ int ret;
+
+ ccu_desc = of_device_get_match_data(&pdev->dev);
+ if (!ccu_desc)
+ return -EINVAL;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ reg = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(reg))
+ return PTR_ERR(reg);
+
+ bus_clk = devm_clk_get(&pdev->dev, "bus");
+ if (IS_ERR(bus_clk)) {
+ ret = PTR_ERR(bus_clk);
+ if (ret != -EPROBE_DEFER)
+ dev_err(&pdev->dev, "Couldn't get bus clk: %d\n", ret);
+ return ret;
+ }
+
+ mod_clk = devm_clk_get(&pdev->dev, "mod");
+ if (IS_ERR(mod_clk)) {
+ ret = PTR_ERR(mod_clk);
+ if (ret != -EPROBE_DEFER)
+ dev_err(&pdev->dev, "Couldn't get mod clk: %d\n", ret);
+ return ret;
+ }
+
+ rstc = devm_reset_control_get_exclusive(&pdev->dev, NULL);
+ if (IS_ERR(rstc)) {
+ ret = PTR_ERR(bus_clk);
+ if (ret != -EPROBE_DEFER)
+ dev_err(&pdev->dev,
+ "Couldn't get reset control: %d\n", ret);
+ return ret;
+ }
+
+ /* The clocks need to be enabled for us to access the registers */
+ ret = clk_prepare_enable(bus_clk);
+ if (ret) {
+ dev_err(&pdev->dev, "Couldn't enable bus clk: %d\n", ret);
+ return ret;
+ }
+
+ ret = clk_prepare_enable(mod_clk);
+ if (ret) {
+ dev_err(&pdev->dev, "Couldn't enable mod clk: %d\n", ret);
+ return ret;
+ }
+
+ /* The reset control needs to be asserted for the controls to work */
+ ret = reset_control_deassert(rstc);
+ if (ret) {
+ dev_err(&pdev->dev,
+ "Couldn't deassert reset control: %d\n", ret);
+ goto err_disable_clk;
+ }
+
+ ret = sunxi_ccu_probe(pdev->dev.of_node, reg, ccu_desc);
+ if (ret)
+ goto err_assert_reset;
+
+ return 0;
+
+err_assert_reset:
+ reset_control_assert(rstc);
+err_disable_clk:
+ clk_disable_unprepare(bus_clk);
+ return ret;
+}
+
+static const struct of_device_id sunxi_de2_clk_ids[] = {
+ {
+ .compatible = "allwinner,sun8i-a83t-de2-clk",
+ .data = &sun8i_a83t_de2_clk_desc,
+ },
+ {
+ .compatible = "allwinner,sun50i-h5-de2-clk",
+ .data = &sun50i_a64_de2_clk_desc,
+ },
+ /*
+ * The Allwinner A64 SoC needs some bit to be poke in syscon to make
+ * DE2 really working.
+ * So there's currently no A64 compatible here.
+ * H5 shares the same reset line with A64, so here H5 is using the
+ * clock description of A64.
+ */
+ { }
+};
+
+static struct platform_driver sunxi_de2_clk_driver = {
+ .probe = sunxi_de2_clk_probe,
+ .driver = {
+ .name = "sunxi-de2-clks",
+ .of_match_table = sunxi_de2_clk_ids,
+ },
+};
+builtin_platform_driver(sunxi_de2_clk_driver);
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-de2.h b/drivers/clk/sunxi-ng/ccu-sun8i-de2.h
new file mode 100644
index 000000000000..530c006e0ae9
--- /dev/null
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-de2.h
@@ -0,0 +1,28 @@
+/*
+ * Copyright 2016 Icenowy Zheng <icenowy@aosc.io>
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef _CCU_SUN8I_DE2_H_
+#define _CCU_SUN8I_DE2_H_
+
+#include <dt-bindings/clock/sun8i-de2.h>
+#include <dt-bindings/reset/sun8i-de2.h>
+
+/* Intermediary clock dividers are not exported */
+#define CLK_MIXER0_DIV 3
+#define CLK_MIXER1_DIV 4
+#define CLK_WB_DIV 5
+
+#define CLK_NUMBER (CLK_WB + 1)
+
+#endif /* _CCU_SUN8I_DE2_H_ */
--
2.12.2
^ permalink raw reply related
* [PATCH 03/13] dt-bindings: add bindings for DE2 on V3s SoC
From: Icenowy Zheng @ 2017-05-04 11:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170504114208.8524-1-icenowy@aosc.io>
Allwinner V3s SoC have a display engine which have a different pipeline
with older SoCs.
Add document for it (new compatibles and the new "mixer" part).
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Acked-by: Rob Herring <robh@kernel.org>
---
.../bindings/display/sunxi/sun4i-drm.txt | 29 ++++++++++++++++++++--
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index 7acdbf14ae1c..33452884b96e 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -41,6 +41,7 @@ Required properties:
* allwinner,sun6i-a31-tcon
* allwinner,sun6i-a31s-tcon
* allwinner,sun8i-a33-tcon
+ * allwinner,sun8i-v3s-tcon
- reg: base address and size of memory-mapped region
- interrupts: interrupt associated to this IP
- clocks: phandles to the clocks feeding the TCON. Three are needed:
@@ -62,7 +63,7 @@ Required properties:
second the block connected to the TCON channel 1 (usually the TV
encoder)
-On SoCs other than the A33, there is one more clock required:
+On SoCs other than the A33 and V3s, there is one more clock required:
- 'tcon-ch1': The clock driving the TCON channel 1
DRC
@@ -148,6 +149,26 @@ Required properties:
Documentation/devicetree/bindings/media/video-interfaces.txt. The
first port should be the input endpoints, the second one the outputs
+Display Engine 2.0 Mixer
+------------------------
+
+The DE2 mixer have many functionalities, currently only layer blending is
+supported.
+
+Required properties:
+ - compatible: value must be one of:
+ * allwinner,sun8i-v3s-de2-mixer
+ - reg: base address and size of the memory-mapped region.
+ - clocks: phandles to the clocks feeding the frontend and backend
+ * bus: the backend interface clock
+ * ram: the backend DRAM clock
+ - clock-names: the clock names mentioned above
+ - resets: phandles to the reset controllers driving the backend
+
+- ports: A ports node with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt. The
+ first port should be the input endpoints, the second one the output
+
Display Engine Pipeline
-----------------------
@@ -162,9 +183,13 @@ Required properties:
* allwinner,sun6i-a31-display-engine
* allwinner,sun6i-a31s-display-engine
* allwinner,sun8i-a33-display-engine
+ * allwinner,sun8i-v3s-display-engine
- allwinner,pipelines: list of phandle to the display engine
- frontends available.
+ pipeline entry point. For SoCs with original DE (currently
+ all SoCs supported by display engine except V3s), this
+ phandle should be a display frontend; for SoCs with DE2,
+ this phandle should be a mixer.
Example:
--
2.12.2
^ permalink raw reply related
* [PATCH 04/13] drm/sun4i: return only planes for layers created
From: Icenowy Zheng @ 2017-05-04 11:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170504114208.8524-1-icenowy@aosc.io>
As we are going to add support for the Allwinner DE2 Mixer in sun4i-drm
driver, we will finally have two types of layers.
Each layer is bound to a drm_plane that is CRTC-specific, so we create
them when initializing CRTC (calling sun4i_layers_init, which will be
generalized in next patch). The drm_plane's will be used when creating
CRTC, but the CRTC initialization code do not care other properties of
the layer, so we let the sun4i_layers_init function return drm_plane's
only.
As we have no need to trace the layers after the CRTC is properly
created, we drop the layers pointer in sun4i_crtc struct.
Doing these things makes the CRTC code independent to the type of layer
(the sun4i_layers_init function name is still hardcoded and will be
changed in the next patch), so that we can finally gain support for the
mixer in DE2, which will has different layers.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
drivers/gpu/drm/sun4i/sun4i_crtc.c | 23 ++++++++++++-----------
drivers/gpu/drm/sun4i/sun4i_crtc.h | 1 -
drivers/gpu/drm/sun4i/sun4i_layer.c | 18 ++++++++++--------
drivers/gpu/drm/sun4i/sun4i_layer.h | 4 ++--
4 files changed, 24 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_crtc.c b/drivers/gpu/drm/sun4i/sun4i_crtc.c
index 3c876c3a356a..708b3543d4e9 100644
--- a/drivers/gpu/drm/sun4i/sun4i_crtc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_crtc.c
@@ -139,6 +139,7 @@ struct sun4i_crtc *sun4i_crtc_init(struct drm_device *drm,
struct sun4i_tcon *tcon)
{
struct sun4i_crtc *scrtc;
+ struct drm_plane **planes;
struct drm_plane *primary = NULL, *cursor = NULL;
int ret, i;
@@ -149,22 +150,22 @@ struct sun4i_crtc *sun4i_crtc_init(struct drm_device *drm,
scrtc->tcon = tcon;
/* Create our layers */
- scrtc->layers = sun4i_layers_init(drm, scrtc->backend);
- if (IS_ERR(scrtc->layers)) {
+ planes = sun4i_layers_init(drm, scrtc);
+ if (IS_ERR(planes)) {
dev_err(drm->dev, "Couldn't create the planes\n");
return NULL;
}
/* find primary and cursor planes for drm_crtc_init_with_planes */
- for (i = 0; scrtc->layers[i]; i++) {
- struct sun4i_layer *layer = scrtc->layers[i];
+ for (i = 0; planes[i]; i++) {
+ struct drm_plane *plane = planes[i];
- switch (layer->plane.type) {
+ switch (plane->type) {
case DRM_PLANE_TYPE_PRIMARY:
- primary = &layer->plane;
+ primary = plane;
break;
case DRM_PLANE_TYPE_CURSOR:
- cursor = &layer->plane;
+ cursor = plane;
break;
default:
break;
@@ -188,12 +189,12 @@ struct sun4i_crtc *sun4i_crtc_init(struct drm_device *drm,
1);
/* Set possible_crtcs to this crtc for overlay planes */
- for (i = 0; scrtc->layers[i]; i++) {
+ for (i = 0; planes[i]; i++) {
uint32_t possible_crtcs = BIT(drm_crtc_index(&scrtc->crtc));
- struct sun4i_layer *layer = scrtc->layers[i];
+ struct drm_plane *plane = planes[i];
- if (layer->plane.type == DRM_PLANE_TYPE_OVERLAY)
- layer->plane.possible_crtcs = possible_crtcs;
+ if (plane->type == DRM_PLANE_TYPE_OVERLAY)
+ plane->possible_crtcs = possible_crtcs;
}
return scrtc;
diff --git a/drivers/gpu/drm/sun4i/sun4i_crtc.h b/drivers/gpu/drm/sun4i/sun4i_crtc.h
index 230cb8f0d601..4dae3508424a 100644
--- a/drivers/gpu/drm/sun4i/sun4i_crtc.h
+++ b/drivers/gpu/drm/sun4i/sun4i_crtc.h
@@ -19,7 +19,6 @@ struct sun4i_crtc {
struct sun4i_backend *backend;
struct sun4i_tcon *tcon;
- struct sun4i_layer **layers;
};
static inline struct sun4i_crtc *drm_crtc_to_sun4i_crtc(struct drm_crtc *crtc)
diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.c b/drivers/gpu/drm/sun4i/sun4i_layer.c
index f26bde5b9117..e1f03e1cc0ac 100644
--- a/drivers/gpu/drm/sun4i/sun4i_layer.c
+++ b/drivers/gpu/drm/sun4i/sun4i_layer.c
@@ -16,6 +16,7 @@
#include <drm/drmP.h>
#include "sun4i_backend.h"
+#include "sun4i_crtc.h"
#include "sun4i_layer.h"
struct sun4i_plane_desc {
@@ -128,15 +129,16 @@ static struct sun4i_layer *sun4i_layer_init_one(struct drm_device *drm,
return layer;
}
-struct sun4i_layer **sun4i_layers_init(struct drm_device *drm,
- struct sun4i_backend *backend)
+struct drm_plane **sun4i_layers_init(struct drm_device *drm,
+ struct sun4i_crtc *crtc)
{
- struct sun4i_layer **layers;
+ struct drm_plane **planes;
+ struct sun4i_backend *backend = crtc->backend;
int i;
- layers = devm_kcalloc(drm->dev, ARRAY_SIZE(sun4i_backend_planes) + 1,
- sizeof(*layers), GFP_KERNEL);
- if (!layers)
+ planes = devm_kcalloc(drm->dev, ARRAY_SIZE(sun4i_backend_planes) + 1,
+ sizeof(*planes), GFP_KERNEL);
+ if (!planes)
return ERR_PTR(-ENOMEM);
/*
@@ -178,8 +180,8 @@ struct sun4i_layer **sun4i_layers_init(struct drm_device *drm,
SUN4I_BACKEND_ATTCTL_REG0_LAY_PIPESEL(plane->pipe));
layer->id = i;
- layers[i] = layer;
+ planes[i] = &layer->plane;
};
- return layers;
+ return planes;
}
diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.h b/drivers/gpu/drm/sun4i/sun4i_layer.h
index 4be1f0919df2..5ea5c994d6ea 100644
--- a/drivers/gpu/drm/sun4i/sun4i_layer.h
+++ b/drivers/gpu/drm/sun4i/sun4i_layer.h
@@ -26,7 +26,7 @@ plane_to_sun4i_layer(struct drm_plane *plane)
return container_of(plane, struct sun4i_layer, plane);
}
-struct sun4i_layer **sun4i_layers_init(struct drm_device *drm,
- struct sun4i_backend *backend);
+struct drm_plane **sun4i_layers_init(struct drm_device *drm,
+ struct sun4i_crtc *crtc);
#endif /* _SUN4I_LAYER_H_ */
--
2.12.2
^ permalink raw reply related
* [PATCH] ARM: dts: imx6sx-sdb: Remove cpufreq OPP override
From: Shawn Guo @ 2017-05-04 11:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <HE1PR04MB1450DA079FC35180FBE305388B100@HE1PR04MB1450.eurprd04.prod.outlook.com>
On Thu, Apr 27, 2017 at 01:17:12AM +0000, Peter Chen wrote:
>
> >
> >The board file for imx6sx-dbg overrides cpufreq operating points to use higher
> >voltages. This is done because the board has a shared rail for VDD_ARM_IN and
> >VDD_SOC_IN and when using LDO bypass the shared voltage needs to be a value
> >suitable for both ARM and SOC.
> >
> >This was introduced in:
> >
> >commit 54183bd7f766 ("ARM: imx6sx-sdb: add revb board and make it default")
> >
> >This only only applies to LDO bypass mode, a feature not present in upstream. When
> >LDOs are enabled the effect is to use higher voltages than necesarry for no good
> >reason.
> >
> >Setting these higher voltages can make some boards fail to boot with ugly semi-
> >random crashes, reminiscent of memory corruption. These failures happen the first
> >time the lowest idle state is used. Remove the OPP override in order to fix those
> >crashes.
> >
>
> Add Anson and Robin
>
> This code has existed more than 2 years, it is strange why the bug has not reported both
> for internal user and external user. I run upstream kernel using imx6sx-sdb revB very often
> at recent years, but not meet this issue. How to trigger this unstable issue, anything needs
> to change at u-boot?
Per comments from Henri and Leonard, it sounds like the issue only
happens on RevC board?
Shawn
^ permalink raw reply
* [PATCH v6 00/24] vITS save/restore
From: Eric Auger @ 2017-05-04 11:44 UTC (permalink / raw)
To: linux-arm-kernel
This series specifies and implements an API aimed at saving and restoring
the state of the in-kernel emulated ITS device.
The ITS is programmed through registers and tables. Those latter
are allocated by the guest. Their base address is programmed in
registers or table entries before the ITS is enabled.
The ITS is free to use some of them to flush its internal caches. This
is likely to be used when entering low power state.
Therefore, for save/restore use case, it looks natural to use this
guest RAM allocated space to save the table related data. However,
currently, The ITS in-kernel emulated device does not use all of those
tables and for those it uses, it does not always sync them with its
cached data. Additional sync must happen for:
- the collection table
- the device table
- the per-device translation tables
- the LPI pending tables.
The LPI configation table and the command queues do not need extra
syncs.
Best Regards
Eric
Git: complete series available at
https://github.com/eauger/linux/tree/v4.11-its-mig-v6
* Testing:
- on Cavium ThunderX using a virtio-net-pci guest,
virsh save/restore commands and virt-manager live migration.
Tested with 1 and 2 stage device table.
History:
v5 -> v6:
- address Christoffer's comments:
- add restore sequence in the doc
- sync with pending and config tables in its_add_lpi
- change in return values when scanning the tables
- several bug fixes pointed out by Christoffer
- see full details in individual logs
v4 -> v5:
- user API changes:
- ITS table save/restore triggered through ITS KVM device
KVM_DEV_ARM_VGIC_GRP_CTRL group, KVM_DEV_ARM_ITS_SAVE_TABLES,
KVM_DEV_ARM_ITS_RESTORE_TABLES
- RDIST pending table flush triggered through GICV3 KVM device
KVM_DEV_ARM_VGIC_GRP_CTRL/KVM_DEV_ARM_VGIC_SAVE_PENDING_TABLES
- Introduce an ABI infrastructure, entry size report using this infra
- IIDR reports ABI chosen set by userspace if any
- pending table save moved to vgic-v3.c
- use optimisation in pending table save
- check target_addr when restore cte
- pending table sync called from restore_tables
- added KVM: arm64: vgic-its: Fix pending table sync
- simplify loopup_table and use kvm_read_guest()
- sort the device and ITE list on save
- add defines for shifts and masks, GIC_ENCODE_SZ macro
v3 -> v4:
- update the DTE format (ITT_addr 52 bit support, validity bit addition)
- Document ABI revision and implement check
- iidr save/restore (including a new patch for iidr user write access)
- changed locking: kvm lock + vcpu lock
- fix nb_eventid_bits mixup
- 2 new patches aiming at exposing next_segment() and lock_all_vcpus()
- rework errror handling of lookup_table functions
- I took into account all Andre's comments/suggestions except:
- trigger the save/restore of pending tables from GICV3 KVM device
instead of ITS KVM device
- implement ITS flush/restore in KVM_DEV_ARM_VGIC_GRP_CTRL
ITS group
See the ML replies for current justifications. In case other people
strongly disagree of course I will change the code.
v2 -> v3:
- fix restore ITS ITT_addr bit masking
v1 -> v2:
- rebased on Vijaya's v11
- all entries now are 8 byte large
- devid/eventid indexing for device table and ITT
- support 2 stage device table
- common infra to read indexed tables
- add cpu <-> le64 conversions
- itte renamed into ite
- do not care anymore about pending table 1st KB
(not needed at the moment for coarse mapping)
RFC v1
- creation
Eric Auger (24):
KVM: arm/arm64: Add ITS save/restore API documentation
KVM: arm/arm64: Add GICV3 pending table save API documentation
KVM: arm/arm64: vgic-its: rename itte into ite
arm/arm64: vgic: turn vgic_find_mmio_region into public
KVM: arm64: vgic-its: KVM_DEV_ARM_VGIC_GRP_ITS_REGS group
KVM: arm/arm64: vgic: expose (un)lock_all_vcpus
KVM: arm64: vgic-its: Implement vgic_its_has_attr_regs and
attr_regs_access
KVM: arm64: vgic-its: Implement vgic_mmio_uaccess_write_its_creadr
KVM: arm64: vgic-its: Introduce migration ABI infrastructure
KVM: arm64: vgic-its: Implement vgic_mmio_uaccess_write_its_iidr
KVM: arm64: vgic-its: Interpret MAPD Size field and check related
errors
KVM: arm64: vgic-its: Interpret MAPD ITT_addr field
KVM: arm64: vgic-its: Check the device id matches TYPER DEVBITS range
KVM: arm64: vgic-v3: vgic_v3_lpi_sync_pending_status
KVM: arm64: vgic-its: Read config and pending bit in add_lpi()
KVM: arm64: vgic-its: KVM_DEV_ARM_ITS_SAVE/RESTORE_TABLES
KVM: arm64: vgic-its: vgic_its_alloc_ite/device
KVM: arm64: vgic-its: Add infrastructure for table lookup
KVM: arm64: vgic-its: Collection table save/restore
KVM: arm64: vgic-its: vgic_its_check_id returns the entry's GPA
KVM: arm64: vgic-its: Device table save/restore
KVM: arm64: vgic-its: ITT save and restore
KVM: arm64: vgic-its: Fix pending table sync
KVM: arm64: vgic-v3: KVM_DEV_ARM_VGIC_SAVE_PENDING_TABLES
Documentation/virtual/kvm/devices/arm-vgic-its.txt | 117 ++
Documentation/virtual/kvm/devices/arm-vgic-v3.txt | 6 +
arch/arm/include/uapi/asm/kvm.h | 6 +-
arch/arm64/include/uapi/asm/kvm.h | 6 +-
include/kvm/arm_vgic.h | 3 +
include/linux/irqchip/arm-gic-v3.h | 14 +
virt/kvm/arm/vgic/vgic-its.c | 1148 +++++++++++++++++---
virt/kvm/arm/vgic/vgic-kvm-device.c | 24 +-
virt/kvm/arm/vgic/vgic-mmio.c | 11 +-
virt/kvm/arm/vgic/vgic-mmio.h | 14 +-
virt/kvm/arm/vgic/vgic-v3.c | 95 ++
virt/kvm/arm/vgic/vgic.h | 28 +
12 files changed, 1330 insertions(+), 142 deletions(-)
--
2.5.5
^ permalink raw reply
* [PATCH v6 01/24] KVM: arm/arm64: Add ITS save/restore API documentation
From: Eric Auger @ 2017-05-04 11:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493898284-29504-1-git-send-email-eric.auger@redhat.com>
Add description for how to access ITS registers and how to save/restore
ITS tables into/from memory.
Signed-off-by: Eric Auger <eric.auger@redhat.com>
---
v5 -> v6:
- add restoration ordering
- 256B -> 256 Byte aligned
- DTE Size is number of bits for the EVENTID
- s/GITS_READR/GITS_CREADR
v4 -> v5:
- take into account Christoffer's comments
- pending table save on GICV3 side now
v3 -> v4:
- take into account Peter's comments:
- typos
- KVM_DEV_ARM_VGIC_GRP_ITS_TABLES kvm_device_attr = 0
- add a validity bit in DTE
- document all fields in CTE and ITE
- document ABI revision
- take into account Andre's comments:
- document restrictions about GITS_CREADR writing and GITS_IIDR
- document -EBUSY error if one or more VCPUS are runnning
- document 64b registers only can be accessed with 64b access
- itt_addr field matches bits [51:8] of the itt_addr
v1 -> v2:
- DTE and ITE now are 8 bytes
- DTE and ITE now indexed by deviceid/eventid
- use ITE name instead of ITTE
- mentions ITT_addr matches bits [51:8] of the actual address
- mentions LE layout
---
Documentation/virtual/kvm/devices/arm-vgic-its.txt | 117 +++++++++++++++++++++
1 file changed, 117 insertions(+)
diff --git a/Documentation/virtual/kvm/devices/arm-vgic-its.txt b/Documentation/virtual/kvm/devices/arm-vgic-its.txt
index 6081a5b..863c359 100644
--- a/Documentation/virtual/kvm/devices/arm-vgic-its.txt
+++ b/Documentation/virtual/kvm/devices/arm-vgic-its.txt
@@ -32,7 +32,124 @@ Groups:
KVM_DEV_ARM_VGIC_CTRL_INIT
request the initialization of the ITS, no additional parameter in
kvm_device_attr.addr.
+
+ KVM_DEV_ARM_ITS_SAVE_TABLES
+ save the ITS table data into guest RAM, at the location provisioned
+ by the guest in corresponding registers/table entries.
+
+ The layout of the tables in guest memory defines an ABI. The entries
+ are laid out in little endian format as described in the last paragraph.
+
+ KVM_DEV_ARM_ITS_RESTORE_TABLES
+ restore the ITS tables from guest RAM to ITS internal structures.
+
+ The GICV3 must be restored before the ITS and all ITS registers but
+ the GITS_CTLR must be restored before restoring the ITS tables.
+
+ The GITS_IIDR read-only register must also be restored before
+ the table restore as the IIDR revision field encodes the ABI revision.
+
+ The expected ordering when restoring the GICv3/ITS is described in section
+ "ITS Restoration Sequence".
+
Errors:
-ENXIO: ITS not properly configured as required prior to setting
this attribute
-ENOMEM: Memory shortage when allocating ITS internal data
+ -EINVAL: Inconsistent restored data
+ -EFAULT: Invalid guest ram access
+ -EBUSY: One or more VCPUS are running
+
+ KVM_DEV_ARM_VGIC_GRP_ITS_REGS
+ Attributes:
+ The attr field of kvm_device_attr encodes the offset of the
+ ITS register, relative to the ITS control frame base address
+ (ITS_base).
+
+ kvm_device_attr.addr points to a __u64 value whatever the width
+ of the addressed register (32/64 bits). 64 bit registers can only
+ be accessed with full length.
+
+ Writes to read-only registers are ignored by the kernel except for:
+ - GITS_CREADR. It needs to be restored otherwise commands in the queue
+ will be re-executed after restoring CWRITER. GITS_CREADR must be
+ restored before restoring the GITS_CTLR which is likely to enable the
+ ITS. Also it needs to be restored after GITS_CBASER since a write to
+ GITS_CBASER resets GITS_CREADR.
+ - GITS_IIDR. Its Revision field encodes the table layout ABI revision.
+ In the future we might implement direct injection of virtual LPIS.
+ This will require an upgrade of the table layout and an evolution of
+ the ABI. GITS_IIDR must be restored before the table restoration.
+
+ For other registers, getting or setting a register has the same
+ effect as reading/writing the register on real hardware.
+ Errors:
+ -ENXIO: Offset does not correspond to any supported register
+ -EFAULT: Invalid user pointer for attr->addr
+ -EINVAL: Offset is not 64-bit aligned
+ -EBUSY: one or more VCPUS are running
+
+ ITS Restoration Sequence:
+ -------------------------
+
+The following ordering must be followed when restoring the GIC and the ITS:
+a) restore all guest memory and create vcpus
+b) initialize the GIC and ITS (KVM_DEV_ARM_VGIC_CTRL_INIT)
+c) provide GIC and ITS base addresses (KVM_DEV_ARM_VGIC_GRP_ADDR)
+d) restore all redistributors
+e) restore the ITS in the following order:
+ 1. Restore GITS_CBASER
+ 2. Restore all other GITS_ registers, except GITS_CTLR!
+ 3. Load the ITS table data (KVM_DEV_ARM_ITS_RESTORE_TABLES)
+ 4. Restore GITS_CTLR
+f) start vcpus
+
+ ITS Table ABI REV0:
+ -------------------
+
+ Revision 0 of the ABI only supports physical LPIs.
+
+ The device table and ITT are indexed by the deviceid and eventid,
+ respectively. The collection table is not indexed by collectionid:
+ CTE are written in the table in the order of collection creation. All
+ entries are 8 bytes.
+
+ Device Table Entry (DTE):
+
+ bits: | 63| 62 ... 49 | 48 ... 5 | 4 ... 0 |
+ values: | V | next | ITT_addr | Size |
+
+ where;
+ - V indicates whether the entry is valid. If not, other fields
+ are not meaningful.
+ - next: equals to 0 if this entry is the last one; otherwise it
+ corresponds to the deviceid offset to the next DTE, capped by
+ 2^14 -1.
+ - ITT_addr matches bits [51:8] of the ITT address (256 Byte aligned).
+ - Size specifies the supported number of bits for the eventid,
+ minus one
+
+ Collection Table Entry (CTE):
+
+ bits: | 63| 62 .. 52 | 51 ... 16 | 15 ... 0 |
+ values: | V | RES0 | RDBase | ICID |
+
+ where:
+ - V indicates whether the entry is valid. If not, other fields are
+ not meaningful.
+ - RES0: reserved field with Should-Be-Zero-or-Preserved behavior.
+ - RDBase is the PE number (GICR_TYPER.Processor_Number semantic),
+ - ICID is the collection ID
+
+ Interrupt Translation Entry (ITE):
+
+ bits: | 63 ... 48 | 47 ... 16 | 15 ... 0 |
+ values: | next | pINTID | ICID |
+
+ where:
+ - next: equals to 0 if this entry is the last one; otherwise it corresponds
+ to the eventid offset to the next ITE capped by 2^16 -1.
+ - pINTID is the physical LPI ID; if zero, it means the entry is not valid
+ and other fields are not meaningful.
+ - ICID is the collection ID
+
--
2.5.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