https://bugs.freedesktop.org/show_bug.cgi?id=110906
Michel Dänzer changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=110783
--- Comment #12 from Gert Wollny ---
I might add that the DIV is lowered in glsl to RCP+MUL before it is translated
to TGSI, so no need for it there.
When I look at the bicubic shader with the offending opcodes, I have to say
that using DIV
https://bugs.freedesktop.org/show_bug.cgi?id=110883
--- Comment #8 from Michel Dänzer ---
*** Bug 110906 has been marked as a duplicate of this bug. ***
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing
https://bugs.freedesktop.org/show_bug.cgi?id=99970
--- Comment #8 from Michel Dänzer ---
(In reply to cosiekvfj from comment #7)
> Is is worth to try to fix DRI3 and EXA for this driver or is it better to
> stick to DRI2?
I'd say the latter.
--
You are receiving this mail because:
You are the
On Thu, Jun 13, 2019 at 02:31:18PM +0800, CK Hu wrote:
> Hi, Daniel:
>
> On Wed, 2019-06-12 at 18:25 +0200, Daniel Vetter wrote:
> > On Wed, Jun 12, 2019 at 03:51:08PM +0800, CK Hu wrote:
> > > Hi Dave, Daniel:
> > >
> > > This include unbind error fix, clock control flow refinement, and PRIME
>
https://bugs.freedesktop.org/show_bug.cgi?id=110856
--- Comment #2 from Arek Tumas ---
Created attachment 144527
--> https://bugs.freedesktop.org/attachment.cgi?id=144527=edit
Dmesg log file
This is during a Rocket League session with kernel version 5.1.4-1-MANJARO
--
You are receiving this
Em Wed, 12 Jun 2019 17:25:39 -0700
"Srivatsa S. Bhat" escreveu:
> On 6/12/19 10:52 AM, Mauro Carvalho Chehab wrote:
> > Convert the PM documents to ReST, in order to allow them to
> > build with Sphinx.
> >
> > The conversion is actually:
> > - add blank lines and identation in order to
https://bugs.freedesktop.org/show_bug.cgi?id=110795
--- Comment #18 from Christian König ---
(In reply to Andre Klapper from comment #17)
> Feel free to talk to AMD about that. You are asking the wrong people.
Well no, he is asking exactly at the right location.
Take a look at the component,
On Wed, May 29, 2019 at 4:25 PM Dan Carpenter wrote:
> We never set "vblank" to "false".
>
> Current versions of GCC will initialize it to zero automatically at
> certain optimization levels so that's probably why this didn't show up
> in testing.
>
> Fixes: 5fc537bfd000 ("drm/mcde: Add new
On Fri, May 31, 2019 at 12:23 AM Maxime Ripard
wrote:
>
> On Fri, May 24, 2019 at 03:55:42PM +0530, Jagan Teki wrote:
> > On Fri, May 24, 2019 at 2:07 AM Maxime Ripard
> > wrote:
> > >
> > > On Mon, May 20, 2019 at 02:33:09PM +0530, Jagan Teki wrote:
> > > > start value in video start delay
On Thu, Jun 13, 2019 at 10:17:27AM +0200, Daniel Vetter wrote:
> On Wed, Jun 12, 2019 at 02:26:24AM +, james qian wang (Arm Technology
> China) wrote:
> > On Tue, Jun 11, 2019 at 02:30:38PM +0200, Daniel Vetter wrote:
> > > On Tue, Jun 11, 2019 at 11:13:45AM +, Lowry Li (Arm Technology
Hi!
On Thu, 2019-06-13 at 12:25 +0800, Hillf Danton wrote:
> Hello Thomas
>
> On Wed, 12 Jun 2019 08:42:39 +0200 Thomas Hellstrom wrote:
> > From: Thomas Hellstrom
> >
> > With the vmwgfx dirty tracking, the default TTM fault handler is
> > not
> > completely sufficient (vmwgfx need to modify
On Mon, Jun 10, 2019 at 10:36:27AM -0300, Helen Koike wrote:
> commit 89a4aac0ab0e6f5eea10d7bf4869dd15c3de2cd4 upstream.
>
> In the case of a normal sync update, the preparation of framebuffers (be
> it calling drm_atomic_helper_prepare_planes() or doing setups with
> drm_framebuffer_get()) are
On Mon, Jun 10, 2019 at 10:18:59AM -0300, Helen Koike wrote:
> commit c16b85559dcfb5a348cc085a7b4c75ed49b05e2c upstream.
>
> Async update callbacks are expected to set the old_fb in the new_state
> so prepare/cleanup framebuffers are balanced.
>
> Calling drm_atomic_set_fb_for_plane() (which
On Thu, Jun 13, 2019 at 08:45:49AM +0200, Thomas Zimmermann wrote:
> Acked-by: Thomas Zimmermann
Thanks for taking a look, pushed to drm-misc-next.
-Daniel
>
> Am 12.06.19 um 11:12 schrieb Daniel Vetter:
> > ast doesn't implement the mode_set_base_atomic hook this would need,
> > so this is
https://bugs.freedesktop.org/show_bug.cgi?id=110907
Michel Dänzer changed:
What|Removed |Added
Attachment #144525|text/x-log |text/plain
mime type|
On Thu, Jun 13, 2019 at 09:30:32AM +0200, Thomas Zimmermann wrote:
> Drivers should not have to care about internal locking of GEM VRAM objects
> and their memory-mapping structures. This patch set removes both from the
> GEM VRAM interface.
>
> This affects the ast and mgag200 drivers. In places
https://bugs.freedesktop.org/show_bug.cgi?id=110897
--- Comment #17 from cosiek...@o2.pl ---
*-display
description: VGA compatible controller
product: RC410M [Mobility Radeon Xpress 200M]
vendor: Advanced Micro Devices, Inc. [AMD/ATI]
https://bugs.freedesktop.org/show_bug.cgi?id=110730
--- Comment #7 from emersion ---
This bug has only been seen once, 4 weeks ago.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=110897
--- Comment #19 from Richard Thier ---
Btw the code paths for my logs are always the same - both when wrong and
good I have no idea...
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=110883
--- Comment #9 from Paul Menzel ---
I also confirm that this fixes the problem on the Dell OptiPlex 5040.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel
https://bugs.freedesktop.org/show_bug.cgi?id=110822
--- Comment #20 from Gobinda Joy ---
(In reply to Alex Deucher from comment #19)
> (In reply to Gobinda Joy from comment #18)
> >
> > What I don't get is why they are using 2 calls to get the bandwidth reading.
> > Since both function walking
Hi, Yongqiang:
On Wed, 2019-06-05 at 19:42 +0800, yongqiang@mediatek.com wrote:
> From: Yongqiang Niu
>
> mutex sof register offset will be private data of ddp
>
> Signed-off-by: Yongqiang Niu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 13 ++---
> 1 file changed, 10
On Thu, Jun 13, 2019 at 09:53:55AM +0200, Daniel Vetter wrote:
> On Wed, Jun 12, 2019 at 10:42:42AM -0300, Rodrigo Siqueira wrote:
> > On Thu, Jun 6, 2019 at 7:28 PM Daniel Vetter wrote:
> > >
> > > Currently we flush pending crc workers very late in the commit flow,
> > > when we destry all the
On Mon, Jun 3, 2019 at 7:19 PM Maxime Ripard wrote:
>
> On Mon, May 20, 2019 at 02:33:16PM +0530, Jagan Teki wrote:
> > Allwinner MIPI DSI controllers are supplied with SoC
> > DSI power rails via VCC-DSI pin.
> >
> > Add support for this supply pin by adding voltage
> > regulator handling code
On Wed, Jun 12, 2019 at 11:10:54PM -0300, Rodrigo Siqueira wrote:
> For historical reason, the function drm_wait_vblank_ioctl always return
> -EINVAL if something gets wrong. This scenario limits the flexibility
> for the userspace make detailed verification of the problem and take
> some action.
On Thu, Jun 13, 2019 at 09:28:13AM +0100, Liviu Dudau wrote:
> On Thu, Jun 13, 2019 at 10:17:27AM +0200, Daniel Vetter wrote:
> > On Wed, Jun 12, 2019 at 02:26:24AM +, james qian wang (Arm Technology
> > China) wrote:
> > > On Tue, Jun 11, 2019 at 02:30:38PM +0200, Daniel Vetter wrote:
> > >
Hi Dave, Daniel, on behalf of Joonas,
drm-intel-fixes-2019-06-13:
drm/i915 fixes for v5.2-rc5:
- Fix DMC firmware input validation to avoid buffer overflow
- Fix perf register access whitelist for userspace
- Fix DSI panel on GPD MicroPC
- Fix per-pixel alpha with CCS
- Fix HDMI audio for SDVO
https://bugs.freedesktop.org/show_bug.cgi?id=110904
Oleg Vasilev changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Wed, Jun 12, 2019 at 11:38:06AM -0400, Sven Van Asbroeck wrote:
> On Tue, Jun 11, 2019 at 7:04 AM Russell King
> wrote:
> >
> > Add bridge timing information so that bridge users can figure out the
> > timing parameters that are necessary for TDA998x.
> >
> > Signed-off-by: Russell King
> >
On Wed, Jun 12, 2019 at 10:38:23AM -0300, Rodrigo Siqueira wrote:
> On Thu, Jun 6, 2019 at 7:28 PM Daniel Vetter wrote:
> >
> > Plus add a comment about what it actually protects. It's very little.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Rodrigo Siqueira
> > Cc: Haneen Mohammed
> > Cc:
https://bugs.freedesktop.org/show_bug.cgi?id=110856
--- Comment #4 from Arek Tumas ---
These are the log files during Rocket League with VRR enabled.
I recorded these with kernel version 5.1.4-1-MANJARO as the 5.2 kernel is not
finished yet. If You need these with kernel 5.2-rc4 then I can also
On Wed, Jun 12, 2019 at 11:24:46AM -0400, Sven Van Asbroeck wrote:
> On Tue, Jun 11, 2019 at 7:01 AM Russell King
> wrote:
> >
> > Introduce a structure to hold the register values to be programmed while
> > programming the TDA998x audio settings. This is currently a stub
> > structure, which
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Rob Clark
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: Jeykumar Sankaran
Cc: Jordan Crouse
Cc:
On Wed, Jun 12, 2019 at 10:46:28AM -0300, Rodrigo Siqueira wrote:
> On Thu, Jun 6, 2019 at 7:28 PM Daniel Vetter wrote:
> >
> > The crc computation worker needs to be able to get at some data
> > structures and framebuffer mappings, while potentially more atomic
> > updates are going on. The
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Eric Anholt
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Greg
So there is no need to check for a value that can never happen. No need
to check the return value all anyway, as any debugfs call can take the
result of this function as an option just fine.
Cc: Thierry Reding
Cc: dri-devel@lists.freedesktop.org
Cc: linux-te...@vger.kernel.org
Signed-off-by:
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Also, because there is no need to save the file dentry, remove the local
variable and just recursively delete the
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Benjamin Gaignard
Cc: Vincent Abriou
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Alex Deucher
Cc: "Christian König"
Cc: "David (ChunMing) Zhou"
Cc: David Airlie
Cc: Daniel Vetter
Cc:
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Rob Clark
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: Jordan Crouse
Cc: Mamta Shukla
Cc: Thomas
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Rob Clark
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: linux-arm-...@vger.kernel.org
Cc:
https://bugzilla.kernel.org/show_bug.cgi?id=203879
--- Comment #2 from Michel Dänzer (mic...@daenzer.net) ---
That sounds like a general CPU related stability issue, not directly related to
the amdgpu driver.
--
You are receiving this mail because:
You are watching the assignee of the bug.
On Thu, Jun 13, 2019 at 08:18:54AM +0530, Hariprasad Kelam wrote:
> On Wed, Jun 12, 2019 at 10:35:26PM -0400, Alex Deucher wrote:
> > On Wed, Jun 12, 2019 at 10:34 PM Hariprasad Kelam
> > wrote:
> > >
> > > this patch fixes below compilation error
> > >
> > >
https://bugs.freedesktop.org/show_bug.cgi?id=110907
--- Comment #1 from Michel Dänzer ---
[ 4.187] (EE) 3: /opt/mesa-latest/x86_64/radeonsi_dri.so
(0x7f5f52ac+0x1b9335) [0x7f5f52c79335]
[ 4.187] (EE) 4: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
(0x7f5f4528c000+0x264dce)
On Wed, Jun 12, 2019 at 11:40:43AM -0400, Sven Van Asbroeck wrote:
> On Tue, Jun 11, 2019 at 7:01 AM Russell King - ARM Linux admin
> wrote:
> >
> > This series represents development work collected over the last six
> > months to improve the TDA998x driver, particularly for the audio
> > side.
https://bugs.freedesktop.org/show_bug.cgi?id=110897
--- Comment #18 from Richard Thier ---
Weird. That is exactly the same card as mine... I have less and less of an idea
when this thing happens. I will try building with various optimization fals but
it might be also that the card can get stick
Because interrupts are generated artifitially, kernel bug may lead to
infinte attempts to submit CRC.
Signed-off-by: Oleg Vasilev
---
drivers/gpu/drm/vkms/vkms_crc.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vkms/vkms_crc.c
Other drivers are able to list crc sources when accessing
/sys/kernel/debug/dri/.../crtc-0/crc/control
Even though VKMS now supports only 'auto' mode, it is more consistent to
have the list available to the userspace.
Signed-off-by: Oleg Vasilev
---
drivers/gpu/drm/vkms/vkms_crc.c | 9
Since we are logging all vblank counter updates 30 lines below,
it is also good to have some details whether and how vblank count
difference is calculated.
Signed-off-by: Oleg Vasilev
---
drivers/gpu/drm/drm_vblank.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git
On Wed, Jun 12, 2019 at 02:26:24AM +, james qian wang (Arm Technology
China) wrote:
> On Tue, Jun 11, 2019 at 02:30:38PM +0200, Daniel Vetter wrote:
> > On Tue, Jun 11, 2019 at 11:13:45AM +, Lowry Li (Arm Technology China)
> > wrote:
> > > From: "Lowry Li (Arm Technology China)"
> > >
>
https://bugs.freedesktop.org/show_bug.cgi?id=110795
Andre Klapper changed:
What|Removed |Added
Resolution|WONTFIX |INVALID
--- Comment #17 from Andre
https://bugs.freedesktop.org/show_bug.cgi?id=110897
--- Comment #15 from Richard Thier ---
(In reply to cosiekvfj from comment #14)
> Created attachment 144524 [details]
> bigger glxgears window
>
> >Is HyperZ just good without any changes to stock mesa?
> yes, mesa is from manjaro repo, and I
https://bugs.freedesktop.org/show_bug.cgi?id=110795
--- Comment #19 from Andre Klapper ---
Ah. Thanks for the correction. I'm sorry!
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
On Wed, Jun 12, 2019 at 08:24:34AM -0700, Shobhit Kukreti wrote:
> On Wed, Jun 12, 2019 at 11:26:15AM +0100, Daniel Thompson wrote:
> > Hi Shobhit
> >
> > Thanks for the patch. Feedback below...
>
> Hi Daneil,
>
> You provided some valuable feedback. Thank you for your time and
>
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: "Guido Günther"
Cc: Thierry Reding
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Tomi Valkeinen
Cc: David Airlie
Cc: Daniel Vetter
Cc: Laurent Pinchart
Cc: Sebastian Reichel
Cc: Jyri
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Ben Skeggs
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc:
Hi,
On Thu, Jun 13, 2019 at 01:57:17PM +0200, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Cc: "Guido Günther"
> Cc:
On Wed, Jun 12, 2019 at 10:42:42AM -0300, Rodrigo Siqueira wrote:
> On Thu, Jun 6, 2019 at 7:28 PM Daniel Vetter wrote:
> >
> > Currently we flush pending crc workers very late in the commit flow,
> > when we destry all the old crtc states. Unfortunately at that point
>
> destry -> destroy
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=110897
--- Comment #16 from Richard Thier ---
Btw I now have no problems at all... This is weird... all I did was to remove
my printfs so that code is actually stock mesa and I both see the speed gain
and there is no problems whatsoever...
But I
On Wed, 12 Jun 2019, Andres Rodriguez wrote:
> DisplayID blocks allow embedding of CEA blocks. The payloads are
> identical to traditional top level CEA extension blocks, but the header
> is slightly different.
>
> This change allows the CEA parser to find a CEA block inside a DisplayID
> block.
https://bugs.freedesktop.org/show_bug.cgi?id=110856
--- Comment #3 from Arek Tumas ---
Created attachment 144528
--> https://bugs.freedesktop.org/attachment.cgi?id=144528=edit
Xorg.0.log file
This is the Xorg.0.log file during a Rocket League session with kernel version
5.1.4-1-MANJARO
--
https://bugs.freedesktop.org/show_bug.cgi?id=110856
--- Comment #6 from Arek Tumas ---
Created attachment 144531
--> https://bugs.freedesktop.org/attachment.cgi?id=144531=edit
Xorg.0.log file with 5.2-rc4 kernel
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=110856
--- Comment #5 from Arek Tumas ---
Created attachment 144530
--> https://bugs.freedesktop.org/attachment.cgi?id=144530=edit
DMESG log with 5.2-rc4 kernel
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=110897
--- Comment #20 from cosiek...@o2.pl ---
>I have less and less of an idea when this thing happens.
My first thought was maybe compositor or 64 vs 32 bit os. I'm using xfwm with
compositing turned off. I also changed the CPU in this laptop ;)
On Thu, Jun 13, 2019 at 02:16:16PM +0200, Guido Günther wrote:
> Hi,
> On Thu, Jun 13, 2019 at 01:57:17PM +0200, Greg Kroah-Hartman wrote:
> > When calling debugfs functions, there is no need to ever check the
> > return value. The function can work or not, but the code logic should
> > never do
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Alex Deucher
Cc: "Christian König"
Cc: "David (ChunMing) Zhou"
Cc: David Airlie
Cc: Daniel Vetter
Cc:
On 10.06.2019 01:13, Linus Walleij wrote:
> This converts the Analogix display port to use GPIO descriptors
> instead of DT-extracted numbers.
>
> Cc: Douglas Anderson
> Cc: Sean Paul
> Cc: Marek Szyprowski
> Cc: Enric Balletbo i Serra
> Signed-off-by: Linus Walleij
Reviewed-by: Andrzej
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Oded Gabbay
Cc: Alex Deucher
Cc: "Christian König"
Cc: "David (ChunMing) Zhou"
Cc: David Airlie
Cc: Daniel
On Wed, Jun 05, 2019 at 01:17:11PM +0530, Jagan Teki wrote:
> On Tue, Jun 4, 2019 at 3:30 PM Maxime Ripard
> wrote:
> >
> > On Wed, May 29, 2019 at 11:44:56PM +0530, Jagan Teki wrote:
> > > On Wed, May 29, 2019 at 8:24 PM Maxime Ripard
> > > wrote:
> > > >
> > > > On Fri, May 24, 2019 at
On Thu, Jun 13, 2019 at 01:25:52PM +0530, Jagan Teki wrote:
> On Mon, Jun 3, 2019 at 7:19 PM Maxime Ripard
> wrote:
> >
> > On Mon, May 20, 2019 at 02:33:16PM +0530, Jagan Teki wrote:
> > > Allwinner MIPI DSI controllers are supplied with SoC
> > > DSI power rails via VCC-DSI pin.
> > >
> > >
On Wed, Jun 05, 2019 at 01:11:44PM +0530, Jagan Teki wrote:
> On Tue, Jun 4, 2019 at 8:00 PM Maxime Ripard
> wrote:
> >
> > On Fri, May 24, 2019 at 03:37:36PM +0530, Jagan Teki wrote:
> > > On Fri, May 24, 2019 at 2:18 AM Maxime Ripard
> > > wrote:
> > > >
> > > > On Mon, May 20, 2019 at
Den 13.06.2019 14.50, skrev Maxime Ripard:
> Hi,
>
> On Wed, Jun 12, 2019 at 03:21:19PM +0200, Noralf Trønnes wrote:
The only way I see for that to happen, is to set
->panel_orientation. And to repeat myself, imo that makes
'orientation' a better name for this video= option.
>>>
On Thu, Jun 13, 2019 at 7:56 AM Greg Kroah-Hartman
wrote:
>
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Cc: Alex Deucher
> Cc: "Christian König"
>
Komeda interrupts may be shared with other hardware blocks.
One needs to use devm_request_irq() with IRQF_SHARED to create a shared
interrupt handler.
As a result of not using drm_irq_install() api, one needs to set
"(struct drm_device *)->irq_enabled = true/false" to enable/disable
vblank
On 10.06.2019 00:32, Linus Walleij wrote:
> This include is only used for some gpio drivers and consumers
> that look up GPIO numbers directly from the device tree.
> This driver does not use it and only needs .
> Delete the unused include.
>
> Cc: Enric Balletbo i Serra
> Cc: Jose Abreu
>
On Fri, Jun 07, 2019 at 08:18:56PM +0200, Daniel Vetter wrote:
Hi Daniel,
> On Fri, Jun 07, 2019 at 03:03:39PM +, Ayan Halder wrote:
> > One needs to set "(struct drm_device *)->irq_enabled = true" to signal drm
> > core
> > to enable vblank interrupts after the hardware has been
Hi Da.*,
A bit more meat on this PR, which should probably be expected given how light we
have been on the last 4.
drm-misc-fixes-2019-06-13:
meson: A few G12A fixes across the driver (Neil)
quirks: A couple quirks for GPD devices (Hans)
gem_shmem: Use writecombine when vmapping non-dmabuf BOs
On Thu, 13 Jun 2019, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
From: Sean Paul
Fixes the following warning:
../drivers/gpu/drm/drm_connector.c:981: WARNING: Definition list ends without a
blank line; unexpected unindent.
Fixes: a09db883e5d9 ("drm: Fix docbook warnings in hdr metadata helper
structures")
Cc: Shashank Sharma
Cc: Ville Syrjä
Cc: Maarten
On 25.05.2019 19:59, Hariprasad Kelam wrote:
> fix below warning reported by coccicheck
>
> ./drivers/gpu/drm/bridge/analogix/analogix_dp_core.c:1414:6-8: WARNING:
> possible condition with no effect (if == else)
>
> Signed-off-by: Hariprasad Kelam
Mixed feelings about it, but:
Reviewed-by:
On Thu, Jun 13, 2019 at 03:28:50PM +0200, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
Please don't merge this patch - I have a
Hi,
This series updates Armada DRM:
- Fix interlace support.
- use __drm_atomic_helper_plane_reset in overlay reset.
- since the overlay and video planes use essentially the same format
registers, precompute their values while validating.
- fix a long-standing deficiency with overlay planes
https://bugzilla.kernel.org/show_bug.cgi?id=203879
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
https://bugs.freedesktop.org/show_bug.cgi?id=110897
--- Comment #22 from Richard Thier ---
Created attachment 144532
--> https://bugs.freedesktop.org/attachment.cgi?id=144532=edit
should not affect anything patch
Interestingly now I am running with this patch, but I never saw this code path
Le jeu. 13 juin 2019 à 13:46, Greg Kroah-Hartman
a écrit :
>
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Cc: Benjamin Gaignard
> Cc: Vincent Abriou
On 12-06-19, 13:55, Viresh Kumar wrote:
> Okay, I have applied this patch (alone) to the OPP tree with minor
> modifications in commit log and diff.
And I have removed it now :)
I am confused as hell on what we should be doing and what we are doing
right now. And if we should do better.
Let me
On Thu, Jun 13, 2019 at 03:18:01PM +0300, Oleg Vasilev wrote:
> Because interrupts are generated artifitially, kernel bug may lead to
> infinte attempts to submit CRC.
>
> Signed-off-by: Oleg Vasilev
> ---
> drivers/gpu/drm/vkms/vkms_crc.c | 10 +-
> 1 file changed, 9 insertions(+), 1
On Thu, Jun 13, 2019 at 03:09:53PM +0200, Daniel Vetter wrote:
> On Thu, Jun 13, 2019 at 02:16:16PM +0200, Guido Günther wrote:
> > Hi,
> > On Thu, Jun 13, 2019 at 01:57:17PM +0200, Greg Kroah-Hartman wrote:
> > > When calling debugfs functions, there is no need to ever check the
> > > return
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Because there is no need to check these functions, a number of local
functions can be made to return void to
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: David Airlie
Cc: Daniel Vetter
Cc:
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Because there is no need to check these functions, a number of local
functions can be made to return void to
On Thu, Jun 13, 2019 at 03:28:29PM +0200, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
I remember when writing this code and
On Thu, Jun 13, 2019 at 11:14:55AM +0200, Enric Balletbo i Serra wrote:
> Hi Matthias,
>
> On 12/6/19 20:00, Matthias Kaehlcke wrote:
> > With commit 88ba95bedb79 ("backlight: pwm_bl: Compute brightness of
> > LED linearly to human eye") the number of set bits (aka hweight())
> > in the PWM
Hi Matthias,
On 12/6/19 20:00, Matthias Kaehlcke wrote:
> With commit 88ba95bedb79 ("backlight: pwm_bl: Compute brightness of
> LED linearly to human eye") the number of set bits (aka hweight())
> in the PWM period is used in the heuristic to determine the number
> of brightness levels, when the
On Thu, Jun 13, 2019 at 03:52:22PM +0100, Liviu Dudau wrote:
> On Thu, Jun 13, 2019 at 03:28:29PM +0200, Greg Kroah-Hartman wrote:
> > When calling debugfs functions, there is no need to ever check the
> > return value. The function can work or not, but the code logic should
> > never do
On Thu, Jun 13, 2019 at 11:08:14AM +0200, Daniel Vetter wrote:
> On Thu, Jun 13, 2019 at 09:28:13AM +0100, Liviu Dudau wrote:
> > On Thu, Jun 13, 2019 at 10:17:27AM +0200, Daniel Vetter wrote:
> > > On Wed, Jun 12, 2019 at 02:26:24AM +, james qian wang (Arm Technology
> > > China) wrote:
> >
On 6/13/19 9:20 AM, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Cc: Harry Wentland
> Cc: Leo Li
> Cc: Alex Deucher
> Cc:
On Thu, Jun 13, 2019 at 03:34:39PM +0200, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Because there is no need to check
1 - 100 of 301 matches
Mail list logo