ned-off-by: Sean Paul
Acked-by: Lucas Stach
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200608210505.48519-8-s...@poorly.run
> #v5
>
> Changes in v5:
> -Added to the set
> Changes in v6:
> -None
> ---
> drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 8 -
to a soft dependency.
Hm, to me this sounds much like the reasoning for the etnaviv
dependency. There is no actual build dependency, as the allocations are
done through the DMA API, but for the allocations to succeed you most
likely want CMA to be enabled. But that's just an observation from the
parate drivers.
Maybe we should move imx-drm into its own ipuv3 directory one day to
make this more clear. Change is still correct, though.
Reviewed-by: Lucas Stach
> Signed-off-by: Daniel Vetter
> Cc: Philipp Zabel
> Cc: Shawn Guo
> Cc: Sascha Hauer
> Cc: Pengutronix Kernel Team
M_FORMAT_MOD_LINEAR, so maybe that's where some of the
confusion about needing to specify the modifier list comes from.
> Now that this is all done consistently across all drivers, document
> the rules and enforce it in the drm core.
This clarification looks good to me.
Reviewed-by:
Am Dienstag, dem 13.04.2021 um 16:04 +0200 schrieb Daniel Vetter:
> On Tue, Apr 13, 2021 at 01:47:28PM +0200, Lucas Stach wrote:
> > Am Dienstag, dem 13.04.2021 um 11:48 +0200 schrieb Daniel Vetter:
> > > Since
> > >
> > > commit 890880ddfdbe25608317086
Hi,
Am Dienstag, dem 27.04.2021 um 09:26 -0400 schrieb Marek Olšák:
> Ok. So that would only make the following use cases broken for now:
> - amd render -> external gpu
> - amd video encode -> network device
FWIW, "only" breaking amd render -> external gpu will make us pretty
unhappy, as we have
the command buffer
physical address, making sure that the command buffer is always mappable.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 52 +--
1 file changed, 26 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv
Hi Dave, Daniel,
things are still slow in etnaviv land. Just one hardware support
addition for the GPU found on the NXP Layerscape LS1028A SoC from
Michael and the GEM mmap cleanup from Thomas.
Regards,
Lucas
The following changes since commit 8a02ea42bc1d4c448caf1bab0e05899dad503f74:
Merge t
Being able to have the refcount manipulation in an assignment makes
it much easier to parse the code.
Cc: sta...@vger.kernel.org # 5.4
Signed-off-by: Lucas Stach
Tested-by: Michael Walle
---
drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 3 +--
drivers/gpu/drm/etnaviv/etnaviv_gem.c| 3
...@vger.kernel.org # 5.4
Signed-off-by: Lucas Stach
Tested-by: Michael Walle
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index c8b9b0cc4442..c1b9c5cbed11 100644
--- a
igned-off-by: Lucas Stach
Tested-by: Michael Walle
---
drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
index dab1b58006d8..9fb1a2aadbcb 100644
--- a/drivers/gpu/drm/et
: Lucas Stach
Tested-by: Michael Walle
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 24 +++---
drivers/gpu/drm/etnaviv/etnaviv_iommu.c| 4
drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c | 8
3 files changed, 24 insertions(+), 12 deletions(-)
diff --git a
After a reset the GPU is no longer using the MMU context and may be
restarted with a different context. While the mmu_state proeprly was
cleared, the context wasn't unreferenced, leading to a memory leak.
Cc: sta...@vger.kernel.org # 5.4
Reported-by: Michael Walle
Signed-off-by: Lucas
When the GPU is reset both the current exec state, as well as all MMU
state is lost. Move the driver side state tracking into the reset function
to keep hardware and software state from diverging.
Cc: sta...@vger.kernel.org # 5.4
Signed-off-by: Lucas Stach
Tested-by: Michael Walle
---
drivers
only exception to this is when the GPU is unbound, in
which case we need to make sure to also free the last active context.
Cc: sta...@vger.kernel.org # 5.4
Reported-by: Michael Walle
Signed-off-by: Lucas Stach
Tested-by: Michael Walle
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 6 +++---
1
: sta...@vger.kernel.org # 5.4
Signed-off-by: Lucas Stach
Tested-by: Michael Walle
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 10 --
drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 1 +
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gp
Am Dienstag, dem 24.08.2021 um 09:24 +0200 schrieb Christian Gmeiner:
> Am Fr., 20. Aug. 2021 um 22:18 Uhr schrieb Lucas Stach
> :
> >
> > Move the refcount manipulation of the MMU context to the point where the
> > hardware state is programmed. At that point it is
Am Donnerstag, dem 26.08.2021 um 16:00 +0100 schrieb Robin Murphy:
> On 2021-08-26 13:10, Michael Walle wrote:
> > The DMA configuration of the virtual device is inherited from the first
> > actual etnaviv device. Unfortunately, this doesn't work with an IOMMU:
> >
> > [5.191008] Failed to set
From: Sascha Hauer
This is the 3D GPU found on the i.MX8MP SoC. The feature bits are
taken from the NXP downstream kernel driver 6.4.3.p1.305572.
Signed-off-by: Sascha Hauer
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_hwdb.c | 31 ++
1 file changed
the command buffer
physical address, making sure that the command buffer is always mappable.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 52 +--
1 file changed, 26 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv
-off-by: Lucas Stach
---
include/uapi/drm/drm_fourcc.h | 16
1 file changed, 16 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index f76de49c768f..76df2a932637 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
o
> > there's no exploit and the vm isn't confused about what's going on.
> > For any legit use case there's no difference from what userspace can
> > observe and do.
> >
> > Cc: sta...@vger.kernel.org
> > Cc: John Hubbard
> >
> > > Am Fr., 19. März 2021 um 20:06 Uhr schrieb Lucas Stach
> > > :
> > > >
> > > > Vivante TS (tile-status) buffer modifiers. They can be combined with
> > > > all of
> > > > the Vivante color buffer tiling modifiers, so the
Hi Simon,
Am Freitag, dem 19.03.2021 um 19:52 + schrieb Simon Ser:
> On Friday, March 19th, 2021 at 8:06 PM, Lucas Stach
> wrote:
>
> > +/*
> > + * Vivante TS (tile-status) buffer modifiers. They can be combined with
> > all of
> > + * the color buffer til
Am Montag, dem 22.03.2021 um 10:20 +0100 schrieb Lucas Stach:
> Hi Christian,
>
> Am Montag, dem 22.03.2021 um 09:54 +0100 schrieb Christian Gmeiner:
> > Am Sa., 20. März 2021 um 20:11 Uhr schrieb Daniel Vetter :
> > >
> > > On Sat, Mar 20, 2021 at 10:28
Hi Fabio,
I've pushed this patch to the libdrm git repo.
Regards,
Lucas
Am Mittwoch, dem 30.12.2020 um 15:29 -0300 schrieb Fabio Estevam:
> Add an entry for the "mxsfb-drm" driver, so that the test utilities
> work with the mxsfb driver without passing the -M argument.
>
> Signed-off-by: Fabio
Am Mittwoch, dem 16.12.2020 um 12:42 +0100 schrieb Christian Gmeiner:
> Make it possible for the user space to access these ID values.
Thanks, I've added this patch to my etnaviv/next branch.
Regards,
Lucas
> Signed-off-by: Christian Gmeiner
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 12 +
Am Mittwoch, dem 23.12.2020 um 20:51 +0100 schrieb Marc Kleine-Budde:
> This patch fixes the following sparse warnings, by adding the missing
> endianess
> conversion functions.
>
> > etnaviv/etnaviv_dump.c:78:26: warning: restricted __le32 degrades to integer
> > etnaviv/etnaviv_dump.c:88:26: wa
Am Montag, dem 25.01.2021 um 11:27 +0800 schrieb Tian Tao:
> fixed the below warning:
> drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c:84:2-8: WARNING: NULL check
> before some freeing functions is not needed.
Thanks, I've added this patch to my etnaviv/next branch.
Regards,
Lucas
> Signed-off-by:
Am Freitag, dem 05.02.2021 um 16:59 +0100 schrieb Daniel Vetter:
> On Fri, Feb 05, 2021 at 04:58:32PM +0100, Daniel Vetter wrote:
> > On Fri, Feb 05, 2021 at 01:03:07PM +, Chris Wilson wrote:
> > > gallium (iris) depends on os_same_file_description() to disambiguate
> > > screens and so avoid i
Drewry
> Cc: Andrew Morton
> Cc: Dave Airlie
> Cc: Daniel Vetter
> Cc: Lucas Stach
> ---
> init/Kconfig | 11 +++
> kernel/Makefile | 2 +-
> tools/testing/selftests/seccomp/seccomp_bpf.c | 2 +-
>
Am Samstag, dem 13.02.2021 um 18:40 +0100 schrieb Pavel Machek:
> Hi!
>
> > Userspace has discovered the functionality offered by SYS_kcmp and has
> > started to depend upon it. In particular, Mesa uses SYS_kcmp for
> > os_same_file_description() in order to identify when two fd (e.g. device
> > o
Am Montag, dem 15.02.2021 um 10:34 +0100 schrieb Christian König:
>
> Am 15.02.21 um 10:06 schrieb Simon Ser:
> > On Monday, February 15th, 2021 at 9:58 AM, Christian König
> > wrote:
> >
> > > we are currently working an Freesync and direct scan out from system
> > > memory on AMD APUs in A+A
Am Montag, dem 15.02.2021 um 13:04 +0100 schrieb Christian König:
> Am 15.02.21 um 12:53 schrieb Lucas Stach:
> > Am Montag, dem 15.02.2021 um 10:34 +0100 schrieb Christian König:
> > > Am 15.02.21 um 10:06 schrieb Simon Ser:
> > > > On Monday, February 15th, 20
From: Sascha Hauer
This is the 3D GPU found on the i.MX8MP SoC.
Signed-off-by: Sascha Hauer
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_hwdb.c | 31 ++
1 file changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_hwdb.c
b/drivers
at one might seek by using userptr. If
that's the case I might still take this patch for stable, but then we
should rather just disallow writable GPU mappings to this BO.
Regards,
Lucas
>
> Cc: sta...@vger.kernel.org
> Cc: John Hubbard
> Signed-off-by: Daniel Vet
modifier, if the plane init
code has already determined that the PRG/PRE is present.
Fixes: 699e7e543f1a ("drm/imx: ipuv3-plane: use drm managed resources")
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/imx/ipuv3-plane.c | 15 ---
1 file changed, 8 insertions(+), 7 deletion
modifier, if the plane init
code has already determined that the PRG/PRE is present.
Fixes: 699e7e543f1a ("drm/imx: ipuv3-plane: use drm managed resources")
Signed-off-by: Lucas Stach
---
v2: Add proper subject.
---
drivers/gpu/drm/imx/ipuv3-plane.c | 15 ---
1 file
Am Freitag, dem 02.04.2021 um 15:48 -0500 schrieb Chris Morgan:
> Update the panel to allow setting the rotation value in device tree.
> Tested on an Odroid Go Advance, where the panel is by default rotated 270
> degrees.
>
> Signed-off-by: Chris Morgan
Reviewed-
Am Freitag, dem 21.05.2021 um 11:09 +0200 schrieb Daniel Vetter:
> Scheduler takes care of its own locking, dont worry. For everything else
> there's reservation locking on each bo.
>
> So seems to be entirely redundnant and just a bit in the way.
I haven't read all the surrounding code, but this
Am Freitag, dem 21.05.2021 um 11:09 +0200 schrieb Daniel Vetter:
> No need to set it explicitly.
>
> Signed-off-by: Daniel Vetter
> Cc: Laurentiu Palcu
> Cc: Lucas Stach
For dcss and imx-drm:
Acked-by: Lucas Stach
> Cc: Shawn Guo
> Cc: Sascha Hauer
> Cc: Pengu
Am Mittwoch, den 25.11.2020, 11:04 + schrieb Steven Price:
> On 25/11/2020 03:17, Luben Tuikov wrote:
> > The job timeout handler now returns status
> > indicating back to the DRM layer whether the job
> > was successfully cancelled or whether more time
> > should be given to the job to complet
Am Mittwoch, den 25.11.2020, 11:22 + schrieb Steven Price:
> On 25/11/2020 11:15, Lucas Stach wrote:
> > Am Mittwoch, den 25.11.2020, 11:04 + schrieb Steven Price:
> > > On 25/11/2020 03:17, Luben Tuikov wrote:
> > > > The job timeout handler now returns sta
On Fr, 2020-11-20 at 22:13 +0100, Lucas Stach wrote:
> The conversion away from the simple display pipeline helper missed
> to convert the prepare_fb plane callback, so no fences are attached to
> the atomic state, breaking synchronization with other devices. Fix
> this by plu
On Do, 2020-11-05 at 16:01 +0200, Laurentiu Palcu wrote:
> Hi,
>
> This patchset fixes 90/270 rotations for Vivante tiled and super-tiled
> formats and a Coccinelle warning.
Thanks, looks good. I've pushed them into drm-misc-next.
Regards,
Lucas
___
d
On Do, 2020-11-05 at 16:50 +0200, Laurentiu Palcu wrote:
> This patch adds support for using NN interpolation scaling by setting the
> SCALING_FILTER plane property to 1. Otherwise, the default method is used.
>
> Signed-off-by: Laurentiu Palcu
Reviewed and pushed into drm-misc-next.
Regards,
L
Hi Dave, hi Daniel,
please pull the following etnaviv updates for 5.11.
Again, nothing big this time. Mostly a new performance counter from
Christian, some more lockdep annotations from Guido and removal of
functionality that duplicates driver core from Robin.
Regards,
Lucas
The following cha
Am Dienstag, den 01.12.2020, 11:37 +0100 schrieb Martin Kepplinger:
> Add interconnect support to mxsfb so that it is able to request enough
> bandwidth to DDR for display output to work.
>
> Signed-off-by: Martin Kepplinger
> ---
> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 33
Am Dienstag, den 01.12.2020, 12:34 +0100 schrieb Guido Günther:
> This allows us to raise DRAM bandiwth to a high enough value for a
> stable picture on i.mx8mq. We pick a bandwidth that should be sufficient
> for 4k@60Hz.
>
> Modelled like mdp5_kms.
>
> Signed-off-by: Guido Günther
> ---
> dri
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/scheduler/sched_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 9a0d77a68018..f517ffd53847 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b
_ALIVE is returned, as
> per the default behaviour.
>
> A more involved driver's solutions can be had
> in subequent patches.
>
> v2: Use enum as the status of a driver's job
> timeout callback method.
>
> Cc: Alexander Deucher
> Cc: Andrey Grodzov
Am Dienstag, dem 29.06.2021 um 05:04 +0200 schrieb Marek Vasut:
> On 6/28/21 10:09 AM, Lucas Stach wrote:
> > Am Samstag, dem 26.06.2021 um 20:15 +0200 schrieb Marek Vasut:
> > > On 6/24/21 2:01 PM, Lucas Stach wrote:
> > > > Am Dienstag, dem 22.06.2021 um 1
Am Freitag, dem 18.06.2021 um 14:04 +0200 schrieb Michael Walle:
> This is the first step to bring GPU support to the NXP LS1028A SoC. It
> features a Mali DP500, a Vivante GC7000 and has one DisplayPort output
> which is driven by a Cadence MHDP controller and PHY.
>
> This was briefly tested wit
Am Donnerstag, dem 24.06.2021 um 10:58 +0200 schrieb Thomas Zimmermann:
> Moving the driver-specific mmap code into a GEM object function allows
> for using DRM helpers for various mmap callbacks.
>
> The respective etnaviv functions are being removed. The file_operations
> structure fops is now b
ption is the fence import ioctl from Jason:
>
> https://lore.kernel.org/dri-devel/20210610210925.642582-7-ja...@jlekstrand.net/
Sorry, but why is the fence import ioctl a alternative to the fix
proposed in this patch?
>
> Signed-off-by: Daniel Vetter
> Cc: Lucas Stach
Am Freitag, dem 02.07.2021 um 23:38 +0200 schrieb Daniel Vetter:
> We need to pull the drm_sched_job_init much earlier, but that's very
> minor surgery.
>
> Signed-off-by: Daniel Vetter
> Cc: Lucas Stach
> Cc: Russell King
> Cc: Christian Gmeiner
> Cc: Sumit S
-by: Tian Tao
> Acked-by: Christian König
> Signed-off-by: Lucas Stach
> Signed-off-by: Sasha Levin
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
&g
Am Mittwoch, dem 07.07.2021 um 13:37 +0200 schrieb Daniel Vetter:
> On Wed, Jul 7, 2021 at 10:54 AM Lucas Stach wrote:
> >
> > Hi Daniel,
> >
> > I'm feeling like I miss a ton of context here, so some maybe dumb
> > questions/remarks below.
> >
&g
Am Mittwoch, dem 07.07.2021 um 13:32 +0200 schrieb Daniel Vetter:
> On Wed, Jul 7, 2021 at 1:26 PM Daniel Vetter wrote:
> > On Wed, Jul 7, 2021 at 11:08 AM Lucas Stach wrote:
> > > Am Freitag, dem 02.07.2021 um 23:38 +0200 schrieb Daniel Vetter:
> > > > We need
Am Donnerstag, dem 01.07.2021 um 00:50 +0200 schrieb Marek Vasut:
> On 6/29/21 10:02 AM, Lucas Stach wrote:
> > Am Dienstag, dem 29.06.2021 um 05:04 +0200 schrieb Marek Vasut:
> > > On 6/28/21 10:09 AM, Lucas Stach wrote:
> > > > Am Samstag, dem 26.06.2021 um 2
: mxsfb: Stop using DRM simple display pipeline helper)
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
index b721b8b262ce..4d556532281a 100644
--- a/drivers/gpu
When the probe routine fails we also need to clean up the
CEC adapter registered in adv7511_cec_init().
Fixes: 3b1b975003e4 ("drm: adv7511/33: add HDMI CEC support")
Signed-off-by: Lucas Stach
---
The "fixed" commit is not the one introducing the issue, it had been
there a
Am Montag, dem 21.03.2022 um 14:58 +0100 schrieb Christian König:
> We can get the excl fence together with the shared ones as well.
>
> Signed-off-by: Christian König
> Reviewed-by: Daniel Vetter
> Cc: Lucas Stach
> Cc: Russell King
> Cc: Christia
The flush sequence is a marker that the page tables have been changed
and any affected TLBs need to be flushed. Move the flush_seq increment
a little further down the call stack to place it next to the actual
page table manipulation. Not functional change.
Signed-off-by: Lucas Stach
---
drivers
are no longer used by any GPU jobs.
Implement reaping of idle MMU mappings that would otherwise
prevent the insertion of a softpin mapping.
Signed-off-by: Lucas Stach
Tested-by: Guido Günther
Acked-by: Guido Günther
Reviewed-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 39
When the mapping is already reaped the unmap must be a no-op, as we
would otherwise try to remove the mapping twice, corrupting the involved
data structures.
Cc: sta...@vger.kernel.org # 5.4
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 6 ++
1 file changed, 6
This makes it a little more clear that the mapping holds a reference
to the context once the buffer has been successfully mapped into that
context and simplifies the error handling a bit.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 11 +++
drivers/gpu/drm
t;
> Signed-off-by: Marek Vasut
> Cc: Jonas Karlman
> Cc: Laurent Pinchart
> Cc: Maxime Ripard
> Cc: Neil Armstrong
> Cc: Rob Herring
> Cc: Sam Ravnborg
> Cc: devicet...@vger.kernel.org
> To: dri-devel@lists.freedesktop.org
Reviewed-by: Lucas Stach
> ---
> V2
Marek Vasut
> Cc: Jonas Karlman
> Cc: Laurent Pinchart
> Cc: Maxime Ripard
> Cc: Neil Armstrong
> Cc: Rob Herring
> Cc: Sam Ravnborg
> Cc: devicet...@vger.kernel.org
> To: dri-devel@lists.freedesktop.org
Acked-by: Lucas Stach
> ---
> V3: - New patch
>
> limits.
>
> Signed-off-by: Marek Vasut
> Cc: Jonas Karlman
> Cc: Laurent Pinchart
> Cc: Maxime Ripard
> Cc: Neil Armstrong
> Cc: Sam Ravnborg
Reviewed-by: Lucas Stach
> ---
> V2: - New patch
> V3: - Drop edp from tc_edp_common_atomic_check,
> s@\@tc_co
Am Donnerstag, dem 24.02.2022 um 20:58 +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 t
Cc: Jonas Karlman
> Cc: Laurent Pinchart
> Cc: Maxime Ripard
> Cc: Neil Armstrong
> Cc: Sam Ravnborg
Reviewed-by: Lucas Stach
> ---
> V2: - New patch
> V3: - No change
> ---
> drivers/gpu/drm/bridge/tc358767.c | 10 +-
> 1 file changed, 5 insertions(+),
fails to link without CONFIG_DRM_MIPI_DSI. As this is not a
visible symbol it needs to be selected from the TC358767 Kconfig entry.
One more nit below, other than that:
Reviewed-by: Lucas Stach
> ---
> V2: - Rebase on next-20220217 and new patches in this series
> V3: - Drop edp from t
n to already supported DPI-to-(e)DP mode.
>
> Cc: Jonas Karlman
> Cc: Laurent Pinchart
> Cc: Maxime Ripard
> Cc: Neil Armstrong
> Cc: Sam Ravnborg
> To: dri-devel@lists.freedesktop.org
Tested-by: Lucas Stach
In both DPI to eDP and DSI to DPI mode.
Regards,
Lucas
>
Hi Marek,
Am Montag, dem 28.03.2022 um 23:43 +0200 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. Clean up the driver,
> switch to atomic ops, and add support for the DSI-to-DPI mode in
> addition to alr
ional change.
>
> Signed-off-by: Marek Vasut
> Cc: Jonas Karlman
> Cc: Laurent Pinchart
> Cc: Maxime Ripard
> Cc: Neil Armstrong
> Cc: Sam Ravnborg
Reviewed-by: Lucas Stach
> ---
> V2: - New patch
> ---
> drivers/gpu/drm/bridge/tc358767.c | 35
onas Karlman
> Cc: Laurent Pinchart
> Cc: Maxime Ripard
> Cc: Neil Armstrong
> Cc: Sam Ravnborg
Reviewed-by: Lucas Stach
> ---
> V2: - New patch
> ---
> drivers/gpu/drm/bridge/tc358767.c | 15 +++
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
>
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.
>
> Sign
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 t
art
> Cc: Maxime Ripard
> Cc: Neil Armstrong
> Cc: Sam Ravnborg
Reviewed-by: Lucas Stach
> ---
> V2: - Rename tc_probe_bridge_mode() to tc_probe_edp_bridge_endpoint()
> to better reflect that it parses the (e)DP output endpoint
> ---
> drivers/gpu/drm/bridge/tc
man
> Cc: Laurent Pinchart
> Cc: Maxime Ripard
> Cc: Neil Armstrong
> Cc: Sam Ravnborg
Reviewed-by: Lucas Stach
> ---
> V2: - New patch
> ---
> drivers/gpu/drm/bridge/tc358767.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a
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
> Cc
-> port@2 -> eDP :: [port@1 is not connected]
> DSI -> port@0 -> port@1 -> DPI :: [port@2 is not connected]
>
> Add function to determine the bridge mode based on connected endpoints.
>
> Signed-off-by: Marek Vasut
> Cc: Jonas Karlman
> Cc: Laurent Pinchart
&
specific
> settings. No functional change.
>
> Signed-off-by: Marek Vasut
> Cc: Jonas Karlman
> Cc: Laurent Pinchart
> Cc: Maxime Ripard
> Cc: Neil Armstrong
> Cc: Sam Ravnborg
Reviewed-by: Lucas Stach
> ---
> V2: - New patch
> ---
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. Add support for the
> DSI-to-DPI mode.
>
> This requires skipping most of the (e)DP initialization code, which is
Am Samstag, dem 19.02.2022 um 03:39 +0100 schrieb Marek Vasut:
> On 2/18/22 18:49, Lucas Stach wrote:
> > 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 fr
Hi Andy,
Am Montag, dem 21.02.2022 um 19:51 +0800 schrieb Andy Yan:
> Hi Sascha:
>
> On 2/17/22 16:29, Sascha Hauer wrote:
> > From: Andy Yan
> >
> > The VOP2 unit is found on Rockchip SoCs beginning with rk3566/rk3568.
> > It replaces the VOP unit found in the older Rockchip SoCs.
> >
> > Thi
Hi Marek,
two more things I noticed.
Am Freitag, dem 18.02.2022 um 19:38 +0100 schrieb Lucas Stach:
> 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,
Hi Marek, hi Liu,
Am Dienstag, dem 01.03.2022 um 10:44 +0800 schrieb Liu Ying:
> On Mon, 2022-02-28 at 16:34 +0100, Marek Vasut wrote:
> > On 2/28/22 09:18, Liu Ying wrote:
> >
> > Hi,
>
> Hi,
>
> >
> > > > > On Mon, 2022-02-28 at 01:45 +0100, Marek Vasut wrote:
> > > > > > Add compatible stri
Am Dienstag, dem 01.03.2022 um 11:19 +0100 schrieb Marek Vasut:
> On 3/1/22 11:04, Lucas Stach wrote:
>
> Hi,
>
> [...]
>
> > > Given the two totally different IPs, I don't see bugs of IP control
> > > logics should be fixed for both drivers. Natu
Am Dienstag, dem 01.03.2022 um 07:03 -0600 schrieb Adam Ford:
> On Tue, Mar 1, 2022 at 5:05 AM Lucas Stach wrote:
> >
> > Am Dienstag, dem 01.03.2022 um 11:19 +0100 schrieb Marek Vasut:
> > > On 3/1/22 11:04, Lucas Stach wrote:
> > >
> > > Hi,
> &g
Am Mittwoch, dem 02.03.2022 um 03:54 +0100 schrieb Marek Vasut:
> On 3/1/22 14:18, Lucas Stach wrote:
> > Am Dienstag, dem 01.03.2022 um 07:03 -0600 schrieb Adam Ford:
> > > On Tue, Mar 1, 2022 at 5:05 AM Lucas Stach wrote:
> > > >
> > > > Am Dienstag, d
Am Mittwoch, dem 02.03.2022 um 17:41 +0800 schrieb Liu Ying:
> On Wed, 2022-03-02 at 10:23 +0100, Lucas Stach wrote:
> > Am Mittwoch, dem 02.03.2022 um 03:54 +0100 schrieb Marek Vasut:
> > > On 3/1/22 14:18, Lucas Stach wrote:
> > > > Am Dienstag, dem 01.03.2022 um
Am Donnerstag, dem 03.03.2022 um 10:54 +0800 schrieb Liu Ying:
> On Wed, 2022-03-02 at 12:57 +0100, Lucas Stach wrote:
> > Am Mittwoch, dem 02.03.2022 um 17:41 +0800 schrieb Liu Ying:
> > > On Wed, 2022-03-02 at 10:23 +0100, Lucas Stach wrote:
> > > > Am Mittwoch,
Am Donnerstag, dem 03.03.2022 um 04:14 +0100 schrieb Marek Vasut:
> On 3/2/22 10:23, Lucas Stach wrote:
>
> [...]
>
> > > > > I tend to agree with Marek on this one. We have an instance where the
> > > > > blk-ctrl and the GPC driver between 8m,
changes up to f2faea8b64125852fa9acc6771c07fc0311a039b:
drm/etnaviv: add missing MMU context put when reaping MMU mapping (2021-09-16
10:35:37 +0200)
Lucas Stach (8):
drm/etnaviv: return context from etnaviv_iommu_context_get
Am Mittwoch, dem 22.09.2021 um 13:41 +0200 schrieb Christian König:
> Setting the exclusive fence without waiting for the shared
> fences violates the DAG and is illegal.
>
> We really need to get away from this ASAP and make the
> driver interface more bullet prove.
Uh, what happened to Daniels
Am Dienstag, dem 28.09.2021 um 11:19 +0200 schrieb Guido Günther:
> Hi,
> On Tue, Sep 28, 2021 at 11:08:58AM +0200, Marek Vasut wrote:
> > On 9/28/21 10:55 AM, Guido Günther wrote:
> > > If a bridge doesn't do any bus format handling MEDIA_BUS_FMT_FIXED is
> > > returned. Fallback to a reasonable d
present")
>
> Signed-off-by: Guido Günther
Reviewed-by: Lucas Stach
> ---
> drivers/gpu/drm/bridge/nwl-dsi.c | 35
> 1 file changed, 35 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c
> b/drivers/gpu/drm/bridge/nwl
Am Montag, dem 04.10.2021 um 09:27 +0200 schrieb Guido Günther:
> media-bus-formats.h has them in hexadecimal as well so matching with
> that file saves one conversion when debugging.
>
> Signed-off-by: Guido Günther
Reviewed-by: Lucas Stach
> ---
> drivers/gpu/drm/mxs
1 - 100 of 1875 matches
Mail list logo
