On Wed, 11 Dec 2024, Dmitry Baryshkov wrote:
> On Wed, Dec 11, 2024 at 03:42:27PM +0100, Johan Hovold wrote:
>> On Wed, Dec 11, 2024 at 03:04:12PM +0200, Abel Vesa wrote:
>>
>> > +/**
>> > + * drm_dp_lttpr_set_transparent_mode - set the LTTPR in transparent mode
>> > + * @aux: DisplayPort AUX ch
On 11/12/2024 15:42, Johan Hovold wrote:
On Wed, Dec 11, 2024 at 03:04:12PM +0200, Abel Vesa wrote:
+/**
+ * drm_dp_lttpr_set_transparent_mode - set the LTTPR in transparent mode
+ * @aux: DisplayPort AUX channel
+ * @enable: Enable or disable transparent mode
+ *
+ * Returns 0 on success or
On Thu, Dec 12, 2024 at 09:31:09AM +0100, neil.armstr...@linaro.org wrote:
> On 11/12/2024 15:42, Johan Hovold wrote:
> >> +EXPORT_SYMBOL(drm_dp_lttpr_set_transparent_mode);
> >
> > This appears to be what the driver currently uses, but why not
> > EXPORT_SYMBOL_GPL?
>
> drivers/gpu/drm/display/
On Thu, 12 Dec 2024 at 04:59, Abhinav Kumar wrote:
>
>
>
> On 12/11/2024 3:41 PM, Dmitry Baryshkov wrote:
> > Having I/O regions inside a msm_dp_catalog_private() results in extra
> > layers of one-line wrappers for accessing the data. Move I/O region base
> > and size to the globally visible stru
On Thu, 12 Dec 2024 05:31:00 +,
Pavan Kondeti wrote:
>
> On Wed, Dec 11, 2024 at 10:40:02AM +, Marc Zyngier wrote:
> > On Wed, 11 Dec 2024 00:37:34 +,
> > Pavan Kondeti wrote:
> > >
> > > On Tue, Dec 10, 2024 at 09:24:03PM +, Marc Zyngier wrote:
> > > > > +static int a6xx_switch
On Thu, 12 Dec 2024 at 05:12, Abhinav Kumar wrote:
>
>
>
> On 12/11/2024 3:41 PM, Dmitry Baryshkov wrote:
> > Use msm_dp_utils_pack_sdp_header() and call msm_dp_write_link() directly
> > to program audio packet data. Use 0 as Packet ID, as it was not
> > programmed earlier.
> >
> > Reviewed-by: St
On Thu, 12 Dec 2024 at 05:26, Abhinav Kumar wrote:
>
>
>
> On 12/11/2024 3:41 PM, Dmitry Baryshkov wrote:
> > All other submodules pass arguments directly. Drop struct
> > msm_dp_panel_in that is used to wrap dp_panel's submodule args and pass
> > all data to msm_dp_panel_get() directly.
> >
> > R
On Wed, Dec 11, 2024 at 05:14:18PM -0800, Abhinav Kumar wrote:
>
>
> On 12/11/2024 3:41 PM, Dmitry Baryshkov wrote:
> > Rather than printing random garbage from stack and pretending that it is
> > the default safe_to_exit_level, set the variable beforehand.
> >
> > Fixes: d13e36d7d222 ("drm/msm/
On Thu, Dec 12, 2024 at 7:59 AM Akhil P Oommen wrote:
>
> On 12/5/2024 10:24 PM, Rob Clark wrote:
> > From: Rob Clark
> >
> > Performance counter usage falls into two categories:
> >
> > 1. Local usage, where the counter configuration, start, and end read
> >happen within (locally to) a singl
On Thu, Dec 12, 2024 at 08:50:12AM +, Marc Zyngier wrote:
> On Thu, 12 Dec 2024 05:31:00 +,
> Pavan Kondeti wrote:
> >
> > On Wed, Dec 11, 2024 at 10:40:02AM +, Marc Zyngier wrote:
> > > On Wed, 11 Dec 2024 00:37:34 +,
> > > Pavan Kondeti wrote:
> > > >
> > > > On Tue, Dec 10, 2
On 12/12/24 4:58 PM, Akhil P Oommen wrote:
On 12/5/2024 10:24 PM, Rob Clark wrote:
From: Rob Clark
Performance counter usage falls into two categories:
1. Local usage, where the counter configuration, start, and end read
happen within (locally to) a single SUBMIT. In this case, there is
6.1-stable review patch. If anyone has any objections, please let me know.
--
From: Randy Dunlap
commit a722511b18268bd1f7084eee243af416b85f288f upstream.
DRM_MSM no longer needs DEVFREQ_GOV_SIMPLE_ONDEMAND (since commit
dbd7a2a941b8 ("PM / devfreq: Fix build issues with devfr
This is a note to let you know that I've just added the patch titled
drm/msm: DEVFREQ_GOV_SIMPLE_ONDEMAND is no longer needed
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:
On Thu, Dec 12, 2024 at 9:08 AM Rob Clark wrote:
>
> On Thu, Dec 12, 2024 at 7:59 AM Akhil P Oommen
> wrote:
> >
> > On 12/5/2024 10:24 PM, Rob Clark wrote:
> > > From: Rob Clark
> > >
> > > Performance counter usage falls into two categories:
> > >
> > > 1. Local usage, where the counter confi
On 12/5/2024 10:24 PM, Rob Clark wrote:
> From: Rob Clark
>
> Performance counter usage falls into two categories:
>
> 1. Local usage, where the counter configuration, start, and end read
>happen within (locally to) a single SUBMIT. In this case, there is
>no dependency on counter confi
On 12/12/2024 12:53 AM, Dmitry Baryshkov wrote:
On Thu, 12 Dec 2024 at 05:26, Abhinav Kumar wrote:
On 12/11/2024 3:41 PM, Dmitry Baryshkov wrote:
All other submodules pass arguments directly. Drop struct
msm_dp_panel_in that is used to wrap dp_panel's submodule args and pass
all data to
On 12/12/2024 10:31 AM, Abhinav Kumar wrote:
On 12/12/2024 12:58 AM, Dmitry Baryshkov wrote:
On Wed, Dec 11, 2024 at 05:14:18PM -0800, Abhinav Kumar wrote:
On 12/11/2024 3:41 PM, Dmitry Baryshkov wrote:
Rather than printing random garbage from stack and pretending that
it is
the defaul
On 12/12/2024 12:58 AM, Dmitry Baryshkov wrote:
On Wed, Dec 11, 2024 at 05:14:18PM -0800, Abhinav Kumar wrote:
On 12/11/2024 3:41 PM, Dmitry Baryshkov wrote:
Rather than printing random garbage from stack and pretending that it is
the default safe_to_exit_level, set the variable beforehand
On Fri, 13 Dec 2024 at 01:53, Abhinav Kumar wrote:
>
>
>
> On 12/12/2024 2:28 PM, Dmitry Baryshkov wrote:
> > On Thu, 12 Dec 2024 at 23:41, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 12/11/2024 3:41 PM, Dmitry Baryshkov wrote:
> >>> Use msm_dp_utils_pack_sdp_header() and call msm_dp_write_l
On 11.12.2024 9:29 AM, Neil Armstrong wrote:
> Now all the DDR bandwidth voting via the GPU Management Unit (GMU)
> is in place, declare the Bus Control Modules (BCMs) and the
> corresponding parameters in the GPU info struct.
>
> Reviewed-by: Dmitry Baryshkov
> Reviewed-by: Akhil P Oommen
> Sig
On 11.12.2024 9:29 AM, Neil Armstrong wrote:
> The Adreno GPU Management Unit (GMU) can also scale the ddr
> bandwidth along the frequency and power domain level, but for
> now we statically fill the bw_table with values from the
> downstream driver.
>
> Only the first entry is used, which is a di
On 11.12.2024 9:29 AM, Neil Armstrong wrote:
> The Adreno GPU Management Unit (GMU) can also scale the DDR Bandwidth
> along the Frequency and Power Domain level, until now we left the OPP
> core scale the OPP bandwidth via the interconnect path.
>
> In order to enable bandwidth voting via the GPU
On 12/12/2024 21:21, Konrad Dybcio wrote:
On 11.12.2024 9:29 AM, Neil Armstrong wrote:
The Adreno GPU Management Unit (GMU) can also scale the DDR Bandwidth
along the Frequency and Power Domain level, until now we left the OPP
core scale the OPP bandwidth via the interconnect path.
In order to
On 12/12/2024 21:32, Konrad Dybcio wrote:
On 11.12.2024 9:29 AM, Neil Armstrong wrote:
Now all the DDR bandwidth voting via the GPU Management Unit (GMU)
is in place, declare the Bus Control Modules (BCMs) and the
corresponding parameters in the GPU info struct.
Reviewed-by: Dmitry Baryshkov
R
On 12/12/2024 21:10, Konrad Dybcio wrote:
On 11.12.2024 9:29 AM, Neil Armstrong wrote:
The Adreno GPU Management Unit (GMU) can also scale the ddr
bandwidth along the frequency and power domain level, but for
now we statically fill the bw_table with values from the
downstream driver.
Only the f
On 12/12/2024 20:55, Konrad Dybcio wrote:
On 11.12.2024 9:29 AM, Neil Armstrong wrote:
The Adreno GPU Management Unit (GMU) can also scale DDR Bandwidth along
the Frequency and Power Domain level, but by default we leave the
OPP core scale the interconnect ddr path.
While scaling via the interc
Quoting Abhinav Kumar (2024-12-11 11:50:26)
> Similar to the r_pipe sspp protect, add a check to protect
> the pipe state prints to avoid NULL ptr dereference for cases when
> the state is dumped without a corresponding atomic_check() where the
> pipe->sspp is assigned.
>
> Fixes: 31f7148fd370 ("dr
On 11.12.2024 9:29 AM, Neil Armstrong wrote:
> The Adreno GPU Management Unit (GMU) can also scale DDR Bandwidth along
> the Frequency and Power Domain level, but by default we leave the
> OPP core scale the interconnect ddr path.
>
> While scaling via the interconnect path was sufficient, newer G
Quoting Dmitry Baryshkov (2024-12-11 15:41:40)
> Move msm_dp_read()/msm_write_foo() functions to the dp_catalog.h,
> allowing other modules to access the data directly.
>
> Signed-off-by: Dmitry Baryshkov
> ---
Reviewed-by: Stephen Boyd
Quoting Dmitry Baryshkov (2024-12-11 15:41:41)
> Move all register-level functions to dp_aux.c, inlining one line
> wrappers during this process.
>
> Signed-off-by: Dmitry Baryshkov
> ---
Reviewed-by: Stephen Boyd
Quoting Dmitry Baryshkov (2024-12-11 15:41:35)
> - Fix register programming in the dp_audio module
> - Rework most of the register programming functions to be local to the
> calling module rather than accessing everything through huge
> dp_catalog monster.
>
> Signed-off-by: Dmitry Baryshkov
>
> dpu_kms->perf.perf_cfg);
> +
> + /*
> + * The given mode, adjusted for the perf clock factor, should not exceed
> + * the max core clock rate
> + */
> + if (adjusted_mode_clk > dpu_kms->perf.max_core_clk_rate / 1000)
> + return MODE_CLOCK_HIGH;
> +
> /*
>* max crtc width is equal to the max mixer width * 2 and max height is
> 4K
>*/
>
> ---
> base-commit: 423c1c96d6b2d3bb35072e33a5fdd8db6d2c0a74
> change-id: 20241212-filter-mode-clock-8cb2e769f05b
>
> Best regards,
> --
> Jessica Zhang
>
--
With best wishes
Dmitry
On 12/12/2024 2:28 PM, Dmitry Baryshkov wrote:
On Thu, 12 Dec 2024 at 23:41, Abhinav Kumar wrote:
On 12/11/2024 3:41 PM, Dmitry Baryshkov wrote:
Use msm_dp_utils_pack_sdp_header() and call msm_dp_write_link() directly
to program audio packet data. Use 0 as Packet ID, as it was not
progra
On Thu, Dec 12, 2024 at 10:40:46AM +, Mark Rutland wrote:
> On Thu, Dec 12, 2024 at 08:50:12AM +, Marc Zyngier wrote:
> > On Thu, 12 Dec 2024 05:31:00 +,
> > Pavan Kondeti wrote:
> > >
> > > On Wed, Dec 11, 2024 at 10:40:02AM +, Marc Zyngier wrote:
> > > > On Wed, 11 Dec 2024 00:3
e-commit: 423c1c96d6b2d3bb35072e33a5fdd8db6d2c0a74
change-id: 20241212-filter-mode-clock-8cb2e769f05b
Best regards,
--
Jessica Zhang
On 12/12/2024 12:52 AM, Dmitry Baryshkov wrote:
On Thu, 12 Dec 2024 at 04:59, Abhinav Kumar wrote:
On 12/11/2024 3:41 PM, Dmitry Baryshkov wrote:
Having I/O regions inside a msm_dp_catalog_private() results in extra
layers of one-line wrappers for accessing the data. Move I/O region base
On 12/11/2024 3:41 PM, Dmitry Baryshkov wrote:
Use msm_dp_utils_pack_sdp_header() and call msm_dp_write_link() directly
to program audio packet data. Use 0 as Packet ID, as it was not
programmed earlier.
Reviewed-by: Stephen Boyd
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/
On Thu, 12 Dec 2024 at 21:15, Abhinav Kumar wrote:
>
>
>
> On 12/12/2024 12:52 AM, Dmitry Baryshkov wrote:
> > On Thu, 12 Dec 2024 at 04:59, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 12/11/2024 3:41 PM, Dmitry Baryshkov wrote:
> >>> Having I/O regions inside a msm_dp_catalog_private() resu
On Thu, 12 Dec 2024 at 20:53, Abhinav Kumar wrote:
>
>
>
> On 12/12/2024 10:31 AM, Abhinav Kumar wrote:
> >
> >
> > On 12/12/2024 12:58 AM, Dmitry Baryshkov wrote:
> >> On Wed, Dec 11, 2024 at 05:14:18PM -0800, Abhinav Kumar wrote:
> >>>
> >>>
> >>> On 12/11/2024 3:41 PM, Dmitry Baryshkov wrote:
>
On Thu, 12 Dec 2024 at 23:41, Abhinav Kumar wrote:
>
>
>
> On 12/11/2024 3:41 PM, Dmitry Baryshkov wrote:
> > Use msm_dp_utils_pack_sdp_header() and call msm_dp_write_link() directly
> > to program audio packet data. Use 0 as Packet ID, as it was not
> > programmed earlier.
> >
> > Reviewed-by: St
40 matches
Mail list logo
