| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
GP107 modesetting support (just recognising the chipset, no other changes until 4.12)
a couple of regression fixes, one of them a rather serious double-free issue that appeared in 4.10.
* 'linux-4.11' of git://github.com/skeggsb/linux:
drm/nouveau: initial support (display-only) for GP107
drm/nouveau/kms/nv50: fix double dma_fence_put() when destroying plane state
drm/nouveau/kms/nv50: fix setting of HeadSetRasterVertBlankDmi method
drm/nouveau/mmu/nv4a: use nv04 mmu rather than the nv44 one
drm/nouveau/mpeg: mthd returns true on success now
|
|
git://anongit.freedesktop.org/git/drm-intel into drm-fixes
drm/i915 fixes for v4.11-rc7
one rcu related fix, and a few GVT fixes.
* tag 'drm-intel-fixes-2017-04-12' of git://anongit.freedesktop.org/git/drm-intel:
drm/i915: Don't call synchronize_rcu_expedited under struct_mutex
drm/i915: Suspend GuC prior to GPU Reset during GEM suspend
drm/i915/gvt: set the correct default value of CTX STATUS PTR
drm/i915/gvt: Fix firmware loading interface for GVT-g golden HW state
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/gvt: remove the redundant info NULL check
drm/i915/gvt: adjust mem size for low resolution type
drm/i915: Avoid lock dropping between rescheduling
drm/i915/gvt: exclude cfg space from failsafe mode
drm/i915/gvt: Activate/de-activate vGPU in mdev ops.
drm/i915/execlists: Wrap tail pointer after reset tweaking
drm/i915/perf: remove user triggerable warn
drm/i915/perf: destroy stream on sample_flags mismatch
drm/i915: Align "unfenced" tiled access on gen2, early gen3
|
|
git://anongit.freedesktop.org/git/drm-misc into drm-fixes
drm-misc-fixes for 2017-04-11
Core changes:
- None
Driver changes
- udl: Fix unaligned memory access on SPARC (Jonathan)
* tag 'drm-misc-fixes-2017-04-11' of git://anongit.freedesktop.org/git/drm-misc:
drm/udl: Fix unaligned memory access in udl_render_hline
|
|
git://anongit.freedesktop.org/tegra/linux into drm-next
drm/panel: Changes for v4.12-rc1
This contains two new drivers for a Sitronix and a Samsung panel as well
as two new panels supported by the panel-simple driver.
* tag 'drm/panel/for-4.12-rc1' of git://anongit.freedesktop.org/tegra/linux:
drm/panel: simple: Add support for Winstar WF35LTIACD
devicetree: add vendor prefix for Winstar Display Corp.
drm/panel: Add driver for sitronix ST7789V LCD controller
dt-bindings: display: panel: Add bindings for the Sitronix ST7789V panel
drm/panel: Add support for S6E3HA2 panel driver on TM2 board
dt-bindings: Add support for Samsung s6e3ha2 panel binding
drm/panel: simple: Add support for Ampire AM-480272H3TMQW-T01H
dt-bindings: Add Ampire AM-480272H3TMQW-T01H panel
|
|
Yet again I've proven that I can't negate conditions :(
Testcase: igt/kms_properties/get_property-sanity
Reviewed-by: Maarten Lankhorst <[email protected]>
Reviewed-by: Sean Paul <[email protected]>
Fixes: eb8eb02ed850 ("drm: Drop modeset_lock_all from the getproperty ioctl")
Cc: Maarten Lankhorst <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Jani Nikula <[email protected]>
Cc: Sean Paul <[email protected]>
Reported-by: Tvrtko Ursulin <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Add the missing unlock before return from function etnaviv_gpu_submit()
in the error handling case.
lst: fixed label name.
Fixes: f3cd1b064f11 ("drm/etnaviv: (re-)protect fence allocation with
GPU mutex")
CC: [email protected] #4.9+
Signed-off-by: Wei Yongjun <[email protected]>
Signed-off-by: Lucas Stach <[email protected]>
|
|
GVT implements a purely virtual monitor for virtual GPU independent of
the host. Some DDI related MMIO are not initialized in current code
which cause the display initialization failure in guest. This patch
fills the gap.
Signed-off-by: Pei Zhang <[email protected]>
Signed-off-by: Zhenyu Wang <[email protected]>
|
|
Let c compiler handle the structure copying. The compiler will use
builtin function to handle that.
Signed-off-by: Changbin Du <[email protected]>
Signed-off-by: Zhenyu Wang <[email protected]>
|
|
misprediction
From perf data, found a significant overhead at ring id check in the
function get_opcode. This inline function is frequently used.
Since Intel static predictor will predict the branch to fall through
so the prediction most fail. This is wasting CPU pipeline resource.
We do not need check the engine id everywhere, it should be reliable.
Signed-off-by: Changbin Du <[email protected]>
Signed-off-by: Zhenyu Wang <[email protected]>
|
|
The platform check is done outside, no need check again. Platform doesn't
include mocs should not invoke this two functions.
Signed-off-by: Changbin Du <[email protected]>
Signed-off-by: Zhenyu Wang <[email protected]>
|
|
Make the global mmio list be cacheline aligned to improve performance.
Signed-off-by: Changbin Du <[email protected]>
Signed-off-by: Zhenyu Wang <[email protected]>
|
|
On SPARC, the udl driver filled my kernel log with these messages:
[186668.910612] Kernel unaligned access at TPC[76609c] udl_render_hline+0x13c/0x3a0
Use put_unaligned_be16 to avoid them. On x86 this results in the same
code, but on SPARC the compiler emits two single-byte stores.
Signed-off-by: Jonathan Neuschäfer <[email protected]>
Acked-by: David Airlie <[email protected]>
Signed-off-by: Sean Paul <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Only call synchronize_rcu_expedited after unlocking struct_mutex to
avoid deadlock because the workqueues depend on struct_mutex.
>From original patch by Andrea:
synchronize_rcu/synchronize_sched/synchronize_rcu_expedited() will
hang until its own workqueues are run. The i915 gem workqueues will
wait on the struct_mutex to be released. So we cannot wait for a
quiescent state using those rcu primitives while holding the
struct_mutex or it creates a circular lock dependency resulting in
kernel hangs (which is reproducible but goes undetected by lockdep).
kswapd0 D 0 700 2 0x00000000
Call Trace:
? __schedule+0x1a5/0x660
? schedule+0x36/0x80
? _synchronize_rcu_expedited.constprop.65+0x2ef/0x300
? wake_up_bit+0x20/0x20
? rcu_stall_kick_kthreads.part.54+0xc0/0xc0
? rcu_exp_wait_wake+0x530/0x530
? i915_gem_shrink+0x34b/0x4b0
? i915_gem_shrinker_scan+0x7c/0x90
? i915_gem_shrinker_scan+0x7c/0x90
? shrink_slab.part.61.constprop.72+0x1c1/0x3a0
? shrink_zone+0x154/0x160
? kswapd+0x40a/0x720
? kthread+0xf4/0x130
? try_to_free_pages+0x450/0x450
? kthread_create_on_node+0x40/0x40
? ret_from_fork+0x23/0x30
plasmashell D 0 4657 4614 0x00000000
Call Trace:
? __schedule+0x1a5/0x660
? schedule+0x36/0x80
? schedule_preempt_disabled+0xe/0x10
? __mutex_lock.isra.4+0x1c9/0x790
? i915_gem_close_object+0x26/0xc0
? i915_gem_close_object+0x26/0xc0
? drm_gem_object_release_handle+0x48/0x90
? drm_gem_handle_delete+0x50/0x80
? drm_ioctl+0x1fa/0x420
? drm_gem_handle_create+0x40/0x40
? pipe_write+0x391/0x410
? __vfs_write+0xc6/0x120
? do_vfs_ioctl+0x8b/0x5d0
? SyS_ioctl+0x3b/0x70
? entry_SYSCALL_64_fastpath+0x13/0x94
kworker/0:0 D 0 29186 2 0x00000000
Workqueue: events __i915_gem_free_work
Call Trace:
? __schedule+0x1a5/0x660
? schedule+0x36/0x80
? schedule_preempt_disabled+0xe/0x10
? __mutex_lock.isra.4+0x1c9/0x790
? del_timer_sync+0x44/0x50
? update_curr+0x57/0x110
? __i915_gem_free_objects+0x31/0x300
? __i915_gem_free_objects+0x31/0x300
? __i915_gem_free_work+0x2d/0x40
? process_one_work+0x13a/0x3b0
? worker_thread+0x4a/0x460
? kthread+0xf4/0x130
? process_one_work+0x3b0/0x3b0
? kthread_create_on_node+0x40/0x40
? ret_from_fork+0x23/0x30
Fixes: 3d3d18f086cd ("drm/i915: Avoid rcu_barrier() from reclaim paths (shrinker)")
Reported-by: Andrea Arcangeli <[email protected]>
Signed-off-by: Joonas Lahtinen <[email protected]>
Cc: Andrea Arcangeli <[email protected]>
Cc: Chris Wilson <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Jani Nikula <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
(cherry picked from commit 8f612d055183545070ca1009ac2eb1f2e044cc20)
Signed-off-by: Jani Nikula <[email protected]>
|
|
i915 is currently doing a full GPU reset at the end of
i915_gem_suspend() followed by GuC suspend in i915_drm_suspend(). This
GPU reset clobbers the GuC, causing the suspend request to then fail,
leaving the GuC in an undefined state. We need to tell the GuC to
suspend before we do the direct intel_gpu_reset().
v2: Commit message update. (Chris, Daniele)
Fixes: 1c777c5d1dcd ("drm/i915/hsw: Fix GPU hang during resume from S3-devices state")
Cc: Jeff McGee <[email protected]>
Cc: Daniele Ceraolo Spurio <[email protected]>
Cc: Chris Wilson <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Cc: Imre Deak <[email protected]>
Cc: Mika Kuoppala <[email protected]>
Signed-off-by: Sagar Arun Kamble <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Daniele Ceraolo Spurio <[email protected]>
Acked-by: Chris Wilson <[email protected]>
Signed-off-by: Chris Wilson <[email protected]>
(cherry picked from commit fd08923384385400101c71ac0d21d37d6b23b00d)
Signed-off-by: Jani Nikula <[email protected]>
|
|
drm-intel-fixes
gvt-fixes-2017-04-07
- execlist csb initial read ptr fix (Min)
Signed-off-by: Jani Nikula <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
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
...
|
|
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
...
|
|
Linux 4.11-rc6
drm-misc needs 4.11-rc5, may as well fix conflicts with rc6.
|
|
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.
|
|
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
...
|
|
Implement the CEC notifier support to allow CEC drivers to
be informed when there is a new physical address.
Signed-off-by: Hans Verkuil <[email protected]>
Tested-by: Marek Szyprowski <[email protected]>
Acked-by: Daniel Vetter <[email protected]>
Acked-by: Krzysztof Kozlowski <[email protected]>
Reviewed-by: Andrzej Hajda <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
Implement the CEC notifier support to allow CEC drivers to
be informed when there is a new physical address.
Signed-off-by: Benjamin Gaignard <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
Acked-by: Daniel Vetter <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
This helper is supposed to validate or reject the modeline before it
applied by the mode setting. Currently this function has been dropped,
it was previously set to a dummy function that always returned true. For
both cases, this means that userspace can ask for a bad modeline that
will be always accepted.
On some platforms, like Rockchip, the drm dw_hdmi-rockchip variant driver
already implements the atomic_check drm helper, so mode_fixup cannot be
handled and implemented there (as drm_atomic_helper relies on either
atomic_check or mode_fixup).
This commit implements this helper. It only checks that this mode is
correct from the connector point of view.
Acked-by: Daniel Vetter <[email protected]>
Signed-off-by: Romain Perier <[email protected]>
Signed-off-by: Archit Taneja <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Instead of using a fixed list of clock names use the clock-names
list in the device tree to discover and get the list of clocks
that we need.
Signed-off-by: Jordan Crouse <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
|
|
User space needs to know where the GMEM whole starts so that they
can set up the addressing correctly.
Signed-off-by: Jordan Crouse <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
|
|
Now that our mdp5_planes can consist of 2 hwpipes, update the
blend_setup() code to stage the right hwpipe to the left and
right LMs
Signed-off-by: Archit Taneja <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
|
|
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:
LM0 -- DSPP0 -- INTF1 -- DSI1
/
hwpipe--
\
LM1 -- DSPP1 -- INTF2 -- DSI2
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 --- LM0 -- DSPP0
- - \
- -- 3D Mux -- INTF0 -- HDMI
- - /
hwpipe2 --- LM1 -- DSPP1
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 <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
|
|
PingPong ID for a Layer Mixer is already contained in
mdp5_hw_mixer.
This avoids the need to retrieve PP ID using macros
Signed-off-by: Archit Taneja <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
|
|
Use the mdp5_hw_mixer struct in the mdp5_crtc and mdp5_ctl instead of
using the LM index.
Like before, the Layer Mixers are assigned statically to the CRTCs.
The hwmixer(s) will later be dynamically assigned to CRTCs.
For now, ignore the hwmixers that can only do WB.
Signed-off-by: Archit Taneja <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
|