On Thu, Apr 14, 2022 at 05:00:04PM +0800, Hsin-Yi Wang wrote:
> Speaker may share I2S with DP and .get_eld callback will be called when
> speaker is playing. When HDMI wans't connected, the connector will be
> null. Instead of return an error, fill in empty ELD.
>
> Signed-off-by: Hsin-Yi Wang
>
i.MX8qxp SoC embeds a Mixel MIPI DPHY + LVDS PHY combo which supports
either a MIPI DSI display or a LVDS display. The PHY mode is controlled
by SCU firmware and the driver would call a SCU firmware function to
configure the PHY mode. The single LVDS PHY has 4 data lanes to support
a LVDS
Add support for Mixel MIPI DPHY + LVDS PHY combo IP
as found on Freescale i.MX8qxp SoC.
Cc: Guido Günther
Cc: Kishon Vijay Abraham I
Cc: Vinod Koul
Cc: Rob Herring
Cc: NXP Linux Team
Reviewed-by: Rob Herring
Reviewed-by: Guido Günther
Signed-off-by: Liu Ying
---
v7->v8:
* No change.
This patch converts the mixel,mipi-dsi-phy binding to
DT schema format using json-schema.
Comparing to the plain text version, the new binding adds
the 'assigned-clocks', 'assigned-clock-parents' and
'assigned-clock-rates' properites, otherwise 'make dtbs_check'
would complain that there are
This patch allows LVDS PHYs to be configured through
the generic functions and through a custom structure
added to the generic union.
The parameters added here are based on common LVDS PHY
implementation practices. The set of parameters
should cover all potential users.
Cc: Kishon Vijay Abraham
The Northwest Logic MIPI DSI host controller embedded in i.MX8qxp
works with a Mixel MIPI DPHY + LVDS PHY combo to support either
a MIPI DSI display or a LVDS display. So, this patch calls
phy_set_mode() from nwl_dsi_mode_set() to set PHY mode to MIPI DPHY
explicitly.
Cc: Guido Günther
Cc:
Hi,
This is the v8 series to add i.MX8qxp LVDS PHY mode support for the Mixel
PHY in the Freescale i.MX8qxp SoC.
The Mixel PHY is MIPI DPHY + LVDS PHY combo, which can works in either
MIPI DPHY mode or LVDS PHY mode. The PHY mode is controlled by i.MX8qxp
SCU firmware. The PHY driver would
On Sun, Apr 17, 2022 at 11:52 AM Vasily Khoruzhick wrote:
>
> On Sun, Apr 17, 2022 at 9:15 AM Torsten Duwe wrote:
> >
> > Align the power-up sequence with the known-good procedure documented in [1]:
> > un-swap dvdd12 and dvdd25, and allow a little extra time for them to settle
> > before
On 4/11/2022 4:49 PM, Dmitry Baryshkov wrote:
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
Hi,
On Fri, Apr 15, 2022 at 5:54 PM Dmitry Baryshkov
wrote:
>
> >>> * They rely on there being exactly 1 AUX device, or we make it a rule
> >>> that we wait for all AUX devices to probe (?)
> >>
> >> Is the backlight a separate device on an AUX bus? Judging from
> >>
Current DP driver implementation, event thread is kept running
after DP display is unbind. This patch fix this problem by disabling
DP irq and stop event thread to exit gracefully at dp_display_unbind().
Changes in v2:
-- start event thread at dp_display_bind()
Changes in v3:
-- disable all HDP
On Tue, 2022-04-12 at 11:15 +0200, Christian König wrote:
>
> Hi Zack,
>
> Reviewed-by: Christian König for the
> entire
> series.
>
> One nit pick is that I want to get rid of using ttm_manager_type() in
> drivers and use pointers to the members directly. But that's
> something
> for a later
Hi Laurent,
Thanks for the feedback.
> Subject: Re: [PATCH v2 2/2] drm: rcar-du: Add RZ/G2L DSI driver
>
> Hi Biju,
>
> Thank you for the patch.
>
> On Mon, Mar 28, 2022 at 07:51:15AM +0100, Biju Das wrote:
> > This driver supports the MIPI DSI encoder found in the RZ/G2L SoC. It
> >
Hi Laurent,
Thanks for the feedback.
> Subject: Re: [PATCH v2 1/2] dt-bindings: display: bridge: Document RZ/G2L
> MIPI DSI TX bindings
>
> Hi Biju,
>
> Thank you for the patch.
>
> On Mon, Mar 28, 2022 at 07:49:30AM +0100, Biju Das wrote:
> > The RZ/G2L MIPI DSI TX is embedded in the Renesas
Smatch reports this issue
virtual_link_hwss.c:32:6: warning: symbol
'virtual_setup_stream_attribute' was not declared.
Should it be static?
virtual_setup_stream_attribute is only used in
virtual_link_hwss.c, but the other functions in the
file are declared in the header file and used
On Tue, 2022-03-29 at 13:02 +0200, Christian König wrote:
> ⚠ External Email
>
> It's the only driver using this.
>
> Signed-off-by: Christian König
Looks good. A small suggestion underneath.
Reviewed-by: Zack Rusin
> ---
> drivers/gpu/drm/ttm/ttm_bo.c | 9 +
>
On 4/18/22 21:25, Thomas Zimmermann wrote:
> Hi
>
> Am 18.04.22 um 00:37 schrieb Dmitry Osipenko:
>> drm_gem_shmem_get_sg_table() never returns NULL on error, but a ERR_PTR.
>> Correct the doc comment which says that it returns NULL on error.
>>
>> Signed-off-by: Dmitry Osipenko
>
>
>> ---
>>
From: Zack Rusin
The initial GEM port broke refcounting on shareable (prime) surfaces and
memory evictions. The prime surfaces broke because the parent surfaces
weren't increasing the ref count on GEM surfaces, which meant that
the memory backing textures could have been deleted while the
Quoting Kuogee Hsieh (2022-04-15 16:47:25)
> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
> b/drivers/gpu/drm/msm/dp/dp_display.c
> index 01453db..5b289b9 100644
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> @@ -266,9 +269,18 @@ static int
Hello,
On 4/18/22 21:38, Thomas Zimmermann wrote:
> Hi
>
> Am 18.04.22 um 00:37 schrieb Dmitry Osipenko:
>> Replace drm_gem_shmem locks with the reservation lock to make GEM
>> lockings more consistent.
>>
>> Previously drm_gem_shmem_vmap() and drm_gem_shmem_get_pages() were
>> protected by
Reviewed-by: Lyude Paul
Will push to the appropriate branch in a moment
On Mon, 2022-04-18 at 11:28 -0400, Tom Rix wrote:
> Smatch reports this issue
> gf108.c:147:1: warning: symbol 'gf108_gr_fwif'
> was not declared. Should it be static?
>
> gf108_gr_fwif is only used in gf108.c. Single
>
Reviewed-by: Lyude Paul
Will push this to the appropriate branch in a little bit
On Mon, 2022-04-18 at 10:18 -0400, Tom Rix wrote:
> Smatch reports this issue
> base917c.c:26:1: warning: symbol 'base917c_format'
> was not declared. Should it be static?
>
> base917c_format is only used in
Hi
Am 18.04.22 um 00:37 schrieb Dmitry Osipenko:
Replace drm_gem_shmem locks with the reservation lock to make GEM
lockings more consistent.
Previously drm_gem_shmem_vmap() and drm_gem_shmem_get_pages() were
protected by separate locks, now it's the same lock, but it doesn't
make any
Hi
Am 18.04.22 um 00:37 schrieb Dmitry Osipenko:
drm_gem_shmem_get_sg_table() never returns NULL on error, but a ERR_PTR.
Correct the doc comment which says that it returns NULL on error.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 5 +++--
1 file
Hi Jani
Am 07.04.22 um 10:45 schrieb Jani Nikula:
...
I think another idea that could work is to use an intermediate symbol.
For DP, drivers would select the tristate DP_HELPER, which in turn
selects tristate DISPLAY_HELPER and boolean DISPLAY_DP_HELPER. But this
would require a 'useless'
Hi
Am 13.04.22 um 14:51 schrieb Rob Herring:
...
+
/**
* of_platform_populate() - Populate platform_devices from device tree data
* @root: parent of the first level to probe or NULL for the root of the tree
@@ -541,9 +595,7 @@ static int __init of_platform_default_populate_init(void)
Hi,
On Fri, Apr 15, 2022 at 5:14 PM Dmitry Baryshkov
wrote:
>
> On 16/04/2022 03:12, Doug Anderson wrote:
> > Hi,
> >
> > On Fri, Apr 15, 2022 at 3:12 PM Dmitry Baryshkov
> > wrote:
> >>
> >> On Sat, 16 Apr 2022 at 00:17, Doug Anderson wrote:
> >>>
> >>> Hi,
> >>>
> >>> On Thu, Apr 14, 2022 at
This implements the callback added by the patch ("drm/dp: Add
wait_hpd_asserted() callback to struct drm_dp_aux").
With this change and all the two "DP AUX Endpoint" drivers changed to
use wait_hpd_asserted(), we no longer need to have an long delay in
the AUX transfer function. It's up to the
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
---
Changes in v3:
- Don't check "hpd_asserted" boolean when
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
---
Left Dmitry's Reviewed-by tag off since patch changed enough.
(no
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
---
(no changes
This is the 2nd four patches from my RFC series ("drm/dp: Improvements
for DP AUX channel") [1]. I've broken the series in two so we can make
progress on the two halves separately.
v2 of this series changes to add wait_hpd_asserted() instead of
is_hpd_asserted(). This allows us to move the extra
Hi,
On Mon, Apr 18, 2022 at 9:58 AM Douglas Anderson wrote:
>
> 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
This implements the callback added by the patch ("drm/dp: Add
wait_hpd_asserted() callback to struct drm_dp_aux").
With this change and all the two "DP AUX Endpoint" drivers changed to
use wait_hpd_asserted(), we no longer need to have an long delay in
the AUX transfer function. It's up to the
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
---
Changes in v2:
- Change is_hpd_asserted() to
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
---
Changes in v2:
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
---
Left Dmitry's Reviewed-by tag off since patch changed enough.
This is the 2nd four patches from my RFC series ("drm/dp: Improvements
for DP AUX channel") [1]. I've broken the series in two so we can make
progress on the two halves separately.
v2 of this series changes to add wait_hpd_asserted() instead of
is_hpd_asserted(). This allows us to move the extra
On 16/04/2022 02:47, Kuogee Hsieh wrote:
Current DP driver implementation, event thread is kept running
after DP display is unbind. This patch fix this problem by disabling
DP irq and stop event thread to exit gracefully at dp_display_unbind().
Changes in v2:
-- start event thread at
On Mon, Apr 18, 2022 at 11:28:30AM -0400, Tony Krowiak wrote:
> > diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
> > index a4555014bd1e72..8a5c46aa2bef61 100644
> > +++ b/drivers/vfio/vfio.c
> > @@ -2484,19 +2484,15 @@ static int vfio_unregister_group_notifier(struct
> > vfio_group
Smatch reports this issue
gf108.c:147:1: warning: symbol 'gf108_gr_fwif'
was not declared. Should it be static?
gf108_gr_fwif is only used in gf108.c. Single
file variables should not be global so change
gf108_gr_fwif's storage-class specifier to static.
Signed-off-by: Tom Rix
---
The i.MX8MP contains two syscon registers which are responsible
for configuring the on-SoC DPI-to-LVDS serializer. Implement a
simple bridge driver for this serializer.
Signed-off-by: Marek Vasut
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Maxime Ripard
Cc: Peng Fan
Cc: Robby Cai
Cc: Robert
The i.MX8MP contains two syscon registers which are responsible
for configuring the on-SoC DPI-to-LVDS serializer. Add DT binding
which represents this serializer as a bridge.
Signed-off-by: Marek Vasut
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Maxime Ripard
Cc: Peng Fan
Cc: Rob Herring
Cc:
Smatch reports this issue
base917c.c:26:1: warning: symbol 'base917c_format'
was not declared. Should it be static?
base917c_format is only used in base917.c. Single
file variables should not be global so change
base917c_format's storage-class specifier to static.
Signed-off-by: Tom Rix
---
From: Tim Gardner
[ Upstream commit 37a1a2e6eeeb101285cd34e12e48a881524701aa ]
Coverity complains of a possible buffer overflow. However,
given the 'static' scope of nvidia_setup_i2c_bus() it looks
like that can't happen after examiniing the call sites.
CID 19036 (#1 of 1): Copy into fixed
From: Tim Gardner
[ Upstream commit 37a1a2e6eeeb101285cd34e12e48a881524701aa ]
Coverity complains of a possible buffer overflow. However,
given the 'static' scope of nvidia_setup_i2c_bus() it looks
like that can't happen after examiniing the call sites.
CID 19036 (#1 of 1): Copy into fixed
On Mon, 18 Apr 2022 at 17:07, Sam Ravnborg wrote:
>
> On Sat, Apr 09, 2022 at 11:00:16AM +0100, Paul Cercueil wrote:
> > The driver was compile-tested then rebased on drm-misc-next, and not
> > compile-tested after the rebase; unfortunately the driver didn't compile
> > anymore when it hit
https://bugzilla.kernel.org/show_bug.cgi?id=212499
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugzilla.kernel.org/show_bug.cgi?id=212635
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Status|NEW |RESOLVED
On Sat, Apr 09, 2022 at 11:00:16AM +0100, Paul Cercueil wrote:
> The driver was compile-tested then rebased on drm-misc-next, and not
> compile-tested after the rebase; unfortunately the driver didn't compile
> anymore when it hit drm-misc-next.
>
> Fixes: 49956b505c53 ("drm/panel: Add panel
Hi,
On Thu, Apr 14, 2022 at 10:27 AM Xin Ji wrote:
>
> On Wed, Apr 13, 2022 at 04:28:51PM +0200, Robert Foss wrote:
> > On Sat, 9 Apr 2022 at 06:47, Xin Ji wrote:
> > >
> > > 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
On Thu, Apr 14, 2022 at 10:53 AM Nick Fan wrote:
>
> Add a basic GPU node for mt8192.
>
> Signed-off-by: Nick Fan
Reviewed-by: Fei Shao
52 matches
Mail list logo
