- 08 5月, 2015 4 次提交
-
-
由 Daniel Vetter 提交于
i915_needs_cmd_parser already checks that for us. Suggested-by: NMika Kuoppala <mika.kuoppala@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
-
由 Nick Hoath 提交于
Signed-off-by: NNick Hoath <nicholas.hoath@intel.com> Reviewed-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chandra Konduru 提交于
This patch enables skylake sprite plane display scaling using shared scalers atomic desgin. v2: -use single copy of scaler limits (Matt) v3: -detaching scalers moved to crtc commit path (Matt) v4: -changes to align with updated scaler structures (Matt, me) -keep sprite src rect in 16.16 format (Matt, Daniel) v5: -rebased on top of 90/270 rotation changes (me) -Refactored skl_update_plane to reduce its size (Daniel) It is a step towards having a single function covering all planes. Signed-off-by: NChandra Konduru <chandra.konduru@intel.com> Reviewed-by: NMatt Roper <matthew.d.roper@intel.com> Testcase: igt/kms_plane_scaling Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chandra Konduru 提交于
This patch enables skylake primary plane scaling using shared scalers atomic desgin. v2: -use single copy of scaler limits (Matt) v3: -move detach_scalers to crtc commit path (Matt) -use values in plane_state->src as regular integers (me) v4: -changes to align with updated scaler structures (Matt, me) -keep plane src rect in 16.16 format (Matt, Daniel) v5: -Rebased on top of 90/270 rotation changes (me) -Fixed an issue introduced by 90/270 changes where plane programming is using drm_plane->state rect instead of intel_plane->state rect. This change also required for scaling to work properly. (me) -With 90/270, updated limits to cover both portrait and landscape usages (me) -Refactored skylake_update_primary_plane to reduce its size (Daniel) Added helper functions for refactoring are comprehended enough to be used for skylake_update_plane (for sprite) too. One stop towards having single function for all planes. v6: -Added fixme note when checking plane_state->src width in update_plane (Daniel) -Release lock when failing to colorkey request with active scaler (Daniel) Signed-off-by: NChandra Konduru <chandra.konduru@intel.com> Reviewed-by: matthew.d.roper@intel.com Reviewed-by: sonika.jindal@intel.com (v5) Testcase: igt/kms_plane_scaling Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 07 5月, 2015 1 次提交
-
-
由 Gerd Hoffmann 提交于
Completely different approach: Instead of encoding each and every framebuffer update as spice operation simply update the shadow framebuffer and maintain a dirty rectangle. Also schedule a worker to push an update for the dirty rectangle as spice operation. Usually a bunch of dirty rectangle updates are collected before the worker actually runs. What changes: Updates get batched now. Instead of sending tons of small updates a few large ones are sent. When the same region is updated multiple times within a short timeframe (scrolling multiple lines for example) we send a single update only. Spice server has an easier job now: The dependency tree for display operations which spice server maintains for lazy rendering is alot smaller now. Spice server's image compression probably works better too with the larger image blits. Net effect: framebuffer console @ qxldrmfb is an order of magnitude faster now. Signed-off-by: NGerd Hoffmann <kraxel@redhat.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 05 5月, 2015 4 次提交
-
-
由 David Herrmann 提交于
In drm_master_destroy() we _free_ the master object. There is no reason to hold any locks while dropping its static members, nor do we have to reset it to 0. Furthermore, kfree() already does NULL checks, so call it directly on master->unique and drop the redundant reset-code. Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 David Herrmann 提交于
The magic auth tokens we have are a simple map from cyclic IDs to drm_file objects. Remove all the old bulk of code and replace it with a simple, direct IDR. The previous behavior is kept. Especially calling authmagic multiple times on the same magic results in EINVAL except on the first call. The only difference in behavior is that we never allocate IDs multiple times as long as a client has its FD open. v2: - Fix return code of GetMagic() - Use non-cyclic IDR allocator - fix off-by-one in "magic > INT_MAX" sanity check v3: - drop redundant "magic > INT_MAX" check Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 David Herrmann 提交于
This list is write-only. It's never used for read-access, so no reason to keep it around. Drop it! Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Oleg Drokin 提交于
Need to free just allocated ctx allocation if we cannot get our config mutex. This one has been flagged by kbuild bot all the way back in August, but somehow nobody picked it up: https://lists.01.org/pipermail/kbuild/2014-August/001691.html In addition there is another failure path that leaks the same ctx reference that is fixed. Found with smatch. Signed-off-by: NOleg Drokin <green@linuxhacker.ru> CC: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 04 5月, 2015 5 次提交
-
-
由 Daniel Vetter 提交于
I've fumbled this in commit f02ad907 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Jan 22 16:36:23 2015 +0100 drm/atomic-helpers: Recover full cursor plane behaviour and accidentally put the assignment for legacy_cursor_upate after the atomic commit, where it is pretty useless. Reported-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
-
由 Mario Kleiner 提交于
This breaks under the vblank timestamp cleanup patch by Daniel Vetter. Also it is pointless to return anything but zero (or any other constant) if the function doesn't actually query a hw vblank counter. The bogus return of the current drm vblank counter via direct readout or via drm_vblank_count() is found in many of the new kms drivers, but it does exactly nothing different from returning any arbitrary constant - it's a no operation. Let's simply return 0 - Easy and fast. Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com> Cc: Dave Airlie <airlied@redhat.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Mario Kleiner 提交于
Since commit 844b03f2 we make sure that after vblank irq off, we return the last valid (vblank count, vblank timestamp) pair to clients, e.g., during modesets, which is good. An overlooked side effect of that commit for kms drivers without support for precise vblank timestamping is that at vblank irq enable, when we update the vblank counter from the hw counter, we can't update the corresponding vblank timestamp, so now we have a totally mismatched timestamp for the new count to confuse clients. Restore old client visible behaviour from before Linux 3.18, but zero out the timestamp at vblank counter update (instead of disable as in original implementation) if we can't generate a meaningful timestamp immediately for the new vblank counter. This will fix this regression, so callers know they need to retry again later if they need a valid timestamp, but at the same time preserves the improvements made in the commit mentioned above. v2: Rebased on top of Daniel Vetter's fixup and documentation patch for timestamp updates. Drop request for stable kernel backport as this would be more difficult, unless the original patch would get applied to stable kernels. Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Dave Airlie <airlied@redhat.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Mario Kleiner 提交于
For a kms driver to support immediate disable of vblank irq's reliably without introducing off by one errors or other mayhem for clients, it must not only support a hardware vblank counter query, but also high precision vblank timestamping, so vblank count and timestamp can be instantaneously reinitialzed to valid values. Additionally the exposed hardware counter must behave as if it is incrementing at leading edge of vblank to avoid off by one errors during reinitialization of the counter while the display happens to be inside or close to vblank. Check during drm_vblank_init that a driver which claims to be capable of vblank_disable_immediate at least supports high precision timestamping and prevent use of instant disable if that isn't present as a minimum requirement. v2: Changed from DRM_ERROR to DRM_INFO and made message more clear, as suggested by Michel Dänzer. Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com> Cc: Dave Airlie <airlied@redhat.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
This was a bit too much cargo-culted, so lets make it solid: - vblank->count doesn't need to be an atomic, writes are always done under the protection of dev->vblank_time_lock. Switch to an unsigned long instead and update comments. Note that atomic_read is just a normal read of a volatile variable, so no need to audit all the read-side access specifically. - The barriers for the vblank counter seqlock weren't complete: The read-side was missing the first barrier between the counter read and the timestamp read, it only had a barrier between the ts and the counter read. We need both. - Barriers weren't properly documented. Since barriers only work if you have them on boths sides of the transaction it's prudent to reference where the other side is. To avoid duplicating the write-side comment 3 times extract a little store_vblank() helper. In that helper also assert that we do indeed hold dev->vblank_time_lock, since in some cases the lock is acquired a few functions up in the callchain. Spotted while reviewing a patch from Chris Wilson to add a fastpath to the vblank_wait ioctl. v2: Add comment to better explain how store_vblank works, suggested by Chris. v3: Peter noticed that as-is the 2nd smp_wmb is redundant with the implicit barrier in the spin_unlock. But that can only be proven by auditing all callers and my point in extracting this little helper was to localize all the locking into just one place. Hence I think that additional optimization is too risky. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Michel Dänzer <michel@daenzer.net> Cc: Peter Hurley <peter@hurleysoftware.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-and-tested-by: NMario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
-
- 30 4月, 2015 6 次提交
-
-
由 Mika Kuoppala 提交于
When we have bound vma into an address space, the layout of page table structures is immutable. So we can be absolutely certain that if vma is already bound, there is no need to (re)allocate a virtual address range for it. v2: - add sanity checks and remove superfluous GLOBAL_BIND set - we might do update for an unbound vma (Chris) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90224 Testcase: igt/gem_exec_big #bdw Reported-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Daniel Vetter 提交于
With the binding regression from the original full ppgtt patches fixed we can throw the switch. Yay! Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90190Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com> [Jani: tweaked commit title per Chris' suggestion] Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Imre Deak 提交于
At the moment intel_prepare_ddi buffer will iterate through both MST and CRT encoders, which is incorrect. Neither of these encoder types have an embedding intel_digital_port object, so for these encoder types we will use random data when dereferencing the corresponding intel_digital_port->port field. Introduced in commit b403745c Author: Damien Lespiau <damien.lespiau@intel.com> Date: Mon Aug 4 22:01:33 2014 +0100 drm/i915: Iterate through the initialized DDIs to prepare their buffers v2: - fix getting at the port for MST encoders too - make sure that intel_prepare_ddi_buffers() gets called for port E too (Paulo) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90067Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Imre Deak 提交于
In the next patch we'll need to get at both the encoder's intel_digital_port object - which maybe NULL for a CRT - and it's port, so factor out this functionality. No functional change. Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Jani Nikula 提交于
Add port check for ibx similar to vlv in commit 535afa2e Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Wed Apr 15 16:52:29 2015 -0700 drm/i915/vlv: check port in infoframe_enabled v2 Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Jani Nikula 提交于
Due to missing shifting, the vlv infoframe port check only works for port A. Fix it. Broken since introduction in commit 535afa2e Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Wed Apr 15 16:52:29 2015 -0700 drm/i915/vlv: check port in infoframe_enabled v2 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90059Tested-by: Nxubin <bin.a.xu@intel.com> Tested-by: NYe Tian <yex.tian@intel.com> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 29 4月, 2015 1 次提交
-
-
由 Chris Wilson 提交于
drivers/gpu/drm/i915/intel_dvo.c: In function ‘intel_dvo_init’: drivers/gpu/drm/i915/intel_dvo.c:531:8: warning: array subscript is above array bounds [-Warray-bounds] gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix and gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.8/lto-wrapper Target: i686-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.2-19ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-i386/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-i386 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-i386 --with-arch-directory=i386 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-targets=all --enable-multiarch --disable-werror --with-arch-32=i686 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu Thread model: posix gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NDave Gordon <david.s.gordon@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 28 4月, 2015 1 次提交
-
-
由 Deepak S 提交于
This WA is avoid problem between shadow vs wake FIFO unload problem during CPD/RC6 transactions on CHV. v2: Define individual bits GTFIFOCTL (Ville) v3: move WA to uncore_early_sanitize (ville) Signed-off-by: NDeepak S <deepak.s@linux.intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> [Jani: fixed some whitespace issues while applying] Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 27 4月, 2015 12 次提交
-
-
由 Christian König 提交于
Otherwise we print false warning from time to time. v2: agd5f: rebase Signed-off-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NJack Xiao <Jack.Xiao@amd.com> CC: stable@vger.kernel.org Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Christian König 提交于
Otherwise the change isn't atomic. Signed-off-by: NChristian König <christian.koenig@amd.com> CC: stable@vger.kernel.org Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Christian König 提交于
Otherwise it is possible that we will have page table corruption if we change a BOs address multiple times. Signed-off-by: NChristian König <christian.koenig@amd.com> CC: stable@vger.kernel.org Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Christian König 提交于
If we unmap BOs before releasing them them the intervall tree locks up because we try to remove an entry not inside the tree. Based on a patch from Michel Dänzer. Signed-off-by: NChristian König <christian.koenig@amd.com> CC: stable@vger.kernel.org Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
Seems to have problems with high mclks. bug: https://bugs.freedesktop.org/show_bug.cgi?id=76490Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Alex Deucher 提交于
Fixes display problems with some monitors when audio is not enabled. Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=89505 https://bugzilla.kernel.org/show_bug.cgi?id=94171 Plus several reports on IRC. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Alex Deucher 提交于
Selectively enable which packets we send based on monitor caps. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Alex Deucher 提交于
Otherwise the driver may try and send audio which may confuse the monitor. v2: set pin to NULL if no audio v3: avoid crash with analog encoders Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Alex Deucher 提交于
Don't enable the audio and avi infoframes and audio stream until all the state is set up. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Alex Deucher 提交于
It's mostly duplicated with evergreen_dp_enable. This is a prerequisite for fix implemented in another patch. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Alex Deucher 提交于
Set the line first, then enable the stream. May fix pink line problems on some displays. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Michel Dänzer 提交于
The number of relocs is passed in by userspace and can be large. It has been observed to cause kcalloc failures in the wild. Cc: stable@vger.kernel.org Reviewed-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 24 4月, 2015 6 次提交
-
-
由 Imre Deak 提交于
Due this typo we don't save/restore the GFX_MAX_REQ_COUNT register across suspend/resume, so fix this. This was introduced in commit ddeea5b0 Author: Imre Deak <imre.deak@intel.com> Date: Mon May 5 15:19:56 2014 +0300 drm/i915: vlv: add runtime PM support I noticed this only by reading the code. To my knowledge it shouldn't cause any real problems at the moment, since the power well backing this register remains on across a runtime s/r. This may change once system-wide s0ix functionality is enabled in the kernel. v2: - resend after a missing git add -u :/ Cc: stable@vger.kernel.org Signed-off-by: NImre Deak <imre.deak@intel.com> Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com) Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Michel Thierry 提交于
WaIdleLiteRestore is an execlists-only workaround, and requires the driver to ensure that any context always has HEAD!=TAIL when attempting lite restore. Add two extra MI_NOOP instructions at the end of each request, but keep the requests tail pointing before the MI_NOOPs. We may not need to executed them, and this is why request->tail is sampled before adding these extra instructions. If we submit a context to the ELSP which has previously been submitted, move the tail pointer past the MI_NOOPs. This ensures HEAD!=TAIL. v2: Move overallocation to gen8_emit_request, and added note about sampling request->tail in commit message (Chris). v3: Remove redundant request->tail assignment in __i915_add_request, in lrc mode this is already set in execlists_context_queue. Do not add wa implementation details inside gem (Chris). v4: Apply the wa whenever the req has been resubmitted and update comment (Chris). Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NThomas Daniel <thomas.daniel@intel.com> Signed-off-by: NMichel Thierry <michel.thierry@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Dmitry Torokhov 提交于
The hardware, according to the specs, is limited to 256 byte transfers, and current driver has no protections in case users attempt to do larger transfers. The code will just stomp over status register and mayhem ensues. Let's split larger transfers into digestable chunks. Doing this allows Atmel MXT driver on Pixel 1 function properly (it hasn't since commit 9d8dc3e5 "Input: atmel_mxt_ts - implement T44 message handling" which tries to consume multiple touchscreen/touchpad reports in a single transaction). Cc: stable@vger.kernel.org Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Daniel Vetter 提交于
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Thomas Richter 提交于
This patch enables the (unfortunately undocumented) scaler of the NatSemi 2501 DVO found in the Fujitsu-Siemens S6010 laptop and other machines of the same series and age. Parts of the DVO scaler logic have been revealed by reverse engineering and trial and error, so your milage may vary. The patch (and the whole ns2501 DVO code) is currently only good for the 1024x768 panel of the S6010, and may hopefully work on other machines with the same panel size. The mode-specific configuration of the scaler have been moved out into a separate class, the mode-agnostic settings remain as raw register list as their purpose remains unclear at this point. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NThomas Richter <thor@math.tu-berlin.de> [danvet: Make the thing apply and conform to kernel patch expectations.] Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
-
由 Daniel Vetter 提交于
We have this neat abstraction between ppgtt and ggtt for (un)bind_vma and didn't end up using it really. What a shame, so fix this and make the ->bind_vma hook a bit more useful. Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
-