Re: [PATCH v2 13/15] arm64: dts: qcom: pmi632: define USB-C related blocks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 1/17/24 23:01, Bjorn Andersson wrote:
On Mon, Jan 15, 2024 at 11:00:53AM +0100, Konrad Dybcio wrote:
On 13.01.2024 21:55, Dmitry Baryshkov wrote:
Define VBUS regulator and the Type-C handling block as present on the
Quacomm PMI632 PMIC.

Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@xxxxxxxxxx>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx>
---
  arch/arm64/boot/dts/qcom/pmi632.dtsi | 30 ++++++++++++++++++++++++++++++
  1 file changed, 30 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/pmi632.dtsi b/arch/arm64/boot/dts/qcom/pmi632.dtsi
index 4eb79e0ce40a..d6832f0b7b80 100644
--- a/arch/arm64/boot/dts/qcom/pmi632.dtsi
+++ b/arch/arm64/boot/dts/qcom/pmi632.dtsi
@@ -45,6 +45,36 @@ pmic@2 {
  		#address-cells = <1>;
  		#size-cells = <0>;
+ pmi632_vbus: usb-vbus-regulator@1100 {
+			compatible = "qcom,pmi632-vbus-reg", "qcom,pm8150b-vbus-reg";
+			reg = <0x1100>;
+			status = "disabled";
+		};
+
+		pmi632_typec: typec@1500 {
+			compatible = "qcom,pmi632-typec";
+			reg = <0x1500>;
+			interrupts = <0x2 0x15 0x00 IRQ_TYPE_EDGE_RISING>,
+				     <0x2 0x15 0x01 IRQ_TYPE_EDGE_BOTH>,
+				     <0x2 0x15 0x02 IRQ_TYPE_EDGE_RISING>,
+				     <0x2 0x15 0x03 IRQ_TYPE_EDGE_BOTH>,
+				     <0x2 0x15 0x04 IRQ_TYPE_EDGE_RISING>,
+				     <0x2 0x15 0x05 IRQ_TYPE_EDGE_RISING>,
+				     <0x2 0x15 0x06 IRQ_TYPE_EDGE_BOTH>,
+				     <0x2 0x15 0x07 IRQ_TYPE_EDGE_RISING>;
This differs from the downstream irq types:

<0x2 0x15 0x0 IRQ_TYPE_EDGE_BOTH>,
<0x2 0x15 0x1 IRQ_TYPE_EDGE_BOTH>,
<0x2 0x15 0x2 IRQ_TYPE_EDGE_RISING>,
<0x2 0x15 0x3 IRQ_TYPE_EDGE_RISING>,
<0x2 0x15 0x4 IRQ_TYPE_EDGE_BOTH>,
<0x2 0x15 0x5 IRQ_TYPE_EDGE_RISING>,
<0x2 0x15 0x6 IRQ_TYPE_EDGE_RISING>,
<0x2 0x15 0x7 IRQ_TYPE_EDGE_RISING>;


Interrupt 1, 3, and 6 are level interrupts for which it's reasonable to
act on both edges. Interrupt 0, 2, 4, 5, and 7 are "pulse interrupts",
for which it seems reasonable to act on only one of the edges.

To me, Dmitry's proposed version makes more sense than downstream.

Thanks a lot for crosschecking!

Konrad




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux