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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DC072EB64DA for ; Wed, 5 Jul 2023 15:59:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233238AbjGEP7e (ORCPT ); Wed, 5 Jul 2023 11:59:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39362 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233230AbjGEP7X (ORCPT ); Wed, 5 Jul 2023 11:59:23 -0400 Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 948FF1BC9 for ; Wed, 5 Jul 2023 08:59:01 -0700 (PDT) Received: by mail-wr1-x432.google.com with SMTP id ffacd0b85a97d-3143b70d6easo3126533f8f.2 for ; Wed, 05 Jul 2023 08:59:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1688572731; x=1691164731; h=content-transfer-encoding:in-reply-to:organization:references:cc:to :content-language:subject:reply-to:from:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=moibl62gzAsWVTokluvPSFK/S0tyJbu/881cJb+p80o=; b=JSlq8CZYrL0RmBsVMhuobUhV95XMGPxVfjGNavCOWyxUgSDHCaJB4aAXpc5KoUvq40 fykvC+WCiFXbWE5Z/OEaXbgEQO5+99cEZcZ439cMGWzd0tn/RtXvHe13K1KHd1M/7kxS agXTzzdaz8SDtGYRZtw+KzPgomGI6nfejQqRPgLR657DflSyEmtY9+UcMcetjEbXGOj0 S3SDFqvZOjtSHTaVjrTDKmXS6TOaWRSwrdb5HqsIN2TlRZEbKVeQIt9vc2/DgiklaPyx XRzTGp9k6pT2BuWv6adsmAYFJtP1xt8B4r+oL5KMEzcv/dB7IqzPrpdKmwZ961oHLbSQ iZBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688572731; x=1691164731; h=content-transfer-encoding:in-reply-to:organization:references:cc:to :content-language:subject:reply-to:from:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=moibl62gzAsWVTokluvPSFK/S0tyJbu/881cJb+p80o=; b=fiq7CMi5K+EA+YfIYyMFh1zV6CcoGwLo8vH/pGtO+IUkXf+9qM1/QPWOHLev+E1VkW 98ijqqCdlAcs2ixlaYtDzV6yckJGlEK9+nFAVwfzosBObmgrrxzjQhI3rNysAkFBwxmk c5rBWukC16nSVzowX7B0vamRLDPVwTH9PKVtEbJTY/sXZn64L6KrZ3TI4WCtagJNaNAS 9VhyKw5XsGb8FHG1fm06IuvvrYv4gRp1cTynD8qPwfZFgMUtQQ6WPLXXumCbpKvDbCF4 Aqtt3CV9MMPGiR0Q2V9sYKYot3fozNYoSX1JcRFpLwY2EdwAm1Dou6/QDjQj7XsG1xnx CUVQ== X-Gm-Message-State: ABy/qLZb5ML03M7O2pMlMPrmnd6D8n/OZ1lRBzVtlOPkoiZHMneF4lAI zPhT2kCs1qZHNLq6DaJrEBaDlg== X-Google-Smtp-Source: APBJJlGx+kWWfQ+ERifBEWKHxqWBwGmPAO4EZnQin0ptwlMz0lU3sRP6zkQMsbyuoLdBaBGZMnrUZQ== X-Received: by 2002:a5d:4f8d:0:b0:314:11ea:480d with SMTP id d13-20020a5d4f8d000000b0031411ea480dmr14762913wru.9.1688572731063; Wed, 05 Jul 2023 08:58:51 -0700 (PDT) Received: from ?IPV6:2a01:e0a:982:cbb0:65eb:d140:2d45:ee85? ([2a01:e0a:982:cbb0:65eb:d140:2d45:ee85]) by smtp.gmail.com with ESMTPSA id s11-20020a5d69cb000000b00313f07ccca4sm27119522wrw.117.2023.07.05.08.58.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 05 Jul 2023 08:58:49 -0700 (PDT) Message-ID: Date: Wed, 5 Jul 2023 17:58:48 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 From: Neil Armstrong Reply-To: neil.armstrong@linaro.org Subject: Re: RFC: DSI host capabilities (was: [PATCH RFC 03/10] drm/panel: Add LGD panel driver for Sony Xperia XZ3) Content-Language: en-US To: Maxime Ripard , Dmitry Baryshkov Cc: AngeloGioacchino Del Regno , "open list:DRM DRIVER FOR MSM ADRENO GPU" , Caleb Connolly , Krzysztof Kozlowski , AngeloGioacchino Del Regno , Marijn Suijten , Sam Ravnborg , Kuogee Hsieh , Andy Gross , Jessica Zhang , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Conor Dooley , "open list:DRM DRIVER FOR MSM ADRENO GPU" , Abhinav Kumar , Rob Herring , Martin Botka , ~postmarketos/upstreaming@lists.sr.ht, Jami Kettunen , Bjorn Andersson , open list , Konrad Dybcio , freedreno References: <617c8f8a-1fc7-c6a0-eaa5-ce75ff2adc1b@linaro.org> <739a8bd9-9ff0-5072-fdae-b64efdf86842@collabora.com> <47a5678c-1eb3-dfc2-a9ac-f8e497455d11@linaro.org> <6e070141-8c0e-59ed-8a08-58c3fadb17df@linaro.org> Organization: Linaro Developer Services In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/07/2023 16:24, Maxime Ripard wrote: > On Wed, Jul 05, 2023 at 04:37:57PM +0300, Dmitry Baryshkov wrote: >>>>> >>>>> Either way, I'm not really sure it's a good idea to multiply the >>>>> capabilities flags of the DSI host, and we should just stick to the >>>>> spec. If the spec says that we have to support DSC while video is >>>>> output, then that's what the panels should expect. >>>> >>>> Except some panels supports DSC & non-DSC, Video and Command mode, and >>>> all that is runtime configurable. How do you handle that ? >>> >>> In this case, most of the constraints are going to be on the encoder >>> still so it should be the one driving it. The panel will only care about >>> which mode has been selected, but it shouldn't be the one driving it, >>> and thus we still don't really need to expose the host capabilities. >> >> This is an interesting perspective. This means that we can and actually have >> to extend the drm_display_mode with the DSI data and compression >> information. > > I wouldn't extend drm_display_mode, but extending one of the state > structures definitely. > > We already have some extra variables in drm_connector_state for HDMI, > I don't think it would be a big deal to add a few for MIPI-DSI. > > We also floated the idea for a while to create bus-specific states, with > helpers to match. Maybe it would be a good occasion to start doing it? > >> For example, the panel that supports all four types for the 1080p should >> export several modes: >> >> 1920x1080-command >> 1920x1080-command-DSC >> 1920x1080-video >> 1920x1080-video-DSC >> >> where video/command and DSC are some kinds of flags and/or information in >> the drm_display_mode? Ideally DSC also has several sub-flags, which denote >> what kind of configuration is supported by the DSC sink (e.g. bpp, yuv, >> etc). > > So we have two things to do, right? We need to expose what the panel can > take (ie, EDID for HDMI), and then we need to tell it what we picked > (infoframes). > > We already express the former in mipi_dsi_device, so we could extend the > flags stored there. > > And then, we need to tie what the DSI host chose to a given atomic state > so the panel knows what was picked and how it should set everything up. Yep this looks like a good plan Neil > >> Another option would be to get this handled via the bus format negotiation, >> but that sounds like worse idea to me. > > Yeah, I'm not really fond of the format negociation stuff either. > > Maxime