* Re: [PATCH 1/2] dt-bindings: phy: Add QMP UFS PHY comptible for SM8475
From: Krzysztof Kozlowski @ 2024-03-28 18:05 UTC (permalink / raw)
To: Danila Tikhonov
Cc: krzysztof.kozlowski+dt, andersson, konrad.dybcio, vkoul, kishon,
robh, conor+dt, linux-arm-msm, linux-phy, devicetree,
linux-kernel
In-Reply-To: <d09c9486-d2ac-48d7-b5d3-49b9e1a8cc0a@jiaxyga.com>
On 28/03/2024 19:02, Danila Tikhonov wrote:
>>>
>> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>>
>> (not reviewed, please provide link to DTS)
>>
>> Best regards,
>> Krzysztof
>>
> Yes, sure.
> SM8475 and Nothing Phone 2 (nothing-pong) on which I tested:
> https://github.com/mainlining/linux/blob/danila/sm8475-test/arch/arm64/boot/dts/qcom/sm8475.dtsi
> https://github.com/mainlining/linux/blob/danila/sm8475-test/arch/arm64/boot/dts/qcom/sm8475-nothing-pong.dts
>
Thanks, looks good and in match with the binding, so let's make it:
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 1/4] dt-bindings: input: Add Himax HX83102J touchscreen
From: Conor Dooley @ 2024-03-28 18:05 UTC (permalink / raw)
To: Allen Lin
Cc: Conor Dooley, Rob Herring, dmitry.torokhov,
krzysztof.kozlowski+dt, conor+dt, jikos, benjamin.tissoires,
linux-input, devicetree, linux-kernel
In-Reply-To: <TY0PR06MB5611F7123B22C4FDEE319C049E3B2@TY0PR06MB5611.apcprd06.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]
On Thu, Mar 28, 2024 at 02:05:17PM +0800, Allen Lin wrote:
> OK, I will list all supplies required by the driver in the Yaml
> document as shown below,
>
> properties:
> compatible:
> const: himax,hx83102j
>
> reg:
> maxItems: 1
>
> interrupts:
> maxItems: 1
>
> reset-gpios:
> maxItems: 1
>
> vccd-supply:
> description: A phandle for the regualtor supplying IO power.
>
> vsn-supply:
> description: Negative supply regulator.
>
> vsp-supply:
> description: Positive supply regulator.
>
> ddreset-gpios:
I think this should be s/dd// with the description explaining how this
display reset is related to this device.
Otherwise, this looks okay to me.
On another note - every time you reply to me I get it 3 times. Can you
fix that please?
Thanks,
Conor.
> description: A phandle of gpio for display reset controlled by the
> LCD driver.
>
> required:
> - compatible
> - reg
> - interrupts
> - reset-gpios
> - panel
> - vccd-supply
> - vsn-supply
> - vsp-supply
> - ddreset-gpios
>
>
> Thanks,
> Allen
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH] arm64: dts: rockchip: Enable device-tree overlay support for select devices
From: Chris Morgan @ 2024-03-28 18:05 UTC (permalink / raw)
To: linux-rockchip
Cc: devicetree, jagan, heiko, conor+dt, krzysztof.kozlowski+dt, robh,
sebastian.reichel, Chris Morgan
From: Chris Morgan <macromorgan@hotmail.com>
Add the '-@' DTC option for the Rock 5B and Indiedroid Nova devices.
These two devices are relatively new both with external GPIO headers
for expansion. This does impact the filesize of the DTB substantially.
rk3588-rock-5b.dtb 75352 -> 150094 bytes
rk3588s-indiedroid-nova.dtb 69507 -> 136739 bytes
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
---
arch/arm64/boot/dts/rockchip/Makefile | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index f906a868b71a..26f306db0aea 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -1,4 +1,9 @@
# SPDX-License-Identifier: GPL-2.0
+
+# Enable support for external device-tree overlays
+DTC_FLAGS_rk3588-rock-5b := -@
+DTC_FLAGS_rk3588s-indiedroid-nova := -@
+
dtb-$(CONFIG_ARCH_ROCKCHIP) += px30-evb.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += px30-engicam-px30-core-ctouch2.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += px30-engicam-px30-core-ctouch2-of10.dtb
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] arm64: dts: rockchip: Enable device-tree overlay support for select devices
From: Dragan Simic @ 2024-03-28 18:47 UTC (permalink / raw)
To: Chris Morgan
Cc: linux-rockchip, devicetree, jagan, heiko, conor+dt,
krzysztof.kozlowski+dt, robh, sebastian.reichel, Chris Morgan
In-Reply-To: <20240328180551.361381-1-macroalpha82@gmail.com>
Hello Chris,
On 2024-03-28 19:05, Chris Morgan wrote:
> From: Chris Morgan <macromorgan@hotmail.com>
>
> Add the '-@' DTC option for the Rock 5B and Indiedroid Nova devices.
> These two devices are relatively new both with external GPIO headers
> for expansion. This does impact the filesize of the DTB substantially.
I think that enabling this should be either left to Linux distributions,
to be enabled for all the dtbs they ship, which they already do, or be
enabled by us for all Rockchip DTs, instead of for enabling it just for
some boards. However, I think that leaving it to Linux distributions is
the preferred way.
> rk3588-rock-5b.dtb 75352 -> 150094 bytes
> rk3588s-indiedroid-nova.dtb 69507 -> 136739 bytes
>
> Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
> ---
> arch/arm64/boot/dts/rockchip/Makefile | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/Makefile
> b/arch/arm64/boot/dts/rockchip/Makefile
> index f906a868b71a..26f306db0aea 100644
> --- a/arch/arm64/boot/dts/rockchip/Makefile
> +++ b/arch/arm64/boot/dts/rockchip/Makefile
> @@ -1,4 +1,9 @@
> # SPDX-License-Identifier: GPL-2.0
> +
> +# Enable support for external device-tree overlays
> +DTC_FLAGS_rk3588-rock-5b := -@
> +DTC_FLAGS_rk3588s-indiedroid-nova := -@
> +
> dtb-$(CONFIG_ARCH_ROCKCHIP) += px30-evb.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += px30-engicam-px30-core-ctouch2.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += px30-engicam-px30-core-ctouch2-of10.dtb
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: leds: Add Silergy SY7802 flash LED
From: Rob Herring @ 2024-03-28 18:50 UTC (permalink / raw)
To: André Apitzsch
Cc: Pavel Machek, Lee Jones, Krzysztof Kozlowski, Conor Dooley,
Kees Cook, Gustavo A. R. Silva, Bjorn Andersson, Konrad Dybcio,
linux-leds, devicetree, linux-kernel, linux-hardening,
linux-arm-msm, ~postmarketos/upstreaming
In-Reply-To: <20240327-sy7802-v1-1-db74ab32faaf@apitzsch.eu>
On Wed, Mar 27, 2024 at 11:51:33PM +0100, André Apitzsch wrote:
> Document Silergy SY7802 flash LED driver devicetree bindings.
>
> Signed-off-by: André Apitzsch <git@apitzsch.eu>
> ---
> .../devicetree/bindings/leds/silergy,sy7802.yaml | 96 ++++++++++++++++++++++
> 1 file changed, 96 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/leds/silergy,sy7802.yaml b/Documentation/devicetree/bindings/leds/silergy,sy7802.yaml
> new file mode 100644
> index 000000000000..d32efac8baa6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/silergy,sy7802.yaml
> @@ -0,0 +1,96 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/leds/silergy,sy7802.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Silergy SY7802 1800mA Boost Charge Pump LED Driver
> +
> +maintainers:
> + - André Apitzsch <git@apitzsch.eu>
> +
> +description: |
> + The SY7802 is a current-regulated charge pump which can regulate two current
> + levels for Flash and Torch modes.
> +
> + The SY7802 is a high-current synchronous boost converter with 2-channel
> + high side current sources. Each channel is able to deliver 900mA current.
> +
> +properties:
> + compatible:
> + enum:
> + - silergy,sy7802
> +
> + reg:
> + maxItems: 1
> +
> + enable-gpios:
> + maxItems: 1
> + description: A connection to the 'EN' pin.
> +
> + flash-gpios:
> + maxItems: 1
> + description: A connection to the 'FLEN' pin.
> +
> + vin-supply:
> + description: Regulator providing power to the 'VIN' pin.
> +
> + "#address-cells":
> + const: 1
> +
> + "#size-cells":
> + const: 0
> +
> +patternProperties:
> + "^led@[0-1]$":
> + type: object
> + $ref: common.yaml#
> + unevaluatedProperties: false
> +
> + properties:
> + reg:
> + description: Index of the LED.
> + minimum: 0
> + maximum: 1
> +
> + led-sources:
> + allOf:
Don't need allOf here.
> + - minItems: 1
> + maxItems: 2
> + items:
> + minimum: 0
> + maximum: 1
> +
> + required:
> + - reg
> + - led-sources
> +
> +required:
> + - compatible
> + - reg
> + - "#address-cells"
> + - "#size-cells"
> + - enable-gpios
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/leds/common.h>
> +
> + flash-led-controller@53 {
This needs to go under an appropriate bus node to fix the errors. i2c
presumably.
> + compatible = "silergy,sy7802";
> + reg = <0x53>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + enable-gpios = <&tlmm 16 GPIO_ACTIVE_HIGH>;
> +
> + led@0 {
> + reg = <0>;
> + function = LED_FUNCTION_FLASH;
> + color = <LED_COLOR_ID_WHITE>;
> + led-sources = <0>, <1>;
> + };
> + };
>
> --
> 2.44.0
>
^ permalink raw reply
* Re: [PATCH v3 2/2] phy: add driver for MediaTek XFI T-PHY
From: Vinod Koul @ 2024-03-28 18:52 UTC (permalink / raw)
To: Daniel Golle
Cc: Bc-bocun Chen, Steven Liu, John Crispin, Chunfeng Yun,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Qingfang Deng, SkyLake Huang, Philipp Zabel, linux-arm-kernel,
linux-mediatek, linux-phy, devicetree, linux-kernel, netdev
In-Reply-To: <3bb95f1d795eede63284dbcb224e06ea6886b421.1707530671.git.daniel@makrotopia.org>
On 10-02-24, 02:10, Daniel Golle wrote:
> Add driver for MediaTek's XFI T-PHY which can be found in the MT7988
What does XFI mean?
> SoC. The XFI T-PHY is a 10 Gigabit/s Ethernet SerDes PHY with muxes on
> the internal side to be used with either USXGMII PCS or LynxI PCS,
> depending on the selected PHY interface mode.
>
> The PHY can operates only in PHY_MODE_ETHERNET, the submode is one of
> PHY_INTERFACE_MODE_* corresponding to the supported modes:
>
> * USXGMII \
> * 10GBase-R }- USXGMII PCS - XGDM \
> * 5GBase-R / \
> }- Ethernet MAC
> * 2500Base-X \ /
> * 1000Base-X }- LynxI PCS - GDM /
> * Cisco SGMII (MAC side) /
>
> In order to work-around a performance issue present on the first of
> two XFI T-PHYs present in MT7988, special tuning is applied which can be
> selected by adding the 'mediatek,usxgmii-performance-errata' property to
> the device tree node.
>
> There is no documentation for most registers used for the
> analog/tuning part, however, most of the registers have been partially
> reverse-engineered from MediaTek's SDK implementation (an opaque
> sequence of 32-bit register writes) and descriptions for all relevant
> digital registers and bits such as resets and muxes have been supplied
> by MediaTek.
>
> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
> v3: no changes
> v2:
> * use IO helpers from mtk-io.h instead of rolling my own
> * use devm_clk_bulk_get()
> * yse devm_platform_ioremap_resource()
> * unify name and description everywhere
> * invert bool is_xgmii into bool use_lynxi_pcs and add comments
> describing the meaning of each of the stack variables
> * not much we can do about remaining magic values unless MTK provides
> definitions for them
>
>
> MAINTAINERS | 1 +
> drivers/phy/mediatek/Kconfig | 12 +
> drivers/phy/mediatek/Makefile | 1 +
> drivers/phy/mediatek/phy-mtk-xfi-tphy.c | 360 ++++++++++++++++++++++++
> 4 files changed, 374 insertions(+)
> create mode 100644 drivers/phy/mediatek/phy-mtk-xfi-tphy.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4be2fd097f261..616b86e3e62fd 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -13776,6 +13776,7 @@ L: netdev@vger.kernel.org
> S: Maintained
> F: drivers/net/phy/mediatek-ge-soc.c
> F: drivers/net/phy/mediatek-ge.c
> +F: drivers/phy/mediatek/phy-mtk-xfi-tphy.c
>
> MEDIATEK I2C CONTROLLER DRIVER
> M: Qii Wang <qii.wang@mediatek.com>
> diff --git a/drivers/phy/mediatek/Kconfig b/drivers/phy/mediatek/Kconfig
> index 3849b7c87d287..117d0e84c7360 100644
> --- a/drivers/phy/mediatek/Kconfig
> +++ b/drivers/phy/mediatek/Kconfig
> @@ -13,6 +13,18 @@ config PHY_MTK_PCIE
> callback for PCIe GEN3 port, it supports software efuse
> initialization.
>
> +config PHY_MTK_XFI_TPHY
> + tristate "MediaTek 10GE SerDes XFI T-PHY driver"
> + depends on ARCH_MEDIATEK || COMPILE_TEST
> + depends on OF && OF_ADDRESS
why both, is OF not enough?
> + depends on HAS_IOMEM
> + select GENERIC_PHY
> + help
> + Say 'Y' here to add support for MediaTek XFI T-PHY driver.
> + The driver provides access to the Ethernet SerDes T-PHY supporting
> + 1GE and 2.5GE modes via the LynxI PCS, and 5GE and 10GE modes
> + via the USXGMII PCS found in MediaTek SoCs with 10G Ethernet.
> +
> config PHY_MTK_TPHY
> tristate "MediaTek T-PHY Driver"
> depends on ARCH_MEDIATEK || COMPILE_TEST
> diff --git a/drivers/phy/mediatek/Makefile b/drivers/phy/mediatek/Makefile
> index f6e24a47e0815..1b8088df71e84 100644
> --- a/drivers/phy/mediatek/Makefile
> +++ b/drivers/phy/mediatek/Makefile
> @@ -8,6 +8,7 @@ obj-$(CONFIG_PHY_MTK_PCIE) += phy-mtk-pcie.o
> obj-$(CONFIG_PHY_MTK_TPHY) += phy-mtk-tphy.o
> obj-$(CONFIG_PHY_MTK_UFS) += phy-mtk-ufs.o
> obj-$(CONFIG_PHY_MTK_XSPHY) += phy-mtk-xsphy.o
> +obj-$(CONFIG_PHY_MTK_XFI_TPHY) += phy-mtk-xfi-tphy.o
>
> phy-mtk-hdmi-drv-y := phy-mtk-hdmi.o
> phy-mtk-hdmi-drv-y += phy-mtk-hdmi-mt2701.o
> diff --git a/drivers/phy/mediatek/phy-mtk-xfi-tphy.c b/drivers/phy/mediatek/phy-mtk-xfi-tphy.c
> new file mode 100644
> index 0000000000000..551d6cee33f94
> --- /dev/null
> +++ b/drivers/phy/mediatek/phy-mtk-xfi-tphy.c
> @@ -0,0 +1,360 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/* MediaTek 10GE SerDes XFI T-PHY driver
> + *
> + * Copyright (c) 2024 Daniel Golle <daniel@makrotopia.org>
> + * Bc-bocun Chen <bc-bocun.chen@mediatek.com>
> + * based on mtk_usxgmii.c and mtk_sgmii.c found in MediaTek's SDK (GPL-2.0)
> + * Copyright (c) 2022 MediaTek Inc.
> + * Author: Henry Yen <henry.yen@mediatek.com>
> + */
> +
> +#include <linux/module.h>
> +#include <linux/device.h>
> +#include <linux/platform_device.h>
> +#include <linux/of.h>
> +#include <linux/io.h>
> +#include <linux/clk.h>
> +#include <linux/reset.h>
> +#include <linux/phy.h>
> +#include <linux/phy/phy.h>
> +
> +#include "phy-mtk-io.h"
> +
> +#define MTK_XFI_TPHY_NUM_CLOCKS 2
> +
> +#define REG_DIG_GLB_70 0x0070
> +#define XTP_PCS_RX_EQ_IN_PROGRESS(x) FIELD_PREP(GENMASK(25, 24), (x))
> +#define XTP_PCS_MODE_MASK GENMASK(17, 16)
> +#define XTP_PCS_MODE(x) FIELD_PREP(GENMASK(17, 16), (x))
> +#define XTP_PCS_RST_B BIT(15)
> +#define XTP_FRC_PCS_RST_B BIT(14)
> +#define XTP_PCS_PWD_SYNC_MASK GENMASK(13, 12)
> +#define XTP_PCS_PWD_SYNC(x) FIELD_PREP(XTP_PCS_PWD_SYNC_MASK, (x))
> +#define XTP_PCS_PWD_ASYNC_MASK GENMASK(11, 10)
> +#define XTP_PCS_PWD_ASYNC(x) FIELD_PREP(XTP_PCS_PWD_ASYNC_MASK, (x))
> +#define XTP_FRC_PCS_PWD_ASYNC BIT(8)
> +#define XTP_PCS_UPDT BIT(4)
> +#define XTP_PCS_IN_FR_RG BIT(0)
> +
> +#define REG_DIG_GLB_F4 0x00f4
> +#define XFI_DPHY_PCS_SEL BIT(0)
> +#define XFI_DPHY_PCS_SEL_SGMII FIELD_PREP(XFI_DPHY_PCS_SEL, 1)
> +#define XFI_DPHY_PCS_SEL_USXGMII FIELD_PREP(XFI_DPHY_PCS_SEL, 0)
> +#define XFI_DPHY_AD_SGDT_FRC_EN BIT(5)
> +
> +#define REG_DIG_LN_TRX_40 0x3040
> +#define XTP_LN_FRC_TX_DATA_EN BIT(29)
> +#define XTP_LN_TX_DATA_EN BIT(28)
> +
> +#define REG_DIG_LN_TRX_B0 0x30b0
> +#define XTP_LN_FRC_TX_MACCK_EN BIT(5)
> +#define XTP_LN_TX_MACCK_EN BIT(4)
> +
> +#define REG_ANA_GLB_D0 0x90d0
> +#define XTP_GLB_USXGMII_SEL_MASK GENMASK(3, 1)
> +#define XTP_GLB_USXGMII_SEL(x) FIELD_PREP(GENMASK(3, 1), (x))
> +#define XTP_GLB_USXGMII_EN BIT(0)
> +
> +struct mtk_xfi_tphy {
> + void __iomem *base;
> + struct device *dev;
> + struct reset_control *reset;
> + struct clk_bulk_data clocks[MTK_XFI_TPHY_NUM_CLOCKS];
> + bool da_war;
> +};
> +
> +static void mtk_xfi_tphy_setup(struct mtk_xfi_tphy *xfi_tphy,
> + phy_interface_t interface)
> +{
> + /* Override 10GBase-R tuning value if work-around is selected */
> + bool da_war = (xfi_tphy->da_war && (interface == PHY_INTERFACE_MODE_10GBASER));
why do you need braces around this?
> + /* Bools to make setting up values for specific PHY speeds easier */
> + bool is_2p5g = (interface == PHY_INTERFACE_MODE_2500BASEX);
> + bool is_1g = (interface == PHY_INTERFACE_MODE_1000BASEX ||
> + interface == PHY_INTERFACE_MODE_SGMII);
> + bool is_10g = (interface == PHY_INTERFACE_MODE_10GBASER ||
> + interface == PHY_INTERFACE_MODE_USXGMII);
> + bool is_5g = (interface == PHY_INTERFACE_MODE_5GBASER);
> + /* Bool to configure input mux to either
> + * - USXGMII PCS (64b/66b coding) for 5G/10G
> + * - LynxI PCS (8b/10b coding) for 1G/2.5G
> + */
> + bool use_lynxi_pcs = (is_1g || is_2p5g);
This is quite terrible to read, how about declaring variables first and
then doing the initialization?
> +
> + dev_dbg(xfi_tphy->dev, "setting up for mode %s\n", phy_modes(interface));
> +
> + /* Setup PLL setting */
> + mtk_phy_update_bits(xfi_tphy->base + 0x9024, 0x100000, is_10g ? 0x0 : 0x100000);
> + mtk_phy_update_bits(xfi_tphy->base + 0x2020, 0x202000, is_5g ? 0x202000 : 0x0);
> + mtk_phy_update_bits(xfi_tphy->base + 0x2030, 0x500, is_1g ? 0x0 : 0x500);
> + mtk_phy_update_bits(xfi_tphy->base + 0x2034, 0xa00, is_1g ? 0x0 : 0xa00);
> + mtk_phy_update_bits(xfi_tphy->base + 0x2040, 0x340000, is_1g ? 0x200000 : 0x140000);
magic numbers?
> +
> + /* Setup RXFE BW setting */
> + mtk_phy_update_bits(xfi_tphy->base + 0x50f0, 0xc10, is_1g ? 0x410 : is_5g ? 0x800 : 0x400);
> + mtk_phy_update_bits(xfi_tphy->base + 0x50e0, 0x4000, is_5g ? 0x0 : 0x4000);
> +
> + /* Setup RX CDR setting */
> + mtk_phy_update_bits(xfi_tphy->base + 0x506c, 0x30000, is_5g ? 0x0 : 0x30000);
> + mtk_phy_update_bits(xfi_tphy->base + 0x5070, 0x670000, is_5g ? 0x620000 : 0x50000);
> + mtk_phy_update_bits(xfi_tphy->base + 0x5074, 0x180000, is_5g ? 0x180000 : 0x0);
> + mtk_phy_update_bits(xfi_tphy->base + 0x5078, 0xf000400, is_5g ? 0x8000000 :
> + 0x7000400);
> + mtk_phy_update_bits(xfi_tphy->base + 0x507c, 0x5000500, is_5g ? 0x4000400 :
> + 0x1000100);
> + mtk_phy_update_bits(xfi_tphy->base + 0x5080, 0x1410, is_1g ? 0x400 : is_5g ? 0x1010 : 0x0);
> + mtk_phy_update_bits(xfi_tphy->base + 0x5084, 0x30300, is_1g ? 0x30300 :
> + is_5g ? 0x30100 :
> + 0x100);
> + mtk_phy_update_bits(xfi_tphy->base + 0x5088, 0x60200, is_1g ? 0x20200 :
> + is_5g ? 0x40000 :
> + 0x20000);
> +
> + /* Setting RXFE adaptation range setting */
> + mtk_phy_update_bits(xfi_tphy->base + 0x50e4, 0xc0000, is_5g ? 0x0 : 0xc0000);
> + mtk_phy_update_bits(xfi_tphy->base + 0x50e8, 0x40000, is_5g ? 0x0 : 0x40000);
> + mtk_phy_update_bits(xfi_tphy->base + 0x50ec, 0xa00, is_1g ? 0x200 : 0x800);
> + mtk_phy_update_bits(xfi_tphy->base + 0x50a8, 0xee0000, is_5g ? 0x800000 :
> + 0x6e0000);
> + mtk_phy_update_bits(xfi_tphy->base + 0x6004, 0x190000, is_5g ? 0x0 : 0x190000);
> +
> + if (is_10g)
> + writel(0x01423342, xfi_tphy->base + 0x00f8);
> + else if (is_5g)
> + writel(0x00a132a1, xfi_tphy->base + 0x00f8);
> + else if (is_2p5g)
> + writel(0x009c329c, xfi_tphy->base + 0x00f8);
> + else
> + writel(0x00fa32fa, xfi_tphy->base + 0x00f8);
> +
> + /* Force SGDT_OUT off and select PCS */
> + mtk_phy_update_bits(xfi_tphy->base + REG_DIG_GLB_F4,
> + XFI_DPHY_AD_SGDT_FRC_EN | XFI_DPHY_PCS_SEL,
> + XFI_DPHY_AD_SGDT_FRC_EN |
> + (use_lynxi_pcs ? XFI_DPHY_PCS_SEL_SGMII :
> + XFI_DPHY_PCS_SEL_USXGMII));
> +
> + /* Force GLB_CKDET_OUT */
> + mtk_phy_set_bits(xfi_tphy->base + 0x0030, 0xc00);
> +
> + /* Force AEQ on */
> + writel(XTP_PCS_RX_EQ_IN_PROGRESS(2) | XTP_PCS_PWD_SYNC(2) | XTP_PCS_PWD_ASYNC(2),
> + xfi_tphy->base + REG_DIG_GLB_70);
> +
> + usleep_range(1, 5);
> +
> + /* Setup TX DA default value */
> + mtk_phy_update_bits(xfi_tphy->base + 0x30b0, 0x30, 0x20);
> + writel(0x00008a01, xfi_tphy->base + 0x3028);
> + writel(0x0000a884, xfi_tphy->base + 0x302c);
> + writel(0x00083002, xfi_tphy->base + 0x3024);
> +
> + /* Setup RG default value */
> + if (use_lynxi_pcs) {
> + writel(0x00011110, xfi_tphy->base + 0x3010);
> + writel(0x40704000, xfi_tphy->base + 0x3048);
> + } else {
> + writel(0x00022220, xfi_tphy->base + 0x3010);
> + writel(0x0f020a01, xfi_tphy->base + 0x5064);
> + writel(0x06100600, xfi_tphy->base + 0x50b4);
> + if (interface == PHY_INTERFACE_MODE_USXGMII)
> + writel(0x40704000, xfi_tphy->base + 0x3048);
> + else
> + writel(0x47684100, xfi_tphy->base + 0x3048);
> + }
> +
> + if (is_1g)
> + writel(0x0000c000, xfi_tphy->base + 0x3064);
> +
> + /* Setup RX EQ initial value */
> + mtk_phy_update_bits(xfi_tphy->base + 0x3050, 0xa8000000,
> + (interface != PHY_INTERFACE_MODE_10GBASER) ? 0xa8000000 : 0x0);
> + mtk_phy_update_bits(xfi_tphy->base + 0x3054, 0xaa,
> + (interface != PHY_INTERFACE_MODE_10GBASER) ? 0xaa : 0x0);
> +
> + if (!use_lynxi_pcs)
> + writel(0x00000f00, xfi_tphy->base + 0x306c);
> + else if (is_2p5g)
> + writel(0x22000f00, xfi_tphy->base + 0x306c);
> + else
> + writel(0x20200f00, xfi_tphy->base + 0x306c);
> +
> + mtk_phy_update_bits(xfi_tphy->base + 0xa008, 0x10000, da_war ? 0x10000 : 0x0);
> +
> + mtk_phy_update_bits(xfi_tphy->base + 0xa060, 0x50000, use_lynxi_pcs ? 0x50000 : 0x40000);
> +
> + /* Setup PHYA speed */
> + mtk_phy_update_bits(xfi_tphy->base + REG_ANA_GLB_D0,
> + XTP_GLB_USXGMII_SEL_MASK | XTP_GLB_USXGMII_EN,
> + is_10g ? XTP_GLB_USXGMII_SEL(0) :
> + is_5g ? XTP_GLB_USXGMII_SEL(1) :
> + is_2p5g ? XTP_GLB_USXGMII_SEL(2) :
> + XTP_GLB_USXGMII_SEL(3));
> + mtk_phy_set_bits(xfi_tphy->base + REG_ANA_GLB_D0, XTP_GLB_USXGMII_EN);
> +
> + /* Release reset */
> + mtk_phy_set_bits(xfi_tphy->base + REG_DIG_GLB_70,
> + XTP_PCS_RST_B | XTP_FRC_PCS_RST_B);
> + usleep_range(150, 500);
> +
> + /* Switch to P0 */
> + mtk_phy_update_bits(xfi_tphy->base + REG_DIG_GLB_70,
> + XTP_PCS_IN_FR_RG |
> + XTP_FRC_PCS_PWD_ASYNC |
> + XTP_PCS_PWD_ASYNC_MASK |
> + XTP_PCS_PWD_SYNC_MASK |
> + XTP_PCS_UPDT,
> + XTP_PCS_IN_FR_RG |
> + XTP_FRC_PCS_PWD_ASYNC |
> + XTP_PCS_UPDT);
> + usleep_range(1, 5);
> +
> + mtk_phy_clear_bits(xfi_tphy->base + REG_DIG_GLB_70, XTP_PCS_UPDT);
> + usleep_range(15, 50);
> +
> + if (use_lynxi_pcs) {
> + /* Switch to Gen2 */
> + mtk_phy_update_bits(xfi_tphy->base + REG_DIG_GLB_70,
> + XTP_PCS_MODE_MASK | XTP_PCS_UPDT,
> + XTP_PCS_MODE(1) | XTP_PCS_UPDT);
> + } else {
> + /* Switch to Gen3 */
> + mtk_phy_update_bits(xfi_tphy->base + REG_DIG_GLB_70,
> + XTP_PCS_MODE_MASK | XTP_PCS_UPDT,
> + XTP_PCS_MODE(2) | XTP_PCS_UPDT);
> + }
> + usleep_range(1, 5);
> +
> + mtk_phy_clear_bits(xfi_tphy->base + REG_DIG_GLB_70, XTP_PCS_UPDT);
> +
> + usleep_range(100, 500);
> +
> + /* Enable MAC CK */
> + mtk_phy_set_bits(xfi_tphy->base + REG_DIG_LN_TRX_B0, XTP_LN_TX_MACCK_EN);
> + mtk_phy_clear_bits(xfi_tphy->base + REG_DIG_GLB_F4, XFI_DPHY_AD_SGDT_FRC_EN);
> +
> + /* Enable TX data */
> + mtk_phy_set_bits(xfi_tphy->base + REG_DIG_LN_TRX_40,
> + XTP_LN_FRC_TX_DATA_EN | XTP_LN_TX_DATA_EN);
> + usleep_range(400, 1000);
> +}
> +
> +static int mtk_xfi_tphy_set_mode(struct phy *phy, enum phy_mode mode, int
> + submode)
> +{
> + struct mtk_xfi_tphy *xfi_tphy = phy_get_drvdata(phy);
> +
> + if (mode != PHY_MODE_ETHERNET)
> + return -EINVAL;
> +
> + switch (submode) {
> + case PHY_INTERFACE_MODE_1000BASEX:
> + case PHY_INTERFACE_MODE_2500BASEX:
> + case PHY_INTERFACE_MODE_SGMII:
> + case PHY_INTERFACE_MODE_5GBASER:
> + case PHY_INTERFACE_MODE_10GBASER:
> + case PHY_INTERFACE_MODE_USXGMII:
> + mtk_xfi_tphy_setup(xfi_tphy, submode);
> + return 0;
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static int mtk_xfi_tphy_reset(struct phy *phy)
> +{
> + struct mtk_xfi_tphy *xfi_tphy = phy_get_drvdata(phy);
> +
> + reset_control_assert(xfi_tphy->reset);
> + usleep_range(100, 500);
> + reset_control_deassert(xfi_tphy->reset);
> + usleep_range(1, 10);
> +
> + return 0;
> +}
> +
> +static int mtk_xfi_tphy_power_on(struct phy *phy)
> +{
> + struct mtk_xfi_tphy *xfi_tphy = phy_get_drvdata(phy);
> +
> + return clk_bulk_prepare_enable(MTK_XFI_TPHY_NUM_CLOCKS, xfi_tphy->clocks);
> +}
> +
> +static int mtk_xfi_tphy_power_off(struct phy *phy)
> +{
> + struct mtk_xfi_tphy *xfi_tphy = phy_get_drvdata(phy);
> +
> + clk_bulk_disable_unprepare(MTK_XFI_TPHY_NUM_CLOCKS, xfi_tphy->clocks);
> +
> + return 0;
> +}
> +
> +static const struct phy_ops mtk_xfi_tphy_ops = {
> + .power_on = mtk_xfi_tphy_power_on,
> + .power_off = mtk_xfi_tphy_power_off,
> + .set_mode = mtk_xfi_tphy_set_mode,
> + .reset = mtk_xfi_tphy_reset,
> + .owner = THIS_MODULE,
> +};
> +
> +static int mtk_xfi_tphy_probe(struct platform_device *pdev)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + struct phy_provider *phy_provider;
> + struct mtk_xfi_tphy *xfi_tphy;
> + struct phy *phy;
> + int ret;
> +
> + if (!np)
> + return -ENODEV;
> +
> + xfi_tphy = devm_kzalloc(&pdev->dev, sizeof(*xfi_tphy), GFP_KERNEL);
> + if (!xfi_tphy)
> + return -ENOMEM;
> +
> + xfi_tphy->base = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(xfi_tphy->base))
> + return PTR_ERR(xfi_tphy->base);
> +
> + xfi_tphy->dev = &pdev->dev;
> + xfi_tphy->clocks[0].id = "topxtal";
> + xfi_tphy->clocks[1].id = "xfipll";
> + ret = devm_clk_bulk_get(&pdev->dev, MTK_XFI_TPHY_NUM_CLOCKS, xfi_tphy->clocks);
> + if (ret)
> + return ret;
> +
> + xfi_tphy->reset = devm_reset_control_get_exclusive(&pdev->dev, NULL);
> + if (IS_ERR(xfi_tphy->reset))
> + return PTR_ERR(xfi_tphy->reset);
> +
> + xfi_tphy->da_war = of_property_read_bool(np, "mediatek,usxgmii-performance-errata");
> +
> + phy = devm_phy_create(&pdev->dev, NULL, &mtk_xfi_tphy_ops);
> + if (IS_ERR(phy))
> + return PTR_ERR(phy);
> +
> + phy_set_drvdata(phy, xfi_tphy);
> + phy_provider = devm_of_phy_provider_register(&pdev->dev, of_phy_simple_xlate);
> +
> + return PTR_ERR_OR_ZERO(phy_provider);
> +}
> +
> +static const struct of_device_id mtk_xfi_tphy_match[] = {
> + { .compatible = "mediatek,mt7988-xfi-tphy", },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, mtk_xfi_tphy_match);
> +
> +static struct platform_driver mtk_xfi_tphy_driver = {
> + .probe = mtk_xfi_tphy_probe,
> + .driver = {
> + .name = "mtk-xfi-tphy",
> + .of_match_table = mtk_xfi_tphy_match,
> + },
> +};
> +module_platform_driver(mtk_xfi_tphy_driver);
> +
> +MODULE_DESCRIPTION("MediaTek 10GE SerDes XFI T-PHY driver");
> +MODULE_AUTHOR("Daniel Golle <daniel@makrotopia.org>");
> +MODULE_AUTHOR("Bc-bocun Chen <bc-bocun.chen@mediatek.com>");
> +MODULE_LICENSE("GPL");
> --
> 2.43.0
--
~Vinod
^ permalink raw reply
* [PATCH v6 0/1] Add property in dwmac-stm32 documentation
From: Christophe Roullier @ 2024-03-28 18:53 UTC (permalink / raw)
To: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Maxime Coquelin,
Alexandre Torgue, Richard Cochran, Jose Abreu, Liam Girdwood,
Mark Brown, Christophe Roullier, Marek Vasut
Cc: netdev, devicetree, linux-stm32, linux-arm-kernel, linux-kernel
Introduce property in dwmac-stm32 documentation
- st,ext-phyclk: is present since 2020 in driver so need to explain
it and avoid dtbs check issue : views/kernel/upstream/net-next/arch/arm/boot/dts/st/stm32mp157c-dk2.dtb:
ethernet@5800a000: Unevaluated properties are not allowed
('st,ext-phyclk' was unexpected)
Furthermore this property will be use in upstream of MP13 dwmac glue. (next step)
V2: - Drop deprecated: property for st,eth-clk-sel and st,eth-ref-clk-sel
V3: - Rework commit message
V4: - Fix syntax issue in commit message
V5: - Remark from Andrew Lunn (remove documentation of PHY regulator, it will come in next step (with
implementation))
V6: - Fix indentation
Christophe Roullier (1):
dt-bindings: net: dwmac: Document STM32 property st,ext-phyclk
Documentation/devicetree/bindings/net/stm32-dwmac.yaml | 7 +++++++
1 file changed, 7 insertions(+)
--
2.25.1
^ permalink raw reply
* [PATCH v6 1/1] dt-bindings: net: dwmac: Document STM32 property st,ext-phyclk
From: Christophe Roullier @ 2024-03-28 18:53 UTC (permalink / raw)
To: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Maxime Coquelin,
Alexandre Torgue, Richard Cochran, Jose Abreu, Liam Girdwood,
Mark Brown, Christophe Roullier, Marek Vasut
Cc: netdev, devicetree, linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <20240328185337.332703-1-christophe.roullier@foss.st.com>
The Linux kernel dwmac-stm32 driver currently supports three DT
properties used to configure whether PHY clock are generated by
the MAC or supplied to the MAC from the PHY.
Originally there were two properties, st,eth-clk-sel and
st,eth-ref-clk-sel, each used to configure MAC clocking in
different bus mode and for different MAC clock frequency.
Since it is possible to determine the MAC 'eth-ck' clock
frequency from the clock subsystem and PHY bus mode from
the 'phy-mode' property, two disparate DT properties are
no longer required to configure MAC clocking.
Linux kernel commit 1bb694e20839 ("net: ethernet: stmmac: simplify phy modes management for stm32")
introduced a third, unified, property st,ext-phyclk. This property
covers both use cases of st,eth-clk-sel and st,eth-ref-clk-sel DT
properties, as well as a new use case for 25 MHz clock generated
by the MAC.
The third property st,ext-phyclk is so far undocumented,
document it.
Below table summarizes the clock requirement and clock sources for
supported PHY interface modes.
__________________________________________________________________________
|PHY_MODE | Normal | PHY wo crystal| PHY wo crystal |No 125Mhz from PHY|
| | | 25MHz | 50MHz | |
---------------------------------------------------------------------------
| MII | - | eth-ck | n/a | n/a |
| | | st,ext-phyclk | | |
---------------------------------------------------------------------------
| GMII | - | eth-ck | n/a | n/a |
| | | st,ext-phyclk | | |
---------------------------------------------------------------------------
| RGMII | - | eth-ck | n/a | eth-ck |
| | | st,ext-phyclk | | st,eth-clk-sel or|
| | | | | st,ext-phyclk |
---------------------------------------------------------------------------
| RMII | - | eth-ck | eth-ck | n/a |
| | | st,ext-phyclk | st,eth-ref-clk-sel | |
| | | | or st,ext-phyclk | |
---------------------------------------------------------------------------
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Marek Vasut <marex@denx.de>
Signed-off-by: Christophe Roullier <christophe.roullier@foss.st.com>
---
Documentation/devicetree/bindings/net/stm32-dwmac.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
index fc8c96b08d7dc..857d58949b029 100644
--- a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
@@ -82,6 +82,13 @@ properties:
Should be phandle/offset pair. The phandle to the syscon node which
encompases the glue register, and the offset of the control register
+ st,ext-phyclk:
+ description:
+ set this property in RMII mode when you have PHY without crystal 50MHz and want to
+ select RCC clock instead of ETH_REF_CLK. OR in RGMII mode when you want to select
+ RCC clock instead of ETH_CLK125.
+ type: boolean
+
st,eth-clk-sel:
description:
set this property in RGMII PHY when you want to select RCC clock instead of ETH_CLK125.
--
2.25.1
^ permalink raw reply related
* Re: [PATCH 18/23] dt-bindings: media: imx258: Add alternate compatible strings
From: Rob Herring @ 2024-03-28 18:55 UTC (permalink / raw)
To: git
Cc: linux-media, dave.stevenson, jacopo.mondi, mchehab,
krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer, kernel,
festevam, sakari.ailus, devicetree, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <20240327231710.53188-19-git@luigi311.com>
On Wed, Mar 27, 2024 at 05:17:04PM -0600, git@luigi311.com wrote:
> From: Dave Stevenson <dave.stevenson@raspberrypi.com>
>
> There are a number of variants of the imx258 modules that can not
> be differentiated at runtime, so add compatible strings for them.
But you are only adding 1 variant.
>
> Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
> Signed-off-by: Luigi311 <git@luigi311.com>
> ---
> .../devicetree/bindings/media/i2c/sony,imx258.yaml | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
> index bee61a443b23..c7856de15ba3 100644
> --- a/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
> @@ -14,10 +14,14 @@ description: |-
> type stacked image sensor with a square pixel array of size 4208 x 3120. It
> is programmable through I2C interface. Image data is sent through MIPI
> CSI-2.
> + There are a number of variants of the sensor which cannot be detected at
> + runtime, so multiple compatible strings are required to differentiate these.
That's more reasoning/why for the patch than description of the h/w.
> properties:
> compatible:
> - const: sony,imx258
> + - enum:
> + - sony,imx258
> + - sony,imx258-pdaf
How do I know which one to use? Please define what PDAF means somewhere
as well as perhaps what the original/default variant is or isn't.
>
> assigned-clocks: true
> assigned-clock-parents: true
> --
> 2.42.0
>
^ permalink raw reply
* Re: [PATCH RESEND v5 1/2] phy: Add Embedded DisplayPort and DisplayPort submodes
From: Vinod Koul @ 2024-03-28 19:09 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Abel Vesa, Kishon Vijay Abraham I, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Johan Hovold,
linux-phy, linux-kernel, linux-arm-msm, devicetree
In-Reply-To: <CAA8EJprPgZJ7hZooJEs1ysn2Py=M_rJguuVdXFuBK757q86ZAQ@mail.gmail.com>
On 24-03-24, 23:26, Dmitry Baryshkov wrote:
> On Sun, 24 Mar 2024 at 20:50, Abel Vesa <abel.vesa@linaro.org> wrote:
> >
> > In some cases, a DP PHY needs to be configured to work in eDP mode.
> > So add submodes for both DP and eDP so they can be used by the
> > controllers for specifying the mode the PHY should be configured in.
> >
> > Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
> > ---
> > include/linux/phy/phy-dp.h | 3 +++
> > 1 file changed, 3 insertions(+)
>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>
> Vinod, we'd need an immutable branch or a tag for this patch, so that
> we can merge DP changes during this cycle
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/phy/linux-phy.git tags/phy_dp_modes_6.10
for you to fetch changes up to 6078b8ce070cad3f9a8ecfce65d0f6d595494f02:
phy: qcom: edp: Add set_mode op for configuring eDP/DP submode (2024-03-29 00:30:16 +0530)
----------------------------------------------------------------
phy_dp_modes_6.10
This contains the dp submode definition and associated qcom driver change
----------------------------------------------------------------
Abel Vesa (2):
phy: Add Embedded DisplayPort and DisplayPort submodes
phy: qcom: edp: Add set_mode op for configuring eDP/DP submode
drivers/phy/qualcomm/phy-qcom-edp.c | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++--------------------
include/linux/phy/phy-dp.h | 3 +++
2 files changed, 59 insertions(+), 20 deletions(-)
--
~Vinod
^ permalink raw reply
* [PATCH 1/2] dt-bindings: arm: ti: Add BeagleY-AI
From: Robert Nelson @ 2024-03-28 19:12 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel, devicetree
Cc: Robert Nelson, Rob Herring, Nishanth Menon, Jared McArthur,
Jason Kridner, Deepak Khatri
This board is based on ti,j722s
https://beagley-ai.org/
https://openbeagle.org/beagley-ai/beagley-ai
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
CC: Rob Herring <robh@kernel.org>
CC: Nishanth Menon <nm@ti.com>
CC: Jared McArthur <j-mcarthur@ti.com>
CC: Jason Kridner <jkridner@beagleboard.org>
CC: Deepak Khatri <lorforlinux@beagleboard.org>
---
Documentation/devicetree/bindings/arm/ti/k3.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml b/Documentation/devicetree/bindings/arm/ti/k3.yaml
index 52b51fd7044e..ca23b7e6a35e 100644
--- a/Documentation/devicetree/bindings/arm/ti/k3.yaml
+++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml
@@ -134,6 +134,7 @@ properties:
- description: K3 J722S SoC and Boards
items:
- enum:
+ - beagle,j722s-beagley-ai
- ti,j722s-evm
- const: ti,j722s
--
2.39.2
^ permalink raw reply related
* [PATCH 2/2] arm64: dts: ti: Add k3-j722s-beagley-ai
From: Robert Nelson @ 2024-03-28 19:12 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel, devicetree
Cc: Robert Nelson, Nishanth Menon, Jared McArthur, Jason Kridner,
Deepak Khatri
In-Reply-To: <20240328191205.82295-1-robertcnelson@gmail.com>
BeagleBoard.org BeagleY-AI is an easy to use, affordable open source
hardware single board computer based on the Texas Instruments AM67A,
which features a quad-core 64-bit Arm CPU subsystem, 2 general-purpose
digital-signal-processors (DSP) and matrix-multiply-accelerators (MMA),
GPU, vision and deep learning accelerators, and multiple Arm Cortex-R5
cores for low-power, low-latency GPIO control.
https://beagley-ai.org/
https://openbeagle.org/beagley-ai/beagley-ai
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
CC: Nishanth Menon <nm@ti.com>
CC: Jared McArthur <j-mcarthur@ti.com>
CC: Jason Kridner <jkridner@beagleboard.org>
CC: Deepak Khatri <lorforlinux@beagleboard.org>
---
arch/arm64/boot/dts/ti/Makefile | 1 +
.../arm64/boot/dts/ti/k3-j722s-beagley-ai.dts | 373 ++++++++++++++++++
2 files changed, 374 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-j722s-beagley-ai.dts
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 9a722c2473fb..c76b41f86527 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -95,6 +95,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm.dtb
dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-pcie1-ep.dtbo
# Boards with J722s SoC
+dtb-$(CONFIG_ARCH_K3) += k3-j722s-beagley-ai.dtb
dtb-$(CONFIG_ARCH_K3) += k3-j722s-evm.dtb
# Boards with J784s4 SoC
diff --git a/arch/arm64/boot/dts/ti/k3-j722s-beagley-ai.dts b/arch/arm64/boot/dts/ti/k3-j722s-beagley-ai.dts
new file mode 100644
index 000000000000..a6e5a4243bef
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-j722s-beagley-ai.dts
@@ -0,0 +1,373 @@
+// SPDX-License-Identifier: GPL-2.0-only OR MIT
+/*
+ * https://beagley-ai.org/
+ *
+ * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+ * Copyright (C) 2024 Robert Nelson, BeagleBoard.org Foundation
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/net/ti-dp83867.h>
+#include "k3-j722s.dtsi"
+
+/ {
+ compatible = "beagle,j722s-beagley-ai", "ti,j722s";
+ model = "BeagleBoard.org BeagleY-AI";
+
+ aliases {
+ serial0 = &wkup_uart0;
+ serial2 = &main_uart0;
+ mmc0 = &sdhci1;
+ };
+
+ chosen {
+ stdout-path = &main_uart0;
+ };
+
+ memory@80000000 {
+ /* 4G RAM */
+ reg = <0x00000000 0x80000000 0x00000000 0x80000000>,
+ <0x00000008 0x80000000 0x00000000 0x80000000>;
+ device_type = "memory";
+ bootph-pre-ram;
+ };
+
+ reserved_memory: reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ secure_tfa_ddr: tfa@9e780000 {
+ reg = <0x00 0x9e780000 0x00 0x80000>;
+ no-map;
+ };
+
+ secure_ddr: optee@9e800000 {
+ reg = <0x00 0x9e800000 0x00 0x01800000>;
+ no-map;
+ };
+
+ wkup_r5fss0_core0_memory_region: r5f-memory@a0100000 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0xa0100000 0x00 0xf00000>;
+ no-map;
+ };
+
+ };
+
+ vsys_5v0: regulator-1 {
+ compatible = "regulator-fixed";
+ regulator-name = "vsys_5v0";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ regulator-boot-on;
+ bootph-all;
+ };
+
+ vdd_3v3: regulator-2 {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd_3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vsys_5v0>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vdd_mmc1: regulator-mmc1 {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd_mmc1";
+ pinctrl-names = "default";
+ pinctrl-0 = <&vdd_3v3_sd_pins_default>;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ enable-active-high;
+ gpio = <&main_gpio1 50 GPIO_ACTIVE_HIGH>;
+ bootph-all;
+ };
+
+ vdd_sd_dv: regulator-TLV71033 {
+ compatible = "regulator-gpio";
+ regulator-name = "tlv71033";
+ pinctrl-names = "default";
+ pinctrl-0 = <&vdd_sd_dv_pins_default>;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ vin-supply = <&vsys_5v0>;
+ gpios = <&main_gpio1 49 GPIO_ACTIVE_HIGH>;
+ states = <1800000 0x0>,
+ <3300000 0x1>;
+ };
+
+ vsys_io_1v8: regulator-vsys-io-1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "vsys_io_1v8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vsys_io_1v2: regulator-vsys-io-1v2 {
+ compatible = "regulator-fixed";
+ regulator-name = "vsys_io_1v2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+};
+
+&main_pmx0 {
+
+ main_i2c0_pins_default: main-i2c0-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x01e0, PIN_INPUT_PULLUP, 0) /* (D23) I2C0_SCL */
+ J722S_IOPAD(0x01e4, PIN_INPUT_PULLUP, 0) /* (B22) I2C0_SDA */
+ >;
+ bootph-all;
+ };
+
+ main_uart0_pins_default: main-uart0-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x01c8, PIN_INPUT, 0) /* (A22) UART0_RXD */
+ J722S_IOPAD(0x01cc, PIN_OUTPUT, 0) /* (B22) UART0_TXD */
+ >;
+ bootph-all;
+ };
+
+ vdd_sd_dv_pins_default: vdd-sd-dv-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x0244, PIN_OUTPUT, 7) /* (A24) MMC1_SDWP.GPIO1_49 */
+ >;
+ bootph-all;
+ };
+
+ main_mmc1_pins_default: main-mmc1-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x023c, PIN_INPUT, 0) /* (H22) MMC1_CMD */
+ J722S_IOPAD(0x0234, PIN_OUTPUT, 0) /* (H24) MMC1_CLK */
+ J722S_IOPAD(0x0230, PIN_INPUT, 0) /* (H23) MMC1_DAT0 */
+ J722S_IOPAD(0x022c, PIN_INPUT_PULLUP, 0) /* (H20) MMC1_DAT1 */
+ J722S_IOPAD(0x0228, PIN_INPUT_PULLUP, 0) /* (J23) MMC1_DAT2 */
+ J722S_IOPAD(0x0224, PIN_INPUT_PULLUP, 0) /* (H25) MMC1_DAT3 */
+ J722S_IOPAD(0x0240, PIN_INPUT, 0) /* (B24) MMC1_SDCD */
+ >;
+ bootph-all;
+ };
+
+ mdio_pins_default: mdio-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x0160, PIN_OUTPUT, 0) /* (AC24) MDIO0_MDC */
+ J722S_IOPAD(0x015c, PIN_INPUT, 0) /* (AD25) MDIO0_MDIO */
+ >;
+ };
+
+ rgmii1_pins_default: rgmii1-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x014c, PIN_INPUT, 0) /* (AC25) RGMII1_RD0 */
+ J722S_IOPAD(0x0150, PIN_INPUT, 0) /* (AD27) RGMII1_RD1 */
+ J722S_IOPAD(0x0154, PIN_INPUT, 0) /* (AE24) RGMII1_RD2 */
+ J722S_IOPAD(0x0158, PIN_INPUT, 0) /* (AE26) RGMII1_RD3 */
+ J722S_IOPAD(0x0148, PIN_INPUT, 0) /* (AE27) RGMII1_RXC */
+ J722S_IOPAD(0x0144, PIN_INPUT, 0) /* (AD23) RGMII1_RX_CTL */
+ J722S_IOPAD(0x0134, PIN_OUTPUT, 0) /* (AF27) RGMII1_TD0 */
+ J722S_IOPAD(0x0138, PIN_OUTPUT, 0) /* (AE23) RGMII1_TD1 */
+ J722S_IOPAD(0x013c, PIN_OUTPUT, 0) /* (AG25) RGMII1_TD2 */
+ J722S_IOPAD(0x0140, PIN_OUTPUT, 0) /* (AF24) RGMII1_TD3 */
+ J722S_IOPAD(0x0130, PIN_OUTPUT, 0) /* (AG26) RGMII1_TXC */
+ J722S_IOPAD(0x012c, PIN_OUTPUT, 0) /* (AF25) RGMII1_TX_CTL */
+ >;
+ };
+
+ pmic_irq_pins_default: pmic-irq-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x01f4, PIN_INPUT_PULLUP, 0) /* (B23) EXTINTn */
+ >;
+ };
+
+ vdd_3v3_sd_pins_default: vdd-3v3-sd-pins-default {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x0254, PIN_OUTPUT, 7) /* (E25) USB0_DRVVBUS.GPIO1_50 */
+ >;
+ };
+};
+
+&cpsw3g {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgmii1_pins_default>, <&gbe_pmx_obsclk>;
+
+ assigned-clocks = <&k3_clks 227 0>;
+ assigned-clock-parents = <&k3_clks 227 6>;
+};
+
+&cpsw3g_mdio {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&mdio_pins_default>;
+
+ cpsw3g_phy0: ethernet-phy@0 {
+ reg = <0>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
+ ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
+ ti,min-output-impedance;
+ };
+};
+
+&cpsw_port1 {
+ phy-mode = "rgmii-rxid";
+ phy-handle = <&cpsw3g_phy0>;
+};
+
+&cpsw_port2 {
+ status = "disabled";
+};
+
+&main_gpio1 {
+ status = "okay";
+};
+
+&main_uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_uart0_pins_default>;
+ status = "okay";
+ bootph-all;
+};
+
+&mcu_pmx0 {
+
+ wkup_uart0_pins_default: wkup-uart0-default-pins {
+ pinctrl-single,pins = <
+ J722S_MCU_IOPAD(0x02c, PIN_INPUT, 0) /* (C7) WKUP_UART0_CTSn */
+ J722S_MCU_IOPAD(0x030, PIN_OUTPUT, 0) /* (C6) WKUP_UART0_RTSn */
+ J722S_MCU_IOPAD(0x024, PIN_INPUT, 0) /* (D8) WKUP_UART0_RXD */
+ J722S_MCU_IOPAD(0x028, PIN_OUTPUT, 0) /* (D7) WKUP_UART0_TXD */
+ >;
+ bootph-all;
+ };
+
+ wkup_i2c0_pins_default: wkup-i2c0-default-pins {
+ pinctrl-single,pins = <
+ J722S_MCU_IOPAD(0x04c, PIN_INPUT_PULLUP, 0) /* (C7) WKUP_I2C0_SCL */
+ J722S_MCU_IOPAD(0x050, PIN_INPUT_PULLUP, 0) /* (C6) WKUP_I2C1_SDA */
+ >;
+ bootph-all;
+ };
+
+ gbe_pmx_obsclk: gbe-pmx-obsclk-default-pins {
+ pinctrl-single,pins = <
+ J722S_MCU_IOPAD(0x0004, PIN_OUTPUT, 1) /* (A10) MCU_SPI0_CS1.MCU_OBSCLK0 */
+ >;
+ };
+};
+
+&wkup_uart0 {
+ /* WKUP UART0 is used by Device Manager firmware */
+ pinctrl-names = "default";
+ pinctrl-0 = <&wkup_uart0_pins_default>;
+ status = "reserved";
+ bootph-all;
+};
+
+&wkup_i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&wkup_i2c0_pins_default>;
+ clock-frequency = <400000>;
+ status = "okay";
+ bootph-all;
+
+ tps65219: pmic@30 {
+ bootph-all;
+ compatible = "ti,tps65219";
+ reg = <0x30>;
+ buck1-supply = <&vsys_5v0>;
+ buck2-supply = <&vsys_5v0>;
+ buck3-supply = <&vsys_5v0>;
+ ldo1-supply = <&vdd_3v3>;
+ ldo3-supply = <&vdd_3v3>;
+ ldo4-supply = <&vdd_3v3>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_irq_pins_default>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 224 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ system-power-controller;
+ ti,power-button;
+
+ regulators {
+ buck1_reg: buck1 {
+ regulator-name = "VDD_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ buck2_reg: buck2 {
+ regulator-name = "VDD_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ buck3_reg: buck3 {
+ regulator-name = "VDD_1V1";
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo1_reg: ldo1 {
+ regulator-name = "VDDSHV5_SDIO";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-allow-bypass;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo2_reg: ldo2 {
+ //Regulator is left as is unused.
+ };
+
+ ldo3_reg: ldo3 {
+ regulator-name = "VDDA_PHY_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo4_reg: ldo4 {
+ regulator-name = "VDDA_PLL_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+ };
+};
+
+&sdhci1 {
+ /* SD/MMC */
+ vmmc-supply = <&vdd_mmc1>;
+ vqmmc-supply = <&vdd_sd_dv>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_mmc1_pins_default>;
+ ti,driver-strength-ohm = <50>;
+ disable-wp;
+ no-1-8-v;
+ status = "okay";
+ bootph-all;
+};
--
2.39.2
^ permalink raw reply related
* [PATCH v2 0/2] thermal: amlogic: introduce A1 SoC family Thermal Sensor controller
From: Dmitry Rokosov @ 2024-03-28 19:13 UTC (permalink / raw)
To: neil.armstrong, jbrunet, mturquette, khilman, martin.blumenstingl,
glaroque, rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh+dt,
krzysztof.kozlowski+dt, conor+dt
Cc: kernel, rockosov, linux-amlogic, linux-pm, linux-kernel,
devicetree, linux-arm-kernel, Dmitry Rokosov
It is primarily based on the G12A thermal controller, with only a slight
variation in the offset value of the efuse parameters. Therefore, this
patch series provides appropriate platform data and dt-bindings to
ensure proper support.
Changes v2 since v1 at [1]:
- provide Neil RvB
- remove 'amlogic,a1-thermal' fallback, cause it's not needed
Links:
[1] https://lore.kernel.org/all/20240328133802.15651-1-ddrokosov@salutedevices.com/
Dmitry Rokosov (2):
dt-bindings: thermal: amlogic: add support for A1 thermal sensor
thermal: amlogic: support A1 SoC family Thermal Sensor controller
.../devicetree/bindings/thermal/amlogic,thermal.yaml | 12 +++++++-----
drivers/thermal/amlogic_thermal.c | 10 ++++++++++
2 files changed, 17 insertions(+), 5 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: thermal: amlogic: add support for A1 thermal sensor
From: Dmitry Rokosov @ 2024-03-28 19:13 UTC (permalink / raw)
To: neil.armstrong, jbrunet, mturquette, khilman, martin.blumenstingl,
glaroque, rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh+dt,
krzysztof.kozlowski+dt, conor+dt
Cc: kernel, rockosov, linux-amlogic, linux-pm, linux-kernel,
devicetree, linux-arm-kernel, Dmitry Rokosov
In-Reply-To: <20240328191322.17551-1-ddrokosov@salutedevices.com>
Provide right compatible properties for Amlogic A1 Thermal Sensor
controller. A1 family supports only one thermal node - CPU thermal
sensor.
Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
---
.../devicetree/bindings/thermal/amlogic,thermal.yaml | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
index 20f8f9b3b971..01fccdfc4178 100644
--- a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
@@ -13,11 +13,13 @@ description: Binding for Amlogic Thermal
properties:
compatible:
- items:
- - enum:
- - amlogic,g12a-cpu-thermal
- - amlogic,g12a-ddr-thermal
- - const: amlogic,g12a-thermal
+ oneOf:
+ - items:
+ - enum:
+ - amlogic,g12a-cpu-thermal
+ - amlogic,g12a-ddr-thermal
+ - const: amlogic,g12a-thermal
+ - const: amlogic,a1-cpu-thermal
reg:
maxItems: 1
--
2.43.0
^ permalink raw reply related
* [PATCH v2 2/2] thermal: amlogic: support A1 SoC family Thermal Sensor controller
From: Dmitry Rokosov @ 2024-03-28 19:13 UTC (permalink / raw)
To: neil.armstrong, jbrunet, mturquette, khilman, martin.blumenstingl,
glaroque, rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh+dt,
krzysztof.kozlowski+dt, conor+dt
Cc: kernel, rockosov, linux-amlogic, linux-pm, linux-kernel,
devicetree, linux-arm-kernel, Dmitry Rokosov
In-Reply-To: <20240328191322.17551-1-ddrokosov@salutedevices.com>
In comparison to other Amlogic chips, there is one key difference.
The offset for the sec_ao base, also known as u_efuse_off, is special,
while other aspects remain the same.
Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
---
drivers/thermal/amlogic_thermal.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/thermal/amlogic_thermal.c b/drivers/thermal/amlogic_thermal.c
index 5877cde25b79..1d23afd32013 100644
--- a/drivers/thermal/amlogic_thermal.c
+++ b/drivers/thermal/amlogic_thermal.c
@@ -222,6 +222,12 @@ static const struct amlogic_thermal_data amlogic_thermal_g12a_ddr_param = {
.regmap_config = &amlogic_thermal_regmap_config_g12a,
};
+static const struct amlogic_thermal_data amlogic_thermal_a1_cpu_param = {
+ .u_efuse_off = 0x114,
+ .calibration_parameters = &amlogic_thermal_g12a,
+ .regmap_config = &amlogic_thermal_regmap_config_g12a,
+};
+
static const struct of_device_id of_amlogic_thermal_match[] = {
{
.compatible = "amlogic,g12a-ddr-thermal",
@@ -231,6 +237,10 @@ static const struct of_device_id of_amlogic_thermal_match[] = {
.compatible = "amlogic,g12a-cpu-thermal",
.data = &amlogic_thermal_g12a_cpu_param,
},
+ {
+ .compatible = "amlogic,a1-cpu-thermal",
+ .data = &amlogic_thermal_a1_cpu_param,
+ },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, of_amlogic_thermal_match);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 2/2] arm64: dts: ti: Add k3-j722s-beagley-ai
From: Robert Nelson @ 2024-03-28 19:15 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel, devicetree
Cc: Nishanth Menon, Jared McArthur, Jason Kridner, Deepak Khatri
In-Reply-To: <20240328191205.82295-2-robertcnelson@gmail.com>
On Thu, Mar 28, 2024 at 2:12 PM Robert Nelson <robertcnelson@gmail.com> wrote:
>
> BeagleBoard.org BeagleY-AI is an easy to use, affordable open source
> hardware single board computer based on the Texas Instruments AM67A,
> which features a quad-core 64-bit Arm CPU subsystem, 2 general-purpose
> digital-signal-processors (DSP) and matrix-multiply-accelerators (MMA),
> GPU, vision and deep learning accelerators, and multiple Arm Cortex-R5
> cores for low-power, low-latency GPIO control.
>
> https://beagley-ai.org/
> https://openbeagle.org/beagley-ai/beagley-ai
@Jason Kridner we need this to become public when you are ready ^ ;)
Boot log:
https://gist.github.com/RobertCNelson/9db8ea04848e7ce2ca52c038fab0e1b7
--
Robert Nelson
https://rcn-ee.com/
^ permalink raw reply
* Re: [PATCH 18/23] dt-bindings: media: imx258: Add alternate compatible strings
From: Luigi311 @ 2024-03-28 19:16 UTC (permalink / raw)
To: Rob Herring
Cc: linux-media, dave.stevenson, jacopo.mondi, mchehab,
krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer, kernel,
festevam, sakari.ailus, devicetree, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <20240328185526.GA88354-robh@kernel.org>
On 3/28/24 12:55, Rob Herring wrote:
> On Wed, Mar 27, 2024 at 05:17:04PM -0600, git@luigi311.com wrote:
>> From: Dave Stevenson <dave.stevenson@raspberrypi.com>
>>
>> There are a number of variants of the imx258 modules that can not
>> be differentiated at runtime, so add compatible strings for them.
>> But you are only adding 1 variant.
I can not speak for Dave but as to why this was added here but looking
at the imx296 yaml that has something similar where there are multiple
variants that may not be detectable at run time but does not include
similar verbiage in the main description. Should I drop this from the
description so it matches the imx296?
>
>>
>> Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
>> Signed-off-by: Luigi311 <git@luigi311.com>
>> ---
>> .../devicetree/bindings/media/i2c/sony,imx258.yaml | 6 +++++-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
>> index bee61a443b23..c7856de15ba3 100644
>> --- a/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
>> +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
>> @@ -14,10 +14,14 @@ description: |-
>> type stacked image sensor with a square pixel array of size 4208 x 3120. It
>> is programmable through I2C interface. Image data is sent through MIPI
>> CSI-2.
>> + There are a number of variants of the sensor which cannot be detected at
>> + runtime, so multiple compatible strings are required to differentiate these.
>
> That's more reasoning/why for the patch than description of the h/w.
>
>> properties:
>> compatible:
>> - const: sony,imx258
>> + - enum:
>> + - sony,imx258
>> + - sony,imx258-pdaf
>
> How do I know which one to use? Please define what PDAF means somewhere
> as well as perhaps what the original/default variant is or isn't.
Would it make sense to change the properties to include a description like so
properties:
compatible:
enum:
- sony,imx258
- sony,imx258-pdaf
description:
The IMX258 sensor exists in two different models, a standard variant
(IMX258) and a variant with phase detection autofocus (IMX258-PDAF).
The camera module does not expose the model through registers, so the
exact model needs to be specified.
>
>>
>> assigned-clocks: true
>> assigned-clock-parents: true
>> --
>> 2.42.0
>>
^ permalink raw reply
* Re: [PATCH RESEND v5 0/2] phy: qcom: edp: Allow eDP/DP configuring via set_mode op
From: Vinod Koul @ 2024-03-28 19:18 UTC (permalink / raw)
To: Kishon Vijay Abraham I, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dmitry Baryshkov,
Johan Hovold, Abel Vesa
Cc: linux-phy, linux-kernel, linux-arm-msm, devicetree
In-Reply-To: <20240324-x1e80100-phy-edp-compatible-refactor-v5-0-a0db5f3150bc@linaro.org>
On Sun, 24 Mar 2024 20:50:16 +0200, Abel Vesa wrote:
> Until now, all platform that supported both eDP and DP had different
> compatibles for each mode. Using different compatibles for basically
> the same IP block but for a different configuration is bad way all
> around. There is a new compute platform from Qualcomm that supports
> both eDP and DP with the same PHY. So instead of following the old
> method, we should allow the submode to be configured via set_mode from
> the controller driver.
>
> [...]
Applied, thanks!
[1/2] phy: Add Embedded DisplayPort and DisplayPort submodes
commit: 368d67dab4cc4a3ffd39fbd062b2f5796cdbb37b
[2/2] phy: qcom: edp: Add set_mode op for configuring eDP/DP submode
commit: 6078b8ce070cad3f9a8ecfce65d0f6d595494f02
Best regards,
--
~Vinod
^ permalink raw reply
* Re: (subset) [PATCH V7 0/6] soc: imx8mp: Finish support for HDMI
From: Vinod Koul @ 2024-03-28 19:19 UTC (permalink / raw)
To: linux-arm-kernel, linux-phy, Adam Ford
Cc: aford, Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Catalin Marinas, Will Deacon, Lucas Stach,
devicetree, imx, linux-kernel
In-Reply-To: <20240227220444.77566-1-aford173@gmail.com>
On Tue, 27 Feb 2024 16:04:34 -0600, Adam Ford wrote:
> The i.MX8M Plus has an HDMI controller, which depends on several
> other systems. The Parallel Video Interface (PVI) and the
> HDMI-TX are already in the Linux-Next staging area 20240209, but
> the HDMI PHY driver and several device trees updates are still needed.
>
> This series is adapted from multiple series from Lucas Stach with
> edits and suggestions from feedback from various attempts, but it
> since it's difficult to use and test them independently,
> I merged them into on unified series. The version history is a
> bit ambiguous since different components were submitted at different
> times and had different amount of attempts.
>
> [...]
Applied, thanks!
[1/6] dt-bindings: phy: add binding for the i.MX8MP HDMI PHY
commit: d0f4b70eb9a9ed05a37d963655698906cd4dac9a
[2/6] phy: freescale: add Samsung HDMI PHY
commit: 6ad082bee9025fa8e0ef8ee478c5a614b9db9e3d
Best regards,
--
~Vinod
^ permalink raw reply
* Re: [PATCH v2 0/2] phy: qcom: eusb2-repeater: Add support for SMB2360
From: Vinod Koul @ 2024-03-28 19:19 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Kishon Vijay Abraham I,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Abel Vesa
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Krzysztof Kozlowski, Dmitry Baryshkov
In-Reply-To: <20240220-phy-qualcomm-eusb2-repeater-smb2360-v2-0-213338ca1d5f@linaro.org>
On Tue, 20 Feb 2024 21:41:58 +0200, Abel Vesa wrote:
> This patchset adds support for the eUSB2 repeater provided
> by the SMB2360 PMICs.
>
>
Applied, thanks!
[1/2] dt-bindings: phy: qcom,snps-eusb2-repeater: Add compatible for SMB2360
commit: f8d27a7e0ae36c204bffe4992043b2bb42ca8580
[2/2] phy: qualcomm: phy-qcom-eusb2-repeater: Add support for SMB2360
commit: 67076749e093ffb3c82ba6225d41c88f8c816472
Best regards,
--
~Vinod
^ permalink raw reply
* Re: [PATCH v4 0/3] phy: qcom: edp: Add support for X1E80100
From: Vinod Koul @ 2024-03-28 19:19 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Konrad Dybcio,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Abhinav Kumar, Dmitry Baryshkov, Johan Hovold,
Rob Herring, Abel Vesa
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <20240221-phy-qualcomm-edp-x1e80100-v4-0-4e5018877bee@linaro.org>
On Wed, 21 Feb 2024 00:05:20 +0200, Abel Vesa wrote:
> This patchset moves the v4 specific bits into version specific ops,
> adds the v6 specific version ops and the compatible for X1E80100.
>
> This patchset is dependent on:
> [1] https://lore.kernel.org/all/20240220-x1e80100-phy-edp-compatible-refactor-v5-0-e8658adf5461@linaro.org/
>
> To: Andy Gross <agross@kernel.org>
> To: Bjorn Andersson <andersson@kernel.org>
> To: Konrad Dybcio <konrad.dybcio@linaro.org>
> To: Vinod Koul <vkoul@kernel.org>
> To: Kishon Vijay Abraham I <kishon@kernel.org>
> To: Rob Herring <robh+dt@kernel.org>
> To: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
> To: Conor Dooley <conor+dt@kernel.org>
> To: Abhinav Kumar <quic_abhinavk@quicinc.com>
> To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> To: Johan Hovold <johan@kernel.org>
> To: Rob Herring <robh@kernel.org>
> Cc: linux-arm-msm@vger.kernel.org
> Cc: linux-phy@lists.infradead.org
> Cc: devicetree@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
>
> [...]
Applied, thanks!
[1/3] dt-bindings: phy: qcom-edp: Add X1E80100 PHY compatibles
commit: 5d5607861350db4020b3d74c02837ffc008701d9
[2/3] phy: qcom: edp: Move v4 specific settings to version ops
commit: 9eb8e3dd297f976aec24e07c5e3ca1e79629140b
[3/3] phy: qcom: edp: Add v6 specific ops and X1E80100 platform support
commit: db83c107dc295a6d26727917dc62baa91a1bf989
Best regards,
--
~Vinod
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: ti: Add k3-j722s-beagley-ai
From: Jason Kridner @ 2024-03-28 19:26 UTC (permalink / raw)
To: Robert Nelson
Cc: linux-arm-kernel, linux-kernel, devicetree, Nishanth Menon,
Jared McArthur, Deepak Khatri
In-Reply-To: <CAOCHtYiSYat771sfx-Pdv59GDUBH_TzqkxUM+BMf0Q7Z0KEC9A@mail.gmail.com>
> On Mar 28, 2024, at 9:16 AM, Robert Nelson <robertcnelson@gmail.com> wrote:
>
> On Thu, Mar 28, 2024 at 2:12 PM Robert Nelson <robertcnelson@gmail.com> wrote:
>>
>> BeagleBoard.org BeagleY-AI is an easy to use, affordable open source
>> hardware single board computer based on the Texas Instruments AM67A,
>> which features a quad-core 64-bit Arm CPU subsystem, 2 general-purpose
>> digital-signal-processors (DSP) and matrix-multiply-accelerators (MMA),
>> GPU, vision and deep learning accelerators, and multiple Arm Cortex-R5
>> cores for low-power, low-latency GPIO control.
>>
>> https://beagley-ai.org/
>> https://openbeagle.org/beagley-ai/beagley-ai
>
> @Jason Kridner we need this to become public when you are ready ^ ;)
>
Did I mess up? Should already be public. We should make a github.com mirror though for up-time/visibility/bandwidth.
> Boot log:
>
> https://gist.github.com/RobertCNelson/9db8ea04848e7ce2ca52c038fab0e1b7
>
> --
> Robert Nelson
> https://rcn-ee.com/
^ permalink raw reply
* [PATCH v2 0/3] arm64: dts: amlogic: a1: introduce thermal setup
From: Dmitry Rokosov @ 2024-03-28 19:26 UTC (permalink / raw)
To: neil.armstrong, jbrunet, mturquette, khilman, martin.blumenstingl,
glaroque, rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh+dt,
krzysztof.kozlowski+dt, conor+dt
Cc: kernel, rockosov, linux-amlogic, linux-pm, linux-kernel,
devicetree, linux-arm-kernel, Dmitry Rokosov
This patch series introduces thermal sensor declaration to the Meson A1
common dtsi file. It also sets up thermal zones for the AD402 reference
board. It depends on the series with A1 thermal support at [1].
Changes v2 since v1 at [2]:
- provide Neil RvB for cooling-cells dts patch
- purge unnecessary 'amlogic,a1-thermal' fallback
Links:
[1] - https://lore.kernel.org/all/20240328191322.17551-1-ddrokosov@salutedevices.com/
[2] - https://lore.kernel.org/all/20240328134459.18446-1-ddrokosov@salutedevices.com/
Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
Dmitry Rokosov (3):
arm64: dts: amlogic: a1: add cooling-cells for DVFS feature
arm64: dts: amlogic: a1: introduce cpu temperature sensor
arm64: dts: amlogic: ad402: setup thermal-zones
.../arm64/boot/dts/amlogic/meson-a1-ad402.dts | 45 +++++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-a1.dtsi | 13 ++++++
2 files changed, 58 insertions(+)
--
2.43.0
^ permalink raw reply
* [PATCH v2 1/3] arm64: dts: amlogic: a1: add cooling-cells for DVFS feature
From: Dmitry Rokosov @ 2024-03-28 19:26 UTC (permalink / raw)
To: neil.armstrong, jbrunet, mturquette, khilman, martin.blumenstingl,
glaroque, rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh+dt,
krzysztof.kozlowski+dt, conor+dt
Cc: kernel, rockosov, linux-amlogic, linux-pm, linux-kernel,
devicetree, linux-arm-kernel, Dmitry Rokosov
In-Reply-To: <20240328192645.20914-1-ddrokosov@salutedevices.com>
It's used for CPU with DVFS feature to specify minimum and maximum
cooling state used in the reference.
Without these values DVFS will not work and dtbs_check will raise the
error.
Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
---
arch/arm64/boot/dts/amlogic/meson-a1.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-a1.dtsi b/arch/arm64/boot/dts/amlogic/meson-a1.dtsi
index fbee986421f1..f65d4a77ee52 100644
--- a/arch/arm64/boot/dts/amlogic/meson-a1.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-a1.dtsi
@@ -32,6 +32,7 @@ cpu0: cpu@0 {
reg = <0x0 0x0>;
enable-method = "psci";
next-level-cache = <&l2>;
+ #cooling-cells = <2>;
};
cpu1: cpu@1 {
@@ -40,6 +41,7 @@ cpu1: cpu@1 {
reg = <0x0 0x1>;
enable-method = "psci";
next-level-cache = <&l2>;
+ #cooling-cells = <2>;
};
l2: l2-cache0 {
--
2.43.0
^ permalink raw reply related
* [PATCH v2 2/3] arm64: dts: amlogic: a1: introduce cpu temperature sensor
From: Dmitry Rokosov @ 2024-03-28 19:26 UTC (permalink / raw)
To: neil.armstrong, jbrunet, mturquette, khilman, martin.blumenstingl,
glaroque, rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh+dt,
krzysztof.kozlowski+dt, conor+dt
Cc: kernel, rockosov, linux-amlogic, linux-pm, linux-kernel,
devicetree, linux-arm-kernel, Dmitry Rokosov
In-Reply-To: <20240328192645.20914-1-ddrokosov@salutedevices.com>
The A1 SoC family has only one thermal sensor for CPU temperature
measurement. It is required to set the TS clock rate to 500kHz to make
it workable.
Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
---
arch/arm64/boot/dts/amlogic/meson-a1.dtsi | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-a1.dtsi b/arch/arm64/boot/dts/amlogic/meson-a1.dtsi
index f65d4a77ee52..de77eb53d1dc 100644
--- a/arch/arm64/boot/dts/amlogic/meson-a1.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-a1.dtsi
@@ -854,6 +854,17 @@ usb2_phy1: phy@4000 {
power-domains = <&pwrc PWRC_USB_ID>;
};
+ cpu_temp: temperature-sensor@4c00 {
+ compatible = "amlogic,a1-cpu-thermal";
+ reg = <0x0 0x4c00 0x0 0x50>;
+ interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc_periphs CLKID_TS>;
+ assigned-clocks = <&clkc_periphs CLKID_TS>;
+ assigned-clock-rates = <500000>;
+ #thermal-sensor-cells = <0>;
+ amlogic,ao-secure = <&sec_AO>;
+ };
+
hwrng: rng@5118 {
compatible = "amlogic,meson-rng";
reg = <0x0 0x5118 0x0 0x4>;
--
2.43.0
^ 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