On 4/18/23 15:42, Jagan Teki wrote:
On Tue, Apr 18, 2023 at 5:52 PM Brandon Cheo Fusi <fusibrandon13@xxxxxxxxx> wrote:Avoid aborting chip configuration after reading invalid IDs and instead issue a warning. I have a bunch of these chips and they all report "Vendor=0x00 Device=0x00:0x00 Version=0x00" but are successfully configured and go on to work just fine. Signed-off-by: Brandon Cheo Fusi <fusibrandon13@xxxxxxxxx> --- drivers/gpu/drm/bridge/chipone-icn6211.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/bridge/chipone-icn6211.c b/drivers/gpu/drm/bridge/chipone-icn6211.c index 0e37840cd..39de9a7c7 100644 --- a/drivers/gpu/drm/bridge/chipone-icn6211.c +++ b/drivers/gpu/drm/bridge/chipone-icn6211.c @@ -361,8 +361,7 @@ static void chipone_atomic_enable(struct drm_bridge *bridge, id[0], id[1], id[2], id[3]); if (id[0] != 0xc1 || id[1] != 0x62 || id[2] != 0x11) { - dev_dbg(icn->dev, "Invalid Chip IDs, aborting configuration\n"); - return; + dev_warn(icn->dev, "Invalid Chip IDs, configuration may fail\n");Did you test I2C-Configured ICN6211 or non-I2C-Configured? if it's later then better to fix a valid ID for it or if it doesn't support ID then a handle via quirk would be a proper solution.
The ICN6211 should always be accessible via either option. If the ID readout does not work, the bug is likely in broken DSI command mode on whatever DSI host is used, or, the ICN6211 clock are misconfigured.
