drm/exynos: hdmi: using drm_display_mode timings for exynos4

Exynos5 is already using drm_display_mode for timings parameters. Exynos4
is also modifed to use the same. List of supported resolutions and
corresponding timings are removed which helps is enabling some extra
resolutions. It also cleans some of the duplicate code.

Exynos4 and Exynos5 Mixers, work fine for the same range of resolutions. Hence
same condition (to find the supported mode) is applied to both.

More exynos4 phy configs can be added later to extend the mode supprot.

Signed-off-by: Rahul Sharma <rahul.sharma@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>

drm/qxl: fix smatch warnings

drivers/gpu/drm/qxl/qxl_display.c:99 qxl_alloc_client_monitors_config() error: dereferencing freed memory 'qdev->client_monitors_config'
drivers/gpu/drm/qxl/qxl_object.c:66 qxl_ttm_placement_from_domain() warn: bitwise AND condition is false here
drivers/gpu/drm/qxl/qxl_ioctl.c:353 qxl_clientcap_ioctl() warn: buffer overflow 'qdev->rom->client_capabilities' 58 <= 58

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/qxl: make lots of things static.

/usr/lib/gcc/x86_64-linux-gnu/4.7/include/stddef.h:414:9: sparse: preprocessor token offsetof redefined
include/linux/stddef.h:17:9: this was the original definition
>> drivers/gpu/drm/qxl/qxl_drv.c:49:5: sparse: symbol 'qxl_modeset' was not declared. Should it be static?

Reported-by: kbuild test robot.
Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge tag 'omapdss-for-3.10' of git://gitorious.org/linux-omap-dss2/linux into drm-next

Omapdss patches for 3.10 merge window

The biggest changes are:

* DSI video mode: automatic clock and timing calculation
* Lots of platform data related panel driver cleanups, to prepare for DT

* tag 'omapdss-for-3.10' of git://gitorious.org/linux-omap-dss2/linux: (69 commits)
  drm/omap: add statics to a few structs
  drm/omap: Fix and improve crtc and overlay manager correlation
  drm/omap: Take a fb reference in omap_plane_update()
  drm/omap: Make fixed resolution panels work
  drm/omap: fix modeset_init if a panel doesn't satisfy omapdrm requirements
  OMAPDSS: DPI: widen the pck search when using dss fck
  OMAPDSS: fix dss_fck clock rate rounding
  omapdss: use devm_clk_get()
  OMAPDSS: nec-nl8048 panel: Use dev_pm_ops
  OMAPDSS: DISPC: Revert to older DISPC Smart Standby mechanism for OMAP5
  OMAPDSS: DISPC: Configure doublestride for NV12 when using 2D Tiler buffers
  omapdss: Features: Fix some parameter ranges
  omapdss: DISPC: add max pixel clock limits for LCD and TV managers
  OMAPDSS: DSI: Use devm_clk_get()
  drivers: video: omap2: dss: Use PTR_RET function
  OMAPDSS: VENC: remove platform_enable/disable calls
  OMAPDSS: n8x0 panel: remove use of platform_enable/disable
  OMAPDSS: n8x0 panel: handle gpio data in panel driver
  OMAPDSS: picodlp panel: remove platform_enable/disable callbacks
  OMAPDSS: picodlp panel: handle gpio data in panel driver
  ...

drm: Perform ioctl command validation on the stored kernel values

Userspace is free to pass in any command bits it feels like through the
ioctl cmd, and for example trinity likes to fuzz those bits to create
conflicting commands. So instead of relying upon userspace to pass along
the correct IN/OUT flags for the ioctl, use the flags as expected by the
kernel.

This does have a side-effect that NULL pointers can not be substituted
by userspace in place of a struct. This feature was not being used by
any driver, but instead exposed all of the command handlers to a user
triggerable OOPS.

Reported-by: Tommi Rantala <tt.rantala@gmail.com>
Link: http://lkml.kernel.org/r/CA+ydwtpuBvbwxbt-tdgPUvj1EU7itmCHo_2B3w13HkD5+jWKow@mail.gmail.com
Signed-off-by: Tommi Rantala <tt.rantala@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm.h: Fix DRM compilation with bare-metal toolchain.

An ifdef in drm.h expects to be compiled with full-fledged Linux
toolchain, but it's common to compile kernel with just bare-metal
toolchain which doesn't define __linux__. So, also add __KERNEL__
check.

[nm@ti.com: port forward to 3.9-rc6 and post to dri devel for feedback as RFC]
Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: use vma_pages() to replace (vm_end - vm_start) >> PAGE_SHIFT

(*->vm_end - *->vm_start) >> PAGE_SHIFT operation is implemented
as a inline funcion vma_pages() in linux/mm.h, so using it.

Signed-off-by: Libin <huawei.libin@huawei.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: Destroy property blobs at mode config cleanup time

Property blob objects need to be destroyed when cleaning up to avoid
memory leaks. Go through the list of all blobs in the
drm_mode_config_cleanup() function and destroy them.

The drm_mode_config_cleanup() function needs to be moved after the
drm_property_destroy_blob() declaration. Move drm_mode_config_init() as
well to keep the functions together.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge tag 'drm-intel-next-2013-04-06' of git://people.freedesktop.org/~danvet/drm-intel into drm-next

Daniel writes:
Since I expect Linus to open the merge window in about a week I guess this
is the last i915 feature pull for 3.10. Highlights:
Updated testing tree for -next. Highlights:
- Corner case fixes discovered with static analyzers (Damien).
- More fixes to combat unclaimed register errors on Haswell (Paulo).
- Some small fixes to the gpu turbo code (Rodrigo+Ben), Ben has more
  fixes for overclocking support pending.
- More prep work for fastboot from Chris.
- VT-switchless suspend/resume from Jesse.
- The prep work of Egbert Eich's hpd irq storm handling. Hopefully we can
  squeeze in the actual storm handling code for 3.10 ...
- More convenience helpers for Imre's sg iterator. Core parts acked by
  Andrew Morton.
- A bit of backlight code cleanup from Jani.
- Fixed ilk gpu reset (Jesse).
- Reduced color range handling fixes for VLV (Ville).

The big item here is though the introduction of pipe_config to properly
pre-compute the desired modeset state before touching the hw. Together
with some very basic support to read out the current config from the hw
and compare the state with the sw tracking. This is all prep work for more
reliable fastboot, atomic modesets and other cool features. Stuff
converted to the new world includes:
- Most simple pipe attributes (reduce color range, pixel multiplier).
- Pipe bpp/dither handling.
- Some convenience flags like ->has_pch_encoder to simplify the code flow.
- (Almost) DP clock handling, had to be reverted since part of a prep
  patch was lost in rebasing ...
Expect a lot of patches for this throughout 3.11, there's tons of work
till we have all state properly tracked for fastbooting to woExpect a lot
of patches for this throughout 3.11, there's tons of work till we have all
state properly tracked for fastbooting to work.

For 3.10 I have a bunch of fixes queued up and I plan to send them all out
at the end of this week. I need to shuffle patches in my -next queue a bit
so that we don't but feature-y stuff in there, too. The main thing I'd
like to sneak in is Egbert's hpd irq storm handling, which should be
pretty low-risk since all the infrastructure work has landed already. I
also have the oops fix pending, but that only mustered review before the
w/e and giving how hairy that part of our modeset code is, I want to give
it some more testing before forwarding.

Note: annarchy.fd.o seems to run out of disk space, so couldn't push the
usual for-airlied branch. Tag should work though.

Note 2: I've had to do a backmerge since conflicts grew too ugly, but the
upstream -rc I've backmerged is already in your drm-next.

* tag 'drm-intel-next-2013-04-06' of git://people.freedesktop.org/~danvet/drm-intel: (75 commits)
  drm/i915: info level for simulated gpu hang dmesg notice
  drm/i915: revert eDP bpp clamping code changes
  Revert "drm/i915: fix DP get_hw_state return value"
  drm/i915: Don't use the HDMI port color range bit on Valleyview
  drm/i915: Set PIPECONF color range bit on Valleyview
  drm/i915: extract i9xx_set_pipeconf
  drm/i915: Add no-lvds quirk for Fujitsu Esprimo Q900
  drm/i915: create pipe_config->dpll for clock state
  drm/i915: hw readout support for ->has_pch_encoders
  drm/i915: add hw state readout/checking for pipe_config
  drm/i915: rip out superflous is_dp&is_cpu_edp tracking
  drm/i915: remove leaky eDP functions
  drm/i915: track dp target_clock in pipe_config
  drm/i915: move dp_m_n computation to dp_encoder->compute_config
  drm/i915: clear up the fdi/dp set_m_n confusion
  drm/i915: Fix sdvo connector get_hw_state function
  drm/i915: drop DPFLIPSTAT enables on VLV v3
  drm/i915: add Punit read/write routines for VLV v2
  drm/i915: panel power sequencing for VLV eDP v2
  drm/i915/dp: fix up VLV DP handling v2
  ...

OMAPDSS: Merge omapdss topic branches

drm: cleanup: use drm_framebuffer_reference instead of a kref_get

drm_framebuffer_lookup() does a kref_get() for the framebuffer if it finds one
corresponding to the fb id passed to it. Use drm_framebuffer_reference() instead
for clarity since it's the function used in other places to take a reference.

Signed-off-by: Archit Taneja <archit@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/mgag200: Convert to managed device resources where possible

Signed-off-by: Christopher Harvey <charvey@matrox.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: Misc comment cleanup

Signed-off-by: Christopher Harvey <charvey@matrox.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: Add 1600x1200 (UXGA) screen resolution to the built-in EDIDs

The 1600x1200 (UXGA) screen resolution was lacking in the set of
built-in selectable EDID screen resolutions that can be used to
repair misbehaving monitor firmware.

This patch adds the related data set and expands the documentation.

Signed-off-by: Carsten Emde <C.Emde@osadl.org>
Acked-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>

video: hdmi: Relicense under MIT

In order to make it easier to port the code to other operating systems
(like the BSDs), relicense the HDMI helpers under the more permissive
MIT license.

Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: add new QXL driver. (v1.4)

QXL is a paravirtual graphics device used by the Spice virtual desktop
interface.

The drivers uses GEM and TTM to manage memory, the qxl hw fencing however
is quite different than normal TTM expects, we have to keep track of a number
of non-linear fence ids per bo that we need to have released by the hardware.

The releases are freed from a workqueue that wakes up and processes the
release ring.

releases are suballocated from a BO, there are 3 release categories, drawables,
surfaces and cursor cmds. The hw also has 3 rings for commands, cursor and release handling.

The hardware also have a surface id tracking mechnaism and the driver encapsulates it completely inside the kernel, userspace never sees the actual hw surface
ids.

This requires a newer version of the QXL userspace driver, so shouldn't be
enabled until that has been placed into your distro of choice.

Authors: Dave Airlie, Alon Levy

v1.1: fixup some issues in the ioctl interface with padding
v1.2: add module device table
v1.3: fix nomodeset, fbcon leak, dumb bo create, release ring irq,
      don't try flush release ring (broken hw), fix -modesetting.
v1.4: fbcon cpu usage reduction + suitable accel flags.

Signed-off-by: Alon Levy <alevy@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

ttm: export functions to allow qxl do its own iomapping

qxl wants to use io mapping like i915 gem does, for now
just export the symbols so the driver can implement atomic
page maps using io mapping.

Signed-off-by: Dave Airlie <airlied@redhat.com>

include/drm/drm_fb_helper.h: remove left over function declaration

Signed-off-by: Alon Levy <alevy@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/omap: add statics to a few structs

Some static structs are not marked as static. Add it.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

drm/omap: Fix and improve crtc and overlay manager correlation

The omapdrm driver currently takes a config/module arg to figure out the number
of crtcs it needs to create. We could create as many crtcs as there are overlay
managers in the DSS hardware, but we don't do that because each crtc eats up
one DSS overlay, and that reduces the number of planes we can attach to a single
crtc.

Since the number of crtcs may be lesser than the number of hardware overlay
managers, we need to figure out which overlay managers to use for our crtcs. The
current approach is to use pipe2chan(), which returns a higher numbered manager
for the crtc.

The problem with this approach is that it assumes that the overlay managers we
choose will connect to the encoders the platform's panels are going to use,
this isn't true, an overlay manager connects only to a few outputs/encoders, and
choosing any overlay manager for our crtc might lead to a situation where the
encoder cannot connect to any of the crtcs we have chosen. For example, an
omap5-panda board has just one hdmi output. If num_crtc is set to 1, with the
current approach, pipe2chan will pick up the LCD2 overlay manager, which cannot
connect to the hdmi encoder at all. The only manager that could have connected
to hdmi was the TV overlay manager.

Therefore, there is a need to choose our overlay managers keeping in mind the
panels we have on that platform. The new approach iterates through all the
available panels, creates encoders and connectors for them, and then tries to
get a suitable overlay manager to create a crtc which can connect to the
encoders.

We use the dispc_channel field in omap_dss_output to retrieve the desired
overlay manager's channel number, we then check whether the manager had already
been assigned to a crtc or not. If it was already assigned to a crtc, we assume
that out of all the encoders which intend use this crtc, only one will run at a
time. If the overlay manager wan't assigned to a crtc till then, we create a
new crtc and link it with the overlay manager.

This approach just looks for the best dispc_channel for each encoder. On DSS HW,
some encoders can connect to multiple overlay managers. Since we don't try
looking for alternate overlay managers, there is a greater possibility that 2
or more encoders end up asking for the same crtc, causing only one encoder to
run at a time.

Also, this approach isn't the most optimal one, it can do either good or bad
depending on the sequence in which the panels/outputs are parsed. The optimal
way would be some sort of back tracking approach, where we improve the set of
managers we use as we iterate through the list of panels/encoders. That's
something left for later.

Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

drm/omap: Take a fb reference in omap_plane_update()

When userspace calls SET_PLANE ioctl, drm core takes a reference of the fb and
passes control to the update_plane op defined by the drm driver.

In omapdrm, we have a worker thread which queues framebuffers objects received
from update_plane and displays them at the appropriate time.

It is possible that the framebuffer is destoryed by userspace between the time
of calling the ioctl and apply-worker being scheduled. If this happens, the
apply-worker holds a pointer to a framebuffer which is already destroyed.

Take an extra refernece/unreference of the fb in omap_plane_update() to prevent
this from happening. A reference is taken of the fb passed to update_plane(),
the previous framebuffer (held by plane->fb) is unreferenced. This will prevent
drm from destroying the framebuffer till the time it's unreferenced by the
apply-worker.

This is in addition to the exisitng reference/unreference in update_pin(),
which is taken for the scanout of the plane's current framebuffer, and an
unreference the previous framebuffer.

Signed-off-by: Archit Taneja <archit@ti.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

drm/omap: Make fixed resolution panels work

The omapdrm driver requires omapdss panel drivers to expose ops like detect,
set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI
and SDI drivers. At some places, there are no checks to see if the panel driver
has these ops or not, and that leads to a crash.

The following things are done to make fixed panels work:

- The omap_connector's detect function is modified such that it considers panel
  types which are generally fixed panels as always connected(provided the panel
  driver doesn't have a detect op). Hence, the connector corresponding to these
  panels is always in a 'connected' state.

- If a panel driver doesn't have a check_timings op, assume that it supports the
  mode passed to omap_connector_mode_valid(the 'mode_valid' drm helper function)

- The function omap_encoder_update shouldn't really do anything for fixed
  resolution panels, make sure that it calls set_timings only if the panel
  driver has one.

Signed-off-by: Archit Taneja <archit@ti.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

drm/omap: fix modeset_init if a panel doesn't satisfy omapdrm requirements

modeset_init iterates through all the registered omapdss devices and has some
initial checks to see if the panel has a driver and the required driver ops for
it to be usable by omapdrm.

The function bails out from modeset_init if a panel doesn't meet the
requirements, and stops the registration of the future panels and encoders which
come after it, that isn't the correct thing to do, we should go through the rest
of the panels. Replace the 'return's with 'continue's.

Signed-off-by: Archit Taneja <archit@ti.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

OMAPDSS: DPI: widen the pck search when using dss fck

When not using DSI PLL to generate the pixel clock, but DSS FCK, the
possible pixel clock rates are rather limited. DSS FCK is currently used
on OMAP2 and OMAP3.

When using Beagleboard with a monitor that supports high resolutions,
the clock rates do not match (at least for me) for the monitor's pixel
clocks within the current threshold in the code, which is +/- 1MHz.

This patch widens the search up to +/- 15MHz. The search is done in
steps, i.e. it first tries to find a rather exact clock, than a bit less
exact, etc. so this should not change the cases where a clock was
already found.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

OMAPDSS: fix dss_fck clock rate rounding

DSS func clock is calculated with prate / div * m. However, the current
omapdss code calculates it with prate * m / div, which yields a slightly
different result when there's a remainder. For example, 432000000 / 14 *
2 = 61714284, but 432000000 * 2 / 14 = 61714285.

In addition to that, the clock framework wants the clock rate given with
clk_set_rate to be higher than the actual (truncated) end result. So, if
prate is 432000000, and div is 14, the real result is 30857142.8571...
We need to call clk_set_rate with 30857143, which gives us a clock of
30857142. That's why we need to use DIV_ROUND_UP() when calling
clk_set_rate.

This patch fixes the clock calculation.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

omapdss: use devm_clk_get()

Use devm_clk_get() instead of clk_get() for dss, and for outputs hdmi
and venc. This reduces code and simplifies error handling.

Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

OMAPDSS: nec-nl8048 panel: Use dev_pm_ops

Use dev_pm_ops instead of the deprecated legacy suspend/resume callbacks.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

OMAPDSS: DISPC: Revert to older DISPC Smart Standby mechanism for OMAP5

DISPC on OMAP5 has a more optimised mechanism of asserting Mstandby to achieve
more power savings when DISPC is configured in Smart Standby mode. This
mechanism leads to underflows when multiple DISPC pipes are enabled.

There is a register field which can let us revert to the older mechanism of
asserting Mstandby. Configure this field to prevent underflows.

Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

OMAPDSS: DISPC: Configure doublestride for NV12 when using 2D Tiler buffers

When using a DISPC video pipeline to a fetch a NV12 buffer in a 2D container, we
need to set set a doublestride bit in the video pipe's ATTRIBUTES register. This
is needed because the stride for the UV plane(using a 16 bit Tiler container) is
double the stride for the Y plane(using a 8 bit Tiler container) for the 0 or
180 degree views. The ROW_INC register is meant for the Y plane, and the HW will
calculate the row increment needed for the UV plane by using double the stride
value based on whether this bit is set or not.

Set the bit when we are using a 2D Tiler buffer and when rotation is 0 or 180
degrees. The stride value is the same for 90 and 270 degree Tiler views, hence
the bit shouldn't be set.

Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

omapdss: Features: Fix some parameter ranges

Increase the DSS_FCLK and DSI_FCLK max supported frequencies, these come because
some frequencies were increased from OMAP5 ES1 to OMAP5 ES2. We support only
OMAP5 ES2 in the kernel, so replace the ES1 values with ES2 values. Increase the
DSI PLL Fint range, this was previously just copied from the OMAP4 param range
struct.

Fix the maximum DSS_FCLK on OMAP2, it's 133 Mhz according to the TRM.

Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

omapdss: DISPC: add max pixel clock limits for LCD and TV managers

Each version of OMAP has a limitation on the maximum pixel clock frequency
supported by an overlay manager. This limit isn't checked by omapdss. Add
dispc feats for lcd and tv managers and check whether the target timings can
be supported or not.

The pixel clock limitations are actually more complex. They depend on which OPP
OMAP is in, and they also depend on which encoder is the manager connected to.
The OPP dependence is ignored as DSS forces the PM framework to be on OPP100
when DSS is enabled, and the encoder dependencies are ignored by DISPC for now.
These limits should come from the encoder driver.

The OMAP2 TRM doesn't mention the maximum pixel clock limit. This value is left
as half of DSS_FCLK, as OMAP2 requires the PCD to be atleast 2.

Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

OMAPDSS: DSI: Use devm_clk_get()

Using devm_clk_get cleans up some code.

Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

drivers: video: omap2: dss: Use PTR_RET function

Use PTR_RET function instead of IS_ERR and PTR_ERR.
Patch found using coccinelle.

Signed-off-by: Alexandru Gheorghiu <gheorghiuandru@gmail.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

drm/i915: info level for simulated gpu hang dmesg notice

Otherwise running igt will fill your dmesg with hang notices and it's
hard to judge from a quick look whether they're expected or not.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: revert eDP bpp clamping code changes

The behaviour around handling the eDP bpp value from vbt has been
slightly changed in

commit 3600836585e3fdef0a1410d63fe5ce4015007aac
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Mar 27 00:44:59 2013 +0100

    drm/i915: convert DP autodither code to new infrastructure

The old behaviour was that we used the plane's bpp (usually 24bpp) for
computing the dp link bw, but set up the pipe with the bpp value from
vbt if available. This takes the vbt bpp override into account even
for the dp link bw configuration.

On Paulo's hsw machine this resulted in a slower link clock and a
black screen - but the mode actually /should/ fit even with the lower
clock. Until we've cleared up simply stay bug-for-bug compatible with
the old code.

While at it, also restore a debug message lost in:

commit 4e53c2e010e531b4a014692199e978482d471c7e
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Mar 27 00:44:58 2013 +0100

    drm/i915: precompute pipe bpp before touching the hw

Cc: Paulo Zanoni <przanoni@gmail.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Revert "drm/i915: fix DP get_hw_state return value"

This reverts commit deb18211a110c102d32b3e9ed866bd7d25e0f8d5.

It completely breaks the logic, since when we fall through to the end
of the function we actually _have_ figured out the correct pipe.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Don't use the HDMI port color range bit on Valleyview

VLV docs still list the the color range selection bit for the HDMI
ports, but for DP ports it has been repurposed.

I have no idea whether the HDMI color range selection bit still works
on VLV, but since we now have to use the PIPECONF color range bit for
DP, we might as well do the same for HDMI.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Set PIPECONF color range bit on Valleyview

VLV has the color range selection bit in the PIPECONF register.
Configure it appropriately.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
[danvet: fixup rebase issues due to slightly different baseline.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: extract i9xx_set_pipeconf

Prep-patch to improve the bpc handling in a next patch.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Add no-lvds quirk for Fujitsu Esprimo Q900

The "Mobile Sandy Bridge CPUs" in the Fujitsu Esprimo Q900
mini desktop PCs are probably misleading the LVDS detection
code in intel_lvds_supported. Nothing is connected to the
LVDS ports in these systems.

Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Merge tag 'drm-intel-next-2013-03-23' of git://people.freedesktop.org/~danvet/drm-intel into drm-next

Daniel writes:
Highlights:
- Imre's for_each_sg_pages rework (now also with the stolen mem backed
  case fixed with a hack) plus the drm prime sg list coalescing patch from
  Rahul Sharma. I have some follow-up cleanups pending, already acked by
  Andrew Morton.
- Some prep-work for the crazy no-pch/display-less platform by Ben.
- Some vlv patches, by far not all (Jesse et al).
- Clean up the HDMI/SDVO #define confusion (Paulo)
- gen2-4 vblank fixes from Ville.
- Unclaimed register warning fixes for hsw (Paulo). More still to come ...
- Complete pageflips which have been stuck in a gpu hang, should prevent
  stuck gl compositors (Ville).
- pm patches for vt-switchless resume (Jesse). Note that the i915 enabling
  is not (yet) included, that took a bit longer to settle. PM patches are
  acked by Rafael Wysocki.
- Minor fixlets all over from various people.

* tag 'drm-intel-next-2013-03-23' of git://people.freedesktop.org/~danvet/drm-intel: (79 commits)
  drm/i915: Implement WaSwitchSolVfFArbitrationPriority
  drm/i915: Set the VIC in AVI infoframe for SDVO
  drm/i915: Kill a strange comment about DPMS functions
  drm/i915: Correct sandybrige overclocking
  drm/i915: Introduce GEN7_FEATURES for device info
  drm/i915: Move num_pipes to intel info
  drm/i915: fixup pd vs pt confusion in gen6 ppgtt code
  style nit: Align function parameter continuation properly.
  drm/i915: VLV doesn't have HDMI on port C
  drm/i915: DSPFW and BLC regs are in the display offset range
  drm/i915: set conservative clock gating values on VLV v2
  drm/i915: fix WaDisablePSDDualDispatchEnable on VLV v2
  drm/i915: add more VLV IDs
  drm/i915: use VLV DIP routines on VLV v2
  drm/i915: add media well to VLV force wake routines v2
  drm/i915: don't use plane pipe select on VLV
  drm: modify pages_to_sg prime helper to create optimized SG table
  drm/i915: use for_each_sg_page for setting up the gtt ptes
  drm/i915: create compact dma scatter lists for gem objects
  drm/i915: handle walking compact dma scatter lists
  ...

mm: prevent mmap_cache race in find_vma()

find_vma() can be called by multiple threads with read lock
held on mm->mmap_sem and any of them can update mm->mmap_cache.
Prevent compiler from re-fetching mm->mmap_cache, because other
readers could update it in the meantime:

               thread 1                             thread 2
                                        |
  find_vma()                            |  find_vma()
    struct vm_area_struct *vma = NULL;  |
    vma = mm->mmap_cache;               |
    if (!(vma && vma->vm_end > addr     |
        && vma->vm_start <= addr)) {    |
                                        |    mm->mmap_cache = vma;
    return vma;                         |
     ^^ compiler may optimize this      |
        local variable out and re-read  |
        mm->mmap_cache                  |

This issue can be reproduced with gcc-4.8.0-1 on s390x by running
mallocstress testcase from LTP, which triggers:

  kernel BUG at mm/rmap.c:1088!
    Call Trace:
     ([<000003d100c57000>] 0x3d100c57000)
      [<000000000023a1c0>] do_wp_page+0x2fc/0xa88
      [<000000000023baae>] handle_pte_fault+0x41a/0xac8
      [<000000000023d832>] handle_mm_fault+0x17a/0x268
      [<000000000060507a>] do_protection_exception+0x1e2/0x394
      [<0000000000603a04>] pgm_check_handler+0x138/0x13c
      [<000003fffcf1f07a>] 0x3fffcf1f07a
    Last Breaking-Event-Address:
      [<000000000024755e>] page_add_new_anon_rmap+0xc2/0x168

Thanks to Jakub Jelinek for his insight on gcc and helping to
track this down.

Signed-off-by: Jan Stancek <jstancek@redhat.com>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: Hugh Dickins <hughd@google.com>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Merge tag 'upstream-3.9-rc6' of git://git.infradead.org/linux-ubifs

Pull UBIFS fix from Artem Bityutskiy:
 "Make the space fixup feature work in the case when the file-system is
  first mounted R/O and then remounted R/W."

* tag 'upstream-3.9-rc6' of git://git.infradead.org/linux-ubifs:
  UBIFS: make space fixup work in the remount case

Merge branch 'for-linus' of git://git./linux/kernel/git/jikos/hid

Pull HID fixes from Jiri Kosina:

 - Workaround for device ID conflict between Masterkit MA901 usb radio
   device and Atmel V-USB devices, to avoid regressions from older
   kernels, by Alexey Klimov

 - fix for possible race during input device registration in magicmouse
   driver, by Benjamin Tissoires

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid:
  HID: magicmouse: fix race between input_register() and probe()
  media: radio-ma901: return ENODEV in probe if usb_device doesn't match
  HID: fix Masterkit MA901 hid quirks

Merge tag 'gpio-fixes-v3.9' of git://git./linux/kernel/git/linusw/linux-gpio

Pull GPIO fixes from Linus Walleij:
 "Two GPIO fixes for the v3.9 series:
   - Fix erroneous return value in the ICH driver
   - Make the STMPE driver proper properly on device tree boots"

* tag 'gpio-fixes-v3.9' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
  gpio: stmpe: pass DT node to irqdomain
  gpio-ich: Fix value returned by ichx_gpio_request

HID: magicmouse: fix race between input_register() and probe()

Since kernel 3.7, it appears that the input registration occured before
the end of magicmouse_setup_input(). This is shown by receiving a lot of
"EV_SYN SYN_REPORT 1" instead of normal "EV_SYN SYN_REPORT 0".
This value means that the output buffer is full, and the user space
is loosing events.

Using .input_configured guarantees that the race is not occuring, and that
the call of "input_set_events_per_packet(input, 60)" is taken into account
by input_register().

Fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=908604

Cc: stable@vger.kernel.org
Reported-and-Tested-By: Clarke Wixon <cwixon@usa.net>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>

Merge branch 'fixes' of git://git.linaro.org/people/rmk/linux-arm

Pull ARM fixes from Russell King:
 "Another round of ARM fixes, which include:
   - Fixing a problem with LPAE mapping sections
   - Reporting of some hwcaps on Krait CPUs
   - Avoiding repetitive warnings in the breakpoint code
   - Fixing a build error noticed on Dove platforms with PJ4 CPUs
   - Fix masking of level 2 cache revision.
   - Fixing timer-based udelay()
   - A larger fix for an erratum causing people major grief with Cortex
     A15 CPUs"

* 'fixes' of git://git.linaro.org/people/rmk/linux-arm:
  ARM: 7690/1: mm: fix CONFIG_LPAE typos
  ARM: 7689/1: add unwind annotations to ftrace asm
  ARM: 7685/1: delay: use private ticks_per_jiffy field for timer-based delay ops
  ARM: 7684/1: errata: Workaround for Cortex-A15 erratum 798181 (TLBI/DSB operations)
  ARM: 7682/1: cache-l2x0: fix masking of RTL revision numbering and set_debug init
  ARM: iWMMXt: always enable iWMMXt support with PJ4 CPUs
  ARM: 7681/1: hw_breakpoint: use warn_once to avoid spam from reset_ctrl_regs()
  ARM: 7678/1: Work around faulty ISAR0 register in some Krait CPUs
  ARM: 7680/1: Detect support for SDIV/UDIV from ISAR0 register
  ARM: 7679/1: Clear IDIVT hwcap if CONFIG_ARM_THUMB=n
  ARM: 7677/1: LPAE: Fix mapping in alloc_init_section for unaligned addresses
  ARM: KVM: vgic: take distributor lock on sync_hwstate path
  ARM: KVM: vgic: force EOIed LRs to the empty state

Merge tag 'ext4_for_linus_stable' of git://git./linux/kernel/git/tytso/ext4

Pull ext4 fixes from Ted Ts'o:
 "Unfortunately, we introduced some big-endian bugs during the last
  merge window.  Fortunately, Cai and Christian noticed before 3.9
  shipped."

* tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4:
  ext4: fix big-endian bugs which could cause fs corruptions

Merge branch 'for_linus' of git://git./linux/kernel/git/jack/linux-fs

Pull reiserfs fix from Jan Kara:
 "A fix for reiserfs xattr bug exposed by changes to lookup_one_len()"

* 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs:
  reiserfs: Fix warning and inode leak when deleting inode with xattrs

Merge branch 'for-linus' of git://git./linux/kernel/git/s390/linux

Pull s390 fixes from Martin Schwidefsky:
 "Just a bunch of bugfixes"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
  s390/mm: provide emtpy check_pgt_cache() function
  s390/uaccess: fix page table walk
  s390/3270: fix minor_start issue
  s390/uaccess: fix clear_user_pt()
  s390/scm_blk: fix error return code in scm_blk_init()
  s390/scm_block: fix printk format string
  drivers/Kconfig: add several missing GENERIC_HARDIRQS dependencies

ext4: fix big-endian bugs which could cause fs corruptions

When an extent was zeroed out, we forgot to do convert from cpu to le16.
It could make us hit a BUG_ON when we try to write dirty pages out.  So
fix it.

[ Also fix a bug found by Dmitry Monakhov where we were missing
  le32_to_cpu() calls in the new indirect punch hole code.

  There are a number of other big endian warnings found by static code
  analyzers, but we'll wait for the next merge window to fix them all
  up.  These fixes are designed to be Obviously Correct by code
  inspection, and easy to demonstrate that it won't make any
  difference (and hence, won't introduce any bugs) on little endian
  architectures such as x86.  --tytso ]

Signed-off-by: Zheng Liu <wenqing.lz@taobao.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reported-by: CAI Qian <caiqian@redhat.com>
Reported-by: Christian Kujau <lists@nerdbynature.de>
Cc: Dmitry Monakhov <dmonakhov@openvz.org>

ARM: 7690/1: mm: fix CONFIG_LPAE typos

CONFIG_LPAE doesn't exist: the correct option is CONFIG_ARM_LPAE, so fix
up the two typos under arch/arm/.

The fix to head.S is slightly scary, but this is just for setting up
an early io-mapping for the serial port when running on a big-endian,
LPAE system. Since these systems don't exist in the wild (at least, I
have no access to one outside of kvmtool, which doesn't provide a serial
port suitable for earlyprintk), then we can revisit the code later if it
causes any problems.

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 7689/1: add unwind annotations to ftrace asm

Add unwind annotations to the ftrace assembly code so that the function
tracer's stacktracing options (func_stack_trace, etc.) work when
CONFIG_ARM_UNWIND is enabled.

Signed-off-by: Rabin Vincent <rabin@rab.in>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 7685/1: delay: use private ticks_per_jiffy field for timer-based delay ops

Commit 70264367a243 ("ARM: 7653/2: do not scale loops_per_jiffy when
using a constant delay clock") fixed a problem with our timer-based
delay loop, where loops_per_jiffy is scaled by cpufreq yet used directly
by the timer delay ops.

This patch fixes the problem in a more elegant way by keeping a private
ticks_per_jiffy field in the delay ops, independent of loops_per_jiffy
and therefore not subject to scaling. The loop-based delay continues to
use loops_per_jiffy directly, as it should.

Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 7684/1: errata: Workaround for Cortex-A15 erratum 798181 (TLBI/DSB operations)

On Cortex-A15 (r0p0..r3p2) the TLBI/DSB are not adequately shooting down
all use of the old entries. This patch implements the erratum workaround
which consists of:

1. Dummy TLBIMVAIS and DSB on the CPU doing the TLBI operation.
2. Send IPI to the CPUs that are running the same mm (and ASID) as the
   one being invalidated (or all the online CPUs for global pages).
3. CPU receiving the IPI executes a DMB and CLREX (part of the exception
   return code already).

Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 7682/1: cache-l2x0: fix masking of RTL revision numbering and set_debug init

Commit b8db6b8 (ARM: 7547/4: cache-l2x0: add support for Aurora L2 cache
ctrl) moved the masking of the part ID which caused the RTL version to be
lost. Commit 6248d06 (ARM: 7545/1: cache-l2x0: make outer_cache_fns a
field of l2x0_of_data) changed how .set_debug is initialized. Both commits
break commit 74ddcdb (ARM: 7608/1: l2x0: Only set .set_debug
on PL310 r3p0 and earlier) which uses the RTL version to conditionally set
.set_debug function pointer. Commit b8db6b8 also caused the printed cache
ID to be missing the version information.

Fix this by reverting how the part number is masked so the RTL version
info is maintained. The cache-id-part DT property does not set the RTL
bits so masking them should have no effect. Also, re-arrange the order
of the function pointer init so the .set_debug function can be overridden.

Reported-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>
Cc: Yehuda Yitschak <yehuday@marvell.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: iWMMXt: always enable iWMMXt support with PJ4 CPUs

Jason Cooper reports these build errors:
arch/arm/kernel/built-in.o: In function `iwmmxt_do':
/.../arch/arm/kernel/pj4-cp0.c:36: undefined reference to `iwmmxt_task_release'
/.../arch/arm/kernel/pj4-cp0.c:40: undefined reference to `iwmmxt_task_switch'
make: *** [vmlinux] Error 1

This is caused because the PJ4 code explicitly references the iWMMXt
code, but doesn't require it to be built.  Fix this by ensuring that
iWMMXt is always enabled with PJ4.

Reported-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

OMAPDSS: VENC: remove platform_enable/disable calls

The platform_enable/disable callbacks in board files for VENC omap_dss_device
instances don't do anything. Hence, we can remove these callbacks from the VENC
driver.

Signed-off-by: Archit Taneja <archit@ti.com>

OMAPDSS: n8x0 panel: remove use of platform_enable/disable

The n8x0 panel driver now manages the gpios required to configure the panel.
This was previously done in panel_n8x0_data's platform_enable/disable callbacks
defined in board files using this panel.

All the board files using this panel now pass the gpio information as platform
data via the panel_n8x0_data struct, which is needed by the panel driver to
configure the gpios connected to the panel. Hence, the uses of
platform_enable/disable ops can be safely removed now.

Signed-off-by: Archit Taneja <archit@ti.com>

OMAPDSS: n8x0 panel: handle gpio data in panel driver

The n8x0 panel driver leaves gpio configurations to the platform_enable and
disable calls in the platform's board file. These should happen in the panel
driver itself.

A platform data struct called panel_n8x0_data already exists to hold gpio
numbers and other platform data. However, the gpio requests are expected to be
done in the board file and not the panel driver.

Request all the gpios in the panel driver so that the board files which use
the the panel don't need to do it. This will help in removing the need for the
panel drivers to have platform related callbacks.

Signed-off-by: Archit Taneja <archit@ti.com>

OMAPDSS: picodlp panel: remove platform_enable/disable callbacks

The picodlp panel driver now manages the gpios required to configure the
panel. This was previously done in omap_dss_device's platform_enable/disable
callbacks defined in board files using this panel.

All the board files using this panel now pass the gpio information as platform
data via the panel_generic_dpi_data struct, which is needed by the panel driver
to configure the gpios connected to the panel. Hence, the
platform_enable/disable ops can be safely removed now.

Signed-off-by: Archit Taneja <archit@ti.com>

OMAPDSS: picodlp panel: handle gpio data in panel driver

The picodlp panel driver leaves gpio requests to the platform's board file.
These should happen in the panel driver itself.

A platform data struct called picodlp_panel_data already exists to hold gpio
numbers and other platform data. Request all the gpios in the panel driver so
that the board files which use the the panel don't need to do it.

This will help in removing the need for the panel drivers to have platform
related callbacks.

Signed-off-by: Archit Taneja <archit@ti.com>

OMAPDSS: tpo-td043: remove platform_enable/disable callbacks

The tpo-td043 panel driver now manages the gpios required to configure the panel.
This was previously done in omap_dss_device's platform_enable/disable callbacks
defined in board files using this panel.

All the board files using this panel now pass the gpio information as platform
data via the panel_tpo_td043_data struct, which is needed by the panel driver to
configure the gpios connected to the panel. Hence, the platform_enable/disable
ops can be safely removed now.

Signed-off-by: Archit Taneja <archit@ti.com>

OMAPDSS: tpo-td043 panel: handle gpios in panel driver

The tpo-td043mtea1 panel driver leaves gpio configurations to the
platform_enable and disable calls in the platform's board file. These should
happen in the panel driver itself.

Create a platform data struct for the panel, this contains the reset gpio
number used by the panel driver, this struct will be passed to the panel driver
as platform data. The driver will request and configure the reset gpio rather
than leaving it to platform callbacks in board files.

This will help in removing the need for the panel drivers to have platform
related callbacks.

Signed-off-by: Archit Taneja <archit@ti.com>

OMAPDSS: nec-nl8048 panel: remove platform_enable/disable callbacks

The nec-nl8048 panel driver now manages the gpios required to configure the
panel. This was previously done in omap_dss_device's platform_enable/disable
callbacks defined in board files using this panel.

All the board files using this panel now pass the gpio information as platform
data via the panel_nec_nl8048_data struct, which is needed by the panel driver
to configure the gpios connected to the panel. Hence, the
platform_enable/disable ops can be safely removed now.

Signed-off-by: Archit Taneja <archit@ti.com>

OMAPDSS: nec-nl8048 panel: handle gpios in panel driver

The nec-nl8048hl11-01 panel driver leaves gpio configurations to the
platform_enable and disable calls in the platform's board file. These should
happen in the panel driver itself.

Create a platform data struct for the panel, this contains the gpio numbers
used by the panel driver, this struct will be passed to the panel driver as
platform data. The driver will request and configure these gpios rather than
leaving it to platform callbacks in board files.

This will help in removing the need for the panel drivers to have platform
related callbacks.

Signed-off-by: Archit Taneja <archit@ti.com>

OMAPDSS: acx565akm panel: handle gpios in panel driver

The acx565akm panel driver leaves gpio configurations to the platform_enable
and disable calls in the platform's board file. These should happen in the panel
driver itself.

Create a platform data struct for the panel, this contains the reset gpio number
used by the panel driver, this struct will be passed to the panel driver as
platform data. The driver will request and configure the reset gpio rather than
leaving it to platform callbacks in board files.

This will help in removing the need for the panel drivers to have platform
related callbacks.

Signed-off-by: Archit Taneja <archit@ti.com>

OMAPDSS: sharp-ls panel: remove platform_enable/disable callbacks

The sharp-ls panel driver now manages the gpios required to configure the panel.
This was previously done in omap_dss_device's platform_enable/disable callbacks
defined in board files using this panel.

All the board files using this panel now pass the gpio information as platform
data via the panel_sharp_ls037v7dw01_data struct, which is needed by the panel
driver to configure the gpios connected to the panel. Hence, the
platform_enable/disable ops can be safely removed now.

Signed-off-by: Archit Taneja <archit@ti.com>

OMAPDSS: LS037V7DW01: handle gpios in panel driver

Move the GPIO handling from board file's platform callbacks to the panel
driver, which gets the gpios via platform data.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

OMAPDSS: generic dpi panel: remove uses of platform_enable/disable ops

The generic dpi panel driver now sets the gpios required to configure the panel.
This was previously done in platform_enable/disable callbacks in board files.

All the board files using generic dpi panel now correctly pass the gpio related
information as platform data, which is needed by the panel driver to configure
the panel. Hence, the platform_enable/disable ops can be safely removed now.

Signed-off-by: Archit Taneja <archit@ti.com>

OMAPDSS: lb035q02 panel: remove platform_enable/disable callbacks

The lgphilips panel driver now manages the gpios required to configure the
panel. This was previously done in omap_dss_device's platform_enable/disable
callbacks defined in board files using this panel.

All the board files using this panel now pass the gpio information as platform
data via the panel_generic_dpi_data struct, which is needed by the panel driver
to configure the gpios connected to the panel. Hence, the
platform_enable/disable ops can be safely removed now.

Signed-off-by: Archit Taneja <archit@ti.com>

OMAPDSS: lb035q02: handle gpios in panel driver

The lgphilips panel driver leaves gpio configurations to the platform_enable
and disable calls in the platform's board file. These should happen in the
panel driver itself.

Use the platform data as defined for generic dpi panels to pass gpio information
to the lgphilips driver.

This will help in removing the need for the panel drivers to have platform
related callbacks.

Signed-off-by: Archit Taneja <archit@ti.com>

OMAPDSS: generic dpi panel: handle gpios in panel driver

The generic dpi panel driver leaves gpio configurations to the platform_enable
and disable calls in the platform's board file. These should happen in the
panel driver itself.

Add a generic way of passing gpio information to the generic dpi panel driver
via it's platform_data. This information includes the number of gpios used by
the panel, the gpio number and logic level (active high/low) for each gpio. This
gpio data will be used by the driver to request and configure the gpios required
by the panel.

This will help in removing the need for the panel drivers to have platform
related callbacks.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Archit Taneja <archit@ti.com>

OMAPDSS: panel acx565akm: remove omap_dss_device maximum backlight level usage

The omap_dss_device structs's max_backlight_level is used to pass maximum
backlight level for the platform. However, no board file using this panel
populates this field. Therefore, we remove it's usage from the panel driver.

Signed-off-by: Archit Taneja <archit@ti.com>

OMAPDSS: picodlp: use devm_kzalloc for allocating driver data

Use devm_kzalloc instead of kzalloc to allocate driver data for the picodlp
panel driver. This simplifies the driver's probe and remove functions.

Signed-off-by: Archit Taneja <archit@ti.com>

OMAPDSS: lb035q02: use devm_kzalloc for allocating driver data

Use devm_kzalloc instead of kzalloc to allocate driver data for the lg phillips
panel driver. This simplifies the driver's probe and remove functions.

Cc: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Archit Taneja <archit@ti.com>

OMAPDSS: Generic DPI Panel: use devm_kzalloc for allocating driver data

Use devm_kzalloc instead of kzalloc to allocate driver data for the generic dpi
panel driver. This simplifies the driver's probe and remove functions.

Signed-off-by: Archit Taneja <archit@ti.com>

OMAPDSS: n8x0: remove platform backlight calls

The n8x0 panel contains support to call platform backlight functions.
These are not used by any board, and can be removed.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Archit Taneja <archit@ti.com>

OMAPDSS: NEC-nl8048hl11: remove platform backlight support

NEC-nl8048hl11 driver contains support to call platform backlight
functions. These are not used by any board, and can be removed.

Signed-off-by: Archit Taneja <archit@ti.com>

OMAPDSS: ls037v7dw01: remove platform backlight calls

Sharp ls037v7dw01 driver contains support to call platform backlight
functions. These are not used by any board, and can be removed.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Archit Taneja <archit@ti.com>

OMAPDSS: acx565akm: remove platform backlight calls

acx565akm has support to call set_backlight/get_backlight in platform
code. They are not used by any board, and thus can be removed from the
driver.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Archit Taneja <archit@ti.com>

OMAPDSS: remove dsi videomode from dssdev

DSI videomode is no longer needed in the omap_dss_device, so remove it.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

OMAPDSS: remove unused old clock calculation code

Now that the old clock calculation code is no longer used, we can remove
it from the driver.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

OMAPDSS: DSI: use new clock calculation code

Use the new clock calculation code in the DSI driver.

The new code does not need DSI video mode parameters from the panel
driver, like the old code does. Instead the new code is given the normal
video timings, and a few DSI parameters, which are used to create DSI
video timings.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

OMAPDSS: DPI: use new clock calculation code

Use the new clock calculation code in the DPI driver.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

OMAPDSS: SDI: use new clock calculation code

Use the new clock calculation code in the SDI driver.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

OMAPDSS: DSI: add new clock calculation code

Add new way to iterate over DSI PLL and HSDIV clock divisors.
dsi_pll_calc() and dss_hsdiv_calc() provide a generic way to go over
all the divisors, within given clock range. The functions will call a
callback function for each divider set, making the function reusable for
all use cases.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

OMAPDSS: DSS: add new clock calculation code

Add new way to iterate over DSS clock divisors. dss_div_calc() provides
a generic way to go over all the divisors, within given clock range.
dss_div_calc() will call a callback function for each divider set,
making the function reusable for all use cases.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

OMAPDSS: DISPC: add new clock calculation code

Add new way to iterate over DISPC clock divisors. dispc_div_calc()
provides a generic way to go over all the divisors, within given pixel
clock range. dispc_div_calc() will call a callback function for each
divider set, making the function reusable for all use cases.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

OMAPDSS: DSI remove unneeded clk source setup code

We always use the same clock sources for DSI, so let's remove the
unnecessary clock source fields from dsi_data.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

OMAPDSS: DSI: add enum omap_dss_dsi_trans_mode

Instead of managing DSI sync ends with booleans, add an enum for the DSI
transfer mode. This is much cleaner way to handle the DSI syncs.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

OMAPDSS: DSI: get line buffer size at probe

To find out the DSI line buffer size we need to read HW registers. To
make it possible to do DSI configuration calculations without HW powered
up, store the line buffer size at DSI driver's probe.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

OMAPDSS: DSI: simplify dsi configuration

We have a bunch of dsi functions that are used to do the basic
configuration for DSI. To simplify things, and to make sure we have all
the necessary information, create a single dsi config function, which
does the basic configuration.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

OMAPDSS: DSI: fix wrong unsigned long long use

dsi_configure_dispc_clocks() stores dsi func clock into unsigned long
long, but it should really be just unsigned long. Fix this.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

OMAPDSS: DISPC: store core clk rate

Store dispc core clock rate so that it's available for calculations even
if the HW is disabled.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

OMAPDSS: DPI: fix dpi_get_dsidev() for omap5

On OMAP5 the DISPC channels and DSI PLLs are not connected the same way.
LCD2 on OMAP5 cannot use any DSI PLL as a source clock, but LCD3 can use
DSI2's PLL.

This patch fixes dpi_get_dsidev() by adding separate case for OMAP5 to
handle the difference.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>

OMAPDSS: Taal: remove rotate & mirror support

Taal panel driver has support to set rotation and mirroring. However,
these features cannot be used without causing tearing, and are never
used. The code is just extra bloat, so let's remove it.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>

OMAPDSS: DSI: fix DSI channel source initialization

During the initialization of the DSI protocol registers, we always set
the sources of all DSI channels to L4. However, we don't update the
value in the dsi_data, so we may end up with a different value in the
register and in the dsi_data, leading to DSI problems.

This patch fixes the issue by initializing also the channel source in
the dsi_data.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>

OMAPDSS: DSI: delay dispc initialization

We currently setup both DSI and DISPC related things when the DSI bus is
enabled. There's no need for DISPC related thing at that point, though,
but only later when the video output is enabled.

To make it possible to use the DSI bus before DISPC overlay manager is
selected, this patch moves DSI's DISPC initialization to
dsi_enable_video_output(), from omapdss_dsi_display_enable(). We also
move the selection of DISPC's LCD clock to dsi_enable_video_output.

This way there are no DISPC dependencies until the video output is
enabled.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>

OMAPDSS: add output->dispc_channel

The DISPC channel used for each output is currently passed in panel
platform data from the board files.

To simplify this, and to make the panel drivers less dependent on OMAP,
this patch changes omapdss to resolve the channel independently. The
channel is resolved based on the OMAP version and, in case of DSI, the
DSI module id. This resolved channel is stored into a new field in
output, dispc_channel.

The few places where dssdev->channel was used are changed to use
output->recommended_channel. After this patch, dssdev->channel is
obsolete.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>