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 909E1C001DE for ; Wed, 5 Jul 2023 15:59:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233253AbjGEP7b (ORCPT ); Wed, 5 Jul 2023 11:59:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39566 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233233AbjGEP7Y (ORCPT ); Wed, 5 Jul 2023 11:59:24 -0400 Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B20DA1FC4 for ; Wed, 5 Jul 2023 08:59:01 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id ffacd0b85a97d-3112f5ab0b1so7624308f8f.0 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=gdN6bxTCEvb9QY0bGw5hnMBchbzLAZaHVoiRztwTkXUJdeJrXhix4BUh5gMQXxvn8S aXMxvIzpTqg+ciq4zFaNbGdquDpkJxCnWyDrIHlvwGK/ds83muRq2xIg+PnXk/+OLHPK bZ4xqMNNBEvehcrkr++fq5tdTIcxGAPqIbHYxBnqZTNfbGpppbntPWwC4NS3exmU8Jh5 lW/I4t57wWFzBr4xDbnKKGKbKBv456XvlHCiH01BKbhTfzerBrKFGLJEWRLBYYgWMx54 MSfVkzL5skjI5lccD2+kptFPk3KTxjdzkz92P2eB3omdYcp2AoYsTuWTQqnN4yqYdFH/ KgEA== X-Gm-Message-State: ABy/qLYbGDZ/rxMoKSQlmv56zL2a6q0hZbEp4Nlgklr82quIh5N5z3oi 2WUJ/UGbbE2+go6zMEfQs7UDag== 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: devicetree@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