On Wed, 2022-09-28 at 03:58 +0300, Laurent Pinchart wrote:
> Up to and including v1.3, HDMI supported limited quantization range only
> for YCbCr. HDMI v1.4 introduced selectable quantization ranges, but this
> features isn't supported in the dw-hdmi driver that is used in
s/features/feature/
>
Hi Liu,
On Thu, Sep 29, 2022 at 03:47:33PM +0800, Liu Ying wrote:
> On Wed, 2022-09-28 at 03:58 +0300, Laurent Pinchart wrote:
> > From: Kieran Bingham
> >
> > The LCDIF includes a color space converter that supports YUV input. Use
> > it to support YUV planes, either through the converter if
On Wed, 2022-09-28 at 03:58 +0300, Laurent Pinchart wrote:
> The BIT() macro is meant to represent a single bit. Don't use it for
> values of register fields that span multiple bits.
>
> Signed-off-by: Laurent Pinchart
> ---
> Changes since v1:
>
> - Use hex for field values
> ---
>
On Wed, 2022-09-28 at 03:58 +0300, Laurent Pinchart wrote:
> A couple of the register macro values are incorrectly indented. Fix
> them.
>
> Signed-off-by: Laurent Pinchart
> Reviewed-by: Marek Vasut
> ---
> drivers/gpu/drm/mxsfb/lcdif_regs.h | 4 ++--
> 1 file changed, 2 insertions(+), 2
Hi Laurent,
On Wed, 2022-09-28 at 03:58 +0300, Laurent Pinchart wrote:
> From: Kieran Bingham
>
> The LCDIF includes a color space converter that supports YUV input. Use
> it to support YUV planes, either through the converter if the output
> format is RGB, or in conversion bypass mode
On 29/09/2022 03:18, john.c.harri...@intel.com wrote:
From: John Harrison
A workaround was added to the driver to allow compute workloads to run
'forever' by disabling pre-emption on the RCS engine for Gen12.
It is not totally unbound as the heartbeat will kick in eventually
and cause a
On 29/09/2022 03:18, john.c.harri...@intel.com wrote:
From: John Harrison
Compute workloads are inherently not pre-emptible for long periods on
current hardware. As a workaround for this, the pre-emption timeout
for compute capable engines was disabled. This is undesirable with GuC
On 29/09/2022 03:18, john.c.harri...@intel.com wrote:
From: John Harrison
GuC converts the pre-emption timeout and timeslice quantum values into
clock ticks internally. That significantly reduces the point of 32bit
overflow. On current platforms, worst case scenario is approximately
110
On Thu, Sep 29, 2022 at 8:10 AM Randy Dunlap wrote:
> On 9/28/22 12:26, broo...@kernel.org wrote:
> > Changes since 20220927:
> >
>
> on x86_64:
>
> ../drivers/gpu/drm/msm/msm_gem_shrinker.c: In function ‘can_block’:
> ../drivers/gpu/drm/msm/msm_gem_shrinker.c:29:28: error: ‘__GFP_ATOMIC’
>
On Wed, Sep 28, 2022 at 02:49:00PM +0200, Thierry Reding wrote:
> On Fri, Sep 16, 2022 at 05:15:04PM +0200, Uwe Kleine-König wrote:
> [...]
> > diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c
> > index 7b357d1cf642..811e6f424927 100644
> > --- a/drivers/pwm/pwm-crc.c
> > +++
On Mon, Sep 26, 2022 at 11:16 AM Christoph Hellwig wrote:
>
> Btw, there is another interesting thing around on the block:
>
> NVMe Computational Storage devices. Don't be fooled by the name, much
> of it is not about neither computation not storage, but it allows to
> use the existing NVMe
Mainline: NA
Category: Bugfix
CVE: NA
When the system wakes up from sleeping, all virtio devices
will be reset. However, restting virtio gpu device will delete
the virtqueue and resources saved on the virtio gpu backend,
making it impossible for the virtio gpu driver to communicate
with the
On 9/28/22 12:26, broo...@kernel.org wrote:
> Hi all,
>
> Changes since 20220927:
>
on x86_64:
../drivers/gpu/drm/msm/msm_gem_shrinker.c: In function ‘can_block’:
../drivers/gpu/drm/msm/msm_gem_shrinker.c:29:28: error: ‘__GFP_ATOMIC’
undeclared (first use in this function); did you mean
201 - 213 of 213 matches
Mail list logo
