drm/i915: Do not use lock all in hsw_trans_edp_pipe_A_crc_wa
There is no need to acquire all locks here,
doing a commit after forcing a modeset on the affected crtc
is enough. Any other locks needed will be acquired as needed.
mode_config.mutex was originally added to fix WARNs in connector
functions, but now that atomic nonblocking modeset support is
included, we will likely never hold any any lock at all.
The WARN mentioned in commit bbf35e9defb9a6d1 ("drm/i915:
Pass atomic state to intel_audio_codec_enable, v2."), so it's
safe to revert this now.
Those properties are not hooked up on MST and were ignored. Best not expose them at all.
Without this the next patch fails to start on X.org, because the DP-MST properties could
not be read.
drm/i915: Convert intel_tv connector properties to atomic, v5.
intel_tv has properties that are handled in the atomic core, but
needs a modeset to update the properties inside the connector.
The detect(), get_mode() and mode_valid() probe callbacks also
depend on the connector state, which made this a good connector
to convert first. It helped find all the issues when converting
connectors to atomic.
Because of these requirements, connector atomic_check() was added
and connection_mutex is held during probing. The diffstat looks
more favorable now. :)
Changes since v1:
- Add intel_encoder->swap_state to allow updating connector state.
- Add intel_tv->format for detect_mode and mode_valid, updated on atomic commit.
Changes since v2:
- Fix typo in tv_choose_preferred modes function name.
- Assignment of tv properties is done in core, so intel_tv only needs
a atomic_check function. Thanks Ville!
Changes since v3:
- connection_mutex is now held in mode_valid() and get_modes(),
this removes the need for caching parts of the connector_state.
Changes since v4:
- Use the new atomic connector check function.
drm/i915: Remove dead KMS encoder save/restore code.
This was brought over from UMS, and used for a while until we decided
that drm_helper_resume_force_mode was easier and more reliable, since
it didn't require duplicating all the code deleted here. We just
forgot to delete all that junk for a while.
Chris Wilson [Tue, 11 Apr 2017 17:58:50 +0000 (18:58 +0100)]
drm/i915/execlists: Document runtime pm for intel_lrc_irq_handler()
We indirectly hold the runtime-pm for the intel_lrc_irq_handler() by
virtue of dev_priv->gt.awake keeping a wakeref whilst the requests are
busy. As this is not obvious from the code, add a comment.
Daniel Vetter [Wed, 12 Apr 2017 08:07:43 +0000 (10:07 +0200)]
Merge airlied/drm-next into drm-intel-next-queued
Maarten needs both the new connector->atomic_check hook and the
connection_mutex locking changes in the probe helpers to be able to
start merging the connector property conversion to atomic.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Tue, 11 Apr 2017 19:00:42 +0000 (20:00 +0100)]
drm/i915: Lie and treat all engines as idle if wedged
Similar to commit 8490ae207f1d ("drm/i915: Suppress busy status for
engines if wedged") we also want to report intel_engine_is_idle() as
true as well as the main intel_engines_are_idle(), as we now check that
the engines are idle when overwriting the HWS page. This is not true
whilst we are setting the device as wedged, at least according to our
bookkeeping, so we have to lie to ourselves!
drm/i915: Use the engine class to get the context size
Technically speaking, the context size is per engine class, not per
instance.
v2: Add MISSING_CASE (Tvrtko)
v3: Rebased
v4: Restore the interface back to hiding the class lookup (Chris)
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1491905472-16189-1-git-send-email-oscar.mateo@intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson [Tue, 11 Apr 2017 16:56:58 +0000 (17:56 +0100)]
drm/i915: Bail if we do not setup the RCS engine
In places, we assume that RCS exists. This has been true forever, but
let us catch this failure during bringup by adding an explicit check
that we do have an RCS engine.
Jani Nikula [Thu, 6 Apr 2017 13:44:13 +0000 (16:44 +0300)]
drm/i915/dp: add functions for max common link rate and lane count
These are the theoretical maximums common for source and sink. These are
the maximums we should start with. They may be degraded in case of link
training failures, and the dynamic link values are stored separately.
Jani Nikula [Thu, 6 Apr 2017 13:44:11 +0000 (16:44 +0300)]
drm/i915/dp: do not limit rate seek when not needed
In link training fallback, we're trying to find a rate that we know is
in a sorted array of common link rates. We don't need to limit the array
using the max rate. For test request, the DP CTS doesn't say we should
limit the rate based on earlier fallback. This lets us get rid of
intel_dp_link_rate_index() and use intel_dp_rate_index() instead.
Jani Nikula [Thu, 6 Apr 2017 13:44:10 +0000 (16:44 +0300)]
drm/i915/dp: cache common rates with sink rates
Now that source rates are static and sink rates are updated whenever
DPCD is updated, we can do and cache the intersection of them whenever
sink rates are updated. This reduces code complexity, as we don't have
to keep calling the functions to intersect. We also get rid of several
common rates arrays on stack.
Limiting the common rates by a max link rate can be done by picking the
first N elements of the cached common rates.
v2: get rid of the local common_rates variable (Manasi)
v3: don't clobber cached eDP rates on short pulse (Ville)
Jani Nikula [Thu, 6 Apr 2017 13:44:09 +0000 (16:44 +0300)]
drm/i915/dp: use the sink rates array for max sink rates
Looking at DPCD DP_MAX_LINK_RATE may be completely bogus for eDP 1.4
which is allowed to use link rate select method and have 0 in max link
rate. With this change, it makes sense to store the max rate as the
actual rate rather than as a bw code.
Chris Wilson [Tue, 11 Apr 2017 12:43:06 +0000 (13:43 +0100)]
drm/i915: Rename intel_engine_cs.exec_id to uabi_id
We want to refer to the index of the engine consistently throughout the
userspace ABI. We already have such an index through the execbuffer
engine specifier, that needs to be able to refer to each engine
specifically, so rename it the index to uabi_id to reflect its
generality beyond execbuf.
Oscar Mateo [Mon, 10 Apr 2017 14:34:32 +0000 (07:34 -0700)]
drm/i915: Split the engine info table in two levels, using class + instance
There are some properties that logically belong to the engine class, and some
that belong to the engine instance. Make it explicit.
v2: Commit message (Tvrtko)
v3:
- Rebased
- Exec/uabi id should be per instance (Chris)
v4:
- Rebased
- Avoid re-ordering fields for smaller diff (Tvrtko)
- Bug on oob access to the class array (Michal)
v5: Bug on the right thing (Michal)
v6: Rebased
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1491834873-9345-5-git-send-email-oscar.mateo@intel.com Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Oscar Mateo [Mon, 10 Apr 2017 14:34:31 +0000 (07:34 -0700)]
drm/i915: Generate the engine name based on the instance number
Not really needed, but makes the next change a little bit more compact.
v2:
- Use zero-based numbering for engine names: xcs0, xcs1.. xcsN (Tvrtko, Chris)
- Make sure the mock engine name is null-terminated (Tvrtko, Chris)
v3: Because I'm stupid (Chris)
v4: Verify engine name wasn't truncated (Michal)
v5:
- Kill the warning in mock engine (Chris)
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1491834873-9345-4-git-send-email-oscar.mateo@intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Oscar Mateo [Mon, 10 Apr 2017 14:34:30 +0000 (07:34 -0700)]
drm/i915: Use the same vfunc for BSD2 ring init
If we needed to do something different for the init functions, we could
always look at the engine instance to make the distinction. But, in any
case, the two functions are virtually identical already (please notice
that BSD2_RING is only used from gen8 onwards).
With this, the init functions depends excusively on the engine class
(a fact that we will use soon).
v2: Commit message
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1491834873-9345-3-git-send-email-oscar.mateo@intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
drm/i915: Classify the engines in class + instance
In such a way that vcs and vcs2 are just two different instances (0 and 1)
of the same engine class (VIDEO_DECODE_CLASS).
v2: Align the instance types (Tvrtko)
v3: Don't use enums for bspec-defined stuff (Michal)
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1491834873-9345-2-git-send-email-oscar.mateo@intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson [Tue, 11 Apr 2017 10:13:40 +0000 (11:13 +0100)]
drm/i915: Use safer intel_uncore_wait_for_register in ring-init
While we do hold the forcewake for legacy ringbuffer initialisation, we
don't guard our access with the uncore.lock spinlock. In theory, we only
initialise when no others should be accessing the same mmio cachelines,
but in practice be safe as this is an infrequently used path and not
worth risky micro-optimisations.
Chris Wilson [Tue, 11 Apr 2017 10:13:39 +0000 (11:13 +0100)]
drm/i915: Use __intel_uncore_wait_for_register_fw for sandybride_pcode_read
Since the sandybridge_pcode_read() may be called from
skl_pcode_request() inside an atomic context (with preempt disabled), we
should avoid hitting any sleeping paths. Currently is being called with
a 500ms timeout, irrespective of being inside an atomic context or not.
This is reduced down to 500us to play nice with the atomic context, and
that appears to be sufficient to keep BAT happy (we have a DRM_ERROR
should it timeout), i.e. we do not see any 500us pcode timeouts for
normal use. So leave it as a pure spin without having to introduce new
code paths to separate atomic/normal contexts.
Chris Wilson [Tue, 11 Apr 2017 10:13:38 +0000 (11:13 +0100)]
drm/i915: Acquire uncore.lock over intel_uncore_wait_for_register()
We acquire the forcewake and use I915_READ_FW instead for the atomic
wait within intel_uncore_wait_for_register. However, this still leaves
us vulnerable to concurrent mmio access to the register, which can cause
system hangs on gen7. The protection is to acquire uncore.lock around
each register, so lets add it back.
v2: Wrap __intel_wait_for_register_fw() to re-use its atomic wait_for
loop and spare adding another for ourselves.
v3: Add might_sleep() annotation
Chris Wilson [Tue, 11 Apr 2017 10:13:37 +0000 (11:13 +0100)]
drm/i915: Stop sleeping from inside gen6_bsd_submit_request()
submit_request() is called from an atomic context, it's not allowed to
sleep. We have to be careful in our parameters to
intel_uncore_wait_for_register() to limit ourselves to the atomic wait
loop and not incur the wrath of our warnings.
Chris Wilson [Tue, 11 Apr 2017 11:27:05 +0000 (12:27 +0100)]
drm/i915: Stop second guessing the caller for intel_uncore_wait_for_register()
Allow the caller to use the fast_timeout_us to specify how long to wait
within the atomic section, rather than transparently switching to a
sleeping loop for larger values. This is required as some callsites may
need a long wait and are in an atomic section.
v2: Reinforce kerneldoc fast_timeout_us limit with a GEM_BUG_ON
Dave Airlie [Mon, 10 Apr 2017 21:47:02 +0000 (07:47 +1000)]
Merge branch 'msm-next' of git://people.freedesktop.org/~robclark/linux into drm-next
Noteworthy changes this time:
1) 4k support for newer chips (ganging up hwpipes and mixers)
2) using OPP bindings for gpu
3) more prep work towards per-process pagetables
* 'msm-next' of git://people.freedesktop.org/~robclark/linux: (47 commits)
msm/drm: gpu: Dynamically locate the clocks from the device tree
drm/msm: gpu: Use OPP tables if we can
drm/msm: Hard code the GPU "slow frequency"
drm/msm: Add MSM_PARAM_GMEM_BASE
drm/msm: Reference count address spaces
drm/msm: Make sure to detach the MMU during GPU cleanup
drm/msm/mdp5: Enable 3D mux in mdp5_ctl
drm/msm/mdp5: Reset CTL blend registers before configuring them
drm/msm/mdp5: Assign 'right' mixer to CRTC state
drm/msm/mdp5: Stage border out on base stage if CRTC has 2 LMs
drm/msm/mdp5: Stage right side hwpipes on Right-side Layer Mixer
drm/msm/mdp5: Prepare Layer Mixers for source split
drm/msm/mdp5: Configure 'right' hwpipe
drm/msm/mdp5: Assign a 'right hwpipe' to plane state
drm/msm/mdp5: Create mdp5_hwpipe_mode_set
drm/msm/mdp5: Add optional 'right' Layer Mixer in CRTC state
drm/msm/mdp5: Add a CAP for Source Split
drm/msm/mdp5: Remove mixer/intf pointers from mdp5_ctl
drm/msm/mdp5: Start using parameters from CRTC state
drm/msm/mdp5: Add more stuff to CRTC state
...
Dave Airlie [Mon, 10 Apr 2017 21:41:10 +0000 (07:41 +1000)]
Merge tag 'drm-misc-next-2017-04-07' of git://anongit.freedesktop.org/git/drm-misc into drm-next
Last drm-misc-next pull req for 4.12
Core changes:
- fb_helper checkpatch cleanup and simplified _add_one_connector() (Thierry)
- drm_ioctl and drm_sysfs improved/gained documentation (Daniel)
- [ABI] Repurpose reserved field in drm_event_vblank for crtc_id (Ander)
- Plumb acquire ctx through legacy paths to avoid lock_all and legacy_backoff
(Daniel)
- Add connector_atomic_check to check conn constraints on modeset (Maarten)
- Add drm_of_find_panel_or_bridge to remove boilerplate in drivers (Rob)
Driver changes:
- meson moved to drm-misc (Neil)
- Added support for Amlogic GX SoCs in dw-hdmi (Neil)
- Rockchip unbind actually cleans up the things bind initializes (Jeffy)
- A couple misc fixes in virtio, dw-hdmi
NOTE: this also includes a backmerge of drm-next as well rc5 (we needed vmwgfx
as well as the new synopsys media formats)
* tag 'drm-misc-next-2017-04-07' of git://anongit.freedesktop.org/git/drm-misc: (77 commits)
Revert "drm: Don't allow interruptions when opening debugfs/crc"
drm: Only take cursor locks when the cursor plane exists
drm/vmwgfx: Fix fbdev emulation using legacy functions
drm/rockchip: Shutdown all crtcs when unbinding drm
drm/rockchip: Reorder drm bind/unbind sequence
drm/rockchip: analogix_dp: Disable clock when unbinding
drm/rockchip: vop: Unprepare clocks when unbinding
drm/rockchip: vop: Enable pm domain before vop_initial
drm/rockchip: cdn-dp: Don't unregister audio dev when unbinding
drm/rockchip: cdn-dp: Don't try to release firmware when not loaded
drm: bridge: analogix: Destroy connector & encoder when unbinding
drm: bridge: analogix: Disable clock when unbinding
drm: bridge: analogix: Unregister dp aux when unbinding
drm: bridge: analogix: Detach panel when unbinding analogix dp
drm: Don't allow interruptions when opening debugfs/crc
drm/virtio: don't leak bo on drm_gem_object_init failure
drm: bridge: dw-hdmi: fix input format/encoding from plat_data
drm: omap: use common OF graph helpers
drm: convert drivers to use drm_of_find_panel_or_bridge
drm: convert drivers to use of_graph_get_remote_node
...
Dave Airlie [Mon, 10 Apr 2017 21:31:18 +0000 (07:31 +1000)]
Merge branch 'drm-next-4.12' of git://people.freedesktop.org/~agd5f/linux into drm-next
Just some bug fixes and vega10 updates for 4.12.
* 'drm-next-4.12' of git://people.freedesktop.org/~agd5f/linux:
drm/amdgpu: fix fence memory leak in wait_all_fence V2
drm/amdgpu: fix "fix 64bit division"
drm/amd/powerplay: add fan controller table v11 support.
drm/amd/powerplay: port newest process pptable code for vega10.
drm/amdgpu: set vm size and block size by individual gmc by default (v3)
drm/amdgpu: Avoid overflows/divide-by-zero in latency_watermark calculations.
drm/amdgpu: Make display watermark calculations more accurate
drm/radeon: fix typo in bandwidth calculation
drm/radeon: Refuse to migrate a prime BO to VRAM. (v2)
drm/radeon: Maintain prime import/export refcount for BOs
drm/amdgpu: Refuse to pin or change acceptable domains of prime BOs to VRAM. (v2)
drm/amdgpu: Fail fb creation from imported dma-bufs. (v2)
drm/radeon: Fail fb creation from imported dma-bufs.
Dave Airlie [Mon, 10 Apr 2017 21:28:01 +0000 (07:28 +1000)]
Merge tag 'drm-intel-testing-2017-04-03' of git://anongit.freedesktop.org/git/drm-intel into drm-next
Last 4.12 feature pile:
GVT updates:
- Add mdev attribute group for per-vgpu info
- Time slice based vGPU scheduling QoS support (Gao Ping)
- Initial KBL support for E3 server (Han Xu)
- other misc.
i915:
- lots and lots of small fixes and improvements all over
- refactor fw_domain code (Chris Wilson)
- improve guc code (Oscar Mateo)
- refactor cursor/sprite code, precompute more for less overhead in
the critical path (Ville)
- refactor guc/huc fw loading code a bit (Michal Wajdeczko)
* tag 'drm-intel-testing-2017-04-03' of git://anongit.freedesktop.org/git/drm-intel: (121 commits)
drm/i915: Update DRIVER_DATE to 20170403
drm/i915: Clear gt.active_requests before checking idle status
drm/i915/uc: Drop use of MISSING_CASE on trivial enums
drm/i915: make a few DDI functions static
drm/i915: Combine reset_all_global_seqno() loops into one
drm/i915: Remove redudant wait for each engine to idle from seqno wrap
drm/i915: Wait for all engines to be idle as part of i915_gem_wait_for_idle()
drm/i915: Move retire-requests into i915_gem_wait_for_idle()
drm/i915/uc: Move fw path check to fetch_uc_fw()
drm/i915/huc: Remove unused intel_huc_fini()
drm/i915/uc: Add intel_uc_fw_fini()
drm/i915/uc: Add intel_uc_fw_type_repr()
drm/i915/uc: Move intel_uc_fw_status_repr() to intel_uc.h
drivers: gpu: drm: i915L intel_lpe_audio: Fix kerneldoc comments
drm/i915: Suppress busy status for engines if wedged
drm/i915: Do request retirement before marking engines as wedged
drm/i915: Drop verbose and archaic "ring" from our internal engine names
drm/i915: Use a dummy timeline name for a signaled fence
drm/i915: Ironlake do_idle_maps w/a may be called w/o struct_mutex
drm/i915/guc: Take enable_guc_loading check out of GEM core code
...
Dave Airlie [Mon, 10 Apr 2017 20:32:11 +0000 (06:32 +1000)]
Merge branch 'drm-next-4.12' of https://github.com/ckhu-mediatek/linux.git-tags into drm-next
This series is MT2701 DRM support.
* 'drm-next-4.12' of https://github.com/ckhu-mediatek/linux.git-tags:
drm/mediatek: add support for Mediatek SoC MT2701
drm/mediatek: update DSI sub driver flow for sending commands to panel
drm/mediatek: add non-continuous clock mode and EOT packet control
drm/mediatek: add dsi transfer function
drm/mediatek: add dsi interrupt control
drm/mediatek: cleaning up and refine
drm/mediatek: update display module connections
drm/mediatek: add BLS component
drm/mediatek: add shadow register support
drm/mediatek: add *driver_data for different hardware settings
drm/mediatek: add helpers for coverting from the generic components
dt-bindings: display: mediatek: update supported chips
Michal Wajdeczko [Mon, 10 Apr 2017 09:38:17 +0000 (09:38 +0000)]
drm/i915: Drop const qualifiers from params in wait_for_register()
These params are passed by value, const qualifiers are ignored any way.
While around, unify timeout_ms type from long to int.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Suggested-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170410093817.151280-1-michal.wajdeczko@intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Merge branch 'for-next' of git://git.samba.org/sfrench/cifs-2.6
Pull CIFS fixes from Steve French:
"This is a set of CIFS/SMB3 fixes for stable.
There is another set of four SMB3 reconnect fixes for stable in
progress but they are still being reviewed/tested, so didn't want to
wait any longer to send these five below"
* 'for-next' of git://git.samba.org/sfrench/cifs-2.6:
Reset TreeId to zero on SMB2 TREE_CONNECT
CIFS: Fix build failure with smb2
Introduce cifs_copy_file_range()
SMB3: Rename clone_range to copychunk_range
Handle mismatched open calls
Merge branch 'fixes' of git://git.armlinux.org.uk/~rmk/linux-arm
Pull ARM fixes from Russell King:
"A number of ARM fixes:
- prevent oopses caused by dma_get_sgtable() and declared DMA
coherent memory
- fix boot failure on nommu caused by ID_PFR1 access
- a number of kprobes fixes from Jon Medhurst and Masami Hiramatsu"
* 'fixes' of git://git.armlinux.org.uk/~rmk/linux-arm:
ARM: 8665/1: nommu: access ID_PFR1 only if CPUID scheme
ARM: dma-mapping: disallow dma_get_sgtable() for non-kernel managed memory
arm: kprobes: Align stack to 8-bytes in test code
arm: kprobes: Fix the return address of multiple kretprobes
arm: kprobes: Skip single-stepping in recursing path if possible
arm: kprobes: Allow to handle reentered kprobe on single-stepping
Merge tag 'driver-core-4.11-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
Pull driver core fixes from Greg KH:
"Here are 3 small fixes for 4.11-rc6.
One resolves a reported issue with sysfs files that NeilBrown found,
one is a documenatation fix for the stable kernel rules, and the last
is a small MAINTAINERS file update for kernfs"
* tag 'driver-core-4.11-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
MAINTAINERS: separate out kernfs maintainership
sysfs: be careful of error returns from ops->show()
Documentation: stable-kernel-rules: fix stable-tag format
Merge tag 'staging-4.11-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
Pull staging/IIO driver rfixes from Greg KH:
"Here are a number of small IIO and staging driver fixes for 4.11-rc6.
Nothing big here, just iio fixes for reported issues, and an ashmem
fix for a very old bug that has been reported by a number of Android
vendors"
* tag 'staging-4.11-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
staging: android: ashmem: lseek failed due to no FMODE_LSEEK.
iio: hid-sensor-attributes: Fix sensor property setting failure.
iio: accel: hid-sensor-accel-3d: Fix duplicate scan index error
iio: core: Fix IIO_VAL_FRACTIONAL_LOG2 for negative values
iio: st_pressure: initialize lps22hb bootime
iio: bmg160: reset chip when probing
iio: cros_ec_sensors: Fix return value to get raw and calibbias data.
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
Pull VFS fixes from Al Viro:
"statx followup fixes and a fix for stack-smashing on alpha"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
alpha: fix stack smashing in old_adjtimex(2)
statx: Include a mask for stx_attributes in struct statx
statx: Reserve the top bit of the mask for future struct expansion
xfs: report crtime and attribute flags to statx
ext4: Add statx support
statx: optimize copy of struct statx to userspace
statx: remove incorrect part of vfs_statx() comment
statx: reject unknown flags when using NULL path
Documentation/filesystems: fix documentation for ->getattr()
Merge branch 'for-linus' of git://git.kernel.dk/linux-block
Pull block fixes from Jens Axboe:
"Here's a pull request for 4.11-rc, fixing a set of issues mostly
centered around the new scheduling framework. These have been brewing
for a while, but split up into what we absolutely need in 4.11, and
what we can defer until 4.12. These are well tested, on both single
queue and multiqueue setups, and with and without shared tags. They
fix several hangs that have happened in testing.
This is obviously larger than I would have preferred at this point in
time, but I don't think we can shave much off this and still get the
desired results.
In detail, this pull request contains:
- a set of five fixes for NVMe, mostly from Christoph and one from
Roland.
- a series from Bart, fixing issues with dm-mq and SCSI shared tags
and scheduling. Note that one of those patches commit messages may
read like an optimization, but it is in fact an important fix for
queue restarts in particular.
- a series from Omar, most importantly fixing a hang with multiple
hardware queues when we fail to get a driver tag. Another important
fix in there is for resizing hardware queues, which nbd does when
handling multiple sockets for one connection.
- fixing an imbalance in putting the ctx for hctx request allocations
from Minchan"
* 'for-linus' of git://git.kernel.dk/linux-block:
blk-mq: Restart a single queue if tag sets are shared
dm rq: Avoid that request processing stalls sporadically
scsi: Avoid that SCSI queues get stuck
blk-mq: Introduce blk_mq_delay_run_hw_queue()
blk-mq: remap queues when adding/removing hardware queues
blk-mq-sched: fix crash in switch error path
blk-mq-sched: set up scheduler tags when bringing up new queues
blk-mq-sched: refactor scheduler initialization
blk-mq: use the right hctx when getting a driver tag fails
nvmet: fix byte swap in nvmet_parse_io_cmd
nvmet: fix byte swap in nvmet_execute_write_zeroes
nvmet: add missing byte swap in nvmet_get_smart_log
nvme: add missing byte swap in nvme_setup_discard
nvme: Correct NVMF enum values to match NVMe-oF rev 1.0
block: do not put mq context in blk_mq_alloc_request_hctx
Merge tag 'pinctrl-v4.11-4' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
Pull pin control fix from Linus Walleij:
"This late fix for pin control is hopefully the last I send this cycle.
The problem was detected early in the v4.11 release cycle and there
has been some back and forth on how to solve it. Sadly the proper fix
arrives late, but at least not too late.
An issue was detected with pin control on the Freescale i.MX after the
refactorings for more general group and function handling.
We now have the proper fix for this"
* tag 'pinctrl-v4.11-4' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
pinctrl: core: Fix pinctrl_register_and_init() with pinctrl_enable()
Merge tag 'powerpc-4.11-7' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux
Pull powerpc fixes from Michael Ellerman:
"Some more powerpc fixes for 4.11:
Headed to stable:
- disable HFSCR[TM] if TM is not supported, fixes a potential host
kernel crash triggered by a hostile guest, but only in
configurations that no one uses
- don't try to fix up misaligned load-with-reservation instructions
- fix flush_(d|i)cache_range() called from modules on little endian
kernels
- add missing global TLB invalidate if cxl is active
- fix missing preempt_disable() in crc32c-vpmsum
And a fix for selftests build changes that went in this release:
- selftests/powerpc: Fix standalone powerpc build
Thanks to: Benjamin Herrenschmidt, Frederic Barrat, Oliver O'Halloran,
Paul Mackerras"
* tag 'powerpc-4.11-7' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
powerpc/crypto/crc32c-vpmsum: Fix missing preempt_disable()
powerpc/mm: Add missing global TLB invalidate if cxl is active
powerpc/64: Fix flush_(d|i)cache_range() called from modules
powerpc: Don't try to fix up misaligned load-with-reservation instructions
powerpc: Disable HFSCR[TM] if TM is not supported
selftests/powerpc: Fix standalone powerpc build
Chris Salls [Sat, 8 Apr 2017 06:48:11 +0000 (23:48 -0700)]
mm/mempolicy.c: fix error handling in set_mempolicy and mbind.
In the case that compat_get_bitmap fails we do not want to copy the
bitmap to the user as it will contain uninitialized stack data and leak
sensitive data.
Signed-off-by: Chris Salls <salls@cs.ucsb.edu> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
sysfs: be careful of error returns from ops->show()
ops->show() can return a negative error code.
Commit 65da3484d9be ("sysfs: correctly handle short reads on PREALLOC attrs.")
(in v4.4) caused this to be stored in an unsigned 'size_t' variable, so errors
would look like large numbers.
As a result, if an error is returned, sysfs_kf_read() will return the
value of 'count', typically 4096.
Commit 17d0774f8068 ("sysfs: correctly handle read offset on PREALLOC attrs")
(in v4.8) extended this error to use the unsigned large 'len' as a size for
memmove().
Consequently, if ->show returns an error, then the first read() on the
sysfs file will return 4096 and could return uninitialized memory to
user-space.
If the application performs a subsequent read, this will trigger a memmove()
with extremely large count, and is likely to crash the machine is bizarre ways.
This bug can currently only be triggered by reading from an md
sysfs attribute declared with __ATTR_PREALLOC() during the
brief period between when mddev_put() deletes an mddev from
the ->all_mddevs list, and when mddev_delayed_delete() - which is
scheduled on a workqueue - completes.
Before this, an error won't be returned by the ->show()
After this, the ->show() won't be called.
I can reproduce it reliably only by putting delay like
usleep_range(500000,700000);
early in mddev_delayed_delete(). Then after creating an
md device md0 run
echo clear > /sys/block/md0/md/array_state; cat /sys/block/md0/md/array_state
The bug can be triggered without the usleep.
Fixes: 65da3484d9be ("sysfs: correctly handle short reads on PREALLOC attrs.") Fixes: 17d0774f8068 ("sysfs: correctly handle read offset on PREALLOC attrs") Cc: stable@vger.kernel.org Signed-off-by: NeilBrown <neilb@suse.com> Acked-by: Tejun Heo <tj@kernel.org> Reported-and-tested-by: Miroslav Benes <mbenes@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Mon, 3 Apr 2017 13:53:34 +0000 (15:53 +0200)]
Documentation: stable-kernel-rules: fix stable-tag format
A patch documenting how to specify which kernels a particular fix should
be backported to (seemingly) inadvertently added a minus sign after the
kernel version. This particular stable-tag format had never been used
prior to this patch, and was neither present when the patch in question
was first submitted (it was added in v2 without any comment).
Drop the minus sign to avoid any confusion.
Fixes: fdc81b7910ad ("stable_kernel_rules: Add clause about specification of kernel versions to patch.") Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jordan Crouse [Tue, 7 Mar 2017 17:02:55 +0000 (10:02 -0700)]
drm/msm: gpu: Use OPP tables if we can
If a OPP table is defined for the GPU device in the device tree use
that in lieu of the downstream style GPU frequency table. If we do
use the downstream table convert it to a OPP table so that we can
take advantage of the OPP lookup facilities later.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
Jordan Crouse [Tue, 7 Mar 2017 17:02:54 +0000 (10:02 -0700)]
drm/msm: Hard code the GPU "slow frequency"
Some A3XX and A4XX GPU targets required that the GPU clock be
programmed to a non zero value when it was disabled so
27Mhz was chosen as the "invalid" frequency.
Even though newer targets do not have the same clock restrictions
we still write 27Mhz on clock disable and expect the clock subsystem
to round down to zero.
For unknown reasons even though the slow clock speed is always
27Mhz and it isn't actually a functional level the legacy device tree
frequency tables always defined it and then did gymnastics to work
around it.
Instead of playing the same silly games just hard code the "slow" clock
speed in the code as 27MHz and save ourselves a bit of infrastructure.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
Jordan Crouse [Tue, 7 Mar 2017 17:02:52 +0000 (10:02 -0700)]
drm/msm: Reference count address spaces
There are reasons for a memory object to outlive the file descriptor
that created it and so the address space that a buffer object is
attached to must also outlive the file descriptor. Reference count
the address space so that it can remain viable until all the objects
have released their addresses.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
Jordan Crouse [Mon, 6 Feb 2017 17:39:29 +0000 (10:39 -0700)]
drm/msm: Make sure to detach the MMU during GPU cleanup
We should be detaching the MMU before destroying the address
space. To do this cleanly, the detach has to happen in
adreno_gpu_cleanup() because it needs access to structs
in adreno_gpu.c. Plus it is better symmetry to have
the attach and detach at the same code level.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
Archit Taneja [Thu, 23 Mar 2017 10:28:17 +0000 (15:58 +0530)]
drm/msm/mdp5: Enable 3D mux in mdp5_ctl
3D mux is a small block placed after the DSPPs in MDP5. It can merge
2 LM/DSPP outputs and feed it to a single interface.
Enable 3D Mux if our mdp5_pipeline has 2 active LMs. This check
will need to be made more specific later when we add Dual DSI
support with source split enabled. In that use case, each LM feeds to a
separae INTF, so the 3D mux isn't needed.
Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
Archit Taneja [Thu, 23 Mar 2017 10:28:16 +0000 (15:58 +0530)]
drm/msm/mdp5: Reset CTL blend registers before configuring them
Assigning LMs dynamically to CRTCs results in REG_MDP5_CTL_LAYER_REGs
and REG_MDP5_CTL_LAYER_EXT_REGs maintaining old values for a LM that
isn't used by our CTL instance anymore.
Clear the ctl's CTL_LAYER_REG and CTL_LAYER_EXT_REGs for all LM
instances. The ones that need to be configured are configured later
in this func.
Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
Archit Taneja [Thu, 23 Mar 2017 10:28:15 +0000 (15:58 +0530)]
drm/msm/mdp5: Assign 'right' mixer to CRTC state
Dynamically assign a right mixer to mdp5_crtc_state in the CRTC's
atomic_check path. Assigning the right mixer has some constraints,
i.e, only a few LMs can be paired together. Update mdp5_mixer_assign
to handle these constraints.
Firstly, we need to identify whether we need a right mixer or not.
At the moment, there are 2 scenarios where a right mixer might be
needed:
- If any of the planes connected to this CRTC is too wide (i.e, is
comprised of 2 hwpipes).
- If the CRTC's mode itself is too wide (i.e, a 4K mode on HDMI).
We implement both these checks in the mdp5_crtc_atomic_check(), and
pass 'need_right_mixer' to mdp5_setup_pipeline.
If a CRTC is already assigned a single mixer, and a new atomic commit
brings in a drm_plane that needs 2 hwpipes, we can successfully commit
this mode without requiring a full modeset, provided that we still use
the previously assigned mixer as the left mixer. If such an assignment
isn't possible, we'd need to do a full modeset. This scenario has been
ignored for now.
The mixer assignment code is a bit messy, considering we have at most
4 LM instances in hardware. This can probably be re-visited later with
simplified logic.
Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
Archit Taneja [Thu, 23 Mar 2017 10:28:14 +0000 (15:58 +0530)]
drm/msm/mdp5: Stage border out on base stage if CRTC has 2 LMs
If a CRTC comprises of 2 LMs, it is mandatory to enable border out
and assign it to the base stage.
We had to enable border out also when the base plane wasn't fullscreen.
Club these checks and put them in a separate function called
get_start_stage() that returns the starting stage for assigning planes.
Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
Archit Taneja [Thu, 23 Mar 2017 10:28:12 +0000 (15:58 +0530)]
drm/msm/mdp5: Prepare Layer Mixers for source split
In order to enable Source Split in HW, we need to add/modify
a few LM register configurations:
- Configure the LM width to be half the mode width, so that
each LM manages one half of the scanout.
- Tell the 'right' LM that it is configured to be the 'right'
LM in source split mode.
- Since we now have 2 places where REG_MDP5_LM_BLEND_COLOR_OUT is
configured, do a read-update-store for the register instead of
directly writing a value to it.
Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
Archit Taneja [Thu, 23 Mar 2017 10:28:11 +0000 (15:58 +0530)]
drm/msm/mdp5: Configure 'right' hwpipe
Now that we have a right hwpipe in mdp5_plane_state, configure it
mdp5_plane_mode_set(). The only parameters that vary between the
left and right hwpipes are the src_w, src_img_w, src_x and crtc_x
as we just even chop the fb into left and right halves.
Add a mdp5_plane_right_pipe() which will be used by the crtc code
to set up LM stages.
Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
Archit Taneja [Thu, 23 Mar 2017 10:28:10 +0000 (15:58 +0530)]
drm/msm/mdp5: Assign a 'right hwpipe' to plane state
If the drm_plane has a source width that's greater than the max width
supported by a SSPP (2560 pixels on 8x96), then we assign a 'r_hwpipe'
to it in mdp5_plane_atomic_check().
TODO: There are a few scenarios where the hwpipe assignments aren't
recommended by HW. For example, an assignment which results in a
drm_plane to of two different types of hwpipes (say RGB0 on left
and DMA1 on right) is not recommended.
Also, hwpipes have a priority mapping, where the higher priority pipe
needs to be staged on left LM, and the lower priority needs to be
staged on the right LM. For example, the priority order for VIG pipes
in decreasing order of priority is VIG0, VIG1, VIG2, and VIG3. So, VIG0
on left and VIG1 on right is a correct configuration, but VIG1 on left
and VIG0 on right isn't. These scenarios are ignored for now for the
sake of simplicity.
Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
Archit Taneja [Thu, 23 Mar 2017 10:28:09 +0000 (15:58 +0530)]
drm/msm/mdp5: Create mdp5_hwpipe_mode_set
Refactor mdp5_plane_mode_set to call mdp5_hwpipe_mode_set. The latter
func takes in only the hwpipe and the parameters that need to be
programmed into the hwpipe registers. All the code that calculates these
parameters is left as is in mdp5_plane_mode_set.
In the future, when we let drm_plane be comprised of 2 hwpipes, this func
allow us to configure each pipe without adding redundant code.
Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
Archit Taneja [Thu, 23 Mar 2017 10:28:08 +0000 (15:58 +0530)]
drm/msm/mdp5: Add optional 'right' Layer Mixer in CRTC state
Add another mdp5_hw_mixer pointer (r_mixer) in mdp5_crtc_state.
This mixer will be used to generate the right half of the scanout.
With Source Split, a SSPP can now be connected to 2 Layer Mixers, but
has to be at the same blend level (stage #) on both Layer Mixers.
A drm_plane that has a lesser width than the max width supported, will
comprise of a single SSPP/hwpipe, staged on both the Layer Mixers at
the same blend level. A plane that is greater than max width will comprise
of 2 SSPPs, with the 'left' SSPP staged on the left LM, and the 'right'
SSPP staged on the right LM at the same blend level.
For now, the drm_plane consists of only one SSPP, therefore, it
needs to be staged on both the LMs in blend_setup() and mdp5_ctl_blend().
We'll extend this logic to support 2 hwpipes per plane later.
The crtc cursor ops (using the LM cursors, not SSPP cursors) simply
return an error if they're called when the right mixer is assigned to
the CRTC state. With source split is enabled, we're expected to only
SSPP cursors.
This commit adds code that configures the right mixer, but the r_mixer
itself isn't assigned at the moment.
Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
Archit Taneja [Thu, 23 Mar 2017 10:28:07 +0000 (15:58 +0530)]
drm/msm/mdp5: Add a CAP for Source Split
Some of the newer MDP5 versions support Source Split of SSPPs. It is a
feature that allows us to route the output of a hwpipe to 2 Layer
Mixers. This is required to achieve the following use cases:
- Dual DSI: For high res DSI panels (such as 2560x1600 etc), a single
DSI interface doesn't have the bandwidth to drive the required pixel
clock. We use 2 DSI interfaces to drive the left and right halves
of the panel (i.e, 1280x1600 each). The MDP5 pipeline here would look
like:
A single hwpipe is used to scan out the left and right halves to DSI1
and DSI2 respectively. In order to do this, we need to configure the
2 Layer Mixers in Source Split mode.
- HDMI 4K: In order to support resolutions with width higher than the
max width supported by a hwpipe, we club 2 hwpipes together:
hwpipe1 is staged on the 'left' Layer Mixer, and hwpipe2 is staged on
the 'right' Layer Mixer. An additional block called the '3D Mux' is
used to merge the output of the 2 DSPPs to a single interface.
In this use case, it is possible that a 4K surface is downscaled and
placed completely within one of the halves. In order to support such
scenarios (and keep the programming simple), Layer Mixers with Source
Split can be assigned 2 hw pipes per stage. While scanning out, the HW
takes care of fetching the pixels fom the correct pipe.
Add a MDP cap to tell whether the HW supports source split or not.
Add a MDP LM cap that tells whether a LM instance can operate in
source split mode (and generate the 'left' part of the display
output).
Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
Archit Taneja [Thu, 23 Mar 2017 10:28:06 +0000 (15:58 +0530)]
drm/msm/mdp5: Remove mixer/intf pointers from mdp5_ctl
These are a part of CRTC state, it doesn't feel nice to leave them
hanging in mdp5_ctl struct. Pass mdp5_pipeline pointer instead
wherever it is needed.
We still have some params in mdp5_ctl like start_mask etc which
are derivative of atomic state, and should be rolled back if
a commit fails, but it doesn't seem to cause much trouble.
Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
Archit Taneja [Thu, 23 Mar 2017 10:28:05 +0000 (15:58 +0530)]
drm/msm/mdp5: Start using parameters from CRTC state
In the last few commits, we've been adding params to mdp5_crtc_state, and
assigning them in the atomic_check() funcs. Now it's time to actually
start using them.
Remove the duplicated params from the mdp5_crtc struct, and start using
them in the mdp5_crtc code. The majority of the references to these params
is in code that executes after the atomic swap has occurred, so it's okay
to use crtc->state in them. There are a couple of legacy LM cursor ops that
may not use the updated state, but (I think) it's okay to live with that.
Now that we dynamically allocate a mixer to the CRTC, we can also remove
the static assignment to it in mdp5_crtc_init, and also drop the code that
skipped init-ing WB bound mixers (those will now be rejected by
mdp5_mixer_assign()).
Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
Archit Taneja [Thu, 23 Mar 2017 10:28:04 +0000 (15:58 +0530)]
drm/msm/mdp5: Add more stuff to CRTC state
Things like vblank/err irq masks, mode of operation (command mode or not)
are derivative of the interface and mixer state. Therefore, they need to
be a part of the CRTC state too.
Add them to mdp5_crtc_state, and assign them in the CRTC's atomic_check()
func, so that it can be rolled back to a clean state.
Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
Archit Taneja [Thu, 23 Mar 2017 10:28:03 +0000 (15:58 +0530)]
drm/msm/mdp5: Assign INTF and CTL in encoder's atomic_check()
The INTF and CTL used in a display pipeline are going to be maintained as
a part of the CRTC state (i.e, in mdp5_crtc_state).
These entities, however, are currently statically assigned to drm_encoders
(i.e. mdp5_encoder). Since these aren't directly visible to the CRTC, we
assign them to the CRTC state in the encoder's atomic_check() op.
With this approach, we assign portions of CRTC state in two different
places: the layer mixer in CRTC's atomic_check(), and the INTF and CTL
pieces in the encoder's atomic_check() op.
We'd have more options here if the drm core maintained encoder state too,
but the current approach of clubbing everything in CRTC's state works just
fine.
Unlike hwpipes and mixers, we don't need to keep a track of INTF/CTL
assignments in the global atomic state. This is because they're currently
not sharable resources. For example, INTF0 and CTL0 will always be assigned
to one drm_encoder. This can change later when we implement writeback and
want a CRTC to use a CTL for a while, and then release it for others to use
it. Or, when a drm_encoder can switch between using a single INTF vs
2 INTFs.
Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
Archit Taneja [Thu, 23 Mar 2017 10:28:02 +0000 (15:58 +0530)]
drm/msm/mdp5: Prepare for dynamic assignment of mixers
Add the stuff needed to allow dynamically assigning a mixer to a CRTC.
Since mixers are a resource that can be shared across multiple CRTCs, we
need to maintain a 'hwmixer_to_crtc' map in the global atomic state,
acquire the mdp5_kms.state_lock modeset lock and so on.
The mixer is assigned in the CRTC's atomic_check() func, a failure will
result in the new state being cleanly rolled back.
The mixer assignment itself is straightforward, and almost identical to
what we do for hwpipes. We don't need to grab the old hwmixer_to_crtc
state like we do in hwpipes since we don't need to compare anything
with the old state at the moment.
The only LM capability we care about at the moment is whether the mixer
instance can be used to display stuff (i.e, connect to an INTF
downstream).
Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
Archit Taneja [Thu, 23 Mar 2017 10:28:01 +0000 (15:58 +0530)]
drm/msm/mdp5: subclass CRTC state
Subclass drm_crtc_state so that we can maintain additional state for
our CRTCs.
Add mdp5_pipeline and mdp5_ctl pointers in the subclassed state.
mdp5_pipeline is a grouping of the HW entities that forms the downstream
pipeline for a particular CRTC. It currently contains pointers to
mdp5_interface and mdp5_hw_mixer tied to this CRTC. Later, we will
have 2 hwmixers in this struct. (We could also have 2 intfs if we want
to support dual DSI with Source Split enabled. Implementing that feature
isn't planned at the moment).
The mdp5_pipeline state isn't used at the moment. For now, we just
introduce mdp5_crtc_state and the crtc funcs needed to manage the
subclassed state.
Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
Archit Taneja [Thu, 23 Mar 2017 10:28:00 +0000 (15:58 +0530)]
drm/msm/mdp5: Remove the pipeline stuff in mdp5_ctl
The mdp5_ctl has an 'op_mode' struct which contains info on
the downstream pipeline.
Grouping these params together in a struct doesn't serve much
purpose in the code. Maybe there was a plan to expand this
further that never happened.
Remove the op_mode struct, and place its members directly in
mdp5_ctl. This will help avoid confusion later when I introduce
my own verion of a mdp5 pipeline :)
Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
Archit Taneja [Thu, 23 Mar 2017 10:27:59 +0000 (15:57 +0530)]
drm/msm/mdp5: Clean up interface assignment
mdp5_interface struct contains data corresponding to a INTF
instance in MDP5 hardware. This sturct is memcpy'd to the
mdp5_encoder struct, and then later to the mdp5_ctl struct.
Instead of copying around interface data, create mdp5_interface
instances in mdp5_init, like how it's done currently done for
pipes and layer mixers. Pass around the interface pointers to
mdp5_encoder and mdp5_ctl. This simplifies the code, and allows
us to decouple encoders from INTFs in the future if needed.
Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
Archit Taneja [Thu, 23 Mar 2017 10:27:56 +0000 (15:57 +0530)]
drm/msm/mdp5: Add structs for hw Layer Mixers
Create a struct to represent MDP5 Layer Mixer instances. This will
eventually allow us to detach CRTCs from the Layer Mixers, and
generally clean things up a bit.
This is very similar to how hwpipes were previously abstracted away
from drm planes.
Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
Archit Taneja [Thu, 23 Mar 2017 10:27:55 +0000 (15:57 +0530)]
drm/msm/mdp5: describe LM instances in mdp5_cfg
The number of Layer Mixers and the downstream blocks (DSPPs and PPs)
connected to each LM can vary with different MDP5 revisions. These
parameters are also static.
Keep the per instance LM data in mdp5_cfg. This will avoid the need
to have macros which identify PP id or DSPP id the LM is connected
to. We don't configure DSPPs at the moment, but keeping the DSPP
instance # here might come handy later.
Also add a 'caps' field that identifies features supported by a
LM instance. Introduce the caps MDP_LM_CAP_DISPLAY and MDP_LM_CAP_WB
that identify whether a LM instance can be used for display or
writeback.
Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
Archit Taneja [Thu, 23 Mar 2017 10:27:54 +0000 (15:57 +0530)]
drm/msm/mdp5: Bring back pipe_lock to mdp5_plane struct
We'd previously moved the pipe_lock spinlock to the hwpipe struct. Bring
it back to mdp5_plane. We will need this because an mdp5_plane in the
future could comprise of 2 hw pipes. It makes more sense to have a single
lock to protect the registers for the hw pipes used by a plane, rather
than trying to take individual locks per hwpipe when committing a
configuration.
Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
Archit Taneja [Fri, 17 Mar 2017 03:39:48 +0000 (09:09 +0530)]
drm/msm/mdp5: Update SSPP_MAX value
'SSPP_MAX + 1' is the max number of hwpipes that can be present on a
MDP5 platform. Recently, 2 new cursor hwpipes were added, which
caused overflows in arrays that used SSPP_MAX to represent the number
of elements. Update the SSPP_MAX value to incorporate the extra
hwpipes.
Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
Archit Taneja [Thu, 16 Feb 2017 10:59:04 +0000 (16:29 +0530)]
drm/msm/dsi: Fix bug in dsi_mgr_phy_enable
A recent commit introduces a bug in dsi_mgr_phy_enable. In the non
dual DSI mode, we reset the mdsi (master DSI) PHY. This isn't right
since master and slave DSI exist only in dual DSI mode. For the normal
mode of operation, we should simply reset the PHY of the DSI device
(i.e. msm_dsi) corresponding to the current bridge.
Usage of the wrong DSI pointer also resulted in a static checker
warning. That too is resolved with this fix.
Fixes: b62aa70a98c5 (drm/msm/dsi: Move PHY operations out of host) Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Rob Clark <robdclark@gmail.com>
CPU: 1 PID: 2323 Comm: drm-api-test Tainted: G W 4.9.0-rc4-00906-g693af44 #213
Hardware name: Qualcomm Technologies, Inc. DB820c (DT)
task: ffff8000d7353400 task.stack: ffff8000d7720000
PC is at drm_mm_insert_node_generic+0x258/0x2f0
LR is at drm_vma_offset_add+0x4c/0x70
Zero sized buffers serve no appreciable value to the user so disallow
them at create time.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
Jordan Crouse [Tue, 7 Mar 2017 16:50:30 +0000 (09:50 -0700)]
drm/msm: Support 64 bit iova in RD_CMDSTREAM_ADDR
Output the upper 32 bits of a 64 bit iova in the RD_CMDSTREAM_ADDR
section while maintaining backwards compatibility for tools that
only understand 32 bit iovas.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
Jordan Crouse [Tue, 7 Mar 2017 16:50:29 +0000 (09:50 -0700)]
drm/msm: Pass interrupt status to a5xx_rbbm_err_irq()
The interrupt status was being cleared before processing the handlers.
a5xx_rbbm_err_irq() was checking the interrupt status again, which would
likely turn out bad because the interrupt status would be 0 (or at least
different). Pass the original status to the function instead.
Also, skip clearing RBBM_AHB_ERROR from the interrupt status. The interrupt
will keep firing until the error source is cleared. Skip the clear to
avoid a storm until the error is cleared in a5xx_rbbm_err_irq().
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
Jordan Crouse [Tue, 7 Mar 2017 16:50:28 +0000 (09:50 -0700)]
drm/msm: Don't increase priv->num_aspaces until we know that it fits
priv->num_aspaces is increased and then checked to see if it still fits
in the priv->aspace array. If it doesn't, we warn and exit but
priv->num_aspaces remains incremented.
Don't incremement the count until we know that it fits in the array.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
Daniel Vetter [Wed, 8 Mar 2017 14:12:54 +0000 (15:12 +0100)]
drm/msm: Simplify vblank event delivery
The core takes care of handling the send_event vs. close() issues, we
can remove that driver code.
Cc: Rob Clark <robdclark@gmail.com> Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Rob Clark <robdclark@gmail.com>
Daniel Vetter [Wed, 8 Mar 2017 14:12:46 +0000 (15:12 +0100)]
drm/msm: switch to postclose
I didn't spot anything that would require ordering here (well not
anywhere else either), and I'm trying to unify at least modern drivers
on one close hook.
Cc: Rob Clark <robdclark@gmail.com> Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Rob Clark <robdclark@gmail.com>
Arnd Bergmann [Mon, 13 Mar 2017 16:43:48 +0000 (17:43 +0100)]
drm/msm: adreno: fix build error without debugfs
The newly added a5xx support fails to build when debugfs is diabled:
drivers/gpu/drm/msm/adreno/a5xx_gpu.c:849:4: error: 'struct msm_gpu_funcs' has no member named 'show'
drivers/gpu/drm/msm/adreno/a5xx_gpu.c:849:11: error: 'a5xx_show' undeclared here (not in a function); did you mean 'a5xx_irq'?
This adds a missing #ifdef.
Fixes: b5f103ab98c7 ("drm/msm: gpu: Add A5XX target support") Cc: stable@vger.kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Rob Clark <robdclark@gmail.com>
Rob Clark [Sat, 25 Feb 2017 15:36:30 +0000 (10:36 -0500)]
drm/msm: move submit fence wait out of struct_mutex
Probably a symptom of needing finer grained locking, but if we wait on
the incoming fence-fd (which could come from a different context) while
holding struct_mutex, that blocks retire_worker so gpu fences cannot get
signalled.
This causes a problem if userspace manages to get more than a frame
ahead, leaving the atomic-commit worker blocked waiting on fences that
cannot be signaled because submit is blocked waiting for a fence
signalled from vblank (after the atomic commit which is blocked).
If we start having multiple fence ctxs for the gpu, submit_fence_sync()
would probably need to move outside of struct_mutex as well.
projects / karo-tx-linux.git / log