From: Markus Schneider-Pargmann
This is a new driver that supports the integrated DisplayPort phy for
mediatek SoCs, especially the mt8195. The phy is integrated into the
DisplayPort controller and will be created by the mtk-dp driver. This
driver expects a struct regmap to be able to work on
dpintf is the displayport interface hardware unit. This unit is similar
to dpi and can reuse most of the code.
This patch adds support for mt8195-dpintf to this dpi driver. Main
differences are:
- Some features/functional components are not available for dpintf
which are now excluded from
This patch adds External DisplayPort support to the mt8195 eDP driver.
Signed-off-by: Guillaume Ranquet
---
drivers/gpu/drm/mediatek/mtk_dp.c | 87 +++
1 file changed, 64 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c
Add flexibility by moving the csc_enable bit to board config
Signed-off-by: Guillaume Ranquet
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index
Add flexibility by moving the yuv422 en bit to board config
Signed-off-by: Guillaume Ranquet
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index
On Fri, Feb 18, 2022 at 7:13 AM Simon Ser wrote:
>
> On Friday, February 18th, 2022 at 12:54, Hans de Goede
> wrote:
>
> > On 2/18/22 12:39, Simon Ser wrote:
> > > On Friday, February 18th, 2022 at 11:38, Hans de Goede
> > > wrote:
> > >
> > >> What I'm reading in the above is that it is
On 2022-02-18 07:12, Simon Ser wrote:
> On Friday, February 18th, 2022 at 12:54, Hans de Goede
> wrote:
>
>> On 2/18/22 12:39, Simon Ser wrote:
>>> On Friday, February 18th, 2022 at 11:38, Hans de Goede
>>> wrote:
>>>
What I'm reading in the above is that it is being considered to allow
From: Rob Clark
With native userspace drivers in guest, a lot of GEM objects need to be
neither shared nor mappable. And in fact making everything mappable
and/or sharable results in unreasonably high fd usage in host VMM.
Signed-off-by: Rob Clark
---
This is for a thing I'm working on, a new
Since switch to simplefb/simpledrm VESA graphic modes are no longer
available with legacy BIOS.
The x86 realmode boot code enables the VESA graphic modes when option
FB_BOOT_VESA_SUPPORT is enabled.
To enable use of VESA modes with simplefb in legacy BIOS boot mode drop
dependency of
On 2022-02-18 05:03, Ville Syrjala wrote:
> 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:
>
On 2022-02-18 05:03, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add a variant of drm_mode_copy() that explicitly clears out
> the list head of the destination mode. Helpful to guarantee
> we don't have stack garbage left in there for on-stack modes.
>
> Signed-off-by: Ville Syrjälä
On Fri, Feb 18, 2022 at 11:39 AM Felix Kuehling wrote:
>
>
> Am 2022-02-18 um 02:57 schrieb David Gow:
> > From: Randy Dunlap
> >
> > cpuinfo_x86 and its associated macros are not available under ARCH=um,
> > even though CONFIG_X86_64 is defined.
> >
> > This patch (and discussion) were
On 2022-02-18 05:03, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> These on stack copies of the modes appear to be pointless.
> Just look at the originals directly.
>
> Cc: Harry Wentland
> Cc: Leo Li
> Cc: Rodrigo Siqueira
> Cc: Alex Deucher
> Cc: amd-...@lists.freedesktop.org
> Cc:
Well in that case somebody could argue that we should probably remove
the structure altogether.
Regards,
Christian.
Am 18.02.22 um 17:15 schrieb Felix Kuehling:
It looks like this structure isn't being used at all. So I'm OK with
this change, in case we ever use it in the future.
Regards,
Am 2022-02-18 um 02:57 schrieb David Gow:
From: Randy Dunlap
cpuinfo_x86 and its associated macros are not available under ARCH=um,
even though CONFIG_X86_64 is defined.
This patch (and discussion) were originally posted here:
https://lkml.org/lkml/2022/1/24/1547
This produces the
It looks like this structure isn't being used at all. So I'm OK with
this change, in case we ever use it in the future.
Regards,
Felix
Am 2022-02-18 um 02:47 schrieb Christian König:
Felix need to comment as well, but I don't think that this will work
that easily.
By changing the entry
On 2022-02-18 05:03, Ville Syrjala wrote:
> 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
On Fri, Feb 18, 2022 at 7:57 AM Rob Clark wrote:
>
> From: Rob Clark
>
> With native userspace drivers in guest, a lot of GEM objects need to be
> neither shared nor mappable. And in fact making everything mappable
> and/or sharable results in unreasonably high fd usage in host VMM.
>
>
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
Am Freitag, dem 18.02.2022 um 02:00 +0100 schrieb Marek Vasut:
> These functions are specific to (e)DP output initialization and
> operation, add specific tc_edp_ prefix to those functions to
> discern them from DPI output functions that will be added later
> in this series. No functional change.
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
Hi Ville,
Thank you for the patch.
On Fri, Feb 18, 2022 at 12:03:47PM +0200, Ville Syrjala wrote:
> 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
Am Freitag, dem 18.02.2022 um 02:00 +0100 schrieb Marek Vasut:
> The TC358767/TC358867/TC9595 are all capable of operating either from
> attached Xtal or from DSI clock lane clock. In case the later is used,
> all I2C accesses will fail until the DSI clock lane is running and
> supplying clock to
Am Freitag, dem 18.02.2022 um 02:00 +0100 schrieb Marek Vasut:
> This bit of code is (e)DP and aux I2C link specific, move it into
> tc_aux_link_setup() to permit cleaner addition of DSI-to-DPI mode.
> No functional change.
>
> Signed-off-by: Marek Vasut
> Cc: Jonas Karlman
> Cc: Laurent
On 18/02/2022 13:47, Ramalingam C wrote:
On 2022-02-17 at 20:57:35 -0800, Jordan Justen wrote:
Robert Beckett writes:
From: Matthew Auld
On discrete platforms like DG2, we need to support a minimum page size
of 64K when dealing with device local-memory. This is quite tricky for
various
Am Freitag, dem 18.02.2022 um 02:00 +0100 schrieb Marek Vasut:
> The TC358767/TC358867/TC9595 are all capable of operating in multiple
> modes, DPI-to-(e)DP, DSI-to-(e)DP, DSI-to-DPI. Only the first mode is
> currently supported. It is possible to find out the mode in which the
> bridge should be
Am Freitag, dem 18.02.2022 um 02:00 +0100 schrieb Marek Vasut:
> Use the atomic version of the enable/disable operations to continue the
> transition to the atomic API. This will be needed to access the mode
> from the atomic state.
>
> Signed-off-by: Marek Vasut
> Cc: Jonas Karlman
> Cc:
Am Freitag, dem 18.02.2022 um 02:00 +0100 schrieb Marek Vasut:
> Implement .atomic_check callback which prevents user space from setting
> unsupported mode. The tc_edp_common_atomic_check() variant is already
> prepared for DSI-to-DPI mode addition, which has different frequency
> limits.
>
>
From: Tom Rix
Clang static analysis reports this problem
kfd_chardev.c:2327:2: warning: 1st function call argument
is an uninitialized value
kvfree(bo_privs);
^~~~
If the copy_from_users(bo_buckets, ...) fails, there is a jump to
the generic error handler at exit:. The
Am Freitag, dem 18.02.2022 um 02:00 +0100 schrieb Marek Vasut:
> The TC358767/TC358867/TC9595 are all capable of operating in multiple
> modes, DPI-to-(e)DP, DSI-to-(e)DP, DSI-to-DPI. Only the first mode is
> currently supported. In order to support the rest of the modes without
> making the
On Fri, Feb 18, 2022 at 8:42 AM Chia-I Wu wrote:
>
> On Fri, Feb 18, 2022 at 7:57 AM Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > With native userspace drivers in guest, a lot of GEM objects need to be
> > neither shared nor mappable. And in fact making everything mappable
> > and/or
Am Freitag, dem 18.02.2022 um 02:00 +0100 schrieb Marek Vasut:
> The bridge ops are specific to the bridge configuration, move them
> into tc_probe_edp_bridge_endpoint() to permit cleaner addition of
> DSI-to-DPI mode. No functional change.
>
> Signed-off-by: Marek Vasut
> Cc: Jonas Karlman
>
Hi Dave, Daniel,
More new stuff for 5.18.
The following changes since commit b9c7babe2c2e37a50aa42401b38d597ea78f506e:
Backmerge tag 'v5.17-rc4' of
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into drm-next
(2022-02-14 10:52:27 +1000)
are available in the Git repository at:
Am Freitag, dem 18.02.2022 um 02:00 +0100 schrieb Marek Vasut:
> The tc_set_video_mode() sets up both common and (e)DP video mode settings of
> the bridge chip. Split the function into tc_set_common_video_mode() to set
> the common settings and tc_set_edp_video_mode() to set the (e)DP specific
>
On Fri, Feb 18, 2022 at 11:22:41AM +, Matthew Auld wrote:
We already completed the steps for this.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: mesa-...@lists.freedesktop.org
I was indeed wondering
201 - 235 of 235 matches
Mail list logo
