Hi Sarah,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm/drm-next drm-intel/for-linux-next
drm-tip/drm-tip next-20231011]
[cannot apply to drm-exynos/exynos-drm-next drm-intel/for-linux-next-fixes
The Solomon SSD132x controllers (such as the SSD1322, SSD1325 and SSD1327)
are used by 16 grayscale dot matrix OLED panels, extend the driver to also
support this chip family.
Signed-off-by: Javier Martinez Canillas
---
Changes in v2:
- Align the rectangle to the segment width (Geert Uytterhoeve
There are DT properties that can be shared across different Solomon OLED
Display Controller families. Split them into a separate common schema to
avoid these properties to be duplicated in different DT bindings schemas.
Suggested-by: Rob Herring
Signed-off-by: Javier Martinez Canillas
---
(no c
Add a Device Tree binding schema for the OLED panels based on the Solomon
SSD132x family of controllers.
Signed-off-by: Javier Martinez Canillas
---
Changes in v2:
- Remove unnecessary 'oneOf' in the SSD132x DT binding schema (Conor Dooley).
- Remove unused DT nodes labels in the binding schema
There are some commands that are shared between the SSD130x and SSD132x
controller families, define these as a common SSD13XX set of commands.
Signed-off-by: Javier Martinez Canillas
---
(no changes since v1)
drivers/gpu/drm/solomon/ssd130x-spi.c | 4 +--
drivers/gpu/drm/solomon/ssd130x.c
To allow the driver to decouple the common logic in the function callbacks
from the behaviour that is specific of a given Solomon controller family.
For this, include a chip family to the device info and add fields to the
driver-private device struct, to store the hardware buffer maximum size,
the
Hello,
This patch-set adds support for the family of SSD132x Solomon controllers,
such as the SSD1322, SSD1325 and SSD1327 chips. These are used for 16 Gray
Scale Dot Matrix OLED panels.
This is a v2 that address issues pointed out during review of the v1:
https://lists.freedesktop.org/archives/
This deemed useful to avoid hardcoding a page height and allow to support
other Solomon controller families, but dividing the screen in pages seems
to be something that is specific to the SSD130x chip family.
For example, SSD132x chip family divides the screen in segments (columns)
and common outp
Thanks Jeffrey for the addition.
Hi Rob, krzysztof,
Just a ping. Is Jeffrey's reply ok for you?
Thanks.
On Tue, 2023-09-19 at 15:15 -0700, Jeffrey Kardatzke wrote:
>
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>
Am 11.10.23 um 18:13 schrieb Gustavo A. R. Silva:
On 10/11/23 10:03, Kees Cook wrote:
On Wed, Oct 11, 2023 at 08:03:43AM -0600, Gustavo A. R. Silva wrote:
Currently, a NULL pointer dereference will happen in function
`dma_fence_enable_sw_signaling()` (at line 615), in case `chain`
is not a
Hi Jeffrey,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on next-20231011]
[cannot apply to linus/master v6.6-rc5]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
On 2023-10-12 00:31, Matthew Brost wrote:
> On Wed, Oct 11, 2023 at 08:39:55PM -0400, Luben Tuikov wrote:
>> On 2023-10-11 19:58, Matthew Brost wrote:
>>> Rather than a global modparam for scheduling policy, move the scheduling
>>> policy to scheduler so user can control each scheduler policy.
>>>
On Thu, Oct 12, 2023 at 04:02:13AM +0200, Danilo Krummrich wrote:
> Hi Matt,
>
> Can you please address my comments from V3 and V4?
>
> https://lore.kernel.org/all/076891e9-b2ce-4c7f-833d-157aca5cd...@amd.com/T/#m34ccee55e37ca47c87adf01439585d0bd187e3a0
>
Not my intent to ignore you. To be clea
On Wed, Oct 11, 2023 at 08:39:55PM -0400, Luben Tuikov wrote:
> On 2023-10-11 19:58, Matthew Brost wrote:
> > Rather than a global modparam for scheduling policy, move the scheduling
> > policy to scheduler so user can control each scheduler policy.
> >
> > v2:
> > - s/DRM_SCHED_POLICY_MAX/DRM_S
Hi Dave, Daniel,
Fixes for 6.6.
The following changes since commit 94f6f0550c625fab1f373bb86a6669b45e9748b3:
Linux 6.6-rc5 (2023-10-08 13:49:43 -0700)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-drm-fixes-6.6-2023-10-11
for you to fetch
From: Andy Yan
The cluster windows on rk3568/6 only support afbc format,
linear format(RGB/YUV) are not supported.
The cluster windows on rk3588 support both linear and afbc rgb
format, but for yuv format it only support afbc.
The esmart windows on rk3588 support uv swap for yuyv, but
rk356x doe
From: Andy Yan
These structs are undefined and un used.
Fixes: 604be85547ce ("drm/rockchip: Add VOP2 driver")
Signed-off-by: Andy Yan
---
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 2 --
drivers/gpu/drm/rockchip/rockchip_drm_vop2.h | 3 ---
2 files changed, 5 deletions(-)
diff --git a/d
From: Andy Yan
There are 8 layers on rk3588, so a fix defined macro is
not appropriate.
Signed-off-by: Andy Yan
---
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
b/drivers/gpu/dr
From: Andy Yan
This is a preparation for the upcoming support for rk3588 vop.
Patch 1 remove unused struct
Patch 2 remove NR_LAYERS macro to support more layers on rk3588
Patch 3 are plane format fix and rename to support more format on rk3588
Andy Yan (3):
drm/rockchip: remove unused struct
These functions are defined in the a6xx_gpu_state.h file, but not called
elsewhere, so delete these unused functions.
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.h:356:36: warning: ‘a7xx_ahb_reglist’
defined but not used.
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.h:360:36: warning:
‘a7xx_gbif_regl
Hi, Lucas
Thanks a lot!
On 2023/10/12 01:04, Lucas Stach wrote:
Am Montag, dem 02.10.2023 um 19:12 +0800 schrieb Sui Jingfeng:
v2:
* refine on v1 and update
Thanks, series applied to my etnaviv/next branch.
Regards,
Lucas
Sui Jingfeng (5):
drm/etnaviv: Drop the second argumen
On 10/12/23 03:52, Luben Tuikov wrote:
Hi,
Thanks for fixing the title and submitting a v2 of this patch. Comments inlined
below.
On 2023-10-09 18:35, Danilo Krummrich wrote:
Currently, job flow control is implemented simply by limiting the number
of jobs in flight. Therefore, a scheduler
Hi Matt,
Can you please address my comments from V3 and V4?
https://lore.kernel.org/all/076891e9-b2ce-4c7f-833d-157aca5cd...@amd.com/T/#m34ccee55e37ca47c87adf01439585d0bd187e3a0
- Danilo
On 10/12/23 01:58, Matthew Brost wrote:
As a prerequisite to merging the new Intel Xe DRM driver [1] [2],
Hi,
Thanks for fixing the title and submitting a v2 of this patch. Comments inlined
below.
On 2023-10-09 18:35, Danilo Krummrich wrote:
> Currently, job flow control is implemented simply by limiting the number
> of jobs in flight. Therefore, a scheduler is initialized with a
> submission limit
Use exiting function to free the allocated GEM object instead of
open-coding it. This has a bonus of internally calling
msm_gem_put_vaddr() to compensate for msm_gem_get_vaddr() in
msm_get_kernel_new().
Fixes: 1e29dff00400 ("drm/msm: Add a common function to free kernel buffer
objects")
Signed-of
If the drm/msm init code gets an error during output modeset
initialisation, the kernel will report an error regarding DRM memory
manager not being clean during shutdown. This is because
msm_dsi_modeset_init() allocates a piece of GEM memory for the TX
buffer, but destruction of the buffer happens
Fix two issues in how the MSM DSI driver handles the GEM-allocated TX
DMA buffer object.
Changes since v1:
- Dropped the unused 'priv' variable from msm_dsi_tx_buf_free()
Dmitry Baryshkov (2):
drm/msm/dsi: use msm_gem_kernel_put to free TX buffer
drm/msm/dsi: free TX buffer in unbind
driver
Hi all,
On Thu, 12 Oct 2023 12:22:09 +1100 Stephen Rothwell
wrote:
>
> After merging the drm-misc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/usb/typec/altmodes/displayport.c: In function 'dp_altmode_vdm':
> drivers/usb/typec/altmodes/displayport.c:309:3
Hi all,
After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/usb/typec/altmodes/displayport.c: In function 'dp_altmode_vdm':
drivers/usb/typec/altmodes/displayport.c:309:33: error: too few arguments to
function 'drm_connector_oob_hotplug_event
Make a6xx_get_registers() use a7xx registers instead of a6xx ones if the
detected Adreno is from the A7xx family.
Fixes: e997ae5f45ca ("drm/msm/a6xx: Mostly implement A7xx gpu_state")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 17 +
drivers/
On 07/10/2023 01:55, Kuogee Hsieh wrote:
Currently DP driver is executed independent of PM runtime framework.
This leads msm eDP panel can not being detected by edp_panel driver
during generic_edp_panel_probe() due to AUX DPCD read failed at
edp panel driver. Incorporate PM runtime framework into
On 07/10/2023 01:55, Kuogee Hsieh wrote:
Currently DP driver is executed independent of PM runtime framework.
This leads msm eDP panel can not being detected by edp_panel driver
during generic_edp_panel_probe() due to AUX DPCD read failed at
edp panel driver. Incorporate PM runtime framework into
On 2023-10-11 19:58, Matthew Brost wrote:
> Rather than a global modparam for scheduling policy, move the scheduling
> policy to scheduler so user can control each scheduler policy.
>
> v2:
> - s/DRM_SCHED_POLICY_MAX/DRM_SCHED_POLICY_COUNT (Luben)
> - Only include policy in scheduler (Luben)
>
Rather than a global modparam for scheduling policy, move the scheduling
policy to scheduler so user can control each scheduler policy.
v2:
- s/DRM_SCHED_POLICY_MAX/DRM_SCHED_POLICY_COUNT (Luben)
- Only include policy in scheduler (Luben)
v3:
- use a ternary operator as opposed to an if-cont
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 a continuation of a RFC [3] with all comments addressed, ready for
a full review, and hopefully in state which can merged in the near
future. More details of t
Also add a lockdep assert to drm_sched_start_timeout.
Signed-off-by: Matthew Brost
Reviewed-by: Luben Tuikov
---
drivers/gpu/drm/scheduler/sched_main.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers
Add helper to queue TDR immediately for current and future jobs. This is
used in Xe, a new Intel GPU driver, to trigger a TDR to cleanup a
drm_scheduler that encounter errors.
v2:
- Drop timeout args, rename function, use mod delayed work (Luben)
v3:
- s/XE/Xe (Luben)
- present tense in commit
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.
v2:
- Test for DMA_FENCE_FLAG_TIMESTAMP_BIT before setting
timestamp in free_job() work item (Danilo)
v3:
- Drop forward dec of drm_sc
In Xe, the new Intel GPU driver, a choice has made to have a 1 to 1
mapping between a drm_gpu_scheduler and drm_sched_entity. At first this
seems a bit odd but let us explain the reasoning below.
1. In Xe the submission order from multiple drm_sched_entity is not
guaranteed to be the same completi
DRM_SCHED_POLICY_SINGLE_ENTITY creates a 1 to 1 relationship between
scheduler and entity. No priorities or run queue used in this mode.
Intended for devices with firmware schedulers.
v2:
- Drop sched / rq union (Luben)
v3:
- Don't pick entity if stopped in drm_sched_select_entity (Danilo)
v4:
Add scheduler wqueue ready, stop, and start helpers to hide the
implementation details of the scheduler from the drivers.
v2:
- s/sched_wqueue/sched_wqueue (Luben)
- Remove the extra white line after the return-statement (Luben)
- update drm_sched_wqueue_ready comment (Luben)
Signed-off-by:
Use exiting function to free the allocated GEM object instead of
open-coding it. This has a bonus of internally calling
msm_gem_put_vaddr() to compensate for msm_gem_get_vaddr() in
msm_get_kernel_new().
Fixes: 1e29dff00400 ("drm/msm: Add a common function to free kernel buffer
objects")
Signed-of
If the drm/msm init code gets an error during output modeset
initialisation, the kernel will report an error regarding DRM memory
manager not being clean during shutdown. This is because
msm_dsi_modeset_init() allocates a piece of GEM memory for the TX
buffer, but destruction of the buffer happens
Fix two issues in how the MSM DSI driver handles the GEM-allocated TX
DMA buffer object.
Dmitry Baryshkov (2):
drm/msm/dsi: use msm_gem_kernel_put to free TX buffer
drm/msm/dsi: free TX buffer in unbind
drivers/gpu/drm/msm/dsi/dsi.c | 1 +
drivers/gpu/drm/msm/dsi/dsi.h | 1 +
dri
On 2023-10-05 00:06, Matthew Brost wrote:
> On Thu, Sep 28, 2023 at 12:14:12PM -0400, Luben Tuikov wrote:
>> On 2023-09-19 01:01, 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
On 2023-10-06 19:43, Matthew Brost wrote:
> On Fri, Oct 06, 2023 at 03:14:04PM +, Matthew Brost wrote:
>> On Fri, Oct 06, 2023 at 08:59:15AM +0100, Tvrtko Ursulin wrote:
>>>
>>> On 05/10/2023 05:13, Luben Tuikov wrote:
On 2023-10-04 23:33, Matthew Brost wrote:
> On Tue, Sep 26, 2023 at
On 2023-10-06 11:14, Matthew Brost wrote:
> On Fri, Oct 06, 2023 at 08:59:15AM +0100, Tvrtko Ursulin wrote:
>>
>> On 05/10/2023 05:13, Luben Tuikov wrote:
>>> On 2023-10-04 23:33, Matthew Brost wrote:
On Tue, Sep 26, 2023 at 11:32:10PM -0400, Luben Tuikov wrote:
> Hi,
>
> On 2023-0
On 2023-10-06 03:59, Tvrtko Ursulin wrote:
>
> On 05/10/2023 05:13, Luben Tuikov wrote:
>> On 2023-10-04 23:33, Matthew Brost wrote:
>>> On Tue, Sep 26, 2023 at 11:32:10PM -0400, Luben Tuikov wrote:
Hi,
On 2023-09-19 01:01, Matthew Brost wrote:
> In XE, the new Intel GPU driver,
.
DEBUG_LOCKS_WARN_ON(lock->magic != lock)
WARNING: CPU: 0 PID: 10 at kernel/locking/mutex.c:582 __mutex_lock+0x468/0x77c
Modules linked in:
CPU: 0 PID: 10 Comm: kworker/0:1 Tainted: G U
6.6.0-rc5-next-20231011-gd81f81c2b682-dirty #1206
Hardware name: Qualcomm Technologies, Inc. Robotics RB5
The lifetime of the created drm_bridge is attached to the drm_device
rather than the HDMI's platform_device. Use correct lifetime for
devm_drm_bridge_add() call.
Fixes: 719093a67c7f ("drm/msm/hdmi: switch to devm_drm_bridge_add()")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdm
The lifetime of the created drm_bridge is attached to the drm_device
rather than the DP's platform_device. Use correct lifetime for
devm_drm_bridge_add() call.
Fixes: 61a72d5efce5 ("drm/msm/dp: switch to devm_drm_bridge_add()")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_drm.c
The lifetime of the created drm_bridge is attached to the drm_device
rather than the DSI's platform_device. Use correct lifetime for
devm_drm_bridge_add() call.
Fixes: 5f403fd7d5c2 ("drm/msm/dsi: switch to devm_drm_bridge_add()")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/dsi_ma
While reworking the drm/msm driver to use devm_drm_bridge_add() I didn't
notice that the drm_bridge instances are allocated with the drm_device
used as a lifetime parameter instead of corresponding platform_device.
This mostly works fine, in rare cases of device reprobing resulting in
the oops such
On Fri, Sep 01, 2023 at 02:59:09PM +0300, Mikko Perttunen wrote:
> From: Johnny Liu
>
> Original implementation over allocates the memory size for the
> contexts list. The size of memory for the contexts list is based
> on the number of iommu groups specified in the device tree.
>
> Fixes: 8aa5b
On Fri, Sep 01, 2023 at 02:40:07PM +0300, Mikko Perttunen wrote:
> From: Mikko Perttunen
>
> Support sharded syncpoint interrupts on Tegra234+. This feature
> allows specifying one of eight interrupt lines for each syncpoint
> to lower processing latency of syncpoint threshold
> interrupts.
>
>
On Fri, Sep 01, 2023 at 02:15:07PM +0300, Mikko Perttunen wrote:
> From: Mikko Perttunen
>
> Add locking around channel allocation to avoid race conditions.
>
> Signed-off-by: Mikko Perttunen
> ---
> drivers/gpu/host1x/channel.c | 7 +++
> drivers/gpu/host1x/channel.h | 3 +++
> 2 files ch
Joel's suggestion to explore the previously proposed generic solution makes
sense, especially considering the recent changes for PMBus devices that have
added delays. Thank you for your review and input.
I will modify the code to incorporate the necessary delay directly in the
max31785 driver.
On Wed, Oct 11, 2023 at 12:20 PM Pekka Paalanen wrote:
>
> On Tue, 10 Oct 2023 15:13:46 -0100
> Melissa Wen wrote:
>
> > O 09/08, Harry Wentland wrote:
> > > Signed-off-by: Harry Wentland
> > > Cc: Ville Syrjala
> > > Cc: Pekka Paalanen
> > > Cc: Simon Ser
> > > Cc: Harry Wentland
> > > Cc:
Reviewed-by: David Heidelberg
On 09/10/2023 02:49, Helen Koike wrote:
When building containers, some rust packages were installed without
locking the dependencies version, which got updated and started giving
errors like:
error: failed to compile `bindgen-cli v0.62.0`, intermediate artifacts c
Am Samstag, dem 07.10.2023 um 15:03 +0800 schrieb Sui Jingfeng:
> The 'len' parameter is the 4th argument, because it is not get used, so
> drop it. No functional change.
>
> Signed-off-by: Sui Jingfeng
Thanks, applied to my etnaviv/next branch.
Regards,
Lucas
> ---
> drivers/gpu/drm/etnaviv/
Am Montag, dem 02.10.2023 um 19:12 +0800 schrieb Sui Jingfeng:
> v2:
> * refine on v1 and update
>
Thanks, series applied to my etnaviv/next branch.
Regards,
Lucas
> Sui Jingfeng (5):
> drm/etnaviv: Drop the second argument of the etnaviv_gem_new_impl()
> drm/etnaviv: Fix coding style
Am Montag, dem 18.09.2023 um 13:34 + schrieb Justin Stitt:
> `strncpy` is deprecated for use on NUL-terminated destination strings [1].
>
> We should prefer more robust and less ambiguous string interfaces.
>
> A suitable replacement is `strscpy_pad` due to the fact that it
> guarantees NUL-t
Hi Guenter,
> I didn't (want to) say that. I am perfectly happy with driver specific
> code, and I would personally still very much prefer it. I only wanted to
> suggest that _if_ a generic solution is implemented, it should cover all
> existing use cases and not just this one. But, really, I'd ra
LS2K1000 is a low end SoC (two core 1.0gHz), it don't has dedicated VRAM.
It requires the framebuffer to be phisically continguous to scanout. The
display controller in LS2K1000 don't has built-in GPIO hardware, the
structure (register bit field) of its pixel, DC, GPU, DDR PLL are also
defferent fr
On 10/11/23 10:03, Kees Cook wrote:
On Wed, Oct 11, 2023 at 08:03:43AM -0600, Gustavo A. R. Silva wrote:
Currently, a NULL pointer dereference will happen in function
`dma_fence_enable_sw_signaling()` (at line 615), in case `chain`
is not allocated in `mock_chain()` and this function returns
On Mon, Oct 09, 2023 at 03:25:54PM +0200, Lucas Stach wrote:
> Hi all,
>
Hi Lucas,
> recently I've been looking at inconsistent frame times in one of our
> graphics workloads and it seems the culprit lies within the MM
> subsystem. During workload execution sporadically some graphics
> buffers,
On 10/11/23 5:47 AM, Luca Ceresoli wrote:
The examples for these panel drivers have a backlight node in addition to
the actual panel node. However the exact backlight is outside the scope of
this binding and should be dropped from the example.
Link:
https://lore.kernel.org/linux-devicetree/2023
śr., 11 paź 2023 o 11:42 Daniel Vetter napisał(a):
>
> On Wed, Oct 11, 2023 at 11:48:16AM +0300, Pekka Paalanen wrote:
> > On Tue, 10 Oct 2023 10:06:02 -0600
> > jim.cro...@gmail.com wrote:
> >
> > > since I name-dropped you all,
> >
> > Hi everyone,
> >
> > I'm really happy to see this topic bein
On Fri, Aug 04, 2023 at 09:28:42AM +0200, AngeloGioacchino Del Regno wrote:
> In preparation for adding a 12-bits gamma support for the DISP_GAMMA
> IP, remove the mtk_gamma_set_common() function and move the relevant
> bits in mtk_gamma_set() for DISP_GAMMA and mtk_aal_gamma_set() for
> DISP_AAL:
On Wed, Oct 11, 2023 at 08:03:43AM -0600, Gustavo A. R. Silva wrote:
> Currently, a NULL pointer dereference will happen in function
> `dma_fence_enable_sw_signaling()` (at line 615), in case `chain`
> is not allocated in `mock_chain()` and this function returns
> `NULL` (at line 86). See below:
>
Hi Thomas (and everyone else)
Maxime has suggested you're the person for DRM framebuffer emulation.
I'm getting some unexpected behaviour when there are multiple DRM
drivers in play. In this case it happens to be vc4 and the tiny
hx8357d SPI display driver, but this affects most of the tiny DRM
d
On Wed, Oct 11, 2023 at 08:34:29AM +0200, Javier Martinez Canillas wrote:
> Conor Dooley writes:
> >> + # Only required for SPI
> >> + dc-gpios:
> >> +description:
> >> + GPIO connected to the controller's D/C# (Data/Command) pin,
> >> + that is needed for 4-wire SPI to tell the co
Hi Rob,
just a question about led-backlight.yaml and pwm-backlight.yaml
common properties.
...
> > +
> > + brightness-levels:
> > +description:
> > + Array of distinct brightness levels, in PWM dimming mode.
> > + Typically these are in the range from 0 to 255, but any range
> >
On Wed, 11 Oct 2023 11:20:51 +0200
Daniel Vetter wrote:
> msm is automagically upgrading normal commits to full modesets, and
> that's a big no-no:
>
> - for one this results in full on->off->on transitions on all these
> crtc, at least if you're using the usual helpers. Which seems to be
>
From: Thierry Reding
The simple-framebuffer bindings specify that the "memory-region"
property can be used as an alternative to the "reg" property to define
the framebuffer memory used by the display hardware. Implement support
for this in the simplefb driver.
Signed-off-by: Thierry Reding
---
From: Thierry Reding
The simple-framebuffer device tree bindings document the power-domains
property, so make sure that simplefb supports it. This ensures that the
power domains remain enabled as long as simplefb is active.
Signed-off-by: Thierry Reding
---
drivers/video/fbdev/simplefb.c | 93
From: Thierry Reding
Hi,
This contains two patches that bring simplefb up to feature parity with
simpledrm. The patches add support for the "memory-region" property that
provides an alternative to the "reg" property to describe the memory
used for the framebuffer and allow attaching the simple-f
Hi,
On Tue, Oct 10, 2023 at 10:42 PM cong yang
wrote:
>
> Hi,
>
> On Wed, Oct 11, 2023 at 3:11 AM Doug Anderson wrote:
> >
> > Hi,
> >
> > On Tue, Oct 10, 2023 at 5:14 AM Cong Yang
> > wrote:
> > >
> > > diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9882t.c
> > > b/drivers/gpu/drm/panel/p
From: Thierry Reding
We need to check if a link is non-NULL before trying to delete it.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tiny/simpledrm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
ind
Currently, a NULL pointer dereference will happen in function
`dma_fence_enable_sw_signaling()` (at line 615), in case `chain`
is not allocated in `mock_chain()` and this function returns
`NULL` (at line 86). See below:
drivers/dma-buf/st-dma-fence-chain.c:
86 chain = mock_chain(NULL, f,
On Mon, 6 Mar 2023 at 11:49, Maxime Ripard wrote:
>
> From: Dave Stevenson
>
> Copy Intel's "Broadcast RGB" property semantics to add manual override
> of the HDMI pixel range for monitors that don't abide by the content
> of the AVI Infoframe.
>
> Signed-off-by: Dave Stevenson
> Signed-off-by:
On Fri, Aug 04, 2023 at 09:28:41AM +0200, AngeloGioacchino Del Regno wrote:
> Make the code more robust and improve readability by using bitfield
> macros instead of open coding bit operations.
>
> Signed-off-by: AngeloGioacchino Del Regno
>
Reviewed-by: Nícolas F. R. A. Prado
Thanks,
Nícolas
On 11/10/2023 14:45, Dmitry Baryshkov wrote:
On Wed, 11 Oct 2023 at 14:59, Neil Armstrong wrote:
Starting from SM8550, the SSPP & WB clock controls are moved
the SSPP and WB register range, as it's called "VBIF_CLK_SPLIT"
downstream.
Implement setup_clk_force_ctrl() only starting from major v
On Sun, 08 Oct 2023, Hans de Goede wrote:
> Hi All,
>
> Ping what is the status of this now? This v3 addresses all review
> remarks from previous versions (specifically the request to file
> + link gitlab issues).
>
> So AFAICT this is ready for merging ?
>
> But I'm waiting for an ack for this be
On Wed, 11 Oct 2023 at 14:59, Neil Armstrong wrote:
>
> The SM8550 has the SSPP clk_ctrl in the SSPP registers, remove the
> duplicate clock controls from the MDP top.
>
> Signed-off-by: Neil Armstrong
> ---
> .../gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h | 20
>
> 1
On Wed, 11 Oct 2023 at 14:59, Neil Armstrong wrote:
>
> Now SSPP and WB can have setup_force_clk_ctrl() ops, it's simpler to call
> them from the plane and wb code and call into the mdp ops if not present.
Reviewed-by: Dmitry Baryshkov
>
> Signed-off-by: Neil Armstrong
> ---
> .../gpu/drm/msm
On Wed, 11 Oct 2023 at 14:59, Neil Armstrong wrote:
>
> Enable WB2 hardware block, enabling writeback support on this platform.
>
> Signed-off-by: Neil Armstrong
Reviewed-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h | 16
> 1 file change
On Wed, 11 Oct 2023 at 14:59, Neil Armstrong wrote:
>
> Starting from SM8550, the SSPP & WB clock controls are moved
> the SSPP and WB register range, as it's called "VBIF_CLK_SPLIT"
> downstream.
>
> Implement setup_clk_force_ctrl() only starting from major version 9
> which corresponds to SM8550
1 - 100 of 149 matches
Mail list logo
