Change-Id: I5ad8dd156ccf27a6f18004aa0a215a0925b6e67b
Signed-off-by: Chunming Zhou <David1.Zhou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Just cleanup the function parameters.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Less overhead than a work item and also adds proper cleanup handling.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Mostly unused and replaced by the common trace points.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Change-Id: I6d138306a878450e5bf8a77a2f1aacc380a39fe5
Signed-off-by: Flora Cui <Flora.Cui@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
No use bothering users about this for whom we disable write-combining for
other reasons anyway.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Write-combining is a CPU feature. From the GPU POV, these both simply
mean no GPU<->CPU cache coherency.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
They reportedly cause random GPU hangs.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91268
Reviewed-by: Christian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Drop the EDP_PSR_BASE() thing, and just stick the PSR register offset
under dev_priv, like we for DSI and GPIO for example.
TODO: could probably move a bunch of this kind of stuff into the device
info instead...
v2: Drop the spurious whitespace change (Jani)
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447266856-30249-7-git-send-email-ville.syrjala@linux.intel.com
Rather than computing on demand, store also the aux data reg
offsets under intel_dp.
v2: Duplicate some code to make things less magic (Jani)
v3: Use PORT_B registers for invalid ports in g4x_aux_data_reg()
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1447266856-30249-6-git-send-email-ville.syrjala@linux.intel.com
Currently we determine the location of the AUX registers in a confusing
way. First we assume the PCH registers are used always, but then we
override it for everything but HSW/BDW to use DP+0x10. Very confusing.
Let's just make it straightforward and simply add a few functions to
pick the right AUX_CTL based on the DP port.
To deal with VLV/CHV we'll include the display_mmio_offset into the
AUX register defines.
v2: Reorder patches (Chris)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
Link: http://patchwork.freedesktop.org/patch/msgid/1447266856-30249-5-git-send-email-ville.syrjala@linux.intel.com
v2: Keep some MISSING_CASE() stuff (Jani)
s/-1/-PIPE_B/ in the register macro
Fix typo in patch subject
v3: Use PORT_B registers for invalid ports in g4x_aux_ctl_reg() (Jani)
v4: Reorder patches (Chris)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com> (v3)
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v3)
Link: http://patchwork.freedesktop.org/patch/msgid/1447266856-30249-4-git-send-email-ville.syrjala@linux.intel.com
Use kasprintf() to generate the "DPDDC-<port>" name for the aux helper.
To deal with errors properly make intel_dp_aux_init() return something,
and adjust the caller to match. It seems we were also missing a
intel_dp_mst_encoder_cleanup() call on edp (non-port A) init failures,
so add that too.
The whole error/cleanup ordering doesn't feel entirely sane to me, but
I'll leave that part alone for now.
v2: Use kasprintf() instead of a table, reorder patches (Chis)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447266856-30249-3-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
After Damien's D3 fix I started to get runtime suspend residency for the
first time and that revealed a breakage on the set_caching IOCTL path
that accesses the HW but doesn't take an RPM ref. Fix this up.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: stable@vger.kernel.org
Link: http://patchwork.freedesktop.org/patch/msgid/1446665132-22491-1-git-send-email-imre.deak@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
When we set and later readback a frequency value through
sysfs interface, igt/pm_rpm assumes that we get same value back
if it matches hw granularity.
On bxt we have found out that this is not always the case.
Currently frequency - hw ratio - frequency conversions round down,
with few exceptions on platforms that have more specific conversions.
On bxt the supported range can be for example from 100Mhz to 650Mhz.
Midpoint is then calculated by test to be 375 which pm_rps uses to find a
closest hw supported frequency. That is 366 (ratio 22),
which it then writes back. But as the rounding down kicks in,
driver actually sets 350 instead of 366, as 366 is 2/3 below 22 * 50/3.
Fix this by rounding to closest instead of rounding down in
freq-ratio-freq conversions.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92768
Testcase: igt/pm_rps/basic-api
Tested-by: Bob Paauwe <bob.j.paauwe@intel.com>
Cc: Bob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447435781-23416-1-git-send-email-mika.kuoppala@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Let's set crtc_y to 0 instead of setting src_y twice.
Multiple assignments in one statement is a good way to hide bugs.
Please don't do that.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: be5651f2d5 ("drm/i915: Update missing properties in find_initial_plane_obj")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447434973-12369-1-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Pull drm sti driver updates from Dave Airlie:
"The sti driver had a requirement on some patches in Greg's tree, they
are in, so I see no problems just merging this one now"
* 'drm-next' of git://people.freedesktop.org/~airlied/linux:
drm/sti: load HQVDP firmware the first time HQVDP's plane is used
drm/sti: fix typo issue in sti_mode_config_init
drm/sti: set mixer background color through module param
drm/sti: Remove local fbdev emulation Kconfig option
drm/sti: remove redundant sign extensions
drm/sti: hdmi use of_get_i2c_adapter_by_node interface
drm/sti: hdmi fix i2c adapter device refcounting
drm/sti: Do not export symbols
drm/sti: Build monolithic driver
drm/sti: Use drm_crtc_vblank_*() API
drm/sti: Store correct CRTC index in events
drm/sti: Select FW_LOADER
drm/sti: Constify function pointer structs
While comparing the B-Spec with the code I noticed that several
values in these tables have been updated in the spec, so I
changed the code to match..
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jim Bride <jim.bride@linux.intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446852654-883-1-git-send-email-jim.bride@linux.intel.com
The i_boost level in the DDI translation tables are stored per level.
However, skl_ddi_set_iboos() would choose an entry of that table based
on the port argument.
Cc: Jim Bride <jim.bride@linux.intel.com>
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Jim Bride <jim.bride@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447247754-802-1-git-send-email-ander.conselvan.de.oliveira@intel.com
sti/drm changes
Add better support for firmware loading
lots of fixes.
* 'drm-sti-next-2015-11-03' of http://git.linaro.org/people/benjamin.gaignard/kernel:
drm/sti: load HQVDP firmware the first time HQVDP's plane is used
drm/sti: fix typo issue in sti_mode_config_init
drm/sti: set mixer background color through module param
drm/sti: Remove local fbdev emulation Kconfig option
drm/sti: remove redundant sign extensions
drm/sti: hdmi use of_get_i2c_adapter_by_node interface
drm/sti: hdmi fix i2c adapter device refcounting
drm/sti: Do not export symbols
drm/sti: Build monolithic driver
drm/sti: Use drm_crtc_vblank_*() API
drm/sti: Store correct CRTC index in events
drm/sti: Select FW_LOADER
drm/sti: Constify function pointer structs
This reverts commit 52f5eb6094.
Rockchip drm can't work with generic drm_of_component_probe now
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Acked-by: Liviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
As during disabling dc6 no need to check for csr firmware
loading status, so removed the assert call (Requested by Damien).
Cc: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-14-git-send-email-imre.deak@intel.com
Currently during system s/r we enable/disable DC6, so before we do so
make sure that the firmware loading is complete.
Note that whether we need to enable DC6 for S3/S4 is still open. At
least the firmware program is lost during S3 and we need to reprogram it
after resuming. Until this is clarified we keep the current behavior and
enable/disable DC6.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-13-git-send-email-imre.deak@intel.com
During driver unload to ensure we dont have any pending task,
flush_work added to complete firmware loading task.
v1: Initial version.
v2: As per review comments from Daniel,
Removed flush_work from skl_set_power_well. As we have taken
power well refernece and rpm count during firmware loading
by using display_power_domain_get/put - this will always
ensure rpm will be blocked if firmware is not loaded.
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-12-git-send-email-imre.deak@intel.com
Two benefits:
- We can use FW_LOADER_USERSPACE_FALLBACK.
- We can use flush_work to synchronize with the oustanding worker,
which is a notch more obvious what it does than having a special
completion.
The next patch will properly synchronize against the async loader in
the resume and unload code.
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-11-git-send-email-imre.deak@intel.com
The loader function will get a bit more complicated soon, extract the
parsing code to make the control flow clearer. While doing that just
use dev_priv->csr.dmc_payload as the indicator for whether it all
suceeded or not.
v2-v3:
- unchanged
v4:
- rebased on top of latest drm-intel-nightly
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
[imre: remove note about BE cast from commit message, it's not relevant
any more]
Signed-off-by: Imre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
[Jani: fix checkpatch warn on multiple blank lines]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447341089-2735-1-git-send-email-imre.deak@intel.com
As all csr firmware related opertion are not using any
any data structures of drm framework level, so better to
use dev_priv instead of dev. it's a new style! :)
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-9-git-send-email-imre.deak@intel.com
We need to make sure we don't put garbage into the hw if dmc firmware
loading failed mid-thru.
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-8-git-send-email-imre.deak@intel.com
If we really want to we can be more verbose here, but we really don't
need an entire function for this.
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-7-git-send-email-imre.deak@intel.com
Standard is to align continuations of parameter lists and if
conditions to the opening ( in i915 and drm code.
Apply this across the entire file since it was sticking out a bit too
much.
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
[imre: removed note about reg definitions from the commit message, it's
not relevant any more]
Signed-off-by: Imre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-6-git-send-email-imre.deak@intel.com
This removes two anti-patterns:
- Locking shouldn't be used to synchronize with async work (of any
form, whether callbacks, workers or other threads). This is what the
mutex_lock/unlock seems to have been for in intel_csr_load_program.
Instead ordering should be ensured with the generic
wait_for_completion()/complete(). Or more specific functions
provided by the core kernel like e.g.
flush_work()/cancel_work_sync() in the case of synchronizing with a
work item.
- Don't invent own completion like the following code did with the
(already removed) wait_for(csr_load_status_get()) pattern - it's
really hard to get these right when you want them to be _really_
correct (and be fast) in all cases. Furthermore it's easier to read
code using the well-known primitives than new ones using
non-standard names.
Before enabling/disabling DC6 check if the firmware is loaded
successfully. This is guaranteed during runtime s/r, since otherwise we
don't enable RPM, but not during system s/r.
Note that it's still unclear whether we need to enable/disable DC6
during system s/r, until that's clarified, keep the current behavior and
enable/disable DC6.
Also after this patch there is a race during system s/r where the
firmware may not be loaded yet, that's addressed in an upcoming patch.
v2-v3:
- unchanged
v4:
- rebased on latest drm-intel-nightly
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
[imre: added code and note about checking if the firmware loaded ok,
before enabling/disabling it]
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447341037-2623-1-git-send-email-imre.deak@intel.com
Avoids non-static functions since all the callers are in intel_rpm.c.
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
[imre: removed note about reg definitions from commit message, since
it's not relevant any more]
Signed-off-by: Imre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
[Jani: make assert_csr_loaded static]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-4-git-send-email-imre.deak@intel.com
Grabbing a runtime pm reference with intel_runtime_pm_get will only
prevent device D3. But dmc firmware is required even earlier (namely
for the skl power well 2).
Hence we need to grab a rpm reference higher up in the hierarchy. For
simplicity just grab the _INIT display power well. That's a bit too
much, but since the firmware loading task should completely fairly
quickly this won't be a real problem really.
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-3-git-send-email-imre.deak@intel.com
Skl is fully dependent on dmc for going to low power state (dc5/dc6).
This requires a trigger from rpm. To ensure the dmc firmware
is available for runtime pm support rpm-reference-count is used
by not releasing the rpm reference if firmware loading is
not completed.
So moved the intel_csr_ucode_init call after runtime pm enable.
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
[imre: moved the call right after power domain init to avoid race with
the console modesetting]
Signed-off-by: Imre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Reviewed-by: A.Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-2-git-send-email-imre.deak@intel.com
Have only one if ladder for platforms and only one range check for
size. Makes it easier to handle new platforms. Remove the use of
negative return values in char, which might underflow to be positive for
some negative error codes.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445344713-1407-3-git-send-email-jani.nikula@intel.com
No need to verify VMA belongs to GGTT since:
1. The function must return a normal VMA belonging to passed in VM.
2. There can only be one normal VMA for any VM.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1447329595-17495-1-git-send-email-tvrtko.ursulin@linux.intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Minor fixup to d0669d0075 ("drm/i915: Clean up LVDS register
handling") which intended to read lvds_reg just once at the
beginning of intel_lvds_init() and use that throughout the rest
of the function but accidentally missed one register readout.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Link: http://patchwork.freedesktop.org/patch/msgid/20151107141244.AB7616E242@gabe.freedesktop.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reading the driver load/unload code leaves one confused as there's
an async_schedule() in the load, but not async_synchronize_full()
in sight. In fact it's hidden inside intel_fbdev.c. So let's move the
async_schedule() into intel_fbdev.c as well so that it's next to the
async_synchronize_full(), which should make the relationship easier
to see.
Plus this way we won't schedule a nop function call when fbdev is
disabled. And we were passing a pointer to a static inline
function to async_schedule(), which seems rather dubious to me.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446815313-9490-4-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
We set up fbdev last during load, so doing the fbdev cleanup should be
first.
We weren't supposed to drop the init power during driver unload, but since
the fbdev teardown happened after intel_power_domains_fini() that could
have happened due in one of two ways. First it could have happened
during the modeset caused by normal fbdev cleanup. But in addition it
could have happened already via the intel_fbdev_initial_config() since
that is executed asynhronously, and the async_synchronize_full() was
done during fbdev cleanup, after intel_power_domains_fini(). All of
that got eliminated by
commit 292b990e86 ("drm/i915: Update power domains on readout.")
since we now drop the init power synchronously during driver load.
So there is no real bug wrt. the init power anymore, but still it seems
better to do the fbdev cleanup first, before we've potentially cleaned
up something else important.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446815313-9490-3-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
intel_runtime_pm_disable() takes an extra rpm reference which combined
with the one we leak from intel_display_set_init_power() leaves the
usage count at <original>+1 after the driver has been unloaded.
The original ref is dropped explicitly in intel_runtime_pm_enable().
So the next time we load the driver we can no longer do runtime PM ever.
This used to work, but
commit 292b990e86 ("drm/i915: Update power domains on readout.")
broke things by not dropping the init power domain during fbdev
teardown. Based on the comment in intel_power_domains_fini(), the
way it used to to work wasn't intentional. As in we weren't supposed
to drop the init power during driver unload. And since we no longer
do, we now leak an extra rpm reference.
So fix things by throwing intel_runtime_pm_disable() to the bin, so
that the only leaked reference comes from the init power domain.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Daniel Stone <daniels@collabora.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Fixes: 292b990e86 ("drm/i915: Update power domains on readout.")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446815313-9490-2-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Merge final patch-bomb from Andrew Morton:
"Various leftovers, mainly Christoph's pci_dma_supported() removals"
* emailed patches from Andrew Morton <akpm@linux-foundation.org>:
pci: remove pci_dma_supported
usbnet: remove ifdefed out call to dma_supported
kaweth: remove ifdefed out call to dma_supported
sfc: don't call dma_supported
nouveau: don't call pci_dma_supported
netup_unidvb: use pci_set_dma_mask insted of pci_dma_supported
cx23885: use pci_set_dma_mask insted of pci_dma_supported
cx25821: use pci_set_dma_mask insted of pci_dma_supported
cx88: use pci_set_dma_mask insted of pci_dma_supported
saa7134: use pci_set_dma_mask insted of pci_dma_supported
saa7164: use pci_set_dma_mask insted of pci_dma_supported
tw68-core: use pci_set_dma_mask insted of pci_dma_supported
pcnet32: use pci_set_dma_mask insted of pci_dma_supported
lib/string.c: add ULL suffix to the constant definition
hugetlb: trivial comment fix
selftests/mlock2: add ULL suffix to 64-bit constants
selftests/mlock2: add missing #define _GNU_SOURCE
Pull drm fixes from Dave Airlie:
"Two build fixes, one for VC4, one for nouveau where the ARM only code
is doing something a bit strange. While people are discussing that,
just workaround it and fix the build for now. The code in question
will never get used on anything non-ARM anyways.
Also one fix for AST that SuSE had been hiding in their kernel, that
allows all fbdev apps to work on that driver"
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm/nouveau: fix build failures on all non ARM.
drm/ast: Initialized data needed to map fbdev memory
drm/vc4: Add dependency on HAVE_DMA_ATTRS, and select DRM_GEM_CMA_HELPER
gk20a is an ARM only GPU, so we can just do the correct thing on
ARM but fail on other architectures. The other option was to use
SWIOTLB as the define, which means phys_to_page exists, but
this seems clearer.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Due to a missing initialization there was no way to map fbdev memory.
Thus for example using the Xserver with the fbdev driver failed.
This fix adds initialization for fix.smem_start and fix.smem_len
in the fb_info structure, which fixes this problem.
Requested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: stable@vger.kernel.org
Signed-off-by: Egbert Eich <eich@suse.de>
[pulled from SuSE tree by me - airlied]
Signed-off-by: Dave Airlie <airlied@redhat.com>
Just try to set a 64-bit DMA mask first and retry with the smaller dma_mask
if dma_set_mask failed.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Cc: David Airlie <airlied@linux.ie>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Alexandre Courbot <acourbot@nvidia.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Thierry Reding <treding@nvidia.com>
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Pull drm updates from Dave Airlie:
"I Was Almost Tempted To Capitalise Every Word, but then I decided I
couldn't read it myself!
I've also got one pull request for the sti driver outstanding. It
relied on a commit in Greg's tree and I didn't find out in time, that
commit is in your tree now so I might send that along once this is
merged.
I also had the accidental misfortune to have access to a Skylake on my
desk for a few days, and I've had to encourage Intel to try harder,
which seems to be happening now.
Here is the main drm-next pull request for 4.4.
Highlights:
New driver:
vc4 driver for the Rasberry Pi VPU.
(From Eric Anholt at Broadcom.)
Core:
Atomic fbdev support
Atomic helpers for runtime pm
dp/aux i2c STATUS_UPDATE handling
struct_mutex usage cleanups.
Generic of probing support.
Documentation:
Kerneldoc for VGA switcheroo code.
Rename to gpu instead of drm to reflect scope.
i915:
Skylake GuC firmware fixes
HPD A support
VBT backlight fallbacks
Fastboot by default for some systems
FBC work
BXT/SKL workarounds
Skylake deeper sleep state fixes
amdgpu:
Enable GPU scheduler by default
New atombios opcodes
GPUVM debugging options
Stoney support.
Fencing cleanups.
radeon:
More efficient CS checking
nouveau:
gk20a instance memory handling improvements.
Improved PGOB detection and GK107 support
Kepler GDDR5 PLL statbility improvement
G8x/GT2xx reclock improvements
new userspace API compatiblity fixes.
virtio-gpu:
Add 3D support - qemu 2.5 has it merged for it's gtk backend.
msm:
Initial msm88896 (snapdragon 8200)
exynos:
HDMI cleanups
Enable mixer driver byt default
Add DECON-TV support
vmwgfx:
Move to using memremap + fixes.
rcar-du:
Add support for R8A7793/4 DU
armada:
Remove support for non-component mode
Improved plane handling
Power savings while in DPMS off.
tda998x:
Remove unused slave encoder support
Use more HDMI helpers
Fix EDID read handling
dwhdmi:
Interlace video mode support for ipu-v3/dw_hdmi
Hotplug state fixes
Audio driver integration
imx:
More color formats support.
tegra:
Minor fixes/improvements"
[ Merge fixup: remove unused variable 'dev' that had all uses removed in
commit 4e270f0880: "drm/gem: Drop struct_mutex requirement from
drm_gem_mmap_obj" ]
* 'drm-next' of git://people.freedesktop.org/~airlied/linux: (764 commits)
drm/vmwgfx: Relax irq locking somewhat
drm/vmwgfx: Properly flush cursor updates and page-flips
drm/i915/skl: disable display side power well support for now
drm/i915: Extend DSL readout fix to BDW and SKL.
drm/i915: Do graphics device reset under forcewake
drm/i915: Skip fence installation for objects with rotated views (v4)
vga_switcheroo: Drop client power state VGA_SWITCHEROO_INIT
drm/amdgpu: group together common fence implementation
drm/amdgpu: remove AMDGPU_FENCE_OWNER_MOVE
drm/amdgpu: remove now unused fence functions
drm/amdgpu: fix fence fallback check
drm/amdgpu: fix stoping the scheduler timeout
drm/amdgpu: cleanup on error in amdgpu_cs_ioctl()
drm/i915: Fix locking around GuC firmware load
drm/amdgpu: update Fiji's Golden setting
drm/amdgpu: update Fiji's rev id
drm/amdgpu: extract common code in vi_common_early_init
drm/amd/scheduler: don't oops on failure to load
drm/amdgpu: don't oops on failure to load (v2)
drm/amdgpu: don't VT switch on suspend
...
ironlake_set_pll_cpu_edp() only gets called just before
ironlake_edp_pll_on(), so just pull the code into ironlake_edp_pll_on().
Also toss in a debug print into ironlake_edp_pll_off() to match the one
we have in ironlake_edp_pll_on().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446146763-31821-15-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use intel_dp->DP in the eDP PLL setup, instead of doing RMWs.
To do this we need to move DP_AUDIO_OUTPUT_ENABLE setup to happen later,
so that we don't enable audio accidentally while configuring the PLL.
Note that actually we already enabled audio before the port due to
the double port register write magic required by VLV/CHV from
7b713f50d7 ("drm/i915: Fix eDP link training when switching pipes on VLV/CHV")
So that gets changed now to keep audio off as long as the port is off.
Also intel_dp_link_down() must be made to update intel_dp->DP so that we
don't re-enable the port by accident when turning off the PLL. This is
safe now that we don't call intel_dp_link_down() during link retraining.
v2: Add a note about the audio vs. port enable (Daniel)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447164977-32315-1-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
We get underruns on the other pipe when enabling the CPU eDP PLL and
port on ILK.
Bspec knows about the PLL issue, and recommends doing a vblank wait just
prior to enabling the PLL. That does seem to help, but unfortunately we
get another underrun when actually enabling the CPU eDP port. Bspec
doesn't mention that at all, and the same vblank wait trick doesn't
appear to be effective there.
Since I have no better clue how to deal with this, just hide the errors.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446146763-31821-10-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Doing the IBX transcoder B workaround causes underruns on
pipe/transcoder A. Just hide them by disabling underrun reporting for
pipe A around the workaround.
It might be possible to avoid the underruns by moving the workaround
to be applied only when enabling pipe A. But I was too lazy to try it
right now, and the current method has been proven to work, so didn't
want to change it too hastily.
Note that this can re-enable underrun reporting on pipe A if was
already disabled due to a previous actual underrun. But that's OK, we
may just get a second underrun report if another real underron occurrs
on pipe A.
v2: Note that pipe A underruns can get re-enabled due to this (Jani)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v1)
Link: http://patchwork.freedesktop.org/patch/msgid/1446225802-11180-1-git-send-email-ville.syrjala@linux.intel.com
ironlake_enaable_pch_transcoder() checks for CPT to see if it should
enable the timing override chicken bit, but
ironlake_disable_pch_transcoder() checks for !IBX to see if it should
clear the same bit. Change ironlake_disable_pch_transcoder() to check
for CPT as well to keep the two sides consistent.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446146763-31821-8-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Due to the shared error interrupt on IVB/HSW and CPT/PPT we may not
always get an interrupt on a FIFO underrun. But we can always do an
explicit check (like we do on GMCH platforms that have no underrun
interrupt).
v2: Drop stale kerneldoc for i9xx_check_fifo_underruns() (Daniel)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1446225741-11070-1-git-send-email-ville.syrjala@linux.intel.com
Some hardware (IVB/HSW and CPT/PPT) have a shared error interrupt for
all the relevant underrun bits, so in order to keep the error interrupt
enabled, we need to have underrun reporting enabled on all PCH
transocders. Currently we leave the underrun reporting disabled when
the pipe is off, which means we won't get any underrun interrupts
when only a subset of the pipes are active.
Fix the problem by re-enabling the underrun reporting after the pipe has
been disabled. And to avoid the spurious underruns during pipe enable,
disable the underrun reporting before embarking on the pipe enable
sequence. So this way we have the error reporting disabled while
running through the modeset sequence.
v2: Re-enable PCH FIFO underrun reporting unconditionally on pre-HSW
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v1)
Link: http://patchwork.freedesktop.org/patch/msgid/1446225691-10928-1-git-send-email-ville.syrjala@linux.intel.com
As we did for ILK/SNB/IVB, move the PCH FIFO underrun enable to happen
after the encoder enable on HSW+. And again, for symmetry, move the
the disable to happen before encoder disable.
I've left out the vblank wait before the enable here because I don't
know if it's needed or not. Actually I don't know if this entire
change is needed as I don't have a HSW/BDW with VGA output.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446146763-31821-5-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
We get spurious PCH FIFO underruns if we enable the reporting too soon
after enabling the crtc. Move it to be the last step, after the encoder
enable. Additionally we need an extra vblank wait, otherwise we still
get the underruns. Presumably the pipe/fdi isn't yet fully up and running
otherwise.
For symmetry, disable the PCH underrun reporting as the first thing,
just before encoder disable, when shutting down the crtc.
v2: Do the PCH underrun enable unconditionally (Jani, Daniel)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v1)
Link: http://patchwork.freedesktop.org/patch/msgid/1446225627-10809-1-git-send-email-ville.syrjala@linux.intel.com
From our maintainer Daniel Vetter a few days ago:
"Oh dear this is dead code. kdbg uses the fbcon, which always uses
untiled, which means fbc will never be enabled. Also we have 0 users
and 0 test coverage for kdbg on top of i915 (Jesse implemented it
for fun years back). Imo just remove all this code."
Adding to what Daniel said: for kgdboc's KMS support,
intel_pipe_set_base_atomic() already manually disables FBC, so we
won't do the in_dbg_master() check there. This is essentially a revert
of:
commit c924b934d0
Author: Jason Wessel <jason.wessel@windriver.com>
Date: Thu Aug 5 09:22:32 2010 -0500
i915: when kgdb is active display compression should be off
Besides, it is not clear what is the exact problem caused by FBC, and
why other features such as PSR, DRRS, IPS and RPM are not also
checking for in_dbg_master(). IMHO we should either remove the code as
suggested by Daniel or we add some nice comments explaining why is FBC
so special.
v2: Rebase due to new patch order.
Cc: Jason Wessel <jason.wessel@windriver.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-13-git-send-email-paulo.r.zanoni@intel.com
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Daniel was looking at this code and asked about whether fb->pitches[0]
is correct, then he suggested we should a comment to make sure it is
actually intentional.
For more information on the CFB size calculation, please see the
commit message of:
commit c4ffd40908
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date: Thu Oct 1 19:55:57 2015 -0300
drm/i915: fix CFB size calculation
Requested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-12-git-send-email-paulo.r.zanoni@intel.com
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
If we run igt/kms_frontbuffer_tracking, this message will appear
thousands of times, eating a significant part of our dmesg buffer.
It's part of the expected FBC behavior, so let's just silence it.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-10-git-send-email-paulo.r.zanoni@intel.com
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Make sure we deactivate FBC at intel_fbc_init(), so we can remove the
call from intel_display.c. Currently we only have the "enabled"
software state, but later we'll have both "enabled" and "active", and
we'll add assertions to them, so just calling intel_fbc_disable() from
intel_modeset_init() won't work. It's better to make sure
intel_fbc_init() already puts the hardware in the expected state, so
we can put nice assertions in the other functions.
v2: Keep/improve the comment (Chris).
v3: Improve the commit message a little bit.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-9-git-send-email-paulo.r.zanoni@intel.com
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
If FBC is disabled we will still call intel_fbc_invalidate(), and as a
result we may call intel_fbc_deactivate(), which will try to touch
registers.
I'm pretty sure I saw this happen on a runtime suspended device, and
I'm almost sure I was running igt/pm_rpm. It produced the "you touched
registers while the device is suspended" WARNs. But this was some time
ago and I can't remember exactly which conditions were necessary to
reproduce the problem.
v2: Rebase to new series order.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-8-git-send-email-paulo.r.zanoni@intel.com
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Don't try to list in comments the cases where we should enable or
disable FBC: it varies a lot with the hardware generations and the
code should be the documentation. Also notice that there's already a
huge gap between the comments and what's in the code.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-7-git-send-email-paulo.r.zanoni@intel.com
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
This change was part of the commit that makes intel_fbc_update()
receive an intel_crtc as argument instead of dev_priv, but since it
was polluting the diff with too many chunks I decided to move it to
its own commit.
It seems that our developers are favoring having this instead of the
old combination drm_crtc *crtc + intel_crtc *intel_crtc, and on the
mentioned commit we'll get rid of the drm_crtc variable, so let's do
an intermediate commit with the rename, so on the next commit we'll
have just struct intel_crtc *crtc.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-6-git-send-email-paulo.r.zanoni@intel.com
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
We're going to kill intel_fbc_find_crtc(), that's why a big part of
the logic moved from intel_fbc_find_crtc() to crtc_is_valid().
v2:
- Rebase due to pipe_a_only change.
- Split the multiline conditional (Chris).
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-5-git-send-email-paulo.r.zanoni@intel.com
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Although the term "nuke" is part of the FBC spec, it's not very
intuitive, so let's rename it to make it easier for people that are
not familiar with the spec.
Requested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-2-git-send-email-paulo.r.zanoni@intel.com
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Switch everything to the new and more capable implementation of abs().
Mainly to give the new abs() a bit of a workout.
Cc: Michal Nazarewicz <mina86@mina86.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The bspec indicates that DDI A using four lanes is the only valid
configuration for Broxton (Broxton doesn't have a DDI E to split these
lanes with); the DDI_A_4_LANES bit of port A's DDI_BUF_CTL should always
be set by the BIOS. However some BIOS versions seem to only be setting
this bit if eDP is actually lit up at boot time; if the BIOS doesn't
turn on the eDP panel because an external display is plugged in, then
this bit is never properly initialized. The end result of this is that
we wind up calculating a lower max data rate than we should and may wind
up rejecting the native mode for panels that we should be able to drive.
Let's workaround this BIOS bug by just turning the DDI_A_4_LANES bit on
in our driver's internal state if we recognize that we're running on BXT
where it should have been on anyway.
Cc: Imre Deak <imre.deak@intel.com>
Cc: Bob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com>
Tested-by: Bob Paauwe <bob.j.paauwe@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446764012-27251-1-git-send-email-matthew.d.roper@intel.com
VMA offsets are 64 bits. Plane surface offsets are in ggtt and
the hardware register to set this is thus 32 bits. Be explicit
about these and convert carefully to from vma to final size.
This will make sparse happy by not creating 32bit pointers out
of 64bit vma offsets.
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446204375-29831-1-git-send-email-mika.kuoppala@intel.com
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
We have had one case where buggy csr/dmc firmware version influenced
gt side and caused a hang. Add dmc firmware loading state and
version to error state.
v2: - Rebased on top of Damien's patches
- included fw load state
v3: include dmc info only if platform supports it (Chris)
v4: move *csr to branch scope (Chris)
v5: remove dependency to csr_state
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v4)
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446124879-22240-1-git-send-email-mika.kuoppala@intel.com
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
We check these to determine firmware loading status. Include
them to help to debug causes of firmware loading fails.
v2: Move all CSR specific registers to i915_reg.h (Ville)
v3: Rebase
v4: Rebase (RPM ref)
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446220487-32691-1-git-send-email-mika.kuoppala@intel.com
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
For bxt CSR firmware exposes a count of dc5 entries. Expose
it through debugs
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
The CSR firmware expose two counters, handy to check if we are indeed
entering DC5/DC6.
v2: Rebase
v3: Take RPM ref before reading (Imre)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (v1)
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446220412-32574-1-git-send-email-mika.kuoppala@intel.com
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Create a new debufs file for it, we'll have a few more things to add
there.
v2: Fix checkpatch warning about static const array
v3: use named initializers (Ville)
v4: strip out csr_state as it will be removed in future (Ville, Imre)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> (v1)
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445950025-5793-3-git-send-email-mika.kuoppala@intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
There is known issue on GT interrupt delivery with DC6 and
firmwares <1.21. There is a suspicion that this causes
spurious gpu hangs on driver init and with some workloads,
as upgrading the firmware to 1.21 makes these problems
disappear.
As of now the current version included in distribution
firmware packages is very like to be 1.19. Play it safe and
refuse to load a firmware version that may affect gpu
side stability.
With < 1.23 there is a palette and dmc ram corruption issue
so blacklist anything below that.
v2: Refuse to load fw instead of notifying the user
v3: Rebase on header version changes
v4: Refuse to load anything less than 1.23
v5: Give enough information for user for finding correct fw (Chris)
v6: better url and formatting (Chris)
v7: move error log for each fail path (Mika)
bail out earlier in load path (Imre)
v8: Fix the version check (Imre)
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Dave Gordon <david.s.gordon@intel.com>
Cc: Arun Siluvery <arun.siluvery@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
References: https://01.org/linuxgraphics/downloads/skldmcver121
References: https://01.org/linuxgraphics/downloads/skylake-dmc-1.23
Testcase: igt/gem_exec_nop
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446220336-32392-1-git-send-email-mika.kuoppala@intel.com
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
That can be handy later on to tell which DMC firmware version the user
has, by just looking at the dmesg.
v2: use DRM_DEBUG_DRIVER (Chris)
v3: use DRM_INFO (Marc Herbert)
Cc: Marc Herbert <marc.herbert@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> (v1)
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445950025-5793-1-git-send-email-mika.kuoppala@intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
We had two failure modes here:
1.
Deadlock in intelfb_alloc failure path where it calls
drm_framebuffer_remove, which grabs the struct mutex and intelfb_create
(caller of intelfb_alloc) was already holding it.
2.
Deadlock in intelfb_create failure path where it calls
drm_framebuffer_unreference, which grabs the struct mutex and
intelfb_create was already holding it.
[Daniel Vetter on why struct_mutex needs to be locked in the second half
of intelfb_create: "The vma [for the fbdev] is pinned, the problem is
that we re-lookup it a few times, which is racy. We should instead track
the vma directly, but oh well we don't."]
v2:
* Reformat commit msg to 72 chars. (Lukas Wunner)
* Add third failure mode. (Lukas Wunner)
v5:
* Rebase on drm-intel-nightly 2015y-09m-01d-09h-06m-08s UTC,
rephrase commit message. (Jani Nicula)
v6:
* In intelfb_alloc, if __intel_framebuffer_create failed,
fb will be an ERR_PTR, thus not null. So in the failure
path we need to check for IS_ERR_OR_NULL to avoid calling
drm_framebuffer_remove on the ERR_PTR. (Lukas Wunner)
* Since this is init code a drm_framebuffer_unreference should
be all we need. drm_framebuffer_remove is for framebuffers
that userspace has created - and is getting somewhat
defeatured. (Daniel Vetter)
v7:
* Clarify why struct_mutex needs to be locked in the second half
of intelfb_create. (Daniel Vetter)
Fixes: 60a5ca015f ("drm/i915: Add locking around
framebuffer_references--")
Reported-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
[Lukas: Create v3 + v4 + v5 + v6 + v7 based on Tvrtko's v2]
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/47d4e88c91b3bf0f7a280cabec54c8c8cf0cf6f2.1446892879.git.lukas@wunner.de
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
In intelfb_alloc(), if the call to intel_pin_and_fence_fb_obj() fails,
the bo is unrefed twice: By drm_framebuffer_remove() and once more by
drm_gem_object_unreference(). Fix it.
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/cd7b33330621a350b0159ec5e098297b139cfaf7.1446892879.git.lukas@wunner.de
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Currently when allocating a framebuffer fails, the gem object gets
unrefed at the bottom of the call stack in __intel_framebuffer_create,
not where it gets refed, which is in intel_framebuffer_create_for_mode
(via i915_gem_alloc_object) and in intel_user_framebuffer_create
(via drm_gem_object_lookup).
This invites mistakes: __intel_framebuffer_create is also called from
intelfb_alloc, and as discovered by Tvrtko Ursulin, a double unref
was introduced there with a8bb681827 ("drm/i915: Fix error path leak
in fbdev fb allocation").
As suggested by Ville Syrjälä, fix the double unref and improve code
clarity by moving the unref away from __intel_framebuffer_create to
where the gem object gets refed.
Based on Tvrtko Ursulin's original v2.
v3: On fb alloc failure, unref gem object where it gets refed,
fix double unref in separate commit (Ville Syrjälä)
v4: Lock struct_mutex on unref (Chris Wilson)
v5: Rebase on drm-intel-nightly 2015y-09m-01d-09h-06m-08s UTC,
rephrase commit message (Jani Nicula)
Tested-by: Pierre Moreau <pierre.morrow@free.fr>
[MBP 5,3 2009 nvidia MCP79 + G96 pre-retina]
Tested-by: Paul Hordiienko <pvt.gord@gmail.com>
[MBP 6,2 2010 intel ILK + nvidia GT216 pre-retina]
Tested-by: William Brown <william@blackhats.net.au>
[MBP 8,2 2011 intel SNB + amd turks pre-retina]
Tested-by: Lukas Wunner <lukas@wunner.de>
[MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina]
Tested-by: Bruno Bierbaumer <bruno@bierbaumer.net>
[MBP 11,3 2013 intel HSW + nvidia GK107 retina]
Fixes: a8bb681827 ("drm/i915: Fix error path leak in fbdev fb
allocation")
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/2161c5062ef5d6458f8ae14d924a26d4d1dba317.1446892879.git.lukas@wunner.de
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Merge second patch-bomb from Andrew Morton:
- most of the rest of MM
- procfs
- lib/ updates
- printk updates
- bitops infrastructure tweaks
- checkpatch updates
- nilfs2 update
- signals
- various other misc bits: coredump, seqfile, kexec, pidns, zlib, ipc,
dma-debug, dma-mapping, ...
* emailed patches from Andrew Morton <akpm@linux-foundation.org>: (102 commits)
ipc,msg: drop dst nil validation in copy_msg
include/linux/zutil.h: fix usage example of zlib_adler32()
panic: release stale console lock to always get the logbuf printed out
dma-debug: check nents in dma_sync_sg*
dma-mapping: tidy up dma_parms default handling
pidns: fix set/getpriority and ioprio_set/get in PRIO_USER mode
kexec: use file name as the output message prefix
fs, seqfile: always allow oom killer
seq_file: reuse string_escape_str()
fs/seq_file: use seq_* helpers in seq_hex_dump()
coredump: change zap_threads() and zap_process() to use for_each_thread()
coredump: ensure all coredumping tasks have SIGNAL_GROUP_COREDUMP
signal: remove jffs2_garbage_collect_thread()->allow_signal(SIGCONT)
signal: introduce kernel_signal_stop() to fix jffs2_garbage_collect_thread()
signal: turn dequeue_signal_lock() into kernel_dequeue_signal()
signals: kill block_all_signals() and unblock_all_signals()
nilfs2: fix gcc uninitialized-variable warnings in powerpc build
nilfs2: fix gcc unused-but-set-variable warnings
MAINTAINERS: nilfs2: add header file for tracing
nilfs2: add tracepoints for analyzing reading and writing metadata files
...
Here's a handful of i915 fixes for drm-next/v4.4. Imre's commit alone
should address the remaining warnings galore you experienced on
Skylake. Almost all of the rest are also fixes against user or QA
reported bugs, with references.
* tag 'drm-intel-next-fixes-2015-11-06' of git://anongit.freedesktop.org/drm-intel:
drm/i915/skl: disable display side power well support for now
drm/i915: Extend DSL readout fix to BDW and SKL.
drm/i915: Do graphics device reset under forcewake
drm/i915: Skip fence installation for objects with rotated views (v4)
drm/i915: add quirk to enable backlight on Dell Chromebook 11 (2015)
drm/i915/skl: Prevent unclaimed register writes on skylake.
drm/i915: disable CPU PWM also on LPT/SPT backlight disable
drm/i915: Fix maxfifo watermark calc on vlv cursor planes
drm/i915: add hotplug activation period to hotplug update mask
One is fix for a regression in 4.3, One irq locking rework.
* 'vmwgfx-next' of git://people.freedesktop.org/~thomash/linux:
drm/vmwgfx: Relax irq locking somewhat
drm/vmwgfx: Properly flush cursor updates and page-flips
It is hardly possible to enumerate all problems with block_all_signals()
and unblock_all_signals(). Just for example,
1. block_all_signals(SIGSTOP/etc) simply can't help if the caller is
multithreaded. Another thread can dequeue the signal and force the
group stop.
2. Even is the caller is single-threaded, it will "stop" anyway. It
will not sleep, but it will spin in kernel space until SIGCONT or
SIGKILL.
And a lot more. In short, this interface doesn't work at all, at least
the last 10+ years.
Daniel said:
Yeah the only times I played around with the DRM_LOCK stuff was when
old drivers accidentally deadlocked - my impression is that the entire
DRM_LOCK thing was never really tested properly ;-) Hence I'm all for
purging where this leaks out of the drm subsystem.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Dave Airlie <airlied@redhat.com>
Cc: Richard Weinberger <richard@nod.at>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
There are many places which use mapping_gfp_mask to restrict a more
generic gfp mask which would be used for allocations which are not
directly related to the page cache but they are performed in the same
context.
Let's introduce a helper function which makes the restriction explicit and
easier to track. This patch doesn't introduce any functional changes.
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Michal Hocko <mhocko@suse.com>
Suggested-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
__GFP_WAIT was used to signal that the caller was in atomic context and
could not sleep. Now it is possible to distinguish between true atomic
context and callers that are not willing to sleep. The latter should
clear __GFP_DIRECT_RECLAIM so kswapd will still wake. As clearing
__GFP_WAIT behaves differently, there is a risk that people will clear the
wrong flags. This patch renames __GFP_WAIT to __GFP_RECLAIM to clearly
indicate what it does -- setting it allows all reclaim activity, clearing
them prevents it.
[akpm@linux-foundation.org: fix build]
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Christoph Lameter <cl@linux.com>
Acked-by: David Rientjes <rientjes@google.com>
Cc: Vitaly Wool <vitalywool@gmail.com>
Cc: Rik van Riel <riel@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
__GFP_WAIT has been used to identify atomic context in callers that hold
spinlocks or are in interrupts. They are expected to be high priority and
have access one of two watermarks lower than "min" which can be referred
to as the "atomic reserve". __GFP_HIGH users get access to the first
lower watermark and can be called the "high priority reserve".
Over time, callers had a requirement to not block when fallback options
were available. Some have abused __GFP_WAIT leading to a situation where
an optimisitic allocation with a fallback option can access atomic
reserves.
This patch uses __GFP_ATOMIC to identify callers that are truely atomic,
cannot sleep and have no alternative. High priority users continue to use
__GFP_HIGH. __GFP_DIRECT_RECLAIM identifies callers that can sleep and
are willing to enter direct reclaim. __GFP_KSWAPD_RECLAIM to identify
callers that want to wake kswapd for background reclaim. __GFP_WAIT is
redefined as a caller that is willing to enter direct reclaim and wake
kswapd for background reclaim.
This patch then converts a number of sites
o __GFP_ATOMIC is used by callers that are high priority and have memory
pools for those requests. GFP_ATOMIC uses this flag.
o Callers that have a limited mempool to guarantee forward progress clear
__GFP_DIRECT_RECLAIM but keep __GFP_KSWAPD_RECLAIM. bio allocations fall
into this category where kswapd will still be woken but atomic reserves
are not used as there is a one-entry mempool to guarantee progress.
o Callers that are checking if they are non-blocking should use the
helper gfpflags_allow_blocking() where possible. This is because
checking for __GFP_WAIT as was done historically now can trigger false
positives. Some exceptions like dm-crypt.c exist where the code intent
is clearer if __GFP_DIRECT_RECLAIM is used instead of the helper due to
flag manipulations.
o Callers that built their own GFP flags instead of starting with GFP_KERNEL
and friends now also need to specify __GFP_KSWAPD_RECLAIM.
The first key hazard to watch out for is callers that removed __GFP_WAIT
and was depending on access to atomic reserves for inconspicuous reasons.
In some cases it may be appropriate for them to use __GFP_HIGH.
The second key hazard is callers that assembled their own combination of
GFP flags instead of starting with something like GFP_KERNEL. They may
now wish to specify __GFP_KSWAPD_RECLAIM. It's almost certainly harmless
if it's missed in most cases as other activity will wake kswapd.
Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Christoph Lameter <cl@linux.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Vitaly Wool <vitalywool@gmail.com>
Cc: Rik van Riel <riel@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Here is the first batch of updates for sound system on 4.4-rc1.
Again at this time, the update looks fairly calm; no big changes in
either ALSA core or ASoC infrastructures, rather all small cleanups,
in addition to the new stuff as usual.
The biggest changes are about Firewire sound devices. It gained lots
of new device support, and MIDI functionality. Also there are updates
for a few still working-in-progress stuff (topology API and ASoC
skylake), too. But overall, this update should give no big surprise.
Some highlight is below:
Core:
- A few more Kconfig items for tinification; it's marked as EXPERT,
so normal user should't be bothered :)
- Refactoring with a new PCM hw_constraint helper
- Removal of unused transfer_ack_{begin,end} PCM callbacks
Firewire:
- Restructuring of code subtree, lots of refactoring
- Support AMDTP variants
- New driver for Digidesign 002/003 family
- Adds support for TASCAM FireOne to ALSA OXFW driver
- Add MIDI support to TASCAM and Digi00x devices
HD-Audio:
- Automated modalias generation for codec drivers, finally
- Improvement on heuristics for setting mixer name
- A few fixes for longstanding bugs on Creative CA0132 cards
- Addition of audio rate callback with i915 communication
- Fix suspend issue on recent Dell XPS
- Intel Lewisburg controller support
ASoC:
- Updates to the topology userspace interface
- Big updates to the Renesas support (rcar)
- More updates for supporting Intel Sky Lake systems
- New drivers for Asahi Kasei Microdevices AK4613, Allwinnner A10,
Cirrus Logic WM8998, Dialog DA7219, Nuvoton NAU8825, Rockchip
S/PDIF, and Atmel class D amplifier
USB-Audio:
- A fix for newer Roland MIDI devices
- Quirks and workarounds for Zoom R16/24 device
Misc:
- A few fixes for some old Cirrus CS46xx PCI sound boards
- Yet another fixes for some old ESS Maestro3 PCI sound boards
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJWPNI9AAoJEGwxgFQ9KSmkOGIP+wUX4eIWwV4BK3mTjdPgvB+i
M7niITY+baN6WqoX8Impe6CyvdOed/pQyHqkT8NFthhmYrgVU9iJBykgF1+BOPt3
ZtYb0qi2mOPbTL0mwFv6oDu8Nvh6hBdCz6ZepQQdjyG4QBdLs7Cea3o3ncJEgsqI
H9LHcCjwSIi4wAcIFVCiD2rJnI/sqhyH2jm9ay8TWDPkBnUBC0Pz1aE+DIbb5x5G
m53rVTjE2dU5MQJrG+rQyH5ngR51Qs6XLYLSnkMXBrZPSP5UQxM282pG19ILumFK
b5uOKWC2DyeWkmDTglAQXaSSbI+3Sj+W+oo05z51Pz2b8YEvehl2XjJpeB0Nlez/
q+i/c8LnUYV8MPlJdldC1jZO8MVRYEX5fEWm1Hwie+q1YozFkhxIfwKCdXnazpYE
ga9E5t/Utg0Rclb2vlYuHv3A4RmY1CW7VazP6PwZjhrahPMxN6zU8aTe+OzBJxkT
i8Ka+R7mMCVyAfauNuBcQtJ+cY+6JbOXsT/5BWTGW0qsa9V17uUOXriAYyNBLwFL
zcBa8OXHtYoiPbWIgE5rJUmRqTXJaOlNYyuot+AT2K7bOW9KMXmEROaSXyVNoqR8
AVZHVmByViI8TuQ98L7vakvyHSKoi4x1Aq/ODrS4Ya4+5T60PmVTyCxT7UUE0FNo
V39cwMFp8TCMifTeRP/+
=l9SO
-----END PGP SIGNATURE-----
Merge tag 'sound-4.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound updates from Takashi Iwai:
"Here is the first batch of updates for sound system on 4.4-rc1.
Again at this time, the update looks fairly calm; no big changes in
either ALSA core or ASoC infrastructures, rather all small cleanups,
in addition to the new stuff as usual.
The biggest changes are about Firewire sound devices. It gained lots
of new device support, and MIDI functionality. Also there are updates
for a few still working-in-progress stuff (topology API and ASoC
skylake), too. But overall, this update should give no big surprise.
Some highlights are below:
Core:
- A few more Kconfig items for tinification; it's marked as EXPERT,
so normal user should't be bothered :)
- Refactoring with a new PCM hw_constraint helper
- Removal of unused transfer_ack_{begin,end} PCM callbacks
Firewire:
- Restructuring of code subtree, lots of refactoring
- Support AMDTP variants
- New driver for Digidesign 002/003 family
- Adds support for TASCAM FireOne to ALSA OXFW driver
- Add MIDI support to TASCAM and Digi00x devices
HD-Audio:
- Automated modalias generation for codec drivers, finally
- Improvement on heuristics for setting mixer name
- A few fixes for longstanding bugs on Creative CA0132 cards
- Addition of audio rate callback with i915 communication
- Fix suspend issue on recent Dell XPS
- Intel Lewisburg controller support
ASoC:
- Updates to the topology userspace interface
- Big updates to the Renesas support (rcar)
- More updates for supporting Intel Sky Lake systems
- New drivers for Asahi Kasei Microdevices AK4613, Allwinnner A10,
Cirrus Logic WM8998, Dialog DA7219, Nuvoton NAU8825, Rockchip
S/PDIF, and Atmel class D amplifier
USB-Audio:
- A fix for newer Roland MIDI devices
- Quirks and workarounds for Zoom R16/24 device
Misc:
- A few fixes for some old Cirrus CS46xx PCI sound boards
- Yet another fixes for some old ESS Maestro3 PCI sound boards"
* tag 'sound-4.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (330 commits)
ALSA: hda - Add Intel Lewisburg device IDs Audio
ALSA: hda - Apply pin fixup for HP ProBook 6550b
ALSA: hda - Fix lost 4k BDL boundary workaround
ALSA: maestro3: Fix Allegro mute until master volume/mute is touched
ALSA: maestro3: Enable docking support for Dell Latitude C810
ALSA: firewire-digi00x: add another rawmidi character device for MIDI control ports
ALSA: firewire-digi00x: add MIDI operations for MIDI control port
ALSA: firewire-digi00x: rename identifiers of MIDI operation for physical ports
ALSA: cs46xx: Fix suspend for all channels
ALSA: cs46xx: Fix Duplicate front for CS4294 and CS4298 codecs
ALSA: DocBook: Add soc-ops.c and soc-compress.c
ALSA: hda - Add / fix kernel doc comments
ALSA: Constify ratden/ratnum constraints
ALSA: hda - Disable 64bit address for Creative HDA controllers
ALSA: hda/realtek - Dell XPS one ALC3260 speaker no sound after resume back
ALSA: hda/ca0132 - Convert leftover pr_info() and pr_err()
ASoC: fsl: Use #ifdef instead of #if for CONFIG_PM_SLEEP
ASoC: rt5645: Sort the order for register bit defines
ASoC: dwc: add check for master/slave format
ASoC: rt5645: Add the HWEQ for the speaker output
...
Relax locking with the goal of reducing the number of locking cycles and
time spent with irqs disabled.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
With the introduction of the new command buffer mechanism,
proper care wasn't taken to flush cursor image updates and
event-less screen-target page-flips.
Fix this by introducing explicit flush points.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
The display power well support on this platform is in a somewhat broken
state atm, so disable it by default.
This in effect will get rid of incorrect assert WARNs about the CSR/DMC
firmware not being loaded during power well toggling. It also removes a
problem during driver loading where a register is accessed while its
backing power well is down, resulting in another WARN. Until we come up
with the root cause of the second problem and the proper fix for both
issues, keep all display side power wells on.
Also clarify a bit the option description.
Reported-by: Dave Airlie <airlied@redhat.com>
Reference: http://mid.gmane.org/CAPM=9tyjBQjSBTKa49cRr6SYkpNW7Pq-fUFznZZ8Y1snvvk7mA@mail.gmail.com
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446757451-2777-1-git-send-email-imre.deak@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
We have a timed release of a forcewake when using
I915_READ/WRITE macros. wait_for() macro will go to quite
long sleep if the first read doesn't satisfy the condition for
successful exit. With these two interacting, it is possible that
we lose the forcewake during the wait_for() and the subsequent read
will reaquire forcewake.
Further experiments with skl shows that when we lose forcewake,
we lose the reset request we submitted. So reset request register
is not power context saved.
Grab forcewakes for all engines before starting the reset/request
dance so that all requests stay valid for the duration of reset
requisition across all the engines.
v2: Add comment on power well sleeps. Wrap the reset handling
under forcewake instead of just reset requests (Chris)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92774
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Tomi Sarvela <tomix.p.sarvela@intel.com> (v1, v2)
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446721898-1450-1-git-send-email-mika.kuoppala@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
In order to prepare for a link training with DDI, the state machine
would call intel_ddi_prepare_link_retrain(). To remove the dependency to
the hardware information, replace that direct call with a callback.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445594525-7174-7-git-send-email-ander.conselvan.de.oliveira@intel.com
Move register write from intel_dp_update_link_train() into
intel_dp_set_signal_levels(). This creates a better split between the
i915 specific code and the generic link training part. Note that this
causes an extra register write in intel_dp_reset_link_train(), since
both intel_dp_set_signal_levels() and intel_dp_set_link_train() write
to the DP register.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445594525-7174-5-git-send-email-ander.conselvan.de.oliveira@intel.com
Move the call to intel_dp_get_adjust_train() out of
intel_dp_update_link_train() and call it instead from the clock recovery
and channel equalization features. A follow up patch will remove the DP
register write from that function, so that it handles only the DPCD
write.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445594525-7174-4-git-send-email-ander.conselvan.de.oliveira@intel.com
It just makes the code more confusing, so just reference intel_dp_>DP
directly.
Note that this also fix a bug where the value of intel_dp->DP could be
different than the last value written to the hw, due to an early return
that would skip the 'intel_dp->DP = DP' line.
v2: Don't preserve old DP value on failure. (Sivakumar)
- Don't call drm_dp_clock_recovery_ok() twice. (Sivakumar)
- Keep return type of clock recovery and channel equalization
functions as void. (Ander)
v3: Remove DP parameter from intel_dp_set_signal_levels(). (Sivakumar)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445594525-7174-2-git-send-email-ander.conselvan.de.oliveira@intel.com
SWF18 is set if the display has been initialized by the pre-os. It also
gives what configuration is enabled on which pipe. In skl_sanitize_cdclk,
the DPLL sanity check can pass even if GOP/VBIOS is not loaded as BIOS
enables DPLL for integrated audio codec related programming.
So fisrt check if SWF18 is set and then follow through with other DPLL
and CDCLK verification. If not set then for sure we need to sanitize the
cdclock.
v2: Update the commit message for clarity (Siva)
v3: Correct the mask to check for bits[23:0] instead of only bits[16:0].
Had missed checking for PIPE C altogether. Remaining are reserved (Siva)
v4: Use ILK_SWF macro for SWF register definitions. Taken from Ville's patch
http://lists.freedesktop.org/archives/intel-gfx/2015-November/079480.html
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446726932-14078-1-git-send-email-shobhit.kumar@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
While pinning a fb object to the display plane, only install a fence
if the object is using a normal view. This corresponds with the
behavior found in i915_gem_object_do_pin() where the fencability
criteria is determined only for objects with normal views.
v2:
Look at the object's map_and_fenceable flag to determine whether to
install a fence or not (Chris).
v3:
Pin and unpin a fence only if the current view type is normal.
v4:
Extend the "view type is normal" check for pin_fence as well.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446170078-20792-1-git-send-email-vivek.kasireddy@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Just two small cleanup patches to fix coccinelle warnings.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJWM6yPAAoJEN0jrNd/PrOhyBUQALPErCqaBBlS6nv+inM/dIqH
UrhdBQcLF0BFPQmTEix82inkuqYEqB3u2TSDU6MH1IcJfJsOvSjj3/IOpx6uw1+P
AygHPGluMQzunjC48zPWwfYzbrz5zqLK+Apq6afyEowxpnLUcO4yT14u/s2SVdkg
qcNRU2pja/SsXJpz+JYBtCqyGPyuNU+AUBCqc3xFd2RuRQ99P5lZL0rdFTFihCoK
If8MT3VehSE9QKYTkWuWe2c3y3CeucOmreGT+HITj+BE7rbULu73vyd4zdfhb5n6
ObOER1L8YyyM9YfmWUm1swrcEUlG+mSq+ISm76mCwOVvftK0UKQV090WEgpNCRbH
I9D1+pn1vjEK2FXyErOH0AifNAILdoDj3boXLLtyITnjc4K4gKuMeDUpHwUarg/a
Ys51eHrO2mS4EWRxe8QwuP7hj2XFP6sFg3uwWNWMb2WYNoOGfPtxBfobhqU6jBMt
NkNWqSBv/dOvj/5Bddz+3dH6Ea7LDw1oZ3GbBX8K1x1EQTvEPwTjseL3PSAbRbMO
wmRQq/cknkQ9mSP0FEupUw73wc81C6C0iyxJXVtXfJUDkUfMPFJLo3L1Sjqsl4Ey
DVqRpGFUt6hspw8f+DzeittVrXsq65XRKDTg3VlnEQVq/tBPErzXPwVNLhi9fLkY
WQzb+vHIEic4zYY8yIjB
=Q9bM
-----END PGP SIGNATURE-----
Merge tag 'drm/panel/for-4.4-rc1' of git://anongit.freedesktop.org/tegra/linux into drm-next
drm/panel: Changes for v4.4-rc1
Just two small cleanup patches to fix coccinelle warnings.
* tag 'drm/panel/for-4.4-rc1' of git://anongit.freedesktop.org/tegra/linux:
drm/bridge: ptn3460: Fix coccinelle warnings
drm/bridge: ps8622: Fix coccinelle warnings
Just a couple of minor fixes and cleanups for this cycle.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJWM6wLAAoJEN0jrNd/PrOh/HwP/23WEi/j4lBC8NMIOuxg9Eg5
xfEN7hD3VLS3a/wzqCsM5UK9d8hSftCSKrYggKFL1NWsb3XIIyDHTc40dHl3MFMA
r8WVk01XJhdpmSxhc0To1/a0HaKWfKlti2tZNTTYRa2w3pWMLSL/TVKmtAnebv9Z
s15ISWzyjsV6hIMwl3AdvawLDy+u/j3kvwXw/XnSJYRvjDvsFQb0msIu7lGEIWfO
/kabMKJAWUt/cdllWUbPbQdDZv2cY4m3MnSv3NLjOeyHqoZbnHvnx1zNMCYs/3+f
tAzIgpPaMRVNA2vvXINqs7GA3oqks9JmqPysBfUoXD3uiewCzSHXV5fC39kwdhSh
BntCBtL8PTbmVbX7dsgFEFHRx99Lvs37Jrk+4TTzO50L8nTtkXg8UsA/dpL/Ww5B
jlNe/ZAXCOvlEpnmLjmH7Y2N+kbaV7yQmYv/7YKDb1hkQ3mEnv2kwbM9WdN9emyG
pHdXWNGeb72Q8+fBAF1h47M40Zeebkfa6issx8uesTJj1smBwIqxIr3r8f3yShKt
YbMre/K5C+X3xbX9uV79A2k9QqCgWhGkdxSmpGfivOZSzfVNZ3e81fgIeF7f3bbs
uMLs2dpo46XSAOa+fl7GEKIt72824TiQSve+HpqqUv+qt2F5QcBldlwbqv0eJdF+
VmfERYXWM8sgLSLru7L7
=c0/4
-----END PGP SIGNATURE-----
Merge tag 'drm/tegra/for-4.4-rc1' of git://anongit.freedesktop.org/tegra/linux into drm-next
drm/tegra: Changes for v4.4-rc1
Just a couple of minor fixes and cleanups for this cycle.
* tag 'drm/tegra/for-4.4-rc1' of git://anongit.freedesktop.org/tegra/linux:
drm/tegra: dc: Request/free syncpoint at init/exit
drm/tegra: fb: Remove gratuituous blank line
gpu: host1x: Fix MLOCK's debug info
- Some correctness fixes found by coccinelle
- Add drivers/gpu/ipu-v3 directory to MAINTAINERS
- Add support for more color formats
- Fix a regression, making displays larger than FullHD work again
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJWM5loAAoJEFDCiBxwnmDrLwkQAOd2iOsgGemyffmh8shGwGq4
pVgw/2Z9FzdlLXe21R9B8rYOsvq/QR74m49blNGSwlNO6c2L3+65BBkyc2VQoI6t
c3GX0w2mnjqfHOZYiBT1Ca84FT1DBXjOprhljVbCBBZOr0xK4jRY3YBtlk30r8Yv
RlithxYNWjoCBidf4w7FyCKM7tIN7bNXXGtyysAMzNuXU7Mq3dfhF8/qYucYFmYP
XHOxFFX/q4EYchcQBCQi56kxEgEHtaFc+pwzM7mCwN5OVETcVeHw0EoTm56AjQrL
zHwBXvP4ryKpuNFCUqsMdy9KZw+4inHycAjfEKwD2s72llycx+W+Kbg/00Ve8rWn
6/Iv4Q0SuSSuRn4fWfioWSdQqHBZig3Y0AWCQ8BVCdTL2K2KIyxcT45vamo/zQhw
uxRVxQzEUle4ZJJ4DOt5h4ZHF70eQNM9TDGYYSKUqtfQcbZ6pr6mz36J9PgyQuh7
lTOfC5OZstTmS1iK+dqb5zbxhC76ff+v1lS8oTyJPK207f0hwt5OXTki9i7TueUH
DXbPmrotajFWoNOkgFPcBBQaI6P5+29lzFqXE2z43Qk6UoYmR4T+UbpD2nNKaj+I
qsIvgn4Zkg2RkxXehVQxRqynxx7XzfXVBXmtpbDfm50PoWsQMQa7fUiqWTyAp493
zQybk9I0eNexJNFIzyie
=EqNE
-----END PGP SIGNATURE-----
Merge tag 'imx-drm-next-2015-10-30' of git://git.pengutronix.de/git/pza/linux into drm-next
imx-drm fixes and color format updates
- Some correctness fixes found by coccinelle
- Add drivers/gpu/ipu-v3 directory to MAINTAINERS
- Add support for more color formats
- Fix a regression, making displays larger than FullHD work again
* tag 'imx-drm-next-2015-10-30' of git://git.pengutronix.de/git/pza/linux:
drm/imx: hdmi: fix HDMI setup to allow modes larger than FullHD
gpu: ipu-v3: fix div_ratio type
gpu: ipu-v3: csi: add support for 8 bpp grayscale sensors.
drm/imx: enable ARGB4444 16-bit color format
gpu: ipu-v3: add support for ARGB4444 16-bit color format
drm/imx: ipuv3-plane: enable support for RGBX8888 and RGBA8888 pixel formats
gpu: ipu-v3: add support for RGBX8888 and RGBA8888 pixel formats
drm/imx: enable 15-bit RGB with 1-bit alpha formats
gpu: ipu-v3: add support for 15-bit RGB with 1-bit alpha formats
MAINTAINERS: Add IPUv3 core driver to the i.MX DRM driver section
gpu: ipu-v3: ipu-csi: bool test doesn't need a comparison to false
- Updated register headers for GFX 8.1 for Stoney
- Add some new CZ revisions
- minor pageflip optimizations
- Fencing clean up
- Warning fix
- More fence cleanup
- oops fix
- Fiji fixes
* 'drm-next-4.4' of git://people.freedesktop.org/~agd5f/linux: (29 commits)
drm/amdgpu: group together common fence implementation
drm/amdgpu: remove AMDGPU_FENCE_OWNER_MOVE
drm/amdgpu: remove now unused fence functions
drm/amdgpu: fix fence fallback check
drm/amdgpu: fix stoping the scheduler timeout
drm/amdgpu: cleanup on error in amdgpu_cs_ioctl()
drm/amdgpu: update Fiji's Golden setting
drm/amdgpu: update Fiji's rev id
drm/amdgpu: extract common code in vi_common_early_init
drm/amd/scheduler: don't oops on failure to load
drm/amdgpu: don't oops on failure to load (v2)
drm/amdgpu: don't VT switch on suspend
drm/amdgpu: Make amdgpu_mn functions inline
drm/amdgpu: remove amdgpu_fence_ref/unref
drm/amdgpu: use common fence for sync
drm/amdgpu: use the new fence_is_later
drm/amdgpu: use common fences for VMID management v2
drm/amdgpu: move ring_from_fence to common code
drm/amdgpu: switch to common fence_wait_any_timeout v2
drm/amdgpu: remove unneeded fence functions
...
BXT CRTC scaling uses the same gen9 codepaths as SKL; these codepaths
store panel fitter information in pipe_config->pch_pfit. However since
HAS_PCH_SPLIT() is false for BXT we never actually wind up filling in
this structure (we wind up filling in pipe_config->gmch_pfit instead,
which is ignored when we go to program the hardware). Make sure we
always take the PCH code path on gen9+ platforms.
v2: Use HAS_GMCH_DISPLAY() to more cleanly describe the platforms that
actually want to use GMCH-style panel fitting. (Ville)
Cc: Imre Deak <imre.deak@intel.com>
Cc: Chandra Konduru <chandra.konduru@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446656727-3516-1-git-send-email-matthew.d.roper@intel.com
And also add some missing function documentation. No functional change.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Moves are exclusive operations anyway, just use the undefined owner for those.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Interrupts are notorious unreliable, enable the fallback at
a couple of more places.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
cancel_delayed_work_sync is forbidden in interrupt context.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
We recently changed the locking in this function and now there is a
missing unlock on error. Also there are some other resources that we
should probably release as well...
Fixes: f48b2659f5 ('drm/amdgpu: fix the broken vm->mutex V2')
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
I wanted to add yet another check to intel_fbc_update() and realized
I would need to create yet another enum no_fbc_reason case. So I
remembered this patch series that Damien wrote a long time ago and
nobody ever reviewed, so I decided to reimplement it since the code
changed a lot since then.
Credits-to: Damien Lespiau <damien.lespiau@intel.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445964628-30226-2-git-send-email-paulo.r.zanoni@intel.com
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
In two places amdgpu tries to tear down something it hasn't
initalised when failing. This is what happens when you
enable experimental support on topaz which then fails in
ring init.
This patch allows it to fail cleanly.
agd: Split out from from the original patch since the
scheduler is a driver independent.
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
In two places amdgpu tries to tear down something it hasn't
initalised when failing. This is what happens when you
enable experimental support on topaz which then fails in
ring init.
This patch allows it to fail cleanly.
v2 (agd): split out scheduler change into a separate patch
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The way to load the HQVDP firmware has been updated.
HQVDP firmware is now loaded the first time an HQVDP plane is used and
no more when the HQVDP driver is bound.
This solves the dependency we had on the file system availability.
The first time the HQVDP plane is used, we are sure that file system is
available so request_firmware function will match.
CONFIG_FW_LOADER_USER_HELPER_FALLBACK is then no more mandatory.
Cc: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Vincent Abriou <vincent.abriou@st.com>
Add bkgcolor module parameter that allow to change the background
color of the mixer. It can be set with an RGB value coded as 0xRRGGBB.
The default value is black.
Signed-off-by: Vincent Abriou <vincent.abriou@st.com>
Signed-off-by: Nicolas VANHAELEWYN <nicolas.vanhaelewyn@st.com>
DRM_STI_FBDEV config is currently used to enable/disable fbdev emulation
for the sti kms driver.
Remove this local config option and use the core fb helpers with
drm_kms_helper.fbdev_emulation module option to enable/disable fbdev
at runtime.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Reviewed-by: Vincent Abriou <vincent.abriou@st.com>
arg is long int, so arg = (arg << 22) >> 22 makes the upper 22 bits of
arg equal to bit 9 (or bit 41). But we then mask away all but bits 0-9, so
this is entirely redundant.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Reviewed-by: Vincent Abriou <vincent.abriou@st.com>
This change is needed to properly lock I2C bus device and driver,
which serve DDC lines. Without this change I2C bus driver module
may gone in runtime and this won't be noticed by the driver.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Reviewed-by: Vincent Abriou <vincent.abriou@st.com>
The commit 53bdcf5f02 ("drm: sti: fix sub-components bind") moves
i2c adapter search and locking from .bind() to .probe(), however
proper error path in the modified .probe() is not implemented and
leftover of the related error path in .bind() remains. This change
fixes these issues.
Fixes: 53bdcf5f02 ("drm: sti: fix sub-components bind")
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Reviewed-by: Vincent Abriou <vincent.abriou@st.com>
None of these exported symbols are used outside of the drm-sti driver,
so there is no reason to export them.
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Vincent Abriou <vincent.abriou@st.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Vincent Abriou <vincent.abriou@st.com>
There's no use building the individual drivers as separate modules
because they are all only useful if combined into a single DRM/KMS
device.
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Vincent Abriou <vincent.abriou@st.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Vincent Abriou <vincent.abriou@st.com>
Non-legacy drivers should only use this API to allow per-CRTC data to be
eventually moved into struct drm_crtc.
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Vincent Abriou <vincent.abriou@st.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Vincent Abriou <vincent.abriou@st.com>
A negative pipe causes a special case to be triggered for drivers that
don't have proper VBLANK support. STi does support VBLANKs, so there is
no need for the fallback code.
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Vincent Abriou <vincent.abriou@st.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Vincent Abriou <vincent.abriou@st.com>
Select FW_LOADER explicitly to satify the direct dependency of
FW_LOADER_USER_HELPER_FALLBACK.
Acked-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
- Vast improvements to gk20a instmem handling.
- Improved PGOB detection + GK107 support.
- Compatibility between old/new interfaces added, final missing piece to
finally enabling userspace to start using them.
- Kepler GDDR5 PLL stability improvements
- Support for non-GPIO (PWM) voltage controllers
- G8x/GT2xx memory clock improvements
- Misc other fixes
* 'linux-4.4' of git://anongit.freedesktop.org/git/nouveau/linux-2.6: (45 commits)
drm/nouveau: bump patchlevel to indicate availability of abi16/nvif interop
drm/nouveau/abi16: implement limited interoperability with usif/nvif
drm/nouveau/abi16: introduce locked variant of nouveau_abi16_get()
drm/nouveau/abi16: remove unused argument from nouveau_abi16_get()
drm/nouveau/pci: enable c800 magic for Medion Erazer X7827
drm/nouveau/pci: enable c800 magic for Lenovo Y510P
drm/nouveau/pll/gk104: fix PLL instability due to bad configuration with gddr5
drm/nouveau/clk/g84: Enable reclocking for GDDR3 G94-G200
drm/nouveau/bus/hwsq: Implement VBLANK waiting heuristic
drm/nouveau/fb/ramnv50: Script changes for G94 and up
drm/nouveau/fb/ramnv50: Deal with cards without timing entries
drm/nouveau/fb/ramnv50: Voltage GPIOs
drm/nouveau/fb/ramgt215: Restructure r111100 calculation for DDR2
drm/nouveau/fb/ramgt215: Change FBVDD/Q when BIOS asks for it
drm/nouveau/fb/ramgt215: Transform GPIO ramfuc method from FBVREF-specific to generic
drm/nouveau/bios/rammap: Identify DLLoff for >= GF100
drm/nouveau/pci: Handle 5-bit and 8-bit tag field
drm/nouveau/disp,pm: constify nvkm_object_func structures
drm/nouveau/gr: add FERMI_COMPUTE_B class to GF110+
drm/nouveau/gr: document mp error 0x10
...
This pull request includes comprehensive cleanups to HDMI part and
several fixups. In addition, this pull request includes also a defconfig
patch which enables mixer driver as default. For this, I got already
Acked-by from Krzysztof Kozlowski who is a Exynos SoC maintainer.
* 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos: (34 commits)
drm/exynos/gem: remove DMA-mapping hacks used for constructing page array
ARM: exynos_defconfig: enable Exynos DRM Mixer driver
drm/exynos: simplify Kconfig component names
drm/exynos: re-arrange Kconfig entries
drm/exynos: abstract out common dependency
drm/exynos: separate Mixer and HDMI drivers
drm/exynos/mixer: replace direct cross-driver call with drm mode validation
drm/exynos: add atomic_check callback to exynos_crtc
drm/exynos/decon5433: add support for DECON-TV
drm/exynos/decon5433: remove duplicated initialization
drm/exynos/decon5433: merge different flag fields
drm/exynos/decon5433: add function to set particular register bits
drm/exynos/decon5433: fix timing registers writes
drm/exynos/decon5433: add PCLK clock
drm/exynos: cleanup name of gem object for exynos_drm
drm/exynos: fix to detach device of iommu
drm/exynos: add cursor plane support
drm/exynos: add global macro for the default primary plane
drm/exynos: fix spelling errors
drm: exynos: mixer: fix using usleep() in atomic context
...
USIF already takes the client mutex, but will need access to ABI16 data
in order to provide some limited interoperability.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This patch uses an approach closer to the nvidia driver to configure
both PLLs for high gddr5 memory clocks (usually above 2400MHz)
Previously nouveau used the one PLL as it was used for the lower clocks
and just adjusted the second PLL to get as close as possible to the
requested clock. This means for my card, that I got a 4050 MHz clock
although 4008 MHz was requested.
Now the driver iterates over a list of PLL configuration also used by
the nvidia driver and then adjust the second PLL to get near the
requested clock. Also it hold to some restriction I found while
analyzing the PLL configurations
This won't fix all gddr5 high clock issues itself, but it should be
fine on hybrid gpu systems as found on many laptops these days. Also
switching while normal desktop usage should be a lot more stable than
before.
v2: move the pll code into ramgk104
Signed-off-by: Karol Herbst <nouveau@karolherbst.de>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Your milage may vary, as it's only been tested on a single G94 and one G96.
Signed-off-by: Roy Spliet <rspliet@eclipso.eu>
Tested-by: Pierre Moreau <pierre.morrow@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Avoids waiting for VBLANKS that never arrive on headless or otherwise
unconventional set-ups. Strategy taken from MEMX.
Signed-off-by: Roy Spliet <rspliet@eclipso.eu>
Tested-by: Pierre Moreau <pierre.morrow@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
10053c is not even read on some cards, and I have no idea exactly what the
criteria are. Likely NVIDIA pre-scans the VBIOS and in their driver disables
all features that are never used. The practical effect should be the same
as this implementation though.
Signed-off-by: Roy Spliet <rspliet@eclipso.eu>
Tested-by: Pierre Moreau <pierre.morrow@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Like Pierre's G94. We might want to structure Kepler similarly in a follow-up.
Signed-off-by: Roy Spliet <rspliet@eclipso.eu>
Tested-by: Pierre Moreau <pierre.morrow@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Does not seem to be necessary for NVA0, hence untested by me.
Signed-off-by: Roy Spliet <rspliet@eclipso.eu>
Tested-by: Pierre Moreau <pierre.morrow@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Seems to be mostly equal to DDR3 on < GT218, should improve stability for
DDR2 reclocks.
Signed-off-by: Roy Spliet <rspliet@eclipso.eu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
In preparation of changing FBVDDQ, as observed on at least one GDDR3 card.
While at it, adhere to func.log[1] properly for consistency.
Signed-off-by: Roy Spliet <rspliet@eclipso.eu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
If the hardware supports extended tag field (8-bit ones), then enable it.
This is usually done by the VBIOS, but not on some MBPs (see fdo#86537).
In case extended tag field is not supported, 5-bit tag field is used which
limits the possible number of requests to 32. Apparently bits 7:0 of
0x08841c stores some number of outstanding requests, so cap it to 32 if
extended tag is unsupported.
Fixes: fdo#86537
v2: Restrict changes to chipsets >= 0x84
v3:
* Add nvkm_pci_mask to pci.h
* Mask bit 8 before setting it
v4:
* Rename `add` argument of nvkm_pci_mask to `value`
* Move code from nvkm_pci_init to g84_pci_init and remove PCIe and chipset
checks
v5:
* Rebase code on latest PCI structure
* Restore PCIe check
* Fix namings in nvkm_pci_mask
* Rephrase part of the commit message
Signed-off-by: Pierre Moreau <pierre.morrow@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
These nvkm_object_func structures are never modified. All other
nvkm_object_func structures are declared as const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
GF110+ supports both the A and B compute classes, make sure to accept
both.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
NVIDIA provided the documentation for mp error 0x10, INVALID_ADDR_SPACE,
which apparently happens when trying to use an atomic operation on
local or shared memory (instead of global memory).
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
If pm_runtime_get_sync() we were going to "out" but we missed freeing
vma.
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
coverity.com reported that memset was using a buffer of size 0, on
checking the code it turned out that the function was not being used. So
remove it.
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Was not able to obtain a trace of NVRM due to kernel version annoyances,
however, experimentally confirmed that the WAR we use on NV50/G8x boards
works here too.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Increase clock timeout of some unknown engines in order to avoid failure
at high gpcclk rate.
This fixes IBUS read faults on my GF119 when reclocking is manually
enabled. Note that memory reclocking is completely broken and NvMemExec
has to be disabled to allow core clock reclocking only.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
I got confirmation that we can read and change the voltage with the same code.
The divider is also computed correctly on the gm204 we got our hands on.
Thanks to Yoshimo on IRC for executing the tests on his gm204!
Signed-off-by: Martin Peres <martin.peres@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Let's ignore the other desktop Maxwells until I get my hands on one and confirm
that we still can change the voltage.
Signed-off-by: Martin Peres <martin.peres@free.fr>
Most Keplers actually use the GPIO-based voltage management instead of the new
PWM-based one. Use the GPIO mode as a fallback as it already gracefully handles
the case where no GPIOs exist.
All the Maxwells seem to use the PWM method though.
v2:
- Do not forget to commit the PWM configuration change!
Signed-off-by: Martin Peres <martin.peres@free.fr>
This patch is not ideal but it definitely beats a rewrite of the current
interface and is very self-contained.
Signed-off-by: Martin Peres <martin.peres@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
So far the DMA mask was not set for platform devices, which limited them
to a 32-bit physical space. Allow dma_set_mask() to be called for
non-PCI devices, and also take the IOMMU bit into account since it could
restrict the physically addressable space.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The pci_dma_* functions are now superseeded in the kernel by the DMA
API. Make the conversion to this more generic API.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Use the IOMMU bit specified in platform data instead of hardcoding it to
the bit used by current Tegra GPUs.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Current Tegra code taking advantage of the IOMMU assumes a hardcoded
value for the IOMMU bit. Make it a platform property instead for
flexibility.
v2 (Ben Skeggs): remove nvkm dependence on drm structures
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The Great Nouveau Refactoring Take II brought us a lot of goodness,
including acquire/release methods that are called before and after an
instobj is modified. These functions can be used as synchronization
points to manage CPU/GPU coherency if we modify an instobj using the
CPU.
This patch replaces the legacy and slow PRAMIN access for gk20a instmem
with CPU mappings and writes. A LRU list is used to unmap unused
mappings after a certain threshold (currently 1MB) of mapped instobjs is
reached. This allows mappings to be reused most of the time.
Accessing instobjs using the CPU requires to maintain the GPU L2 cache,
which we do in the acquire/release functions. This triggers a lot of L2
flushes/invalidates, but most of them are performed on an empty cache
(and thus return immediately), and overall context setup performance
greatly benefits from this (from 250ms to 160ms on Jetson TK1 for a
simple libdrm program).
Making L2 management more explicit should allow us to grab some more
performance in the future.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
No longer required in a lot of cases, as objects are identified over NVIF
via an alternate mechanism since the rework.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Allow clients to manually flush and invalidate L2. This will be useful
for Tegra systems for which we want to write instmem using the CPU.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
These are useful for systems without a coherent CPU/GPU bus. For such
systems we may need to maintain the L2 ourselves.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reintroduce macros allowing us to test a register against a certain
mask, since this is the most common usage pattern for the more generic
nvkm_xsec macros and makes the code more concise and readable.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Some devices may not have a PMU. Avoid a NULL pointer dereference in
such cases by checking whether the pointer given to nvkm_pmu_pgob() is
valid.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
On nv50+, we restrict the valid domains to just the one where the buffer
was originally created. However after the buffer is evicted to system
memory, we might move it back to a different domain that was not
originally valid. When sharing the buffer and retrieving its GEM_INFO
data, we still want the domain that will be valid for this buffer in a
pushbuf, not the one where it currently happens to be.
This resolves fdo#92504 and several others. These are due to suspend
evicting all buffers, making it more likely that they temporarily end up
in the wrong place.
Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92504
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Exynos GEM objects contains an array of pointers to the pages, which the
allocated buffer consists of. Till now the code used some hacks (like
relying on DMA-mapping internal structures or using ARM-specific
dma_to_pfn helper) to build this array. This patch fixes this by adding
proper call to dma_get_sgtable_attrs() and using the acquired scatter-list
to construct needed array. This approach is more portable (work also for
ARM64) and finally fixes the layering violation that was present in this
code.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Many Exynos DRM sub-options mentions Exynos DRM in their titles.
It is redundant and can be safely shortened. The patch additionally
makes some entries more descriptive.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Exynos DRM driver have quite big number of components and options.
The patch re-arranges them into three logical groups:
- CRTCs,
- Encoders and Bridges,
- Sub-drivers.
It should make driver options more clear.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
All options depends on DRM_EXYNOS so it can be moved to enclosing if clause.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Latest Exynos SoCs does not have Mixer IP, but they still have HDMI IP.
Their drivers should be configurable separately.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
HDMI driver called directly function from MIXER driver to invalidate modes
not supported by MIXER. The patch replaces the hack with proper .atomic_check
callback.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Some CRTCs needs mode validation, this patch adds neccessary
callback to Exynos DRM framework. It is called from DRM core
via atomic_check helper for drm_crtc.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
DECON-TV IP is responsible for generating video stream which is transferred
to HDMI IP. It is almost fully compatible with DECON IP.
The patch is based on initial work of Hyungwon Hwang.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Field .commit is already initialized few lines above.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Driver uses four different fields for internal flags. They can be merged
into one.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The driver often sets only particular bits of configuration registers.
Using separate function to such action simplifies the code.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
All timing registers should contain values decreased by one.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
PCLK clock is used by DECON IP. The patch also replaces magic number with
number of clocks in array definition.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Unused amdgpu_mn functions threw warnings for every file that includes
amdgpu.h. It makes sense to inline this amdgpu_mn stubs to avoid the warning.
Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
Make pinning and waiting a separate step, and wait for object idle
without struct_mutex held.
Changes since v1:
- Do not wait when a reset is in progress.
- Remove call to i915_gem_object_wait_rendering for
intel_overlay_do_put_image (Chris Wilson)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
struct_mutex is being locked for every plane in intel_prepare_plane_fb
and intel_cleanup_plane_fb.
Require the caller to hold the mutex, and only acquire the mutex for
each helper call. This way the lock only needs to be acquired
twice in ->atomic_commit(). Once for pinning new framebuffers at the
start, the second time for unpinning old framebuffer.
Changes since v1:
- Use mutex_lock_interruptible instead of i915 variant,
to prevent a deadlock when called from the reset code.
Changes since v2:
- Clarify struct_mutex is locked by the caller.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com> #v1
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Move it from intel_crtc_atomic_commit to prepare_plane_fb.
Waiting is done before committing, otherwise it's too late
to undo the changes.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ander Conselvan De Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Extends i915_display_info so that for each active crtc also print
all planes associated with the pipe. This patch shows information
about each plane wrt format, size, position, rotation, and scaling.
This is very useful when debugging user space compositors that try
to utilize several planes for a commit.
V2: Fixed comments from Maarten, Ville, and Chris. Fixed printing of
16.16 fixpoint, better rotation bitmask management and some minor fixes
V3: Corrected state->src_x & 0x00ff to state->src_x & 0xffff...
Signed-off-by: Robert Fekete <robert.fekete@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445961512-25317-1-git-send-email-robert.fekete@linux.intel.com
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
One branch of the if clause uses pr_info, the other pr_err; change
the 'false' branch to also use pr_info. This minor oversight has gone
unfixed since the initial vga_switcheroo implementation in 6a9ee8af.
Signed-off-by: Ioan-Adrian Ratiu <adi@adirat.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446246960-22620-1-git-send-email-adi@adirat.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Now that we use memremap instead of ioremap, Use WRITE_ONCE / READ_ONCE
instead of iowrite / ioread.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Do this until we know how much MOB memory to allocate for these surfaces.
v2: Mask also non-DX multisample.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Per commit 2e586a7e01 "drm/vmwgfx: Map the fifo as cached" the driver
expects the fifo registers to be cacheable. In preparation for
deprecating ioremap_cache() convert its usage in vmwgfx to memremap().
Cc: David Airlie <airlied@linux.ie>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Sinclair Yeh <syeh@vmware.com>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
I'm getting unclaimed register writes when checking the WM registers
after the crtc is disabled. So I would imagine those are guarded by
the crtc power well. Fix this by not reading out wm state when the
power well is off.
Cc: stable@vger.kernel.org # v4.3
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92181
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
DRM_ERROR an continue without any issues aren't allowed since that
causes noise in the CI system. But we absolutely want to have the
DRM_ERROR when we want to run with GuC.
For simplicity just short-circuit all the loader code when it's not
needed.
v2: Mika&Chris complained that I shouldn't hit send on patches written
before coffee kicks in.
v3: Make it compile at least ...
Cc: Alex Dai <yu.dai@intel.com>
Cc: Dave Gordon <david.s.gordon@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445591459-4327-1-git-send-email-daniel.vetter@ffwll.ch
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Arguments passed to list_add_tail were reversed resulting in deletion
of old blob property everytime the new one is added.
Fixes
commit e2f5d2ea47
Author: Daniel Stone <daniels@collabora.com>
Date: Fri May 22 13:34:51 2015 +0100
drm/mode: Add user blob-creation ioctl
Signed-off-by: Maneet Singh <mmaneetsingh@nvidia.com>
[seanpaul tweaked commit subject a little]
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Cc: stable@kernel.org # v4.2
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
The size here comes from the user via the ioctl, it is a number between
1-u32max so the addition here could overflow on 32 bit systems.
Fixes: f453ba0460 ('DRM: add mode setting support')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Cc: stable@kernel.org # v4.2
Signed-off-by: Dave Airlie <airlied@gmail.com>
syncpoints are resources provided by host1x and their lifetime is tied
to the host1x device. They are not properly reference counted either, so
removing the host1x device before any of its clients causes a use-after-
free error. Adding proper reference counting would be a major enterprise
so work around it for now by requesting and freeing the syncpoint at
init and exit time, respectively. The host1x device is guaranteed to be
around at this point.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The platform_no_drv_owner.cocci coccinelle script generates the
following warning:
drivers/gpu/drm/bridge/nxp-ptn3460.c:403:3-8: No need to set .owner here. The core will do it.
Remove .owner field if calls are used which set it automatically. Patch
generated by scripts/coccinelle/api/platform_no_drv_owner.cocci.
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The platform_no_drv_owner.cocci coccinelle script generates the
following warning:
drivers/gpu/drm/bridge/parade-ps8622.c:671:3-8: No need to set .owner here. The core will do it.
Remove .owner field if calls are used which set it automatically. Patch
generated by scripts/coccinelle/api/platform_no_drv_owner.cocci.
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This worked before the dw-hdmi bridge code was changed to validate
the setup data more strictly. Add back support for modes with a
pixel clock up to 216MHz. Even higher clocks should work, but we
are missing the required setup data for now.
Also change the mode validate callbacks to disallow modes with
higher pixelclocks, so we don't end up failing the modeset later
on.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
This patch allows to use the ARGB4444 color format on planes.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
This was introduced by mistake in commit 0f7d9052fb ("drm/tegra: Use
new drm_fb_helper functions"). Remove it.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Just move the remaining users to fence_put/get.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Stop using the driver internal functions.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
No need to duplicate the functionality any more.
v2: fix handling if no fence is available.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (v1)
amdgpu_fence_default_wait isn't needed any more the default wait does the same
thing and amdgpu_test_signaled is dead as well.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Few more drm-misc stragglers for 4.4. Big thing is the generic probe for
imx/rockchip/armada (but the variant for msm/rpi/exynos is still missing).
Also the hdmi clocking fixes from Ville which was a lot of confusion about
which tree it should be applied to ;-)
* tag 'topic/drm-misc-2015-10-22' of git://anongit.freedesktop.org/drm-intel:
drm: correctly check failed allocation
vga_switcheroo: Constify vga_switcheroo_handler
drm/armada: Convert the probe function to the generic drm_of_component_probe()
drm/rockchip: Convert the probe function to the generic drm_of_component_probe()
drm/imx: Convert the probe function to the generic drm_of_component_probe()
drm: Introduce generic probe function for component based masters.
drm/edid: Round to closest when computing the CEA/HDMI alternate clock
drm/edid: Fix up clock for CEA/HDMI modes specified via detailed timings
More amdgpu and radeon stuff for drm-next. Stoney support is the big change.
The rest is just bug fixes and code cleanups. The Stoney stuff is pretty
low impact with respect to existing chips.
* 'drm-next-4.4' of git://people.freedesktop.org/~agd5f/linux:
drm/amdgpu: change VM size default to 64GB
drm/amdgpu: add Stoney pci ids
drm/amdgpu: update the core VI support for Stoney
drm/amdgpu: add VCE support for Stoney (v2)
drm/amdgpu: add UVD support for Stoney
drm/amdgpu: add GFX support for Stoney (v2)
drm/amdgpu: add SDMA support for Stoney (v2)
drm/amdgpu: add DCE support for Stoney
drm/amdgpu: Update SMC/DPM for Stoney
drm/amdgpu: add GMC support for Stoney
drm/amdgpu: add Stoney chip family
drm/amdgpu: fix the broken vm->mutex V2
drm/amdgpu: remove the unnecessary parameter adev for amdgpu_fence_wait_any()
drm/amdgpu: remove the exclusive lock
drm/amdgpu: remove old lockup detection infrastructure
drm: fix trivial typos
drm/amdgpu/dce: simplify suspend/resume
drm/amdgpu/gfx8: set TC_WB_ACTION_EN in RELEASE_MEM packet
drm/radeon: Use rdev->gem.mutex to protect hyperz/cmask owners
Bunch of -fixes for 4.4. Well not just, I've left the mmio/register work
from Ville in here since it's low-risk but lots of churn all over.
* tag 'drm-intel-next-fixes-2015-10-22' of git://anongit.freedesktop.org/drm-intel: (23 commits)
drm/i915: Use round to closest when computing the CEA 1.001 pixel clocks
drm/i915: Kill the leftover RMW from ivb_sprite_disable()
drm/i915: restore ggtt double-bind avoidance
drm/i915/skl: Enable pipe gamma for sprite planes.
drm/i915/skl+: Enable pipe CSC on cursor planes. (v2)
MAINTAINERS: add link to the Intel Graphics for Linux web site
drm/i915: Move skl/bxt gt specific workarounds to ring init
drm/i915: Drop i915_gem_obj_is_pinned() from set-cache-level
drm/i915: revert a few more watermark commits
drm/i915: Remove dev_priv argument from NEEDS_FORCE_WAKE
drm/i915: Clean up LVDS register handling
drm/i915: Throw out some useless variables
drm/i915: Parametrize and fix SWF registers
drm/i915: s/PIPE_FRMCOUNT_GM45/PIPE_FRMCOUNT_G4X/ etc.
drm/i915: Turn GEN5_ASSERT_IIR_IS_ZERO() into a function
drm/i915: Fix a few bad hex numbers in register defines
drm/i915: Protect register macro arguments
drm/i915: Include gpio_mmio_base in GMBUS reg defines
drm/i915: Parametrize HSW video DIP data registers
drm/i915: Eliminate weird parameter inversion from BXT PPS registers
...
If driver backlight control is disabled, either by driver
parameter or default per-asic setting, revert to the old behavior.
Fixes a regression in commit:
4281f46ef8
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
So that the bl encoder will be null if the GPU does not
control the backlight.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
We are going to submit them before the job anyway.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
v2: (Rodrigo) Rebase after commit 3cb27f38f
("drm/i915: remove an extra level of indirection in PCI ID list")
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Deepak S <deepak.s@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446060072-19489-1-git-send-email-rodrigo.vivi@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
v2: separate out device info into different GT (Damien)
v3: Add is_kabylake to the KBL gt3 structuer (Damien)
Sort the platforms in older -> newer order (Damien)
v4: Split platform definition since is_skylake=1 on
kabylake structure was Nacked. (Rodrigo)
v5: (Rodrigo) Rebase after commit 3cb27f38f
("drm/i915: remove an extra level of indirection in PCI ID list")
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Deepak S <deepak.s@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446059991-17033-1-git-send-email-rodrigo.vivi@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Kabylake is a Intel® Processor containing Intel® HD Graphics
following Skylake.
It is Gen9p5, so it inherits everything from Skylake.
Let's start by adding the platform separated from Skylake
but reusing most of all features, functions etc. Later we
rebase the PCI-ID patch without is_skylake=1
so we don't replace what original Author did there.
Few IS_SKYLAKEs if statements are not being covered by this patch
on purpose:
- Workarounds: Kabylake is derivated from Skylake H0 so no
W/As apply here.
- GuC: A following patch removes Kabylake support with an
explanation: No firmware available yet.
- DMC/CSR: Done in a separated patch since we need to be carefull
and load the version for revision 7 since
Kabylake is Skylake H0.
v2: relative cleaner commit message and added the missed
IS_KABYLAKE to intel_i2c.c as pointed out by Jani.
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Add the PCI IDs directly in the pciidlist array instead of defining an
extra macro. The minor benefit from this is neater diffs when adding to
the end of the list.
v2: drop the "aka" comment (Ville)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446053589-21283-1-git-send-email-jani.nikula@intel.com
Although we don't support or enable CPU PWM with LPT/SPT based systems,
it may have been enabled prior to loading the driver. Disable the CPU
PWM on LPT/SPT backlight disable to avoid warnings on LCPLL disable.
The issue has been present on BDW since BDW enabling, but was recently
introduced on HSW with
commit 437b15b801
Author: Jani Nikula <jani.nikula@intel.com>
Date: Fri Sep 4 16:55:13 2015 +0300
drm/i915: use pch backlight override on hsw too
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reference: http://mid.gmane.org/87y4frhwsn.fsf@yhuang-dev.intel.com
Reported-by: kernel test robot <ying.huang@intel.com>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446033429-8006-1-git-send-email-jani.nikula@intel.com
Having flushed all requests from all queues, we know that all
ringbuffers must now be empty. However, since we do not reclaim
all space when retiring the request (to prevent HEADs colliding
with rapid ringbuffer wraparound) the amount of available space
on each ringbuffer upon reset is less than when we start. Do one
more pass over all the ringbuffers to reset the available space
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Arun Siluvery <arun.siluvery@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Dave Gordon <david.s.gordon@intel.com>
An spi_driver does not need to set an owner, it will be populated by the
driver core.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
A typo resulted in the watermarks for cursor planes not being calculated
correctly. Fixed the typo.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Thomas Daniel <thomas.daniel@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Taking the grph update lock is only necessary when
updating the the secondary address (for single pipe stereo).
v2: fix comment as per Michel's suggestion
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Include an early NEEDS_FORCEWAKE() check for vlv and chv.
Hopefully that will avoid doing so many range checks in for many
register accesses (at least for all display registers).
Note that vlv already had the check in the write path since it shares
the gen6+ code for that.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445517300-28173-6-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Change the fw domain handling in the vlv/chv register read/write
functions to look more like the SKL code, ie. have a single
__force_wake_get() get call instead of multiple ones.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445517300-28173-5-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Change FORCEWAKE & co. reads for the error state to use I915_READ_FW().
Reading a FORCEWAKE register using a function that can frob forcewake
just seems wrong.
There is a check to skip grabbing the forcewake for accessing FORCEWAKE
in intel_uncore.c, but there's no such check for FORCEWAKE_MT. So no
idea what is currently happening with FORCEWAKE_MT reads. FORCEWAKE_VLV
is fortunately outside the forcewake range anyway, so no actual issue
with that one.
So let's just make the rule that you can't access FORCEWAKE registers with
the normal I915_READ() stuff, and we can drop the extra FORCEWAKE check
from NEEDS_FORCEWAKE(). While at it use NEEDS_FORCEWAKE() on BDW, where
it was skipped for whatever bikeshed reason that I've already forgotten.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445517300-28173-3-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
There's no need for __raw_i915_read8() & co. to be macros, so make them
inline functions. To avoid typo mistakes generate the inline functions
using preprocessor templates.
We have a few users of the raw register acces functions outside
intel_uncore.c, so let's also move the functions into intel_drv.h.
While doing that switch I915_READ_FW() & co. to use the
__raw_i915_read() functions, and use the _FW macros everywhere
outside intel_uncore.c where we want to read registers without
grabbing forcewake and whatnot. The only exception is
i915_check_vgpu() which itself gets called from intel_uncore.c,
so using the __raw_i915_read stuff there seems appropriate.
v2: Squash in the intel_uncore.c->i915_drv.h move
Convert I915_READ_FW() to use __raw_i915_read(), and use
I915_READ_FW() outside of intel_uncore.c (Chris)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445517300-28173-2-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Not much core work here, a few small tweaks to interfaces but mainly the
changes here are driver ones. Highlights include:
- Updates to the topology userspace interface
- Big updates to the Renesas support from Morimoto-san
- Most of the support for Intel Sky Lake systems.
- New drivers for Asahi Kasei Microdevices AK4613, Allwinnner A10,
Cirrus Logic WM8998, Dialog DA7219, Nuvoton NAU8825 and Rockchip
S/PDIF.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJWLbbGAAoJECTWi3JdVIfQH7oH/1VdN2ozP9A03p24aC5qso1F
VWOBnG4pkw1G6J5qK2lemMDeJdRdTfreICUAa9Tw9kOSfTIb6F3X8kCw8tbwlw0I
4phgmyo23P53OfLZFMkQi/RCfwItnE0sszqhvoumUg0ryjYxg2JT+gTMgwvVo7Pq
hf6m6a3we5pxLIIYP4wlQgOKwUJe4B4nC37ExySf24Dlo/DzmWDtfQbGvmyluFzb
MB1qzEvAc/KC3LZFkIFmhfg2/caNRhcQrzkUCYrLR3t+oz9P1zCpYTII7VDdMg7L
SM2VoL+ynEAdBqa38Ozwxvd/mpHwinlAeiikuwz1PyxVOqZvZqqiWzD8eUJkhZk=
=/F/Q
-----END PGP SIGNATURE-----
Merge tag 'asoc-v4.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-next
ASoC: Updates for v4.4
Not much core work here, a few small tweaks to interfaces but mainly the
changes here are driver ones. Highlights include:
- Updates to the topology userspace interface
- Big updates to the Renesas support from Morimoto-san
- Most of the support for Intel Sky Lake systems.
- New drivers for Asahi Kasei Microdevices AK4613, Allwinnner A10,
Cirrus Logic WM8998, Dialog DA7219, Nuvoton NAU8825 and Rockchip
S/PDIF.
- A new driver for the Atmel Class D speaker drivers
Struct of gem object in exynos_drm driver is struct exynos_drm_gem_obj.
It's too long and we can know its meaning of name without _obj postfix.
We use several names to variable name of gem object for exynos_drm -
exynos_gem_obj, gem_obj and obj. Especially "obj" name can cause
misunderstanding with variable name "obj" of struct drm_gem_object.
This will clean about name of gem object for exynos_drm as follows.
s/struct exynos_drm_gem_obj/struct exynos_drm_gem
s/exynos_gem_obj or gem_obj or obj/exynos_gem
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The arm_iommu_detach_device() is a function to detach device of iommu
attached by arm_iommu_attach_device(). The exynos-drm uses
arm_iommu_attach_device() so it should use arm_iommu_detach_device() to
detach device of iommu, not iommu_detach_device().
The drm_release_iommu_mapping() is a function to release mapping of
iommu created by arm_iommu_create_mapping(). It is called by
exynos_drm_unload() so shouldn't be called by drm_iommu_detach_device().
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Set one of the planes for each crtc driver as a cursor plane enabled
window managers to fully work on exynos.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Define DEFAULT_WIN as zero to help set the primary plane on all CRTCs.
Some CRTCs were defining a variable to store the default window, but that
is not necessary as the default (primary) window is always the window zero.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This patch fixes calling usleep_range() after taking reg_slock
using spin_lock_irqsave(). The mdelay() is used instead.
Waiting in atomic context is not the best idea in general.
Hopefully, waiting occurs only when Video Processor fails
to reset correctly.
Signed-off-by: Tomasz Stanislawski <t.stanislaws@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Simple formula can be used to calculate CTS and N coefficients.
Additionaly ACR registers have different offsets for different versions
of IP.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Inline function is safer than macro, also the name has been changed to
be consistent with other inline function encoder_to_hdmi.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
hdmi_resources structure was filled by old platform data code and is not
necessary anymore. The patch removes it at groups together resource related
fields in hdmi_context.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The patch converts API to gpiod and moves initialization code
to hdmi_resources_init.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Driver tries to disable sclk_hdmi during re-parenting, to avoid possible
glitches. It is ineffective as the clock is used also by other devices (mixer).
Anyway driver works without disabling sclk_hdmi.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Driver always uses the same number of regulators, so there is no point in
dynamic allocation.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
hdmi-en is an optional regulator so it should be better handled by
devm_regulator_get_optional call.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
DRM device should be destroyed before releasing resources.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Registers are 32-bit, even if only lower 8-bits are used.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Currently driver tries to set specific HDMI-PHY registers in three situations:
- before reset,
- before power off,
- after applying HDMI-PHY configuration.
First two cases seems to be unnecessary - register contents will be lost
anyway. The third case can be merged with HDMI-PHY configuration by fixing
the last byte of configuration data.
The patch has been tested with following platforms:
- exynos4210-universal_c210,
- exynos4412-odroidu3,
- exynos5422-odroidxu3.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The patch moves PLL stabilization check to separate function, adjust timeout
parameters and de-duplicates code common for both HW variants.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Some registers resides at different offsets depending on device version.
This patch adds infrastructure for mapping such registers to proper address
based on hdmi_type. It adds also mappings to some registers.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This compatible was marked as deprecated in Jun 2013 and it is not used since
then. Additionally its driver data points to wrong pll settings, so it
cannot work anyway.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
I'm not sure whether this patch comes in too late, but it would be good to
have it in. It stabilizes command submission in case of command buffer errors.
* 'vmwgfx-fixes-4.3' of git://people.freedesktop.org/~thomash/linux:
drm/vmwgfx: Stabilize the command buffer submission code
Taking the grph update lock is only necessary when
updating the the secondary address (for single pipe stereo).
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Taking the grph update lock is only necessary when
updating the the secondary address (for single pipe stereo).
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Taking the grph update lock is only necessary when
updating the the secondary address (for single pipe stereo).
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Since we're not synchronizing the ring request list during error state capture
the request list state might change between the time the corresponding error
request list was allocated and dimensioned to the time when the ring request
list is actually captured into the error state. If this happens then do an
early exit and be aware that the captured error state might not be fully
reliable.
* v2:
- Chris Wilson: Removed WARN_ON from size check since having the error state
request list and the live driver request list diverge like this is a
legitimate behaviour.
- Tomas Elf: Removed update of num_request field since this made no sense. Just
exit and move on.
* v3:
- Chris Wilson: Removed error message at the point of early exit. The user is
not interested in any state changes happening during the error state capture,
only in the state that we're trying to capture at the point of the error.
Signed-off-by: Tomas Elf <tomas.elf@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This reverts commit 5105672341.
I somehow managed to combine a patch from Tomas Elf with a totally
unrelated commit message from Chris Wilson. Let's revert this and
reapply properly.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
We get tons of cases where the master interrupt handler apparently set
a bit, with the SDEIIR disagreeing. No idea what's going on there, but
it's consistent on gen8+, no one seems to care about it and it's
making CI results flaky.
Shut it up.
No idea what's going on here, but we've had fun with PCH interrupts
before:
commit 44498aea29
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date: Fri Feb 22 17:05:28 2013 -0300
drm/i915: also disable south interrupts when handling them
Note that there's a regression report in Bugzilla, and other
regression reports on the mailing lists keep croping up. But no ill
effects have ever been reported. But for paranoia still keep the
message at a debug level as a breadcrumb, just in case.
This message was introduced in
commit 38cc46d73e
Author: Oscar Mateo <oscar.mateo@intel.com>
Date: Mon Jun 16 16:10:59 2014 +0100
drm/i915/bdw: Ack interrupts before handling them (GEN8)
v2: Improve commit message a bit.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445590572-23631-2-git-send-email-daniel.vetter@ffwll.ch
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92084
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80896
Acked-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
DRM_MSM_FBDEV config is used to enable/disable fbdev emulation for the
msm kms driver.
Replace this with the top level DRM_FBDEV_EMULATION config option where
applicable. This also prevents build breaks caused by undefined
drm_fb_helper_* functions when legacy fbdev support was disabled.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
This change adds the basic MDP5 support for MSM8996.
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
In order to produce an image, the scalar needs to be fed extra
pixels. These top/bottom/left/right values depend on a various of
factors, including resolution, scaling type, phase step and
initial phase.
Pixel Extension are programmed by hardware in most targets - and
can be overwritten by software. For some targets (e.g.: msm8996),
software *must* program those registers.
In order to ease this computation, let's always use bilinear
filters, which are easier to program from kernel. Eventually,
all of these values will come down from user space for better
quality.
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
When calculating phase steps, let's use the same enum
mdp_component_type in order to ease the readability; 0/1 indexes
are a bit confusing and we now have explicit values to index
this type of arrays.
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
The HDMI controller is new in MDP5 v1.7. As of now, this change
doesn't reflect the novelty and only adds the basics so the probe
gets triggered.
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
The current behavior is to try to get optional clocks and print a
dev_err message in case of failure. This looks rather confusing
and may increase with the amount of optional clocks.
We may need a cleaner way to handle per-device clocks but in the
meantime, let's reduce the amount of dev_err messages during the
probe.
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
msm_iommu_new() can fail and this change makes sure that we
detect the failure and free the allocated domain before going
any further.
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
We want to make sure we control all the information being passed
down to SMP block. Having access to the cfg pointer here may create
bad things in the future.
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
The current settings for 28nm PHY data lane CFG4 registers do
not work with certain panels. This change is to modify them to
hw recommended values.
Signed-off-by: Hai Li <hali@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
In some configurations the supplies are voltage switches and not LDOs,
making the set voltage call to fail. Check with the regulator framework
if the supply can change voltage before attempting.
Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Reviewed-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Grab execlist lock when cleaning up execlist queues after GPU reset to avoid
concurrency problems between the context event interrupt handler and the reset
path immediately following a GPU reset.
* v2 (Chris Wilson):
Do execlist check and use simpler form of spinlock functions.
Signed-off-by: Tomas Elf <tomas.elf@intel.com>
Reviewed-by: Dave Gordon <david.s.gordon@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
commit 0706f17c30
Author: Egbert Eich <eich@suse.de>
Date: Wed Sep 23 16:15:27 2015 +0200
drm/i915: Avoid race of intel_crt_detect_hotplug() with HPD interrupt, v2
added a check with WARN to ensure only bits within the mask are
enabled. Turns out that doesn't hold for G4X, which spits out:
[ 2.641439] ------------[ cut here ]------------
[ 2.641444] WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/i915/i915_irq.c:182 i915_hotplug_interrupt_update_locked+0x45/0x83()
[ 2.641446] WARN_ON(bits & ~mask)
etc.
Add CRT_HOTPLUG_ACTIVATION_PERIOD_64 to the mask to fix the warning.
Reported-and-tested-by: Oleksij Rempel <linux@rempel-privat.de>
References: https://bugzilla.kernel.org/show_bug.cgi?id=104991
Fixes: 0706f17c30 ("drm/i915: Avoid race of intel_crt_detect_hotplug() with HPD interrupt, v2")
Cc: Egbert Eich <eich@suse.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1445437363-3030-1-git-send-email-jani.nikula@intel.com
Userspace can pass in an offset that it presumes the object is located
at. The kernel will then do its utmost to fit the object into that
location. The assumption is that userspace is handling its own object
locations (for example along with full-ppgtt) and that the kernel will
rarely have to make space for the user's requests.
v2: Fix i915_gem_evict_range() (now evict_for_vma) to handle ordinary
and fixed objects within the same batch
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: "Daniel, Thomas" <thomas.daniel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
rcar-du support for r8a7793/4
* 'drm/next/du' of git://linuxtv.org/pinchartl/fbdev:
drm: rcar-du: Add support for the R8A7794 DU
drm: rcar-du: Add support for the R8A7793 DU
This pull request introduces the vc4 driver, for kernel modesetting on
the Raspberry Pi (bcm2835/bcm2836 architectures). It currently
supports a display plane and cursor on the HDMI output. The driver
doesn't do 3D, power management, or overlay planes yet.
[airlied: fixup the enable/disable vblank APIs]
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* tag 'drm-vc4-next-2015-10-21' of http://github.com/anholt/linux:
drm/vc4: Allow vblank to be disabled
drm/vc4: Use the fbdev_cma helpers
drm/vc4: Add KMS support for Raspberry Pi.
drm/vc4: Add devicetree bindings for VC4.
Just a crash fix for radeon and amdgpu if the user has forcibly disabled
dpm and tries to access the pwm sysfs controls.
* 'drm-fixes-4.3' of git://people.freedesktop.org/~agd5f/linux:
drm/amdgpu: add missing dpm check for KV dpm late init
drm/amdgpu/dpm: don't add pwm attributes if DPM is disabled
drm/radeon/dpm: don't add pwm attributes if DPM is disabled
The revert dance could use some explanation: we had stuff fixed in
-next, and initially backported one commit to v4.3. Now, turns out we
need more fixes, and we could cherry-pick them all without conflicts if
we reverted the backported one first. So did that to not have to edit
and backport them all.
* tag 'drm-intel-fixes-2015-10-16' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Add primary plane to mask if it's visible
drm/i915: Move sprite/cursor plane disable to intel_sanitize_crtc()
drm/i915: Assign hwmode after encoder state readout
Revert "drm/i915: Add primary plane to mask if it's visible"
drm/i915: Deny wrapping an userptr into a framebuffer
drm/i915: Enable DPLL VGA mode before P1/P2 divider write
drm/i915: Restore lost DPLL register write on gen2-4
drm/i915: Flush pipecontrol post-sync writes
drm/i915: Fix kerneldoc for i915_gem_shrink_all
Just one fix from Ilia to resolve various issues that have resulted from
buffer eviction.
* 'linux-4.3' of git://anongit.freedesktop.org/nouveau/linux-2.6:
drm/nouveau/gem: return only valid domain when there's only one
On nv50+, we restrict the valid domains to just the one where the buffer
was originally created. However after the buffer is evicted to system
memory, we might move it back to a different domain that was not
originally valid. When sharing the buffer and retrieving its GEM_INFO
data, we still want the domain that will be valid for this buffer in a
pushbuf, not the one where it currently happens to be.
This resolves fdo#92504 and several others. These are due to suspend
evicting all buffers, making it more likely that they temporarily end up
in the wrong place.
Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92504
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
In Linux 4.3-rc5, there is an error case in drm_dp_get_branch_device
that returns without releasing mgr->lock, resulting a spew of kernel
messages about a kernel work function possibly having leaked a mutex
and presumably more serious adverse consequences later. This patch
changes the error to "goto out" to unlock the mutex before returning.
[airlied: grabbed from drm-next as it fixes something we've seen]
Signed-off-by: Adam J. Richter <adam_richter2004@yahoo.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
v2: Don't forget to actually check the cstate->active value when
tallying up the number of active CRTC's. (Ander)
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Smoke-tested-by: Paulo Zanoni <przanoni@gmail.com>
Link: http://patchwork.freedesktop.org/patch/59561/
We already ensure that pstate->visible = false when crtc->active = false
during runtime programming; make sure we follow the same logic when
reading out initial hardware state.
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Smoke-tested-by: Paulo Zanoni <przanoni@gmail.com>
Link: http://patchwork.freedesktop.org/patch/59564/
Calculate pipe watermarks during atomic calculation phase, based on the
contents of the atomic transaction's state structure. We still program
the watermarks at the same time we did before, but the computation now
happens much earlier.
While this patch isn't too exciting by itself, it paves the way for
future patches. The eventual goal (which will be realized in future
patches in this series) is to calculate multiple sets up watermark
values up front, and then program them at different times (pre- vs
post-vblank) on the platforms that need a two-step watermark update.
While we're at it, s/intel_compute_pipe_wm/ilk_compute_pipe_wm/ since
this function only applies to ILK-style watermarks and we have a
completely different function for SKL-style watermarks.
Note that the original code had a memcmp() in ilk_update_wm() to avoid
calling ilk_program_watermarks() if the watermarks hadn't changed. This
memcmp vanishes here, which means we may do some unnecessary result
generation and merging in cases where watermarks didn't change, but the
lower-level function ilk_write_wm_values already makes sure that we
don't actually try to program the watermark registers again.
v2: Squash a few commits from the original series together; no longer
leave pre-calculated wm's in a separate temporary structure since
it's easier to follow the logic if we just cut over to using the
pre-calculated values directly.
v3:
- Pass intel_crtc instead of drm_crtc to .compute_pipe_wm() entrypoint
and use intel_atomic_get_crtc_state() to avoid need for extra
casting. (Ander)
- Drop unused intel_check_crtc() function prototype. (Ander)
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Smoke-tested-by: Paulo Zanoni <przanoni@gmail.com>
Link: http://patchwork.freedesktop.org/patch/60363/
A future patch will calculate these during the atomic 'check' phase
rather than at WM programming time, so let's store the watermark
values we're planning to use in the CRTC state; the values actually
active on the hardware remains in intel_crtc.
While we're at it, do some minor restructuring to keep ILK and SKL
values in a union.
v2: Don't move cxsr_allowed to state (Maarten)
v3: Only calculate watermarks in state. Still keep active watermarks in
intel_crtc itself. (Ville)
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Smoke-tested-by: Paulo Zanoni <przanoni@gmail.com>
Link: http://patchwork.freedesktop.org/patch/59556/
Split ilk_update_wm() into two parts; one doing the programming
and the other the calculations.
v2: Fix typo in commit message
v3 (by Matt): Heavily rebased for current codebase.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Smoke-tested-by: Paulo Zanoni <przanoni@gmail.com>
Link: http://patchwork.freedesktop.org/patch/60366/
The only platform that still has an update_sprite_wm entrypoint is SKL;
on SKL, intel_update_sprite_watermarks just updates intel_plane->wm and
then performs a regular watermark update. However intel_plane->wm is
only used to update a couple fields in intel_wm_config, and those fields
are never used by the SKL code, so on SKL an update_sprite_wm is
effectively identical to an update_wm call. Since we're already
ensuring that the regular intel_update_wm is called any time we'd try to
call intel_update_sprite_watermarks, the whole call is redundant and can
be dropped.
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Smoke-tested-by: Paulo Zanoni <przanoni@gmail.com>
Link: http://patchwork.freedesktop.org/patch/60372/
Determine whether we need to apply this workaround at atomic check time
and just set a flag that will be used by the main watermark update
routine.
Moving this workaround into the atomic framework reduces
ilk_update_sprite_wm() to just a standard watermark update, so drop it
completely and just ensure that ilk_update_wm() is called whenever a
sprite plane is updated in a way that would affect watermarks.
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Smoke-tested-by: Paulo Zanoni <przanoni@gmail.com>
Link: http://patchwork.freedesktop.org/patch/60367/
This commit addresses some stability problems with the command buffer
submission code recently introduced:
1) Make the vmw_cmdbuf_man_process() function handle reruns internally to
avoid losing interrupts if the caller forgets to rerun on -EAGAIN.
2) Handle default command buffer allocations using inline command buffers.
This avoids rare allocation deadlocks.
3) In case of command buffer errors we might lose fence submissions.
Therefore send a new fence after each command buffer error. This will help
avoid lengthy fence waits.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
That's still small enough to not waste to much memory on PD/PTs.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Stoney is VCE 3.x single.
v2: Stoney is single pipe like Fiji
Signed-off-by: Samuel Li <samuel.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Stoney is GFX 8.1.
v2: update to latest golden settings
Signed-off-by: Samuel Li <samuel.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Stoney is SDMA 3.x.
v2: update to latest golden register settings
Signed-off-by: Samuel Li <samuel.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The R8A7794 DU has a fixed output routing configuration with one RGB
output per CRTC and thus lacks the RGB output routing register field.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
The R8A7793 DU is identical to the R8A7791 and thus only requires a new
DT compatible string.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
fix the vm->mutex and ww_mutex confilcts.
vm->mutex is always token first, then ww_mutex.
V2: remove unneccessary checking for pt bo.
Change-Id: Iea56e183752c02831126d06d2f5b7a474a6e4743
Signed-off-by: Chunming Zhou <david1.zhou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
It didn't worked to well anyway.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com>
Requested by Chris, and since we're no longer rebasing the -next queue
I can't rectify history.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Nick Hoath <nicholas.hoath@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445415633-21897-1-git-send-email-daniel.vetter@ffwll.ch
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The size / offset information of all firmware ingredients are
now caculated from header. Driver will validate the header and
rsa key size. If any component is out of boundary, driver will
reject the loading too.
v6: Clean up warnings from make docs
v5: Tidy up GuC titles in kernel/Doc
v4: Now using 'size_dw' for those defined in css_header
v3: 1) Move DOC to intel_guc_fwif.h right before css_header
definition. Add more comments.
2) Change 'size' to 'len' or 'length' to avoid confusion.
3) Add UOS_RSA_SCRATCH_MAX_COUNT according to BSpec. And
driver validate size of RSA key now.
4) Add fw component size/offset info to intel_guc_fw.
v2: Add indent into DOC to make fixed-width format rather than
change the tmpl.
v1: 1) guc_css_header is defined as __packed now
2) Add and correct GuC related topics in kernel/Doc
Signed-off-by: Alex Dai <yu.dai@intel.com>
Reviewed-by: Dave Gordon <david.s.gordon@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Keep the fbdev_cma pointer around so we can use it on hotplog and close
to ensure the frame buffer console is in a useful state.
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
