Am 11.07.2017 um 04:36 schrieb Michel Dänzer:
On 11/07/17 06:09 AM, Jason Ekstrand wrote:
On Mon, Jul 10, 2017 at 9:15 AM, Christian König
mailto:deathsim...@vodafone.de>> wrote:
Am 10.07.2017 um 17:52 schrieb Jason Ekstrand:
On Mon, Jul 10, 2017 at 8:45 AM, Christian König
mail
On Mon, Jul 10, 2017 at 02:09:42PM -0700, Jason Ekstrand wrote:
> On Mon, Jul 10, 2017 at 9:15 AM, Christian König
> wrote:
>
> > Am 10.07.2017 um 17:52 schrieb Jason Ekstrand:
> >
> > On Mon, Jul 10, 2017 at 8:45 AM, Christian König
> > wrote:
> >
> >> Am 10.07.2017 um 17:28 schrieb Jason Ekstr
https://bugs.freedesktop.org/show_bug.cgi?id=101731
--- Comment #5 from Philipp Überbacher ---
I've managed to install amdgpu-pro and that has brought me a bit closer to
narrowing this down. Just for reference, the software versions are amdgpu-pro
17.10.401251-2 and related packages
(https://aur.
https://bugs.freedesktop.org/show_bug.cgi?id=101731
--- Comment #6 from Philipp Überbacher ---
Created attachment 132604
--> https://bugs.freedesktop.org/attachment.cgi?id=132604&action=edit
console output when replaying the apitrace of a crash
--
You are receiving this mail because:
You are
On Tue, Jul 11, 2017 at 01:57:10PM +0900, Sergey Senozhatsky wrote:
> On (07/11/17 11:31), Sergey Senozhatsky wrote:
> [..]
> > (replying to both Petr and Daniel)
> >
> > interesting direction, gents.
> >
> > and this is what I thought about over the weekend; it's very sketchy and
> > I didn't sp
On Mon, Jul 10, 2017 at 09:56:20PM +0200, Alexandru Moise wrote:
> On Mon, Jul 10, 2017 at 08:00:37PM +0200, Daniel Vetter wrote:
> > On Mon, Jul 10, 2017 at 9:14 AM, Alexandru Moise
> > <00moses.alexande...@gmail.com> wrote:
> > > On Mon, Jul 10, 2017 at 08:52:46AM +0200, Daniel Vetter wrote:
> >
On Mon, Jul 10, 2017 at 03:47:54PM -0700, John Stultz wrote:
> On Mon, Jul 10, 2017 at 2:18 PM, Sean Paul wrote:
> > On Mon, Jul 10, 2017 at 01:48:02PM -0700, John Stultz wrote:
> >> Currently the hikey dsi logic cannot generate accurate byte
> >> clocks values for all pixel clock values. Thus if
On Thu, Jul 06, 2017 at 02:20:35PM +0200, Peter Rosin wrote:
> While at it, add some words in the kernel-doc about the 'replaced' arg and
> remove a faulty kernel-doc comment on the return value.
>
> Also remove a redundant return statement.
>
> Signed-off-by: Peter Rosin
> ---
> drivers/gpu/dr
On Thu, Jul 06, 2017 at 02:20:36PM +0200, Peter Rosin wrote:
> Do not waste cycles looking up the property id when we have the
> actual property already.
>
> Signed-off-by: Peter Rosin
With the names adjusted per my comments on patch 1 this lgtm. Btw good
practice is to cc original authors of th
On Thu, Jul 06, 2017 at 02:20:37PM +0200, Peter Rosin wrote:
> The legacy path implements setcmap in terms of crtc .gamma_set.
>
> The atomic path implements setcmap by directly updating the crtc gamma_lut
> property.
>
> This has a couple of benefits:
> - it makes the redundant fb helpers .load_
On Thu, Jul 06, 2017 at 02:20:48PM +0200, Peter Rosin wrote:
> Drivers no longer have any need for these callbacks, and there are no
> users. Zap. Zap-zap-zzzap-p-pp-p.
>
> Signed-off-by: Peter Rosin
On patches 4-14: Acked-by: Daniel Vetter
I'll try to haggle for a few more reviews by maintain
Am 11.07.2017 um 08:49 schrieb Dave Airlie:
On 7 July 2017 at 19:07, Christian König wrote:
Hi Dave,
on first glance that looks rather good to me, but there is one things I
don't really like and I strongly think Marek will absolutely agree on that:
When we add a new CS function then let's get
On 11 July 2017 at 18:36, Christian König wrote:
> Am 11.07.2017 um 08:49 schrieb Dave Airlie:
>>
>> On 7 July 2017 at 19:07, Christian König wrote:
>>>
>>> Hi Dave,
>>>
>>> on first glance that looks rather good to me, but there is one things I
>>> don't really like and I strongly think Marek wi
Instead check info->ops->owner, which amounts to the same.
Spotted because I want to remove the pile of broken and cargo-culted
fb_info->flags assignments in drm drivers.
v2: Fixup matrox (reported by kbuild). Also nuke FBINFO_FLAG_* defines
that I've failed to spot.
Cc: Bartlomiej Zolnierkiewic
Am 11.07.2017 um 11:20 schrieb Dave Airlie:
On 11 July 2017 at 18:36, Christian König wrote:
Am 11.07.2017 um 08:49 schrieb Dave Airlie:
On 7 July 2017 at 19:07, Christian König wrote:
Hi Dave,
on first glance that looks rather good to me, but there is one things I
don't really like and I s
On Mon, Jul 10, 2017 at 08:00:37PM +0200, Daniel Vetter wrote:
> On Mon, Jul 10, 2017 at 9:14 AM, Alexandru Moise
> <00moses.alexande...@gmail.com> wrote:
> > On Mon, Jul 10, 2017 at 08:52:46AM +0200, Daniel Vetter wrote:
> >> On Sat, Jul 08, 2017 at 11:43:52PM +0200, Alexandru Moise wrote:
> >> >
On 6 July 2017 at 13:46, Deucher, Alexander wrote:
>> Attach it to analogous primitive?
>
> Radeon libdrm is much different than amdgpu. There is no analog.
>
Upon a closer look, indeed there isn't. Must have gotten confused earlier.
>>
>> > I think the current radeon API is simpler. Maybe a fo
On Tue, Jul 11, 2017 at 11:41 AM, Greg Kroah-Hartman
wrote:
> On Mon, Jul 10, 2017 at 08:00:37PM +0200, Daniel Vetter wrote:
>> On Mon, Jul 10, 2017 at 9:14 AM, Alexandru Moise
>> <00moses.alexande...@gmail.com> wrote:
>> > On Mon, Jul 10, 2017 at 08:52:46AM +0200, Daniel Vetter wrote:
>> >> On Sa
On Sat, Jul 08, 2017 at 11:43:52PM +0200, Alexandru Moise wrote:
> If the DRM core fails to init for whatever reason, ensure that
> no driver ever calls drm_dev_register().
>
> This is best done at drm_dev_init() as it covers drivers that call
> drm_dev_alloc() as well as drivers that prefer to em
From: Hans Verkuil
This patch adds support to VC4 for CEC.
To prevent the firmware from eating the CEC interrupts you need to add this to
your config.txt:
mask_gpu_interrupt1=0x100
Signed-off-by: Hans Verkuil
---
drivers/gpu/drm/vc4/Kconfig| 8 ++
drivers/gpu/drm/vc4/vc4_hdmi.c | 203 +
From: Hans Verkuil
In order to support CEC the hsm clock needs to be enabled in
vc4_hdmi_bind(), not in vc4_hdmi_encoder_enable(). Otherwise you wouldn't
be able to support CEC when there is no hotplug detect signal, which is
required by some monitors that turn off the HPD when in standby, but ke
From: Hans Verkuil
Some hardware does more than one attempt. So when it calls
cec_transmit_done when an error occurred it will e.g. use an error count
of 2 instead of 1.
The framework always assumed a single attempt, but now it is smarter
and will sum the counters to detect how many attempts wer
From: Hans Verkuil
This patch series adds support for HDMI CEC to the vc4 drm driver.
This series is based on the mainline kernel as of yesterday since
both the vc4 and cec patches for the 4.13 merge window are now merged
in that kernel.
Note: the first cec patch is independent of the vc4 patche
From: Eric Anholt
Basic usage:
poweron: HSM clock should be running. Set the bit clock divider,
set all the other _US timeouts based on bit clock rate. Bring RX/TX
reset up and then down.
powerdown: Set RX/TX reset.
interrupt: read CPU_STATUS, write bits that have been handled to
CPU_CLEAR.
https://bugs.freedesktop.org/show_bug.cgi?id=100189
--- Comment #14 from Indie ---
I also have a problem with these Gallium drivers. Is there a way to fix them,
or find an old unbroken version?
--
You are receiving this mail because:
You are the assignee for the bug.
On Tue, Jul 11, 2017 at 11:48 AM, Sergey Senozhatsky
wrote:
> On (07/11/17 09:50), Daniel Vetter wrote:
> [..]
>> > ok, obviously stupid.
>> >
>> > I meant to hold con->lock between console_disable() and console_enable().
>> > so no other CPU can unregister it, etc. printk->console_unlock(), thus,
https://bugs.freedesktop.org/show_bug.cgi?id=101736
Indie changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
-define-for-the-PCI-resource-type-mask-v2/20170711-104904
base: https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
-resource-type-mask-v2/20170711-104904
base: https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
reproduce: make htmldocs
All warnings (new ones prefixed by >>):
WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick
(https://www.imagemagick.org)
Register init table use un-document define, it is unreadable,
And sometimes we only want to update tiny bits, init table
method is not friendly, it's diffcult to reuse for difference
chips.
Signed-off-by: Mark Yao
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 6 ++--
drivers/gpu/drm/rockchi
These patches try to make all current rockchip full framework vop works
on drm, The newer vop design always have some different to the old one,
So we add a register verify mechanism to distinguish those register, then
the registers table can be reused.
And people can easy to know the different for
Signed-off-by: Mark Yao
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 66 +
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 18 ++--
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 20 ++---
3 files changed, 77 insertions(+), 27 deletions(-)
diff --git a/drive
Signed-off-by: Mark Yao
---
Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt | 4
1 file changed, 4 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
index
Signed-off-by: Mark Yao
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 2 +-
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 4 ++--
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 8
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.
Vop Full framework now has following vops:
IP versionchipname
3.1 rk3288
3.2 rk3368
3.4 rk3366
3.5 rk3399 big
3.6 rk3399 lit
3.7 rk322x
3.8 rk3328
The above IP version is from H/W define, some of vop support ge
Hi Mark,
Am Dienstag, 11. Juli 2017, 20:42:38 CEST schrieb Mark Yao:
> Signed-off-by: Mark Yao
> ---
> Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt | 4
> 1 file changed, 4 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/display/rockchip/rockchip-vo
Hi Dave, drm/i915 fixes for v4.13-rc1. Almost half of them for stable
kernels, the rest for issues in this merge window. Two batches of GVT
fixes, otherwise fixes all around.
BR,
Jani.
The following changes since commit bdbbf7d619d1fd2f1fa9eb529b7817e4faf73f5e:
drm/i915: Clear execbuf's vma b
From: Hans Verkuil
Document the Display Port CEC helper functions.
Signed-off-by: Hans Verkuil
---
Documentation/gpu/drm-kms-helpers.rst | 9 +
1 file changed, 9 insertions(+)
diff --git a/Documentation/gpu/drm-kms-helpers.rst
b/Documentation/gpu/drm-kms-helpers.rst
index 7c5e2549a58
From: Hans Verkuil
This patch series adds support for the DisplayPort CEC-Tunneling-over-AUX
feature. This patch series is based on the latest mainline kernel (as of today)
which has all the needed cec and drm 4.13 patches merged.
This patch series has been tested with my NUC7i5BNK and a Samsung
From: Hans Verkuil
Implement support for this DisplayPort feature.
The cec device is created whenever it detects an adapter that
has this feature. It is only removed when a new adapter is connected
that does not support this. If a new adapter is connected that has
different properties than the p
From: Hans Verkuil
This adds support for the DisplayPort CEC-Tunneling-over-AUX
feature that is part of the DisplayPort 1.3 standard.
Unfortunately, not all DisplayPort/USB-C to HDMI adapters with a
chip that has this capability actually hook up the CEC pin, so
even though a CEC device is create
The first patch I've already sent to list and plan to include in a
v4.13-fixes pull request, but I'm resending as part of this patchset
since 3/3 depends on it.
The 2nd patch exports get_fb_info()/put_fb_info() so that in the 3rd
patch we can iterate over the registered fb's (before kicking out fw
Fixes a problem with console not appearing when booting with EFI that
has GOP support, because fb0 would end up being efifb, even after drm
has taken over the display.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.c | 20
drivers/gpu/drm/msm/msm_drv.h | 2 ++
Needed for following patch.
Signed-off-by: Rob Clark
---
drivers/video/fbdev/core/fbmem.c | 6 --
include/linux/fb.h | 2 ++
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 5324358f110f..db
If we are kicking out efifb or simplefb then we want to hijack the
outgoing fb's memory and wrap it in a gem object so that it can
be allocated for use by fbdev helpers. This way we keep the same
scanout buffer that the display is already using.
This is prep-work for enabling drm/msm to take over
On Tue, Jul 11, 2017 at 3:38 PM, Rob Clark wrote:
> +static unsigned long hijack_firmware_fb(struct drm_device *dev)
> +{
> + struct msm_drm_private *priv = dev->dev_private;
> + unsigned long size;
> + int i;
> +
> + /* if we have simplefb/efifb, find it's aperture and hij
Quoting Rob Clark (2017-07-11 14:38:22)
> +static unsigned long hijack_firmware_fb(struct drm_device *dev)
> +{
> + struct msm_drm_private *priv = dev->dev_private;
> + unsigned long size;
> + int i;
> +
> + /* if we have simplefb/efifb, find it's aperture and hijack
> +
On Tue, Jul 11, 2017 at 10:03 AM, Daniel Vetter wrote:
> On Tue, Jul 11, 2017 at 3:38 PM, Rob Clark wrote:
>> +static unsigned long hijack_firmware_fb(struct drm_device *dev)
>> +{
>> + struct msm_drm_private *priv = dev->dev_private;
>> + unsigned long size;
>> + int i;
>> +
>>
We want to change swap_state to wait indefinitely, but to do this
swap_state should wait interruptibly. This requires propagating
the error to each driver.
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc: intel-...@lists.freedesktop.org
Signed-off-by: Maarten Lankhorst
---
drm_atomic_helper_swap_state() will be changed to interruptible waiting
in the next few commits, so all drivers have to be changed to handling
failure.
Signed-off-by: Maarten Lankhorst
Cc: Ben Skeggs
Cc: nouv...@lists.freedesktop.org
---
drivers/gpu/drm/nouveau/nv50_display.c | 5 -
1 file
Make it more clear that post commit return ret is really return 0,
and add a missing drm_atomic_helper_cleanup_planes when
drm_atomic_helper_wait_for_fences fails.
Fixes: 839ca903f12e ("drm/nouveau/kms/nv50: transition to atomic interfaces
internally")
Cc: Ben Skeggs
Cc: dri-devel@lists.freedes
drm_atomic_helper_swap_state() will be changed to interruptible waiting
in the next few commits, so all drivers have to be changed to handling
failure.
Atmel tracks pending commits through dc->commit.pending, so it can
ignore the changes by setting stall = false. We never return failure in
this ca
drm_atomic_helper_swap_state() will be changed to interruptible waiting
in the next few commits, so all drivers have to be changed to handling
failure.
MSM has its own busy tracking, which means the swap_state call can be
done with stall = false, in which case it should never return an error.
Hand
drm_atomic_helper_swap_state could previously never fail, in order to still
continue it would set a limit of 10s on waiting for previous updates to
complete,
then it moved forward. This can be very bad when ignoring previous updates,
because the hw state and sw state may get out of sync when for e
drm_atomic_helper_swap_state() will be changed to interruptible waiting
in the next few commits, so all drivers have to be changed to handling
failure.
Signed-off-by: Maarten Lankhorst
Cc: Thierry Reding
Cc: Jonathan Hunter
Cc: linux-te...@vger.kernel.org
---
drivers/gpu/drm/tegra/drm.c | 7 ++
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_helper.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index bfb98fbd0e0e..05a22aeffbb0 100644
--- a/drivers/gpu/drm/drm
Now that all drivers check the return value, convert swap_state to
__must_check. This is done separately to force build warnings if we
missed a driver.
Signed-off-by: Maarten Lankhorst
---
include/drm/drm_atomic_helper.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/inclu
drm_atomic_helper_swap_state() will be changed to interruptible waiting
in the next few commits, so all drivers have to be changed to handling
failure.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff
drm_atomic_helper_swap_state() will be changed to interruptible waiting
in the next few commits, so all drivers have to be changed to handling
failure.
VC4 has its own nonblocking modeset tracking through the vc4->async_modeset
semaphore, so it doesn't need to stall in swap_state. Pass stall = fal
drm_atomic_helper_swap_state() will be changed to interruptible waiting
in the next few commits, so all drivers have to be changed to handling
failure.
Signed-off-by: Maarten Lankhorst
Cc: Jyri Sarha
Cc: Tomi Valkeinen
---
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 6 +-
1 file changed, 5 inser
drm_atomic_helper_swap_state() will be changed to interruptible waiting
in the next few commits, so all drivers have to be changed to handling
failure.
Signed-off-by: Maarten Lankhorst
Cc: CK Hu
Cc: Philipp Zabel
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-media...@lists.infradead.org
--
On Tue, Jul 11, 2017 at 10:17 AM, Chris Wilson wrote:
> Quoting Rob Clark (2017-07-11 14:38:22)
>> +static unsigned long hijack_firmware_fb(struct drm_device *dev)
>> +{
>> + struct msm_drm_private *priv = dev->dev_private;
>> + unsigned long size;
>> + int i;
>> +
>> + /*
On Tue, Jul 11, 2017 at 4:31 PM, Rob Clark wrote:
> On Tue, Jul 11, 2017 at 10:03 AM, Daniel Vetter wrote:
>> On Tue, Jul 11, 2017 at 3:38 PM, Rob Clark wrote:
>>> +static unsigned long hijack_firmware_fb(struct drm_device *dev)
>>> +{
>>> + struct msm_drm_private *priv = dev->dev_private;
Instead check info->ops->owner, which amounts to the same.
Spotted because I want to remove the pile of broken and cargo-culted
fb_info->flags assignments in drm drivers.
v2: Fixup matrox (reported by kbuild). Also nuke FBINFO_FLAG_* defines
that I've failed to spot.
v3: Don't nuke FBINFO_FLAG_D
https://bugs.freedesktop.org/show_bug.cgi?id=101712
Vedran Miletić changed:
What|Removed |Added
Summary|CPU lockup after ring 0 |[Turks PRO/Radeon HD
On Tue, Jul 11, 2017 at 12:56 AM, Daniel Vetter wrote:
> On Mon, Jul 10, 2017 at 03:47:54PM -0700, John Stultz wrote:
>> On Mon, Jul 10, 2017 at 2:18 PM, Sean Paul wrote:
>> > On Mon, Jul 10, 2017 at 01:48:02PM -0700, John Stultz wrote:
>> >> Currently the hikey dsi logic cannot generate accurate
https://bugs.freedesktop.org/show_bug.cgi?id=100189
--- Comment #15 from Indie ---
I actually need this.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.
On Tue, Jul 11, 2017 at 5:05 PM, John Stultz wrote:
>>> > be even better if you could calculate whether the mode is valid, but I
>>> > didn't
>>> > spend enough time to figure out if this is possible.
>>>
>>> Theoretically that might be possible, checking if the requested freq
>>> matches the cal
https://bugs.freedesktop.org/show_bug.cgi?id=101712
--- Comment #6 from guiscara...@gmail.com ---
Created attachment 132618
--> https://bugs.freedesktop.org/attachment.cgi?id=132618&action=edit
Dmesg after boot
(In reply to Julien Isorce from comment #5)
> Thx for the apitrace. I could not repr
On Tue, Jul 11, 2017 at 12:17 AM, Christian König
wrote:
> Am 11.07.2017 um 04:36 schrieb Michel Dänzer:
>
>> On 11/07/17 06:09 AM, Jason Ekstrand wrote:
>>
>>> On Mon, Jul 10, 2017 at 9:15 AM, Christian König
>>> mailto:deathsim...@vodafone.de>> wrote:
>>>
>>> Am 10.07.2017 um 17:52 schrieb
On Tue, Jul 11, 2017 at 8:12 AM, Daniel Vetter wrote:
> On Tue, Jul 11, 2017 at 5:05 PM, John Stultz wrote:
> be even better if you could calculate whether the mode is valid, but I
> didn't
> spend enough time to figure out if this is possible.
Theoretically that might b
https://bugs.freedesktop.org/show_bug.cgi?id=92715
Armando Antonio changed:
What|Removed |Added
Summary|[IGT] |[IGT]
|[BYT-M/KBL/BS
https://bugs.freedesktop.org/show_bug.cgi?id=101749
--- Comment #1 from Christoph Haag ---
Possibly the same as bug 100742 which is very visible with SteamVR.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel maili
https://bugs.freedesktop.org/show_bug.cgi?id=92715
--- Comment #29 from Armando Antonio ---
Sorry this is the test list
igt@gem_reset_stats@ban-default
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing lis
https://bugs.freedesktop.org/show_bug.cgi?id=92715
Armando Antonio changed:
What|Removed |Added
Summary|[IGT] |[IGT]
|[BYT-M/KBL/BX
https://bugs.freedesktop.org/show_bug.cgi?id=92715
--- Comment #31 from Armando Antonio ---
The following test fail on BSW with latest configuration
Test list
gt@gem_reset_stats@reset-count-
On Tue, Jul 11, 2017 at 5:44 PM, John Stultz wrote:
> On Tue, Jul 11, 2017 at 8:12 AM, Daniel Vetter wrote:
>> On Tue, Jul 11, 2017 at 5:05 PM, John Stultz wrote:
> > be even better if you could calculate whether the mode is valid, but I
> > didn't
> > spend enough time to figure ou
Quoting Chris Wilson (2017-02-14 12:40:01)
> [ 236.821534] WARNING: kmemcheck: Caught 64-bit read from uninitialized
> memory (8802538683d0)
> [ 236.828642]
> 42001e7f0008
> [ 236.839543] i i i i u u u u i i i i i i i i u u u u u u u u u
On Mon, Jul 10, 2017 at 4:56 PM, Daniel Vetter wrote:
> On Mon, Jul 10, 2017 at 11:37 AM, Takashi Iwai wrote:
>>> DPMS should be an error anyway, we want that to be able to properly
>>> thread the acquire_ctx EDEADLK backoff stuff through that we need for
>>> atomic. That would be the best long-t
On Tue, Jul 11, 2017 at 11:20 AM, Dave Airlie wrote:
> On 11 July 2017 at 18:36, Christian König wrote:
>> Am 11.07.2017 um 08:49 schrieb Dave Airlie:
>>>
>>> On 7 July 2017 at 19:07, Christian König wrote:
Hi Dave,
on first glance that looks rather good to me, but there is o
On Tue, Jul 11, 2017 at 3:07 PM, kbuild test robot wrote:
> make ARCH=i386
Yeah, either this code shouldn't have been built on 32-bit arch at
all, or be portable.
>arch/x86/pci/fixup.c: In function 'pci_amd_enable_64bit_bar':
>>> arch/x86/pci/fixup.c:674:15: warning: large integer i
Some details that may be useful in analysis of the bug:
1. lspci -nn -d 10de:
2. What displays, if any, you have plugged into the NVIDIA board when
this happens?
3. Any boot parameters, esp relating to ACPI, PM, or related?
Cheers,
-ilia
On Tue, Jul 11, 2017 at 1:32 PM, Mike Galbraith wrote:
On Tue, 11 Jul 2017 19:35:36 +0200,
Daniel Vetter wrote:
>
> On Mon, Jul 10, 2017 at 4:56 PM, Daniel Vetter wrote:
> > On Mon, Jul 10, 2017 at 11:37 AM, Takashi Iwai wrote:
> >>> DPMS should be an error anyway, we want that to be able to properly
> >>> thread the acquire_ctx EDEADLK backoff stuf
So now that this is working (at least on a single device), I figured
it was a good time to send out an RFC to start discussion about how
to do this properly, in particular the CCF/powerdomain parts.
The first patch adds flags so we can mark power domains and leaf
node clocks which might (or might
We need to do some things a bit differently if the bridge chip is
already powered up when the driver loads (ie. bootloader has already
enabled display). In particular we don't want to do anything that
would kill the display.
---
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 57 ++
The goal here is to support inheriting a display setup by bootloader,
although there may also be some non-display related use-cases.
Rough idea is to add a flag for clks and power domains that might
already be enabled when kernel starts, and make corresponding fixups
to clk enable/prepare_count an
It is quite common for bootloader to enable display on tablets/phones.
But until now for upstream kernel we've been ignoring that since it
highly confuses drm/msm, and recommending to disable the bootloader
display. (Otherwise we end up trying to set rates on already enabled
clks and all sorts of
On Tue, Jul 11, 2017 at 2:08 PM, Mike Galbraith wrote:
> On Tue, 2017-07-11 at 13:51 -0400, Ilia Mirkin wrote:
>> Some details that may be useful in analysis of the bug:
>>
>> 1. lspci -nn -d 10de:
>
> 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM204 [GeForce
> GTX 980] [10de:13
Hi Rob,
On Tue, Jul 11, 2017 at 8:20 PM, Rob Clark wrote:
> So now that this is working (at least on a single device), I figured
> it was a good time to send out an RFC to start discussion about how
> to do this properly, in particular the CCF/powerdomain parts.
>
> The first patch adds flags so
On Tue, Jul 11, 2017 at 2:35 PM, Geert Uytterhoeven
wrote:
> Hi Rob,
>
> On Tue, Jul 11, 2017 at 8:20 PM, Rob Clark wrote:
>> So now that this is working (at least on a single device), I figured
>> it was a good time to send out an RFC to start discussion about how
>> to do this properly, in part
On Mon, Jul 10, 2017 at 04:55:04PM +1000, Jonathan Liu wrote:
> The drm_driver lastclose callback is called when the last userspace
> DRM client has closed. Call drm_fbdev_cma_restore_mode to restore
> the fbdev console otherwise the fbdev console will stop working.
>
> Fixes: 9026e0d122ac ("drm:
On Mon, Jul 10, 2017 at 11:48:00PM +0800, Chen-Yu Tsai wrote:
> On Sun, Jun 18, 2017 at 10:05 PM, Rob Herring wrote:
> > On Wed, Jun 14, 2017 at 02:30:16PM +0800, Chen-Yu Tsai wrote:
> >> The explanation for the endpoint ID numbering scheme is convoluted
> >> and hard to understand.
> >>
> >> This
On Tue, Jul 11, 2017 at 12:22 AM, Daniel Vetter wrote:
> On Mon, Jul 10, 2017 at 02:09:42PM -0700, Jason Ekstrand wrote:
> > On Mon, Jul 10, 2017 at 9:15 AM, Christian König <
> deathsim...@vodafone.de>
> > wrote:
> >
> > > Am 10.07.2017 um 17:52 schrieb Jason Ekstrand:
> > >
> > > On Mon, Jul 10
On Tue, Jul 11, 2017 at 10:42 AM, Daniel Vetter wrote:
> On Tue, Jul 11, 2017 at 4:31 PM, Rob Clark wrote:
>> On Tue, Jul 11, 2017 at 10:03 AM, Daniel Vetter wrote:
>>> On Tue, Jul 11, 2017 at 3:38 PM, Rob Clark wrote:
+static unsigned long hijack_firmware_fb(struct drm_device *dev)
+
This is just future proofing code, not something that can be triggered
in real life. We're testing to make sure we don't shift wrap when we
do "1ull << i" so "i" has to be in the 0-63 range. If it's 64 then we
have gone too far.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/amd/amd
On 11/07/17 08:30, Hans Verkuil wrote:
> From: Hans Verkuil
>
> This patch series adds CEC support for the sun4i HDMI controller.
>
> The CEC hardware support for the A10 is very low-level as it just
> controls the CEC pin. Since I also wanted to support GPIO-based CEC
> hardware most of this pa
On Tue, Jul 11, 2017 at 8:10 PM, Takashi Iwai wrote:
> On Tue, 11 Jul 2017 19:35:36 +0200,
> Daniel Vetter wrote:
>>
>> On Mon, Jul 10, 2017 at 4:56 PM, Daniel Vetter wrote:
>> > On Mon, Jul 10, 2017 at 11:37 AM, Takashi Iwai wrote:
>> >>> DPMS should be an error anyway, we want that to be able
On Tue, Jul 11, 2017 at 9:53 PM, Rob Clark wrote:
> On Tue, Jul 11, 2017 at 10:42 AM, Daniel Vetter wrote:
>> On Tue, Jul 11, 2017 at 4:31 PM, Rob Clark wrote:
>>> On Tue, Jul 11, 2017 at 10:03 AM, Daniel Vetter wrote:
On Tue, Jul 11, 2017 at 3:38 PM, Rob Clark wrote:
> +static unsign
On Tue, Jul 11, 2017 at 08:30:33AM +0200, Hans Verkuil wrote:
> From: Hans Verkuil
>
> This patch series adds CEC support for the sun4i HDMI controller.
>
> The CEC hardware support for the A10 is very low-level as it just
> controls the CEC pin. Since I also wanted to support GPIO-based CEC
> h
When implementing support for interlaced modes, the driver switched from
reporting vblank events on the vertical blanking (VBK) interrupt to the
frame end interrupt (FRM). This incorrectly divided the reported refresh
rate by two. Fix it by moving back to the VBK interrupt.
Fixes: 906eff7fcada ("d
1 - 100 of 144 matches
Mail list logo
