On Thu, Nov 16, 2023 at 03:24:54PM +0800, Andy Yan wrote:
> > case ROCKCHIP_VOP2_EP_HDMI0:
> > case ROCKCHIP_VOP2_EP_HDMI1:
> > ...
> > }
> >
> > would look a bit better overall.
> >
> > > + /*
> > > + * K = 2: dclk_core = if_pixclk_rate > if_dclk_rate
> > >
Let dev_err_probe handle the -EPROBE_DEFER case and also add an entry to
/sys/kernel/debug/devices_deferred when deferred.
Signed-off-by: Alexander Stein
---
drivers/video/backlight/pwm_bl.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/video/backlight/pwm_bl.c
Zack Rusin writes:
Hello Zack,
> On Wed, 2023-11-15 at 14:15 +0100, Javier Martinez Canillas wrote:
[...]
>>
>> Changes in v2:
>> - Add a struct drm_plane_state .ignore_damage_clips to set in the plane's
>> .atomic_check, instead of having different helpers (Thomas Zimmermann).
>> - Set
Hi Sascha:
Thanks for your review.
Let's confirm your remarks in function vop2_calc_cru_cfg fist,
others are small nits I think can be easy to address.
On 11/15/23 17:08, Sascha Hauer wrote:
Hi Andy,
Thanks for your patches, some remarks inline.
On Tue, Nov 14, 2023 at 07:28:55PM +0800,
On 11/16/2023 2:39 AM, Mario Limonciello wrote:
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
On Wed, 2023-11-15 at 14:15 +0100, Javier Martinez Canillas wrote:
> 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,
Hi Biju,
Thank you for the patch.
On Wed, Nov 15, 2023 at 03:09:32PM +, Biju Das wrote:
> The rcar_du_vsps_init() doesn't free the np allocated by
> of_parse_phandle_with_fixed_args() for the non-error case.
>
> Fix memory leak for the non-error case.
Good catch.
> Fixes: 3e81374e2014
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!
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
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
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 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
---
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
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
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
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
>
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
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
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
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 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
>
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 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
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 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
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
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:
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
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/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
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/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 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 15.11.2023 11:00, Tvrtko Ursulin wrote:
>
> 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
On Mon, Nov 13, 2023 at 2:53 AM Javier Martinez Canillas
wrote:
>
> Some DT platforms use EFI to boot and in this case the EFI Boot Services
> may register a EFI_GRAPHICS_OUTPUT_PROTOCOL handle, that will later be
> queried by the Linux EFI stub to fill the global struct screen_info data.
>
> The
On Wed, Nov 15, 2023 at 04:29:01PM +0100, Flavio Suligoi wrote:
> Signed-off-by: Flavio Suligoi
You omitted my ack that I gave on the previous version.
Acked-by: Conor Dooley
Cheers,
Conor.
signature.asc
Description: PGP signature
Hi Vinay,
> -Original Message-
> From: dri-devel On Behalf Of
> Belgaumkar, Vinay
> Sent: Thursday, November 9, 2023 5:02 PM
> To: Ville Syrjälä
> Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Read a shadowed mmio
6.6-stable review patch. If anyone has any objections, please let me know.
--
From: Randy Dunlap
[ Upstream commit 96413b355a49fd684430a230479bd231d977894f ]
Three DRM bridge drivers select GENERIC_PHY_MIPI_DPHY when GENERIC_PHY
might not be set. This causes Kconfig warnings
On Wed, 15 Nov 2023 at 20:46, Dipam Turkar wrote:
>
> They are not outdated, my bad. I went through the locks' code and saw that
> they have been updated. But they are probably not necessary here as most of
> the drivers do not use any form of locking in their implementations. The
> generic
6.5-stable review patch. If anyone has any objections, please let me know.
--
From: Randy Dunlap
[ Upstream commit 96413b355a49fd684430a230479bd231d977894f ]
Three DRM bridge drivers select GENERIC_PHY_MIPI_DPHY when GENERIC_PHY
might not be set. This causes Kconfig warnings
On 11/15/2023 3:02 AM, Tvrtko Ursulin wrote:
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
They are not outdated, my bad. I went through the locks' code and saw that
they have been updated. But they are probably not necessary here as most of
the drivers do not use any form of locking in their implementations. The
generic implementations drm_gem_dumb_map_offset() and
They are not outdated, my bad. I went through the locks' code and saw that
they have been updated. But they are probably not necessary here as most of
the drivers do not use any form of locking in their implementations. The
generic implementations drm_gem_dumb_map_offset() and
On 10/30/2023 4:23 PM, Bjorn Andersson wrote:
During USB transfers on the SC8280XP __arm_smmu_tlb_sync() is seen to
typically take 1-2ms to complete. As expected this results in poor
performance, something that has been mitigated by proposing running the
iommu in non-strict mode (boot with
On 2023-10-05 13:15, Melissa Wen wrote:
> Add AMD pre-defined transfer function property to default DRM CRTC gamma
> to convert to wire encoding with or without a user gamma LUT. There is
> no post-blending regamma ROM for pre-defined TF. When setting Gamma TF
> (!= Identity) and LUT at the
On 2023-10-05 13:15, Melissa Wen wrote:
> From: Joshua Ashton
>
> Blend 1D LUT or a pre-defined transfer function (TF) can be set to
> linearize content before blending, so that it's positioned just before
> blending planes in the AMD color mgmt pipeline, and after 3D LUT
> (non-linear
On 2023-10-05 13:15, Melissa Wen wrote:
> On AMD HW, 3D LUT always assumes a preceding shaper 1D LUT used for
> delinearizing and/or normalizing the color space before applying a 3D
> LUT. Add pre-defined transfer function to enable delinearizing content
> with or without shaper LUT, where AMD
On 2023-10-05 13:15, Melissa Wen wrote:
> From: Joshua Ashton
>
> Multiplier to 'gain' the plane. When PQ is decoded using the fixed func
> transfer function to the internal FP16 fb, 1.0 -> 80 nits (on AMD at
> least) When sRGB is decoded, 1.0 -> 1.0. Therefore, 1.0 multiplier = 80
> nits
On 2023-10-05 13:15, Melissa Wen wrote:
> Brief documentation about pre-defined transfer function usage on AMD
> display driver and standardized EOTFs and inverse EOTFs.
>
> v3:
> - Document BT709 OETF (Pekka)
> - Fix description of sRGB and pure power funcs (Pekka)
>
> v4:
> - Add
On 2023-10-05 13:15, Melissa Wen wrote:
> Instead of relying on color block names to get the transfer function
> intention regarding encoding pixel's luminance, define supported
> Electro-Optical Transfer Functions (EOTFs) and inverse EOTFs, that
> includes pure gamma or standardized transfer
Add my self as maintainer for RZ DU drivers.
While at it, update the entries for common parts, rcar-du and shmobile.
Signed-off-by: Biju Das
Reviewed-by: Laurent Pinchart
---
v12->v13:
* No change.
v11->v12:
* No change.
v10->v11:
* No change.
v9->v10:
* No change.
v8->v9:
* Added Rb tag
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 RPFs to support the blending of two picture layers and
raster operations (ROPs).
The DU
Document DU found in RZ/V2L SoC. The DU block is identical to RZ/G2L
SoC and therefore use RZ/G2L fallback to avoid any driver changes.
Signed-off-by: Biju Das
Reviewed-by: Rob Herring
Reviewed-by: Laurent Pinchart
Reviewed-by: Geert Uytterhoeven
---
v12->v13:
* No change.
v11->v12:
* No
The RZ/G2L LCD controller is composed of Frame Compression Processor
(FCPVD), Video Signal Processor (VSPD), and Display Unit (DU).
The DU module supports the following hardware features
− Display Parallel Interface (DPI) and MIPI LINK Video Interface
− Display timing master
− Generates video
This path series aims to add support for RZ/G2L DU DRM driver.
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.
The output from
On 11/15/2023 12:06 AM, Johan Hovold wrote:
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
On 2023-11-14 14:00:19, Jonathan Marek wrote:
> On 11/14/23 1:28 PM, Marijn Suijten wrote:
> > On what hardware have you been testing this? Dmitry and I have a stack of
> > patches to resolve support for Active CTL programming on newer hardware (DPU
> > 5.0+ IIRC), where a single CTL is
On 11/15/23 18:02, Danilo Krummrich wrote:
On 11/15/23 17:04, Thomas Hellström wrote:
Hi, Danilo,
On Wed, 2023-11-15 at 16:11 +0100, Danilo Krummrich wrote:
On Wed, Nov 15, 2023 at 01:49:37PM +0100, Thomas Hellström wrote:
Add the first version of the VM_BIND locking document which is
Hi Tvrtko,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-intel/for-linux-next-fixes]
[also build test WARNING on drm-tip/drm-tip drm/drm-next
drm-exynos/exynos-drm-next drm-misc/drm-misc-next linus/master v6.7-rc1
next-20231115]
[cannot apply to drm
On 11/15/2023 04:40, Mika Westerberg wrote:
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
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 Gen1 device. The actual performance of these
On 11/15/23 17:04, Thomas Hellström wrote:
Hi, Danilo,
On Wed, 2023-11-15 at 16:11 +0100, Danilo Krummrich wrote:
On Wed, Nov 15, 2023 at 01:49:37PM +0100, Thomas Hellström wrote:
Add the first version of the VM_BIND locking document which is
intended to be part of the xe driver upstreaming
From: Dani Liberman
Failure to map is considered a non-trivial error and we need to notify
the user about it.
Signed-off-by: Dani Liberman
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/common/memory.c | 7 ---
1 file changed, 4 insertions(+), 3
From: Tomer Tayar
hl_device_cond_reset() might be called with the hard reset flag unset,
because a compute reset upon device release as part of a graceful reset
is valid.
If the conditions for graceful reset are not met, hl_device_reset() will
be called for an immediate reset. In this case a
From: Dani Liberman
Module ID exposes the physical location of the device in the server,
from the pov of the devices in regard to how they are connected by
internal fabric.
This information is already exposed in our INFO ioctl, but there are
utilities and scripts running in data-center which
From: Tomer Tayar
Upon a QM error, the address/size from both the CQ and the ARC_CQ are
printed, although the instruction that led to the error was received
from only one of them.
Moreover, in case of a QM undefined opcode, only one of these
address/size sets will be captured based on the value
From: Dafna Hirschfeld
currently the undefined opcode event bit in set only for lower cp and
only if 'write_enable' is true. It should be set anyway and for all
streams in order to report that event to userspace.
Signed-off-by: Dafna Hirschfeld
Reviewed-by: Oded Gabbay
Signed-off-by: Oded
From: Ofir Bitton
The print was added long back for a specific debug and can
now be removed.
Signed-off-by: Ofir Bitton
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/common/hwmon.c | 4
1 file changed, 4 deletions(-)
diff --git
From: Farah Kassabri
Stop rescheduling another heartbeat check when EQ heartbeat check fails
as it generates confusing logs in dmesg that the heartbeat fails.
Signed-off-by: Farah Kassabri
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/common/device.c | 14
Gaudi2 with PCI revision ID with the value of '3' represents Gaudi2C
device and should be detected and initialized as Gaudi2.
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/common/device.c | 3 +++
drivers/accel/habanalabs/common/habanalabs.h | 2 ++
From: Farah Kassabri
Add error log when no eq event is received from FW,
to cover a scenario when FW is stuck for some reason.
In such case driver will not receive neither the eq error interrupt
or the eq heartbeat event, and will just initiate a reset without
indication in the dmesg about the
From: Tomer Tayar
When a PCIe AXI drain event happens, it is possible that the driver
cannot access the device through PCIe, and therefore cannot send a
hard-reset request to FW.
Starting from FW version 1.13, FW will initiate a hard-reset in such
a case without waiting for a reset request from
Hi Brenton,
On 11/15/23 16:52, Brenton Simpson wrote:
> Yes, thanks!
>
> That's the email attached to my public git work, so it should be the
> one here as well.
Ok, I've pushed this to drm-misc-fixes now, thank you for the patch.
> Sorry for the hassle. Very new to sending PRs over email,
Hi, Danilo,
On Wed, 2023-11-15 at 16:11 +0100, Danilo Krummrich wrote:
> On Wed, Nov 15, 2023 at 01:49:37PM +0100, Thomas Hellström wrote:
> > Add the first version of the VM_BIND locking document which is
> > intended to be part of the xe driver upstreaming agreement.
> >
> > The document
On Wed, 15 Nov 2023 at 16:51, Maxime Ripard wrote:
>
> On Sat, 11 Nov 2023 04:08:26 +0800, David Gow wrote:
> > KUnit's deferred action API accepts a void(*)(void *) function pointer
> > which is called when the test is exited. However, we very frequently
> > want to use existing functions which
On Wed, 15 Nov 2023 at 15:30, Keith Zhao wrote:
>
>
>
> On 2023/11/14 18:59, Dmitry Baryshkov wrote:
> > On Tue, 14 Nov 2023 at 12:42, Keith Zhao
> > wrote:
> >>
> >>
> >>
> >> On 2023/10/26 3:28, Dmitry Baryshkov wrote:
> >> > On 25/10/2023 13:39, Keith Zhao wrote:
> >> >> add 2 crtcs and 8
Yes, thanks!
That's the email attached to my public git work, so it should be the
one here as well.
Sorry for the hassle. Very new to sending PRs over email, and still
working through the kinks.
On Wed, Nov 15, 2023 at 7:51 AM Hans de Goede wrote:
>
> Hi,
>
> On 11/15/23 16:48, Brenton
On Sat, 11 Nov 2023 04:08:26 +0800, David Gow wrote:
> KUnit's deferred action API accepts a void(*)(void *) function pointer
> which is called when the test is exited. However, we very frequently
> want to use existing functions which accept a single pointer, but which
> may not be of type void*.
Hi,
On 11/15/23 16:48, Brenton Simpson wrote:
> Resending from the email address linked to my GitHub account.
Ok, this doesn't really help. I'll just fix-up the author
field of the original patch.
Do understand correctly that both the author and the Signed-off-by
should be set to:
Brenton
Hi David,
On Sat, Nov 11, 2023 at 04:08:27AM +0800, David Gow wrote:
> In order to pass functions to kunit_add_action(), they need to be of the
> kunit_action_t type. While casting the function pointer can work, it
> will break control-flow integrity.
>
> drm_kunit_helpers already defines
Arg - the special characters got mangled. One last time.
-- >8 --
The Legion Go has a 2560x1600 portrait screen, with the native "up"
facing the right controller (90° CW from the rest of the device).
Signed-off-by: Brenton Simpson
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
Resending from the email address linked to my GitHub account.
-- >8 --
The Legion Go has a 2560x1600 portrait screen, with the native "up" facing =
the right controller (90=C2=B0 CW from the rest of the device).
Signed-off-by: Brenton Simpson
---
drivers/gpu/drm/drm_panel_orientation_quirks.c
The Monolithic Power (MPS) MP3309C is a WLED step-up converter, featuring a
programmable switching frequency to optimize efficiency.
The brightness can be controlled either by I2C commands (called "analog"
mode) or by a PWM input signal (PWM mode).
This driver supports both modes.
For DT
This patchset (rebased on v6.7-rc1 kernel version):
- updates the mps,mp3309c.yaml dt bindings file:
- Documentation/devicetree/bindings/leds/backlight/mps,mp3309c.yaml
- adds the related device driver to support the MPS MP3309C backlight chip.
Note: about the first point, the
The two properties:
- max-brightness
- default brightness
are not really required, so they can be removed from the "required"
section.
The "max-brightness" is no longer used in the current version
of the driver (it was used only in the first version).
The "default-brightness", if omitted in the
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 shutdown/removed.
Signed-off-by: Chris Morgan
---
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 panel in reset status after it is unprepared,
this
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
---
drivers/gpu/drm/panel/panel-elida-kd35t133.c | 5 -
1 file changed, 5 deletions(-)
diff --git
From: Chris Morgan
Fix a few bugs and clean up no longer needed code on the Elida KD35T133
DSI panel, as used in devices such as the Odroid Go Advance and the
Anbernic RG351M.
Chris Morgan (4):
drm/panel-elida-kd35t133: trival: update panel size from 5.5 to 3.5
drm/panel-elida-kd35t133:
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
---
drivers/gpu/drm/panel/panel-elida-kd35t133.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Hi David,
On Sat, Nov 11, 2023 at 04:08:26AM +0800, David Gow wrote:
> KUnit's deferred action API accepts a void(*)(void *) function pointer
> which is called when the test is exited. However, we very frequently
> want to use existing functions which accept a single pointer, but which
> may not
On Wed, Nov 15, 2023 at 01:49:37PM +0100, Thomas Hellström wrote:
> 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
The rcar_du_vsps_init() doesn't free the np allocated by
of_parse_phandle_with_fixed_args() for the non-error case.
Fix memory leak for the non-error case.
Fixes: 3e81374e2014 ("drm: rcar-du: Support multiple sources from the same VSP")
Signed-off-by: Biju Das
---
On Wed, 15 Nov 2023 at 16:30, Dipam Turkar wrote:
>
> 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
On 2023/10/25 21:57, Maxime Ripard wrote:
> On Wed, Oct 25, 2023 at 06:39:56PM +0800, Keith Zhao wrote:
>> +static struct drm_crtc_state *
>> +vs_crtc_atomic_duplicate_state(struct drm_crtc *crtc)
>> +{
>> +struct vs_crtc_state *ori_state;
>> +struct vs_crtc_state *state;
>> +
>> +
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 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,
> ---
>
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
1 - 100 of 171 matches
Mail list logo
