On 1/13/21 7:06 AM, Nicolas Boichat wrote:
Hi!
Follow-up on the v5 [1], things have gotten significantly
better in the last 9 months, thanks to the efforts on Bifrost
support by the Collabora team (and probably others I'm not
aware of).
I've been testing this series on a MT8183/kukui device, wi
On 1/7/21 9:49 AM, Nicolas Boichat wrote:
On Thu, Jan 7, 2021 at 4:31 PM Tomeu Vizoso wrote:
On 1/7/21 9:26 AM, Nicolas Boichat wrote:
GPUs with more than a single regulator (e.g. G72 on MT8183) will
require platform-specific handling, disable devfreq for now.
Signed-off-by: Nicolas Boichat
On 1/7/21 9:26 AM, Nicolas Boichat wrote:
GPUs with more than a single regulator (e.g. G72 on MT8183) will
require platform-specific handling, disable devfreq for now.
Signed-off-by: Nicolas Boichat
---
Changes in v7:
- Fix GPU ID in commit message
Changes in v6:
- New change
drivers/g
Hi Clément,
Have just noticed that my Pine H64 board hangs when I try to set the
performance governor for the GPU devfreq.
Is this a known bug?
Thanks,
Tomeu
On Mon, 5 Oct 2020 at 08:44, Tomeu Vizoso wrote:
>
> On Fri, 19 Jun 2020 at 11:00, Steven Price wrote:
> >
> > On 11/06/2020 09:58, Tomeu Vizoso wrote:
> > > Mesa now supports some Bifrost devices, so enable it.
> > >
> > > Signed-off-by: To
On Fri, 19 Jun 2020 at 11:00, Steven Price wrote:
>
> On 11/06/2020 09:58, Tomeu Vizoso wrote:
> > Mesa now supports some Bifrost devices, so enable it.
> >
> > Signed-off-by: Tomeu Vizoso
>
> Reviewed-by: Steven Price
>
> I've also dug out my Hikey960 (
Bifrost devices do support the flush reduction feature, so on first job
submit we were trying to read the register while still powered off.
If the GPU is powered off, the feature doesn't bring any benefit, so
don't try to read.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/dr
Mesa now supports some Bifrost devices, so enable it.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 882fecc33fdb..8ff8e140f91e
On 5/29/20 2:38 PM, Clément Péron wrote:
Hi Steven
On Thu, 28 May 2020 at 15:22, Steven Price wrote:
On 10/05/2020 17:55, Clément Péron wrote:
Later we will introduce devfreq probing regulator if they
are present. As regulator should be probe only one time we
need to get this logic in the de
On 5/10/20 6:55 PM, Clément Péron wrote:
Hi,
This serie cleans and adds regulator support to Panfrost devfreq.
This is mostly based on comment for the freshly introduced lima
devfreq.
We need to add regulator support because on Allwinner the GPU OPP
table defines both frequencies and voltages.
With the goal of making it easier for CI services such as KernelCI to
run tests for it.
Signed-off-by: Tomeu Vizoso
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig
b/arch/arm/configs/multi_v7_defconfig
index
With the goal of making it easier for CI services such as KernelCI to
run tests for it.
Signed-off-by: Tomeu Vizoso
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 4d583514258c..d588ceb9aa3c
On Wed, 29 May 2019 at 19:38, Robin Murphy wrote:
>
> On 29/05/2019 16:09, Tomeu Vizoso wrote:
> > On Tue, 21 May 2019 at 18:11, Clément Péron wrote:
> >>
> > [snip]
> >> [ 345.204813] panfrost 180.gpu: mmu irq status=1
> >> [ 345.209617] panf
On Wed, 29 May 2019 at 17:37, Clément Péron wrote:
>
> Hi Tomeu,
>
> On Wed, 29 May 2019 at 17:33, Tomeu Vizoso wrote:
> >
> > The GPU driver needs them to change the clock frequency and regulator
> > voltage depending on the load.
>
> As requested by Maxim
The GPU driver needs them to change the clock frequency and regulator
voltage depending on the load.
Signed-off-by: Tomeu Vizoso
Cc: Clément Péron
---
Feel free to pick up this patch if you are going to keep pushing this
series forward.
Thanks,
Tomeu
---
arch/arm64/boot/dts/allwinner
On Fri, 24 May 2019 at 15:54, Eduardo Valentin wrote:
>
> Hello,
>
> On Fri, May 24, 2019 at 10:23:09AM +0200, Tomeu Vizoso wrote:
> > On Fri, 24 May 2019 at 04:40, Eduardo Valentin wrote:
> > >
> > > On Thu, May 23, 2019 at 11:46:47AM +0200, To
On Fri, 24 May 2019 at 04:40, Eduardo Valentin wrote:
>
> On Thu, May 23, 2019 at 11:46:47AM +0200, Tomeu Vizoso wrote:
> > Hi Eduardo,
> >
> > I saw that for 5.1 [0] you included a kernelci boot report for your
> > tree, but not for 5.2. Have you found anything
Hi Eduardo,
I saw that for 5.1 [0] you included a kernelci boot report for your
tree, but not for 5.2. Have you found anything that should be improved
in KernelCI for it to be more useful to maintainers like you?
[0] https://lore.kernel.org/lkml/20190306161207.GA7365@localhost.localdomain/
I fou
On Wed, 24 Apr 2019 at 15:20, Daniel Vetter wrote:
>
> On Wed, Apr 24, 2019 at 03:13:53PM +0200, Tomeu Vizoso wrote:
> > So userspace can get feedback on any error conditions, instead of going
> > ahead and things breaking later.
> >
> > Signed-off-by: Tomeu V
On Tue, 23 Apr 2019 at 11:56, Enric Balletbo i Serra
wrote:
>
> Hi Tomeu,
>
> On 23/4/19 10:11, Tomeu Vizoso wrote:
> > Callers don't expect it to return NULL, but an error code.
> >
> > Fixes Oops such as the one below, when one tries to set a governor that
>
x100/0x1e0)
[] (kernfs_fop_write) from [] (__vfs_write+0x2c/0x17c)
[] (__vfs_write) from [] (vfs_write+0xa4/0x184)
[] (vfs_write) from [] (ksys_write+0x4c/0xac)
[] (ksys_write) from [] (ret_fast_syscall+0x0/0x28)
Signed-off-by: Tomeu Vizoso
Fixes: 23c7b54ca1cd ("PM / devfreq: Fix devfreq_add_device() w
NanoPi NEO4.
Signed-off-by: Tomeu Vizoso
---
v2: - Rename compatible from friendlyelec to friendlyarm, to match
existing bindings
- Remove superfluous node spi1
v3: - Rewrite regulator tree to match the schematics (Heiko)
- Sort top-level nodes alphabetically (Heiko)
- Used
NanoPi NEO4.
Signed-off-by: Tomeu Vizoso
---
v2: - Rename compatible from friendlyelec to friendlyarm, to match
existing bindings
- Remove superfluous node spi1
v3: - Rewrite regulator tree to match the schematics (Heiko)
- Sort top-level nodes alphabetically (Heiko)
- Used
NanoPi NEO4.
Signed-off-by: Tomeu Vizoso
---
v2: - Rename compatible from friendlyelec to friendlyarm, to match
existing bindings
- Remove superfluous node spi1
---
.../devicetree/bindings/arm/rockchip.txt | 4 +
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../boot
NanoPi NEO4.
Signed-off-by: Tomeu Vizoso
---
.../devicetree/bindings/arm/rockchip.txt | 4 +
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../boot/dts/rockchip/rk3399-nanopc-t4.dts| 18 +
.../boot/dts/rockchip/rk3399-nanopi4.dtsi | 782 ++
4 files changed
28 PM, Heiko Stuebner wrote:
>>>> Am Montag, 26. März 2018, 11:00:01 CEST schrieb Tomeu Vizoso:
>>>>> devm_regulator_get_optional returns -ENODEV if the regulator isn't
>>>>> there, so if that's the case we have to make sure not to leave -ENODEV
Hi there,
in today's linux-next, the DRM driver fails to probe because the iommu
driver fails to find the aclk. I need to apply this patch for things
to work again.
Thanks,
Tomeu
On 23 March 2018 at 08:38, Jeffy Chen wrote:
> Add clocks in iommu nodes, since we are going to control clocks in
>
Hi Minas,
On 04/05/2018 09:54 AM, Minas Harutyunyan wrote:
Hi Tomeu,
On 3/26/2018 1:01 PM, Tomeu Vizoso wrote:
devm_regulator_get_optional returns -ENODEV if the regulator isn't
there, so if that's the case we have to make sure not to leave -ENODEV
in the regulator pointer.
Also,
Could this patch be picked up, please?
Thanks,
Tomeu
On 26 March 2018 at 13:51, Heiko Stübner wrote:
> Am Montag, 26. März 2018, 11:00:01 CEST schrieb Tomeu Vizoso:
>> devm_regulator_get_optional returns -ENODEV if the regulator isn't
>> there, so if that's the case we
_hcd_start.
Fixes: 531ef5ebea96 ("usb: dwc2: add support for host mode external vbus
supply")
Cc: Amelie Delaunay
Signed-off-by: Tomeu Vizoso
---
v2: Only overwrite the error in the pointer after checking it (Heiko
Stübner )
v3: Remove hunks that shouldn't be in this patch
v4:
Currently we warn the user when the root hub lost power after resume,
but the user cannot do anything about it so it should probably be a
notice.
This will reduce the noise in the console during suspend and resume,
which is already quite significant in many systems.
Signed-off-by: Tomeu Vizoso
To allow userspace to prevent this message from appearing in the
console by changing the log priority.
This matches other informative messages that the power subsystem emits
when the system changes power states.
Signed-off-by: Tomeu Vizoso
---
kernel/printk/printk.c | 2 +-
1 file changed, 1
On 03/22/2018 02:26 PM, Heiko Stübner wrote:
Am Donnerstag, 22. März 2018, 14:14:51 CET schrieb Tomeu Vizoso:
devm_regulator_get_optional returns -ENODEV if the regulator isn't
there, so if that's the case we have to make sure not to leave -ENODEV
in the regulator pointer.
Also, ma
_hcd_start.
Fixes: 531ef5ebea96 ("usb: dwc2: add support for host mode external vbus
supply")
Cc: Amelie Delaunay
Signed-off-by: Tomeu Vizoso
---
v2: Only overwrite the error in the pointer after checking it (Heiko
Stübner )
v3: Remove hunks that shouldn't be in this patch
--
_hcd_start.
Fixes: 531ef5ebea96 ("usb: dwc2: add support for host mode external vbus
supply")
Cc: Amelie Delaunay
Signed-off-by: Tomeu Vizoso
---
v2: Only overwrite the error in the pointer after checking it (Heiko
Stübner )
---
arch/arm/configs/multi_v7_defconfig | 3 +++
dr
_hcd_start.
Fixes: 531ef5ebea96 ("usb: dwc2: add support for host mode external vbus
supply")
Cc: Amelie Delaunay
Signed-off-by: Tomeu Vizoso
---
drivers/usb/dwc2/hcd.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/
On 02/12/2018 12:45 PM, Gerd Hoffmann wrote: 4. QEMU pops
data+buffers from the virtqueue, looks up shmem FD for each
resource, sends data + FDs to the compositor with SCM_RIGHTS
>>>
>>> BTW: Is there a 1:1 relationship between buffers and shmem blocks? Or
>>> does the wayland protocol
On 02/12/2018 12:45 PM, Gerd Hoffmann wrote:
Hi,
(a) software rendering: client allocates shared memory buffer, renders
into it, then passes a file handle for that shmem block together
with some meta data (size, format, ...) to the wayland server.
(b) gpu rendering:
On 02/12/2018 03:27 PM, Gerd Hoffmann wrote:
On Mon, Feb 12, 2018 at 03:00:24PM +0100, Tomeu Vizoso wrote:
On 02/12/2018 12:52 PM, Gerd Hoffmann wrote:
Hi,
can we reach agreement on whether vsock should be involved in this?
I think the best approach would be to have guest proxy and
On 02/12/2018 12:52 PM, Gerd Hoffmann wrote:
Hi,
can we reach agreement on whether vsock should be involved in this?
I think the best approach would be to have guest proxy and host proxy
use vsock for the wayland protocol. Use a wayland protocol extension to
reference the buffers in stdvg
Hi Gerd and Stefan,
can we reach agreement on whether vsock should be involved in this?
Thanks,
Tomeu
On 02/07/2018 10:49 AM, Tomeu Vizoso wrote:
On 02/06/2018 03:23 PM, Gerd Hoffmann wrote:
Hi,
Hmm? I'm assuming the wayland client (in the guest) talks to the
wayland proxy, usin
On 02/06/2018 03:23 PM, Gerd Hoffmann wrote:
Hi,
Hmm? I'm assuming the wayland client (in the guest) talks to the
wayland proxy, using the wayland protocol, like it would talk to a
wayland display server. Buffers must be passed from client to
server/proxy somehow, probably using fd passing
On 02/07/2018 02:09 AM, Michael S. Tsirkin wrote:
On Tue, Feb 06, 2018 at 03:23:02PM +0100, Gerd Hoffmann wrote:
Creation of shareable buffer by guest
-
1. Client requests virtio driver to create a buffer suitable for sharing
with host (DRM_VIRTGP
On 02/05/2018 05:03 PM, Gerd Hoffmann wrote:
On Mon, Feb 05, 2018 at 03:46:17PM +0100, Tomeu Vizoso wrote:
On 02/05/2018 01:20 PM, Gerd Hoffmann wrote:
Hi,
Why not use virtio-vsock to run the wayland protocol? I don't like
the idea to duplicate something with very simliar function
On 02/05/2018 01:20 PM, Gerd Hoffmann wrote:
Hi,
Why not use virtio-vsock to run the wayland protocol? I don't like
the idea to duplicate something with very simliar functionality in
virtio-gpu.
The reason for abandoning that approach was the type of objects that
could be shared via virtio
On 1 February 2018 at 17:36, Gerd Hoffmann wrote:
Hi,
Sorry for joining the party late. Had a broken finger and was
offline for a bunch of weeks (and a buif backlog afterwards ...).
Hi, no problem, hope it's fine now.
This is to allow clients running within VMs to be able to
communicate wit
When retrieving queued messages from the compositor in the host for
clients in the guest, handle buffers that may be passed.
These buffers should have been mapped to the guest's address space, for
example via the KVM_SET_USER_MEMORY_REGION ioctl.
Signed-off-by: Tomeu Vizoso
---
driver
absence of winsrv support in QEMU (Dave Airlie)
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 1 +
drivers/gpu/drm/virtio/virtgpu_drv.h | 39 -
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 165 +++
drivers/gpu/drm/virtio/virtgpu_kms.c | 66
o the host part of a resource, so the extra copy in
TRANSFER_TO_HOST isn't needed.
Have pushed the QEMU counterpart to this branch, though it isn't as
polished atm:
https://gitlab.collabora.com/tomeu/qemu/commits/winsrv-wip
Thanks,
Tomeu
Tomeu Vizoso (2):
drm/virtio: Add window serve
On 01/12/2018 05:11 AM, Dave Airlie wrote:
this work is based on the virtio_wl driver in the ChromeOS kernel by
Zach Reizner, currently at:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/virtio/virtio_wl.c
There's two features missing in this patch when
On 28 December 2017 at 12:53, Tomeu Vizoso wrote:
> This is to allow clients running within VMs to be able to communicate
> with a compositor in the host. Clients will use the communication
> protocol that the compositor supports, and virtio-gpu will assist with
> making buffers avail
On 26 December 2017 at 19:19, Matt Roper wrote:
> On Wed, Dec 20, 2017 at 10:59:57AM +0100, Daniel Vetter wrote:
>> On Tue, Dec 19, 2017 at 03:27:31PM -0800, Dongwon Kim wrote:
>> > I forgot to include this brief information about this patch series.
>> >
>> > This patch series contains the impleme
: Tomeu Vizoso
Cc: Zach Reizner
---
Hi,
this work is based on the virtio_wl driver in the ChromeOS kernel by
Zach Reizner, currently at:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/virtio/virtio_wl.c
There's two features missing in this patch
tested with Wayland clients that make use of wl_shm to
pass buffers to the compositor, but is expected to work similarly for X
clients that make use of MIT-SHM with FD passing.
Signed-off-by: Tomeu Vizoso
Cc: Zach Reizner
---
Hi,
this work is based on the virtio_wl driver in the ChromeOS kernel
If the wait timeouts, the caps are probably invalid and we shouldn't be
passing them to userspace.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
b/drivers/gpu/drm/v
And now with the correct email.
Sorry about that,
Tomeu
On 16 November 2017 at 10:16, Tomeu Vizoso wrote:
> Adding regress...@leemhuis.info to CC so this regression is tracked.
>
> Regards,
>
> Tomeu
>
> On 8 November 2017 at 09:37, Tomeu Vizoso wrote:
>> On 6
Adding regress...@leemhuis.info to CC so this regression is tracked.
Regards,
Tomeu
On 8 November 2017 at 09:37, Tomeu Vizoso wrote:
> On 6 November 2017 at 23:01, Tom Lendacky wrote:
>> On 11/6/2017 3:41 PM, H. Peter Anvin wrote:
>>>
>>> On 11/06/17 12:17, Tom Len
Add a boolean variable that is set to true when the MP-table is found.
>>> Use this variable for testing if the MP-table was found so that even a
>>> value of 0 for mpf_base will result in continued parsing of the MP-table.
>>>
>>> Reported-by: Tomeu Vizoso
>>
On 3 November 2017 at 16:31, Tom Lendacky wrote:
> On 11/3/2017 10:12 AM, Tomeu Vizoso wrote:
>>
>> On 17 July 2017 at 23:10, Tom Lendacky wrote:
>>>
>>> The SMP MP-table is built by UEFI and placed in memory in a decrypted
>>> state. These tables
On 17 July 2017 at 23:10, Tom Lendacky wrote:
> The SMP MP-table is built by UEFI and placed in memory in a decrypted
> state. These tables are accessed using a mix of early_memremap(),
> early_memunmap(), phys_to_virt() and virt_to_phys(). Change all accesses
> to use early_memremap()/early_memun
On 29 March 2017 at 23:34, J. Bruce Fields wrote:
> On Wed, Mar 29, 2017 at 05:27:23PM +0200, Tomeu Vizoso wrote:
>> Labelling of files in a NFSv4.2 currently fails with ENOTSUPP because
>> the mount point doesn't have SBLABEL_MNT.
>>
>> Add specific condition
Labelling of files in a NFSv4.2 currently fails with ENOTSUPP because
the mount point doesn't have SBLABEL_MNT.
Add specific condition for NFS4 filesystems so it gets correctly
labeled.
Signed-off-by: Tomeu Vizoso
Cc: J. Bruce Fields
---
Hi,
cannot remotely say that I currently under
On 9 March 2017 at 16:50, Paul E. McKenney wrote:
>
> On Thu, Mar 09, 2017 at 07:29:26AM -0800, Paul E. McKenney wrote:
> > On Thu, Mar 09, 2017 at 04:12:55PM +0100, Peter Zijlstra wrote:
> > > On Thu, Mar 09, 2017 at 02:08:23PM +0100, Thomas Gleixner wrote:
> > > > On Wed, 8 Mar 2017, Paul E. McK
Gabriel Krisman reported these warnings when building the documentation:
./drivers/gpu/drm/drm_dp_helper.c:1165: warning: No description found
for parameter 'crtc'
./drivers/gpu/drm/drm_dp_helper.c:1166: warning: No description found
for parameter 'crtc'
Signed-
backpointer in drm_dp_aux becomes drm_crtc instead of
drm_connector, following discussion with Sean Paul.
Thanks,
Tomeu
Tomeu Vizoso (4):
drm/dp: add crtc backpointer to drm_dp_aux
drm/dp: add helpers for capture of frame CRCs
drm/bridge: analogix_dp: add helpers for capture of frame CRCs
Implement the .set_crc_source() callback and call the DP helpers
accordingly to start and stop CRC capture.
This is only done if this CRTC is currently using the eDP connector.
v3: Remove superfluous check on rockchip_crtc_state->output_type
v6: Remove superfluous variable
Signed-off-by: To
5: Move back to make the retry explicitly once
v6: Set and use the drm_crtc backpointer (Sean Paul)
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/drm_dp_helper.c | 126
include/drm/drm_dp_helper.h | 7 +++
2 files changed, 133 insertions(+)
diff
This backpointer allows DP helpers to access the crtc it's currently
being used for.
v6: Have the backpointer be to drm_crtc (Sean Paul)
Signed-off-by: Tomeu Vizoso
---
include/drm/drm_dp_helper.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/drm/drm_dp_helper.h b/includ
Add two simple functions that just take the drm_dp_aux from our struct
and calls the corresponding DP helpers with it.
v6: Pass to the DP helper the drm_crtc of the current connector (Sean Paul)
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 22
bug.cgi?id=99869
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/drm_edid.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 24e7b282f16c..d994ccf94f88 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -148,6
On 10 January 2017 at 17:31, Daniel Vetter wrote:
> On Tue, Jan 10, 2017 at 05:54:57PM +0200, Ville Syrjälä wrote:
>> On Tue, Jan 10, 2017 at 02:43:05PM +0100, Tomeu Vizoso wrote:
>> > Use drm_accurate_vblank_count so we have the full 32 bit to represent
>> > the frame
On 01/12/2017 07:26 PM, Ben Hutchings wrote:
> On Thu, 2017-01-12 at 18:41 +0100, Greg Kroah-Hartman wrote:
>> On Thu, Jan 12, 2017 at 11:27:01AM -0600, Rob Herring wrote:
>>> I just noticed that we have a new device attribute 'deferred_probe'
>>> added in 4.10 with this commit:
>>>
>>> commit 6751
.
Also, I have left the connector back pointer in the AUX structure, as on
IRC nor danvet nor me could find a good reason to change it.
Thanks,
Tomeu
Tomeu Vizoso (4):
drm/bridge: analogix_dp: set connector to drm_dp_aux
drm/dp: add helpers for capture of frame CRCs
drm/bridge: analogix_dp: a
Implement the .set_crc_source() callback and call the DP helpers
accordingly to start and stop CRC capture.
This is only done if this CRTC is currently using the eDP connector.
v3: Remove superfluous check on rockchip_crtc_state->output_type
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/
Add two simple functions that just take the drm_dp_aux from our struct
and calls the corresponding DP helpers with it.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 16
include/drm/bridge/analogix_dp.h | 3 +++
2 files
5: Move back to make the retry explicitly once
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/drm_dp_helper.c | 124
include/drm/drm_dp_helper.h | 7 +++
2 files changed, 131 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/
Set the backpointer so that the DP helpers are able to access the
connector that the drm_dp_aux is associated with.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers
the new ABI we
skip the 1st or 2nd frames.
v9:
- Add stub for intel_crtc_set_crc_source.
v12:
- Rebased.
- Remove stub for intel_crtc_set_crc_source and instead set the
callback to NULL (Jani Nikula).
v15:
- Rebased.
Signed-off-by: Tomeu Vizoso
Reviewed-by: Emil
Use drm_accurate_vblank_count so we have the full 32 bit to represent
the frame counter and userspace has a simpler way of knowing when the
counter wraps around.
Signed-off-by: Tomeu Vizoso
Reviewed-by: Emil Velikov
Reviewed-by: Robert Foss
---
drivers/gpu/drm/i915/i915_irq.c | 6 +++---
1
Hi,
here are the last two patches that remain to be merged in this series,
rebased on today's drm-tip.
Thanks,
Tomeu
Tomeu Vizoso (2):
drm/i915: Use new CRC debugfs API
drm/i915: Put "cooked" vlank counters in frame CRC lines
drivers/gpu/drm/i915/i915_drv.h | 1 +
Set the backpointer so that the DP helpers are able to access the
connector that the drm_dp_aux is associated with.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers
l.
Thanks,
Tomeu
Tomeu Vizoso (5):
drm/dp: add connector backpointer to drm_dp_aux
drm/bridge: analogix_dp: set connector to drm_dp_aux
drm/dp: add helpers for capture of frame CRCs
drm/bridge: analogix_dp: add helpers for capture of frame CRCs
drm/rockchip: Implement CRC debugfs API
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/drm_dp_helper.c | 129
include/drm/drm_dp_helper.h | 7 +++
2 files changed, 136 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 3e6fe82c6d64..f901
This backpointer allows DP helpers to access the connector it's being
used for.
Signed-off-by: Tomeu Vizoso
---
include/drm/drm_dp_helper.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 55bbeb0ff594..4fa77b434594 1
Add two simple functions that just take the drm_dp_aux from our struct
and calls the corresponding DP helpers with it.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 16
include/drm/bridge/analogix_dp.h | 3 +++
2 files
Implement the .set_crc_source() callback and call the DP helpers
accordingly to start and stop CRC capture.
This is only done if this CRTC is currently using the eDP connector.
v3: Remove superfluous check on rockchip_crtc_state->output_type
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/
On 6 January 2017 at 16:56, Sean Paul wrote:
> On Fri, Jan 6, 2017 at 9:30 AM, Tomeu Vizoso
> wrote:
>> Implement the .set_crc_source() callback and call the DP helpers
>> accordingly to start and stop CRC capture.
>>
>> This is only done if this CRTC is cur
On 6 January 2017 at 16:56, Sean Paul wrote:
> On Fri, Jan 6, 2017 at 9:30 AM, Tomeu Vizoso
> wrote:
>> Adds helpers for starting and stopping capture of frame CRCs through the
>> DPCD. When capture is on, a worker waits for vblanks and retrieves the
>> frame CRC to pu
On 6 January 2017 at 16:56, Sean Paul wrote:
> On Fri, Jan 6, 2017 at 9:30 AM, Tomeu Vizoso
> wrote:
>> This backpointer allows DP helpers to access the connector it's being
>> used for.
>>
>> Signed-off-by: Tomeu Vizoso
>> ---
>>
>> inc
Implement the .set_crc_source() callback and call the DP helpers
accordingly to start and stop CRC capture.
This is only done if this CRTC is currently using the eDP connector.
v3: Remove superfluous check on rockchip_crtc_state->output_type
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/
Add two simple functions that just take the drm_dp_aux from our struct
and calls the corresponding DP helpers with it.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 16
include/drm/bridge/analogix_dp.h | 3 +++
2 files
the CRCs afterwards, I will be glad
to hear about better alternatives.
With these patches, tests in IGT such as kms_pipe_crc_basic and
kms_plane do pass on RK3288.
Thanks,
Tomeu
Tomeu Vizoso (5):
drm/dp: add connector backpointer to drm_dp_aux
drm/bridge: analogix_dp: set connector to
This backpointer allows DP helpers to access the connector it's being
used for.
Signed-off-by: Tomeu Vizoso
---
include/drm/drm_dp_helper.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 55bbeb0ff594..4fa77b434594 1
pdate locking, as drm_crtc_add_crc_entry now takes the lock
v3: Don't call wake_up_interruptible directly, that's now done in
drm_crtc_add_crc_entry.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/drm_dp_helper.c | 118
include/drm/
Set the backpointer so that the DP helpers are able to access the
connector that the drm_dp_aux is associated with.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers
Add two simple functions that just take the drm_dp_aux from our struct
and calls the corresponding DP helpers with it.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 16
include/drm/bridge/analogix_dp.h | 3 +++
2 files
Implement the .set_crc_source() callback and call the DP helpers
accordingly to start and stop CRC capture.
This is only done if this CRTC is currently using the eDP connector.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 48 +
1
pdate locking, as drm_crtc_add_crc_entry now takes the lock
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/drm_dp_helper.c | 120
include/drm/drm_dp_helper.h | 7 +++
2 files changed, 127 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helpe
the CRCs afterwards, I will be glad
to hear about better alternatives.
Thanks,
Tomeu
Tomeu Vizoso (5):
drm/dp: add connector backpointer to drm_dp_aux
drm/bridge: analogix_dp: set connector to drm_dp_aux
drm/dp: add helpers for capture of frame CRCs
drm/bridge: analogix_dp: add helpers
Set the backpointer so that the DP helpers are able to access the
connector that the drm_dp_aux is associated with.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers
1 - 100 of 1365 matches
Mail list logo
