It doesn't appear to be used anywhere.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>

Add a drm_is_legacy() helper, constify argument to drm_is_render_client(),
and use / change helpers where appropriate.

v2: s/drm_is_legacy/drm_is_legacy_client/ and adapt to new code context.
v3: s/legacy_client/primary_client/
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NBrian Paul <brianp@vmware.com>

Like for render-nodes, there is no point in maintaining the master concept
for control nodes, so set the struct drm_file::master pointer to NULL.

At the same time, make sure DRM_MASTER | DRM_CONTROL_ALLOW ioctls are always
allowed when called through the control node. Previously the caller also
needed to be master.

v2: Adapt to refactoring of ioctl permission check.
v3: Formatting of logical expression. Use drm_is_control_client() instead of
    drm_is_control().
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NBrian Paul <brianp@vmware.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>

Helps reviewing and understanding these checks.
v2: Remove misplaced newlines.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>

control- and render nodes are intended to be master-less.

v2: Replace tests for !legacy with tests for !mode_group for readability.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>

/ssd/git/drm-next/drivers/gpu/drm/i915/i915_cmd_parser.c: In function ‘i915_parse_cmds’:
/ssd/git/drm-next/drivers/gpu/drm/i915/i915_cmd_parser.c:405:4: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 5 has type ‘int’ [-Wformat=]
    DRM_DEBUG_DRIVER("CMD: Command length exceeds batch length: 0x%08X length=%d batchlen=%ld\n",
    ^
Signed-off-by: NDave Airlie <airlied@redhat.com>

Right now a debug message looks like:

  [drm:drm_ioctl], pid=860, dev=0xe200, auth=1, DRM_IOCTL_MODE_GETCRTC

That first comma looks weird as we already have ']' as a separator.
Remove it.

If anyone sees this commit message and also thinks that auth=1 isn't the
most useful info to have here, let's just say I'd happily review a patch
removing it. If I don't get annoyed enough to submit a patch, that is.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This is always DRM_NAME, so we can just make it part of the format
string instead of asking prink to do it for us.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The DRM_LOG* macros where the only sites where drm_ut_debug_printk was
called with NULL arguments for prefix and function_name. Now that they
are gone, we can remove that case.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

In the logging code, we are currently checking is we need to output in
drm_ut_debug_printk(). This is too late. The problem is that when we write
something like:

    DRM_DEBUG_DRIVER("ELD on [CONNECTOR:%d:%s], [ENCODER:%d:%s]\n",
                     connector->base.id,
                     drm_get_connector_name(connector),
                     connector->encoder->base.id,
                     drm_get_encoder_name(connector->encoder));

We start by evaluating the arguments (so call drm_get_connector_name() and
drm_get_connector_name()) before ending up in drm_ut_debug_printk() which will
then does nothing.

This means we execute a lot of instructions (drm_get_connector_name(), in turn,
calls snprintf() for example) to happily discard them in the normal case,
drm.debug=0.

So, let's put the test on drm_debug earlier, in the macros themselves.
Sprinkle an unlikely() as well for good measure.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

There are only a few users of the DRM_LOG_KMS() macro. We can simplify
the DRM code a bit by replacing them by DRM_DEBUG_KMS().
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

There are only a few users of the DRM_LOG_KMS() macro. We can simplify
the DRM code a bit by replacing them by DRM_DEBUG_KMS().

Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Acked-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

There are only a few users of the DRM_LOG_KMS() macro. We can simplify
the DRM code a bit by replacing them by DRM_DEBUG_KMS().

Cc: Inki Dae <inki.dae@samsung.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The recently added PTN3460 device driver uses interfaces that
are provided by the KMS helper infrastructure, so we should
explicitly select that to avoid this linker error:

ERROR: "drm_helper_probe_single_connector_modes" [drivers/gpu/drm/bridge/ptn3460.ko] undefined!
ERROR: "drm_helper_connector_dpms" [drivers/gpu/drm/bridge/ptn3460.ko] undefined!

We have to drop the I2C dependency to avoid a circular dependency
chain, but that's ok because DRM already selects I2C.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Add a missing newline at the end of a DRM_INFO message.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Other kind of accesses are unreliable on Kepler cards. As advised by NVIDIA,
let's only use 32-bit accesses to fetch the vbios from PROM.

This fixes vbios fetching on my nve7 which failed in certain specific
conditions.

I suggest we Cc stable, for all kernels they still maintain after the big
rewrite.
Suggested-by: NChristian Zander <czander@nvidia.com>
Signed-off-by: NMartin Peres <martin.peres@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This should fix automatic fan management on fermi cards who do not have
0x46 entries in the thermal table.

On my nve6, the blob sets the default linear range from 40°C to 100°C
but my nvcf's default values are 40°C to 85°C. Let's keep 85 as a default
for everyone.
Signed-off-by: NMartin Peres <martin.peres@labri.fr>
Tested-by: NTimothée Ravier <tim@siosm.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This should fix fan management on many nvd7+ chipsets.
Signed-off-by: NMartin Peres <martin.peres@labri.fr>
Tested-by: NTimothée Ravier <tim@siosm.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This should fix a deadlock that has been reported to us where fan_update()
would hold the fan lock and try to grab the alarm_program_lock to reschedule
an update. On an other CPU, the alarm_program_lock would have been taken
before calling fan_update(), leading to a deadlock.

We should Cc: <stable@vger.kernel.org> # 3.9+
Reported-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
Tested-by: NTimothée Ravier <tim@siosm.fr>
Tested-by: Boris Fersing (IRC nick fersingb, no public email address)
Signed-off-by: NMartin Peres <martin.peres@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

*hpos horizontal scanout position doesn't need to be corrected
to count the pixels between hactive end and htotal negative.
That is only needed for *vpos to count lines until end of
vblank for the vblank timestamping.

Use hpos as is without correction.

Removes occassional spikes in timestamps of up to 1 scanline
duration, thereby improves accuracy to about +/- 2 usecs instead
of +/- 12 usecs, wrt. true onset time as measured with high
precision equipment on NV-A5.
Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76319Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

I should resurrect/merge that cleanup branch to remove the weird
duplication.. One day.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

It doesn't look like the others have the registers.
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>

Shouldn't effect anything, was just momentarily confusing while looking
at traces.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Not needed everywhere, and potentially not safe to do depending on how
the rest of PTHERM is configured...
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Our ucode only partially works at this point, so requiring binary fw
image for now.
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>

This does *not* (and is not intended to) fix the issue reported by
Christoph Rudorff on the nouveau mailinglist.

The patch proposed (which is similar to this one, but also reorders
whether we disable accel or call fb_set_suspend first), papers over
another problem entirely by avoiding touching the framebuffer.
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>

Unit names come from the Android GK20A driver.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>