All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Daniel Vetter <daniel.vetter@ffwll.ch>,
	<intel-gfx@lists.freedesktop.org>,
	<dri-devel@lists.freedesktop.org>
Cc: linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
	"Ville Syrjälä" <ville.syrjala@linux.intel.com>
Subject: linux-next: manual merge of the drm-misc tree with Linus' tree
Date: Sat, 12 Sep 2015 13:15:29 +1000	[thread overview]
Message-ID: <20150912131529.5e0f0980@canb.auug.org.au> (raw)

Hi all,

Today's linux-next merge of the drm-misc tree got a conflict in:

  drivers/gpu/drm/drm_dp_helper.c

between commits:

  79a2b161c12a ("drm/dp: Define AUX_RETRY_INTERVAL as 500 us")
  4efa83c8c786 ("drm/dp: Adjust i2c-over-aux retry count based on message size and i2c bus speed")
  f36203be608a ("drm/dp: Add dp_aux_i2c_speed_khz module param to set the assume i2c bus speed")

from Linus' tree and commit:

  68ec2a2a2481 ("drm/dp: Use I2C_WRITE_STATUS_UPDATE to drain partial I2C_WRITE requests")

from the drm-misc tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/gpu/drm/drm_dp_helper.c
index 291734e87fca,5a55d905b8ee..000000000000
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@@ -424,90 -422,19 +424,103 @@@ static u32 drm_dp_i2c_functionality(str
  	       I2C_FUNC_10BIT_ADDR;
  }
  
 +#define AUX_PRECHARGE_LEN 10 /* 10 to 16 */
 +#define AUX_SYNC_LEN (16 + 4) /* preamble + AUX_SYNC_END */
 +#define AUX_STOP_LEN 4
 +#define AUX_CMD_LEN 4
 +#define AUX_ADDRESS_LEN 20
 +#define AUX_REPLY_PAD_LEN 4
 +#define AUX_LENGTH_LEN 8
 +
 +/*
 + * Calculate the duration of the AUX request/reply in usec. Gives the
 + * "best" case estimate, ie. successful while as short as possible.
 + */
 +static int drm_dp_aux_req_duration(const struct drm_dp_aux_msg *msg)
 +{
 +	int len = AUX_PRECHARGE_LEN + AUX_SYNC_LEN + AUX_STOP_LEN +
 +		AUX_CMD_LEN + AUX_ADDRESS_LEN + AUX_LENGTH_LEN;
 +
 +	if ((msg->request & DP_AUX_I2C_READ) == 0)
 +		len += msg->size * 8;
 +
 +	return len;
 +}
 +
 +static int drm_dp_aux_reply_duration(const struct drm_dp_aux_msg *msg)
 +{
 +	int len = AUX_PRECHARGE_LEN + AUX_SYNC_LEN + AUX_STOP_LEN +
 +		AUX_CMD_LEN + AUX_REPLY_PAD_LEN;
 +
 +	/*
 +	 * For read we expect what was asked. For writes there will
 +	 * be 0 or 1 data bytes. Assume 0 for the "best" case.
 +	 */
 +	if (msg->request & DP_AUX_I2C_READ)
 +		len += msg->size * 8;
 +
 +	return len;
 +}
 +
 +#define I2C_START_LEN 1
 +#define I2C_STOP_LEN 1
 +#define I2C_ADDR_LEN 9 /* ADDRESS + R/W + ACK/NACK */
 +#define I2C_DATA_LEN 9 /* DATA + ACK/NACK */
 +
 +/*
 + * Calculate the length of the i2c transfer in usec, assuming
 + * the i2c bus speed is as specified. Gives the the "worst"
 + * case estimate, ie. successful while as long as possible.
 + * Doesn't account the the "MOT" bit, and instead assumes each
 + * message includes a START, ADDRESS and STOP. Neither does it
 + * account for additional random variables such as clock stretching.
 + */
 +static int drm_dp_i2c_msg_duration(const struct drm_dp_aux_msg *msg,
 +				   int i2c_speed_khz)
 +{
 +	/* AUX bitrate is 1MHz, i2c bitrate as specified */
 +	return DIV_ROUND_UP((I2C_START_LEN + I2C_ADDR_LEN +
 +			     msg->size * I2C_DATA_LEN +
 +			     I2C_STOP_LEN) * 1000, i2c_speed_khz);
 +}
 +
 +/*
 + * Deterine how many retries should be attempted to successfully transfer
 + * the specified message, based on the estimated durations of the
 + * i2c and AUX transfers.
 + */
 +static int drm_dp_i2c_retry_count(const struct drm_dp_aux_msg *msg,
 +			      int i2c_speed_khz)
 +{
 +	int aux_time_us = drm_dp_aux_req_duration(msg) +
 +		drm_dp_aux_reply_duration(msg);
 +	int i2c_time_us = drm_dp_i2c_msg_duration(msg, i2c_speed_khz);
 +
 +	return DIV_ROUND_UP(i2c_time_us, aux_time_us + AUX_RETRY_INTERVAL);
 +}
 +
 +/*
 + * FIXME currently assumes 10 kHz as some real world devices seem
 + * to require it. We should query/set the speed via DPCD if supported.
 + */
 +static int dp_aux_i2c_speed_khz __read_mostly = 10;
 +module_param_unsafe(dp_aux_i2c_speed_khz, int, 0644);
 +MODULE_PARM_DESC(dp_aux_i2c_speed_khz,
 +		 "Assumed speed of the i2c bus in kHz, (1-400, default 10)");
 +
+ static void drm_dp_i2c_msg_write_status_update(struct drm_dp_aux_msg *msg)
+ {
+ 	/*
+ 	 * In case of i2c defer or short i2c ack reply to a write,
+ 	 * we need to switch to WRITE_STATUS_UPDATE to drain the
+ 	 * rest of the message
+ 	 */
+ 	if ((msg->request & ~DP_AUX_I2C_MOT) == DP_AUX_I2C_WRITE) {
+ 		msg->request &= DP_AUX_I2C_MOT;
+ 		msg->request |= DP_AUX_I2C_WRITE_STATUS_UPDATE;
+ 	}
+ }
+ 
  /*
   * Transfer a single I2C-over-AUX message and handle various error conditions,
   * retrying the transaction as appropriate.  It is assumed that the
@@@ -595,7 -521,8 +610,8 @@@ static int drm_dp_i2c_do_msg(struct drm
  			aux->i2c_defer_count++;
  			if (defer_i2c < 7)
  				defer_i2c++;
 -			usleep_range(400, 500);
 +			usleep_range(AUX_RETRY_INTERVAL, AUX_RETRY_INTERVAL + 100);
+ 			drm_dp_i2c_msg_write_status_update(msg);
  			continue;
  
  		default:

WARNING: multiple messages have this Message-ID (diff)
From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Daniel Vetter <daniel.vetter@ffwll.ch>,
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Cc: linux-next@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: linux-next: manual merge of the drm-misc tree with Linus' tree
Date: Sat, 12 Sep 2015 13:15:29 +1000	[thread overview]
Message-ID: <20150912131529.5e0f0980@canb.auug.org.au> (raw)

Hi all,

Today's linux-next merge of the drm-misc tree got a conflict in:

  drivers/gpu/drm/drm_dp_helper.c

between commits:

  79a2b161c12a ("drm/dp: Define AUX_RETRY_INTERVAL as 500 us")
  4efa83c8c786 ("drm/dp: Adjust i2c-over-aux retry count based on message size and i2c bus speed")
  f36203be608a ("drm/dp: Add dp_aux_i2c_speed_khz module param to set the assume i2c bus speed")

from Linus' tree and commit:

  68ec2a2a2481 ("drm/dp: Use I2C_WRITE_STATUS_UPDATE to drain partial I2C_WRITE requests")

from the drm-misc tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/gpu/drm/drm_dp_helper.c
index 291734e87fca,5a55d905b8ee..000000000000
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@@ -424,90 -422,19 +424,103 @@@ static u32 drm_dp_i2c_functionality(str
  	       I2C_FUNC_10BIT_ADDR;
  }
  
 +#define AUX_PRECHARGE_LEN 10 /* 10 to 16 */
 +#define AUX_SYNC_LEN (16 + 4) /* preamble + AUX_SYNC_END */
 +#define AUX_STOP_LEN 4
 +#define AUX_CMD_LEN 4
 +#define AUX_ADDRESS_LEN 20
 +#define AUX_REPLY_PAD_LEN 4
 +#define AUX_LENGTH_LEN 8
 +
 +/*
 + * Calculate the duration of the AUX request/reply in usec. Gives the
 + * "best" case estimate, ie. successful while as short as possible.
 + */
 +static int drm_dp_aux_req_duration(const struct drm_dp_aux_msg *msg)
 +{
 +	int len = AUX_PRECHARGE_LEN + AUX_SYNC_LEN + AUX_STOP_LEN +
 +		AUX_CMD_LEN + AUX_ADDRESS_LEN + AUX_LENGTH_LEN;
 +
 +	if ((msg->request & DP_AUX_I2C_READ) == 0)
 +		len += msg->size * 8;
 +
 +	return len;
 +}
 +
 +static int drm_dp_aux_reply_duration(const struct drm_dp_aux_msg *msg)
 +{
 +	int len = AUX_PRECHARGE_LEN + AUX_SYNC_LEN + AUX_STOP_LEN +
 +		AUX_CMD_LEN + AUX_REPLY_PAD_LEN;
 +
 +	/*
 +	 * For read we expect what was asked. For writes there will
 +	 * be 0 or 1 data bytes. Assume 0 for the "best" case.
 +	 */
 +	if (msg->request & DP_AUX_I2C_READ)
 +		len += msg->size * 8;
 +
 +	return len;
 +}
 +
 +#define I2C_START_LEN 1
 +#define I2C_STOP_LEN 1
 +#define I2C_ADDR_LEN 9 /* ADDRESS + R/W + ACK/NACK */
 +#define I2C_DATA_LEN 9 /* DATA + ACK/NACK */
 +
 +/*
 + * Calculate the length of the i2c transfer in usec, assuming
 + * the i2c bus speed is as specified. Gives the the "worst"
 + * case estimate, ie. successful while as long as possible.
 + * Doesn't account the the "MOT" bit, and instead assumes each
 + * message includes a START, ADDRESS and STOP. Neither does it
 + * account for additional random variables such as clock stretching.
 + */
 +static int drm_dp_i2c_msg_duration(const struct drm_dp_aux_msg *msg,
 +				   int i2c_speed_khz)
 +{
 +	/* AUX bitrate is 1MHz, i2c bitrate as specified */
 +	return DIV_ROUND_UP((I2C_START_LEN + I2C_ADDR_LEN +
 +			     msg->size * I2C_DATA_LEN +
 +			     I2C_STOP_LEN) * 1000, i2c_speed_khz);
 +}
 +
 +/*
 + * Deterine how many retries should be attempted to successfully transfer
 + * the specified message, based on the estimated durations of the
 + * i2c and AUX transfers.
 + */
 +static int drm_dp_i2c_retry_count(const struct drm_dp_aux_msg *msg,
 +			      int i2c_speed_khz)
 +{
 +	int aux_time_us = drm_dp_aux_req_duration(msg) +
 +		drm_dp_aux_reply_duration(msg);
 +	int i2c_time_us = drm_dp_i2c_msg_duration(msg, i2c_speed_khz);
 +
 +	return DIV_ROUND_UP(i2c_time_us, aux_time_us + AUX_RETRY_INTERVAL);
 +}
 +
 +/*
 + * FIXME currently assumes 10 kHz as some real world devices seem
 + * to require it. We should query/set the speed via DPCD if supported.
 + */
 +static int dp_aux_i2c_speed_khz __read_mostly = 10;
 +module_param_unsafe(dp_aux_i2c_speed_khz, int, 0644);
 +MODULE_PARM_DESC(dp_aux_i2c_speed_khz,
 +		 "Assumed speed of the i2c bus in kHz, (1-400, default 10)");
 +
+ static void drm_dp_i2c_msg_write_status_update(struct drm_dp_aux_msg *msg)
+ {
+ 	/*
+ 	 * In case of i2c defer or short i2c ack reply to a write,
+ 	 * we need to switch to WRITE_STATUS_UPDATE to drain the
+ 	 * rest of the message
+ 	 */
+ 	if ((msg->request & ~DP_AUX_I2C_MOT) == DP_AUX_I2C_WRITE) {
+ 		msg->request &= DP_AUX_I2C_MOT;
+ 		msg->request |= DP_AUX_I2C_WRITE_STATUS_UPDATE;
+ 	}
+ }
+ 
  /*
   * Transfer a single I2C-over-AUX message and handle various error conditions,
   * retrying the transaction as appropriate.  It is assumed that the
@@@ -595,7 -521,8 +610,8 @@@ static int drm_dp_i2c_do_msg(struct drm
  			aux->i2c_defer_count++;
  			if (defer_i2c < 7)
  				defer_i2c++;
 -			usleep_range(400, 500);
 +			usleep_range(AUX_RETRY_INTERVAL, AUX_RETRY_INTERVAL + 100);
+ 			drm_dp_i2c_msg_write_status_update(msg);
  			continue;
  
  		default:
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

             reply	other threads:[~2015-09-12  3:15 UTC|newest]

Thread overview: 119+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-12  3:15 Stephen Rothwell [this message]
2015-09-12  3:15 ` linux-next: manual merge of the drm-misc tree with Linus' tree Stephen Rothwell
  -- strict thread matches above, loose matches on Subject: below --
2024-03-25 23:29 Stephen Rothwell
2024-02-06  0:59 Stephen Rothwell
2024-02-06  1:06 ` Stephen Rothwell
2024-02-06 11:28   ` Michael Walle
2024-02-06 11:34     ` Dario Binacchi
2023-11-14  0:42 Stephen Rothwell
2023-11-14  0:42 ` Stephen Rothwell
2023-11-14  0:36 Stephen Rothwell
2023-11-14  0:36 ` Stephen Rothwell
2023-11-14  0:31 Stephen Rothwell
2023-11-14  0:31 ` Stephen Rothwell
2023-11-14  0:25 Stephen Rothwell
2023-11-14  0:25 ` Stephen Rothwell
2023-09-25  1:41 Stephen Rothwell
2023-09-25  1:41 ` Stephen Rothwell
2023-09-20  1:12 Stephen Rothwell
2023-09-20  1:12 ` Stephen Rothwell
2023-09-13  1:09 Stephen Rothwell
2023-09-13  1:09 ` Stephen Rothwell
2023-09-13  9:04 ` Uwe Kleine-König
2023-09-13  9:04   ` Uwe Kleine-König
2023-07-12 23:58 Stephen Rothwell
2023-07-12 23:58 ` Stephen Rothwell
2023-05-23  0:43 Stephen Rothwell
2023-05-23  0:43 ` Stephen Rothwell
2023-05-15  1:14 Stephen Rothwell
2023-05-15  1:14 ` Stephen Rothwell
2023-03-14  0:19 Stephen Rothwell
2023-03-14  0:19 ` Stephen Rothwell
2023-01-19  1:13 Stephen Rothwell
2023-01-19  1:13 ` Stephen Rothwell
2023-01-05 23:50 Stephen Rothwell
2023-01-05 23:50 ` Stephen Rothwell
2022-11-03 23:15 Stephen Rothwell
2022-11-03 23:15 ` Stephen Rothwell
2022-10-05  0:43 Stephen Rothwell
2022-10-05  0:43 ` Stephen Rothwell
2022-06-29  1:06 Stephen Rothwell
2022-06-29  1:06 ` Stephen Rothwell
2022-06-10  0:44 Stephen Rothwell
2022-06-10  0:44 ` Stephen Rothwell
2021-11-16 22:29 Stephen Rothwell
2021-11-16 22:29 ` Stephen Rothwell
2021-10-28  2:48 Stephen Rothwell
2021-01-21  1:24 Stephen Rothwell
2021-01-21  1:24 ` Stephen Rothwell
2020-10-27  1:26 Stephen Rothwell
2020-10-27  1:26 ` Stephen Rothwell
2020-10-27  1:20 Stephen Rothwell
2020-10-27  1:20 ` Stephen Rothwell
2020-10-27  1:16 Stephen Rothwell
2020-10-27  1:16 ` Stephen Rothwell
2020-08-26  0:01 Stephen Rothwell
2020-08-26  0:01 ` Stephen Rothwell
2020-09-02  3:11 ` Stephen Rothwell
2020-09-02  3:11   ` Stephen Rothwell
2020-06-29  1:14 Stephen Rothwell
2020-06-29  1:14 ` Stephen Rothwell
2020-06-26  1:43 Stephen Rothwell
2020-06-26  1:43 ` Stephen Rothwell
2020-06-17  0:46 Stephen Rothwell
2020-06-17  0:46 ` Stephen Rothwell
2020-04-16  1:25 Stephen Rothwell
2020-04-16  1:25 ` Stephen Rothwell
2020-04-15  1:46 Stephen Rothwell
2020-04-15  1:46 ` Stephen Rothwell
2019-12-16  0:51 Stephen Rothwell
2019-12-16  0:51 ` Stephen Rothwell
2019-12-16  0:46 Stephen Rothwell
2019-12-16  0:46 ` Stephen Rothwell
2019-05-21  0:51 Stephen Rothwell
2019-05-23  0:27 ` Stephen Rothwell
2019-05-23  8:10 ` Maxime Ripard
2019-05-23  9:34   ` Stephen Rothwell
2019-05-23 11:53 ` Maxime Ripard
2019-05-23 11:53   ` Maxime Ripard
2019-05-23 13:04   ` Stephen Rothwell
2019-05-23 13:11     ` Daniel Vetter
2019-05-23 14:16       ` Stephen Rothwell
2019-05-23 14:16         ` Stephen Rothwell
2019-05-23 16:10   ` Rob Herring
2019-05-23 16:10     ` Rob Herring
2019-05-24  7:12     ` Maxime Ripard
2019-05-24  7:12       ` Maxime Ripard
2019-01-11  0:14 Stephen Rothwell
2018-03-20  1:08 Stephen Rothwell
2018-03-23  0:43 ` Stephen Rothwell
2018-03-23  0:43   ` Stephen Rothwell
2018-03-15  3:14 Stephen Rothwell
2018-03-15  3:14 ` Stephen Rothwell
2018-03-23  0:45 ` Stephen Rothwell
2018-03-23  0:45   ` Stephen Rothwell
2017-09-22  2:24 Stephen Rothwell
2017-08-02  2:23 Stephen Rothwell
2017-08-02  2:23 ` Stephen Rothwell
2017-08-10  2:06 ` Stephen Rothwell
2017-08-10  2:06   ` Stephen Rothwell
2017-07-19  1:30 Stephen Rothwell
2016-09-23  1:35 Stephen Rothwell
2016-06-07  1:32 Stephen Rothwell
2016-06-07  1:32 ` Stephen Rothwell
2016-03-31  0:15 Stephen Rothwell
2016-03-31  0:15 ` Stephen Rothwell
2016-03-29 23:49 Stephen Rothwell
2016-03-29 23:49 ` Stephen Rothwell
2015-12-16  0:38 Stephen Rothwell
2015-12-16  0:38 ` Stephen Rothwell
2015-12-14  1:12 Stephen Rothwell
2015-12-14  1:12 ` Stephen Rothwell
2015-12-14  7:09 ` Thomas Hellstrom
2015-12-14  7:09   ` Thomas Hellstrom
2015-08-14  2:06 Stephen Rothwell
2015-08-14  2:06 ` Stephen Rothwell
2015-08-03  2:11 Stephen Rothwell
2015-08-03  2:11 ` Stephen Rothwell
2015-07-30  3:04 Stephen Rothwell
2015-07-30  3:04 ` Stephen Rothwell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150912131529.5e0f0980@canb.auug.org.au \
    --to=sfr@canb.auug.org.au \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=ville.syrjala@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.