Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH v6 2/3] drm: bridge: Add support for Cadence MHDP DPI/DP
 bridge
To:     Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
        Yuti Amonkar <yamonkar@cadence.com>
CC:     <linux-kernel@vger.kernel.org>, <dri-devel@lists.freedesktop.org>,
        <devicetree@vger.kernel.org>, <robh+dt@kernel.org>,
        <maxime@cerno.tech>, <airlied@linux.ie>, <daniel@ffwll.ch>,
        <mark.rutland@arm.com>, <a.hajda@samsung.com>,
        <narmstrong@baylibre.com>, <jonas@kwiboo.se>,
        <jernej.skrabec@siol.net>, <praneeth@ti.com>, <jsarha@ti.com>,
        <mparab@cadence.com>, <sjakhade@cadence.com>
References: <1582712579-28504-1-git-send-email-yamonkar@cadence.com>
 <1582712579-28504-3-git-send-email-yamonkar@cadence.com>
 <20200311222053.GE4863@pendragon.ideasonboard.com>
From:   Tomi Valkeinen <tomi.valkeinen@ti.com>
Message-ID: <ef6a6e31-425f-c402-83ab-886221b4a0c3@ti.com>
Date:   Thu, 12 Mar 2020 09:13:06 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <20200311222053.GE4863@pendragon.ideasonboard.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Laurent,

On 12/03/2020 00:20, Laurent Pinchart wrote:
>> +	ret = load_firmware(mhdp);
>> +	if (ret)
>> +		goto phy_exit;
>> +
>> +	drm_bridge_add(&mhdp->bridge);
> What if someone starts using the bridge before the firmware is
> operational ? It seems that you should delay bridge registration until
> the firmware is loaded. It may make it possible to remove
> bridge_attached and solve the problem you mention in mhdp_fw_cb().

Handling the fw has been a bit of a pain... This is what we came up with to support all the 
combinations (built-in/module, fw-userspace-helper/direct load, single-output/multiple-outputs).

The idea is that when the driver is loaded and probed (with or without fw), the DP is "ready". If we 
don't have fw yet, everything looks fine, but the connector stays in disconnected state. When we get 
the fw, connector will get connected (only if there's a cable connected, of course).

If we register the bridge only when we have fw, two things can happen:

- If we get the fw only rather late (in case userspace fw helper), a userspace app (e.g. weston) 
could already have been started, and failed due to there being no DRM card.

- If we have two displays from the same display controller, say, DP and HDMI, the HDMI will only be 
available when the DP is available. If the DP fw, for some reason, cannot be loaded, we never get HDMI.

  Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki