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 9D739C47422 for ; Wed, 24 Jan 2024 05:19:36 +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=w5KUiBjqOGIkQUB7B0fRPrGSSHmNQ+9M47g2XiRKB2k=; b=mW+pwJcuc0a/WH /G+sTdlQHbYOWnEY/GL/IrdfoTqr7ZCxrhTVawG2P3wwZ08jgnMQ40H2y4ccKs+3qyfT41Yw+Wva0 Ha7bkIHkFXdrDUKu8U77OMwmIXBjInfkpV2KCpYECViEGRWUWJLeJRG7B7d2QxXn8THDnFRpwdTkC p/8Y0Z7U+O5tRXHL3RxeeUBANXIX0K3zLGzicSk1/NUfBsANR/MZWZeBwstdrYy8df5jvKQUdKk9C xm3llTyXmkFDtSqw0W4ysaFAU59IW4/L6KBuV+778cxUlE5k3ubAnubJbobqSxQnLtU4XLvRlbYqo /MUebRw77tYZ/NV44J4Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rSVfF-001Zm4-1v; Wed, 24 Jan 2024 05:19:05 +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 1rSVf9-001ZhZ-0U for linux-arm-kernel@lists.infradead.org; Wed, 24 Jan 2024 05:19:03 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1706073539; x=1737609539; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zQQbAq+bbxq12iM3xL4cXGH8CjixZyeFs5PX3PfWFsQ=; b=a5TxwiM0iIXRj37mPQr2UaGMBsvqzZtd/1HWMmRYF+Euuuu/LTxTTjJI gOoTCYQZeYILR3N9jafN135E655SCY/4B6ifYuP3jXVyniaVrOPt22PBI zzj7UXQSDFsTH36OpyeQpco0dpyOSdc0ZcJyfs+Z4xiM3fnQKuDdBSocN g5XyW12CmXZu6sCqCveOWMaObxlUYONqe4FmYMdtiY0JlFh+QAKpkxAt9 ANgYCL8cuJrLEM3MokbInCoRIwvBp0m6YYn22rDvWIfgcVmXNfoomH3yH 9S4K2m5rdlTZdJYI/uhsmibf7hcpgS9poE1sG5PV8KWA5TfVI9gNu86U5 w==; X-CSE-ConnectionGUID: phPKyoNJT4qQ4jzxUq7xnA== X-CSE-MsgGUID: JT6F1kgKSeCuVGaHNBd7vA== X-IronPort-AV: E=Sophos;i="6.05,216,1701154800"; d="scan'208";a="15201450" 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; 23 Jan 2024 22:18:51 -0700 Received: from chn-vm-ex02.mchp-main.com (10.10.85.144) 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; Tue, 23 Jan 2024 22:18:29 -0700 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (10.10.215.250) by email.microchip.com (10.10.87.72) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35 via Frontend Transport; Tue, 23 Jan 2024 22:18:29 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=d5NWIp6g2z04UeuBhI0ulGoidL+IfnTJMbOIoMCmnvUM4bTIxteD/PGww8tqOaxSzID0rnMv7zPfNlg4AmWm7S0TDCE0HYKF10yhNgPDf7BO0AqcYzy5WTbucyc+E+WDJhBIeC61ySdEujfweF8uYV4QeFVqvgHcHXhkLMtWFWdtxp9I+ClIcmp7SaEtQ8A7H9HcT7hDgTq7Qp0FZNz/e6Qs3oQCodiTOz4jROXiFDOjQvIZ/e6o48yf6eYGBEZKkjQzsc4M3y4D4mOkyioxhxcn9OqimbHfArEtFH7wSV+ayS9aieu4/gJnf6uZ1rhu+MMS8bRlrzGtNcwRhgiIAw== 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=zQQbAq+bbxq12iM3xL4cXGH8CjixZyeFs5PX3PfWFsQ=; b=W0pGUv8bO4v/a0RtVNc0ArUXUYHtMN7DsdUZvfXoJMEaADcDRAt2FRejjmpAM2WG158H9W2zP0ySK1KBzfnBpwNtiSo/zFWKMJihT9FDFMxPHWLCxVUOg4Ck+P27YCrSVX7v8os8SGBos4uLgcCBGjXAtZRVgl8YMyt/Ebl1FqwmPRXJeuZOKVf880/OC3RMii0S1xWpfTDLj/f5STwljYndgltMWlDwyZlrZr+e+UJfzcBvfZdPY/s7mr20zOOl0rq4kHRdxBI2725/vMuaLMtDxFVbSkoaGE7L4BtbaVf3322ksZ7+FkFs+oOUCmM0nxF3HBeuO4xLiShywleVHA== 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=zQQbAq+bbxq12iM3xL4cXGH8CjixZyeFs5PX3PfWFsQ=; b=ZRzt7BlWm2ZLOFxhzu0UyBsRTHjBHfaUSX330xFilYiX6LC2ikVLvfEGAZlezo5pUUdSJcNG9nOyrY02LNrER1tanZ9z1xHe+FrJRSNmx2j0n2RFmOpHTSqQI3iOjSvDUvAkxeWIa9DQXYeKsLDZxjFpLZ6UwpEosUMeoszh/Cm2oaieC4saEA6fYVRc23u7kKq2HQ4/gy2PqsPoMFnye7JfyfFWMDcIkukddkubMaBGirGe6SZJ3iBlglV1uaG5XRqItrb8pMDgo1UW4if0oTECu2efLja/n/ZOZ9Y27XsUdOBPcT9qfZZTc1mGhbXwkA0uFEeFde0FKkgANMC/dg== Received: from PH7PR11MB6451.namprd11.prod.outlook.com (2603:10b6:510:1f4::16) by DS0PR11MB7831.namprd11.prod.outlook.com (2603:10b6:8:de::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7202.34; Wed, 24 Jan 2024 05:18:26 +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; Wed, 24 Jan 2024 05:18:26 +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+vm5oXSwEmW6mjsJvC8kbDftWKAgADHFQCAAI7AgIAEKeOAgABefoCAAuIIAA== Date: Wed, 24 Jan 2024 05:18:26 +0000 Message-ID: <4906b7e2-0ddb-4d3c-a48b-e16278f2d649@microchip.com> 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> In-Reply-To: <20240122-stark-duress-2f59294dcf27@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_|DS0PR11MB7831:EE_ x-ms-office365-filtering-correlation-id: acaafc70-01ae-4559-c235-08dc1c9be4d2 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: uBZw+s71Snf4zB/17jMfYOXmfpgr1cWP/annI9IjmtNuMAVsEhKTlsSBDGbv5izdatcXUEP/1ue9NjhIrNWTIGSMzMMxyW8v3zD/tw1qBDYJ8drY4HgUmTD4B5A+Jzg1X1wlgVoUoT7dDRABvZWUE2emxcrl/l0vRSFAF0OF3drpSSy2ZU5zetvcNTBFX/H+dWrLzpqsME84pekB4LeWfDFKklqXf/2gM59jtJ/i4oQeOV6CLr4d/TmLC0+Idqx9QicZrXcqhuzdjyvzmsZAAsHWj25mZV4wznZVa8mQfs1x8+AOmjuOsgriQxoXg8E12Etrn/4+HMDLm1o967G6NJQ2ndfgXx6BjEMFBYpoCgCz9nD3GZd2EItbjCfZUtNdE4mgL7TlMe2ehx6IOcc/zAj2RjZqVCZHw1xgKb9qlLCQx87Bh1dt9oezAJqQLTV19k3EGyI6cVO9jFJgQ+YeVX5jG4NEjhgTZ4JCoNRlKu2FkGDZmemJwV+817/ZR+3OutdxEv+y0qNCQXg9bvrJrlLz95qJ/Ei5Apj91JVDMl0F9wI4GkcZaVqw6M3gVCFsAzSRddu6CtjVA5+7NGi4DjVE9KOThXtyFK7Ij9TN7n4AL2hnIDZGLGsijB9lE9NFueOgEyMMrrKN9I9i2BHAgZlCeYXqRS8DbK3GZbvOiLotZCPz9H8GtwqqF+1Pu4OY 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)(376002)(136003)(366004)(39860400002)(396003)(346002)(230922051799003)(451199024)(64100799003)(1800799012)(186009)(6512007)(64756008)(66476007)(66556008)(6506007)(6486002)(66946007)(66446008)(53546011)(71200400001)(478600001)(6916009)(8676002)(316002)(8936002)(76116006)(54906003)(107886003)(26005)(2616005)(83380400001)(2906002)(7416002)(5660300002)(4326008)(41300700001)(38070700009)(36756003)(38100700002)(122000001)(86362001)(31696002)(31686004)(45980500001);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?eGRiNE04MFdWU2RRTDJDL3lKS2g3RkZ2UmRLUkxLY1FGM0pBaHcvSmMwTzRH?= =?utf-8?B?aWdwMUhxVkVrOW1MNTRYM2UzMW1kZmhXK0VSaHpnQndYcnNBVVJ2clQzem9O?= =?utf-8?B?d0l3S1NCblJZY1hscGIxRTV6WG9PNC9iaGc0ZDZKZGpDQWNpV3Z2MWdoeUYz?= =?utf-8?B?Y3g5NVNxNHUwZ0luZnV6OFdRaWxudzJWdEtFVEZzeU45VHFGWEc5SnhWMWZh?= =?utf-8?B?NEhIKzc5aENpUU0yNm1zV3JPdlZ3KzljbkdmRU5HNWFKUmduWkR5L0VUVmpj?= =?utf-8?B?bHBybXJmWkp0MVJ4Um4wZGcvUTBqc25mQ2pLNjdueUR4QmJESzFnTjd0QmQw?= =?utf-8?B?U3A4WnpQQlpxUjNQUHdNdEwrVXhsb3Nra3dZSC9wZnhvQVMwY1FhRUJOcXRs?= =?utf-8?B?aXFJZE1SN09BdE03OUVkTHVSbFhEbUVoZFN4ak82aFBqVUM1a21rRFVTSXdG?= =?utf-8?B?UHRZZUM0YXBNSXEyRFF2c2JBcWd1NndkaVJLNWRoY3FPOTEwbzBKV1VlaVQv?= =?utf-8?B?NGFLT0k4ZHFTaHhrdDIrN2xDVEtHMkdDMElUSU9oY2dvZHFIcFc2aXc2S3hB?= =?utf-8?B?YWRySG5RYTlrSm8zTGcybEpvazFqdFFkNnZkbVFQbjJuSjNnbjhuYXNPWXZJ?= =?utf-8?B?NkJUQ3pVZSswcGpyLzhKRitxL1ZTbG1yY04wdG13MmxqTVMxVW1kQytqTDF3?= =?utf-8?B?bHJ3bEVIcWNKcjJZRWVpbkExMXROT2VWN2NIVFpFcjMxRGQ5Rm9uMU5WNmIw?= =?utf-8?B?KzI0RDMzN1VzRW51YVc3WEZ4blQrcmUvNm96azZhZkNHUmJPMlZqZ09tNEVD?= =?utf-8?B?NXBUallvZUZEcTN6VEY1MmFMWG9BMGdmLzY0Z0FsTWFvRUFkNXBLSkJ1TkhL?= =?utf-8?B?czkrQkJUT2c4Qk9ucTlqY3dGRGNIWTZpZDdrU1Q5S0haTmRPVWMrbERUbW1B?= =?utf-8?B?YTBGejJsQmw3RkZwMDhsbmlOWFkzVzNuYktaOU43bGRuSEU3eHF5bnNHTGxx?= =?utf-8?B?UzI2L0VhSEpiNm5TMG8yWldFbU9paHF4QlVoOWdnYjlwaXdJYVh6emQ5SlBI?= =?utf-8?B?RDFYb2l6ZHlFUHA2QklJRnFCOXJ3cFJUZXFsZklzL1REOW1rWXdrS2pjM1lT?= =?utf-8?B?ZGtTN1Nuay82TCttYWdVNlkzWnZLNnVVOWRMU0kvYXlKd1lEQ1pOWXBISHJj?= =?utf-8?B?azdQS01oQkNCU1hRQnJVc29Yb3F5dWNhVmZDMm1kN1lIb2g5d3VZWGJjc3RJ?= =?utf-8?B?MWZMRnNrU2tBb1NMNko3elJ4dmFnVFB0TU5MVTFCa0F1MFdaR2NUT1FUWFpG?= =?utf-8?B?UHVCa09aY1Y0eUNhLzg2cERmakduQmljVHRsNjZlejgxKzk4aVI0TGw1aTQv?= =?utf-8?B?RHQvMGJ5ZktWWlJqa3hreXdGSTJhOFZhZWU3MmVMNnZJeWZxNHB0b2FTdEFE?= =?utf-8?B?T1NkNmRDZG56Z1p5VHpoNWMzY2VJVTZXYmpYYW51VjF5ZHhBWE13c2ZFK3dj?= =?utf-8?B?T1RLR0k5NHNHMkxXM1I1WjAraDBXdVRwT1FnZnhTbzZHM1pid3o5U0xPZXJs?= =?utf-8?B?RDhaWTU5cVRqb1J5VUlyYWZkU1RUM2E0VnRhUWVoMytJQnFoSlFsNVl1WHQy?= =?utf-8?B?ZUNRL1ovOW8vcC9oQ2tGRVRudkFQS25SVDkrWGMwWXNvWmZjWTVON2ZGcy96?= =?utf-8?B?ZkRyMkZ4Mk92Vy9qRk1JZFgxMDVEeHNpYU1tZk0xOHZOY3Q2U1ZEVWtjUjdK?= =?utf-8?B?bXpab2hoQUY3dDdHVmlWT2F1L1pSay8wK0l5RkJQbzBUU1hGQ1hUVU1ZS1Y4?= =?utf-8?B?MC92dWJKelpnbDRMWlNsRk5pTUd6TFpFV2xDeXpETHJRSW5TQnpwVHRFUkZm?= =?utf-8?B?SE5xd2FXbStwOEYvejI3N3VCZTQ5ckFKKytFMzM0UUtwUmZhMmJTUGgrZkox?= =?utf-8?B?MFlUNnFZenU1Nzd1Ti9UN1VQWnpSYllSSlc2eEpZNWFtc2tacU5Jck56TDNj?= =?utf-8?B?ZUVJRmE3dk1YMm83RlE1TnlnN25FVSt3d3MrZmN5ZEtlb0FtZC9BSDM4VmVG?= =?utf-8?B?ZlVtSzZvWVRINDRPUzlESDdsUER0WERuaTArUE1DNytpWSsydk1ROW9ESjJt?= =?utf-8?Q?WB6JAT/skCpZtHuM++s7BYWsD?= 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: acaafc70-01ae-4559-c235-08dc1c9be4d2 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2024 05:18:26.3928 (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: iGanHChSa+Na7l9cCwy/i0kdGeK/GxgbLBrWigu58A0irdKo3b90s2Tn3rYL8UN5D/GSZOvpGyxvlyYzPEl2HQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR11MB7831 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240123_211859_562354_806926BE X-CRM114-Status: GOOD ( 17.20 ) 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 & 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. -- Thanks, Dharma B. > > Cheers, > Conor. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel