The cases of vmw_user_bo_synccpu_grab failing with -ERESTARTSYS or -EBUSY
are handled in vmw_user_bo_synccpu_ioctl by not printing an error message.
However, the error value gets discarded, indicating success. This leads
to rendering glitches and a reported drm error on the next ioctl call to
Hi Joe,
On 13/03/22 3:57 am, Joe Perches wrote:
On Sat, 2022-03-12 at 07:26 -0800, Harshit Mogalapalli wrote:
kvcalloc is same as kvmalloc_array + __GFP_ZERO.
[]
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
[]
@@ -308,9 +308,8 @@ v3d_lookup_bos(struct
Hello,
syzbot found the following issue on:
HEAD commit:ea4424be1688 Merge tag 'mtd/fixes-for-5.17-rc8' of git://g..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14095f9e70
kernel config: https://syzkaller.appspot.com/x/.config?x=aba0ab2928a512c2
kvcalloc is same as kvmalloc_array + __GFP_ZERO.
Signed-off-by: Harshit Mogalapalli
---
drivers/gpu/drm/v3d/v3d_gem.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index c7ed2e1cbab6..f7d37228461e 100644
On Sat, 2022-03-12 at 07:26 -0800, Harshit Mogalapalli wrote:
> kvcalloc is same as kvmalloc_array + __GFP_ZERO.
[]
> diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
[]
> @@ -308,9 +308,8 @@ v3d_lookup_bos(struct drm_device *dev,
> return -EINVAL;
> }
The LCD controller is composed of Frame Compression Processor (FCPVD),
Video Signal Processor (VSPD), and Display Unit (DU).
It has DPI/DSI interfaces and supports a maximum resolution of 1080p
along with 2 rpf's to support blending of two picture layers and
raster operations (ROPs).
The DU part
RZ/G2L does not have group/plane registers compared to RCar, hence it
needs a different CRTC implementation. Factorise rcar_du_vsp{complete,
enable,plane_atomic_check} so that it can support later SoC without any
code changes.
Signed-off-by: Biju Das
---
RFC->v1:
* New patch
---
RZ/G2L SoC's does not have group/plane registers compared to RCar, hence it
needs a different CRTC implementation. Factorise rcar_du_{atomic_check,
modeset_init} by adding struct rcar_du_crtc_helper_funcs to struct
rcar_du_device_info, so that it can support later SoC without any code
changes.
RZ/G2L SoC's does not have group/plane registers compared to RCar, hence it
needs a different CRTC implementation.
Move rcar_du_output_name() to a new common file rcar_du_common.c, So that
the same function can be reused by RZ/G2L SoC later.
Signed-off-by: Biju Das
---
RFC->v1:
New patch
---
There are some differences related to max frame size supported by different
R-Car/RZ-G family of SoC's
Max frame size supported by R-Car Gen1 & R-Car Gen2 is 4095x2047
Max frame size supported by R-Car Gen3 is 8190x8190
Max frame size supported by RZ/G2L is 1920x1080
Add max_width and max_height
Number of RPF's VSP is different on R-Car and RZ/G2L
R-Car Gen3 -> 5 RPFs
R-Car Gen2 -> 4 RPFs
RZ/G2L -> 2 RPFs
Add num_rpf to struct rcar_du_device_info to support later
SoC without any code changes.
Signed-off-by: Biju Das
---
RFC->v1:
* Fixed the comment for num_rpf s/rpf's/RPFs/ and
Extend the Renesas DU display bindings to support the r9a07g044l
RZ/G2L LCDC.
Signed-off-by: Biju Das
---
RFC->v1:
* Changed minItems->maxItems for renesas,vsps.
RFC:
https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220112174612.10773-18-biju.das...@bp.renesas.com/
---
RZ/G2L LCD controller composed of Frame compression Processor(FCPVD),
Video signal processor (VSPD) and Display unit(DU). The output of LCDC is
connected to Display parallel interface and MIPI link video interface.
This patch series aims to add basic display support on RZ/G2L SMARC EVK
platform.
On 3/11/22 11:33, Sascha Hauer wrote:
> The rk3568 HDMI has an additional clock that needs to be enabled for the
> HDMI controller to work. This clock is not needed for the HDMI
> controller itself, but to make the SoC internal bus logic work. From the
> reference manual:
>
>> 2.8.6 NIU Clock
On Sun, Feb 06, 2022 at 09:00:14AM +0100, Andreas Kemnade wrote:
> The EPDC can process some dirty rectangles at a time, pick them up and
> forward them to the controller. Only processes not involving PXP are
> supported at the moment. Due to that and to work with more waveforms,
> there is some
On Sun, Feb 06, 2022 at 09:00:13AM +0100, Andreas Kemnade wrote:
> Adds display parameter initialisation, display power up/down and
> waveform loading
>
> Signed-off-by: Andreas Kemnade
> ---
[...]
> + /* Enable the v3p3 regulator */
> + ret = regulator_enable(priv->v3p3_regulator);
> +
On Sun, Feb 06, 2022 at 09:00:12AM +0100, Andreas Kemnade wrote:
> This driver is for the EPD controller in the i.MX SoCs. Add a skeleton
> and basic things for the driver
>
> Signed-off-by: Andreas Kemnade
> ---
> drivers/gpu/drm/Kconfig | 2 +
> drivers/gpu/drm/Makefile
Hello Andreas,
Sorry for the delay, I finally got around to having a look at the
patchset.
Some comments from skimming the patches below, and in my other replies.
On Sun, Feb 06, 2022 at 09:00:11AM +0100, Andreas Kemnade wrote:
> Add a binding for the Electrophoretic Display Controller found
The pull request you sent on Sat, 12 Mar 2022 17:45:38 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-03-12
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/1518a4f636b39718788c81154420d7abc62fd839
Thank you!
--
Deet-doot-dot, I am a bot.
01.03.2022 19:14, cyn...@kapsi.fi пишет:
> +/* host1x context devices */
> +
> +struct host1x_context {
> + struct host1x *host;
> +
> + refcount_t ref;
> + struct pid *owner;
> +
> + struct device dev;
> + u64 dma_mask;
> + u32 stream_id;
> +};
I'm still not very happy
On Tue 08 Mar 10:54 CST 2022, Vinod Polimera wrote:
Please run:
git log --oneline --no-decorate -- arch/arm64/boot/dts/qcom/sc7280.dtsi
and make sure your $subject is prefixed according to all other
sc7280-specific changes.
> Kernel clock driver assumes that initial rate is the
> max rate
On Saturday, March 12, 2022 7:41 AM, Drew Davenport
wrote:
>On Fri, Mar 11, 2022 at 09:22:14AM +0800, Lee Shawn C wrote:
>> drm_find_cea_extension() always look for a top level CEA block. Pass
>> ext_index from caller then this function to search next available CEA
>> ext block from a specific
22 matches
Mail list logo
