* Re: [PATCH v16 8/9] usb: dwc3: qcom: Enable wakeup for applicable ports of multiport
From: Johan Hovold @ 2024-03-25 12:50 UTC (permalink / raw)
To: Krishna Kurapati
Cc: Krzysztof Kozlowski, Rob Herring, Bjorn Andersson, Wesley Cheng,
Konrad Dybcio, Greg Kroah-Hartman, Conor Dooley, Thinh Nguyen,
Felipe Balbi, devicetree, linux-arm-msm, linux-usb, linux-kernel,
quic_ppratap, quic_jackp
In-Reply-To: <20240307062052.2319851-9-quic_kriskura@quicinc.com>
On Thu, Mar 07, 2024 at 11:50:51AM +0530, Krishna Kurapati wrote:
> DWC3 Qcom wrapper currently supports only wakeup configuration
> for single port controllers. Read speed of each port connected
> to the controller and enable wakeup for each of them accordingly.
>
> Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
^ permalink raw reply
* Re: [PATCH v16 7/9] usb: dwc3: qcom: Refactor IRQ handling in glue driver
From: Johan Hovold @ 2024-03-25 12:48 UTC (permalink / raw)
To: Krishna Kurapati
Cc: Krzysztof Kozlowski, Rob Herring, Bjorn Andersson, Wesley Cheng,
Konrad Dybcio, Greg Kroah-Hartman, Conor Dooley, Thinh Nguyen,
Felipe Balbi, devicetree, linux-arm-msm, linux-usb, linux-kernel,
quic_ppratap, quic_jackp
In-Reply-To: <20240307062052.2319851-8-quic_kriskura@quicinc.com>
On Thu, Mar 07, 2024 at 11:50:50AM +0530, Krishna Kurapati wrote:
> On multiport supported controllers, each port has its own DP/DM
> and SS (if super speed capable) interrupts. As per the bindings,
> their interrupt names differ from standard ones having "_x" added
> as suffix (x indicates port number). Identify from the interrupt
> names whether the controller is a multiport controller or not.
> Refactor dwc3_qcom_setup_irq() call to parse multiport interrupts
> along with non-multiport ones accordingly..
>
> Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
> ---
> drivers/usb/dwc3/dwc3-qcom.c | 146 +++++++++++++++++++++++++++--------
> 1 file changed, 112 insertions(+), 34 deletions(-)
This is much better. Just a couple of nits below.
> +static int dwc3_qcom_find_num_ports(struct platform_device *pdev)
> +{
> + const char *irq_name;
> + int port_index;
> + int irq;
> +
> + irq = platform_get_irq_byname_optional(pdev, "qusb2_phy");
> + if (irq > 0)
> + return 1;
> +
> + irq = platform_get_irq_byname_optional(pdev, "dp_hs_phy_irq");
> + if (irq > 0)
> + return 1;
> +
> + for (port_index = 0; port_index < DWC3_MAX_PORTS; port_index++) {
> + irq_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, "dp_hs_phy_%d", port_index + 1);
Please use a stack allocated buffer for these strings as we don't need
them any more after this function returns.
> + if (!irq_name)
> + return -ENOMEM;
> +
> + irq = platform_get_irq_byname_optional(pdev, irq_name);
> + if (irq <= 0)
> + return port_index;
> + }
> +
> + return port_index;
I think explicitly returning DWC3_MAX_PORTS here would be more readable.
> +}
> +
> +static int dwc3_qcom_setup_irq(struct platform_device *pdev)
> +{
> + struct dwc3_qcom *qcom = platform_get_drvdata(pdev);
> + bool is_multiport;
> + int ret;
> + int i;
> +
> + qcom->num_ports = dwc3_qcom_find_num_ports(pdev);
> + if (qcom->num_ports < 0)
> + return -ENOMEM;
Just return 'ret' directly.
> +
> + is_multiport = (qcom->num_ports > 1) ? true : false;
And no need for the ternary operator:
is_multiport = (qcom->num_ports > 1);
> +
> + for (i = 0; i < qcom->num_ports; i++) {
> + ret = dwc3_qcom_setup_port_irq(pdev, i, is_multiport);
> if (ret)
> return ret;
> - qcom->ss_phy_irq = irq;
> }
>
> return 0;
With that fixed:
Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 5/7] ARM: dts: samsung: exynos5433: specify the SPI FIFO depth
From: Tudor Ambarus @ 2024-03-25 12:45 UTC (permalink / raw)
To: Krzysztof Kozlowski, krzysztof.kozlowski+dt, robh, conor+dt
Cc: alim.akhtar, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel, broonie, andi.shyti, semen.protsenko, kernel-team,
willmcvicker, andre.draszik, peter.griffin
In-Reply-To: <1d9f160f-e155-4d2b-b598-d1dc76e49110@linaro.org>
On 3/25/24 11:13, Krzysztof Kozlowski wrote:
>> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 5 +++++
> This and next one has wrong subject prefix. I fixed it.
ah, s/arm/arm64. Thank you!
^ permalink raw reply
* Re: [RFC PATCH 2/2] mfd: rohm-bd71828: Add power off functionality
From: Matti Vaittinen @ 2024-03-25 12:44 UTC (permalink / raw)
To: Andreas Kemnade
Cc: lee, robh+dt, krzysztof.kozlowski+dt, conor+dt, devicetree,
linux-kernel, imx
In-Reply-To: <20240325131605.6607b778@aktux>
Hi Andreas,
On 3/25/24 14:16, Andreas Kemnade wrote:
> On Mon, 25 Mar 2024 13:31:15 +0200
> Matti Vaittinen <mazziesaccount@gmail.com> wrote:
>
>> On 3/24/24 22:12, Andreas Kemnade wrote:
>>> Since the chip can power off the system, add the corresponding
>>> functionality.
>>> Based on https://github.com/kobolabs/Kobo-Reader/raw/master/hw/imx6sll-clara2e/kernel.tar.bz2
>>> No information source about the magic numbers found.
>>
>> Oh, interesting repository :) Thanks for linking to it! I didn't know
>> someone had reworked this driver...
>>
> which btw: contains this interesting snippet (output from fdtdump)
> bd71828-i2c@4b {
> reg = <0x0000004b>;
> compatible = "rohm,bd71828";
> gpio_int = <0x00000008 0x00000013 0x00000001>;
> gpio_wdogb = <0x00000039 0x00000018 0x00000001>;
> #address-cells = <0x00000001>;
> #size-cells = <0x00000000>;
> pmic@4b {
> compatible = "rohm,bd71828";
> regulators {
> BUCK1 {
> regulator-name = "buck1";
>
>
> and to make it work since basically no regulators are registered
> instead just some regmap_write()s are done to configure something
> in probe(). It is a pitfall to think that the information below pmic@4b
> is used, especially since it is not that obvious in the source.
Just to ensure there will be no misunderstanding - I have not authored
the modifications seen in "Kobo-Reader" repository. Upstream driver does
register the regulators - and it does not use the oddly named gpio_int
or the gpio_wdogb:
https://elixir.bootlin.com/linux/v6.9-rc1/source/drivers/regulator/bd71828-regulator.c#L750
>> I have access to the data-sheets so I also have some pieces of
>> information. I hope I can clarify part of the puzzle. Unfortunately I
>> have no information about the magic delays. I guess I could try asking
>> though.
>>
>> Oh, it seems to me this handler is only working on BD71828, not on
>> BD71815. So, it should be tied to the ROHM_CHIP_TYPE_BD71828.
>>
>>> Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
>>> ---
>>> drivers/mfd/rohm-bd71828.c | 31 ++++++++++++++++++++++++++++++-
>>> 1 file changed, 30 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mfd/rohm-bd71828.c b/drivers/mfd/rohm-bd71828.c
>>> index 594718f7e8e1..5a55aa3620d0 100644
>>> --- a/drivers/mfd/rohm-bd71828.c
>>> +++ b/drivers/mfd/rohm-bd71828.c
>>> @@ -464,6 +464,24 @@ static int set_clk_mode(struct device *dev, struct regmap *regmap,
>>> OUT32K_MODE_CMOS);
>>> }
>>>
>>> +static struct i2c_client *bd71828_dev;
>>
>> I'm not sure why to store pointer to the device and not a pointer to the
>> regmap?
>>
>>> +static void bd71828_power_off(void)
>>> +{
>>> + i2c_smbus_write_byte_data(bd71828_dev, 0x03, 0xff);
>>
>> 0x03 is a "reset reason" - register. Spec I have states that the
>> register should clear when a reset occurs - but it also says the bits
>> are "write '1' to clear". So, for some reason(?), this clears the
>> previous reset reason.
>
> well, so just check in bootloader what the reset reason is and check if
> there is anything odd.
I understand why bootloader would check this register - but I don't
understand why the driver would clear it as it should be cleared by
reset (unless I missread the spec).
>> I am unsure why i2c_smbus_write_byte_data() and
>> not regmap()?
>>
> regmap involves mutex_lock() and we are not allowed to sleep here.
Right. It makes perfect sense now. Thanks! (Do you think it's worth a
comment?)
>>> + mdelay(500);
>>> + i2c_smbus_write_byte_data(bd71828_dev, BD71828_REG_INT_DCIN2, 0x02);
>>
>> This clears the DCIN monitoring status bit from the IRQ status register.
>> I don't understand the purpose though.
>>
> so maybe something to prevent power on by just plugging a usb cable? Will
> experiment a bit with it.
I still think this is odd because, if I read it right, this is an IRQ
status and not a mask register. Well, wouldn't be a first undocumented
"feature" I see...
>>> + mdelay(500);
>>> + while (true) {
>>> + i2c_smbus_write_byte_data(bd71828_dev, BD71828_REG_PS_CTRL_1, 0x02);
>>
>> This write to PS_CTRL_1 initiates a state transition. 0x2 equals to HBNT
>> state. Eg, in usual cases this should be a start of the power-off sequence.
>>
>>> + mdelay(500);
>>> + }
>>> +}
>>
>> If you have the hardware to test this on, then it'd be great to see if
>> clearing the reset reason and IRQ status could be dropped. I can't
>> immediately think of a reason for those.
>>
> I will to so. That will also remove the need for all those delays.
Thanks :) Very much appreciated!
Yours,
-- Matti
--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland
~~ When things go utterly wrong vim users can always type :help! ~~
^ permalink raw reply
* Re: [PATCH v16 6/9] usb: dwc3: qcom: Add helper function to request wakeup interrupts
From: Johan Hovold @ 2024-03-25 12:35 UTC (permalink / raw)
To: Krishna Kurapati
Cc: Krzysztof Kozlowski, Rob Herring, Bjorn Andersson, Wesley Cheng,
Konrad Dybcio, Greg Kroah-Hartman, Conor Dooley, Thinh Nguyen,
Felipe Balbi, devicetree, linux-arm-msm, linux-usb, linux-kernel,
quic_ppratap, quic_jackp
In-Reply-To: <20240307062052.2319851-7-quic_kriskura@quicinc.com>
On Thu, Mar 07, 2024 at 11:50:49AM +0530, Krishna Kurapati wrote:
> The logic for requesting interrupts is duplicated for each interrupt. In
> the upcoming patches that introduces support for multiport, it would be
> better to clean up the duplication before reading mulitport related
> interrupts.
>
> Refactor interrupt setup call by adding a new helper function for
> requesting the wakeup interrupts. To simplify implementation, make
> the display name same as the interrupt name expected in DT.
>
> Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
^ permalink raw reply
* Re: [PATCH v16 5/9] dt-bindings: usb: qcom,dwc3: Add bindings for SC8280 Multiport
From: Johan Hovold @ 2024-03-25 12:34 UTC (permalink / raw)
To: Krishna Kurapati
Cc: Krzysztof Kozlowski, Rob Herring, Bjorn Andersson, Wesley Cheng,
Konrad Dybcio, Greg Kroah-Hartman, Conor Dooley, Thinh Nguyen,
Felipe Balbi, devicetree, linux-arm-msm, linux-usb, linux-kernel,
quic_ppratap, quic_jackp, Rob Herring
In-Reply-To: <20240307062052.2319851-6-quic_kriskura@quicinc.com>
On Thu, Mar 07, 2024 at 11:50:48AM +0530, Krishna Kurapati wrote:
> Add the compatible string for SC8280 Multiport USB controller from
> Qualcomm.
>
> There are 4 power event irq interrupts supported by this controller
> (one for each port of multiport). Added all the 4 as non-optional
> interrupts for SC8280XP-MP
>
> Also each port of multiport has one DP and oen DM IRQ. Add all DP/DM
> IRQ's related to 4 ports of SC8280XP Teritiary controller.
>
> Also added ss phy irq for both SS Ports.
>
> Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
> Reviewed-by: Bjorn Andersson <andersson@kernel.org>
> Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
^ permalink raw reply
* [PATCH v2 2/2] arm64: dts: qcom: x1e80100-crd: switch WSA8845 speakers to shared reset-gpio
From: Krzysztof Kozlowski @ 2024-03-25 12:33 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20240325123348.45249-1-krzysztof.kozlowski@linaro.org>
Each pair of WSA8845 speakers share the powerdown SD_N GPIO, thus this
GPIO is specified twice in each WSA8845 device node. Such DTS was added
hoping non-exclusive GPIO usage would be accepted, but it turned out
otherwise: it is not supported by the Linux kernel.
Linux kernel however supports sharing reset GPIOs, when used via the
reset controller framework as implemented in commit 26c8a435fce6 ("ASoC:
dt-bindings: qcom,wsa8840: Add reset-gpios for shared line") and
commit c721f189e89c ("reset: Instantiate reset GPIO controller for
shared reset-gpios").
Convert the property with shutdown GPIO to "reset-gpios" to use
mentioned Linux kernel feature. This allows to bring all four speakers
out of reset.
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
Changes in v2:
1. Rb tag.
2. Fix typo in commit msg (bia->via)
Patch #3 in the series was already applied.
v1: https://lore.kernel.org/all/20240227142725.625561-1-krzysztof.kozlowski@linaro.org/
---
arch/arm64/boot/dts/qcom/x1e80100-crd.dts | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/x1e80100-crd.dts b/arch/arm64/boot/dts/qcom/x1e80100-crd.dts
index d7ba45953277..266a461f4882 100644
--- a/arch/arm64/boot/dts/qcom/x1e80100-crd.dts
+++ b/arch/arm64/boot/dts/qcom/x1e80100-crd.dts
@@ -802,13 +802,14 @@ &smb2360_2_eusb2_repeater {
&swr0 {
status = "okay";
+ pinctrl-0 = <&wsa_swr_active>, <&spkr_01_sd_n_active>;
+ pinctrl-names = "default";
+
/* WSA8845, Left Woofer */
left_woofer: speaker@0,0 {
compatible = "sdw20217020400";
reg = <0 0>;
- pinctrl-0 = <&spkr_01_sd_n_active>;
- pinctrl-names = "default";
- powerdown-gpios = <&lpass_tlmm 12 GPIO_ACTIVE_LOW>;
+ reset-gpios = <&lpass_tlmm 12 GPIO_ACTIVE_LOW>;
#sound-dai-cells = <0>;
sound-name-prefix = "WooferLeft";
vdd-1p8-supply = <&vreg_l15b_1p8>;
@@ -819,8 +820,7 @@ left_woofer: speaker@0,0 {
left_tweeter: speaker@0,1 {
compatible = "sdw20217020400";
reg = <0 1>;
- /* pinctrl in left_woofer node because of sharing the GPIO*/
- powerdown-gpios = <&lpass_tlmm 12 GPIO_ACTIVE_LOW>;
+ reset-gpios = <&lpass_tlmm 12 GPIO_ACTIVE_LOW>;
#sound-dai-cells = <0>;
sound-name-prefix = "TwitterLeft";
vdd-1p8-supply = <&vreg_l15b_1p8>;
@@ -853,13 +853,14 @@ wcd_tx: codec@0,3 {
&swr3 {
status = "okay";
+ pinctrl-0 = <&wsa2_swr_active>, <&spkr_23_sd_n_active>;
+ pinctrl-names = "default";
+
/* WSA8845, Right Woofer */
right_woofer: speaker@0,0 {
compatible = "sdw20217020400";
reg = <0 0>;
- pinctrl-0 = <&spkr_23_sd_n_active>;
- pinctrl-names = "default";
- powerdown-gpios = <&lpass_tlmm 13 GPIO_ACTIVE_LOW>;
+ reset-gpios = <&lpass_tlmm 13 GPIO_ACTIVE_LOW>;
#sound-dai-cells = <0>;
sound-name-prefix = "WooferRight";
vdd-1p8-supply = <&vreg_l15b_1p8>;
@@ -870,8 +871,7 @@ right_woofer: speaker@0,0 {
right_tweeter: speaker@0,1 {
compatible = "sdw20217020400";
reg = <0 1>;
- /* pinctrl in right_woofer node because of sharing the GPIO*/
- powerdown-gpios = <&lpass_tlmm 13 GPIO_ACTIVE_LOW>;
+ reset-gpios = <&lpass_tlmm 13 GPIO_ACTIVE_LOW>;
#sound-dai-cells = <0>;
sound-name-prefix = "TwitterRight";
vdd-1p8-supply = <&vreg_l15b_1p8>;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 1/2] arm64: dts: qcom: x1e80100: correct SWR1 pack mode
From: Krzysztof Kozlowski @ 2024-03-25 12:33 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
Correct the SWR1 Soundwire controller port block pack mode to match
reference code. Not sure if this has any impact.
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
Changes in v2:
1. None, just Rb tag.
---
arch/arm64/boot/dts/qcom/x1e80100.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/x1e80100.dtsi b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
index c6b025503f4f..be4d2674151a 100644
--- a/arch/arm64/boot/dts/qcom/x1e80100.dtsi
+++ b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
@@ -3430,7 +3430,7 @@ swr1: soundwire@6ad0000 {
qcom,ports-hstart = /bits/ 8 <0xff 0x03 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff>;
qcom,ports-hstop = /bits/ 8 <0xff 0x06 0x0f 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff>;
qcom,ports-word-length = /bits/ 8 <0x01 0x07 0x04 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff>;
- qcom,ports-block-pack-mode = /bits/ 8 <0xff 0x00 0x01 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff>;
+ qcom,ports-block-pack-mode = /bits/ 8 <0xff 0xff 0x01 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff>;
qcom,ports-block-group-count = /bits/ 8 <0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff>;
qcom,ports-lane-control = /bits/ 8 <0x01 0x00 0x00 0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff>;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v16 4/9] usb: dwc3: core: Refactor PHY logic to support Multiport Controller
From: Johan Hovold @ 2024-03-25 12:33 UTC (permalink / raw)
To: Krishna Kurapati
Cc: Krzysztof Kozlowski, Rob Herring, Bjorn Andersson, Wesley Cheng,
Konrad Dybcio, Greg Kroah-Hartman, Conor Dooley, Thinh Nguyen,
Felipe Balbi, devicetree, linux-arm-msm, linux-usb, linux-kernel,
quic_ppratap, quic_jackp
In-Reply-To: <20240307062052.2319851-5-quic_kriskura@quicinc.com>
On Thu, Mar 07, 2024 at 11:50:47AM +0530, Krishna Kurapati wrote:
> Currently the DWC3 driver supports only single port controller
> which requires at least one HS PHY and at most one SS PHY.
>
> But the DWC3 USB controller can be connected to multiple ports and
> each port can have their own PHYs. Each port of the multiport
> controller can either be HS+SS capable or HS only capable
> Proper quantification of them is required to modify GUSB2PHYCFG
> and GUSB3PIPECTL registers appropriately.
>
> Add support for detecting, obtaining and configuring PHYs supported
> by a multiport controller. Limit support to multiport controllers
> with up to four ports for now (e.g. as needed for SC8280XP).
>
> Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
^ permalink raw reply
* Re: [PATCH v16 2/9] usb: dwc3: core: Access XHCI address space temporarily to read port info
From: Johan Hovold @ 2024-03-25 12:31 UTC (permalink / raw)
To: Krishna Kurapati
Cc: Krzysztof Kozlowski, Rob Herring, Bjorn Andersson, Wesley Cheng,
Konrad Dybcio, Greg Kroah-Hartman, Conor Dooley, Thinh Nguyen,
Felipe Balbi, devicetree, linux-arm-msm, linux-usb, linux-kernel,
quic_ppratap, quic_jackp
In-Reply-To: <20240307062052.2319851-3-quic_kriskura@quicinc.com>
On Thu, Mar 07, 2024 at 11:50:45AM +0530, Krishna Kurapati wrote:
> All DWC3 Multi Port controllers that exist today only support host mode.
> Temporarily map XHCI address space for host-only controllers and parse
> XHCI Extended Capabilities registers to read number of usb2 ports and
> usb3 ports present on multiport controller. Each USB Port is at least HS
> capable.
>
> The port info for usb2 and usb3 phy are identified as num_usb2_ports
> and num_usb3_ports. The intention is as follows:
>
> Wherever we need to perform phy operations like:
>
> LOOP_OVER_NUMBER_OF_AVAILABLE_PORTS()
> {
> phy_set_mode(dwc->usb2_generic_phy[i], PHY_MODE_USB_HOST);
> phy_set_mode(dwc->usb3_generic_phy[i], PHY_MODE_USB_HOST);
> }
>
> If number of usb2 ports is 3, loop can go from index 0-2 for
> usb2_generic_phy. If number of usb3-ports is 2, we don't know for sure,
> if the first 2 ports are SS capable or some other ports like (2 and 3)
> are SS capable. So instead, num_usb2_ports is used to loop around all
> phy's (both hs and ss) for performing phy operations. If any
> usb3_generic_phy turns out to be NULL, phy operation just bails out.
> num_usb3_ports is used to modify GUSB3PIPECTL registers while setting up
> phy's as we need to know how many SS capable ports are there for this.
>
> Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
^ permalink raw reply
* Re: [PATCH v16 1/9] dt-bindings: usb: Add bindings for multiport properties on DWC3 controller
From: Johan Hovold @ 2024-03-25 12:30 UTC (permalink / raw)
To: Krishna Kurapati
Cc: Krzysztof Kozlowski, Rob Herring, Bjorn Andersson, Wesley Cheng,
Konrad Dybcio, Greg Kroah-Hartman, Conor Dooley, Thinh Nguyen,
Felipe Balbi, devicetree, linux-arm-msm, linux-usb, linux-kernel,
quic_ppratap, quic_jackp, Rob Herring
In-Reply-To: <20240307062052.2319851-2-quic_kriskura@quicinc.com>
On Thu, Mar 07, 2024 at 11:50:44AM +0530, Krishna Kurapati wrote:
> Add bindings to indicate properties required to support multiport
> on Synopsys DWC3 controller.
>
> Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
> Reviewed-by: Bjorn Andersson <andersson@kernel.org>
> Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: arm: qcom: Add Motorola Moto G (2013)
From: Krzysztof Kozlowski @ 2024-03-25 12:18 UTC (permalink / raw)
To: Stanislav Jakubek, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-arm-kernel, phone-devel,
linux-kernel
In-Reply-To: <f5d4d71cd59f25b80889ef88fa044aa3a4268d46.1711288736.git.stano.jakubek@gmail.com>
On 24/03/2024 15:03, Stanislav Jakubek wrote:
> Document the Motorola Moto G (2013), which is a smartphone based
> on the Qualcomm MSM8226 SoC.
>
> Signed-off-by: Stanislav Jakubek <stano.jakubek@gmail.com>
> ---
> Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: iio: health: maxim,max30102: add max30101
From: Krzysztof Kozlowski @ 2024-03-25 12:18 UTC (permalink / raw)
To: Javier Carrasco, Jonathan Cameron, Lars-Peter Clausen,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matt Ranostay
Cc: linux-iio, devicetree, linux-kernel
In-Reply-To: <20240324-max30101-v2-1-611deb510c97@gmail.com>
On 24/03/2024 20:20, Javier Carrasco wrote:
> The Maxim max30101 is the replacement for the max30105, which is no
> longer recommended for future designs.
>
> The max30101 does not require new properties, and it can be described
> with the existing ones for the max30105, which will be used as a
> fallback compatible.
>
> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
> ---
> .../devicetree/bindings/iio/health/maxim,max30102.yaml | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [RFC PATCH 1/2] dt-bindings: mfd: Add ROHM BD71828 system-power-controller property
From: Krzysztof Kozlowski @ 2024-03-25 12:13 UTC (permalink / raw)
To: Andreas Kemnade, lee, robh+dt, krzysztof.kozlowski+dt, conor+dt,
mazziesaccount, devicetree, linux-kernel, imx
In-Reply-To: <20240324201210.232301-2-andreas@kemnade.info>
On 24/03/2024 21:12, Andreas Kemnade wrote:
> As the PMIC can power off the system, add the corresponding property.
>
> Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
> ---
> Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml | 2 ++
> 1 file changed, 2 insertions(+)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [RFC PATCH 2/2] mfd: rohm-bd71828: Add power off functionality
From: Krzysztof Kozlowski @ 2024-03-25 12:13 UTC (permalink / raw)
To: Andreas Kemnade, lee, robh+dt, krzysztof.kozlowski+dt, conor+dt,
mazziesaccount, devicetree, linux-kernel, imx
In-Reply-To: <20240324201210.232301-3-andreas@kemnade.info>
On 24/03/2024 21:12, Andreas Kemnade wrote:
> struct regmap_irq_chip_data *irq_data;
> @@ -542,7 +560,18 @@ static int bd71828_i2c_probe(struct i2c_client *i2c)
> ret = devm_mfd_add_devices(&i2c->dev, PLATFORM_DEVID_AUTO, mfd, cells,
> NULL, 0, regmap_irq_get_domain(irq_data));
> if (ret)
> - dev_err_probe(&i2c->dev, ret, "Failed to create subdevices\n");
> + return dev_err_probe(&i2c->dev, ret, "Failed to create subdevices\n");
> +
> + if (of_device_is_system_power_controller(i2c->dev.of_node)) {
> + if (!pm_power_off) {
> + bd71828_dev = i2c;
> + pm_power_off = bd71828_power_off;
> + ret = devm_add_action_or_reset(&i2c->dev,
> + bd71828_remove_poweroff,
> + NULL);
> + } else
> + dev_warn(&i2c->dev, "Poweroff callback already assigned\n");
Missing {}
Please run scripts/checkpatch.pl and fix reported warnings. Some
warnings can be ignored, but the code here looks like it needs a fix.
Feel free to get in touch if the warning is not clear.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/1] arm64: dts: rockchip: disable analog audio for rock-5b
From: Pratham Patel @ 2024-03-25 12:04 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: robh, krzysztof.kozlowski+dt, conor+dt, heiko, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <37afb6dc-28a0-46e5-ac39-3443999f3bd0@linaro.org>
On Monday, March 25th, 2024 at 13:18, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote:
>
>
> On 24/03/2024 12:21, Pratham Patel wrote:
>
> > On Sunday, March 24th, 2024 at 16:15, Krzysztof Kozlowski krzysztof.kozlowski@linaro.org wrote:
> >
> > > On 24/03/2024 07:28, Pratham Patel wrote:
> > >
> > > > The addition of `of: property: fw_devlink: Fix stupid bug in remote-endpoint parsing`
> > >
> > > Please refer to commits using commit sha () syntax, as mentioned in
> > > submitting patches.
> >
> > Noticed that in the wiki but didn't do that since the commit hash for the commit
> > was different in each branch (of the stable tree). Maybe I should have copied the SHA
> > from Linus' tree. I will do that.
>
>
> There is only one tree: master/mainline tree. Commits in stable do not
> matter outside of stable.
Ack, thank you.
-- Pratham Patel
^ permalink raw reply
* Re: [RFC PATCH 2/2] mfd: rohm-bd71828: Add power off functionality
From: Matti Vaittinen @ 2024-03-25 11:31 UTC (permalink / raw)
To: Andreas Kemnade, lee, robh+dt, krzysztof.kozlowski+dt, conor+dt,
devicetree, linux-kernel, imx
In-Reply-To: <20240324201210.232301-3-andreas@kemnade.info>
On 3/24/24 22:12, Andreas Kemnade wrote:
> Since the chip can power off the system, add the corresponding
> functionality.
> Based on https://github.com/kobolabs/Kobo-Reader/raw/master/hw/imx6sll-clara2e/kernel.tar.bz2
> No information source about the magic numbers found.
Oh, interesting repository :) Thanks for linking to it! I didn't know
someone had reworked this driver...
I have access to the data-sheets so I also have some pieces of
information. I hope I can clarify part of the puzzle. Unfortunately I
have no information about the magic delays. I guess I could try asking
though.
Oh, it seems to me this handler is only working on BD71828, not on
BD71815. So, it should be tied to the ROHM_CHIP_TYPE_BD71828.
> Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
> ---
> drivers/mfd/rohm-bd71828.c | 31 ++++++++++++++++++++++++++++++-
> 1 file changed, 30 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mfd/rohm-bd71828.c b/drivers/mfd/rohm-bd71828.c
> index 594718f7e8e1..5a55aa3620d0 100644
> --- a/drivers/mfd/rohm-bd71828.c
> +++ b/drivers/mfd/rohm-bd71828.c
> @@ -464,6 +464,24 @@ static int set_clk_mode(struct device *dev, struct regmap *regmap,
> OUT32K_MODE_CMOS);
> }
>
> +static struct i2c_client *bd71828_dev;
I'm not sure why to store pointer to the device and not a pointer to the
regmap?
> +static void bd71828_power_off(void)
> +{
> + i2c_smbus_write_byte_data(bd71828_dev, 0x03, 0xff);
0x03 is a "reset reason" - register. Spec I have states that the
register should clear when a reset occurs - but it also says the bits
are "write '1' to clear". So, for some reason(?), this clears the
previous reset reason. I am unsure why i2c_smbus_write_byte_data() and
not regmap()?
> + mdelay(500);
> + i2c_smbus_write_byte_data(bd71828_dev, BD71828_REG_INT_DCIN2, 0x02);
This clears the DCIN monitoring status bit from the IRQ status register.
I don't understand the purpose though.
> + mdelay(500);
> + while (true) {
> + i2c_smbus_write_byte_data(bd71828_dev, BD71828_REG_PS_CTRL_1, 0x02);
This write to PS_CTRL_1 initiates a state transition. 0x2 equals to HBNT
state. Eg, in usual cases this should be a start of the power-off sequence.
> + mdelay(500);
> + }
> +}
If you have the hardware to test this on, then it'd be great to see if
clearing the reset reason and IRQ status could be dropped. I can't
immediately think of a reason for those.
> +static void bd71828_remove_poweroff(void *data)
> +{
> + bd71828_dev = NULL;
This does not smell correct to me. Should we remove the
bd71828_power_off() from the pm_power_off instead?
> +}
> +
> static int bd71828_i2c_probe(struct i2c_client *i2c)
> {
> struct regmap_irq_chip_data *irq_data;
> @@ -542,7 +560,18 @@ static int bd71828_i2c_probe(struct i2c_client *i2c)
> ret = devm_mfd_add_devices(&i2c->dev, PLATFORM_DEVID_AUTO, mfd, cells,
> NULL, 0, regmap_irq_get_domain(irq_data));
> if (ret)
> - dev_err_probe(&i2c->dev, ret, "Failed to create subdevices\n");
> + return dev_err_probe(&i2c->dev, ret, "Failed to create subdevices\n");
> +
> + if (of_device_is_system_power_controller(i2c->dev.of_node)) {
> + if (!pm_power_off) {
> + bd71828_dev = i2c;
> + pm_power_off = bd71828_power_off;
> + ret = devm_add_action_or_reset(&i2c->dev,
> + bd71828_remove_poweroff,
> + NULL);
> + } else
> + dev_warn(&i2c->dev, "Poweroff callback already assigned\n");
> + }
>
> return ret;
> }
Thanks for doing the digging Andreas! I think supporting the power-off
for devices using this PMIC is nice!
Yours,
-- Matti
--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland
~~ When things go utterly wrong vim users can always type :help! ~~
^ permalink raw reply
* Re: [PATCH v4 2/2] backlight: Add new lm3509 backlight driver
From: Daniel Thompson @ 2024-03-25 11:28 UTC (permalink / raw)
To: Patrick Gansterer
Cc: dri-devel, devicetree, Lee Jones, Jingoo Han, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <20240310135344.3455294-2-paroga@paroga.com>
^^^
Also not copied to LKML...
On Sun, Mar 10, 2024 at 02:52:57PM +0100, Patrick Gansterer wrote:
> This is a general driver for LM3509 backlight chip of TI.
> LM3509 is High Efficiency Boost for White LEDs and/or OLED Displays with
> Dual Current Sinks. This driver supports OLED/White LED select, brightness
> control and sub/main control.
> The datasheet can be found at http://www.ti.com/product/lm3509.
>
> Signed-off-by: Patrick Gansterer <paroga@paroga.com>
Overall looks good but there are some review comments inline below.
> diff --git a/drivers/video/backlight/lm3509_bl.c b/drivers/video/backlight/lm3509_bl.c
> new file mode 100644
> index 000000000000..696ec8aab6aa
> --- /dev/null
> +++ b/drivers/video/backlight/lm3509_bl.c
> @@ -0,0 +1,338 @@
> <snip>
> +struct lm3509_bl {
> + struct regmap *regmap;
> + struct backlight_device *bl_main;
> + struct backlight_device *bl_sub;
> + struct gpio_desc *reset_gpio;
> +};
> +
> +struct lm3509_bl_led_pdata {
What does the p stand for here?
(only asking because pdata was the idiomatic form for platform data and
this driver only uses DT-only so I'm finding pdata values everywhere
really confusing)
> + const char *label;
> + int led_sources;
> + u32 brightness;
> + u32 max_brightness;
> +};
> +
> +static void lm3509_reset(struct lm3509_bl *data)
> +{
> + if (data->reset_gpio) {
> + gpiod_set_value(data->reset_gpio, 1);
> + udelay(1);
> + gpiod_set_value(data->reset_gpio, 0);
> + udelay(10);
> + }
> +}
> +
> <snip>
> +
> +static struct backlight_device *
> +lm3509_backlight_register(struct device *dev, const char *name_suffix,
> + struct lm3509_bl *data,
> + const struct backlight_ops *ops,
> + const struct lm3509_bl_led_pdata *pdata)
> +
> +{
> + struct backlight_device *bd;
> + struct backlight_properties props;
> + const char *label = pdata->label;
> + char name[64];
> +
> + memset(&props, 0, sizeof(props));
> + props.type = BACKLIGHT_RAW;
> + props.brightness = pdata->brightness;
> + props.max_brightness = pdata->max_brightness;
Please set props.scale appropriately for this device (given it only has
32 brightness levels I assume it is non-linear?).
> +
> + if (!label) {
> + snprintf(name, sizeof(name), "lm3509-%s-%s", dev_name(dev),
> + name_suffix);
> + label = name;
> + }
> +
> + bd = devm_backlight_device_register(dev, label, dev, data, ops, &props);
> + if (bd)
> + backlight_update_status(bd);
> +
> + return bd;
> +}
> +
> <snip>
> +
> +static int lm3509_probe(struct i2c_client *client)
> +{
> + struct lm3509_bl *data;
> + struct device *dev = &client->dev;
> + int ret;
> + bool oled_mode = false;
> + unsigned int reg_gp_val = 0;
> + struct lm3509_bl_led_pdata pdata[LM3509_NUM_SINKS];
> + u32 rate_of_change = 0;
> +
> + if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
> + dev_err(dev, "i2c functionality check failed\n");
> + return -EOPNOTSUPP;
> + }
> +
> + data = devm_kzalloc(dev, sizeof(struct lm3509_bl), GFP_KERNEL);
> + if (!data)
> + return -ENOMEM;
> +
> + data->regmap = devm_regmap_init_i2c(client, &lm3509_regmap);
> + if (IS_ERR(data->regmap))
> + return PTR_ERR(data->regmap);
> + i2c_set_clientdata(client, data);
> +
> + data->reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
> + if (IS_ERR(data->reset_gpio))
> + return dev_err_probe(dev, PTR_ERR(data->reset_gpio),
> + "Failed to get 'reset' gpio\n");
> +
> + lm3509_reset(data);
> +
> + memset(pdata, 0, sizeof(pdata));
> + ret = lm3509_parse_dt_node(dev, pdata);
> + if (ret)
> + return ret;
> +
> + oled_mode = of_property_read_bool(dev->of_node, "ti,oled-mode");
> +
> + if (!of_property_read_u32(dev->of_node,
> + "ti,brightness-rate-of-change-us",
> + &rate_of_change)) {
> + switch (rate_of_change) {
> + case 51:
> + reg_gp_val = 0;
> + break;
> + case 13000:
> + reg_gp_val = BIT(REG_GP_RMP1_BIT);
> + break;
> + case 26000:
> + reg_gp_val = BIT(REG_GP_RMP0_BIT);
> + break;
> + case 52000:
> + reg_gp_val = BIT(REG_GP_RMP0_BIT) |
> + BIT(REG_GP_RMP1_BIT);
> + break;
> + default:
> + dev_warn(dev, "invalid rate of change %u\n",
> + rate_of_change);
> + break;
> + }
> + }
> +
> + if (pdata[0].led_sources ==
> + (BIT(LM3509_SINK_MAIN) | BIT(LM3509_SINK_SUB)))
> + reg_gp_val |= BIT(REG_GP_UNI_BIT);
> + if (oled_mode)
> + reg_gp_val |= BIT(REG_GP_OLED_BIT);
> +
> + ret = regmap_write(data->regmap, REG_GP, reg_gp_val);
> + if (ret < 0)
> + return ret;
Is this the first time we write to the peripheral? If so the error path
is probably worth a dev_err_probe() (I don't think regmap_write() logs
anything on failure to write).
> + if (pdata[0].led_sources) {
> + data->bl_main = lm3509_backlight_register(
> + dev, "main", data, &lm3509_main_ops, &pdata[0]);
> + if (IS_ERR(data->bl_main)) {
> + dev_err(dev, "failed to register main backlight\n");
> + return PTR_ERR(data->bl_main);
This should use dev_err_probe().
> + }
> + }
> +
> + if (pdata[1].led_sources) {
> + data->bl_sub = lm3509_backlight_register(
> + dev, "sub", data, &lm3509_sub_ops, &pdata[1]);
> + if (IS_ERR(data->bl_sub)) {
> + dev_err(dev,
> + "failed to register secondary backlight\n");
> + return PTR_ERR(data->bl_sub);
Another good place for dev_err_probe().
Daniel.
^ permalink raw reply
* Re: [PATCH RESEND 1/2] dt-bindings: arm: qcom,coresight-tpda: drop redundant type from ports
From: Krzysztof Kozlowski @ 2024-03-25 11:18 UTC (permalink / raw)
To: Suzuki K Poulose, Bjorn Andersson, Konrad Dybcio, Mike Leach,
James Clark, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Mao Jinlong, Tao Zhang, linux-arm-msm, coresight,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <f3a1325b-4126-42d7-b777-9b511279251f@arm.com>
On 25/03/2024 12:07, Suzuki K Poulose wrote:
> Hi Krzysztof
>
> On 25/03/2024 10:40, Krzysztof Kozlowski wrote:
>> "in-ports" and "out-ports" are defined by graph schema, so defining its
>> type is redundant.
>>
>> Acked-by: Rob Herring <robh@kernel.org>
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>
> Both patches look good to me. How would you like to pull this ? I could
> queue them for v6.10 via coresight tree.
>
> If you would like to take them,
>
> Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Please take them via coresight.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 0/7] ARM: dts: samsung: specify the SPI FIFO depth
From: Krzysztof Kozlowski @ 2024-03-25 11:13 UTC (permalink / raw)
To: krzysztof.kozlowski+dt, robh, conor+dt, Tudor Ambarus
Cc: alim.akhtar, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel, broonie, andi.shyti, semen.protsenko, kernel-team,
willmcvicker, andre.draszik, peter.griffin
In-Reply-To: <20240216140449.2564625-1-tudor.ambarus@linaro.org>
On Fri, 16 Feb 2024 14:04:42 +0000, Tudor Ambarus wrote:
> Bindings patch sent but not yet integrated:
> https://lore.kernel.org/linux-spi/20240216070555.2483977-2-tudor.ambarus@linaro.org/
>
> Up to now the SPI alias was used as an index into an array defined in
> the SPI driver to determine the SPI FIFO depth. Drop the dependency on
> the SPI alias and specify the SPI FIFO depth directly into the SPI node.
>
> [...]
Applied, thanks!
[1/7] ARM: dts: samsung: exynos3250: specify the SPI FIFO depth
https://git.kernel.org/krzk/linux/c/43dc9f88ff4db5c932cfb35cfe4bfeff25ed60e2
[2/7] ARM: dts: samsung: exynos4: specify the SPI FIFO depth
https://git.kernel.org/krzk/linux/c/f743fedc881b38a62ee47d752e59ab1ddb247052
[3/7] ARM: dts: samsung: exynos5250: specify the SPI FIFO depth
https://git.kernel.org/krzk/linux/c/a0f87a269f660cb41c2b38041183e3e31c69818d
[4/7] ARM: dts: samsung: exynos5420: specify the SPI FIFO depth
https://git.kernel.org/krzk/linux/c/cc8e49917ca8a3a939d303a7103b9d30ed7d0873
[5/7] ARM: dts: samsung: exynos5433: specify the SPI FIFO depth
https://git.kernel.org/krzk/linux/c/65993c76e64a2fa71ffd05ce260f553d1b3e904f
[6/7] ARM: dts: samsung: exynosautov9: specify the SPI FIFO depth
https://git.kernel.org/krzk/linux/c/b115751fddaf31a0367c19bf080dddcb928a109a
[7/7] ARM: dts: samsung: s5pv210: specify the SPI FIFO depth
https://git.kernel.org/krzk/linux/c/d2c81a9b6acc9ad6fa1a97bf21939adad1882dfa
Best regards,
--
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
^ permalink raw reply
* Re: [PATCH v2 5/7] ARM: dts: samsung: exynos5433: specify the SPI FIFO depth
From: Krzysztof Kozlowski @ 2024-03-25 11:13 UTC (permalink / raw)
To: Tudor Ambarus, krzysztof.kozlowski+dt, robh, conor+dt
Cc: alim.akhtar, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel, broonie, andi.shyti, semen.protsenko, kernel-team,
willmcvicker, andre.draszik, peter.griffin
In-Reply-To: <20240216140449.2564625-6-tudor.ambarus@linaro.org>
On 16/02/2024 15:04, Tudor Ambarus wrote:
> Up to now the SPI alias was used as an index into an array defined in
> the SPI driver to determine the SPI FIFO depthj Drop the dependency on
> the SPI alias and specify the SPI FIFO depth directly into the SPI node.
>
> The FIFO depth were determined based on the SPI aliases that are defined
> in exynos5433-tm2-common.dtsi:
> spi0 = &spi_0;
> spi1 = &spi_1;
> spi2 = &spi_2;
> spi3 = &spi_3;
> spi4 = &spi_4;
> spi-s3c64xx.c driver defines the following fifo_lvl_mask for the
> "samsung,exynos5433-spi" compatible:
> .fifo_lvl_mask = { 0x1ff, 0x7f, 0x7f, 0x7f, 0x7f, 0x1ff},
> Thus spi{0, 4} were considered having 256 byte FIFO depths, and
> spi{1, 2, 3} having 64 byte FIFO depths. Update device tree with these
> FIFO depths. No functional change expected.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> ---
> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 5 +++++
This and next one has wrong subject prefix. I fixed it.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 05/11] riscv: Kconfig.socs: Split ARCH_CANAAN and SOC_CANAAN_K210
From: Conor Dooley @ 2024-03-25 11:10 UTC (permalink / raw)
To: Dan Carpenter
Cc: Yangyu Chen, linux-riscv, Damien Le Moal, Rob Herring,
Krzysztof Kozlowski, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Guo Ren, Michael Turquette, Stephen Boyd, Linus Walleij,
Philipp Zabel, linux-gpio, linux-clk, devicetree, linux-kernel
In-Reply-To: <e255a964-27bf-4eb9-8e9a-4f60d1ccd12b@moroto.mountain>
[-- Attachment #1: Type: text/plain, Size: 2777 bytes --]
On Mon, Mar 25, 2024 at 01:52:42PM +0300, Dan Carpenter wrote:
> On Sat, Mar 23, 2024 at 08:12:17PM +0800, Yangyu Chen wrote:
> > Since SOC_FOO should be deprecated from patch [1], and cleanup for other
> > SoCs is already on the mailing list [2,3,4], we remove the use of
> > SOC_CANAAN and use ARCH_CANAAN for SoCs vendored by Canaan instead from
> > now on. And allows ARCH_CANAAN to be selected for other Canaan SoCs.
> >
> > Then, since we have Canaan Kendryte K230 with MMU now, the use of
> > SOC_CANAAN is no longer only referred to K210. Thus, we introduce a new
> > symbol SOC_CANAAN_K210 for any conditional code or driver selection
> > specific to the K210, so users will not try to build some K210-specific
> > things when MMU is enabled and see it fails to boot on K210.
> >
> > [1] https://lore.kernel.org/linux-riscv/20221121221414.109965-1-conor@kernel.org/
> > [2] https://lore.kernel.org/linux-riscv/20240305-praying-clad-c4fbcaa7ed0a@spud/
> > [3] https://lore.kernel.org/linux-riscv/20240305-fled-undrilled-41dc0c46bb29@spud/
> > [4] https://lore.kernel.org/linux-riscv/20240305-stress-earflap-d7ddb8655a4d@spud/
> >
> > Signed-off-by: Yangyu Chen <cyy@cyyself.name>
> > ---
> > arch/riscv/Kconfig.socs | 8 +++++---
> > arch/riscv/Makefile | 2 +-
> > arch/riscv/configs/nommu_k210_defconfig | 3 ++-
> > arch/riscv/configs/nommu_k210_sdcard_defconfig | 3 ++-
> > 4 files changed, 10 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
> > index 623de5f8a208..5710aee456ac 100644
> > --- a/arch/riscv/Kconfig.socs
> > +++ b/arch/riscv/Kconfig.socs
> > @@ -72,11 +72,13 @@ config SOC_VIRT
> > This enables support for QEMU Virt Machine.
> >
> > config ARCH_CANAAN
> > - def_bool SOC_CANAAN
> > + bool "Canaan Kendryte SoC"
> > + help
> > + This enables support for Canaan Kendryte SoC platform hardware.
> >
> > -config SOC_CANAAN
> > +config SOC_CANAAN_K210
>
> This breaks git bisect, right? There are references to SOC_CANAAN that
> are get updated later in the patch series. You can't delete SOC_CANAAN
> and leave the other references dangling.
Right. I thought that I had said to resend the patch from v5 and solicit
acks to take it via the soc tree [1]. Splitting it out like this means you
have to introduce a symbol that shadows the original one and then switch
only once all references have been removed. If this series went into 6.10,
which it should, the switch would be in 6.11. I think the chances of a
meaningful conflict are low with the treewide swap so it should be safe
to do.
1 - https://lore.kernel.org/all/20240320-ideology-pasty-d3aea07cc519@spud/
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH v11 7/7] arm64: dts: amlogic: meson-g12b-bananapi-cm4: add support for MNT Reform2 with CM4 adaper
From: Neil Armstrong @ 2024-03-25 11:09 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Kevin Hilman,
Jerome Brunet, Michael Turquette, Stephen Boyd,
Martin Blumenstingl, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Nicolas Belin,
Jagan Teki
Cc: devicetree, linux-kernel, linux-amlogic, linux-clk,
linux-arm-kernel, dri-devel, Neil Armstrong, Lukas F. Hartmann
In-Reply-To: <20240325-amlogic-v6-4-upstream-dsi-ccf-vim3-v11-0-04f55de44604@linaro.org>
This adds a basic devicetree for the MNT Reform2 DIY laptop when using a
CM4 adapter and a BPI-CM4 module.
Co-developed-by: Lukas F. Hartmann <lukas@mntre.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
arch/arm64/boot/dts/amlogic/Makefile | 1 +
.../meson-g12b-bananapi-cm4-mnt-reform2.dts | 384 +++++++++++++++++++++
2 files changed, 385 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile
index bf723bec3e15..a89491bb72e8 100644
--- a/arch/arm64/boot/dts/amlogic/Makefile
+++ b/arch/arm64/boot/dts/amlogic/Makefile
@@ -18,6 +18,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-g12b-a311d-bananapi-m2s.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-a311d-khadas-vim3.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-a311d-khadas-vim3-ts050.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-bananapi-cm4-cm4io.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-g12b-bananapi-cm4-mnt-reform2.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-gsking-x.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-gtking-pro.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-gtking.dtb
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-bananapi-cm4-mnt-reform2.dts b/arch/arm64/boot/dts/amlogic/meson-g12b-bananapi-cm4-mnt-reform2.dts
new file mode 100644
index 000000000000..003efed529ba
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-bananapi-cm4-mnt-reform2.dts
@@ -0,0 +1,384 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2023 Neil Armstrong <neil.armstrong@linaro.org>
+ * Copyright 2023 MNT Research GmbH
+ */
+
+/dts-v1/;
+
+#include "meson-g12b-bananapi-cm4.dtsi"
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/sound/meson-g12a-tohdmitx.h>
+
+/ {
+ model = "MNT Reform 2 with BPI-CM4 Module";
+ compatible = "mntre,reform2-cm4", "bananapi,bpi-cm4", "amlogic,a311d", "amlogic,g12b";
+ chassis-type = "laptop";
+
+ aliases {
+ ethernet0 = ðmac;
+ i2c0 = &i2c1;
+ i2c1 = &i2c3;
+ };
+
+ hdmi_connector: hdmi-connector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&hdmi_tx_tmds_out>;
+ };
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led-blue {
+ color = <LED_COLOR_ID_BLUE>;
+ function = LED_FUNCTION_STATUS;
+ gpios = <&gpio_ao GPIOAO_7 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+
+ led-green {
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_STATUS;
+ gpios = <&gpio_ao GPIOAO_2 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ sound {
+ compatible = "amlogic,axg-sound-card";
+ model = "MNT-REFORM2-BPI-CM4";
+ audio-widgets = "Headphone", "Headphone Jack",
+ "Speaker", "External Speaker",
+ "Microphone", "Mic Jack";
+ audio-aux-devs = <&tdmout_a>, <&tdmout_b>, <&tdmin_b>;
+ audio-routing = "TDMOUT_A IN 0", "FRDDR_A OUT 0",
+ "TDMOUT_A IN 1", "FRDDR_B OUT 0",
+ "TDMOUT_A IN 2", "FRDDR_C OUT 0",
+ "TDM_A Playback", "TDMOUT_A OUT",
+ "TDMOUT_B IN 0", "FRDDR_A OUT 1",
+ "TDMOUT_B IN 1", "FRDDR_B OUT 1",
+ "TDMOUT_B IN 2", "FRDDR_C OUT 1",
+ "TDM_B Playback", "TDMOUT_B OUT",
+ "TDMIN_B IN 1", "TDM_B Capture",
+ "TDMIN_B IN 4", "TDM_B Loopback",
+ "TODDR_A IN 1", "TDMIN_B OUT",
+ "TODDR_B IN 1", "TDMIN_B OUT",
+ "TODDR_C IN 1", "TDMIN_B OUT",
+ "Headphone Jack", "HP_L",
+ "Headphone Jack", "HP_R",
+ "External Speaker", "SPK_LP",
+ "External Speaker", "SPK_LN",
+ "External Speaker", "SPK_RP",
+ "External Speaker", "SPK_RN",
+ "LINPUT1", "Mic Jack",
+ "Mic Jack", "MICB";
+
+ assigned-clocks = <&clkc CLKID_MPLL2>,
+ <&clkc CLKID_MPLL0>,
+ <&clkc CLKID_MPLL1>;
+ assigned-clock-parents = <0>, <0>, <0>;
+ assigned-clock-rates = <294912000>,
+ <270950400>,
+ <393216000>;
+
+ dai-link-0 {
+ sound-dai = <&frddr_a>;
+ };
+
+ dai-link-1 {
+ sound-dai = <&frddr_b>;
+ };
+
+ dai-link-2 {
+ sound-dai = <&frddr_c>;
+ };
+
+ dai-link-3 {
+ sound-dai = <&toddr_a>;
+ };
+
+ dai-link-4 {
+ sound-dai = <&toddr_b>;
+ };
+
+ dai-link-5 {
+ sound-dai = <&toddr_c>;
+ };
+
+ /* 8ch hdmi interface */
+ dai-link-6 {
+ sound-dai = <&tdmif_a>;
+ dai-format = "i2s";
+ dai-tdm-slot-tx-mask-0 = <1 1>;
+ dai-tdm-slot-tx-mask-1 = <1 1>;
+ dai-tdm-slot-tx-mask-2 = <1 1>;
+ dai-tdm-slot-tx-mask-3 = <1 1>;
+ mclk-fs = <256>;
+
+ codec {
+ sound-dai = <&tohdmitx TOHDMITX_I2S_IN_A>;
+ };
+ };
+
+ /* Analog Audio */
+ dai-link-7 {
+ sound-dai = <&tdmif_b>;
+ dai-format = "i2s";
+ dai-tdm-slot-tx-mask-0 = <1 1>;
+ mclk-fs = <256>;
+
+ codec {
+ sound-dai = <&wm8960>;
+ };
+ };
+
+ /* hdmi glue */
+ dai-link-8 {
+ sound-dai = <&tohdmitx TOHDMITX_I2S_OUT>;
+
+ codec {
+ sound-dai = <&hdmi_tx>;
+ };
+ };
+ };
+
+ reg_main_1v8: regulator-main-1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <®_main_3v3>;
+ };
+
+ reg_main_1v2: regulator-main-1v2 {
+ compatible = "regulator-fixed";
+ regulator-name = "1V2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ vin-supply = <®_main_5v>;
+ };
+
+ reg_main_3v3: regulator-main-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ reg_main_5v: regulator-main-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "5V";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
+
+ reg_main_usb: regulator-main-usb {
+ compatible = "regulator-fixed";
+ regulator-name = "USB_PWR";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <®_main_5v>;
+ };
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm_AO_ab 0 10000 0>;
+ power-supply = <®_main_usb>;
+ enable-gpios = <&gpio 58 GPIO_ACTIVE_HIGH>;
+ brightness-levels = <0 32 64 128 160 200 255>;
+ default-brightness-level = <6>;
+ };
+
+ panel {
+ compatible = "innolux,n125hce-gn1";
+ power-supply = <®_main_3v3>;
+ backlight = <&backlight>;
+ no-hpd;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&edp_bridge_out>;
+ };
+ };
+ };
+
+ clock_12288: clock_12288 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <12288000>;
+ };
+};
+
+&mipi_analog_dphy {
+ status = "okay";
+};
+
+&mipi_dphy {
+ status = "okay";
+};
+
+&mipi_dsi {
+ status = "okay";
+
+ assigned-clocks = <&clkc CLKID_GP0_PLL>,
+ <&clkc CLKID_MIPI_DSI_PXCLK_SEL>,
+ <&clkc CLKID_MIPI_DSI_PXCLK>,
+ <&clkc CLKID_CTS_ENCL_SEL>,
+ <&clkc CLKID_VCLK2_SEL>;
+ assigned-clock-parents = <0>,
+ <&clkc CLKID_GP0_PLL>,
+ <0>,
+ <&clkc CLKID_VCLK2_DIV1>,
+ <&clkc CLKID_GP0_PLL>;
+ assigned-clock-rates = <936000000>,
+ <0>,
+ <936000000>,
+ <0>,
+ <0>;
+};
+
+&mipi_dsi_panel_port {
+ mipi_dsi_out: endpoint {
+ remote-endpoint = <&edp_bridge_in>;
+ };
+};
+
+&cecb_AO {
+ status = "okay";
+};
+
+ðmac {
+ status = "okay";
+};
+
+&hdmi_tx {
+ status = "okay";
+};
+
+&hdmi_tx_tmds_port {
+ hdmi_tx_tmds_out: endpoint {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+};
+
+&pwm_AO_ab {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm_ao_a_pins>;
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+};
+
+&i2c3 {
+ status = "okay";
+
+ edp_bridge: bridge@2c {
+ compatible = "ti,sn65dsi86";
+ reg = <0x2c>;
+ enable-gpios = <&gpio GPIOX_10 GPIO_ACTIVE_HIGH>; // PIN_24 / GPIO8
+ vccio-supply = <®_main_1v8>;
+ vpll-supply = <®_main_1v8>;
+ vcca-supply = <®_main_1v2>;
+ vcc-supply = <®_main_1v2>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ edp_bridge_in: endpoint {
+ remote-endpoint = <&mipi_dsi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ edp_bridge_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+ };
+ };
+};
+
+&i2c2 {
+ status = "okay";
+
+ wm8960: codec@1a {
+ compatible = "wlf,wm8960";
+ reg = <0x1a>;
+ clocks = <&clock_12288>;
+ clock-names = "mclk";
+ #sound-dai-cells = <0>;
+ wlf,shared-lrclk;
+ };
+
+ rtc@68 {
+ compatible = "nxp,pcf8523";
+ reg = <0x68>;
+ };
+};
+
+&pcie {
+ status = "okay";
+};
+
+&sd_emmc_b {
+ status = "okay";
+};
+
+&tdmif_a {
+ status = "okay";
+};
+
+&tdmout_a {
+ status = "okay";
+};
+
+&tdmif_b {
+ pinctrl-0 = <&tdm_b_dout0_pins>, <&tdm_b_fs_pins>, <&tdm_b_sclk_pins>, <&tdm_b_din1_pins>;
+ pinctrl-names = "default";
+
+ assigned-clocks = <&clkc_audio AUD_CLKID_TDM_SCLK_PAD1>,
+ <&clkc_audio AUD_CLKID_TDM_LRCLK_PAD1>;
+ assigned-clock-parents = <&clkc_audio AUD_CLKID_MST_B_SCLK>,
+ <&clkc_audio AUD_CLKID_MST_B_LRCLK>;
+ assigned-clock-rates = <0>, <0>;
+};
+
+&tdmin_b {
+ status = "okay";
+};
+
+&toddr_a {
+ status = "okay";
+};
+
+&toddr_b {
+ status = "okay";
+};
+
+&toddr_c {
+ status = "okay";
+};
+
+&tohdmitx {
+ status = "okay";
+};
+
+&usb {
+ dr_mode = "host";
+
+ status = "okay";
+};
--
2.34.1
^ permalink raw reply related
* [PATCH v11 6/7] arm64: meson: khadas-vim3l: add TS050 DSI panel overlay
From: Neil Armstrong @ 2024-03-25 11:09 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Kevin Hilman,
Jerome Brunet, Michael Turquette, Stephen Boyd,
Martin Blumenstingl, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Nicolas Belin,
Jagan Teki
Cc: devicetree, linux-kernel, linux-amlogic, linux-clk,
linux-arm-kernel, dri-devel, Neil Armstrong
In-Reply-To: <20240325-amlogic-v6-4-upstream-dsi-ccf-vim3-v11-0-04f55de44604@linaro.org>
This add dtbo overlay to support the Khadas TS050 panel on the
Khadas VIM3 & VIM3L boards.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
arch/arm64/boot/dts/amlogic/Makefile | 4 +
.../boot/dts/amlogic/meson-khadas-vim3-ts050.dtso | 108 +++++++++++++++++++++
2 files changed, 112 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile
index 1ab160bf928a..bf723bec3e15 100644
--- a/arch/arm64/boot/dts/amlogic/Makefile
+++ b/arch/arm64/boot/dts/amlogic/Makefile
@@ -16,6 +16,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-g12a-u200.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12a-x96-max.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-a311d-bananapi-m2s.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-a311d-khadas-vim3.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-g12b-a311d-khadas-vim3-ts050.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-bananapi-cm4-cm4io.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-gsking-x.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-gtking-pro.dtb
@@ -76,6 +77,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-sm1-bananapi-m2-pro.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-bananapi-m5.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-h96-max.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-khadas-vim3l.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-sm1-khadas-vim3l-ts050.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-s905d3-libretech-cc.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-odroid-c4.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-odroid-hc4.dtb
@@ -86,3 +88,5 @@ dtb-$(CONFIG_ARCH_MESON) += meson-sm1-x96-air.dtb
# Overlays
meson-g12a-fbx8am-brcm-dtbs := meson-g12a-fbx8am.dtb meson-g12a-fbx8am-brcm.dtbo
meson-g12a-fbx8am-realtek-dtbs := meson-g12a-fbx8am.dtb meson-g12a-fbx8am-realtek.dtbo
+meson-g12b-a311d-khadas-vim3-ts050 := meson-g12b-a311d-khadas-vim3.dtb meson-khadas-vim3-ts050.dtbo
+meson-sm1-khadas-vim3l-ts050 := meson-sm1-khadas-vim3l.dtb meson-khadas-vim3-ts050.dtbo
diff --git a/arch/arm64/boot/dts/amlogic/meson-khadas-vim3-ts050.dtso b/arch/arm64/boot/dts/amlogic/meson-khadas-vim3-ts050.dtso
new file mode 100644
index 000000000000..a41b4e619580
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-khadas-vim3-ts050.dtso
@@ -0,0 +1,108 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 BayLibre, SAS
+ * Author: Neil Armstrong <narmstrong@baylibre.com>
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/clock/g12a-clkc.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/interrupt-controller/amlogic,meson-g12a-gpio-intc.h>
+
+/dts-v1/;
+/plugin/;
+
+/*
+ * Enable Khadas TS050 DSI Panel + Touch Controller
+ * on Khadas VIM3 (A311D) and VIM3L (S905D3)
+ */
+
+&{/} {
+ panel_backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm_AO_cd 0 25000 0>;
+ brightness-levels = <0 255>;
+ num-interpolated-steps = <255>;
+ default-brightness-level = <200>;
+ };
+};
+
+&i2c3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-0 = <&i2c3_sda_a_pins>, <&i2c3_sck_a_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ touch-controller@38 {
+ compatible = "edt,edt-ft5206";
+ reg = <0x38>;
+ interrupt-parent = <&gpio_intc>;
+ interrupts = <IRQID_GPIOA_5 IRQ_TYPE_EDGE_FALLING>;
+ reset-gpios = <&gpio_expander 6 GPIO_ACTIVE_LOW>;
+ touchscreen-size-x = <1080>;
+ touchscreen-size-y = <1920>;
+ status = "okay";
+ };
+};
+
+&mipi_dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ assigned-clocks = <&clkc CLKID_GP0_PLL>,
+ <&clkc CLKID_MIPI_DSI_PXCLK_SEL>,
+ <&clkc CLKID_MIPI_DSI_PXCLK>,
+ <&clkc CLKID_CTS_ENCL_SEL>,
+ <&clkc CLKID_VCLK2_SEL>;
+ assigned-clock-parents = <0>,
+ <&clkc CLKID_GP0_PLL>,
+ <0>,
+ <&clkc CLKID_VCLK2_DIV1>,
+ <&clkc CLKID_GP0_PLL>;
+ assigned-clock-rates = <960000000>,
+ <0>,
+ <960000000>,
+ <0>,
+ <0>;
+
+ panel@0 {
+ compatible = "khadas,ts050";
+ reset-gpios = <&gpio_expander 0 GPIO_ACTIVE_LOW>;
+ enable-gpios = <&gpio_expander 1 GPIO_ACTIVE_HIGH>;
+ power-supply = <&vcc_3v3>;
+ backlight = <&panel_backlight>;
+ reg = <0>;
+
+ port {
+ mipi_in_panel: endpoint {
+ remote-endpoint = <&mipi_out_panel>;
+ };
+ };
+ };
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ mipi_out_panel: endpoint {
+ remote-endpoint = <&mipi_in_panel>;
+ };
+ };
+ };
+};
+
+&mipi_analog_dphy {
+ status = "okay";
+};
+
+&mipi_dphy {
+ status = "okay";
+};
+
+&pwm_AO_cd {
+ pinctrl-0 = <&pwm_ao_c_6_pins>, <&pwm_ao_d_e_pins>;
+};
--
2.34.1
^ permalink raw reply related
* [PATCH v11 5/7] arm64: meson: g12-common: add the MIPI DSI nodes
From: Neil Armstrong @ 2024-03-25 11:09 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Kevin Hilman,
Jerome Brunet, Michael Turquette, Stephen Boyd,
Martin Blumenstingl, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Nicolas Belin,
Jagan Teki
Cc: devicetree, linux-kernel, linux-amlogic, linux-clk,
linux-arm-kernel, dri-devel, Neil Armstrong
In-Reply-To: <20240325-amlogic-v6-4-upstream-dsi-ccf-vim3-v11-0-04f55de44604@linaro.org>
Add the MIPI DSI Analog & Digital PHY nodes and the DSI control
nodes with proper port endpoint to the VPU.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi | 70 +++++++++++++++++++++++
1 file changed, 70 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
index 9d5eab6595d0..b058ed78faf0 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
@@ -1663,9 +1663,28 @@ pwrc: power-controller {
<250000000>,
<0>; /* Do Nothing */
};
+
+ mipi_analog_dphy: phy {
+ compatible = "amlogic,g12a-mipi-dphy-analog";
+ #phy-cells = <0>;
+ status = "disabled";
+ };
};
};
+ mipi_dphy: phy@44000 {
+ compatible = "amlogic,axg-mipi-dphy";
+ reg = <0x0 0x44000 0x0 0x2000>;
+ clocks = <&clkc CLKID_MIPI_DSI_PHY>;
+ clock-names = "pclk";
+ resets = <&reset RESET_MIPI_DSI_PHY>;
+ reset-names = "phy";
+ phys = <&mipi_analog_dphy>;
+ phy-names = "analog";
+ #phy-cells = <0>;
+ status = "disabled";
+ };
+
usb3_pcie_phy: phy@46000 {
compatible = "amlogic,g12a-usb3-pcie-phy";
reg = <0x0 0x46000 0x0 0x2000>;
@@ -2152,6 +2171,15 @@ hdmi_tx_out: endpoint {
remote-endpoint = <&hdmi_tx_in>;
};
};
+
+ /* DPI output port */
+ dpi_port: port@2 {
+ reg = <2>;
+
+ dpi_out: endpoint {
+ remote-endpoint = <&mipi_dsi_in>;
+ };
+ };
};
gic: interrupt-controller@ffc01000 {
@@ -2189,6 +2217,48 @@ gpio_intc: interrupt-controller@f080 {
amlogic,channel-interrupts = <64 65 66 67 68 69 70 71>;
};
+ mipi_dsi: dsi@7000 {
+ compatible = "amlogic,meson-g12a-dw-mipi-dsi";
+ reg = <0x0 0x7000 0x0 0x1000>;
+ resets = <&reset RESET_MIPI_DSI_HOST>;
+ reset-names = "top";
+ clocks = <&clkc CLKID_MIPI_DSI_HOST>,
+ <&clkc CLKID_MIPI_DSI_PXCLK>,
+ <&clkc CLKID_CTS_ENCL>;
+ clock-names = "pclk", "bit", "px";
+ phys = <&mipi_dphy>;
+ phy-names = "dphy";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+
+ assigned-clocks = <&clkc CLKID_MIPI_DSI_PXCLK_SEL>,
+ <&clkc CLKID_CTS_ENCL_SEL>,
+ <&clkc CLKID_VCLK2_SEL>;
+ assigned-clock-parents = <&clkc CLKID_GP0_PLL>,
+ <&clkc CLKID_VCLK2_DIV1>,
+ <&clkc CLKID_GP0_PLL>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* VPU VENC Input */
+ mipi_dsi_venc_port: port@0 {
+ reg = <0>;
+
+ mipi_dsi_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+
+ /* DSI Output */
+ mipi_dsi_panel_port: port@1 {
+ reg = <1>;
+ };
+ };
+ };
+
watchdog: watchdog@f0d0 {
compatible = "amlogic,meson-gxbb-wdt";
reg = <0x0 0xf0d0 0x0 0x10>;
--
2.34.1
^ 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