On Tue, Jun 11, 2019 at 11:54:00AM -0700, Jeffrey Hugo wrote:
> The A540 is a derivative of the A530, and is found in the MSM8998 SoC.
>
> Signed-off-by: Jeffrey Hugo
This looks correct and more importantly, it seems to work, so there is that.
Thanks for doing this; this fills in a sizable gap
On Thu, Jun 13, 2019 at 06:01:14PM +0200, Greg Kroah-Hartman wrote:
> On Thu, Jun 13, 2019 at 03:36:00PM +0100, Russell King - ARM Linux admin
> wrote:
> > 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
On Thu, Jun 13, 2019 at 3:27 AM Randy Dunlap wrote:
>
> On 6/12/19 12:00 AM, Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20190611:
> >
>
> on x86_64:
>
> ../drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c: In
> function ‘dcn10_apply_ctx_for_surface’:
>
On Thu, Jun 13, 2019 at 03:36:00PM +0100, Russell King - ARM Linux admin wrote:
> 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
>
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=110783
--- Comment #13 from Ilia Mirkin ---
(In reply to Gert Wollny from comment #12)
> Anyway, since there is already a CAP for TEX_LZ I was able to create a
> simple fix:
>https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1084
TEX_LZ ==
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=110897
Richard Thier changed:
What|Removed |Added
Severity|normal |minor
Priority|medium
https://bugs.freedesktop.org/show_bug.cgi?id=110897
--- Comment #23 from Richard Thier ---
Or can it be that literally I had a short term hardware error in my card
because of running in this hot summer for very long periods. I could be ram
corruption too that just got solved now for some reason.
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
https://bugzilla.kernel.org/show_bug.cgi?id=203879
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
The dw-hdmi-i2s supports more formats than just regular i2s.
Add support for left justified, right justified and dsp modes
A and B.
Signed-off-by: Jerome Brunet
---
Tested on the Amlogic arm64 meson-g12a-sei510 with i2s, left_j, dsp_a
and dsp_b. right_j is not supported by this platform.
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
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
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
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"
>
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, 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: Greg Kroah-Hartman
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
On Thu, Jun 13, 2019 at 03:28:06PM +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: "James (Qian) Wang"
> Cc: Liviu
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
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, 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
On Thu, Jun 13, 2019 at 02:24:37PM +0100, Liviu Dudau wrote:
> 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
This series represents development work collected over the last six
months to improve the TDA998x driver, particularly for the audio
side. These patches can be found in my "drm-tda998x-devel" branch
at git://git.armlinux.org.uk/~rmk/linux-arm.git
- Introduce an audio_settings structure so we can
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
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 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
On Tue, Jun 4, 2019 at 4:22 PM Yrjan Skrimstad wrote:
>
> On Thu, May 30, 2019 at 02:08:21AM +0200, Yrjan Skrimstad wrote:
> > This driver currently contains a repeated 500ms blocking delay call
> > which causes frequent major buffer underruns in PulseAudio. This patch
> > fixes this issue by
On Mon, 10 Jun 2019 at 18:58, Rob Herring wrote:
>
> In order to increase the chances of using 2MB pages, we need to align the
> GPU VA mapping to 2MB. Only do this if the object size is 2MB or more.
>
> Cc: Robin Murphy
> Cc: Steven Price
> Cc: Tomeu Vizoso
> Signed-off-by: Rob Herring
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:
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
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: Liviu Dudau
Cc: Brian Starkey
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: Russell King
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Greg
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: "James (Qian) Wang"
Cc: Liviu Dudau
Cc: Brian Starkey
Cc: David Airlie
Cc: Daniel Vetter
Cc:
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: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
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.
> >
> > orientation and rotation are two different
Hi,
On Wed, Jun 12, 2019 at 02:43:44PM +0200, Noralf Trønnes wrote:
> Den 11.06.2019 14.49, skrev Maxime Ripard:
> >>> + } else if (!strncmp(option, "reflect_x", delim - option)) {
> >>> + rotation |= DRM_MODE_REFLECT_X;
> >>> + sep = delim;
> >>> +
Hi,
On Wed, Jun 12, 2019 at 12:00:21PM +0200, Andrzej Hajda wrote:
> On 07.06.2019 11:40, Torsten Duwe wrote:
> > On Fri, Jun 07, 2019 at 08:28:02AM +0200, Maxime Ripard wrote:
> >> On Thu, Jun 06, 2019 at 03:59:27PM +0200, Harald Geyer wrote:
> >>> If think valid compatible properties would be:
On Fri, Jun 07, 2019 at 11:40:30AM +0200, Torsten Duwe wrote:
> On Fri, Jun 07, 2019 at 08:28:02AM +0200, Maxime Ripard wrote:
> > On Thu, Jun 06, 2019 at 03:59:27PM +0200, Harald Geyer wrote:
> > >
> > > If think valid compatible properties would be:
> > > compatible = "innolux,n116bge",
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 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.
Cc: Harry Wentland
Cc: Leo Li
Cc: Alex Deucher
Cc: "Christian König"
Cc: "David (ChunMing) Zhou"
Cc: David
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
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
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 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 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
On Thu, Jun 13, 2019 at 01:44:55PM +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.
>
> Also, because there is no need to
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 12:32:39PM +0300, Jani Nikula 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
On Tue, Jun 11, 2019 at 4:02 PM dbasehore . wrote:
>
> On Tue, Jun 11, 2019 at 8:25 AM Rob Herring wrote:
> >
> > On Mon, Jun 10, 2019 at 10:03 PM Derek Basehore
> > wrote:
> > >
> > > This adds to the rotation documentation to explain how drivers should
> > > use the property and gives an
https://bugs.freedesktop.org/show_bug.cgi?id=110897
--- Comment #21 from cosiek...@o2.pl ---
No wait. That reminds me of this weird behavior I had in
https://bugs.freedesktop.org/show_bug.cgi?id=101382
17.1.2-1 crash(different)
17.1.1-1 crash(different)
17.1.0-1 crash(different)
17.0.5-1 working
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 ;)
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:
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:
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
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
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
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
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:
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:
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: "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: Alex Deucher
Cc: "Christian König"
Cc: "David (ChunMing) Zhou"
Cc: David Airlie
Cc: Daniel Vetter
Cc:
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
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
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: 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
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=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
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=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
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
>
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=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 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
> >
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 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
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
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
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|---
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
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
--
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 #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
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:
> > >
101 - 200 of 301 matches
Mail list logo
