On Tue, 15 Sep 2020, Lyude Paul wrote:
> This reverts commit 0883ce8146ed6074c76399f4e70dbed788582e12. Originally
> these quirks were added because of the issues with using the eDP
> backlight interfaces on certain laptop panels, which made it impossible
> to properly probe for DPCD backlight supp
Am 16.09.20 um 08:56 schrieb Dave Airlie:
On Wed, 16 Sep 2020 at 16:44, Thomas Hellström (Intel)
wrote:
On 9/16/20 6:28 AM, Dave Airlie wrote:
On Wed, 16 Sep 2020 at 14:19, Dave Airlie wrote:
On Wed, 16 Sep 2020 at 00:12, Christian König
wrote:
Hi Dave,
I think we should just completely
On Wed, Sep 16, 2020 at 8:50 AM Thomas Hellström (Intel)
wrote:
>
>
> On 9/16/20 6:28 AM, Dave Airlie wrote:
> > On Wed, 16 Sep 2020 at 14:19, Dave Airlie wrote:
> >> On Wed, 16 Sep 2020 at 00:12, Christian König
> >> wrote:
> >>> Hi Dave,
> >>>
> >>> I think we should just completely nuke ttm_t
On Wed, 16 Sep 2020 at 16:58, Christian König wrote:
>
> Am 16.09.20 um 08:44 schrieb Thomas Hellström (Intel):
> >
> > On 9/16/20 6:28 AM, Dave Airlie wrote:
> >> On Wed, 16 Sep 2020 at 14:19, Dave Airlie wrote:
> >>> On Wed, 16 Sep 2020 at 00:12, Christian König
> >>> wrote:
> Hi Dave,
>
Greg, will you pick up this patch?
It seems that finding the real cause of [3] and actually fixing [3] will be
difficult.
Since I can't reproduce [3] locally, I will have to try flood of "#syz test"
requests
for debug printk() patches.
On 2020/09/11 7:57, Tetsuo Handa wrote:
> syzbot is reporti
On Wed 02 Sep 01:44 CDT 2020, Sumit Semwal wrote:
> Novatek nt36672a is a display driver IC that can drive DSI panel. It
> is also present in the Tianma video mode panel, which is a FHD+ panel
> with a resolution of 1080x2246 and 6.18 inches size. It is found in
> some of the Poco F1 phones.
>
>
On Wed 02 Sep 01:44 CDT 2020, Sumit Semwal wrote:
> Novatek NT36672a is a generic DSI IC that drives command and video mode
> panels. Add the driver for it.
>
> Right now adding support for some Poco F1 phones that have an LCD panel
> from Tianma connected with this IC, with a resolution of 1080x
On Tue, Sep 15, 2020 at 12:20 AM Jordan Crouse wrote:
>
> On Sat, Sep 12, 2020 at 06:25:58PM +0800, Zhenzhong Duan wrote:
> > It's allocating an array of a6xx_gpu_state_obj structure rathor than
> > its pointers.
> >
> > This patch fix it.
> >
> > Signed-off-by: Zhenzhong Duan
>
> LGTM but should
Use for_each_child_of_node() macro instead of open coding it.
Signed-off-by: Qinglang Miao
---
drivers/video/fbdev/nvidia/nv_of.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/nvidia/nv_of.c
b/drivers/video/fbdev/nvidia/nv_of.c
index 5f3e5179c..d20b87
Hi Sylwester,
On 9/9/20 17:47, Sylwester Nawrocki wrote:
> Hi Georgi,
>
> On 09.09.2020 11:07, Georgi Djakov wrote:
>> On 8/28/20 17:49, Sylwester Nawrocki wrote:
>>> On 30.07.2020 14:28, Sylwester Nawrocki wrote:
On 09.07.2020 23:04, Rob Herring wrote:
> On Thu, Jul 02, 2020 at 06:37:19
On Tue, Sep 15 2020 at 10:35, Linus Torvalds wrote:
> On Tue, Sep 15, 2020 at 1:39 AM Thomas Gleixner wrote:
>>
>> OTOH, having a working 'preemptible()' or maybe better named
>> 'can_schedule()' check makes tons of sense to make decisions about
>> allocation modes or other things.
>
> No. I think
On Tue, Sep 15, 2020 at 7:35 PM Linus Torvalds
wrote:
>
> On Tue, Sep 15, 2020 at 1:39 AM Thomas Gleixner wrote:
> >
> > OTOH, having a working 'preemptible()' or maybe better named
> > 'can_schedule()' check makes tons of sense to make decisions about
> > allocation modes or other things.
>
> No
Am 15.09.20 um 21:35 schrieb Ville Syrjälä:
On Tue, Sep 15, 2020 at 03:16:32PM -0400, Alex Deucher wrote:
I question the value of these warnings. Why even have a boolean type
if you are going to get warnings when you use them...
That said, applied to avoid getting these patches again and again
On 9/16/20 9:22 AM, Daniel Vetter wrote:
On Wed, Sep 16, 2020 at 8:50 AM Thomas Hellström (Intel)
wrote:
On 9/16/20 6:28 AM, Dave Airlie wrote:
On Wed, 16 Sep 2020 at 14:19, Dave Airlie wrote:
On Wed, 16 Sep 2020 at 00:12, Christian König
wrote:
Hi Dave,
I think we should just completel
On Mon, Sep 14, 2020 at 05:45:09PM +0100, Tvrtko Ursulin wrote:
>
> On 23/07/2020 18:21, Chris Wilson wrote:
> > Since the debugfs may peek into the GEM contexts as the corresponding
> > client/fd is being closed, we may try and follow a dangling pointer.
> > However, the context closure itself is
On Tue, 15 Sep 2020, Rodrigo Vivi wrote:
> On Tue, Sep 15, 2020 at 01:29:35PM -0400, Lyude Paul wrote:
>> Since we're about to start adding support for Intel's magic HDR
>> backlight interface over DPCD, we need to ensure we're properly
>> programming this field so that Intel specific sink service
On Wed, Sep 16, 2020 at 09:01:06AM +0900, Tetsuo Handa wrote:
> Greg, will you pick up this patch?
>
> It seems that finding the real cause of [3] and actually fixing [3] will be
> difficult.
> Since I can't reproduce [3] locally, I will have to try flood of "#syz test"
> requests
> for debug pr
On Wed, Sep 16, 2020 at 09:38:34AM +0200, Christian König wrote:
> Am 15.09.20 um 21:35 schrieb Ville Syrjälä:
> > On Tue, Sep 15, 2020 at 03:16:32PM -0400, Alex Deucher wrote:
> > > I question the value of these warnings. Why even have a boolean type
> > > if you are going to get warnings when yo
https://bugzilla.kernel.org/show_bug.cgi?id=206475
--- Comment #19 from Andrew Ammerlaan (andrewammerl...@riseup.net) ---
I'm on 5.8.8 at the moment and I haven't had this happen in a long time. I've
had some other freezes but I'm not sure they're GPU/graphics related. So I too
think this is fixed
On Fri, Sep 11, 2020 at 03:54:13PM +0200, Michael Tretter wrote:
> As the driver is not platform dependent anymore, move it to the drm
> bridge driver directory.
>
> Signed-off-by: Michael Tretter
So new drm_bridge drivers that still use the component stuff is a bit
uncool. We're trying to get a
On Wed, Sep 02, 2020 at 01:23:50PM +0200, Andrzej Hajda wrote:
>
> On 31.08.2020 14:50, Marek Szyprowski wrote:
> > Hi Krzysztof,
> >
> > On 29.08.2020 16:25, Krzysztof Kozlowski wrote:
> >> The USB-C connector bindings require port@0. Such port was already
> >> described in DTS but outside of th
Hi Tian
Am 14.09.20 um 09:07 schrieb Thomas Zimmermann:
> Hi
>
> Am 11.09.20 um 10:09 schrieb Tian Tao:
>> Handing the return value of drm_universal_plane_init to fix the following
>> W=1 kernel build warning(s):
>> vc4_plane.c: In function ‘vc4_plane_init’:
>> vc4_plane.c:1340:6: warning: variab
On Wed, Sep 16, 2020 at 09:01:06AM +0900, Tetsuo Handa wrote:
> Greg, will you pick up this patch?
>
> It seems that finding the real cause of [3] and actually fixing [3] will be
> difficult.
> Since I can't reproduce [3] locally, I will have to try flood of "#syz test"
> requests
> for debug pr
On 16/09/2020 08:42, Daniel Vetter wrote:
On Mon, Sep 14, 2020 at 05:45:09PM +0100, Tvrtko Ursulin wrote:
On 23/07/2020 18:21, Chris Wilson wrote:
Since the debugfs may peek into the GEM contexts as the corresponding
client/fd is being closed, we may try and follow a dangling pointer.
Howeve
Hi Robin,
On 16/09/2020 01:51, Robin Murphy wrote:
> According to a downstream commit I found in the Khadas vendor kernel,
> the GPU on G12b is wired up for ACE-lite, so (now that Panfrost knows
> how to handle this properly) we should describe it as such. Otherwise
> the mismatch leads to all man
These settings are used by an ASPEED BMC to determine when the host is
trying to drive the display over PCIe (vga_pw) and to switch the
output between PCIe and the internal graphics device (dac_mux).
The valid values for the dac mux are:
00: VGA mode (default, aka PCIe)
01: Graphics CRT (aka BM
On Wed, 16 Sep 2020 09:58:39 +0200, Daniel Vetter wrote:
> On Fri, Sep 11, 2020 at 03:54:13PM +0200, Michael Tretter wrote:
> > As the driver is not platform dependent anymore, move it to the drm
> > bridge driver directory.
> >
> > Signed-off-by: Michael Tretter
>
> So new drm_bridge drivers th
On Wed, Sep 16, 2020 at 10:58:33AM +0200, Michael Tretter wrote:
> On Wed, 16 Sep 2020 09:58:39 +0200, Daniel Vetter wrote:
> > On Fri, Sep 11, 2020 at 03:54:13PM +0200, Michael Tretter wrote:
> > > As the driver is not platform dependent anymore, move it to the drm
> > > bridge driver directory.
>
On Fri, Sep 11, 2020 at 03:57:22PM +0200, Philipp Zabel wrote:
> This allows to drop the custom drm_encoder_cleanup() actions.
>
> Signed-off-by: Philipp Zabel
> ---
> New in v3, example conversion of drm_simple_encoder_init() users.
>
> This and the following patches depend on the drm/imx conve
On Fri, Sep 11, 2020 at 10:59:23AM -0400, Rodrigo Siqueira wrote:
> Debug issues related to display can be a challenge due to the complexity
> around this topic and different source of information might help in this
> process. We already have support for tracepoints inside the display
> component,
On Sat, Sep 12, 2020 at 08:33:34PM +0200, Lukas Bulwahn wrote:
> Commit f15a3ea80391 ("MAINTAINERS: Add ASPEED BMC GFX DRM driver entry")
> does not mention that linux-asp...@lists.ozlabs.org is moderated for
> non-subscribers, but the other three entries for
> linux-asp...@lists.ozlabs.org do.
>
On Mon, Sep 14, 2020 at 09:22:32AM +0200, Thomas Zimmermann wrote:
> Since converting the ast driver to atomic modesetting, modesetting
> occationally locks up the graphics hardware and turns the display
> permanently dark. This happens once or twice per 10 mode switches.
> Investigation shows that
On Mon, Sep 14, 2020 at 01:25:20PM +0200, Thomas Zimmermann wrote:
> This patch updates dma_buf_vmap() and dma-buf's vmap callback to use
> struct dma_buf_map.
>
> The interfaces used to return a buffer address. This address now gets
> stored in an instance of the structure that is given as an add
On Mon, Sep 14, 2020 at 01:25:18PM +0200, Thomas Zimmermann wrote:
> Dma-buf provides vmap() and vunmap() for retrieving and releasing mappings
> of dma-buf memory in kernel address space. The functions operate with plain
> addresses and the assumption is that the memory can be accessed with load
>
On 2020-09-08 16:16, Stefan Agner wrote:
> The lcdif IP does not support a framebuffer pitch (stride) other than
> framebuffer width. Check for equality and reject the framebuffer
> otherwise.
>
> This prevents a distorted picture when using 640x800 and running the
> Mesa graphics stack. Mesa trie
On Mon, Sep 14, 2020 at 08:26:47PM +0200, Christian König wrote:
> Am 14.09.20 um 16:06 schrieb Jason Gunthorpe:
> > On Mon, Sep 14, 2020 at 03:30:47PM +0200, Christian König wrote:
> > > Am 14.09.20 um 15:29 schrieb Christian König:
> > > > Hi Andrew,
> > > >
> > > > I'm the new DMA-buf maintaine
On Wed, Sep 16, 2020 at 08:33:00AM +0200, Greg KH wrote:
> On Tue, Sep 15, 2020 at 02:46:07PM -0400, Alex Deucher wrote:
> > This change breaks tons of systems.
>
> Very vague :(
>
> This commit has also been merged for over a year, why the sudden
> problem now?
Unrelated rant, but one year is g
On Tue, Sep 15, 2020 at 04:59:41PM +0200, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in exynos. The only exception is gem_prime_mmap,
> which is non-
Am 16.09.20 um 11:53 schrieb Daniel Vetter:
On Mon, Sep 14, 2020 at 08:26:47PM +0200, Christian König wrote:
Am 14.09.20 um 16:06 schrieb Jason Gunthorpe:
On Mon, Sep 14, 2020 at 03:30:47PM +0200, Christian König wrote:
Am 14.09.20 um 15:29 schrieb Christian König:
Hi Andrew,
I'm the new DMA
Hi Daniel,
On Wed, 2020-09-16 at 11:08 +0200, Daniel Vetter wrote:
> On Fri, Sep 11, 2020 at 03:57:22PM +0200, Philipp Zabel wrote:
> > This allows to drop the custom drm_encoder_cleanup() actions.
> >
> > Signed-off-by: Philipp Zabel
> > ---
> > New in v3, example conversion of drm_simple_encod
Hi Laurent,
On 16/09/2020 00:38, Laurent Pinchart wrote:
> The reference to the VSP device acquired with of_find_device_by_node()
> in rcar_du_vsp_init() is never released. Fix it with a drmm action,
> which gets run both in the probe error path and in the remove path.
>
> Fixes: 6d62ef3ac30b ("d
On 2020-09-11 10:50, Daniel Vetter wrote:
> On Thu, Sep 10, 2020 at 11:24:23AM +0200, Stefan Agner wrote:
>> To improve readability and make it easier to add further optional checks
>> replace the boolean parameters with a single flag bitfield as parameter
>> of drm_atomic_helper_check_plane_state.
Hi
Am 16.09.20 um 12:03 schrieb Daniel Vetter:
> On Tue, Sep 15, 2020 at 04:59:41PM +0200, Thomas Zimmermann wrote:
>> GEM object functions deprecate several similar callback interfaces in
>> struct drm_driver. This patch replaces the per-driver callbacks with
>> per-instance callbacks in exynos.
On 2020-09-11 10:52, Daniel Vetter wrote:
> On Thu, Sep 10, 2020 at 11:24:24AM +0200, Stefan Agner wrote:
>> Add flag which checks that the framebuffer size matches the plane size
>> exactly. This is useful for display controller which can't handle
>> framebuffers other than the plane/CRTC size.
>>
Hi
Am 16.09.20 um 11:37 schrieb Daniel Vetter:
> On Mon, Sep 14, 2020 at 01:25:18PM +0200, Thomas Zimmermann wrote:
>> Dma-buf provides vmap() and vunmap() for retrieving and releasing mappings
>> of dma-buf memory in kernel address space. The functions operate with plain
>> addresses and the assu
On 2020-09-11 13:59, Ville Syrjälä wrote:
> On Thu, Sep 10, 2020 at 11:24:24AM +0200, Stefan Agner wrote:
>> Add flag which checks that the framebuffer size matches the plane size
>> exactly. This is useful for display controller which can't handle
>> framebuffers other than the plane/CRTC size.
>>
On Tue, Sep 15, 2020 at 04:59:40PM +0200, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in etnaviv. The only exception is gem_prime_mmap,
> which is non
On Wed, Sep 16, 2020 at 12:36:28PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 16.09.20 um 12:03 schrieb Daniel Vetter:
> > On Tue, Sep 15, 2020 at 04:59:41PM +0200, Thomas Zimmermann wrote:
> >> GEM object functions deprecate several similar callback interfaces in
> >> struct drm_driver. This pat
On Wed, Sep 16, 2020 at 12:31:44PM +0200, Stefan Agner wrote:
> On 2020-09-11 10:50, Daniel Vetter wrote:
> > On Thu, Sep 10, 2020 at 11:24:23AM +0200, Stefan Agner wrote:
> >> To improve readability and make it easier to add further optional checks
> >> replace the boolean parameters with a single
On Tue, Sep 15, 2020 at 04:59:42PM +0200, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in gma500.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by:
On Tue, Sep 15, 2020 at 04:59:44PM +0200, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in mediatek. The only exception is gem_prime_mmap,
> which is no
[SNIP]
But Jason pointed me to the right piece of code. See this comment in
in mmap_region():
/* ->mmap() can change vma->vm_file, but must guarantee that
* vma_link() below can deny write-access if VM_DENYWRITE is set
* and map writably if VM_SHARED is set. This usually means
On Tue, Sep 15, 2020 at 04:59:45PM +0200, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in msm. The only exception is gem_prime_mmap,
> which is non-tri
On Tue, Sep 15, 2020 at 04:59:46PM +0200, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in nouveau.
>
> Signed-off-by: Thomas Zimmermann
Hm ttm and g
On Tue, Sep 15, 2020 at 04:59:50PM +0200, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in rockchip. The only exception is gem_prime_mmap,
> which is no
On Tue, Sep 15, 2020 at 04:59:54PM +0200, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces virtgpu's per-driver PRIME export
> function with a per-object function.
>
> Signed-off-by: Thomas Zimmermann
Review
On Tue, Sep 15, 2020 at 04:59:58PM +0200, Thomas Zimmermann wrote:
> Several GEM and PRIME callbacks have been deprecated in favor of
> per-instance GEM object functions. Remove the callbacks as they are
> now unused. The only exception is .gem_prime_mmap, which is still
> in use by several drivers
On Wed, Sep 16, 2020 at 12:48:20PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 16.09.20 um 11:37 schrieb Daniel Vetter:
> > On Mon, Sep 14, 2020 at 01:25:18PM +0200, Thomas Zimmermann wrote:
> >> Dma-buf provides vmap() and vunmap() for retrieving and releasing mappings
> >> of dma-buf memory in k
On Wed, Sep 16, 2020 at 07:06:31PM +0900, Tetsuo Handa wrote:
> On 2020/09/16 17:26, Greg KH wrote:
> > On Wed, Sep 16, 2020 at 09:01:06AM +0900, Tetsuo Handa wrote:
> >> Greg, will you pick up this patch?
> >>
> >> It seems that finding the real cause of [3] and actually fixing [3] will
> >> be d
On 9/15/2020 7:17 PM, Ville Syrjälä wrote:
On Mon, Sep 14, 2020 at 11:26:26AM +0530, Karthik B S wrote:
Add enable/disable flip done functions and the flip done handler
function which handles the flip done interrupt.
Enable the flip done interrupt in IER.
Enable flip done function is called
On 9/15/2020 7:18 PM, Ville Syrjälä wrote:
On Mon, Sep 14, 2020 at 11:26:27AM +0530, Karthik B S wrote:
Set the Async Address Update Enable bit in plane ctl
when async flip is requested.
v2: -Move the Async flip enablement to individual patch (Paulo)
v3: -Rebased.
v4: -Add separate plane ho
On Wed, Sep 16, 2020 at 1:45 PM Christian König
wrote:
>
> [SNIP]
>
> But Jason pointed me to the right piece of code. See this comment in in
> mmap_region():
>
> /* ->mmap() can change vma->vm_file, but must guarantee that
> * vma_link() below can deny write-access if VM_DENYWRITE is set
> * and
On 9/15/2020 7:33 PM, Ville Syrjälä wrote:
On Mon, Sep 14, 2020 at 11:26:28AM +0530, Karthik B S wrote:
If flip is requested on any other plane, reject it.
Make sure there is no change in fbc, offset and framebuffer modifiers
when async flip is requested.
If any of these are modified, reject
On 9/15/2020 7:37 PM, Ville Syrjälä wrote:
On Mon, Sep 14, 2020 at 11:26:29AM +0530, Karthik B S wrote:
Since the flip done event will be sent in the flip_done_handler,
no need to add the event to the list and delay it for later.
v2: -Moved the async check above vblank_get as it
was cau
On 9/15/2020 7:40 PM, Ville Syrjälä wrote:
On Mon, Sep 14, 2020 at 11:26:30AM +0530, Karthik B S wrote:
This hook is added to avoid writing other plane registers in case of
async flips, so that we do not write the double buffered registers
during async surface address update.
v7: -Plane ctl n
On 9/15/2020 7:49 PM, Ville Syrjälä wrote:
On Mon, Sep 14, 2020 at 11:26:31AM +0530, Karthik B S wrote:
In Gen 9 and Gen 10 platforms, async address update enable bit is
double buffered. Due to this, during the transition from async flip
to sync flip we have to wait until this bit is updated b
Am 16.09.20 um 14:24 schrieb Daniel Vetter:
On Wed, Sep 16, 2020 at 12:48:20PM +0200, Thomas Zimmermann wrote:
Hi
Am 16.09.20 um 11:37 schrieb Daniel Vetter:
On Mon, Sep 14, 2020 at 01:25:18PM +0200, Thomas Zimmermann wrote:
Dma-buf provides vmap() and vunmap() for retrieving and releasing ma
On 9/15/2020 8:11 PM, Ville Syrjälä wrote:
On Mon, Sep 14, 2020 at 11:26:30AM +0530, Karthik B S wrote:
This hook is added to avoid writing other plane registers in case of
async flips, so that we do not write the double buffered registers
during async surface address update.
v7: -Plane ctl n
On Wed, Sep 16, 2020 at 2:32 AM Greg KH wrote:
>
> On Tue, Sep 15, 2020 at 02:46:07PM -0400, Alex Deucher wrote:
> > This change breaks tons of systems.
>
> Very vague :(
Screen corruption making the system unusable.
>
> This commit has also been merged for over a year, why the sudden
> problem
Hi
Am 16.09.20 um 14:59 schrieb Christian König:
> Am 16.09.20 um 14:24 schrieb Daniel Vetter:
>> On Wed, Sep 16, 2020 at 12:48:20PM +0200, Thomas Zimmermann wrote:
>>> Hi
>>>
>>> Am 16.09.20 um 11:37 schrieb Daniel Vetter:
On Mon, Sep 14, 2020 at 01:25:18PM +0200, Thomas Zimmermann wrote:
>>
This causes screen corruption when using the GPU which makes the
system unusable.
It was noticed by several people closer to when the change went in as
well. We looked into it a bit at the time but couldn't determine the
problem. It only seems to affect really old chips (like 15-20 years
old) wh
On Wed, Sep 16, 2020 at 3:51 AM Daniel Vetter wrote:
>
> On Wed, Sep 16, 2020 at 09:38:34AM +0200, Christian König wrote:
> > Am 15.09.20 um 21:35 schrieb Ville Syrjälä:
> > > On Tue, Sep 15, 2020 at 03:16:32PM -0400, Alex Deucher wrote:
> > > > I question the value of these warnings. Why even ha
On 9/16/20 2:59 PM, Christian König wrote:
Am 16.09.20 um 14:24 schrieb Daniel Vetter:
On Wed, Sep 16, 2020 at 12:48:20PM +0200, Thomas Zimmermann wrote:
Hi
Am 16.09.20 um 11:37 schrieb Daniel Vetter:
On Mon, Sep 14, 2020 at 01:25:18PM +0200, Thomas Zimmermann wrote:
Dma-buf provides vmap()
Am 16.09.20 um 15:36 schrieb Alex Deucher:
On Wed, Sep 16, 2020 at 3:51 AM Daniel Vetter wrote:
On Wed, Sep 16, 2020 at 09:38:34AM +0200, Christian König wrote:
Am 15.09.20 um 21:35 schrieb Ville Syrjälä:
On Tue, Sep 15, 2020 at 03:16:32PM -0400, Alex Deucher wrote:
I question the value of t
Am 16.09.20 um 16:07 schrieb Jason Gunthorpe:
On Wed, Sep 16, 2020 at 11:53:59AM +0200, Daniel Vetter wrote:
But within the driver, we generally need thousands of these, and that
tends to bring fd exhaustion problems with it. That's why all the private
buffer objects which aren't shared with ot
When we move from the SYSTEM domain to the TT domain
we still need to potentially change the caching state.
This is most likely the source of a bunch of problems with
AGP and USWC together with hibernation and swap.
Signed-off-by: Christian König
CC: sta...@vger.kernel.org
---
drivers/gpu/drm/t
Am 16.09.20 um 16:24 schrieb Christian König:
When we move from the SYSTEM domain to the TT domain
Typo in the subject, the order in the sentence here is the correct one.
This is an important bug fix I'm hunting for years. Please review.
Thanks,
Christian.
we still need to potentially chang
On 16/09/2020 01:51, Robin Murphy wrote:
> According to a downstream commit I found in the Khadas vendor kernel,
> the GPU on G12b is wired up for ACE-lite, so (now that Panfrost knows
> how to handle this properly) we should describe it as such. Otherwise
> the mismatch leads to all manner of fun
Hi Robin,
On 16/09/2020 01:51, Robin Murphy wrote:
> Hi all,
>
> I polished up my original proof-of-concept a little while back, but now
> that I've got my hands on my Juno again I've been able to actually test
> it to my satisfaction, so here are proper patches!
I tested on the Kkadas VIM3, and
The T820, G31 & G52 GPUs integrated by Amlogic in the respective GXM, G12A/SM1
& G12B
SoCs needs a quirk in the PWR registers at the GPU reset time.
This serie adds the necessary quirks for the Amlogic integrated GPUs only.
Changes since v1 at [1]:
- removed the BROKEN_SH quirk after [2] was sen
The T820, G31 & G52 GPUs integratewd by Amlogic in the respective GXM, G12A/SM1
& G12B
SoCs needs a quirk in the PWR registers after each reset.
This adds a callback in the device compatible struct of permit this.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/panfrost/panfrost_device.h | 3
The T820, G31 & G52 GPUs integratewd by Amlogic in the respective GXM, G12A/SM1
& G12B
SoCs needs a quirk in the PWR registers at the GPU reset time.
Since the Amlogic's integration of the GPU cores with the SoC is not
publicly documented we do not know what does these
values, but they permit hav
This adds the required GPU quirks, including the quirk in the PWR registers at
the GPU
reset time and the IOMMU quirk for shareability issues observed on G52 in
Amlogic G12B SoCs.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 11 +++
1 file changed, 11 ins
On Wed, Sep 16, 2020 at 4:14 PM Christian König
wrote:
>
> Am 16.09.20 um 16:07 schrieb Jason Gunthorpe:
> > On Wed, Sep 16, 2020 at 11:53:59AM +0200, Daniel Vetter wrote:
> >
> >> But within the driver, we generally need thousands of these, and that
> >> tends to bring fd exhaustion problems with
On 2020-09-16 5:12 a.m., Daniel Vetter wrote:
On Fri, Sep 11, 2020 at 10:59:23AM -0400, Rodrigo Siqueira wrote:
Debug issues related to display can be a challenge due to the complexity
around this topic and different source of information might help in this
process. We already have support for t
On Wed, Sep 16, 2020 at 09:37:17AM +0200, Daniel Vetter wrote:
> On Tue, Sep 15, 2020 at 7:35 PM Linus Torvalds
> wrote:
> >
> > On Tue, Sep 15, 2020 at 1:39 AM Thomas Gleixner wrote:
> > >
> > > OTOH, having a working 'preemptible()' or maybe better named
> > > 'can_schedule()' check makes tons
Am 16.09.20 um 17:24 schrieb Daniel Vetter:
On Wed, Sep 16, 2020 at 4:14 PM Christian König
wrote:
Am 16.09.20 um 16:07 schrieb Jason Gunthorpe:
On Wed, Sep 16, 2020 at 11:53:59AM +0200, Daniel Vetter wrote:
But within the driver, we generally need thousands of these, and that
tends to bring
On Wed, Sep 16, 2020 at 04:02:18PM +0200, Christian König wrote:
> Am 16.09.20 um 15:36 schrieb Alex Deucher:
> > On Wed, Sep 16, 2020 at 3:51 AM Daniel Vetter wrote:
> > > On Wed, Sep 16, 2020 at 09:38:34AM +0200, Christian König wrote:
> > > > Am 15.09.20 um 21:35 schrieb Ville Syrjälä:
> > > >
On Wed, 2020-09-16 at 10:43 +0300, Jani Nikula wrote:
> On Tue, 15 Sep 2020, Rodrigo Vivi wrote:
> > On Tue, Sep 15, 2020 at 01:29:35PM -0400, Lyude Paul wrote:
> > > Since we're about to start adding support for Intel's magic HDR
> > > backlight interface over DPCD, we need to ensure we're proper
Set the Async Address Update Enable bit in plane ctl
when async flip is requested.
v2: -Move the Async flip enablement to individual patch (Paulo)
v3: -Rebased.
v4: -Add separate plane hook for async flip case (Ville)
v5: -Rebased.
v6: -Move the plane hook to separate patch. (Paulo)
-Remov
Since the flip done event will be sent in the flip_done_handler,
no need to add the event to the list and delay it for later.
v2: -Moved the async check above vblank_get as it
was causing issues for PSR.
v3: -No need to wait for vblank to pass, as this wait was causing a
16ms delay once
This hook is added to avoid writing other plane registers in case of
async flips, so that we do not write the double buffered registers
during async surface address update.
v7: -Plane ctl needs bits from skl_plane_ctl_crtc as well. (Ville)
-Add a vfunc for skl_program_async_surface_address
Without async flip support in the kernel, fullscreen apps where game
resolution is equal to the screen resolution, must perform an extra blit
per frame prior to flipping.
Asynchronous page flips will also boost the FPS of Mesa benchmarks.
v2: -Few patches have been squashed and patches have been
In Gen 9 and Gen 10 platforms, async address update enable bit is
double buffered. Due to this, during the transition from async flip
to sync flip we have to wait until this bit is updated before continuing
with the normal commit for sync flip.
v9: -Rename skl_toggle_async_sync() to skl_disable_as
Add enable/disable flip done functions and the flip done handler
function which handles the flip done interrupt.
Enable the flip done interrupt in IER.
Enable flip done function is called before writing the
surface address register as the write to this register triggers
the flip done interrupt
F
If flip is requested on any other plane, reject it.
Make sure there is no change in fbc, offset and framebuffer modifiers
when async flip is requested.
If any of these are modified, reject async flip.
v2: -Replace DRM_ERROR (Paulo)
-Add check for changes in OFFSET, FBC, RC(Paulo)
v3: -Remov
Add the details of the implementation of asynchronous flips for i915.
v7: -Rebased.
v8: -Rebased.
v9: -Rebased.
Signed-off-by: Karthik B S
Signed-off-by: Vandita Kulkarni
---
Documentation/gpu/i915.rst | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/gpu/i915.rst b/Doc
Enable asynchronous flips in i915 for gen9+ platforms.
v2: -Async flip enablement should be a stand alone patch (Paulo)
v3: -Move the patch to the end of the series (Paulo)
v4: -Rebased.
v5: -Rebased.
v6: -Rebased.
v7: -Rebased.
v8: -Rebased.
v9: -Rebased.
Signed-off-by: Karthik B S
Signe
On 2020/09/16 17:26, Greg KH wrote:
> On Wed, Sep 16, 2020 at 09:01:06AM +0900, Tetsuo Handa wrote:
>> Greg, will you pick up this patch?
>>
>> It seems that finding the real cause of [3] and actually fixing [3] will be
>> difficult.
>> Since I can't reproduce [3] locally, I will have to try flood
On Tue, Sep 15, 2020 at 04:38:04PM -0700, Gurchetan Singh wrote:
> On Tue, Sep 15, 2020 at 8:27 AM Maxime Ripard wrote:
>
> > Hi,
> >
> > On Mon, Sep 14, 2020 at 04:39:41PM -0700, Gurchetan Singh wrote:
> > > Hi,
> > >
> > > This set of changes are required for zero-copy virtio-gpu.
> > >
> > > T
1 - 100 of 189 matches
Mail list logo
