Successful sw_init() and hw_init() states are tracked, but not
late_init(). Various error paths may result in amdgpu_fini() being
called before .late init is done, so late_init needs to be tracked
to avoid unexpected or multiple .late_fini() calls.
Signed-off-by: Grazvydas Ignotas
---
drivers/gp
If this happens (and it recently did), we free a structure while part of
it is still in use, which results in non-obvious crashes. The way it's
detached is not trivial (DRM core has to call the connector .destroy
callback and things must be torn down in the right order), so better
detect it and war
All other amdgpu/dce_v* files have this call, it's only mysteriously
missing from dce_v11_0.c since the file was added and causes leaks.
Fixes: aaa36a976bbb ("drm/amdgpu: Add initial VI support")
Signed-off-by: Grazvydas Ignotas
---
drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 1 +
1 file changed, 1
mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161003/bcce5877/attachment.html>
from Michel Dänzer ---
Monk, any ideas?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161003/7caab355/attachment-0001.html>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20161003/a6a5a6c1/attachment.html>
vel/attachments/20161003/ce03dbfc/attachment.html>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161003/835d732a/attachment.html>
mesamatrix (by
features.txt) there are all extensions implemented for radeonsi.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/at
On Mon, Sep 26, 2016 at 9:32 PM, Ard Biesheuvel
wrote:
> Some subdevices (i.e., fb/nv50.c and fb/gf100.c) map a scratch page using
> dma_map_page() way before the TTM layer has had a chance to set the DMA
> mask. This may prevent the driver from loading at all on platforms whose
> system memory is
On Mon, Sep 26, 2016 at 9:32 PM, Ard Biesheuvel
wrote:
> The 100c10 scratch page is mapped using dma_map_page() before the TTM
> layer has had a chance to set the DMA mask. This means we are still
> running with the default of 32 when this code executes, and this causes
> problems for platforms wi
On Mon, Sep 26, 2016 at 9:32 PM, Ard Biesheuvel
wrote:
> The 100c08 scratch page is mapped using dma_map_page() before the TTM
> layer has had a chance to set the DMA mask. This means we are still
> running with the default of 32 when this code executes, and this causes
> problems for platforms wi
attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161003/194d102d/attachment.html>
On Sun, Oct 02, 2016 at 08:01:22AM +0200, Christophe JAILLET wrote:
> We should use 'ida_simple_remove()' instead of 'ida_remove()' when freeing
> resources allocated with 'ida_simple_get()'.
Should fix drm_connector_cleanup() then as well...
>
> This as been spotted with the following coccinell
On pe, 2016-09-30 at 11:38 +0100, Chris Wilson wrote:
> dma_buf_export() adds a reference to the owning module to the dmabuf (to
> prevent the driver from being unloaded whilst a third party still refers
> to the dmabuf). However, drm_gem_prime_export() was passing its own
> THIS_MODULE (i.e. drm.k
se:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161003/93483974/attachment.html>
I screwed up rebasing of my patch in
commit 43968d7b806d7a7e021261294c583a216fddf0e5
Author: Daniel Vetter
Date: Wed Sep 21 10:59:24 2016 +0200
drm: Extract drm_plane.[hc]
which meant on error paths drm_crtc_vblank_put could be called without
a get, leading to an underrun of the refcount.
On 03/10/16 05:28 PM, Daniel Vetter wrote:
> I screwed up rebasing of my patch in
>
> commit 43968d7b806d7a7e021261294c583a216fddf0e5
> Author: Daniel Vetter
> Date: Wed Sep 21 10:59:24 2016 +0200
>
> drm: Extract drm_plane.[hc]
>
> which meant on error paths drm_crtc_vblank_put could be
the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161003/c9a72a4b/attachment-0001.html>
rg/archives/dri-devel/attachments/20161003/cd9bd80c/attachment.html>
On Fri, 30 Sep 2016, kbuild test robot wrote:
> tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc
> head: 6c4d6f9f997c5dafccb54b52167f0c4d0ea37874
> commit: 6c4d6f9f997c5dafccb54b52167f0c4d0ea37874 [3/3] drm/fb-helper: add
> DRM_FB_HELPER_DEFAULT_OPS for fb_ops
> reproduce: make ht
stead.
That fixes it, thanks.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161003/5151397f/attachment.html>
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161003/74878021/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161003/6f35be09/attachment.html>
On 1 October 2016 at 01:22, Shawn Guo wrote:
> Hi Emil,
>
> On Fri, Sep 30, 2016 at 01:34:14PM +0100, Emil Velikov wrote:
>> Hi Shawn,
>>
>> A couple of fly-by suggestions, which I hope you'll find useful :-)
>
> Thanks for the suggestions.
>
>> On 24 September 2016 at 15:26, Shawn Guo wrote:
>>
Hi Maxime,
On 09/30/2016 08:07 PM, Maxime Ripard wrote:
> Some boards have an entirely passive RGB to VGA bridge, based on either
> DACs or resistor ladders.
>
> Those might or might not have an i2c bus routed to the VGA connector in
> order to access the screen EDIDs.
>
> Add a bridge that doesn'
On 09/27/2016 06:58 PM, Sean Paul wrote:
> On Fri, Sep 23, 2016 at 10:06 AM, Tomeu Vizoso
> wrote:
>> So users know whether PSR should be enabled or not.
>>
>> Signed-off-by: Tomeu Vizoso
>> Cc: Sean Paul
>> Cc: Yakir Yang
>> Cc: Archit Taneja
>
> Reviewed-by: Sean Paul
queued to drm-misc.
On 09/27/2016 06:58 PM, Sean Paul wrote:
> On Fri, Sep 23, 2016 at 10:06 AM, Tomeu Vizoso
> wrote:
>> There's no point in enabling PSR when the panel doesn't support it.
>>
>> This also avoids a problem when PSR gets enabled when a CRTC is being
>> disabled, because sometimes in that situation t
On 30 September 2016 at 18:26, Laszlo Ersek wrote:
> On 09/30/16 18:38, Hans de Goede wrote:
>> Hi,
>>
>> On 30-09-16 17:33, Laszlo Ersek wrote:
>>> On 09/30/16 16:59, Hans de Goede wrote:
Hi,
On 30-09-16 16:51, Laszlo Ersek wrote:
> On 09/30/16 12:35, Hans de Goede wrote:
>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20161003/399e73a9/attachment.html>
HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161003/ea89fc0c/attachment.html>
On 3 October 2016 at 13:14, Laszlo Ersek wrote:
> On 10/03/16 13:34, Emil Velikov wrote:
>> On 30 September 2016 at 18:26, Laszlo Ersek wrote:
>
>>> This setup (modulo the kernel of course) was known to work, but now the
>>> X server actually segfaults (apparently in the
>>> xf86PlatformDeviceChe
even somewhat what we've
been using to implement the VGA hack we use on the CHIP.
Can you send that patch?
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was sc
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161003/a3fa0e41/attachment.html>
On Mon, Oct 03, 2016 at 05:35:05PM +0900, Michel Dänzer wrote:
> On 03/10/16 05:28 PM, Daniel Vetter wrote:
> > I screwed up rebasing of my patch in
> >
> > commit 43968d7b806d7a7e021261294c583a216fddf0e5
> > Author: Daniel Vetter
> > Date: Wed Sep 21 10:59:24 2016 +0200
> >
> > drm: Extr
On 10/03/16 13:34, Emil Velikov wrote:
> On 30 September 2016 at 18:26, Laszlo Ersek wrote:
>> This setup (modulo the kernel of course) was known to work, but now the
>> X server actually segfaults (apparently in the
>> xf86PlatformDeviceCheckBusID() function). Please find the logfile attached.
>
On 10/03/16 14:46, Emil Velikov wrote:
> On 3 October 2016 at 13:14, Laszlo Ersek wrote:
>> On 10/03/16 13:34, Emil Velikov wrote:
>>> On 30 September 2016 at 18:26, Laszlo Ersek wrote:
>>
This setup (modulo the kernel of course) was known to work, but now the
X server actually segfault
On 30/09/16 05:11, Bibby Hsieh wrote:
> On Thu, 2016-09-29 at 10:46 +0200, Matthias Brugger wrote:
>>
>> On 29/09/16 06:01, CK Hu wrote:
>>> Acked-by: CK Hu
>>>
>>> On Thu, 2016-09-29 at 11:22 +0800, Bibby Hsieh wrote:
Fix the typo: OD_RELAYMODE->OD_CFG
>>
>
> Hi, Matthias
> Thanks for
Hi Dave,
As promised another pull request. A bit late because flu.
- generic pipe crc from Tomeu, required a backmerge to apply
- fixes for my fumbled drm_plane.c extraction
- display_info cleanup/fixes from Ville
- misc stuff all over
Cheers, Daniel
The following changes since commit c0d5fb4d0
On Mon, Oct 3, 2016 at 12:36 PM, Emil Velikov
wrote:
>>> > +static int zx_gl_get_fmt(uint32_t format)
>>> > +{
>>> > + switch (format) {
>>> > + case DRM_FORMAT_ARGB:
>>> > + case DRM_FORMAT_XRGB:
>>> > + return GL_FMT_ARGB;
>>> > + case DRM_FORMA
On Mon, Oct 3, 2016 at 11:35 AM, Jani Nikula
wrote:
>>220/**
>>221 * @DRM_FB_HELPER_DEFAULT_OPS:
>
> Superfluous @.
Stefan, pls fix this and run
$ make htmldocs
to make sure the output looks correct. Cargo-culting kerneldoc without
checking the output doesn't work too we
On Sun, Oct 2, 2016 at 7:15 PM, Marek Vasut wrote:
>> One thing we could look into for simple pipe helpers is to have a
>> drm_simple_pipe_state which contains both states, and pass that
>> simple_state into all callbacks. Needs a bit of trickery in the
>> atomic_duplicate_state hooks though, so n
On Sun, Oct 2, 2016 at 7:19 PM, Marek Vasut wrote:
>>> /**
>>> * drm_fb_cma_extract_and_attach_fence() - Extract fence from plane and
>>> attach to planestate
>>> * @plane: Which plane
>>> * @state: Plane state attach fence to
>>> *
>>> * If the plane fb has an dma-buf attached, fish out the
On 3 October 2016 at 15:27, Laszlo Ersek wrote:
[snip]
> the v3 patch accidentally removed the similarly customized set_busid
> callback for amdgpu -- drm_pci_set_busid(). Emil caught that error in
> review, hence the v4 patch wouldn't contain the same error.
>
You're spot on - virtio-gpu doesn't
On Sun, Oct 2, 2016 at 5:06 PM, Grazvydas Ignotas wrote:
> Successful sw_init() and hw_init() states are tracked, but not
> late_init(). Various error paths may result in amdgpu_fini() being
> called before .late init is done, so late_init needs to be tracked
> to avoid unexpected or multiple .lat
On Sun, Oct 2, 2016 at 5:06 PM, Grazvydas Ignotas wrote:
> All other amdgpu/dce_v* files have this call, it's only mysteriously
> missing from dce_v11_0.c since the file was added and causes leaks.
>
> Fixes: aaa36a976bbb ("drm/amdgpu: Add initial VI support")
> Signed-off-by: Grazvydas Ignotas
Due to some potential tweaks for the da850 LCDC (for example: the
required memory bandwith settings) we need a separate compatible
for the IP present on the da850 boards.
Suggested-by: Sekhar Nori
Signed-off-by: Bartosz Golaszewski
---
v1 -> v2:
- added the new compatible to the bindings documen
2016-10-01 11:30 GMT+02:00 Sekhar Nori :
> On Friday 30 September 2016 07:22 PM, Bartosz Golaszewski wrote:
>> Due to some potential tweaks for the da850 LCDC (for example: the
>> required memory bandwith settings) we need a separate compatible
>> for the IP present on the da850 boards.
>>
>
> This
On Sun, Oct 2, 2016 at 5:06 PM, Grazvydas Ignotas wrote:
> If this happens (and it recently did), we free a structure while part of
> it is still in use, which results in non-obvious crashes. The way it's
> detached is not trivial (DRM core has to call the connector .destroy
> callback and things
Hi Alex and Baoyou,
I will implement and use most of the functions in Patch2 in the future.
and I will refine the code and fix the build warning.
Thanks very much.
Best Regards
Rex
-Original Message-
From: Alex Deucher [mailto:alexdeuc...@gmail.com]
Sent: Saturday, October 01, 2016 1:
r bug report. (No errors in the dmesg log.) Right now it
works fine.)
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161003/
On Mon, 3 Oct 2016 14:58:11 +0200
Maxime Ripard wrote:
> Hi Boris,
>
> On Fri, Sep 30, 2016 at 06:08:26PM +0200, Boris Brezillon wrote:
> > On Fri, 30 Sep 2016 16:33:20 +0200
> > Maxime Ripard wrote:
> >
> > > Our planes cannot be set at negative coordinates. Make sure we reject such
> > > c
Earlier commit was removing all the users of drm_platform_set_busid and
removed the virtio hunk (which uses the PCI version of the function) by
mistake.
This in itself resulted in user space receiving an incorrect value for
the busid, which in the case below lead to the failure to detect
the (corr
https://bugzilla.kernel.org/show_bug.cgi?id=107001
--- Comment #3 from Timo Valtoaho ---
Fix still working for 4.8.0
--
You are receiving this mail because:
You are watching the assignee of the bug.
On 3 October 2016 at 18:08, Laszlo Ersek wrote:
> On 10/03/16 18:43, Emil Velikov wrote:
>> Earlier commit was removing all the users of drm_platform_set_busid and
>> removed the virtio hunk (which uses the PCI version of the function) by
>> mistake.
>>
>> This in itself resulted in user space rec
ment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161003/4bcc14b0/attachment-0001.html>
On Sat, Sep 24, 2016 at 10:26:24PM +0800, Shawn Guo wrote:
> It adds initial bindings doc for ZTE VOU display controller. HDMI is
> the only supported output device right now.
>
> Signed-off-by: Shawn Guo
> ---
> .../devicetree/bindings/display/zte,vou.txt| 86
> ++
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161003/6f95de1b/attachment.html>
On Tue, Sep 27, 2016 at 12:27:11AM +0200, Peter Rosin wrote:
> The Sharp 15" LQ150X1LG11 panel is an XGA TFT LCD panel.
>
> Signed-off-by: Peter Rosin
> ---
> .../bindings/display/panel/sharp,lq150x1lg11.txt | 36
> ++
> 1 file changed, 36 insertions(+)
> create mode 1006
On Mon, Oct 3, 2016 at 4:15 PM, Laszlo Ersek wrote:
> With kernel commit a325725633c2 applied, the drmGetBusid() call in
> get_drm_info() [hw/xfree86/os-support/linux/lnx_platform.c] returns
> "virtio0".
>
> Without kernel commit a325725633c2 in place, the same function call
> produces "pci::0
quickly I can boot...
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161003/5348061e/attachment.html>
On Mon, Oct 3, 2016 at 9:36 PM, Laszlo Ersek wrote:
> On 10/03/16 21:12, Daniel Vetter wrote:
>> On Mon, Oct 3, 2016 at 4:15 PM, Laszlo Ersek wrote:
>>> With kernel commit a325725633c2 applied, the drmGetBusid() call in
>>> get_drm_info() [hw/xfree86/os-support/linux/lnx_platform.c] returns
>>> "
debug when the computer simply stops responding without any text
etc.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/2016
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161003/d54047a7/attachment.html>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Daniel Kurtz (1):
modetest: add mediatek to module list
Eric Anholt (1):
Simplify the RELEASING steps based on current release.sh.
Flora Cui (1):
amdgpu: expose the AMDGPU_GEM_CREATE_VRAM_CLEARED flag
Kristian H. K
Helpful if your nm executable has a prefix based on the
architecture, for example.
Signed-off-by: Heiko Becker
---
amdgpu/amdgpu-symbol-check | 2 +-
configure.ac | 1 +
etnaviv/etnaviv-symbol-check | 2 +-
exynos/exynos-symbol-check | 2 +-
freedreno/freedren
On 10/03/16 16:15, Laszlo Ersek wrote:
> On 10/03/16 13:34, Emil Velikov wrote:
>> On 30 September 2016 at 18:26, Laszlo Ersek wrote:
>>> On 09/30/16 18:38, Hans de Goede wrote:
Hi,
On 30-09-16 17:33, Laszlo Ersek wrote:
> On 09/30/16 16:59, Hans de Goede wrote:
>> Hi,
>
On 10/03/16 19:08, Laszlo Ersek wrote:
> On 10/03/16 18:43, Emil Velikov wrote:
>> Earlier commit was removing all the users of drm_platform_set_busid and
>> removed the virtio hunk (which uses the PCI version of the function) by
>> mistake.
>>
>> This in itself resulted in user space receiving an
On 10/03/16 19:28, Emil Velikov wrote:
> On 3 October 2016 at 18:08, Laszlo Ersek wrote:
>> On 10/03/16 18:43, Emil Velikov wrote:
>>> Earlier commit was removing all the users of drm_platform_set_busid and
>>> removed the virtio hunk (which uses the PCI version of the function) by
>>> mistake.
>>
On 10/03/16 13:34, Emil Velikov wrote:
> On 30 September 2016 at 18:26, Laszlo Ersek wrote:
>> On 09/30/16 18:38, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 30-09-16 17:33, Laszlo Ersek wrote:
On 09/30/16 16:59, Hans de Goede wrote:
> Hi,
>
> On 30-09-16 16:51, Laszlo Ersek wrote:
>>
On 10/03/16 21:12, Daniel Vetter wrote:
> On Mon, Oct 3, 2016 at 4:15 PM, Laszlo Ersek wrote:
>> With kernel commit a325725633c2 applied, the drmGetBusid() call in
>> get_drm_info() [hw/xfree86/os-support/linux/lnx_platform.c] returns
>> "virtio0".
>>
>> Without kernel commit a325725633c2 in place
Before commit a325725633c2 ("drm: Lobotomize set_busid nonsense for !pci
drivers"), several DRM drivers for platform devices used to expose an
explicit "drm_driver.set_busid" callback, invariably backed by
drm_platform_set_busid().
Commit a325725633c2 removed drm_platform_set_busid(), along with t
On 10/03/16 17:00, Emil Velikov wrote:
> On 3 October 2016 at 15:27, Laszlo Ersek wrote:
> [snip]
>> the v3 patch accidentally removed the similarly customized set_busid
>> callback for amdgpu -- drm_pci_set_busid(). Emil caught that error in
>> review, hence the v4 patch wouldn't contain the same
On 10/03/16 18:43, Emil Velikov wrote:
> Earlier commit was removing all the users of drm_platform_set_busid and
> removed the virtio hunk (which uses the PCI version of the function) by
> mistake.
>
> This in itself resulted in user space receiving an incorrect value for
> the busid, which in the
On 10/03/16 22:34, Daniel Vetter wrote:
> On Mon, Oct 3, 2016 at 9:36 PM, Laszlo Ersek wrote:
>> On 10/03/16 21:12, Daniel Vetter wrote:
>>> On Mon, Oct 3, 2016 at 4:15 PM, Laszlo Ersek wrote:
With kernel commit a325725633c2 applied, the drmGetBusid() call in
get_drm_info() [hw/xfree86/
75 matches
Mail list logo
