* Re: [PATCH v11 03/12] dt-binding: gce: add binding for gce client reg property
From: Rob Herring @ 2019-08-16 22:06 UTC (permalink / raw)
To: Bibby Hsieh
Cc: devicetree, Nicolas Boichat, Philipp Zabel, srv_heupstream,
Daoyuan Huang, Sascha Hauer, Jassi Brar, linux-kernel,
Daniel Kurtz, YT Shen, CK HU, Dennis-YC Hsieh, linux-mediatek,
Houlong Wei, Sascha Hauer, Matthias Brugger, Jiaguang Zhang,
Bibby Hsieh, linux-arm-kernel, ginny.chen
In-Reply-To: <20190729070106.9332-4-bibby.hsieh@mediatek.com>
On Mon, 29 Jul 2019 15:00:57 +0800, Bibby Hsieh wrote:
> cmdq driver provide a function that get the relationship
> of sub system number from device node for client.
> add specification for #subsys-cells, mediatek,gce-client-reg.
>
> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
> ---
> .../devicetree/bindings/mailbox/mtk-gce.txt | 16 ++++++++++++----
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/6] drm+dma: cache support for arm, etc
From: Rob Clark @ 2019-08-16 21:04 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Kate Stewart, Masayoshi Mizuma, Maciej W. Rozycki, Eric Biggers,
Catalin Marinas, Imre Deak, dri-devel, Chris Wilson,
Masahiro Yamada, Benjamin Gaignard, Mauro Carvalho Chehab,
Will Deacon, Emil Velikov, Deepak Sharma, Michael Ellerman,
Paul Burton, Mike Rapoport, Geert Uytterhoeven,
moderated list:ARM64 PORT (AARCH64 ARCHITECTURE), Daniel Vetter,
open list:MIPS, Linus Walleij, Robin Murphy,
open list:DRM DRIVER FOR MSM ADRENO GPU, Joerg Roedel,
Arnd Bergmann, Anshuman Khandual, Hauke Mehrtens,
Jesper Dangaard Brouer, Wolfram Sang (Renesas),
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT), Alexios Zavras,
Russell King, Doug Anderson, Thomas Gleixner, Sean Paul,
Allison Randal, Christophe Leroy, Enrico Weigelt, Ard Biesheuvel,
Greg Kroah-Hartman, open list, Rob Clark, Souptick Joarder,
Andrew Morton, open list:DRM DRIVER FOR MSM ADRENO GPU,
christian.koenig
In-Reply-To: <20190815175346.GA19839@lst.de>
On Thu, Aug 15, 2019 at 10:53 AM Christoph Hellwig <hch@lst.de> wrote:
>
> On Thu, Aug 15, 2019 at 06:54:39AM -0700, Rob Clark wrote:
> > On Wed, Aug 14, 2019 at 11:51 PM Christoph Hellwig <hch@lst.de> wrote:
> > >
> > > As said before I don't think these low-level helpers are the
> > > right API to export, but even if they did you'd just cover a tiny
> > > subset of the architectures.
> >
> > Are you thinking instead something like:
> >
> > void dma_sync_sg_for_{cpu,device}(struct device *dev, struct scatterlist *sgl,
> > int nents, enum dma_data_direction dir)
> > {
> > for_each_sg(sgl, sg, nents, i) {
> > arch_sync_dma_for_..(dev, sg_phys(sg), sg->length, dir);
> > }
> > }
> > EXPORT_SYMBOL_GPL(dma_sync_sg_for_..)
> >
> > or did you have something else in mind?
>
> No. We really need an interface thay says please give me uncached
> memory (for some definition of uncached that includes that grapics
> drivers call write combine), and then let the architecture do the right
> thing. Basically dma_alloc_coherent with DMA_ATTR_NO_KERNEL_MAPPING
> is superficially close to what you want, except that the way the drm
> drivers work you can't actually use it.
I don't disagree about needing an API to get uncached memory (or
ideally just something outside of the linear map). But I think this
is a separate problem.
What I was hoping for, for v5.4, is a way to stop abusing dma_map/sync
for cache ops to get rid of the hack I had to make for v5.3. And also
to fix vgem on non-x86. (Unfortunately changing vgem to used cached
mappings breaks x86 CI, but fixes CI on arm/arm64..) We can do that
without any changes in allocation. There is still the possibility for
problems due to cached alias, but that has been a problem this whole
time, it isn't something new.
BR,
-R
> The reason for that is if we can we really need to not create another
> uncachable alias, but instead change the page attributes in place.
> On x86 we can and must do that for example, and based on the
> conversation with Will arm64 could do that fairly easily. arm32 can
> right now only do that for CMA, though.
>
> The big question is what API do we want. I had a pretty similar
> discussion with Christian on doing such an allocation for amdgpu,
> where the device normally is cache coherent, but they actually want
> to turn it into non-coherent by using PCIe unsnooped transactions.
>
> Here is my high level plan, which still has a few lose end:
>
> (1) provide a new API:
>
> struct page *dma_alloc_pages(struct device *dev, unsigned nr_pages,
> gfp_t gfp, unsigned long flags);
> void dma_free_pages(struct device *dev, unsigned nr_pages,
> unsigned long flags);
>
> These give you back page backed memory that is guaranteed to be
> addressable by the device (no swiotlb or similar). The memory can
> then be mapped using dma_map*, including unmap and dma_sync to
> bounce ownership around. This is the replacement for the current
> dma_alloc_attrs with DMA_ATTR_NON_CONSISTENT API, that is rather
> badly defined.
>
> (2) Add support for DMA_ATTR_NO_KERNEL_MAPPING to this new API instead
> of dma_alloc_attrs. The initial difference with that flag is just
> that we allow highmem, but in the future we could also unmap this
> memory from the kernel linear mapping entirely on architectures
> where we can easily do that.
>
> (3) Add a dma_pages_map/dma_pages_unmap or similar API that allows you
> to get a kernel mapping for parts or all of a
> DMA_ATTR_NO_KERNEL_MAPPING allocation. This is to replace things
> like your open-coded vmap in msm (or similarly elsewhere in dma-buf
> providers).
>
> (4) Add support for a DMA_ATTR_UNCACHABLE flags (or similar) to the new
> API, that maps the pages as uncachable iff they have a kernel
> mapping, including invalidating the caches at time of this page
> attribute change (or creation of a new mapping). This API will fail
> if the architecture does not allow in-place remapping. Note that for
> arm32 we could always dip into the CMA pool if one is present to not
> fail. We'll also need some helper to map from the DMA_ATTR_* flags
> to a pgprot for mapping the page to userspace. There is also a few
> other weird bits here, e.g. on architectures like mips that use an
> uncached segment we'll have to fail use with the plain
> DMA_ATTR_UNCACHABLE flag, but it could be supported with
> DMA_ATTR_UNCACHABLE | DMA_ATTR_NO_KERNEL_MAPPING.
>
> I was hoping to get most of this done for this merge window, but I'm
> probably lucky if I get at least parts done. Too much distraction.
>
> > Hmm, not entirely sure why.. you should be on the cc list for each
> > individual patch.
>
> They finally made it, although even with the delay they only ended up
> in the spam mailbox. I still can't see them on the various mailing
> lists.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/2] arm64: dts: allwinner: h6: Introduce Tanix TX6 board
From: Jernej Skrabec @ 2019-08-16 20:53 UTC (permalink / raw)
To: robh+dt, mark.rutland, mripard, wens
Cc: devicetree, jernej.skrabec, linux-kernel, linux-arm-kernel
In-Reply-To: <20190816205342.29552-1-jernej.skrabec@siol.net>
Tanix TX6 is an Allwinner H6 based TV box, which supports:
- Allwinner H6 Quad-core 64-bit ARM Cortex-A53
- GPU Mali-T720
- 4GiB DDR3 RAM (3GiB useable)
- 100Mbps EMAC via AC200 EPHY
- Cdtech 47822BS Wifi/BT
- 2x USB 2.0 Host and 1x USB 3.0 Host
- HDMI port
- IR receiver
- 64GiB eMMC
- 5V/2A DC power supply
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
arch/arm64/boot/dts/allwinner/Makefile | 1 +
.../dts/allwinner/sun50i-h6-tanix-tx6.dts | 100 ++++++++++++++++++
2 files changed, 101 insertions(+)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h6-tanix-tx6.dts
diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
index f6db0611cb85..395fe76f6819 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -25,3 +25,4 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-3.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-lite2.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-one-plus.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-tanix-tx6.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-tanix-tx6.dts
new file mode 100644
index 000000000000..7e7cb10e3d96
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-tanix-tx6.dts
@@ -0,0 +1,100 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+/*
+ * Copyright (c) 2019 Jernej Skrabec <jernej.skrabec@siol.net>
+ */
+
+/dts-v1/;
+
+#include "sun50i-h6.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+ model = "Tanix TX6";
+ compatible = "oranth,tanix-tx6", "allwinner,sun50i-h6";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ connector {
+ compatible = "hdmi-connector";
+ ddc-en-gpios = <&pio 7 2 GPIO_ACTIVE_HIGH>; /* PH2 */
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <&hdmi_out_con>;
+ };
+ };
+ };
+
+ reg_vcc3v3: vcc3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+};
+
+&de {
+ status = "okay";
+};
+
+&ehci0 {
+ status = "okay";
+};
+
+&ehci3 {
+ status = "okay";
+};
+
+&hdmi {
+ status = "okay";
+};
+
+&hdmi_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <&hdmi_con_in>;
+ };
+};
+
+&mmc0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins>;
+ vmmc-supply = <®_vcc3v3>;
+ cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>;
+ bus-width = <4>;
+ status = "okay";
+};
+
+&ohci0 {
+ status = "okay";
+};
+
+&ohci3 {
+ status = "okay";
+};
+
+&r_ir {
+ status = "okay";
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_ph_pins>;
+ status = "okay";
+};
+
+&usb2otg {
+ dr_mode = "host";
+ status = "okay";
+};
+
+&usb2phy {
+ status = "okay";
+};
--
2.22.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 0/2] Introduce Tanix TX6 box DT
From: Jernej Skrabec @ 2019-08-16 20:53 UTC (permalink / raw)
To: robh+dt, mark.rutland, mripard, wens
Cc: devicetree, jernej.skrabec, linux-kernel, linux-arm-kernel
This series adds support for Tanix TX6 box:
- Allwinner H6 Quad-core 64-bit ARM Cortex-A53
- GPU Mali-T720
- 4GiB DDR3 RAM (3GiB useable)
- 100Mbps EMAC via AC200 EPHY
- Cdtech 47822BS Wifi/BT
- 2x USB 2.0 Host and 1x USB 3.0 Host
- HDMI port
- IR receiver
- 64GiB eMMC
- 5V/2A DC power supply
Patch 1 adds compatible strings to dt bindings documentation.
Patch 2 adds Tanix TX6 DT.
Best regards,
Jernej
Jernej Skrabec (2):
dt-bindings: arm: sunxi: Add compatible for Tanix TX6 board
arm64: dts: allwinner: h6: Introduce Tanix TX6 board
.../devicetree/bindings/arm/sunxi.yaml | 5 +
arch/arm64/boot/dts/allwinner/Makefile | 1 +
.../dts/allwinner/sun50i-h6-tanix-tx6.dts | 100 ++++++++++++++++++
3 files changed, 106 insertions(+)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h6-tanix-tx6.dts
--
2.22.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/2] dt-bindings: arm: sunxi: Add compatible for Tanix TX6 board
From: Jernej Skrabec @ 2019-08-16 20:53 UTC (permalink / raw)
To: robh+dt, mark.rutland, mripard, wens
Cc: devicetree, jernej.skrabec, linux-kernel, linux-arm-kernel
In-Reply-To: <20190816205342.29552-1-jernej.skrabec@siol.net>
Add new Oranth Tanix TX6 board compatible string to the bindings
documentation.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
Documentation/devicetree/bindings/arm/sunxi.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
index 000a00d12d6a..6afeb1be3a44 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.yaml
+++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
@@ -671,6 +671,11 @@ properties:
- const: sinlinx,sina33
- const: allwinner,sun8i-a33
+ - description: Tanix TX6
+ items:
+ - const: oranth,tanix-tx6
+ - const: allwinner,sun50i-h6
+
- description: TBS A711 Tablet
items:
- const: tbs-biometrics,a711
--
2.22.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 4/3] pwm: atmel: document known weaknesses of both hardware and software
From: Alexandre Belloni @ 2019-08-16 20:43 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: linux-pwm, Ludovic Desroches, Thierry Reding, Claudiu Beznea,
linux-arm-kernel
In-Reply-To: <20190816093748.11769-1-uwe@kleine-koenig.org>
On 16/08/2019 11:37:48+0200, Uwe Kleine-König wrote:
> Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
> ---
> drivers/pwm/pwm-atmel.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
> index 42fe7bc043a8..1ddb93db9627 100644
> --- a/drivers/pwm/pwm-atmel.c
> +++ b/drivers/pwm/pwm-atmel.c
> @@ -7,6 +7,16 @@
> *
> * Reference manual for "atmel,at91sam9rl-pwm":
> * http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-11032-32-bit-ARM926EJ-S-Microcontroller-SAM9G25_Datasheet.pdf
> + *
> + * Limitations:
> + * - Periods start with the inactive level.
> + * - Hardware has to be stopped in general to update settings.
> + *
> + * Software bugs/possible improvements:
> + * - When atmel_pwm_apply() is called with state->enabled=false a change in
> + * state->polarity isn't honored.
> + * - Instead of sleeping to wait for a completed period, the interrupt
> + * functionality could be used.
This is definitively not trivial to do right. The main reason it is not
done so is that reading PWM_ISR will clear all the bits so it is
necessary to be very careful to avoid race conditions. I'm not sure it
is worth the effort.
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] updates to soc/fsl drivers for v5.4
From: Li Yang @ 2019-08-16 19:53 UTC (permalink / raw)
To: arm, soc; +Cc: shawnguo, linux-kernel, linux-arm-kernel
Hi arm-soc maintainers,
Please look into the following changes and merge them if they
look good.
Regards,
Leo
The following changes since commit 157eed91b374c42eb264157366daf3dabc8bc816:
Merge tag 'tee-optee-for-5.4' of git://git.linaro.org/people/jens.wiklander/linux-tee into arm/drivers (2019-08-15 14:29:43 +0200)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/leo/linux.git tags/soc-fsl-next-v5.4
for you to fetch changes up to eadf0b17b43db4e73a6bdde1ad745d3b582a71c5:
bus: fsl-mc: remove explicit device_link_del (2019-08-16 14:17:35 -0500)
----------------------------------------------------------------
NXP/FSL SoC driver updates for v5.4
DPAA2 DPIO/MC driver
- Remove explicit device_link_remove() and device_link_del() calls due to
framework change
DPAA QBman driver
- Various changes to make it working with kexec
- Remove dev_err() usage after platform_get_irq()
GUTS driver
- Add LS1028 SoC support
----------------------------------------------------------------
Ioana Ciornei (2):
soc: fsl: dpio: remove explicit device_link_remove
bus: fsl-mc: remove explicit device_link_del
Roy Pledge (7):
soc/fsl/qbman: Rework QBMan private memory setup
soc/fsl/qbman: Cleanup buffer pools if BMan was initialized prior to bootup
soc/fsl/qbman: Cleanup QMan queues if device was already initialized
soc/fsl/qbman: Fix drain_mr_fqni()
soc/fsl/qbman: Disable interrupts during portal recovery
soc/fsl/qbman: Fixup qman_shutdown_fq()
soc/fsl/qbman: Update device tree with reserved memory
Stephen Boyd (1):
soc: fsl: qbman: Remove dev_err() usage after platform_get_irq()
Yinbo Zhu (1):
soc: fsl: guts: Add definition for LS1028A
drivers/bus/fsl-mc/fsl-mc-allocator.c | 1 -
drivers/bus/fsl-mc/mc-io.c | 1 -
drivers/soc/fsl/dpio/dpio-service.c | 2 -
drivers/soc/fsl/guts.c | 6 +++
drivers/soc/fsl/qbman/bman.c | 17 +++----
drivers/soc/fsl/qbman/bman_ccsr.c | 36 ++++++++++++++-
drivers/soc/fsl/qbman/bman_portal.c | 22 ++++++++--
drivers/soc/fsl/qbman/bman_priv.h | 5 +++
drivers/soc/fsl/qbman/dpaa_sys.c | 63 +++++++++++++++-----------
drivers/soc/fsl/qbman/qman.c | 83 ++++++++++++++++++++++++++++-------
drivers/soc/fsl/qbman/qman_ccsr.c | 68 +++++++++++++++++++++++++---
drivers/soc/fsl/qbman/qman_portal.c | 22 ++++++++--
drivers/soc/fsl/qbman/qman_priv.h | 8 ++++
13 files changed, 263 insertions(+), 71 deletions(-)
_______________________________________________
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 1/2] dt-bindings: i2c: mv64xxx: Add compatible for the H6 i2c node.
From: Rob Herring @ 2019-08-16 19:44 UTC (permalink / raw)
To: Bhushan Shah
Cc: Mark Rutland, devicetree, Wolfram Sang, Maxime Ripard,
Gregory CLEMENT, linux-kernel@vger.kernel.org, Chen-Yu Tsai,
Linux I2C,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Icenowy Zheng
In-Reply-To: <20190816084309.27440-2-bshah@kde.org>
On Fri, Aug 16, 2019 at 2:44 AM Bhushan Shah <bshah@kde.org> wrote:
>
> Allwinner H6 have a mv64xxx i2c interface available to be used.
>
> Signed-off-by: Bhushan Shah <bshah@kde.org>
> ---
>
> Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml | 3 +++
> 1 file changed, 3 insertions(+)
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [Freedreno] [PATCH v3 0/2] iommu/arm-smmu: Split pagetable support
From: Robin Murphy @ 2019-08-16 19:43 UTC (permalink / raw)
To: Rob Clark, Jordan Crouse
Cc: Rob Herring, Jean-Philippe Brucker, Will Deacon, Joerg Roedel,
Zhen Lei, Linux Kernel Mailing List, iommu, linux-arm-msm,
freedreno,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAF6AEGujjF+MQFw45g799i+2QE4X=eRZdDSsD_F3y3mfbc6UPw@mail.gmail.com>
On 16/08/2019 19:12, Rob Clark wrote:
> On Fri, Aug 16, 2019 at 9:58 AM Robin Murphy <robin.murphy@arm.com> wrote:
>>
>> Hi Jordan,
>>
>> On 15/08/2019 16:33, Jordan Crouse wrote:
>>> On Wed, Aug 07, 2019 at 04:21:38PM -0600, Jordan Crouse wrote:
>>>> (Sigh, resend. I freaked out my SMTP server)
>>>>
>>>> This is part of an ongoing evolution for enabling split pagetable support for
>>>> arm-smmu. Previous versions can be found [1].
>>>>
>>>> In the discussion for v2 Robin pointed out that this is a very Adreno specific
>>>> use case and that is exactly true. Not only do we want to configure and use a
>>>> pagetable in the TTBR1 space, we also want to configure the TTBR0 region but
>>>> not allocate a pagetable for it or touch it until the GPU hardware does so. As
>>>> much as I want it to be a generic concept it really isn't.
>>>>
>>>> This revision leans into that idea. Most of the same io-pgtable code is there
>>>> but now it is wrapped as an Adreno GPU specific format that is selected by the
>>>> compatible string in the arm-smmu device.
>>>>
>>>> Additionally, per Robin's suggestion we are skipping creating a TTBR0 pagetable
>>>> to save on wasted memory.
>>>>
>>>> This isn't as clean as I would like it to be but I think that this is a better
>>>> direction than trying to pretend that the generic format would work.
>>>>
>>>> I'm tempting fate by posting this and then taking some time off, but I wanted
>>>> to try to kick off a conversation or at least get some flames so I can try to
>>>> refine this again next week. Please take a look and give some advice on the
>>>> direction.
>>>
>>> Will, Robin -
>>>
>>> Modulo the impl changes from Robin, do you think that using a dedicated
>>> pagetable format is the right approach for supporting split pagetables for the
>>> Adreno GPU?
>>
>> How many different Adreno drivers would benefit from sharing it?
>
> Hypothetically everything back to a3xx, so I *could* see usefulness of
> this in qcom_iommu (or maybe even msm-iommu). OTOH maybe with
> "modularizing" arm-smmu we could re-combine qcom_iommu and arm-smmu.
Indeed, that's certainly something I'm planning to investigate as a
future refactoring step.
> And as a practical matter, I'm not sure if anyone will get around to
> backporting per-context pagetables as far back as a3xx.
>
> BR,
> -R
>
>> The more I come back to this, the more I'm convinced that io-pgtable
>> should focus on the heavy lifting of pagetable management - the code
>> that nobody wants to have to write at all, let alone more than once -
>> and any subtleties which aren't essential to that should be pushed back
>> into whichever callers actually care. Consider that already, literally
>> no caller actually uses an unmodified stage 1 TCR value as provided in
>> the io_pgtable_cfg.
>>
>> I feel it would be most productive to elaborate further in the form of
>> patches, so let me get right on that and try to bash something out
>> before I go home tonight...
...and now there's a rough WIP branch here:
http://linux-arm.org/git?p=linux-rm.git;a=shortlog;h=refs/heads/iommu/pgtable
I'll finish testing and polishing those patches at some point next week,
probably, but hopefully they're sufficiently illustrative for the moment.
Robin.
_______________________________________________
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 v1 0/8] arm64: MMU enabled kexec relocation
From: Pavel Tatashin @ 2019-08-16 19:19 UTC (permalink / raw)
To: James Morse
Cc: Sasha Levin, Vladimir Murzin, Jonathan Corbet, Marc Zyngier,
Catalin Marinas, Bhupesh Sharma, kexec mailing list, LKML,
James Morris, linux-mm, Eric W. Biederman, Matthias Brugger, will,
Linux ARM
In-Reply-To: <746ceee3-43a7-231d-b2f6-0991a4148a28@arm.com>
Hi James,
Thank you for your feedback, my replies below:
> > It is not really an all-new implementation of hibernate (for kexec it
> > is true though). I used the current implementation of hibernate as
> > bases, and simply generalized the functions by providing a flexible
> > interface. So what you are asking is actually exactly what I am doing.
>
> I disagree. The resume page-table code is the bulk of the complexity in hibernate.c. Your
> first patch dumps ~200 lines of differently-complex code, and your second switches
> hibernate over to it.
OK, I will make the change incremental.
>
> Instead, please move that code, keeping it as it is. git will spot the move, and the
> generated diffstat should only reflect the build-system changes. You don't need to 'switch
> hibernate to transitional page tables.'
>
> Adding kexec will then show-up what needs changing, each change comes with a commit
> message explaining why. Having these as 'generalisations' in the first patch is a mess.
Makes sense, I will fix it.
>
> There is existing code that we don't want to break. Any changes need to be done as a
> sequence of small incremental changes. It can't be reviewed any other way.
>
>
> > I realize, that I introduced a bug that I will fix.
>
> Done as a sequence of small incremental changes, I could bisect it to the patch that
> introduces the bug, and probably fix it from the description in the commit message.
BTW, I root caused it, there were two trivial errors:
1. In "arm64, mm: transitional tables"
int i = pgd_index(addr);
In trans_table_copy_*:
should be: pte_index(), pmd_index(), pud_index(), accordingly.
2. In trans_table_create_copy()
pgd_offset_k(PAGE_OFFSET) should be: mm_init.pgd
> >> It looks like you are creating the page tables just after the kexec:segments have been
> >> loaded. This will go horribly wrong if anything changes between then and kexec time. (e.g.
> >> memory you've got mapped gets hot-removed).
> >> This needs to be done as late as possible, so we don't waste memory, and the world can't
> >> change around us. Reboot notifiers run before kexec, can't we do the memory-allocation there?
>
> > Kexec by design does not allow allocate during kexec time. This is
> > because we cannot fail during kexec syscall.
>
> This problem needs solving.
>
> | Reboot notifiers run before kexec, can't we do the memory-allocation there?
>
>
> > All allocations must be done during kexec load time.
>
> This increases the memory footprint. I don't think we should waste ~2MB per GB of kernel
> memory on this feature. (Assuming 4K pages and rodata_full)
>
> Another option is to allocate this memory at load time, but then free it so it can be used
> in the meantime. You can keep the list of allocated pfn, as we know they aren't in use by
> the running kernel, kexec metadata, loaded images etc.
This is until a new kernel module is loaded, I do not think this is safe to do.
In my opinion 2M per 1 GB is a fair trade off for a faster kexec
performance. Unlike with crash kexec for which we do not add any
memory useage, the kernel does not have to be all the time in memory,
but can be loaded by user before reboot. If machine is so scare on
memory resources that 2M per 1G matters, user simply won't keep new
kernel in memory until it is actually needed.
>
> Memory hotplug would need handling carefully, as would anything that 'donates' memory to
> another agent. (I suspect the TEE stuff does this, I don't know how it interacts with kexec)
>
>
> > Kernel memory cannot be hot-removed, as
> > it is not part of ZONE_MOVABLE, and cannot be migrated.
>
> Today, yes. Tomorrow?, "arm64/mm: Enable memory hot remove":
> https://lore.kernel.org/r/1563171470-3117-1-git-send-email-anshuman.khandual@arm.com
I understand that ARM64 is about to get hot-remove feature, but what I
am saying is that my feature does not introduce new problem because
the current kexec code assumes that kernel memory is not movable
(array of sparse physical source dest addresses in kimage->head). It
is possible to offline and hot-remove only memory that can be freed by
page migration, the pages that were allocated for kexec kernel are not
one of them.
> >>>> Previously:
> >>>> kernel shutdown 0.022131328s
> >>>> relocation 0.440510736s
> >>>> kernel startup 0.294706768s
> >>>>
> >>>> Relocation was taking: 58.2% of reboot time
> >>>>
> >>>> Now:
> >>>> kernel shutdown 0.032066576s
> >>>> relocation 0.022158152s
> >>>> kernel startup 0.296055880s
> >>>>
> >>>> Now: Relocation takes 6.3% of reboot time
> >>>>
> >>>> Total reboot is x2.16 times faster.
> >>
> >> When I first saw these numbers they were ~'0.29s', which I wrongly assumed was 29 seconds.
> >> Savings in milliseconds, for _reboot_ is a hard sell. I'm hoping that on the machines that
> >> take minutes to kexec we'll get numbers that make this change more convincing.
>
> > Sure, this userland is very small kernel+userland is only 47M. Here is
> > another data point: fitImage: 380M, it contains a larger userland.
> > The numbers for kernel shutdown and startup are the same as this is
> > the same kernel, but relocation takes: 3.58s
> > shutdown: 0.02s
> > relocation: 3.58s
> > startup: 0.30s
> >
> > Relocation take 88% of reboot time. And, we must have it under one second.
>
> Where does this one second number come from? (was it ever a reasonable starting point?)
Currently we have two fitImages for this system in development: one
that has a bare minimal userland, only ~40 packages, and another has a
more complete userland. So, my first experiment shows the data from
this first bare minimum ftImage, the second experiment from the second
more complete fitImage. As I stated in cover letter, kexec time is
proportional to the size of the image and this series fixes this
scalability issue by making relocation ~20 times faster.
Pasha
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: aarch64 Kernel Panic Asynchronous SError Interrupt on large file IO
From: Philipp Richter @ 2019-08-16 18:54 UTC (permalink / raw)
To: Robin Murphy
Cc: heiko, catalin.marinas, vicencb, linux-rockchip, andre.przywara,
Will Deacon, linux-arm-kernel
In-Reply-To: <2facb3cb-388a-87ee-4d87-717dd65825ae@arm.com>
On Fri, 16 Aug 2019 at 14:01, Robin Murphy <robin.murphy@arm.com> wrote:
>
> This does start to smell like some issue with that particular area of
> physical memory - either because it's been marked as Secure-only by
> firmware and the controller configured to abort Non-Secure accesses, or
> possibly because of an actual DRAM failure. The next thing I'd do is
> have a play around with the "memtest=..." kernel parameter to see if
> that can consistently find a problem, and see if the firmware change
> that Heiko pointed out makes any difference.
>
> Robin.
Thank you very much for this insight.
I compiled u-boot with the patch that Heiko Stübner linked to and
rewrote the images to the target locations but this didn't resolve the
problem.
I'll try some memtests but the stock Archlinux ARM kernel does not
have it enabled so I'll need to compile it in myself then I guess.
Regards,
Philipp Richter
_______________________________________________
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 05/19] irqchip/mmp: do not use of_address_to_resource() to get mux regs
From: Lubomir Rintel @ 2019-08-16 18:41 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, Pavel Machek,
Thomas Gleixner, linux-clk, linux-arm-kernel
In-Reply-To: <16d77ca3-7ad1-3af2-650e-722cf6a931ed@kernel.org>
On Fri, 2019-08-09 at 13:12 +0100, Marc Zyngier wrote:
> On 09/08/2019 10:31, Lubomir Rintel wrote:
> > The "regs" property of the "mrvl,mmp2-mux-intc" devices are silly. They
> > are offsets from intc's base, not addresses on the parent bus. At this
> > point it probably can't be fixed.
> >
> > On an OLPC XO-1.75 machine, the muxes are children of the intc, not the
> > axi bus, and thus of_address_to_resource() won't work. We should treat
> > the values as mere integers as opposed to bus addresses.
> >
> > Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
> > Acked-by: Pavel Machek <pavel@ucw.cz>
> >
> > ---
> > drivers/irqchip/irq-mmp.c | 20 +++++++++++---------
> > 1 file changed, 11 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/irqchip/irq-mmp.c b/drivers/irqchip/irq-mmp.c
> > index 14618dc0bd396..af9cba4a51c2e 100644
> > --- a/drivers/irqchip/irq-mmp.c
> > +++ b/drivers/irqchip/irq-mmp.c
> > @@ -424,9 +424,9 @@ IRQCHIP_DECLARE(mmp2_intc, "mrvl,mmp2-intc", mmp2_of_init);
> > static int __init mmp2_mux_of_init(struct device_node *node,
> > struct device_node *parent)
> > {
> > - struct resource res;
> > int i, ret, irq, j = 0;
> > u32 nr_irqs, mfp_irq;
> > + u32 reg[4];
> >
> > if (!parent)
> > return -ENODEV;
> > @@ -438,18 +438,20 @@ static int __init mmp2_mux_of_init(struct device_node *node,
> > pr_err("Not found mrvl,intc-nr-irqs property\n");
> > return -EINVAL;
> > }
> > - ret = of_address_to_resource(node, 0, &res);
> > +
> > + /*
> > + * For historical reasonsm, the "regs" property of the
> > + * mrvl,mmp2-mux-intc is not a regular * "regs" property containing
> > + * addresses on the parent bus, but offsets from the intc's base.
> > + * That is why we can't use of_address_to_resource() here.
> > + */
> > + ret = of_property_read_u32_array(node, "reg", reg, ARRAY_SIZE(reg));
>
> This will return 0 even if you've read less than your expected 4 u32s.
> You may want to try of_property_read_variable_u32_array instead.
Will it? Unless I'm reading the of_property_read_u32_array()
documentation wrong, it suggests that would return -EOVERFLOW in that
case.
It ignores the extra values it the property is larger. I guess that is
not a good thing and we still want to use
of_property_read_variable_u32_array() though.
> > if (ret < 0) {
> > pr_err("Not found reg property\n");
> > return -EINVAL;
> > }
> > - icu_data[i].reg_status = mmp_icu_base + res.start;
> > - ret = of_address_to_resource(node, 1, &res);
> > - if (ret < 0) {
> > - pr_err("Not found reg property\n");
> > - return -EINVAL;
> > - }
> > - icu_data[i].reg_mask = mmp_icu_base + res.start;
> > + icu_data[i].reg_status = mmp_icu_base + reg[0];
> > + icu_data[i].reg_mask = mmp_icu_base + reg[2];
> > icu_data[i].cascade_irq = irq_of_parse_and_map(node, 0);
> > if (!icu_data[i].cascade_irq)
> > return -EINVAL;
> >
>
> Thanks,
>
> M.
Thanks
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 v1 0/8] arm64: MMU enabled kexec relocation
From: James Morse @ 2019-08-16 18:17 UTC (permalink / raw)
To: Pavel Tatashin
Cc: Sasha Levin, Vladimir Murzin, Jonathan Corbet, Marc Zyngier,
Catalin Marinas, Bhupesh Sharma, kexec mailing list, LKML,
James Morris, linux-mm, Eric W. Biederman, Matthias Brugger, will,
Linux ARM
In-Reply-To: <CA+CK2bAqBi43Cchr=md7EPRuEWH-iuToK0PxN3ysSBQ42Hd0-g@mail.gmail.com>
Hi Pavel,
On 15/08/2019 21:09, Pavel Tatashin wrote:
>>> Also, I'd appreciate if anyone could test this series on vhe hardware
>>> with vhe kernel, it does not look like QEMU can emulate it yet
>>
>> This locks up during resume from hibernate on my AMD Seattle, a regular v8.0 machine.
>
> Thanks for reporting a bug I will root cause and fix it.
>> Please try and build the series to reduce review time. What you have here is an all-new
>> page-table generation API, which you switch hibernate and kexec too. This is effectively a
>> new implementation of hibernate and kexec. There are three things here that need review.
>>
>> You have a regression in your all-new implementation of hibernate. It took six months (and
>> lots of review) to get the existing code right, please don't rip it out if there is
>> nothing wrong with it.
>
>> Instead, please just move the hibernate copy_page_tables() code, and then wire kexec up.
>> You shouldn't need to change anything in the copy_page_tables() code as the linear map is
>> the same in both cases.
> It is not really an all-new implementation of hibernate (for kexec it
> is true though). I used the current implementation of hibernate as
> bases, and simply generalized the functions by providing a flexible
> interface. So what you are asking is actually exactly what I am doing.
I disagree. The resume page-table code is the bulk of the complexity in hibernate.c. Your
first patch dumps ~200 lines of differently-complex code, and your second switches
hibernate over to it.
Instead, please move that code, keeping it as it is. git will spot the move, and the
generated diffstat should only reflect the build-system changes. You don't need to 'switch
hibernate to transitional page tables.'
Adding kexec will then show-up what needs changing, each change comes with a commit
message explaining why. Having these as 'generalisations' in the first patch is a mess.
There is existing code that we don't want to break. Any changes need to be done as a
sequence of small incremental changes. It can't be reviewed any other way.
> I realize, that I introduced a bug that I will fix.
Done as a sequence of small incremental changes, I could bisect it to the patch that
introduces the bug, and probably fix it from the description in the commit message.
>> It looks like you are creating the page tables just after the kexec:segments have been
>> loaded. This will go horribly wrong if anything changes between then and kexec time. (e.g.
>> memory you've got mapped gets hot-removed).
>> This needs to be done as late as possible, so we don't waste memory, and the world can't
>> change around us. Reboot notifiers run before kexec, can't we do the memory-allocation there?
> Kexec by design does not allow allocate during kexec time. This is
> because we cannot fail during kexec syscall.
This problem needs solving.
| Reboot notifiers run before kexec, can't we do the memory-allocation there?
> All allocations must be done during kexec load time.
This increases the memory footprint. I don't think we should waste ~2MB per GB of kernel
memory on this feature. (Assuming 4K pages and rodata_full)
Another option is to allocate this memory at load time, but then free it so it can be used
in the meantime. You can keep the list of allocated pfn, as we know they aren't in use by
the running kernel, kexec metadata, loaded images etc.
Memory hotplug would need handling carefully, as would anything that 'donates' memory to
another agent. (I suspect the TEE stuff does this, I don't know how it interacts with kexec)
> Kernel memory cannot be hot-removed, as
> it is not part of ZONE_MOVABLE, and cannot be migrated.
Today, yes. Tomorrow?, "arm64/mm: Enable memory hot remove":
https://lore.kernel.org/r/1563171470-3117-1-git-send-email-anshuman.khandual@arm.com
>>>> Previously:
>>>> kernel shutdown 0.022131328s
>>>> relocation 0.440510736s
>>>> kernel startup 0.294706768s
>>>>
>>>> Relocation was taking: 58.2% of reboot time
>>>>
>>>> Now:
>>>> kernel shutdown 0.032066576s
>>>> relocation 0.022158152s
>>>> kernel startup 0.296055880s
>>>>
>>>> Now: Relocation takes 6.3% of reboot time
>>>>
>>>> Total reboot is x2.16 times faster.
>>
>> When I first saw these numbers they were ~'0.29s', which I wrongly assumed was 29 seconds.
>> Savings in milliseconds, for _reboot_ is a hard sell. I'm hoping that on the machines that
>> take minutes to kexec we'll get numbers that make this change more convincing.
> Sure, this userland is very small kernel+userland is only 47M. Here is
> another data point: fitImage: 380M, it contains a larger userland.
> The numbers for kernel shutdown and startup are the same as this is
> the same kernel, but relocation takes: 3.58s
> shutdown: 0.02s
> relocation: 3.58s
> startup: 0.30s
>
> Relocation take 88% of reboot time. And, we must have it under one second.
Where does this one second number come from? (was it ever a reasonable starting point?)
Thanks,
James
_______________________________________________
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 07/19] irqchip/mmp: mask off interrupts from other cores
From: Lubomir Rintel @ 2019-08-16 18:15 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, Andres Salomon,
Thomas Gleixner, linux-clk, linux-arm-kernel
In-Reply-To: <19a21c54-93ac-19dc-d679-8d376d44e68c@kernel.org>
On Fri, 2019-08-09 at 13:18 +0100, Marc Zyngier wrote:
> On 09/08/2019 10:31, Lubomir Rintel wrote:
> > From: Andres Salomon <dilinger@queued.net>
> >
> > On mmp3, there's an extra set of ICU registers (ICU2) that handle
> > interrupts on the extra cores. When masking off interrupts on MP1,
> > these should be masked as well.
> >
> > We add a new interrupt controller via device tree to identify when we're
> > looking at an mmp3 machine via compatible field of "marvell,mmp3-intc".
> >
> > [lkundrak@v3.sk: Changed "mrvl,mmp3-intc" compatible strings to
> > "marvell,mmp3-intc". Tidied up the subject line a bit.]
> >
> > Signed-off-by: Andres Salomon <dilinger@queued.net>
> > Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
> >
> > ---
> > arch/arm/mach-mmp/regs-icu.h | 3 +++
> > drivers/irqchip/irq-mmp.c | 51 ++++++++++++++++++++++++++++++++++++
> > 2 files changed, 54 insertions(+)
> >
> > diff --git a/arch/arm/mach-mmp/regs-icu.h b/arch/arm/mach-mmp/regs-icu.h
> > index 0375d5a7fcb2b..410743d2b4020 100644
> > --- a/arch/arm/mach-mmp/regs-icu.h
> > +++ b/arch/arm/mach-mmp/regs-icu.h
> > @@ -11,6 +11,9 @@
> > #define ICU_VIRT_BASE (AXI_VIRT_BASE + 0x82000)
> > #define ICU_REG(x) (ICU_VIRT_BASE + (x))
> >
> > +#define ICU2_VIRT_BASE (AXI_VIRT_BASE + 0x84000)
> > +#define ICU2_REG(x) (ICU2_VIRT_BASE + (x))
> > +
> > #define ICU_INT_CONF(n) ICU_REG((n) << 2)
> > #define ICU_INT_CONF_MASK (0xf)
> >
> > diff --git a/drivers/irqchip/irq-mmp.c b/drivers/irqchip/irq-mmp.c
> > index cd8d2253f56d1..25497c75cc861 100644
> > --- a/drivers/irqchip/irq-mmp.c
> > +++ b/drivers/irqchip/irq-mmp.c
> > @@ -44,6 +44,7 @@ struct icu_chip_data {
> > unsigned int conf_enable;
> > unsigned int conf_disable;
> > unsigned int conf_mask;
> > + unsigned int conf2_mask;
> > unsigned int clr_mfp_irq_base;
> > unsigned int clr_mfp_hwirq;
> > struct irq_domain *domain;
> > @@ -53,9 +54,11 @@ struct mmp_intc_conf {
> > unsigned int conf_enable;
> > unsigned int conf_disable;
> > unsigned int conf_mask;
> > + unsigned int conf2_mask;
> > };
> >
> > static void __iomem *mmp_icu_base;
> > +static void __iomem *mmp_icu2_base;
> > static struct icu_chip_data icu_data[MAX_ICU_NR];
> > static int max_icu_nr;
> >
> > @@ -98,6 +101,16 @@ static void icu_mask_irq(struct irq_data *d)
> > r &= ~data->conf_mask;
> > r |= data->conf_disable;
> > writel_relaxed(r, mmp_icu_base + (hwirq << 2));
> > +
> > + if (data->conf2_mask) {
> > + /*
> > + * ICU1 (above) only controls PJ4 MP1; if using SMP,
> > + * we need to also mask the MP2 and MM cores via ICU2.
> > + */
> > + r = readl_relaxed(mmp_icu2_base + (hwirq << 2));
> > + r &= ~data->conf2_mask;
> > + writel_relaxed(r, mmp_icu2_base + (hwirq << 2));
> > + }
> > } else {
> > r = readl_relaxed(data->reg_mask) | (1 << hwirq);
> > writel_relaxed(r, data->reg_mask);
> > @@ -201,6 +214,14 @@ static const struct mmp_intc_conf mmp2_conf = {
> > MMP2_ICU_INT_ROUTE_PJ4_FIQ,
> > };
> >
> > +static struct mmp_intc_conf mmp3_conf = {
> > + .conf_enable = 0x20,
> > + .conf_disable = 0x0,
> > + .conf_mask = MMP2_ICU_INT_ROUTE_PJ4_IRQ |
> > + MMP2_ICU_INT_ROUTE_PJ4_FIQ,
> > + .conf2_mask = 0xf0,
> > +};
> > +
> > static void __exception_irq_entry mmp_handle_irq(struct pt_regs *regs)
> > {
> > int hwirq;
> > @@ -364,6 +385,14 @@ static int __init mmp_init_bases(struct device_node *node)
> > pr_err("Failed to get interrupt controller register\n");
> > return -ENOMEM;
> > }
> > + if (of_device_is_compatible(node, "marvell,mmp3-intc")) {
>
> Instead of harcoding the compatible property once more, why don't you
> simply pass a flag from mmpx_of_init()?
Will do so in next version.
> > + mmp_icu2_base = of_iomap(node, 1);
> > + if (!mmp_icu2_base) {
> > + pr_err("Failed to get interrupt controller register #2\n");
> > + iounmap(mmp_icu_base);
> > + return -ENOMEM;
> > + }
> > + }
> >
> > icu_data[0].virq_base = 0;
> > icu_data[0].domain = irq_domain_add_linear(node, nr_irqs,
> > @@ -386,6 +415,8 @@ static int __init mmp_init_bases(struct device_node *node)
> > irq_dispose_mapping(icu_data[0].virq_base + i);
> > }
> > irq_domain_remove(icu_data[0].domain);
> > + if (of_device_is_compatible(node, "marvell,mmp3-intc"))
> > + iounmap(mmp_icu2_base);
> > iounmap(mmp_icu_base);
> > return -EINVAL;
> > }
> > @@ -428,6 +459,26 @@ static int __init mmp2_of_init(struct device_node *node,
> > }
> > IRQCHIP_DECLARE(mmp2_intc, "mrvl,mmp2-intc", mmp2_of_init);
> >
> > +static int __init mmp3_of_init(struct device_node *node,
> > + struct device_node *parent)
> > +{
> > + int ret;
> > +
> > + ret = mmp_init_bases(node);
> > + if (ret < 0)
> > + return ret;
> > +
> > + icu_data[0].conf_enable = mmp3_conf.conf_enable;
> > + icu_data[0].conf_disable = mmp3_conf.conf_disable;
> > + icu_data[0].conf_mask = mmp3_conf.conf_mask;
> > + icu_data[0].conf2_mask = mmp3_conf.conf2_mask;
> > + irq_set_default_host(icu_data[0].domain);
>
> Why do you need this? On a fully DT-ified platform, there should be no
> notion of a default domain.
I didn't know. Pretty sure this was cargo-culted, because it's done
elsewhere too and also unnecessary. Will remove those cases too.
> > + set_handle_irq(mmp2_handle_irq);
> > + max_icu_nr = 1;
> > + return 0;
> > +}
> > +IRQCHIP_DECLARE(mmp3_intc, "marvell,mmp3-intc", mmp3_of_init);
> > +
> > static int __init mmp2_mux_of_init(struct device_node *node,
> > struct device_node *parent)
> > {
> >
>
> Thanks,
>
> M.
Thanks
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: [Freedreno] [PATCH v3 0/2] iommu/arm-smmu: Split pagetable support
From: Rob Clark @ 2019-08-16 18:12 UTC (permalink / raw)
To: Robin Murphy
Cc: Rob Herring, Jean-Philippe Brucker, Will Deacon, Joerg Roedel,
Zhen Lei, Linux Kernel Mailing List,
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, ,
linux-arm-msm, freedreno,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <ac248f33-2528-c1d4-17ed-17e92e6ed5ad@arm.com>
On Fri, Aug 16, 2019 at 9:58 AM Robin Murphy <robin.murphy@arm.com> wrote:
>
> Hi Jordan,
>
> On 15/08/2019 16:33, Jordan Crouse wrote:
> > On Wed, Aug 07, 2019 at 04:21:38PM -0600, Jordan Crouse wrote:
> >> (Sigh, resend. I freaked out my SMTP server)
> >>
> >> This is part of an ongoing evolution for enabling split pagetable support for
> >> arm-smmu. Previous versions can be found [1].
> >>
> >> In the discussion for v2 Robin pointed out that this is a very Adreno specific
> >> use case and that is exactly true. Not only do we want to configure and use a
> >> pagetable in the TTBR1 space, we also want to configure the TTBR0 region but
> >> not allocate a pagetable for it or touch it until the GPU hardware does so. As
> >> much as I want it to be a generic concept it really isn't.
> >>
> >> This revision leans into that idea. Most of the same io-pgtable code is there
> >> but now it is wrapped as an Adreno GPU specific format that is selected by the
> >> compatible string in the arm-smmu device.
> >>
> >> Additionally, per Robin's suggestion we are skipping creating a TTBR0 pagetable
> >> to save on wasted memory.
> >>
> >> This isn't as clean as I would like it to be but I think that this is a better
> >> direction than trying to pretend that the generic format would work.
> >>
> >> I'm tempting fate by posting this and then taking some time off, but I wanted
> >> to try to kick off a conversation or at least get some flames so I can try to
> >> refine this again next week. Please take a look and give some advice on the
> >> direction.
> >
> > Will, Robin -
> >
> > Modulo the impl changes from Robin, do you think that using a dedicated
> > pagetable format is the right approach for supporting split pagetables for the
> > Adreno GPU?
>
> How many different Adreno drivers would benefit from sharing it?
Hypothetically everything back to a3xx, so I *could* see usefulness of
this in qcom_iommu (or maybe even msm-iommu). OTOH maybe with
"modularizing" arm-smmu we could re-combine qcom_iommu and arm-smmu.
And as a practical matter, I'm not sure if anyone will get around to
backporting per-context pagetables as far back as a3xx.
BR,
-R
> The more I come back to this, the more I'm convinced that io-pgtable
> should focus on the heavy lifting of pagetable management - the code
> that nobody wants to have to write at all, let alone more than once -
> and any subtleties which aren't essential to that should be pushed back
> into whichever callers actually care. Consider that already, literally
> no caller actually uses an unmodified stage 1 TCR value as provided in
> the io_pgtable_cfg.
>
> I feel it would be most productive to elaborate further in the form of
> patches, so let me get right on that and try to bash something out
> before I go home tonight...
>
> Robin.
>
> > If so, then is adding the changes to io-pgtable-arm.c possible for 5.4 and then
> > add the implementation specific code on top of Robin's stack later or do you
> > feel they should come as part of a package deal?
> >
> > Jordan
> >
> >> Jordan Crouse (2):
> >> iommu/io-pgtable-arm: Add support for ARM_ADRENO_GPU_LPAE io-pgtable
> >> format
> >> iommu/arm-smmu: Add support for Adreno GPU pagetable formats
> >>
> >> drivers/iommu/arm-smmu.c | 8 +-
> >> drivers/iommu/io-pgtable-arm.c | 214 ++++++++++++++++++++++++++++++++++++++---
> >> drivers/iommu/io-pgtable.c | 1 +
> >> include/linux/io-pgtable.h | 2 +
> >> 4 files changed, 209 insertions(+), 16 deletions(-)
> >>
> >> --
> >> 2.7.4
> >>
> >> _______________________________________________
> >> Freedreno mailing list
> >> Freedreno@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/freedreno
> >
> _______________________________________________
> Freedreno mailing list
> Freedreno@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
_______________________________________________
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 15/19] ARM: mmp: add SMP support
From: Florian Fainelli @ 2019-08-16 18:11 UTC (permalink / raw)
To: Lubomir Rintel, Olof Johansson
Cc: Mark Rutland, devicetree, Jason Cooper, Stephen Boyd,
Marc Zyngier, Michael Turquette, Russell King,
Kishon Vijay Abraham I, Rob Herring, linux-arm-kernel,
Thomas Gleixner, linux-clk, linux-kernel
In-Reply-To: <20190809093158.7969-16-lkundrak@v3.sk>
On 8/9/19 2:31 AM, Lubomir Rintel wrote:
> Used to bring up the second core on MMP3.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
> ---
> arch/arm/mach-mmp/Makefile | 3 +++
> arch/arm/mach-mmp/platsmp.c | 32 ++++++++++++++++++++++++++++++++
> 2 files changed, 35 insertions(+)
> create mode 100644 arch/arm/mach-mmp/platsmp.c
>
> diff --git a/arch/arm/mach-mmp/Makefile b/arch/arm/mach-mmp/Makefile
> index 322c1c97dc900..7b3a7f979eece 100644
> --- a/arch/arm/mach-mmp/Makefile
> +++ b/arch/arm/mach-mmp/Makefile
> @@ -22,6 +22,9 @@ ifeq ($(CONFIG_PM),y)
> obj-$(CONFIG_CPU_PXA910) += pm-pxa910.o
> obj-$(CONFIG_CPU_MMP2) += pm-mmp2.o
> endif
> +ifeq ($(CONFIG_SMP),y)
> +obj-$(CONFIG_MACH_MMP3_DT) += platsmp.o
> +endif
>
> # board support
> obj-$(CONFIG_MACH_ASPENITE) += aspenite.o
> diff --git a/arch/arm/mach-mmp/platsmp.c b/arch/arm/mach-mmp/platsmp.c
> new file mode 100644
> index 0000000000000..255df640b5bc1
> --- /dev/null
> +++ b/arch/arm/mach-mmp/platsmp.c
> @@ -0,0 +1,32 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) 2019 Lubomir Rintel <lkundrak@v3.sk>
> + */
> +#include <linux/io.h>
> +#include <asm/smp_scu.h>
> +#include <asm/smp.h>
> +#include "addr-map.h"
> +
> +#define SW_BRANCH_VIRT_ADDR CIU_REG(0x24)
> +
> +static int mmp3_boot_secondary(unsigned int cpu, struct task_struct *idle)
> +{
> + /*
> + * Apparently, the boot ROM on the second core spins on this
> + * register becoming non-zero and then jumps to the address written
> + * there. No IPIs involved.
> + */
> + __raw_writel(virt_to_phys(secondary_startup), SW_BRANCH_VIRT_ADDR);
You would want to use __pa_symbol() here (which is equivalent, but will
avoid barfing on you with CONFIG_DEBUG_VIRTUAL).
--
Florian
_______________________________________________
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 14/19] ARM: mmp: add support for MMP3 SoC
From: Stephen Boyd @ 2019-08-16 18:06 UTC (permalink / raw)
To: Lubomir Rintel, Olof Johansson
Cc: Mark Rutland, devicetree, Jason Cooper, Marc Zyngier,
Michael Turquette, Russell King, Kishon Vijay Abraham I,
Lubomir Rintel, Rob Herring, linux-arm-kernel, Thomas Gleixner,
linux-clk, linux-kernel
In-Reply-To: <20190809093158.7969-15-lkundrak@v3.sk>
Quoting Lubomir Rintel (2019-08-09 02:31:53)
> diff --git a/drivers/clk/mmp/Makefile b/drivers/clk/mmp/Makefile
> index 7bc7ac69391e3..deb069a4e4215 100644
> --- a/drivers/clk/mmp/Makefile
> +++ b/drivers/clk/mmp/Makefile
> @@ -9,6 +9,7 @@ obj-$(CONFIG_RESET_CONTROLLER) += reset.o
>
> obj-$(CONFIG_MACH_MMP_DT) += clk-of-pxa168.o clk-of-pxa910.o
> obj-$(CONFIG_MACH_MMP2_DT) += clk-of-mmp2.o
> +obj-$(CONFIG_MACH_MMP3_DT) += clk-of-mmp2.o
>
Maybe make a Kconfig variable in drivers/clk/mmp/Kconfig that builds
clk-of-mmp2.c and is selected by MACH_MMP*_DT?
> obj-$(CONFIG_CPU_PXA168) += clk-pxa168.o
> obj-$(CONFIG_CPU_PXA910) += clk-pxa910.o
_______________________________________________
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 6/6] arm64: document the choice of page attributes for pgprot_dmacoherent
From: Will Deacon @ 2019-08-16 18:05 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Shawn Anastasio, linux-m68k, Guan Xuetao, linuxppc-dev,
linux-kernel, Russell King, linux-mips, iommu, Geert Uytterhoeven,
Paul Burton, Catalin Marinas, James Hogan, Robin Murphy,
linux-arm-kernel
In-Reply-To: <20190816175942.GA4879@lst.de>
On Fri, Aug 16, 2019 at 07:59:42PM +0200, Christoph Hellwig wrote:
> On Fri, Aug 16, 2019 at 06:31:18PM +0100, Will Deacon wrote:
> > Mind if I tweak the second sentence to be:
> >
> > This is different from "Device-nGnR[nE]" memory which is intended for MMIO
> > and thus forbids speculation, preserves access size, requires strict
> > alignment and can also force write responses to come from the endpoint.
> >
> > ? It's a small change, but it better fits with the arm64 terminology
> > ("strongly ordered" is no longer used in the architecture).
> >
> > If you're happy with that, I can make the change and queue this patch
> > for 5.4.
>
> I'm fine with the change, but you really need this series as base,
> as there is no pgprot_dmacoherent before the series. So I think I'll
> have to queue it up if we want it for 5.4, and I'll need a few more
> reviews for the other patches in this series first.
Ah, I didn't think about the contextual stuff. In which case, with my
change in wording:
Acked-by: Will Deacon <will@kernel.org>
and feel free to route it with the rest.
Thanks,
Will
_______________________________________________
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] clk: imx8mn: fix int pll clk gate
From: Stephen Boyd @ 2019-08-16 18:02 UTC (permalink / raw)
To: mturquette, peng.fan, s.hauer, shawnguo
Cc: peng.fan, ping.bai, Anson.Huang, linux-kernel, linux-imx, kernel,
festevam, linux-clk, linux-arm-kernel, abel.vesa
In-Reply-To: <20190814015312.11711-1-peng.fan@nxp.com>
Quoting peng.fan@nxp.com (2019-08-13 18:53:12)
> From: Peng Fan <peng.fan@nxp.com>
>
> To Frac pll, the gate shift is 13, however to Int PLL the gate shift
> is 11.
>
> Cc: <stable@vger.kernel.org>
> Fixes: 96d6392b54db ("clk: imx: Add support for i.MX8MN clock driver")
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> Reviewed-by: Jacky Bai <ping.bai@nxp.com>
> ---
This is a fix for a change in -next. Why is stable Cced?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] arm64 fixes for 5.3-rc5
From: pr-tracker-bot @ 2019-08-16 18:00 UTC (permalink / raw)
To: Catalin Marinas; +Cc: will, Linus Torvalds, linux-kernel, linux-arm-kernel
In-Reply-To: <20190816172411.GA36979@arrakis.emea.arm.com>
The pull request you sent on Fri, 16 Aug 2019 18:24:13 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/b7e7c85dc7b0ea5ff821756c331489e3b151eed1
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
_______________________________________________
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 6/6] arm64: document the choice of page attributes for pgprot_dmacoherent
From: Christoph Hellwig @ 2019-08-16 17:59 UTC (permalink / raw)
To: Will Deacon
Cc: Shawn Anastasio, linux-m68k, Catalin Marinas, linuxppc-dev,
linux-kernel, Russell King, linux-mips, iommu, Geert Uytterhoeven,
Paul Burton, James Hogan, Guan Xuetao, Christoph Hellwig,
linux-arm-kernel, Robin Murphy
In-Reply-To: <20190816173118.4rbbzuogfamfa554@willie-the-truck>
On Fri, Aug 16, 2019 at 06:31:18PM +0100, Will Deacon wrote:
> Mind if I tweak the second sentence to be:
>
> This is different from "Device-nGnR[nE]" memory which is intended for MMIO
> and thus forbids speculation, preserves access size, requires strict
> alignment and can also force write responses to come from the endpoint.
>
> ? It's a small change, but it better fits with the arm64 terminology
> ("strongly ordered" is no longer used in the architecture).
>
> If you're happy with that, I can make the change and queue this patch
> for 5.4.
I'm fine with the change, but you really need this series as base,
as there is no pgprot_dmacoherent before the series. So I think I'll
have to queue it up if we want it for 5.4, and I'll need a few more
reviews for the other patches in this series first.
_______________________________________________
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 03/13] dt-bindings: bcm2835-cprman: Add bcm2711 support
From: Stephen Boyd @ 2019-08-16 17:41 UTC (permalink / raw)
To: Eric Anholt, Florian Fainelli, Mark Rutland, Michael Turquette,
Ray Jui, Rob Herring, Scott Branden, Stefan Wahren, Wolfram Sang
Cc: devicetree, Stefan Wahren, bcm-kernel-feedback-list,
linux-rpi-kernel, linux-clk, linux-arm-kernel, linux-i2c
In-Reply-To: <1565713248-4906-4-git-send-email-wahrenst@gmx.net>
Quoting Stefan Wahren (2019-08-13 09:20:38)
> The new BCM2711 supports an additional clock for the emmc2 block.
> So we need an additional compatible.
>
> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
> Acked-by: Eric Anholt <eric@anholt.net>
> ---
If you want, just send the clk patches (this and the next three) to me
and linux-clk list as a series. I will apply them directly once the
minor comments are fixed.
> Documentation/devicetree/bindings/clock/brcm,bcm2835-cprman.txt | 4 +++-
> include/dt-bindings/clock/bcm2835.h | 2 ++
> 2 files changed, 5 insertions(+), 1 deletion(-)
>
_______________________________________________
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 06/13] clk: bcm2835: Mark PLLD_PER as CRITICAL
From: Stephen Boyd @ 2019-08-16 17:39 UTC (permalink / raw)
To: Eric Anholt, Florian Fainelli, Mark Rutland, Michael Turquette,
Ray Jui, Rob Herring, Scott Branden, Stefan Wahren, Wolfram Sang
Cc: devicetree, Stefan Wahren, bcm-kernel-feedback-list,
linux-rpi-kernel, linux-clk, linux-arm-kernel, linux-i2c
In-Reply-To: <1565713248-4906-7-git-send-email-wahrenst@gmx.net>
Quoting Stefan Wahren (2019-08-13 09:20:41)
> The VPU firmware assume that the PLLD_PER isn't modified by the ARM core.
> Otherwise this could cause firmware lookups. So mark the clock as critical
> to avoid this.
>
> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
> ---
> drivers/clk/bcm/clk-bcm2835.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
> index fdf672a..b62052e 100644
> --- a/drivers/clk/bcm/clk-bcm2835.c
> +++ b/drivers/clk/bcm/clk-bcm2835.c
> @@ -1785,7 +1785,7 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
> .load_mask = CM_PLLD_LOADPER,
> .hold_mask = CM_PLLD_HOLDPER,
> .fixed_divider = 1,
> - .flags = CLK_SET_RATE_PARENT),
> + .flags = CLK_IS_CRITICAL | CLK_SET_RATE_PARENT),
Please add a comment in the code to the effect that is in the commit
text so we don't have to dig through commits to figure out why this
special CLK_IS_CRITICAL flag is here.
> [BCM2835_PLLD_DSI0] = REGISTER_PLL_DIV(
> SOC_ALL,
> .name = "plld_dsi0",
_______________________________________________
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 6/6] arm64: document the choice of page attributes for pgprot_dmacoherent
From: Mark Rutland @ 2019-08-16 17:36 UTC (permalink / raw)
To: Will Deacon
Cc: Shawn Anastasio, linux-m68k, Catalin Marinas, linuxppc-dev,
linux-kernel, Russell King, linux-mips, iommu, Geert Uytterhoeven,
Paul Burton, James Hogan, Guan Xuetao, Christoph Hellwig,
linux-arm-kernel, Robin Murphy
In-Reply-To: <20190816173118.4rbbzuogfamfa554@willie-the-truck>
On Fri, Aug 16, 2019 at 06:31:18PM +0100, Will Deacon wrote:
> Hi Christoph,
>
> Thanks for spinning this into a patch.
>
> On Fri, Aug 16, 2019 at 09:07:54AM +0200, Christoph Hellwig wrote:
> > Based on an email from Will Deacon.
> >
> > Signed-off-by: Christoph Hellwig <hch@lst.de>
> > ---
> > arch/arm64/include/asm/pgtable.h | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> > index 6700371227d1..6ff221d9a631 100644
> > --- a/arch/arm64/include/asm/pgtable.h
> > +++ b/arch/arm64/include/asm/pgtable.h
> > @@ -435,6 +435,14 @@ static inline pmd_t pmd_mkdevmap(pmd_t pmd)
> > __pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_NORMAL_NC) | PTE_PXN | PTE_UXN)
> > #define pgprot_device(prot) \
> > __pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_DEVICE_nGnRE) | PTE_PXN | PTE_UXN)
> > +/*
> > + * DMA allocations for non-coherent devices use what the Arm architecture calls
> > + * "Normal non-cacheable" memory, which permits speculation, unaligned accesses
> > + * and merging of writes. This is different from "Strongly Ordered" memory
> > + * which is intended for MMIO and thus forbids speculation, preserves access
> > + * size, requires strict alignment and also forces write responses to come from
> > + * the endpoint.
> > + */
>
> Mind if I tweak the second sentence to be:
>
> This is different from "Device-nGnR[nE]" memory which is intended for MMIO
> and thus forbids speculation, preserves access size, requires strict
> alignment and can also force write responses to come from the endpoint.
>
> ? It's a small change, but it better fits with the arm64 terminology
> ("strongly ordered" is no longer used in the architecture).
>
> If you're happy with that, I can make the change and queue this patch
> for 5.4.
FWIW, with that wording:
Acked-by: Mark Rutland <mark.rutland@arm.com>
Mark.
_______________________________________________
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 6/6] arm64: document the choice of page attributes for pgprot_dmacoherent
From: Will Deacon @ 2019-08-16 17:31 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Shawn Anastasio, linux-m68k, Guan Xuetao, linuxppc-dev,
linux-kernel, Russell King, linux-mips, iommu, Geert Uytterhoeven,
Paul Burton, Catalin Marinas, James Hogan, Robin Murphy,
linux-arm-kernel
In-Reply-To: <20190816070754.15653-7-hch@lst.de>
Hi Christoph,
Thanks for spinning this into a patch.
On Fri, Aug 16, 2019 at 09:07:54AM +0200, Christoph Hellwig wrote:
> Based on an email from Will Deacon.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> arch/arm64/include/asm/pgtable.h | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index 6700371227d1..6ff221d9a631 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -435,6 +435,14 @@ static inline pmd_t pmd_mkdevmap(pmd_t pmd)
> __pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_NORMAL_NC) | PTE_PXN | PTE_UXN)
> #define pgprot_device(prot) \
> __pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_DEVICE_nGnRE) | PTE_PXN | PTE_UXN)
> +/*
> + * DMA allocations for non-coherent devices use what the Arm architecture calls
> + * "Normal non-cacheable" memory, which permits speculation, unaligned accesses
> + * and merging of writes. This is different from "Strongly Ordered" memory
> + * which is intended for MMIO and thus forbids speculation, preserves access
> + * size, requires strict alignment and also forces write responses to come from
> + * the endpoint.
> + */
Mind if I tweak the second sentence to be:
This is different from "Device-nGnR[nE]" memory which is intended for MMIO
and thus forbids speculation, preserves access size, requires strict
alignment and can also force write responses to come from the endpoint.
? It's a small change, but it better fits with the arm64 terminology
("strongly ordered" is no longer used in the architecture).
If you're happy with that, I can make the change and queue this patch
for 5.4.
Thanks,
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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