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 DBA24C433F5 for ; Thu, 6 Sep 2018 16:48:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7407E2083D for ; Thu, 6 Sep 2018 16:48:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=agner.ch header.i=@agner.ch header.b="g5BE+Kpl" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7407E2083D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=agner.ch 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 S1728239AbeIFVZO (ORCPT ); Thu, 6 Sep 2018 17:25:14 -0400 Received: from mail.kmu-office.ch ([178.209.48.109]:46750 "EHLO mail.kmu-office.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727738AbeIFVZO (ORCPT ); Thu, 6 Sep 2018 17:25:14 -0400 Received: from webmail.kmu-office.ch (unknown [IPv6:2a02:418:6a02::a3]) by mail.kmu-office.ch (Postfix) with ESMTPSA id 5C8725C08AC; Thu, 6 Sep 2018 18:48:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=agner.ch; s=dkim; t=1536252531; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZtMm+q5K0uLBEnCXOndLdPzPHG4bKRNCOaaBo9673O0=; b=g5BE+KplTNOf7ssvA+uBj9kLjMLvJJJpbxuYO/WYQ73KwKaC40ecrwinyYu87pu2FkM1fz 0UfA1hiziTocYtunf8e8dRCOtDw8F3JX2EpUniolWcXQCKllAin/qWjpMLt0sMQQqKUAyQ CEyyo2qZ6vk8GkEVcga8AlJeaT/LR94= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Date: Thu, 06 Sep 2018 09:48:51 -0700 From: Stefan Agner To: Laurent Pinchart Cc: Linus Walleij , 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 In-Reply-To: <10044412.4MiZRujKJI@avalon> References: <20180905052113.21262-1-stefan@agner.ch> <10044412.4MiZRujKJI@avalon> Message-ID: X-Sender: stefan@agner.ch User-Agent: Roundcube Webmail/1.3.4 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06.09.2018 05:25, Laurent Pinchart wrote: > 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. We do have pixel clock flags for displays, but also they are actually controller oriented: https://elixir.bootlin.com/linux/latest/source/include/video/display_timing.h#L15 I guess having different flags to denote driving and sampling edge independently would be ideal. But then, is there really a use case where it wouldn't be the exact opposite? The other bus flags are actually fine as is. I suggest to just stick with the bus flags as we have them now, at least for now. Alternatively, we could provide "consumer/bridge" oriented flags which use the same bit and just are the opposite of the controller oriented flags, e.g.: /* 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) /* sample data on neg. edge */ #define DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE (1<<2) /* sample data on pos. edge */ #define DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE (1<<3) -- Stefan