On Thu, 10 Apr 2025 at 18:33, Ville Syrjala
wrote:
> From: Ville Syrjälä
>
> Pass long the format information from the top to .fb_create()
s/long/along/
> so that we can avoid redundant (and somewhat expensive) lookups
> in the drivers.
[...]
> Signed-off-by: Ville Syrjälä
> drivers/gpu/dr
On Fri, 14 Mar 2025 11:36:47 +0200, Dmitry Baryshkov wrote:
> A lot of DisplayPort bridges use HDMI Codec in order to provide audio
> support. Present DRM HDMI Audio support has been written with the HDMI
> and in particular DRM HDMI Connector framework support, however those
> audio helpers can be
On Mon, Apr 07, 2025 at 04:23:33PM +0200, Luca Ceresoli wrote:
> This is the new API for allocating DRM bridges.
>
> Signed-off-by: Luca Ceresoli
>
> ---
>
> Cc: Abhinav Kumar
> Cc: Marijn Suijten
> Cc: Rob Clark
> Cc: Sean Paul
> ---
> drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 9 -
From: Konrad Dybcio
The Highest Bank address Bit value can change based on memory type used.
Attempt to retrieve it dynamically, and fall back to a reasonable
default (the one used prior to this change) on error.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 13
On 08/04/2025 12:38, Ayushi Makhija wrote:
>>> +properties:
>>> + compatible:
>>> +items:
>>
>> contains
>>
>>> + - const: qcom,sa8775p-dsi-ctrl
>>> + - const: qcom,mdss-dsi-ctrl
>>
>> Drop fallback
>>
>
> Hi Krzysztof,
>
> I couldn't understand the meaning of
Hi Philipp,
On Wed, 9 Apr 2025 14:06:37 +0200
Philipp Stanner wrote:
> dma_fence_is_signaled()'s name strongly reads as if this function were
> intended for checking whether a fence is already signaled. Also the
> boolean it returns hints at that.
>
> The function's behavior, however, is more
On Thu, Apr 10, 2025 at 08:08:17AM +0200, Krzysztof Kozlowski wrote:
> On 09/04/2025 17:24, Dmitry Baryshkov wrote:
> > On 09/04/2025 09:07, Krzysztof Kozlowski wrote:
> >> On 08/04/2025 22:26, Dmitry Baryshkov wrote:
> > + - const: qcom,sa8775p-dsi-ctrl
> > + - co
Hi,
On Mon, Apr 07, 2025 at 05:27:39PM +0200, Luca Ceresoli wrote:
> This is the new API for allocating DRM bridges.
>
> The devm lifetime management of this driver is peculiar. The underlying
> device for the panel_bridge is the panel, and the devm lifetime is tied the
> panel device (panel->dev
On 3/12/2025 5:15 PM, Krzysztof Kozlowski wrote:
> On Tue, Mar 11, 2025 at 05:54:38PM +0530, Ayushi Makhija wrote:
>> Document DSI controller and phy on SA8775P platform.
>>
>> Signed-off-by: Ayushi Makhija
>> ---
>> .../display/msm/qcom,sa8775p-mdss.yaml| 188 ++
>> 1 fil
There is a duplication between msm_hdmi_audio_update() calls in
msm_hdmi_set_timings() and msm_hdmi_bridge_atomic_pre_enable(). Merge
those two calls to be performed unconditionally at
msm_hdmi_bridge_atomic_pre_enable().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
On Thu, Apr 10, 2025 at 06:37:54PM +0530, Ayushi Makhija wrote:
> Hi Dmirity/Konard
>
> On 4/7/2025 1:42 AM, Dmitry Baryshkov wrote:
> > On Fri, Apr 04, 2025 at 05:25:36PM +0530, Ayushi Makhija wrote:
> >> Add anx7625 DSI to DP bridge device nodes.
> >>
> >> Signed-off-by: Ayushi Makhija
> >> ---
On Thu, Apr 10, 2025 at 07:43:43PM +0200, Konrad Dybcio wrote:
> SMEM allows the OS to retrieve information about the DDR memory.
> Among that information, is a semi-magic value called 'HBB', or Highest
> Bank address Bit, which multimedia drivers (for hardware like Adreno
> and MDSS) must retrieve
Hi Ville,
kernel test robot noticed the following build warnings:
[auto build test WARNING on linus/master]
[also build test WARNING on v6.15-rc1 next-20250410]
[cannot apply to drm-exynos/exynos-drm-next tegra/for-next
rmk-arm/drm-armada-devel rmk-arm/drm-armada-fixes]
[If your patch is
On 4/9/25 5:30 PM, Connor Abbott wrote:
> On Wed, Apr 9, 2025 at 11:22 AM Konrad Dybcio
> wrote:
>>
>> On 4/9/25 5:12 PM, Connor Abbott wrote:
>>> On Wed, Apr 9, 2025 at 10:48 AM Konrad Dybcio
>>> wrote:
From: Konrad Dybcio
The Highest Bank address Bit value can change based
Hi Ville,
Thank you for the patch.
On Thu, Apr 10, 2025 at 07:32:04PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Soon all drivers should have the format info already available in the
> places where they call drm_helper_mode_fill_fb_struct(). Allow it to
> be passed along into drm_hel
Hi Ville,
Thank you for the patch.
On Thu, Apr 10, 2025 at 07:32:03PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Pass long the format information from the top to .fb_create()
> so that we can avoid redundant (and somewhat expensive) lookups
> in the drivers.
>
> Done with cocci (wit
On Thu, Apr 10, 2025 at 05:51:38PM +0200, Anthony Ruhier wrote:
> Hi,
>
> Sorry I should have gave an update on this: I don't think the lockups are
> related to this patch series, the same problem happens without applying these
> patches. It seems to increase by a lot the chances that a GPU lockup
Hi Ville,
Thank you for the patch.
On Thu, Apr 10, 2025 at 07:32:01PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Decouple drm_get_format_info() from struct drm_mode_fb_cmd2 and just
> pass the pixel format+modifier combo in by hand.
>
> We may want to use drm_get_format_info() outsi
On Thu, Apr 10, 2025 at 07:32:14PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Plumb the format info from .fb_create() all the way to
> drm_helper_mode_fill_fb_struct() to avoid the redundant
> lookups.
>
> For the fbdev case a manual drm_get_format_info() lookup
> is needed.
>
> Cc:
Hi Dmirity/Konard
On 4/7/2025 1:42 AM, Dmitry Baryshkov wrote:
> On Fri, Apr 04, 2025 at 05:25:36PM +0530, Ayushi Makhija wrote:
>> Add anx7625 DSI to DP bridge device nodes.
>>
>> Signed-off-by: Ayushi Makhija
>> ---
>> arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi | 208 -
>>
This is the new API for allocating DRM bridges.
Signed-off-by: Luca Ceresoli
---
Cc: Kieran Bingham
Cc: Laurent Pinchart
Cc: Tomi Valkeinen
---
drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/renesas
On Thu, Apr 10, 2025 at 10:52:21AM +0800, Chen Ni wrote:
> Replace comma between expressions with semicolons.
>
> Using a ',' in place of a ';' can have unintended side effects.
> Although that is not the case here, it is seems best to use ';'
> unless ',' is intended.
>
> Found by inspection.
>
On Wed, 2025-04-09 at 16:10 +0200, Christian König wrote:
> Am 09.04.25 um 16:01 schrieb Philipp Stanner:
> > On Wed, 2025-04-09 at 15:14 +0200, Christian König wrote:
> > > Am 09.04.25 um 14:56 schrieb Philipp Stanner:
> > > > On Wed, 2025-04-09 at 14:51 +0200, Philipp Stanner wrote:
> > > > > On
From: Konrad Dybcio
The Highest Bank address Bit value can change based on memory type used.
Attempt to retrieve it dynamically, and fall back to a reasonable
default (the one used prior to this change) on error.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/msm_mdss.c | 30 +++
From: Konrad Dybcio
The Highest Bank address Bit value can change based on memory type used.
Attempt to retrieve it dynamically, and fall back to a reasonable
default (the one used prior to this change) on error.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 15
From: Konrad Dybcio
The Highest Bank address Bit value can change based on memory type used.
Attempt to retrieve it dynamically, and fall back to a reasonable
default (the one used prior to this change) on error.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 12
From: Konrad Dybcio
Most modern Qualcomm platforms (>= SM8150) expose information about the
DDR memory present on the system via SMEM.
Details from this information is used in various scenarios, such as
multimedia drivers configuring the hardware based on the "Highest Bank
address Bit" (hbb), or
SMEM allows the OS to retrieve information about the DDR memory.
Among that information, is a semi-magic value called 'HBB', or Highest
Bank address Bit, which multimedia drivers (for hardware like Adreno
and MDSS) must retrieve in order to program the IP blocks correctly.
This series introduces a
From: Ville Syrjälä
Plumb the format info from .fb_create() all the way to
drm_helper_mode_fill_fb_struct() to avoid the redundant
lookups.
For the fbdev case a manual drm_get_format_info() lookup
is needed.
Cc: Rob Clark
Cc: Abhinav Kumar
Cc: Dmitry Baryshkov
Cc: Sean Paul
Cc: Marijn Suijt
From: Ville Syrjälä
Soon all drivers should have the format info already available in the
places where they call drm_helper_mode_fill_fb_struct(). Allow it to
be passed along into drm_helper_mode_fill_fb_struct() instead of doing
yet another redundant lookup.
Start by always passing in NULL and
From: Ville Syrjälä
Pass long the format information from the top to .fb_create()
so that we can avoid redundant (and somewhat expensive) lookups
in the drivers.
Done with cocci (with some manual fixups):
@@
identifier func =~ ".*create.*";
identifier dev, file, mode_cmd;
@@
struct drm_framebuff
From: Ville Syrjälä
Decouple drm_get_format_info() from struct drm_mode_fb_cmd2 and just
pass the pixel format+modifier combo in by hand.
We may want to use drm_get_format_info() outside of the normal
addfb paths where we won't have a struct drm_mode_fb_cmd2, and
creating a temporary one just fo
Hi,
Tested-by: Anthony Ruhier
--
Anthony Ruhier
Hi,
Sorry I should have gave an update on this: I don't think the lockups are
related to this patch series, the same problem happens without applying these
patches. It seems to increase by a lot the chances that a GPU lockup happens at
start, however, so I could use that to debug the real problem.
[AMD Official Use Only - AMD Internal Distribution Only]
Hi Philipp,
I feel like the problem has two parts. The documentation does not make explicit
that DMA_FENCE_FLAG_SIGNALED_BIT is "caching" the hardware state when a fence
is backed by hardware, so what dma_fence_is_signaled here is doing i
Hi,
I've rebased the series on top of drm-next, applied the minor tweaks suggested by Tvrtko on v8 and
the R-b tags. The result can be found on gitlab.fdo:
https://gitlab.freedesktop.org/pepp/linux/-/commits/improve_gpu_scheduler_trace_v9
I believe it's ready to be merged, unless I've missed
Replace comma between expressions with semicolons.
Using a ',' in place of a ';' can have unintended side effects.
Although that is not the case here, it is seems best to use ';'
unless ',' is intended.
Found by inspection.
No functional change intended.
Compile tested only.
Signed-off-by: Chen
Am 09.04.25 um 17:04 schrieb Philipp Stanner:
> On Wed, 2025-04-09 at 16:10 +0200, Christian König wrote:
>>> I only see improvement by making things more obvious.
>>>
>>> In any case, how would you call a wrapper that just does
>>> test_bit(IS_SIGNALED, …) ?
>> Broken, that was very intentionally
38 matches
Mail list logo
