On Thu, 08 May 2025, "Lin, Wayne" <wayne....@amd.com> wrote: > [Public] > >> -----Original Message----- >> From: Jani Nikula <jani.nik...@intel.com> >> Sent: Thursday, May 8, 2025 4:19 PM >> To: Lin, Wayne <wayne....@amd.com>; dri-devel@lists.freedesktop.org >> Cc: ville.syrj...@linux.intel.com; Limonciello, Mario >> <mario.limoncie...@amd.com>; >> Wentland, Harry <harry.wentl...@amd.com>; Lin, Wayne >> <wayne....@amd.com>; sta...@vger.kernel.org >> Subject: Re: [PATCH] drm/dp: Fix Write_Status_Update_Request AUX request >> format >> >> On Sun, 27 Apr 2025, Wayne Lin <wayne....@amd.com> wrote: >> > + /* >> > + * When I2C write firstly get defer and get ack after >> > + * retries by wirte_status_update, we have to return >> > + * all data bytes get transferred instead of 0. >> > + */ >> >> My brain gives me syntax and parse error here. ;) > > Appreciate for the feedback, Jani. > Could you elaborate more on your concerns please? > > Since Write_Status_Update_Request is address only request. Data length > is 0. When I2C write request completes, reply for > Write_Status_Update_Request from DPRx will be ACK only (i.e. data > length is 0). > > Is your concern about returning 0 from aux->transfer? > My thoughts is drm_dp_i2c_do_msg() is designed to handle I2C-Over-Aux > reply data, and aux->transfer() is handling hw specific manipulation and > return transferred bytes. For Write_Status_Update_Request request itself, > nothing new to be transferred. I think drm_dp_i2c_do_msg() should be > responsible for determining the correct transferred data bytes under this > case. Or do you expect aux->transfer to memorize the data length of > write request?
My concern is that I don't understand what the comment is trying to say. "when i2c write firstly get defer" - what does it mean? "wirte_status_update" - typo "we have to" - why? "return all data bytes get transferred" - what does it mean? > > Thanks! >> >> BR, >> Jani. >> >> -- >> Jani Nikula, Intel > -- > Wayne Lin -- Jani Nikula, Intel
