This is final pull request for Exynos next and includes device tree
support for fimc device, one revert, some code cleanups and fixup.
The revert replaces wrong one[1] with correct one[2].
This was my mistake and sorry for this.
* 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos:
drm/exynos: Don't blend mixer layer 0
drm/exynos: Remove unnecessary braces in exynos_hdmi.c
drm/exynos: Select VIDEOMODE_HELPERS for FIMD
drm/exynos: do not use generic flags to dumb
drm/exynos: added ipp device registration to drm driver
exynos/drm: hdmi: cleanup for hdmi common device registration
drm/exynos: fix wrong return check for platform_device_register_simple
drm/exynos: add device tree support for fimc ipp driver
drm/exynos: rework fimc clocks handling
drm/exynos: remove redundant devm_kfree()
drm/exynos: enable FIMD clocks
Revert "drm/exynos: prepare FIMD clocks"
These two variables are set again immediately in 'mgag200_modeset_init'
Signed-off-by: Christopher Harvey <charvey@matrox.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This does duplicate the logic in intel_crtc_mode_get a bit, but the
issue is that we also should handle interlace modes and other insanity
correctly.
Hence I've opted for a sligthly more elaborate route where we first
read out the crtc timings for the adjusted mode, and then optionally
(not sure if we really need it) compute the modeline from that.
v2: Also read out the pipe source dimensions into the requested mode.
v3: Rebase on top of the moved cpu_transcoder.
v4: Simplify CHECK_FLAGS logic as suggested by Chris Wilson. Also
properly #undef that macro again.
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> (v3)
[danvet: Use the existing mask for interlaced bits, spotted by Mika.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We want to use the fdi m/n values to easily compute the adjusted mode
dotclock on pch ports. Hence make sure the values stored in the pipe
config are always reliable.
v2: Fixup FDI TU readout.
v3: Rebase on top of moved cpu_transcoder.
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This code will get _really_ repetive, and we'll end up with tons more
of this kind. So extract the common patterns.
This should also help when we add a lazy pipe_config compare mode for
fastboot.
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So on a bunch of setups we only have 2 fdi lanes available, e.g. hsw
VGA or 3 pipes on ivb. And seemingly a lot of modes don't quite fit
into this, among them the default 1080p mode.
The solution is to dither down the pipe a bit so that everything fits,
which this patch implements.
But ports compute their state under the assumption that the bpp they
pick will be the one selected, e.g. the display port bw computations
won't work otherwise. Now we could adjust our code to again up-dither
to the computed DP link parameters, but that's pointless.
So instead when the pipe needs to adjust parameters we need to retry
the pipe_config computation at the encoder stage. Furthermore we need
to inform encoders that they should not increase bandwidth
requirements if possible. This is required for the hdmi code, which
prefers the pipe to up-dither to either of the two possible hdmi bpc
values.
LVDS has a similar requirement, although that's probably only
theoretical in nature: It's unlikely that we'll ever see an 8bpc
high-res lvds panel (which is required to hit the 2 fdi lane limit).
eDP is the only thing which could increase the pipe_bpp setting again,
even when in the retry-loop. This could hit the WARN. Two reasons for
not bothering:
- On many eDP panels we'll get a black screen if the bpp settings
don't match vbt. So failing the modeset is the right thing to do.
But since that also means it's the only way to light up the panel,
it should work. So we shouldn't be able to hit this WARN.
- There are still opens around the eDP panel handling, and maybe we
need additional tricks. Before that happens it's imo no use trying
to be too clever.
Worst case we just need to kill that WARN or maybe fail the compute
config stage if the eDP connector can't get the bpp setting it wants.
And since this can only happen with an fdi link in between and so for
pch eDP panels it's rather unlikely to blow up, if ever.
v2: Rebased on top of a bikeshed from Paulo.
v3: Improve commit message around eDP handling with the stuff
things with Imre.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need to multiply the hdmi port dotclock by 1.5x since it's not
really a dotclock, but the 10/8 encoding bitclock divided by 10.
Also add correct limit checks for the dotclock and reject modes which
don't fit. HDMI 1.4 would allow more, but our hw doesn't support that
unfortunately :(
Somehow I suspect 12bpc hdmi output never really worked - we really
need an i-g-t testcase to check all the different pixel modes and
outputs.
v2: Fixup the adjusted port clock handling - we need to make sure that
the fdi link code still gets the real pixelclock.
v3: g4x/vlv don't support 12bpc hdmi output so drop the bogus comment.
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Switch dotclock limit check to <= as suggested by Ville.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This allows us to use all 4 fdi lanes on fdi B when the cpu eDP is
running on pipe C. Yay!
v2: Encapsulate test into a little helper function, as suggested by
Chris Wilson.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This nicely allows us to drop some hacks which have only been used
to work around modeset failures due to lack of fdi lanes.
v2: Implement proper checking for Haswell platforms - the fdi link to
the LPT PCH has only 2 lanes. Note that we already filter out
impossible modes in intel_crt_mode_valid. Unfortunately LPT does not
support 6bpc on the fdi rx, so we can't pull clever tricks to squeeze
in a few more modes.
v2: Rebased on top of Ben Widawsky's num_pipes reorg.
v3: Rebase on top of Ville's pipe debug output ocd rampage.
v4: Fixup rebase fail spotted by Ville.
v5: Fixup rebase fail spotted by Imre Deak. I suck.
Cc: Imre Deak <imre.deak@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Again in preparation to move the configuration checks into the
pipe_config computation stage of the modeset sequence.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that it's split up, we can easily move it around and precompute
the fdi lane configuration.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
And also move the computed m_n values into the pipe_config. This is a
prep step to move the fdi state computation completely into the
prepare phase of the modeset sequence. Which will allow us to handle
fdi link bw constraints in a better way.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2: Introduce some nice #defines for the FDI lane width fields and put
them to good use. Suggested by Ville.
v3: Fixup the mask vs. shift copy&pasta fail Imre Deak spotted, and
use the shift #define also in the mask.
Cc: Imre Deak <imre.deak@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need this for two reasons:
- Correct handling of shared fdi lanes on ivb with fastboot.
- Handling fdi link bw limits when we only have two fdi lanes by
dithering down a bit.
Just search&replace in this patch, no functional change at all.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Totally untested due to lack of screens supporting more than 8bpc. But
now we should have closed all holes in our bpp handling, so this
should be safe. The last missing piece was 10bpc support for g4x/vlv,
since we directly use the pipe bpp to feed the display link (and
anyway, only the cpt has any means to have a pipe bpp != the display
link bpp).
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The current code is rather ... ugly. The only thing it managed to pull
off is getting 6bpc on DP working on g4x. Then someone added another
custom hack for 6bpc eDP on vlv. Fix up this entire mess by properly
implementing the PIPECONF-based dither/bpc controls on g4x/vlv.
Note that compared to pch based platforms g4x/vlv don't support 12bpc
modes. g4x is already caught, extend the check for vlv.
The other fixup is to restrict the lvds-specific dithering to early
gen4 devices - g4x should use the pipeconf dither controls. Note that
on gen2/3 the dither control is in the panel fitter even.
v2: Don't enable dithering when the pipe is in 10 bpc mode. Quoting
from Bspec "PIPEACONF - Pipe A Configuration Register, bit 4":
"Programming note: Dithering should only be enabled for 8 bpc or 6
bpc."
v3: Actually drop the old ugly dither code.
v4: Explain in a short comment why g4x/vlv shouldn't dither for 30 bpp
pipes (Jesse).
v5: Also clear the dither type correctly as spotted by Ville.
v6: As Ville pointed out we need to indeed set the dithering both in
the pipeconf register (for DP outputs) and in the LVDS port register
(for LVDS ouputs). Otherwise LVDS panel will not get properly
dithered. The old patch got away with this since it forgot to clear
the LVDS dither bit ...
v7: Remove redundant BPC_MASK clearing, spotted by Ville.
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>
We've had our fair share of woes already which showed that we can't
rely on the bpc limits in the EDID for eDP panels without risking
black screens. So now we limit the depth by what the BIOS recommends
in the VBT:
commit 2f4f649a69
Author: Jani Nikula <jani.nikula@intel.com>
Date: Mon Nov 12 14:33:44 2012 +0200
drm/i915: do not ignore eDP bpc settings from vbt
But that's not enough, since at least the panel on my ASUS Zenbook
Prime here is also unhappy if the bpc is too low. Hence just take the
firmware value and dither to get what flimsy panels want.
Like before we ensure that we don't change the bpp if the firmware
doesn't provide a value, see
commit 9a30a61f35
Author: Jani Nikula <jani.nikula@intel.com>
Date: Mon Nov 12 14:33:45 2012 +0200
drm/i915: do not default to 18 bpp for eDP if missing from VBT
v2: Apparently there are some horribly broken eDP panels around which
only work if the DP link is set up as if we want to driver a 24bpp
mode, but still only work if the data is feed at 18bpp. See
commit 57c2196332
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Apr 4 17:19:37 2013 +0200
drm/i915: revert eDP bpp clamping code changes
for the gory details.
Adjust the patch accordingly and update all the relevant comments.
v3: Give up on the cargo-culting v2 attempt and just enfore the edp
bpp value if it's there. Broken panels be damned!
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Paulo Zanoni <przanoni@gmail.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Tested-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This hack is getting a bit messy, but this plugs the leak for now
until we have the cpu_transcoder properly pipe_config'ed.
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch disables blending the mixer's layer 0 onto the background
(solid color). It doesn't make sense to blend this layer by default,
and causes color distortion if the layer is used for arbitrary content.
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Silences the following checkpatch warning:
WARNING: braces {} are not necessary for any arm of this statement
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
FIMD also requires video mode helper APIs.
Without this patch we get the following build error:
drivers/gpu/drm/exynos/exynos_drm_fimd.c:895: undefined reference to
`of_get_fb_videomode'
make: *** [vmlinux] Error 1
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This patch removes the use of dumb flags from driver.
As Dave pointed out, the dumb flags are not driver specific
so this should be removed from driver.
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
This patch added exynos-drm-ipp platform device registration to the exynos drm
driver. When DT is enabled, platform devices need to be registered within the
driver code. This patch fits the requirement of both DT and Non DT based drm
drivers.
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The hdmi common device registration function does not need extern definition
and for error case and unregister case, exynos_drm_hdmi_pdev should be cleared.
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
platform_device_register_simple() never returns NULL, but IS_ERR_OR_NULL macro
is used for checking return value in exynos drm driver.
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This patch adds OF initialization support for the FIMC driver.
The binding documentation can be found at Documentation/devicetree/
bindings/media/samsung-fimc.txt.
The syscon regmap interface is used to serialize access to the
shared CAMBLK registers from within the V4L2 FIMC-IS and the DRM
FIMC drivers. The DRM driver uses this interface for setting up
the FIFO data link between FIMD and FIMC IP blocks, while the V4L2
one for setting up a data link between the camera ISP and FIMC for
camera capture. The CAMBLK registers are not accessed any more
through a statically mapped IO. Synchronized access to these
registers is required for simultaneous operation of the camera
ISP and the DRM IPP on Exynos4x12.
The driver data and driver_ids static data structures are removed
since Exynos4 is going to be a dt-only platform and there is
currently no board file in mainline that defines platform data
for the FIMC IPP, i.e. uses it.
Camera input signal polarities are not currently parsed from the
device tree.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The clocks handling is refactored and a "mux" clock handling is
added to account for changes in the clocks driver. After switching
to the common clock framework the sclk_fimc clock is now split
into two clocks: a gate and a mux clock. In order to retain the
exisiting functionality two additional consumer clocks are passed
to the driver from device tree: "mux" and "parent". Then the driver
sets "parent" clock as a parent clock of the "mux" clock. These two
additional clocks are optional, and should go away when there is a
standard way of setting up parent clocks on DT platforms.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
There is no need for explicit calls of devm_kfree(), as
the allocated memory will be freed during driver's detach.
Remove the redundant devm_kfree() calls from probe() and
remove() callbacks.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Common Clock Framework introduced the need to prepare clocks before
enabling them, otherwise clk_enable() fails. This patch adds clk_prepare_enable
and clk_disable_unprepare() calls to the driver.
This patch also removes clk_disable() from fimd_remove() as it will be done
by pm_runtime_put_sync.
Signed-off-by: Vikas Sajjan <vikas.sajjan@linaro.org>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
* acpi-hotplug:
ACPI / memhotplug: Remove info->failed bit
ACPI / memhotplug: set info->enabled for memory present at boot time
ACPI: Verify device status after eject
acpi: remove reference to ACPI_HOTPLUG_IO
ACPI: Update _OST handling for notify
ACPI: Update PNPID match handling for notify
ACPI: Update PNPID set/free interfaces
ACPI: Remove acpi_device dependency in acpi_device_set_id()
ACPI / hotplug: Make acpi_hotplug_profile_ktype static
ACPI / scan: Make memory hotplug driver use struct acpi_scan_handler
ACPI / container: Use hotplug profile user space interface
ACPI / hotplug: Introduce user space interface for hotplug profiles
ACPI / scan: Introduce acpi_scan_handler_matching()
ACPI / container: Use common hotplug code
ACPI / scan: Introduce common code for ACPI-based device hotplug
ACPI / scan: Introduce acpi_scan_match_handler()
When ppgtt is enabled, dev_priv->gtt.total has excluded the gtt space
occupied by ppgtt table in i915_gem_init_global_gtt() function. So the
calculation of first_pd_entry_in_global_pt doesn't need to subtract
I915_PPGTT_PD_ENTRIES again. Or else PPGTT directory table will be
destroyed by global gtt allocation.
This regression has been introduced in
commit a54c0c279f
Author: Ben Widawsky <ben@bwidawsk.net>
Date: Thu Jan 24 14:45:00 2013 -0800
drm/i915: remove intel_gtt structure
The breakage is pretty subtile since the old gtt_total_entries
included the pde range, whereas the new on did not.
Cc: stable@vger.kernel.org
Signed-off-by: Xiong Zhang<xiong.y.zhang@intel.com>
[danvet: Add regression citation and cc: stable. Thanks to Chris for
correcting my wrong guess about which commit broke things.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Instead of repeatedly bombarding the user with a request to reboot and
increase the stolen size with every fb refresh, just inform them the
first time only.
v2: Rearrange code so the hint to increase the amount of memory stolen
by the BIOS is only emitted if we fail to find sufficient stolen memory
for FBC.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Fixup formatting code mismatch that gcc spotted.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
"Nothing overly exciting here aside from calim's fermi/kepler vram
compression patches. The rest is misc fixes I gathered from the list.
Most of the stuff from me is fixing issues that have come up from the
work on kepler PM, as well as a commit moving all the old-school
modesetting out of the way (no code changes here). There's other
patches to go on top of that, but, it'll have to wait until I can rip
out the old PM code, it's a bit tangled."
* 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6: (38 commits)
drm/nouveau/fifo: implement channel creation event generation
drm/nouveau/core: allow non-maskable events
drm/nouveau/timer: allow alarms to be cancelled
drm/nouveau/device: tweak the device/subdev relationship a little
drm/nouveau/device: enable proper constructor/destructor
drm/nouveau/device: have engine object initialised before creation
drm/nouveau/device: convert to engine, rather than subdev
drm/nv50-/disp: use self as parent for subobjects
drm/nv50-/fifo: use parent as self for subobjects
drm/nv20-nv30/gr: use parent as self for subobjects
drm/nvc0-/gr: use self as parent for subobjects
drm/nv04-nv40/instmem: use self as parent for subobjects
drm/nv04-nv40/vm: use self as parent for subobjects
drm/nv50-/bar: use self as parent for subobjects
drm/nv04-nv40/instmem: remove parent deref hack
drm/nouveau/i2c: remove parent deref hack
drm/nouveau/core: rebase object ref/use counts after ctor/init/fini events
drm/nv50/disp: inform core when we're not creating a new context
drm/nouveau/therm: send some messages to debug level
drm/nve0/gr: add handling for a bunch of PGRAPH traps
...
