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 10668C47258 for ; Thu, 25 Jan 2024 08:29:13 +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-Type:Cc: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject: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=GE4PDWYYoMfUNvh/qWQBd/XMB9VoVEm/DA70d6I5xK0=; b=Dl/SxUG29wL4rOwAFwxA6RRUda rBDzDAZAfOjoVHScC7ugoE8ff67f0HDS1HBWAO1aKF6AGUbvt5JFnEYyOn916UfhOJt/I67QOTVA7 bOSDd/ZCTTSVnd4j7OhrSDmqJbZE25XIQLGdVgZTUZq4aWqGImcHdW2DUkhyuYZwDLoNSSCmDBWkI aRBdntH913NLLSEcHANqSjU/5ZWZDXhsy2dlKjUeHgbnTjW1ttvNAe0VBvujMvivb4bxljHEv7FtH r/o6aQbzj0hu78MAX9j9HsB4UZscKNpXTQkLvxP7/apvLeonL/IlWoL7Wmwokgz4GqwZuhkqhz60c C7lZAa3Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rSv6K-007L9m-0f; Thu, 25 Jan 2024 08:28:44 +0000 Received: from esa.microchip.iphmx.com ([68.232.153.233]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1rSv6G-007L8e-1k for linux-arm-kernel@lists.infradead.org; Thu, 25 Jan 2024 08:28:42 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1706171321; x=1737707321; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=0o18t8f3/iC5wQSPwN+S8bs8VJQ/VDGiBZsmcwU/bDw=; b=QtIUhfPhoQEXW2ZzwdPCNgdsDR5A9CzYcH4RSbpEqbp28/AkOHJzxj7W XBVwmitP/f2aVkfxAQJEr4CMqAiGWNiAHrhNWXpiHfrTYI7w7eVnpMdz6 /OakRGCgdeDnZ46D6FPcMNETTovOJiLoQBLs6AqZk061b2qDPAKCCUSMT 35urRmTROyjCf+RCtLPlm1Yxfn7DK1HfcJ2NQIwA+yzeoRb2IIqHsvEs6 /32U9R21uc4tOCCoh0d9ejrS3LeMld848HPttPyce3FSDlu12x0fuyppb Dgm8tzQsXnE/Z9k3TXENnnzOktbWjiOaq1lQxJi1OThcMSPUK7ObKZ8q0 A==; X-CSE-ConnectionGUID: yWKH6XeGSSC8CBa5MkUWWA== X-CSE-MsgGUID: /2Vw4AgiQCK4jHQhEACeAA== X-IronPort-AV: E=Sophos;i="6.05,216,1701154800"; d="asc'?scan'208";a="15276256" X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN Received: from unknown (HELO email.microchip.com) ([170.129.1.10]) by esa3.microchip.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 25 Jan 2024 01:28:38 -0700 Received: from chn-vm-ex04.mchp-main.com (10.10.85.152) by chn-vm-ex02.mchp-main.com (10.10.85.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 25 Jan 2024 01:28:36 -0700 Received: from wendy (10.10.85.11) by chn-vm-ex04.mchp-main.com (10.10.85.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35 via Frontend Transport; Thu, 25 Jan 2024 01:28:32 -0700 Date: Thu, 25 Jan 2024 08:27:55 +0000 From: Conor Dooley To: Subject: Re: [PATCH v3 3/3] dt-bindings: mfd: atmel,hlcdc: Convert to DT schema format Message-ID: <20240125-proved-passage-7fa128f828db@wendy> References: <20240118092612.117491-1-dharma.b@microchip.com> <20240118092612.117491-4-dharma.b@microchip.com> <20240118-recent-glorified-fd35d72e006e@spud> <20240119-character-mardi-43571d7fe7d5@wendy> <20240122-stark-duress-2f59294dcf27@spud> <4906b7e2-0ddb-4d3c-a48b-e16278f2d649@microchip.com> <20240124-lend-emerald-1028fe65cc39@spud> MIME-Version: 1.0 In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240125_002840_595025_F9F316A6 X-CRM114-Status: GOOD ( 27.30 ) 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: , Cc: alexandre.belloni@bootlin.com, linux-pwm@vger.kernel.org, Linux4Microchip@microchip.com, dri-devel@lists.freedesktop.org, thierry.reding@gmail.com, krzysztof.kozlowski+dt@linaro.org, claudiu.beznea@tuxon.dev, airlied@gmail.com, sam@ravnborg.org, lee@kernel.org, u.kleine-koenig@pengutronix.de, devicetree@vger.kernel.org, conor+dt@kernel.org, tzimmermann@suse.de, maarten.lankhorst@linux.intel.com, mripard@kernel.org, robh+dt@kernel.org, linux-arm-kernel@lists.infradead.org, bbrezillon@kernel.org, linux-kernel@vger.kernel.org, conor@kernel.org, daniel@ffwll.ch Content-Type: multipart/mixed; boundary="===============9023440612770641918==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============9023440612770641918== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KV2dTBGvLz55uW11" Content-Disposition: inline --KV2dTBGvLz55uW11 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > > If the lvds pll is an input to the hlcdc, you need to add it here. > > From your description earlier it does sound like it is an input to > > the hlcdc, but now you are claiming that it is not. >=20 > The LVDS PLL serves as an input to both the LCDC and LVDSC Then it should be an input to both the LCDC and LVDSC in the devicetree. > with the=20 > LVDS_PLL multiplied by 7 for the Pixel clock to the LVDS PHY, and=20 Are you sure? The diagram doesn't show a multiplier, the 7x comment there seems to be showing relations? > LVDS_PLL divided by 7 for the Pixel clock to the LCDC. > I am inclined to believe that appropriately configuring and enabling it= =20 > in the LVDS driver would be the appropriate course of action. We're talking about bindings here, not drivers, but I would imagine that if two peripherals are using the same clock then both of them should be getting a reference to and enabling that clock so that the clock framework can correctly track the users. > > I don't know your hardware, so I have no idea which of the two is > > correct, but it sounds like the former. Without digging into how this > > works my assumption about the hardware here looks like is that the lvds > > controller is a clock provider, >=20 > It's a PLL clock from PMC. >=20 > > and that the lvds controller's clock is > > an optional input for the hlcdc. >=20 > Again it's a PLL clock from PMC. >=20 > Please refer Section 39.3=20 > https://ww1.microchip.com/downloads/aemDocuments/documents/MPU32/ProductD= ocuments/DataSheets/SAM9X7-Series-Data-Sheet-DS60001813.pdf It is not the same exact clock as you pointed out above though, so the by 7 divider should be modelled. > > Can you please explain what provides the lvds pll clock and show an > > example of how you think the devictree would look with "the lvds pll in > > the lvds dt node"? >=20 > Sure, Please see the below example >=20 > The typical lvds node will look like >=20 > lvds_controller: lvds-controller@f8060000 { > compatible =3D "microchip,sam9x7-lvds"; > reg =3D <0xf8060000 0x100>; > interrupts =3D <56 IRQ_TYPE_LEVEL_HIGH 0>; > clocks =3D <&pmc PMC_TYPE_PERIPHERAL 56>, <&pmc= =20 > PMC_TYPE_CORE PMC_LVDSPLL>; > clock-names =3D "pclk", "lvds_pll_clk"; > status =3D "disabled"; > }; In isolation, this looks fine. Cheers, Conor. --KV2dTBGvLz55uW11 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZbIbiwAKCRB4tDGHoIJi 0h+8AQCpYI71+drl2FDrbEGThmMOFS/iz1jS+CPJczvYePVUqwD/ZilClwywAcjj BSSdZJ4KLwpHGZIe4dxZJbifZWhXPAY= =rMTy -----END PGP SIGNATURE----- --KV2dTBGvLz55uW11-- --===============9023440612770641918== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============9023440612770641918==--