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=-14.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 A50F5C4743C for ; Mon, 21 Jun 2021 14:16:43 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 751DA6124B for ; Mon, 21 Jun 2021 14:16:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 751DA6124B 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-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=2+HKYcy1deWcjO9WlDI7aJuU8gNQ8QXFLromwb8UNI0=; b=UYf2xSWfRaMagj kQhF01PtGBWCSvBHuas7uFtnbwrWbOxeLcd6KTcdiiF9JImR2jgEZob77DNEDqV8Gvei0T+YjAQnt 1ZzpQKL96LG5QWm8nYSuaUEmch7CRAHAp86hCxBnizd31txGrx1K9Td8JoihfmjOPGCUDWKhW6RsV t0et6AEDlFlO9eVoRBn9ccsGWoZA2OIYSa0yJJCXbtd9q9GdSIzOhrov8aquF1Q7bu26+VTYStExX e8KAWB2D3Qmx0Y1kcolDn6WlGp1BhUKKO7dyWZfJ7NibcMTUrWGpJu9XneYnsDisvWx2+6b+HJ/1y T6Sa2q74VcrByCATtU1w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lvKhH-003hoh-Bi; Mon, 21 Jun 2021 14:14:43 +0000 Received: from perceval.ideasonboard.com ([213.167.242.64]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lvKhD-003hn9-2p; Mon, 21 Jun 2021 14:14:41 +0000 Received: from pendragon.ideasonboard.com (62-78-145-57.bb.dnainternet.fi [62.78.145.57]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 5DC315C75; Mon, 21 Jun 2021 16:14:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1624284877; bh=+ijZcGgErRf9SanuSF2mZQpMGv5X/UoUh1FlzcKR980=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=mxylxRwyRfISf9L8jpkV9gaKB50jrdUVt44Nl6y/lk7t+sib/k3PJgnnaVmUe+DyH 2HdKUdB7w6cx1wdVoiFjC9a7YA/DmXWBDB+2Rh+lkaU1Wd6hb+t/+R7BpiGTREWLiv 6QMuhpZ4zeIalnjUXOYNidlpRrD1v6HWJc+h3RmQ= Date: Mon, 21 Jun 2021 17:14:11 +0300 From: Laurent Pinchart To: Jagan Teki Cc: Dave Stevenson , Marek Vasut , Tim Gover , Eric Anholt , linux-arm-kernel , LKML , DRI Development , Andrzej Hajda , bcm-kernel-feedback-list@broadcom.com, Maxime Ripard , Phil Elwell , Nicolas Saenz Julienne , linux-rpi-kernel@lists.infradead.org Subject: Re: [PATCH] drm/vc4: dsi: Only register our component once a DSI device is attached Message-ID: References: <20200707101912.571531-1-maxime@cerno.tech> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210621_071439_342288_9B1071A5 X-CRM114-Status: GOOD ( 57.35 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Jagan, On Mon, Jun 21, 2021 at 07:41:07PM +0530, Jagan Teki wrote: > On Mon, Jun 21, 2021 at 6:26 PM Laurent Pinchart wrote: > > On Mon, Jun 21, 2021 at 12:49:14PM +0100, Dave Stevenson wrote: > > > On Sun, 20 Jun 2021 at 23:49, Laurent Pinchart wrote: > > > > On Sun, Jun 20, 2021 at 09:42:27PM +0300, Laurent Pinchart wrote: > > > > > On Sun, Jun 20, 2021 at 03:29:03PM +0100, Dave Stevenson wrote: > > > > > > On Sun, 20 Jun 2021 at 04:26, Laurent Pinchart wrote: > > > > > > > > > > > > > > Hi Maxime, > > > > > > > > > > > > > > I'm testing this, and I'm afraid it causes an issue with all the > > > > > > > I2C-controlled bridges. I'm focussing on the newly merged ti-sn65dsi83 > > > > > > > driver at the moment, but other are affected the same way. > > > > > > > > > > > > > > With this patch, the DSI component is only added when the DSI device is > > > > > > > attached to the host with mipi_dsi_attach(). In the ti-sn65dsi83 driver, > > > > > > > this happens in the bridge attach callback, which is called when the > > > > > > > bridge is attached by a call to drm_bridge_attach() in vc4_dsi_bind(). > > > > > > > This creates a circular dependency, and the DRM/KMS device is never > > > > > > > created. > > > > > > > > > > > > > > How should this be solved ? Dave, I think you have shown an interest in > > > > > > > the sn65dsi83 recently, any help would be appreciated. On a side note, > > > > > > > I've tested the ti-sn65dsi83 driver on a v5.10 RPi kernel, without much > > > > > > > success (on top of commit e1499baa0b0c I get a very weird frame rate - > > > > > > > 147 fps of 99 fps instead of 60 fps - and nothing on the screen, and on > > > > > > > top of the latest v5.10 RPi branch, I get lock-related warnings at every > > > > > > > page flip), which is why I tried v5.12 and noticed this patch. Is it > > > > > > > worth trying to bring up the display on the v5.10 RPi kernel in parallel > > > > > > > to fixing the issue introduced in this patch, or is DSI known to be > > > > > > > broken there ? > > > > > > > > > > > > I've been looking at SN65DSI83/4, but as I don't have any hardware > > > > > > I've largely been suggesting things to try to those on the forums who > > > > > > do [1]. > > > > > > > > > > > > My branch at https://github.com/6by9/linux/tree/rpi-5.10.y-sn65dsi8x-marek > > > > > > is the latest one I've worked on. It's rpi-5.10.y with Marek's driver > > > > > > cherry-picked, and an overlay and simple-panel definition by others. > > > > > > It also has a rework for vc4_dsi to use pm_runtime, instead of > > > > > > breaking up the DSI bridge chain (which is flawed as it never calls > > > > > > the bridge mode_set or mode_valid functions which sn65dsi83 relies > > > > > > on). > > > > > > > > > > > > I ran it on Friday in the lab and encountered an issue with vc4_dsi > > > > > > should vc4_dsi_encoder_mode_fixup wish for a divider of 7 (required > > > > > > for this 800x1280 panel over 4 lanes) where it resulted in an invalid > > > > > > mode configuration. That resulted in patch [2] which then gave me > > > > > > sensible numbers. > > > > > > > > > > > > That branch with dtoverlay=vc4-kms-v3d and > > > > > > dtoverlay=vc4-kms-dsi-ti-sn65dsi83 created all the expected devices, > > > > > > and everything came up normally. > > > > > > It was a busy day, but I think I even stuck a scope on the clock lanes > > > > > > at that point and confirmed that they were at the link frequency > > > > > > expected. > > > > > > > > > > Thanks, I'll test your branch and will report the results. > > > > > > > > I had to apply the following diff to work around a crash: > > > > > > > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c > > > > index 55b6c53207f5..647426aa793a 100644 > > > > --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c > > > > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c > > > > @@ -525,6 +525,9 @@ static bool sn65dsi83_mode_fixup(struct drm_bridge *bridge, > > > > > > > > /* The DSI format is always RGB888_1X24 */ > > > > list_for_each_entry(connector, &ddev->mode_config.connector_list, head) { > > > > + if (!connector->display_info.bus_formats) > > > > + continue; > > > > + > > > > switch (connector->display_info.bus_formats[0]) { > > > > case MEDIA_BUS_FMT_RGB666_1X7X3_SPWG: > > > > ctx->lvds_format_24bpp = false; > > > > > > > > connector->display_info.bus_formats is NULL for the HDMI connectors, as > > > > I have nothing connected to them, as well as for the writeback > > > > connector. > > > > > > I'm now confused as to what I'm doing as my branch appears NOT to have > > > Marek's latest version of the driver as it doesn't have > > > sn65dsi83_mode_fixup. > > > I need to have another look at what's going on - I think I've got > > > branches confused when switching between machines :-( Remaking that > > > branch now. > > > > > > I do see that Marek has sent another patch around > > > sn65dsi83_mode_fixup, but it'll still dereference > > > connector->display_info.bus_formats[0] on all connectors. Shouldn't it > > > only be switching on the one connector that is connected to this > > > bridge, not HDMI or writeback connectors? I'm not totally clear on > > > which connectors are in that list. > > > https://patchwork.freedesktop.org/patch/440175/ > > > > The following series should fix the issue: > > > > [PATCH] drm/bridge: ti-sn65dsi83: Replace connector format patching with atomic_get_input_bus_fmts > > [PATCH 0/5] ti-sn65dsi83: Finalize transition to atomic operations > > Look like DSI on STM32MP1 seems broken even with these on top of > drm-misc/drm-misc-next , anything broken on the tree? No idea, I don't have a functional display on my RPi CM4 device yet, so I can't tell :-) -- Regards, Laurent Pinchart _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel