From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 30C61C433F5 for ; Tue, 14 Dec 2021 09:01:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:In-Reply-To:References: Message-ID:Date:Subject:CC:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=/+Gnh2dduXa4xXkff6/lQuN/Eqq8JsuPx4TaFql0uZA=; b=Isq9zrcv/7xvet 8XCfziApSApLqGZohK/gmlFuvlF0BzPXJFZyOQVGiApCu92Rj7Lv19gG+tc+X+G7c3Cxqv5wt0fK1 TuF5S1TOPhUWE8DmCR2aZw9m7mgpPtCuYSPVc8v53sCYiH1VXLFvb52F1GdWe1rheTWIRQxnnLmjo H4o4TkSrFpAsI9+3jsHg5ZdnRf7dfWKe3yY8dbW7/HpJ34wGWCKBTtaifVqDe6UU386KAjcLMkKvh 5KneCEdcNLzsVGWG46LE2/8HgksuVLNoU+MncR/UuzfM4N16AdbZt5m8jlUeiZOQBIhEP6bN6Yt6I bvtXbputkFWWdRf+pGVA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mx3f6-00DAcj-IJ; Tue, 14 Dec 2021 08:59:53 +0000 Received: from mx4.securetransport.de ([178.254.6.145]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mx3ez-00DAYs-66 for linux-arm-kernel@lists.infradead.org; Tue, 14 Dec 2021 08:59:47 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dh-electronics.com; s=dhelectronicscom; t=1639472363; bh=VEh9CiBBkTUq8L+uBe4gN1BCUC6pibpqaFZqp5GRjtc=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=Zp7KZBtl0evyGrrboiTAtgUnq/wOieck99X2hSE5hmQRjVpfnwDKDXiyEuN7RK+z/ Z/HZltq+eTaGL1OsZzRjboXMPT+b1Ci89iLZyEriG51cc9A03A5jnxhpGo4aw2WuIn u6FH//UdAx0zEzXauZxyhd4P2sXRNvjturAukZbvc6MIBBK8dvOrEjDgOh7qwlfHFQ QenXaG3WRy853gX+AwYA+0Mp1z+wGCGQNO/0aYLkPOKv9XGp57FqhRNX9IxlwuAFi/ dnKEoAa3xKK1I9K2wuDI6HiQ9P3qe/S0y/w2Nfa0rv7dD4JBXpD1exVxshSSJwP9TP 4fbHEqrCjXgBw== X-secureTransport-forwarded: yes From: Christoph Niedermaier Complaints-To: abuse@cubewerk.de To: "Marek MV. Vasut" , "linux-arm-kernel@lists.infradead.org" CC: Shawn Guo , Fabio Estevam , "NXP Linux Team" , kernel Subject: RE: [PATCH] ARM: dts: imx6qdl-dhcom: Add USB overcurrent pin on SoM layer Thread-Topic: [PATCH] ARM: dts: imx6qdl-dhcom: Add USB overcurrent pin on SoM layer Thread-Index: AQHX7EaK1KK+ea/u1U+GNWWVPdOK66wpPJgAgACYmYCAANkYgIAAqR8QgAQeGgCAAkKcQA== Date: Tue, 14 Dec 2021 08:59:09 +0000 Message-ID: References: <20211208151504.10758-1-cniedermaier@dh-electronics.com> <07f9d418afb34494ad78ed5c903930da@dh-electronics.com> <328c8b19f2ae43a89a7db4b1a13ff7f5@dh-electronics.com> <15756425-feb9-0086-cb35-90eda4c9bf1b@denx.de> In-Reply-To: <15756425-feb9-0086-cb35-90eda4c9bf1b@denx.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211214_005945_623125_E4FDEC96 X-CRM114-Status: GOOD ( 30.61 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org From: Marek Vasut Sent: Monday, December 13, 2021 12:25 AM > On 12/10/21 08:58, Christoph Niedermaier wrote: >> From: Marek Vasut [mailto:marex@denx.de] >> Sent: Thursday, December 9, 2021 11:26 PM >>> On 12/9/21 10:54, Christoph Niedermaier wrote: >>>> From: Marek Vasut >>>> Sent: Thursday, December 9, 2021 1:23 AM >>>>> >>>>> On 12/8/21 16:15, Christoph Niedermaier wrote: >>>>>> Add USB overcurrent pin muxing on SoM layer, but disable it >>>>>> by default. If a board has connected this pin like the >>>>>> picoITX, this property should be removed in the board file. >>>>>> >>>>>> Signed-off-by: Christoph Niedermaier >>>>>> Cc: Shawn Guo >>>>>> Cc: Fabio Estevam >>>>>> Cc: Marek Vasut >>>>>> Cc: NXP Linux Team >>>>>> Cc: kernel@dh-electronics.com >>>>>> To: linux-arm-kernel@lists.infradead.org >>>>>> --- >>>>>> arch/arm/boot/dts/imx6qdl-dhcom-picoitx.dtsi | 4 ++++ >>>>>> arch/arm/boot/dts/imx6qdl-dhcom-som.dtsi | 2 ++ >>>>>> 2 files changed, 6 insertions(+) >>>>>> >>>>>> diff --git a/arch/arm/boot/dts/imx6qdl-dhcom-picoitx.dtsi b/arch/arm/boot/dts/imx6qdl-dhcom-picoitx.dtsi >>>>>> index 4cd4cb9543c8..a67682bfe7bd 100644 >>>>>> --- a/arch/arm/boot/dts/imx6qdl-dhcom-picoitx.dtsi >>>>>> +++ b/arch/arm/boot/dts/imx6qdl-dhcom-picoitx.dtsi >>>>>> @@ -48,6 +48,10 @@ >>>>>> "", "", "", "", "", "", "", ""; >>>>>> }; >>>>>> >>>>>> +&usbh1 { /* USB overcurrent pin is connected */ >>>>>> + /delete-property/ disable-over-current; >>>>>> +}; >>>>>> + >>>>>> &iomuxc { >>>>>> pinctrl-0 = < >>>>>> /* >>>>>> diff --git a/arch/arm/boot/dts/imx6qdl-dhcom-som.dtsi b/arch/arm/boot/dts/imx6qdl-dhcom-som.dtsi >>>>>> index 5d10c40313cb..e4fdce016c34 100644 >>>>>> --- a/arch/arm/boot/dts/imx6qdl-dhcom-som.dtsi >>>>>> +++ b/arch/arm/boot/dts/imx6qdl-dhcom-som.dtsi >>>>>> @@ -385,6 +385,7 @@ >>>>>> }; >>>>>> >>>>>> &usbh1 { >>>>>> + disable-over-current; >>>>>> dr_mode = "host"; >>>>>> pinctrl-0 = <&pinctrl_usbh1>; >>>>>> pinctrl-names = "default"; >>>>>> @@ -728,6 +729,7 @@ >>>>>> pinctrl_usbh1: usbh1-grp { >>>>>> fsl,pins = < >>>>>> MX6QDL_PAD_EIM_D31__GPIO3_IO31 0x120b0 >>>>>> + MX6QDL_PAD_EIM_D30__USB_H1_OC 0x1b0b1 >>>>>> >; >>>>>> }; >>>>> >>>>> Shouldn't this be the other way around -- boards with unused USB >>>>> overcurrent detection should disable it ? In this case, PDK2 and DRC02 >>>>> should add the 'disable-over-current' DT property and pinmux, while >>>>> picoitx should add the USB OC pinmux . >>>> >>>> This pin is defined by the DHCOM standard, therefore no other function >>>> can be used on this pin. That is why it should be configured in the SoM >>>> file. >>> >>> Then the pinmux in the SoM dtsi is OK. >>> >>>> The first internal version was the other way around, but then we had a >>>> discussion about accidentally enabling the overcurrent detection, because >>>> it is enabled by default. Since most customers do not use overcurrent >>>> detection, we have decided to disable it by default. So if a customer >>>> uses that pin, he has to actively remove the DT property as for example >>>> shown in the PicoITX board file. In this way, the source of issues should >>>> be reduced. >>> >>> It seems to me that if the SoM has a dedicated pin for USB OC, then the >>> SoM dtsi should keep the default configuration of USB OC (i.e. enabled). >>> If a board does not use the USB OC (e.g. because there is a USB hub on >>> it), then the board should add the 'disable-over-current' property, >>> because this is clearly a board property, not a SoM property. >>> >>> Besides, on systems without a USB hub, you likely want to make sure the >>> OC detection is not accidentally forgotten disabled, as that might lead >>> to damage to the port. >>> >>> So I would say, keep the pinmux settings in the SoM dtsi, and add >>> disable-over-current property on board level dts. >> >> I am with you, it is a board property. But I don't want to enable it by >> default, because here I rate the accidental damage of the port higher. >> So if you need it you can enable it on board layer. Because of the negative >> logic have to do it this way. What is the argument against it? > > Per the DHCOM specification, there is a dedicated USB OC input pin on > the SoM. This would imply the SoM deliberately exposes a functionality > and therefore that functionality should be enabled by default, or left > in default setting (which is enabled) -- that means putting only the > pinmux settings into the SoM DT, the OC input is enabled by default by > the CI HDRC driver, so no need for extra SoM level properties. > > Next, if a board does not use the OC input of the SoM, that is a board > property, so the board should add 'disable-over-current' property in the > board DT. The recommended configuration of boards is to connect the OC > input, so in case there is an OC condition on a port, the CI HDRC driver > would be notified and can turn off Vbus too e.g. via regulator to avoid > stressing those Vbus power distribution switches on the board. > > There is also an additional benefit of not adding the > 'disable-over-current' property into SoM DT when it comes to DTOs, which > are used on some DHSOM. A DTO can add a new DT property, but it is not > capable of deleting an existing property in the base DT. I will send a version 2. Regards Christoph _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel