Received-SPF: pass (google.com: domain of linux-kernel+bounces-135610-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: Mon, 8 Apr 2024 11:36:23 -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: <ZhQO979YpKA24pML@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>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <938489b1-eb94-4f8a-8881-230951299f6a@linaro.org>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?6+PfjW63+XexsMoRZA2802C3Gi2mHvRSoCIIlSPQUEpTzO9QJbjKHeI5rrfu?=
 =?us-ascii?Q?BDWv8HVRlP2ePL+EP5LlCoA/fQYx215DNbPkt8Q4yvHaLcP+3GGoYoozgWl+?=
 =?us-ascii?Q?j85uVRcbLNysdKeh2bR3Yht27FSx7bOtjcKIdN3hDkd/CtxK4+rcOHAChicY?=
 =?us-ascii?Q?7vyyK9Gw8UplM64K1zvi3ftoWkPV8F7V0lrzIetGeem+jV92/h8wkMJd/poD?=
 =?us-ascii?Q?xXOsL64TJORDRY/y3bl3NbfGvX2ogEI758IFaahIuQbHWyd+V5Nsy7eLNrIe?=
 =?us-ascii?Q?xceqE+II6gBdiLBAXQSFIO1IK3iItEoAhtR2GVSqJ8dYoiSrLeGywFeJGKYC?=
 =?us-ascii?Q?BBDzJwTDXhRNe0p19CKZnVxKC9rmTTWKwP4K5Q6z0QZJBQ48mxFhFWGaqTs6?=
 =?us-ascii?Q?5beYjpS+nMOI5xIR1+Fq+XSUc8knBE1MAArguUJejSraN4hBKu7xRUxoAR7A?=
 =?us-ascii?Q?wnDwUL8CPZU9m4vAQrJDuPhihD/75VD2QDe2/l4ceUIcIyF/U2n5aRIQID3V?=
 =?us-ascii?Q?V8oUyhKD8sUNs98rur4uyunA0YZzpXcWYJC6ZxxTe60pQyRCncvYRDoqD0dc?=
 =?us-ascii?Q?mtwZJWNKk78Kl1pJWexh2/eFMcnVpKeM/UbgtqIiJbqJTwvW9p9VznjiVZhG?=
 =?us-ascii?Q?CiXJ8Vh8DmiVwg4ZPd7eMMFVcwLsZNNAtvDu+9vX0YUmzaR0aFQYTDnfT+6g?=
 =?us-ascii?Q?6HkNF7YpopAKNW/5h/sZC3CZgzW1nt6D5U3N5P5vpkIRrEVSudWwh1OK8l6Q?=
 =?us-ascii?Q?VvurWRaDJ2SBOLWHplp+35zYh8SmuEmXKOsyeCSaHr3zEQV8wX5ltJ3o/pxW?=
 =?us-ascii?Q?/AIwWO5HFjBvyTDfpLIAnwSMqslqCsPymss57juSBnWgZKT+p4KVG/OqJWaE?=
 =?us-ascii?Q?6kAEwYKXBWIWYasr1sgInv90URuC1WGqCd7lxRr4PxDTAPybuztt1cygc34o?=
 =?us-ascii?Q?x6lcuqQIWWHJWvbCiXA179dqyeHEM4gd8IIRhf3BNBLrXtQfYnO9y//K3XjD?=
 =?us-ascii?Q?AvZ4x9D/lG3+08bFUHJmZ+9fUMoqH5JwZSxwVmj0iEXXFOLAClcrPMSVGzHV?=
 =?us-ascii?Q?EkV8DJQ+bq2sCwV9U/blf/OIq0hfcosl5ZYzzKVOzbP+24iOwG10ENJkr2Cu?=
 =?us-ascii?Q?pf+oY7fwwYSUGZUNBYzVFYWGQeLDKwq92gpU1HWhMxIvIZuwnqkAB1fkMxj/?=
 =?us-ascii?Q?SXLZCWedc7p49TZjK9rT0oq6kIZb5vIm5KPor5+BfXzkmD3NPs4Z441aa7+e?=
 =?us-ascii?Q?SRGdMnIl6P65cddbkTwFcHPbv2mSX23m3/IqW8wZbRtk0O3aw/q4lNBKekM8?=
 =?us-ascii?Q?vQ/bpdGNWjayAz+RjmqLY53RR80UDd5c1ndDoy+hy4hFr6hbn/bejw43oeym?=
 =?us-ascii?Q?9KGdqboWzQbKs5mGvz+pG0RiS3/xQiPuiPMeIfrX8ogILOpR6bvpWLcZ2TaP?=
 =?us-ascii?Q?iFj5PfHCZIKzz74HpsBFizSvSosTralpkolxO6nlSLEP/poRQKfnkHYoQ517?=
 =?us-ascii?Q?0GkBvTiOk+P6gPVcMviG4pSZw7xDvjipQ1Ym0y+iT3fPhGsg7YHhFvOma9+Q?=
 =?us-ascii?Q?1Lce14a5jfZEi/9dpRg=3D?=
X-OriginatorOrg: nxp.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 85139a6a-fd0e-43ed-187d-08dc57e1a9fe
X-MS-Exchange-CrossTenant-AuthSource: PAXPR04MB9642.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Apr 2024 15:36:31.2046
 (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: 6AwwfKRqFTHtDDW0ZCbRJiIWgq7/ZYmh+QC2Ql6KFTOc84x3i2RhXvXJtz1NqTmB2ElqnwEhL7yKX5q0DOjiTA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA2PR04MB10309

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

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.
  
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.

Frank

> 
> Best regards,
> Krzysztof
>