Hi Thomas,
On Wed, Aug 28, 2019 at 12:51:40PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 28.08.19 um 11:37 schrieb Rong Chen:
> > Hi Thomas,
> >
> > On 8/28/19 1:16 AM, Thomas Zimmermann wrote:
> >> Hi
> >>
> >> Am 27.08.19 um 14:33 schrieb Chen, Rong A:
> >>> Both patches have little impact
https://bugs.freedesktop.org/show_bug.cgi?id=108973
Timothy Arceri changed:
What|Removed |Added
Status|NEEDINFO|RESOLVED
Resolution|---
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
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 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.
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,
> > > >
> >
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.
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
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
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
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, 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 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
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 skipped. That is apparently the
>> reason why it's faster.
>
> Thanks
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
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
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
> > > >
> > >
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
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 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
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
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.
>
>
>
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
>
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
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
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
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
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
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
Hi all,
Today's linux-next merge of the drm tree got conflicts in:
drivers/gpu/drm/amd/display/dc/calcs/Makefile
drivers/gpu/drm/amd/display/dc/dml/Makefile
drivers/gpu/drm/amd/display/dc/dsc/Makefile
between commit:
30851871d5ab ("kbuild: change *FLAGS_.o to take the path relative
to
https://bugs.freedesktop.org/show_bug.cgi?id=108979
--- Comment #6 from Timothy Arceri ---
Is this still a problem?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
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
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
> > >
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,
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
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
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 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
> > ---
> >
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
On 03/09/2019 18:34, Laurent Pinchart wrote:
> Hi Tomi,
>
> Thank you for the patch.
>
> Missing "Move" in the subject after "dss: " ?
>
That was intentional to keep the subject short enough. But it looks like
it is just bellow 76 chars (80 - 4 char indent) even with "Move" added
to it.
BR,
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
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
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
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,
> > >>
> >
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
On 9/4/19 1:15 AM, Andy Lutomirski wrote:
On Sep 3, 2019, at 3:15 PM, Thomas Hellström (VMware)
wrote:
On 9/4/19 12:08 AM, Thomas Hellström (VMware) wrote:
On 9/3/19 11:46 PM, Andy Lutomirski wrote:
On Tue, Sep 3, 2019 at 2:05 PM Thomas Hellström (VMware)
wrote:
On 9/3/19 10:51 PM, Dave
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
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 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
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=111077
--- Comment #25 from Matt Turner ---
(In reply to rol...@rptd.ch from comment #24)
> (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
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
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
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
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
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
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=edit
dmesg 001
as per request, dmesg output
--
You are receiving this mail because:
You are
The "lvds->backlight" pointer could be NULL in situations were
of_parse_phandle() returns NULL. Also it's slightly cleaner to use
backlight_put() which already has a check for NULL built in.
Fixes: 7c9dff5bd643 ("drm: panels: Add LVDS panel driver")
Signed-off-by: Dan Carpenter
---
v2: Use
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 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://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.___
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.___
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
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
---
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=109628
--- Comment #15 from peter m ---
(In reply to peter m from comment #14)
> Thread with similar problem
>
> https://bugs.freedesktop.org/show_bug.cgi?id=111459
In my case, screen became black after entering password in welcome screen.
--
You
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
---
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
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:
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
On Wed, Sep 4, 2019 at 7:14 PM Davidlohr Bueso wrote:
> On Wed, 04 Sep 2019, Daniel Vetter wrote:
> >I'm also not sure whether we have a real problem here, it's just debug
> >noise that we're fighting here?
>
> It is non stop debug noise as the memory range in question is being added +
> deleted
DP 1.4a specification defines Link Training Tunable PHY Repeater (LTTPR)
which is required to add support for systems with Thunderbolt or other
repeater devices.
Changes since V3:
- Replace spaces by tabs
Changes since V2:
- Drop the kernel-doc comment
- Reorder LTTPR according to register offset
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=111551
Christian König changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
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
https://bugs.freedesktop.org/show_bug.cgi?id=107538
Matt Roper changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
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)
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
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
---
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/
>
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
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
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
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
On Wed, Sep 04, 2019 at 02:50:57PM +0300, Laurent Pinchart wrote:
> > error:
> > - put_device(>backlight->dev);
> > + if (lvds->backlight)
> > + put_device(>backlight->dev);
>
> How about simply
>
> - put_device(>backlight->dev);
> + backlight_put(lvds->backlight);
Yeah.
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
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
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
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
- 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
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
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
1 - 100 of 133 matches
Mail list logo
