[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <54c62926-d501-35f8-f135-477216bf3444@ideasonboard.com>
Date: Tue, 9 Aug 2022 12:57:41 +0300
From: Tomi Valkeinen <tomi.valkeinen@...asonboard.com>
To: Aradhya Bhatia <a-bhatia1@...com>
Cc: Jyri Sarha <jyri.sarha@....fi>, Rob Herring <robh+dt@...nel.org>,
David Airlie <airlied@...ux.ie>,
Daniel Vetter <daniel@...ll.ch>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Nishanth Menon <nm@...com>,
Devicetree List <devicetree@...r.kernel.org>,
Vignesh Raghavendra <vigneshr@...com>,
Devarsh Thakkar <devarsht@...com>,
Linux Kernel List <linux-kernel@...r.kernel.org>,
DRI Development List <dri-devel@...ts.freedesktop.org>,
Rahul T R <r-ravikumar@...com>
Subject: Re: [PATCH v3 2/2] drm/tidss: Add support for AM625 DSS
On 09/08/2022 12:21, Aradhya Bhatia wrote:
> Hi Tomi,
>
> On 09-Aug-22 12:01, Tomi Valkeinen wrote:
>> On 09/08/2022 09:08, Aradhya Bhatia wrote:
>>> Hi Tomi,
>>>
>>> On 28-Jul-22 17:34, Tomi Valkeinen wrote:
>>>> On 27/06/2022 18:12, Aradhya Bhatia wrote:
>>>>> Add support for the DSS IP on TI's new AM625 SoC in the tidss driver.
>>>>>
>>>>> Signed-off-by: Aradhya Bhatia <a-bhatia1@...com>
>>>>> Reviewed-by: Rahul T R <r-ravikumar@...com>
>>>>> ---
>>>>> drivers/gpu/drm/tidss/tidss_dispc.c | 56
>>>>> ++++++++++++++++++++++++++++-
>>>>> drivers/gpu/drm/tidss/tidss_dispc.h | 2 ++
>>>>> drivers/gpu/drm/tidss/tidss_drv.c | 1 +
>>>>> 3 files changed, 58 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/tidss/tidss_dispc.c
>>>>> b/drivers/gpu/drm/tidss/tidss_dispc.c
>>>>> index dae47853b728..f084f0688a54 100644
>>>>> --- a/drivers/gpu/drm/tidss/tidss_dispc.c
>>>>> +++ b/drivers/gpu/drm/tidss/tidss_dispc.c
>>>>> @@ -272,6 +272,55 @@ const struct dispc_features dispc_j721e_feats = {
>>>>> .vid_order = { 1, 3, 0, 2 },
>>>>> };
>>>>> +const struct dispc_features dispc_am625_feats = {
>>>>> + .max_pclk_khz = {
>>>>> + [DISPC_VP_DPI] = 165000,
>>>>> + [DISPC_VP_OLDI] = 165000,
>>>>> + },
>>>>> +
>>>>> + .scaling = {
>>>>> + .in_width_max_5tap_rgb = 1280,
>>>>> + .in_width_max_3tap_rgb = 2560,
>>>>> + .in_width_max_5tap_yuv = 2560,
>>>>> + .in_width_max_3tap_yuv = 4096,
>>>>> + .upscale_limit = 16,
>>>>> + .downscale_limit_5tap = 4,
>>>>> + .downscale_limit_3tap = 2,
>>>>> + /*
>>>>> + * The max supported pixel inc value is 255. The value
>>>>> + * of pixel inc is calculated like this: 1+(xinc-1)*bpp.
>>>>> + * The maximum bpp of all formats supported by the HW
>>>>> + * is 8. So the maximum supported xinc value is 32,
>>>>> + * because 1+(32-1)*8 < 255 < 1+(33-1)*4.
>>>>> + */
>>>>> + .xinc_max = 32,
>>>>> + },
>>>>> +
>>>>> + .subrev = DISPC_AM625,
>>>>> +
>>>>> + .common = "common",
>>>>> + .common_regs = tidss_am65x_common_regs,
>>>>> +
>>>>> + .num_vps = 2,
>>>>> + .vp_name = { "vp1", "vp2" },
>>>>> + .ovr_name = { "ovr1", "ovr2" },
>>>>> + .vpclk_name = { "vp1", "vp2" },
>>>>> + .vp_bus_type = { DISPC_VP_OLDI, DISPC_VP_DPI },
>>>>
>>>> This looks correct, but with the two OLDI TXes, I think there will
>>>> be some interesting issues.
>>>>
>>>> The tidss_kms.c associates a DSS VP and a DT port, but that's no
>>>> longer true if you add the ports for both OLDI TXes, as they both
>>>> use the same VP. I think fixing that won't affect this patch,
>>>> though, and merging this patch will, afaik, enable similar DSS
>>>> functionality as we have for AM65x.
>>>>
>>>> So, I think these two patches could be merged, or we could wait a
>>>> bit until the OLDI situation becomes more clear. Up to you. In any
>>>> case, for both patches:
>>>>
>>>> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@...asonboard.com>\
>>>
>>> Thank you for the review!
>>>
>>> This patch set is required for the dss DT patches to be upstreamed for
>>> the AM625-SK, so I would like them to get merged.
>>>
>>> Since these were posted in the previous merge window, I will re-send
>>> with your tag.
>>
>> I'd like to understand better the dual OLDI TX case before merging any
>> AM625 dss changes.
>>
>> At the moment you have only one port in the DT for the OLDI TX for
>> AM625, right? I don't see how that is supposed to work as there are
>> two OLDI outputs.
> The OLDI node doesn't have node of its own at all. Its the dss port that
> gets directly connected to the panel ports.
>
>> And if we do add a new port, it perhaps makes sense to have two OLDI
>> TX ports as ports 0 and 1, and the DPI as port 2, which is then
>> different from AM65x.
> The DSS still has a single (DPI) VP for the OLDI outputs. Both the OLDI
> TXes receive the same input from the DSS VP.
Yes, but don't mix the DSS VP and the DT port. They are not the same thing.
> Wouldn't having them modeled as videp ports 0 and 1 would mean that the
> DSS is capable of driving 2 different OLDI displays? (which is not the
> case here).
If you use the OLDI cloning, the AM625 is driving two OLDI displays, no?
In theory the panels could be of different model, as long as they both
support the same video mode, and they could be managed by different
drivers. This requires two ports so that you can connect the panels in
the DT.
But let's continue this discussion in the "[PATCH 4/8] drm/tidss: Add
support for Dual Link LVDS Bus Format" thread, no need to discuss the
same things in two threads =).
Tomi
Powered by blists - more mailing lists