* [PATCH 4/4] dts: arm64: enable mmc3 for supporting sdio feature
From: Yingjoe Chen @ 2016-11-10 2:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478585341-6749-5-git-send-email-yong.mao@mediatek.com>
On Tue, 2016-11-08 at 14:09 +0800, Yong Mao wrote:
> From: yong mao <yong.mao@mediatek.com>
>
> Add description of mmc3 for supporting sdio feature
>
> Signed-off-by: Yong Mao <yong.mao@mediatek.com>
> Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com>
> ---
> arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 82 +++++++++++++++++++++++++++
> 1 file changed, 82 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> index 2a7f731..4dbd299 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> @@ -43,6 +43,14 @@
> enable-active-high;
> };
>
> + sdio_fixed_3v3: fixedregulator at 0 {
This should be regulator at 1 instead of fixedregulator.
> + compatible = "regulator-fixed";
> + regulator-name = "3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + gpio = <&pio 85 GPIO_ACTIVE_HIGH>;
> + };
> +
> connector {
> compatible = "hdmi-connector";
> label = "hdmi";
> @@ -139,6 +147,25 @@
> vqmmc-supply = <&mt6397_vmc_reg>;
> };
>
> +&mmc3 {
> + status = "okay";
> + pinctrl-names = "default", "state_uhs";
> + pinctrl-0 = <&mmc3_pins_default>;
> + pinctrl-1 = <&mmc3_pins_uhs>;
> + bus-width = <4>;
> + max-frequency = <200000000>;
> + cap-sd-highspeed;
> + sd-uhs-sdr50;
> + sd-uhs-sdr104;
> + sdr104-clk-delay = <5>;
> + keep-power-in-suspend;
> + enable-sdio-wakeup;
> + cap-sdio-irq;
> + vmmc-supply = <&sdio_fixed_3v3>;
> + vqmmc-supply = <&mt6397_vgp3_reg>;
> + non-removable;
> +};
> +
> &pio {
> disp_pwm0_pins: disp_pwm0_pins {
> pins1 {
> @@ -197,6 +224,36 @@
> };
> };
>
> + mmc3_pins_default: mmc3default {
Please keep nodes in &pio sorted, move this one after mmc1_pins_uhs.
> + pins_dat {
> + pinmux = <MT8173_PIN_22_MSDC3_DAT0__FUNC_MSDC3_DAT0>,
> + <MT8173_PIN_23_MSDC3_DAT1__FUNC_MSDC3_DAT1>,
> + <MT8173_PIN_24_MSDC3_DAT2__FUNC_MSDC3_DAT2>,
> + <MT8173_PIN_25_MSDC3_DAT3__FUNC_MSDC3_DAT3>;
> + input-enable;
> + drive-strength = <MTK_DRIVE_8mA>;
> + bias-pull-up = <MTK_PUPD_SET_R1R0_10>;
> + };
> +
> + pins_cmd {
> + pinmux = <MT8173_PIN_27_MSDC3_CMD__FUNC_MSDC3_CMD>;
> + input-enable;
> + drive-strength = <MTK_DRIVE_8mA>;
> + bias-pull-up = <MTK_PUPD_SET_R1R0_10>;
> + };
> +
> + pins_clk {
> + pinmux = <MT8173_PIN_26_MSDC3_CLK__FUNC_MSDC3_CLK>;
> + bias-pull-down;
> + drive-strength = <MTK_DRIVE_8mA>;
> + };
> +
> + pins_pdn {
> + pinmux = <MT8173_PIN_85_AUD_DAT_MOSI__FUNC_GPIO85>;
> + output-low;
> + };
This one is used in regulator, not really an mmc pin.
Also, you don't need to add node for gpio usage, request_gpio will set
mode for you.
So please remove pins_pdn node.
> + };
> +
> mmc0_pins_uhs: mmc0 {
> pins_cmd_dat {
> pinmux = <MT8173_PIN_57_MSDC0_DAT0__FUNC_MSDC0_DAT0>,
> @@ -243,6 +300,31 @@
> bias-pull-down = <MTK_PUPD_SET_R1R0_10>;
> };
> };
> +
> + mmc3_pins_uhs: mmc3 {
Please keep nodes in &pio sorted, move this one after mmc1_pins_uhs.
Joe.C
> + pins_dat {
> + pinmux = <MT8173_PIN_22_MSDC3_DAT0__FUNC_MSDC3_DAT0>,
> + <MT8173_PIN_23_MSDC3_DAT1__FUNC_MSDC3_DAT1>,
> + <MT8173_PIN_24_MSDC3_DAT2__FUNC_MSDC3_DAT2>,
> + <MT8173_PIN_25_MSDC3_DAT3__FUNC_MSDC3_DAT3>;
> + input-enable;
> + drive-strength = <MTK_DRIVE_8mA>;
> + bias-pull-up = <MTK_PUPD_SET_R1R0_10>;
> + };
> +
> + pins_cmd {
> + pinmux = <MT8173_PIN_27_MSDC3_CMD__FUNC_MSDC3_CMD>;
> + input-enable;
> + drive-strength = <MTK_DRIVE_8mA>;
> + bias-pull-up = <MTK_PUPD_SET_R1R0_10>;
> + };
> +
> + pins_clk {
> + pinmux = <MT8173_PIN_26_MSDC3_CLK__FUNC_MSDC3_CLK>;
> + drive-strength = <MTK_DRIVE_8mA>;
> + bias-pull-down = <MTK_PUPD_SET_R1R0_10>;
> + };
> + };
> };
>
> &pwm0 {
^ permalink raw reply
* Summary of LPC guest MSI discussion in Santa Fe
From: Will Deacon @ 2016-11-10 2:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109175517.174e7803@t450s.home>
On Wed, Nov 09, 2016 at 05:55:17PM -0700, Alex Williamson wrote:
> On Thu, 10 Nov 2016 01:14:42 +0100
> Auger Eric <eric.auger@redhat.com> wrote:
> > On 10/11/2016 00:59, Alex Williamson wrote:
> > > On Wed, 9 Nov 2016 23:38:50 +0000
> > > Will Deacon <will.deacon@arm.com> wrote:
> > >> On Wed, Nov 09, 2016 at 04:24:58PM -0700, Alex Williamson wrote:
> > >>> The VFIO_IOMMU_MAP_DMA ioctl is a contract, the user ask to map a range
> > >>> of IOVAs to a range of virtual addresses for a given device. If VFIO
> > >>> cannot reasonably fulfill that contract, it must fail. It's up to QEMU
> > >>> how to manage the hotplug and what memory regions it asks VFIO to map
> > >>> for a device, but VFIO must reject mappings that it (or the SMMU by
> > >>> virtue of using the IOMMU API) know to overlap reserved ranges. So I
> > >>> still disagree with the referenced statement. Thanks,
> > >>
> > >> I think that's a pity. Not only does it mean that both QEMU and the kernel
> > >> have more work to do (the former has to carve up its mapping requests,
> > >> whilst the latter has to check that it is indeed doing this), but it also
> > >> precludes the use of hugepage mappings on the IOMMU because of reserved
> > >> regions. For example, a 4k hole someplace may mean we can't put down 1GB
> > >> table entries for the guest memory in the SMMU.
> > >>
> > >> All this seems to do is add complexity and decrease performance. For what?
> > >> QEMU has to go read the reserved regions from someplace anyway. It's also
> > >> the way that VFIO works *today* on arm64 wrt reserved regions, it just has
> > >> no way to identify those holes at present.
> > >
> > > Sure, that sucks, but how is the alternative even an option? The user
> > > asked to map something, we can't, if we allow that to happen now it's a
> > > bug. Put the MSI doorbells somewhere that this won't be an issue. If
> > > the platform has it fixed somewhere that this is an issue, don't use
> > > that platform. The correctness of the interface is more important than
> > > catering to a poorly designed system layout IMO. Thanks,
> >
> > Besides above problematic, I started to prototype the sysfs API. A first
> > issue I face is the reserved regions become global to the iommu instead
> > of characterizing the iommu_domain, ie. the "reserved_regions" attribute
> > file sits below an iommu instance (~
> > /sys/class/iommu/dmar0/intel-iommu/reserved_regions ||
> > /sys/class/iommu/arm-smmu0/arm-smmu/reserved_regions).
> >
> > MSI reserved window can be considered global to the IOMMU. However PCIe
> > host bridge P2P regions rather are per iommu-domain.
I don't think we can treat them as per-domain, given that we want to
enumerate this stuff before we've decided to do a hotplug (and therefore
don't have a domain).
> >
> > Do you confirm the attribute file should contain both global reserved
> > regions and all per iommu_domain reserved regions?
> >
> > Thoughts?
>
> I don't think we have any business describing IOVA addresses consumed
> by peer devices in an IOMMU sysfs file. If it's a separate device it
> should be exposed by examining the rest of the topology. Regions
> consumed by PCI endpoints and interconnects are already exposed in
> sysfs. In fact, is this perhaps a more accurate model for these MSI
> controllers too? Perhaps they should be exposed in the bus topology
> somewhere as consuming the IOVA range. If DMA to an IOVA is consumed
> by an intermediate device before it hits the IOMMU vs not being
> translated as specified by the user at the IOMMU, I'm less inclined to
> call that something VFIO should reject.
Oh, so perhaps we've been talking past each other. In all of these cases,
the SMMU can translate the access if it makes it that far. The issue is
that not all accesses do make it that far, because they may be "consumed"
by another device, such as an MSI doorbell or another endpoint. In other
words, I don't envisage a scenario where e.g. some address range just
bypasses the SMMU straight to memory. I realise now that that's not clear
from the slides I presented.
> However, instantiating a VM
> with holes to account for every potential peer device seems like it
> borders on insanity. Thanks,
Ok, so rather than having a list of reserved regions under the iommu node,
you're proposing that each region is attributed to the device that "owns"
(consumes) it? I think that can work, but we need to make sure that:
(a) The topology is walkable from userspace (where do you start?)
(b) It also works for platform (non-PCI) devices, that lack much in the
way of bus hierarchy
(c) It doesn't require Linux to have a driver bound to a device in order
for the ranges consumed by that device to be advertised (again,
more of an issue for non-PCI).
How is this currently advertised for PCI? I'd really like to use the same
scheme irrespective of the bus type.
Will
^ permalink raw reply
* [PATCH 1/1] arm64: dts: msm8996: Add SCM DT node
From: Stephen Boyd @ 2016-11-10 1:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477700063-18641-1-git-send-email-spjoshi@codeaurora.org>
On 10/28, Sarangdhar Joshi wrote:
> Add SCM DT node to enable SCM functionality on MSM8996.
>
> Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
> ---
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2 1/3] dt-bindings: firmware: scm: Add MSM8996 DT bindings
From: Stephen Boyd @ 2016-11-10 1:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478218237-1737-2-git-send-email-spjoshi@codeaurora.org>
On 11/03, Sarangdhar Joshi wrote:
> Add SCM DT bindings for Qualcomm's MSM8996 platform.
>
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
> ---
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v5 7/8] Documentation: bindings: Add support for Amlogic GXBB SCPI protocol
From: Rob Herring @ 2016-11-10 1:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478148731-11712-8-git-send-email-sudeep.holla@arm.com>
On Wed, Nov 02, 2016 at 10:52:10PM -0600, Sudeep Holla wrote:
> From: Neil Armstrong <narmstrong@baylibre.com>
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> (decoupled from the generic scpi binding)
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> .../devicetree/bindings/arm/amlogic,scpi.txt | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/amlogic,scpi.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol
From: Rob Herring @ 2016-11-10 1:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478148731-11712-7-git-send-email-sudeep.holla@arm.com>
On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote:
> This patch adds specific compatible to support legacy SCPI protocol.
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt
> index d1882c4540d0..ebd03fc93135 100644
> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power operations.
>
> Required properties:
>
> -- compatible : should be "arm,scpi"
> +- compatible : should be
> + * "arm,scpi" : For implementations complying to SCPI v1.0 or above
> + * "arm,legacy-scpi" : For implementations complying pre SCPI v1.0
I'd prefer that we explicitly enumerate the old versions. Are there
many?
Rob
^ permalink raw reply
* [PATCH v5 5/8] Documentation: bindings: decouple juno specific details from generic binding
From: Rob Herring @ 2016-11-10 1:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478148731-11712-6-git-send-email-sudeep.holla@arm.com>
On Wed, Nov 02, 2016 at 10:52:08PM -0600, Sudeep Holla wrote:
> Since SCPI is a generic protocol and the bindings are intended to be
> generic, we need to decouple all the platform specific binding details
> out of the generic bindings.
>
> This patch moves are the Juno platform specific details into a separate
> binding document.
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> Documentation/devicetree/bindings/arm/arm,scpi.txt | 20 ++++++-----------
> .../devicetree/bindings/arm/juno,scpi.txt | 26 ++++++++++++++++++++++
> 2 files changed, 33 insertions(+), 13 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arm/juno,scpi.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH] arm: dts: qcom: Fix ipq board clock rates
From: Stephen Boyd @ 2016-11-10 1:13 UTC (permalink / raw)
To: linux-arm-kernel
The ipq board has these rates as 25MHz, and not 19.2 and 27. I
copy/pasted from other boards that have those rates but forgot
to fix the rates here.
Fixes: 30fc4212d541 ("arm: dts: qcom: Add more board clocks")
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
arch/arm/boot/dts/qcom-ipq8064.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/qcom-ipq8064.dtsi b/arch/arm/boot/dts/qcom-ipq8064.dtsi
index 2e375576ffd0..76f4e8921d58 100644
--- a/arch/arm/boot/dts/qcom-ipq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-ipq8064.dtsi
@@ -65,13 +65,13 @@
cxo_board {
compatible = "fixed-clock";
#clock-cells = <0>;
- clock-frequency = <19200000>;
+ clock-frequency = <25000000>;
};
pxo_board {
compatible = "fixed-clock";
#clock-cells = <0>;
- clock-frequency = <27000000>;
+ clock-frequency = <25000000>;
};
sleep_clk: sleep_clk {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH 1/2] arm64: perf: Move ARMv8 PMU perf event definitions to asm/perf_event.h
From: kbuild test robot @ 2016-11-10 1:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478721480-24852-1-git-send-email-wei@redhat.com>
Hi Wei,
[auto build test ERROR on tip/perf/core]
[also build test ERROR on v4.9-rc4 next-20161109]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Wei-Huang/arm64-perf-Move-ARMv8-PMU-perf-event-definitions-to-asm-perf_event-h/20161110-040107
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64
Note: the linux-review/Wei-Huang/arm64-perf-Move-ARMv8-PMU-perf-event-definitions-to-asm-perf_event-h/20161110-040107 HEAD 72ad64c0d8d13a655312ace104d723c9dd7dc5b0 builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
arch/arm64/kvm/../../../virt/kvm/arm/pmu.c: In function 'kvm_pmu_software_increment':
>> arch/arm64/kvm/../../../virt/kvm/arm/pmu.c:308:16: error: 'ARMV8_PMU_EVTYPE_EVENT_SW_INCR' undeclared (first use in this function)
if ((type == ARMV8_PMU_EVTYPE_EVENT_SW_INCR)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/arm64/kvm/../../../virt/kvm/arm/pmu.c:308:16: note: each undeclared identifier is reported only once for each function it appears in
arch/arm64/kvm/../../../virt/kvm/arm/pmu.c: In function 'kvm_pmu_set_counter_event_type':
arch/arm64/kvm/../../../virt/kvm/arm/pmu.c:382:18: error: 'ARMV8_PMU_EVTYPE_EVENT_SW_INCR' undeclared (first use in this function)
if (eventsel == ARMV8_PMU_EVTYPE_EVENT_SW_INCR)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
vim +/ARMV8_PMU_EVTYPE_EVENT_SW_INCR +308 arch/arm64/kvm/../../../virt/kvm/arm/pmu.c
7a0adc70 Shannon Zhao 2015-09-08 302 enable = vcpu_sys_reg(vcpu, PMCNTENSET_EL0);
7a0adc70 Shannon Zhao 2015-09-08 303 for (i = 0; i < ARMV8_PMU_CYCLE_IDX; i++) {
7a0adc70 Shannon Zhao 2015-09-08 304 if (!(val & BIT(i)))
7a0adc70 Shannon Zhao 2015-09-08 305 continue;
7a0adc70 Shannon Zhao 2015-09-08 306 type = vcpu_sys_reg(vcpu, PMEVTYPER0_EL0 + i)
7a0adc70 Shannon Zhao 2015-09-08 307 & ARMV8_PMU_EVTYPE_EVENT;
7a0adc70 Shannon Zhao 2015-09-08 @308 if ((type == ARMV8_PMU_EVTYPE_EVENT_SW_INCR)
7a0adc70 Shannon Zhao 2015-09-08 309 && (enable & BIT(i))) {
7a0adc70 Shannon Zhao 2015-09-08 310 reg = vcpu_sys_reg(vcpu, PMEVCNTR0_EL0 + i) + 1;
7a0adc70 Shannon Zhao 2015-09-08 311 reg = lower_32_bits(reg);
:::::: The code at line 308 was first introduced by commit
:::::: 7a0adc7064b88609e2917446af8789fac1d4fdd1 arm64: KVM: Add access handler for PMSWINC register
:::::: TO: Shannon Zhao <shannon.zhao@linaro.org>
:::::: CC: Marc Zyngier <marc.zyngier@arm.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 32739 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161110/5b2a68e8/attachment-0001.gz>
^ permalink raw reply
* Summary of LPC guest MSI discussion in Santa Fe
From: Alex Williamson @ 2016-11-10 0:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <83b6440a-31eb-c1b4-642c-a4c311f37ef2@redhat.com>
On Thu, 10 Nov 2016 01:14:42 +0100
Auger Eric <eric.auger@redhat.com> wrote:
> Hi,
>
> On 10/11/2016 00:59, Alex Williamson wrote:
> > On Wed, 9 Nov 2016 23:38:50 +0000
> > Will Deacon <will.deacon@arm.com> wrote:
> >
> >> On Wed, Nov 09, 2016 at 04:24:58PM -0700, Alex Williamson wrote:
> >>> On Wed, 9 Nov 2016 22:25:22 +0000
> >>> Will Deacon <will.deacon@arm.com> wrote:
> >>>
> >>>> On Wed, Nov 09, 2016 at 03:17:09PM -0700, Alex Williamson wrote:
> >>>>> On Wed, 9 Nov 2016 20:31:45 +0000
> >>>>> Will Deacon <will.deacon@arm.com> wrote:
> >>>>>> On Wed, Nov 09, 2016 at 08:23:03PM +0100, Christoffer Dall wrote:
> >>>>>>>
> >>>>>>> (I suppose it's technically possible to get around this issue by letting
> >>>>>>> QEMU place RAM wherever it wants but tell the guest to never use a
> >>>>>>> particular subset of its RAM for DMA, because that would conflict with
> >>>>>>> the doorbell IOVA or be seen as p2p transactions. But I think we all
> >>>>>>> probably agree that it's a disgusting idea.)
> >>>>>>
> >>>>>> Disgusting, yes, but Ben's idea of hotplugging on the host controller with
> >>>>>> firmware tables describing the reserved regions is something that we could
> >>>>>> do in the distant future. In the meantime, I don't think that VFIO should
> >>>>>> explicitly reject overlapping mappings if userspace asks for them.
> >>>>>
> >>>>> I'm confused by the last sentence here, rejecting user mappings that
> >>>>> overlap reserved ranges, such as MSI doorbell pages, is exactly how
> >>>>> we'd reject hot-adding a device when we meet such a conflict. If we
> >>>>> don't reject such a mapping, we're knowingly creating a situation that
> >>>>> potentially leads to data loss. Minimally, QEMU would need to know
> >>>>> about the reserved region, map around it through VFIO, and take
> >>>>> responsibility (somehow) for making sure that region is never used for
> >>>>> DMA. Thanks,
> >>>>
> >>>> Yes, but my point is that it should be up to QEMU to abort the hotplug, not
> >>>> the host kernel, since there may be ways in which a guest can tolerate the
> >>>> overlapping region (e.g. by avoiding that range of memory for DMA).
> >>>
> >>> The VFIO_IOMMU_MAP_DMA ioctl is a contract, the user ask to map a range
> >>> of IOVAs to a range of virtual addresses for a given device. If VFIO
> >>> cannot reasonably fulfill that contract, it must fail. It's up to QEMU
> >>> how to manage the hotplug and what memory regions it asks VFIO to map
> >>> for a device, but VFIO must reject mappings that it (or the SMMU by
> >>> virtue of using the IOMMU API) know to overlap reserved ranges. So I
> >>> still disagree with the referenced statement. Thanks,
> >>
> >> I think that's a pity. Not only does it mean that both QEMU and the kernel
> >> have more work to do (the former has to carve up its mapping requests,
> >> whilst the latter has to check that it is indeed doing this), but it also
> >> precludes the use of hugepage mappings on the IOMMU because of reserved
> >> regions. For example, a 4k hole someplace may mean we can't put down 1GB
> >> table entries for the guest memory in the SMMU.
> >>
> >> All this seems to do is add complexity and decrease performance. For what?
> >> QEMU has to go read the reserved regions from someplace anyway. It's also
> >> the way that VFIO works *today* on arm64 wrt reserved regions, it just has
> >> no way to identify those holes at present.
> >
> > Sure, that sucks, but how is the alternative even an option? The user
> > asked to map something, we can't, if we allow that to happen now it's a
> > bug. Put the MSI doorbells somewhere that this won't be an issue. If
> > the platform has it fixed somewhere that this is an issue, don't use
> > that platform. The correctness of the interface is more important than
> > catering to a poorly designed system layout IMO. Thanks,
>
> Besides above problematic, I started to prototype the sysfs API. A first
> issue I face is the reserved regions become global to the iommu instead
> of characterizing the iommu_domain, ie. the "reserved_regions" attribute
> file sits below an iommu instance (~
> /sys/class/iommu/dmar0/intel-iommu/reserved_regions ||
> /sys/class/iommu/arm-smmu0/arm-smmu/reserved_regions).
>
> MSI reserved window can be considered global to the IOMMU. However PCIe
> host bridge P2P regions rather are per iommu-domain.
>
> Do you confirm the attribute file should contain both global reserved
> regions and all per iommu_domain reserved regions?
>
> Thoughts?
I don't think we have any business describing IOVA addresses consumed
by peer devices in an IOMMU sysfs file. If it's a separate device it
should be exposed by examining the rest of the topology. Regions
consumed by PCI endpoints and interconnects are already exposed in
sysfs. In fact, is this perhaps a more accurate model for these MSI
controllers too? Perhaps they should be exposed in the bus topology
somewhere as consuming the IOVA range. If DMA to an IOVA is consumed
by an intermediate device before it hits the IOMMU vs not being
translated as specified by the user at the IOMMU, I'm less inclined to
call that something VFIO should reject. However, instantiating a VM
with holes to account for every potential peer device seems like it
borders on insanity. Thanks,
Alex
^ permalink raw reply
* [PATCH 08/14] ARM: dts: armada-375: Fixup pcie DT warnings
From: Gregory CLEMENT @ 2016-11-10 0:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110001000.10619-9-gregory.clement@free-electrons.com>
Hi
On jeu., nov. 10 2016, Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:
> PCIe has a ranges property, so the unit name should contain an address.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
> arch/arm/boot/dts/armada-375.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
> index 700d80fe0d85..a157b62e810e 100644
> --- a/arch/arm/boot/dts/armada-375.dtsi
> +++ b/arch/arm/boot/dts/armada-375.dtsi
> @@ -580,7 +580,7 @@
> };
> };
>
> - pciec: pcie-controller at 82000000@ {
> + pciec: pcie-controller at 82000000 {
I don't know what happened but this patch should have been squashed in
the previous one.
I will fix it before applying on the mvebu tree of course.
Gregory
> compatible = "marvell,armada-370-pcie";
> status = "disabled";
> device_type = "pci";
> --
> 2.10.1
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Summary of LPC guest MSI discussion in Santa Fe
From: Auger Eric @ 2016-11-10 0:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109165957.62c1eb61@t450s.home>
Hi,
On 10/11/2016 00:59, Alex Williamson wrote:
> On Wed, 9 Nov 2016 23:38:50 +0000
> Will Deacon <will.deacon@arm.com> wrote:
>
>> On Wed, Nov 09, 2016 at 04:24:58PM -0700, Alex Williamson wrote:
>>> On Wed, 9 Nov 2016 22:25:22 +0000
>>> Will Deacon <will.deacon@arm.com> wrote:
>>>
>>>> On Wed, Nov 09, 2016 at 03:17:09PM -0700, Alex Williamson wrote:
>>>>> On Wed, 9 Nov 2016 20:31:45 +0000
>>>>> Will Deacon <will.deacon@arm.com> wrote:
>>>>>> On Wed, Nov 09, 2016 at 08:23:03PM +0100, Christoffer Dall wrote:
>>>>>>>
>>>>>>> (I suppose it's technically possible to get around this issue by letting
>>>>>>> QEMU place RAM wherever it wants but tell the guest to never use a
>>>>>>> particular subset of its RAM for DMA, because that would conflict with
>>>>>>> the doorbell IOVA or be seen as p2p transactions. But I think we all
>>>>>>> probably agree that it's a disgusting idea.)
>>>>>>
>>>>>> Disgusting, yes, but Ben's idea of hotplugging on the host controller with
>>>>>> firmware tables describing the reserved regions is something that we could
>>>>>> do in the distant future. In the meantime, I don't think that VFIO should
>>>>>> explicitly reject overlapping mappings if userspace asks for them.
>>>>>
>>>>> I'm confused by the last sentence here, rejecting user mappings that
>>>>> overlap reserved ranges, such as MSI doorbell pages, is exactly how
>>>>> we'd reject hot-adding a device when we meet such a conflict. If we
>>>>> don't reject such a mapping, we're knowingly creating a situation that
>>>>> potentially leads to data loss. Minimally, QEMU would need to know
>>>>> about the reserved region, map around it through VFIO, and take
>>>>> responsibility (somehow) for making sure that region is never used for
>>>>> DMA. Thanks,
>>>>
>>>> Yes, but my point is that it should be up to QEMU to abort the hotplug, not
>>>> the host kernel, since there may be ways in which a guest can tolerate the
>>>> overlapping region (e.g. by avoiding that range of memory for DMA).
>>>
>>> The VFIO_IOMMU_MAP_DMA ioctl is a contract, the user ask to map a range
>>> of IOVAs to a range of virtual addresses for a given device. If VFIO
>>> cannot reasonably fulfill that contract, it must fail. It's up to QEMU
>>> how to manage the hotplug and what memory regions it asks VFIO to map
>>> for a device, but VFIO must reject mappings that it (or the SMMU by
>>> virtue of using the IOMMU API) know to overlap reserved ranges. So I
>>> still disagree with the referenced statement. Thanks,
>>
>> I think that's a pity. Not only does it mean that both QEMU and the kernel
>> have more work to do (the former has to carve up its mapping requests,
>> whilst the latter has to check that it is indeed doing this), but it also
>> precludes the use of hugepage mappings on the IOMMU because of reserved
>> regions. For example, a 4k hole someplace may mean we can't put down 1GB
>> table entries for the guest memory in the SMMU.
>>
>> All this seems to do is add complexity and decrease performance. For what?
>> QEMU has to go read the reserved regions from someplace anyway. It's also
>> the way that VFIO works *today* on arm64 wrt reserved regions, it just has
>> no way to identify those holes at present.
>
> Sure, that sucks, but how is the alternative even an option? The user
> asked to map something, we can't, if we allow that to happen now it's a
> bug. Put the MSI doorbells somewhere that this won't be an issue. If
> the platform has it fixed somewhere that this is an issue, don't use
> that platform. The correctness of the interface is more important than
> catering to a poorly designed system layout IMO. Thanks,
Besides above problematic, I started to prototype the sysfs API. A first
issue I face is the reserved regions become global to the iommu instead
of characterizing the iommu_domain, ie. the "reserved_regions" attribute
file sits below an iommu instance (~
/sys/class/iommu/dmar0/intel-iommu/reserved_regions ||
/sys/class/iommu/arm-smmu0/arm-smmu/reserved_regions).
MSI reserved window can be considered global to the IOMMU. However PCIe
host bridge P2P regions rather are per iommu-domain.
Do you confirm the attribute file should contain both global reserved
regions and all per iommu_domain reserved regions?
Thoughts?
Thanks
Eric
>
> Alex
>
> _______________________________________________
> 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 14/14] ARM: dts: armada-375: Fixup ethernet child DT warning
From: Gregory CLEMENT @ 2016-11-10 0:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110001000.10619-1-gregory.clement@free-electrons.com>
Child of mvpp2 ethernet do not have a reg property so the unit name
should not contain an address: remove them.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index 74824a1817b4..d0ea8afa15d0 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -224,13 +224,13 @@
clock-names = "pp_clk", "gop_clk";
status = "disabled";
- eth0: eth0 at c4000 {
+ eth0: eth0 {
interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
port-id = <0>;
status = "disabled";
};
- eth1: eth1 at c5000 {
+ eth1: eth1 {
interrupts = <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
port-id = <1>;
status = "disabled";
--
2.10.1
^ permalink raw reply related
* [PATCH 13/14] ARM: dts: armada-375: Fixup memory DT warning
From: Gregory CLEMENT @ 2016-11-10 0:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110001000.10619-1-gregory.clement@free-electrons.com>
memory has a reg property so the unit name should contain an address.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375-db.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-375-db.dts b/arch/arm/boot/dts/armada-375-db.dts
index 2da6300d184d..2018ccbfd058 100644
--- a/arch/arm/boot/dts/armada-375-db.dts
+++ b/arch/arm/boot/dts/armada-375-db.dts
@@ -58,7 +58,7 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory at 0 {
device_type = "memory";
reg = <0x00000000 0x40000000>; /* 1 GB */
};
--
2.10.1
^ permalink raw reply related
* [PATCH 12/14] ARM: dts: armada-375: Remove skeleton.dtsi
From: Gregory CLEMENT @ 2016-11-10 0:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110001000.10619-1-gregory.clement@free-electrons.com>
The skeleton.dtsi file was removed in ARM64 for different reasons as
explained in commit ("3ebee5a2e141 arm64: dts: kill skeleton.dtsi").
These also applies to ARM and it will also allow to get rid of the
following DTC warnings in the future:
"Node /memory has a reg or ranges property, but no unit name"
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375.dtsi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index 6fa7500df893..74824a1817b4 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -45,7 +45,6 @@
* OTHER DEALINGS IN THE SOFTWARE.
*/
-#include "skeleton.dtsi"
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/phy/phy.h>
@@ -53,6 +52,9 @@
#define MBUS_ID(target,attributes) (((target) << 24) | ((attributes) << 16))
/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
model = "Marvell Armada 375 family SoC";
compatible = "marvell,armada375";
--
2.10.1
^ permalink raw reply related
* [PATCH 11/14] ARM: dts: armada-375: Fixup internal-regs DT warning
From: Gregory CLEMENT @ 2016-11-10 0:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110001000.10619-1-gregory.clement@free-electrons.com>
internal-regs has a ranges property so the unit name should contain an
address.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index d7781554687d..6fa7500df893 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -165,7 +165,7 @@
status = "disabled";
};
- internal-regs {
+ internal-regs at f1000000 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
--
2.10.1
^ permalink raw reply related
* [PATCH 10/14] ARM: dts: armada-375: Fixup soc DT warning
From: Gregory CLEMENT @ 2016-11-10 0:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110001000.10619-1-gregory.clement@free-electrons.com>
soc has a ranges property so the unit name should contain an address.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375-db.dts | 2 +-
arch/arm/boot/dts/armada-375.dtsi | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/armada-375-db.dts b/arch/arm/boot/dts/armada-375-db.dts
index b33a674088ed..2da6300d184d 100644
--- a/arch/arm/boot/dts/armada-375-db.dts
+++ b/arch/arm/boot/dts/armada-375-db.dts
@@ -63,7 +63,7 @@
reg = <0x00000000 0x40000000>; /* 1 GB */
};
- soc {
+ soc at f1000000 {
ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000
MBUS_ID(0x09, 0x09) 0 0xf1100000 0x10000
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index 84ef033aeeed..d7781554687d 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -101,7 +101,7 @@
interrupts-extended = <&mpic 3>;
};
- soc {
+ soc at f1000000 {
compatible = "marvell,armada375-mbus", "simple-bus";
#address-cells = <2>;
#size-cells = <1>;
--
2.10.1
^ permalink raw reply related
* [PATCH 09/14] ARM: dts: armada-375: Fixup pinctrl DT warnings
From: Gregory CLEMENT @ 2016-11-10 0:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110001000.10619-1-gregory.clement@free-electrons.com>
pinctrl has a ranges property, so the unit name should contain an
address.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index a157b62e810e..84ef033aeeed 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -307,7 +307,7 @@
status = "disabled";
};
- pinctrl: pinctrl {
+ pinctrl: pinctrl at 18000 {
compatible = "marvell,mv88f6720-pinctrl";
reg = <0x18000 0x24>;
--
2.10.1
^ permalink raw reply related
* [PATCH 08/14] ARM: dts: armada-375: Fixup pcie DT warnings
From: Gregory CLEMENT @ 2016-11-10 0:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110001000.10619-1-gregory.clement@free-electrons.com>
PCIe has a ranges property, so the unit name should contain an address.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index 700d80fe0d85..a157b62e810e 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -580,7 +580,7 @@
};
};
- pciec: pcie-controller at 82000000@ {
+ pciec: pcie-controller at 82000000 {
compatible = "marvell,armada-370-pcie";
status = "disabled";
device_type = "pci";
--
2.10.1
^ permalink raw reply related
* [PATCH 07/14] ARM: dts: armada-375: Fixup pcie DT warnings
From: Gregory CLEMENT @ 2016-11-10 0:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110001000.10619-1-gregory.clement@free-electrons.com>
PCIe has a range property, so the unit name should contain an address.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index c832ebb40ac4..700d80fe0d85 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -580,7 +580,7 @@
};
};
- pciec: pcie-controller {
+ pciec: pcie-controller at 82000000@ {
compatible = "marvell,armada-370-pcie";
status = "disabled";
device_type = "pci";
--
2.10.1
^ permalink raw reply related
* [PATCH 06/14] ARM: dts: armada-375: Fixup sa-ram DT warning
From: Gregory CLEMENT @ 2016-11-10 0:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110001000.10619-1-gregory.clement@free-electrons.com>
sa-sram which is a mmio-sram has a reg property so the unit name should
contain an address.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index 390575b2142c..c832ebb40ac4 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -635,7 +635,7 @@
};
- crypto_sram0: sa-sram0 {
+ crypto_sram0: sa-sram0 at 0 {
compatible = "mmio-sram";
reg = <MBUS_ID(0x09, 0x09) 0 0x800>;
clocks = <&gateclk 30>;
@@ -644,7 +644,7 @@
ranges = <0 MBUS_ID(0x09, 0x09) 0 0x800>;
};
- crypto_sram1: sa-sram1 {
+ crypto_sram1: sa-sram1 at 0 {
compatible = "mmio-sram";
reg = <MBUS_ID(0x09, 0x05) 0 0x800>;
clocks = <&gateclk 31>;
--
2.10.1
^ permalink raw reply related
* [PATCH 05/14] ARM: dts: armada-375: Fixup devbus DT warning
From: Gregory CLEMENT @ 2016-11-10 0:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110001000.10619-1-gregory.clement@free-electrons.com>
devbus has a reg property so the unit name should contain an address.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375.dtsi | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index e4150c34f128..390575b2142c 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -115,7 +115,7 @@
reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;
};
- devbus_bootcs: devbus-bootcs {
+ devbus_bootcs: devbus-bootcs at 10400 {
compatible = "marvell,mvebu-devbus";
reg = <MBUS_ID(0xf0, 0x01) 0x10400 0x8>;
ranges = <0 MBUS_ID(0x01, 0x2f) 0 0xffffffff>;
@@ -125,7 +125,7 @@
status = "disabled";
};
- devbus_cs0: devbus-cs0 {
+ devbus_cs0: devbus-cs0 at 10408 {
compatible = "marvell,mvebu-devbus";
reg = <MBUS_ID(0xf0, 0x01) 0x10408 0x8>;
ranges = <0 MBUS_ID(0x01, 0x3e) 0 0xffffffff>;
@@ -135,7 +135,7 @@
status = "disabled";
};
- devbus_cs1: devbus-cs1 {
+ devbus_cs1: devbus-cs1 at 10410 {
compatible = "marvell,mvebu-devbus";
reg = <MBUS_ID(0xf0, 0x01) 0x10410 0x8>;
ranges = <0 MBUS_ID(0x01, 0x3d) 0 0xffffffff>;
@@ -145,7 +145,7 @@
status = "disabled";
};
- devbus_cs2: devbus-cs2 {
+ devbus_cs2: devbus-cs2 at 10418 {
compatible = "marvell,mvebu-devbus";
reg = <MBUS_ID(0xf0, 0x01) 0x10418 0x8>;
ranges = <0 MBUS_ID(0x01, 0x3b) 0 0xffffffff>;
@@ -155,7 +155,7 @@
status = "disabled";
};
- devbus_cs3: devbus-cs3 {
+ devbus_cs3: devbus-cs3 at 10420 {
compatible = "marvell,mvebu-devbus";
reg = <MBUS_ID(0xf0, 0x01) 0x10420 0x8>;
ranges = <0 MBUS_ID(0x01, 0x37) 0 0xffffffff>;
--
2.10.1
^ permalink raw reply related
* [PATCH 04/14] ARM: dts: armada-375: Fixup bootrom DT warning
From: Gregory CLEMENT @ 2016-11-10 0:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110001000.10619-1-gregory.clement@free-electrons.com>
bootrom has a reg property so the unit name should contain an address.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index 97b663d83fb6..e4150c34f128 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -110,7 +110,7 @@
pcie-mem-aperture = <0xe0000000 0x8000000>;
pcie-io-aperture = <0xe8000000 0x100000>;
- bootrom {
+ bootrom at 0 {
compatible = "marvell,bootrom";
reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;
};
--
2.10.1
^ permalink raw reply related
* [PATCH 03/14] ARM: dts: armada-375: Fixup mdio DT warning
From: Gregory CLEMENT @ 2016-11-10 0:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110001000.10619-1-gregory.clement@free-electrons.com>
MDIO has a reg property so the unit name should contain an address.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index e016ff3ed970..97b663d83fb6 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -203,7 +203,7 @@
<0xc100 0x100>;
};
- mdio: mdio {
+ mdio: mdio at c0054 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "marvell,orion-mdio";
--
2.10.1
^ permalink raw reply related
* [PATCH 02/14] ARM: dts: armada-375: Use the node labels
From: Gregory CLEMENT @ 2016-11-10 0:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110001000.10619-1-gregory.clement@free-electrons.com>
Use the node label when possible. As a result it flattens the device tree
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375-db.dts | 269 ++++++++++++++++++------------------
1 file changed, 136 insertions(+), 133 deletions(-)
diff --git a/arch/arm/boot/dts/armada-375-db.dts b/arch/arm/boot/dts/armada-375-db.dts
index cded5f0a262d..b33a674088ed 100644
--- a/arch/arm/boot/dts/armada-375-db.dts
+++ b/arch/arm/boot/dts/armada-375-db.dts
@@ -69,138 +69,141 @@
MBUS_ID(0x09, 0x09) 0 0xf1100000 0x10000
MBUS_ID(0x09, 0x05) 0 0xf1110000 0x10000>;
- internal-regs {
- spi at 10600 {
- pinctrl-0 = <&spi0_pins>;
- pinctrl-names = "default";
- /*
- * SPI conflicts with NAND, so we disable it
- * here, and select NAND as the enabled device
- * by default.
- */
- status = "disabled";
-
- spi-flash at 0 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "n25q128a13", "jedec,spi-nor";
- reg = <0>; /* Chip select 0 */
- spi-max-frequency = <108000000>;
- };
- };
-
- i2c at 11000 {
- status = "okay";
- clock-frequency = <100000>;
- pinctrl-0 = <&i2c0_pins>;
- pinctrl-names = "default";
- };
-
- i2c at 11100 {
- status = "okay";
- clock-frequency = <100000>;
- pinctrl-0 = <&i2c1_pins>;
- pinctrl-names = "default";
- };
-
- serial at 12000 {
- status = "okay";
- };
-
- pinctrl {
- sdio_st_pins: sdio-st-pins {
- marvell,pins = "mpp44", "mpp45";
- marvell,function = "gpio";
- };
- };
-
- sata at a0000 {
- status = "okay";
- nr-ports = <2>;
- };
-
- nand: nand at d0000 {
- pinctrl-0 = <&nand_pins>;
- pinctrl-names = "default";
- status = "okay";
- num-cs = <1>;
- marvell,nand-keep-config;
- marvell,nand-enable-arbiter;
- nand-on-flash-bbt;
- nand-ecc-strength = <4>;
- nand-ecc-step-size = <512>;
-
- partition at 0 {
- label = "U-Boot";
- reg = <0 0x800000>;
- };
- partition at 800000 {
- label = "Linux";
- reg = <0x800000 0x800000>;
- };
- partition at 1000000 {
- label = "Filesystem";
- reg = <0x1000000 0x3f000000>;
- };
- };
-
- usb at 54000 {
- status = "okay";
- };
-
- usb3 at 58000 {
- status = "okay";
- };
-
- mvsdio at d4000 {
- pinctrl-0 = <&sdio_pins &sdio_st_pins>;
- pinctrl-names = "default";
- status = "okay";
- cd-gpios = <&gpio1 12 GPIO_ACTIVE_HIGH>;
- wp-gpios = <&gpio1 13 GPIO_ACTIVE_HIGH>;
- };
-
- mdio {
- phy0: ethernet-phy at 0 {
- reg = <0>;
- };
-
- phy3: ethernet-phy at 3 {
- reg = <3>;
- };
- };
-
- ethernet at f0000 {
- status = "okay";
-
- eth0 at c4000 {
- status = "okay";
- phy = <&phy0>;
- phy-mode = "rgmii-id";
- };
-
- eth1 at c5000 {
- status = "okay";
- phy = <&phy3>;
- phy-mode = "gmii";
- };
- };
- };
-
- pcie-controller {
- status = "okay";
- /*
- * The two PCIe units are accessible through
- * standard PCIe slots on the board.
- */
- pcie at 1,0 {
- /* Port 0, Lane 0 */
- status = "okay";
- };
- pcie at 2,0 {
- /* Port 1, Lane 0 */
- status = "okay";
- };
- };
};
};
+&pciec {
+ status = "okay";
+};
+
+/*
+ * The two PCIe units are accessible through
+ * standard PCIe slots on the board.
+ */
+&pcie0 {
+ /* Port 0, Lane 0 */
+ status = "okay";
+};
+
+&pcie1 {
+ /* Port 1, Lane 0 */
+ status = "okay";
+};
+
+
+&spi0 {
+ pinctrl-0 = <&spi0_pins>;
+ pinctrl-names = "default";
+
+ /*
+ * SPI conflicts with NAND, so we disable it here, and
+ * select NAND as the enabled device by default.
+ */
+
+ status = "disabled";
+
+ spi-flash at 0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "n25q128a13", "jedec,spi-nor";
+ reg = <0>; /* Chip select 0 */
+ spi-max-frequency = <108000000>;
+ };
+};
+
+&i2c0 {
+ status = "okay";
+ clock-frequency = <100000>;
+ pinctrl-0 = <&i2c0_pins>;
+ pinctrl-names = "default";
+};
+
+&i2c1 {
+ status = "okay";
+ clock-frequency = <100000>;
+ pinctrl-0 = <&i2c1_pins>;
+ pinctrl-names = "default";
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&pinctrl {
+ sdio_st_pins: sdio-st-pins {
+ marvell,pins = "mpp44", "mpp45";
+ marvell,function = "gpio";
+ };
+};
+
+&sata {
+ status = "okay";
+ nr-ports = <2>;
+};
+
+&nand {
+ pinctrl-0 = <&nand_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ num-cs = <1>;
+ marvell,nand-keep-config;
+ marvell,nand-enable-arbiter;
+ nand-on-flash-bbt;
+ nand-ecc-strength = <4>;
+ nand-ecc-step-size = <512>;
+
+ partition at 0 {
+ label = "U-Boot";
+ reg = <0 0x800000>;
+ };
+ partition at 800000 {
+ label = "Linux";
+ reg = <0x800000 0x800000>;
+ };
+ partition at 1000000 {
+ label = "Filesystem";
+ reg = <0x1000000 0x3f000000>;
+ };
+};
+
+&usb1 {
+ status = "okay";
+};
+
+&usb2 {
+ status = "okay";
+};
+
+&sdio {
+ pinctrl-0 = <&sdio_pins &sdio_st_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ cd-gpios = <&gpio1 12 GPIO_ACTIVE_HIGH>;
+ wp-gpios = <&gpio1 13 GPIO_ACTIVE_HIGH>;
+};
+
+&mdio {
+ phy0: ethernet-phy at 0 {
+ reg = <0>;
+ };
+
+ phy3: ethernet-phy at 3 {
+ reg = <3>;
+ };
+};
+
+ðernet {
+ status = "okay";
+};
+
+
+ð0 {
+ status = "okay";
+ phy = <&phy0>;
+ phy-mode = "rgmii-id";
+};
+
+ð1 {
+ status = "okay";
+ phy = <&phy3>;
+ phy-mode = "gmii";
+};
--
2.10.1
^ 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