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 2/3] arm64: dts: ti: k3-j721e-main.dtsi: Add DSS node
To:     Tomi Valkeinen <tomi.valkeinen@ti.com>, Jyri Sarha <jsarha@ti.com>,
        Nishanth Menon <nm@ti.com>, Rob Herring <robh+dt@kernel.org>,
        <linux-arm-kernel@lists.infradead.org>,
        <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>
References: <20200422091512.950-1-tomi.valkeinen@ti.com>
 <20200422091512.950-2-tomi.valkeinen@ti.com>
 <ade3a177-f060-bc40-bcc1-494093e3071d@ti.com>
 <47b7f858-a8d9-1c3b-4dca-2cc493f6730f@ti.com>
 <fa497e8d-7911-5f3d-cf91-347370f8edaa@ti.com>
 <217c0c14-f4fb-7321-9f57-205df0cd01fe@ti.com>
 <9a4b1d0a-c871-2280-8d22-196730e9385b@ti.com>
 <3eb05f6d-523f-f7e5-a0e9-d47b852fe079@ti.com>
From:   Tero Kristo <t-kristo@ti.com>
Message-ID: <6427a827-9175-75ab-72fb-a62a21795bf3@ti.com>
Date:   Mon, 27 Apr 2020 14:41:37 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <3eb05f6d-523f-f7e5-a0e9-d47b852fe079@ti.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 27/04/2020 14:37, Tomi Valkeinen wrote:
> On 27/04/2020 14:15, Tomi Valkeinen wrote:
>> On 27/04/2020 14:10, Jyri Sarha wrote:
>>> On 27/04/2020 13:51, Tomi Valkeinen wrote:
>>>> On 27/04/2020 13:37, Jyri Sarha wrote:
>>>>> On 27/04/2020 13:09, Tero Kristo wrote:
>>>>>>> +        status = "disabled";
>>>>>>
>>>>>> Again, why disabled by default?
>>>>>>
>>>>>
>>>>> tidss device is not functional without a defined video-port. The 
>>>>> driver
>>>>> is not implemented in a way that it would handle a broken 
>>>>> configuration
>>>>> gracefully.
>>>>
>>>> Then we need to fix it. The driver should handle the case where there
>>>> are no ports defined just fine.
>>>>
>>>
>>> Just by reading the code, I would say that currently the probe would
>>> fail with returned -ENOMEM after calling drm_vblank_init() with zero 
>>> CRTCs.
>>>
>>> So should the probe fail gracefully and silently, or should we try to
>>> register a DRM device with no CRTCs? Is that even possible?
>>
>> My first thought is that the driver should exit probe silently with 
>> ENODEV if there are no outputs defined (but, of course, with 
>> EPROBE_DEFER if there are outputs which haven't been probed yet).
>>
>> It gets a bit more complex if we ever support writeback, as that can 
>> be used as mem-to-mem without any displays, but I think we can ignore 
>> that for now.
> 
> In any case, that's not the reason for status = "disabled", so that 
> discussion is not related to these patches as such.
> 
> The reason to have DSS disabled is just to prevent pointless driver 
> probing. When a board dts or a DT overlay adds a display, the DSS DT 
> node has to be modified anyway to add the DT graph and the panel/bridge 
> data. So one can as well add the single line of "status = enabled" there.

Ok, thanks for the explanation, queued all three patches towards 5.8 
based on that.

-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki