On Tuesday, May 14th, 2024 at 22:42, Laurent Pinchart
wrote:
> My experience on Arm platforms is that the KMS drivers offer allocation
> for scanout buffers, not render buffers, and mostly using the dumb
> allocator API. If the KMS device can scan out YUV natively, YUV buffer
> allocation should
Discussion with Doug and Linus in V1, we need a
separate driver to enable the hx83102 controller.
So this series this series mainly Break out as separate driver
for Starry-himax83102-j02 panels from boe tv101wum driver.
Then add BOE nv110wum-l60 and IVO t109nw41 in himax-hx83102 driver.
Add comp
In V1, discussed with Doug and Linus [1], we need break out as separate
driver for the himax83102-j02 controller. Beacuse "starry,himax83102-j02"
and in this series "BOE nv110wum-l60" "IVO t109nw41" panels use same
controller, they have some common CMDS. So add new documentation for
this panels.
F
The Starry HX83102 based mipi panel should never have been part of the boe
tv101wum-n16 driver. Discussion with Doug and Linus in V1 [1], we need a
separate driver to enable the hx83102 controller.
In hx83102 driver, add DSI commands as macros. So it can add some panels
with same control model in
The BOE nv110wum-l60 is a 11.0" WUXGA TFT LCD panel with himax-hx83102
controller. Hence, we add a new compatible with panel specific config.
Signed-off-by: Cong Yang
Acked-by: Conor Dooley
---
Chage since V8:
- No change.
V7:
https://lore.kernel.org/all/20240515014643.2715010-5-yangco...@hua
The BOE nv110wum-l60 is a 11.0" WUXGA TFT LCD panel, use hx83102 controller
which fits in nicely with the existing panel-himax-hx83102 driver. Hence,
we add a new compatible with panel specific config.
Signed-off-by: Cong Yang
Reviewed-by: Douglas Anderson
Reviewed-by: Linus Walleij
---
Chage s
The IVO t109nw41 is a 11.0" WUXGA TFT LCD panel with himax-hx83102
controller. Hence, we add a new compatible with panel specific config.
Signed-off-by: Cong Yang
Acked-by: Conor Dooley
---
Chage since V8:
- No change.
V7:
https://lore.kernel.org/all/20240515014643.2715010-7-yangco...@huaqin.
The IVO t109nw41 is a 11.0" WUXGA TFT LCD panel, use hx83102 controller
which fits in nicely with the existing panel-himax-hx83102 driver. Hence,
we add a new compatible with panel specific config.
Signed-off-by: Cong Yang
Reviewed-by: Douglas Anderson
Reviewed-by: Linus Walleij
---
Chage since
Hi Dave, Sima
there's only a single patch in this week's drm-misc-fixes PR.
Best regards
Thomas
drm-misc-fixes-2024-05-16:
Short summary of fixes pull:
nouveau:
- use tile_mode and pte_kind for VM_BIND bo allocations
The following changes since commit 6897204ea3df808d342c8e4613135728bc538bcd:
Il 13/05/24 08:15, CK Hu (胡俊光) ha scritto:
On Fri, 2024-05-10 at 12:14 +0200, AngeloGioacchino Del Regno wrote:
Il 10/05/24 11:34, CK Hu (胡俊光) ha scritto:
On Thu, 2024-05-09 at 11:27 +0200, AngeloGioacchino Del Regno
wrote:
Il 09/05/24 07:42, CK Hu (胡俊光) ha scritto:
On Wed, 2024-05-08 at 15:0
Hi,
On Wed, May 15, 2024 at 09:42:34AM +0200, Sean Nyekjaer wrote:
> On Wed, May 15, 2024 at 08:39:49AM UTC, Yannick FERTRE wrote:
> > Hi Sean,
> >
> > thanks for your patch.
> >
> > Tested-by: Yannick Fertre
> >
> > I think that a helper could be useful in simplifying this part.
> > This migh
On 15/05/2024 22:42, Lucas De Marchi wrote:
Print the accumulated runtime for client when printing fdinfo.
Each time a query is done it first does 2 things:
1) loop through all the exec queues for the current client and
accumulate the runtime, per engine class. CTX_TIMESTAMP is used for
On Wed, 15 May 2024, Linus Torvalds wrote:
> On Wed, 15 May 2024 at 16:17, Dave Airlie wrote:
>> AMDGPU, I915 and XE all have !COMPILE_TEST on their variants
>
> Hmm. It turns out that I didn't notice the AMDGPU one because my
> Threadripper - that has AMDGPU enabled - I have actually turned off
Hi,
On Sat, May 11, 2024 at 09:00:45PM +0530, Aradhya Bhatia wrote:
> Add support for mode_fixup for the tidss CRTC.
>
> Some bridges like the cdns-dsi consume the crtc_* timing parameters for
> programming the blanking values. Allow for the normal timing parameters
> to get copied to crtc_* timi
The display IPs in MediaTek SoCs support being interconnected with
different instances of DDP IPs (for example, merge0 or merge1) and/or
with different DDP IPs (for example, rdma can be connected with either
color, dpi, dsi, merge, etc), forming a full Display Data Path that
ends with an actual dis
395 boards;
- Rebased on next-20240516
Changes in v3:
- Rebased on next-20240502 because of renames in mediatek-drm
Changes in v2:
- Fixed wrong `required` block indentation in commit [2/3]
The display IPs in MediaTek SoCs are *VERY* flexible and those support
being interconnected with differ
It is impossible to add each and every possible DDP path combination
for each and every possible combination of SoC and board: right now,
this driver hardcodes configuration for 10 SoCs and this is going to
grow larger and larger, and with new hacks like the introduction of
mtk_drm_route which is a
Document OF graph on MMSYS/VDOSYS: this supports up to three DDP paths
per HW instance (so potentially up to six displays for multi-vdo SoCs).
The MMSYS or VDOSYS is always the first component in the DDP pipeline,
so it only supports an output port with multiple endpoints - where each
endpoint def
On Sat, May 11, 2024 at 09:00:46PM +0530, Aradhya Bhatia wrote:
> Update the Phy initialized state to "not initialized" when the driver
> (and the hardware by extension) gets suspended. This will allow the Phy
> to get initialized again after resume.
>
> Fix the OF node that gets passed to find th
Am 15.05.24 um 15:56 schrieb Maxime Ripard:
The uAPI header has a bunch of constants and structures that might be
handy in drivers.
Let's include the header in the driver-side dma-heap header.
Well as long as this header doesn't need any symbols from the uAPI
itself I think that is a no-go.
Am 15.05.24 um 13:23 schrieb Yong Wu:
Introduce a FLAG for the restricted memory which means the memory is
protected by TEE or hypervisor, then it's inaccessiable for kernel.
Currently we don't use sg_dma_unmark_restricted, thus this interface
has not been added.
Why should that be part of the
./drivers/gpu/drm/amd/amdgpu/amdgpu.h: amdgpu_umsch_mm.h is included more than
once.
Reported-by: Abaci Robot
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=9063
Signed-off-by: Jiapeng Chong
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/driv
On Sat, May 11, 2024 at 09:00:50PM +0530, Aradhya Bhatia wrote:
> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> index 4baca0d9107b..40f93230abb2 100644
> --- a/include/drm/drm_bridge.h
> +++ b/include/drm/drm_bridge.h
> @@ -206,6 +206,20 @@ struct drm_bridge_funcs {
>*/
On Wed, May 15, 2024 at 11:19:58PM +0800, Sui Jingfeng wrote:
> Hi,
>
>
> On 5/15/24 22:58, Maxime Ripard wrote:
> > On Wed, May 15, 2024 at 10:53:00PM +0800, Sui Jingfeng wrote:
> > > On 5/15/24 22:30, Maxime Ripard wrote:
> > > > On Wed, May 15, 2024 at 12:53:33AM +0800, Sui Jingfeng wrote:
> >
If WERROR is already enabled, there's no point in enabling DRM_WERROR or
asking users about it.
Reported-by: Linus Torvalds
Closes:
https://lore.kernel.org/r/CAHk-=whxT8D_0j=bjtrvj-O=veojn6gw8gk4j2v+biduntz...@mail.gmail.com
Fixes: f89632a9e5fa ("drm: Add CONFIG_DRM_WERROR")
Signed-off-by: Jani
Add PANEL_REPLAY_CONFIGURATION_2 register and some missing Panel Replay
bits.
Signed-off-by: Jouni Högander
---
include/drm/display/drm_dp.h | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
index 906
eDP1.5 adds some more bits into DP_RECEIVER_ALPM_CAP and
DP_RECEIVER_ALPM_CONFIG registers. Add definitions for these.
Signed-off-by: Jouni Högander
---
include/drm/display/drm_dp.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
Thanks for this refactor of mgag200.
for the whole series:
Reviewed-by: Jocelyn Falempe
--
Jocelyn
On 13/05/2024 14:51, Thomas Zimmermann wrote:
Clean up a the driver's DDC code, make it simpler, more robust, and
mostly self contained. The patches in this patchset have previously
been sent
Hi Andy,
On Sun, May 12, 2024 at 04:29:47PM +0800, Andy Yan wrote:
> At 2024-05-07 21:17:45, "Maxime Ripard" wrote:
> >The new HDMI connector infrastructure allows to remove some boilerplate,
> >especially to generate infoframes. Let's switch to it.
> >
> >Reviewed-by: Heiko Stuebner
> >Acked-by
Hi Maxime,
Thank you for reviewing the patches!
On 16/05/24 13:52, Maxime Ripard wrote:
> On Sat, May 11, 2024 at 09:00:50PM +0530, Aradhya Bhatia wrote:
>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
>> index 4baca0d9107b..40f93230abb2 100644
>> --- a/include/drm/drm_bridge.
On 16/05/24 13:41, Maxime Ripard wrote:
> On Sat, May 11, 2024 at 09:00:46PM +0530, Aradhya Bhatia wrote:
>> Update the Phy initialized state to "not initialized" when the driver
>> (and the hardware by extension) gets suspended. This will allow the Phy
>> to get initialized again after resume.
Il 16/05/24 11:23, CK Hu (胡俊光) ha scritto:
Hi, Angelo:
On Thu, 2024-05-16 at 10:11 +0200, AngeloGioacchino Del Regno wrote:
Document OF graph on MMSYS/VDOSYS: this supports up to three DDP paths
per HW instance (so potentially up to six displays for multi-vdo SoCs).
The MMSYS or VDOSYS is alwa
Hi again,
On Sun, May 12, 2024 at 04:18:38PM +0800, Andy Yan wrote:
> 在 2024-05-07 21:17:33，"Maxime Ripard" 写道：
> >Now that we have all the infrastructure needed, we can add some code
> >that will, for a given connector state and mode, compute the best output
> >format and bpc.
> >
> >The algorit
Hi,
On 5/16/24 14:26, Markus Elfring wrote:
…
fullfill the implement under the new framework.
fulfil the implementation?
Please improve your change descriptions another bit.
I'll accept you suggestions, with pleasure. Thanks.
Regards,
Markus
--
Best regards
Sui
Il 15/05/24 13:23, Yong Wu ha scritto:
Introduce a FLAG for the restricted memory which means the memory is
protected by TEE or hypervisor, then it's inaccessiable for kernel.
Currently we don't use sg_dma_unmark_restricted, thus this interface
has not been added.
Signed-off-by: Yong Wu
---
Commit f3d9683346d6 ("drm/bridge: adv7511: Allow IRQ to share GPIO pins")
fails to consider the case where adv7511->i2c_main->irq is zero, i.e.,
no interrupt requested at all.
Without interrupt, adv7511_wait_for_edid() could return -EIO sometimes,
because it polls adv7511->edid_read flag by callin
Il 09/04/24 19:02, Uwe Kleine-König ha scritto:
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this
On Mon, May 13, 2024 at 01:51:23PM +, Simon Ser wrote:
> On Wednesday, May 8th, 2024 at 17:49, Daniel Vetter wrote:
>
> > On Wed, May 08, 2024 at 09:38:33AM +0100, Daniel Stone wrote:
> >
> > > On Wed, 8 May 2024 at 09:33, Daniel Vetter dan...@ffwll.ch wrote:
> > >
> > > > On Wed, May 08, 2
On Thu, May 09, 2024 at 10:23:16AM +0100, Daniel Stone wrote:
> Hi,
>
> On Wed, 8 May 2024 at 16:49, Daniel Vetter wrote:
> > On Wed, May 08, 2024 at 09:38:33AM +0100, Daniel Stone wrote:
> > > Right now, if your platform requires CMA for display, then the app
> > > needs access to the GPU render
On Wed, May 08, 2024 at 08:38:00PM +0100, Chris Clayton wrote:
>
>
> On 08/05/2024 16:54, Daniel Vetter wrote:
> > On Wed, May 08, 2024 at 09:02:02AM +0100, Chris Clayton wrote:
> >> Hi,
> >>
> >> I'm running the latest development kernel - 6.9.0-rc7+ (HEAD is
> >> dccb07f2914cdab2ac3a5b6c98406f
Hi,
On 5/16/24 16:25, Maxime Ripard wrote:
On Wed, May 15, 2024 at 11:19:58PM +0800, Sui Jingfeng wrote:
Hi,
On 5/15/24 22:58, Maxime Ripard wrote:
On Wed, May 15, 2024 at 10:53:00PM +0800, Sui Jingfeng wrote:
On 5/15/24 22:30, Maxime Ripard wrote:
On Wed, May 15, 2024 at 12:53:33AM +0800,
Hi Maxime,
On 5/16/24 17:45, Maxime Ripard wrote:
Hi again,
On Sun, May 12, 2024 at 04:18:38PM +0800, Andy Yan wrote:
在 2024-05-07 21:17:33，"Maxime Ripard" 写道：
Now that we have all the infrastructure needed, we can add some code
that will, for a given connector state and mode, compute the be
Hi Louis,
On 5/13/24 04:50, Louis Chauvet wrote:
As all the rotation are now supported by VKMS, this simplification does
not make sense anymore, so remove it.
Signed-off-by: Louis Chauvet
I'd like to push all commits up to this point to drm-misc-next. Do you
see a problem with it? Reason: I'
Hi
Am 16.05.24 um 11:14 schrieb Jocelyn Falempe:
Thanks for this refactor of mgag200.
for the whole series:
Reviewed-by: Jocelyn Falempe
Thank you so much!
Best regards
Thomas
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 9046
On Wed, May 15, 2024 at 11:42:58AM -0700, John Stultz wrote:
> On Wed, May 15, 2024 at 6:57 AM Maxime Ripard wrote:
> > This series is the follow-up of the discussion that John and I had a few
> > months ago here:
> >
> > https://lore.kernel.org/all/candhncqujn6bh3kxkf65bwitylvqsd9892-xtfdhhqqyrro
Hi Maxime,
Thank you for reviewing the patches.
On 16/05/24 13:40, Maxime Ripard wrote:
> Hi,
>
> On Sat, May 11, 2024 at 09:00:45PM +0530, Aradhya Bhatia wrote:
>> Add support for mode_fixup for the tidss CRTC.
>>
>> Some bridges like the cdns-dsi consume the crtc_* timing parameters for
>> pro
Hi Liu,
Thanks for reviewing the patch.
On 16/05/24 07:49, Liu Ying wrote:
> On 5/15/24 17:51, Aradhya Bhatia wrote:
>> Add the Microtips Technology USA's MF-101HIEBCAF0 10.1"[0] panel,
>> MF-103HIEB0GA0 10.25"[1] panel, and Lincoln Technology Solutions'
>> LCD185-101CT 10.1"[2] panel.
>>
>> Thes
Le 16/05/24 - 07:43, Maíra Canal a écrit :
> Hi Louis,
>
> On 5/13/24 04:50, Louis Chauvet wrote:
> > As all the rotation are now supported by VKMS, this simplification does
> > not make sense anymore, so remove it.
> >
> > Signed-off-by: Louis Chauvet
>
> I'd like to push all commits up to thi
Hi,
On 5/16/24 18:10, Liu Ying wrote:
Commit f3d9683346d6 ("drm/bridge: adv7511: Allow IRQ to share GPIO pins")
fails to consider the case where adv7511->i2c_main->irq is zero, i.e.,
no interrupt requested at all.
Without interrupt, adv7511_wait_for_edid() could return -EIO sometimes,
because
On Thu, May 16, 2024 at 07:00:31AM +, Simon Ser wrote:
> On Tuesday, May 14th, 2024 at 22:42, Laurent Pinchart wrote:
>
> > My experience on Arm platforms is that the KMS drivers offer allocation
> > for scanout buffers, not render buffers, and mostly using the dumb
> > allocator API. If the K
Hi Nicolas,
On Wed, May 15, 2024 at 01:43:58PM -0400,
nicolas.dufre...@collabora.corp-partner.google.com wrote:
> Le mardi 14 mai 2024 à 23:42 +0300, Laurent Pinchart a écrit :
> > > You'll hit the same limitation as we hit in GStreamer, which is that KMS
> > > driver
> > > only offer allocation
Am 16.05.24 um 12:13 schrieb Daniel Vetter:
(Long w/en and I caught a cold)
Handing over a coup of tea.
I'm fighting with a cold since last week and I think it's one of the
worst I've ever had.
(On the other hand every cold feels like the worst you ever had).
Christian.
Hi Sui,
On Thu, May 16, 2024 at 12:13:03AM +0800, Sui Jingfeng wrote:
> On 5/14/24 23:12, Laurent Pinchart wrote:
> > On Tue, May 14, 2024 at 12:26:15AM +0800, Sui Jingfeng wrote:
> >> On 5/13/24 16:02, Liu Ying wrote:
> >>> The connector is created by either this ADV7511 bridge driver or
> >>> an
On 5/16/24 18:40, Sui Jingfeng wrote:
use 'to_i2c_client(bridge->dev)' to retrieve the pointer
to_i2c_client(bridge->kdev).
Besides, this also means that we don't need to add the fwnode
pointer into struct drm_bridge as member. Relief the conflicts
with other reviewers if the work of switch
From: Tvrtko Ursulin
Currently the driver appears to be thinking that it will be attempting to
re-validate the evicted buffers on the next submission if they are not in
their preferred placement.
That however appears not to be true for the very common case of buffers
with allowed placements of V
From: Tvrtko Ursulin
Current code appears to live in a misconception that playing with buffer
allowed and preferred placements can always control the decision on
whether backing store migration will be attempted or not.
That is however not the case when userspace sets buffer placements of
VRAM+G
From: Tvrtko Ursulin
Reduced re-spin of my previous series after Christian corrected a few
misconceptions that I had. So lets see if what remains makes sense or is still
misguided.
To summarise, the series address the following two issues:
* Migration rate limiting does not work, at least not
The patch series used to enable secure video playback (SVP) on MediaTek
hardware in the Linux kernel.
Memory Definitions:
secure memory - Memory allocated in the TEE (Trusted Execution
Environment) which is inaccessible in the REE (Rich Execution
Environment, i.e. linux kernel/user space).
secure
From: Jeffrey Kardatzke
Adds a V4L2 flag which indicates that a queue is using restricted
dmabufs and the corresponding capability flag.
Signed-off-by: Jeffrey Kardatzke
Signed-off-by: Yunfei Dong
---
include/media/videobuf2-core.h | 8 +++-
include/uapi/linux/videodev2.h | 2 ++
2 files
From: "T.J. Mercier"
The docs for dma_heap_get_name were incorrect, and since they were
duplicated in the header they were wrong there too.
The docs formatting was inconsistent so I tried to make it more
consistent across functions since I'm already in here doing cleanup.
Remove multiple unused
From: Jeffrey Kardatzke
Adds documentation for V4L2_MEMORY_FLAG_RESTRICTED.
Signed-off-by: Jeffrey Kardatzke
Signed-off-by: Yunfei Dong
---
Documentation/userspace-api/media/v4l/buffer.rst | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/Documentation/userspace-ap
From: Jeffrey Kardatzke
Verfies in the dmabuf implementations that if the restricted memory
flag is set for a queue that the dmabuf submitted to the queue is
unmappable.
Signed-off-by: Jeffrey Kardatzke
Signed-off-by: Yunfei Dong
---
drivers/media/common/videobuf2/videobuf2-dma-contig.c | 8 +
From: Jeffrey Kardatzke
Validates the restricted memory flags when setting up a queue and
ensures the queue has the proper capability.
Signed-off-by: Jeffrey Kardatzke
Signed-off-by: Yunfei Dong
---
.../media/common/videobuf2/videobuf2-core.c | 21 +++
.../media/common/video
Open tee context to initialize the environment in order to communication
with optee-os, then open tee session as the communication pipeline for
lat and core to send data for hardware decode.
Signed-off-by: Yunfei Dong
---
.../platform/mediatek/vcodec/decoder/Makefile | 1 +
.../vcodec/decoder/
From: John Stultz
Add proper refcounting on the dma_heap structure.
While existing heaps are built-in, we may eventually
have heaps loaded from modules, and we'll need to be
able to properly handle the references to the heaps
Signed-off-by: John Stultz
Signed-off-by: T.J. Mercier
Signed-off-by
From: John Stultz
This allows drivers who don't want to create their own
DMA-BUF exporter to be able to allocate DMA-BUFs directly
from existing DMA-BUF Heaps.
There is some concern that the premise of DMA-BUF heaps is
that userland knows better about what type of heap memory
is needed for a pip
Need to call dma heap interface to allocate/free secure memory when playing
secure video.
Signed-off-by: Yunfei Dong
---
.../media/platform/mediatek/vcodec/Kconfig| 1 +
.../mediatek/vcodec/common/mtk_vcodec_util.c | 122 +-
.../mediatek/vcodec/common/mtk_vcodec_util.h |
Hi,
On 5/16/24 18:10, Liu Ying wrote:
Commit f3d9683346d6 ("drm/bridge: adv7511: Allow IRQ to share GPIO pins")
fails to consider the case where adv7511->i2c_main->irq is zero, i.e.,
no interrupt requested at all.
Without interrupt, adv7511_wait_for_edid() could return -EIO sometimes,
because
Setting msg and vsi information to shared buffer, then call tee invoke
function to send it to optee-os.
Signed-off-by: Yunfei Dong
---
.../vcodec/decoder/mtk_vcodec_dec_optee.c | 140 ++
.../vcodec/decoder/mtk_vcodec_dec_optee.h | 51 +++
2 files changed, 191 inserti
Waiting interrupt in optee-os for svp mode, need to disable it in kernel
in case of interrupt is cleaned.
Signed-off-by: Yunfei Dong
---
.../vcodec/decoder/mtk_vcodec_dec_hw.c| 34 +--
.../vcodec/decoder/mtk_vcodec_dec_pm.c| 6 +-
.../decoder/vdec/vdec_h264_req_multi_if.
The capture buffer has two planes for format MM21, but user space only
allocate secure memory for plane[0], and the size is Y data + uv data.
The driver need to support one plane decoder for svp mode.
Signed-off-by: Yunfei Dong
---
.../mediatek/vcodec/decoder/mtk_vcodec_dec.c | 7 -
.../vc
From: Yilong Zhou
Change vp9 driver to support secure video playback(svp) for
mt8188. Need to map shared memory with optee interface and
wait interrupt in optee-os.
Signed-off-by: Yilong Zhou
Signed-off-by: Yunfei Dong
---
.../vcodec/decoder/vdec/vdec_vp9_req_lat_if.c | 91 ---
Define one uncompressed capture format V4L2_PIX_FMT_MS21 in order to
support one plane memory. The buffer size is luma + chroma, luma is
stored at the start and chrome is stored at the end.
Signed-off-by: Yunfei Dong
---
Documentation/userspace-api/media/v4l/pixfmt-reserved.rst | 8
dri
The vsi buffer is allocated by tee share memory for svp mode, need to
use the share memory as the vsi address to store vsi data.
Signed-off-by: Yunfei Dong
---
.../vcodec/decoder/vdec/vdec_h264_req_multi_if.c | 9 +++--
.../media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c | 8 +++
Change hevc driver to support secure video playback(svp) for
mt8188. Need to map shared memory with optee interface and
wait interrupt in optee-os.
Signed-off-by: Yunfei Dong
---
.../decoder/vdec/vdec_hevc_req_multi_if.c | 89 +++
1 file changed, 54 insertions(+), 35 deletion
Getting secure video playback (svp) flag when request output buffer, then
calling init interface to init svp parameters in optee-os.
Signed-off-by: Yunfei Dong
---
.../mediatek/vcodec/decoder/mtk_vcodec_dec.c | 139 +++---
1 file changed, 89 insertions(+), 50 deletions(-)
diff --gi
Initialize tee private data to support secure decoder.
Release tee related information for each instance when decoder
done.
Signed-off-by: Yunfei Dong
---
.../platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c | 8
1 file changed, 8 insertions(+)
diff --git
a/drivers/media/platform
Adding capture formats to support V4L2_PIX_FMT_MS21. This format has
one plane and only be used for secure video playback at current period.
Signed-off-by: Yunfei Dong
---
.../platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c| 4 +++-
.../mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
From: Xiaoyong Lu
Change av1 driver to support secure video playback(svp) for
mt8188. Need to map shared memory with optee interface and
wait interrupt in optee-os.
Signed-off-by: Xiaoyong Lu
Signed-off-by: Yunfei Dong
---
.../vcodec/decoder/vdec/vdec_av1_req_lat_if.c | 97 ---
Allocate two share memory for each lat and core hardware used to share
information with optee-os. Msg buffer used to send ipi command and get ack
command with optee-os, data buffer used to store vsi information which
used for hardware decode.
Signed-off-by: Yunfei Dong
---
.../vcodec/decoder/mtk
The hardware can parse syntax to get nal_info, needn't to use cpu.
Signed-off-by: Yunfei Dong
---
.../vcodec/decoder/vdec/vdec_h264_req_multi_if.c| 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git
a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_
Need secure buffer size to convert secure handle to secure
pa in optee-os, re-construct the vsi struct to store each
secure buffer size.
Separate svp and normal wait interrupt condition for svp mode
waiting hardware interrupt in optee-os.
Signed-off-by: Yunfei Dong
---
.../decoder/vdec/vdec_h26
Need to initialize msg and vsi information before sending to optee-os, then
calling optee invoke command to send the information to optee-os.
For the optee communication interface is different with scp, using
flag to separate them.
Signed-off-by: Yunfei Dong
---
.../vcodec/decoder/mtk_vcodec_de
Hi John,
Thanks for your feedback
On Wed, May 15, 2024 at 11:42:58AM -0700, John Stultz wrote:
> On Wed, May 15, 2024 at 6:57 AM Maxime Ripard wrote:
> > This series is the follow-up of the discussion that John and I had a few
> > months ago here:
> >
> > https://lore.kernel.org/all/candhncqujn6
On Thu, May 16, 2024 at 5:01 AM Liu Ying wrote:
>
> Commit f3d9683346d6 ("drm/bridge: adv7511: Allow IRQ to share GPIO pins")
> fails to consider the case where adv7511->i2c_main->irq is zero, i.e.,
> no interrupt requested at all.
Sorry about that.
>
> Without interrupt, adv7511_wait_for_edid()
On 16/05/2024 13:06, Aradhya Bhatia wrote:
Hi Liu,
Thanks for reviewing the patch.
On 16/05/24 07:49, Liu Ying wrote:
On 5/15/24 17:51, Aradhya Bhatia wrote:
Add the Microtips Technology USA's MF-101HIEBCAF0 10.1"[0] panel,
MF-103HIEB0GA0 10.25"[1] panel, and Lincoln Technology Solutions'
LCD
Hi,
On 5/16/24 16:33, Jani Nikula wrote:
If WERROR is already enabled, there's no point in enabling DRM_WERROR or
asking users about it.
Reported-by: Linus Torvalds
Closes:
https://lore.kernel.org/r/CAHk-=whxT8D_0j=bjtrvj-O=veojn6gw8gk4j2v+biduntz...@mail.gmail.com
Fixes: f89632a9e5fa ("drm:
These drivers don't use the driver_data member of struct i2c_device_id,
so don't explicitly initialize this member.
This prepares putting driver_data in an anonymous union which requires
either no initialization or named designators. But it's also a nice
cleanup on its own.
While add it, also rem
On Thu, May 16, 2024 at 12:56:27PM +0200, Daniel Vetter wrote:
> On Wed, May 15, 2024 at 11:42:58AM -0700, John Stultz wrote:
> > On Wed, May 15, 2024 at 6:57 AM Maxime Ripard wrote:
> > > This series is the follow-up of the discussion that John and I had a few
> > > months ago here:
> > >
> > > h
Commit 2fd001cd3600 ("arch: Rename fbdev header and source files")
renames the video source files under arch/ such that they does not
refer to fbdev any longer. The new files named video.o conflict with
ACPI's video.ko module. Modprobing the ACPI module can then fail with
warnings about missing sym
: a38297e3fb012ddfa7ce0321a7e5a8daeb1872b6
patch link:
https://lore.kernel.org/r/20240515-dma-buf-ecc-heap-v1-7-54cbbd049511%40kernel.org
patch subject: [PATCH 7/8] dma-buf: heaps: cma: Handle ECC flags
config: mips-allmodconfig
(https://download.01.org/0day-ci/archive/20240516/202405162048.cexrv8yy
On Wed, May 15, 2024 at 04:45:09PM +0200, Javier Martinez Canillas wrote:
> Devarsh Thakkar writes:
>
> Hello Devarsh and Maxime,
>
> > Hi Maxime,
> >
> > On 14/03/24 20:04, Maxime Ripard wrote:
> >> Hi,
> >>
> >> On Wed, Feb 14, 2024 at 09:17:12PM +0530, Devarsh Thakkar wrote:
> >>> On 13/02/2
CC Hans who has been doing the majority of the ACPI video work.
On Thu, May 16, 2024 at 2:43 PM Thomas Zimmermann wrote:
>
> Commit 2fd001cd3600 ("arch: Rename fbdev header and source files")
> renames the video source files under arch/ such that they does not
> refer to fbdev any longer. The new
On Thu, May 16, 2024 at 4:42 AM Jani Nikula wrote:
>
> On Wed, 15 May 2024, Linus Torvalds wrote:
> > On Wed, 15 May 2024 at 16:17, Dave Airlie wrote:
> >> AMDGPU, I915 and XE all have !COMPILE_TEST on their variants
> >
> > Hmm. It turns out that I didn't notice the AMDGPU one because my
> > T
This patchset is the second version of [1]. It is almost a complete
rewrite to use a line-by-line algorithm for the composition.
During the development of this series Pekka and Arthur found an issue in
drm core. The YUV part of this series depend on the fix [9]. I'll let
Arthur extract it and subm
From: Arthur Grillo
Remove intermidiary variables and access the variables directly from
drm_frame. These changes should be noop.
Signed-off-by: Arthur Grillo
Acked-by: Pekka Paalanen
Reviewed-by: Maíra Canal
Reviewed-by: Louis Chauvet
[Louis Chauvet: Applied review from Maíra]
Signed-off-by
Few no-op changes to remove double spaces and fix wrong alignments.
Reviewed-by: Pekka Paalanen
Reviewed-by: Maíra Canal
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/vkms/vkms_composer.c | 10 +-
drivers/gpu/drm/vkms/vkms_crtc.c | 6 ++
drivers/gpu/drm/vkms/vkms_drv.c
Introduce two typedefs: pixel_read_t and pixel_write_t. It allows the
compiler to check if the passed functions take the correct arguments.
Such typedefs will help ensuring consistency across the code base in
case of update of these prototypes.
Rename input/output variable in a consistent way betw
Introduce two callbacks which does nothing. They are used in replacement
of NULL and it avoid kernel OOPS if this NULL is called.
If those callback are used, it means that there is a mismatch between
what formats are announced by atomic_check and what is realy supported by
atomic_update.
Acked-by
1 - 100 of 181 matches
Mail list logo
