[Intel-gfx] [PATCH v3 2/2] drm/i915/gmbus: Enable burst read
Ramalingam C
ramalingam.c at intel.com
Wed Apr 18 11:18:43 UTC 2018
Thanks ville for reviewing this change.
On Wednesday 18 April 2018 12:12 AM, Ville Syrjälä wrote:
> On Tue, Apr 17, 2018 at 02:25:33PM +0530, Ramalingam C wrote:
>> Support for Burst read in HW is added for HDCP2.2 compliance
>> requirement.
>>
>> This patch enables the burst read for all the gmbus read of more than
>> 511Bytes, on capable platforms.
>>
>> v2:
>> Extra line is removed.
>> v3:
>> Macro is added for detecting the BURST_READ Support [Jani]
>> Runtime detection of the need for burst_read [Jani]
>>
>> Signed-off-by: Ramalingam C <ramalingam.c at intel.com>
>> ---
>> drivers/gpu/drm/i915/i915_drv.h | 3 +++
>> drivers/gpu/drm/i915/i915_reg.h | 1 +
>> drivers/gpu/drm/i915/intel_i2c.c | 22 ++++++++++++++++++++--
>> 3 files changed, 24 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
>> index 5373b171bb96..9cddcaa3efb2 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -2548,6 +2548,9 @@ intel_info(const struct drm_i915_private *dev_priv)
>> */
>> #define HAS_AUX_IRQ(dev_priv) true
>> #define HAS_GMBUS_IRQ(dev_priv) (INTEL_GEN(dev_priv) >= 4)
>> +#define HAS_GMBUS_BURST_READ(dev_priv) (INTEL_GEN(dev_priv) >= 10 || \
>> + IS_GEMINILAKE(dev_priv) || \
>> + IS_KABYLAKE(dev_priv))
> Spec says "Not available until KBLPCH-H A0, SPT-LP D1, SPT-H E1"
> Not quite sure if those two statements are equivalenet or not.
>
>>
>> /* With the 945 and later, Y tiling got adjusted so that it was 32 128-byte
>> * rows, which changed the alignment requirements and fence programming.
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
>> index be6114a0e8ab..8b4e6363c7d2 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -2984,6 +2984,7 @@ enum i915_power_well_id {
>> #define GMBUS_RATE_400KHZ (2<<8) /* reserved on Pineview */
>> #define GMBUS_RATE_1MHZ (3<<8) /* reserved on Pineview */
>> #define GMBUS_HOLD_EXT (1<<7) /* 300ns hold time, rsvd on Pineview */
>> +#define GMBUS_BYTE_CNT_OVERRIDE (1<<6)
>> #define GMBUS_PIN_DISABLED 0
>> #define GMBUS_PIN_SSC 1
>> #define GMBUS_PIN_VGADDC 2
>> diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
>> index 4367827d7661..cb260f667cfa 100644
>> --- a/drivers/gpu/drm/i915/intel_i2c.c
>> +++ b/drivers/gpu/drm/i915/intel_i2c.c
>> @@ -373,10 +373,21 @@ gmbus_xfer_read_chunk(struct drm_i915_private *dev_priv,
>> unsigned short addr, u8 *buf, unsigned int len,
>> u32 gmbus1_index)
>> {
>> + unsigned int bytes_af_override = 0, size = len;
> whatis af?
stands for bytes after override. Bytes that will be read after resetting
the
Byte Count Override bit. we can use size for the purpose of
bytes_af_override also.
Which is feed to HW total_byte_count fields.
>
>> + bool burst_read = len > gmbus_max_xfer_size(dev_priv);
>> +
>> + if (burst_read) {
>> + bytes_af_override = (len % 256) + 256;
> The spec has a special case for 512 for some reason. Would be nice to
> find out why it's there, and why there is no special case listed for
> other larger multiples of 256.
Sent a mail for clarification from HW team. But I hope that could be
iterative fix, on top of this. Need not block this!?
>
> No need for () around the %.
>
>> + size = bytes_af_override;
> Why two variables for the same thing?
will fix it. My bad.
>
>> +
>> + I915_WRITE_FW(GMBUS0, (I915_READ_FW(GMBUS0) |
>> + GMBUS_BYTE_CNT_OVERRIDE));
> useless parens
>
> We could probably avoid the rmw by passing in the gmbus0
> value from the caller.
Is that fine to add another parameter throughout
do_gmbus_xfer-->gmbus_index_xfer-->
gmbus_xfer_read-->gmbus_xfer_read_chunk to avoid the reg read?
--Ram
>
>> + }
>> +
>> I915_WRITE_FW(GMBUS1,
>> gmbus1_index |
>> GMBUS_CYCLE_WAIT |
>> - (len << GMBUS_BYTE_COUNT_SHIFT) |
>> + (size << GMBUS_BYTE_COUNT_SHIFT) |
>> (addr << GMBUS_SLAVE_ADDR_SHIFT) |
>> GMBUS_SLAVE_READ | GMBUS_SW_RDY);
>> while (len) {
>> @@ -392,6 +403,10 @@ gmbus_xfer_read_chunk(struct drm_i915_private *dev_priv,
>> *buf++ = val & 0xff;
>> val >>= 8;
>> } while (--len && ++loop < 4);
>> +
>> + if (burst_read && len == (bytes_af_override - 4))
> more useless parens
>
>> + I915_WRITE_FW(GMBUS0, (I915_READ_FW(GMBUS0) &
>> + ~GMBUS_BYTE_CNT_OVERRIDE));
> and some more
>
>> }
>>
>> return 0;
>> @@ -407,7 +422,10 @@ gmbus_xfer_read(struct drm_i915_private *dev_priv, struct i2c_msg *msg,
>> int ret;
>>
>> do {
>> - len = min(rx_size, gmbus_max_xfer_size(dev_priv));
>> + if (HAS_GMBUS_BURST_READ(dev_priv))
>> + len = rx_size;
>> + else
>> + len = min(rx_size, gmbus_max_xfer_size(dev_priv));
>>
>> ret = gmbus_xfer_read_chunk(dev_priv, msg->addr,
>> buf, len, gmbus1_index);
>> --
>> 2.7.4
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx/attachments/20180418/f96a7677/attachment.html>
More information about the Intel-gfx
mailing list