aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2014-01-14drm: store the gem vma offset manager in a typed pointerDaniel Vetter
This was hidden in a generic void * dev->mm_private. But only ever used for gem. But thanks to this fake generic pretension no one noticed that Rob's drm drivers are now all broken. So just give the offset manager a type pointer and fix up msm, omapdrm and tilcdc. v2: Fixup compile fail. v3: Fixup rebase fail that David spotted. Cc: David Herrmann <dh.herrmann@gmail.com> Cc: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-01-14Merge tag 'vmwgfx-next-2014-01-13' of ↵Dave Airlie
git://people.freedesktop.org/~thomash/linux into drm-next Anyway, nothing big here, Three more code cleanup patches from Rashika Kheria, and one TTM/vmwgfx patch from me that tightens security around TTM objects enough for them to opened using prime objects from render nodes: Previously any client could access a shared buffer using the "name", also without actually opening it. Now a reference is required, and for render nodes such a reference is intended to only be obtainable using a prime fd. vmwgfx-next 2014-01-13 pull request * tag 'vmwgfx-next-2014-01-13' of git://people.freedesktop.org/~thomash/linux: drivers: gpu: Mark functions as static in vmwgfx_fence.c drivers: gpu: Mark functions as static in vmwgfx_buffer.c drivers: gpu: Mark functions as static in vmwgfx_kms.c drm/ttm: ttm object security fixes for render nodes
2014-01-14Merge tag 'ttm-next-2014-01-13' of ↵Dave Airlie
git://people.freedesktop.org/~thomash/linux into drm-next Some code cleanup by Rashika Keria, VM stuff for ttm: -Use PFNMAP instead of MIXEDMAP where possible for performance -Refuse to fault imported pages, an initial step to support dma-bufs better from within TTM. -Correctly set page mapping and -index members. These are needed in various places in the vm subsystem that we are not using yet, but plan to use soonish: For example unmap-mapping-range keeping COW pages, and dirty tracking fbdefio style, but also for PCI memory. ttm-next 2013-01-14 pull request * tag 'ttm-next-2014-01-13' of git://people.freedesktop.org/~thomash/linux: drivers: gpu: Remove unused function in ttm_lock.c drivers: gpu: Mark function as static in ttm_bo_util.c drivers: gpu: Mark function as static in ttm_bo.c drm/ttm: Correctly set page mapping and -index members drm/ttm: Refuse to fault (prime-) imported pages drm/ttm: Use VM_PFNMAP for shared bo maps
2014-01-13drm/cirrus: Fix cirrus drm driver for fbdev + qemuMartin Koegler
Xorg fbdev driver requires smem_start/smem_len, otherwise it tries to map 0 bytes as video memory. Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=856760 Signed-off-by: Martin Koegler <martin.koegler@chello.at> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-01-13Merge branch 'exynos-drm-next' of ↵Dave Airlie
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next This pull request adds an anon file for exynos specific mmaper to resolve potential a dead lock issue pointed out by Al Viro, and fixes build break of drm-next. * 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos: drm/exynos: fix build error caused by removed drm core macros drm/exynos: use a new anon file for exynos gem mmaper
2014-01-13Merge branch 'drm-next-3.14-wip' of ↵Dave Airlie
git://people.freedesktop.org/~agd5f/linux into drm-next This is the drm-next pull for radeon for 3.14. Highlights include: - dpm rework which fixes some issues and allows us to enable dpm by default on CIK parts - enable clockgating on CIK parts - pci config reset. This is a bus-level chip reset that can be more reliable than soft reset in certain cases. Disabled by default. Enable with the hard_reset module option. - big endian rptr/wrptr update fixes - lots of debugfs improvements - some driver cleanup patches from Rashika Kheria - bug fixes * 'drm-next-3.14-wip' of git://people.freedesktop.org/~agd5f/linux: (50 commits) drm/radeon: implement pci config reset for CIK (v3) drm/radeon: implement pci config reset for SI (v2) drm/radeon: implement pci config reset for evergreen/cayman (v2) drm/radeon: implement pci config reset for r6xx/7xx (v3) drm/radeon: add pci config hard reset drm/radeon: add hard_reset module parameter drm/radeon: skip colorbuffer checking if COLOR_INFO.FORMAT is set to INVALID radeon/pm: Guard access to rdev->pm.power_state array drivers: gpu: Move prototype declarations to header file radeon_mode.h from radeon_atombios.c and radeon_combios.c drivers: gpu: Move prototype declaration to header file radeon_mode.h drm/radeon: move com/atombios scratch reg functions to radeon_mode.h drm/radeon/dpm: make some functions static for TN drm/radeon/dpm: make some functions static for sumo drm/radeon/dpm: make some functions static for CI drivers: gpu: Include appropriate header file in ci_smc.c drivers: gpu: Move prototype declaration to header file radeon_mode.h from atombios_i2c.c drivers: gpu: Include appropriate header file in si_smc.c and remove prototype declaration from header file sislands_smc.h drivers: gpu: Add static keyword to the definition of KMS_INVALID_IOCTL in radeon_kms.c drivers: gpu: Mark function as static in r600_hdmi.c drivers: gpu: Mark function as static in radeon_gem.c ...
2014-01-13Merge branch 'msm-next' of git://people.freedesktop.org/~robclark/linux into ↵Dave Airlie
drm-next MSM tree from Rob. * 'msm-next' of git://people.freedesktop.org/~robclark/linux: drm/msm: add a330/apq8x74 drm/msm: add mdp5/apq8x74 drm/msm: add hdmi support for apq8x74/mdp5 drm/msm: move irq utils to mdp_kms drm/msm: split out msm_kms.h drm/msm: mdp4_format -> mdp_format drm/msm: resync generated headers drm/msm: move mdp4 -> mdp/mdp4 drm/msm: add support for msm8060ab/bstem drm/msm: add support for non-IOMMU systems drm/msm: fix bus scaling drm/msm: add missing MODULE_FIRMWARE()s drm/msm: COMPILE_TEST support
2014-01-12Merge branch 'acpi-dsm'Rafael J. Wysocki
* acpi-dsm: ACPI / extlog: replace open-coded _DSM code with helper functions ACPI / nouveau: replace open-coded _DSM code with helper functions nouveau / ACPI: fix memory leak in ACPI _DSM related code ACPI / i915: replace open-coded _DSM code with helper functions ACPI / i2c-hid: replace open-coded _DSM code with helper functions ACPI / TPM: detect PPI features by checking availability of _DSM functions ACPI / TPM: replace open-coded _DSM code with helper functions ACPI / TPM: match node name instead of full path when searching for TPM device PCI / pci-label: treat PCI label with index 0 as valid label ACPI / PCI: replace open-coded _DSM code with helper functions PCI / pci-label: release allocated ACPI object on error recovery path ACPI: introduce helper interfaces for _DSM method
2014-01-12Merge branch 'acpi-cleanup'Rafael J. Wysocki
* acpi-cleanup: (22 commits) ACPI / tables: Return proper error codes from acpi_table_parse() and fix comment. ACPI / tables: Check if id is NULL in acpi_table_parse() ACPI / proc: Include appropriate header file in proc.c ACPI / EC: Remove unused functions and add prototype declaration in internal.h ACPI / dock: Include appropriate header file in dock.c ACPI / PCI: Include appropriate header file in pci_link.c ACPI / PCI: Include appropriate header file in pci_slot.c ACPI / EC: Mark the function acpi_ec_add_debugfs() as static in ec_sys.c ACPI / NVS: Include appropriate header file in nvs.c ACPI / OSL: Mark the function acpi_table_checksum() as static ACPI / processor: initialize a variable to silence compiler warning ACPI / processor: use ACPI_COMPANION() to get ACPI device ACPI: correct minor typos ACPI / sleep: Drop redundant acpi_disabled check ACPI / dock: Drop redundant acpi_disabled check ACPI / table: Replace '1' with specific error return values ACPI: remove trailing whitespace ACPI / IBFT: Fix incorrect <acpi/acpi.h> inclusion in iSCSI boot firmware module ACPI / i915: Fix incorrect <acpi/acpi.h> inclusions via <linux/acpi_io.h> SFI / ACPI: Fix warnings reported during builds with W=1 ... Conflicts: drivers/acpi/nvs.c drivers/hwmon/asus_atk0110.c
2014-01-10drm/i915/bdw: make sure south port interrupts are enabled properly v2Jesse Barnes
We were apparently relying on the defaults on BDW, which resulted in no hotplug or AUX interrupts. So be sure to call the ibx_irq_preinstall to enable all interrupts. v2: use preinstall instead of redundant SDIER write References: https://bugs.freedesktop.org/show_bug.cgi?id=72834 References: https://bugs.freedesktop.org/show_bug.cgi?id=72833 Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-10drm/i915: Include more information in disabled hotplug interrupt warningChris Wilson
Daniel thought that this was an opportune moment to include which pins and bits ended up being stuck in the WARN. Suggested-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-10drm/i915: Only complain about a rogue hotplug IRQ after disablingChris Wilson
Disabling the hotplug IRQ is a two-step process. First, inside the IRQ handler we mark the rogue hotplug pin for disabling. Then later in the hotplug worker, we actually disable the hotplug pin. So we should not WARN about the rogue hotplug IRQ being sent until after we have completed disabling the pin. References: https://bugzilla.redhat.com/show_bug.cgi?id=1051170 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-10drm/i915: Only WARN about a stuck hotplug irq ONCEChris Wilson
It seems that hardware that is broken enough to emit a hotplug IRQ even though the pin is surposedly disable, will do so indefinitely. Note: There's a good chance the underlying issue has been fixed with commit 0ce99f749b3834edeb500e17d6ad17e86b60ff83 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Jul 26 11:27:49 2013 +0200 drm/i915: fix gen4 digital port hotplug definitions References: https://bugzilla.redhat.com/show_bug.cgi?id=1051170 Link: https://bugzilla.redhat.com/attachment.cgi?id=847786 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Add note about the potential fix.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-10drm/i915: s/hotplugt_status_gen4/hotplug_status_g4x/Daniel Vetter
We specifically exclude original gen4 (i.e. i965g/gm), so update the naming for consistency. Spotted while reviewing related code due to a report from Jesse about byt needing again different values. v2: g4x, not gm45 since this also applies to the desktop version. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-10drm/i915: add braces around KHz/MHz macro parametersJani Nikula
It's an accident waiting to happen. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-10drm/i915: Fix 915GM self-refresh enable/disableVille Syrjälä
INSTPM is a masked register so use the _MASKED_BIT_{ENABLE,DISABLE} macros when enabling/disabling self-refresh on 915GM. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-10drm/i915: 830M doesn't have an LVDS portVille Syrjälä
There's no LVDS port on 830M so don't go reading the LVDS control register. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-10drm/i915: No panel fitter on 830M or non-mobile gen2/3 platformsVille Syrjälä
PFIT_CONTROL doesn't exist on 830M, so avoid reading it in i9xx_get_pfit_config(). Also assume that only mobile gen2/3 chipsets have a panel fitter. This matches the documentation, but I didn't have real hardware to verify. Gen4 docmentation is a bit inconsistent, but experimenetation on my LPT machine suggests that the panel fitter is available on non-mobile gen4 platforms. At least on this machine panel fitter appears works just fine even on VGA output. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-10drm/i915/vlv: Add drpc debugfs support for valleyviewDeepak S
Many of the fields from Gen6 have gone away for vlv. Strip all those fields that are not relevent and try to update fields that we care about. This patch give information about current RP & RC status and individual Wells. v2: Move Render & Media Well status to separate lines (Ville) Signed-off-by: Deepak S <deepak.s@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-10drm/i915: vlv: W/a for hotplug/manual VGA detectionImre Deak
VGA detection requires the reference clock to be on, so make sure this is the case. This fixes VGA hotplug/manual detection where all pipes are off and so we would normally disable all clocks. v2: - Instead of disabling PSR clock gating, force the reference clock on through the DPLL_A register. (Kin Chan S <kin.s.chan@intel.com>) v3: - Move enabling of the clock to intel_reset_dpio() and use the DPLL_B register instead, where we already have a similar tweak for the CRI clock. (Ville) Reported-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-10drm/i915: vlv: make CRI clock enabling explicit during resumeImre Deak
intel_init_dpio() isn't called during resume, so we won't set the CRI clock enable bit during that time. Move the enabling to intel_reset_dpio() instead. Note that the HW reset value for this bit is 1, so probably this patch won't make any difference. We should still make the setting explicit, since BIOS could change things under us. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-10drm/i915: only apply GAMMA_MODE IPS WA on HSWPaulo Zanoni
The WA is mentioned in HSW's GAMMA_MODE register documentation, but not on on BDW's documentation, so let's assume it is not needed there. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-10drm/i915: Introduce new intel_output_name()Damien Lespiau
That we can use for debugging purposes. v2: Use designated initializers for the 'names' array (Paulo Zanoni, Jani Nikula). Add a check in case the array has a hole (which can now remain unnoticed with designated initializers) (Jani Nikula) Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (for v1) Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-10drm/i915: don't set modes for 2 connectors on the same encoderPaulo Zanoni
In some cases we have more than 1 connector associated to an encoder (e.g., SDVO, Haswell DP/HDMI) and we can only set a mode for one of these connectors. If we only allowed modesets for connected connectors we would never need this patch, but since we do allow modeset for disconnected connectors we may see user space trying to set modes on the two connectors attached to the same encoder, so we need to forbid that. This problem can be reproduced by running the following intel-gpu-tools test case: ./kms_setmode --run-subtest clone-exclusive-crtc Thanks to Daniel Vetter for providing a version of this patch on pastebin. Credits-to: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-10drm/i915: i830M has watermarks like i855Daniel Vetter
So shuffle the checks around a bit. Also give all the structs and functions proper prefixes: i830_ for the dual-pipe mobile platforms and i845_ for the two single-pipe desktop platforms. Note that the max fifo value isn't actually correct for the i830M, but since we don't frob the fifo split we don't actually need it. This is different for some gen3 devices where we need the full fifo for self refresh mode. Cc: Thomas Richter <richter@rus.uni-stuttgart.de> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-10mkregtable: Fix sscanf handlingAlan
If you feed the tool a suitable bogus register map you can break it in arbitary (code executing) ways. While this isn't a particularly exciting or probable attack vector we still ought to fix it. One of a set of sscanf issues reported by Jackie Chang Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2014-01-10drm/i915: Drop I915_ prefix from HAS_FBCDaniel Vetter
My OCD just couldn't let this slide. Spotted while reviewing Ville's patch to only flip planes when we have FBC. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-10drm/i915: Don't swap planes on 830MVille Syrjälä
Looks like 830M doesn't quite like it when you try to move a plane from one pipe to another. It seems that the plane's old pipe has to be active even if the plane is already disabled, otherwise the relevant register just won't accept new values. The following commit: commit 1f1c2e2468f937cefd6bcb645c959c7b5d9821df Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Thu Nov 28 17:30:01 2013 +0200 drm/i915: Swap primary planes on gen2 for FBC caused a regression on 830M. It will attempt to swap the planes when the driver is loaded, but at that time only pipe A might be active, so plane A gets disabled, but plane B won't get enabled since pipe B is not active when we try to move the plane over to pipe A. There's no reason to swap planes on 830M since it doesn't support FBC. Change the logic a bit to limit the plane swapping to platforms which actually support FBC. This should avoid getting a black screen on 830M. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-10drm/i915: Don't grab crtc mutexes in intel_modeset_gem_init()Ville Syrjälä
When the pipe A force quirk is applied the code will attempt to grab a crtc mutex during intel_modeset_setup_hw_state(). If we're already holding all crtc mutexes this will obviously deadlock every time. So instead of using drm_modeset_lock_all() just grab the mode_config.mutex. This is enough to avoid the unlocked mutex warnings from certain lower level functions. The regression was introduced in: commit 027476642811f8559cbe00ef6cc54db230e48a20 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Mon Dec 2 11:08:06 2013 +0200 drm/i915: Take modeset locks around intel_modeset_setup_hw_state() Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: stable@vger.kernel.org [danvet: Add cc: stable since the offending commit has that, too.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-10drm/i915: Free requests after object release when retiring requestsChris Wilson
Freeing a request triggers the destruction of the context. This needs to occur after all objects are themselves unbound from the context, and so the free request needs to occur after the object release during retire. This tidies up commit e20780439b26ba95aeb29d3e27cd8cc32bc82a4c Author: Ben Widawsky <ben@bwidawsk.net> Date: Fri Dec 6 14:11:22 2013 -0800 drm/i915: Defer request freeing by simply swapping the order of operations rather than introducing further complexity - as noted during review. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-10drm/i915: set ctx->initialized only after RCSBen Widawsky
The initialized flag is used to specify a context has been initialized and it's context is safe to load, ie. the 3d state is setup properly. With full PPGTT, we emit the address space loads during context switch and this currently marks a context as initialized. With full PPGTT patches, if a client first emits a batch to !RCS, then later, RCS, the code will mistake the context as initialized and try to reload an uninitialized context. 1. context 1 blit // context marked as initialized, but isn't 2. context 1 render // loads random state from step 2 It is really easy to hit this with a planned upcoming patch which makes default context reuse possible. NOTE: This should only effect full PPGTT branches, ie. current drm-intel-nightly. Thanks to Chris for helping me track this down. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Simplify the failure scenario in the commit message according to Chris' review a bit.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-10drm/i915/bdw: Return -ENONENT on default ctx destroyBen Widawsky
This was an accidental "ABI" change introduced during PPGTT: commit 0eea67eb26000657079b7fc41079097942339452 Author: Ben Widawsky <ben@bwidawsk.net> Date: Fri Dec 6 14:11:19 2013 -0800 drm/i915: Create a per file_priv default context The failure test application actually tests the return type. The other option is to simply change the test. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-10drm/i915: fix ppgtt dump code for DEBUG_FS=nDaniel Vetter
A regression in the topic/ppgtt branch introduce in commit 87d60b63e0371529faaed0667d457e5022964010 Author: Ben Widawsky <ben@bwidawsk.net> Date: Fri Dec 6 14:11:29 2013 -0800 drm/i915: Add PPGTT dumper The issue is that we're missing the definitions for the seq_file functions and hence compilation fails. v2: Just include the right header instead of splattering #ifdefs all over the place (Chris). Cc: Chris Wilson <chris@chris-wilson.co.uk> Reported-by: kbuild test robot <fengguang.wu@intel.com> Reported-by: Antti Koskipaa <antti.koskipaa@linux.intel.com> Cc: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-09drm/msm: add a330/apq8x74Rob Clark
Add support for adreno 330. Not too much different, just a few differences in initial configuration plus setting OCMEM base. Userspace support is already in upstream mesa. Note that the existing DT code is simply using the bindings from downstream android kernel, to simplify porting of this driver to existing devices. These do not constitute any committed/stable DT ABI. The addition of proper DT bindings will be a subsequent patch, at which point (as best as possible) I will try to support either upstream bindings or what is found in downstream android kernel, so that existing device DT files can be used. Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-01-09drm/msm: add mdp5/apq8x74Rob Clark
Add support for the new MDP5 display controller block. The mapping between parts of the display controller and KMS is: plane -> PIPE{RGBn,VIGn} \ crtc -> LM (layer mixer) |-> MDP "device" encoder -> INTF / connector -> HDMI/DSI/eDP/etc --> other device(s) Unlike MDP4, it appears we can get by with a single encoder, rather than needing a different implementation for DTV, DSI, etc. (Ie. the register interface is same, just different bases.) Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are routed through MDP. And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from which blocks need to be allocated to the active pipes based on fetch stride. Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-01-09drm/msm: add hdmi support for apq8x74/mdp5Rob Clark
The HDMI block is basically the same between older SoC's with mdp4 display controller, and newer ones with mdp5. So mostly this consists of better abstracting out the different sets of regulators, clks, etc. In particular, for regulators and clks we can split it up by what is needed for hot plug detect to work, and what is needed to light up the display. Also, 8x74 has a new phy.. a very simple one, but split out into a different mmio space. And with mdp5, the irq is shared with mdp, so we don't directly register our own irq handler. Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-01-09drm/msm: move irq utils to mdp_kmsRob Clark
We'll want basically the same thing for mdp5, so refactor it out so it can be shared. Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-01-09drm/msm: split out msm_kms.hRob Clark
Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-01-09drm/msm: mdp4_format -> mdp_formatRob Clark
This can be shared between mdp4 and mdp5. Both use the same set of parameters to describe the format to the hw. Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-01-09drm/msm: resync generated headersRob Clark
resync to latest envytools db, add mdp5 registers Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-01-09drm/msm: move mdp4 -> mdp/mdp4Rob Clark
There are some little bits and pieces that mdp4 and mdp5 can share, so move things around so that we can have both in a common parent directory. Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-01-09drm/msm: add support for msm8060ab/bstemRob Clark
This adds the necessary configuration for the APQ8060A SoC (dual-core krait + a320 gpu) as found on the bstem board. Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-01-09drm/msm: add support for non-IOMMU systemsRob Clark
Add a VRAM carveout that is used for systems which do not have an IOMMU. The VRAM carveout uses CMA. The arch code must setup a CMA pool for the device (preferrably in highmem.. a 256m-512m VRAM pool in lowmem is not cool). The user can configure the VRAM pool size using msm.vram module param. Technically, the abstraction of IOMMU behind msm_mmu is not strictly needed, but it simplifies the GEM code a bit, and will be useful later when I add support for a2xx devices with GPUMMU, so I decided to keep this part. It appears to be possible to configure the GPU to restrict access to addresses within the VRAM pool, but this is not done yet. So for now the GPU will refuse to load if there is no sort of mmu. Once address based limits are supported and tested to confirm that we aren't giving the GPU access to arbitrary memory, this restriction can be lifted Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-01-09drm/msm: fix bus scalingRob Clark
This got a bit broken with original patches when re-arranging things to move dependencies on mach-msm inside #ifndef OF. Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-01-09drm/msm: add missing MODULE_FIRMWARE()sRob Clark
Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-01-09drm/msm: COMPILE_TEST supportRob Clark
With a simple stub, we can get COMPILE_TEST support. Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-01-09drm/omap: Enable DT support for DMMArchit Taneja
Enable use of DT for DMM/Tiler. Originally worked on by Andy Gross <andygro@gmail.com> Cc: Andy Gross <andygro@gmail.com> Cc: DRI Development <dri-devel@lists.freedesktop.org> Signed-off-by: Archit Taneja <archit@ti.com> [tomi.valkeinen@ti.com: use of_match_ptr()] Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2014-01-09drm/omap: fix: change dev_unload orderArchit Taneja
The current dev_unload order uninits the irqs too early. In the current sequence, it's possible that a crtc queues work(apply_worker) to display a buffer, which registers to omap_crtc_apply_irq to notfiy the completion of the configuration we applied. Calling drm_vblank_cleanup and omap_drm_irq_uninstall here causes the crtc's apply handler to never get called, which results in an incorrect state of the apply_irq.registered parameter. This condition occurs where there is no mode set via omapdrm, and dev_lastclose tries to set a default fb mode via drm_fb_helper_restore_fbdev_mode. The apply work scheduled by restore_fbdev_mode is very close in time to the disabling of the irq handler, and hence leads to a race condition. We move the irq cleanup at the end of the unload sequence to prevent this. Also, the call to flush_workqueue is removed since it's called internally by destroy_workqueue. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2014-01-09drm/omap: fix: disable encoder before destroying itArchit Taneja
Currently, an encoder is disabled only when an apply work is queued for the corresponding crtc. This works fine for the paths where userspace explicitly disables crtc, this results in disabling the omapdss device in the crtc's pre_apply function. However, when the omapdrm module is removed, there is no work queued to ensure that the encoder is disabled. This can result in an enabled omapdss device when removing omapdrm. omapdss is left in an inconsistent state, and that prevents us from using that omapdss device being used again. Disable enabled encoders in omap_encoder_destroy, we could consider a better place for doing this later. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2014-01-09drm/omap: fix: disconnect devices when omapdrm module is removedArchit Taneja
At omapdrm probe, we install manager ops and connect omapdss devices. This needs to be undone when omapdrm module is removed so that omapdss is in a clean state. This ensures that we can re-insert omapdrm module, or some other module which uses omapdss(like omapfb/omap_vout). Currently, omapdrm's remove neither uninstalls manager ops, or disconnects omapdss devices. We make sure that this is done in pdev_remove. omapdrm establishes connections for omap_dss_device devices when probed. It should also be responsible to disconnect the devices. Keeping the devices connected can prevent the panel driver modules from unloading, it also causes issues when we try to remove or re-insert omapdrm module. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>