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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2CD27C433F5 for ; Tue, 19 Oct 2021 06:50:20 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id DF68560F56 for ; Tue, 19 Oct 2021 06:50:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org DF68560F56 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ideasonboard.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 126FC6E059; Tue, 19 Oct 2021 06:50:19 +0000 (UTC) Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [213.167.242.64]) by gabe.freedesktop.org (Postfix) with ESMTPS id 1488D6E059 for ; Tue, 19 Oct 2021 06:50:18 +0000 (UTC) Received: from pendragon.ideasonboard.com (62-78-145-57.bb.dnainternet.fi [62.78.145.57]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 9F6F312A; Tue, 19 Oct 2021 08:50:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1634626215; bh=oJYsDdKLUakPqw9h1bXi8+Pb1dLvnArcaFFmBay2viU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=XSekLkn32Iq+m7kSZE3sJlMJgl8CXfD09jgTdHWiANVpa3JNPcYfRIMkmKWBwXd+G rpfQVpSyFDJQ4MFlzQtP0/+QzCJVr0iQZJGDPAODn5QweYSRuOEJdAH858jkjbyPuu 5YouweI8hKsJqS3m9ndtOKq2iJHy8FjGEAMzaf7o= Date: Tue, 19 Oct 2021 09:49:57 +0300 From: Laurent Pinchart To: Marek Vasut Cc: dri-devel@lists.freedesktop.org, Rob Herring , Sam Ravnborg , devicetree@vger.kernel.org Subject: Re: [PATCH v5 1/2] dt-bindings: display: bridge: lvds-codec: Document pixel data sampling edge select Message-ID: References: <20211017001204.299940-1-marex@denx.de> <4f235f45-5c03-eaeb-69ac-3d801a1dd58c@denx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4f235f45-5c03-eaeb-69ac-3d801a1dd58c@denx.de> X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Hi Marek, On Tue, Oct 19, 2021 at 12:18:11AM +0200, Marek Vasut wrote: > On 10/18/21 9:57 PM, Laurent Pinchart wrote: > > Hi, > > >>>> diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml > >>>> index 1faae3e323a4..708de84ac138 100644 > >>>> --- a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml > >>>> +++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml > >>>> @@ -79,6 +79,14 @@ properties: > >>>> - port@0 > >>>> - port@1 > >>>> > >>>> + pclk-sample: > >>>> + description: > >>>> + Data sampling on rising or falling edge. > >>>> + enum: > >>>> + - 0 # Falling edge > >>>> + - 1 # Rising edge > >>>> + default: 0 > >>>> + > >>> > >>> Shouldn't this be moved to the endpoint, the same way data-mapping is > >>> defined as an endpoint property ? > >> > >> The strapping is a chip property, not port property, so no. > > > > For this particular chip that's true. I'm still not convinced overall. > > For some cases it could be a per-port property > > Can you be more specific about "some cases" ? I'm thinking about bridges that could have multiple parallel inputs. > > , and moving it there for > > lvds-codec too could allow implementing helpers to parse DT properties, > > without much drawback for this particular use case as far as I can see. > > It's hard to predict the future with certainty of course, so I won't > > insist. > > The DT bindings and the OS drivers are separate thing, we really > shouldn't start bending DT bindings so that they would fit nicely with a > specific OS driver model. DT bindings are not holy beings that live in a mythical heaven way above the mere mortal drivers, they would be useless without implementations. It's not about bending them, which I regularly push against during review, but about structuring them in a way that facilitates implementations when all other things are equal. As I said, despite wondering whether or not it would be better to move the property to the endpoint (and that was a genuine open question), I won't insist in this case. -- Regards, Laurent Pinchart