Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH v1 2/2] drm/tegra: Use drm_dp_aux_register_ddc/chardev()
 helpers
To:     Thierry Reding <thierry.reding@gmail.com>,
        Jonathan Hunter <jonathanh@nvidia.com>,
        Lyude Paul <lyude@redhat.com>,
        Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
        Maxime Ripard <mripard@kernel.org>,
        Thomas Zimmermann <tzimmermann@suse.de>,
        David Airlie <airlied@linux.ie>,
        Thomas Graichen <thomas.graichen@gmail.com>,
        dri-devel@lists.freedesktop.org, linux-tegra@vger.kernel.org,
        linux-kernel@vger.kernel.org
References: <20211107230821.13511-1-digetx@gmail.com>
 <20211107230821.13511-2-digetx@gmail.com>
 <YYk/jfcceun/Qleq@phenom.ffwll.local>
From:   Dmitry Osipenko <digetx@gmail.com>
Message-ID: <0a2c02ae-3fe1-e384-28d3-13e13801d675@gmail.com>
Date:   Mon, 8 Nov 2021 21:16:07 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <YYk/jfcceun/Qleq@phenom.ffwll.local>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk

08.11.2021 18:17, Daniel Vetter пишет:
> On Mon, Nov 08, 2021 at 02:08:21AM +0300, Dmitry Osipenko wrote:
>> Use drm_dp_aux_register_ddc/chardev() helpers that allow to register I2C
>> adapter separately from the character device. This fixes broken display
>> panel driver of Acer Chromebook CB5-311 that fails to probe starting with
>> v5.13 kernel when DP AUX registration order was changed. Tegra SOR driver
>> is never probed now using the new registration order because tegra-output
>> always fails with -EPROBE_DEFER due to missing display panel that requires
>> DP AUX DDC to be registered first. The offending commit made DDC to be
>> registered after SOR's output, which can't ever happen. Use new helpers
>> to restore the registration order and revive display panel.
> 
> This feels a bit backward, I think the clean solution would be to untangle
> the SOR loading from the panel driver loading, and then only block
> registering the overall drm_device on both drivers having loaded.

Sounds impossible.

1. DRM device can be created only when all components are ready, panel
is one of the components.

2. SOR driver is controlling panel and programs h/w based on panel presence.

3. Panel can't become ready until DP AUX DDC is created.

4. DP AUX DDC can't be created until DRM device is created.

5. Go to 1.

Even if there is an option to somehow rewrite Tegra DRM driver to
accommodate it to the desired driver model, it won't be something
portable to stable kernels.

> This here at least feels like a game of whack-a-mole, if like every driver
> needs its own careful staging of everything.

That is inevitable because each hardware design is individual.