Create a dss_lcd_mgr_config struct instance in DPI. Fill up all the parameters
of the struct with configurations held by the panel, and the configurations
required by DPI.

Use these to write to the DISPC registers. These direct register writes would be
later replaced by a function which applies the configuration using the shadow
register programming model.

The DISPC_DIVISORo registers were written in the functions dpi_set_dispc_clk()
and dpi_set_dsi_clk(), now they just fill up the dispc_clock_info parameter in
mgr_config. They are written later in dpi_config_lcd_manager.
Signed-off-by: NArchit Taneja <archit@ti.com>

Create a struct dss_lcd_mgr_config which holds LCD overlay manager related
parameters. These are currently partially contained in the omap_dss_device
connected to the manager, and the rest are in the interface driver.

The parameters are directly written to the DISPC registers in the interface
drivers. These should eventually be applied at the correct time using the
shadow register programming model. This struct would help in grouping these
parameters so that they can be applied together.
Signed-off-by: NArchit Taneja <archit@ti.com>

dipsc_mgr_set_clock div has an int return type to report errors or success.
The function doesn't really check for errors and always returns 0. Change
the return type to void.

Checking for the correct DISPC clock divider ranges will be done when a DSS2
user does a manager apply. This support will be added later.
Signed-off-by: NArchit Taneja <archit@ti.com>

The dispc_disable_outputs() function currently disables all LCD managers except
LCD3. This patch adds disabling functionality for LCD3 manager thereby
maintaining consistency of Display Subsystem for in case Display Controller is
reset when LCD3 manager is in use.
Signed-off-by: NChandrabhanu Mahapatra <cmahapatra@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

This series does the following things:

- Remove passive matrix LCD support: There are no panel drivers with
  passive matrix LCD drivers in DSS2. There are no passive matrix panels
  even available to test with DSS. Since no one is using passive matrix
  panels, stop trying to support it. It cleans up the DSS driver.

- Add some new fields to omap_video_timings: There were some standard
  panel timing fields missing from omap_video_timings. Namely
  Hsync/Vsync/DE levels and interlace. Add these to omap_video_timings
  to align it more with xorg modeline. Add some other OMAP DSS specific
  fields to omap_video_timings.

- Remove some hacks done because omap_video_timings didn't have the
  above fields.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

For DSI operation in videomode, DISPC logic levels for the signals HSYNC, VSYNC
and DE need to be specified to DSI via the fields VP_HSYNC_POL, VP_VSYNC_POL and
VP_DE_POL in DSI_CTRL registers.

This information is completely internal to DSS as logic levels for the above
signals hold no meaning on the DSI bus. Hence a DSI panel driver should be
totally oblivious of these fields.

Fix the logic levels/polarities in the DISPC and DSI registers to a default
value. This is done by overriding these fields in omap_video_timings struct
filled by the panel driver for DISPC, and use the equivalent default values
when programming DSI_CTRL registers. Also, remove the redundant polarity related
fields in omap_dss_dsi_videomode_data.
Signed-off-by: NArchit Taneja <archit@ti.com>

The hdmi CEA and VESA timings were represented by the struct hdmi_video_timings,
omap_video_timings couldn't be used as it didn't contain the fields hsync/vsync
polarities and interlaced/progressive information.

Remove hdmi_video_timings, and use omap_video_timings instead.

Cc: Mythri P K <mythripk@ti.com>
Signed-off-by: NArchit Taneja <archit@ti.com>

Use the interlace field in omap_video_timings to configure/retrieve
corresponding fb mode flags in fb_var_screeninfo and fb_videomode.

The interlace field maps with the fb mode flags FB_VMODE_INTERLACED and
FB_VMODE_NONINTERLACED.
Signed-off-by: NArchit Taneja <archit@ti.com>

Currently the interlace parameter passed to dispc_ovl_setup() is configured by
checking the display type, and set to true if the display type is VENC.

This isn't correct as other panels can take interlaced content too. The
omap_video_timings struct in manager's private data contains the info whether
the panel is in interlaced mode or not.
Signed-off-by: NArchit Taneja <archit@ti.com>

Add a parameter called interlace which tells whether the timings are in
interlaced or progressive mode. This aligns the omap_video_timings struct with
the Xorg modeline configuration.

It also removes the hack needed to write to divide the manager height by 2 if
the connected interface is VENC.
Signed-off-by: NArchit Taneja <archit@ti.com>

omap_panel_config contains fields which are finally written to DISPC_POL_FREQo
registers. These are now held by omap_video_timings and are set when the manager
timings are applied.

Remove the omap_panel_config enum, and remove all it's references from panel or
interface drivers.
Signed-off-by: NArchit Taneja <archit@ti.com>

Use the newly added fields in omap_video_timings(hsync, vsync and data_enable
logic levels and data, hsync and vsync latching related info) to
configure/retrieve corresponding sync flags in fb_var_screeninfo and
fb_videomode.

Out of the new fields, hsync_level and vsync_level can be mapped to the fb sync
flags FB_SYNC_HOR_HIGH_ACT and FB_SYNC_VERT_HIGH_ACT.

When converting fb mode to omap_video_timings, the fields which don't have an
equivalent parameter in fb are kept as the original values if the panel driver
has a get_timings op, else they are set to default values.
Signed-off-by: NArchit Taneja <archit@ti.com>

dispc_mgr_set_pol_freq() configures the fields in the register DISPC_POL_FREQo.
All these fields have been moved to omap_video_timings struct, and are now
programmed in dispc_mgr_set_lcd_timings(). These will be configured when timings
are applied via dss_mgr_set_timings().

Remove dispc_mgr_set_pol_freq() and it's calls from the interface drivers.
Signed-off-by: NArchit Taneja <archit@ti.com>

Hsync, Vsync, Data enable enable logic levels and latching info of Data lanes,
Hsync and Vsync signals(with respect to pixel clock) are newly added parameters
in omap_video_timings.

Program these in dispc_mgr_set_lcd_timings. These will be configured when the
manager's timings are set via dss_mgr_set_timings().
Signed-off-by: NArchit Taneja <archit@ti.com>

The display sysfs file for viewing/storing display timings is something which
will be deprecated. The new omap_video_timings fields (hsync_level, vsync_level
and others) are not configurable or viewable via this sysfs file.

This prevents the need to make the input more configurable to take the new
fields and at the same time work without these fields for backward
compatibility.

In display_timings_store, the omap_video_timings struct used to set the timings
is initialized to the existing panel timings so that the new fields are taken in
correctly. The other fields are taken from the user as before.
Signed-off-by: NArchit Taneja <archit@ti.com>

Some panel timing related fields are contained in omap_panel_config in the form
of flags. The fields are:

- Hsync logic level
- Vsync logic level
- Data driven on rising/falling edge of pixel clock
- Output enable/Data enable logic level
- HSYNC/VSYNC driven on rising/falling edge of pixel clock

Out of these parameters, Hsync and Vsync logic levels are a part of the timings
in the Xorg modeline configuration. So it makes sense to move the to
omap_video_timings. The rest aren't a part of modeline, but it still makes
sense to move these since they are related to panel timings.

These fields stored in omap_panel_config in dssdev are configured for LCD
panels, and the corresponding LCD managers in the DISPC_POL_FREQo registers.

Add the above fields in omap_video_timings. Represent their state via new enums.

Add these parameters to the omap_video_timings instances in the panel drivers.
Keep the corresponding IVS, IHS, IPC, IEO, RF and ONOFF flags in
omap_panel_config for now. The struct will be removed later.
Signed-off-by: NArchit Taneja <archit@ti.com>

Remove configuration of Ac-bias pins

Ac-bias pins need to be configured only for passive matrix displays. Remove
acbi and acb fields in omap_dss_device and their configuration in panel
drivers. Don't program these fields in DISP_POL_FREQo register any more.

The panel driver for sharp-ls037v7dw01, and the panel config for
Innolux AT070TN8 in generic dpi panel driver set acb to a non zero value. This
is most likely carried over from the old omapfb driver which supported passive
matrix displays.

Cc: Thomas Weber <weber@corscience.de>
Signed-off-by: NArchit Taneja <archit@ti.com>

Remove omap_lcd_display_type enum

The enum omap_lcd_display_type is used to configure the lcd display type in
DISPC. Remove this enum and always set display type to TFT by creating function
dss_mgr_set_lcd_type_tft().
Signed-off-by: NArchit Taneja <archit@ti.com>

Remove OMAP_DSS_LCD_TFT as a omap_panel_config flag.

We don't support passive matrix displays any more. Remove this flag from all the
panel drivers.

Force the display_type to OMAP_DSS_LCD_DISPLAY_TFT in the interface drivers.
Signed-off-by: NArchit Taneja <archit@ti.com>

Remove clock constraints related to passive matrix displays.

There is a constraint (pcd_min should be 3) for passive matrix displays. Remove
this constraint in clock divider calculations as we won't support passive
matrix displays any more.

This cleans up the functions which calculate the clock dividers with DSI's PLL
or DSS_FCLK as the clock source.
Signed-off-by: NArchit Taneja <archit@ti.com>

State change of HDMI PHY could potentially take many millisecs, we can do
better by protecting things in hdmi_set_phy_pwr() with a mutex rather than
a spin_lock_irqsave.
Signed-off-by: NJassi Brar <jaswinder.singh@linaro.org>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

It is simpler to read the current status from a register as compared
to maintaining a state variable to hold the information.
Signed-off-by: NJassi Brar <jaswinder.singh@linaro.org>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

DISPC functions have been modified to provide clock and register dumps and debug
support for the LCD3 manager.
Signed-off-by: NChandrabhanu Mahapatra <cmahapatra@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The support for LCD3 manager has been added into the manager module. LCD3 panel
has registers as DISPC_CONTROL3 and DISPC_CONFIG3 just like those in LCD and
LCD2 panels. These registers control the Display Controller (DISPC) module for
LCD3 output. The three LCDs support Display Serial Interface (DSI), Remote Frame
Buffer Interface (RFBI) and Parallel CMOS Output Interface (DPI). These LCDs can
be connected through parallel output interface using DISPC and RFBI or DPI. For
serial interface DSS uses DSI.

The LCD3 panel, just like LCD and LCD2 panels, has a clock switch in DSS_CTRL
register which has been enabled. The clock switch chooses between DSS_CLK and
DPLL_DSI1_C_CLK1 as source for LCD3_CLK. New IRQs as DISPC_IRQ_VSYNC3,
DISPC_IRQ_FRAMEDONE3, DISPC_IRQ_ACBIAS_COUNT_STAT3 and DISPC_IRQ_SYNC_LOST3 have
been added specific to the new manager.
Signed-off-by: NChandrabhanu Mahapatra <cmahapatra@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

OMAP5 Display Subsystem (DSS) architecture comes with a additional LCD3 channel
with its own dedicated overlay manager. The current patch adds LCD3 channel and
basic register support for LCD3 channel. It adds register addresses for various
Display Controller (DISPC) registers like DISPC_DEFAULT_COLOR, DISPC_TIMING_H,
DISPC_DIVISORo, etc.
Signed-off-by: NChandrabhanu Mahapatra <cmahapatra@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The current implementation of LCD channels and managers consists of a number of
if-else construct which has been replaced by a simpler interface. A constant
structure mgr_desc has been created in Display Controller (DISPC) module. The
mgr_desc contains for each channel its name, irqs and  is initialized one time
with all registers and their corresponding fields to be written to enable
various features of Display Subsystem. This structure is later used by various
functions of DISPC which simplifies the further implementation of LCD channels
and its corresponding managers.
Signed-off-by: NChandrabhanu Mahapatra <cmahapatra@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

If runtime PM is not enabled in the kernel config, pm_runtime_get_sync()
will always return 1 and pm_runtime_put_sync() will always return
-ENOSYS. pm_runtime_get_sync() returning 1 presents no problem to the
driver, but -ENOSYS from pm_runtime_put_sync() causes the driver to
print a warning.

One option would be to ignore errors returned by pm_runtime_put_sync()
totally, as they only say that the call was unable to put the hardware
into suspend mode.

However, I chose to ignore the returned -ENOSYS explicitly, and print a
warning for other errors, as I think we should get notified if the HW
failed to go to suspend properly.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Jassi Brar <jaswinder.singh@linaro.org>
Cc: Grazvydas Ignotas <notasas@gmail.com>

The current way how omapdss handles system suspend and resume is that
omapdss device (a platform device, which is not part of the device
hierarchy of the DSS HW devices, like DISPC and DSI, or panels.) uses
the suspend and resume callbacks from platform_driver to handle system
suspend. It does this by disabling all enabled panels on suspend, and
resuming the previously disabled panels on resume.

This presents a few problems.

One is that as omapdss device is not related to the panel devices or the
DSS HW devices, there's no ordering in the suspend process. This means
that suspend could be first ran for DSS HW devices and panels, and only
then for omapdss device. Currently this is not a problem, as DSS HW
devices and panels do not handle suspend.

Another, more pressing problem, is that when suspending or resuming, the
runtime PM functions return -EACCES as runtime PM is disabled during
system suspend. This causes the driver to print warnings, and operations
to fail as they think that they failed to bring up the HW.

This patch changes the omapdss suspend handling to use PM notifiers,
which are called before suspend and after resume. This way we have a
normally functioning system when we are suspending and resuming the
panels.

This patch, I believe, creates a problem that somebody could enable or
disable a panel between PM_SUSPEND_PREPARE and the system suspend, and
similarly the other way around in resume. I choose to ignore the problem
for now, as it sounds rather unlikely, and if it happens, it's not
fatal.

In the long run the system suspend handling of omapdss and panels should
be thought out properly. The current approach feels rather hacky.
Perhaps the panel drivers should handle system suspend, or the users of
omapdss (omapfb, omapdrm) should handle system suspend.

Note that after this patch we could probably revert
0eaf9f52 (OMAPDSS: use sync versions of
pm_runtime_put). But as I said, this patch may be temporary, so let's
leave the sync version still in place.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reported-by: NJassi Brar <jaswinder.singh@linaro.org>
Tested-by: NJassi Brar <jaswinder.singh@linaro.org>

In preparation of OMAP moving to Common Clk Framework(CCF) change
clk_enable() and clk_disable() calls to clk_prepare_enable() and
clk_disable_unprepare() in omapdss. This can be safely done, as omapdss
never enables or disables clocks in atomic context.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: <linux-fbdev@vger.kernel.org>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Mike Turquette <mturquette@linaro.org>
[tomi.valkeinen@ti.com: updated patch description]
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Signed-off-by: NPeter Meerwald <pmeerw@pmeerw.net>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We have two almost the same enums: omap_channel and
omap_dss_overlay_managers. omap_channel is used almost everywhere, and
omap_channel assigns explicit values to the enum values which are needed
for proper operation.

omap_dss_overlay_managers is only used in one place, so it's easy to
remove it, which is what this patch does.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Merge v3.5-rc2 to get latest device tree and dynamic debug changes.

If the privileges given to root threads (3% of allowable memory) or a
negative value of /proc/pid/oom_score_adj happen to exceed the amount of
rss of a thread, its badness score overflows as a result of commit
a7f638f9 ("mm, oom: normalize oom scores to oom_score_adj scale only
for userspace").

Fix this by making the type signed and return 1, meaning the thread is
still eligible for kill, if the value is negative.
Reported-by: NDave Jones <davej@redhat.com>
Acked-by: NOleg Nesterov <oleg@redhat.com>
Signed-off-by: NDavid Rientjes <rientjes@google.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Pull scheduler fixes from Ingo Molnar.

* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  sched: Fix the relax_domain_level boot parameter
  sched: Validate assumptions in sched_init_numa()
  sched: Always initialize cpu-power
  sched: Fix domain iteration
  sched/rt: Fix lockdep annotation within find_lock_lowest_rq()
  sched/numa: Load balance between remote nodes
  sched/x86: Calculate booted cores after construction of sibling_mask

Fix lots of new kernel-doc warnings in kernel/sched/fair.c:

  Warning(kernel/sched/fair.c:3625): No description found for parameter 'env'
  Warning(kernel/sched/fair.c:3625): Excess function parameter 'sd' description in 'update_sg_lb_stats'
  Warning(kernel/sched/fair.c:3735): No description found for parameter 'env'
  Warning(kernel/sched/fair.c:3735): Excess function parameter 'sd' description in 'update_sd_pick_busiest'
  Warning(kernel/sched/fair.c:3735): Excess function parameter 'this_cpu' description in 'update_sd_pick_busiest'
  .. more warnings
Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This reverts commit 9e612a00.

It incorrectly finds VGA connectors where none are attached, apparently
not noticing that nothing replied to the EDID queries, and happily using
the default EDID modes that have nothing to do with actual hardware.

That in turn then causes X to fall down to the lowest common
denominator, which is usually the default 1024x768 mode that is in the
default EDID and pretty much anything supports).

I'd suggest that if not relying on the HDP pin, the code should at least
check whether it gets valid EDID data back, rather than just assume
there's something on the VGA connector.

Cc: Dave Airlie <airlied@linux.ie>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Pull ext4 bug fixes from Theodore Ts'o:
 "This update contains two bug fixes, both destined for the stable tree.
  Perhaps the most important is one which fixes ext4 when used with file
  systems originally formatted for use with ext3, but then later
  converted to take advantage of ext4."

* tag 'ext4_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4:
  ext4: don't set i_flags in EXT4_IOC_SETFLAGS
  ext4: fix the free blocks calculation for ext3 file systems w/ uninit_bg

Pull powerpc fixes from Paul Mackerras:
 "Two small fixes for powerpc:
   - a fix for a regression since 3.2 that causes 4-second (or longer)
     pauses
   - a fix for a potential oops when loading kernel modules on 32-bit
     embedded systems."

* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc:
  powerpc: Fix kernel panic during kernel module load
  powerpc/time: Sanity check of decrementer expiration is necessary

Pull UBI/UBIFS fixes from Artem Bityutskiy:
 "Fix UBI and UBIFS - they refuse to work without debugfs.  This was
  broken by the 3.5-rc1 UBI/UBIFS changes when we removed the debugging
  Kconfig switches.

  Also, correct locking in 'ubi_wl_flush()' - it was extended to support
  flushing a specific LEB in 3.5-rc1, and the locking was sub-optimal."

* tag 'upstream-3.5-rc2' of git://git.infradead.org/linux-ubifs:
  UBI: correct ubi_wl_flush locking
  UBIFS: fix debugfs-less systems support
  UBI: fix debugfs-less systems support