Gerd Hoffmann (3):
drm/qxl: add mode/framebuffer check functions
drm/qxl: add qxl_add_mode helper function
drm/qxl: use kernel mode db
drivers/gpu/drm/qxl/qxl_display.c | 138 +++---
1 file changed, 70 insertions(+), 68 deletions(-)
--
2.9.3
Add all standard modes from the kernel's video mode data base.
Keep a few non-standard modes in the qxl mode list.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_display.c | 27 +++
1 file changed, 7 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/q
Add a helper function to add custom video modes to a connector.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_display.c | 84 +++
1 file changed, 49 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qx
Add a helper functions to check video modes. Also add a helper to check
framebuffer buffer objects, using the former for consistency. That way
we should not fail in qxl_primary_atomic_check() because video modes
which are too big will not be added to the mode list in the first place.
Signed-off-
On Tue, 15 Jan 2019, Andrew F. Davis wrote:
> On 1/14/19 11:13 AM, Liam Mark wrote:
> > On Fri, 11 Jan 2019, Andrew F. Davis wrote:
> >
> >> Buffers may not be mapped from the CPU so skip cache maintenance here.
> >> Accesses from the CPU to a cached heap should be bracketed with
> >> {begin,end}
https://bugzilla.kernel.org/show_bug.cgi?id=202263
Emre Işık (e.isi...@gmail.com) changed:
What|Removed |Added
CC||e.isi...@gmail.com
--- C
On Mi, 2019-01-09 at 18:09 +0100, Stefan Agner wrote:
> On 09.01.2019 15:13, Robert Chiras wrote:
> >
> > Currently, the enable of the axi clock return status is ignored,
> > causing
> > issues when the enable fails then we try to disable it. Therefore,
> > it is
> > better to check the return sta
On 1/16/19 8:30 AM, Gerd Hoffmann wrote:
>Hi,
>
>> +if (!dma_map_sg(dev->dev, xen_obj->sgt->sgl, xen_obj->sgt->nents,
>> +DMA_BIDIRECTIONAL)) {
>> +ret = -EFAULT;
>> +goto fail_free_sgt;
>> +}
> Hmm, so it seems the arm guys could not come up
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c: In function 'vmw_hw_surface_destroy':
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c:335:22: warning:
variable 'srf' set but not used [-Wunused-but-set-variable]
It never used since commit 543831cfc976 ï¼"drm/vmwgf
On Fri 2019-01-11 15:04:32, Sergey Senozhatsky wrote:
> On (01/10/19 14:03), Prarit Bhargava wrote:
> > +++ b/drivers/video/fbdev/core/fbcon.c
> > @@ -649,11 +649,14 @@ static void fbcon_prepare_logo(struct vc_data *vc,
> > struct fb_info *info,
> > kfree(save);
> > }
> >
> > +
On Tue, Jan 15, 2019 at 02:17:26PM +, Thomas Hellstrom wrote:
> Hi, Christoph,
>
> On Mon, 2019-01-14 at 10:48 +0100, Christoph Hellwig wrote:
> > On Thu, Jan 10, 2019 at 04:42:18PM -0700, Jason Gunthorpe wrote:
> > > > Changes since the RFC:
> > > > - Rework vmwgfx too [CH]
> > > > - Use a di
On 1/16/19 8:36 AM, Christoph Hellwig wrote:
> On Wed, Jan 16, 2019 at 07:30:02AM +0100, Gerd Hoffmann wrote:
>>Hi,
>>
>>> + if (!dma_map_sg(dev->dev, xen_obj->sgt->sgl, xen_obj->sgt->nents,
>>> + DMA_BIDIRECTIONAL)) {
>>> + ret = -EFAULT;
>>> + goto fail
On Tue, Jan 15, 2019 at 10:49:51AM +0100, Maxime Ripard wrote:
> Hi,
>
> (Sending those kind of bug reports to linux-sunxi doesn't really work,
> you should Cc at least the ML involved in the development of the
> driver at fault).
OK, sorry for that.
>
> On Mon, Jan 14, 2019 at 01:29:34PM +
Hi Will,
Will Deacon writes:
> [+ BenH and MPE]
>
> On Mon, Jan 14, 2019 at 07:21:08PM +, Koenig, Christian wrote:
>> Am 14.01.19 um 20:13 schrieb Will Deacon:
...
>
>> > The Arm architecture (and others including Power afaiu) doesn't
>> > guarantee coherency when memory is accessed using mis
On Wed, 16 Jan 2019 at 08:36, Koenig, Christian
wrote:
>
> Am 16.01.19 um 01:33 schrieb Benjamin Herrenschmidt:
> > On Tue, 2019-01-15 at 22:31 +1100, Michael Ellerman wrote:
> As far as I know Power doesn't really supports un-cached memory at all,
> except for a very very old and odd co
https://bugs.freedesktop.org/show_bug.cgi?id=102909
Michel Dänzer changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|NEW
>
> Add a helper functions to check video modes. Also add a helper to check
> framebuffer buffer objects, using the former for consistency. That way
> we should not fail in qxl_primary_atomic_check() because video modes
> which are too big will not be added to the mode list in the first place.
>
On Tue, Jan 15, 2019 at 4:57 PM Maxime Ripard wrote:
>
> Hi Daniel, Dave,
>
> Here is the drm-misc-next PR for this week.
>
> Thanks!
> Maxime
>
> drm-misc-next-2019-01-15:
> drm-misc-next for 5.1:
>
> UAPI Changes:
>
> Cross-subsystem Changes:
>
> Core Changes:
> - Reorganisation of drm_device a
The fbdev subsystem is closed for new drivers, those need to become
drm ones (which generally results in smaller drivers nowadays, with
the massive amounts of shared infrastructure and helper libraries drm
has).
Although given the lack of progress since 2010, maybe time to ditch it
from staging ou
On Tue, Jan 15, 2019 at 4:32 PM Greg Kroah-Hartman
wrote:
>
> On Tue, Jan 15, 2019 at 04:15:49PM +0100, Daniel Vetter wrote:
> > On Tue, Jan 15, 2019 at 02:45:53PM +0100, Greg Kroah-Hartman wrote:
> > > On Tue, Jan 15, 2019 at 01:12:28PM +0100, Daniel Vetter wrote:
> > > > On Tue, Jan 15, 2019 at
https://bugs.freedesktop.org/show_bug.cgi?id=109375
Bug ID: 109375
Summary: Regression: dark notebook display (no backlight) after
resume
Product: DRI
Version: XOrg git
Hardware: x86-64 (AMD64)
OS: Linux (Al
On Wed, Jan 16, 2019 at 07:28:13AM +, Koenig, Christian wrote:
> Am 16.01.19 um 08:09 schrieb Thomas Hellstrom:
> > On Tue, 2019-01-15 at 21:58 +0100, h...@lst.de wrote:
> >> On Tue, Jan 15, 2019 at 07:13:11PM +, Koenig, Christian wrote:
> >>> Thomas is correct that the interface you propos
On Tue, Jan 15, 2019 at 10:48:45PM +0100, Sam Ravnborg wrote:
> 0-DAY reported the following bug:
>
> tree: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
> head: 21376e2c3c5bad5e87ba700c055c8a8235c2bfd5
> commit: e9eafcb589213395232084a2378e2e90f67feb29 [1/2] drm: move
> drm_can_sl
https://bugs.freedesktop.org/show_bug.cgi?id=109375
--- Comment #1 from Rafał Miłecki ---
For a comparison: behavior with the commit 262485a50fd4~1 (before the
regression):
Before suspend:
> cat /sys/class/backlight/amdgpu_bl0/{actual_brightness,brightness}
255
255
After resume:
> cat /sys/clas
On Wed, Jan 16, 2019 at 09:47:17AM +0200, Jani Nikula wrote:
> On Tue, 15 Jan 2019, Lyude Paul wrote:
> > Something that I completely missed when implementing the new MST VCPI
> > atomic helpers is that with those helpers, there's technically a chance
> > of us having to grab additional modeset lo
On Tue, Jan 15, 2019 at 11:27:54AM +0100, Daniel Vetter wrote:
> It's a debug hack flag useful to work around driver bugs. That's not a
> good idea for a new driver. Especially for a new drm driver.
>
> Aside: the fbdev support should probably be converted over to the new
> generic fbdev support.
Am 15.01.19 um 22:25 schrieb Jason Gunthorpe:
On Tue, Jan 15, 2019 at 02:17:26PM +, Thomas Hellstrom wrote:
Hi, Christoph,
On Mon, 2019-01-14 at 10:48 +0100, Christoph Hellwig wrote:
On Thu, Jan 10, 2019 at 04:42:18PM -0700, Jason Gunthorpe wrote:
Changes since the RFC:
- Rework vmwgfx to
> > +static int qxl_check_mode(struct qxl_device *qdev,
> > + unsigned int width,
> > + unsigned int height)
> > +{
> > + if (width * height * 4 > qdev->vram_size)
>
> Is someone checking for integer overflows already?
Need to have a look. This is just .
https://bugzilla.kernel.org/show_bug.cgi?id=202263
Emre Işık (e.isi...@gmail.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolut
On 2019/01/14, Daniel Vetter wrote:
> On Mon, Jan 14, 2019 at 08:44:10AM +, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > Currently we fail to free and detach the drm_file when drm_setup() fails.
> > Use the drm_close_helper to do address that.
> >
> > Signed-off-by: Emil Velikov
> > -
On Wed, Jan 16, 2019 at 11:40:41AM +, Emil Velikov wrote:
> On 2019/01/14, Daniel Vetter wrote:
> > On Mon, Jan 14, 2019 at 08:44:10AM +, Emil Velikov wrote:
> > > From: Emil Velikov
> > >
> > > Currently we fail to free and detach the drm_file when drm_setup() fails.
> > > Use the drm_cl
On Monday, January 7, 2019 3:21:49 PM CET Rafael J. Wysocki wrote:
> On Mon, Jan 7, 2019 at 3:04 PM Vincent Guittot
> wrote:
> >
> > Hi Tvrtko,
> >
> > On Mon, 31 Dec 2018 at 13:32, Tvrtko Ursulin
> > wrote:
> > >
> > >
> > > On 21/12/2018 13:26, Vincent Guittot wrote:
> > > > On Fri, 21 Dec 2018
On 2019/01/14, Daniel Vetter wrote:
> On Mon, Jan 14, 2019 at 08:54:08AM +, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > There are cases (in mesa and applications) where one would open the
> > primary node without properly authenticating the client.
> >
> > Sometimes we don't check if
On Wed, Jan 16, 2019 at 12:28:00PM +0100, Gerd Hoffmann wrote:
> > > +static int qxl_check_mode(struct qxl_device *qdev,
> > > + unsigned int width,
> > > + unsigned int height)
> > > +{
> > > + if (width * height * 4 > qdev->vram_size)
> >
> > Is someone checki
https://bugs.freedesktop.org/show_bug.cgi?id=108940
H.Habighorst changed:
What|Removed |Added
CC||h.habigho...@protonmail.com
--- Comment
https://bugs.freedesktop.org/show_bug.cgi?id=108940
--- Comment #14 from H.Habighorst ---
Can confirm.
But I'm a bit worried - there is a part before the "core_link_enable_stream"
that seems wrong to me in initializing the device, which seems to occure in all
dmesg outputs.
I've attached line
Hi, I am using drm_simple_kms_helper and writing a new driver.
The code is here:
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git/log/?h=ux500-mcde
It's starting to look acceptable, but I just don't wanna post the driver
until I get a clean probe.
This is using a comman
So, I guess this is to do w/ the magic of merge commits, but it looks
like the hunk changing the crtc_ww_class got lost:
~/src/linux master git show --pretty=short
08295b3b5beec9aac0f7a9db86f0fc3792039da3
drivers/gpu/drm/drm_modeset_lock.c
commit 08295b3b5beec9aac0f7a9db86f0fc3792039da3
Au
https://bugs.freedesktop.org/show_bug.cgi?id=109135
--- Comment #20 from i...@yahoo.com ---
(In reply to Alex Deucher from comment #12)
> (In reply to iive from comment #10)
[...]
> > Most of the new changes are done before RC1 and it is quite common that
> > there are major breakages there, in sy
On Fri, 11 Jan 2019 14:29:28 +
Peter Rosin wrote:
> On 2019-01-10 20:25, Boris Brezillon wrote:
> > On Thu, 10 Jan 2019 18:51:21 +
> > Peter Rosin wrote:
> >
> >> On 2019-01-10 18:29, Boris Brezillon wrote:
> >>> On Thu, 10 Jan 2019 15:10:48 +
> >>> Peter Rosin wrote:
> >>>
https://bugs.freedesktop.org/show_bug.cgi?id=109370
MIka R changed:
What|Removed |Added
Severity|minor |normal
Priority|low
https://bugs.freedesktop.org/show_bug.cgi?id=109375
--- Comment #2 from Leo Li ---
Created attachment 143141
--> https://bugs.freedesktop.org/attachment.cgi?id=143141&action=edit
drm/amd/display: Detach backlight from stream
Hi Rafał,
Please give the attached patch a shot. It's in our staging
Hi :-)
On Tue, Jan 15, 2019 at 12:40:16PM -0600, Andrew F. Davis wrote:
> On 1/15/19 12:38 PM, Andrew F. Davis wrote:
> > On 1/15/19 11:45 AM, Liam Mark wrote:
> >> On Tue, 15 Jan 2019, Andrew F. Davis wrote:
> >>
> >>> On 1/14/19 11:13 AM, Liam Mark wrote:
> On Fri, 11 Jan 2019, Andrew F. Da
The Vivante GPU cores are found in many different SoCs and the driver
does not depend on anything architecture specific, so just drop the
architecture restriction.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/et
Hi Andrew,
On Fri, Jan 11, 2019 at 12:05:20PM -0600, Andrew F. Davis wrote:
> The heap name can be used for debugging but otherwise does not seem
> to be required and no other part of the code will fail if left NULL
> except here. We can make it required and check for it at some point,
> for now l
Am Montag, den 14.01.2019, 13:49 +0300 schrieb Dan Carpenter:
> The etnaviv_gem_get_pages() never returns NULL. It returns error
> pointers on error.
>
> Fixes: a8c21a5451d8 ("drm/etnaviv: add initial etnaviv DRM driver")
> Signed-off-by: Dan Carpenter
Thanks, applied to etnaviv/next.
> ---
>
On Wed, Jan 16, 2019 at 11:04:40AM +0100, Daniel Vetter wrote:
> The fbdev subsystem is closed for new drivers, those need to become
> drm ones (which generally results in smaller drivers nowadays, with
> the massive amounts of shared infrastructure and helper libraries drm
> has).
>
> Although gi
https://bugs.freedesktop.org/show_bug.cgi?id=109375
--- Comment #3 from Rafał Miłecki ---
It didn't apply cleanly on top of 5.0.0-rc2 (a trivial conflict in the
dc_link.c.rej). After fixing that, compiling & testing I can confirm is solves
the problem for me! Thanks!
Before suspend:
> cat /sys/c
On 01/16/2019 02:46 AM, Christian König wrote:
Am 15.01.19 um 23:01 schrieb Grodzovsky, Andrey:
On 01/11/2019 05:03 PM, Andrey Grodzovsky wrote:
On 01/11/2019 02:11 PM, Koenig, Christian wrote:
Am 11.01.19 um 16:37 schrieb Grodzovsky, Andrey:
On 01/11/2019 04:42 AM, Koenig, Christian wro
Am 16.01.19 um 16:45 schrieb Grodzovsky, Andrey:
On 01/16/2019 02:46 AM, Christian König wrote:
Am 15.01.19 um 23:01 schrieb Grodzovsky, Andrey:
On 01/11/2019 05:03 PM, Andrey Grodzovsky wrote:
On 01/11/2019 02:11 PM, Koenig, Christian wrote:
Am 11.01.19 um 16:37 schrieb Grodzovsky, Andrey:
https://bugzilla.kernel.org/show_bug.cgi?id=202263
--- Comment #8 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to Emre Işık from comment #7)
> Thanks for the patch.
> Do you gonna commit this patch to the official kernel?
> Maybe others have the same error like me.
Yes, I'll make sure
On 1/15/19 12:58 PM, Laura Abbott wrote:
> On 1/15/19 9:47 AM, Andrew F. Davis wrote:
>> On 1/14/19 8:39 PM, Laura Abbott wrote:
>>> On 1/11/19 10:05 AM, Andrew F. Davis wrote:
Hello all,
This is a set of (hopefully) non-controversial cleanups for the ION
framework and current s
On Wed, Jan 16, 2019 at 07:28:13AM +, Koenig, Christian wrote:
> To summarize once more: We have an array of struct pages and want to
> coherently map that to a device.
And the answer to that is very simple: you can't. What is so hard
to understand about? If you want to map arbitrary memory
On Tue, Jan 15, 2019 at 02:25:01PM -0700, Jason Gunthorpe wrote:
> RDMA needs something similar as well, in this case drivers take a
> struct page * from get_user_pages() and need to have the DMA map fail
> if the platform can't DMA map in a way that does not require any
> additional DMA API calls
https://bugzilla.kernel.org/show_bug.cgi?id=202263
--- Comment #9 from Emre Işık (e.isi...@gmail.com) ---
Thank you, too, for writing the patch so quickly.
It has been a great pleasure to cooperate with you, Alex Deucher.
It's a great thing helping other people's.
Which u a nice day!
Best regar
On 1/15/19 1:05 PM, Laura Abbott wrote:
> On 1/15/19 10:38 AM, Andrew F. Davis wrote:
>> On 1/15/19 11:45 AM, Liam Mark wrote:
>>> On Tue, 15 Jan 2019, Andrew F. Davis wrote:
>>>
On 1/14/19 11:13 AM, Liam Mark wrote:
> On Fri, 11 Jan 2019, Andrew F. Davis wrote:
>
>> Buffers may no
On 1/15/19 1:11 PM, Laura Abbott wrote:
> On 1/15/19 10:43 AM, Laura Abbott wrote:
>> On 1/15/19 7:58 AM, Andrew F. Davis wrote:
>>> On 1/14/19 8:32 PM, Laura Abbott wrote:
On 1/11/19 10:05 AM, Andrew F. Davis wrote:
> The "unmapped" heap is very similar to the carveout heap except
> t
On Mon, Jan 14, 2019 at 07:31:57PM +0300, Eugeniy Paltsev wrote:
> ARC HSDK SoC has Vivante GPU IP so allow build etnaviv for ARC.
>
> Signed-off-by: Eugeniy Paltsev
> ---
> drivers/gpu/drm/etnaviv/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/
Am Mittwoch, den 16.01.2019, 08:21 -0800 schrieb Christoph Hellwig:
> On Mon, Jan 14, 2019 at 07:31:57PM +0300, Eugeniy Paltsev wrote:
> > ARC HSDK SoC has Vivante GPU IP so allow build etnaviv for ARC.
> >
> > Signed-off-by: Eugeniy Paltsev
> > ---
> > drivers/gpu/drm/etnaviv/Kconfig | 2 +-
> >
On Wed, 16 Jan 2019 at 16:06, h...@lst.de wrote:
> On Wed, Jan 16, 2019 at 07:28:13AM +, Koenig, Christian wrote:
> > To summarize once more: We have an array of struct pages and want to
> > coherently map that to a device.
>
> And the answer to that is very simple: you can't. What is so hard
On Wed, Jan 16, 2019 at 04:27:58PM +0100, Lucas Stach wrote:
> The Vivante GPU cores are found in many different SoCs and the driver
> does not depend on anything architecture specific, so just drop the
> architecture restriction.
>
> Signed-off-by: Lucas Stach
For good measure I throwed this af
https://bugs.freedesktop.org/show_bug.cgi?id=109135
--- Comment #21 from Alex Deucher ---
(In reply to iive from comment #20)
> Anyway, bisect was done successfully.
>
> I just still kind of don't understand why it landed on that commit.
> It doesn't look like this is the commit that changes the
On 01/07/2019 11:35 AM, Peter Rosin wrote:
> On 2019-01-07 10:11, Geert Uytterhoeven wrote:
>> Hi Peter,
>>
>> On Mon, Jan 7, 2019 at 10:03 AM Peter Rosin wrote:
>>> On 2019-01-07 09:59, Peter Rosin wrote:
On 2019-01-07 09:40, Geert Uytterhoeven wrote:
> On Mon, Jan 7, 2019 at 9:26 AM Pe
Hi,
On Wed, 2019-01-16 at 09:24 -0500, Rob Clark wrote:
> So, I guess this is to do w/ the magic of merge commits, but it looks
> like the hunk changing the crtc_ww_class got lost:
So what happened here is that this commit changed it to
DEFINE_WD_CLASS
and the following commit changed it back ag
On 1/16/19 9:19 AM, Brian Starkey wrote:
> Hi :-)
>
> On Tue, Jan 15, 2019 at 12:40:16PM -0600, Andrew F. Davis wrote:
>> On 1/15/19 12:38 PM, Andrew F. Davis wrote:
>>> On 1/15/19 11:45 AM, Liam Mark wrote:
On Tue, 15 Jan 2019, Andrew F. Davis wrote:
> On 1/14/19 11:13 AM, Liam Mark
On 1/16/19 9:28 AM, Brian Starkey wrote:
> Hi Andrew,
>
> On Fri, Jan 11, 2019 at 12:05:20PM -0600, Andrew F. Davis wrote:
>> The heap name can be used for debugging but otherwise does not seem
>> to be required and no other part of the code will fail if left NULL
>> except here. We can make it re
On 01/16/2019 11:02 AM, Koenig, Christian wrote:
Am 16.01.19 um 16:45 schrieb Grodzovsky, Andrey:
On 01/16/2019 02:46 AM, Christian König wrote:
Am 15.01.19 um 23:01 schrieb Grodzovsky, Andrey:
On 01/11/2019 05:03 PM, Andrey Grodzovsky wrote:
On 01/11/2019 02:11 PM, Koenig, Christian wrote:
On Mon, Jan 14, 2019 at 03:16:54PM -0700, Jason Gunthorpe wrote:
> On Sat, Jan 12, 2019 at 01:03:05PM -0600, Shiraz Saleem wrote:
> > On Sat, Jan 12, 2019 at 06:37:58PM +, Jason Gunthorpe wrote:
> > > On Sat, Jan 12, 2019 at 12:27:05PM -0600, Shiraz Saleem wrote:
> > > > On Fri, Jan 04, 2019 at
https://bugs.freedesktop.org/show_bug.cgi?id=109135
--- Comment #22 from i...@yahoo.com ---
(In reply to Alex Deucher from comment #21)
> (In reply to iive from comment #20)
> > Anyway, bisect was done successfully.
> >
> > I just still kind of don't understand why it landed on that commit.
> > I
Add the nodes to describe the Adreno GPU and GMU devices for sdm845.
Signed-off-by: Jordan Crouse
Reviewed-by: Douglas Anderson
Tested-by: Douglas Anderson
---
This has the following dependencies:
[v11,1/9] dt-bindings: opp: Introduce opp-level bindings
https://patchwork.kernel.org/patch/10755
Hi Daniel.
> v5: Actually try to sort them, and while at it, sort all the ones I
> touch.
Applied this variant on top of drm-misc and did a build test.
Looked good for ia64, x86 and alpha.
Took a closer look at the changes to atmel_hlcd - and they looked OK.
But I noticed that atmel_hlcdc uses
https://bugzilla.kernel.org/show_bug.cgi?id=202261
--- Comment #5 from Johannes Hirte (johannes.hi...@datenkhaos.de) ---
With the change from
https://lists.linuxfoundation.org/pipermail/iommu/2019-January/032651.html see
bug seems to be fixed. I've not encountered any Oops since testing with this
https://bugs.freedesktop.org/show_bug.cgi?id=106175
--- Comment #103 from Hans D ---
With the latest xf86 DDX driver 3d works better in amdgpu.dc=0, but still lags,
even though a built-in counter is showing high fps. Does amdgpu.dc=1 improve
3d performance that much?
--
You are receiving this
Compared to the RFC[1] no changes to the patch itself, but igt moved
forward a lot:
- gitlab CI builds with: reduced configs/libraries, arm cross build
and a sysroot build (should address all the build/cross platform
concerns raised in the RFC discussions).
- tests reorganized into subdirecto
On Mon, 7 Jan 2019 17:07:09 +
Brian Starkey wrote:
> On Mon, Jan 07, 2019 at 07:57:54AM -0800, Keith Packard wrote:
> > Daniel Vetter writes:
> >
> > > Best to pull in some other compositor people and get them to agree. From a
> > > kernel pov I'm fine with whatever userspace preferes.
On Tue, Jan 15, 2019 at 11:47 PM Rafael J. Wysocki wrote:
>
> [CC Greg]
>
> On Tuesday, January 15, 2019 1:04:02 AM CET Rafael J. Wysocki wrote:
> > [CC Lukas and linux-pm]
> >
> > On Mon, Jan 14, 2019 at 1:32 PM Rafael J. Wysocki wrote:
> > >
> > > On Fri, Jan 11, 2019 at 3:49 PM Russell King -
The patch ("OPP: Add support for parsing the 'opp-level' property")
adds an API enabling a cleaner way to read the opp-level. Let's use
the new API.
Signed-off-by: Douglas Anderson
Reviewed-by: Jordan Crouse
---
Obviously this can't land until we have a tree that contains the patch
adding the A
The bindings for Qualcomm opp levels changed after being Acked but
before landing. Thus the code in the GPU driver that was relying on
the old bindings is now broken.
Let's change the code to match the new bindings by adjusting the old
string 'qcom,level' to the new string 'opp-level'. See the p
https://bugs.freedesktop.org/show_bug.cgi?id=109135
--- Comment #23 from Alex Deucher ---
(In reply to iive from comment #22)
>
> It is code refactoring. It doesn't remove, add or modify any functionality.
> It just changes how some functions are called. (1 function pointer and
> switch/case, in
On Tue, Jan 8, 2019 at 5:47 PM Otto Sabart wrote:
>
> The primecell.txt and cpus.txt files were converted into YAML. This
> patch updates old references with new ones.
>
> Fixes: d3c207eeb905 ("dt-bindings: arm: Convert primecell binding to
> json-schema")
> Fixes: 672951cbd1b7 ("dt-bindings: arm
On Wed, Jan 16, 2019 at 08:35:26PM +0200, Pekka Paalanen wrote:
> On Mon, 7 Jan 2019 17:07:09 +
> Brian Starkey wrote:
>
> > On Mon, Jan 07, 2019 at 07:57:54AM -0800, Keith Packard wrote:
> > > Daniel Vetter writes:
> > >
> > > > Best to pull in some other compositor people and get them t
https://bugs.freedesktop.org/show_bug.cgi?id=108711
--- Comment #1 from mittorn ---
Re-uploaded traces here
http://mittorn.the-swank.pp.ua/xash64.1.trace.xz
http://mittorn.the-swank.pp.ua/xash64.trace.xz
--
You are receiving this mail because:
You are the assignee for the bug.__
Hi,
On Wed, Jan 16, 2019 at 10:03 AM Jordan Crouse wrote:
>
> Add the nodes to describe the Adreno GPU and GMU devices for sdm845.
>
> Signed-off-by: Jordan Crouse
> Reviewed-by: Douglas Anderson
> Tested-by: Douglas Anderson
> ---
> This has the following dependencies:
>
> [v11,1/9] dt-bindin
On Wed, Jan 16, 2019 at 3:06 PM Linus Walleij wrote:
>
> Hi, I am using drm_simple_kms_helper and writing a new driver.
>
> The code is here:
> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git/log/?h=ux500-mcde
> It's starting to look acceptable, but I just don't wanna p
On Sun, Jan 13, 2019 at 01:07:41AM +0530, Jagan Teki wrote:
> > > > > > Again, I cannot help you without the datasheet for the panels you're
> > > > > > trying to submit.
> > > > >
> > > > > The panel bound with Sitronix ST7701 IC
> > > > > http://www.startek-lcd.com/res/starteklcd/pdres/201705/201
On Sun, Jan 13, 2019 at 09:47:44AM +0100, Julia Lawall wrote:
> The device node iterators perform an of_node_get on each
> iteration, so a jump out of the loop requires an of_node_put.
>
> Remote and port also have augmented reference counts, so drop them
> on each iteration and at the end of the
Hi Priit,
On Wed, Jan 16, 2019 at 07:58:54AM +, Priit Laes wrote:
> > On Mon, Jan 14, 2019 at 01:29:34PM +, Priit Laes wrote:
> > > I have a somewhat curious case with one HDMI/DVI screen that fails
> > > to initialize properly every 6-7 boots. The display itself is also
> > > somewhat fla
On Wed, 2019-01-16 at 20:35 +0200, Pekka Paalanen wrote:
> I would agree with an effort to establish a userspace EDID parsing
> library in any case. As mentioned above, there will probably be too
> much to expose via kernel UABI, or it will become just another
> encoded format that again should ha
On Wed, Jan 16, 2019 at 10:46:21AM -0800, Douglas Anderson wrote:
> The bindings for Qualcomm opp levels changed after being Acked but
> before landing. Thus the code in the GPU driver that was relying on
> the old bindings is now broken.
>
> Let's change the code to match the new bindings by adj
Hi Daniel, Dave,
Here is a re-run of the previous drm-misc-next as asked by Daniel.
Thanks!
Maxime
drm-misc-next-2019-01-16:
drm-misc-next for 5.1:
UAPI Changes:
- New fourcc identifier for ARM Framebuffer Compression v1.3
Cross-subsystem Changes:
Core Changes:
- Reorganisation of drm_devic
Adam Jackson writes:
> If the kernel wanted to expose its quirks db somehow the library could
> certainly be taught to use it. However there are likely to be quirks
> relevant only to userspace (see below), making the kernel carry that
> doesn't make a ton of sense.
We do expose some of the quir
Two not terribly important fixes, and one actually important fix. Should
be pretty easy to review :)
Lyude Paul (3):
drm/dp_mst: Remove lock check in drm_atomic_get_mst_topology_state()
drm/dp_mst: Fix potential topology ref leak in
drm_dp_atomic_find_vcpi_slots()
drm/dp_mst: Fix topolog
Another drive-by fix. If slots < 0, or drm_dp_init_vcpi() fails, we'll
end up returning from the function without dropping the topology ref
that we grabbed at the very start. This would result in an MST hub
and/or it's ports staying around even after the MST topology has been
removed from the syste
Since modesetting locks by default were added to private objects in:
commit b962a12050a3 ("drm/atomic: integrate modeset lock with private
objects")
This means that the atomic state of a drm_dp_mst_topology_mgr is now
protected by drm_dp_mst_topology_mgr->base.lock as opposed to the main
connecti
This is a very minute issue I introduced that I just noticed when
scrolling through drm_dp_mst_topology.c: if a driver uses
drm_dp_atomic_find_vcpi_slots() incorrectly, we'll forget to release the
topology reference we grabbed on port.
So, fix this by jumping to 'out' instead of returning -EINVAL
https://bugs.freedesktop.org/show_bug.cgi?id=109331
andrew.m.mcma...@gmail.com changed:
What|Removed |Added
Blocks||77449
Version|18
https://bugs.freedesktop.org/show_bug.cgi?id=108917
--- Comment #7 from Hans D ---
Can confirm that enabling redshift causes occasional stutters every 2-4 seconds
with amdgpu.dc=1 with linux 5.0rc2. Without redshift everything (scrolling in
browser, video playback)is buttery smooth. With amdgpu.
On Mon, 14 Jan 2019 09:43:28 +, wrote:
> From: Cristian Birsan
>
> PDA 91-00156-A0 5.0 is a 5.0" WVGA TFT LCD panel.
> This panel with backlight is found in PDA 5" LCD screen (TM5000 series or
> AC320005-5).
> Adding Device Tree bindings for this panel.
>
> Signed-off-by: Cristian Birsan
>
Commit 24937c540917 ("dt-bindings: drm/msm/a6xx: Document GMU and update
GPU bindings") mistakenly omitted the GMU bindings as seen in [1].
Return them to their rightful place.
[1] https://patchwork.freedesktop.org/patch/268679/
Signed-off-by: Jordan Crouse
Reviewed-by: Rob Herring
---
.../de
[I am experimenting with checking the Fixes tags in commits in linux-next.
Please let me know if you think I am being too strict.]
Hi all,
Commit
94520db52fc0 ("drm: fix alpha build after drm_util.h change")
has a malformed Fixes tag:
Fixes: 733748ac37b45 ("drm: move drm_can_sleep() to drm
1 - 100 of 124 matches
Mail list logo