Received-SPF: pass (google.com: domain of linux-kernel+bounces-137286-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Tue, 9 Apr 2024 12:02:28 -0400
From: Frank Li <Frank.li@nxp.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>, Shawn Guo <shawnguo@kernel.org>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Pengutronix Kernel Team <kernel@pengutronix.de>,
	Fabio Estevam <festevam@gmail.com>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@vger.kernel.org>,
	"open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" <imx@lists.linux.dev>,
	"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" <linux-arm-kernel@lists.infradead.org>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/1] arm64: dts: imx8qxp-mek: add cm40_i2c, wm8960/wm8962
 and sai[0,1,4,5]
Message-ID: <ZhVmlFIq/Ed+HbT9@lizhi-Precision-Tower-5810>
References: <20240404161914.1655305-1-Frank.Li@nxp.com>
 <efc9c624-6a31-4299-a604-8aad1d0cd878@linaro.org>
 <ZhAO4YWuB8r8k+m8@lizhi-Precision-Tower-5810>
 <938489b1-eb94-4f8a-8881-230951299f6a@linaro.org>
 <ZhQO979YpKA24pML@lizhi-Precision-Tower-5810>
 <76714850-0e02-4333-acce-02c7657666b0@linaro.org>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <76714850-0e02-4333-acce-02c7657666b0@linaro.org>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?qmbvlek6cOf8MMBuRZajeU3fk2+Q7/crRXXIRe6/Kbo042yQbx8kO/2tZc75?=
 =?us-ascii?Q?xVG+IJh2VeFlqXifC5pKQJxYcutyJgJ0RY4DUuY59NuyNo7zAgPQH1ZM+D0D?=
 =?us-ascii?Q?hoV0KHg82woo1YkIQKd2+umkb5s2QrOP2Utmth4k866UeGCeK3yysmRLNUUN?=
 =?us-ascii?Q?NZim8n8U85OG9JpjNSJSsQIVcD60sMHRR8VqkNWtAK2cAcJsqRVNyXAuDQbB?=
 =?us-ascii?Q?BDBvhEPe6hUlBgwZOq0a7gCNnwoeYY0L64pY3RFNrd/KltgvqxGqaYuM6sx8?=
 =?us-ascii?Q?70IpZJ8720zlh5L18+y50AVypKArOQjQq3DgGEbFsRzvG2fzKBYppr7woD/k?=
 =?us-ascii?Q?6w9H9mRHwEi8hFCRCc0m3kQWMSbO3buor1zWoawUUUTa5+DzXxoEZd0l2XFn?=
 =?us-ascii?Q?xo4OzJ7pTli2mNa5witDOXfofxDwJ5AAc5M/r7Gz90DPBu2ucgbTPDfmDp4b?=
 =?us-ascii?Q?+A1vM2TIO+iuimm0HjJG321BDUc2AjyPi/npMvRCkTJ57M65u+c31pkrCLjT?=
 =?us-ascii?Q?sUqgk1M5UFOJXNe31Rqu2b3nivgPXutFOYAwv35PS4XMriRY5adUXIFCZX/l?=
 =?us-ascii?Q?bVGQa/MutRO7HQLytj37gz2XrCnzD3djP+MrMhUhY6aoslpSCfGzCV/evcgA?=
 =?us-ascii?Q?3EIj1raJy6fR1xl20TCrPLBjZGvR81xe+MOjRppkMVbhPHn4x07h2341Xm9s?=
 =?us-ascii?Q?GaKJYpEYCfCJhkw2wSi16Rp/l088o+xs19ws/AK/wa+moFjlNLmDOHioxGAZ?=
 =?us-ascii?Q?QDCdI2TZgYxYlHRzhUcdBz19BUsOPvDu7Zm5YqMmO2qrkq5DHCmBsuB4rGzK?=
 =?us-ascii?Q?sADzCS5vRbAM8pE1Y0CTEO5Xlnhlgx7Zjzlyo4MYKLPF1/dunas9/8f7c08w?=
 =?us-ascii?Q?JvYT+P98T2GbAmMczmnXUz9xLy/w369F7N36iZbLn0k3eiHuwK1WL7qwR5GI?=
 =?us-ascii?Q?EwoY0ac2y0Njm3AY/hGkjZvsMyQ1VdePsTTUNfNeHxcXPIJoeHHebHlKgNeU?=
 =?us-ascii?Q?NW8McNT2FDTlObRpdw3k/T+g4YKh8jAfx+DfnndJXlhV7VEobDhQsGb3Hd4W?=
 =?us-ascii?Q?42MQPFbyM7lnJd5kU9PWdL3ToDyRoMvf3Xn5qpdrQTz8s4O0ngdpZAK+ncfs?=
 =?us-ascii?Q?vF9FhCNAqdxvYbxuOsFoVWP3aaA945SLd1STXloCuyq3Jz6MiPJR1ne7sqnw?=
 =?us-ascii?Q?FP+T5yowDMd+vdoLM0zuPsx9s+vXuel/7kYeUkLyWbUEbNJseqjV6IhOfbvE?=
 =?us-ascii?Q?RJ2Vm1hCZZFqHh2SgvpOq6iuaTjzbJq1Nx0BOJdrSNn7xrNr/RLjLSb/QbBZ?=
 =?us-ascii?Q?VdqSf2WACAynu+4NbJ2wUPrr9rk3W94RKqU2YWZzp+LlNlNBggm5c+mBVAOv?=
 =?us-ascii?Q?5EsBK0svCGc9PvXUVjaBxtCDP/jgxY2bfg3xPmrle4Nimx+NuLxhyf11eo1J?=
 =?us-ascii?Q?OZ+Ye1Lol1bjKUVq8V2hNo/jtv5Bh5FJwt3P3MTI5rlZaxa5BEb00tL/QDZR?=
 =?us-ascii?Q?njzcXs0YCrSanL2YUGxrT69sRIOvyUsxzBAxfeEQ6a2ukvPFbkqQuz2WXAWD?=
 =?us-ascii?Q?+KvlbtR1X3HPhtBQ4JU=3D?=
X-OriginatorOrg: nxp.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1ee8f0cb-2db7-41d0-4f13-08dc58ae7a05
X-MS-Exchange-CrossTenant-AuthSource: PAXPR04MB9642.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Apr 2024 16:02:37.5910
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: ZIrCHSI9y7u85GgqtUhovgw1G+Jjz7brhtxQGdEhdFNgA0WvjN+MC/66bYT0+tdmZi8Ht+8iWDeM1f7eqLzaKg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR04MB8405

On Tue, Apr 09, 2024 at 08:33:22AM +0200, Krzysztof Kozlowski wrote:
> On 08/04/2024 17:36, Frank Li wrote:
> > On Fri, Apr 05, 2024 at 08:21:18PM +0200, Krzysztof Kozlowski wrote:
> >> On 05/04/2024 16:46, Frank Li wrote:
> >>> On Fri, Apr 05, 2024 at 08:41:59AM +0200, Krzysztof Kozlowski wrote:
> >>>> On 04/04/2024 18:19, Frank Li wrote:
> >>>>> imx8qxp-mek use two kind audio codec, wm8960 and wm8962. Using dummy gpio
> >>>>> i2c bus mux to connect both i2c devices. One will probe failure and other
> >>>>> will probe success when devices driver check whoami. So one dtb can cover
> >>>>> both board configuration.
> >>>>
> >>>> I don't understand it. Either you add real device or not. If one board
> >>>> has two devices, then why do you need to check for failures?
> >>>>
> >>>> Anyway, don't add fake stuff to DTS.
> >>>
> >>> NAK can't resolve the problem. It should be common problem for long time
> >>> cycle boards. Some chipes will be out life cycle. such as some sensor. So
> >>> chips on boards have been replace by some pin to pin compatible sensor. For
> >>> example: 
> >>> 	old boards: use sensor A with address 0x1a
> >>> 	new bench: use sensor B with address 0x1b.
> >>>
> >>> You can treat it as two kind boards, RevA or RevB. But most user want to
> >>> use one dtb to handle such small differences. For this case, it should be
> >>> simple. Just add a super set.
> >>> 	i2c
> >>> 	{
> >>> 		sensorA@1a
> >>> 		{
> >>> 		}
> >>> 		sensorB@1b
> >>> 		{
> >>> 		}	
> >>> 	}
> >>>
> >>> It also depend on whoami check by i2c devices. Only A or B will probe.
> >>>
> >>> wm8960 and wm8962 are more complex example.  wm8960 is out of life. But
> >>> wm8962 and wm8960 have the same i2c address. The current i2c frame can't
> >>> allow the same i2c address in one i2c bus.
> >>>
> >>> You are feel to NAK my method, but I hope you also provide constructive
> >>> solution to help resolve the problem.
> >>
> >> Yes, we resolved it long time ago. Your bootloader can (usually easily)
> >> detect revision of the board and load appropriate DTS or DTS+DTSO.
> > 
> > I knewn it. But the problem is one development boards A have many options,
> > so create many child dts for files, A1, A2, ... An which base on A
> 
> So use DTSO, what's the problem? Other vendors, liek Rpi does not have
> problem with it and it works well. No confusion.
> 
> > 
> > If there are difference happen at A, create new B. then create all child
> > dtb, B1, B2, ... Bn.  DTB number will increase exponent.
> > 
> > If change is quite bit, we have to do that. But if change is quite small,
> > One dtb can cover it by driver auto detect, which will work like some
> > adaptor card have not plug into boards, or some sensor or NOR-flash have
> > not installed because reduce cost.
> 
> You have two boards, not 20 here!

Actually, it is around ~20 derived boards. It is not upstream just because
we have not time to do that yet. After some clean up, I estimate about 7 -
- 10. 

> 
> >   
> > Although boot loader can update dts or choose difference dts, It also cause
> > many confusition, such as layerscape, uboot update many kernel dtb's
> > information, which actually increase dependence between uboot and kernel.
> > Also it confuse people, for example,  when try to debug kernel dtb, why
> > change have not token affect when change dts because not realized uboot
> > over write it.
> > 
> > What's I dide is that trying to reduce unnecessary dts.
> 
> There is no confusion. That's normal process, so if someone is confused
> by having variants of board, this someone will be even more confused by
> seeing non-existing hardware in his DTS.

How about existed dummy_clk and dummy regulator in dts? 

> 
> This problem was solved long time ago and you do not bring any
> reasonable new arguments. All vendors solved it (just look at ongoing
> discussions on board id) but only you have problem with their solution.

I never said solution was not work. Just not friend for user enough for
this case. It likes USB TypeC vs USB A port. Both works, just TypeC can't
care direction.

> 
> NAK
> 
> Best regards,
> Krzysztof
>