[Bug 93144] [radeonsi] Alien: Isolation bug
https://bugs.freedesktop.org/show_bug.cgi?id=93144 --- Comment #6 from Nicolai Hähnle --- Could one of you record an apitrace of this behavior? -- 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/20151211/10e7e9f4/attachment.html>
[Bug 92944] [Fiji/LLVM/RadeonSI] CS:GO segfaults in llvm
https://bugs.freedesktop.org/show_bug.cgi?id=92944 --- Comment #9 from Michel Dänzer --- (In reply to Bogar Boris from comment #7) > So i tried to compiled an old revision of mesa but around that date i found > that the mesa fail to configure/compile because of some new virgl driver. Can't you just disable the virgl driver build? If that doesn't work either, please attach the failure output from configure / make. -- 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/20151211/b67ecc5a/attachment.html>
[Bug 93144] [radeonsi] Alien: Isolation bug
https://bugs.freedesktop.org/show_bug.cgi?id=93144 --- Comment #7 from Stepan Bakshaev --- I will try to figure out how and do api trace on saturday. -- 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/20151211/14f76293/attachment.html>
[Bug 93341] GPU lockups on RadeonHD 7770 (radeonsi driver) when running OpenGL games
_PC kernel: [] do_exit+0x80a/0xae0 déc 10 21:49:01 the_PC kernel: [] oops_end+0x9e/0xd0 déc 10 21:49:01 the_PC kernel: [] no_context+0x135/0x380 déc 10 21:49:01 the_PC kernel: [] __bad_area_nosemaphore+0x80/0x1f0 déc 10 21:49:01 the_PC kernel: [] bad_area_nosemaphore+0x13/0x20 déc 10 21:49:01 the_PC kernel: [] __do_page_fault+0xb7/0x400 déc 10 21:49:01 the_PC kernel: [] do_page_fault+0x2f/0x80 déc 10 21:49:01 the_PC kernel: [] page_fault+0x28/0x30 déc 10 21:49:01 the_PC kernel: [] ? radeon_ring_backup+0xda/0x190 [radeon] déc 10 21:49:01 the_PC kernel: [] ? radeon_ring_backup+0x180/0x190 [radeon] déc 10 21:49:01 the_PC kernel: [] ? radeon_irq_kms_disable_hpd+0x73/0x80 [radeon] déc 10 21:49:01 the_PC kernel: [] radeon_gpu_reset+0xd0/0x330 [radeon] déc 10 21:49:01 the_PC kernel: [] ? wake_atomic_t_function+0x70/0x70 déc 10 21:49:01 the_PC kernel: [] ? radeon_fence_wait+0x9f/0xe0 [radeon] déc 10 21:49:01 the_PC kernel: [] radeon_flip_work_func+0x130/0x170 [radeon] déc 10 21:49:01 the_PC kernel: [] process_one_work+0x19e/0x3f0 déc 10 21:49:01 the_PC kernel: [] worker_thread+0x4e/0x450 déc 10 21:49:01 the_PC kernel: [] ? process_one_work+0x3f0/0x3f0 déc 10 21:49:01 the_PC kernel: [] ? process_one_work+0x3f0/0x3f0 déc 10 21:49:01 the_PC kernel: [] kthread+0xd8/0xf0 déc 10 21:49:01 the_PC kernel: [] ? kthread_worker_fn+0x160/0x160 déc 10 21:49:01 the_PC kernel: [] ret_from_fork+0x3f/0x70 déc 10 21:49:01 the_PC kernel: [] ? kthread_worker_fn+0x160/0x160 déc 10 21:49:01 the_PC kernel: Code: c4 08 44 89 e8 5b 41 5c 41 5d 5d c3 4c 89 e7 e8 e7 eb fd ff eb 88 0f 1f 44 00 00 66 66 66 66 90 48 8b 87 90 05 00 00 55 48 89 e5 <48> 8b 40 d8 5d c3 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 déc 10 21:49:01 the_PC kernel: RIP [] kthread_data+0x10/0x20 déc 10 21:49:01 the_PC kernel: RSP déc 10 21:49:01 the_PC kernel: CR2: ffd8 déc 10 21:49:01 the_PC kernel: ---[ end trace 37e2470f6b251993 ]--- déc 10 21:49:01 the_PC kernel: Fixing recursive fault but reboot is needed! -- Reboot -- -- 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/20151211/c32049bb/attachment-0001.html>
[PATCH RFC 0/9] omapdrm/omapfb/omapdss split
On 12/10/2015 07:55 PM, Tomi Valkeinen wrote: > Hi, > > Here's an RFC series to fix the mess we have at the moment with > omapdrm/omapfb/omapdss. > > First, a short background on the current status. We have the following > entities: > > * omapdss, located in drivers/video/fbdev/omap2/dss/. This is a driver for the >display subsystem IPs used on OMAP (and related) SoCs. It offers only a >kernel internal API, and does not implement anything for fbdev or drm. > > * omapdss panels and encoders, located in >drivers/video/fbdev/omap2/displays-new/. These are panel and external > encoder >drivers, which use APIs offered by omapdss driver. These also don't > implement >anything for fbdev or drm. > > * omapdrm, located in drivers/gpu/drm/omapdrm/. This is a drm driver, which >uses omapdss and the panel/encoder drivers to operate the hardware. > > * omapfb, located in drivers/video/fbdev/omap2/omapfb/. This is an fbdev >driver, which uses omapdss and the panel/encoder drivers to operate the >hardware. > > * omap_vout, located in drivers/media/platform/omap/. This is a v4l2 driver, >which uses omapdss and omapfb to implement a v4l2 API for the video > overlays. > > So, on the top level, we have either omapdrm, or omapfb+omap_vout. Both of > those use the same low level drivers. Without going to the historical details > why the architecture is like that, I think it's finally time to change that. > > The situation with omapfb+omap_vout is that it still works, but no new > features > have been added for a long time, and I want to keep it working as it's still > being used. At some point in the future I'd like to remove omapfb and > omap_vout altogether. > > Omapdrm, on the other hand, is being actively developed. Sharing the low level > parts with omapfb makes that development more difficult than it should be. It > also "hides" half of the development, as everything happening in the low level > parts resides under fbdev directory, not in the drm directory. > > I've been wanting to clean this up for a long time, but I haven't figured out > a > very good way to do it. I still haven't, but here's the best way I have come > up > with. > > This series makes a full copy of the low level parts, omapdss and > panel/encoder > drivers. Both omapfb+omap_vout and omapdrm will have their own versions. The > copy omapfb+omap_vout get is a new copy, and the copy that omapdrm gets is > just > the current files moved. This way git will associate the omapdrm version with > the old files. Is it possible to make omapfb get some of the old files (apply.c, overlay.c, manager.c, sysfs files etc)? It might be helpful to have git associate these files with omapfb/omap_vout since they have been the only users of it. After cleanups, these files would eventually be removed in the omapdrm copy, and it would be hard to track their history using the omapfb copy. > > The omapfb+omap_vout versions won't be touched unless there are some big > issues > there. > > The omapdrm versions can be refactored and cleaned up, as the omapfb support > code is no longer needed. We can perhaps also merge omapdss and omapdrm into > the same kernel module. > > This series only does the copy, and the absolutely necessary parts. No further > cleanups are done yet. Ack for the series! Archit > > Tomi > > Tomi Valkeinen (9): >omapfb: allow compilation only if DRM_OMAP is disabled >omapfb: copy omapdss & displays for omapfb >omapdss: remove CONFIG_OMAP2_DSS_VENC from omapdss.h >omapfb/dss: change CONFIG_OMAP* to CONFIG_FB_OMAP* >omapfb/displays: change CONFIG_DISPLAY_* to CONFIG_FB_OMAP2_* >omapfb: take omapfb's prive omapdss into use >omapfb: move vrfb into omapfb >drm/omap: move omapdss & displays under omapdrm >drm/omap: make omapdrm select OMAP2_DSS > > drivers/gpu/drm/Makefile |2 +- > drivers/gpu/drm/omapdrm/Kconfig| 10 +- > drivers/gpu/drm/omapdrm/Makefile |3 + > .../drm/omapdrm/displays}/Kconfig |3 +- > .../drm/omapdrm/displays}/Makefile |0 > .../drm/omapdrm/displays}/connector-analog-tv.c|0 > .../drm/omapdrm/displays}/connector-dvi.c |0 > .../drm/omapdrm/displays}/connector-hdmi.c |0 > .../drm/omapdrm/displays}/encoder-opa362.c |0 > .../drm/omapdrm/displays}/encoder-tfp410.c |0 > .../drm/omapdrm/displays}/encoder-tpd12s015.c |0 > .../drm/omapdrm/displays}/panel-dpi.c |0 > .../drm/omapdrm/displays}/panel-dsi-cm.c |0 > .../omapdrm/displays}/panel-lgphilips-lb035q02.c |0 > .../drm/omapdrm/displays}/panel-nec-nl8048hl11.c |0 > .../omapdrm/displays}/panel-sharp-ls037v7dw01.c|0 > .../drm/omapdrm/displays}/panel-sony-acx565akm.c |0 > .../drm/omapdrm/displays}/panel-tpo-td028ttec1.c |0 > .../drm/omapdrm/d
[RFC PATCH 3/9] drm/rockchip: Convert to support atomic API
On 2015å¹´12æ02æ¥ 22:18, Daniel Stone wrote:
> Hi Mark,
> Thanks for getting back to this.
>
> On 1 December 2015 at 09:31, Mark yao wrote:
>> On 2015å¹´12æ01æ¥ 16:18, Daniel Stone wrote:
>>> On 1 December 2015 at 03:26, Mark Yao wrote:
> + for_each_crtc_in_state(state, crtc, crtc_state, i) {
> + if (!crtc->state->active)
> + continue;
> +
> + rockchip_crtc_wait_for_update(crtc);
> + }
>>> I'd be much more comfortable if this passed in an explicit pointer to
>>> state, or an address to wait for, rather than have wait_for_complete
>>> dig out state with no locking. The latter is potentially racy for
>>> async operations.
>>>
>> Hi Daniel
>> "if this passed in an explicit pointer to state, or an address to wait
>> for", I don't understand, can you point how it work?
> Ah, OK. I mean that rockchip_crtc_wait_for_update takes a drm_crtc
> pointer, and establishes the state from that (e.g.
> crtc->primary->state). This can easily lead to confusion in async
> contexts, as the states attached to a drm_crtc and a drm_plane can
> change here while you wait for it.
>
> It would be better if the call was:
>
> for_each_plane_in_state(state, plane, plane_state, i) {
> if (plane->type == DRM_PLANE_TYPE_PRIMARY)
> rockchip_crtc_wait_for_update(plane_state->crtc, plane_state);
> }
>
> This way it is very clear, and there is no confusion as to which
> request we are waiting to complete.
>
> In general, using crtc->state or plane->state is a very bad idea,
> _except_ in the atomic_check function where you are calculating
> changes (e.g. if (plane_state->fb->pitches[0] !=
> plane->state->fb->pitches[0]) rockchip_plane_state->pitch_changed =
> true). After atomic_check, you should always pass around pointers to
> the plane state explicitly, and avoid using the pointers from drm_crtc
> and drm_plane.
>
> Does that help?
Hi Daniel
Sorry, I don't actually understand why crtc->state or plane->state is no
recommended
except atomic_check, on atomic_update, we need use plane->state, is that
a problem?
I guess that, drm_atomic_helper_swap_state would race with async operations,
so use crtc->state on async stack is not safe. is it correct?
I think we can make asynchronous commit serialize as tegra drm done to
avoid this problem:
86 /* serialize outstanding asynchronous commits */
87 mutex_lock(&tegra->commit.lock);
88 flush_work(&tegra->commit.work);
89
90 /*
91 * This is the point of no return - everything below never
fails except
92 * when the hw goes bonghits. Which means we can commit
the new state on
93 * the software side now.
94 */
95
96 drm_atomic_helper_swap_state(drm, state);
97
98 if (async)
99 tegra_atomic_schedule(tegra, state);
100 else
101 tegra_atomic_complete(tegra, state);
102
103 mutex_unlock(&tegra->commit.lock);
>
if (is_yuv) {
/*
* Src.x1 can be odd when do clip, but yuv plane start
point
* need align with 2 pixel.
*/
- val = (src.x1 >> 16) % 2;
- src.x1 += val << 16;
- src.x2 += val << 16;
+ uint32_t temp = (src->x1 >> 16) % 2;
+
+ src->x1 += temp << 16;
+ src->x2 += temp << 16;
}
>>> I know this isn't new, but moving the plane around is bad. If the user
>>> gives you a pixel boundary that you can't actually use, please reject
>>> the configuration rather than silently trying to fix it up.
>> the origin src.x1 would align with 2 pixel, but when we move the dest
>> window, and do clip by output, the src.x1 may be clipped to odd.
>> regect this configuration may let user confuse, sometimes good, sometimes
>> bad.
> For me, it is more confusing when the display shows something
> different to what I have requested. In some media usecases, doing this
> is a showstopper and will result in products failing acceptance
> testing. Userspace can make a policy decision to try different
> alignments to get _something_ to show (even if it's not what was
> explicitly requested), but doing this in the kernel is inappropriate:
> please just reject it, and have userspace fall back to another
> composition method (e.g. GL) in these cases.
>
-static void vop_plane_destroy(struct drm_plane *plane)
+static void vop_atomic_plane_destroy_state(struct drm_plane *plane,
+ struct drm_plane_state *state)
{
- vop_disable_plane(plane);
- drm_plane_cleanup(plane);
+ struct vop_plane_state *vop_state = to_vop_plane_state(state);
+
+ if (state->fb)
+ drm_framebuffer_unreference(state->fb);
+
+ kfree(vop_
[git pull] drm fixes
Hi Linus, Not too much this time. One nouveau workaround extended to a few more GPUs. Some amdgpu big endian fixes, and a regression fixer. Some vmwgfx fixes One ttm locking fix. One vgaarb fix. Dave. The following changes since commit aa53685549a2cfb5f175b0c4a20bc9aa1e5a1b85: Merge branch 'for-linus-4.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml (2015-12-08 17:22:45 -0800) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to 9f5bd30818c42c6c36a51f93b4df75a2ea2bd85e: vgaarb: fix signal handling in vga_get() (2015-12-11 14:04:44 +1000) Ben Skeggs (1): drm/nouveau/pmu: remove whitelist for PGOB-exit WAR, enable by default Chunming Zhou (1): drm/amdgpu: fix the lost duplicates checking Dan Carpenter (1): drm/vmwgfx: fix a warning message Dave Airlie (3): Merge branch 'linux-4.4' of https://github.com/skeggsb/linux into drm-fixes Merge tag 'vmwgfx-fixes-4.4-151208' of git://people.freedesktop.org/~thomash/linux into drm-fixes Merge branch 'drm-fixes-4.4' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Kirill A. Shutemov (1): vgaarb: fix signal handling in vga_get() Oded Gabbay (3): radeon/cik: Fix GFX IB test on Big-Endian radeon: Fix VCE ring test for Big-Endian systems radeon: Fix VCE IB test on Big-Endian systems Thomas Hellstrom (2): drm/ttm: Fixed a read/write lock imbalance drm/vmwgfx: Implement the cursor_set2 callback v2 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 8 ++ drivers/gpu/drm/nouveau/include/nvkm/core/device.h | 1 - drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c | 35 +--- drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gk104.c| 4 +- drivers/gpu/drm/radeon/cik.c | 6 +- drivers/gpu/drm/radeon/radeon_vce.c| 100 ++--- drivers/gpu/drm/ttm/ttm_lock.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 1 + drivers/gpu/drm/vmwgfx/vmwgfx_drv.h| 1 + drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c| 64 ++--- drivers/gpu/drm/vmwgfx/vmwgfx_kms.h| 7 +- drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c| 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 2 +- drivers/gpu/vga/vgaarb.c | 6 +- 16 files changed, 131 insertions(+), 112 deletions(-)
-next trees and my time this cycle
Hey all, Hopefully all my sub-maintainers are awake and reading this. So since Xmas is coming up and I've got an impending new arrival, I'm betting this merge window might get a bit haphazard. So I'd like people to start telling me now via git pull's what they'd like to get in. I've seen etnaviv, rockchip(?), vc4 gpu api, can I get plans for if people would like these in now, also anything I've missed on the list. Other ARM maintainers (especially exynos) please try and get pull requests in early. I might drop things that come in too late. I expect the x86 folks and others who are pretty regular to not be a problem (i.e. don't be a problem). Especially nouveau early is good for me if you have anything. Dave.
-next trees and my time this cycle
Hi Dave, 2015ë 12ì 11ì¼ 15:58ì Dave Airlie ì´(ê°) ì´ ê¸: > Hey all, > > Hopefully all my sub-maintainers are awake and reading this. > > So since Xmas is coming up and I've got an impending new arrival, I'm > betting this merge window might get a bit haphazard. So I'd like > people to start telling me now via git pull's what they'd like to get > in. > > I've seen etnaviv, rockchip(?), vc4 gpu api, can I get plans for if > people would like these in now, also anything I've missed on the list. > Other ARM maintainers (especially exynos) please try and get pull > requests in early. I might drop things that come in too late. Sorry for late. I am strugging for review and verification of exynos-drm-next tree. This time, exynos drm tree will include below features, - support runtime pm - support dp panel dt binding using of graph concept. - cleanup part of IPP enhancement patch series. Now while I'm reviewing the cleanup part of IPP enhancement patch series, I found out a critical issue so as soon as I and original author resolve it, I will requst GIT PULL at least within next Monday. Thanks, Inki Dae > > I expect the x86 folks and others who are pretty regular to not be a > problem (i.e. don't be a problem). Especially nouveau early is good > for me if you have anything. > > Dave. > >
[PATCH RFC 0/9] omapdrm/omapfb/omapdss split
On 11/12/15 08:14, Archit Taneja wrote: > Is it possible to make omapfb get some of the old files (apply.c, > overlay.c, manager.c, sysfs files etc)? It might be helpful to have git > associate these files with omapfb/omap_vout since they have been the > only users of it. After cleanups, these files would eventually be > removed in the omapdrm copy, and it would be hard to track their history > using the omapfb copy. Good point. Unfortunately I don't know how I could do that... I need to keep all the files for a copy of omapdss intact, otherwise that copy won't work. So I need all the files for omapfb's copy, but I can't remove (i.e. move) any from the remaining copy... However, in the commit where I create the omapfb copy, I can add the original path in the commit description. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151211/e1faa44e/attachment.sig>
[PATCH 1/2] drm: make drm_dev_set_unique() not use a format string
On Wed, Dec 09, 2015 at 12:52:58AM +0100, Nicolas Iooss wrote:
> On 12/09/2015 12:28 AM, Emil Velikov wrote:
> > On 8 December 2015 at 22:12, Nicolas Iooss
> > wrote:
> >> drm_dev_set_unique() uses a format string to define the unique name of a
> >> device. This feature is not used as currently all the calls to this
> >> function either use "%s" as a format string or directly use
> >> dev_name().
> >>
> >> Even though this second kind of call does not introduce security
> >> problems, because there cannot be "%" characters in dev_name() results,
> >> gcc issues a warning when building with -Wformat-security flag
> >> ("warning: format string is not a string literal (potentially
> >> insecure)"). This warning is useful to find real bugs like the one
> >> fixed by commit 3958b79266b1 ("configfs: fix kernel infoleak through
> >> user-controlled format string"). False positives which do not bring
> >> an extra value make the work of finding real bugs harder.
> >>
> >> Therefore remove the format-string feature from drm_dev_set_unique().
> >>
> >> Signed-off-by: Nicolas Iooss
> >> ---
> >> drivers/gpu/drm/drm_drv.c | 11 +++
> >> drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +-
> >> drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +-
> >> include/drm/drmP.h | 2 +-
> >> 4 files changed, 6 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> >> index 7dd6728dd092..20eaa0aae205 100644
> >> --- a/drivers/gpu/drm/drm_drv.c
> >> +++ b/drivers/gpu/drm/drm_drv.c
> >> @@ -797,7 +797,7 @@ EXPORT_SYMBOL(drm_dev_unregister);
> >> /**
> >> * drm_dev_set_unique - Set the unique name of a DRM device
> >> * @dev: device of which to set the unique name
> >> - * @fmt: format string for unique name
> >> + * @name: unique name
> >> *
> >> * Sets the unique name of a DRM device using the specified format string
> >> and
> >> * a variable list of arguments. Drivers can use this at driver probe
> >> time if
> > You might want to also update the above hunk :-)
>
> Indeed, thanks! I will wait a little bit for other feedbacks, read all
> the comments/documentation to see if anything else needs an update and
> submit a v2.
fyi 4.5 window for drm is closing in the next few days (because holidays
and all that). Please resend soon, otherwise it might miss and get delayed
to 4.6.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[Intel-gfx] [PATCH v3 06/14] drm: Add plane->name and use it in debug prints
On Tue, Dec 08, 2015 at 06:41:54PM +0200, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrjälä
>
> Show a sensible name for the plane in debug mesages. The driver
> may supply its own name, otherwise the core genrates the name
> ("plane-0", "plane-1" etc.).
>
> v2: kstrdup() the name passed by the caller (Jani)
> v3: Generate a default name if the driver doesn't supply one
>
> Signed-off-by: Ville Syrjälä
Merged up to this one to drm-misc. I guess given how things align with 4.5
probably easier to pull in the remaining i915 bits for 4.6.
Thanks, Daniel
> ---
> drivers/gpu/drm/drm_atomic.c| 12 ++--
> drivers/gpu/drm/drm_atomic_helper.c | 4 ++--
> drivers/gpu/drm/drm_crtc.c | 30 ++
> include/drm/drm_crtc.h | 2 ++
> 4 files changed, 40 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index feb66895e48c..6a21e5c378c1 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -549,8 +549,8 @@ drm_atomic_get_plane_state(struct drm_atomic_state *state,
> state->planes[index] = plane;
> plane_state->state = state;
>
> - DRM_DEBUG_ATOMIC("Added [PLANE:%d] %p state to %p\n",
> - plane->base.id, plane_state, state);
> + DRM_DEBUG_ATOMIC("Added [PLANE:%d:%s] %p state to %p\n",
> + plane->base.id, plane->name, plane_state, state);
>
> if (plane_state->crtc) {
> struct drm_crtc_state *crtc_state;
> @@ -770,8 +770,8 @@ static int drm_atomic_plane_check(struct drm_plane *plane,
> }
>
> if (plane_switching_crtc(state->state, plane, state)) {
> - DRM_DEBUG_ATOMIC("[PLANE:%d] switching CRTC directly\n",
> - plane->base.id);
> + DRM_DEBUG_ATOMIC("[PLANE:%d:%s] switching CRTC directly\n",
> + plane->base.id, plane->name);
> return -EINVAL;
> }
>
> @@ -1248,8 +1248,8 @@ int drm_atomic_check_only(struct drm_atomic_state
> *state)
> for_each_plane_in_state(state, plane, plane_state, i) {
> ret = drm_atomic_plane_check(plane, plane_state);
> if (ret) {
> - DRM_DEBUG_ATOMIC("[PLANE:%d] atomic core check
> failed\n",
> - plane->base.id);
> + DRM_DEBUG_ATOMIC("[PLANE:%d:%s] atomic core check
> failed\n",
> + plane->base.id, plane->name);
> return ret;
> }
> }
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 6ba3fe5639e4..63f925b75357 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -545,8 +545,8 @@ drm_atomic_helper_check_planes(struct drm_device *dev,
>
> ret = funcs->atomic_check(plane, plane_state);
> if (ret) {
> - DRM_DEBUG_ATOMIC("[PLANE:%d] atomic driver check
> failed\n",
> - plane->base.id);
> + DRM_DEBUG_ATOMIC("[PLANE:%d:%s] atomic driver check
> failed\n",
> + plane->base.id, plane->name);
> return ret;
> }
> }
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index ae2c6c5d48e9..9fe085b2efbf 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1181,6 +1181,18 @@ void drm_encoder_cleanup(struct drm_encoder *encoder)
> }
> EXPORT_SYMBOL(drm_encoder_cleanup);
>
> +static unsigned int drm_num_planes(struct drm_device *dev)
> +{
> + unsigned int num = 0;
> + struct drm_plane *tmp;
> +
> + drm_for_each_plane(tmp, dev) {
> + num++;
> + }
> +
> + return num;
> +}
> +
> /**
> * drm_universal_plane_init - Initialize a new universal plane object
> * @dev: DRM device
> @@ -1224,6 +1236,22 @@ int drm_universal_plane_init(struct drm_device *dev,
> struct drm_plane *plane,
> return -ENOMEM;
> }
>
> + if (name) {
> + va_list ap;
> +
> + va_start(ap, name);
> + plane->name = kvasprintf(GFP_KERNEL, name, ap);
> + va_end(ap);
> + } else {
> + plane->name = kasprintf(GFP_KERNEL, "plane-%d",
> + drm_num_planes(dev));
> + }
> + if (!plane->name) {
> + kfree(plane->format_types);
> + drm_mode_object_put(dev, &plane->base);
> + return -ENOMEM;
> + }
> +
> memcpy(plane->format_types, formats, format_count * sizeof(uint32_t));
> plane->format_count = format_count;
> plane->possible_crtcs = possible_crtcs;
> @@ -1314,6 +1342,8 @@ void drm_plane_cleanup(struct drm_plane *plane)
> if (plane->state && plane->f
[PATCH 0/7] drm: Fix mode pruning
On Thu, Dec 03, 2015 at 11:14:08PM +0200, ville.syrjala at linux.intel.com wrote: > From: Ville Syrjälä > > Turns out I broke mode pruning when the connector mode lists changes > without the connector getting disconnected in between. Mostly a problem > for i-g-t EDID forcing stuff I suppose, but maybe someone is fast enough > that they can swap cables without the system noticing until the new > cable is plugged in. > > Anyway here's the fix, and I also ended up reviewing the way we merge > new and old modes together, and made some changes there. Pulled in the entire series except patch 3 into drm-misc. Thanks, Daniel > > Ville Syrjälä (7): > drm: Don't overwrite UNVERFIED mode status to OK > drm: Rename MODE_UNVERIFIED to MODE_STALE > drm: Reindent enum drm_mode_status > drm: Flatten drm_mode_connector_list_update() a bit > drm: Only merge mode type bits between new probed modes > drm: Drop drm_helper_probe_single_connector_modes_nomerge() > drm/sti: Drop bogus drm_mode_sort() call > > drivers/gpu/drm/drm_modes.c | 56 +- > drivers/gpu/drm/drm_probe_helper.c | 72 ++-- > drivers/gpu/drm/qxl/qxl_display.c| 2 +- > drivers/gpu/drm/sti/sti_hda.c| 2 - > drivers/gpu/drm/virtio/virtgpu_display.c | 2 +- > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 2 +- > include/drm/drm_crtc_helper.h| 4 -- > include/drm/drm_modes.h | 80 > > 8 files changed, 103 insertions(+), 117 deletions(-) > > -- > 2.4.10 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH 1/2] drm: Allow override_edid to override the firmware EDID
On Thu, Dec 10, 2015 at 11:13:56PM +0200, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrjälä
>
> IMO the override_edid should override any default EDID for the
> connector, whether that came in via the connector helper ->get_modes()
> vfunc or via the firmware EDID mechanism.
>
> Cc: Thomas Wood
> Signed-off-by: Ville Syrjälä
Yeah makes sense. And the kerneldoc one looks great, so pulled both into
drm-misc.
-Daniel
> ---
> drivers/gpu/drm/drm_probe_helper.c | 17 -
> 1 file changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> b/drivers/gpu/drm/drm_probe_helper.c
> index 169f1ad1668d..85971a74532d 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -233,17 +233,16 @@ int drm_helper_probe_single_connector_modes(struct
> drm_connector *connector,
> goto prune;
> }
>
> + if (connector->override_edid) {
> + struct edid *edid = (struct edid *)
> connector->edid_blob_ptr->data;
> +
> + count = drm_add_edid_modes(connector, edid);
> + drm_edid_to_eld(connector, edid);
> + } else {
> #ifdef CONFIG_DRM_LOAD_EDID_FIRMWARE
> - count = drm_load_edid_firmware(connector);
> - if (count == 0)
> + count = drm_load_edid_firmware(connector);
> + if (count == 0)
> #endif
> - {
> - if (connector->override_edid) {
> - struct edid *edid = (struct edid *)
> connector->edid_blob_ptr->data;
> -
> - count = drm_add_edid_modes(connector, edid);
> - drm_edid_to_eld(connector, edid);
> - } else
> count = (*connector_funcs->get_modes)(connector);
> }
>
> --
> 2.4.10
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH v2 06/22] drm/exynos: move dma_addr attribute from exynos plane to exynos fb
Hi Marek,
I found out why NULL point access happened. That was incurred by below your
patch,
[PATCH] drm/exynos: move dma_addr attribute from exynos plane to exynos fb
When another crtc driver is hotplugged in runtime such as HDMI or VIDI,
the drm frambuffer object of fb_helper is set to the plane state of the new
crtc driver
so the driver should get the drm framebuffer object from the plane's state or
exynos_plane->pending_fb which is set by exynos_plane_atomic_update function.
After that, I think the drm framebuffer should be set to drm plane as a current
fb
which would be scanned out.
Anyway, I can fix it like below if you are ok.
Thanks,
Inki Dae
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -137,7 +137,7 @@ static void vidi_update_plane(struct exynos_drm_crtc *crtc,
if (ctx->suspended)
return;
- addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);
+ addr = exynos_drm_fb_dma_addr(plane->pending_fb, 0);
DRM_DEBUG_KMS("dma_addr = %pad\n", &addr);
+ plane->base.fb = plane->pending_fb;
if (ctx->vblank_on)
2015ë
12ì 10ì¼ 22:05ì Inki Dae ì´(ê°) ì´ ê¸:
>
>
> 2015ë
11ì 30ì¼ 22:53ì Marek Szyprowski ì´(ê°) ì´ ê¸:
>> DMA address is a framebuffer attribute and the right place for it is
>> exynos_drm_framebuffer not exynos_drm_plane. This patch also introduces
>> helper function for getting dma address of the given framebuffer.
>>
>> Signed-off-by: Marek Szyprowski
>> Reviewed-by: Gustavo Padovan
>> ---
>> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 13 -
>> drivers/gpu/drm/exynos/exynos7_drm_decon.c| 16 +---
>> drivers/gpu/drm/exynos/exynos_drm_drv.h | 3 ---
>> drivers/gpu/drm/exynos/exynos_drm_fb.c| 16 ++--
>> drivers/gpu/drm/exynos/exynos_drm_fb.h| 3 +--
>> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 10 ++
>> drivers/gpu/drm/exynos/exynos_drm_plane.c | 18 --
>> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 5 -
>> drivers/gpu/drm/exynos/exynos_mixer.c | 7 ---
>> 9 files changed, 38 insertions(+), 53 deletions(-)
>>
>
> <--snip-->
>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>> b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>> index 669362c53f49..3ce141236fad 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>> @@ -24,6 +24,7 @@
>>
>> #include "exynos_drm_drv.h"
>> #include "exynos_drm_crtc.h"
>> +#include "exynos_drm_fb.h"
>> #include "exynos_drm_plane.h"
>> #include "exynos_drm_vidi.h"
>>
>> @@ -126,11 +127,13 @@ static void vidi_update_plane(struct exynos_drm_crtc
>> *crtc,
>>struct exynos_drm_plane *plane)
>> {
>> struct vidi_context *ctx = crtc->ctx;
>> +dma_addr_t addr;
>>
>> if (ctx->suspended)
>> return;
>>
>> -DRM_DEBUG_KMS("dma_addr = %pad\n", plane->dma_addr);
>> +addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);
>
> At this point, plane->base.fb is NULL so null pointer access happens like
> below,
>
> [5.969422] Unable to handle kernel NULL pointer dereference at virtual
> address 0090
> [5.977481] pgd = ee59
> [5.980142] [0090] *pgd=6e526831, *pte=, *ppte=
> [5.986347] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
> [5.991712] Modules linked in:
> [5.994770] CPU: 3 PID: 1598 Comm: sh Not tainted
> 4.4.0-rc3-00052-gc60d7e2-dirty #199
> [6.002565] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [6.008647] task: ef328000 ti: ee4d4000 task.ti: ee4d4000
> [6.014053] PC is at exynos_drm_fb_dma_addr+0x8/0x14
> [6.018990] LR is at vidi_update_plane+0x4c/0xc4
> [6.023581] pc : []lr : []psr: 8013
> [6.023581] sp : ee4d5d90 ip : 0001 fp :
> [6.035029] r10: r9 : c05b965c r8 : ee813e00
> [6.040241] r7 : r6 : ee8e3330 r5 : r4 : ee8e3010
> [6.046749] r3 : r2 : r1 : 0024 r0 :
> [6.053264] Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment
> none
> [6.060379] Control: 10c5387d Table: 6e59004a DAC: 0051
> [6.066107] Process sh (pid: 1598, stack limit = 0xee4d4210)
> [6.071748] Stack: (0xee4d5d90 to 0xee4d6000)
> [6.076100] 5d80: ee813300
> ee476e40 0005
> [6.084236] 5da0: ee8e3330 c028ac14 0008 ee476e40 ee476fc0 ef3b3800
> ee476fc0 eeb3e380
> [6.092395] 5dc0: 0002 c02b08e4 eeb3e3a4 ee476fc0 ee476e40
> ef3b3800 eeb3e380
> [6.100554] 5de0: 0002 c02b12b8 ee854400 0001 ee8501a8
> ee476e40
> [6.108714] 5e00: ef3b3800 0001 ee476e40 0050 ee850c80 0001
> ee476e40 ef3b3aac
> [6.116873] 5e20: 0002 00ff c028e0ec 000a82b4 c02acc50
> ee8e36a0 ee47
[PATCH v2 14/22] drm/exynos: fimd: fix dma burst size setting for small plane size
2015ë
12ì 10ì¼ 21:59ì Marek Szyprowski ì´(ê°) ì´ ê¸:
> Hello,
>
> On 2015-12-10 12:35, Inki Dae wrote:
>> Hi Marek,
>>
>> 2015ë
11ì 30ì¼ 22:53ì Marek Szyprowski ì´(ê°) ì´ ê¸:
>>> This patch fixes trashed display of buffers cropped to very small width.
>>> Even if DMA is unstable and causes tearing when changing the burst size,
>>> it is still better than displaying a garbage.
>> It seems that this patch is different from above description. I think below
>> patch is just cleanup,
>> which passes each member necessary instead of passing a drm_framebuffer
>> object.
>
> Please note the last chunk of this patch. After applying it width is
> taken from state->src.w instead of fb->width. If you want, I can split
> this patch into 2 parts - one cleanup without functional change, and
> second, replacement of fb->width with state->src.w.
Will just merge it.
Thanks,
Inki Dae
>
>
>>
>>> Signed-off-by: Marek Szyprowski
>>> ---
>>> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 24 +++-
>>> 1 file changed, 11 insertions(+), 13 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> index 70cd2681e343..2e2247126581 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> @@ -487,7 +487,7 @@ static void fimd_commit(struct exynos_drm_crtc *crtc)
>>> static void fimd_win_set_pixfmt(struct fimd_context *ctx, unsigned
>>> int win,
>>> -struct drm_framebuffer *fb)
>>> +uint32_t pixel_format, int width)
>>> {
>>> unsigned long val;
>>> @@ -498,11 +498,11 @@ static void fimd_win_set_pixfmt(struct fimd_context
>>> *ctx, unsigned int win,
>>>* So the request format is ARGB then change it to XRGB.
>>>*/
>>> if (ctx->driver_data->has_limited_fmt && !win) {
>>> -if (fb->pixel_format == DRM_FORMAT_ARGB)
>>> -fb->pixel_format = DRM_FORMAT_XRGB;
>>> +if (pixel_format == DRM_FORMAT_ARGB)
>>> +pixel_format = DRM_FORMAT_XRGB;
>>> }
>>> -switch (fb->pixel_format) {
>>> +switch (pixel_format) {
>>> case DRM_FORMAT_C8:
>>> val |= WINCON0_BPPMODE_8BPP_PALETTE;
>>> val |= WINCONx_BURSTLEN_8WORD;
>>> @@ -538,17 +538,15 @@ static void fimd_win_set_pixfmt(struct fimd_context
>>> *ctx, unsigned int win,
>>> break;
>>> }
>>> -DRM_DEBUG_KMS("bpp = %d\n", fb->bits_per_pixel);
>>> -
>>> /*
>>> - * In case of exynos, setting dma-burst to 16Word causes permanent
>>> - * tearing for very small buffers, e.g. cursor buffer. Burst Mode
>>> - * switching which is based on plane size is not recommended as
>>> - * plane size varies alot towards the end of the screen and rapid
>>> - * movement causes unstable DMA which results into iommu crash/tear.
>>> + * Setting dma-burst to 16Word causes permanent tearing for very small
>>> + * buffers, e.g. cursor buffer. Burst Mode switching which based on
>>> + * plane size is not recommended as plane size varies alot towards the
>>> + * end of the screen and rapid movement causes unstable DMA, but it is
>>> + * still better to change dma-burst than displaying garbage.
>>>*/
>>> -if (fb->width < MIN_FB_WIDTH_FOR_16WORD_BURST) {
>>> +if (width < MIN_FB_WIDTH_FOR_16WORD_BURST) {
>>> val &= ~WINCONx_BURSTLEN_MASK;
>>> val |= WINCONx_BURSTLEN_4WORD;
>>> }
>>> @@ -723,7 +721,7 @@ static void fimd_update_plane(struct exynos_drm_crtc
>>> *crtc,
>>> DRM_DEBUG_KMS("osd size = 0x%x\n", (unsigned int)val);
>>> }
>>> -fimd_win_set_pixfmt(ctx, win, fb);
>>> +fimd_win_set_pixfmt(ctx, win, fb->pixel_format, state->src.w);
>>> /* hardware window 0 doesn't support color key. */
>>> if (win != 0)
>>>
>
> Best regards
[PATCH v2 06/22] drm/exynos: move dma_addr attribute from exynos plane to exynos fb
Hi Inki,
On 2015-12-11 10:02, Inki Dae wrote:
> Hi Marek,
>
> I found out why NULL point access happened. That was incurred by below your
> patch,
> [PATCH] drm/exynos: move dma_addr attribute from exynos plane to exynos fb
>
> When another crtc driver is hotplugged in runtime such as HDMI or VIDI,
> the drm frambuffer object of fb_helper is set to the plane state of the new
> crtc driver
> so the driver should get the drm framebuffer object from the plane's state or
> exynos_plane->pending_fb which is set by exynos_plane_atomic_update function.
>
> After that, I think the drm framebuffer should be set to drm plane as a
> current fb
> which would be scanned out.
>
> Anyway, I can fix it like below if you are ok.
>
> Thanks,
> Inki Dae
>
> --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> @@ -137,7 +137,7 @@ static void vidi_update_plane(struct exynos_drm_crtc
> *crtc,
> if (ctx->suspended)
> return;
>
> - addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);
> + addr = exynos_drm_fb_dma_addr(plane->pending_fb, 0);
> DRM_DEBUG_KMS("dma_addr = %pad\n", &addr);
>
> + plane->base.fb = plane->pending_fb;
plane->base.fb should not be modified. I think that the following fix is
more
appropriate:
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -132,12 +132,13 @@ static void vidi_update_plane(struct
exynos_drm_crtc *crtc,
struct exynos_drm_plane *plane)
{
struct vidi_context *ctx = crtc->ctx;
- dma_addr_t addr;
+ dma_addr_t addr = 0;
if (ctx->suspended)
return;
- addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);
+ if (plane->base.fb)
+ addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);
DRM_DEBUG_KMS("dma_addr = %pad\n", &addr);
if (ctx->vblank_on)
I will investigate the case of NULL plane->state.fb, because it might be
relevant
to other crtc drivers as well.
>
> if (ctx->vblank_on)
>
>
> 2015ë
12ì 10ì¼ 22:05ì Inki Dae ì´(ê°) ì´ ê¸:
>>
>> 2015ë
11ì 30ì¼ 22:53ì Marek Szyprowski ì´(ê°) ì´ ê¸:
>>> DMA address is a framebuffer attribute and the right place for it is
>>> exynos_drm_framebuffer not exynos_drm_plane. This patch also introduces
>>> helper function for getting dma address of the given framebuffer.
>>>
>>> Signed-off-by: Marek Szyprowski
>>> Reviewed-by: Gustavo Padovan
>>> ---
>>> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 13 -
>>> drivers/gpu/drm/exynos/exynos7_drm_decon.c| 16 +---
>>> drivers/gpu/drm/exynos/exynos_drm_drv.h | 3 ---
>>> drivers/gpu/drm/exynos/exynos_drm_fb.c| 16 ++--
>>> drivers/gpu/drm/exynos/exynos_drm_fb.h| 3 +--
>>> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 10 ++
>>> drivers/gpu/drm/exynos/exynos_drm_plane.c | 18 --
>>> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 5 -
>>> drivers/gpu/drm/exynos/exynos_mixer.c | 7 ---
>>> 9 files changed, 38 insertions(+), 53 deletions(-)
>>>
>> <--snip-->
>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>>> index 669362c53f49..3ce141236fad 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>>> @@ -24,6 +24,7 @@
>>>
>>> #include "exynos_drm_drv.h"
>>> #include "exynos_drm_crtc.h"
>>> +#include "exynos_drm_fb.h"
>>> #include "exynos_drm_plane.h"
>>> #include "exynos_drm_vidi.h"
>>>
>>> @@ -126,11 +127,13 @@ static void vidi_update_plane(struct exynos_drm_crtc
>>> *crtc,
>>> struct exynos_drm_plane *plane)
>>> {
>>> struct vidi_context *ctx = crtc->ctx;
>>> + dma_addr_t addr;
>>>
>>> if (ctx->suspended)
>>> return;
>>>
>>> - DRM_DEBUG_KMS("dma_addr = %pad\n", plane->dma_addr);
>>> + addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);
>> At this point, plane->base.fb is NULL so null pointer access happens like
>> below,
>>
>> [5.969422] Unable to handle kernel NULL pointer dereference at virtual
>> address 0090
>> [5.977481] pgd = ee59
>> [5.980142] [0090] *pgd=6e526831, *pte=, *ppte=
>> [5.986347] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
>> [5.991712] Modules linked in:
>> [5.994770] CPU: 3 PID: 1598 Comm: sh Not tainted
>> 4.4.0-rc3-00052-gc60d7e2-dirty #199
>> [6.002565] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>> [6.008647] task: ef328000 ti: ee4d4000 task.ti: ee4d4000
>> [6.014053] PC is at exynos_drm_fb_dma_addr+0x8/0x14
>> [6.018990] LR is at vidi_update_plane+0x4c/0xc4
>> [6.023581] pc : []lr : []psr: 8013
>> [6.023581] sp : ee4d5d90 ip : 0001 fp :
>> [6.035029] r10: r9
[PULL] drm-intel-fixes
Hi Dave - Here are some i915 fixes for v4.4, sorry for being late this week. BR, Jani. The following changes since commit 527e9316f8ec44bd53d90fb9f611fa752bb9: Linux 4.4-rc4 (2015-12-06 15:43:12 -0800) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2015-12-11 for you to fetch changes up to 634b3a4a476e96816d5d6cd5bb9f8900a53f56ba: drm/i915: Do a better job at disabling primary plane in the noatomic case. (2015-12-10 13:33:42 +0200) Maarten Lankhorst (1): drm/i915: Do a better job at disabling primary plane in the noatomic case. Mika Kuoppala (2): drm/i915/skl: Disable coarse power gating up until F0 drm/i915/skl: Double RC6 WRL always on Tvrtko Ursulin (1): drm/i915: Remove incorrect warning in context cleanup drivers/gpu/drm/i915/i915_gem_context.c | 2 -- drivers/gpu/drm/i915/intel_display.c| 4 +++- drivers/gpu/drm/i915/intel_pm.c | 5 ++--- 3 files changed, 5 insertions(+), 6 deletions(-) -- Jani Nikula, Intel Open Source Technology Center
[PATCH v2 06/22] drm/exynos: move dma_addr attribute from exynos plane to exynos fb
Hi Marek,
2015ë
12ì 11ì¼ 18:26ì Marek Szyprowski ì´(ê°) ì´ ê¸:
> Hi Inki,
>
> On 2015-12-11 10:02, Inki Dae wrote:
>> Hi Marek,
>>
>> I found out why NULL point access happened. That was incurred by below your
>> patch,
>> [PATCH] drm/exynos: move dma_addr attribute from exynos plane to exynos fb
>>
>> When another crtc driver is hotplugged in runtime such as HDMI or VIDI,
>> the drm frambuffer object of fb_helper is set to the plane state of the new
>> crtc driver
>> so the driver should get the drm framebuffer object from the plane's state or
>> exynos_plane->pending_fb which is set by exynos_plane_atomic_update function.
>>
>> After that, I think the drm framebuffer should be set to drm plane as a
>> current fb
>> which would be scanned out.
>>
>> Anyway, I can fix it like below if you are ok.
>>
>> Thanks,
>> Inki Dae
>>
>> --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>> @@ -137,7 +137,7 @@ static void vidi_update_plane(struct exynos_drm_crtc
>> *crtc,
>> if (ctx->suspended)
>> return;
>> - addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);
>> + addr = exynos_drm_fb_dma_addr(plane->pending_fb, 0);
>> DRM_DEBUG_KMS("dma_addr = %pad\n", &addr);
>>
>> +plane->base.fb = plane->pending_fb;
>
> plane->base.fb should not be modified. I think that the following fix is more
Could you explain why plane->base.fb shouldn't be modified?
In case that userspace requests setplane, plane->base.fb would be updated after
update_plane callback.
However, in other cases, I don't see how plane->base.fb could be updated.
In this case, I think vendor specific drivers would need to update it as a
current fb to be scanned out like other some drivers did.
Of course, it may be possible for drm core part to take care of it
appropriately later.
Thanks,
Inki Dae
> appropriate:
> --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> @@ -132,12 +132,13 @@ static void vidi_update_plane(struct exynos_drm_crtc
> *crtc,
> struct exynos_drm_plane *plane)
> {
> struct vidi_context *ctx = crtc->ctx;
> - dma_addr_t addr;
> + dma_addr_t addr = 0;
>
> if (ctx->suspended)
> return;
>
> - addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);
> + if (plane->base.fb)
> + addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);
> DRM_DEBUG_KMS("dma_addr = %pad\n", &addr);
>
> if (ctx->vblank_on)
>
> I will investigate the case of NULL plane->state.fb, because it might be
> relevant
> to other crtc drivers as well.
>
>
>>if (ctx->vblank_on)
>>
>>
>> 2015ë
12ì 10ì¼ 22:05ì Inki Dae ì´(ê°) ì´ ê¸:
>>>
>>> 2015ë
11ì 30ì¼ 22:53ì Marek Szyprowski ì´(ê°) ì´ ê¸:
DMA address is a framebuffer attribute and the right place for it is
exynos_drm_framebuffer not exynos_drm_plane. This patch also introduces
helper function for getting dma address of the given framebuffer.
Signed-off-by: Marek Szyprowski
Reviewed-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 13 -
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 16 +---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 3 ---
drivers/gpu/drm/exynos/exynos_drm_fb.c| 16 ++--
drivers/gpu/drm/exynos/exynos_drm_fb.h| 3 +--
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 10 ++
drivers/gpu/drm/exynos/exynos_drm_plane.c | 18 --
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 5 -
drivers/gpu/drm/exynos/exynos_mixer.c | 7 ---
9 files changed, 38 insertions(+), 53 deletions(-)
>>> <--snip-->
>>>
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 669362c53f49..3ce141236fad 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -24,6 +24,7 @@
#include "exynos_drm_drv.h"
#include "exynos_drm_crtc.h"
+#include "exynos_drm_fb.h"
#include "exynos_drm_plane.h"
#include "exynos_drm_vidi.h"
@@ -126,11 +127,13 @@ static void vidi_update_plane(struct
exynos_drm_crtc *crtc,
struct exynos_drm_plane *plane)
{
struct vidi_context *ctx = crtc->ctx;
+dma_addr_t addr;
if (ctx->suspended)
return;
-DRM_DEBUG_KMS("dma_addr = %pad\n", plane->dma_addr);
+addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);
>>> At this point, plane->base.fb is NULL so null pointer access happens like
>>> below,
>>>
>>> [5.969422] Unable to handle kernel NULL pointer dereference at virtual
>>> address 0090
>>> [5.977481] pgd = ee59
>>> [
-next trees and my time this cycle
On Fri, Dec 11, 2015 at 04:58:08PM +1000, Dave Airlie wrote: > I've seen etnaviv, rockchip(?), vc4 gpu api, can I get plans for if > people would like these in now, also anything I've missed on the list. I would definitely like to see etnaviv make it in for the next merge window, but that depends on it being reviewed, and I haven't seen anything from DRM people yet. I've queued up some of the TDA998x and Armada DRM changes (3 and 5 patches respectively) which I'll send you shortly if they haven't already been merged via some other route. -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[PATCH v2 1/2] drm: make drm_dev_set_unique() not use a format string
drm_dev_set_unique() uses a format string to define the unique name of a
device. This feature is not used as currently all the calls to this
function either use "%s" as a format string or directly use
dev_name().
Even though this second kind of call does not introduce security
problems, because there cannot be "%" characters in dev_name() results,
gcc issues a warning when building with -Wformat-security flag
("warning: format string is not a string literal (potentially
insecure)"). This warning is useful to find real bugs like the one
fixed by commit 3958b79266b1 ("configfs: fix kernel infoleak through
user-controlled format string"). False positives which do not bring
an extra value make the work of finding real bugs harder.
Therefore remove the format-string feature from drm_dev_set_unique().
Signed-off-by: Nicolas Iooss
---
v2: update drm_dev_set_unique() comment
drivers/gpu/drm/drm_drv.c | 17 ++---
drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +-
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +-
include/drm/drmP.h | 2 +-
4 files changed, 9 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 7dd6728dd092..eaa4316f3c45 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -797,23 +797,18 @@ EXPORT_SYMBOL(drm_dev_unregister);
/**
* drm_dev_set_unique - Set the unique name of a DRM device
* @dev: device of which to set the unique name
- * @fmt: format string for unique name
+ * @name: unique name
*
- * Sets the unique name of a DRM device using the specified format string and
- * a variable list of arguments. Drivers can use this at driver probe time if
- * the unique name of the devices they drive is static.
+ * Sets the unique name of a DRM device using the specified string. Drivers
+ * can use this at driver probe time if the unique name of the devices they
+ * drive is static.
*
* Return: 0 on success or a negative error code on failure.
*/
-int drm_dev_set_unique(struct drm_device *dev, const char *fmt, ...)
+int drm_dev_set_unique(struct drm_device *dev, const char *name)
{
- va_list ap;
-
kfree(dev->unique);
-
- va_start(ap, fmt);
- dev->unique = kvasprintf(GFP_KERNEL, fmt, ap);
- va_end(ap);
+ dev->unique = kstrdup(name, GFP_KERNEL);
return dev->unique ? 0 : -ENOMEM;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 1d3ee5179ab8..2d23f95f17ce 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -1046,7 +1046,7 @@ nouveau_platform_device_create(const struct
nvkm_device_tegra_func *func,
goto err_free;
}
- err = drm_dev_set_unique(drm, "%s", dev_name(&pdev->dev));
+ err = drm_dev_set_unique(drm, dev_name(&pdev->dev));
if (err < 0)
goto err_free;
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index f22e1e1ee64a..215d6c44af55 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -450,7 +450,7 @@ static int rockchip_drm_bind(struct device *dev)
if (!drm)
return -ENOMEM;
- ret = drm_dev_set_unique(drm, "%s", dev_name(dev));
+ ret = drm_dev_set_unique(drm, dev_name(dev));
if (ret)
goto err_free;
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 0a271ca1f7c7..f14c25a6bbf2 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1059,7 +1059,7 @@ void drm_dev_ref(struct drm_device *dev);
void drm_dev_unref(struct drm_device *dev);
int drm_dev_register(struct drm_device *dev, unsigned long flags);
void drm_dev_unregister(struct drm_device *dev);
-int drm_dev_set_unique(struct drm_device *dev, const char *fmt, ...);
+int drm_dev_set_unique(struct drm_device *dev, const char *name);
struct drm_minor *drm_minor_acquire(unsigned int minor_id);
void drm_minor_release(struct drm_minor *minor);
--
2.6.3
[PATCH v2 2/2] drm: use dev_name as default unique name in drm_dev_alloc()
The following code pattern exists in some DRM drivers:
ddev = drm_dev_alloc(&driver, parent_dev);
drm_dev_set_unique(ddev, dev_name(parent_dev));
(Sometimes dev_name(ddev->dev) is used, which is the same.)
As suggested in
http://lists.freedesktop.org/archives/dri-devel/2015-December/096441.html,
the unique name of a new DRM device can be set as dev_name(parent_dev)
when parent_dev is not NULL (vgem is a special case).
Signed-off-by: Nicolas Iooss
Acked-by: Boris Brezillon
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 4
drivers/gpu/drm/drm_drv.c| 9 +
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c| 1 -
drivers/gpu/drm/nouveau/nouveau_drm.c| 4
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 4
drivers/gpu/drm/tegra/drm.c | 1 -
drivers/gpu/drm/vc4/vc4_drv.c| 2 --
7 files changed, 9 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 244df0a440b7..fba4f72e7ae1 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -733,10 +733,6 @@ static int atmel_hlcdc_dc_drm_probe(struct platform_device
*pdev)
if (!ddev)
return -ENOMEM;
- ret = drm_dev_set_unique(ddev, dev_name(ddev->dev));
- if (ret)
- goto err_unref;
-
ret = atmel_hlcdc_dc_load(ddev);
if (ret)
goto err_unref;
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index eaa4316f3c45..bf934cdea21c 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -633,8 +633,17 @@ struct drm_device *drm_dev_alloc(struct drm_driver *driver,
}
}
+ if (parent) {
+ ret = drm_dev_set_unique(dev, dev_name(parent));
+ if (ret)
+ goto err_setunique;
+ }
+
return dev;
+err_setunique:
+ if (drm_core_check_feature(dev, DRIVER_GEM))
+ drm_gem_destroy(dev);
err_ctxbitmap:
drm_legacy_ctxbitmap_cleanup(dev);
drm_ht_remove(&dev->map_hash);
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
index 1930234ba5f1..fca97d3fc846 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
@@ -363,7 +363,6 @@ static int fsl_dcu_drm_probe(struct platform_device *pdev)
fsl_dev->np = dev->of_node;
drm->dev_private = fsl_dev;
dev_set_drvdata(dev, fsl_dev);
- drm_dev_set_unique(drm, dev_name(dev));
ret = drm_dev_register(drm, 0);
if (ret < 0)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 2d23f95f17ce..b3a563c44bcd 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -1046,10 +1046,6 @@ nouveau_platform_device_create(const struct
nvkm_device_tegra_func *func,
goto err_free;
}
- err = drm_dev_set_unique(drm, dev_name(&pdev->dev));
- if (err < 0)
- goto err_free;
-
drm->platformdev = pdev;
platform_set_drvdata(pdev, drm);
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 215d6c44af55..afbb7407c44f 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -450,10 +450,6 @@ static int rockchip_drm_bind(struct device *dev)
if (!drm)
return -ENOMEM;
- ret = drm_dev_set_unique(drm, dev_name(dev));
- if (ret)
- goto err_free;
-
ret = drm_dev_register(drm, 0);
if (ret)
goto err_free;
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 159ef515cab1..12e2d3ccbc9d 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -991,7 +991,6 @@ static int host1x_drm_probe(struct host1x_device *dev)
if (!drm)
return -ENOMEM;
- drm_dev_set_unique(drm, dev_name(&dev->dev));
dev_set_drvdata(&dev->dev, drm);
err = drm_dev_register(drm, 0);
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index d5db9e0f3b73..647772305e8f 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -168,8 +168,6 @@ static int vc4_drm_bind(struct device *dev)
vc4->dev = drm;
drm->dev_private = vc4;
- drm_dev_set_unique(drm, dev_name(dev));
-
drm_mode_config_init(drm);
if (ret)
goto unref;
--
2.6.3
[PATCH v2 06/22] drm/exynos: move dma_addr attribute from exynos plane to exynos fb
Hi Inki,
On 2015-12-11 10:57, Inki Dae wrote:
> Hi Marek,
>
> 2015ë
12ì 11ì¼ 18:26ì Marek Szyprowski ì´(ê°) ì´ ê¸:
>> Hi Inki,
>>
>> On 2015-12-11 10:02, Inki Dae wrote:
>>> Hi Marek,
>>>
>>> I found out why NULL point access happened. That was incurred by below your
>>> patch,
>>> [PATCH] drm/exynos: move dma_addr attribute from exynos plane to exynos fb
>>>
>>> When another crtc driver is hotplugged in runtime such as HDMI or VIDI,
>>> the drm frambuffer object of fb_helper is set to the plane state of the new
>>> crtc driver
>>> so the driver should get the drm framebuffer object from the plane's state
>>> or
>>> exynos_plane->pending_fb which is set by exynos_plane_atomic_update
>>> function.
>>>
>>> After that, I think the drm framebuffer should be set to drm plane as a
>>> current fb
>>> which would be scanned out.
>>>
>>> Anyway, I can fix it like below if you are ok.
>>>
>>> Thanks,
>>> Inki Dae
>>>
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>>> @@ -137,7 +137,7 @@ static void vidi_update_plane(struct exynos_drm_crtc
>>> *crtc,
>>> if (ctx->suspended)
>>> return;
>>>- addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);
>>> + addr = exynos_drm_fb_dma_addr(plane->pending_fb, 0);
>>> DRM_DEBUG_KMS("dma_addr = %pad\n", &addr);
>>>
>>> +plane->base.fb = plane->pending_fb;
>> plane->base.fb should not be modified. I think that the following fix is more
> Could you explain why plane->base.fb shouldn't be modified?
All 'base' classes are modified by DRM core and there should be no need
to modify them from the drivers.
I've checked this issue and the proper fix for is the following code:
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -131,13 +131,14 @@ static void vidi_disable_vblank(struct
exynos_drm_crtc *crtc)
static void vidi_update_plane(struct exynos_drm_crtc *crtc,
struct exynos_drm_plane *plane)
{
+ struct drm_plane_state *state = plane->base.state;
struct vidi_context *ctx = crtc->ctx;
dma_addr_t addr;
if (ctx->suspended)
return;
- addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);
+ addr = exynos_drm_fb_dma_addr(state->fb, 0);
DRM_DEBUG_KMS("dma_addr = %pad\n", &addr);
if (ctx->vblank_on)
plane->base.fb is updated from the core once all crtc/plane atomic update
calls finishes. The drivers should use the fb stored in plane->base.state.
I've missed that VIDI driver doesn't get the fb and incorrectly used
plane->base.fb instad of state->fb while updating the code.
> In case that userspace requests setplane, plane->base.fb would be updated
> after update_plane callback.
> However, in other cases, I don't see how plane->base.fb could be updated.
> In this case, I think vendor specific drivers would need to update it as a
> current fb to be scanned out like other some drivers did.
> Of course, it may be possible for drm core part to take care of it
> appropriately later.
>
> Thanks,
> Inki Dae
>
>> appropriate:
>> --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>> @@ -132,12 +132,13 @@ static void vidi_update_plane(struct exynos_drm_crtc
>> *crtc,
>>struct exynos_drm_plane *plane)
>> {
>> struct vidi_context *ctx = crtc->ctx;
>> - dma_addr_t addr;
>> + dma_addr_t addr = 0;
>>
>> if (ctx->suspended)
>> return;
>>
>> - addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);
>> + if (plane->base.fb)
>> + addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);
>> DRM_DEBUG_KMS("dma_addr = %pad\n", &addr);
>>
>> if (ctx->vblank_on)
>>
>> I will investigate the case of NULL plane->state.fb, because it might be
>> relevant
>> to other crtc drivers as well.
>>
>>
>>> if (ctx->vblank_on)
>>>
>>>
>>> 2015ë
12ì 10ì¼ 22:05ì Inki Dae ì´(ê°) ì´ ê¸:
2015ë
11ì 30ì¼ 22:53ì Marek Szyprowski ì´(ê°) ì´ ê¸:
> DMA address is a framebuffer attribute and the right place for it is
> exynos_drm_framebuffer not exynos_drm_plane. This patch also introduces
> helper function for getting dma address of the given framebuffer.
>
> Signed-off-by: Marek Szyprowski
> Reviewed-by: Gustavo Padovan
> ---
>drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 13 -
>drivers/gpu/drm/exynos/exynos7_drm_decon.c| 16 +---
>drivers/gpu/drm/exynos/exynos_drm_drv.h | 3 ---
>drivers/gpu/drm/exynos/exynos_drm_fb.c| 16 ++--
>drivers/gpu/drm/exynos/exynos_drm_fb.h| 3 +--
>drivers/gpu/drm/exynos/exynos_drm_fimd.c | 10 ++
>drivers/gpu/drm/exynos/exynos_drm_plane.c | 18 --
>
[PATCH RFC 0/9] omapdrm/omapfb/omapdss split
On 12/11/2015 01:27 PM, Tomi Valkeinen wrote: > > On 11/12/15 08:14, Archit Taneja wrote: > >> Is it possible to make omapfb get some of the old files (apply.c, >> overlay.c, manager.c, sysfs files etc)? It might be helpful to have git >> associate these files with omapfb/omap_vout since they have been the >> only users of it. After cleanups, these files would eventually be >> removed in the omapdrm copy, and it would be hard to track their history >> using the omapfb copy. > > Good point. Unfortunately I don't know how I could do that... > > I need to keep all the files for a copy of omapdss intact, otherwise > that copy won't work. So I need all the files for omapfb's copy, but I > can't remove (i.e. move) any from the remaining copy... > > However, in the commit where I create the omapfb copy, I can add the > original path in the commit description. That should be good enough I guess. Archit -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
[PATCH] drm: modes: Revert cc344980c767 "replace simple_strtoul by kstrtouint"
My latest commit introduce some case where a valid mode, could be
rejected.
simple_strtox functions stop at first non-digit character, but kstrtox
not.
So args like "video=HDMI-A-1:720x480-16 at 60" will be reject when checking
16 at .
Discussions about this change comes to the conclusion that the best
solution is to revert my commit cc344980c76748e57c9c03100c2a14d36ab00334.
Signed-off-by: LABBE Corentin
---
drivers/gpu/drm/drm_modes.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index db36af7..3da1434 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1230,7 +1230,7 @@ bool drm_mode_parse_command_line_for_connector(const char
*mode_option,
unsigned int xres = 0, yres = 0, bpp = 32, refresh = 0;
bool yres_specified = false, cvt = false, rb = false;
bool interlace = false, margins = false, was_digit = false;
- int i, err;
+ int i;
enum drm_connector_force force = DRM_FORCE_UNSPECIFIED;
#ifdef CONFIG_FB
@@ -1250,9 +1250,7 @@ bool drm_mode_parse_command_line_for_connector(const char
*mode_option,
case '@':
if (!refresh_specified && !bpp_specified &&
!yres_specified && !cvt && !rb && was_digit) {
- err = kstrtouint(&name[i + 1], 10, &refresh);
- if (err)
- return false;
+ refresh = simple_strtol(&name[i+1], NULL, 10);
refresh_specified = true;
was_digit = false;
} else
@@ -1261,9 +1259,7 @@ bool drm_mode_parse_command_line_for_connector(const char
*mode_option,
case '-':
if (!bpp_specified && !yres_specified && !cvt &&
!rb && was_digit) {
- err = kstrtouint(&name[i + 1], 10, &bpp);
- if (err)
- return false;
+ bpp = simple_strtol(&name[i+1], NULL, 10);
bpp_specified = true;
was_digit = false;
} else
@@ -1271,9 +1267,7 @@ bool drm_mode_parse_command_line_for_connector(const char
*mode_option,
break;
case 'x':
if (!yres_specified && was_digit) {
- err = kstrtouint(&name[i + 1], 10, &yres);
- if (err)
- return false;
+ yres = simple_strtol(&name[i+1], NULL, 10);
yres_specified = true;
was_digit = false;
} else
@@ -1496,4 +1490,4 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
out:
return ret;
-}
+}
\ No newline at end of file
--
2.4.10
[Bug 93217] [tonga] [powerplay] Radon M395X isn't initialised with the powerplay branch
https://bugs.freedesktop.org/show_bug.cgi?id=93217 --- Comment #8 from Mike Lothian --- Created attachment 120464 --> https://bugs.freedesktop.org/attachment.cgi?id=120464&action=edit Ooops on shutdown This is what's produced on shutdown on Linus's tree (0bd0f1e6d40aa16c4d507b1fff27163a7e7711f5) I'm not sure if it's related -- 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/20151211/232af207/attachment.html>
[Bug 93144] [radeonsi] Alien: Isolation bug
https://bugs.freedesktop.org/show_bug.cgi?id=93144 --- Comment #8 from Daniel Scharrer --- FYI, the game requires OpenGL 4.3 [1] (the porters have mentioned compute shaders specifically [2]), so it *can't* work with radeonsi yet. [1] See the Linux system requirements on http://store.steampowered.com/app/214490/ [2] https://www.reddit.com/r/linux_gaming/comments/3t5p0r/a/cx3hn8i -- 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/20151211/b3f7ec3c/attachment.html>
[PATCH] ttm/drm: constify ttm_backend_func structures
The ttm_backend_func structures are never modified, so declare them as
const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |2 +-
drivers/gpu/drm/ast/ast_ttm.c |2 +-
drivers/gpu/drm/bochs/bochs_mm.c|2 +-
drivers/gpu/drm/cirrus/cirrus_ttm.c |2 +-
drivers/gpu/drm/mgag200/mgag200_ttm.c |2 +-
drivers/gpu/drm/nouveau/nouveau_sgdma.c |4 ++--
drivers/gpu/drm/qxl/qxl_ttm.c |2 +-
drivers/gpu/drm/radeon/radeon_ttm.c |2 +-
drivers/gpu/drm/ttm/ttm_agp_backend.c |2 +-
drivers/gpu/drm/virtio/virtgpu_ttm.c|2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c |2 +-
include/drm/ttm/ttm_bo_driver.h |2 +-
12 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ttm.c
b/drivers/gpu/drm/virtio/virtgpu_ttm.c
index 9fd924c..a323422 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ttm.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ttm.c
@@ -319,7 +319,7 @@ static void virtio_gpu_ttm_backend_destroy(struct ttm_tt
*ttm)
kfree(gtt);
}
-static struct ttm_backend_func virtio_gpu_backend_func = {
+static const struct ttm_backend_func virtio_gpu_backend_func = {
.bind = &virtio_gpu_ttm_backend_bind,
.unbind = &virtio_gpu_ttm_backend_unbind,
.destroy = &virtio_gpu_ttm_backend_destroy,
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index e343074..9fa758c 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -666,7 +666,7 @@ static void radeon_ttm_backend_destroy(struct ttm_tt *ttm)
kfree(gtt);
}
-static struct ttm_backend_func radeon_backend_func = {
+static const struct ttm_backend_func radeon_backend_func = {
.bind = &radeon_ttm_backend_bind,
.unbind = &radeon_ttm_backend_unbind,
.destroy = &radeon_ttm_backend_destroy,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index d4bac5f..befa9c2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -634,7 +634,7 @@ static void amdgpu_ttm_backend_destroy(struct ttm_tt *ttm)
kfree(gtt);
}
-static struct ttm_backend_func amdgpu_backend_func = {
+static const struct ttm_backend_func amdgpu_backend_func = {
.bind = &amdgpu_ttm_backend_bind,
.unbind = &amdgpu_ttm_backend_unbind,
.destroy = &amdgpu_ttm_backend_destroy,
diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_ttm.c
index 08f82ea..5840785 100644
--- a/drivers/gpu/drm/ast/ast_ttm.c
+++ b/drivers/gpu/drm/ast/ast_ttm.c
@@ -203,7 +203,7 @@ static void ast_ttm_backend_destroy(struct ttm_tt *tt)
kfree(tt);
}
-static struct ttm_backend_func ast_tt_backend_func = {
+static const struct ttm_backend_func ast_tt_backend_func = {
.destroy = &ast_ttm_backend_destroy,
};
diff --git a/drivers/gpu/drm/bochs/bochs_mm.c b/drivers/gpu/drm/bochs/bochs_mm.c
index d812ad0..b5b782d 100644
--- a/drivers/gpu/drm/bochs/bochs_mm.c
+++ b/drivers/gpu/drm/bochs/bochs_mm.c
@@ -180,7 +180,7 @@ static void bochs_ttm_backend_destroy(struct ttm_tt *tt)
kfree(tt);
}
-static struct ttm_backend_func bochs_tt_backend_func = {
+static const struct ttm_backend_func bochs_tt_backend_func = {
.destroy = &bochs_ttm_backend_destroy,
};
diff --git a/drivers/gpu/drm/cirrus/cirrus_ttm.c
b/drivers/gpu/drm/cirrus/cirrus_ttm.c
index dfffd52..da88541 100644
--- a/drivers/gpu/drm/cirrus/cirrus_ttm.c
+++ b/drivers/gpu/drm/cirrus/cirrus_ttm.c
@@ -203,7 +203,7 @@ static void cirrus_ttm_backend_destroy(struct ttm_tt *tt)
kfree(tt);
}
-static struct ttm_backend_func cirrus_tt_backend_func = {
+static const struct ttm_backend_func cirrus_tt_backend_func = {
.destroy = &cirrus_ttm_backend_destroy,
};
diff --git a/drivers/gpu/drm/mgag200/mgag200_ttm.c
b/drivers/gpu/drm/mgag200/mgag200_ttm.c
index 05108b5..e368562 100644
--- a/drivers/gpu/drm/mgag200/mgag200_ttm.c
+++ b/drivers/gpu/drm/mgag200/mgag200_ttm.c
@@ -203,7 +203,7 @@ static void mgag200_ttm_backend_destroy(struct ttm_tt *tt)
kfree(tt);
}
-static struct ttm_backend_func mgag200_tt_backend_func = {
+static const struct ttm_backend_func mgag200_tt_backend_func = {
.destroy = &mgag200_ttm_backend_destroy,
};
diff --git a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
index 8c3053a..3b8f556 100644
--- a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
+++ b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
@@ -51,7 +51,7 @@ nv04_sgdma_unbind(struct ttm_tt *ttm)
return 0;
}
-static struct ttm_backend_func nv04_sgdma_backend = {
+static const struct ttm_backend_func nv04_sgdma_backend = {
.bind = nv04_sgdma_bind,
.unbind = nv04_sgdma_unbind,
.destroy= nouveau_sgdma_destroy
@@ -82,7 +8
[PATCH] ttm/drm: constify ttm_backend_func structures
On 11.12.2015 14:37, Julia Lawall wrote:
> The ttm_backend_func structures are never modified, so declare them as
> const.
>
> Done with the help of Coccinelle.
>
> Signed-off-by: Julia Lawall
Reviewed-by: Christian König
>
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |2 +-
> drivers/gpu/drm/ast/ast_ttm.c |2 +-
> drivers/gpu/drm/bochs/bochs_mm.c|2 +-
> drivers/gpu/drm/cirrus/cirrus_ttm.c |2 +-
> drivers/gpu/drm/mgag200/mgag200_ttm.c |2 +-
> drivers/gpu/drm/nouveau/nouveau_sgdma.c |4 ++--
> drivers/gpu/drm/qxl/qxl_ttm.c |2 +-
> drivers/gpu/drm/radeon/radeon_ttm.c |2 +-
> drivers/gpu/drm/ttm/ttm_agp_backend.c |2 +-
> drivers/gpu/drm/virtio/virtgpu_ttm.c|2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c |2 +-
> include/drm/ttm/ttm_bo_driver.h |2 +-
> 12 files changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_ttm.c
> b/drivers/gpu/drm/virtio/virtgpu_ttm.c
> index 9fd924c..a323422 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_ttm.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_ttm.c
> @@ -319,7 +319,7 @@ static void virtio_gpu_ttm_backend_destroy(struct ttm_tt
> *ttm)
> kfree(gtt);
> }
>
> -static struct ttm_backend_func virtio_gpu_backend_func = {
> +static const struct ttm_backend_func virtio_gpu_backend_func = {
> .bind = &virtio_gpu_ttm_backend_bind,
> .unbind = &virtio_gpu_ttm_backend_unbind,
> .destroy = &virtio_gpu_ttm_backend_destroy,
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index e343074..9fa758c 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -666,7 +666,7 @@ static void radeon_ttm_backend_destroy(struct ttm_tt *ttm)
> kfree(gtt);
> }
>
> -static struct ttm_backend_func radeon_backend_func = {
> +static const struct ttm_backend_func radeon_backend_func = {
> .bind = &radeon_ttm_backend_bind,
> .unbind = &radeon_ttm_backend_unbind,
> .destroy = &radeon_ttm_backend_destroy,
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index d4bac5f..befa9c2 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -634,7 +634,7 @@ static void amdgpu_ttm_backend_destroy(struct ttm_tt *ttm)
> kfree(gtt);
> }
>
> -static struct ttm_backend_func amdgpu_backend_func = {
> +static const struct ttm_backend_func amdgpu_backend_func = {
> .bind = &amdgpu_ttm_backend_bind,
> .unbind = &amdgpu_ttm_backend_unbind,
> .destroy = &amdgpu_ttm_backend_destroy,
> diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_ttm.c
> index 08f82ea..5840785 100644
> --- a/drivers/gpu/drm/ast/ast_ttm.c
> +++ b/drivers/gpu/drm/ast/ast_ttm.c
> @@ -203,7 +203,7 @@ static void ast_ttm_backend_destroy(struct ttm_tt *tt)
> kfree(tt);
> }
>
> -static struct ttm_backend_func ast_tt_backend_func = {
> +static const struct ttm_backend_func ast_tt_backend_func = {
> .destroy = &ast_ttm_backend_destroy,
> };
>
> diff --git a/drivers/gpu/drm/bochs/bochs_mm.c
> b/drivers/gpu/drm/bochs/bochs_mm.c
> index d812ad0..b5b782d 100644
> --- a/drivers/gpu/drm/bochs/bochs_mm.c
> +++ b/drivers/gpu/drm/bochs/bochs_mm.c
> @@ -180,7 +180,7 @@ static void bochs_ttm_backend_destroy(struct ttm_tt *tt)
> kfree(tt);
> }
>
> -static struct ttm_backend_func bochs_tt_backend_func = {
> +static const struct ttm_backend_func bochs_tt_backend_func = {
> .destroy = &bochs_ttm_backend_destroy,
> };
>
> diff --git a/drivers/gpu/drm/cirrus/cirrus_ttm.c
> b/drivers/gpu/drm/cirrus/cirrus_ttm.c
> index dfffd52..da88541 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_ttm.c
> +++ b/drivers/gpu/drm/cirrus/cirrus_ttm.c
> @@ -203,7 +203,7 @@ static void cirrus_ttm_backend_destroy(struct ttm_tt *tt)
> kfree(tt);
> }
>
> -static struct ttm_backend_func cirrus_tt_backend_func = {
> +static const struct ttm_backend_func cirrus_tt_backend_func = {
> .destroy = &cirrus_ttm_backend_destroy,
> };
>
> diff --git a/drivers/gpu/drm/mgag200/mgag200_ttm.c
> b/drivers/gpu/drm/mgag200/mgag200_ttm.c
> index 05108b5..e368562 100644
> --- a/drivers/gpu/drm/mgag200/mgag200_ttm.c
> +++ b/drivers/gpu/drm/mgag200/mgag200_ttm.c
> @@ -203,7 +203,7 @@ static void mgag200_ttm_backend_destroy(struct ttm_tt *tt)
> kfree(tt);
> }
>
> -static struct ttm_backend_func mgag200_tt_backend_func = {
> +static const struct ttm_backend_func mgag200_tt_backend_func = {
> .destroy = &mgag200_ttm_backend_destroy,
> };
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
> b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
> index 8c3053a..3b8f556 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
> @@ -51,7 +51,7 @@ nv04_sgdma_unbind(
[PATCH v2 06/22] drm/exynos: move dma_addr attribute from exynos plane to exynos fb
Hi Marek,
2015-12-11 20:27 GMT+09:00 Marek Szyprowski :
> Hi Inki,
>
>
> On 2015-12-11 10:57, Inki Dae wrote:
>>
>> Hi Marek,
>>
>> 2015ë
12ì 11ì¼ 18:26ì Marek Szyprowski ì´(ê°) ì´ ê¸:
>>>
>>> Hi Inki,
>>>
>>> On 2015-12-11 10:02, Inki Dae wrote:
Hi Marek,
I found out why NULL point access happened. That was incurred by below
your patch,
[PATCH] drm/exynos: move dma_addr attribute from exynos plane to exynos
fb
When another crtc driver is hotplugged in runtime such as HDMI or VIDI,
the drm frambuffer object of fb_helper is set to the plane state of the
new crtc driver
so the driver should get the drm framebuffer object from the plane's
state or
exynos_plane->pending_fb which is set by exynos_plane_atomic_update
function.
After that, I think the drm framebuffer should be set to drm plane as a
current fb
which would be scanned out.
Anyway, I can fix it like below if you are ok.
Thanks,
Inki Dae
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -137,7 +137,7 @@ static void vidi_update_plane(struct exynos_drm_crtc
*crtc,
if (ctx->suspended)
return;
- addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);
+ addr = exynos_drm_fb_dma_addr(plane->pending_fb, 0);
DRM_DEBUG_KMS("dma_addr = %pad\n", &addr);
+plane->base.fb = plane->pending_fb;
>>>
>>> plane->base.fb should not be modified. I think that the following fix is
>>> more
>>
>> Could you explain why plane->base.fb shouldn't be modified?
>
>
> All 'base' classes are modified by DRM core and there should be no need
> to modify them from the drivers.
Ok, If so - drm core updates plane->fb - then it's reasonable. But I
couldn't find the exact location where plane->fb is set to a fb to be
scanned out.
So could you let me know the exact location? it's not clear to me yet.
>
> I've checked this issue and the proper fix for is the following code:
>
> --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> @@ -131,13 +131,14 @@ static void vidi_disable_vblank(struct exynos_drm_crtc
> *crtc)
> static void vidi_update_plane(struct exynos_drm_crtc *crtc,
> struct exynos_drm_plane *plane)
> {
> + struct drm_plane_state *state = plane->base.state;
> struct vidi_context *ctx = crtc->ctx;
> dma_addr_t addr;
>
> if (ctx->suspended)
> return;
>
> - addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);
> + addr = exynos_drm_fb_dma_addr(state->fb, 0);
> DRM_DEBUG_KMS("dma_addr = %pad\n", &addr);
>
> if (ctx->vblank_on)
>
>
> plane->base.fb is updated from the core once all crtc/plane atomic update
> calls finishes. The drivers should use the fb stored in plane->base.state.
> I've missed that VIDI driver doesn't get the fb and incorrectly used
> plane->base.fb instad of state->fb while updating the code.
>
Actually, I used state->fb instead of plane->pending_fb but in
exynos_plane_atomic_update function, plane->pending_fb is set to
state->fb.
That is why I commented like below,
" so the driver should get the drm framebuffer object from the plane's
state or exynos_plane->pending_fb which is set by
exynos_plane_atomic_update function."
Anyway, using state->fb looks like more consistent with other drivers,
fimd, decon and mixer.
Thanks,
Inki Dae
>
>
>> In case that userspace requests setplane, plane->base.fb would be updated
>> after update_plane callback.
>> However, in other cases, I don't see how plane->base.fb could be updated.
>> In this case, I think vendor specific drivers would need to update it as a
>> current fb to be scanned out like other some drivers did.
>> Of course, it may be possible for drm core part to take care of it
>> appropriately later.
>>
>> Thanks,
>> Inki Dae
>>
>>> appropriate:
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>>> @@ -132,12 +132,13 @@ static void vidi_update_plane(struct
>>> exynos_drm_crtc *crtc,
>>>struct exynos_drm_plane *plane)
>>> {
>>> struct vidi_context *ctx = crtc->ctx;
>>> - dma_addr_t addr;
>>> + dma_addr_t addr = 0;
>>>
>>> if (ctx->suspended)
>>> return;
>>>
>>> - addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);
>>> + if (plane->base.fb)
>>> + addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);
>>> DRM_DEBUG_KMS("dma_addr = %pad\n", &addr);
>>>
>>> if (ctx->vblank_on)
>>>
>>> I will investigate the case of NULL plane->state.fb, because it might be
>>> relevant
>>> to other crtc drivers as well.
>>>
>>>
if (ctx->vblank_on)
2015ë
12ì 10ì¼ 22:05ì Inki Dae ì´(ê°) ì´ ê¸:
>
>>>
[PATCH v6 1/4] drm: arm: Add DT bindings documentation for HDLCD driver.
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Signed-off-by: Liviu Dudau
Acked-by: Rob Herring
---
.../devicetree/bindings/display/arm,hdlcd.txt | 79 ++
1 file changed, 79 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/arm,hdlcd.txt
diff --git a/Documentation/devicetree/bindings/display/arm,hdlcd.txt
b/Documentation/devicetree/bindings/display/arm,hdlcd.txt
new file mode 100644
index 000..78bc242
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/arm,hdlcd.txt
@@ -0,0 +1,79 @@
+ARM HDLCD
+
+This is a display controller found on several development platforms produced
+by ARM Ltd and in more modern of its' Fast Models. The HDLCD is an RGB
+streamer that reads the data from a framebuffer and sends it to a single
+digital encoder (DVI or HDMI).
+
+Required properties:
+ - compatible: "arm,hdlcd"
+ - reg: Physical base address and length of the controller's registers.
+ - interrupts: One interrupt used by the display controller to notify the
+interrupt controller when any of the interrupt sources programmed in
+the interrupt mask register have activated.
+ - clocks: A list of phandle + clock-specifier pairs, one for each
+entry in 'clock-names'.
+ - clock-names: A list of clock names. For HDLCD it should contain:
+ - "pxlclk" for the clock feeding the output PLL of the controller.
+
+Required sub-nodes:
+ - port: The HDLCD connection to an encoder chip. The connection is modeled
+using the OF graph bindings specified in
+Documentation/devicetree/bindings/graph.txt.
+
+Optional properties:
+ - memory-region: phandle to a node describing memory (see
+Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt) to
be
+used for the framebuffer; if not present, the framebuffer may be located
+anywhere in memory.
+
+
+Example:
+
+/ {
+ ...
+
+ hdlcd at 2b00 {
+ compatible = "arm,hdlcd";
+ reg = <0 0x2b00 0 0x1000>;
+ interrupts = ;
+ clocks = <&oscclk5>;
+ clock-names = "pxlclk";
+ port {
+ hdlcd_output: endpoint at 0 {
+ remote-endpoint = <&hdmi_enc_input>;
+ };
+ };
+ };
+
+ /* HDMI encoder on I2C bus */
+ i2c at 7ffa {
+
+ hdmi-transmitter at 70 {
+ compatible = ".";
+ reg = <0x70>;
+ port at 0 {
+ hdmi_enc_input: endpoint {
+ remote-endpoint = <&hdlcd_output>;
+ };
+
+ hdmi_enc_output: endpoint {
+ remote-endpoint = <&hdmi_1_port>;
+ };
+ };
+ };
+
+ };
+
+ hdmi1: connector at 1 {
+ compatible = "hdmi-connector";
+ type = "a";
+ port {
+ hdmi_1_port: endpoint {
+ remote-endpoint = <&hdmi_enc_output>;
+ };
+ };
+ };
+
+ ...
+};
--
2.6.4
[PATCH v6 4/4] MAINTAINERS: Add Liviu Dudau as maintainer for ARM HDLCD driver.
Update MAINTAINERS file for HDLCD driver. Cc: Greg KH Cc: Andrew Morton Cc: Mauro Carvalho Chehab Cc: David S. Miller Signed-off-by: Liviu Dudau --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index cba790b..4208dae 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -820,6 +820,12 @@ S: Maintained F: drivers/net/arcnet/ F: include/uapi/linux/if_arcnet.h +ARM HDLCD DRM DRIVER +M: Liviu Dudau +S: Supported +F: drivers/gpu/drm/arm/ +F: Documentation/devicetree/bindings/display/arm,hdlcd.txt + ARM MFM AND FLOPPY DRIVERS M: Ian Molton S: Maintained -- 2.6.4
[PATCH v6 3/4] arm64: Juno: Add HDLCD support to the Juno boards.
ARM's Juno board has two HDLCD controllers, each linked to an NXP
TDA19988 HDMI transmitter that provides output encoding. Add them
to the device tree.
Signed-off-by: Liviu Dudau
Acked-by: Sudeep Holla
---
arch/arm64/boot/dts/arm/juno-base.dtsi | 46 +++---
1 file changed, 42 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi
b/arch/arm64/boot/dts/arm/juno-base.dtsi
index dd5158e..8ee094a 100644
--- a/arch/arm64/boot/dts/arm/juno-base.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
@@ -92,8 +92,8 @@
scpi_clk: scpi_clocks at 3 {
compatible = "arm,scpi-variable-clocks";
#clock-cells = <1>;
- clock-indices = <3>, <4>;
- clock-output-names = "pxlclk0", "pxlclk1";
+ clock-indices = <3>;
+ clock-output-names = "pxlclk";
};
};
@@ -123,6 +123,34 @@
clock-names = "apb_pclk";
};
+ hdlcd at 7ff5 {
+ compatible = "arm,hdlcd";
+ reg = <0 0x7ff5 0 0x1000>;
+ interrupts = ;
+ clocks = <&scpi_clk 3>;
+ clock-names = "pxlclk";
+
+ port {
+ hdlcd1_output: endpoint at 0 {
+ remote-endpoint = <&tda998x_1_input>;
+ };
+ };
+ };
+
+ hdlcd at 7ff6 {
+ compatible = "arm,hdlcd";
+ reg = <0 0x7ff6 0 0x1000>;
+ interrupts = ;
+ clocks = <&scpi_clk 3>;
+ clock-names = "pxlclk";
+
+ port {
+ hdlcd0_output: endpoint at 0 {
+ remote-endpoint = <&tda998x_0_input>;
+ };
+ };
+ };
+
soc_uart0: uart at 7ff8 {
compatible = "arm,pl011", "arm,primecell";
reg = <0x0 0x7ff8 0x0 0x1000>;
@@ -141,14 +169,24 @@
i2c-sda-hold-time-ns = <500>;
clocks = <&soc_smc50mhz>;
- dvi0: dvi-transmitter at 70 {
+ hdmi-transmitter at 70 {
compatible = "nxp,tda998x";
reg = <0x70>;
+ port {
+ tda998x_0_input: endpoint at 0 {
+ remote-endpoint = <&hdlcd0_output>;
+ };
+ };
};
- dvi1: dvi-transmitter at 71 {
+ hdmi-transmitter at 71 {
compatible = "nxp,tda998x";
reg = <0x71>;
+ port {
+ tda998x_1_input: endpoint at 0 {
+ remote-endpoint = <&hdlcd1_output>;
+ };
+ };
};
};
--
2.6.4
[PATCH v6 0/4] drm: Add support for the ARM HDLCD display controller
This series adds support for ARM's HDLCD display controller found in Juno and ARM TC2 Coretile. The HDLCD outputs an RGB stream that feeds into a single digital encoder (DVI or HDMI). Most of the dependencies for this patch series are now queued for the next release or are already in the mainline. The one dependency that I'm not sure about its future is Thierry Reding's cleanup of the connector->encoder being set in the drivers [1]. It is not blocking the HDLCD functionality but avoids having an ugly WARNING splat at boot time. Only the Juno functionality has been tested as the TC2 Coretile require a working SiI9022 driver for VExpress that is not subject of this patchset. I think I have addressed most of the comments and I would like to add the series to some queue for v4.5. David Airlie's tree feels the most appropriate, even if only 1 patch touches drivers/gpu/drm, but I'm open to suggestions. Changelog: v6: Addressed the style nits pointed by Robin Murphy and fixed the use of default color to highlight underrun errors. Also modified MAINTAINERS file to change the status to Supported for HDLCD. v5: Queue the pending vblank events sent by userspace using a list instead of keeping the last event seen. Suggested by Daniel Stone . [2] v4: Remove some debugging code that could return an error on a critical path and updated the check for valid format in hdlcd_set_pxl_fmt() to only WARN() if an invalid format found (unlikely case). Added the ACKs received. [3] v3: Changed the driver to use the memory-region phandle for bespoke framebuffers. [4] v2: Added support for atomic modeset [5] v1: Original DRM submission [6] [1] http://lists.freedesktop.org/archives/dri-devel/2015-November/094576.html [2] http://lists.freedesktop.org/archives/dri-devel/2015-December/096432.html [3] http://lists.freedesktop.org/archives/dri-devel/2015-December/095990.html [4] http://lists.freedesktop.org/archives/dri-devel/2015-December/095877.html [5] http://lists.freedesktop.org/archives/dri-devel/2015-November/094177.html [6] http://lists.freedesktop.org/archives/dri-devel/2015-August/087685.html Best regards, Liviu Liviu Dudau (4): drm: arm: Add DT bindings documentation for HDLCD driver. drm: Add support for ARM's HDLCD controller. arm64: Juno: Add HDLCD support to the Juno boards. MAINTAINERS: Add Liviu Dudau as maintainer for ARM HDLCD driver. .../devicetree/bindings/display/arm,hdlcd.txt | 79 +++ MAINTAINERS| 6 + arch/arm64/boot/dts/arm/juno-base.dtsi | 46 +- drivers/gpu/drm/Kconfig| 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/arm/Kconfig| 29 ++ drivers/gpu/drm/arm/Makefile | 2 + drivers/gpu/drm/arm/hdlcd_crtc.c | 327 drivers/gpu/drm/arm/hdlcd_drv.c| 579 + drivers/gpu/drm/arm/hdlcd_drv.h| 42 ++ drivers/gpu/drm/arm/hdlcd_regs.h | 87 11 files changed, 1196 insertions(+), 4 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/arm,hdlcd.txt create mode 100644 drivers/gpu/drm/arm/Kconfig create mode 100644 drivers/gpu/drm/arm/Makefile create mode 100644 drivers/gpu/drm/arm/hdlcd_crtc.c create mode 100644 drivers/gpu/drm/arm/hdlcd_drv.c create mode 100644 drivers/gpu/drm/arm/hdlcd_drv.h create mode 100644 drivers/gpu/drm/arm/hdlcd_regs.h -- 2.6.4
[PATCH v6 2/4] drm: Add support for ARM's HDLCD controller.
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.
Cc: David Airlie
Cc: Robin Murphy
Signed-off-by: Liviu Dudau
Acked-by: Daniel Vetter
---
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/arm/Kconfig | 29 ++
drivers/gpu/drm/arm/Makefile | 2 +
drivers/gpu/drm/arm/hdlcd_crtc.c | 327 ++
drivers/gpu/drm/arm/hdlcd_drv.c | 579 +++
drivers/gpu/drm/arm/hdlcd_drv.h | 42 +++
drivers/gpu/drm/arm/hdlcd_regs.h | 87 ++
8 files changed, 1069 insertions(+)
create mode 100644 drivers/gpu/drm/arm/Kconfig
create mode 100644 drivers/gpu/drm/arm/Makefile
create mode 100644 drivers/gpu/drm/arm/hdlcd_crtc.c
create mode 100644 drivers/gpu/drm/arm/hdlcd_drv.c
create mode 100644 drivers/gpu/drm/arm/hdlcd_drv.h
create mode 100644 drivers/gpu/drm/arm/hdlcd_regs.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index c4bf9a1..3fd9124 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -106,6 +106,8 @@ config DRM_TDFX
Choose this option if you have a 3dfx Banshee or Voodoo3 (or later),
graphics card. If M is selected, the module will be called tdfx.
+source "drivers/gpu/drm/arm/Kconfig"
+
config DRM_R128
tristate "ATI Rage 128"
depends on DRM && PCI
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 1e9ff4c..6b42d75 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -35,6 +35,7 @@ CFLAGS_drm_trace_points.o := -I$(src)
obj-$(CONFIG_DRM) += drm.o
obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o
+obj-$(CONFIG_DRM_ARM) += arm/
obj-$(CONFIG_DRM_TTM) += ttm/
obj-$(CONFIG_DRM_TDFX) += tdfx/
obj-$(CONFIG_DRM_R128) += r128/
diff --git a/drivers/gpu/drm/arm/Kconfig b/drivers/gpu/drm/arm/Kconfig
new file mode 100644
index 000..5e8c8a8
--- /dev/null
+++ b/drivers/gpu/drm/arm/Kconfig
@@ -0,0 +1,29 @@
+config DRM_ARM
+ bool "ARM Ltd. drivers"
+ depends on DRM && OF && (ARM || ARM64)
+ select DRM_KMS_HELPER
+ help
+ Choose this option to select drivers for ARM's devices
+
+config DRM_HDLCD
+ tristate "ARM HDLCD"
+ depends on DRM_ARM
+ depends on COMMON_CLK
+ select COMMON_CLK_SCPI
+ select DMA_CMA
+ select DRM_KMS_CMA_HELPER
+ select DRM_GEM_CMA_HELPER
+ help
+ Choose this option if you have an ARM High Definition Colour LCD
+ controller.
+
+ If M is selected the module will be called hdlcd.
+
+config DRM_HDLCD_SHOW_UNDERRUN
+ bool "Show underrun conditions"
+ depends on DRM_HDLCD
+ default n
+ help
+ Enable this option to show in red colour the pixels that the
+ HDLCD device did not fetch from framebuffer due to underrun
+ conditions.
diff --git a/drivers/gpu/drm/arm/Makefile b/drivers/gpu/drm/arm/Makefile
new file mode 100644
index 000..89dcb7b
--- /dev/null
+++ b/drivers/gpu/drm/arm/Makefile
@@ -0,0 +1,2 @@
+hdlcd-y := hdlcd_drv.o hdlcd_crtc.o
+obj-$(CONFIG_DRM_HDLCD)+= hdlcd.o
diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
new file mode 100644
index 000..979b35d
--- /dev/null
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -0,0 +1,327 @@
+/*
+ * Copyright (C) 2013-2015 ARM Limited
+ * Author: Liviu Dudau
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive
+ * for more details.
+ *
+ * Implementation of a CRTC class for the HDLCD driver.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "hdlcd_drv.h"
+#include "hdlcd_regs.h"
+
+/*
+ * The HDLCD controller is a dumb RGB streamer that gets connected to
+ * a single HDMI transmitter or in the case of the ARM Models it gets
+ * emulated by the software that does the actual rendering.
+ *
+ */
+
+static const struct drm_crtc_funcs hdlcd_crtc_funcs = {
+ .destroy = drm_crtc_cleanup,
+ .set_config = drm_atomic_helper_set_config,
+ .page_flip = drm_atomic_helper_page_flip,
+ .reset = drm_atomic_helper_crtc_reset,
+ .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
+};
+
+static struct simplefb_format supported_formats[] = SIMPLEFB_FORMATS;
+
+/*
+ * Setup the HDLCD registers for decoding the pixels out of the framebuffer
+ */
+static int hdlcd_set_pxl_fmt(struct drm_crtc *crtc)
+{
+ unsigned int btpp;
+ struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
+ uint32_t pixel_format;
+ struct simplefb_format *format = NULL;
+
-next trees and my time this cycle
On Fri, Dec 11, 2015 at 04:58:08PM +1000, Dave Airlie wrote: > Hey all, Hi Dave, > > Hopefully all my sub-maintainers are awake and reading this. > > So since Xmas is coming up and I've got an impending new arrival, I'm > betting this merge window might get a bit haphazard. So I'd like > people to start telling me now via git pull's what they'd like to get > in. > > I've seen etnaviv, rockchip(?), vc4 gpu api, can I get plans for if > people would like these in now, also anything I've missed on the list. > Other ARM maintainers (especially exynos) please try and get pull > requests in early. I might drop things that come in too late. I would like to include the HDLCD series as well if possible. I have pushed it at git://linux-arm.org/linux-ld for-upstream/hdlcd but I can send a pull request if you are happy to include it. Best regards, Liviu > > I expect the x86 folks and others who are pretty regular to not be a > problem (i.e. don't be a problem). Especially nouveau early is good > for me if you have anything. > > Dave. > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ã)_/¯
[Bug 92270] Radeon R7 M260/M265 - *ERROR* amdgpu: ring 0 test failed (scratch(0xC040)=0xCAFEDEAD)
https://bugs.freedesktop.org/show_bug.cgi?id=92270 --- Comment #7 from René Linder --- Is there any Progress with this Bug? I've a Notebook here from a project, where the Official Driver could not be used currently (Xorg 1.18) -- 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/20151211/8b579b43/attachment.html>
[Bug 92982] slow switching to KD_GRAPHICS (KMS?)
https://bugs.freedesktop.org/show_bug.cgi?id=92982 --- Comment #12 from royvandervegt at gmail.com --- Interestingly enough, it seems to have little to do with the clock speeds. With dpm turned on and radeon_dpm_force_performance_level set to high (doesn't switch properly): uvdvclk: 0 dclk: 0 power level 2sclk: 75000 mclk: 8 vddc: 1120 vddci: 0 With radeon.dpm=0 (WORKS, switches quickly): default engine clock: 75 kHz current engine clock: 749980 kHz default memory clock: 80 kHz current memory clock: 799870 kHz voltage: 1120 mV PCIE lanes: 16 -- 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/20151211/67c1ac4b/attachment.html>
[PATCH] drm: modes: Revert cc344980c767 "replace simple_strtoul by kstrtouint"
On Fri, Dec 11, 2015 at 01:58:59PM +0100, LABBE Corentin wrote:
> My latest commit introduce some case where a valid mode, could be
> rejected.
> simple_strtox functions stop at first non-digit character, but kstrtox
> not.
> So args like "video=HDMI-A-1:720x480-16 at 60" will be reject when checking
> 16 at .
>
> Discussions about this change comes to the conclusion that the best
> solution is to revert my commit cc344980c76748e57c9c03100c2a14d36ab00334.
>
> Signed-off-by: LABBE Corentin
Queued for -next, thanks for the patch.
-Daniel
> ---
> drivers/gpu/drm/drm_modes.c | 16 +---
> 1 file changed, 5 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index db36af7..3da1434 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -1230,7 +1230,7 @@ bool drm_mode_parse_command_line_for_connector(const
> char *mode_option,
> unsigned int xres = 0, yres = 0, bpp = 32, refresh = 0;
> bool yres_specified = false, cvt = false, rb = false;
> bool interlace = false, margins = false, was_digit = false;
> - int i, err;
> + int i;
> enum drm_connector_force force = DRM_FORCE_UNSPECIFIED;
>
> #ifdef CONFIG_FB
> @@ -1250,9 +1250,7 @@ bool drm_mode_parse_command_line_for_connector(const
> char *mode_option,
> case '@':
> if (!refresh_specified && !bpp_specified &&
> !yres_specified && !cvt && !rb && was_digit) {
> - err = kstrtouint(&name[i + 1], 10, &refresh);
> - if (err)
> - return false;
> + refresh = simple_strtol(&name[i+1], NULL, 10);
> refresh_specified = true;
> was_digit = false;
> } else
> @@ -1261,9 +1259,7 @@ bool drm_mode_parse_command_line_for_connector(const
> char *mode_option,
> case '-':
> if (!bpp_specified && !yres_specified && !cvt &&
> !rb && was_digit) {
> - err = kstrtouint(&name[i + 1], 10, &bpp);
> - if (err)
> - return false;
> + bpp = simple_strtol(&name[i+1], NULL, 10);
> bpp_specified = true;
> was_digit = false;
> } else
> @@ -1271,9 +1267,7 @@ bool drm_mode_parse_command_line_for_connector(const
> char *mode_option,
> break;
> case 'x':
> if (!yres_specified && was_digit) {
> - err = kstrtouint(&name[i + 1], 10, &yres);
> - if (err)
> - return false;
> + yres = simple_strtol(&name[i+1], NULL, 10);
> yres_specified = true;
> was_digit = false;
> } else
> @@ -1496,4 +1490,4 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
>
> out:
> return ret;
> -}
> +}
> \ No newline at end of file
> --
> 2.4.10
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
-next trees and my time this cycle
On Fri, Dec 11, 2015 at 10:02:45AM +, Russell King - ARM Linux wrote: > On Fri, Dec 11, 2015 at 04:58:08PM +1000, Dave Airlie wrote: > > I've seen etnaviv, rockchip(?), vc4 gpu api, can I get plans for if > > people would like these in now, also anything I've missed on the list. > > I would definitely like to see etnaviv make it in for the next merge > window, but that depends on it being reviewed, and I haven't seen > anything from DRM people yet. > > I've queued up some of the TDA998x and Armada DRM changes (3 and 5 > patches respectively) which I'll send you shortly if they haven't > already been merged via some other route. I did look at etnaviv on v1, if all the things I've raised there have been addressed (and it looks like, but no time for detailed checking): Acked-by: Daniel Vetter For detailed review it would be best to just get some of the new big submissions to cross review I think. But personally I'd be ok with etnaviv going in as is, trusting that you've done plenty of review within your group. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH 1/2] drm/dp: move hw_mutex up the call stack
On Wed, Dec 09, 2015 at 04:20:09PM -0500, Rob Clark wrote:
Something small missing here perhaps. The patch subject is not part
of the commit message body.
> 1) don't let other threads trying to bang on aux channel interrupt the
> defer timeout/logic
> 2) don't let other threads interrupt the i2c over aux logic
>
> Technically, according to people who actually have the DP spec, this
> should not be required. In practice, it makes some troublesome Dell
> monitor (and perhaps others) work, so probably a case of "It's compliant
> if it works with windows" on the hw vendor's part..
>
> Reported-by: Dave Wysochanski
> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1274157
> Cc: stable at vger.kernel.org
> Signed-off-by: Rob Clark
Real world wins.
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_dp_helper.c | 29 +++--
> 1 file changed, 19 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 9535c5b..76e08dc 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -178,7 +178,7 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8
> request,
> {
> struct drm_dp_aux_msg msg;
> unsigned int retry;
> - int err;
> + int err = 0;
>
> memset(&msg, 0, sizeof(msg));
> msg.address = offset;
> @@ -186,6 +186,8 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8
> request,
> msg.buffer = buffer;
> msg.size = size;
>
> + mutex_lock(&aux->hw_mutex);
> +
> /*
>* The specification doesn't give any recommendation on how often to
>* retry native transactions. We used to retry 7 times like for
> @@ -194,25 +196,24 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux,
> u8 request,
>*/
> for (retry = 0; retry < 32; retry++) {
>
> - mutex_lock(&aux->hw_mutex);
> err = aux->transfer(aux, &msg);
> - mutex_unlock(&aux->hw_mutex);
> if (err < 0) {
> if (err == -EBUSY)
> continue;
>
> - return err;
> + goto unlock;
> }
>
>
> switch (msg.reply & DP_AUX_NATIVE_REPLY_MASK) {
> case DP_AUX_NATIVE_REPLY_ACK:
> if (err < size)
> - return -EPROTO;
> - return err;
> + err = -EPROTO;
> + goto unlock;
>
> case DP_AUX_NATIVE_REPLY_NACK:
> - return -EIO;
> + err = -EIO;
> + goto unlock;
>
> case DP_AUX_NATIVE_REPLY_DEFER:
> usleep_range(AUX_RETRY_INTERVAL, AUX_RETRY_INTERVAL +
> 100);
> @@ -221,7 +222,11 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8
> request,
> }
>
> DRM_DEBUG_KMS("too many retries, giving up\n");
> - return -EIO;
> + err = -EIO;
> +
> +unlock:
> + mutex_unlock(&aux->hw_mutex);
> + return err;
> }
>
> /**
> @@ -542,10 +547,10 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux,
> struct drm_dp_aux_msg *msg)
>*/
> int max_retries = max(7, drm_dp_i2c_retry_count(msg,
> dp_aux_i2c_speed_khz));
>
> + WARN_ON(!mutex_is_locked(&aux->hw_mutex));
> +
> for (retry = 0, defer_i2c = 0; retry < (max_retries + defer_i2c);
> retry++) {
> - mutex_lock(&aux->hw_mutex);
> ret = aux->transfer(aux, msg);
> - mutex_unlock(&aux->hw_mutex);
> if (ret < 0) {
> if (ret == -EBUSY)
> continue;
> @@ -684,6 +689,8 @@ static int drm_dp_i2c_xfer(struct i2c_adapter *adapter,
> struct i2c_msg *msgs,
>
> memset(&msg, 0, sizeof(msg));
>
> + mutex_lock(&aux->hw_mutex);
> +
> for (i = 0; i < num; i++) {
> msg.address = msgs[i].addr;
> drm_dp_i2c_msg_set_request(&msg, &msgs[i]);
> @@ -738,6 +745,8 @@ static int drm_dp_i2c_xfer(struct i2c_adapter *adapter,
> struct i2c_msg *msgs,
> msg.size = 0;
> (void)drm_dp_i2c_do_msg(aux, &msg);
>
> + mutex_unlock(&aux->hw_mutex);
> +
> return err;
> }
>
> --
> 2.5.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel OTC
[PATCH 2/2] drm/dp: add DPCD logging
On Wed, Dec 09, 2015 at 04:20:10PM -0500, Rob Clark wrote:
> Add a new drm_debug bit for turning on DPCD logging, to aid debugging
> with troublesome monitors.
>
> v2: don't try to hexdump the universe if driver returns -errno, and
> change the "too many retries" traces to DRM_ERROR()
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/drm_dp_helper.c | 60
> ++---
> include/drm/drmP.h | 10 ++-
> 2 files changed, 59 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 76e08dc..3f27cc9 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -159,6 +159,44 @@ int drm_dp_bw_code_to_link_rate(u8 link_bw)
> }
> EXPORT_SYMBOL(drm_dp_bw_code_to_link_rate);
>
> +static ssize_t aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg
> *msg)
> +{
> + ssize_t ret;
> +
> + DRM_DEBUG_DPCD("%s: req=0x%02x, address=0x%05x, size=%zu\n", aux->name,
> + msg->request, msg->address, msg->size);
> +
> + if (unlikely(drm_debug & DRM_UT_DPCD)) {
> + switch (msg->request & ~DP_AUX_I2C_MOT) {
> + case DP_AUX_NATIVE_WRITE:
> + case DP_AUX_I2C_WRITE:
Missing DP_AUX_I2C_WRITE_STATUS_UPDATE on purpose?
> + print_hex_dump(KERN_DEBUG, "DPCD: ", DUMP_PREFIX_OFFSET,
> + 16, 1, msg->buffer, msg->size, false);
i2c != dpcd
So might be it should be called DRM_UT_AUX etc.
> + break;
> + default:
> + break;
> + }
> + }
> +
> + ret = aux->transfer(aux, msg);
> +
> + DRM_DEBUG_DPCD("%s: reply=0x%02x, size=%zd\n", aux->name, msg->reply,
> ret);
I was thinking the reply might contain random garbage on error, but at
least we memset the whole thing to zero initially, so I guess it ought
to be good enough.
> +
> + if (unlikely(drm_debug & DRM_UT_DPCD) && (ret > 0)) {
> + switch (msg->request & ~DP_AUX_I2C_MOT) {
> + case DP_AUX_NATIVE_READ:
> + case DP_AUX_I2C_READ:
> + print_hex_dump(KERN_DEBUG, "DPCD: ", DUMP_PREFIX_OFFSET,
> + 16, 1, msg->buffer, ret, false);
> + break;
> + default:
> + break;
> + }
> + }
> +
> + return ret;
> +}
> +
> #define AUX_RETRY_INTERVAL 500 /* us */
>
> /**
> @@ -196,7 +234,7 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8
> request,
>*/
> for (retry = 0; retry < 32; retry++) {
>
> - err = aux->transfer(aux, &msg);
> + err = aux_transfer(aux, &msg);
> if (err < 0) {
> if (err == -EBUSY)
> continue;
> @@ -212,16 +250,18 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux,
> u8 request,
> goto unlock;
>
> case DP_AUX_NATIVE_REPLY_NACK:
> + DRM_DEBUG_DPCD("native nack (result=%d, size=%zu)\n",
> err, msg.size);
> err = -EIO;
> goto unlock;
>
> case DP_AUX_NATIVE_REPLY_DEFER:
> + DRM_DEBUG_DPCD("native defer\n");
> usleep_range(AUX_RETRY_INTERVAL, AUX_RETRY_INTERVAL +
> 100);
> break;
> }
> }
>
> - DRM_DEBUG_KMS("too many retries, giving up\n");
> + DRM_ERROR("DPCD: too many retries, giving up!\n");
> err = -EIO;
>
> unlock:
> @@ -550,12 +590,12 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux,
> struct drm_dp_aux_msg *msg)
> WARN_ON(!mutex_is_locked(&aux->hw_mutex));
>
> for (retry = 0, defer_i2c = 0; retry < (max_retries + defer_i2c);
> retry++) {
> - ret = aux->transfer(aux, msg);
> + ret = aux_transfer(aux, msg);
> if (ret < 0) {
> if (ret == -EBUSY)
> continue;
>
> - DRM_DEBUG_KMS("transaction failed: %d\n", ret);
> + DRM_DEBUG_DPCD("transaction failed: %d\n", ret);
> return ret;
> }
>
> @@ -569,11 +609,11 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux,
> struct drm_dp_aux_msg *msg)
> break;
>
> case DP_AUX_NATIVE_REPLY_NACK:
> - DRM_DEBUG_KMS("native nack (result=%d, size=%zu)\n",
> ret, msg->size);
> + DRM_DEBUG_DPCD("native nack (result=%d, size=%zu)\n",
> ret, msg->size);
> return -EREMOTEIO;
>
> case DP_AUX_NATIVE_REPLY_DEFER:
> - DRM_DEBUG_KMS("native defer\n");
> + DRM_DEBUG_DPCD("native defer\n");
> /*
>* We could check for I2C bit
[Bug 93352] GRID Autosport crashes on start of race
https://bugs.freedesktop.org/show_bug.cgi?id=93352 Bug ID: 93352 Summary: GRID Autosport crashes on start of race Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: juergen.scholz.84 at gmail.com QA Contact: dri-devel at lists.freedesktop.org System configuration: * updated ubuntu wily/15.10 * Padoka PPA resulting in: * mesa 11.2~git151211033900.64c59b0~padoka0 * libllvm3.8 3.8~svn255314-0~padoka0 * xserver-xorg-video-radeon 7.6.99+git1512041459.78fbca0~padoka0 * linux kernel 4.4.0-040400rc4-generic (kernel.org) PPA OR * linux kernel 4.2.0-19-generic (ubuntu wily default kernel) Graphics card: ~> lspci -v -s 01:00.0 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Tahiti XT [Radeon HD 7970/8970 OEM / R9 280X] (prog-if 00 [VGA controller]) Subsystem: XFX Pine Group Inc. Device 3001 Flags: bus master, fast devsel, latency 0, IRQ 41 Memory at e000 (64-bit, prefetchable) [size=256M] Memory at f7e0 (64-bit, non-prefetchable) [size=256K] I/O ports at e000 [size=256] Expansion ROM at f7e4 [disabled] [size=128K] Capabilities: Kernel driver in use: radeon To reproduce (you will possibly need a Tahiti XT card): 1) Start GRID via Steam 2) Go through the menus to start a game or a benchmark 3) The game will crash immediately after the loading screen dmesg: OpenGL dispatch[8010]: segfault at 7fbfce4bf774 ip 7fc131b2ef75 sp 7fc12653b430 error 4 in radeonsi_dri.so[7fc131919000+931000] I will try to get a backtrace with gdb. -- 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/20151211/af357763/attachment.html>
[Bug 93352] GRID Autosport crashes on start of race
https://bugs.freedesktop.org/show_bug.cgi?id=93352 --- Comment #1 from Jürgen Scholz --- I might have gotten a possibly incomplete backtrace: (gdb) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f34937fe700 (LWP 22944)] 0x7f34f7717f75 in translate_src (t=, src_reg=) at ../../../../src/mesa/state_tracker/st_glsl_to_tgsi.cpp:4629 4629../../../../src/mesa/state_tracker/st_glsl_to_tgsi.cpp: Datei oder Verzeichnis nicht gefunden. (gdb) bt #0 0x7f34f7717f75 in translate_src (t=, src_reg=) at ../../../../src/mesa/state_tracker/st_glsl_to_tgsi.cpp:4629 #1 0x7f34f773d4b1 in st_translate_program (ctx=, procType=, ureg=, program=, proginfo=, numInputs=, inputMapping=, inputSlotToAttr=, inputSemanticName=, inputSemanticIndex=, interpMode=, interpLocation=, numOutputs=, outputMapping=, outputSlotToAttr=, outputSemanticName=, outputSemanticIndex=) at ../../../../src/mesa/state_tracker/st_glsl_to_tgsi.cpp:4798 #2 0x7f34f774d203 in st_translate_program_common (st=, prog=, glsl_to_tgsi=, ureg=, tgsi_processor=, out_state=) at ../../../../src/mesa/state_tracker/st_program.c:1266 #3 0x7f34f774e7c6 in st_translate_tesseval_program (st=0x6478b50, sttep=0x7f338996ca20) at ../../../../src/mesa/state_tracker/st_program.c:1496 #4 0x7f34f770bda5 in st_program_string_notify (ctx=, target=, prog=0x7f338996ca20) at ../../../../src/mesa/state_tracker/st_cb_program.c:275 #5 0x7f34f774187c in st_link_shader (ctx=, prog=) at ../../../../src/mesa/state_tracker/st_glsl_to_tgsi.cpp:5877 #6 0x7f34f77579eb in _mesa_glsl_link_shader (ctx=, prog=) at ../../../../src/mesa/program/ir_to_mesa.cpp:2984 #7 0x7f34f768532b in link_program (ctx=0x6439b40, program=) at ../../../../src/mesa/main/shaderapi.c:1047 #8 0x008b1171 in ?? () #9 0x7f350e576030 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #10 0x7f35092436aa in start_thread (arg=0x7f34937fe700) at pthread_create.c:333 #11 0x7f3507a45eed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 -- 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/20151211/90e94079/attachment-0001.html>
[Bug 93353] GRID Autosport crash on loading screen with an HD 6950
https://bugs.freedesktop.org/show_bug.cgi?id=93353 Bug ID: 93353 Summary: GRID Autosport crash on loading screen with an HD 6950 Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: blocker Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel at lists.freedesktop.org Reporter: serge.yquel at laposte.net QA Contact: dri-devel at lists.freedesktop.org Created attachment 120465 --> https://bugs.freedesktop.org/attachment.cgi?id=120465&action=edit GRID Autosport crash report Hello, On loading screen just before starting a race, the game crash to the desktop with this on the terminal: EE r600_shader.c:182 r600_pipe_shader_create - translation from TGSI failed ! EE r600_state_common.c:826 r600_shader_select - Failed to build shader variant (type=1) -1 i added a crash report from the game .dmp, if it can help. it was working on low setting with a previous version of mesa, i don't know the exact version number but it was just before r600 add full support for OpenGL 4.1 and probably the tesselation. Here are the information about the version i currently use and make the game crash just before the race start: VGA: Advanced Micro Devices, Inc. [AMD/ATI] Cayman PRO [Radeon HD 6950] Driver: r600 direct rendering: Yes OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD CAYMAN (DRM 2.43.0, LLVM 3.8.0) OpenGL core profile version string: 4.1 (Core Profile) Mesa 11.2.0-devel (git-369afdb) OpenGL core profile shading language version string: 4.10 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile GL_ARB_direct_state_access, GL_ARB_draw_buffers, GL_ARB_draw_indirect, GL_ARB_draw_instanced, GL_ARB_map_buffer_range, GL_ARB_multi_bind, GL_ARB_multi_draw_indirect, OpenGL version string: 3.0 Mesa 11.2.0-devel (git-369afdb) OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL ES profile version string: OpenGL ES 3.0 Mesa 11.2.0-devel (git-369afdb) OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00 -- 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/20151211/4e2e15cd/attachment.html>
[PATCH v7 02/14] drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.
Hi Matthias, thanks for your reply. It would be helpful if you could trim the quoted text a bit when replying to a small part of a huge patch like this. Am Freitag, den 11.12.2015, 18:10 +0100 schrieb Matthias Brugger: > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c > > b/drivers/gpu/drm/mediatek/mtk_drm_drv.c > > new file mode 100644 > > index 000..a34c765 > > --- /dev/null > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c > > @@ -0,0 +1,562 @@ > > +/* > > + * Copyright (c) 2015 MediaTek Inc. > > + * Author: YT SHEN > > + * > > + * This program is free software; you can redistribute it and/or modify > > + * it under the terms of the GNU General Public License version 2 as > > + * published by the Free Software Foundation. > > + * > > + * This program is distributed in the hope that it will be useful, > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > > + * GNU General Public License for more details. > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > Do we need this include here? No, thank you for noticing. Will be removed in the next version. best regards Philipp
[Bug 93353] GRID Autosport crash on loading screen with an HD 6950
https://bugs.freedesktop.org/show_bug.cgi?id=93353 --- Comment #1 from serge --- i also have this on another try: EE r600_shader.c:182 r600_pipe_shader_create - translation from TGSI failed ! EE r600_state_common.c:826 r600_shader_select - Failed to build shader variant (type=1) -1 EE r600_shader.c:429 tgsi_is_supported - unsupported src 1 (file 0, dimension 1) EE r600_shader.c:182 r600_pipe_shader_create - translation from TGSI failed ! EE r600_state_common.c:826 r600_shader_select - Failed to build shader variant (type=4) -22 -- 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/20151211/e174350b/attachment.html>
[Bug 93352] GRID Autosport crashes on start of race
https://bugs.freedesktop.org/show_bug.cgi?id=93352 --- Comment #2 from Jürgen Scholz --- After installing (possibly unnecessary debug symbols and source files): * aptitude install libgl1-mesa-dri-dev:i386 libgl1-mesa-dri-dbg:i386 libgl1-mesa-dri-dbg xserver-xorg-video-radeon-dbg libgl1-mesa-dev * cd /usr/src; apt-get source libgl1-mesa-dri * ln -s /usr/src/mesa-11.2~git151211033900.64c59b0~padoka0/src/mesa /usr/src/mesa The backtrace seems to be complete: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f45137fe700 (LWP 9173)] 0x7f452824cd43 in LLVMBuildLoad () from /usr/lib/x86_64-linux-gnu/libLLVM-3.8.so.1 (gdb) bt #0 0x7f452824cd43 in LLVMBuildLoad () from /usr/lib/x86_64-linux-gnu/libLLVM-3.8.so.1 #1 0x7f452b751aa3 in emit_array_index (bld=, reg=, offset=4294955456) at ../../../../../../src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c:108 #2 0x7f452b753a25 in radeon_llvm_emit_fetch (bld_base=0x7f45137f57d0, reg=0x7f43b7077f90, type=TGSI_TYPE_FLOAT, swizzle=0) at ../../../../../../src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c:191 #3 0x7f452b4144e2 in lp_build_emit_fetch (bld_base=0x7f45137f57d0, inst=0x7f43b7077f50, src_op=1, chan_index=) at ../../../../../src/gallium/auxiliary/gallivm/lp_bld_tgsi.c:351 #4 0x7f452b414654 in lp_build_fetch_args (bld_base=0x7f45137f57d0, emit_data=0x7f45137f4bd0) at ../../../../../src/gallium/auxiliary/gallivm/lp_bld_tgsi.c:180 #5 0x7f452b4149db in lp_build_tgsi_inst_llvm (bld_base=0x7f45137f57d0, inst=0x7f43b7077f50) at ../../../../../src/gallium/auxiliary/gallivm/lp_bld_tgsi.c:291 #6 0x7f452b414c6d in lp_build_tgsi_llvm (bld_base=0x7f45137f57d0, tokens=) at ../../../../../src/gallium/auxiliary/gallivm/lp_bld_tgsi.c:518 #7 0x7f452b69161e in si_shader_create (sscreen=0x344fc20, tm=0x6a0fb30, shader=0x7f43b6e51230) at ../../../../../../src/gallium/drivers/radeonsi/si_shader.c:4177 #8 0x7f452b69c389 in si_shader_select (ctx=0x696cb30, state=0x696d780) at ../../../../../../src/gallium/drivers/radeonsi/si_state_shaders.c:619 #9 0x7f452b69cd08 in si_update_shaders (sctx=0x696cb30) at ../../../../../../src/gallium/drivers/radeonsi/si_state_shaders.c:1514 #10 0x7f452b699679 in si_draw_vbo (ctx=0x696cb30, info=0x7f45137fd300) at ../../../../../../src/gallium/drivers/radeonsi/si_state_draw.c:788 #11 0x7f452b3ae207 in u_vbuf_draw_vbo (mgr=0x6a74200, info=0x7f45137fd300) at ../../../../../src/gallium/auxiliary/util/u_vbuf.c:1162 #12 0x7f452b1fa523 in st_draw_vbo (ctx=0x6a1ce70, prims=0x7f45137fd3c0, nr_prims=, ib=0x0, index_bounds_valid=, min_index=0, max_index=2, tfb_vertcount=0x0, stream=0, indirect=0x0) at ../../../../src/mesa/state_tracker/st_draw.c:291 #13 0x7f452b1c83f6 in vbo_draw_arrays (ctx=0x6a1ce70, mode=14, start=0, count=3, numInstances=1, baseInstance=0) at ../../../../src/mesa/vbo/vbo_exec_array.c:645 #14 0x008b1171 in ?? () #15 0x7f454205d030 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #16 0x7f453cd2a6aa in start_thread (arg=0x7f45137fe700) at pthread_create.c:333 #17 0x7f453b52ceed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 (gdb) Can I supply more information? -- 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/20151211/7b6eea2b/attachment.html>
[Bug 93353] GRID Autosport crash on loading screen with an HD 6950
https://bugs.freedesktop.org/show_bug.cgi?id=93353 --- Comment #2 from Jürgen Scholz --- This could be related to the report just filed by me: https://bugs.freedesktop.org/show_bug.cgi?id=93352 -- 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/20151211/d9e1f683/attachment-0001.html>
-next trees and my time this cycle
On Fri, Dec 11, 2015 at 05:15:40PM +0100, Daniel Vetter wrote: > On Fri, Dec 11, 2015 at 10:02:45AM +, Russell King - ARM Linux wrote: > > On Fri, Dec 11, 2015 at 04:58:08PM +1000, Dave Airlie wrote: > > > I've seen etnaviv, rockchip(?), vc4 gpu api, can I get plans for if > > > people would like these in now, also anything I've missed on the list. > > > > I would definitely like to see etnaviv make it in for the next merge > > window, but that depends on it being reviewed, and I haven't seen > > anything from DRM people yet. > > > > I've queued up some of the TDA998x and Armada DRM changes (3 and 5 > > patches respectively) which I'll send you shortly if they haven't > > already been merged via some other route. > > I did look at etnaviv on v1, if all the things I've raised there have been > addressed (and it looks like, but no time for detailed checking): I did keep a list of your points, and made sure that we'd addressed them all. We went a little further towards the end with your 'flags' suggestion for several of the ioctls, which I think was a very good point you raised. > Acked-by: Daniel Vetter Thanks! > For detailed review it would be best to just get some of the new big > submissions to cross review I think. But personally I'd be ok with > etnaviv going in as is, trusting that you've done plenty of review > within your group. We have had a certain amount of review within our group - Christian reviewed many of my early patches, and I've reviewed Lucas' patches. There could have been more review. I was rather hoping for some review of the changes since your last comments, especially with the locking changes. I'm fairly confident with the locking changes (which were particularly hairy) as I've been running them for some time now with lockdep enabled. The particularly "hairy" bit was in etnaviv_gem_get_iova(). -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[Bug 93217] [tonga] [powerplay] Radon M395X isn't initialised with the powerplay branch
https://bugs.freedesktop.org/show_bug.cgi?id=93217 --- Comment #9 from Alex Deucher --- Please try the latest powerplay branch and attach the dmesg log. It will print some additional debugging info for the failures. -- 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/20151211/9564a2ac/attachment.html>
[Bug 93352] GRID Autosport crashes on start of race
https://bugs.freedesktop.org/show_bug.cgi?id=93352 --- Comment #3 from Ilia Mirkin --- The first issue is somewhere with glsl ir -> tgsi translation of a tessellation evaluation program. The second issue is that the generated TGSI is somehow problematic (or radeonsi has issues processing it). It might be helpful to run the program with MESA_GLSL=dump ST_DEBUG=tgsi in the environment, and provide the resulting log file. I expect it'll be quite large. -- 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/20151211/5cd5ebe7/attachment.html>
[PULL] drm-intel-next
Hi Dave,
drm-intel-next-2015-12-04-1:
This is the "fix igt basic test set issues" edition.
- more PSR fixes from Rodrigo, getting closer
- tons of fifo underrun fixes from Ville
- runtime pm fixes from Imre, Daniel Stone
- fix SDE interrupt handling properly (Jani Nikula)
- hsw/bdw fdi modeset sequence fixes (Ville)
- "don't register bad VGA connectors and fall over" fixes (Ville)
- more fbc fixes from Paulo
- and a grand total of exactly one feature item: Implement dma-buf/fence based
cross-driver sync in the i915 pageflip path (Alex Goins)
For 4.4 there's going to be another sizeable drm-misc (will seend out
soonish), plus another round of drm-intel stuff.
Cheers, Daniel
The following changes since commit 92907cbbef8625bb3998d1eb385fc88f23c97a3f:
Merge tag 'v4.4-rc2' into drm-intel-next-queued (2015-11-23 09:04:05 +0100)
are available in the git repository at:
git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-2015-12-04-1
for you to fetch changes up to 03a97d825573de7b6ff1b44f257345efbff2161a:
drm/i915: Update DRIVER_DATE to 20151204 (2015-12-04 21:56:02 +0100)
This is the "fix igt basic test set issues" edition.
- more PSR fixes from Rodrigo, getting closer
- tons of fifo underrun fixes from Ville
- runtime pm fixes from Imre, Daniel Stone
- fix SDE interrupt handling properly (Jani Nikula)
- hsw/bdw fdi modeset sequence fixes (Ville)
- "don't register bad VGA connectors and fall over" fixes (Ville)
- more fbc fixes from Paulo
- and a grand total of exactly one feature item: Implement dma-buf/fence based
cross-driver sync in the i915 pageflip path (Alex Goins)
Alex Dai (1):
drm/i915/guc: Clean up locks in GuC
Alex Goins (2):
i915: wait for fence in mmio_flip_work_func
i915: wait for fence in prepare_plane_fb
Chris Wilson (1):
drm/i915: Fix RPS pointer passed from wait_ioctl to i915_wait_request
Daniel Stone (2):
drm/i915/pm: Unstatic power_domain_str
drm/i915/pm: Print offending domain in refcount failure
Daniel Vetter (5):
drm/i915: fix fdi related fifo underruns on hsw
Revert "drm/i915: Remove superfluous NULL check"
drm/i915: Restore skl_gt3 device info
Revert "drm/i915: Extend LRC pinning to cover GPU context writeback"
drm/i915: Update DRIVER_DATE to 20151204
Deepak M (1):
drm/i915: Correct the Ref clock value for BXT
Gerd Hoffmann (1):
drm/i915: more virtual south bridge detection
Imre Deak (3):
drm/i915/skl: enable PC9/10 power states during suspend-to-idle
drm/i915/skl: re-enable power well support
drm/i915/bxt: backlight clock gating workaround
Jani Nikula (10):
drm/i915: remove duplicate definition of for_each_power_domain
drm/i915: fix the SDE irq dmesg warnings properly
Revert "drm/i915: shut up gen8+ SDE irq dmesg noise"
drm/i915/dsi: merge pre_pll_enable hook to pre_enable
drm/i915: remove pre_pll_enable hook from DDI/gen9+ crtc enable
drm/i915: add has_dsi_encoder to crtc state
drm/i915/bxt: add support for setting backlight freq from vbt
drm/i915: use default 200 Hz backlight frequency
drm/i915: simplify gmbus xfer error checks
drm/i915: abstract i2c bit banging fallback in gmbus xfer
Maarten Lankhorst (1):
drm/i915: Handle cdclk limits on broadwell.
Matt Roper (1):
drm/i915/bxt: Disable power well support
Mika Kuoppala (1):
drm/i915/skl: Add SKL GT4 PCI IDs
Namrta Salonie (1):
drm/i915: Fix possible null dereference in framebuffer_info debugfs
function
Nick Hoath (1):
drm/i915: Extend LRC pinning to cover GPU context writeback
Paulo Zanoni (11):
drm/i915: fix the CFB size check
drm/i915: set dev_priv->fbc.crtc before scheduling the enable work
drm/i915: pass the crtc as an argument to intel_fbc_update()
drm/i915: introduce is_active/activate/deactivate to the FBC terminology
drm/i915: introduce intel_fbc_{enable,disable}
drm/i915: alloc/free the FBC CFB during enable/disable
drm/i915: check for FBC planes in the same place as the pipes
drm/i915: use a single intel_fbc_work struct
drm/i915: kill fbc.uncompressed_size
drm/i915: get rid of FBC {,de}activation messages
drm/i915: only recompress FBC after flushing a drawing operation
Rodrigo Vivi (5):
drm/i915: Remove duplicated dpcd write on hsw_psr_enable_sink.
drm/i915: PSR: Let's rely more on frontbuffer tracking.
drm/i915: PSR: Mask LPSP hw tracking back again.
drm/i915: Remove PSR Perf Counter for SKL+
drm/i915: Also disable PSR on Sink when disabling it on Source.
Takashi Iwai (1):
drm/i915: Remove superfluous NULL check
Tvrtko Ursulin (1):
drm/i915: Remove incorrect warning in context cleanup
Ville Syrjälä (20):
drm/i915: Suppress spurious CPU FIFO underruns o
[Bug 93217] [tonga] [powerplay] Radon M395X isn't initialised with the powerplay branch
https://bugs.freedesktop.org/show_bug.cgi?id=93217 Mike Lothian changed: What|Removed |Added Attachment #120399|0 |1 is obsolete|| --- Comment #10 from Mike Lothian --- Created attachment 120466 --> https://bugs.freedesktop.org/attachment.cgi?id=120466&action=edit Dmesg with rebased powerplay branch Seems "init_thermal_controller failed" is the problem -- 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/20151211/51fd3f1c/attachment.html>
[Bug 92944] [Fiji/LLVM/RadeonSI] CS:GO segfaults in llvm
https://bugs.freedesktop.org/show_bug.cgi?id=92944 --- Comment #10 from Tobias Droste --- It's not a mesa change that caused this. I have the same problem with Hawaii. The first time I saw this I tried an older version of mesa which worked a day before and the problem was still there. I can't say which change in llvm caused this, because I'm only building mesa on my own and receive a prebuilt llvm copy from a repository. I can upload a backtrace as well if you want, but the segfault I see also happens in SlotIndex::getIndex(). -- 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/20151211/1b9d71a6/attachment-0001.html>
[Bug 93352] GRID Autosport crashes on start of race
https://bugs.freedesktop.org/show_bug.cgi?id=93352 --- Comment #4 from Jürgen Scholz --- Created attachment 120468 --> https://bugs.freedesktop.org/attachment.cgi?id=120468&action=edit Console log of GRID Autosport This file is the output of a game session which goes from start through the menu to the loading screen. It ends (=game crashes) at the (end of the) loading screen. Sadly the file is rather huge (35MB), so I zipped it (3MB). The command line used to obtain it: ~> env LD_PRELOAD='/usr/$LIB/libstdc++.so.6' DISPLAY=:0 \ PATH="~/.steam/ubuntu12_32/steam-runtime/amd64/bin:~/.steam/ubuntu12_32/steam-runtime/amd64/usr/bin:$PATH" \ LD_LIBRARY_PATH="/home/juergen/.steam/ubuntu12_32/steam-runtime/i386/lib/i386-linux-gnu:/home/juergen/.steam/ubuntu12_32/steam-runtime/i386/lib:/home/juergen/.steam/ubuntu12_32/steam-runtime/i386/usr/lib/i386-linux-gnu:/home/juergen/.steam/ubuntu12_32/steam-runtime/i386/usr/lib:/home/juergen/.steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu:/home/juergen/.steam/ubuntu12_32/steam-runtime/amd64/lib:/home/juergen/.steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu:/home/juergen/.steam/ubuntu12_32/steam-runtime/amd64/usr/lib:/home/juergen/.steam/ubuntu12_32:/home/juergen/.steam/ubuntu12_32/panorama:/usr/lib32" \ LANG=C MESA_GLSL=dump ST_DEBUG=tgsi \ /home/juergen/.steam/SteamApps/common/GRID\ Autosport/bin/GridAutosport 2>| cat - > /home/juergen/gridAutosport_console.txt -- 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/20151211/9ed7afb6/attachment.html>
[Bug 93352] GRID Autosport crashes on start of race
https://bugs.freedesktop.org/show_bug.cgi?id=93352 --- Comment #5 from Ilia Mirkin --- Hmmm... that did not have the desired output. Can you make sure to build mesa with --enable-debug ? I'm guessing some of the stuff is only output in that case. Also, for your next attachment, please use xz -9 foo.log (saves a step... zip is an archive, so you have to unzip in order to see it, while with a stream compression format you can view it directly). -- 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/20151211/ea2489dd/attachment.html>
[Bug 92944] [Fiji/LLVM/RadeonSI] CS:GO segfaults in llvm
https://bugs.freedesktop.org/show_bug.cgi?id=92944 --- Comment #11 from Tobias Droste --- The change in LLVM happend somewhere between November 9th (known good) and yesterday (known bad). -- 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/20151211/f20dc31d/attachment.html>
[Bug 93352] GRID Autosport crashes on start of race
https://bugs.freedesktop.org/show_bug.cgi?id=93352 --- Comment #6 from Jürgen Scholz --- Created attachment 120469 --> https://bugs.freedesktop.org/attachment.cgi?id=120469&action=edit Second console log of GRID Autosport I am looking into building the mesa package with the debug option. I have not done that before, so I will need some time. In the meantime I kindly ask you to check if the issue is solvable with additional environment variables. http://www.mesa3d.org/envvars.html and http://www.mesa3d.org/shading.html#envvars could be helpful. Attached is another console log, where the command line now includes environment switches to enable more debug output. Thanks for the tip about using xz. Awesome! Command line: ulimit -c unlimited; env LD_PRELOAD='/usr/$LIB/libstdc++.so.6' DISPLAY=:0 \ PATH="~/.steam/ubuntu12_32/steam-runtime/amd64/bin:~/.steam/ubuntu12_32/steam-runtime/amd64/usr/bin:$PATH" \ LD_LIBRARY_PATH="/home/juergen/.steam/ubuntu12_32/steam-runtime/i386/lib/i386-linux-gnu:/home/juergen/.steam/ubuntu12_32/steam-runtime/i386/lib:/home/juergen/.steam/ubuntu12_32/steam-runtime/i386/usr/lib/i386-linux-gnu:/home/juergen/.steam/ubuntu12_32/steam-runtime/i386/usr/lib:/home/juergen/.steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu:/home/juergen/.steam/ubuntu12_32/steam-runtime/amd64/lib:/home/juergen/.steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu:/home/juergen/.steam/ubuntu12_32/steam-runtime/amd64/usr/lib:/home/juergen/.steam/ubuntu12_32:/home/juergen/.steam/ubuntu12_32/panorama:/usr/lib32" \ LANG=C \ MESA_GLSL=dump ST_DEBUG=tgsi \ LIBGL_DEBUG=verbose MESA_DEBUG=true \ /home/juergen/.steam/SteamApps/common/GRID\ Autosport/bin/GridAutosport 2>| cat - > /home/juergen/gridAutosport_console(date +%Y%m%d-%H%M%S).txt -- 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/20151211/0249d2e0/attachment.html>
[Bug 93270] Only one of LVDS and VGA-0 work on HP Pavilion m6 with Radeon HD 7660G
https://bugs.freedesktop.org/show_bug.cgi?id=93270 --- Comment #5 from Suren Karapetyan --- Is there any other information I can provide to help with this? I'll have time to spend on this during the weekend and a little system programming experience. -- 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/20151211/bdcba369/attachment.html>
[PATCH] intel: merge latest i915_drm.h
Pick up context flags, softpin, etc.
Signed-off-by: Jesse Barnes
---
include/drm/i915_drm.h | 57 ++
1 file changed, 48 insertions(+), 9 deletions(-)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index ded43b1..4ce1fe9 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -171,8 +171,12 @@ typedef struct _drm_i915_sarea {
#define I915_BOX_TEXTURE_LOAD 0x8
#define I915_BOX_LOST_CONTEXT 0x10
-/* I915 specific ioctls
- * The device specific ioctl range is 0x40 to 0x79.
+/*
+ * i915 specific ioctls.
+ *
+ * The device specific ioctl range is [DRM_COMMAND_BASE, DRM_COMMAND_END) ie
+ * [0x40, 0xa0) (a0 is excluded). The numbers below are defined as offset
+ * against DRM_COMMAND_BASE and should be between [0x0, 0x60).
*/
#define DRM_I915_INIT 0x00
#define DRM_I915_FLUSH 0x01
@@ -270,7 +274,7 @@ typedef struct _drm_i915_sarea {
#define DRM_IOCTL_I915_OVERLAY_PUT_IMAGE DRM_IOW(DRM_COMMAND_BASE +
DRM_I915_OVERLAY_PUT_IMAGE, struct drm_intel_overlay_put_image)
#define DRM_IOCTL_I915_OVERLAY_ATTRS DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_OVERLAY_ATTRS, struct drm_intel_overlay_attrs)
#define DRM_IOCTL_I915_SET_SPRITE_COLORKEY DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_SET_SPRITE_COLORKEY, struct drm_intel_sprite_colorkey)
-#define DRM_IOCTL_I915_GET_SPRITE_COLORKEY DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_SET_SPRITE_COLORKEY, struct drm_intel_sprite_colorkey)
+#define DRM_IOCTL_I915_GET_SPRITE_COLORKEY DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GET_SPRITE_COLORKEY, struct drm_intel_sprite_colorkey)
#define DRM_IOCTL_I915_GEM_WAITDRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_WAIT, struct drm_i915_gem_wait)
#define DRM_IOCTL_I915_GEM_CONTEXT_CREATE DRM_IOWR (DRM_COMMAND_BASE +
DRM_I915_GEM_CONTEXT_CREATE, struct drm_i915_gem_context_create)
#define DRM_IOCTL_I915_GEM_CONTEXT_DESTROY DRM_IOW (DRM_COMMAND_BASE +
DRM_I915_GEM_CONTEXT_DESTROY, struct drm_i915_gem_context_destroy)
@@ -350,9 +354,16 @@ typedef struct drm_i915_irq_wait {
#define I915_PARAM_REVISION 32
#define I915_PARAM_SUBSLICE_TOTAL 33
#define I915_PARAM_EU_TOTAL 34
+#define I915_PARAM_HAS_GPU_RESET35
+#define I915_PARAM_HAS_RESOURCE_STREAMER 36
+#define I915_PARAM_HAS_EXEC_SOFTPIN 37
typedef struct drm_i915_getparam {
- int param;
+ __s32 param;
+ /*
+* WARNING: Using pointers instead of fixed-size u64 means we need to
write
+* compat32 code. Don't repeat this mistake.
+*/
int *value;
} drm_i915_getparam_t;
@@ -672,15 +683,21 @@ struct drm_i915_gem_exec_object2 {
__u64 alignment;
/**
-* Returned value of the updated offset of the object, for future
-* presumed_offset writes.
+* When the EXEC_OBJECT_PINNED flag is specified this is populated by
+* the user with the GTT offset at which this object will be pinned.
+* When the I915_EXEC_NO_RELOC flag is specified this must contain the
+* presumed_offset of the object.
+* During execbuffer2 the kernel populates it with the value of the
+* current GTT offset of the object, for future presumed_offset writes.
*/
__u64 offset;
#define EXEC_OBJECT_NEEDS_FENCE (1<<0)
#define EXEC_OBJECT_NEEDS_GTT (1<<1)
#define EXEC_OBJECT_WRITE (1<<2)
-#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_WRITE<<1)
+#define EXEC_OBJECT_SUPPORTS_48B_ADDRESS (1<<3)
+#define EXEC_OBJECT_PINNED (1<<4)
+#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_PINNED<<1)
__u64 flags;
__u64 rsvd1;
@@ -760,7 +777,12 @@ struct drm_i915_gem_execbuffer2 {
#define I915_EXEC_BSD_RING1(1<<13)
#define I915_EXEC_BSD_RING2(2<<13)
-#define __I915_EXEC_UNKNOWN_FLAGS -(1<<15)
+/** Tell the kernel that the batchbuffer is processed by
+ * the resource streamer.
+ */
+#define I915_EXEC_RESOURCE_STREAMER (1<<15)
+
+#define __I915_EXEC_UNKNOWN_FLAGS -(I915_EXEC_RESOURCE_STREAMER<<1)
#define I915_EXEC_CONTEXT_ID_MASK (0x)
#define i915_execbuffer2_set_context_id(eb2, context) \
@@ -996,6 +1018,7 @@ struct drm_intel_overlay_put_image {
/* flags */
#define I915_OVERLAY_UPDATE_ATTRS (1<<0)
#define I915_OVERLAY_UPDATE_GAMMA (1<<1)
+#define I915_OVERLAY_DISABLE_DEST_COLORKEY (1<<2)
struct drm_intel_overlay_attrs {
__u32 flags;
__u32 color_key;
@@ -1062,9 +1085,23 @@ struct drm_i915_gem_context_destroy {
};
struct drm_i915_reg_read {
+ /*
+* Register offset.
+* For 64bit wide registers where the upper 32bits don't immediately
+* follow the lower 32bits, the offset of the lower 32bits must
+* be specified
+*/
__u64 offset;
__u64 val; /* Return value */
};
+/* Known registers:
+ *
+ * Render engine timestamp - 0x2358 + 64bit - gen7+
+ * - Note this register returns an invalid valu
[Bug 93353] GRID Autosport crash on loading screen with an HD 6950
https://bugs.freedesktop.org/show_bug.cgi?id=93353 --- Comment #3 from Ilia Mirkin --- You might try running with ST_DEBUG=tgsi -- should show the failing shaders. Make sure you're on a debug build. MESA_GLSL=dump should be interesting too. [Sadly there's a 4k limit on the dumped shader code size which is likely too short for a lot of shaders...] -- 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/20151211/fde3f22b/attachment.html>
[PATCH 5/5] drm: Enable markdown^Wasciidoc for gpu.tmpl
On Wed, 25 Nov 2015 18:07:59 +0100 Daniel Vetter wrote: > Unfortunately the entire improved docbook project died at KS in a > massive bikeshed. So we need to carry this around in drm private trees > forever :( I don't think that's an entirely helpful way to look at things, honestly. Changing how the docs system works affects a lot of people, they're going to have input on the matter. And I sure hope it hasn't "died". The posting of these patches suggests that perhaps it has not. Anyway, I wanted to say that, my silence notwithstanding, I haven't just dropped these. I had some hassles to deal with (replacing the entire LWN server infrastructure, for example) but those are done; I hope to be able to mess with this stuff a bit in the very near future. Have the table-rendering issues that Graham talked about before gotten any better with the newer scheme? Thanks, jon
[GIT PULL] VC4 3D support
Hi Dave, Since you asked for early pull requests, here's what I've got queued up. I may want to add some more after this if I can, but this will let us ship 3D support on 4.5 kernels. It's also what I'm pushing to the Raspberry Pi Foundation kernel for their update to 4.2. The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec: Linux 4.4-rc1 (2015-11-15 17:00:27 -0800) are available in the git repository at: http://github.com/anholt/linux drm-vc4-next-2015-12-11 for you to fetch changes up to d6f19f9ace07a246389f8e4803daf796aeb1f263: drm/vc4: Add support for more a few more RGB display plane formats. (2015-12-11 16:27:47 -0800) This pull request brings in 3D acceleration support for the VC4 GPU. While there is still performance work to be done (particularly surrounding RCL generation), the CL submit ABI should be settled and done now. Eric Anholt (10): drm: Create a driver hook for allocating GEM object structs. drm/vc4: Add a BO cache. drm/vc4: Add create and map BO ioctls. drm/vc4: Add an API for creating GPU shaders in GEM BOs. drm/vc4: Fix a typo in a V3D debug register. drm/vc4: Bind and initialize the V3D engine. drm/vc4: Add support for drawing 3D frames. drm/vc4: Add support for async pageflips. drm/vc4: Add an interface for capturing the GPU state after a hang. drm/vc4: Add support for more a few more RGB display plane formats. drivers/gpu/drm/drm_gem_cma_helper.c | 10 +- drivers/gpu/drm/vc4/Makefile | 11 +- drivers/gpu/drm/vc4/vc4_bo.c | 517 - drivers/gpu/drm/vc4/vc4_crtc.c | 99 +++- drivers/gpu/drm/vc4/vc4_debugfs.c | 3 + drivers/gpu/drm/vc4/vc4_drv.c | 36 +- drivers/gpu/drm/vc4/vc4_drv.h | 318 +- drivers/gpu/drm/vc4/vc4_gem.c | 867 +++ drivers/gpu/drm/vc4/vc4_irq.c | 210 +++ drivers/gpu/drm/vc4/vc4_kms.c | 149 - drivers/gpu/drm/vc4/vc4_packet.h | 399 + drivers/gpu/drm/vc4/vc4_plane.c| 56 ++ drivers/gpu/drm/vc4/vc4_qpu_defines.h | 264 + drivers/gpu/drm/vc4/vc4_regs.h | 2 +- drivers/gpu/drm/vc4/vc4_render_cl.c| 634 drivers/gpu/drm/vc4/vc4_trace.h| 63 ++ drivers/gpu/drm/vc4/vc4_trace_points.c | 14 + drivers/gpu/drm/vc4/vc4_v3d.c | 262 + drivers/gpu/drm/vc4/vc4_validate.c | 900 + drivers/gpu/drm/vc4/vc4_validate_shaders.c | 513 include/drm/drmP.h | 7 + include/uapi/drm/Kbuild| 1 + include/uapi/drm/vc4_drm.h | 279 + 23 files changed, 5593 insertions(+), 21 deletions(-) create mode 100644 drivers/gpu/drm/vc4/vc4_gem.c create mode 100644 drivers/gpu/drm/vc4/vc4_irq.c create mode 100644 drivers/gpu/drm/vc4/vc4_packet.h create mode 100644 drivers/gpu/drm/vc4/vc4_qpu_defines.h create mode 100644 drivers/gpu/drm/vc4/vc4_render_cl.c create mode 100644 drivers/gpu/drm/vc4/vc4_trace.h create mode 100644 drivers/gpu/drm/vc4/vc4_trace_points.c create mode 100644 drivers/gpu/drm/vc4/vc4_v3d.c create mode 100644 drivers/gpu/drm/vc4/vc4_validate.c create mode 100644 drivers/gpu/drm/vc4/vc4_validate_shaders.c create mode 100644 include/uapi/drm/vc4_drm.h [ signature.asc: application/pgp-signature ] -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151211/3a2e3e69/attachment-0001.sig>
[PATCH 12/12] ARM: dts: imx6: add Vivante GPU nodes
On Fri, Dec 04, 2015 at 03:00:04PM +0100, Lucas Stach wrote:
> This adds the device nodes for 2D, 3D and VG GPU cores.
>
> Signed-off-by: Russell King
> Signed-off-by: Lucas Stach
> ---
> arch/arm/boot/dts/imx6dl.dtsi | 5 +
> arch/arm/boot/dts/imx6q.dtsi | 15 +++
> arch/arm/boot/dts/imx6qdl.dtsi | 22 ++
> 3 files changed, 42 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
> index 4b0ec0703825..51c517a5cafd 100644
> --- a/arch/arm/boot/dts/imx6dl.dtsi
> +++ b/arch/arm/boot/dts/imx6dl.dtsi
> @@ -104,6 +104,11 @@
> compatible = "fsl,imx-display-subsystem";
> ports = <&ipu1_di0>, <&ipu1_di1>;
> };
> +
> + gpu-subsystem {
> + compatible = "fsl,imx-gpu-subsystem";
> + cores = <&gpu_2d>, <&gpu_3d>;
> + };
> };
>
> &gpt {
> diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
> index 399103b8e2c9..77d618b2870c 100644
> --- a/arch/arm/boot/dts/imx6q.dtsi
> +++ b/arch/arm/boot/dts/imx6q.dtsi
> @@ -153,6 +153,16 @@
> status = "disabled";
> };
>
> + gpu_vg: gpu at 02204000 {
> + compatible = "vivante,gc";
> + reg = <0x02204000 0x4000>;
> + interrupts = <0 11 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks IMX6QDL_CLK_OPENVG_AXI>,
> + <&clks IMX6QDL_CLK_GPU2D_CORE>;
> + clock-names = "bus", "core";
> + power-domains = <&gpc 1>;
Shouldn't property 'power-domains' be mentioned a bit in bindings doc?
> + };
> +
> ipu2: ipu at 0280 {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -225,6 +235,11 @@
> compatible = "fsl,imx-display-subsystem";
> ports = <&ipu1_di0>, <&ipu1_di1>, <&ipu2_di0>, <&ipu2_di1>;
> };
> +
> + gpu-subsystem {
> + compatible = "fsl,imx-gpu-subsystem";
> + cores = <&gpu_2d>, <&gpu_3d>, <&gpu_vg>;
> + };
> };
>
> &hdmi {
> diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
> index 2b6cc8bf3c5c..018975b867e1 100644
> --- a/arch/arm/boot/dts/imx6qdl.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl.dtsi
> @@ -119,6 +119,28 @@
> status = "disabled";
> };
>
> +
> + gpu_2d: gpu at 00134000 {
> + compatible = "vivante,gc";
> + reg = <0x00134000 0x4000>;
> + interrupts = <0 10 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks IMX6QDL_CLK_GPU2D_AXI>,
> + <&clks IMX6QDL_CLK_GPU2D_CORE>;
> + clock-names = "bus", "core";
> + power-domains = <&gpc 1>;
> + };
> +
> + gpu_3d: gpu at 0013 {
> + compatible = "vivante,gc";
> + reg = <0x0013 0x4000>;
> + interrupts = <0 9 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks IMX6QDL_CLK_GPU3D_AXI>,
> + <&clks IMX6QDL_CLK_GPU3D_CORE>,
> + <&clks IMX6QDL_CLK_GPU3D_SHADER>;
> + clock-names = "bus", "core", "shader";
> + power-domains = <&gpc 1>;
> + };
> +
Please keep these added nodes sorted in unit-address.
Shawn
> hdmi: hdmi at 012 {
> #address-cells = <1>;
> #size-cells = <0>;
> --
> 2.6.2
>
>
[PATCH v7 02/14] drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.
On 30/11/15 22:07, Philipp Zabel wrote: > From: CK Hu > > This patch adds an initial DRM driver for the Mediatek MT8173 DISP > subsystem. It currently supports two fixed output streams from the > OVL0/OVL1 sources to the DSI0/DPI0 sinks, respectively. > > Signed-off-by: CK Hu > Signed-off-by: YT Shen > Signed-off-by: Philipp Zabel > --- > Changes since v6: > - Split disp_ovl driver from mtk_drm_crtc code > - Added crtc and plane state atomic reset functions > - Toned down debug messages > - Improved error handling for hardware initialization > - Get/put smi_larb in crtc_enable/disable > - Added memory barrier before marking crtc state as ready > - Changed crtc_disable to wait for vblank > - Renamed component power_on/off to start/stop > - Made component ops optional > - Moved crtc creation from disp_ovl driver bind callback into > mtk_drm_kms_init > - Various fixes > - Added support for DRIVER_PRIME feature > - Moved DISP_OVL, DSI, DPI and component initialization into the respective > drivers > --- > drivers/gpu/drm/Kconfig | 2 + > drivers/gpu/drm/Makefile| 1 + > drivers/gpu/drm/mediatek/Kconfig| 16 + > drivers/gpu/drm/mediatek/Makefile | 11 + > drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 301 +++ > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 565 > > drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 31 ++ > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 355 + > drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 41 ++ > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 275 ++ > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 148 > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 562 > +++ > drivers/gpu/drm/mediatek/mtk_drm_drv.h | 53 +++ > drivers/gpu/drm/mediatek/mtk_drm_fb.c | 135 +++ > drivers/gpu/drm/mediatek/mtk_drm_fb.h | 28 ++ > drivers/gpu/drm/mediatek/mtk_drm_gem.c | 227 +++ > drivers/gpu/drm/mediatek/mtk_drm_gem.h | 55 +++ > drivers/gpu/drm/mediatek/mtk_drm_plane.c| 238 > drivers/gpu/drm/mediatek/mtk_drm_plane.h| 58 +++ > 19 files changed, 3102 insertions(+) > create mode 100644 drivers/gpu/drm/mediatek/Kconfig > create mode 100644 drivers/gpu/drm/mediatek/Makefile > create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_ovl.c > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_crtc.c > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_crtc.h > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_ddp.c > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_ddp.h > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_drv.c > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_drv.h > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_fb.c > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_fb.h > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_gem.c > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_gem.h > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_plane.c > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_plane.h > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index c4bf9a1..8fdb0c2 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -266,3 +266,5 @@ source "drivers/gpu/drm/amd/amdkfd/Kconfig" > source "drivers/gpu/drm/imx/Kconfig" > > source "drivers/gpu/drm/vc4/Kconfig" > + > +source "drivers/gpu/drm/mediatek/Kconfig" > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile > index 1e9ff4c..607a49f 100644 > --- a/drivers/gpu/drm/Makefile > +++ b/drivers/gpu/drm/Makefile > @@ -71,6 +71,7 @@ obj-$(CONFIG_DRM_MSM) += msm/ > obj-$(CONFIG_DRM_TEGRA) += tegra/ > obj-$(CONFIG_DRM_STI) += sti/ > obj-$(CONFIG_DRM_IMX) += imx/ > +obj-$(CONFIG_DRM_MEDIATEK) += mediatek/ > obj-y += i2c/ > obj-y += panel/ > obj-y += bridge/ > diff --git a/drivers/gpu/drm/mediatek/Kconfig > b/drivers/gpu/drm/mediatek/Kconfig > new file mode 100644 > index 000..5343cf1 > --- /dev/null > +++ b/drivers/gpu/drm/mediatek/Kconfig > @@ -0,0 +1,16 @@ > +config DRM_MEDIATEK > + tristate "DRM Support for Mediatek SoCs" > + depends on DRM > + depends on ARCH_MEDIATEK || (ARM && COMPILE_TEST) > + select MTK_SMI > + select DRM_PANEL > + select DRM_MIPI_DSI > + select DRM_PANEL_SIMPLE > + select DRM_KMS_HELPER > + select IOMMU_DMA > + help > + Choose this option if you have a Mediatek SoCs. > + The module will be called mediatek-drm > + This driver provides kernel mode setting and > + buffer management to userspace. > + > diff --git a/drivers/gpu/drm/mediatek/Make
