Hi
Am 11.10.22 um 22:06 schrieb Arnd Bergmann:
On Tue, Oct 11, 2022, at 1:30 PM, Thomas Zimmermann wrote:
Am 11.10.22 um 09:46 schrieb Javier Martinez Canillas:
+static bool display_get_big_endian_of(struct drm_device *dev, struct
device_node *of_node)
+{
+ bool big_endian;
+
+#ifdef __
Am 11.10.22 um 17:20 schrieb Simon Ser:
On Tuesday, October 11th, 2022 at 13:56, Christian König
wrote:
Am 11.10.22 um 13:37 schrieb Simon Ser:
On Tuesday, October 11th, 2022 at 13:04, Christian König
ckoenig.leichtzumer...@gmail.com wrote:
we already have quite a bunch of devices which
On Tue, Oct 11, 2022 at 09:51:08PM -0700, Lucas De Marchi wrote:
It's a constant pattern in the driver to need to use 2 ranges of MMIOs
based on port, phy, pll, etc. When that happens, instead of using
_PICK_EVEN(), _PICK() needs to be used. Using _PICK() is discouraged
due to some reasons like:
Hi Hyunwoo:
[patch "fbdev: smscufx: Fix use-after-free in
ufx_ops_open()"](https://lore.kernel.org/all/20220925133243.GA383897@ubuntu/T/)
fix [CVE-2022-41849](https://nvd.nist.gov/vuln/detail/CVE-2022-41849).
If the UAF scenarios is as follows, it seems that [fix path
v3](https://lore.kernel
Avoid the array lookup, converting the PLL macros after ICL to
_PICK_EVEN_RANGES. This provides the following reduction in code size:
$ size build64/drivers/gpu/drm/i915/i915.o{.old,.new}
textdata bss dec hex filename
3570297 1312326824 3708353 3895
-commit: caaf8c4c270b6b9ce1b8610b4eea888190fc087f
change-id: 20221011-pick-even-ranges-76ad8a5007e9
Best regards,
--
Lucas De Marchi
It's a constant pattern in the driver to need to use 2 ranges of MMIOs
based on port, phy, pll, etc. When that happens, instead of using
_PICK_EVEN(), _PICK() needs to be used. Using _PICK() is discouraged
due to some reasons like:
1) It increases the code size since the array is declared
Abide by the rules in the top of the header: 2 spaces for bitfield,
prefix offsets with underscore and prefer the use of REG_BIT().
Signed-off-by: Lucas De Marchi
(cherry picked from commit c5545ec37a7f5b928f3f6e3993f1f24b9e70ba32)
---
drivers/gpu/drm/i915/i915_reg.h | 20 ++--
1
Some bridges are able to update HDCP status from userspace request if
they support HDCP.
HDCP property is the same as other connector properties that need to be
created after the connecter is initialized and before the connector is
registered.
Signed-off-by: Hsin-Yi Wang
Reported-by: kernel test
The RTNI field is multiplied by 16 and incremented by 512 before being
used as the minimum number of pixel clock per horizontal line, hence
it is necessary to subtract those 512 bytes from htotal and then divide
the result by 16 before writing the value into the RTNI field. Fix the
calculation.
Fi
On 10/10/2022 15:57, Ceraolo Spurio, Daniele wrote:
On 10/10/2022 3:50 PM, John Harrison wrote:
On 10/10/2022 11:48, Daniele Ceraolo Spurio wrote:
We're observing sporadic HuC delayed load timeouts in CI, due to
mei_pxp
binding completing later than we expected. HuC is still loaded when the
bi
STM32MP15xx RM0436 Rev 6 "35.7.3 LTDC synchronization size configuration
register (LTDC_SSCR)" on page 1784 and onward indicates VSH and similar
bits are all [11:0] instead of [10:0] wide. Fix this.
[1] https://www.st.com/resource/en/reference_manual/DM00327659-.pdf
Fixes: b759012c5fa7 ("drm/stm:
On Mon, 10 Oct 2022 17:06:06 -0600 Jason A. Donenfeld wrote:
> - If you want a secure or an insecure random u64, use get_random_u64().
> - If you want a secure or an insecure random u32, use get_random_u32().
> * The old function prandom_u32() has been deprecated for a while now
> and is just
On Tue, Oct 11, 2022 at 10:06:59PM +0200, Arnd Bergmann wrote:
> On Tue, Oct 11, 2022, at 1:30 PM, Thomas Zimmermann wrote:
> > Am 11.10.22 um 09:46 schrieb Javier Martinez Canillas:
> >>> +static bool display_get_big_endian_of(struct drm_device *dev, struct
> >>> device_node *of_node)
> >>> +{
>
On 10/7/2022 6:56 AM, Robert Foss wrote:
On Thu, 6 Oct 2022 at 17:07, Abhinav Kumar wrote:
Hi Robert
Thanks for the review.
On 10/4/2022 8:55 AM, Robert Foss wrote:
On Mon, 29 Aug 2022 at 20:23, Abhinav Kumar wrote:
adv7533 bridge tries to dynamically switch lanes based on the
mode by
adv7533 bridge tries to dynamically switch lanes based on the
mode by detaching and attaching the mipi dsi device.
This approach is incorrect because this method of dynamic switch of
detaching and attaching the mipi dsi device also results in removing
and adding the component which is not necessar
Currently the EDID is requested during the resume. But since it's
requested too early, this means before the filesystem is mounted, the
firmware request fails. This make the DRM driver crash when resuming.
This kind of issue should be prevented by the firmware caching process
which cache every firm
On Tue, Oct 11, 2022, at 1:30 PM, Thomas Zimmermann wrote:
> Am 11.10.22 um 09:46 schrieb Javier Martinez Canillas:
>>> +static bool display_get_big_endian_of(struct drm_device *dev, struct
>>> device_node *of_node)
>>> +{
>>> + bool big_endian;
>>> +
>>> +#ifdef __BIG_ENDIAN
>>> + big_endian
Thank you for the feedback. Incorporated the review and posted new patches here
[1].
Thanks,
Radhakrishna(RK) Sripada
[1] https://patchwork.freedesktop.org/series/109588/
> -Original Message-
> From: Ville Syrjälä
> Sent: Tuesday, October 11, 2022 3:33 AM
> To: Jani Nikula
> Cc: Sripa
Hi Angelo,
Thanks for the suggestions! I'll upload another patch with those changes.
Re the pitch register math, would it be acceptable to define separate
macros for the LSB and MSB to abstract away the magic numbers? For
example:
#define OVL_PITCH_MSB(n)((n >> 16) & GENMAS
The pull request you sent on Sun, 9 Oct 2022 12:49:05 +0200:
> http://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git
> tags/fbdev-for-6.1-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/eec4ed317dccdef610b54224f45e0e1f4fdb75fb
Thank you!
--
Deet-
On 11/10/2022 17:27, Matthew Auld wrote:
On 10/10/2022 07:58, Niranjana Vishwanathapura wrote:
Each VM creates a root_obj and shares it with all of its private objects
to use it as dma_resv object. This has a performance advantage as it
requires a single dma_resv object update for all private BO
On 10/10/2022 07:58, Niranjana Vishwanathapura wrote:
Add uapi and implement support for bind and unbind of an
object at the specified GPU virtual addresses.
The vm_bind mode is not supported in legacy execbuf2 ioctl.
It will be supported only in the newer execbuf3 ioctl.
v2: On older platforms
Hi Hsin-Yi,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on linus/master v6.0 next-20221011]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '-
On 9/28/22 22:15, Dmitry Osipenko wrote:
> Hello,
>
> This series moves all drivers to a dynamic dma-buf locking specification.
> From now on all dma-buf importers are made responsible for holding
> dma-buf's reservation lock around all operations performed over dma-bufs
> in accordance to the loc
Thanks a lot for your series. This solves a big performance impact when
using Gnome/Wayland on some Aspeed chip, with BMC.
This also remove the need for "shadowFB" workaround in userspace.
With the small change in patch 8, and the two typo's,
the whole series is
Reviewed-by: Jocelyn Falempe
Te
On Fri, 07 Oct 2022, Ville Syrjälä wrote:
> On Thu, Oct 06, 2022 at 06:11:37PM +0300, Ville Syrjälä wrote:
>> On Thu, Oct 06, 2022 at 11:33:14AM +0200, Simon Rettberg wrote:
>> > Current dual mode adaptor ("DP++") detection code assumes that all
>> > adaptors support i2c sub-addressing for read op
On 10/10/2022 12:36, Thomas Zimmermann wrote:
Replace GEM VRAM helpers with GEM SHMEM helpers in ast. Avoids OOM
errors when allocating video memory. Also adds support for dma-buf
functionality.
Aspeed display hardware supports display resolutions of FullHD and
more at 32-bit pixel depth. But th
On 10/10/2022 12:36, Thomas Zimmermann wrote:
Hold I/O-register lock in atomic_commit_tail to protect all pipeline
updates at once. Protects modesetting against concurrent EDID reads.
Complex modesetting operations involve mode changes and plane updates.
These steps used to be protected individu
On 11/10/2022 16:59, Thomas Zimmermann wrote:
Hi
Am 11.10.22 um 16:21 schrieb Jocelyn Falempe:
On 10/10/2022 12:36, Thomas Zimmermann wrote:
Some AST-based BMCs stop display output for up to 5 seconds after
reprogramming the scanout address. As the address is fixed, avoid
re-setting the addres
Provides a default CRTC state check handler for CRTCs that only have one
primary plane attached.
There are some drivers that duplicate this logic in their helpers, such as
simpledrm and ssd130x. Factor out this common code into a CRTC helper and
make drivers use it.
Signed-off-by: Javier Martinez
There's no need to add planes to the atomic state. Remove the call
to drm_atomic_add_affected_planes() from simpledrm.
On full modesets, the DRM helpers already add a CRTC's planes to the
atomic state; see drm_atomic_helper_check_modeset(). There's no reason
to call drm_atomic_add_affected_planes(
There's no need to add planes to the atomic state. Remove the call
to drm_atomic_add_affected_planes() from ssd130x.
On full modesets, the DRM helpers already add a CRTC's planes to the
atomic state; see drm_atomic_helper_check_modeset(). There's no reason
to call drm_atomic_add_affected_planes()
There's no need to add planes to the atomic state. Remove the call
to drm_atomic_add_affected_planes() from mgag200.
On full modesets, the DRM helpers already add a CRTC's planes to the
atomic state; see drm_atomic_helper_check_modeset(). There's no reason
to call drm_atomic_add_affected_planes()
Add a helper function and make drivers that have the same logic in their
struct drm_crtc_helper_funcs .atomic_check handler to use this instead.
Patch #1, #2 and #3 are just cleanups for the mgag200, simpledrm and
ssd130x drivers respectively. Finally patch #4 converts the last two
drivers to use
On 10/10/2022 07:58, Niranjana Vishwanathapura wrote:
Each VM creates a root_obj and shares it with all of its private objects
to use it as dma_resv object. This has a performance advantage as it
requires a single dma_resv object update for all private BOs vs list of
dma_resv objects update for s
Hi Hsin-Yi,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on linus/master v6.0 next-20221011]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '-
Applied. Thanks!
Alex
On Tue, Oct 11, 2022 at 11:27 AM Harry Wentland wrote:
>
> On 2022-10-10 03:38, Yang Li wrote:
> > The result of 'pwr_status == 0' is Boolean, and the question mark
> > expression is redundant.
> >
> > Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2354
> > Reported-
On Tue, Oct 11, 2022 at 12:55 AM Aashish Sharma wrote:
>
> Rectify the below smatch warning:
> drivers/gpu/drm/msm/msm_gem_submit.c:963 msm_ioctl_gem_submit() warn:
> variable dereferenced before check 'submit'
>
> 'submit' is normally error pointer or valid, so remove its NULL
> initializer as it
On 11/10/2022 01:55, Niranjana Vishwanathapura wrote:
On Mon, Oct 10, 2022 at 05:43:47PM -0700, Niranjana Vishwanathapura wrote:
On Mon, Oct 10, 2022 at 06:15:02PM +0100, Matthew Auld wrote:
On 10/10/2022 17:11, Niranjana Vishwanathapura wrote:
On Mon, Oct 10, 2022 at 02:30:49PM +0100, Matthew
Platforms prior to MTL do not have a separate media and graphics version.
On platforms where GMD id is not supported, reuse the graphics ip version,
release info for media.
The rest of the IP graphics, display versions would be copied during driver
creation.
While at it warn if GMD is not used fo
Rename struct ip_version to intel_ip_version to comply with the
naming conventions for structures.
Suggested-by: Jani Nikula
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/intel_device_info.c | 2 +-
drivers/gpu/drm/i915/intel_device_info.h | 8
drivers/gpu/drm/i915/intel
On Tue, Oct 11, 2022 at 10:13:02PM +0800, ChenXiaoSong wrote:
> Hi Hyunwoo:
>
> [patch "fbdev: smscufx: Fix use-after-free in
> ufx_ops_open()"](https://lore.kernel.org/all/20220925133243.GA383897@ubuntu/T/)
> fix [CVE-2022-41849](https://nvd.nist.gov/vuln/detail/CVE-2022-41849).
>
> If the UAF
On 2022-10-10 03:38, Yang Li wrote:
> The result of 'pwr_status == 0' is Boolean, and the question mark
> expression is redundant.
>
> Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2354
> Reported-by: Abaci Robot
> Signed-off-by: Yang Li
Reviewed-by: Harry Wentland
Harry
> ---
> driv
On Tuesday, October 11th, 2022 at 13:56, Christian König
wrote:
> Am 11.10.22 um 13:37 schrieb Simon Ser:
>
> > On Tuesday, October 11th, 2022 at 13:04, Christian König
> > ckoenig.leichtzumer...@gmail.com wrote:
> >
> > > we already have quite a bunch of devices which are essentially render
Support the CRTC's color-management property and implement each model's
palette support.
The OF hardware has different methods of setting the palette. The
respective code has been taken from fbdev's offb and refactored into
per-model device functions. The device functions integrate this
functional
Add a per-model device-function structure in preparation of adding
color-management support. Detection of the individual models has been
taken from fbdev's offb.
v3:
* define constants for PCI ids (Javier)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drive
Add a dedicated CRTC state to ofdrm to later store information for
palette updates.
v3:
* rework CRTC state helpers (Javier)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/tiny/ofdrm.c | 59 ++--
1 file changed
All DRM formats assume little-endian byte order. On big-endian systems,
it is likely that the scanout buffer is in big endian as well. Update
the format accordingly and add endianess conversion to the format-helper
library. Also opt-in to allocated buffers in host format by default.
Suggested-by:
Open Firmware provides basic display output via the 'display' node.
DT platform code already provides a device that represents the node's
framebuffer. Add a DRM driver for the device. The display mode and
color format is pre-initialized by the system's firmware. Runtime
modesetting via DRM is not p
PowerPC's Open Firmware offers a simple display buffer for graphics
output. Add ofdrm, a DRM driver for the device. As with the existing
simpledrm driver, the graphics hardware is pre-initialized by the
firmware. The driver only provides blitting, no actual DRM modesetting
is possible.
Patch 1 add
Hi
Am 11.10.22 um 15:26 schrieb Javier Martinez Canillas:
On 10/11/22 15:21, Thomas Zimmermann wrote:
Hi
Am 10.10.22 um 19:02 schrieb Javier Martinez Canillas:
Provides a default CRTC state check handler for CRTCs that only have one
primary plane attached.
There are some drivers that duplica
Hi
Am 11.10.22 um 16:21 schrieb Jocelyn Falempe:
On 10/10/2022 12:36, Thomas Zimmermann wrote:
Some AST-based BMCs stop display output for up to 5 seconds after
reprogramming the scanout address. As the address is fixed, avoid
re-setting the address' value.
Reported-by: Jocelyn Falempe
Signed
On 11/10/2022 14:59, Andi Shyti wrote:
Commit 3e7abf814193 ("drm/i915: Extract GT render power state management")
removes the "trace_intel_gpu_freq_change()" trace points but
their definition was left without users. Remove it.
Suggested-by: Tvrtko Ursulin
Signed-off-by: Andi Shyti
Cc: Chris
On 10/10/2022 12:36, Thomas Zimmermann wrote:
Some AST-based BMCs stop display output for up to 5 seconds after
reprogramming the scanout address. As the address is fixed, avoid
re-setting the address' value.
Reported-by: Jocelyn Falempe
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/a
On Tue, Oct 11, 2022 at 10:12 AM Jani Nikula wrote:
>
> On Tue, 11 Oct 2022, Harry Wentland wrote:
> > On 2022-10-11 09:49, Jani Nikula wrote:
> >> The connector->override_edid flag is strictly for EDID override debugfs
> >> management, and drivers have no business using it.
> >>
> >> Cc: Alex De
On Tue, 11 Oct 2022, Harry Wentland wrote:
> On 2022-10-11 09:49, Jani Nikula wrote:
>> The connector->override_edid flag is strictly for EDID override debugfs
>> management, and drivers have no business using it.
>>
>> Cc: Alex Deucher
>> Cc: Christian König
>> Cc: Xinhui Pan
>> Cc: amd-...@l
While it takes more vertical space, sorted build lists with one object
per line are arguably easier to manage, especially when there are
conflicting changes.
Split anything with more than one object file.
v2: also split drm_cache.o and put it after drm_bridge.o (Andi)
Signed-off-by: Jani Nikula
On 2022-10-11 09:49, Jani Nikula wrote:
> The connector->override_edid flag is strictly for EDID override debugfs
> management, and drivers have no business using it.
>
> Cc: Alex Deucher
> Cc: Christian König
> Cc: Xinhui Pan
> Cc: amd-...@lists.freedesktop.org
> Signed-off-by: Jani Nikula
Commit 3e7abf814193 ("drm/i915: Extract GT render power state management")
removes the "trace_intel_gpu_freq_change()" trace points but
their definition was left without users. Remove it.
Suggested-by: Tvrtko Ursulin
Signed-off-by: Andi Shyti
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_trac
Convert to drm_kms_dbg/drm_err where possible, and unify the rest of the
debugs to DRM_DEBUG_KMS.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 105 ++---
1 file changed, 50 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/dr
Conform to device specific logging.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid_load.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
index 882caaa6e663..dd472c66cb3c 100644
--- a/driver
The EDID loader is internal to drm, not for drivers.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_crtc_internal.h | 11 +++
drivers/gpu/drm/drm_edid_load.c | 5 +++--
include/drm/drm_edid.h | 7 ---
3 files changed, 14 insertions(+), 9 deletions(-)
diff --gi
There's a lot going on here, but the main thing is switching the
firmware EDID loader to use struct drm_edid. Unfortunately, it's
difficult to reasonably split to smaller pieces.
Convert the EDID loader to struct drm_edid. There's a functional change
in validation; it no longer tries to fix errors
Follow the usual naming convention by file name.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 10 +-
drivers/gpu/drm/drm_edid_load.c | 2 +-
include/drm/drm_edid.h | 4 ++--
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_
Split the drm_edid block count helper to a base version that reports the
block count indicated by EDID contents, and another on top that limits
the block count based on size allocated for the EDID.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 15 +++
1 file changed, 11
Stop passing around something that's readily available in
connector->name.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid_load.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
index 3
Follow the naming of both EDID override functions as well as
drm_edid_connector_update(). This also matches better what the function
does; a combination of EDID property update and add modes. Indeed it
should later be converted to call drm_edid_connector_update().
Signed-off-by: Jani Nikula
---
Having the EDID override debugfs directly update the EDID property is
problematic. The update is partial only. The driver has no way of
knowing it's been updated. Mode list is not updated. It's an
inconsistent state.
Detach debugfs EDID override from the property update completely. Only
set and re
The connector->override_edid flag is strictly for EDID override debugfs
management, and drivers have no business using it.
The check for override_edid was added in commit 301906290553 ("drm/i915:
Ignore TMDS clock limit for DP++ when EDID override is set") to
facilitate mode list cross-checking ag
We've lacked a function for immutable validity check on drm_edid. Add
one.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 30 ++
include/drm/drm_edid.h | 1 +
2 files changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/dr
The connector->override_edid flag is strictly for EDID override debugfs
management, and drivers have no business using it.
Cc: Alex Deucher
Cc: Christian König
Cc: Xinhui Pan
Cc: amd-...@lists.freedesktop.org
Signed-off-by: Jani Nikula
---
I really have no idea what the functional impact her
Add a function to dump the override EDID in debugfs. This hides the
override EDID management better in drm_edid.c.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_crtc_internal.h | 4 +++-
drivers/gpu/drm/drm_debugfs.c | 8 +---
drivers/gpu/drm/drm_edid.c | 11 +++
It's useful debugging information to know if and when an override EDID
was set or reset.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 47465b9765f1..a863cffa2dc5 10
For normal connector detect, there's really no point in trying dual mode
detect if the connector is disconnected. We can simplify the detect
sequence by skipping it. Since intel_hdmi_dp_dual_mode_detect() is only
called when EDID is present, we can drop the has_edid parameter.
The functional effec
I set out to fix some issues in switching i915 over to use drm_edid more
widely, and stumbled onto issues with edid override usage. Here's some
resulting fixes, refactoring and cleanup.
BR,
Jani.
Jani Nikula (15):
drm/i915/hdmi: do dual mode detect only if connected
drm/i915/hdmi: stop using
Applied. Thanks.
Alex
On Tue, Oct 11, 2022 at 8:41 AM Yang Yingliang wrote:
>
> dcn20_build_mapped_resource() and dcn20_acquire_dsc() is not defined,
> if CONFIG_DRM_AMD_DC_DCN is disabled.
>
> Fix the following build error on arm64:
>
> ERROR: modpost: "dcn20_build_mapped_resource"
> [drive
On 10/11/22 15:21, Thomas Zimmermann wrote:
> Hi
>
> Am 10.10.22 um 19:02 schrieb Javier Martinez Canillas:
>> Provides a default CRTC state check handler for CRTCs that only have one
>> primary plane attached.
>>
>> There are some drivers that duplicate this logic in their helpers, such as
>> sim
Hi
Am 10.10.22 um 19:02 schrieb Javier Martinez Canillas:
Provides a default CRTC state check handler for CRTCs that only have one
primary plane attached.
There are some drivers that duplicate this logic in their helpers, such as
simpledrm and ssd130x. Factor out this common code into a CRTC he
Hello Thomas,
On 10/11/22 15:06, Thomas Zimmermann wrote:
> Hi
>
> Am 10.10.22 um 19:02 schrieb Javier Martinez Canillas:
>> There's no need to add planes to the atomic state. Remove the call
>> to drm_atomic_add_affected_planes() from simpledrm.
>>
>> On full modesets, the DRM helpers already ad
Am 10.10.22 um 19:02 schrieb Javier Martinez Canillas:
There's no need to add planes to the atomic state. Remove the call
to drm_atomic_add_affected_planes() from ssd130x.
On full modesets, the DRM helpers already add a CRTC's planes to the
atomic state; see drm_atomic_helper_check_modeset().
Hi
Am 10.10.22 um 19:02 schrieb Javier Martinez Canillas:
There's no need to add planes to the atomic state. Remove the call
to drm_atomic_add_affected_planes() from simpledrm.
On full modesets, the DRM helpers already add a CRTC's planes to the
atomic state; see drm_atomic_helper_check_modeset
dcn20_build_mapped_resource() and dcn20_acquire_dsc() is not defined,
if CONFIG_DRM_AMD_DC_DCN is disabled.
Fix the following build error on arm64:
ERROR: modpost: "dcn20_build_mapped_resource"
[drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
ERROR: modpost: "dcn20_acquire_dsc" [drivers/gpu
Am 10.10.22 um 11:13 schrieb Simon Ser:
On Sunday, October 9th, 2022 at 20:00, Christian König
wrote:
Am 09.10.22 um 16:40 schrieb Simon Ser:
Introduce a new DRM_IOCTL_SYNCOBJ_TIMELINE_REGISTER_EVENTFD IOCTL
which signals an eventfd when a timeline point completes.
I was entertaining the s
Yeah, that's a known issue. Dave already reverted the problematic patch
in drm-next.
But it will probably take a while until the revert propagates down into
the drm-misc-next or whatever you uses.
Regards,
Christian.
Am 11.10.22 um 14:02 schrieb Mikhail Gavrilov:
Hi!
The hungs occurs random
Hi!
The hungs occurs randomly, but I found good reproductive scenario
(This is running the campaign in the game Halo Infinite)
The backtrace is look like this:
[ 147.260971] BUG: kernel NULL pointer dereference, address: 0088
[ 147.260987] [ cut here ]
[ 147.
Am 11.10.22 um 13:37 schrieb Simon Ser:
On Tuesday, October 11th, 2022 at 13:04, Christian König
wrote:
we already have quite a bunch of devices which are essentially render
only and don't expose any connectors or more general display functionality.
Just recently I ran into a case where an o
Am 11.10.22 um 13:39 schrieb Simon Ser:
On Tuesday, October 11th, 2022 at 13:04, Christian König
wrote:
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -54,7 +54,6 @@ struct file;
*/
enum drm_minor_type {
DRM_MINOR_PRIMARY,
- DRM_MINOR_CONTROL,
DRM_MINO
On Tuesday, October 11th, 2022 at 13:04, Christian König
wrote:
> --- a/include/drm/drm_file.h
> +++ b/include/drm/drm_file.h
> @@ -54,7 +54,6 @@ struct file;
> */
> enum drm_minor_type {
> DRM_MINOR_PRIMARY,
> - DRM_MINOR_CONTROL,
> DRM_MINOR_RENDER,
> };
This makes me unco
On Tuesday, October 11th, 2022 at 13:04, Christian König
wrote:
> we already have quite a bunch of devices which are essentially render
> only and don't expose any connectors or more general display functionality.
>
> Just recently I ran into a case where an older X/DDX combination
> caused pro
Hi
Am 11.10.22 um 09:46 schrieb Javier Martinez Canillas:
Hello Thomas,
On 9/28/22 12:50, Thomas Zimmermann wrote:
All DRM formats assume little-endian byte order. On big-endian systems,
it is likely that the scanout buffer is in big endian as well. Update
You say it is likely, not always th
On Tue, 11 Oct 2022, Andi Shyti wrote:
> Hi Jani,
>
>> While it takes more vertical space, sorted build lists with one object
>> per line are arguably easier to manage, especially when there are
>> conflicting changes.
>>
>> Split anything with more than one object file.
>
> looks much better! Ju
Am 11.10.22 um 13:27 schrieb Thomas Zimmermann:
Hi
Am 11.10.22 um 13:04 schrieb Christian König:
This allows to suppress creating the primary node. Useful for drivers
which don't expose any display functionality, but are render only by
design.
Signed-off-by: Christian König
---
drivers/gpu/
Hi
Am 11.10.22 um 13:04 schrieb Christian König:
This allows to suppress creating the primary node. Useful for drivers
which don't expose any display functionality, but are render only by
design.
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_drv.c | 10 ++
drivers/gpu/drm
Not used any more. This makes room for up to 128 DRM devices.
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_drv.c | 4 ++--
include/drm/drm_file.h| 1 -
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 8214a0b
This allows to suppress creating the primary node. Useful for drivers
which don't expose any display functionality, but are render only by
design.
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_drv.c | 10 ++
drivers/gpu/drm/drm_prime.c | 2 +-
include/drm/drm_drv.h | 7
Hi guys,
we already have quite a bunch of devices which are essentially render only and
don't expose any connectors or more general display functionality.
Just recently I ran into a case where an older X/DDX combination caused
problems for such a device so I looked a bit into the possibility to
On Tue, Oct 11, 2022 at 01:10:26PM +0300, Jani Nikula wrote:
> On Tue, 11 Oct 2022, "Sripada, Radhakrishna"
> wrote:
> > Hi Jani,
> >
> >> -Original Message-
> >> From: Jani Nikula
> >> Sent: Tuesday, October 11, 2022 12:28 AM
> >> To: Sripada, Radhakrishna ; intel-
> >> g...@lists.freed
Hi Jani,
> While it takes more vertical space, sorted build lists with one object
> per line are arguably easier to manage, especially when there are
> conflicting changes.
>
> Split anything with more than one object file.
looks much better! Just an error below.
> Signed-off-by: Jani Nikula
>
Some bridges are able to update HDCP status from userspace requests if
they support HDCP.
HDCP property is the same as other connector properties that need to be
created after the connecter is initialized and before the connector is
registered.
Signed-off-by: Hsin-Yi Wang
---
drivers/gpu/drm/dr
1 - 100 of 113 matches
Mail list logo
