* [PATCH V3] dt-bindings: thermal: Convert qoriq to json-schema
From: Anson Huang @ 2020-06-02 1:15 UTC (permalink / raw)
To: rui.zhang, daniel.lezcano, amit.kucheria, robh+dt, hongtao.jia,
linux-pm, devicetree, linux-kernel
Cc: Linux-imx
Convert the qoriq thermal binding to DT schema format using json-schema
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
Changes since V2:
- correct maintainer's email address.
---
.../devicetree/bindings/thermal/qoriq-thermal.txt | 71 -------------
.../devicetree/bindings/thermal/qoriq-thermal.yaml | 112 +++++++++++++++++++++
2 files changed, 112 insertions(+), 71 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
create mode 100644 Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
diff --git a/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt b/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
deleted file mode 100644
index 28f2cba..0000000
--- a/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
+++ /dev/null
@@ -1,71 +0,0 @@
-* Thermal Monitoring Unit (TMU) on Freescale QorIQ SoCs
-
-Required properties:
-- compatible : Must include "fsl,qoriq-tmu" or "fsl,imx8mq-tmu". The
- version of the device is determined by the TMU IP Block Revision
- Register (IPBRR0) at offset 0x0BF8.
- Table of correspondences between IPBRR0 values and example chips:
- Value Device
- ---------- -----
- 0x01900102 T1040
-- reg : Address range of TMU registers.
-- interrupts : Contains the interrupt for TMU.
-- fsl,tmu-range : The values to be programmed into TTRnCR, as specified by
- the SoC reference manual. The first cell is TTR0CR, the second is
- TTR1CR, etc.
-- fsl,tmu-calibration : A list of cell pairs containing temperature
- calibration data, as specified by the SoC reference manual.
- The first cell of each pair is the value to be written to TTCFGR,
- and the second is the value to be written to TSCFGR.
-- #thermal-sensor-cells : Must be 1. The sensor specifier is the monitoring
- site ID, and represents the "n" in TRITSRn and TRATSRn.
-
-Optional property:
-- little-endian : If present, the TMU registers are little endian. If absent,
- the default is big endian.
-- clocks : the clock for clocking the TMU silicon.
-
-Example:
-
-tmu@f0000 {
- compatible = "fsl,qoriq-tmu";
- reg = <0xf0000 0x1000>;
- interrupts = <18 2 0 0>;
- fsl,tmu-range = <0x000a0000 0x00090026 0x0008004a 0x0001006a>;
- fsl,tmu-calibration = <0x00000000 0x00000025
- 0x00000001 0x00000028
- 0x00000002 0x0000002d
- 0x00000003 0x00000031
- 0x00000004 0x00000036
- 0x00000005 0x0000003a
- 0x00000006 0x00000040
- 0x00000007 0x00000044
- 0x00000008 0x0000004a
- 0x00000009 0x0000004f
- 0x0000000a 0x00000054
-
- 0x00010000 0x0000000d
- 0x00010001 0x00000013
- 0x00010002 0x00000019
- 0x00010003 0x0000001f
- 0x00010004 0x00000025
- 0x00010005 0x0000002d
- 0x00010006 0x00000033
- 0x00010007 0x00000043
- 0x00010008 0x0000004b
- 0x00010009 0x00000053
-
- 0x00020000 0x00000010
- 0x00020001 0x00000017
- 0x00020002 0x0000001f
- 0x00020003 0x00000029
- 0x00020004 0x00000031
- 0x00020005 0x0000003c
- 0x00020006 0x00000042
- 0x00020007 0x0000004d
- 0x00020008 0x00000056
-
- 0x00030000 0x00000012
- 0x00030001 0x0000001d>;
- #thermal-sensor-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml b/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
new file mode 100644
index 0000000..4bc344a
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
@@ -0,0 +1,112 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/qoriq-thermal.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Thermal Monitoring Unit (TMU) on Freescale QorIQ SoCs
+
+maintainers:
+ - Hongtao Jia <hongtao.jia@nxp.com>
+
+properties:
+ compatible:
+ description: |
+ The version of the device is determined by the TMU IP Block Revision
+ Register (IPBRR0) at offset 0x0BF8.
+ Table of correspondences between IPBRR0 values and example chips:
+ Value Device
+ ---------- -----
+ 0x01900102 T1040
+ enum:
+ - fsl,qoriq-tmu
+ - fsl,imx8mq-tmu
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ fsl,tmu-range:
+ $ref: '/schemas/types.yaml#/definitions/uint32-array'
+ description: |
+ The values to be programmed into TTRnCR, as specified by the SoC
+ reference manual. The first cell is TTR0CR, the second is TTR1CR, etc.
+ maxItems: 4
+
+ fsl,tmu-calibration:
+ $ref: '/schemas/types.yaml#/definitions/uint32-matrix'
+ description: |
+ A list of cell pairs containing temperature calibration data, as
+ specified by the SoC reference manual. The first cell of each pair
+ is the value to be written to TTCFGR, and the second is the value
+ to be written to TSCFGR.
+ items:
+ items:
+ - description: value for TTCFGR
+ - description: value for TSCFGR
+ minItems: 1
+ maxItems: 64
+
+ little-endian:
+ description: |
+ boolean, if present, the TMU registers are little endian. If absent,
+ the default is big endian.
+ type: boolean
+
+ clocks:
+ maxItems: 1
+
+ "#thermal-sensor-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - fsl,tmu-range
+ - fsl,tmu-calibration
+ - '#thermal-sensor-cells'
+
+examples:
+ - |
+ tmu@f0000 {
+ compatible = "fsl,qoriq-tmu";
+ reg = <0xf0000 0x1000>;
+ interrupts = <18 2 0 0>;
+ fsl,tmu-range = <0x000a0000 0x00090026 0x0008004a 0x0001006a>;
+ fsl,tmu-calibration = <0x00000000 0x00000025>,
+ <0x00000001 0x00000028>,
+ <0x00000002 0x0000002d>,
+ <0x00000003 0x00000031>,
+ <0x00000004 0x00000036>,
+ <0x00000005 0x0000003a>,
+ <0x00000006 0x00000040>,
+ <0x00000007 0x00000044>,
+ <0x00000008 0x0000004a>,
+ <0x00000009 0x0000004f>,
+ <0x0000000a 0x00000054>,
+ <0x00010000 0x0000000d>,
+ <0x00010001 0x00000013>,
+ <0x00010002 0x00000019>,
+ <0x00010003 0x0000001f>,
+ <0x00010004 0x00000025>,
+ <0x00010005 0x0000002d>,
+ <0x00010006 0x00000033>,
+ <0x00010007 0x00000043>,
+ <0x00010008 0x0000004b>,
+ <0x00010009 0x00000053>,
+ <0x00020000 0x00000010>,
+ <0x00020001 0x00000017>,
+ <0x00020002 0x0000001f>,
+ <0x00020003 0x00000029>,
+ <0x00020004 0x00000031>,
+ <0x00020005 0x0000003c>,
+ <0x00020006 0x00000042>,
+ <0x00020007 0x0000004d>,
+ <0x00020008 0x00000056>,
+ <0x00030000 0x00000012>,
+ <0x00030001 0x0000001d>;
+ #thermal-sensor-cells = <1>;
+ };
--
2.7.4
^ permalink raw reply related
* Re: [RFC PATCH v5 3/6] PM / devfreq: exynos-bus: Add registration of interconnect child device
From: Chanwoo Choi @ 2020-06-02 0:50 UTC (permalink / raw)
To: Sylwester Nawrocki, Chanwoo Choi
Cc: Georgi Djakov, Krzysztof Kozlowski, Artur Świgoń,
MyungJoo Ham, inki.dae, Seung-Woo Kim, Bartlomiej Zolnierkiewicz,
Marek Szyprowski, linux-kernel, linux-samsung-soc, dri-devel,
linux-arm-kernel, Rob Herring, devicetree
In-Reply-To: <8a977716-9e0e-5daf-fb22-32d943da42e5@samsung.com>
Hi Sylwester,
On 6/1/20 7:04 PM, Sylwester Nawrocki wrote:
> Cc: Rob, devicetree ML
>
> On 31.05.2020 01:57, Chanwoo Choi wrote:
>> On Sat, May 30, 2020 at 1:33 AM Sylwester Nawrocki
>> <s.nawrocki@samsung.com> wrote:
>>>
>>> This patch adds registration of a child platform device for the exynos
>>> interconnect driver. It is assumed that the interconnect provider will
>>> only be needed when #interconnect-cells property is present in the bus
>>> DT node, hence the child device will be created only when such a property
>>> is present.
>>>
>>> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
>>>
>>> Changes for v5:
>>> - new patch.
>>> ---
>>> drivers/devfreq/exynos-bus.c | 17 +++++++++++++++++
>>> 1 file changed, 17 insertions(+)
>>>
>>> diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
>>> index 8fa8eb5..856e37d 100644
>>> --- a/drivers/devfreq/exynos-bus.c
>>> +++ b/drivers/devfreq/exynos-bus.c
>>> @@ -24,6 +24,7 @@
>>>
>>> struct exynos_bus {
>>> struct device *dev;
>>> + struct platform_device *icc_pdev;
>>>
>>> struct devfreq *devfreq;
>>> struct devfreq_event_dev **edev;
>>> @@ -156,6 +157,8 @@ static void exynos_bus_exit(struct device *dev)
>>> if (ret < 0)
>>> dev_warn(dev, "failed to disable the devfreq-event devices\n");
>>>
>>> + platform_device_unregister(bus->icc_pdev);
>>> +
>>> dev_pm_opp_of_remove_table(dev);
>>> clk_disable_unprepare(bus->clk);
>>> if (bus->opp_table) {
>>> @@ -168,6 +171,8 @@ static void exynos_bus_passive_exit(struct device *dev)
>>> {
>>> struct exynos_bus *bus = dev_get_drvdata(dev);
>>>
>>> + platform_device_unregister(bus->icc_pdev);
>>> +
>>> dev_pm_opp_of_remove_table(dev);
>>> clk_disable_unprepare(bus->clk);
>>> }
>>> @@ -431,6 +436,18 @@ static int exynos_bus_probe(struct platform_device *pdev)
>>> if (ret < 0)
>>> goto err;
>>>
>>> + /* Create child platform device for the interconnect provider */
>>> + if (of_get_property(dev->of_node, "#interconnect-cells", NULL)) {
>>> + bus->icc_pdev = platform_device_register_data(
>>> + dev, "exynos-generic-icc",
>>> + PLATFORM_DEVID_AUTO, NULL, 0);
>>> +
>>> + if (IS_ERR(bus->icc_pdev)) {
>>> + ret = PTR_ERR(bus->icc_pdev);
>>> + goto err;
>>> + }
>>> + }
>>> +
>>> max_state = bus->devfreq->profile->max_state;
>>> min_freq = (bus->devfreq->profile->freq_table[0] / 1000);
>>> max_freq = (bus->devfreq->profile->freq_table[max_state - 1] / 1000);
>>> --
>>> 2.7.4
>>>
>>
>> It looks like very similar like the registering the interconnect
>> device of imx-bus.c
>> and I already reviewed and agreed this approach.
>>
>> Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
>>
>> nitpick: IMHO, I think that 'exynos-icc' is proper and simple without
>> 'generic' word.
>> If we need to add new icc compatible int the future, we will add
>> 'exynosXXXX-icc' new compatible.
>> But, I'm not forcing it. just opinion. Anyway, I agree this approach.
>
> Thanks for review. I will change the name to exynos-icc in next version,
> as I commented at other patch, it is not part of any DT binding,
> it is just for device/driver matching between devfreq and interconnect.
Thanks. I have not any objection to use either 'exynos-generic-icc'
or 'exynos-icc'. It is just my opinion. And on next version,
please add linux-pm mailing list to Cc.
--
Best Regards,
Chanwoo Choi
Samsung Electronics
^ permalink raw reply
* Re: [PATCH v1 2/6] drm: panel-simple: add Seiko 70WVW2T 7" simple panel
From: Doug Anderson @ 2020-06-02 0:31 UTC (permalink / raw)
To: Sam Ravnborg
Cc: dri-devel,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Søren Andersen, Thierry Reding, Ville Syrjälä,
Bjorn Andersson, Sebastian Reichel
In-Reply-To: <20200601083309.712606-3-sam@ravnborg.org>
Hi,
On Mon, Jun 1, 2020 at 1:33 AM Sam Ravnborg <sam@ravnborg.org> wrote:
>
> The Seiko 70WVW2T is a discontinued product, but may be used somewhere.
> Tested on a proprietary product.
>
> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
> Cc: Søren Andersen <san@skov.dk>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> ---
> drivers/gpu/drm/panel/panel-simple.c | 28 ++++++++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> index b067f66cea0e..8624bb80108c 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -3194,6 +3194,31 @@ static const struct panel_desc shelly_sca07010_bfn_lnn = {
> .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
> };
>
> +static const struct drm_display_mode sii_70wvw2t_mode = {
> + .clock = 33000,
> + .hdisplay = 800,
> + .hsync_start = 800 + 256,
> + .hsync_end = 800 + 256 + 0,
> + .htotal = 800 + 256 + 0 + 0,
> + .vdisplay = 480,
> + .vsync_start = 480 + 0,
> + .vsync_end = 480 + 0 + 0,
> + .vtotal = 480 + 0 + 0 + 45,
Important to have a "vrefresh"?
> + .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
> +};
> +
> +static const struct panel_desc sii_70wvw2t = {
> + .modes = &sii_70wvw2t_mode,
> + .num_modes = 1,
Do we want "bpc = 6"?
> + .size = {
> + .width = 152,
> + .height = 91,
> + },
> + .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
Should this be a 666 format? Random internet-found data sheet says
262K colors...
^ permalink raw reply
* Re: [PATCH v1 4/6] drm: panel-simple: add Hitachi 3.5" QVGA panel
From: Doug Anderson @ 2020-06-02 0:30 UTC (permalink / raw)
To: Sam Ravnborg
Cc: dri-devel,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Søren Andersen, Thierry Reding, Ville Syrjälä,
Bjorn Andersson, Sebastian Reichel
In-Reply-To: <20200601083309.712606-5-sam@ravnborg.org>
Hi,
On Mon, Jun 1, 2020 at 1:33 AM Sam Ravnborg <sam@ravnborg.org> wrote:
>
> This panel is used on evaluation boards for Atmel at91sam9261 and
> at91sam6263.
>
> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> ---
> drivers/gpu/drm/panel/panel-simple.c | 29 ++++++++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> index 8624bb80108c..25c96639631f 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -1813,6 +1813,32 @@ static const struct panel_desc hannstar_hsd100pxn1 = {
> .connector_type = DRM_MODE_CONNECTOR_LVDS,
> };
>
> +static const struct drm_display_mode hitachi_tx09d71vm1cca_mode = {
> + .clock = 4965000,
This is the pixel clock in kHz, right? So it runs at almost 5 Terahertz?
> + .hdisplay = 240,
> + .hsync_start = 240 + 0,
> + .hsync_end = 240 + 0 + 5,
> + .htotal = 240 + 0 + 5 + 1,
> + .vdisplay = 320,
> + .vsync_start = 320 + 0,
> + .vsync_end = 320 + 0 + 1,
> + .vtotal = 320 + 0 + 1 + 1,
Some random datasheet I found has really different numbers. If the
numbers above are what everyone is using then I suppose it's fine,
just curious why the mismatch.
Also: should you provide "vrefresh"?
-Doug
^ permalink raw reply
* Re: [PATCH v1 6/6] drm: panel-simple: add LOGIC Technologies panels
From: Doug Anderson @ 2020-06-02 0:30 UTC (permalink / raw)
To: Sam Ravnborg
Cc: dri-devel,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Søren Andersen, Thierry Reding, Ville Syrjälä,
Bjorn Andersson, Sebastian Reichel
In-Reply-To: <20200601083309.712606-7-sam@ravnborg.org>
Hi,
On Mon, Jun 1, 2020 at 1:33 AM Sam Ravnborg <sam@ravnborg.org> wrote:
>
> +static const struct drm_display_mode logictechno_lttd800480070_l6wh_rt_mode = {
> + .clock = 33000,
> + .hdisplay = 800,
> + .hsync_start = 800 + 154,
> + .hsync_end = 800 + 154 + 3,
> + .htotal = 800 + 154 + 3 + 43,
> + .vdisplay = 480,
> + .vsync_start = 480 + 47,
> + .vsync_end = 480 + 47 + 3,
> + .vtotal = 480 + 47 + 3 + 20,
> + .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
This is different than the "typ" mode from the random spreadsheet I
found on the internet:
https://logictechno.com/wp-content/uploads/2016/11/LTTD800480070-L6WH-RT-v1.1.pdf
As per my other comments, I wonder how important "vrefresh" is and if
we should include it.
-Doug
^ permalink raw reply
* [PATCH] ARM: dts: omap4-droid4: Fix spi configuration and increase rate
From: Tony Lindgren @ 2020-06-02 0:19 UTC (permalink / raw)
To: linux-omap
Cc: Benoît Cousson, devicetree, maemo-leste, Merlijn Wajer,
Pavel Machek, Sebastian Reichel
We can currently sometimes get "RXS timed out" errors and "EOT timed out"
errors with spi transfers.
These errors can be made easy to reproduce by reading the cpcap iio
values in a loop while keeping the CPUs busy by also reading /dev/urandom.
The "RXS timed out" errors we can fix by adding spi-cpol and spi-cpha
in addition to the spi-cs-high property we already have.
The "EOT timed out" errors we can fix by increasing the spi clock rate
to 9.6 MHz. Looks similar MC13783 PMIC says it works at spi clock rates
up to 20 MHz, so let's assume we can pick any rate up to 20 MHz also
for cpcap.
Cc: maemo-leste@lists.dyne.org
Cc: Merlijn Wajer <merlijn@wizzup.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/boot/dts/motorola-cpcap-mapphone.dtsi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/motorola-cpcap-mapphone.dtsi b/arch/arm/boot/dts/motorola-cpcap-mapphone.dtsi
--- a/arch/arm/boot/dts/motorola-cpcap-mapphone.dtsi
+++ b/arch/arm/boot/dts/motorola-cpcap-mapphone.dtsi
@@ -13,8 +13,10 @@ cpcap: pmic@0 {
#interrupt-cells = <2>;
#address-cells = <1>;
#size-cells = <0>;
- spi-max-frequency = <3000000>;
+ spi-max-frequency = <9600000>;
spi-cs-high;
+ spi-cpol;
+ spi-cpha;
cpcap_adc: adc {
compatible = "motorola,mapphone-cpcap-adc";
--
2.26.2
^ permalink raw reply
* Re: [PATCH v3 04/20] arm64: dts: arm: vexpress: Move fixed devices out of bus node
From: Rob Herring @ 2020-06-01 23:12 UTC (permalink / raw)
To: André Przywara
Cc: Guenter Roeck, Sudeep Holla, Liviu Dudau, Lorenzo Pieralisi,
Mark Rutland, devicetree,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <22687572-becf-7b4e-9759-cfba44677a1d@arm.com>
On Mon, Jun 1, 2020 at 4:15 AM André Przywara <andre.przywara@arm.com> wrote:
>
> On 28/05/2020 14:30, André Przywara wrote:
>
> Hi,
>
> > On 28/05/2020 03:48, Guenter Roeck wrote:
> >
> > Hi Guenter,
> >
> >> On Wed, May 13, 2020 at 11:30:00AM +0100, Andre Przywara wrote:
> >>> The devicetree compiler complains when DT nodes without a reg property
> >>> live inside a (simple) bus node:
> >>> Warning (simple_bus_reg): Node /bus@8000000/motherboard-bus/refclk32khz
> >>> missing or empty reg/ranges property
> >>>
> >>> Move the fixed clocks, the fixed regulator, the leds and the config bus
> >>> subtree to the root node, since they do not depend on any busses.
> >>>
> >>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> >>
> >> This patch results in tracebacks when booting the vexpress-a15 machine
> >> with vexpress-v2p-ca15-tc1 devicetree file in qemu. Reverting it as well
> >> as the subsequent patches affecting the same file (to avoid revert
> >> conflicts) fixes the problem.
> >
> > Many thanks for the heads up! I was able to reproduce it here. On the
> > first glance it looks like the UART is probed before the clocks now,
> > because the traversal of the changed DT leads to a different probe
> > order. I will look into how to fix this.
>
> Turned out to be a bit more complicated:
> The arm,vexpress,config-bus driver walks up the device tree to find a
> arm,vexpress,site property [1]. With this patch the first parent node
> with that property it finds is now the root node, with the wrong site ID
> (0xf instead of 0x0). So it queries the wrong clocks (those IDs are
> actually reserved there), and QEMU reports back "0", consequently [2].
> Finding a clock frequency in the range of [0, 0] won't get very far.
>
> Possible solutions are:
> 1) Just keep the mcc and its children at where it is in mainline right
> now, so *partly* reverting this patch. This has the problem of still
> producing a dtc warning, so kind of defeats the purpose of this patch.
>
> 2) Add a "arm,vexpress,site = <0>;" line to the "mcc" node itself.
> Works, but looks somewhat dodgy, as the mcc node should really be a
> child of the motherboard node, and we should not hack around this.
>
> 3) Dig deeper and fix the DT in a way that makes dtc happy. Might
> involve (dummy?) ranges or reg properties. My gut feeling is that
> arm,vexpress-sysreg,func should really have been "reg" in the first
> place, but that's too late to change now, anyway.
>
> I will post 2) as a fix if 3) turns out to be not feasible.
I would just do 1).
To some extent, the warnings are for avoiding poor design on new
bindings. We need a way to distinguish between existing boards and new
ones. Maybe dts needs to learn some warning disable annotations or we
need per target warning settings (DTC_FLAGS_foo.dtb ?). Or maybe this
check is just too strict.
Rob
^ permalink raw reply
* Re: [PATCH v8 0/5] support reserving crashkernel above 4G on arm64 kdump
From: John Donnelly @ 2020-06-01 21:59 UTC (permalink / raw)
To: Bhupesh Sharma
Cc: Prabhakar Kushwaha, Chen Zhou, Simon Horman, Devicetree List,
Baoquan He, Will Deacon, Linux Doc Mailing List, Catalin Marinas,
kexec mailing list, Linux Kernel Mailing List, Rob Herring,
Ingo Molnar, Arnd Bergmann, guohanjun, James Morse,
Thomas Gleixner, Prabhakar Kushwaha, RuiRui Yang,
linux-arm-kernel
In-Reply-To: <CACi5LpOZzdfEKUYAfYxtgeUbk9K6YFVUKLaGS8XoS0kForjH9A@mail.gmail.com>
Hi . See below !
> On Jun 1, 2020, at 4:02 PM, Bhupesh Sharma <bhsharma@redhat.com> wrote:
>
> Hi John,
>
> On Tue, Jun 2, 2020 at 1:01 AM John Donnelly <John.P.donnelly@oracle.com> wrote:
>>
>> Hi,
>>
>>
>> On 6/1/20 7:02 AM, Prabhakar Kushwaha wrote:
>>> Hi Chen,
>>>
>>> On Thu, May 21, 2020 at 3:05 PM Chen Zhou <chenzhou10@huawei.com> wrote:
>>>> This patch series enable reserving crashkernel above 4G in arm64.
>>>>
>>>> There are following issues in arm64 kdump:
>>>> 1. We use crashkernel=X to reserve crashkernel below 4G, which will fail
>>>> when there is no enough low memory.
>>>> 2. Currently, crashkernel=Y@X can be used to reserve crashkernel above 4G,
>>>> in this case, if swiotlb or DMA buffers are required, crash dump kernel
>>>> will boot failure because there is no low memory available for allocation.
>>>>
>>>> To solve these issues, introduce crashkernel=X,low to reserve specified
>>>> size low memory.
>>>> Crashkernel=X tries to reserve memory for the crash dump kernel under
>>>> 4G. If crashkernel=Y,low is specified simultaneously, reserve spcified
>>>> size low memory for crash kdump kernel devices firstly and then reserve
>>>> memory above 4G.
>>>>
>>>> When crashkernel is reserved above 4G in memory, that is, crashkernel=X,low
>>>> is specified simultaneously, kernel should reserve specified size low memory
>>>> for crash dump kernel devices. So there may be two crash kernel regions, one
>>>> is below 4G, the other is above 4G.
>>>> In order to distinct from the high region and make no effect to the use of
>>>> kexec-tools, rename the low region as "Crash kernel (low)", and add DT property
>>>> "linux,low-memory-range" to crash dump kernel's dtb to pass the low region.
>>>>
>>>> Besides, we need to modify kexec-tools:
>>>> arm64: kdump: add another DT property to crash dump kernel's dtb(see [1])
>>>>
>>>> The previous changes and discussions can be retrieved from:
>>>>
>>>> Changes since [v7]
>>>> - Move x86 CRASH_ALIGN to 2M
>>>> Suggested by Dave and do some test, move x86 CRASH_ALIGN to 2M.
>>>> - Update Documentation/devicetree/bindings/chosen.txt
>>>> Add corresponding documentation to Documentation/devicetree/bindings/chosen.txt suggested by Arnd.
>>>> - Add Tested-by from Jhon and pk
>>>>
>>>> Changes since [v6]
>>>> - Fix build errors reported by kbuild test robot.
>>>>
>>>> Changes since [v5]
>>>> - Move reserve_crashkernel_low() into kernel/crash_core.c.
>>>> - Delete crashkernel=X,high.
>>>> - Modify crashkernel=X,low.
>>>> If crashkernel=X,low is specified simultaneously, reserve spcified size low
>>>> memory for crash kdump kernel devices firstly and then reserve memory above 4G.
>>>> In addition, rename crashk_low_res as "Crash kernel (low)" for arm64, and then
>>>> pass to crash dump kernel by DT property "linux,low-memory-range".
>>>> - Update Documentation/admin-guide/kdump/kdump.rst.
>>>>
>>>> Changes since [v4]
>>>> - Reimplement memblock_cap_memory_ranges for multiple ranges by Mike.
>>>>
>>>> Changes since [v3]
>>>> - Add memblock_cap_memory_ranges back for multiple ranges.
>>>> - Fix some compiling warnings.
>>>>
>>>> Changes since [v2]
>>>> - Split patch "arm64: kdump: support reserving crashkernel above 4G" as
>>>> two. Put "move reserve_crashkernel_low() into kexec_core.c" in a separate
>>>> patch.
>>>>
>>>> Changes since [v1]:
>>>> - Move common reserve_crashkernel_low() code into kernel/kexec_core.c.
>>>> - Remove memblock_cap_memory_ranges() i added in v1 and implement that
>>>> in fdt_enforce_memory_region().
>>>> There are at most two crash kernel regions, for two crash kernel regions
>>>> case, we cap the memory range [min(regs[*].start), max(regs[*].end)]
>>>> and then remove the memory range in the middle.
>>>>
>>>> [1]: https://urldefense.com/v3/__http://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbvpn1uM1$
>>>> [v1]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/2/1174__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbt0xN9PE$
>>>> [v2]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/9/86__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbub7yUQH$
>>>> [v3]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/9/306__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbnc4zPPV$
>>>> [v4]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/15/273__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbvsAsZLu$
>>>> [v5]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/5/6/1360__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbl24n-79$
>>>> [v6]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/8/30/142__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbs7r8G2a$
>>>> [v7]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/12/23/411__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbiFUH90G$
>>>>
>>>> Chen Zhou (5):
>>>> x86: kdump: move reserve_crashkernel_low() into crash_core.c
>>>> arm64: kdump: reserve crashkenel above 4G for crash dump kernel
>>>> arm64: kdump: add memory for devices by DT property, low-memory-range
>>>> kdump: update Documentation about crashkernel on arm64
>>>> dt-bindings: chosen: Document linux,low-memory-range for arm64 kdump
>>>>
>>> We are getting "warn_alloc" [1] warning during boot of kdump kernel
>>> with bootargs as [2] of primary kernel.
>>> This error observed on ThunderX2 ARM64 platform.
>>>
>>> It is observed with latest upstream tag (v5.7-rc3) with this patch set
>>> and https://urldefense.com/v3/__https://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbiIAAlzu$
>>> Also **without** this patch-set
>>> "https://urldefense.com/v3/__https://www.spinics.net/lists/arm-kernel/msg806882.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbjC6ujMA$"
>>>
>>> This issue comes whenever crashkernel memory is reserved after 0xc000_0000.
>>> More details discussed earlier in
>>> https://urldefense.com/v3/__https://www.spinics.net/lists/arm-kernel/msg806882.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbjC6ujMA$ without any
>>> solution
>>>
>>> This patch-set is expected to solve similar kind of issue.
>>> i.e. low memory is only targeted for DMA, swiotlb; So above mentioned
>>> observation should be considered/fixed. .
>>>
>>> --pk
>>>
>>> [1]
>>> [ 30.366695] DMI: Cavium Inc. Saber/Saber, BIOS
>>> TX2-FW-Release-3.1-build_01-2803-g74253a541a mm/dd/yyyy
>>> [ 30.367696] NET: Registered protocol family 16
>>> [ 30.369973] swapper/0: page allocation failure: order:6,
>>> mode:0x1(GFP_DMA), nodemask=(null),cpuset=/,mems_allowed=0
>>> [ 30.369980] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.7.0-rc3+ #121
>>> [ 30.369981] Hardware name: Cavium Inc. Saber/Saber, BIOS
>>> TX2-FW-Release-3.1-build_01-2803-g74253a541a mm/dd/yyyy
>>> [ 30.369984] Call trace:
>>> [ 30.369989] dump_backtrace+0x0/0x1f8
>>> [ 30.369991] show_stack+0x20/0x30
>>> [ 30.369997] dump_stack+0xc0/0x10c
>>> [ 30.370001] warn_alloc+0x10c/0x178
>>> [ 30.370004] __alloc_pages_slowpath.constprop.111+0xb10/0xb50
>>> [ 30.370006] __alloc_pages_nodemask+0x2b4/0x300
>>> [ 30.370008] alloc_page_interleave+0x24/0x98
>>> [ 30.370011] alloc_pages_current+0xe4/0x108
>>> [ 30.370017] dma_atomic_pool_init+0x44/0x1a4
>>> [ 30.370020] do_one_initcall+0x54/0x228
>>> [ 30.370027] kernel_init_freeable+0x228/0x2cc
>>> [ 30.370031] kernel_init+0x1c/0x110
>>> [ 30.370034] ret_from_fork+0x10/0x18
>>> [ 30.370036] Mem-Info:
>>> [ 30.370064] active_anon:0 inactive_anon:0 isolated_anon:0
>>> [ 30.370064] active_file:0 inactive_file:0 isolated_file:0
>>> [ 30.370064] unevictable:0 dirty:0 writeback:0 unstable:0
>>> [ 30.370064] slab_reclaimable:34 slab_unreclaimable:4438
>>> [ 30.370064] mapped:0 shmem:0 pagetables:14 bounce:0
>>> [ 30.370064] free:1537719 free_pcp:219 free_cma:0
>>> [ 30.370070] Node 0 active_anon:0kB inactive_anon:0kB
>>> active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB
>>> isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB shmem:0kB
>>> shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB
>>> unstable:0kB all_unreclaimable? no
>>> [ 30.370073] Node 1 active_anon:0kB inactive_anon:0kB
>>> active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB
>>> isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB shmem:0kB
>>> shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB
>>> unstable:0kB all_unreclaimable? no
>>> [ 30.370079] Node 0 DMA free:0kB min:0kB low:0kB high:0kB
>>> reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
>>> active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
>>> present:128kB managed:0kB mlocked:0kB kernel_stack:0kB pagetables:0kB
>>> bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
>>> [ 30.370084] lowmem_reserve[]: 0 250 6063 6063
>>> [ 30.370090] Node 0 DMA32 free:256000kB min:408kB low:664kB
>>> high:920kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
>>> active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
>>> present:269700kB managed:256000kB mlocked:0kB kernel_stack:0kB
>>> pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
>>> [ 30.370094] lowmem_reserve[]: 0 0 5813 5813
>>> [ 30.370100] Node 0 Normal free:5894876kB min:9552kB low:15504kB
>>> high:21456kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
>>> active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
>>> present:8388608kB managed:5953112kB mlocked:0kB kernel_stack:21672kB
>>> pagetables:56kB bounce:0kB free_pcp:876kB local_pcp:176kB free_cma:0kB
>>> [ 30.370104] lowmem_reserve[]: 0 0 0 0
>>> [ 30.370107] Node 0 DMA: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB
>>> 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 0kB
>>> [ 30.370113] Node 0 DMA32: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB
>>> 0*256kB 0*512kB 0*1024kB 1*2048kB (M) 62*4096kB (M) = 256000kB
>>> [ 30.370119] Node 0 Normal: 2*4kB (M) 3*8kB (ME) 2*16kB (UE) 3*32kB
>>> (UM) 1*64kB (U) 2*128kB (M) 2*256kB (ME) 3*512kB (ME) 3*1024kB (ME)
>>> 3*2048kB (UME) 1436*4096kB (M) = 5893600kB
>>> [ 30.370129] Node 0 hugepages_total=0 hugepages_free=0
>>> hugepages_surp=0 hugepages_size=1048576kB
>>> [ 30.370130] 0 total pagecache pages
>>> [ 30.370132] 0 pages in swap cache
>>> [ 30.370134] Swap cache stats: add 0, delete 0, find 0/0
>>> [ 30.370135] Free swap = 0kB
>>> [ 30.370136] Total swap = 0kB
>>> [ 30.370137] 2164609 pages RAM
>>> [ 30.370139] 0 pages HighMem/MovableOnly
>>> [ 30.370140] 612331 pages reserved
>>> [ 30.370141] 0 pages hwpoisoned
>>> [ 30.370143] DMA: failed to allocate 256 KiB pool for atomic
>>> coherent allocation
>>
>>
>> During my testing I saw the same error and Chen's solution corrected it .
>
> Which combination you are using on your side? I am using Prabhakar's
> suggested environment and can reproduce the issue
> with or without Chen's crashkernel support above 4G patchset.
>
> I am also using a ThunderX2 platform with latest makedumpfile code and
> kexec-tools (with the suggested patch
> <https://urldefense.com/v3/__https://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!J6lUig58-Gw6TKZnEEYzEeSU36T-1SqlB1kImU00xtX_lss5Tx-JbUmLE9TJC3foXBLg$ >).
>
> Thanks,
> Bhupesh
I did this activity 5 months ago and I have moved on to other activities. My DMA failures were related to PCI devices that could not be enumerated because low-DMA space was not available when crashkernel was moved above 4G; I don’t recall the exact platform.
For this failure ,
>>> DMA: failed to allocate 256 KiB pool for atomic
>>> coherent allocation
Is due to :
3618082c
("arm64 use both ZONE_DMA and ZONE_DMA32")
With the introduction of ZONE_DMA to support the Raspberry DMA
region below 1G, the crashkernel is placed in the upper 4G
ZONE_DMA_32 region. Since the crashkernel does not have access
to the ZONE_DMA region, it prints out call trace during bootup.
It is due to having this CONFIG item ON :
CONFIG_ZONE_DMA=y
Turning off ZONE_DMA fixes a issue and Raspberry PI 4 will
use the device tree to specify memory below 1G.
I would like to see Chen’s feature added , perhaps as EXPERIMENTAL, so we can get some configuration testing done on it. It corrects having a DMA zone in low memory while crash-kernel is above 4GB. This has been going on for a year now.
Thank you,
John.
( Note .. I am not on the all the kernel-dlist emails so this won’t be seen by everyone , - someone may have to bounce it )
^ permalink raw reply
* Re: [PATCHv1 00/19] Improve SBS battery support
From: Sebastian Reichel @ 2020-06-01 21:57 UTC (permalink / raw)
To: Pavel Machek
Cc: Rob Herring, Greg Kroah-Hartman, Rafael J . Wysocki, linux-pm,
devicetree, linux-kernel, kernel
In-Reply-To: <20200529162704.GA3709@amd>
[-- Attachment #1: Type: text/plain, Size: 1327 bytes --]
Hi,
On Fri, May 29, 2020 at 06:27:04PM +0200, Pavel Machek wrote:
> > This patchset improves support for SBS compliant batteries. Due to
> > the changes, the battery now exposes 32 power supply properties and
> > (un)plugging it generates a backtrace containing the following message
> > without the first patch in this series:
> >
> > ---------------------------
> > WARNING: CPU: 0 PID: 20 at lib/kobject_uevent.c:659 add_uevent_var+0xd4/0x104
> > add_uevent_var: too many keys
> > ---------------------------
> >
> > For references this is what an SBS battery status looks like after
> > the patch series has been applied:
> >
> > POWER_SUPPLY_VOLTAGE_MIN_DESIGN=10800000
> > POWER_SUPPLY_VOLTAGE_MAX_DESIGN=10800000
>
> Is that correct, BTW? sounds like these should not be equal...
(Some) GE batteries have weird values stored in the SBS chip.
For example manufacturer and model name are swapped:
POWER_SUPPLY_MANUFACTURER=UR18650A
POWER_SUPPLY_MODEL_NAME=GEHC
I carefully checked manufacturer/model name when writing these
patches some time ago and came to the conclusion that the batteries
do report it the wrong way around.
I will have a look for the design voltages (which are not modified
by this patchset), but I expect this to be another GE specific thing.
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 5/5] PCI: uniphier: Add error message when failed to get phy
From: Rob Herring @ 2020-06-01 21:43 UTC (permalink / raw)
To: Kunihiko Hayashi
Cc: Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han, Gustavo Pimentel,
Masahiro Yamada, linux-pci, devicetree, linux-arm-kernel,
linux-kernel, Masami Hiramatsu, Jassi Brar
In-Reply-To: <1589536743-6684-6-git-send-email-hayashi.kunihiko@socionext.com>
On Fri, May 15, 2020 at 06:59:03PM +0900, Kunihiko Hayashi wrote:
> Even if phy driver doesn't probe, the error message can't be distinguished
> from other errors. This displays error message caused by the phy driver
> explicitly.
>
> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
> ---
> drivers/pci/controller/dwc/pcie-uniphier.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-uniphier.c b/drivers/pci/controller/dwc/pcie-uniphier.c
> index 493f105..7ae9688 100644
> --- a/drivers/pci/controller/dwc/pcie-uniphier.c
> +++ b/drivers/pci/controller/dwc/pcie-uniphier.c
> @@ -468,8 +468,11 @@ static int uniphier_pcie_probe(struct platform_device *pdev)
> return PTR_ERR(priv->rst);
>
> priv->phy = devm_phy_optional_get(dev, "pcie-phy");
> - if (IS_ERR(priv->phy))
> - return PTR_ERR(priv->phy);
> + if (IS_ERR(priv->phy)) {
> + ret = PTR_ERR(priv->phy);
> + dev_err(dev, "Failed to get phy (%d)\n", ret);
This will print an error on EPROBE_DEFERRED which isn't an error.
> + return ret;
> + }
>
> platform_set_drvdata(pdev, priv);
>
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH v2 0/3] media: rockchip: Introduce driver for the camera interface on PX30
From: Heiko Stübner @ 2020-06-01 21:38 UTC (permalink / raw)
To: Tomasz Figa
Cc: Maxime Chevallier, Helen Koike, Dafna Hirschfeld,
Mauro Carvalho Chehab, Robin Murphy, Rob Herring, Mark Rutland,
Hans Verkuil, Linux Media Mailing List, linux-devicetree
In-Reply-To: <CAAFQd5AVD+LhYZziqNUfga1sCp98MMu+ESgBMagS1n6++ae=pg@mail.gmail.com>
Hi Tomasz,
Am Montag, 1. Juni 2020, 20:45:14 CEST schrieb Tomasz Figa:
> On Fri, May 29, 2020 at 3:04 PM Maxime Chevallier
> <maxime.chevallier@bootlin.com> wrote:
> >
> > Hello everyone,
> >
> > Here's a V2 of the series adding very basic support for the camera interface on
> > the Rockchip PX30 SoC.
> >
> > Thanks to everyone that commented on the first series, your reviews were
> > very helpful :)
> >
> > This Camera Interface is also supported on other Rockchip SoC such as
> > the RK1808, RK3128, RK3288 and RK3288, but for now I've only been able to
> > test it on the PX30, using a PAL format.
>
> How does this hardware relate to the one handled by the rkisp1 driver
> that is available under staging/media/rkisp1? It was written with
> RK3399 in mind, but I have a loose recollection that the hardware in
> RK3288 was roughly the same.
(un-)educated guess would be that the rk3288 has both.
When introducing new IPs Rockchip often keeps the previous incarnation
around - probably as a fallback.
From a bit of digging around manuals and vendor-dtsi [0] I found:
in rk3288.dtsi both:
- isp: isp@ff910000
- cif_isp0: cif_isp@ff910000
- grf_con_disable_isp in GRF_SOC_CON6
- dphy_rx1_src_sel (1: isp, 0: csi host) in GRF_SOC_CON14
Heiko
[0] https://github.com/rockchip-linux/kernel/blob/develop-4.4/arch/arm/boot/dts/rk3288.dtsi
> +Helen Koike +Dafna Hirschfeld working on the rkisp1 driver.
>
> Best regards,
> Tomasz
>
> >
> > This driver is mostly based on the driver found in Rockchip's BSP, that
> > has been trimmed down to support the set of features that I was able to test,
> > that is pretty much a very basic one-frame capture and video streaming
> > with GStreamer.
> >
> > This first draft only supports the Parallel interface, although the
> > controller has support for BT656 and CSI2.
> >
> > Finally, this controller has an iommu that could be used in this driver,
> > but as of today I've not been able to get it to work.
> >
> > Any review is welcome.
> >
> > Thanks,
> >
> > Maxime
> >
> > --- Changes since V1 ---
> >
> > - Took reviews from Rob, Hans, Robin and Heiko into account :
> > - Renamed the clocks in the binding
> > - Fixed the DT schema compiling
> > - Fixed a few typos
> > - Used the clk bulk API
> > - Used the reset array API
> > - Changed a few helpers for more suitable ones
> > - Rebased on 5.7-rc7
> >
> >
> >
> > Maxime Chevallier (3):
> > media: dt-bindings: media: Document Rockchip CIF bindings
> > media: rockchip: Introduce driver for Rockhip's camera interface
> > arm64: dts: rockchip: Add the camera interface description of the PX30
> >
> > .../bindings/media/rockchip-cif.yaml | 100 ++
> > arch/arm64/boot/dts/rockchip/px30.dtsi | 12 +
> > drivers/media/platform/Kconfig | 13 +
> > drivers/media/platform/Makefile | 1 +
> > drivers/media/platform/rockchip/cif/Makefile | 3 +
> > drivers/media/platform/rockchip/cif/capture.c | 1170 +++++++++++++++++
> > drivers/media/platform/rockchip/cif/dev.c | 358 +++++
> > drivers/media/platform/rockchip/cif/dev.h | 213 +++
> > drivers/media/platform/rockchip/cif/regs.h | 256 ++++
> > 9 files changed, 2126 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/media/rockchip-cif.yaml
> > create mode 100644 drivers/media/platform/rockchip/cif/Makefile
> > create mode 100644 drivers/media/platform/rockchip/cif/capture.c
> > create mode 100644 drivers/media/platform/rockchip/cif/dev.c
> > create mode 100644 drivers/media/platform/rockchip/cif/dev.h
> > create mode 100644 drivers/media/platform/rockchip/cif/regs.h
> >
> > --
> > 2.25.4
> >
>
^ permalink raw reply
* Re: [PATCH v2 4/5] PCI: uniphier: Add iATU register support
From: Rob Herring @ 2020-06-01 21:32 UTC (permalink / raw)
To: Kunihiko Hayashi
Cc: Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han, Gustavo Pimentel,
Masahiro Yamada, linux-pci, devicetree, linux-arm-kernel,
linux-kernel, Masami Hiramatsu, Jassi Brar
In-Reply-To: <1589536743-6684-5-git-send-email-hayashi.kunihiko@socionext.com>
On Fri, May 15, 2020 at 06:59:02PM +0900, Kunihiko Hayashi wrote:
> This gets iATU register area from reg property. In Synopsis DWC version
> 4.80 or later, since iATU register area is separated from core register
> area, this area is necessary to get from DT independently.
>
> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
> ---
> drivers/pci/controller/dwc/pcie-uniphier.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/pci/controller/dwc/pcie-uniphier.c b/drivers/pci/controller/dwc/pcie-uniphier.c
> index a8dda39..493f105 100644
> --- a/drivers/pci/controller/dwc/pcie-uniphier.c
> +++ b/drivers/pci/controller/dwc/pcie-uniphier.c
> @@ -447,6 +447,13 @@ static int uniphier_pcie_probe(struct platform_device *pdev)
> if (IS_ERR(priv->pci.dbi_base))
> return PTR_ERR(priv->pci.dbi_base);
>
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "atu");
> + if (res) {
> + priv->pci.atu_base = devm_pci_remap_cfg_resource(dev, res);
This isn't config space, so this function shouldn't be used.
Use devm_platform_ioremap_resource_byname().
> + if (IS_ERR(priv->pci.atu_base))
> + priv->pci.atu_base = NULL;
> + }
> +
> res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "link");
> priv->base = devm_ioremap_resource(dev, res);
Feel free to convert this one too.
> if (IS_ERR(priv->base))
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH v4 10/10] PCI: qcom: Add Force GEN1 support
From: Rob Herring @ 2020-06-01 21:10 UTC (permalink / raw)
To: Ansuel Smith
Cc: linux-pci, Rob Herring, Andy Gross, linux-arm-msm, Mark Rutland,
Stanimir Varbanov, devicetree, Sham Muthayyan, Lorenzo Pieralisi,
linux-kernel, Bjorn Helgaas, Andrew Murray, Bjorn Andersson,
Philipp Zabel
In-Reply-To: <20200514200712.12232-11-ansuelsmth@gmail.com>
On Thu, 14 May 2020 22:07:11 +0200, Ansuel Smith wrote:
> From: Sham Muthayyan <smuthayy@codeaurora.org>
>
> Add Force GEN1 support needed in some ipq8064 board that needs to limit
> some PCIe line to gen1 for some hardware limitation. This is set by the
> max-link-speed binding and needed by some soc based on ipq8064. (for
> example Netgear R7800 router)
>
> Signed-off-by: Sham Muthayyan <smuthayy@codeaurora.org>
> Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
> ---
> drivers/pci/controller/dwc/pcie-qcom.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 08/10] PCI: qcom: Add ipq8064 rev2 variant and set tx term offset
From: Rob Herring @ 2020-06-01 21:08 UTC (permalink / raw)
To: Ansuel Smith
Cc: Bjorn Andersson, Sham Muthayyan, Andy Gross, Bjorn Helgaas,
Mark Rutland, Stanimir Varbanov, Lorenzo Pieralisi, Andrew Murray,
Philipp Zabel, linux-arm-msm, linux-pci, devicetree, linux-kernel
In-Reply-To: <20200514200712.12232-9-ansuelsmth@gmail.com>
On Thu, May 14, 2020 at 10:07:09PM +0200, Ansuel Smith wrote:
> Add tx term offset support to pcie qcom driver need in some revision of
> the ipq806x SoC. Ipq8064 have tx term offset set to 7. Ipq8064-v2 revision
> and ipq8065 have the tx term offset set to 0.
Seems like this should be 2 patches or why isn't 'Ipq8064 have tx term
offset set to 7' done in the prior patch? One tweak is needed for
stable, but this isn't?
>
> Signed-off-by: Sham Muthayyan <smuthayy@codeaurora.org>
> Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
> ---
> drivers/pci/controller/dwc/pcie-qcom.c | 18 ++++++++++++++++--
> 1 file changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
> index f5398b0d270c..ab6f1bdd24c3 100644
> --- a/drivers/pci/controller/dwc/pcie-qcom.c
> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
> @@ -45,6 +45,9 @@
> #define PCIE_CAP_CPL_TIMEOUT_DISABLE 0x10
>
> #define PCIE20_PARF_PHY_CTRL 0x40
> +#define PHY_CTRL_PHY_TX0_TERM_OFFSET_MASK GENMASK(20, 16)
> +#define PHY_CTRL_PHY_TX0_TERM_OFFSET(x) ((x) << 16)
> +
> #define PCIE20_PARF_PHY_REFCLK 0x4C
> #define PHY_REFCLK_SSP_EN BIT(16)
> #define PHY_REFCLK_USE_PAD BIT(12)
> @@ -363,7 +366,8 @@ static int qcom_pcie_init_2_1_0(struct qcom_pcie *pcie)
> val &= ~BIT(0);
> writel(val, pcie->parf + PCIE20_PARF_PHY_CTRL);
>
> - if (of_device_is_compatible(node, "qcom,pcie-ipq8064")) {
> + if (of_device_is_compatible(node, "qcom,pcie-ipq8064") |
> + of_device_is_compatible(node, "qcom,pcie-ipq8064-v2")) {
> writel(PCS_DEEMPH_TX_DEEMPH_GEN1(24) |
> PCS_DEEMPH_TX_DEEMPH_GEN2_3_5DB(24) |
> PCS_DEEMPH_TX_DEEMPH_GEN2_6DB(34),
> @@ -374,9 +378,18 @@ static int qcom_pcie_init_2_1_0(struct qcom_pcie *pcie)
> writel(PHY_RX0_EQ(4), pcie->parf + PCIE20_PARF_CONFIG_BITS);
> }
>
> + if (of_device_is_compatible(node, "qcom,pcie-ipq8064")) {
> + /* set TX termination offset */
> + val = readl(pcie->parf + PCIE20_PARF_PHY_CTRL);
> + val &= ~PHY_CTRL_PHY_TX0_TERM_OFFSET_MASK;
> + val |= PHY_CTRL_PHY_TX0_TERM_OFFSET(7);
> + writel(val, pcie->parf + PCIE20_PARF_PHY_CTRL);
> + }
> +
> /* enable external reference clock */
> val = readl(pcie->parf + PCIE20_PARF_PHY_REFCLK);
> - val |= BIT(16);
> + val &= ~PHY_REFCLK_USE_PAD;
> + val |= PHY_REFCLK_SSP_EN;
> writel(val, pcie->parf + PCIE20_PARF_PHY_REFCLK);
>
> /* wait for clock acquisition */
> @@ -1452,6 +1465,7 @@ static int qcom_pcie_probe(struct platform_device *pdev)
> static const struct of_device_id qcom_pcie_match[] = {
> { .compatible = "qcom,pcie-apq8084", .data = &ops_1_0_0 },
> { .compatible = "qcom,pcie-ipq8064", .data = &ops_2_1_0 },
> + { .compatible = "qcom,pcie-ipq8064-v2", .data = &ops_2_1_0 },
> { .compatible = "qcom,pcie-apq8064", .data = &ops_2_1_0 },
> { .compatible = "qcom,pcie-msm8996", .data = &ops_2_3_2 },
> { .compatible = "qcom,pcie-ipq8074", .data = &ops_2_3_3 },
> --
> 2.25.1
>
^ permalink raw reply
* Re: [PATCH v4 07/10] PCI: qcom: Define some PARF params needed for ipq8064 SoC
From: Rob Herring @ 2020-06-01 21:04 UTC (permalink / raw)
To: Ansuel Smith
Cc: linux-pci, stable, Philipp Zabel, linux-kernel, devicetree,
Andy Gross, Stanimir Varbanov, Andrew Murray, linux-arm-msm,
Bjorn Helgaas, Rob Herring, Bjorn Andersson, Lorenzo Pieralisi,
Mark Rutland
In-Reply-To: <20200514200712.12232-8-ansuelsmth@gmail.com>
On Thu, 14 May 2020 22:07:08 +0200, Ansuel Smith wrote:
> Set some specific value for Tx De-Emphasis, Tx Swing and Rx equalization
> needed on some ipq8064 based device (Netgear R7800 for example). Without
> this the system locks on kernel load.
>
> Fixes: 82a823833f4e ("PCI: qcom: Add Qualcomm PCIe controller driver")
> Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
> Cc: stable@vger.kernel.org # v4.5+
> ---
> drivers/pci/controller/dwc/pcie-qcom.c | 27 ++++++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v8 0/5] support reserving crashkernel above 4G on arm64 kdump
From: Bhupesh Sharma @ 2020-06-01 21:02 UTC (permalink / raw)
To: John Donnelly
Cc: Prabhakar Kushwaha, Chen Zhou, Simon Horman, Devicetree List,
Baoquan He, Will Deacon, Linux Doc Mailing List, Catalin Marinas,
kexec mailing list, Linux Kernel Mailing List, Rob Herring,
Ingo Molnar, Arnd Bergmann, guohanjun, James Morse,
Thomas Gleixner, Prabhakar Kushwaha, RuiRui Yang,
linux-arm-kernel
In-Reply-To: <303695cc-d3ea-9f51-1489-07d27d4253d4@oracle.com>
Hi John,
On Tue, Jun 2, 2020 at 1:01 AM John Donnelly <John.P.donnelly@oracle.com> wrote:
>
> Hi,
>
>
> On 6/1/20 7:02 AM, Prabhakar Kushwaha wrote:
> > Hi Chen,
> >
> > On Thu, May 21, 2020 at 3:05 PM Chen Zhou <chenzhou10@huawei.com> wrote:
> >> This patch series enable reserving crashkernel above 4G in arm64.
> >>
> >> There are following issues in arm64 kdump:
> >> 1. We use crashkernel=X to reserve crashkernel below 4G, which will fail
> >> when there is no enough low memory.
> >> 2. Currently, crashkernel=Y@X can be used to reserve crashkernel above 4G,
> >> in this case, if swiotlb or DMA buffers are required, crash dump kernel
> >> will boot failure because there is no low memory available for allocation.
> >>
> >> To solve these issues, introduce crashkernel=X,low to reserve specified
> >> size low memory.
> >> Crashkernel=X tries to reserve memory for the crash dump kernel under
> >> 4G. If crashkernel=Y,low is specified simultaneously, reserve spcified
> >> size low memory for crash kdump kernel devices firstly and then reserve
> >> memory above 4G.
> >>
> >> When crashkernel is reserved above 4G in memory, that is, crashkernel=X,low
> >> is specified simultaneously, kernel should reserve specified size low memory
> >> for crash dump kernel devices. So there may be two crash kernel regions, one
> >> is below 4G, the other is above 4G.
> >> In order to distinct from the high region and make no effect to the use of
> >> kexec-tools, rename the low region as "Crash kernel (low)", and add DT property
> >> "linux,low-memory-range" to crash dump kernel's dtb to pass the low region.
> >>
> >> Besides, we need to modify kexec-tools:
> >> arm64: kdump: add another DT property to crash dump kernel's dtb(see [1])
> >>
> >> The previous changes and discussions can be retrieved from:
> >>
> >> Changes since [v7]
> >> - Move x86 CRASH_ALIGN to 2M
> >> Suggested by Dave and do some test, move x86 CRASH_ALIGN to 2M.
> >> - Update Documentation/devicetree/bindings/chosen.txt
> >> Add corresponding documentation to Documentation/devicetree/bindings/chosen.txt suggested by Arnd.
> >> - Add Tested-by from Jhon and pk
> >>
> >> Changes since [v6]
> >> - Fix build errors reported by kbuild test robot.
> >>
> >> Changes since [v5]
> >> - Move reserve_crashkernel_low() into kernel/crash_core.c.
> >> - Delete crashkernel=X,high.
> >> - Modify crashkernel=X,low.
> >> If crashkernel=X,low is specified simultaneously, reserve spcified size low
> >> memory for crash kdump kernel devices firstly and then reserve memory above 4G.
> >> In addition, rename crashk_low_res as "Crash kernel (low)" for arm64, and then
> >> pass to crash dump kernel by DT property "linux,low-memory-range".
> >> - Update Documentation/admin-guide/kdump/kdump.rst.
> >>
> >> Changes since [v4]
> >> - Reimplement memblock_cap_memory_ranges for multiple ranges by Mike.
> >>
> >> Changes since [v3]
> >> - Add memblock_cap_memory_ranges back for multiple ranges.
> >> - Fix some compiling warnings.
> >>
> >> Changes since [v2]
> >> - Split patch "arm64: kdump: support reserving crashkernel above 4G" as
> >> two. Put "move reserve_crashkernel_low() into kexec_core.c" in a separate
> >> patch.
> >>
> >> Changes since [v1]:
> >> - Move common reserve_crashkernel_low() code into kernel/kexec_core.c.
> >> - Remove memblock_cap_memory_ranges() i added in v1 and implement that
> >> in fdt_enforce_memory_region().
> >> There are at most two crash kernel regions, for two crash kernel regions
> >> case, we cap the memory range [min(regs[*].start), max(regs[*].end)]
> >> and then remove the memory range in the middle.
> >>
> >> [1]: https://urldefense.com/v3/__http://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbvpn1uM1$
> >> [v1]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/2/1174__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbt0xN9PE$
> >> [v2]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/9/86__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbub7yUQH$
> >> [v3]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/9/306__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbnc4zPPV$
> >> [v4]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/15/273__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbvsAsZLu$
> >> [v5]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/5/6/1360__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbl24n-79$
> >> [v6]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/8/30/142__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbs7r8G2a$
> >> [v7]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/12/23/411__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbiFUH90G$
> >>
> >> Chen Zhou (5):
> >> x86: kdump: move reserve_crashkernel_low() into crash_core.c
> >> arm64: kdump: reserve crashkenel above 4G for crash dump kernel
> >> arm64: kdump: add memory for devices by DT property, low-memory-range
> >> kdump: update Documentation about crashkernel on arm64
> >> dt-bindings: chosen: Document linux,low-memory-range for arm64 kdump
> >>
> > We are getting "warn_alloc" [1] warning during boot of kdump kernel
> > with bootargs as [2] of primary kernel.
> > This error observed on ThunderX2 ARM64 platform.
> >
> > It is observed with latest upstream tag (v5.7-rc3) with this patch set
> > and https://urldefense.com/v3/__https://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbiIAAlzu$
> > Also **without** this patch-set
> > "https://urldefense.com/v3/__https://www.spinics.net/lists/arm-kernel/msg806882.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbjC6ujMA$"
> >
> > This issue comes whenever crashkernel memory is reserved after 0xc000_0000.
> > More details discussed earlier in
> > https://urldefense.com/v3/__https://www.spinics.net/lists/arm-kernel/msg806882.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbjC6ujMA$ without any
> > solution
> >
> > This patch-set is expected to solve similar kind of issue.
> > i.e. low memory is only targeted for DMA, swiotlb; So above mentioned
> > observation should be considered/fixed. .
> >
> > --pk
> >
> > [1]
> > [ 30.366695] DMI: Cavium Inc. Saber/Saber, BIOS
> > TX2-FW-Release-3.1-build_01-2803-g74253a541a mm/dd/yyyy
> > [ 30.367696] NET: Registered protocol family 16
> > [ 30.369973] swapper/0: page allocation failure: order:6,
> > mode:0x1(GFP_DMA), nodemask=(null),cpuset=/,mems_allowed=0
> > [ 30.369980] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.7.0-rc3+ #121
> > [ 30.369981] Hardware name: Cavium Inc. Saber/Saber, BIOS
> > TX2-FW-Release-3.1-build_01-2803-g74253a541a mm/dd/yyyy
> > [ 30.369984] Call trace:
> > [ 30.369989] dump_backtrace+0x0/0x1f8
> > [ 30.369991] show_stack+0x20/0x30
> > [ 30.369997] dump_stack+0xc0/0x10c
> > [ 30.370001] warn_alloc+0x10c/0x178
> > [ 30.370004] __alloc_pages_slowpath.constprop.111+0xb10/0xb50
> > [ 30.370006] __alloc_pages_nodemask+0x2b4/0x300
> > [ 30.370008] alloc_page_interleave+0x24/0x98
> > [ 30.370011] alloc_pages_current+0xe4/0x108
> > [ 30.370017] dma_atomic_pool_init+0x44/0x1a4
> > [ 30.370020] do_one_initcall+0x54/0x228
> > [ 30.370027] kernel_init_freeable+0x228/0x2cc
> > [ 30.370031] kernel_init+0x1c/0x110
> > [ 30.370034] ret_from_fork+0x10/0x18
> > [ 30.370036] Mem-Info:
> > [ 30.370064] active_anon:0 inactive_anon:0 isolated_anon:0
> > [ 30.370064] active_file:0 inactive_file:0 isolated_file:0
> > [ 30.370064] unevictable:0 dirty:0 writeback:0 unstable:0
> > [ 30.370064] slab_reclaimable:34 slab_unreclaimable:4438
> > [ 30.370064] mapped:0 shmem:0 pagetables:14 bounce:0
> > [ 30.370064] free:1537719 free_pcp:219 free_cma:0
> > [ 30.370070] Node 0 active_anon:0kB inactive_anon:0kB
> > active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB
> > isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB shmem:0kB
> > shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB
> > unstable:0kB all_unreclaimable? no
> > [ 30.370073] Node 1 active_anon:0kB inactive_anon:0kB
> > active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB
> > isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB shmem:0kB
> > shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB
> > unstable:0kB all_unreclaimable? no
> > [ 30.370079] Node 0 DMA free:0kB min:0kB low:0kB high:0kB
> > reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
> > active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
> > present:128kB managed:0kB mlocked:0kB kernel_stack:0kB pagetables:0kB
> > bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
> > [ 30.370084] lowmem_reserve[]: 0 250 6063 6063
> > [ 30.370090] Node 0 DMA32 free:256000kB min:408kB low:664kB
> > high:920kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
> > active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
> > present:269700kB managed:256000kB mlocked:0kB kernel_stack:0kB
> > pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
> > [ 30.370094] lowmem_reserve[]: 0 0 5813 5813
> > [ 30.370100] Node 0 Normal free:5894876kB min:9552kB low:15504kB
> > high:21456kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
> > active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
> > present:8388608kB managed:5953112kB mlocked:0kB kernel_stack:21672kB
> > pagetables:56kB bounce:0kB free_pcp:876kB local_pcp:176kB free_cma:0kB
> > [ 30.370104] lowmem_reserve[]: 0 0 0 0
> > [ 30.370107] Node 0 DMA: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB
> > 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 0kB
> > [ 30.370113] Node 0 DMA32: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB
> > 0*256kB 0*512kB 0*1024kB 1*2048kB (M) 62*4096kB (M) = 256000kB
> > [ 30.370119] Node 0 Normal: 2*4kB (M) 3*8kB (ME) 2*16kB (UE) 3*32kB
> > (UM) 1*64kB (U) 2*128kB (M) 2*256kB (ME) 3*512kB (ME) 3*1024kB (ME)
> > 3*2048kB (UME) 1436*4096kB (M) = 5893600kB
> > [ 30.370129] Node 0 hugepages_total=0 hugepages_free=0
> > hugepages_surp=0 hugepages_size=1048576kB
> > [ 30.370130] 0 total pagecache pages
> > [ 30.370132] 0 pages in swap cache
> > [ 30.370134] Swap cache stats: add 0, delete 0, find 0/0
> > [ 30.370135] Free swap = 0kB
> > [ 30.370136] Total swap = 0kB
> > [ 30.370137] 2164609 pages RAM
> > [ 30.370139] 0 pages HighMem/MovableOnly
> > [ 30.370140] 612331 pages reserved
> > [ 30.370141] 0 pages hwpoisoned
> > [ 30.370143] DMA: failed to allocate 256 KiB pool for atomic
> > coherent allocation
>
>
> During my testing I saw the same error and Chen's solution corrected it .
Which combination you are using on your side? I am using Prabhakar's
suggested environment and can reproduce the issue
with or without Chen's crashkernel support above 4G patchset.
I am also using a ThunderX2 platform with latest makedumpfile code and
kexec-tools (with the suggested patch
<https://lists.infradead.org/pipermail/kexec/2020-May/025128.html>).
Thanks,
Bhupesh
^ permalink raw reply
* Re: [PATCH v4 06/10] PCI: qcom: Use bulk clk api and assert on error
From: Rob Herring @ 2020-06-01 21:02 UTC (permalink / raw)
To: Ansuel Smith
Cc: linux-arm-msm, Bjorn Andersson, Mark Rutland, Andy Gross,
devicetree, Rob Herring, linux-pci, Lorenzo Pieralisi,
Andrew Murray, Stanimir Varbanov, Philipp Zabel, linux-kernel,
Bjorn Helgaas
In-Reply-To: <20200514200712.12232-7-ansuelsmth@gmail.com>
On Thu, 14 May 2020 22:07:07 +0200, Ansuel Smith wrote:
> Rework 2.1.0 revision to use bulk clk api and fix missing assert on
> reset_control_deassert error.
>
> Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
> ---
> drivers/pci/controller/dwc/pcie-qcom.c | 131 +++++++++----------------
> 1 file changed, 46 insertions(+), 85 deletions(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 01/10] PCI: qcom: Add missing ipq806x clocks in PCIe driver
From: Rob Herring @ 2020-06-01 20:56 UTC (permalink / raw)
To: Ansuel Smith
Cc: linux-arm-msm, devicetree, Andy Gross, Andrew Murray,
Mark Rutland, Stanimir Varbanov, linux-pci, Lorenzo Pieralisi,
Rob Herring, Sham Muthayyan, Bjorn Andersson, Philipp Zabel,
linux-kernel, Bjorn Helgaas
In-Reply-To: <20200514200712.12232-2-ansuelsmth@gmail.com>
On Thu, 14 May 2020 22:07:02 +0200, Ansuel Smith wrote:
> Aux and Ref clk are missing in PCIe qcom driver. Add support for this
> optional clks for ipq8064/apq8064 SoC.
>
> Fixes: 82a823833f4e ("PCI: qcom: Add Qualcomm PCIe controller driver")
> Signed-off-by: Sham Muthayyan <smuthayy@codeaurora.org>
> Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
> ---
> drivers/pci/controller/dwc/pcie-qcom.c | 38 ++++++++++++++++++++++----
> 1 file changed, 33 insertions(+), 5 deletions(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: Subject: [PATCH v9 2/2] PCI: Microchip: Add host driver for Microchip PCIe controller
From: Rob Herring @ 2020-06-01 20:39 UTC (permalink / raw)
To: Daire.McNamara
Cc: amurray, lorenzo.pieralisi, linux-pci, bhelgaas, devicetree
In-Reply-To: <f08d04901b66a1d2d9329d5cc6bb47864d66254f.camel@microchip.com>
On Wed, May 20, 2020 at 11:46:32AM +0000, Daire.McNamara@microchip.com wrote:
>
Something mangled the subject.
> This patch adds support for the Microchip PCIe PolarFire PCIe
> controller when configured in host (Root Complex) mode.
>
> Signed-off-by: Daire McNamara <daire.mcnamara@microchip.com>
> ---
> drivers/pci/controller/Kconfig | 9 +
> drivers/pci/controller/Makefile | 1 +
> drivers/pci/controller/pcie-microchip-host.c | 664 +++++++++++++++++++
> 3 files changed, 674 insertions(+)
> create mode 100644 drivers/pci/controller/pcie-microchip-host.c
>
> diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
> index 91bfdb784829..5ec760466bd9 100644
> --- a/drivers/pci/controller/Kconfig
> +++ b/drivers/pci/controller/Kconfig
> @@ -258,6 +258,15 @@ config PCI_HYPERV_INTERFACE
> The Hyper-V PCI Interface is a helper driver allows other drivers to
> have a common interface with the Hyper-V PCI frontend driver.
>
> +config PCIE_MICROCHIP_HOST
> + bool "Microchip AXI PCIe host bridge support"
> + depends on PCI_MSI && OF
> + select PCI_MSI_IRQ_DOMAIN
> + select GENERIC_MSI_IRQ_DOMAIN
> + help
> + Say Y here if you want kernel to support the Microchip AXI PCIe
> + Host Bridge driver.
> +
> source "drivers/pci/controller/dwc/Kconfig"
> source "drivers/pci/controller/mobiveil/Kconfig"
> source "drivers/pci/controller/cadence/Kconfig"
> diff --git a/drivers/pci/controller/Makefile b/drivers/pci/controller/Makefile
> index 158c59771824..416528d8553e 100644
> --- a/drivers/pci/controller/Makefile
> +++ b/drivers/pci/controller/Makefile
> @@ -26,6 +26,7 @@ obj-$(CONFIG_PCIE_ROCKCHIP_EP) += pcie-rockchip-ep.o
> obj-$(CONFIG_PCIE_ROCKCHIP_HOST) += pcie-rockchip-host.o
> obj-$(CONFIG_PCIE_MEDIATEK) += pcie-mediatek.o
> obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
> +obj-$(CONFIG_PCIE_MICROCHIP_HOST) += pcie-microchip-host.o
> obj-$(CONFIG_VMD) += vmd.o
> obj-$(CONFIG_PCIE_BRCMSTB) += pcie-brcmstb.o
> # pcie-hisi.o quirks are needed even without CONFIG_PCIE_DW
> diff --git a/drivers/pci/controller/pcie-microchip-host.c b/drivers/pci/controller/pcie-microchip-host.c
> new file mode 100644
> index 000000000000..bdea416aff79
> --- /dev/null
> +++ b/drivers/pci/controller/pcie-microchip-host.c
> @@ -0,0 +1,664 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Microchip AXI PCIe Bridge host controller driver
> + *
> + * Copyright (c) 2018 - 2019 Microchip Corporation. All rights reserved.
> + *
> + * Author: Daire McNamara <daire.mcnamara@microchip.com>
> + *
> + * Based on:
> + * pcie-rcar.c
> + * pcie-xilinx.c
> + * pcie-altera.c
> + */
> +#include <linux/irqchip/chained_irq.h>
> +#include <linux/module.h>
> +#include <linux/msi.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_pci.h>
> +#include <linux/pci-ecam.h>
> +#include <linux/platform_device.h>
> +
> +#include "../pci.h"
> +
> +/* Number of MSI IRQs */
> +#define MC_NUM_MSI_IRQS 32
> +#define MC_NUM_MSI_IRQS_CODED 5
> +
> +/* PCIe Bridge Phy and Controller Phy offsets */
> +#define MC_PCIE1_BRIDGE_ADDR 0x00008000u
> +#define MC_PCIE1_CTRL_ADDR 0x0000a000u
> +
> +/* PCIe Controller Phy Regs */
> +#define MC_SEC_ERROR_INT 0x28
> +#define SEC_ERROR_INT_TX_RAM_SEC_ERR_INT GENMASK(3, 0)
> +#define SEC_ERROR_INT_RX_RAM_SEC_ERR_INT GENMASK(7, 4)
> +#define SEC_ERROR_INT_PCIE2AXI_RAM_SEC_ERR_INT GENMASK(11, 8)
> +#define SEC_ERROR_INT_AXI2PCIE_RAM_SEC_ERR_INT GENMASK(15, 12)
> +#define MC_SEC_ERROR_INT_MASK 0x2c
> +#define MC_DED_ERROR_INT 0x30
> +#define DED_ERROR_INT_TX_RAM_DED_ERR_INT GENMASK(3, 0)
> +#define DED_ERROR_INT_RX_RAM_DED_ERR_INT GENMASK(7, 4)
> +#define DED_ERROR_INT_PCIE2AXI_RAM_DED_ERR_INT GENMASK(11, 8)
> +#define DED_ERROR_INT_AXI2PCIE_RAM_DED_ERR_INT GENMASK(15, 12)
> +#define MC_DED_ERROR_INT_MASK 0x34
> +#define MC_ECC_CONTROL 0x38
> +#define ECC_CONTROL_AXI2PCIE_RAM_ECC_BYPASS BIT(27)
> +#define ECC_CONTROL_PCIE2AXI_RAM_ECC_BYPASS BIT(26)
> +#define ECC_CONTROL_RX_RAM_ECC_BYPASS BIT(25)
> +#define ECC_CONTROL_TX_RAM_ECC_BYPASS BIT(24)
> +#define MC_LTSSM_STATE 0x5c
> +#define LTSSM_L0_STATE 0x10
> +#define MC_PCIE_EVENT_INT 0x14c
> +#define PCIE_EVENT_INT_L2_EXIT_INT BIT(0)
> +#define PCIE_EVENT_INT_HOTRST_EXIT_INT BIT(1)
> +#define PCIE_EVENT_INT_DLUP_EXIT_INT BIT(2)
> +#define PCIE_EVENT_INT_L2_EXIT_INT_MASK BIT(16)
> +#define PCIE_EVENT_INT_HOTRST_EXIT_INT_MASK BIT(17)
> +#define PCIE_EVENT_INT_DLUP_EXIT_INT_MASK BIT(18)
> +
> +/* PCIe Bridge Phy Regs */
> +#define MC_PCIE_PCI_IDS_DW1 0x9c
> +
> +/* PCIe Config space MSI capability structure */
> +#define MC_MSI_CAP_CTRL 0xe0u
> +#define MSI_ENABLE (0x01u << 16)
> +#define MSI_CAP_MULTI (MC_NUM_MSI_IRQS_CODED << 17)
> +#define MSI_ENABLE_MULTI (MC_NUM_MSI_IRQS_CODED << 20)
> +#define MC_MSI_MSG_LO_ADDR 0xe4u
> +#define MC_MSI_MSG_HI_ADDR 0xe8u
> +#define MC_MSI_MSG_DATA 0xf0u
There's standard definitions for these registers, use them.
> +
> +#define MC_IMASK_LOCAL 0x180
> +#define PCIE_LOCAL_INT_ENABLE 0x0f000000u
> +#define PCI_INTS 0x0f000000u
> +#define PM_MSI_INT_SHIFT 24
> +#define PCIE_ENABLE_MSI 0x10000000u
> +#define MSI_INT 0x10000000u
> +#define MSI_INT_SHIFT 28
> +#define MC_ISTATUS_LOCAL 0x184
> +#define MC_IMASK_HOST 0x188
> +#define MC_ISTATUS_HOST 0x18c
> +#define MC_MSI_ADDR 0x190
> +#define MC_ISTATUS_MSI 0x194
> +
> +/* PCIe Master table init defines */
> +#define MC_ATR0_PCIE_WIN0_SRCADDR_PARAM 0x600u
> +#define ATR0_PCIE_ATR_SIZE 0x1f
> +#define ATR0_PCIE_ATR_SIZE_SHIFT 1
> +#define MC_ATR0_PCIE_WIN0_SRC_ADDR 0x604u
> +#define MC_ATR0_PCIE_WIN0_TRSL_ADDR_LSB 0x608u
> +#define MC_ATR0_PCIE_WIN0_TRSL_ADDR_UDW 0x60cu
> +#define MC_ATR0_PCIE_WIN0_TRSL_PARAM 0x610u
> +
> +/* PCIe AXI slave table init defines */
> +#define MC_ATR0_AXI4_SLV0_SRCADDR_PARAM 0x800u
> +#define ATR_SIZE_SHIFT 1
> +#define ATR_IMPL_ENABLE 1
> +#define MC_ATR0_AXI4_SLV0_SRC_ADDR 0x804u
> +#define MC_ATR0_AXI4_SLV0_TRSL_ADDR_LSB 0x808u
> +#define MC_ATR0_AXI4_SLV0_TRSL_ADDR_UDW 0x80cu
> +#define MC_ATR0_AXI4_SLV0_TRSL_PARAM 0x810u
> +#define PCIE_TX_RX_INTERFACE 0x00000000u
> +#define PCIE_CONFIG_INTERFACE 0x00000001u
> +
> +#define ATT_ENTRY_SIZE 32
> +
> +struct mc_msi {
> + struct mutex lock; /* Protect used bitmap */
> + struct irq_domain *msi_domain;
> + struct irq_domain *dev_domain;
> + u32 num_vectors;
> + u64 vector_phy;
> + DECLARE_BITMAP(used, MC_NUM_MSI_IRQS);
> +};
> +
> +struct mc_pcie {
> + struct platform_device *pdev;
> + void __iomem *cfg_base_addr;
> + void __iomem *bridge_base_addr;
> + void __iomem *ctrl_base_addr;
> + u64 cfghw_base_addr;
> + u64 cfg_size;
> + u32 atr_sz;
> + u32 irq;
These are all already stored as resources, no reason to store them again
here.
> + struct irq_domain *intx_domain;
> + raw_spinlock_t intx_mask_lock;
> + struct mc_msi msi;
> +};
> +
> +static inline u32 cfg_readl(struct mc_pcie *pcie, const u32 reg)
> +{
> + return readl_relaxed(pcie->cfg_base_addr + reg);
> +}
> +
> +static inline void cfg_writel(struct mc_pcie *pcie, const u32 val,
> + const u32 reg)
> +{
> + writel_relaxed(val, pcie->cfg_base_addr + reg);
> +}
> +
> +static void mc_pcie_enable(struct mc_pcie *pcie)
> +{
> + u32 enb;
> +
> + enb = readl(pcie->bridge_base_addr + MC_LTSSM_STATE);
> + enb |= LTSSM_L0_STATE;
> + writel(enb, pcie->bridge_base_addr + MC_LTSSM_STATE);
> +}
> +
> +static void mc_pcie_isr(struct irq_desc *desc)
> +{
> + struct irq_chip *chip = irq_desc_get_chip(desc);
> + struct mc_pcie *pcie = irq_desc_get_handler_data(desc);
> + struct device *dev = &pcie->pdev->dev;
> + struct mc_msi *msi = &pcie->msi;
> + unsigned long status;
> + unsigned long intx_status;
> + unsigned long msi_status;
> + u32 bit;
> + u32 virq;
> +
> + /*
> + * The core provides a single interrupt for both INTx/MSI messages.
> + * So we'll read both INTx and MSI status.
> + */
> + chained_irq_enter(chip, desc);
> +
> + status = readl(pcie->bridge_base_addr + MC_ISTATUS_LOCAL);
> + while (status & (PCI_INTS | MSI_INT)) {
> + intx_status = (status & PCI_INTS) >> PM_MSI_INT_SHIFT;
> + for_each_set_bit(bit, &intx_status, PCI_NUM_INTX) {
> + virq = irq_find_mapping(pcie->intx_domain, bit + 1);
> + if (virq)
> + generic_handle_irq(virq);
> + else
> + dev_err_ratelimited(dev, "bad INTx IRQ %d\n",
> + bit);
> +
> + /* Clear that interrupt bit */
> + writel(1 << (bit + PM_MSI_INT_SHIFT),
> + pcie->bridge_base_addr + MC_ISTATUS_LOCAL);
> + }
> +
> + msi_status = (status & MSI_INT);
> + if (msi_status) {
> + msi_status = readl(pcie->bridge_base_addr +
> + MC_ISTATUS_MSI);
> + for_each_set_bit(bit, &msi_status, msi->num_vectors) {
> + virq = irq_find_mapping(msi->dev_domain, bit);
> + if (virq)
> + generic_handle_irq(virq);
> + else
> + dev_err_ratelimited(dev,
> + "bad MSI IRQ %d\n",
> + bit);
> +
> + /* Clear that MSI interrupt bit */
> + writel((1 << bit), pcie->bridge_base_addr +
> + MC_ISTATUS_MSI);
> + }
> + /* Clear the ISTATUS MSI bit */
> + writel(1 << MSI_INT_SHIFT, pcie->bridge_base_addr +
> + MC_ISTATUS_LOCAL);
> + }
> +
> + status = readl(pcie->bridge_base_addr + MC_ISTATUS_LOCAL);
> + }
> +
> + chained_irq_exit(chip, desc);
> +}
> +
> +static int mc_pcie_parse_dt(struct mc_pcie *pcie)
> +{
> + struct platform_device *pdev = pcie->pdev;
> + struct device *dev = &pcie->pdev->dev;
> + struct mc_msi *msi = &pcie->msi;
> + struct resource *res;
> + void __iomem *axi_base_addr;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> + axi_base_addr = devm_ioremap_resource(dev, res);
> + if (IS_ERR(axi_base_addr))
> + return PTR_ERR(axi_base_addr);
> +
> + pcie->bridge_base_addr = axi_base_addr + MC_PCIE1_BRIDGE_ADDR;
> + pcie->ctrl_base_addr = axi_base_addr + MC_PCIE1_CTRL_ADDR;
> +
> + msi->vector_phy = MC_MSI_ADDR;
> +
> + msi->num_vectors = MC_NUM_MSI_IRQS;
> +
> + pcie->irq = platform_get_irq(pdev, 0);
> + if (pcie->irq < 0) {
> + dev_err(dev, "unable to request IRQ%d\n", pcie->irq);
> + return -ENODEV;
> + }
> +
> + return 0;
> +}
> +
> +static void mc_pcie_enable_msi(struct mc_pcie *pcie)
> +{
> + struct mc_msi *msi = &pcie->msi;
> + u32 msg_ctrl = cfg_readl(pcie, MC_MSI_CAP_CTRL);
> +
> + msg_ctrl |= MSI_ENABLE_MULTI | MSI_CAP_MULTI | MSI_ENABLE;
> + cfg_writel(pcie, msg_ctrl, MC_MSI_CAP_CTRL);
> +
> + cfg_writel(pcie, lower_32_bits(msi->vector_phy), MC_MSI_MSG_LO_ADDR);
> + cfg_writel(pcie, upper_32_bits(msi->vector_phy), MC_MSI_MSG_HI_ADDR);
> +}
> +
> +static int mc_host_init(struct mc_pcie *pcie)
> +{
> + u32 val;
> +
> + mc_pcie_enable(pcie);
> +
> + val = ECC_CONTROL_AXI2PCIE_RAM_ECC_BYPASS |
> + ECC_CONTROL_PCIE2AXI_RAM_ECC_BYPASS |
> + ECC_CONTROL_RX_RAM_ECC_BYPASS | ECC_CONTROL_TX_RAM_ECC_BYPASS;
> + writel(val, pcie->ctrl_base_addr + MC_ECC_CONTROL);
These should all be able to use the _relaxed variant.
> +
> + val = PCIE_EVENT_INT_L2_EXIT_INT | PCIE_EVENT_INT_HOTRST_EXIT_INT |
> + PCIE_EVENT_INT_DLUP_EXIT_INT | PCIE_EVENT_INT_L2_EXIT_INT_MASK |
> + PCIE_EVENT_INT_HOTRST_EXIT_INT_MASK |
> + PCIE_EVENT_INT_DLUP_EXIT_INT_MASK;
> + writel(val, pcie->ctrl_base_addr + MC_PCIE_EVENT_INT);
> +
> + val = SEC_ERROR_INT_TX_RAM_SEC_ERR_INT |
> + SEC_ERROR_INT_RX_RAM_SEC_ERR_INT |
> + SEC_ERROR_INT_PCIE2AXI_RAM_SEC_ERR_INT |
> + SEC_ERROR_INT_AXI2PCIE_RAM_SEC_ERR_INT;
> + writel(val, pcie->ctrl_base_addr + MC_SEC_ERROR_INT);
> + writel(val, pcie->ctrl_base_addr + MC_SEC_ERROR_INT_MASK);
> +
> + val = DED_ERROR_INT_TX_RAM_DED_ERR_INT |
> + DED_ERROR_INT_RX_RAM_DED_ERR_INT |
> + DED_ERROR_INT_PCIE2AXI_RAM_DED_ERR_INT |
> + DED_ERROR_INT_AXI2PCIE_RAM_DED_ERR_INT;
> + writel(val, pcie->ctrl_base_addr + MC_DED_ERROR_INT);
> + writel(val, pcie->ctrl_base_addr + MC_DED_ERROR_INT_MASK);
> +
> + writel(0, pcie->bridge_base_addr + MC_IMASK_LOCAL);
> + writel(GENMASK(31, 0), pcie->bridge_base_addr + MC_ISTATUS_LOCAL);
> + writel(0, pcie->bridge_base_addr + MC_IMASK_HOST);
> + writel(GENMASK(31, 0), pcie->bridge_base_addr + MC_ISTATUS_HOST);
> +
> + /* Configure Address Translation Table 0 for PCIe config space */
> + writel(PCIE_CONFIG_INTERFACE, pcie->bridge_base_addr +
> + MC_ATR0_AXI4_SLV0_TRSL_PARAM);
> +
> + val = lower_32_bits(pcie->cfghw_base_addr) |
> + (pcie->atr_sz << ATR_SIZE_SHIFT) | ATR_IMPL_ENABLE;
> + writel(val, pcie->bridge_base_addr + MC_ATR0_AXI4_SLV0_SRCADDR_PARAM);
> + writel(0, pcie->bridge_base_addr + MC_ATR0_AXI4_SLV0_SRC_ADDR);
> +
> + val = lower_32_bits(pcie->cfghw_base_addr);
> + writel(val, pcie->bridge_base_addr + MC_ATR0_AXI4_SLV0_TRSL_ADDR_LSB);
> + val = upper_32_bits(pcie->cfghw_base_addr);
> + writel(val, pcie->bridge_base_addr + MC_ATR0_AXI4_SLV0_TRSL_ADDR_UDW);
> +
> + val = readl(pcie->bridge_base_addr + MC_ATR0_PCIE_WIN0_SRCADDR_PARAM);
> + val |= (ATR0_PCIE_ATR_SIZE << ATR0_PCIE_ATR_SIZE_SHIFT);
> + writel(val, pcie->bridge_base_addr + MC_ATR0_PCIE_WIN0_SRCADDR_PARAM);
> + writel(0, pcie->bridge_base_addr + MC_ATR0_PCIE_WIN0_SRC_ADDR);
> +
> + return 0;
> +}
> +
> +static void mc_mask_intx_irq(struct irq_data *data)
> +{
> + struct irq_desc *desc = irq_to_desc(data->irq);
> + struct mc_pcie *pcie;
> + unsigned long flags;
> + u32 mask, val;
> +
> + pcie = irq_desc_get_chip_data(desc);
> + mask = PCIE_LOCAL_INT_ENABLE;
> + raw_spin_lock_irqsave(&pcie->intx_mask_lock, flags);
> + val = readl(pcie->bridge_base_addr + MC_IMASK_LOCAL);
> + val &= ~mask;
> + writel(val, pcie->bridge_base_addr + MC_IMASK_LOCAL);
> + raw_spin_unlock_irqrestore(&pcie->intx_mask_lock, flags);
> +}
> +
> +static void mc_unmask_intx_irq(struct irq_data *data)
> +{
> + struct irq_desc *desc = irq_to_desc(data->irq);
> + struct mc_pcie *pcie;
> + unsigned long flags;
> + u32 mask, val;
> +
> + pcie = irq_desc_get_chip_data(desc);
> + mask = PCIE_LOCAL_INT_ENABLE;
> + raw_spin_lock_irqsave(&pcie->intx_mask_lock, flags);
> + val = readl(pcie->bridge_base_addr + MC_IMASK_LOCAL);
> + val |= mask;
> + writel(val, pcie->bridge_base_addr + MC_IMASK_LOCAL);
> + raw_spin_unlock_irqrestore(&pcie->intx_mask_lock, flags);
> +}
> +
> +static struct irq_chip mc_intx_irq_chip = {
> + .name = "microchip_pcie:intx",
> + .irq_enable = mc_unmask_intx_irq,
> + .irq_disable = mc_mask_intx_irq,
> + .irq_mask = mc_mask_intx_irq,
> + .irq_unmask = mc_unmask_intx_irq,
I believe you can drop enable/disable and mask/unmask will be used by
the core.
> +};
> +
> +static int mc_pcie_intx_map(struct irq_domain *domain, unsigned int irq,
> + irq_hw_number_t hwirq)
> +{
> + irq_set_chip_and_handler(irq, &mc_intx_irq_chip, handle_simple_irq);
> + irq_set_chip_data(irq, domain->host_data);
> +
> + return 0;
> +}
> +
> +static const struct irq_domain_ops intx_domain_ops = {
> + .map = mc_pcie_intx_map,
> +};
> +
> +static struct irq_chip mc_msi_irq_chip = {
> + .name = "Microchip PCIe MSI",
> + .irq_mask = pci_msi_mask_irq,
> + .irq_unmask = pci_msi_unmask_irq,
> +};
> +
> +static struct msi_domain_info mc_msi_domain_info = {
> + .flags = (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
> + MSI_FLAG_PCI_MSIX),
> + .chip = &mc_msi_irq_chip,
> +};
> +
> +static void mc_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
> +{
> + struct mc_pcie *pcie = irq_data_get_irq_chip_data(data);
> + phys_addr_t addr = pcie->msi.vector_phy;
> +
> + msg->address_lo = lower_32_bits(addr);
> + msg->address_hi = upper_32_bits(addr);
> + msg->data = data->hwirq;
> +
> + dev_dbg(&pcie->pdev->dev, "msi#%x address_hi %#x address_lo %#x\n",
> + (int)data->hwirq, msg->address_hi, msg->address_lo);
> +}
> +
> +static int mc_msi_set_affinity(struct irq_data *irq_data,
> + const struct cpumask *mask, bool force)
> +{
> + return -EINVAL;
> +}
> +
> +static struct irq_chip mc_msi_bottom_irq_chip = {
> + .name = "Microchip MSI",
> + .irq_compose_msi_msg = mc_compose_msi_msg,
> + .irq_set_affinity = mc_msi_set_affinity,
> +};
> +
> +static int mc_irq_msi_domain_alloc(struct irq_domain *domain,
> + unsigned int virq, unsigned int nr_irqs,
> + void *args)
> +{
> + struct mc_pcie *pcie = domain->host_data;
> + struct mc_msi *msi = &pcie->msi;
> + unsigned long bit;
> + u32 reg;
> +
> + WARN_ON(nr_irqs != 1);
> + mutex_lock(&msi->lock);
> + bit = find_first_zero_bit(msi->used, msi->num_vectors);
> + if (bit >= msi->num_vectors) {
> + mutex_unlock(&msi->lock);
> + return -ENOSPC;
> + }
> +
> + set_bit(bit, msi->used);
> + mutex_unlock(&msi->lock);
> +
> + irq_domain_set_info(domain, virq, bit, &mc_msi_bottom_irq_chip,
> + domain->host_data, handle_simple_irq, NULL, NULL);
> +
> + /* Enable MSI interrupts */
> + reg = readl(pcie->bridge_base_addr + MC_IMASK_LOCAL);
> + reg |= PCIE_ENABLE_MSI;
> + writel(reg, pcie->bridge_base_addr + MC_IMASK_LOCAL);
Should have the spinlock around it?
> +
> + return 0;
> +}
> +
> +static void mc_irq_msi_domain_free(struct irq_domain *domain,
> + unsigned int virq, unsigned int nr_irqs)
> +{
> + struct irq_data *d = irq_domain_get_irq_data(domain, virq);
> + struct mc_pcie *pcie = irq_data_get_irq_chip_data(d);
> + struct mc_msi *msi = &pcie->msi;
> +
> + mutex_lock(&msi->lock);
> +
> + if (test_bit(d->hwirq, msi->used))
> + __clear_bit(d->hwirq, msi->used);
> + else
> + dev_err(&pcie->pdev->dev, "trying to free unused MSI%lu\n",
> + d->hwirq);
> +
> + mutex_unlock(&msi->lock);
> +}
> +
> +static const struct irq_domain_ops msi_domain_ops = {
> + .alloc = mc_irq_msi_domain_alloc,
> + .free = mc_irq_msi_domain_free,
> +};
> +
> +static int mc_allocate_msi_domains(struct mc_pcie *pcie)
> +{
> + struct device *dev = &pcie->pdev->dev;
> + struct fwnode_handle *fwnode = of_node_to_fwnode(dev->of_node);
> + struct mc_msi *msi = &pcie->msi;
> +
> + mutex_init(&pcie->msi.lock);
> +
> + msi->dev_domain = irq_domain_add_linear(NULL, msi->num_vectors,
> + &msi_domain_ops, pcie);
> + if (!msi->dev_domain) {
> + dev_err(dev, "failed to create IRQ domain\n");
> + return -ENOMEM;
> + }
> +
> + msi->msi_domain = pci_msi_create_irq_domain(fwnode,
> + &mc_msi_domain_info,
> + msi->dev_domain);
> + if (!msi->msi_domain) {
> + dev_err(dev, "failed to create MSI domain\n");
> + irq_domain_remove(msi->dev_domain);
> + return -ENOMEM;
> + }
> +
> + return 0;
> +}
> +
> +static int mc_pcie_init_irq_domains(struct mc_pcie *pcie)
> +{
> + struct device *dev = &pcie->pdev->dev;
> + struct device_node *node = dev->of_node;
> +
> + pcie->intx_domain = irq_domain_add_linear(node, PCI_NUM_INTX,
> + &intx_domain_ops, pcie);
> + if (!pcie->intx_domain) {
> + dev_err(dev, "failed to get an INTx IRQ domain\n");
> + return -ENOMEM;
> + }
> + raw_spin_lock_init(&pcie->intx_mask_lock);
> +
> + return mc_allocate_msi_domains(pcie);
> +}
> +
> +static void mc_pci_unmap_cfg(void *ptr)
> +{
> + pci_ecam_free((struct pci_config_window *)ptr);
> +}
> +
> +static int mc_pcie_probe(struct platform_device *pdev)
> +{
> + struct mc_pcie *pcie;
> + struct pci_host_bridge *bridge;
> + struct pci_config_window *cfg;
> + struct device *dev = &pdev->dev;
> + struct resource_entry *win;
> + struct resource *bus_range = NULL;
> + struct resource *cfgres;
> + int ret;
> + resource_size_t size;
> + u32 index;
> + u32 atr_sz;
> + u32 val;
> +
> + if (!dev->of_node)
> + return -ENODEV;
> +
> + /* Allocate the PCIe port */
> + bridge = devm_pci_alloc_host_bridge(dev, sizeof(*pcie));
> + if (!bridge)
> + return -ENOMEM;
> +
> + pcie = pci_host_bridge_priv(bridge);
> +
> + pcie->pdev = pdev;
> +
> + cfgres = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + pcie->cfghw_base_addr = cfgres->start;
> + size = resource_size(cfgres);
> + pcie->cfg_size = size;
Why do you save this? Not used anywhere.
> + pcie->atr_sz = find_first_bit((const unsigned long *)&size, 64) - 1;
size can be 32 or 64 bits, so this is wrong in the 32-bit case though
I'm guessing you never have >4G of config space.
Use roundup_pow_of_two or ilog2.
> +
> + ret = mc_pcie_parse_dt(pcie);
> + if (ret) {
> + dev_err(dev, "parsing devicetree failed, ret %x\n", ret);
> + return ret;
> + }
> +
> + irq_set_chained_handler_and_data(pcie->irq, mc_pcie_isr, pcie);
> +
> + ret = mc_host_init(pcie);
> + if (ret) {
> + dev_err(dev, "failed to initialize host\n");
> + return ret;
> + }
> +
> + /*
> + * Configure all inbound and outbound windows and prepare
> + * for config access
> + */
> + ret = pci_parse_request_of_pci_ranges(dev, &bridge->windows,
> + &bridge->dma_ranges, &bus_range);
> + if (ret) {
> + dev_err(dev, "failed to parse PCI ranges\n");
> + return ret;
> + }
> +
> + index = 1;
> + resource_list_for_each_entry(win, &bridge->windows) {
> + if ((resource_type(win->res) != IORESOURCE_MEM) &&
> + (resource_type(win->res) != IORESOURCE_IO))
> + continue;
> +
> + size = resource_size(win->res);
> + atr_sz = find_first_bit((const unsigned long *)&size, 64) - 1;
Same issue here.
> +
> + /*
> + * Configure Address Translation Table index for PCI
> + * mem space
> + */
> + writel(PCIE_TX_RX_INTERFACE, pcie->bridge_base_addr +
> + (index * ATT_ENTRY_SIZE) +
> + MC_ATR0_AXI4_SLV0_TRSL_PARAM);
> +
> + val = lower_32_bits(win->res->start) |
> + (atr_sz << ATR_SIZE_SHIFT) |
> + ATR_IMPL_ENABLE;
> +
> + writel(val, pcie->bridge_base_addr +
> + (index * ATT_ENTRY_SIZE) +
> + MC_ATR0_AXI4_SLV0_SRCADDR_PARAM);
> +
> + val = upper_32_bits(win->res->start);
> + writel(val, pcie->bridge_base_addr + (index * ATT_ENTRY_SIZE) +
> + MC_ATR0_AXI4_SLV0_SRC_ADDR);
> +
> + val = lower_32_bits(win->res->start - win->offset);
> + writel(val, pcie->bridge_base_addr +
> + (index * ATT_ENTRY_SIZE) +
> + MC_ATR0_AXI4_SLV0_TRSL_ADDR_LSB);
> +
> + val = upper_32_bits(win->res->start);
> + writel(val, pcie->bridge_base_addr + (index * ATT_ENTRY_SIZE) +
> + MC_ATR0_AXI4_SLV0_TRSL_ADDR_UDW);
> +
> + index++;
> + }
> +
> + ret = mc_pcie_init_irq_domains(pcie);
> + if (ret) {
> + dev_err(dev, "failed creating IRQ domains\n");
> + return ret;
> + }
> +
> + /* Parse and map our Configuration Space windows */
> + cfg = pci_ecam_create(dev, cfgres, bus_range, &pci_generic_ecam_ops);
> + if (IS_ERR(cfg)) {
> + dev_err(dev, "failed creating Configuration Space\n");
> + return PTR_ERR(cfg);
> + }
> +
> + pcie->cfg_base_addr = cfg->win;
> +
> + val = cfg_readl(pcie, PCI_PRIMARY_BUS);
> + val &= 0xff000000;
> + val |= 0x00ff0100;
> + cfg_writel(pcie, val, PCI_PRIMARY_BUS);
What's this for?
> +
> + /* Hardware doesn't setup MSI by default */
> + mc_pcie_enable_msi(pcie);
> +
> + val = PCIE_ENABLE_MSI | PCIE_LOCAL_INT_ENABLE;
> + writel(val, pcie->bridge_base_addr + MC_IMASK_LOCAL);
> +
> + ret = devm_add_action_or_reset(dev, mc_pci_unmap_cfg, cfg);
> + if (ret)
> + return ret;
> +
> + /* Initialize bridge */
> + bridge->dev.parent = dev;
> + bridge->sysdata = cfg;
> + bridge->busnr = cfg->busr.start;
> + bridge->ops = &pci_generic_ecam_ops.pci_ops;
> + bridge->map_irq = of_irq_parse_and_map_pci;
> + bridge->swizzle_irq = pci_common_swizzle;
> +
> + return pci_host_probe(bridge);
> +}
> +
> +static const struct of_device_id mc_pcie_of_match[] = {
> + { .compatible = "microchip,pf-axi-pcie-host-1.0" },
> + {},
> +};
> +
> +MODULE_DEVICE_TABLE(of, mc_pcie_of_match)
> +
> +static struct platform_driver mc_pcie_driver = {
> + .probe = mc_pcie_probe,
> + .driver = {
> + .name = "microchip-pcie",
> + .of_match_table = mc_pcie_of_match,
> + .suppress_bind_attrs = true,
> + },
> +};
> +
> +builtin_platform_driver(mc_pcie_driver);
> +
> +MODULE_LICENSE("GPL v2");
> +MODULE_DESCRIPTION("Microchip PCIe host controller driver");
> +MODULE_AUTHOR("Daire McNamara <daire.mcnamara@microchip.com>");
> --
> 2.17.1
>
^ permalink raw reply
* [PATCH v2 2/2] hwrng: ba431-rng: add support for BA431 hwrng
From: Olivier Sobrie @ 2020-06-01 14:27 UTC (permalink / raw)
To: Matt Mackall, Herbert Xu, Rob Herring, Arnd Bergmann,
Greg Kroah-Hartman, linux-crypto, devicetree, linux-kernel
Cc: Olivier Sobrie, Waleed Ziad, sebastien.rabou
In-Reply-To: <20200601142740.443548-1-olivier.sobrie@silexinsight.com>
Silex insight BA431 is an IP designed to generate random numbers that
can be integrated in various FPGA.
This driver adds support for it through the hwrng interface.
This driver is used in Silex Insight Viper OEM boards.
Signed-off-by: Olivier Sobrie <olivier.sobrie@silexinsight.com>
Signed-off-by: Waleed Ziad <waleed94ziad@gmail.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/char/hw_random/Kconfig | 12 ++
drivers/char/hw_random/Makefile | 1 +
drivers/char/hw_random/ba431-rng.c | 234 +++++++++++++++++++++++++++++
3 files changed, 247 insertions(+)
create mode 100644 drivers/char/hw_random/ba431-rng.c
diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index 9bc46da8d77a8..4f50ee02c639e 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -74,6 +74,18 @@ config HW_RANDOM_ATMEL
If unsure, say Y.
+config HW_RANDOM_BA431
+ tristate "Silex Insight BA431 Random Number Generator support"
+ default HW_RANDOM
+ help
+ This driver provides kernel-side support for the Random Number
+ Generator hardware based on Silex Insight BA431 IP.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ba431-rng.
+
+ If unsure, say Y.
+
config HW_RANDOM_BCM2835
tristate "Broadcom BCM2835/BCM63xx Random Number Generator support"
depends on ARCH_BCM2835 || ARCH_BCM_NSP || ARCH_BCM_5301X || \
diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
index a7801b49ce6c0..02ccadafcca99 100644
--- a/drivers/char/hw_random/Makefile
+++ b/drivers/char/hw_random/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_HW_RANDOM_TIMERIOMEM) += timeriomem-rng.o
obj-$(CONFIG_HW_RANDOM_INTEL) += intel-rng.o
obj-$(CONFIG_HW_RANDOM_AMD) += amd-rng.o
obj-$(CONFIG_HW_RANDOM_ATMEL) += atmel-rng.o
+obj-$(CONFIG_HW_RANDOM_BA431) += ba431-rng.o
obj-$(CONFIG_HW_RANDOM_GEODE) += geode-rng.o
obj-$(CONFIG_HW_RANDOM_N2RNG) += n2-rng.o
n2-rng-y := n2-drv.o n2-asm.o
diff --git a/drivers/char/hw_random/ba431-rng.c b/drivers/char/hw_random/ba431-rng.c
new file mode 100644
index 0000000000000..a39e3abf50b94
--- /dev/null
+++ b/drivers/char/hw_random/ba431-rng.c
@@ -0,0 +1,234 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2020 Silex Insight
+
+#include <linux/delay.h>
+#include <linux/hw_random.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/workqueue.h>
+
+#define BA431_RESET_DELAY 1 /* usec */
+#define BA431_RESET_READ_STATUS_TIMEOUT 1000 /* usec */
+#define BA431_RESET_READ_STATUS_INTERVAL 10 /* usec */
+#define BA431_READ_RETRY_INTERVAL 1 /* usec */
+
+#define BA431_REG_CTRL 0x00
+#define BA431_REG_FIFO_LEVEL 0x04
+#define BA431_REG_STATUS 0x30
+#define BA431_REG_FIFODATA 0x80
+
+#define BA431_CTRL_ENABLE BIT(0)
+#define BA431_CTRL_SOFTRESET BIT(8)
+
+#define BA431_STATUS_STATE_MASK (BIT(1) | BIT(2) | BIT(3))
+#define BA431_STATUS_STATE_OFFSET 1
+
+enum ba431_state {
+ BA431_STATE_RESET,
+ BA431_STATE_STARTUP,
+ BA431_STATE_FIFOFULLON,
+ BA431_STATE_FIFOFULLOFF,
+ BA431_STATE_RUNNING,
+ BA431_STATE_ERROR
+};
+
+struct ba431_trng {
+ struct device *dev;
+ void __iomem *base;
+ struct hwrng rng;
+ atomic_t reset_pending;
+ struct work_struct reset_work;
+};
+
+static inline u32 ba431_trng_read_reg(struct ba431_trng *ba431, u32 reg)
+{
+ return ioread32(ba431->base + reg);
+}
+
+static inline void ba431_trng_write_reg(struct ba431_trng *ba431, u32 reg,
+ u32 val)
+{
+ iowrite32(val, ba431->base + reg);
+}
+
+static inline enum ba431_state ba431_trng_get_state(struct ba431_trng *ba431)
+{
+ u32 status = ba431_trng_read_reg(ba431, BA431_REG_STATUS);
+
+ return (status & BA431_STATUS_STATE_MASK) >> BA431_STATUS_STATE_OFFSET;
+}
+
+static int ba431_trng_is_in_error(struct ba431_trng *ba431)
+{
+ enum ba431_state state = ba431_trng_get_state(ba431);
+
+ if ((state < BA431_STATE_STARTUP) ||
+ (state >= BA431_STATE_ERROR))
+ return 1;
+
+ return 0;
+}
+
+static int ba431_trng_reset(struct ba431_trng *ba431)
+{
+ int ret;
+
+ /* Disable interrupts, random generation and enable the softreset */
+ ba431_trng_write_reg(ba431, BA431_REG_CTRL, BA431_CTRL_SOFTRESET);
+ udelay(BA431_RESET_DELAY);
+ ba431_trng_write_reg(ba431, BA431_REG_CTRL, BA431_CTRL_ENABLE);
+
+ /* Wait until the state changed */
+ if (readx_poll_timeout(ba431_trng_is_in_error, ba431, ret, !ret,
+ BA431_RESET_READ_STATUS_INTERVAL,
+ BA431_RESET_READ_STATUS_TIMEOUT)) {
+ dev_err(ba431->dev, "reset failed (state: %d)\n",
+ ba431_trng_get_state(ba431));
+ return -ETIMEDOUT;
+ }
+
+ dev_info(ba431->dev, "reset done\n");
+
+ return 0;
+}
+
+static void ba431_trng_reset_work(struct work_struct *work)
+{
+ struct ba431_trng *ba431 = container_of(work, struct ba431_trng,
+ reset_work);
+ ba431_trng_reset(ba431);
+ atomic_set(&ba431->reset_pending, 0);
+}
+
+static void ba431_trng_schedule_reset(struct ba431_trng *ba431)
+{
+ if (atomic_cmpxchg(&ba431->reset_pending, 0, 1))
+ return;
+
+ schedule_work(&ba431->reset_work);
+}
+
+static int ba431_trng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
+{
+ struct ba431_trng *ba431 = container_of(rng, struct ba431_trng, rng);
+ u32 *data = buf;
+ unsigned int level, i;
+ int n = 0;
+
+ while (max > 0) {
+ level = ba431_trng_read_reg(ba431, BA431_REG_FIFO_LEVEL);
+ if (!level) {
+ if (ba431_trng_is_in_error(ba431)) {
+ ba431_trng_schedule_reset(ba431);
+ break;
+ }
+
+ if (!wait)
+ break;
+
+ udelay(BA431_READ_RETRY_INTERVAL);
+ continue;
+ }
+
+ i = level;
+ do {
+ data[n++] = ba431_trng_read_reg(ba431,
+ BA431_REG_FIFODATA);
+ max -= sizeof(*data);
+ } while (--i && (max > 0));
+
+ if (ba431_trng_is_in_error(ba431)) {
+ n -= (level - i);
+ ba431_trng_schedule_reset(ba431);
+ break;
+ }
+ }
+
+ n *= sizeof(data);
+ return (n || !wait) ? n : -EIO;
+}
+
+static void ba431_trng_cleanup(struct hwrng *rng)
+{
+ struct ba431_trng *ba431 = container_of(rng, struct ba431_trng, rng);
+
+ ba431_trng_write_reg(ba431, BA431_REG_CTRL, 0);
+ cancel_work_sync(&ba431->reset_work);
+}
+
+static int ba431_trng_init(struct hwrng *rng)
+{
+ struct ba431_trng *ba431 = container_of(rng, struct ba431_trng, rng);
+
+ return ba431_trng_reset(ba431);
+}
+
+static int ba431_trng_probe(struct platform_device *pdev)
+{
+ struct ba431_trng *ba431;
+ struct resource *res;
+ int ret;
+
+ ba431 = devm_kzalloc(&pdev->dev, sizeof(*ba431), GFP_KERNEL);
+ if (!ba431)
+ return -ENOMEM;
+
+ ba431->dev = &pdev->dev;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ ba431->base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(ba431->base))
+ return PTR_ERR(ba431->base);
+
+ atomic_set(&ba431->reset_pending, 0);
+ INIT_WORK(&ba431->reset_work, ba431_trng_reset_work);
+ ba431->rng.name = pdev->name;
+ ba431->rng.init = ba431_trng_init;
+ ba431->rng.cleanup = ba431_trng_cleanup;
+ ba431->rng.read = ba431_trng_read;
+
+ platform_set_drvdata(pdev, ba431);
+
+ ret = hwrng_register(&ba431->rng);
+ if (ret) {
+ dev_err(&pdev->dev, "BA431 registration failed (%d)\n", ret);
+ return ret;
+ }
+
+ dev_info(&pdev->dev, "BA431 TRNG registered\n");
+
+ return 0;
+}
+
+static int ba431_trng_remove(struct platform_device *pdev)
+{
+ struct ba431_trng *ba431 = platform_get_drvdata(pdev);
+
+ hwrng_unregister(&ba431->rng);
+
+ return 0;
+}
+
+static const struct of_device_id ba431_trng_dt_ids[] = {
+ { .compatible = "silex-insight,ba431-rng", .data = NULL },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, ba431_trng_dt_ids);
+
+static struct platform_driver ba431_trng_driver = {
+ .driver = {
+ .name = "ba431-rng",
+ .of_match_table = ba431_trng_dt_ids,
+ },
+ .probe = ba431_trng_probe,
+ .remove = ba431_trng_remove,
+};
+
+module_platform_driver(ba431_trng_driver);
+
+MODULE_AUTHOR("Olivier Sobrie <olivier@sobrie.be>");
+MODULE_DESCRIPTION("TRNG driver for Silex Insight BA431");
+MODULE_LICENSE("GPL");
--
2.26.2
^ permalink raw reply related
* [PATCH v2 0/2] hwrng: add support for Silex Insight BA431
From: Olivier Sobrie @ 2020-06-01 14:27 UTC (permalink / raw)
To: Matt Mackall, Herbert Xu, Rob Herring, Arnd Bergmann,
Greg Kroah-Hartman, linux-crypto, devicetree, linux-kernel
Cc: Olivier Sobrie, Waleed Ziad, sebastien.rabou
Hello all,
This set of patches aims at introducing a linux hwrng driver for the
Silex Insight BA431 IP which is available for various FPGA.
This hardware is for instance present in Silex Insight Viper OEM boards.
The first patch documents the device tree bindings.
The second one contains the BA431 hwrng driver.
Olivier Sobrie (2):
dt-bindings: rng: document Silex Insight BA431 hwrng
hwrng: ba431-rng: add support for BA431 hwrng
.../bindings/rng/silex-insight,ba431-rng.yaml | 36 +++
drivers/char/hw_random/Kconfig | 12 +
drivers/char/hw_random/Makefile | 1 +
drivers/char/hw_random/ba431-rng.c | 234 ++++++++++++++++++
4 files changed, 283 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rng/silex-insight,ba431-rng.yaml
create mode 100644 drivers/char/hw_random/ba431-rng.c
Changes in v2:
- Dropped the first patch that has been applied by Rob.
- Added Rob's review tag in the first patch.
- Fixed copyright header.
- Added missing endpoint and "If unsure, say Y" in the Kconfig like it is
done for the other rng drivers.
- Replaced the udelay() loop by readx_poll_timeout() in the driver.
- Added Arnd's ack in the second patch.
--
2.26.2
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: rng: document Silex Insight BA431 hwrng
From: Olivier Sobrie @ 2020-06-01 14:27 UTC (permalink / raw)
To: Matt Mackall, Herbert Xu, Rob Herring, Arnd Bergmann,
Greg Kroah-Hartman, linux-crypto, devicetree, linux-kernel
Cc: Olivier Sobrie, Waleed Ziad, sebastien.rabou, Rob Herring
In-Reply-To: <20200601142740.443548-1-olivier.sobrie@silexinsight.com>
This patch documents the device tree bindings of the BA431 hardware
random number generator.
This IP is for instance present in the Viper OEM boards sold by Silex
Insight.
Signed-off-by: Olivier Sobrie <olivier.sobrie@silexinsight.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
.../bindings/rng/silex-insight,ba431-rng.yaml | 36 +++++++++++++++++++
1 file changed, 36 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rng/silex-insight,ba431-rng.yaml
diff --git a/Documentation/devicetree/bindings/rng/silex-insight,ba431-rng.yaml b/Documentation/devicetree/bindings/rng/silex-insight,ba431-rng.yaml
new file mode 100644
index 0000000000000..48ab82abf50ec
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/silex-insight,ba431-rng.yaml
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rng/silex-insight,ba431-rng.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Silex Insight BA431 RNG bindings
+
+description: |
+ The BA431 hardware random number generator is an IP that is FIPS-140-2/3
+ certified.
+
+maintainers:
+ - Olivier Sobrie <olivier.sobrie@silexinsight.com>
+
+properties:
+ compatible:
+ const: silex-insight,ba431-rng
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ rng@42800000 {
+ compatible = "silex-insight,ba431-rng";
+ reg = <0x42800000 0x1000>;
+ };
+
+...
--
2.26.2
^ permalink raw reply related
* Re: [PATCH V6 4/5] clk: qcom: Add ipq6018 apss clock controller
From: Stephen Boyd @ 2020-06-01 19:36 UTC (permalink / raw)
To: Sivaprakash Murugesan, agross, bjorn.andersson, devicetree,
linux-arm-msm, linux-clk, linux-kernel, mturquette, robh+dt
In-Reply-To: <824cd7bb-0971-d387-4b78-75c36ddf2f66@codeaurora.org>
Quoting Sivaprakash Murugesan (2020-06-01 05:41:15)
> On 5/28/2020 7:29 AM, Stephen Boyd wrote:
> > Quoting Sivaprakash Murugesan (2020-05-27 05:24:51)
> >> diff --git a/drivers/clk/qcom/apss-ipq6018.c b/drivers/clk/qcom/apss-ipq6018.c
> >> new file mode 100644
> >> index 0000000..004f7e1
> >> --- /dev/null
> >> +++ b/drivers/clk/qcom/apss-ipq6018.c
> >> @@ -0,0 +1,106 @@
> >> + P_XO,
> >> + P_APSS_PLL_EARLY,
> >> +};
> >> +
> >> +static const struct clk_parent_data parents_apcs_alias0_clk_src[] = {
> >> + { .fw_name = "xo" },
> >> + { .fw_name = "pll" },
> > This pll clk is not described in the binding. Please add it there.
>
> Sorry I did not get this, this PLL is not directly defined in this
> driver and it comes
>
> from dts. do you still want to describe it in binding?
>
Yes, there should be a clock-names property for "pll" and a clocks
property in the binding document. I didn't see that.
^ permalink raw reply
* Re: [PATCH v8 0/5] support reserving crashkernel above 4G on arm64 kdump
From: John Donnelly @ 2020-06-01 19:30 UTC (permalink / raw)
To: Prabhakar Kushwaha, Chen Zhou
Cc: Thomas Gleixner, mingo, Catalin Marinas, Will Deacon, dyoung, bhe,
robh+dt, arnd, devicetree, Linux Doc Mailing List,
kexec mailing list, Linux Kernel Mailing List, horms, guohanjun,
Prabhakar Kushwaha, linux-arm-kernel, James Morse
In-Reply-To: <CAJ2QiJ+1Hj2OQzpR5CfvLGMfTTbXAST94hsbfm0VcDmJKV3WTw@mail.gmail.com>
Hi,
On 6/1/20 7:02 AM, Prabhakar Kushwaha wrote:
> Hi Chen,
>
> On Thu, May 21, 2020 at 3:05 PM Chen Zhou <chenzhou10@huawei.com> wrote:
>> This patch series enable reserving crashkernel above 4G in arm64.
>>
>> There are following issues in arm64 kdump:
>> 1. We use crashkernel=X to reserve crashkernel below 4G, which will fail
>> when there is no enough low memory.
>> 2. Currently, crashkernel=Y@X can be used to reserve crashkernel above 4G,
>> in this case, if swiotlb or DMA buffers are required, crash dump kernel
>> will boot failure because there is no low memory available for allocation.
>>
>> To solve these issues, introduce crashkernel=X,low to reserve specified
>> size low memory.
>> Crashkernel=X tries to reserve memory for the crash dump kernel under
>> 4G. If crashkernel=Y,low is specified simultaneously, reserve spcified
>> size low memory for crash kdump kernel devices firstly and then reserve
>> memory above 4G.
>>
>> When crashkernel is reserved above 4G in memory, that is, crashkernel=X,low
>> is specified simultaneously, kernel should reserve specified size low memory
>> for crash dump kernel devices. So there may be two crash kernel regions, one
>> is below 4G, the other is above 4G.
>> In order to distinct from the high region and make no effect to the use of
>> kexec-tools, rename the low region as "Crash kernel (low)", and add DT property
>> "linux,low-memory-range" to crash dump kernel's dtb to pass the low region.
>>
>> Besides, we need to modify kexec-tools:
>> arm64: kdump: add another DT property to crash dump kernel's dtb(see [1])
>>
>> The previous changes and discussions can be retrieved from:
>>
>> Changes since [v7]
>> - Move x86 CRASH_ALIGN to 2M
>> Suggested by Dave and do some test, move x86 CRASH_ALIGN to 2M.
>> - Update Documentation/devicetree/bindings/chosen.txt
>> Add corresponding documentation to Documentation/devicetree/bindings/chosen.txt suggested by Arnd.
>> - Add Tested-by from Jhon and pk
>>
>> Changes since [v6]
>> - Fix build errors reported by kbuild test robot.
>>
>> Changes since [v5]
>> - Move reserve_crashkernel_low() into kernel/crash_core.c.
>> - Delete crashkernel=X,high.
>> - Modify crashkernel=X,low.
>> If crashkernel=X,low is specified simultaneously, reserve spcified size low
>> memory for crash kdump kernel devices firstly and then reserve memory above 4G.
>> In addition, rename crashk_low_res as "Crash kernel (low)" for arm64, and then
>> pass to crash dump kernel by DT property "linux,low-memory-range".
>> - Update Documentation/admin-guide/kdump/kdump.rst.
>>
>> Changes since [v4]
>> - Reimplement memblock_cap_memory_ranges for multiple ranges by Mike.
>>
>> Changes since [v3]
>> - Add memblock_cap_memory_ranges back for multiple ranges.
>> - Fix some compiling warnings.
>>
>> Changes since [v2]
>> - Split patch "arm64: kdump: support reserving crashkernel above 4G" as
>> two. Put "move reserve_crashkernel_low() into kexec_core.c" in a separate
>> patch.
>>
>> Changes since [v1]:
>> - Move common reserve_crashkernel_low() code into kernel/kexec_core.c.
>> - Remove memblock_cap_memory_ranges() i added in v1 and implement that
>> in fdt_enforce_memory_region().
>> There are at most two crash kernel regions, for two crash kernel regions
>> case, we cap the memory range [min(regs[*].start), max(regs[*].end)]
>> and then remove the memory range in the middle.
>>
>> [1]: https://urldefense.com/v3/__http://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbvpn1uM1$
>> [v1]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/2/1174__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbt0xN9PE$
>> [v2]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/9/86__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbub7yUQH$
>> [v3]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/9/306__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbnc4zPPV$
>> [v4]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/15/273__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbvsAsZLu$
>> [v5]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/5/6/1360__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbl24n-79$
>> [v6]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/8/30/142__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbs7r8G2a$
>> [v7]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/12/23/411__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbiFUH90G$
>>
>> Chen Zhou (5):
>> x86: kdump: move reserve_crashkernel_low() into crash_core.c
>> arm64: kdump: reserve crashkenel above 4G for crash dump kernel
>> arm64: kdump: add memory for devices by DT property, low-memory-range
>> kdump: update Documentation about crashkernel on arm64
>> dt-bindings: chosen: Document linux,low-memory-range for arm64 kdump
>>
> We are getting "warn_alloc" [1] warning during boot of kdump kernel
> with bootargs as [2] of primary kernel.
> This error observed on ThunderX2 ARM64 platform.
>
> It is observed with latest upstream tag (v5.7-rc3) with this patch set
> and https://urldefense.com/v3/__https://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbiIAAlzu$
> Also **without** this patch-set
> "https://urldefense.com/v3/__https://www.spinics.net/lists/arm-kernel/msg806882.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbjC6ujMA$"
>
> This issue comes whenever crashkernel memory is reserved after 0xc000_0000.
> More details discussed earlier in
> https://urldefense.com/v3/__https://www.spinics.net/lists/arm-kernel/msg806882.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbjC6ujMA$ without any
> solution
>
> This patch-set is expected to solve similar kind of issue.
> i.e. low memory is only targeted for DMA, swiotlb; So above mentioned
> observation should be considered/fixed. .
>
> --pk
>
> [1]
> [ 30.366695] DMI: Cavium Inc. Saber/Saber, BIOS
> TX2-FW-Release-3.1-build_01-2803-g74253a541a mm/dd/yyyy
> [ 30.367696] NET: Registered protocol family 16
> [ 30.369973] swapper/0: page allocation failure: order:6,
> mode:0x1(GFP_DMA), nodemask=(null),cpuset=/,mems_allowed=0
> [ 30.369980] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.7.0-rc3+ #121
> [ 30.369981] Hardware name: Cavium Inc. Saber/Saber, BIOS
> TX2-FW-Release-3.1-build_01-2803-g74253a541a mm/dd/yyyy
> [ 30.369984] Call trace:
> [ 30.369989] dump_backtrace+0x0/0x1f8
> [ 30.369991] show_stack+0x20/0x30
> [ 30.369997] dump_stack+0xc0/0x10c
> [ 30.370001] warn_alloc+0x10c/0x178
> [ 30.370004] __alloc_pages_slowpath.constprop.111+0xb10/0xb50
> [ 30.370006] __alloc_pages_nodemask+0x2b4/0x300
> [ 30.370008] alloc_page_interleave+0x24/0x98
> [ 30.370011] alloc_pages_current+0xe4/0x108
> [ 30.370017] dma_atomic_pool_init+0x44/0x1a4
> [ 30.370020] do_one_initcall+0x54/0x228
> [ 30.370027] kernel_init_freeable+0x228/0x2cc
> [ 30.370031] kernel_init+0x1c/0x110
> [ 30.370034] ret_from_fork+0x10/0x18
> [ 30.370036] Mem-Info:
> [ 30.370064] active_anon:0 inactive_anon:0 isolated_anon:0
> [ 30.370064] active_file:0 inactive_file:0 isolated_file:0
> [ 30.370064] unevictable:0 dirty:0 writeback:0 unstable:0
> [ 30.370064] slab_reclaimable:34 slab_unreclaimable:4438
> [ 30.370064] mapped:0 shmem:0 pagetables:14 bounce:0
> [ 30.370064] free:1537719 free_pcp:219 free_cma:0
> [ 30.370070] Node 0 active_anon:0kB inactive_anon:0kB
> active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB
> isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB shmem:0kB
> shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB
> unstable:0kB all_unreclaimable? no
> [ 30.370073] Node 1 active_anon:0kB inactive_anon:0kB
> active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB
> isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB shmem:0kB
> shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB
> unstable:0kB all_unreclaimable? no
> [ 30.370079] Node 0 DMA free:0kB min:0kB low:0kB high:0kB
> reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
> active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
> present:128kB managed:0kB mlocked:0kB kernel_stack:0kB pagetables:0kB
> bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
> [ 30.370084] lowmem_reserve[]: 0 250 6063 6063
> [ 30.370090] Node 0 DMA32 free:256000kB min:408kB low:664kB
> high:920kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
> active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
> present:269700kB managed:256000kB mlocked:0kB kernel_stack:0kB
> pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
> [ 30.370094] lowmem_reserve[]: 0 0 5813 5813
> [ 30.370100] Node 0 Normal free:5894876kB min:9552kB low:15504kB
> high:21456kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
> active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
> present:8388608kB managed:5953112kB mlocked:0kB kernel_stack:21672kB
> pagetables:56kB bounce:0kB free_pcp:876kB local_pcp:176kB free_cma:0kB
> [ 30.370104] lowmem_reserve[]: 0 0 0 0
> [ 30.370107] Node 0 DMA: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB
> 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 0kB
> [ 30.370113] Node 0 DMA32: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB
> 0*256kB 0*512kB 0*1024kB 1*2048kB (M) 62*4096kB (M) = 256000kB
> [ 30.370119] Node 0 Normal: 2*4kB (M) 3*8kB (ME) 2*16kB (UE) 3*32kB
> (UM) 1*64kB (U) 2*128kB (M) 2*256kB (ME) 3*512kB (ME) 3*1024kB (ME)
> 3*2048kB (UME) 1436*4096kB (M) = 5893600kB
> [ 30.370129] Node 0 hugepages_total=0 hugepages_free=0
> hugepages_surp=0 hugepages_size=1048576kB
> [ 30.370130] 0 total pagecache pages
> [ 30.370132] 0 pages in swap cache
> [ 30.370134] Swap cache stats: add 0, delete 0, find 0/0
> [ 30.370135] Free swap = 0kB
> [ 30.370136] Total swap = 0kB
> [ 30.370137] 2164609 pages RAM
> [ 30.370139] 0 pages HighMem/MovableOnly
> [ 30.370140] 612331 pages reserved
> [ 30.370141] 0 pages hwpoisoned
> [ 30.370143] DMA: failed to allocate 256 KiB pool for atomic
> coherent allocation
During my testing I saw the same error and Chen's solution corrected it .
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: memory: document Renesas RPC-IF bindings
From: Sergei Shtylyov @ 2020-06-01 19:18 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, Mason Yang, linux-spi, Chris Brandt, linux-mtd
In-Reply-To: <20200501212547.GB15294@bogus>
On 05/02/2020 12:25 AM, Rob Herring wrote:
>> Renesas Reduced Pin Count Interface (RPC-IF) allows a SPI flash or
>> HyperFlash connected to the SoC to be accessed via the external address
>> space read mode or the manual mode.
>>
>> Document the device tree bindings for the Renesas RPC-IF found in the R-Car
>> gen3 SoCs.
>>
>> Based on the original patch by Mason Yang <masonccyang@mxic.com.tw>.
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>>
[...]
>> Index: linux/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml
>> ===================================================================
>> --- /dev/null
>> +++ linux/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml
>> @@ -0,0 +1,88 @@
[...]
>> +patternProperties:
>> + "^.*@[0-9a-f]+$":
>
> ^flash@... if you're that restrictive.
>
>> + type: object
>> + properties:
>> + compatible:
>> + oneOf:
>> + - const: cfi-flash
>> + - const: jedec,spi-nor
>
> enum is better than oneOf+const.
- enum:
- cfi-flash
- jedec,spi-nor
causes the build error you encountered while trying to merge the last time.
What was I doing wrong?
[...]
MBR, Sergei
^ permalink raw reply
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