On Wed, Mar 30, 2022 at 08:50:09PM +0800, Andy Yan wrote:
> Hi Sascha:
>
> On 3/30/22 14:39, Sascha Hauer wrote:
> > Hi Andy,
> >
> > On Tue, Mar 29, 2022 at 07:56:27PM +0800, Andy Yan wrote:
> > > Hi Sascha:
> > >
> > > On 3/28/22 23:11, Sascha Hauer wrote:
> > > > With upcoming VOP2 support VO
Hi Jani and Joonas:
Are you OK with these patches? I noticed I need to change the license of the
new file. Will do that when check-in if you are OK with these.
Thanks,
Zhi.
On 3/28/22 6:50 AM, Christoph Hellwig wrote:
> On Fri, Mar 25, 2022 at 01:52:49PM -0400, Zhi Wang wrote:
>>
>> v7:
>>
>> -
Hi Sascha:
On 3/31/22 15:06, Sascha Hauer wrote:
On Wed, Mar 30, 2022 at 08:50:09PM +0800, Andy Yan wrote:
Hi Sascha:
On 3/30/22 14:39, Sascha Hauer wrote:
Hi Andy,
On Tue, Mar 29, 2022 at 07:56:27PM +0800, Andy Yan wrote:
Hi Sascha:
On 3/28/22 23:11, Sascha Hauer wrote:
With upcoming VOP
Well the fix is trivial, but somehow rebuilding drm-tip always fails for
me while merging drm-intel-next.
I probably have somehow messed up reverting the conflict resolution. Ideas?
Christian.
Am 31.03.22 um 08:28 schrieb Christian König:
I'm going to take a look, but need to figure out how to
report by coccicheck:
drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c:1951:2-3: Unneeded semicolon
fixed c543dcb ("drm/amdgpu/vcn: Add VCN ras error query support")
Signed-off-by: Haowen Bai
---
drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/driv
any suggestions or extra test I can do now?
Regards,
Cong
On 2022/3/25 15:45, Christian König wrote:
Am 24.03.22 um 11:49 schrieb Cong Liu:
qxl use ioremap to map ram_header and rom, in the arm64 implementation,
the device is mapped as DEVICE_nGnRE, it can not support unaligned
access. and qxl
Hi Yunfei,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on media-tree/master]
[also build test ERROR on linus/master next-20220331]
[cannot apply to remoteproc/rproc-next linux/master v5.17]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And
Hi Yunfei,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on media-tree/master]
[also build test ERROR on linus/master next-20220331]
[cannot apply to remoteproc/rproc-next linux/master v5.17]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And
Hi Chris:
Thanks for the testing. Can you attach the dmesg? I tested mostly on my skylake
desktop with some 3D workload.
Thanks,
Zhi.
On 3/31/22 7:42 AM, Christoph Hellwig wrote:
> On Thu, Mar 31, 2022 at 07:11:07AM +, Wang, Zhi A wrote:
>> Hi Jani and Joonas:
>>
>> Are you OK with these pa
Hi Daniel,
I'm using this thread as the occasion to discuss the legacy cursor stuff
a bit further.
I've been trying to address the issue detailed here:
https://lore.kernel.org/all/20220221134155.125447-1-max...@cerno.tech/
And the last patch in particular:
https://lore.kernel.org/all/20220221134
On Thu, Mar 31, 2022 at 09:35:50AM +0200, Christian König wrote:
Well the fix is trivial, but somehow rebuilding drm-tip always fails
for me while merging drm-intel-next.
I probably have somehow messed up reverting the conflict resolution. Ideas?
It looks like the error is in the wrong confli
On Thu, Mar 31, 2022 at 03:20:37PM +0800, Andy Yan wrote:
> Hi Sascha:
>
> On 3/31/22 15:06, Sascha Hauer wrote:
> > On Wed, Mar 30, 2022 at 08:50:09PM +0800, Andy Yan wrote:
> > > Hi Sascha:
> > >
> > > On 3/30/22 14:39, Sascha Hauer wrote:
> > > > Hi Andy,
> > > >
> > > > On Tue, Mar 29, 2022
Am 31.03.22 um 10:15 schrieb Lucas De Marchi:
On Thu, Mar 31, 2022 at 09:35:50AM +0200, Christian König wrote:
Well the fix is trivial, but somehow rebuilding drm-tip always fails
for me while merging drm-intel-next.
I probably have somehow messed up reverting the conflict resolution.
Ideas?
Dear Chuansheng,
Am 31.03.22 um 02:06 schrieb Liu, Chuansheng:
-Original Message-
From: Paul Menzel
Sent: Thursday, March 31, 2022 12:47 AM
[…]
Am 29.03.22 um 01:58 schrieb Liu, Chuansheng:
-Original Message-
From: Paul Menzel
Sent: Monday, March 28, 2022 2:15 PM
Am 2
On Mon, 28 Mar 2022 14:43:00 +0200, Maxime Ripard wrote:
> This series adds an atomic_print_state hook for drm_private_obj to ease the
> debugging of driver-specific sub-classes, and adds one for vc4.
>
> It also changes the call site of drm_atomic_print_new_state to make it more
> consistent.
>
On Thu, 31 Mar 2022, "Wang, Zhi A" wrote:
> Hi Jani and Joonas:
>
> Are you OK with these patches? I noticed I need to change the license
> of the new file. Will do that when check-in if you are OK with these.
Use SPDX license header instead of the full text?
I don't know much about the actual c
Adding a pile of people who've expressed interest in vm_bind for their
drivers.
Also note to the intel folks: This is largely written with me having my
subsystem co-maintainer hat on, i.e. what I think is the right thing to do
here for the subsystem at large. There is substantial rework involved
h
On Thu, Mar 31, 2022 at 10:20:58AM +0200, Christian König wrote:
Am 31.03.22 um 10:15 schrieb Lucas De Marchi:
On Thu, Mar 31, 2022 at 09:35:50AM +0200, Christian König wrote:
Well the fix is trivial, but somehow rebuilding drm-tip always
fails for me while merging drm-intel-next.
I probably
Thanks. Let me fix that. :)
On 3/31/22 04:33, Christoph Hellwig wrote:
On Thu, Mar 31, 2022 at 08:04:04AM +, Wang, Zhi A wrote:
Hi Chris:
Thanks for the testing. Can you attach the dmesg? I tested mostly on my skylake
desktop with some 3D workload.
Sure, I should have done that from the
Am 31.03.22 um 10:30 schrieb Lucas De Marchi:
On Thu, Mar 31, 2022 at 10:20:58AM +0200, Christian König wrote:
Am 31.03.22 um 10:15 schrieb Lucas De Marchi:
On Thu, Mar 31, 2022 at 09:35:50AM +0200, Christian König wrote:
Well the fix is trivial, but somehow rebuilding drm-tip always
fails for
Hi Paul,
> -Original Message-
> From: dri-devel On Behalf Of Paul
> Menzel
> Sent: Thursday, March 31, 2022 4:22 PM
> To: Liu, Chuansheng
> Cc: linux-fb...@vger.kernel.org; Dave Hansen ;
> a...@linux-foundation.org; dan...@iogearbox.net; linux...@kvack.org;
> net...@vger.kernel.org; del.
On 31.03.22 10:53, Christoph Hellwig wrote:
>> -page = vm_normal_page(vma, addr, pte);
>> +page = vm_normal_lru_page(vma, addr, pte);
>
> Why can't this deal with ZONE_DEVICE pages? It certainly has
> nothing do with a LRU I think. In fact being able to have
> stats that count say the nu
On Thu, Mar 31, 2022 at 10:39:47AM +0200, Christian König wrote:
Am 31.03.22 um 10:30 schrieb Lucas De Marchi:
On Thu, Mar 31, 2022 at 10:20:58AM +0200, Christian König wrote:
Am 31.03.22 um 10:15 schrieb Lucas De Marchi:
On Thu, Mar 31, 2022 at 09:35:50AM +0200, Christian König wrote:
Well th
On 18/03/2022 18:12, Daniel Vetter wrote:
Maybe also good to add dri-devel to these discussions.
I'm not sure where exactly we landed with dgpu error capture (maybe I
should check the code but it's really w/e here), but I think we can
also toss in "you need a non-recoverable context for error ca
https://bugzilla.kernel.org/show_bug.cgi?id=214071
kasimir (info@lox.enterprises) changed:
What|Removed |Added
CC||info@lox.enterprises
---
On Thu, 31 Mar 2022 at 09:05, Vinod Koul wrote:
>
> On 29-03-22, 10:52, Rob Herring wrote:
> > On Tue, Mar 29, 2022 at 12:01:52PM +0530, Vinod Koul wrote:
> > > On 28-03-22, 13:21, Rob Herring wrote:
> > > > On Mon, Mar 28, 2022 at 12:18 PM Krzysztof Kozlowski
> > > > wrote:
> > > > >
> > > > > O
On Fri, Mar 25, 2022 at 09:31:35AM -0700, Abhinav Kumar wrote:
> Hi Liviu
Hi Abhinav,
Sorry for the delay, got busy with other things at the beginning of the week.
>
> On 3/25/2022 3:19 AM, Liviu Dudau wrote:
> > On Thu, Mar 24, 2022 at 09:36:50AM -0700, Abhinav Kumar wrote:
> > > Hi Liviu
> >
On Wed, 30 Mar 2022, Ville Syrjälä wrote:
> On Wed, Mar 30, 2022 at 08:04:26PM +0300, Jani Nikula wrote:
>> The invalid EDID block filtering uses the number of valid EDID
>> extensions instead of all EDID extensions for looping the extensions in
>> the copy. This is fine, by coincidence, if all th
On 31/03/2022 08:53, Sankeerth Billakanti (QUIC) wrote:
Hi Dmitry,
On Wed, 30 Mar 2022 at 19:03, Sankeerth Billakanti
wrote:
The interrupt register will still reflect the connect and disconnect
interrupt status without generating an actual HW interrupt.
The controller driver should not handl
Hi Lucas,
On Wed, Mar 23, 2022 at 05:08:22PM +0100, Lucas Stach wrote:
> 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 Sta
Hi:
On 3/31/22 16:18, Sascha Hauer wrote:
On Thu, Mar 31, 2022 at 03:20:37PM +0800, Andy Yan wrote:
Hi Sascha:
On 3/31/22 15:06, Sascha Hauer wrote:
On Wed, Mar 30, 2022 at 08:50:09PM +0800, Andy Yan wrote:
Hi Sascha:
On 3/30/22 14:39, Sascha Hauer wrote:
Hi Andy,
On Tue, Mar 29, 2022 at
Hi Dmitry,
> On 31/03/2022 08:53, Sankeerth Billakanti (QUIC) wrote:
> > Hi Dmitry,
> >
> >> On Wed, 30 Mar 2022 at 19:03, Sankeerth Billakanti
> >> wrote:
> >>>
> >>> The interrupt register will still reflect the connect and disconnect
> >>> interrupt status without generating an actual HW inter
On Thu, 31 Mar 2022 at 14:05, Sankeerth Billakanti
wrote:
>
> Hi Dmitry,
>
> > On 31/03/2022 08:53, Sankeerth Billakanti (QUIC) wrote:
> > > Hi Dmitry,
> > >
> > >> On Wed, 30 Mar 2022 at 19:03, Sankeerth Billakanti
> > >> wrote:
> > >>>
> > >>> The interrupt register will still reflect the conne
One thing I've forgotten, since it's only hinted at here: If/when we
switch tlb flushing from the current dumb&synchronous implementation
we now have in i915 in upstream to one with batching using dma_fence,
then I think that should be something which is done with a small
helper library of shared c
Hey Marek,
On Fri, 18 Mar 2022 at 19:48, Marek Vasut wrote:
>
> This series fixes multiple problems with the ICN6211 driver and adds
> support for configuration of the chip via I2C bus.
>
> First, in the current state, the ICN6211 driver hard-codes DPI timing
> and clock settings specific to some
Applied to drm-misc-next.
Am 28.03.22 um 19:14 schrieb Daniel Vetter:
On Mon, Mar 21, 2022 at 02:58:45PM +0100, Christian König wrote:
[SNIP]
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index ea0cde4904f0..2f808decd8d9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgp
On Mon, 21 Mar 2022 at 11:47, Lucas Stach wrote:
>
> 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 i
Hi Piotr:
On 3/31/22 03:20, Sascha Hauer wrote:
On Wed, Mar 30, 2022 at 04:52:22PM +0200, Piotr Oniszczuk wrote:
Wiadomość napisana przez Sascha Hauer w dniu
30.03.2022, o godz. 12:20:
Does it change anything if you do a "modetest -s 69@67:1920x1080" before
starting the app? Or if you run
On Thu, Mar 31, 2022 at 08:13:09PM +0800, Andy Yan wrote:
> Hi Piotr:
>
> On 3/31/22 03:20, Sascha Hauer wrote:
> > On Wed, Mar 30, 2022 at 04:52:22PM +0200, Piotr Oniszczuk wrote:
> > >
> > > > Wiadomość napisana przez Sascha Hauer w dniu
> > > > 30.03.2022, o godz. 12:20:
> > > >
> > > > Doe
This ensures userspace cannot prematurely clean-up the client before
it is fully initialised which has been proven to cause issues in the
past.
Cc: Felix Kuehling
Cc: Alex Deucher
Cc: "Christian König"
Cc: "Pan, Xinhui"
Cc: David Airlie
Cc: Daniel Vetter
Cc: amd-...@lists.freedesktop.org
Cc:
From: Daniel Vetter
The stuff never really worked, and leads to lots of fun because it
out-of-order frees atomic states. Which upsets KASAN, among other
things.
For async updates we now have a more solid solution with the
->atomic_async_check and ->atomic_async_commit hooks. Support for that
for
On 30/03/2022 20:52, Umesh Nerlige Ramappa wrote:
On Tue, Feb 22, 2022 at 01:55:55PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Tests and intel_gpu_top will share common code for parsing this file.
Signed-off-by: Tvrtko Ursulin
---
lib/igt_drm_fdinfo.c | 183
On 30/03/2022 21:11, Umesh Nerlige Ramappa wrote:
This looks very similar to existing perf_pmu tests with the slight
change that the busyness is now captured from the fdinfo.
Yep, much copy-and-paste was involved. :)
lgtm,
Reviewed-by: Umesh Nerlige Ramappa
Thanks!
Regards,
Tvrtko
Um
On Thu, Mar 31, 2022 at 03:05:45PM +0200, Maxime Ripard wrote:
> From: Daniel Vetter
>
> The stuff never really worked, and leads to lots of fun because it
> out-of-order frees atomic states. Which upsets KASAN, among other
> things.
>
> For async updates we now have a more solid solution with t
https://bugzilla.kernel.org/show_bug.cgi?id=214071
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
On 3/31/22 14:02, Robert Foss wrote:
Hey Marek,
Hi,
On Fri, 18 Mar 2022 at 19:48, Marek Vasut wrote:
This series fixes multiple problems with the ICN6211 driver and adds
support for configuration of the chip via I2C bus.
First, in the current state, the ICN6211 driver hard-codes DPI timin
From: Tvrtko Ursulin
Tests and intel_gpu_top will share common code for parsing this file.
v2:
* Fix key-value parsing if valid key line ends with ':'.
* Add DRM_CLIENT_FDINFO_MAX_ENGINES. (Umesh)
* Always zero terminate read buffer. (Umesh)
Signed-off-by: Tvrtko Ursulin
---
lib/igt_drm_fd
From: Tvrtko Ursulin
This series contains four main components:
1. Per client support for intel_gpu_top.
2. IGT test for per client data exposed via fdinfo from i915.
3. Extracting intel_gpu_top code into shared IGT libraries - which makes
possible to write:
4. Vendor agnostic rudimentar
From: Tvrtko Ursulin
Mostly inherited from the perf_pmu, some basic tests, and some tests to
verify exported GPU busyness is as expected.
Signed-off-by: Tvrtko Ursulin
---
tests/i915/drm_fdinfo.c | 555
tests/meson.build | 8 +
2 files changed,
From: Tvrtko Ursulin
Intel_gpu_top gets it's main engine configuration data via PMU probe and
uses that for per client view as well. Furthemore code so far assumed only
clients belonging from a single DRM card would be tracked in a single
clients list.
Break this inter-dependency by moving the e
From: Tvrtko Ursulin
Prep code for incoming work.
Signed-off-by: Tvrtko Ursulin
---
lib/igt_drm_fdinfo.c | 2 ++
lib/igt_drm_fdinfo.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/lib/igt_drm_fdinfo.c b/lib/igt_drm_fdinfo.c
index d5c66881ed43..3926cbd25ecf 100644
--- a/lib/igt_drm_fdin
From: Tvrtko Ursulin
Instead of hard coding the engine names, allow a map of names to indices
to either be passed in or it gets auto-detected (less efficient) while
parsing.
Signed-off-by: Tvrtko Ursulin
---
lib/igt_drm_clients.c | 7 +++---
lib/igt_drm_clients.h | 3 ++-
lib/igt_drm_fdi
From: Tvrtko Ursulin
Use the i915 exported data in /proc//fdinfo to show GPU utilization
per DRM client.
Example of the output:
intel-gpu-top: Intel Tigerlake (Gen12) @ /dev/dri/card0 - 220/ 221 MHz
70% RC6; 0.62/ 7.08 W; 760 irqs/s
ENGINES BUSY
From: Tvrtko Ursulin
Rudimentary vendor agnostic example of how lib_igt_drm_clients can be used
to display a sorted by card and usage list of processes using GPUs.
Signed-off-by: Tvrtko Ursulin
Cc: Rob Clark
---
tools/gputop.c| 276 ++
tools/mes
From: Tvrtko Ursulin
Code movement with some improvements to prepare for further work in
making a vendor agnostic gputop tool possible.
Signed-off-by: Tvrtko Ursulin
---
lib/igt_drm_clients.c | 386 +++
lib/igt_drm_clients.h | 102 +
lib/meson.build |
From: Tvrtko Ursulin
Require DRM minor match during client lookup.
Signed-off-by: Tvrtko Ursulin
---
lib/igt_drm_clients.c | 14 --
lib/igt_drm_clients.h | 2 +-
2 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/lib/igt_drm_clients.c b/lib/igt_drm_clients.c
index 1164
From: Tvrtko Ursulin
Prepare for supporting clients belonging to multiple DRM cards by storing
the DRM minor in the client record.
Signed-off-by: Tvrtko Ursulin
---
lib/igt_drm_clients.c | 33 -
lib/igt_drm_clients.h | 6 --
2 files changed, 24 insertions(+
From: Tvrtko Ursulin
It is currently unused so no need to export it as API for now.
Also change the signature to take struct drm_client_fdinfo in order to
avoid needing to pass in a sized array.
Signed-off-by: Tvrtko Ursulin
---
lib/igt_drm_clients.c | 16
lib/igt_drm_clients
From: Tvrtko Ursulin
Some libdrmclient operations require that inactive clients are last in the
list. Rather than relying on callers of the library sort routine to
implement their comparison callbacks correctly, enforce this order
directly in the library and let callers comparison callbacks conce
From: Tvrtko Ursulin
Just a rebase - fully reviewed now.
Example of the intel_gpu_top output:
intel-gpu-top: Intel Tigerlake (Gen12) @ /dev/dri/card0 - 220/ 221 MHz
70% RC6; 0.62/ 7.08 W; 760 irqs/s
From: Tvrtko Ursulin
Tracking DRM clients more explicitly will allow later patches to
accumulate past and current GPU usage in a centralised place and also
consolidate access to owning task pid/name.
Unique client id is also assigned for the purpose of distinguishing/
consolidating between multi
From: Tvrtko Ursulin
Make GEM contexts keep a reference to i915_drm_client for the whole of
of their lifetime which will come handy in following patches.
v2: Don't bother supporting selftests contexts from debugfs. (Chris)
v3 (Lucas): Finish constructing ctx before adding it to the list
v4 (Ram)
From: Tvrtko Ursulin
Similar to AMD commit
874442541133 ("drm/amdgpu: Add show_fdinfo() interface"), using the
infrastructure added in previous patches, we add basic client info
and GPU engine utilisation for i915.
Example of the output:
pos:0
flags: 012
mnt_id: 21
drm-driver:
From: Tvrtko Ursulin
Track context active (on hardware) status together with the start
timestamp.
This will be used to provide better granularity of context
runtime reporting in conjunction with already tracked pphwsp accumulated
runtime.
The latter is only updated on context save so does not g
From: Tvrtko Ursulin
This will be useful to have at hand in a following patch.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/gt/intel_engine_user.c | 11 ++-
drivers/gpu/drm/i915/i915_drv.h | 1 +
2 files changed, 7 insertions(+
From: Tvrtko Ursulin
As contexts are abandoned we want to remember how much GPU time they used
(per class) so later we can used it for smarter purposes.
As GEM contexts are closed we want to have the DRM client remember how
much GPU time they used (per class) so later we can used it for smarter
From: Tvrtko Ursulin
Proposal to standardise the fdinfo text format as optionally output by DRM
drivers.
Idea is that a simple but, well defined, spec will enable generic
userspace tools to be written while at the same time avoiding a more heavy
handed approach of adding a mid-layer to DRM.
i91
From: Tvrtko Ursulin
We soon want to start answering questions like how much GPU time is the
context belonging to a client which exited still using.
To enable this we start tracking all context belonging to a client on a
separate list.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Aravind Iddamse
On Fri, 25 Mar 2022 at 17:04, Adam Ford wrote:
>
> On Fri, Mar 25, 2022 at 10:00 AM Marek Szyprowski
> wrote:
> >
> > Hi Jagan,
> >
> > On 03.03.2022 17:36, Jagan Teki wrote:
> > > Updated series about drm bridge conversion of exynos dsi.
> > >
> > > Previous version can be accessible, here [1].
During a commit, the core clock, which feeds the HVS, needs to run at
a minimum of 500MHz.
While doing that commit, we can also change the mode to one that
requires a higher core clock, so we take the core clock rate associated
to that new state into account for that boost.
However, the old state
Hi,
These patches used to be part of the series:
https://lore.kernel.org/all/20220221134155.125447-1-max...@cerno.tech/
but since the main patch got superseded by another core patch, I've split the
cleanup patches out into their own series.
Let me know what you think,
Maxime
Changes from v1:
Setting the DISPLISTx register needs to occur in every case, and we
don't need to protect the register using the event_lock, so we can just
move it after the if branches and simplify a bit the function.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hvs.c | 9 +++--
1 file changed,
The assigned_channel field of our vc4_crtc_state structure is accessed
multiple times in vc4_hvs_atomic_flush, so let's move it to a variable
that can be used in all those places.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hvs.c | 9 +
1 file changed, 5 insertions(+), 4 del
The vc4_hvs_update_dlist function mostly deals with setting up the
vblank events and setting up the dlist entry pointer to our current
active one.
We'll want to do the former separately from the vblank handling in later
patches, so let's move it to a function of its own.
Signed-off-by: Maxime Rip
atomic_flush will be called for each CRTC even if they aren't enabled.
The whole code we have there will thus run without a properly affected
channel, which can then result in all sorts of weird behaviour.
Fortunately, the DRM_PLANE_COMMIT_ACTIVE_ONLY flag will skip the CRTC
atomic_begin and atom
In order to get the field currently being output, the driver has been
using the display FIFO frame count in the HVS, reading a 6-bit field at
the offset 12 in the DISPSTATx register.
While that field is indeed at that location for the FIFO 1 and 2, the
one for the FIFO0 is actually in the DISPSTAT
Those macros are really about the HVS itself, and thus its associated
structure vc4_hvs, rather than the entire (virtual) vc4 device.
Let's change those macros to use the hvs pointer directly, and change
the calling sites accordingly.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crt
Am 2022-03-31 um 08:21 schrieb Lee Jones:
This ensures userspace cannot prematurely clean-up the client before
it is fully initialised which has been proven to cause issues in the
past.
Cc: Felix Kuehling
Cc: Alex Deucher
Cc: "Christian König"
Cc: "Pan, Xinhui"
Cc: David Airlie
Cc: Daniel
On Thu, 31 Mar 2022 at 15:42, Marek Vasut wrote:
>
> On 3/31/22 14:02, Robert Foss wrote:
> > Hey Marek,
>
> Hi,
>
> > On Fri, 18 Mar 2022 at 19:48, Marek Vasut wrote:
> >>
> >> This series fixes multiple problems with the ICN6211 driver and adds
> >> support for configuration of the chip via I2C
+ Robert
On Tue, Feb 22, 2022 at 12:17 PM Jagan Teki wrote:
>
> On Mon, Feb 7, 2022 at 6:34 PM Jagan Teki wrote:
> >
> > Hi Sam,
> >
> > On Mon, Dec 20, 2021 at 1:45 PM Sam Ravnborg wrote:
> > >
> > > Hi Jagan,
> > >
> > > On Sun, Dec 19, 2021 at 10:10:10PM +0530, Jagan Teki wrote:
> > > > Hi S
On Thu, 31 Mar 2022 at 16:50, Jagan Teki wrote:
>
> + Robert
>
> On Tue, Feb 22, 2022 at 12:17 PM Jagan Teki
> wrote:
> >
> > On Mon, Feb 7, 2022 at 6:34 PM Jagan Teki
> > wrote:
> > >
> > > Hi Sam,
> > >
> > > On Mon, Dec 20, 2021 at 1:45 PM Sam Ravnborg wrote:
> > > >
> > > > Hi Jagan,
> >
> Wiadomość napisana przez Andy Yan w dniu
> 31.03.2022, o godz. 14:13:
>
>
> Piotr:
>
> What soc is on you board? rk3566 or rk3568?
it is rk3566 in x96-x6 tvbox
>
> I have a scripts[0] use io[1] command to dump the VOP2 register you can use
> it dump the register configuration when y
On Tue, Mar 29, 2022 at 09:42:14PM +0300, Jani Nikula wrote:
> Add edid_block_check() that only checks the EDID block validity, without
> any actions. Turns out it's simple and crystal clear.
>
> Rewrite drm_edid_block_valid() around it, keeping all the functionality
> fairly closely the same, war
On Tue, Mar 29, 2022 at 09:42:15PM +0300, Jani Nikula wrote:
> Just i is a bit terse, clarify what it's about.
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edid.c | 16 +---
> 1 file changed, 9 insertions(+), 7 deletion
On Tue, Mar 29, 2022 at 09:42:19PM +0300, Jani Nikula wrote:
> The code modifying the EDID block should not need to do tricks to fix
> the checksum. We have a function for computing the checksum, use it.
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_edid.c | 2 +
On Thu, Mar 31, 2022 at 04:53:05PM +0200, Piotr Oniszczuk wrote:
>
>
> > Wiadomość napisana przez Andy Yan w dniu
> > 31.03.2022, o godz. 14:13:
> >
> >
> > Piotr:
> >
> > What soc is on you board? rk3566 or rk3568?
>
> it is rk3566 in x96-x6 tvbox
>
>
> >
> > I have a scripts[0] use io
TI DLPC3433 is a MIPI DSI based display controller bridge
for processing high resolution DMD based projectors.
It has a flexible configuration of MIPI DSI and DPI signal
input that produces a DMD output in RGB565, RGB666, RGB888
formats.
It supports upto 720p resolution with 60 and 120 Hz refresh
TI DLPC3433 is a MIPI DSI based display controller bridge
for processing high resolution DMD based projectors.
It has a flexible configuration of MIPI DSI and DPI signal
input that produces a DMD output in RGB565, RGB666, RGB888
formats.
It supports upto 720p resolution with 60 and 120 Hz refresh
The HFP_HSW_HBP_HI register must be programmed with 2 LSbits of each
Horizontal Front Porch/Sync/Back Porch. Currently the driver programs
this register to 0, which breaks displays with either value above 255.
The HFP_MIN register must be set to the same value as HFP_LI, otherwise
there is visible
This series fixes multiple problems with the ICN6211 driver and adds
support for configuration of the chip via I2C bus.
First, in the current state, the ICN6211 driver hard-codes DPI timing
and clock settings specific to some unknown panel. The settings provided
by panel driver are ignored. Using
The chip register layout has nothing to do with MIPI DCS, the registers
incorrectly marked as MIPI DCS in the driver are regular chip registers
often with completely different function.
Fill in the actual register names and bits from [1] and [2] and add the
entire register layout, since the docume
Implement .atomic_get_input_bus_fmts callback, which sets up the
input (DSI-end) format, and that format can then be used in pipeline
format negotiation between the DSI-end of this bridge and the other
component closer to the scanout engine.
Acked-by: Maxime Ripard
Signed-off-by: Marek Vasut
Cc:
The driver currently hard-codes HS/VS polarity to active-low and DE to
active-high, which is not correct for a lot of supported DPI panels.
Add the missing mode flag handling for HS/VS/DE polarity.
Acked-by: Maxime Ripard
Signed-off-by: Marek Vasut
Cc: Jagan Teki
Cc: Maxime Ripard
Cc: Robert F
The chip contains fractional PLL, however the driver currently hard-codes
one specific PLL setting. Implement generic PLL parameter calculation code,
so any DPI panel with arbitrary pixel clock can be attached to this bridge.
The datasheet for this bridge is not available, the PLL behavior has bee
Both example code [1], [2] as well as one provided by custom panel vendor
set register SYS_CTRL_1 to 0x88. What exactly does the value mean is unknown
due to unavailable datasheet. Align this register value with example code.
[1]
https://github.com/rockchip-linux/kernel/blob/develop-4.19/drivers/
The ICN6211 chip starts in I2C configuration mode after cold boot.
Implement support for configuring the chip via I2C in addition to
the current DSI LP command mode configuration support. The later
seems to be available only on chips which have additional MCU on
the panel/bridge board which preconf
The chip is capable of swapping DPI RGB channels. The driver currently
does not implement support for this functionality. Write the MIPI_PN_SWAP
register to 0 to assure the color swap is disabled.
Acked-by: Maxime Ripard
Signed-off-by: Marek Vasut
Cc: Jagan Teki
Cc: Maxime Ripard
Cc: Robert Fo
The DSI burst mode is more energy efficient than the DSI sync pulse mode,
make use of the burst mode since the chip supports it as well. Disable the
generation of EoT packet, the chip ignores it, so no point in emitting it.
Enable transmission of data in LP mode, otherwise register read via DSI
doe
Rename and inline macro ICN6211_DSI() into function chipone_writeb()
to keep all function names lower-case. No functional change.
Acked-by: Maxime Ripard
Signed-off-by: Marek Vasut
Cc: Jagan Teki
Cc: Maxime Ripard
Cc: Robert Foss
Cc: Sam Ravnborg
Cc: Thomas Zimmermann
To: dri-devel@lists.fr
1 - 100 of 219 matches
Mail list logo
