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 2153BC02181 for ; Mon, 20 Jan 2025 12:43:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=8/DVdlrVoXcTUlLhGfvwAA7dr+O9VTylvZ3HNVi2N90=; b=JHONImN+vNce49pg6bpub7Ha0s jo9iKaKQw3t9evBqxs6fPgA04Ff8lVdcwEzoW6y5Fkg0ZcMikMWrUIi6og+sqmQ8WGr7SvjNobIFK O/frQjO3f/Ps0R4ADMkmSIzRO/l9NGSjnnCWiBvPhm5tZyVkffXe/JoSyQHZVa1AAAfcJ2N/qRpWE cieSHxAF2kyc/s5oiYU/Mg+JiWkYeey8sYfjyY1EhEyzdejXIS3aZuIVg4BofChfTTLXnTwj9J3nR OTg0RLD2/l0SpKyXhBUZQtdPId6+ch+bWju5/5HG8sDRWIHBZS/15RJGMBci5eQRrpFaFCPIXzEr/ Iz2pKSxg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tZr7r-00000005ZKG-2QYe; Mon, 20 Jan 2025 12:43:31 +0000 Received: from bali.collaboradmins.com ([148.251.105.195]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tZr6Z-00000005ZAF-3Nxg; Mon, 20 Jan 2025 12:42:13 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1737376928; bh=4buDT01o+ogkMLuBe/lVOY9SSe5oxu1NeJw/qESAoWE=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=geCnwOdjgZ1CvL2aCSZU72KpP7iYX76xdIjm45dgqCiR2nqRUzCFf442ZYJ3i8vmj ADTCelvCDXcwXyeHiY04tqxrRHrDphkMHmK0cdZ2DPYG4GHC+pwDazBRQrU4Ow+1bG qHX3xu38aWVbcFnh42zqPHphrQFEpQNjvkfeuuwXIaaW/3DLxKE+w4S3yUFHDQ+que xFFgtYX+jMZJTJj0cMNVicZd8mZslwCZEMrtPC3oBemDjhANLZ6efVAoPfcDXTH07U Qte/P6404Ye+rvePMwsOlggg7bx6MuZenkUMUlpfnGCxj9lvBePR3oJhBQgKN30KeF jBqFqelOLz31g== Received: from [192.168.1.100] (2-237-20-237.ip236.fastwebnet.it [2.237.20.237]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) (Authenticated sender: kholk11) by bali.collaboradmins.com (Postfix) with ESMTPSA id 7CA0A17E0FAA; Mon, 20 Jan 2025 13:42:07 +0100 (CET) Message-ID: Date: Mon, 20 Jan 2025 13:42:06 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 1/2] dt-bindings: pinctrl: mediatek: add support for mt8196 To: =?UTF-8?B?Q2F0aHkgWHUgKOiuuOWNjuWptyk=?= , "krzk@kernel.org" Cc: "linux-kernel@vger.kernel.org" , "linux-mediatek@lists.infradead.org" , =?UTF-8?B?TGVpIFh1ZSAo6Jab56OKKQ==?= , "devicetree@vger.kernel.org" , =?UTF-8?B?V2VuYmluIE1laSAo5qKF5paH5b2sKQ==?= , "linus.walleij@linaro.org" , =?UTF-8?B?R3VvZG9uZyBMaXUgKOWImOWbveagiyk=?= , "linux-gpio@vger.kernel.org" , "conor+dt@kernel.org" , "robh@kernel.org" , "sean.wang@kernel.org" , "linux-arm-kernel@lists.infradead.org" , "matthias.bgg@gmail.com" , "krzk+dt@kernel.org" References: <20250115063555.32492-1-ot_cathy.xu@mediatek.com> <20250115063555.32492-2-ot_cathy.xu@mediatek.com> From: AngeloGioacchino Del Regno Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250120_044212_026781_6A027FED X-CRM114-Status: GOOD ( 22.34 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Il 20/01/25 10:17, Cathy Xu (许华婷) ha scritto: > On Thu, 2025-01-16 at 11:20 +0100, Krzysztof Kozlowski wrote: >> External email : Please do not click links or open attachments until >> you have verified the sender or the content. >> >> >> On 16/01/2025 09:18, Cathy Xu (许华婷) wrote: >>> On Thu, 2025-01-16 at 08:28 +0100, Krzysztof Kozlowski wrote: >>>> External email : Please do not click links or open attachments >>>> until >>>> you have verified the sender or the content. >>>> >>>> >>>> On 16/01/2025 03:20, Cathy Xu (许华婷) wrote: >>>>>>> + bias-pull-down: >>>>>>> + oneOf: >>>>>>> + - type: boolean >>>>>>> + - enum: [100, 101, 102, 103] >>>>>>> + description: mt8196 pull down PUPD/R0/R1 >>>>>>> type >>>>>>> define value. >>>>>>> + - enum: [200, 201, 202, 203, 204, 205, 206, >>>>>>> 207] >>>>>>> + description: mt8196 pull down RSEL type >>>>>>> define >>>>>>> value. >>>>>> >>>>>> Not much improved. >>>>> >>>>> I have removed the content related to 'resistance value', we >>>>> use >>>>> 'RSEL' instead of 'resistance value'. This is wrong. >>>> >>>> So the value in Ohms was removed? I assume above do not have >>>> known >>>> value >>>> in Ohms? >>> >>> Yes, value in Ohns was removed, no code have knowm value. >> >> Does the hardware have known value in Ohms? It does. > > What do you mean by 'hardware'? When writing to the rsel register, > the value written is 0-7. > Hardware means "the pin controller of the mt8196 SoC" :-) Anyway. The RSEL registers' function is to select a specific resistance value to pullup/down a pin, or a group of pins. Devicetree bindings require to specify values in known units, so in device tree you *need* to specify the RSEL resistance in Ohms. You cannot specify RSEL register value in device-tree. That's unacceptable. Regards, Angelo >> >> >>> >>>> >>>>> >>>>>> >>>>>> >>>>>>> + description: | >>>>>>> + For pull down type is normal, it doesn't >>>>>>> need >>>>>>> add >>>>>>> RSEL & R1R0. >>>>>>> + For pull down type is PUPD/R0/R1 type, it >>>>>>> can >>>>>>> add >>>>>>> R1R0 define to >>>>>>> + set different resistance. It can support >>>>>>> "MTK_PUPD_SET_R1R0_00" & >>>>>>> + "MTK_PUPD_SET_R1R0_01" & >>>>>>> "MTK_PUPD_SET_R1R0_10" >>>>>>> & >>>>>>> + "MTK_PUPD_SET_R1R0_11" define in mt8196. >>>>>>> + For pull down type is PD/RSEL, it can add >>>>>>> RSEL >>>>>>> define to set >>>>>>> + different resistance. It can support >>>>>>> + "MTK_PULL_SET_RSEL_000" & >>>>>>> "MTK_PULL_SET_RSEL_001" & >>>>>>> + "MTK_PULL_SET_RSEL_010" & >>>>>>> "MTK_PULL_SET_RSEL_011" & >>>>>>> + "MTK_PULL_SET_RSEL_100" & >>>>>>> "MTK_PULL_SET_RSEL_101" & >>>>>>> + "MTK_PULL_SET_RSEL_110" & >>>>>>> "MTK_PULL_SET_RSEL_111" >>>>>>> define in >>>>>>> + mt8196. >>>>>>> diff --git a/include/dt-bindings/pinctrl/mt8196-pinfunc.h >>>>>>> b/include/dt-bindings/pinctrl/mt8196-pinfunc.h >>>>>>> new file mode 100644 >>>>>>> index 000000000000..bf0c8374407c >>>>>>> --- /dev/null >>>>>>> +++ b/include/dt-bindings/pinctrl/mt8196-pinfunc.h >>>>>>> @@ -0,0 +1,1572 @@ >>>>>>> +/* SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause >>>>>>> */ >>>>>>> +/* >>>>>>> + * Copyright (C) 2025 Mediatek Inc. >>>>>>> + * Author: Guodong Liu >>>>>>> + */ >>>>>>> + >>>>>>> +#ifndef __MT8196_PINFUNC_H >>>>>>> +#define __MT8196_PINFUNC_H >>>>>>> + >>>>>>> +#include >>>>>>> + >>>>>>> +#define PINMUX_GPIO0__FUNC_GPIO0 (MTK_PIN_NO(0) | 0) >>>>>>> +#define PINMUX_GPIO0__FUNC_DMIC1_CLK (MTK_PIN_NO(0) | 1) >>>>>>> +#define PINMUX_GPIO0__FUNC_SPI3_A_MO (MTK_PIN_NO(0) | 3) >>>>>>> +#define PINMUX_GPIO0__FUNC_FMI2S_B_LRCK (MTK_PIN_NO(0) | >>>>>>> 4) >>>>>>> +#define PINMUX_GPIO0__FUNC_SCP_DMIC1_CLK (MTK_PIN_NO(0) | >>>>>>> 5) >>>>>>> +#define PINMUX_GPIO0__FUNC_TP_GPIO14_AO (MTK_PIN_NO(0) | >>>>>>> 6) >>>>>> >>>>>> I do not see how you resolved my comment from v1. In v2 I >>>>>> reminded >>>>>> about >>>>>> it, so you responded that yopu will change something, but I >>>>>> do >>>>>> not >>>>>> see >>>>>> any changes. >>>>>> >>>>>> So explain: how did you resolve my comment? >>>>>> >>>>>> These two examples where you claim you will change something, >>>>>> but >>>>>> send >>>>>> the same. I skipped the rest of the patch. >>>>> >>>>> Thank you for your patient response, here is my explanation >>>>> for >>>>> you >>>>> question: >>>>> >>>>> In v1, I undertand that you meant I didn't sent a real >>>>> binding, >>>>> and >>>> >>>> >>>> The comment is under specific lines, so I said these defines are >>>> not >>>> a >>>> real binding. You sent them again, but they are still not >>>> bindings, >>>> because they are not used in the driver. Maybe the usage is >>>> convoluted, >>>> so which part of implementation are these connecting with DTS? >>>> IOW, >>>> which part of driver relies on the binding? >>> >>> I got you. This binding define many macros, which will be used >>> for >>> 'pinmux' setting in the DTS. The usage like this: >>> >>> adsp_uart_pins: adsp-uart-pins { >>> pins-tx-rx { >>> pinmux = >>> , >>> >>> ; >>> }; >>> }; >> >> >> That's DTS, not driver, so not a binding. Drop the header from >> bindings. > > Sorry, I don't quite understand the relationship between binding and > driver. Driver will parse this macro to get gpio number and function. >