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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 94C43C7EE23 for ; Wed, 7 Jun 2023 08:40:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238568AbjFGIkZ convert rfc822-to-8bit (ORCPT ); Wed, 7 Jun 2023 04:40:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44066 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238524AbjFGIkV (ORCPT ); Wed, 7 Jun 2023 04:40:21 -0400 Received: from gloria.sntech.de (gloria.sntech.de [185.11.138.130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 203571706; Wed, 7 Jun 2023 01:40:14 -0700 (PDT) Received: from ip5b412278.dynamic.kabel-deutschland.de ([91.65.34.120] helo=diego.localnet) by gloria.sntech.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1q6oi6-0006LM-Ch; Wed, 07 Jun 2023 10:40:06 +0200 From: Heiko =?ISO-8859-1?Q?St=FCbner?= To: Conor Dooley Cc: Keith Zhao , Shengyu Qu , dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org, David Airlie , Daniel Vetter , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Emil Renner Berthing , Paul Walmsley , Palmer Dabbelt , Albert Ou , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , Philipp Zabel , Sumit Semwal , christian.koenig@amd.com, Bjorn Andersson , Shawn Guo , Jagan Teki , Chris Morgan , Jack Zhu , Shengyang Chen , Changhuang Liang Subject: Re: [PATCH 1/9] dt-bindings: display: Add yamls for JH7110 display subsystem Date: Wed, 07 Jun 2023 10:40:04 +0200 Message-ID: <3560873.iIbC2pHGDl@diego> In-Reply-To: <20230606-geometry-blurb-1f0f07d4bf6a@spud> References: <20230602074043.33872-1-keith.zhao@starfivetech.com> <1991848.PYKUYFuaPT@diego> <20230606-geometry-blurb-1f0f07d4bf6a@spud> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org Am Mittwoch, 7. Juni 2023, 00:37:53 CEST schrieb Conor Dooley: > On Wed, Jun 07, 2023 at 12:22:33AM +0200, Heiko Stübner wrote: > > Am Dienstag, 6. Juni 2023, 20:41:17 CEST schrieb Shengyu Qu: > > > > On Fri, Jun 02, 2023 at 03:40:35PM +0800, Keith Zhao wrote: > > > >> Add bindings for JH7110 display subsystem which > > > >> has a display controller verisilicon dc8200 > > > >> and an HDMI interface. > > > > >> +description: > > > >> + The StarFive SoC uses the HDMI signal transmiter based on innosilicon IP > > > > Is innosilicon the same thing as verisilicon? Also > > > > s/transmiter/transmitter/, both here and in the title. > > > > > > I think that is not the same, I remember Rockchip has used a HDMI > > > transmitter from > > > > > > Innosilicon, and there is a existing driver for that in mainline. > > > > Yep, I think Innosilicon is the company you turn to when you want to save > > a bit of money ;-) . In the bigger SoCs Rockchip most of the time uses > > Designware hdmi blocks and looking at the history only the rk3036 ever > > used an Innosilicon block. > > > > Looking at the history, 2016 really was a long time ago :-D. > > > > > So Keith, if that's true, I think it is better to seperate the HDMI > > > stuff and reuse existing driver. > > > > I'm not so sure about that - at least from a cursory glance :-) . > > > > The registers do look slightly different and I don't know how much > > the IP changed between the rk3036-version and the jh7110 version. > > > > At the very least, I know my rk3036 board isn't booting right now, so > > I can't really provide help for generalizing the rockchip-driver. > > > > At the very least both the binding and driver could drop the "starfive-hdmi" > > and actually use the Innosilicon in the naming somewhere, so that it's > > clear for future developers :-) > > Seeing "based on" always makes me a little bit nervous to be honest when > it comes to using a compatible from the IP. Is it the IP? What version > is it? etc. Perhaps "starfive,jh7110-hdmi" & falling back to some sort > of "innosilicon,hdmi" would be more future/IP-silliness proof. > Driver can always be generic & bind against "innosilicon,hdmi" until > that becomes impossible. what Connor said makes a lot of sense. Just name the compatible after the actual implementation - aka "starfive,jh7110-hdmi" . This is similar to what the rk3036 does with its "rockchip,rk3036-inno-hdmi". That way you're nicely independent and future proof. Heiko