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 X-Spam-Level: X-Spam-Status: No, score=-9.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BF706C433DF for ; Tue, 13 Oct 2020 23:30:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5AB6022200 for ; Tue, 13 Oct 2020 23:30:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388556AbgJMXaw convert rfc822-to-8bit (ORCPT ); Tue, 13 Oct 2020 19:30:52 -0400 Received: from mga18.intel.com ([134.134.136.126]:63710 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726773AbgJMXaw (ORCPT ); Tue, 13 Oct 2020 19:30:52 -0400 IronPort-SDR: MYNgG1A7tSH/EpqImiWJCliMLxcn50noY5aO2Nhi2CIoZna0FiFm+h4aE0WO2um/KNWFQauLiD alOWranzGV7g== X-IronPort-AV: E=McAfee;i="6000,8403,9773"; a="153837618" X-IronPort-AV: E=Sophos;i="5.77,372,1596524400"; d="scan'208";a="153837618" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Oct 2020 16:30:50 -0700 IronPort-SDR: 235LoJrnDi8tb/2MVYVbqUho211EXcnyCLEh3YDOE9lJvmMGsuGANCF6MixwASEPbaW4LE6+xF xwG/25jfLLIA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.77,372,1596524400"; d="scan'208";a="345438754" Received: from irsmsx606.ger.corp.intel.com ([163.33.146.139]) by fmsmga004.fm.intel.com with ESMTP; 13 Oct 2020 16:30:49 -0700 Received: from orsmsx610.amr.corp.intel.com (10.22.229.23) by IRSMSX606.ger.corp.intel.com (163.33.146.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Wed, 14 Oct 2020 00:30:47 +0100 Received: from orsmsx610.amr.corp.intel.com ([10.22.229.23]) by ORSMSX610.amr.corp.intel.com ([10.22.229.23]) with mapi id 15.01.1713.004; Tue, 13 Oct 2020 16:30:46 -0700 From: "Paauwe, Bob J" To: Rob Herring , "Chrisanthus, Anitha" CC: "devicetree@vger.kernel.org" , Neil Armstrong , "Dea, Edmund J" , "dri-devel@lists.freedesktop.org" , "Vetter, Daniel" , "sam@ravnborg.org" Subject: RE: [PATCH v9 1/5] dt-bindings: display: Add support for Intel KeemBay Display Thread-Topic: [PATCH v9 1/5] dt-bindings: display: Add support for Intel KeemBay Display Thread-Index: AQHWndgeA8gVyqifRECc4bPveICdhKmPcYSAgAW2nACAAQB6AIAAA2rw Date: Tue, 13 Oct 2020 23:30:46 +0000 Message-ID: References: <1602205443-9036-1-git-send-email-anitha.chrisanthus@intel.com> <1602205443-9036-2-git-send-email-anitha.chrisanthus@intel.com> <20201013154236.GA3562909@bogus> In-Reply-To: <20201013154236.GA3562909@bogus> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.5.1.3 dlp-reaction: no-action x-originating-ip: [10.22.254.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org > -----Original Message----- > From: dri-devel On Behalf Of Rob > Herring > Sent: Tuesday, October 13, 2020 8:43 AM > To: Chrisanthus, Anitha > Cc: devicetree@vger.kernel.org; Neil Armstrong ; > Dea, Edmund J ; dri-devel@lists.freedesktop.org; > Vetter, Daniel ; sam@ravnborg.org > Subject: Re: [PATCH v9 1/5] dt-bindings: display: Add support for Intel KeemBay > Display > > On Tue, Oct 13, 2020 at 12:24:38AM +0000, Chrisanthus, Anitha wrote: > > Hi Neil, > > > > Thanks for your review, please see my reply inline. > > > > > -----Original Message----- > > > From: Neil Armstrong > > > Sent: Friday, October 9, 2020 2:10 AM > > > To: Chrisanthus, Anitha ; dri- > > > devel@lists.freedesktop.org; devicetree@vger.kernel.org; Vetter, Daniel > > > > > > Cc: Dea, Edmund J ; sam@ravnborg.org > > > Subject: Re: [PATCH v9 1/5] dt-bindings: display: Add support for Intel > > > KeemBay Display > > > > > > Hi, > > > > > > On 09/10/2020 03:03, Anitha Chrisanthus wrote: > > > > This patch adds bindings for Intel KeemBay Display > > > > > > > > v2: review changes from Rob Herring > > > > > > > > Signed-off-by: Anitha Chrisanthus > > > > --- > > > > .../bindings/display/intel,keembay-display.yaml | 99 > > > ++++++++++++++++++++++ > > > > 1 file changed, 99 insertions(+) > > > > create mode 100644 > > > Documentation/devicetree/bindings/display/intel,keembay-display.yaml > > > > > > > > diff --git a/Documentation/devicetree/bindings/display/intel,keembay- > > > display.yaml b/Documentation/devicetree/bindings/display/intel,keembay- > > > display.yaml > > > > new file mode 100644 > > > > index 0000000..a38493d > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/display/intel,keembay- > > > display.yaml > > > > @@ -0,0 +1,99 @@ > > > > +# SPDX-License-Identifier: GPL-2.0-only > > > > +%YAML 1.2 > > > > +--- > > > > +$id: http://devicetree.org/schemas/display/intel,keembay- > > > display.yaml# > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > + > > > > +title: Devicetree bindings for Intel Keem Bay display controller > > > > + > > > > +maintainers: > > > > + - Anitha Chrisanthus > > > > + - Edmond J Dea > > > > + > > > > +properties: > > > > + compatible: > > > > + const: intel,kmb_display > > > > + > > > > + reg: > > > > + items: > > > > + - description: Lcd registers range > > > > + - description: Mipi registers range > > > > > > Looking at the registers, the MIPI transceiver seems to be a separate IP, > > > same for D-PHY which should have a proper PHY driver instead of beeing > > > handled > > > here. > > > > > The LCD, MIPI DSI, DPHY and MSSCAM as a group, are considered the > > display subsystem for Keem Bay. As such, there are several > > interdependencies that make splitting them up next to impossible and > > Please detail what those inter-dependencies are. It's doubtful that you > have anything we have not had to deal with in other SoCs. > > > currently we do not have the resources available for that effort. > > That is certainly not justification for accepting this. > > Rob Hi Rob, the wording was probably a bit exaggerated and you're right in that there it's not unique from a hardware perspective. The problem we have (and I know, it's our problem, not yours) is that our program required us to develop this internally first and then try to upstream it. So now that we've put a large effort into developing and testing the driver, it's very difficult for us to justify the resources to re-design it to better match the design of other SOC display drivers. We did review other SOC display drivers before creating this and thought that we were following the best practices for the design. I fully agree that lack of resources is not justification for not fixing something broken. But on the flip side, neither is changing the design because it could be "better" justification for not accepting it. If there is something wrong with the driver and it will cause problems in the future, then please, let us know. That would provide the data needed to justify additional effort. Bob > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel