Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] mtd: nand: raw: atmel: add module param to avoid using dma
From: Peter Rosin @ 2018-05-26 17:40 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <a25ca617-d3da-d401-1ba9-8e5887f8a8e5@microchip.com>

On 2018-05-25 16:51, Tudor Ambarus wrote:
> Hi, Peter,
> 
> On 04/11/2018 06:34 PM, Nicolas Ferre wrote:
>> I'll try to move forward with your detailed explanation and with my 
>> contacts within the "product" team internally.
> 
> We have talked with the hardware team, looks like there is an error in
> the description of the Master to Slave Access matrix. CPU accesses DDR2
> port0 through AXI matrix and not AHB. There is no conflict between CPU
> and LCDC DMA when accessing DDR2 ports. This explains why using CPU
> helps.
> 
> The slave numbers from "Table 14-3 Master to Slave Access" are wrong.
> The 7th row  should be removed and all the other rows from below it,
> shifted up with one level (DDR2 Port 1 is Slave no 7, DDR2 port 2 is
> Slave no 8, ... , APB1 is slave no 11).

Yes, the fact that row 7 (the 8th row, since there is a row 0, but I get
what you mean) should be removed was pretty much what I had guessed. But
what about the other strange things I found? To reiterate, this is my
PRxSy register content (zeroes shown as -):

PRxS0  33--3--3--3333--
PRxS1  33--3--3--3333--
PRxS2  33--------------
PRxS3  -3--------333---
PRxS4  33--------------
PRxS5  3---------------
PRxS6  33--33-33333333-
PRxS7  --3-3--3--------
PRxS8  -3---3--3--3----
PRxS9  --3-3--3-33-333-
PRxS10 3--3------------
PRxS11 3-----3---------
PRxS12 ----------------
PRxS13 ----------------
PRxS14 ----------------
PRxS15 ----------------

So, PRxS7 matches row 8 (DDR2 port 1) in the datasheet.
And PRxS8 matches row 9 (DDR2 port 2) in the datasheet.
But PRxS9 is not matching row 10 (DDR2 port 3)!
And PRxS10-11 match rows 11-12 (APB 0-1) in the datasheet.

But also look at PRxS3 (Internal ROM), there's a missing 3 in the
first slot (A5)! Maybe the priority of that one can't be changed
for some fundamental reason? But there is no hint to that effect
in the datasheet AFAICT...

> We think the best way is to keep LCD on DDR Ports 2 and 3 (8th and 9th
> slaves), to have maximum bandwidth and to use DMA on DDR port 1 for NAND
> (7th slave).

I think I tried to arrange for that last time around. Not sure though,
so I will try again next week...

> Also, some information about your configuration is useful. Can you
> please tell us what NAND DMA configuration did you use?  Are you using
> NAND storage for the videos that you are playing on the LCD screen?

Not sure what level of detail you are after?

We use W949D2CBJX5E LPDDR1 memories from Winbond. Years ago, I wrote some
LPDDR1 patches for at91bootstrap to driver/ddramc.c (which predate the
current upstream support) and to board/sama5d3xek/sama5d3xek.c (which doesn't
to this day support LPDDR1 upstream, but I guess it shouldn't and that we
should have a board of our own, so that part isn't really clean and also the
reason I never upstreamed it). Anyway, some other trivial glue was also
needed, but the meat are in those files. I just had a brief look at the
LPDDR1 support in the upstream ddramc.c file and our code is very similar.
But I did notice some differences and I will look into if that difference
is something that matters. I can show provide patches if you think they
are relevant?

We use this in the sam-ba .qml file when we flash the devices with sam-ba and
the nandflash applet (don't know if it's relevant, but it shows that we have
a 16-bit bus):

        device: SAMA5D3 {
		name: "sama5d3-linea"

		aliases: []

		description: "SAMA5D3 Linea"

		config {
			nandflash {
				ioset: 1
				busWidth: 16
				header: 0xc0902405
			}
		}
	}

*time passes*

Oh dear ... you said NAND *DMA* configuration. Nothing special that I know
of. So, the default? Anything specific I should check?

Further, we are not playing any video. The artifacts are visible on a
static screen on an otherwise "idle" system (i.e. just showing whatever
on the screen and accessing the DRAM with DMA is enough to trigger the
visual glitches).

Cheers,
Peter

^ permalink raw reply

* i2c-gpio and boards conversions to GPIO descriptors
From: Linus Walleij @ 2018-05-26 16:38 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180525154144.GC19100@kw.sim.vm.gnt>

On Fri, May 25, 2018 at 5:41 PM, Simon Guinot <simon.guinot@sequanux.org> wrote:
> Hi Linus,
>
> I think your patch b2e63555592f "i2c: gpio: Convert to use descriptors"
> may have broken i2c-gpio support for some boards using old fashion
> platform_device declarations.
>
> Indeed when an "i2c-gpio" platform_device is registered with a fixed id
> e.g. 0, then I think the device name becomes "i2c-gpio.0". And then this
> won't match a lookup table registered with an "i2c-gpio" dev_id.

Yeah what a mess, I'm sending patches to fix it up, the ARM
patch already sent, I will send a separate one for the MIPS
machines.

Sorry for the mess! :(

Yours,
Linus Walleij

^ permalink raw reply

* [PATCH] ARM: Fix i2c-gpio GPIO descriptor tables
From: Linus Walleij @ 2018-05-26 16:37 UTC (permalink / raw)
  To: linux-arm-kernel

I used bad names in my clumsiness when rewriting many board
files to use GPIO descriptors instead of platform data. A few
had the platform_device ID set to -1 which would indeed give
the device name "i2c-gpio".

But several had it set to >=0 which gives the names
"i2c-gpio.0", "i2c-gpio.1" ...

Fix the offending instances in the ARM tree. Sorry for the
mess.

Fixes: b2e63555592f ("i2c: gpio: Convert to use descriptors")
Cc: Wolfram Sang <wsa@the-dreams.de>
Cc: Simon Guinot <simon.guinot@sequanux.org>
Reported-by: Simon Guinot <simon.guinot@sequanux.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ARM SoC folks: please apply this directly for fixes if
it check out fine.
(The fact that it took so long to discover tells us something
about how used these board files are.)
---
 arch/arm/mach-ep93xx/core.c          | 2 +-
 arch/arm/mach-ixp4xx/avila-setup.c   | 2 +-
 arch/arm/mach-ixp4xx/dsmg600-setup.c | 2 +-
 arch/arm/mach-ixp4xx/fsg-setup.c     | 2 +-
 arch/arm/mach-ixp4xx/ixdp425-setup.c | 2 +-
 arch/arm/mach-ixp4xx/nas100d-setup.c | 2 +-
 arch/arm/mach-ixp4xx/nslu2-setup.c   | 2 +-
 arch/arm/mach-pxa/palmz72.c          | 2 +-
 arch/arm/mach-pxa/viper.c            | 4 ++--
 arch/arm/mach-sa1100/simpad.c        | 2 +-
 10 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-ep93xx/core.c b/arch/arm/mach-ep93xx/core.c
index e70feec6fad5..0581ffbedddd 100644
--- a/arch/arm/mach-ep93xx/core.c
+++ b/arch/arm/mach-ep93xx/core.c
@@ -323,7 +323,7 @@ void __init ep93xx_register_eth(struct ep93xx_eth_data *data, int copy_addr)
 
 /* All EP93xx devices use the same two GPIO pins for I2C bit-banging */
 static struct gpiod_lookup_table ep93xx_i2c_gpiod_table = {
-	.dev_id		= "i2c-gpio",
+	.dev_id		= "i2c-gpio.0",
 	.table		= {
 		/* Use local offsets on gpiochip/port "G" */
 		GPIO_LOOKUP_IDX("G", 1, NULL, 0,
diff --git a/arch/arm/mach-ixp4xx/avila-setup.c b/arch/arm/mach-ixp4xx/avila-setup.c
index 77def6169f50..44cbbce6bda6 100644
--- a/arch/arm/mach-ixp4xx/avila-setup.c
+++ b/arch/arm/mach-ixp4xx/avila-setup.c
@@ -51,7 +51,7 @@ static struct platform_device avila_flash = {
 };
 
 static struct gpiod_lookup_table avila_i2c_gpiod_table = {
-	.dev_id		= "i2c-gpio",
+	.dev_id		= "i2c-gpio.0",
 	.table		= {
 		GPIO_LOOKUP_IDX("IXP4XX_GPIO_CHIP", AVILA_SDA_PIN,
 				NULL, 0, GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN),
diff --git a/arch/arm/mach-ixp4xx/dsmg600-setup.c b/arch/arm/mach-ixp4xx/dsmg600-setup.c
index 0f5c99941a7d..397190f3a8da 100644
--- a/arch/arm/mach-ixp4xx/dsmg600-setup.c
+++ b/arch/arm/mach-ixp4xx/dsmg600-setup.c
@@ -70,7 +70,7 @@ static struct platform_device dsmg600_flash = {
 };
 
 static struct gpiod_lookup_table dsmg600_i2c_gpiod_table = {
-	.dev_id		= "i2c-gpio",
+	.dev_id		= "i2c-gpio.0",
 	.table		= {
 		GPIO_LOOKUP_IDX("IXP4XX_GPIO_CHIP", DSMG600_SDA_PIN,
 				NULL, 0, GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN),
diff --git a/arch/arm/mach-ixp4xx/fsg-setup.c b/arch/arm/mach-ixp4xx/fsg-setup.c
index 033f79b35d51..f0a152e365b1 100644
--- a/arch/arm/mach-ixp4xx/fsg-setup.c
+++ b/arch/arm/mach-ixp4xx/fsg-setup.c
@@ -56,7 +56,7 @@ static struct platform_device fsg_flash = {
 };
 
 static struct gpiod_lookup_table fsg_i2c_gpiod_table = {
-	.dev_id		= "i2c-gpio",
+	.dev_id		= "i2c-gpio.0",
 	.table		= {
 		GPIO_LOOKUP_IDX("IXP4XX_GPIO_CHIP", FSG_SDA_PIN,
 				NULL, 0, GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN),
diff --git a/arch/arm/mach-ixp4xx/ixdp425-setup.c b/arch/arm/mach-ixp4xx/ixdp425-setup.c
index b168e2fbdbeb..3ec829d52cdd 100644
--- a/arch/arm/mach-ixp4xx/ixdp425-setup.c
+++ b/arch/arm/mach-ixp4xx/ixdp425-setup.c
@@ -124,7 +124,7 @@ static struct platform_device ixdp425_flash_nand = {
 #endif	/* CONFIG_MTD_NAND_PLATFORM */
 
 static struct gpiod_lookup_table ixdp425_i2c_gpiod_table = {
-	.dev_id		= "i2c-gpio",
+	.dev_id		= "i2c-gpio.0",
 	.table		= {
 		GPIO_LOOKUP_IDX("IXP4XX_GPIO_CHIP", IXDP425_SDA_PIN,
 				NULL, 0, GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN),
diff --git a/arch/arm/mach-ixp4xx/nas100d-setup.c b/arch/arm/mach-ixp4xx/nas100d-setup.c
index 76dfff03cb71..4138d6aa4c52 100644
--- a/arch/arm/mach-ixp4xx/nas100d-setup.c
+++ b/arch/arm/mach-ixp4xx/nas100d-setup.c
@@ -102,7 +102,7 @@ static struct platform_device nas100d_leds = {
 };
 
 static struct gpiod_lookup_table nas100d_i2c_gpiod_table = {
-	.dev_id		= "i2c-gpio",
+	.dev_id		= "i2c-gpio.0",
 	.table		= {
 		GPIO_LOOKUP_IDX("IXP4XX_GPIO_CHIP", NAS100D_SDA_PIN,
 				NULL, 0, GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN),
diff --git a/arch/arm/mach-ixp4xx/nslu2-setup.c b/arch/arm/mach-ixp4xx/nslu2-setup.c
index 91da63a7d7b5..341b263482ef 100644
--- a/arch/arm/mach-ixp4xx/nslu2-setup.c
+++ b/arch/arm/mach-ixp4xx/nslu2-setup.c
@@ -70,7 +70,7 @@ static struct platform_device nslu2_flash = {
 };
 
 static struct gpiod_lookup_table nslu2_i2c_gpiod_table = {
-	.dev_id		= "i2c-gpio",
+	.dev_id		= "i2c-gpio.0",
 	.table		= {
 		GPIO_LOOKUP_IDX("IXP4XX_GPIO_CHIP", NSLU2_SDA_PIN,
 				NULL, 0, GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN),
diff --git a/arch/arm/mach-pxa/palmz72.c b/arch/arm/mach-pxa/palmz72.c
index 5877e547cecd..0adb1bd6208e 100644
--- a/arch/arm/mach-pxa/palmz72.c
+++ b/arch/arm/mach-pxa/palmz72.c
@@ -322,7 +322,7 @@ static struct soc_camera_link palmz72_iclink = {
 };
 
 static struct gpiod_lookup_table palmz72_i2c_gpiod_table = {
-	.dev_id		= "i2c-gpio",
+	.dev_id		= "i2c-gpio.0",
 	.table		= {
 		GPIO_LOOKUP_IDX("gpio-pxa", 118, NULL, 0,
 				GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN),
diff --git a/arch/arm/mach-pxa/viper.c b/arch/arm/mach-pxa/viper.c
index 90d0f277de55..207dcc2e94e7 100644
--- a/arch/arm/mach-pxa/viper.c
+++ b/arch/arm/mach-pxa/viper.c
@@ -460,7 +460,7 @@ static struct platform_device smc91x_device = {
 
 /* i2c */
 static struct gpiod_lookup_table viper_i2c_gpiod_table = {
-	.dev_id		= "i2c-gpio",
+	.dev_id		= "i2c-gpio.1",
 	.table		= {
 		GPIO_LOOKUP_IDX("gpio-pxa", VIPER_RTC_I2C_SDA_GPIO,
 				NULL, 0, GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN),
@@ -789,7 +789,7 @@ static int __init viper_tpm_setup(char *str)
 __setup("tpm=", viper_tpm_setup);
 
 struct gpiod_lookup_table viper_tpm_i2c_gpiod_table = {
-	.dev_id = "i2c-gpio",
+	.dev_id = "i2c-gpio.2",
 	.table = {
 		GPIO_LOOKUP_IDX("gpio-pxa", VIPER_TPM_I2C_SDA_GPIO,
 				NULL, 0, GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN),
diff --git a/arch/arm/mach-sa1100/simpad.c b/arch/arm/mach-sa1100/simpad.c
index ace010479eb6..f45aed2519ba 100644
--- a/arch/arm/mach-sa1100/simpad.c
+++ b/arch/arm/mach-sa1100/simpad.c
@@ -327,7 +327,7 @@ static struct platform_device simpad_gpio_leds = {
  * i2c
  */
 static struct gpiod_lookup_table simpad_i2c_gpiod_table = {
-	.dev_id = "i2c-gpio",
+	.dev_id = "i2c-gpio.0",
 	.table = {
 		GPIO_LOOKUP_IDX("gpio", 21, NULL, 0,
 				GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN),
-- 
2.17.0

^ permalink raw reply related

* [GIT PULL] Allwinner core changes for 4.18
From: Chen-Yu Tsai @ 2018-05-26 16:22 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180525210218.orjdivwnkm6j4d4q@localhost>

On Fri, May 25, 2018 at 2:02 PM, Olof Johansson <olof@lixom.net> wrote:
> On Mon, May 21, 2018 at 01:41:56PM +0200, Maxime Ripard wrote:
>> Hi,
>>
>> Here is our mach-sunxi changes for the next merge window, thanks!
>> Maxime
>>
>> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>>
>>   Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>>
>> are available in the Git repository at:
>>
>>   https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-core-for-4.18
>>
>> for you to fetch changes up to 6961275e72a8c15cc4ebf108a81eee758480a6a2:
>>
>>   ARM: sun8i: smp: Add support for A83T (2018-05-08 15:00:20 +0200)
>>
>> ----------------------------------------------------------------
>> Allwinner core changes for 4.18
>>
>> The A83t, unlike the other Allwinner SoCs, cannot use PSCI because of a
>> silicon bug. As such, we needed to have some smp_ops in order to bringup
>> the various cores (and clusters) found on this SoC.
>
> Hrm. that's unfortunate. Is there any public documentation of what the bug is?

The security extensions in the A80 and A83T is not entirely enabled.
The security bit is not forwarded on to the bus, so all accesses from
non-secure become secure. This is not documented, but was the result
of some tests I did.

See https://lists.denx.de/pipermail/u-boot/2017-June/294672.html
for a summary (in the quotes) of what we think is the issue.

Marc's suggestion is that if virtualization doesn't work on it, then
there's no point in running it non-secure. [1]

ChenYu

[1] https://lists.denx.de/pipermail/u-boot/2017-June/294697.html

^ permalink raw reply

* [PATCH 1/2] arm64: arch_timer: Workaround for Allwinner A64 timer instability
From: André Przywara @ 2018-05-26 15:15 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180511022751.9096-2-samuel@sholland.org>

On 05/11/2018 03:27 AM, Samuel Holland wrote:
> The Allwinner A64 SoC is known [1] to have an unstable architectural
> timer, which manifests itself most obviously in the time jumping forward
> a multiple of 95 years [2][3]. This coincides with 2^56 cycles at a
> timer frequency of 24 MHz, implying that the time went slightly backward
> (and this was interpreted by the kernel as it jumping forward and
> wrapping around past the epoch).
> 
> Further investigation revealed instability in the low bits of CNTVCT at
> the point a high bit rolls over. This leads to power-of-two cycle
> forward and backward jumps. (Testing shows that forward jumps are about
> twice as likely as backward jumps.)
> 
> Without trapping reads to CNTVCT, a userspace program is able to read it
> in a loop faster than it changes. A test program running on all 4 CPU
> cores that reported jumps larger than 100 ms was run for 13.6 hours and
> reported the following:
> 
>  Count | Event
> -------+---------------------------
>   9940 | jumped backward      699ms
>    268 | jumped backward     1398ms
>      1 | jumped backward     2097ms
>  16020 | jumped forward       175ms
>   6443 | jumped forward       699ms
>   2976 | jumped forward      1398ms
>      9 | jumped forward    356516ms
>      9 | jumped forward    357215ms
>      4 | jumped forward    714430ms
>      1 | jumped forward   3578440ms
> 
> This works out to a jump larger than 100 ms about every 5.5 seconds on
> each CPU core.
> 
> The largest jump (almost an hour!) was the following sequence of reads:
>       0x0000007fffffffff ? 0x00000093feffffff ? 0x0000008000000000
> 
> Note that the middle bits don't necessarily all read as all zeroes or
> all ones during the anomalous behavior; however the low 11 bits checked
> by the function in this patch have never been observed with any other
> value.
> 
> Also note that smaller jumps are much more common, with the smallest
> backward jumps of 2048 cycles observed over 400 times per second on each
> core. (Of course, this is partially due to lower bits rolling over more
> frequently.) Any one of these could have caused the 95 year time skip.
> 
> Similar anomalies were observed while reading CNTPCT (after patching the
> kernel to allow reads from userspace). However, the jumps are much less
> frequent, and only small jumps were observed. The same program as before
> (except now reading CNTPCT) observed after 72 hours:
> 
>  Count | Event
> -------+---------------------------
>     17 | jumped backward      699ms
>     52 | jumped forward       175ms
>   2831 | jumped forward       699ms
>      5 | jumped forward      1398ms
> 
> ========================================================================
> 
> Because the CPU can read the CNTPCT/CNTVCT registers faster than they
> change, performing two reads of the register and comparing the high bits
> (like other workarounds) is not a workable solution. And because the
> timer can jump both forward and backward, no pair of reads can
> distinguish a good value from a bad one. The only way to guarantee a
> good value from consecutive reads would be to read _three_ times, and
> take the middle value iff the three values are 1) individually unique
> and 2) increasing. This takes at minimum 3 cycles (125 ns), or more if
> an anomaly is detected.
> 
> However, since there is a distinct pattern to the bad values, we can
> optimize the common case (2046/2048 of the time) to a single read by
> simply ignoring values that match the pattern. This still takes no more
> than 3 cycles in the worst case, and requires much less code.

Clever solution, and indeed much less costly than other workarounds.

FWIW, I tested this on a Pine64 and can confirm that it works.
I put a test program here:
https://github.com/apritzel/pine64/blob/master/tools/test_timer.c

This only checks for consecutive reads going backwards, but within a
split second yells on an unpatched kernel:
https://gist.github.com/apritzel/fc78ca6edb17be2024d5adfd35edb520

Applying the patch and adding the DT property fixed that for me.

I second Marc's request for an upper bound on the loop. Question is just
what we do when we reach the loop count limit?

But regardless, given that this fixes this nasty issue:

Tested-by: Andre Przywara <andre.przywara@arm.com>

Cheers,
Andre.

^ permalink raw reply

* [PATCH] media: mtk-vpu: fix spelling mistake: "Prosessor" -> "Processor"
From: Colin King @ 2018-05-26 13:45 UTC (permalink / raw)
  To: linux-arm-kernel

From: Colin Ian King <colin.king@canonical.com>

Trivial fix to spelling mistake in module description text.

Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
 drivers/media/platform/mtk-vpu/mtk_vpu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/mtk-vpu/mtk_vpu.c b/drivers/media/platform/mtk-vpu/mtk_vpu.c
index 1ff6a93262b7..f8d35e3ac1dc 100644
--- a/drivers/media/platform/mtk-vpu/mtk_vpu.c
+++ b/drivers/media/platform/mtk-vpu/mtk_vpu.c
@@ -960,4 +960,4 @@ static struct platform_driver mtk_vpu_driver = {
 module_platform_driver(mtk_vpu_driver);
 
 MODULE_LICENSE("GPL v2");
-MODULE_DESCRIPTION("Mediatek Video Prosessor Unit driver");
+MODULE_DESCRIPTION("Mediatek Video Processor Unit driver");
-- 
2.17.0

^ permalink raw reply related

* Boot failures in -next on Jetson TK1
From: Mark Brown @ 2018-05-26 10:36 UTC (permalink / raw)
  To: linux-arm-kernel

Currently -next is failing to boot on Jetson TK1.  The problem looks to
be the Nouveau driver, during initialization it reports an address
decode error then starts printing error messages saying "nouveau
57000000.gpu: fifo: SCHED_ERROR 20 []" over and over again.

I've pasted the start of the errors below, you can see a full log and
more details at:

   https://kernelci.org/boot/id/5b0882a259b514339779a881/

The warnings about Spectre are a separate issue and don't seem to affect
the boot.

[ 15.194484] nouveau 57000000.gpu: NVIDIA GK20A (0ea000a1)
[   15.200109] udevd[109]: could not rename interface '3' from 'eth0' to 'enp1s0': Device or resource busy
[   15.206399] nouveau 57000000.gpu: imem: using IOMMU
[   15.315122] CPU2: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable
[   15.320021] nouveau 57000000.gpu: Direct firmware load for nvidia/gk20a/fecs_inst.bin failed with error -2
[   15.384841] nouveau 57000000.gpu: Direct firmware load for nouveau/nvea_fuc409c failed with error -2
[   15.393972] nouveau 57000000.gpu: Direct firmware load for nouveau/fuc409c failed with error -2
[   15.402679] nouveau 57000000.gpu: gr: failed to load fuc409c
[   15.409434] CPU1: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable
[   15.419398] CPU1: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable
[   15.482568] tegra-mc 70019000.memory-controller: gpusrd: read @0x00041200: EMEM address decode error (EMEM decode error)
[   15.491232] [TTM] Zone  kernel: Available graphics memory: 375202 kiB
[   15.502768] [TTM] Zone highmem: Available graphics memory: 1030050 kiB
[   15.509290] [TTM] Initializing pool allocator
[   15.513658] nouveau 57000000.gpu: DRM: VRAM: 0 MiB
[   15.518451] nouveau 57000000.gpu: DRM: GART: 1048576 MiB
[   15.526546] CPU1: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable
[   15.527290] tegra-mc 70019000.memory-controller: gpusrd: read @0x00072000: EMEM address decode error (EMEM decode error)
[   15.537050] CPU1: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable
[   15.546928] nouveau 57000000.gpu: fifo: SCHED_ERROR 20 []
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180526/689741b6/attachment.sig>

^ permalink raw reply

* [RESEND PATCH] dmaengine: pxa: add a default requestor policy
From: Robert Jarzmik @ 2018-05-26  9:54 UTC (permalink / raw)
  To: linux-arm-kernel

As what former drcmr -1 value meant, add a this as a default to each
channel, ie. that by default no requestor line is used.

This is specifically used for network drivers smc91x and smc911x, and
needed for their port to slave maps.

Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
 drivers/dma/pxa_dma.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/dma/pxa_dma.c b/drivers/dma/pxa_dma.c
index 9505334f9c6e..604df1bdadf7 100644
--- a/drivers/dma/pxa_dma.c
+++ b/drivers/dma/pxa_dma.c
@@ -762,6 +762,8 @@ static void pxad_free_chan_resources(struct dma_chan *dchan)
 	dma_pool_destroy(chan->desc_pool);
 	chan->desc_pool = NULL;
 
+	chan->drcmr = (u32)-1;
+	chan->prio = PXAD_PRIO_LOWEST;
 }
 
 static void pxad_free_desc(struct virt_dma_desc *vd)
@@ -1386,6 +1388,9 @@ static int pxad_init_dmadev(struct platform_device *op,
 		c = devm_kzalloc(&op->dev, sizeof(*c), GFP_KERNEL);
 		if (!c)
 			return -ENOMEM;
+
+		c->drcmr = (u32)-1;
+		c->prio = PXAD_PRIO_LOWEST;
 		c->vc.desc_free = pxad_free_desc;
 		vchan_init(&c->vc, &pdev->slave);
 		init_waitqueue_head(&c->wq_state);
-- 
2.11.0

^ permalink raw reply related

* [PATCH] ARM: pxa: hx4700: fix the usb client
From: Robert Jarzmik @ 2018-05-26  9:38 UTC (permalink / raw)
  To: linux-arm-kernel

The usb client of the hx4700 is not working because no platform data is
declared. Fix it by adding the missing call.

Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
 arch/arm/mach-pxa/hx4700.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/mach-pxa/hx4700.c b/arch/arm/mach-pxa/hx4700.c
index e2e7f247a645..b79b757fdd41 100644
--- a/arch/arm/mach-pxa/hx4700.c
+++ b/arch/arm/mach-pxa/hx4700.c
@@ -54,6 +54,7 @@
 
 #include "devices.h"
 #include "generic.h"
+#include "udc.h"
 
 /* Physical address space information */
 
@@ -594,6 +595,8 @@ static struct platform_device gpio_vbus = {
 	},
 };
 
+static struct pxa2xx_udc_mach_info hx4700_udc_info;
+
 /*
  * Touchscreen - TSC2046 connected to SSP2
  */
@@ -891,6 +894,7 @@ static void __init hx4700_init(void)
 	gpio_set_value(GPIO71_HX4700_ASIC3_nRESET, 1);
 	mdelay(10);
 
+	pxa_set_udc_info(&hx4700_udc_info);
 	regulator_has_full_constraints();
 }
 
-- 
2.11.0

^ permalink raw reply related

* [PATCH 1/6] arm64: dts: amlogic: Add missing cooling device properties for CPUs
From: Neil Armstrong @ 2018-05-26  8:37 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180525211025.c73zdcdtyuvlewng@localhost>

Hi,

On 25/05/2018 23:10, Olof Johansson wrote:
> On Fri, May 25, 2018 at 11:10:01AM +0530, Viresh Kumar wrote:
>> The cooling device properties, like "#cooling-cells" and
>> "dynamic-power-coefficient", should either be present for all the CPUs
>> of a cluster or none. If these are present only for a subset of CPUs of
>> a cluster then things will start falling apart as soon as the CPUs are
>> brought online in a different order. For example, this will happen
>> because the operating system looks for such properties in the CPU node
>> it is trying to bring up, so that it can register a cooling device.
>>
>> Add such missing properties.
> 
> This seems awkward compared to just having one cooling-cells in the /cpus node
> instead.
> 
> What's it used for? I don't see any properties in the device nodes on meson-gxm
> that have any cooling-foo cells in them? So why should #cooling-cells be
> needed?


There is no reason to have the cooling-cells on these other CPUs, the DVFS is
controlled on the first CPU of each cluster, here cpu0 and cpu4 and only
cpu0 and cpu4 are used as cooling-cells.

Neil

> 
> 
> -Olof
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

^ permalink raw reply

* qcom: add firmware file for Venus on SDM845
From: Vikash Garodia @ 2018-05-26  8:18 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CA+5PVA67tow+prVC55XF4=CbRGXJvPi2SuCMyhRyuw5qt8T6_Q@mail.gmail.com>

Hi Josh,

On 2018-05-25 17:34, Josh Boyer wrote:
> On Fri, May 25, 2018 at 7:03 AM Vikash Garodia 
> <vgarodia@codeaurora.org>
> wrote:
> 
>> This pull request adds firmware files for Venus h/w codec found on the
> Qualcomm SDM845 chipset.
> 
>> The following changes since commit
> 2a9b2cf50fb32e36e4fc1586c2f6f1421913b553:
> 
>>    Merge branch 'for-upstreaming-v1.7.2' of
> https://github.com/felix-cavium/linux-firmware (2018-05-18 08:35:22 
> -0400)
> 
>> are available in the git repository at:
> 
> 
>>    https://github.com/vgarodia/linux-firmware master
> 
>> for you to fetch changes up to 
>> d6088b9c9d7f49d3c6c43681190889eca0abdcce:
> 
>>    qcom: add venus firmware files for v5.2 (2018-05-25 15:16:43 +0530)
> 
>> ----------------------------------------------------------------
>> Vikash Garodia (1):
>>        qcom: add venus firmware files for v5.2
> 
>>   WHENCE                   |   9 +++++++++
>>   qcom/venus-5.2/venus.b00 | Bin 0 -> 212 bytes
>>   qcom/venus-5.2/venus.b01 | Bin 0 -> 6600 bytes
>>   qcom/venus-5.2/venus.b02 | Bin 0 -> 819552 bytes
>>   qcom/venus-5.2/venus.b03 | Bin 0 -> 33536 bytes
>>   qcom/venus-5.2/venus.b04 |   1 +
>>   qcom/venus-5.2/venus.mbn | Bin 0 -> 865408 bytes
>>   qcom/venus-5.2/venus.mdt | Bin 0 -> 6812 bytes
>>   8 files changed, 10 insertions(+)
>>   create mode 100644 qcom/venus-5.2/venus.b00
>>   create mode 100644 qcom/venus-5.2/venus.b01
>>   create mode 100644 qcom/venus-5.2/venus.b02
>>   create mode 100644 qcom/venus-5.2/venus.b03
>>   create mode 100644 qcom/venus-5.2/venus.b04
>>   create mode 100644 qcom/venus-5.2/venus.mbn
>>   create mode 100644 qcom/venus-5.2/venus.mdt
> 
> The venus.mbn file isn't mentioned in WHENCE:
> 
> [jwboyer at vader linux-firmware]$ ./check_whence.py
> E: qcom/venus-5.2/venus.mbn not listed in WHENCE
> [jwboyer at vader linux-firmware]$
> 
> Can you fix that up and let me know when to re-pull?
I have fixed the error and is ready to be re-pulled from the same git 
repository.
I have noted the process to run check_whence.py before uploading the 
firmwares.

Do i need to resend the pull request as the end commit is now changed to
7602644358157e4b89960472b6d59ffcc040ca52 ?

-Vikash

^ permalink raw reply

* [PATCH 0/3] Dts nodes for Keystone2 hw_rng driver
From: santosh.shilimkar at oracle.com @ 2018-05-26  4:43 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1527167538-29837-1-git-send-email-vitalya@ti.com>

On 5/24/18 6:12 AM, Vitaly Andrianov wrote:
> This series adds dts nodes for Keystone2 hw_rng driver
> 
> Vitaly Andrianov (3):
>    ARM: dts: k2hk: add dts node for k2hk hw_rng driver
>    ARM: dts: k2l: add dts node for k2l hw_rng driver
>    ARM: dts: k2e: add dts node for k2e hw_rng driver
> 
Looks good. Will queue this up for 4.19. Thanks !!

Regards,
Santosh

^ permalink raw reply

* linux-next: Signed-off-by missing for commit in the arm-soc tree
From: Stephen Rothwell @ 2018-05-26  4:34 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <80df07c8-b89c-503e-ad25-9f235cb08038@st.com>

Hi Alexandre,

On Tue, 15 May 2018 09:15:23 +0200 Alexandre Torgue <alexandre.torgue@st.com> wrote:
>
> On 05/14/2018 11:22 PM, Stephen Rothwell wrote:
> > 
> > Commit
> > 
> >    949a0c0dec85 ("ARM: dts: stm32: add USB Host (USBH) support to stm32mp157c")
> > 
> > is missing a Signed-off-by from its committer.
> 
> My fault, I forgot it when I applied patch on my branch. Do we need an 
> update or it is just a reminder?

Some people rebase their tree to fix these up, some just take it as a
learning experience :-)

-- 
Cheers,
Stephen Rothwell
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180526/6bd6efa8/attachment.sig>

^ permalink raw reply

* [PATCH v2 03/40] iommu/sva: Manage process address spaces
From: Kenneth Lee @ 2018-05-26  2:24 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180525093959.000040a7@huawei.com>

On Fri, May 25, 2018 at 09:39:59AM +0100, Jonathan Cameron wrote:
> Date: Fri, 25 May 2018 09:39:59 +0100
> From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> To: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> CC: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>,
>  "xieyisheng1 at huawei.com" <xieyisheng1@huawei.com>, "kvm at vger.kernel.org"
>  <kvm@vger.kernel.org>, "linux-pci at vger.kernel.org"
>  <linux-pci@vger.kernel.org>, "xuzaibo at huawei.com" <xuzaibo@huawei.com>,
>  Will Deacon <Will.Deacon@arm.com>, "okaya at codeaurora.org"
>  <okaya@codeaurora.org>, "linux-mm at kvack.org" <linux-mm@kvack.org>,
>  "yi.l.liu at intel.com" <yi.l.liu@intel.com>, "ashok.raj at intel.com"
>  <ashok.raj@intel.com>, "tn at semihalf.com" <tn@semihalf.com>,
>  "joro at 8bytes.org" <joro@8bytes.org>, "robdclark at gmail.com"
>  <robdclark@gmail.com>, "bharatku at xilinx.com" <bharatku@xilinx.com>,
>  "linux-acpi at vger.kernel.org" <linux-acpi@vger.kernel.org>,
>  "liudongdong3 at huawei.com" <liudongdong3@huawei.com>, "rfranz at cavium.com"
>  <rfranz@cavium.com>, "devicetree at vger.kernel.org"
>  <devicetree@vger.kernel.org>, "kevin.tian at intel.com"
>  <kevin.tian@intel.com>, Jacob Pan <jacob.jun.pan@linux.intel.com>,
>  "alex.williamson at redhat.com" <alex.williamson@redhat.com>,
>  "rgummal at xilinx.com" <rgummal@xilinx.com>, "thunder.leizhen at huawei.com"
>  <thunder.leizhen@huawei.com>, "linux-arm-kernel at lists.infradead.org"
>  <linux-arm-kernel@lists.infradead.org>, "shunyong.yang at hxt-semitech.com"
>  <shunyong.yang@hxt-semitech.com>, "dwmw2 at infradead.org"
>  <dwmw2@infradead.org>, "liubo95 at huawei.com" <liubo95@huawei.com>,
>  "jcrouse at codeaurora.org" <jcrouse@codeaurora.org>,
>  "iommu at lists.linux-foundation.org" <iommu@lists.linux-foundation.org>,
>  Robin Murphy <Robin.Murphy@arm.com>, "christian.koenig at amd.com"
>  <christian.koenig@amd.com>, "nwatters at codeaurora.org"
>  <nwatters@codeaurora.org>, "baolu.lu at linux.intel.com"
>  <baolu.lu@linux.intel.com>, liguozhu at hisilicon.com,
>  kenneth-lee-2012 at foxmail.com
> Subject: Re: [PATCH v2 03/40] iommu/sva: Manage process address spaces
> Message-ID: <20180525093959.000040a7@huawei.com>
> 
> +CC Kenneth Lee
> 
> On Fri, 25 May 2018 09:33:11 +0300
> Ilias Apalodimas <ilias.apalodimas@linaro.org> wrote:
> 
> > On Thu, May 24, 2018 at 04:04:39PM +0100, Jean-Philippe Brucker wrote:
> > > On 24/05/18 12:50, Ilias Apalodimas wrote:  
> > > >> Interesting, I hadn't thought about this use-case before. At first I
> > > >> thought you were talking about mdev devices assigned to VMs, but I think
> > > >> you're referring to mdevs assigned to userspace drivers instead? Out of
> > > >> curiosity, is it only theoretical or does someone actually need this?  
> > > > 
> > > > There has been some non upstreamed efforts to have mdev and produce userspace
> > > > drivers. Huawei is using it on what they call "wrapdrive" for crypto devices and
> > > > we did a proof of concept for ethernet interfaces. At the time we choose not to
> > > > involve the IOMMU for the reason you mentioned, but having it there would be
> > > > good.  
> > > 
> > > I'm guessing there were good reasons to do it that way but I wonder, is
> > > it not simpler to just have the kernel driver create a /dev/foo, with a
> > > standard ioctl/mmap/poll interface? Here VFIO adds a layer of
> > > indirection, and since the mediating driver has to implement these
> > > operations already, what is gained?  
> > The best reason i can come up with is "common code". You already have one API
> > doing that for you so we replicate it in a /dev file?
> > The mdev approach still needs extentions to support what we tried to do (i.e
> > mdev bus might need yo have access on iommu_ops), but as far as i undestand it's
> > a possible case.

Hi, Jean, Please allow me to share my understanding here:
https://zhuanlan.zhihu.com/p/35489035

The reason we do not use the /dev/foo scheme is that the devices to be
shared are programmable accelerators. We cannot fix up the kernel driver for them.
> > > 
> > > Thanks,
> > > Jean  
> 
> 

-- 
			-Kenneth Lee (Hisilicon)

^ permalink raw reply

* [PATCH v2] ARM: dts: imx51-zii-rdu1: Make sure SD1_WP is low
From: Andrey Smirnov @ 2018-05-26  2:12 UTC (permalink / raw)
  To: linux-arm-kernel

Make sure that MX51_PAD_GPIO1_1 does not remain configure as
ALT0/SD1_WP (it is out of reset). This is needed because of external
pull-up resistor attached to that pad that, when left unchanged, will
drive SD1_WP high preventing eSDHC1/eMMC from working correctly.

To fix that add a pinmux configuration line configureing the pad to
function as a GPIO. While we are at it, add a corresponding
output-high GPIO hog in an effort to minimize current consumption.

Cc: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Chris Healy <cphealy@gmail.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-arm-kernel at lists.infradead.org
Cc: devicetree at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---

Changes since [v1]:

 - Switched GPIO hog to be output-high

 - Removed whitespace damage

[v1] lkml.kernel.org/r/20180525030153.15986-1-andrew.smirnov at gmail.com

 arch/arm/boot/dts/imx51-zii-rdu1.dts | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/arch/arm/boot/dts/imx51-zii-rdu1.dts b/arch/arm/boot/dts/imx51-zii-rdu1.dts
index df9eca94d812..1e343f35a9d9 100644
--- a/arch/arm/boot/dts/imx51-zii-rdu1.dts
+++ b/arch/arm/boot/dts/imx51-zii-rdu1.dts
@@ -476,6 +476,17 @@
 	status = "okay";
 };
 
+&gpio1 {
+	unused-sd3-wp-gpio {
+		/*
+		 * See pinctrl_esdhc1 below for more details on this
+		 */
+		gpio-hog;
+		gpios = <1 GPIO_ACTIVE_HIGH>;
+		output-high;
+	};
+};
+
 &i2c2 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_i2c2>;
@@ -660,6 +671,23 @@
 			MX51_PAD_SD1_DATA1__SD1_DATA1		0x20d5
 			MX51_PAD_SD1_DATA2__SD1_DATA2		0x20d5
 			MX51_PAD_SD1_DATA3__SD1_DATA3		0x20d5
+			/*
+			 * GPIO1_1 is not directly used by eSDHC1 in
+			 * any capacity, but earlier versions of RDU1
+			 * used that pin as WP GPIO for eSDHC3 and
+			 * because of that that pad has an external
+			 * pull-up resistor. This is problematic
+			 * because out of reset the pad is configured
+			 * as ALT0 which serves as SD1_WP, which, when
+			 * pulled high by and external pull-up, will
+			 * inhibit execution of any write request to
+			 * attached eMMC device.
+			 *
+			 * To avoid this problem we configure the pad
+			 * to ALT1/GPIO and avoid driving SD1_WP
+			 * signal high.
+			 */
+			MX51_PAD_GPIO1_1__GPIO1_1		0x0000
 		>;
 	};
 
-- 
2.17.0

^ permalink raw reply related

* [PATCH v2 07/40] iommu: Add a page fault handler
From: Jacob Pan @ 2018-05-26  0:35 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <bdf9f221-ab97-2168-d072-b7f6a0dba840@arm.com>

On Thu, 24 May 2018 12:44:38 +0100
Jean-Philippe Brucker <jean-philippe.brucker@arm.com> wrote:

> On 23/05/18 00:35, Jacob Pan wrote:
> >>>> +			/* Insert *before* the last fault */
> >>>> +			list_move(&fault->head, &group->faults);
> >>>> +	}
> >>>> +    
> >>> If you already sorted the group list with last fault at the end,
> >>> why do you need a separate entry to track the last fault?    
> >>
> >> Not sure I understand your question, sorry. Do you mean why the
> >> iopf_group.last_fault? Just to avoid one more kzalloc.
> >>  
> > kind of :) what i thought was that why can't the last_fault
> > naturally be the last entry in your group fault list? then there is
> > no need for special treatment in terms of allocation of the last
> > fault. just my preference.  
> 
> But we need a kzalloc for the last fault anyway, so I thought I'd just
> piggy-back on the group allocation. And if I don't add the last fault
> at the end of group->faults, then it's iopf_handle_group that requires
> special treatment. I'm still not sure I understood your question
> though, could you send me a patch that does it?
> 
> >>>> +
> >>>> +	queue->flush(queue->flush_arg, dev);
> >>>> +
> >>>> +	/*
> >>>> +	 * No need to clear the partial list. All PRGs
> >>>> containing the PASID that
> >>>> +	 * needs to be decommissioned are whole (the device
> >>>> driver made sure of
> >>>> +	 * it before this function was called). They have been
> >>>> submitted to the
> >>>> +	 * queue by the above flush().
> >>>> +	 */    
> >>> So you are saying device driver need to make sure LPIG PRQ is
> >>> submitted in the flush call above such that partial list is
> >>> cleared?    
> >>
> >> Not exactly, it's the IOMMU driver that makes sure all LPIG in its
> >> queues are submitted by the above flush call. In more details the
> >> flow is:
> >>
> >> * Either device driver calls unbind()/sva_device_shutdown(), or the
> >> process exits.
> >> * If the device driver called, then it already told the device to
> >> stop using the PASID. Otherwise we use the mm_exit() callback to
> >> tell the device driver to stop using the PASID.
Sorry I still need more clarification. For the PASID termination
initiated by vfio unbind, I don't see device driver given a chance to
stop PASID. Seems just call __iommu_sva_unbind_device() which already
assume device stopped issuing DMA with the PASID.
So it is the vfio unbind caller responsible for doing driver callback
to stop DMA on a given PASID?

> >> * In either case, when receiving a stop request from the driver,
> >> the device sends the LPIGs to the IOMMU queue.
> >> * Then, the flush call above ensures that the IOMMU reports the
> >> LPIG with iommu_report_device_fault.
> >> * While submitting all LPIGs for this PASID to the work queue,
> >> ipof_queue_fault also picked up all partial faults, so the partial
> >> list is clean.
> >>
> >> Maybe I should improve this comment?
> >>  
> > thanks for explaining. LPIG submission is done by device
> > asynchronously w.r.t. driver stopping/decommission PASID.  
> 
> Hmm, it should really be synchronous, otherwise there is no way to
> know when the PASID can be decommissioned. We need a guarantee such
> as the one in 6.20.1 of the PCIe spec, "Managing PASID TLP Prefix
> Usage":
> 
> "When the stop request mechanism indicates completion, the Function
> has:
> * Completed all Non-Posted Requests associated with this PASID.
> * Flushed to the host all Posted Requests addressing host memory in
> all TCs that were used by the PASID."
> 
> That's in combination with "The function shall [...] finish
> transmitting any multi-page Page Request Messages for this PASID
> (i.e. send the Page Request Message with the L bit Set)." from the
> ATS spec.
> 
I am not contesting on the device side, what I meant was from the
host IOMMU driver perspective, LPIG is received via IOMMU host queue,
therefore asynchronous. Not sure about ARM, but on VT-d LPIG submission
could meet queue full condition. So per VT-d spec, iommu will generate a
successful auto response to the device. At this point, assume we
already stopped the given PASID on the device, there might not be
another LPIG sent for the device. Therefore, you could have a partial
list. I think we can just drop the requests in the partial list for
that PASID until the PASID gets re-allocated.


> (If I remember correctly a PRI Page Request is a Posted Request.) Only
> after this stop request completes can the driver call unbind(), or
> return from exit_mm(). Then we know that if there was a LPIG for that
> PASID, it is in the IOMMU's PRI queue (or already completed) once we
> call flush().
> 
agreed.
> > so if we were to use this
> > flow on vt-d, which does not stall page request queue, then we
> > should use the iommu model specific flush() callback to ensure LPIG
> > is received? There could be queue full condition and retry. I am
> > just trying to understand how and where we can make sure LPIG is
> > received and all groups are whole.  
> 
> For SMMU in patch 30, the flush() callback waits until the PRI queue
> is empty or, when the PRI thread is running in parallel, until the
> thread has done a full circle (handled as many faults as the queue
> size). It's really unpleasant to implement because the flush()
> callback takes a lock to inspect the hardware state, but I don't
> think we have a choice.
> 
yes, vt-d has similar situation in page request queue. one option is to
track queue head (SW update) to make sure one complete cycle when queue
tail(HW update) crosses. Or we(suggested by Ashok Raj) can take a
snapshot of the entire queue and process (drops PRQs belong to the
terminated PASID) without holding the queue.

Thanks,

Jacob

^ permalink raw reply

* [PATCH] perf tools: Fix indexing for decoder packet queue
From: Mathieu Poirier @ 2018-05-25 23:10 UTC (permalink / raw)
  To: linux-arm-kernel

The tail of a queue is supposed to be pointing to the next available slot
in a queue.  In this implementation the tail is incremented before it is
used and as such points to the last used element, something that has the
immense advantage of centralizing tail management at a single location
and eliminating a lot of redundant code.

But this needs to be taken into consideration on the dequeueing side where
the head also needs to be incremented before it is used, or the first
available element of the queue will be skipped.

Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
---
 tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
index c8b98fa22997..4d5fc374e730 100644
--- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
+++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
@@ -96,11 +96,19 @@ int cs_etm_decoder__get_packet(struct cs_etm_decoder *decoder,
 	/* Nothing to do, might as well just return */
 	if (decoder->packet_count == 0)
 		return 0;
+	/*
+	 * The queueing process in function cs_etm_decoder__buffer_packet()
+	 * increments the tail *before* using it.  This is somewhat counter
+	 * intuitive but it has the advantage of centralizing tail management
+	 * at a single location.  Because of that we need to follow the same
+	 * heuristic with the head, i.e we increment it before using its
+	 * value.  Otherwise the first element of the packet queue is not
+	 * used.
+	 */
+	decoder->head = (decoder->head + 1) & (MAX_BUFFER - 1);
 
 	*packet = decoder->packet_buffer[decoder->head];
 
-	decoder->head = (decoder->head + 1) & (MAX_BUFFER - 1);
-
 	decoder->packet_count--;
 
 	return 1;
-- 
2.7.4

^ permalink raw reply related

* [GIT PULL] ARM: at91: DT for 4.18
From: Alexandre Belloni @ 2018-05-25 22:50 UTC (permalink / raw)
  To: linux-arm-kernel

Arnd, Olof,

I'm a bit late for this very small PR, as I had to extend the expiration
date for my GPG signature key.

Two small DT changes that have no functional impact.

The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:

  Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git tags/at91-ab-4.18-dt

for you to fetch changes up to a642693882ce417683012a211ca9d6e65bae1dc4:

  ARM: dts: at91-sama5d2_xplained: Use IRQ_TYPE specifier (2018-05-14 15:29:52 +0200)

----------------------------------------------------------------
AT91 DT for 4.18:

 - small DT improvements without functional changes

----------------------------------------------------------------
Dmitry Torokhov (1):
      ARM: dts: at91: sama5d4ek: use canonical compatible for touchscreen

Hern?n Gonzalez (1):
      ARM: dts: at91-sama5d2_xplained: Use IRQ_TYPE specifier

 arch/arm/boot/dts/at91-sama5d2_xplained.dts | 2 +-
 arch/arm/boot/dts/at91-sama5d4ek.dts        | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

-- 
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

^ permalink raw reply

* [PATCH] arm64: dts: msm8916: fix Coresight ETF graph connections
From: Andy Gross @ 2018-05-25 22:46 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CANLsYkz9tAH7mazz2LNCtoYsdH4f5bKfGWEnJHsgH0mK6vNMEg@mail.gmail.com>

On Thu, May 24, 2018 at 10:32:46AM -0600, Mathieu Poirier wrote:

<snip>

> >
> >  Hi Rob,
> >
> >  I no longer have access to this hardware and documentation.
> >  I am sure that Mathieu and friends will take care for verification
> >  of this patch :-)
> 
> The code triggers on the "slave-mode" property rather than the labels,
> so this patch has no effect on how a path is established.  I've tested
> this on a 410c and things look good.
> 
> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> Tested-by: Mathieu Poirier <mathieu.poirier@linaro.org>

Thanks for verifying this Matthew.  I'll put this in for a fixes as I just sent
out my last set for 4.18.

Regards,

Andy

^ permalink raw reply

* [GIT PULL] Qualcomm Driver Fixes for 4.17-rc7
From: Andy Gross @ 2018-05-25 22:42 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180525220124.f3tv2bpkb54rga53@localhost>

On Fri, May 25, 2018 at 03:01:24PM -0700, Olof Johansson wrote:
> On Thu, May 24, 2018 at 10:55:09PM -0500, Andy Gross wrote:
> > The following changes since commit 771c577c23bac90597c685971d7297ea00f99d11:
> > 
> >   Linux 4.17-rc6 (2018-05-20 15:31:38 -0700)
> 
> This is a newer -rc than I had for fixes, so I had to move forward. Feel
> free to use as old an rc as you can on these branches too.

Oops.  I should have just used -rc1.  Sorry for that.

Andy

^ permalink raw reply

* [GIT PULL] Qualcomm Device Tree updates for 4.18 - Part 2
From: Andy Gross @ 2018-05-25 22:41 UTC (permalink / raw)
  To: linux-arm-kernel

The following changes since commit 90ce62659994b87723ec6ba26815f9634c18e449:

  ARM: dts: qcom-apq8064: use correct pci address for address translation (2018-05-14 15:22:28 -0500)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git tags/qcom-dts-for-4.18-2

for you to fetch changes up to 0e4c982096f873f893d0e7b59f5abb3ef234e667:

  ARM: dts: ipq8074: Enable few peripherals for hk01 board (2018-05-25 15:40:21 -0500)

----------------------------------------------------------------
Qualcomm Device Tree Changes for v4.18 - Part 2

* Numerous updates for IPQ8074 and IPQ4019 based devices
* Add support for Sony Xperia Z1 Compact

----------------------------------------------------------------
Attila Sz?ll?si (1):
      ARM: dts: qcom: msm8974: Add Sony Xperia Z1 Compact

Sricharan R (12):
      ARM: dts: ipq4019: Add a default chosen node
      ARM: dts: ipq4019: Add a few peripheral nodes
      ARM: dts: ipq4019: Change the max opp frequency
      ARM: dts: ipq4019: Add ipq4019-ap.dk04.dtsi
      ARM: dts: ipq4019: Add ipq4019-ap.dk04.1-c1 board file
      ARM: dts: ipq4019: Add qcom-ipq4019-ap.dk04.1-c3 board file
      ARM: dts: ipq4019: Add ipq4019-ap.dk07.1 common data
      ARM: dts: ipq4019: Add qcom-ipq4019-ap.dk07.1-c1 board file
      ARM: dts: ipq4019: Add qcom-ipq4019-ap.dk07.1-c2 board file
      ARM: dts: ipq8074: Add peripheral nodes
      ARM: dts: ipq8074: Add pcie nodes
      ARM: dts: ipq8074: Enable few peripherals for hk01 board

 arch/arm/boot/dts/Makefile                         |   5 +
 arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi      |  10 +-
 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c1.dts    |  19 +
 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c3.dts    |   9 +
 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1.dtsi      | 111 ++++++
 arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c1.dts    |  64 +++
 arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c2.dts    |  25 ++
 arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1.dtsi      |  75 ++++
 arch/arm/boot/dts/qcom-ipq4019.dtsi                | 162 +++++++-
 .../boot/dts/qcom-msm8974-sony-xperia-amami.dts    | 436 +++++++++++++++++++++
 arch/arm64/boot/dts/qcom/ipq8074-hk01.dts          |  62 ++-
 arch/arm64/boot/dts/qcom/ipq8074.dtsi              | 313 ++++++++++++++-
 12 files changed, 1264 insertions(+), 27 deletions(-)
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c1.dts
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c3.dts
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1.dtsi
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c1.dts
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c2.dts
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1.dtsi
 create mode 100644 arch/arm/boot/dts/qcom-msm8974-sony-xperia-amami.dts

^ permalink raw reply

* [GIT PULL] Qualcomm ARM64 DT updates for 4.18 - Part 2
From: Andy Gross @ 2018-05-25 22:41 UTC (permalink / raw)
  To: linux-arm-kernel

The following changes since commit 57fc67ef0d35af11fbb1b928e359b370889994ae:

  arm64: dts: qcom: msm8996: Add ufs related nodes (2018-05-22 23:29:03 -0500)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git tags/qcom-arm64-for-4.18-2

for you to fetch changes up to d8f8d467f53a192041193fc17176ceb013f4d041:

  arm64: dts: apq8096-db820c: Removed bt-en-1-8v regulator (2018-05-25 16:21:05 -0500)

----------------------------------------------------------------
Qualcomm ARM64 Updates for v4.18 Part 2

* Fix UFS GDSC on msm8996
* Remove unused BT node regulator
* Correct WLAN PCIe regulator endpoint name

----------------------------------------------------------------
Bjorn Andersson (1):
      arm64: dts: qcom: msm8996: Use UFS_GDSC for UFS

Niklas Cassel (1):
      arm64: dts: fix regulator property name for wlan pcie endpoint

Thierry Escande (1):
      arm64: dts: apq8096-db820c: Removed bt-en-1-8v regulator

 arch/arm64/boot/dts/qcom/apq8096-db820c-pmic-pins.dtsi |  2 +-
 arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi           | 16 +---------------
 arch/arm64/boot/dts/qcom/msm8996.dtsi                  |  4 ++--
 3 files changed, 4 insertions(+), 18 deletions(-)

^ permalink raw reply

* [GIT PULL] Qualcomm ARM64 Defconfig updates for 4.18
From: Andy Gross @ 2018-05-25 22:34 UTC (permalink / raw)
  To: linux-arm-kernel

The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:

  Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git tags/qcom-arm64-defconfig-for-4.18

for you to fetch changes up to b741377f1ff72a17e3b06e4b506b13f5c6158b1c:

  arm64: defconfig: Enable PCIe on msm8996 and db820c (2018-05-25 15:49:12 -0500)

----------------------------------------------------------------
Qualcomm ARM64 Based defconfig Updates for v4.18

* Enable UFS and PCIe for Qualcomm msm8996/db820c

----------------------------------------------------------------
Bjorn Andersson (2):
      arm64: defconfig: Enable UFS on msm8996
      arm64: defconfig: Enable PCIe on msm8996 and db820c

 arch/arm64/configs/defconfig | 10 ++++++++++
 1 file changed, 10 insertions(+)

^ permalink raw reply

* [PATCH V2] PCI/portdrv: do not disable device on reboot/shutdown
From: okaya at codeaurora.org @ 2018-05-25 22:34 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180525221024.GC92995@bhelgaas-glaptop.roam.corp.google.com>

On 2018-05-25 15:10, Bjorn Helgaas wrote:
> On Fri, May 25, 2018 at 09:30:59AM -0400, Sinan Kaya wrote:
>> On 5/24/2018 2:35 PM, Bjorn Helgaas wrote:
>> > That sounds like a reasonable idea, and it is definitely another can
>> > of worms.  I looked briefly at some of the .shutdown() cases:
>> 
>> should we throw it into 4.18 and see what happens?
> 
> It wouldn't solve this particular problem because hpsa *does* have a
> .shutdown() method.  The problem is that it doesn't work -- it's
> supposed to stop DMA and interrupts but it apparently doesn't.
> 
> I think we need to fix hpsa first.


Absolutely, the othet patch is a parallel issue.

^ permalink raw reply

* [GIT PULL] Qualcomm Driver updates for 4.18 - RESEND
From: Andy Gross @ 2018-05-25 22:33 UTC (permalink / raw)
  To: linux-arm-kernel

The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:

  Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git tags/qcom-drivers-for-4.18

for you to fetch changes up to 6d361c1db7b69fddf5748cf212169ab57bb13a6e:

  soc: qcom: smem: introduce qcom_smem_virt_to_phys() (2018-05-25 15:53:59 -0500)

----------------------------------------------------------------
Qualcomm ARM Based Driver Updates for v4.18

* Various SMEM updates/fixes
* Add qcom_smem_virt_to_phys SMEM API
* Update MAINTAINERS to include qcom_scm pattern
* Add Qualcomm Command DB driver
* Add Qualcomm SCM compatible for IPQ4019
* Add MSM8998 to smd-rpm compatible list
* Add Qualcomm GENI based QUP wrapper
* Fix Qualcomm QMI buffer sizing bug

----------------------------------------------------------------
Alex Elder (8):
      soc: qcom: smem: fix first cache entry calculation
      soc: qcom: smem: return proper type for cached entry functions
      soc: qcom: smem: byte swap values properly
      soc: qcom: smem: fix off-by-one error in qcom_smem_alloc_private()
      soc: qcom: smem: fix qcom_smem_set_global_partition()
      soc: qcom: smem: check sooner in qcom_smem_set_global_partition()
      soc: qcom: qmi: fix a buffer sizing bug
      soc: qcom: smem: introduce qcom_smem_virt_to_phys()

Bjorn Andersson (1):
      soc: qcom: smd-rpm: Add msm8998 compatible

Guenter Roeck (1):
      soc: Unconditionally include qcom Makefile

Karthikeyan Ramasubramanian (1):
      soc: qcom: Add GENI based QUP Wrapper driver

Mahesh Sivasubramanian (1):
      drivers: qcom: add command DB driver

Niklas Cassel (1):
      MAINTAINERS: Update pattern for qcom_scm

Sricharan R (1):
      firmware: qcom: scm: Add ipq4019 soc compatible

Stephen Boyd (1):
      soc: qcom: cmd-db: Make endian-agnostic

 .../devicetree/bindings/firmware/qcom,scm.txt      |   3 +-
 .../devicetree/bindings/soc/qcom/qcom,smd-rpm.txt  |   1 +
 MAINTAINERS                                        |   2 +-
 drivers/firmware/qcom_scm.c                        |   3 +
 drivers/of/platform.c                              |   1 +
 drivers/soc/Makefile                               |   2 +-
 drivers/soc/qcom/Kconfig                           |  18 +
 drivers/soc/qcom/Makefile                          |   2 +
 drivers/soc/qcom/cmd-db.c                          | 317 +++++++++
 drivers/soc/qcom/qcom-geni-se.c                    | 748 +++++++++++++++++++++
 drivers/soc/qcom/qmi_interface.c                   |   5 +-
 drivers/soc/qcom/smd-rpm.c                         |   1 +
 drivers/soc/qcom/smem.c                            |  77 ++-
 include/linux/qcom-geni-se.h                       | 425 ++++++++++++
 include/linux/soc/qcom/smem.h                      |   2 +
 include/soc/qcom/cmd-db.h                          |  45 ++
 16 files changed, 1625 insertions(+), 27 deletions(-)
 create mode 100644 drivers/soc/qcom/cmd-db.c
 create mode 100644 drivers/soc/qcom/qcom-geni-se.c
 create mode 100644 include/linux/qcom-geni-se.h
 create mode 100644 include/soc/qcom/cmd-db.h

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox