drm/nouveau/therm: reduce stack usage of nouveau_therm_ic_ctor

Before: 1496 bytes
After:   152 bytes

Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/therm: use workqueue to shutdown the machine

orderly_poweroff cannot be called from atomic context.

Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Acked-by: Martin Peres <martin.peres@labri.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nv40/therm: reset temperature sensor on init

Current uninitialized sensor detection does not work for me on nv4b and
sensor returns crazy values (>190°C). It stabilises later, but it's too
late - therm code shutdowns the machine...

Let's just reset it on init.

Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Acked-by: Martin Peres <martin.peres@labri.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/therm: turn on fan only when threshold hit in positive direction

+ the same for shutdown threshold - seems impossible, but shutdown can fail.

Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Acked-by: Martin Peres <martin.peres@labri.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau: report channel owner in ioctl error paths

Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/therm: always initialize alarm_program_lock

Fixes "BUG: spinlock bad magic" on module load for nva3+ cards.

Introduced in commit "drm/nouveau/therm: implement support for temperature
alarms".

Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau: handle backlight_device_register failure

Found by smatch.

Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau: use kmemdup for edid allocation/copying

Avoids potential null pointer dereference.

Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau: use drm_property_create_range helper

Avoids potential null pointer dereference.

Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau: remove unnecessary null pointer check from nouveau_fence_new

the variable chan is dereferenced in line 190, so it is no reason to check
null again in line 198.

Signed-off-by: Cong Ding <dinggnu@gmail.com>
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nvc0/graph: remove redundant null checks

It's safe to call kfree(NULL).

Found by smatch.

Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fan: fix selection of fan speed when fan->get returns an error

fan->get returns int, but we write it to unsigned variable, and then check
whether it's >= 0 (it always is)

Found by smatch:
drivers/gpu/drm/nouveau/core/subdev/therm/fan.c:61 nouveau_fan_update() warn: always true condition '(duty >= 0) => (0-u32max >= 0)'

Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau: quiet static-related sparse noise

Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/bios: tiny debugging messages fixes

COPY_ZM_REG: destination and source addresses were swapped
RAM_RESTRICT_ZM_REG_GROUP: missing 0x prefix for register address

Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau: mark nv_printk_ as printf-like function

...and fix all warnings

Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau: share fence structures between nv10+ and nv50 implementations

We already rely on them having the same fields and layout.

Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fan: handle the cases where we are outside of the linear zone

This fixes a bug where, when temperature is outside of the linear range, fan
pwm would be outside of the allowed range ([0, 100]) and could get negative in
some cases.

It seems like a regression that happened when we re-worked the fan management
logic before merging.

Tested-by: Ozan Çağlayan <ozancag@gmail.com>
Signed-off-by: Martin Peres <martin.peres@labri.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau: report channel owner in error messages

Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau: prepare for reporting channel owner

- record channel owner process name
- add some helpers for accessing this information
- let nouveau_enum hold additional value (will be needed in the next patch)

Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau: use pr_cont

Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau: split fifo interrupt handler

Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/therm: force a minimum hysteresis on temperature alarm thresholds

This should avoid the situation where a user gets its kernel logs flooded when
temperature oscillates around a threshold with 0°C hysteresis.

This patch is just meant to fix broken vbios (as reported on a nv4e on
sysfs hwmon interface.

Signed-off-by: Martin Peres <martin.peres@labri.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau: set legacy bios data before parsing the structure

Commit 767baf82 drm/nouveau: remove some more unnecessary legacy bios code

has introduced a regression my misplacing the code that sets the major/chip
versions, which are used whist parsing the bmp/bit structure in vbios

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/therm: don't try pwm/toggle control if GPIO_FAN is input

My GTX660 has the GPIO_FAN function, but it's configured in input-mode;
presumably to monitor the frequency set by an I2C fan controller?

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/bios: rename DCB_GPIO_PWM_FAN to DCB_GPIO_FAN

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/bios: add support for parsing xpio table data

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau: remove some more unnecessary legacy bios code

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau: remove legacy vbios type detection

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/hwmon: create hwmon attributes under hwmon device in sysfs

From browsing my /sys, a few other things seem to do this, and it looks
cleaner this way too :)

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/hwmon: s/fan0/fan1/

Fan speed info now shown by sensors.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/therm: better transitions and debug logging

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Martin Peres <martin.peres@labri.fr>

drm/nouveau/doc: document the sysfs thermal management interface

Signed-off-by: Martin Peres <martin.peres@labri.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/hwmon: add missing alarm thresholds

Expose all the hysteresis parameters + shutdown (emergency) +
fan_boost (fixed pwm trip point).

Signed-off-by: Martin Peres <martin.peres@labri.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/therm: implement support for temperature alarms

For now, we only boost the fan speed to the maximum and auto-mode
when hitting the FAN_BOOST threshold and halt the computer when it
reaches the shutdown temperature. The downclock and critical thresholds
do nothing.

On nv43:50 and nva3+, temperature is polled because of the limited hardware.
I'll improve the nva3+ situation by implementing alarm management in PDAEMON
whenever I can but polling once every second shouldn't be such a problem.

v2 (Ben Skeggs):
- rebased

v3: fixed false-detections and threshold reprogrammation handling on nv50:nvc0

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Martin Peres <martin.peres@labri.fr>

drm/nv41/bus: report useful data on mmio fault

Based on Ben Skeggs's nvc0 patch. Tested on my nv4b, 84 and 92.

Signed-off-by: Martin Peres <martin.peres@labri.fr>

drm/nvc0/bus: report useful data on mmio fault

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/pbus: add a PBUS subdev that hands IRQs to the right subdevs

We are going to use PTHERM's IRQs for thermal monitoring but we need to route
them first.

On nv31-50, PBUS's IRQ line is shared with GPIOs IRQs.

It seems like nv10-31 GPIO interruptions aren't well handled. I kept the
original behaviour but it is wrong and may lead to an IRQ storm.

Since we enable all PBUS IRQs, we need a way to avoid being stormed if we
don't handle them. The solution I used was to mask the IRQs that have not been
handled. This will also print one message in the logs to let us know.

v2: drop the shared intr handler because of was racy
v3: style fixes
v4: drop a useless construct in the chipset-dependent INTR
v5: add BUS to the disable mask
v6 (Ben Skeggs):
- general tidy to match the rest of the driver's style
- nva3->nvc0, nva3 can be serviced just fine with nv50.c, rnndb even notes
  that the THERM_ALARM bit got left in the hw until fermi anyway.. so, it's
  not going to conflict
- removed the peephole and user stuff, for the moment.. will handle them
  later if we find a good reason to actually care..
- limited INTR_EN to just what we can handle for now, mostly to prevent
  spam of unknown status bits (seen on at least nv4x)

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Martin Peres <martin.peres@labri.fr>

drm/nouveau/therm: implement automatic fan management

v2: improved design but drops safety monitoring (to be in a later patch)
v3: fix locking and mode management
v4: gently fallback to the no-control mode when temperature cannot be got
    and use kernel-provided min/max macros
v5 (Ben Skeggs):
- rebased on my previous patches
v6: fix hysterisis management in trip-based auto fan management

This commit also forbids access to fan management to nvc0+ chipsets as
fan management is already taken care of my PDAEMON's default fw.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Martin Peres <martin.peres@labri.fr>

drm/nouveau/fan: obey fan bump/slow periods as defined by vbios

v2 (Ben Skeggs):
- split from larger patch
- fixed to not require alarm resched patch

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Martin Peres <martin.peres@labri.fr>

drm/nouveau/bios: parse fan bump/slow periods, and trip points

Signed-off-by: Martin Peres <martin.peres@labri.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fan: add toggle fan support

v2: change percent from int to atomic_t
v3: random fixes
v4 (Ben Skeggs):
- adapted for split-out fan-control "protocol" structure
- removed need for timer resched
- support for forcing 'toggle' control on PWM boards

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Martin Peres <martin.peres@labri.fr>

drm/nouveau/therm: cleanly separate pwm control logic from therm

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Martin Peres <martin.peres@labri.fr>

drm/nouveau/therm: add interfaces to allow forcing off pwm fan control

Mostly to allow for the possibility of testing 'toggle' fan control easily.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Martin Peres <martin.peres@labri.fr>

drm/nvd0/therm: add support for hardware fan tachometer

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nva3/therm: add support for hardware fan tachometer

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/therm: collect fan tach info in common fan constructor

This info will be used by two more implementations in upcoming commits.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Martin Peres <martin.peres@labri.fr>

drm/nouveau/therm: fix various style issues, make more consistent

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Martin Peres <martin.peres@labri.fr>

nvd0/therm: implement more appropriate pwm fan control functions

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-next

So here's my promised pile of fixes for 3.9. I've dropped the core prep
patches for vt-switchless suspend/resume as discussed on irc. Highlights:
- Fix dmar on g4x. Not really gfx related, but I'm fed up with getting
  blamed for dmar crapouts.
- Disable wc ptes updates on ilk when dmar is enabled (Chris). So again,
  dmar, but this time gfx related :(
- Reduced range support for hsw, using the pipe CSC (Ville).
- Fixup pll limits for gen3/4 (Patrick Jakobsson). The sdvo patch is
  already confirmed to fix 2 bug reports, so added cc: stable on that one.
- Regression fix for 8bit fb console (Ville).
- Preserve lane reversal bits on DDI/FDI ports (Damien).
- Page flip vs. gpu hang fixes (Ville). Unfortuntely not quite all of
  them, need to decide what to do with the currently still in-flight ones.
- Panel fitter regression fix from Mika Kuoppala (was accidentally left on
  on some pipes with the new modset code since 3.7). This also improves
  the modeset sequence and might help a few other unrelated issues with
  lvds.
- Write backlight regs even harder ... another installement in our eternal
  fight against the BIOS and backlights.
- Fixup lid notifier vs. suspend/resume races (Zhang Rui). Prep work for
  new ACPI stuff, but closing the race itself seems worthwile on its own.
- A few other small fixes and tiny cleanups all over.

Lots of the patches are cc: stable since I've stalled on a few
not-so-important fixes for 3.8 due to the grumpy noise Linus made.

* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel: (33 commits)
  intel/iommu: force writebuffer-flush quirk on Gen 4 Chipsets
  drm/i915: Disable WC PTE updates to w/a buggy IOMMU on ILK
  drm/i915: Implement pipe CSC based limited range RGB output
  drm/i915: inverted brightness quirk for Acer Aspire 4736Z
  drm/i915: Print the hw context status is debugfs
  drm/i915: Use HAS_L3_GPU_CACHE in i915_gem_l3_remap
  drm/i915: Fix PIPE_CONTROL DW/QW write through global GTT on IVB+
  drm/i915: Set i9xx sdvo clock limits according to specifications
  drm/i915: Set i9xx lvds clock limits according to specifications
  drm/i915: Preserve the DDI link reversal configuration
  drm/i915: Preserve the FDI line reversal override bit on CPT
  drm/i915: add missing \n to UTS_RELEASE in the error_state
  drm: Use C8 instead of RGB332 when determining the format from depth/bpp
  drm: Fill depth/bits_per_pixel for C8 format
  drm/i915: don't clflush gem objects in stolen memory
  drm/i915: Don't wait for page flips if there was GPU reset
  drm/i915: Kill obj->pending_flip
  drm/i915: Fix a typo in a intel_modeset_stage_output_state() comment
  drm/i915: remove bogus mutex_unlock from error-path
  drm/i915: Print the pipe control page GTT address
  ...

intel/iommu: force writebuffer-flush quirk on Gen 4 Chipsets

We already have the quirk entry for the mobile platform, but also
reports on some desktop versions. So be paranoid and set it
everywhere.

References: http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg33138.html
Cc: stable@vger.kernel.org
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: "Sankaran, Rajesh" <rajesh.sankaran@intel.com>
Reported-and-tested-by: Mihai Moldovan <ionic@ionic.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Disable WC PTE updates to w/a buggy IOMMU on ILK

Whilst IOMMU is enabled for the Intel GPU on Ironlake, it appears that
using WC writes to update the PTE on the GPU fails miserably. The
result looks like the majority of the writes do not land leading to
lots of screen corruption and a hard system hang.

v2: s/</<=/ to preserve the current exclusion of Sandybridge

Reported-by: Nathan Myers <ncm@cantrip.org>
Bugzilla: https://bugzilla.freedesktop.org/show_bug.cgi?id=60391
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Nathan Myers <ncm@cantrip.org>
[danvet: Remove cc: stable and add tested-by.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Implement pipe CSC based limited range RGB output

HSW no longer has the PIPECONF bit for limited range RGB output.
Instead the pipe CSC unit must be used to perform that task.

The CSC pre offset are set to 0, since the incoming data is full
[0:255] range RGB, the coefficients are programmed to compress the
data into [0:219] range, and then we use either the CSC_MODE black
screen offset bit, or the CSC post offsets to shift the data to
the correct [16:235] range.

Also have to change the confiuration of all planes so that the
data is sent through the pipe CSC unit. For simplicity send the
plane data through the pipe CSC unit always, and in case full
range output is requested, the pipe CSC unit is set up with an
identity transform to pass the plane data through unchanged.

I've been told by some hardware people that the use of the pipe
CSC unit shouldn't result in any measurable increase in power
consumption numbers.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: inverted brightness quirk for Acer Aspire 4736Z

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=53881
Cc: stable@vger.kernel.org
Cc: Jani Nikula <jani.nikula@intel.com>
Tested-by: Jani Monoses <jani@ubuntu.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Print the hw context status is debugfs

Print out the HW context object information per ring. Even though the
existing code only utilizes the render ring, it's simple enough to
support future expansion.

I had this in a patch somewhere in a rev of the original implementation,
but I must have lost it.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: s/context/default context/ bikeshed applied.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Use HAS_L3_GPU_CACHE in i915_gem_l3_remap

Yet another remnant ... this might explain why l3 remapping didn't
really work on HSW.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57441
Spotted-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fix PIPE_CONTROL DW/QW write through global GTT on IVB+

The bit controlling whether PIPE_CONTROL DW/QW write targets
the global GTT or PPGTT moved moved from DW 2 bit 2 to
DW 1 bit 24 on IVB.

I verified on IVB that the fix is in fact effective. Without the fix
none of the scratch writes actually landed in the pipe control page.
With the fix the writes show up correctly.

v2: move PIPE_CONTROL_GLOBAL_GTT_IVB setup to where other flags are set

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Set i9xx sdvo clock limits according to specifications

The Intel PRM says the M1 and M2 divisors must be in the range of 10-20 and 5-9.
Since we do all calculations based on them being register values (which are
subtracted by 2) we need to specify them accordingly.

Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56359
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Set i9xx lvds clock limits according to specifications

The Intel PRM says the M1 and M2 divisors must be in the range of 10-20 and 5-9.
Since we do all calculations based on them being register values (which are
subtracted by 2) we need to specify them accordingly.

Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Preserve the DDI link reversal configuration

Similarly to:

  commit 6a0d1df3d3a0d2370541164eb0595fe35dcd6de3
  Author: Damien Lespiau <damien.lespiau@intel.com>
  Date:   Tue Dec 11 15:18:28 2012 +0000

      drm/i915: Preserve the FDI line reversal override bit on CPT

DDI port support lane reversal to easy the PCB layouting work. Let's
preserve the bit configured by the BIOS (until we find how to correctly
retrieve the information from the VBT, but this does sound more fragile
then just relying on the BIOS that has, hopefully, been validated
already.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Preserve the FDI line reversal override bit on CPT

The FDI link has supported link reversal to make the PCB layout
engineer's life easier for quite a while and we have always presered
this bit as we programmed FDI_RX_CTL with a read/modify/write sequence.

We're trying to take a bit more control over what the BIOS leaves in
various register and with the introduction of DDI, started to program
FDI_RX_CTL fully.

There's a fused bit to indicate DMI link reversal and FDI defaults to
mirroring that configuration. We have a bit to override that behaviour
that we need to preserve from the BIOS.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add missing \n to UTS_RELEASE in the error_state

Amending
commit 4518f611ba21ba165ea3714055938a8984a44ff9
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Jan 23 16:16:35 2013 +0100

    drm/i915: dump UTS_RELEASE into the error_state

CC: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Use C8 instead of RGB332 when determining the format from depth/bpp

Support for real RGB332 is a rarity, most hardware only really support
C8. So use C8 instead of RGB332 when determining the format based on
depth/bpp.

This fixes 8bpp fbcon on i915, since i915 will only accept C8 and not
RGB332.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59572
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Tested-by: mlsemon35@gmail.com
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Fill depth/bits_per_pixel for C8 format

Set depth/bits_per_pixel to 8 for C8 format.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: don't clflush gem objects in stolen memory

As explained by Chris Wilson gem objects in stolen memory are always
coherent with the GPU so we don't need to ever flush the CPU caches for
these.

This fixes a breakage - at least with the compact sg patches applied -
during the resume/restore gtt mappings path, when we tried to clflush an
FB object in stolen memory, but since stolen objects don't have backing
pages we passed an invalid page pointer to drm_clflush_page().

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Don't wait for page flips if there was GPU reset

If a GPU reset occurs while a page flip has been submitted to the ring,
the flip will never complete once the ring has been reset.

The GPU reset can be detected by sampling the reset_counter before the
flip is submitted, and then while waiting for the flip, the sampled
counter is compared with the current reset_counter value.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: Move the reset_counter assignment to an earlier place in
common code as discussed on the mailing list.]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60140
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Kill obj->pending_flip

The pending flip mask no longer set anywhere, so trying to wait for
while it's non-zero is a no-op. Remove it completely.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fix a typo in a intel_modeset_stage_output_state() comment

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: remove bogus mutex_unlock from error-path

This has been lost in the locking rework for intel_alloc_context_page:

commit 2c34b850ee1e9f86b41706149d0954eee58757a3
Author: Ben Widawsky <ben@bwidawsk.net>
Date:   Sat Mar 19 18:14:26 2011 -0700

    drm/i915: fix ilk rc6 teardown locking

Cc: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Print the pipe control page GTT address

We already print the HWS addresses during init, so do the same for the
pipe control page. Reduces guesswork when looking at hex addresses
later.

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

drm/i915: clean up panel fitter handling in lvds

With the previous patch "drm/i915: disable shared panel fitter for
pipe" we now disable the panel fitter at the right spot in the modeset
sequence in the crtc functions on all platforms. Hence the disabling
in intel_disable_lvds is no longer required and potentially harmful
(since the plane is still enabled at this point).

Similarly on the enabling side we enable the panel fitter in the lvds
callback only once the plane is enabled. Which is too late. Hence move
this into a new intel_pre_enable_lvds callback.

Finally we can ditch lvds_encoder->pfit_dirty - this was required to
work around the crtc helper semantics, but with the new i915 modeset
infrastructure we should enable/disable the pfit only when enabling or
disabling the entire output pipeline. So separate state tracking for
the pfit is no longer required.

Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
[danvet: Bikeshed the commit message a bit to stress that now we
enable/disable the pfit on i9xx platforms at the right point of time
compared to the old code.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: disable shared panel fitter for pipe

If encoder is switched off by BIOS, but the panel fitter is left on,
we never try to turn off the panel fitter and leave it still attached
to the pipe - which can cause blurry output elsewhere.

Based on work by Chris Wilson <chris@chris-wilson.co.uk>

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58867
Cc: stable@vger.kernel.org
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Tested-by: Andreas Sturmlechner <andreas.sturmlechner@gmail.com>
[danvet: Remove the redundant HAS_PCH_SPLIT check and add a tiny
comment.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: detect wrong MCH watermark values

Some early bios versions seem to ship with the wrong tuning values for
the MCH, possible resulting in pipe underruns under load. Especially
on DP outputs this can lead to black screen, since DP really doesn't
like an occasional whack from an underrun.

Unfortunately the registers seem to be locked after boot, so the only
thing we can do is politely point out issues and suggest a BIOS
upgrade.

Arthur Runyan pointed us at this issue while discussion DP bugs - thus
far no confirmation from a bug report yet that it helps. But at least
some of my machines here have wrong values, so this might be useful in
understanding bug reports.

v2: After a bit more discussion with Art and Ben we've decided to only
the check the watermark values, since the OREF ones could be be a
notch more aggressive on certain machines.

Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Runyan, Arthur J <arthur.j.runyan@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/tilcdc: add support for LCD panels (v5)

Add an output panel driver for LCD panels.  Tested with LCD3 cape on
beaglebone.

v1: original
v2: s/of_find_node_by_name()/of_get_child_by_name()/ from Pantelis
    Antoniou
v3: add backlight support
v4: rebase to latest of video timing helpers
v5: remove some unneeded fields from panel-info struct, add DT bindings
    docs

Signed-off-by: Rob Clark <robdclark@gmail.com>
Tested-by: Koen Kooi <koen@dominion.thruhere.net>

drm/tilcdc: add encoder slave (v2)

Add output panel driver for i2c encoder slaves.

v1: original
v2: add DT bindings docs, and minor updates for review comments

Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: Koen Kooi <koen@dominion.thruhere.net>

drm/i2c: nxp-tda998x (v3)

Driver for the NXP TDA998X i2c hdmi encoder slave.

v1: original
v2: fix npix/nline programming
v3: add Kconfig, fix dup'd MODULE_DESCRIPTION

Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: Koen Kooi <koen@dominion.thruhere.net>

drm/tilcdc: add TI LCD Controller DRM driver (v4)

A simple DRM/KMS driver for the TI LCD Controller found in various
smaller TI parts (AM33xx, OMAPL138, etc).  This driver uses the
CMA helpers.  Currently only the TFP410 DVI encoder is supported
(tested with beaglebone + DVI cape).  There are also various LCD
displays, for which support can be added (as I get hw to test on),
and an external i2c HDMI encoder found on some boards.

The display controller supports a single CRTC.  And the encoder+
connector are split out into sub-devices.  Depending on which LCD
or external encoder is actually present, the appropriate output
module(s) will be loaded.

v1: original
v2: fix fb refcnting and few other cleanups
v3: get +/- vsync/hsync from timings rather than panel-info, add
    option DT max-bandwidth field so driver doesn't attempt to
    pick a display mode with too high memory bandwidth, and other
    small cleanups
v4: remove some unneeded stuff from panel-info struct, properly
    set high bits for hfp/hsw/hbp for rev 2, add DT bindings docs

Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: Koen Kooi <koen@dominion.thruhere.net>

drm: Don't set the plane->fb to NULL on successfull set_plane

We need to clear the local variable to get the refcounting right
(since the reference drm_mode_setplane holds is transferred to the
plane->fb pointer). But should be done _after_ we update the pointer.

Breakage introduced in

commit 6c2a75325c800de286166c693e0cd33c3a1c5ec8
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Dec 11 00:59:24 2012 +0100

    drm: refcounting for sprite framebuffers

Reported-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Rob Clark <rob@ti.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Thierry Reding <thierry.reding@avionic-design.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: don't add inferred modes for monitors that don't support them

If bit 0 of the features byte (0x18) is set to 0, then, according to
the EDID spec, "the display is non-continuous frequency (multi-mode)
and is only specified to accept the video timing formats that are
listed in Base EDID and certain Extension Blocks".

For more information, please see the EDID spec, check the notes of the
table that explains the "Feature Support" byte (18h) and also the
notes on the tables of the section that explains "Display Range Limits
& Additional Timing Description Definition (tag #FDh)".

Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45729
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/cma-helper: fixup compilation

/me grabs a few brown paper bags

So it looks like I've broken compilation in

commit 6aed8ec3f76a22217c9ae183d32b1aa990bed069
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun Jan 20 17:32:21 2013 +0100

    drm: review locking for drm_fb_helper_restore_fbdev_mode

Fix it up again.

v2: Only deref fbdev_cma once we're sure it's non-NULL, noticed by
Thierry Reding.

Reported-by: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Thierry Reding <thierry.reding@avionic-design.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge branch 'omapdrm-next' of git://people.freedesktop.org/~robclark/linux into drm-next

* 'omapdrm-next' of git://people.freedesktop.org/~robclark/linux:
  drm/omap: remove fbdev debug enter/leave hooks
  omapdrm: simplify locking in the fb debugfs file
  omapdrm: only take crtc->mutex in crtc callbacks
  drm/omap: move out of staging
  staging/omapdrm: Use kmemdup rather than duplicating its implementation
  staging: omapdrm/omap_gem_dmabuf.c: fix memory leakage
  drm/omap: Add OMAP5 support
  drm/omap: Add PM capabilities

drm/nouveau: use i2c encoder helper wrappers

Signed-off-by: Rob Clark <robdclark@gmail.com>

drm: i2c encoder helper wrappers

Simplify life for drivers using an encoder-slave, so that they can make
their drm_encoder_helper_funcs const, rather than needing to dynamically
allocate and populate them.

Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/cma: add debugfs helpers

Add helper to display fb's which can be used directly in drm_info_list:

static struct drm_info_list foo_debugfs_list[] = {
...
{ "fb",   drm_fb_cma_debugfs_show, 0 },
};

to display information about CMA fb objects, as well as a
drm_gem_cma_describe() which can be used if the driver bothers to keep
a list of CMA GEM objects.

Signed-off-by: Rob Clark <robdclark@gmail.com>

drm: small fix in drm_send_vblank_event()

Initialize e->pipe.. some drivers set this themselves, others do not.
Setting it in drm_send_vblank_event() should help ensure more consistent
behavior with the different drivers.

Signed-off-by: Rob Clark <robdclark@gmail.com>

drm: Don't set the plane->fb to NULL on successfull set_plane

We need to clear the local variable to get the refcounting right
(since the reference drm_mode_setplane holds is transferred to the
plane->fb pointer). But should be done _after_ we update the pointer.

Breakage introduced in

commit 6c2a75325c800de286166c693e0cd33c3a1c5ec8
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Dec 11 00:59:24 2012 +0100

    drm: refcounting for sprite framebuffers

Reported-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Rob Clark <rob@ti.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/cma-helper: fixup compilation

/me grabs a few brown paper bags

So it looks like I've broken compilation in

commit 6aed8ec3f76a22217c9ae183d32b1aa990bed069
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun Jan 20 17:32:21 2013 +0100

    drm: review locking for drm_fb_helper_restore_fbdev_mode

Fix it up again.

Reported-by: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/omap: remove fbdev debug enter/leave hooks

This will result in badness for drivers that do not implement
mode_set_base_atomic().  So don't pretend like we can support this.

Signed-off-by: Rob Clark <robdclark@gmail.com>

omapdrm: simplify locking in the fb debugfs file

We don't need to hold onto mode_config.mutex any more to keep the fb
objects around. And locking dev->struct_mutex is also not required,
since omap_gem_describe only reads data anyway. And for a debug
interface it's better to grab fewer locks in case the driver is
deadlocked already ...

The only thing we need is to hold onto mode_config.fb_lock to ensure
the user-created fbs don't disappear. The fbcon fb doesn't need any
protection, since it lives as long as the driver (and so the debugfs
files) itself. And if the teardown/setup isn't following the right
sequence grabbing locks won't prevent a NULL deref on priv->fbdev if
the fb is not yet (or no longer) there.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Rob Clark <robdclark@gmail.com>

omapdrm: only take crtc->mutex in crtc callbacks

Omapdrm doesn't do anything nefarious with crtc load detection or has
any shared resources, so this is enough. We also need to adjust the
WARN_ON.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/omap: move out of staging

Now that the omapdss interface has been reworked so that omapdrm can use
dispc directly, we have been able to fix the remaining functional kms
issues with omapdrm.  And in the mean time the PM sequencing and many
other of that open issues have been solved.  So I think it makes sense
to finally move omapdrm out of staging.

Signed-off-by: Rob Clark <robdclark@gmail.com>

staging/omapdrm: Use kmemdup rather than duplicating its implementation

Found with coccicheck.
The semantic patch that makes this change is available
in scripts/coccinelle/api/memdup.cocci.

Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: Rob Clark <rob@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: omapdrm/omap_gem_dmabuf.c: fix memory leakage

There is a memory leakage in variable sg if it goes to error.

Signed-off-by: Cong Ding <dinggnu@gmail.com>
Signed-off-by: Rob Clark <rob@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/omap: Add OMAP5 support

Add support for OMAP5 processor.  The main differences are that the OMAP5
has 2 containers, one for 1D and one for 2D.  Each container is 128MiB in
size.

Signed-off-by: Andy Gross <andy.gross@ti.com>
Signed-off-by: Rob Clark <rob@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/omap: Add PM capabilities

Added power management capabilities into the omapdrm and DMM drivers.
During suspend, we don't need to do anything to maintain the state of
the LUT.  We have all the necessary information to recreate the mappings
of the GEM object list maintained by the omapdrm driver.

On resume, the DMM resume handler will first reprogram the LUT to point
to the dummy page.  The subsequent resume handler in the omapdrm will call
into the DMM and reprogram each of the buffer objects.  This will ensure
that all of the necessary objects will be pinned into the DMM properly.

Order of suspend/resume handlers is done by device creation.  We create
the DMM device before the omapdrm, so the correct order is maintained.

Signed-off-by: Andy Gross <andy.gross@ti.com>
Signed-off-by: Rob Clark <rob@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/i915/ctx: Remove bad invariant

It's not that the assertion is incorrect, but rather that we can call
do_destroy early in loading, and we will falsely BUG().

Since contexts have been in for a while now, and in the internal APIs
are pretty stable, it should be fairly safe to remove this.

v2: Remove unused dev_priv, and dev

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Extract ring init from hw_init

The ring initialization will differ a bit in upcoming generations, and
this split will prepare the code for what's needed.

This patch also fixes a bug introduced in:
commit 99433931950f33039d9e1a52b4ed9af3f1b58e84
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date:   Tue Jan 22 14:12:17 2013 +0200

    drm/i915: use gem_set_seqno() on hardware init

After doing the extraction, the bad error handling became obvious.  I
acknowledge that this should be two patches, but it's a pretty
small/trivial patch. If requested, I can certainly do the fix as a
distinct patch.

v2: Should be cleanup blt, not init blt on failure (Chris)

v3: Forgot to git add on v2

Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fix gen2 mappable calculations

When I refactored the code initially, I forgot that gen2 uses a
different bar for the CPU mappable aperture. The agp-less code knows
nothing of generations less than 5, so we have to expand the gtt_probe
function to include the mappable base and end.

It was originally broken by me:
commit baa09f5fd8a6d033ec075355dda99a65b7f6a0f3
Author: Ben Widawsky <ben@bwidawsk.net>
Date:   Thu Jan 24 13:49:57 2013 -0800

    drm/i915: Add probe and remove to the gtt ops

Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add ibx_irq_postinstall

So we can remove duplicated code. Note that this function is used not
only on IBX, but also CPT and LPT.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Also bikeshed s/ironlake_enable_pch_hotplug/ibx_enable_hotplug
to keep consistent with our ibx for pch naming scheme.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fix sprite_scaling_enabled for multiple sprites

We have more than one sprite, so a boolean simply won't cut it.
Turn sprite_scaling_enabled into a bitmask and track the state
of sprite scaler for each sprite independently.

Also don't re-enable LP watermarks until the sprite registers
have actually been written, and thus sprite scaling has really
been disabled.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: unify HDMI/DP hpd definitions

They're physically the same pins and also the same bits, duplicating
only confuses the reader. This also makes it a bit obvious that we
have quite some code duplication going on here. Squashing that is for
a larger rework in our hpd handling though.

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