Hi Maíra,
Am 16.04.24 um 03:02 schrieb Maíra Canal:
On 4/15/24 13:54, Andre Przywara wrote:
On Mon, 15 Apr 2024 13:00:39 -0300
Maíra Canal wrote:
Hi,
RPi 0-3 is packed with a GPU that provides 3D rendering capabilities to
the RPi. Currently, the downstream kernel uses an overlay to enable
On Tue, Apr 16, 2024 at 03:52:40AM +, Zhu Wang wrote:
> From: Nicholas Kazlauskas
>
> stable inclusion
> from stable-v6.7.3
> commit 2ef98c6d753a744e333b7e34b9cf687040fba57d
> category: bugfix
> bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9BV4C
> CVE: CVE-2023-52624
>
>
On Tue, Apr 16, 2024 at 02:43:47AM +, Zhu Wang wrote:
> From: Nicholas Kazlauskas
>
> stable inclusion
> from stable-v6.7.3
> commit2ef98c6d753a7 ("drm/amd/display: Wake DMCUB before executing
> GPINT commands")
> category: bugfix
> bugzilla:
On Mon, 15 Apr 2024 16:35:02 -0700, Armin Wolf wrote:
>
Hi Armin,
> Am 16.04.24 um 00:36 schrieb Ashutosh Dixit:
> > @@ -818,10 +818,10 @@ void i915_hwmon_register(struct drm_i915_private
> > *i915)
> > hwm_get_preregistration_info(i915);
> >
> > /* hwmon_dev points to device hwmon */
From: Nicholas Kazlauskas
stable inclusion
from stable-v6.7.3
commit 2ef98c6d753a744e333b7e34b9cf687040fba57d
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9BV4C
CVE: CVE-2023-52624
Reference:
When both hwmon and hwmon drvdata (on which hwmon depends) are device
managed resources, the expectation, on device unbind, is that hwmon will be
released before drvdata. However, in i915 there are two separate code
paths, which both release either drvdata or hwmon and either can be
released
When both hwmon and hwmon drvdata (on which hwmon depends) are device
managed resources, the expectation, on device unbind, is that hwmon will be
released before drvdata. However, in i915 there are two separate code
paths, which both release either drvdata or hwmon and either can be
released
From: Nicholas Kazlauskas
stable inclusion
from stable-v6.7.3
commit 2ef98c6d753a7 ("drm/amd/display: Wake DMCUB before executing GPINT
commands")
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9BV4C
CVE: CVE-2023-52624
Reference:
This patch does not apply to amd-staging-drm-next. This is against a
DKMS branch and should be reviewed on our internal mailing list.
However, I suspect that part of the problem is, that the DKMS branch has
diverged quite a bit in this area, and is missing at least one patch
from me that was
On Mon, Apr 15, 2024 at 05:49:33PM -0400, Nícolas F. R. A. Prado wrote:
> Given that failing to find a DSI host causes the driver to defer probe,
> make use of dev_err_probe() to log the reason. This makes the defer
> probe reason available and avoids alerting userspace about something
> that is
On Mon, Apr 15, 2024 at 05:49:32PM -0400, Nícolas F. R. A. Prado wrote:
> Given that failing to find a DSI host causes the driver to defer probe,
> make use of dev_err_probe() to log the reason. This makes the defer
> probe reason available and avoids alerting userspace about something
> that is
On Mon, Apr 15, 2024 at 09:53:09PM +0200, Janusz Krzysztofik wrote:
> We defer actually closing, unbinding and destroying a VMA until next idle
> point, or until the object is freed in the meantime. By postponing the
> unbind, we allow for the VMA to be reopened by the client, avoiding the
> work
On 4/15/24 13:54, Andre Przywara wrote:
On Mon, 15 Apr 2024 13:00:39 -0300
Maíra Canal wrote:
Hi,
RPi 0-3 is packed with a GPU that provides 3D rendering capabilities to
the RPi. Currently, the downstream kernel uses an overlay to enable the
GPU and use GPU hardware acceleration. When
On Mon, Apr 15, 2024 at 01:21:47PM +0200, Maxime Ripard wrote:
> On Wed, Apr 10, 2024 at 07:06:39PM +0100, Mark Brown wrote:
> > Is there any news on getting the rest of this merged? It's been more
> > than a week now and the Designware display controllers are all still
> > broken in -next,
On 4/15/2024 9:10 AM, David Wronek wrote:
Add support for the 2560x1600@90Hz OLED panel by EDO bundled with a
Raydium RM69380 controller, as found on the Lenovo Xiaoxin Pad Pro 2021.
Signed-off-by: David Wronek
---
drivers/gpu/drm/panel/Kconfig | 14 +
Am 16.04.24 um 00:36 schrieb Ashutosh Dixit:
When both hwmon and hwmon drvdata (on which hwmon depends) are device
managed resources, the expectation, on device unbind, is that hwmon will be
released before drvdata. However, in i915 there are two separate code
paths, which both release either
tree: git://anongit.freedesktop.org/drm/drm-misc for-linux-next
head: 7b0062036c3b71b4a69e244ecf0502c06c4cf5f0
commit: 879b3b6511fe92b1b93dfc543961347289a8aeaa [5/9] drm/fb_dma: Add generic
get_scanout_buffer() for drm_panic
config: riscv-defconfig
When both hwmon and hwmon drvdata (on which hwmon depends) are device
managed resources, the expectation, on device unbind, is that hwmon will be
released before drvdata. However, in i915 there are two separate code
paths, which both release either drvdata or hwmon and either can be
released
On 2024-04-15 04:19, Pekka Paalanen wrote:
On Fri, 12 Apr 2024 16:14:28 -0400
Leo Li wrote:
On 2024-04-12 11:31, Alex Deucher wrote:
On Fri, Apr 12, 2024 at 11:08 AM Pekka Paalanen
wrote:
On Fri, 12 Apr 2024 10:28:52 -0400
Leo Li wrote:
On 2024-04-12 04:03, Pekka Paalanen wrote:
On Thu, Apr 11, 2024 at 10:22 PM Zack Rusin wrote:
>
> - with stdu what happens when the mode selected is close to our
> limits, the guest is using a hardware cursor and we allocate cursor
> mobs?
With overcommit (cfdc3458db8a1620b1e307e3cb07480a161146ab) it won't be
an issue. Before overcommit
Given that failing to find a DSI host causes the driver to defer probe,
make use of dev_err_probe() to log the reason. This makes the defer
probe reason available and avoids alerting userspace about something
that is not necessarily an error.
Suggested-by: AngeloGioacchino Del Regno
Given that failing to find a DSI host causes the driver to defer probe,
make use of dev_err_probe() to log the reason. This makes the defer
probe reason available and avoids alerting userspace about something
that is not necessarily an error.
Also move the "failed to attach" error message so that
Given that failing to find a DSI host causes the driver to defer probe,
make use of dev_err_probe() to log the reason. This makes the defer
probe reason available and avoids alerting userspace about something
that is not necessarily an error.
Fixes: 623a3531e9cf ("drm/panel: Add driver for
Given that failing to find a DSI host causes the driver to defer probe,
make use of dev_err_probe() to log the reason. This makes the defer
probe reason available and avoids alerting userspace about something
that is not necessarily an error.
Fixes: b26975593b17 ("display/drm/bridge: TC358775
Given that failing to find a DSI host causes the driver to defer probe,
make use of dev_err_probe() to log the reason. This makes the defer
probe reason available and avoids alerting userspace about something
that is not necessarily an error.
Fixes: 0cbbd5b1a012 ("drm: bridge: add support for
Given that failing to find a DSI host causes the driver to defer probe,
make use of dev_err_probe() to log the reason. This makes the defer
probe reason available and avoids alerting userspace about something
that is not necessarily an error.
Fixes: 23278bf54afe ("drm/bridge: Introduce LT9611 DSI
Given that failing to find a DSI host causes the driver to defer probe,
make use of dev_err_probe() to log the reason. This makes the defer
probe reason available and avoids alerting userspace about something
that is not necessarily an error.
Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B
Given that failing to find a DSI host causes the driver to defer probe,
make use of dev_err_probe() to log the reason. This makes the defer
probe reason available and avoids alerting userspace about something
that is not necessarily an error.
Fixes: 8dde6f7452a1 ("drm: bridge: icn6211: Add I2C
e() helper.
Changes in v3:
- Added trailers
- Rebased on next-20240415
- Link to v2:
https://lore.kernel.org/r/20240229-anx7625-defer-log-no-dsi-host-v2-0-005069410...@collabora.com
Changes in v2:
- Added patches 2 onwards to fix all occurences of this pattern instead
of just for the anx7625
Given that failing to find a DSI host causes the driver to defer probe,
make use of dev_err_probe() to log the reason. This makes the defer
probe reason available and avoids alerting userspace about something
that is not necessarily an error.
Fixes: 269332997a16 ("drm/bridge: anx7625: Return
Dne sreda, 3. april 2024 ob 12:56:23 GMT +2 je Maxime Ripard napisal(a):
> Commit 4fc8cb47fcfd ("drm/display: Move HDMI helpers into display-helper
> module") turned the DRM_DW_HDMI dependency of DRM_SUN8I_DW_HDMI into a
> depends on which ended up disabling the driver in the defconfig. Make
>
Dne sreda, 3. april 2024 ob 17:31:47 GMT +2 je Frank Oltmanns napisal(a):
> Dear clk and sunxi-ng maintainers,
>
> Patches 1-4 have been reviewed and there are no pending issues. If there
> is something else you need me to do to get this applied, please let me
> know.
Sorry for late patch merge.
We defer actually closing, unbinding and destroying a VMA until next idle
point, or until the object is freed in the meantime. By postponing the
unbind, we allow for the VMA to be reopened by the client, avoiding the
work required to rebind the VMA.
It was assumed that as long as a GT is held
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 6bd343537461b57f3efe5dfc5fc193a232dfef1e Add linux-next specific
files for 20240415
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202404151720.ha4kzy01-...@intel.com
https
We defer actually closing, unbinding and destroying a VMA until next idle
point, or until the object is freed in the meantime. By postponing the
unbind, we allow for the VMA to be reopened by the client, avoiding the
work required to rebind the VMA.
It was assumed that as long as a GT is held
On 4/3/24 17:24, Maíra Canal wrote:
The commit 509433d8146c ("drm/v3d: Expose the total GPU usage stats on sysfs")
introduced the calculation of global GPU stats. For the regards, it used
the already existing infrastructure provided by commit 09a93cc4f7d1 ("drm/v3d:
Implement show_fdinfo()
Le 15/04/2024 à 18:10, David Wronek a écrit :
Add support for the 2560x1600@90Hz OLED panel by EDO bundled with a
Raydium RM69380 controller, as found on the Lenovo Xiaoxin Pad Pro 2021.
Signed-off-by: David Wronek
---
drivers/gpu/drm/panel/Kconfig | 14 +
ndpoint': {'remote-endpoint': [[4294967295]]}}}, '$nodename':
['panel@0']}
from schema $id:
http://devicetree.org/schemas/display/panel/raydium,rm69380.yaml#
doc reference errors (make refcheckdocs):
See
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240415-raydium-rm
On 15/04/2024 19:00, Tomi Valkeinen wrote:
Add a new flag, TI_SCI_PD_KEEP_BOOT_STATE, which can be set in the dts
when referring to power domains. When this flag is set, the ti-sci
driver will check if the PD is currently enabled in the HW, and if so,
set the GENPD_FLAG_ALWAYS_ON flag so that
Hi Tvrtko,
On 4/1/24 10:21, Tvrtko Ursulin wrote:
On 01/04/2024 13:45, Christian König wrote:
Am 01.04.24 um 14:39 schrieb Tvrtko Ursulin:
On 29/03/2024 00:00, T.J. Mercier wrote:
On Thu, Mar 28, 2024 at 7:53 AM Tvrtko Ursulin
wrote:
From: Tvrtko Ursulin
There is no point in compiling
On Mon, Apr 15, 2024 at 06:10:41PM +0200, David Wronek wrote:
> Raydium RM69380 is a display driver IC used to drive OLED DSI panels.
> Add a dt-binding for it.
>
> Signed-off-by: David Wronek
> ---
> .../bindings/display/panel/raydium,rm69380.yaml| 91
> ++
> 1 file
On 4/15/24 12:19, Jocelyn Falempe wrote:
Hi,
You're right, I messed up the rename, and I mostly test on x86, where I
don't build the imx driver.
Reviewed-by: Jocelyn Falempe
Best regards,
Applied to drm-misc/drm-misc-next!
Best Regards,
- Maíra
Hm. Could you share some logs with drm.debug=0x116? I'm a bit confused
because I would have thought that we were already probing for eDP
backlights seeing as I added support for them at one point?
(I hope this isn't the point I learn I actually forgot to add support
for them :P)
On Fri,
On Mon, 15 Apr 2024 13:00:39 -0300
Maíra Canal wrote:
Hi,
> RPi 0-3 is packed with a GPU that provides 3D rendering capabilities to
> the RPi. Currently, the downstream kernel uses an overlay to enable the
> GPU and use GPU hardware acceleration. When deploying a mainline kernel
> to the RPi
On Mon, Apr 15, 2024 at 06:10:42PM +0200, David Wronek wrote:
> Add support for the 2560x1600@90Hz OLED panel by EDO bundled with a
> Raydium RM69380 controller, as found on the Lenovo Xiaoxin Pad Pro 2021.
>
> Signed-off-by: David Wronek
> ---
> drivers/gpu/drm/panel/Kconfig |
On Sat, Apr 13, 2024 at 05:38:05PM +0200, Johan Jonker wrote:
> The Rockchip DWC HDMI TX Encoder can take one I2S input and transmit it
> over the HDMI output. Add #sound-dai-cells (= 0) to the binding for it.
>
> Signed-off-by: Johan Jonker
Please send cover letters for multi-patch series, for
Add support for the 2560x1600@90Hz OLED panel by EDO bundled with a
Raydium RM69380 controller, as found on the Lenovo Xiaoxin Pad Pro 2021.
Signed-off-by: David Wronek
---
drivers/gpu/drm/panel/Kconfig | 14 +
drivers/gpu/drm/panel/Makefile| 1 +
This patch adds support the 2560x1600@90Hz dual DSI command mode panel by
EDO in combination with a Raydium RM69380 driver IC.
This driver IC can be found in the following devices:
* Lenovo Xiaoxin Pad Pro 2021 (TB-J716F) with EDO panel
* Lenovo Tab P11 Pro (TB-J706F) with EDO panel
* Robo &
Raydium RM69380 is a display driver IC used to drive OLED DSI panels.
Add a dt-binding for it.
Signed-off-by: David Wronek
---
.../bindings/display/panel/raydium,rm69380.yaml| 91 ++
1 file changed, 91 insertions(+)
diff --git
Hi Christian,
Could you please push these patches into drm branch.
Thanks,
Arun.
On 4/15/2024 2:53 AM, Arunpravin Paneer Selvam wrote:
- Add tracking clear page feature.
- Driver should enable the DRM_BUDDY_CLEARED flag if it
successfully clears the blocks in the free path. On the
RPi 0-3 is packed with a GPU that provides 3D rendering capabilities to
the RPi. Currently, the downstream kernel uses an overlay to enable the
GPU and use GPU hardware acceleration. When deploying a mainline kernel
to the RPi 0-3, we end up without any GPU hardware acceleration
(essentially, we
: 0bbac3facb5d6cc0171c45c9873a2dc96bea9680
change-id: 20240415-ti-sci-pd-33b39f6b0586
Best regards,
--
Tomi Valkeinen
When the dts file has multiple referrers to a single PD (e.g.
simple-framebuffer and dss nodes both point to the DSS power-domain) the
ti-sci driver will create two power domains, both with the same ID, and
that will cause problems as one of the power domains will hide the other
one.
Fix this
Add a new flag, TI_SCI_PD_KEEP_BOOT_STATE, which can be set in the dts
when referring to power domains. When this flag is set, the ti-sci
driver will check if the PD is currently enabled in the HW, and if so,
set the GENPD_FLAG_ALWAYS_ON flag so that the PD will stay enabled.
The main issue I'm
Hi Christian,
On Mon, Apr 15 2024, Christian König wrote:
> Am 14.04.24 um 15:07 schrieb Baruch Siach:
>> Signed-off-by: Baruch Siach
>> ---
>> Documentation/driver-api/dma-buf.rst | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/Documentation/driver-api/dma-buf.rst
El 3/4/24 a las 22:24, Maíra Canal escribió:
This will make it easier to instantiate the GPU stats variables and it
will create a structure where we can store all the variables that refer
to GPU stats.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/v3d/v3d_drv.c | 14 ++
Hi,
You're right, I messed up the rename, and I mostly test on x86, where I
don't build the imx driver.
Reviewed-by: Jocelyn Falempe
Best regards,
--
Jocelyn
On 15/04/2024 17:09, Maíra Canal wrote:
On version 11, Thomas suggested to change the name of the function and
this request was
On version 11, Thomas suggested to change the name of the function and
this request was applied on version 12, which is the version that
landed. Although the name of the function changed on the C file, it
didn't changed on the header file, leading to a compilation error as
such:
On 10/04/2024 10:12, Daniel Vetter wrote:
On Tue, Apr 09, 2024 at 06:30:39PM +0200, Jocelyn Falempe wrote:
drm/panic: Add a drm panic handler
This introduces a new drm panic handler, which displays a message when a panic
occurs.
So when fbcon is disabled, you can still see a kernel panic.
6.1-stable review patch. If anyone has any objections, please let me know.
--
From: Jammy Huang
commit bc004f5038220b1891ef4107134ccae44be55109 upstream.
There is a while-loop in ast_dp_set_on_off() that could lead to
infinite-loop. This is because the register, VGACRI-Dx,
Hello Nouveau Devs,
Commit 9e999023 ("drm/nouveau/disp/r535: initial support") from
Sep 19, 2023 (linux-next), leads to the following Smatch static
checker warning:
drivers/gpu/drm/nouveau/nvkm/engine/disp/r535.c:1482 r535_disp_oneinit() error:
potential NULL/IS_ERR bug 'ctrl'
Am 15.04.24 um 16:32 schrieb Felix Kuehling:
On 2024-04-15 10:08, Christian König wrote:
Am 15.04.24 um 15:53 schrieb Felix Kuehling:
On 2024-04-15 9:48, Christian König wrote:
From: Christian König
We only pool write combined and uncached allocations because they
require extra overhead on
6.6-stable review patch. If anyone has any objections, please let me know.
--
From: Jammy Huang
commit bc004f5038220b1891ef4107134ccae44be55109 upstream.
There is a while-loop in ast_dp_set_on_off() that could lead to
infinite-loop. This is because the register, VGACRI-Dx,
6.6-stable review patch. If anyone has any objections, please let me know.
--
From: Zack Rusin
commit 4c08f01934ab67d1d283d5cbaa52b923abcfe4cd upstream.
Enable DMA mappings in vmwgfx after TTM has been fixed in commit
3bf3710e3718 ("drm/ttm: Add a generic TTM memcpy move for
Am 14.04.24 um 15:07 schrieb Baruch Siach:
Signed-off-by: Baruch Siach
---
Documentation/driver-api/dma-buf.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/driver-api/dma-buf.rst
b/Documentation/driver-api/dma-buf.rst
index 0c153d79ccc4..29abf1eebf9f
On 2024-04-15 10:08, Christian König wrote:
Am 15.04.24 um 15:53 schrieb Felix Kuehling:
On 2024-04-15 9:48, Christian König wrote:
From: Christian König
We only pool write combined and uncached allocations because they
require extra overhead on allocation and release.
If we also pool
On Tue, Apr 09, 2024 at 12:04:05PM +0200, Louis Chauvet wrote:
> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> index 6e74de833466..8d4b317eb9d7 100644
> --- a/drivers/gpu/drm/drm_blend.c
> +++ b/drivers/gpu/drm/drm_blend.c
> @@ -321,6 +321,11 @@
6.8-stable review patch. If anyone has any objections, please let me know.
--
From: Jammy Huang
commit bc004f5038220b1891ef4107134ccae44be55109 upstream.
There is a while-loop in ast_dp_set_on_off() that could lead to
infinite-loop. This is because the register, VGACRI-Dx,
6.8-stable review patch. If anyone has any objections, please let me know.
--
From: Zack Rusin
commit 4c08f01934ab67d1d283d5cbaa52b923abcfe4cd upstream.
Enable DMA mappings in vmwgfx after TTM has been fixed in commit
3bf3710e3718 ("drm/ttm: Add a generic TTM memcpy move for
On Tue, Apr 09, 2024 at 12:04:06PM +0200, Louis Chauvet wrote:
> @@ -266,8 +257,41 @@ EXPORT_SYMBOL(drm_plane_create_alpha_property);
> *
> * Rotation is the specified amount in degrees in counter clockwise
> direction,
> * the X and Y axis are within the source rectangle, i.e. the X/Y
On Mon, 15 Apr 2024 16:09:22 +0300, Jani Nikula wrote:
> On Wed, 10 Apr 2024, Jani Nikula wrote:
> > Surprisingly many places depend on debugfs.h to be included via
> > drm_print.h. Fix them.
>
> While all of this is trivial, merely adding some includes, please
>
> [ ... ]
Acked-by: Maxime
On Tue, Apr 09, 2024 at 12:04:07PM +0200, Louis Chauvet wrote:
> /**
> * struct drm_format_info - information about a DRM format
> + *
> + * A drm_format_info describes how planes and pixels are stored in memory.
> + *
> + * Some format like YUV can have multiple planes, counted in @num_planes.
Am 15.04.24 um 15:53 schrieb Felix Kuehling:
On 2024-04-15 9:48, Christian König wrote:
From: Christian König
We only pool write combined and uncached allocations because they
require extra overhead on allocation and release.
If we also pool cached NUMA it not only means some extra
The Board of Directors election concluded on 08 April 2024. There were
81 Members of the X.Org Foundation eligible to vote, and 61 Members cast
votes. This is a 75.3% turn out.
In the election of the Directors to the Board of the X.Org Foundation,
the results were that Erik Faye-Lund, Simon Ser,
On Mon, Apr 15, 2024 at 4:40 AM Thorsten Blum wrote:
>
> s/,please/, please/
>
> Signed-off-by: Thorsten Blum
Reviewed-by: Alex Deucher
And applied. Thanks!
Alex
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On 2024-04-15 9:48, Christian König wrote:
From: Christian König
We only pool write combined and uncached allocations because they
require extra overhead on allocation and release.
If we also pool cached NUMA it not only means some extra unnecessary
overhead, but also that under memory
From: Christian König
We only pool write combined and uncached allocations because they
require extra overhead on allocation and release.
If we also pool cached NUMA it not only means some extra unnecessary
overhead, but also that under memory pressure it can happen that
pages from the wrong
On Mon, 08 Apr 2024, Jani Nikula wrote:
> v2 of [1], dropping drm_mode_print() stuff altogether, and switching to
> DRM_MODE_FMT/DRM_MODE_ARG() in a separate patch. Also add a few more drm
> device based logging conversion patches, so the last patch makes more sense.
Thanks for the reviews,
On Wed, 10 Apr 2024, Jani Nikula wrote:
> We've accumulated enough Intel specific header files under include/drm
> that they warrant a subdirectory of their own. Clean up the top drm
> header directory by moving the Intel files under include/drm/intel.
>
> Since i915 is most impacted, I suggest
On Wed, 10 Apr 2024, Jani Nikula wrote:
> Surprisingly many places depend on debugfs.h to be included via
> drm_print.h. Fix them.
While all of this is trivial, merely adding some includes, please
consider acking the changes to your corner of the kernel.
Thanks,
Jani.
>
> Signed-off-by: Jani
On Sun, Apr 14, 2024 at 06:35:58PM +0200, Krzysztof Kozlowski wrote:
> Hi,
>
> Dependencies
>
> All further patches depend on the first patch. Therefore everything
> could go via backlight tree (please ack) or via cross-tree pulls. Or
> whatever maintainer choose, just coordinate
On Sun, Apr 14, 2024 at 06:36:12PM +0200, Krzysztof Kozlowski wrote:
> 'struct lcd_ops' is not modified by core backlight code, so it can be
> made const for increased code safety.
>
> Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Daniel Thompson
Daniel.
On Sun, Apr 14, 2024 at 06:36:11PM +0200, Krzysztof Kozlowski wrote:
> 'struct lcd_ops' is not modified by core backlight code, so it can be
> made const for increased code safety.
>
> Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Daniel Thompson
Daniel.
On Sun, Apr 14, 2024 at 06:36:10PM +0200, Krzysztof Kozlowski wrote:
> 'struct lcd_ops' is not modified by core backlight code, so it can be
> made const for increased code safety.
>
> Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Daniel Thompson
Daniel.
On Tue, 09 Apr 2024, Ville Syrjälä wrote:
> On Tue, Apr 09, 2024 at 12:46:11PM +0300, Jani Nikula wrote:
>> To avoid accessing and parsing the raw EDID with drm_edid_raw(), switch
>> to the struct drm_edid based function to extract product id, and use the
>> drm printer function to debug log it.
On Sun, Apr 14, 2024 at 06:36:09PM +0200, Krzysztof Kozlowski wrote:
> 'struct lcd_ops' is not modified by core backlight code, so it can be
> made const for increased code safety.
>
> Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Daniel Thompson
Daniel.
On Sun, Apr 14, 2024 at 06:36:08PM +0200, Krzysztof Kozlowski wrote:
> 'struct lcd_ops' is not modified by core backlight code, so it can be
> made const for increased code safety.
>
> Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Daniel Thompson
Daniel.
On Sun, Apr 14, 2024 at 06:36:07PM +0200, Krzysztof Kozlowski wrote:
> 'struct lcd_ops' is not modified by core backlight code, so it can be
> made const for increased code safety.
>
> Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Daniel Thompson
Daniel.
On Sun, Apr 14, 2024 at 06:36:06PM +0200, Krzysztof Kozlowski wrote:
> 'struct lcd_ops' is not modified by core backlight code, so it can be
> made const for increased code safety.
>
> Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Daniel Thompson
Daniel.
On Sun, Apr 14, 2024 at 06:36:05PM +0200, Krzysztof Kozlowski wrote:
> 'struct lcd_ops' is not modified by core backlight code, so it can be
> made const for increased code safety.
>
> Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Daniel Thompson
Daniel.
On 05/04/2024 18:59, Rob Clark wrote:
On Wed, Apr 3, 2024 at 11:37 AM Adrián Larumbe
wrote:
Up to this day, all fdinfo-based GPU profilers must traverse the entire
/proc directory structure to find open DRM clients with fdinfo file
descriptors. This is inefficient and time-consuming.
This
On Sun, Apr 14, 2024 at 06:36:04PM +0200, Krzysztof Kozlowski wrote:
> 'struct lcd_ops' is not modified by core backlight code, so it can be
> made const for increased code safety.
>
> Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Daniel Thompson
Daniel.
On Sun, Apr 14, 2024 at 06:36:03PM +0200, Krzysztof Kozlowski wrote:
> 'struct lcd_ops' is not modified by core backlight code, so it can be
> made const for increased code safety.
>
> Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Daniel Thompson
Daniel.
On Sun, Apr 14, 2024 at 06:36:02PM +0200, Krzysztof Kozlowski wrote:
> 'struct lcd_ops' is not modified by core backlight code, so it can be
> made const for increased code safety.
>
> Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Daniel Thompson
Daniel.
This is a note to let you know that I've just added the patch titled
drm/ast: Fix soft lockup
to the 6.1-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-ast-fix-soft-lockup.patch
On Sun, Apr 14, 2024 at 06:36:01PM +0200, Krzysztof Kozlowski wrote:
> 'struct lcd_ops' is not modified by core backlight code, so it can be
> made const for increased code safety.
>
> Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Daniel Thompson
Daniel.
This is a note to let you know that I've just added the patch titled
drm/vmwgfx: Enable DMA mappings with SEV
to the 6.6-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
drm/ast: Fix soft lockup
to the 6.6-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-ast-fix-soft-lockup.patch
On Sun, Apr 14, 2024 at 06:36:00PM +0200, Krzysztof Kozlowski wrote:
> 'struct lcd_ops' is not modified by core backlight code, so it can be
> made const for increased code safety.
>
> Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Daniel Thompson
Daniel.
1 - 100 of 157 matches
Mail list logo
