* [PATCH v2 2/4] vesnin: add secondary SPI flash chip
From: Ivan Mikhaylov @ 2019-08-26 10:46 UTC (permalink / raw)
To: Guenter Roeck, Wim Van Sebroeck
Cc: Mark Rutland, devicetree, linux-watchdog, linux-aspeed,
Andrew Jeffery, openbmc, Alexander Amelkin, linux-kernel,
Rob Herring, Joel Stanley, Ivan Mikhaylov, linux-arm-kernel
In-Reply-To: <20190826104636.19324-1-i.mikhaylov@yadro.com>
Adds secondary SPI flash chip into dts for vesnin.
Signed-off-by: Ivan Mikhaylov <i.mikhaylov@yadro.com>
---
arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts b/arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts
index 2ee26c86a32e..db4cc3df61ce 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts
@@ -81,6 +81,14 @@
label = "bmc";
#include "openbmc-flash-layout.dtsi"
};
+
+ flash@1 {
+ status = "okay";
+ reg = < 1 >;
+ compatible = "jedec,spi-nor";
+ m25p,fast-read;
+ label = "alt";
+ };
};
&spi {
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 3/4] watchdog/aspeed: add support for dual boot
From: Ivan Mikhaylov @ 2019-08-26 10:46 UTC (permalink / raw)
To: Guenter Roeck, Wim Van Sebroeck
Cc: Mark Rutland, devicetree, linux-watchdog, linux-aspeed,
Andrew Jeffery, openbmc, Alexander Amelkin, linux-kernel,
Rob Herring, Joel Stanley, Ivan Mikhaylov, linux-arm-kernel
In-Reply-To: <20190826104636.19324-1-i.mikhaylov@yadro.com>
Set WDT_CLEAR_TIMEOUT_AND_BOOT_CODE_SELECTION into WDT_CLEAR_TIMEOUT_STATUS
to clear out boot code source and re-enable access to the primary SPI flash
chip while booted via wdt2 from the alternate chip.
AST2400 datasheet says:
"In the 2nd flash booting mode, all the address mapping to CS0# would be
re-directed to CS1#. And CS0# is not accessable under this mode. To access
CS0#, firmware should clear the 2nd boot mode register in the WDT2 status
register WDT30.bit[1]."
Signed-off-by: Ivan Mikhaylov <i.mikhaylov@yadro.com>
---
drivers/watchdog/aspeed_wdt.c | 62 ++++++++++++++++++++++++++++++++++-
1 file changed, 61 insertions(+), 1 deletion(-)
diff --git a/drivers/watchdog/aspeed_wdt.c b/drivers/watchdog/aspeed_wdt.c
index cc71861e033a..bbc42847c0e3 100644
--- a/drivers/watchdog/aspeed_wdt.c
+++ b/drivers/watchdog/aspeed_wdt.c
@@ -53,6 +53,8 @@ MODULE_DEVICE_TABLE(of, aspeed_wdt_of_table);
#define WDT_CTRL_ENABLE BIT(0)
#define WDT_TIMEOUT_STATUS 0x10
#define WDT_TIMEOUT_STATUS_BOOT_SECONDARY BIT(1)
+#define WDT_CLEAR_TIMEOUT_STATUS 0x14
+#define WDT_CLEAR_TIMEOUT_AND_BOOT_CODE_SELECTION BIT(0)
/*
* WDT_RESET_WIDTH controls the characteristics of the external pulse (if
@@ -165,6 +167,57 @@ static int aspeed_wdt_restart(struct watchdog_device *wdd,
return 0;
}
+/* access_cs0 shows if cs0 is accessible, hence the reverted bit */
+static ssize_t access_cs0_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct aspeed_wdt *wdt = dev_get_drvdata(dev);
+ uint32_t status = readl(wdt->base + WDT_TIMEOUT_STATUS);
+
+ return sprintf(buf, "%u\n",
+ !(status & WDT_TIMEOUT_STATUS_BOOT_SECONDARY));
+}
+
+static ssize_t access_cs0_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t size)
+{
+ struct aspeed_wdt *wdt = dev_get_drvdata(dev);
+ unsigned long val;
+
+ if (kstrtoul(buf, 10, &val))
+ return -EINVAL;
+
+ if (val)
+ writel(WDT_CLEAR_TIMEOUT_AND_BOOT_CODE_SELECTION,
+ wdt->base + WDT_CLEAR_TIMEOUT_STATUS);
+
+ return size;
+}
+
+/*
+ * At alternate side the 'access_cs0' sysfs node provides:
+ * ast2400: a way to get access to the primary SPI flash chip at CS0
+ * after booting from the alternate chip at CS1.
+ * ast2500: a way to restore the normal address mapping from
+ * (CS0->CS1, CS1->CS0) to (CS0->CS0, CS1->CS1).
+ *
+ * Clearing the boot code selection and timeout counter also resets to the
+ * initial state the chip select line mapping. When the SoC is in normal
+ * mapping state (i.e. booted from CS0), clearing those bits does nothing for
+ * both versions of the SoC. For alternate boot mode (booted from CS1 due to
+ * wdt2 expiration) the behavior differs as described above.
+ *
+ * This option can be used with wdt2 (watchdog1) only.
+ */
+static DEVICE_ATTR_RW(access_cs0);
+
+static struct attribute *bswitch_attrs[] = {
+ &dev_attr_access_cs0.attr,
+ NULL
+};
+ATTRIBUTE_GROUPS(bswitch);
+
static const struct watchdog_ops aspeed_wdt_ops = {
.start = aspeed_wdt_start,
.stop = aspeed_wdt_stop,
@@ -306,9 +359,16 @@ static int aspeed_wdt_probe(struct platform_device *pdev)
}
status = readl(wdt->base + WDT_TIMEOUT_STATUS);
- if (status & WDT_TIMEOUT_STATUS_BOOT_SECONDARY)
+ if (status & WDT_TIMEOUT_STATUS_BOOT_SECONDARY) {
wdt->wdd.bootstatus = WDIOF_CARDRESET;
+ if (of_device_is_compatible(np, "aspeed,ast2400-wdt") ||
+ of_device_is_compatible(np, "aspeed,ast2500-wdt"))
+ wdt->wdd.groups = bswitch_groups;
+ }
+
+ dev_set_drvdata(dev, wdt);
+
return devm_watchdog_register_device(dev, &wdt->wdd);
}
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 4/4] dt-bindings/watchdog: Add access_cs0 option for alt-boot
From: Ivan Mikhaylov @ 2019-08-26 10:46 UTC (permalink / raw)
To: Guenter Roeck, Wim Van Sebroeck
Cc: Mark Rutland, devicetree, linux-watchdog, linux-aspeed,
Andrew Jeffery, openbmc, Alexander Amelkin, linux-kernel,
Rob Herring, Joel Stanley, Ivan Mikhaylov, linux-arm-kernel
In-Reply-To: <20190826104636.19324-1-i.mikhaylov@yadro.com>
The option for the ast2400/2500 to get access to CS0 at runtime.
Signed-off-by: Ivan Mikhaylov <i.mikhaylov@yadro.com>
---
Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt b/Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt
index c5077a1f5cb3..023a9b578df6 100644
--- a/Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt
@@ -34,6 +34,13 @@ Optional properties:
engine is responsible for this.
- aspeed,alt-boot: If property is present then boot from alternate block.
+ At alternate side 'access_cs0' sysfs file provides:
+ ast2400: a way to get access to the primary SPI flash
+ chip at CS0 after booting from the alternate
+ chip at CS1.
+ ast2500: a way to restore the normal address mapping from
+ (CS0->CS1, CS1->CS0) to (CS0->CS0, CS1->CS1).
+
- aspeed,external-signal: If property is present then signal is sent to
external reset counter (only WDT1 and WDT2). If not
specified no external signal is sent.
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2 2/2] ARM: exynos: Enable support for ARM architected timers
From: Marc Zyngier @ 2019-08-26 10:49 UTC (permalink / raw)
To: Marek Szyprowski
Cc: Chanwoo Choi, linux-samsung-soc, Krzysztof Kozlowski,
linux-arm-kernel, Bartlomiej Zolnierkiewicz
In-Reply-To: <20190826103142.3477-4-m.szyprowski@samsung.com>
On 2019-08-26 11:31, Marek Szyprowski wrote:
> ARM architected timer can be used together with Exynos MultiCore
> Timer
> driver, so enable support for it. Support for ARM architected timers
> is
> essential for enabling proper KVM support.
How can you say that this is to "enable KVM support", while in the
previous
patch, you set "arm,cpu-registers-not-fw-configured" which implies that
you're
booting in secure mode with the timer's CP15 registers left to
undefined values?
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
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 v2 10/11] arm64: edit zone_dma_bits to fine tune dma-direct min mask
From: Nicolas Saenz Julienne @ 2019-08-26 11:08 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-arch, devicetree, linux-rpi-kernel, f.fainelli, will, eric,
marc.zyngier, catalin.marinas, frowand.list, linux-kernel,
linux-mm, iommu, robh+dt, wahrenst, mbrugger, linux-riscv,
m.szyprowski, Robin Murphy, akpm, linux-arm-kernel, phill
In-Reply-To: <20190826070633.GB11331@lst.de>
[-- Attachment #1.1: Type: text/plain, Size: 821 bytes --]
On Mon, 2019-08-26 at 09:06 +0200, Christoph Hellwig wrote:
> On Tue, Aug 20, 2019 at 04:58:18PM +0200, Nicolas Saenz Julienne wrote:
> > - if (IS_ENABLED(CONFIG_ZONE_DMA))
> > + if (IS_ENABLED(CONFIG_ZONE_DMA)) {
> > arm64_dma_phys_limit = max_zone_dma_phys();
> > + zone_dma_bits = ilog2((arm64_dma_phys_limit - 1) &
> > GENMASK_ULL(31, 0)) + 1;
>
Hi Christoph,
thanks for the rewiews.
> This adds a way too long line.
I know, I couldn't find a way to split the operation without making it even
harder to read. I'll find a solution.
> I also find the use of GENMASK_ULL
> horribly obsfucating, but I know that opinion is't shared by everyone.
Don't have any preference so I'll happily change it. Any suggestions? Using the
explicit 0xffffffffULL seems hard to read, how about SZ_4GB - 1?
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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 5/6] dt-bindings: pinctrl: k3: Introduce pinmux definitions for J721E
From: Rob Herring @ 2019-08-26 11:25 UTC (permalink / raw)
To: Lokesh Vutla
Cc: Nishanth Menon, Device Tree Mailing List, Keerthy, Linus Walleij,
Tero Kristo, open list:GPIO SUBSYSTEM, Linux ARM Mailing List
In-Reply-To: <da0286cb-8e4c-e12c-240c-b6de72bdd0ee@ti.com>
On Mon, Aug 26, 2019 at 5:27 AM Lokesh Vutla <lokeshvutla@ti.com> wrote:
>
> Hi Rob,
>
> On 22/08/19 2:32 AM, Rob Herring wrote:
> > On Fri, Aug 09, 2019 at 01:59:46PM +0530, Lokesh Vutla wrote:
> >> Add pinctrl macros for J721E SoC. These macro definitions are
> >> similar to that of AM6, but adding new definitions to avoid
> >> any naming confusions in the soc dts files.
> >>
> >> Acked-by: Nishanth Menon <nm@ti.com>
> >> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> >> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
> >> ---
> >> include/dt-bindings/pinctrl/k3.h | 3 +++
> >> 1 file changed, 3 insertions(+)
> >>
> >> diff --git a/include/dt-bindings/pinctrl/k3.h b/include/dt-bindings/pinctrl/k3.h
> >> index 45e11b6170ca..499de6216581 100644
> >> --- a/include/dt-bindings/pinctrl/k3.h
> >> +++ b/include/dt-bindings/pinctrl/k3.h
> >> @@ -32,4 +32,7 @@
> >> #define AM65X_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | (muxmode))
> >> #define AM65X_WKUP_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | (muxmode))
> >>
> >> +#define J721E_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | (muxmode))
> >> +#define J721E_WKUP_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | (muxmode))
> >
> > checkpatch reports a parentheses error: (((pa) & 0x1fff) ((val) | (muxmode)))
>
> This was left intentionally as this macro is giving out two entries in DT like
> below:
>
> pinctrl-single,pins = <
> J721E_IOPAD(0x0, PIN_INPUT, 7)
> >;
>
> comes out as
>
> pinctrl-single,pins = <
> 0x0 (PIN_INPUT | 7)
> >;
>
> If parenthesis are added for the whole macro, the following build error occurs:
> DTC arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dtb
> Error: arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts:41.24-25 syntax error
> FATAL ERROR: Unable to parse input tree
Okay, NM.
Acked-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 09/11] dma-direct: turn ARCH_ZONE_DMA_BITS into a variable
From: Michael Ellerman @ 2019-08-26 11:33 UTC (permalink / raw)
To: Nicolas Saenz Julienne, catalin.marinas, hch, wahrenst,
marc.zyngier, robh+dt, Robin Murphy, linux-arm-kernel, devicetree,
linux-arch, iommu, linux-mm, linux-riscv, Marek Szyprowski
Cc: linux-s390, f.fainelli, Vasily Gorbik, Christian Borntraeger,
frowand.list, linuxppc-dev, Heiko Carstens, linux-kernel, eric,
mbrugger, Paul Mackerras, linux-rpi-kernel,
Benjamin Herrenschmidt, akpm, will, nsaenzjulienne
In-Reply-To: <20190820145821.27214-10-nsaenzjulienne@suse.de>
Nicolas Saenz Julienne <nsaenzjulienne@suse.de> writes:
> diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
> index 0d52f57fca04..73668a21ae78 100644
> --- a/arch/powerpc/include/asm/page.h
> +++ b/arch/powerpc/include/asm/page.h
> @@ -319,13 +319,4 @@ struct vm_area_struct;
> #endif /* __ASSEMBLY__ */
> #include <asm/slice.h>
>
> -/*
> - * Allow 30-bit DMA for very limited Broadcom wifi chips on many powerbooks.
This comment got lost.
> diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
> index 9191a66b3bc5..2a69f87585df 100644
> --- a/arch/powerpc/mm/mem.c
> +++ b/arch/powerpc/mm/mem.c
> @@ -237,9 +238,14 @@ void __init paging_init(void)
> printk(KERN_DEBUG "Memory hole size: %ldMB\n",
> (long int)((top_of_ram - total_ram) >> 20));
>
> + if (IS_ENABLED(CONFIG_PPC32))
Can you please propagate it here?
> + zone_dma_bits = 30;
> + else
> + zone_dma_bits = 31;
> +
cheers
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC 1/9] dt-bindings: arm: samsung: Convert Samsung board/soc bindings to json-schema
From: Rob Herring @ 2019-08-26 11:37 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Mark Rutland, Alessandro Zummo, Alexandre Belloni,
Lars-Peter Clausen, Arnd Bergmann, devicetree,
open list:IIO SUBSYSTEM AND DRIVERS, Marek Szyprowski,
linux-kernel@vger.kernel.org, Tomasz Figa, linux-samsung-soc,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Peter Meerwald-Stadler, Hartmut Knaack, Olof Johansson,
open list:REAL TIME CLOCK (RTC) SUBSYSTEM, notify,
Jonathan Cameron, Paweł Chmiel
In-Reply-To: <20190823145356.6341-1-krzk@kernel.org>
On Fri, Aug 23, 2019 at 9:54 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> Convert Samsung S5P and Exynos SoC bindings to DT schema format using
> json-schema. This is purely conversion of already documented bindings
> so it does not cover all of DTS in the Linux kernel (few S5P/Exynos and
> all S3C are missing).
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
>
> ---
>
> If the schema looks sensible, I will continue on converting other
> SoC and driver bindings and later adding missing schemas (S3C
> SoCs).
Looks pretty good.
> ---
> .../bindings/arm/samsung/samsung-boards.txt | 83 --------
> .../bindings/arm/samsung/samsung-boards.yaml | 188 ++++++++++++++++++
> 2 files changed, 188 insertions(+), 83 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
> create mode 100644 Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml
> diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml
> new file mode 100644
> index 000000000000..e963fd70c436
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml
> @@ -0,0 +1,188 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/samsung/samsung-boards.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Samsung Exynos and S5P SoC based boards
> +
> +maintainers:
> + - Krzysztof Kozlowski <krzk@kernel.org>
> +
> +properties:
> + $nodename:
> + const: '/'
> + compatible:
> + oneOf:
> + - description: S5PV210 based Aries boards
> + items:
> + - enum:
> + - samsung,fascinate4g # Samsung Galaxy S Fascinate 4G (SGH-T959P)
> + - samsung,galaxys # Samsung Galaxy S (i9000)
> + - const: samsung,aries
> + - const: samsung,s5pv210
> +
> + - description: Exynos3250 based boards
> + items:
> + - enum:
> + - samsung,monk # Samsung Simband
> + - samsung,rinato # Samsung Gear2
> + - const: samsung,exynos3250
> + - const: samsung,exynos3
> +
> + - description: Samsung ARTIK5 boards
> + items:
> + - enum:
> + - samsung,artik5-eval # Samsung ARTIK5 eval board
> + - const: samsung,artik5 # Samsung ARTIK5 module
> + - const: samsung,exynos3250
> + - const: samsung,exynos3
> +
> + - description: Exynos4210 based boards
> + items:
> + - enum:
> + - insignal,origen # Insignal Origen
> + - samsung,smdkv310 # Samsung SMDKV310 eval
> + - samsung,trats # Samsung Tizen Reference
> + - samsung,universal_c210 # Samsung C210
> + - const: samsung,exynos4210
> + - const: samsung,exynos4
> +
> + - description: Exynos4412 based boards
> + items:
> + - enum:
> + - friendlyarm,tiny4412 # FriendlyARM TINY4412
> + - hardkernel,odroid-u3 # Hardkernel Odroid U3
> + - hardkernel,odroid-x # Hardkernel Odroid X
> + - hardkernel,odroid-x2 # Hardkernel Odroid X2
> + - insignal,origen4412 # Insignal Origen
> + - samsung,smdk4412 # Samsung SMDK4412 eval
> + - topeet,itop4412-elite # TOPEET Elite base
> + - const: samsung,exynos4412
> + - const: samsung,exynos4
> +
> + - description: Samsung Midas family boards
> + items:
> + - enum:
> + - samsung,i9300 # Samsung GT-I9300
> + - samsung,i9305 # Samsung GT-I9305
> + - samsung,n710x # Samsung GT-N7100/GT-N7105
> + - samsung,trats2 # Samsung Tizen Reference
> + - const: samsung,midas
> + - const: samsung,exynos4412
> + - const: samsung,exynos4
> +
> + - description: Exynos5250 based boards
> + items:
> + - enum:
> + - google,snow-rev5 # Google Snow Rev 5+
> + - google,spring # Google Spring
> + - insignal,arndale # Insignal Arndale
> + - samsung,smdk5250 # Samsung SMDK5250 eval
> + - const: samsung,exynos5250
> + - const: samsung,exynos5
> +
> + - description: Google Snow Boards (Rev 4+)
> + items:
> + - enum:
> + - google,snow-rev4
const here as I wouldn't expect this list to grow.
> + - const: google,snow
> + - const: samsung,exynos5250
> + - const: samsung,exynos5
> +
> + - description: Exynos5260 based boards
> + items:
> + - enum:
> + - samsung,xyref5260 # Samsung Xyref5260 eval
> + - const: samsung,exynos5260
> + - const: samsung,exynos5
> +
> + - description: Exynos5410 based boards
> + items:
> + - enum:
> + - hardkernel,odroid-xu # Hardkernel Odroid XU
> + - samsung,smdk5410 # Samsung SMDK5410 eval
> + - const: samsung,exynos5410
> + - const: samsung,exynos5
> +
> + - description: Exynos5420 based boards
> + items:
> + - enum:
> + - insignal,arndale-octa # Insignal Arndale Octa
> + - samsung,smdk5420 # Samsung SMDK5420 eval
> + - const: samsung,exynos5420
> + - const: samsung,exynos5
> +
> + - description: Google Peach Pit Boards (Rev 6+)
> + items:
> + - enum:
> + - google,pit-rev16
const
> + - const: google,pit-rev15
> + - const: google,pit-rev14
> + - const: google,pit-rev13
> + - const: google,pit-rev12
> + - const: google,pit-rev11
> + - const: google,pit-rev10
> + - const: google,pit-rev9
> + - const: google,pit-rev8
> + - const: google,pit-rev7
> + - const: google,pit-rev6
> + - const: google,pit
> + - const: google,peach
> + - const: samsung,exynos5420
> + - const: samsung,exynos5
> +
> + - description: Exynos5800 based boards
> + items:
> + - enum:
> + - hardkernel,odroid-xu3 # Hardkernel Odroid XU3
> + - hardkernel,odroid-xu3-lite # Hardkernel Odroid XU3 Lite
> + - hardkernel,odroid-xu4 # Hardkernel Odroid XU4
> + - hardkernel,odroid-hc1 # Hardkernel Odroid HC1
> + - const: samsung,exynos5800
> + - const: samsung,exynos5
> +
> + - description: Google Peach Pi Boards (Rev 10+)
> + items:
> + - enum:
> + - google,pi-rev16
> + - const: google,pi-rev15
> + - const: google,pi-rev14
> + - const: google,pi-rev13
> + - const: google,pi-rev12
> + - const: google,pi-rev11
> + - const: google,pi-rev10
> + - const: google,pi
> + - const: google,peach
> + - const: samsung,exynos5800
> + - const: samsung,exynos5
> +
> + - description: Exynos5433 based boards
> + items:
> + - enum:
> + - samsung,tm2 # Samsung TM2
> + - samsung,tm2e # Samsung TM2E
> + - const: samsung,exynos5433
> +
> + firmware:
This should be moved to its own file.
> + type: object
> + description:
> + node specifying presence and type of secure firmware
> + properties:
> + compatible:
> + enum:
> + - samsung,secure-firmware
> + reg:
> + description:
> + address of non-secure SYSRAM used for communication with firmware
> + maxItems: 1
> +
> +required:
> + - compatible
> +
> +examples:
> + - |
> + firmware@203f000 {
> + compatible = "samsung,secure-firmware";
> + reg = <0x0203F000 0x1000>;
> + };
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V5 1/3] mmc: mmci: add hardware busy timeout feature
From: Ulf Hansson @ 2019-08-26 11:39 UTC (permalink / raw)
To: Ludovic Barre
Cc: DTML, Alexandre Torgue, linux-mmc@vger.kernel.org,
Linux Kernel Mailing List, Rob Herring, Srinivas Kandagatla,
Maxime Coquelin, linux-stm32, Linux ARM
In-Reply-To: <20190813095951.26275-2-ludovic.Barre@st.com>
On Tue, 13 Aug 2019 at 12:00, Ludovic Barre <ludovic.Barre@st.com> wrote:
>
> From: Ludovic Barre <ludovic.barre@st.com>
>
> In some variants, the data timer starts and decrements
> when the DPSM enters in Wait_R or Busy state
> (while data transfer or MMC_RSP_BUSY), and generates a
> data timeout error if the counter reach 0.
I don't quite follow here, sorry. Can you please try to elaborate on
the use case(s) more exactly?
For example, what happens when a data transfer has just finished (for
example when MCI_DATAEND has been received) and we are going to send a
CMD12 to stop it? In this case the CMD12 has the MMC_RSP_BUSY flag
set.
Another example is the CMD5, which has no data with it.
>
> -Define max_busy_timeout (in ms) according to clock.
> -Set data timer register if the command has rsp_busy flag.
> If busy_timeout is not defined by framework, the busy
> length after Data Burst is defined as 1 second
> (refer: 4.6.2.2 Write of sd specification part1 v6-0).
One second is not sufficient for all operations, like ERASE for
example. However, I understand that you want to pick some value, as a
safety. I guess that's fine.
I am thinking that if the command has the MMC_RSP_BUSY flag set, the
core should really provide a busy timeout for it. That said, maybe the
host driver should splat a WARN in case there is not busy timeout
specified.
> -Add MCI_DATATIMEOUT error management in mmci_cmd_irq.
>
> Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
> ---
> drivers/mmc/host/mmci.c | 37 ++++++++++++++++++++++++++++++++-----
> drivers/mmc/host/mmci.h | 3 +++
> 2 files changed, 35 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
> index c37e70dbe250..c50586540765 100644
> --- a/drivers/mmc/host/mmci.c
> +++ b/drivers/mmc/host/mmci.c
> @@ -1075,6 +1075,7 @@ static void
> mmci_start_command(struct mmci_host *host, struct mmc_command *cmd, u32 c)
> {
> void __iomem *base = host->base;
> + unsigned long long clks = 0;
>
> dev_dbg(mmc_dev(host->mmc), "op %02x arg %08x flags %08x\n",
> cmd->opcode, cmd->arg, cmd->flags);
> @@ -1097,6 +1098,19 @@ mmci_start_command(struct mmci_host *host, struct mmc_command *cmd, u32 c)
> else
> c |= host->variant->cmdreg_srsp;
> }
> +
> + if (host->variant->busy_timeout && !host->mrq->data) {
Suppose this is a CMD12 command, having the MMC_RSP_BUSY flag set. The
command would then be sent to stop the transmission and then
host->mrq->data would also be set.
If I recall earlier what you stated about the new sdmmc variant, the
CMD12 is needed to exit the DPSM. Hence don't you need to re-program a
new value for the MMCIDATATIMER register for this scenario?
> + if (cmd->flags & MMC_RSP_BUSY) {
> + if (!cmd->busy_timeout)
> + cmd->busy_timeout = 1000;
> +
> + clks = (unsigned long long)cmd->busy_timeout;
> + clks *= host->cclk;
Any problems with putting the above on one line?
> + do_div(clks, MSEC_PER_SEC);
> + }
> + writel_relaxed(clks, host->base + MMCIDATATIMER);
This is writing zero to MMCIDATATIMER in case the MMC_RSP_BUSY isn't
set, is that on purpose?
> + }
> +
> if (/*interrupt*/0)
> c |= MCI_CPSM_INTERRUPT;
>
> @@ -1203,6 +1217,7 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command *cmd,
> {
> void __iomem *base = host->base;
> bool sbc, busy_resp;
> + u32 err_msk;
>
> if (!cmd)
> return;
> @@ -1215,8 +1230,12 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command *cmd,
> * handling. Note that we tag on any latent IRQs postponed
> * due to waiting for busy status.
> */
> - if (!((status|host->busy_status) &
> - (MCI_CMDCRCFAIL|MCI_CMDTIMEOUT|MCI_CMDSENT|MCI_CMDRESPEND)))
> + err_msk = MCI_CMDCRCFAIL | MCI_CMDTIMEOUT;
You might as well move the initial assignment of err_msk to the its
declaration above.
> + if (host->variant->busy_timeout && busy_resp)
> + err_msk |= MCI_DATATIMEOUT;
> +
> + if (!((status | host->busy_status) &
> + (err_msk | MCI_CMDSENT | MCI_CMDRESPEND)))
> return;
>
> /* Handle busy detection on DAT0 if the variant supports it. */
> @@ -1235,8 +1254,7 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command *cmd,
> * while, to allow it to be set, but tests indicates that it
> * isn't needed.
> */
> - if (!host->busy_status &&
> - !(status & (MCI_CMDCRCFAIL|MCI_CMDTIMEOUT)) &&
> + if (!host->busy_status && !(status & err_msk) &&
> (readl(base + MMCISTATUS) & host->variant->busy_detect_flag)) {
>
> writel(readl(base + MMCIMASK0) |
> @@ -1290,6 +1308,9 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command *cmd,
> cmd->error = -ETIMEDOUT;
> } else if (status & MCI_CMDCRCFAIL && cmd->flags & MMC_RSP_CRC) {
> cmd->error = -EILSEQ;
> + } else if (host->variant->busy_timeout && busy_resp &&
> + status & MCI_DATATIMEOUT) {
> + cmd->error = -ETIMEDOUT;
> } else {
> cmd->resp[0] = readl(base + MMCIRESPONSE0);
> cmd->resp[1] = readl(base + MMCIRESPONSE1);
> @@ -1948,6 +1969,8 @@ static int mmci_probe(struct amba_device *dev,
> * Enable busy detection.
> */
> if (variant->busy_detect) {
> + u32 max_busy_timeout = 0;
> +
> mmci_ops.card_busy = mmci_card_busy;
> /*
> * Not all variants have a flag to enable busy detection
> @@ -1957,7 +1980,11 @@ static int mmci_probe(struct amba_device *dev,
> mmci_write_datactrlreg(host,
> host->variant->busy_dpsm_flag);
> mmc->caps |= MMC_CAP_WAIT_WHILE_BUSY;
> - mmc->max_busy_timeout = 0;
> +
> + if (variant->busy_timeout)
> + max_busy_timeout = ~0UL / (mmc->f_max / MSEC_PER_SEC);
It looks like the max busy timeout is depending on the current picked
clock rate, right?
In such case, perhaps it's better to update mmc->max_busy_timeout as
part of the ->set_ios() callback, as it's from there the clock rate
gets updated. Or what do you think?
> +
> + mmc->max_busy_timeout = max_busy_timeout;
> }
>
> /* Prepare a CMD12 - needed to clear the DPSM on some variants. */
> diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
> index 833236ecb31e..d8b7f6774e8f 100644
> --- a/drivers/mmc/host/mmci.h
> +++ b/drivers/mmc/host/mmci.h
> @@ -287,6 +287,8 @@ struct mmci_host;
> * @signal_direction: input/out direction of bus signals can be indicated
> * @pwrreg_clkgate: MMCIPOWER register must be used to gate the clock
> * @busy_detect: true if the variant supports busy detection on DAT0.
> + * @busy_timeout: true if the variant starts data timer when the DPSM
> + * enter in Wait_R or Busy state.
> * @busy_dpsm_flag: bitmask enabling busy detection in the DPSM
> * @busy_detect_flag: bitmask identifying the bit in the MMCISTATUS register
> * indicating that the card is busy
> @@ -333,6 +335,7 @@ struct variant_data {
> u8 signal_direction:1;
> u8 pwrreg_clkgate:1;
> u8 busy_detect:1;
> + u8 busy_timeout:1;
> u32 busy_dpsm_flag;
> u32 busy_detect_flag;
> u32 busy_detect_mask;
> --
> 2.17.1
>
Kind regards
Uffe
_______________________________________________
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 v3 00/19] Enhance CP110 COMPHY support
From: Kishon Vijay Abraham I @ 2019-08-26 11:51 UTC (permalink / raw)
To: Miquel Raynal
Cc: Andrew Lunn, Jason Cooper, devicetree, Antoine Tenart,
Grzegorz Jaszczyk, Gregory Clement, Russell King,
Maxime Chevallier, Nadav Haklai, Matt Pelland, Rob Herring,
Thomas Petazzoni, linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <20190824135414.5c490337@xps13>
Hi,
On 24/08/19 5:24 PM, Miquel Raynal wrote:
> Hi Kishon,
>
> + Matt Pelland
>
> Kishon Vijay Abraham I <kishon@ti.com> wrote on Fri, 23 Aug 2019
> 08:46:14 +0530:
>
>> On 31/07/19 5:51 PM, Miquel Raynal wrote:
>>> Armada CP110 have a COMPHY IP which supports configuring SERDES lanes
>>> in one mode, either:
>>> - SATA
>>> - USB3 host
>>> - PCIe (several width)
>>> - Ethernet (several modes)
>>>
>>> As of today, only a few Ethernet modes are supported and the code is
>>> embedded in the Linux driver. A more complete COMPHY driver that can
>>> be used by both Linux and U-Boot is embedded in the firmware and can
>>> be run through SMC calls.
>>>
>>> First the current COMPHY driver is updated to use SMC calls but
>>> fallbacks to the already existing functions if the firmware is not
>>> up-to-date. Then, more Ethernet modes are added (through SMC calls
>>> only). SATA, USB3H and PCIe modes are also supported one by one.
>>>
>>> There is one subtle difference with the PCIe functions: we must tell
>>> the firmware the number of lanes to configure (x1, x2 or x4). This
>>> parameter depends on the number of entries in the 'phys' property
>>> describing the PCIe PHY. We use the "submode" parameter of the generic
>>> PHY API to carry this value. The Armada-8k PCIe driver has been
>>> updated to follow this idea and this change has been merged already:
>>> http://patchwork.ozlabs.org/patch/1072763/
>>
>> Some of the patches are not applying cleanly. Care to resend the series after
>> rebasing to phy -next?
>
> Besides two conflicts that I can fix very easily about missing
> of_node_put() calls, you just merged in phy-next this patch:
>
> phy: marvell: phy-mvebu-cp110-comphy: implement RXAUI support
>
> Which totally conflicts with my series while I also add RXAUI support
> in patch 5. Please note that even the third version of my series
> was contributed before this patch.
>
> There is one difference to note though: in the patch from Matt Peland,
> RXAUI support is embedded in the driver while I do SMC calls.
>
> Anyway, would it be possible to change the order of application if
> you want both methods in the driver because it will be much easier
> to add Matt's patch on top of my series than the opposite. I can
> even do it myself if you wish.
I've resolved this. Can you review in phy -next if the changes looks okay?
Thanks
Kishon
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC 5/9] dt-bindings: arm: samsung: Convert Exynos PMU bindings to json-schema
From: Rob Herring @ 2019-08-26 11:54 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Mark Rutland, Alessandro Zummo, Alexandre Belloni,
Lars-Peter Clausen, Arnd Bergmann, devicetree,
open list:IIO SUBSYSTEM AND DRIVERS, Marek Szyprowski,
linux-kernel@vger.kernel.org, Tomasz Figa, linux-samsung-soc,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Peter Meerwald-Stadler, Hartmut Knaack, Olof Johansson,
open list:REAL TIME CLOCK (RTC) SUBSYSTEM, notify,
Jonathan Cameron, Paweł Chmiel
In-Reply-To: <20190823145356.6341-5-krzk@kernel.org>
On Fri, Aug 23, 2019 at 9:54 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> Convert Samsung Exynos Power Management Unit (PMU) bindings to DT schema
> format using json-schema.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> ---
> .../devicetree/bindings/arm/samsung/pmu.txt | 72 --------------
> .../devicetree/bindings/arm/samsung/pmu.yaml | 93 +++++++++++++++++++
> 2 files changed, 93 insertions(+), 72 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/arm/samsung/pmu.txt
> create mode 100644 Documentation/devicetree/bindings/arm/samsung/pmu.yaml
> diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.yaml b/Documentation/devicetree/bindings/arm/samsung/pmu.yaml
> new file mode 100644
> index 000000000000..818c6f3488ef
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/samsung/pmu.yaml
> @@ -0,0 +1,93 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/samsung/pmu.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Samsung Exynos SoC series Power Management Unit (PMU)
> +
> +maintainers:
> + - Krzysztof Kozlowski <krzk@kernel.org>
> +
> +properties:
> + compatible:
> + items:
> + - enum:
> + - samsung,exynos3250-pmu
> + - samsung,exynos4210-pmu
> + - samsung,exynos4412-pmu
> + - samsung,exynos5250-pmu
> + - samsung,exynos5260-pmu
> + - samsung,exynos5410-pmu
> + - samsung,exynos5420-pmu
> + - samsung,exynos5433-pmu
> + - samsung,exynos7-pmu
> + - const: syscon
> +
> + reg:
> + maxItems: 1
> +
> + '#clock-cells':
> + const: 1
> +
> + clock-names:
> + description:
> + list of clock names for particular CLKOUT mux inputs
> + # TODO: what is the maximum number of elements (mux inputs)?
> + minItems: 1
> + maxItems: 32
> + items:
> + - enum:
This isn't correct as you are only defining possible names for the
first item. Drop the '-' (making items a schema instead of a list) and
then it applies to all. However, doing that will cause a meta-schema
error which I need to fix to allow. Or if there's a small set of
possibilities of number of inputs, you can list them under a 'oneOf'
list.
> + - clkout0
> + - clkout1
> + - clkout2
> + - clkout3
> + - clkout4
> + - clkout5
> + - clkout6
> + - clkout7
> + - clkout8
> + - clkout9
> + - clkout10
> + - clkout11
> + - clkout12
> + - clkout13
> + - clkout14
> + - clkout15
> + - clkout16
> +
> + clocks:
> + minItems: 1
> + maxItems: 32
> +
> + interrupt-controller:
> + description:
> + Some PMUs are capable of behaving as an interrupt controller (mostly
> + to wake up a suspended PMU).
> +
> + '#interrupt-cells':
> + # TODO: must be identical to the that of the parent interrupt controller.
There's not really a way to express that. Just state that in the
description if you want.
> + const: 3
> +
> + # TODO: Mark interrupt-controller and #interrupt-cells as required, if one is present
No need, the core schemas handle that dependency. It would be good to
define for which compatibles the properties are required. You can do
this with if/then schema. There's several examples in the tree.
> + # TODO: nodes defining the restart and poweroff syscon children
> +
> +required:
> + - compatible
> + - reg
> + - '#clock-cells'
> + - clock-names
> + - clocks
> +
> +examples:
> + - |
> + pmu_system_controller: system-controller@10040000 {
> + compatible = "samsung,exynos5250-pmu", "syscon";
> + reg = <0x10040000 0x5000>;
> + interrupt-controller;
> + #interrupt-cells = <3>;
> + interrupt-parent = <&gic>;
> + #clock-cells = <1>;
> + clock-names = "clkout16";
> + clocks = <&clock 0>; // CLK_FIN_PLL
> + };
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH V3 3/4] dt-bindings: mt8183: Add sensor interface dt-bindings
From: Sakari Ailus @ 2019-08-26 11:52 UTC (permalink / raw)
To: Louis Kuo
Cc: devicetree, Sean.Cheng, laurent.pinchart+renesas, Rynn.Wu,
christie.yu, srv_heupstream, holmes.chiou, Jerry-ch.Chen, tfiga,
keiichiw, jungo.lin, sj.huang, yuzhao, hans.verkuil, zwisler,
frederic.chen, matthias.bgg, linux-mediatek, mchehab,
linux-arm-kernel, linux-media
In-Reply-To: <1559815233-24796-4-git-send-email-louis.kuo@mediatek.com>
Hi Louis,
On Thu, Jun 06, 2019 at 06:00:32PM +0800, Louis Kuo wrote:
> This patch adds the DT binding documentation for the sensor interface
> module in Mediatek SoCs.
>
> Signed-off-by: Louis Kuo <louis.kuo@mediatek.com>
> ---
> .../devicetree/bindings/media/mediatek-seninf.txt | 31 ++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/mediatek-seninf.txt
>
> diff --git a/Documentation/devicetree/bindings/media/mediatek-seninf.txt b/Documentation/devicetree/bindings/media/mediatek-seninf.txt
> new file mode 100644
> index 0000000..979063a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/mediatek-seninf.txt
> @@ -0,0 +1,31 @@
> +* Mediatek seninf MIPI-CSI2 host driver
Note that DT bindings document the hardware, not the driver implementation.
> +
> +Seninf MIPI-CSI2 host driver is a HW camera interface controller. It support a widely adopted,
Same here; driver apparently refers to software.
Please wrap before or at 80 characters per line.
> +simple, high-speed protocol primarily intended for point-to-point image and video
> +transmission between cameras and host devices.
Could you elaborate the properties of the hardware in a bit more detail,
such as how many ports there are and how many lanes they can support? See
e.g. Documentation/devicetree/bindings/media/ti,omap3isp.txt .
Please also refer to video-interfaces.txt and document the port nodes and
the relevant properties in the endpoint nodes, as in the binding example I
referred to.
> +
> +Required properties:
> + - compatible: "mediatek,mt8183-seninf"
> + - reg: Must contain an entry for each entry in reg-names.
> + - reg-names: Must include the following entries:
> + "base_reg": seninf registers base
> + "rx_reg": Rx analog registers base
> + - interrupts: interrupt number to the cpu.
> + - clocks : clock name from clock manager
> + - clock-names: must be CLK_CAM_SENINF and CLK_TOP_MUX_SENINF.
> + It is the clocks of seninf
> +
> +Example:
> + seninf: seninf@1a040000 {
> + compatible = "mediatek,mt8183-seninf";
> + reg = <0 0x1a040000 0 0x8000>,
> + <0 0x11C80000 0 0x6000>;
> + reg-names = "base_reg", "rx_reg";
> + interrupts = <GIC_SPI 251 IRQ_TYPE_LEVEL_LOW>;
> + power-domains = <&scpsys MT8183_POWER_DOMAIN_CAM>;
> + clocks =
> + <&camsys CLK_CAM_SENINF>, <&topckgen CLK_TOP_MUX_SENINF>;
Please wrap before 80 and align the above two lines.
> + clock-names =
> + "CLK_CAM_SENINF", "CLK_TOP_MUX_SENINF";
No need to wrap here.
> + }
> +
> --
> 1.9.1
This must be old.
--
Regards,
Sakari Ailus
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH V3 2/4] media: platform: Add Mediatek sensor interface driver KConfig
From: Sakari Ailus @ 2019-08-26 11:53 UTC (permalink / raw)
To: Louis Kuo
Cc: devicetree, Sean.Cheng, laurent.pinchart+renesas, Rynn.Wu,
christie.yu, srv_heupstream, holmes.chiou, Jerry-ch.Chen, tfiga,
keiichiw, jungo.lin, sj.huang, yuzhao, hans.verkuil, zwisler,
frederic.chen, matthias.bgg, linux-mediatek, mchehab,
linux-arm-kernel, linux-media
In-Reply-To: <1559815233-24796-3-git-send-email-louis.kuo@mediatek.com>
On Thu, Jun 06, 2019 at 06:00:31PM +0800, Louis Kuo wrote:
> This patch adds KConfig for sensor interface driver. Sensor interface
> driver
> is a MIPI-CSI2 host driver, namely, a HW camera interface controller.
> It support a widely adopted, simple, high-speed protocol primarily
> intended
> for point-to-point image and video transmission between cameras and host
> devices.
>
> Signed-off-by: Louis Kuo <louis.kuo@mediatek.com>
> ---
> drivers/media/platform/mtk-isp/Kconfig | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
> create mode 100644 drivers/media/platform/mtk-isp/Kconfig
>
> diff --git a/drivers/media/platform/mtk-isp/Kconfig b/drivers/media/platform/mtk-isp/Kconfig
> new file mode 100644
> index 0000000..bc7fd01
> --- /dev/null
> +++ b/drivers/media/platform/mtk-isp/Kconfig
> @@ -0,0 +1,17 @@
> +config MTK_SENINF
> + bool "Mediatek mipi csi2 driver"
> + depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
> + depends on MEDIA_CAMERA_SUPPORT
> + select V4L2_FWNODE
> +
> + default n
> + help
> + This driver provides a mipi-csi2 host driver used as a
> + interface to connect camera with Mediatek's
> + MT8183 SOCs. It is able to handle multiple cameras
> + at the same time.
> +
> + Choose y if you want to use Mediatek SoCs to create image
> + capture application such as video recording and still image
> + capture.
Rather than being a separate patch, this should go in with the driver.
The DT bindings should precede the driver, and you'll need a MAINTAINERS
entry for the driver, too.
--
Sakari Ailus
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH -next] mmc: aspeed: Fix return value check in aspeed_sdc_probe()
From: Wei Yongjun @ 2019-08-26 12:00 UTC (permalink / raw)
To: Adrian Hunter, Ulf Hansson, Joel Stanley, Andrew Jeffery
Cc: linux-mmc, kernel-janitors, Wei Yongjun, linux-aspeed,
linux-arm-kernel
In case of error, the function of_platform_device_create() returns
NULL pointer not ERR_PTR(). The IS_ERR() test in the return value
check should be replaced with NULL test.
Fixes: 09eed7fffd33 ("mmc: Add support for the ASPEED SD controller")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/mmc/host/sdhci-of-aspeed.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci-of-aspeed.c b/drivers/mmc/host/sdhci-of-aspeed.c
index 8bb095ca2fa9..d5acb5afc50f 100644
--- a/drivers/mmc/host/sdhci-of-aspeed.c
+++ b/drivers/mmc/host/sdhci-of-aspeed.c
@@ -261,9 +261,9 @@ static int aspeed_sdc_probe(struct platform_device *pdev)
struct platform_device *cpdev;
cpdev = of_platform_device_create(child, NULL, &pdev->dev);
- if (IS_ERR(cpdev)) {
+ if (!cpdev) {
of_node_put(child);
- ret = PTR_ERR(cpdev);
+ ret = -ENODEV;
goto err_clk;
}
}
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH -next] ASoC: SOF: imx8: Fix return value check in imx8_probe()
From: Wei Yongjun @ 2019-08-26 12:00 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Daniel Baluta
Cc: kernel-janitors, alsa-devel, Wei Yongjun, linux-kernel,
linux-arm-kernel
In case of error, the function devm_ioremap_wc() returns NULL pointer
not ERR_PTR(). The IS_ERR() test in the return value check should be
replaced with NULL test.
Fixes: 202acc565a1f ("ASoC: SOF: imx: Add i.MX8 HW support")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
sound/soc/sof/imx/imx8.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/sof/imx/imx8.c b/sound/soc/sof/imx/imx8.c
index e502f584207f..263d4df35fe8 100644
--- a/sound/soc/sof/imx/imx8.c
+++ b/sound/soc/sof/imx/imx8.c
@@ -296,10 +296,10 @@ static int imx8_probe(struct snd_sof_dev *sdev)
sdev->bar[SOF_FW_BLK_TYPE_SRAM] = devm_ioremap_wc(sdev->dev, res.start,
res.end - res.start +
1);
- if (IS_ERR(sdev->bar[SOF_FW_BLK_TYPE_SRAM])) {
+ if (!sdev->bar[SOF_FW_BLK_TYPE_SRAM]) {
dev_err(sdev->dev, "failed to ioremap mem 0x%x size 0x%x\n",
base, size);
- ret = PTR_ERR(sdev->bar[SOF_FW_BLK_TYPE_SRAM]);
+ ret = -ENOMEM;
goto exit_pdev_unregister;
}
sdev->mailbox_bar = SOF_FW_BLK_TYPE_SRAM;
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2 00/20] Initial support for Marvell MMP3 SoC
From: Lubomir Rintel @ 2019-08-26 11:59 UTC (permalink / raw)
To: Marc Zyngier, Olof Johansson
Cc: Mark Rutland, devicetree, Jason Cooper, Stephen Boyd,
linux-kernel, Michael Turquette, Russell King,
Kishon Vijay Abraham I, Rob Herring, Thomas Gleixner, linux-clk,
linux-arm-kernel
In-Reply-To: <08a0e65e-4a80-f611-e36e-8e3f70fa8113@kernel.org>
On Fri, 2019-08-23 at 10:42 +0100, Marc Zyngier wrote:
> On 23/08/2019 08:21, Lubomir Rintel wrote:
> > On Thu, 2019-08-22 at 11:31 +0100, Marc Zyngier wrote:
> > > On 22/08/2019 10:26, Lubomir Rintel wrote:
> > > > Hi,
> > > >
> > > > this is a second spin of a patch set that adds support for the Marvell
> > > > MMP3 processor. MMP3 is used in OLPC XO-4 laptops, Panasonic Toughpad
> > > > FZ-A1 tablet and Dell Wyse 3020 Tx0D thin clients.
> > > >
> > > > Compared to v1, there's a handful of fixes in response to reviews. Patch
> > > > 02/20 is new. Details in individual patches.
> > > >
> > > > Apart from the adjustments in mach-mmp/, the patch makes necessary
> > > > changes to the irqchip driver and adds an USB2 PHY driver. The latter
> > > > has a dependency on the mach-mmp/ changes, so it can't be submitted
> > > > separately.
> > > >
> > > > The patch set has been tested to work on Wyse Tx0D and not ruin MMP2
> > > > support on XO-1.75.
> > >
> > > How do you want this series to be merged? I'm happy to take the irqchip
> > > related patches as well as the corresponding DT change (once reviewed)
> > > through my tree.
> >
> > I was hoping for the Arm SoC tree, because there are some dependencies
> > (MMP3 USB PHY depends on MMP3 SoC).
> >
> > That said, the irqchip patches are rather independent and the only
> > downside of them going in via a different tree will be that the other
> > tree that will lack them won't boot on MMP3 (things will compile
> > though). I don't know if that's okay. What's typically done in cases
> > like these?
>
> I usually take the irqchip patches that can be built standalone (without
> dependency on header files, for example). If you want them to go via
> another tree, stick my
>
> Acked-by: Marc Zyngier <maz@kernel.org>
>
> on patches #6 through #9.
Actually, please go ahead and pick the irqchip patches into your tree.
The rest of the patch set may need a couple more spins, and it will be
nice if it gets shorter.
Thank you
Lubo
_______________________________________________
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 -next] ASoC: SOF: imx8: Fix return value check in imx8_probe()
From: Daniel Baluta @ 2019-08-26 12:01 UTC (permalink / raw)
To: weiyongjun1@huawei.com, broonie@kernel.org, tiwai@suse.com,
lgirdwood@gmail.com, shawnguo@kernel.org, perex@perex.cz,
kernel@pengutronix.de, s.hauer@pengutronix.de
Cc: alsa-devel@alsa-project.org, kernel-janitors@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190826120003.183279-1-weiyongjun1@huawei.com>
On Mon, 2019-08-26 at 12:00 +0000, Wei Yongjun wrote:
> In case of error, the function devm_ioremap_wc() returns NULL pointer
> not ERR_PTR(). The IS_ERR() test in the return value check should be
> replaced with NULL test.
>
> Fixes: 202acc565a1f ("ASoC: SOF: imx: Add i.MX8 HW support")
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Good catch. Thanks!
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
> ---
> sound/soc/sof/imx/imx8.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/sound/soc/sof/imx/imx8.c b/sound/soc/sof/imx/imx8.c
> index e502f584207f..263d4df35fe8 100644
> --- a/sound/soc/sof/imx/imx8.c
> +++ b/sound/soc/sof/imx/imx8.c
> @@ -296,10 +296,10 @@ static int imx8_probe(struct snd_sof_dev *sdev)
> sdev->bar[SOF_FW_BLK_TYPE_SRAM] = devm_ioremap_wc(sdev->dev,
> res.start,
> res.end -
> res.start +
> 1);
> - if (IS_ERR(sdev->bar[SOF_FW_BLK_TYPE_SRAM])) {
> + if (!sdev->bar[SOF_FW_BLK_TYPE_SRAM]) {
> dev_err(sdev->dev, "failed to ioremap mem 0x%x size
> 0x%x\n",
> base, size);
> - ret = PTR_ERR(sdev->bar[SOF_FW_BLK_TYPE_SRAM]);
> + ret = -ENOMEM;
> goto exit_pdev_unregister;
> }
> sdev->mailbox_bar = SOF_FW_BLK_TYPE_SRAM;
>
>
>
_______________________________________________
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 v3 00/15] Improvements and fixes for mxsfb DRM driver
From: Guido Günther @ 2019-08-26 12:05 UTC (permalink / raw)
To: Robert Chiras
Cc: Marek Vasut, Mark Rutland, Pengutronix Kernel Team, dri-devel,
devicetree, David Airlie, Fabio Estevam, Sascha Hauer,
linux-kernel, Stefan Agner, Rob Herring, NXP Linux Team,
Daniel Vetter, Shawn Guo, linux-arm-kernel
In-Reply-To: <1566382555-12102-1-git-send-email-robert.chiras@nxp.com>
Hi,
On Wed, Aug 21, 2019 at 01:15:40PM +0300, Robert Chiras wrote:
> This patch-set improves the use of eLCDIF block on iMX 8 SoCs (like 8MQ, 8MM
> and 8QXP). Following, are the new features added and fixes from this
> patch-set:
I've applied this whole series on top of my NWL work and it looks good
with a DSI panel. Applying the whole series also fixes an issue where
after unblank the output was sometimes shifted about half a screen width
to the right (which didn't happen with DCSS). So at least from the parts
I could test:
Tested-by: Guido Günther <agx@sigxcpu.org>
for the whole thing.
Cheers,
-- Guido
>
> 1. Add support for drm_bridge
> On 8MQ and 8MM, the LCDIF block is not directly connected to a parallel
> display connector, where an LCD panel can be attached, but instead it is
> connected to DSI controller. Since this DSI stands between the display
> controller (eLCDIF) and the physical connector, the DSI can be implemented
> as a DRM bridge. So, in order to be able to connect the mxsfb driver to
> the DSI driver, the support for a drm_bridge was needed in mxsfb DRM
> driver (the actual driver for the eLCDIF block).
>
> 2. Add support for additional pixel formats
> Some of the pixel formats needed by Android were not implemented in this
> driver, but they were actually supported. So, add support for them.
>
> 3. Add support for horizontal stride
> Having support for horizontal stride allows the use of eLCDIF with a GPU
> (for example) that can only output resolution sizes multiple of a power of
> 8. For example, 1080 is not a power of 16, so in order to support 1920x1080
> output from GPUs that can produce linear buffers only in sizes multiple to 16,
> this feature is needed.
>
> 3. Few minor features and bug-fixing
> The addition of max-res DT property was actually needed in order to limit
> the bandwidth usage of the eLCDIF block. This is need on systems where
> multiple display controllers are presend and the memory bandwidth is not
> enough to handle all of them at maximum capacity (like it is the case on
> 8MQ, where there are two display controllers: DCSS and eLCDIF).
> The rest of the patches are bug-fixes.
>
> v3:
> - Removed the max-res property patches and added support for
> max-memory-bandwidth property, as it is also implemented in other drivers
> - Removed unnecessary drm_vblank_off in probe
>
> v2:
> - Collected Tested-by from Guido
> - Split the first patch, which added more than one feature into relevant
> patches, explaining each feature added
> - Also split the second patch into more patches, to differentiate between
> the feature itself (additional pixel formats support) and the cleanup
> of the register definitions for a better representation (guido)
> - Included a patch submitted by Guido, while he was testing my patch-set
>
> Guido Günther (1):
> drm/mxsfb: Read bus flags from bridge if present
>
> Mirela Rabulea (1):
> drm/mxsfb: Signal mode changed when bpp changed
>
> Robert Chiras (13):
> drm/mxsfb: Update mxsfb to support a bridge
> drm/mxsfb: Add defines for the rest of registers
> drm/mxsfb: Reset vital registers for a proper initialization
> drm/mxsfb: Update register definitions using bit manipulation defines
> drm/mxsfb: Update mxsfb with additional pixel formats
> drm/mxsfb: Fix the vblank events
> drm/mxsfb: Add max-memory-bandwidth property for MXSFB
> dt-bindings: display: Add max-memory-bandwidth property for mxsfb
> drm/mxsfb: Update mxsfb to support LCD reset
> drm/mxsfb: Improve the axi clock usage
> drm/mxsfb: Clear OUTSTANDING_REQS bits
> drm/mxsfb: Add support for horizontal stride
> drm/mxsfb: Add support for live pixel format change
>
> .../devicetree/bindings/display/mxsfb.txt | 5 +
> drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 287 ++++++++++++++++++---
> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 203 +++++++++++++--
> drivers/gpu/drm/mxsfb/mxsfb_drv.h | 12 +-
> drivers/gpu/drm/mxsfb/mxsfb_out.c | 26 +-
> drivers/gpu/drm/mxsfb/mxsfb_regs.h | 193 +++++++++-----
> 6 files changed, 589 insertions(+), 137 deletions(-)
>
> --
> 2.7.4
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC 7/9] dt-bindings: rtc: s3c: Convert S3C/Exynos RTC bindings to json-schema
From: Rob Herring @ 2019-08-26 12:06 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Mark Rutland, Alessandro Zummo, Alexandre Belloni,
Lars-Peter Clausen, Arnd Bergmann, devicetree,
open list:IIO SUBSYSTEM AND DRIVERS, Marek Szyprowski,
linux-kernel@vger.kernel.org, Tomasz Figa, linux-samsung-soc,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Peter Meerwald-Stadler, Hartmut Knaack, Olof Johansson,
open list:REAL TIME CLOCK (RTC) SUBSYSTEM, notify,
Jonathan Cameron, Paweł Chmiel
In-Reply-To: <20190823145356.6341-7-krzk@kernel.org>
On Fri, Aug 23, 2019 at 9:54 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> Convert Samsung S3C/Exynos Real Time Clock bindings to DT schema format
> using json-schema.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> ---
> .../devicetree/bindings/rtc/s3c-rtc.txt | 31 ------
> .../devicetree/bindings/rtc/s3c-rtc.yaml | 95 +++++++++++++++++++
> 2 files changed, 95 insertions(+), 31 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/rtc/s3c-rtc.txt
> create mode 100644 Documentation/devicetree/bindings/rtc/s3c-rtc.yaml
> diff --git a/Documentation/devicetree/bindings/rtc/s3c-rtc.yaml b/Documentation/devicetree/bindings/rtc/s3c-rtc.yaml
> new file mode 100644
> index 000000000000..44b021812a83
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rtc/s3c-rtc.yaml
> @@ -0,0 +1,95 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/rtc/s3c-rtc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Samsung S3C, S5P and Exynos Real Time Clock controller
> +
> +maintainers:
> + - Krzysztof Kozlowski <krzk@kernel.org>
> +
> +# Select also deprecated compatibles (for finding deprecate usage)
> +select:
> + properties:
> + compatible:
> + items:
> + - enum:
> + - samsung,s3c2410-rtc
> + - samsung,s3c2416-rtc
> + - samsung,s3c2443-rtc
> + - samsung,s3c6410-rtc
> + # Deprecated, use samsung,s3c6410-rtc
> + - samsung,exynos3250-rtc
We've come up with a better way of doing this that doesn't need a
custom 'select'. Add a 'oneOf' to compatible and add another entry:
- const: samsung,exynos3250-rtc
deprecated: true
It's not implemented yet in the tool, but we'll keep the compatible
for 'select' and otherwise drop schema marked deprecated.
> + required:
> + - compatible
> +
> +properties:
> + compatible:
> + items:
> + - enum:
You can drop 'items' when there's only 1 entry.
> + - samsung,s3c2410-rtc
> + - samsung,s3c2416-rtc
> + - samsung,s3c2443-rtc
> + - samsung,s3c6410-rtc
> + reg:
> + maxItems: 1
> +
> + clocks:
> + description:
> + Must contain a list of phandle and clock specifier for the rtc
> + clock and in the case of a s3c6410 compatible controller, also
> + a source clock.
> + minItems: 1
> + maxItems: 2
> +
> + clock-names:
> + description:
> + Must contain "rtc" and for a s3c6410 compatible controller,
> + a "rtc_src" sorted in the same order as the clocks property.
> + oneOf:
> + - items:
> + - const: rtc
> + - items:
> + # TODO: This can be in any order matching clocks, how to express it?
It shouldn't be in any order. Fix the dts files.
> + - const: rtc
> + - const: rtc_src
You should drop all this and add an else clause below.
> +
> + interrupts:
> + description:
> + Two interrupt numbers to the cpu should be specified. First
> + interrupt number is the rtc alarm interrupt and second interrupt number
> + is the rtc tick interrupt. The number of cells representing a interrupt
> + depends on the parent interrupt controller.
> + minItems: 2
> + maxItems: 2
> +
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - samsung,s3c6410-rtc
> + - samsung,exynos3250-rtc
> +
> + then:
> + properties:
> + clocks:
> + minItems: 2
> + maxItems: 2
> + clock-names:
> + items:
> + - const: rtc
> + - const: rtc_src
Should be indented 2 more spaces.
> +
> +examples:
> + - |
> + rtc@10070000 {
> + compatible = "samsung,s3c6410-rtc";
> + reg = <0x10070000 0x100>;
> + interrupts = <0 44 4>, <0 45 4>;
> + clocks = <&clock 0>, // CLK_RTC
> + <&s2mps11_osc 0>; // S2MPS11_CLK_AP
> + clock-names = "rtc", "rtc_src";
> + };
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2,1/3] dt-bindings: Add vendor prefix for Ugoos
From: Rob Herring @ 2019-08-26 12:10 UTC (permalink / raw)
To: Christian Hewitt
Cc: Mark Rutland, devicetree, Oleg Ivanov, Kevin Hilman,
linux-kernel@vger.kernel.org, linux-amlogic,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <1566633850-9421-2-git-send-email-christianshewitt@gmail.com>
On Sat, Aug 24, 2019 at 3:05 AM Christian Hewitt
<christianshewitt@gmail.com> wrote:
>
> Ugoos Industrial Co., Ltd. are a manufacturer of ARM based TV Boxes,
> Dongles, Digital Signage and Advertisement Solutions [0].
>
> [0] (https://ugoos.com)
>
> Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> 1 file changed, 2 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2,2/3] dt-bindings: arm: amlogic: Add support for the Ugoos AM6
From: Rob Herring @ 2019-08-26 12:11 UTC (permalink / raw)
To: Christian Hewitt
Cc: Mark Rutland, devicetree, Oleg Ivanov, Kevin Hilman,
linux-kernel@vger.kernel.org, linux-amlogic,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <1566633850-9421-3-git-send-email-christianshewitt@gmail.com>
On Sat, Aug 24, 2019 at 3:05 AM Christian Hewitt
<christianshewitt@gmail.com> wrote:
>
> The Ugoos AM6 is based on the Amlogic W400 (G12B) reference design using the
> S922X chipset.
>
> Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
> ---
> Documentation/devicetree/bindings/arm/amlogic.yaml | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* swiotlb-xen cleanups v2
From: Christoph Hellwig @ 2019-08-26 12:19 UTC (permalink / raw)
To: Stefano Stabellini, Konrad Rzeszutek Wilk
Cc: xen-devel, iommu, x86, linux-kernel, linux-arm-kernel
Hi Xen maintainers and friends,
please take a look at this series that cleans up the parts of swiotlb-xen
that deal with non-coherent caches.
Changes since v1:
- rewrite dma_cache_maint to be much simpler
- improve various comments and commit logs
- remove page-coherent.h entirely
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 01/11] xen/arm: use dma-noncoherent.h calls for xen-swiotlb cache maintainance
From: Christoph Hellwig @ 2019-08-26 12:19 UTC (permalink / raw)
To: Stefano Stabellini, Konrad Rzeszutek Wilk
Cc: xen-devel, iommu, x86, linux-kernel, linux-arm-kernel
In-Reply-To: <20190826121944.515-1-hch@lst.de>
Reuse the arm64 code that uses the dma-direct/swiotlb helpers for DMA
non-coherent devices.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/arm/include/asm/device.h | 3 -
arch/arm/include/asm/xen/page-coherent.h | 93 ----------------------
arch/arm/mm/dma-mapping.c | 8 +-
arch/arm64/include/asm/xen/page-coherent.h | 75 -----------------
drivers/xen/swiotlb-xen.c | 49 +-----------
include/xen/arm/page-coherent.h | 80 +++++++++++++++++++
6 files changed, 83 insertions(+), 225 deletions(-)
diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
index f6955b55c544..c675bc0d5aa8 100644
--- a/arch/arm/include/asm/device.h
+++ b/arch/arm/include/asm/device.h
@@ -14,9 +14,6 @@ struct dev_archdata {
#endif
#ifdef CONFIG_ARM_DMA_USE_IOMMU
struct dma_iommu_mapping *mapping;
-#endif
-#ifdef CONFIG_XEN
- const struct dma_map_ops *dev_dma_ops;
#endif
unsigned int dma_coherent:1;
unsigned int dma_ops_setup:1;
diff --git a/arch/arm/include/asm/xen/page-coherent.h b/arch/arm/include/asm/xen/page-coherent.h
index 2c403e7c782d..27e984977402 100644
--- a/arch/arm/include/asm/xen/page-coherent.h
+++ b/arch/arm/include/asm/xen/page-coherent.h
@@ -1,95 +1,2 @@
/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef _ASM_ARM_XEN_PAGE_COHERENT_H
-#define _ASM_ARM_XEN_PAGE_COHERENT_H
-
-#include <linux/dma-mapping.h>
-#include <asm/page.h>
#include <xen/arm/page-coherent.h>
-
-static inline const struct dma_map_ops *xen_get_dma_ops(struct device *dev)
-{
- if (dev && dev->archdata.dev_dma_ops)
- return dev->archdata.dev_dma_ops;
- return get_arch_dma_ops(NULL);
-}
-
-static inline void *xen_alloc_coherent_pages(struct device *hwdev, size_t size,
- dma_addr_t *dma_handle, gfp_t flags, unsigned long attrs)
-{
- return xen_get_dma_ops(hwdev)->alloc(hwdev, size, dma_handle, flags, attrs);
-}
-
-static inline void xen_free_coherent_pages(struct device *hwdev, size_t size,
- void *cpu_addr, dma_addr_t dma_handle, unsigned long attrs)
-{
- xen_get_dma_ops(hwdev)->free(hwdev, size, cpu_addr, dma_handle, attrs);
-}
-
-static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
- dma_addr_t dev_addr, unsigned long offset, size_t size,
- enum dma_data_direction dir, unsigned long attrs)
-{
- unsigned long page_pfn = page_to_xen_pfn(page);
- unsigned long dev_pfn = XEN_PFN_DOWN(dev_addr);
- unsigned long compound_pages =
- (1<<compound_order(page)) * XEN_PFN_PER_PAGE;
- bool local = (page_pfn <= dev_pfn) &&
- (dev_pfn - page_pfn < compound_pages);
-
- /*
- * Dom0 is mapped 1:1, while the Linux page can span across
- * multiple Xen pages, it's not possible for it to contain a
- * mix of local and foreign Xen pages. So if the first xen_pfn
- * == mfn the page is local otherwise it's a foreign page
- * grant-mapped in dom0. If the page is local we can safely
- * call the native dma_ops function, otherwise we call the xen
- * specific function.
- */
- if (local)
- xen_get_dma_ops(hwdev)->map_page(hwdev, page, offset, size, dir, attrs);
- else
- __xen_dma_map_page(hwdev, page, dev_addr, offset, size, dir, attrs);
-}
-
-static inline void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
- size_t size, enum dma_data_direction dir, unsigned long attrs)
-{
- unsigned long pfn = PFN_DOWN(handle);
- /*
- * Dom0 is mapped 1:1, while the Linux page can be spanned accross
- * multiple Xen page, it's not possible to have a mix of local and
- * foreign Xen page. Dom0 is mapped 1:1, so calling pfn_valid on a
- * foreign mfn will always return false. If the page is local we can
- * safely call the native dma_ops function, otherwise we call the xen
- * specific function.
- */
- if (pfn_valid(pfn)) {
- if (xen_get_dma_ops(hwdev)->unmap_page)
- xen_get_dma_ops(hwdev)->unmap_page(hwdev, handle, size, dir, attrs);
- } else
- __xen_dma_unmap_page(hwdev, handle, size, dir, attrs);
-}
-
-static inline void xen_dma_sync_single_for_cpu(struct device *hwdev,
- dma_addr_t handle, size_t size, enum dma_data_direction dir)
-{
- unsigned long pfn = PFN_DOWN(handle);
- if (pfn_valid(pfn)) {
- if (xen_get_dma_ops(hwdev)->sync_single_for_cpu)
- xen_get_dma_ops(hwdev)->sync_single_for_cpu(hwdev, handle, size, dir);
- } else
- __xen_dma_sync_single_for_cpu(hwdev, handle, size, dir);
-}
-
-static inline void xen_dma_sync_single_for_device(struct device *hwdev,
- dma_addr_t handle, size_t size, enum dma_data_direction dir)
-{
- unsigned long pfn = PFN_DOWN(handle);
- if (pfn_valid(pfn)) {
- if (xen_get_dma_ops(hwdev)->sync_single_for_device)
- xen_get_dma_ops(hwdev)->sync_single_for_device(hwdev, handle, size, dir);
- } else
- __xen_dma_sync_single_for_device(hwdev, handle, size, dir);
-}
-
-#endif /* _ASM_ARM_XEN_PAGE_COHERENT_H */
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index d42557ee69c2..738097396445 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1132,10 +1132,6 @@ static const struct dma_map_ops *arm_get_dma_map_ops(bool coherent)
* 32-bit DMA.
* Use the generic dma-direct / swiotlb ops code in that case, as that
* handles bounce buffering for us.
- *
- * Note: this checks CONFIG_ARM_LPAE instead of CONFIG_SWIOTLB as the
- * latter is also selected by the Xen code, but that code for now relies
- * on non-NULL dev_dma_ops. To be cleaned up later.
*/
if (IS_ENABLED(CONFIG_ARM_LPAE))
return NULL;
@@ -2363,10 +2359,8 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
set_dma_ops(dev, dma_ops);
#ifdef CONFIG_XEN
- if (xen_initial_domain()) {
- dev->archdata.dev_dma_ops = dev->dma_ops;
+ if (xen_initial_domain())
dev->dma_ops = xen_dma_ops;
- }
#endif
dev->archdata.dma_ops_setup = true;
}
diff --git a/arch/arm64/include/asm/xen/page-coherent.h b/arch/arm64/include/asm/xen/page-coherent.h
index d88e56b90b93..27e984977402 100644
--- a/arch/arm64/include/asm/xen/page-coherent.h
+++ b/arch/arm64/include/asm/xen/page-coherent.h
@@ -1,77 +1,2 @@
/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef _ASM_ARM64_XEN_PAGE_COHERENT_H
-#define _ASM_ARM64_XEN_PAGE_COHERENT_H
-
-#include <linux/dma-mapping.h>
-#include <asm/page.h>
#include <xen/arm/page-coherent.h>
-
-static inline void *xen_alloc_coherent_pages(struct device *hwdev, size_t size,
- dma_addr_t *dma_handle, gfp_t flags, unsigned long attrs)
-{
- return dma_direct_alloc(hwdev, size, dma_handle, flags, attrs);
-}
-
-static inline void xen_free_coherent_pages(struct device *hwdev, size_t size,
- void *cpu_addr, dma_addr_t dma_handle, unsigned long attrs)
-{
- dma_direct_free(hwdev, size, cpu_addr, dma_handle, attrs);
-}
-
-static inline void xen_dma_sync_single_for_cpu(struct device *hwdev,
- dma_addr_t handle, size_t size, enum dma_data_direction dir)
-{
- unsigned long pfn = PFN_DOWN(handle);
-
- if (pfn_valid(pfn))
- dma_direct_sync_single_for_cpu(hwdev, handle, size, dir);
- else
- __xen_dma_sync_single_for_cpu(hwdev, handle, size, dir);
-}
-
-static inline void xen_dma_sync_single_for_device(struct device *hwdev,
- dma_addr_t handle, size_t size, enum dma_data_direction dir)
-{
- unsigned long pfn = PFN_DOWN(handle);
- if (pfn_valid(pfn))
- dma_direct_sync_single_for_device(hwdev, handle, size, dir);
- else
- __xen_dma_sync_single_for_device(hwdev, handle, size, dir);
-}
-
-static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
- dma_addr_t dev_addr, unsigned long offset, size_t size,
- enum dma_data_direction dir, unsigned long attrs)
-{
- unsigned long page_pfn = page_to_xen_pfn(page);
- unsigned long dev_pfn = XEN_PFN_DOWN(dev_addr);
- unsigned long compound_pages =
- (1<<compound_order(page)) * XEN_PFN_PER_PAGE;
- bool local = (page_pfn <= dev_pfn) &&
- (dev_pfn - page_pfn < compound_pages);
-
- if (local)
- dma_direct_map_page(hwdev, page, offset, size, dir, attrs);
- else
- __xen_dma_map_page(hwdev, page, dev_addr, offset, size, dir, attrs);
-}
-
-static inline void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
- size_t size, enum dma_data_direction dir, unsigned long attrs)
-{
- unsigned long pfn = PFN_DOWN(handle);
- /*
- * Dom0 is mapped 1:1, while the Linux page can be spanned accross
- * multiple Xen page, it's not possible to have a mix of local and
- * foreign Xen page. Dom0 is mapped 1:1, so calling pfn_valid on a
- * foreign mfn will always return false. If the page is local we can
- * safely call the native dma_ops function, otherwise we call the xen
- * specific function.
- */
- if (pfn_valid(pfn))
- dma_direct_unmap_page(hwdev, handle, size, dir, attrs);
- else
- __xen_dma_unmap_page(hwdev, handle, size, dir, attrs);
-}
-
-#endif /* _ASM_ARM64_XEN_PAGE_COHERENT_H */
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index ae1df496bf38..b8808677ae1d 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -547,51 +547,6 @@ xen_swiotlb_dma_supported(struct device *hwdev, u64 mask)
return xen_virt_to_bus(xen_io_tlb_end - 1) <= mask;
}
-/*
- * Create userspace mapping for the DMA-coherent memory.
- * This function should be called with the pages from the current domain only,
- * passing pages mapped from other domains would lead to memory corruption.
- */
-static int
-xen_swiotlb_dma_mmap(struct device *dev, struct vm_area_struct *vma,
- void *cpu_addr, dma_addr_t dma_addr, size_t size,
- unsigned long attrs)
-{
-#ifdef CONFIG_ARM
- if (xen_get_dma_ops(dev)->mmap)
- return xen_get_dma_ops(dev)->mmap(dev, vma, cpu_addr,
- dma_addr, size, attrs);
-#endif
- return dma_common_mmap(dev, vma, cpu_addr, dma_addr, size, attrs);
-}
-
-/*
- * This function should be called with the pages from the current domain only,
- * passing pages mapped from other domains would lead to memory corruption.
- */
-static int
-xen_swiotlb_get_sgtable(struct device *dev, struct sg_table *sgt,
- void *cpu_addr, dma_addr_t handle, size_t size,
- unsigned long attrs)
-{
-#ifdef CONFIG_ARM
- if (xen_get_dma_ops(dev)->get_sgtable) {
-#if 0
- /*
- * This check verifies that the page belongs to the current domain and
- * is not one mapped from another domain.
- * This check is for debug only, and should not go to production build
- */
- unsigned long bfn = PHYS_PFN(dma_to_phys(dev, handle));
- BUG_ON (!page_is_ram(bfn));
-#endif
- return xen_get_dma_ops(dev)->get_sgtable(dev, sgt, cpu_addr,
- handle, size, attrs);
- }
-#endif
- return dma_common_get_sgtable(dev, sgt, cpu_addr, handle, size, attrs);
-}
-
const struct dma_map_ops xen_swiotlb_dma_ops = {
.alloc = xen_swiotlb_alloc_coherent,
.free = xen_swiotlb_free_coherent,
@@ -604,6 +559,6 @@ const struct dma_map_ops xen_swiotlb_dma_ops = {
.map_page = xen_swiotlb_map_page,
.unmap_page = xen_swiotlb_unmap_page,
.dma_supported = xen_swiotlb_dma_supported,
- .mmap = xen_swiotlb_dma_mmap,
- .get_sgtable = xen_swiotlb_get_sgtable,
+ .mmap = dma_common_mmap,
+ .get_sgtable = dma_common_get_sgtable,
};
diff --git a/include/xen/arm/page-coherent.h b/include/xen/arm/page-coherent.h
index 2ca9164a79bf..a840d6949a87 100644
--- a/include/xen/arm/page-coherent.h
+++ b/include/xen/arm/page-coherent.h
@@ -2,6 +2,9 @@
#ifndef _XEN_ARM_PAGE_COHERENT_H
#define _XEN_ARM_PAGE_COHERENT_H
+#include <linux/dma-mapping.h>
+#include <asm/page.h>
+
void __xen_dma_map_page(struct device *hwdev, struct page *page,
dma_addr_t dev_addr, unsigned long offset, size_t size,
enum dma_data_direction dir, unsigned long attrs);
@@ -13,4 +16,81 @@ void __xen_dma_sync_single_for_cpu(struct device *hwdev,
void __xen_dma_sync_single_for_device(struct device *hwdev,
dma_addr_t handle, size_t size, enum dma_data_direction dir);
+static inline void *xen_alloc_coherent_pages(struct device *hwdev, size_t size,
+ dma_addr_t *dma_handle, gfp_t flags, unsigned long attrs)
+{
+ return dma_direct_alloc(hwdev, size, dma_handle, flags, attrs);
+}
+
+static inline void xen_free_coherent_pages(struct device *hwdev, size_t size,
+ void *cpu_addr, dma_addr_t dma_handle, unsigned long attrs)
+{
+ dma_direct_free(hwdev, size, cpu_addr, dma_handle, attrs);
+}
+
+static inline void xen_dma_sync_single_for_cpu(struct device *hwdev,
+ dma_addr_t handle, size_t size, enum dma_data_direction dir)
+{
+ unsigned long pfn = PFN_DOWN(handle);
+
+ if (pfn_valid(pfn))
+ dma_direct_sync_single_for_cpu(hwdev, handle, size, dir);
+ else
+ __xen_dma_sync_single_for_cpu(hwdev, handle, size, dir);
+}
+
+static inline void xen_dma_sync_single_for_device(struct device *hwdev,
+ dma_addr_t handle, size_t size, enum dma_data_direction dir)
+{
+ unsigned long pfn = PFN_DOWN(handle);
+ if (pfn_valid(pfn))
+ dma_direct_sync_single_for_device(hwdev, handle, size, dir);
+ else
+ __xen_dma_sync_single_for_device(hwdev, handle, size, dir);
+}
+
+static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
+ dma_addr_t dev_addr, unsigned long offset, size_t size,
+ enum dma_data_direction dir, unsigned long attrs)
+{
+ unsigned long page_pfn = page_to_xen_pfn(page);
+ unsigned long dev_pfn = XEN_PFN_DOWN(dev_addr);
+ unsigned long compound_pages =
+ (1<<compound_order(page)) * XEN_PFN_PER_PAGE;
+ bool local = (page_pfn <= dev_pfn) &&
+ (dev_pfn - page_pfn < compound_pages);
+
+ /*
+ * Dom0 is mapped 1:1, while the Linux page can span across
+ * multiple Xen pages, it's not possible for it to contain a
+ * mix of local and foreign Xen pages. So if the first xen_pfn
+ * == mfn the page is local otherwise it's a foreign page
+ * grant-mapped in dom0. If the page is local we can safely
+ * call the native dma_ops function, otherwise we call the xen
+ * specific function.
+ */
+ if (local)
+ dma_direct_map_page(hwdev, page, offset, size, dir, attrs);
+ else
+ __xen_dma_map_page(hwdev, page, dev_addr, offset, size, dir, attrs);
+}
+
+static inline void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
+ size_t size, enum dma_data_direction dir, unsigned long attrs)
+{
+ unsigned long pfn = PFN_DOWN(handle);
+ /*
+ * Dom0 is mapped 1:1, while the Linux page can be spanned accross
+ * multiple Xen page, it's not possible to have a mix of local and
+ * foreign Xen page. Dom0 is mapped 1:1, so calling pfn_valid on a
+ * foreign mfn will always return false. If the page is local we can
+ * safely call the native dma_ops function, otherwise we call the xen
+ * specific function.
+ */
+ if (pfn_valid(pfn))
+ dma_direct_unmap_page(hwdev, handle, size, dir, attrs);
+ else
+ __xen_dma_unmap_page(hwdev, handle, size, dir, attrs);
+}
+
#endif /* _XEN_ARM_PAGE_COHERENT_H */
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 02/11] xen/arm: use dev_is_dma_coherent
From: Christoph Hellwig @ 2019-08-26 12:19 UTC (permalink / raw)
To: Stefano Stabellini, Konrad Rzeszutek Wilk
Cc: x86, Julien Grall, linux-kernel, iommu, xen-devel,
linux-arm-kernel
In-Reply-To: <20190826121944.515-1-hch@lst.de>
Use the dma-noncoherent dev_is_dma_coherent helper instead of the home
grown variant. Note that both are always initialized to the same
value in arch_setup_dma_ops.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Julien Grall <julien.grall@arm.com>
---
arch/arm/include/asm/dma-mapping.h | 6 ------
arch/arm/xen/mm.c | 12 ++++++------
arch/arm64/include/asm/dma-mapping.h | 9 ---------
3 files changed, 6 insertions(+), 21 deletions(-)
diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
index dba9355e2484..bdd80ddbca34 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -91,12 +91,6 @@ static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
}
#endif
-/* do not use this function in a driver */
-static inline bool is_device_dma_coherent(struct device *dev)
-{
- return dev->archdata.dma_coherent;
-}
-
/**
* arm_dma_alloc - allocate consistent memory for DMA
* @dev: valid struct device pointer, or NULL for ISA and EISA-like devices
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index d33b77e9add3..90574d89d0d4 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0-only
#include <linux/cpu.h>
-#include <linux/dma-mapping.h>
+#include <linux/dma-noncoherent.h>
#include <linux/gfp.h>
#include <linux/highmem.h>
#include <linux/export.h>
@@ -99,7 +99,7 @@ void __xen_dma_map_page(struct device *hwdev, struct page *page,
dma_addr_t dev_addr, unsigned long offset, size_t size,
enum dma_data_direction dir, unsigned long attrs)
{
- if (is_device_dma_coherent(hwdev))
+ if (dev_is_dma_coherent(hwdev))
return;
if (attrs & DMA_ATTR_SKIP_CPU_SYNC)
return;
@@ -112,7 +112,7 @@ void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
unsigned long attrs)
{
- if (is_device_dma_coherent(hwdev))
+ if (dev_is_dma_coherent(hwdev))
return;
if (attrs & DMA_ATTR_SKIP_CPU_SYNC)
return;
@@ -123,7 +123,7 @@ void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
void __xen_dma_sync_single_for_cpu(struct device *hwdev,
dma_addr_t handle, size_t size, enum dma_data_direction dir)
{
- if (is_device_dma_coherent(hwdev))
+ if (dev_is_dma_coherent(hwdev))
return;
__xen_dma_page_dev_to_cpu(hwdev, handle, size, dir);
}
@@ -131,7 +131,7 @@ void __xen_dma_sync_single_for_cpu(struct device *hwdev,
void __xen_dma_sync_single_for_device(struct device *hwdev,
dma_addr_t handle, size_t size, enum dma_data_direction dir)
{
- if (is_device_dma_coherent(hwdev))
+ if (dev_is_dma_coherent(hwdev))
return;
__xen_dma_page_cpu_to_dev(hwdev, handle, size, dir);
}
@@ -159,7 +159,7 @@ bool xen_arch_need_swiotlb(struct device *dev,
* memory and we are not able to flush the cache.
*/
return (!hypercall_cflush && (xen_pfn != bfn) &&
- !is_device_dma_coherent(dev));
+ !dev_is_dma_coherent(dev));
}
int xen_create_contiguous_region(phys_addr_t pstart, unsigned int order,
diff --git a/arch/arm64/include/asm/dma-mapping.h b/arch/arm64/include/asm/dma-mapping.h
index bdcb0922a40c..67243255a858 100644
--- a/arch/arm64/include/asm/dma-mapping.h
+++ b/arch/arm64/include/asm/dma-mapping.h
@@ -18,14 +18,5 @@ static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus)
return NULL;
}
-/*
- * Do not use this function in a driver, it is only provided for
- * arch/arm/mm/xen.c, which is used by arm64 as well.
- */
-static inline bool is_device_dma_coherent(struct device *dev)
-{
- return dev->dma_coherent;
-}
-
#endif /* __KERNEL__ */
#endif /* __ASM_DMA_MAPPING_H */
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 03/11] xen/arm: simplify dma_cache_maint
From: Christoph Hellwig @ 2019-08-26 12:19 UTC (permalink / raw)
To: Stefano Stabellini, Konrad Rzeszutek Wilk
Cc: xen-devel, iommu, x86, linux-kernel, linux-arm-kernel
In-Reply-To: <20190826121944.515-1-hch@lst.de>
Calculate the required operation in the caller, and pass it directly
instead of recalculating it for each page, and use simple arithmetics
to get from the physical address to Xen page size aligned chunks.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/arm/xen/mm.c | 62 +++++++++++++++++------------------------------
1 file changed, 22 insertions(+), 40 deletions(-)
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index 90574d89d0d4..14210ebdea1a 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -35,64 +35,46 @@ unsigned long xen_get_swiotlb_free_pages(unsigned int order)
return __get_free_pages(flags, order);
}
-enum dma_cache_op {
- DMA_UNMAP,
- DMA_MAP,
-};
static bool hypercall_cflush = false;
-/* functions called by SWIOTLB */
-
-static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
- size_t size, enum dma_data_direction dir, enum dma_cache_op op)
+/* buffers in highmem or foreign pages cannot cross page boundaries */
+static void dma_cache_maint(dma_addr_t handle, size_t size, u32 op)
{
struct gnttab_cache_flush cflush;
- unsigned long xen_pfn;
- size_t left = size;
- xen_pfn = (handle >> XEN_PAGE_SHIFT) + offset / XEN_PAGE_SIZE;
- offset %= XEN_PAGE_SIZE;
+ cflush.a.dev_bus_addr = handle & XEN_PAGE_MASK;
+ cflush.offset = xen_offset_in_page(handle);
+ cflush.op = op;
do {
- size_t len = left;
-
- /* buffers in highmem or foreign pages cannot cross page
- * boundaries */
- if (len + offset > XEN_PAGE_SIZE)
- len = XEN_PAGE_SIZE - offset;
-
- cflush.op = 0;
- cflush.a.dev_bus_addr = xen_pfn << XEN_PAGE_SHIFT;
- cflush.offset = offset;
- cflush.length = len;
-
- if (op == DMA_UNMAP && dir != DMA_TO_DEVICE)
- cflush.op = GNTTAB_CACHE_INVAL;
- if (op == DMA_MAP) {
- if (dir == DMA_FROM_DEVICE)
- cflush.op = GNTTAB_CACHE_INVAL;
- else
- cflush.op = GNTTAB_CACHE_CLEAN;
- }
- if (cflush.op)
- HYPERVISOR_grant_table_op(GNTTABOP_cache_flush, &cflush, 1);
+ if (size + cflush.offset > XEN_PAGE_SIZE)
+ cflush.length = XEN_PAGE_SIZE - cflush.offset;
+ else
+ cflush.length = size;
+
+ HYPERVISOR_grant_table_op(GNTTABOP_cache_flush, &cflush, 1);
+
+ handle += cflush.length;
+ size -= cflush.length;
- offset = 0;
- xen_pfn++;
- left -= len;
- } while (left);
+ cflush.offset = 0;
+ } while (size);
}
static void __xen_dma_page_dev_to_cpu(struct device *hwdev, dma_addr_t handle,
size_t size, enum dma_data_direction dir)
{
- dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, DMA_UNMAP);
+ if (dir != DMA_TO_DEVICE)
+ dma_cache_maint(handle, size, GNTTAB_CACHE_INVAL);
}
static void __xen_dma_page_cpu_to_dev(struct device *hwdev, dma_addr_t handle,
size_t size, enum dma_data_direction dir)
{
- dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, DMA_MAP);
+ if (dir == DMA_FROM_DEVICE)
+ dma_cache_maint(handle, size, GNTTAB_CACHE_INVAL);
+ else
+ dma_cache_maint(handle, size, GNTTAB_CACHE_CLEAN);
}
void __xen_dma_map_page(struct device *hwdev, struct page *page,
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
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