On Fri, 07 Jun 2024 16:22:57 +0300, Dmitry Baryshkov wrote:
> This patchset sits on top Maxime's HDMI connector patchset ([1]).
>
> Currently this is an RFC exploring the interface between HDMI bridges
> and HDMI connector code. This has been lightly verified on the Qualcomm
> DB820c, which has
On Wed, 12 Jun 2024 09:23:13 +0200, Geert Uytterhoeven wrote:
> Based on grepping through the source code, this driver appears to be
> missing a call to drm_atomic_helper_shutdown() at system shutdown time.
> This is important because drm_atomic_helper_shutdown() will cause
> panels to get
On Tue, 11 Jun 2024 10:27:44 -0700, Douglas Anderson wrote:
> Based on grepping through the source code this driver appears to be
> missing a call to drm_atomic_helper_shutdown() at system shutdown
> time. Among other things, this means that if a panel is in use that it
> won't be cleanly powered
On Mon, 10 Jun 2024 11:20:56 +0100, Amjad Ouled-Ameur wrote:
> komeda_pipeline_get_state() may return an error-valued pointer, thus
> check the pointer for negative or null value before dereferencing.
>
>
Applied to misc/kernel.git (drm-misc-fixes).
Thanks!
Maxime
Thomas Zimmermann writes:
Hello Thomas,
> Hi
>
> Am 10.06.24 um 10:47 schrieb Thomas Zimmermann:
>> Hi
>>
>> Am 04.06.24 um 10:03 schrieb Peng Fan (OSS):
>>> From: Peng Fan
>>>
>>> If 'info->screen_buffer' locates in vmalloc address space, virt_to_page
>>> will not be able to get correct
From: Douglas Anderson
Based on grepping through the source code, this driver appears to be
missing a call to drm_atomic_helper_shutdown() at system shutdown time.
This is important because drm_atomic_helper_shutdown() will cause
panels to get disabled cleanly which may be important for their
Hi Sam,
long time no see.
Am 11.06.24 um 19:55 schrieb Sam Ravnborg:
Hi Thomas.
On Tue, Jun 11, 2024 at 02:41:56PM +0200, Thomas Zimmermann wrote:
Duplicate FB_BLANK_ constants as BL_CORE_ constants in the backlight
header file. Allows backlight drivers to avoid including the fbdev
header
> > [geert: shmob_drm_remove() already calls drm_atomic_helper_shutdown]
> > Signed-off-by: Geert Uytterhoeven
> > Reviewed-by: Laurent Pinchart
> > ---
> > v2:
> > - Add Reviewed-by.
> >
> > Tested on Atmark Techno Armadillo-800-EVA.
> > ---
> &g
mipi_dsi_msleep expects struct mipi_dsi_multi_context to be passed as a
value and not as a reference.
Fixes: a2ab7cb169da ("drm/panel: himax-hx83102: use wrapped MIPI DCS functions")
Signed-off-by: Tejas Vipin
---
Changes in v2:
- Add Fixes tag
v1:
Use functions introduced in commit 966e397e4f60 ("drm/mipi-dsi: Introduce
mipi_dsi_*_write_seq_multi()") and commit f79d6d28d8fe
("drm/mipi-dsi: wrap more functions for streamline handling") for the
sony tulip truly nt35521 panel.
Signed-off-by: Tejas Vipin
---
Changes in
Hi Greg KH, Sasha,
Please pick up this patch for 5.15 stable tree. I have built a test kernel and
can confirm that it fixes affected users.
Downstream bug:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2068738
Thanks,
Matthew
Document OF graph on MMSYS/VDOSYS: this supports up to three DDP paths
per HW instance (so potentially up to six displays for multi-vdo SoCs).
The MMSYS or VDOSYS is always the first component in the DDP pipeline,
so it only supports an output port with multiple endpoints - where each
endpoint
Changes in v7:
- Fix typo in patch 3/3
Changes in v6:
- Added EPROBE_DEFER check to fix dsi/dpi false positive DT fallback case
- Dropped refcount of ep_out in mtk_drm_of_get_ddp_ep_cid()
- Fixed double refcount drop during path building
- Removed failure upon finding a DT-disabled path
It is impossible to add each and every possible DDP path combination
for each and every possible combination of SoC and board: right now,
this driver hardcodes configuration for 10 SoCs and this is going to
grow larger and larger, and with new hacks like the introduction of
mtk_drm_route which is
The display IPs in MediaTek SoCs support being interconnected with
different instances of DDP IPs (for example, merge0 or merge1) and/or
with different DDP IPs (for example, rdma can be connected with either
color, dpi, dsi, merge, etc), forming a full Display Data Path that
ends with an actual
Hi
Am 10.06.24 um 10:47 schrieb Thomas Zimmermann:
Hi
Am 04.06.24 um 10:03 schrieb Peng Fan (OSS):
From: Peng Fan
If 'info->screen_buffer' locates in vmalloc address space, virt_to_page
will not be able to get correct results. With CONFIG_DEBUG_VM and
CONFIG_DEBUG_VIRTUAL enabled on ARM64,
, 460 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/msm/qcom,sm7150-mdss.yaml
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
Documentation/devicetree/bindings/display/msm/qcom,sm7150
gt; > >
> > > On Tue, Apr 23, 2024 at 6:55 PM Xuxin Xiong
> > > wrote:
> > > >
> > > > Hi Doug, thank you!
> > > > We had reported this info to the CSOT to correct the vendor id.
> > > > If they confirm to fix this with the same pro
On Thu, May 16, 2024 at 08:20:50PM +0800, Yunfei Dong wrote:
> Need to call dma heap interface to allocate/free secure memory when playing
> secure video.
>
> Signed-off-by: Yunfei Dong
> ---
> .../media/platform/mediatek/vcodec/Kconfig| 1 +
> .../mediatek/vcodec/common/mtk_vcodec_util.c
On Wed, May 22, 2024 at 02:16:22PM +0300, Laurent Pinchart wrote:
> Hi Jefrey,
>
> Thank you for the patch.
>
> On Thu, May 16, 2024 at 08:20:42PM +0800, Yunfei Dong wrote:
> > From: Jeffrey Kardatzke
> >
> > Adds documentation for V4L2_MEMORY_FLAG_RESTRICTED
On Thu, May 16, 2024 at 08:20:41PM +0800, Yunfei Dong wrote:
> From: Jeffrey Kardatzke
>
> Verfies in the dmabuf implementations that if the restricted memory
> flag is set for a queue that the dmabuf submitted to the queue is
> unmappable.
>
> Signed-off-by: Jeffrey Kardatzke
> Signed-off-by:
stage_cfg);
}
Is this part of the change related to this patch? We moved from
hard-coding 0 and 1 for the stage_idx to stage_indices[pstate->stage]
will still result in the same values of 0 and 1 right?
The sharing will be achieved with the change b
Hi AngeloGioacchino,
kernel test robot noticed the following build errors:
[auto build test ERROR on robh/for-next]
[also build test ERROR on linus/master v6.10-rc3 next-20240611]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
(+)
> create mode 100644
> Documentation/devicetree/bindings/display/msm/qcom,sm7150-mdss.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
Documentation/devicetree/bindings/display/msm/qcom,sm7150-mds
On 5/22/2024 3:50 AM, Dmitry Baryshkov wrote:
In consequent modeset calls, the atomic_pre_enable() will be called
several times without calling atomic_post_disable() inbetween. Thus
Hi Dmitry,
Just wondering, where are you seeing multiple pre_enable() calls without
a post_disable()
On 3/13/2024 5:02 PM, Dmitry Baryshkov wrote:
Make dpu_rm_print_state() also output the SSPP allocation state.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 7 +++
1 file changed, 7 insertions(+)
Reviewed-by: Abhinav Kumar
(+)
> create mode 100644
> Documentation/devicetree/bindings/display/msm/qcom,sm7150-dpu.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
Documentation/devicetree/bindings/display/msm/qcom,sm7150-dpu.exam
On 3/13/2024 5:02 PM, Dmitry Baryshkov wrote:
Since we have enabled sharing of SSPP blocks between two planes, it is
now possible to use twice as much planes as there are hardware SSPP
blocks. Create additional overlay planes.
Signed-off-by: Dmitry Baryshkov
---
all planes are virtual, there are only 3 unique pairs to be
considered? Otherwise technically 6 pairs are possible.
General request:
Patches 1-9 : Add support for using 2 SSPPs in one plane
Patches 10-12 : Add support for using two rectangles of the same SSPP as
two virtual planes
Patch 13 :
Add definitions for the display hardware used on the Qualcomm SM7150
platform.
Signed-off-by: Danila Tikhonov
---
.../msm/disp/dpu1/catalog/dpu_5_2_sm7150.h| 349 ++
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 1 +
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 1 +
Document the MDSS hardware found on the Qualcomm SM7150 platform.
Signed-off-by: Danila Tikhonov
---
.../display/msm/qcom,sm7150-mdss.yaml | 460 ++
1 file changed, 460 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/msm/qcom,sm7150-mdss.yaml
Document the DPU hardware found on the Qualcomm SM7150 platform.
Signed-off-by: Danila Tikhonov
---
.../bindings/display/msm/qcom,sm7150-dpu.yaml | 145 ++
1 file changed, 145 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/msm/qcom,sm7150-dpu.yaml
Add support for MDSS on SM7150.
Signed-off-by: Danila Tikhonov
---
drivers/gpu/drm/msm/msm_mdss.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
index fab6ad4e5107c..d90b9471ba6ff 100644
---
This series adds MDSS and DPU support for SM7150.
To: Rob Clark
To: Abhinav Kumar
To: Dmitry Baryshkov
To: Sean Paul
To: Marijn Suijten
To: Maarten Lankhorst
To: Maxime Ripard
To: Thomas Zimmermann
To: David Airlie
To: Daniel Vetter
To: Rob Herring
To: Krzysztof Kozlowski
To: Conor
I'm trying to merge these into pci/next, but I'm having a hard time
writing the merge commit log. I want a one-sentence description of
each patch that tells me what the benefit of the patch is. Usually
the subject line is a good start.
"Reimplement plural devres functions" is kin
parser")
Remove it.
Signed-off-by: Dr. David Alan Gilbert
Acked-by: Danilo Krummrich
To which series does this patch belong?
Actually all of them were independent patches on drm
some of which are all in, so it can be taken by itself.
Need me to apply it?
Yes please!
Applied to dr
("drm/mipi-dsi: Introduce
> > > mipi_dsi_*_write_seq_multi()") and commit f79d6d28d8fe
> > > ("drm/mipi-dsi: wrap more functions for streamline handling") for the
> > > sony tulip truly nt35521 panel.
> > >
> > > Signed-off-by
d28d8fe
> > ("drm/mipi-dsi: wrap more functions for streamline handling") for the
> > sony tulip truly nt35521 panel.
> >
> > Signed-off-by: Tejas Vipin
> > ---
> >
> > Changes in v2:
> > - Fix patch format
> > - Fix c
(and is apparently force-enabled
on newer bridge chips with no option to disable it) unless the Pixel
clock are sourced from DSI clock (which is never the case with this
driver). That's what the [1] patch does.
But messing with the HFP isn't really working for all resolutions, so
this patch instead
Hi AngeloGioacchino,
kernel test robot noticed the following build errors:
[auto build test ERROR on robh/for-next]
[also build test ERROR on linus/master v6.10-rc3 next-20240611]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
On 5/22/2024 3:50 AM, Dmitry Baryshkov wrote:
In preparation of reworking the HDMI mode setting, switch pre_enable and
post_disable callbacks to their atomic variants.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Jessica Zhang
---
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 15
On 5/22/2024 3:50 AM, Dmitry Baryshkov wrote:
With the extp being the only "power" clock left, remove the surrounding
loops and handle the extp clock directly.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Jessica Zhang
---
drivers/gpu/drm/msm/hdmi/hdmi.c| 24
On 5/22/2024 3:50 AM, Dmitry Baryshkov wrote:
According to the vendor kernel [1] , the alt_iface clock should be
enabled together with the rest of HPD clocks, to make HPD to work
properly.
[1]
On Mon, Jun 10, 2024 at 3:15 PM Jason Gunthorpe wrote:
>
> On Mon, Jun 10, 2024 at 08:20:08PM +0100, Pavel Begunkov wrote:
> > On 6/10/24 16:16, David Ahern wrote:
>
> > > > There is no reason you shouldn't be able to use your fast io_uring
> > > > completion and lifecycle flow with DMABUF backed
Hi Thomas.
On Tue, Jun 11, 2024 at 02:41:56PM +0200, Thomas Zimmermann wrote:
> Duplicate FB_BLANK_ constants as BL_CORE_ constants in the backlight
> header file. Allows backlight drivers to avoid including the fbdev
> header file and removes a compile-time dependency between the two
>
On Mon, Jun 10, 2024 at 11:26 PM Christoph Hellwig wrote:
>
> On Mon, Jun 10, 2024 at 09:16:43AM -0600, David Ahern wrote:
> >
> > exactly. io_uring, page_pool, dmabuf - all kernel building blocks for
> > solutions. This why I was pushing for Mina's set not to be using the
> > name `devmem` - it
t; 2. 3x4 CTM
>> 3. HDR Multiplier
>> 4. 1D Curve Inverse EOTF
>> 5. 1D LUT
>> 6. 3D LUT
>> 7. 1D Curve EOTF
>> 8. 1D LUT
>>
>> This, essentially mirrors the color pipeline used by gamescope
>> and presented by Melissa Wen, with the exception of
Hi Robert,
On Mon, Jun 10, 2024 at 02:53:09PM +0200, Robert Foss wrote:
> On Fri, 31 May 2024 22:37:44 +0200, Sam Ravnborg wrote:
> > I had a few bridge related patches in an old branch.
> >
> > They were last posted here almost one year ago:
> >
Add Reviewed-by.
>
> Tested on Atmark Techno Armadillo-800-EVA.
> ---
> drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c | 8
> 1 file changed, 8 insertions(+)
FWIW: I've created a patch to list DRM modeset drivers that handle
shutdown properly [1]. For now "shmob-dr
shutdown() is called and as of commit 2a073968289d
("drm/atomic-helper: drm_atomic_helper_shutdown(NULL) should be a
noop") we don't need to confirm that "drm" is non-NULL.
Suggested-by: Maxime Ripard
Reviewed-by: Maxime Ripard
Reviewed-by: Fei Shao
Tested-by: Fei Shao
Signed-off-by
> > We had reported this info to the CSOT to correct the vendor id.
> > > If they confirm to fix this with the same product ID, we will submit a
> > > patch to fix this.
> >
> > FYI, "top posting" like this is generally frowned upon on kernel
> >
ocumentation changes for this
API, pls add that
>
> Signed-off-by: Paul Cercueil
> Signed-off-by: Nuno Sa
>
> ---
> v3: New patch
>
> v5: Replace with function dmaengine_prep_slave_dma_vec(), and struct
> 'dma_vec'.
> Note that at some point we will need to su
Hi Christian,
On 04/06/2024 17:05, Christian König wrote:
This should prevent buffer moves when the threshold is reached during
CS.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 36 --
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 22
mpile tests
fine. This is because the macro mipi_dsi_msleep() fell into a macro
trap. :( Specifically, we have:
#define mipi_dsi_msleep(ctx, delay)\
do { \
if (!ctx.accum_err) \
msleep(delay); \
} while
On 6/11/2024 7:05 AM, Tejas Vipin wrote:
mipi_dsi_msleep expects struct mipi_dsi_multi_context to be passed as a
value and not as a reference.
Fixes: a2ab7cb169da ("drm/panel: himax-hx83102: use wrapped MIPI DCS functions")
Signed-off-by: Tejas Vipin
Hi Tejas,
(for future reference, you
On Tue, Jun 11, 2024 at 2:35 AM wrote:
>
> From: Carsten Haitzler
>
> In a few places (core drm + AMD kfd driver), the ioctl handling uses a
> temporary 128 byte buffer on the stack to copy to/from user. ioctl data
> can have structs with types of much larger sizes than a byte and a
> system may
Use the passed mode instead of mixing use of passed mode and the stored
previous_mode. The passed mode is currenly always the previous_mode.
Also fix a small type and add a variable to help shorten a code line.
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 9
With CEC phys addr invalidation moved away from the irq handler there is
no longer a need for cec_notifier_mutex, remove it.
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git
Change to only call poweron/poweroff from atomic_enable/atomic_disable
ops instead of trying to keep a bridge_is_on state and poweron/off in
the hotplug irq handler.
A benefit of this is that drm mode_config mutex is always held at
poweron/off, something that may reduce the need for our own
Update successfully read EDID during hotplug processing to ensure the
connector diplay_info is always up-to-date.
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 12
1 file changed, 12 insertions(+)
diff --git
With the use of adjusted_mode directly from the crtc_state there is no
longer a need to store a copy in previous_mode, remove it and the now
unneeded mode_set ops.
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 19 +--
1 file changed, 1
Wait until the connector detect ops is called to invalidate CEC phys
addr instead of doing it directly from the irq handler.
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git
Fold the poweron and setup functions into one function and use the
adjusted_mode directly from the new crtc_state to remove the need of
storing previous_mode.
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 21 -
1 file changed, 8 insertions(+),
drm_edid_connector_update() is being called from bridge connector ops
and from detect and get_modes ops for dw-hdmi connector.
Change to use is_hdmi and has_audio from display_info directly instead
of keeping our own state in sink_is_hdmi and sink_has_audio.
Also remove the old and unused edid
This series ensure poweron/poweroff and CEC phys addr invalidation is
happening under drm mode_config mutex lock, and also ensure EDID is
updated (when the dw-hdmi connector is used) after a hotplug pulse.
These changes has mainly been tested on Rockchip devices together with a
forthcoming series
> sony tulip truly nt35521 panel.
>
> Signed-off-by: Tejas Vipin
> ---
>
> Changes in v2:
> - Fix patch format
> - Fix code style
>
> v1:
> https://lore.kernel.org/all/485eef24-ddad-466a-a89f-f9f226801...@gmail.com/
>
> ---
> .../panel/panel-son
On Sat, Jun 8, 2024 at 11:16 PM Asahi Lina wrote:
>
>
>
> On 5/22/24 6:23 AM, Rob Herring wrote:
> > On Mon, May 20, 2024 at 07:20:50PM +0200, Danilo Krummrich wrote:
> >> From: Asahi Lina
> >>
> >> Add abstractions for DRM drivers and devices. These go together in one
> >> commit since both are
Hi Jocelyn
Am 11.06.24 um 16:41 schrieb Jocelyn Falempe:
On 10/06/2024 16:06, Thomas Zimmermann wrote:
Set .detect_ctx() in struct drm_connector_helper_funcs to the
common helper drm_connector_helper_detect_from_ddc() and enable
polling for the connector. Mgag200 will now test for the
es so even if folks hate it we could
still land the rest of the series.
This was a "bonus" extra patch I added at the end of v3 of the series
("drm/panel: Remove most store/double-check of prepared/enabled
state") [1]. There, I had the note: "I came up with this idea to hel
ld it need backporting? IGT
cares about the atomic view of user_forcewake_count and individual
domains or what?
There is no serious back story. This came from a static code analyzer
report. I keep forgetting debugfs isn't mounted on production systems so
we don't have to backport this patch.
l want to handle
> > > reset-gpios and powergood-gpios before any devices 'appear'. Otherwise,
> > > you add devices on i2c1, start probing them, and then reset them at some
> > > async time?
> >
> > This is not a problem because the code is asserting reset before
> > loadi
On 10/06/2024 16:06, Thomas Zimmermann wrote:
Set .detect_ctx() in struct drm_connector_helper_funcs to the
common helper drm_connector_helper_detect_from_ddc() and enable
polling for the connector. Mgag200 will now test for the monitor's
presence by probing the DDC in regular intervals.
On 10/06/2024 16:06, Thomas Zimmermann wrote:
The BMC output can be viewed via the BMC's web interface or a
similar client. Represent it as virtual encoder and connector.
It's attached to the same CRTC as the VGA connector.
The connector's status depends on the physical connector's status.
On 10/06/2024 16:06, Thomas Zimmermann wrote:
The various models have common code for the VGA output's encoder and
connector. Move everything into a single shared source file. Remove some
obsolete initializer macros. No functional changes.
Thanks for this patch, it removes some duplication
or that
> module.
>
> Signed-off-by: Jeff Johnson
> ---
> This is the last in a set of patches to drivers/gpu/drm. The
> preceeding patches cleaned up subdirectiries that had more than one
> issue. This patch cleans up the stragglers. Let me know if any of
> these modifications need t
On 10/06/2024 10:24, Nirmoy Das wrote:
Hi Andi,
On 6/7/2024 4:51 PM, Andi Shyti wrote:
The forcewake count and domains listing is multi process critical
and the uncore provides a spinlock for such cases.
Lock the forcewake evaluation section in the fw_domains_show()
debugfs interface.
eaned up subdirectiries that had more than one
issue. This patch cleans up the stragglers. Let me know if any of
these modifications need to segregated into separate patches.
---
Changes in v2:
- Removed all references to drivers/gpu/drm/drm_mipi_dbi.c since it is already
being handled by:
On Tue, Jun 11, 2024 at 06:46:12AM -0700, Jeff Johnson wrote:
> On 4/25/24 05:56, Andy Shevchenko wrote:
...
> I'll remove this from my series
No need, Maxime already applied, and I see
665415092eca ("drm: add missing MODULE_DESCRIPTION() macros")
> Reviewed-by: Jeff Johnson
But thanks.
--
On 4/25/24 05:56, Andy Shevchenko wrote:
The modpost script is not happy
WARNING: modpost: missing MODULE_DESCRIPTION() in
drivers/gpu/drm/drm_mipi_dbi.o
because there is a missing module description.
Add it to the module.
Signed-off-by: Andy Shevchenko
---
On 6/11/2024 6:34 AM, Andy Shevchenko wrote:
> On Wed, Jun 05, 2024 at 11:38:31PM +0300, Andy Shevchenko wrote:
>> On Thu, Apr 25, 2024 at 03:56:26PM +0300, Andy Shevchenko wrote:
>>> The modpost script is not happy
>>>
>>> WARNING: modpost: missing MODULE_DESCRIPTION() in
>>>
Hi Daniele,
thanks for checking this patch.
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > index 0eaa1064242c..1181043bc5e9 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission
Hi Rodrigo,
...
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> > b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> > index 4fcba42cfe34..0437fd8217e0 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> > @@
On Wed, Jun 05, 2024 at 11:38:31PM +0300, Andy Shevchenko wrote:
> On Thu, Apr 25, 2024 at 03:56:26PM +0300, Andy Shevchenko wrote:
> > The modpost script is not happy
> >
> > WARNING: modpost: missing MODULE_DESCRIPTION() in
> > drivers/gpu/drm/drm_mipi_dbi.o
> >
> > because there is a
On Mon, 2024-06-03 at 15:36 +0200, Karolina Stolarek wrote:
> Update the tests and helpers to use unsigned kernel types.
>
> Signed-off-by: Karolina Stolarek
> Suggested-by: Thomas Hellström
Reviewed-by: Thomas Hellström
> ---
> drivers/gpu/drm/ttm/tests/ttm_bo_test.c | 12 ++--
On Mon, 2024-06-03 at 15:36 +0200, Karolina Stolarek wrote:
> The test files are GPL and MIT, so update the definitions
> accordingly.
>
> Signed-off-by: Karolina Stolarek
Reviewed-by: Thomas Hellström
> ---
> drivers/gpu/drm/ttm/tests/ttm_bo_test.c | 2 +-
>
On Mon, 2024-06-03 at 15:36 +0200, Karolina Stolarek wrote:
> Add mock resource manager to test ttm_bo_validate() with non-system
> placements. Update KConfig entry to enable DRM Buddy allocator, used
> by the mock manager. Update move function to do more than just assign
> a resource.
>
>
Replace FB_BLANK_ constants with their counterparts from the
backlight subsystem. The values are identical, so there's no
change in functionality.
Signed-off-by: Thomas Zimmermann
---
drivers/video/backlight/lm3533_bl.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
Replace FB_BLANK_ constants with their counterparts from the
backlight subsystem. The values are identical, so there's no
change in functionality.
Signed-off-by: Thomas Zimmermann
---
drivers/video/backlight/pwm_bl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Replace FB_BLANK_ constants with their counterparts from the
backlight subsystem. The values are identical, so there's no
change in functionality.
Signed-off-by: Thomas Zimmermann
---
drivers/video/backlight/jornada720_bl.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
Replace FB_BLANK_ constants with their counterparts from the
backlight subsystem. The values are identical, so there's no
change in functionality.
Signed-off-by: Thomas Zimmermann
---
drivers/video/backlight/ipaq_micro_bl.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
Replace FB_BLANK_ constants with their counterparts from the
backlight subsystem. The values are identical, so there's no
change in functionality.
Signed-off-by: Thomas Zimmermann
---
drivers/video/backlight/pandora_bl.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
Replace FB_BLANK_ constants with their counterparts from the
backlight subsystem. The values are identical, so there's no
change in functionality.
Signed-off-by: Thomas Zimmermann
---
drivers/video/backlight/kb3886_bl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Replace FB_BLANK_ constants with their counterparts from the
backlight subsystem. The values are identical, so there's no
change in functionality.
Signed-off-by: Thomas Zimmermann
---
drivers/video/backlight/mp3309c.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Replace FB_BLANK_ constants with their counterparts from the
backlight subsystem. The values are identical, so there's no
change in functionality.
Signed-off-by: Thomas Zimmermann
---
drivers/video/backlight/ams369fg06.c | 23 +++
1 file changed, 11 insertions(+), 12
Replace FB_BLANK_ constants with their counterparts from the
backlight subsystem. The values are identical, so there's no
change in functionality.
Signed-off-by: Thomas Zimmermann
---
drivers/video/backlight/rave-sp-backlight.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Replace FB_BLANK_ constants with their counterparts from the
backlight subsystem. The values are identical, so there's no
change in functionality.
Signed-off-by: Thomas Zimmermann
---
drivers/video/backlight/gpio_backlight.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff
Replace FB_BLANK_ constants with their counterparts from the
backlight subsystem. The values are identical, so there's no
change in functionality.
Signed-off-by: Thomas Zimmermann
---
drivers/video/backlight/aat2870_bl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Replace FB_BLANK_ constants with their counterparts from the
backlight subsystem. The values are identical, so there's no
change in functionality.
Signed-off-by: Thomas Zimmermann
---
drivers/video/backlight/pcf50633-backlight.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff
801 - 900 of 356370 matches
Mail list logo
