On Wed, 18 Jul 2018 22:54:35 +0200,
Pierre-Louis Bossart wrote:
>
>
>
> On 07/17/2018 04:26 AM, Takashi Iwai wrote:
> > Hi,
> >
> > this is a preliminiary patch set to convert the existing i915 /
> > HD-audio component binding to be applicable to other drivers like
> > radeon / amdgpu. This pat
On 16-Jul-18 17:43, Sandeep Panda wrote:
> Add support for TI's sn65dsi86 dsi2edp bridge chip.
> The chip converts DSI transmitted signal to eDP signal,
> which is fed to the connected eDP panel.
>
> This chip can be controlled via either i2c interface or
> dsi interface. Currently in driver all th
Hi Lee,
Today's linux-next merge of the mfd tree got a conflict in:
drivers/gpu/drm/i915/intel_display.h
between commit:
ac213c1b45f7 ("drm/i915/icl: introduce tc_port")
from the drm tree and commit:
9c229127aee2 ("drm/i915: hdmi: add CEC notifier to intel_hdmi")
from the mfd tree.
I
On Tue, Jul 17, 2018 at 01:11:14PM +0200, Thomas Zimmermann wrote:
> This patch unifies the naming of DRM functions for reference counting
> of struct drm_device. The resulting code is more aligned with the rest
> of the Linux kernel interfaces.
>
> Signed-off-by: Thomas Zimmermann
Acked-by: Sha
Currently, vkms shows an error message if the following steps occur: (1)
load vkms, (2) perform any specific operation in the vkms (e.g., run an
IGT test), and (3) unload the module. The following error message
emerges:
[drm:drm_mode_config_cleanup [drm]] *ERROR* connector Virtual-1 leaked!
This
https://bugs.freedesktop.org/show_bug.cgi?id=107224
Timothy Arceri changed:
What|Removed |Added
QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
On Wed, 2018-07-18 at 16:07 -0700, Rodrigo Vivi wrote:
> On Wed, Jul 18, 2018 at 05:57:16PM -0400, Lyude Paul wrote:
> > This isn't supposed to take dev as an argument, I guess no one noticed!
>
> Apparently no one using it... Why don't we just kill it?
Yeah-I've got plans to hopefully use this a
On Wed, Jul 18, 2018 at 05:57:16PM -0400, Lyude Paul wrote:
> This isn't supposed to take dev as an argument, I guess no one noticed!
Apparently no one using it... Why don't we just kill it?
>
> Signed-off-by: Lyude Paul
anyways, if you prefer to keep or have plans to use:
Reviewed-by: Rodrig
On Tue, Jul 17, 2018 at 02:49:38PM -0700, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood
>
> This bit was added to DP Training Aux RD interval sometime between DP
> 1.2 and DP 1.3. Via description of the spec this field indicates the
> panels true capabilities are described in DPCD address
This isn't supposed to take dev as an argument, I guess no one noticed!
Signed-off-by: Lyude Paul
---
include/drm/drm_print.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 767c90b654c5..fc08584a5101 100644
--- a/includ
On Wed, Jul 18, 2018 at 10:11 PM, Lyude Paul wrote:
> On Wed, 2018-07-18 at 10:36 +0200, Lukas Wunner wrote:
>> On Wed, Jul 18, 2018 at 10:25:05AM +0200, Lukas Wunner wrote:
>> > The GPU contains an i2c subdevice for each connector with DDC lines.
>> > I believe those are modelled as children of t
I think that is an issue with your client? It seems to come up fine if I apply
it locally and look at it with gvim
On Tue, 2018-07-17 at 12:25 +0200, Karol Herbst wrote:
> isn't there like 1 space missing for each change? Or maybe my client
> is messed up, but please align it with the first letter
Hi Paul,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on sunxi/sunxi/for-next]
[also build test ERROR on v4.18-rc5 next-20180718]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
When DP MST hubs get confused, they can occasionally stop responding for
a good bit of time up until the point where the DRM driver manages to
do the right DPCD accesses to get it to start responding again. In a
worst case scenario however, this process can take upwards of 10+
seconds.
Currently w
For nouveau, while the GPU is guaranteed to be on when a hotplug has
been received, the same assertion does not hold true if a connector
probe has been started by userspace without having had received a sysfs
event.
So ensure that any connector probing keeps the GPU alive for the
duration of the p
This is a trimmed down version of
https://patchwork.freedesktop.org/series/46637/
with all of the review comments addressed.
The last version of this series had fixes for the i2c and DP aux busses
to ensure that the GPU would be turned on whenever anything tried to
access the i2c/aux busses. Unf
Hello Krzysztof,
looks good to me!
Reviewed-by: Tobias Jakobi
- Tobias
Krzysztof Kozlowski wrote:
> Remove local variable 'priv' to fix GCC warning:
>
> drivers/gpu/drm/exynos/exynos_mixer.c: In function 'mixer_initialize':
> drivers/gpu/drm/exynos/exynos_mixer.c:840:29: warning: var
On Wed, 2018-07-18 at 10:36 +0200, Lukas Wunner wrote:
> On Wed, Jul 18, 2018 at 10:25:05AM +0200, Lukas Wunner wrote:
> > The GPU contains an i2c subdevice for each connector with DDC lines.
> > I believe those are modelled as children of the GPU's PCI device as
> > they're accessed via mmio of th
Hi Dave,
Another round for 4.19. Fixes the build issue for sun4i. Many fixes and
improvements, most interesting thing is probably the DisplayPort
CEC-Tunneling-over-AUX support. Please pull, thanks.
drm-misc-next-2018-07-18:
drm-misc-next for 4.19:
Core Changes:
- add support for DisplayPort CEC
Remove local variable 'priv' to fix GCC warning:
drivers/gpu/drm/exynos/exynos_mixer.c: In function 'mixer_initialize':
drivers/gpu/drm/exynos/exynos_mixer.c:840:29: warning: variable 'priv' set
but not used [-Wunused-but-set-variable]
Signed-off-by: Krzysztof Kozlowski
---
drivers/gpu
Hi Thomas,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on sof-driver-fuweitax/master]
[also build test ERROR on v4.18-rc5 next-20180718]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com
Use the stronger compiler.link() test (instead of the weaker
compiler.compile()) to fix the intel atomics detection.
Fixes false positive in case of sparc compile (buildroot toolchain).
Signed-off-by: Peter Seiderer
---
Changes v1 -> v2:
- link test needs main() method
---
meson.build | 3 ++-
Use meson library instead of shared_library to enable static build.
Signed-off-by: Peter Seiderer
---
Changes v1 -> v2:
- new patch
---
amdgpu/meson.build| 2 +-
etnaviv/meson.build | 2 +-
exynos/meson.build| 2 +-
freedreno/meson.build | 2 +-
intel/meson.build | 2 +-
libkms/m
Hi Thomas,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on sof-driver-fuweitax/master]
[also build test ERROR on v4.18-rc5 next-20180718]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com
On Wed, Jul 18, 2018 at 07:24:34PM +0300, Haneen Mohammed wrote:
> First, just so you have the complete view, this is the missing part in this
> patch:
> -- vkms_crc.c
> static uint32_t _vkms_get_crc(struct vkms_crc_data *crc_data)
> {
> struct drm_framebuffer *fb = &crc_data->fb;
>
https://bugs.freedesktop.org/show_bug.cgi?id=102962
--- Comment #12 from Tobias Auerochs ---
(In reply to Timothy Arceri from comment #11)
> (In reply to gloriouseggroll from comment #9)
> > Created attachment 138466 [details]
> > broken colors with mesa override
> >
> > This was originally able
https://bugs.freedesktop.org/show_bug.cgi?id=107277
Paul Menzel changed:
What|Removed |Added
Status|NEEDINFO|NEW
--- Comment #6 from Paul Menzel ---
On Tue, Jul 17, 2018 at 3:59 AM, Dmitry Safonov wrote:
> I would be glad if someone helps/bothers to review the change :C
>
Perhaps Petr and / or Steven can help you.
> Thanks,
> Dmitry
>
> On Tue, 2018-07-03 at 23:56 +0100, Dmitry Safonov wrote:
>> Currently ratelimit_state is protected with sp
On Thu, Jul 12, 2018 at 08:40:55PM +0100, Chris Wilson wrote:
> Quoting Jordan Crouse (2018-07-12 19:59:19)
> > Add a drm printer suitable for use with the read callback for
> > devcoredump or other suitable buffer based output format that
> > isn't otherwise covered by seq_file.
> >
> > Signed-of
On Wed, Jul 18, 2018 at 04:55:44PM +0100, Lee Jones wrote:
> On Wed, 18 Jul 2018, Daniel Thompson wrote:
>
> > On Wed, Jul 18, 2018 at 02:08:53PM +0100, Lee Jones wrote:
> > > > > > > No, then we are back to the initial issue of num_steps
> > > > > > > potentially not
> > > > > > > being initialis
Hi Dave,
Fixes for 4.18. The ACP patch is a bit bigger than I would like
at this point, but it should have gone in long ago, it just fell
through the cracks. The others are pretty small and straight-forward.
- ACP fix for boards with 2 I2S instances
- DP fix for CZ, vega
- Fix for a hybrid graph
On Wed, 18 Jul 2018, Daniel Thompson wrote:
> On Wed, Jul 18, 2018 at 02:08:53PM +0100, Lee Jones wrote:
> > > > > > No, then we are back to the initial issue of num_steps
> > > > > > potentially not
> > > > > > being initialised. We really want both of_property_read_u32() to
> > > > > > succeed A
https://bugs.freedesktop.org/show_bug.cgi?id=107261
Paul Menzel changed:
What|Removed |Added
CC||pmenzel+bugs.freedesktop@mo
https://bugs.freedesktop.org/show_bug.cgi?id=107277
--- Comment #5 from Alex Deucher ---
Created attachment 140702
--> https://bugs.freedesktop.org/attachment.cgi?id=140702&action=edit
quick hack for s#
Here's a quick hack for S3, but it will need more work to not break S4 support
as well.
--
https://bugs.freedesktop.org/show_bug.cgi?id=107277
Alex Deucher changed:
What|Removed |Added
Attachment #140702|quick hack for s# |quick hack for S3
description|
https://bugs.freedesktop.org/show_bug.cgi?id=107277
--- Comment #4 from Alex Deucher ---
(In reply to Paul Menzel from comment #3)
> (In reply to Christian König from comment #2)
> > There isn't much you can do here:
> > > amdgpu_bo_evict_vram [amdgpu] (306.331 ms @ 74.694620)
> >
> > This is ev
https://bugs.freedesktop.org/show_bug.cgi?id=107277
Alex Deucher changed:
What|Removed |Added
Severity|normal |enhancement
--
You are receiving this m
https://bugs.freedesktop.org/show_bug.cgi?id=107278
Alex Deucher changed:
What|Removed |Added
Severity|normal |enhancement
--
You are receiving this m
On Wed, Jul 18, 2018 at 11:35:23AM +0200, Paul Kocialkowski wrote:
> On Wed, 2018-07-18 at 11:29 +0200, Paul Kocialkowski wrote:
> > Not all sunxi platforms with the first version of the Display Engine
> > support an alpha component on the plane with the lowest z position
> > (as in: lowest z-pos),
https://bugs.freedesktop.org/show_bug.cgi?id=107277
--- Comment #3 from Paul Menzel ---
(In reply to Christian König from comment #2)
> There isn't much you can do here:
> > amdgpu_bo_evict_vram [amdgpu] (306.331 ms @ 74.694620)
>
> This is evacuating the content of VRAM to RAM/disk to make sure
https://bugzilla.kernel.org/show_bug.cgi?id=200517
--- Comment #14 from Alex Deucher (alexdeuc...@gmail.com) ---
On the GPU side, we are working on enabling gfxoff and stutter mode which
should save some additional power. They are not enabled by default yet, but
should be in the near future. For
https://bugs.freedesktop.org/show_bug.cgi?id=107277
Christian König changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #2 from Christia
g to improve:
[auto build test WARNING on sof-driver-fuweitax/master]
[also build test WARNING on v4.18-rc5 next-20180718]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/matthias-bgg-kernel-o
https://bugzilla.kernel.org/show_bug.cgi?id=200517
--- Comment #13 from bakarichar...@gmail.com ---
That is clear, thanks.
Another topic, you seems to be competent to ask your opinion: what do you think
why are my gpu and cpu core temps ~5-8C higher than on Windows 10. This is the
best what open/
t WARNING on v4.18-rc5 next-20180718]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/matthias-bgg-kernel-org/arm-arm64-mediatek-Fix-mmsys-device-probing/20180718-191916
base: https://github.com/fu
Hi Eric,
Thanks for your reply back in April. I have finally found some time to
get back to this.
On 18 April 2018 at 03:43, Eric Anholt wrote:
> Joel Stanley writes:
>
>> This driver is for the ASPEED BMC SoC's GFX display hardware. This
>> driver runs on the ARM based BMC systems, unlike the
https://bugs.freedesktop.org/show_bug.cgi?id=107278
Paul Menzel changed:
What|Removed |Added
CC||pmenzel+bugs.freedesktop@mo
https://bugs.freedesktop.org/show_bug.cgi?id=107278
Bug ID: 107278
Summary: Raven: pci_pm_resume takes over 1 second
Product: DRI
Version: DRI git
Hardware: Other
OS: All
Status: NEW
Severity: normal
https://bugs.freedesktop.org/show_bug.cgi?id=107277
Paul Menzel changed:
What|Removed |Added
CC||pmenzel+bugs.freedesktop@mo
https://bugs.freedesktop.org/show_bug.cgi?id=107277
Bug ID: 107277
Summary: Raven: pci_pm_suspend takes over 1 second
Product: DRI
Version: DRI git
Hardware: Other
OS: All
Status: NEW
Severity: normal
On Wed, Jul 18, 2018 at 01:15:40PM +0300, Ville Syrj?l? wrote:
Hi Ville,
> On Tue, Jul 17, 2018 at 06:13:46PM +0100, Ayan Kumar Halder wrote:
> > drm_format_info table has a field 'is_yuv' to denote if the format
> > is yuv or not. The driver is expected to use this instead of
> > having a functio
https://bugs.freedesktop.org/show_bug.cgi?id=107266
--- Comment #5 from robert ---
So I stripped this down, and the ring error pops up after I've applied a new
pp_table and start utilizing the GPU.
My guess is this error has something to do with why this doesnt work in
drm-next-4.19-wip
[2
https://bugzilla.kernel.org/show_bug.cgi?id=200517
--- Comment #12 from Alex Deucher (alexdeuc...@gmail.com) ---
If you are using X, you need to use xrandr to setup the dGPU for render
offload. E.g., see:
https://wiki.archlinux.org/index.php/PRIME
or similar pages.
--
You are receiving this mai
https://bugs.freedesktop.org/show_bug.cgi?id=107266
--- Comment #4 from robert ---
No, I wasnt running ROCm userland.
I've been using amdgpu-pro-18.20-606296 for several weeks with the fkxamd
kernel as recommened by Felix.
When I remove all userland, I dont see the ring sdma0 timeout. Without
https://bugs.freedesktop.org/show_bug.cgi?id=107266
--- Comment #3 from robert ---
Created attachment 140697
--> https://bugs.freedesktop.org/attachment.cgi?id=140697&action=edit
dmesg.amdgpupro.txt
Polaris radeon pro duo, dmesg with amdgpu-pro 18.20-606296
--
You are receiving this mail bec
https://bugs.freedesktop.org/show_bug.cgi?id=107266
--- Comment #2 from robert ---
Created attachment 140696
--> https://bugs.freedesktop.org/attachment.cgi?id=140696&action=edit
dmesg.base.txt
Polaris radeon pro duo, dmesg with no userland.
--
You are receiving this mail because:
You are th
https://bugs.freedesktop.org/show_bug.cgi?id=105684
--- Comment #32 from Paul Menzel ---
I am also seeing this with Linux 4.18-rc5+ on a MSI MS-7A37/B350M MORTAR.
```
19.940: [0.072004] ACPI BIOS Error (bug): Failure creating [\_SB.SMIC],
AE_ALREADY_EXISTS (20180531/dswload2-316)
19.939: [
On Wed, Jul 18, 2018 at 02:08:53PM +0100, Lee Jones wrote:
> > > > > No, then we are back to the initial issue of num_steps
> > > > > potentially not
> > > > > being initialised. We really want both of_property_read_u32() to
> > > > > succeed AND num_steps to actually be set.
> > > >
> > > > I als
On Tue, Jul 17, 2018 at 08:02:46AM -0600, Rob Herring wrote:
> On Tue, Jul 17, 2018 at 1:47 AM Linus Walleij
> wrote:
> >
> > On Tue, Jul 17, 2018 at 12:50 AM Rob Herring wrote:
> > > On Mon, Jul 16, 2018 at 3:23 AM Linus Walleij
> > > wrote:
> >
> > > > +Video Graphics Array
> > >
> > > VGA i
On Wed, 18 Jul 2018, Marcel Ziswiler wrote:
> On Wed, 2018-07-18 at 11:12 +0100, Daniel Thompson wrote:
> > On Wed, Jul 18, 2018 at 10:53:35AM +0100, Lee Jones wrote:
> > > On Wed, 18 Jul 2018, Marcel Ziswiler wrote:
> > >
> > > > On Wed, 2018-07-18 at 09:09 +0100, Lee Jones wrote:
> > > > > On M
On Wed, Jul 18, 2018 at 04:24:40PM +0530, Jagan Teki wrote:
> Allwinner A64 has display engine pipeline like other Allwinner SOC's
> A83T/H3/H5.
>
> A64 behaviour similar to Allwinner A83T where
> Mixer0 => TCON0 => LVDS/RGB/MIPI-DSI
> Mixer1 => TCON1 => HDMI
> as per Display System Block Diagram
https://bugs.freedesktop.org/show_bug.cgi?id=104790
--- Comment #6 from lei.p...@gmail.com ---
It doesn't matter how I enabled it, results are the same.
However, I tested now, with Mesa 18.1.4 and it does not crash applications that
were crashing before, everything seems to work fine with any Ope
https://bugs.freedesktop.org/show_bug.cgi?id=107273
Bug ID: 107273
Summary: [Intel GFX CI] amdgpu :01:00.0: HDMI-A-1: EDID is
invalid
Product: DRI
Version: XOrg git
Hardware: Other
OS: All
St
On Wed, Jul 18, 2018 at 6:54 PM, Jagan Teki wrote:
> Allwinner A64 has display engine pipeline like other Allwinner SOC's
> A83T/H3/H5.
>
> A64 behaviour similar to Allwinner A83T where
> Mixer0 => TCON0 => LVDS/RGB/MIPI-DSI
> Mixer1 => TCON1 => HDMI
> as per Display System Block Diagram from All
Patch has been applied to our internal amd-staging-drm-next tree.
Thanks.
Best Regards
Rex
From: Christian K?nig
Sent: Tuesday, July 17, 2018 2:58:21 PM
To: Zhu, Rex; Kees Cook; Deucher, Alexander
Cc: Zhou, David(ChunMing); David Airlie; Kuehling, Felix; LKML
On Wed, Jul 18, 2018 at 10:12:02AM +0100, Brian Starkey wrote:
> Hi Ayan,
>
> On Tue, Jul 17, 2018 at 06:13:42PM +0100, Ayan Kumar Halder wrote:
> >A lot of drivers duplicate the function to check if a format is yuv or not.
> >If we add a field (to denote whether the format is yuv or not) in the
>
On Tue, Jul 17, 2018 at 06:13:45PM +0100, Ayan Kumar Halder wrote:
> drm_format_info table has a field 'is_yuv' to denote if the format
> is yuv or not. The driver is expected to use this instead of
> having a function for the same purpose.
>
> Signed-off-by: Ayan Kumar halder
> ---
> drivers/gp
On Tue, Jul 17, 2018 at 06:13:46PM +0100, Ayan Kumar Halder wrote:
> drm_format_info table has a field 'is_yuv' to denote if the format
> is yuv or not. The driver is expected to use this instead of
> having a function for the same purpose.
>
> Signed-off-by: Ayan Kumar halder
> ---
> drivers/gp
On Wed, Jul 18, 2018 at 10:53:35AM +0100, Lee Jones wrote:
> On Wed, 18 Jul 2018, Marcel Ziswiler wrote:
>
> > On Wed, 2018-07-18 at 09:09 +0100, Lee Jones wrote:
> > > On Mon, 16 Jul 2018, Daniel Thompson wrote:
> > >
> > > > Currently, if the DT does not define num-interpolated-steps then
> > >
+ MM Team.
On 18/07/18 09:55, Laurent Pinchart wrote:
> Hi Kieran,
>
> On Tuesday, 17 July 2018 23:32:56 EEST Kieran Bingham wrote:
>> On 17/07/18 14:51, Laurent Pinchart wrote:
>>> On Monday, 16 July 2018 20:20:30 EEST Kieran Bingham wrote:
On 24/05/18 12:50, Laurent Pinchart wrote:
> O
On Wed, 18 Jul 2018, Marcel Ziswiler wrote:
> On Wed, 2018-07-18 at 09:09 +0100, Lee Jones wrote:
> > On Mon, 16 Jul 2018, Daniel Thompson wrote:
> >
> > > Currently, if the DT does not define num-interpolated-steps then
> > > num_steps is undefined and the interpolation code will deploy
> > > ra
On Wed, 2018-07-18 at 11:29 +0200, Paul Kocialkowski wrote:
> Not all sunxi platforms with the first version of the Display Engine
> support an alpha component on the plane with the lowest z position
> (as in: lowest z-pos), that gets blended with the background color.
>
> In particular, the A13 i
Hi,
On 18-07-18 11:30, Thomas Zimmermann wrote:
If the console is unlocked during registration, the console subsystem
generates significant amounts of warnings, which obfuscate actual
debugging messages. Setting ignore_console_lock_warning while debugging
console registration avoid the noise.
v
Not all sunxi platforms with the first version of the Display Engine
support an alpha component on the plane with the lowest z position
(as in: lowest z-pos), that gets blended with the background color.
In particular, the A13 is known to have this limitation. However, it was
recently discovered t
If the console is unlocked during registration, the console subsystem
generates significant amounts of warnings, which obfuscate actual
debugging messages. Setting ignore_console_lock_warning while debugging
console registration avoid the noise.
v2:
- restore ignore_console_lock_warning if
Hi,
this is a follow-up patch for the recent addition of
'ignore_console_lock_warning' to the console module [1] and should probably
go through the same tree. When debugging fbdev console registration, the
console-lock warnings will now be disabled temporarily.
Best regards
Thomas
[1] https://ma
o exported via tools/include/uapi/drm/drm.h so
changing the typedef of drm_context_t could break applications and thus
this is not an option.
Patch was compile tested with: x86_64_defconfig
Patch is against 4.18-rc5 (localversion-next is next-20180718)
drivers/gpu/drm/drm_context.c | 13
Am 18.07.2018 um 10:44 schrieb Hans de Goede:
> Hi,
>
> On 18-07-18 10:36, Thomas Zimmermann wrote:
>> If the console is unlocked during registration, the console subsystem
>> generates significant amounts of warnings, which obfuscate actual
>> debugging messages. Setting ignore_console_lock_warn
Hi Ayan,
On Tue, Jul 17, 2018 at 06:13:42PM +0100, Ayan Kumar Halder wrote:
A lot of drivers duplicate the function to check if a format is yuv or not.
If we add a field (to denote whether the format is yuv or not) in the
drm_format_info table, all the drivers can use this field and it will
prev
Hi Kieran,
On Tuesday, 17 July 2018 23:32:56 EEST Kieran Bingham wrote:
> On 17/07/18 14:51, Laurent Pinchart wrote:
> > On Monday, 16 July 2018 20:20:30 EEST Kieran Bingham wrote:
> >> On 24/05/18 12:50, Laurent Pinchart wrote:
> >>> On Thursday, 3 May 2018 16:36:22 EEST Kieran Bingham wrote:
> >
Hi,
On 18-07-18 10:36, Thomas Zimmermann wrote:
If the console is unlocked during registration, the console subsystem
generates significant amounts of warnings, which obfuscate actual
debugging messages. Setting ignore_console_lock_warning while debugging
console registration avoid the noise.
S
Hi,
this is a follow-up patch for the recent addition of
'ignore_console_lock_warning' to the console module [1] and should probably
go through the same tree. When debugging fbdev console registration, the
console-lock warnings will now be disabled temporarily.
Best regards
Thomas
[1] https://ma
If the console is unlocked during registration, the console subsystem
generates significant amounts of warnings, which obfuscate actual
debugging messages. Setting ignore_console_lock_warning while debugging
console registration avoid the noise.
Signed-off-by: Thomas Zimmermann
---
drivers/video
On Wed, Jul 18, 2018 at 10:25:05AM +0200, Lukas Wunner wrote:
> The GPU contains an i2c subdevice for each connector with DDC lines.
> I believe those are modelled as children of the GPU's PCI device as
> they're accessed via mmio of the PCI device.
>
> The problem here is that when the GPU's PCI
On Wed, Jul 18, 2018 at 10:25 AM, Lukas Wunner wrote:
> On Wed, Jul 18, 2018 at 09:38:41AM +0200, Rafael J. Wysocki wrote:
>> On Tue, Jul 17, 2018 at 8:20 PM, Lukas Wunner wrote:
>> > Okay, the PCI device is suspending and the nvkm_i2c_aux_acquire()
>> > wants it in resumed state, so is waiting f
On Wed, Jul 18, 2018 at 09:09:13AM +0100, Lee Jones wrote:
> On Mon, 16 Jul 2018, Daniel Thompson wrote:
>
> > Currently, if the DT does not define num-interpolated-steps then
> > num_steps is undefined and the interpolation code will deploy randomly.
> > Fix this.
> >
> > Fixes: 573fe6d1c25c ("b
On Wed, Jul 18, 2018 at 09:38:41AM +0200, Rafael J. Wysocki wrote:
> On Tue, Jul 17, 2018 at 8:20 PM, Lukas Wunner wrote:
> > Okay, the PCI device is suspending and the nvkm_i2c_aux_acquire()
> > wants it in resumed state, so is waiting forever for the device to
> > runtime suspend in order to res
Hi,
On Tue, 2018-07-17 at 14:25 +0200, Maxime Ripard wrote:
> On Tue, Jul 17, 2018 at 10:52:30AM +0200, Paul Kocialkowski wrote:
> > Not all sunxi platforms with the first version of the Display Engine
> > support an alpha component on the plane with the lowest z position
> > (as in: lowest z-pos)
Am 12.07.2018 um 15:29 schrieb Steven Rostedt:
>
> From: Steven Rostedt (VMware)
>
> There's been discussion on the fb list about the addition of
> WARN_CONSOLE_UNLOCKED() inside the fb code. The complaint is that when
> the fb module is loaded with lockless_register_fb the console lock is
> n
On Wed, 18 Jul 2018, Lee Jones wrote:
> On Mon, 16 Jul 2018, Daniel Thompson wrote:
>
> > Currently, if the DT does not define num-interpolated-steps then
> > num_steps is undefined and the interpolation code will deploy randomly.
> > Fix this.
> >
> > Fixes: 573fe6d1c25c ("backlight: pwm_bl: Li
On Mon, 16 Jul 2018, Daniel Thompson wrote:
> Currently, if the DT does not define num-interpolated-steps then
> num_steps is undefined and the interpolation code will deploy randomly.
> Fix this.
>
> Fixes: 573fe6d1c25c ("backlight: pwm_bl: Linear interpolation between
> brightness-levels")
> Re
Hi Sean,
On Wednesday, 18 July 2018 05:57:35 EEST Sean Wang wrote:
> On Wed, 2018-07-18 at 00:03 +0200, matthias@kernel.org wrote:
> > From: Matthias Brugger
> >
> > The MMSYS subsystem includes clocks and drm components.
> > This patch adds an initailization path through a platform device
>
On Tue, Jul 17, 2018 at 02:34:47PM -0400, Lyude Paul wrote:
> On Tue, 2018-07-17 at 20:32 +0200, Lukas Wunner wrote:
> > On Tue, Jul 17, 2018 at 02:24:31PM -0400, Lyude Paul wrote:
> > > On Tue, 2018-07-17 at 20:20 +0200, Lukas Wunner wrote:
> > > > Okay, the PCI device is suspending and the nvkm_i
On Tue, Jul 17, 2018 at 8:34 PM, Lyude Paul wrote:
> On Tue, 2018-07-17 at 20:32 +0200, Lukas Wunner wrote:
>> On Tue, Jul 17, 2018 at 02:24:31PM -0400, Lyude Paul wrote:
>> > On Tue, 2018-07-17 at 20:20 +0200, Lukas Wunner wrote:
>> > > Okay, the PCI device is suspending and the nvkm_i2c_aux_acqu
On Tue, Jul 17, 2018 at 8:20 PM, Lukas Wunner wrote:
> On Tue, Jul 17, 2018 at 12:53:11PM -0400, Lyude Paul wrote:
>> On Tue, 2018-07-17 at 09:16 +0200, Lukas Wunner wrote:
>> > On Mon, Jul 16, 2018 at 07:59:25PM -0400, Lyude Paul wrote:
>> > > In order to fix all of the spots that need to have ru
https://bugzilla.kernel.org/show_bug.cgi?id=200531
--- Comment #3 from Alexander Mezin (mezin.alexan...@gmail.com) ---
Created attachment 277393
--> https://bugzilla.kernel.org/attachment.cgi?id=277393&action=edit
dmesg with BUG: unable to handle kernel NULL pointer dereference
--
You are rece
https://bugzilla.kernel.org/show_bug.cgi?id=200531
--- Comment #2 from Alexander Mezin (mezin.alexan...@gmail.com) ---
Also got "BUG: unable to handle kernel NULL pointer dereference". Happened when
waking the display from suspend (the system itself wasn't suspended, because of
https://bugzilla.ke
On Wed, 2018-07-18 at 00:03 +0200, matthias@kernel.org wrote:
> From: Matthias Brugger
>
> It can happen that the clock drivers wasn't probed before the
> ddp driver gets invoked. The driver used to omit a warning
> that the driver failed to get the clocks. Omit this error on
> the defered pr
Try a bit harder to produce a devcoredump when things go wrong. If we
fail to allocate the memory for a dump including the actual bo contents,
omit the bos and try again. Capturing some information from the GPU is
better than having no information.
Signed-off-by: Russell King
---
drivers/gpu/d
From: Kieran Bingham
VSPD and VSP-DL devices can provide extended display lists supporting
extended command display list objects.
These extended commands require their own dma memory areas for a header
and body specific to the command type.
Implement a command pool to allocate all necessary mem
1 - 100 of 133 matches
Mail list logo
