- 28 Nov, 2016 8 commits
-
-
Jordan Crouse authored
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>
-
Jordan Crouse authored
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>
-
Jordan Crouse authored
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>
-
Jordan Crouse authored
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>
-
Rob Clark authored
Pull in a5xx registers. Signed-off-by:
Rob Clark <robdclark@gmail.com>
-
Rob Clark authored
Scratch registers move, annoyingly enough, in a5xx. Move to per-generation aNxx_recover() fxn. Signed-off-by:
Rob Clark <robdclark@gmail.com>
-
Rob Clark authored
For backwards compat, the rd format puts the high 32b after the size field in the GPUADDR packet. Signed-off-by:
Rob Clark <robdclark@gmail.com>
-
Rob Clark authored
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>
-
- 27 Nov, 2016 17 commits
-
-
Rob Clark authored
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>
-
Archit Taneja authored
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>
-
Rob Clark authored
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>
-
Rob Clark authored
If the dumpstate modparam is enabled, for debugging error irq's, also dump SMP state. Signed-off-by:
Rob Clark <robdclark@gmail.com>
-
Rob Clark authored
Signed-off-by:
Rob Clark <robdclark@gmail.com>
-
Rob Clark authored
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>
-
Rob Clark authored
(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>
-
Rob Clark authored
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>
-
Rob Clark authored
This will give the kms backends a slot to stash their own hw specific global state. Signed-off-by:
Rob Clark <robdclark@gmail.com>
-
Rob Clark authored
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>
-
Rob Clark authored
It wasn't really doing the right thing if, for example, position or height changed. Signed-off-by:
Rob Clark <robdclark@gmail.com>
-
Rob Clark authored
Signed-off-by:
Rob Clark <robdclark@gmail.com>
-
Rob Clark authored
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>
-
Rob Clark authored
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>
-
Rob Clark authored
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>
-
Rob Clark authored
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>
-
Rob Clark authored
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>
-
- 26 Nov, 2016 6 commits
-
-
Rob Clark authored
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>
-
Rob Clark authored
Signed-off-by:
Rob Clark <robdclark@gmail.com>
-
Rob Clark authored
Signed-off-by:
Rob Clark <robdclark@gmail.com>
-
Rob Clark authored
The same file in libdrm is, as is the tradition with the rest of libdrm, etc, using an MIT license. To avoid complications in the future with sync'ing the uapi header to libdrm, lets fix the license mismatch now before there are any non-trivial commits from someone other than myself. Cc: Emil Velikov <emil.l.velikov@gmail.com> Cc: Gabriel Laskar <gabriel@lse.epita.fr> Cc: Mikko Rapeli <mikko.rapeli@iki.fi> Signed-off-by:
Rob Clark <robdclark@gmail.com> Acked-by:
Emil Velikov <emil.l.velikov@gmail.com>
-
Rob Clark authored
Looks like cut/paste error from the other device cfgs (which do support scaling on RGBn pipes). Signed-off-by:
Rob Clark <robdclark@gmail.com>
-
Rob Clark authored
If the bottom-most layer is not fullscreen, we need to use the BASE mixer stage for solid fill (ie. MDP5_CTL_BLEND_OP_FLAG_BORDER_OUT). The blend_setup() code pretty much handled this already, we just had to figure this out in _atomic_check() and assign the stages appropriately. Also fix the case where there are zero enabled planes, where we also need to enable BORDER_OUT. Signed-off-by:
Rob Clark <robdclark@gmail.com>
-
- 24 Nov, 2016 2 commits
-
-
git://git.armlinux.org.uk/~rmk/linux-armDave Airlie authored
These updates: * improve the robustness of the driver wrt races * improve the compliance for sending infoframes and audio * re-organise the function order in the driver to group like functions together. (This unfortunately causes a conflict with the change in drm-misc, but it should be trivial to solve, although it looks more scarey than it really is - sfr has already sent two reports about this, one earlier today.) * simplify tda998x_audio_get_eld and DPMS handling * power down sections of the chip that we never use * add some initial preparation for supporting the CEC driver * 'drm-tda998x-devel' of git://git.armlinux.org.uk/~rmk/linux-arm: drm/i2c: tda998x: fix spelling mistake drm/i2c: tda998x: allow sharing of the CEC device accesses drm/i2c: tda998x: allow interrupt to be shared drm/i2c: tda998x: power down pre-filter and color conversion drm/i2c: tda998x: switch to boolean is_on drm/i2c: tda998x: remove complexity from tda998x_audio_get_eld() drm/i2c: tda998x: group audio functions together drm/i2c: tda998x: separate connector initialisation drm/i2c: tda998x: group connector functions and funcs together drm/i2c: tda998x: move and rename tda998x_encoder_set_config() drm/i2c: tda998x: correct function name in comments drm/i2c: tda998x: only enable audio if supported by sink drm/i2c: tda998x: only configure infoframes and audio if supported drm/i2c: tda998x: avoid race when programming audio drm/i2c: tda998x: avoid racy access to mode clock drm/i2c: tda998x: avoid race in tda998x_encoder_mode_set() drm/i2c: tda998x: move audio mutex initialisation
-
git://git.armlinux.org.uk/~rmk/linux-armDave Airlie authored
Building on top of the MALI change previously merged, these changes: * add tracing support for overlay updates * refactor some of the plane support code * de-midlayer the driver * cleanups from other folk reviewing the code * 'drm-armada-devel' of git://git.armlinux.org.uk/~rmk/linux-arm: drm/armada: fix NULL pointer comparison warning drm/armada: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops drm/armada: remove some dead code drm/armada: mark symbols static where possible drm/armada: de-midlayer armada drm/armada: use common helper for plane base address drm/armada: move setting primary plane position to armada_drm_primary_set() drm/armada: split out primary plane update drm/armada: move plane state to struct armada_plane drm/armada: clean up armada_drm_plane_work_run() drm/armada: add tracing support
-
- 21 Nov, 2016 1 commit
-
-
http://github.com/zourongrong/linuxDave Airlie authored
hibmc drm driver for hisilicon. * tag 'drm-hisilicon-next-2016-11-17' of http://github.com/zourongrong/linux: MAINTAINERS: Update HISILICON DRM entries drm/hisilicon/hibmc: Add support for vblank interrupt drm/hisilicon/hibmc: Add support for VDAC drm/hisilicon/hibmc: Add support for display engine drm/hisilicon/hibmc: Add support for frame buffer drm/hisilicon/hibmc: Add video memory management drm/hisilicon/hibmc: Add hisilicon hibmc drm master driver
-
- 18 Nov, 2016 6 commits
-
-
Colin Ian King authored
Trivial fix to spelling mistake "configutation" to "configuration" in dev_err message Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk>
-
Russell King authored
cec_read() is non-atomic in the presence of other I2C bus transactions to the same device. This presents a problem when we add support for the TDA9950 CEC engine part - both drivers can be trying to access the device. Avoid the inherent problems by switching to i2c_transfer() instead, which allows us to perform more than one bus transaction atomically. As this means we will be using I2C transactions rather than SMBUS, we have to check that the host supports I2C functionality. Tested-by:
Brian Starkey <brian.starkey@arm.com> Reviewed-by:
Brian Starkey <brian.starkey@arm.com> Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk>
-
Russell King authored
Some TDA998x contain several different I2C devices - there is the HDMI encoder, and there is a TDA9950 CEC engine. These two share the same interrupt signal. In order to allow a driver for the CEC engine to work, we need to be able to share the interrupt with the CEC driver, so convert the handler and registration to allow this to happen. Tested-by:
Brian Starkey <brian.starkey@arm.com> Reviewed-by:
Brian Starkey <brian.starkey@arm.com> Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk>
-
Russell King authored
Disabling the pre-filter block of the TDA998x saves 40mW and the colour conversion block saves 15mW. As we always disable these two blocks, we can power these sections of the chip down to save 55mW of unnecessary power consumption. Tested-by:
Brian Starkey <brian.starkey@arm.com> Reviewed-by:
Brian Starkey <brian.starkey@arm.com> Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk>
-
Russell King authored
Rather than storing the DPMS mode (which will always be on or off) use a boolean to store this instead. Tested-by:
Robin Murphy <robin.murphy@arm.com> Tested-by:
Jon Medhurst <tixy@linaro.org> Acked-by:
Jon Medhurst <tixy@linaro.org> Tested-by:
Jyri Sarha <jsarha@ti.com> Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk>
-
Russell King authored
tda998x_audio_get_eld() is needlessly complex - the connector associated with the encoder is always our own priv->connector. Remove this complexity, but ensure that there are no races when copying out the ELD. Tested-by:
Jon Medhurst <tixy@linaro.org> Acked-by:
Jon Medhurst <tixy@linaro.org> Tested-by:
Jyri Sarha <jsarha@ti.com> Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk>
-