Re: [RFC PATCH 5/6] drm/msm/dsi: Flip greater-than check for slice_count and slice_per_intf

2022-12-16 Thread Abhinav Kumar
On 12/13/2022 3:22 PM, Marijn Suijten wrote: According to downstream /and the comment copied from it/ this comparison should be the other way around. In other words, when the panel driver requests to use more slices per packet than what could be sent over this interface, it is bumped down to

Re: [RFC PATCH 5/6] drm/msm/dsi: Flip greater-than check for slice_count and slice_per_intf

2022-12-14 Thread Dmitry Baryshkov
On 14/12/2022 01:22, Marijn Suijten wrote: According to downstream /and the comment copied from it/ this comparison should be the other way around. In other words, when the panel driver requests to use more slices per packet than what could be sent over this interface, it is bumped down to only

Re: [RFC PATCH 5/6] drm/msm/dsi: Flip greater-than check for slice_count and slice_per_intf

2022-12-14 Thread Marijn Suijten
On 2022-12-14 01:02:14, Konrad Dybcio wrote: > > > On 14.12.2022 00:22, Marijn Suijten wrote: > > According to downstream /and the comment copied from it/ this comparison > > should be the other way around. In other words, when the panel driver > > requests to use more slices per packet than

Re: [RFC PATCH 5/6] drm/msm/dsi: Flip greater-than check for slice_count and slice_per_intf

2022-12-13 Thread Konrad Dybcio
On 14.12.2022 00:22, Marijn Suijten wrote: > According to downstream /and the comment copied from it/ this comparison > should be the other way around. In other words, when the panel driver > requests to use more slices per packet than what could be sent over this > interface, it is bumped

[RFC PATCH 5/6] drm/msm/dsi: Flip greater-than check for slice_count and slice_per_intf

2022-12-13 Thread Marijn Suijten
According to downstream /and the comment copied from it/ this comparison should be the other way around. In other words, when the panel driver requests to use more slices per packet than what could be sent over this interface, it is bumped down to only use a single slice per packet (and strangely