Disable the interrupt during the init sequence to avoid having
interrupts fired for errors and other things that we are not
ready to handle while initializing.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
The adreno code inherited a silly workaround from downstream
from the bad old days before decent clock control. grp_clk[0]
(named 'src_clk') doesn't actually exist - it was used as a proxy
for whatever the core clock actually was (usually 'core_clk').
All targets should be able to correctly request 'core_clk' and
get the right thing back so zap the anachronism and directly
use grp_clk[0] to control the clock rate.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Add helper functions for TYPE4 and TYPE7 ME opcodes that replace
TYPE0 and TYPE3 starting with the A5XX targets.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Add a new generic function to write a "64" bit value. This isn't
actually a 64 bit operation, it just writes the upper and lower
32 bit of a 64 bit value to a specified LO and HI register. If
a particular target doesn't support one of the registers it can
mark that register as SKIP and writes/reads from that register
will be quietly dropped.
This can be immediately put in place for the ringbuffer base and
the RPTR address. Both writes are converted to use
adreno_gpu_write64() with their respective high and low registers
and the high register appropriately marked as SKIP for both 32 bit
targets (a3xx and a4xx). When a5xx comes it will define valid target
registers for the 'hi' option and everything else will just work.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Add some new functions to manipulate GPU registers. gpu_read64 and
gpu_write64 can read/write a 64 bit value to two 32 bit registers.
For 4XX and older these are normally perfcounter registers, but
future targets will use 64 bit addressing so there will be many
more spots where a 64 bit read and write are needed.
gpu_rmw() does a read/modify/write on a 32 bit register given a mask
and bits to OR in.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
When the GPU hardware init function fails (like say, ME_INIT timed
out) return error instead of blindly continuing on. This gives us
a small chance of saving the system before it goes boom.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
There are very few register accesses in the common code. Cut down
the list of common registers to just those that are used. This
saves const space and saves us the effort of maintaining registers
for A3XX and A4XX that don't exist or are unused.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
For a5xx the gpu is 64b so we need to change iova to 64b everywhere. On
the display side, iova is still 32b so it can ignore the upper bits.
(Although all the armv8 devices have an iommu that can map 64b pa to 32b
iova.)
Signed-off-by: Rob Clark <robdclark@gmail.com>
The newly added sound driver depends on SND_SOC_HDMI_CODEC, which in
turn only makes sense when ASoC is enabled, as shown by this warning:
warning: (DRM_MSM && DRM_STI && DRM_MEDIATEK_HDMI && DRM_I2C_NXP_TDA998X && DRM_DW_HDMI_I2S_AUDIO) selects SND_SOC_HDMI_CODEC which has unmet direct dependencies (SOUND && !M68K && !UML && SND && SND_SOC)
Since the audio driver is probably useless without the audio subsystem,
adding a dependency here seems the right solution.
Fixes: 2761ba6c09 ("drm: bridge: add DesignWare HDMI I2S audio support")
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20161125205411.1157522-1-arnd@arndb.de
smatch correctly warns:
drivers/gpu/drm/drm_fb_helper.c:1960 drm_target_preferred() warn: should '1 << i' be a 64 bit type?
drivers/gpu/drm/drm_fb_helper.c:2001 drm_target_preferred() warn: should '1 << i' be a 64 bit type?
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need to call drm_helper_hpd_irq_event() on resume to properly detect
monitor connection / disconnection on some laptops, use hpd_work for
this to avoid deadlocks.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
We need to call drm_helper_hpd_irq_event() on resume to properly detect
monitor connection / disconnection on some laptops. For runtime-resume
(which gets called on resume from normal suspend too) we must call
drm_helper_hpd_irq_event() from a workqueue to avoid a deadlock.
Rename acpi_work to hpd_work, and move it out of the #ifdef CONFIG_ACPI
blocks to make it suitable for generic work.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The new atomic modesetting/pageflip code for nv50+ for
Linux 4.10+ no longer uses pageflip irq's to signal
flip completion. Instead it polls for flip completion
from within a kthread/work queue.
This creates a race between the vblank irq handler
updating the vblank count and timestamp for the
vblank of flip completion, and the kthread's
polling code detecting flip completion and sending
out the flip completion event.
Depending on who executes a few microseconds earlier,
the flip completion event will either contain correct
count/timestamp or a stale count/timestamp from the
previous vblank. This error was observed for about
50% of all executed flips, e.g., observable under DRI2
by the Xorg.log filling with flip handler warning
messages.
Call drm_accurate_vblank_count() before sending
out flip completion events to enforce a vblank
count/ts update for the vblank of flip completion
and avoid stale counts/timestamps.
This fix leads to one redundant call to drm_update_vblank_count
for each completed flip, but no other side effects. On
a ~6 year old Core i7 M620@ 2.67GHz the redundant call
costs about 10 usecs per flip
Successfully tested on GeForce 9500/9600/330M so far.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Previous value really only made sense on armv7 without LPAE. Everything
that supports more than 4g of memory also has iommu's that can map
anything.
Signed-off-by: Rob Clark <robdclark@gmail.com>
In add_components_mdp, we parse the endpoints in MDP output ports
using the helper for_each_endpoint_of_node(). Our function calls
of_node_put() on the endpoint node before we iterate over the
next one. This is already done by the helper, and results in
trying to decrement the refcount twice.
Remove the extra of_node_put calls. This fixes warnings seen when
we try to insert the driver as a module on IFC6410.
Reported-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
The mode_config->max_{width,height} is for the maximum size of a fb, not
the max scanout limits (of the layer-mixer). It is legal, and in fact
common, to create a larger fb, only only scan-out a smaller part of it.
For example multi-monitor configurations for x11, or android wallpaper
layer (which is created larger than the screen resolution for fast
scrolling by just changing the src x/y coordinates).
Signed-off-by: Rob Clark <robdclark@gmail.com>
Previously, SMP block allocation was not checked in the plane's
atomic_check() fxn, so we could fail allocation SMP block allocation at
atomic_update() time. Re-work the block allocation to request blocks
during atomic_check(), but not update the hw until committing the atomic
update.
Since SMP blocks allocated at atomic_check() time, we need to manage the
SMP state as part of mdp5_state (global atomic state). This actually
ends up significantly simplifying the SMP management, as the SMP module
does not need to manage the intermediate state between assigning new
blocks before setting flush bits and releasing old blocks after vblank.
(The SMP registers and SMP allocation is not double-buffered, so newly
allocated blocks need to be updated in kms->prepare_commit() released
blocks in kms->complete_commit().)
Signed-off-by: Rob Clark <robdclark@gmail.com>
(re)assign the hw pipes to planes based on required caps, and to handle
situations where we could not modify an in-use plane (ie. SMP block
reallocation).
This means all planes advertise the superset of formats and properties.
Userspace must (as always) use atomic TEST_ONLY step for atomic updates,
as not all planes may be available for use on every frame.
The mapping of hwpipe to plane is stored in mdp5_state, so that state
updates are atomically committed in the same way that plane/etc state
updates are managed. This is needed because the mdp5_plane_state keeps
a pointer to the hwpipe, and we don't want global state to become out
of sync with the plane state if an atomic update fails, we hit deadlock/
backoff scenario, etc. The use of state_lock keeps multiple parallel
updates which both re-assign hwpipes properly serialized.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Add basic state duplication/apply mechanism. Following commits will
move actual global hw state into this.
The state_lock allows multiple concurrent updates to proceed as long as
they don't both try to alter global state. The ww_mutex mechanism will
trigger backoff in case of deadlock between multiple threads trying to
update state.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Archit Taneja <architt@codeaurora.org>
Split out the hardware pipe specifics from mdp5_plane. To start, the hw
pipes are statically assigned to planes, but next step is to assign the
hw pipes during plane->atomic_check() based on requested caps (scaling,
YUV, etc). And then hw pipe re-assignment if required if required SMP
blocks changes.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Archit Taneja <architt@codeaurora.org>
Just use plane->name now that it is a thing. In a following patch, once
we dynamically assign hw pipes to planes, it won't make sense to name
planes the way we do, so this also partly reduces churn in following
patch.
Signed-off-by: Rob Clark <robdclark@gmail.com>
We can do this all from mdp5_plane_complete_commit(), so simplify things
a bit and drop mdp5_plane_complete_flip().
Signed-off-by: Rob Clark <robdclark@gmail.com>
Plane's (pipes) can be assigned dynamically with atomic, so it doesn't
make much sense to name the pipe after it's primary plane.
Signed-off-by: Rob Clark <robdclark@gmail.com>
These are really plane-id's, not crtc-id's. Only connection to CRTCs is
that they are used as primary-planes.
Current name is just legacy from when we only supported RGB/primary
planes. Lets pick a better name now.
Signed-off-by: Rob Clark <robdclark@gmail.com>
We can have various combinations of 64b and 32b address space, ie. 64b
CPU but 32b display and gpu, or 64b CPU and GPU but 32b display. So
best to decouple the device iova's from mmap offset.
Signed-off-by: Rob Clark <robdclark@gmail.com>
If fb dimensions are larger than what can be scanned out, but the src
dimensions are not, the hw can still handle this. So clip.
Signed-off-by: Rob Clark <robdclark@gmail.com>
