* [PATCH 1/3] ARM: dts: stm32: Enable VREFBUF on stm32mp157a-dk1
From: Fabrice Gasnier @ 2019-09-13 14:34 UTC (permalink / raw)
To: alexandre.torgue
Cc: mark.rutland, devicetree, linux-kernel, robh+dt, mcoquelin.stm32,
fabrice.gasnier, linux-stm32, linux-arm-kernel
In-Reply-To: <1568385280-2633-1-git-send-email-fabrice.gasnier@st.com>
Enable VREFBUF as ADC/DAC uses it on stm32mp157a-dk1 board.
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
---
arch/arm/boot/dts/stm32mp157a-dk1.dts | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/stm32mp157a-dk1.dts b/arch/arm/boot/dts/stm32mp157a-dk1.dts
index 0615d1c..ebd9f33 100644
--- a/arch/arm/boot/dts/stm32mp157a-dk1.dts
+++ b/arch/arm/boot/dts/stm32mp157a-dk1.dts
@@ -449,3 +449,10 @@
pinctrl-0 = <&uart4_pins_a>;
status = "okay";
};
+
+&vrefbuf {
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2500000>;
+ vdda-supply = <&vdd>;
+ status = "okay";
+};
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/3] Add support for ADC on stm32mp157a-dk1
From: Fabrice Gasnier @ 2019-09-13 14:34 UTC (permalink / raw)
To: alexandre.torgue
Cc: mark.rutland, devicetree, linux-kernel, robh+dt, mcoquelin.stm32,
fabrice.gasnier, linux-stm32, linux-arm-kernel
This series adds support for ADC on stm32mp157a-dk1 board:
- enable vrefbuf regulator used as reference voltage
- define ADC pins for AIN connector and USB Type-C CC pins
- configure ADC1 and ADC2 to use these
Fabrice Gasnier (3):
ARM: dts: stm32: Enable VREFBUF on stm32mp157a-dk1
ARM: dts: stm32: add ADC pins used on stm32mp157a-dk1
ARM: dts: stm32: enable ADC support on stm32mp157a-dk1
arch/arm/boot/dts/stm32mp157-pinctrl.dtsi | 16 +++++++++++++++
arch/arm/boot/dts/stm32mp157a-dk1.dts | 34 +++++++++++++++++++++++++++++++
2 files changed, 50 insertions(+)
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/3] ARM: dts: stm32: add ADC pins used on stm32mp157a-dk1
From: Fabrice Gasnier @ 2019-09-13 14:34 UTC (permalink / raw)
To: alexandre.torgue
Cc: mark.rutland, devicetree, linux-kernel, robh+dt, mcoquelin.stm32,
fabrice.gasnier, linux-stm32, linux-arm-kernel
In-Reply-To: <1568385280-2633-1-git-send-email-fabrice.gasnier@st.com>
Define pins that can be used for ADC on stm32mp157a-dk1 board:
- AIN connector has ADC input pins
- USB Type-C CC1 & CC2 pins (e.g. in18, in19)
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
---
arch/arm/boot/dts/stm32mp157-pinctrl.dtsi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi b/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
index e4a0d51..eeb60d0 100644
--- a/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
@@ -137,6 +137,22 @@
status = "disabled";
};
+ adc12_ain_pins_a: adc12-ain-0 {
+ pins {
+ pinmux = <STM32_PINMUX('C', 3, ANALOG)>, /* ADC1 in13 */
+ <STM32_PINMUX('F', 12, ANALOG)>, /* ADC1 in6 */
+ <STM32_PINMUX('F', 13, ANALOG)>, /* ADC2 in2 */
+ <STM32_PINMUX('F', 14, ANALOG)>; /* ADC2 in6 */
+ };
+ };
+
+ adc12_usb_cc_pins_a: adc12-usb-cc-pins-0 {
+ pins {
+ pinmux = <STM32_PINMUX('A', 4, ANALOG)>, /* ADC12 in18 */
+ <STM32_PINMUX('A', 5, ANALOG)>; /* ADC12 in19 */
+ };
+ };
+
cec_pins_a: cec-0 {
pins {
pinmux = <STM32_PINMUX('A', 15, AF4)>;
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/3] ARM: dts: stm32: enable ADC support on stm32mp157a-dk1
From: Fabrice Gasnier @ 2019-09-13 14:34 UTC (permalink / raw)
To: alexandre.torgue
Cc: mark.rutland, devicetree, linux-kernel, robh+dt, mcoquelin.stm32,
fabrice.gasnier, linux-stm32, linux-arm-kernel
In-Reply-To: <1568385280-2633-1-git-send-email-fabrice.gasnier@st.com>
Configure ADC support on stm32mp157a-dk1. It can be used for various
purpose:
- AIN connector has several analog inputs: ANA0, ANA1, ADC2 in6 & in2,
ADC1 in13 & in6
- USB Type-C CC1 & CC2 pins wired to in18 & in19
It's easier then to Configure them all. But keep them disabled by default,
so the pins are kept in their initial state to lower power consumption.
This way they can also be used as GPIO.
Add VDD and VDDA supplies to ADC on stm32mp157c-dk1 board. This allows to
get full ADC analog performances in case VDDA is below 2.7V (not the case
by default).
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
---
arch/arm/boot/dts/stm32mp157a-dk1.dts | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/arch/arm/boot/dts/stm32mp157a-dk1.dts b/arch/arm/boot/dts/stm32mp157a-dk1.dts
index ebd9f33..2f42fcd 100644
--- a/arch/arm/boot/dts/stm32mp157a-dk1.dts
+++ b/arch/arm/boot/dts/stm32mp157a-dk1.dts
@@ -97,6 +97,33 @@
};
};
+&adc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&adc12_ain_pins_a>, <&adc12_usb_cc_pins_a>;
+ vdd-supply = <&vdd>;
+ vdda-supply = <&vdd>;
+ vref-supply = <&vrefbuf>;
+ status = "disabled";
+ adc1: adc@0 {
+ /*
+ * Type-C USB_PWR_CC1 & USB_PWR_CC2 on in18 & in19.
+ * Use at least 5 * RC time, e.g. 5 * (Rp + Rd) * C:
+ * 5 * (56 + 47kOhms) * 5pF => 2.5us.
+ * Use arbitrary margin here (e.g. 5us).
+ */
+ st,min-sample-time-nsecs = <5000>;
+ /* AIN connector, USB Type-C CC1 & CC2 */
+ st,adc-channels = <0 1 6 13 18 19>;
+ status = "okay";
+ };
+ adc2: adc@100 {
+ /* AIN connector, USB Type-C CC1 & CC2 */
+ st,adc-channels = <0 1 2 6 18 19>;
+ st,min-sample-time-nsecs = <5000>;
+ status = "okay";
+ };
+};
+
&cec {
pinctrl-names = "default", "sleep";
pinctrl-0 = <&cec_pins_b>;
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] iommu/arm-smmu: Report USF more clearly
From: Qian Cai @ 2019-09-13 14:35 UTC (permalink / raw)
To: Robin Murphy, will, joro; +Cc: iommu, Douglas Anderson, linux-arm-kernel
In-Reply-To: <2762ffd4c196dc91d62e10eb8b753f256ea9b629.1568375317.git.robin.murphy@arm.com>
On Fri, 2019-09-13 at 12:48 +0100, Robin Murphy wrote:
> Although CONFIG_ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT is a welcome tool
> for smoking out inadequate firmware, the failure mode is non-obvious
> and can be confusing for end users. Add some special-case reporting of
> Unidentified Stream Faults to help clarify this particular symptom.
>
> CC: Douglas Anderson <dianders@chromium.org>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
> drivers/iommu/arm-smmu.c | 5 +++++
> drivers/iommu/arm-smmu.h | 2 ++
> 2 files changed, 7 insertions(+)
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index b7cf24402a94..76ac8c180695 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -499,6 +499,11 @@ static irqreturn_t arm_smmu_global_fault(int irq, void *dev)
> dev_err_ratelimited(smmu->dev,
> "\tGFSR 0x%08x, GFSYNR0 0x%08x, GFSYNR1 0x%08x, GFSYNR2 0x%08x\n",
> gfsr, gfsynr0, gfsynr1, gfsynr2);
> + if (IS_ENABLED(CONFIG_ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT) &&
> + (gfsr & sGFSR_USF))
> + dev_err_ratelimited(smmu->dev,
> + "Stream ID %hu may not be described by firmware, try booting with \"arm-smmu.disable_bypass=0\"\n",
> + (u16)gfsynr1);
dev_err_once(), i.e., don't need to remind people to set "arm-
smmu.disable_bypass=0" multiple times.
>
> arm_smmu_gr0_write(smmu, ARM_SMMU_GR0_sGFSR, gfsr);
> return IRQ_HANDLED;
> diff --git a/drivers/iommu/arm-smmu.h b/drivers/iommu/arm-smmu.h
> index c9c13b5785f2..46f7e161e83e 100644
> --- a/drivers/iommu/arm-smmu.h
> +++ b/drivers/iommu/arm-smmu.h
> @@ -79,6 +79,8 @@
> #define ID7_MINOR GENMASK(3, 0)
>
> #define ARM_SMMU_GR0_sGFSR 0x48
> +#define sGFSR_USF BIT(2)
> +
> #define ARM_SMMU_GR0_sGFSYNR0 0x50
> #define ARM_SMMU_GR0_sGFSYNR1 0x54
> #define ARM_SMMU_GR0_sGFSYNR2 0x58
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: edac: al-mc-edac: Amazon's Annapurna Labs Memory Controller EDAC
From: Rob Herring @ 2019-09-13 14:36 UTC (permalink / raw)
To: Talel Shenhar
Cc: mark.rutland, devicetree, barakw, ronenk, hhhawa, gregkh, jonnyc,
hanochu, linux-kernel, james.morse, catalin.marinas, bp, mchehab,
will, davem, linux-arm-kernel, linux-edac
In-Reply-To: <1567603943-25316-2-git-send-email-talel@amazon.com>
On Wed, Sep 04, 2019 at 04:32:21PM +0300, Talel Shenhar wrote:
> Document Amazon's Annapurna Labs Memory Controller EDAC SoC binding.
>
> Signed-off-by: Talel Shenhar <talel@amazon.com>
> ---
> .../devicetree/bindings/edac/amazon,al-mc-edac.txt | 24 ++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/edac/amazon,al-mc-edac.txt
>
> diff --git a/Documentation/devicetree/bindings/edac/amazon,al-mc-edac.txt b/Documentation/devicetree/bindings/edac/amazon,al-mc-edac.txt
> new file mode 100644
> index 0000000..9a3803f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/edac/amazon,al-mc-edac.txt
> @@ -0,0 +1,24 @@
> +Amazon's Annapurna Labs Memory Controller EDAC
> +
> +EDAC node is defined to describe on-chip error detection and correction for
> +Amazon's Annapurna Labs Memory Controller.
> +
> +Required properties:
> +- compatible: Shall be "amazon,al-mc-edac".
> +- reg: DDR controller resource.
> +
> +Optional:
> +- interrupt-names: may include "ue", for uncorrectable errors,
> + and/or "ce", for correctable errors.
> +- interrupts: should contain the interrupts associated with the
> + interrupts names.
> +
> +Example:
> +
> +al_mc_edac {
edac@f0080000
With that,
Reviewed-by: Rob Herring <robh@kernel.org>
> + compatible = "amazon,al-mc-edac";
> + reg = <0x0 0xf0080000 0x0 0x00010000>;
> + interrupt-parent = <&amazon_al_system_fabric>;
> + interrupt-names = "ue";
> + interrupts = <20 IRQ_TYPE_LEVEL_HIGH>;
> +};
> --
> 2.7.4
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/3] dt-bindings: ddr: Add bindings for Samsung LPDDR3 memories
From: Rob Herring @ 2019-09-13 14:36 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: mark.rutland, devicetree, willy.mh.wolff.ml,
linux-samsung-soc@vger.kernel.org, linux-pm,
Bartłomiej Żołnierkiewicz,
linux-kernel@vger.kernel.org, Lukasz Luba, Chanwoo Choi,
kyungmin.park, kgene, myungjoo.ham, s.nawrocki, linux-arm-kernel,
Marek Szyprowski
In-Reply-To: <CAJKOXPfEcURr_bLRaAdjWT3cb7mcuKTk8rmn7OTO=xtvjvJ=jQ@mail.gmail.com>
On Fri, Sep 06, 2019 at 01:50:26PM +0200, Krzysztof Kozlowski wrote:
> On Fri, 6 Sep 2019 at 13:39, Lukasz Luba <l.luba@partner.samsung.com> wrote:
> >
> > Hi Krzysztof,
> >
> > On 9/6/19 12:56 PM, Krzysztof Kozlowski wrote:
> > > On Fri, 6 Sep 2019 at 12:14, Lukasz Luba <l.luba@partner.samsung.com> wrote:
> > >>
> > >> Add description of bindings for Samsung k3qf2f20db LPDDR3 memory.
> > >> Minor fixes in the old documentation.
> > >>
> > >> Signed-off-by: Lukasz Luba <l.luba@partner.samsung.com>
> > >> ---
> > >> .../devicetree/bindings/ddr/lpddr3.txt | 29 +++++++++++++++++--
> > >> 1 file changed, 27 insertions(+), 2 deletions(-)
> > >>
> > >> diff --git a/Documentation/devicetree/bindings/ddr/lpddr3.txt b/Documentation/devicetree/bindings/ddr/lpddr3.txt
> > >> index 3b2485b84b3f..de0905239767 100644
> > >> --- a/Documentation/devicetree/bindings/ddr/lpddr3.txt
> > >> +++ b/Documentation/devicetree/bindings/ddr/lpddr3.txt
> > >> @@ -40,10 +40,34 @@ Child nodes:
> > >> a given speed-bin. Please see Documentation/devicetree/
> > >> bindings/ddr/lpddr3-timings.txt for more information on "lpddr3-timings"
> > >>
> > >> +Samsung K3QF2F20DB LPDDR3 memory
> > >> +------------------------------------------------------------
> > >> +
> > >> +This binding uses the LPDDR3 binding (described above)
> > >> +
> > >> +Required properties:
> > >> +- compatible: Should be:
> > >> + "samsung,K3QF2F20DB"
> > >> + followed by "jedec,lpddr3"
> > >> +- density : <u32> representing density in Mb (Mega bits)
> > >> +- io-width : <u32> representing bus width. Possible value 32
> > >> +- #address-cells: Must be set to 1
> > >> +- #size-cells: Must be set to 0
> > >
> > > If you decided to repeat all properties again, then it deserves its
> > > own bindings file. However I though about simpler solution - just
> > > document compatible. Exactly the same as AT24 or AT25 EEPROM bindings.
> > > There is not much benefit from copying all these properties.
> > OK, I see. I will add only 'compatible' and skip the rest then.
> > So the lpddr3.txt file will get this addition:
> >
> > +Samsung K3QF2F20DB LPDDR3 memory
> > +------------------------------------------------------------
> > +
> > +This binding uses the LPDDR3 binding (described above)
> > +
> > +Required properties:
> > +- compatible: Should be:
> > + "samsung,K3QF2F20DB"
> > + followed by "jedec,lpddr3"
> > +
> > +Optional properties:
> > +
> > +The optional properties are the same as in the LPDDR3 generic bindings and
> > +values should be taken from the data-sheet. Detailed bindings are described
> > +above.
> > +
> > +Child nodes:
> > +
> > +Detailed bindings are described in LPDDR3 generic bindings described above.
> > +
> >
> > Is it OK?
>
> To me it is still a lot of text just for one compatible and I can
> image more of such entries for other memories... However I do not mind
> and anyway, YAML will simplify it. If you're in doubt, wait for Rob's
> reply as this is his part.
We can't have multiple (top-level) schema in one file, so better to add
in where the existing compatible strings are.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] dt-bindings: memory-controllers: Convert Samsung Exynos SROM bindings to json-schema
From: Rob Herring @ 2019-09-13 14:36 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Mark Rutland, devicetree, linux-samsung-soc, linux-kernel,
Kukjin Kim, linux-arm-kernel
In-Reply-To: <20190907144442.16788-1-krzk@kernel.org>
On Sat, Sep 07, 2019 at 04:44:42PM +0200, Krzysztof Kozlowski wrote:
> Convert Samsung Exynos SROM controller bindings to DT schema format
> using json-schema.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> ---
> .../memory-controllers/exynos-srom.txt | 79 ----------
> .../memory-controllers/exynos-srom.yaml | 136 ++++++++++++++++++
> 2 files changed, 136 insertions(+), 79 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/memory-controllers/exynos-srom.txt
> create mode 100644 Documentation/devicetree/bindings/memory-controllers/exynos-srom.yaml
> diff --git a/Documentation/devicetree/bindings/memory-controllers/exynos-srom.yaml b/Documentation/devicetree/bindings/memory-controllers/exynos-srom.yaml
> new file mode 100644
> index 000000000000..9573bcfd68bf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/memory-controllers/exynos-srom.yaml
> @@ -0,0 +1,136 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/memory-controllers/exynos-srom.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Samsung Exynos SoC SROM Controller driver
> +
> +maintainers:
> + - Krzysztof Kozlowski <krzk@kernel.org>
> +
> +description: |+
> + The SROM controller can be used to attach external peripherals. In this case
> + extra properties, describing the bus behind it, should be specified.
> +
> +properties:
> + compatible:
> + items:
> + - const: samsung,exynos4210-srom
> +
> + reg:
> + maxItems: 1
> +
> + "#address-cells":
> + const: 2
> +
> + "#size-cells":
> + const: 1
> +
> + ranges:
> + description: |
> + Reflects the memory layout with four integer values per bank. Format:
> + <bank-number> 0 <parent address of bank> <size>
> +
> +patternProperties:
> + "^.*@[0-9]+,[0-9]+$":
How many chip selects? Can be a single digit?
Also, these should be hex values.
> + type: object
> + description:
> + The actual device nodes should be added as subnodes to the SROMc node.
> + These subnodes, in addition to regular device specification, should
> + contain the following properties, describing configuration
> + of the relevant SROM bank.
> +
> + properties:
> + reg:
> + description:
> + Bank number, base address (relative to start of the bank) and size
> + of the memory mapped for the device. Note that base address will be
> + typically 0 as this is the start of the bank.
> + maxItems: 1
> +
> + reg-io-width:
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
> + - enum: [1, 2]
> + description:
> + Data width in bytes (1 or 2). If omitted, default of 1 is used.
> +
> + samsung,srom-page-mode:
> + description:
> + If page mode is set, 4 data page mode will be configured,
> + else normal (1 data) page mode will be set.
> + type: boolean
> +
> + samsung,srom-timing:
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32-array
> + - items:
> + minItems: 6
> + maxItems: 6
> + description: |
> + Array of 6 integers, specifying bank timings in the following order:
> + Tacp, Tcah, Tcoh, Tacc, Tcos, Tacs.
> + Each value is specified in cycles and has the following meaning
> + and valid range:
> + Tacp: Page mode access cycle at Page mode (0 - 15)
> + Tcah: Address holding time after CSn (0 - 15)
> + Tcoh: Chip selection hold on OEn (0 - 15)
> + Tacc: Access cycle (0 - 31, the actual time is N + 1)
> + Tcos: Chip selection set-up before OEn (0 - 15)
> + Tacs: Address set-up before CSn (0 - 15)
> +
> + required:
> + - reg
> + - samsung,srom-timing
> +
> +required:
> + - compatible
> + - reg
> +
> +allOf:
> + - if:
> + anyOf:
> + - required: [ "#address-cells" ]
> + - required: [ ranges ]
> + - required: [ "#size-cells" ]
> + then:
> + required:
> + - "#address-cells"
> + - ranges
> + - "#size-cells"
I don't think this is necessary as the core schema should take care of
it. This can also be expressed using 'dependencies'.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 4/4] DTS: bindings: omap: update bindings documentation
From: Rob Herring @ 2019-09-13 14:36 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Mark Rutland, letux-kernel, devicetree, Tony Lindgren,
Viresh Kumar, linux-pm, Rafael J. Wysocki, linux-kernel,
Enric Balletbo i Serra, kernel, André Roth,
Benoît Cousson, H. Nikolaus Schaller, Teresa Remmet,
Javier Martinez Canillas, linux-omap, Adam Ford, linux-arm-kernel,
Roger Quadros
In-Reply-To: <35e4f219af5f8bff48e89ece7541f4e4ae6f27a0.1567878413.git.hns@goldelico.com>
On Sat, 7 Sep 2019 19:46:53 +0200, "H. Nikolaus Schaller" wrote:
> * clarify that we now need either "ti,omap3430" or "ti,omap3630" or "ti,am3517" for omap3 chips
> * clarify that "ti,omap3" has no default
> * clarify that AM33x is not an "ti,omap3"
> * clarify that the list of boards is incomplete
> * remove some "ti,am33xx", "ti,omap3"
> * add some missing "ti,omap4"
>
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
> Acked-by: Tony Lindgren <tony@atomide.com>
> ---
> .../devicetree/bindings/arm/omap/omap.txt | 30 +++++++++++--------
> 1 file changed, 17 insertions(+), 13 deletions(-)
>
Acked-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] irqchip/atmel-aic5: add support for sam9x60 irqchip
From: Rob Herring @ 2019-09-13 14:36 UTC (permalink / raw)
To: Claudiu Beznea
Cc: mark.rutland, devicetree, alexandre.belloni, jason, maz,
Sandeep Sheriker Mallikarjun, linux-kernel, ludovic.desroches,
robh+dt, tglx, Claudiu Beznea, linux-arm-kernel
In-Reply-To: <1568026835-6646-1-git-send-email-claudiu.beznea@microchip.com>
On Mon, 9 Sep 2019 14:00:35 +0300, Claudiu Beznea wrote:
> From: Sandeep Sheriker Mallikarjun <sandeepsheriker.mallikarjun@microchip.com>
>
> Add support for SAM9X60 irqchip.
>
> Signed-off-by: Sandeep Sheriker Mallikarjun <sandeepsheriker.mallikarjun@microchip.com>
> [claudiu.beznea@microchip.com: update aic5_irq_fixups[], update
> documentation]
> Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
> ---
> .../devicetree/bindings/interrupt-controller/atmel,aic.txt | 7 +++++--
> drivers/irqchip/irq-atmel-aic5.c | 10 ++++++++++
> 2 files changed, 15 insertions(+), 2 deletions(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/6] dt-bindings: pci: amlogic, meson-pcie: Add G12A bindings
From: Rob Herring @ 2019-09-13 14:36 UTC (permalink / raw)
To: Neil Armstrong
Cc: devicetree, lorenzo.pieralisi, Neil Armstrong, khilman, linux-pci,
linux-kernel, kishon, repk, maz, bhelgaas, linux-amlogic,
yue.wang, linux-arm-kernel
In-Reply-To: <1567950178-4466-2-git-send-email-narmstrong@baylibre.com>
On Sun, 8 Sep 2019 13:42:53 +0000, Neil Armstrong wrote:
> Add PCIE bindings for the Amlogic G12A SoC, the support is the same
> but the PHY is shared with USB3 to control the differential lines.
>
> Thus this adds a phy phandle to control the PHY, and sets invalid
> MIPI clock as optional for G12A.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> .../devicetree/bindings/pci/amlogic,meson-pcie.txt | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] dt-bindings: timer: Convert Exynos MCT bindings to json-schema
From: Rob Herring @ 2019-09-13 14:36 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Mark Rutland, devicetree, linux-samsung-soc, Daniel Lezcano,
linux-kernel, Kukjin Kim, Thomas Gleixner, linux-arm-kernel
In-Reply-To: <20190909162537.27635-1-krzk@kernel.org>
On Mon, Sep 09, 2019 at 06:25:37PM +0200, Krzysztof Kozlowski wrote:
> Convert Samsung Exynos Soc Multi Core Timer bindings to DT schema format
> using json-schema.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> ---
> .../bindings/timer/samsung,exynos4210-mct.txt | 88 --------------
> .../timer/samsung,exynos4210-mct.yaml | 115 ++++++++++++++++++
> 2 files changed, 115 insertions(+), 88 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
> create mode 100644 Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml
> diff --git a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml
> new file mode 100644
> index 000000000000..b96d2877955f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml
> @@ -0,0 +1,115 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/timer/samsung,exynos4210-mct.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Samsung Exynos SoC Multi Core Timer (MCT)
> +
> +maintainers:
> + - Krzysztof Kozlowski <krzk@kernel.org>
> +
> +description: |+
> + The Samsung's Multi Core Timer (MCT) module includes two main blocks, the
> + global timer and CPU local timers. The global timer is a 64-bit free running
> + up-counter and can generate 4 interrupts when the counter reaches one of the
> + four preset counter values. The CPU local timers are 32-bit free running
> + down-counters and generate an interrupt when the counter expires. There is
> + one CPU local timer instantiated in MCT for every CPU in the system.
> +
> +properties:
> + compatible:
> + enum:
> + - samsung,exynos4210-mct
> + - samsung,exynos4412-mct
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + description: |
> + Interrupts should be put in specific order. This is, the local timer
> + interrupts should be specified after the four global timer interrupts
> + have been specified:
> + 0: Global Timer Interrupt 0
> + 1: Global Timer Interrupt 1
> + 2: Global Timer Interrupt 2
> + 3: Global Timer Interrupt 3
> + 4: Local Timer Interrupt 0
> + 5: Local Timer Interrupt 1
> + 6: ..
> + 7: ..
> + i: Local Timer Interrupt n
> + For MCT block that uses a per-processor interrupt for local timers, such
> + as ones compatible with "samsung,exynos4412-mct", only one local timer
> + interrupt might be specified, meaning that all local timers use the same
> + per processor interrupt.
> + minItems: 5 # 4 Global + 1 local
> + maxItems: 20 # 4 Global + 16 local
> +
> +required:
> + - compatible
> + - interrupts
> + - reg
> +
> +examples:
> + - |
> + // In this example, the IP contains two local timers, using separate
> + // interrupts, so two local timer interrupts have been specified,
> + // in addition to four global timer interrupts.
> + mct@10050000 {
Can we clean this up and use 'timer' here.
> + compatible = "samsung,exynos4210-mct";
> + reg = <0x10050000 0x800>;
> + interrupts = <0 57 0>, <0 69 0>, <0 70 0>, <0 71 0>,
> + <0 42 0>, <0 48 0>;
> + };
> +
> + - |
> + // In this example, the timer interrupts are connected to two separate
> + // interrupt controllers. Hence, an interrupt-map is created to map
> + // the interrupts to the respective interrupt controllers.
> +
> + mct@101c0000 {
> + compatible = "samsung,exynos4210-mct";
> + reg = <0x101C0000 0x800>;
> + interrupt-parent = <&mct_map>;
> + interrupts = <0>, <1>, <2>, <3>, <4>, <5>;
> +
> + mct_map: mct-map {
This needs to be documented.
Note, I don't really see any reason this needs to be a child node.
> + #interrupt-cells = <1>;
> + #address-cells = <0>;
> + #size-cells = <0>;
> + interrupt-map = <0 &gic 0 57 0>,
> + <1 &gic 0 69 0>,
> + <2 &combiner 12 6>,
> + <3 &combiner 12 7>,
> + <4 &gic 0 42 0>,
> + <5 &gic 0 48 0>;
> + };
> + };
> +
> + - |
> + // In this example, the IP contains four local timers, but using
> + // a per-processor interrupt to handle them. Only one first local
> + // interrupt is specified.
> +
> + mct@10050000 {
> + compatible = "samsung,exynos4412-mct";
> + reg = <0x10050000 0x800>;
> +
> + interrupts = <0 57 0>, <0 69 0>, <0 70 0>, <0 71 0>,
> + <0 42 0>;
> + };
> +
> + - |
> + // In this example, the IP contains four local timers, but using
> + // a per-processor interrupt to handle them. All the local timer
> + // interrupts are specified.
> +
> + mct@10050000 {
> + compatible = "samsung,exynos4412-mct";
> + reg = <0x10050000 0x800>;
> +
> + interrupts = <0 57 0>, <0 69 0>, <0 70 0>, <0 71 0>,
> + <0 42 0>, <0 42 0>, <0 42 0>, <0 42 0>;
> + };
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH 2/2] dt-bindings: pwm: Convert Samsung PWM bindings to json-schema
From: Rob Herring @ 2019-09-13 14:36 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Mark Rutland, linux-pwm, linux-samsung-soc, Maciej Falkowski,
devicetree, linux-kernel, Thierry Reding, linux-leds, linux-clk,
linux-arm-kernel
In-Reply-To: <20190909183436.9045-2-krzk@kernel.org>
On Mon, Sep 09, 2019 at 08:34:36PM +0200, Krzysztof Kozlowski wrote:
> Convert Samsung PWM (S3C, S5P and Exynos SoCs) bindings to DT schema
> format using json-schema.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> ---
> .../devicetree/bindings/pwm/pwm-samsung.txt | 51 --------
> .../devicetree/bindings/pwm/pwm-samsung.yaml | 111 ++++++++++++++++++
> 2 files changed, 111 insertions(+), 51 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/pwm/pwm-samsung.txt
> create mode 100644 Documentation/devicetree/bindings/pwm/pwm-samsung.yaml
> diff --git a/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml b/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml
> new file mode 100644
> index 000000000000..90fb467bcdd5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml
> @@ -0,0 +1,111 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pwm/pwm-samsung.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Samsung SoC PWM timers
> +
> +maintainers:
> + - Thierry Reding <thierry.reding@gmail.com>
> + - Krzysztof Kozlowski <krzk@kernel.org>
> +
> +description: |+
> + Samsung SoCs contain PWM timer blocks which can be used for system clock source
> + and clock event timers, as well as to drive SoC outputs with PWM signal. Each
> + PWM timer block provides 5 PWM channels (not all of them can drive physical
> + outputs - see SoC and board manual).
> +
> + Be aware that the clocksource driver supports only uniprocessor systems.
> +
> +allOf:
> + - $ref: pwm.yaml#
> +
> +properties:
> + compatible:
> + enum:
> + - samsung,s3c2410-pwm # 16-bit, S3C24xx
> + - samsung,s3c6400-pwm # 32-bit, S3C64xx
> + - samsung,s5p6440-pwm # 32-bit, S5P64x0
> + - samsung,s5pc100-pwm # 32-bit, S5PC100, S5PV210, Exynos4210 rev0 SoCs
> + - samsung,exynos4210-pwm # 32-bit, Exynos
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + minItems: 1
> + maxItems: 3
> +
> + clock-names:
> + description: |
> + Should contain all following required clock names:
> + - "timers" - PWM base clock used to generate PWM signals,
> + and any subset of following optional clock names:
> + - "pwm-tclk0" - first external PWM clock source,
> + - "pwm-tclk1" - second external PWM clock source.
> + Note that not all IP variants allow using all external clock sources.
> + Refer to SoC documentation to learn which clock source configurations
> + are available.
> + oneOf:
> + - items:
> + - const: "timers"
> + - items:
> + - const: "timers"
> + - const: "pwm-tclk0"
> + - items:
> + - const: "timers"
> + - const: "pwm-tclk1"
> + - items:
> + - const: "timers"
> + - const: "pwm-tclk0"
> + - const: "pwm-tclk1"
> +
> + interrupts:
> + description:
> + One interrupt per timer, starting at timer 0.
> + minItems: 1
> + maxItems: 5
> +
> + "#pwm-cells":
> + description:
> + The only third cell flag supported by this binding
> + is PWM_POLARITY_INVERTED.
> + const: 3
> +
> + samsung,pwm-outputs:
> + description:
> + A list of PWM channels used as PWM outputs on particular platform.
> + It is an array of up to 5 elements being indices of PWM channels
> + (from 0 to 4), the order does not matter.
> + # TODO: Values should not repeat
uniqueItems: true
Though it looks like we have to enable that keyword. (As silently
ignoring unknown keywords (such as typos) is 'feature' of json-schema,
we explicitly list keywords we use.)
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32-array
> + # FIXME: min/max limit of items does not work
> + - items:
> + minItems: 1
> + maxItems: 5
> + - items:
> + minimum: 0
> + maximum: 4
I think you want:
minItems: 1
maxItems: 2
items:
minimum: 0
maximum: 4
> +
> +required:
> + - clocks
> + - clock-names
> + - compatible
> + - interrupts
> + - "#pwm-cells"
> + - reg
> +
> +examples:
> + - |
> + pwm@7f006000 {
> + compatible = "samsung,s3c6400-pwm";
> + reg = <0x7f006000 0x1000>;
> + interrupt-parent = <&vic0>;
> + interrupts = <23>, <24>, <25>, <27>, <28>;
> + clocks = <&clock 67>;
> + clock-names = "timers";
> + samsung,pwm-outputs = <0>, <1>;
> + #pwm-cells = <3>;
> + };
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] reset: uniphier-glue: Add Pro5 USB3 support
From: Rob Herring @ 2019-09-13 14:36 UTC (permalink / raw)
To: Kunihiko Hayashi
Cc: Mark Rutland, Kunihiko Hayashi, Masami Hiramatsu, devicetree,
linux-kernel, Masahiro Yamada, Philipp Zabel, Jassi Brar,
linux-arm-kernel
In-Reply-To: <1568080527-1767-1-git-send-email-hayashi.kunihiko@socionext.com>
On Tue, 10 Sep 2019 10:55:27 +0900, Kunihiko Hayashi wrote:
> Pro5 SoC has same scheme of USB3 reset as Pro4, so the data for Pro5 is
> equivalent to Pro4.
>
> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
> ---
> Documentation/devicetree/bindings/reset/uniphier-reset.txt | 5 +++--
> drivers/reset/reset-uniphier-glue.c | 4 ++++
> 2 files changed, 7 insertions(+), 2 deletions(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] iommu/arm-smmu: Report USF more clearly
From: Robin Murphy @ 2019-09-13 14:43 UTC (permalink / raw)
To: Qian Cai, will, joro; +Cc: iommu, Douglas Anderson, linux-arm-kernel
In-Reply-To: <1568385318.5576.146.camel@lca.pw>
On 13/09/2019 15:35, Qian Cai wrote:
> On Fri, 2019-09-13 at 12:48 +0100, Robin Murphy wrote:
>> Although CONFIG_ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT is a welcome tool
>> for smoking out inadequate firmware, the failure mode is non-obvious
>> and can be confusing for end users. Add some special-case reporting of
>> Unidentified Stream Faults to help clarify this particular symptom.
>>
>> CC: Douglas Anderson <dianders@chromium.org>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> ---
>> drivers/iommu/arm-smmu.c | 5 +++++
>> drivers/iommu/arm-smmu.h | 2 ++
>> 2 files changed, 7 insertions(+)
>>
>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>> index b7cf24402a94..76ac8c180695 100644
>> --- a/drivers/iommu/arm-smmu.c
>> +++ b/drivers/iommu/arm-smmu.c
>> @@ -499,6 +499,11 @@ static irqreturn_t arm_smmu_global_fault(int irq, void *dev)
>> dev_err_ratelimited(smmu->dev,
>> "\tGFSR 0x%08x, GFSYNR0 0x%08x, GFSYNR1 0x%08x, GFSYNR2 0x%08x\n",
>> gfsr, gfsynr0, gfsynr1, gfsynr2);
>> + if (IS_ENABLED(CONFIG_ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT) &&
>> + (gfsr & sGFSR_USF))
>> + dev_err_ratelimited(smmu->dev,
>> + "Stream ID %hu may not be described by firmware, try booting with \"arm-smmu.disable_bypass=0\"\n",
>> + (u16)gfsynr1);
>
> dev_err_once(), i.e., don't need to remind people to set "arm-
> smmu.disable_bypass=0" multiple times.
Indeed, but in many cases it then quickly gets buried by an unending
storm of repeated faults (not every console has capture and scrollback...)
Given that it's a "this is why your machine is on fire" kind of message,
I figured that it's probably best to err on the side of visibility.
Robin.
>>
>> arm_smmu_gr0_write(smmu, ARM_SMMU_GR0_sGFSR, gfsr);
>> return IRQ_HANDLED;
>> diff --git a/drivers/iommu/arm-smmu.h b/drivers/iommu/arm-smmu.h
>> index c9c13b5785f2..46f7e161e83e 100644
>> --- a/drivers/iommu/arm-smmu.h
>> +++ b/drivers/iommu/arm-smmu.h
>> @@ -79,6 +79,8 @@
>> #define ID7_MINOR GENMASK(3, 0)
>>
>> #define ARM_SMMU_GR0_sGFSR 0x48
>> +#define sGFSR_USF BIT(2)
>> +
>> #define ARM_SMMU_GR0_sGFSYNR0 0x50
>> #define ARM_SMMU_GR0_sGFSYNR1 0x54
>> #define ARM_SMMU_GR0_sGFSYNR2 0x58
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: KASAN: slab-out-of-bounds Read in handle_vmptrld
From: Paolo Bonzini @ 2019-09-13 15:01 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: mark.rutland, x86, wanpengli, kvm, narmstrong, catalin.marinas,
will.deacon, hpa, khilman, joro, rkrcmar, mingo, Dmitry Vyukov,
syzbot, devicetree, syzkaller-bugs, robh+dt, bp, linux-amlogic,
tglx, linux-arm-kernel, jmattson, USB list, linux-kernel,
sean.j.christopherson, carlo, Vitaly Kuznetsov
In-Reply-To: <20190913130226.GB403359@kroah.com>
On 13/09/19 15:02, Greg Kroah-Hartman wrote:
> Look at linux-next, we "should" have fixed up hcd_buffer_alloc() now to
> not need this type of thing. If we got it wrong, please let us know and
> then yes, a fix like this would be most appreciated :)
I still see
/* some USB hosts just use PIO */
if (!hcd_uses_dma(hcd)) {
*dma = ~(dma_addr_t) 0;
return kmalloc(size, mem_flags);
}
in linux-next's hcd_buffer_alloc and also in usb.git's usb-next branch.
I also see the same
if (remap_pfn_range(vma, vma->vm_start,
virt_to_phys(usbm->mem) >> PAGE_SHIFT,
size, vma->vm_page_prot) < 0) {
...
}
in usbdev_mmap. Of course it's possible that I'm looking at the wrong
branch, or just being dense.
Paolo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/3] OMAP3: PM: Set/clear T2 bit for Smartreflex on TWL
From: Adam Ford @ 2019-09-13 15:11 UTC (permalink / raw)
To: Tony Lindgren
Cc: Nishanth Menon, Kevin Hilman, H. Nikolaus Schaller, Shweta Gulati,
André Roth, Thara Gopinath, Linux-OMAP, arm-soc
In-Reply-To: <20190912210937.GU52127@atomide.com>
On Thu, Sep 12, 2019 at 4:09 PM Tony Lindgren <tony@atomide.com> wrote:
>
> * Adam Ford <aford173@gmail.com> [190912 19:00]:
> > On Wed, Jul 31, 2019 at 8:29 PM André Roth <neolynx@gmail.com> wrote:
> > >
> > > From: Thara Gopinath <thara@ti.com>
> > >
> > > Voltage control on TWL can be done using VMODE/I2C1/I2C_SR.
> > > Since almost all platforms use I2C_SR on omap3, omap3_twl_init by
> > > default expects that OMAP's I2C_SR is plugged in to TWL's I2C
> > > and calls omap3_twl_set_sr_bit. On platforms where I2C_SR is not connected,
> > > the board files are expected to call omap3_twl_set_sr_bit(false) to
> > > ensure that I2C_SR path is not set for voltage control and prevent
> > > the default behavior of omap3_twl_init.
> > >
> > > Signed-off-by: Nishanth Menon <nm@ti.com>
> > > Signed-off-by: Thara Gopinath <thara@ti.com>
> > > Signed-off-by: Shweta Gulati <shweta.gulati@ti.com>
> > > Cc: linux-arm-kernel@lists.infradead.org
> > > Signed-off-by: Kevin Hilman <khilman@ti.com>
> >
> > Tony,
> >
> > Is there a status update on this series? It's been several months,
> > and I haven't seen any feedback on it, nor does it appear to be in any
> > of your branches that I can see.
>
> Well it was tagged RFC.. Does something need updating
> with it?
I didn't notice the RTC until you pointed out the 0/3 file showed the RFC.
Andre - since you have sign-off by various TI people and Tony seems
satisfied, would you be will to re-base and push the patch series
without the RFC?
I think some of the work that H Nikolaus Schaller is doing will
benefit from this.
Thank you,
adam
>
> At least the first two patches looked OK to me.
>
> Regards,
>
> Tony
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: dts: renesas: Add /soc dma-ranges
From: Rob Herring @ 2019-09-13 15:14 UTC (permalink / raw)
To: Marek Vašut
Cc: devicetree, Geert Uytterhoeven, Wolfram Sang,
open list:MEDIA DRIVERS FOR RENESAS - FCP,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Marek Vasut
In-Reply-To: <20190907161634.27378-1-marek.vasut@gmail.com>
On Sat, Sep 7, 2019 at 5:16 PM <marek.vasut@gmail.com> wrote:
>
> From: Marek Vasut <marek.vasut+renesas@gmail.com>
>
> Add dma-ranges property into /soc node to describe the DMA capabilities
> of the bus. This is currently needed to translate PCI DMA ranges, which
> are limited to 32bit addresses.
FYI, I've started working on this problem and issues around
dma-ranges/dma_mask. Hopefully I'll get some patches out next week.
> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Wolfram Sang <wsa@the-dreams.de>
> Cc: devicetree@vger.kernel.org
> Cc: linux-renesas-soc@vger.kernel.org
> To: linux-arm-kernel@lists.infradead.org
> ---
> NOTE: This is needed for the following patches to work correctly:
> https://patchwork.ozlabs.org/patch/1144870/
> https://patchwork.ozlabs.org/patch/1144871/
First I'm seeing those... Well, I do have v7 from 2+ years ago...
Not sure if these take into account the new dma_bus_mask, but that
should simplify solving the issue.
> ---
> arch/arm64/boot/dts/renesas/r8a7795.dtsi | 1 +
> arch/arm64/boot/dts/renesas/r8a7796.dtsi | 1 +
> arch/arm64/boot/dts/renesas/r8a77965.dtsi | 1 +
> 3 files changed, 3 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> index 95deff66eeb6..2102140a6723 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> @@ -330,6 +330,7 @@
> #address-cells = <2>;
> #size-cells = <2>;
> ranges;
> + dma-ranges = <0 0x40000000 0 0x40000000 0 0xc0000000>;
Is the limitation in the bus or the PCI bridge or both? The commit
message sounds like it's the PCI bridge in which case this is wrong
(or incomplete). 'dma-ranges' should be on the bus node where the
restriction/translation exists. For PCI devices, that's the PCI bridge
node. So a 32-bit only PCI bridge should have a dma-ranges size of
4GB. If the SoC bus has more restrictions, then that should be in the
PCI bridge parent assuming that restriction also applies to other
devices.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: KASAN: slab-out-of-bounds Read in handle_vmptrld
From: Robin Murphy @ 2019-09-13 15:32 UTC (permalink / raw)
To: Paolo Bonzini, Greg Kroah-Hartman
Cc: mark.rutland, wanpengli, kvm, narmstrong, catalin.marinas,
will.deacon, rkrcmar, hpa, khilman, joro, x86, mingo,
linux-arm-kernel, syzbot, devicetree, syzkaller-bugs, robh+dt, bp,
linux-amlogic, tglx, Dmitry Vyukov, jmattson, USB list,
linux-kernel, sean.j.christopherson, carlo, Vitaly Kuznetsov
In-Reply-To: <6a0ec3a2-2a52-f67a-6140-e0a60874538a@redhat.com>
On 13/09/2019 16:01, Paolo Bonzini wrote:
> On 13/09/19 15:02, Greg Kroah-Hartman wrote:
>> Look at linux-next, we "should" have fixed up hcd_buffer_alloc() now to
>> not need this type of thing. If we got it wrong, please let us know and
>> then yes, a fix like this would be most appreciated :)
>
> I still see
>
> /* some USB hosts just use PIO */
> if (!hcd_uses_dma(hcd)) {
> *dma = ~(dma_addr_t) 0;
> return kmalloc(size, mem_flags);
> }
>
> in linux-next's hcd_buffer_alloc and also in usb.git's usb-next branch.
> I also see the same
>
> if (remap_pfn_range(vma, vma->vm_start,
> virt_to_phys(usbm->mem) >> PAGE_SHIFT,
> size, vma->vm_page_prot) < 0) {
> ...
> }
>
> in usbdev_mmap. Of course it's possible that I'm looking at the wrong
> branch, or just being dense.
Oh, that bit of usbdev_mmap() is already known to be pretty much totally
bogus for various reasons - there have been a few threads about it, of
which I think [1] is both the most recent and the most informative.
There was another patch[2], but that might have stalled (and might need
reworking with additional hcd_uses_dma() checks anyway).
Robin.
[1]
https://lore.kernel.org/linux-arm-kernel/20190808084636.GB15080@priv-mua.localdomain/
[2]
https://lore.kernel.org/linux-usb/20190801220134.3295-1-gavinli@thegavinli.com/
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: KASAN: slab-out-of-bounds Read in handle_vmptrld
From: Alan Stern @ 2019-09-13 15:36 UTC (permalink / raw)
To: Paolo Bonzini
Cc: mark.rutland, x86, wanpengli, kvm, rkrcmar, catalin.marinas,
will.deacon, hpa, khilman, joro, narmstrong, mingo, Dmitry Vyukov,
syzbot, devicetree, syzkaller-bugs, robh+dt, bp, linux-amlogic,
tglx, linux-arm-kernel, jmattson, Greg Kroah-Hartman, USB list,
linux-kernel, sean.j.christopherson, carlo, Vitaly Kuznetsov
In-Reply-To: <6a0ec3a2-2a52-f67a-6140-e0a60874538a@redhat.com>
On Fri, 13 Sep 2019, Paolo Bonzini wrote:
> On 13/09/19 15:02, Greg Kroah-Hartman wrote:
> > Look at linux-next, we "should" have fixed up hcd_buffer_alloc() now to
> > not need this type of thing. If we got it wrong, please let us know and
> > then yes, a fix like this would be most appreciated :)
>
> I still see
>
> /* some USB hosts just use PIO */
> if (!hcd_uses_dma(hcd)) {
> *dma = ~(dma_addr_t) 0;
> return kmalloc(size, mem_flags);
> }
>
> in linux-next's hcd_buffer_alloc and also in usb.git's usb-next branch.
> I also see the same
>
> if (remap_pfn_range(vma, vma->vm_start,
> virt_to_phys(usbm->mem) >> PAGE_SHIFT,
> size, vma->vm_page_prot) < 0) {
> ...
> }
>
> in usbdev_mmap. Of course it's possible that I'm looking at the wrong
> branch, or just being dense.
Have you seen
https://marc.info/?l=linux-usb&m=156758511218419&w=2
? It certainly is relevant, although Greg hasn't replied to it.
There have been other messages on the mailing list about this issue,
but I haven't tried to keep track of them.
Also, just warning about a non-page-aligned allocation doesn't really
help. It would be better to fix the misbehaving allocator.
Alan Stern
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: KASAN: slab-out-of-bounds Read in handle_vmptrld
From: Paolo Bonzini @ 2019-09-13 16:14 UTC (permalink / raw)
To: Alan Stern
Cc: mark.rutland, x86, wanpengli, kvm, rkrcmar, catalin.marinas,
will.deacon, hpa, khilman, joro, narmstrong, mingo, Dmitry Vyukov,
syzbot, devicetree, syzkaller-bugs, robh+dt, bp, linux-amlogic,
tglx, linux-arm-kernel, jmattson, Greg Kroah-Hartman, USB list,
linux-kernel, sean.j.christopherson, carlo, Vitaly Kuznetsov
In-Reply-To: <Pine.LNX.4.44L0.1909131129390.1466-100000@iolanthe.rowland.org>
On 13/09/19 17:36, Alan Stern wrote:
> On Fri, 13 Sep 2019, Paolo Bonzini wrote:
>
>> On 13/09/19 15:02, Greg Kroah-Hartman wrote:
>>> Look at linux-next, we "should" have fixed up hcd_buffer_alloc() now to
>>> not need this type of thing. If we got it wrong, please let us know and
>>> then yes, a fix like this would be most appreciated :)
>>
>> I still see
>>
>> /* some USB hosts just use PIO */
>> if (!hcd_uses_dma(hcd)) {
>> *dma = ~(dma_addr_t) 0;
>> return kmalloc(size, mem_flags);
>> }
>>
>> in linux-next's hcd_buffer_alloc and also in usb.git's usb-next branch.
>> I also see the same
>>
>> if (remap_pfn_range(vma, vma->vm_start,
>> virt_to_phys(usbm->mem) >> PAGE_SHIFT,
>> size, vma->vm_page_prot) < 0) {
>> ...
>> }
>>
>> in usbdev_mmap. Of course it's possible that I'm looking at the wrong
>> branch, or just being dense.
>
> Have you seen
>
> https://marc.info/?l=linux-usb&m=156758511218419&w=2
>
> ? It certainly is relevant, although Greg hasn't replied to it.
It helps but it's not a full fix, since the address would fail
is_vmalloc_addr. On top of that, hcd_buffer_alloc and hcd_buffer_free
need to switch from kmalloc to vmalloc.
> Also, just warning about a non-page-aligned allocation doesn't really
> help. It would be better to fix the misbehaving allocator.
Of course. The above patch does not fix the issue, it should just allow
for an easier reproduction not involving KVM. More long term, it points
out where the contracts mismatch (i.e. between hcd_buffer_alloc and
usb_alloc_coherent), and more selfishly whose bug it is when syzkaller
complains. :)
Paolo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 0/2] fix double page fault on arm64
From: Jia He @ 2019-09-13 16:32 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Mark Rutland, James Morse,
Marc Zyngier, Matthew Wilcox, Kirill A. Shutemov,
linux-arm-kernel, linux-kernel, linux-mm
Cc: Ralph Campbell, Jia He, Andrew Morton, Anshuman Khandual, Jun Yao,
Jérôme Glisse, Punit Agrawal, hejianet, Thomas Gleixner,
Robin Murphy, Alex Van Brunt
When we tested pmdk unit test vmmalloc_fork TEST1 in arm64 guest, there
will be a double page fault in __copy_from_user_inatomic of cow_user_page.
As told by Catalin: "On arm64 without hardware Access Flag, copying from
user will fail because the pte is old and cannot be marked young. So we
always end up with zeroed page after fork() + CoW for pfn mappings. we
don't always have a hardware-managed access flag on arm64."
Changes
v3: add vmf->ptl lock/unlock (by Kirill A. Shutemov)
add arch_faults_on_old_pte (Matthew, Catalins)
v2: remove FAULT_FLAG_WRITE when setting pte access flag (by Catalin)
Jia He (2):
arm64: mm: implement arch_faults_on_old_pte() on arm64
mm: fix double page fault on arm64 if PTE_AF is cleared
arch/arm64/include/asm/pgtable.h | 11 +++++++++++
mm/memory.c | 29 ++++++++++++++++++++++++-----
2 files changed, 35 insertions(+), 5 deletions(-)
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 1/2] arm64: mm: implement arch_faults_on_old_pte() on arm64
From: Jia He @ 2019-09-13 16:32 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Mark Rutland, James Morse,
Marc Zyngier, Matthew Wilcox, Kirill A. Shutemov,
linux-arm-kernel, linux-kernel, linux-mm
Cc: Ralph Campbell, Jia He, Andrew Morton, Anshuman Khandual, Jun Yao,
Jérôme Glisse, Punit Agrawal, hejianet, Thomas Gleixner,
Robin Murphy, Alex Van Brunt
In-Reply-To: <20190913163239.125108-1-justin.he@arm.com>
On arm64 without hardware Access Flag, copying fromuser will fail because
the pte is old and cannot be marked young. So we always end up with zeroed
page after fork() + CoW for pfn mappings. we don't always have a
hardware-managed access flag on arm64.
Hence implement arch_faults_on_old_pte on arm64 to indicate that it might
cause page fault when accessing old pte.
Signed-off-by: Jia He <justin.he@arm.com>
---
arch/arm64/include/asm/pgtable.h | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index e09760ece844..b41399d758df 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -868,6 +868,18 @@ static inline void update_mmu_cache(struct vm_area_struct *vma,
#define phys_to_ttbr(addr) (addr)
#endif
+/*
+ * On arm64 without hardware Access Flag, copying fromuser will fail because
+ * the pte is old and cannot be marked young. So we always end up with zeroed
+ * page after fork() + CoW for pfn mappings. we don't always have a
+ * hardware-managed access flag on arm64.
+ */
+static inline bool arch_faults_on_old_pte(void)
+{
+ return true;
+}
+#define arch_faults_on_old_pte arch_faults_on_old_pte
+
#endif /* !__ASSEMBLY__ */
#endif /* __ASM_PGTABLE_H */
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 2/2] mm: fix double page fault on arm64 if PTE_AF is cleared
From: Jia He @ 2019-09-13 16:32 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Mark Rutland, James Morse,
Marc Zyngier, Matthew Wilcox, Kirill A. Shutemov,
linux-arm-kernel, linux-kernel, linux-mm
Cc: Ralph Campbell, Jia He, Andrew Morton, Anshuman Khandual, Jun Yao,
Jérôme Glisse, Punit Agrawal, hejianet, Thomas Gleixner,
Robin Murphy, Alex Van Brunt
In-Reply-To: <20190913163239.125108-1-justin.he@arm.com>
When we tested pmdk unit test [1] vmmalloc_fork TEST1 in arm64 guest, there
will be a double page fault in __copy_from_user_inatomic of cow_user_page.
Below call trace is from arm64 do_page_fault for debugging purpose
[ 110.016195] Call trace:
[ 110.016826] do_page_fault+0x5a4/0x690
[ 110.017812] do_mem_abort+0x50/0xb0
[ 110.018726] el1_da+0x20/0xc4
[ 110.019492] __arch_copy_from_user+0x180/0x280
[ 110.020646] do_wp_page+0xb0/0x860
[ 110.021517] __handle_mm_fault+0x994/0x1338
[ 110.022606] handle_mm_fault+0xe8/0x180
[ 110.023584] do_page_fault+0x240/0x690
[ 110.024535] do_mem_abort+0x50/0xb0
[ 110.025423] el0_da+0x20/0x24
The pte info before __copy_from_user_inatomic is (PTE_AF is cleared):
[ffff9b007000] pgd=000000023d4f8003, pud=000000023da9b003, pmd=000000023d4b3003, pte=360000298607bd3
As told by Catalin: "On arm64 without hardware Access Flag, copying from
user will fail because the pte is old and cannot be marked young. So we
always end up with zeroed page after fork() + CoW for pfn mappings. we
don't always have a hardware-managed access flag on arm64."
This patch fix it by calling pte_mkyoung. Also, the parameter is
changed because vmf should be passed to cow_user_page()
[1] https://github.com/pmem/pmdk/tree/master/src/test/vmmalloc_fork
Reported-by: Yibo Cai <Yibo.Cai@arm.com>
Signed-off-by: Jia He <justin.he@arm.com>
---
mm/memory.c | 30 +++++++++++++++++++++++++-----
1 file changed, 25 insertions(+), 5 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index e2bb51b6242e..a64af6495f71 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -118,6 +118,13 @@ int randomize_va_space __read_mostly =
2;
#endif
+#ifndef arch_faults_on_old_pte
+static inline bool arch_faults_on_old_pte(void)
+{
+ return false;
+}
+#endif
+
static int __init disable_randmaps(char *s)
{
randomize_va_space = 0;
@@ -2140,7 +2147,8 @@ static inline int pte_unmap_same(struct mm_struct *mm, pmd_t *pmd,
return same;
}
-static inline void cow_user_page(struct page *dst, struct page *src, unsigned long va, struct vm_area_struct *vma)
+static inline void cow_user_page(struct page *dst, struct page *src,
+ struct vm_fault *vmf)
{
debug_dma_assert_idle(src);
@@ -2152,20 +2160,32 @@ static inline void cow_user_page(struct page *dst, struct page *src, unsigned lo
*/
if (unlikely(!src)) {
void *kaddr = kmap_atomic(dst);
- void __user *uaddr = (void __user *)(va & PAGE_MASK);
+ void __user *uaddr = (void __user *)(vmf->address & PAGE_MASK);
+ pte_t entry;
/*
* This really shouldn't fail, because the page is there
* in the page tables. But it might just be unreadable,
* in which case we just give up and fill the result with
- * zeroes.
+ * zeroes. If PTE_AF is cleared on arm64, it might
+ * cause double page fault. So makes pte young here
*/
+ if (arch_faults_on_old_pte() && !pte_young(vmf->orig_pte)) {
+ spin_lock(vmf->ptl);
+ entry = pte_mkyoung(vmf->orig_pte);
+ if (ptep_set_access_flags(vmf->vma, vmf->address,
+ vmf->pte, entry, 0))
+ update_mmu_cache(vmf->vma, vmf->address,
+ vmf->pte);
+ spin_unlock(vmf->ptl);
+ }
+
if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE))
clear_page(kaddr);
kunmap_atomic(kaddr);
flush_dcache_page(dst);
} else
- copy_user_highpage(dst, src, va, vma);
+ copy_user_highpage(dst, src, vmf->address, vmf->vma);
}
static gfp_t __get_fault_gfp_mask(struct vm_area_struct *vma)
@@ -2318,7 +2338,7 @@ static vm_fault_t wp_page_copy(struct vm_fault *vmf)
vmf->address);
if (!new_page)
goto oom;
- cow_user_page(new_page, old_page, vmf->address, vma);
+ cow_user_page(new_page, old_page, vmf);
}
if (mem_cgroup_try_charge_delay(new_page, mm, GFP_KERNEL, &memcg, false))
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* RE: [PATCH V3 00/15] arm64: dts: imx8: architecture improvement and adding imx8qm support
From: Aisheng Dong @ 2019-09-13 16:43 UTC (permalink / raw)
To: Oliver Graute
Cc: devicetree@vger.kernel.org, dongas86@gmail.com,
catalin.marinas@arm.com, will.deacon@arm.com, robh+dt@kernel.org,
dl-linux-imx, kernel@pengutronix.de, Fabio Estevam,
shawnguo@kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190913121608.GD16292@optiplex>
> From: Oliver Graute <oliver.graute@gmail.com>
> Sent: Friday, September 13, 2019 8:16 PM
>
> On 12/09/19, Dong Aisheng wrote:
> > IMX SCU based platforms (e.g. MX8QM/MX8QXP) are comprised of a
> number
> > of SS (Subsystems), those SS may be shared between different SoCs
> > while most of them can be reused like Devices Resources, Clocks, Power
> domains and etc.
> >
> > This patch series aims to improve the MX8 architecture to comply with
> > the HW design to save a lot of duplicated codes and benefits us a
> > better maintainability and scalability in the future.
> >
> > This patch series depends on another clk new binding series:
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> >
> hwork.kernel.org%2Fcover%2F11046287%2F&data=02%7C01%7Caishen
> g.dong
> > %40nxp.com%7C2dffe4b2a0734c5a031408d738447876%7C686ea1d3bc2b
> 4c6fa92cd9
> >
> 9c5c301635%7C0%7C1%7C637039739035971290&sdata=JsAy8vUkkCp
> n5HYh79oC
> > vekH3SJAICg7VQnLMP01O3c%3D&reserved=0
>
> Thx for your update of this patch series. I'am running into the issue that my
> linux next-20190904 unfortunately is not booting with it on my imx8QM
> board. Kernel is just stuck during boot see below.
>
> I applied your v5 of your clock binding patches series and applied this series in
> v3. Your former two patch series worked well with next-20190716.
>
> The last messages from the kernel are:
>
> [ 1.019208] imx-scu scu: mbox_request_channel_byname() could not
> locate channel named "gip3"
> [ 1.027316] imx-scu scu: failed to request mbox chan gip3, ret -22
> [ 1.033480] imx-scu scu: failed to enable general irq channel: -22
> [ 1.039646] imx-scu scu: NXP i.MX SCU Initialized
> [ 1.047414] a35_clk: failed to get clock rate -22
> [ 1.058682] lcd0-pwm0: failed to power up resource 188 ret -22
> [ 1.064314] imx-scu-clk: probe of pwm_clk failed with error -22
> [ 1.070538] lcd0: failed to power up resource 187 ret -22
> [ 1.075690] imx-scu-clk: probe of lcd_clk failed with error -22
> [ 1.085965] mipi_csi0_core_clk: failed to attached the power domain -2
> [ 1.092359] mipi_csi0_esc_clk: failed to attached the power domain -2
> [ 1.098777] mipi_csi0_i2c0_clk: failed to attached the power domain -2
> [ 1.105278] mipi_csi0_pwm0_clk: failed to attached the power domain -2
> [ 1.115744] imx8qm-pinctrl scu:pinctrl: initialized IMX pinctrl driver
> [ 1.123923] gpio-mxc 5d080000.gpio: IRQ index 1 not found
> [ 1.130276] gpio-mxc 5d090000.gpio: IRQ index 1 not found
>
> I see similar messages also with your older working patches, only the last two
> lines are new errors.
>
Those warnings are because we are still missing some domains added into the
pd driver support, it does not block the booting.
But I did miss to send another power domain patch to avoid gate of console domain
which may result in the console hang.
Please try below patch:
From 4685f604938b2a8d91d9b14081c15cb554c5711f Mon Sep 17 00:00:00 2001
From: Dong Aisheng <aisheng.dong@nxp.com>
Date: Sun, 7 Jul 2019 19:37:33 +0800
Subject: [PATCH 1/1] firmware: imx: scu-pd: do not power off console domain
Do not power off console domain in runtime pm.
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
---
drivers/firmware/imx/scu-pd.c | 28 +++++++++++++++++++++++++++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/imx/scu-pd.c b/drivers/firmware/imx/scu-pd.c
index b556612..770e368 100644
--- a/drivers/firmware/imx/scu-pd.c
+++ b/drivers/firmware/imx/scu-pd.c
@@ -85,6 +85,8 @@ struct imx_sc_pd_soc {
u8 num_ranges;
};
+int imx_con_rsrc;
+
static const struct imx_sc_pd_range imx8qxp_scu_pd_ranges[] = {
/* LSIO SS */
{ "pwm", IMX_SC_R_PWM_0, 8, true, 0 },
@@ -173,6 +175,23 @@ to_imx_sc_pd(struct generic_pm_domain *genpd)
return container_of(genpd, struct imx_sc_pm_domain, pd);
}
+static void imx_sc_pd_get_console_rsrc(void)
+{
+ struct of_phandle_args specs;
+ int ret;
+
+ if (!of_stdout)
+ return;
+
+ ret = of_parse_phandle_with_args(of_stdout, "power-domains",
+ "#power-domain-cells",
+ 0, &specs);
+ if (ret)
+ return;
+
+ imx_con_rsrc = specs.args[0];
+}
+
static int imx_sc_pd_power(struct generic_pm_domain *domain, bool power_on)
{
struct imx_sc_msg_req_set_resource_power_mode msg;
@@ -233,6 +252,7 @@ imx_scu_add_pm_domain(struct device *dev, int idx,
const struct imx_sc_pd_range *pd_ranges)
{
struct imx_sc_pm_domain *sc_pd;
+ bool is_off = true;
int ret;
sc_pd = devm_kzalloc(dev, sizeof(*sc_pd), GFP_KERNEL);
@@ -251,6 +271,10 @@ imx_scu_add_pm_domain(struct device *dev, int idx,
"%s", pd_ranges->name);
sc_pd->pd.name = sc_pd->name;
+ if (imx_con_rsrc == sc_pd->rsrc) {
+ sc_pd->pd.flags = GENPD_FLAG_RPM_ALWAYS_ON;
+ is_off = false;
+ }
if (sc_pd->rsrc >= IMX_SC_R_LAST) {
dev_warn(dev, "invalid pd %s rsrc id %d found",
@@ -260,7 +284,7 @@ imx_scu_add_pm_domain(struct device *dev, int idx,
return NULL;
}
- ret = pm_genpd_init(&sc_pd->pd, NULL, true);
+ ret = pm_genpd_init(&sc_pd->pd, NULL, is_off);
if (ret) {
dev_warn(dev, "failed to init pd %s rsrc id %d",
sc_pd->name, sc_pd->rsrc);
@@ -326,6 +350,8 @@ static int imx_sc_pd_probe(struct platform_device *pdev)
if (!pd_soc)
return -ENODEV;
+ imx_sc_pd_get_console_rsrc();
+
return imx_scu_init_pm_domains(&pdev->dev, pd_soc);
}
--
2.7.4
Regards
Aisheng
> Best regards,
>
> Oliver
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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