On Wed, Oct 25, 2023 at 12:23:10PM +0300, Dmitry Baryshkov wrote:
> While developing and testing the commit bfcc3d8f94f4 ("drm/msm/dp:
> support setting the DP subconnector type") I had the patch [1] in my
> tree. I haven't noticed that it was a dependency for the commit in
> question. Mea culpa.
On 14/11/2023 16:55, Michal Wajdeczko wrote:
On 14.11.2023 13:37, Tvrtko Ursulin wrote:
On 10/11/2023 18:22, Michal Wajdeczko wrote:
The Single Root I/O Virtualization (SR-IOV) extension to the PCI
Express (PCIe) specification suite is supported starting from 12th
generation of Intel
From: Stefan Eichenberger
Add Lontium lt8912b power supplies.
Signed-off-by: Stefan Eichenberger
Signed-off-by: Francesco Dolcini
---
.../display/bridge/lontium,lt8912b.yaml | 21 +++
1 file changed, 21 insertions(+)
diff --git
From: Francesco Dolcini
Add support for suspend and resume, power off the bridge when going into
suspend and power on when resuming.
Stefan Eichenberger (3):
drm/bridge: lt8912b: Add suspend/resume support
dt-bindings: display: bridge: lt8912b: Add power supplies
drm/bridge: lt8912b: Add
From: Stefan Eichenberger
Add support for suspend and resume. The lt8912b will power off when
going into suspend and power on when resuming.
Signed-off-by: Stefan Eichenberger
Signed-off-by: Francesco Dolcini
---
drivers/gpu/drm/bridge/lontium-lt8912b.c | 28
1 file
From: Stefan Eichenberger
Add supplies to the driver that can be used to turn the Lontium lt8912b
on and off. It can have up to 7 independent supplies, we add them all
and enable/disable them with bulk_enable/disable.
Signed-off-by: Stefan Eichenberger
Signed-off-by: Francesco Dolcini
---
Add the first version of the VM_BIND locking document which is
intended to be part of the xe driver upstreaming agreement.
The document describes and discuss the locking used during exec-
functions, evicton and for userptr gpu-vmas. Intention is to be using the
same nomenclature as the
On Wed, 15 Nov 2023 at 01:00, Jonathan Marek wrote:
>
> Add necessary DPU changes for DSC to work with DSI video mode.
>
> Note this changes the logic to enable HCTL to match downstream, it will
> now be enabled for the no-DSC no-widebus case.
>
> Signed-off-by: Jonathan Marek
> ---
>
Hello Danilo,
On Tue, Nov 14, 2023 at 05:23:59PM +0100, Danilo Krummrich wrote:
> Hi Yuran,
>
> op_map_prepare() can't be called with `args` being NULL, since when called
> through nouveau_uvmm_sm_unmap_prepare() we can't hit the DRM_GPUVA_OP_MAP
> case at all.
>
> Unmapping something never
On Wed, 15 Nov 2023 11:35:36 +0100, Marco Pagani wrote:
> Rearrange entries in Kconfig and Makefile alphabetically to make room
> for additional KUnit test suites.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
Hi Andy,
Thanks for your patches, some remarks inline.
On Tue, Nov 14, 2023 at 07:28:55PM +0800, Andy Yan wrote:
> From: Andy Yan
>
> VOP2 on rk3588:
>
> Four video ports:
> VP0 Max 4096x2160
> VP1 Max 4096x2160
> VP2 Max 4096x2160
> VP3 Max 2048x1080
>
> 4 4K Cluster windows with AFBC/line
Rearrange entries in Kconfig and Makefile alphabetically to make room
for additional KUnit test suites.
Signed-off-by: Marco Pagani
---
drivers/gpu/drm/Kconfig| 10 +-
drivers/gpu/drm/tests/Makefile | 4 ++--
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git
Am 02.11.23 um 14:08 schrieb Thomas Zimmermann:
Do not acquire a reference on the module that provides a client's
callback functions in drm_client_init(). The additional reference
prevents the user from unloading the callback functions' module and
thus creating dangling pointers.
This is only
On Wed, Oct 25, 2023 at 12:23:09PM +0300, Dmitry Baryshkov wrote:
> From: Abel Vesa
>
> In case of the eDP connection there is no subconnetor and as such no
> subconnector property. Put drm_dp_set_subconnector_property() calls
> under the !is_edp condition.
>
> Fixes: bfcc3d8f94f4 ("drm/msm/dp:
Am Mittwoch, 15. November 2023, 03:02:42 CET schrieb Andy Yan:
> Hi Heiko:
>
> On 11/15/23 07:34, Heiko Stübner wrote:
> > Hi Andy,
> >
> > Am Dienstag, 14. November 2023, 12:28:55 CET schrieb Andy Yan:
> >> From: Andy Yan
> >>
> >> VOP2 on rk3588:
> >>
> >> Four video ports:
> >> VP0 Max
Hello,
syzbot found the following issue on:
HEAD commit:ac347a0655db Merge tag 'arm64-fixes' of git://git.kernel.o..
git tree: upstream
console+strace: https://syzkaller.appspot.com/x/log.txt?x=101ba588e8
kernel config: https://syzkaller.appspot.com/x/.config?x=88e7ba51eecd9cd6
If a driver sets struct fb_ops.fb_mmap, the fbdev core automatically
calls pgprot_decrypted(). But the default fb_mmap code doesn't handle
pgprot_decrypted().
Move the call to pgprot_decrypted() into each drivers' fb_mmap function.
This only concerns fb_mmap functions for system and DMA memory.
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in I/O address space. Set the read/write,
draw and mmap callbacks to the correct implementation and avoid
implicit defaults. Also select the necessary helpers in Kconfig.
The driver previously selected drawing
The ht16k33 driver operates on system memory. Mark the framebuffer
accordingly. Helpers operating on the framebuffer memory will test
for the presence of this flag.
Signed-off-by: Thomas Zimmermann
Cc: Miguel Ojeda
Cc: Robin van der Gracht
---
drivers/auxdisplay/ht16k33.c | 1 +
1 file
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in DMA-able address space. This explictily
sets the read/write, draw and mmap callbacks to the correct default
implementation. Also select the necessary helpers in Kconfig.
Fbdev drivers sometimes rely on the
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in virtual address space. Set the read/write,
draw and mmap callbacks to the correct implementation and avoid
implicit defaults. Also select the necessary helpers in Kconfig.
Fbdev drivers sometimes rely on
Split up lynxfb_ops and declare each as constant. The fb_ops
instance used to be modified while initializing the driver. It is
now constant and the driver picks the correct instance, depending
on the settings for acceleration and cursor support.
Signed-off-by: Thomas Zimmermann
Cc: Sudip
Move the default fb_mmap code for I/O address spaces into the helper
function fb_io_mmap(). The helper can either be called via struct
fb_ops.fb_mmap or as the default if no fb_mmap has been set. Also
set the new helper in __FB_DEFAULT_IOMEM_OPS_MMAP.
In the mid-term, fb_io_mmap() is supposed to
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in virtual address space. Set the read/write,
draw and mmap callbacks to the correct implementation and avoid
implicit defaults. Also select the necessary helpers in Kconfig.
Fbdev drivers sometimes rely on
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in I/O address space. Set the read/write,
draw and mmap callbacks to the correct implementation and avoid
implicit defaults. Also select the necessary helpers in Kconfig.
Fbdev drivers sometimes rely on the
Test in framebuffer read, write and drawing helpers if FBINFO_VIRTFB
has been set correctly. Framebuffers in I/O memory should only be
accessed with the architecture's respective helpers. Framebuffers
in system memory should be accessed with the regular load and
store operations. Presumably not
The ps3fb driver operates on system memory. Mark the framebuffer
accordingly. Helpers operating on the framebuffer memory will test
for the presence of this flag.
Signed-off-by: Thomas Zimmermann
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Christophe Leroy
Cc: linuxppc-...@lists.ozlabs.org
Implement the driver's fops with the generator macros for deferred
I/O. Only requires per-driver code for the on-scren scanout buffer.
The generated helpers implement reading, writing and drawing on top
of that. Also update the selected Kconfig tokens accordingly.
Actual support for deferred I/O
Rename the token to harmonize naming among various helpers. For
example, I/O-memory helpers use FB_IOMEM_FOPS.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/Kconfig | 4 ++--
drivers/video/fbdev/core/Kconfig | 6 +++---
drivers/video/fbdev/core/Makefile | 2 +-
3 files
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in DMA-able virtual address space. Set the
read/write, draw and mmap callbacks to the correct implementation
and avoid implicit defaults. Also select the necessary helpers in
Kconfig.
The driver uses a mixture
The sh_mobile_lcdcfb driver operates on DMA-able system memory. Mark
the framebuffer accordingly. Helpers operating on the framebuffer memory
will test for the presence of this flag.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/sh_mobile_lcdcfb.c | 2 ++
1 file changed, 2
Drop the default implementations for file read, write and mmap
operations. Each fbdev driver must now provide an implementation
and select any necessary helpers. If no implementation has been
set, fbdev returns an errno code to user space. The code is the
same as if the operation had not been set
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in DMA-able virtual address space. Set the
read/write, draw and mmap callbacks to the correct implementation
and avoid implicit defaults. Also select the necessary helpers in
Kconfig.
Fbdev drivers sometimes
Fix coding style. No functional changes.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/sbuslib.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/sbuslib.c b/drivers/video/fbdev/sbuslib.c
index 21e9fd8e69e26..4d524db5c4f26 100644
---
The driver uses deferred I/O. Select the correct helpers via
FB_SYSMEM_HELPERS_DEFERRED in the Kconfig file.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/Kconfig | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/video/fbdev/Kconfig
Initialize all instances of struct fb_ops with fbdev initializer
macros for framebuffers in I/O address space. Set the read/write,
draw and mmap callbacks to the correct implementation and avoid
implicit defaults. Also select the necessary helpers in Kconfig.
Fbdev drivers sometimes rely on the
The arcfb driver operates on system memory. Mark the framebuffer
accordingly. Helpers operating on the framebuffer memory will test
for the presence of this flag.
Signed-off-by: Thomas Zimmermann
Cc: Jaya Kumar
---
drivers/video/fbdev/arcfb.c | 1 +
1 file changed, 1 insertion(+)
diff --git
The vfb driver operates on system memory. Mark the framebuffer
accordingly. Helpers operating on the framebuffer memory will test
for the presence of this flag.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/vfb.c | 1 +
1 file changed, 1 insertion(+)
diff --git
On Wed, 15 Nov 2023 at 05:54, Danilo Krummrich wrote:
>
> On 11/5/23 21:37, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > If we get back ENODEV don't fail load.
>
> Maybe worth to note why this is OK in this case, might not be obvious
> to future readers of the code.
Sent an updated version
On Tue, 14 Nov 2023, Luben Tuikov wrote:
> diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
> index a93a387f8a1a15..ce784118e4f762 100644
> --- a/include/drm/drm_print.h
> +++ b/include/drm/drm_print.h
> @@ -453,7 +453,7 @@ void __drm_dev_dbg(struct _ddebug *desc, const struct
>
It's valid to add the same fence multiple times to a dma-resv object and
we shouldn't need one extra slot for each.
Signed-off-by: Christian König
Fixes: a3f7c10a269d5 ("dma-buf/dma-resv: check if the new fence is really
later")
Cc: sta...@vger.kernel.org # v5.19+
---
Hi Mario,
On Tue, Nov 14, 2023 at 02:07:53PM -0600, Mario Limonciello wrote:
> USB4 routers support a feature called "PCIe tunneling". This
> allows PCIe traffic to be transmitted over USB4 fabric.
>
> PCIe root ports that are used in this fashion can be discovered
> by device specific data that
From: Tvrtko Ursulin
The GSC CS is not exposed to the user, so we skipped assigning a uabi
class number for it. However, the trace logs use the uabi class and
instance to identify the engine, so leaving uabi class unset makes the
GSC CS show up as the RCS in those logs.
Given that the engine is
Hello,
This series is to fix an issue that surfaced after damage clipping was
enabled for the virtio-gpu by commit 01f05940a9a7 ("drm/virtio: Enable
fb damage clips property for the primary plane").
After that change, flickering artifacts was reported to be present with
both weston and wlroots
The "Damage Tracking Properties" section in the documentation doesn't have
info about the two type of damage handling: frame damage vs buffer damage.
Add it to the section and mention that helpers only support frame damage,
and how drivers handling buffer damage can indicate that the damage clips
Currently, only damage tracking for frame damage is supported. If a driver
needs to do buffer damage (e.g: the framebuffer attached to plane's state
has changed since the last page-flip), the damage helpers just fallback to
a full plane update.
Add en entry in the TODO about implementing buffer
The driver does per-buffer uploads and needs to force a full plane update
if the plane's attached framebuffer has change since the last page-flip.
Fixes: 01f05940a9a7 ("drm/virtio: Enable fb damage clips property for the
primary plane")
Cc: # v6.4+
Reported-by: nerdopolis
Closes:
The driver does per-buffer uploads and needs to force a full plane update
if the plane's attached framebuffer has change since the last page-flip.
Suggested-by: Sima Vetter
Signed-off-by: Javier Martinez Canillas
---
Changes in v2:
- Set struct drm_plane_state .ignore_damage_clips in vmwgfx
Hi Jacopo Mondi,
> -Original Message-
> From: Jacopo Mondi
> Subject: Re: [PATCH v12 3/4] drm: renesas: Add RZ/G2L DU Support
>
> Hi Biju
>
> the series does not apply on v6.3. What is the base for the series ?
This patch series is based on drm-misc. I will add base-commit id on
ok， I will do this in my next patch
Thanks your advice!
On 2023/10/25 23:44, Simon Ser wrote:
> it seems like you could start with just simple
> enumerated modifiers like Intel does, and then only switch to more
> complicated logic with macros and fields if there is an actual need in
> the
Hi Michal,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm/drm-next drm-exynos/exynos-drm-next
drm-intel/for-linux-next drm-intel/for-linux-next-fixes drm-tip/drm-tip
linus/master v6.7-rc1 next-20231115
Make msm use drm_gem_create_map_offset() instead of its custom
implementation for associating GEM object with a fake offset. Since,
we already have this generic implementation, we don't need the custom
implementation and it is better to standardize the code for GEM based
drivers. This also removes
On Wed, Nov 15, 2023 at 01:13:37PM +0100, Francesco Dolcini wrote:
> From: Stefan Eichenberger
>
> Add Lontium lt8912b power supplies.
>
> Signed-off-by: Stefan Eichenberger
> Signed-off-by: Francesco Dolcini
Acked-by: Conor Dooley
Cheers,
Conor,
> ---
>
Fix build by using the correct name for the initializer macro
for struct fb_ops.
Signed-off-by: Thomas Zimmermann
Fixes: 9037afde8b9d ("fbdev/acornfb: Use fbdev I/O helpers")
Cc: Thomas Zimmermann
Cc: Sam Ravnborg
Cc: Helge Deller
Cc: Javier Martinez Canillas
Cc: Arnd Bergmann
Cc: # v6.6+
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in virtual address space. Set the read/write,
draw and mmap callbacks to the correct implementation and avoid
implicit defaults. Also select the necessary helpers in Kconfig.
Fbdev drivers sometimes rely on
The cfag12864bfb driver operates on system memory. Mark the framebuffer
accordingly. Helpers operating on the framebuffer memory will test for
the presence of this flag.
Signed-off-by: Thomas Zimmermann
Cc: Miguel Ojeda
---
drivers/auxdisplay/cfag12864bfb.c | 1 +
1 file changed, 1
The au1200fb driver operates on DMA-able system memory. Mark the
framebuffer accordingly. Helpers operating on the framebuffer memory
will test for the presence of this flag.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/au1200fb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
The picolcd_fb driver operates on system memory. Mark the framebuffer
accordingly. Helpers operating on the framebuffer memory will test
for the presence of this flag.
Signed-off-by: Thomas Zimmermann
Cc: "Bruno Prémont"
Cc: Jiri Kosina
Cc: Benjamin Tissoires
Cc: linux-in...@vger.kernel.org
Convert the remaining fbdev drivers to use fbdev's helpers macros
for struct fb_ops. Then push the current default code for file-I/O
operations into a module and remove it as default. Each driver now
selects the helpers its needs for file I/O and drawing to its
framebuffer. If no helper has been
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in virtual address space. Set the read/write,
draw and mmap callbacks to the correct implementation and avoid
implicit defaults. Also select the necessary helpers in Kconfig.
Fbdev drivers sometimes rely on
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in DMA-able virtual address space. Set the
read/write, draw and mmap callbacks to the correct implementation
and avoid implicit defaults. Also select the necessary helpers in
Kconfig.
Fbdev drivers sometimes
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in I/O address space. This explictily sets
the read/write, draw and mmap callbacks to the correct default
implementation.
Fbdev drivers sometimes rely on the callbacks being NULL for a
default implementation
The driver uses deferred I/O. Select the correct helpers via
FB_SYSMEM_HELPERS_DEFERRED in the Kconfig file.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/Kconfig | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/video/fbdev/Kconfig
Only initialize mmap and draw helpers with macros; leave read/write
callbacks to driver implementations. Fixes the following warnings:
CC [M] drivers/video/fbdev/sm712fb.o
sm712fb.c:1355:25: warning: initialized field overwritten [-Woverride-init]
1355 | .fb_fillrect =
There is no need to call MMIO reset using VPU_37XX_BUTTRESS_VPU_IP_RESET
register. IP will be reset by FLR or by entering d0i3. Also IP reset
during power_up is not needed as the VPU is already in reset.
Removing MMIO reset improves stability as it a partial device reset
that is not safe in some
Hi,
On Tue, Nov 14, 2023 at 05:18:08PM +0100, Marco Pagani wrote:
> On 2023-11-10 15:41, Maxime Ripard wrote:
> > On Wed, Nov 08, 2023 at 02:42:03PM +0100, Marco Pagani wrote:
> >> This patch introduces an initial KUnit test suite for GEM objects
> >> backed by shmem buffers.
> >>
> >>
Hi Biju
On Wed, Nov 15, 2023 at 12:36:55PM +, Biju Das wrote:
> Hi Jacopo Mondi,
>
> Thanks for the feedback.
>
> > Subject: Re: [PATCH v12 3/4] drm: renesas: Add RZ/G2L DU Support
> >
> > Hi Biju
> >
> > the series does not apply on v6.3. What is the base for the series ?
> >
> > On Thu,
From: Dave Airlie
If we get back ENODEV don't fail load. There are nvidia devices
that don't have display blocks and the driver should work on those.
Fixes: 15740541e8f0 ("drm/nouveau/devinit/tu102-: prepare for GSP-RM")
Link: https://gitlab.freedesktop.org/drm/nouveau/-/issues/270
Am 14.11.23 um 21:07 schrieb Mario Limonciello:
pci_is_thunderbolt_attached() looks at the hierarchy of the PCIe device
to determine if any bridge along the way has the is_thunderbolt bit set.
This bit will only be set when one of the devices in the hierarchy is an
Intel Thunderbolt device.
Hi Jacopo Mondi,
Thanks for the feedback.
> Subject: Re: [PATCH v12 3/4] drm: renesas: Add RZ/G2L DU Support
>
> Hi Biju
>
> the series does not apply on v6.3. What is the base for the series ?
>
> On Thu, Nov 02, 2023 at 03:07:43PM +, Biju Das wrote:
> > The LCD controller is composed
Hi Christian,
CC virtgpu
On Tue, Nov 14, 2023 at 10:45 AM Christian Zigotzky
wrote:
> On 13 November 2023 at 01:48 pm, Geert Uytterhoeven wrote:
> > I can confirm there is no graphics output with m68k/virt, and
Before the error message you reported:
virtio-mmio virtio-mmio.125: [drm]
On Wed, Nov 15, 2023 at 09:33:28AM +0100, Geert Uytterhoeven wrote:
> Hi Christian,
>
> CC virtgpu
>
> On Tue, Nov 14, 2023 at 10:45 AM Christian Zigotzky
> wrote:
> > On 13 November 2023 at 01:48 pm, Geert Uytterhoeven wrote:
> > > I can confirm there is no graphics output with m68k/virt, and
On 11/15/2023 7:26 AM, Chris Morgan wrote:
From: Chris Morgan
Stop calling drm_connector_set_orientation_from_panel() as its now
called by the panel bridge directly when it is initialized.
Signed-off-by: Chris Morgan
Reviewed-by: Jessica Zhang
---
On 11/9/2023 1:50 PM, Chris Morgan wrote:
From: Chris Morgan
Refactor the driver to add support for the powkiddy,rk2023-panel
panel. This panel is extremely similar to the rg353p-panel but
requires a smaller vertical back porch and isn't as tolerant of
higher speeds. Note that while all of
Most of the things in this patch should go in the MTK specific
implementation (except for the secure_heap_init changes). Especially
the RESERVEDMEM_OF_DECLARE.
On Sat, Nov 11, 2023 at 3:18 AM Yong Wu wrote:
>
> Create a new MediaTek CMA heap from the CMA reserved buffer.
>
> In this heap, When
From: Chris Morgan
Add support for the Powkiddy RK2023. The Powkiddy RK2023 is a handheld
gaming device with a 3.5 inch screen powered by the Rockchip RK3566
SoC. The device looks physically different from the Powkiddy RGB30,
but is functionally identical except for the panel.
Signed-off-by:
From: Chris Morgan
The Powkiddy RGB30 device is similar to the Anbernic RGxx3 series,
however there are several differences which require deleting nodes in
order to properly define the hardware. This was deemed unacceptable
for the RK2023, so instead create a common include file for the
Powkiddy
From: Chris Morgan
Improve the panel's ability to restore from suspend by holding the
panel in suspend after unprepare.
Fixes: b1d39f0f4264 ("drm/panel: Add NewVision NV3051D MIPI-DSI LCD panel")
Signed-off-by: Chris Morgan
---
drivers/gpu/drm/panel/panel-newvision-nv3051d.c | 2 ++
1 file
From: Chris Morgan
Update the NewVision NV3051D compatible strings by adding a new panel,
the powkiddy,rk2023-panel, and removing another entry, the
anbernic,rg353v-panel.
The rk2023-panel is similar to the rg353p-panel but has slightly
different timings so it needs a new string.
The
From: Chris Morgan
Refactor the driver to add support for the powkiddy,rk2023-panel
panel. This panel is extremely similar to the rg353p-panel but
requires a smaller vertical back porch and isn't as tolerant of
higher speeds. Note that while all of these panels are identical in
size (70x57) it
From: Chris Morgan
Add support for the Powkiddy RK2023, which is extremely similar to
existing Powkiddy RGB30 device.
Changes since V2:
- Split "hold panel in reset" to a separate patch for the NV3051D.
- Changed replaced common include to a new Powkiddy specific include
to better reflect
From: Chris Morgan
The Powkiddy RK2023 is a handheld gaming device made by Powkiddy and
powered by the Rockchip RK3566 SoC. Group the Powkiddy RK3566 based
devices together as they are both extremely similar.
Signed-off-by: Chris Morgan
Acked-by: Krzysztof Kozlowski
---
On 11/15/2023 4:17 PM, Chris Morgan wrote:
From: Chris Morgan
Refactor the driver to add support for the powkiddy,rk2023-panel
panel. This panel is extremely similar to the rg353p-panel but
requires a smaller vertical back porch and isn't as tolerant of
higher speeds. Note that while all of
On 11/15/2023 4:17 PM, Chris Morgan wrote:
From: Chris Morgan
Improve the panel's ability to restore from suspend by holding the
panel in suspend after unprepare.
Fixes: b1d39f0f4264 ("drm/panel: Add NewVision NV3051D MIPI-DSI LCD panel")
Signed-off-by: Chris Morgan
Thanks!
The main goal is for secure video playback, and to also enable other
potential uses of this in the future. The 'secure dma-heap' will be
used to allocate dma_buf objects that reference memory in the secure
world that is inaccessible/unmappable by the non-secure (i.e.
kernel/userspace) world. That
On 11/15/2023 7:26 AM, Chris Morgan wrote:
From: Chris Morgan
Drop the prepare/unprepare logic, as this is now tracked elsewhere.
Additionally, the driver shutdown is also duplicate as it calls
drm_unprepare and drm_disable which are called anyway when
associated drivers are
On Sat, Nov 11, 2023 at 3:16 AM Yong Wu wrote:
>
> Initialize a secure heap. Currently just add a null heap, Prepare for
> the later patches.
>
> Signed-off-by: Yong Wu
> ---
> drivers/dma-buf/heaps/Kconfig | 7 +++
> drivers/dma-buf/heaps/Makefile | 1 +
>
On Sat, Nov 11, 2023 at 3:17 AM Yong Wu wrote:
>
> Add TEE service call. In the case of MediaTek, secure memory management is
> located within the TEE. The kernel just needs to tell TEE what size it
> needs and the TEE will return a "security handle" to kernel.
>
> To be consistent with the cma
You should drop this patch completely.
On Sat, Nov 11, 2023 at 3:18 AM Yong Wu wrote:
>
> Add a normal CMA heap which use the standard cma allocate.
>
> Signed-off-by: Yong Wu
> ---
> Hi Vijay and Jaskaran,
>
> For this heap,
> 1) It uses sec_heap_buf_ops currently. I guess we cann't use the
>
On 11/9/2023 4:54 PM, john.c.harri...@intel.com wrote:
From: John Harrison
If a context is blocked, unblocked and subitted repeatedly in rapid
succession, the driver can end up trying to enable the context while
the previous enable request is still in flight. This can lead to much
confusion
On 11/15/2023 7:26 AM, Chris Morgan wrote:
From: Chris Morgan
The comments at the top of the driver state the panel size incorrectly
as 5.5" instead of 3.5".
Signed-off-by: Chris Morgan
Reviewed-by: Jessica Zhang
---
drivers/gpu/drm/panel/panel-elida-kd35t133.c | 2 +-
1 file
On 11/15/2023 2:44 PM, Rob Clark wrote:
From: Rob Clark
The dpu devcore's are already associated with the dpu device. So we
should associate the gpu devcore's with the gpu device, for easier
classification.
Signed-off-by: Rob Clark
Reviewed-by: Abhinav Kumar
Everything in this patch set should move into the MTK specific
implementation I suggested in patch 1 (secure_heap_mtk.c)
On Sat, Nov 11, 2023 at 3:17 AM Yong Wu wrote:
>
> The TEE probe later than dma-buf heap, and PROBE_DEDER doesn't work
> here since this is not a platform driver, therefore
On 11/15/2023 11:04, Mario Limonciello wrote:
On 11/14/2023 21:23, Lazar, Lijo wrote:
On 11/15/2023 1:37 AM, Mario Limonciello wrote:
The USB4 spec specifies that PCIe ports that are used for tunneling
PCIe traffic over USB4 fabric will be hardcoded to advertise 2.5GT/s and
behave as a PCIe
On 11/15/2023 7:26 AM, Chris Morgan wrote:
From: Chris Morgan
For devices like the Anbernic RG351M and RG351P the panel is wired to
an always on regulator. When the device suspends and wakes up, there
are some slight artifacts on the screen that go away over time. If
instead we hold the
Le mer. 15 nov. 2023 à 15:40, a écrit :
>
> From: Dave Airlie
>
> If we get back ENODEV don't fail load. There are nvidia devices
> that don't have display blocks and the driver should work on those.
>
> Fixes: 15740541e8f0 ("drm/nouveau/devinit/tu102-: prepare for GSP-RM")
> Link:
From: Rob Clark
The dpu devcore's are already associated with the dpu device. So we
should associate the gpu devcore's with the gpu device, for easier
classification.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gpu.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff
On Mon, Nov 06, 2023 at 02:58:12PM +0100, mrip...@kernel.org wrote:
> > But a similar thing is happening here where we have so many bogus
> > warnings that we missed a real bug.
>
> IIRC, there was a similar discussion for lockdep issues. IMO, any
> (unintended) warning should trigger a test
On Sat, Nov 11, 2023 at 3:16 AM Yong Wu wrote:
>
> For the secure memory, there are two steps:
> a) Allocate buffers in kernel side;
> b) Secure that buffer.
> Different heaps may have different buffer allocation methods and
> different memory protection methods. Here abstract the memory
>
May I suggest the following for the device tree binding? (I'm not very
familiar w/ device trees, so apologies for any oversights, but trying
to process the feedback here and help move Mediatek along). This
should align with my other suggestions for having an MTK specific
portion to their secure
1 - 100 of 171 matches
Mail list logo
