[PATCH v2 1/4] scripts/kernel-doc: Adding cross-reference links to html documentation.
On Tue, 28 Jul 2015 16:45:15 -0300 Danilo Cesar Lemes de Paula wrote: > Functions, Structs and Parameters definitions on kernel documentation > are pure cosmetic, it only highlights the element. > > To ease the navigation in the documentation we should use inside > those tags so readers can easily jump between methods directly. > > This was discussed in 2014[1] and is implemented by getting a list > of from the DocBook XML to generate a database. Then it looks > for , and tags that matches the ones in > the database. As it only links existent references, no broken links are > added. So I had some airplane time today and was able to mess with this some. I can't make it break anymore, and it clearly improves the resulting documentation, so I've applied it to the docs tree for 4.3. I want to look at the rest of the stuff a bit more and play with it, but it's hard to imagine why we wouldn't want that as well. I'm a bit more leery just because it adds another dependency to the build, even if it's an optional dependency. My thinking at the moment is to apply it shortly after the merge window so it can have a long soak in linux-next before a 4.4 merge; hope that sounds good. Thanks for doing this work, jon
[Intel-gfx] [PATCH v2 00/22] Enable gpu switching on the MacBook Pro
Hi Daniel, On Wed, Aug 12, 2015 at 11:10:59PM +0200, Daniel Vetter wrote: > Yes just squash and mention that the patch is based on work from > $list_of_other_authors, plus cc them. There's not much point in > acknowledging when people write broken patches ;-) As you requested I've squashed the first 7 patches and I'll post the resulting 3 replacement patches to dri-devel immediately after sending this e-mail. I've also overhauled locking. These 3 patches lay the groundwork for DDC switching with gmux. The subsequent patches in the series mostly concern reprobing and though I've made locking-related changes to these as well, I don't want to spam the list with them again until we have reached consensus how reprobing should be implemented: On Thu, Aug 13, 2015 at 08:50:47AM +0200, Daniel Vetter wrote: > EDEFERREDPROBE isn't something that gets returned to userspace, it's > just internal handling so that the kernel knows there's a depency > issue and it needs to retry probing once other drivers have finished > loading. It is the generic means linux has to handle cross-driver > depencies which aren't reflected in the bus hierarchy. > > I.e. it's just something to make sure that apple-gmux is fully loaded > before i915/nouveau. The driver _will_ be initialized eventually. Aha, so you want to stall initialization of i915/nouveau/radeon *completely* until apple-gmux is loaded. So how do you determine if initialization should be stalled? You would have to hardcode DMIs for all MacBook Pro models. I just counted it, there are 5 DMIs which require apple-gmux, 2 DMIs which require nouveau and 1 DMI which requires radeon (they require nouveau/radeon for proxying, apple-gmux won't help these models). And every year you would have to add another DMI for the latest MacBook Pro model. People using the latest model with an older kernel won't be able to use switching and may open support tickets. And if the module required for initialization is not installed or has a different version than the kernel, i915 won't initialize at all, which will be another source for support cases that you'll have to deal with. I think this doesn't scale and it shows that it's the wrong approach. vga_switcheroo *knows* when the handler registers, or the driver to proxy AUX, and it can *notify* the inactive GPU's driver. No need to hardcode DMIs, keep it simple. And there *is* already a callback to notify drivers that they should reprobe their outputs: * struct drm_mode_config_funcs - basic driver provided mode setting functions * @output_poll_changed: function to handle output configuration changes > On Thu, Aug 13, 2015 at 1:37 AM, Lukas Wunner wrote: > > vga_switcheroo calls drm_kms_helper_hotplug_event() when the handler > > registers (patch 11), which will invoke ->output_poll_changed. > > Oh I didn't spot that one. This kind of layering inversions generally > leads to deadlocks and fun stuff. Please elaborate why you think it's a layering inversion to call drm_kms_helper_hotplug_event() from vga_switcheroo. > Also reprobing lvds/edp is just a > side-effect when you have fbdev emulation enabled. No, even though ->output_poll_changed is most commonly used to update the fbcon output configuration, it gets called even if fbdev emulation is disabled, and I've changed i915's callback in patch 13 so that the LVDS/eDP connectors are reprobed even if CONFIG_DRM_I915_FBDEV is not set. > If we go with this re-probing approach then we definitely > need a new hook in vga-switcheroo Why? From my point of view, drm_kms_helper_hotplug_event() already does the job. The only problem is that i915 removes LVDS and eDP connectors from the mode configuration if they can't be probed. By contrast, nouveau (and I think radeon) will just keep them, but with status disconnected. I changed i915 with patch 13 to behave identically to nouveau/radeon. (Sorry, I've written this before but I feel like I need to overcommunicate in this medium.) The question is, do you consider it harmful to keep a modeless LVDS or eDP connector in the mode configuration (with status disconnected)? On the MacBooks it works fine but I have no idea if it causes issues on other platforms. If you absolutely positively believe that this causes issues and don't want to change i915's behaviour, then yes indeed we may need a separate vga_switcheroo callback. > and even then there's still the locking problem. The only lock held when calling drm_kms_helper_hotplug_event() from vga_switcheroo is vgasr_mutex. When can this deadlock? Whenever we call a vga_switcheroo function from the driver upon probing outputs, specifically: - vga_switcheroo_client_fb_set() gets called if the fb is recreated on reprobe - vga_switcheroo_lock_ddc() / _unlock_ddc() get called when probing DDC and retrieving the EDID - vga_switcheroo_set_ddc() / _get_ddc() / _set_aux() / get_aux() get called for proxying So we can't lock vgasr_mutex in those functions. In the case of _lock_ddc() /
[PULL] drm-intel-next-fixes
Hi Dave, Bunch more fixes for 4.3, most of it skl fallout. It's not quite all yet, there's still a few more patches pending to enable DDI-E correctly on skl. Also included the dpms atomic work from Maarten since atomic is just a pain and not including would cause piles of conflicts right from the start. Pull request stats are all screwed up because I had to do 2 backmerges here (because atomic is painful) and because there's still some earlier pulls for drm-misc and drm-intel-next pending. I'll be at lpc next week, but Jani will take over 4.3 anyway so shouldn't be any troubles. Cheers, Daniel The following changes since commit 8c10342cb48f3140d9abeadcfd2fa6625d447282: drm/atomic: Update legacy DPMS state during modesets, v3. (2015-07-27 16:23:29 +0200) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-fixes-2015-08-16 for you to fetch changes up to 75067ddecf21271631bc018d2fb23ddd09b66aae: drm/i915: Per-DDI I_boost override (2015-08-14 18:13:09 +0200) AMAN DEEP (1): usb: xhci: Bugfix for NULL pointer deference in xhci_endpoint_init() function Aaron Plattner (1): ALSA: hda - Add new GPU codec ID 0x10de007d to snd-hda Adriana Reus (1): iio: inv-mpu: Specify the expected format/precision for write channels Al Cooper (1): usb: gadget: bdc: fix a driver crash on disconnect Al Viro (1): link_path_walk(): be careful when failing with ENOTDIR Alan Stern (3): USB: OHCI: Fix race between ED unlink and URB submission USB: OHCI: fix bad #define in ohci-tmio.c usb: udc: core: add device_del() call to error pathway Alban Bedel (1): DEVICETREE: Misc fix for the AR7100 SPI controller binding Aleksei Mamlin (1): libata: add ATA_HORKAGE_BROKEN_FPDMA_AA quirk for HP 250GB SATA disk VB0250EAVER Alex Dai (1): drm/i915: Add GuC-related module parameters Alex Deucher (8): drm/amdgpu: implement VCE 3.0 harvesting support (v4) drm/amdgpu/cz: implement voltage validation properly drm/amdgpu/cz/dpm: properly report UVD and VCE clock levels drm/radeon: rework audio detect (v4) drm/radeon: rework audio modeset to handle non-audio hdmi features drm/radeon/combios: add some validation of lvds values drm/amdgpu: clean up init sequence for failures drm/amdgpu: fix rb setting for CZ Alex Gartrell (2): ipvs: fix ipv6 route unreach panic ipvs: skb_orphan in case of forwarding Alex Smith (1): MIPS: SMP: Don't increment irq_count multiple times for call function IPIs Alex Williamson (3): iommu/vt-d: Fix VM domain ID leak vfio: Fix lockdep issue KVM: MTRR: Use default type for non-MTRR-covered gfn before WARN_ON Alexander Drozdov (1): packet: tpacket_snd(): fix signed/unsigned comparison Alexander Duyck (1): fib_trie: Drop unnecessary calls to leaf_pull_suffix Alexandre Courbot (7): drm/ttm: recognize ARM64 arch in ioprot handler drm/nouveau/platform: fix compile error if !CONFIG_IOMMU drm/nouveau/ibus/gk20a: increase SM wait timeout drm/nouveau/fifo/gk104: kick channels when deactivating them drm/nouveau/gr/gf100: wait on bottom half of FE's pipeline drm/nouveau/gr/gf100: wait for GR idle after GO_IDLE bundle drm/nouveau/nouveau/ttm: fix tiled system memory with Maxwell Alexei Potashnik (6): qla2xxx: delay plogi/prli ack until existing sessions are deleted qla2xxx: Abort stale cmds on qla_tgt_wq when plogi arrives qla2xxx: added sess generations to detect RSCN update races qla2xxx: disable scsi_transport_fc registration in target mode qla2xxx: drop cmds/tmrs arrived while session is being deleted qla2xxx: terminate exchange when command is aborted by LIO Alexei Starovoitov (1): tc: act_bpf: fix memory leak Alexey Brodkin (2): ARCv2: add knob for DIV_REV in Kconfig ARCv2: allow selection of page size for MMUv4 Alexey Kardashevskiy (1): powerpc/powernv/ioda2: Fix calculation for memory allocated for TCE table Alexey Khoroshilov (1): usb: gadget: mv_udc_core: fix phy_regs I/O memory leak Alistair Popple (1): powerpc/eeh-powernv: Fix unbalanced IRQ warning Amanieu d'Antras (3): signal: fix information leak in copy_siginfo_from_user32 signal: fix information leak in copy_siginfo_to_user signalfd: fix information leak in signalfd_copyinfo Anand Jain (1): btrfs: its btrfs_err() instead of btrfs_error() Andrew Lunn (1): net: fec: Ensure clocks are enabled while using mdio bus Andrzej Pietrasiewicz (2): usb: gadget: f_hid: actually limit the number of instances usb: gadget: f_printer: actually limit the number of instances Andy Grover (2): target: Indicate success if writing 0 to pi_prot_type target: Do not return 0 from aptpl and alua configfs store functions Andy
[Bug 91656] Pillars of Eternity glitch in maps
https://bugs.freedesktop.org/show_bug.cgi?id=91656 --- Comment #2 from christoph.rabel at gmail.com --- Hi have create an apitrace, you can find it here: https://drive.google.com/file/d/0B3-ikYPrROroM3M3SFM4NGd4c0E/view?usp=sharing I noticed something interesting. The trace slows the rendering of the map down. What I perceived previously as "flickering" became kind of an "animation". The map is shown an initially nearly "correct". Then it fades and most of it becomes darker and darker till it becomes as in the screenshot. I can create some screenshots, if they are helpful. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150816/ee30506c/attachment.html>
drm/exynos: g2d userptr memory corruption
Hello, some time ago I checked whether I could use the userptr functionality to do zero-copy from userspace allocated buffers via the G2D. This didn't work out so well, so kinda put this to the bottom of my TODO list. Now that IOMMU support has landed and Jan Kara has rewrote page pinning using frame vectors (see [1]) I gave userptr another try. The results are much better. I'm not experiencing any kernel lockups or sysmmu pagefaults anymore. However the image now suffers from visual artifacts. These images show the nature of the artifacts: http://i.imgur.com/nzT6g3Y.jpg http://i.imgur.com/wkuYI6X.jpg The corruption always manifests itself in these pixel lines of fixed size and wrong color. I have written a testcase as part of libdrm for this issue: https://github.com/tobiasjakobi/libdrm/commit/db8bf6844436598251f67a71fc334b929bfb2b71 It allocates N (N an even number) buffers which are aligned to the system pagesize. Then it does this each iteration: 1) Fill the first N/2 buffers with random data 2) Copy the first half to the second half of the buffers 3) memcmp() first and second half (verification pass) Usually this verification already fails on the first iteration. An interesting observation is that increasing (!) the buffer size (so the amount of pixels that have to copied per buffer grows) makes this issue less likely to happen. With the default 512x512 buffers however it happens, like I said above, almost immediately. I first suspected that the clock rate of the G2D was too high (I overclock the engine from 200MHz to 400MHz here), but even with the default clock there is no change to the behaviour. While looking at the issue I remember this discussion [2] so while ago. Adding Marek to Cc since I guess that this could be related to the IOMMU as well (some missing flushing?). With best wishes, Tobias [1] http://www.spinics.net/lists/linux-samsung-soc/msg45931.html [2] http://lists.freedesktop.org/archives/dri-devel/2014-July/062675.html -- -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 13/14] drm/exynos: use prime helpers
On 2015ë
08ì 16ì¼ 14:26, Inki Dae wrote:
> On 2015ë
07ì 28ì¼ 17:53, Joonyoung Shim wrote:
>> The dma-buf codes of exynos drm is almost same with prime helpers. A
>> difference is that consider DMA_NONE when import dma-buf, but it's wrong
>> and we don't consider it any more, so we can use prime interface.
>
> I think it's good idea to use prime helpers. However, I'm not sure of
> there really is no any corner case the prime helper doesn't consider for
> Vendor SoC yet. So let's have more reviews about this.
Just merged. We could consider something specific to Vendor SoC later
when that is clarified.
Thanks,
Inki Dae
>
> Thanks,
> Inki Dae
>
>>
>> Signed-off-by: Joonyoung Shim
>> ---
>> drivers/gpu/drm/exynos/Makefile| 2 +-
>> drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 289
>> -
>> drivers/gpu/drm/exynos/exynos_drm_dmabuf.h | 20 --
>> drivers/gpu/drm/exynos/exynos_drm_drv.c| 9 +-
>> drivers/gpu/drm/exynos/exynos_drm_gem.c| 79
>> drivers/gpu/drm/exynos/exynos_drm_gem.h| 9 +
>> 6 files changed, 95 insertions(+), 313 deletions(-)
>> delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
>> delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_dmabuf.h
>>
>> diff --git a/drivers/gpu/drm/exynos/Makefile
>> b/drivers/gpu/drm/exynos/Makefile
>> index 7de0b10..95d0306 100644
>> --- a/drivers/gpu/drm/exynos/Makefile
>> +++ b/drivers/gpu/drm/exynos/Makefile
>> @@ -6,7 +6,7 @@ ccflags-y := -Iinclude/drm -Idrivers/gpu/drm/exynos
>> exynosdrm-y := exynos_drm_drv.o exynos_drm_encoder.o \
>> exynos_drm_crtc.o exynos_drm_fbdev.o exynos_drm_fb.o \
>> exynos_drm_buf.o exynos_drm_gem.o exynos_drm_core.o \
>> -exynos_drm_plane.o exynos_drm_dmabuf.o
>> +exynos_drm_plane.o
>>
>> exynosdrm-$(CONFIG_DRM_EXYNOS_IOMMU) += exynos_drm_iommu.o
>> exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD) += exynos_drm_fimd.o
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
>> b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
>> deleted file mode 100644
>> index 619ecdd..000
>> --- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
>> +++ /dev/null
>> @@ -1,289 +0,0 @@
>> -/* exynos_drm_dmabuf.c
>> - *
>> - * Copyright (c) 2012 Samsung Electronics Co., Ltd.
>> - * Author: Inki Dae
>> - *
>> - * This program is free software; you can redistribute it and/or modify it
>> - * under the terms of the GNU General Public License as published by the
>> - * Free Software Foundation; either version 2 of the License, or (at your
>> - * option) any later version.
>> - */
>> -
>> -#include
>> -#include
>> -#include "exynos_drm_dmabuf.h"
>> -#include "exynos_drm_drv.h"
>> -#include "exynos_drm_gem.h"
>> -
>> -#include
>> -
>> -struct exynos_drm_dmabuf_attachment {
>> -struct sg_table *sgt;
>> -enum dma_data_direction dir;
>> -bool is_mapped;
>> -};
>> -
>> -static struct exynos_drm_gem_obj *dma_buf_to_obj(struct dma_buf *buf)
>> -{
>> -return to_exynos_gem_obj(buf->priv);
>> -}
>> -
>> -static int exynos_gem_attach_dma_buf(struct dma_buf *dmabuf,
>> -struct device *dev,
>> -struct dma_buf_attachment *attach)
>> -{
>> -struct exynos_drm_dmabuf_attachment *exynos_attach;
>> -
>> -exynos_attach = kzalloc(sizeof(*exynos_attach), GFP_KERNEL);
>> -if (!exynos_attach)
>> -return -ENOMEM;
>> -
>> -exynos_attach->dir = DMA_NONE;
>> -attach->priv = exynos_attach;
>> -
>> -return 0;
>> -}
>> -
>> -static void exynos_gem_detach_dma_buf(struct dma_buf *dmabuf,
>> -struct dma_buf_attachment *attach)
>> -{
>> -struct exynos_drm_dmabuf_attachment *exynos_attach = attach->priv;
>> -struct sg_table *sgt;
>> -
>> -if (!exynos_attach)
>> -return;
>> -
>> -sgt = exynos_attach->sgt;
>> -if (sgt) {
>> -if (exynos_attach->dir != DMA_NONE)
>> -dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents,
>> -exynos_attach->dir);
>> -sg_free_table(sgt);
>> -}
>> -
>> -kfree(sgt);
>> -kfree(exynos_attach);
>> -attach->priv = NULL;
>> -}
>> -
>> -static struct sg_table *
>> -exynos_gem_map_dma_buf(struct dma_buf_attachment *attach,
>> -enum dma_data_direction dir)
>> -{
>> -struct exynos_drm_dmabuf_attachment *exynos_attach = attach->priv;
>> -struct exynos_drm_gem_obj *gem_obj = dma_buf_to_obj(attach->dmabuf);
>> -struct exynos_drm_gem_buf *buf;
>> -struct sg_table *sgt;
>> -int npages;
>> -
>> -/* just return current sgt if already requested. */
>> -if (exynos_attach->dir == dir && exynos_attach->is_mapped)
>> -return exynos_attach->sgt;
>> -
>> -buf = gem_obj->buffer;
>> -if (!buf) {
>> -DRM_ERROR("buffer is null.\n");
>> -return
[PATCH 13/14] drm/exynos: use prime helpers
On 2015ë
07ì 28ì¼ 17:53, Joonyoung Shim wrote:
> The dma-buf codes of exynos drm is almost same with prime helpers. A
> difference is that consider DMA_NONE when import dma-buf, but it's wrong
> and we don't consider it any more, so we can use prime interface.
I think it's good idea to use prime helpers. However, I'm not sure of
there really is no any corner case the prime helper doesn't consider for
Vendor SoC yet. So let's have more reviews about this.
Thanks,
Inki Dae
>
> Signed-off-by: Joonyoung Shim
> ---
> drivers/gpu/drm/exynos/Makefile| 2 +-
> drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 289
> -
> drivers/gpu/drm/exynos/exynos_drm_dmabuf.h | 20 --
> drivers/gpu/drm/exynos/exynos_drm_drv.c| 9 +-
> drivers/gpu/drm/exynos/exynos_drm_gem.c| 79
> drivers/gpu/drm/exynos/exynos_drm_gem.h| 9 +
> 6 files changed, 95 insertions(+), 313 deletions(-)
> delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_dmabuf.h
>
> diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
> index 7de0b10..95d0306 100644
> --- a/drivers/gpu/drm/exynos/Makefile
> +++ b/drivers/gpu/drm/exynos/Makefile
> @@ -6,7 +6,7 @@ ccflags-y := -Iinclude/drm -Idrivers/gpu/drm/exynos
> exynosdrm-y := exynos_drm_drv.o exynos_drm_encoder.o \
> exynos_drm_crtc.o exynos_drm_fbdev.o exynos_drm_fb.o \
> exynos_drm_buf.o exynos_drm_gem.o exynos_drm_core.o \
> - exynos_drm_plane.o exynos_drm_dmabuf.o
> + exynos_drm_plane.o
>
> exynosdrm-$(CONFIG_DRM_EXYNOS_IOMMU) += exynos_drm_iommu.o
> exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD) += exynos_drm_fimd.o
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> deleted file mode 100644
> index 619ecdd..000
> --- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> +++ /dev/null
> @@ -1,289 +0,0 @@
> -/* exynos_drm_dmabuf.c
> - *
> - * Copyright (c) 2012 Samsung Electronics Co., Ltd.
> - * Author: Inki Dae
> - *
> - * This program is free software; you can redistribute it and/or modify it
> - * under the terms of the GNU General Public License as published by the
> - * Free Software Foundation; either version 2 of the License, or (at your
> - * option) any later version.
> - */
> -
> -#include
> -#include
> -#include "exynos_drm_dmabuf.h"
> -#include "exynos_drm_drv.h"
> -#include "exynos_drm_gem.h"
> -
> -#include
> -
> -struct exynos_drm_dmabuf_attachment {
> - struct sg_table *sgt;
> - enum dma_data_direction dir;
> - bool is_mapped;
> -};
> -
> -static struct exynos_drm_gem_obj *dma_buf_to_obj(struct dma_buf *buf)
> -{
> - return to_exynos_gem_obj(buf->priv);
> -}
> -
> -static int exynos_gem_attach_dma_buf(struct dma_buf *dmabuf,
> - struct device *dev,
> - struct dma_buf_attachment *attach)
> -{
> - struct exynos_drm_dmabuf_attachment *exynos_attach;
> -
> - exynos_attach = kzalloc(sizeof(*exynos_attach), GFP_KERNEL);
> - if (!exynos_attach)
> - return -ENOMEM;
> -
> - exynos_attach->dir = DMA_NONE;
> - attach->priv = exynos_attach;
> -
> - return 0;
> -}
> -
> -static void exynos_gem_detach_dma_buf(struct dma_buf *dmabuf,
> - struct dma_buf_attachment *attach)
> -{
> - struct exynos_drm_dmabuf_attachment *exynos_attach = attach->priv;
> - struct sg_table *sgt;
> -
> - if (!exynos_attach)
> - return;
> -
> - sgt = exynos_attach->sgt;
> - if (sgt) {
> - if (exynos_attach->dir != DMA_NONE)
> - dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents,
> - exynos_attach->dir);
> - sg_free_table(sgt);
> - }
> -
> - kfree(sgt);
> - kfree(exynos_attach);
> - attach->priv = NULL;
> -}
> -
> -static struct sg_table *
> - exynos_gem_map_dma_buf(struct dma_buf_attachment *attach,
> - enum dma_data_direction dir)
> -{
> - struct exynos_drm_dmabuf_attachment *exynos_attach = attach->priv;
> - struct exynos_drm_gem_obj *gem_obj = dma_buf_to_obj(attach->dmabuf);
> - struct exynos_drm_gem_buf *buf;
> - struct sg_table *sgt;
> - int npages;
> -
> - /* just return current sgt if already requested. */
> - if (exynos_attach->dir == dir && exynos_attach->is_mapped)
> - return exynos_attach->sgt;
> -
> - buf = gem_obj->buffer;
> - if (!buf) {
> - DRM_ERROR("buffer is null.\n");
> - return ERR_PTR(-ENOMEM);
> - }
> -
> - npages = buf->size >> PAGE_SHIFT;
> -
> - sgt = drm_prime_pages_to_sg(buf->pages, npages);
> - if (IS_ERR(sgt))
> - goto err;
> -
> - if (dir != DMA_NONE) {
> - if (!dma_map_sg(attach->dev,
[PATCH 10/14] drm/exynos: remove function check_gem_flags
On 2015ë
07ì 28ì¼ 17:53, Joonyoung Shim wrote:
> The function check_gem_flags is too simple, so it's better to move codes
> in each consumer functions.
>
> Signed-off-by: Joonyoung Shim
> ---
> drivers/gpu/drm/exynos/exynos_drm_gem.c | 24
> 1 file changed, 8 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index ab7d029..03e85d8 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -20,16 +20,6 @@
> #include "exynos_drm_buf.h"
> #include "exynos_drm_iommu.h"
>
> -static int check_gem_flags(unsigned int flags)
> -{
> - if (flags & ~(EXYNOS_BO_MASK)) {
> - DRM_ERROR("invalid flags.\n");
> - return -EINVAL;
> - }
> -
> - return 0;
> -}
> -
> static void update_vm_cache_attr(struct exynos_drm_gem_obj *obj,
> struct vm_area_struct *vma)
> {
> @@ -169,6 +159,11 @@ struct exynos_drm_gem_obj *exynos_drm_gem_create(struct
> drm_device *dev,
> struct exynos_drm_gem_buf *buf;
> int ret;
>
> + if (flags & ~(EXYNOS_BO_MASK)) {
> + DRM_ERROR("invalid flags.\n");
> + return ERR_PTR(-EINVAL);
> + }
> +
> if (!size) {
> DRM_ERROR("invalid size.\n");
> return ERR_PTR(-EINVAL);
> @@ -176,10 +171,6 @@ struct exynos_drm_gem_obj *exynos_drm_gem_create(struct
> drm_device *dev,
>
> size = roundup_gem_size(size, flags);
>
> - ret = check_gem_flags(flags);
> - if (ret)
> - return ERR_PTR(ret);
> -
> buf = exynos_drm_init_buf(dev, size);
> if (!buf)
> return ERR_PTR(-ENOMEM);
> @@ -584,9 +575,10 @@ int exynos_drm_gem_mmap(struct file *filp, struct
> vm_area_struct *vma)
> obj = vma->vm_private_data;
> exynos_gem_obj = to_exynos_gem_obj(obj);
>
> - ret = check_gem_flags(exynos_gem_obj->flags);
> - if (ret)
> + if (exynos_gem_obj->flags & ~(EXYNOS_BO_MASK)) {
> + DRM_ERROR("invalid flags.\n");
> goto err_close_vm;
> + }
I will remove above checking as Daniel Stone commented because user
space cannot control the flag.
Thanks,
Inki Dae
>
> update_vm_cache_attr(exynos_gem_obj, vma);
>
>
[PATCH 09/14] drm/exynos: remove call to drm_gem_free_mmap_offset()
On 2015ë 07ì 28ì¼ 17:53, Joonyoung Shim wrote: > The drm_gem_object_release() function already performs this cleanup, > so there is no reason to do it explicitly. > > Signed-off-by: Joonyoung Shim > --- > drivers/gpu/drm/exynos/exynos_drm_gem.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c > b/drivers/gpu/drm/exynos/exynos_drm_gem.c > index c76aa8a..ab7d029 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c > @@ -100,8 +100,6 @@ out: > exynos_drm_fini_buf(obj->dev, buf); > exynos_gem_obj->buffer = NULL; > > - drm_gem_free_mmap_offset(obj); > - > /* release file pointer to gem object. */ > drm_gem_object_release(obj); > > @@ -600,7 +598,6 @@ int exynos_drm_gem_mmap(struct file *filp, struct > vm_area_struct *vma) > > err_close_vm: > drm_gem_vm_close(vma); > - drm_gem_free_mmap_offset(obj); Without previous patch, drm_gem_free_mmap_offset is required. I guess the reason you removed above line is that you thought drm_gem_object_release function would be called by drm_gem_vm_close function which drops a reference of the gem object. However, drm_gem_vm_close should be a pair with drm_gem_vm_open function. These will be called whenever a process opens or closes the VMA. So the reference count of the gem object had already been taken by open operation when a new reference to the VMA had been created. Thanks, Inki Dae > > return ret; > } >
[PATCH 08/14] drm/exynos: create a fake mmap offset with gem creation
On 2015ë
07ì 28ì¼ 17:53, Joonyoung Shim wrote:
> Don't create a fake mmap offset in exynos_drm_gem_dumb_map_offset. If
> not, it will call drm_gem_create_mmap_offset whenever user requests
> DRM_IOCTL_MODE_MAP_DUMB ioctl.
This patch makes drm_gem_create_mmap_offset to be called even in case of
not using dumb* interfaces. I.e.,
exynos_drm_gem_create_ioctl -> exynos_drm_gem_mmap
And drm_gem_create_mmap_offset checks if vma_node was already allocated
or not so this patch doesn't make sense.
Thanks,
Inki Dae
>
> Signed-off-by: Joonyoung Shim
> ---
> drivers/gpu/drm/exynos/exynos_drm_gem.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index 550d267..c76aa8a 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -151,6 +151,13 @@ struct exynos_drm_gem_obj *exynos_drm_gem_init(struct
> drm_device *dev,
> return ERR_PTR(ret);
> }
>
> + ret = drm_gem_create_mmap_offset(obj);
> + if (ret < 0) {
> + drm_gem_object_release(obj);
> + kfree(exynos_gem_obj);
> + return ERR_PTR(ret);
> + }
> +
> DRM_DEBUG_KMS("created file object = 0x%x\n", (unsigned int)obj->filp);
>
> return exynos_gem_obj;
> @@ -521,14 +528,9 @@ int exynos_drm_gem_dumb_map_offset(struct drm_file
> *file_priv,
> goto unlock;
> }
>
> - ret = drm_gem_create_mmap_offset(obj);
> - if (ret)
> - goto out;
> -
> *offset = drm_vma_node_offset_addr(>vma_node);
> DRM_DEBUG_KMS("offset = 0x%lx\n", (unsigned long)*offset);
>
> -out:
> drm_gem_object_unreference(obj);
> unlock:
> mutex_unlock(>struct_mutex);
>
[PATCH 02/14] drm/exynos: remove function convert_to_vm_err_msg
On 2015ë
07ì 28ì¼ 17:53, Joonyoung Shim wrote:
> The convert_to_vm_err_msg is called just once by exynos_drm_gem_fault,
> so it's simple not to use the function.
>
> Signed-off-by: Joonyoung Shim
> ---
> drivers/gpu/drm/exynos/exynos_drm_gem.c | 33
> +
> 1 file changed, 9 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index d320acd..752cb7c 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -20,29 +20,6 @@
> #include "exynos_drm_buf.h"
> #include "exynos_drm_iommu.h"
>
> -static unsigned int convert_to_vm_err_msg(int msg)
> -{
> - unsigned int out_msg;
> -
> - switch (msg) {
> - case 0:
> - case -ERESTARTSYS:
> - case -EINTR:
> - out_msg = VM_FAULT_NOPAGE;
> - break;
> -
> - case -ENOMEM:
> - out_msg = VM_FAULT_OOM;
> - break;
> -
> - default:
> - out_msg = VM_FAULT_SIGBUS;
> - break;
> - }
> -
> - return out_msg;
> -}
> -
> static int check_gem_flags(unsigned int flags)
> {
> if (flags & ~(EXYNOS_BO_MASK)) {
> @@ -600,7 +577,15 @@ int exynos_drm_gem_fault(struct vm_area_struct *vma,
> struct vm_fault *vmf)
>
> mutex_unlock(>struct_mutex);
>
> - return convert_to_vm_err_msg(ret);
> + switch (ret) {
> + case 0:
> + case -ERESTARTSYS:
You missed -EINTR but I can modify it.
Thanks,
Inki Dae
> + return VM_FAULT_NOPAGE;
> + case -ENOMEM:
> + return VM_FAULT_OOM;
> + default:
> + return VM_FAULT_SIGBUS;
> + }
> }
>
> int exynos_drm_gem_mmap(struct file *filp, struct vm_area_struct *vma)
>
[PATCH] drm: make sure to check callbacks of ENCODER and CRTC helpers
This patch fixes NULL pointer access issues to ENCODER
and CRTC drivers.
Vendor specific DRM KMS drivers may not set their helper callbacks
to ENCODER dn CRTC drivers. In this case, that will incur NULL
pointer access when modeset is tried.
So this patch makes sure to check if the callbacks are NULL or not.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/drm_crtc_helper.c | 44 ++-
1 file changed, 29 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index ef53475..aa1f42f 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -318,16 +318,22 @@ bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
}
encoder_funcs = encoder->helper_private;
- if (!(ret = encoder_funcs->mode_fixup(encoder, mode,
- adjusted_mode))) {
- DRM_DEBUG_KMS("Encoder fixup failed\n");
- goto done;
+ if (encoder_funcs->mode_fixup) {
+ ret = encoder_funcs->mode_fixup(encoder, mode,
+ adjusted_mode);
+ if (!ret) {
+ DRM_DEBUG_KMS("Encoder fixup failed\n");
+ goto done;
+ }
}
}
- if (!(ret = crtc_funcs->mode_fixup(crtc, mode, adjusted_mode))) {
- DRM_DEBUG_KMS("CRTC fixup failed\n");
- goto done;
+ if (crtc_funcs->mode_fixup) {
+ ret = crtc_funcs->mode_fixup(crtc, mode, adjusted_mode);
+ if (!ret) {
+ DRM_DEBUG_KMS("CRTC fixup failed\n");
+ goto done;
+ }
}
DRM_DEBUG_KMS("[CRTC:%d]\n", crtc->base.id);
@@ -343,21 +349,26 @@ bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
encoder_funcs = encoder->helper_private;
/* Disable the encoders as the first thing we do. */
- encoder_funcs->prepare(encoder);
+ if (encoder_funcs->prepare)
+ encoder_funcs->prepare(encoder);
drm_bridge_post_disable(encoder->bridge);
}
drm_crtc_prepare_encoders(dev);
- crtc_funcs->prepare(crtc);
+ if (crtc_funcs->prepare)
+ crtc_funcs->prepare(crtc);
/* Set up the DPLL and any encoders state that needs to adjust or depend
* on the DPLL.
*/
- ret = !crtc_funcs->mode_set(crtc, mode, adjusted_mode, x, y, old_fb);
- if (!ret)
- goto done;
+ if (crtc_funcs->mode_set) {
+ ret = !crtc_funcs->mode_set(crtc, mode, adjusted_mode, x, y,
+ old_fb);
+ if (!ret)
+ goto done;
+ }
drm_for_each_encoder(encoder, dev) {
@@ -368,13 +379,15 @@ bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
encoder->base.id, encoder->name,
mode->base.id, mode->name);
encoder_funcs = encoder->helper_private;
- encoder_funcs->mode_set(encoder, mode, adjusted_mode);
+ if (encoder_funcs->mode_set)
+ encoder_funcs->mode_set(encoder, mode, adjusted_mode);
drm_bridge_mode_set(encoder->bridge, mode, adjusted_mode);
}
/* Now enable the clocks, plane, pipe, and connectors that we set up. */
- crtc_funcs->commit(crtc);
+ if (crtc_funcs->commit)
+ crtc_funcs->commit(crtc);
drm_for_each_encoder(encoder, dev) {
@@ -384,7 +397,8 @@ bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
drm_bridge_pre_enable(encoder->bridge);
encoder_funcs = encoder->helper_private;
- encoder_funcs->commit(encoder);
+ if (encoder_funcs->commit)
+ encoder_funcs->commit(encoder);
drm_bridge_enable(encoder->bridge);
}
--
1.9.1
[PATCH] drm/atomic: do not call ww_acquire_done in drm_atomic_check_only
This patch fixes warning case when two more crtc driver are enabled and two more atomic checking are tried at booting time. With fbcon, modeset operation is performed at booting time. In this case, if two mode crtc drivers are enabled, then drm_atomic_check_only function will be called by restore_fbdev_mode function - the value of fb_helper->crtc_count is bigger than 1 - two more times. So that will incur warning by below line of ww_acquire_done, DEBUG_LOCKS_WARN_ON(ctx->done_acquire); ctx->done_acquire = 1; ctx->done_acquire became 1 when drm_mode_set_config_internal for first crtc driver was called, and then ctx->done_acquire becomes 2 when drm_mode_set_con_internal for second crtc driver was called. So the function, ww_acqure_done(), should be called at more top function than at drm_atomic_check_only() to make sure that no one tries to acquire more locks. Signed-off-by: Inki Dae --- drivers/gpu/drm/drm_atomic.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 1066e4b..4349154 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -1230,9 +1230,6 @@ int drm_atomic_check_only(struct drm_atomic_state *state) } } - if (ret == 0) - ww_acquire_done(>acquire_ctx->ww_ctx); - return ret; } EXPORT_SYMBOL(drm_atomic_check_only); -- 1.9.1
[Bug 91656] Pillars of Eternity glitch in maps
https://bugs.freedesktop.org/show_bug.cgi?id=91656 --- Comment #1 from Marek Olšák --- Would you please bisect or create an apitrace that reproduces the issue? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150816/81567a50/attachment.html>
[Bug 91656] Pillars of Eternity glitch in maps
https://bugs.freedesktop.org/show_bug.cgi?id=91656 Bug ID: 91656 Summary: Pillars of Eternity glitch in maps Product: Mesa Version: git Hardware: Other OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel at lists.freedesktop.org Reporter: christoph.rabel at gmail.com QA Contact: dri-devel at lists.freedesktop.org There is a regression/graphical glitch when playing Pillars of Eternity. When I use the ingame map, it is partly "dark/black". You can find a screenshot here: http://images.akamai.steamusercontent.com/ugc/439450977393999113/19DF4F643F0C4BB058665F056DBC4600D669ED7B/ The map looks fine with regular Ubuntu drivers (10.1.3), I checked a couple of days ago with a reinstall (my harddisk broke). After an "upgrade" to oibaf repository, the glitch appeared. The glitch was not there mid-June with 10.6(?) or so. I used oibaf then too, but didn't play for a month. It was probably introduced about June 15 or later. (Maybe a bit earlier, I don't upgrade the beta drivers every day). It was there when I started playing again July 18th. My card is a Radeon 4870: OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD RV770 OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.0.0-devel (git-28ed1e0 2015-08-14 trusty-oibaf-ppa) If you need me to test something or need further information, please feel free to ask. (Enable debug output somehow?) I have browsed PoE logfiles and /var/log, but couldn't find anything that looked even vaguely related. No errors when loading the map or displaying it. (Btw.: Congrats to Mesa 11!) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150816/4cc9028c/attachment.html>
[PATCH 2/4] drm: Add support for ARM's HDLCD controller.
Hi Liviu, On 5 August 2015 at 15:28, Liviu Dudau wrote: > The HDLCD controller is a display controller that supports resolutions > up to 4096x4096 pixels. It is present on various development boards > produced by ARM Ltd and emulated by the latest Fast Models from the > company. > I believe there is a unofficial requirement(?) for new drm drivers to use atomic modesetting. Not 100% sure on this one though. The following drivers: tegra, msm, rcar-du, i915, and Daniel's blog [1] [2] cat provide some information on the topic. The driver seems to has has a bit of dead code guarded by HDLCD_*_UNDERRUN. Perhaps these macros should become build or runtime switch(es) ? Most DRM drivers do not threat dma, bus_error, vsync and/or underrun interrupts as debug functionality. They are of limited use in this driver, presently, yet the CONFIG_DEBUG_FS guard seems a bit strange imho. Cheers, Emil [1] http://blog.ffwll.ch/2014/11/atomic-modeset-support-for-kms-drivers.html [2] http://blog.ffwll.ch/2015/01/update-for-atomic-display-updates.html
[Intel-gfx] [PATCH] drm/mm: Do DRM_MM_CREATE_TOP adj_start calculation after color_adjust
On Sun, Aug 16, 2015 at 04:02:28AM +0100, Michel Thierry wrote: > The adj_start calculation for DRM_MM_CREATE_TOP should happen after > mm->color_adjust. There was an inconsistency between > drm_mm_insert_helper_range > and drm_mm_insert_helper, as the later was already updating after > color_adjust. > > Didn't spot it before, as color_adjust is only done in systems without > LLC. But I'm not aware of anybody using this test case yet. > > Signed-off-by: Michel Thierry I sent this patch a few years ago, when I was using a top-down allocator before llc and I have a similar patch in my tree which I kept meaning to polish up and warn you about before PIN_HIGH. Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre
[Bug 53118] Rendering error in unigine heaven when GL_ARB_shader_bit_encoding is used.
https://bugs.freedesktop.org/show_bug.cgi?id=53118 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Andreas Boll --- It works for me. Tested with unigine heaven 4.0 and enabled GL_ARB_shader_bit_encoding. Gallium 0.4 on AMD BARTS 3.3 (Core Profile) Mesa 10.6.4 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150816/feb03789/attachment-0001.html>
[Bug 91256] Xorg dies - monitor goes to black and after a few seconds came back
https://bugs.freedesktop.org/show_bug.cgi?id=91256 --- Comment #3 from gangeld at gmail.com --- Created attachment 117717 --> https://bugs.freedesktop.org/attachment.cgi?id=117717=edit xorg log file The issue is still exists. I attached my xorg log file. I'm using now kernel: 4.1.2 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150816/2a39c123/attachment.html>
[PATCH] drm/mm: Do DRM_MM_CREATE_TOP adj_start calculation after color_adjust
The adj_start calculation for DRM_MM_CREATE_TOP should happen after
mm->color_adjust. There was an inconsistency between
drm_mm_insert_helper_range
and drm_mm_insert_helper, as the later was already updating after
color_adjust.
Didn't spot it before, as color_adjust is only done in systems without
LLC. But I'm not aware of anybody using this test case yet.
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/drm_mm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 3427b11..04de6fd 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -267,12 +267,12 @@ static void drm_mm_insert_helper_range(struct drm_mm_node
*hole_node,
if (adj_end > end)
adj_end = end;
- if (flags & DRM_MM_CREATE_TOP)
- adj_start = adj_end - size;
-
if (mm->color_adjust)
mm->color_adjust(hole_node, color, _start, _end);
+ if (flags & DRM_MM_CREATE_TOP)
+ adj_start = adj_end - size;
+
if (alignment) {
u64 tmp = adj_start;
unsigned rem;
--
2.5.0
[PATCH] drm/nouveau/fifo: fix simple_return.cocci warnings
drivers/gpu/drm/nouveau/nvkm/engine/fifo/g84.c:396:1-4: WARNING: end returns can be simpified Simplify a trivial if-return sequence. Possibly combine with a preceding function call. Generated by: scripts/coccinelle/misc/simple_return.cocci Signed-off-by: Fengguang Wu --- g84.c |6 +- 1 file changed, 1 insertion(+), 5 deletions(-) --- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/g84.c +++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/g84.c @@ -393,12 +393,8 @@ g84_fifo_context_ctor(struct nvkm_object if (ret) return ret; - ret = nvkm_gpuobj_new(nv_object(base), nv_object(base), 0x0100, + return nvkm_gpuobj_new(nv_object(base), nv_object(base), 0x0100, 0x100, NVOBJ_FLAG_ZERO_ALLOC, >ramfc); - if (ret) - return ret; - - return 0; } static struct nvkm_oclass
[PATCH] drm/nouveau/fifo: fix simple_return.cocci warnings
drivers/gpu/drm/nouveau/nvkm/engine/fifo/gf100.c:340:1-4: WARNING: end returns can be simpified Simplify a trivial if-return sequence. Possibly combine with a preceding function call. Generated by: scripts/coccinelle/misc/simple_return.cocci Signed-off-by: Fengguang Wu --- gf100.c |6 +- 1 file changed, 1 insertion(+), 5 deletions(-) --- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gf100.c +++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gf100.c @@ -337,11 +337,7 @@ gf100_fifo_context_ctor(struct nvkm_obje nv_wo32(base, 0x0208, 0x); nv_wo32(base, 0x020c, 0x00ff); - ret = nvkm_vm_ref(nvkm_client(parent)->vm, >vm, base->pgd); - if (ret) - return ret; - - return 0; + return nvkm_vm_ref(nvkm_client(parent)->vm, >vm, base->pgd); } static void
[PATCH v2 11/11] drm/exynos: remove struct exynos_drm_encoder layer
2015-08-13 0:54 GMT+09:00 Gustavo Padovan : > 2015-08-12 Gustavo Padovan : > >> Hi Inki, >> >> 2015-08-11 Inki Dae : >> >> > On 2015ë 08ì 11ì¼ 09:38, Gustavo Padovan wrote: >> > > Hi Inki, >> > > >> > > 2015-08-07 Inki Dae : >> > > >> > >> Hi Gustavo, >> > >> >> > >> On 2015ë 08ì 06ì¼ 22:31, Gustavo Padovan wrote: >> > >>> From: Gustavo Padovan >> > >>> >> > >>> struct exynos_drm_encoder was justing wrapping struct drm_encoder, it >> > >>> had >> > >>> only a drm_encoder member and the internal exynos_drm_encoders ops that >> > >>> was directly mapped to the drm_encoder helper funcs. >> > >>> >> > >>> So now exynos DRM uses struct drm_encoder directly, this removes >> > >>> completely the struct exynos_drm_encoder. >> > >>> >> > >> >> > >> Trats2 board, which uses Exynos4412 Soc, doesn't work after this patch >> > >> is applied. Below is the booting logs, >> > >> [1.171318] console [ttySAC2] enabled >> > >> [1.175522] 1383.serial: ttySAC3 at MMIO 0x1383 (irq = 60, >> > >> base_baud = 0) is a S3C6400/10 >> > >> [1.185545] [drm] Initialized drm 1.1.0 20060810 >> > >> [1.194104] exynos-drm exynos-drm: bound 11c0.fimd (ops >> > >> fimd_component_ops) >> > >> [1.200352] exynos-drm exynos-drm: bound 11c8.dsi (ops >> > >> exynos_dsi_component_ops) >> > >> [1.207688] [drm] Supports vblank timestamp caching Rev 2 >> > >> (21.10.2013). >> > >> [1.214313] [drm] No driver support for vblank timestamp query. >> > >> [1.220218] [drm] Initialized exynos 1.0.0 20110530 on minor 0 >> > >> >> > >> Booting is locked up here. This patch looks good to me so I tried to >> > >> find why locked up and I found the booting is locked up as soon as >> > >> console_lock function is called. Can you and other guys look into this >> > >> issue? >> > > >> > > I've realized that I left a fix for patch 01 behind, it could be the >> > > cause of this issue. I've just resent this patch with the added v2 fix >> > > up. >> > >> > With above change, still locked up. So your updated patch doesn't >> > resolve this issue. >> > >> > Anyway, I tested it with fbdev emulation relevant patch series[1] and >> > the booting was ok with disabling fbdev emulation as Daniel commented. >> > However, I think the booting should also be ok with fbdev emulation so I >> > don't want for your last patch to be merged to mainline until the issue >> > is resolved. >> >> I've tried to reproduce your issue with these patches on a odroid-x2 >> (exynos4412) but it seems to work fine for me with fbdev emulation >> enabled. In snow and peach-pi it also works fine. We would need >> to debug better on your side to figure out what is breaking for you. > > Can you please git bisect this? So we can figure out which commit is > causing the issue. That would be great. I already commented above, your last patch - 11/11. Without 11/11, it worked well. Did you test odroid-x2 with LVDS based Display panel? If so, it's not different because I tested it with Trats2 board with MIPI-DSI + Display panel. AFAIK, Odroid-x2 board doesn't support MIPI-DSI panel. I will have a pull request soon without 11/11. After that, I think we could find and resolve the issue later. Thanks, Inki Dae > > Gustavo > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
