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@xxxxxxxxxxxxxxxxxxxxx> On Behalf Of >>>>>> Bhanuprakash Modem >>>>>> Sent: Monday, April 11, 2022 3:21 PM >>>>>> To: intel-gfx@xxxxxxxxxxxxxxxxxxxxx; dri-devel@xxxxxxxxxxxxxxxxxxxxx; >>>>>> amd- >>>>>> gfx@xxxxxxxxxxxxxxxxxxxxx; jani.nikula@xxxxxxxxxxxxxxx; >>>>>> ville.syrjala@xxxxxxxxxxxxxxx; harry.wentland@xxxxxxx; Sharma, Swati2 >>>>>> <swati2.sharma@xxxxxxxxx> >>>>>> Cc: Rodrigo Siqueira <Rodrigo.Siqueira@xxxxxxx> >>>>>> Subject: [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@xxxxxxx> >>>>>> Cc: Rodrigo Siqueira <Rodrigo.Siqueira@xxxxxxx> >>>>>> Signed-off-by: Bhanuprakash Modem <bhanuprakash.modem@xxxxxxxxx> >>>>>> Reported-by: kernel test robot <lkp@xxxxxxxxx> >>>>>> --- >>>>> Reviewed-by: Arun R Murthy <arun.r.murthy@xxxxxxxxx> >>>> >>>> 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 >>>>> -------------------- >>>> >>
