* Re: [PATCH 0/5] can: xilinx_can: Bug fixes
From: Michal Simek @ 2019-08-12 10:57 UTC (permalink / raw)
To: Marc Kleine-Budde, Michal Simek, Appana Durga Kedareswara rao, wg,
davem
Cc: netdev, linux-kernel, linux-arm-kernel, linux-can
In-Reply-To: <cb8f91b5-174f-79e5-d476-b01da2f3a65c@pengutronix.de>
On 12. 08. 19 12:47, Marc Kleine-Budde wrote:
> On 8/12/19 12:18 PM, Michal Simek wrote:
>> On 12. 08. 19 11:10, Marc Kleine-Budde wrote:
>>> On 8/12/19 11:05 AM, Marc Kleine-Budde wrote:
>>>> On 8/12/19 9:28 AM, Appana Durga Kedareswara rao wrote:
>>>>> This patch series fixes below issues
>>>>> --> Bugs in the driver w.r.to CANFD 2.0 IP support
>>>>> --> Defer the probe if clock is not found
>>>>>
>>>>> Appana Durga Kedareswara rao (3):
>>>>> can: xilinx_can: Fix FSR register handling in the rx path
>>>>> can: xilinx_can: Fix the data updation logic for CANFD FD frames
>>>>> can: xilinx_can: Fix FSR register FL and RI mask values for canfd 2.0
>>>>>
>>>>> Srinivas Neeli (1):
>>>>> can: xilinx_can: Fix the data phase btr1 calculation
>>>>>
>>>>> Venkatesh Yadav Abbarapu (1):
>>>>> can: xilinx_can: defer the probe if clock is not found
>>>>
>>>> Please add your S-o-b to patches 4+5.
>>>>
>>>> As these all are bugfixes please add a reference to the commit it fixes:
>>>>
>>>> Fixes: commitish ("description")
>>>
>>> Add this to your ~/.gitconfig:
>>>
>>> [alias]
>>> lfixes = log --pretty=fixes
>>> [pretty]
>>> fixes = Fixes: %h (\"%s\")
>>
>> This is understandable and I have this in my .gitconfig for quite a long
>> time. And this is just log
>>
>>> and then use $(git lfixes $commitish).
>>
>> But what do you mean by this? Are you able to add this to commit message
>> just with sha1?
>
> First identify the commit that this patch fixes then go to the command
> line and enter
>
> git lfixes $committish
>
> and git will print out the line that you can copy directly to the commit
> message.
ok. I thought you have any nice way to directly add it to commit message
without c&p.
Thanks,
Michal
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [linux-sunxi] [PATCH] ARM64: dts: allwinner: Add devicetree for pine H64 modelA evaluation board
From: Jernej Škrabec @ 2019-08-12 10:56 UTC (permalink / raw)
To: linux-sunxi, clabbe.montjoie
Cc: mark.rutland, devicetree, linux-kernel, mripard, wens, robh+dt,
linux-arm-kernel
In-Reply-To: <20190808084253.10573-1-clabbe.montjoie@gmail.com>
Dne četrtek, 08. avgust 2019 ob 10:42:53 CEST je Corentin Labbe napisal(a):
> This patch adds the evaluation variant of the model A of the PineH64.
> The model A has the same size of the pine64 and has a PCIE slot.
>
> The only devicetree difference with current pineH64, is the PHY
> regulator.
I have Model A board which also needs ddc-en-gpios property for HDMI connector
in order for HDMI to work correctly. Otherwise it will just use 1024x768
resolution. Can you confirm that?
Best regards,
Jernej
>
> Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> ---
> arch/arm64/boot/dts/allwinner/Makefile | 1 +
> .../sun50i-h6-pine-h64-modelA-eval.dts | 26 +++++++++++++++++++
> 2 files changed, 27 insertions(+)
> create mode 100644
> arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-modelA-eval.dts
>
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile
> b/arch/arm64/boot/dts/allwinner/Makefile index f6db0611cb85..9a02166cbf72
> 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-pine-h64-modelA-eval.dtb
> diff --git
> a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-modelA-eval.dts
> b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-modelA-eval.dts new file
> mode 100644
> index 000000000000..d8ff02747efe
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-modelA-eval.dts
> @@ -0,0 +1,26 @@
> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> +/*
> + * Copyright (C) 2019 Corentin Labbe <clabbe.montjoie@gmail.com>
> + */
> +
> +#include "sun50i-h6-pine-h64.dts"
> +
> +/ {
> + model = "Pine H64 model A evaluation board";
> + compatible = "pine64,pine-h64-modelA-eval", "allwinner,sun50i-h6";
> +
> + reg_gmac_3v3: gmac-3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc-gmac-3v3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + startup-delay-us = <100000>;
> + gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> +};
> +
> +&emac {
> + phy-supply = <®_gmac_3v3>;
> +};
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v6 2/2] arm64: dts: allwinner: h6: Enable SPDIF for Beelink GS1
From: Clément Péron @ 2019-08-12 10:51 UTC (permalink / raw)
To: Maxime Ripard, Rob Herring
Cc: devicetree, linux-sunxi, Clément Péron, linux-kernel,
linux-arm-kernel
In-Reply-To: <20190812105115.26676-1-peron.clem@gmail.com>
Beelink GS1 board has a SPDIF out connector, so enable it in
the device-tree and add a simple SPDIF soundcard.
Signed-off-by: Clément Péron <peron.clem@gmail.com>
---
.../dts/allwinner/sun50i-h6-beelink-gs1.dts | 22 +++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
index 0dc33c90dd60..4bd14f085070 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
@@ -51,6 +51,24 @@
regulator-max-microvolt = <5000000>;
regulator-always-on;
};
+
+ sound-spdif {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "sun50i-h6-spdif";
+
+ simple-audio-card,cpu {
+ sound-dai = <&spdif>;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <&spdif_out>;
+ };
+ };
+
+ spdif_out: spdif-out {
+ #sound-dai-cells = <0>;
+ compatible = "linux,spdif-dit";
+ };
};
&de {
@@ -243,6 +261,10 @@
vcc-pm-supply = <®_aldo1>;
};
+&spdif {
+ status = "okay";
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_ph_pins>;
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v6 1/2] arm64: dts: allwinner: Add SPDIF node for Allwinner H6
From: Clément Péron @ 2019-08-12 10:51 UTC (permalink / raw)
To: Maxime Ripard, Rob Herring
Cc: devicetree, linux-sunxi, Clément Péron, linux-kernel,
linux-arm-kernel
In-Reply-To: <20190812105115.26676-1-peron.clem@gmail.com>
The Allwinner H6 has a SPDIF controller called OWA (One Wire Audio).
Only one pinmuxing is available so set it as default.
Signed-off-by: Clément Péron <peron.clem@gmail.com>
---
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
index 7628a7c83096..2ba9ab9e0924 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
@@ -282,6 +282,11 @@
bias-pull-up;
};
+ spdif_tx_pin: spdif-tx-pin {
+ pins = "PH7";
+ function = "spdif";
+ };
+
uart0_ph_pins: uart0-ph-pins {
pins = "PH0", "PH1";
function = "uart0";
@@ -411,6 +416,21 @@
};
};
+ spdif: spdif@5093000 {
+ #sound-dai-cells = <0>;
+ compatible = "allwinner,sun50i-h6-spdif";
+ reg = <0x05093000 0x400>;
+ interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_SPDIF>, <&ccu CLK_SPDIF>;
+ clock-names = "apb", "spdif";
+ resets = <&ccu RST_BUS_SPDIF>;
+ dmas = <&dma 2>;
+ dma-names = "tx";
+ pinctrl-names = "default";
+ pinctrl-0 = <&spdif_tx_pin>;
+ status = "disabled";
+ };
+
usb2otg: usb@5100000 {
compatible = "allwinner,sun50i-h6-musb",
"allwinner,sun8i-a33-musb";
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v6 0/2] Allwinner H6 SPDIF support
From: Clément Péron @ 2019-08-12 10:51 UTC (permalink / raw)
To: Maxime Ripard, Rob Herring
Cc: devicetree, linux-sunxi, Clément Péron, linux-kernel,
linux-arm-kernel
Allwinner H6 SoC has a SPDIF controller called One Wire Audio (OWA) which
is different from the previous H3 generation and not compatible.
Difference are an increase of fifo sizes, some memory mapping are different
and there is now the possibility to output the master clock on a pin.
Actually all these features are unused and only a bit for flushing the TX
fifo is required.
Changes since v5:
- Move soundcard to board device-tree
Changes since v4:
- rename audio card name to sun50i-h6-spdif
- drop patches already merged
Changes since v3:
- rename reg_fctl_ftx to val_fctl_ftx
- rebase this series on sound-next
- fix dt-bindings due to change in sound-next
- change node name sound_spdif to sound-spdif
Changes since v2:
- Split quirks and H6 support patch
- Add specific section for quirks comment
Changes since v1:
- Remove H3 compatible
- Add TX fifo bit flush quirks
- Add H6 bindings in SPDIF driver
Clément Péron (2):
arm64: dts: allwinner: Add SPDIF node for Allwinner H6
arm64: dts: allwinner: h6: Enable SPDIF for Beelink GS1
.../dts/allwinner/sun50i-h6-beelink-gs1.dts | 22 +++++++++++++++++++
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 20 +++++++++++++++++
2 files changed, 42 insertions(+)
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/6] pwm: sun4i: Add support for H6 PWM
From: Jernej Škrabec @ 2019-08-12 10:51 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Mark Rutland, linux-pwm, devicetree, linux-sunxi, linux-kernel,
Maxime Ripard, Chen-Yu Tsai, Rob Herring, Thierry Reding, kernel,
Frank Rowand, linux-arm-kernel
In-Reply-To: <20190812104700.vzpdxx3yddthiif5@pengutronix.de>
Dne ponedeljek, 12. avgust 2019 ob 12:47:00 CEST je Uwe Kleine-König
napisal(a):
> Hello Maxime,
>
> the idea of my mail was to summarize quickly the discussion for the dt
> people to give their judgement to stop us circling in a discussion about
> the always same points.
>
> I suggest we stop the discussion here now and wait for a reply from them
> instead.
Shouldn't we just go with compromise solution you suggested and Maxime
accepted? I would like to send new version in time for 5.4.
Best regards,
Jernej
>
> Best regards
> Uwe
_______________________________________________
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] coresight: Serialize enabling/disabling a link device.
From: Suzuki K Poulose @ 2019-08-12 10:48 UTC (permalink / raw)
To: yabinc, mathieu.poirier, alexander.shishkin
Cc: linux-kernel, linux-arm-kernel
In-Reply-To: <056f411f-eef2-752e-0c02-2e5ed803cc62@arm.com>
Hi Yabin,
On 12/08/2019 11:38, Suzuki K Poulose wrote:
>
> Hi Yabin,
>
> On 09/08/2019 22:45, Yabin Cui wrote:
>> When tracing etm data of multiple threads on multiple cpus through perf
>> interface, some link devices are shared between paths of different cpus.
>> It creates race conditions when different cpus wants to enable/disable
>> the same link device at the same time.
>>
>> Example 1:
>> Two cpus want to enable different ports of a coresight funnel, thus
>> calling the funnel enable operation at the same time. But the funnel
>> enable operation isn't reentrantable.
>>
>> Example 2:
>> For an enabled coresight dynamic replicator with refcnt=1, one cpu wants
>> to disable it, while another cpu wants to enable it. Ideally we still have
>> an enabled replicator with refcnt=1 at the end. But in reality the result
>> is uncertain.
>>
>> Since coresight devices claim themselves when enabled for self-hosted
>> usage, the race conditions above usually make the link devices not usable
>> after many cycles.
>>
>> To fix the race conditions, this patch adds a spinlock to serialize
>> enabling/disabling a link device.
Please could you also add :
Fixes : a06ae8609b3dd ("coresight: add CoreSight core layer framework")
Suzuki
_______________________________________________
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/5] can: xilinx_can: Bug fixes
From: Marc Kleine-Budde @ 2019-08-12 10:47 UTC (permalink / raw)
To: Michal Simek, Appana Durga Kedareswara rao, wg, davem
Cc: netdev, linux-kernel, linux-arm-kernel, linux-can
In-Reply-To: <f0e3360d-7c9a-a455-f63c-7fb584dfad2f@xilinx.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 1883 bytes --]
On 8/12/19 12:18 PM, Michal Simek wrote:
> On 12. 08. 19 11:10, Marc Kleine-Budde wrote:
>> On 8/12/19 11:05 AM, Marc Kleine-Budde wrote:
>>> On 8/12/19 9:28 AM, Appana Durga Kedareswara rao wrote:
>>>> This patch series fixes below issues
>>>> --> Bugs in the driver w.r.to CANFD 2.0 IP support
>>>> --> Defer the probe if clock is not found
>>>>
>>>> Appana Durga Kedareswara rao (3):
>>>> can: xilinx_can: Fix FSR register handling in the rx path
>>>> can: xilinx_can: Fix the data updation logic for CANFD FD frames
>>>> can: xilinx_can: Fix FSR register FL and RI mask values for canfd 2.0
>>>>
>>>> Srinivas Neeli (1):
>>>> can: xilinx_can: Fix the data phase btr1 calculation
>>>>
>>>> Venkatesh Yadav Abbarapu (1):
>>>> can: xilinx_can: defer the probe if clock is not found
>>>
>>> Please add your S-o-b to patches 4+5.
>>>
>>> As these all are bugfixes please add a reference to the commit it fixes:
>>>
>>> Fixes: commitish ("description")
>>
>> Add this to your ~/.gitconfig:
>>
>> [alias]
>> lfixes = log --pretty=fixes
>> [pretty]
>> fixes = Fixes: %h (\"%s\")
>
> This is understandable and I have this in my .gitconfig for quite a long
> time. And this is just log
>
>> and then use $(git lfixes $commitish).
>
> But what do you mean by this? Are you able to add this to commit message
> just with sha1?
First identify the commit that this patch fixes then go to the command
line and enter
git lfixes $committish
and git will print out the line that you can copy directly to the commit
message.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 4/6] pwm: sun4i: Add support for H6 PWM
From: Uwe Kleine-König @ 2019-08-12 10:47 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, linux-pwm, Jernej Škrabec, devicetree,
linux-sunxi, linux-kernel, Chen-Yu Tsai, Rob Herring,
Thierry Reding, kernel, Frank Rowand, linux-arm-kernel
In-Reply-To: <20190812095648.wuefcr2mep3dpkth@flea>
Hello Maxime,
the idea of my mail was to summarize quickly the discussion for the dt
people to give their judgement to stop us circling in a discussion about
the always same points.
I suggest we stop the discussion here now and wait for a reply from them
instead.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 1/2] arm64: Define Documentation/arm64/tagged-address-abi.rst
From: Andrew Murray @ 2019-08-12 10:46 UTC (permalink / raw)
To: Will Deacon
Cc: linux-arch, linux-doc, Szabolcs Nagy, Catalin Marinas,
Kevin Brodsky, Will Deacon, Dave Hansen, Andrey Konovalov,
Vincenzo Frascino, linux-arm-kernel
In-Reply-To: <20190808170424.6td34cpdngkcxxpu@willie-the-truck>
On Thu, Aug 08, 2019 at 06:04:24PM +0100, Will Deacon wrote:
> On Wed, Aug 07, 2019 at 04:53:20PM +0100, Catalin Marinas wrote:
> > From: Vincenzo Frascino <vincenzo.frascino@arm.com>
> >
> > On arm64 the TCR_EL1.TBI0 bit has been always enabled hence
> > the userspace (EL0) is allowed to set a non-zero value in the
> > top byte but the resulting pointers are not allowed at the
> > user-kernel syscall ABI boundary.
> >
> > With the relaxed ABI proposed through this document, it is now possible
> > to pass tagged pointers to the syscalls, when these pointers are in
> > memory ranges obtained by an anonymous (MAP_ANONYMOUS) mmap().
> >
> > This change in the ABI requires a mechanism to requires the userspace
> > to opt-in to such an option.
> >
> > Specify and document the way in which sysctl and prctl() can be used
> > in combination to allow the userspace to opt-in this feature.
> >
> > Cc: Will Deacon <will.deacon@arm.com>
> > Cc: Andrey Konovalov <andreyknvl@google.com>
> > Cc: Szabolcs Nagy <szabolcs.nagy@arm.com>
> > Cc: Kevin Brodsky <kevin.brodsky@arm.com>
> > Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
> > [catalin.marinas@arm.com: some rewording, dropped MAP_PRIVATE]
> > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > ---
> > Documentation/arm64/tagged-address-abi.rst | 151 +++++++++++++++++++++
> > 1 file changed, 151 insertions(+)
> > create mode 100644 Documentation/arm64/tagged-address-abi.rst
> >
> > diff --git a/Documentation/arm64/tagged-address-abi.rst b/Documentation/arm64/tagged-address-abi.rst
> > new file mode 100644
> > index 000000000000..f91a5d2ac865
> > --- /dev/null
> > +++ b/Documentation/arm64/tagged-address-abi.rst
> > @@ -0,0 +1,151 @@
> > +==========================
> > +AArch64 TAGGED ADDRESS ABI
> > +==========================
> > +
> > +Author: Vincenzo Frascino <vincenzo.frascino@arm.com>
> > +
> > +Date: 25 July 2019
> > +
> > +This document describes the usage and semantics of the Tagged Address
> > +ABI on AArch64 Linux.
> > +
> > +1. Introduction
> > +---------------
> > +
> > +On AArch64 the TCR_EL1.TBI0 bit has always been enabled, allowing userspace
> > +(EL0) to perform memory accesses through 64-bit pointers with a non-zero
> > +top byte. Such tagged pointers, however, were not allowed at the
> > +user-kernel syscall ABI boundary.
>
> I think we should drop the temporal language, so:
>
> "has always been enabled" => "is set by the kernel"
> "were not allowed" => "are not allowed by default"
>
> > +
> > +This document describes the relaxation of the syscall ABI that allows
> > +userspace to pass certain tagged pointers to kernel syscalls, as described
> > +in section 2.
> > +
> > +2. AArch64 Tagged Address ABI
> > +-----------------------------
> > +
> > +From the kernel syscall interface perspective and for the purposes of this
> > +document, a "valid tagged pointer" is a pointer with a potentially non-zero
> > +top-byte that references an address in the user process address space
> > +obtained in one of the following ways:
> > +
> > +- mmap() done by the process itself (or its parent), where either:
> > +
> > + - flags have the **MAP_ANONYMOUS** bit set
> > + - the file descriptor refers to a regular file (including those returned
> > + by memfd_create()) or **/dev/zero**
> > +
> > +- brk() system call done by the process itself (i.e. the heap area between
> > + the initial location of the program break at process creation and its
> > + current location).
> > +
> > +- any memory mapped by the kernel in the address space of the process
> > + during creation and with the same restrictions as for mmap() above (e.g.
> > + data, bss, stack).
> > +
> > +The AArch64 Tagged Address ABI is an opt-in feature and an application can
> > +control it via **prctl()** as follows:
> > +
> > +- **PR_SET_TAGGED_ADDR_CTRL**: enable or disable the AArch64 Tagged Address
> > + ABI for the calling process.
> > +
> > + The (unsigned int) arg2 argument is a bit mask describing the control mode
> > + used:
> > +
> > + - **PR_TAGGED_ADDR_ENABLE**: enable AArch64 Tagged Address ABI. Default
> > + status is disabled.
> > +
> > + The arguments arg3, arg4, and arg5 are ignored.
> > +
> > +- **PR_GET_TAGGED_ADDR_CTRL**: get the status of the AArch64 Tagged Address
> > + ABI for the calling process.
> > +
> > + The arguments arg2, arg3, arg4, and arg5 are ignored.
>
> I agree with Dave (H) that we should require these to be zero. We may be
> able to use arg2 to namespace things for PR_SET_TAGGED_ADDR_CTRL, but for
> PR_GET_TAGGED_ADDR_CTRL we'd have to add a new prctl if we wanted to extend
> it otherwise.
>
> > +The prctl(PR_SET_TAGGED_ADDR_CTRL, ...) will return -EINVAL if the
>
> *The* prctl? Maybe "Calling prctl(..." is better?
>
> > +AArch64 Tagged Address ABI is not available
> > +(CONFIG_ARM64_TAGGED_ADDR_ABI disabled or sysctl abi.tagged_addr=0).
>
> drop the brackets and say "because CONFIG_... is disabled or ..".
>
> > +
> > +The ABI properties set by the mechanism described above are inherited by
> > +threads of the same application and fork()'ed children but cleared by
> > +execve().
>
> Maybe just exec() here, since there are other flavours we shouldn't need to
> enumerate.
>
> > +Opting in (the prctl() option described above only) to or out of the
> > +AArch64 Tagged Address ABI can be disabled globally at runtime using the
> > +sysctl interface:
>
> This sentence reads really badly thanks to the random bracketed part.
>
> > +
> > +- **abi.tagged_addr**: a new sysctl interface that can be used to prevent
> > + applications from enabling or disabling the relaxed ABI. The sysctl
> > + supports the following configuration options:
> > +
> > + - **0**: disable the prctl(PR_SET_TAGGED_ADDR_CTRL) option to
> > + enable/disable the AArch64 Tagged Address ABI globally
>
> This is clunky because it sounds like we're enabling the ABI for everybody,
> where in actual fact we're enabling the controls for the ABI instead. It
> also applies equally to PR_GET_TAGGED_ADDR_CTRL (but see below). Given that
> we've already defined the prctl() above, I think we can just say:
>
> **0**: AArch64 Tagged Address ABI prctl() calls will return -EINVAL
> **1**: AArch64 Tagged Address ABI prctl() calls will behave as documented above.
>
> > + - **1** (Default): enable the prctl(PR_SET_TAGGED_ADDR_CTRL) option to
> > + enable/disable the AArch64 Tagged Address ABI globally
> > +
> > + Note that this sysctl does not affect the status of the AArch64 Tagged
> > + Address ABI of the running processes.
>
> Hmm, but it does mean that you can no longer ask if a previously running
> process is using tags. Is that intentional?
>
> > +When a process has successfully enabled the new ABI by invoking
> > +prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE), the following
> > +behaviours are guaranteed:
>
> nit: this also applies to processes that have inherited the new ABI
> bevaiour via fork() and haven't invoked the prctl() themselves.
>
> > +- Every currently available syscall, except the cases mentioned in section
>
> "currently available" is meaningless and should be removed
>
> > + 3, can accept any valid tagged pointer. The same rule is applicable to
> > + any syscall introduced in the future.
>
> Delete this last sentence.
>
> > +- The syscall behaviour is undefined for non valid tagged pointers.
>
> non valid => invalid
>
> although this needs to be better defined, I think.
>
> > +
> > +- Every valid tagged pointer is expected to work as an untagged one.
>
> What does that mean? Expected by who? What does "work" mean?
>
> > +A definition of the meaning of tagged pointers on AArch64 can be found in:
> > +Documentation/arm64/tagged-pointers.txt.
>
> .txt => .rst
>
> > +
> > +3. AArch64 Tagged Address ABI Exceptions
> > +-----------------------------------------
> > +
> > +The behaviour described in section 2, with particular reference to the
> > +acceptance by the syscalls of any valid tagged pointer, is not applicable
> > +to the following cases:
>
> Jeez louise...
>
> How about: "The following system call parameters must be untagged, regardless
> of the ABI relaxation:"
>
> > +
> > +- mmap() addr parameter.
> > +
> > +- mremap() new_address parameter.
> > +
> > +- prctl(PR_SET_MM, ``*``, ...) other than arg2 PR_SET_MM_MAP and
> > + PR_SET_MM_MAP_SIZE.
> > +
> > +- prctl(PR_SET_MM, PR_SET_MM_MAP{,_SIZE}, ...) struct prctl_mm_map fields.
>
> How did you generate this list and who will keep it up to date? How do you
> know you haven't missed anything?
What about shared memory system calls: shmat, shmdt? The latest "arm64: untag
user pointers passed to the kernel" series doesn't untag these, thus we should
indicate here that these too are no supported.
Thanks,
Andrew Murray
>
> > +Any attempt to use non-zero tagged pointers will lead to undefined
> > +behaviour.
>
> In the tagged pointer document we're slightly more specific and say that
> using non-zero address tags "may result in an error code being returned, a
> (fatal) signal being rasied, or other modes of failure". Maybe reuse that?
>
> > +4. Example of correct usage
> > +---------------------------
> > +.. code-block:: c
> > +
> > + void main(void)
> > + {
> > + static int tbi_enabled = 0;
> > + unsigned long tag = 0;
> > +
>
> Some comments won't go amiss here.
>
> > + char *ptr = mmap(NULL, PAGE_SIZE, PROT_READ | PROT_WRITE,
> > + MAP_ANONYMOUS, -1, 0);
> > +
> > + if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE,
> > + 0, 0, 0) == 0)
> > + tbi_enabled = 1;
> > +
> > + if (ptr == (void *)-1) /* MAP_FAILED */
> > + return -1;
> > +
> > + if (tbi_enabled)
> > + tag = rand() & 0xff;
> > +
> > + ptr = (char *)((unsigned long)ptr | (tag << TAG_SHIFT));
> > +
> > + *ptr = 'a';
> > +
> > + ...
> > + }
>
> Hmm, doesn't this snippet work today? You're not actually passing the
> tagged pointer back to the kernel...
>
> Will
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
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] coresight: tmc-etr: Fix perf_data check.
From: Suzuki K Poulose @ 2019-08-12 10:45 UTC (permalink / raw)
To: yabinc, mathieu.poirier, alexander.shishkin
Cc: linux-kernel, linux-arm-kernel
In-Reply-To: <20190809202330.51183-1-yabinc@google.com>
On 09/08/2019 21:23, Yabin Cui wrote:
> When tracing etm data of multiple threads on multiple cpus through
> perf interface, each cpu has a unique etr_perf_buffer while sharing
> the same etr device. There is no guarantee that the last cpu starts
> etm tracing also stops last. This makes perf_data check fail.
>
> Fix it by checking etr_buf instead of etr_perf_buffer.
Please could you add a Fixes tag for this:
Fixes: 3147da92a8a81fc3 ("coresight: tmc-etr: Allocate and free ETR memory
buffers for CPU-wide scenarios")
as the problem was introduced as a side effect of the above patch ?
>
> Signed-off-by: Yabin Cui <yabinc@google.com>
> ---
> drivers/hwtracing/coresight/coresight-tmc-etr.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> index 17006705287a..f466f05afe08 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> @@ -1484,7 +1484,7 @@ tmc_update_etr_buffer(struct coresight_device *csdev,
> goto out;
> }
>
> - if (WARN_ON(drvdata->perf_data != etr_perf)) {
> + if (WARN_ON(drvdata->perf_data != etr_buf)) {
> lost = true;
> spin_unlock_irqrestore(&drvdata->spinlock, flags);
> goto out;
> @@ -1556,7 +1556,7 @@ static int tmc_enable_etr_sink_perf(struct coresight_device *csdev, void *data)
> }
>
> etr_perf->head = PERF_IDX2OFF(handle->head, etr_perf);
> - drvdata->perf_data = etr_perf;
> + drvdata->perf_data = etr_perf->etr_buf;
minor nit: Now that we are storing the etr_buf instead of the etr_perf_buf in
perf_data, we could make the "perf_data" => "perf_buf" inline with the
sysfs_buf.
Either ways:
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] iommu/arm-smmu-v3: add nr_ats_masters to avoid unnecessary operations
From: John Garry @ 2019-08-12 10:42 UTC (permalink / raw)
To: Zhen Lei, Jean-Philippe Brucker, Robin Murphy, Will Deacon,
Joerg Roedel, linux-arm-kernel, iommu, linux-kernel,
jean-philippe
In-Reply-To: <20190801122040.26024-1-thunder.leizhen@huawei.com>
On 01/08/2019 13:20, Zhen Lei wrote:
> When (smmu_domain->smmu->features & ARM_SMMU_FEAT_ATS) is true, even if a
> smmu domain does not contain any ats master, the operations of
> arm_smmu_atc_inv_to_cmd() and lock protection in arm_smmu_atc_inv_domain()
> are always executed. This will impact performance, especially in
> multi-core and stress scenarios. For my FIO test scenario, about 8%
> performance reduced.
>
> In fact, we can use a atomic member to record how many ats masters the
> smmu contains. And check that without traverse the list and check all
> masters one by one in the lock protection.
>
Hi Will, Robin, Jean-Philippe,
Can you kindly check this issue? We have seen a signifigant performance
regression here.
Thanks!
> Fixes: 9ce27afc0830 ("iommu/arm-smmu-v3: Add support for PCI ATS")
> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
> ---
> drivers/iommu/arm-smmu-v3.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> index a9a9fabd396804a..1b370d9aca95f94 100644
> --- a/drivers/iommu/arm-smmu-v3.c
> +++ b/drivers/iommu/arm-smmu-v3.c
> @@ -631,6 +631,7 @@ struct arm_smmu_domain {
>
> struct io_pgtable_ops *pgtbl_ops;
> bool non_strict;
> + atomic_t nr_ats_masters;
It's not ideal to keep a separate count of ats masters...hmmm
>
> enum arm_smmu_domain_stage stage;
> union {
> @@ -1531,7 +1532,7 @@ static int arm_smmu_atc_inv_domain(struct arm_smmu_domain *smmu_domain,
> struct arm_smmu_cmdq_ent cmd;
> struct arm_smmu_master *master;
>
> - if (!(smmu_domain->smmu->features & ARM_SMMU_FEAT_ATS))
> + if (!atomic_read(&smmu_domain->nr_ats_masters))
> return 0;
The rest of the code is here:
arm_smmu_atc_inv_to_cmd(ssid, iova, size, &cmd);
spin_lock_irqsave(&smmu_domain->devices_lock, flags);
list_for_each_entry(master, &smmu_domain->devices, domain_head)
ret |= arm_smmu_atc_inv_master(master, &cmd);
spin_unlock_irqrestore(&smmu_domain->devices_lock, flags);
return ret ? -ETIMEDOUT : 0;
}
Not directly related to leizhen's issue: Could RCU protection be used
for this list iteration? I can't imagine that the devices list changes
often. And also we already protect the cmdq in arm_smmu_atc_inv_master().
>
> arm_smmu_atc_inv_to_cmd(ssid, iova, size, &cmd);
> @@ -1869,6 +1870,7 @@ static int arm_smmu_enable_ats(struct arm_smmu_master *master)
> size_t stu;
> struct pci_dev *pdev;
> struct arm_smmu_device *smmu = master->smmu;
> + struct arm_smmu_domain *smmu_domain = master->domain;
> struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(master->dev);
>
> if (!(smmu->features & ARM_SMMU_FEAT_ATS) || !dev_is_pci(master->dev) ||
> @@ -1887,12 +1889,15 @@ static int arm_smmu_enable_ats(struct arm_smmu_master *master)
> return ret;
>
> master->ats_enabled = true;
> + atomic_inc(&smmu_domain->nr_ats_masters);
> +
> return 0;
> }
>
> static void arm_smmu_disable_ats(struct arm_smmu_master *master)
> {
> struct arm_smmu_cmdq_ent cmd;
> + struct arm_smmu_domain *smmu_domain = master->domain;
>
> if (!master->ats_enabled || !dev_is_pci(master->dev))
> return;
> @@ -1901,6 +1906,7 @@ static void arm_smmu_disable_ats(struct arm_smmu_master *master)
> arm_smmu_atc_inv_master(master, &cmd);
> pci_disable_ats(to_pci_dev(master->dev));
> master->ats_enabled = false;
> + atomic_dec(&smmu_domain->nr_ats_masters);
> }
>
> static void arm_smmu_detach_dev(struct arm_smmu_master *master)
> @@ -1915,10 +1921,10 @@ static void arm_smmu_detach_dev(struct arm_smmu_master *master)
> list_del(&master->domain_head);
> spin_unlock_irqrestore(&smmu_domain->devices_lock, flags);
>
> - master->domain = NULL;
> arm_smmu_install_ste_for_dev(master);
>
> arm_smmu_disable_ats(master);
> + master->domain = NULL;
> }
>
> static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
>
_______________________________________________
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 9/9] arm64: Retrieve stolen time as paravirtualized guest
From: Steven Price @ 2019-08-12 10:39 UTC (permalink / raw)
To: Zenghui Yu
Cc: kvm, linux-doc, Catalin Marinas, Russell King, linux-kernel,
Marc Zyngier, Paolo Bonzini, Will Deacon, kvmarm,
linux-arm-kernel
In-Reply-To: <5d763c8e-9c06-c448-2644-25bfa0e57e8c@huawei.com>
On 09/08/2019 14:51, Zenghui Yu wrote:
[...]
> Hi Steven,
>
> Since userspace is not involved yet (right?), no one will create the
> PV_TIME device for guest (and no one will specify the IPA of the shared
> stolen time region), and I guess we will get a "not supported" error
> here.
>
> So what should we do if we want to test this series now? Any userspace
> tools? If no, do you have any plans for userspace developing? ;-)
At the moment I have the following patch to kvmtool which creates the
PV_TIME device - this isn't in a state to go upstream, and Marc has
asked that I rework the memory allocation, so this will need to change.
It's a little ugly as it simply reserves the first page of RAM to use
for the PV time structures.
----8<----
diff --git a/Makefile b/Makefile
index 3862112..a79956b 100644
--- a/Makefile
+++ b/Makefile
@@ -158,7 +158,7 @@ endif
# ARM
OBJS_ARM_COMMON := arm/fdt.o arm/gic.o arm/gicv2m.o arm/ioport.o \
arm/kvm.o arm/kvm-cpu.o arm/pci.o arm/timer.o \
- arm/pmu.o
+ arm/pmu.o arm/pvtime.o
HDRS_ARM_COMMON := arm/include
ifeq ($(ARCH), arm)
DEFINES += -DCONFIG_ARM
diff --git a/arm/fdt.c b/arm/fdt.c
index c80e6da..19eccbc 100644
--- a/arm/fdt.c
+++ b/arm/fdt.c
@@ -119,6 +119,7 @@ static int setup_fdt(struct kvm *kvm)
/* Create new tree without a reserve map */
_FDT(fdt_create(fdt, FDT_MAX_SIZE));
+ _FDT(fdt_add_reservemap_entry(fdt, kvm->arch.memory_guest_start, 4096));
_FDT(fdt_finish_reservemap(fdt));
/* Header */
diff --git a/arm/kvm.c b/arm/kvm.c
index 1f85fc6..8bbfef1 100644
--- a/arm/kvm.c
+++ b/arm/kvm.c
@@ -11,6 +11,8 @@
#include <linux/kvm.h>
#include <linux/sizes.h>
+int pvtime_create(struct kvm *kvm);
+
struct kvm_ext kvm_req_ext[] = {
{ DEFINE_KVM_EXT(KVM_CAP_IRQCHIP) },
{ DEFINE_KVM_EXT(KVM_CAP_ONE_REG) },
@@ -86,6 +88,10 @@ void kvm__arch_init(struct kvm *kvm, const char *hugetlbfs_path, u64 ram_size)
/* Create the virtual GIC. */
if (gic__create(kvm, kvm->cfg.arch.irqchip))
die("Failed to create virtual GIC");
+
+ /* Setup PV time */
+ if (pvtime_create(kvm))
+ die("Failed to initialise PV time");
}
#define FDT_ALIGN SZ_2M
diff --git a/arm/pvtime.c b/arm/pvtime.c
new file mode 100644
index 0000000..abcaab3
--- /dev/null
+++ b/arm/pvtime.c
@@ -0,0 +1,77 @@
+#include "kvm/kvm.h"
+
+#define KVM_DEV_TYPE_ARM_PV_TIME (KVM_DEV_TYPE_ARM_VGIC_ITS+2)
+
+/* Device Control API: PV_TIME */
+#define KVM_DEV_ARM_PV_TIME_PADDR 0
+#define KVM_DEV_ARM_PV_TIME_FREQUENCY 3
+
+#define KVM_DEV_ARM_PV_TIME_ST 0
+#define KVM_DEV_ARM_PV_TIME_LPT 1
+
+static int pvtime_fd;
+
+int pvtime_create(struct kvm *kvm);
+
+int pvtime_create(struct kvm *kvm)
+{
+ int err;
+ u64 lpt_paddr = 0x10000000;
+ u64 st_paddr = lpt_paddr + 4096;
+ u32 frequency = 100 * 1000 * 1000;
+
+ printf("lpt_paddr=%llx\n", lpt_paddr);
+
+ struct kvm_create_device pvtime_device = {
+ .type = KVM_DEV_TYPE_ARM_PV_TIME,
+ .flags = 0,
+ };
+
+ err = ioctl(kvm->vm_fd, KVM_CREATE_DEVICE, &pvtime_device);
+ if (err) {
+ printf("Failed to create PV device\n");
+ return 0;
+ }
+
+ pvtime_fd = pvtime_device.fd;
+
+ struct kvm_device_attr lpt_base = {
+ .group = KVM_DEV_ARM_PV_TIME_PADDR,
+ .attr = KVM_DEV_ARM_PV_TIME_LPT,
+ .addr = (u64)(unsigned long)&lpt_paddr
+ };
+ struct kvm_device_attr st_base = {
+ .group = KVM_DEV_ARM_PV_TIME_PADDR,
+ .attr = KVM_DEV_ARM_PV_TIME_ST,
+ .addr = (u64)(unsigned long)&st_paddr
+ };
+
+ struct kvm_device_attr lpt_freq = {
+ .group = KVM_DEV_ARM_PV_TIME_FREQUENCY,
+ .attr = KVM_DEV_ARM_PV_TIME_LPT,
+ .addr = (u64)(unsigned long)&frequency
+ };
+
+ err = ioctl(pvtime_fd, KVM_SET_DEVICE_ATTR, &lpt_base);
+ if (err) {
+ perror("ioctl lpt_base failed");
+ printf("Ignoring LPT...\n");
+ }
+ err = ioctl(pvtime_fd, KVM_SET_DEVICE_ATTR, &st_base);
+ if (err) {
+ perror("ioctl st_base failed");
+ goto out_err;
+ }
+ err = ioctl(pvtime_fd, KVM_SET_DEVICE_ATTR, &lpt_freq);
+ if (err) {
+ perror("ioctl lpt_freq failed");
+ printf("Ignoring LPT...\n");
+ }
+
+ printf("PV time setup\n");
+
+ return 0;
+out_err:
+ close(pvtime_fd);
+ return err;
+}
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2] coresight: Serialize enabling/disabling a link device.
From: Suzuki K Poulose @ 2019-08-12 10:38 UTC (permalink / raw)
To: yabinc, mathieu.poirier, alexander.shishkin
Cc: linux-kernel, linux-arm-kernel
In-Reply-To: <20190809214538.29677-1-yabinc@google.com>
Hi Yabin,
On 09/08/2019 22:45, Yabin Cui wrote:
> When tracing etm data of multiple threads on multiple cpus through perf
> interface, some link devices are shared between paths of different cpus.
> It creates race conditions when different cpus wants to enable/disable
> the same link device at the same time.
>
> Example 1:
> Two cpus want to enable different ports of a coresight funnel, thus
> calling the funnel enable operation at the same time. But the funnel
> enable operation isn't reentrantable.
>
> Example 2:
> For an enabled coresight dynamic replicator with refcnt=1, one cpu wants
> to disable it, while another cpu wants to enable it. Ideally we still have
> an enabled replicator with refcnt=1 at the end. But in reality the result
> is uncertain.
>
> Since coresight devices claim themselves when enabled for self-hosted
> usage, the race conditions above usually make the link devices not usable
> after many cycles.
>
> To fix the race conditions, this patch adds a spinlock to serialize
> enabling/disabling a link device.
>
> Signed-off-by: Yabin Cui <yabinc@google.com>
> ---
>
> v1 -> v2: extend lock range to protect read of refcnt in
> coresight_disable_link().
Thanks for this. Please find my comments below.
>
> ---
> drivers/hwtracing/coresight/coresight.c | 12 +++++++++++-
> include/linux/coresight.h | 3 +++
> 2 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
> index 55db77f6410b..e526bdeaeb22 100644
> --- a/drivers/hwtracing/coresight/coresight.c
> +++ b/drivers/hwtracing/coresight/coresight.c
> @@ -256,6 +256,7 @@ static int coresight_enable_link(struct coresight_device *csdev,
> int ret;
> int link_subtype;
> int refport, inport, outport;
> + unsigned long flags;
>
> if (!parent || !child)
> return -EINVAL;
> @@ -274,15 +275,18 @@ static int coresight_enable_link(struct coresight_device *csdev,
> if (refport < 0)
> return refport;
>
> + spin_lock_irqsave(&csdev->spinlock, flags);
> if (atomic_inc_return(&csdev->refcnt[refport]) == 1) {
> if (link_ops(csdev)->enable) {
> ret = link_ops(csdev)->enable(csdev, inport, outport);
> if (ret) {
> atomic_dec(&csdev->refcnt[refport]);
> + spin_unlock_irqrestore(&csdev->spinlock, flags);
> return ret;
> }
> }
> }
> + spin_unlock_irqrestore(&csdev->spinlock, flags);
>
> csdev->enable = true;
Please could we move this inside the spin_lock () too ?
>
> @@ -296,6 +300,7 @@ static void coresight_disable_link(struct coresight_device *csdev,
> int i, nr_conns;
> int link_subtype;
> int refport, inport, outport;
> + unsigned long flags;
>
> if (!parent || !child)
> return;
> @@ -315,14 +320,18 @@ static void coresight_disable_link(struct coresight_device *csdev,
> nr_conns = 1;
> }
>
> + spin_lock_irqsave(&csdev->spinlock, flags);
> if (atomic_dec_return(&csdev->refcnt[refport]) == 0) {
> if (link_ops(csdev)->disable)
> link_ops(csdev)->disable(csdev, inport, outport);
> }
>
> for (i = 0; i < nr_conns; i++)
> - if (atomic_read(&csdev->refcnt[i]) != 0)
> + if (atomic_read(&csdev->refcnt[i]) != 0) {
> + spin_unlock_irqrestore(&csdev->spinlock, flags);
> return;
> + }
> + spin_unlock_irqrestore(&csdev->spinlock, flags);
>
> csdev->enable = false;
> }
And this too ? I understand this may not be used right now, but we can avoid any
surprises when we do so.
With the above fixed, :
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [EXT] Re: [PATCHv3 1/2] PCI: layerscape: Add the bar_fixed_64bit property in EP driver.
From: Xiaowei Bao @ 2019-08-12 10:39 UTC (permalink / raw)
To: Lorenzo Pieralisi, kishon@ti.com
Cc: mark.rutland@arm.com, Roy Zang, arnd@arndb.de,
devicetree@vger.kernel.org, gregkh@linuxfoundation.org,
kstewart@linuxfoundation.org, linuxppc-dev@lists.ozlabs.org,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Leo Li,
M.h. Lian, robh+dt@kernel.org,
linux-arm-kernel@lists.infradead.org, pombredanne@nexb.com,
bhelgaas@google.com, shawnguo@kernel.org,
shawn.lin@rock-chips.com, Mingkai Hu
In-Reply-To: <20190812101213.GB20861@e121166-lin.cambridge.arm.com>
> -----Original Message-----
> From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Sent: 2019年8月12日 18:12
> To: Xiaowei Bao <xiaowei.bao@nxp.com>; kishon@ti.com
> Cc: bhelgaas@google.com; robh+dt@kernel.org; mark.rutland@arm.com;
> shawnguo@kernel.org; Leo Li <leoyang.li@nxp.com>; arnd@arndb.de;
> gregkh@linuxfoundation.org; M.h. Lian <minghuan.lian@nxp.com>; Mingkai
> Hu <mingkai.hu@nxp.com>; Roy Zang <roy.zang@nxp.com>;
> kstewart@linuxfoundation.org; pombredanne@nexb.com;
> shawn.lin@rock-chips.com; linux-pci@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org
> Subject: [EXT] Re: [PATCHv3 1/2] PCI: layerscape: Add the bar_fixed_64bit
> property in EP driver.
>
> Caution: EXT Email
>
> First off:
>
> Trim the CC list, you CC'ed maintainers (and mailing lists) for no reasons
> whatsover.
[Xiaowei Bao]Hi Lorenzo, I am not clear why the mail list is the CC, I use the command "git send-email --to", I will try to send the patch again, do I need to modify the version is v4 when I send this patch again?
>
> Then, read this:
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.ke
> rnel.org%2Flinux-pci%2F20171026223701.GA25649%40bhelgaas-glaptop.roa
> m.corp.google.com%2F&data=02%7C01%7Cxiaowei.bao%40nxp.com%7
> C1c586178e23c423a0e8808d71f0d8f6f%7C686ea1d3bc2b4c6fa92cd99c5c30
> 1635%7C0%7C0%7C637012015426788575&sdata=3bx1bDFIzik8FnD0wl
> duAUv7wtLdD1J3hQ3xNH2xmFY%3D&reserved=0
>
> and make your patches compliant please.
>
> On Fri, Jun 28, 2019 at 09:38:25AM +0800, Xiaowei Bao wrote:
> > The PCIe controller of layerscape just have 4 BARs, BAR0 and BAR1 is
> > 32bit, BAR3 and BAR4 is 64bit, this is determined by hardware, so set
> > the bar_fixed_64bit with 0x14.
> >
> > Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> > ---
> > v2:
> > - Replace value 0x14 with a macro.
> > v3:
> > - No change.
> >
> > drivers/pci/controller/dwc/pci-layerscape-ep.c | 1 +
> > 1 files changed, 1 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > index be61d96..227c33b 100644
> > --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > @@ -44,6 +44,7 @@ static int ls_pcie_establish_link(struct dw_pcie *pci)
> > .linkup_notifier = false,
> > .msi_capable = true,
> > .msix_capable = false,
> > + .bar_fixed_64bit = (1 << BAR_2) | (1 << BAR_4),
>
> I would appreciate Kishon's ACK on this.
>
> Lorenzo
>
> > };
> >
> > static const struct pci_epc_features*
> > --
> > 1.7.1
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V15 00/13] PCI: tegra: Add Tegra194 PCIe support
From: Thierry Reding @ 2019-08-12 10:34 UTC (permalink / raw)
To: Vidya Sagar
Cc: mark.rutland, devicetree, lorenzo.pieralisi, mperttunen,
mmaddireddy, linux-pci, catalin.marinas, will.deacon,
linux-kernel, kthota, kishon, linux-tegra, robh+dt,
gustavo.pimentel, jingoohan1, bhelgaas, digetx, jonathanh,
linux-arm-kernel, sagar.tv
In-Reply-To: <aa666d78-43b3-dbea-dac6-386deaca3e12@nvidia.com>
[-- Attachment #1.1: Type: text/plain, Size: 1818 bytes --]
On Mon, Aug 12, 2019 at 03:59:39PM +0530, Vidya Sagar wrote:
> On 8/12/2019 3:55 PM, Thierry Reding wrote:
> > On Fri, Aug 09, 2019 at 10:15:56AM +0530, Vidya Sagar wrote:
> > > Tegra194 has six PCIe controllers based on Synopsys DesignWare core.
> > > There are two Universal PHY (UPHY) blocks with each supporting 12(HSIO:
> > > Hisg Speed IO) and 8(NVHS: NVIDIA High Speed) lanes respectively.
> > > Controllers:0~4 use UPHY lanes from HSIO brick whereas Controller:5 uses
> > > UPHY lanes from NVHS brick. Lane mapping in HSIO UPHY brick to each PCIe
> > > controller (0~4) is controlled in XBAR module by BPMP-FW. Since PCIe
> > > core has PIPE interface, a glue module called PIPE-to-UPHY (P2U) is used
> > > to connect each UPHY lane (applicable to both HSIO and NVHS UPHY bricks)
> > > to PCIe controller
> > > This patch series
> > > - Adds support for P2U PHY driver
> > > - Adds support for PCIe host controller
> > > - Adds device tree nodes each PCIe controllers
> > > - Enables nodes applicable to p2972-0000 platform
> > > - Adds helper APIs in Designware core driver to get capability regs offset
> > > - Adds defines for new feature registers of PCIe spec revision 4
> > > - Makes changes in DesignWare core driver to get Tegra194 PCIe working
> > >
> > > Testing done on P2972-0000 platform
> > > - Able to get PCIe link up with on-board Marvel eSATA controller
> > > - Able to get PCIe link up with NVMe cards connected to M.2 Key-M slot
> > > - Able to do data transfers with both SATA drives and NVMe cards
> > > - Able to perform suspend-resume sequence
> >
> > Do you happen to have a patch for P2972-0000 PCI support? I don't see it
> > in this series.
> It is already merged.
> V10 link @ http://patchwork.ozlabs.org/patch/1114445/
D'oh! Indeed.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] firmware: arm_scmi: Eliminate local db variable in SCMI_PERF_FC_RING_DB
From: Sudeep Holla @ 2019-08-12 10:32 UTC (permalink / raw)
To: Nathan Chancellor; +Cc: clang-built-linux, linux-kernel, linux-arm-kernel
In-Reply-To: <20190810044910.114015-1-natechancellor@gmail.com>
On Fri, Aug 09, 2019 at 09:49:10PM -0700, Nathan Chancellor wrote:
> clang warns four times:
>
> drivers/firmware/arm_scmi/perf.c:320:24: warning: variable 'db' is
> uninitialized when used within its own initialization [-Wuninitialized]
> SCMI_PERF_FC_RING_DB(db, 64);
> ~~~~~~~~~~~~~~~~~~~~~^~~~~~~
> drivers/firmware/arm_scmi/perf.c:300:31: note: expanded from macro
> 'SCMI_PERF_FC_RING_DB'
> struct scmi_fc_db_info *db = doorbell; \
> ~~ ^~~~~~~~
>
> This happens because the doorbell identifier becomes db after
> preprocessing:
>
> if (db->width == 1)
> do {
> u8 val = 0;
> struct scmi_fc_db_info *db = db;
> if (db->mask)
> val = ioread8(db->addr) & db->mask;
> iowrite8((u8)db->set | val, db->addr);
> } while (0);
>
> We could swap the doorbell and db identifiers within the macro and that
> would resolve the issue; however, there doesn't appear to be a good
> reason for having two copies of the same variable. Eliminate the one in
> the do while loop to prevent this warning and make the code clearer.
>
I originally had exactly what we will after this patch applied. I think
one of the tool complained about argument 'db' reused in the macro
might have possible side-effects. That's the reason I moved it. I will
dig it up and fold this in the original patch as before.
--
Regards,
Sudeep
_______________________________________________
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] mfd: db8500-prcmu: Mark expected switch fall-throughs
From: Lee Jones @ 2019-08-12 10:30 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Stephen Rothwell, Linus Walleij, linux-kernel, linux-arm-kernel,
Kees Cook
In-Reply-To: <20190728235614.GA23618@embeddedor>
On Sun, 28 Jul 2019, Gustavo A. R. Silva wrote:
> Mark switch cases where we are expecting to fall through.
>
> This patch fixes the following warnings:
>
> drivers/mfd/db8500-prcmu.c: In function 'dsiclk_rate':
> drivers/mfd/db8500-prcmu.c:1592:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
> div *= 2;
> ~~~~^~~~
> drivers/mfd/db8500-prcmu.c:1593:2: note: here
> case PRCM_DSI_PLLOUT_SEL_PHI_2:
> ^~~~
> drivers/mfd/db8500-prcmu.c:1594:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
> div *= 2;
> ~~~~^~~~
> drivers/mfd/db8500-prcmu.c:1595:2: note: here
> case PRCM_DSI_PLLOUT_SEL_PHI:
> ^~~~
>
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
> ---
> drivers/mfd/db8500-prcmu.c | 2 ++
> 1 file changed, 2 insertions(+)
Applied, thanks.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
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 V15 00/13] PCI: tegra: Add Tegra194 PCIe support
From: Vidya Sagar @ 2019-08-12 10:29 UTC (permalink / raw)
To: Thierry Reding
Cc: mark.rutland, devicetree, lorenzo.pieralisi, mperttunen,
mmaddireddy, linux-pci, catalin.marinas, will.deacon,
linux-kernel, kthota, kishon, linux-tegra, robh+dt,
gustavo.pimentel, jingoohan1, bhelgaas, digetx, jonathanh,
linux-arm-kernel, sagar.tv
In-Reply-To: <20190812102519.GN8903@ulmo>
On 8/12/2019 3:55 PM, Thierry Reding wrote:
> On Fri, Aug 09, 2019 at 10:15:56AM +0530, Vidya Sagar wrote:
>> Tegra194 has six PCIe controllers based on Synopsys DesignWare core.
>> There are two Universal PHY (UPHY) blocks with each supporting 12(HSIO:
>> Hisg Speed IO) and 8(NVHS: NVIDIA High Speed) lanes respectively.
>> Controllers:0~4 use UPHY lanes from HSIO brick whereas Controller:5 uses
>> UPHY lanes from NVHS brick. Lane mapping in HSIO UPHY brick to each PCIe
>> controller (0~4) is controlled in XBAR module by BPMP-FW. Since PCIe
>> core has PIPE interface, a glue module called PIPE-to-UPHY (P2U) is used
>> to connect each UPHY lane (applicable to both HSIO and NVHS UPHY bricks)
>> to PCIe controller
>> This patch series
>> - Adds support for P2U PHY driver
>> - Adds support for PCIe host controller
>> - Adds device tree nodes each PCIe controllers
>> - Enables nodes applicable to p2972-0000 platform
>> - Adds helper APIs in Designware core driver to get capability regs offset
>> - Adds defines for new feature registers of PCIe spec revision 4
>> - Makes changes in DesignWare core driver to get Tegra194 PCIe working
>>
>> Testing done on P2972-0000 platform
>> - Able to get PCIe link up with on-board Marvel eSATA controller
>> - Able to get PCIe link up with NVMe cards connected to M.2 Key-M slot
>> - Able to do data transfers with both SATA drives and NVMe cards
>> - Able to perform suspend-resume sequence
>
> Do you happen to have a patch for P2972-0000 PCI support? I don't see it
> in this series.
It is already merged.
V10 link @ http://patchwork.ozlabs.org/patch/1114445/
- Vidya Sagar
>
> Thierry
>
_______________________________________________
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 V15 00/13] PCI: tegra: Add Tegra194 PCIe support
From: Thierry Reding @ 2019-08-12 10:25 UTC (permalink / raw)
To: Vidya Sagar
Cc: mark.rutland, devicetree, lorenzo.pieralisi, mperttunen,
mmaddireddy, linux-pci, catalin.marinas, will.deacon,
linux-kernel, kthota, kishon, linux-tegra, robh+dt,
gustavo.pimentel, jingoohan1, bhelgaas, digetx, jonathanh,
linux-arm-kernel, sagar.tv
In-Reply-To: <20190809044609.20401-1-vidyas@nvidia.com>
[-- Attachment #1.1: Type: text/plain, Size: 1502 bytes --]
On Fri, Aug 09, 2019 at 10:15:56AM +0530, Vidya Sagar wrote:
> Tegra194 has six PCIe controllers based on Synopsys DesignWare core.
> There are two Universal PHY (UPHY) blocks with each supporting 12(HSIO:
> Hisg Speed IO) and 8(NVHS: NVIDIA High Speed) lanes respectively.
> Controllers:0~4 use UPHY lanes from HSIO brick whereas Controller:5 uses
> UPHY lanes from NVHS brick. Lane mapping in HSIO UPHY brick to each PCIe
> controller (0~4) is controlled in XBAR module by BPMP-FW. Since PCIe
> core has PIPE interface, a glue module called PIPE-to-UPHY (P2U) is used
> to connect each UPHY lane (applicable to both HSIO and NVHS UPHY bricks)
> to PCIe controller
> This patch series
> - Adds support for P2U PHY driver
> - Adds support for PCIe host controller
> - Adds device tree nodes each PCIe controllers
> - Enables nodes applicable to p2972-0000 platform
> - Adds helper APIs in Designware core driver to get capability regs offset
> - Adds defines for new feature registers of PCIe spec revision 4
> - Makes changes in DesignWare core driver to get Tegra194 PCIe working
>
> Testing done on P2972-0000 platform
> - Able to get PCIe link up with on-board Marvel eSATA controller
> - Able to get PCIe link up with NVMe cards connected to M.2 Key-M slot
> - Able to do data transfers with both SATA drives and NVMe cards
> - Able to perform suspend-resume sequence
Do you happen to have a patch for P2972-0000 PCI support? I don't see it
in this series.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/3] arm64: imx8mq: add imx8mq iomux-gpr field defines
From: Lee Jones @ 2019-08-12 10:24 UTC (permalink / raw)
To: Guido Günther, arnd
Cc: Mark Rutland, devicetree, Jernej Skrabec, Pengutronix Kernel Team,
Sam Ravnborg, Neil Armstrong, David Airlie, Fabio Estevam,
Sascha Hauer, Jonas Karlman, linux-kernel, dri-devel,
Andrzej Hajda, Rob Herring, NXP Linux Team, Daniel Vetter,
Robert Chiras, Shawn Guo, linux-arm-kernel, Laurent Pinchart
In-Reply-To: <e0562d8bb4098dc4cdb4023b41fb75b312be22a5.1565367567.git.agx@sigxcpu.org>
On Fri, 09 Aug 2019, Guido Günther wrote:
> This adds all the gpr registers and the define needed for selecting
> the input source in the imx-nwl drm bridge.
>
> Signed-off-by: Guido Günther <agx@sigxcpu.org>
> ---
> include/linux/mfd/syscon/imx8mq-iomuxc-gpr.h | 62 ++++++++++++++++++++
> 1 file changed, 62 insertions(+)
> create mode 100644 include/linux/mfd/syscon/imx8mq-iomuxc-gpr.h
I would like Arnd to look at this please.
> diff --git a/include/linux/mfd/syscon/imx8mq-iomuxc-gpr.h b/include/linux/mfd/syscon/imx8mq-iomuxc-gpr.h
> new file mode 100644
> index 000000000000..62e85ffacfad
> --- /dev/null
> +++ b/include/linux/mfd/syscon/imx8mq-iomuxc-gpr.h
> @@ -0,0 +1,62 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (C) 2017 NXP
> + * 2019 Purism SPC
> + */
> +
> +#ifndef __LINUX_IMX8MQ_IOMUXC_GPR_H
> +#define __LINUX_IMX8MQ_IOMUXC_GPR_H
> +
> +#define IOMUXC_GPR0 0x00
> +#define IOMUXC_GPR1 0x04
> +#define IOMUXC_GPR2 0x08
> +#define IOMUXC_GPR3 0x0c
> +#define IOMUXC_GPR4 0x10
> +#define IOMUXC_GPR5 0x14
> +#define IOMUXC_GPR6 0x18
> +#define IOMUXC_GPR7 0x1c
> +#define IOMUXC_GPR8 0x20
> +#define IOMUXC_GPR9 0x24
> +#define IOMUXC_GPR10 0x28
> +#define IOMUXC_GPR11 0x2c
> +#define IOMUXC_GPR12 0x30
> +#define IOMUXC_GPR13 0x34
> +#define IOMUXC_GPR14 0x38
> +#define IOMUXC_GPR15 0x3c
> +#define IOMUXC_GPR16 0x40
> +#define IOMUXC_GPR17 0x44
> +#define IOMUXC_GPR18 0x48
> +#define IOMUXC_GPR19 0x4c
> +#define IOMUXC_GPR20 0x50
> +#define IOMUXC_GPR21 0x54
> +#define IOMUXC_GPR22 0x58
> +#define IOMUXC_GPR23 0x5c
> +#define IOMUXC_GPR24 0x60
> +#define IOMUXC_GPR25 0x64
> +#define IOMUXC_GPR26 0x68
> +#define IOMUXC_GPR27 0x6c
> +#define IOMUXC_GPR28 0x70
> +#define IOMUXC_GPR29 0x74
> +#define IOMUXC_GPR30 0x78
> +#define IOMUXC_GPR31 0x7c
> +#define IOMUXC_GPR32 0x80
> +#define IOMUXC_GPR33 0x84
> +#define IOMUXC_GPR34 0x88
> +#define IOMUXC_GPR35 0x8c
> +#define IOMUXC_GPR36 0x90
> +#define IOMUXC_GPR37 0x94
> +#define IOMUXC_GPR38 0x98
> +#define IOMUXC_GPR39 0x9c
> +#define IOMUXC_GPR40 0xa0
> +#define IOMUXC_GPR41 0xa4
> +#define IOMUXC_GPR42 0xa8
> +#define IOMUXC_GPR43 0xac
> +#define IOMUXC_GPR44 0xb0
> +#define IOMUXC_GPR45 0xb4
> +#define IOMUXC_GPR46 0xb8
> +#define IOMUXC_GPR47 0xbc
> +
> +/* i.MX8Mq iomux gpr register field defines */
> +#define IMX8MQ_GPR13_MIPI_MUX_SEL BIT(2)
> +
> +#endif /* __LINUX_IMX8MQ_IOMUXC_GPR_H */
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64: dts: allwinner: Enable DDC regulator for Beelink GS1
From: Clément Péron @ 2019-08-12 10:23 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Rob Herring
Cc: devicetree, linux-sunxi, Clément Péron, linux-kernel,
linux-arm-kernel
Beelink GS1 has a DDC I2C bus voltage shifter. This is actually missing
and video is limited to 1024x768 due to missing EDID information.
Add the DDC regulator in the device-tree.
Signed-off-by: Clément Péron <peron.clem@gmail.com>
---
arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
index 680dc29cb089..67d7f269c5da 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
@@ -25,6 +25,7 @@
connector {
compatible = "hdmi-connector";
type = "a";
+ ddc-en-gpios = <&pio 7 2 GPIO_ACTIVE_HIGH>; /* PH2 */
port {
hdmi_con_in: endpoint {
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH V15 12/13] phy: tegra: Add PCIe PIPE2UPHY support
From: Thierry Reding @ 2019-08-12 10:23 UTC (permalink / raw)
To: Vidya Sagar
Cc: mark.rutland, devicetree, lorenzo.pieralisi, mperttunen,
mmaddireddy, linux-pci, catalin.marinas, will.deacon,
linux-kernel, kthota, kishon, linux-tegra, robh+dt,
gustavo.pimentel, jingoohan1, bhelgaas, digetx, jonathanh,
linux-arm-kernel, sagar.tv
In-Reply-To: <20190809044609.20401-13-vidyas@nvidia.com>
[-- Attachment #1.1: Type: text/plain, Size: 1732 bytes --]
On Fri, Aug 09, 2019 at 10:16:08AM +0530, Vidya Sagar wrote:
> Synopsys DesignWare core based PCIe controllers in Tegra 194 SoC interface
> with Universal PHY (UPHY) module through a PIPE2UPHY (P2U) module.
> For each PCIe lane of a controller, there is a P2U unit instantiated at
> hardware level. This driver provides support for the programming required
> for each P2U that is going to be used for a PCIe controller.
>
> Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
> Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> V15:
> * None
>
> V14:
> * None
>
> V13:
> * None
>
> V12:
> * None
>
> V11:
> * Replaced PTR_ERR_OR_ZERO() with PTR_ERR() as the check for zero is already
> present in the code.
>
> V10:
> * Used _relaxed() versions of readl() & writel()
>
> V9:
> * Made it dependent on ARCH_TEGRA_194_SOC directly instead of ARCH_TEGRA
>
> V8:
> * Changed P2U driver file name from pcie-p2u-tegra194.c to phy-tegra194-p2u.c
>
> V7:
> * None
>
> V6:
> * Addressed review comments from Thierry
>
> V5:
> * None
>
> V4:
> * Rebased on top of linux-next top of the tree
>
> V3:
> * Replaced spaces with tabs in Kconfig file
> * Sorted header file inclusion alphabetically
>
> V2:
> * Added COMPILE_TEST in Kconfig
> * Removed empty phy_ops implementations
> * Modified code according to DT documentation file modifications
>
> drivers/phy/tegra/Kconfig | 7 ++
> drivers/phy/tegra/Makefile | 1 +
> drivers/phy/tegra/phy-tegra194-p2u.c | 120 +++++++++++++++++++++++++++
> 3 files changed, 128 insertions(+)
> create mode 100644 drivers/phy/tegra/phy-tegra194-p2u.c
Acked-by: Thierry Reding <treding@nvidia.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 07/10] mfd: mt6323: add mt6323 rtc+pwrc
From: Lee Jones @ 2019-08-12 10:22 UTC (permalink / raw)
To: Frank Wunderlich
Cc: Kate Stewart, Mark Rutland, Alexandre Belloni, linux-kernel,
Richard Fontana, Mauro Carvalho Chehab, linux-rtc, Allison Randal,
devicetree, linux-pm, Sean Wang, Tianping . Fang, Rob Herring,
linux-mediatek, Jonathan Cameron, Matthias Brugger,
Thomas Gleixner, Eddie Huang, linux-arm-kernel, Alessandro Zummo,
Josef Friedl, Greg Kroah-Hartman, Sebastian Reichel,
David S. Miller
In-Reply-To: <20190729174154.4335-8-frank-w@public-files.de>
On Mon, 29 Jul 2019, Frank Wunderlich wrote:
> From: Josef Friedl <josef.friedl@speed.at>
>
> add entry for rtc and power-controller to mt6323
>
> changes since v2: only splitting, second part of v2 part 4
>
> Signed-off-by: Josef Friedl <josef.friedl@speed.at>
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> ---
> drivers/mfd/mt6397-core.c | 25 +++++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
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 06/10] mfd: mt6323: some improvements of mt6397-core
From: Lee Jones @ 2019-08-12 10:22 UTC (permalink / raw)
To: Frank Wunderlich
Cc: Kate Stewart, Mark Rutland, Alexandre Belloni, linux-kernel,
Richard Fontana, Mauro Carvalho Chehab, linux-rtc, Allison Randal,
devicetree, linux-pm, Sean Wang, Tianping . Fang, Rob Herring,
linux-mediatek, Jonathan Cameron, Matthias Brugger,
Thomas Gleixner, Eddie Huang, linux-arm-kernel, Alessandro Zummo,
Josef Friedl, Greg Kroah-Hartman, Sebastian Reichel,
David S. Miller
In-Reply-To: <20190729174154.4335-7-frank-w@public-files.de>
On Mon, 29 Jul 2019, Frank Wunderlich wrote:
> From: Josef Friedl <josef.friedl@speed.at>
>
> simplyfications (resource definitions my DEFINE_RES_* macros)
>
> changes since v2: splitted v2 part 4 into 6+7
>
> Signed-off-by: Josef Friedl <josef.friedl@speed.at>
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> ---
> drivers/mfd/mt6397-core.c | 15 ++++-----------
> 1 file changed, 4 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
> index 337bcccdb914..5f7070267c9a 100644
> --- a/drivers/mfd/mt6397-core.c
> +++ b/drivers/mfd/mt6397-core.c
> @@ -1,10 +1,11 @@
> // SPDX-License-Identifier: GPL-2.0-only
> /*
> - * Copyright (c) 2014 MediaTek Inc.
> + * Copyright (c) 2014-2018 MediaTek Inc.
This is out of date. Please update it.
Once fixed, please apply my:
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
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