On Wed, Sep 04, 2019 at 04:10:30PM -0700, Chia-I Wu wrote:
> On Wed, Sep 4, 2019 at 12:48 AM Gerd Hoffmann wrote:
> >
> > Only call virtio_gpu_array_add_fence if we actually have a fence.
> >
> > Fixes: da758d51968a ("drm/virtio: rework virtio_gpu_execbuffer_ioctl
> > fencing")
> >
Hi, Jitao:
For this series, applied to mediatek-drm-next-5.5 [1], and I break
"[v6,2/7] drm/mediatek: fixes CMDQ reg address of mt8173 is different
with mt2701" into two patches, thanks.
[1]
https://github.com/ckhu-mediatek/linux.git-tags/commits/mediatek-drm-next-5.5
Regards,
CK
On Sun,
Hi, Jitao:
For this series, applied to mediatek-drm-next-5.5 [1], thanks.
[1]
https://github.com/ckhu-mediatek/linux.git-tags/commits/mediatek-drm-next-5.5
Regards,
CK
On Wed, 2019-08-07 at 16:46 +0800, Jitao Shi wrote:
> Change since v5:
> - remove mipi_tx->ref_clk
> - remove mt8183 pll
https://bugs.freedesktop.org/show_bug.cgi?id=111482
--- Comment #11 from Andrew Sheldon ---
One more thing to add: some users on Windows have had issues with X470/X570
PCIE4 support. The problem being that Navi advertises PCIE4 support, but
doesn't actually support it properly yet, causing weird
Use alpha value to blend source value and destination value Instead of
just overwrite with source value.
Signed-off-by: Sidong Yang
---
v1 -> v2:
* Move variables to tighter scope.
drivers/gpu/drm/vkms/vkms_composer.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff
https://bugs.freedesktop.org/show_bug.cgi?id=111482
--- Comment #10 from Andrew Sheldon ---
>I don't know how to interpret your last comment
Yeah, I was a bit unclear. I was just indicating that while I can workaround
the issue, it can still be triggered on my system as well. E.g. if I switch
On Wed, Sep 4, 2019 at 12:48 AM Gerd Hoffmann wrote:
>
> 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 +
On Wed, 4 Sep 2019 at 13:37, Daniel Vetter wrote:
>
> Extend your backtrac warning slightly like
>
> WARN(r, "we're stuck on fence %pS\n", fence->ops);
>
> Also adding Harry and Alex, I'm not really working on amdgpu ...
[ 3511.998320] [ cut here ]
[ 3511.998714]
https://bugs.freedesktop.org/show_bug.cgi?id=111482
--- Comment #9 from Robert ---
Thanks Andrew, but I guess I don't know how to interpret your last comment ;-)
Is there something I can test/change? I can't change the value of
"/sys/class/drm/card0/device/pp_dpm_mclk" which is the memclock
Hi Jyri,
On Wed, Sep 04, 2019 at 11:08:20PM +0300, Jyri Sarha wrote:
> On 04/09/2019 14:11, Laurent Pinchart wrote:
> > 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
Hi Dan,
Thank you for the patch.
On Wed, Sep 04, 2019 at 09:55:07PM +0300, Dan Carpenter wrote:
> 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.
>
Move the static keyword to the front of declarations
of msm_dsi_v2_host_ops, msm_dsi_6g_host_ops and
msm_dsi_6g_v2_host_ops, and resolve the following
compiler warnings that can be seen when building
with warnings enabled (W=1):
drivers/gpu/drm/msm/dsi/dsi_cfg.c:150:1: warning:
‘static’ is not
https://bugs.freedesktop.org/show_bug.cgi?id=109955
--- Comment #95 from koala_man ---
I am also seeing this issue on my stock Ubuntu.
>OS Info can be taken from neofetch
OS: Ubuntu 19.04 x86_64
Host: All Series
Kernel: 5.0.0-27-generic
Uptime: 8 mins
Packages: 2671 (dpkg), 6 (flatpak), 10
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #67 from tempel.jul...@gmail.com ---
(In reply to Michel Dänzer from comment #66)
> They still use page flipping though, similar to TearFree. Which Wayland
> compositor(s) have you tried?
I have tried a Wayland Gnome and Plasma
From: Sean Paul
Since the dirtyfb ioctl doesn't give us any hints as to which plane is
scanning out the fb it's marking as damaged, we need to loop through
planes to find it.
Currently we just reach into plane state and check, but that can race
with another commit changing the fb out from under
On Wed, Sep 4, 2019 at 4:08 PM Jyri Sarha wrote:
>
> On 04/09/2019 14:11, Laurent Pinchart wrote:
> > 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
There is a use case to share h/w pipe resources between lessee masters.
Two planes are created and allocated to two masters, but internally they
share the same h/w pipe:
masterA masterB
planeA planeB
||
\--- same H/W ---/
A seamless handoff between the
On Wed, Sep 4, 2019 at 3:28 PM Laurent Pinchart
wrote:
> 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.
>
>
On 04/09/2019 14:11, Laurent Pinchart wrote:
> 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
On Wed, Sep 4, 2019 at 9:58 PM Souza, Jose wrote:
>
> On Wed, 2019-09-04 at 16:39 +0200, Daniel Vetter wrote:
> > - 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
On Wed, 2019-09-04 at 16:39 +0200, Daniel Vetter wrote:
> - 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
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
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
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
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=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
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.___
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.___
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=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
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 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
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:
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
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
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
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
---
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: 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
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
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://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
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
https://bugs.freedesktop.org/show_bug.cgi?id=107538
Matt Roper changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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 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
- 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
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
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
---
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
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
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
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
>
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 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 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 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
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
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 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
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.
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
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
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 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=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 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
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
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
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
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
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
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
(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
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
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
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
> ---
>
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
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
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
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 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
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 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 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
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 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, 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.
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 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 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
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,
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 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 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.
1 - 100 of 133 matches
Mail list logo
