On Fri, Apr 8, 2022 at 9:22 AM Jagan Teki wrote:
>
> This series supports common bridge support for Samsung MIPI DSIM
> which is used in Exynos and i.MX8MM SoC's.
>
> Previous RFC can be available here [1].
>
> The final bridge supports both the Exynos and i.MX8MM DSI devices.
>
> On, summary this
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
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
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
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
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
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:
>
> 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
This patch addresses pre-existing issues that came up during the
review process of Sankeerth's series trying to add eDP for Qualcomm
SoCs [1].
It's really sorta two series but jammed into one. The first two
patches fix a problem with ps8640 when the panel doesn't finish
probing right away. The res
While it works, for the most part, to assume that the panel has
finished probing when devm_of_dp_aux_populate_ep_devices() returns,
it's a bit fragile. This is talked about at length in commit
a1e3667a9835 ("drm/bridge: ti-sn65dsi86: Promote the AUX channel to
its own sub-dev").
When reviewing the
As talked about in the kerneldoc for "struct dp_aux_ep_client" in this
patch and also in the past in commit a1e3667a9835 ("drm/bridge:
ti-sn65dsi86: Promote the AUX channel to its own sub-dev"), to use the
DP AUX bus properly we really need two "struct device"s. One "struct
device" is in charge of
Let's add support for being able to read the HPD pin even if it's
hooked directly to the controller. This will allow us to get more
accurate delays also lets us take away the waiting in the AUX transfer
functions of the eDP controller drivers.
Signed-off-by: Douglas Anderson
---
drivers/gpu/drm
Sometimes it's useful for users of the DP AUX bus (like panels) to be
able to poll HPD. Let's add a callback that allows DP AUX busses
drivers to provide this.
Suggested-by: Dmitry Baryshkov
Signed-off-by: Douglas Anderson
---
include/drm/dp/drm_dp_helper.h | 14 ++
1 file changed,
This implements the callback added by the patch ("drm/dp: Add
is_hpd_asserted() callback to struct drm_dp_aux").
With this change and all the two "DP AUX Endpoint" drivers changed to
use is_hpd_asserted(), we no longer need to have an long delay in the
AUX transfer function. It's up to the panel c
Let's add support for being able to read the HPD pin even if it's
hooked directly to the controller. This will let us take away the
waiting in the AUX transfer functions of the eDP controller drivers.
Signed-off-by: Douglas Anderson
---
.../gpu/drm/panel/panel-samsung-atna33xc20.c | 35 +++
This appears to be needed for video output to function correctly.
Signed-off-by: James Hilliard
---
drivers/gpu/drm/gma500/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig
index 0cff20265f97..ff8c7b6e87f5 100644
--- a/d
ARM64 always has CONFIG_MMU=y but adding a dependency on
COMPILE_TEST allows an arch with MMU optional (riscv in this case)
to build the hibmc driver, leading to a kconfig warning and
build errors, so restore the MMU dependency.
WARNING: unmet direct dependencies detected for DRM_TTM
Depends on
On Thu 07 Apr 04:34 CDT 2022, Paul Kocialkowski wrote:
> With the previous rework of drm_of_find_panel_or_bridge only
> -EPROBE_DEFER is returned while previous behavior allowed -ENODEV
> to be returned when the port/endpoint is either missing or unavailable.
>
> Make the default return code of t
Hi,
On 4/8/22 19:59, James Hilliard wrote:
> This appears to be needed for video output to function correctly.
More proof/justification?
> Signed-off-by: James Hilliard
> ---
> drivers/gpu/drm/gma500/Kconfig | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/gma500/Kco
This appears to be needed for video output to function correctly.
Signed-off-by: James Hilliard
---
Changes v1 -> v2:
- use depends instead of select
---
drivers/gpu/drm/gma500/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500
On 4/7/2022 4:12 PM, Rob Clark wrote:
On Thu, Apr 7, 2022 at 3:59 PM Abhinav Kumar wrote:
Hi Rob and Daniel
On 4/7/2022 3:51 PM, Rob Clark wrote:
On Wed, Apr 6, 2022 at 6:27 PM Jessica Zhang wrote:
On 3/31/2022 8:20 AM, Daniel Vetter wrote:
The stuff never really worked, and leads t
On 4/8/22 20:44, James Hilliard wrote:
> This appears to be needed for video output to function correctly.
>
> Signed-off-by: James Hilliard
> ---
> Changes v1 -> v2:
> - use depends instead of select
Thanks.
> ---
> drivers/gpu/drm/gma500/Kconfig | 2 ++
> 1 file changed, 2 insertions(+)
Select the efi framebuffer if efi is enabled.
This appears to be needed for video output to function correctly.
Signed-off-by: James Hilliard
---
Changes v2 -> v3:
- select EFI_FB instead of depending on it
Changes v1 -> v2:
- use depends instead of select
---
drivers/gpu/drm/gma500/Kconfig
Hi--
On 4/8/22 21:23, James Hilliard wrote:
> Select the efi framebuffer if efi is enabled.
>
> This appears to be needed for video output to function correctly.
>
> Signed-off-by: James Hilliard
Acked-by: Randy Dunlap
> ---
> Changes v2 -> v3:
> - select EFI_FB instead of depending on it
On Mon, Apr 04, 2022 at 12:52:14PM -0500, Rob Herring wrote:
> On Mon, Mar 28, 2022 at 08:09:54PM +0800, Xin Ji wrote:
> > Change bus-type define for DPI.
> >
> > Fixes: a43661e7e819 ("dt-bindings:drm/bridge:anx7625:add vendor define")
> >
> > Signed-off-by: Xin Ji
> > ---
> > .../devicetree/bi
Hi Yunfei,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on media-tree/master]
[also build test WARNING on v5.18-rc1 next-20220408]
[cannot apply to remoteproc/rproc-next drm-tip/drm-tip]
[If your patch is applied to the wrong git tree, kindly drop us a note
201 - 227 of 227 matches
Mail list logo
