On Thu, Feb 08, 2024 at 07:13:18PM +0100, Erick Archer wrote:
> The "struct i915_syncmap" uses a dynamically sized set of trailing
> elements. It can use an "u32" array or a "struct i915_syncmap *"
> array.
>
> So, use the preferred way in the kernel declaring flexible arrays [1].
> Because there
Verify during drm_atomic_bridge_check() that the lane assignment set in
a bridge's atomic_check() callback is going to be satisfied by the
previous bridge. If the next bridge is requiring something besides the
default 1:1 lane assignment on its input then there must be an output
lane assignment on
Add support to the DRM atomic logic to support lane remapping between
bridges, encoders and connectors. Typically lane mapping is handled
statically in firmware, e.g. on DT we use the data-lanes property to
assign lanes when connecting display bridges. Lane assignment is dynamic
with USB-C
This series adds support for fully describing the USB/DP topology on
ChromeOS Trogdor devices in DT. Trogdor devices have a single DP phy in
the AP that is muxed to one of two usb type-c connectors depending on
which port asserts HPD first to the EC. We'd like to know which port is
connected to an
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 445a555e0623387fa9b94e68e61681717e70200a Add linux-next specific
files for 20240209
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202402091752.dgmpja49-...@intel.com
https
There is no reason to prohibit sh7760fb from being built as a
loadable module as suggested by Geert, so change the config symbol
from bool to tristate to allow that and change the FB dependency as
needed.
Fixes: f75f71b2c418 ("fbdev/sh7760fb: Depend on FB=y")
Suggested-by: Geert Uytterhoeven
On Sat, Feb 10, 2024 at 01:24:43AM +0100, Ao Zhong wrote:
> This patch addresses an issue with the Anbernic RG353V-V2 panel
> initialization that was caused by incorrect parameter. The correct
> initialization sequence was derived by referencing the JELOS (Just
> Enough Linux OS) BSP kernel's
YUV420 format is supported only in the VSC SDP packet and not through
MSA. Hence add an API which indicates the sink support which can be used
by the rest of the DP programming.
Changes in v2:
- Move VSC SDP support check API from dp_panel.c to
drm_dp_helper.c
Signed-off-by:
Change relevant DP controller related programming for YUV420 cases.
Program the configuration control register to indicate YUV420.
Changes in v2:
- Create a new patch only for configuration control programming
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/dp/dp_ctrl.c | 3 +++
Adjust the encoder format programming in the case of video mode for DP
to accommodate CDM related changes.
Changes in v2:
- Move timing engine programming to a separate patch from this
one
- Move update_pending_flush_periph() invocation completely to
this patch
Modify the output width and height parameters of hw_cdm to utilize the
physical encoder's data instead of obtaining the information from the
framebuffer. CDM is to be set up to utilize the actual output data since
at CDM setup, there is no difference between the two sources.
Changes in v2:
The Chroma Down Sampling (CDM) block is a hardware component in the DPU
pipeline that includes a CSC block capable of converting RGB input from
the DPU to YUV data.
This block can be used with either HDMI, DP, or writeback interfaces.
This series adds support for the CDM block to be used with DP
From: Kuogee Hsieh
Introduce a peripheral flushing mechanism to decouple peripheral
metadata flushing from timing engine related flush.
Changes in v2:
- Fixed some misalignment issues
Signed-off-by: Kuogee Hsieh
Signed-off-by: Paloma Arellano
---
Add support to pack and send the VSC SDP packet for DP. This therefore
allows the transmision of format information to the sinks which is
needed for YUV420 support over DP.
Changes in v2:
- Rename GENERIC0_SDPSIZE macro to GENERIC0_SDPSIZE_VALID
- Remove dp_sdp from the dp_catalog
All the components of YUV420 over DP are added. Therefore, let's mark the
connector property as true for DP connector when the DP type is not eDP
and when there is a CDM block available.
Changes in v2:
- Check for if dp_catalog has a CDM block available instead of
checking if
Wide bus is not supported when the mode is YUV420 in DP. In preparation
for changing the DPU programming to reflect this, the value and
assignment location of wide_bus_en for the DP submodules must be
changed. Move it from boot time in dp_init_sub_modules() to run time in
dp_display_mode_set.
Adjust the encoder timing engine setup programming in the case of video
mode for YUV420 over DP to accommodate CDM.
Changes in v2:
- Move timing engine programming to this patch
Signed-off-by: Paloma Arellano
---
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 16
1
Reserve CDM blocks for DP if the mode format is YUV420. Currently this
reservation only works for writeback and DP if the format is YUV420. But
this can be easily extented to other YUV formats for DP.
Changes in v2:
- Minor code simplification
Signed-off-by: Paloma Arellano
---
DP controller can be setup to operate in either SDP update flush mode or
peripheral flush mode based on the DP controller hardware version.
Starting in DP v1.2, the hardware documents require the use of
peripheral flush mode for SDP packets such as PPS OR VSC SDP packets.
In-line with this
Generalize dpu_encoder_helper_phys_setup_cdm to be compatible with DP.
Changes in v2:
- Minor formatting changes
- Move the modification of the dimesions for CDM setup to a new
patch
Signed-off-by: Paloma Arellano
---
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 4
Parity calculation is necessary for VSC SDP implementation. Therefore
create new files dp_utils.c and dp_utils.h and move the parity
calculating functions here. This ensures that they are usable by SDP
programming in both dp_catalog.c and dp_audio.c
Changes in v2:
- Create new files
In the DP driver, check if VSC SDP is supported and propagate this value
to dp_panel. In dp_display's dp_mode, the out_fmt_is_yuv_420 parameter
must also utilize this value since YUV420 is only allowed when VSC SDP
is supported.
Changes in v2:
- Move DP programming when VSC SDP is
Change all relevant DP controller related programming for YUV420 cases.
Namely, change the pixel clock math to consider YUV420 and modify the
MVID programming to consider YUV420.
Changes in v2:
- Move configuration control progamming to a different commit
- Slight code
Rename wide_bus_en to wide_bus_supported in dp_display_private to
correctly establish that the parameter is referencing if wide bus is
supported instead of enabled.
Signed-off-by: Paloma Arellano
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_display.c | 42
Widebus enablement is decided by the interfaces based on their specific
checks and that already happens with DSI/DP specific helpers. Let's
invoke these helpers from dpu_encoder_is_widebus_enabled() to make it
cleaner overall.
Signed-off-by: Paloma Arellano
Reviewed-by: Dmitry Baryshkov
---
Move dpu_encoder_helper_phys_setup_cdm to dpu_encoder in preparation for
implementing YUV420 over DP, which requires CDM compatibility.
Changes in v2:
- Slightly change the wording of the commit text to make clear
that YUV over DP requires CDM
Signed-off-by: Paloma Arellano
CDM block supports formats other than H1V2 for DP. Since we are now
adding support for CDM over DP, relax the checks to allow all other
formats for DP other than H1V2.
Changes in v2:
- Add fixes tag
- Move patch to top of series
Fixes: 0afac0ba6024 ("drm/msm/dpu: add dpu_hw_cdm
This patch addresses an issue with the Anbernic RG353V-V2 panel
initialization that was caused by incorrect parameter. The correct
initialization sequence was derived by referencing the JELOS (Just
Enough Linux OS) BSP kernel's device tree for the V2 panel, which is
identified by the ID "38 21".
On Thu, Feb 08, 2024 at 05:34:57PM -0800, Jessica Zhang wrote:
> On 2/8/2024 4:16 PM, Richard Acayan wrote:
>> The S6E3FA7 display controller is enabled in every Pixel 3a (non-XL)
>> variant. Add the driver for it, generated by
>> linux-mdss-dsi-panel-driver-generator.
>>
>> There are other
On 12/2/2023 4:05 PM, Dmitry Baryshkov wrote:
Since the commit b962a12050a3 ("drm/atomic: integrate modeset lock with
private objects") the DRM framework no longer requires the external
lock for private objects. Drop the lock, letting the DRM to manage
private object locking.
Signed-off-by:
This patch addresses an issue with the Anbernic RG353V-V2 panel
initialization that was caused by incorrect parameter. The correct
initialization sequence was derived by referencing the JELOS (Just
Enough Linux OS) BSP kernel's device tree for the V2 panel, which is
identified by the ID "38 21".
On 12/2/2023 4:05 PM, Dmitry Baryshkov wrote:
The Shared Memory Pool (SMP) state is a part of the MDP5's private
object state. Use existing infrastructure, atomic_print_state()
callback, to dump SMP state (which also makes it included into
debugfs/dri/N/state). This allows us to drop the
On 12/2/2023 4:05 PM, Dmitry Baryshkov wrote:
Since the commit b962a12050a3 ("drm/atomic: integrate modeset lock with
private objects") the DRM framework no longer requires the external
lock for private objects. Drop the lock, letting the DRM to manage
private object locking.
Signed-off-by:
Hi Dave, Sima,
New stuff for 6.9.
The following changes since commit d7643fe6fb76edb1f2f1497bf5e8b8f4774b5129:
drm/amd/display: Avoid enum conversion warning (2024-01-15 18:35:07 -0500)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
Hello Chris Morgan, Guido Günther,
I will post a v2 patch. I will supplement the commit information and
attach the reference links I used when modifying the init sequence.
Ao Zhong
Am Fr., 9. Feb. 2024 um 22:35 Uhr schrieb Chris Morgan
:
>
> On Fri, Feb 09, 2024 at 11:08:22AM +0100, Guido
On 21.01.2024 20:41, Adam Skladowski wrote:
> Add node describing wireless connectivity subsystem.
>
> Signed-off-by: Adam Skladowski
> ---
> arch/arm64/boot/dts/qcom/msm8976.dtsi | 96 +++
> 1 file changed, 96 insertions(+)
>
> diff --git
On Fri, Feb 09, 2024 at 11:08:22AM +0100, Guido Günther wrote:
> Hi Ao,
>
> this doesn't say why that was changed but your cover letter
> has that information:
>
> > After correcting these parameters by referencing the
> > device tree in JELOS (which uses the BSP kernel for RK3566), the panel
>
On 21.01.2024 20:41, Adam Skladowski wrote:
> Add Adreno GPU node.
>
> Signed-off-by: Adam Skladowski
> ---
> arch/arm64/boot/dts/qcom/msm8976.dtsi | 66 +++
> 1 file changed, 66 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8976.dtsi
>
On 21.01.2024 20:41, Adam Skladowski wrote:
> Add MDSS nodes to support displays on MSM8976 SoC.
>
> Signed-off-by: Adam Skladowski
> ---
> arch/arm64/boot/dts/qcom/msm8976.dtsi | 268 +-
> 1 file changed, 264 insertions(+), 4 deletions(-)
>
> diff --git
On Fri, Feb 09, 2024 at 05:53:07PM +0100, Xaver Hugl wrote:
> Signed-off-by: Xaver Hugl
> ---
> drivers/gpu/drm/drm_connector.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index b0516505f7ae..01e13984629b
On Mon, Feb 05, 2024 at 10:39:38AM +0100, Maxime Ripard wrote:
> On Fri, Feb 02, 2024 at 06:37:52PM +0200, Ville Syrjälä wrote:
> > On Fri, Feb 02, 2024 at 04:59:30PM +0100, Maxime Ripard wrote:
> > > On Fri, Feb 02, 2024 at 05:40:47PM +0200, Ville Syrjälä wrote:
> > > > On Fri, Feb 02, 2024 at
On Fri, Feb 02, 2024 at 04:49:04PM +0100, Maxime Ripard wrote:
> Hi Sebastian,
>
> On Mon, Jan 15, 2024 at 03:33:08PM +0100, Sebastian Wick wrote:
> > > /**
> > > * DOC: HDMI connector properties
> > > *
> > > + * Broadcast RGB
> > > + * Indicates the RGB Quantization Range (Full vs
Hi
Am 09.02.24 um 06:15 schrieb Michael Ellerman:
Thomas Zimmermann writes:
Am 07.02.24 um 17:13 schrieb Randy Dunlap:
When VIDEO is not set, there is a build error. Fix that by selecting
VIDEO for PS3_PS3AV.
ERROR: modpost: ".video_get_options" [drivers/ps3/ps3av_mod.ko] undefined!
Fixes:
On 12/2/2023 4:05 PM, Dmitry Baryshkov wrote:
Add calls to finalise global state object and corresponding lock.
Fixes: de3916c70a24 ("drm/msm/dpu: Track resources in global state")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 8
1 file changed, 8
On Sat, Feb 10, 2024 at 12:06:58AM +0530, Arunpravin Paneer Selvam wrote:
> Hi Daniel,
>
> On 2/9/2024 11:34 PM, Daniel Vetter wrote:
> > On Fri, Feb 09, 2024 at 08:56:24PM +0530, Arunpravin Paneer Selvam wrote:
> > > Few users have observed display corruption when they boot
> > > the machine to
On Fri, 2 Feb 2024 at 10:06, Danilo Krummrich wrote:
>
> nouveau_abi16_ioctl_channel_alloc() and nouveau_cli_init() simply call
> their corresponding *_fini() counterpart. This can lead to
> nouveau_sched_fini() being called without struct nouveau_sched ever
> being initialized in the first
Create a benchmark for the VKMS driver. Use a KMS layout with deliberate
odd sizes to try to avoid alignment accidents and run it for FRAME_COUNT
frames flipping framebuffers in each plane.
This benchmark was suggested by Pekka Paalanen to better analyse
possible performance regression on the
On Fri, 9 Feb 2024 at 20:44, Abhinav Kumar wrote:
>
>
>
> On 2/8/2024 7:01 AM, Dmitry Baryshkov wrote:
> > Existing MDP5 devices have slightly different bindings. The main
> > register region is called `mdp_phys' instead of `mdp'. Also vbif
> > register regions are a part of the parent, MDSS
On Fri, Feb 09, 2024 at 09:34:13AM -0600, Mario Limonciello wrote:
> On 2/9/2024 05:07, Daniel Vetter wrote:
> > On Thu, Feb 08, 2024 at 11:57:11AM +0200, Jani Nikula wrote:
> > > On Wed, 07 Feb 2024, Mario Limonciello wrote:
> > > > Some manufacturers have intentionally put an EDID that differs
On Fri, Feb 09, 2024 at 06:41:32PM +0100, Danilo Krummrich wrote:
> On 2/6/24 15:03, Daniel Vetter wrote:
> > On Mon, Feb 05, 2024 at 11:00:04PM +0100, Danilo Krummrich wrote:
> > > On 2/5/24 22:08, Dave Airlie wrote:
> > > > On Tue, 6 Feb 2024 at 02:22, Danilo Krummrich wrote:
> > > > >
> > > >
The pull request you sent on Fri, 9 Feb 2024 14:28:39 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2024-02-09
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c76b766ec50d3d43e2dacea53a733b285f4b730d
Thank you!
--
Deet-doot-dot, I am a bot.
On 2/8/2024 7:01 AM, Dmitry Baryshkov wrote:
Existing MDP5 devices have slightly different bindings. The main
register region is called `mdp_phys' instead of `mdp'. Also vbif
register regions are a part of the parent, MDSS device. Add support for
handling this binding differences.
On 2/8/2024 7:01 AM, Dmitry Baryshkov wrote:
Older (mdp5) platforms do not use per-SoC compatible strings. Instead
they use a single compat entry 'qcom,mdss'. To facilitate migrating
these platforms to the DPU driver provide a way to generate the MDSS /
UBWC data at runtime, when the DPU
On 2/8/2024 7:20 AM, Dmitry Baryshkov wrote:
The single helper for both enable and disable cases is too complicated,
especially if we start adding more code to these helpers. Split it into
irq_enable and irq_disable cases.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
On 2/8/2024 7:20 AM, Dmitry Baryshkov wrote:
The atomic_mode_set() callback only sets the phys_enc's IRQ data. As the
INTF and WB are statically allocated to each encoder/phys_enc, drop the
atomic_mode_set callback and set the IRQs during encoder init.
For the CMD panel usecase some of IRQ
On 2/8/2024 7:20 AM, Dmitry Baryshkov wrote:
Follow the _dpu_encoder_irq_control() change and split the
_dpu_encoder_resource_control_helper() into enable and disable parts.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
Tested-by: Paloma Arellano
Hi Daniel,
On 2/9/2024 11:34 PM, Daniel Vetter wrote:
On Fri, Feb 09, 2024 at 08:56:24PM +0530, Arunpravin Paneer Selvam wrote:
Few users have observed display corruption when they boot
the machine to KDE Plasma or playing games. We have root
caused the problem that whenever alloc_range()
On 2/8/2024 7:20 AM, Dmitry Baryshkov wrote:
dpu_encoder_phys_wb is the only user of encoder's atomic_check callback.
Move corresponding checks to drm_writeback_connector's implementation
and drop the dpu_encoder_phys_wb_atomic_check() function.
Signed-off-by: Dmitry Baryshkov
Tested-by:
On 2/8/2024 7:20 AM, Dmitry Baryshkov wrote:
Writeback was the last user of dpu_encoder_phys_ops's atomic_check()
callback. As the code was moved to the dpu_writeback.c, the callback
becomes unused. Drop it now.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
Tested-by: Paloma
On 30/01/2024 12:03, Vignesh Raman wrote:
Enable CONFIG_DRM_ANALOGIX_ANX7625 in the arm64 defconfig to get
display driver probed on the mt8183-kukui-jacuzzi-juniper machine.
arch/arm64/configs/defconfig has CONFIG_DRM_ANALOGIX_ANX7625=m,
but drm-ci don't have initrd with modules, so add
On 30/01/2024 12:03, Vignesh Raman wrote:
For mediatek mt8173, the GPU driver is powervr and for mediatek
mt8183, the GPU driver is panfrost. So add support in drm-ci to
test panfrost and powervr GPU driver for mediatek SOCs and update
xfails. Powervr driver was merged in linux kernel, but
Applied. Thanks!
Alex
On Tue, Feb 6, 2024 at 11:51 AM Nikita Zhandarovich
wrote:
>
> Since 'adev->dm.dc' in amdgpu_dm_fini() might turn out to be NULL
> before the call to dc_enable_dmub_notifications(), check
> beforehand to ensure there will not be a possible NULL-ptr-deref
> there.
>
>
Applied. Thanks!
On Tue, Feb 6, 2024 at 11:48 AM Nikita Zhandarovich
wrote:
>
> Clean up a typo in pr_err() erroneously printing NI MC 'rdev->mc_fw->size'
> during SMC firmware load. Log 'rdev->smc_fw->size' instead.
>
> Found by Linux Verification Center (linuxtesting.org) with static
>
On Fri, Feb 09, 2024 at 08:56:24PM +0530, Arunpravin Paneer Selvam wrote:
> Few users have observed display corruption when they boot
> the machine to KDE Plasma or playing games. We have root
> caused the problem that whenever alloc_range() couldn't
> find the required memory blocks the function
On 01/02/2024 03:53, Vignesh Raman wrote:
Add job that runs igt on top of vkms.
Signed-off-by: Vignesh Raman
Acked-by: Jessica Zhang
Tested-by: Jessica Zhang
Acked-by: Maxime Ripard
Signed-off-by: Helen Koike
---
v2:
- do not mv modules to /lib/modules in the job definition, leave it
On 2/6/24 15:03, Daniel Vetter wrote:
On Mon, Feb 05, 2024 at 11:00:04PM +0100, Danilo Krummrich wrote:
On 2/5/24 22:08, Dave Airlie wrote:
On Tue, 6 Feb 2024 at 02:22, Danilo Krummrich wrote:
On 1/29/24 02:50, Dave Airlie wrote:
From: Dave Airlie
This should break the deadlock between
On 09/02/24 05:32, Pekka Paalanen wrote:
> On Thu, 8 Feb 2024 16:38:31 -0300
> Arthur Grillo wrote:
>
>> On 08/02/24 06:50, Pekka Paalanen wrote:
>>> On Wed, 07 Feb 2024 17:17:15 -0300
>>> Arthur Grillo wrote:
>>>
Create a benchmark for the VKMS driver. Use a KMS layout with
On 2/9/24 08:02, Dan Carpenter wrote:
These ANDs should be ORs or it will lead to a NULL dereference.
Fixes: fb5a3d037082 ("drm/amd/display: Add NULL test for 'timing generator' in
'dcn21_set_pipe()'")
Fixes: 886571d217d7 ("drm/amd/display: Fix 'panel_cntl' could be null in
Signed-off-by: Xaver Hugl
---
drivers/gpu/drm/drm_connector.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b0516505f7ae..01e13984629b 100644
--- a/drivers/gpu/drm/drm_connector.c
+++
On Wed, Feb 07, 2024 at 11:45:20PM -0800, Lucas De Marchi wrote:
> Implement fixed-type BIT() to help drivers add stricter checks, like was
> done for GENMASK.
>
> Signed-off-by: Lucas De Marchi
> Acked-by: Jani Nikula
So I get v1 from Jan.23 in my mailbox, and this one is v3. Did I miss
a v2?
On 22/01/2024 16:30, Boris Brezillon wrote:
> MMU and VM management is related and placed in the same source file.
>
> Page table updates are delegated to the io-pgtable-arm driver that's in
> the iommu subsystem.
>
> The VM management logic is based on drm_gpuva_mgr, and is assuming the
> VA
On Tue, Jan 23, 2024 at 09:02:04PM -0800, Lucas De Marchi wrote:
> Implement fixed-type BIT() to help drivers add stricter checks, like was
> done for GENMASK.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Yury Norov
> ---
> include/linux/bits.h | 9 +
> 1 file changed, 9
Hi Dave and Sima,
here's the PR for drm-misc-next for this week. There's nothing that
stands out: plenty of fixes, the usual round of newly supported panel
and bridge devices, and some changes to the internal interfaces.
Best regards
Thomas
drm-misc-next-2024-02-08:
drm-misc-next for v6.9:
Hi,
On 2024/2/9 23:15, Maxime Ripard wrote:
On Fri, Feb 09, 2024 at 12:02:48PM +0100, Daniel Vetter wrote:
On Thu, Feb 08, 2024 at 04:27:02PM +0100, Maxime Ripard wrote:
On Wed, Feb 07, 2024 at 10:35:49AM +0100, Daniel Vetter wrote:
On Wed, Feb 07, 2024 at 01:27:59AM +0800, Sui Jingfeng
On 09/02/2024 17:05, Krzysztof Kozlowski wrote:
> On 09/02/2024 16:02, dharm...@microchip.com wrote:
>> On 09/02/24 7:50 pm, Dharma B wrote:
>>> On 08/02/24 2:31 pm, Krzysztof Kozlowski wrote:
EXTERNAL EMAIL: Do not click links or open attachments unless you know
the content is safe
The pointer map is being initialized with a value that is never
read, it is being re-assigned later on in a for-loop. The
initialization is redundant and can be removed.
Cleans up clang scan build warning:
drivers/gpu/drm/i915/gvt/interrupt.c:346:28: warning: Value stored to
'map' during its
On 09/02/2024 16:02, dharm...@microchip.com wrote:
> On 09/02/24 7:50 pm, Dharma B wrote:
>> On 08/02/24 2:31 pm, Krzysztof Kozlowski wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know
>>> the content is safe
>>>
>>> On 07/02/2024 11:27, Dharma Balasubiramani wrote:
On 22/01/2024 16:30, Boris Brezillon wrote:
> Anything relating to GEM object management is placed here. Nothing
> particularly interesting here, given the implementation is based on
> drm_gem_shmem_object, which is doing most of the work.
>
> v4:
> - Force kernel BOs to be GPU mapped
> - Make
On 2/9/24 16:23, Michael Kelley wrote:
From: Thomas Zimmermann Sent: Thursday, February 1, 2024
12:17 AM
Hi
Am 01.02.24 um 07:00 schrieb mhkelle...@gmail.com:
From: Michael Kelley
A recent commit removing the use of screen_info introduced a logic
error. The error causes hvfb_getmem() to
On Sun, Feb 04, 2024 at 11:56:18AM +0200, Laurent Pinchart wrote:
> On Thu, Feb 01, 2024 at 06:01:01PM +0100, Maxime Ripard wrote:
> > On Fri, Jan 26, 2024 at 11:18:30PM +, Klymenko, Anatoliy wrote:
> > > On Friday, January 26, 2024 4:26 AM, Maxime Ripard wrote:
> > > > On Wed, Jan 17, 2024 at
On 2/7/2024 3:24 AM, Jacek Lawrynowicz wrote:
Issue IP reset before shutdown in order to
complete all upstream requests to the SOC.
Without this DevTLB is complaining about
incomplete transactions and NPU cannot resume from
suspend.
This problem is only happening on recent IFWI
releases.
IP
On Thu, Feb 01, 2024 at 02:22:16AM +, Keith Zhao wrote:
>
>
>
>
> > -Original Message-
>
> > From: Maxime Ripard
>
> > Sent: 2024年1月31日 21:24
>
> > To: Keith Zhao
>
> > Cc: devicet...@vger.kernel.org; dri-devel@lists.freedesktop.org;
>
> > linux-ker...@vger.kernel.org;
On 2/9/2024 05:07, Daniel Vetter wrote:
On Thu, Feb 08, 2024 at 11:57:11AM +0200, Jani Nikula wrote:
On Wed, 07 Feb 2024, Mario Limonciello wrote:
Some manufacturers have intentionally put an EDID that differs from
the EDID on the internal panel on laptops. Drivers can call this
helper to
Few users have observed display corruption when they boot
the machine to KDE Plasma or playing games. We have root
caused the problem that whenever alloc_range() couldn't
find the required memory blocks the function was returning
SUCCESS in some of the corner cases.
The right approach would be if
From: Thomas Zimmermann Sent: Thursday, February 1, 2024
12:17 AM
>
> Hi
>
> Am 01.02.24 um 07:00 schrieb mhkelle...@gmail.com:
> > From: Michael Kelley
> >
> > A recent commit removing the use of screen_info introduced a logic
> > error. The error causes hvfb_getmem() to always return
Few users have observed display corruption when they boot
the machine to KDE Plasma or playing games. We have root
caused the problem that whenever alloc_range() couldn't
find the required memory blocks the function was returning
SUCCESS in some of the corner cases.
The right approach would be if
On Fri, Feb 09, 2024 at 12:02:48PM +0100, Daniel Vetter wrote:
> On Thu, Feb 08, 2024 at 04:27:02PM +0100, Maxime Ripard wrote:
> > On Wed, Feb 07, 2024 at 10:35:49AM +0100, Daniel Vetter wrote:
> > > On Wed, Feb 07, 2024 at 01:27:59AM +0800, Sui Jingfeng wrote:
> > > > The component helper
Enable LVDS serializer support for display pipeline.
Signed-off-by: Dharma Balasubiramani
Acked-by: Hari Prasath Gujulan Elango
Acked-by: Nicolas Ferre
---
Changelog
v3 -> v4
- No Changes.
v2 -> v3
- No Changes.
---
arch/arm/configs/at91_dt_defconfig | 1 +
1 file changed, 1 insertion(+)
Add the newly added LVDS controller for the SAM9X7 SoC to the existing
MAINTAINERS entry.
Signed-off-by: Dharma Balasubiramani
Reviewed-by: Neil Armstrong
Acked-by: Nicolas Ferre
---
Changelog
v3 ->v4
- No changes.
v2 -> v3
- Move the entry before "MICROCHIP SAMA5D2-COMPATIBLE ADC DRIVER".
v1
Add the 'sam9x75-lvds' compatible binding, which describes the Low Voltage
Differential Signaling (LVDS) Controller found on some Microchip's sam9x7
series System-on-Chip (SoC) devices. This binding will be used to define
the properties and configuration for the LVDS Controller in DT.
Add a new LVDS controller driver for sam9x7 which does the following:
- Prepares and enables the LVDS Peripheral clock
- Defines its connector type as DRM_MODE_CONNECTOR_LVDS and adds itself
to the global bridge list.
- Identifies its output endpoint as panel and adds it to the encoder
display
This patch series introduces LVDS controller support for the SAM9X75 SoC. The
LVDS controller is designed to work with Microchip's sam9x7 series
System-on-Chip (SoC) devices, providing Low Voltage Differential Signaling
capabilities.
Patch series Changelog:
- Include configs: at91: Enable LVDS
On Mon, Jan 22, 2024 at 04:42:55PM +, Biju Das wrote:
> +static const struct drm_gem_object_funcs rzg2l_du_gem_funcs = {
> + .free = drm_gem_dma_object_free,
> + .print_info = drm_gem_dma_object_print_info,
> + .get_sg_table = drm_gem_dma_object_get_sg_table,
> + .vmap =
On Fri, 09 Feb 2024, Michał Winiarski wrote:
> Fix one of the tests in drm_mm that was not converted prior to
> drm_debug_printer removal, causing tests build failure.
My bad, thanks for fixing this.
Reviewed-by: Jani Nikula
For one thing, I must not have git grep'd for new
On 09/02/24 7:50 pm, Dharma B wrote:
> On 08/02/24 2:31 pm, Krzysztof Kozlowski wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know
>> the content is safe
>>
>> On 07/02/2024 11:27, Dharma Balasubiramani wrote:
>>> Add the 'sam9x75-lvds' compatible binding, which
On Fri, Feb 09, 2024 at 07:50:52AM +, Lee Jones wrote:
> On Thu, 08 Feb 2024, Andy Shevchenko wrote:
> > On Thu, Feb 08, 2024 at 06:14:55PM +, Lee Jones wrote:
> > > On Thu, 08 Feb 2024, Andy Shevchenko wrote:
> > > > On Thu, Feb 08, 2024 at 05:39:46PM +, Lee Jones wrote:
> > > > > On
On 2/9/24 15:08, Michał Winiarski wrote:
Fix one of the tests in drm_mm that was not converted prior to
drm_debug_printer removal, causing tests build failure.
Fixes: e154c4fc7bf2d ("drm: remove drm_debug_printer in favor of
drm_dbg_printer")
Signed-off-by: Michał Winiarski
---
On 09.02.2024 15:08, Michał Winiarski wrote:
> Fix one of the tests in drm_mm that was not converted prior to
> drm_debug_printer removal, causing tests build failure.
>
> Fixes: e154c4fc7bf2d ("drm: remove drm_debug_printer in favor of
> drm_dbg_printer")
> Signed-off-by: Michał Winiarski
Hi Conor,
On 07/02/24 9:22 pm, Conor Dooley wrote:
> $subject: dt-bindings: display: bridge: add sam9x75-lvds compatible
>
> If there's a respin for some reason, please update the subject to match
> what the commit is actually doing (adding a whole binding).
Absolutely, I'll make the adjustment
On 08/02/24 2:31 pm, Krzysztof Kozlowski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On 07/02/2024 11:27, Dharma Balasubiramani wrote:
>> Add the 'sam9x75-lvds' compatible binding, which describes the Low Voltage
>> Differential
1 - 100 of 118 matches
Mail list logo
