* [PATCH 0/5] Add support for WD MyCloud EX2 Ultra (+ versatile UART-based restart/poweroff drivers)
From: Evgeny Kolesnikov @ 2019-07-22 19:53 UTC (permalink / raw)
Cc: Evgeny Kolesnikov, Sebastian Reichel, Rob Herring, Mark Rutland,
Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
linux-pm, devicetree, linux-kernel, linux-arm-kernel
This patchset consists of the DTS, which describes the WD MyCloud EX2 Ultra device,
'poweroff' and 'resert' drivers for power-managing MCUs connected to a board via UART
(these drivers are more versatile than qnap-poweroff and could be used as a substitude),
and DT bindings for these drivers.
The difference between uart-poweroff and qnap-poweroff is small, but important:
uart-poweroff is able to send to an MCU a command of arbitrary length, and the command
itself is defined in a DTS file for a specific device/board, thus making this driver
applicable to wider range of devices.
Evgeny Kolesnikov (5):
power: reset: Add UART-based MCU poweroff DT bindings
power: reset: Add UART-based MCU restart DT bindings
power/reset: Add a power off driver for UART-based PM MCUs
power/reset: Add a restart driver for UART-based PM MCUs
ARM: dts: armada385-wd-mcex2u: Add DTS file for WD My Cloud EX2 Ultra
.../bindings/power/reset/uart-poweroff.txt | 38 +++
.../bindings/power/reset/uart-restart.txt | 39 +++
arch/arm/boot/dts/armada-385-wd-mcex2u.dts | 313 ++++++++++++++++++
drivers/power/reset/Kconfig | 14 +
drivers/power/reset/Makefile | 2 +
drivers/power/reset/uart-poweroff.c | 155 +++++++++
drivers/power/reset/uart-restart.c | 204 ++++++++++++
7 files changed, 765 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/reset/uart-poweroff.txt
create mode 100644 Documentation/devicetree/bindings/power/reset/uart-restart.txt
create mode 100644 arch/arm/boot/dts/armada-385-wd-mcex2u.dts
create mode 100644 drivers/power/reset/uart-poweroff.c
create mode 100644 drivers/power/reset/uart-restart.c
--
2.21.0
^ permalink raw reply
* Re: [PATCH v2 6/7] dt-bindings: net: realtek: Add property to configure LED mode
From: Andrew Lunn @ 2019-07-22 19:38 UTC (permalink / raw)
To: Matthias Kaehlcke
Cc: Rob Herring, Florian Fainelli, David S . Miller, Mark Rutland,
Heiner Kallweit, netdev, devicetree, linux-kernel@vger.kernel.org,
Douglas Anderson
In-Reply-To: <20190722191411.GW250418@google.com>
> as of now it isn't even an API, the phy_device populates a new array
> in its struct with the values from the DT. PHY drivers access the
> array directly. Is it still preferable to post everything together?
>
> (maybe I'm too concerned about 'noise' from the driver patches while
> we are figuring out what exactly the binding should be).
We should try to have the DT parsing made generic in phylib, and add
new driver API calls to actually configure the LEDs.
Please also take a look at the Linux generic LED binding. It would be
nice to have something compatible with that. With time, the code could
morph into being part of the generic LED subsystem. So we are mostly
talking about triggers. But we offload the trigger to the hardware,
rather than have software trigger the blinking of the LEDs. So
something like:
ethernet-phy0 {
reg = <0>;
leds {
phy-led@0 {
reg = <0>
label = "left:green";
linux,default-trigger = "phy_link_1000_active";
}
phy-led@1 {
reg = <1>
label = "right:red";
linux,default-trigger = "phy_collision";
}
}
}
Andrew
^ permalink raw reply
* Re: [PATCH v2 3/6] pwm: jz4740: Apply configuration atomically
From: Uwe Kleine-König @ 2019-07-22 19:34 UTC (permalink / raw)
To: Paul Cercueil
Cc: Thierry Reding, Rob Herring, Mark Rutland, od, linux-pwm,
devicetree, linux-kernel
In-Reply-To: <20190607154410.10633-4-paul@crapouillou.net>
Hello Paul,
On Fri, Jun 07, 2019 at 05:44:07PM +0200, Paul Cercueil wrote:
> -static int jz4740_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
> - int duty_ns, int period_ns)
> +static int jz4740_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> + struct pwm_state *state)
> {
> struct jz4740_pwm_chip *jz4740 = to_jz4740(pwm->chip);
> unsigned long long tmp;
> unsigned long period, duty;
> unsigned int prescaler = 0;
> uint16_t ctrl;
> - bool is_enabled;
>
> - tmp = (unsigned long long)clk_get_rate(jz4740->clk) * period_ns;
> + tmp = (unsigned long long)clk_get_rate(jz4740->clk) * state->period;
> do_div(tmp, 1000000000);
> period = tmp;
>
> @@ -96,16 +95,14 @@ static int jz4740_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
> if (prescaler == 6)
> return -EINVAL;
>
> - tmp = (unsigned long long)period * duty_ns;
> - do_div(tmp, period_ns);
> + tmp = (unsigned long long)period * state->duty_cycle;
> + do_div(tmp, state->period);
> duty = period - tmp;
>
> if (duty >= period)
> duty = period - 1;
>
> - is_enabled = jz4740_timer_is_enabled(pwm->hwpwm);
> - if (is_enabled)
> - jz4740_pwm_disable(chip, pwm);
> + jz4740_pwm_disable(chip, pwm);
I assume this stops the PWM. Does this complete the currently running
period? How does the PWM behave then? (Does it still drive the output?
If so, on which level?)
>
> jz4740_timer_set_count(pwm->hwpwm, 0);
> jz4740_timer_set_duty(pwm->hwpwm, duty);
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH v4 7/8] dt-bindings: arm: sunxi: add binding for Lichee Zero Plus core board
From: Maxime Ripard @ 2019-07-22 19:29 UTC (permalink / raw)
To: Icenowy Zheng
Cc: linux-arm-kernel, devicetree, Linus Walleij, linux-sunxi,
linux-kernel, linux-gpio, Chen-Yu Tsai, Rob Herring, linux-clk
In-Reply-To: <BDF0C9F6-DD0D-4343-8E24-06A07055004C@aosc.io>
[-- Attachment #1: Type: text/plain, Size: 2094 bytes --]
On Sat, Jul 20, 2019 at 07:39:08PM +0800, Icenowy Zheng wrote:
>
>
> 于 2019年7月20日 GMT+08:00 下午6:13:18, Maxime Ripard <maxime.ripard@bootlin.com> 写到:
> >On Sat, Jul 13, 2019 at 11:46:33AM +0800, Icenowy Zheng wrote:
> >> The Lichee Zero Plus is a core board made by Sipeed, with a microUSB
> >> connector on it, TF slot or WSON8 SD chip, optional eMMC or SPI
> >Flash.
> >> It has a gold finger connector for expansion, and UART is available
> >from
> >> reserved pins w/ 2.54mm pitch. The board can use either SoChip S3 or
> >> Allwinner V3L SoCs.
> >>
> >> Add the device tree binding of the basic version of the core board --
> >> w/o eMMC or SPI Flash, w/ TF slot or WSON8 SD, and use S3 SoC.
> >>
> >> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> >> ---
> >> No changes since v3.
> >>
> >> Patch introduced in v2.
> >>
> >> Documentation/devicetree/bindings/arm/sunxi.yaml | 5 +++++
> >> 1 file changed, 5 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml
> >b/Documentation/devicetree/bindings/arm/sunxi.yaml
> >> index 000a00d12d6a..48c126a7a848 100644
> >> --- a/Documentation/devicetree/bindings/arm/sunxi.yaml
> >> +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
> >> @@ -353,6 +353,11 @@ properties:
> >> - const: licheepi,licheepi-zero
> >> - const: allwinner,sun8i-v3s
> >>
> >> + - description: Lichee Zero Plus (with S3, without eMMC/SPI
> >Flash)
> >> + items:
> >> + - const: sipeed,lichee-zero-plus
> >> + - const: allwinner,sun8i-s3
> >
> >If the S3 is just a rebranded V3, then we should have the v3 compatile
> >in that list too.
>
> S3 is V3 with copackaged DDR3 DRAM.
>
> It's pin incompatible w/ V3.
Does it matter though?
If the only thing that changes is the package, we're not manipulating
that, and any software that deals with the v3 can deal with the
s3. Which is what the compatible is about.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 1/4][V3] spi: Add optional stall delay between cs_change transfers
From: Alexandru Ardelean @ 2019-07-22 19:27 UTC (permalink / raw)
To: Mark Brown
Cc: Alexandru Ardelean, linux-iio, linux-spi, devicetree, LKML,
Jonathan Cameron, Rob Herring, Mark Rutland, Michael Hennerich
In-Reply-To: <20190722163202.GG4756@sirena.org.uk>
On Mon, Jul 22, 2019 at 8:42 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Mon, Jul 22, 2019 at 03:47:44PM +0300, Alexandru Ardelean wrote:
> > Some devices like the ADIS16460 IMU require a longer period between
> > transfers, i.e. between when the CS is de-asserted and re-asserted. The
> > default value of 10us is not enough. This change makes the delay
> > configurable for when the next CS change goes active, allowing the default
> > to remain 10us is case it is unspecified.
>
> For the third time:
>
> | This looks like cs_change_delay.
>
> > #define SPI_NBITS_QUAD 0x04 /* 4bits transfer */
> > u8 bits_per_word;
> > u8 word_delay_usecs;
> > + u8 cs_change_delay;
> > u16 delay_usecs;
> > u32 speed_hz;
> > u16 word_delay;
>
> This patch doesn't apply and even if it did it won't compile because you
> are trying to add a field with the same name as an existing one.
oooohhhhhhhh
now i see;
well, my fault here;
i was basing my patchset on top of branch iio/togreg from Jonathan's
tree for the IMU:
https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git/log/?h=togreg
[ typically that's the base branch for new IIO drivers ]
that one is a bit behind, and does not contain the cs_change_delay
stuff you mentioned;
also, i will admit that sometimes, some review comments are not
completely obvious to me;
i should have checked the SPI tree before opening my mouth, but this
will [hopefully] serve me as a learning experience when sending
multi-subsystem patches
when sending to a single subsystem, it's clear; when sending to 2, i
get a bit lost
i do feel a bit bad for the noise i caused, but it's not the worst
thing i did today
anyway: disregard this, and i will sync with Jonathan about how to
proceed with this patch just for IIO;
thanks for your time and sorry for the noise
Alex
^ permalink raw reply
* Re: [PATCH v8 0/7] Unify CPU topology across ARM & RISC-V
From: Paul Walmsley @ 2019-07-22 19:25 UTC (permalink / raw)
To: Atish Patra
Cc: linux-kernel, Jeremy Linton, Albert Ou, Anup Patel,
Catalin Marinas, David S. Miller, devicetree, Greg Kroah-Hartman,
Ingo Molnar, Johan Hovold, Linus Walleij, linux-riscv,
Mark Rutland, Mauro Carvalho Chehab, Morten Rasmussen,
Otto Sabart, Palmer Dabbelt, Peter Zijlstra (Intel),
Rafael J. Wysocki, Rob
In-Reply-To: <alpine.DEB.2.21.9999.1907121012050.2267@viisi.sifive.com>
On Fri, 12 Jul 2019, Paul Walmsley wrote:
> On Thu, 27 Jun 2019, Atish Patra wrote:
>
> > The cpu-map DT entry in ARM can describe the CPU topology in much better
> > way compared to other existing approaches. RISC-V can easily adopt this
> > binding to represent its own CPU topology. Thus, both cpu-map DT
> > binding and topology parsing code can be moved to a common location so
> > that RISC-V or any other architecture can leverage that.
> > different config for the architectures that do not support them.
>
> Once v5.3-rc1 is released, let's plan to get these patches rebased and
> reposted and into linux-next as soon as possible.
These CPU topology patches are now queued for v5.4-rc1. They should enter
linux-next shortly.
- Paul
^ permalink raw reply
* [PATCH 2/2] ARM: dts: aspeed: tiogapass: Add Riser card
From: Vijay Khemka @ 2019-07-22 19:24 UTC (permalink / raw)
To: Jean Delvare, Guenter Roeck, Rob Herring, Mark Rutland,
Joel Stanley, Andrew Jeffery, linux-hwmon, devicetree,
linux-kernel, linux-arm-kernel, linux-aspeed
Cc: openbmc @ lists . ozlabs . org, sdasari, vijaykhemka
In-Reply-To: <20190722192451.1947348-1-vijaykhemka@fb.com>
Added i2c mux for riser card and multiple ava card and its sensor
components for Facebook Tiogapass platform
Signed-off-by: Vijay Khemka <vijaykhemka@fb.com>
---
.../dts/aspeed-bmc-facebook-tiogapass.dts | 230 ++++++++++++++++++
1 file changed, 230 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts b/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts
index b7783833a58c..8d0bcb3cd419 100644
--- a/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts
@@ -12,6 +12,27 @@
aliases {
serial0 = &uart1;
serial4 = &uart5;
+
+ /*
+ * Hardcode the bus number of i2c switches' channels to
+ * avoid breaking the legacy applications.
+ */
+ i2c16 = &imux16;
+ i2c17 = &imux17;
+ i2c18 = &imux18;
+ i2c19 = &imux19;
+ i2c20 = &imux20;
+ i2c21 = &imux21;
+ i2c22 = &imux22;
+ i2c23 = &imux23;
+ i2c24 = &imux24;
+ i2c25 = &imux25;
+ i2c26 = &imux26;
+ i2c27 = &imux27;
+ i2c28 = &imux28;
+ i2c29 = &imux29;
+ i2c30 = &imux30;
+ i2c31 = &imux31;
};
chosen {
stdout-path = &uart5;
@@ -124,6 +145,215 @@
&i2c1 {
status = "okay";
//X24 Riser
+ i2c-switch@71 {
+ compatible = "nxp,pca9544";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x71>;
+
+ imux16: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ ina219@45 {
+ compatible = "ti,ina219";
+ reg = <0x45>;
+ };
+
+ tmp75@48 {
+ compatible = "ti,tmp75";
+ reg = <0x48>;
+ };
+
+ tmp421@49 {
+ compatible = "ti,tmp75";
+ reg = <0x49>;
+ };
+
+ eeprom@50 {
+ compatible = "atmel,24c64";
+ reg = <0x50>;
+ pagesize = <32>;
+ };
+
+ i2c-switch@73 {
+ compatible = "nxp,pca9546";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x73>;
+
+ imux20: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ };
+
+ imux21: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+
+ imux22: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ };
+
+ imux23: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ };
+
+ };
+
+ };
+
+ imux17: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ ina219@45 {
+ compatible = "ti,ina219";
+ reg = <0x45>;
+ };
+
+ tmp421@48 {
+ compatible = "ti,tmp75";
+ reg = <0x48>;
+ };
+
+ tmp421@49 {
+ compatible = "ti,tmp75";
+ reg = <0x49>;
+ };
+
+ eeprom@50 {
+ compatible = "atmel,24c64";
+ reg = <0x50>;
+ pagesize = <32>;
+ };
+
+ i2c-switch@73 {
+ compatible = "nxp,pca9546";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x73>;
+
+ imux24: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ };
+
+ imux25: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+
+ imux26: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ };
+
+ imux27: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ };
+
+ };
+
+ };
+
+ imux18: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+
+ ina219@45 {
+ compatible = "ti,ina219";
+ reg = <0x45>;
+ };
+
+ tmp421@48 {
+ compatible = "ti,tmp75";
+ reg = <0x48>;
+ };
+
+ tmp421@49 {
+ compatible = "ti,tmp75";
+ reg = <0x49>;
+ };
+
+ eeprom@50 {
+ compatible = "atmel,24c64";
+ reg = <0x50>;
+ pagesize = <32>;
+ };
+
+ i2c-switch@73 {
+ compatible = "nxp,pca9546";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x73>;
+
+ imux28: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ };
+
+ imux29: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+
+ imux30: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ };
+
+ imux31: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ };
+
+ };
+
+ };
+
+ imux19: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+
+ i2c-switch@40 {
+ compatible = "ti,ina219";
+ reg = <0x40>;
+ };
+
+ i2c-switch@41 {
+ compatible = "ti,ina219";
+ reg = <0x41>;
+ };
+
+ i2c-switch@45 {
+ compatible = "ti,ina219";
+ reg = <0x45>;
+ };
+
+ };
+
+ };
};
&i2c2 {
--
2.17.1
^ permalink raw reply related
* [PATCH] dt-bindings: hwmon: Add binding for pxe1610
From: Vijay Khemka @ 2019-07-22 19:24 UTC (permalink / raw)
To: Jean Delvare, Guenter Roeck, Rob Herring, Mark Rutland,
Joel Stanley, Andrew Jeffery, linux-hwmon, devicetree,
linux-kernel, linux-arm-kernel, linux-aspeed
Cc: openbmc @ lists . ozlabs . org, sdasari, vijaykhemka
In-Reply-To: <20190722192451.1947348-1-vijaykhemka@fb.com>
Added new DT binding document for Infineon PXE1610 devices.
Signed-off-by: Vijay Khemka <vijaykhemka@fb.com>
---
.../devicetree/bindings/hwmon/pxe1610.txt | 15 +++++++++++++++
1 file changed, 15 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/pxe1610.txt
diff --git a/Documentation/devicetree/bindings/hwmon/pxe1610.txt b/Documentation/devicetree/bindings/hwmon/pxe1610.txt
new file mode 100644
index 000000000000..635daf4955db
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/pxe1610.txt
@@ -0,0 +1,15 @@
+pxe1610 properties
+
+Required properties:
+- compatible: Must be one of the following:
+ - "infineon,pxe1610" for pxe1610
+ - "infineon,pxe1110" for pxe1610
+ - "infineon,pxm1310" for pxm1310
+- reg: I2C address
+
+Example:
+
+vr@48 {
+ compatible = "infineon,pxe1610";
+ reg = <0x48>;
+};
--
2.17.1
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: aspeed: tiogapass: Add VR devices
From: Vijay Khemka @ 2019-07-22 19:24 UTC (permalink / raw)
To: Jean Delvare, Guenter Roeck, Rob Herring, Mark Rutland,
Joel Stanley, Andrew Jeffery, linux-hwmon, devicetree,
linux-kernel, linux-arm-kernel, linux-aspeed
Cc: openbmc @ lists . ozlabs . org, sdasari, vijaykhemka
Addes Voltage regulators Infineon pxe1610 devices to Facebook
tiogapass platform.
Signed-off-by: Vijay Khemka <vijaykhemka@fb.com>
---
.../dts/aspeed-bmc-facebook-tiogapass.dts | 36 +++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts b/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts
index c4521eda787c..b7783833a58c 100644
--- a/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts
@@ -144,6 +144,42 @@
&i2c5 {
status = "okay";
// CPU Voltage regulators
+ vr@48 {
+ compatible = "infineon,pxe1610";
+ reg = <0x48>;
+ };
+ vr@4a {
+ compatible = "infineon,pxe1610";
+ reg = <0x4a>;
+ };
+ vr@50 {
+ compatible = "infineon,pxe1610";
+ reg = <0x50>;
+ };
+ vr@52 {
+ compatible = "infineon,pxe1610";
+ reg = <0x52>;
+ };
+ vr@58 {
+ compatible = "infineon,pxe1610";
+ reg = <0x58>;
+ };
+ vr@5a {
+ compatible = "infineon,pxe1610";
+ reg = <0x5a>;
+ };
+ vr@68 {
+ compatible = "infineon,pxe1610";
+ reg = <0x68>;
+ };
+ vr@70 {
+ compatible = "infineon,pxe1610";
+ reg = <0x70>;
+ };
+ vr@72 {
+ compatible = "infineon,pxe1610";
+ reg = <0x72>;
+ };
};
&i2c6 {
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v2 6/7] dt-bindings: net: realtek: Add property to configure LED mode
From: Matthias Kaehlcke @ 2019-07-22 19:14 UTC (permalink / raw)
To: Andrew Lunn
Cc: Rob Herring, Florian Fainelli, David S . Miller, Mark Rutland,
Heiner Kallweit, netdev, devicetree, linux-kernel@vger.kernel.org,
Douglas Anderson
In-Reply-To: <20190722190133.GF8972@lunn.ch>
Hi Andrew,
On Mon, Jul 22, 2019 at 09:01:33PM +0200, Andrew Lunn wrote:
> On Mon, Jul 22, 2019 at 10:14:18AM -0700, Matthias Kaehlcke wrote:
> > I'm working on a generic binding.
> >
> > I wonder what is the best process for reviewing/landing it, I'm
> > doubting between two options:
> >
> > a) only post the binding doc and the generic PHY code that reads
> > the configuration from the DT. Post Realtek patches once
> > the binding/generic code has been acked.
> >
> > pros: no churn from Realtek specific patches
> > cons: initially no (real) user of the new binding
> >
> > b) post generic and Realtek changes together
> >
> > pros: the binding has a user initially
> > cons: churn from Realtek specific patches
> >
> > I can do either, depending on what maintainers/reviewers prefer. I'm
> > slightly inclined towards a)
>
> Hi Matthias
>
> It is normal to include one user of any generic API which is added,
> just to make is clear how an API should be used.
as of now it isn't even an API, the phy_device populates a new array
in its struct with the values from the DT. PHY drivers access the
array directly. Is it still preferable to post everything together?
(maybe I'm too concerned about 'noise' from the driver patches while
we are figuring out what exactly the binding should be).
Thanks
Matthias
^ permalink raw reply
* Re: [v3 1/4] dt-bindngs: display: panel: Add BOE tv101wum-n16 panel bindings
From: Uwe Kleine-König @ 2019-07-22 19:11 UTC (permalink / raw)
To: Jitao Shi
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, linux-pwm,
David Airlie, Matthias Brugger, Thierry Reding, Ajay Kumar,
Inki Dae, Rahul Sharma, Sean Paul, Vincent Palatin, Andy Yan,
Philipp Zabel, Russell King, devicetree, linux-kernel, dri-devel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <20190626025400.109567-2-jitao.shi@mediatek.com>
$Subject ~= s/bindngs/bindings/
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH 2/2] arm64: dts: ti: k3-j721e-main: Add hwspinlock node
From: Suman Anna @ 2019-07-22 19:05 UTC (permalink / raw)
To: Tero Kristo, Nishanth Menon; +Cc: devicetree, linux-arm-kernel
In-Reply-To: <20190722190539.27816-1-s-anna@ti.com>
The Main NavSS block on J721E SoCs contains a HwSpinlock IP instance that
is same as the IP on AM65x SoCs and similar to the IP on some OMAP SoCs.
Add the DT node for this on J721E SoCs. The node is present within the
Main NavSS block, and is added as a child node under the cbass_main_navss
interconnect node.
Signed-off-by: Suman Anna <s-anna@ti.com>
---
arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
index a01308142f77..a2e031f7d88e 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
@@ -89,6 +89,12 @@
ti,sci-rm-range-vint = <0xa>;
ti,sci-rm-range-global-event = <0xd>;
};
+
+ hwspinlock: spinlock@30e00000 {
+ compatible = "ti,am654-hwspinlock";
+ reg = <0x00 0x30e00000 0x00 0x1000>;
+ #hwlock-cells = <1>;
+ };
};
secure_proxy_main: mailbox@32c00000 {
--
2.22.0
^ permalink raw reply related
* [PATCH 1/2] arm64: dts: ti: k3-am65-main: Add hwspinlock node
From: Suman Anna @ 2019-07-22 19:05 UTC (permalink / raw)
To: Tero Kristo, Nishanth Menon; +Cc: devicetree, linux-arm-kernel
In-Reply-To: <20190722190539.27816-1-s-anna@ti.com>
The Main NavSS block on AM65x SoCs contains a HwSpinlock IP instance
that is similar to the IP on some OMAP SoCs. Add the DT node for this
on AM65x SoCs. The node is present within the NavSS block, and is
added as a child node under the cbass_main_navss interconnect node.
Signed-off-by: Suman Anna <s-anna@ti.com>
---
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
index ca70ff73f171..8413e80f9d3a 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
@@ -413,6 +413,12 @@
ti,sci-rm-range-vint = <0x0>;
ti,sci-rm-range-global-event = <0x1>;
};
+
+ hwspinlock: spinlock@30e00000 {
+ compatible = "ti,am654-hwspinlock";
+ reg = <0x00 0x30e00000 0x00 0x1000>;
+ #hwlock-cells = <1>;
+ };
};
main_gpio0: main_gpio0@600000 {
--
2.22.0
^ permalink raw reply related
* [PATCH 0/2] Add HwSpinlock nodes for TI K3 SoCs
From: Suman Anna @ 2019-07-22 19:05 UTC (permalink / raw)
To: Tero Kristo, Nishanth Menon; +Cc: devicetree, linux-arm-kernel
Hi Tero,
The following series adds the HwSpinlock DT nodes for the
TI K3 AM65x and J721E SoC families. Patches are based on
v5.3-rc1.
The bindings and driver support for the same have been
merged in v5.3-rc1.
regards
Suman
Suman Anna (2):
arm64: dts: ti: k3-am65-main: Add hwspinlock node
arm64: dts: ti: k3-j721e-main: Add hwspinlock node
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 6 ++++++
arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 6 ++++++
2 files changed, 12 insertions(+)
--
2.22.0
^ permalink raw reply
* Re: [PATCH v2 6/7] dt-bindings: net: realtek: Add property to configure LED mode
From: Andrew Lunn @ 2019-07-22 19:01 UTC (permalink / raw)
To: Matthias Kaehlcke
Cc: Rob Herring, Florian Fainelli, David S . Miller, Mark Rutland,
Heiner Kallweit, netdev, devicetree, linux-kernel@vger.kernel.org,
Douglas Anderson
In-Reply-To: <20190722171418.GV250418@google.com>
On Mon, Jul 22, 2019 at 10:14:18AM -0700, Matthias Kaehlcke wrote:
> I'm working on a generic binding.
>
> I wonder what is the best process for reviewing/landing it, I'm
> doubting between two options:
>
> a) only post the binding doc and the generic PHY code that reads
> the configuration from the DT. Post Realtek patches once
> the binding/generic code has been acked.
>
> pros: no churn from Realtek specific patches
> cons: initially no (real) user of the new binding
>
> b) post generic and Realtek changes together
>
> pros: the binding has a user initially
> cons: churn from Realtek specific patches
>
> I can do either, depending on what maintainers/reviewers prefer. I'm
> slightly inclined towards a)
Hi Matthias
It is normal to include one user of any generic API which is added,
just to make is clear how an API should be used.
Andrew
^ permalink raw reply
* Re: [PATCH v3 6/7] dt-bindings: Add ANX6345 DP/eDP transmitter binding
From: Vasily Khoruzhick @ 2019-07-22 18:51 UTC (permalink / raw)
To: Torsten Duwe
Cc: Maxime Ripard, Chen-Yu Tsai, Rob Herring, Mark Rutland,
Thierry Reding, David Airlie, Daniel Vetter, Andrzej Hajda,
Laurent Pinchart, Icenowy Zheng, Sean Paul, Harald Geyer,
Greg Kroah-Hartman, Thomas Gleixner, dri-devel, devicetree,
arm-linux, linux-kernel
In-Reply-To: <20190722151202.5506768B20@verein.lst.de>
On Mon, Jul 22, 2019 at 8:12 AM Torsten Duwe <duwe@lst.de> wrote:
>
> The anx6345 is an ultra-low power DisplayPort/eDP transmitter designed
> for portable devices.
>
> Add a binding document for it.
I believe you'll have to convert it to yaml format.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Torsten Duwe <duwe@suse.de>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> .../devicetree/bindings/display/bridge/anx6345.txt | 57 ++++++++++++++++++++++
> 1 file changed, 57 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/bridge/anx6345.txt
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/anx6345.txt b/Documentation/devicetree/bindings/display/bridge/anx6345.txt
> new file mode 100644
> index 000000000000..0af092d101c5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/anx6345.txt
> @@ -0,0 +1,57 @@
> +Analogix ANX6345 eDP Transmitter
> +--------------------------------
> +
> +The ANX6345 is an ultra-low power Full-HD eDP transmitter designed for
> +portable devices.
> +
> +Required properties:
> +
> + - compatible : "analogix,anx6345"
> + - reg : I2C address of the device
> + - reset-gpios : Which GPIO to use for reset (active low)
> + - dvdd12-supply : Regulator for 1.2V digital core power.
> + - dvdd25-supply : Regulator for 2.5V digital core power.
> + - Video port 0 for LVTTL input, using the DT bindings defined in [1].
> +
> +Optional properties:
> +
> + - Video port 1 for eDP output (panel or connector) using the DT bindings
> + defined in [1].
> +
> +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> +Example:
> +
> +anx6345: anx6345@38 {
> + compatible = "analogix,anx6345";
> + reg = <0x38>;
> + reset-gpios = <&pio 3 24 GPIO_ACTIVE_LOW>; /* PD24 */
> + dvdd25-supply = <®_dldo2>;
> + dvdd12-supply = <®_fldo1>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + anx6345_in: port@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> + anx6345_in_tcon0: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&tcon0_out_anx6345>;
> + };
> + };
> +
> + anx6345_out: port@1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> +
> + anx6345_out_panel: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&panel_in_edp>;
> + };
> + };
> + };
> +};
> --
> 2.16.4
>
^ permalink raw reply
* Re: [PATCH v3 5/7] drm/bridge: Add Analogix anx6345 support
From: Vasily Khoruzhick @ 2019-07-22 18:49 UTC (permalink / raw)
To: Torsten Duwe
Cc: Mark Rutland, devicetree, Maxime Ripard, Greg Kroah-Hartman,
linux-kernel, dri-devel, David Airlie, Chen-Yu Tsai, Rob Herring,
Thierry Reding, Laurent Pinchart, Harald Geyer, Sean Paul,
Thomas Gleixner, arm-linux, Icenowy Zheng
In-Reply-To: <20190722151154.8344568BFE@verein.lst.de>
On Mon, Jul 22, 2019 at 8:11 AM Torsten Duwe <duwe@lst.de> wrote:
>
> From: Icenowy Zheng <icenowy@aosc.io>
>
> The ANX6345 is an ultra-low power DisplayPower/eDP transmitter designed
> for portable devices. This driver adds initial support for RGB to eDP
> mode, without HPD and interrupts.
>
> This is a configuration usually seen in eDP applications.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> Signed-off-by: Torsten Duwe <duwe@suse.de>
> ---
> drivers/gpu/drm/bridge/analogix/Kconfig | 12 +
> drivers/gpu/drm/bridge/analogix/Makefile | 1 +
> drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 797 +++++++++++++++++++++
> 3 files changed, 810 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
>
> --- a/drivers/gpu/drm/bridge/analogix/Kconfig
> +++ b/drivers/gpu/drm/bridge/analogix/Kconfig
> @@ -1,6 +1,18 @@
> # SPDX-License-Identifier: GPL-2.0-only
> +config DRM_ANALOGIX_ANX6345
> + tristate "Analogix ANX6345 bridge"
> + select DRM_ANALOGIX_DP
> + select DRM_KMS_HELPER
> + select REGMAP_I2C
> + help
> + ANX6345 is an ultra-low Full-HD DisplayPort/eDP
> + transmitter designed for portable devices. The
> + ANX6345 transforms the LVTTL RGB output of an
> + application processor to eDP or DisplayPort.
> +
> config DRM_ANALOGIX_ANX78XX
> tristate "Analogix ANX78XX bridge"
> + select DRM_ANALOGIX_DP
> select DRM_KMS_HELPER
> select REGMAP_I2C
> help
> --- a/drivers/gpu/drm/bridge/analogix/Makefile
> +++ b/drivers/gpu/drm/bridge/analogix/Makefile
> @@ -1,4 +1,5 @@
> # SPDX-License-Identifier: GPL-2.0-only
> analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o analogix-i2c-dptx.o
> +obj-$(CONFIG_DRM_ANALOGIX_ANX6345) += analogix-anx6345.o
> obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
> obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> @@ -0,0 +1,793 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright(c) 2016, Analogix Semiconductor.
> + * Copyright(c) 2017, Icenowy Zheng <icenowy@aosc.io>
> + *
> + * Based on anx7808 driver obtained from chromeos with copyright:
> + * Copyright(c) 2013, Google Inc.
> + */
> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/i2c.h>
> +#include <linux/interrupt.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of_platform.h>
> +#include <linux/regmap.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/types.h>
> +
> +#include <drm/drm_atomic_helper.h>
> +#include <drm/drm_crtc.h>
> +#include <drm/drm_crtc_helper.h>
> +#include <drm/drm_dp_helper.h>
> +#include <drm/drm_edid.h>
> +#include <drm/drm_of.h>
> +#include <drm/drm_panel.h>
> +#include <drm/drm_print.h>
> +#include <drm/drm_probe_helper.h>
> +
> +#include "analogix-i2c-dptx.h"
> +#include "analogix-i2c-txcommon.h"
> +
> +#define POLL_DELAY 50000 /* us */
> +#define POLL_TIMEOUT 5000000 /* us */
> +
> +#define I2C_IDX_DPTX 0
> +#define I2C_IDX_TXCOM 1
> +
> +static const u8 anx6345_i2c_addresses[] = {
> + [I2C_IDX_DPTX] = ANALOGIX_I2C_DPTX,
> + [I2C_IDX_TXCOM] = ANALOGIX_I2C_TXCOMMON,
> +};
> +#define I2C_NUM_ADDRESSES ARRAY_SIZE(anx6345_i2c_addresses)
> +
> +struct anx6345 {
> + struct drm_dp_aux aux;
> + struct drm_bridge bridge;
> + struct i2c_client *client;
> + struct edid *edid;
> + struct drm_connector connector;
> + struct drm_dp_link link;
> + struct drm_panel *panel;
> + struct regulator *dvdd12;
> + struct regulator *dvdd25;
> + struct gpio_desc *gpiod_reset;
> + struct mutex lock; /* protect EDID access */
> +
> + /* I2C Slave addresses of ANX6345 are mapped as DPTX and SYS */
> + struct i2c_client *i2c_clients[I2C_NUM_ADDRESSES];
> + struct regmap *map[I2C_NUM_ADDRESSES];
> +
> + u16 chipid;
> + u8 dpcd[DP_RECEIVER_CAP_SIZE];
> +
> + bool powered;
> +};
> +
> +static inline struct anx6345 *connector_to_anx6345(struct drm_connector *c)
> +{
> + return container_of(c, struct anx6345, connector);
> +}
> +
> +static inline struct anx6345 *bridge_to_anx6345(struct drm_bridge *bridge)
> +{
> + return container_of(bridge, struct anx6345, bridge);
> +}
> +
> +static int anx6345_set_bits(struct regmap *map, u8 reg, u8 mask)
> +{
> + return regmap_update_bits(map, reg, mask, mask);
> +}
> +
> +static int anx6345_clear_bits(struct regmap *map, u8 reg, u8 mask)
> +{
> + return regmap_update_bits(map, reg, mask, 0);
> +}
> +
> +static ssize_t anx6345_aux_transfer(struct drm_dp_aux *aux,
> + struct drm_dp_aux_msg *msg)
> +{
> + struct anx6345 *anx6345 = container_of(aux, struct anx6345, aux);
> +
> + return anx_dp_aux_transfer(anx6345->map[I2C_IDX_DPTX], msg);
> +}
> +
> +static int anx6345_dp_link_training(struct anx6345 *anx6345)
> +{
> + unsigned int value;
> + u8 dp_bw;
> + int err;
> +
> + err = anx6345_clear_bits(anx6345->map[I2C_IDX_TXCOM],
> + SP_POWERDOWN_CTRL_REG,
> + SP_TOTAL_PD);
> + if (err)
> + return err;
> +
> + err = drm_dp_dpcd_readb(&anx6345->aux, DP_MAX_LINK_RATE, &dp_bw);
> + if (err < 0)
> + return err;
> +
> + switch (dp_bw) {
> + case DP_LINK_BW_1_62:
> + case DP_LINK_BW_2_7:
> + break;
> +
> + default:
> + DRM_DEBUG_KMS("DP bandwidth (%#02x) not supported\n", dp_bw);
> + return -EINVAL;
> + }
> +
> + err = anx6345_set_bits(anx6345->map[I2C_IDX_TXCOM], SP_VID_CTRL1_REG,
> + SP_VIDEO_MUTE);
> + if (err)
> + return err;
> +
> + err = anx6345_clear_bits(anx6345->map[I2C_IDX_TXCOM],
> + SP_VID_CTRL1_REG, SP_VIDEO_EN);
> + if (err)
> + return err;
> +
> + /* Get DPCD info */
> + err = drm_dp_dpcd_read(&anx6345->aux, DP_DPCD_REV,
> + &anx6345->dpcd, DP_RECEIVER_CAP_SIZE);
> + if (err < 0) {
> + DRM_ERROR("Failed to read DPCD: %d\n", err);
> + return err;
> + }
> +
> + /* Clear channel x SERDES power down */
> + err = anx6345_clear_bits(anx6345->map[I2C_IDX_DPTX],
> + SP_DP_ANALOG_POWER_DOWN_REG, SP_CH0_PD);
> + if (err)
> + return err;
> +
> + /* Check link capabilities */
> + err = drm_dp_link_probe(&anx6345->aux, &anx6345->link);
> + if (err < 0) {
> + DRM_ERROR("Failed to probe link capabilities: %d\n", err);
> + return err;
> + }
> +
> + /* Power up the sink */
> + err = drm_dp_link_power_up(&anx6345->aux, &anx6345->link);
> + if (err < 0) {
> + DRM_ERROR("Failed to power up DisplayPort link: %d\n", err);
> + return err;
> + }
> +
> + /* Possibly enable downspread on the sink */
> + err = regmap_write(anx6345->map[I2C_IDX_DPTX],
> + SP_DP_DOWNSPREAD_CTRL1_REG, 0);
> + if (err)
> + return err;
> +
> + if (anx6345->dpcd[DP_MAX_DOWNSPREAD] & DP_MAX_DOWNSPREAD_0_5) {
> + DRM_DEBUG("Enable downspread on the sink\n");
> + /* 4000PPM */
> + err = regmap_write(anx6345->map[I2C_IDX_DPTX],
> + SP_DP_DOWNSPREAD_CTRL1_REG, 8);
> + if (err)
> + return err;
> +
> + err = drm_dp_dpcd_writeb(&anx6345->aux, DP_DOWNSPREAD_CTRL,
> + DP_SPREAD_AMP_0_5);
> + if (err < 0)
> + return err;
> + } else {
> + err = drm_dp_dpcd_writeb(&anx6345->aux, DP_DOWNSPREAD_CTRL, 0);
> + if (err < 0)
> + return err;
> + }
> +
> + /* Set the lane count and the link rate on the sink */
> + if (drm_dp_enhanced_frame_cap(anx6345->dpcd))
> + err = anx6345_set_bits(anx6345->map[I2C_IDX_DPTX],
> + SP_DP_SYSTEM_CTRL_BASE + 4,
> + SP_ENHANCED_MODE);
> + else
> + err = anx6345_clear_bits(anx6345->map[I2C_IDX_DPTX],
> + SP_DP_SYSTEM_CTRL_BASE + 4,
> + SP_ENHANCED_MODE);
> + if (err)
> + return err;
> +
> + value = drm_dp_link_rate_to_bw_code(anx6345->link.rate);
> + err = regmap_write(anx6345->map[I2C_IDX_DPTX],
> + SP_DP_MAIN_LINK_BW_SET_REG, value);
> + if (err)
> + return err;
> +
> + err = regmap_write(anx6345->map[I2C_IDX_DPTX],
> + SP_DP_LANE_COUNT_SET_REG, anx6345->link.num_lanes);
> + if (err)
> + return err;
> +
> + err = drm_dp_link_configure(&anx6345->aux, &anx6345->link);
> + if (err < 0) {
> + DRM_ERROR("Failed to configure DisplayPort link: %d\n", err);
> + return err;
> + }
> +
> + /* Start training on the source */
> + err = regmap_write(anx6345->map[I2C_IDX_DPTX], SP_DP_LT_CTRL_REG,
> + SP_LT_EN);
> + if (err)
> + return err;
> +
> + return regmap_read_poll_timeout(anx6345->map[I2C_IDX_DPTX],
> + SP_DP_LT_CTRL_REG,
> + value, !(value & SP_DP_LT_INPROGRESS),
> + POLL_DELAY, POLL_TIMEOUT);
> +}
> +
> +static int anx6345_tx_initialization(struct anx6345 *anx6345)
> +{
> + int err, i;
> +
> + /* FIXME: colordepth is hardcoded for now */
> + err = regmap_write(anx6345->map[I2C_IDX_TXCOM], SP_VID_CTRL2_REG,
> + SP_IN_BPC_6BIT << SP_IN_BPC_SHIFT);
> + if (err)
> + return err;
> +
> + err = regmap_write(anx6345->map[I2C_IDX_DPTX], SP_DP_PLL_CTRL_REG, 0);
> + if (err)
> + return err;
> +
> + err = regmap_write(anx6345->map[I2C_IDX_TXCOM],
> + SP_ANALOG_DEBUG1_REG, 0);
> + if (err)
> + return err;
> +
> + err = regmap_write(anx6345->map[I2C_IDX_DPTX],
> + SP_DP_LINK_DEBUG_CTRL_REG,
> + SP_NEW_PRBS7 | SP_M_VID_DEBUG);
> + if (err)
> + return err;
> +
> + err = regmap_write(anx6345->map[I2C_IDX_DPTX],
> + SP_DP_ANALOG_POWER_DOWN_REG, 0);
> + if (err)
> + return err;
> +
> + /* Force HPD */
> + err = anx6345_set_bits(anx6345->map[I2C_IDX_DPTX],
> + SP_DP_SYSTEM_CTRL_BASE + 3,
> + SP_HPD_FORCE | SP_HPD_CTRL);
> + if (err)
> + return err;
> +
> + for (i = 0; i < 4; i++) {
> + /* 4 lanes */
> + err = regmap_write(anx6345->map[I2C_IDX_DPTX],
> + SP_DP_LANE0_LT_CTRL_REG + i, 0);
> + if (err)
> + return err;
> + }
> +
> + /* Reset AUX */
> + err = anx6345_set_bits(anx6345->map[I2C_IDX_TXCOM],
> + SP_RESET_CTRL2_REG, SP_AUX_RST);
> + if (err)
> + return err;
> +
> + return anx6345_clear_bits(anx6345->map[I2C_IDX_TXCOM],
> + SP_RESET_CTRL2_REG, SP_AUX_RST);
> +}
> +
> +static void anx6345_poweron(struct anx6345 *anx6345)
> +{
> + int err;
> +
> + /* Ensure reset is asserted before starting power on sequence */
> + gpiod_set_value_cansleep(anx6345->gpiod_reset, 1);
> + usleep_range(1000, 2000);
> +
> + err = regulator_enable(anx6345->dvdd12);
> + if (err) {
> + DRM_ERROR("Failed to enable dvdd12 regulator: %d\n",
> + err);
> + return;
> + }
> +
> + /* T1 - delay between VDD12 and VDD25 should be 0-2ms */
> + usleep_range(1000, 2000);
> +
> + err = regulator_enable(anx6345->dvdd25);
> + if (err) {
> + DRM_ERROR("Failed to enable dvdd25 regulator: %d\n",
> + err);
> + return;
> + }
> +
> + /* T2 - delay between RESETN and all power rail stable,
> + * should be 2-5ms
> + */
> + usleep_range(2000, 5000);
> +
> + gpiod_set_value_cansleep(anx6345->gpiod_reset, 0);
> +
> + /* Power on registers module */
> + anx6345_set_bits(anx6345->map[I2C_IDX_TXCOM], SP_POWERDOWN_CTRL_REG,
> + SP_HDCP_PD | SP_AUDIO_PD | SP_VIDEO_PD | SP_LINK_PD);
> + anx6345_clear_bits(anx6345->map[I2C_IDX_TXCOM], SP_POWERDOWN_CTRL_REG,
> + SP_REGISTER_PD | SP_TOTAL_PD);
> +
> + if (anx6345->panel)
> + drm_panel_prepare(anx6345->panel);
> +
> + anx6345->powered = true;
> +}
> +
> +static void anx6345_poweroff(struct anx6345 *anx6345)
> +{
> + int err;
> +
> + gpiod_set_value_cansleep(anx6345->gpiod_reset, 1);
> + usleep_range(1000, 2000);
> +
> + if (anx6345->panel)
> + drm_panel_unprepare(anx6345->panel);
> +
> + err = regulator_disable(anx6345->dvdd25);
> + if (err) {
> + DRM_ERROR("Failed to disable dvdd25 regulator: %d\n",
> + err);
> + return;
> + }
> +
> + usleep_range(5000, 10000);
> +
> + err = regulator_disable(anx6345->dvdd12);
> + if (err) {
> + DRM_ERROR("Failed to disable dvdd12 regulator: %d\n",
> + err);
> + return;
> + }
> +
> + usleep_range(1000, 2000);
> +
> + anx6345->powered = false;
> +}
> +
> +static int anx6345_start(struct anx6345 *anx6345)
> +{
> + int err;
> +
> + if (!anx6345->powered)
> + anx6345_poweron(anx6345);
> +
> + /* Power on needed modules */
> + err = anx6345_clear_bits(anx6345->map[I2C_IDX_TXCOM],
> + SP_POWERDOWN_CTRL_REG,
> + SP_VIDEO_PD | SP_LINK_PD);
> +
> + err = anx6345_tx_initialization(anx6345);
> + if (err) {
> + DRM_ERROR("Failed eDP transmitter initialization: %d\n", err);
> + anx6345_poweroff(anx6345);
> + return err;
> + }
> +
> + err = anx6345_dp_link_training(anx6345);
> + if (err) {
> + DRM_ERROR("Failed link training: %d\n", err);
> + anx6345_poweroff(anx6345);
> + return err;
> + }
> +
> + /*
> + * This delay seems to help keep the hardware in a good state. Without
> + * it, there are times where it fails silently.
> + */
> + usleep_range(10000, 15000);
> +
> + return 0;
> +}
> +
> +static int anx6345_config_dp_output(struct anx6345 *anx6345)
> +{
> + int err;
> +
> + err = anx6345_clear_bits(anx6345->map[I2C_IDX_TXCOM], SP_VID_CTRL1_REG,
> + SP_VIDEO_MUTE);
> + if (err)
> + return err;
> +
> + /* Enable DP output */
> + err = anx6345_set_bits(anx6345->map[I2C_IDX_TXCOM], SP_VID_CTRL1_REG,
> + SP_VIDEO_EN);
> + if (err)
> + return err;
> +
> + /* Force stream valid */
> + return anx6345_set_bits(anx6345->map[I2C_IDX_DPTX],
> + SP_DP_SYSTEM_CTRL_BASE + 3,
> + SP_STRM_FORCE | SP_STRM_CTRL);
> +}
> +
> +static int anx6345_get_downstream_info(struct anx6345 *anx6345)
> +{
> + u8 value;
> + int err;
> +
> + err = drm_dp_dpcd_readb(&anx6345->aux, DP_SINK_COUNT, &value);
> + if (err < 0) {
> + DRM_ERROR("Get sink count failed %d\n", err);
> + return err;
> + }
> +
> + if (!DP_GET_SINK_COUNT(value)) {
> + DRM_ERROR("Downstream disconnected\n");
> + return -EIO;
> + }
> +
> + return 0;
> +}
> +
> +static int anx6345_get_modes(struct drm_connector *connector)
> +{
> + struct anx6345 *anx6345 = connector_to_anx6345(connector);
> + int err, num_modes = 0;
> + bool power_off = false;
> +
> + mutex_lock(&anx6345->lock);
> +
> + if (!anx6345->edid) {
> + if (!anx6345->powered) {
> + anx6345_poweron(anx6345);
> + power_off = true;
> + }
> +
> + err = anx6345_get_downstream_info(anx6345);
> + if (err) {
> + DRM_ERROR("Failed to get downstream info: %d\n", err);
> + goto unlock;
> + }
> +
> + anx6345->edid = drm_get_edid(connector, &anx6345->aux.ddc);
> + if (!anx6345->edid)
> + DRM_ERROR("Failed to read EDID from panel\n");
> +
> + err = drm_connector_update_edid_property(connector,
> + anx6345->edid);
> + if (err) {
> + DRM_ERROR("Failed to update EDID property: %d\n", err);
> + goto unlock;
> + }
> + }
> +
> + num_modes += drm_add_edid_modes(connector, anx6345->edid);
> +
> +unlock:
> + if (power_off)
> + anx6345_poweroff(anx6345);
> +
> + mutex_unlock(&anx6345->lock);
> +
> + if (!num_modes && anx6345->panel)
> + num_modes += drm_panel_get_modes(anx6345->panel);
> +
> + return num_modes;
> +}
> +
> +static const struct drm_connector_helper_funcs anx6345_connector_helper_funcs = {
> + .get_modes = anx6345_get_modes,
> +};
> +
> +static void
> +anx6345_connector_destroy(struct drm_connector *connector)
> +{
> + struct anx6345 *anx6345 = connector_to_anx6345(connector);
> +
> + if (anx6345->panel)
> + drm_panel_detach(anx6345->panel);
> + drm_connector_cleanup(connector);
> +}
> +
> +static const struct drm_connector_funcs anx6345_connector_funcs = {
> + .fill_modes = drm_helper_probe_single_connector_modes,
> + .destroy = anx6345_connector_destroy,
> + .reset = drm_atomic_helper_connector_reset,
> + .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> + .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> +};
> +
> +static int anx6345_bridge_attach(struct drm_bridge *bridge)
> +{
> + struct anx6345 *anx6345 = bridge_to_anx6345(bridge);
> + int err;
> +
> + if (!bridge->encoder) {
> + DRM_ERROR("Parent encoder object not found");
> + return -ENODEV;
> + }
> +
> + /* Register aux channel */
> + anx6345->aux.name = "DP-AUX";
> + anx6345->aux.dev = &anx6345->client->dev;
> + anx6345->aux.transfer = anx6345_aux_transfer;
> +
> + err = drm_dp_aux_register(&anx6345->aux);
> + if (err < 0) {
> + DRM_ERROR("Failed to register aux channel: %d\n", err);
> + return err;
> + }
> +
> + err = drm_connector_init(bridge->dev, &anx6345->connector,
> + &anx6345_connector_funcs,
> + DRM_MODE_CONNECTOR_eDP);
> + if (err) {
> + DRM_ERROR("Failed to initialize connector: %d\n", err);
> + return err;
> + }
> +
> + drm_connector_helper_add(&anx6345->connector,
> + &anx6345_connector_helper_funcs);
> +
> + err = drm_connector_register(&anx6345->connector);
> + if (err) {
> + DRM_ERROR("Failed to register connector: %d\n", err);
> + return err;
> + }
> +
> + anx6345->connector.polled = DRM_CONNECTOR_POLL_HPD;
> +
> + err = drm_connector_attach_encoder(&anx6345->connector,
> + bridge->encoder);
> + if (err) {
> + DRM_ERROR("Failed to link up connector to encoder: %d\n", err);
> + return err;
> + }
> +
> + if (anx6345->panel) {
> + err = drm_panel_attach(anx6345->panel, &anx6345->connector);
> + if (err) {
> + DRM_ERROR("Failed to attach panel: %d\n", err);
> + return err;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static enum drm_mode_status
> +anx6345_bridge_mode_valid(struct drm_bridge *bridge,
> + const struct drm_display_mode *mode)
> +{
> + if (mode->flags & DRM_MODE_FLAG_INTERLACE)
> + return MODE_NO_INTERLACE;
> +
> + /* Max 1200p at 5.4 Ghz, one lane */
> + if (mode->clock > 154000)
> + return MODE_CLOCK_HIGH;
> +
> + return MODE_OK;
> +}
> +
> +static void anx6345_bridge_disable(struct drm_bridge *bridge)
> +{
> + struct anx6345 *anx6345 = bridge_to_anx6345(bridge);
> +
> + /* Power off all modules except configuration registers access */
> + anx6345_set_bits(anx6345->map[I2C_IDX_TXCOM], SP_POWERDOWN_CTRL_REG,
> + SP_HDCP_PD | SP_AUDIO_PD | SP_VIDEO_PD | SP_LINK_PD);
> + if (anx6345->panel)
> + drm_panel_disable(anx6345->panel);
> +
> + if (anx6345->powered)
> + anx6345_poweroff(anx6345);
> +}
> +
> +static void anx6345_bridge_enable(struct drm_bridge *bridge)
> +{
> + struct anx6345 *anx6345 = bridge_to_anx6345(bridge);
> + int err;
> +
> + if (anx6345->panel)
> + drm_panel_enable(anx6345->panel);
> +
> + err = anx6345_start(anx6345);
> + if (err) {
> + DRM_ERROR("Failed to initialize: %d\n", err);
> + return;
> + }
> +
> + err = anx6345_config_dp_output(anx6345);
> + if (err)
> + DRM_ERROR("Failed to enable DP output: %d\n", err);
> +}
> +
> +static const struct drm_bridge_funcs anx6345_bridge_funcs = {
> + .attach = anx6345_bridge_attach,
> + .mode_valid = anx6345_bridge_mode_valid,
> + .disable = anx6345_bridge_disable,
> + .enable = anx6345_bridge_enable,
> +};
> +
> +static void unregister_i2c_dummy_clients(struct anx6345 *anx6345)
> +{
> + unsigned int i;
> +
> + for (i = 1; i < ARRAY_SIZE(anx6345->i2c_clients); i++)
> + if (anx6345->i2c_clients[i] &&
> + anx6345->i2c_clients[i]->addr != anx6345->client->addr)
> + i2c_unregister_device(anx6345->i2c_clients[i]);
> +}
> +
> +static const struct regmap_config anx6345_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .max_register = 0xff,
> + .cache_type = REGCACHE_NONE,
> +};
> +
> +static const u16 anx6345_chipid_list[] = {
> + 0x6345,
> +};
> +
> +static bool anx6345_get_chip_id(struct anx6345 *anx6345)
> +{
> + unsigned int i, idl, idh, version;
> +
> + if (regmap_read(anx6345->map[I2C_IDX_TXCOM], SP_DEVICE_IDL_REG, &idl))
> + return false;
> +
> + if (regmap_read(anx6345->map[I2C_IDX_TXCOM], SP_DEVICE_IDH_REG, &idh))
> + return false;
> +
> + anx6345->chipid = (u8)idl | ((u8)idh << 8);
> +
> + if (regmap_read(anx6345->map[I2C_IDX_TXCOM], SP_DEVICE_VERSION_REG,
> + &version))
> + return false;
> +
> + for (i = 0; i < ARRAY_SIZE(anx6345_chipid_list); i++) {
> + if (anx6345->chipid == anx6345_chipid_list[i]) {
> + DRM_INFO("Found ANX%x (ver. %d) eDP Transmitter\n",
> + anx6345->chipid, version);
> + return true;
> + }
> + }
> +
> + DRM_ERROR("ANX%x (ver. %d) not supported by this driver\n",
> + anx6345->chipid, version);
> +
> + return false;
> +}
> +
> +static int anx6345_i2c_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct anx6345 *anx6345;
> + struct device *dev;
> + int i, err;
> +
> + anx6345 = devm_kzalloc(&client->dev, sizeof(*anx6345), GFP_KERNEL);
> + if (!anx6345)
> + return -ENOMEM;
> +
> + mutex_init(&anx6345->lock);
> +
> + anx6345->bridge.of_node = client->dev.of_node;
> +
> + anx6345->client = client;
> + i2c_set_clientdata(client, anx6345);
> +
> + dev = &anx6345->client->dev;
> +
> + err = drm_of_find_panel_or_bridge(client->dev.of_node, 1, 0,
> + &anx6345->panel, NULL);
> + if (err == -EPROBE_DEFER)
> + return err;
> +
> + if (err)
> + DRM_DEBUG("No panel found\n");
> +
> + /* 1.2V digital core power regulator */
> + anx6345->dvdd12 = devm_regulator_get(dev, "dvdd12-supply");
> + if (IS_ERR(anx6345->dvdd12)) {
> + DRM_ERROR("dvdd12-supply not found\n");
> + return PTR_ERR(anx6345->dvdd12);
> + }
> +
> + /* 2.5V digital core power regulator */
> + anx6345->dvdd25 = devm_regulator_get(dev, "dvdd25-supply");
> + if (IS_ERR(anx6345->dvdd25)) {
> + DRM_ERROR("dvdd25-supply not found\n");
> + return PTR_ERR(anx6345->dvdd25);
> + }
> +
> + /* GPIO for chip reset */
> + anx6345->gpiod_reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
> + if (IS_ERR(anx6345->gpiod_reset)) {
> + DRM_ERROR("Reset gpio not found\n");
> + return PTR_ERR(anx6345->gpiod_reset);
> + }
> +
> + /* Map slave addresses of ANX6345 */
> + for (i = 0; i < I2C_NUM_ADDRESSES; i++) {
> + if (anx6345_i2c_addresses[i] >> 1 != client->addr)
> + anx6345->i2c_clients[i] = i2c_new_dummy(client->adapter,
> + anx6345_i2c_addresses[i] >> 1);
> + else
> + anx6345->i2c_clients[i] = client;
> +
> + if (!anx6345->i2c_clients[i]) {
> + err = -ENOMEM;
> + DRM_ERROR("Failed to reserve I2C bus %02x\n",
> + anx6345_i2c_addresses[i]);
> + goto err_unregister_i2c;
> + }
> +
> + anx6345->map[i] = devm_regmap_init_i2c(anx6345->i2c_clients[i],
> + &anx6345_regmap_config);
> + if (IS_ERR(anx6345->map[i])) {
> + err = PTR_ERR(anx6345->map[i]);
> + DRM_ERROR("Failed regmap initialization %02x\n",
> + anx6345_i2c_addresses[i]);
> + goto err_unregister_i2c;
> + }
> + }
> +
> + /* Look for supported chip ID */
> + anx6345_poweron(anx6345);
> + if (anx6345_get_chip_id(anx6345)) {
> + anx6345->bridge.funcs = &anx6345_bridge_funcs;
> + drm_bridge_add(&anx6345->bridge);
> +
> + return 0;
> + } else {
> + anx6345_poweroff(anx6345);
> + err = -ENODEV;
> + }
> +
> +err_unregister_i2c:
> + unregister_i2c_dummy_clients(anx6345);
> + return err;
> +}
> +
> +static int anx6345_i2c_remove(struct i2c_client *client)
> +{
> + struct anx6345 *anx6345 = i2c_get_clientdata(client);
> +
> + drm_bridge_remove(&anx6345->bridge);
> +
> + unregister_i2c_dummy_clients(anx6345);
> +
> + kfree(anx6345->edid);
> +
> + mutex_destroy(&anx6345->lock);
> +
> + return 0;
> +}
> +
> +static const struct i2c_device_id anx6345_id[] = {
> + { "anx6345", 0 },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(i2c, anx6345_id);
> +
> +static const struct of_device_id anx6345_match_table[] = {
> + { .compatible = "analogix,anx6345", },
> + { /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(of, anx6345_match_table);
> +
> +static struct i2c_driver anx6345_driver = {
> + .driver = {
> + .name = "anx6345",
> + .of_match_table = of_match_ptr(anx6345_match_table),
> + },
> + .probe = anx6345_i2c_probe,
> + .remove = anx6345_i2c_remove,
> + .id_table = anx6345_id,
> +};
> +module_i2c_driver(anx6345_driver);
> +
> +MODULE_DESCRIPTION("ANX6345 eDP Transmitter driver");
> +MODULE_AUTHOR("Enric Balletbo i Serra <enric.balletbo@collabora.com>");
I believe Icenowy is the author of this driver. If you think otherwise
please add Enric to CC and get his Signed-off-by.
> +MODULE_LICENSE("GPL v2");
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v5 00/13] Allwinner A64/H6 IR support
From: Clément Péron @ 2019-07-22 18:48 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Rob Herring, Mark Rutland, Maxime Ripard,
Chen-Yu Tsai
Cc: devicetree, linux-kernel, linux-sunxi, linux-arm-kernel,
linux-media
In-Reply-To: <20190607231100.5894-1-peron.clem@gmail.com>
Hi,
This series received ack from device-tree, media and sunxi maintainers.
Can patch 2/3/4 goes to linux-media and the rest to linux-sunxi ?
Thanks,
Clément
On Sat, 8 Jun 2019 at 01:11, Clément Péron <peron.clem@gmail.com> wrote:
>
> Hi,
>
> A64 IR support series[1] pointed out that an A31 bindings should be
> introduced.
>
> This series introduce the A31 compatible bindings, then switch it on
> the already existing board.
>
> Finally introduce A64 and H6 support.
>
> I have reenable the other H6 boards IR support as Ondrej solve the issue.
>
> Regards,
> Clément
>
> [1] https://lore.kernel.org/patchwork/patch/1031390/#1221464
> [2] https://lkml.org/lkml/2019/5/27/321
> [3] https://patchwork.kernel.org/patch/10975563/
>
> Changes since v4:
> - Reuse defines for RXSTA bits definition
>
> Changes since v3:
> - Reenable IR for other H6 boards
> - Add RXSTA bits definition
> - Add Sean Young's "Acked-by" tags
>
> Changes since v2:
> - Disable IR for other H6 boards
> - Split DTS patch for H3/H5
> - Introduce IR quirks
>
> Clément Péron (11):
> dt-bindings: media: sunxi-ir: Add A31 compatible
> media: rc: Introduce sunxi_ir_quirks
> media: rc: sunxi: Add A31 compatible
> media: rc: sunxi: Add RXSTA bits definition
> ARM: dts: sunxi: Prefer A31 bindings for IR
> ARM: dts: sunxi: Prefer A31 bindings for IR
> dt-bindings: media: sunxi-ir: Add A64 compatible
> dt-bindings: media: sunxi-ir: Add H6 compatible
> arm64: dts: allwinner: h6: Add IR receiver node
> arm64: dts: allwinner: h6: Enable IR on H6 boards
> arm64: defconfig: Enable IR SUNXI option
>
> Igors Makejevs (1):
> arm64: dts: allwinner: a64: Add IR node
>
> Jernej Skrabec (1):
> arm64: dts: allwinner: a64: Enable IR on Orange Pi Win
>
> .../devicetree/bindings/media/sunxi-ir.txt | 11 ++-
> arch/arm/boot/dts/sun6i-a31.dtsi | 2 +-
> arch/arm/boot/dts/sun8i-a83t.dtsi | 2 +-
> arch/arm/boot/dts/sun9i-a80.dtsi | 2 +-
> arch/arm/boot/dts/sunxi-h3-h5.dtsi | 2 +-
> .../dts/allwinner/sun50i-a64-orangepi-win.dts | 4 +
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 18 ++++
> .../dts/allwinner/sun50i-h6-beelink-gs1.dts | 4 +
> .../dts/allwinner/sun50i-h6-orangepi.dtsi | 4 +
> .../boot/dts/allwinner/sun50i-h6-pine-h64.dts | 4 +
> arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 19 ++++
> arch/arm64/configs/defconfig | 1 +
> drivers/media/rc/sunxi-cir.c | 88 ++++++++++++++-----
> 13 files changed, 135 insertions(+), 26 deletions(-)
>
> --
> 2.20.1
>
^ permalink raw reply
* Re: [PATCH v2 0/7] Add anx6345 DP/eDP bridge for Olimex Teres-I
From: Vasily Khoruzhick @ 2019-07-22 18:47 UTC (permalink / raw)
To: Torsten Duwe
Cc: Maxime Ripard, Chen-Yu Tsai, Rob Herring, Mark Rutland,
Thierry Reding, David Airlie, Daniel Vetter, Andrzej Hajda,
Laurent Pinchart, Icenowy Zheng, Sean Paul, Harald Geyer,
Greg Kroah-Hartman, Thomas Gleixner, dri-devel, devicetree,
arm-linux, linux-kernel, "Bcc:duwe"
In-Reply-To: <20190722150414.9F97668B20@verein.lst.de>
On Mon, Jul 22, 2019 at 8:04 AM Torsten Duwe <duwe@lst.de> wrote:
>
> ANX6345 LVTTL->eDP video bridge, driver with device tree bindings.
>
> Changes from v2:
>
> * use SPDX-IDs throughout
>
> * removed the panel output again, as it was not what Maxime had in mind.
> At least the Teres-I does very well without. No connector spec, no "quirks"[1],
> just plain EDID at work.
You still need a panel to put backlight in there. Otherwise backlight
will stay on when display is turned off.
>
> * binding clarifications and cosmetic changes as suggested by Andrzej
>
> Changes from v1:
>
> * fixed up copyright information. Most code changes are only moves and thus
> retain copyright and module ownership. Even the new analogix-anx6345.c originates
> from the old 1495-line analogix-anx78xx.c, with 306 insertions and 987 deletions
> (ignoring the trivial anx78xx -> anx6345 replacements) 306 new vs. 508 old...
>
> * fixed all minor formatting issues brought up
>
> * merged previously separate new analogix_dp_i2c module into existing analogix_dp
>
> * split additional defines into a preparatory patch
>
> * renamed the factored-out common functions anx_aux_* -> anx_dp_aux_*, because
> anx_...aux_transfer was exported globally. Besides, it is now GPL-only exported.
>
> * moved chip ID read into a separate function.
>
> * keep the chip powered after a successful probe.
> (There's a good chance that this is the only display during boot!)
>
> * updated the binding document: LVTTL input is now required, only the output side
> description is optional.
>
> Laurent: I have also looked into the drm_panel_bridge infrastructure,
> but it's not that trivial to convert these drivers to it.
>
> Changes from the respective previous versions:
>
> * the reset polarity is corrected in DT and the driver;
> things should be clearer now.
>
> * as requested, add a panel (the known innolux,n116bge) and connect
> the ports.
>
> * renamed dvdd?? to *-supply to match the established scheme
>
> * trivial update to the #include list, to make it compile in 5.2
>
> --------------
> [1] I hesitate to associate information about a connected panel with that term.
> But should it be neccessary for maximum power saving (e.g. pinebooks),
> it would be good to have something here, regardless of nomenclature.
>
> Torsten
^ permalink raw reply
* Re: [PATCH V6 01/21] irqchip: tegra: Do not disable COP IRQ during suspend
From: Marc Zyngier @ 2019-07-22 18:38 UTC (permalink / raw)
To: Sowjanya Komatineni
Cc: Dmitry Osipenko, thierry.reding, jonathanh, tglx, jason,
linus.walleij, stefan, mark.rutland, pdeschrijver, pgaikwad,
sboyd, linux-clk, linux-gpio, jckuo, josephl, talho, linux-tegra,
linux-kernel, mperttunen, spatra, robh+dt, devicetree
In-Reply-To: <a2ecc3ad-b7e9-9398-d59b-c7d3fbbd10bb@nvidia.com>
On Mon, 22 Jul 2019 09:21:21 -0700
Sowjanya Komatineni <skomatineni@nvidia.com> wrote:
> On 7/22/19 3:57 AM, Dmitry Osipenko wrote:
> > 22.07.2019 13:13, Marc Zyngier пишет:
> >> On 22/07/2019 10:54, Dmitry Osipenko wrote:
> >>> 21.07.2019 22:40, Sowjanya Komatineni пишет:
> >>>> Tegra210 platforms use sc7 entry firmware to program Tegra LP0/SC7 entry
> >>>> sequence and sc7 entry firmware is run from COP/BPMP-Lite.
> >>>>
> >>>> So, COP/BPMP-Lite still need IRQ function to finish SC7 suspend sequence
> >>>> for Tegra210.
> >>>>
> >>>> This patch has fix for leaving the COP IRQ enabled for Tegra210 during
> >>>> interrupt controller suspend operation.
> >>>>
> >>>> Acked-by: Thierry Reding <treding@nvidia.com>
> >>>> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
> >>>> ---
> >>>> drivers/irqchip/irq-tegra.c | 20 ++++++++++++++++++--
> >>>> 1 file changed, 18 insertions(+), 2 deletions(-)
> >>>>
> >>>> diff --git a/drivers/irqchip/irq-tegra.c b/drivers/irqchip/irq-tegra.c
> >>>> index e1f771c72fc4..851f88cef508 100644
> >>>> --- a/drivers/irqchip/irq-tegra.c
> >>>> +++ b/drivers/irqchip/irq-tegra.c
> >>>> @@ -44,6 +44,7 @@ static unsigned int num_ictlrs;
> >>>>
> >>>> struct tegra_ictlr_soc {
> >>>> unsigned int num_ictlrs;
> >>>> + bool supports_sc7;
> >>>> };
> >>>>
> >>>> static const struct tegra_ictlr_soc tegra20_ictlr_soc = {
> >>>> @@ -56,6 +57,7 @@ static const struct tegra_ictlr_soc tegra30_ictlr_soc = {
> >>>>
> >>>> static const struct tegra_ictlr_soc tegra210_ictlr_soc = {
> >>>> .num_ictlrs = 6,
> >>>> + .supports_sc7 = true,
> >>>> };
> >>>>
> >>>> static const struct of_device_id ictlr_matches[] = {
> >>>> @@ -67,6 +69,7 @@ static const struct of_device_id ictlr_matches[] = {
> >>>>
> >>>> struct tegra_ictlr_info {
> >>>> void __iomem *base[TEGRA_MAX_NUM_ICTLRS];
> >>>> + const struct tegra_ictlr_soc *soc;
> >>>> #ifdef CONFIG_PM_SLEEP
> >>>> u32 cop_ier[TEGRA_MAX_NUM_ICTLRS];
> >>>> u32 cop_iep[TEGRA_MAX_NUM_ICTLRS];
> >>>> @@ -147,8 +150,20 @@ static int tegra_ictlr_suspend(void)
> >>>> lic->cop_ier[i] = readl_relaxed(ictlr + ICTLR_COP_IER);
> >>>> lic->cop_iep[i] = readl_relaxed(ictlr + ICTLR_COP_IEP_CLASS);
> >>>>
> >>>> - /* Disable COP interrupts */
> >>>> - writel_relaxed(~0ul, ictlr + ICTLR_COP_IER_CLR);
> >>>> + /*
> >>>> + * AVP/COP/BPMP-Lite is the Tegra boot processor.
> >>>> + *
> >>>> + * Tegra210 system suspend flow uses sc7entry firmware which
> >>>> + * is executed by COP/BPMP and it includes disabling COP IRQ,
> >>>> + * clamping CPU rail, turning off VDD_CPU, and preparing the
> >>>> + * system to go to SC7/LP0.
> >>>> + *
> >>>> + * COP/BPMP wakes up when COP IRQ is triggered and runs
> >>>> + * sc7entry-firmware. So need to keep COP interrupt enabled.
> >>>> + */
> >>>> + if (!lic->soc->supports_sc7)
> >>>> + /* Disable COP interrupts if SC7 is not supported */
> >>> All Tegra SoCs support SC7, hence the 'supports_sc7' and the comment
> >>> doesn't sound correct to me. Something like 'firmware_sc7' should suit
> >>> better here.
> >> If what you're saying is true, then the whole patch is wrong, and the
> >> SC7 property should come from DT.
> > It should be safe to assume that all of existing Tegra210 devices use
> > the firmware for SC7, hence I wouldn't say that the patch is entirely
> > wrong. To me it's not entirely correct.
>
> Yes, all existing Tegra210 platforms uses sc7 entry firmware for SC7 and
> AVP/COP IRQ need to be kept enabled as during suspend ATF triggers IRQ
> to COP for SC7 entry fw execution.
That's not the question. Dmitry says that the SC7 support is not a
property of the SoC, but mostly a platform decision on whether the
firmware supports SC7 or not.
To me, that's a clear indication that this should not be hardcoded in
the driver, but instead obtained dynamically, via DT or otherwise.
>
>
> >>>> + writel_relaxed(~0ul, ictlr + ICTLR_COP_IER_CLR);
> >>> Secondly, I'm also not sure why COP interrupts need to be disabled for
> >>> pre-T210 at all, since COP is unused. This looks to me like it was
> >>> cut-n-pasted from downstream kernel without a good reason and could be
> >>> simply removed.
> >> Please verify that this is actually the case. Tegra-2 definitely needed
> >> some level of poking, and I'm not keen on changing anything there until
> >> you (or someone else) has verified it on actual HW (see e307cc8941fc).
> > Tested on Tegra20 and Tegra30, LP1 suspend-resume works perfectly fine
> > with all COP bits removed from the driver.
> >
> > AFAIK, the reason why downstream needed that disabling is that it uses
> > proprietary firmware which is running on the COP and that firmware is
> > usually a BLOB audio/video DEC-ENC driver which doesn't cleanup
> > interrupts after itself. That firmware is not applicable for the
> > upstream kernel, hence there is no need to care about it.
> >
> >> Joseph, can you please shed some light here?
>
> SC7 entry flow uses 3rd party ATF (arm-trusted FW) blob which is the
> one that actually loads SC7 entry firmware and triggers IRQ to
> AVP/COP which causes COP to wakeup and run SC7 entry FW.
>
> So when SC7 support is enabled, IRQ need to be kept enabled and when
> SC7 FW starts execution, it will disable COP IRQ.
This looks like a lot of undocumented assumptions on what firmware
does, as well as what firmware *is*. What I gather from this thread is
that there is at least two versions of firmware (a "proprietary
firmware" for "downstream kernels", and another one for mainline), and
that they do different things.
Given that we cannot know what people actually run, I don't think we
can safely remove anything unless this gets tested on the full spectrum
of HW/FW combination.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [RESEND PATCH 01/10] dt-bindings: crypto: k3: Add sa2ul bindings documentation
From: Rob Herring @ 2019-07-22 18:29 UTC (permalink / raw)
To: Keerthy
Cc: herbert, davem, linux-kernel, linux-arm-kernel, devicetree,
t-kristo, linux-crypto, nm
In-Reply-To: <20190628042745.28455-2-j-keerthy@ti.com>
On Fri, Jun 28, 2019 at 09:57:36AM +0530, Keerthy wrote:
> The series adds Crypto hardware accelerator support for SA2UL.
> SA2UL stands for security accelerator ultra lite.
>
> The Security Accelerator (SA2_UL) subsystem provides hardware
> cryptographic acceleration for the following use cases:
> • Encryption and authentication for secure boot
> • Encryption and authentication of content in applications
> requiring DRM (digital rights management) and
> content/asset protection
> The device includes one instantiation of SA2_UL named SA2_UL0
>
> SA2UL needs on tx channel and a pair of rx dma channels.
>
> Signed-off-by: Keerthy <j-keerthy@ti.com>
> ---
> .../devicetree/bindings/crypto/sa2ul.txt | 47 +++++++++++++++++++
> 1 file changed, 47 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/crypto/sa2ul.txt
>
> diff --git a/Documentation/devicetree/bindings/crypto/sa2ul.txt b/Documentation/devicetree/bindings/crypto/sa2ul.txt
> new file mode 100644
> index 000000000000..81cc039673b4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/crypto/sa2ul.txt
> @@ -0,0 +1,47 @@
> +K3 SoC SA2UL crypto module
> +
> +Required properties:
> +
> +- compatible : Should be:
> + - "ti,sa2ul-crypto"
Needs to be SoC specific.
> +- reg : Offset and length of the register set for the module
> +
> +- dmas: DMA specifiers for tx and rx dma. sa2ul needs one tx channel
> + and 2 rx channels. First rx channel for < 256 bytes and
> + the other one for >=256 bytes. See the DMA client binding,
> + Documentation/devicetree/bindings/dma/dma.txt
> +- dma-names: DMA request names has to have one tx and 2 rx names
> + corresponding to dmas abive.
> +- ti,psil-config* - UDMA PSIL native Peripheral using packet mode.
> + SA2UL must have EPIB(Extended protocal information block)
> + and PSDATA(protocol specific data) properties.
If ti,needs-epib is required, then why do you need to specify it in DT?
In any case, this all seems like channel config info that should be part
of the #dma-cells.
Also, don't use vendor prefixes on node names.
> +
> +Example AM654 SA2UL:
> +crypto: crypto@4E00000 {
> + compatible = "ti,sa2ul-crypto";
> + reg = <0x0 0x4E00000 0x0 0x1200>;
> + ti,psil-base = <0x4000>;
> +
> + dmas = <&main_udmap &crypto 0 UDMA_DIR_TX>,
> + <&main_udmap &crypto 0 UDMA_DIR_RX>,
> + <&main_udmap &crypto 1 UDMA_DIR_RX>;
> + dma-names = "tx", "rx1", "rx2";
> +
> + ti,psil-config0 {
> + linux,udma-mode = <UDMA_PKT_MODE>;
> + ti,needs-epib;
> + ti,psd-size = <64>;
> + };
> +
> + ti,psil-config1 {
> + linux,udma-mode = <UDMA_PKT_MODE>;
> + ti,needs-epib;
> + ti,psd-size = <64>;
> + };
> +
> + ti,psil-config2 {
> + linux,udma-mode = <UDMA_PKT_MODE>;
> + ti,needs-epib;
> + ti,psd-size = <64>;
> + };
> +};
> --
> 2.17.1
>
^ permalink raw reply
* Re: drm/msm/dpu: Correct dpu encoder spinlock initialization
From: Sean Paul @ 2019-07-22 18:20 UTC (permalink / raw)
To: Shubhashree Dhar
Cc: dri-devel, linux-arm-msm, freedreno, devicetree, linux-kernel,
robdclark, seanpaul, hoegsberg, abhinavk, jsanka, chandanu,
nganji, jshekhar
In-Reply-To: <1561357632-15361-1-git-send-email-dhar@codeaurora.org>
On Mon, Jun 24, 2019 at 11:57:12AM +0530, Shubhashree Dhar wrote:
> dpu encoder spinlock should be initialized during dpu encoder
> init instead of dpu encoder setup which is part of commit.
> There are chances that vblank control uses the uninitialized
> spinlock if not initialized during encoder init.
>
> Change-Id: I5a18b95fa47397c834a266b22abf33a517b03a4e
> Signed-off-by: Shubhashree Dhar <dhar@codeaurora.org>
Thanks for your patch.
I've resolved the conflict and tweaked the commit message a bit to reflect
current reality.
Applied to drm-misc-fixes for 5.3
Sean
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index 5f085b5..22938c7 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -2195,8 +2195,6 @@ int dpu_encoder_setup(struct drm_device *dev, struct drm_encoder *enc,
> if (ret)
> goto fail;
>
> - spin_lock_init(&dpu_enc->enc_spinlock);
> -
> atomic_set(&dpu_enc->frame_done_timeout, 0);
> timer_setup(&dpu_enc->frame_done_timer,
> dpu_encoder_frame_done_timeout, 0);
> @@ -2250,6 +2248,7 @@ struct drm_encoder *dpu_encoder_init(struct drm_device *dev,
>
> drm_encoder_helper_add(&dpu_enc->base, &dpu_encoder_helper_funcs);
>
> + spin_lock_init(&dpu_enc->enc_spinlock);
> dpu_enc->enabled = false;
>
> return &dpu_enc->base;
> --
> 1.9.1
>
--
Sean Paul, Software Engineer, Google / Chromium OS
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: clock: cdce925: Add regulator documentation
From: Rob Herring @ 2019-07-22 18:18 UTC (permalink / raw)
To: Phil Reid; +Cc: mturquette, sboyd, robh+dt, mark.rutland, linux-clk, devicetree
In-Reply-To: <1561691950-42154-2-git-send-email-preid@electromag.com.au>
On Fri, 28 Jun 2019 11:19:09 +0800, Phil Reid wrote:
> The cdce925 has two separate supply pins. Document the bindings
> for them.
>
> Signed-off-by: Phil Reid <preid@electromag.com.au>
> ---
> Documentation/devicetree/bindings/clock/ti,cdce925.txt | 4 ++++
> 1 file changed, 4 insertions(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v9 04/18] kunit: test: add kunit_stream a std::stream like logger
From: Brendan Higgins @ 2019-07-22 18:10 UTC (permalink / raw)
To: Stephen Boyd
Cc: Petr Mladek, open list:DOCUMENTATION, Peter Zijlstra,
Amir Goldstein, dri-devel, Sasha Levin, Masahiro Yamada,
Michael Ellerman, open list:KERNEL SELFTEST FRAMEWORK, shuah,
linux-nvdimm, Frank Rowand, Knut Omang, Kieran Bingham, wfg,
Joel Stanley, David Rientjes, Jeff Dike, Dan Carpenter,
devicetree, linux-kbuild,
"Bird, Timothy" <Tim.Bird>
In-Reply-To: <20190719000834.GA3228@google.com>
On Thu, Jul 18, 2019 at 5:08 PM Brendan Higgins
<brendanhiggins@google.com> wrote:
>
> On Thu, Jul 18, 2019 at 12:22:33PM -0700, Brendan Higgins wrote:
> > On Thu, Jul 18, 2019 at 10:50 AM Stephen Boyd <sboyd@kernel.org> wrote:
> > >
> > > Quoting Brendan Higgins (2019-07-16 11:52:01)
> > > > On Tue, Jul 16, 2019 at 10:50 AM Stephen Boyd <sboyd@kernel.org> wrote:
> [...]
> > > Do you have a link to those earlier patches?
> >
> > This is the first patchset:
> >
> > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1788057.html
> >
> > In particular you can see the code for matching functions here:
> >
> > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1788073.html
> >
> > And parameter matching code here:
> >
> > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1788072.html
> >
> > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1788086.html
> >
> > My apologies in advance, but the code at this early stage had not
> > adopted the kunit_* prefix and was still using the test_* and mock_*
> > prefix. (Hence, struct kunit_stream was known as struct test_stream).
> [...]
> > > The crux of my complaint is that the string stream API is too loosely
> > > defined to be usable. It allows tests to build up a string of
> > > unstructured information, but with certain calling constraints so we
> > > have to tread carefully. If there was more structure to the data that's
> > > being recorded then the test case runner could operate on the data
> > > without having to do string/stream operations, allocations, etc. This
> > > would make the assertion logic much more concrete and specific to kunit,
> > > instead of this small kunit wrapper that's been placed on top of string
> > > stream.
> >
> > Yeah, I can see the point of wanting something that provides more
> > structure than the raw `struct kunit_stream` interface. In fact, it is
> > something I had already started working on, when I had determined it
> > would be a large effort to capture all the variations. I was further
> > put off from the idea when I had been asked to convert the KUnit
> > intermediate format from what I was using to TAP, because, as it is,
> > the current data printed out by KUnit doesn't contain all the data I
> > would like to put in it in a way that best takes advantage of the TAP
> > specification. One problematic area in particular: TAP already
> > provides a way to present a lot of the data I would like to export,
> > but it involves JSON serialization which was an idea that some of the
> > other reviewers understandably weren't too keen on. TAP also wants to
> > report data some time after it is available, which is generally not a
> > good idea for test debug information; you want to make it available as
> > soon as you can or you risk crashing with the data still inside.
> >
> > Hence, I decided we could probably spend a good long while debating
> > how I present the information. So the idea of having a loose
> > definition seemed attractive to me in its own right since it would
> > likely conform to whatever we ended up deciding in the long run. Also,
> > all the better that it was what I already had and no one seemed to
> > mind too much.
> >
> > The only constant I expect is that `struct kunit` will likely need to
> > take an abstract object with a `commit` method, or a `format` method
> > or whatever so it could control when data was going to be printed out
> > to the user. We will probably also use a string builder in there
> > somewhere.
> >
> > > TL;DR: If we can get rid of the string stream API I'd view that as an
> > > improvement because building arbitrary strings in the kernel is complex,
> > > error prone and has calling context concerns.
> >
> > True. No argument there.
> >
> > > Is the intention that other code besides unit tests will use this string
> > > stream API to build up strings? Any targets in mind? This would be a
> > > good way to get the API merged upstream given that its 2019 and we
> > > haven't had such an API in the kernel so far.
> >
> > Someone, (was it you?) asked about code sharing with a string builder
> > thingy that was used for creating structured human readable files, but
> > that seemed like a pretty massive undertaking.
> >
> > Aside from that, no. I would kind of prefered that nobody used it for
> > anything else because I the issues you described.
> >
> > Nevertheless, I think the debate over the usefulness of the
> > string_stream and kunit_stream are separate topics. Even if we made
> > kunit_stream more structured, I am pretty sure I would want to use
> > string_stream or some variation for constructing the message.
> >
> > > An "object oriented" (strong quotes!) approach where kunit_fail_msg is
> > > the innermost struct in some assertion specific structure might work
> > > nicely and allow the test runner to call a generic 'format' function to
> > > print out the message based on the type of assertion/expectation it is.
> > > It probably would mean less code size too because the strings that are
> > > common will be in the common printing function instead of created twice,
> > > in the macros/code and then copied to the heap for the string stream.
> > >
> > > struct kunit_assert {
> > > const char *line;
> > > const char *file;
> > > const char *func;
> > > void (*format)(struct kunit_assert *assert);
> > > };
> > >
> > > struct kunit_comparison_assert {
> > > enum operator operator;
> > > const char *left;
> > > const char *right;
> > > struct kunit_assert assert;
> > > };
> > >
> > > struct kunit_bool_assert {
> > > const char *truth;
> > > const char *statement;
> > > struct kunit_assert assert;
> > > };
> > >
> > > void kunit_format_comparison(struct kunit_assert *assert)
> > > {
> > > struct kunit_comparison_assert *comp = container_of(assert, ...)
> > >
> > > kunit_printk(...)
> > > }
>
> I started poking around with your suggestion while we are waiting. A
> couple early observations:
>
> 1) It is actually easier to do than I previously thought and will probably
> help with getting more of the planned TAP output stuff working.
>
> That being said, this is still a pretty substantial undertaking and
> will likely take *at least* a week to implement and properly review.
> Assuming everything goes extremely well (no unexpected issues on my
> end, very responsive reviewers, etc).
>
> 2) It *will* eliminate the need for kunit_stream.
>
> 3) ...but, it *will not* eliminate the need for string_stream.
>
> Based on my early observations, I do think it is worth doing, but I
> don't think it is worth trying to make it in this patchset (unless I
> have already missed the window, or it is going to be open for a while):
> I do think it will make things much cleaner, but I don't think it will
> achieve your desired goal of getting rid of an unstructured
> {kunit|string}_stream style interface; it just adds a layer on top of it
> that makes it harder to misuse.
>
> I attached a patch of what I have so far at the end of this email so you
> can see what I am talking about. And of course, if you agree with my
> assessment, so we can start working on it as a future patch.
>
> A couple things in regard to the patch I attached:
>
> 1) I wrote it pretty quickly so there are almost definitely mistakes.
> You should consider it RFC. I did verify it compiles though.
>
> 2) Also, I did use kunit_stream in writing it: all occurences should be
> pretty easy to replace with string_stream; nevertheless, the reason
> for this is just to make it easier to play with the current APIs. I
> wanted to have something working before I went through a big tedious
> refactoring. So sorry if it causes any confusion.
>
> 3) I also based the patch on all the KUnit patches I have queued up
> (includes things like mocking and such) since I want to see how this
> serialization thing will work with mocks and matchers and things like
> that.
>
> > I started working on something similarish, but by the time I ended up
> > coming up with a parent object whose definition was loose enough to
> > satisfy all the properties required by the child classes it ended up
> > basically being the same as what I have now just with a more complex
> > hierarchy of message manipulation logic.
> >
> > On the other hand, I didn't have the idea of doing the parent object
> > quite the way you did and that would clean up a lot of the duplicated
> > first line logic.
> >
> > I would like to give it a try, but I am afraid I am going to get
> > sucked down a really deep rabbit hole.
> >
> > > Maybe other people have opinions here on if you should do it now or
> > > later. Future coding is not a great argument because it's hard to
> > > predict the future. On the other hand, this patchset is in good shape to
> >
> > Yeah, that's kind of why I am afraid to go down this road when I have
> > something that works now and I know works with the mocking stuff I
> > want to do.
> >
> > I would like to try your suggestion, but I want to try to make it work
> > with my mocking patches before I commit to it because otherwise I am
> > just going to have to back it out in a follow up patchset.
> >
> > > merge and I'd like to use it to write unit tests for code I maintain so
> > > I don't want to see this stall out. Sorry if I'm opening the can of
> > > worms you're talking about.
> >
> > Don't be sorry. I agree with you that the kunit_stream stuff is not very pretty.
> >
> > Shuah, have we missed the merge window for 5.3?
> >
> > I saw you only sent one PR out so far for this release, and there
> > wasn't much in it; I imagine you are going to send at least one more?
> >
> > I figure, if we still got time to try out your suggestion, Stephen, no
> > harm in trying.
> >
> > Also if we missed it, then I have another couple months to play around with it.
> >
> > What do you think?
I talked to Shuah off thread, she would like us to resolve this
discussion before accepting the patchset.
She also said that this is probably going to have to wait until v5.4.
Nevertheless, Stephen, would you mind taking a look at the patch I
posted below? I would like to get your thoughts on the sum of all the
changes I am going to have to make before I try to integrate them into
the existing patches.
Sorry for being lazy, but I suspect you won't like the first pass of
how I am doing it, and I think it will probably be easier for you to
give early feedback on it as its own change anyway.
> I attached the patch mentioned above below. Let me know what you think!
>
> Cheers!
>
> From 53d475d3d56afcf92b452c6d347dbedfa1a17d34 Mon Sep 17 00:00:00 2001
> From: Brendan Higgins <brendanhiggins@google.com>
> Date: Thu, 18 Jul 2019 16:08:52 -0700
> Subject: [PATCH v1] DO NOT MERGE: started playing around with the
> serialization api
>
> ---
> include/kunit/assert.h | 130 ++++++++++++++++++++++++++++++
> include/kunit/mock.h | 4 +
> kunit/Makefile | 3 +-
> kunit/assert.c | 179 +++++++++++++++++++++++++++++++++++++++++
> kunit/mock.c | 6 +-
> 5 files changed, 318 insertions(+), 4 deletions(-)
> create mode 100644 include/kunit/assert.h
> create mode 100644 kunit/assert.c
>
> diff --git a/include/kunit/assert.h b/include/kunit/assert.h
> new file mode 100644
> index 0000000000000..e054fdff4642f
> --- /dev/null
> +++ b/include/kunit/assert.h
> @@ -0,0 +1,130 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Assertion and expectation serialization API.
> + *
> + * Copyright (C) 2019, Google LLC.
> + * Author: Brendan Higgins <brendanhiggins@google.com>
> + */
> +
> +#ifndef _KUNIT_ASSERT_H
> +#define _KUNIT_ASSERT_H
> +
> +#include <kunit/test.h>
> +#include <kunit/mock.h>
> +
> +enum kunit_assert_type {
> + KUNIT_ASSERTION,
> + KUNIT_EXPECTATION,
> +};
> +
> +struct kunit_assert {
> + enum kunit_assert_type type;
> + const char *line;
> + const char *file;
> + struct va_format message;
> + void (*format)(struct kunit_assert *assert,
> + struct kunit_stream *stream);
> +};
> +
> +void kunit_base_assert_format(struct kunit_assert *assert,
> + struct kunit_stream *stream);
> +
> +void kunit_assert_print_msg(struct kunit_assert *assert,
> + struct kunit_stream *stream);
> +
> +struct kunit_unary_assert {
> + struct kunit_assert assert;
> + const char *condition;
> + bool expected_true;
> +};
> +
> +void kunit_unary_assert_format(struct kunit_assert *assert,
> + struct kunit_stream *stream);
> +
> +struct kunit_ptr_not_err_assert {
> + struct kunit_assert assert;
> + const char *text;
> + void *value;
> +};
> +
> +void kunit_ptr_not_err_assert_format(struct kunit_assert *assert,
> + struct kunit_stream *stream);
> +
> +struct kunit_binary_assert {
> + struct kunit_assert assert;
> + const char *operation;
> + const char *left_text;
> + long long left_value;
> + const char *right_text;
> + long long right_value;
> +};
> +
> +void kunit_binary_assert_format(struct kunit_assert *assert,
> + struct kunit_stream *stream);
> +
> +struct kunit_binary_ptr_assert {
> + struct kunit_assert assert;
> + const char *operation;
> + const char *left_text;
> + void *left_value;
> + const char *right_text;
> + void *right_value;
> +};
> +
> +void kunit_binary_ptr_assert_format(struct kunit_assert *assert,
> + struct kunit_stream *stream);
> +
> +struct kunit_binary_str_assert {
> + struct kunit_assert assert;
> + const char *operation;
> + const char *left_text;
> + const char *left_value;
> + const char *right_text;
> + const char *right_value;
> +};
> +
> +void kunit_binary_str_assert_format(struct kunit_assert *assert,
> + struct kunit_stream *stream);
> +
> +struct kunit_mock_assert {
> + struct kunit_assert assert;
> +};
> +
> +struct kunit_mock_no_expectations {
> + struct kunit_mock_assert assert;
> +};
> +
> +struct kunit_mock_declaration {
> + const char *function_name;
> + const char **type_names;
> + const void **params;
> + int len;
> +};
> +
> +void kunit_mock_declaration_format(struct kunit_mock_declaration *declaration,
> + struct kunit_stream *stream);
> +
> +struct kunit_matcher_result {
> + struct kunit_assert assert;
> +};
> +
> +struct kunit_mock_failed_match {
> + struct list_head node;
> + const char *expectation_text;
> + struct kunit_matcher_result *matcher_list;
> + size_t matcher_list_len;
> +};
> +
> +void kunit_mock_failed_match_format(struct kunit_mock_failed_match *match,
> + struct kunit_stream *stream);
> +
> +struct kunit_mock_no_match {
> + struct kunit_mock_assert assert;
> + struct kunit_mock_declaration declaration;
> + struct list_head failed_match_list;
> +};
> +
> +void kunit_mock_no_match_format(struct kunit_assert *assert,
> + struct kunit_stream *stream);
> +
> +#endif /* _KUNIT_ASSERT_H */
> diff --git a/include/kunit/mock.h b/include/kunit/mock.h
> index 001b96af62f1e..52c9e427c831b 100644
> --- a/include/kunit/mock.h
> +++ b/include/kunit/mock.h
> @@ -144,6 +144,10 @@ void mock_register_formatter(struct mock_param_formatter *formatter);
>
> void mock_unregister_formatter(struct mock_param_formatter *formatter);
>
> +void mock_format_param(struct kunit_stream *stream,
> + const char *type_name,
> + const void *param);
> +
> struct mock *mock_get_global_mock(void);
>
> #define MOCK(name) name##_mock
> diff --git a/kunit/Makefile b/kunit/Makefile
> index bbf43fcfb93a9..149d856a30f04 100644
> --- a/kunit/Makefile
> +++ b/kunit/Makefile
> @@ -3,7 +3,8 @@ obj-$(CONFIG_KUNIT) += test.o \
> common-mocks.o \
> string-stream.o \
> kunit-stream.o \
> - try-catch.o
> + try-catch.o \
> + assert.o
>
> obj-$(CONFIG_KUNIT_TEST) += test-test.o \
> test-mock.o \
> diff --git a/kunit/assert.c b/kunit/assert.c
> new file mode 100644
> index 0000000000000..75bb6922a994e
> --- /dev/null
> +++ b/kunit/assert.c
> @@ -0,0 +1,179 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Assertion and expectation serialization API.
> + *
> + * Copyright (C) 2019, Google LLC.
> + * Author: Brendan Higgins <brendanhiggins@google.com>
> + */
> +#include <kunit/assert.h>
> +
> +void kunit_base_assert_format(struct kunit_assert *assert,
> + struct kunit_stream *stream)
> +{
> + const char *expect_or_assert;
> +
> + if (assert->type == KUNIT_EXPECTATION)
> + expect_or_assert = "EXPECTATION";
> + else
> + expect_or_assert = "ASSERTION";
> +
> + kunit_stream_add(stream, "%s FAILED at %s:%s\n",
> + expect_or_assert, assert->file, assert->line);
> +}
> +
> +void kunit_assert_print_msg(struct kunit_assert *assert,
> + struct kunit_stream *stream)
> +{
> + if (assert->message.fmt)
> + kunit_stream_add(stream, "\n%pV", &assert->message);
> +}
> +
> +void kunit_unary_assert_format(struct kunit_assert *assert,
> + struct kunit_stream *stream)
> +{
> + struct kunit_unary_assert *unary_assert = container_of(
> + assert, struct kunit_unary_assert, assert);
> +
> + kunit_base_assert_format(assert, stream);
> + if (unary_assert->expected_true)
> + kunit_stream_add(stream,
> + "\tExpected %s to be true, but is false\n",
> + unary_assert->condition);
> + else
> + kunit_stream_add(stream,
> + "\tExpected %s to be false, but is true\n",
> + unary_assert->condition);
> + kunit_assert_print_msg(assert, stream);
> +}
> +
> +void kunit_ptr_not_err_assert_format(struct kunit_assert *assert,
> + struct kunit_stream *stream)
> +{
> + struct kunit_ptr_not_err_assert *ptr_assert = container_of(
> + assert, struct kunit_ptr_not_err_assert, assert);
> +
> + kunit_base_assert_format(assert, stream);
> + if (!ptr_assert->value) {
> + kunit_stream_add(stream,
> + "\tExpected %s is not null, but is\n",
> + ptr_assert->text);
> + } else if (IS_ERR(ptr_assert->value)) {
> + kunit_stream_add(stream,
> + "\tExpected %s is not error, but is: %ld\n",
> + ptr_assert->text,
> + PTR_ERR(ptr_assert->value));
> + }
> + kunit_assert_print_msg(assert, stream);
> +}
> +
> +void kunit_binary_assert_format(struct kunit_assert *assert,
> + struct kunit_stream *stream)
> +{
> + struct kunit_binary_assert *binary_assert = container_of(
> + assert, struct kunit_binary_assert, assert);
> +
> + kunit_base_assert_format(assert, stream);
> + kunit_stream_add(stream,
> + "\tExpected %s %s %s, but\n",
> + binary_assert->left_text,
> + binary_assert->operation,
> + binary_assert->right_text);
> + kunit_stream_add(stream, "\t\t%s == %lld\n",
> + binary_assert->left_text,
> + binary_assert->left_value);
> + kunit_stream_add(stream, "\t\t%s == %lld",
> + binary_assert->right_text,
> + binary_assert->right_value);
> + kunit_assert_print_msg(assert, stream);
> +}
> +
I could probably reduce some of the code duplication here by using a
variable type struct for left_value and right_value, but that would
actually increase the usage of {kunit|string}_stream; it is probably
the right thing to do, but I wanted to get your thoughts on it first.
> +void kunit_binary_ptr_assert_format(struct kunit_assert *assert,
> + struct kunit_stream *stream)
> +{
> + struct kunit_binary_ptr_assert *binary_assert = container_of(
> + assert, struct kunit_binary_ptr_assert, assert);
> +
> + kunit_base_assert_format(assert, stream);
> + kunit_stream_add(stream,
> + "\tExpected %s %s %s, but\n",
> + binary_assert->left_text,
> + binary_assert->operation,
> + binary_assert->right_text);
> + kunit_stream_add(stream, "\t\t%s == %pK\n",
> + binary_assert->left_text,
> + binary_assert->left_value);
> + kunit_stream_add(stream, "\t\t%s == %pK",
> + binary_assert->right_text,
> + binary_assert->right_value);
> + kunit_assert_print_msg(assert, stream);
> +}
> +
> +void kunit_binary_str_assert_format(struct kunit_assert *assert,
> + struct kunit_stream *stream)
> +{
> + struct kunit_binary_str_assert *binary_assert = container_of(
> + assert, struct kunit_binary_str_assert, assert);
> +
> + kunit_base_assert_format(assert, stream);
> + kunit_stream_add(stream,
> + "\tExpected %s %s %s, but\n",
> + binary_assert->left_text,
> + binary_assert->operation,
> + binary_assert->right_text);
> + kunit_stream_add(stream, "\t\t%s == %s\n",
> + binary_assert->left_text,
> + binary_assert->left_value);
> + kunit_stream_add(stream, "\t\t%s == %s",
> + binary_assert->right_text,
> + binary_assert->right_value);
> + kunit_assert_print_msg(assert, stream);
> +}
> +
> +void kunit_mock_declaration_format(struct kunit_mock_declaration *declaration,
> + struct kunit_stream *stream)
> +{
> + int i;
> +
> + kunit_stream_add(stream, "%s(", declaration->function_name);
> + for (i = 0; i < declaration->len; i++) {
> + mock_format_param(stream,
> + declaration->type_names[i],
> + declaration->params[i]);
> + if (i < declaration->len - 1)
> + kunit_stream_add(stream, ", ");
> + }
> + kunit_stream_add(stream, ")\n");
> +}
> +
> +void kunit_mock_failed_match_format(struct kunit_mock_failed_match *match,
> + struct kunit_stream *stream)
> +{
> + struct kunit_matcher_result *result;
> + size_t i;
> +
> + kunit_stream_add(stream,
> + "Tried expectation: %s, but\n",
> + match->expectation_text);
> + for (i = 0; i < match->matcher_list_len; i++) {
> + result = &match->matcher_list[i];
> + kunit_stream_add(stream, "\t");
> + result->assert.format(&result->assert, stream);
> + kunit_stream_add(stream, "\n");
> + }
> +}
> +
> +void kunit_mock_no_match_format(struct kunit_assert *assert,
> + struct kunit_stream *stream)
> +{
> + struct kunit_mock_assert *mock_assert = container_of(
> + assert, struct kunit_mock_assert, assert);
> + struct kunit_mock_no_match *no_match = container_of(
> + mock_assert, struct kunit_mock_no_match, assert);
> + struct kunit_mock_failed_match *expectation;
> +
> + kunit_base_assert_format(assert, stream);
> + kunit_mock_declaration_format(&no_match->declaration, stream);
> +
> + list_for_each_entry(expectation, &no_match->failed_match_list, node)
> + kunit_mock_failed_match_format(expectation, stream);
> +}
> diff --git a/kunit/mock.c b/kunit/mock.c
> index ccb0abe111402..ab441a58a918c 100644
> --- a/kunit/mock.c
> +++ b/kunit/mock.c
> @@ -269,9 +269,9 @@ struct mock_param_formatter *mock_find_formatter(const char *type_name)
> return NULL;
> }
>
> -static void mock_format_param(struct kunit_stream *stream,
> - const char *type_name,
> - const void *param)
> +void mock_format_param(struct kunit_stream *stream,
> + const char *type_name,
> + const void *param)
> {
> struct mock_param_formatter *formatter;
>
> --
> 2.22.0.657.g960e92d24f-goog
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH 2/2] MIPS: dts: ingenic: Add 'cpus' node
From: Paul Cercueil @ 2019-07-22 17:55 UTC (permalink / raw)
To: Ralf Baechle, Paul Burton, James Hogan, Rob Herring, Mark Rutland
Cc: od, linux-mips, devicetree, linux-kernel, Paul Cercueil
In-Reply-To: <20190722175548.18434-1-paul@crapouillou.net>
Add 'cpus' node to the jz4740.dtsi, jz4770.dtsi, jz4780.dtsi files.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
---
arch/mips/boot/dts/ingenic/jz4740.dtsi | 19 +++++++++++
arch/mips/boot/dts/ingenic/jz4770.dtsi | 29 ++++++++++++++++
arch/mips/boot/dts/ingenic/jz4780.dtsi | 47 ++++++++++++++++++++++++++
3 files changed, 95 insertions(+)
diff --git a/arch/mips/boot/dts/ingenic/jz4740.dtsi b/arch/mips/boot/dts/ingenic/jz4740.dtsi
index 2beb78a62b7d..14d777dae87d 100644
--- a/arch/mips/boot/dts/ingenic/jz4740.dtsi
+++ b/arch/mips/boot/dts/ingenic/jz4740.dtsi
@@ -6,6 +6,25 @@
#size-cells = <1>;
compatible = "ingenic,jz4740";
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "ingenic,xburst-d0";
+ reg = <0>;
+ clocks = <&cgu JZ4740_CLK_CCLK>;
+ clock-names = "cpu";
+
+ i-cache-size = <0x4000>;
+ i-cache-block-size = <32>;
+
+ d-cache-size = <0x4000>;
+ d-cache-block-size = <32>;
+ };
+ };
+
cpuintc: interrupt-controller {
#address-cells = <0>;
#interrupt-cells = <1>;
diff --git a/arch/mips/boot/dts/ingenic/jz4770.dtsi b/arch/mips/boot/dts/ingenic/jz4770.dtsi
index 49ede6c14ff3..83ee526fbe10 100644
--- a/arch/mips/boot/dts/ingenic/jz4770.dtsi
+++ b/arch/mips/boot/dts/ingenic/jz4770.dtsi
@@ -7,6 +7,35 @@
#size-cells = <1>;
compatible = "ingenic,jz4770";
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "ingenic,xburst-d1";
+ reg = <0>;
+ clocks = <&cgu JZ4770_CLK_CCLK>;
+ clock-names = "cpu";
+
+ i-cache-size = <0x4000>;
+ i-cache-block-size = <32>;
+
+ d-cache-size = <0x4000>;
+ d-cache-block-size = <32>;
+
+ next-level-cache = <&L2_cache>;
+
+ L2_cache: cache-controller {
+ compatible = "cache";
+ cache-unified;
+ cache-level = <2>;
+ cache-size = <0x40000>;
+ cache-block-size = <32>;
+ };
+ };
+ };
+
cpuintc: interrupt-controller {
#address-cells = <0>;
#interrupt-cells = <1>;
diff --git a/arch/mips/boot/dts/ingenic/jz4780.dtsi b/arch/mips/boot/dts/ingenic/jz4780.dtsi
index b03cdec56de9..3339b37101c0 100644
--- a/arch/mips/boot/dts/ingenic/jz4780.dtsi
+++ b/arch/mips/boot/dts/ingenic/jz4780.dtsi
@@ -7,6 +7,53 @@
#size-cells = <1>;
compatible = "ingenic,jz4780";
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "ingenic,xburst-e1";
+ reg = <0>;
+
+ clocks = <&cgu JZ4780_CLK_CPU>;
+ clock-names = "cpu";
+
+ i-cache-size = <0x8000>;
+ i-cache-block-size = <32>;
+
+ d-cache-size = <0x8000>;
+ d-cache-block-size = <32>;
+
+ next-level-cache = <&L2_cache>;
+
+ L2_cache: l2-cache {
+ compatible = "cache";
+ cache-unified;
+ cache-level = <2>;
+ cache-size = <0x80000>;
+ cache-block-size = <32>;
+ };
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "ingenic,xburst-e1";
+ reg = <1>;
+
+ clocks = <&cgu JZ4780_CLK_CORE1>;
+ clock-names = "cpu";
+
+ i-cache-size = <0x8000>;
+ i-cache-block-size = <32>;
+
+ d-cache-size = <0x8000>;
+ d-cache-block-size = <32>;
+
+ next-level-cache = <&L2_cache>;
+ };
+ };
+
cpuintc: interrupt-controller {
#address-cells = <0>;
#interrupt-cells = <1>;
--
2.21.0.593.g511ec345e18
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox