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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,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 5F35BC43334 for ; Thu, 6 Sep 2018 12:25:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1486820652 for ; Thu, 6 Sep 2018 12:25:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="FmU7EmQD" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1486820652 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ideasonboard.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728489AbeIFRBK (ORCPT ); Thu, 6 Sep 2018 13:01:10 -0400 Received: from perceval.ideasonboard.com ([213.167.242.64]:39786 "EHLO perceval.ideasonboard.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726436AbeIFRBK (ORCPT ); Thu, 6 Sep 2018 13:01:10 -0400 Received: from avalon.localnet (38-237-62-37.mobileinternet.proximus.be [37.62.237.38]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 4741B119E; Thu, 6 Sep 2018 14:25:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1536236752; bh=oTWt0i8tpHR94qs+kZq4+rnkmm4BrLC9HhAoBJSKkTo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FmU7EmQDLmDiztTquyqYwL/SXoYqUkQ9wxqMtZh8pgOe4kLfNqwp+CgL1NKUxNuwP A3Ixrv88UGJtazLCcrO/GychHapeyPlblCz61aHPeL/Msv4T8n+OcsY9yLQD61+RH3 Ba0PZ3PM5o3LiGb8u6o4FGJSCuAmLKSvKRXLVclU= From: Laurent Pinchart To: Linus Walleij Cc: Stefan Agner , Dave Airlie , Rob Herring , Mark Rutland , Shawn Guo , Sascha Hauer , Philipp Zabel , Sascha Hauer , Fabio Estevam , NXP Linux Team , Archit Taneja , Andrzej Hajda , Gustavo Padovan , Maarten Lankhorst , sean@poorly.run, Marcel Ziswiler , max.krummenacher@toradex.com, "open list:DRM PANEL DRIVERS" , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Linux ARM , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH 1/6] drm/bridge: use bus flags in bridge timings Date: Thu, 06 Sep 2018 15:25:56 +0300 Message-ID: <10044412.4MiZRujKJI@avalon> Organization: Ideas on Board Oy In-Reply-To: References: <20180905052113.21262-1-stefan@agner.ch> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Linus, On Thursday, 6 September 2018 14:07:41 EEST Linus Walleij wrote: > On Wed, Sep 5, 2018 at 8:32 PM Stefan Agner wrote: > > On 05.09.2018 00:44, Laurent Pinchart wrote: > > > > Good point! I actually really don't like that we use the same flags here > > but from a different perspective. Especially since the flags defines > > document things differently: > > > > /* drive data on pos. edge */ > > #define DRM_BUS_FLAG_PIXDATA_POSEDGE (1<<2) > > /* drive data on neg. edge */ > > #define DRM_BUS_FLAG_PIXDATA_NEGEDGE (1<<3) > > Maybe a stupid comment from my side, but can't we just change the > documentation to match the usecases? > > /* Trigger pixel data latch on positive edge */ > #define DRM_BUS_FLAG_PIXDATA_POSEDGE (1<<2) The flags are used for the drm_connector bus_flags field, and really mean driving on the positive/negative edges. We this can't change their meaning like this. > > Using the opposite perspective would also need translation in crtc > > drivers... So far no driver uses sampling_edge. > > > > I would prefer if we always use the meaning as documented by the flags. > > > > I guess we would need to convert DRM_BUS_FLAG_PIXDATA_POSEDGE -> > > DRM_BUS_FLAG_PIXDATA_NEGEDGE. > > > > Linus Walleij, you added sampling edge, any thoughts? > > I just thought it was generally useful to have triggering edge encoded > into the bridge as it makes it clear that this edge is something > that is a delayed version of the driving edge which is subject to > clock skew caused by the speed of electrons in silicon and > copper and slew rate caused by parasitic capacitance. I agree that we need both the driving and sampling edge. In many case they will be opposite, and providing some kind of appropriate defaults in APIs is fine by me, but we need a way to specify both when needed. -- Regards, Laurent Pinchart From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laurent Pinchart Subject: Re: [PATCH 1/6] drm/bridge: use bus flags in bridge timings Date: Thu, 06 Sep 2018 15:25:56 +0300 Message-ID: <10044412.4MiZRujKJI@avalon> References: <20180905052113.21262-1-stefan@agner.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Linus Walleij Cc: Stefan Agner , Dave Airlie , Rob Herring , Mark Rutland , Shawn Guo , Sascha Hauer , Philipp Zabel , Sascha Hauer , Fabio Estevam , NXP Linux Team , Archit Taneja , Andrzej Hajda , Gustavo Padovan , Maarten Lankhorst , sean@poorly.run, Marcel Ziswiler , max.krummenacher@toradex.com, "open list:DRM PANEL DRIVERS" , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" List-Id: devicetree@vger.kernel.org Hi Linus, On Thursday, 6 September 2018 14:07:41 EEST Linus Walleij wrote: > On Wed, Sep 5, 2018 at 8:32 PM Stefan Agner wrote: > > On 05.09.2018 00:44, Laurent Pinchart wrote: > > > > Good point! I actually really don't like that we use the same flags here > > but from a different perspective. Especially since the flags defines > > document things differently: > > > > /* drive data on pos. edge */ > > #define DRM_BUS_FLAG_PIXDATA_POSEDGE (1<<2) > > /* drive data on neg. edge */ > > #define DRM_BUS_FLAG_PIXDATA_NEGEDGE (1<<3) > > Maybe a stupid comment from my side, but can't we just change the > documentation to match the usecases? > > /* Trigger pixel data latch on positive edge */ > #define DRM_BUS_FLAG_PIXDATA_POSEDGE (1<<2) The flags are used for the drm_connector bus_flags field, and really mean driving on the positive/negative edges. We this can't change their meaning like this. > > Using the opposite perspective would also need translation in crtc > > drivers... So far no driver uses sampling_edge. > > > > I would prefer if we always use the meaning as documented by the flags. > > > > I guess we would need to convert DRM_BUS_FLAG_PIXDATA_POSEDGE -> > > DRM_BUS_FLAG_PIXDATA_NEGEDGE. > > > > Linus Walleij, you added sampling edge, any thoughts? > > I just thought it was generally useful to have triggering edge encoded > into the bridge as it makes it clear that this edge is something > that is a delayed version of the driving edge which is subject to > clock skew caused by the speed of electrons in silicon and > copper and slew rate caused by parasitic capacitance. I agree that we need both the driving and sampling edge. In many case they will be opposite, and providing some kind of appropriate defaults in APIs is fine by me, but we need a way to specify both when needed. -- Regards, Laurent Pinchart From mboxrd@z Thu Jan 1 00:00:00 1970 From: laurent.pinchart@ideasonboard.com (Laurent Pinchart) Date: Thu, 06 Sep 2018 15:25:56 +0300 Subject: [PATCH 1/6] drm/bridge: use bus flags in bridge timings In-Reply-To: References: <20180905052113.21262-1-stefan@agner.ch> Message-ID: <10044412.4MiZRujKJI@avalon> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Linus, On Thursday, 6 September 2018 14:07:41 EEST Linus Walleij wrote: > On Wed, Sep 5, 2018 at 8:32 PM Stefan Agner wrote: > > On 05.09.2018 00:44, Laurent Pinchart wrote: > > > > Good point! I actually really don't like that we use the same flags here > > but from a different perspective. Especially since the flags defines > > document things differently: > > > > /* drive data on pos. edge */ > > #define DRM_BUS_FLAG_PIXDATA_POSEDGE (1<<2) > > /* drive data on neg. edge */ > > #define DRM_BUS_FLAG_PIXDATA_NEGEDGE (1<<3) > > Maybe a stupid comment from my side, but can't we just change the > documentation to match the usecases? > > /* Trigger pixel data latch on positive edge */ > #define DRM_BUS_FLAG_PIXDATA_POSEDGE (1<<2) The flags are used for the drm_connector bus_flags field, and really mean driving on the positive/negative edges. We this can't change their meaning like this. > > Using the opposite perspective would also need translation in crtc > > drivers... So far no driver uses sampling_edge. > > > > I would prefer if we always use the meaning as documented by the flags. > > > > I guess we would need to convert DRM_BUS_FLAG_PIXDATA_POSEDGE -> > > DRM_BUS_FLAG_PIXDATA_NEGEDGE. > > > > Linus Walleij, you added sampling edge, any thoughts? > > I just thought it was generally useful to have triggering edge encoded > into the bridge as it makes it clear that this edge is something > that is a delayed version of the driving edge which is subject to > clock skew caused by the speed of electrons in silicon and > copper and slew rate caused by parasitic capacitance. I agree that we need both the driving and sampling edge. In many case they will be opposite, and providing some kind of appropriate defaults in APIs is fine by me, but we need a way to specify both when needed. -- Regards, Laurent Pinchart