On Sat, 9 Apr 2022 at 03:54, Abhinav Kumar wrote:
>
> For some vendor driver implementations, display hardware can
> be shared between the encoder used for writeback and the physical
> display.
>
> In addition resources such as clocks and interrupts can
> also be shared between writeback and the r
On Sat, 9 Apr 2022 at 03:54, Abhinav Kumar wrote:
>
> For vendors drivers which pass an already allocated and
> initialized encoder especially for cases where the encoder
> hardware is shared OR the writeback encoder shares the resources
> with the rest of the display pipeline introduce a new API,
On Sat, 9 Apr 2022 at 03:54, Abhinav Kumar wrote:
>
> Clients of drm_writeback_connector_init() initialize the
> possible_crtcs and then invoke the call to this API.
>
> To simplify things, allow passing possible_crtcs as a parameter
> to drm_writeback_connector_init() and make changes to the
> ot
vc4 driver currently embeds the drm_encoder into struct vc4_txp
and later on uses container_of to retrieve the vc4_txp from
the drm_encoder.
Make vc4 driver use the new API so that the embedded encoder model
can be retained in the driver and there is no change in
functionality.
changes in v7:
For some vendor driver implementations, display hardware can
be shared between the encoder used for writeback and the physical
display.
In addition resources such as clocks and interrupts can
also be shared between writeback and the real encoder.
To accommodate such vendor drivers and hardware, a
For vendors drivers which pass an already allocated and
initialized encoder especially for cases where the encoder
hardware is shared OR the writeback encoder shares the resources
with the rest of the display pipeline introduce a new API,
drm_writeback_connector_init_with_encoder() which expects
an
Clients of drm_writeback_connector_init() initialize the
possible_crtcs and then invoke the call to this API.
To simplify things, allow passing possible_crtcs as a parameter
to drm_writeback_connector_init() and make changes to the
other drm drivers to make them compatible with this change.
chang
There are some vendor drivers for which the writeback encoder shares
hardware resources such as clocks and interrupts with the rest of the
display pipeline. In addition, there can be use-cases where the
writeback encoder could be a shared encoder between the physical display
path and the writeback
On Sat, 9 Apr 2022 at 00:05, Bjorn Andersson wrote:
>
> Add an optional reference to the MDSS_CORE reset, which when specified
> can be used by the implementation to reset the hardware blocks.
>
> Signed-off-by: Bjorn Andersson
Reviewed-by: Dmitry Baryshkov
> ---
>
> Resending these two patch
On Sat, 9 Apr 2022 at 00:05, Bjorn Andersson wrote:
>
> It's typical for the bootloader to bring up the display for showing a
> boot splash or efi framebuffer. But in some cases the kernel driver ends
> up only partially configuring (in particular) the DPU, which might
> result in e.g. that two di
On Sat, 9 Apr 2022 at 00:05, Kuogee Hsieh wrote:
>
> There is possible circular locking dependency detected on event_mutex
> (see below logs). This is due to set fail safe mode is done at
> dp_panel_read_sink_caps() within event_mutex scope. To break this
> possible circular locking, this patch mo
On Sat, 9 Apr 2022 at 00:12, Chia-I Wu wrote:
>
> In practice, trace_dma_fence_init is good enough and almost no driver
> calls trace_dma_fence_emit. But this is still more correct in theory.
Please mention in the commit message that the trace_dma_fence_init()
is called from dma_fence_init().
Wi
On Fri, 8 Apr 2022 at 23:30, Kuogee Hsieh wrote:
>
>
> On 4/8/2022 5:27 AM, Dmitry Baryshkov wrote:
> > On 07/04/2022 00:28, Kuogee Hsieh wrote:
> >> dp_hpd_plug_handle() is responsible for setting up main link and send
> >> uevent to notify user space framework to start video stream. Similarly,
>
In practice, trace_dma_fence_init is good enough and almost no driver
calls trace_dma_fence_emit. But this is still more correct in theory.
Signed-off-by: Chia-I Wu
Cc: Rob Clark
---
drivers/gpu/drm/msm/msm_gpu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_gpu
It's typical for the bootloader to bring up the display for showing a
boot splash or efi framebuffer. But in some cases the kernel driver ends
up only partially configuring (in particular) the DPU, which might
result in e.g. that two different data paths attempts to push data to
the interface - wit
Add an optional reference to the MDSS_CORE reset, which when specified
can be used by the implementation to reset the hardware blocks.
Signed-off-by: Bjorn Andersson
---
Resending these two patches again as I put "v2" in the subject, even though I
meant v3. Sorry about that.
Changes since v2:
-
There is possible circular locking dependency detected on event_mutex
(see below logs). This is due to set fail safe mode is done at
dp_panel_read_sink_caps() within event_mutex scope. To break this
possible circular locking, this patch move setting fail safe mode
out of event_mutex scope.
[ 23.
It's typical for the bootloader to bring up the display for showing a
boot splash or efi framebuffer. But in some cases the kernel driver ends
up only partially configuring (in particular) the DPU, which might
result in e.g. that two different data paths attempts to push data to
the interface - wit
Add an optional reference to the MDSS_CORE reset, which when specified
can be used by the implementation to reset the hardware blocks.
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- None
.../devicetree/bindings/display/msm/dpu-qcm2290.yaml | 4
Documentation/devicetree/bi
On 4/8/2022 5:27 AM, Dmitry Baryshkov wrote:
On 07/04/2022 00:28, Kuogee Hsieh wrote:
dp_hpd_plug_handle() is responsible for setting up main link and send
uevent to notify user space framework to start video stream. Similarly,
dp_hdp_unplug_handle is responsible to send uevent to notify user
On Fri, 8 Apr 2022 at 20:38, Sankeerth Billakanti
wrote:
>
> > > > > > > > > > On Wed, 30 Mar 2022 at 19:04, Sankeerth Billakanti
> > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > The panel-edp driver modes needs to be validated
> > > > > > > > > > > differently from DP becau
On Fri, 8 Apr 2022 at 20:12, Sankeerth Billakanti
wrote:
>
> > > On Wed, Mar 30, 2022 at 9:04 AM Sankeerth Billakanti
> > > wrote:
> > >>
> > >> The aux_bus support with the dp_display driver will enable the dp
> > >> resources during msm_dp_modeset_init. The host_init has to return
> > >> early
> > > > > > > > > On Wed, 30 Mar 2022 at 19:04, Sankeerth Billakanti
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > The panel-edp driver modes needs to be validated
> > > > > > > > > > differently from DP because the link capabilities are
> > > > > > > > > > not available for EDP
Hi Doug and Dmitry
On 4/8/2022 7:58 AM, Dmitry Baryshkov wrote:
On Fri, 8 Apr 2022 at 16:43, Doug Anderson wrote:
Hi,
On Fri, Apr 8, 2022 at 5:20 AM Dmitry Baryshkov
wrote:
I guess my thought was that in DP you could still create the AUX bus
at probe time. Then for DP you just return an
> > On Wed, Mar 30, 2022 at 9:04 AM Sankeerth Billakanti
> > wrote:
> >>
> >> The aux_bus support with the dp_display driver will enable the dp
> >> resources during msm_dp_modeset_init. The host_init has to return
> >> early if the core is already initialized to prevent putting an
> >> additional
On Fri, 8 Apr 2022 at 18:50, Sankeerth Billakanti
wrote:
>
> Hi Dmitry,
>
> > > > > > > > On Wed, 30 Mar 2022 at 19:04, Sankeerth Billakanti
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > The panel-edp driver modes needs to be validated
> > > > > > > > > differently from DP because th
On 01/04/2022 02:23, Doug Anderson wrote:
Hi,
On Wed, Mar 30, 2022 at 9:04 AM Sankeerth Billakanti
wrote:
The aux_bus support with the dp_display driver will enable the dp
resources during msm_dp_modeset_init. The host_init has to return early
if the core is already initialized to prevent put
Hi Dmitry,
> > > > > > > On Wed, 30 Mar 2022 at 19:04, Sankeerth Billakanti
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > The panel-edp driver modes needs to be validated
> > > > > > > > differently from DP because the link capabilities are not
> > > > > > > > available for EDP by
> > > th
On Fri, 8 Apr 2022 at 16:43, Doug Anderson wrote:
>
> Hi,
>
> On Fri, Apr 8, 2022 at 5:20 AM Dmitry Baryshkov
> wrote:
> >
> > > I guess my thought was that in DP you could still create the AUX bus
> > > at probe time. Then for DP you just return an instant "transfer
> > > failed" from the AUX bu
On Fri, 8 Apr 2022 at 16:56, Doug Anderson wrote:
>
> Hi,
>
> On Fri, Apr 8, 2022 at 5:13 AM Dmitry Baryshkov
> wrote:
> >
> > On Fri, 8 Apr 2022 at 03:28, Doug Anderson wrote:
> > >
> > > Hi,
> > >
> > > On Thu, Apr 7, 2022 at 4:36 PM Dmitry Baryshkov
> > > wrote:
> > > >
> > > > The ps8640 dr
Hi,
On Fri, Apr 8, 2022 at 5:13 AM Dmitry Baryshkov
wrote:
>
> On Fri, 8 Apr 2022 at 03:28, Doug Anderson wrote:
> >
> > Hi,
> >
> > On Thu, Apr 7, 2022 at 4:36 PM Dmitry Baryshkov
> > wrote:
> > >
> > > The ps8640 driver looks 'working by coincidence'. It calls
> > > dp_aux_populate, then imme
Hi,
On Fri, Apr 8, 2022 at 5:20 AM Dmitry Baryshkov
wrote:
>
> > I guess my thought was that in DP you could still create the AUX bus
> > at probe time. Then for DP you just return an instant "transfer
> > failed" from the AUX bus if HPD isn't asserted. For eDP (as discussed
> > elsewhere) when w
Add calls to drm_bridge_add()/drm_bridge_remove() DRM bridges created by
the driver. This fixes the following warning.
WARNING: CPU: 0 PID: 1 at kernel/locking/mutex.c:579 __mutex_lock+0x840/0x9f4
DEBUG_LOCKS_WARN_ON(lock->magic != lock)
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted
On 07/04/2022 00:28, Kuogee Hsieh wrote:
dp_hpd_plug_handle() is responsible for setting up main link and send
uevent to notify user space framework to start video stream. Similarly,
dp_hdp_unplug_handle is responsible to send uevent to notify user space
framework to stop video stream and then te
On Thu, 7 Apr 2022 at 05:33, wrote:
>
> From: Xiaoke Wang
>
> kzalloc() is a memory allocation function which can return NULL when
> some internal memory errors happen. So it is better to check it to
> prevent potential wrong memory access.
>
> Besides, since mdp5_plane_reset() is void type, so w
On Thu, 7 Apr 2022 at 23:27, Rob Clark wrote:
>
> From: Rob Clark
>
> The fourth param is size, rather than range_end.
>
> Note that we could increase the address space size if we had a way to
> prevent buffers from spanning a 4G split, mostly just to avoid fw bugs
> with 64b math.
>
> Fixes: 84c
On Fri, 8 Apr 2022 at 03:26, Doug Anderson wrote:
>
> Hi,
>
> On Thu, Apr 7, 2022 at 4:46 PM Dmitry Baryshkov
> wrote:
> >
> > > The way I'm arguing it should work is that:
> > >
> > > 1. A whole bunch of the DP init code should move to the DP driver's
> > > probe function. This includes parsing
On Fri, 8 Apr 2022 at 03:28, Doug Anderson wrote:
>
> Hi,
>
> On Thu, Apr 7, 2022 at 4:36 PM Dmitry Baryshkov
> wrote:
> >
> > The ps8640 driver looks 'working by coincidence'. It calls
> > dp_aux_populate, then immediately after the function returns it checks
> > for the panel. If panel-edp is b
On Thu, 7 Apr 2022 at 17:05, Sankeerth Billakanti (QUIC)
wrote:
>
> Hi Dmitry,
>
> > > > > > On Wed, 30 Mar 2022 at 19:04, Sankeerth Billakanti
> > > > > > wrote:
> > > > > > >
> > > > > > > The panel-edp driver modes needs to be validated differently
> > > > > > > from DP because the link capabi
On Thu, 7 Apr 2022 at 19:51, Kuogee Hsieh wrote:
>
> There is possible circular locking dependency detected on event_mutex.
> To break this possible circular locking, this patch move setting fail
> safe mode out of event_mutex scope.
Please provide the lockdep trace here, it might help other peop
40 matches
Mail list logo
