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 81183C3DA49 for ; Thu, 18 Jul 2024 15:53: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:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=xlT6O/64sTUqCqC71xlo9d1RoNXyJdMOO1TfvmvqZkM=; b=d184H2d/+Lm+m58UMm8Sz1ppG6 DZj4qYSrKzkNNOd+FhWRZIJFnAQatcGIGOiOR2fHCQMxqc/u1R5l2ICpQ+y83HTM3f2pBs6hkRBGA tfHyCyhojtfoAIuy1SCn0oqO9lPDbq4/1wTQabFhrDYoBbJhWgI96qXkd10AT3h+eyNceYdEOhjNN 469F9dRP4XEV9HkJB+ABNPkmdL6DGxIveIlXU/X8kHQGlz69sxG6LI7UXbYs7KMZa1jZ0+fUtAJ7q pIt/LOsvpVU96nIANUs42V/1JNVM5NfNDxO3UBwxRV3dNaCFdtEqICjN8oTkcYPT+RO0HIJc5bx+P wyCen9Iw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sUTRj-0000000HVL1-3YeU; Thu, 18 Jul 2024 15:53:31 +0000 Received: from sin.source.kernel.org ([145.40.73.55]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sUTRM-0000000HVFv-0OPW for linux-arm-kernel@lists.infradead.org; Thu, 18 Jul 2024 15:53:11 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 72856CE1A8B; Thu, 18 Jul 2024 15:53:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 872FDC116B1; Thu, 18 Jul 2024 15:53:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1721317984; bh=B6iJ8irjzz/fOi4lxXcJbV9yEeC3eoXu0jTG6TiEPUs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=mKH5T1rbFec9wRNcHrkmhjzBr2c1uhMGVcP9KX45hACZt+yoOXyRiclZLBZL5g7MQ 7cQkLgnxDCmdLt5++A2K+OuFLyM4frb5WPnyM/NPRwKgGX6mpSYaWqEVqJ6TdWzM7A fw44b5e0UH7LYuas5XxKZxFljegRv35N3S2A3opwtT2+NAHy9pDV1kBrSDGutYtZPT Lt0nKiTCV8rVeYGHQjPmgO4FMUyBPK3ikcSSiQl9LiPBovx0BwXUsfMLkJFbZN0f8T 2Md7mFGAjfTyhfn9ZtImQXKTts+K7GUBXJsgVLu2jw5VaXTAt0aBU3tIHeHwcG4Zk3 efq+uA0gw5pmQ== Date: Thu, 18 Jul 2024 17:53:00 +0200 From: Maxime Ripard To: Krzysztof Kozlowski Cc: Liu Ying , dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org, imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, p.zabel@pengutronix.de, airlied@gmail.com, daniel@ffwll.ch, maarten.lankhorst@linux.intel.com, tzimmermann@suse.de, robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org, shawnguo@kernel.org, s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com, tglx@linutronix.de Subject: Re: [PATCH 02/10] dt-bindings: display: imx: Add i.MX8qxp Display Controller display engine Message-ID: <20240718-watchful-macho-muskrat-dcda01@houat> References: <20240705090932.1880496-1-victor.liu@nxp.com> <20240705090932.1880496-3-victor.liu@nxp.com> <20240708-mega-nautilus-of-champagne-cd4be6@houat> <35667bd4-bfb4-4939-9fd7-328e2e8c228f@kernel.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gkwlffv6qrxgj6ri" Content-Disposition: inline In-Reply-To: <35667bd4-bfb4-4939-9fd7-328e2e8c228f@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240718_085308_510906_311DE1B1 X-CRM114-Status: GOOD ( 22.57 ) 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 --gkwlffv6qrxgj6ri Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 09, 2024 at 08:50:35AM GMT, Krzysztof Kozlowski wrote: > On 08/07/2024 16:52, Maxime Ripard wrote: > > On Mon, Jul 08, 2024 at 04:04:21PM GMT, Krzysztof Kozlowski wrote: > >> On 08/07/2024 08:40, Liu Ying wrote: > >>>>> + > >>>>> + "^framegen@[0-9a-f]+$": > >>>>> + type: object > >>>>> + additionalProperties: true > >>>>> + > >>>>> + properties: > >>>>> + compatible: > >>>>> + const: fsl,imx8qxp-dc-framegen > >>>>> + > >>>>> + "^gammacor@[0-9a-f]+$": > >>>> > >>>> This looks like you are organizing bindings per your driver architec= ture. > >>> > >>> As I mentioned in cover letter, this series addresses Maxime's > >>> comment for the previous series - split the display controller > >>> into multiple internal devices. Maxime insisted on doing this. > >> > >> But these are not separate devices. Look: > >> 1. parent DC: > >> reg =3D <0x56180000 0x40000>; > >> > >> 2. child interrupt controller: > >> reg =3D <0x56180040 0x60>; > >> > >> That address is within parent. > >> > >> 3. Then we go to things like: > >> reg =3D <0x5618b400 0x14>, <0x5618b800 0x1c00>; > >> > >> Still within parent's range and just few words in address range. That's > >> a clear indication that you choose few registers and call it a "device= ". > >=20 > > That's never really been a metric though? > >=20 > > If not, one could just create a "soc" device node covering the entire > > register map, and since it would overlap despite clearly defined > > features, you would claim it's a single device? >=20 > Since I do not create such one-address-soc devices, I claim I have > separate devices in the SoC. Here is not the case: there is a device > covering entire address space. >=20 > Soc is a good example, because components/blocks of the SoC are being > re-used among different SoCs. Is the case here? >=20 > BTW, it could be that some of the sub-devices here are worth to be > devices, I agree. This was the binding of the previous version: https://lore.kernel.org/dri-devel/20230822085949.816844-2-victor.liu@nxp.co= m/ To me, the duplication of interrupts, clocks and power domains with different indices kind of proves that it's all separate devices Maxime --gkwlffv6qrxgj6ri Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCZpk6XAAKCRDj7w1vZxhR xYY5AQDq8KMOoRmdOKy1XHix4IqZooYahpg3GzvOtZ/WqsMsZwEA8vf7t6Uk7oIc BmI0C5iPkUa2dgea9uKW9CpOO3yBXAM= =8Z54 -----END PGP SIGNATURE----- --gkwlffv6qrxgj6ri--