Daniel Vetter
>>
>> Now 11:01pm and "gnome shell stuck warning" not appear since 19:17. So
>> looks like issue happens only when computer blocked and monitor in
>> power save mode.
>
> I'd bet on runtime pm or some other power saving feature in amdgpu
> shutting the interrupt handling down before
On 9/3/19 3:17 AM, Stephen Rothwell wrote:
> Hi all,
>
> News: I will only be doing 1 more release before I leave for Kernel
> Summit (there may be some reports on Thursday, but I doubt I will have
> time to finish the full release) and then no more until Sept 30.
>
> Changes since 20190902:
>
On Tue, 3 Sep 2019 11:48:12 +0500 From: Mikhail Gavrilov
> On Fri, 30 Aug 2019 at 08:30, Hillf Danton wrote:
> >
> > Add a warning to show if it makes sense in field: neither regression nor
> > problem will have been observed with the warning printed.
>
> I caught the problem.
>
>
> [21793.09
Hi,
While doing some changes to x86's pat code and thus having 'debugpat', I noticed
some weird behavior in a server running linux-next as of -- yes, reverting does
'fix'
the issue:
90f479ae51a (drm/mgag200: Replace struct mga_fbdev with generic framebuffer
emulation)
Where the following spla
Hi,
I tried this and it works with patches 4+5 from Rob's series and
changing gpummu to use sg_phys(sg) instead of sg->dma_address
(dma_address isn't set now that dma_map_sg isn't used).
Jonathan
On 9/3/19 11:22 AM, Rob Clark wrote:
On Mon, Sep 2, 2019 at 11:03 AM Fabio Estevam wrote:
Hi
Hi Sam：
sorry，My reply was late.
I commited to the following commit (d6781e490179 - (HEAD -> tmp, tag:
drm-misc-next-2019-08-03) drm/pl111: Drop special pads config check (3
weeks ago) )
I don't know why you executed the error.
- Can you paste your mistakes?
I used the following command to j
On Tue, 3 Sep 2019 at 21:49, Daniel Thompson wrote:
>
> On Tue, Aug 13, 2019 at 10:12:51AM +0100, Daniel Thompson wrote:
> > On Tue, Aug 13, 2019 at 02:28:55PM +0530, Nishka Dasgupta wrote:
> > > Static structure micro_bl_props, having type backlight_properties, is
> > > used only once, when it is
On 03/09/2019 18:24, Laurent Pinchart wrote:
> Hi Tomi,
>
> Thank you for the patch.
>
> On Mon, Sep 02, 2019 at 03:53:56PM +0300, Tomi Valkeinen wrote:
>> From: Jyri Sarha
>>
>> Implement CTM color management property for OMAP CRTC using DSS
>> overlay manager's Color Phase Rotation matrix. The
On Mon, Sep 02, 2019 at 03:28:58PM +0300, Ville Syrjälä wrote:
> On Sat, Aug 31, 2019 at 06:25:46PM +0100, Sidong Yang wrote:
> > Use alpha value to blend source value and destination value Instead of
> > just overwrite with source value.
> >
> > Signed-off-by: Sidong Yang
> > ---
> > drivers/gp
On 9/4/19 8:58 AM, Christoph Hellwig wrote:
On Tue, Sep 03, 2019 at 10:46:18PM +0200, Thomas Hellström (VMware) wrote:
What I mean with "from an engineering perspective" is that drivers would end
up with a non-trivial amount of code supporting purely academic cases:
Setups where software renderi
Am 03.09.19 um 23:05 schrieb Thomas Hellström (VMware):
> On 9/3/19 10:51 PM, Dave Hansen wrote:
>> On 9/3/19 1:36 PM, Thomas Hellström (VMware) wrote:
>>> So the question here should really be, can we determine already at mmap
>>> time whether backing memory will be unencrypted and adjust the *rea
Only call virtio_gpu_array_add_fence if we actually have a fence.
Fixes: da758d51968a ("drm/virtio: rework virtio_gpu_execbuffer_ioctl fencing")
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_vq.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drive
On Wed, Sep 4, 2019 at 8:49 AM Thomas Hellström (VMware)
wrote:
> On 9/4/19 1:15 AM, Andy Lutomirski wrote:
> > But, reading this, I have more questions:
> >
> > Can’t you get rid of cvma by using vmf_insert_pfn_prot()?
>
> It looks like that, although there are comments in the code about
> seriou
On Wed, Sep 4, 2019 at 8:53 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 04.09.19 um 08:27 schrieb Feng Tang:
> >> Thank you for testing. But don't get too excited, because the patch
> >> simulates a bug that was present in the original mgag200 code. A
> >> significant number of frames are simply ski
Hi, Christian,
On 9/4/19 9:33 AM, Koenig, Christian wrote:
Am 03.09.19 um 23:05 schrieb Thomas Hellström (VMware):
On 9/3/19 10:51 PM, Dave Hansen wrote:
On 9/3/19 1:36 PM, Thomas Hellström (VMware) wrote:
So the question here should really be, can we determine already at mmap
time whether ba
https://bugs.freedesktop.org/show_bug.cgi?id=109246
--- Comment #27 from Michel Dänzer ---
Disabling input probing in the monitor isn't a full workaround for me (with an
HP EliteDisplay E242, in case it matters). The monitor stays off, but there's
still a hotplug event, which requires me to re-ar
Hi, Dave,
On 9/4/19 1:10 AM, Dave Hansen wrote:
Thomas, this series has garnered a nak and a whole pile of thoroughly
confused reviewers.
Could you take another stab at this along with a more ample changelog
explaining the context of the problem? I suspect that's a better place
to start than h
Hi Daniel,
On Wed, Sep 04, 2019 at 10:11:11AM +0200, Daniel Vetter wrote:
> On Wed, Sep 4, 2019 at 8:53 AM Thomas Zimmermann wrote:
> >
> > Hi
> >
> > Am 04.09.19 um 08:27 schrieb Feng Tang:
> > >> Thank you for testing. But don't get too excited, because the patch
> > >> simulates a bug that was
On Tue, 2019-09-03 at 17:49 +0200, Daniel Vetter wrote:
> On Tue, Sep 03, 2019 at 11:49:23AM +, Lisovskiy, Stanislav wrote:
> > On Tue, 2019-09-03 at 11:40 +0200, Daniel Vetter wrote:
> > >
> > > > > In fact I was wrong - when it worked, it was using exactly
> > > > > those
> > > > > patches :
On Wed, Sep 04, 2019 at 09:17:16AM +0800, Hillf Danton wrote:
> Daniel Vetter
> >>
> >> Now 11:01pm and "gnome shell stuck warning" not appear since 19:17. So
> >> looks like issue happens only when computer blocked and monitor in
> >> power save mode.
> >
> > I'd bet on runtime pm or some other p
On 9/4/19 10:19 AM, Thomas Hellström (VMware) wrote:
Hi, Christian,
On 9/4/19 9:33 AM, Koenig, Christian wrote:
Am 03.09.19 um 23:05 schrieb Thomas Hellström (VMware):
On 9/3/19 10:51 PM, Dave Hansen wrote:
On 9/3/19 1:36 PM, Thomas Hellström (VMware) wrote:
So the question here should really
Hi
Am 04.09.19 um 10:35 schrieb Feng Tang:
> Hi Daniel,
>
> On Wed, Sep 04, 2019 at 10:11:11AM +0200, Daniel Vetter wrote:
>> On Wed, Sep 4, 2019 at 8:53 AM Thomas Zimmermann wrote:
>>>
>>> Hi
>>>
>>> Am 04.09.19 um 08:27 schrieb Feng Tang:
> Thank you for testing. But don't get too excited,
On Tue, Sep 03, 2019 at 04:43:45PM -0400, Kenny Ho wrote:
> On Tue, Sep 3, 2019 at 4:12 PM Daniel Vetter wrote:
> > On Tue, Sep 3, 2019 at 9:45 PM Kenny Ho wrote:
> > > On Tue, Sep 3, 2019 at 3:57 AM Daniel Vetter wrote:
> > > > Iterating over minors for cgroups sounds very, very wrong. Why do w
On 2019-09-03 10:16 p.m., Daniel Vetter wrote:
> On Tue, Sep 3, 2019 at 10:01 PM Sasha Levin wrote:
>> On Tue, Sep 03, 2019 at 07:03:47PM +0200, Greg KH wrote:
>>> On Tue, Sep 03, 2019 at 06:40:43PM +0200, Michel Dänzer wrote:
On 2019-09-03 6:23 p.m., Sasha Levin wrote:
> From: Yu Zhao
>
Hi,
On Tue, Sep 3, 2019 at 5:53 PM Neil Armstrong wrote:
>
> Hi,
>
> On 03/09/2019 07:51, Cheng-Yi Chiang wrote:
> > From: Yakir Yang
> >
> > When transmitting IEC60985 linear PCM audio, we configure the
> > Audio Sample Channel Status information of all the channel
> > status bits in the IEC609
On Wed, Sep 4, 2019 at 2:00 AM Neil Armstrong wrote:
>
> Hi,
>
> Le 03/09/2019 à 11:53, Neil Armstrong a écrit :
> > Hi,
> >
> > On 03/09/2019 07:51, Cheng-Yi Chiang wrote:
> >> From: Yakir Yang
> >>
> >> When transmitting IEC60985 linear PCM audio, we configure the
> >> Audio Sample Channel Stat
On Wed, Sep 4, 2019 at 10:35 AM Feng Tang wrote:
>
> Hi Daniel,
>
> On Wed, Sep 04, 2019 at 10:11:11AM +0200, Daniel Vetter wrote:
> > On Wed, Sep 4, 2019 at 8:53 AM Thomas Zimmermann
> > wrote:
> > >
> > > Hi
> > >
> > > Am 04.09.19 um 08:27 schrieb Feng Tang:
> > > >> Thank you for testing. Bu
On Wed, Sep 04, 2019 at 08:36:46AM +, Lisovskiy, Stanislav wrote:
> On Tue, 2019-09-03 at 17:49 +0200, Daniel Vetter wrote:
> > On Tue, Sep 03, 2019 at 11:49:23AM +, Lisovskiy, Stanislav wrote:
> > > On Tue, 2019-09-03 at 11:40 +0200, Daniel Vetter wrote:
> > > >
> > > > > > In fact I was
On Wed, Sep 4, 2019 at 2:08 AM Jernej Škrabec wrote:
>
> Hi!
>
> Dne torek, 03. september 2019 ob 20:00:33 CEST je Neil Armstrong napisal(a):
> > Hi,
> >
> > Le 03/09/2019 à 11:53, Neil Armstrong a écrit :
> > > Hi,
> > >
> > > On 03/09/2019 07:51, Cheng-Yi Chiang wrote:
> > >> From: Yakir Yang
>
On Wed, Sep 04, 2019 at 05:09:29PM +0800, Cheng-yi Chiang wrote:
> Hi,
>
> On Tue, Sep 3, 2019 at 5:53 PM Neil Armstrong wrote:
> >
> > Hi,
> >
> > On 03/09/2019 07:51, Cheng-Yi Chiang wrote:
> > > From: Yakir Yang
> > >
> > > When transmitting IEC60985 linear PCM audio, we configure the
> > > A
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #65 from tempel.jul...@gmail.com ---
@Nicholas
Since this commit, the modesetting driver shows the same behavior as
xf86-video-amdgpu:
https://gitlab.freedesktop.org/xorg/xserver/commit/f0d78b47ac49977a6007f5fe081f00c6eb19a12e
So, no
Hi,
On 04/09/2019 11:09, Cheng-yi Chiang wrote:
> Hi,
>
> On Tue, Sep 3, 2019 at 5:53 PM Neil Armstrong wrote:
>>
>> Hi,
>>
>> On 03/09/2019 07:51, Cheng-Yi Chiang wrote:
>>> From: Yakir Yang
>>>
>>> When transmitting IEC60985 linear PCM audio, we configure the
>>> Audio Sample Channel Status i
On Wed, Sep 4, 2019 at 4:33 AM Jonas Karlman wrote:
>
> On 2019-09-03 20:08, Jernej Škrabec wrote:
> > Hi!
> >
> > Dne torek, 03. september 2019 ob 20:00:33 CEST je Neil Armstrong napisal(a):
> >> Hi,
> >>
> >> Le 03/09/2019 à 11:53, Neil Armstrong a écrit :
> >>> Hi,
> >>>
> >>> On 03/09/2019 07:
On Wed, Sep 4, 2019 at 5:28 PM Neil Armstrong wrote:
>
> Hi,
>
> On 04/09/2019 11:09, Cheng-yi Chiang wrote:
> > Hi,
> >
> > On Tue, Sep 3, 2019 at 5:53 PM Neil Armstrong
> > wrote:
> >>
> >> Hi,
> >>
> >> On 03/09/2019 07:51, Cheng-Yi Chiang wrote:
> >>> From: Yakir Yang
> >>>
> >>> When trans
The "lvds->backlight" pointer could be NULl if of_parse_phandle()
returns NULL.
Fixes: 7c9dff5bd643 ("drm: panels: Add LVDS panel driver")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/panel/panel-lvds.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/pan
On Wed, 2019-09-04 at 11:23 +0200, Daniel Vetter wrote:
>
> > Sure this will work, but still we need somehow to be able to
> > determine
> > this "if it's different" state. In your solution we just move that
> > comparison to drm_connector_update_edid_property, which is quite
> > fine
> > for me.
On 03.09.2019 18:18, John Stultz wrote:
> On Mon, Sep 2, 2019 at 6:22 AM Andrzej Hajda wrote:
>> On 30.08.2019 19:00, Rob Clark wrote:
>>> On Thu, Aug 29, 2019 at 11:52 PM Andrzej Hajda wrote:
Of course it seems you have different opinion what is the right thing in
this case, so if you
On Wed, Sep 04, 2019 at 05:45:20PM +0800, Cheng-yi Chiang wrote:
> On Wed, Sep 4, 2019 at 5:28 PM Neil Armstrong wrote:
> >
> > Hi,
> >
> > On 04/09/2019 11:09, Cheng-yi Chiang wrote:
> > > Hi,
> > >
> > > On Tue, Sep 3, 2019 at 5:53 PM Neil Armstrong
> > > wrote:
> > >>
> > >> Hi,
> > >>
> > >>
On 9/4/19 9:53 AM, Daniel Vetter wrote:
On Wed, Sep 4, 2019 at 8:49 AM Thomas Hellström (VMware)
wrote:
On 9/4/19 1:15 AM, Andy Lutomirski wrote:
But, reading this, I have more questions:
Can’t you get rid of cvma by using vmf_insert_pfn_prot()?
It looks like that, although there are comment
On Wed, Sep 4, 2019 at 6:32 PM Russell King - ARM Linux admin
wrote:
>
> On Wed, Sep 04, 2019 at 05:45:20PM +0800, Cheng-yi Chiang wrote:
> > On Wed, Sep 4, 2019 at 5:28 PM Neil Armstrong
> > wrote:
> > >
> > > Hi,
> > >
> > > On 04/09/2019 11:09, Cheng-yi Chiang wrote:
> > > > Hi,
> > > >
> > >
Am 04.09.19 um 10:19 schrieb Thomas Hellström (VMware):
> Hi, Christian,
>
> On 9/4/19 9:33 AM, Koenig, Christian wrote:
>> Am 03.09.19 um 23:05 schrieb Thomas Hellström (VMware):
>>> On 9/3/19 10:51 PM, Dave Hansen wrote:
On 9/3/19 1:36 PM, Thomas Hellström (VMware) wrote:
> So the questi
Hi Jyri,
On Wed, Sep 04, 2019 at 10:17:00AM +0300, Jyri Sarha wrote:
> On 03/09/2019 18:24, Laurent Pinchart wrote:
> > On Mon, Sep 02, 2019 at 03:53:56PM +0300, Tomi Valkeinen wrote:
> >> From: Jyri Sarha
> >>
> >> Implement CTM color management property for OMAP CRTC using DSS
> >> overlay mana
On Wed, 4 Sep 2019 at 19:17, Daniel Vetter wrote:
>
> On Wed, Sep 4, 2019 at 10:35 AM Feng Tang wrote:
> >
> > Hi Daniel,
> >
> > On Wed, Sep 04, 2019 at 10:11:11AM +0200, Daniel Vetter wrote:
> > > On Wed, Sep 4, 2019 at 8:53 AM Thomas Zimmermann
> > > wrote:
> > > >
> > > > Hi
> > > >
> > > >
On Wed, Sep 4, 2019 at 1:15 PM Dave Airlie wrote:
>
> On Wed, 4 Sep 2019 at 19:17, Daniel Vetter wrote:
> >
> > On Wed, Sep 4, 2019 at 10:35 AM Feng Tang wrote:
> > >
> > > Hi Daniel,
> > >
> > > On Wed, Sep 04, 2019 at 10:11:11AM +0200, Daniel Vetter wrote:
> > > > On Wed, Sep 4, 2019 at 8:53 A
On Wed, Sep 4, 2019 at 12:38 PM Thomas Hellström (VMware)
wrote:
>
> On 9/4/19 9:53 AM, Daniel Vetter wrote:
> > On Wed, Sep 4, 2019 at 8:49 AM Thomas Hellström (VMware)
> > wrote:
> >> On 9/4/19 1:15 AM, Andy Lutomirski wrote:
> >>> But, reading this, I have more questions:
> >>>
> >>> Can’t you
https://bugs.freedesktop.org/show_bug.cgi?id=111551
--- Comment #3 from Christian König ---
As far as I can see this is a really large box with multiple GPUs installed.
The SDMA rarely locks up, especially not while executing page table updates. So
there is most likely something wrong with the h
Hi Dan,
Thank you for the patch.
On Wed, Sep 04, 2019 at 01:03:29PM +0300, Dan Carpenter wrote:
> The "lvds->backlight" pointer could be NULl if of_parse_phandle()
> returns NULL.
>
> Fixes: 7c9dff5bd643 ("drm: panels: Add LVDS panel driver")
> Signed-off-by: Dan Carpenter
> ---
> drivers/gpu/
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
---
drivers/video/fbdev/da8xx-fb.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/da8xx-fb.c b/drivers/v
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
---
drivers/video/fbdev/omap2/omapfb/vrfb.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/
(was: drm/vram-helper: Fix performance regression in fbdev)
Generic fbdev emulation maps and unmaps the console BO for updating it's
content from the shadow buffer. If this involves an actual mapping
operation (instead of reusing an existing mapping), lots of debug messages
may be printed, such as
The generic fbdev emulation will map and unmap the framebuffer's memory
if required. As consoles are most often updated while being on screen,
we map the fbdev buffer while it's being displayed. This avoids frequent
map/unmap operations in the fbdev code. The original fbdev code in mgag200
used the
The kmap and kunmap operations of GEM VRAM buffers can now be called
in interleaving pairs. The first call to drm_gem_vram_kmap() maps the
buffer's memory to kernel address space and the final call to
drm_gem_vram_kunmap() unmaps the memory. Intermediate calls to these
functions increment or decrem
The generic fbdev emulation will map and unmap the framebuffer's memory
if required. As consoles are most often updated while being on screen,
we map the fbdev buffer while it's being displayed. This avoids frequent
map/unmap operations in the fbdev code. The original fbdev code in ast
used the sam
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
---
drivers/video/fbdev/sa1100fb.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/sa1100fb.c b/drivers/v
Hi
Am 04.09.19 um 08:49 schrieb Davidlohr Bueso:
> Hi,
>
> While doing some changes to x86's pat code and thus having 'debugpat', I
> noticed
> some weird behavior in a server running linux-next as of -- yes,
> reverting does 'fix'
> the issue:
>
> 90f479ae51a (drm/mgag200: Replace struct mga_fb
On Wed, Sep 04, 2019 at 10:55:10AM +0200, Michel Dänzer wrote:
On 2019-09-03 10:16 p.m., Daniel Vetter wrote:
On Tue, Sep 3, 2019 at 10:01 PM Sasha Levin wrote:
On Tue, Sep 03, 2019 at 07:03:47PM +0200, Greg KH wrote:
On Tue, Sep 03, 2019 at 06:40:43PM +0200, Michel Dänzer wrote:
On 2019-09-
On Wed, Sep 4, 2019 at 1:56 PM Thomas Zimmermann wrote:
>
> (was: drm/vram-helper: Fix performance regression in fbdev)
>
> Generic fbdev emulation maps and unmaps the console BO for updating it's
> content from the shadow buffer. If this involves an actual mapping
> operation (instead of reusing
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #26 from Marko Popovic ---
(In reply to Mathieu Belanger from comment #25)
> I confirm that a system wide nongg do not fix random surprise crash I get on
> filezilla and phpstorm.
>
> Switching to system wide nodma (that sound scary
On Wed, Sep 04, 2019 at 09:32:30AM +0200, Thomas Hellström (VMware) wrote:
> That sounds great. Is there anything I can do to help out? I thought this
> was more or less a dead end since the current dma_mmap_ API requires the
> mmap_sem to be held in write mode (modifying the vma->vm_flags) whereas
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #27 from Mathieu Belanger ---
It did fix it for me too.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
---
drivers/video/fbdev/wm8505fb.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/wm8505fb.c b/drivers/v
https://bugs.freedesktop.org/show_bug.cgi?id=111551
--- Comment #4 from yanhua <78666...@qq.com> ---
I have asked hardware team, they have tested, and can be sure there are no
power supply problem.
The system is arm64 with 64 cores. and there are three amdgpu card in the
board.
there are rarel
The panfrost driver requests a supply using regulator_get_optional()
but both the name of the supply and the usage pattern suggest that it is
being used for the main power for the device and is not at all optional
for the device for function, there is no meaningful handling for absent
supplies. Su
The lima driver requests a supply using regulator_get_optional() but
both the name of the supply and the usage pattern suggest that it is
being used for the main power for the device and is not at all optional
for the device for function, there is no meaningful handling for absent
supplies. Such r
On 9/4/19 1:10 PM, Koenig, Christian wrote:
Am 04.09.19 um 10:19 schrieb Thomas Hellström (VMware):
Hi, Christian,
On 9/4/19 9:33 AM, Koenig, Christian wrote:
Am 03.09.19 um 23:05 schrieb Thomas Hellström (VMware):
On 9/3/19 10:51 PM, Dave Hansen wrote:
On 9/3/19 1:36 PM, Thomas Hellström (V
https://bugs.freedesktop.org/show_bug.cgi?id=111551
Christian König changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=111551
--- Comment #6 from yanhua <78666...@qq.com> ---
As far as I know, arm64 does not support wc memory. and We have already turn
the wc flag as newer kernel version does.
--
You are receiving this mail because:
You are the assignee for the bug.___
On 2019-09-03 3:06 p.m., Daniel Vetter wrote:
> It's the only flag anyone actually cares about. Plus if we're unlucky,
> the atomic ioctl might need a different flag for async flips. So
> better to abstract this away from the uapi a bit.
>
> Cc: Maarten Lankhorst
> Cc: Michel Dänzer
> Cc: Alex D
On Wed, Sep 04, 2019 at 02:50:57PM +0300, Laurent Pinchart wrote:
> > error:
> > - put_device(&lvds->backlight->dev);
> > + if (lvds->backlight)
> > + put_device(&lvds->backlight->dev);
>
> How about simply
>
> - put_device(&lvds->backlight->dev);
> + backlight_put(lvds->ba
On 9/4/19 2:35 PM, Thomas Hellström (VMware) wrote:
I've already talked with Christoph that we probably want to switch TTM
over to using that instead to also get rid of the ttm_io_prot() hack.
OK, would that mean us ditching other memory modes completely? And
on-the-fly caching transitions?
Hi Sam,
On Sat, Aug 24, 2019 at 05:02:34PM +0300, Laurent Pinchart wrote:
> On Sat, Aug 24, 2019 at 11:54:21AM +0200, Sam Ravnborg wrote:
> > On Fri, Aug 23, 2019 at 10:32:44PM +0300, Laurent Pinchart wrote:
> >> Add a type field to the drm_panel structure to report the panel type,
> >> using DRM_
On 2019-09-04 5:12 a.m., Jean Delvare wrote:
> It is fine for displays without audio functionality to not provide
> any SAD block in their EDID. Do not log an error in that case,
> just return quietly.
>
> This fixes half of bug fdo#107825:
> https://bugs.freedesktop.org/show_bug.cgi?id=107825
>
On Tue, 03 Sep 2019, Baolin Wang wrote:
> From: Chris Wilson
>
> If we skipped all the connectors that were not part of a tile, we would
> leave conn_seq=0 and conn_configured=0, convincing ourselves that we
> had stagnated in our configuration attempts. Avoid this situation by
> starting conn_se
Add a type field to the drm_panel structure to report the panel type,
using DRM_MODE_CONNECTOR_* macros (the values that make sense are LVDS,
eDP, DSI and DPI). This will be used to initialise the corresponding
connector type.
Update all panel drivers accordingly. The panel-simple driver only
spec
Hello,
This series, whose previous version was named "[PATCH v2 0/4] drm/panel:
Extend panels to report their types" and is available at
https://www.spinics.net/lists/dri-devel/msg224579.html, allows panels to
report their type, in order to create drm_connector instances with
appropriate types in
The drm panel bridge creates a connector using a connector type
explicitly passed by the display controller or bridge driver that
instantiates the panel bridge. Now that drm_panel reports its connector
type, we can use it to avoid passing an explicit (and often incorrect)
connector type to drm_pane
The OSD070T1718 is a DPI panel, set its type accordingly.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/panel/panel-simple.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 4b92b27eba86..5d487686d25c 100
When using single_open() for opening, single_release() should be
used, otherwise there is a memory leak.
This is detected by Coccinelle semantic patch.
Fixes: 6e9fc177399f ("drm/nouveau/debugfs: add copy of sysfs pstate interface
ported to debugfs")
Signed-off-by: Wei Yongjun
---
drivers/gpu/d
Hi Thomas,
On 9/4/2019 4:43 PM, Thomas Zimmermann wrote:
Hi
Am 04.09.19 um 10:35 schrieb Feng Tang:
Hi Daniel,
On Wed, Sep 04, 2019 at 10:11:11AM +0200, Daniel Vetter wrote:
On Wed, Sep 4, 2019 at 8:53 AM Thomas Zimmermann wrote:
Hi
Am 04.09.19 um 08:27 schrieb Feng Tang:
Thank you for t
- it's what we recommend in our docs:
https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#recommended-ioctl-return-values
- it's the overwhelmingly used error code for "operation not
supported", at least in drm core (slightly less so in drivers):
$ git grep EOPNOTSUP -- drivers/gpu/drm/*c |
On 2019-09-04 2:08 p.m., Sasha Levin wrote:
>
> FWIW, I've added another test to my scripts to try and catch these cases
> (Revert "%s"). It'll slow down the scripts a bit but it's better to get
> it right rather than to be done quickly :)
Indeed, thanks! And again sorry for the brouhaha, I just
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #66 from Michel Dänzer ---
(In reply to tempel.julian from comment #65)
> Since this commit, the modesetting driver shows the same behavior as
> xf86-video-amdgpu:
> https://gitlab.freedesktop.org/xorg/xserver/commit/
> f0d78b47ac499
https://bugs.freedesktop.org/show_bug.cgi?id=107538
Matt Roper changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Den 04.09.2019 16.39, skrev Daniel Vetter:
> - it's what we recommend in our docs:
>
> https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#recommended-ioctl-return-values
>
> - it's the overwhelmingly used error code for "operation not
> supported", at least in drm core (slightly less so i
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #28 from Pierre-Eric Pelloux-Prayer
---
Regarding sdma ring hangs: if you still have access to the affected machine
using ssh, it would be helpful to add a comment with the following information:
- the last dmesg lines (at least
On Wed, Sep 04, 2019 at 08:27:07AM +0100, Sidong Yang wrote:
> On Mon, Sep 02, 2019 at 03:28:58PM +0300, Ville Syrjälä wrote:
> > On Sat, Aug 31, 2019 at 06:25:46PM +0100, Sidong Yang wrote:
> > > Use alpha value to blend source value and destination value Instead of
> > > just overwrite with sourc
From: Laurent Pinchart
[ Upstream commit 8090f7eb318d4241625449252db2741e7703e027 ]
When refactoring port lookup for DSS outputs, commit d17eb4537a7e
("drm/omap: Factor out common init/cleanup code for output devices")
incorrectly hardcoded usage of DT port 0. This breaks operation for SDI
(whic
From: Gerd Hoffmann
[ Upstream commit 9b2a0a1ef66f96bf34921a3865581eca32ff05ec ]
We must make sure our scatterlist segments are not too big, otherwise
we might see swiotlb failures (happens with sev, also reproducable with
swiotlb=force).
Suggested-by: Laszlo Ersek
Signed-off-by: Gerd Hoffmann
From: Christian König
[ Upstream commit 42068e1ef961c719f967dbbb4ddcb394a0ba7917 ]
We need to grab a reference to the fence we wait for.
Signed-off-by: Christian König
Reviewed-by: Chunming Zhou
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ct
From: Evan Quan
[ Upstream commit 83e09d5bddbee749fc83063890244397896a1971 ]
Correct the settings for auto mode and skip the unnecessary
settings for dcefclk and fclk.
Signed-off-by: Evan Quan
Acked-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../drm/amd/pow
On Thu, Aug 15, 2019 at 11:14:17AM +, Wen He wrote:
>
>
> > -Original Message-
> > From: Liviu Dudau
> > Sent: 2019年7月22日 17:33
> > To: Wen He
> > Cc: dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org;
> > brian.star...@arm.com; airl...@linux.ie; dan...@ffwll.ch; Leo Li
https://bugzilla.kernel.org/show_bug.cgi?id=204725
--- Comment #52 from Dmitri Seletski (drj...@gmail.com) ---
Created attachment 284845
--> https://bugzilla.kernel.org/attachment.cgi?id=284845&action=edit
dmesg 001
as per request, dmesg output
--
You are receiving this mail because:
You are
https://bugs.freedesktop.org/show_bug.cgi?id=111459
--- Comment #3 from peter m ---
Unfortunately I don't know how to apply this patch/patches.
Updated to new kernel 5.2.11-200.fc30.x86_64, problem still exists.
Sep 04 19:45:23 kernel: WARNING: CPU: 2 PID: 1014 at
drivers/gpu/drm/amd/amdgpu/../
From: Rob Clark
Looks like the dma_sync calls don't do what we want on armv7 either.
Fixes:
Unable to handle kernel paging request at virtual address 50001000
pgd = (ptrval)
[50001000] *pgd=
Internal error: Oops: 805 [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper
On Tue, Sep 03, 2019 at 02:55:26PM +0800, Baolin Wang wrote:
> From: Chris Wilson
>
> If we skipped all the connectors that were not part of a tile, we would
> leave conn_seq=0 and conn_configured=0, convincing ourselves that we
> had stagnated in our configuration attempts. Avoid this situation
On 9/4/19 2:22 PM, Christoph Hellwig wrote:
On Wed, Sep 04, 2019 at 09:32:30AM +0200, Thomas Hellström (VMware) wrote:
That sounds great. Is there anything I can do to help out? I thought this
was more or less a dead end since the current dma_mmap_ API requires the
mmap_sem to be held in write m
https://bugs.freedesktop.org/show_bug.cgi?id=111077
--- Comment #24 from rol...@rptd.ch ---
(In reply to Matt Turner from comment #23)
> Can you make an apitrace of the application that demonstrates the problem?
I can only try RenderDoc. But can you export an API trace with it?
--
You are rece
On 04/09/2019 01:12, Rob Clark wrote:
On Tue, Sep 3, 2019 at 12:31 PM Fabio Estevam wrote:
Hi Jonathan,
On Tue, Sep 3, 2019 at 4:25 PM Jonathan Marek wrote:
Hi,
I tried this and it works with patches 4+5 from Rob's series and
changing gpummu to use sg_phys(sg) instead of sg->dma_address
(
https://bugs.freedesktop.org/show_bug.cgi?id=111459
--- Comment #4 from peter m ---
Thread with similar problem
https://bugs.freedesktop.org/show_bug.cgi?id=109628
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel
https://bugs.freedesktop.org/show_bug.cgi?id=109628
--- Comment #14 from peter m ---
Thread with similar problem
https://bugs.freedesktop.org/show_bug.cgi?id=111459
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-deve
1 - 100 of 133 matches
Mail list logo
