[RFC] drm: Start documenting userspace ABI
On Wednesday 19 November 2014 14:23:47 Daniel Vetter wrote: > On Tue, Nov 18, 2014 at 04:24:39PM +0100, Thierry Reding wrote: > > On Tue, Nov 18, 2014 at 04:05:08PM +0100, David Herrmann wrote: > > > On Tue, Nov 18, 2014 at 3:43 PM, Thierry Reding wrote: > > > > On Tue, Nov 18, 2014 at 03:27:27PM +0100, Daniel Vetter wrote: > > > >> On Tue, Nov 18, 2014 at 03:19:33PM +0100, Thierry Reding wrote: > > > >> > From: Thierry Reding > > > >> > > > > >> > After seeing how the DRM_IOCTL_MODE_CREATE_DUMB was implemented > > > >> > with different semantics on different drivers it seems like a good > > > >> > idea to start to more rigorously document userspace ABI to avoid > > > >> > these things in the future. > > > >> > > > > >> > This is a first draft of what such documentation could look like. > > > >> > Not all IOCTLs are documented and some explanation about the other > > > >> > system calls (mmap(), poll(), read(), ...) would be good too. But I > > > >> > wanted to send this out for early review to see if the direction is > > > >> > reasonable. If so my plan is to continue to chip away at this as I > > > >> > find time. > > > >> > > > > >> > Signed-off-by: Thierry Reding > > > >> > > > >> Imo for ioctls the right thing to do is having proper manpages, not > > > >> kerneldoc or DocBook sections. manpages really lend themselves well > > > >> to specify all the different facets of a single interface. > > > > > > > > I don't think I've ever seen manpages document IOCTLs at this level of > > > > detail. The intention of this is to add documentation about the IOCTLs > > > > at the kernel/userspace transition. Keeping this in the kernel has the > > > > advantage that it's a whole lot easier to keep updated, much like what > > > > we do with the other kerneldoc. > > > > > > > > That doesn't mean we shouldn't have manpages, but I think both are for > > > > the most part orthogonal, even though they may describe various facets > > > > of the same interfaces. > > > > > > tty_ioctl(4) > > > console_ioctl(4) > > > > > > I think a similar man-page ala drm_ioctl(4) makes a lot of sense. The DRM API is much more complex, I think it deserves one page per ioctl. > > > >> Also, we already have some skeleton of that in libdrm, so I think > > > >> extending that would be best. > > > > > > > > One other reason why I don't think libdrm is the best fit for this is > > > > that libdrm is just one userspace implementation abstracting away the > > > > interfaces that this describes. Not everyone will use libdrm. So in my > > > > opinion its great if libdrm documents the API that it exposes, but I > > > > don't think it should document the kernel interfaces that it uses. The > > > > kernel exposes them, so it should provide the documentation for it as > > > > well. > > > > > > I don't mind documenting this in the kernel-doc. But if we start > > > something like drm_ioctl(4) (I pushed some more generic man-pages to > > > libdrm a few years ago), we have this documented in 2 places, which is > > > always annoying for updates. > > > > I wonder if it would somehow be possible to generate manpages from the > > DocBook to avoid this duplication. I'm pretty sure that should be possible. DocBook has appropriate markup to document functions in a manpage-like manner, see http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-reqbufs.html for instance. > > One of the things that DRM_IOCTL_MODE_CREATE_DUMB showed is that both > > drivers and userspace can interpret things wrongly, and I fear that if all > > we have is a manpage to document the IOCTLs, people writing the drivers > > may not be tempted enough to read that manpage. So I think we want > > documentation for both driver and userspace developers. > > Imo docs don't help with that kind of fumble, only nasty testcases will. > People only read docs when they don't understand stuff (i.e. trying to > write drivers). Imo manpages an ioctl docs are only really good for > designing the interface (since it forces you to really think through the > semantics to be able to describe them concisely and precisely). But even > there I think having solid testcases is better invested time. > > Documentation for developers is imo an entirely different matter, I think > that gets used a lot more. Or at least I find them fairly useful. I think both are useful. From my personal experience proper detailed ioctl documentation helps a lots when writing kernel drivers. Even in the case of the DRM subsystem where various helper functions push the driver away from the ioctl API, proper documentation of the structures passed by userspace is very helpful for driver developers. Not to mention of course that the documentation helps getting the helpers right. Test cases are also invaluable. I've seen both test cases being used to fix drivers and documentation, clarifying the API as they get developed. Implementing a test case is a very good way to test the maturity of an API. > > Documenting this
[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux
https://bugs.freedesktop.org/show_bug.cgi?id=73530 --- Comment #73 from Alex Deucher --- (In reply to Benjamin from comment #72) > I'm having the same issue, but it seems to be getting worse with newer > kernels. I was able to do the suspend/resume trick to get a working screen, > but this seems to have stopped working with kernel 3.16 and 3.17. No amount > of suspending/resuming seems to get the screen to appear now, so I've had to > stick with 3.15 for the time being. I'm on Arch, so packages are fairly > generic, but I can provide any information that would help. Can you bisect and see what commit made it worse? That might help narrow down 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/20141201/1f272640/attachment.html>
[Bug 85421] radeon stalled, GPU lockup, reset and failed on resume; crashed by firefox.
https://bugzilla.kernel.org/show_bug.cgi?id=85421 --- Comment #14 from Alex Deucher --- Please make sure your version of mesa has this patch: http://cgit.freedesktop.org/mesa/mesa/commit/?id=ae4536b4f71cbe76230ea7edc7eb4d6041e651b4 -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 86861] [rv6xx] When using a hardware KVM switch between computers EDID sometimes not detected/display goes fuzzy
https://bugs.freedesktop.org/show_bug.cgi?id=86861 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTOURBUG --- Comment #3 from Alex Deucher --- (In reply to Shawn Starr from comment #2) > The newer firmware updates don't address VGA EDID detection, at least the > documentation doesn't list this. > > One thought though, we don't cache the EDID information if it was previously > detected? If you switch the screen, does that effectively mean the cable is > disconnected on the other computer? For analog displays like VGA, the drm core polls every 10 seconds or so to see if the monitor is still there since the older analog connctors like VGA do not support hotplug like digital connectors like DVI or HDMI do. -- 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/20141201/60f53858/attachment.html>
[Bug 86864] [rv6xx] RADEON_FLAG_GTT_WC causes GPU to reset when playing Second Life / other games
https://bugs.freedesktop.org/show_bug.cgi?id=86864 --- Comment #6 from Michel Dänzer --- So current Mesa Git master is still affected by this problem, and reverting commit 7b4276d7acf2e0f77044cb50caa6ad936fa78786 on top of that works around it? Does setting the environment variable RADEON_THREAD=0 work around the problem? If not, please attach gdb to the Second Life process to make sure the environment variable takes effect, i.e. there's no CS helper thread spawned by the r600g driver. -- 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/20141201/1c23a703/attachment-0001.html>
[Bug 86864] [rv6xx] RADEON_FLAG_GTT_WC causes GPU to reset when playing Second Life / other games
https://bugs.freedesktop.org/show_bug.cgi?id=86864 --- Comment #7 from Shawn Starr --- Reverting patch does stop the lockup. I will test RADEON_THREAD=0 and confirm w/ gdb running the game. -- 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/20141201/bef79540/attachment.html>
[Intel-gfx] [RFC PATCH v3 1/4] drm/i915: add i915_ved.c to setup bridge for VED
> -Original Message- > From: Beckett, Robert > Sent: Saturday, November 29, 2014 0:59 > To: Cheng, Yao; intel-gfx at lists.freedesktop.org; dri- > devel at lists.freedesktop.org; daniel.vetter at ffwll.ch; Kelley, Sean V; > Chehab, > John > Cc: emil.l.velikov at gmail.com; Jiang, Fei; dh.herrmann at gmail.com; > daniel at fooishbar.org > Subject: Re: [Intel-gfx] [RFC PATCH v3 1/4] drm/i915: add i915_ved.c to setup > bridge for VED > > + * Threats: > > + * Due to the restriction in Linux platform device model, user need > > +manually > > + * uninstall ipvr driver before uninstalling i915 module, otherwise > > +he might > > + * run into use-after-free issues after i915 removes the platform device. > > Can you go in to more detail on what you consider to be the restriction in the > platform device model? > > When removing the device via platform_device_unregister, it will call the > remove callback of any drivers handling this device (via the bus remove > function). It is then up to the driver to ensure no further usage of the > device > from which it is being removed. This usually involves removing all user input > vectors, disabling interrupts involved and flushing/canceling any delayed > work. This should prevent any further use of the device by the driver. > > The driver's remove function is called in a direct call chain from > platform_device_unregister, so by the time it returns, there should be no > further chance of accesses. > Bob, thx for your review comments. The symptom is, after "rmmod i915", though drm_drv_release() is also called on the child device "ipvr", I still see the module exist in the system (check it by "lsmod"). This causes issue when I modprobe i915 and ipvr again later. Actually I don't understand why this restriction exists, but accroding to Daniel, grabbing a module refcount for the platform device doesn't work (it would pin the module forever). > > +void vlv_teardown_ved(struct drm_device *dev) { > > + struct drm_i915_private *dev_priv = dev->dev_private; > > you may want to mask the i915 interrupt for the VED block before removing > the device. > Thx, will add it. > > + vlv_ved_platdev_destroy(dev); > > + if (dev_priv->ved.irq >= 0) > > + irq_free_desc(dev_priv->ved.irq); > > +} > > > > > Generally it is a nicely interfaced child device. >
[RFC PATCH v3 4/4] tests/drv_module_reload: add ipvr support
> -Original Message- > From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel > Vetter > Sent: Monday, November 24, 2014 21:15 > To: Thierry Reding > Cc: Daniel Vetter; Cheng, Yao; intel-gfx at lists.freedesktop.org; dri- > devel at lists.freedesktop.org; daniel.vetter at ffwll.ch; Kelley, Sean V; > Chehab, > John; emil.l.velikov at gmail.com; Jiang, Fei > Subject: Re: [RFC PATCH v3 4/4] tests/drv_module_reload: add ipvr support > > On Mon, Nov 24, 2014 at 10:55:46AM +0100, Thierry Reding wrote: > > On Fri, Nov 21, 2014 at 09:36:33PM +0100, Daniel Vetter wrote: > > > On Fri, Nov 21, 2014 at 09:27:04PM +0100, Thierry Reding wrote: > > > > On Sat, Nov 22, 2014 at 03:10:01AM +0800, Yao Cheng wrote: > > > > > on vlv, if ipvr is installed, it need be manually unloaded > > > > > before i915, otherwise user might run into use-after-free issue. > > > > > > > > Huh? That doesn't sound right. What exactly is it that's going wrong? > > > > You should never have to do this. If you do you're almost > > > > certainly doing something wrong in the kernel module. > > > > > > It's the hilarity called platform devices. Removing them is somewhat > > > racy, so doing that upfront makes the entire thing a bit safer. The > > > use after free is on the text, since grabbing a module refcount for > > > the platform device doesn't work (it would pin the module forever). > > > > I don't understand what the issue is here. I've used platform devices > > quite extensively on ARM and I've never encountered a situation where > > they were insufficient (or racy for that matter). > > > > If I understand correctly what this commit tries to achieve, then it > > unloads one module before another module that it depends on so that > > the dependency can be removed subsequently without causing a crash. > > That sounds really brittle to me. How are you going to document this > > for users so that they don't accidentally go and unload the i915 > > module and crash their system? > > Module unloading taints your kernel and isn't an end-user supported feature. > That simple ;-) > > Also afaik the problem is that you actually can't unload i915 until you've > unloaded the subordinate driver, since i915 registering the platform driver > prevents unload. Or at least that was my understanding, I didn't test this > myself. I just asked whether the unload script still works and apparently it > breaks. > > I guess what's different with ARM is that DT creates all the platform devices, > and not modules themselves? > -Daniel Thierry/Daniel, the actual symptom is, after "rmmod i915", though drm_drv_release() is also called on the child device "ipvr", I still see the module exist in the system (check it by "lsmod"). This causes issue when I modprobe i915 and ipvr again later. I don't understand why this happens but I believe what Daniel said: "grabbing a module refcount for the platform device doesn't work (it would pin the module forever)". > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst
https://bugs.freedesktop.org/show_bug.cgi?id=73338 --- Comment #57 from Alex Deucher --- You're right about the masks. Fixed in my 3.19-wip branch: http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.19-wip -- 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/20141201/f256e096/attachment.html>
[Bug 85421] radeon stalled, GPU lockup, reset and failed on resume; crashed by firefox.
https://bugzilla.kernel.org/show_bug.cgi?id=85421 --- Comment #15 from Hin-Tak Leung --- FWIW, so far my best experience seems to be 10.2.9 which I haven't had a lockup yet (had two(?) lockup's with 10.2.8 and once within a few hours after upgrading to 10.3.3.). So far I spent about 6 weeks under 10.2.8, and 3 weeks with 10.2.9. -- You are receiving this mail because: You are watching the assignee of the bug.
[RFC PATCH v3 2/4] drm/ipvr: drm driver for VED
Add Jon/Bob/Raf for detail review. > -Original Message- > From: dri-devel [mailto:dri-devel-bounces at lists.freedesktop.org] On Behalf > Of Cheng, Yao > Sent: Thursday, November 27, 2014 19:49 > To: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org; > daniel.vetter at ffwll.ch; Kelley, Sean V; Chehab, John > Cc: emil.l.velikov at gmail.com; Jiang, Fei > Subject: RE: [RFC PATCH v3 2/4] drm/ipvr: drm driver for VED > > > -Original Message- > > From: Cheng, Yao > > Sent: Saturday, November 22, 2014 3:07 > > To: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org; > > daniel.vetter at ffwll.ch; Kelley, Sean V; Chehab, John > > Cc: Jiang, Fei; dh.herrmann at gmail.com; jani.nikula at linux.intel.com; > > emil.l.velikov at gmail.com; ville.syrjala at linux.intel.com; > > jbarnes at virtuousgeek.org; daniel at fooishbar.org; Cheng, Yao > > Subject: [RFC PATCH v3 2/4] drm/ipvr: drm driver for VED > > +typedef struct drm_ipvr_private { > > + struct drm_device *dev; > > + struct pci_dev *pci_root; > > + > > + /* IMG video context */ > > + struct list_head ipvr_ctx_list; > > The current design leads to ctx leak. There's no ctx_list for each file > struct, so > each create_context_ioctl causes one ctx leak. > Need to move the ctx_list from dev_private to file_private. > > > + spinlock_t ipvr_ctx_lock; > > + struct idr ipvr_ctx_idr; > > + struct ipvr_context default_ctx; > > + > > + /* PM related */ > > + atomic_t pending_events; > > + > > + /* exec related */ > > + struct ipvr_validate_context validate_ctx; > > + > > + /* IMG MMU specific */ > > + struct ipvr_mmu_driver *mmu; > > + /*struct ipvr_mmu_pd *pf_pd;*/ > > + atomic_t ipvr_mmu_invaldc; > > + > > + /* GEM mm related */ > > + struct ipvr_gem_stat ipvr_stat; > > + struct kmem_cache *ipvr_bo_slab; > > + struct ipvr_address_space addr_space; > > + > > + /* fence related */ > > + u32 last_seq; > > + wait_queue_head_t fence_queue; > > + struct ipvr_fence_driver fence_drv; > > + > > + /* MMIO window shared from parent device */ > > + u8 __iomem* reg_base; > > + > > + /* > > +* VED specific > > +*/ > > + struct ved_private *ved_private; > > +}drm_ipvr_private_t; > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH v3 3/4] ipvr: user mode helper for ipvr drm driver
Add Jon/Bob/Raf for detail review. > -Original Message- > From: Cheng, Yao > Sent: Saturday, November 22, 2014 3:09 > To: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org; > daniel.vetter at ffwll.ch; Kelley, Sean V; Chehab, John > Cc: Jiang, Fei; dh.herrmann at gmail.com; jani.nikula at linux.intel.com; > emil.l.velikov at gmail.com; ville.syrjala at linux.intel.com; > jbarnes at virtuousgeek.org; daniel at fooishbar.org; Cheng, Yao > Subject: [RFC PATCH v3 3/4] ipvr: user mode helper for ipvr drm driver > > add usermode helper for the ipvr kernel driver. > test_ioctl: test kernel driver by directly ioctl > > v2: > take Emil's comments > - correctly align ipvr_drm.h > > v3: > take Daniel Vetter and Daniel Stone's comments, and implement PRIME > - correctly align ipvr_drm.h > - use __u32 family in ipvr_drm.h > - rip out explicit fence from libdrm_ipvr > - implemented PRIME support > - add relocation fixup implementation > > Signed-off-by: Yao Cheng > --- > Makefile.am|6 +- > Makefile.sources |1 + > configure.ac | 26 +- > include/drm/ipvr_drm.h | 278 +++ > ipvr/Makefile.am | 57 +++ > ipvr/Makefile.sources |5 + > ipvr/ipvr_bufmgr.h | 149 ++ > ipvr/ipvr_bufmgr_gem.c | 1200 > > ipvr/libdrm_ipvr.pc.in | 11 + > ipvr/test_ioctl.c | 423 + > 10 files changed, 2154 insertions(+), 2 deletions(-) > create mode 100644 include/drm/ipvr_drm.h > create mode 100644 ipvr/Makefile.am > create mode 100644 ipvr/Makefile.sources > create mode 100644 ipvr/ipvr_bufmgr.h > create mode 100644 ipvr/ipvr_bufmgr_gem.c > create mode 100644 ipvr/libdrm_ipvr.pc.in > create mode 100644 ipvr/test_ioctl.c > > diff --git a/Makefile.am b/Makefile.am > index 3952a88..2227add 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -33,6 +33,10 @@ if HAVE_INTEL > INTEL_SUBDIR = intel > endif > > +if HAVE_IPVR > +IPVR_SUBDIR = ipvr > +endif > + > if HAVE_NOUVEAU > NOUVEAU_SUBDIR = nouveau > endif > @@ -53,7 +57,7 @@ if HAVE_FREEDRENO > FREEDRENO_SUBDIR = freedreno > endif > > -SUBDIRS = . $(LIBKMS_SUBDIR) $(INTEL_SUBDIR) $(NOUVEAU_SUBDIR) > $(RADEON_SUBDIR) $(OMAP_SUBDIR) $(EXYNOS_SUBDIR) > $(FREEDRENO_SUBDIR) tests man > +SUBDIRS = . $(LIBKMS_SUBDIR) $(INTEL_SUBDIR) $(IPVR_SUBDIR) > $(NOUVEAU_SUBDIR) $(RADEON_SUBDIR) $(OMAP_SUBDIR) > $(EXYNOS_SUBDIR) $(FREEDRENO_SUBDIR) tests man > > libdrm_la_LTLIBRARIES = libdrm.la > libdrm_ladir = $(libdir) > diff --git a/Makefile.sources b/Makefile.sources > index d86fb2a..96f8c60 100644 > --- a/Makefile.sources > +++ b/Makefile.sources > @@ -18,6 +18,7 @@ LIBDRM_INCLUDE_H_FILES := \ > include/drm/drm_mode.h \ > include/drm/drm_sarea.h \ > include/drm/i915_drm.h \ > + include/drm/ipvr_drm.h \ > include/drm/mach64_drm.h \ > include/drm/mga_drm.h \ > include/drm/nouveau_drm.h \ > diff --git a/configure.ac b/configure.ac > index ee59b03..6dcf1b2 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -68,6 +68,11 @@ AC_ARG_ENABLE(intel, > [Enable support for intel's KMS API (default: auto)]), > [INTEL=$enableval], [INTEL=auto]) > > +AC_ARG_ENABLE(ipvr, > + AS_HELP_STRING([--disable-ipvr], > + [Enable support for baytrail's hardware VP8 decode (default: > auto)]), > + [IPVR=$enableval], [IPVR=auto]) > + > AC_ARG_ENABLE(radeon, > AS_HELP_STRING([--disable-radeon], > [Enable support for radeon's KMS API (default: auto)]), > @@ -204,7 +209,7 @@ if test "x$drm_cv_atomic_primitives" = "xlibatomic- > ops"; then > AC_DEFINE(HAVE_LIB_ATOMIC_OPS, 1, [Enable if you have > libatomic-ops-dev installed]) > fi > > -if test "x$INTEL" != "xno" -o "x$RADEON" != "xno" -o "x$NOUVEAU" != > "xno"; then > +if test "x$INTEL" != "xno" -o "x$IPVR" != "xno" -o "x$RADEON" != "xno" -o > "x$NOUVEAU" != "xno"; then > if test "x$drm_cv_atomic_primitives" = "xnone"; then > if test "x$INTEL" != "xauto"; then > if test "x$INTEL" != "xno"; then > @@ -214,6 +219,14 @@ if test "x$INTEL" != "xno" -o "x$RADEON" != "xno" -o > "x$NOUVEAU" != "xno"; then > AC_MSG_WARN([Disabling libdrm_intel. It depends > on atomic operations, which were not found for your compiler/cpu. Try > compiling with -march=native, or install the libatomics-op-dev package.]) > INTEL=no > fi > + if test "x$IPVR" != "xauto"; then > + if test "x$IPVR" != "xno"; then > + AC_MSG_ERROR([libdrm_ipvr depends upon > atomic operations, which were not found for your compiler/cpu. Try > compiling with -march=native, or install the libatomics-op-dev package, or, > failing both of those, disable support for Baytrail VP8 by passing > --disable-ipvr > to ./configure]) > +
[PATCH] drm/radeon: Hide cursor on CRTCs used by fbdev
On 28.11.2014 22:38, Daniel Vetter wrote: > On Fri, Nov 28, 2014 at 11:48:48AM +0900, Michel Dänzer wrote: >> From: Michel Dänzer >> >> Since we are now preserving the cursor across modesets, the cursor could >> be left over in console if e.g. X crashed. > > I'd add a fixme for this since if you implement universal plane support > fbdev will automatically disable all non-primary planes (and so the > cursor). Thanks Daniel for the suggestion, and Alex for merging the patch. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
[Bug 86864] [rv6xx] RADEON_FLAG_GTT_WC causes GPU to reset when playing Second Life / other games
https://bugs.freedesktop.org/show_bug.cgi?id=86864 --- Comment #8 from Shawn Starr --- With the environment variable set prior to X (in .bashrc). Running game with gdb still locks up GPU. No crash in game reported (break within gdb): here is threads: (gdb) info threads Id Target Id Frame 14 Thread 0x7fffe0602700 (LWP 1625) "do-not-directly" 0x0037a5cc491d in nanosleep () from /lib64/libc.so.6 13 Thread 0x7000f700 (LWP 1624) "do-not-directly" 0x0037a640c578 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 12 Thread 0x7fffe0e03700 (LWP 1623) "threaded-ml" 0x0037a5cf51dd in poll () from /lib64/libc.so.6 11 Thread 0x7fffc23a4700 (LWP 1621) "gdbus" 0x0037a5cf51dd in poll () from /lib64/libc.so.6 10 Thread 0x7fffc2ba5700 (LWP 1620) "do-not-directly" 0x0037a5d00d83 in epoll_wait () from /lib64/libc.so.6 9Thread 0x7fffe27fc700 (LWP 1615) "do-not-directly" 0x0037a640c590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 8Thread 0x7fffe2ffd700 (LWP 1614) "do-not-directly" 0x0037a640c590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 7Thread 0x7fffe37fe700 (LWP 1613) "do-not-directly" 0x0037a640c590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 6Thread 0x7fffe3fff700 (LWP 1612) "do-not-directly" 0x0037a640c590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 5Thread 0x70b46700 (LWP 1611) "do-not-directly" 0x0037a640c590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 4Thread 0x71347700 (LWP 1610) "do-not-directly" 0x0037a640f8fd in nanosleep () from /lib64/libpthread.so.0 3Thread 0x71b48700 (LWP 1609) "do-not-directly" 0x0037a640c590 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 2Thread 0x72403700 (LWP 1583) "do-not-directly" 0x0037a640f8fd in nanosleep () from /lib64/libpthread.so.0 * 1Thread 0x7270aa00 (LWP 1579) "do-not-directly" 0x0037a640f8fd in nanosleep () from /lib64/libpthread.so.0 -- 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/20141201/a92bc6e5/attachment-0001.html>
[Bug 86011] [drm] "Memory manager not clean during takedown" after vga-switcheroo turn off nvidia card
https://bugzilla.kernel.org/show_bug.cgi?id=86011 --- Comment #5 from JoaquÃn AramendÃa --- Created attachment 159291 --> https://bugzilla.kernel.org/attachment.cgi?id=159291&action=edit fix for runtime power management in nouveau I made this patch that fixed the issue for me. Applies on top of commit a4c5f39. Should apply with offset to newer kernels but fine. -- You are receiving this mail because: You are watching someone on the CC list of the bug.
[Bug 86864] [rv6xx] RADEON_FLAG_GTT_WC causes GPU to reset when playing Second Life / other games
https://bugs.freedesktop.org/show_bug.cgi?id=86864 --- Comment #9 from Michel Dänzer --- Unfortunately, the r600g helper thread doesn't set a distinctive thread name. Please attach (as opposed to paste) the output of 'thread apply all bt' in gdb when setting RADEON_THREAD=0. -- 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/20141201/329c8ff1/attachment.html>
[Bug 86832] [dota2][si] freezes up to 3 seconds when many/big display effects happen
https://bugs.freedesktop.org/show_bug.cgi?id=86832 --- Comment #3 from Michel Dänzer --- What version of Mesa are you using? -- 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/20141201/a2496892/attachment.html>
[Bug 86864] [rv6xx] RADEON_FLAG_GTT_WC causes GPU to reset when playing Second Life / other games
https://bugs.freedesktop.org/show_bug.cgi?id=86864 --- Comment #10 from Shawn Starr --- Created attachment 110280 --> https://bugs.freedesktop.org/attachment.cgi?id=110280&action=edit Running threads listed -- 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/20141201/1c07ba83/attachment-0001.html>
[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst
https://bugs.freedesktop.org/show_bug.cgi?id=73338 --- Comment #58 from Chernovsky Oleg --- Another observation: I've uncommented ci_fan_ctrl_set_fan_speed_percent and tried to bind it to hwmon interface. So, if I try to set static value to the fan, then I see 0x50CB1435 in CG_FDO_CTRL2 and the fan runs 100% percent always, regardless of values I'm echoing But if I push 0x50CB0C00 to the CG_FDO_CTRL2 instead of trusting ci_fan_ctrl_set_static_mode, it begins to react on values I echoed. Can you elaborate on what each bit of this control register means? Maybe I just can't into abbreviations :) -- 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/20141201/2aa5b68f/attachment.html>
[PATCH v4 2/3] drm: panel: simple-panel: add support for bus_format retrieval
Provide a way to specify panel requirement in terms of supported media bus format (particularly useful for panels connected to an RGB or LVDS bus). Signed-off-by: Boris Brezillon --- drivers/gpu/drm/panel/panel-simple.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 23de22f..66838a5 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -61,6 +61,8 @@ struct panel_desc { unsigned int disable; unsigned int unprepare; } delay; + + u32 bus_format; }; struct panel_simple { @@ -111,6 +113,9 @@ static int panel_simple_get_fixed_modes(struct panel_simple *panel) connector->display_info.bpc = panel->desc->bpc; connector->display_info.width_mm = panel->desc->size.width; connector->display_info.height_mm = panel->desc->size.height; + if (panel->desc->bus_format) + drm_display_info_set_bus_formats(&connector->display_info, +&panel->desc->bus_format, 1); return num; } -- 1.9.1
[PATCH v4 3/3] drm: panel: simple-panel: add bus format information for foxlink panel
Foxlink's fl500wvr00-a0t supports RGB888 format. Signed-off-by: Boris Brezillon --- drivers/gpu/drm/panel/panel-simple.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 66838a5..695f406 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -545,6 +545,7 @@ static const struct panel_desc foxlink_fl500wvr00_a0t = { .width = 108, .height = 65, }, + .bus_format = MEDIA_BUS_FMT_RGB888_1X24, }; static const struct drm_display_mode innolux_n116bge_mode = { -- 1.9.1
[PATCH v4 1/3] drm: add bus_formats and num_bus_formats fields to drm_display_info
Add bus_formats and num_bus_formats fields and drm_display_info_set_bus_formats helper function to specify the bus formats supported by a given display. This information can be used by display controller drivers to configure the output interface appropriately (i.e. RGB565, RGB666 or RGB888 on raw RGB or LVDS busses). Signed-off-by: Boris Brezillon --- drivers/gpu/drm/drm_crtc.c | 32 include/drm/drm_crtc.h | 7 +++ 2 files changed, 39 insertions(+) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index e79c8d3..d3b7ed0 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -763,6 +763,38 @@ static void drm_mode_remove(struct drm_connector *connector, drm_mode_destroy(connector->dev, mode); } +/* + * drm_display_info_set_bus_formats - set the supported bus formats + * @info: display info to store bus formats in + * @fmts: array containing the supported bus formats + * @nfmts: the number of entries in the fmts array + * + * Store the suppported bus formats in display info structure. + * See MEDIA_BUS_FMT_* definitions in include/uapi/linux/media-bus-format.h for + * a full list of available formats. + */ +int drm_display_info_set_bus_formats(struct drm_display_info *info, const u32 *fmts, +unsigned int num_fmts) +{ + u32 *formats = NULL; + + if (!fmts && num_fmts) + return -EINVAL; + + if (fmts && num_fmts) { + formats = kmemdup(fmts, sizeof(*fmts) * num_fmts, GFP_KERNEL); + if (!formats) + return -ENOMEM; + } + + kfree(info->bus_formats); + info->bus_formats = formats; + info->num_bus_formats = num_fmts; + + return 0; +} +EXPORT_SYMBOL(drm_display_info_set_bus_formats); + /** * drm_connector_get_cmdline_mode - reads the user's cmdline mode * @connector: connector to quwery diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index c40070a..a35844f 100644 --- a/include/drm/drm_crtc.h +++ b/include/drm/drm_crtc.h @@ -31,6 +31,7 @@ #include #include #include +#include #include #include #include @@ -130,6 +131,9 @@ struct drm_display_info { enum subpixel_order subpixel_order; u32 color_formats; + const u32 *bus_formats; + unsigned int num_bus_formats; + /* Mask of supported hdmi deep color modes */ u8 edid_hdmi_dc_modes; @@ -982,6 +986,9 @@ extern int drm_mode_connector_set_path_property(struct drm_connector *connector, extern int drm_mode_connector_update_edid_property(struct drm_connector *connector, struct edid *edid); +extern int drm_display_info_set_bus_formats(struct drm_display_info *info, + const u32 *fmts, unsigned int nfmts); + static inline bool drm_property_type_is(struct drm_property *property, uint32_t type) { -- 1.9.1
[PATCH v4 0/3] drm: describe display bus format
Hello, This series makes use of the MEDIA_BUS_FMT definition to describe how the data are transmitted to the display. This will allow drivers to configure their output display bus according to the display capabilities. For example some display controllers support DPI (or raw RGB) connectors and need to specify which format will be transmitted on the DPI bus (RGB444, RGB565, RGB888, ...). This series also adds a field to the panel_desc struct so that one can specify which format is natevely supported by a panel. Regards, Boris Changes since v3: - store num_bus_formats on an unsigned int - clearly state that fmts argument (in drm_display_info_set_bus_formats function) should be an array of MEDIA_BUS_FMT_* values. Changes since v2: - use the MEDIA_BUS_FMT macros Changes since v1: - rename nformats into num_formats - declare num_formats as an unsigned int Boris Brezillon (3): drm: add bus_formats and num_bus_formats fields to drm_display_info drm: panel: simple-panel: add support for bus_format retrieval drm: panel: simple-panel: add bus format information for foxlink panel drivers/gpu/drm/drm_crtc.c | 32 drivers/gpu/drm/panel/panel-simple.c | 6 ++ include/drm/drm_crtc.h | 7 +++ 3 files changed, 45 insertions(+) -- 1.9.1
[PATCH v4 1/3] drm: add bus_formats and num_bus_formats fields to drm_display_info
Add bus_formats and num_bus_formats fields and drm_display_info_set_bus_formats helper function to specify the bus formats supported by a given display. This information can be used by display controller drivers to configure the output interface appropriately (i.e. RGB565, RGB666 or RGB888 on raw RGB or LVDS busses). Signed-off-by: Boris Brezillon --- drivers/gpu/drm/drm_crtc.c | 32 include/drm/drm_crtc.h | 7 +++ 2 files changed, 39 insertions(+) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index e79c8d3..d3b7ed0 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -763,6 +763,38 @@ static void drm_mode_remove(struct drm_connector *connector, drm_mode_destroy(connector->dev, mode); } +/* + * drm_display_info_set_bus_formats - set the supported bus formats + * @info: display info to store bus formats in + * @fmts: array containing the supported bus formats + * @nfmts: the number of entries in the fmts array + * + * Store the suppported bus formats in display info structure. + * See MEDIA_BUS_FMT_* definitions in include/uapi/linux/media-bus-format.h for + * a full list of available formats. + */ +int drm_display_info_set_bus_formats(struct drm_display_info *info, const u32 *fmts, +unsigned int num_fmts) +{ + u32 *formats = NULL; + + if (!fmts && num_fmts) + return -EINVAL; + + if (fmts && num_fmts) { + formats = kmemdup(fmts, sizeof(*fmts) * num_fmts, GFP_KERNEL); + if (!formats) + return -ENOMEM; + } + + kfree(info->bus_formats); + info->bus_formats = formats; + info->num_bus_formats = num_fmts; + + return 0; +} +EXPORT_SYMBOL(drm_display_info_set_bus_formats); + /** * drm_connector_get_cmdline_mode - reads the user's cmdline mode * @connector: connector to quwery diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index c40070a..a35844f 100644 --- a/include/drm/drm_crtc.h +++ b/include/drm/drm_crtc.h @@ -31,6 +31,7 @@ #include #include #include +#include #include #include #include @@ -130,6 +131,9 @@ struct drm_display_info { enum subpixel_order subpixel_order; u32 color_formats; + const u32 *bus_formats; + unsigned int num_bus_formats; + /* Mask of supported hdmi deep color modes */ u8 edid_hdmi_dc_modes; @@ -982,6 +986,9 @@ extern int drm_mode_connector_set_path_property(struct drm_connector *connector, extern int drm_mode_connector_update_edid_property(struct drm_connector *connector, struct edid *edid); +extern int drm_display_info_set_bus_formats(struct drm_display_info *info, + const u32 *fmts, unsigned int nfmts); + static inline bool drm_property_type_is(struct drm_property *property, uint32_t type) { -- 1.9.1
[PATCH v4 3/3] drm: panel: simple-panel: add bus format information for foxlink panel
Foxlink's fl500wvr00-a0t supports RGB888 format. Signed-off-by: Boris Brezillon --- drivers/gpu/drm/panel/panel-simple.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 66838a5..695f406 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -545,6 +545,7 @@ static const struct panel_desc foxlink_fl500wvr00_a0t = { .width = 108, .height = 65, }, + .bus_format = MEDIA_BUS_FMT_RGB888_1X24, }; static const struct drm_display_mode innolux_n116bge_mode = { -- 1.9.1
[PATCH v4 0/3] drm: describe display bus format
Hello, This series makes use of the MEDIA_BUS_FMT definition to describe how the data are transmitted to the display. This will allow drivers to configure their output display bus according to the display capabilities. For example some display controllers support DPI (or raw RGB) connectors and need to specify which format will be transmitted on the DPI bus (RGB444, RGB565, RGB888, ...). This series also adds a field to the panel_desc struct so that one can specify which format is natevely supported by a panel. Regards, Boris Changes since v3: - store num_bus_formats on an unsigned int - clearly state that fmts argument (in drm_display_info_set_bus_formats function) should be an array of MEDIA_BUS_FMT_* values. Changes since v2: - use the MEDIA_BUS_FMT macros Changes since v1: - rename nformats into num_formats - declare num_formats as an unsigned int Boris Brezillon (3): drm: add bus_formats and num_bus_formats fields to drm_display_info drm: panel: simple-panel: add support for bus_format retrieval drm: panel: simple-panel: add bus format information for foxlink panel drivers/gpu/drm/drm_crtc.c | 32 drivers/gpu/drm/panel/panel-simple.c | 6 ++ include/drm/drm_crtc.h | 7 +++ 3 files changed, 45 insertions(+) -- 1.9.1
[PATCH v4 2/3] drm: panel: simple-panel: add support for bus_format retrieval
Provide a way to specify panel requirement in terms of supported media bus format (particularly useful for panels connected to an RGB or LVDS bus). Signed-off-by: Boris Brezillon --- drivers/gpu/drm/panel/panel-simple.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 23de22f..66838a5 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -61,6 +61,8 @@ struct panel_desc { unsigned int disable; unsigned int unprepare; } delay; + + u32 bus_format; }; struct panel_simple { @@ -111,6 +113,9 @@ static int panel_simple_get_fixed_modes(struct panel_simple *panel) connector->display_info.bpc = panel->desc->bpc; connector->display_info.width_mm = panel->desc->size.width; connector->display_info.height_mm = panel->desc->size.height; + if (panel->desc->bus_format) + drm_display_info_set_bus_formats(&connector->display_info, +&panel->desc->bus_format, 1); return num; } -- 1.9.1
[Intel-gfx] [RFC PATCH v3 1/4] drm/i915: add i915_ved.c to setup bridge for VED
On Mon, Dec 01, 2014 at 03:04:27AM +, Cheng, Yao wrote: > > -Original Message- > > From: Beckett, Robert > > Sent: Saturday, November 29, 2014 0:59 > > To: Cheng, Yao; intel-gfx at lists.freedesktop.org; dri- > > devel at lists.freedesktop.org; daniel.vetter at ffwll.ch; Kelley, Sean V; > > Chehab, > > John > > Cc: emil.l.velikov at gmail.com; Jiang, Fei; dh.herrmann at gmail.com; > > daniel at fooishbar.org > > Subject: Re: [Intel-gfx] [RFC PATCH v3 1/4] drm/i915: add i915_ved.c to > > setup > > bridge for VED > > > + * Threats: > > > + * Due to the restriction in Linux platform device model, user need > > > +manually > > > + * uninstall ipvr driver before uninstalling i915 module, otherwise > > > +he might > > > + * run into use-after-free issues after i915 removes the platform device. > > > > Can you go in to more detail on what you consider to be the restriction in > > the > > platform device model? > > > > When removing the device via platform_device_unregister, it will call the > > remove callback of any drivers handling this device (via the bus remove > > function). It is then up to the driver to ensure no further usage of the > > device > > from which it is being removed. This usually involves removing all user > > input > > vectors, disabling interrupts involved and flushing/canceling any delayed > > work. This should prevent any further use of the device by the driver. > > > > The driver's remove function is called in a direct call chain from > > platform_device_unregister, so by the time it returns, there should be no > > further chance of accesses. > > > > Bob, thx for your review comments. > The symptom is, after "rmmod i915", though drm_drv_release() is also > called on the child device "ipvr", I still see the module exist in the > system (check it by "lsmod"). This causes issue when I modprobe i915 and > ipvr again later. Actually I don't understand why this restriction > exists, but accroding to Daniel, grabbing a module refcount for the > platform device doesn't work (it would pin the module forever). Btw this entire story with platform drivers make unload a mess was just a best guess from my side why module unloading doesn't work well or could blow up. I've thought platform drivers registered from modules are inheritely racy, but I'll be very happy to learn that this is a misunderstanding on my side ;-) Wrt the testcase I'm fairly pragmatic though: Whatever makes it work reliably is good enough for me, even if it's a gross hack (we already need to manually kick fbcon anyway). Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH RESEND v4 1/3] drm: add bus_formats and num_bus_formats fields to drm_display_info
Add bus_formats and num_bus_formats fields and drm_display_info_set_bus_formats helper function to specify the bus formats supported by a given display. This information can be used by display controller drivers to configure the output interface appropriately (i.e. RGB565, RGB666 or RGB888 on raw RGB or LVDS busses). Signed-off-by: Boris Brezillon --- Hi, Sorry for the noise: I ran checkpatch after sending the series and it found a typo and two "line over 80 characters" warnings. This version fixes those warnings. Regards, Boris drivers/gpu/drm/drm_crtc.c | 33 + include/drm/drm_crtc.h | 8 2 files changed, 41 insertions(+) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index e79c8d3..20030ec 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -763,6 +763,39 @@ static void drm_mode_remove(struct drm_connector *connector, drm_mode_destroy(connector->dev, mode); } +/* + * drm_display_info_set_bus_formats - set the supported bus formats + * @info: display info to store bus formats in + * @fmts: array containing the supported bus formats + * @nfmts: the number of entries in the fmts array + * + * Store the supported bus formats in display info structure. + * See MEDIA_BUS_FMT_* definitions in include/uapi/linux/media-bus-format.h for + * a full list of available formats. + */ +int drm_display_info_set_bus_formats(struct drm_display_info *info, +const u32 *fmts, +unsigned int num_fmts) +{ + u32 *formats = NULL; + + if (!fmts && num_fmts) + return -EINVAL; + + if (fmts && num_fmts) { + formats = kmemdup(fmts, sizeof(*fmts) * num_fmts, GFP_KERNEL); + if (!formats) + return -ENOMEM; + } + + kfree(info->bus_formats); + info->bus_formats = formats; + info->num_bus_formats = num_fmts; + + return 0; +} +EXPORT_SYMBOL(drm_display_info_set_bus_formats); + /** * drm_connector_get_cmdline_mode - reads the user's cmdline mode * @connector: connector to quwery diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index c40070a..65dd08a 100644 --- a/include/drm/drm_crtc.h +++ b/include/drm/drm_crtc.h @@ -31,6 +31,7 @@ #include #include #include +#include #include #include #include @@ -130,6 +131,9 @@ struct drm_display_info { enum subpixel_order subpixel_order; u32 color_formats; + const u32 *bus_formats; + unsigned int num_bus_formats; + /* Mask of supported hdmi deep color modes */ u8 edid_hdmi_dc_modes; @@ -982,6 +986,10 @@ extern int drm_mode_connector_set_path_property(struct drm_connector *connector, extern int drm_mode_connector_update_edid_property(struct drm_connector *connector, struct edid *edid); +extern int drm_display_info_set_bus_formats(struct drm_display_info *info, + const u32 *fmts, + unsigned int nfmts); + static inline bool drm_property_type_is(struct drm_property *property, uint32_t type) { -- 1.9.1
[PATCH] drm/i915 Trouble with minimum brightness
On Fri, 28 Nov 2014, Jay Aurabind wrote: > Hello all, > > I notice that some activity has been going on with the minimum value > of display brightness recently (e1c412e7575). > > But the minimum value thats currently chosen is not at all acceptable > for my eyes. My display is working perfectly without that restriction > on minimum intensity. I tend to stare at the screen a lot and the > current minimum settings is straining my eyes. > > Even if you say that it may not be good for the devices, I still > insist, because I want my *display* to fail first, not my eyes. So > please try providing a way for the needy users to override this > minimum settings. I hope adding a module parameter would be easy fix. > > Something like this: ? (I dont call myself a kernel programmer yet, > just scratching the surface) > > > Provide provision for users to disable restriction on minimum brightness > value introduced in: > > commit e1c412e75754ab7b7002f3e18a2652d999c40d4b > Author: Jani Nikula > Date: Wed Nov 5 14:46:31 2014 +0200 > > drm/i915: safeguard against too high minimum brightness > > There are systems which work reliably without restriction on minimum > value of display brightness. Also the arbitrary value may be too high > for many users as well. Please file a new bug at [1], reference this mail, and attach /sys/kernel/debug/dri/0/i915_opregion. The minimum value is chosen and provided by the OEM. There's still some open questions about the interpretation of the value though (which lead to the commit you referenced), so I'm hesitant to make changes before we have those cleared up. In general I am not fond of adding new module parameters for tuning things. Every new knob is another point of failure that we need to test, and they are pretty much part of the ABI we can't easily drop or change. BR, Jani. [1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel > > Signed-off-by: Aurabindo J > --- > drivers/gpu/drm/i915/i915_drv.h| 1 + > drivers/gpu/drm/i915/i915_params.c | 6 ++ > drivers/gpu/drm/i915/intel_panel.c | 14 ++ > 3 files changed, 17 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index 16a6f6d..55d2ead 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -2213,6 +2213,7 @@ struct i915_params { > int disable_power_well; > int enable_ips; > int invert_brightness; > + int restrict_min_brightness; > int enable_cmd_parser; > /* leave bools at the end to not create holes */ > bool enable_hangcheck; > diff --git a/drivers/gpu/drm/i915/i915_params.c > b/drivers/gpu/drm/i915/i915_params.c > index c91cb20..0601c2a 100644 > --- a/drivers/gpu/drm/i915/i915_params.c > +++ b/drivers/gpu/drm/i915/i915_params.c > @@ -46,6 +46,7 @@ struct i915_params i915 __read_mostly = { > .prefault_disable = 0, > .reset = true, > .invert_brightness = 0, > + .restrict_min_brightness = 1, > .disable_display = 0, > .enable_cmd_parser = 1, > .disable_vtd_wa = 0, > @@ -155,6 +156,11 @@ MODULE_PARM_DESC(invert_brightness, > "to dri-devel at lists.freedesktop.org, if your machine needs it. " > "It will then be included in an upcoming module version."); > > +module_param_named(restrict_min_brightness, i915.restrict_min_brightness, > int, 0600); > +MODULE_PARM_DESC(restrict_min_brightness, > + "Restrict minimum brightness " > + "(-1 disable restriction, 0 value from VBT, 1 arbitrary value )"); > + > module_param_named(disable_display, i915.disable_display, bool, 0600); > MODULE_PARM_DESC(disable_display, "Disable display (default: false)"); > > diff --git a/drivers/gpu/drm/i915/intel_panel.c > b/drivers/gpu/drm/i915/intel_panel.c > index 41b3be2..def9f4e 100644 > --- a/drivers/gpu/drm/i915/intel_panel.c > +++ b/drivers/gpu/drm/i915/intel_panel.c > @@ -1109,10 +1109,16 @@ static u32 get_backlight_min_vbt(struct > intel_connector *connector) >* against this by letting the minimum be at most (arbitrarily chosen) >* 25% of the max. >*/ > - min = clamp_t(int, dev_priv->vbt.backlight.min_brightness, 0, 64); > - if (min != dev_priv->vbt.backlight.min_brightness) { > - DRM_DEBUG_KMS("clamping VBT min backlight %d/255 to %d/255\n", > - dev_priv->vbt.backlight.min_brightness, min); > + if (i915.restrict_min_brightness < 0) > + min = 0; > + else if (i915.restrict_min_brightness == 0) > + min = dev_priv->vbt.backlight.min_brightness; > + else { > + min = clamp_t(int, dev_priv->vbt.backlight.min_brightness, 0, > 64); > + if (min != dev_priv->vbt.backlight.min_brightness) { > + DRM_DEBUG_KMS("clamping VBT min backlight %d/255 to > %d/255\n", > + dev_priv->vbt.backlight.min_brightness,
RFC on upstreaming of a Mediatek DRM modesetting driver
Hi, We are currently in negotiations with one of our customers (Mediatek) on a strategy that will allow them to push a DRM modesetting driver into the upstream kernel. We are writing to get people's opinions and feedback on our proposed approach. Currently, our driver is structured in such a way that the display driver is more tightly integrated with the GPU driver than we would like. Although our kernel driver has been shipped with a GPL license for a long time, it is not in a form that would be considered acceptable upstream. Unfortunately, it is going to be a long process to get this part of the driver into a reasonable state. However, in the meantime, we don't want to prevent customer portions of the driver from being upstreamed. With the work done on recent kernels, and with a willing partner in Mediatek, we now think that we can restructure our driver in such a way as to allow this to happen. We see two basic approaches to achieving this: 1) Two independent DRM drivers, i.e. modesetting and render node drivers 2) A single componentised DRM driver Our (IMG's) preferred approach is to have a single componentised DRM driver. This is due to the following reasons: - Existing user space is not fully prepared to handle render nodes. - There is concern that any IMG DRM render node driver will need knowledge about multiple SoCs, each one being from a different vendor. Would this be deemed acceptable? - There is a trend, at least for DRM SoC drivers, towards using the component interface. Although there appears to be very few (one?) examples of GPU component drivers. To give some high level details on how we expect the componentised DRM driver model to work, each vendor (in this case Mediatek) will write their own DRM driver (supporting modesetting, dumb buffers, GEM, prime, etc) and IMG will provide an almost entirely independent component driver that adds in GPU support. Until our GPU driver is in a suitable state this will most likely necessitate a small kernel patch to wire up support, e.g. GPU specific ioctls. Cross-device and cross-process memory allocations will be made using the DRM driver. In order for this memory to be shared with the GPU component driver it will be necessary, at least for the time being, to export it via prime and import it via a GPU ioctl. Synchronisation between the display and GPU will be performed via reservation objects. Does this sound like a sane approach? Questions and/or feedback is very welcome. Thanks Frank
[PATCH 2/3] drm/panel: add s6e63j0x03 LCD Panel driver
ctx); > + > + s6e63j0x03_set_sequence(ctx); > + ret = ctx->error; > + > + if (ret < 0) > + return s6e63j0x03_disable(panel); No, you can't do this. While there's nothing enforcing this (yet), the panel can't be disabled before it's been prepared. > + > + ctx->power = FB_BLANK_UNBLANK; > + > + return ret; > +} > + > +static int s6e63j0x03_unprepare(struct drm_panel *panel) > +{ > + struct s6e63j0x03 *ctx = panel_to_s6e63j0x03(panel); > + int ret; > + > + s6e63j0x03_dcs_write_seq_static(ctx, MIPI_DCS_SET_DISPLAY_OFF); Use mipi_dsi_dcs_set_display_off(). > + s6e63j0x03_dcs_write_seq_static(ctx, MIPI_DCS_ENTER_SLEEP_MODE); Use mipi_dsi_dcs_enter_sleep_mode(). > + > + s6e63j0x03_clear_error(ctx); > + > + usleep_range(ctx->power_off_delay * 1000, > + (ctx->power_off_delay + 1) * 1000); > + > + ret = s6e63j0x03_power_off(ctx); > + if (ret < 0) > + return s6e63j0x03_prepare(panel); Huh? Why? > + > + ctx->power = FB_BLANK_POWERDOWN; > + > + return ret; > +} > + > +static const struct drm_panel_funcs s6e63j0x03_drm_funcs = { No need for "_drm" in the variable name here. > + .enable = s6e63j0x03_enable, > + .disable = s6e63j0x03_disable, > + .prepare= s6e63j0x03_prepare, Missing space between '.prepare' and '='. > + .unprepare = s6e63j0x03_unprepare, > + .get_modes = s6e63j0x03_get_modes, Please order these in the same way as they are declared in the structure. > +static int s6e63j0x03_parse_dt(struct s6e63j0x03 *ctx) > +{ > + struct device *dev = ctx->dev; > + struct device_node *np = dev->of_node; > + int ret; > + > + ret = of_get_videomode(np, &ctx->vm, 0); > + if (ret < 0) > + return ret; > + > + of_property_read_u32(np, "power-on-delay", &ctx->power_on_delay); > + of_property_read_u32(np, "power-off-delay", &ctx->power_off_delay); > + of_property_read_u32(np, "reset-delay", &ctx->reset_delay); > + of_property_read_u32(np, "init-delay", &ctx->init_delay); I take it that these are optional (I can't tell because you haven't provided a DT binding for this panel)? > +static int s6e63j0x03_probe(struct mipi_dsi_device *dsi) > +{ > + struct device *dev = &dsi->dev; > + struct s6e63j0x03 *ctx; > + int ret; > + > + ctx = devm_kzalloc(dev, sizeof(struct s6e63j0x03), GFP_KERNEL); > + if (!ctx) > + return -ENOMEM; > + > + mipi_dsi_set_drvdata(dsi, ctx); > + > + ctx->dev = dev; > + > + dsi->lanes = 1; > + dsi->format = MIPI_DSI_FMT_RGB888; > + dsi->mode_flags = MIPI_DSI_MODE_EOT_PACKET | MIPI_DSI_MODE_VIDEO_BURST; > + > + ret = s6e63j0x03_parse_dt(ctx); > + if (ret < 0) > + return ret; > + > + ctx->supplies[0].supply = "vdd3"; > + ctx->supplies[1].supply = "vci"; > + ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(ctx->supplies), > + ctx->supplies); > + if (ret < 0) { > + dev_err(dev, "failed to get regulators: %d\n", ret); > + return ret; > + } > + > + ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH); > + if (IS_ERR(ctx->reset_gpio)) { > + dev_err(dev, "cannot get reset-gpios %ld\n", > + PTR_ERR(ctx->reset_gpio)); "reset GPIO" since it's only one. Also please separate the error code from the rest of the message using a colon to make it more obvious that the number isn't the GPIO that could be gotten. > + ctx->bl_dev->props.max_brightness = MAX_BRIGHTNESS; > + ctx->bl_dev->props.brightness = DEFAULT_BRIGHTNESS; > + > + ret = drm_panel_add(&ctx->panel); > + if (ret < 0) > + goto err_unregister_backlight; > + > + ret = mipi_dsi_attach(dsi); > + if (ret < 0) > + goto err_remove_panel; > + > + return ret; > + > +err_remove_panel: > + drm_panel_remove(&ctx->panel); > + > +err_unregister_backlight: No need for the err_ prefix here. > + backlight_device_unregister(ctx->bl_dev); > + > + return ret; > +} > + > +static int s6e63j0x03_remove(struct mipi_dsi_device *dsi) > +{ > + struct s6e63j0x03 *ctx = mipi_dsi_get_drvdata(dsi); > + > + mipi_dsi_detach(dsi); > + drm_panel_remove(&ctx->panel); > + > + backlight_device_unregister(ctx->bl_dev); > + > + return 0; > +} > + > +static struct of_device_id s6e63j0x03_of_match[] = { static const please. > + { .compatible = "samsung,s6e63j0x03" }, > + { } > +}; > +MODULE_DEVICE_TABLE(of, s6e63j0x03_of_match); > + > +static struct mipi_dsi_driver s6e63j0x03_driver = { > + .probe = s6e63j0x03_probe, > + .remove = s6e63j0x03_remove, > + .driver = { > + .name = "panel_s6e63j0x03", > + .owner = THIS_MODULE, It is no longer necessary to specify this explicitly. > + .of_match_table = s6e63j0x03_of_match, > + }, > +}; > +module_mipi_dsi_driver(s6e63j0x03_driver); You're missing MODULE_AUTHOR, MODULE_DESCRIPTION and MODULE_LICENSE here. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141201/56994439/attachment.sig>
[PATCH 0/2] drm: tda998x: Fix a couple of problems
On Sat, Nov 29, 2014 at 09:12:51AM +0100, Jean-Francois Moine wrote: > 1) > The HDMI registers of the tda998x chips are accessed by pages. > As these HDMI registers may be accessed from different tasks > (video, irq/workqueue, and soon audio), the page register setting > must be protected. > > 2) > On HDMI reconnect (cable plug-in), the EDID is read too early and > this raises a EDID read timeout. Delaying a bit the connect event > fixes the problem. Both patches applied, thanks. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net.
[PATCH 1/3] hdmi: add new HDMI 2.0 defines
On Fri, Nov 28, 2014 at 03:50:49PM +0100, Hans Verkuil wrote: > From: Hans Verkuil > > Add new Video InfoFrame colorspace information introduced in HDMI 2.0 > and new Audio Coding Extension Types, also from HDMI 2.0. > > Signed-off-by: Hans Verkuil > --- > include/linux/hdmi.h | 20 > 1 file changed, 20 insertions(+) > > diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h > index 11c0182..38fd2a0 100644 > --- a/include/linux/hdmi.h > +++ b/include/linux/hdmi.h > @@ -37,6 +37,8 @@ enum hdmi_colorspace { > HDMI_COLORSPACE_RGB, > HDMI_COLORSPACE_YUV422, > HDMI_COLORSPACE_YUV444, > + HDMI_COLORSPACE_YUV420, > + HDMI_COLORSPACE_IDO_DEFINED = 7, > }; > > enum hdmi_scan_mode { > @@ -77,6 +79,10 @@ enum hdmi_extended_colorimetry { > HDMI_EXTENDED_COLORIMETRY_S_YCC_601, > HDMI_EXTENDED_COLORIMETRY_ADOBE_YCC_601, > HDMI_EXTENDED_COLORIMETRY_ADOBE_RGB, > + > + /* The following EC values are only defined in CEA-861-F. */ > + HDMI_EXTENDED_COLORIMETRY_BT2020_CONST_LUM, > + HDMI_EXTENDED_COLORIMETRY_BT2020, > }; > > enum hdmi_quantization_range { > @@ -201,9 +207,23 @@ enum hdmi_audio_sample_frequency { > > enum hdmi_audio_coding_type_ext { > HDMI_AUDIO_CODING_TYPE_EXT_STREAM, > + > + /* > + * The next three CXT values are defined in CEA-861-E only. > + * They do not exist in older versions, and in CEA-861-F they are > + * defined as 'Not in use'. > + */ > HDMI_AUDIO_CODING_TYPE_EXT_HE_AAC, > HDMI_AUDIO_CODING_TYPE_EXT_HE_AAC_V2, > HDMI_AUDIO_CODING_TYPE_EXT_MPEG_SURROUND, > + > + /* The following CXT values are only defined in CEA-861-F. */ > + HDMI_AUDIO_CODING_TYPE_EXT_MPEG4_HE_AAC, > + HDMI_AUDIO_CODING_TYPE_EXT_MPEG4_HE_AAC_V2, > + HDMI_AUDIO_CODING_TYPE_EXT_MPEG4_AAC_LC, > + HDMI_AUDIO_CODING_TYPE_EXT_DRA, > + HDMI_AUDIO_CODING_TYPE_EXT_MPEG_HE_AAC_SURROUND, > + HDMI_AUDIO_CODING_TYPE_EXT_MPEG_AAC_LC_SURROUND = 10, I think the last two should be MPEG4_{HE_AAC,AAC}_SURROUND, and with that fixed: Reviewed-by: Thierry Reding -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141201/9aa18dcc/attachment.sig>
[PATCH 2/2] drm/panel: Add support for Giantplus GPG482739QS5 panel
Hi Thierry, just a gentle ping for those 2 patches. It would be nice if you could pick them up, so they can go into the next mergewindow. Regards, Lucas Am Mittwoch, den 19.11.2014, 10:29 +0100 schrieb Lucas Stach: > From: Philipp Zabel > > This patch adds support for the GiantPlus GPG48273QS5 4.3" WQVGA TFT LCD panel > to the simple-panel driver. > > This panel is connected via a parallel bus and uses both HSYNC and VSYNC, > whose lengths are unfortunately not clearly defined. The datasheet only > specifies the front- and backporch length, but the timing diagram suggests > that both sync signals should be asserted for exactly one clock cycle. > > Signed-off-by: Philipp Zabel > Signed-off-by: Lucas Stach > --- > [lst]: rebased on top of drm/panel/for-next + added commit message > --- > .../bindings/panel/giantplus,gpg482739qs5.txt | 7 ++ > drivers/gpu/drm/panel/panel-simple.c | 26 > ++ > 2 files changed, 33 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/panel/giantplus,gpg482739qs5.txt > > diff --git > a/Documentation/devicetree/bindings/panel/giantplus,gpg482739qs5.txt > b/Documentation/devicetree/bindings/panel/giantplus,gpg482739qs5.txt > new file mode 100644 > index ..24b0b624434b > --- /dev/null > +++ b/Documentation/devicetree/bindings/panel/giantplus,gpg482739qs5.txt > @@ -0,0 +1,7 @@ > +GiantPlus GPG48273QS5 4.3" (480x272) WQVGA TFT LCD panel > + > +Required properties: > +- compatible: should be "giantplus,gpg48273qs5" > + > +This binding is compatible with the simple-panel binding, which is specified > +in simple-panel.txt in this directory. > diff --git a/drivers/gpu/drm/panel/panel-simple.c > b/drivers/gpu/drm/panel/panel-simple.c > index c4b6167a8bf3..1d8ed2062841 100644 > --- a/drivers/gpu/drm/panel/panel-simple.c > +++ b/drivers/gpu/drm/panel/panel-simple.c > @@ -560,6 +560,29 @@ static const struct panel_desc foxlink_fl500wvr00_a0t = { > }, > }; > > +static const struct drm_display_mode giantplus_gpg482739qs5_mode = { > + .clock = 9000, > + .hdisplay = 480, > + .hsync_start = 480 + 5, > + .hsync_end = 480 + 5 + 1, > + .htotal = 480 + 5 + 1 + 40, > + .vdisplay = 272, > + .vsync_start = 272 + 8, > + .vsync_end = 272 + 8 + 1, > + .vtotal = 272 + 8 + 1 + 8, > + .vrefresh = 60, > +}; > + > +static const struct panel_desc giantplus_gpg482739qs5 = { > + .modes = &giantplus_gpg482739qs5_mode, > + .num_modes = 1, > + .bpc = 8, > + .size = { > + .width = 95, > + .height = 54, > + }, > +}; > + > static const struct drm_display_mode hannstar_hsd070pww1_mode = { > .clock = 71100, > .hdisplay = 1280, > @@ -757,6 +780,9 @@ static const struct of_device_id platform_of_match[] = { > .compatible = "foxlink,fl500wvr00-a0t", > .data = &foxlink_fl500wvr00_a0t, > }, { > + .compatible = "giantplus,gpg482739qs5", > + .data = &giantplus_gpg482739qs5 > + }, { > .compatible = "hannstar,hsd070pww1", > .data = &hannstar_hsd070pww1, > }, { -- Pengutronix e.K. | Lucas Stach | Industrial Linux Solutions | http://www.pengutronix.de/ |
[PATCH 1/3] hdmi: add new HDMI 2.0 defines
On 12/01/2014 12:03 PM, Thierry Reding wrote: > On Fri, Nov 28, 2014 at 03:50:49PM +0100, Hans Verkuil wrote: >> From: Hans Verkuil >> >> Add new Video InfoFrame colorspace information introduced in HDMI 2.0 >> and new Audio Coding Extension Types, also from HDMI 2.0. >> >> Signed-off-by: Hans Verkuil >> --- >> include/linux/hdmi.h | 20 >> 1 file changed, 20 insertions(+) >> >> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h >> index 11c0182..38fd2a0 100644 >> --- a/include/linux/hdmi.h >> +++ b/include/linux/hdmi.h >> @@ -37,6 +37,8 @@ enum hdmi_colorspace { >> HDMI_COLORSPACE_RGB, >> HDMI_COLORSPACE_YUV422, >> HDMI_COLORSPACE_YUV444, >> +HDMI_COLORSPACE_YUV420, >> +HDMI_COLORSPACE_IDO_DEFINED = 7, >> }; >> >> enum hdmi_scan_mode { >> @@ -77,6 +79,10 @@ enum hdmi_extended_colorimetry { >> HDMI_EXTENDED_COLORIMETRY_S_YCC_601, >> HDMI_EXTENDED_COLORIMETRY_ADOBE_YCC_601, >> HDMI_EXTENDED_COLORIMETRY_ADOBE_RGB, >> + >> +/* The following EC values are only defined in CEA-861-F. */ >> +HDMI_EXTENDED_COLORIMETRY_BT2020_CONST_LUM, >> +HDMI_EXTENDED_COLORIMETRY_BT2020, >> }; >> >> enum hdmi_quantization_range { >> @@ -201,9 +207,23 @@ enum hdmi_audio_sample_frequency { >> >> enum hdmi_audio_coding_type_ext { >> HDMI_AUDIO_CODING_TYPE_EXT_STREAM, >> + >> +/* >> + * The next three CXT values are defined in CEA-861-E only. >> + * They do not exist in older versions, and in CEA-861-F they are >> + * defined as 'Not in use'. >> + */ >> HDMI_AUDIO_CODING_TYPE_EXT_HE_AAC, >> HDMI_AUDIO_CODING_TYPE_EXT_HE_AAC_V2, >> HDMI_AUDIO_CODING_TYPE_EXT_MPEG_SURROUND, >> + >> +/* The following CXT values are only defined in CEA-861-F. */ >> +HDMI_AUDIO_CODING_TYPE_EXT_MPEG4_HE_AAC, >> +HDMI_AUDIO_CODING_TYPE_EXT_MPEG4_HE_AAC_V2, >> +HDMI_AUDIO_CODING_TYPE_EXT_MPEG4_AAC_LC, >> +HDMI_AUDIO_CODING_TYPE_EXT_DRA, >> +HDMI_AUDIO_CODING_TYPE_EXT_MPEG_HE_AAC_SURROUND, >> +HDMI_AUDIO_CODING_TYPE_EXT_MPEG_AAC_LC_SURROUND = 10, > > I think the last two should be MPEG4_{HE_AAC,AAC}_SURROUND, and with > that fixed: > > Reviewed-by: Thierry Reding > You are correct, I will correct that. Thanks, Hans
[PATCH v14 05/12] drm: imx: imx-hdmi: move imx-hdmi to bridge/dw_hdmi
Hi Andy, Am Montag, den 01.12.2014, 19:24 +0800 schrieb Andy Yan: [...] > diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h > new file mode 100644 > index 000..1bbf3ca > --- /dev/null > +++ b/include/drm/bridge/dw_hdmi.h > @@ -0,0 +1,57 @@ > +/* > + * Copyright (C) 2011 Freescale Semiconductor, Inc. > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or > + * (at your option) any later version. > + */ > + > +#ifndef __DW_HDMI__ > +#define __DW_HDMI__ > + > +#include > + > +enum { > + RES_8, > + RES_10, > + RES_12, > + RES_MAX, > +}; > + > +enum dw_hdmi_devtype { > + IMX6Q_HDMI, > + IMX6DL_HDMI, > +}; > + > +struct mpll_config { > + unsigned long mpixelclock; > + struct { > + u16 cpce; > + u16 gmp; > + } res[RES_MAX]; > +}; > + > +struct curr_ctrl { > + unsigned long mpixelclock; > + u16 curr[RES_MAX]; > +}; > + > +struct sym_term { > + unsigned long mpixelclock; > + u16 sym_ctr;/*clock symbol and transmitter control*/ > + u16 term; /*transmission termination value*/ > +}; since this is going to be used by multiple drivers, the enums and structs should all be properly namespaced. How about DW_HDMI_RES_x, struct dw_hdmi_mpll_config, struct dw_hdmi_curr_ctrl, and struct dw_hdmi_sym_term? > +struct dw_hdmi_plat_data { > + enum dw_hdmi_devtype dev_type; > + const struct mpll_config *mpll_cfg; > + const struct curr_ctrl *cur_ctr; > + const struct sym_term *sym_term; > +}; > + > +void dw_hdmi_unbind(struct device *dev, struct device *master, void *data); > +int dw_hdmi_bind(struct device *dev, struct device *master, > + void *data, struct drm_encoder *encoder, > + const struct dw_hdmi_plat_data *plat_data); > +#endif /* __IMX_HDMI_H__ */ regards Philipp
[Bug 83461] hdmi screen flicker/unusable
https://bugzilla.kernel.org/show_bug.cgi?id=83461 --- Comment #27 from Christian König --- Created attachment 159331 --> https://bugzilla.kernel.org/attachment.cgi?id=159331&action=edit Testing patch. (In reply to kb from comment #26) > (In reply to Christian König from comment #25) > > You could try to artificially limit ref_div_max or fb_div_max until you get > > a stable signal once more. Maybe this will yield some more light on the root > > cause of the issue. > > Can you give me some details - how to do this? Attached is a testing patch which adds an artificially upper limit to 400.0 for the feedback divider (normal range 17.0-2048.0) and an upper limit of 13 for the reference divider (normal range 2-15). I suggest you start playing with the feedback divider values until you can figure out the limits for your hardware. E.g. try 400 as in my patch first, if that works raise it to 800 if that doesn't work go down to 600 again etc.. > > > > Do you think change of graphics card would resolve the issue? > > > > Well, most likely yes. > > > > But the new kernel seems to work better for some people, but has regressed > > for you. So I would really like to create a solution that works for > > everybody. > > Right now I switched to catalyst which seems to work and allows me to use > new kernel. But since apparently my card is "legacy" I had to downgrade to > xorg server 1.12 :-| Yeah, that's the problem I've got as well. The hardware isn't supported any more so the whole documentation is not available. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v13 07/12] drm: bridge/dw_hdmi: add support for multi-byte register width access
Am Freitag, den 28.11.2014, 17:43 +0800 schrieb Andy Yan: > Hi Zabel: > On 2014å¹´11æ27æ¥ 00:34, Philipp Zabel wrote: > > Am Mittwoch, den 26.11.2014, 21:32 +0800 schrieb Andy Yan: > >> On rockchip rk3288, only word(32-bit) accesses are > >> permitted for hdmi registers. Byte width accesses (writeb, > >> readb) generate an imprecise external abort. > >> > >> Signed-off-by: Andy Yan > >> > >> --- > >> > >> Changes in v13: None > >> Changes in v12: None > >> Changes in v11: None > >> Changes in v10: None > >> Changes in v9: None > >> Changes in v8: None > >> Changes in v7: None > >> Changes in v6: > >> - refactor register access without reg_shift > >> > >> Changes in v5: > >> - refactor reg-io-width > >> > >> Changes in v4: None > >> Changes in v3: > >> - split multi-register access to one indepent patch > >> > >> drivers/gpu/drm/bridge/dw_hdmi.c | 57 > >> +++- > >> 1 file changed, 51 insertions(+), 6 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c > >> b/drivers/gpu/drm/bridge/dw_hdmi.c > >> index a53bf63..5e88c8d 100644 > >> --- a/drivers/gpu/drm/bridge/dw_hdmi.c > >> +++ b/drivers/gpu/drm/bridge/dw_hdmi.c > >> @@ -100,6 +100,11 @@ struct hdmi_data_info { > >>struct hdmi_vmode video_mode; > >> }; > >> > >> +union dw_reg_ptr { > >> + u32 __iomem *p32; > >> + u8 __iomem *p8; > >> +}; > > I see no need to introduce this. Just explicitly multiply the offset in > > dw_hdmi_writel. > > > Is there any disadvantage to do like this? > The compiler can help us do the explicitly multiply by this way. Four additional lines, a new defined type, a few more changes to struct dw_hdmi and dw_hdmi_bind necessary. Technically I see no problem to let the compiler do the multiplication, my issue is that it ever so slightly obfuscates the code. Instead of just writing "* 4" in two functions, we get a new union that you need to know about when looking at struct dw_hdmi and dw_hdmi_bind, regs.p8 is used but never assigned directly, it's just a tiny bit of additional effort needed to understand the code. But when the cost to avoid that is so small... regards Philipp
[PATCH] drm/i915 Trouble with minimum brightness
On Mon, 01 Dec 2014, Jay Aurabind wrote: >> Please file a new bug at [1], reference this mail, and attach >> /sys/kernel/debug/dri/0/i915_opregion. > > Thank you for the response. But the file you mentioned to attach seems to be > a binary file, because I'm getting lot of junk characters. Is this normal ? Yes, it's binary. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center
[PATCH RESEND v4 1/3] drm: add bus_formats and num_bus_formats fields to drm_display_info
Hi Boris, Thank you for the patch. On Monday 01 December 2014 09:42:15 Boris Brezillon wrote: > Add bus_formats and num_bus_formats fields and > drm_display_info_set_bus_formats helper function to specify the bus > formats supported by a given display. > > This information can be used by display controller drivers to configure > the output interface appropriately (i.e. RGB565, RGB666 or RGB888 on raw > RGB or LVDS busses). > > Signed-off-by: Boris Brezillon Acked-by: Laurent Pinchart > --- > Hi, > > Sorry for the noise: I ran checkpatch after sending the series and it found > a typo and two "line over 80 characters" warnings. > > This version fixes those warnings. Please remember to increment the version number next time, it gets confusing otherwise when people start asking questions such as "which v4 ?". > drivers/gpu/drm/drm_crtc.c | 33 + > include/drm/drm_crtc.h | 8 > 2 files changed, 41 insertions(+) > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c > index e79c8d3..20030ec 100644 > --- a/drivers/gpu/drm/drm_crtc.c > +++ b/drivers/gpu/drm/drm_crtc.c > @@ -763,6 +763,39 @@ static void drm_mode_remove(struct drm_connector > *connector, drm_mode_destroy(connector->dev, mode); > } > > +/* > + * drm_display_info_set_bus_formats - set the supported bus formats > + * @info: display info to store bus formats in > + * @fmts: array containing the supported bus formats > + * @nfmts: the number of entries in the fmts array > + * > + * Store the supported bus formats in display info structure. > + * See MEDIA_BUS_FMT_* definitions in include/uapi/linux/media-bus-format.h > for > + * a full list of available formats. > + */ > +int drm_display_info_set_bus_formats(struct drm_display_info *info, > + const u32 *fmts, > + unsigned int num_fmts) > +{ > + u32 *formats = NULL; > + > + if (!fmts && num_fmts) > + return -EINVAL; > + > + if (fmts && num_fmts) { > + formats = kmemdup(fmts, sizeof(*fmts) * num_fmts, GFP_KERNEL); > + if (!formats) > + return -ENOMEM; > + } > + > + kfree(info->bus_formats); > + info->bus_formats = formats; > + info->num_bus_formats = num_fmts; > + > + return 0; > +} > +EXPORT_SYMBOL(drm_display_info_set_bus_formats); > + > /** > * drm_connector_get_cmdline_mode - reads the user's cmdline mode > * @connector: connector to quwery > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h > index c40070a..65dd08a 100644 > --- a/include/drm/drm_crtc.h > +++ b/include/drm/drm_crtc.h > @@ -31,6 +31,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -130,6 +131,9 @@ struct drm_display_info { > enum subpixel_order subpixel_order; > u32 color_formats; > > + const u32 *bus_formats; > + unsigned int num_bus_formats; > + > /* Mask of supported hdmi deep color modes */ > u8 edid_hdmi_dc_modes; > > @@ -982,6 +986,10 @@ extern int drm_mode_connector_set_path_property(struct > drm_connector *connector, extern int > drm_mode_connector_update_edid_property(struct drm_connector *connector, > struct edid *edid); > > +extern int drm_display_info_set_bus_formats(struct drm_display_info *info, > + const u32 *fmts, > + unsigned int nfmts); > + > static inline bool drm_property_type_is(struct drm_property *property, > uint32_t type) > { -- Regards, Laurent Pinchart
[PATCH RESEND v4 1/3] drm: add bus_formats and num_bus_formats fields to drm_display_info
Hi Laurent, On Mon, 01 Dec 2014 15:00:15 +0200 Laurent Pinchart wrote: > Hi Boris, > > Thank you for the patch. > > On Monday 01 December 2014 09:42:15 Boris Brezillon wrote: > > Add bus_formats and num_bus_formats fields and > > drm_display_info_set_bus_formats helper function to specify the bus > > formats supported by a given display. > > > > This information can be used by display controller drivers to configure > > the output interface appropriately (i.e. RGB565, RGB666 or RGB888 on raw > > RGB or LVDS busses). > > > > Signed-off-by: Boris Brezillon > > Acked-by: Laurent Pinchart > > > --- > > Hi, > > > > Sorry for the noise: I ran checkpatch after sending the series and it found > > a typo and two "line over 80 characters" warnings. > > > > This version fixes those warnings. > > Please remember to increment the version number next time, it gets confusing > otherwise when people start asking questions such as "which v4 ?". Okay. I wasn't sure, and eventually decided to just prefix the version with RESEND because these were only cosmetic changes, and I fixed them right after sending the v4. I'll know for next time ;-). Thanks, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
build regression with "rcar-du: Remove platform data support"
Hi Laurent, linux-next has failed to build with lager_defconfig and marzen_defconfig for a while, with this error: arch/arm/mach-shmobile/board-lager.c:35:41: fatal error: linux/platform_data/rcar-du.h: No such file or directory #include which is evidently the result of your patch commit 2378ad1228d2cdae0ea5448beb4fb2b42ebaf99c Author: Laurent Pinchart Date: Wed Sep 17 02:07:52 2014 +0300 drm: rcar-du: Remove platform data support All platforms now instantiate the DU through DT, platform data support isn't needed anymore. Signed-off-by: Laurent Pinchart that removes the header files. I assume some dependency wasn't tracked right, since linux-next still has these. $ git grep rcar_du_ arch/arm arch/arm/mach-shmobile/board-lager.c:static struct rcar_du_encoder_data lager_du_encoders[] = { arch/arm/mach-shmobile/board-lager.c:static const struct rcar_du_platform_data lager_du_pdata __initconst = { arch/arm/mach-shmobile/board-marzen.c:static struct rcar_du_encoder_data du_encoders[] = { arch/arm/mach-shmobile/board-marzen.c:static const struct rcar_du_platform_data du_pdata __initconst = { Can we please fix this before the merge window? Should the platform device registration just get removed from the two board files? Arnd
[PATCH 2/3] hdmi: added unpack and logging functions for InfoFrames
709"; > + case HDMI_COLORIMETRY_EXTENDED: return "Extended"; > + } > + return "Invalid/Unknown"; > +} These are names again, so same comments as for the infoframe type. And perhaps "No Data" -> "None" in that case. > + > +static const char *hdmi_picture_aspect_txt(enum hdmi_picture_aspect > picture_aspect) > +{ > + switch (picture_aspect) { > + case HDMI_PICTURE_ASPECT_NONE: return "No Data"; > + case HDMI_PICTURE_ASPECT_4_3: return "4:3"; > + case HDMI_PICTURE_ASPECT_16_9: return "16:9"; > + } > + return "Future"; > +} Same here. > +static const char *hdmi_quantization_range_txt(enum hdmi_quantization_range > quantization_range) > +{ > + switch (quantization_range) { > + case HDMI_QUANTIZATION_RANGE_DEFAULT: return "Default (depends on video > format)"; I think "Default" would do here ("depends on video format" can be derived from the reading of the specification). Generally I think these should focus on providing a human-readable version of the infoframes, not be a replacement for reading the specification. > +/** > + * hdmi_avi_infoframe_log() - log info of HDMI AVI infoframe > + * @dev: device > + * @frame: HDMI AVI infoframe > + */ > +static void hdmi_avi_infoframe_log(struct device *dev, struct > hdmi_avi_infoframe *frame) Perhaps allow this to take a log level? I can imagine drivers wanting to use this with dev_dbg() instead. > +/** > + * hdmi_vendor_infoframe_log() - log info of HDMI VENDOR infoframe > + * @dev: device > + * @frame: HDMI VENDOR infoframe > + */ > +static void hdmi_vendor_any_infoframe_log(struct device *dev, union > hdmi_vendor_any_infoframe *frame) > +{ > + struct hdmi_vendor_infoframe *hvf = &frame->hdmi; > + > + hdmi_infoframe_log_header(dev, frame); > + > + if (frame->any.oui != HDMI_IEEE_OUI) { > + dev_info(dev, "not a HDMI vendor infoframe\n"); > + return; > + } > + if (hvf->vic == 0 && hvf->s3d_struct == HDMI_3D_STRUCTURE_INVALID) { > + dev_info(dev, "empty frame\n"); > + return; > + } > + > + if (hvf->vic) { > + dev_info(dev, "Hdmi Vic: %d\n", hvf->vic); "HDMI VIC"? > + } No need for these braces. > +/** > + * hdmi_infoframe_log() - log info of HDMI infoframe > + * @dev: device > + * @frame: HDMI infoframe > + */ > +void hdmi_infoframe_log(struct device *dev, union hdmi_infoframe *frame) > +{ > + switch (frame->any.type) { > + case HDMI_INFOFRAME_TYPE_AVI: > + hdmi_avi_infoframe_log(dev, &frame->avi); > + break; > + case HDMI_INFOFRAME_TYPE_SPD: > + hdmi_spd_infoframe_log(dev, &frame->spd); > + break; > + case HDMI_INFOFRAME_TYPE_AUDIO: > + hdmi_audio_infoframe_log(dev, &frame->audio); > + break; > + case HDMI_INFOFRAME_TYPE_VENDOR: > + hdmi_vendor_any_infoframe_log(dev, &frame->vendor); > + break; > + default: > + WARN(1, "Bad infoframe type %d\n", frame->any.type); Does it make sense for this to be WARN? It's perfectly legal for future devices to expose new types of infoframes. Perhaps even expected. But if we want to keep this here to help get bug reports so that we don't forget to update this code, then maybe we should do the same wherever we query the name of enum values above. > +/** > + * hdmi_avi_infoframe_unpack() - unpack binary buffer to a HDMI AVI infoframe > + * @buffer: source buffer > + * @frame: HDMI AVI infoframe > + * > + * Unpacks the information contained in binary @buffer into a structured > + * @frame of the HDMI Auxiliary Video (AVI) information frame. > + * Also verifies the checksum as required by section 5.3.5 of the HDMI 1.4 > specification. > + * > + * Returns 0 on success or a negative error code on failure. > + */ > +static int hdmi_avi_infoframe_unpack(void *buffer, struct hdmi_avi_infoframe > *frame) I'm on the fence about ordering of arguments here. I think I'd slightly prefer the infoframe to be the first, to make the API more object- oriented. > +{ > + u8 *ptr = buffer; > + int ret; > + > + if (ptr[0] != HDMI_INFOFRAME_TYPE_AVI || > + ptr[1] != 2 || > + ptr[2] != HDMI_AVI_INFOFRAME_SIZE) { > + return -EINVAL; > + } No need for the braces. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141201/b49d69f2/attachment.sig>
build regression with "rcar-du: Remove platform data support"
Hi Arnd, On Monday 01 December 2014 14:09:36 Arnd Bergmann wrote: > Hi Laurent, > > linux-next has failed to build with lager_defconfig and marzen_defconfig for > a while, with this error: > > arch/arm/mach-shmobile/board-lager.c:35:41: fatal error: > linux/platform_data/rcar-du.h: No such file or directory #include > > > which is evidently the result of your patch > > commit 2378ad1228d2cdae0ea5448beb4fb2b42ebaf99c > Author: Laurent Pinchart > Date: Wed Sep 17 02:07:52 2014 +0300 > > drm: rcar-du: Remove platform data support > > All platforms now instantiate the DU through DT, platform data support > isn't needed anymore. > > Signed-off-by: Laurent Pinchart > > > that removes the header files. I assume some dependency wasn't tracked > right, since linux-next still has these. > > $ git grep rcar_du_ arch/arm > arch/arm/mach-shmobile/board-lager.c:static struct rcar_du_encoder_data > lager_du_encoders[] = { arch/arm/mach-shmobile/board-lager.c:static const > struct rcar_du_platform_data lager_du_pdata __initconst = { > arch/arm/mach-shmobile/board-marzen.c:static struct rcar_du_encoder_data > du_encoders[] = { arch/arm/mach-shmobile/board-marzen.c:static const struct > rcar_du_platform_data du_pdata __initconst = { > > Can we please fix this before the merge window? Should the platform > device registration just get removed from the two board files? That's what I've proposed in http://www.spinics.net/lists/dri-devel/msg72750.html Dave, could you please reply to that ? -- Regards, Laurent Pinchart
[PATCH 2/3] hdmi: added unpack and logging functions for InfoFrames
Hi Thierry, Thanks for the review, see my comments below. On 12/01/2014 02:15 PM, Thierry Reding wrote: > On Fri, Nov 28, 2014 at 03:50:50PM +0100, Hans Verkuil wrote: >> From: Martin Bugge >> >> When receiving video it is very useful to be able to unpack the InfoFrames. >> Logging is useful as well, both for transmitters and receivers. >> >> Especially when implementing the VIDIOC_LOG_STATUS ioctl (supported by many >> V4L2 drivers) for a receiver it is important to be able to easily log what >> the InfoFrame contains. This greatly simplifies debugging. >> >> Signed-off-by: Martin Bugge >> Signed-off-by: Hans Verkuil >> --- >> drivers/video/hdmi.c | 622 >> ++- >> include/linux/hdmi.h | 3 + >> 2 files changed, 618 insertions(+), 7 deletions(-) >> >> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c >> index 9e758a8..9f0f554 100644 >> --- a/drivers/video/hdmi.c >> +++ b/drivers/video/hdmi.c >> @@ -27,10 +27,10 @@ >> #include >> #include >> #include >> +#include >> >> -static void hdmi_infoframe_checksum(void *buffer, size_t size) >> +static u8 hdmi_infoframe_calc_checksum(u8 *ptr, size_t size) > > I'd personally keep the name here. I'll do that. > >> @@ -434,3 +441,604 @@ hdmi_infoframe_pack(union hdmi_infoframe *frame, void >> *buffer, size_t size) >> return length; >> } >> EXPORT_SYMBOL(hdmi_infoframe_pack); >> + >> +static const char *hdmi_infoframe_type_txt(enum hdmi_infoframe_type type) > > Perhaps: hdmi_infoframe_type_get_name()? I think that's better as well, I'll change it. > >> +{ >> +switch (type) { >> +case HDMI_INFOFRAME_TYPE_VENDOR: return "Vendor"; >> +case HDMI_INFOFRAME_TYPE_AVI: return "Auxiliary Video Information >> (AVI)"; >> +case HDMI_INFOFRAME_TYPE_SPD: return "Source Product Description (SPD)"; >> +case HDMI_INFOFRAME_TYPE_AUDIO: return "Audio"; > > I'd prefer "case ...:" and "return ...;" on separate lines for > readability. I actually think that makes it *less* readable. If you really want that, then I'll change it, but I would suggest that you try it yourself first to see if it is really more readable for you. It isn't for me, so I'll keep this for the next version. > >> +} >> +return "Invalid/Unknown"; >> +} > > Maybe include the numerical value here? Of course that either means that > callers must pass in a buffer or we sacrifice thread-safety. The buffer > could be optional, somewhat like this: > > const char *hdmi_infoframe_get_name(char *buffer, size_t length, > enum hdmi_infoframe_type type) > { > const char *name = NULL; > > switch (type) { > case HDMI_INFOFRAME_TYPE_VENDOR: > name = "Vendor"; > break; > ... > } > > if (buffer) { > if (!name) > snprintf(buffer, length, "unknown (%d)", type); > else > snprintf(buffer, length, name); > > name = buffer; > } > > return name; > } > > That way the function would be generally useful and could even be made > publicly available. I would do this only where it makes sense. Some of these fields have only one or two reserved bits left, and in that case is it easier to just say something like "Reserved (3)" and do that for each reserved value. > >> +static void hdmi_infoframe_log_header(struct device *dev, void *f) >> +{ >> +struct hdmi_any_infoframe *frame = f; >> +dev_info(dev, "HDMI infoframe: %s, version %d, length %d\n", >> +hdmi_infoframe_type_txt(frame->type), frame->version, >> frame->length); >> +} >> + >> +static const char *hdmi_colorspace_txt(enum hdmi_colorspace colorspace) >> +{ >> +switch (colorspace) { >> +case HDMI_COLORSPACE_RGB: return "RGB"; >> +case HDMI_COLORSPACE_YUV422: return "YCbCr 4:2:2"; >> +case HDMI_COLORSPACE_YUV444: return "YCbCr 4:4:4"; >> +case HDMI_COLORSPACE_YUV420: return "YCbCr 4:2:0"; >> +case HDMI_COLORSPACE_IDO_DEFINED: return "IDO Defined"; >> +} >> +return "Future"; >> +} > > Similar comments as for the above. > >> +static const char *hdmi_scan_mode_txt(enum hdmi_scan_mode scan_mode) >> +{ >> +switch(scan_mode) { >> +case HDMI_SCAN_MODE_NONE: return "No Data"; >> +case HDMI_SCAN_MODE_OVERSCAN: return "Composed for overscanned display"; >> +case HDMI_SCAN_MODE_UNDERSCAN: return "Composed for underscanned >> display"; >> +} >> +return "Future"; >> +} > > This isn't really a name any more, I think it should either stick to > names like "None", "Overscan", "Underscan" I agree with that, I'll change it. > or it should return a > description, in which case hdmi_scan_mode_get_description() might be > more accurate for a name. > >> +static const char *hd
[Bug 86832] [dota2][si] freezes up to 3 seconds when many/big display effects happen
https://bugs.freedesktop.org/show_bug.cgi?id=86832 --- Comment #4 from Sylvain BERTRAND --- up-to-date fedora rawhide, but dota2 is a 32 bits app: Name: mesa-libGL Arch: i686 Version : 10.5.0 Release : 0.devel.2.3d9c1a9.fc22 Size: 783 k Repo: installed >From repo : rawhide Summary : Mesa libGL runtime libraries and DRI drivers URL : http://www.mesa3d.org License : MIT Description : Mesa libGL runtime library. -- 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/20141201/b410079d/attachment.html>
[PATCH libdrm] drm: Avoid out of bound write in drmOpenByName()
In the fallback code that looks for devices in /proc, the read() may return with -1 in case of error (interruption from a signal for instance). We'll then happily write '\0' to buf[-2]. As we didn't really care about the signal interruption before, I kept it the same way, just making sure that retcode is > 0 to avoid that case. This was found by static analysis. Signed-off-by: Damien Lespiau --- xf86drm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xf86drm.c b/xf86drm.c index d900b4b..106b8ab 100644 --- a/xf86drm.c +++ b/xf86drm.c @@ -579,7 +579,7 @@ static int drmOpenByName(const char *name) if ((fd = open(proc_name, 0, 0)) >= 0) { retcode = read(fd, buf, sizeof(buf)-1); close(fd); - if (retcode) { + if (retcode > 0) { buf[retcode-1] = '\0'; for (driver = pt = buf; *pt && *pt != ' '; ++pt) ; -- 1.8.3.1
[Bug 83998] Oopses on R9270X using UVD since radeon/uvd: use PIPE_USAGE_STAGING for msg&fb buffers
https://bugs.freedesktop.org/show_bug.cgi?id=83998 --- Comment #7 from Andy Furniss --- Created attachment 110298 --> https://bugs.freedesktop.org/attachment.cgi?id=110298&action=edit different trace with newer kernel This is getting harder to trigger, started to think it was fixed. Haven't triggered with mpv yet, but can still just with mplayer. On third attempt, 115 starts in CPUs set to perf (may help trigger, but not sure). Uploading because current drm-next-219-wip has some fence changes and the trace starts with - radeon_fence_signaled -- 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/20141201/718d64cb/attachment.html>
[PATCH v4 1/3] drm: add bus_formats and num_bus_formats fields to drm_display_info
Am Montag, den 01.12.2014, 09:20 +0100 schrieb Boris Brezillon: > Add bus_formats and num_bus_formats fields and > drm_display_info_set_bus_formats helper function to specify the bus > formats supported by a given display. > > This information can be used by display controller drivers to configure > the output interface appropriately (i.e. RGB565, RGB666 or RGB888 on raw > RGB or LVDS busses). > > Signed-off-by: Boris Brezillon > --- > drivers/gpu/drm/drm_crtc.c | 32 > include/drm/drm_crtc.h | 7 +++ > 2 files changed, 39 insertions(+) > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c > index e79c8d3..d3b7ed0 100644 > --- a/drivers/gpu/drm/drm_crtc.c > +++ b/drivers/gpu/drm/drm_crtc.c > @@ -763,6 +763,38 @@ static void drm_mode_remove(struct drm_connector > *connector, > drm_mode_destroy(connector->dev, mode); > } > > +/* > + * drm_display_info_set_bus_formats - set the supported bus formats > + * @info: display info to store bus formats in > + * @fmts: array containing the supported bus formats > + * @nfmts: the number of entries in the fmts array > + * > + * Store the suppported bus formats in display info structure. > + * See MEDIA_BUS_FMT_* definitions in include/uapi/linux/media-bus-format.h > for > + * a full list of available formats. > + */ > +int drm_display_info_set_bus_formats(struct drm_display_info *info, const > u32 *fmts, > + unsigned int num_fmts) > +{ > + u32 *formats = NULL; > + > + if (!fmts && num_fmts) > + return -EINVAL; > + > + if (fmts && num_fmts) { > + formats = kmemdup(fmts, sizeof(*fmts) * num_fmts, GFP_KERNEL); > + if (!formats) > + return -ENOMEM; > + } > + > + kfree(info->bus_formats); > + info->bus_formats = formats; > + info->num_bus_formats = num_fmts; > + > + return 0; > +} > +EXPORT_SYMBOL(drm_display_info_set_bus_formats); > + > /** > * drm_connector_get_cmdline_mode - reads the user's cmdline mode > * @connector: connector to quwery > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h > index c40070a..a35844f 100644 > --- a/include/drm/drm_crtc.h > +++ b/include/drm/drm_crtc.h > @@ -31,6 +31,7 @@ > #include > #include > #include > +#include Nothing in drm_crtc.h uses MEDIA_BUS_FMT_*, is media-bus-format.h included here for the convenience of the user of drm_display_info_set_bus_formats? > #include > #include > #include > @@ -130,6 +131,9 @@ struct drm_display_info { > enum subpixel_order subpixel_order; > u32 color_formats; > > + const u32 *bus_formats; > + unsigned int num_bus_formats; > + > /* Mask of supported hdmi deep color modes */ > u8 edid_hdmi_dc_modes; > > @@ -982,6 +986,9 @@ extern int drm_mode_connector_set_path_property(struct > drm_connector *connector, > extern int drm_mode_connector_update_edid_property(struct drm_connector > *connector, > struct edid *edid); > > +extern int drm_display_info_set_bus_formats(struct drm_display_info *info, > + const u32 *fmts, unsigned int > nfmts); > + > static inline bool drm_property_type_is(struct drm_property *property, > uint32_t type) > { regards Philipp
[PATCH 0/2] Fix legacy boards compilation breakage with DU
On Friday 28 November 2014 10:17:33 Laurent Pinchart wrote: > On Friday 28 November 2014 09:18:46 Simon Horman wrote: > > [CCed Magnus, ARM SoC maintainers] > > > > On Thu, Nov 27, 2014 at 05:19:11PM +0200, Laurent Pinchart wrote: > > > Hello, > > > > > > The DU driver has lost support for platform data, resulting in a > > > compilation breakage for the legacy Marzen and Lager board files that > > > managed to keep under the radar until now. > > > > > > As the multiplatform boards should be used instead, drop support for DU in > > > the legacy Marzen and Lager boards. > > > > > > Simon, this is required to fix a compilation breakage in the drm-next > > > branch. I'm sorry for not catching it earlier :-/ How would you like this > > > to go in ? Could the patches be applied to the DRM tree ? They seem to > > > apply cleanly to both drm-next and your latest devel branch. > > > > > > Laurent Pinchart (2): > > > ARM: shmobile: lager: Remove DU platform device > > > ARM: shmobile: marzen: Remove DU platform device > > > > > > arch/arm/mach-shmobile/board-lager.c | 58 -- > > > arch/arm/mach-shmobile/board-marzen.c | 58 -- > > > > Yes, I think that should be fine as these fines are in maintenance mode and > > the only recent change I see to them is to modify the FSF address, which > > seems far away from the hunks in this patch-set. > > > > In other words, I think the chance of conflicts is small and I am fine with > > these changes going through the DRM tree if that is where the breakage > > manifests. > > > > Acked-by: Simon Horman > > > > I am of course, happy to take them if the DRM maintainer(s) prefer me to. > > Dave, how would you prefer to handle this ? If you want to pick it up, you can also add my Acked-by: Arnd Bergmann Otherwise we can merge it through arm-soc, but that would cause a larger bisection problem.
build regression with "rcar-du: Remove platform data support"
On Monday 01 December 2014 15:25:06 Laurent Pinchart wrote: > On Monday 01 December 2014 14:09:36 Arnd Bergmann wrote: > > Hi Laurent, > > > > linux-next has failed to build with lager_defconfig and marzen_defconfig for > > a while, with this error: > > > > arch/arm/mach-shmobile/board-lager.c:35:41: fatal error: > > linux/platform_data/rcar-du.h: No such file or directory #include > > > > > > which is evidently the result of your patch > > > > commit 2378ad1228d2cdae0ea5448beb4fb2b42ebaf99c > > Author: Laurent Pinchart > > Date: Wed Sep 17 02:07:52 2014 +0300 > > > > drm: rcar-du: Remove platform data support > > > > All platforms now instantiate the DU through DT, platform data support > > isn't needed anymore. > > > > Signed-off-by: Laurent Pinchart > > > > > > that removes the header files. I assume some dependency wasn't tracked > > right, since linux-next still has these. > > > > $ git grep rcar_du_ arch/arm > > arch/arm/mach-shmobile/board-lager.c:static struct rcar_du_encoder_data > > lager_du_encoders[] = { arch/arm/mach-shmobile/board-lager.c:static const > > struct rcar_du_platform_data lager_du_pdata __initconst = { > > arch/arm/mach-shmobile/board-marzen.c:static struct rcar_du_encoder_data > > du_encoders[] = { arch/arm/mach-shmobile/board-marzen.c:static const struct > > rcar_du_platform_data du_pdata __initconst = { > > > > Can we please fix this before the merge window? Should the platform > > device registration just get removed from the two board files? > > That's what I've proposed in > > http://www.spinics.net/lists/dri-devel/msg72750.html Ok, I actually saw that mail the other day but then forgot about it when I looked at the build logs. Arnd
[PATCH v4 1/3] drm: add bus_formats and num_bus_formats fields to drm_display_info
Hi Philipp, On Mon, 01 Dec 2014 16:06:26 +0100 Philipp Zabel wrote: > Am Montag, den 01.12.2014, 09:20 +0100 schrieb Boris Brezillon: > > Add bus_formats and num_bus_formats fields and > > drm_display_info_set_bus_formats helper function to specify the bus > > formats supported by a given display. > > > > This information can be used by display controller drivers to configure > > the output interface appropriately (i.e. RGB565, RGB666 or RGB888 on raw > > RGB or LVDS busses). > > > > Signed-off-by: Boris Brezillon > > --- > > drivers/gpu/drm/drm_crtc.c | 32 > > include/drm/drm_crtc.h | 7 +++ > > 2 files changed, 39 insertions(+) > > > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c > > index e79c8d3..d3b7ed0 100644 > > --- a/drivers/gpu/drm/drm_crtc.c > > +++ b/drivers/gpu/drm/drm_crtc.c > > @@ -763,6 +763,38 @@ static void drm_mode_remove(struct drm_connector > > *connector, > > drm_mode_destroy(connector->dev, mode); > > } > > > > +/* > > + * drm_display_info_set_bus_formats - set the supported bus formats > > + * @info: display info to store bus formats in > > + * @fmts: array containing the supported bus formats > > + * @nfmts: the number of entries in the fmts array > > + * > > + * Store the suppported bus formats in display info structure. > > + * See MEDIA_BUS_FMT_* definitions in > > include/uapi/linux/media-bus-format.h for > > + * a full list of available formats. > > + */ > > +int drm_display_info_set_bus_formats(struct drm_display_info *info, const > > u32 *fmts, > > +unsigned int num_fmts) > > +{ > > + u32 *formats = NULL; > > + > > + if (!fmts && num_fmts) > > + return -EINVAL; > > + > > + if (fmts && num_fmts) { > > + formats = kmemdup(fmts, sizeof(*fmts) * num_fmts, GFP_KERNEL); > > + if (!formats) > > + return -ENOMEM; > > + } > > + > > + kfree(info->bus_formats); > > + info->bus_formats = formats; > > + info->num_bus_formats = num_fmts; > > + > > + return 0; > > +} > > +EXPORT_SYMBOL(drm_display_info_set_bus_formats); > > + > > /** > > * drm_connector_get_cmdline_mode - reads the user's cmdline mode > > * @connector: connector to quwery > > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h > > index c40070a..a35844f 100644 > > --- a/include/drm/drm_crtc.h > > +++ b/include/drm/drm_crtc.h > > @@ -31,6 +31,7 @@ > > #include > > #include > > #include > > +#include > > Nothing in drm_crtc.h uses MEDIA_BUS_FMT_*, is media-bus-format.h > included here for the convenience of the user of > drm_display_info_set_bus_formats? Yes it is. Actually in the first versions MEDIA_BUS_FMT_* values were part of an enum. Still, I think keeping this include will help people finding where those MEDIA_BUS_FMT_* macros are defined. Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
[PATCH RESEND v4 1/3] drm: add bus_formats and num_bus_formats fields to drm_display_info
Am Montag, den 01.12.2014, 09:42 +0100 schrieb Boris Brezillon: > Add bus_formats and num_bus_formats fields and > drm_display_info_set_bus_formats helper function to specify the bus > formats supported by a given display. > > This information can be used by display controller drivers to configure > the output interface appropriately (i.e. RGB565, RGB666 or RGB888 on raw > RGB or LVDS busses). > > Signed-off-by: Boris Brezillon Acked-by: Philipp Zabel > --- > Hi, > > Sorry for the noise: I ran checkpatch after sending the series and it found > a typo and two "line over 80 characters" warnings. > > This version fixes those warnings. > > Regards, > > Boris > > drivers/gpu/drm/drm_crtc.c | 33 + > include/drm/drm_crtc.h | 8 > 2 files changed, 41 insertions(+) > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c > index e79c8d3..20030ec 100644 > --- a/drivers/gpu/drm/drm_crtc.c > +++ b/drivers/gpu/drm/drm_crtc.c > @@ -763,6 +763,39 @@ static void drm_mode_remove(struct drm_connector > *connector, > drm_mode_destroy(connector->dev, mode); > } > > +/* > + * drm_display_info_set_bus_formats - set the supported bus formats > + * @info: display info to store bus formats in > + * @fmts: array containing the supported bus formats > + * @nfmts: the number of entries in the fmts array > + * > + * Store the supported bus formats in display info structure. > + * See MEDIA_BUS_FMT_* definitions in include/uapi/linux/media-bus-format.h > for > + * a full list of available formats. > + */ > +int drm_display_info_set_bus_formats(struct drm_display_info *info, > + const u32 *fmts, > + unsigned int num_fmts) > +{ > + u32 *formats = NULL; > + > + if (!fmts && num_fmts) > + return -EINVAL; > + > + if (fmts && num_fmts) { > + formats = kmemdup(fmts, sizeof(*fmts) * num_fmts, GFP_KERNEL); > + if (!formats) > + return -ENOMEM; > + } > + > + kfree(info->bus_formats); > + info->bus_formats = formats; > + info->num_bus_formats = num_fmts; > + > + return 0; > +} > +EXPORT_SYMBOL(drm_display_info_set_bus_formats); > + > /** > * drm_connector_get_cmdline_mode - reads the user's cmdline mode > * @connector: connector to quwery > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h > index c40070a..65dd08a 100644 > --- a/include/drm/drm_crtc.h > +++ b/include/drm/drm_crtc.h > @@ -31,6 +31,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -130,6 +131,9 @@ struct drm_display_info { > enum subpixel_order subpixel_order; > u32 color_formats; > > + const u32 *bus_formats; > + unsigned int num_bus_formats; > + > /* Mask of supported hdmi deep color modes */ > u8 edid_hdmi_dc_modes; > > @@ -982,6 +986,10 @@ extern int drm_mode_connector_set_path_property(struct > drm_connector *connector, > extern int drm_mode_connector_update_edid_property(struct drm_connector > *connector, > struct edid *edid); > > +extern int drm_display_info_set_bus_formats(struct drm_display_info *info, > + const u32 *fmts, > + unsigned int nfmts); > + > static inline bool drm_property_type_is(struct drm_property *property, > uint32_t type) > {
RFC on upstreaming of a Mediatek DRM modesetting driver
On Mon, Dec 01, 2014 at 10:01:37AM +, Frank Binns wrote: > Hi, > > We are currently in negotiations with one of our customers (Mediatek) on > a strategy that will allow them to push a DRM modesetting driver into > the upstream kernel. We are writing to get people's opinions and > feedback on our proposed approach. > > Currently, our driver is structured in such a way that the display > driver is more tightly integrated with the GPU driver than we would > like. Although our kernel driver has been shipped with a GPL license for > a long time, it is not in a form that would be considered acceptable > upstream. Unfortunately, it is going to be a long process to get this > part of the driver into a reasonable state. However, in the meantime, we > don't want to prevent customer portions of the driver from being > upstreamed. With the work done on recent kernels, and with a willing > partner in Mediatek, we now think that we can restructure our driver in > such a way as to allow this to happen. > > We see two basic approaches to achieving this: > 1) Two independent DRM drivers, i.e. modesetting and render node drivers > 2) A single componentised DRM driver > > Our (IMG's) preferred approach is to have a single componentised DRM > driver. This is due to the following reasons: > > - Existing user space is not fully prepared to handle render nodes. > > - There is concern that any IMG DRM render node driver will need > knowledge about multiple SoCs, each one being from a different vendor. > Would this be deemed acceptable? > > - There is a trend, at least for DRM SoC drivers, towards using the > component interface. Although there appears to be very few (one?) > examples of GPU component drivers. > > To give some high level details on how we expect the componentised DRM > driver model to work, each vendor (in this case Mediatek) will write > their own DRM driver (supporting modesetting, dumb buffers, GEM, prime, > etc) and IMG will provide an almost entirely independent component > driver that adds in GPU support. Until our GPU driver is in a suitable > state this will most likely necessitate a small kernel patch to wire up > support, e.g. GPU specific ioctls. > > Cross-device and cross-process memory allocations will be made using the > DRM driver. In order for this memory to be shared with the GPU component > driver it will be necessary, at least for the time being, to export it > via prime and import it via a GPU ioctl. Synchronisation between the > display and GPU will be performed via reservation objects. > > Does this sound like a sane approach? Questions and/or feedback is very > welcome. Rule of thumb is that if it's an externally licensed IP block it should be a separate driver. Which is the case here. The idea is that the mostly generic IMG driver could be reused on other platforms that ship the same IP-block, while linking up with the respective display controller driver. The end result is 2 drm drivers: - Display block drm driver which expose KMS objects for modesetting, but only very basic gem (just enough to allocate dumb framebuffers and import/export dma-bufs). - Full-blown gem driver for the img render IP block. For an example look at the tegra/nouveau combo which can run on TK1. Plugggin in an IMG driver into each display block like it's currently done with all the armsoc stuff on android is imo completely no-go. Note that the component interface is completely irrelevant wrt the interface you expose to userspace. It's just an driver-internal helper library useful in certain situation. Not even the drm core really cares whether you use component helpers or not. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH libdrm] drm: Avoid out of bound write in drmOpenByName()
On Mon, Dec 01, 2014 at 02:07:03PM +, Damien Lespiau wrote: > In the fallback code that looks for devices in /proc, the read() may > return with -1 in case of error (interruption from a signal for > instance). We'll then happily write '\0' to buf[-2]. > > As we didn't really care about the signal interruption before, I kept it > the same way, just making sure that retcode is > 0 to avoid that case. > > This was found by static analysis. > > Signed-off-by: Damien Lespiau procfs support is dead, absolutely no point imo to fix it. From the kernel: commit cb6458f97b53d7f73043206c18014b3ca63ac345 Author: Daniel Vetter Date: Thu Aug 8 15:41:34 2013 +0200 drm: remove procfs code, take 2 So almost two years ago I've tried to nuke the procfs code already once before: http://lists.freedesktop.org/archives/dri-devel/2011-October/015707.html The conclusion was that userspace drivers (specifically libdrm device node detection) stopped relying on procfs in 2001. But after some digging it turned out that the drmstat tool in libdrm is still using those files (but only when certain options are set). So we've decided to keep profcs. But I when I've started to dig around again what exactly this tool does I've noticed that it tries to read the "mem", "vm", and "vma" files from procfs. Now as far my git history digging shows "mem" never did anything useful (at least in the version that first showed up in upstream history in 2004) and the file was remove in commit 955b12def42e83287c1bdb1411d99451753c1391 Author: Ben Gamari Date: Tue Feb 17 20:08:49 2009 -0500 drm: Convert proc files to seq_file and introduce debugfs Which means that for over 4 years drmstat has been broken, and no one cared. In my opinion that's proof enough that no one is actually using drmstat, and so that we can savely nuke the procfs support from drm. While at it fix up the error case cleanup for debugfs in drm_get_minor. v2: Fix dates, libdrm stopped relying on procfs for drm node detection in 2001. v3: fixup compilation warning for !CONFIG_DEBUG_FS, reported by Fengguang Wu. Cc: kbuild test robot Cc: Dave Airlie Signed-off-by: Daniel Vetter Signed-off-by: Dave Airlie Instead I think we should just rip this fallback code out. Volunteered? You can reuse the digging I've done for the kernel side. Cheers, Daniel > --- > xf86drm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/xf86drm.c b/xf86drm.c > index d900b4b..106b8ab 100644 > --- a/xf86drm.c > +++ b/xf86drm.c > @@ -579,7 +579,7 @@ static int drmOpenByName(const char *name) > if ((fd = open(proc_name, 0, 0)) >= 0) { > retcode = read(fd, buf, sizeof(buf)-1); > close(fd); > - if (retcode) { > + if (retcode > 0) { > buf[retcode-1] = '\0'; > for (driver = pt = buf; *pt && *pt != ' '; ++pt) > ; > -- > 1.8.3.1 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
RFC on upstreaming of a Mediatek DRM modesetting driver
On Mon, Dec 01, 2014 at 10:01:37AM +, Frank Binns wrote: > Hi, > > We are currently in negotiations with one of our customers (Mediatek) on a > strategy that will allow them to push a DRM modesetting driver into the > upstream kernel. We are writing to get people's opinions and feedback on > our proposed approach. > > Currently, our driver is structured in such a way that the display driver > is more tightly integrated with the GPU driver than we would like. Although > our kernel driver has been shipped with a GPL license for a long time, it > is not in a form that would be considered acceptable upstream. Unfortunately, > it is going to be a long process to get this part of the driver into a > reasonable state. However, in the meantime, we don't want to prevent customer > portions of the driver from being upstreamed. With the work done on recent > kernels, and with a willing partner in Mediatek, we now think that we can > restructure our driver in such a way as to allow this to happen. > > We see two basic approaches to achieving this: > 1) Two independent DRM drivers, i.e. modesetting and render node drivers > 2) A single componentised DRM driver > > Our (IMG's) preferred approach is to have a single componentised DRM driver. > This is due to the following reasons: > > - Existing user space is not fully prepared to handle render nodes. > > - There is concern that any IMG DRM render node driver will need knowledge > about multiple SoCs, each one being from a different vendor. Would this > be deemed acceptable? > > - There is a trend, at least for DRM SoC drivers, towards using the component > interface. Although there appears to be very few (one?) examples of GPU > component drivers. > > To give some high level details on how we expect the componentised DRM driver > model to work, each vendor (in this case Mediatek) will write their own DRM > driver (supporting modesetting, dumb buffers, GEM, prime, etc) and IMG will > provide an almost entirely independent component driver that adds in GPU > support. Until our GPU driver is in a suitable state this will most likely > necessitate a small kernel patch to wire up support, e.g. GPU specific ioctls. > > Cross-device and cross-process memory allocations will be made using the DRM > driver. In order for this memory to be shared with the GPU component driver > it will be necessary, at least for the time being, to export it via prime and > import it via a GPU ioctl. Synchronisation between the display and GPU will be > performed via reservation objects. > > Does this sound like a sane approach? Questions and/or feedback is very > welcome. Writting a standalone KMS only drm driver for the whole modesetting side is fine. So is using DMA buffer to export/import buffer btw your KMS driver and your accel providing driver (two separate standalone driver). As long as you do not do anything as ugly as IMG have done in the past in which they hook up inside each drm driver and add there own set of ioctl on top. A side note is that any IMG driver can not be accepted without open source user space and also a proper design. AFAICT current IMG driver design is unsuited for upstream given how unsecure it is. My understanding of it is that it's very easy for userspace to use IMG to read/write to any system memory. So frankly i do not expect anything on the IMG side to be worth troubling us with as long as there is no open source userspace and proper secure driver design. Cheers, Jérôme > > Thanks > Frank
[PATCH 2/3] hdmi: added unpack and logging functions for InfoFrames
On Mon, Dec 01, 2014 at 02:48:47PM +0100, Hans Verkuil wrote: > Hi Thierry, > > Thanks for the review, see my comments below. > > On 12/01/2014 02:15 PM, Thierry Reding wrote: > > On Fri, Nov 28, 2014 at 03:50:50PM +0100, Hans Verkuil wrote: [...] > >> +{ > >> + switch (type) { > >> + case HDMI_INFOFRAME_TYPE_VENDOR: return "Vendor"; > >> + case HDMI_INFOFRAME_TYPE_AVI: return "Auxiliary Video Information > >> (AVI)"; > >> + case HDMI_INFOFRAME_TYPE_SPD: return "Source Product Description (SPD)"; > >> + case HDMI_INFOFRAME_TYPE_AUDIO: return "Audio"; > > > > I'd prefer "case ...:" and "return ...;" on separate lines for > > readability. > > I actually think that makes it *less* readable. If you really want that, then > I'll > change it, but I would suggest that you try it yourself first to see if it is > really more readable for you. It isn't for me, so I'll keep this for the next > version. I did, and I still think separate lines are more readable, especially if you throw in a blank line after the "return ...;". Anyway, I could keep my OCD in check if it weren't for the fact that half of these are the cause for checkpatch to complain. And then if you change the ones that checkpatch wants you to change, all the others would be inconsistent and then I'd complain about the inconsistency... checkpatch flagged a couple other issues, please make sure to address those as well. > > Maybe include the numerical value here? Of course that either means that > > callers must pass in a buffer or we sacrifice thread-safety. The buffer > > could be optional, somewhat like this: > > > > const char *hdmi_infoframe_get_name(char *buffer, size_t length, > > enum hdmi_infoframe_type type) > > { > > const char *name = NULL; > > > > switch (type) { > > case HDMI_INFOFRAME_TYPE_VENDOR: > > name = "Vendor"; > > break; > > ... > > } > > > > if (buffer) { > > if (!name) > > snprintf(buffer, length, "unknown (%d)", type); > > else > > snprintf(buffer, length, name); > > > > name = buffer; > > } > > > > return name; > > } > > > > That way the function would be generally useful and could even be made > > publicly available. > > I would do this only where it makes sense. Some of these fields have only one > or > two reserved bits left, and in that case is it easier to just say something > like "Reserved (3)" and do that for each reserved value. Okay. > >> +/** > >> + * hdmi_infoframe_log() - log info of HDMI infoframe > >> + * @dev: device > >> + * @frame: HDMI infoframe > >> + */ > >> +void hdmi_infoframe_log(struct device *dev, union hdmi_infoframe *frame) > >> +{ > >> + switch (frame->any.type) { > >> + case HDMI_INFOFRAME_TYPE_AVI: > >> + hdmi_avi_infoframe_log(dev, &frame->avi); > >> + break; > >> + case HDMI_INFOFRAME_TYPE_SPD: > >> + hdmi_spd_infoframe_log(dev, &frame->spd); > >> + break; > >> + case HDMI_INFOFRAME_TYPE_AUDIO: > >> + hdmi_audio_infoframe_log(dev, &frame->audio); > >> + break; > >> + case HDMI_INFOFRAME_TYPE_VENDOR: > >> + hdmi_vendor_any_infoframe_log(dev, &frame->vendor); > >> + break; > >> + default: > >> + WARN(1, "Bad infoframe type %d\n", frame->any.type); > > > > Does it make sense for this to be WARN? It's perfectly legal for future > > devices to expose new types of infoframes. Perhaps even expected. But if > > we want to keep this here to help get bug reports so that we don't > > forget to update this code, then maybe we should do the same wherever we > > query the name of enum values above. > > I'll drop the WARN from the log function. I think it should also be dropped > from the unpack. The only place it makes sense is for pack() since there the > data comes from the driver, not from an external source. Sounds good. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141201/df0abddb/attachment-0001.sig>
[PATCH 2/3] hdmi: added unpack and logging functions for InfoFrames
On Mon, Dec 01, 2014 at 04:33:31PM +0100, Thierry Reding wrote: > On Mon, Dec 01, 2014 at 02:48:47PM +0100, Hans Verkuil wrote: > > Hi Thierry, > > > > Thanks for the review, see my comments below. > > > > On 12/01/2014 02:15 PM, Thierry Reding wrote: > > > On Fri, Nov 28, 2014 at 03:50:50PM +0100, Hans Verkuil wrote: > [...] > > >> +{ > > >> +switch (type) { > > >> +case HDMI_INFOFRAME_TYPE_VENDOR: return "Vendor"; > > >> +case HDMI_INFOFRAME_TYPE_AVI: return "Auxiliary Video > > >> Information (AVI)"; > > >> +case HDMI_INFOFRAME_TYPE_SPD: return "Source Product > > >> Description (SPD)"; > > >> +case HDMI_INFOFRAME_TYPE_AUDIO: return "Audio"; > > > > > > I'd prefer "case ...:" and "return ...;" on separate lines for > > > readability. > > > > I actually think that makes it *less* readable. If you really want that, > > then I'll > > change it, but I would suggest that you try it yourself first to see if it > > is > > really more readable for you. It isn't for me, so I'll keep this for the > > next > > version. > > I did, and I still think separate lines are more readable, especially if > you throw in a blank line after the "return ...;". Anyway, I could keep > my OCD in check if it weren't for the fact that half of these are the > cause for checkpatch to complain. And then if you change the ones that > checkpatch wants you to change, all the others would be inconsistent and > then I'd complain about the inconsistency... Throwing in my own unasked-for bikshed opinion ;-) I agree with Thierry that it's more readable since this way the key and the value can be lined up easily. That's also possible with the single-line case/return like you do with some more tabs, but usually means all the lines overflow the 80 limit badly. So only really works for small defines/values. So my rule of thumb is - go with single-line case/return and align them - but break the lines if they would be too long. Now back to doing useful stuff for me. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH v4 1/3] drm: add bus_formats and num_bus_formats fields to drm_display_info
On Mon, Dec 01, 2014 at 09:20:59AM +0100, Boris Brezillon wrote: > Add bus_formats and num_bus_formats fields and > drm_display_info_set_bus_formats helper function to specify the bus > formats supported by a given display. > > This information can be used by display controller drivers to configure > the output interface appropriately (i.e. RGB565, RGB666 or RGB888 on raw > RGB or LVDS busses). > > Signed-off-by: Boris Brezillon > --- > drivers/gpu/drm/drm_crtc.c | 32 > include/drm/drm_crtc.h | 7 +++ > 2 files changed, 39 insertions(+) > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c > index e79c8d3..d3b7ed0 100644 > --- a/drivers/gpu/drm/drm_crtc.c > +++ b/drivers/gpu/drm/drm_crtc.c > @@ -763,6 +763,38 @@ static void drm_mode_remove(struct drm_connector > *connector, > drm_mode_destroy(connector->dev, mode); > } > > +/* This needs a /** marker to make it a valid kerneldoc comment. > + * drm_display_info_set_bus_formats - set the supported bus formats > + * @info: display info to store bus formats in > + * @fmts: array containing the supported bus formats > + * @nfmts: the number of entries in the fmts array > + * > + * Store the suppported bus formats in display info structure. > + * See MEDIA_BUS_FMT_* definitions in include/uapi/linux/media-bus-format.h > for > + * a full list of available formats. > + */ > +int drm_display_info_set_bus_formats(struct drm_display_info *info, const > u32 *fmts, This one still exceeds 80-characters per line, but perhaps I'm reviewing the wrong patch? Also I think fmts should be formats here. > + unsigned int num_fmts) And this should be num_formats, for consistency. Also make sure to keep this consistent with the kerneldoc. > +{ > + u32 *formats = NULL; If you name the parameter formats, maybe bus_formats would be a good alternative for this local variable. Or fmts here. I think it's most important that the public API gets the more idiomatic name. > + > + if (!fmts && num_fmts) > + return -EINVAL; > + > + if (fmts && num_fmts) { > + formats = kmemdup(fmts, sizeof(*fmts) * num_fmts, GFP_KERNEL); > + if (!formats) > + return -ENOMEM; > + } > + > + kfree(info->bus_formats); > + info->bus_formats = formats; > + info->num_bus_formats = num_fmts; > + > + return 0; > +} > +EXPORT_SYMBOL(drm_display_info_set_bus_formats); I think you'll want to call kfree() on the bus_formats array from drm_connector_cleanup() as well to make sure you don't leak this on driver unload. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141201/ec921883/attachment.sig>
drm: exynos: mixer: fix using usleep() in atomic context
On Sun, Nov 30, 2014 at 01:35:25AM +0100, tjakobi at math.uni-bielefeld.de wrote: > From: Tomasz Stanislawski > > This patch fixes calling usleep_range() after taking reg_slock > using spin_lock_irqsave(). The mdelay() is used instead. > Waiting in atomic context is not the best idea in general. > Hopefully, waiting occurs only when Video Processor fails > to reset correctly. > > Signed-off-by: Tomasz Stanislawski > --- > drivers/gpu/drm/exynos/exynos_mixer.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c > b/drivers/gpu/drm/exynos/exynos_mixer.c > index a41c84e..cc7 100644 > --- a/drivers/gpu/drm/exynos/exynos_mixer.c > +++ b/drivers/gpu/drm/exynos/exynos_mixer.c > @@ -632,7 +632,7 @@ static void vp_win_reset(struct mixer_context *ctx) > /* waiting until VP_SRESET_PROCESSING is 0 */ > if (~vp_reg_read(res, VP_SRESET) & VP_SRESET_PROCESSING) > break; > - usleep_range(1, 12000); > + mdelay(10); > } > WARN(tries == 0, "failed to reset Video Processor\n"); > } I can't see a reason why you would need to hold the lock around this code. Perhaps a better way to fix this would be to drop the lock before calling vp_win_reset()? Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141201/e30b9bbe/attachment.sig>
[PATCH 1/1] GPU-DRM-MSM-Adreno: Deletion of unnecessary checks before the function call "release_firmware"
On Tue, Nov 25, 2014 at 01:50:25PM +0100, SF Markus Elfring wrote: > From: Markus Elfring You can probably get rid of this if you configure your emailer properly. > Date: Tue, 25 Nov 2014 13:44:20 +0100 This is odd. I've never seen git send-email generate these. I didn't notice with your earlier patches, but the subject prefix is wrong. Please use something more consistent with existing patches, in this case: "drm/msm: ..." or "drm/msm/adreno: ..." > The release_firmware() function tests whether its argument is NULL > and then returns immediately. Thus the test around the call is not needed. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring > --- > drivers/gpu/drm/msm/adreno/adreno_gpu.c | 6 ++ > 1 file changed, 2 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c > b/drivers/gpu/drm/msm/adreno/adreno_gpu.c > index 655ce5b..757052c 100644 > --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c > +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c > @@ -404,9 +404,7 @@ void adreno_gpu_cleanup(struct adreno_gpu *gpu) > msm_gem_put_iova(gpu->memptrs_bo, gpu->base.id); > drm_gem_object_unreference(gpu->memptrs_bo); > } > - if (gpu->pm4) > - release_firmware(gpu->pm4); > - if (gpu->pfp) > - release_firmware(gpu->pfp); > + release_firmware(gpu->pm4); > + release_firmware(gpu->pfp); > msm_gpu_cleanup(&gpu->base); > } Besides the subject prefix, Reviewed-by: Thierry Reding -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141201/10bc8e41/attachment.sig>
[PATCH 1/1] GPU-DRM-MSM: Deletion of unnecessary checks before two function calls
On Tue, Nov 25, 2014 at 02:33:53PM +0100, SF Markus Elfring wrote: > From: Markus Elfring > Date: Tue, 25 Nov 2014 14:30:28 +0100 > > The functions framebuffer_release() and vunmap() perform also input > parameter validation. Thus the test around the call is not needed. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring > --- > drivers/gpu/drm/msm/msm_fbdev.c | 3 +-- > drivers/gpu/drm/msm/msm_gem.c | 3 +-- > 2 files changed, 2 insertions(+), 4 deletions(-) This needs the same fix for the subject prefix that I mentioned for your other patch, otherwise: Reviewed-by: Thierry Reding Perhaps a good idea would be to send all of these patches with the subject prefix fixed up as a second version and threaded in a series. That makes it easier for people to pick them up (assuming Dave will take them directly). Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141201/11f42aa7/attachment.sig>
[PATCH 1/1] GPU-DRM-MSM: Deletion of unnecessary checks before two function calls
On Mon, Dec 1, 2014 at 11:04 AM, Thierry Reding wrote: > On Tue, Nov 25, 2014 at 02:33:53PM +0100, SF Markus Elfring wrote: >> From: Markus Elfring >> Date: Tue, 25 Nov 2014 14:30:28 +0100 >> >> The functions framebuffer_release() and vunmap() perform also input >> parameter validation. Thus the test around the call is not needed. >> >> This issue was detected by using the Coccinelle software. >> >> Signed-off-by: Markus Elfring >> --- >> drivers/gpu/drm/msm/msm_fbdev.c | 3 +-- >> drivers/gpu/drm/msm/msm_gem.c | 3 +-- >> 2 files changed, 2 insertions(+), 4 deletions(-) > > This needs the same fix for the subject prefix that I mentioned for your > other patch, otherwise: > > Reviewed-by: Thierry Reding > > Perhaps a good idea would be to send all of these patches with the > subject prefix fixed up as a second version and threaded in a series. > That makes it easier for people to pick them up (assuming Dave will take > them directly). > no worries, I'll fix up the subject lines when I apply.. BR, -R > Thierry > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >
[PATCH 1/1] GPU-DRM-MSM: Deletion of unnecessary checks before two function calls
btw, I have these two queued up on msm-next, thanks BR, -R On Tue, Nov 25, 2014 at 8:33 AM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Tue, 25 Nov 2014 14:30:28 +0100 > > The functions framebuffer_release() and vunmap() perform also input > parameter validation. Thus the test around the call is not needed. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring > --- > drivers/gpu/drm/msm/msm_fbdev.c | 3 +-- > drivers/gpu/drm/msm/msm_gem.c | 3 +-- > 2 files changed, 2 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/msm/msm_fbdev.c b/drivers/gpu/drm/msm/msm_fbdev.c > index ab5bfd2..fd5a6f3 100644 > --- a/drivers/gpu/drm/msm/msm_fbdev.c > +++ b/drivers/gpu/drm/msm/msm_fbdev.c > @@ -193,8 +193,7 @@ fail_unlock: > fail: > > if (ret) { > - if (fbi) > - framebuffer_release(fbi); > + framebuffer_release(fbi); > if (fb) { > drm_framebuffer_unregister_private(fb); > drm_framebuffer_remove(fb); > diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c > index 4b1b82a..157cf21 100644 > --- a/drivers/gpu/drm/msm/msm_gem.c > +++ b/drivers/gpu/drm/msm/msm_gem.c > @@ -543,8 +543,7 @@ void msm_gem_free_object(struct drm_gem_object *obj) > drm_free_large(msm_obj->pages); > > } else { > - if (msm_obj->vaddr) > - vunmap(msm_obj->vaddr); > + vunmap(msm_obj->vaddr); > put_pages(obj); > } > > -- > 2.1.3 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/
RFC on upstreaming of a Mediatek DRM modesetting driver
On Mon, Dec 1, 2014 at 5:01 AM, Frank Binns wrote: > Hi, > > We are currently in negotiations with one of our customers (Mediatek) on a > strategy that will allow them to push a DRM modesetting driver into the > upstream kernel. We are writing to get people's opinions and feedback on our > proposed approach. > > Currently, our driver is structured in such a way that the display driver is > more tightly integrated with the GPU driver than we would like. Although our > kernel driver has been shipped with a GPL license for a long time, it is not > in a form that would be considered acceptable upstream. Unfortunately, it is > going to be a long process to get this part of the driver into a reasonable > state. However, in the meantime, we don't want to prevent customer portions > of the driver from being upstreamed. With the work done on recent kernels, > and with a willing partner in Mediatek, we now think that we can restructure > our driver in such a way as to allow this to happen. > > We see two basic approaches to achieving this: > 1) Two independent DRM drivers, i.e. modesetting and render node drivers > 2) A single componentised DRM driver As others have said, a render-node kms driver is the way to go, so that the various KMS drivers it works with can be themselves upstreamed. In the past, I had gone (more or less) the second approach w/ omapdrm but that required carrying some downstream omapdrm patches for the integration with gpu. This was, because at the time there was really no alternative. But now that we have dmabuf/prime and fence stuff in place, there is no more a need to do that. So the best approach is one that allows the display/kms drivers to be used without downstream patches. Ofc, it would be nice to see an upstream-worthy driver for the gpu side of things, but as others have noted, upstream kernel drivers require *some* form of open source userspace so that we actually have a proper way to review and test the code. BR, -R > Our (IMG's) preferred approach is to have a single componentised DRM driver. > This is due to the following reasons: > > - Existing user space is not fully prepared to handle render nodes. > > - There is concern that any IMG DRM render node driver will need knowledge > about multiple SoCs, each one being from a different vendor. Would this be > deemed acceptable? > > - There is a trend, at least for DRM SoC drivers, towards using the component > interface. Although there appears to be very few (one?) examples of GPU > component drivers. > > To give some high level details on how we expect the componentised DRM driver > model to work, each vendor (in this case Mediatek) will write their own DRM > driver (supporting modesetting, dumb buffers, GEM, prime, etc) and IMG will > provide an almost entirely independent component driver that adds in GPU > support. Until our GPU driver is in a suitable > state this will most likely necessitate a small kernel patch to wire up > support, e.g. GPU specific ioctls. > > Cross-device and cross-process memory allocations will be made using the DRM > driver. In order for this memory to be shared with the GPU component driver > it will be necessary, at least for the time being, to export it via prime and > import it via a GPU ioctl. Synchronisation between the display and GPU will > be performed via reservation objects. > > Does this sound like a sane approach? Questions and/or feedback is very > welcome. > > Thanks > Frank > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/6] drm/edid: new drm_edid_block_checksum helper function V3
On Sun, Nov 30, 2014 at 07:57:43PM +0100, Stefan Brüns wrote: > The function will also be used by a later patch, so factor it out. > > V2: make raw_edid const, define/declare before first use > V3: fix erroneuos removal of csum variable > > Signed-off-by: Stefan Brüns > Reviewed-by: Jani Nikula Ok, merged the first three patches from this series to my drm patch pile branch. I'll send a pull for that to Dave for 3.19 I think, but might miss for 3.20. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 86267] [drm:evergreen_resume] *ERROR* evergreen startup failed on resume
https://bugs.freedesktop.org/show_bug.cgi?id=86267 Ismael changed: What|Removed |Added Hardware|Other |x86-64 (AMD64) OS|All |Linux (All) Severity|normal |major --- Comment #6 from Ismael --- I get the error every time I suspend the machine. And 3D acceleration is disabled until I reboot. I am using a HD5770 running 3.17.4-1-ck. Both Mesa and X are in the last stable version (I use Arch). Nov 30 14:49:32 boreal kernel: [drm] PCIE GART of 1024M enabled (table at 0x0025D000). Nov 30 14:49:32 boreal kernel: radeon :01:00.0: WB enabled Nov 30 14:49:32 boreal kernel: radeon :01:00.0: fence driver on ring 0 use gpu addr 0x4c00 and cpu addr Nov 30 14:49:32 boreal kernel: radeon :01:00.0: fence driver on ring 3 use gpu addr 0x4c0c and cpu addr Nov 30 14:49:32 boreal kernel: radeon :01:00.0: fence driver on ring 5 use gpu addr 0x0005c418 and cpu addr Nov 30 14:49:32 boreal kernel: [drm:r600_ring_test] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD) Nov 30 14:49:32 boreal kernel: [drm:evergreen_resume] *ERROR* evergreen startup failed on resume -- 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/20141201/3cb50a09/attachment.html>
[PATCH] drm/gma500: add support for atom e6xx lpc lvds i2c
On Fri, Sep 26, 2014 at 10:40 AM, Jan Safrata wrote: > add gpio bitbanging i2c adapter on LPC device of atom e6xx > gpu chipset to access lvds EDID > tested on SECO QuadMo747-E6xx-EXTREME Qseven platform > > Cc: Patrik Jakobsson > Signed-off-by: Jan Safrata > --- > drivers/gpu/drm/gma500/Makefile| 1 + > drivers/gpu/drm/gma500/oaktrail_lvds.c | 31 -- > drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c | 170 > + > drivers/gpu/drm/gma500/psb_drv.c | 20 > drivers/gpu/drm/gma500/psb_drv.h | 3 + > drivers/gpu/drm/gma500/psb_intel_drv.h | 1 + > 6 files changed, 214 insertions(+), 12 deletions(-) > create mode 100644 drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c > > diff --git a/drivers/gpu/drm/gma500/Makefile b/drivers/gpu/drm/gma500/Makefile > index b153155..190e55f 100644 > --- a/drivers/gpu/drm/gma500/Makefile > +++ b/drivers/gpu/drm/gma500/Makefile > @@ -39,6 +39,7 @@ gma500_gfx-$(CONFIG_DRM_GMA3600) += cdv_device.o \ > gma500_gfx-$(CONFIG_DRM_GMA600) += oaktrail_device.o \ > oaktrail_crtc.o \ > oaktrail_lvds.o \ > + oaktrail_lvds_i2c.o \ > oaktrail_hdmi.o \ > oaktrail_hdmi_i2c.o > > diff --git a/drivers/gpu/drm/gma500/oaktrail_lvds.c > b/drivers/gpu/drm/gma500/oaktrail_lvds.c > index 0d39da6..83bbc27 100644 > --- a/drivers/gpu/drm/gma500/oaktrail_lvds.c > +++ b/drivers/gpu/drm/gma500/oaktrail_lvds.c > @@ -359,22 +359,26 @@ void oaktrail_lvds_init(struct drm_device *dev, > *if closed, act like it's not there for now > */ > > + edid = NULL; > mutex_lock(&dev->mode_config.mutex); > i2c_adap = i2c_get_adapter(dev_priv->ops->i2c_bus); > - if (i2c_adap == NULL) > - dev_err(dev->dev, "No ddc adapter available!\n"); > + if (i2c_adap) > + edid = drm_get_edid(connector, i2c_adap); > + if (edid == NULL && dev_priv->lpc_gpio_base) { > + oaktrail_lvds_i2c_init(encoder); > + if (gma_encoder->ddc_bus != NULL) { > + i2c_adap = &gma_encoder->ddc_bus->adapter; > + edid = drm_get_edid(connector, i2c_adap); > + } > + } > /* > * Attempt to get the fixed panel mode from DDC. Assume that the > * preferred mode is the right one. > */ > - if (i2c_adap) { > - edid = drm_get_edid(connector, i2c_adap); > - if (edid) { > - drm_mode_connector_update_edid_property(connector, > - edid); > - drm_add_edid_modes(connector, edid); > - kfree(edid); > - } > + if (edid) { > + drm_mode_connector_update_edid_property(connector, edid); > + drm_add_edid_modes(connector, edid); > + kfree(edid); > > list_for_each_entry(scan, &connector->probed_modes, head) { > if (scan->type & DRM_MODE_TYPE_PREFERRED) { > @@ -383,7 +387,8 @@ void oaktrail_lvds_init(struct drm_device *dev, > goto out; /* FIXME: check for quirks */ > } > } > - } > + } else > + dev_err(dev->dev, "No ddc adapter available!\n"); > /* > * If we didn't get EDID, try geting panel timing > * from configuration data > @@ -411,8 +416,10 @@ failed_find: > mutex_unlock(&dev->mode_config.mutex); > > dev_dbg(dev->dev, "No LVDS modes found, disabling.\n"); > - if (gma_encoder->ddc_bus) > + if (gma_encoder->ddc_bus) { > psb_intel_i2c_destroy(gma_encoder->ddc_bus); > + gma_encoder->ddc_bus = NULL; > + } > > /* failed_ddc: */ > > diff --git a/drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c > b/drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c > new file mode 100644 > index 000..f913a62 > --- /dev/null > +++ b/drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c > @@ -0,0 +1,170 @@ > +/* > + * Copyright (c) 2002-2010, Intel Corporation. > + * Copyright (c) 2014 ATRON electronic GmbH > + * Author: Jan Safrata > + * > + * Permission is hereby granted, free of charge, to any person obtaining a > copy > + * of this software and associated documentation files (the "Software"), to > deal > + * in the Software without restriction, including without limitation the > rights > + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell > + * copies of the Software, and to permit persons to whom the Software is > + * furnished to do so, subject to the following conditions: > + * > + * The above copyright notice and this permission notice shall be included in > + * all copies or substantial portions of the Software. > + * > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
[PATCH v4 1/3] drm: add bus_formats and num_bus_formats fields to drm_display_info
Hi Thierry, On Mon, 1 Dec 2014 16:42:58 +0100 Thierry Reding wrote: > On Mon, Dec 01, 2014 at 09:20:59AM +0100, Boris Brezillon wrote: > > Add bus_formats and num_bus_formats fields and > > drm_display_info_set_bus_formats helper function to specify the bus > > formats supported by a given display. > > > > This information can be used by display controller drivers to configure > > the output interface appropriately (i.e. RGB565, RGB666 or RGB888 on raw > > RGB or LVDS busses). > > > > Signed-off-by: Boris Brezillon > > --- > > drivers/gpu/drm/drm_crtc.c | 32 > > include/drm/drm_crtc.h | 7 +++ > > 2 files changed, 39 insertions(+) > > > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c > > index e79c8d3..d3b7ed0 100644 > > --- a/drivers/gpu/drm/drm_crtc.c > > +++ b/drivers/gpu/drm/drm_crtc.c > > @@ -763,6 +763,38 @@ static void drm_mode_remove(struct drm_connector > > *connector, > > drm_mode_destroy(connector->dev, mode); > > } > > > > +/* > > This needs a /** marker to make it a valid kerneldoc comment. Yep, I'll fix that. > > > + * drm_display_info_set_bus_formats - set the supported bus formats > > + * @info: display info to store bus formats in > > + * @fmts: array containing the supported bus formats > > + * @nfmts: the number of entries in the fmts array > > + * > > + * Store the suppported bus formats in display info structure. > > + * See MEDIA_BUS_FMT_* definitions in > > include/uapi/linux/media-bus-format.h for > > + * a full list of available formats. > > + */ > > +int drm_display_info_set_bus_formats(struct drm_display_info *info, const > > u32 *fmts, > > This one still exceeds 80-characters per line, but perhaps I'm reviewing > the wrong patch? Also I think fmts should be formats here. > > > +unsigned int num_fmts) > > And this should be num_formats, for consistency. Also make sure to keep > this consistent with the kerneldoc. > > > +{ > > + u32 *formats = NULL; > > If you name the parameter formats, maybe bus_formats would be a good > alternative for this local variable. Or fmts here. I think it's most > important that the public API gets the more idiomatic name. Okay, I'll rework the argument and variable names. > > > + > > + if (!fmts && num_fmts) > > + return -EINVAL; > > + > > + if (fmts && num_fmts) { > > + formats = kmemdup(fmts, sizeof(*fmts) * num_fmts, GFP_KERNEL); > > + if (!formats) > > + return -ENOMEM; > > + } > > + > > + kfree(info->bus_formats); > > + info->bus_formats = formats; > > + info->num_bus_formats = num_fmts; > > + > > + return 0; > > +} > > +EXPORT_SYMBOL(drm_display_info_set_bus_formats); > > I think you'll want to call kfree() on the bus_formats array from > drm_connector_cleanup() as well to make sure you don't leak this on > driver unload. Indeed, I'll fix that memory leak. Thanks, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
[PATCH v5 0/3] drm: describe display bus format
Hello, This series makes use of the MEDIA_BUS_FMT definition to describe how the data are transmitted to the display. This will allow drivers to configure their output display bus according to the display capabilities. For example some display controllers support DPI (or raw RGB) connectors and need to specify which format will be transmitted on the DPI bus (RGB444, RGB565, RGB888, ...). This series also adds a field to the panel_desc struct so that one can specify which format is natevely supported by a panel. Regards, Boris Changes since v4: - fix typo - fix 'line over 80 characters' warnings - fix leak of formats array Changes since v3: - store num_bus_formats on an unsigned int - clearly state that fmts argument (in drm_display_info_set_bus_formats function) should be an array of MEDIA_BUS_FMT_* values. Changes since v2: - use the MEDIA_BUS_FMT macros Changes since v1: - rename nformats into num_formats - declare num_formats as an unsigned int Boris Brezillon (3): drm: add bus_formats and num_bus_formats fields to drm_display_info drm: panel: simple-panel: add support for bus_format retrieval drm: panel: simple-panel: add bus format information for foxlink panel drivers/gpu/drm/drm_crtc.c | 35 +++ drivers/gpu/drm/panel/panel-simple.c | 6 ++ include/drm/drm_crtc.h | 8 3 files changed, 49 insertions(+) -- 1.9.1
[PATCH v5 1/3] drm: add bus_formats and num_bus_formats fields to drm_display_info
Add bus_formats and num_bus_formats fields and drm_display_info_set_bus_formats helper function to specify the bus formats supported by a given display. This information can be used by display controller drivers to configure the output interface appropriately (i.e. RGB565, RGB666 or RGB888 on raw RGB or LVDS busses). Signed-off-by: Boris Brezillon Acked-by: Laurent Pinchart Acked-by: Philipp Zabel --- drivers/gpu/drm/drm_crtc.c | 35 +++ include/drm/drm_crtc.h | 8 2 files changed, 43 insertions(+) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index e79c8d3..1295863 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -764,6 +764,40 @@ static void drm_mode_remove(struct drm_connector *connector, } /** + * drm_display_info_set_bus_formats - set the supported bus formats + * @info: display info to store bus formats in + * @fmts: array containing the supported bus formats + * @nfmts: the number of entries in the fmts array + * + * Store the supported bus formats in display info structure. + * See MEDIA_BUS_FMT_* definitions in include/uapi/linux/media-bus-format.h for + * a full list of available formats. + */ +int drm_display_info_set_bus_formats(struct drm_display_info *info, +const u32 *formats, +unsigned int num_formats) +{ + u32 *fmts = NULL; + + if (!formats && num_formats) + return -EINVAL; + + if (formats && num_formats) { + fmts = kmemdup(formats, sizeof(*formats) * num_formats, + GFP_KERNEL); + if (!formats) + return -ENOMEM; + } + + kfree(info->bus_formats); + info->bus_formats = fmts; + info->num_bus_formats = num_formats; + + return 0; +} +EXPORT_SYMBOL(drm_display_info_set_bus_formats); + +/** * drm_connector_get_cmdline_mode - reads the user's cmdline mode * @connector: connector to quwery * @mode: returned mode @@ -914,6 +948,7 @@ void drm_connector_cleanup(struct drm_connector *connector) ida_remove(&drm_connector_enum_list[connector->connector_type].ida, connector->connector_type_id); + kfree(connector->display_info.bus_formats); drm_mode_object_put(dev, &connector->base); kfree(connector->name); connector->name = NULL; diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index c40070a..5d351f5 100644 --- a/include/drm/drm_crtc.h +++ b/include/drm/drm_crtc.h @@ -31,6 +31,7 @@ #include #include #include +#include #include #include #include @@ -130,6 +131,9 @@ struct drm_display_info { enum subpixel_order subpixel_order; u32 color_formats; + const u32 *bus_formats; + unsigned int num_bus_formats; + /* Mask of supported hdmi deep color modes */ u8 edid_hdmi_dc_modes; @@ -982,6 +986,10 @@ extern int drm_mode_connector_set_path_property(struct drm_connector *connector, extern int drm_mode_connector_update_edid_property(struct drm_connector *connector, struct edid *edid); +extern int drm_display_info_set_bus_formats(struct drm_display_info *info, + const u32 *formats, + unsigned int num_formats); + static inline bool drm_property_type_is(struct drm_property *property, uint32_t type) { -- 1.9.1
[PATCH v5 2/3] drm: panel: simple-panel: add support for bus_format retrieval
Provide a way to specify panel requirement in terms of supported media bus format (particularly useful for panels connected to an RGB or LVDS bus). Signed-off-by: Boris Brezillon --- drivers/gpu/drm/panel/panel-simple.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 23de22f..66838a5 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -61,6 +61,8 @@ struct panel_desc { unsigned int disable; unsigned int unprepare; } delay; + + u32 bus_format; }; struct panel_simple { @@ -111,6 +113,9 @@ static int panel_simple_get_fixed_modes(struct panel_simple *panel) connector->display_info.bpc = panel->desc->bpc; connector->display_info.width_mm = panel->desc->size.width; connector->display_info.height_mm = panel->desc->size.height; + if (panel->desc->bus_format) + drm_display_info_set_bus_formats(&connector->display_info, +&panel->desc->bus_format, 1); return num; } -- 1.9.1
[PATCH v5 3/3] drm: panel: simple-panel: add bus format information for foxlink panel
Foxlink's fl500wvr00-a0t supports RGB888 format. Signed-off-by: Boris Brezillon --- drivers/gpu/drm/panel/panel-simple.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 66838a5..695f406 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -545,6 +545,7 @@ static const struct panel_desc foxlink_fl500wvr00_a0t = { .width = 108, .height = 65, }, + .bus_format = MEDIA_BUS_FMT_RGB888_1X24, }; static const struct drm_display_mode innolux_n116bge_mode = { -- 1.9.1
[PATCH] drm/cirrus: fix leaky driver load error handling
On Mon, Nov 17, 2014 at 5:19 PM, Zach Reizner wrote: > Before this patch, cirrus_device_init could have failed while > cirrus_mm_init succeeded and the driver would have reported overall > success on load. This patch causes cirrus_device_init to return on > the first error encountered. > > Reviewed-by: Stéphane Marchesin The code itself looks good, just a few nits with the commit message. I think you mean to s/cirrus_mm_init/cirrus_modeset_init/ and s/cirrus_device_init/cirrus_mm_init/. You should also have a Signed-off-by line (see section 12 of [1]) Sean [1]- https://www.kernel.org/doc/Documentation/SubmittingPatches > --- > drivers/gpu/drm/cirrus/cirrus_main.c | 13 + > 1 file changed, 9 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/cirrus/cirrus_main.c > b/drivers/gpu/drm/cirrus/cirrus_main.c > index 99c1983..ab7cb54 100644 > --- a/drivers/gpu/drm/cirrus/cirrus_main.c > +++ b/drivers/gpu/drm/cirrus/cirrus_main.c > @@ -179,17 +179,22 @@ int cirrus_driver_load(struct drm_device *dev, unsigned > long flags) > } > > r = cirrus_mm_init(cdev); > - if (r) > + if (r) { > dev_err(&dev->pdev->dev, "fatal err on mm init\n"); > + goto out; > + } > > r = cirrus_modeset_init(cdev); > - if (r) > + if (r) { > dev_err(&dev->pdev->dev, "Fatal error during modeset init: > %d\n", r); > + goto out; > + } > > dev->mode_config.funcs = (void *)&cirrus_mode_funcs; > + > + return 0; > out: > - if (r) > - cirrus_driver_unload(dev); > + cirrus_driver_unload(dev); > return r; > } > > -- > 2.1.0.rc2.206.gedb03e5 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC] drm/ttm: dma: Fixes for 32-bit and 64-bit ARM
On Wed, Nov 12, 2014 at 06:03:49PM +0100, Arnd Bergmann wrote: > On Wednesday 12 November 2014 09:18:59 Konrad Rzeszutek Wilk wrote: > > On Wed, Nov 12, 2014 at 01:39:05PM +0100, Thierry Reding wrote: > > > From: Thierry Reding > > > > > > dma_alloc_coherent() returns a kernel virtual address that is part of > > > the linear range. Passing such an address to virt_to_page() is illegal > > > on non-coherent architectures. This causes the kernel to oops on 64-bit > > > ARM because the struct page * obtained from virt_to_page() points to > > > unmapped memory. > > > > Oh! That is not good! > > > I think what Thierry meant is that the returned pointer is /not/ in the > linear range. > > > > Until that time, this temporary fix will allow TTM to work on 32-bit > > > and 64-bit ARM as well, provided that no IOMMU translations are enabled > > > for the GPU. > > > > Is there a way to query the 'struct device' to see if the IOMMU translation > > is enabled/disabled for said device? ? > > > > Now your patch looks to get the 'struct page' by doing some form of > > translation. Could you explain to me which type of memory have a 'struct > > page' > > and which ones do not ? > > > > It is OK if you explain this in nauseating details > > Basically there are two types of memory that have a struct page: > > - directly mapped cacheable memory, i.e. anything that can be accessed > through a kernel pointer without having to go though ioremap/vmalloc/... > > - highmem pages on 32-bit system. > > On noncoherent ARM systems, dma_alloc_coherent will return memory that > is was unmapped from the linear range to avoid having both cacheable and > noncachable mappings for the same page. > > Arnd
[PATCH v2] drm/cirrus: fix leaky driver load error handling
Before this patch, cirrus_mm_init could have failed while cirrus_modeset_init succeeded and the driver would have reported overall success on load. This patch causes cirrus_driver_load to return on the first error encountered. Reviewed-by: Stéphane Marchesin Signed-off-by: Zach Reizner --- drivers/gpu/drm/cirrus/cirrus_main.c | 13 + 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/cirrus/cirrus_main.c b/drivers/gpu/drm/cirrus/cirrus_main.c index 99c1983..ab7cb54 100644 --- a/drivers/gpu/drm/cirrus/cirrus_main.c +++ b/drivers/gpu/drm/cirrus/cirrus_main.c @@ -179,17 +179,22 @@ int cirrus_driver_load(struct drm_device *dev, unsigned long flags) } r = cirrus_mm_init(cdev); - if (r) + if (r) { dev_err(&dev->pdev->dev, "fatal err on mm init\n"); + goto out; + } r = cirrus_modeset_init(cdev); - if (r) + if (r) { dev_err(&dev->pdev->dev, "Fatal error during modeset init: %d\n", r); + goto out; + } dev->mode_config.funcs = (void *)&cirrus_mode_funcs; + + return 0; out: - if (r) - cirrus_driver_unload(dev); + cirrus_driver_unload(dev); return r; } -- 2.2.0.rc0.207.ga3a616c
[PATCH v2] drm/cirrus: fix leaky driver load error handling
On Mon, Dec 1, 2014 at 2:15 PM, Zach Reizner wrote: > Before this patch, cirrus_mm_init could have failed while > cirrus_modeset_init succeeded and the driver would have reported overall > success on load. This patch causes cirrus_driver_load to return on the > first error encountered. > > Reviewed-by: Stéphane Marchesin Thanks for updating this, looks good to me. Reviewed-by: Sean Paul > Signed-off-by: Zach Reizner > --- > drivers/gpu/drm/cirrus/cirrus_main.c | 13 + > 1 file changed, 9 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/cirrus/cirrus_main.c > b/drivers/gpu/drm/cirrus/cirrus_main.c > index 99c1983..ab7cb54 100644 > --- a/drivers/gpu/drm/cirrus/cirrus_main.c > +++ b/drivers/gpu/drm/cirrus/cirrus_main.c > @@ -179,17 +179,22 @@ int cirrus_driver_load(struct drm_device *dev, unsigned > long flags) > } > > r = cirrus_mm_init(cdev); > - if (r) > + if (r) { > dev_err(&dev->pdev->dev, "fatal err on mm init\n"); > + goto out; > + } > > r = cirrus_modeset_init(cdev); > - if (r) > + if (r) { > dev_err(&dev->pdev->dev, "Fatal error during modeset init: > %d\n", r); > + goto out; > + } > > dev->mode_config.funcs = (void *)&cirrus_mode_funcs; > + > + return 0; > out: > - if (r) > - cirrus_driver_unload(dev); > + cirrus_driver_unload(dev); > return r; > } > > -- > 2.2.0.rc0.207.ga3a616c >
[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst
https://bugs.freedesktop.org/show_bug.cgi?id=73338 --- Comment #59 from Alex Deucher --- (In reply to Chernovsky Oleg from comment #58) > Can you elaborate on what each bit of this control register means? Maybe I > just can't into abbreviations :) TMIN - temp at which the fan would be turned on FDO_PWM_MODE - which PWM mode to use: 0 - static PWM based on fuse value 1 - static PWM based on CG_FDO_CTRL0.FDO_STATIC_DUTY value 2 - dynamic PWM 5 - static PWM based on RPM CG_TACH_CTRL.TARGET_PERIOD value TACH_PWM_RESP_RATE - amount to adjust PWM in tach mode As far as I know, only values 1 and 5 are used for FDO_PWM_MODE in the driver for manual control. I'm not sure what dynamic PWM (2) means or how it works. It might be used by the smc for fan control. I also noticed a minor error in the RPM control setup, and I've pushed a patch to my 3.19-wip branch. -- 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/20141201/c44f85a3/attachment.html>
[PATCH 01/10] drm: add helper to get crtc timings (v5)
From: Gustavo Padovan We need to get hdisplay and vdisplay in a few places so create a helper to make our job easier. Note that drm_crtc_check_viewport() and intel_modeset_pipe_config() were previously making adjustments for doublescan modes and vscan > 1 modes, which was incorrect. Using our new helper fixes this mistake. v2 (by Matt): Use new stereo doubling function (suggested by Ville) v3 (by Matt): - Add missing kerneldoc (Daniel) - Use drm_mode_copy() (Jani) v4 (by Matt): - Drop stereo doubling function again; add 'stereo only' flag to drm_mode_set_crtcinfo() instead (Ville) v5 (by Matt): - Note behavioral change in drm_crtc_check_viewport() and intel_modeset_pipe_config(). (Ander) - Describe new adjustment flags in drm_mode_set_crtcinfo()'s kerneldoc. (Ander) Cc: dri-devel at lists.freedesktop.org Suggested-by: Ville Syrjälä Signed-off-by: Gustavo Padovan Signed-off-by: Matt Roper --- drivers/gpu/drm/drm_crtc.c | 32 ++-- drivers/gpu/drm/drm_modes.c | 26 -- drivers/gpu/drm/i915/intel_display.c | 6 +++--- include/drm/drm_crtc.h | 2 ++ include/drm/drm_modes.h | 3 +++ 5 files changed, 46 insertions(+), 23 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index de79283..2985e3f 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -2550,6 +2550,27 @@ int drm_mode_set_config_internal(struct drm_mode_set *set) EXPORT_SYMBOL(drm_mode_set_config_internal); /** + * drm_crtc_get_hv_timing - Fetches hdisplay/vdisplay for given mode + * @mode: mode to query + * @hdisplay: hdisplay value to fill in + * @vdisplay: vdisplay value to fill in + * + * The vdisplay value will be doubled if the specified mode is a stereo mode of + * the appropriate layout. + */ +void drm_crtc_get_hv_timing(const struct drm_display_mode *mode, + int *hdisplay, int *vdisplay) +{ + struct drm_display_mode adjusted; + + drm_mode_copy(&adjusted, mode); + drm_mode_set_crtcinfo(&adjusted, CRTC_STEREO_DOUBLE_ONLY); + *hdisplay = adjusted.crtc_hdisplay; + *vdisplay = adjusted.crtc_vdisplay; +} +EXPORT_SYMBOL(drm_crtc_get_hv_timing); + +/** * drm_crtc_check_viewport - Checks that a framebuffer is big enough for the * CRTC viewport * @crtc: CRTC that framebuffer will be displayed on @@ -2566,16 +2587,7 @@ int drm_crtc_check_viewport(const struct drm_crtc *crtc, { int hdisplay, vdisplay; - hdisplay = mode->hdisplay; - vdisplay = mode->vdisplay; - - if (drm_mode_is_stereo(mode)) { - struct drm_display_mode adjusted = *mode; - - drm_mode_set_crtcinfo(&adjusted, CRTC_STEREO_DOUBLE); - hdisplay = adjusted.crtc_hdisplay; - vdisplay = adjusted.crtc_vdisplay; - } + drm_crtc_get_hv_timing(mode, &hdisplay, &vdisplay); if (crtc->invert_dimensions) swap(hdisplay, vdisplay); diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index 6d8b941..7689c14 100644 --- a/drivers/gpu/drm/drm_modes.c +++ b/drivers/gpu/drm/drm_modes.c @@ -739,6 +739,8 @@ EXPORT_SYMBOL(drm_mode_vrefresh); * - The CRTC_STEREO_DOUBLE flag can be used to compute the timings for * buffers containing two eyes (only adjust the timings when needed, eg. for * "frame packing" or "side by side full"). + * - The CRTC_NO_DBLSCAN and CRTC_NO_VSCAN flags request that adjustment *not* + * be performed for doublescan and vscan > 1 modes respectively. */ void drm_mode_set_crtcinfo(struct drm_display_mode *p, int adjust_flags) { @@ -765,18 +767,22 @@ void drm_mode_set_crtcinfo(struct drm_display_mode *p, int adjust_flags) } } - if (p->flags & DRM_MODE_FLAG_DBLSCAN) { - p->crtc_vdisplay *= 2; - p->crtc_vsync_start *= 2; - p->crtc_vsync_end *= 2; - p->crtc_vtotal *= 2; + if (!(adjust_flags & CRTC_NO_DBLSCAN)) { + if (p->flags & DRM_MODE_FLAG_DBLSCAN) { + p->crtc_vdisplay *= 2; + p->crtc_vsync_start *= 2; + p->crtc_vsync_end *= 2; + p->crtc_vtotal *= 2; + } } - if (p->vscan > 1) { - p->crtc_vdisplay *= p->vscan; - p->crtc_vsync_start *= p->vscan; - p->crtc_vsync_end *= p->vscan; - p->crtc_vtotal *= p->vscan; + if (!(adjust_flags & CRTC_NO_VSCAN)) { + if (p->vscan > 1) { + p->crtc_vdisplay *= p->vscan; + p->crtc_vsync_start *= p->vscan; + p->crtc_vsync_end *= p->vscan; + p->crtc_vtotal *= p->vscan; + } } if (adjust_flags & CRTC_STEREO_DOUBLE) { diff --git a/drivers/gpu/drm/i915/intel_display.
[PATCH v14 10/12] drm: bridge/dw_hdmi: add function dw_hdmi_phy_enable_spare
RK3288 HDMI will not work without the spare bit of HDMI_PHY_CONF0 enable Signed-off-by: Andy Yan --- Changes in v14: None Changes in v13: None Changes in v12: None Changes in v11: None Changes in v10: None Changes in v9: None Changes in v8: None Changes in v7: None Changes in v6: None Changes in v5: None Changes in v4: None Changes in v3: None drivers/gpu/drm/bridge/dw_hdmi.c | 7 +++ drivers/gpu/drm/bridge/dw_hdmi.h | 3 ++- 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c index 5be643c..df52347 100644 --- a/drivers/gpu/drm/bridge/dw_hdmi.c +++ b/drivers/gpu/drm/bridge/dw_hdmi.c @@ -715,6 +715,13 @@ static void dw_hdmi_phy_enable_tmds(struct dw_hdmi *hdmi, u8 enable) HDMI_PHY_CONF0_ENTMDS_MASK); } +static void dw_hdmi_phy_enable_spare(struct dw_hdmi *hdmi, u8 enable) +{ + hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0, +HDMI_PHY_CONF0_SPARECTRL_OFFSET, +HDMI_PHY_CONF0_SPARECTRL_MASK); +} + static void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable) { hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0, diff --git a/drivers/gpu/drm/bridge/dw_hdmi.h b/drivers/gpu/drm/bridge/dw_hdmi.h index baa7849..175dbc8 100644 --- a/drivers/gpu/drm/bridge/dw_hdmi.h +++ b/drivers/gpu/drm/bridge/dw_hdmi.h @@ -837,7 +837,8 @@ enum { HDMI_PHY_CONF0_PDZ_OFFSET = 7, HDMI_PHY_CONF0_ENTMDS_MASK = 0x40, HDMI_PHY_CONF0_ENTMDS_OFFSET = 6, - HDMI_PHY_CONF0_SPARECTRL = 0x20, + HDMI_PHY_CONF0_SPARECTRL_MASK = 0x20, + HDMI_PHY_CONF0_SPARECTRL_OFFSET = 5, HDMI_PHY_CONF0_GEN2_PDDQ_MASK = 0x10, HDMI_PHY_CONF0_GEN2_PDDQ_OFFSET = 4, HDMI_PHY_CONF0_GEN2_TXPWRON_MASK = 0x8, -- 1.9.1
[PATCH v14 11/12] dt-bindings: Add documentation for rockchip dw hdmi
Signed-off-by: Andy Yan --- Changes in v14: None Changes in v13: None Changes in v12: None Changes in v11: None Changes in v10: None Changes in v9: None Changes in v8: - Add documentation for rockchip dw hdmi Changes in v7: None Changes in v6: None Changes in v5: None Changes in v4: None Changes in v3: None .../devicetree/bindings/video/dw_hdmi-rockchip.txt | 43 ++ 1 file changed, 43 insertions(+) create mode 100644 Documentation/devicetree/bindings/video/dw_hdmi-rockchip.txt diff --git a/Documentation/devicetree/bindings/video/dw_hdmi-rockchip.txt b/Documentation/devicetree/bindings/video/dw_hdmi-rockchip.txt new file mode 100644 index 000..0735464 --- /dev/null +++ b/Documentation/devicetree/bindings/video/dw_hdmi-rockchip.txt @@ -0,0 +1,43 @@ +Rockchip specific extensions to the Synopsys Designware HDMI + + +Required properties: +- compatible: "rockchip,rk3288-dw-hdmi"; +- reg: Physical base address and length of the controller's registers. +- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing +- clocks: from common clock binding: handle to hdmi clock. +- clock-names: should be "clk" "hdcp_clk" +- rockchip,grf: this soc should set GRF regs to mux vopl/vopb. +- interrupts: HDMI interrupt number +- ports: contain a port node with endpoint definitions as defined in + Documentation/devicetree/bindings/media/video-interfaces.txt. For + vopb,set the reg = <0> and set the reg = <1> for vopl. +- reg-io-width: the width of the reg:1,4, the value should be 4 on + rk3288 platform + +Example: +hdmi: hdmi at ff98 { + compatible = "rockchip,rk3288-dw-hdmi"; + reg = <0xff98 0x2>; + reg-io-width = <4>; + ddc-i2c-bus = <&i2c5>; + rockchip,grf = <&grf>; + interrupts = ; + clocks = <&cru PCLK_HDMI_CTRL>, <&cru SCLK_HDMI_HDCP>; + clock-names = "clk", "hdcp_clk"; + status = "disabled"; + ports { + hdmi_in: port { + #address-cells = <1>; + #size-cells = <0>; + hdmi_in_vopb: endpoint at 0 { + reg = <0>; + remote-endpoint = <&vopb_out_hdmi>; + }; + hdmi_in_vopl: endpoint at 1 { + reg = <1>; + remote-endpoint = <&vopl_out_hdmi>; + }; + }; + }; +}; -- 1.9.1
[PATCH v14 12/12] drm: bridge/dw_hdmi: add rockchip rk3288 support
Rockchip RK3288 hdmi is compatible with dw_hdmi this patch is depend on patch by Mark Yao Add drm driver for Rockchip Socs see https://lkml.org/lkml/2014/11/19/1153 Signed-off-by: Andy Yan --- Changes in v14: None Changes in v13: None Changes in v12: - add comment for the depend on patch Changes in v11: None Changes in v10: - add more display mode support mpll configuration for rk3288 Changes in v9: - move some phy configuration to platform driver Changes in v8: None Changes in v7: None Changes in v6: None Changes in v5: None Changes in v4: None Changes in v3: None drivers/gpu/drm/bridge/dw_hdmi.c| 3 + drivers/gpu/drm/rockchip/Kconfig| 10 + drivers/gpu/drm/rockchip/Makefile | 2 +- drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 355 include/drm/bridge/dw_hdmi.h| 1 + 5 files changed, 370 insertions(+), 1 deletion(-) create mode 100644 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c index df52347..326bffb 100644 --- a/drivers/gpu/drm/bridge/dw_hdmi.c +++ b/drivers/gpu/drm/bridge/dw_hdmi.c @@ -853,6 +853,9 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, unsigned char prep, dw_hdmi_phy_gen2_txpwron(hdmi, 1); dw_hdmi_phy_gen2_pddq(hdmi, 0); + if (hdmi->dev_type == RK3288_HDMI) + dw_hdmi_phy_enable_spare(hdmi, 1); + /*Wait for PHY PLL lock */ msec = 5; do { diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig index 0ff6682..06371ae 100644 --- a/drivers/gpu/drm/rockchip/Kconfig +++ b/drivers/gpu/drm/rockchip/Kconfig @@ -15,3 +15,13 @@ config DRM_ROCKCHIP management to userspace. This driver does not provide 2D or 3D acceleration; acceleration is performed by other IP found on the SoC. + +config ROCKCHIP_DW_HDMI +bool "Rockchip specific extensions for Synopsys DW HDMI" +depends on DRM_ROCKCHIP +select DRM_DW_HDMI +help + This selects support for Rockchip SoC specific extensions + for the Synopsys DesignWare HDMI driver. If you want to + enable HDMI on RK3288 based SoC, you should selet this + option. diff --git a/drivers/gpu/drm/rockchip/Makefile b/drivers/gpu/drm/rockchip/Makefile index b3a5193..347e65c 100644 --- a/drivers/gpu/drm/rockchip/Makefile +++ b/drivers/gpu/drm/rockchip/Makefile @@ -4,5 +4,5 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o rockchip_drm_fbdev.o \ rockchip_drm_gem.o rockchip_drm_vop.o - +rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c new file mode 100644 index 000..16cad75 --- /dev/null +++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c @@ -0,0 +1,355 @@ +/* + * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "rockchip_drm_drv.h" +#include "rockchip_drm_vop.h" + +#define GRF_SOC_CON60x025c +#define HDMI_SEL_VOP_LIT(1 << 4) + +struct rockchip_hdmi { + struct device *dev; + struct clk *clk; + struct clk *hdcp_clk; + struct regmap *regmap; + struct drm_encoder encoder; +}; + +#define to_rockchip_hdmi(x)container_of(x, struct rockchip_hdmi, x) + +static const struct mpll_config rockchip_mpll_cfg[] = { + { + 2700, { + { 0x00b3, 0x}, + { 0x2153, 0x}, + { 0x40f3, 0x} + }, + }, { + 3600, { + { 0x00b3, 0x}, + { 0x2153, 0x}, + { 0x40f3, 0x} + }, + }, { + 4000, { + { 0x00b3, 0x}, + { 0x2153, 0x}, + { 0x40f3, 0x} + }, + }, { + 5400, { + { 0x0072, 0x0001}, + { 0x2142, 0x0001}, + { 0x40a2, 0x0001}, + }, + }, { + 6500, { + { 0x0072, 0x0001}, + { 0x2142, 0x0001}, + { 0x40a2, 0x0001}, + }, + }, { + 6600, { + { 0x013e, 0x0003}, + { 0x217e, 0x0002}, + {
[PATCH 1/4] drm/msm/hdmi: use HPD interrupt to track connector status change
HPD interrupt can be tracked for each connector, so don't need to poll the connector status for state change. Signed-off-by: Jilai Wang --- drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c index 4aca2a3..92fddd8 100644 --- a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c +++ b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c @@ -242,7 +242,7 @@ hotplug_work(struct work_struct *work) struct hdmi_connector *hdmi_connector = container_of(work, struct hdmi_connector, hpd_work); struct drm_connector *connector = &hdmi_connector->base; - drm_helper_hpd_irq_event(connector->dev); + drm_kms_helper_hotplug_event(connector->dev); } void hdmi_connector_irq(struct drm_connector *connector) @@ -431,9 +431,6 @@ struct drm_connector *hdmi_connector_init(struct hdmi *hdmi) DRM_MODE_CONNECTOR_HDMIA); drm_connector_helper_add(connector, &hdmi_connector_helper_funcs); - connector->polled = DRM_CONNECTOR_POLL_CONNECT | - DRM_CONNECTOR_POLL_DISCONNECT; - connector->interlace_allowed = 1; connector->doublescan_allowed = 0; -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH 2/4] drm/msm/hdmi: enable regulators before clocks to avoid warnings
HPD regulators need to be enabled before clocks, otherwise clock driver will report warning. Signed-off-by: Jilai Wang --- drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 45 +-- 1 file changed, 18 insertions(+), 27 deletions(-) diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c index 92fddd8..caa1301 100644 --- a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c +++ b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c @@ -141,6 +141,15 @@ static int hpd_enable(struct hdmi_connector *hdmi_connector) uint32_t hpd_ctrl; int i, ret; + for (i = 0; i < config->hpd_reg_cnt; i++) { + ret = regulator_enable(hdmi->hpd_regs[i]); + if (ret) { + dev_err(dev->dev, "failed to enable hpd regulator: %s (%d)\n", + config->hpd_reg_names[i], ret); + goto fail; + } + } + ret = gpio_config(hdmi, true); if (ret) { dev_err(dev->dev, "failed to configure GPIOs: %d\n", ret); @@ -164,15 +173,6 @@ static int hpd_enable(struct hdmi_connector *hdmi_connector) } } - for (i = 0; i < config->hpd_reg_cnt; i++) { - ret = regulator_enable(hdmi->hpd_regs[i]); - if (ret) { - dev_err(dev->dev, "failed to enable hpd regulator: %s (%d)\n", - config->hpd_reg_names[i], ret); - goto fail; - } - } - hdmi_set_mode(hdmi, false); phy->funcs->reset(phy); hdmi_set_mode(hdmi, true); @@ -200,7 +200,7 @@ fail: return ret; } -static int hdp_disable(struct hdmi_connector *hdmi_connector) +static void hdp_disable(struct hdmi_connector *hdmi_connector) { struct hdmi *hdmi = hdmi_connector->hdmi; const struct hdmi_platform_config *config = hdmi->config; @@ -212,28 +212,19 @@ static int hdp_disable(struct hdmi_connector *hdmi_connector) hdmi_set_mode(hdmi, false); - for (i = 0; i < config->hpd_reg_cnt; i++) { - ret = regulator_disable(hdmi->hpd_regs[i]); - if (ret) { - dev_err(dev->dev, "failed to disable hpd regulator: %s (%d)\n", - config->hpd_reg_names[i], ret); - goto fail; - } - } - for (i = 0; i < config->hpd_clk_cnt; i++) clk_disable_unprepare(hdmi->hpd_clks[i]); ret = gpio_config(hdmi, false); - if (ret) { - dev_err(dev->dev, "failed to unconfigure GPIOs: %d\n", ret); - goto fail; - } - - return 0; + if (ret) + dev_warn(dev->dev, "failed to unconfigure GPIOs: %d\n", ret); -fail: - return ret; + for (i = 0; i < config->hpd_reg_cnt; i++) { + ret = regulator_disable(hdmi->hpd_regs[i]); + if (ret) + dev_warn(dev->dev, "failed to disable hpd regulator: %s (%d)\n", + config->hpd_reg_names[i], ret); + } } static void -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH] rnndb: Add register fields for msm/hdmi HDCP support
This patch adds the field description for HDMI HDCP registers. Signed-off-by: Jilai Wang --- rnndb/hdmi/hdmi.xml | 46 -- 1 file changed, 40 insertions(+), 6 deletions(-) diff --git a/rnndb/hdmi/hdmi.xml b/rnndb/hdmi/hdmi.xml index 64393b4..c67e6c1 100644 --- a/rnndb/hdmi/hdmi.xml +++ b/rnndb/hdmi/hdmi.xml @@ -12,12 +12,14 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ rules-ng.xsd"> - - - - - - + + + + + + + + @@ -168,15 +170,39 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ rules-ng.xsd"> + + + + + + + + + + + + + + + + + + + + + + + + @@ -319,6 +345,11 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ rules-ng.xsd"> + + + + + @@ -374,6 +405,9 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ rules-ng.xsd"> + + + -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH V2] drm/exynos: Add DECON driver
Hi Ajay, On 28 November 2014 at 16:45, Ajay Kumar wrote: > This series is based on exynos-drm-next branch of Inki Dae's tree at: > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git > > DECON(Display and Enhancement Controller) is the new IP > in exynos7 SOC for generating video signals using pixel data. > > DECON driver can be used to drive 2 different interfaces on Exynos7: > DECON-INT(video controller) and DECON-EXT(Mixer for HDMI) > > The existing FIMD driver code was used as a template to create > DECON driver. Only DECON-INT is supported as of now, and > DECON-EXT support will be added later. > > Signed-off-by: Akshu Agrawal > Signed-off-by: Ajay Kumar > --- > Changes since V1: > -- Address comments from Pankaj and do few cleanups. > Thanks, but still I can see this needs modification, please see my comments: > .../devicetree/bindings/video/exynos7-decon.txt| 67 ++ > drivers/gpu/drm/exynos/Kconfig | 13 +- > drivers/gpu/drm/exynos/Makefile|1 + > drivers/gpu/drm/exynos/exynos7_drm_decon.c | 1037 > > drivers/gpu/drm/exynos/exynos_drm_drv.c|4 + > drivers/gpu/drm/exynos/exynos_drm_drv.h|1 + > include/video/exynos7_decon.h | 346 +++ > 7 files changed, 1466 insertions(+), 3 deletions(-) > create mode 100644 Documentation/devicetree/bindings/video/exynos7-decon.txt > create mode 100644 drivers/gpu/drm/exynos/exynos7_drm_decon.c > create mode 100644 include/video/exynos7_decon.h > [snip] > +static int decon_mgr_initialize(struct exynos_drm_manager *mgr, > + struct drm_device *drm_dev) > +{ > + struct decon_context *ctx = mgr_to_decon(mgr); > + struct exynos_drm_private *priv = drm_dev->dev_private; > + int ret; > + > + mgr->drm_dev = drm_dev; > + mgr->pipe = ctx->pipe = priv->pipe++; > + Do we really need 'pipe' in exynos_drm_manager and decon_context both? > + /* attach this sub driver to iommu mapping if supported. */ > + if (is_drm_iommu_supported(mgr->drm_dev)) { [snip] > +static void decon_win_mode_set(struct exynos_drm_manager *mgr, > + struct exynos_drm_overlay *overlay) > +{ > + struct decon_context *ctx = mgr_to_decon(mgr); > + struct decon_win_data *win_data; > + int win, padding; > + > + if (!overlay) { > + DRM_ERROR("overlay is NULL\n"); > + return; > + } > + > + win = overlay->zpos; > + if (win == DEFAULT_ZPOS) > + win = ctx->default_win; > + > + if (win < 0 || win >= WINDOWS_NR) > + return; > + > + > + win_data = &ctx->win_data[win]; > + As I mentioned in V1, since these 5 lines are getting repeating better we move it in one static function. It will help in reducing code footprint. [snip] > + > +/** > + * shadow_protect_win() - disable updating values from shadow registers at > vsync > + * > + * @win: window to protect registers for > + * @protect: 1 to protect (disable updates) > + */ > +static void decon_shadow_protect_win(struct decon_context *ctx, > + int win, bool protect) > +{ > + u32 reg, bits, val; > + > + reg = SHADOWCON; How about using SHADOWCON directly instead of using local variable? > + bits = SHADOWCON_WINx_PROTECT(win); > + > + val = readl(ctx->regs + reg); > + if (protect) > + val |= bits; > + else > + val &= ~bits; > + writel(val, ctx->regs + reg); > +} > + > +static void decon_win_commit(struct exynos_drm_manager *mgr, int zpos) > +{ > + struct decon_context *ctx = mgr_to_decon(mgr); > + struct decon_win_data *win_data; > + int win = zpos; > + unsigned long val, alpha, blendeq; > + unsigned int last_x; > + unsigned int last_y; > + > + if (ctx->suspended) > + return; > + > + if (win == DEFAULT_ZPOS) > + win = ctx->default_win; > + > + if (win < 0 || win >= WINDOWS_NR) > + return; > + > + win_data = &ctx->win_data[win]; > + > + /* If suspended, enable this on resume */ > + if (ctx->suspended) { > + win_data->resume = true; > + return; > + } > + > + /* [snip] > +static int decon_probe(struct platform_device *pdev) > +{ > + struct device *dev = &pdev->dev; > + struct decon_context *ctx; > + struct resource *res; > + int ret = -EINVAL; > + > + if (!dev->of_node) > + return -ENODEV; > + > + ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL); > + if (!ctx) > + return -ENOMEM; > + > + ctx->manager.type = EXYNOS_DISPLAY_TYPE_LCD; > + ctx->manager.ops = &decon_manager_ops; > + > + ret = exynos_drm_component_add(dev, EXYNOS_DEVICE_TYPE_CRTC,
[PATCH v14 0/12] dw-hdmi: convert imx hdmi to bridge/dw_hdmi
We found Freescale imx6 and Rockchip rk3288 and Ingenic JZ4780 (Xburst/MIPS) use the interface compatible Designware HDMI IP, but they also have some lightly differences, such as phy pll configuration, register width(imx hdmi register is one byte, but rk3288 is 4 bytes width and can only be accessed by word), 4K support(imx6 doesn't support 4k, but rk3288 does), and HDMI2.0 support. To reuse the imx-hdmi driver, we make this patch set: (1): fix some CodingStyle warning to make checkpatch happy (2): convert imx-hdmi to drm_bridge (3): split platform specific code (4): move imx-hdmi to bridge/dw_hdmi (5): extend dw_hdmi.c to support rk3288 hdmi (6): add rockchip rk3288 platform specific code dw_hdmi-rockchip.c Changes in v14: - add defer probing, adviced by Philipp Zabel - remove drm_connector_register, because imx-drm core has registered connector Changes in v13: - patch against drm-next - split platform specific phy configuration - split phy configuration from patch#4 Changes in v12: - refactor of_node_put(ddc_node) - squash patch - add comment for the depend on patch Changes in v11: - squash patch Changes in v10: - split generic dw_hdmi.c improvements from patch#11 (add rk3288 support) - add more display mode support mpll configuration for rk3288 Changes in v9: - move some phy configuration to platform driver Changes in v8: - correct some spelling mistake - modify ddc-i2c-bus and interrupt description - Add documentation for rockchip dw hdmi Changes in v7: - remove unused variables from structure dw_hdmi - remove a wrong modification - add copyrights for dw_hdmi-imx.c Changes in v6: - rearrange the patch order - refactor register access without reg_shift Changes in v5: - refactor reg-io-width Changes in v4: - fix checkpatch CHECK - defer probe ddc i2c adapter Changes in v3: - split multi-register access to one indepent patch Andy Yan (12): drm: imx: imx-hdmi: make checkpatch happy drm: imx: imx-hdmi: return defer if can't get ddc i2c adapter drm: imx: imx-hdmi: convert imx-hdmi to drm_bridge mode drm: imx: imx-hdmi: split phy configuration to platform driver drm: imx: imx-hdmi: move imx-hdmi to bridge/dw_hdmi dt-bindings: add document for dw_hdmi drm: bridge/dw_hdmi: add support for multi-byte register width access drm: bridge/dw_hdmi: add mode_valid support drm: bridge/dw_hdmi: clear i2cmphy_stat0 reg in hdmi_phy_wait_i2c_done drm: bridge/dw_hdmi: add function dw_hdmi_phy_enable_spare dt-bindings: Add documentation for rockchip dw hdmi drm: bridge/dw_hdmi: add rockchip rk3288 support .../devicetree/bindings/drm/bridge/dw_hdmi.txt | 40 ++ .../devicetree/bindings/video/dw_hdmi-rockchip.txt | 43 ++ drivers/gpu/drm/bridge/Kconfig | 5 + drivers/gpu/drm/bridge/Makefile| 1 + .../gpu/drm/{imx/imx-hdmi.c => bridge/dw_hdmi.c} | 755 + .../gpu/drm/{imx/imx-hdmi.h => bridge/dw_hdmi.h} | 4 +- drivers/gpu/drm/imx/Kconfig| 1 + drivers/gpu/drm/imx/Makefile | 2 +- drivers/gpu/drm/imx/dw_hdmi-imx.c | 281 drivers/gpu/drm/rockchip/Kconfig | 10 + drivers/gpu/drm/rockchip/Makefile | 2 +- drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c| 355 ++ include/drm/bridge/dw_hdmi.h | 60 ++ 13 files changed, 1138 insertions(+), 421 deletions(-) create mode 100644 Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt create mode 100644 Documentation/devicetree/bindings/video/dw_hdmi-rockchip.txt rename drivers/gpu/drm/{imx/imx-hdmi.c => bridge/dw_hdmi.c} (71%) rename drivers/gpu/drm/{imx/imx-hdmi.h => bridge/dw_hdmi.h} (99%) create mode 100644 drivers/gpu/drm/imx/dw_hdmi-imx.c create mode 100644 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c create mode 100644 include/drm/bridge/dw_hdmi.h -- 1.9.1
[PATCH v14 01/12] drm: imx: imx-hdmi: make checkpatch happy
CHECK: Alignment should match open parenthesis + if ((hdmi->vic == 10) || (hdmi->vic == 11) || + (hdmi->vic == 12) || (hdmi->vic == 13) || CHECK: braces {} should be used on all arms of this statement + if (hdmi->hdmi_data.video_mode.mdvi) [...] + else { [...] Signed-off-by: Andy Yan Reviewed-by: Daniel Kurtz --- Changes in v14: None Changes in v13: - patch against drm-next Changes in v12: None Changes in v11: None Changes in v10: None Changes in v9: None Changes in v8: None Changes in v7: None Changes in v6: - rearrange the patch order Changes in v5: None Changes in v4: - fix checkpatch CHECK Changes in v3: None drivers/gpu/drm/imx/imx-hdmi.c | 97 +- 1 file changed, 48 insertions(+), 49 deletions(-) diff --git a/drivers/gpu/drm/imx/imx-hdmi.c b/drivers/gpu/drm/imx/imx-hdmi.c index aaec6b2..79daec4 100644 --- a/drivers/gpu/drm/imx/imx-hdmi.c +++ b/drivers/gpu/drm/imx/imx-hdmi.c @@ -163,7 +163,7 @@ static void hdmi_modb(struct imx_hdmi *hdmi, u8 data, u8 mask, unsigned reg) } static void hdmi_mask_writeb(struct imx_hdmi *hdmi, u8 data, unsigned int reg, - u8 shift, u8 mask) +u8 shift, u8 mask) { hdmi_modb(hdmi, data << shift, mask, reg); } @@ -327,7 +327,7 @@ static unsigned int hdmi_compute_cts(unsigned int freq, unsigned long pixel_clk, } static void hdmi_set_clk_regenerator(struct imx_hdmi *hdmi, - unsigned long pixel_clk) +unsigned long pixel_clk) { unsigned int clk_n, clk_cts; @@ -338,7 +338,7 @@ static void hdmi_set_clk_regenerator(struct imx_hdmi *hdmi, if (!clk_cts) { dev_dbg(hdmi->dev, "%s: pixel clock not supported: %lu\n", -__func__, pixel_clk); + __func__, pixel_clk); return; } @@ -477,13 +477,11 @@ static void imx_hdmi_update_csc_coeffs(struct imx_hdmi *hdmi) u16 coeff_b = (*csc_coeff)[1][i]; u16 coeff_c = (*csc_coeff)[2][i]; - hdmi_writeb(hdmi, coeff_a & 0xff, - HDMI_CSC_COEF_A1_LSB + i * 2); + hdmi_writeb(hdmi, coeff_a & 0xff, HDMI_CSC_COEF_A1_LSB + i * 2); hdmi_writeb(hdmi, coeff_a >> 8, HDMI_CSC_COEF_A1_MSB + i * 2); hdmi_writeb(hdmi, coeff_b & 0xff, HDMI_CSC_COEF_B1_LSB + i * 2); hdmi_writeb(hdmi, coeff_b >> 8, HDMI_CSC_COEF_B1_MSB + i * 2); - hdmi_writeb(hdmi, coeff_c & 0xff, - HDMI_CSC_COEF_C1_LSB + i * 2); + hdmi_writeb(hdmi, coeff_c & 0xff, HDMI_CSC_COEF_C1_LSB + i * 2); hdmi_writeb(hdmi, coeff_c >> 8, HDMI_CSC_COEF_C1_MSB + i * 2); } @@ -535,21 +533,22 @@ static void hdmi_video_packetize(struct imx_hdmi *hdmi) struct hdmi_data_info *hdmi_data = &hdmi->hdmi_data; u8 val, vp_conf; - if (hdmi_data->enc_out_format == RGB - || hdmi_data->enc_out_format == YCBCR444) { - if (!hdmi_data->enc_color_depth) + if (hdmi_data->enc_out_format == RGB || + hdmi_data->enc_out_format == YCBCR444) { + if (!hdmi_data->enc_color_depth) { output_select = HDMI_VP_CONF_OUTPUT_SELECTOR_BYPASS; - else if (hdmi_data->enc_color_depth == 8) { + } else if (hdmi_data->enc_color_depth == 8) { color_depth = 4; output_select = HDMI_VP_CONF_OUTPUT_SELECTOR_BYPASS; - } else if (hdmi_data->enc_color_depth == 10) + } else if (hdmi_data->enc_color_depth == 10) { color_depth = 5; - else if (hdmi_data->enc_color_depth == 12) + } else if (hdmi_data->enc_color_depth == 12) { color_depth = 6; - else if (hdmi_data->enc_color_depth == 16) + } else if (hdmi_data->enc_color_depth == 16) { color_depth = 7; - else + } else { return; + } } else if (hdmi_data->enc_out_format == YCBCR422_8BITS) { if (!hdmi_data->enc_color_depth || hdmi_data->enc_color_depth == 8) @@ -561,8 +560,9 @@ static void hdmi_video_packetize(struct imx_hdmi *hdmi) else return; output_select = HDMI_VP_CONF_OUTPUT_SELECTOR_YCC422; - } else + } else { return; + } /* set the packetizer registers */ val = ((color_depth << HDMI_VP_PR_CD_COLOR_DEPTH_OFFSET) & @@ -623,34 +623,34 @@ static void hdmi_video_packetize(struct imx_hdmi *hdmi) } static inline void hdmi_phy_test_clear(struct imx_hdmi *hdmi, - unsigned char bit) + unsigned char bit) {
[PATCH v14 02/12] drm: imx: imx-hdmi: return defer if can't get ddc i2c adapter
drm driver may probe before the i2c bus, so the driver should defer probing until it is available Signed-off-by: Andy Yan Reviewed-by: Daniel Kurtz --- Changes in v14: None Changes in v13: None Changes in v12: - refactor of_node_put(ddc_node) Changes in v11: None Changes in v10: None Changes in v9: None Changes in v8: None Changes in v7: None Changes in v6: None Changes in v5: None Changes in v4: - defer probe ddc i2c adapter Changes in v3: None drivers/gpu/drm/imx/imx-hdmi.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/imx/imx-hdmi.c b/drivers/gpu/drm/imx/imx-hdmi.c index 79daec4..8029a07 100644 --- a/drivers/gpu/drm/imx/imx-hdmi.c +++ b/drivers/gpu/drm/imx/imx-hdmi.c @@ -1611,10 +1611,12 @@ static int imx_hdmi_bind(struct device *dev, struct device *master, void *data) ddc_node = of_parse_phandle(np, "ddc-i2c-bus", 0); if (ddc_node) { hdmi->ddc = of_find_i2c_adapter_by_node(ddc_node); - if (!hdmi->ddc) + of_node_put(ddc_node); + if (!hdmi->ddc) { dev_dbg(hdmi->dev, "failed to read ddc node\n"); + return -EPROBE_DEFER; + } - of_node_put(ddc_node); } else { dev_dbg(hdmi->dev, "no ddc property found\n"); } -- 1.9.1
[PATCH v14 03/12] drm: imx: imx-hdmi: convert imx-hdmi to drm_bridge mode
IMX6 and Rockchip RK3288 and JZ4780 (Ingenic Xburst/MIPS) use the interface compatible Designware HDMI IP, but they also have some lightly differences, such as phy pll configuration, register width, 4K support, clk useage, and the crtc mux configuration is also platform specific. To reuse the imx hdmi driver, convert it to drm_bridge handle encoder in imx-hdmi_pltfm.c, as most of the encoder operation are platform specific such as crtc select and panel format set This patch depends on Russell King's patch: drm: imx: convert imx-drm to use the generic DRM OF helper http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2014-July/053484.html Signed-off-by: Andy Yan Signed-off-by: Yakir Yang --- Changes in v14: - add defer probing, adviced by Philipp Zabel Changes in v13: - split platform specific phy configuration Changes in v12: - squash patch Changes in v11: - squash patch Changes in v10: - split generic dw_hdmi.c improvements from patch#11 (add rk3288 support) Changes in v9: None Changes in v8: None Changes in v7: - remove unused variables from structure dw_hdmi - remove a wrong modification - add copyrights for dw_hdmi-imx.c Changes in v6: None Changes in v5: None Changes in v4: None Changes in v3: None drivers/gpu/drm/imx/Makefile | 2 +- drivers/gpu/drm/imx/imx-hdmi.c | 298 --- drivers/gpu/drm/imx/imx-hdmi.h | 14 ++ drivers/gpu/drm/imx/imx-hdmi_pltfm.c | 226 ++ 4 files changed, 339 insertions(+), 201 deletions(-) create mode 100644 drivers/gpu/drm/imx/imx-hdmi_pltfm.c diff --git a/drivers/gpu/drm/imx/Makefile b/drivers/gpu/drm/imx/Makefile index 582c438..63cf56a 100644 --- a/drivers/gpu/drm/imx/Makefile +++ b/drivers/gpu/drm/imx/Makefile @@ -9,4 +9,4 @@ obj-$(CONFIG_DRM_IMX_LDB) += imx-ldb.o imx-ipuv3-crtc-objs := ipuv3-crtc.o ipuv3-plane.o obj-$(CONFIG_DRM_IMX_IPUV3)+= imx-ipuv3-crtc.o -obj-$(CONFIG_DRM_IMX_HDMI) += imx-hdmi.o +obj-$(CONFIG_DRM_IMX_HDMI) += imx-hdmi.o imx-hdmi_pltfm.o diff --git a/drivers/gpu/drm/imx/imx-hdmi.c b/drivers/gpu/drm/imx/imx-hdmi.c index 8029a07..f05b404 100644 --- a/drivers/gpu/drm/imx/imx-hdmi.c +++ b/drivers/gpu/drm/imx/imx-hdmi.c @@ -12,25 +12,19 @@ * Copyright (C) 2010, Guennadi Liakhovetski */ -#include #include #include #include -#include #include -#include -#include -#include #include +#include #include #include #include #include -#include #include "imx-hdmi.h" -#include "imx-drm.h" #define HDMI_EDID_LEN 512 @@ -54,11 +48,6 @@ enum hdmi_datamap { YCbCr422_12B = 0x12, }; -enum imx_hdmi_devtype { - IMX6Q_HDMI, - IMX6DL_HDMI, -}; - static const u16 csc_coeff_default[3][4] = { { 0x2000, 0x, 0x, 0x }, { 0x, 0x2000, 0x, 0x }, @@ -113,14 +102,14 @@ struct hdmi_data_info { struct imx_hdmi { struct drm_connector connector; - struct drm_encoder encoder; + struct drm_encoder *encoder; + struct drm_bridge *bridge; enum imx_hdmi_devtype dev_type; struct device *dev; - struct clk *isfr_clk; - struct clk *iahb_clk; struct hdmi_data_info hdmi_data; + const struct imx_hdmi_plat_data *plat_data; int vic; u8 edid[HDMI_EDID_LEN]; @@ -137,13 +126,6 @@ struct imx_hdmi { int ratio; }; -static void imx_hdmi_set_ipu_di_mux(struct imx_hdmi *hdmi, int ipu_di) -{ - regmap_update_bits(hdmi->regmap, IOMUXC_GPR3, - IMX6Q_GPR3_HDMI_MUX_CTL_MASK, - ipu_di << IMX6Q_GPR3_HDMI_MUX_CTL_SHIFT); -} - static inline void hdmi_writeb(struct imx_hdmi *hdmi, u8 val, int offset) { writeb(val, hdmi->regs + offset); @@ -1371,6 +1353,50 @@ static void imx_hdmi_poweroff(struct imx_hdmi *hdmi) imx_hdmi_phy_disable(hdmi); } +static void imx_hdmi_bridge_mode_set(struct drm_bridge *bridge, +struct drm_display_mode *mode, +struct drm_display_mode *adjusted_mode) +{ + struct imx_hdmi *hdmi = bridge->driver_private; + + imx_hdmi_setup(hdmi, mode); + + /* Store the display mode for plugin/DKMS poweron events */ + memcpy(&hdmi->previous_mode, mode, sizeof(hdmi->previous_mode)); +} + +static bool imx_hdmi_bridge_mode_fixup(struct drm_bridge *bridge, + const struct drm_display_mode *mode, + struct drm_display_mode *adjusted_mode) +{ + return true; +} + +static void imx_hdmi_bridge_disable(struct drm_bridge *bridge) +{ + struct imx_hdmi *hdmi = bridge->driver_private; + + imx_hdmi_poweroff(hdmi); +} + +static void imx_hdmi_bridge_enable(struct drm_bridge *bridge) +{ + struct imx_hdmi *hdmi = bridge->driver_private; + + imx_hdmi_poweron(hdmi); +} + +static void imx_hdmi_bridge_destroy(struct drm_bridge *bridge) +{ + drm_br
[PATCH v14 04/12] drm: imx: imx-hdmi: split phy configuration to platform driver
hdmi phy configuration is platform specific, which can be adusted according to the board to get the best SI Signed-off-by: Andy Yan --- Changes in v14: None Changes in v13: - split phy configuration from patch#4 Changes in v12: None Changes in v11: None Changes in v10: None Changes in v9: None Changes in v8: None Changes in v7: None Changes in v6: None Changes in v5: None Changes in v4: None Changes in v3: None drivers/gpu/drm/imx/imx-hdmi.c | 85 +++- drivers/gpu/drm/imx/imx-hdmi.h | 29 drivers/gpu/drm/imx/imx-hdmi_pltfm.c | 57 3 files changed, 101 insertions(+), 70 deletions(-) diff --git a/drivers/gpu/drm/imx/imx-hdmi.c b/drivers/gpu/drm/imx/imx-hdmi.c index f05b404..99c2966 100644 --- a/drivers/gpu/drm/imx/imx-hdmi.c +++ b/drivers/gpu/drm/imx/imx-hdmi.c @@ -710,76 +710,14 @@ static void imx_hdmi_phy_sel_interface_control(struct imx_hdmi *hdmi, u8 enable) HDMI_PHY_CONF0_SELDIPIF_MASK); } -enum { - RES_8, - RES_10, - RES_12, - RES_MAX, -}; - -struct mpll_config { - unsigned long mpixelclock; - struct { - u16 cpce; - u16 gmp; - } res[RES_MAX]; -}; - -static const struct mpll_config mpll_config[] = { - { - 4525, { - { 0x01e0, 0x }, - { 0x21e1, 0x }, - { 0x41e2, 0x } - }, - }, { - 9250, { - { 0x0140, 0x0005 }, - { 0x2141, 0x0005 }, - { 0x4142, 0x0005 }, - }, - }, { - 14850, { - { 0x00a0, 0x000a }, - { 0x20a1, 0x000a }, - { 0x40a2, 0x000a }, - }, - }, { - ~0UL, { - { 0x00a0, 0x000a }, - { 0x2001, 0x000f }, - { 0x4002, 0x000f }, - }, - } -}; - -struct curr_ctrl { - unsigned long mpixelclock; - u16 curr[RES_MAX]; -}; - -static const struct curr_ctrl curr_ctrl[] = { - /* pixelclk bpp8bpp10 bpp12 */ - { -5400, { 0x091c, 0x091c, 0x06dc }, - }, { -5840, { 0x091c, 0x06dc, 0x06dc }, - }, { -7200, { 0x06dc, 0x06dc, 0x091c }, - }, { -7425, { 0x06dc, 0x0b5c, 0x091c }, - }, { - 11880, { 0x091c, 0x091c, 0x06dc }, - }, { - 21600, { 0x06dc, 0x0b5c, 0x091c }, - } -}; - static int hdmi_phy_configure(struct imx_hdmi *hdmi, unsigned char prep, unsigned char res, int cscon) { unsigned res_idx, i; u8 val, msec; + const struct mpll_config *mpll_config = hdmi->plat_data->mpll_cfg; + const struct curr_ctrl *curr_ctrl = hdmi->plat_data->cur_ctr; + const struct sym_term *sym_term = hdmi->plat_data->sym_term; if (prep) return -EINVAL; @@ -825,7 +763,7 @@ static int hdmi_phy_configure(struct imx_hdmi *hdmi, unsigned char prep, hdmi_phy_test_clear(hdmi, 0); /* PLL/MPLL Cfg - always match on final entry */ - for (i = 0; i < ARRAY_SIZE(mpll_config) - 1; i++) + for (i = 0; mpll_config[i].mpixelclock != (~0UL); i++) if (hdmi->hdmi_data.video_mode.mpixelclock <= mpll_config[i].mpixelclock) break; @@ -833,12 +771,12 @@ static int hdmi_phy_configure(struct imx_hdmi *hdmi, unsigned char prep, hdmi_phy_i2c_write(hdmi, mpll_config[i].res[res_idx].cpce, 0x06); hdmi_phy_i2c_write(hdmi, mpll_config[i].res[res_idx].gmp, 0x15); - for (i = 0; i < ARRAY_SIZE(curr_ctrl); i++) + for (i = 0; curr_ctrl[i].mpixelclock != (~0UL); i++) if (hdmi->hdmi_data.video_mode.mpixelclock <= curr_ctrl[i].mpixelclock) break; - if (i >= ARRAY_SIZE(curr_ctrl)) { + if (curr_ctrl[i].mpixelclock == (~0UL)) { dev_err(hdmi->dev, "Pixel clock %d - unsupported by HDMI\n", hdmi->hdmi_data.video_mode.mpixelclock); return -EINVAL; @@ -849,10 +787,17 @@ static int hdmi_phy_configure(struct imx_hdmi *hdmi, unsigned char prep, hdmi_phy_i2c_write(hdmi, 0x, 0x13); /* PLLPHBYCTRL */ hdmi_phy_i2c_write(hdmi, 0x0006, 0x17); + + for (i = 0; sym_term[i].mpixelclock != (~0UL); i++) + if (hdmi->hdmi_data.video_mode.mpixelclock <= + sym_term[i].mpixelclock) + break; + /* RESISTANCE TERM 133Ohm Cfg */ - hdmi_phy_i2c_write(hdmi, 0x0005, 0x19); /* TXTERM */ + hdmi_phy_i2c_write(hdmi, sym_term[i].term, 0x19); /* TXTERM */ /* PREEMP Cgf 0.00 */ - hdmi_p
[PATCH v14 05/12] drm: imx: imx-hdmi: move imx-hdmi to bridge/dw_hdmi
the original imx hdmi driver is under drm/imx/, which depends on imx-drm, so move the imx hdmi driver out to drm/bridge and rename it to dw_hdmi Signed-off-by: Andy Yan --- Changes in v14: None Changes in v13: None Changes in v12: None Changes in v11: None Changes in v10: None Changes in v9: None Changes in v8: None Changes in v7: None Changes in v6: None Changes in v5: None Changes in v4: None Changes in v3: None drivers/gpu/drm/bridge/Kconfig | 5 + drivers/gpu/drm/bridge/Makefile| 1 + .../gpu/drm/{imx/imx-hdmi.c => bridge/dw_hdmi.c} | 269 +++-- .../gpu/drm/{imx/imx-hdmi.h => bridge/dw_hdmi.h} | 42 drivers/gpu/drm/imx/Kconfig| 1 + drivers/gpu/drm/imx/Makefile | 2 +- .../drm/imx/{imx-hdmi_pltfm.c => dw_hdmi-imx.c}| 122 +- include/drm/bridge/dw_hdmi.h | 57 + 8 files changed, 260 insertions(+), 239 deletions(-) rename drivers/gpu/drm/{imx/imx-hdmi.c => bridge/dw_hdmi.c} (84%) rename drivers/gpu/drm/{imx/imx-hdmi.h => bridge/dw_hdmi.h} (98%) rename drivers/gpu/drm/imx/{imx-hdmi_pltfm.c => dw_hdmi-imx.c} (61%) create mode 100644 include/drm/bridge/dw_hdmi.h diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 884923f..26162ef 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -3,3 +3,8 @@ config DRM_PTN3460 depends on DRM select DRM_KMS_HELPER ---help--- + +config DRM_DW_HDMI + bool "Synopsys DesignWare High-Definition Multimedia Interface" + depends on DRM + select DRM_KMS_HELPER diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile index b4733e1..d8a8cfd 100644 --- a/drivers/gpu/drm/bridge/Makefile +++ b/drivers/gpu/drm/bridge/Makefile @@ -1,3 +1,4 @@ ccflags-y := -Iinclude/drm obj-$(CONFIG_DRM_PTN3460) += ptn3460.o +obj-$(CONFIG_DRM_DW_HDMI) += dw_hdmi.o diff --git a/drivers/gpu/drm/imx/imx-hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c similarity index 84% rename from drivers/gpu/drm/imx/imx-hdmi.c rename to drivers/gpu/drm/bridge/dw_hdmi.c index 99c2966..a53bf63 100644 --- a/drivers/gpu/drm/imx/imx-hdmi.c +++ b/drivers/gpu/drm/bridge/dw_hdmi.c @@ -6,12 +6,11 @@ * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * - * SH-Mobile High-Definition Multimedia Interface (HDMI) driver - * for SLISHDMI13T and SLIPHDMIT IP cores + * Designware High-Definition Multimedia Interface (HDMI) driver * * Copyright (C) 2010, Guennadi Liakhovetski */ - +#include #include #include #include @@ -23,8 +22,9 @@ #include #include #include +#include -#include "imx-hdmi.h" +#include "dw_hdmi.h" #define HDMI_EDID_LEN 512 @@ -100,16 +100,17 @@ struct hdmi_data_info { struct hdmi_vmode video_mode; }; -struct imx_hdmi { +struct dw_hdmi { struct drm_connector connector; struct drm_encoder *encoder; struct drm_bridge *bridge; - enum imx_hdmi_devtype dev_type; + enum dw_hdmi_devtype dev_type; struct device *dev; struct hdmi_data_info hdmi_data; - const struct imx_hdmi_plat_data *plat_data; + const struct dw_hdmi_plat_data *plat_data; + int vic; u8 edid[HDMI_EDID_LEN]; @@ -126,17 +127,17 @@ struct imx_hdmi { int ratio; }; -static inline void hdmi_writeb(struct imx_hdmi *hdmi, u8 val, int offset) +static inline void hdmi_writeb(struct dw_hdmi *hdmi, u8 val, int offset) { writeb(val, hdmi->regs + offset); } -static inline u8 hdmi_readb(struct imx_hdmi *hdmi, int offset) +static inline u8 hdmi_readb(struct dw_hdmi *hdmi, int offset) { return readb(hdmi->regs + offset); } -static void hdmi_modb(struct imx_hdmi *hdmi, u8 data, u8 mask, unsigned reg) +static void hdmi_modb(struct dw_hdmi *hdmi, u8 data, u8 mask, unsigned reg) { u8 val = hdmi_readb(hdmi, reg) & ~mask; @@ -144,13 +145,13 @@ static void hdmi_modb(struct imx_hdmi *hdmi, u8 data, u8 mask, unsigned reg) hdmi_writeb(hdmi, val, reg); } -static void hdmi_mask_writeb(struct imx_hdmi *hdmi, u8 data, unsigned int reg, +static void hdmi_mask_writeb(struct dw_hdmi *hdmi, u8 data, unsigned int reg, u8 shift, u8 mask) { hdmi_modb(hdmi, data << shift, mask, reg); } -static void hdmi_set_clock_regenerator_n(struct imx_hdmi *hdmi, +static void hdmi_set_clock_regenerator_n(struct dw_hdmi *hdmi, unsigned int value) { hdmi_writeb(hdmi, value & 0xff, HDMI_AUD_N1); @@ -161,7 +162,7 @@ static void hdmi_set_clock_regenerator_n(struct imx_hdmi *hdmi, hdmi_modb(hdmi, 0, HDMI_AUD_CTS3_N_SHIFT_MASK, HDMI_AUD_CTS3); } -static void hdmi_regenerate_cts(struct imx_hdmi *hdmi, unsigned int cts) +static void hdmi_regenerate_cts(struct dw_hdmi *hdmi, unsigned int cts) { /
[PATCH v14 08/12] drm: bridge/dw_hdmi: add mode_valid support
some platform may not support all the display mode, add mode_valid interface check it Signed-off-by: Andy Yan --- Changes in v14: - remove drm_connector_register, because imx-drm core has registered connector Changes in v13: None Changes in v12: None Changes in v11: None Changes in v10: None Changes in v9: None Changes in v8: None Changes in v7: None Changes in v6: None Changes in v5: None Changes in v4: None Changes in v3: None drivers/gpu/drm/bridge/dw_hdmi.c | 15 +++ include/drm/bridge/dw_hdmi.h | 2 ++ 2 files changed, 17 insertions(+) diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c index 5e88c8d..a95a553 100644 --- a/drivers/gpu/drm/bridge/dw_hdmi.c +++ b/drivers/gpu/drm/bridge/dw_hdmi.c @@ -1406,6 +1406,20 @@ static int dw_hdmi_connector_get_modes(struct drm_connector *connector) return 0; } +static enum drm_mode_status +dw_hdmi_connector_mode_valid(struct drm_connector *connector, +struct drm_display_mode *mode) +{ + struct dw_hdmi *hdmi = container_of(connector, + struct dw_hdmi, connector); + enum drm_mode_status mode_status = MODE_OK; + + if (hdmi->plat_data->mode_valid) + mode_status = hdmi->plat_data->mode_valid(connector, mode); + + return mode_status; +} + static struct drm_encoder *dw_hdmi_connector_best_encoder(struct drm_connector *connector) { @@ -1430,6 +1444,7 @@ static struct drm_connector_funcs dw_hdmi_connector_funcs = { static struct drm_connector_helper_funcs dw_hdmi_connector_helper_funcs = { .get_modes = dw_hdmi_connector_get_modes, + .mode_valid = dw_hdmi_connector_mode_valid, .best_encoder = dw_hdmi_connector_best_encoder, }; diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h index 1bbf3ca..1777ab4 100644 --- a/include/drm/bridge/dw_hdmi.h +++ b/include/drm/bridge/dw_hdmi.h @@ -48,6 +48,8 @@ struct dw_hdmi_plat_data { const struct mpll_config *mpll_cfg; const struct curr_ctrl *cur_ctr; const struct sym_term *sym_term; + enum drm_mode_status (*mode_valid)(struct drm_connector *connector, + struct drm_display_mode *mode); }; void dw_hdmi_unbind(struct device *dev, struct device *master, void *data); -- 1.9.1
[PATCH v14 09/12] drm: bridge/dw_hdmi: clear i2cmphy_stat0 reg in hdmi_phy_wait_i2c_done
HDMI_IH_I2CMPHY_STAT0 is a clear on write register, which indicates i2cm operation status(i2c transfer done or error), every hdmi phy register configuration must check this register to make sure the configuration has complete. But the indication bit should be cleared after check, otherwise the corresponding bit will hold on forever, this may give a wrong signal for next check. Signed-off-by: Andy Yan --- Changes in v14: None Changes in v13: None Changes in v12: None Changes in v11: None Changes in v10: None Changes in v9: None Changes in v8: None Changes in v7: None Changes in v6: None Changes in v5: None Changes in v4: None Changes in v3: None drivers/gpu/drm/bridge/dw_hdmi.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c index a95a553..5be643c 100644 --- a/drivers/gpu/drm/bridge/dw_hdmi.c +++ b/drivers/gpu/drm/bridge/dw_hdmi.c @@ -668,11 +668,15 @@ static inline void hdmi_phy_test_dout(struct dw_hdmi *hdmi, static bool hdmi_phy_wait_i2c_done(struct dw_hdmi *hdmi, int msec) { - while ((hdmi_readb(hdmi, HDMI_IH_I2CMPHY_STAT0) & 0x3) == 0) { + u32 val; + + while ((val = hdmi_readb(hdmi, HDMI_IH_I2CMPHY_STAT0) & 0x3) == 0) { if (msec-- == 0) return false; udelay(1000); } + hdmi_writeb(hdmi, val, HDMI_IH_I2CMPHY_STAT0); + return true; } -- 1.9.1
[PATCH] drm/i915 Trouble with minimum brightness
On 12/01/2014 03:04 PM, Jani Nikula wrote: > On Fri, 28 Nov 2014, Jay Aurabind wrote: >> Hello all, >> >> I notice that some activity has been going on with the minimum value >> of display brightness recently (e1c412e7575). >> >> But the minimum value thats currently chosen is not at all acceptable >> for my eyes. My display is working perfectly without that restriction >> on minimum intensity. I tend to stare at the screen a lot and the >> current minimum settings is straining my eyes. >> >> Even if you say that it may not be good for the devices, I still >> insist, because I want my *display* to fail first, not my eyes. So >> please try providing a way for the needy users to override this >> minimum settings. I hope adding a module parameter would be easy fix. >> >> Something like this: ? (I dont call myself a kernel programmer yet, >> just scratching the surface) >> >> >> Provide provision for users to disable restriction on minimum brightness >> value introduced in: >> >> commit e1c412e75754ab7b7002f3e18a2652d999c40d4b >> Author: Jani Nikula >> Date: Wed Nov 5 14:46:31 2014 +0200 >> >> drm/i915: safeguard against too high minimum brightness >> >> There are systems which work reliably without restriction on minimum >> value of display brightness. Also the arbitrary value may be too high >> for many users as well. > > Please file a new bug at [1], reference this mail, and attach > /sys/kernel/debug/dri/0/i915_opregion. Thank you for the response. But the file you mentioned to attach seems to be a binary file, because I'm getting lot of junk characters. Is this normal ? > > The minimum value is chosen and provided by the OEM. There's still some > open questions about the interpretation of the value though (which lead > to the commit you referenced), so I'm hesitant to make changes before we > have those cleared up.
[PATCH v13 07/12] drm: bridge/dw_hdmi: add support for multi-byte register width access
Hi Philipp: On 2014å¹´12æ01æ¥ 20:04, Philipp Zabel wrote: > Am Freitag, den 28.11.2014, 17:43 +0800 schrieb Andy Yan: >> Hi Zabel: >> On 2014å¹´11æ27æ¥ 00:34, Philipp Zabel wrote: >>> Am Mittwoch, den 26.11.2014, 21:32 +0800 schrieb Andy Yan: On rockchip rk3288, only word(32-bit) accesses are permitted for hdmi registers. Byte width accesses (writeb, readb) generate an imprecise external abort. Signed-off-by: Andy Yan --- Changes in v13: None Changes in v12: None Changes in v11: None Changes in v10: None Changes in v9: None Changes in v8: None Changes in v7: None Changes in v6: - refactor register access without reg_shift Changes in v5: - refactor reg-io-width Changes in v4: None Changes in v3: - split multi-register access to one indepent patch drivers/gpu/drm/bridge/dw_hdmi.c | 57 +++- 1 file changed, 51 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c index a53bf63..5e88c8d 100644 --- a/drivers/gpu/drm/bridge/dw_hdmi.c +++ b/drivers/gpu/drm/bridge/dw_hdmi.c @@ -100,6 +100,11 @@ struct hdmi_data_info { struct hdmi_vmode video_mode; }; +union dw_reg_ptr { + u32 __iomem *p32; + u8 __iomem *p8; +}; >>> I see no need to introduce this. Just explicitly multiply the offset in >>> dw_hdmi_writel. >>> >> Is there any disadvantage to do like this? >> The compiler can help us do the explicitly multiply by this way. > Four additional lines, a new defined type, a few more changes to struct > dw_hdmi and dw_hdmi_bind necessary. > > Technically I see no problem to let the compiler do the multiplication, > my issue is that it ever so slightly obfuscates the code. Instead of > just writing "* 4" in two functions, we get a new union that you need to > know about when looking at struct dw_hdmi and dw_hdmi_bind, regs.p8 is > used but never assigned directly, it's just a tiny bit of additional > effort needed to understand the code. But when the cost to avoid that is > so small... > > regards > Philipp > What you said is right, I will change it in PATCH V15 thanks . > ___ > Linux-rockchip mailing list > Linux-rockchip at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-rockchip
[PATCH] drm: i2c: tda998x: Retry fetching the EDID if it fails first time.
On 11/29/14 10:41, Jean-Francois Moine wrote: > On Fri, 28 Nov 2014 09:02:39 + > Andrew Jackson wrote: > >>> It seems that your patch is deprecated by Laurent Pinchart's >>> [PATCH] drm: tda998x: Use drm_do_get_edid() >>> http://lists.freedesktop.org/archives/dri-devel/2014-November/072906.html >>> >> >> Thank you for the heads-up, I'd not seen that. I'll consider how my patch >> might be modified to suit the new infrastructure. > > You don't need any patch: drm_do_get_edid() already loops on reading > the EDID. > Thank you again: that saves me work! Andrew
omapdrm/pvr kernel crash with camera capture and display application
88 ef0a5e58 80060018 [ 114.062591] 9fa0: ef0b9fb0 8000ee18 80060024 [ 114.062591] 9fc0: [ 114.062591] 9fe0: 0013 40c04a08 00412274 [ 114.062591] Backtrace: [ 114.062591] [<800605b0>] (kthread_data+0x0/0x20) from [<80058a54>] (wq_worker_sleeping+0x1c/0xac) [ 114.062622] [<80058a38>] (wq_worker_sleeping+0x0/0xac) from [<804c5b68>] (__schedule+0x104/0x678) [ 114.062622] r6:ef0b8000 r5:8901a740 r4:ef0a1680 r3:0420806c [ 114.062622] [<804c5a64>] (__schedule+0x0/0x678) from [<804c6280>] (schedule+0x94/0x98) [ 114.062622] [<804c61ec>] (schedule+0x0/0x98) from [<80040998>] (do_exit+0x868/0x8d8) [ 114.062652] [<80040130>] (do_exit+0x0/0x8d8) from [<80013b58>] (die+0x360/0x3d8) [ 114.062652] r7:804c4ff0 [ 114.062652] [<800137f8>] (die+0x0/0x3d8) from [<804bfa08>] (__do_kernel_fault.part.9+0x64/0x84) [ 114.062652] [<804bf9a4>] (__do_kernel_fault.part.9+0x0/0x84) from [<8001bf34>] (do_page_fault+0x2f8/0x340) [ 114.062683] r7:ef0a1680 r3:ef0b9dc8 [ 114.062683] [<8001bc3c>] (do_page_fault+0x0/0x340) from [<80008524>] (do_DataAbort+0x44/0xa8) [ 114.062683] [<800084e0>] (do_DataAbort+0x0/0xa8) from [<8000e8d8>] (__dabt_svc+0x38/0x60) [ 114.062683] Exception stack(0xef0b9dc8 to 0xef0b9e10) [ 114.062683] 9dc0: 0014 6013 0001d838 f000 0014 [ 114.062713] 9de0: ee9653c0 8073ef0c ef0b9e24 ef0b9e28 ef0b9e10 [ 114.062713] 9e00: 80324a80 804c4ff0 0013 [ 114.062713] r7:ef0b9dfc r6: r5:0013 r4:804c4ff0 [ 114.062713] [<804c4fd4>] (mutex_lock+0x0/0x58) from [<80324a80>] (omap_gem_put_paddr+0x24/0xb8) [ 114.062744] r4:ecfe5300 r3:f000 [ 114.062774] [<80324a5c>] (omap_gem_put_paddr+0x0/0xb8) from [<7f009e44>] (UnwrapExtMemoryCallBack+0x64/0x74 [omapdrm_pvr]) [ 114.062774] r5: r4:ecfe5300 [ 114.062805] [<7f009de0>] (UnwrapExtMemoryCallBack+0x0/0x74 [omapdrm_pvr]) from [<7f014d88>] (FreeResourceByPtr+0x48/0xe8 [omapdrm_pvr]) [ 114.062805] r6: r5:0001 r4:ee965b00 r3:7f009de0 [ 114.062866] [<7f014d40>] (FreeResourceByPtr+0x0/0xe8 [omapdrm_pvr]) from [<7f0155b4>] (ResManFreeResByPtr+0x64/0x80 [omapdrm_pvr]) [ 114.062866] r6:ecf68880 r5: r4:ee965b00 [ 114.062927] [<7f015550>] (ResManFreeResByPtr+0x0/0x80 [omapdrm_pvr]) from [<7f009314>] (async_unmap+0x34/0x54 [omapdrm_pvr]) [ 114.062927] r5:7f0268a0 r4:ee9653c0 [ 114.062957] [<7f0092e0>] (async_unmap+0x0/0x54 [omapdrm_pvr]) from [<803244e0>] (notify_worker+0x40/0x48) [ 114.062957] r6:7f0092e0 r5:807bbaa4 r4:ee965420 r3: [ 114.062957] [<803244a0>] (notify_worker+0x0/0x48) from [<80058198>] (process_one_work+0x278/0x488) [ 114.062988] r7:ef2aca00 r6:8073ee00 r5:ee965420 r4:ef0661c0 [ 114.062988] [<80057f20>] (process_one_work+0x0/0x488) from [<80058808>] (worker_thread+0x278/0x398) [ 114.062988] [<80058590>] (worker_thread+0x0/0x398) from [<800600d4>] (kthread+0xbc/0xcc) [ 114.062988] [<80060018>] (kthread+0x0/0xcc) from [<8000ee18>] (ret_from_fork+0x14/0x20) [ 114.063018] r7: r6: r5:80060018 r4:ef0a5e58 [ 114.063018] Code: e24cb004 e52de004 e8bd4000 e59031cc (e5130014) [ 114.063018] ---[ end trace 2441b1bbdffd41f0 ]--- [ 114.063018] Fixing recursive fault but reboot is needed! -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141201/1ea00b3a/attachment-0001.html>
RFC on upstreaming of a Mediatek DRM modesetting driver
+Puneet,+Zel We will get back to you guys with answers soon. On Dec 1, 2014 9:28 AM, "Daniel Vetter" wrote: > On Mon, Dec 01, 2014 at 10:01:37AM +, Frank Binns wrote: > > Hi, > > > > We are currently in negotiations with one of our customers (Mediatek) on > > a strategy that will allow them to push a DRM modesetting driver into > > the upstream kernel. We are writing to get people's opinions and > > feedback on our proposed approach. > > > > Currently, our driver is structured in such a way that the display > > driver is more tightly integrated with the GPU driver than we would > > like. Although our kernel driver has been shipped with a GPL license for > > a long time, it is not in a form that would be considered acceptable > > upstream. Unfortunately, it is going to be a long process to get this > > part of the driver into a reasonable state. However, in the meantime, we > > don't want to prevent customer portions of the driver from being > > upstreamed. With the work done on recent kernels, and with a willing > > partner in Mediatek, we now think that we can restructure our driver in > > such a way as to allow this to happen. > > > > We see two basic approaches to achieving this: > > 1) Two independent DRM drivers, i.e. modesetting and render node drivers > > 2) A single componentised DRM driver > > > > Our (IMG's) preferred approach is to have a single componentised DRM > > driver. This is due to the following reasons: > > > > - Existing user space is not fully prepared to handle render nodes. > > > > - There is concern that any IMG DRM render node driver will need > > knowledge about multiple SoCs, each one being from a different vendor. > > Would this be deemed acceptable? > > > > - There is a trend, at least for DRM SoC drivers, towards using the > > component interface. Although there appears to be very few (one?) > > examples of GPU component drivers. > > > > To give some high level details on how we expect the componentised DRM > > driver model to work, each vendor (in this case Mediatek) will write > > their own DRM driver (supporting modesetting, dumb buffers, GEM, prime, > > etc) and IMG will provide an almost entirely independent component > > driver that adds in GPU support. Until our GPU driver is in a suitable > > state this will most likely necessitate a small kernel patch to wire up > > support, e.g. GPU specific ioctls. > > > > Cross-device and cross-process memory allocations will be made using the > > DRM driver. In order for this memory to be shared with the GPU component > > driver it will be necessary, at least for the time being, to export it > > via prime and import it via a GPU ioctl. Synchronisation between the > > display and GPU will be performed via reservation objects. > > > > Does this sound like a sane approach? Questions and/or feedback is very > > welcome. > > Rule of thumb is that if it's an externally licensed IP block it should be > a separate driver. Which is the case here. The idea is that the mostly > generic IMG driver could be reused on other platforms that ship the same > IP-block, while linking up with the respective display controller driver. > The end result is 2 drm drivers: > - Display block drm driver which expose KMS objects for modesetting, but > only very basic gem (just enough to allocate dumb framebuffers and > import/export dma-bufs). > - Full-blown gem driver for the img render IP block. > > For an example look at the tegra/nouveau combo which can run on TK1. > > Plugggin in an IMG driver into each display block like it's currently done > with all the armsoc stuff on android is imo completely no-go. > > Note that the component interface is completely irrelevant wrt the > interface you expose to userspace. It's just an driver-internal helper > library useful in certain situation. Not even the drm core really cares > whether you use component helpers or not. > > Thanks, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141201/57b1e1c6/attachment-0001.html>