* Re: [PATCH 5/8] arm64: use ZONE_DMA on DMA addressing limited devices
From: Nicolas Saenz Julienne @ 2019-08-01 16:40 UTC (permalink / raw)
To: Robin Murphy, Catalin Marinas
Cc: phill, devicetree, f.fainelli, linux-mm, marc.zyngier,
Will Deacon, linux-kernel, eric, iommu, robh+dt, linux-rpi-kernel,
mbrugger, akpm, m.szyprowski, frowand.list, hch, linux-arm-kernel,
wahrenst
In-Reply-To: <e35dd4a5-281b-d281-59c9-3fc7108eb8be@arm.com>
[-- Attachment #1: Type: text/plain, Size: 2044 bytes --]
On Thu, 2019-08-01 at 17:07 +0100, Robin Murphy wrote:
> On 2019-08-01 4:44 pm, Nicolas Saenz Julienne wrote:
> > On Wed, 2019-07-31 at 18:07 +0100, Catalin Marinas wrote:
> > > On Wed, Jul 31, 2019 at 05:47:48PM +0200, Nicolas Saenz Julienne wrote:
> > > > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > > > index 1c4ffabbe1cb..f5279ef85756 100644
> > > > --- a/arch/arm64/mm/init.c
> > > > +++ b/arch/arm64/mm/init.c
> > > > @@ -50,6 +50,13 @@
> > > > s64 memstart_addr __ro_after_init = -1;
> > > > EXPORT_SYMBOL(memstart_addr);
> > > >
> > > > +/*
> > > > + * We might create both a ZONE_DMA and ZONE_DMA32. ZONE_DMA is needed
> > > > if
> > > > there
> > > > + * are periferals unable to address the first naturally aligned 4GB of
> > > > ram.
> > > > + * ZONE_DMA32 will be expanded to cover the rest of that memory. If
> > > > such
> > > > + * limitations doesn't exist only ZONE_DMA32 is created.
> > > > + */
> > >
> > > Shouldn't we instead only create ZONE_DMA to cover the whole 32-bit
> > > range and leave ZONE_DMA32 empty? Can__GFP_DMA allocations fall back
> > > onto ZONE_DMA32?
> >
> > Hi Catalin, thanks for the review.
> >
> > You're right, the GFP_DMA page allocation will fail with a nasty dmesg error
> > if
> > ZONE_DMA is configured but empty. Unsurprisingly the opposite situation is
> > fine
> > (GFP_DMA32 with an empty ZONE_DMA32).
>
> Was that tested on something other than RPi4 with more than 4GB of RAM?
> (i.e. with a non-empty ZONE_NORMAL either way)
No, all I did is play around with RPi4's memory size (1 GB vs 4 GB).
I'll see If I can get access to a dts based board with more than 4 GB, If not
I'll try to fake it. It's not ideal but I can set the limit on 3 GB and have
the 3 areas created (with and witouth an empty ZONE_DMA32).
On top of that, now that you ask, I realise I neglected all the ACPI based
servers. I have access to some so I'll make sure I test everything on them too
for the next series.
Regards,
Nicolas
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v1 2/2] net: npcm: add NPCM7xx EMC 10/100 Ethernet driver
From: David Miller @ 2019-08-01 16:27 UTC (permalink / raw)
To: avifishman70
Cc: venture, yuenn, benjaminfair, robh+dt, mark.rutland, gregkh,
tmaimon77, tali.perry1, openbmc, netdev, devicetree, linux-kernel,
tglx
In-Reply-To: <20190801072611.27935-3-avifishman70@gmail.com>
From: Avi Fishman <avifishman70@gmail.com>
Date: Thu, 1 Aug 2019 10:26:11 +0300
> +#Eternet 10/100 EMC
"Ethernet"
> +#ifdef CONFIG_NPCM7XX_EMC_ETH_DEBUG
> +#define DEBUG
> +#endif
Please don't control the DEBUG define in this way.
> +#if defined CONFIG_NPCM7XX_EMC_ETH_DEBUG || defined CONFIG_DEBUG_FS
> +#define REG_PRINT(reg_name) {t = scnprintf(next, size, "%-10s = %08X\n", \
> + #reg_name, readl(ether->reg + (reg_name))); size -= t; next += t; }
> +#define DUMP_PRINT(f, x...) {t = scnprintf(next, size, f, ## x); size -= t; \
> + next += t; }
Really, get rid of this custom debugging infrastructure and just use
generic facilities the kernel has for this, as designed.
> +static int npcm7xx_info_dump(char *buf, int count, struct net_device *netdev)
> +{
> + struct npcm7xx_ether *ether = netdev_priv(netdev);
> + struct npcm7xx_txbd *txbd;
> + struct npcm7xx_rxbd *rxbd;
> + unsigned long flags;
> + unsigned int i, cur, txd_offset, rxd_offset;
> + char *next = buf;
> + unsigned int size = count;
> + int t;
> + int is_locked = spin_is_locked(ðer->lock);
Reverse christmas tree (longest to shortest) ordering for local variables
please.
Audit your entire submission for this problem.
^ permalink raw reply
* Re: [PATCH v9 09/15] dt-bindings: memory: tegra30: Convert to Tegra124 YAML
From: Rob Herring @ 2019-08-01 16:25 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Michael Turquette, Joseph Lo, Thierry Reding, Jonathan Hunter,
Peter De Schrijver, Prashant Gaikwad, Stephen Boyd, devicetree,
linux-clk, linux-tegra, linux-kernel@vger.kernel.org
In-Reply-To: <20190730165618.10122-10-digetx@gmail.com>
On Tue, Jul 30, 2019 at 10:58 AM Dmitry Osipenko <digetx@gmail.com> wrote:
>
> The Tegra30 binding will actually differ from the Tegra124 a tad, in
> particular the EMEM configuration description. Hence rename the binding
> to Tegra124 during of the conversion to YAML.
>
> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
> ---
> .../nvidia,tegra124-mc.yaml | 158 ++++++++++++++++++
> .../memory-controllers/nvidia,tegra30-mc.txt | 123 --------------
> 2 files changed, 158 insertions(+), 123 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-mc.yaml
> delete mode 100644 Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-mc.txt
>
> diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-mc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-mc.yaml
> new file mode 100644
> index 000000000000..2e2a116f1911
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-mc.yaml
> @@ -0,0 +1,158 @@
> +# SPDX-License-Identifier: (GPL-2.0)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/memory-controllers/nvidia,tegra124-mc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: NVIDIA Tegra124 SoC Memory Controller
> +
> +maintainers:
> + - Jon Hunter <jonathanh@nvidia.com>
> + - Thierry Reding <thierry.reding@gmail.com>
> +
> +description: |
> + Tegra124 SoC features a hybrid 2x32-bit / 1x64-bit memory controller.
> + These are interleaved to provide high performance with the load shared across
> + two memory channels. The Tegra124 Memory Controller handles memory requests
> + from internal clients and arbitrates among them to allocate memory bandwidth
> + for DDR3L and LPDDR3 SDRAMs.
> +
> +properties:
> + compatible:
> + const: nvidia,tegra124-mc
> +
> + reg:
> + maxItems: 1
> + description:
> + Physical base address.
You don't really need a description when there's only 1 item. Same on
the others below.
With that,
Reviewed-by: Rob Herring <robh@kernel.org>
> +
> + clocks:
> + maxItems: 1
> + description:
> + Memory Controller clock.
> +
> + clock-names:
> + items:
> + - const: mc
> +
> + interrupts:
> + maxItems: 1
> + description:
> + Memory Controller interrupt.
> +
> + "#reset-cells":
> + const: 1
> +
> + "#iommu-cells":
> + const: 1
> +
> +patternProperties:
> + "^emc-timings-[0-9]+$":
> + type: object
> + properties:
> + nvidia,ram-code:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + Value of RAM_CODE this timing set is used for.
> +
> + patternProperties:
> + "^timing-[0-9]+$":
> + type: object
> + properties:
> + clock-frequency:
> + description:
> + Memory clock rate in Hz.
> + minimum: 1000000
> + maximum: 1066000000
> +
> + nvidia,emem-configuration:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + description: |
> + Values to be written to the EMEM register block. See section
> + "15.6.1 MC Registers" in the TRM.
> + items:
> + - description: MC_EMEM_ARB_CFG
> + - description: MC_EMEM_ARB_OUTSTANDING_REQ
> + - description: MC_EMEM_ARB_TIMING_RCD
> + - description: MC_EMEM_ARB_TIMING_RP
> + - description: MC_EMEM_ARB_TIMING_RC
> + - description: MC_EMEM_ARB_TIMING_RAS
> + - description: MC_EMEM_ARB_TIMING_FAW
> + - description: MC_EMEM_ARB_TIMING_RRD
> + - description: MC_EMEM_ARB_TIMING_RAP2PRE
> + - description: MC_EMEM_ARB_TIMING_WAP2PRE
> + - description: MC_EMEM_ARB_TIMING_R2R
> + - description: MC_EMEM_ARB_TIMING_W2W
> + - description: MC_EMEM_ARB_TIMING_R2W
> + - description: MC_EMEM_ARB_TIMING_W2R
> + - description: MC_EMEM_ARB_DA_TURNS
> + - description: MC_EMEM_ARB_DA_COVERS
> + - description: MC_EMEM_ARB_MISC0
> + - description: MC_EMEM_ARB_MISC1
> + - description: MC_EMEM_ARB_RING1_THROTTLE
> +
> + required:
> + - clock-frequency
> + - nvidia,emem-configuration
> +
> + additionalProperties: false
> +
> + required:
> + - nvidia,ram-code
> +
> + additionalProperties: false
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> + - clock-names
> + - "#reset-cells"
> + - "#iommu-cells"
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + memory-controller@70019000 {
> + compatible = "nvidia,tegra124-mc";
> + reg = <0x0 0x70019000 0x0 0x1000>;
> + clocks = <&tegra_car 32>;
> + clock-names = "mc";
> +
> + interrupts = <0 77 4>;
> +
> + #iommu-cells = <1>;
> + #reset-cells = <1>;
> +
> + emc-timings-3 {
> + nvidia,ram-code = <3>;
> +
> + timing-12750000 {
> + clock-frequency = <12750000>;
> +
> + nvidia,emem-configuration = <
> + 0x40040001 /* MC_EMEM_ARB_CFG */
> + 0x8000000a /* MC_EMEM_ARB_OUTSTANDING_REQ */
> + 0x00000001 /* MC_EMEM_ARB_TIMING_RCD */
> + 0x00000001 /* MC_EMEM_ARB_TIMING_RP */
> + 0x00000002 /* MC_EMEM_ARB_TIMING_RC */
> + 0x00000000 /* MC_EMEM_ARB_TIMING_RAS */
> + 0x00000002 /* MC_EMEM_ARB_TIMING_FAW */
> + 0x00000001 /* MC_EMEM_ARB_TIMING_RRD */
> + 0x00000002 /* MC_EMEM_ARB_TIMING_RAP2PRE */
> + 0x00000008 /* MC_EMEM_ARB_TIMING_WAP2PRE */
> + 0x00000003 /* MC_EMEM_ARB_TIMING_R2R */
> + 0x00000002 /* MC_EMEM_ARB_TIMING_W2W */
> + 0x00000003 /* MC_EMEM_ARB_TIMING_R2W */
> + 0x00000006 /* MC_EMEM_ARB_TIMING_W2R */
> + 0x06030203 /* MC_EMEM_ARB_DA_TURNS */
> + 0x000a0402 /* MC_EMEM_ARB_DA_COVERS */
> + 0x77e30303 /* MC_EMEM_ARB_MISC0 */
> + 0x70000f03 /* MC_EMEM_ARB_MISC1 */
> + 0x001f0000 /* MC_EMEM_ARB_RING1_THROTTLE */
> + >;
> + };
> + };
> + };
> diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-mc.txt b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-mc.txt
> deleted file mode 100644
> index a878b5908a4d..000000000000
> --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-mc.txt
> +++ /dev/null
> @@ -1,123 +0,0 @@
> -NVIDIA Tegra Memory Controller device tree bindings
> -===================================================
> -
> -memory-controller node
> -----------------------
> -
> -Required properties:
> -- compatible: Should be "nvidia,tegra<chip>-mc"
> -- reg: Physical base address and length of the controller's registers.
> -- clocks: Must contain an entry for each entry in clock-names.
> - See ../clocks/clock-bindings.txt for details.
> -- clock-names: Must include the following entries:
> - - mc: the module's clock input
> -- interrupts: The interrupt outputs from the controller.
> -- #reset-cells : Should be 1. This cell represents memory client module ID.
> - The assignments may be found in header file <dt-bindings/memory/tegra30-mc.h>
> - or in the TRM documentation.
> -
> -Required properties for Tegra30, Tegra114, Tegra124, Tegra132 and Tegra210:
> -- #iommu-cells: Should be 1. The single cell of the IOMMU specifier defines
> - the SWGROUP of the master.
> -
> -This device implements an IOMMU that complies with the generic IOMMU binding.
> -See ../iommu/iommu.txt for details.
> -
> -emc-timings subnode
> --------------------
> -
> -The node should contain a "emc-timings" subnode for each supported RAM type (see field RAM_CODE in
> -register PMC_STRAPPING_OPT_A).
> -
> -Required properties for "emc-timings" nodes :
> -- nvidia,ram-code : Should contain the value of RAM_CODE this timing set is used for.
> -
> -timing subnode
> ---------------
> -
> -Each "emc-timings" node should contain a subnode for every supported EMC clock rate.
> -
> -Required properties for timing nodes :
> -- clock-frequency : Should contain the memory clock rate in Hz.
> -- nvidia,emem-configuration : Values to be written to the EMEM register block. For the Tegra124 SoC
> -(see section "15.6.1 MC Registers" in the TRM), these are the registers whose values need to be
> -specified, according to the board documentation:
> -
> - MC_EMEM_ARB_CFG
> - MC_EMEM_ARB_OUTSTANDING_REQ
> - MC_EMEM_ARB_TIMING_RCD
> - MC_EMEM_ARB_TIMING_RP
> - MC_EMEM_ARB_TIMING_RC
> - MC_EMEM_ARB_TIMING_RAS
> - MC_EMEM_ARB_TIMING_FAW
> - MC_EMEM_ARB_TIMING_RRD
> - MC_EMEM_ARB_TIMING_RAP2PRE
> - MC_EMEM_ARB_TIMING_WAP2PRE
> - MC_EMEM_ARB_TIMING_R2R
> - MC_EMEM_ARB_TIMING_W2W
> - MC_EMEM_ARB_TIMING_R2W
> - MC_EMEM_ARB_TIMING_W2R
> - MC_EMEM_ARB_DA_TURNS
> - MC_EMEM_ARB_DA_COVERS
> - MC_EMEM_ARB_MISC0
> - MC_EMEM_ARB_MISC1
> - MC_EMEM_ARB_RING1_THROTTLE
> -
> -Example SoC include file:
> -
> -/ {
> - mc: memory-controller@70019000 {
> - compatible = "nvidia,tegra124-mc";
> - reg = <0x0 0x70019000 0x0 0x1000>;
> - clocks = <&tegra_car TEGRA124_CLK_MC>;
> - clock-names = "mc";
> -
> - interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>;
> -
> - #iommu-cells = <1>;
> - #reset-cells = <1>;
> - };
> -
> - sdhci@700b0000 {
> - compatible = "nvidia,tegra124-sdhci";
> - ...
> - iommus = <&mc TEGRA_SWGROUP_SDMMC1A>;
> - resets = <&mc TEGRA124_MC_RESET_SDMMC1>;
> - };
> -};
> -
> -Example board file:
> -
> -/ {
> - memory-controller@70019000 {
> - emc-timings-3 {
> - nvidia,ram-code = <3>;
> -
> - timing-12750000 {
> - clock-frequency = <12750000>;
> -
> - nvidia,emem-configuration = <
> - 0x40040001 /* MC_EMEM_ARB_CFG */
> - 0x8000000a /* MC_EMEM_ARB_OUTSTANDING_REQ */
> - 0x00000001 /* MC_EMEM_ARB_TIMING_RCD */
> - 0x00000001 /* MC_EMEM_ARB_TIMING_RP */
> - 0x00000002 /* MC_EMEM_ARB_TIMING_RC */
> - 0x00000000 /* MC_EMEM_ARB_TIMING_RAS */
> - 0x00000002 /* MC_EMEM_ARB_TIMING_FAW */
> - 0x00000001 /* MC_EMEM_ARB_TIMING_RRD */
> - 0x00000002 /* MC_EMEM_ARB_TIMING_RAP2PRE */
> - 0x00000008 /* MC_EMEM_ARB_TIMING_WAP2PRE */
> - 0x00000003 /* MC_EMEM_ARB_TIMING_R2R */
> - 0x00000002 /* MC_EMEM_ARB_TIMING_W2W */
> - 0x00000003 /* MC_EMEM_ARB_TIMING_R2W */
> - 0x00000006 /* MC_EMEM_ARB_TIMING_W2R */
> - 0x06030203 /* MC_EMEM_ARB_DA_TURNS */
> - 0x000a0402 /* MC_EMEM_ARB_DA_COVERS */
> - 0x77e30303 /* MC_EMEM_ARB_MISC0 */
> - 0x70000f03 /* MC_EMEM_ARB_MISC1 */
> - 0x001f0000 /* MC_EMEM_ARB_RING1_THROTTLE */
> - >;
> - };
> - };
> - };
> -};
> --
> 2.22.0
>
^ permalink raw reply
* Re: [PATCH v3 3/3] media: dt-bindings: imx7-csi: add i.MX6UL/L support
From: Fabio Estevam @ 2019-08-01 16:15 UTC (permalink / raw)
To: Sébastien Szymanski
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:STAGING SUBSYSTEM, Pengutronix Kernel Team, Rob Herring,
Greg Kroah-Hartman, Sascha Hauer, Rob Herring, NXP Linux Team,
Philipp Zabel, Steve Longerbeam, Mauro Carvalho Chehab, Shawn Guo,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-media
In-Reply-To: <20190731163358.32622-1-sebastien.szymanski@armadeus.com>
On Wed, Jul 31, 2019 at 1:34 PM Sébastien Szymanski
<sebastien.szymanski@armadeus.com> wrote:
>
> Document "fsl,imx6ul-csi" entry.
>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
^ permalink raw reply
* Re: [PATCH v3 2/3] media: imx7-media-csi: add i.MX6UL support
From: Fabio Estevam @ 2019-08-01 16:14 UTC (permalink / raw)
To: Sébastien Szymanski
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:STAGING SUBSYSTEM, Pengutronix Kernel Team,
Greg Kroah-Hartman, Sascha Hauer, Rui Miguel Silva, Rob Herring,
NXP Linux Team, Philipp Zabel, Steve Longerbeam,
Mauro Carvalho Chehab, Shawn Guo,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-media
In-Reply-To: <20190731163330.32532-1-sebastien.szymanski@armadeus.com>
On Wed, Jul 31, 2019 at 1:33 PM Sébastien Szymanski
<sebastien.szymanski@armadeus.com> wrote:
>
> i.MX7 and i.MX6UL/L have the same CSI controller. So add i.MX6UL/L support
> to imx7-media-csi driver.
>
> Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 10/20] clk: tegra: clk-dfll: Add suspend and resume support
From: Sowjanya Komatineni @ 2019-08-01 16:10 UTC (permalink / raw)
To: Dmitry Osipenko, thierry.reding@gmail.com, Jonathan Hunter,
tglx@linutronix.de, jason@lakedaemon.net, marc.zyngier@arm.com,
linus.walleij@linaro.org, stefan@agner.ch, mark.rutland@arm.com
Cc: Peter De Schrijver, Prashant Gaikwad, sboyd@kernel.org,
linux-clk@vger.kernel.org, linux-gpio@vger.kernel.org,
Jui Chang Kuo, Joseph Lo, Timo Alho, linux-tegra@vger.kernel.org,
linux-kernel@vger.kernel.org, Mikko Perttunen, Sandipan Patra,
robh+dt@kernel.org, devicetree@vger.kernel.org, rjw@rjwysocki.net,
viresh.kumar@linaro.org, linux-pm@vger.kernel.org
In-Reply-To: <501a9d0e-ce78-9b35-642d-dff7f9223926@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3986 bytes --]
I didn’t updated any patches. This is still same v7 just resent with CPUFreq maintainers in CC as I missed to add them earlier.
________________________________
From: Dmitry Osipenko <digetx@gmail.com>
Sent: Thursday, August 1, 2019 3:37:21 AM
To: Sowjanya Komatineni <skomatineni@nvidia.com>; thierry.reding@gmail.com <thierry.reding@gmail.com>; Jonathan Hunter <jonathanh@nvidia.com>; tglx@linutronix.de <tglx@linutronix.de>; jason@lakedaemon.net <jason@lakedaemon.net>; marc.zyngier@arm.com <marc.zyngier@arm.com>; linus.walleij@linaro.org <linus.walleij@linaro.org>; stefan@agner.ch <stefan@agner.ch>; mark.rutland@arm.com <mark.rutland@arm.com>
Cc: Peter De Schrijver <pdeschrijver@nvidia.com>; Prashant Gaikwad <pgaikwad@nvidia.com>; sboyd@kernel.org <sboyd@kernel.org>; linux-clk@vger.kernel.org <linux-clk@vger.kernel.org>; linux-gpio@vger.kernel.org <linux-gpio@vger.kernel.org>; Jui Chang Kuo <jckuo@nvidia.com>; Joseph Lo <josephl@nvidia.com>; Timo Alho <talho@nvidia.com>; linux-tegra@vger.kernel.org <linux-tegra@vger.kernel.org>; linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>; Mikko Perttunen <mperttunen@nvidia.com>; Sandipan Patra <spatra@nvidia.com>; robh+dt@kernel.org <robh+dt@kernel.org>; devicetree@vger.kernel.org <devicetree@vger.kernel.org>; rjw@rjwysocki.net <rjw@rjwysocki.net>; viresh.kumar@linaro.org <viresh.kumar@linaro.org>; linux-pm@vger.kernel.org <linux-pm@vger.kernel.org>
Subject: Re: [PATCH v7 10/20] clk: tegra: clk-dfll: Add suspend and resume support
01.08.2019 13:18, Dmitry Osipenko пишет:
> 01.08.2019 0:10, Sowjanya Komatineni пишет:
>> This patch implements DFLL suspend and resume operation.
>>
>> During system suspend entry, CPU clock will switch CPU to safe
>> clock source of PLLP and disables DFLL clock output.
>>
>> DFLL driver suspend confirms DFLL disable state and errors out on
>> being active.
>>
>> DFLL is re-initialized during the DFLL driver resume as it goes
>> through complete reset during suspend entry.
>>
>> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
>> ---
>> drivers/clk/tegra/clk-dfll.c | 56 ++++++++++++++++++++++++++++++
>> drivers/clk/tegra/clk-dfll.h | 2 ++
>> drivers/clk/tegra/clk-tegra124-dfll-fcpu.c | 1 +
>> 3 files changed, 59 insertions(+)
>>
>> diff --git a/drivers/clk/tegra/clk-dfll.c b/drivers/clk/tegra/clk-dfll.c
>> index f8688c2ddf1a..9900097ec2aa 100644
>> --- a/drivers/clk/tegra/clk-dfll.c
>> +++ b/drivers/clk/tegra/clk-dfll.c
>> @@ -1513,6 +1513,62 @@ static int dfll_init(struct tegra_dfll *td)
>> return ret;
>> }
>>
>> +/**
>> + * tegra_dfll_suspend - check DFLL is disabled
>> + * @dev: DFLL device *
>> + *
>> + * DFLL clock should be disabled by the CPUFreq driver. So, make
>> + * sure it is disabled and disable all clocks needed by the DFLL.
>> + */
>> +int tegra_dfll_suspend(struct device *dev)
>> +{
>> + struct tegra_dfll *td = dev_get_drvdata(dev);
>> +
>> + if (dfll_is_running(td)) {
>> + dev_err(td->dev, "dfll is enabled while shouldn't be\n");
>> + return -EBUSY;
>> + }
>> +
>> + reset_control_assert(td->dvco_rst);
>> +
>> + return 0;
>> +}
>> +EXPORT_SYMBOL(tegra_dfll_suspend);
>> +
>> +/**
>> + * tegra_dfll_resume - reinitialize DFLL on resume
>> + * @dev: DFLL instance
>> + *
>> + * DFLL is disabled and reset during suspend and resume.
>> + * So, reinitialize the DFLL IP block back for use.
>> + * DFLL clock is enabled later in closed loop mode by CPUFreq
>> + * driver before switching its clock source to DFLL output.
>> + */
>> +int tegra_dfll_resume(struct device *dev)
>> +{
>> + struct tegra_dfll *td = dev_get_drvdata(dev);
>> +
>> + reset_control_deassert(td->dvco_rst);
>> +
>> + pm_runtime_irq_safe(td->dev);
>
> Please see my previous reply.
>
Also, you should always bump version of the patches no matter what.
otherwise it turns out very confusing.
[-- Attachment #2: Type: text/html, Size: 6089 bytes --]
^ permalink raw reply
* Re: [PATCH 5/8] arm64: use ZONE_DMA on DMA addressing limited devices
From: Robin Murphy @ 2019-08-01 16:07 UTC (permalink / raw)
To: Nicolas Saenz Julienne, Catalin Marinas
Cc: phill, devicetree, linux-rpi-kernel, f.fainelli, frowand.list,
eric, marc.zyngier, Will Deacon, linux-kernel, linux-mm, iommu,
robh+dt, wahrenst, mbrugger, akpm, hch, linux-arm-kernel,
m.szyprowski
In-Reply-To: <d8b4a7cb9c06824ca88a0602a5bf38b6324b43c0.camel@suse.de>
On 2019-08-01 4:44 pm, Nicolas Saenz Julienne wrote:
> On Wed, 2019-07-31 at 18:07 +0100, Catalin Marinas wrote:
>> On Wed, Jul 31, 2019 at 05:47:48PM +0200, Nicolas Saenz Julienne wrote:
>>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>>> index 1c4ffabbe1cb..f5279ef85756 100644
>>> --- a/arch/arm64/mm/init.c
>>> +++ b/arch/arm64/mm/init.c
>>> @@ -50,6 +50,13 @@
>>> s64 memstart_addr __ro_after_init = -1;
>>> EXPORT_SYMBOL(memstart_addr);
>>>
>>> +/*
>>> + * We might create both a ZONE_DMA and ZONE_DMA32. ZONE_DMA is needed if
>>> there
>>> + * are periferals unable to address the first naturally aligned 4GB of ram.
>>> + * ZONE_DMA32 will be expanded to cover the rest of that memory. If such
>>> + * limitations doesn't exist only ZONE_DMA32 is created.
>>> + */
>>
>> Shouldn't we instead only create ZONE_DMA to cover the whole 32-bit
>> range and leave ZONE_DMA32 empty? Can__GFP_DMA allocations fall back
>> onto ZONE_DMA32?
>
> Hi Catalin, thanks for the review.
>
> You're right, the GFP_DMA page allocation will fail with a nasty dmesg error if
> ZONE_DMA is configured but empty. Unsurprisingly the opposite situation is fine
> (GFP_DMA32 with an empty ZONE_DMA32).
Was that tested on something other than RPi4 with more than 4GB of RAM?
(i.e. with a non-empty ZONE_NORMAL either way)
Robin.
> I switched to the scheme you're suggesting for the next version of the series.
> The comment will be something the likes of this:
>
> /*
> * We create both a ZONE_DMA and ZONE_DMA32. ZONE_DMA's size is decided based
> * on whether the SoC's peripherals are able to address the first naturally
> * aligned 4 GB of ram.
> *
> * If limited, ZONE_DMA covers that area and ZONE_DMA32 the rest of that 32 bit
> * addressable memory.
> *
> * If not ZONE_DMA is expanded to cover the whole 32 bit addressable memory and
> * ZONE_DMA32 is left empty.
> */
>
> Regards,
> Nicolas
>
>
^ permalink raw reply
* Re: [PATCH 6/8] dma-direct: turn ARCH_ZONE_DMA_BITS into a variable
From: Nicolas Saenz Julienne @ 2019-08-01 15:59 UTC (permalink / raw)
To: Christoph Hellwig
Cc: catalin.marinas, wahrenst, marc.zyngier, Robin Murphy,
linux-arm-kernel, devicetree, iommu, linux-mm, Marek Szyprowski,
phill, f.fainelli, will, linux-kernel, robh+dt, eric, mbrugger,
akpm, frowand.list, linux-rpi-kernel, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, linuxppc-dev
In-Reply-To: <20190801140452.GB23435@lst.de>
[-- Attachment #1: Type: text/plain, Size: 2485 bytes --]
Hi Christoph, thanks for the review.
On Thu, 2019-08-01 at 16:04 +0200, Christoph Hellwig wrote:
> A few nitpicks, otherwise this looks great:
>
> > @@ -201,7 +202,7 @@ static int __init mark_nonram_nosave(void)
> > * everything else. GFP_DMA32 page allocations automatically fall back to
> > * ZONE_DMA.
> > *
> > - * By using 31-bit unconditionally, we can exploit ARCH_ZONE_DMA_BITS to
> > + * By using 31-bit unconditionally, we can exploit arch_zone_dma_bits to
> > * inform the generic DMA mapping code. 32-bit only devices (if not
> > handled
> > * by an IOMMU anyway) will take a first dip into ZONE_NORMAL and get
> > * otherwise served by ZONE_DMA.
> > @@ -237,9 +238,18 @@ void __init paging_init(void)
> > printk(KERN_DEBUG "Memory hole size: %ldMB\n",
> > (long int)((top_of_ram - total_ram) >> 20));
> >
> > + /*
> > + * Allow 30-bit DMA for very limited Broadcom wifi chips on many
> > + * powerbooks.
> > + */
> > + if (IS_ENABLED(CONFIG_PPC32))
> > + arch_zone_dma_bits = 30;
> > + else
> > + arch_zone_dma_bits = 31;
> > +
>
> So the above unconditionally comment obviously isn't true any more, and
> Ben also said for the recent ppc32 hack he'd prefer dynamic detection.
>
> Maybe Ben and or other ppc folks can chime in an add a patch to the series
> to sort this out now that we have a dynamic ZONE_DMA threshold?
Noted, for now I'll remove the comment.
> > diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> > index 59bdceea3737..40dfc9b4ee4c 100644
> > --- a/kernel/dma/direct.c
> > +++ b/kernel/dma/direct.c
> > @@ -19,9 +19,7 @@
> > * Most architectures use ZONE_DMA for the first 16 Megabytes, but
> > * some use it for entirely different regions:
> > */
> > -#ifndef ARCH_ZONE_DMA_BITS
> > -#define ARCH_ZONE_DMA_BITS 24
> > -#endif
> > +unsigned int arch_zone_dma_bits __ro_after_init = 24;
>
> I'd prefer to drop the arch_ prefix and just calls this zone_dma_bits.
> In the long run we really need to find a way to just automatically set
> this from the meminit code, but that is out of scope for this series.
> For now can you please just update the comment above to say something
> like:
>
> /*
> * Most architectures use ZONE_DMA for the first 16 Megabytes, but some use it
> * it for entirely different regions. In that case the arch code needs to
> * override the variable below for dma-direct to work properly.
> */
Ok perfect.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v3 4/5] RISC-V: Export few kernel symbols
From: Christoph Hellwig @ 2019-08-01 15:56 UTC (permalink / raw)
To: Atish Patra
Cc: linux-kernel, Mark Rutland, devicetree, Albert Ou, Daniel Lezcano,
Yangtao Li, Greg Kroah-Hartman, Anup Patel, Johan Hovold,
Rob Herring, Palmer Dabbelt, Gary Guo, Paul Walmsley, linux-riscv,
Enrico Weigelt, Thomas Gleixner, Allison Randal
In-Reply-To: <20190801005843.10343-5-atish.patra@wdc.com>
On Wed, Jul 31, 2019 at 05:58:42PM -0700, Atish Patra wrote:
> Export few symbols used by kvm module. Without this, kvm can not
> be compiled as a module.
Please add this to the kvm series instead as we don't merge exports
without their users in the same series.
^ permalink raw reply
* Re: [PATCH v2 2/6] irqchip/irq-pruss-intc: Add a PRUSS irqchip driver for PRUSS interrupts
From: Suman Anna @ 2019-08-01 15:51 UTC (permalink / raw)
To: Marc Zyngier, Thomas Gleixner, Jason Cooper
Cc: devicetree, Grygorii Strashko, David Lechner, Tony Lindgren,
Sekhar Nori, linux-kernel, Andrew F. Davis, Lokesh Vutla,
Rob Herring, Murali Karicheri, linux-omap, linux-arm-kernel,
Roger Quadros
In-Reply-To: <d0d539c2-4247-d74e-3bb2-ddb98e0bafb5@kernel.org>
Hi Marc,
On 8/1/19 4:42 AM, Marc Zyngier wrote:
> On 31/07/2019 23:41, Suman Anna wrote:
>> From: "Andrew F. Davis" <afd@ti.com>
>>
>> The Programmable Real-Time Unit Subsystem (PRUSS) contains a local
>> interrupt controller (INTC) that can handle various system input events
>> and post interrupts back to the device-level initiators. The INTC can
>> support upto 64 input events with individual control configuration and
>> hardware prioritization. These events are mapped onto 10 output interrupt
>> lines through two levels of many-to-one mapping support. Different
>> interrupt lines are routed to the individual PRU cores or to the host
>> CPU, or to other devices on the SoC. Some of these events are sourced
>> from peripherals or other sub-modules within that PRUSS, while a few
>> others are sourced from SoC-level peripherals/devices.
>>
>> The PRUSS INTC platform driver manages this PRUSS interrupt controller
>> and implements an irqchip driver to provide a Linux standard way for
>> the PRU client users to enable/disable/ack/re-trigger a PRUSS system
>> event. The system events to interrupt channels and output interrupts
>> relies on the mapping configuration provided either through the PRU
>> firmware blob or via the PRU application's device tree node. The
>> mappings will be programmed during the boot/shutdown of a PRU core.
>>
>> The PRUSS INTC module is reference counted during the interrupt
>> setup phase through the irqchip's irq_request_resources() and
>> irq_release_resources() ops. This restricts the module from being
>> removed as long as there are active interrupt users.
>>
>> The driver currently supports and can be built for OMAP architecture
>> based AM335x, AM437x and AM57xx SoCs; Keystone2 architecture based
>> 66AK2G SoCs and Davinci architecture based OMAP-L13x/AM18x/DA850 SoCs.
>> All of these SoCs support 64 system events, 10 interrupt channels and
>> 10 output interrupt lines per PRUSS INTC with a few SoC integration
>> differences.
>>
>> NOTE:
>> Each PRU-ICSS's INTC on AM57xx SoCs is preceded by a Crossbar that
>> enables multiple external events to be routed to a specific number
>> of input interrupt events. Any non-default external interrupt event
>> directed towards PRUSS needs this crossbar to be setup properly.
>>
>> Signed-off-by: Andrew F. Davis <afd@ti.com>
>> Signed-off-by: Suman Anna <s-anna@ti.com>
>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>> ---
>> v2:
>> - Addressed all of David Lechner's comments
>> - Dropped irq_retrigger callback
>> - Updated interrupt names from "hostX" to "host_intrX"
>> - Moved host_mask variable to patch 4
>> v1: https://patchwork.kernel.org/patch/11034545/
>> v0: https://patchwork.kernel.org/patch/10795761/
>>
>> drivers/irqchip/Kconfig | 10 +
>> drivers/irqchip/Makefile | 1 +
>> drivers/irqchip/irq-pruss-intc.c | 338 +++++++++++++++++++++++++++++++
>> 3 files changed, 349 insertions(+)
>> create mode 100644 drivers/irqchip/irq-pruss-intc.c
>>
>> diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
>> index 80e10f4e213a..dc6b5aa77a5d 100644
>> --- a/drivers/irqchip/Kconfig
>> +++ b/drivers/irqchip/Kconfig
>> @@ -471,6 +471,16 @@ config TI_SCI_INTA_IRQCHIP
>> If you wish to use interrupt aggregator irq resources managed by the
>> TI System Controller, say Y here. Otherwise, say N.
>>
>> +config TI_PRUSS_INTC
>> + tristate "TI PRU-ICSS Interrupt Controller"
>> + depends on ARCH_DAVINCI || SOC_AM33XX || SOC_AM437X || SOC_DRA7XX || ARCH_KEYSTONE
>> + select IRQ_DOMAIN
>> + help
>> + This enables support for the PRU-ICSS Local Interrupt Controller
>> + present within a PRU-ICSS subsystem present on various TI SoCs.
>> + The PRUSS INTC enables various interrupts to be routed to multiple
>> + different processors within the SoC.
>> +
>> endmenu
>>
>> config SIFIVE_PLIC
>> diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
>> index 8d0fcec6ab23..a02e652ca805 100644
>> --- a/drivers/irqchip/Makefile
>> +++ b/drivers/irqchip/Makefile
>> @@ -102,3 +102,4 @@ obj-$(CONFIG_MADERA_IRQ) += irq-madera.o
>> obj-$(CONFIG_LS1X_IRQ) += irq-ls1x.o
>> obj-$(CONFIG_TI_SCI_INTR_IRQCHIP) += irq-ti-sci-intr.o
>> obj-$(CONFIG_TI_SCI_INTA_IRQCHIP) += irq-ti-sci-inta.o
>> +obj-$(CONFIG_TI_PRUSS_INTC) += irq-pruss-intc.o
>> diff --git a/drivers/irqchip/irq-pruss-intc.c b/drivers/irqchip/irq-pruss-intc.c
>> new file mode 100644
>> index 000000000000..4a9456544fd0
>> --- /dev/null
>> +++ b/drivers/irqchip/irq-pruss-intc.c
>> @@ -0,0 +1,338 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * PRU-ICSS INTC IRQChip driver for various TI SoCs
>> + *
>> + * Copyright (C) 2016-2019 Texas Instruments Incorporated - http://www.ti.com/
>> + * Andrew F. Davis <afd@ti.com>
>> + * Suman Anna <s-anna@ti.com>
>> + */
>> +
>> +#include <linux/irq.h>
>> +#include <linux/irqchip/chained_irq.h>
>> +#include <linux/irqdomain.h>
>> +#include <linux/module.h>
>> +#include <linux/of_device.h>
>> +#include <linux/platform_device.h>
>> +
>> +/*
>> + * Number of host interrupts reaching the main MPU sub-system. Note that this
>> + * is not the same as the total number of host interrupts supported by the PRUSS
>> + * INTC instance
>> + */
>> +#define MAX_NUM_HOST_IRQS 8
>> +
>> +/* minimum starting host interrupt number for MPU */
>> +#define MIN_PRU_HOST_INT 2
>> +
>> +/* maximum number of system events */
>> +#define MAX_PRU_SYS_EVENTS 64
>> +
>> +/* PRU_ICSS_INTC registers */
>> +#define PRU_INTC_REVID 0x0000
>> +#define PRU_INTC_CR 0x0004
>> +#define PRU_INTC_GER 0x0010
>> +#define PRU_INTC_GNLR 0x001c
>> +#define PRU_INTC_SISR 0x0020
>> +#define PRU_INTC_SICR 0x0024
>> +#define PRU_INTC_EISR 0x0028
>> +#define PRU_INTC_EICR 0x002c
>> +#define PRU_INTC_HIEISR 0x0034
>> +#define PRU_INTC_HIDISR 0x0038
>> +#define PRU_INTC_GPIR 0x0080
>> +#define PRU_INTC_SRSR0 0x0200
>> +#define PRU_INTC_SRSR1 0x0204
>> +#define PRU_INTC_SECR0 0x0280
>> +#define PRU_INTC_SECR1 0x0284
>> +#define PRU_INTC_ESR0 0x0300
>> +#define PRU_INTC_ESR1 0x0304
>> +#define PRU_INTC_ECR0 0x0380
>> +#define PRU_INTC_ECR1 0x0384
>> +#define PRU_INTC_CMR(x) (0x0400 + (x) * 4)
>> +#define PRU_INTC_HMR(x) (0x0800 + (x) * 4)
>> +#define PRU_INTC_HIPIR(x) (0x0900 + (x) * 4)
>> +#define PRU_INTC_SIPR0 0x0d00
>> +#define PRU_INTC_SIPR1 0x0d04
>> +#define PRU_INTC_SITR0 0x0d80
>> +#define PRU_INTC_SITR1 0x0d84
>> +#define PRU_INTC_HINLR(x) (0x1100 + (x) * 4)
>> +#define PRU_INTC_HIER 0x1500
>> +
>> +/* HIPIR register bit-fields */
>> +#define INTC_HIPIR_NONE_HINT 0x80000000
>> +
>> +/**
>> + * struct pruss_intc - PRUSS interrupt controller structure
>> + * @irqs: kernel irq numbers corresponding to PRUSS host interrupts
>> + * @base: base virtual address of INTC register space
>> + * @irqchip: irq chip for this interrupt controller
>> + * @domain: irq domain for this interrupt controller
>> + * @lock: mutex to serialize access to INTC
>> + */
>> +struct pruss_intc {
>> + unsigned int irqs[MAX_NUM_HOST_IRQS];
>> + void __iomem *base;
>> + struct irq_chip *irqchip;
>> + struct irq_domain *domain;
>> + struct mutex lock; /* PRUSS INTC lock */
>
> Nothing seem to use that lock in this patch (other than to initialize it).
Correct, will move this to patch 4 where the actual usage is similar to
the host_mask move done in this version.
>
>> +};
>> +
>> +static inline u32 pruss_intc_read_reg(struct pruss_intc *intc, unsigned int reg)
>> +{
>> + return readl_relaxed(intc->base + reg);
>> +}
>> +
>> +static inline void pruss_intc_write_reg(struct pruss_intc *intc,
>> + unsigned int reg, u32 val)
>> +{
>> + writel_relaxed(val, intc->base + reg);
>> +}
>> +
>> +static int pruss_intc_check_write(struct pruss_intc *intc, unsigned int reg,
>> + unsigned int sysevent)
>> +{
>> + if (!intc)
>> + return -EINVAL;
>> +
>> + if (sysevent >= MAX_PRU_SYS_EVENTS)
>> + return -EINVAL;
>
> How can any of these happen? That'd be a bug in the driver surely.
> Also, nothing ever checks the return value.
Yeah, I think I can drop this. The ack/mask/unmask callbacks are all
void returning functions, but we do return the value in
irq_set_irqchip_state() callback added in patch 5 (will reorder that
patch for the next version). This is similar to the check in
gic_irq_set_irqchip_state().
>
>> +
>> + pruss_intc_write_reg(intc, reg, sysevent);
>> +
>> + return 0;
>> +}
>> +
>> +static void pruss_intc_init(struct pruss_intc *intc)
>> +{
>> + int i;
>> +
>> + /* configure polarity to active high for all system interrupts */
>> + pruss_intc_write_reg(intc, PRU_INTC_SIPR0, 0xffffffff);
>> + pruss_intc_write_reg(intc, PRU_INTC_SIPR1, 0xffffffff);
>> +
>> + /* configure type to pulse interrupt for all system interrupts */
>> + pruss_intc_write_reg(intc, PRU_INTC_SITR0, 0);
>> + pruss_intc_write_reg(intc, PRU_INTC_SITR1, 0);
>> +
>> + /* clear all 16 interrupt channel map registers */
>> + for (i = 0; i < 16; i++)
>> + pruss_intc_write_reg(intc, PRU_INTC_CMR(i), 0);
>> +
>> + /* clear all 3 host interrupt map registers */
>> + for (i = 0; i < 3; i++)
>> + pruss_intc_write_reg(intc, PRU_INTC_HMR(i), 0);
>> +}
>> +
>> +static void pruss_intc_irq_ack(struct irq_data *data)
>> +{
>> + struct pruss_intc *intc = irq_data_get_irq_chip_data(data);
>> + unsigned int hwirq = data->hwirq;
>> +
>> + pruss_intc_check_write(intc, PRU_INTC_SICR, hwirq);
>> +}
>> +
>> +static void pruss_intc_irq_mask(struct irq_data *data)
>> +{
>> + struct pruss_intc *intc = irq_data_get_irq_chip_data(data);
>> + unsigned int hwirq = data->hwirq;
>> +
>> + pruss_intc_check_write(intc, PRU_INTC_EICR, hwirq);
>> +}
>> +
>> +static void pruss_intc_irq_unmask(struct irq_data *data)
>> +{
>> + struct pruss_intc *intc = irq_data_get_irq_chip_data(data);
>> + unsigned int hwirq = data->hwirq;
>> +
>> + pruss_intc_check_write(intc, PRU_INTC_EISR, hwirq);
>> +}
>> +
>> +static int pruss_intc_irq_reqres(struct irq_data *data)
>> +{
>> + if (!try_module_get(THIS_MODULE))
>> + return -ENODEV;
>> +
>> + return 0;
>> +}
>> +
>> +static void pruss_intc_irq_relres(struct irq_data *data)
>> +{
>> + module_put(THIS_MODULE);
>> +}
>> +
>> +static int pruss_intc_irq_domain_map(struct irq_domain *d, unsigned int virq,
>> + irq_hw_number_t hw)
>> +{
>> + struct pruss_intc *intc = d->host_data;
>> +
>> + irq_set_chip_data(virq, intc);
>> + irq_set_chip_and_handler(virq, intc->irqchip, handle_level_irq);
>> +
>> + return 0;
>> +}
>> +
>> +static void pruss_intc_irq_domain_unmap(struct irq_domain *d, unsigned int virq)
>> +{
>> + irq_set_chip_and_handler(virq, NULL, NULL);
>> + irq_set_chip_data(virq, NULL);
>> +}
>> +
>> +static const struct irq_domain_ops pruss_intc_irq_domain_ops = {
>> + .xlate = irq_domain_xlate_onecell,
>> + .map = pruss_intc_irq_domain_map,
>> + .unmap = pruss_intc_irq_domain_unmap,
>> +};
>> +
>> +static void pruss_intc_irq_handler(struct irq_desc *desc)
>> +{
>> + unsigned int irq = irq_desc_get_irq(desc);
>> + struct irq_chip *chip = irq_desc_get_chip(desc);
>> + struct pruss_intc *intc = irq_get_handler_data(irq);
>> + u32 hipir;
>> + unsigned int virq;
>> + int i, hwirq;
>> +
>> + chained_irq_enter(chip, desc);
>> +
>> + /* find our host irq number */
>> + for (i = 0; i < MAX_NUM_HOST_IRQS; i++)
>> + if (intc->irqs[i] == irq)
>> + break;
>> + if (i == MAX_NUM_HOST_IRQS)
>> + goto err;
>> +
>> + i += MIN_PRU_HOST_INT;
>> +
>> + /* get highest priority pending PRUSS system event */
>> + hipir = pruss_intc_read_reg(intc, PRU_INTC_HIPIR(i));
>> + while (!(hipir & INTC_HIPIR_NONE_HINT)) {
>> + hwirq = hipir & GENMASK(9, 0);
>> + virq = irq_linear_revmap(intc->domain, hwirq);
>> +
>> + /*
>> + * NOTE: manually ACK any system events that do not have a
>> + * handler mapped yet
>> + */
>> + if (unlikely(!virq))
>> + pruss_intc_check_write(intc, PRU_INTC_SICR, hwirq);
>
> How were they configured the first place?
Ideally, this should not occur, I probably should add a WARN_ON here
catching any misuse. The PRUSS INTC is touched by multiple processors,
and each of them have to use some of the same registers to ack the
internal event. The current design is limited to only acking and
triggering the interrupts from PRU firmwares while the mappings are all
done by Linux. We are forced to do this to save some instruction space
in the tiny Instruction RAM that the PRUs (smallest is 4K and largest is
12K) have.
>
>> + else
>> + generic_handle_irq(virq);
>> +
>> + /* get next system event */
>> + hipir = pruss_intc_read_reg(intc, PRU_INTC_HIPIR(i));
>> + }
>> +err:
>> + chained_irq_exit(chip, desc);
>> +}
>> +
>> +static int pruss_intc_probe(struct platform_device *pdev)
>> +{
>> + static const char * const irq_names[] = {
>
> Should this be sized with MAX_NUM_HOST_IRQS, given that this is how you
> parse it?
Yes, will update in the next version.
>
>> + "host_intr0", "host_intr1", "host_intr2", "host_intr3",
>> + "host_intr4", "host_intr5", "host_intr6", "host_intr7", };
>> + struct device *dev = &pdev->dev;
>> + struct pruss_intc *intc;
>> + struct resource *res;
>> + struct irq_chip *irqchip;
>> + int i, irq;
>> +
>> + intc = devm_kzalloc(dev, sizeof(*intc), GFP_KERNEL);
>> + if (!intc)
>> + return -ENOMEM;
>> + platform_set_drvdata(pdev, intc);
>> +
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + intc->base = devm_ioremap_resource(dev, res);
>> + if (IS_ERR(intc->base)) {
>> + dev_err(dev, "failed to parse and map intc memory resource\n");
>> + return PTR_ERR(intc->base);
>> + }
>> +
>> + dev_dbg(dev, "intc memory: pa %pa size 0x%zx va %pK\n", &res->start,
>> + (size_t)resource_size(res), intc->base);
>> +
>> + mutex_init(&intc->lock);
>> +
>> + pruss_intc_init(intc);
>> +
>> + irqchip = devm_kzalloc(dev, sizeof(*irqchip), GFP_KERNEL);
>> + if (!irqchip)
>> + return -ENOMEM;
>> +
>> + irqchip->irq_ack = pruss_intc_irq_ack;
>> + irqchip->irq_mask = pruss_intc_irq_mask;
>> + irqchip->irq_unmask = pruss_intc_irq_unmask;
>> + irqchip->irq_request_resources = pruss_intc_irq_reqres;
>> + irqchip->irq_release_resources = pruss_intc_irq_relres;
>> + irqchip->name = dev_name(dev);
>> + intc->irqchip = irqchip;
>
> Given that each and every pruss_intc ends up with a pointer to its own
> irqchip, why is it a separate allocation instead of directly embedding
> the structure?
>
> Alternatively, have a single 'static const struct irq_chip' and lose the
> slightly pointless dev_name as the irqchip name.
Agreed, this can be optimized.
>
>> +
>> + /* always 64 events */
>> + intc->domain = irq_domain_add_linear(dev->of_node, MAX_PRU_SYS_EVENTS,
>> + &pruss_intc_irq_domain_ops, intc);
>> + if (!intc->domain)
>> + return -ENOMEM;
>> +
>> + for (i = 0; i < MAX_NUM_HOST_IRQS; i++) {
>> + irq = platform_get_irq_byname(pdev, irq_names[i]);
>> + if (irq < 0) {
>
> irq == 0 is also an error.
OK, will fix.
>
>> + dev_err(dev, "platform_get_irq_byname failed for %s : %d\n",
>> + irq_names[i], irq);
>> + goto fail_irq;
>> + }
>> +
>> + intc->irqs[i] = irq;
>> + irq_set_handler_data(irq, intc);
>> + irq_set_chained_handler(irq, pruss_intc_irq_handler);
>> + }
>> +
>> + return 0;
>> +
>> +fail_irq:
>> + while (--i >= 0) {
>> + if (intc->irqs[i])
>
> This 'if' seems supperfluous.
So, some interrupts among the MAX_NUM_HOST_IRQS are not connected to the
Arm processor on some SoCs. I will move this check to the next patch
which introduces the skipping of interrupts.
>
>> + irq_set_chained_handler_and_data(intc->irqs[i], NULL,
>> + NULL);
>> + }
>> + irq_domain_remove(intc->domain);
>> + return irq;
>> +}
>> +
>> +static int pruss_intc_remove(struct platform_device *pdev)
>> +{
>> + struct pruss_intc *intc = platform_get_drvdata(pdev);
>> + unsigned int hwirq;
>> + int i;
>> +
>> + for (i = 0; i < MAX_NUM_HOST_IRQS; i++) {
>> + if (intc->irqs[i])
>
> Same here.
Will move this as well.
>
>> + irq_set_chained_handler_and_data(intc->irqs[i], NULL,
>> + NULL);
>> + }
>> +
>> + for (hwirq = 0; hwirq < MAX_PRU_SYS_EVENTS; hwirq++)
>> + irq_dispose_mapping(irq_find_mapping(intc->domain, hwirq));
>> + irq_domain_remove(intc->domain);
>> +
>> + return 0;
>> +}
>> +
>> +static const struct of_device_id pruss_intc_of_match[] = {
>> + { .compatible = "ti,pruss-intc", },
>> + { /* sentinel */ },
>> +};
>> +MODULE_DEVICE_TABLE(of, pruss_intc_of_match);
>> +
>> +static struct platform_driver pruss_intc_driver = {
>> + .driver = {
>> + .name = "pruss-intc",
>> + .of_match_table = pruss_intc_of_match,
>> + },
>> + .probe = pruss_intc_probe,
>> + .remove = pruss_intc_remove,
>> +};
>> +module_platform_driver(pruss_intc_driver);
>> +
>> +MODULE_AUTHOR("Andrew F. Davis <afd@ti.com>");
>> +MODULE_AUTHOR("Suman Anna <s-anna@ti.com>");
>> +MODULE_DESCRIPTION("TI PRU-ICSS INTC Driver");
>> +MODULE_LICENSE("GPL v2");
>>
>
> Thanks,
>
Thank you for all the review comments.
regards
Suman
^ permalink raw reply
* Re: [PATCH v3 5/5] dt-bindings: Update the riscv,isa string description
From: Rob Herring @ 2019-08-01 15:50 UTC (permalink / raw)
To: Atish Patra
Cc: linux-kernel@vger.kernel.org, Paul Walmsley, Albert Ou,
Allison Randal, Anup Patel, Daniel Lezcano, devicetree,
Enrico Weigelt, Gary Guo, Greg Kroah-Hartman, Johan Hovold,
linux-riscv, Mark Rutland, Palmer Dabbelt, Thomas Gleixner,
Yangtao Li
In-Reply-To: <20190801005843.10343-6-atish.patra@wdc.com>
On Wed, Jul 31, 2019 at 6:58 PM Atish Patra <atish.patra@wdc.com> wrote:
>
> Since the RISC-V specification states that ISA description strings are
> case-insensitive, there's no functional difference between mixed-case,
> upper-case, and lower-case ISA strings. Thus, to simplify parsing,
> specify that the letters present in "riscv,isa" must be all lowercase.
>
> Suggested-by: Paul Walmsley <paul.walmsley@sifive.com>
> Signed-off-by: Atish Patra <atish.patra@wdc.com>
> ---
> Documentation/devicetree/bindings/riscv/cpus.yaml | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
> index c899111aa5e3..4f0acb00185a 100644
> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml
> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
> @@ -46,10 +46,12 @@ properties:
> - rv64imafdc
> description:
> Identifies the specific RISC-V instruction set architecture
> - supported by the hart. These are documented in the RISC-V
> + supported by the hart. These are documented in the RISC-V
> User-Level ISA document, available from
> https://riscv.org/specifications/
>
> + Letters in the riscv,isa string must be all lowercase.
> +
The schemas are case sensitive this looks pretty pointless without the
context of the commit msg. Can you prefix with 'While the
specification is case insensitive, "
For some background, FDT generally always has been case sensitive too
(dtc won't merge/override nodes/properties with differing case). It's
really only some older true OF systems that were case insensitive. The
kernel had a mixture of case sensitive and insensitive comparisons
somewhat depending on the arch and whether of_prop_cmp/of_node_cmp or
str*cmp functions were used. There's been a lot of clean-up and now
most comparisons are case sensitive with only Sparc having some
deviation.
Rob
^ permalink raw reply
* Re: [PATCH v3 2/3] media: imx7-media-csi: add i.MX6UL support
From: Rui Miguel Silva @ 2019-08-01 15:50 UTC (permalink / raw)
To: Sébastien Szymanski
Cc: Mark Rutland, devicetree, devel, Pengutronix Kernel Team,
Greg Kroah-Hartman, Fabio Estevam, Sascha Hauer, Rob Herring,
NXP Linux Team, Philipp Zabel, Steve Longerbeam,
Mauro Carvalho Chehab, Shawn Guo, linux-arm-kernel, linux-media
In-Reply-To: <20190731163330.32532-1-sebastien.szymanski@armadeus.com>
Hi Sebastien,
Thanks for the patch.
On Wed 31 Jul 2019 at 17:33, Sébastien Szymanski wrote:
> i.MX7 and i.MX6UL/L have the same CSI controller. So add i.MX6UL/L support
> to imx7-media-csi driver.
>
> Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
>
LGTM. Thanks for adding the support to this imx6ul/l soc.
Reviewed-by: Rui Miguel Silva <rmfrfs@gmail.com>
---
Cheers,
Rui
> ---
>
> Changes for v3:
> - rebase on Linux v5.3-rc2
> - remove csi_soc_id var as it's not needed anymore thanks to commit
> e0c76a7d3428 ("media: imx7-media-csi: get csi upstream endpoint")
>
> Changes for v2:
> - rebase on top of linuxtv/master
> - mention i.MX6UL/L in header and Kconfig help text
> - rename csi_type to csi_soc_id
>
> drivers/staging/media/imx/Kconfig | 4 +--
> drivers/staging/media/imx/imx7-media-csi.c | 30 +++++++++++++++-------
> 2 files changed, 23 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/staging/media/imx/Kconfig b/drivers/staging/media/imx/Kconfig
> index 4c726345dc25..f51476243016 100644
> --- a/drivers/staging/media/imx/Kconfig
> +++ b/drivers/staging/media/imx/Kconfig
> @@ -22,11 +22,11 @@ config VIDEO_IMX_CSI
> A video4linux camera sensor interface driver for i.MX5/6.
>
> config VIDEO_IMX7_CSI
> - tristate "i.MX7 Camera Sensor Interface driver"
> + tristate "i.MX6UL/L / i.MX7 Camera Sensor Interface driver"
> depends on VIDEO_IMX_MEDIA && VIDEO_DEV && I2C
> default y
> help
> Enable support for video4linux camera sensor interface driver for
> - i.MX7.
> + i.MX6UL/L or i.MX7.
> endmenu
> endif
> diff --git a/drivers/staging/media/imx/imx7-media-csi.c b/drivers/staging/media/imx/imx7-media-csi.c
> index 500b4c08d967..4ca79ff4c9b3 100644
> --- a/drivers/staging/media/imx/imx7-media-csi.c
> +++ b/drivers/staging/media/imx/imx7-media-csi.c
> @@ -1,6 +1,6 @@
> // SPDX-License-Identifier: GPL-2.0
> /*
> - * V4L2 Capture CSI Subdev for Freescale i.MX7 SOC
> + * V4L2 Capture CSI Subdev for Freescale i.MX6UL/L / i.MX7 SOC
> *
> * Copyright (c) 2019 Linaro Ltd
> *
> @@ -765,6 +765,7 @@ static int imx7_csi_configure(struct imx7_csi *csi)
> struct v4l2_pix_format *out_pix = &vdev->fmt.fmt.pix;
> __u32 in_code = csi->format_mbus[IMX7_CSI_PAD_SINK].code;
> u32 cr1, cr18;
> + int width = out_pix->width;
>
> if (out_pix->field == V4L2_FIELD_INTERLACED) {
> imx7_csi_deinterlace_enable(csi, true);
> @@ -774,15 +775,27 @@ static int imx7_csi_configure(struct imx7_csi *csi)
> imx7_csi_buf_stride_set(csi, 0);
> }
>
> - imx7_csi_set_imagpara(csi, out_pix->width, out_pix->height);
> + cr18 = imx7_csi_reg_read(csi, CSI_CSICR18);
> +
> + if (!csi->is_csi2) {
> + if (out_pix->pixelformat == V4L2_PIX_FMT_UYVY ||
> + out_pix->pixelformat == V4L2_PIX_FMT_YUYV)
> + width *= 2;
> +
> + imx7_csi_set_imagpara(csi, width, out_pix->height);
> +
> + cr18 |= (BIT_BASEADDR_SWITCH_EN | BIT_BASEADDR_SWITCH_SEL |
> + BIT_BASEADDR_CHG_ERR_EN);
> + imx7_csi_reg_write(csi, cr18, CSI_CSICR18);
>
> - if (!csi->is_csi2)
> return 0;
> + }
> +
> + imx7_csi_set_imagpara(csi, width, out_pix->height);
>
> cr1 = imx7_csi_reg_read(csi, CSI_CSICR1);
> cr1 &= ~BIT_GCLK_MODE;
>
> - cr18 = imx7_csi_reg_read(csi, CSI_CSICR18);
> cr18 &= BIT_MIPI_DATA_FORMAT_MASK;
> cr18 |= BIT_DATA_FROM_MIPI;
>
> @@ -817,11 +830,9 @@ static void imx7_csi_enable(struct imx7_csi *csi)
> {
> imx7_csi_sw_reset(csi);
>
> - if (csi->is_csi2) {
> - imx7_csi_dmareq_rff_enable(csi);
> - imx7_csi_hw_enable_irq(csi);
> - imx7_csi_hw_enable(csi);
> - }
> + imx7_csi_dmareq_rff_enable(csi);
> + imx7_csi_hw_enable_irq(csi);
> + imx7_csi_hw_enable(csi);
> }
>
> static void imx7_csi_disable(struct imx7_csi *csi)
> @@ -1302,6 +1313,7 @@ static int imx7_csi_remove(struct platform_device *pdev)
>
> static const struct of_device_id imx7_csi_of_match[] = {
> { .compatible = "fsl,imx7-csi" },
> + { .compatible = "fsl,imx6ul-csi" },
> { },
> };
> MODULE_DEVICE_TABLE(of, imx7_csi_of_match);
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 8/8] ARM: dts: imx25: mbimxsd25: native-mode is part of display-timings
From: Martin Kaiser @ 2019-08-01 15:46 UTC (permalink / raw)
To: Shawn Guo, Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team
Cc: devicetree, linux-kernel, Martin Kaiser
In-Reply-To: <20190801154628.1624-1-martin@kaiser.cx>
Move the native-mode property inside the display-timings node.
According to
Documentation/devicetree/bindings/display/panel/display-timing.txt.
native-mode is a property of the display-timings node.
If it's located outside of display-timings, the native-mode setting is
ignored and the first display timing is used (which is a problem only if
someone adds another display timing).
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
---
arch/arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard-dvi-vga.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard-dvi-vga.dts b/arch/arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard-dvi-vga.dts
index d60d8f464ca9..24027a1fb46d 100644
--- a/arch/arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard-dvi-vga.dts
+++ b/arch/arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard-dvi-vga.dts
@@ -14,8 +14,8 @@
bits-per-pixel = <16>;
fsl,pcr = <0xfa208b80>;
bus-width = <18>;
- native-mode = <&dvi_vga_timings>;
display-timings {
+ native-mode = <&dvi_vga_timings>;
dvi_vga_timings: 640x480 {
clock-frequency = <31250000>;
hactive = <640>;
--
2.11.0
^ permalink raw reply related
* [PATCH 7/8] ARM: dts: apf27dev: native-mode is part of display-timings
From: Martin Kaiser @ 2019-08-01 15:46 UTC (permalink / raw)
To: Shawn Guo, Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team
Cc: devicetree, linux-kernel, Martin Kaiser
In-Reply-To: <20190801154628.1624-1-martin@kaiser.cx>
Move the native-mode property inside the display-timings node.
According to
Documentation/devicetree/bindings/display/panel/display-timing.txt.
native-mode is a property of the display-timings node.
If it's located outside of display-timings, the native-mode setting is
ignored and the first display timing is used (which is a problem only if
someone adds another display timing).
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
---
arch/arm/boot/dts/imx27-apf27dev.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx27-apf27dev.dts b/arch/arm/boot/dts/imx27-apf27dev.dts
index 087c6e237af0..6f1e8ce9e76e 100644
--- a/arch/arm/boot/dts/imx27-apf27dev.dts
+++ b/arch/arm/boot/dts/imx27-apf27dev.dts
@@ -12,10 +12,10 @@
display: display {
model = "Chimei-LW700AT9003";
- native-mode = <&timing0>;
bits-per-pixel = <16>; /* non-standard but required */
fsl,pcr = <0xfae80083>; /* non-standard but required */
display-timings {
+ native-mode = <&timing0>;
timing0: 800x480 {
clock-frequency = <33000033>;
hactive = <800>;
--
2.11.0
^ permalink raw reply related
* [PATCH 6/8] ARM: dts: edb7211: native-mode is part of display-timings
From: Martin Kaiser @ 2019-08-01 15:46 UTC (permalink / raw)
To: Shawn Guo, Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team
Cc: devicetree, linux-kernel, Martin Kaiser
In-Reply-To: <20190801154628.1624-1-martin@kaiser.cx>
Move the native-mode property inside the display-timings node.
According to
Documentation/devicetree/bindings/display/panel/display-timing.txt.
native-mode is a property of the display-timings node.
If it's located outside of display-timings, the native-mode setting is
ignored and the first display timing is used (which is a problem only if
someone adds another display timing).
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
---
arch/arm/boot/dts/ep7211-edb7211.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/ep7211-edb7211.dts b/arch/arm/boot/dts/ep7211-edb7211.dts
index a0c270f63fee..da076479c8e2 100644
--- a/arch/arm/boot/dts/ep7211-edb7211.dts
+++ b/arch/arm/boot/dts/ep7211-edb7211.dts
@@ -25,11 +25,11 @@
display: display {
model = "320x240x4";
- native-mode = <&timing0>;
bits-per-pixel = <4>;
ac-prescale = <17>;
display-timings {
+ native-mode = <&timing0>;
timing0: 320x240 {
hactive = <320>;
hback-porch = <0>;
--
2.11.0
^ permalink raw reply related
* [PATCH 5/8] ARM: dts: imx27-phytec-phycore-rdk: native-mode is part of display-timings
From: Martin Kaiser @ 2019-08-01 15:46 UTC (permalink / raw)
To: Shawn Guo, Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team
Cc: devicetree, linux-kernel, Martin Kaiser
In-Reply-To: <20190801154628.1624-1-martin@kaiser.cx>
Move the native-mode property inside the display-timings node.
According to
Documentation/devicetree/bindings/display/panel/display-timing.txt.
native-mode is a property of the display-timings node.
If it's located outside of display-timings, the native-mode setting is
ignored and the first display timing is used (which is a problem only if
someone adds another display timing).
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
---
arch/arm/boot/dts/imx27-phytec-phycore-rdk.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx27-phytec-phycore-rdk.dts b/arch/arm/boot/dts/imx27-phytec-phycore-rdk.dts
index 5606f417e9e8..bf883e45576a 100644
--- a/arch/arm/boot/dts/imx27-phytec-phycore-rdk.dts
+++ b/arch/arm/boot/dts/imx27-phytec-phycore-rdk.dts
@@ -14,11 +14,11 @@
display0: LQ035Q7 {
model = "Sharp-LQ035Q7";
- native-mode = <&timing0>;
bits-per-pixel = <16>;
fsl,pcr = <0xf00080c0>;
display-timings {
+ native-mode = <&timing0>;
timing0: 240x320 {
clock-frequency = <5500000>;
hactive = <240>;
--
2.11.0
^ permalink raw reply related
* [PATCH 4/8] ARM: dts: mbimxsd25: native-mode is part of display-timings
From: Martin Kaiser @ 2019-08-01 15:46 UTC (permalink / raw)
To: Shawn Guo, Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team
Cc: devicetree, linux-kernel, Martin Kaiser
In-Reply-To: <20190801154628.1624-1-martin@kaiser.cx>
Move the native-mode property inside the display-timings node.
According to
Documentation/devicetree/bindings/display/panel/display-timing.txt.
native-mode is a property of the display-timings node.
If it's located outside of display-timings, the native-mode setting is
ignored and the first display timing is used (which is a problem only if
someone adds another display timing).
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
---
arch/arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard-cmo-qvga.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard-cmo-qvga.dts b/arch/arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard-cmo-qvga.dts
index dbecd6d2cfc4..7d4301b22b90 100644
--- a/arch/arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard-cmo-qvga.dts
+++ b/arch/arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard-cmo-qvga.dts
@@ -14,8 +14,8 @@
bits-per-pixel = <16>;
fsl,pcr = <0xcad08b80>;
bus-width = <18>;
- native-mode = <&qvga_timings>;
display-timings {
+ native-mode = <&qvga_timings>;
qvga_timings: 320x240 {
clock-frequency = <6500000>;
hactive = <320>;
--
2.11.0
^ permalink raw reply related
* [PATCH 3/8] ARM: dts: eukrea-mbimxsd27: native-mode is part of display-timings
From: Martin Kaiser @ 2019-08-01 15:46 UTC (permalink / raw)
To: Shawn Guo, Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team
Cc: devicetree, linux-kernel, Martin Kaiser
In-Reply-To: <20190801154628.1624-1-martin@kaiser.cx>
Move the native-mode property inside the display-timings node.
According to
Documentation/devicetree/bindings/display/panel/display-timing.txt.
native-mode is a property of the display-timings node.
If it's located outside of display-timings, the native-mode setting is
ignored and the first display timing is used (which is a problem only if
someone adds another display timing).
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
---
arch/arm/boot/dts/imx27-eukrea-mbimxsd27-baseboard.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx27-eukrea-mbimxsd27-baseboard.dts b/arch/arm/boot/dts/imx27-eukrea-mbimxsd27-baseboard.dts
index 84fc8df4be7c..9c3ec82ec7e5 100644
--- a/arch/arm/boot/dts/imx27-eukrea-mbimxsd27-baseboard.dts
+++ b/arch/arm/boot/dts/imx27-eukrea-mbimxsd27-baseboard.dts
@@ -11,11 +11,11 @@
display0: CMO-QVGA {
model = "CMO-QVGA";
- native-mode = <&timing0>;
bits-per-pixel = <16>;
fsl,pcr = <0xfad08b80>;
display-timings {
+ native-mode = <&timing0>;
timing0: 320x240 {
clock-frequency = <6500000>;
hactive = <320>;
--
2.11.0
^ permalink raw reply related
* [PATCH 2/8] ARM: dts: imx25: mbimxsd25: native-mode is part of display-timings
From: Martin Kaiser @ 2019-08-01 15:46 UTC (permalink / raw)
To: Shawn Guo, Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team
Cc: devicetree, linux-kernel, Martin Kaiser
In-Reply-To: <20190801154628.1624-1-martin@kaiser.cx>
Move the native-mode property inside the display-timings node.
According to
Documentation/devicetree/bindings/display/panel/display-timing.txt.
native-mode is a property of the display-timings node.
If it's located outside of display-timings, the native-mode setting is
ignored and the first display timing is used (which is a problem only if
someone adds another display timing).
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
---
arch/arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard-dvi-svga.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard-dvi-svga.dts b/arch/arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard-dvi-svga.dts
index ad2f7e879831..80a7f96de4c6 100644
--- a/arch/arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard-dvi-svga.dts
+++ b/arch/arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard-dvi-svga.dts
@@ -14,8 +14,8 @@
bits-per-pixel = <16>;
fsl,pcr = <0xfa208b80>;
bus-width = <18>;
- native-mode = <&dvi_svga_timings>;
display-timings {
+ native-mode = <&dvi_svga_timings>;
dvi_svga_timings: 800x600 {
clock-frequency = <40000000>;
hactive = <800>;
--
2.11.0
^ permalink raw reply related
* [PATCH 1/8] ARM: dts: imx27 phyCARD-S: native-mode is part of display-timings
From: Martin Kaiser @ 2019-08-01 15:46 UTC (permalink / raw)
To: Shawn Guo, Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team
Cc: devicetree, linux-kernel, Martin Kaiser
In-Reply-To: <20190801154628.1624-1-martin@kaiser.cx>
Move the native-mode property inside the display-timings node.
According to
Documentation/devicetree/bindings/display/panel/display-timing.txt.
native-mode is a property of the display-timings node.
If it's located outside of display-timings, the native-mode setting is
ignored and the first display timing is used (which is a problem only if
someone adds another display timing).
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
---
arch/arm/boot/dts/imx27-phytec-phycard-s-rdk.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx27-phytec-phycard-s-rdk.dts b/arch/arm/boot/dts/imx27-phytec-phycard-s-rdk.dts
index 5e5e282ed30e..0cd75dadf292 100644
--- a/arch/arm/boot/dts/imx27-phytec-phycard-s-rdk.dts
+++ b/arch/arm/boot/dts/imx27-phytec-phycard-s-rdk.dts
@@ -15,10 +15,10 @@
display: display {
model = "Primeview-PD050VL1";
- native-mode = <&timing0>;
bits-per-pixel = <16>; /* non-standard but required */
fsl,pcr = <0xf0c88080>; /* non-standard but required */
display-timings {
+ native-mode = <&timing0>;
timing0: 640x480 {
hactive = <640>;
vactive = <480>;
--
2.11.0
^ permalink raw reply related
* [PATCH 0/8] move native-mode inside display-timings
From: Martin Kaiser @ 2019-08-01 15:46 UTC (permalink / raw)
To: Shawn Guo, Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team
Cc: devicetree, linux-kernel, Martin Kaiser
For display descriptions in the device tree, native-mode is a property
of the display-timings node.
Fix this for the boards that got it wrong and added native-mode on the
same level as display-timings.
Martin Kaiser (8):
ARM: dts: imx27 phyCARD-S: native-mode is part of display-timings
ARM: dts: imx25: mbimxsd25: native-mode is part of display-timings
ARM: dts: eukrea-mbimxsd27: native-mode is part of display-timings
ARM: dts: mbimxsd25: native-mode is part of display-timings
ARM: dts: imx27-phytec-phycore-rdk: native-mode is part of display-timings
ARM: dts: edb7211: native-mode is part of display-timings
ARM: dts: apf27dev: native-mode is part of display-timings
ARM: dts: imx25: mbimxsd25: native-mode is part of display-timings
arch/arm/boot/dts/ep7211-edb7211.dts | 2 +-
arch/arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard-cmo-qvga.dts | 2 +-
arch/arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard-dvi-svga.dts | 2 +-
arch/arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard-dvi-vga.dts | 2 +-
arch/arm/boot/dts/imx27-apf27dev.dts | 2 +-
arch/arm/boot/dts/imx27-eukrea-mbimxsd27-baseboard.dts | 2 +-
arch/arm/boot/dts/imx27-phytec-phycard-s-rdk.dts | 2 +-
arch/arm/boot/dts/imx27-phytec-phycore-rdk.dts | 2 +-
8 files changed, 8 insertions(+), 8 deletions(-)
--
2.11.0
^ permalink raw reply
* Re: [PATCH 5/8] arm64: use ZONE_DMA on DMA addressing limited devices
From: Nicolas Saenz Julienne @ 2019-08-01 15:44 UTC (permalink / raw)
To: Catalin Marinas
Cc: phill, devicetree, linux-rpi-kernel, f.fainelli, frowand.list,
eric, marc.zyngier, Will Deacon, linux-kernel, linux-mm, iommu,
robh+dt, wahrenst, mbrugger, akpm, Robin Murphy, hch,
linux-arm-kernel, m.szyprowski
In-Reply-To: <20190731170742.GC17773@arrakis.emea.arm.com>
[-- Attachment #1: Type: text/plain, Size: 1734 bytes --]
On Wed, 2019-07-31 at 18:07 +0100, Catalin Marinas wrote:
> On Wed, Jul 31, 2019 at 05:47:48PM +0200, Nicolas Saenz Julienne wrote:
> > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > index 1c4ffabbe1cb..f5279ef85756 100644
> > --- a/arch/arm64/mm/init.c
> > +++ b/arch/arm64/mm/init.c
> > @@ -50,6 +50,13 @@
> > s64 memstart_addr __ro_after_init = -1;
> > EXPORT_SYMBOL(memstart_addr);
> >
> > +/*
> > + * We might create both a ZONE_DMA and ZONE_DMA32. ZONE_DMA is needed if
> > there
> > + * are periferals unable to address the first naturally aligned 4GB of ram.
> > + * ZONE_DMA32 will be expanded to cover the rest of that memory. If such
> > + * limitations doesn't exist only ZONE_DMA32 is created.
> > + */
>
> Shouldn't we instead only create ZONE_DMA to cover the whole 32-bit
> range and leave ZONE_DMA32 empty? Can__GFP_DMA allocations fall back
> onto ZONE_DMA32?
Hi Catalin, thanks for the review.
You're right, the GFP_DMA page allocation will fail with a nasty dmesg error if
ZONE_DMA is configured but empty. Unsurprisingly the opposite situation is fine
(GFP_DMA32 with an empty ZONE_DMA32).
I switched to the scheme you're suggesting for the next version of the series.
The comment will be something the likes of this:
/*
* We create both a ZONE_DMA and ZONE_DMA32. ZONE_DMA's size is decided based
* on whether the SoC's peripherals are able to address the first naturally
* aligned 4 GB of ram.
*
* If limited, ZONE_DMA covers that area and ZONE_DMA32 the rest of that 32 bit
* addressable memory.
*
* If not ZONE_DMA is expanded to cover the whole 32 bit addressable memory and
* ZONE_DMA32 is left empty.
*/
Regards,
Nicolas
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [Patch v3 2/2] dt-bindings: spi: spi-fsl-qspi: Add bindings of ls1088a and ls1012a
From: Han Xu @ 2019-08-01 15:24 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, bbrezillon, Kuldeep Singh, Ashish Kumar, broonie,
linux-mtd, linux-arm-kernel
In-Reply-To: <20190709200857.GA8477@bogus>
On Tue, Jul 9, 2019 at 3:09 PM Rob Herring <robh@kernel.org> wrote:
>
> On Wed, 19 Jun 2019 16:41:54 +0530, Ashish Kumar wrote:
> > Signed-off-by: Kuldeep Singh <kuldeep.singh@nxp.com>
> > Signed-off-by: Ashish Kumar <ashish.kumar@nxp.com>
> > ---
> > v3:
> > Rebase to top
> > v2:
> > Convert to patch series and rebasing done on top of tree
> >
> > Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt | 2 ++
> > 1 file changed, 2 insertions(+)
> >
>
> Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Han Xu <han.xu@nxp.com>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
--
Sincerely,
Han XU
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [Patch v3 1/2] dt-bindings: spi: spi-fsl-qspi: Add ls2080a compatibility string to bindings
From: Han Xu @ 2019-08-01 15:22 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, bbrezillon, Kuldeep Singh, Ashish Kumar, broonie,
linux-mtd, linux-arm-kernel
In-Reply-To: <20190709200837.GA7806@bogus>
On Tue, Jul 9, 2019 at 3:09 PM Rob Herring <robh@kernel.org> wrote:
>
> On Wed, 19 Jun 2019 16:41:53 +0530, Ashish Kumar wrote:
> > There are 2 version of QSPI-IP, according to which controller registers sets
> > can be big endian or little endian.There are some other minor changes like
> > RX fifo depth etc.
> >
> > The big endian version uses driver compatible "fsl,ls1021a-qspi" and
> > little endian version uses driver compatible "fsl,ls2080a-qspi"
> >
> > Signed-off-by: Kuldeep Singh <kuldeep.singh@nxp.com>
> > Signed-off-by: Ashish Kumar <ashish.kumar@nxp.com>
> > ---
> > v3:
> > Rebase to top
> > v2:
> > Convert to patch series and rebasing done on top of tree
> >
> > Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
>
> Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Han Xu <han.xu@nxp.com>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [RFC 0/9] dt-bindings: first tentative of conversion to yaml format
From: Rob Herring @ 2019-08-01 15:20 UTC (permalink / raw)
To: Neil Armstrong
Cc: Philipp Zabel, devicetree, LINUX-WATCHDOG, Jassi Brar, linux-spi,
open list:HARDWARE RANDOM NUMBER GENERATOR CORE,
open list:SERIAL DRIVERS, linux-amlogic, Kishon Vijay Abraham I,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190801135644.12843-1-narmstrong@baylibre.com>
On Thu, Aug 1, 2019 at 7:56 AM Neil Armstrong <narmstrong@baylibre.com> wrote:
>
> This is a first tentative to convert some of the simplest Amlogic
> dt-bindings to the yaml format.
Great to see this.
I've gone thru all of the patches. Some of the same minor comments I
made also apply to the patches I didn't comment on.
Rob
^ 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