Hi,
Resurrecting an old series [1], now that we have an in-tree user for it.
For regular BAR, drivers can use pci_resize_resource to resize it to the
desired size provided that it is supported by the hardware, which the
driver can query using pci_rebar_get_possible_sizes.
This series expands the
Similar to regular resizable BAR, VF BAR can also be resized.
The structures are very similar, which means we can reuse most of the
implementation. See PCIe r4.0, sec 9.3.7.4.
Signed-off-by: Michał Winiarski
---
drivers/pci/iov.c | 28 ++
drivers/pci/pci.c
VF MMIO resource reservation, either created by system firmware and
inherited by Linux PCI subsystem or created by the subsystem itself,
contains enough space to fit the BAR of all SR-IOV Virtual Functions
that can potentially be created (total VFs supported by the device).
This can be leveraged wh
Am 20.09.24 um 04:27 schrieb WangYuli:
There are some spelling mistakes of 'acccess' in comments which
should be instead of 'access'.
And the comment style should be like this:
/*
* Text
* Text
*/
Suggested-by: Christian König
Link: https://lore.kernel.org/all/f75fbe30-528e-404f-97e
Hi Neil,
On 2024-09-13 10:02, Neil Armstrong wrote:
> On 08/09/2024 15:28, Jonas Karlman wrote:
>> Update successfully read EDID during hotplug processing to ensure the
>> connector diplay_info is always up-to-date.
>>
>> Signed-off-by: Jonas Karlman
>> ---
>> v2: No change
>> ---
>> drivers/gp
在 2024/9/20 03:01, Christian König wrote:
Am 19.09.24 um 20:28 schrieb WangYuli:
There are some spelling mistakes of 'acccess' in comments which
should be instead of 'access'.
Signed-off-by: WangYuli
---
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/gfx_v9_4
On Thu, 19 Sep 2024, Fangzhi Zuo wrote:
> [why]
> How we determine the dsc_aux used for dsc decompression in
> drm_dp_mst_dsc_aux_for_port() today having some defects:
>
> 1. The method how we determine a connected peer device is virtual or not
>in drm_dp_mst_is_virtual_dpcd() is not always co
On Thu, Sep 19, 2024 at 10:58 AM wrote:
>
> From: Hermes Wu
>
> Fix HDCP CTS items on UNIGRAF DPR-100.
>
> Signed-off-by: Hermes Wu
Reviewed-by: Pin-yen Lin
> ---
> drivers/gpu/drm/bridge/ite-it6505.c | 152 ++--
> 1 file changed, 101 insertions(+), 51 deletions(-)
>
>
On 9/6/2024 4:39 PM, Masahiro Yamada wrote:
On Fri, Sep 6, 2024 at 8:01 PM Daniel Gomez via B4 Relay
wrote:
From: Daniel Gomez
Use getprogname() [1] instead of program_invocation_short_name() [2]
for macOS hosts.
[1]:
https://www.gnu.org/software/gnulib/manual/html_node/
program_005finvocat
Hi Pierre-Eric,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-exynos/exynos-drm-next]
[also build test WARNING on drm-intel/for-linux-next
drm-intel/for-linux-next-fixes drm-misc/drm-misc-next drm-tip/drm-tip
linus/master v6.11 next-20240919]
[cannot
There are some spelling mistakes of 'acccess' in comments which
should be instead of 'access'.
And the comment style should be like this:
/*
* Text
* Text
*/
Suggested-by: Christian König
Link: https://lore.kernel.org/all/f75fbe30-528e-404f-97e4-854d27d7a...@amd.com/
Acked-by: Thomas Zimm
Hi Dave and Simona,
A few fixes for 6.11-rc1.
Thanks
Lucas De Marchi
drm-xe-next-fixes-2024-09-19:
Driver Changes:
- Fix macro for checking minimum GuC version (Michal Wajdeczko)
- Fix CCS offset calculation for some BMG SKUs (Matthew Auld)
- Fix locking on memory usage reporting via fdinfo and
Opt into extending the VF BAR.
LMEM is partitioned between multiple VFs, and we expect that the more
VFs we have, the less LMEM is assigned to each VF.
This means that we can achieve full LMEM BAR access without the need to
attempt full VF LMEM BAR resize via pci_resize_resource().
Signed-off-by:
From: John Harrison
The dump of the CT buffers was only showing the unprocessed data which
is not generally useful for saying why a hang occurred - because it
was probably caused by the commands that were just processed. So save
and dump the entire buffer but in a more compact dump format. Also
z
On Thu, Sep 19, 2024 at 09:27:52AM GMT, Stephen Rothwell wrote:
Hi all,
On Mon, 9 Sep 2024 19:59:39 +1000 Stephen Rothwell
wrote:
After merging the kspp tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/xe/xe_gt_idle.c:56:27: error: redefinition of 'str_
From: John Harrison
Include the GuC log in devcoredump captures because they can be useful
with debugging certain types of bug.
v2: Fix kerneldoc
v3: Drop module parameter as now using more compact ascii85 encoding
rather than hexdump (although still not compressed) (review feedback
from Matthew
From: "Dr. David Alan Gilbert"
backlight_register_notifier and backlight_unregister_notifier have
been unused since
commit 6cb634d0dc85 ("ACPI: video: Remove code to unregister acpi_video
backlight when a native backlight registers")
With those not being called, it means that the backlight_not
On Thu, Sep 19, 2024 at 09:56:47PM GMT, Lucas De Marchi wrote:
Hi Dave and Simona,
A few fixes for 6.11-rc1.
oops, I meant 6.12-rc1, of course :)
Lucas De Marchi
From: John Harrison
Add a worker function helper for asynchronously dumping state when an
internal/fatal error is detected in CT processing. Being asynchronous
is required to avoid deadlocks and scheduling-while-atomic or
process-stalled-for-too-long issues. Also check for a bunch more error
cond
From: Michal Wajdeczko
This drm printer wrapper can be used to increase the robustness of
the captured output generated by any other drm_printer to make sure
we didn't lost any intermediate lines of the output by adding line
numbers to each output line. Helpful for capturing some crash data.
v2:
From: John Harrison
Split the GuC log dump into a two stage snapshot and print mechanism.
This allows the log to be captured at the point of an error (which may
be in a restricted context) and then dump it out later (from a regular
context such as a worker function or a sysfs file handler).
Also
From: Michal Wajdeczko
This drm printer wrapper can be used to increase the robustness of
the captured output generated by any other drm_printer to make sure
we didn't lost any intermediate lines of the output by adding line
numbers to each output line. Helpful for capturing some crash data.
v2:
From: John Harrison
Add an extra stage to the GuC log print to copy the log buffer into
regular host memory first, rather than printing the live GPU buffer
object directly. Doing so helps prevent inconsistencies due to the log
being updated as it is being dumped. It also allows the use of the
ASC
From: John Harrison
Create a helper function that can be used to dump the GuC log to dmesg
in a manner that is reliable for extraction and decode. The intention
is that calls to this can be added by developers when debugging
specific issues that require a GuC log but do not allow easy capture
of
From: John Harrison
There is a debug mechanism for dumping the GuC log as an ASCII hex
stream via dmesg. This is extremely useful for situations where it is
not possibe to query the log from debugfs (self tests, bugs that cause
the driver to fail to load, system hangs, etc.). However, dumping via
On 2024/9/20 02:58, Thomas Zimmermann wrote:
Hi
Am 19.09.24 um 20:28 schrieb WangYuli:
There are some spelling mistakes of 'acccess' in comments which
should be instead of 'access'.
Signed-off-by: WangYuli
---
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/gfx
From: John Harrison
The xe_guc_exec_queue_snapshot is not really a GuC internal thing and
is definitely not a GuC CT thing. So give it its own section heading.
The snapshot itself is really a capture of the submission backend's
internal state. Although all it currently prints out is the submissio
From: John Harrison
Including line feeds at the start of a debug print messes up the
output when sent to dmesg. The break appears between all the useful
prefix information and the actual string being printed. In this case,
each block of data has a very clear start line and an extra delimeter
is r
From: John Harrison
There is a need to include the GuC log and other large binary objects
in core dumps and via dmesg. So add a helper for dumping to a printer
function via conversion to ASCII85 encoding.
Another issue with dumping such a large buffer is that it can be slow,
especially if dumpin
Please ignore, sent to the wrong mailing list!
John.
From: John Harrison
There are a bunch of calls to drm_printf with static strings. Switch
them to drm_puts instead.
There are also a bunch of 'coredump->snapshot.XXX' references when
'coredump->snapshot' has alread been cached locally as 'ss'. So use
'ss->XXX' instead.
Signed-off-by: John Harris
Il 17/09/24 19:34, Markus Elfring ha scritto:
From: Markus Elfring
Date: Tue, 17 Sep 2024 19:16:45 +0200
A few update suggestions were taken into account
from static source code analysis.
Hello Markus,
In my opinion, the suggested changes aren't bringing any improvement, not
in readability n
> > + pmic@60 {
> > + compatible = "samsung,s2dos05";
> > + reg = <0x60>;
> > +
> > + regulators {
> > + s2dos05_ldo1: ldo1 {
> > + regulator-active-discharge = <1
On Thu, Sep 19, 2024 at 09:55:54AM +, Winkler, Tomas wrote:
> > On Mon, Sep 16, 2024 at 04:49:18PM +0300, Alexander Usyskin wrote:
> > > In intel-dg spi, there is no access to the spi controller, the
> > > information is extracted from the descriptor region.
> > Which information? I can't te
On Thu, Sep 19, 2024 at 09:54:24AM +, Winkler, Tomas wrote:
> > On Mon, Sep 16, 2024 at 04:49:17PM +0300, Alexander Usyskin wrote:
> > > @@ -0,0 +1,142 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/*
> > > + * Copyright(c) 2019-2024, Intel Corporation. All rights reserved.
> > > + */
On Sat, Aug 31, 2024 at 09:06:51PM GMT, Stephen Boyd wrote:
> Extend the usb-switch binding to support DisplayPort (DP) alternate
> modes. A third port for the DP signal is necessary when a mode-switch is
> muxing USB and DP together onto a usb type-c connector. Add data-lanes
> to the usbc output
On Thu, Sep 19, 2024 at 10:01:06AM +, Winkler, Tomas wrote:
> > On Mon, Sep 16, 2024 at 04:49:20PM +0300, Alexander Usyskin wrote:
> > > +static int intel_dg_spi_write(struct mtd_info *mtd, loff_t to, size_t
> > > len,
> > > + size_t *retlen, const u_char *buf) {
> > > +
On Thu, 19 Sept 2024 at 09:48, Dave Airlie wrote:
>
> There are some minor conflicts with your tree but none seemed too
> difficult to solve, let me know if there is any problems on your end.
Christ. One of them is due to you guys being horrible at merging.
Your tree had
drm/xe/gt: Remove d
On Tue, 17 Sep 2024, Raag Jadav wrote:
> Introduce device wedged event, which will notify userspace of wedged
> (hanged/unusable) state of the DRM device through a uevent. This is
> useful especially in cases where the device is no longer operating as
> expected and has become unrecoverable from d
On Wed, Sep 18, 2024 at 04:01:16PM +0530, Manikandan Muralidharan wrote:
> Add the 'sam9x75-mipi-dsi' compatible binding, which describes the
> Microchip's specific wrapper for the Synopsys DesignWare MIPI DSI HOST
> Controller for the sam9x75 series System-on-Chip (SoC) devices.
>
> Signed-off-by
Tzung-Bi Shih writes:
Hello Tzung-Bi,
> On Mon, Sep 16, 2024 at 01:00:24PM +0200, Javier Martinez Canillas wrote:
>> The patches have only been compiled tested because I don't have access to
>> a coreboot machine. Please let me know if you plan to merge both patches
>> through the chrome-platfor
On 18/09/2024 14:53, Dzmitry Sankouski wrote:
> пн, 16 сент. 2024 г. в 12:10, Krzysztof Kozlowski :
>>
>> On Fri, Sep 13, 2024 at 06:07:51PM +0300, Dzmitry Sankouski wrote:
>>> Remove `enum max77693_irq_source` declaration because unused.
>>>
>>> Signed-off-by: Dzmitry Sankouski
>>> ---
>>> inclu
On 19/09/2024 10:40, Dzmitry Sankouski wrote:
> чт, 19 сент. 2024 г. в 10:00, Krzysztof Kozlowski :
>>
>> On 18/09/2024 14:53, Dzmitry Sankouski wrote:
>>> пн, 16 сент. 2024 г. в 12:10, Krzysztof Kozlowski :
On Fri, Sep 13, 2024 at 06:07:51PM +0300, Dzmitry Sankouski wrote:
> Remove `
Le 16/09/2024 à 16:35, Tvrtko Ursulin a écrit :
On 16/09/2024 14:32, Pierre-Eric Pelloux-Prayer wrote:
Giving the opportunity to userspace to associate a free-form
name with a drm_file struct is helpful for tracking and debugging.
This is similar to the existing DMA_BUF_SET_NAME ioctl.
Acc
On 19/09/2024 15:17, Dzmitry Sankouski wrote:
>>> + pmic@60 {
>>> + compatible = "samsung,s2dos05";
>>> + reg = <0x60>;
>>> +
>>> + regulators {
>>> + s2dos05_ldo1: ldo1 {
>>> +
On Thu, 19 Sep 2024, Raag Jadav wrote:
> On Tue, Sep 17, 2024 at 10:49:07AM +0300, Jani Nikula wrote:
>> On Tue, 17 Sep 2024, Raag Jadav wrote:
>> > Now that we have device wedged event in place, add wedge_recovery sysfs
>> > attribute which will expose recovery methods supported by the DRM devic
On Mon, Sep 16, 2024 at 01:00:24PM +0200, Javier Martinez Canillas wrote:
> The patches have only been compiled tested because I don't have access to
> a coreboot machine. Please let me know if you plan to merge both patches
> through the chrome-platforms tree or if you prefer to get merged through
On 8/29/2024 16:11, Lu Yao wrote:
On 2024/8/22 22:05, Mario Limonciello wrote:
On 7/23/2024 04:42, Lu Yao wrote:
[Why]
When running kdump test on a machine with R7340 card, a hang is caused due
to the failure of 'amdgpu_device_ip_init()', error message as follows:
'[drm:amdgpu_device_ip_
From: Hermes Wu
Fix HDCP CTS items on UNIGRAF DPR-100.
Signed-off-by: Hermes Wu
---
drivers/gpu/drm/bridge/ite-it6505.c | 152 ++--
1 file changed, 101 insertions(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ite-it6505.c
b/drivers/gpu/drm/bridge/ite-it6505.
Hi Dave & Sima,
Here goes drm-intel-next-fixes PR towards 6.12.
Three display fixes; One to limit BMG to UHBR13.5 and two PSR ones.
Regards, Joonas
***
drm-intel-next-fixes-2024-09-19:
- Fix BMG support to UHBR13.5
- Two PSR fixes
The following changes since commit bf05aeac230e390a5aee4bd3dc
>
> On Mon, Sep 16, 2024 at 04:49:17PM +0300, Alexander Usyskin wrote:
>
> > Add auxiliary driver for intel discrete graphics on-die spi device.
>
> This doesn't actually do anything AFAICT? It doesn't register with any
> subsystem or anything. Please don't submit empty boilerplate like this
>
> On Mon, Sep 16, 2024 at 04:49:18PM +0300, Alexander Usyskin wrote:
>
> > In intel-dg spi, there is no access to the spi controller, the
> > information is extracted from the descriptor region.
>
> Which information? I can't tell what this patch is supposed to do; as with
> the
> first patc
>
> On Mon, Sep 16, 2024 at 04:49:20PM +0300, Alexander Usyskin wrote:
>
> > From: Tomas Winkler
> >
> > Register the on-die spi device with the mtd subsystem.
> > Refcount spi object on _get and _put mtd callbacks.
>
> This is a MTD driver, it should be in drivers/mtd.
Okay.
>
> > +static
On Thu, Sep 19, 2024 at 12:24:09PM +0300, Jani Nikula wrote:
> On Thu, 19 Sep 2024, Raag Jadav wrote:
> > On Thu, Sep 19, 2024 at 10:38:51AM +0300, Jani Nikula wrote:
> >> On Thu, 19 Sep 2024, Raag Jadav wrote:
> >> > On Tue, Sep 17, 2024 at 10:49:07AM +0300, Jani Nikula wrote:
> >> >> On Tue, 17
Le 17/09/24 - 18:02, José Expósito a écrit :
> Hey Louis,
>
> > Currently drm_writeback_connector are created by
> > drm_writeback_connector_init or drm_writeback_connector_init_with_encoder.
> > Both of the function uses drm_connector_init and drm_encoder_init, but
> > there is no way to properly
On Thu, 19 Sep 2024, Raag Jadav wrote:
> On Thu, Sep 19, 2024 at 10:38:51AM +0300, Jani Nikula wrote:
>> On Thu, 19 Sep 2024, Raag Jadav wrote:
>> > On Tue, Sep 17, 2024 at 10:49:07AM +0300, Jani Nikula wrote:
>> >> On Tue, 17 Sep 2024, Raag Jadav wrote:
>> >> >
>> >> > +extern const char *con
The pull request you sent on Thu, 19 Sep 2024 17:48:14 +1000:
> https://gitlab.freedesktop.org/drm/kernel.git tags/drm-next-2024-09-19
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/de848da12f752170c2ebe114804a985314fd5a6a
Thank you!
--
Deet-doot-dot, I am a bot.
ht
On Thu, 19 Sep 2024, Raag Jadav wrote:
> On Thu, Sep 19, 2024 at 12:24:09PM +0300, Jani Nikula wrote:
>> On Thu, 19 Sep 2024, Raag Jadav wrote:
>> > On Thu, Sep 19, 2024 at 10:38:51AM +0300, Jani Nikula wrote:
>> >> On Thu, 19 Sep 2024, Raag Jadav wrote:
>> >> > On Tue, Sep 17, 2024 at 10:49:07A
On Sat, Aug 31, 2024 at 09:06:41PM GMT, Stephen Boyd wrote:
> Ease driver development by adding stubs for the typec_switch APIs when
> CONFIG_TYPEC=n. Copy the same method used for the typec_mux APIs to be
> consistent.
>
> Cc: Heikki Krogerus
> Cc: Greg Kroah-Hartman
> Cc:
> Cc: Pin-yen Lin
>
Hi,
Am Dienstag, 27. August 2024, 05:03:56 CEST schrieb Jinjie Ruan:
> Avoid need to manually handle of_node_put() by using __free(), and use
> dev_err() to replace deprecated() DRM_DEV_ERROR(), which can simplfy
> code.
please make that two separate commits, one for the dev_err conversion
and on
Hi,
Am Freitag, 30. August 2024, 09:34:54 CEST schrieb Jinjie Ruan:
> Avoids the need for manual cleanup of_node_put() in early exits
> from the loop.
>
> Signed-off-by: Jinjie Ruan
> Reviewed-by: Heiko Stuebner
> ---
> v2:
> - Add Reviewed-by.
> - Split out from the PATCH set.
This patch also
On Sun, 8 Sep 2024 14:54:57 +, Jonas Karlman wrote:
> This prepares and enable use of HDMI2.0 modes, e.g. 4K@60Hz, on RK3228,
> RK3328, RK3399 and RK356x. Support for 10-bit and/or YUV output modes is
> not part of this series.
>
> Patch 1 add hdmiphy rate validation in mode_valid so that HDMI
On 9/19/2024 11:03, Alex Hung wrote:
A minor comment (see inline below).
Otherwise
Reviewed-by: Alex Hung
On 2024-09-18 15:38, Mario Limonciello wrote:
Some manufacturers have intentionally put an EDID that differs from
the EDID on the internal panel on laptops.
Attempt to fetch this EDID i
A minor comment (see inline below).
Otherwise
Reviewed-by: Alex Hung
On 2024-09-18 15:38, Mario Limonciello wrote:
Some manufacturers have intentionally put an EDID that differs from
the EDID on the internal panel on laptops.
Attempt to fetch this EDID if it exists and prefer it over the EDI
On Thu, Sep 19, 2024 at 12:06 PM Mario Limonciello
wrote:
>
> On 9/19/2024 11:03, Alex Hung wrote:
> > A minor comment (see inline below).
> >
> > Otherwise
> >
> > Reviewed-by: Alex Hung
> >
> > On 2024-09-18 15:38, Mario Limonciello wrote:
> >> Some manufacturers have intentionally put an EDID
+dri-devel
For those joining late; this is the full series for context.
https://lore.kernel.org/linux-pm/20240919171952.403745-1-l...@antheas.dev/T/#maee308be5349d8df25c8ccf12144ea96bbd4cbbd
On 9/19/2024 12:19, Antheas Kapenekakis wrote:
Currently, the screen off/on calls are handled within th
On 9/19/24 13:29, Alex Deucher wrote:
On Thu, Sep 19, 2024 at 12:06 PM Mario Limonciello
wrote:
On 9/19/2024 11:03, Alex Hung wrote:
A minor comment (see inline below).
Otherwise
Reviewed-by: Alex Hung
On 2024-09-18 15:38, Mario Limonciello wrote:
Some manufacturers have intentionally pu
[why]
How we determine the dsc_aux used for dsc decompression in
drm_dp_mst_dsc_aux_for_port() today having some defects:
1. The method how we determine a connected peer device is virtual or not
in drm_dp_mst_is_virtual_dpcd() is not always correct. There are DP1.4
products
in the market wh
> > diff --git a/include/linux/regulator/s2dos05.h
> > b/include/linux/regulator/s2dos05.h
> > new file mode 100644
> > index ..2e89fcbce769
> > --- /dev/null
> > +++ b/include/linux/regulator/s2dos05.h
> > @@ -0,0 +1,73 @@
> > +/* SPDX-License-Identifier: GPL-2.0+ */
>
> Are you sure
On Tue, Sep 17, 2024 at 12:14 PM Antonino Maniscalco
wrote:
>
> Add documentation about the preemption feature supported by the msm
> driver.
>
> Signed-off-by: Antonino Maniscalco
> ---
> Documentation/gpu/msm-preemption.rst | 98
>
> 1 file changed, 98 ins
On Sun, 15 Sep 2024 15:39:43 +0300, Andrew Kreimer wrote:
> Fix a typo in comments.
>
>
Applied, thanks!
[1/1] drm/rockchip: Fix a typo
commit: 87d45979140e49611696e97e2b33df572bf4fa24
Best regards,
--
Heiko Stuebner
On 9/18/2024 5:41 PM, Konrad Dybcio wrote:
On 18.09.2024 5:52 PM, Jeffrey Hugo wrote:
The Sahara protocol has a crashdump functionality. In the hello
exchange, the device can advertise it has a memory dump available for
the host to collect. Instead of the device making requests of the host,
the
Hi Christian,
Ping?
/Thomas
On Thu, 2024-09-12 at 15:40 +0200, Thomas Hellström wrote:
> Hi, Christian,
>
> On Wed, 2024-09-04 at 12:47 +0200, Christian König wrote:
> > Am 04.09.24 um 10:54 schrieb Thomas Hellström:
> > > On Wed, 2024-09-04 at 10:50 +0200, Christian König wrote:
> > > > Am 04
Am Dienstag, 27. August 2024, 05:03:57 CEST schrieb Jinjie Ruan:
> Use dev_err_probe to replace deprecated() DRM_DEV_ERROR(), which
> can simplfy code.
>
> Signed-off-by: Jinjie Ruan
> ---
> drivers/gpu/drm/rockchip/rockchip_lvds.c | 30 +---
> 1 file changed, 11 insertions(+
On 19.09.2024 5:00 PM, Jeffrey Hugo wrote:
> On 9/18/2024 5:41 PM, Konrad Dybcio wrote:
>> On 18.09.2024 5:52 PM, Jeffrey Hugo wrote:
>>> The Sahara protocol has a crashdump functionality. In the hello
>>> exchange, the device can advertise it has a memory dump available for
>>> the host to collect
From: Nikita Zhandarovich
commit 5b511572660190db1dc8ba412efd0be0d3781ab6 upstream.
On the off chance that clock value ends up being too high (by means
of skl_ddi_calculate_wrpll() having been called with big enough
value of crtc_state->port_clock * 1000), one possible consequence
may be that th
This patch addresses issues of integer overflow and possibly erroneous
integer promotion in skl_ddi_calculate_wrpll() and
skl_ddi_hdmi_pll_dividers() in kernel versions 5.10 and 5.15.
The problem has been fixed in upstream and stable versions up to 6.1
with commit:
5b5115726601 ("drm/i915: Fix pos
On Thu, Sep 19, 2024 at 06:56:39AM +, Usyskin, Alexander wrote:
> > On Mon, Sep 16, 2024 at 04:49:16PM +0300, Alexander Usyskin wrote:
> > As far as I can tell this does not actually provide a SPI driver, there
> > is no call to any SPI API that I've noticed here. The SPI framework
> > does h
Add support for Microchip AC69T88A 5 inch TFT LCD 800x480
Display module with LVDS interface.The panel uses the Sitronix
ST7262 800x480 Display driver
Signed-off-by: Manikandan Muralidharan
Signed-off-by: Dharma Balasubiramani
---
changes in v2:
- replace microchip,ac69t88a-lvds-panel with
micro
Add Microchip AC69T88A 5" LVDS interface (800x480) TFT LCD panel
compatible string
Signed-off-by: Manikandan Muralidharan
---
changes in v2:
- Replace microchip,ac69t88a-lvds-panel with
microchip,ac69t88a
---
.../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
1 file changed,
QXL supports the drm_panic module, which displays a message to the
screen when a kernel panic occurs.
Signed-off-by: Ryosuke Yasuoka
---
v2
In [1], Jocelyn gives me feedbacks and fix them.
1. Removing qxl_surface_evict(): It takes a mutex and it possibly
causes deadlock in panic handler. As the p
чт, 19 сент. 2024 г. в 10:00, Krzysztof Kozlowski :
>
> On 18/09/2024 14:53, Dzmitry Sankouski wrote:
> > пн, 16 сент. 2024 г. в 12:10, Krzysztof Kozlowski :
> >>
> >> On Fri, Sep 13, 2024 at 06:07:51PM +0300, Dzmitry Sankouski wrote:
> >>> Remove `enum max77693_irq_source` declaration because unus
On Thu, Sep 19, 2024 at 10:38:51AM +0300, Jani Nikula wrote:
> On Thu, 19 Sep 2024, Raag Jadav wrote:
> > On Tue, Sep 17, 2024 at 10:49:07AM +0300, Jani Nikula wrote:
> >> On Tue, 17 Sep 2024, Raag Jadav wrote:
> >> > Now that we have device wedged event in place, add wedge_recovery sysfs
> >> >
Hi,
It's just a friendly reminder.
Anastasia Belova
10/09/24 18:16, Anastasia Belova пишет:
Switch to a managed drm device to cleanup some error handling
and make future work easier.
Fix dereference of NULL in meson_drv_bind_master by removing
drm_dev_put(drm) before meson_encoder_*_remove an
On Tue, Sep 17, 2024 at 10:53:10AM +0200, Luca Ceresoli wrote:
> led-backlight is a consumer of one or multiple LED class devices, but no
> devlink is created for such supplier-producer relationship. One consequence
> is that removal ordered is not correctly enforced.
>
> Issues happen for example
пн, 16 сент. 2024 г. в 12:14, Krzysztof Kozlowski :
>
> On Fri, Sep 13, 2024 at 06:07:49PM +0300, Dzmitry Sankouski wrote:
> > Add samsung,s2dos05 MFD module binding.
> >
> > Signed-off-by: Dzmitry Sankouski
> >
> > ---
> > Changes in v4:
> > - split long(>80) lines
> > - fix indentation
> > - mer
On Thu, Sep 19, 2024 at 12:00:33PM GMT, Ekansh Gupta wrote:
>
>
> On 8/30/2024 3:03 PM, Dmitry Baryshkov wrote:
> > On Thu, Aug 22, 2024 at 04:29:33PM GMT, Ekansh Gupta wrote:
> >> If multiple dma handles are passed with same fd over a remote call
> >> the kernel driver takes a reference and expe
Histogram added as part of i915/display driver. Adding the same for xe
as well.
Signed-off-by: Arun R Murthy
---
drivers/gpu/drm/xe/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/xe/Makefile b/drivers/gpu/drm/xe/Makefile
index edfd812e0f41..2a5e3ed5ea17 100644
--- a
Upon enabling histogram an interrupt is trigerred after the generation
of the statistics. This patch registers the histogram interrupt and
handles the interrupt.
v2: Added intel_crtc backpointer to intel_histogram struct (Jani)
Removed histogram_wq and instead use dev_priv->unodered_eq (Jani)
In Display 20+, new registers are added for setting index, reading
histogram and writing the IET.
v2: Removed duplicate code (Jani)
v3: Moved histogram core changes to earlier patches (Jani/Suraj)
Signed-off-by: Arun R Murthy
---
.../gpu/drm/i915/display/intel_histogram.c| 111 +
The delay counter for histogram does not reset and as a result the
histogram bin never gets updated. Workaround would be to use save and
restore histogram register.
HSD: 14014889975
Signed-off-by: Arun R Murthy
---
drivers/gpu/drm/i915/display/intel_histogram.c | 17 +
.../gpu/d
Display histogram is a hardware functionality where a statistics for 'x'
number of frames is generated to form a histogram data. This is notified
to the user via histogram event. Compositor will then upon sensing the
histogram event will read the histogram data from KMD via crtc property.
A library
CRTC properties have been added for enable/disable histogram, reading
the histogram data and writing the IET data.
"HISTOGRAM_EN" is the crtc property to enable/disable the global
histogram and takes a value 0/1 accordingly.
"Histogram" is a crtc property to read the binary histogram data.
"Global
Statistics is generated from the image frame that is coming to display
and an event is sent to user after reading this histogram data.
This statistics/histogram is then shared with the user upon getting a
request from user. User can then use this histogram and generate an
enhancement factor. This e
On Thu, Sep 19, 2024 at 11:38:50AM +0300, Raag Jadav wrote:
> On Thu, Sep 19, 2024 at 10:38:51AM +0300, Jani Nikula wrote:
...
> Anyway, would you prefer strlcat instead?
FYI: strl*() are subject to remove. They are bad, no-one should really prefer
them in the Linux kernel.
--
With Best Regard
On 9/19/2024 12:36, Hamza Mahfooz wrote:
On 9/19/24 13:29, Alex Deucher wrote:
On Thu, Sep 19, 2024 at 12:06 PM Mario Limonciello
wrote:
On 9/19/2024 11:03, Alex Hung wrote:
A minor comment (see inline below).
Otherwise
Reviewed-by: Alex Hung
On 2024-09-18 15:38, Mario Limonciello wrote:
Hi all,
I'd like to discuss a potential opportunity to enhance the `vrr_enabled`
property of `drm_crtc_state`. Currently, this property is a Boolean flag, but
this exposes some ambiguity and potential disconnect between client and
driver/display behavior. Namely, it's unclear to the client wheth
On 9/4/2024 8:26 PM, Dmitry Baryshkov wrote:
On the SDM845 platform ther are no LM_3 and LM_4 blocks. Drop them from
the SDM845 catalog.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h | 12 -
In DP alt mode, when pin assignment is D, only one PHY lane is owned
by the display. intel_cx0pll_enable currently performs a power state
ready on both the lanes in all cases.
Address the todo to perfom power state ready on owned lanes.
Tested on Meteor Lake-P [Intel Arc Graphics] with DP alt mod
There are some spelling mistakes of 'acccess' in comments which
should be instead of 'access'.
Signed-off-by: WangYuli
---
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c | 2 +-
drivers/leds/rgb/leds-group-multicolor.c | 2 +-
3 files changed, 3 inserti
1 - 100 of 108 matches
Mail list logo
