Quoting Kuogee Hsieh (2022-02-17 13:36:28)
> Widebus feature will transmit two pixel data per pixel clock to interface.
> This feature now is required to be enabled to easy migrant to higher
s/migrant/migrate/?
> resolution applications in future. However since some legacy chipsets
s/in/in the/
Quoting Kuogee Hsieh (2022-02-17 13:36:27)
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index 0d315b4..0c22839 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -217,6
Quoting Kuogee Hsieh (2022-02-17 13:36:26)
> To improve code readability, this patch replace BIT(x) with
> correspond register bit define string
>
> Signed-off-by: Kuogee Hsieh
> ---
Reviewed-by: Stephen Boyd
Quoting Kuogee Hsieh (2022-02-17 13:36:25)
> The “DP timing” requires the active region to be defined in the
> bottom-right corner of the frame dimensions which is different
> with DSI. Therefore both display_h_end and display_v_end need
> to be adjusted accordingly. However current implementation
On 19/02/2022 02:56, Stephen Boyd wrote:
Quoting Dmitry Baryshkov (2022-02-11 14:40:02)
In commit 8a3b4c17f863 ("drm/msm/dp: employ bridge mechanism for display
enable and disable") the DP driver received a drm_bridge instance, which
is always attached to the encoder as a root bridge. However
On Sat, 19 Feb 2022 at 03:55, Stephen Boyd wrote:
>
> Quoting Dmitry Baryshkov (2022-02-18 14:32:53)
> > On 19/02/2022 00:31, Kuogee Hsieh wrote:
> > >
> > > On 2/11/2022 2:40 PM, Dmitry Baryshkov wrote:
> > >> There is little point in having both connector and root bridge
> > >> implementation
Quoting Dmitry Baryshkov (2022-02-18 14:32:53)
> On 19/02/2022 00:31, Kuogee Hsieh wrote:
> >
> > On 2/11/2022 2:40 PM, Dmitry Baryshkov wrote:
> >> There is little point in having both connector and root bridge
> >> implementation in the same driver. Move connector's functionality to the
> >>
Hi,
On Thu, Feb 10, 2022 at 3:58 AM Sankeerth Billakanti
wrote:
>
> Add support in the DP driver to utilize the custom eDP panels
> from drm/panels.
>
> An eDP panel is always connected to the platform. So, the eDP
> connector can be reported as always connected. The display mode
> will be
Quoting Dmitry Baryshkov (2022-02-11 14:40:04)
> It is possible to supply display-connector (bridge) to the DP interface,
> add support for parsing it too.
>
> Signed-off-by: Dmitry Baryshkov
> ---
Reviewed-by: Stephen Boyd
Quoting Dmitry Baryshkov (2022-02-11 14:40:02)
> In commit 8a3b4c17f863 ("drm/msm/dp: employ bridge mechanism for display
> enable and disable") the DP driver received a drm_bridge instance, which
> is always attached to the encoder as a root bridge. However it conflicts
> with the panel_bridge
Quoting Dmitry Baryshkov (2022-02-11 14:40:03)
> Currently DP driver will allocate panel bridge for eDP panels. This
> supports only the following topology:
>
> - eDP encoder ⇒ eDP panel (wrapped using panel-bridge)
>
> Simplify this code to just check if there is any next bridge in the
> chain
On 19/02/2022 00:31, Kuogee Hsieh wrote:
On 2/11/2022 2:40 PM, Dmitry Baryshkov wrote:
There is little point in having both connector and root bridge
implementation in the same driver. Move connector's functionality to the
bridge to let next bridge in chain to override it.
Signed-off-by:
On 19/02/2022 00:31, Kuogee Hsieh wrote:
On 2/11/2022 2:40 PM, Dmitry Baryshkov wrote:
There is little point in having both connector and root bridge
implementation in the same driver. Move connector's functionality to the
bridge to let next bridge in chain to override it.
Signed-off-by:
On 19/02/2022 00:29, Abhinav Kumar wrote:
On 2/18/2022 1:21 PM, Dmitry Baryshkov wrote:
On 18/02/2022 23:46, Abhinav Kumar wrote:
On 2/16/2022 11:12 PM, Dmitry Baryshkov wrote:
On 17/02/2022 09:33, Abhinav Kumar wrote:
On 2/16/2022 10:10 PM, Vinod Koul wrote:
On 16-02-22, 19:11,
On 2/11/2022 2:40 PM, Dmitry Baryshkov wrote:
There is little point in having both connector and root bridge
implementation in the same driver. Move connector's functionality to the
bridge to let next bridge in chain to override it.
Signed-off-by: Dmitry Baryshkov
This patch break primary
On 19/02/2022 00:28, Kuogee Hsieh wrote:
On 2/11/2022 2:40 PM, Dmitry Baryshkov wrote:
Currently DP driver will allocate panel bridge for eDP panels. This
supports only the following topology:
- eDP encoder ⇒ eDP panel (wrapped using panel-bridge)
Simplify this code to just check if there is
On 2/18/2022 1:21 PM, Dmitry Baryshkov wrote:
On 18/02/2022 23:46, Abhinav Kumar wrote:
On 2/16/2022 11:12 PM, Dmitry Baryshkov wrote:
On 17/02/2022 09:33, Abhinav Kumar wrote:
On 2/16/2022 10:10 PM, Vinod Koul wrote:
On 16-02-22, 19:11, Abhinav Kumar wrote:
On 2/10/2022 2:34 AM,
On 2/11/2022 2:40 PM, Dmitry Baryshkov wrote:
It is possible to supply display-connector (bridge) to the DP interface,
add support for parsing it too.
Signed-off-by: Dmitry Baryshkov
Tested-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_parser.c | 19 ---
1 file
On 2/11/2022 2:40 PM, Dmitry Baryshkov wrote:
Currently DP driver will allocate panel bridge for eDP panels. This
supports only the following topology:
- eDP encoder ⇒ eDP panel (wrapped using panel-bridge)
Simplify this code to just check if there is any next bridge in the
chain (be it a
On 18/02/2022 23:46, Abhinav Kumar wrote:
On 2/16/2022 11:12 PM, Dmitry Baryshkov wrote:
On 17/02/2022 09:33, Abhinav Kumar wrote:
On 2/16/2022 10:10 PM, Vinod Koul wrote:
On 16-02-22, 19:11, Abhinav Kumar wrote:
On 2/10/2022 2:34 AM, Vinod Koul wrote:
We cannot enable mode_3d when we
On 2/11/2022 2:40 PM, Dmitry Baryshkov wrote:
In commit 8a3b4c17f863 ("drm/msm/dp: employ bridge mechanism for display
enable and disable") the DP driver received a drm_bridge instance, which
is always attached to the encoder as a root bridge. However it conflicts
with the panel_bridge support
On 2/16/2022 11:12 PM, Dmitry Baryshkov wrote:
On 17/02/2022 09:33, Abhinav Kumar wrote:
On 2/16/2022 10:10 PM, Vinod Koul wrote:
On 16-02-22, 19:11, Abhinav Kumar wrote:
On 2/10/2022 2:34 AM, Vinod Koul wrote:
We cannot enable mode_3d when we are using the DSC. So pass
configuration
On 11/09/2021 19:39, AngeloGioacchino Del Regno wrote:
Add a function that returns whether the requested CTL is active or not:
this will be used in a later commit to fix command mode panel issues.
Signed-off-by: AngeloGioacchino Del Regno
Reviewed-by: Dmitry Baryshkov
---
On 11/09/2021 19:39, AngeloGioacchino Del Regno wrote:
In function dpu_encoder_phys_cmd_wait_for_commit_done we are always
checking if the relative CTL is started by waiting for an interrupt
to fire: it is fine to do that, but then sometimes we call this
function while the CTL is up and has
On 02/02/2022 12:48, Marijn Suijten wrote:
On 2022-01-20 02:12:51, Dmitry Baryshkov wrote:
On 22/12/2021 13:55, Marijn Suijten wrote:
As per the specification of DPU_CTL_ACTIVE_CFG the configuration of
active blocks should be proactively specified, and the pingpong block is
no different.
The
Hi,
On Thu, Feb 10, 2022 at 4:04 PM Bjorn Andersson
wrote:
>
> > +_edp {
> > + status = "okay";
> > +
> > + vdda-1p2-supply = <_l6b_1p2>;
> > + vdda-0p9-supply = <_l10c_0p8>;
> > + /delete-property/ pinctrl-names;
> > + /delete-property/ pinctrl-0;
>
> If the first device to
- Some DPU versions support inline rot90. It is supported only for
limited amount of UBWC formats.
- There are two versions of inline rotators, v1 (present on sm8250 and
sm7250) and v2 (sc7280). These versions differ in the list of supported
formats and in the scaler possibilities.
Changes in
From: Ville Syrjälä
struct drm_display_mode embeds a list head, so overwriting
the full struct with another one will corrupt the list
(if the destination mode is on a list). Use drm_mode_copy()
instead which explicitly preserves the list head of
the destination mode.
Even if we know the
From: Ville Syrjälä
Initialize on-stack modes with drm_mode_init() to guarantee
no stack garbage in the list head, or that we aren't copying
over another mode's list head.
Based on the following cocci script, with manual fixups:
@decl@
identifier M;
expression E;
@@
- struct drm_display_mode M
From: Ville Syrjälä
This on stack middle man mode looks entirely pointless.
Just duplicate the original mode directly.
Cc: Rob Clark
Cc: Sean Paul
Cc: Abhinav Kumar
Cc: linux-arm-...@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
I might be taking this a bit too far, but the lack of
consistency in our methods to copy drm_display_mode
structs around is bugging me.
The main worry is the embedded list head, which if
clobbered could lead to list corruption. I'd also
prefer to make sure even the valid
31 matches
Mail list logo
