Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <dd5f274f-46f5-c20b-bc61-ba7d1c4e4869@linaro.org>
Date:   Tue, 6 Jun 2023 08:18:52 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.2
Subject: Re: [PATCH] arm64: dts: qcom: Split sdm845-db845c to add headless
 support
Content-Language: en-US
To:     Amit Pundir <amit.pundir@linaro.org>,
        Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Cc:     Bjorn Andersson <andersson@kernel.org>,
        Konrad Dybcio <konrad.dybcio@linaro.org>,
        Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
        Caleb Connolly <caleb.connolly@linaro.org>,
        Andy Gross <agross@kernel.org>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Conor Dooley <conor+dt@kernel.org>,
        linux-arm-msm <linux-arm-msm@vger.kernel.org>,
        lkml <linux-kernel@vger.kernel.org>
References: <20230605094710.2037879-1-amit.pundir@linaro.org>
 <cd71ee53-391a-90fd-27ca-c174f2b24a94@linaro.org>
 <CAMi1Hd0MhOyn1HHq5YYFxJwWrkMZbS9ZqksNDBLM9Ayx67rEOg@mail.gmail.com>
From:   Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
In-Reply-To: <CAMi1Hd0MhOyn1HHq5YYFxJwWrkMZbS9ZqksNDBLM9Ayx67rEOg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 06/06/2023 08:11, Amit Pundir wrote:
> On Mon, 5 Jun 2023 at 16:07, Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>>
>> On 05/06/2023 11:47, Amit Pundir wrote:
>>> This is a follow-up of the upstream discussion,
>>> https://lore.kernel.org/linux-kernel/20230124182857.1524912-1-amit.pundir@linaro.org/T/#u,
>>> around adding a reserved memory region in sdm845-db845c
>>> for the framebuffer memory (the splash region set up by
>>> the bootloader) but the general opinion was to avoid
>>> adding that reserved memory for the headless DB845c
>>> usecase.
>>>
>>> So this patch splits the sdm845-db845c into a common dtsi,
>>> a new sdm845-db845-headless DT, which disables the mdss
>>> display subsystem, and a new sdm845-db845c DT with an
>>> additional reserved-memory region for the framebuffer.
>>>
>>> The default sdm845-db845c.dtb remains pretty much the same
>>> (with an exception of additional reserved-memory region),
>>> while others can use sdm845-db845c-headless.dtb for their
>>> headless systems.
>>
>> You should describe the hardware in commit msg. What is "headless"? If
>> no HDMI plugged in, then it is a NAK because plug or unplugged HDMI
>> cable is not a property of a DTS.
> 
> Hi, my only intended goal [1] is to add a reserved-memory region
> (specific to the framebuffer memory reserved by the bootloader for the
> boot splash) in sdm45-db845c. But I have been told that reserving
> these 30+ MBs for every DB845c is a waste in case we are not using
> display at all (a headless system?). So I prepared this patch for RFC.
> The definition of headless is ambiguous to me as well. It could be no
> HDMI plugged in or no display drivers enabled at all. I believe it all
> comes down to specific use cases.

HDMI is plug-n-play, thus you do not need new DTSI to describe that
something is plugged or not. How would it even work? You plug HDMI, so
you need to boot your system with different DTB!

Whether driver are enabled or not, does not change the hardware and does
not matter. If I disable MMC driver, shall I create a "no-mmc" DTS variant?

NAK

> 
> As far as my use-case (vanilla AOSP) is concerned, display is a
> critical component and device doesn't boot to completion unless it is
> hooked to any kind of display. 

That's problem in AOSP to fix, not in DTS. Systems with no display
attached are perfectly normal and valid systems. They do not need any
tweaks, changes, fixes.

> May I suggest we go back to my original
> change [1] of adding a reserved-memory region for now and let the
> users of a headless system, define or come up with their respective
> use-case?
> 


Best regards,
Krzysztof