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>
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
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
...
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
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>
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>
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>
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 0ce99f749b
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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 1f1c2e2468
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>
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 0274766428
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>
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 e20780439b
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>
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>
This was an accidental "ABI" change introduced during PPGTT:
commit 0eea67eb26
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>
A regression in the topic/ppgtt branch introduce in
commit 87d60b63e0
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
With the omapdss device model changes. omapdrm is required to call dssdriver's
connect() op to register a panel. This is currently done in omap_modeset_init()
A call to connect() can fail if the omapdss panels or the encoders(HDMI/DPI)
they connect to have some resource(like regulators, I2C adapter) missing. If
this happens, the correct approach is to defer omapdrm's probe.
omapdrm currently ignores those panels which return a non zero value when
connected. This could result in omapdrm ignoring all panels on an omap board.
The right approach would be for omapdrm to request for probe deferral when a
panel's connect op returns -EPROBE_DEFER.
In order to do this, we need to call connect() much earlier during omapdrm's
probe to prevent too many things are already done by then. We now connect the
panels during pdev_probe(), before anything else is initialized, so that we
don't need to undo too many things if a defer was requested.
Now when we enter omap_modeset_init(), we have a set of panels that have been
connected. We now proceed with registering only those panels that are already
connected.
A special case has to be considered when no panels are available to connect when
omapdrm probes. In this case too, we defer probe and expect that a panel will be
available to connect the next time.
Checking whether the panel has a driver or whether it has get_timing/read_edid
ops in omap_modeset_init() are redundant with the new display model. These can
be removed since a dssdev device will always have a driver associated with it,
and all dssdev drivers have a get_timings op.
This will mainly fix cases when omapdrm is built-in the kernel, since that's
generally where resources like regulators or I2C are unavailable because of
probe order dependencies.
In particular this fixes boot with omapdrm built-in on an omap4 panda ES board.
The regulators used by HDMI(provided by I2C based TWL regulators) aren't
initialized because I2C isn't initialized, I2C isn't initialized as it's pins
are not configured because pinctrl is yet to probe.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
omapdrm (un)registers irqs inside an irq handler. The problem is that
the (un)register function uses dispc_runtime_get/put() to enable the
clocks, and those functions are not irq safe by default.
This was kind of fixed in 48664b21ae
(OMAPDSS: DISPC: set irq_safe for runtime PM), which makes dispc's
runtime calls irq-safe.
However, using pm_runtime_irq_safe in dispc makes the parent of dispc,
dss, always enabled, effectively preventing PM for the whole DSS module.
This patch makes omapdrm behave better by adding new irq (un)register
functions that do not use dispc_runtime_get/put, and using those
functions in interrupt context. Thus we can make dispc again
non-irq-safe, allowing proper PM.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Rob Clark <robdclark@gmail.com>
pci config reset is a low level reset that resets
the entire chip from the bus interface. It can
be more reliable if soft reset fails.
v2: fix rebase
v3: hide behind module parameter
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
pci config reset is a low level reset that resets
the entire chip from the bus interface. It can
be more reliable if soft reset fails.
v2: hide behind module parameter
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
pci config reset is a low level reset that resets
the entire chip from the bus interface. It can
be more reliable if soft reset fails.
v2: put behind module parameter
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
pci config reset is a low level reset that resets
the entire chip from the bus interface. It can
be more reliable if soft reset fails.
There's not much information still available on
r6xx, so r6xx is based on guess-work.
v2: put behind module parameter
v3: add IGP check
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
