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>
regressions, typically boot failures or other unsafe system
configuration that causes badness.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQIcBAABAgAGBQJSz5HsAAoJEDqPOy9afJhJYCcP/RgFkHD39l28dCUlxAZK1S1b
loyQn9OhpTDkMqcRNiv71dMm7y0Z28Qvf3CHPaZmkddstd351Agdz4mPTIOpbutQ
/THb0mAU7kufYkFUXq8+fDOcgkERMsQysIWAYV/vlCBDMPd+1j6z15E3A9jNC0Ap
q1o8KgmAbxDcsqltZmdlT+He7XsJiRSuyS+YFfNvtSm6MJ1qtuqiAumf9/DSBgFg
0aj+ADWS2mWiw50LOOaVVKKjKYKaO/DPq2gYz2Tz8C49rQfstMnOmjMWqIPGRpiZ
YPCDzAiutI8H+SXBaetkgIJn/MiVS2rnNPXfMHmCgWoO3Xi0PCq9+Vg7cTuvNSRl
HeMCnEsBcU9N2DfaZkom2OVU6XQXUkOM/jLIuTBGf7IKdLALSXy+w22NknRd0WKv
VKdie6GBmV5KwAeytDETdSxSQNuxIxLUfILd5+Y5kl1cFDUCsSxBDGD+01EbqS6B
Q/FkoS3EMvQvvFeGopCEje8fv87JvTrviJ7Mkj8xpJZGCWW7FTpsgTS0mP2ifDTX
RpjTGhcho0LbD4Hu3E58Kykc7LBO5LH5vnPHpMPj7KQxC/4gFVwdWHWgRFKI2pEr
B6zSl0W5j7cSR0mADH4MWuqQh8T2zbKgP4pcNJ878V3hGhBktcxure1VGcIr/yj9
U+FKg/lBoKUvVBDUnajQ
=iLBN
-----END PGP SIGNATURE-----
Merge tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mike.turquette/linux
Pull clock fixes from Mike Turquette:
"Late fixes for clock drivers. All of these fixes are for user-visible
regressions, typically boot failures or other unsafe system
configuration that causes badness"
* tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mike.turquette/linux:
clk: clk-divider: fix divisor > 255 bug
clk: exynos: File scope reg_save array should depend on PM_SLEEP
clk: samsung: exynos5250: Add CLK_IGNORE_UNUSED flag for the sysreg clock
ARM: dts: exynos5250: Fix MDMA0 clock number
clk: samsung: exynos5250: Add MDMA0 clocks
clk: samsung: exynos5250: Fix ACP gate register offset
clk: exynos5250: fix sysmmu_mfc{l,r} gate clocks
clk: samsung: exynos4: Correct SRC_MFC register
Hopefully the last set of arm-soc fixes for 3.13, or at least only a
few stray patches after this.
There are a few fixes for Renesas platforms to fixup DMA masks (this
started causing errors once the DMA API added checks for valid masks in
3.13). Two more dealing with resources for MMC and PWM setup.
There's also a few TI/OMAP/DRA fixes for smaller stuff and a fix for
compilation failures on a PXA platform.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJSzmLqAAoJEIwa5zzehBx3AIMP/i/Br36+IPTft/v6EN1dON3p
RXLTSh5bAO7uS5lEd7osRKvFGAM7kk7V1xwpixJaweiDBhJYgCC08fLQsmXr2ktL
uQZsWNqPzvNOUib8qmJSeYjuu4Otr+4KOS1FNhPmLJppnnZCnF0SsCaOTT/UZiV1
dgwB3JwRZvSE+twqbeL6LDHdh3qF3Kp85IeeFMZjvRAlAtwwwK4zBc0mbAHUUYs9
+h18T1iaJ+/j/5MQDVED6sJOWH4+cNh/DIvvWKGKe1z56Ji6wuMmrAFAhSiyeVNA
sxRXgtaqeegXu/LQkxTeFI4PYOzU/LGXPuO6lDqKJ8h5/YfHoxdiAnkxA1WFrq6z
sB4mc2A6WPKu13HbjqZOeVkFSZTL6lZDlLEP4f6mTDoHW5kJ6X7WabCBJswLpi9c
d5PvAu+jYF20OXks2ctnsITHk5xcYXMK1VSNiv6z7Dff63x7Lh078bkns5E1YLqs
vhkmZRGBWSsofFvyobNFKOsVvIW4Z6CGOiwW8RkQr6nlYzzoytnMU8E4yOUeXFRJ
c4veMRPn4pgNkbRXdxvUXmRado6hs53YFcRWYXX3fuFTC5x8KTjR2hxLm6J+Ca/m
2d9EFbBZQB1oZoHT6n/ghZCRIBjgVkbaaxNrdoMozF/ryOOj9ujj0xTB5dRoiX21
0Fhq/UVUxj0i5XWLgxQA
=edy8
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC fixes from Olof Johansson:
"A few fixes for Renesas platforms to fixup DMA masks (this started
causing errors once the DMA API added checks for valid masks in 3.13)"
* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
ARM: shmobile: mackerel: Fix coherent DMA mask
ARM: shmobile: kzm9g: Fix coherent DMA mask
ARM: shmobile: armadillo: Fix coherent DMA mask
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>
In the past the IFA_PERMANENT flag indicated, that the valid and preferred
lifetime where ignored. Since change fad8da3e08 ("ipv6 addrconf: fix
preferred lifetime state-changing behavior while valid_lft is infinity")
we honour at least the preferred lifetime on those addresses. As such
the valid lifetime gets recalculated and updated to 0.
If loopback address is added manually this problem does not occur.
Also if NetworkManager manages IPv6, those addresses will get added via
inet6_rtm_newaddr and thus will have a correct lifetime, too.
Reported-by: François-Xavier Le Bail <fx.lebail@yahoo.com>
Reported-by: Damien Wyart <damien.wyart@gmail.com>
Fixes: fad8da3e08 ("ipv6 addrconf: fix preferred lifetime state-changing behavior while valid_lft is infinity")
Cc: Yasushi Asano <yasushi.asano@jp.fujitsu.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Starting with commit 80c33dd "net: add might_sleep() call to napi_disable"
bnx2x fails the might_sleep tests causing a stack trace to appear whenever
the driver is unloaded, as local_bh_disable() is being called before
napi_disable().
This changes the locking schematics related to CONFIG_NET_RX_BUSY_POLL,
preventing the need for calling local_bh_disable() and thus eliminating
the issue.
Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Close avn_cstates array with correct marker to avoid overflow
in function intel_idle_cpu_init().
[rjw: The problem was introduced when commit 22e580d07f was merged
on top of eba682a5ae (intel_idle: shrink states tables).]
Fixes: 22e580d07f (intel_idle: Fixed C6 state on Avoton/Rangeley processors)
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Function tracing callbacks expect to have the ftrace_ops that registered it
passed to them, not the address of the variable that holds the ftrace_ops
that registered it.
Use a mov instead of a lea to store the ftrace_ops into the parameter
of the function tracing callback.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Reviewed-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Link: http://lkml.kernel.org/r/20131113152004.459787f9@gandalf.local.home
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Cc: <stable@vger.kernel.org> # v3.8+
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>
Pull parisc fix from Helge Deller:
"This patch fixes the kmap/kunmap implementation on parisc and finally
makes AIO work on parisc"
* 'parisc-3.13' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
parisc: Ensure full cache coherency for kmap/kunmap
Pull libata fixes from Tejun Heo:
"Late fixes for libata. Nothing too interesting. Adding missing PM
callbacks to satat_sis and an additional PCI ID for ahci"
* 'for-3.13-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata:
sata_sis: missing PM support
ahci: add PCI ID for Marvell 88SE9170 SATA controller
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>
This is used to hard reset the asic. If a soft
reset is not able to reset things, a hard reset
can be used.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Enabling this parameter enables pci config reset,
aka hard reset, which is a bus level chip reset.
In some cases this works more reliably than a soft
reset. Disabled by default.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Helge Deller noted a few weeks ago problems with the AIO support on
parisc. This change is the result of numerous iterations on how best to
deal with this problem.
The solution adopted here is to provide full cache coherency in a
uniform manner on all parisc systems. This involves calling
flush_dcache_page() on kmap operations and flush_kernel_dcache_page() on
kunmap operations. As a result, the copy_user_page() and
clear_user_page() functions can be removed and the overall code is
simpler.
The change ensures that both userspace and kernel aliases to a mapped
page are invalidated and flushed. This is necessary for the correct
operation of PA8800 and PA8900 based systems which do not support
inequivalent aliases.
With this change, I have observed no cache related issues on c8000 and
rp3440. It is now possible for example to do kernel builds with "-j64"
on four way systems.
On systems using XFS file systems, the patch recently posted by Mikulas
Patocka to "fix crash using XFS on loopback" is needed to avoid a hang
caused by an uninitialized lock passed to flush_dcache_page() in the
page struct.
Signed-off-by: John David Anglin <dave.anglin@bell.net>
Cc: stable@vger.kernel.org # v3.9+
Signed-off-by: Helge Deller <deller@gmx.de>
