https://bugs.freedesktop.org/show_bug.cgi?id=100101
Eric Blau changed:
What|Removed |Added
Component|Drivers/DRI/i965|Drivers/DRI/i915
QA Contact|intel-3
https://bugzilla.kernel.org/show_bug.cgi?id=194843
--- Comment #4 from Johannes Hirte (johannes.hi...@datenkhaos.de) ---
it's a Carrizo, A10-8700B R6
Requested logs attached, both running kernel 4.10.0 at moment. Do you need them
from 4.11-rc1?
--
You are receiving this mail because:
You are wa
https://bugzilla.kernel.org/show_bug.cgi?id=194843
--- Comment #3 from Johannes Hirte (johannes.hi...@datenkhaos.de) ---
Created attachment 255175
--> https://bugzilla.kernel.org/attachment.cgi?id=255175&action=edit
Xorg.0.log
--
You are receiving this mail because:
You are watching the assign
https://bugzilla.kernel.org/show_bug.cgi?id=194843
--- Comment #2 from Johannes Hirte (johannes.hi...@datenkhaos.de) ---
Created attachment 255173
--> https://bugzilla.kernel.org/attachment.cgi?id=255173&action=edit
dmesg-4.10.0
--
You are receiving this mail because:
You are watching the assi
Hello Alexandre Courbot,
The patch 5429f82f3415: "drm/nouveau/secboot: add
gp102/gp104/gp106/gp107 support" from Jan 26, 2017, leads to the
following static checker warning:
drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gp102.c:63
gp102_run_secure_scrub()
warn: passing zero to 'PTR
On Fri, Mar 10, 2017 at 2:23 PM, Lukas Wunner wrote:
> +/**
> + * pci_is_thunderbolt_attached - whether device is on a Thunderbolt daisy
> chain
> + * @pdev: PCI device to check
> + *
> + * Walk upwards from @pdev and check for each encountered bridge if it's part
> + * of a Thunderbolt controll
https://bugzilla.kernel.org/show_bug.cgi?id=194843
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
https://bugzilla.kernel.org/show_bug.cgi?id=194843
Bug ID: 194843
Summary: [amdgpu] oops [drm:gfx_v8_0_priv_reg_irq] *ERROR*
Illegal register access in command stream
Product: Drivers
Version: 2.5
Kernel Version: 4.11.0-rc1
On MacBook Pros introduced 2011 and onward, external DP ports are
combined DP/Thunderbolt ports that are no longer fully switchable
between GPUs, they can only be driven by the discrete GPU.
More specifically, the Main Link pins (which transport the actual video
and audio streams) are soldered to
An external Thunderbolt GPU can neither drive the laptop's panel nor be
powered off by the platform, so there's no point in registering it with
vga_switcheroo. In fact, when the external GPU is runtime suspended,
vga_switcheroo will cut power to the internal discrete GPU, resulting in
a lockup.
C
An external Thunderbolt GPU can neither drive the laptop's panel nor be
powered off by the platform, so there's no point in registering it with
vga_switcheroo. In fact, when the external GPU is runtime suspended,
vga_switcheroo will cut power to the internal discrete GPU, resulting in
a lockup. M
An external Thunderbolt GPU can neither drive the laptop's panel nor be
powered off by the platform, so there's no point in registering it with
vga_switcheroo. In fact, when the external GPU is runtime suspended,
vga_switcheroo will cut power to the internal discrete GPU, resulting in
a lockup. M
Detect on probe whether a PCI device is part of a Thunderbolt controller.
Intel uses a Vendor-Specific Extended Capability (VSEC) with ID 0x1234
on such devices. Detect presence of this VSEC and cache it in a newly
added is_thunderbolt bit in struct pci_dev.
Also, add a helper to check whether a
Fix Thunderbolt-related issues in apple-gmux and vga_switcheroo, v2:
Same as v1 but includes all the acks collected and in patch [1/5]
the commit message and a code comment were edited as requested by
Bjorn Helgaas.
For details on this series please refer to the cover letter of v1:
https://lists.
On Fri, Mar 10, 2017 at 05:52:34PM +0100, Daniel Vetter wrote:
> On Fri, Mar 10, 2017 at 11:01:54AM -0500, Sean Paul wrote:
> > On Fri, Mar 10, 2017 at 02:12:14PM +1000, Dave Airlie wrote:
> > > Talk to Jonas (jadahl) on irc, he had 3 mutters running and on hotplug
> > > all 3 of them were diving i
On 03/01/2017, 03:09 PM, Gerd Hoffmann wrote:
> @@ -128,12 +96,9 @@ void virtio_gpu_free_vbufs(struct virtio_gpu_device
> *vgdev)
> {
> struct virtio_gpu_vbuffer *vbuf;
>
> - spin_lock(&vgdev->free_vbufs_lock);
> - BUG_ON(list_empty(&vgdev->free_vbufs));
> - vbuf = list_first_
On Fri, Mar 10, 2017 at 11:01:54AM -0500, Sean Paul wrote:
> On Fri, Mar 10, 2017 at 02:12:14PM +1000, Dave Airlie wrote:
> > Talk to Jonas (jadahl) on irc, he had 3 mutters running and on hotplug
> > all 3 of them were diving into the connector getting code. Now I think
> > we can avoid this in us
On 03/10/2017 06:27 AM, Brian Starkey wrote:
> On Fri, Mar 10, 2017 at 11:46:42AM +, Robin Murphy wrote:
>> On 10/03/17 10:31, Brian Starkey wrote:
>>> Hi,
>>>
>>> On Thu, Mar 09, 2017 at 09:38:49AM -0800, Laura Abbott wrote:
On 03/09/2017 02:00 AM, Benjamin Gaignard wrote:
>>>
>>> [snip]
On Fri, Mar 10, 2017 at 02:12:14PM +1000, Dave Airlie wrote:
> Talk to Jonas (jadahl) on irc, he had 3 mutters running and on hotplug
> all 3 of them were diving into the connector getting code. Now I think
> we can avoid this in userspace by not probing when not owning the VT,
> but it's still mes
Hi Dave,
I have obviously missed the boat on -rc2, so I'm sending this
in hope to get them into -rc3. A couple of patches, one to remove
the use of the mclk clock that dictates the amount of scaling that
you can do with Mali DP hardware and one to make the smart layer
usable as a DRM plane (smart
On Fri, Mar 10, 2017 at 11:46:42AM +, Robin Murphy wrote:
On 10/03/17 10:31, Brian Starkey wrote:
Hi,
On Thu, Mar 09, 2017 at 09:38:49AM -0800, Laura Abbott wrote:
On 03/09/2017 02:00 AM, Benjamin Gaignard wrote:
[snip]
For me those patches are going in the right direction.
I still h
On Fri, Mar 10, 2017 at 04:09:57PM +0900, Tomasz Figa wrote:
> Hi Sean,
>
> On Fri, Mar 10, 2017 at 1:32 PM, Sean Paul wrote:
> >
> > From: Tomasz Figa
> >
> > Since we take the ownership of drvdata, the master driver does not have
> > any means of accessing its own data from unbind callback and
The output stage of the mixer uses YCbCr for the internal
computations, which is the reason that some registers take
YCbCr related data as input. In particular this applies
to MXR_BG_COLOR{0,1,2} and MXR_CM_COEFF_{Y,CB,CR}.
Document the formatting of the data which we write to
these registers.
Wh
On 10.03.2017 14:30, Tobias Jakobi wrote:
> The output stage of the mixer uses YCbCr for the internal
> computations, which is the reason that some registers take
> YCbCr related data as input. In particular this applies
> to MXR_BG_COLOR{0,1,2} and MXR_CM_COEFF_{Y,CB,CR}.
>
> Document the formatti
On Fri, Mar 10, 2017 at 7:40 AM, Daniel Vetter wrote:
> On Fri, Mar 10, 2017 at 10:31:13AM +, Brian Starkey wrote:
>> Hi,
>>
>> On Thu, Mar 09, 2017 at 09:38:49AM -0800, Laura Abbott wrote:
>> > On 03/09/2017 02:00 AM, Benjamin Gaignard wrote:
>>
>> [snip]
>>
>> > >
>> > > For me those patches
The output stage of the mixer uses YCbCr for the internal
computations, which is the reason that some registers take
YCbCr related data as input. In particular this applies
to MXR_BG_COLOR{0,1,2} and MXR_CM_COEFF_{Y,CB,CR}.
Document the formatting of the data which we write to
these registers.
Wh
Convert if-statements to switch statement. Removes
duplicated code.
Reviewed-by: Andrzej Hajda
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_mixer.c | 30 --
1 file changed, 8 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos
On Thu, Mar 09, 2017 at 09:09:52PM +0200, Mikko Perttunen wrote:
> On 03/09/2017 08:58 PM, Daniel Vetter wrote:
> > On Thu, Mar 9, 2017 at 6:57 PM, Mikko Perttunen
> > wrote:
> > > Hi everyone,
> > >
> > > this series adds support for using sync fences as prefences and
> > > postfences for host1
On Fri, Mar 10, 2017 at 10:31:13AM +, Brian Starkey wrote:
> Hi,
>
> On Thu, Mar 09, 2017 at 09:38:49AM -0800, Laura Abbott wrote:
> > On 03/09/2017 02:00 AM, Benjamin Gaignard wrote:
>
> [snip]
>
> > >
> > > For me those patches are going in the right direction.
> > >
> > > I still have f
On Fri, Mar 10, 2017 at 2:07 PM, Lukas Wunner wrote:
> On Thu, Mar 09, 2017 at 04:03:47PM +0100, Daniel Vetter wrote:
>> On Fri, Feb 24, 2017 at 08:19:45PM +0100, Lukas Wunner wrote:
>> > Fix Thunderbolt-related issues in apple-gmux and vga_switcheroo:
>> >
>> > Patch [1/5] ("Recognize Thunderbolt
On 10/03/17 11:39, Laurent Pinchart wrote:
> The is_cache_coherent() function currently returns true when the mapping
> is not cache-coherent. This isn't a bug as such as the callers interpret
> cache-coherent as meaning that the driver has to handle the coherency
> manually, but it is nonetheless
On Thu, Mar 09, 2017 at 04:03:47PM +0100, Daniel Vetter wrote:
> On Fri, Feb 24, 2017 at 08:19:45PM +0100, Lukas Wunner wrote:
> > Fix Thunderbolt-related issues in apple-gmux and vga_switcheroo:
> >
> > Patch [1/5] ("Recognize Thunderbolt devices") has already been subjected
> > to a fair amount
On 10/03/17 10:31, Brian Starkey wrote:
> Hi,
>
> On Thu, Mar 09, 2017 at 09:38:49AM -0800, Laura Abbott wrote:
>> On 03/09/2017 02:00 AM, Benjamin Gaignard wrote:
>
> [snip]
>
>>>
>>> For me those patches are going in the right direction.
>>>
>>> I still have few questions:
>>> - since alignmen
On 3/3/2017 10:49 PM, Laurent Pinchart wrote:
Hello,
This patch series refactors all the PHY handling code in order to allow
support of vendor PHYs and Synopsys DWC HDMI 2.0 TX PHYs.
The series starts with a few cleanups and small fixes. Patch 01/10 just
removes unused code, patch 02/10 moves
Hi,
On Thu, Mar 09, 2017 at 09:38:49AM -0800, Laura Abbott wrote:
On 03/09/2017 02:00 AM, Benjamin Gaignard wrote:
[snip]
For me those patches are going in the right direction.
I still have few questions:
- since alignment management has been remove from ion-core, should it
be also removed
The fields, variables and functions deal with DMA addresses, name them
accordingly. The omap_gem_get_paddr() and omap_gem_put_paddr() will be
addressed differently separately.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_drv.h| 6 +--
drivers/gpu/drm/omapdrm/omap_fb.
This makes the function more readable.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_gem.c | 43 +++---
1 file changed, 21 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
b/drivers/gpu/drm/omapdrm/omap_gem.c
inde
The function is always called with the remap argument set to true.
Hardcode that behaviour and remove it.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_drv.h| 3 +--
drivers/gpu/drm/omapdrm/omap_fb.c | 2 +-
drivers/gpu/drm/omapdrm/omap_fbdev.c | 2 +-
The reflects the purpose of the function better.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_drv.h| 4 ++--
drivers/gpu/drm/omapdrm/omap_fb.c | 6 ++---
drivers/gpu/drm/omapdrm/omap_fbdev.c | 9
drivers/gpu/drm/omapdrm/omap_gem.c| 38
Hello,
Memory leaks have been reported when allocating a cached omap_bo (with
OMAP_BO_CACHED. Investigation showed that this can only come from the DMA
mapping debug layer, as on ARM32 the non-coherent, non-IOMMU DMA mapping code
doesn't allocate memory to map a page (and kmemcheck facility is onl
The field contains DMA addresses, clarify that by renaming it.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_gem.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
b/drivers/gpu/drm/omapdrm/omap_ge
Both coherent (uncached) and non-coherent (cached) buffers can have
their pages mapped to the device through the DMA mapping API. Make sure
to unmap any mapped page when freeing a buffer, regardless of its type.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_gem.c | 17 ++--
The is_cache_coherent() function currently returns true when the mapping
is not cache-coherent. This isn't a bug as such as the callers interpret
cache-coherent as meaning that the driver has to handle the coherency
manually, but it is nonetheless very confusing. Fix it and add a bit
more documenta
Hi Laura,
Thanks for the patch.
On 3 March 2017 at 03:14, Laura Abbott wrote:
>
> Frameworks that may want to enumerate CMA heaps (e.g. Ion) will find it
> useful to have an explicit name attached to each region. Store the name
> in each CMA structure.
>
> Signed-off-by: Laura Abbott
> ---
> d
44 matches
Mail list logo
