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 53164C47258 for ; Thu, 25 Jan 2024 06:48:58 +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-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Content-ID:In-Reply-To: References:Message-ID:Date:Subject:To:From:Reply-To:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=2TPTsEWpk/klz22mPq8m2pONePRVV+a3fpKDcJtZ5BY=; b=QLChOMOWGw8T/b zXisVPHN638mmkzYYcAF7FR2c1QI7t73kU2hz0g78qoy87xSTOPn4QRA4Wop7ZeRzaOAenghtS7dF hI2wUC3o5lezj34wVKUA9dy7SW9cqWqDFN6JDe7nw17HVSW29RutVZ4tFg0Dnylr8287VVZIU966o 2jWAunGLMW71hJK973zNyXD5e0JH+OcJkiQnZp1R5WsPz48SM78lqpf8P6sk9NjWpYr8cLFAtX3Zc lZQNTIqJlRVUKXxzgWgE/pHaX249kd72iH+WHSTlHKACf3MxYySI8MgiaBkI/YwOvQ/G1vtjZ/MAB x1KKAfeXBKjoY5jEVmWA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rStXK-006soO-1o; Thu, 25 Jan 2024 06:48:30 +0000 Received: from esa.microchip.iphmx.com ([68.232.154.123]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1rStXG-006sml-0D for linux-arm-kernel@lists.infradead.org; Thu, 25 Jan 2024 06:48:28 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1706165305; x=1737701305; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=R6J5Vf60ZH593Fnfny1wUtHopAtVM5VwNjmMh2bUKaM=; b=nl8ryPXf3YN/Km3EzaKJ/DeuuMKMNgrrYN5KDYMSTK0FHK/IsRFQtM+2 Xnqbx5bbKkJvQ6d5TUZrD9cS2Xzo0lU4GN31j2QcyZpIJNUjXGrfR2icg hRkHCttAtRMfmy3p7RhFNcmfJ4w35ayF5xMtgGj7t74HX8LmiL7Dtmy7k Yg86G4qi2XqN+mb9KIcUaZMTeoxkl4ueBdpTigCIQFicnhyIO2NIetSEG kMTKXOlJJUg4BD0RZVZ0vkta1nM2bc5VQx+IbUs89KnCJ8hnc/YRydyd/ r9SnkRvfOcifDprdC0PFgS2A2BRuO7GPJrMW4WQn2AHLHLnjxpkMTDndH Q==; X-CSE-ConnectionGUID: gwXo0qD7QFqfgZHJSNFyfQ== X-CSE-MsgGUID: 8HFVOQE9Q4yCehPQyWaz/w== X-IronPort-AV: E=Sophos;i="6.05,216,1701154800"; d="scan'208";a="15266430" X-Amp-Result: SKIPPED(no attachment in message) Received: from unknown (HELO email.microchip.com) ([170.129.1.10]) by esa4.microchip.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 24 Jan 2024 23:48:18 -0700 Received: from chn-vm-ex03.mchp-main.com (10.10.85.151) by chn-vm-ex01.mchp-main.com (10.10.85.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 24 Jan 2024 23:47:55 -0700 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (10.10.215.250) by email.microchip.com (10.10.87.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; Wed, 24 Jan 2024 23:47:55 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fTqWGZhxGxxOHWUnML1R8AdcFNmPSDOPMPy2ewf2AUkuRn8S0xZ4oNEy61pCMTYwcducHlfWgHvacZnr9fQgXfUTAnXcWO/SibE8dOQJzBZgPKnY6HOjIeKQipbffhAE/vpoAtdU0h4oE9ilbKANcdcfMPR1YzgU/3Dujknp3Bir9u3NcjOldYw/3dK22Ms2Ycsdsbkn7e9L/lkINYLK1pXEj+P+pTB41/Eowo26v79iDGwKdTm5CIJSZgncp78sRCjTOn2GPkOcKbZdnadPRVPnjedGhx5USxPcjk/4pxl1uAzClAh2CETKTCOQQoK1W7aLBOwA+tpiL9XUHGHgzA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=R6J5Vf60ZH593Fnfny1wUtHopAtVM5VwNjmMh2bUKaM=; b=SCn0sQVsOJIcTTh4jzXSgtc3Ak/2LnN8L7mxRfCX34nB1h6stfgehP7a14TZJRSBd7shfOiM5paFSo1YZS+ngWHvffLg0ciK4vBoJenscWJoOhDx6MmI3+Z3EXMw9P2Y9XWg80Q59Qb5JP0j2hyoo5VAVfjo6K0/SWp56WmAA/LGzGi2sc7PPE4PrFTBcb0+nDuYM+zDMQnh3ZtRqxvM60uzISD1veTXwCDQtLpEyGVbiblrOZMsGtnqX4GPCXKkAiIqtPBv9nCzLBupF5xAwRMXhmoYXKtioScmSbyX6l/oPDrCL/y41ADH5GaWaQXu2tG9ntFZwc8PykFLdtU45g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microchip.com; dmarc=pass action=none header.from=microchip.com; dkim=pass header.d=microchip.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microchip.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=R6J5Vf60ZH593Fnfny1wUtHopAtVM5VwNjmMh2bUKaM=; b=5Er2dY56NqSvEmuGR9I/q+qVf3r3cu3mvPEJOux0fee04trZ+AAsVo0PsF5p5w8C3NsJKwo2lteiOvR76qoljgtgWCdHMJDkuHJGUk2eb9rq/vJDocpKAXTQYEv43b1mEC1D4J0+UHIaY0JNoDxD1jDW1miRWdldAyAuednp2zyNg72QvIP1AUohKKBExU/HPq289P/e9Ta0NOUVSgFdEatsmTJCCJOGoPoBOvfd24ODVcdUmkDuf0WT0wOgJGm4kBVQU/9zQLWQNhGI/MkzMjHq4+QiMfwXZUS0X34/80X27FVsfzV/UNXK6qKIv25aZepjw5y7/ZnQRTK3ssNMqw== Received: from PH7PR11MB6451.namprd11.prod.outlook.com (2603:10b6:510:1f4::16) by PH0PR11MB5062.namprd11.prod.outlook.com (2603:10b6:510:3e::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7228.22; Thu, 25 Jan 2024 06:47:51 +0000 Received: from PH7PR11MB6451.namprd11.prod.outlook.com ([fe80::80b9:80a3:e88a:57ee]) by PH7PR11MB6451.namprd11.prod.outlook.com ([fe80::80b9:80a3:e88a:57ee%3]) with mapi id 15.20.7228.022; Thu, 25 Jan 2024 06:47:51 +0000 From: To: Subject: Re: [PATCH v3 3/3] dt-bindings: mfd: atmel,hlcdc: Convert to DT schema format Thread-Topic: [PATCH v3 3/3] dt-bindings: mfd: atmel,hlcdc: Convert to DT schema format Thread-Index: AQHaSfB9G+vm5oXSwEmW6mjsJvC8kbDftWKAgADHFQCAAI7AgIAEKeOAgABefoCAAuIIAIAAvjkAgADtGQA= Date: Thu, 25 Jan 2024 06:47:51 +0000 Message-ID: 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> In-Reply-To: <20240124-lend-emerald-1028fe65cc39@spud> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=microchip.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: PH7PR11MB6451:EE_|PH0PR11MB5062:EE_ x-ms-office365-filtering-correlation-id: 6a989846-f219-41fd-cb69-08dc1d718d0d x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: i+MPAI6qUOH35nPKakDITY/vhnA8LumRTz/yoZMSwRQlP4jyAuCRgRfLpr147WugVJag7VPaGytfDuOhlUbhBGquHYycNRXKcnSNRVB3GucQotoEztGf1pa6MaLlzqH33z5/KgcUiO1LE2FgS2YYd7P8xr7UYK8jWyemaqkdyFt/ez1kPk/iM/OTOaZxNCLCMnpCbOodFCYjmFyHeeZLz7yu/rWK/6TPg2tHywvDp+sHjjUF5IABDJi+hL9B0TzhQZkzck0+DOQrf5Qx9G5QkX0j7nqMbulEBGq2pa+n40mvsRmep0T2BY7okdLOJbhsbxU85dnLtF6vye7HOUF02KR0Me4aQ3EUbB+84dLhPvEcq+fDUapa4Nj/ZCe3w2deqR0lKYixa2EXzWQIBr+8/vGuU0vfuv+9aKqWi7R+VusaV/Qxxppj3aodcGIS4T1h/c7zrzkDpKDRuJLope94KjL4RP9feKswk1yLZ30mVYNIiJTRDJudRlOExd63zq34FCpRZEJQVhNLVfms9PLsG1Cg/HpZDCp82biwNgwYRhpWcV4Pws6mzEX27bO2t0XUigHi4G4oAPA8UVEg8WJ5MKduymd19Mo66XWhCAux/8rzONIQiHz31iEzcM34uy8uYdhf/k5WieOZovqfma9R6jTxpLx7tKXbOeZvyFu0d+oOeQvbaU17rbVFSO5Iqqa/ x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH7PR11MB6451.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(396003)(366004)(39860400002)(376002)(136003)(346002)(230922051799003)(186009)(451199024)(64100799003)(1800799012)(76116006)(83380400001)(66946007)(6916009)(38070700009)(31696002)(86362001)(316002)(36756003)(41300700001)(54906003)(64756008)(38100700002)(122000001)(66446008)(66476007)(53546011)(6512007)(31686004)(6506007)(2906002)(7416002)(71200400001)(5660300002)(66556008)(6486002)(4326008)(478600001)(966005)(8936002)(8676002)(2616005)(26005)(107886003)(45980500001);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?NTI3ajJick8xUXI4dEpDZzVNTVBzL1Q3eEhJVndIRmdHR0dxTzBodllSVk92?= =?utf-8?B?UjQ4bjRyeENMamVNbzNra2JhaGR5TW9JMUl4OG1QR213ZFU4NTNQVCszalNL?= =?utf-8?B?Y3VGOEcwMWhuTXBTZlR0eSswQW5sb0dxOHBmRlphWVl3YUNzVXJsenJTbGRy?= =?utf-8?B?MTYyblYvM0l0aXFGbkNyUTV0MTdlaEZoNEVJQzVjTTBWVlpPc082MkorWmVv?= =?utf-8?B?Z1YyUUtBRUxObFVaVUI5T05tWGhaN0tuU09IWW5oNDkxdWhHOUpUL21NeXVW?= =?utf-8?B?aS9vQTNML0J3L0d1TVVtMUN6OXBwdWwyOW5MYzZaOHVWaEdDY0M2dForVHU4?= =?utf-8?B?KzZaMEdUQmJ1Y3B0UEhFM2t2S1pKbmtKZlhhaGY5c0R1S3g2MkJQZmYrc2w3?= =?utf-8?B?a1phSUUxR3FZb3FoblgweUVkNlJKSUw5azM2QS9qamtCbGsxTXpjRDRMZ2J6?= =?utf-8?B?cVpGODVNVEwyZjZKamM1OGtLcGsrQ3dNY3JQRTlsZTFNZnRmdG5uMEZwL1d0?= =?utf-8?B?Q1lJYlllRkdpc1dnamhTOFlPaUU0MEpHOWdDeFUybGxuZUlZZHpNSklEL3gv?= =?utf-8?B?N2hqekltemt1NHRzVjRRajhHZ1Z2L0F3QVNpVFJmNnA1K0NjaHFZZW5CbU05?= =?utf-8?B?LzNTeDVmc2RUam9qeWF3ZysrQ3RwR1h1WXIzUXZhM2diek5ZbW5xSWZjVFBX?= =?utf-8?B?alRSVkZjaVRITmYxc1FSQko5bFFHdEZDZ2twb01jRU5CQUpSc2UyRTNtY3Jl?= =?utf-8?B?RTRLR240QUEvMFNRTHdhVGxFTDg5NkZYcXJXN1JkQVU0ZkEwVXg5UHVPRzEy?= =?utf-8?B?ZUgyUnhQaHVKaWY2SStiVGdEVWVybjYrUldzeTRESlAxWWc4RXNmaGdFUjBl?= =?utf-8?B?cEUzZktjWGgra3JZNUhWc1FoYUQ2bnNiRFhmVlBzeFppenlJZDNrdVRkOU1v?= =?utf-8?B?S1BjandhSkN3Z3JFdlIwVkVvQmtESWk3YnlsMDI3TmVKeCtmZ1VZZS82TTJD?= =?utf-8?B?WE5oY05nUXpkY20rcGdpQUFzRVl6VXdCZ2pxSzg1Z3lsaVR1d05WUXNoVnp3?= =?utf-8?B?cmlVeWYxWkNqQUhOZndtV2VNTEpLekY3TUFaUytnTjRVQjQyUHBEME0wVjFI?= =?utf-8?B?N093TTVCNXZOTFJ2Zk1nUFVIL0tNMWc3Q1dRem0vMkYxWCs2bFliNlJDUERZ?= =?utf-8?B?QnNoczNaOVAyaUwzUS9yK0FzakNXdDRXUjliSklYVlhpeGFzNWVnUlRSNHMy?= =?utf-8?B?SUhOSksyOFFCWXd2WHllWHBLQm9PcEtqaFNrS2pHeVZ5TEk4UWFlOEZIblNN?= =?utf-8?B?a3ZZUmZ5NDJiOXI3YjNsOFkvMTM4RFh4K3BWZ2R5M0t4a1BqSE9PcWQ5N1l3?= =?utf-8?B?N2YwcXB6VFZDTXZIU1dHMy9XWk9JQ09ZSUpkSWYyNjg4NHBPcnBJaXVQY29O?= =?utf-8?B?SGpDM21YWlFRYlhpSU12VXQwd0VyRmhCbVhHeXJQTHRPTkNDczlMOG1ZK011?= =?utf-8?B?bFBqdHJPcktOOHZsTGtiM1U2RkN3VEJNWDBwbTZLNGJLVUxDdjhUTzF4R1li?= =?utf-8?B?K080cGQ5Yzl5L1hYLzN4KzM5OGRmVitlbWlMaW5BbjB3QzFDQW9BdnBvK2Qw?= =?utf-8?B?ejNJSElxQUoxOHlRWlR2T3hYNmV0b21kSXhFN2tRRG9maXB5Q3JhdjhuWS9k?= =?utf-8?B?ZGVjdjlGcmtoQ2hlTFdyT1hmK0hOYTBHSDN2TjRJOHZJOWl3NEtUSUFoMTNR?= =?utf-8?B?aGpoc1ZpeGYvMVF5ZFRRYjdZVjFMbmNESUlhUGMxMGpjMVlqQTBZaTlSRTlB?= =?utf-8?B?SjBtUWU2QWhEQVh3aDNDOVNhQnNhN2E2emRNdVFOejRGYnEvcVM0K2FZdG90?= =?utf-8?B?WmlzVEs4bVR6MzlyWmI5dGxMSGxieStyVklKUXNxTm5vNStMeStRcU9INHV4?= =?utf-8?B?ajFIay9rQ2tuMmpSbitHTGtNK295NGhQZEZ1L01aUkJiTTRObUV6dW00NGg3?= =?utf-8?B?dkZxbzJKN1NxclhlMEUzcXA0Y2k0Vy9jMjJHQmx3VFBZaW4xaW4va2M5eWRs?= =?utf-8?B?MWNUNEJ2WGdkUjVLSHEydkp2YWhWNlBOYWlZdnAwTGZ0K0s5MnlSWUtSZVhS?= =?utf-8?Q?UFEeYjK0m2hcA4bKdtNIrtBRv?= Content-ID: MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH7PR11MB6451.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6a989846-f219-41fd-cb69-08dc1d718d0d X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jan 2024 06:47:51.4466 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3f4057f3-b418-4d4e-ba84-d55b4e897d88 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: qhbDcKkbNEQgQb/EACgHFOgm4IhpegqEqhhFp+SsCDz65pi55pjPh8cB+ALWKz+8Vkkk0Sq/WnPw/bmR4gc7mg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5062 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240124_224826_387613_F1EF7E2E X-CRM114-Status: GOOD ( 17.23 ) 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, Conor.Dooley@microchip.com, 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, daniel@ffwll.ch Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Conor, On 24/01/24 10:09 pm, Conor Dooley wrote: > On Wed, Jan 24, 2024 at 05:18:26AM +0000,Dharma.B@microchip.com wrote: >> Hi Conor & All, >> >> On 22/01/24 2:46 pm, Conor Dooley wrote: >>> On Mon, Jan 22, 2024 at 03:38:41AM +0000,Dharma.B@microchip.com wrote: >>>> Hi Conor, >>>> On 19/01/24 5:33 pm, Conor Dooley - M52691 wrote: >>>>> On Fri, Jan 19, 2024 at 03:32:49AM +0000,Dharma.B@microchip.com wrote: >>>>>> On 18/01/24 9:10 pm, Conor Dooley wrote: >>>>>>> On Thu, Jan 18, 2024 at 02:56:12PM +0530, Dharma Balasubiramani wrote: >>>>>>>> Convert the atmel,hlcdc binding to DT schema format. >>>>>>>> >>>>>>>> Adjust the clock-names property to clarify that the LCD controller expects >>>>>>>> one of these clocks (either sys_clk or lvds_pll_clk to be present but not >>>>>>>> both) along with the slow_clk and periph_clk. This alignment with the actual >>>>>>>> hardware requirements will enable accurate device tree configuration for >>>>>>>> systems using the HLCDC IP. >>>>>>>> >>>>>>>> Signed-off-by: Dharma Balasubiramani >>>>>>>> --- >>>>>>>> changelog >>>>>>>> v2 -> v3 >>>>>>>> - Rename hlcdc-display-controller and hlcdc-pwm to generic names. >>>>>>>> - Modify the description by removing the unwanted comments and '|'. >>>>>>>> - Modify clock-names simpler. >>>>>>>> v1 -> v2 >>>>>>>> - Remove the explicit copyrights. >>>>>>>> - Modify title (not include words like binding/driver). >>>>>>>> - Modify description actually describing the hardware and not the driver. >>>>>>>> - Add details of lvds_pll addition in commit message. >>>>>>>> - Ref endpoint and not endpoint-base. >>>>>>>> - Fix coding style. >>>>>>>> ... >>>>>>>> .../devicetree/bindings/mfd/atmel,hlcdc.yaml | 97 +++++++++++++++++++ >>>>>>>> .../devicetree/bindings/mfd/atmel-hlcdc.txt | 56 ----------- >>>>>>>> 2 files changed, 97 insertions(+), 56 deletions(-) >>>>>>>> create mode 100644 Documentation/devicetree/bindings/mfd/atmel,hlcdc.yaml >>>>>>>> delete mode 100644 Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt >>>>>>>> >>>>>>>> diff --git a/Documentation/devicetree/bindings/mfd/atmel,hlcdc.yaml b/Documentation/devicetree/bindings/mfd/atmel,hlcdc.yaml >>>>>>>> new file mode 100644 >>>>>>>> index 000000000000..eccc998ac42c >>>>>>>> --- /dev/null >>>>>>>> +++ b/Documentation/devicetree/bindings/mfd/atmel,hlcdc.yaml >>>>>>>> @@ -0,0 +1,97 @@ >>>>>>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) >>>>>>>> +%YAML 1.2 >>>>>>>> +--- >>>>>>>> +$id:http://devicetree.org/schemas/mfd/atmel,hlcdc.yaml# >>>>>>>> +$schema:http://devicetree.org/meta-schemas/core.yaml# >>>>>>>> + >>>>>>>> +title: Atmel's HLCD Controller >>>>>>>> + >>>>>>>> +maintainers: >>>>>>>> + - Nicolas Ferre >>>>>>>> + - Alexandre Belloni >>>>>>>> + - Claudiu Beznea >>>>>>>> + >>>>>>>> +description: >>>>>>>> + The Atmel HLCDC (HLCD Controller) IP available on Atmel SoCs exposes two >>>>>>>> + subdevices, a PWM chip and a Display Controller. >>>>>>>> + >>>>>>>> +properties: >>>>>>>> + compatible: >>>>>>>> + enum: >>>>>>>> + - atmel,at91sam9n12-hlcdc >>>>>>>> + - atmel,at91sam9x5-hlcdc >>>>>>>> + - atmel,sama5d2-hlcdc >>>>>>>> + - atmel,sama5d3-hlcdc >>>>>>>> + - atmel,sama5d4-hlcdc >>>>>>>> + - microchip,sam9x60-hlcdc >>>>>>>> + - microchip,sam9x75-xlcdc >>>>>>>> + >>>>>>>> + reg: >>>>>>>> + maxItems: 1 >>>>>>>> + >>>>>>>> + interrupts: >>>>>>>> + maxItems: 1 >>>>>>>> + >>>>>>>> + clocks: >>>>>>>> + maxItems: 3 >>>>>>> Hmm, one thing I probably should have said on the previous version, but >>>>>>> I missed somehow: It would be good to add an items list to the clocks >>>>>>> property here to explain what the 3 clocks are/are used for - especially >>>>>>> since there is additional complexity being added here to use either the >>>>>>> sys or lvds clocks. >>>>>> May I inquire if this approach is likely to be effective? >>>>>> >>>>>> clocks: >>>>>> items: >>>>>> - description: peripheral clock >>>>>> - description: generic clock or lvds pll clock >>>>>> Once the LVDS PLL is enabled, the pixel clock is used as the >>>>>> clock for LCDC, so its GCLK is no longer needed. >>>>>> - description: slow clock >>>>>> maxItems: 3 >>>>> Hmm that sounds very suspect to me. "Once the lvdspll is enabled the >>>>> generic clock is no longer needed" sounds like both clocks can be provided >>>>> to the IP on different pins and their provision is not mutually >>>>> exclusive, just that the IP will only actually use one at a time. If >>>>> that is the case, then this patch is nott correct and the binding should >>>>> allow for 4 clocks, with both the generic clock and the lvds pll being >>>>> present in the DT at the same time. >>>>> >>>>> I vaguely recall internal discussion about this problem some time back >>>>> but the details all escape me. >>>> Let's delve deeper into the clock configuration for LCDC_PCK. >>>> >>>> Considering the flexibility of the design, it appears that both clocks, >>>> sys_clk (generic clock) and lvds_pll_clk, can indeed be provided to the >>>> IP simultaneously. The crucial aspect, however, is that the IP will >>>> utilize only one of these clocks at any given time. This aligns with the >>>> specific requirements of the application, where the choice of clock >>>> depends on whether the LVDS interface or MIPI/DSI is in use. >>> If both clocks can physically be provided to the IP then both of them >>> should be in the dt. The hcldc appears to me to be a part of the SoC and >>> the clock routing to the IP is likely fixed. >>> >>>> To ensure proper configuration of the pixel clock period, we need to >>>> distinctly identify which clocks are being utilized. For instance, in >>>> the LVDS interface scenario, the lvds_pll_clk is essential, resulting in >>>> LCDC_PCK being set to the source clock. Conversely, in the MIPI/DSI >>>> case, the LCDC GCLK is required, leading to LCDC_PCK being defined as >>>> source clock/CLKDIV+2. >>>> >>>> Considering the potential coexistence of sys_clk and lvds_pll_clk in the >>>> Device Tree (DT), we may need to introduce an additional flag in the DT. >>>> This flag could serve as a clear indicator of whether the LVDS interface >>>> or MIPI/DSI is being employed. As we discussed to drop this flag and >>>> just have any one of the clocks I believe that this approach provides a >>>> sensible and scalable solution, allowing for a comprehensive >>>> representation of the clocking configuration. >>> This is probably a question for the folks on the DRM or media side of >>> things, but is it not possible to determine based on the endpoint what >>> protocol is required? >>> I know that on the media side of things there's an endpoint property >>> that can be used to specific the bus-type - is there an equivalent >>> property for DRM stuff? >> Yes, it can be done. >> I will have the lvds pll in the lvds DT node. >> I will just convert the existing text binding to yaml without this >> additonal lvds pll clock. > 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. The LVDS PLL serves as an input to both the LCDC and LVDSC, with the LVDS_PLL multiplied by 7 for the Pixel clock to the LVDS PHY, and LVDS_PLL divided by 7 for the Pixel clock to the LCDC. I am inclined to believe that appropriately configuring and enabling it in the LVDS driver would be the appropriate course of action. > > 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, It's a PLL clock from PMC. > and that the lvds controller's clock is > an optional input for the hlcdc. Again it's a PLL clock from PMC. Please refer Section 39.3 https://ww1.microchip.com/downloads/aemDocuments/documents/MPU32/ProductDocuments/DataSheets/SAM9X7-Series-Data-Sheet-DS60001813.pdf > > 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"? Sure, Please see the below example The typical lvds node will look like lvds_controller: lvds-controller@f8060000 { compatible = "microchip,sam9x7-lvds"; reg = <0xf8060000 0x100>; interrupts = <56 IRQ_TYPE_LEVEL_HIGH 0>; clocks = <&pmc PMC_TYPE_PERIPHERAL 56>, <&pmc PMC_TYPE_CORE PMC_LVDSPLL>; clock-names = "pclk", "lvds_pll_clk"; status = "disabled"; }; -- With Best Regards, Dharma B. > > Thanks, > Conor. > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel