* [PATCH v3 2/2] ARM: dts: sun5i: Add PocketBook 614 Plus support
From: Denis Burkov @ 2024-03-28 12:29 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Maxime Ripard, devicetree,
linux-arm-kernel, linux-sunxi, linux-kernel
Cc: Denis Burkov
In-Reply-To: <20240328122922.13796-1-hitechshell@mail.ru>
What works:
- Serial console
- mmc0, mmc2 (both microSD card slots on the board)
- All buttons (gpio and lradc based)
- Power LED
- PMIC
- RTC
- USB OTG/gadgets mode
Signed-off-by: Denis Burkov <hitechshell@mail.ru>
---
arch/arm/boot/dts/allwinner/Makefile | 1 +
.../sun5i-a13-pocketbook-614-plus.dts | 218 ++++++++++++++++++
2 files changed, 219 insertions(+)
create mode 100644 arch/arm/boot/dts/allwinner/sun5i-a13-pocketbook-614-plus.dts
diff --git a/arch/arm/boot/dts/allwinner/Makefile b/arch/arm/boot/dts/allwinner/Makefile
index 5fbb44ddacd0..6209243ad975 100644
--- a/arch/arm/boot/dts/allwinner/Makefile
+++ b/arch/arm/boot/dts/allwinner/Makefile
@@ -61,6 +61,7 @@ dtb-$(CONFIG_MACH_SUN5I) += \
sun5i-a13-olinuxino.dtb \
sun5i-a13-olinuxino-micro.dtb \
sun5i-a13-pocketbook-touch-lux-3.dtb \
+ sun5i-a13-pocketbook-614-plus.dtb \
sun5i-a13-q8-tablet.dtb \
sun5i-a13-utoo-p66.dtb \
sun5i-gr8-chip-pro.dtb \
diff --git a/arch/arm/boot/dts/allwinner/sun5i-a13-pocketbook-614-plus.dts b/arch/arm/boot/dts/allwinner/sun5i-a13-pocketbook-614-plus.dts
new file mode 100644
index 000000000000..ab8d138dc11d
--- /dev/null
+++ b/arch/arm/boot/dts/allwinner/sun5i-a13-pocketbook-614-plus.dts
@@ -0,0 +1,218 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2024 Denis Burkov <hitechshell@mail.ru>
+ */
+
+/dts-v1/;
+#include "sun5i-a13.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/leds/common.h>
+
+/ {
+ model = "PocketBook 614 Plus";
+ compatible = "pocketbook,614-plus", "allwinner,sun5i-a13";
+
+ aliases {
+ serial0 = &uart1;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led-0 {
+ color = <LED_COLOR_ID_WHITE>;
+ function = LED_FUNCTION_POWER;
+ linux,default-trigger = "default-on";
+ gpios = <&pio 4 8 GPIO_ACTIVE_LOW>; /* PE8 */
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ key-0 {
+ label = "Right";
+ linux,code = <KEY_NEXT>;
+ gpios = <&pio 6 9 GPIO_ACTIVE_LOW>; /* PG9 */
+ };
+
+ key-1 {
+ label = "Left";
+ linux,code = <KEY_PREVIOUS>;
+ gpios = <&pio 6 10 GPIO_ACTIVE_LOW>; /* PG10 */
+ };
+ };
+
+ reg_3v3_mmc0: regulator-mmc0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd-mmc0";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&pio 4 4 GPIO_ACTIVE_LOW>; /* PE4 */
+ vin-supply = <®_vcc3v3>;
+ };
+};
+
+&cpu0 {
+ cpu-supply = <®_dcdc2>;
+};
+
+&ehci0 {
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+
+ axp209: pmic@34 {
+ compatible = "x-powers,axp209";
+ reg = <0x34>;
+ interrupts = <0>;
+ };
+};
+
+#include "axp209.dtsi"
+
+&i2c1 {
+ status = "okay";
+
+ pcf8563: rtc@51 {
+ compatible = "nxp,pcf8563";
+ reg = <0x51>;
+ #clock-cells = <0>;
+ };
+};
+
+&lradc {
+ vref-supply = <®_ldo2>;
+ status = "okay";
+
+ button-300 {
+ label = "Down";
+ linux,code = <KEY_DOWN>;
+ channel = <0>;
+ voltage = <300000>;
+ };
+
+ button-700 {
+ label = "Up";
+ linux,code = <KEY_UP>;
+ channel = <0>;
+ voltage = <700000>;
+ };
+
+ button-1000 {
+ label = "Left";
+ linux,code = <KEY_LEFT>;
+ channel = <0>;
+ voltage = <1000000>;
+ };
+
+ button-1200 {
+ label = "Menu";
+ linux,code = <KEY_MENU>;
+ channel = <0>;
+ voltage = <1200000>;
+ };
+
+ button-1500 {
+ label = "Right";
+ linux,code = <KEY_RIGHT>;
+ channel = <0>;
+ voltage = <1500000>;
+ };
+};
+
+&mmc0 {
+ vmmc-supply = <®_3v3_mmc0>;
+ bus-width = <4>;
+ cd-gpios = <&pio 6 0 GPIO_ACTIVE_LOW>; /* PG0 */
+ status = "okay";
+};
+
+&mmc2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc2_4bit_pc_pins>;
+ vmmc-supply = <®_vcc3v3>;
+ bus-width = <4>;
+ non-removable;
+ status = "okay";
+};
+
+&ohci0 {
+ status = "okay";
+};
+
+&otg_sram {
+ status = "okay";
+};
+
+®_dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-name = "vdd-cpu";
+};
+
+®_dcdc3 {
+ regulator-always-on;
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1400000>;
+ regulator-name = "vdd-int-dll";
+};
+
+®_ldo1 {
+ regulator-name = "vdd-rtc";
+};
+
+®_ldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-name = "avcc";
+};
+
+®_usb0_vbus {
+ status = "okay";
+ gpio = <&pio 6 12 GPIO_ACTIVE_HIGH>; /* PG12 */
+};
+
+®_usb1_vbus {
+ gpio = <&pio 6 11 GPIO_ACTIVE_HIGH>; /* PG11 */
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_pg_pins>;
+ status = "okay";
+};
+
+&usb_otg {
+ dr_mode = "otg";
+ status = "okay";
+};
+
+&usb_power_supply {
+ status = "okay";
+};
+
+&battery_power_supply {
+ status = "okay";
+};
+
+&usbphy {
+ usb0_id_det-gpios = <&pio 6 2 GPIO_ACTIVE_HIGH>; /* PG2 */
+ usb0_vbus_det-gpios = <&axp_gpio 1 GPIO_ACTIVE_HIGH>;
+ usb0_vbus-supply = <®_usb0_vbus>;
+ usb1_vbus-supply = <®_usb1_vbus>;
+ status = "okay";
+};
--
2.43.2
^ permalink raw reply related
* [PATCH v3 1/2] dt-bindings: arm: sunxi: Add PocketBook 614 Plus
From: Denis Burkov @ 2024-03-28 12:29 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Maxime Ripard, devicetree,
linux-arm-kernel, linux-sunxi, linux-kernel
Cc: Denis Burkov, Rob Herring
Add a new board name.
Signed-off-by: Denis Burkov <hitechshell@mail.ru>
Acked-by: Rob Herring <robh@kernel.org>
---
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 09d835db6db5..43491e7f8a5e 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.yaml
+++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
@@ -774,6 +774,11 @@ properties:
- const: pocketbook,touch-lux-3
- const: allwinner,sun5i-a13
+ - description: PocketBook 614 Plus
+ items:
+ - const: pocketbook,614-plus
+ - const: allwinner,sun5i-a13
+
- description: Point of View Protab2-IPS9
items:
- const: pov,protab2-ips9
--
2.43.2
^ permalink raw reply related
* Re: [PATCH net-next v6 10/17] net: pse-pd: Add support for PSE PIs
From: Andrew Lunn @ 2024-03-28 12:24 UTC (permalink / raw)
To: Kory Maincent
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jonathan Corbet, Luis Chamberlain, Russ Weight,
Greg Kroah-Hartman, Rafael J. Wysocki, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Oleksij Rempel, Mark Brown,
Frank Rowand, Heiner Kallweit, Russell King, Thomas Petazzoni,
netdev, linux-kernel, linux-doc, devicetree, Dent Project
In-Reply-To: <20240326-feature_poe-v6-10-c1011b6ea1cb@bootlin.com>
> +.. code-block::
> +
> + +-------------+
> + | PSE PI |
> + 8 -----+ +-------------+
> + 7 -----+ Rail 1 |
> + 6 -----+------+----------------------+
> + 5 -----+ | |
> + 4 -----+ / Rail 2 | PSE 1
> + 3 -----+----? +-------------+
> + 2 -----+----+---------? |
> + 1 -----+---? +-------------+
> + |
> + +-------------+
Is ? a standard markup character? I don't remember seeing it used like
this before.
Maybe offset the connection for pins 1 and 2 from that of 3. I mean:
> + 4 -----+ / Rail 2 | PSE 1
> + 3 -----+----? +-------------+
> + 2 -----+--------+-----? |
> + 1 -----+-------? +-------------+
You version is a little ambiguous, pins 1, 2 & 3 could be
interconnected at the +. The text does however make it clear they are
not, but i don't see any harm in making the diagram clearer.
> +static int of_load_single_pse_pi_pairset(struct device_node *node,
> + struct pse_pi *pi,
> + int pairset_num)
> +{
> + struct device_node *pairset_np;
> + const char *name;
> + int ret;
> +
> + ret = of_property_read_string_index(node, "pairset-names",
> + pairset_num, &name);
> + if (ret)
> + return ret;
> +
> + if (!strcmp(name, "alternative-a")) {
> + pi->pairset[pairset_num].pinout = ALTERNATIVE_A;
> + } else if (!strcmp(name, "alternative-b")) {
> + pi->pairset[pairset_num].pinout = ALTERNATIVE_B;
> + } else {
> + pr_err("pse: wrong pairset-names value %s\n", name);
> + return -EINVAL;
Maybe include the node path in the error message? For a 24 port
switch, it will help find a typo in one of the ports. I would do this
for all error messages in this code.
Please add my Reviewed-by on the next version.
Andrew
^ permalink raw reply
* Re: [GIT PULL] Immutable branch between MFD and Regulator due for the v6.9 merge window:wq
From: Lee Jones @ 2024-03-28 12:03 UTC (permalink / raw)
To: Andre Przywara
Cc: Liam Girdwood, Mark Brown, Chen-Yu Tsai, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, devicetree, Samuel Holland,
Jernej Skrabec, Chris Morgan, linux-kernel, linux-sunxi,
Ryan Walklin
In-Reply-To: <20240328120011.GE13211@google.com>
On Thu, 28 Mar 2024, Lee Jones wrote:
> On Thu, 28 Mar 2024, Andre Przywara wrote:
>
> > On Thu, 28 Mar 2024 09:56:31 +0000
> > Lee Jones <lee@kernel.org> wrote:
> >
> > Hi Lee,
> >
> > many thanks for picking this up!
> >
> > > Enjoy!
> > >
> > > The following changes since commit 4cece764965020c22cff7665b18a012006359095:
> > >
> > > Linux 6.9-rc1 (2024-03-24 14:10:05 -0700)
> > >
> > > are available in the Git repository at:
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-regulator-v6.9
> > >
> > > for you to fetch changes up to d2ac3df75c3a995064cfac0171e082a30d8c4c66:
> > >
> > > regulator: axp20x: add support for the AXP717 (2024-03-28 09:51:03 +0000)
> > >
> > > ----------------------------------------------------------------
> > > Immutable branch between MFD and Regulator due for the v6.9 merge window
> >
> > Did you mean v6.10 merge window? Or is there a plan to merge this into
> > 6.9 still?
>
> Yes - off-by-one!
Just recreated ib-mfd-regulator-v6.10 for all the OCD types (like me!).
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [GIT PULL] Immutable branch between MFD and Regulator due for the v6.9 merge window:wq
From: Lee Jones @ 2024-03-28 12:00 UTC (permalink / raw)
To: Andre Przywara
Cc: Liam Girdwood, Mark Brown, Chen-Yu Tsai, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, devicetree, Samuel Holland,
Jernej Skrabec, Chris Morgan, linux-kernel, linux-sunxi,
Ryan Walklin
In-Reply-To: <20240328111108.5ddfa073@minigeek.lan>
On Thu, 28 Mar 2024, Andre Przywara wrote:
> On Thu, 28 Mar 2024 09:56:31 +0000
> Lee Jones <lee@kernel.org> wrote:
>
> Hi Lee,
>
> many thanks for picking this up!
>
> > Enjoy!
> >
> > The following changes since commit 4cece764965020c22cff7665b18a012006359095:
> >
> > Linux 6.9-rc1 (2024-03-24 14:10:05 -0700)
> >
> > are available in the Git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-regulator-v6.9
> >
> > for you to fetch changes up to d2ac3df75c3a995064cfac0171e082a30d8c4c66:
> >
> > regulator: axp20x: add support for the AXP717 (2024-03-28 09:51:03 +0000)
> >
> > ----------------------------------------------------------------
> > Immutable branch between MFD and Regulator due for the v6.9 merge window
>
> Did you mean v6.10 merge window? Or is there a plan to merge this into
> 6.9 still?
Yes - off-by-one!
> Also I found some issue with the LDOs' supply voltage: there are not
> all the same, as described right now. Fix is quite easy, how do you
> want to take this? As a follow up patch? And would this be squashed or
> kept separate?
> Or do you want we to send a new version? If yes, based on what branch?
Please submit a fix-up.
I'll sent out a new (ib-mfd-regulator-v6.9-1) PR based on this one.
> > ----------------------------------------------------------------
> > Andre Przywara (4):
> > regulator: axp20x: fix typo-ed identifier
> > dt-bindings: mfd: x-powers,axp152: Document AXP717
> > mfd: axp20x: Add support for AXP717 PMIC
> > regulator: axp20x: add support for the AXP717
> >
> > .../devicetree/bindings/mfd/x-powers,axp152.yaml | 2 +
> > drivers/mfd/axp20x-i2c.c | 2 +
> > drivers/mfd/axp20x-rsb.c | 1 +
> > drivers/mfd/axp20x.c | 90 ++++++++++++++++++++
> > drivers/regulator/axp20x-regulator.c | 94 +++++++++++++++++++--
> > include/linux/mfd/axp20x.h | 98 ++++++++++++++++++++--
> > 6 files changed, 277 insertions(+), 10 deletions(-)
> >
>
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v2 0/2] dt-bindings: leds: add LED_FUNCTION_* mainly for router devices
From: Lee Jones @ 2024-03-28 11:57 UTC (permalink / raw)
To: pavel, lee, robh, krzysztof.kozlowski+dt, conor+dt,
INAGAKI Hiroshi
Cc: linux-leds, devicetree, linux-kernel
In-Reply-To: <20240323074326.1428-1-musashino.open@gmail.com>
On Sat, 23 Mar 2024 16:36:08 +0900, INAGAKI Hiroshi wrote:
> This patch series adds some LED_FUNCTION_* definitions mainly for router
> devices.
> Those definitions are useful for OpenWrt or something.
>
> v1 -> v2
>
> - fix sort order of LED_FUNCTION_MOBILE
> - improve the commit description of the first commit
>
> [...]
Applied, thanks!
[1/2] dt-bindings: leds: add LED_FUNCTION_MOBILE for mobile network
commit: c332f0450f33c123a538a8fcc69fa8e4e5aedfbb
[2/2] dt-bindings: leds: add LED_FUNCTION_SPEED_* for link speed on LAN/WAN
commit: 2588a5d98532244a7faf4514f79dc684fddf4c14
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH net-next v6 01/17] MAINTAINERS: net: Add Oleksij to pse-pd maintainers
From: Andrew Lunn @ 2024-03-28 11:55 UTC (permalink / raw)
To: Kory Maincent
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jonathan Corbet, Luis Chamberlain, Russ Weight,
Greg Kroah-Hartman, Rafael J. Wysocki, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Oleksij Rempel, Mark Brown,
Frank Rowand, Heiner Kallweit, Russell King, Thomas Petazzoni,
netdev, linux-kernel, linux-doc, devicetree, Dent Project
In-Reply-To: <20240326-feature_poe-v6-1-c1011b6ea1cb@bootlin.com>
On Tue, Mar 26, 2024 at 03:04:38PM +0100, Kory Maincent wrote:
> From: Kory Maincent (Dent Project) <kory.maincent@bootlin.com>
>
> Oleksij was the first to add support for pse-pd net subsystem.
> Add himself to the maintainers seems logical.
>
> Acked-by: Oleksij Rempel <o.rempel@pengutronix.de>
> Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH v3 2/5] mfd: rk8xx: Add RK816 support
From: Lee Jones @ 2024-03-28 11:55 UTC (permalink / raw)
To: Alex Bee
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Linus Walleij, Liam Girdwood, Mark Brown, Chris Zhong, Zhang Qing,
devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
linux-gpio
In-Reply-To: <20240323132757.141861-6-knaerzche@gmail.com>
On Sat, 23 Mar 2024, Alex Bee wrote:
> This integrates RK816 support in the this existing rk8xx mfd driver.
>
> This version has unaligned interrupt registers, which requires to define a
> separate get_irq_reg callback for the regmap. Apart from that the
> integration is straightforward and the existing structures can be used as
> is. The initialization sequence has been taken from vendor kernel.
>
> Signed-off-by: Alex Bee <knaerzche@gmail.com>
> ---
> chnages since v1:
> - un-constify rk816_get_irq_reg's return type
>
> drivers/mfd/Kconfig | 4 +-
> drivers/mfd/rk8xx-core.c | 103 ++++++++++++++++++++++++++++
> drivers/mfd/rk8xx-i2c.c | 45 +++++++++++-
> include/linux/mfd/rk808.h | 141 ++++++++++++++++++++++++++++++++++++++
> 4 files changed, 290 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 4b023ee229cf..2e7286cc98e4 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -1225,7 +1225,7 @@ config MFD_RK8XX
> select MFD_CORE
>
> config MFD_RK8XX_I2C
> - tristate "Rockchip RK805/RK808/RK809/RK817/RK818 Power Management Chip"
> + tristate "Rockchip RK805/RK808/RK809/RK816/RK817/RK818 Power Management Chip"
> depends on I2C && OF
> select MFD_CORE
> select REGMAP_I2C
> @@ -1233,7 +1233,7 @@ config MFD_RK8XX_I2C
> select MFD_RK8XX
> help
> If you say yes here you get support for the RK805, RK808, RK809,
> - RK817 and RK818 Power Management chips.
> + RK816, RK817 and RK818 Power Management chips.
> This driver provides common support for accessing the device
> through I2C interface. The device supports multiple sub-devices
> including interrupts, RTC, LDO & DCDC regulators, and onkey.
> diff --git a/drivers/mfd/rk8xx-core.c b/drivers/mfd/rk8xx-core.c
> index e2261b68b844..c68a380332e7 100644
> --- a/drivers/mfd/rk8xx-core.c
> +++ b/drivers/mfd/rk8xx-core.c
> @@ -28,6 +28,10 @@ static const struct resource rtc_resources[] = {
> DEFINE_RES_IRQ(RK808_IRQ_RTC_ALARM),
> };
>
> +static const struct resource rk816_rtc_resources[] = {
> + DEFINE_RES_IRQ(RK816_IRQ_RTC_ALARM),
> +};
> +
> static const struct resource rk817_rtc_resources[] = {
> DEFINE_RES_IRQ(RK817_IRQ_RTC_ALARM),
> };
> @@ -87,6 +91,21 @@ static const struct mfd_cell rk808s[] = {
> },
> };
>
> +static const struct mfd_cell rk816s[] = {
> + { .name = "rk805-pinctrl", },
> + { .name = "rk808-clkout", },
> + { .name = "rk808-regulator", },
> + { .name = "rk805-pwrkey",
Newline after the '{'.
> + .num_resources = ARRAY_SIZE(rk805_key_resources),
> + .resources = rk805_key_resources,
> + },
> + {
> + .name = "rk808-rtc",
> + .num_resources = ARRAY_SIZE(rk816_rtc_resources),
> + .resources = rk816_rtc_resources,
> + },
> +};
> +
> static const struct mfd_cell rk817s[] = {
> { .name = "rk808-clkout", },
> { .name = "rk808-regulator", },
> @@ -148,6 +167,17 @@ static const struct rk808_reg_data rk808_pre_init_reg[] = {
> VB_LO_SEL_3500MV },
> };
>
> +static const struct rk808_reg_data rk816_pre_init_reg[] = {
> + { RK818_BUCK1_CONFIG_REG, RK817_RAMP_RATE_MASK,
> + RK817_RAMP_RATE_12_5MV_PER_US },
> + { RK818_BUCK2_CONFIG_REG, RK817_RAMP_RATE_MASK,
> + RK817_RAMP_RATE_12_5MV_PER_US },
> + { RK818_BUCK4_CONFIG_REG, BUCK_ILMIN_MASK, BUCK_ILMIN_250MA },
> + { RK808_THERMAL_REG, TEMP_HOTDIE_MSK, TEMP105C},
> + { RK808_VB_MON_REG, VBAT_LOW_VOL_MASK | VBAT_LOW_ACT_MASK,
> + RK808_VBAT_LOW_3V0 | EN_VABT_LOW_SHUT_DOWN },
> +};
> +
> static const struct rk808_reg_data rk817_pre_init_reg[] = {
> {RK817_RTC_CTRL_REG, RTC_STOP, RTC_STOP},
> /* Codec specific registers */
> @@ -350,6 +380,59 @@ static const struct regmap_irq rk808_irqs[] = {
> },
> };
>
> +static const unsigned int rk816_irq_status_offsets[] = {
> + (RK816_INT_STS_REG1 - RK816_INT_STS_REG1),
Turn this into a macro please.
> + (RK816_INT_STS_REG2 - RK816_INT_STS_REG1),
> + (RK816_INT_STS_REG3 - RK816_INT_STS_REG1),
> +};
> +
> +static const unsigned int rk816_irq_mask_offsets[] = {
> + (RK816_INT_STS_MSK_REG1 - RK816_INT_STS_MSK_REG1),
> + (RK816_INT_STS_MSK_REG2 - RK816_INT_STS_MSK_REG1),
> + (RK816_INT_STS_MSK_REG3 - RK816_INT_STS_MSK_REG1),
> +};
> +
> +static unsigned int rk816_get_irq_reg(struct regmap_irq_chip_data *data,
> + unsigned int base, int index)
> +{
> + unsigned int irq_reg = base;
> +
> + switch (base) {
> + case RK816_INT_STS_REG1:
> + irq_reg += rk816_irq_status_offsets[index];
> + break;
> + case RK816_INT_STS_MSK_REG1:
> + irq_reg += rk816_irq_mask_offsets[index];
> + break;
> + }
> +
> + return irq_reg;
> +};
> +
> +static const struct regmap_irq rk816_irqs[] = {
> + /* INT_STS_REG1 IRQs */
> + REGMAP_IRQ_REG(RK816_IRQ_PWRON_FALL, 0, RK816_INT_STS_PWRON_FALL),
> + REGMAP_IRQ_REG(RK816_IRQ_PWRON_RISE, 0, RK816_INT_STS_PWRON_RISE),
> +
> + /* INT_STS_REG2 IRQs */
> + REGMAP_IRQ_REG(RK816_IRQ_VB_LOW, 1, RK816_INT_STS_VB_LOW),
> + REGMAP_IRQ_REG(RK816_IRQ_PWRON, 1, RK816_INT_STS_PWRON),
> + REGMAP_IRQ_REG(RK816_IRQ_PWRON_LP, 1, RK816_INT_STS_PWRON_LP),
> + REGMAP_IRQ_REG(RK816_IRQ_HOTDIE, 1, RK816_INT_STS_HOTDIE),
> + REGMAP_IRQ_REG(RK816_IRQ_RTC_ALARM, 1, RK816_INT_STS_RTC_ALARM),
> + REGMAP_IRQ_REG(RK816_IRQ_RTC_PERIOD, 1, RK816_INT_STS_RTC_PERIOD),
> + REGMAP_IRQ_REG(RK816_IRQ_USB_OV, 1, RK816_INT_STS_USB_OV),
> +
> + /* INT_STS3 IRQs */
> + REGMAP_IRQ_REG(RK816_IRQ_PLUG_IN, 2, RK816_INT_STS_PLUG_IN),
> + REGMAP_IRQ_REG(RK816_IRQ_PLUG_OUT, 2, RK816_INT_STS_PLUG_OUT),
> + REGMAP_IRQ_REG(RK816_IRQ_CHG_OK, 2, RK816_INT_STS_CHG_OK),
> + REGMAP_IRQ_REG(RK816_IRQ_CHG_TE, 2, RK816_INT_STS_CHG_TE),
> + REGMAP_IRQ_REG(RK816_IRQ_CHG_TS, 2, RK816_INT_STS_CHG_TS),
> + REGMAP_IRQ_REG(RK816_IRQ_CHG_CVTLIM, 2, RK816_INT_STS_CHG_CVTLIM),
> + REGMAP_IRQ_REG(RK816_IRQ_DISCHG_ILIM, 2, RK816_INT_STS_DISCHG_ILIM),
> +};
> +
> static const struct regmap_irq rk818_irqs[] = {
> /* INT_STS */
> [RK818_IRQ_VOUT_LO] = {
> @@ -482,6 +565,18 @@ static const struct regmap_irq_chip rk808_irq_chip = {
> .init_ack_masked = true,
> };
>
> +static const struct regmap_irq_chip rk816_irq_chip = {
> + .name = "rk816",
> + .irqs = rk816_irqs,
> + .num_irqs = ARRAY_SIZE(rk816_irqs),
> + .num_regs = 3,
> + .get_irq_reg = rk816_get_irq_reg,
> + .status_base = RK816_INT_STS_REG1,
> + .mask_base = RK816_INT_STS_MSK_REG1,
> + .ack_base = RK816_INT_STS_REG1,
> + .init_ack_masked = true,
> +};
> +
> static struct regmap_irq_chip rk817_irq_chip = {
> .name = "rk817",
> .irqs = rk817_irqs,
> @@ -530,6 +625,7 @@ static int rk808_power_off(struct sys_off_data *data)
> reg = RK817_SYS_CFG(3);
> bit = DEV_OFF;
> break;
> + case RK816_ID:
> case RK818_ID:
> reg = RK818_DEVCTRL_REG;
> bit = DEV_OFF;
> @@ -637,6 +733,13 @@ int rk8xx_probe(struct device *dev, int variant, unsigned int irq, struct regmap
> cells = rk808s;
> nr_cells = ARRAY_SIZE(rk808s);
> break;
> + case RK816_ID:
> + rk808->regmap_irq_chip = &rk816_irq_chip;
> + pre_init_reg = rk816_pre_init_reg;
> + nr_pre_init_regs = ARRAY_SIZE(rk816_pre_init_reg);
> + cells = rk816s;
> + nr_cells = ARRAY_SIZE(rk816s);
> + break;
> case RK818_ID:
> rk808->regmap_irq_chip = &rk818_irq_chip;
> pre_init_reg = rk818_pre_init_reg;
> diff --git a/drivers/mfd/rk8xx-i2c.c b/drivers/mfd/rk8xx-i2c.c
> index 75b5cf09d5a0..69a6b297d723 100644
> --- a/drivers/mfd/rk8xx-i2c.c
> +++ b/drivers/mfd/rk8xx-i2c.c
> @@ -1,6 +1,6 @@
> // SPDX-License-Identifier: GPL-2.0-only
> /*
> - * Rockchip RK808/RK818 Core (I2C) driver
> + * Rockchip RK805/RK808/RK816/RK817/RK818 Core (I2C) driver
> *
> * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
> * Copyright (C) 2016 PHYTEC Messtechnik GmbH
> @@ -49,6 +49,35 @@ static bool rk808_is_volatile_reg(struct device *dev, unsigned int reg)
> return false;
> }
>
> +static bool rk816_is_volatile_reg(struct device *dev, unsigned int reg)
> +{
> + /*
> + * Technically the ROUND_30s bit makes RTC_CTRL_REG volatile, but
> + * we don't use that feature. It's better to cache.
> + */
> +
> + switch (reg) {
> + case RK808_SECONDS_REG ... RK808_WEEKS_REG:
> + case RK808_RTC_STATUS_REG:
> + case RK808_VB_MON_REG:
> + case RK808_THERMAL_REG:
> + case RK816_DCDC_EN_REG1:
> + case RK816_DCDC_EN_REG2:
> + case RK816_INT_STS_REG1:
> + case RK816_INT_STS_REG2:
> + case RK816_INT_STS_REG3:
> + case RK808_DEVCTRL_REG:
> + case RK816_SUP_STS_REG:
> + case RK816_GGSTS_REG:
> + case RK816_ZERO_CUR_ADC_REGH:
> + case RK816_ZERO_CUR_ADC_REGL:
> + case RK816_GASCNT_REG(0) ... RK816_BAT_VOL_REGL:
> + return true;
> + }
> +
> + return false;
> +}
> +
> static bool rk817_is_volatile_reg(struct device *dev, unsigned int reg)
> {
> /*
> @@ -100,6 +129,14 @@ static const struct regmap_config rk808_regmap_config = {
> .volatile_reg = rk808_is_volatile_reg,
> };
>
> +static const struct regmap_config rk816_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .max_register = RK816_DATA_REG(18),
> + .cache_type = REGCACHE_MAPLE,
> + .volatile_reg = rk816_is_volatile_reg,
> +};
> +
> static const struct regmap_config rk817_regmap_config = {
> .reg_bits = 8,
> .val_bits = 8,
> @@ -123,6 +160,11 @@ static const struct rk8xx_i2c_platform_data rk809_data = {
> .variant = RK809_ID,
> };
>
> +static const struct rk8xx_i2c_platform_data rk816_data = {
> + .regmap_cfg = &rk816_regmap_config,
> + .variant = RK816_ID,
> +};
> +
> static const struct rk8xx_i2c_platform_data rk817_data = {
> .regmap_cfg = &rk817_regmap_config,
> .variant = RK817_ID,
> @@ -161,6 +203,7 @@ static const struct of_device_id rk8xx_i2c_of_match[] = {
> { .compatible = "rockchip,rk805", .data = &rk805_data },
> { .compatible = "rockchip,rk808", .data = &rk808_data },
> { .compatible = "rockchip,rk809", .data = &rk809_data },
> + { .compatible = "rockchip,rk816", .data = &rk816_data },
> { .compatible = "rockchip,rk817", .data = &rk817_data },
> { .compatible = "rockchip,rk818", .data = &rk818_data },
> { },
> diff --git a/include/linux/mfd/rk808.h b/include/linux/mfd/rk808.h
> index 78e167a92483..b90d1c278790 100644
> --- a/include/linux/mfd/rk808.h
> +++ b/include/linux/mfd/rk808.h
> @@ -113,6 +113,145 @@ enum rk808_reg {
> #define RK808_INT_STS_MSK_REG2 0x4f
> #define RK808_IO_POL_REG 0x50
>
> +/* RK816 */
> +enum rk816_reg {
> + RK816_ID_DCDC1,
> + RK816_ID_DCDC2,
> + RK816_ID_DCDC3,
> + RK816_ID_DCDC4,
> + RK816_ID_LDO1,
> + RK816_ID_LDO2,
> + RK816_ID_LDO3,
> + RK816_ID_LDO4,
> + RK816_ID_LDO5,
> + RK816_ID_LDO6,
> + RK816_ID_BOOST,
> + RK816_ID_OTG_SW,
> +};
> +
> +enum rk816_irqs {
> + /* INT_STS_REG1 */
> + RK816_IRQ_PWRON_FALL,
> + RK816_IRQ_PWRON_RISE,
> +
> + /* INT_STS_REG2 */
> + RK816_IRQ_VB_LOW,
> + RK816_IRQ_PWRON,
> + RK816_IRQ_PWRON_LP,
> + RK816_IRQ_HOTDIE,
> + RK816_IRQ_RTC_ALARM,
> + RK816_IRQ_RTC_PERIOD,
> + RK816_IRQ_USB_OV,
> +
> + /* INT_STS_REG3 */
> + RK816_IRQ_PLUG_IN,
> + RK816_IRQ_PLUG_OUT,
> + RK816_IRQ_CHG_OK,
> + RK816_IRQ_CHG_TE,
> + RK816_IRQ_CHG_TS,
> + RK816_IRQ_CHG_CVTLIM,
> + RK816_IRQ_DISCHG_ILIM,
> +};
> +
> +/* power channel registers */
> +#define RK816_DCDC_EN_REG1 0x23
> +
> +#define RK816_DCDC_EN_REG2 0x24
> +#define RK816_BOOST_EN BIT(1)
> +#define RK816_OTG_EN BIT(2)
> +#define RK816_BOOST_EN_MSK BIT(5)
> +#define RK816_OTG_EN_MSK BIT(6)
> +#define RK816_BUCK_DVS_CONFIRM BIT(7)
> +
> +#define RK816_LDO_EN_REG1 0x27
> +
> +#define RK816_LDO_EN_REG2 0x28
> +
> +/* interrupt registers and irq definitions */
> +#define RK816_INT_STS_REG1 0x49
> +#define RK816_INT_STS_MSK_REG1 0x4a
> +#define RK816_INT_STS_PWRON_FALL BIT(5)
> +#define RK816_INT_STS_PWRON_RISE BIT(6)
> +
> +#define RK816_INT_STS_REG2 0x4c
> +#define RK816_INT_STS_MSK_REG2 0x4d
> +#define RK816_INT_STS_VB_LOW BIT(1)
> +#define RK816_INT_STS_PWRON BIT(2)
> +#define RK816_INT_STS_PWRON_LP BIT(3)
> +#define RK816_INT_STS_HOTDIE BIT(4)
> +#define RK816_INT_STS_RTC_ALARM BIT(5)
> +#define RK816_INT_STS_RTC_PERIOD BIT(6)
> +#define RK816_INT_STS_USB_OV BIT(7)
> +
> +#define RK816_INT_STS_REG3 0x4e
> +#define RK816_INT_STS_MSK_REG3 0x4f
> +#define RK816_INT_STS_PLUG_IN BIT(0)
> +#define RK816_INT_STS_PLUG_OUT BIT(1)
> +#define RK816_INT_STS_CHG_OK BIT(2)
> +#define RK816_INT_STS_CHG_TE BIT(3)
> +#define RK816_INT_STS_CHG_TS BIT(4)
> +#define RK816_INT_STS_CHG_CVTLIM BIT(6)
> +#define RK816_INT_STS_DISCHG_ILIM BIT(7)
> +
> +/* charger, boost and OTG registers */
> +#define RK816_OTG_BUCK_LDO_CONFIG_REG 0x2a
> +#define RK816_CHRG_CONFIG_REG 0x2b
> +#define RK816_BOOST_ON_VESL_REG 0x54
> +#define RK816_BOOST_SLP_VSEL_REG 0x55
> +#define RK816_CHRG_BOOST_CONFIG_REG 0x9a
> +#define RK816_SUP_STS_REG 0xa0
> +#define RK816_USB_CTRL_REG 0xa1
> +#define RK816_CHRG_CTRL(x) (0xa3 + (x))
> +#define RK816_BAT_CTRL_REG 0xa6
> +#define RK816_BAT_HTS_TS_REG 0xa8
> +#define RK816_BAT_LTS_TS_REG 0xa9
> +
> +/* adc and fuel gauge registers */
> +#define RK816_TS_CTRL_REG 0xac
> +#define RK816_ADC_CTRL_REG 0xad
> +#define RK816_GGCON_REG 0xb0
> +#define RK816_GGSTS_REG 0xb1
> +#define RK816_ZERO_CUR_ADC_REGH 0xb2
> +#define RK816_ZERO_CUR_ADC_REGL 0xb3
> +#define RK816_GASCNT_CAL_REG(x) (0xb7 - (x))
> +#define RK816_GASCNT_REG(x) (0xbb - (x))
> +#define RK816_BAT_CUR_AVG_REGH 0xbc
> +#define RK816_BAT_CUR_AVG_REGL 0xbd
> +#define RK816_TS_ADC_REGH 0xbe
> +#define RK816_TS_ADC_REGL 0xbf
> +#define RK816_USB_ADC_REGH 0xc0
> +#define RK816_USB_ADC_REGL 0xc1
> +#define RK816_BAT_OCV_REGH 0xc2
> +#define RK816_BAT_OCV_REGL 0xc3
> +#define RK816_BAT_VOL_REGH 0xc4
> +#define RK816_BAT_VOL_REGL 0xc5
> +#define RK816_RELAX_ENTRY_THRES_REGH 0xc6
> +#define RK816_RELAX_ENTRY_THRES_REGL 0xc7
> +#define RK816_RELAX_EXIT_THRES_REGH 0xc8
> +#define RK816_RELAX_EXIT_THRES_REGL 0xc9
> +#define RK816_RELAX_VOL1_REGH 0xca
> +#define RK816_RELAX_VOL1_REGL 0xcb
> +#define RK816_RELAX_VOL2_REGH 0xcc
> +#define RK816_RELAX_VOL2_REGL 0xcd
> +#define RK816_RELAX_CUR1_REGH 0xce
> +#define RK816_RELAX_CUR1_REGL 0xcf
> +#define RK816_RELAX_CUR2_REGH 0xd0
> +#define RK816_RELAX_CUR2_REGL 0xd1
> +#define RK816_CAL_OFFSET_REGH 0xd2
> +#define RK816_CAL_OFFSET_REGL 0xd3
> +#define RK816_NON_ACT_TIMER_CNT_REG 0xd4
> +#define RK816_VCALIB0_REGH 0xd5
> +#define RK816_VCALIB0_REGL 0xd6
> +#define RK816_VCALIB1_REGH 0xd7
> +#define RK816_VCALIB1_REGL 0xd8
> +#define RK816_FCC_GASCNT_REG(x) (0xdc - (x))
> +#define RK816_IOFFSET_REGH 0xdd
> +#define RK816_IOFFSET_REGL 0xde
> +#define RK816_SLEEP_CON_SAMP_CUR_REG 0xdf
> +
> +/* general purpose data registers 0xe0 ~ 0xf2 */
> +#define RK816_DATA_REG(x) (0xe0 + (x))
> +
> /* RK818 */
> #define RK818_DCDC1 0
> #define RK818_LDO1 4
> @@ -791,6 +930,7 @@ enum rk806_dvs_mode {
> #define VOUT_LO_INT BIT(0)
> #define CLK32KOUT2_EN BIT(0)
>
> +#define TEMP105C 0x08
> #define TEMP115C 0x0c
> #define TEMP_HOTDIE_MSK 0x0c
> #define SLP_SD_MSK (0x3 << 2)
> @@ -1191,6 +1331,7 @@ enum {
> RK806_ID = 0x8060,
> RK808_ID = 0x0000,
> RK809_ID = 0x8090,
> + RK816_ID = 0x8160,
> RK817_ID = 0x8170,
> RK818_ID = 0x8180,
> };
> --
> 2.43.2
>
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v10 0/5] Add support for CS40L50
From: Lee Jones @ 2024-03-28 11:44 UTC (permalink / raw)
To: James Ogletree
Cc: dmitry.torokhov, robh+dt, krzysztof.kozlowski+dt, conor+dt,
broonie, jeff, patches, linux-sound, linux-input, devicetree
In-Reply-To: <20240320192956.2395731-1-jogletre@opensource.cirrus.com>
On Wed, 20 Mar 2024, James Ogletree wrote:
> Changes in v10:
> - Minor refactoring and logical improvements all around
> - Renamed and added supplies
>
> Changes in v9:
> - Fixed empty struct by utilizing cs_dsp's post_run callback
> - Style fixes in MFD driver
>
> Changes in v8:
> - set_sysclk() -> set_bclk_ratio()
> - Added ID table to codec driver
> - Style improvements
> - Fixed ordering of new write sequence operations
>
> Changes in v7:
> - Fixed sparse warning
> - Moved write sequences to private data structure
> - Logical and style improvements in write sequence interface
>
> Changes in v6:
> - Updated write sequencer interface to be control-name based
> - Fixed a race condition and non-handling of repeats in playback callback
> - Stylistic and logical improvements all around
>
> Changes in v5:
> - Added a codec sub-device to support I2S streaming
> - Moved write sequencer code from cirrus_haptics to cs_dsp
> - Reverted cirrus_haptics library; future Cirrus input
> drivers will export and utilize cs40l50_vibra functions
> - Added more comments
> - Many small stylistic and logical improvements
>
> Changes in v4:
> - Moved from Input to MFD
> - Moved common Cirrus haptic functions to a library
> - Incorporated runtime PM framework
> - Many style improvements
>
> Changes in v3:
> - YAML formatting corrections
> - Fixed typo in MAINTAINERS
> - Used generic node name "haptic-driver"
> - Fixed probe error code paths
> - Switched to "sizeof(*)"
> - Removed tree reference in MAINTAINERS
>
> Changes in v2:
> - Fixed checkpatch warnings
>
> James Ogletree (5):
> firmware: cs_dsp: Add write sequence interface
> dt-bindings: input: cirrus,cs40l50: Add initial DT binding
> mfd: cs40l50: Add support for CS40L50 core driver
> Input: cs40l50 - Add support for the CS40L50 haptic driver
> ASoC: cs40l50: Support I2S streaming to CS40L50
>
> .../bindings/input/cirrus,cs40l50.yaml | 68 +++
> MAINTAINERS | 12 +
> drivers/firmware/cirrus/cs_dsp.c | 278 +++++++++
> drivers/input/misc/Kconfig | 10 +
> drivers/input/misc/Makefile | 1 +
> drivers/input/misc/cs40l50-vibra.c | 577 ++++++++++++++++++
> drivers/mfd/Kconfig | 30 +
> drivers/mfd/Makefile | 4 +
> drivers/mfd/cs40l50-core.c | 570 +++++++++++++++++
> drivers/mfd/cs40l50-i2c.c | 68 +++
> drivers/mfd/cs40l50-spi.c | 68 +++
> include/linux/firmware/cirrus/cs_dsp.h | 27 +
> include/linux/mfd/cs40l50.h | 137 +++++
> sound/soc/codecs/Kconfig | 11 +
> sound/soc/codecs/Makefile | 2 +
> sound/soc/codecs/cs40l50-codec.c | 308 ++++++++++
> 16 files changed, 2171 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/input/cirrus,cs40l50.yaml
> create mode 100644 drivers/input/misc/cs40l50-vibra.c
> create mode 100644 drivers/mfd/cs40l50-core.c
> create mode 100644 drivers/mfd/cs40l50-i2c.c
> create mode 100644 drivers/mfd/cs40l50-spi.c
> create mode 100644 include/linux/mfd/cs40l50.h
> create mode 100644 sound/soc/codecs/cs40l50-codec.c
MFD part looks okay.
I need Acks from all of the other maintainers before I can process the set.
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v4 03/11] mfd: tps6594: add regmap config in match data
From: Lee Jones @ 2024-03-28 11:37 UTC (permalink / raw)
To: Bhargav Raviprakash
Cc: linux-kernel, m.nirmaladevi, robh+dt, krzysztof.kozlowski+dt,
conor+dt, jpanis, devicetree, arnd, gregkh, lgirdwood, broonie,
linus.walleij, linux-gpio, linux-arm-kernel, nm, vigneshr, kristo,
eblanc
In-Reply-To: <20240320102559.464981-4-bhargav.r@ltts.com>
On Wed, 20 Mar 2024, Bhargav Raviprakash wrote:
> Introduces a new struct tps6594_match_data. This struct holds fields for
> chip id and regmap config. Using this struct in of_device_id data field.
> This helps in adding support for TPS65224 PMIC.
>
> Signed-off-by: Bhargav Raviprakash <bhargav.r@ltts.com>
> Acked-by: Julien Panis <jpanis@baylibre.com>
> ---
> drivers/mfd/tps6594-i2c.c | 24 ++++++++++++++++--------
> drivers/mfd/tps6594-spi.c | 24 ++++++++++++++++--------
> include/linux/mfd/tps6594.h | 11 +++++++++++
> 3 files changed, 43 insertions(+), 16 deletions(-)
Mostly fine, just a couple of nits.
Firstly the subject lines for the entire set are inconsistent.
Please use the style set by the subsystem:
`git log --oneline -- <subsystem>` is your friend.
> diff --git a/drivers/mfd/tps6594-i2c.c b/drivers/mfd/tps6594-i2c.c
> index c125b474b..9e2ed48b7 100644
> --- a/drivers/mfd/tps6594-i2c.c
> +++ b/drivers/mfd/tps6594-i2c.c
> @@ -192,10 +192,16 @@ static const struct regmap_config tps6594_i2c_regmap_config = {
> .write = tps6594_i2c_write,
> };
>
> +static const struct tps6594_match_data match_data[] = {
> + [TPS6594] = {TPS6594, &tps6594_i2c_regmap_config},
> + [TPS6593] = {TPS6593, &tps6594_i2c_regmap_config},
> + [LP8764] = {LP8764, &tps6594_i2c_regmap_config},
Spaces after the '{' and before the '}' please.
> +};
> +
> static const struct of_device_id tps6594_i2c_of_match_table[] = {
> - { .compatible = "ti,tps6594-q1", .data = (void *)TPS6594, },
> - { .compatible = "ti,tps6593-q1", .data = (void *)TPS6593, },
> - { .compatible = "ti,lp8764-q1", .data = (void *)LP8764, },
> + { .compatible = "ti,tps6594-q1", .data = &match_data[TPS6594], },
> + { .compatible = "ti,tps6593-q1", .data = &match_data[TPS6593], },
> + { .compatible = "ti,lp8764-q1", .data = &match_data[LP8764], },
> {}
> };
> MODULE_DEVICE_TABLE(of, tps6594_i2c_of_match_table);
> @@ -205,6 +211,7 @@ static int tps6594_i2c_probe(struct i2c_client *client)
> struct device *dev = &client->dev;
> struct tps6594 *tps;
> const struct of_device_id *match;
> + const struct tps6594_match_data *mdata;
>
> tps = devm_kzalloc(dev, sizeof(*tps), GFP_KERNEL);
> if (!tps)
> @@ -216,14 +223,15 @@ static int tps6594_i2c_probe(struct i2c_client *client)
> tps->reg = client->addr;
> tps->irq = client->irq;
>
> - tps->regmap = devm_regmap_init(dev, NULL, client, &tps6594_i2c_regmap_config);
> - if (IS_ERR(tps->regmap))
> - return dev_err_probe(dev, PTR_ERR(tps->regmap), "Failed to init regmap\n");
> -
> match = of_match_device(tps6594_i2c_of_match_table, dev);
> if (!match)
> return dev_err_probe(dev, -EINVAL, "Failed to find matching chip ID\n");
> - tps->chip_id = (unsigned long)match->data;
> + mdata = (struct tps6594_match_data *)match->data;
What happens when you drop this case?
I was under the impression this was not required when casting from (void *)
> + tps->chip_id = mdata->chip_id;
> +
> + tps->regmap = devm_regmap_init(dev, NULL, client, mdata->config);
> + if (IS_ERR(tps->regmap))
> + return dev_err_probe(dev, PTR_ERR(tps->regmap), "Failed to init regmap\n");
"initialise"
>
> crc8_populate_msb(tps6594_i2c_crc_table, TPS6594_CRC8_POLYNOMIAL);
>
> diff --git a/drivers/mfd/tps6594-spi.c b/drivers/mfd/tps6594-spi.c
> index 5afb1736f..82a1c02e3 100644
> --- a/drivers/mfd/tps6594-spi.c
> +++ b/drivers/mfd/tps6594-spi.c
> @@ -77,10 +77,16 @@ static const struct regmap_config tps6594_spi_regmap_config = {
> .use_single_write = true,
> };
>
> +static const struct tps6594_match_data match_data[] = {
> + [TPS6594] = {TPS6594, &tps6594_spi_regmap_config},
> + [TPS6593] = {TPS6593, &tps6594_spi_regmap_config},
> + [LP8764] = {LP8764, &tps6594_spi_regmap_config},
As above.
> +};
> +
> static const struct of_device_id tps6594_spi_of_match_table[] = {
> - { .compatible = "ti,tps6594-q1", .data = (void *)TPS6594, },
> - { .compatible = "ti,tps6593-q1", .data = (void *)TPS6593, },
> - { .compatible = "ti,lp8764-q1", .data = (void *)LP8764, },
> + { .compatible = "ti,tps6594-q1", .data = &match_data[TPS6594], },
> + { .compatible = "ti,tps6593-q1", .data = &match_data[TPS6593], },
> + { .compatible = "ti,lp8764-q1", .data = &match_data[LP8764], },
> {}
> };
> MODULE_DEVICE_TABLE(of, tps6594_spi_of_match_table);
> @@ -90,6 +96,7 @@ static int tps6594_spi_probe(struct spi_device *spi)
> struct device *dev = &spi->dev;
> struct tps6594 *tps;
> const struct of_device_id *match;
> + const struct tps6594_match_data *mdata;
>
> tps = devm_kzalloc(dev, sizeof(*tps), GFP_KERNEL);
> if (!tps)
> @@ -101,14 +108,15 @@ static int tps6594_spi_probe(struct spi_device *spi)
> tps->reg = spi_get_chipselect(spi, 0);
> tps->irq = spi->irq;
>
> - tps->regmap = devm_regmap_init(dev, NULL, spi, &tps6594_spi_regmap_config);
> - if (IS_ERR(tps->regmap))
> - return dev_err_probe(dev, PTR_ERR(tps->regmap), "Failed to init regmap\n");
> -
> match = of_match_device(tps6594_spi_of_match_table, dev);
> if (!match)
> return dev_err_probe(dev, -EINVAL, "Failed to find matching chip ID\n");
> - tps->chip_id = (unsigned long)match->data;
> + mdata = (struct tps6594_match_data *)match->data;
> + tps->chip_id = mdata->chip_id;
> +
> + tps->regmap = devm_regmap_init(dev, NULL, spi, mdata->config);
> + if (IS_ERR(tps->regmap))
> + return dev_err_probe(dev, PTR_ERR(tps->regmap), "Failed to init regmap\n");
>
> crc8_populate_msb(tps6594_spi_crc_table, TPS6594_CRC8_POLYNOMIAL);
>
> diff --git a/include/linux/mfd/tps6594.h b/include/linux/mfd/tps6594.h
> index 16543fd4d..d781e0fe3 100644
> --- a/include/linux/mfd/tps6594.h
> +++ b/include/linux/mfd/tps6594.h
> @@ -1337,6 +1337,17 @@ struct tps6594 {
> struct regmap_irq_chip_data *irq_data;
> };
>
> +/**
> + * struct tps6594_match_data - of match data of PMIC
> + *
> + * @chip_id: chip ID of PMIC
> + * @config: regmap config of PMIC
> + */
> +struct tps6594_match_data {
> + unsigned long chip_id;
> + const struct regmap_config *config;
> +};
> +
> extern const struct regmap_access_table tps6594_volatile_table;
> extern const struct regmap_access_table tps65224_volatile_table;
>
> --
> 2.25.1
>
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v2 3/4] arm64: dts: exynos: gs101: join lines close to 80 chars
From: Peter Griffin @ 2024-03-28 11:34 UTC (permalink / raw)
To: Tudor Ambarus
Cc: robh+dt, krzysztof.kozlowski+dt, conor+dt, alim.akhtar,
linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel,
andre.draszik, willmcvicker, kernel-team
In-Reply-To: <20240326103620.298298-4-tudor.ambarus@linaro.org>
Hi Tudor,
On Tue, 26 Mar 2024 at 10:36, Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
> These lines fit 81 characters, which is pretty close to 80.
> Join the lines.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> ---
Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
> arch/arm64/boot/dts/exynos/google/gs101.dtsi | 12 ++++--------
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> index cfb3ddc7f885..690deca37e4f 100644
> --- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> +++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> @@ -374,8 +374,7 @@ pinctrl_peric0: pinctrl@10840000 {
> };
>
> usi8: usi@109700c0 {
> - compatible = "google,gs101-usi",
> - "samsung,exynos850-usi";
> + compatible = "google,gs101-usi", "samsung,exynos850-usi";
> reg = <0x109700c0 0x20>;
> ranges;
> #address-cells = <1>;
> @@ -403,8 +402,7 @@ hsi2c_8: i2c@10970000 {
> };
>
> usi_uart: usi@10a000c0 {
> - compatible = "google,gs101-usi",
> - "samsung,exynos850-usi";
> + compatible = "google,gs101-usi", "samsung,exynos850-usi";
> reg = <0x10a000c0 0x20>;
> ranges;
> #address-cells = <1>;
> @@ -419,8 +417,7 @@ usi_uart: usi@10a000c0 {
> serial_0: serial@10a00000 {
> compatible = "google,gs101-uart";
> reg = <0x10a00000 0xc0>;
> - interrupts = <GIC_SPI 634
> - IRQ_TYPE_LEVEL_HIGH 0>;
> + interrupts = <GIC_SPI 634 IRQ_TYPE_LEVEL_HIGH 0>;
> clocks = <&cmu_peric0 CLK_GOUT_PERIC0_PERIC0_TOP1_PCLK_0>,
> <&cmu_peric0 CLK_GOUT_PERIC0_PERIC0_TOP1_IPCLK_0>;
> clock-names = "uart", "clk_uart_baud0";
> @@ -454,8 +451,7 @@ pinctrl_peric1: pinctrl@10c40000 {
> };
>
> usi12: usi@10d500c0 {
> - compatible = "google,gs101-usi",
> - "samsung,exynos850-usi";
> + compatible = "google,gs101-usi", "samsung,exynos850-usi";
> reg = <0x10d500c0 0x20>;
> ranges;
> #address-cells = <1>;
> --
> 2.44.0.396.g6e790dbe36-goog
>
^ permalink raw reply
* Re: [PATCH v2 4/4] dt-bindings: aspeed: Add eSPI controller
From: Manojkiran Eda @ 2024-03-28 11:33 UTC (permalink / raw)
To: Krzysztof Kozlowski, patrick.rudolph, chiawei_wang, ryan_chen,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
linux-mtd
Cc: robh+dt, krzysztof.kozlowski+dt, conor+dt, joel, andrew,
miquel.raynal, richard, vigneshr, jk, openbmc, broonie, linux-spi
In-Reply-To: <f2a487c4-eba3-4a78-9a14-67c8754c8b61@linaro.org>
On 20/03/24 8:14 pm, Krzysztof Kozlowski wrote:
> On 20/03/2024 10:59, Manojkiran Eda wrote:
>>
>> On 19/03/24 3:26 pm, Krzysztof Kozlowski wrote:
>>> On 19/03/2024 10:34, Manojkiran Eda wrote:
>>>> This commit adds the device tree bindings for aspeed eSPI
>>>> controller.
>>>>
>>>> Although aspeed eSPI hardware supports 4 different channels,
>>>> this commit only adds the support for flash channel, the
>>>> bindings for other channels could be upstreamed when the driver
>>>> support for those are added.
>>>>
>>>> Signed-off-by: Manojkiran Eda<manojkiran.eda@gmail.com>
>>>> ---
>>>> .../bindings/soc/aspeed/aspeed,espi.yaml | 94 +++++++++++++++++++
>>>> 1 file changed, 94 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/soc/aspeed/aspeed,espi.yaml
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/soc/aspeed/aspeed,espi.yaml b/Documentation/devicetree/bindings/soc/aspeed/aspeed,espi.yaml
>>>> new file mode 100644
>>>> index 000000000000..3d3ad528e3b3
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/soc/aspeed/aspeed,espi.yaml
>>> Why Rob's comments got ignored?
>>>
>>> This is not a soc component.
>> I did not mean to ignore, i have few reasons listed below that provides
>> information on why i felt this belongs into soc.
>
> soc is dumping ground of things which are purely SoC specific, not
> covered by existing hardware structure in bindings. Maybe indeed this
> does not have any other place, but did you actually look?
>
Yes, i did look at existing hardware bindings, and cannot seem to find
out any other suitable place. I can definitely look again.
> Anyway, please CC SPI maintainers on future submission.
Sure, will add them.
>
>>>
>>>> @@ -0,0 +1,94 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>> +# # Copyright (c) 2024 IBM Corporation.
>>>> +# # Copyright (c) 2021 Aspeed Technology Inc.
>>>> +%YAML 1.2
>>>> +---
>>>> +$id:http://devicetree.org/schemas/soc/aspeed/aspeed,espi.yaml#
>>>> +$schema:http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: Aspeed eSPI Controller
>>>> +
>>>> +maintainers:
>>>> + - Manojkiran Eda<manojkiran.eda@gmail.com>
>>>> + - Patrick Rudolph<patrick.rudolph@9elements.com>
>>>> + - Chia-Wei Wang<chiawei_wang@aspeedtech.com>
>>>> + - Ryan Chen<ryan_chen@aspeedtech.com>
>>>> +
>>>> +description:
>>>> + Aspeed eSPI controller implements a device side eSPI endpoint device
>>>> + supporting the flash channel.
>>> Explain what is eSPI.
>> eSPI is a serial bus interface for client and server platforms that is
>
> Explain in description of the hardware.
Sure, i will add this description in the binding document in the future
submission.
>
>> based on SPI, using the same master and slave topology but operates
>> with a different protocol to meet new requirements. For instance, eSPI
>> uses I/O, or input/output, communication, instead of MOSI/MISO used in
>> SPI. It also includes a transaction layer on top of the SPI protocol,
>> defining packets such as command and response packets that allow both
>> the master and slave to initiate alert and reset signals. eSPI supports
>> communication between Embedded Controller (EC), Baseboard Management
>> Controller (BMC), Super-I/O (SIO) and Port-80 debug cards. I could add
>> this to the commit message as well in the next patchset.
>>>
>>>> +
>>>> +properties:
>>>> + compatible:
>>>> + items:
>>>> + - enum:
>>>> + - aspeed,ast2500-espi
>>>> + - aspeed,ast2600-espi
>>>> + - const: simple-mfd
>>>
>>> That's not simple-mfd. You have driver for this. Drop.
>>>
>>>> + - const: syscon
>>> That's not syscon. Why do you have ranges then? Where is any explanation
>>> of hardware which would justify such combination?
>>>
>>>> +
>>>> + reg:
>>>> + maxItems: 1
>>>> +
>>>> + "#address-cells":
>>>> + const: 1
>>>> +
>>>> + "#size-cells":
>>>> + const: 1
>>>> +
>>>> + ranges: true
>>>> +
>>>> +patternProperties:
>>>> + "^espi-ctrl@[0-9a-f]+$":
>>>> + type: object
>>>> +
>>>> + description: Controls the flash channel of eSPI hardware
>>> That explains nothing. Unless you wanted to use here MTD bindings.
>>>
>>> This binding did not improve much. I don't understand why this is not
>>> SPI (nothing in commit msg, nothing in description), what is eSPI,
>>
>> eSPI uses Peripheral, Virtual Wire, Out of Band, and Flash Access
>> channels to communicate different sets of data.
>
> And what are these channels? What does it mean a "channel"? Is it just
> how you organize transfers and classes of devices? Or some sort of
> addressable instance on the bus?
>
Yes, an espi channel provides a means to allow multiple independent
flows of traffic to share the same physical bus. Each of the channels
has its own dedicated resources such as queue and flow control.
> The channels feel like some sort of software or logical concept, not
> physical. Physical would be endpoint with peripheral. Or flash memory.
A channel is a logical communication pathway or interface between the
chipset and peripheral devices. The concept of channels in the ESPI
protocol helps organize and manage different types of communication
between the chipset and peripherals. Each channel may have its own set
of protocols, data transfer rates, and supported features, tailored to
the requirements of the devices it serves.
> How do they fit here?
I am not sure I understand, can you please elaborate ?
>>
>> * The *Peripheral* Channel is used for communication between eSPI host
>> bridge located on the master side and eSPI endpoints located on the
>> slave side. LPC Host and LPC Peripherals are an example of eSPI host
>> bridge and eSPI endpoints respectively.
>> * *Virtual Wire* Channel: The Virtual Wire channel is used to
>> communicate the state of sideband pins or GPIO tunneled through eSPI
>> as in-band messages. Serial IRQ interrupts are communicated through
>> this channel as in-band messages.
>> * *OOB* Channel: The SMBus packets are tunneled through eSPI as
>> Out-Of-Band (OOB) messages. The whole SMBus packet is embedded
>> inside the eSPI OOB message as data.
>> * *Flash Access* Channel: The Flash Access channel provides a path
>> allowing the flash components to be shared run-time between chipset
>> and the eSPI slaves that require flash accesses such as EC (Embedded
>> Controller) and BMC.
>
> Please make binding complete, so define all of the channels.
I would like to inquire about the rationale behind this request. Based
on previous feedback received from the upstream efforts
[https://lore.kernel.org/openbmc/HK0PR06MB37798462D17443C697433D7191D09@HK0PR06MB3779.apcprd06.prod.outlook.com/],
suggestions were made to model the flash channel by utilizing the mtd
subsystem, the virtual wire channel by utilizing the GPIO subsystem, and
to consider the OOB channel as a type of i2c device, thereby allowing it
to be utilized by the existing in-kernel MCTP subsystem, among others.
My intention was to prioritize upstreaming the flash channel binding,
along with its driver code, before proceeding to address other channels.
I am curious to understand if it is a strict requirement to have the
complete binding upstreamed before addressing the device drivers code.
>
>>
>> Although , eSPI reuses the timing and electrical specification of Serial
>> Peripheral Interface (SPI) but it runs an entirely different protocol to
>> meet a set of different requirements. Which is why i felt probably
>> placing this in soc was a better choice rather than spi. Do you think
>> otherwise ?
>
> soc is dumping ground for things do not fit other places. Are there any
> other buses / IP blocks similar to this one?
>
>
> Best regards,
> Krzysztof
>
Thanks,
Manoj
^ permalink raw reply
* Re: [PATCH 00/12] Use clksel for more clocks for dra7
From: Tony Lindgren @ 2024-03-28 11:31 UTC (permalink / raw)
To: linux-omap; +Cc: Benoît Cousson, devicetree
In-Reply-To: <20240327073856.21517-1-tony@atomide.com>
* Tony Lindgren <tony@atomide.com> [240327 09:39]:
> The DPLL output clocks are problematic at this point as the
> clock driver makes assumptions based on no reg property in
> _register_dpll_x2() for the ti,omap4-dpll-x2-clock. After
> the driver issues are solved, the DPLL output related clocks
> can also use the clksel binding.
Actually the driver needs changes only for clocks where there's no
reg entry. For the clocks with a reg entry like dpll_per m2 outputs,
the following seems to work based on light testing.
Regards,
Tony
8< -----------------
diff --git a/arch/arm/boot/dts/ti/omap/dra7xx-clocks.dtsi b/arch/arm/boot/dts/ti/omap/dra7xx-clocks.dtsi
--- a/arch/arm/boot/dts/ti/omap/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/ti/omap/dra7xx-clocks.dtsi
@@ -1425,6 +1425,7 @@ dpll_per_byp_mux: clock@23 {
};
};
+ /* CM_CLKSEL_DPLL_PER */
dpll_per_ck: clock@140 {
#clock-cells = <0>;
compatible = "ti,omap4-dpll-clock";
@@ -1433,16 +1434,43 @@ dpll_per_ck: clock@140 {
reg = <0x0140>, <0x0144>, <0x014c>, <0x0148>;
};
- dpll_per_m2_ck: clock-dpll-per-m2-8@150 {
- #clock-cells = <0>;
- compatible = "ti,divider-clock";
- clock-output-names = "dpll_per_m2_ck";
- clocks = <&dpll_per_ck>;
- ti,max-div = <31>;
- ti,autoidle-shift = <8>;
- reg = <0x0150>;
- ti,index-starts-at-one;
- ti,invert-autoidle-bit;
+ /* CM_DIV_M2_DPLL_PER */
+ clock@150 {
+ compatible = "ti,clksel";
+ reg = <0x150>;
+ #clock-cells = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dpll_per_m2x2_ck: clock@0 {
+ reg = <0>;
+ #clock-cells = <0>;
+ compatible = "ti,divider-clock";
+ clock-output-names = "dpll_per_m2x2_ck";
+ clocks = <&dpll_per_x2_ck>;
+ ti,max-div = <31>;
+ ti,autoidle-shift = <8>;
+ ti,index-starts-at-one;
+ ti,invert-autoidle-bit;
+ };
+
+ dpll_per_m2_ck: clock@8 {
+ compatible = "fixed-factor-clock";
+ reg = <8>;
+ #clock-cells = <0>;
+ clocks = <&dpll_per_m2x2_ck>;
+ clock-mult = <1>;
+ clock-div = <2>;
+ clock-output-names = "dpll_per_m2_ck";
+ };
+
+ dpll_per_x2_ck: clock@10 {
+ reg = <10>;
+ #clock-cells = <0>;
+ compatible = "ti,omap4-dpll-x2-clock";
+ clock-output-names = "dpll_per_x2_ck";
+ clocks = <&dpll_per_ck>;
+ };
};
func_96m_aon_dclk_div: clock-func-96m-aon-dclk-div {
@@ -1503,13 +1531,6 @@ dpll_pcie_ref_m2_ck: clock-dpll-pcie-ref-m2-8@210 {
ti,invert-autoidle-bit;
};
- dpll_per_x2_ck: clock-dpll-per-x2 {
- #clock-cells = <0>;
- compatible = "ti,omap4-dpll-x2-clock";
- clock-output-names = "dpll_per_x2_ck";
- clocks = <&dpll_per_ck>;
- };
-
dpll_per_h11x2_ck: clock-dpll-per-h11x2-8@158 {
#clock-cells = <0>;
compatible = "ti,divider-clock";
@@ -1558,18 +1579,6 @@ dpll_per_h14x2_ck: clock-dpll-per-h14x2-8@164 {
ti,invert-autoidle-bit;
};
- dpll_per_m2x2_ck: clock-dpll-per-m2x2-8@150 {
- #clock-cells = <0>;
- compatible = "ti,divider-clock";
- clock-output-names = "dpll_per_m2x2_ck";
- clocks = <&dpll_per_x2_ck>;
- ti,max-div = <31>;
- ti,autoidle-shift = <8>;
- reg = <0x0150>;
- ti,index-starts-at-one;
- ti,invert-autoidle-bit;
- };
-
dpll_usb_clkdcoldo: clock-dpll-usb-clkdcoldo {
#clock-cells = <0>;
compatible = "fixed-factor-clock";
--
2.44.0
^ permalink raw reply
* Re: [GIT PULL] Immutable branch between MFD and Regulator due for the v6.9 merge window:wq
From: Andre Przywara @ 2024-03-28 11:11 UTC (permalink / raw)
To: Lee Jones
Cc: Liam Girdwood, Mark Brown, Chen-Yu Tsai, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, devicetree, Samuel Holland,
Jernej Skrabec, Chris Morgan, linux-kernel, linux-sunxi,
Ryan Walklin
In-Reply-To: <20240328095631.GW13211@google.com>
On Thu, 28 Mar 2024 09:56:31 +0000
Lee Jones <lee@kernel.org> wrote:
Hi Lee,
many thanks for picking this up!
> Enjoy!
>
> The following changes since commit 4cece764965020c22cff7665b18a012006359095:
>
> Linux 6.9-rc1 (2024-03-24 14:10:05 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-regulator-v6.9
>
> for you to fetch changes up to d2ac3df75c3a995064cfac0171e082a30d8c4c66:
>
> regulator: axp20x: add support for the AXP717 (2024-03-28 09:51:03 +0000)
>
> ----------------------------------------------------------------
> Immutable branch between MFD and Regulator due for the v6.9 merge window
Did you mean v6.10 merge window? Or is there a plan to merge this into
6.9 still?
Also I found some issue with the LDOs' supply voltage: there are not
all the same, as described right now. Fix is quite easy, how do you
want to take this? As a follow up patch? And would this be squashed or
kept separate?
Or do you want we to send a new version? If yes, based on what branch?
Thanks,
Andre
>
> ----------------------------------------------------------------
> Andre Przywara (4):
> regulator: axp20x: fix typo-ed identifier
> dt-bindings: mfd: x-powers,axp152: Document AXP717
> mfd: axp20x: Add support for AXP717 PMIC
> regulator: axp20x: add support for the AXP717
>
> .../devicetree/bindings/mfd/x-powers,axp152.yaml | 2 +
> drivers/mfd/axp20x-i2c.c | 2 +
> drivers/mfd/axp20x-rsb.c | 1 +
> drivers/mfd/axp20x.c | 90 ++++++++++++++++++++
> drivers/regulator/axp20x-regulator.c | 94 +++++++++++++++++++--
> include/linux/mfd/axp20x.h | 98 ++++++++++++++++++++--
> 6 files changed, 277 insertions(+), 10 deletions(-)
>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: crypto: ice: Document sc7280 inline crypto engine
From: Herbert Xu @ 2024-03-28 10:54 UTC (permalink / raw)
To: Luca Weiss
Cc: Bjorn Andersson, Konrad Dybcio, David S. Miller, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, cros-qcom-dts-watchers,
~postmarketos/upstreaming, phone-devel, linux-arm-msm,
linux-crypto, devicetree, linux-kernel
In-Reply-To: <20240313-sc7280-ice-v1-1-3fa089fb7a27@fairphone.com>
On Wed, Mar 13, 2024 at 01:53:14PM +0100, Luca Weiss wrote:
> Document the compatible used for the inline crypto engine found on
> SC7280.
>
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
> Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml | 1 +
> 1 file changed, 1 insertion(+)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v4 0/7] crypto: starfive: Add support for JH8100
From: Herbert Xu @ 2024-03-28 10:45 UTC (permalink / raw)
To: Jia Jie Ho
Cc: David S . Miller, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Eugeniy Paltsev, Vinod Koul, linux-crypto, devicetree,
linux-kernel, dmaengine
In-Reply-To: <20240305071006.2181158-1-jiajie.ho@starfivetech.com>
On Tue, Mar 05, 2024 at 03:09:59PM +0800, Jia Jie Ho wrote:
> This patch series add driver support for StarFive JH8100 SoC crypto
> engine. Patch 1 adds compatible string and update irq descriptions for
> JH8100 device. Subsequent patches update current driver implementations
> to support both 7110 and 8100 variants.
>
> v3->v4:
> - Updated interrupts descriptions for jh8100-crypto compatible. (Rob)
> - Added patch 3 to skip unneeded key freeing for RSA module.
>
> v2->v3:
> - Use of device data instead of #ifdef CONFIG_ for different device
> variants.
> - Updated dt bindings compatible and interrupts descriptions.
> - Added patch 4 to support hardware quirks for dw-axi-dmac driver.
>
> v1->v2:
> - Resolved build warnings reported by kernel test robot
> https://lore.kernel.org/oe-kbuild-all/202312170614.24rtwf9x-lkp@intel.com/
>
> Jia Jie Ho (7):
> dt-bindings: crypto: starfive: Add jh8100 support
> crypto: starfive: Update hash dma usage
> crypto: starfive: Skip unneeded key free
> crypto: starfive: Use dma for aes requests
> dmaengine: dw-axi-dmac: Support hardware quirks
> crypto: starfive: Add sm3 support for JH8100
> crypto: starfive: Add sm4 support for JH8100
>
> .../crypto/starfive,jh7110-crypto.yaml | 30 +-
> drivers/crypto/starfive/Kconfig | 30 +-
> drivers/crypto/starfive/Makefile | 5 +-
> drivers/crypto/starfive/jh7110-aes.c | 592 ++++++---
> drivers/crypto/starfive/jh7110-cryp.c | 77 +-
> drivers/crypto/starfive/jh7110-cryp.h | 114 +-
> drivers/crypto/starfive/jh7110-hash.c | 316 +++--
> drivers/crypto/starfive/jh7110-rsa.c | 3 +
> drivers/crypto/starfive/jh8100-sm3.c | 544 ++++++++
> drivers/crypto/starfive/jh8100-sm4.c | 1119 +++++++++++++++++
> .../dma/dw-axi-dmac/dw-axi-dmac-platform.c | 32 +-
> drivers/dma/dw-axi-dmac/dw-axi-dmac.h | 2 +
> include/linux/dma/dw_axi.h | 11 +
> 13 files changed, 2437 insertions(+), 438 deletions(-)
> create mode 100644 drivers/crypto/starfive/jh8100-sm3.c
> create mode 100644 drivers/crypto/starfive/jh8100-sm4.c
> create mode 100644 include/linux/dma/dw_axi.h
>
> --
> 2.34.1
Patches 1-4 applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH net-next v6 10/17] net: pse-pd: Add support for PSE PIs
From: Simon Horman @ 2024-03-28 10:40 UTC (permalink / raw)
To: Kory Maincent
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jonathan Corbet, Luis Chamberlain, Russ Weight,
Greg Kroah-Hartman, Rafael J. Wysocki, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Oleksij Rempel, Mark Brown,
Frank Rowand, Andrew Lunn, Heiner Kallweit, Russell King,
Thomas Petazzoni, netdev, linux-kernel, linux-doc, devicetree,
Dent Project
In-Reply-To: <20240328103322.GX403975@kernel.org>
On Thu, Mar 28, 2024 at 10:33:22AM +0000, Simon Horman wrote:
> On Tue, Mar 26, 2024 at 03:04:47PM +0100, Kory Maincent wrote:
> > From: Kory Maincent (Dent Project) <kory.maincent@bootlin.com>
...
> > diff --git a/include/linux/pse-pd/pse.h b/include/linux/pse-pd/pse.h
>
> ...
>
> > @@ -73,11 +103,11 @@ struct pse_control;
> > * @pse_control_head: head of internal list of requested PSE controls
> > * @dev: corresponding driver model device struct
> > * @of_pse_n_cells: number of cells in PSE line specifiers
> > - * @of_xlate: translation function to translate from specifier as found in the
> > - * device tree to id as given to the PSE control ops
> > * @nr_lines: number of PSE controls in this controller device
> > * @lock: Mutex for serialization access to the PSE controller
> > * @types: types of the PSE controller
> > + * @pi: table of PSE PIs described in this controller device
> > + * @of_legacy: flag set if the pse_pis devicetree node is not used
>
> nit: it looks line the documentation didn't keep up with the
> structure during development: @no_of_pse_pi should be
> documented instead of @of_legacy.
There seem to be some similar minor problems in
[PATCH net-next v6 13/17] net: pse-pd: Use regulator framework within PSE framework
./scripts/kernel-doc -none is your friend here.
>
> > */
> > struct pse_controller_dev {
> > const struct pse_controller_ops *ops;
> > @@ -86,11 +116,11 @@ struct pse_controller_dev {
> > struct list_head pse_control_head;
> > struct device *dev;
> > int of_pse_n_cells;
> > - int (*of_xlate)(struct pse_controller_dev *pcdev,
> > - const struct of_phandle_args *pse_spec);
> > unsigned int nr_lines;
> > struct mutex lock;
> > enum ethtool_pse_types types;
> > + struct pse_pi *pi;
> > + bool no_of_pse_pi;
> > };
>
> ...
>
^ permalink raw reply
* Re: [PATCH v4 10/11] pinctrl: pinctrl-tps6594: Add TPS65224 PMIC pinctrl and GPIO
From: Bhargav Raviprakash @ 2024-03-28 10:35 UTC (permalink / raw)
To: eblanc, jpanis
Cc: arnd, bhargav.r, broonie, conor+dt, devicetree, gregkh, kristo,
krzysztof.kozlowski+dt, lee, lgirdwood, linus.walleij,
linux-arm-kernel, linux-gpio, linux-kernel, m.nirmaladevi, nm,
robh+dt, vigneshr
In-Reply-To: <D00DSDGHFPLU.1MTQNFWP5DF0J@baylibre.com>
Hello,
On Fri, 22 Mar 2024 16:24:07 +0100, Esteban Blanc wrote:
> Hi Bhargav,
>
> LP8764 is not supported but the driver was wrongly instanciated on the
> MFD. For V5 could you:
> - Disable this driver for LD8764.
> - Make sure this driver correctly supports TPS6593
>
> Best Regards,
>
> --
> Esteban "Skallwar" Blanc
> BayLibre
Thanks!
We will make sure the driver properly supports TPS6593.
This issue will be fixed in v5.
Regards,
Bhargav
^ permalink raw reply
* Re: [PATCH net-next v6 10/17] net: pse-pd: Add support for PSE PIs
From: Simon Horman @ 2024-03-28 10:33 UTC (permalink / raw)
To: Kory Maincent
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jonathan Corbet, Luis Chamberlain, Russ Weight,
Greg Kroah-Hartman, Rafael J. Wysocki, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Oleksij Rempel, Mark Brown,
Frank Rowand, Andrew Lunn, Heiner Kallweit, Russell King,
Thomas Petazzoni, netdev, linux-kernel, linux-doc, devicetree,
Dent Project
In-Reply-To: <20240326-feature_poe-v6-10-c1011b6ea1cb@bootlin.com>
On Tue, Mar 26, 2024 at 03:04:47PM +0100, Kory Maincent wrote:
> From: Kory Maincent (Dent Project) <kory.maincent@bootlin.com>
>
> The Power Sourcing Equipment Power Interface (PSE PI) plays a pivotal role
> in the architecture of Power over Ethernet (PoE) systems. It is essentially
> a blueprint that outlines how one or multiple power sources are connected
> to the eight-pin modular jack, commonly known as the Ethernet RJ45 port.
> This connection scheme is crucial for enabling the delivery of power
> alongside data over Ethernet cables.
>
> This patch adds support for getting the PSE controller node through PSE PI
> device subnode.
>
> This supports adds a way to get the PSE PI id from the pse_pi devicetree
> subnode of a PSE controller node simply by reading the reg property.
>
> Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
Hi Kory,
Some minor documentation nits from my side.
> diff --git a/Documentation/networking/pse-pd/pse-pi.rst b/Documentation/networking/pse-pd/pse-pi.rst
...
> +Table 145\u20133\u2014PSE Pinout Alternatives
> +-----------------------------------
When running make htmldocs I see the following warning:
Table 145\u20133\u2014PSE Pinout Alternatives
And the header is rendered as:
Table 145u20133u2014PSE Pinout Alternatives
I'm assuming my version of Sphinx doesn't understand the use
of escape sequences for unicode characters here.
I have observed this with (I assume this is the relevant command):
$ sphinx-build --version
sphinx-build 7.2.6
$ sphinx-build --version
sphinx-build 6.2.1
...
> diff --git a/drivers/net/pse-pd/pse_core.c b/drivers/net/pse-pd/pse_core.c
...
> /**
> - * of_pse_zero_xlate - dummy function for controllers with one only control
> - * @pcdev: a pointer to the PSE controller device
> - * @pse_spec: PSE line specifier as found in the device tree
> - *
> - * This static translation function is used by default if of_xlate in
> - * :c:type:`pse_controller_dev` is not set. It is useful for all PSE
> - * controllers with #pse-cells = <0>.
> + * of_load_pse_pi_pairset - load PSE PI pairsets pinout and polarity
nit: of_load_pse_pi_pairsets
> + * @node: a pointer of the device node
> + * @pi: a pointer of the PSE PI to fill
> + * @npairsets: the number of pairsets (1 or 2) used by the PI
> */
> -static int of_pse_zero_xlate(struct pse_controller_dev *pcdev,
> - const struct of_phandle_args *pse_spec)
> +static int of_load_pse_pi_pairsets(struct device_node *node,
> + struct pse_pi *pi,
> + int npairsets)
...
> diff --git a/include/linux/pse-pd/pse.h b/include/linux/pse-pd/pse.h
...
> @@ -73,11 +103,11 @@ struct pse_control;
> * @pse_control_head: head of internal list of requested PSE controls
> * @dev: corresponding driver model device struct
> * @of_pse_n_cells: number of cells in PSE line specifiers
> - * @of_xlate: translation function to translate from specifier as found in the
> - * device tree to id as given to the PSE control ops
> * @nr_lines: number of PSE controls in this controller device
> * @lock: Mutex for serialization access to the PSE controller
> * @types: types of the PSE controller
> + * @pi: table of PSE PIs described in this controller device
> + * @of_legacy: flag set if the pse_pis devicetree node is not used
nit: it looks line the documentation didn't keep up with the
structure during development: @no_of_pse_pi should be
documented instead of @of_legacy.
> */
> struct pse_controller_dev {
> const struct pse_controller_ops *ops;
> @@ -86,11 +116,11 @@ struct pse_controller_dev {
> struct list_head pse_control_head;
> struct device *dev;
> int of_pse_n_cells;
> - int (*of_xlate)(struct pse_controller_dev *pcdev,
> - const struct of_phandle_args *pse_spec);
> unsigned int nr_lines;
> struct mutex lock;
> enum ethtool_pse_types types;
> + struct pse_pi *pi;
> + bool no_of_pse_pi;
> };
...
^ permalink raw reply
* Re: [PATCH v4 10/11] pinctrl: pinctrl-tps6594: Add TPS65224 PMIC pinctrl and GPIO
From: Bhargav Raviprakash @ 2024-03-28 10:27 UTC (permalink / raw)
To: eblanc
Cc: arnd, bhargav.r, broonie, conor+dt, devicetree, gregkh, jpanis,
kristo, krzysztof.kozlowski+dt, lee, lgirdwood, linus.walleij,
linux-arm-kernel, linux-gpio, linux-kernel, m.nirmaladevi, nm,
robh+dt, vigneshr
In-Reply-To: <D00EM8TTYGXL.3MMIBWJT03M5R@baylibre.com>
Hi,
On Fri, 22 Mar 2024 17:03:08 +0100, Esteban Blanc wrote:
> On Wed Mar 20, 2024 at 11:25 AM CET, Bhargav Raviprakash wrote:
> > From: Nirmala Devi Mal Nadar <m.nirmaladevi@ltts.com>
> >
> > Add support for TPS65224 pinctrl and GPIOs to TPS6594 driver as they have
> > significant functional overlap.
> > TPS65224 PMIC has 6 GPIOS which can be configured as GPIO or other
> > dedicated device functions.
> >
> > Signed-off-by: Nirmala Devi Mal Nadar <m.nirmaladevi@ltts.com>
> > Signed-off-by: Bhargav Raviprakash <bhargav.r@ltts.com>
> > Acked-by: Linus Walleij <linus.walleij@linaro.org>
> > ---
> > drivers/pinctrl/pinctrl-tps6594.c | 258 +++++++++++++++++++++++++-----
> > 1 file changed, 215 insertions(+), 43 deletions(-)
> >
> > diff --git a/drivers/pinctrl/pinctrl-tps6594.c b/drivers/pinctrl/pinctrl-tps6594.c
> > index 66985e54b..db0f5d2a8 100644
> > --- a/drivers/pinctrl/pinctrl-tps6594.c
> > +++ b/drivers/pinctrl/pinctrl-tps6594.c
> > @@ -320,8 +451,18 @@ static int tps6594_pinctrl_probe(struct platform_device *pdev)
> > return -ENOMEM;
> > pctrl_desc->name = dev_name(dev);
> > pctrl_desc->owner = THIS_MODULE;
> > - pctrl_desc->pins = tps6594_pins;
> > - pctrl_desc->npins = ARRAY_SIZE(tps6594_pins);
> > + switch (tps->chip_id) {
> > + case TPS65224:
> > + pctrl_desc->pins = tps65224_pins;
> > + pctrl_desc->npins = ARRAY_SIZE(tps65224_pins);
> > + break;
> > + case TPS6594:
> > + pctrl_desc->pins = tps6594_pins;
> > + pctrl_desc->npins = ARRAY_SIZE(tps6594_pins);
> > + break;
> > + default:
> > + break;
> > + }
> > pctrl_desc->pctlops = &tps6594_pctrl_ops;
> > pctrl_desc->pmxops = &tps6594_pmx_ops;
>
> See below.
>
> > @@ -329,8 +470,28 @@ static int tps6594_pinctrl_probe(struct platform_device *pdev)
> > if (!pinctrl)
> > return -ENOMEM;
> > pinctrl->tps = dev_get_drvdata(dev->parent);
> > - pinctrl->funcs = pinctrl_functions;
> > - pinctrl->pins = tps6594_pins;
> > + switch (pinctrl->tps->chip_id) {
>
> You could use tps->chip_id like in the previous switch.
>
> > + case TPS65224:
> > + pinctrl->funcs = tps65224_pinctrl_functions;
> > + pinctrl->func_cnt = ARRAY_SIZE(tps65224_pinctrl_functions);
> > + pinctrl->pins = tps65224_pins;
> > + pinctrl->num_pins = ARRAY_SIZE(tps65224_pins);
> > + pinctrl->mux_sel_mask = TPS65224_MASK_GPIO_SEL;
> > + pinctrl->remap = tps65224_muxval_remap;
> > + pinctrl->remap_cnt = ARRAY_SIZE(tps65224_muxval_remap);
> > + break;
> > + case TPS6594:
> > + pinctrl->funcs = pinctrl_functions;
>
> This should be tps6594_pinctrl_functions
>
> > + pinctrl->func_cnt = ARRAY_SIZE(pinctrl_functions);
> > + pinctrl->pins = tps6594_pins;
> > + pinctrl->num_pins = ARRAY_SIZE(tps6594_pins);
> > + pinctrl->mux_sel_mask = TPS6594_MASK_GPIO_SEL;
> > + pinctrl->remap = tps6594_muxval_remap;
> > + pinctrl->remap_cnt = ARRAY_SIZE(tps6594_muxval_remap);
> > + break;
> > + default:
> > + break;
> > + }
>
> See blow.
>
> > pinctrl->pctl_dev = devm_pinctrl_register(dev, pctrl_desc, pinctrl);
> > if (IS_ERR(pinctrl->pctl_dev))
> > return dev_err_probe(dev, PTR_ERR(pinctrl->pctl_dev),
> > @@ -338,8 +499,18 @@ static int tps6594_pinctrl_probe(struct platform_device *pdev)
> >
> > config.parent = tps->dev;
> > config.regmap = tps->regmap;
> > - config.ngpio = TPS6594_PINCTRL_PINS_NB;
> > - config.ngpio_per_reg = 8;
> > + switch (pinctrl->tps->chip_id) {
>
> Same here, use tps->chip_id
>
Sure, will do!
> > + case TPS65224:
> > + config.ngpio = ARRAY_SIZE(tps65224_gpio_func_group_names);
> > + config.ngpio_per_reg = TPS65224_NGPIO_PER_REG;
> > + break;
> > + case TPS6594:
> > + config.ngpio = ARRAY_SIZE(tps6594_gpio_func_group_names);
> > + config.ngpio_per_reg = TPS6594_NGPIO_PER_REG;
> > + break;
> > + default:
> > + break;
> > + }
> > config.reg_dat_base = TPS6594_REG_GPIO_IN_1;
> > config.reg_set_base = TPS6594_REG_GPIO_OUT_1;
> > config.reg_dir_out_base = TPS6594_REG_GPIOX_CONF(0);
>
> Regarding all the switch case, they should be use to set all the struct
> fields that are known at runtime only. For example, pinctrl->funcs, and
> pinctrl->func_cnt are known at compile time. You should create template
> structs, one for TPS6594 the other TPS65224, initialise the allocated
> struct with the template and then fill the remaining fields with the
> runtime values. Something like this:
>
> ```c
> struct test {
> int a;
> int *b;
> };
>
> static struct test template = {
> .a = 42,
> };
>
> int main(void) {
> struct test *test = malloc(sizeof(*test));
> *test = sample;
> test->b = NULL;
>
> return 0;
> }
> ```
>
> You could also try to reduce the number of switch case, there is no good
> reason to have 2 switch instead of one for pctrl_desc and pinctrl
> structs.
>
> Best regards,
>
> --
> Esteban "Skallwar" Blanc
> BayLibre
Thank you for bringing these issues to our attention.
We will follow the template struct way as suggested and also try to reduce the number of switch
cases. These changes will be available in the next version.
Regards,
Bhargav
^ permalink raw reply
* [PATCH 4/4] drm/panel: simple: Add Innolux G121XCE-L01 LVDS display support
From: Marek Vasut @ 2024-03-28 10:27 UTC (permalink / raw)
To: dri-devel
Cc: Marek Vasut, Conor Dooley, Daniel Vetter, David Airlie,
Jessica Zhang, Krzysztof Kozlowski, Maarten Lankhorst,
Maxime Ripard, Neil Armstrong, Rob Herring, Sam Ravnborg,
Thierry Reding, Thomas Zimmermann, devicetree
In-Reply-To: <20240328102746.17868-1-marex@denx.de>
G121XCE-L01 is a Color Active Matrix Liquid Crystal Display composed of
a TFT LCD panel, a driver circuit, and LED backlight system. The screen
format is intended to support the 4:3, 1024(H) x 768(V) screen and either
262k/16.7M colors (RGB 6-bits or 8-bits) with LED backlight driver circuit.
All input signals are LVDS interface compatible.
Documentation [1] and [2] indicate that G121X1-L03 and G121XCE-L01 are
effectively identical panels, use the former as RGB 6-bits variant and
add the later as RGB 8-bits variant.
[1] https://www.distec.de/fileadmin/pdf/produkte/TFT-Displays/Innolux/G121X1-L03_Datasheet.pdf
[2] https://www.distec.de/fileadmin/pdf/produkte/TFT-Displays/Innolux/G121XCE-L01_Datasheet.pdf
Signed-off-by: Marek Vasut <marex@denx.de>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: David Airlie <airlied@gmail.com>
Cc: Jessica Zhang <quic_jesszhan@quicinc.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Neil Armstrong <neil.armstrong@linaro.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/panel/panel-simple.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 737c78b3b8a23..5acc9f2941909 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2623,6 +2623,24 @@ static const struct panel_desc innolux_g121x1_l03 = {
.connector_type = DRM_MODE_CONNECTOR_LVDS,
};
+static const struct panel_desc innolux_g121xce_l01 = {
+ .timings = &innolux_g121x1_l03_timings,
+ .num_timings = 1,
+ .bpc = 8,
+ .size = {
+ .width = 246,
+ .height = 185,
+ },
+ .delay = {
+ .enable = 200,
+ .unprepare = 200,
+ .disable = 400,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH,
+ .connector_type = DRM_MODE_CONNECTOR_LVDS,
+};
+
static const struct display_timing innolux_g156hce_l01_timings = {
.pixelclock = { 120000000, 141860000, 150000000 },
.hactive = { 1920, 1920, 1920 },
@@ -4596,6 +4614,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "innolux,g121x1-l03",
.data = &innolux_g121x1_l03,
+ }, {
+ .compatible = "innolux,g121xce-l01",
+ .data = &innolux_g121xce_l01,
}, {
.compatible = "innolux,g156hce-l01",
.data = &innolux_g156hce_l01,
--
2.43.0
^ permalink raw reply related
* [PATCH 3/4] drm/panel: simple: Convert Innolux G121X1-L03 to display_timing
From: Marek Vasut @ 2024-03-28 10:27 UTC (permalink / raw)
To: dri-devel
Cc: Marek Vasut, Conor Dooley, Daniel Vetter, David Airlie,
Jessica Zhang, Krzysztof Kozlowski, Maarten Lankhorst,
Maxime Ripard, Neil Armstrong, Rob Herring, Sam Ravnborg,
Thierry Reding, Thomas Zimmermann, devicetree
In-Reply-To: <20240328102746.17868-1-marex@denx.de>
Use display_timing instead of drm_display_mode to define a range of
possible display timings supported by this panel. This makes the panel
support more flexible and improves compatibility. No functional change
is expected.
The settings are picked from documentation [1] section 6.1 INPUT SIGNAL
TIMING SPECIFICATIONS.
[1] https://www.distec.de/fileadmin/pdf/produkte/TFT-Displays/Innolux/G121X1-L03_Datasheet.pdf
Signed-off-by: Marek Vasut <marex@denx.de>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: David Airlie <airlied@gmail.com>
Cc: Jessica Zhang <quic_jesszhan@quicinc.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Neil Armstrong <neil.armstrong@linaro.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/panel/panel-simple.c | 26 +++++++++++++-------------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index d4c30a86d15d6..737c78b3b8a23 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2592,22 +2592,22 @@ static const struct panel_desc innolux_g121i1_l01 = {
.connector_type = DRM_MODE_CONNECTOR_LVDS,
};
-static const struct drm_display_mode innolux_g121x1_l03_mode = {
- .clock = 65000,
- .hdisplay = 1024,
- .hsync_start = 1024 + 0,
- .hsync_end = 1024 + 1,
- .htotal = 1024 + 0 + 1 + 320,
- .vdisplay = 768,
- .vsync_start = 768 + 38,
- .vsync_end = 768 + 38 + 1,
- .vtotal = 768 + 38 + 1 + 0,
- .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+static const struct display_timing innolux_g121x1_l03_timings = {
+ .pixelclock = { 57500000, 64900000, 74400000 },
+ .hactive = { 1024, 1024, 1024 },
+ .hfront_porch = { 90, 140, 190 },
+ .hback_porch = { 90, 140, 190 },
+ .hsync_len = { 36, 40, 60 },
+ .vactive = { 768, 768, 768 },
+ .vfront_porch = { 2, 15, 30 },
+ .vback_porch = { 2, 15, 30 },
+ .vsync_len = { 2, 8, 20 },
+ .flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW,
};
static const struct panel_desc innolux_g121x1_l03 = {
- .modes = &innolux_g121x1_l03_mode,
- .num_modes = 1,
+ .timings = &innolux_g121x1_l03_timings,
+ .num_timings = 1,
.bpc = 6,
.size = {
.width = 246,
--
2.43.0
^ permalink raw reply related
* [PATCH 1/4] dt-bindings: display: simple: Document support for Innolux G121XCE-L01
From: Marek Vasut @ 2024-03-28 10:27 UTC (permalink / raw)
To: dri-devel
Cc: Marek Vasut, Conor Dooley, Daniel Vetter, David Airlie,
Jessica Zhang, Krzysztof Kozlowski, Maarten Lankhorst,
Maxime Ripard, Neil Armstrong, Rob Herring, Sam Ravnborg,
Thierry Reding, Thomas Zimmermann, devicetree
Document support for Innolux CheMei 12" G121XCE-L01 XGA LVDS display.
G121XCE-L01 is a Color Active Matrix Liquid Crystal Display composed of
a TFT LCD panel, a driver circuit, and LED backlight system. The screen
format is intended to support the 4:3, 1024(H) x 768(V) screen and either
262k/16.7M colors (RGB 6-bits or 8-bits) with LED backlight driver circuit.
All input signals are LVDS interface compatible.
Documentation [1] and [2] indicate that G121X1-L03 and G121XCE-L01 are
effectively identical panels, use the former as RGB 6-bits variant and
document the later as RGB 8-bits variant.
[1] https://www.distec.de/fileadmin/pdf/produkte/TFT-Displays/Innolux/G121X1-L03_Datasheet.pdf
[2] https://www.distec.de/fileadmin/pdf/produkte/TFT-Displays/Innolux/G121XCE-L01_Datasheet.pdf
Signed-off-by: Marek Vasut <marex@denx.de>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: David Airlie <airlied@gmail.com>
Cc: Jessica Zhang <quic_jesszhan@quicinc.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Neil Armstrong <neil.armstrong@linaro.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
---
.../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index e0f6aa9a025c4..931d98836e121 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -190,6 +190,8 @@ properties:
- innolux,g121i1-l01
# Innolux Corporation 12.1" G121X1-L03 XGA (1024x768) TFT LCD panel
- innolux,g121x1-l03
+ # Innolux Corporation 12.1" G121XCE-L01 XGA (1024x768) TFT LCD panel
+ - innolux,g121xce-l01
# Innolux Corporation 11.6" WXGA (1366x768) TFT LCD panel
- innolux,n116bca-ea1
# Innolux Corporation 11.6" WXGA (1366x768) TFT LCD panel
--
2.43.0
^ permalink raw reply related
* [PATCH 2/4] drm/panel: simple: Add missing Innolux G121X1-L03 format, flags, connector
From: Marek Vasut @ 2024-03-28 10:27 UTC (permalink / raw)
To: dri-devel
Cc: Marek Vasut, Conor Dooley, Daniel Vetter, David Airlie,
Jessica Zhang, Krzysztof Kozlowski, Maarten Lankhorst,
Maxime Ripard, Neil Armstrong, Rob Herring, Sam Ravnborg,
Thierry Reding, Thomas Zimmermann, devicetree
In-Reply-To: <20240328102746.17868-1-marex@denx.de>
The .bpc = 6 implies .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG ,
add the missing bus_format. Add missing connector type and bus_flags
as well.
Documentation [1] 1.4 GENERAL SPECIFICATI0NS indicates this panel is
capable of both RGB 18bit/24bit panel, the current configuration uses
18bit mode, .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG , .bpc = 6.
Support for the 24bit mode would require another entry in panel-simple
with .bus_format = MEDIA_BUS_FMT_RGB666_1X7X4_SPWG and .bpc = 8, which
is out of scope of this fix.
[1] https://www.distec.de/fileadmin/pdf/produkte/TFT-Displays/Innolux/G121X1-L03_Datasheet.pdf
Fixes: f8fa17ba812b ("drm/panel: simple: Add support for Innolux G121X1-L03")
Signed-off-by: Marek Vasut <marex@denx.de>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: David Airlie <airlied@gmail.com>
Cc: Jessica Zhang <quic_jesszhan@quicinc.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Neil Armstrong <neil.armstrong@linaro.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/panel/panel-simple.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index d9ddef0e675a7..d4c30a86d15d6 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2618,6 +2618,9 @@ static const struct panel_desc innolux_g121x1_l03 = {
.unprepare = 200,
.disable = 400,
},
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH,
+ .connector_type = DRM_MODE_CONNECTOR_LVDS,
};
static const struct display_timing innolux_g156hce_l01_timings = {
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v3 6/6] riscv: dts: starfive: add Milkv Mars board device tree
From: Jisheng Zhang @ 2024-03-28 10:08 UTC (permalink / raw)
To: Conor Dooley
Cc: Rob Herring, Krzysztof Kozlowski, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Emil Renner Berthing, linux-riscv, devicetree,
linux-kernel
In-Reply-To: <20240327-cotton-fang-37f6d8fde0e5@spud>
On Wed, Mar 27, 2024 at 06:06:58PM +0000, Conor Dooley wrote:
> Yo,
>
> On Tue, Feb 06, 2024 at 07:13:48PM +0000, Conor Dooley wrote:
> > On Wed, Jan 31, 2024 at 09:26:00PM +0800, Jisheng Zhang wrote:
> > > The Milkv Mars is a development board based on the Starfive JH7110 SoC.
> > > The board features:
> > >
> > > - JH7110 SoC
> > > - 1/2/4/8 GiB LPDDR4 DRAM
> > > - AXP15060 PMIC
> > > - 40 pin GPIO header
> > > - 3x USB 3.0 host port
> > > - 1x USB 2.0 host port
> > > - 1x M.2 E-Key
> > > - 1x eMMC slot
> > > - 1x MicroSD slot
> > > - 1x QSPI Flash
> > > - 1x 1Gbps Ethernet port
> > > - 1x HDMI port
> > > - 1x 2-lane DSI and 1x 4-lane DSI
> > > - 1x 2-lane CSI
> > >
> > > Add the devicetree file describing the currently supported features,
> > > namely PMIC, UART, I2C, GPIO, SD card, QSPI Flash, eMMC and Ethernet.
> > >
> > > Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
> >
> > Got a dtbs_check issue in the patchwork CI:
> >
> > +arch/riscv/boot/dts/starfive/jh7110-milkv-mars.dtb: gmac1-rgmii-rxin-clock: 'clock-frequency' is a required property
> > + from schema $id: http://devicetree.org/schemas/clock/fixed-clock.yaml#
> > +arch/riscv/boot/dts/starfive/jh7110-milkv-mars.dtb: gmac1-rmii-refin-clock: 'clock-frequency' is a required property
> > + from schema $id: http://devicetree.org/schemas/clock/fixed-clock.yaml#
> >
> > Can you fix that please? Also, I applied some patches the other day that
> > seem to conflict quite a bit with the common board dts patch. Would you
> > please do a rebase on top of that please?
>
> Been going through stuff on my todo list now that the merge window is
> closed. Could you please resend this with the rebase done?
Thanks for the reminding, I will rebase on 6.9-rc1 then send out the
patches.
>
> Thanks,
> Conor.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox