Removes some functions that are not used anywhere:
nv04_display_late_takedown() nv04_display_early_init()

This was partially found by using a static code analysis program
called cppcheck.
Signed-off-by: NRickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Remove the function domain_to_ttm() that is not used anywhere.

This was partially found by using a static code analysis program
called cppcheck.
Signed-off-by: NRickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Remove the function nouveau_bo_rd16() that is not used anywhere.

This was partially found by using a static code analysis program
called cppcheck.
Signed-off-by: NRickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This patch adds one option for the boot config strings "NvClkMode*", so
that we can enable the "auto" mode when loading module.
Signed-off-by: NVince Hsu <vinceh@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This patch adds PWR support for GK20A. But instead of adding the PWR
features like firmware loading and communication with PMU firmware, we
add the DVFS (Dynamic Voltage and Frequency Scaling), which is one of
the PMU firmware's jobs on dGPUs, in this patch. This refers to the
idle signals provided by the NVIDIA hardware and tries to adjust the
performance level based on the calculated target. The reclocking policy
can be fine-tuned later when we have more real use cases.
Signed-off-by: NVince Hsu <vinceh@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The platform device does not use the common nouveau_pwr_init() to initialize
the PWR, but it does need the .pgob() be assigned to avoid NULL pointer
dereference in graph/nve4.c.
Signed-off-by: NVince Hsu <vinceh@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

There might be some callers of nouveau_clock_astate(), and they are from
inetrrupt context. So we must ensure that this function can be atomic in
that condition. This patch adds one parameter which is subsequently passed
to nouveau_pstate_calc(). Therefore we can choose whether we want to wait
for the pstate work's completion or not.
Signed-off-by: NVince Hsu <vinceh@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Several braces were misplaced unintentionally. That caused the msi handling
became part of the default case of the first switch statement. So add the
missing ones.
Signed-off-by: NVince Hsu <vinceh@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Looks like a userspace bug can trigger this somehow during a mode
switch, causing: EVO complaint -> semaphores get out of sync ->
entire display stalled.

We likely want to be even stricter than this (or at least deal
better if EVO rejects our request), but I'll save that for the
drm_plane/atomic conversion and just fix the bug that I already
know can be triggered.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

On NV50 and up, we'll allow fixed panels to use EDID-provided modes
without the GPU scaler, and force scaling (even for NONE) otherwise.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Should be the same defaults as before, just easier to follow.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

The hilarious part is that, under X, this won't work anyway because the
server decides to construct its own modes for some reason.

Tested with modetest, which isn't quite as insane.  I'd hope that
wayland is more sensible.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

Common programming sense dictates that resources allocated by a function
are freed by this function should it fails, but this is not the case for
the allocated structure of nouveau_sgdma_create_ttm(). It seems that
n00b contributors attempt to fix this one like bugs flying towards a bug
zapper, so add a comment to hopefully prevent this from happening
anymore.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

nouveau_sgdma_be::dev is only set once during init and never used
anywhere, so remove it.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

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

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

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

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

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

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

It's about to not be valid for objects that aren't in the client
object tree.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

These are a tad more complex than a direct cast with paranoia safeties.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The [  SUBDEV] specified in log output will be a bit different for
children of a subdev now.  Previously this reports whatever subdev
is specified by object.engine, now it reports the subdev that owns
the object (so, up object.parent somewhere).

Later patches will append object and class identifiers to messages,
which will help clarify where it's coming from.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Makes the output slightly less useful, in that objects with the same
class handle can't be distinguished from each other now.

Upcoming commits will name objects with user-readable strings to fix
this problem.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

gpuobj has a condition of (bar && bar->alloc) around usage to avoid
some nasty ordering issues (which, i've now been reminded to add a
todo about fixing...) between bar and vm.

The bar->alloc part of the condition isn't currently necessary (it
used to be, another change made bar always NULL where it matters),
so we got lucky.  That won't be the case for much longer.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

Makes things a bit more readable.  This is specially important now as
upcoming commits are going to be gradually removing the use of macros
for down-casts, in favour of compile-time checking.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Has additional safeties for one.  For two, needed for an upcoming
commit that removes abuse of nouveau_object.engine.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

The Atmel HLCDC (HLCD Controller) IP available on some Atmel SoCs (i.e.
at91sam9n12, at91sam9x5 family or sama5d3 family) provides a display
controller device.

This display controller supports at least one primary plane and might
provide several overlays and an hardware cursor depending on the IP
version.

At the moment, this driver only implements an RGB connector to interface
with LCD panels, but support for other kind of external devices might be
added later.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: NRob Clark <robdclark@gmail.com>
Tested-by: NAnthony Harivel <anthony.harivel@emtrion.de>
Tested-by: NLudovic Desroches <ludovic.desroches@atmel.com>
Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com>

Foxlink's fl500wvr00-a0t supports RGB888 format.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: NThierry Reding <treding@nvidia.com>

Provide a way to specify panel requirement in terms of supported media bus
format (particularly useful for panels connected to an RGB or LVDS bus).
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: NThierry Reding <treding@nvidia.com>

Add bus_formats and num_bus_formats fields and
drm_display_info_set_bus_formats helper function to specify the bus
formats supported by a given display.

This information can be used by display controller drivers to configure
the output interface appropriately (i.e. RGB565, RGB666 or RGB888 on raw
RGB or LVDS busses).
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Acked-by: NThierry Reding <treding@nvidia.com>

There are still some places in the fb helper that need to avoid
sleeping in panic context. Here's an example:

[   65.615496] bad: scheduling from the idle thread!
[   65.620747] CPU: 92 PID: 0 Comm: swapper/92 Tainted: G   M        E  3.18.0-rc4-7-default+ #20

[   65.630364] Hardware name: Intel Corporation BRICKLAND/BRICKLAND, BIOS
BRHSXSD1.86B.0056.R01.1409242327 09/24/2014
[   65.641923]  ffff88087f693d80 ffff88087f689878 ffffffff81566db9 0000000000000000
[   65.650226]  ffff88087f693d80 ffff88087f689898 ffffffff810871ff ffff88046eb3e0d0
[   65.658527]  ffff88087f693d80 ffff88087f6898c8 ffffffff8107c1fa 000000017f6898b8
[   65.666830] Call Trace:
[   65.669557]  <#MC>  [<ffffffff81566db9>] dump_stack+0x46/0x58
[   65.675994]  [<ffffffff810871ff>] dequeue_task_idle+0x2f/0x40
[   65.682412]  [<ffffffff8107c1fa>] dequeue_task+0x5a/0x80
[   65.688345]  [<ffffffff810804f3>] deactivate_task+0x23/0x30
[   65.694569]  [<ffffffff81569050>] __schedule+0x580/0x7f0
[   65.700502]  [<ffffffff81569739>] schedule_preempt_disabled+0x29/0x70
[   65.707696]  [<ffffffff8156abb6>] __ww_mutex_lock_slowpath+0xb8/0x162
[   65.714891]  [<ffffffff8156acb3>] __ww_mutex_lock+0x53/0x85
[   65.721125]  [<ffffffffa00b3a5d>] drm_modeset_lock+0x3d/0x110 [drm]
[   65.728132]  [<ffffffffa00b3c2a>] __drm_modeset_lock_all+0x8a/0x120 [drm]
[   65.735721]  [<ffffffffa00b3cd0>] drm_modeset_lock_all+0x10/0x30 [drm]
[   65.743015]  [<ffffffffa01af8bf>] drm_fb_helper_pan_display+0x2f/0xf0 [drm_kms_helper]
[   65.751857]  [<ffffffff8132bd21>] fb_pan_display+0xd1/0x1a0
[   65.758081]  [<ffffffff81326010>] bit_update_start+0x20/0x50
[   65.764400]  [<ffffffff813259f2>] fbcon_switch+0x3a2/0x550
[   65.770528]  [<ffffffff813a01c9>] redraw_screen+0x189/0x240
[   65.776750]  [<ffffffff81322f8a>] fbcon_blank+0x20a/0x2d0
[   65.782778]  [<ffffffff8137d359>] ? erst_writer+0x209/0x330
[   65.789002]  [<ffffffff810ba2f3>] ? internal_add_timer+0x63/0x80
[   65.795710]  [<ffffffff810bc137>] ? mod_timer+0x127/0x1e0
[   65.801740]  [<ffffffff813a0cd8>] do_unblank_screen+0xa8/0x1d0
[   65.808255]  [<ffffffff813a0e10>] unblank_screen+0x10/0x20
[   65.814381]  [<ffffffff812ca0d9>] bust_spinlocks+0x19/0x40
[   65.820508]  [<ffffffff81561ca7>] panic+0x106/0x1f5
[   65.825955]  [<ffffffff8102336c>] mce_panic+0x2ac/0x2e0
[   65.831789]  [<ffffffff812c796a>] ? delay_tsc+0x4a/0x80
[   65.837625]  [<ffffffff81024e1f>] do_machine_check+0xbaf/0xbf0
[   65.844138]  [<ffffffff813365d7>] ? intel_idle+0xc7/0x150
[   65.850166]  [<ffffffff8156f03f>] machine_check+0x1f/0x30
[   65.856195]  [<ffffffff813365d7>] ? intel_idle+0xc7/0x150
[   65.862222]  <<EOE>>  [<ffffffff814283d5>] cpuidle_enter_state+0x55/0x170
[   65.869823]  [<ffffffff814285a7>] cpuidle_enter+0x17/0x20
[   65.875852]  [<ffffffff81097b08>] cpu_startup_entry+0x2d8/0x370
[   65.882467]  [<ffffffff8102fe29>] start_secondary+0x159/0x180

There's __drm_modeset_lock_all() which Daniel Vetter introduced for this
purpose. We can leverage that without reinventing anything. This patch
works with the latest kernel.
Reviewed-by: NRob Clark <robdclark@gmail.com>
Tested-by: NTony Luck <tony.luck@intel.com>
Signed-off-by: NRui Wang <rui.y.wang@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

sd_set_power_mode() in derived module drivers/mmc/host/rtsx_usb_sdmmc.c
acquires dev_mutex and then calls pm_runtime_get_sync() to make sure the
device is awake while initializing a newly inserted card. Once it is
called during suspending state and explicitly before rtsx_usb_suspend()
acquires the same dev_mutex, both routine deadlock and further hang the
driver because pm_runtime_get_sync() waits the pending PM operations.

Fix this by using an empty suspend method. mmc_core always turns the
LED off after a request is done and thus it is ok to remove the only
rtsx_usb_turn_off_led() here.

Cc: <stable@vger.kernel.org> # v3.16+
Fixes: 730876be ("mfd: Add realtek USB card reader driver")
Signed-off-by: NRoger Tseng <rogerable@realtek.com>
[Lee: Removed newly unused variable]
Signed-off-by: NLee Jones <lee.jones@linaro.org>

If we don't tell regmap-irq that our first status
register is at offset 1, it will try to read offset
zero, which is the chipid register.

Fixes: 44b4dc61 mfd: tps65218: Add driver for the TPS65218 PMIC
Cc: <stable@vger.kernel.org> # v3.15+
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>