Allow clocks to keep their rate when parent (or grandparent) rate
changes.
Signed-off-by: Frank Oltmanns
---
drivers/clk/clk.c| 48 +++-
include/linux/clk-provider.h | 2 ++
2 files changed, 49 insertions(+), 1 deletion(-)
diff --git
From: Icenowy Zheng
As the clk framework keeps A64's TCON0 clock stable when HDMI changes
its parent's clock, do not protect TCON0 clock on A64 in the TCON driver
to allow PLL-Video0 to get changed by HDMI.
Signed-off-by: Icenowy Zheng
Signed-off-by: Frank Oltmanns
---
Keep the clock rate of Allwinner A64's pll-mipi even when the parent
(pll-video0) changes its rate. This is required, to drive both an LCD
and HDMI display, because both have pll-video0 as an ancestor.
Signed-off-by: Frank Oltmanns
---
drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 3 ++-
1 file
2 ++
5 files changed, 65 insertions(+), 4 deletions(-)
---
base-commit: c539c5c0a7ccafe7169c02564cceeb50317b540b
change-id: 20230824-pll-mipi_keep_rate-0a3a0d3574cf
Best regards,
--
Frank Oltmanns
On Thu, Aug 24, 2023 at 9:26 PM Laurent Pinchart
wrote:
> On Thu, Aug 24, 2023 at 07:15:46PM +0100, Biju Das wrote:
...
> I wonder, as the device can only be instantiated from OF, should we add
>
> depends on OF
Generally speaking this is a bad idea. It prevents a component from
being
Hi Linus,
A bit bigger than I'd care for, but it's mostly a single vmwgfx fix
and a fix for an i915 hotplug probing. Otherwise misc i915, bridge,
panfrost and dma-buf fixes.
Dave.
drm-fixes-2023-08-25:
drm fixes for 6.5-rc8
core:
- add a HPD poll helper
i915:
- fix regression in i915 polling
On Fri, Aug 25, 2023 at 01:04:10AM +0200, Danilo Krummrich wrote:
> On Thu, Aug 10, 2023 at 07:31:32PM -0700, Matthew Brost wrote:
> > Rather than call free_job and run_job in same work item have a dedicated
> > work item for each. This aligns with the design and intended use of work
> > queues.
>
In some cases the bridge drivers would like to receive hotplug events
even in the case new status is equal to the old status. In the DP case
this is used to deliver "attention" messages to the DP host. Stop
filtering the events in the drm_bridge_connector_hpd_cb() and let
drivers decide whether
Implement the oob_hotplug_event() callback. Translate it to the HPD
notification sent to the HPD bridge in the chain.
Reviewed-by: Janne Grunau
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/drm_bridge_connector.c | 29 +++---
1 file changed, 26 insertions(+), 3
From: Bjorn Andersson
In some implementations, such as the Qualcomm platforms, the display
driver has no way to query the current HPD state and as such it's
impossible to distinguish between disconnect and attention events.
Add a parameter to drm_connector_oob_hotplug_event() to pass the HPD
Note, numbering for this series starts from v5, since there were several
revisions for this patchset under a different series title ([1]).
USB altmodes code would send OOB notifications to the drm_connector
specified in the device tree. However as the MSM DP driver uses
drm_bridge_connector,
On Thu, Aug 10, 2023 at 07:31:32PM -0700, Matthew Brost wrote:
> Rather than call free_job and run_job in same work item have a dedicated
> work item for each. This aligns with the design and intended use of work
> queues.
>
> Signed-off-by: Matthew Brost
> ---
>
On Thu, Aug 24, 2023 at 01:51:59PM -0700, Doug Anderson wrote:
> On Thu, Aug 24, 2023 at 11:26 AM Laurent Pinchart wrote:
> > On Thu, Aug 24, 2023 at 07:15:46PM +0100, Biju Das wrote:
> > > The driver has an ID table, but it uses the wrong API for retrieving match
> > > data and that will lead to
d, command,
VPU_DYNDBG_CMD_MAX_LEN);
ret = ivpu_ipc_send_receive(vdev, , VPU_JSM_MSG_DYNDBG_CONTROL_RSP,
,
VPU_IPC_CHAN_ASYNC_CMD, vdev->timeout.jsm);
---
base-commit: f9604036a3fb6149badf346994b46b03f9292db7
change-id: 20230824-strncpy-drivers-accel-ivpu
Before sending a uevent to userspace in order to trigger a corrective
modeset, we change the failing connector's link-status to BAD. However,
the downstream MST branch ports are left in their original GOOD state.
This patch utilizes the drm helper function
drm_dp_set_mst_topology_link_status() to
When a link-training attempt fails, emit a uevent to user space that
includes the trigger property, which in this case will be
link-statue=Bad.
This will allow userspace to parse the uevent property and better
understand the reason for the previous modeset failure.
Signed-off-by: Gil Dekel
V2:
Currently, link-training fallback is only implemented for SST, so having
modeset_retry_work in intel_connector makes sense. However, we hope to
implement link training fallback for MST in a follow-up patchset, so
moving modeset_retry_work to indel_dp will make handling both SST and
MST connectors
Unlike SST, MST can support multiple displays connected to a single
connector. However, this also means that if the DisplayPort link to the
top-level MST branch device becomes unstable, then every single branch
device has an unstable link.
Since there are multiple downstream ports per connector,
Currently, MST link training has no fallback. This means that if an MST
base connector fails to link-train once, the training completely fails,
which makes this case significantly more common than a complete SST link
training failure.
Similar to the final failure state of SST, this patch zeros
Instead of silently giving up when all link-training fallback values are
exhausted, this patch modifies the fallback's failure branch to reduces
both max_link_lane_count and max_link_rate to zero (0) and continues to
emit uevents until userspace stops attempting to modeset.
By doing so, we ensure
Next version of https://patchwork.freedesktop.org/series/122850/
v4:
Another blunder. I uploaded the patches from my ChromeiumOS kernel dev repo
instead of drm-tip/drm-tip. Apologies for the noise :(
v3:
Still learning the ropes of upstream workflow. Apologies for mucking up v2.
This is
Hi,
On Thu, Aug 24, 2023 at 11:26 AM Laurent Pinchart
wrote:
>
> Hi Biju,
>
> Thank you for the patch.
>
> On Thu, Aug 24, 2023 at 07:15:46PM +0100, Biju Das wrote:
> > The driver has an ID table, but it uses the wrong API for retrieving match
> > data and that will lead to a crash, if it is
Hi Laurent Pinchart,
Thanks for the feedback.
> Subject: Re: [PATCH v3] drm/bridge/analogix/anx78xx: Drop ID table
>
> Hi Biju,
>
> Thank you for the patch.
>
> On Thu, Aug 24, 2023 at 07:15:46PM +0100, Biju Das wrote:
> > The driver has an ID table, but it uses the wrong API for retrieving
>
;cpucp_info.card_name, GOYA_DEFAULT_CARD_NAME,
+ strscpy(prop->cpucp_info.card_name, GOYA_DEFAULT_CARD_NAME,
CARD_NAME_MAX_LEN);
return 0;
---
base-commit: f9604036a3fb6149badf346994b46b03f9292db7
change-id: 20230824-strncpy-drivers-accel-habanalabs-goya-g
dev->dram_binning = prop->cpucp_info.dram_binning_mask;
---
base-commit: f9604036a3fb6149badf346994b46b03f9292db7
change-id:
20230824-strncpy-drivers-accel-habanalabs-gaudi2-gaudi2-c-0b3f717bee12
Best regards,
--
Justin Stitt
ucp_info.card_type);
---
base-commit: f9604036a3fb6149badf346994b46b03f9292db7
change-id: 20230824-strncpy-drivers-accel-habanalabs-gaudi-gaudi-c-f0b5814ced38
Best regards,
--
Justin Stitt
On 24.08.23 20:30, Jason Gunthorpe wrote:
On Thu, Aug 24, 2023 at 08:30:17PM +0200, David Hildenbrand wrote:
On 24.08.23 08:31, Kasireddy, Vivek wrote:
Hi David,
- Add a new API to the backing store/allocator to longterm-pin the page.
For example, something along the lines of
On Thu, Aug 24, 2023 at 08:30:17PM +0200, David Hildenbrand wrote:
> On 24.08.23 08:31, Kasireddy, Vivek wrote:
> > Hi David,
> >
> > >
> > > > > - Add a new API to the backing store/allocator to longterm-pin the
> > > > > page.
> > > > > For example, something along the lines of
> > >
On 24.08.23 08:31, Kasireddy, Vivek wrote:
Hi David,
- Add a new API to the backing store/allocator to longterm-pin the page.
For example, something along the lines of
shmem_pin_mapping_page_longterm()
for shmem as suggested by Daniel. A similar one needs to be added for
https://bugzilla.kernel.org/show_bug.cgi?id=217664
--- Comment #28 from Mario Limonciello (AMD) (mario.limoncie...@amd.com) ---
> https://mega.nz/file/OoBmED6L#6Tw4c1kwsUirYXK_XQ7pw6vtLyghrho8MMyB5rzmYYw -
> ppa install
> https://mega.nz/file/3gRwgDyD#trmYYtnvYSP8z03U4Ggr3BvKFG-KFMOjhJvGnowBjFU -
Hi Biju,
Thank you for the patch.
On Thu, Aug 24, 2023 at 07:15:46PM +0100, Biju Das wrote:
> The driver has an ID table, but it uses the wrong API for retrieving match
> data and that will lead to a crash, if it is instantiated by user space or
> using ID. From this, there is no user for the ID
Hi,
On Thu, Aug 24, 2023 at 11:15 AM Biju Das wrote:
>
> The driver has an ID table, but it uses the wrong API for retrieving match
> data and that will lead to a crash, if it is instantiated by user space or
> using ID. From this, there is no user for the ID table and let's drop it
> from the
The driver has an ID table, but it uses the wrong API for retrieving match
data and that will lead to a crash, if it is instantiated by user space or
using ID. From this, there is no user for the ID table and let's drop it
from the driver as it saves some memory.
Signed-off-by: Biju Das
---
Hi Dave and Daniel,
here is this week's PR for drm-misc-next. One of the patches is a
change to nouveau's UAPI.
Best regards
Thomas
drm-misc-next-fixes-2023-08-24:
Short summary of fixes pull:
* gpuva: Cleanups
* kunit: Documentation fixes
* nouveau:
* UAPI: Avoid implicit NO_PREFETCH
Hi,
On Thu, Aug 24, 2023 at 11:10 AM Biju Das wrote:
>
> The driver has an ID table, but it uses the wrong API for retrieving match
> data and that will lead to a crash, if it is instantiated by user space or
> using ID. From this, there is no user for the ID table and let's drop it
> from the
The driver has an ID table, but it uses the wrong API for retrieving match
data and that will lead to a crash, if it is instantiated by user space or
using ID. From this, there is no user for the ID table and let's drop it
from the driver as it saves some memory.
Signed-off-by: Biju Das
---
On 8/23/2023 8:52 PM, Dmitry Osipenko wrote:
On 8/20/23 23:58, Kim, Dongwon wrote:
On 8/17/2023 7:33 PM, Dmitry Osipenko wrote:
On 7/13/23 01:44, Dongwon Kim wrote:
This helper is needed for framebuffer synchronization. Old
framebuffer data
is often displayed on the guest display without
On 20.08.23 12:06, Christophe JAILLET wrote:
[...]
+static void hid_bl_remove(struct hid_device *hdev)
+{
+ struct backlight_device *bl;
+ struct hid_bl_data *data;
+
+ hid_dbg(hdev, "remove\n");
+ bl = hid_get_drvdata(hdev);
+ data = bl_get_data(bl);
+
+
Thank you, Christian.
Glad to hear about that.
However, I guess this assumes that this piece of code between
-<>-
preempt_disable();
tail = (struct spsc_node **)atomic_long_xchg(>tail,
(long)>next);
WRITE_ONCE(*tail, node);
atomic_inc(>job_count);
/*
*
On 21.08.23 18:36, Daniel Thompson wrote:
@@ -472,6 +472,14 @@ config BACKLIGHT_LED
If you have a LCD backlight adjustable by LED class driver, say Y
to enable this driver.
+config BACKLIGHT_HID
+ tristate "VESA VCP HID Backlight Driver"
+ depends on HID
+
On Wed, 23 Aug 2023 10:15:00 +0200, Krzysztof Kozlowski wrote:
> The panel-common schema does not define what "ports" property is, so
> bring the definition by referencing the panel-common-dual.yaml. Panels
> can be single- or dual-link, depending on the compatible, thus add
> if:then:else:
On Wed, Aug 23, 2023 at 10:14:59AM +0200, Krzysztof Kozlowski wrote:
> The panel-common schema does not define what "ports" property is, so
> bring the definition by referencing the panel-common-dual.yaml. Panels
> can be single- or dual-link, thus require only one port@0.
>
> Signed-off-by:
Fix the following warning:
Documentation/gpu/automated_testing.rst:55: WARNING: Inline emphasis
start-string without end-string.
Reported-by: Stephen Rothwell
Signed-off-by: Helen Koike
---
Patch for topic/drm-ci
V2:
- Fix typo s/scape/escape
---
Documentation/gpu/automated_testing.rst |
Fix the following warning:
Documentation/gpu/automated_testing.rst:55: WARNING: Inline emphasis
start-string without end-string.
Reported-by: Stephen Rothwell
Signed-off-by: Helen Koike
---
Patch for topic/drm-ci
---
Documentation/gpu/automated_testing.rst | 2 +-
1 file changed, 1
Merge all developer debug options available as separated module
parameters in one, making it obvious that are for developers.
Signed-off-by: André Almeida
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 24
drivers/gpu/drm/amd/include/amd_shared.h | 9 +
2 files
Create a module option to disable soft recoveries on amdgpu, making
every recovery go through the device reset path. This option makes
easier to force device resets for testing and debugging purposes.
Signed-off-by: André Almeida
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
As suggested by Christian at [0], this patchset merges all debug modules
parameters and creates a new one for disabling soft recovery:
> Maybe we can overload the amdgpu_gpu_recovery module option with this.
> Or even better merge all the developer module parameter into a
> amdgpu_debug option.
https://bugzilla.kernel.org/show_bug.cgi?id=201957
Priit O. (pr...@ww.ee) changed:
What|Removed |Added
CC||pr...@ww.ee
--- Comment #89
When a link-training attempt fails, emit a uevent to user space that
includes the trigger property, which in this case will be
link-statue=Bad.
This will allow userspace to parse the uevent property and better
understand the reason for the previous modeset failure.
Change-Id:
Currently, link-training fallback is only implemented for SST, so having
modeset_retry_work in intel_connector makes sense. However, we hope to
implement link training fallback for MST in a follow-up patchset, so
moving modeset_retry_work to indel_dp will make handling both SST and
MST connectors
Before sending a uevent to userspace in order to trigger a corrective
modeset, we change the failing connector's link-status to BAD. However,
the downstream MST branch ports are left in their original GOOD state.
This patch utilizes the drm helper function
drm_dp_set_mst_topology_link_status() to
Unlike SST, MST can support multiple displays connected to a single
connector. However, this also means that if the DisplayPort link to the
top-level MST branch device becomes unstable, then every single branch
device has an unstable link.
Since there are multiple downstream ports per connector,
Currently, MST link training has no fallback. This means that if an MST
base connector fails to link-train once, the training completely fails,
which makes this case significantly more common than a complete SST link
training failure.
Similar to the final failure state of SST, this patch zeros
Instead of silently giving up when all link-training fallback values are
exhausted, this patch modifies the fallback's failure branch to reduces
both max_link_lane_count and max_link_rate to zero (0) and continues to
emit uevents until userspace stops attempting to modeset.
By doing so, we ensure
Next version of https://patchwork.freedesktop.org/series/122643/
v3:
Still learning the ropes of upstream workflow. Apologies for mucking up v2.
This is just a re-upload.
v2:
Reorganize into:
1) Add for final failure state for SST and MST link training fallback.
2) Add a DRM helper for
Hi Daniel,
On Thu, Aug 24, 2023 at 5:12 PM Daniel Stone wrote:
> On Thu, 24 Aug 2023 at 16:09, Geert Uytterhoeven wrote:
> > struct drm_client_dev *client = buffer->client;
> > - struct drm_mode_fb_cmd fb_req = { };
> > - const struct drm_format_info *info;
> > +
Hi Geert,
On Thu, 24 Aug 2023 at 16:09, Geert Uytterhoeven wrote:
> struct drm_client_dev *client = buffer->client;
> - struct drm_mode_fb_cmd fb_req = { };
> - const struct drm_format_info *info;
> + struct drm_mode_fb_cmd2 fb_req = { };
> int ret;
>
> -
Hi all,
The native display format of ssd1306 OLED displays is monochrome
light-on-dark (R1). This patch series adds support for the R1 buffer
format to both the ssd130x DRM driver and the FB helpers, so monochrome
applications (including fbdev emulation and the text console) not only
drm_mode_create_dumb() calculates the number of characters per pixel
from the number of bits per pixel by rounding up, which is not correct
as the actual value of cpp may be non-integer. While we do not need to
care here about complex formats like YUV, bpp < 8 is a valid use case.
- The
The .need_pwm and .need_chargepump fields in struct ssd130x_deviceinfo
are flags that can have only two possible values: 0 and 1.
Reduce kernel size by changing their types from int to bool.
Signed-off-by: Geert Uytterhoeven
---
v2:
- New.
---
drivers/gpu/drm/solomon/ssd130x.h | 4 ++--
1
The native display format is R1. Hence change the preferred_depth and
preferred_bpp to 1, to avoid the overhead of using XR24 and the
associated conversions when using fbdev emulation and its text console.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Javier Martinez Canillas
Tested-by:
Currently drm_client_buffer_addfb() uses the legacy drm_mode_addfb(),
which uses bpp and depth to guess the wanted buffer format.
However, drm_client_buffer_addfb() already knows the exact buffer
format, so there is no need to convert back and forth between buffer
format and bpp/depth, and the
Due to the reuse of buffers, ssd130x_clear_screen() no longers clears
the screen, but merely redraws the last image that is residing in the
intermediate buffer.
As there is no point in clearing the intermediate buffer and transposing
an all-black image, fix this by just clearing the HW format
The native display format is monochrome light-on-dark (R1).
Hence add support for R1, so monochrome applications not only look
better, but also avoid the overhead of back-and-forth conversions
between R1 and XR24.
Do not allocate the intermediate conversion buffer when it is not
needed, and
drm_fb_helper_single_fb_probe() first calls drm_fb_helper_find_sizes(),
followed by drm_fbdev_generic_helper_fb_probe():
- The former tries to find a suitable buffer format, taking into
account limitations of the whole display pipeline,
- The latter just calls drm_mode_legacy_fb_format()
Add support for the monochrome light-on-dark buffer format (R1) to the
fb helper, so this format can be used for fbdev emulation and for the
text console. This avoids the overhead of using XR24 and the associated
conversions on display hardware that supports only a simple monochrome
format.
R1
Currently, the vga_is_firmware_default() function only works on x86 and
ia64, it is a no-op on the rest of the architectures. This patch completes
the implementation for it, the added code tries to capture the PCI (e) VGA
device that owns the firmware framebuffer address range before the PCI
Currently, the vga_is_firmware_default() function only works on x86 and
ia64, it is a no-op on the rest of the architectures. This patch completes
the implementation for it, the added code tries to capture the PCI (e) VGA
device that owns the firmware framebuffer, since only one GPU could own
the
The new implemented pci_boot_vga_capturer() function is also effective on
X86 and IA64, it can determine the default boot VGA device before VRAM BAR
relocations done by the PCI core. Since the fixup handler has already
identified the firmware framebuffer, there no need to look again later. So,
Applied. Thanks!
On Thu, Aug 24, 2023 at 4:35 AM Sharma, Shashank
wrote:
>
> [AMD Official Use Only - General]
>
> Reviewed-by: : Shashank Sharma
>
> Regards
> Shashank
> -Original Message-
> From: Lee Jones
> Sent: Thursday, August 24, 2023 9:37 AM
> To: l...@kernel.org
> Cc:
Applied. Thanks!
On Thu, Aug 24, 2023 at 3:38 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/imu_v11_0.c: In function
> ‘imu_v11_0_init_microcode’:
> drivers/gpu/drm/amd/amdgpu/imu_v11_0.c:52:54: warning: ‘_imu.bin’ directive
> output
Applied. Thanks!
On Thu, Aug 24, 2023 at 3:38 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c: In function
> ‘amdgpu_sdma_init_microcode’:
> drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c:217:64: warning: ‘.bin’ directive
>
Applied. Thanks!
On Thu, Aug 24, 2023 at 3:38 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c: In function
> ‘amdgpu_ras_sysfs_create’:
> drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:1406:20: warning: ‘_err_count’
> directive
Applied. Thanks!
On Thu, Aug 24, 2023 at 3:38 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:516: warning: Function parameter
> or member 'xcc_id' not described in 'amdgpu_mm_wreg_mmio_rlc'
>
> Signed-off-by: Lee Jones
Applied. Thanks!
On Thu, Aug 24, 2023 at 3:37 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/radeon/radeon_ttm.c: In function ‘radeon_bo_move’:
> drivers/gpu/drm/radeon/radeon_ttm.c:201:27: warning: variable ‘rbo’ set but
> not used
On 8/24/23 05:23, Matthew Brost wrote:
On Thu, Aug 24, 2023 at 02:08:59AM +0200, Danilo Krummrich wrote:
Hi Matt,
On 8/11/23 04:31, Matthew Brost wrote:
As a prerequisite to merging the new Intel Xe DRM driver [1] [2], we
have been asked to merge our common DRM scheduler patches first.
This
Applied. Thanks!
Alex
On Wed, Aug 23, 2023 at 5:50 AM Wang, Yang(Kevin)
wrote:
>
> [AMD Official Use Only - General]
>
> Reviewed-by: Yang Wang
>
> Best Regards,
> Kevin
>
> -Original Message-
> From: dri-devel On Behalf Of Colin
> Ian King
> Sent: Wednesday, August 23, 2023 5:03 PM
On Thu, Aug 24, 2023 at 01:44:41PM +0200, Christian König wrote:
> Am 24.08.23 um 01:12 schrieb Matthew Brost:
> > On Wed, Aug 23, 2023 at 01:26:09PM -0400, Rodrigo Vivi wrote:
> > > On Wed, Aug 23, 2023 at 11:41:19AM -0400, Alex Deucher wrote:
> > > > On Wed, Aug 23, 2023 at 11:26 AM Matthew
On Tue, Aug 22, 2023 at 9:35 AM Somalapuram, Amaranath wrote:
>
>
> On 8/21/2023 6:30 PM, Shashank Sharma wrote:
> > + Amar should be able to help.
> >
> > Amar,
> >
> > Can you please check this patch (series if required) with a few IGTs
> > and probably with Xonotic as well ?
> >
> Tested patch
On Tue, Aug 22, 2023 at 7:36 AM Sasha Levin wrote:
>
> From: Alex Deucher
>
> [ Upstream commit 616f92d188ee7142a95a52068efdbea82645f859 ]
>
> Use the dGPU path instead. There were a lot of platform
> issues with IOMMU in general on these chips due to windows
> not enabling IOMMU at the time.
In the drm subsystem, the source physical address is, in most cases,
available without having to parse the EDID again. Add notes about
preferring to use the pre-parsed address instead.
Cc: Hans Verkuil
Cc: linux-me...@vger.kernel.org
Signed-off-by: Jani Nikula
---
Avoid parsing the EDID again for source physical address. Also gets rids
of a few remaining raw EDID usages.
Cc: Hans Verkuil
Cc: linux-me...@vger.kernel.org
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dp.c | 7 ++-
drivers/gpu/drm/i915/display/intel_hdmi.c | 5
CEC needs the source physical address. Parsing it is trivial with the
existing EDID CEA DB infrastructure.
Default to CEC_PHYS_ADDR_INVALID (0x) instead of 0 to cater for
easier CEC usage.
Cc: Hans Verkuil
Cc: linux-me...@vger.kernel.org
Signed-off-by: Jani Nikula
---
Connectors have source physical address available in display
info. There's no need to parse the EDID again for this. Add
drm_dp_cec_attach() to do this.
Seems like the set_edid/unset_edid naming is a bit specific now that
there's no need to pass the EDID at all, so aim for attach/detach going
Checking edid->input & DRM_EDID_INPUT_DIGITAL is common enough to
deserve a helper that also lets us abstract the raw EDID a bit better.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 17 +++--
include/drm/drm_edid.h | 1 +
2 files changed, 16 insertions(+), 2
Reduce the use of struct edid and drm_edid_raw().
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_crt.c | 11 ---
drivers/gpu/drm/i915/display/intel_hdmi.c | 9 -
drivers/gpu/drm/i915/display/intel_sdvo.c | 7 ++-
3 files changed, 10 insertions(+), 17
Avoid accessing the raw edid directly. Pre-parse the source physical
address during normal EDID parsing and use that for CEC.
Jani Nikula (6):
drm/edid: add drm_edid_is_digital()
drm/i915/display: use drm_edid_is_digital()
drm/edid: parse source physical address
drm/cec: add
On Thu, Aug 24, 2023 at 01:01:24PM +0100, Lee Jones wrote:
> On Thu, 24 Aug 2023, Jani Nikula wrote:
>
> > On Thu, 24 Aug 2023, Thierry Reding wrote:
> > > On Thu, Aug 24, 2023 at 08:37:00AM +0100, Lee Jones wrote:
> > >> When converting from int to string, we must allow for up to 10-chars
> >
For DRM legacy gamma, AMD display manager applies implicit sRGB degamma
using a pre-defined sRGB transfer function. It works fine for DCN2
family where degamma ROM and custom curves go to the same color block.
But, on DCN3+, degamma is split into two blocks: degamma ROM for
pre-defined TFs and
Edid specific BPC constraints are stored in limits->max_bpp. Honor these
limits while computing the input bpp for DSC.
v2: Use int instead of u8 for computations. (Jani)
Add closes tag. (Ankit)
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9161
Signed-off-by: Ankit Nautiyal
As per DP v1.4, a DP DSC Sink device shall support 8bpc in DPCD 6Ah.
Apparently some panels that do support DSC, are not setting the bit for
8bpc.
So always assume 8bpc support by DSC decoder, when DSC is claimed to be
supported.
v2: Use helper to get check dsc support. (Ankit)
v3: Fix styling
Assume 8bpc is supported if Sink claims DSC support.
Also consider bpc constraint coming from EDID while computing
input BPC for DSC.
Rev2: Fix check for dsc support.
Rev3: Minor styling and typos fix.
Ankit Nautiyal (2):
drm/display/dp: Assume 8 bpc support when DSC is supported
Hi Lee,
On 8/24/23 09:37, Lee Jones wrote:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/drm_gpuva_mgr.c: In function ‘__drm_gpuva_sm_map’:
drivers/gpu/drm/drm_gpuva_mgr.c:1079:39: warning: variable ‘prev’ set but not
used [-Wunused-but-set-variable]
Thanks for fixing
Hi Dave and Daniel,
And this is our fixes targeting 6.5 (rc8?).
I'm again covering for Tvrtko at this round.
Please also notice that here we also have the drm
patches fixing the HPD polling that I had mentioned
in our next-fixes.
One is the fix itself and the other is a dependency
to add the
Hi Dave and Daniel,
Here goes our next-fixes targeting 6.6-rc1.
Please notice that we have 2 drm level patches there,
one to fix the display HPD polling and one dependency
introducing a helper to reschedule the poll work.
drm-intel-next-fixes-2023-08-24:
- Fix TLB invalidation (Alan)
- Fix
On Thu, 24 Aug 2023, Hamza Mahfooz wrote:
>
> On 8/24/23 08:07, Lee Jones wrote:
> > On Thu, 24 Aug 2023, Jani Nikula wrote:
> >
> > > On Thu, 24 Aug 2023, Lee Jones wrote:
> > > > This set is part of a larger effort attempting to clean-up W=1
> > > > kernel builds, which are currently
On 8/24/23 08:07, Lee Jones wrote:
On Thu, 24 Aug 2023, Jani Nikula wrote:
On Thu, 24 Aug 2023, Lee Jones wrote:
This set is part of a larger effort attempting to clean-up W=1
kernel builds, which are currently overwhelmingly riddled with
niggly little warnings.
The next question is, how
On Thu, 24 Aug 2023, Maxime Ripard wrote:
> Hi,
>
> On Thu, Aug 24, 2023 at 08:36:58AM +0100, Lee Jones wrote:
> > Fixes the following W=1 kernel build warning(s):
> >
> > drivers/gpu/drm/tests/drm_kunit_helpers.c:172: warning: expecting
> > prototype for
On Thu, 24 Aug 2023, Maxime Ripard wrote:
> Hi,
>
> On Thu, Aug 24, 2023 at 10:59:54AM +0200, Maxime Ripard wrote:
> > On Thu, 24 Aug 2023 08:36:45 +0100, Lee Jones wrote:
> > > This set is part of a larger effort attempting to clean-up W=1
> > > kernel builds, which are currently overwhelmingly
On Thu, 24 Aug 2023, Lee Jones wrote:
> On Thu, 24 Aug 2023, Jani Nikula wrote:
>
> > On Thu, 24 Aug 2023, Lee Jones wrote:
> > > This set is part of a larger effort attempting to clean-up W=1
> > > kernel builds, which are currently overwhelmingly riddled with
> > > niggly little warnings.
> >
1 - 100 of 175 matches
Mail list logo
