- 02 Sep, 2015 3 commits
-
-
Ville Syrjälä authored
To help with debugging i2c-over-aux issues, add a module parameter than can be used to tweak the assumed i2c bus speed, and thus the maximum number of retries we will do for each aux message. Cc: Simon Farnsworth <simon.farnsworth@onelan.com> Cc: moosotc@gmail.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Simon Farnsworth <simon.farnsworth@onelan.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
Calculate the number of retries we should do for each i2c-over-aux message based on the time it takes to perform the i2c transfer vs. the aux transfer. We assume the shortest possible length for the aux transfer, and the longest possible (exluding clock stretching) for the i2c transfer. The DP spec has some examples on how to calculate this, but we don't calculate things quite the same way. The spec doesn't account for the retry interval (assumes immediate retry on defer), and doesn't assume the best/worst case behaviour as we do. Note that currently we assume 10 kHz speed for the i2c bus. Some real world devices (eg. some Apple DP->VGA dongle) fails with less than 16 retries. and that would correspond to something close to 15 kHz (with our method of calculating things) But let's just go for 10 kHz to be on the safe side. Ideally we should query/set the i2c bus speed via DPCD but for now this should at leaast remove the regression from the 1->16 byte trasnfer size change. And of course if the sink completes the transfer quicker this shouldn't slow things down since we don't change the interval between retries. I did a few experiments with a DP->DVI dongle I have that allows you to change the i2c bus speed. Here are the results of me changing the actual bus speed and the assumed bus speed and seeing when we start to fail the operation: actual i2c khz assumed i2c khz max retries 1 1 ok -> 2 fail 211 ok -> 106 fail 5 8 ok -> 9 fail 27 ok -> 24 fail 10 17 ok -> 18 fail 13 ok -> 12 fail 100 210 ok -> 211 fail 2 ok -> 1 fail So based on that we have a fairly decent safety margin baked into the formula to calculate the max number of retries. Fixes a regression with some DP dongles from: commit 1d002fa7 Author: Simon Farnsworth <simon.farnsworth@onelan.co.uk> Date: Tue Feb 10 18:38:08 2015 +0000 drm/dp: Use large transactions for I2C over AUX v2: Use best case for AUX and worst case for i2c (Simon Farnsworth) Add a define our AUX retry interval and account for it v3: Make everything usecs to avoid confusion about units (Daniel) Add a comment reminding people about the AUX bitrate (Daniel) Use DIV_ROUND_UP() since we're after the "worst" case for i2c Cc: Simon Farnsworth <simon.farnsworth@onelan.com> Cc: moosotc@gmail.com Tested-by: moosotc@gmail.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91451Reviewed-by: Simon Farnsworth <simon.farnsworth@onelan.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
Currently we react to native and i2c defers by waiting either 400-500 us or 500-600 us, depending on which code path we take. Consolidate them all to one define AUX_RETRY_INTERVAL which defines the minimum interval. Since we've been using two different intervals pick the longer of them and define AUX_RETRY_INTERVAL as 500 us. For the maximum just use AUX_RETRY_INTERVAL+100 us. I want to have a define for this so that I can use it when calculating the estimated duration of i2c-over-aux transfers. Without a define it would be very easy to change the sleep duration and neglect to update the i2c-over-aux estimates. Cc: Simon Farnsworth <simon.farnsworth@onelan.com> Cc: moosotc@gmail.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Simon Farnsworth <simon.farnsworth@onelan.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
-
- 01 Sep, 2015 1 commit
-
-
Maarten Lankhorst authored
Commit ec9f932e "drm/atomic: Cleanup on error properly in the atomic ioctl." cleaned up some error paths, but didn't fix the TEST_ONLY path. In the check only case plane->fb shouldn't be updated, and the vblank events should be cleared as on failure. Changes since v1: - Fix -EDEADLK handling of vblank events too. - Free state last with CHECK_ONLY. Changes since v2: - Add comment about freeing crtc_state->event with TEST_ONLY. (Daniel Stone) Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
-
- 31 Aug, 2015 3 commits
-
-
Dave Airlie authored
Merge branch 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next This is a second pull-request which adds last part of atomic modeset/pageflip support, render node support, clean-up, and fix-up. * 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos: drm/exynos: fix build warning to exynos_drm_gem.c drm/exynos: Properly report supported formats for each device drm/exynos: add render node support drm/exynos: implement atomic_{begin/flush} of DECON drm/exynos: remove legacy ->suspend()/resume() drm/exynos: Enable atomic modesetting feature drm/exynos: remove wait queue for pending page flip drm/exynos: wait all planes updates to finish drm/exynos: add atomic asynchronous commit drm/exynos: fimd: only finish update if START == START_S drm/exynos: add macro to get the address of START_S reg drm/exynos: check for pending fb before finish update drm/exynos: fimd: move window protect code to prepare/cleanup_plane drm/exynos: add prepare and cleanup phases for planes drm/exynos: fimd: unify call to exynos_drm_crtc_finish_pageflip() drm/exynos: don't track enabled state at exynos_crtc
-
Dave Airlie authored
Merge tag 'drm-intel-next-fixes-2015-08-28' of git://anongit.freedesktop.org/drm-intel into drm-next Some i915 fixes headed for v4.3. SKL DDI-E is a wip, but here's the first in a series. * tag 'drm-intel-next-fixes-2015-08-28' of git://anongit.freedesktop.org/drm-intel: drm/i915/skl: enable DDI-E hotplug drm/i915: Fix build warning on 32-bit drm/i915/skl: Update DDI buffer translation programming. drm/i915: Allow parsing of variable size child device entries from VBT drm/i915: fix link rates reported for SKL drm/i915: fix VBT parsing for SDVO child device mapping
-
Dave Airlie authored
Merge tag 'drm-amdkfd-next-fixes-2015-08-30' of git://people.freedesktop.org/~gabbayo/linux into drm-next Just one small fix before 4.3 merge window: - Use linux/mman.h instead of uapi's mman-common.h inside the driver. * tag 'drm-amdkfd-next-fixes-2015-08-30' of git://people.freedesktop.org/~gabbayo/linux: amdkfd: use <linux/mman.h> instead of <uapi/asm-generic/mman-common.h>
-
- 30 Aug, 2015 17 commits
-
-
Inki Dae authored
Signed-off-by: Inki Dae <daeinki@gmail.com>
-
Marek Szyprowski authored
Exynos DRM reported that all planes for all supported sub-devices supports only three pixel formats: XRGB24, ARGB24 and NV12. This patch lets each Exynos DRM sub-drivers to provide the list of supported pixel formats and registers this list to DRM core. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
-
Joonyoung Shim authored
This patch allows clients who want to use render node to access rendering relevant ioctls - g2d, post processor and gem allocation. Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
-
Hyungwon Hwang authored
Each CRTC's atomic_{begin/flush} must stop/start the update of shadow registers to active register in the functions. This patch achieves these purpose by moving the setting of protection bits to those functions from decon_update_plane. v2: rebased to the branch exynos-drm-next Signed-off-by: Hyungwon Hwang <human.hwang@samsung.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
-
Gustavo Padovan authored
These legacy helpers should only be used by shadow-attaching drivers. KMS drivers has its own way to handle suspend/resume and don't need to use these two helpers. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <daeinki@gmail.com>
-
Gustavo Padovan authored
From: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Now that atomic modesetting is implemented for exynos enable the DRIVER_ATOMIC flag on the driver's features. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
-
Gustavo Padovan authored
Exynos atomic commit procedures already does this job of waiting for pending updates to finish, that means using pending_flip_queue is pointless now because the disable CRTC procedure will never happen during a page_flip. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
-
Gustavo Padovan authored
Add infrastructure to wait for all planes updates to finish by using an atomic_t variable to track how many pending updates we are waiting plus a wait_queue for the wait part. It also changes vblank behaviour and keeps it enabled for all types of updates Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
-
Gustavo Padovan authored
The atomic modesetting interfaces supports async commits that should be implemented by the drivers. If drm core requests an async commit exynos_atomic_commit() will now schedule a work task to run the update later. It also serializes commits that needs to run on the same crtc, putting the following commit to wait until the current one is finished. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
-
Gustavo Padovan authored
fimd_update_plane() programs BUF_START[win] and during the update BUF_START[win] is copied to BUF_START_S[win] (its shadow register) and starts scanning out, then it raises a irq. The fimd_irq_handler, in the case we have a pending_fb, will check the fb value was copied to START_S register and finish the update in case of success. Based on patch from Daniel Kurtz <djkurtz@chromium.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
-
Gustavo Padovan authored
This macro is need to get the value of the START shadow register, that will tell if an framebuffer is currently displayed on the screen or not. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
-
Gustavo Padovan authored
The current code was ignoring the end of update for all overlay planes, caring only for the primary plane update in case of pageflip. This change adds a change to start to check for pending updates for all planes through exynos_plane->pending_fb. At the start of plane update the pending_fb is set with the fb to be shown on the screen. Then only when to fb is already presented in the screen we set pending_fb to NULL to signal that the update was finished. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com> fixup! drm/exynos: check for pending fb before finish update
-
Gustavo Padovan authored
Only set/clear the update bit in the CRTC's .atomic_begin()/flush() so all planes are really committed at the same time. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
-
Gustavo Padovan authored
From: Gustavo Padovan <gustavo.padovan@collabora.co.uk> .prepare_plane() and .cleanup_plane() allows to perform extra operations before and after the update of planes. For FIMD for example this will be used to enable disable the shadow protection bit. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
-
Gustavo Padovan authored
Unify handling of finished plane update to prepare for a following patch that will check for the START and START_S regs to really make sure that the plane was updated. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
-
Gustavo Padovan authored
struct drm_crtc already stores the enabled state of the crtc thus we don't need to replicate enabled in exynos_drm_crtc. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
-
Christoph Hellwig authored
The latter is a default version of <asm/mman.h> and not for driver use. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
-
- 28 Aug, 2015 16 commits
-
-
Dave Airlie authored
align with mask code in overlay.c, Ben can clean the naming up later if necessary. Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Dave Airlie authored
Reported-by: Ilia Mirkin on irc. Signed-off-by: Dave Airlie <airlied@redhat.com>
-
git://anongit.freedesktop.org/git/nouveau/linux-2.6Dave Airlie authored
Rather large pull request this time around, due to the long-pending cleanup of the kernel driver being here. There's a stupidly large number of commits for that, as I wanted to have the series be bisectable at a fairly fine-grained level. That said, a very large portion of the churn in the rework was automated, and a very large number of boards from right across the whole range we support have been tested. I'm fairly confident there shouldn't be (too many) issues from this. Beyond correcting some not-so-great design decisions and making the code a lot easier to work with, there's not much exciting (lower memory usage, GPU VM should be a lot faster, etc) to be gained by the end-user as a result of the cleanup, it mostly lays the groundwork for future improvements. A big thanks goes to Alexandre Courbot for testing/debugging the GK20A codepaths for me :) Highlights: - A heap of perfmon work, providing a more useful userspace interface and specifying counters for a bunch of boards - Support for GT200 reclocking + other misc pm improvements - Initial patches towards supporting GM20B (Tegra X1) - Maxwell DisplayPort fixes - Cleanup of the kernel driver - The usual collection of random fixes * 'linux-4.3' of git://anongit.freedesktop.org/git/nouveau/linux-2.6: (312 commits) drm/nouveau: bump driver version for release drm/nouveau/tegra: merge platform setup from nouveau drm drm/nouveau/pci: merge agp handling from nouveau drm drm/nouveau/device: remove pci/platform_device from common struct drm/nouveau/device: import pciid list and integrate quirks with it drm/nouveau/device: cleaner abstraction for device resource functions drm/nouveau/mc: move device irq handling to platform-specific code drm/nouveau/mc/gf100-: handle second interrupt tree drm/nouveau/mc: abstract interface to master intr registers drm/nouveau/pci: new subdev drm/nouveau/object: merge with handle drm/nouveau/core: remove the remainder of the previous style drm/nouveau/mpeg: convert to new-style nvkm_engine drm/nouveau/sw: convert to new-style nvkm_engine drm/nouveau/pm: convert to new-style nvkm_engine drm/nouveau/gr: convert to new-style nvkm_engine drm/nouveau/fifo: convert to new-style nvkm_engine drm/nouveau/disp: convert to new-style nvkm_engine drm/nouveau/dma: convert to new-style nvkm_engine drm/nouveau/cipher: convert to new-style nvkm_engine ...
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
The copyright header in nvkm/engine/device/platform.c has been replaced with the NVIDIA one from drm/nouveau_platform.c, as most of the actual code is now theirs. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
This commit reinstates the pre-DEVINIT AGP fiddling that was broken in an earlier commit. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
PCI IDs taken from the NVIDIA binary driver, with permission. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Doesn't fix any known issue, but best be safe in case control is handed to us from firmware with these left enabled. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-