When trying to split up the initialisation phase and the registration
phase, one immediate problem encountered is trying to use our own i2c
devices before registration with userspace (to read EDID during device
discovery). drm_dp_aux in particular only offers an interface for setting
up the device *after* we have exposed the connector via sysfs. In order
to break the chicken-and-egg problem, export drm_dp_aux_init() to
minimally prepare the i2c device for internal use before
drm_connector_register().
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Rafael Antognolli <rafael.antognolli@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: dri-devel@lists.freedesktop.org
[danvet: Amend kerneldoc slightly.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466152398-20157-3-git-send-email-chris@chris-wilson.co.uk

Rather than have both drm_dp_aux lock within its transfer, and i2c to
lock around the transfer, use the same lock by filling in the locking
callbacks that i2c wants to use. We require our own hw_mutex as we
bypass i2c_transfer for drm_dp_dpcd_access().
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Rafael Antognolli <rafael.antognolli@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466152398-20157-2-git-send-email-chris@chris-wilson.co.uk

This is part of a patch series to migrate all of the workarounds for
commonly seen behavior from bad sinks in intel_dp_dpcd_read_wake() to drm's
DP helper.

Some sinks will just return garbage for the first aux tranaction they
receive when coming out of sleep mode, so we need to perform an additional
read before the actual read to workaround this.

			    Changes since v5
- If the throwaway read in drm_dp_dpcd_read() fails, return the error
  from that instead of continuing. This follows the same logic we do in
  drm_dp_dpcd_access() (e.g. the error from the first transaction may
  differ from the errors that proceeding attempts might return).
Signed-off-by: NLyude <cpaul@redhat.com>
Tested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1460730335-5012-1-git-send-email-cpaul@redhat.com

This is part of a patch series to migrate all of the workarounds for
commonly seen behavior from bad sinks in intel_dp_dpcd_read_wake() to
drm's DP helper.

We cannot rely on sinks NACKing or deferring when they can't receive
transactions, nor can we rely on any other sort of consistent error to
know when we should stop retrying. As such, we need to just retry
unconditionally on errors. We also make sure here to return the error we
encountered during the first transaction, since it's possible that
retrying the transaction might return a different error then we had
originally.

This, along with the previous patch, work around a weird bug with the
ThinkPad T560's and it's dock. When resuming the laptop, it appears that
there's a short period of time where we're unable to complete any aux
transactions, as they all immediately timeout. The only machine I'm able
to reproduce this on is the T560 as other production Skylake models seem
to be fine. The period during which AUX transactions fail appears to be
around 22ms long. AFAIK, the dock for the T560 never actually turns off,
the only difference is that it's in SST mode at the start of the resume
process, so it's unclear as to why it would need so much time to come
back up.

There's been a discussion on this issue going on for a while on the
intel-gfx mailing list about this that has, in addition to including
developers from Intel, also had the correspondence of one of the
hardware engineers for Intel:

http://www.spinics.net/lists/intel-gfx/msg88831.html
http://www.spinics.net/lists/intel-gfx/msg88410.html

We've already looked into a couple of possible explanations for the
problem:

- Calling intel_dp_mst_resume() before right fix.
  intel_runtime_pm_enable_interrupts(). This was the first fix I tried,
  and while it worked it definitely wasn't the right fix. This worked
  because DP aux transactions don't actually require interrupts to work:

	static uint32_t
	intel_dp_aux_wait_done(struct intel_dp *intel_dp, bool has_aux_irq)
	{
		struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
		struct drm_device *dev = intel_dig_port->base.base.dev;
		struct drm_i915_private *dev_priv = dev->dev_private;
		i915_reg_t ch_ctl = intel_dp->aux_ch_ctl_reg;
		uint32_t status;
		bool done;

	#define C (((status = I915_READ_NOTRACE(ch_ctl)) & DP_AUX_CH_CTL_SEND_BUSY) == 0)
		if (has_aux_irq)
			done = wait_event_timeout(dev_priv->gmbus_wait_queue, C,
						  msecs_to_jiffies_timeout(10));
		else
			done = wait_for_atomic(C, 10) == 0;
		if (!done)
			DRM_ERROR("dp aux hw did not signal timeout (has irq: %i)!\n",
				  has_aux_irq);
	#undef C

		return status;
	}

  When there's no interrupts enabled, we end up timing out on the
  wait_event_timeout() call, which causes us to check the DP status
  register once to see if the transaction was successful or not. Since
  this adds a 10ms delay to each aux transaction, it ends up adding a
  long enough delay to the resume process for aux transactions to become
  functional again. This gave us the illusion that enabling interrupts
  had something to do with making things work again, and put me on the
  wrong track for a while.

- Interrupts occurring when we try to perform the aux transactions
  required to put the dock back into MST mode. This isn't the problem,
  as the only interrupts I've observed that come during this timeout
  period are from the snd_hda_intel driver, and disabling that driver
  doesn't appear to change the behavior at all.

- Skylake's PSR block causing issues by performing aux transactions
  while we try to bring the dock out of MST mode. Disabling PSR through
  i915's command line options doesn't seem to change the behavior
  either, nor does preventing the DMC firmware from being loaded.

Since this investigation went on for about 2 weeks, we decided it would
be better for the time being to just workaround this issue by making
sure AUX transactions wait a short period of time before retrying.
Signed-off-by: NLyude <cpaul@redhat.com>
Tested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1460559513-32280-3-git-send-email-cpaul@redhat.com

This is part of a patch series to migrate all of the workarounds for
commonly seen behavior from bad sinks in intel_dp_dpcd_read_wake() to
drm's DP helper.

Some sinks need some time during the process of resuming the system from
sleep before they're ready to handle transactions. While it would be
nice if they responded with NACKs in these scenarios, this isn't always
the case as a few sinks will just timeout on all of the transactions
they receive until they're ready.
Signed-off-by: NLyude <cpaul@redhat.com>
Tested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1460559513-32280-2-git-send-email-cpaul@redhat.com

1) don't let other threads trying to bang on aux channel interrupt the
defer timeout/logic
2) don't let other threads interrupt the i2c over aux logic

Technically, according to people who actually have the DP spec, this
should not be required.  In practice, it makes some troublesome Dell
monitor (and perhaps others) work, so probably a case of "It's compliant
if it works with windows" on the hw vendor's part..

v2: rebased to come before DPCD/AUX logging patch for easier backport
to stable branches.
Reported-by: NDave Wysochanski <dwysocha@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1274157
Cc: stable@vger.kernel.org
Signed-off-by: NRob Clark <robdclark@gmail.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This module is heavily based on i2c-dev. Once loaded, it provides one
dev node per DP AUX channel, named drm_dp_auxN, where N is an integer.

It's possible to know which connector owns this aux channel by looking
at the respective sysfs /sys/class/drm_aux_dev/drm_dp_auxN/connector, if
the connector device pointer was correctly set in the aux helper struct.

Two main operations are provided on the registers read and write. The
address of the register to be read or written is given using lseek. The
seek position is updated upon read or write.

v2:
 - lseek is used to select the register to read/write
 - read/write are used instead of ioctl
 - no blocking_notifier is used, just a direct callback

v3:
 - use drm_dp_aux_dev prefix for public functions
 - chardev is named drm_dp_auxN
 - read/write don't allocate a buffer anymore, and transfer up to 16 bytes a
   time
 - remove notifier list from the implementation
 - option on menuconfig is now a boolean
 - add inline stub functions to avoid breakage when this option is disabled

v4:
 - fix build system changes - actually disable this module when not selected.

v5:
 - Use kref to avoid device closing while still in use
 - Don't use list, use an idr for storing aux_dev
 - Remove "connector" attribute
 - set aux.dev to the connector drm_connector device, instead of
   drm_device

v6:
 - Use atomic_t for usage count
 - Use a mutex instead of spinlock for idr lock
 - Destroy chardev immediately on unregister
 - other minor suggestions from Ville

v7:
 - style fixes
 - error handling fixes

v8:
 - more error handling fixes

v9:
 - remove module_init and module_exit, and add drm_dp_aux_dev_init/exit
 to drm_kms_helper_init/exit.
Signed-off-by: NRafael Antognolli <rafael.antognolli@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1453417821-2811-3-git-send-email-rafael.antognolli@intel.com

When an i2c WRITE gets an i2c defer or short i2c ack reply, we are
supposed to switch the request from I2C_WRITE to I2C_WRITE_STATUS_UPDATE
when we continue to poll for the completion of the request.

v2: Don't assume DP_AUX_I2C_WRITE is 0 even though it is, to make the
    code more obvious to the casual reader (Jani)
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Resolve conflict due to changed context.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

To help with debugging i2c-over-aux issues, add a module parameter than
can be used to tweak the assumed i2c bus speed, and thus the maximum
number of retries we will do for each aux message.

Cc: Simon Farnsworth <simon.farnsworth@onelan.com>
Cc: moosotc@gmail.com
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NSimon Farnsworth <simon.farnsworth@onelan.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Calculate the number of retries we should do for each i2c-over-aux
message based on the time it takes to perform the i2c transfer vs. the
aux transfer. We assume the shortest possible length for the aux
transfer, and the longest possible (exluding clock stretching) for the
i2c transfer.

The DP spec has some examples on how to calculate this, but we don't
calculate things quite the same way. The spec doesn't account for the
retry interval (assumes immediate retry on defer), and doesn't assume
the best/worst case behaviour as we do.

Note that currently we assume 10 kHz speed for the i2c bus. Some real
world devices (eg. some Apple DP->VGA dongle) fails with less than 16
retries. and that would correspond to something close to 15 kHz (with
our method of calculating things) But let's just go for 10 kHz to be
on the safe side. Ideally we should query/set the i2c bus speed via
DPCD but for now this should at leaast remove the regression from the
1->16 byte trasnfer size change. And of course if the sink completes
the transfer quicker this shouldn't slow things down since we don't
change the interval between retries.

I did a few experiments with a DP->DVI dongle I have that allows you
to change the i2c bus speed. Here are the results of me changing the
actual bus speed and the assumed bus speed and seeing when we start
to fail the operation:

actual i2c khz          assumed i2c khz         max retries
1                       1 ok -> 2 fail          211 ok -> 106 fail
5                       8 ok -> 9 fail          27 ok -> 24 fail
10                      17 ok -> 18 fail        13 ok -> 12 fail
100                     210 ok -> 211 fail      2 ok -> 1 fail

So based on that we have a fairly decent safety margin baked into
the formula to calculate the max number of retries.

Fixes a regression with some DP dongles from:
commit 1d002fa7
Author: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Date:   Tue Feb 10 18:38:08 2015 +0000

    drm/dp: Use large transactions for I2C over AUX

v2: Use best case for AUX and worst case for i2c (Simon Farnsworth)
    Add a define our AUX retry interval and account for it
v3: Make everything usecs to avoid confusion about units (Daniel)
    Add a comment reminding people about the AUX bitrate (Daniel)
    Use DIV_ROUND_UP() since we're after the "worst" case for i2c

Cc: Simon Farnsworth <simon.farnsworth@onelan.com>
Cc: moosotc@gmail.com
Tested-by: moosotc@gmail.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91451Reviewed-by: NSimon Farnsworth <simon.farnsworth@onelan.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Currently we react to native and i2c defers by waiting either 400-500 us
or 500-600 us, depending on which code path we take. Consolidate them
all to one define AUX_RETRY_INTERVAL which defines the minimum interval.
Since we've been using two different intervals pick the longer of them
and define AUX_RETRY_INTERVAL as 500 us. For the maximum just use
AUX_RETRY_INTERVAL+100 us.

I want to have a define for this so that I can use it when calculating
the estimated duration of i2c-over-aux transfers. Without a define it
would be very easy to change the sleep duration and neglect to update
the i2c-over-aux estimates.

Cc: Simon Farnsworth <simon.farnsworth@onelan.com>
Cc: moosotc@gmail.com
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NSimon Farnsworth <simon.farnsworth@onelan.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

For test 4.2.2.5 to pass per the Link CTS Core 1.2 rev1.1 spec, the source
device must attempt at least 7 times to read the EDID when it receives an
I2C defer. The normal DRM code makes only 7 retries, regardless of whether
or not the response is a native defer or an I2C defer. Test 4.2.2.5 fails
since there are native defers interspersed with the I2C defers which
results in less than 7 EDID read attempts.

The solution is to add the numer of defers to the retry counter when an I2C
DEFER is returned such that another read attempt will be made. This situation
should normally only occur in compliance testing, however, as a worse case
real-world scenario, it would result in 13 attempts ( 6 native defers, 7 I2C
defers) for a single transaction to complete. The net result is a slightly
slower response to an EDID read that shouldn't significantly impact overall
performance.

V2:
- Added a check on the number of I2C Defers to limit the number
  of times that the retries variable will be decremented. This
  is to address review feedback regarding possible infinite loops
  from misbehaving sink devices.
V3:
- Fixed the limit value to 7 instead of 8 to get the correct retry
  count.
- Combined the increment of the defer count into the if-statement
V4:
- Removed i915 tag from subject as the patch is not i915-specific
V5:
- Updated the for-loop to add the number of i2c defers to the retry
  counter such that the correct number of retry attempts will be
  made
Signed-off-by: NTodd Previte <tprevite@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The debug message is missing a newline at the end and it makes the
logs hard to read when a device defers a lot. Simple 2-character fix
adds the newline at the end.
Signed-off-by: NTodd Previte <tprevite@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When doing a native or i2c aux write the sink will indicate the number
of bytes written even if it the nacks the transfer. When we receive a
nack we just return an error upwards, but it might still be interesting
to see how many bytes made it before the nack. So include that information
in the debug messages.

v2: Also print the message size (Jani)
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Older DisplayPort to DVI-D Dual Link adapters designed by Bizlink have bugs
in their I2C over AUX implementation (fixed in newer revisions). They work
fine with Windows, but fail with Linux.

It turns out that they cannot keep an I2C transaction open unless the
previous read was 16 bytes; shorter reads can only be followed by a zero
byte transfer ending the I2C transaction.

Copy Windows's behaviour, and read 16 bytes at a time. If we get a short
reply, assume that there's a hardware bottleneck, and shrink our read size
to match. For this purpose, use the algorithm in the DisplayPort 1.2 spec,
in the hopes that it'll be closest to what Windows does.

Also provide an unsafe module parameter for testing smaller transfer sizes,
in case there are sinks out there that cannot work with Windows.

Note also that despite the previous comment in drm_dp_i2c_xfer, this speeds
up native DP EDID reads; Ville Syrjälä <ville.syrjala@linux.intel.com> found
the following changes in his testing:

Device under test:     old  -> with this patch
DP->DVI (OUI 001cf8):  40ms -> 35ms
DP->VGA (OUI 0022b9):  45ms -> 38ms
Zotac DP->2xHDMI:      25ms ->  4ms
Asus PB278 monitor:    22ms ->  3ms

A back of the envelope calculation shows that peak theoretical transfer rate
for 1 byte reads is around 60 kbit/s; with 16 byte reads, this increases to
around 500 kbit/s, which explains the increase in speed.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55228
Tested-by: Aidan Marks <aidanamarks@gmail.com> (v3)
Signed-off-by: NSimon Farnsworth <simon.farnsworth@onelan.co.uk>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We had _power_up(), but drivers also need to be able to power down.
Signed-off-by: NRob Clark <robdclark@gmail.com>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>

At least on two MST devices I've tested with, when
they are link training downstream, they are totally
unable to handle aux ch msgs, so they defer like nuts.
I tried 16, it wasn't enough, 32 seems better.

This fixes one Dell 4k monitor and one of the
MST hubs.

v1.1: fixup comment (Tom).
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

These counters are used for Displayort compliance testing to detect error
conditions when executing tests 4.2.2.4 and 4.2.2.5 in the Displayport Link
CTS specificaiton. They determine whether to use the preferred/requested
mode or the failsafe mode during these tests.

V2:
- Addressed previous review feedback
- Updated commit message
- Changed from uint8_t to uint32_t

Cc: dri-devel@lists.freedesktop.org
Signed-off-by: NTodd Previte <tprevite@gmail.com>
[danvet: s/uint32_t/unsigned/ for clearer intent. Also drop the i915
from the subject, it's all core stuff.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Except for gma500 all drivers are converted to the new style helpers,
which have much better abstraction of the underlying hw protocols and
already much more helper functions (including the entire mst library)
on top of them. Since no one seems to work on converting gma500 let's
just move the code away so that new drivers don't end up accidentally
using this.

Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Reviewed-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com>
Reviewed-by: NAlan Cox <alan@linux.intel.com>
[danvet: Add __deprecated as requested by Alan. Also add a short FIXME
comment and drop the EXPORT_SYMBOL which is no longer needed.]
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

This should avoid races between connector probing and HPD
irqs in the future, currently mode_config.mutex blocks this
possibility.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Only gma500 is still using this, once that's converted we can kill all
this code. If that conversion doesn't happen soonish I think we should
just move this helper code into the gma500 driver itself to avoid
abuse from new drivers.

Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Replace an occurrence of "adapater" with "adapter".
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If you are using the common dp over i2c functionality, it is
asumed that the aux transfer function does not modify the any
of the msg structure other than the reply field.  Doing so
breaks the logic in the common code.

v2: update struct drm_dp_aux comments about assumptions
v3 (chk): rebased on upstream changes
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Thierry Reding <treding@nvidia.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NChristian König <christian.koenig@amd.com>

We need bare address packets at the start and end of
each i2c over aux transaction to properly reset the connection
between transactions.  This mirrors what the existing dp i2c
over aux algo currently does.

This fixes EDID fetches on certain monitors especially with
dp bridges.

v2: update as per Ville's comments
    - Set buffer to NULL for zero sized packets
    - abort the entre transaction if one of the messages fails
v3: drop leftover debugging code
v4: integrate Thierry's comments
    - add comments about address only transactions
    - switch back to i and j
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Thierry Reding <treding@nvidia.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NChristian König <christian.koenig@amd.com>

If we get a msg.reply of REPLY_DEFER, we also get an err of 0
so we fail reads with 0 < size and return -EPROTO instead of trying
again.

v2: same fix in i2c code.

Found writing MST support.
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Switch to debug only to avoid flooding the logs.
This mirrors the behavior in some other drivers.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NChristian König <christian.koenig@amd.com>

Let the drivers specify the name of the I2C-over-AUX adapter to maintain
backwards compatibility in the sysfs when converting to the new
I2C-over-AUX helper infrastructure.

The i915 driver currently uses DPDDC-A to DPDDC-D as names for the DP
i2c adapters. These names show up in the i2c sysfs name attribute. We'd
like to be able to maintain that when switching over to the new helpers.

Due to i2c device and connector cleanup ordering issues we also recently
made the drm device (instead of connector) the parent of the i2c
adapters:

commit 80f65de3
Author: Imre Deak <imre.deak@intel.com>
Date:   Tue Feb 11 17:12:49 2014 +0200

    drm/i915: dp: fix order of dp aux i2c device cleanup

With the name picked up from the adapter parent using dev_name(), it
would be the same for all i2c adapters with the current I2C-over-AUX
helpers.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Acked-by: NDave Airlie <airlied@redhat.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Implements an I2C-over-AUX I2C adapter on top of the generic drm_dp_aux
infrastructure. It extracts the retry logic from existing drivers, which
should help in porting those drivers to this new helper.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
---
Changes in v5:
- move comments partially to to header file
- keep MOT set between I2C messages
- return -EPROTO on short reads

Changes in v4:
- fix typo "bitrate" -> "bit rate"

Changes in v3:
- add back DRM_DEBUG_KMS and DRM_ERROR messages
- embed i2c_adapter within struct drm_dp_aux
- fix typo in comment

Add a helper to probe a DP link (read out the supported DPCD revision,
maximum rate, link count and capabilities) as well as power up the DP
link and configure it accordingly.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
---
Changes in v5:
- export helpers

Changes in v4:
- fix a couple of typos in comments as pointed out by Alex Deucher

Changes in v3:
- split into drm_dp_link_power_up() and drm_dp_link_configure()
- do not change sink state for DPCD versions earlier than 1.1
- sleep for 1-2 ms after setting local sink to D0 state
- read and write consecutive registers where possible
- read DPCD revision when link is probed
- remove duplicate kerneldoc

The function reads the link status (6 bytes starting at offset 0x202)
from the DPCD so that it can be conveniently passed to other DPCD
helpers.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

This is a superset of the current i2c_dp_aux bus functionality and can
be used to transfer native AUX in addition to I2C-over-AUX messages.

Helpers are provided to read and write the DPCD, either blockwise or
byte-wise. Many of the existing helpers for DisplayPort take a copy of a
portion of the DPCD and operate on that, without a way to write data
back to the DPCD (e.g. for configuration of the link).

Subsequent patches will build upon this infrastructure to provide common
functionality in a generic way.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
---
Changes in v5:
- move comments partially to struct drm_dp_aux_msg in header file
- return -EPROTO on short reads in DPCD helpers

Changes in v4:
- fix a typo in a comment

Changes in v3:
- reorder drm_dp_dpcd_writeb() arguments to be more intuitive
- return number of bytes transferred in drm_dp_dpcd_write()
- factor out drm_dp_dpcd_access()
- describe error codes

None of the DP DPCD helpers need to modify the DPCD.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

I didn't bother with documenting the really trivial new "extract
something from dpcd" helpers, but the i2c over aux ch is now
documented a bit.

v2: Clarify the comment for i2c_dp_aux_add_bus a bit.

v3: Fix more spelling fail spotted by Laurent Pinchart.
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Acked-by: NDave Airlie <airlied@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This requires a few changes since that dpcd value is above the
range currently cached by radeon. I've check the dp specs, and
above 0xf there's a big gap and nothing that looks like we should
cache it while a given device is plugged in. It's also the same value
that i915.ko uses.

Hence extend the various dpcd arrays in the radeon driver, use
proper symbolic constants where applicable (one place overallocated
the dpcd array to 25 bytes). Then also drop the rd_interval cache -
radeon_dp_link_train_init re-reads the dpcd block, so the values we'll
consume in train_cr and train_ce will always be fresh.

To avoid needless diff-churn, #define the old size of dpcd as the new
one and keep it around.

v2: Alex Deucher noticed one place where I've forgotten to replace 8
with DP_RECEIVER_CAP_SIZE.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Acked-by: NDave Airlie <airlied@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Safe for the minor difference that the intel versions get an offset
into the link_status as an argument, both are the same again.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Acked-by: NDave Airlie <airlied@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

radeon and intel use the exact same definition.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Acked-by: NDave Airlie <airlied@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

I want to move some dp link training helpers into this place, so in
the future this won't be just about i2c any longer.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Acked-by: NDave Airlie <airlied@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Convert #include "..." to #include <path/...> in drivers/gpu/.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NDave Airlie <airlied@redhat.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: NDave Jones <davej@redhat.com>

include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files.  percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed.  Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability.  As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

  http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
  only the necessary includes are there.  ie. if only gfp is used,
  gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
  blocks and try to put the new include such that its order conforms
  to its surrounding.  It's put in the include block which contains
  core kernel includes, in the same order that the rest are ordered -
  alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
  doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
  because the file doesn't have fitting include block), it prints out
  an error message indicating which .h file needs to be added to the
  file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
   over 4000 files, deleting around 700 includes and adding ~480 gfp.h
   and ~3000 slab.h inclusions.  The script emitted errors for ~400
   files.

2. Each error was manually checked.  Some didn't need the inclusion,
   some needed manual addition while adding it to implementation .h or
   embedding .c file was more appropriate for others.  This step added
   inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
   from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
   e.g. lib/decompress_*.c used malloc/free() wrappers around slab
   APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
   editing them as sprinkling gfp.h and slab.h inclusions around .h
   files could easily lead to inclusion dependency hell.  Most gfp.h
   inclusion directives were ignored as stuff from gfp.h was usually
   wildly available and often used in preprocessor macros.  Each
   slab.h inclusion directive was examined and added manually as
   necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
   were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
   distributed build env didn't work with gcov compiles) and a few
   more options had to be turned off depending on archs to make things
   build (like ipr on powerpc/64 which failed due to missing writeq).

   * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
   * powerpc and powerpc64 SMP allmodconfig
   * sparc and sparc64 SMP allmodconfig
   * ia64 SMP allmodconfig
   * s390 SMP allmodconfig
   * alpha SMP allmodconfig
   * um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
   a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: NTejun Heo <tj@kernel.org>
Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>