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 381EDC4743C for ; Mon, 21 Jun 2021 14:13:06 +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 018476124B for ; Mon, 21 Jun 2021 14:13:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 018476124B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=amarulasolutions.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:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=W0OL+2kTr0nvmB4/sS5dIPrhKL9qaaj8y9wlFOIfAnI=; b=PGYnQ1iAEQ7LlB pqCSMqdwg9uncWZQDpvigbBnpHArz60YIisfd/fDgcHuHS5aro76yHmNfzrsu49jB5tTrZ46ZPwIm 1Q7f9ADqoDsYIbm+6f8aQdtS9sPQFVxaDxWlyxoJjWioDejERXHcnzZxmI0ahDJ/DUewvwH8EeeMl VYjZrTgAKGP5hK0FaWRWlbyEYJc63uDjrhEfveyob61Ssje23tHgEr5ju6Ar2d75XiqRiXNJc2H4M S1lWG8IiQKowZYV/RVpkdhsf4T/Yt8Cj2h1K9XFHWecW5lvden/YHb+xSAzGHBGpqPg91qjzYoBNd BuleCoWMuNi099iSOhdA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lvKe6-003ghK-EW; Mon, 21 Jun 2021 14:11:26 +0000 Received: from mail-ed1-x52b.google.com ([2a00:1450:4864:20::52b]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lvKe0-003geJ-TY for linux-arm-kernel@lists.infradead.org; Mon, 21 Jun 2021 14:11:23 +0000 Received: by mail-ed1-x52b.google.com with SMTP id h17so9233495edw.11 for ; Mon, 21 Jun 2021 07:11:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amarulasolutions.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gW2DuBp6PYxR8VdUAWk5TQ4o8Fw8pxr8PTkYGeTMSPg=; b=XSZpRh7TbioQD1n+w20pDt4bP2qKvUorbYRFYXZVsiyQg9dcl0ixn/FWFxJnfvXVOe xt9Nkwq4ypPNapbuFCcD5YgUzpUFWL7QHHh+wvUTCtOwLRp/xzMd/j+VcHKxCIsVBDgb m80MbSnx/JKLLJe78YWUx2IqRQrLBki/oAC+U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gW2DuBp6PYxR8VdUAWk5TQ4o8Fw8pxr8PTkYGeTMSPg=; b=npRJhfzjamsZK9f1r0TOL2oWtV2dOK7vSGrBu3yZaH1Z9jxuUGTAf25R5bzLvc0NCD wAo6k9gaS8Kaj2Anqd4AjrVHiPoiBunpIEGOUs+jkkAPE/6C5l+C/U4LdPtUDGdQVzCy smRz51p9dF+92iezrOSe8YXvyMy/qtYGyDVkhDE6O9S2llkq5+r4g9gtwyl4NzNG6ajn LWa7GrzfxQMKnyE46Gv1xMD1HZaPmrKQCnMk+/HqO7ArDgDY3JIZhAVXv2FetQDGDtcn 14yyjVcjBgEhF6mKnuHlumGe0yBUUihd9Vc0ExZ8VSat16ZGUs9XNc/XxdKGStKUCJ9f /lrQ== X-Gm-Message-State: AOAM532vvyVmir2kSQb2ZVYfuYLmnSa2+akH43JIwpCxbCO7GAlq6fxR Fn+RRmfdB8ZrrJM/ZK7H+GScAPUhfZ5Hb/6qo6hzCA== X-Google-Smtp-Source: ABdhPJxG9P77+APKg6mp1XlCvL5d1ONtJYaEIcmdQg/8dpmek2fPUH4x88H44HB+ti79K690gOn7IZf82p4zd4tD0WA= X-Received: by 2002:a05:6402:22a1:: with SMTP id cx1mr19007627edb.338.1624284679150; Mon, 21 Jun 2021 07:11:19 -0700 (PDT) MIME-Version: 1.0 References: <20200707101912.571531-1-maxime@cerno.tech> In-Reply-To: From: Jagan Teki Date: Mon, 21 Jun 2021 19:41:07 +0530 Message-ID: Subject: Re: [PATCH] drm/vc4: dsi: Only register our component once a DSI device is attached To: Laurent Pinchart 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210621_071121_126945_16930A68 X-CRM114-Status: GOOD ( 57.79 ) 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 Laurent, On Mon, Jun 21, 2021 at 6:26 PM Laurent Pinchart wrote: > > Hi Dave, > > 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? Thanks, Jagan. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel