;
> > amd-gfx@lists.freedesktop.org; jani.nik...@intel.com; imre.d...@intel.com;
> > Wentland, Harry ; Zuo, Jerry
> > ; ville.syrj...@linux.intel.com
> > Subject: Re: [Patch v2 2/3] drm/mst: Refactor the flow for payload
> > allocation/removement
> >
> > On Thu, A
mre.d...@intel.com;
> Wentland, Harry ; Zuo, Jerry
> ; ville.syrj...@linux.intel.com
> Subject: Re: [Patch v2 2/3] drm/mst: Refactor the flow for payload
> allocation/removement
>
> On Thu, Aug 31, 2023 at 6:45 PM Lyude Paul wrote:
> >
> > On Thu, 2023-08-24 at 04:12 +,
> > -Original Message-
> > > > > From: Lyude Paul
> > > > > Sent: Friday, August 18, 2023 6:17 AM
> > > > > To: Lin, Wayne ; dri-de...@lists.freedesktop.org;
> > > > > amd-gfx@lists.freedesktop.org
> > > > > Cc: jani.nik
; ville.syrj...@linux.intel.com;
> > imre.d...@intel.com;
> > Wentland, Harry ; Zuo, Jerry
> >
> > Subject: Re: [Patch v2 2/3] drm/mst: Refactor the flow for payload
> > allocation/removement
> >
> > Sure - you're also welcome to push the first two patches af
esktop.org
> Cc: jani.nik...@intel.com; ville.syrj...@linux.intel.com; imre.d...@intel.com;
> Wentland, Harry ; Zuo, Jerry
>
> Subject: Re: [Patch v2 2/3] drm/mst: Refactor the flow for payload
> allocation/removement
>
> Sure - you're also welcome to push the first two pa
> > From: Lyude Paul
> > Sent: Friday, August 18, 2023 6:17 AM
> > To: Lin, Wayne ; dri-de...@lists.freedesktop.org;
> > amd-gfx@lists.freedesktop.org
> > Cc: jani.nik...@intel.com; ville.syrj...@linux.intel.com;
> > imre.d...@intel.com;
> > Wentland,
el.com; ville.syrj...@linux.intel.com; imre.d...@intel.com;
> Wentland, Harry ; Zuo, Jerry
>
> Subject: Re: [Patch v2 2/3] drm/mst: Refactor the flow for payload
> allocation/removement
>
> Two small comments:
>
> On Mon, 2023-08-07 at 10:56 +0800, Wayne Lin wrote:
> > [W
Two small comments:
On Mon, 2023-08-07 at 10:56 +0800, Wayne Lin wrote:
> [Why]
> Today, the allocation/deallocation steps and status is a bit unclear.
>
> For instance, payload->vc_start_slot = -1 stands for "the failure of
> updating DPCD payload ID table" and can also represent as "payload is
el.com; ville.syrj...@linux.intel.com; imre.d...@intel.com;
> Wentland, Harry ; Zuo, Jerry
>
> Subject: Re: [Patch v2 2/3] drm/mst: Refactor the flow for payload
> allocation/removement
>
> Oo! This is a wonderful idea so far - keeping track of the status of
> allocat
Oo! This is a wonderful idea so far - keeping track of the status of
allocations like this solves a lot of problems, especially with regards to the
fact this actually seems to make it possible for us to have much better
handling of payload failures in drivers - especially in situations like
[Why]
Today, the allocation/deallocation steps and status is a bit unclear.
For instance, payload->vc_start_slot = -1 stands for "the failure of
updating DPCD payload ID table" and can also represent as "payload is not
allocated yet". These two cases should be handled differently and hence
better
11 matches
Mail list logo
