[Intel-gfx] [V2 3/3] drm/amd/display: Move connector debugfs to drm

Harry Wentland harry.wentland at amd.com
Mon May 2 18:54:24 UTC 2022



On 2022-05-02 10:29, Harry Wentland wrote:
> 
> 
> On 2022-05-02 10:27, Modem, Bhanuprakash wrote:
>> On Mon-02-05-2022 07:08 pm, Harry Wentland wrote:
>>>
>>>
>>> On 2022-05-02 09:28, Modem, Bhanuprakash wrote:
>>>> On Fri-29-04-2022 08:02 pm, Murthy, Arun R wrote:
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Intel-gfx <intel-gfx-bounces at lists.freedesktop.org> On Behalf Of
>>>>>> Bhanuprakash Modem
>>>>>> Sent: Monday, April 11, 2022 3:21 PM
>>>>>> To: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org;
>>>>>> amd-
>>>>>> gfx at lists.freedesktop.org; jani.nikula at linux.intel.com;
>>>>>> ville.syrjala at linux.intel.com; harry.wentland at amd.com; Sharma, Swati2
>>>>>> <swati2.sharma at intel.com>
>>>>>> Cc: Rodrigo Siqueira <Rodrigo.Siqueira at amd.com>
>>>>>> Subject: [Intel-gfx] [V2 3/3] drm/amd/display: Move connector
>>>>>> debugfs to
>>>>>> drm
>>>>>>
>>>>>> As drm_connector already have the display_info, instead of creating
>>>>>> "output_bpc" debugfs in vendor specific driver, move the logic to the
>>>>>> drm
>>>>>> layer.
>>>>>>
>>>>>> This patch will also move "Current" bpc to the crtc debugfs from
>>>>>> connector
>>>>>> debugfs, since we are getting this info from crtc_state.
>>>>>>
>>>>>> Cc: Harry Wentland <harry.wentland at amd.com>
>>>>>> Cc: Rodrigo Siqueira <Rodrigo.Siqueira at amd.com>
>>>>>> Signed-off-by: Bhanuprakash Modem <bhanuprakash.modem at intel.com>
>>>>>> Reported-by: kernel test robot <lkp at intel.com>
>>>>>> ---
>>>>> Reviewed-by: Arun R Murthy <arun.r.murthy at intel.com>
>>>>
>>>> Thanks Arun,
>>>>
>>>> @Harry/@Rodrigo, If this change sounds good to you, can you please help
>>>> to push it?
>>>>
>>>
>>> This changes the output_bpc debugfs behavior on amdgpu and breaks
>>> the amd_max_bpc IGT test. I don't think we should merge this as-is.
>>
>> Yeah, I have floated the IGT changes to support this series:
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.freedesktop.org%2Fseries%2F102387%2F&data=05%7C01%7Charry.wentland%40amd.com%7C8cb627c63b194b3b82f808da2c4839b0%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637870985961376064%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=kn26Et7wc9IUkYhSG3R%2FXVKIJoqyKlQ1%2FNcduVh9Fuo%3D&reserved=0
>>
>>
>> With this IGT change, we can merge this series as-is. I would like to
>> request you to review IGT patches too.
>>
>>>
>>> This patch also seems dependent on patch 1 of the series. Shouldn't
>>> they be merged together (please don't merge them as-is, though)?
>>
>> Yes, as other patches in this series are already reviewed, I think we
>> need to plan to merge all patches in this series together (If above IGT
>> & this patch looks good to you).
>>
> 
> Thanks for the context again and apologies I haven't had the time to
> have a closer look so far. I'll go over these and the IGT patches today
> and get back to you.
> 

Both the kernel and IGT series look good to me.

I recommend you merge the entire kernel set as one into drm-next. We
can pull it into amd-staging-drm-next so as not to break our CI once
the IGT patches land.

Harry

> Harry
> 
>> - Bhanu
>>
>>>
>>> Harry
>>>
>>>> - Bhanu
>>>>
>>>>>
>>>>> Thanks and Regards,
>>>>> Arun R Murthy
>>>>> --------------------
>>>>
>>


More information about the amd-gfx mailing list