Re: [Intel-gfx] [MIPI SEQ PARSING v2 PATCH 01/11] drm/i915: Adding the parsing logic for the i2c element
>-Original Message-
>From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>Sent: Thursday, September 17, 2015 2:48 PM
>To: Deepak, M; intel-gfx@lists.freedesktop.org
>Cc: Deepak, M
>Subject: Re: [Intel-gfx] [MIPI SEQ PARSING v2 PATCH 01/11] drm/i915: Adding
>the parsing logic for the i2c element
>
>On Thu, 10 Sep 2015, Deepak M wrote:
>> From: vkorjani
>>
>> New sequence element for i2c is been added in the mipi sequence block
>> of the VBT. This patch parses and executes the i2c sequence.
>>
>> v2: Add i2c_put_adapter call(Jani), rebase
>>
>> Signed-off-by: vkorjani
>> Signed-off-by: Deepak M
>> ---
>> drivers/gpu/drm/i915/intel_bios.c |6 +++
>> drivers/gpu/drm/i915/intel_bios.h |1 +
>> drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 61
>
>> 3 files changed, 68 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_bios.c
>> b/drivers/gpu/drm/i915/intel_bios.c
>> index c8acc29..0bf0942 100644
>> --- a/drivers/gpu/drm/i915/intel_bios.c
>> +++ b/drivers/gpu/drm/i915/intel_bios.c
>> @@ -714,6 +714,12 @@ static u8 *goto_next_sequence(u8 *data, int
>> *size)
>>
>> data += 3;
>> break;
>> +case MIPI_SEQ_ELEM_I2C:
>> +/* skip by this element payload size */
>> +data += 7;
>> +len = *data;
>> +data += len + 1;
>> +break;
>> default:
>> DRM_ERROR("Unknown element\n");
>> return NULL;
>> diff --git a/drivers/gpu/drm/i915/intel_bios.h
>> b/drivers/gpu/drm/i915/intel_bios.h
>> index 1b7417e..21a7f3f 100644
>> --- a/drivers/gpu/drm/i915/intel_bios.h
>> +++ b/drivers/gpu/drm/i915/intel_bios.h
>> @@ -956,6 +956,7 @@ enum mipi_seq_element {
>> MIPI_SEQ_ELEM_SEND_PKT,
>> MIPI_SEQ_ELEM_DELAY,
>> MIPI_SEQ_ELEM_GPIO,
>> +MIPI_SEQ_ELEM_I2C,
>> MIPI_SEQ_ELEM_STATUS,
>
>Side note, MIPI_SEQ_ELEM_STATUS doesn't seem to be in spec.
>
>
>> MIPI_SEQ_ELEM_MAX
>> };
>> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
>> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
>> index a5e99ac..9989f61 100644
>> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
>> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
>> @@ -31,6 +31,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include "i915_drv.h"
>> @@ -104,6 +105,65 @@ static struct gpio_table gtable[] = {
>> { GPIO_NC_11_PCONF0, GPIO_NC_11_PAD, 0} };
>>
>> +static const u8 *mipi_exec_i2c(struct intel_dsi *intel_dsi, const u8
>> +*data) {
>> +struct i2c_adapter *adapter;
>> +int ret;
>> +u8 reg_offset, payload_size, retries = 5;
>> +struct i2c_msg msg;
>> +u8 *transmit_buffer = NULL;
>> +u8 flag = *data++;
>> +u8 index = *data++;
>> +u8 bus_number = *data++;
>> +u16 slave_add = *(u16 *)(data);
>> +
>> +data = data + 2;
>> +reg_offset = *data++;
>> +payload_size = *data++;
>> +
>> +adapter = i2c_get_adapter(bus_number);
>> +
>> +if (!adapter) {
>> +DRM_ERROR("i2c_get_adapter(%u) failed, index:%u flag:
>%u\n",
>> +(bus_number + 1), index, flag);
>
>Why do you log bus_number + 1 instead of what was actually tried?
[Deepak M] Will fix this.
>
>I don't see why the flag/index are useful for in the message, as they're not
>relevant to the i2c_get_adapter failing.
>
[Deepak M] Flag field is reserved and then the index is used for windows, for
Linux these two can be skipped. Will not try to declare flag and index variable.
>> +goto out;
>> +}
>> +
>> +transmit_buffer = kmalloc(1 + payload_size, GFP_TEMPORARY);
>> +
>> +if (!transmit_buffer)
>> +goto out;
>> +
>> +transmit_buffer[0] = reg_offset;
>> +memcpy(&transmit_buffer[1], data, (size_t)payload_size);
>
>Why do you need the cast?
>
>> +
>> +msg.addr = slave_add;
>> +msg.flags = 0;
>> +msg.len= payload_size + 1;
>> +msg.buf= &transmit_buffer[0];
>> +
>> +do {
>> +ret = i2c_transfer(adapter, &msg, 1);
>> +if (ret == 1)
>> +break;
>> +else if (ret == -EAGAIN)
>> +usleep_range(1000, 2500);
>> +else {
>> +DRM_ERROR("i2c transfer failed, error code:%d", ret);
>
>\n missing.
>
>> +break;
>> +}
>> +} while (retries--);
>> +
>> +if (retries == 0)
>
>Due to the way you post-decrement retries, you may end up here even if the
>transfer succeeds on the last try.
>
>You may also end up printing two error messages, if i2c_transfer fails on the
>last try.
[Deepak M] okay, Will handle this.
>
>> +DRM_ERROR("i2c transfer failed, error code:%d", ret);
>
>\n missing.
>
>> +out:
>> +kfree(transmit_buffer);
>> +i2c_put_adapter(adapter);
>> +
>> +data = data + payload_
Re: [Intel-gfx] [MIPI SEQ PARSING v2 PATCH 03/11] drm/i915: Parsing VBT if size of VBT exceeds 6KB
>-Original Message-
>From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>Sent: Thursday, September 17, 2015 5:41 PM
>To: Deepak, M; intel-gfx@lists.freedesktop.org
>Cc: Deepak, M
>Subject: Re: [Intel-gfx] [MIPI SEQ PARSING v2 PATCH 03/11] drm/i915: Parsing
>VBT if size of VBT exceeds 6KB
>
>On Thu, 10 Sep 2015, Deepak M wrote:
>> Currently the iomap for VBT works only if the size of the VBT is less
>> than 6KB, but if the size of the VBT exceeds 6KB than the physical
>> address and the size of the VBT to be iomapped is specified in the
>> mailbox3 and is iomapped accordingly.
>>
>> v2: - Moving the validate_vbt to opregion file (Jani)
>> - Fix the i915_opregion() in debugfs (Jani)
>>
>> Signed-off-by: Deepak M
>> ---
>> drivers/gpu/drm/i915/i915_debugfs.c | 24 ++-
>> drivers/gpu/drm/i915/i915_drv.h |4 +
>> drivers/gpu/drm/i915/intel_bios.c | 49 +-
>> drivers/gpu/drm/i915/intel_opregion.c | 279
>> +
>> drivers/gpu/drm/i915/intel_opregion.h | 230
>> +++
>> 5 files changed, 329 insertions(+), 257 deletions(-) create mode
>> 100644 drivers/gpu/drm/i915/intel_opregion.h
>>
>> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
>> b/drivers/gpu/drm/i915/i915_debugfs.c
>> index 41629fa..5534aa2 100644
>> --- a/drivers/gpu/drm/i915/i915_debugfs.c
>> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
>> @@ -26,6 +26,8 @@
>> *
>> */
>>
>> +#include
>> +#include
>> #include
>> #include
>> #include
>> @@ -39,6 +41,7 @@
>> #include "intel_ringbuffer.h"
>> #include
>> #include "i915_drv.h"
>> +#include "intel_opregion.h"
>>
>> enum {
>> ACTIVE_LIST,
>> @@ -1832,7 +1835,7 @@ static int i915_opregion(struct seq_file *m, void
>*unused)
>> struct drm_device *dev = node->minor->dev;
>> struct drm_i915_private *dev_priv = dev->dev_private;
>> struct intel_opregion *opregion = &dev_priv->opregion;
>> -void *data = kmalloc(OPREGION_SIZE, GFP_KERNEL);
>> +void *data = kmalloc(OPREGION_VBT_OFFSET, GFP_KERNEL);
>> int ret;
>>
>> if (data == NULL)
>> @@ -1843,12 +1846,25 @@ static int i915_opregion(struct seq_file *m, void
>*unused)
>> goto out;
>>
>> if (opregion->header) {
>> -memcpy_fromio(data, opregion->header, OPREGION_SIZE);
>> -seq_write(m, data, OPREGION_SIZE);
>> +memcpy_fromio(data, opregion->header,
>OPREGION_VBT_OFFSET);
>> +seq_write(m, data, OPREGION_VBT_OFFSET);
>> +kfree(data);
>> +if (opregion->asle->rvda) {
>> +data = kmalloc(opregion->asle->rvds, GFP_KERNEL);
>> +memcpy_fromio(data,
>> +(const void __iomem *) opregion->asle->rvda,
>> +opregion->asle->rvds);
>> +seq_write(m, data, opregion->asle->rvds);
>> +} else {
>> +data = kmalloc(OPREGION_SIZE -
>OPREGION_VBT_OFFSET,
>> +GFP_KERNEL);
>> +memcpy_fromio(data, opregion->vbt,
>> +OPREGION_SIZE -
>OPREGION_VBT_OFFSET);
>> +seq_write(m, data, OPREGION_SIZE -
>OPREGION_VBT_OFFSET);
>> +}
>
>If rvda != 0, this debugfs file no longer represents the opregion contents.
>Mailboxes #4 and #5 are dropped from the output. BTW, what is mailbox #4
>expected to contain when rvda != 0? (I still don't have access to the latest
>opregion spec version, so can't check what it actually says.)
>
>I am beginning to think we should leave "i915_opregion" debugfs file intact,
>and add a new "i915_vbt" file that contains either mailbox #4 or the data in
>rvda. This might be a cleaner approach.
>
>See my comments below, and you'll see how this would be feasible.
>
[Deepak M] I was thinking of splitting this function into 5 for dumping each
mailbox. Which
I felt will be cleaner.
>> }
>>
>> mutex_unlock(&dev->struct_mutex);
>> -
>> out:
>> kfree(data);
>> return 0;
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h
>> b/drivers/gpu/drm/i915/i915_drv.h index 1287007..507d57a 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -1780,6 +1780,7 @@ struct drm_i915_private {
>> struct i915_hotplug hotplug;
>> struct i915_fbc fbc;
>> struct i915_drrs drrs;
>> +const struct bdb_header *bdb_start;
>
>What is wrong with using dev_priv->opregion.vbt for this?
>
>> struct intel_opregion opregion;
>> struct intel_vbt_data vbt;
>>
>> @@ -3306,6 +3307,9 @@ intel_opregion_notify_adapter(struct drm_device
>> *dev, pci_power_t state) } #endif
>>
>> +const struct bdb_header *validate_vbt(const void __iomem *_vbt,
>> +size_t size, const char *source);
>> +
>> /* intel_acpi.c */
>> #ifdef CONFIG_ACPI
>> extern void intel_register_dsm_handler(void); diff --git
>> a/drivers/gpu/drm/i915/intel_bi
Re: [Intel-gfx] [MIPI SEQ PARSING v2 PATCH 04/11] drm/i915: Using the approprite vbt size if vbt is not in mailbox4 of opregion
>-Original Message-
>From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>Sent: Thursday, September 17, 2015 5:48 PM
>To: Deepak, M; intel-gfx@lists.freedesktop.org
>Cc: Deepak, M
>Subject: Re: [Intel-gfx] [MIPI SEQ PARSING v2 PATCH 04/11] drm/i915: Using
>the approprite vbt size if vbt is not in mailbox4 of opregion
>
>On Thu, 10 Sep 2015, Deepak M wrote:
>> Currently the field in bdb header which indicates the VBT size is of 2
>> bytes, but there are some cases where VBT size exceeds 64KB in which
>> case this field may not contain the correct VBT size.
>> So its better to get the VBT size from the mailbox3 if VBT is not
>> present in the mailbox4 of opregion.
>>
>> v2: - Use opregion filed from dev_priv struct instead of creating
>> a new field in dev_priv (Jani)
>> - Have vbt_size field vaild in all scenarios (Jani)
>> - rebase
>>
>> Signed-off-by: Deepak M
>> ---
>> drivers/gpu/drm/i915/i915_drv.h |2 ++
>> drivers/gpu/drm/i915/intel_bios.c | 42 +++--
>
>> drivers/gpu/drm/i915/intel_opregion.c |6 +
>> 3 files changed, 32 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h
>> b/drivers/gpu/drm/i915/i915_drv.h index 507d57a..91ccbc6 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -1777,6 +1777,8 @@ struct drm_i915_private {
>> u32 pm_rps_events;
>> u32 pipestat_irq_mask[I915_MAX_PIPES];
>>
>> +u32 vbt_size;
>
>No. dev_priv is not a random area to throw things into. The place you're
>looking for is dev_priv->opregion, i.e. struct intel_opregion.
>
>> +
>> struct i915_hotplug hotplug;
>> struct i915_fbc fbc;
>> struct i915_drrs drrs;
>> diff --git a/drivers/gpu/drm/i915/intel_bios.c
>> b/drivers/gpu/drm/i915/intel_bios.c
>> index 1932a86..34a1042 100644
>> --- a/drivers/gpu/drm/i915/intel_bios.c
>> +++ b/drivers/gpu/drm/i915/intel_bios.c
>> @@ -37,17 +37,19 @@
>> static int panel_type;
>>
>> static const void *
>> -find_section(const void *_bdb, int section_id)
>> +find_section(struct drm_i915_private *dev_priv,
>> +const void *_bdb, int section_id)
>> {
>> const struct bdb_header *bdb = _bdb;
>> const u8 *base = _bdb;
>> int index = 0;
>> -u16 total, current_size;
>> +u32 total, current_size;
>> u8 current_id;
>>
>> /* skip to first section */
>> index += bdb->header_size;
>> -total = bdb->bdb_size;
>> +
>> +total = dev_priv->vbt_size;
>
>vbt_size != bdb_size. See below.
>
>>
>> /* walk the sections looking for section_id */
>> while (index + 3 < total) {
>> @@ -179,7 +181,7 @@ parse_lfp_panel_data(struct drm_i915_private
>*dev_priv,
>> struct drm_display_mode *panel_fixed_mode;
>> int drrs_mode;
>>
>> -lvds_options = find_section(bdb, BDB_LVDS_OPTIONS);
>> +lvds_options = find_section(dev_priv, bdb, BDB_LVDS_OPTIONS);
>> if (!lvds_options)
>> return;
>>
>> @@ -211,11 +213,12 @@ parse_lfp_panel_data(struct drm_i915_private
>*dev_priv,
>> break;
>> }
>>
>> -lvds_lfp_data = find_section(bdb, BDB_LVDS_LFP_DATA);
>> +lvds_lfp_data = find_section(dev_priv, bdb, BDB_LVDS_LFP_DATA);
>> if (!lvds_lfp_data)
>> return;
>>
>> -lvds_lfp_data_ptrs = find_section(bdb, BDB_LVDS_LFP_DATA_PTRS);
>> +lvds_lfp_data_ptrs = find_section(dev_priv, bdb,
>> +BDB_LVDS_LFP_DATA_PTRS);
>> if (!lvds_lfp_data_ptrs)
>> return;
>>
>> @@ -257,7 +260,7 @@ parse_lfp_backlight(struct drm_i915_private
>*dev_priv,
>> const struct bdb_lfp_backlight_data *backlight_data;
>> const struct bdb_lfp_backlight_data_entry *entry;
>>
>> -backlight_data = find_section(bdb, BDB_LVDS_BACKLIGHT);
>> +backlight_data = find_section(dev_priv, bdb, BDB_LVDS_BACKLIGHT);
>> if (!backlight_data)
>> return;
>>
>> @@ -305,14 +308,15 @@ parse_sdvo_panel_data(struct drm_i915_private
>*dev_priv,
>> if (index == -1) {
>> const struct bdb_sdvo_lvds_options *sdvo_lvds_options;
>>
>> -sdvo_lvds_options = find_section(bdb,
>BDB_SDVO_LVDS_OPTIONS);
>> +sdvo_lvds_options = find_section(dev_priv, bdb,
>> +BDB_SDVO_LVDS_OPTIONS);
>> if (!sdvo_lvds_options)
>> return;
>>
>> index = sdvo_lvds_options->panel_type;
>> }
>>
>> -dvo_timing = find_section(bdb, BDB_SDVO_PANEL_DTDS);
>> +dvo_timing = find_section(dev_priv, bdb, BDB_SDVO_PANEL_DTDS);
>> if (!dvo_timing)
>> return;
>>
>> @@ -349,7 +353,7 @@ parse_general_features(struct drm_i915_private
>*dev_priv,
>> struct drm_device *dev = dev_priv->dev;
>> const struct bdb_general_features *general;
>>
>> -general = find_section(bdb, BDB_GENERAL_FEATURES);
>> +general = find_section(dev_priv, bdb, BDB_GENERAL_FEATURES);
>>
Re: [Intel-gfx] [MIPI SEQ PARSING v2 PATCH 05/11] drm/i915: Added support the v3 mipi sequence block
>-Original Message-
>From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>Sent: Thursday, September 17, 2015 8:09 PM
>To: Deepak, M; intel-gfx@lists.freedesktop.org
>Cc: Deepak, M
>Subject: Re: [Intel-gfx] [MIPI SEQ PARSING v2 PATCH 05/11] drm/i915: Added
>support the v3 mipi sequence block
>
>On Thu, 10 Sep 2015, Deepak M wrote:
>> From: vkorjani
>>
>> The Block 53 of the VBT, which is the MIPI sequence block has
>> undergone a design change because of which the parsing logic has to be
>> changed.
>>
>> The current code will handle the parsing of v3 and other lower
>> versions of the MIPI sequence block.
>>
>> v2: rebase
>>
>> Signed-off-by: vkorjani
>> Signed-off-by: Deepak M
>> ---
>> drivers/gpu/drm/i915/intel_bios.c | 119
>+++-
>> drivers/gpu/drm/i915/intel_bios.h |8 ++
>> drivers/gpu/drm/i915/intel_dsi_panel_vbt.c |7 ++
>> 3 files changed, 114 insertions(+), 20 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_bios.c
>> b/drivers/gpu/drm/i915/intel_bios.c
>> index 34a1042..cea641f 100644
>> --- a/drivers/gpu/drm/i915/intel_bios.c
>> +++ b/drivers/gpu/drm/i915/intel_bios.c
>> @@ -45,6 +45,7 @@ find_section(struct drm_i915_private *dev_priv,
>> int index = 0;
>> u32 total, current_size;
>> u8 current_id;
>> +u8 version;
>>
>> /* skip to first section */
>> index += bdb->header_size;
>> @@ -56,7 +57,17 @@ find_section(struct drm_i915_private *dev_priv,
>> current_id = *(base + index);
>> index++;
>>
>> -current_size = *((const u16 *)(base + index));
>> +if (current_id == BDB_MIPI_SEQUENCE) {
>> +version = *(base + index + 2);
>> +if (version >= 3)
>> +current_size = *((const u32 *)(base +
>> +index + 3));
>> +else
>> +current_size = *((const u16 *)(base + index));
>> +} else {
>> +current_size = *((const u16 *)(base + index));
>> +}
>> +
>
>While reviewing I've realized the old kernels will hit this hard. I've
>submitted a
>patch [1] to be applied to v4.3-rc and older stable kernels so that they fail
>gracefully instead of starting to parse garbage. The real parsing is too big to
>backport to upstream stable. Please review.
>
>[1] http://mid.gmane.org/1442497327-27033-1-git-send-email-
>jani.nik...@intel.com
>
>> index += 2;
>>
>> if (index + current_size > total)
>> @@ -745,6 +756,55 @@ static u8 *goto_next_sequence(u8 *data, int *size)
>> return data;
>> }
>>
>> +static u8 *goto_next_sequence_v3(u8 *data, int *size) {
>> +int tmp = *size;
>> +int op_size;
>> +
>> +if (--tmp < 0)
>> +return NULL;
>> +
>> +/* Skip the panel id and the sequence size */
>
>It's not panel id, it's the sequence byte, right?
>
>You could also store data + 1 + size of sequence, and check whether data ends
>up pointing at the same place in the end. They should.
>
>Shouldn't you also take 4 bytes of sequence size field into account in tmp?
>
>> +data = data + 5;
>> +while (*data != 0) {
>> +u8 element_type = *data++;
>> +
>> +switch (element_type) {
>
>Would be helpful to refer to operation_byte like in the spec.
>
>> +default:
>> +DRM_ERROR("Unknown element type %d\n",
>element_type);
>> +case MIPI_SEQ_ELEM_SEND_PKT:
>> +case MIPI_SEQ_ELEM_DELAY:
>> +case MIPI_SEQ_ELEM_GPIO:
>> +case MIPI_SEQ_ELEM_I2C:
>> +case MIPI_SEQ_ELEM_SPI:
>> +case MIPI_SEQ_ELEM_PMIC:
>> +/*
>> + * skip by this element payload size
>> + * skip elem id, command flag and data type
>> + */
>> +op_size = *data++;
>> +tmp = tmp - (op_size + 1);
>> +if (tmp < 0)
>> +return NULL;
>
>Isn't each operation operation byte | size of operation | payload size, i.e.
>your
>tmp change is one byte short?
>
>The fact that the goto_next_sequence* functions increase data and decrease
>size is getting increasingly confusing to follow. One simple alternative would
>be to calculate some endp = start + size up front, and then pass the endp
>around, and check if we're about to go past the end marker.
>
>This is not a problem with your series, it was there already. And fixing it
>doesn't have to be part of your series. It just really takes ages to review
>this
>approach of range checking. Unless I close my eyes and trust there are no off-
>by-ones anywhere. But that kind of defeats the purpose of review...
>
[Deepak M] Okay will try to simplify the logic.
>> +
>> +/* skip by len */
>> +data += op_size;
>> +
Re: [Intel-gfx] [MIPI SEQ PARSING v2 PATCH 04/11] drm/i915: Using the approprite vbt size if vbt is not in mailbox4 of opregion
>-Original Message-
>From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>Sent: Thursday, September 17, 2015 7:01 PM
>To: Deepak, M; intel-gfx@lists.freedesktop.org
>Cc: Deepak, M
>Subject: Re: [Intel-gfx] [MIPI SEQ PARSING v2 PATCH 04/11] drm/i915: Using
>the approprite vbt size if vbt is not in mailbox4 of opregion
>
>On Thu, 17 Sep 2015, Jani Nikula wrote:
>> On Thu, 10 Sep 2015, Deepak M wrote:
>>> Currently the field in bdb header which indicates the VBT size is of
>>> 2 bytes, but there are some cases where VBT size exceeds 64KB in
>>> which case this field may not contain the correct VBT size.
>>> So its better to get the VBT size from the mailbox3 if VBT is not
>>> present in the mailbox4 of opregion.
>>>
>>> v2: - Use opregion filed from dev_priv struct instead of creating
>>> a new field in dev_priv (Jani)
>>> - Have vbt_size field vaild in all scenarios (Jani)
>>> - rebase
>>>
>>> Signed-off-by: Deepak M
>>> ---
>>> drivers/gpu/drm/i915/i915_drv.h |2 ++
>>> drivers/gpu/drm/i915/intel_bios.c | 42 +++-
>-
>>> drivers/gpu/drm/i915/intel_opregion.c |6 +
>>> 3 files changed, 32 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_drv.h
>>> b/drivers/gpu/drm/i915/i915_drv.h index 507d57a..91ccbc6 100644
>>> --- a/drivers/gpu/drm/i915/i915_drv.h
>>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>>> @@ -1777,6 +1777,8 @@ struct drm_i915_private {
>>> u32 pm_rps_events;
>>> u32 pipestat_irq_mask[I915_MAX_PIPES];
>>>
>>> + u32 vbt_size;
>>
>> No. dev_priv is not a random area to throw things into. The place
>> you're looking for is dev_priv->opregion, i.e. struct intel_opregion.
>>
>>> +
>>> struct i915_hotplug hotplug;
>>> struct i915_fbc fbc;
>>> struct i915_drrs drrs;
>>> diff --git a/drivers/gpu/drm/i915/intel_bios.c
>>> b/drivers/gpu/drm/i915/intel_bios.c
>>> index 1932a86..34a1042 100644
>>> --- a/drivers/gpu/drm/i915/intel_bios.c
>>> +++ b/drivers/gpu/drm/i915/intel_bios.c
>>> @@ -37,17 +37,19 @@
>>> static int panel_type;
>>>
>>> static const void *
>>> -find_section(const void *_bdb, int section_id)
>>> +find_section(struct drm_i915_private *dev_priv,
>>> + const void *_bdb, int section_id)
>>> {
>>> const struct bdb_header *bdb = _bdb;
>>> const u8 *base = _bdb;
>>> int index = 0;
>>> - u16 total, current_size;
>>> + u32 total, current_size;
>>> u8 current_id;
>>>
>>> /* skip to first section */
>>> index += bdb->header_size;
>>> - total = bdb->bdb_size;
>>> +
>>> + total = dev_priv->vbt_size;
>>
>> vbt_size != bdb_size. See below.
>>
>>>
>>> /* walk the sections looking for section_id */
>>> while (index + 3 < total) {
>>> @@ -179,7 +181,7 @@ parse_lfp_panel_data(struct drm_i915_private
>*dev_priv,
>>> struct drm_display_mode *panel_fixed_mode;
>>> int drrs_mode;
>>>
>>> - lvds_options = find_section(bdb, BDB_LVDS_OPTIONS);
>>> + lvds_options = find_section(dev_priv, bdb, BDB_LVDS_OPTIONS);
>>> if (!lvds_options)
>>> return;
>>>
>>> @@ -211,11 +213,12 @@ parse_lfp_panel_data(struct drm_i915_private
>*dev_priv,
>>> break;
>>> }
>>>
>>> - lvds_lfp_data = find_section(bdb, BDB_LVDS_LFP_DATA);
>>> + lvds_lfp_data = find_section(dev_priv, bdb, BDB_LVDS_LFP_DATA);
>>> if (!lvds_lfp_data)
>>> return;
>>>
>>> - lvds_lfp_data_ptrs = find_section(bdb, BDB_LVDS_LFP_DATA_PTRS);
>>> + lvds_lfp_data_ptrs = find_section(dev_priv, bdb,
>>> + BDB_LVDS_LFP_DATA_PTRS);
>>> if (!lvds_lfp_data_ptrs)
>>> return;
>>>
>>> @@ -257,7 +260,7 @@ parse_lfp_backlight(struct drm_i915_private
>*dev_priv,
>>> const struct bdb_lfp_backlight_data *backlight_data;
>>> const struct bdb_lfp_backlight_data_entry *entry;
>>>
>>> - backlight_data = find_section(bdb, BDB_LVDS_BACKLIGHT);
>>> + backlight_data = find_section(dev_priv, bdb, BDB_LVDS_BACKLIGHT);
>>> if (!backlight_data)
>>> return;
>>>
>>> @@ -305,14 +308,15 @@ parse_sdvo_panel_data(struct drm_i915_private
>*dev_priv,
>>> if (index == -1) {
>>> const struct bdb_sdvo_lvds_options *sdvo_lvds_options;
>>>
>>> - sdvo_lvds_options = find_section(bdb,
>BDB_SDVO_LVDS_OPTIONS);
>>> + sdvo_lvds_options = find_section(dev_priv, bdb,
>>> + BDB_SDVO_LVDS_OPTIONS);
>>> if (!sdvo_lvds_options)
>>> return;
>>>
>>> index = sdvo_lvds_options->panel_type;
>>> }
>>>
>>> - dvo_timing = find_section(bdb, BDB_SDVO_PANEL_DTDS);
>>> + dvo_timing = find_section(dev_priv, bdb, BDB_SDVO_PANEL_DTDS);
>>> if (!dvo_timing)
>>> return;
>>>
>>> @@ -349,7 +353,7 @@ parse_general_features(struct drm_i915_private
>*dev_priv,
>>> struct drm_device *dev = dev_priv->dev;
>>> const struct bdb_general_features *general;
>>>
>>> - general = f
[Intel-gfx] [PATCH] drm/fbdev: Update legacy plane->fb refcounting for atomic restore
Starting with commit
commit 28cc504e8d52248962f5b485bdc65f539e3fe21d
Author: Rob Clark
Date: Tue Aug 25 15:36:00 2015 -0400
drm/i915: enable atomic fb-helper
I've been seeing some panics on i915 when the DRM master shuts down that appear
to be caused by using an already-freed framebuffer (i.e., we're unexpectedly
dropping our initial FB's reference count to 0 and freeing it, which causes a
crash when we try to restore it later). Digging deeper, the state FB
refcounting is working as expected, but we seem to be missing proper
refcounting on the legacy plane->fb pointers in the new atomic fbdev code.
Tracking plane->old_fb and then doing a ref/unref at the end of the
fbdev restore like we do in the legacy ioctl's ensures we don't miscount
references on plane->fb and avoids the panics.
Cc: Rob Clark
Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: Matt Roper
---
I don't see any existing bugzilla's (or mailing list complaints) for this,
which surprises me a bit since it seems to be very easy to reproduce for me on
latest drm-intel-nightly running on IVB...boot the system, load X, kill X,
panic.
drivers/gpu/drm/drm_fb_helper.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 64fc5ca..2149ac7 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -352,6 +352,8 @@ retry:
drm_for_each_plane(plane, dev) {
struct drm_plane_state *plane_state;
+ plane->old_fb = plane->fb;
+
plane_state = drm_atomic_get_plane_state(state, plane);
if (IS_ERR(plane_state)) {
ret = PTR_ERR(plane_state);
@@ -385,6 +387,14 @@ retry:
if (ret != 0)
goto fail;
+ drm_for_each_plane(plane, dev) {
+ if (plane->fb)
+ drm_framebuffer_reference(plane->fb);
+ if (plane->old_fb)
+ drm_framebuffer_unreference(plane->old_fb);
+ plane->old_fb = NULL;
+ }
+
return 0;
fail:
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 8/9] drm/i915: reject invalid formats for FBC
This commit is essentially a rewrite of "drm/i915: Check pixel format
for fbc" from Ville Syrjälä. The idea is the same, but the code is
different due to all the changes that happened since his original
patch. So any bugs are due to my bad rewrite.
v2:
- Drop the alpha formats (Ville).
v3:
- Drop the stale comment (Ville).
Testcases: igt/kms_frontbuffer_tracking/*fbc*-${format_name}-draw-*
Credits-to: Ville Syrjälä
Reviewed-by: Ville Syrjälä
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_fbc.c | 30 ++
2 files changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d22120f..4e44352 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -950,6 +950,7 @@ struct i915_fbc {
FBC_IN_DBG_MASTER, /* kernel debugger is active */
FBC_BAD_STRIDE, /* stride is not supported */
FBC_PIXEL_RATE, /* pixel rate is too big */
+ FBC_PIXEL_FORMAT /* pixel format is invalid */
} no_fbc_reason;
bool (*fbc_enabled)(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 56cf110..9d2f56e 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -484,6 +484,8 @@ const char *intel_no_fbc_reason_str(enum no_fbc_reason
reason)
return "framebuffer stride not supported";
case FBC_PIXEL_RATE:
return "pixel rate is too big";
+ case FBC_PIXEL_FORMAT:
+ return "pixel format is invalid";
default:
MISSING_CASE(reason);
return "unknown reason";
@@ -709,6 +711,29 @@ static bool stride_is_valid(struct drm_i915_private
*dev_priv,
return true;
}
+static bool pixel_format_is_valid(struct drm_framebuffer *fb)
+{
+ struct drm_device *dev = fb->dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ switch (fb->pixel_format) {
+ case DRM_FORMAT_XRGB:
+ case DRM_FORMAT_XBGR:
+ return true;
+ case DRM_FORMAT_XRGB1555:
+ case DRM_FORMAT_RGB565:
+ /* 16bpp not supported on gen2 */
+ if (IS_GEN2(dev))
+ return false;
+ /* WaFbcOnly1to1Ratio:ctg */
+ if (IS_G4X(dev_priv))
+ return false;
+ return true;
+ default:
+ return false;
+ }
+}
+
/**
* __intel_fbc_update - enable/disable FBC as needed, unlocked
* @dev_priv: i915 device instance
@@ -824,6 +849,11 @@ static void __intel_fbc_update(struct drm_i915_private
*dev_priv)
goto out_disable;
}
+ if (!pixel_format_is_valid(fb)) {
+ set_no_fbc_reason(dev_priv, FBC_PIXEL_FORMAT);
+ goto out_disable;
+ }
+
/* If the kernel debugger is active, always disable compression */
if (in_dbg_master()) {
set_no_fbc_reason(dev_priv, FBC_IN_DBG_MASTER);
--
2.5.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/7] drm/i915: WaRsUseTimeoutMode
Hello,
This change looks good but incomplete.
When changing RC6 from EI mode to TO mode,
should the time value in GEN6_RC6_THRESHOLD
be changed to hold the timeout value instead
of the evaluation interval period?
Should the workaround name be included in a comment?
While this workaround is unnamed for Broadwell, it is
called WaRsUseTimeoutMode for Skylake.
If possible, I would like to see those changes
squashed into this patch. If not, then putting
those changes in a followup patch would be OK.
Thanks,
Tom
On Mon, Sep 21, 2015 at 11:49:58AM -0700, Yu Dai wrote:
> Looks good to me.
> Reviewed-by: Alex Dai
>
> On 09/11/2015 09:47 PM, Sagar Arun Kamble wrote:
> >Enable TO mode for RC6 for SKL till D0 and BXT till A0.
> >
> >Cc: Tom O'Rourke
> >Cc: Akash Goel
> >Signed-off-by: Sagar Arun Kamble
> >---
> > drivers/gpu/drm/i915/intel_pm.c | 13 ++---
> > 1 file changed, 10 insertions(+), 3 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/intel_pm.c
> >b/drivers/gpu/drm/i915/intel_pm.c
> >index c93d3a7..6e4818d 100644
> >--- a/drivers/gpu/drm/i915/intel_pm.c
> >+++ b/drivers/gpu/drm/i915/intel_pm.c
> >@@ -4847,9 +4847,16 @@ static void gen9_enable_rc6(struct drm_device *dev)
> > rc6_mask = GEN6_RC_CTL_RC6_ENABLE;
> > DRM_INFO("RC6 %s\n", (rc6_mask & GEN6_RC_CTL_RC6_ENABLE) ?
> > "on" : "off");
> >-I915_WRITE(GEN6_RC_CONTROL, GEN6_RC_CTL_HW_ENABLE |
> >- GEN6_RC_CTL_EI_MODE(1) |
> >- rc6_mask);
> >+
> >+if ((IS_SKYLAKE(dev) && INTEL_REVID(dev) <= SKL_REVID_D0) ||
> >+(IS_BROXTON(dev) && INTEL_REVID(dev) <= BXT_REVID_A0))
> >+I915_WRITE(GEN6_RC_CONTROL, GEN6_RC_CTL_HW_ENABLE |
> >+GEN7_RC_CTL_TO_MODE |
> >+rc6_mask);
> >+else
> >+I915_WRITE(GEN6_RC_CONTROL, GEN6_RC_CTL_HW_ENABLE |
> >+GEN6_RC_CTL_EI_MODE(1) |
> >+rc6_mask);
> > /*
> > * 3b: Enable Coarse Power Gating only when RC6 is enabled.
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PULL] topic/drm-misc
On 17 September 2015 at 00:45, Daniel Vetter wrote: > On Mon, Sep 14, 2015 at 8:22 AM, Daniel Vetter wrote: >> Hi Dave, >> >> -rc1 is out the door and here's my first pull request for drm-next. It's >> all over: >> - better atomic helpers for runtime pm drivers >> - atomic fbdev > > David Herrmann just pointed out to me that atomic fbdev isn't actually > in this pull. Just checked my mails and it looks like there's some > small things pending for the kerneldoc. I'll do a separate pull for > atomic fbdev when I'm back from xdc. > -Daniel This also conflicts with -rc2, which I'm not really sure I like as the first thing I pull in. Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 4/7] drm/i915: WaRsDoubleRc6WrlWithCoarsePowerGating
Looks good to me. Reviewed-by: Alex Dai On 09/11/2015 09:47 PM, Sagar Arun Kamble wrote: Cc: Tom O'Rourke Cc: Akash Goel Signed-off-by: Sagar Arun Kamble --- drivers/gpu/drm/i915/intel_pm.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 6e4818d..4d6bb6b 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -4830,7 +4830,13 @@ static void gen9_enable_rc6(struct drm_device *dev) I915_WRITE(GEN6_RC_CONTROL, 0); /* 2b: Program RC6 thresholds.*/ - I915_WRITE(GEN6_RC6_WAKE_RATE_LIMIT, 54 << 16); + + /* WaRsDoubleRc6WrlWithCoarsePowerGating: Doubling WRL only when CPG is enabled */ + if (IS_SKYLAKE(dev) && !((IS_SKL_GT3(dev) || IS_SKL_GT4(dev)) && + (INTEL_REVID(dev) <= SKL_REVID_E0))) + I915_WRITE(GEN6_RC6_WAKE_RATE_LIMIT, 108 << 16); + else + I915_WRITE(GEN6_RC6_WAKE_RATE_LIMIT, 54 << 16); I915_WRITE(GEN6_RC_EVALUATION_INTERVAL, 125000); /* 12500 * 1280ns */ I915_WRITE(GEN6_RC_IDLE_HYSTERSIS, 25); /* 25 * 1280ns */ for_each_ring(ring, dev_priv, unused) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 5/7] drm/i915: Program GuC MAX IDLE Count
Looks good to me. Reviewed-by: Alex Dai On 09/11/2015 09:47 PM, Sagar Arun Kamble wrote: Cc: Alex Dai Cc: Tom O'Rourke Cc: Akash Goel Signed-off-by: Sagar Arun Kamble --- drivers/gpu/drm/i915/i915_guc_reg.h | 1 + drivers/gpu/drm/i915/intel_pm.c | 4 2 files changed, 5 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_guc_reg.h b/drivers/gpu/drm/i915/i915_guc_reg.h index 8c8e574..9d79a6b 100644 --- a/drivers/gpu/drm/i915/i915_guc_reg.h +++ b/drivers/gpu/drm/i915/i915_guc_reg.h @@ -53,6 +53,7 @@ #define START_DMA (1<<0) #define DMA_GUC_WOPCM_OFFSET 0xc340 #define GUC_WOPCM_OFFSET_VALUE0x8 /* 512KB */ +#define GUC_MAX_IDLE_COUNT 0xC3E4 #define GUC_WOPCM_SIZE 0xc050 #define GUC_WOPCM_SIZE_VALUE (0x80 << 12)/* 512KB */ diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 4d6bb6b..6843a48 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -4841,6 +4841,10 @@ static void gen9_enable_rc6(struct drm_device *dev) I915_WRITE(GEN6_RC_IDLE_HYSTERSIS, 25); /* 25 * 1280ns */ for_each_ring(ring, dev_priv, unused) I915_WRITE(RING_MAX_IDLE(ring->mmio_base), 10); + + if (HAS_GUC_UCODE(dev)) + I915_WRITE(GUC_MAX_IDLE_COUNT, 0xA); + I915_WRITE(GEN6_RC_SLEEP, 0); I915_WRITE(GEN6_RC6_THRESHOLD, 37500); /* 37.5/125ms per EI */ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/7] drm/i915: Add IS_SKL_GT3 and IS_SKL_GT4 macro.
Looks good to me.
Reviewed-by: Alex Dai
On 09/11/2015 09:47 PM, Sagar Arun Kamble wrote:
It will be usefull to specify w/a that affects only SKL GT3 and GT4.
Signed-off-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/i915_drv.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b5db246..1e48c86 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2491,6 +2491,11 @@ struct drm_i915_cmd_table {
#define IS_SKL_ULX(dev) (INTEL_DEVID(dev) == 0x190E || \
INTEL_DEVID(dev) == 0x1915 || \
INTEL_DEVID(dev) == 0x191E)
+#define IS_SKL_GT3(dev)(IS_SKYLAKE(dev) && \
+(INTEL_DEVID(dev) & 0x00F0) == 0x0020)
+#define IS_SKL_GT4(dev)(IS_SKYLAKE(dev) && \
+(INTEL_DEVID(dev) & 0x00F0) == 0x0030)
+
#define IS_PRELIMINARY_HW(intel_info) ((intel_info)->is_preliminary)
#define SKL_REVID_A0 (0x0)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 7/7] drm/i915/bxt: WaGsvDisableTurbo
Looks good to me.
Reviewed-by: Alex Dai
On 09/11/2015 09:47 PM, Sagar Arun Kamble wrote:
Disable Turbo on steppings prior to B0 on BXT due to hangs seen during GT CPD
exit.
Change-Id: I50c5c03f59f5ba092db19e17234951d89db42c6c
Signed-off-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/intel_pm.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 6843a48..90d8834 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4473,6 +4473,10 @@ static void gen6_set_rps(struct drm_device *dev, u8 val)
{
struct drm_i915_private *dev_priv = dev->dev_private;
+ /* WaGsvDisableTurbo: Workaround to disable turbo on BXT A* */
+ if (IS_BROXTON(dev) && (INTEL_REVID(dev) < BXT_REVID_B0))
+ return;
+
WARN_ON(!mutex_is_locked(&dev_priv->rps.hw_lock));
WARN_ON(val > dev_priv->rps.max_freq);
WARN_ON(val < dev_priv->rps.min_freq);
@@ -4793,6 +4797,12 @@ static void gen9_enable_rps(struct drm_device *dev)
gen6_init_rps_frequencies(dev);
+ /* WaGsvDisableTurbo: Workaround to disable turbo on BXT A* */
+ if (IS_BROXTON(dev) && (INTEL_REVID(dev) < BXT_REVID_B0)) {
+ intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
+ return;
+ }
+
/* Program defaults and thresholds for RPS*/
I915_WRITE(GEN6_RC_VIDEO_FREQ,
GEN9_FREQUENCY(dev_priv->rps.rp1_freq));
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/7] drm/i915: WaRsDisableCoarsePowerGating
Looks good to me. Reviewed-by: Alex Dai On 09/11/2015 09:47 PM, Sagar Arun Kamble wrote: WaRsDisableCoarsePowerGating: Coarse Power Gating (CPG) needs to be disabled for platforms prior to BXT B0 and SKL GT3/GT4 till E0. v2: Added GT3/GT4 Check. Change-Id: Ia3c4c16e050c88d3e259f601054875c812d69c3a Signed-off-by: Sagar Arun Kamble --- drivers/gpu/drm/i915/intel_pm.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 1f6b5bb..c93d3a7 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -4853,11 +4853,14 @@ static void gen9_enable_rc6(struct drm_device *dev) /* * 3b: Enable Coarse Power Gating only when RC6 is enabled. -* WaDisableRenderPowerGating:skl,bxt - Render PG need to be disabled with RC6. +* WaRsDisableCoarsePowerGating:skl,bxt - Render/Media PG need to be disabled with RC6. */ - I915_WRITE(GEN9_PG_ENABLE, (rc6_mask & GEN6_RC_CTL_RC6_ENABLE) ? - GEN9_MEDIA_PG_ENABLE : 0); - + if ((IS_BROXTON(dev) && (INTEL_REVID(dev) < BXT_REVID_B0)) || + ((IS_SKL_GT3(dev) || IS_SKL_GT4(dev)) && (INTEL_REVID(dev) <= SKL_REVID_E0))) + I915_WRITE(GEN9_PG_ENABLE, 0); + else + I915_WRITE(GEN9_PG_ENABLE, (rc6_mask & GEN6_RC_CTL_RC6_ENABLE) ? + (GEN9_RENDER_PG_ENABLE | GEN9_MEDIA_PG_ENABLE) : 0); intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL); ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/1] drm/i915: Direct all DE interrupts to host.
On Fri, Sep 11, 2015 at 05:44:32AM -0700, Kamble, Sagar A wrote: > Due to flip interrupts routed to GuC, GuC stays awake always and GT does not > enter RC6. > GuC firmware should re-direct to GuC those interrupts that it can handle. > > v2: Commit message change and routing all interrupts to host. (Tom) > > Cc: Alex Dai > Cc: Tom O'Rourke > Cc: Akash Goel > Signed-off-by: Sagar Arun Kamble > --- > drivers/gpu/drm/i915/intel_guc_loader.c | 8 ++-- > 1 file changed, 2 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c > b/drivers/gpu/drm/i915/intel_guc_loader.c > index 5eafd31..0b047c4 100644 > --- a/drivers/gpu/drm/i915/intel_guc_loader.c > +++ b/drivers/gpu/drm/i915/intel_guc_loader.c > @@ -110,12 +110,8 @@ static void direct_interrupts_to_guc(struct > drm_i915_private *dev_priv) > for_each_ring(ring, dev_priv, i) > I915_WRITE(RING_MODE_GEN7(ring), irqs); > > - /* tell DE to send (all) flip_done to GuC */ > - irqs = DERRMR_PIPEA_PRI_FLIP_DONE | DERRMR_PIPEA_SPR_FLIP_DONE | > -DERRMR_PIPEB_PRI_FLIP_DONE | DERRMR_PIPEB_SPR_FLIP_DONE | > -DERRMR_PIPEC_PRI_FLIP_DONE | DERRMR_PIPEC_SPR_FLIP_DONE; > - /* Unmasked bits will cause GuC response message to be sent */ > - I915_WRITE(DE_GUCRMR, ~irqs); > + /* tell DE to send nothing to GuC */ > + I915_WRITE(DE_GUCRMR, ~0); [TOR:] Should the host driver be writing these bits in DE_GUCRMR at all? An alternative approach would let GuC set/clear these bits based on whether or not GuC wants to handle the resulting interrupts; the host driver should not touch these bits since the host driver does not know what GuC wants to do (or may have already done with DE_GUCRMR register). Thanks, Tom > > /* route USER_INTERRUPT to Host, all others are sent to GuC. */ > irqs = GT_RENDER_USER_INTERRUPT << GEN8_RCS_IRQ_SHIFT | > -- > 1.9.1 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 6/7] drm/i915/guc: Notify coarse power gating configuration to GuC properly
This one can be discarded and I will amend a fix to my other patch series.
Thanks,
Alex
On 09/11/2015 09:47 PM, Sagar Arun Kamble wrote:
From: Alex Dai
GuC expects two bits for Render and Media domain separately when
driver sends data via host2guc SAMPLE_FORCEWAKE when full coarse power
gating is enabled. Bit 0 is for Render and bit 1 is for Media domain.
Signed-off-by: Alex Dai
Signed-off-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/i915_guc_submission.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 792d0b9..05d1eff4 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -155,10 +155,17 @@ static int host2guc_sample_forcewake(struct intel_guc
*guc,
struct i915_guc_client *client)
{
struct drm_i915_private *dev_priv = guc_to_i915(guc);
+ struct drm_device *dev = dev_priv->dev;
u32 data[2];
data[0] = HOST2GUC_ACTION_SAMPLE_FORCEWAKE;
- data[1] = (intel_enable_rc6(dev_priv->dev)) ? 1 : 0;
+
+ /* Notify GuC about Coarse Power Gating where supported */
+ if ((IS_BROXTON(dev) && (INTEL_REVID(dev) < BXT_REVID_B0)) ||
+((IS_SKL_GT3(dev) || IS_SKL_GT4(dev)) && (INTEL_REVID(dev) <=
SKL_REVID_E0)))
+ data[1] = 0;
+else
+ data[1] = (intel_enable_rc6(dev)) ? 3 : 0;
return host2guc_action(guc, data, 2);
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/7] drm/i915: WaRsUseTimeoutMode
Looks good to me.
Reviewed-by: Alex Dai
On 09/11/2015 09:47 PM, Sagar Arun Kamble wrote:
Enable TO mode for RC6 for SKL till D0 and BXT till A0.
Cc: Tom O'Rourke
Cc: Akash Goel
Signed-off-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/intel_pm.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index c93d3a7..6e4818d 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4847,9 +4847,16 @@ static void gen9_enable_rc6(struct drm_device *dev)
rc6_mask = GEN6_RC_CTL_RC6_ENABLE;
DRM_INFO("RC6 %s\n", (rc6_mask & GEN6_RC_CTL_RC6_ENABLE) ?
"on" : "off");
- I915_WRITE(GEN6_RC_CONTROL, GEN6_RC_CTL_HW_ENABLE |
- GEN6_RC_CTL_EI_MODE(1) |
- rc6_mask);
+
+ if ((IS_SKYLAKE(dev) && INTEL_REVID(dev) <= SKL_REVID_D0) ||
+ (IS_BROXTON(dev) && INTEL_REVID(dev) <= BXT_REVID_A0))
+I915_WRITE(GEN6_RC_CONTROL, GEN6_RC_CTL_HW_ENABLE |
+GEN7_RC_CTL_TO_MODE |
+rc6_mask);
+else
+I915_WRITE(GEN6_RC_CONTROL, GEN6_RC_CTL_HW_ENABLE |
+GEN6_RC_CTL_EI_MODE(1) |
+rc6_mask);
/*
* 3b: Enable Coarse Power Gating only when RC6 is enabled.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [git pull] drm for 4.3
On Mon, Sep 07, 2015 at 02:45:59PM -0400, Dave Jones wrote: > On Fri, Sep 04, 2015 at 11:40:53PM +0100, Dave Airlie wrote: > > > > Hi Linus, > > > > This is the main pull request for the drm for 4.3. Nouveau is probably > the biggest > > amount of changes in here, since it missed 4.2. Highlights below, along > with the usual > > bunch of fixes. There are a few minor conflicts with your tree but > nothing > > you can't handle. All stuff outside drm should have applicable acks. > > > > Highlights: > > > > ... > > i915: > > Skylake support enabled by default > > legacy modesetting using atomic infrastructure > > Skylake fixes > > GEN9 workarounds > > Since this merge, I'm seeing this twice during boot.. And still there in -rc2. Several other people reported this too, and they also got no reponse. I'll start bisecting when I get home tonight. It shouldn't be too hard, as 4.2 was fine. Dave > [ cut here ] > WARNING: CPU: 0 PID: 6 at drivers/gpu/drm/i915/intel_display.c:1377 > assert_planes_disabled+0xdf/0x140() > plane A assertion failure, should be disabled but not > CPU: 0 PID: 6 Comm: kworker/u8:0 Not tainted 4.2.0-think+ #9 > Workqueue: events_unbound async_run_entry_fn > 0561 88050392b6f8 8d7dccce 88050392b740 > 88050392b730 8d079ee2 880500a6 > 8805008e99c8 88050392b790 > Call Trace: > [] dump_stack+0x4e/0x79 > [] warn_slowpath_common+0x82/0xc0 > [] warn_slowpath_fmt+0x4c/0x50 > [] assert_planes_disabled+0xdf/0x140 > [] intel_disable_pipe+0x4b/0x2c0 > [] haswell_crtc_disable+0x8a/0x2e0 > [] intel_atomic_commit+0xff/0x1320 > [] ? drm_atomic_check_only+0x21e/0x550 > [] drm_atomic_commit+0x37/0x60 > [] drm_atomic_helper_set_config+0x1c5/0x430 > [] drm_mode_set_config_internal+0x65/0x110 > [] restore_fbdev_mode+0xbe/0xe0 > [] drm_fb_helper_restore_fbdev_mode_unlocked+0x25/0x70 > [] drm_fb_helper_set_par+0x2d/0x50 > [] intel_fbdev_set_par+0x1a/0x60 > [] fbcon_init+0x545/0x5d0 > [] visual_init+0xca/0x130 > [] do_bind_con_driver+0x1c5/0x3b0 > [] do_take_over_console+0x149/0x1a0 > [] do_fbcon_takeover+0x57/0xb0 > [] fbcon_event_notify+0x66c/0x760 > [] notifier_call_chain+0x3e/0xb0 > [] __blocking_notifier_call_chain+0x4d/0x70 > [] blocking_notifier_call_chain+0x16/0x20 > [] fb_notifier_call_chain+0x1b/0x20 > [] register_framebuffer+0x1e7/0x300 > [] drm_fb_helper_initial_config+0x252/0x3e0 > [] intel_fbdev_initial_config+0x1b/0x20 > [] async_run_entry_fn+0x4a/0x140 > [] process_one_work+0x1fd/0x670 > [] ? process_one_work+0x16c/0x670 > [] worker_thread+0x4e/0x450 > [] ? process_one_work+0x670/0x670 > [] kthread+0x101/0x120 > [] ? kthread_create_on_node+0x250/0x250 > [] ret_from_fork+0x3f/0x70 > [] ? kthread_create_on_node+0x250/0x250 > ---[ end trace 54cab2e0c772d5d9 ]--- > > > 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3 > Processor Integrated Graphics Controller (rev 06) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/skl+: Fix Watermark calculation for Broxton
In case of Y-Tiling, "plane_blocks_per_line" calculation is different
than X/None-Tiling case.
This patch corrects this calculation according to Bspec.
plane blocks per line = Plane memory format is Y tile ?
ceiling[4 * plane bytes per line / 512]/4 :
ceiling[plane bytes per line / 512]
As per BSpec Don't increment selected "result_blocks" & "result_lines"
in case of BROXTON.
Signed-off-by: Kumar, Mahesh
---
drivers/gpu/drm/i915/intel_pm.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index a1ed920..5cfb5d9 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3247,7 +3247,13 @@ static bool skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
latency);
plane_bytes_per_line = p_params->horiz_pixels * bytes_per_pixel;
- plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512);
+
+ if (p_params->tiling == I915_FORMAT_MOD_Y_TILED ||
+ p_params->tiling == I915_FORMAT_MOD_Yf_TILED) {
+ plane_blocks_per_line = DIV_ROUND_UP(4 * plane_bytes_per_line,
512);
+ plane_blocks_per_line /= 4;
+ } else
+ plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512);
if (p_params->tiling == I915_FORMAT_MOD_Y_TILED ||
p_params->tiling == I915_FORMAT_MOD_Yf_TILED) {
@@ -3277,7 +3283,7 @@ static bool skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
res_blocks = selected_result + 1;
res_lines = DIV_ROUND_UP(selected_result, plane_blocks_per_line);
- if (level >= 1 && level <= 7) {
+ if (level >= 1 && level <= 7 && !IS_BROXTON(dev_priv->dev)) {
if (p_params->tiling == I915_FORMAT_MOD_Y_TILED ||
p_params->tiling == I915_FORMAT_MOD_Yf_TILED)
res_lines += 4;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/skl: Correct other-pipe watermark update condition check
If ddb allocation for planes in current CRTC is changed, that doesn't lead to ddb allocation change for other CRTCs, because our DDB allocation is not dynamic according to plane parameters, ddb is allocated according to number of CRTC enabled, & divided equally among CTRC's. In current condition check during Watermark calculation, if number of plane/ddb allocation changes for current CRTC, Watermark for other pipes are recalculated. But there is no change in DDB allocation of other pipe so watermark is also not changed, This leads to warning messages. WARN_ON(!wm_changed) This patch corrects this and check if DDB allocation for pipes is changed, then only recalculate watermarks. Signed-off-by: Kumar, Mahesh --- drivers/gpu/drm/i915/intel_pm.c | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 62de97e..a1ed920 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -3127,14 +3127,12 @@ static bool skl_ddb_allocation_changed(const struct skl_ddb_allocation *new_ddb, struct drm_device *dev = intel_crtc->base.dev; struct drm_i915_private *dev_priv = dev->dev_private; const struct skl_ddb_allocation *cur_ddb = &dev_priv->wm.skl_hw.ddb; - enum pipe pipe = intel_crtc->pipe; - - if (memcmp(new_ddb->plane[pipe], cur_ddb->plane[pipe], - sizeof(new_ddb->plane[pipe]))) - return true; - if (memcmp(&new_ddb->cursor[pipe], &cur_ddb->cursor[pipe], - sizeof(new_ddb->cursor[pipe]))) + /* +* If ddb allocation of pipes chenged, it may require recalculation of +* watermarks +*/ + if (memcmp(new_ddb->pipe, cur_ddb->pipe, sizeof(new_ddb->pipe))) return true; return false; -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/bxt: eDP low vswing support
Reviewed-by: Sivakumar Thulasimani
On 9/18/2015 2:11 PM, Sonika Jindal wrote:
Adding voltage swing table for edp to support low vswings.
Signed-off-by: Sonika Jindal
---
drivers/gpu/drm/i915/intel_ddi.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 0d9b304..17281bc 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -256,9 +256,6 @@ struct bxt_ddi_buf_trans {
bool default_index; /* true if the entry represents default value */
};
-/* BSpec does not define separate vswing/pre-emphasis values for eDP.
- * Using DP values for eDP as well.
- */
static const struct bxt_ddi_buf_trans bxt_ddi_translations_dp[] = {
/* Idx NT mV diff db */
{ 52, 0, 0, 128, true }, /* 0: 400 0 */
@@ -273,6 +270,20 @@ static const struct bxt_ddi_buf_trans
bxt_ddi_translations_dp[] = {
{ 154, 0x9A, 1, 128, false }, /* 9: 12000 */
};
+static const struct bxt_ddi_buf_trans bxt_ddi_translations_edp[] = {
+ /* Idx NT mV diff db */
+ { 26, 0, 0, 128, false }, /* 0: 200 0 */
+ { 38, 0, 0, 112, false }, /* 1: 200 1.5 */
+ { 48, 0, 0, 96, false }, /* 2: 200 4 */
+ { 54, 0, 0, 69, false }, /* 3: 200 6 */
+ { 32, 0, 0, 128, false }, /* 4: 250 0 */
+ { 48, 0, 0, 104, false }, /* 5: 250 1.5 */
+ { 54, 0, 0, 85, false }, /* 6: 250 4 */
+ { 43, 0, 0, 128, false }, /* 7: 300 0 */
+ { 54, 0, 0, 101, false }, /* 8: 300 1.5 */
+ { 48, 0, 0, 128, false }, /* 9: 300 0 */
+};
+
/* BSpec has 2 recommended values - entries 0 and 8.
* Using the entry with higher vswing.
*/
@@ -2113,7 +2124,11 @@ static void bxt_ddi_vswing_sequence(struct drm_device
*dev, u32 level,
u32 n_entries, i;
uint32_t val;
- if (type == INTEL_OUTPUT_DISPLAYPORT || type == INTEL_OUTPUT_EDP) {
+ if (type == INTEL_OUTPUT_EDP && dev_priv->edp_low_vswing) {
+ n_entries = ARRAY_SIZE(bxt_ddi_translations_edp);
+ ddi_translations = bxt_ddi_translations_edp;
+ } else if (type == INTEL_OUTPUT_DISPLAYPORT
+ || type == INTEL_OUTPUT_EDP) {
n_entries = ARRAY_SIZE(bxt_ddi_translations_dp);
ddi_translations = bxt_ddi_translations_dp;
} else if (type == INTEL_OUTPUT_HDMI) {
--
regards,
Sivakumar
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/bxt: Set oscaledcompmethod to enable scale value
Reviewed-by: Sivakumar Thulasimani
On 9/18/2015 2:11 PM, Sonika Jindal wrote:
Bspec update tells that we have to enable oscaledcompmethod instead of
ouniqetrangenmethod for enabling scale value during swing programming.
Also, scale value is 'don't care' for other levels except the last entry
translation table. So, make it 0 instead of 0x9A.
Signed-off-by: Sonika Jindal
---
drivers/gpu/drm/i915/i915_reg.h |2 +-
drivers/gpu/drm/i915/intel_ddi.c | 22 +++---
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 812b7b2..cec6546 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1395,7 +1395,7 @@ enum skl_disp_power_wells {
#define BXT_PORT_TX_DW3_LN0(port) _PORT3(port, _PORT_TX_DW3_LN0_A, \
_PORT_TX_DW3_LN0_B, \
_PORT_TX_DW3_LN0_C)
-#define UNIQE_TRANGE_EN_METHOD (1 << 27)
+#define SCALE_DCOMP_METHOD (1 << 26)
#define _PORT_TX_DW4_LN0_A 0x162510
#define _PORT_TX_DW4_LN0_B0x6C510
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index fec51df..0d9b304 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -261,15 +261,15 @@ struct bxt_ddi_buf_trans {
*/
static const struct bxt_ddi_buf_trans bxt_ddi_translations_dp[] = {
/* Idx NT mV diff db */
- { 52, 0x9A, 0, 128, true }, /* 0: 400 0 */
- { 78, 0x9A, 0, 85, false }, /* 1: 400 3.5 */
- { 104, 0x9A, 0, 64, false }, /* 2: 400 6 */
- { 154, 0x9A, 0, 43, false }, /* 3: 400 9.5 */
- { 77, 0x9A, 0, 128, false }, /* 4: 600 0 */
- { 116, 0x9A, 0, 85, false }, /* 5: 600 3.5 */
- { 154, 0x9A, 0, 64, false }, /* 6: 600 6 */
- { 102, 0x9A, 0, 128, false }, /* 7: 800 0 */
- { 154, 0x9A, 0, 85, false }, /* 8: 800 3.5 */
+ { 52, 0, 0, 128, true }, /* 0: 400 0 */
+ { 78, 0, 0, 85, false }, /* 1: 400 3.5 */
+ { 104, 0, 0, 64, false }, /* 2: 400 6 */
+ { 154, 0, 0, 43, false }, /* 3: 400 9.5 */
+ { 77, 0, 0, 128, false }, /* 4: 600 0 */
+ { 116, 0, 0, 85, false }, /* 5: 600 3.5 */
+ { 154, 0, 0, 64, false }, /* 6: 600 6 */
+ { 102, 0, 0, 128, false }, /* 7: 800 0 */
+ { 154, 0, 0, 85, false }, /* 8: 800 3.5 */
{ 154, 0x9A, 1, 128, false }, /* 9: 12000 */
};
@@ -2151,9 +2151,9 @@ static void bxt_ddi_vswing_sequence(struct drm_device *dev, u32 level,
I915_WRITE(BXT_PORT_TX_DW2_GRP(port), val);
val = I915_READ(BXT_PORT_TX_DW3_LN0(port));
- val &= ~UNIQE_TRANGE_EN_METHOD;
+ val &= ~SCALE_DCOMP_METHOD;
if (ddi_translations[level].enable)
- val |= UNIQE_TRANGE_EN_METHOD;
+ val |= SCALE_DCOMP_METHOD;
I915_WRITE(BXT_PORT_TX_DW3_GRP(port), val);
val = I915_READ(BXT_PORT_TX_DW4_LN0(port));
--
regards,
Sivakumar
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/5] drm/i915: WaRsDisableCoarsePowerGating
On 08/23/2015 05:22 AM, Sagar Arun Kamble wrote: WaRsDisableCoarsePowerGating: Coarse Power Gating (CPG) needs to be disabled for platforms prior to BXT B0 and till SKL E0. Change-Id: Ia3c4c16e050c88d3e259f601054875c812d69c3a Signed-off-by: Sagar Arun Kamble --- drivers/gpu/drm/i915/intel_pm.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 75f1c8c..c0345d2 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -4840,11 +4840,14 @@ static void gen9_enable_rc6(struct drm_device *dev) /* * 3b: Enable Coarse Power Gating only when RC6 is enabled. -* WaDisableRenderPowerGating:skl,bxt - Render PG need to be disabled with RC6. +* WaRsDisableCoarsePowerGating:skl,bxt - Render/Media PG need to be disabled with RC6. */ - I915_WRITE(GEN9_PG_ENABLE, (rc6_mask & GEN6_RC_CTL_RC6_ENABLE) ? - GEN9_MEDIA_PG_ENABLE : 0); - + if ((IS_BROXTON(dev) && (INTEL_REVID(dev) < BXT_REVID_B0)) || + (IS_SKYLAKE(dev) && (INTEL_REVID(dev) <= SKL_REVID_E0))) + I915_WRITE(GEN9_PG_ENABLE, 0); + else + I915_WRITE(GEN9_PG_ENABLE, (rc6_mask & GEN6_RC_CTL_RC6_ENABLE) ? + (GEN9_RENDER_PG_ENABLE | GEN9_MEDIA_PG_ENABLE) : 0); intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL); Reviewed by: Alex Dai . ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 35/43] drm/i915: Move __raw_i915_read8() & co. into i915_drv.h
On Mon, Sep 21, 2015 at 09:26:11AM -0700, Jesse Barnes wrote:
> On 09/18/2015 12:26 PM, Ville Syrjälä wrote:
> > On Fri, Sep 18, 2015 at 07:44:34PM +0100, Chris Wilson wrote:
> > Yeah I guess that was a crappy example. Trying to think of a better one,
> > I figure execlist status could be read from memory, but apparently
> > that's just mmio. I guess the context update + ELSP write is something
> > we do from the irq handler, but there are plenty of barriers between
> > those two it seems. Maybe there's no good example here.
> >
> >>
> >> Anyway, I thought we had strongly ordered reads on x64/x32?
> >
> > The cpu won't reoder reads vs. reads, or writes vs. writes for that
> > matter if you ignore the nt stuff and whatnot. But AFAIU the whole
> > point of _relaxed() on x86 is that it allows the compiler to reoder
> > memory vs. mmio any which way it wants.
>
> If you mean the top level readX_relaxed() functions, those were more
> about re-ordering on a large I/O fabric than compiler re-ordering. I'm
> not sure how the compiler handles things these days; I thought maybe the
> volatile accesses would imply a re-order barrier as well, since they
> could have side effects the compiler can't anticipate (i.e. re-ordering
> even read after read could change behavior). But it would be good to
> double check... and according to memory-barriers.txt we should be safe
> there, from the readX_relaxed() section:
>
> "Note that relaxed accesses to the same peripheral are guaranteed to be
> ordered with respect to each other."
We have
#define barrier() asm volatile("" ::: "memory")
so I take it someone definitely thinks just volatile isn't enough to
keep the compiler in check.
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] drm/i915/bxt: WaGsvDisableTurbo
Looks fine to me.
Reviewed by: Alex Dai .
On 08/23/2015 05:22 AM, Sagar Arun Kamble wrote:
Disable Turbo on steppings prior to B0 on BXT due to hangs seen during GT CPD
exit.
Change-Id: I50c5c03f59f5ba092db19e17234951d89db42c6c
Signed-off-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/intel_pm.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index fff0c22..75f1c8c 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4450,6 +4450,10 @@ static void gen6_set_rps(struct drm_device *dev, u8 val)
{
struct drm_i915_private *dev_priv = dev->dev_private;
+ /* WaGsvDisableTurbo: Workaround to disable turbo on BXT A* */
+ if (IS_BROXTON(dev) && (INTEL_REVID(dev) < BXT_REVID_B0))
+ return;
+
WARN_ON(!mutex_is_locked(&dev_priv->rps.hw_lock));
WARN_ON(val > dev_priv->rps.max_freq);
WARN_ON(val < dev_priv->rps.min_freq);
@@ -4770,6 +4774,12 @@ static void gen9_enable_rps(struct drm_device *dev)
gen6_init_rps_frequencies(dev);
+ /* WaGsvDisableTurbo: Workaround to disable turbo on BXT A* */
+ if (IS_BROXTON(dev) && (INTEL_REVID(dev) < BXT_REVID_B0)) {
+ intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
+ return;
+ }
+
/* Program defaults and thresholds for RPS*/
I915_WRITE(GEN6_RC_VIDEO_FREQ,
GEN9_FREQUENCY(dev_priv->rps.rp1_freq));
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/5] drm/i915: Increase maximum polling time to 50ms for forcewake request/clear ack
Looks fine to me. Reviewed by: Alex Dai . On 08/23/2015 05:22 AM, Sagar Arun Kamble wrote: On BXT, We Observe timeout for forcewake request completion with 2ms polling period as given here: [drm:fw_domains_get] ERROR render: timed out waiting for forcewake ack request. Polling for 50ms is recommended to avoid these timeouts. Change-Id: Ie715b0069a3049606e9602bc5e97a6511890864d Signed-off-by: Sagar Arun Kamble --- drivers/gpu/drm/i915/intel_uncore.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c index 9d3c2e4..2df03b1 100644 --- a/drivers/gpu/drm/i915/intel_uncore.c +++ b/drivers/gpu/drm/i915/intel_uncore.c @@ -27,7 +27,7 @@ #include -#define FORCEWAKE_ACK_TIMEOUT_MS 2 +#define FORCEWAKE_ACK_TIMEOUT_MS 50 #define __raw_i915_read8(dev_priv__, reg__) readb((dev_priv__)->regs + (reg__)) #define __raw_i915_write8(dev_priv__, reg__, val__) writeb(val__, (dev_priv__)->regs + (reg__)) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 6/7] drm/i915/guc: Notify coarse power gating configuration to GuC properly
On 09/11/2015 09:47 PM, Sagar Arun Kamble wrote:
From: Alex Dai
GuC expects two bits for Render and Media domain separately when
driver sends data via host2guc SAMPLE_FORCEWAKE when full coarse power
gating is enabled. Bit 0 is for Render and bit 1 is for Media domain.
Signed-off-by: Alex Dai
Signed-off-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/i915_guc_submission.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 792d0b9..05d1eff4 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -155,10 +155,17 @@ static int host2guc_sample_forcewake(struct intel_guc
*guc,
struct i915_guc_client *client)
{
struct drm_i915_private *dev_priv = guc_to_i915(guc);
+ struct drm_device *dev = dev_priv->dev;
u32 data[2];
data[0] = HOST2GUC_ACTION_SAMPLE_FORCEWAKE;
- data[1] = (intel_enable_rc6(dev_priv->dev)) ? 1 : 0;
+
+ /* Notify GuC about Coarse Power Gating where supported */
+ if ((IS_BROXTON(dev) && (INTEL_REVID(dev) < BXT_REVID_B0)) ||
+((IS_SKL_GT3(dev) || IS_SKL_GT4(dev)) && (INTEL_REVID(dev) <=
SKL_REVID_E0)))
+ data[1] = 0;
+else
+ data[1] = (intel_enable_rc6(dev)) ? 3 : 0;
Please hold off this patch. I plan to squash it into
http://lists.freedesktop.org/archives/intel-gfx/2015-September/075959.html,
where we remove the magic code '3' here by defining forcewake domain flags.
Thanks,
Alex
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 35/43] drm/i915: Move __raw_i915_read8() & co. into i915_drv.h
On 09/21/2015 09:53 AM, Ville Syrjälä wrote:
> On Mon, Sep 21, 2015 at 09:26:11AM -0700, Jesse Barnes wrote:
>> On 09/18/2015 12:26 PM, Ville Syrjälä wrote:
>>> On Fri, Sep 18, 2015 at 07:44:34PM +0100, Chris Wilson wrote:
>>> Yeah I guess that was a crappy example. Trying to think of a better one,
>>> I figure execlist status could be read from memory, but apparently
>>> that's just mmio. I guess the context update + ELSP write is something
>>> we do from the irq handler, but there are plenty of barriers between
>>> those two it seems. Maybe there's no good example here.
>>>
Anyway, I thought we had strongly ordered reads on x64/x32?
>>>
>>> The cpu won't reoder reads vs. reads, or writes vs. writes for that
>>> matter if you ignore the nt stuff and whatnot. But AFAIU the whole
>>> point of _relaxed() on x86 is that it allows the compiler to reoder
>>> memory vs. mmio any which way it wants.
>>
>> If you mean the top level readX_relaxed() functions, those were more
>> about re-ordering on a large I/O fabric than compiler re-ordering. I'm
>> not sure how the compiler handles things these days; I thought maybe the
>> volatile accesses would imply a re-order barrier as well, since they
>> could have side effects the compiler can't anticipate (i.e. re-ordering
>> even read after read could change behavior). But it would be good to
>> double check... and according to memory-barriers.txt we should be safe
>> there, from the readX_relaxed() section:
>>
>> "Note that relaxed accesses to the same peripheral are guaranteed to be
>> ordered with respect to each other."
>
> We have
> #define barrier() asm volatile("" ::: "memory")
>
> so I take it someone definitely thinks just volatile isn't enough to
> keep the compiler in check.
Yeah, maybe with respect to other, non-I/O targeted reads & writes
things get messier...
Jesse
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/23] drm: Add drm structures for palette color property
On Wed, Sep 16, 2015 at 11:07:01PM +0530, Shashank Sharma wrote:
> From: Kausal Malladi
>
> This patch adds new structures in DRM layer for Palette color
> correction.These structures will be used by user space agents
> to configure appropriate number of samples and Palette LUT for
> a platform.
>
> Signed-off-by: Shashank Sharma
> Signed-off-by: Kausal Malladi
> ---
> include/uapi/drm/drm.h | 27 +++
> 1 file changed, 27 insertions(+)
>
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index e3c642f..f72b916 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -840,6 +840,33 @@ struct drm_palette_caps {
> __u32 num_samples_after_ctm;
> };
>
> +struct drm_r32g32b32 {
> + /*
> + * Data is in U8.24 fixed point format.
> + * All platforms support values within [0, 1.0] range,
> + * for Red, Green and Blue colors.
> + */
> + __u32 r32;
> + __u32 g32;
> + __u32 b32;
> +};
> +
> +struct drm_palette {
> + /* Structure version. Should be 1 currently */
> + __u32 version;
I don't think we want to version the blobs. For one, we don't have a way
for userspace to ask for a specific version, so the kernel wouldn't know
which version it should return to each client.
If we ever need to come up with new version of a specific blob, I think we
just have to define another property for it. Either that or we'd some kind
of client cap stuff to negotiate the used version between the kernel and
a specific client.
Well, I suppose we migth be able to borrow the "flags+extend at the end"
trick we sometimes use for ioctl parameters to work for blobs too. But I
have a feeling we don't want to go there.
So yeah, I think we should go with the "blob layout is fixed for each
property" approach. Versioning then happens by introducing new versions
of the same property if needed.
> + /*
> + * This has to be a supported value during get call.
> + * Feature will be disabled if this is 0 while set
> + */
> + __u32 num_samples;
> + /*
> + * Starting of palette LUT in R32G32B32 format.
> + * Each of RGB value is in U8.24 fixed point format.
> + * Actual number of samples will depend upon num_samples
> + */
> + struct drm_r32g32b32 lut[0];
> +};
> +
> /* typedef area */
> #ifndef __KERNEL__
> typedef struct drm_clip_rect drm_clip_rect_t;
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 35/43] drm/i915: Move __raw_i915_read8() & co. into i915_drv.h
On 09/18/2015 12:26 PM, Ville Syrjälä wrote: > On Fri, Sep 18, 2015 at 07:44:34PM +0100, Chris Wilson wrote: > Yeah I guess that was a crappy example. Trying to think of a better one, > I figure execlist status could be read from memory, but apparently > that's just mmio. I guess the context update + ELSP write is something > we do from the irq handler, but there are plenty of barriers between > those two it seems. Maybe there's no good example here. > >> >> Anyway, I thought we had strongly ordered reads on x64/x32? > > The cpu won't reoder reads vs. reads, or writes vs. writes for that > matter if you ignore the nt stuff and whatnot. But AFAIU the whole > point of _relaxed() on x86 is that it allows the compiler to reoder > memory vs. mmio any which way it wants. If you mean the top level readX_relaxed() functions, those were more about re-ordering on a large I/O fabric than compiler re-ordering. I'm not sure how the compiler handles things these days; I thought maybe the volatile accesses would imply a re-order barrier as well, since they could have side effects the compiler can't anticipate (i.e. re-ordering even read after read could change behavior). But it would be good to double check... and according to memory-barriers.txt we should be safe there, from the readX_relaxed() section: "Note that relaxed accesses to the same peripheral are guaranteed to be ordered with respect to each other." Jesse ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/15] drm/i915: Add NV12 support to intel_framebuffer_init
> > > > + if (mode_cmd->modifier[1] == I915_FORMAT_MOD_Y_TILED
> > &&
> > > > + ((mode_cmd->offsets[1] / mode_cmd->pitches[1]) %
> > 4)) {
> > > > + DRM_DEBUG("tile-Y uv offset 0x%x isn't 4-line
> > aligned\n",
> > > > + mode_cmd->offsets[1]);
> > > > + return -EINVAL;
> > > > + }
> > >
> > > I was going to say I can't find anything in the spec to support this,
> > > but after some more reading I got it "The display hardware requires
> > > that the UV surface start satisfies four line alignment from the
> > > begining of the page." So the check should be something like
> > > ((offsets[1] & 0xfff) / pitches[1] % 4.
> > >
> Ignore my previous response for this. Yes, above check should
> check for 12-lsbs. Will update and respun shortly.
Submitted updated patch.
With this change, resolved all your feedback.
Is there any more feedback?
If not, can you issue R-B tag for the patches?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Clean up associated VMAs on context destruction
From: Tvrtko Ursulin
Prevent leaking VMAs and PPGTT VMs when objects are imported
via flink.
Scenario is that any VMAs created by the importer will be left
dangling after the importer exits, or destroys the PPGTT context
with which they are associated.
This is caused by object destruction not running when the
importer closes the buffer object handle due the reference held
by the exporter. This also leaks the VM since the VMA has a
reference on it.
In practice these leaks can be observed by stopping and starting
the X server on a kernel with fbcon compiled in. Every time
X server exits another VMA will be leaked against the fbcon's
frame buffer object.
Also on systems where flink buffer sharing is used extensively,
like Android, this leak has even more serious consequences.
This version is takes a general approach from the earlier work
by Rafael Barabalho (drm/i915: Clean-up PPGTT on context
destruction) and tries to incorporate the subsequent discussion
between Chris Wilson and Daniel Vetter.
On context destruction a worker thread is scheduled to unbind
all inactive VMAs for this VM.
v2:
Removed immediate cleanup on object retire - it was causing a
recursive VMA unbind via i915_gem_object_wait_rendering. And
it is in fact not even needed since by definition context
cleanup worker runs only after the last context reference has
been dropped, hence all VMAs against the VM belonging to the
context are already on the inactive list.
Signed-off-by: Tvrtko Ursulin
Testcase: igt/gem_ppgtt.c/flink-and-exit-vma-leak
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: Rafael Barbalho
Cc: Michel Thierry
---
drivers/gpu/drm/i915/i915_gem_context.c | 50 +
drivers/gpu/drm/i915/i915_gem_gtt.h | 2 ++
2 files changed, 52 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 74aa0c9929ba..714d71bae572 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -133,6 +133,49 @@ static int get_context_size(struct drm_device *dev)
return ret;
}
+static void
+i915_gem_context_cleanup_worker(struct work_struct *work)
+{
+ struct i915_hw_ppgtt *ppgtt = container_of(work, typeof(*ppgtt),
+ cleanup_work);
+ struct drm_device *dev = ppgtt->base.dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct i915_vma *vma, *next;
+ bool was_interruptible;
+
+ mutex_lock(&dev->struct_mutex);
+ was_interruptible = dev_priv->mm.interruptible;
+
+ WARN_ON(!list_empty(&ppgtt->base.active_list));
+
+ list_for_each_entry_safe(vma, next, &ppgtt->base.inactive_list,
+mm_list) {
+ dev_priv->mm.interruptible = false;
+ if (WARN_ON(i915_vma_unbind(vma)))
+ break;
+ }
+
+ i915_ppgtt_put(ppgtt);
+
+ dev_priv->mm.interruptible = was_interruptible;
+ mutex_unlock(&dev->struct_mutex);
+}
+
+static void i915_gem_context_clean(struct intel_context *ctx)
+{
+ struct i915_hw_ppgtt *ppgtt = ctx->ppgtt;
+
+ if (!ppgtt)
+ return;
+
+ /*
+* Unbind all inactive VMAs for this VM, but do it asynchronously.
+*/
+ INIT_WORK(&ppgtt->cleanup_work, i915_gem_context_cleanup_worker);
+ i915_ppgtt_get(ppgtt);
+ schedule_work(&ppgtt->cleanup_work);
+}
+
void i915_gem_context_free(struct kref *ctx_ref)
{
struct intel_context *ctx = container_of(ctx_ref, typeof(*ctx), ref);
@@ -142,6 +185,13 @@ void i915_gem_context_free(struct kref *ctx_ref)
if (i915.enable_execlists)
intel_lr_context_free(ctx);
+ /*
+* This context is going away and we need to remove all VMAs still
+* around. This is to handle imported shared objects for which
+* destructor did not run when their handles were closed.
+*/
+ i915_gem_context_clean(ctx);
+
i915_ppgtt_put(ctx->ppgtt);
if (ctx->legacy_hw_ctx.rcs_state)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 430cc283d3c9..c7426b76cd1d 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -375,6 +375,8 @@ struct i915_hw_ppgtt {
struct drm_i915_file_private *file_priv;
+ struct work_struct cleanup_work;
+
gen6_pte_t __iomem *pd_addr;
int (*enable)(struct i915_hw_ppgtt *ppgtt);
--
2.5.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 04/43] drm/i915: Parametrize fence registers
From: Ville Syrjälä
v2: Hide the 945 vs. rest of gen2/3 difference in the macro
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_gem_fence.c | 41 +++
drivers/gpu/drm/i915/i915_gpu_error.c | 21 +++---
drivers/gpu/drm/i915/i915_reg.h | 18 ++-
3 files changed, 39 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_fence.c
b/drivers/gpu/drm/i915/i915_gem_fence.c
index 6077dff..1cbfd5b 100644
--- a/drivers/gpu/drm/i915/i915_gem_fence.c
+++ b/drivers/gpu/drm/i915/i915_gem_fence.c
@@ -59,19 +59,19 @@ static void i965_write_fence_reg(struct drm_device *dev,
int reg,
struct drm_i915_gem_object *obj)
{
struct drm_i915_private *dev_priv = dev->dev_private;
- int fence_reg;
+ int fence_reg_lo, fence_reg_hi;
int fence_pitch_shift;
if (INTEL_INFO(dev)->gen >= 6) {
- fence_reg = FENCE_REG_SANDYBRIDGE_0;
- fence_pitch_shift = SANDYBRIDGE_FENCE_PITCH_SHIFT;
+ fence_reg_lo = FENCE_REG_GEN6_LO(reg);
+ fence_reg_hi = FENCE_REG_GEN6_HI(reg);
+ fence_pitch_shift = GEN6_FENCE_PITCH_SHIFT;
} else {
- fence_reg = FENCE_REG_965_0;
+ fence_reg_lo = FENCE_REG_965_LO(reg);
+ fence_reg_hi = FENCE_REG_965_HI(reg);
fence_pitch_shift = I965_FENCE_PITCH_SHIFT;
}
- fence_reg += reg * 8;
-
/* To w/a incoherency with non-atomic 64-bit register updates,
* we split the 64-bit update into two 32-bit writes. In order
* for a partial fence not to be evaluated between writes, we
@@ -81,8 +81,8 @@ static void i965_write_fence_reg(struct drm_device *dev, int
reg,
* For extra levels of paranoia, we make sure each step lands
* before applying the next step.
*/
- I915_WRITE(fence_reg, 0);
- POSTING_READ(fence_reg);
+ I915_WRITE(fence_reg_lo, 0);
+ POSTING_READ(fence_reg_lo);
if (obj) {
u32 size = i915_gem_obj_ggtt_size(obj);
@@ -103,14 +103,14 @@ static void i965_write_fence_reg(struct drm_device *dev,
int reg,
val |= 1 << I965_FENCE_TILING_Y_SHIFT;
val |= I965_FENCE_REG_VALID;
- I915_WRITE(fence_reg + 4, val >> 32);
- POSTING_READ(fence_reg + 4);
+ I915_WRITE(fence_reg_hi, val >> 32);
+ POSTING_READ(fence_reg_hi);
- I915_WRITE(fence_reg + 0, val);
- POSTING_READ(fence_reg);
+ I915_WRITE(fence_reg_lo, val);
+ POSTING_READ(fence_reg_lo);
} else {
- I915_WRITE(fence_reg + 4, 0);
- POSTING_READ(fence_reg + 4);
+ I915_WRITE(fence_reg_hi, 0);
+ POSTING_READ(fence_reg_hi);
}
}
@@ -149,13 +149,8 @@ static void i915_write_fence_reg(struct drm_device *dev,
int reg,
} else
val = 0;
- if (reg < 8)
- reg = FENCE_REG_830_0 + reg * 4;
- else
- reg = FENCE_REG_945_8 + (reg - 8) * 4;
-
- I915_WRITE(reg, val);
- POSTING_READ(reg);
+ I915_WRITE(FENCE_REG(reg), val);
+ POSTING_READ(FENCE_REG(reg));
}
static void i830_write_fence_reg(struct drm_device *dev, int reg,
@@ -186,8 +181,8 @@ static void i830_write_fence_reg(struct drm_device *dev,
int reg,
} else
val = 0;
- I915_WRITE(FENCE_REG_830_0 + reg * 4, val);
- POSTING_READ(FENCE_REG_830_0 + reg * 4);
+ I915_WRITE(FENCE_REG(reg), val);
+ POSTING_READ(FENCE_REG(reg));
}
inline static bool i915_gem_object_needs_mb(struct drm_i915_gem_object *obj)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 3379f9c..3b574c2 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -786,20 +786,15 @@ static void i915_gem_record_fences(struct drm_device *dev,
int i;
if (IS_GEN3(dev) || IS_GEN2(dev)) {
- for (i = 0; i < 8; i++)
- error->fence[i] = I915_READ(FENCE_REG_830_0 + (i * 4));
- if (IS_I945G(dev) || IS_I945GM(dev) || IS_G33(dev))
- for (i = 0; i < 8; i++)
- error->fence[i+8] = I915_READ(FENCE_REG_945_8 +
- (i * 4));
- } else if (IS_GEN5(dev) || IS_GEN4(dev))
- for (i = 0; i < 16; i++)
- error->fence[i] = I915_READ64(FENCE_REG_965_0 +
- (i * 8));
- else if (INTEL_INFO(dev)->gen >= 6)
for (i = 0; i < dev_priv->num_fence_regs; i++)
- error->fence[i] = I915_READ64(FENCE_REG_SANDYBRIDGE_0 +
-
Re: [Intel-gfx] [PATCH 9/9] drm/i915: fix FBC for cases where crtc->base.y is non-zero
On Mon, Sep 14, 2015 at 03:20:03PM -0300, Paulo Zanoni wrote:
> I only tested this on BDW and SKL, but since the register description
> is the same ever since gen4, let's assume that all gens take the same
> register format. If that's not true, then hopefully someone will
> bisect a bug to this patch and we'll fix it.
>
> Notice that the wrong fence offset register just means that the
> hardware tracking will be wrong.
>
> Testcases:
> - igt/kms_frontbuffer_tracking/fbc-1p-primscrn-pri-shrfb-draw-mmap-gtt
> - igt/kms_frontbuffer_tracking/fbc-2p-primscrn-pri-shrfb-draw-mmap-gtt
>
> v2:
> - Add intel_crtc->adjusted_{x,y} so this code can work independently
> of intel_gen4_compute_page_offset(). (Ville).
> - This version also works on SKL.
>
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_display.c | 9 +
> drivers/gpu/drm/i915/intel_drv.h | 2 ++
> drivers/gpu/drm/i915/intel_fbc.c | 25 -
> 3 files changed, 31 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index fc00867..c27a636 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2730,6 +2730,9 @@ static void i9xx_update_primary_plane(struct drm_crtc
> *crtc,
> (intel_crtc->config->pipe_src_w - 1) * pixel_size;
> }
>
> + intel_crtc->adjusted_x = x;
> + intel_crtc->adjusted_y = y;
> +
> I915_WRITE(reg, dspcntr);
>
> I915_WRITE(DSPSTRIDE(plane), fb->pitches[0]);
> @@ -2830,6 +2833,9 @@ static void ironlake_update_primary_plane(struct
> drm_crtc *crtc,
> }
> }
>
> + intel_crtc->adjusted_x = x;
> + intel_crtc->adjusted_y = y;
> +
> I915_WRITE(reg, dspcntr);
>
> I915_WRITE(DSPSTRIDE(plane), fb->pitches[0]);
> @@ -3082,6 +3088,9 @@ static void skylake_update_primary_plane(struct
> drm_crtc *crtc,
> }
> plane_offset = y_offset << 16 | x_offset;
>
> + intel_crtc->adjusted_x = x_offset;
> + intel_crtc->adjusted_y = y_offset;
> +
> I915_WRITE(PLANE_CTL(pipe, 0), plane_ctl);
> I915_WRITE(PLANE_OFFSET(pipe, 0), plane_offset);
> I915_WRITE(PLANE_SIZE(pipe, 0), plane_size);
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 02a755a..6054bcb 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -537,6 +537,8 @@ struct intel_crtc {
>* gen4+ this only adjusts up to a tile, offsets within a tile are
>* handled in the hw itself (with the TILEOFF register). */
> unsigned long dspaddr_offset;
> + int adjusted_x;
> + int adjusted_y;
>
> struct drm_i915_gem_object *cursor_bo;
> uint32_t cursor_addr;
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> b/drivers/gpu/drm/i915/intel_fbc.c
> index a3a97f2..2319dc5 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -41,6 +41,19 @@
> #include "intel_drv.h"
> #include "i915_drv.h"
>
> +/*
> + * In some platforms where the CRTC's x:0/y:0 coordinates doesn't match the
> + * frontbuffer's x:0/y:0 coordinates we lie to the hardware about the plane's
> + * origin so the x and y offsets can actually fit the registers. As a
> + * consequence, the fence doesn't really start exactly at the display plane
> + * address we program because it starts at the real start of the buffer, so
> we
> + * have to take this into consideration here.
> + */
> +static unsigned int get_crtc_fence_y_offset(struct intel_crtc *crtc)
> +{
> + return crtc->base.y - crtc->adjusted_y;
> +}
We may want to move over to using the plane state here in the future.
But for now it looks OK, so:
Reviewed-by: Ville Syrjälä
> +
> static void i8xx_fbc_disable(struct drm_i915_private *dev_priv)
> {
> u32 fbc_ctl;
> @@ -97,7 +110,7 @@ static void i8xx_fbc_enable(struct intel_crtc *crtc)
> fbc_ctl2 = FBC_CTL_FENCE_DBL | FBC_CTL_IDLE_IMM |
> FBC_CTL_CPU_FENCE;
> fbc_ctl2 |= FBC_CTL_PLANE(crtc->plane);
> I915_WRITE(FBC_CONTROL2, fbc_ctl2);
> - I915_WRITE(FBC_FENCE_OFF, crtc->base.y);
> + I915_WRITE(FBC_FENCE_OFF, get_crtc_fence_y_offset(crtc));
> }
>
> /* enable it... */
> @@ -135,7 +148,7 @@ static void g4x_fbc_enable(struct intel_crtc *crtc)
> dpfc_ctl |= DPFC_CTL_LIMIT_1X;
> dpfc_ctl |= DPFC_CTL_FENCE_EN | obj->fence_reg;
>
> - I915_WRITE(DPFC_FENCE_YOFF, crtc->base.y);
> + I915_WRITE(DPFC_FENCE_YOFF, get_crtc_fence_y_offset(crtc));
>
> /* enable it... */
> I915_WRITE(DPFC_CONTROL, dpfc_ctl | DPFC_CTL_EN);
> @@ -177,6 +190,7 @@ static void ilk_fbc_enable(struct intel_crtc *crtc)
> struct drm_i915_gem_object *obj = intel_fb_obj(fb);
> u32 dpfc_ctl;
> int threshold = dev_priv->fbc.threshold;
> + unsigned int y_offset
Re: [Intel-gfx] [PATCH 8/9] drm/i915: reject invalid formats for FBC
On Mon, Sep 14, 2015 at 03:20:02PM -0300, Paulo Zanoni wrote:
> This commit is essentially a rewrite of "drm/i915: Check pixel format
> for fbc" from Ville Syrjälä. The idea is the same, but the code is
> different due to all the changes that happened since his original
> patch. So any bugs are due to my bad rewrite.
>
> v2:
> - Drop the alpha formats (Ville).
>
> Testcases: igt/kms_frontbuffer_tracking/*fbc*-${format_name}-draw-*
> Credits-to: Ville Syrjälä
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_fbc.c | 32
> 2 files changed, 33 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index d22120f..4e44352 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -950,6 +950,7 @@ struct i915_fbc {
> FBC_IN_DBG_MASTER, /* kernel debugger is active */
> FBC_BAD_STRIDE, /* stride is not supported */
> FBC_PIXEL_RATE, /* pixel rate is too big */
> + FBC_PIXEL_FORMAT /* pixel format is invalid */
> } no_fbc_reason;
>
> bool (*fbc_enabled)(struct drm_i915_private *dev_priv);
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> b/drivers/gpu/drm/i915/intel_fbc.c
> index 56cf110..a3a97f2 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -484,6 +484,8 @@ const char *intel_no_fbc_reason_str(enum no_fbc_reason
> reason)
> return "framebuffer stride not supported";
> case FBC_PIXEL_RATE:
> return "pixel rate is too big";
> + case FBC_PIXEL_FORMAT:
> + return "pixel format is invalid";
> default:
> MISSING_CASE(reason);
> return "unknown reason";
> @@ -709,6 +711,31 @@ static bool stride_is_valid(struct drm_i915_private
> *dev_priv,
> return true;
> }
>
> +static bool pixel_format_is_valid(struct drm_framebuffer *fb)
> +{
> + struct drm_device *dev = fb->dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> +
> + /* Primary planes don't support alpha, so the "A" formats and "X"
> + * formats are one and the same. */
Stale comment. With that removed:
Reviewed-by: Ville Syrjälä
> + switch (fb->pixel_format) {
> + case DRM_FORMAT_XRGB:
> + case DRM_FORMAT_XBGR:
> + return true;
> + case DRM_FORMAT_XRGB1555:
> + case DRM_FORMAT_RGB565:
> + /* 16bpp not supported on gen2 */
> + if (IS_GEN2(dev))
> + return false;
> + /* WaFbcOnly1to1Ratio:ctg */
> + if (IS_G4X(dev_priv))
> + return false;
> + return true;
> + default:
> + return false;
> + }
> +}
> +
> /**
> * __intel_fbc_update - enable/disable FBC as needed, unlocked
> * @dev_priv: i915 device instance
> @@ -824,6 +851,11 @@ static void __intel_fbc_update(struct drm_i915_private
> *dev_priv)
> goto out_disable;
> }
>
> + if (!pixel_format_is_valid(fb)) {
> + set_no_fbc_reason(dev_priv, FBC_PIXEL_FORMAT);
> + goto out_disable;
> + }
> +
> /* If the kernel debugger is active, always disable compression */
> if (in_dbg_master()) {
> set_no_fbc_reason(dev_priv, FBC_IN_DBG_MASTER);
> --
> 2.5.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/38] drm/i915: fix handling gen8_emit_flush_coherentl3_wa result
On Mon, 21 Sep 2015, Andrzej Hajda wrote:
> The function can return negative value.
>
> The problem has been detected using proposed semantic patch
> scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1].
>
> [1]: http://permalink.gmane.org/gmane.linux.kernel/2038576
>
> Signed-off-by: Andrzej Hajda
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index fe06accb0..ff9a481 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1254,9 +1254,10 @@ static int gen8_init_indirectctx_bb(struct
> intel_engine_cs *ring,
>
> /* WaFlushCoherentL3CacheLinesAtContextSwitch:bdw */
> if (IS_BROADWELL(ring->dev)) {
> - index = gen8_emit_flush_coherentl3_wa(ring, batch, index);
> - if (index < 0)
> - return index;
> + int rc = gen8_emit_flush_coherentl3_wa(ring, batch, index);
> + if (rc < 0)
> + return rc;
> + index = rc;
> }
>
> /* WaClearSlmSpaceAtContextSwitch:bdw,chv */
> --
> 1.9.1
>
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/9] drm/i915: don't enable FBC when pixel rate exceeds 95% on HSW/BDW
On Mon, Sep 14, 2015 at 03:19:59PM -0300, Paulo Zanoni wrote:
> BSpec says we shouldn't enable FBC on HSW/BDW when the pipe pixel rate
> exceeds 95% of the core display clock.
>
> v2:
> - HSW also needs the WA (Ville).
> - Add the WA name (Ville).
> - Use the current cdclk (Ville).
>
> Signed-off-by: Paulo Zanoni
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_fbc.c | 10 ++
> 2 files changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 1f02a5a..d22120f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -949,6 +949,7 @@ struct i915_fbc {
> FBC_ROTATION, /* rotation is not supported */
> FBC_IN_DBG_MASTER, /* kernel debugger is active */
> FBC_BAD_STRIDE, /* stride is not supported */
> + FBC_PIXEL_RATE, /* pixel rate is too big */
> } no_fbc_reason;
>
> bool (*fbc_enabled)(struct drm_i915_private *dev_priv);
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> b/drivers/gpu/drm/i915/intel_fbc.c
> index 69726a7..1c4536a 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -482,6 +482,8 @@ const char *intel_no_fbc_reason_str(enum no_fbc_reason
> reason)
> return "Kernel debugger is active";
> case FBC_BAD_STRIDE:
> return "framebuffer stride not supported";
> + case FBC_PIXEL_RATE:
> + return "pixel rate is too big";
> default:
> MISSING_CASE(reason);
> return "unknown reason";
> @@ -828,6 +830,14 @@ static void __intel_fbc_update(struct drm_i915_private
> *dev_priv)
> goto out_disable;
> }
>
> + /* WaFbcExceedCdClockThreshold:hsw,bdw */
> + if ((IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) &&
> + ilk_pipe_pixel_rate(intel_crtc->config) >=
> + dev_priv->cdclk_freq * 95 / 100) {
> + set_no_fbc_reason(dev_priv, FBC_PIXEL_RATE);
> + goto out_disable;
> + }
> +
> if (intel_fbc_setup_cfb(dev_priv, obj->base.size,
> drm_format_plane_cpp(fb->pixel_format, 0))) {
> set_no_fbc_reason(dev_priv, FBC_STOLEN_TOO_SMALL);
> --
> 2.5.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/9] drm/i915: avoid the last 8mb of stolen on BDW/SKL
On Mon, Sep 14, 2015 at 03:19:57PM -0300, Paulo Zanoni wrote:
> The FBC hardware for these platforms doesn't have access to the
> bios_reserved range, so it always assumes the maximum (8mb) is used.
> So avoid this range while allocating.
>
> This solves a bunch of FIFO underruns that happen if you end up
> putting the CFB in that memory range. On my machine, with 32mb of
> stolen, I need a 2560x1440 mode for that.
>
> Testcase: igt/kms_frontbuffer_tracking/fbc-* (given the right setup)
> Signed-off-by: Paulo Zanoni
Thwe only real spec quote I was able to find is in FBC_CFB_BASE:
"The buffer must not overlap the top 8 MB of stolen memory. |
BDW,SKL,EXCLUDE(BXT)"
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_drv.h| 4
> drivers/gpu/drm/i915/i915_gem_gtt.h| 1 +
> drivers/gpu/drm/i915/i915_gem_stolen.c | 26 +++---
> drivers/gpu/drm/i915/intel_fbc.c | 16 ++--
> 4 files changed, 38 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 8cf2969..1f02a5a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3173,6 +3173,10 @@ static inline void i915_gem_chipset_flush(struct
> drm_device *dev)
> int i915_gem_stolen_insert_node(struct drm_i915_private *dev_priv,
> struct drm_mm_node *node, u64 size,
> unsigned alignment);
> +int i915_gem_stolen_insert_node_in_range(struct drm_i915_private *dev_priv,
> + struct drm_mm_node *node, u64 size,
> + unsigned alignment, u64 start,
> + u64 end);
> void i915_gem_stolen_remove_node(struct drm_i915_private *dev_priv,
>struct drm_mm_node *node);
> int i915_gem_init_stolen(struct drm_device *dev);
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
> b/drivers/gpu/drm/i915/i915_gem_gtt.h
> index 8275007..96ebb98 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.h
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
> @@ -341,6 +341,7 @@ struct i915_gtt {
> struct i915_address_space base;
>
> size_t stolen_size; /* Total size of stolen memory */
> + size_t stolen_usable_size; /* Total size minus BIOS reserved */
> u64 mappable_end; /* End offset that we can CPU map */
> struct io_mapping *mappable;/* Mapping to our CPU mappable region */
> phys_addr_t mappable_base; /* PA of our GMADR */
> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
> b/drivers/gpu/drm/i915/i915_gem_stolen.c
> index bf26ecc..081ef6d 100644
> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> @@ -42,9 +42,9 @@
> * for is a boon.
> */
>
> -int i915_gem_stolen_insert_node(struct drm_i915_private *dev_priv,
> - struct drm_mm_node *node, u64 size,
> - unsigned alignment)
> +int i915_gem_stolen_insert_node_in_range(struct drm_i915_private *dev_priv,
> + struct drm_mm_node *node, u64 size,
> + unsigned alignment, u64 start, u64 end)
> {
> int ret;
>
> @@ -52,13 +52,23 @@ int i915_gem_stolen_insert_node(struct drm_i915_private
> *dev_priv,
> return -ENODEV;
>
> mutex_lock(&dev_priv->mm.stolen_lock);
> - ret = drm_mm_insert_node(&dev_priv->mm.stolen, node, size, alignment,
> - DRM_MM_SEARCH_DEFAULT);
> + ret = drm_mm_insert_node_in_range(&dev_priv->mm.stolen, node, size,
> + alignment, start, end,
> + DRM_MM_SEARCH_DEFAULT);
> mutex_unlock(&dev_priv->mm.stolen_lock);
>
> return ret;
> }
>
> +int i915_gem_stolen_insert_node(struct drm_i915_private *dev_priv,
> + struct drm_mm_node *node, u64 size,
> + unsigned alignment)
> +{
> + return i915_gem_stolen_insert_node_in_range(dev_priv, node, size,
> + alignment, 0,
> + dev_priv->gtt.stolen_usable_size);
> +}
> +
> void i915_gem_stolen_remove_node(struct drm_i915_private *dev_priv,
>struct drm_mm_node *node)
> {
> @@ -355,9 +365,11 @@ int i915_gem_init_stolen(struct drm_device *dev)
> dev_priv->gtt.stolen_size >> 10,
> (dev_priv->gtt.stolen_size - reserved_total) >> 10);
>
> + dev_priv->gtt.stolen_usable_size = dev_priv->gtt.stolen_size -
> +reserved_total;
> +
> /* Basic memrange allocator for stolen space */
> - drm_mm_init(&dev_priv->mm.stolen, 0, dev_priv->gtt.stolen_size -
> - reserved_total);
> +
Re: [Intel-gfx] [PATCH] drm/i915/skl: Don't clear all watermarks when updating. (v2)
On Tue, Jul 21, 2015 at 10:42:53AM -0700, Bob Paauwe wrote:
> Clearing the watermarks for all pipes/planes when updating the
> watermarks for a single CRTC change seems like the wrong thing to
> do here. As is, this code will ony update any pipe/plane watermarks
> that need updating and leave the remaining set to zero. Later, the
> watermark checks in check_wm_state() will flag these zero'd out pipe/plane
> watermarks and throw errors.
>
> By clearing only the watermark values associated with the specific crtc
> the other watermark values may remain unchanged.
>
> v2: Make sure all the dirty flags are cleared. Damien
> Clear all values assoicated with crtc/pipe being updated. Damien
>
> Signed-off-by: Bob Paauwe
Reviewed-by: Damien Lespiau
- Moving to a "array of structs" from a "struct of arrays" organization
as suggested by Ville would make that much better
- I'd move clearing the dirty flag right after writing the registers
--
Damien
> ---
> drivers/gpu/drm/i915/intel_pm.c | 26 +-
> 1 file changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index a1d92b7..27c3126 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3670,6 +3670,26 @@ static void skl_update_other_pipe_wm(struct drm_device
> *dev,
> }
> }
>
> +static void skl_clear_wm(struct skl_wm_values *watermarks, enum pipe pipe)
> +{
> + watermarks->wm_linetime[pipe] = 0;
> + memset(watermarks->plane[pipe], 0,
> +sizeof(uint32_t) * 8 * I915_MAX_PLANES);
> + memset(watermarks->cursor[pipe], 0, sizeof(uint32_t) * 8);
> + memset(watermarks->plane_trans[pipe],
> +0, sizeof(uint32_t) * I915_MAX_PLANES);
> + watermarks->cursor_trans[pipe] = 0;
> +
> + /* Clear ddb entries for pipe */
> + memset(&watermarks->ddb.pipe[pipe], 0, sizeof(struct skl_ddb_entry));
> + memset(&watermarks->ddb.plane[pipe], 0,
> +sizeof(struct skl_ddb_entry) * I915_MAX_PLANES);
> + memset(&watermarks->ddb.y_plane[pipe], 0,
> +sizeof(struct skl_ddb_entry) * I915_MAX_PLANES);
> + memset(&watermarks->ddb.cursor[pipe], 0, sizeof(struct skl_ddb_entry));
> +
> +}
> +
> static void skl_update_wm(struct drm_crtc *crtc)
> {
> struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> @@ -3680,7 +3700,11 @@ static void skl_update_wm(struct drm_crtc *crtc)
> struct skl_pipe_wm pipe_wm = {};
> struct intel_wm_config config = {};
>
> - memset(results, 0, sizeof(*results));
> +
> + /* Clear all dirty flags */
> + memset(results->dirty, 0, sizeof(bool) * I915_MAX_PIPES);
> +
> + skl_clear_wm(results, intel_crtc->pipe);
>
> skl_compute_wm_global_parameters(dev, &config);
>
> --
> 2.1.0
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/9] drm/i915: check for the supported strides on HSW+ FBC
On Mon, Sep 14, 2015 at 03:19:56PM -0300, Paulo Zanoni wrote:
> Don't allow FBC for cases where the spec says we can't FBC.
>
> v2:
> - Just WARN_ON() the strides that should have been caught earlier
> (Daniel)
> - Make it a new function since I expect this to grow more.
> v3:
> - Document which IGT test is exercised by this.
> v4:
> - Implement the restrictions for gens 2-6 too (Ville).
> - Fix off-by-one mistake (Ville).
>
> Testcase: igt/kms_frontbuffer_tracking/fbc-badstride
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_fbc.c | 28
> 2 files changed, 29 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 3bf8a9b..8cf2969 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -948,6 +948,7 @@ struct i915_fbc {
> FBC_CHIP_DEFAULT, /* disabled by default on this chip */
> FBC_ROTATION, /* rotation is not supported */
> FBC_IN_DBG_MASTER, /* kernel debugger is active */
> + FBC_BAD_STRIDE, /* stride is not supported */
> } no_fbc_reason;
>
> bool (*fbc_enabled)(struct drm_i915_private *dev_priv);
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> b/drivers/gpu/drm/i915/intel_fbc.c
> index 9e42079..db38091 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -480,6 +480,8 @@ const char *intel_no_fbc_reason_str(enum no_fbc_reason
> reason)
> return "rotation unsupported";
> case FBC_IN_DBG_MASTER:
> return "Kernel debugger is active";
> + case FBC_BAD_STRIDE:
> + return "framebuffer stride not supported";
> default:
> MISSING_CASE(reason);
> return "unknown reason";
> @@ -671,6 +673,27 @@ static int intel_fbc_setup_cfb(struct drm_i915_private
> *dev_priv, int size,
> return intel_fbc_alloc_cfb(dev_priv, size, fb_cpp);
> }
>
> +static bool stride_is_valid(struct drm_i915_private *dev_priv,
> + unsigned int stride)
> +{
> + /* These should have been caught earlier. */
> + WARN_ON(stride < 512);
> + WARN_ON((stride & (64 - 1)) != 0);
> +
> + /* Below are the additional FBC restrictions. */
> +
> + if (IS_GEN2(dev_priv) || IS_GEN3(dev_priv))
> + return stride == 4096 || stride == 8192;
> +
> + if (IS_GEN4(dev_priv) && !IS_G4X(dev_priv) && stride < 2048)
> + return false;
> +
> + if (stride > 16384)
> + return false;
Looks to match what I caught from my spec trawling trip last time.
Reviewed-by: Ville Syrjälä
> +
> + return true;
> +}
> +
> /**
> * __intel_fbc_update - enable/disable FBC as needed, unlocked
> * @dev_priv: i915 device instance
> @@ -781,6 +804,11 @@ static void __intel_fbc_update(struct drm_i915_private
> *dev_priv)
> goto out_disable;
> }
>
> + if (!stride_is_valid(dev_priv, fb->pitches[0])) {
> + set_no_fbc_reason(dev_priv, FBC_BAD_STRIDE);
> + goto out_disable;
> + }
> +
> /* If the kernel debugger is active, always disable compression */
> if (in_dbg_master()) {
> set_no_fbc_reason(dev_priv, FBC_IN_DBG_MASTER);
> --
> 2.5.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/38] drm/i915: fix handling gen8_emit_flush_coherentl3_wa result
The function can return negative value.
The problem has been detected using proposed semantic patch
scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1].
[1]: http://permalink.gmane.org/gmane.linux.kernel/2038576
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/i915/intel_lrc.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index fe06accb0..ff9a481 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1254,9 +1254,10 @@ static int gen8_init_indirectctx_bb(struct
intel_engine_cs *ring,
/* WaFlushCoherentL3CacheLinesAtContextSwitch:bdw */
if (IS_BROADWELL(ring->dev)) {
- index = gen8_emit_flush_coherentl3_wa(ring, batch, index);
- if (index < 0)
- return index;
+ int rc = gen8_emit_flush_coherentl3_wa(ring, batch, index);
+ if (rc < 0)
+ return rc;
+ index = rc;
}
/* WaClearSlmSpaceAtContextSwitch:bdw,chv */
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/38] Fixes related to incorrect usage of unsigned types
Hi, This is set of independent patches. The only connection between them is that they try to address problems spotted by proposed coccinelle semantic patch unsigned_lesser_than_zero.cocci[1]. Semantic patch finds comparisons of types: unsigned < 0 unsigned >= 0 The former is always false, the latter is always true. Such comparisons are useless, so theoretically they could be safely removed, but their presence quite often indicates bugs. This patchset contains mainly real bug fixes(patches 01-25), usually type fixes. Patches 26-37 removes unnecessary checks. Semantic patch found much more such places (more than 80), but since every case needs some analysis I have decided to leave them for antoher patchset. The last patch should be probably replaced with something better, I guess it should be treated rather as bug report. The patches are based on linux-next (20150918). Patches were only compile tested, so please look at them carefully. I have sent all patches to linux-kernel mailing list. Individual patches + cover letter went also to apropriate addresses, according to get_maintainers.pl script. One more thing. To fullfill different maintaner/subsystem requirements I have decided to prefix patch subjects with prefixes present in last 10 commits for affected files. I am not sure if this is the best solution, if there are any better solutions please let me know :) [1]: http://permalink.gmane.org/gmane.linux.kernel/2038576 Regards Andrzej Andrzej Hajda (38): arm-cci: fix handling cpumask_any_but return value bus: arm-ccn: fix handling cpumask_any_but return value drm/i915: fix handling gen8_emit_flush_coherentl3_wa result IB/ehca: fix handling idr_alloc result staging: lustre: fix handling lustre_posix_acl_xattr_filter result tty: serial: lpc32xx_hs: fix handling platform_get_irq result usb: host: ehci-msm: fix handling platform_get_irq result openvswitch: fix handling result of ipv6_skip_exthdr selftests/timers: fix write return value handlng hwrng: fix handling platform_get_irq HSI: omap_ssi: fix handling ida_simple_get result HSI: omap_ssi_port: fix handling of_get_named_gpio result ARM: shmobile: apmu: correct type of CPU id clk: vt8500: fix sign of possible PLL values drm/layerscape: fix handling fsl_dcu_drm_plane_index result gpu: ipu-v3: fix div_ratio type isdn: hisax: fix frame calculation net/ibm/emac: fix type of phy_mode net: stmmac: fix type of entry variable net: brcm80211: fix range check mwifiex: fix comparison expression orinoco: fix checking for default value rndis_wlan: fix checking for default value rtc: opal: fix type of token staging: media: davinci_vpfe: fix ipipe_mode type staging: lustre: remove invalid check usbnet: remove invalid check video/omap: remove invalid check Input: touchscreen: atmel: remove invalid check leds: flash: remove invalid check leds: tca6507: remove invalid check fs/cachefiles: remove invalid checks mm/memblock.c: remove invalid check perf: remove invalid check ptrace: remove invalid check MIPS: remove invalid check zlib_deflate/deftree: change always true condition to 1 drm/radeon: simplify boot level calculation arch/arm/mach-shmobile/platsmp-apmu.c | 2 +- arch/mips/mm/sc-mips.c | 4 ++-- arch/sh/kernel/ptrace_32.c | 3 +-- arch/sh/kernel/ptrace_64.c | 4 ++-- drivers/bus/arm-cci.c | 2 +- drivers/bus/arm-ccn.c | 2 +- drivers/char/hw_random/xgene-rng.c | 7 --- drivers/clk/clk-vt8500.c| 6 +++--- drivers/gpu/drm/amd/amdgpu/kv_dpm.c | 11 +-- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 3 ++- drivers/gpu/drm/i915/intel_lrc.c| 7 --- drivers/gpu/drm/radeon/kv_dpm.c | 11 +-- drivers/gpu/ipu-v3/ipu-csi.c| 2 +- drivers/hsi/controllers/omap_ssi.c | 7 +++ drivers/hsi/controllers/omap_ssi_port.c | 8 drivers/input/touchscreen/atmel_mxt_ts.c| 2 +- drivers/isdn/hisax/hfc4s8s_l1.c | 10 +- drivers/leds/led-class-flash.c | 2 +- drivers/leds/leds-tca6507.c | 2 +- drivers/net/ethernet/ibm/emac/core.h| 2 +- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +- drivers/net/usb/lan78xx.c | 5 - drivers/net/usb/smsc75xx.c | 5 - drivers/net/usb/smsc95xx.c | 5 - drivers/net/wireless/brcm80211/brcmsmac/main.c | 2 +- drivers/net/wireless/mwifiex/11n_rxreorder.c| 4 ++-- drivers/net/wireless/orinoco/cfg.c | 6 +++--- drivers/net/wireless/rndis_wlan.c | 2 +- drivers/
Re: [Intel-gfx] [PATCH] drm/i915: Remove extraneous request cancel.
On 09/21/2015 02:02 PM, Nick Hoath wrote:
Remove extraneous request cancel in request allocation failure path
in intel_lr_context_deferred_alloc (Tvrtko Ursulin)
Signed-off-by: Nick Hoath
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index fe06accb0..3a50de6 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2488,7 +2488,6 @@ int intel_lr_context_deferred_alloc(struct intel_context
*ctx,
if (ret) {
DRM_ERROR("ring create req: %d\n",
ret);
- i915_gem_request_cancel(req);
goto error_ringbuf;
}
Reviewed-by: Tvrtko Ursulin
Could add to the commit that popular blurb of:
Regression from:
commit e84fe80337dc85cca07d0417ea97edbec4789d8b
Author: Nick Hoath
Date: Fri Sep 11 12:53:46 2015 +0100
drm/i915: Split alloc from init for lrc
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/43] drm/i915: Parametrize fence registers
On Mon, Sep 21, 2015 at 03:33:00PM +0300, Ville Syrjälä wrote:
> On Mon, Sep 21, 2015 at 10:45:46AM +0300, Jani Nikula wrote:
> > On Fri, 18 Sep 2015, ville.syrj...@linux.intel.com wrote:
> > > From: Ville Syrjälä
> > >
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/i915/i915_gem_fence.c | 42
> > > +--
> > > drivers/gpu/drm/i915/i915_gpu_error.c | 21 --
> > > drivers/gpu/drm/i915/i915_reg.h | 12 +-
> > > 3 files changed, 37 insertions(+), 38 deletions(-)
> > >
>
> > > diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
> > > b/drivers/gpu/drm/i915/i915_gpu_error.c
> > > index 3379f9c..e873eb4 100644
> > > --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> > > +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> > > @@ -787,19 +787,16 @@ static void i915_gem_record_fences(struct
> > > drm_device *dev,
> > >
> > > if (IS_GEN3(dev) || IS_GEN2(dev)) {
> > > for (i = 0; i < 8; i++)
> > > - error->fence[i] = I915_READ(FENCE_REG_830_0 + (i * 4));
> > > - if (IS_I945G(dev) || IS_I945GM(dev) || IS_G33(dev))
> > > - for (i = 0; i < 8; i++)
> > > - error->fence[i+8] = I915_READ(FENCE_REG_945_8 +
> > > - (i * 4));
> > > - } else if (IS_GEN5(dev) || IS_GEN4(dev))
> > > - for (i = 0; i < 16; i++)
> > > - error->fence[i] = I915_READ64(FENCE_REG_965_0 +
> > > - (i * 8));
> > > - else if (INTEL_INFO(dev)->gen >= 6)
> > > + error->fence[i] = I915_READ(FENCE_REG_830(i));
> > > + for (i = 8; i < dev_priv->num_fence_regs; i++)
> > > + error->fence[i] = I915_READ(FENCE_REG_945_8(i));
> > > + } else if (IS_GEN5(dev) || IS_GEN4(dev)) {
> > > for (i = 0; i < dev_priv->num_fence_regs; i++)
> > > - error->fence[i] = I915_READ64(FENCE_REG_SANDYBRIDGE_0 +
> > > - (i * 8));
> > > + error->fence[i] = I915_READ64(FENCE_REG_965_LO(i));
> > > + } else if (INTEL_INFO(dev)->gen >= 6) {
> > > + for (i = 0; i < dev_priv->num_fence_regs; i++)
> > > + error->fence[i] = I915_READ64(FENCE_REG_GEN6_LO(i));
> > > + }
> > > }
> > >
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index 44cedbf..b1cf17a 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -1437,8 +1437,8 @@ enum skl_disp_power_wells {
> > > /*
> > > * Fence registers
> > > */
> > > -#define FENCE_REG_830_0 0x2000
> > > -#define FENCE_REG_945_8 0x3000
> > > +#define FENCE_REG_830(i) (0x2000 + (i) * 4) /* 8 registers */
> > > +#define FENCE_REG_945_8(i) (0x3000 + ((i) - 8) * 4) /* 8
> > > registers */
> >
> > How about defining that as
> >
> > #define FENCE_REG_945(i) (i < 8 ? FENCE_REG_830(i) : (0x3000 + ((i) - 8) *
> > 4))
> >
> > and changing the code to look at platforms, not reg number?
>
> Yeah, I guess we can hide the magic entirely. In fact we wouldn't even
> need any gen2 vs. gen3 platforms checks anymore with that macro.
Oh I think I already considered making this even more magic with
something like this:
(0x2000 + (((i) & 8) << 9) + ((i) & 7) * 4)
or
(0x2000 + (((i) >> 3) * 0x1000) + ((i) & 7) * 4)
Not sure if that's too obscure for people? I suppose I could toss in a
comment in there to explain it a bit.
>
> >
> >
> > BR,
> > Jani.
> >
> >
> > > #define I830_FENCE_START_MASK 0x07f8
> > > #define I830_FENCE_TILING_Y_SHIFT 12
> > > #define I830_FENCE_SIZE_BITS(size) ((ffs((size) >> 19) - 1) << 8)
> > > @@ -1451,14 +1451,16 @@ enum skl_disp_power_wells {
> > > #define I915_FENCE_START_MASK 0x0ff0
> > > #define I915_FENCE_SIZE_BITS(size) ((ffs((size) >> 20) - 1) << 8)
> > >
> > > -#define FENCE_REG_965_0 0x03000
> > > +#define FENCE_REG_965_LO(i) (0x03000 + (i) * 8)
> > > +#define FENCE_REG_965_HI(i) (0x03000 + (i) * 8 + 4)
> > > #define I965_FENCE_PITCH_SHIFT 2
> > > #define I965_FENCE_TILING_Y_SHIFT 1
> > > #define I965_FENCE_REG_VALID (1<<0)
> > > #define I965_FENCE_MAX_PITCH_VAL 0x0400
> > >
> > > -#define FENCE_REG_SANDYBRIDGE_0 0x10
> > > -#define SANDYBRIDGE_FENCE_PITCH_SHIFT 32
> > > +#define FENCE_REG_GEN6_LO(i) (0x10 + (i) * 8)
> > > +#define FENCE_REG_GEN6_HI(i) (0x10 + (i) * 8 + 4)
> > > +#define GEN6_FENCE_PITCH_SHIFT 32
> > > #define GEN7_FENCE_MAX_PITCH_VAL 0x0800
> > >
> > >
> > > --
> > > 2.4.6
> > >
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/intel-
[Intel-gfx] [PATCH] drm/i915: Only disable visible planes in intel_crtc_disable_planes
This is fix for a regression introduced by 27321ae88c70104df
"drm/i915: Use the disable callback for disabling planes."
Disabling invisible planes may cause recalculation of
watermarks, which is a problem because the software state
is not yet in sync with the hardware state.
This may result in a black screen during kernel boot and
plymouth splash until any input action is performed in X.
Explicitly checking for plane visibility fixes the regression.
This is a patch for v4.2 only, v4.3 needs a different fix because
it was fixed by d032ffa04cf7c6f
"drm/i915: Handle disabling planes better, v2."
but later broken again in
4cf0ebbd4fafbdf "drm/i915: Rework plane readout."
This will be fixed in v4.3 by:
"drm/i915: Add .get_hw_state() method for planes"
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91952
Cc: João Paulo Rechi Vita
Cc: sta...@vger.kernel.org # v4.2 only
---
drivers/gpu/drm/i915/intel_display.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 87476ff181dd..a5f97cfd86d8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4863,7 +4863,8 @@ static void intel_crtc_disable_planes(struct drm_crtc
*crtc)
intel_crtc_dpms_overlay_disable(intel_crtc);
for_each_intel_plane(dev, intel_plane) {
- if (intel_plane->pipe == pipe) {
+ if (intel_plane->pipe == pipe &&
+ to_intel_plane_state(intel_plane->base.state)->visible) {
struct drm_crtc *from = intel_plane->base.crtc;
intel_plane->disable_plane(&intel_plane->base,
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Remove extraneous request cancel.
Remove extraneous request cancel in request allocation failure path
in intel_lr_context_deferred_alloc (Tvrtko Ursulin)
Signed-off-by: Nick Hoath
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index fe06accb0..3a50de6 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2488,7 +2488,6 @@ int intel_lr_context_deferred_alloc(struct intel_context
*ctx,
if (ret) {
DRM_ERROR("ring create req: %d\n",
ret);
- i915_gem_request_cancel(req);
goto error_ringbuf;
}
--
2.1.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Revert "sna: Coldplug unknown connections as well"
On Mon, Sep 21, 2015 at 02:48:03PM +0200, Sedat Dilek wrote: > On Mon, Sep 21, 2015 at 11:42 AM, Chris Wilson > wrote: > > On Sun, Sep 20, 2015 at 08:20:21PM +0200, Sedat Dilek wrote: > >> Hi, > >> > >> I am here on Ubuntu/precise AMD64 with libdrm v2.4.65 and mesa v10.6.8. > >> > >> I cannot see my LightDM login-manager, my system hangs in VT-1. > >> > >> When I revert... > >> > >> commit 650da13c7257019728cfca361dfcbe34a6c526ef > >> "sna: Coldplug unknown connections as well" > > > > All it is doing is a RRGetInfo() call after 2 seconds if the display > > manager hasn't already done so. Easiest step forward is to look at the > > ddx logs to see timings on who calls what and then try and get the > > lightdm + unity logs to see why they changed behaviour. > > > > Yes, I can look at the LightDM and Unity logs. > Shall I build my intelddx with debugging enabled? The only thing of interest will be the timings given by the full debug log. I don't expect to see a problem as such, but could be proven wrong. > >> ...everything is as usual. > > > > Apart from the kernel issue... > > > > Which kernel-issue? > > On shutdown and after LightDM closes, my system hangs 4ever in VT-1, > so reverting above commit does not really help. That ^ strongly suggests an issue lower down the stack. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Revert "sna: Coldplug unknown connections as well"
On Mon, Sep 21, 2015 at 11:42 AM, Chris Wilson wrote: > On Sun, Sep 20, 2015 at 08:20:21PM +0200, Sedat Dilek wrote: >> Hi, >> >> I am here on Ubuntu/precise AMD64 with libdrm v2.4.65 and mesa v10.6.8. >> >> I cannot see my LightDM login-manager, my system hangs in VT-1. >> >> When I revert... >> >> commit 650da13c7257019728cfca361dfcbe34a6c526ef >> "sna: Coldplug unknown connections as well" > > All it is doing is a RRGetInfo() call after 2 seconds if the display > manager hasn't already done so. Easiest step forward is to look at the > ddx logs to see timings on who calls what and then try and get the > lightdm + unity logs to see why they changed behaviour. > Yes, I can look at the LightDM and Unity logs. Shall I build my intelddx with debugging enabled? >> ...everything is as usual. > > Apart from the kernel issue... > Which kernel-issue? On shutdown and after LightDM closes, my system hangs 4ever in VT-1, so reverting above commit does not really help. - Sedat - ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/1] drm/i915/bxt: Set time interval unit to 0.833us
On pe, 2015-09-18 at 23:39 +0530, Sagar Arun Kamble wrote:
> From: Akash Goel
>
> Signed-off-by: Ankitprasad Sharma
> Signed-off-by: Akash Goel
> Signed-off-by: Sagar Arun Kamble
> ---
> drivers/gpu/drm/i915/i915_reg.h | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 67bf205..6b1998c 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -2802,8 +2802,11 @@ enum skl_disp_power_wells {
>
> #define INTERVAL_1_28_US(us) (((us) * 100) >> 7)
> #define INTERVAL_1_33_US(us) (((us) * 3) >> 2)
> +#define INTERVAL_0_833_US(us)(((us) * 6) / 5)
> #define GT_INTERVAL_FROM_US(dev_priv, us) (IS_GEN9(dev_priv) ? \
> - INTERVAL_1_33_US(us) : \
> + (IS_BROXTON(dev_priv) ? \
> + INTERVAL_0_833_US(us) : \
> + INTERVAL_1_33_US(us)) : \
> INTERVAL_1_28_US(us))
Note that neither of the GEN9 values are mentioned in Bspec, so a
request for update should be filed there. I haven't found any other
place that would document this either, could you point me to it?
--Imre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/43] drm/i915: Parametrize fence registers
On Mon, Sep 21, 2015 at 10:45:46AM +0300, Jani Nikula wrote:
> On Fri, 18 Sep 2015, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/i915_gem_fence.c | 42
> > +--
> > drivers/gpu/drm/i915/i915_gpu_error.c | 21 --
> > drivers/gpu/drm/i915/i915_reg.h | 12 +-
> > 3 files changed, 37 insertions(+), 38 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
> > b/drivers/gpu/drm/i915/i915_gpu_error.c
> > index 3379f9c..e873eb4 100644
> > --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> > +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> > @@ -787,19 +787,16 @@ static void i915_gem_record_fences(struct drm_device
> > *dev,
> >
> > if (IS_GEN3(dev) || IS_GEN2(dev)) {
> > for (i = 0; i < 8; i++)
> > - error->fence[i] = I915_READ(FENCE_REG_830_0 + (i * 4));
> > - if (IS_I945G(dev) || IS_I945GM(dev) || IS_G33(dev))
> > - for (i = 0; i < 8; i++)
> > - error->fence[i+8] = I915_READ(FENCE_REG_945_8 +
> > - (i * 4));
> > - } else if (IS_GEN5(dev) || IS_GEN4(dev))
> > - for (i = 0; i < 16; i++)
> > - error->fence[i] = I915_READ64(FENCE_REG_965_0 +
> > - (i * 8));
> > - else if (INTEL_INFO(dev)->gen >= 6)
> > + error->fence[i] = I915_READ(FENCE_REG_830(i));
> > + for (i = 8; i < dev_priv->num_fence_regs; i++)
> > + error->fence[i] = I915_READ(FENCE_REG_945_8(i));
> > + } else if (IS_GEN5(dev) || IS_GEN4(dev)) {
> > for (i = 0; i < dev_priv->num_fence_regs; i++)
> > - error->fence[i] = I915_READ64(FENCE_REG_SANDYBRIDGE_0 +
> > - (i * 8));
> > + error->fence[i] = I915_READ64(FENCE_REG_965_LO(i));
> > + } else if (INTEL_INFO(dev)->gen >= 6) {
> > + for (i = 0; i < dev_priv->num_fence_regs; i++)
> > + error->fence[i] = I915_READ64(FENCE_REG_GEN6_LO(i));
> > + }
> > }
> >
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 44cedbf..b1cf17a 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -1437,8 +1437,8 @@ enum skl_disp_power_wells {
> > /*
> > * Fence registers
> > */
> > -#define FENCE_REG_830_00x2000
> > -#define FENCE_REG_945_80x3000
> > +#define FENCE_REG_830(i) (0x2000 + (i) * 4) /* 8 registers */
> > +#define FENCE_REG_945_8(i) (0x3000 + ((i) - 8) * 4) /* 8 registers
> > */
>
> How about defining that as
>
> #define FENCE_REG_945(i) (i < 8 ? FENCE_REG_830(i) : (0x3000 + ((i) - 8) * 4))
>
> and changing the code to look at platforms, not reg number?
Yeah, I guess we can hide the magic entirely. In fact we wouldn't even
need any gen2 vs. gen3 platforms checks anymore with that macro.
>
>
> BR,
> Jani.
>
>
> > #define I830_FENCE_START_MASK0x07f8
> > #define I830_FENCE_TILING_Y_SHIFT12
> > #define I830_FENCE_SIZE_BITS(size) ((ffs((size) >> 19) - 1) << 8)
> > @@ -1451,14 +1451,16 @@ enum skl_disp_power_wells {
> > #define I915_FENCE_START_MASK0x0ff0
> > #define I915_FENCE_SIZE_BITS(size) ((ffs((size) >> 20) - 1) << 8)
> >
> > -#define FENCE_REG_965_00x03000
> > +#define FENCE_REG_965_LO(i)(0x03000 + (i) * 8)
> > +#define FENCE_REG_965_HI(i)(0x03000 + (i) * 8 + 4)
> > #define I965_FENCE_PITCH_SHIFT 2
> > #define I965_FENCE_TILING_Y_SHIFT1
> > #define I965_FENCE_REG_VALID (1<<0)
> > #define I965_FENCE_MAX_PITCH_VAL 0x0400
> >
> > -#define FENCE_REG_SANDYBRIDGE_00x10
> > -#define SANDYBRIDGE_FENCE_PITCH_SHIFT32
> > +#define FENCE_REG_GEN6_LO(i) (0x10 + (i) * 8)
> > +#define FENCE_REG_GEN6_HI(i) (0x10 + (i) * 8 + 4)
> > +#define GEN6_FENCE_PITCH_SHIFT 32
> > #define GEN7_FENCE_MAX_PITCH_VAL 0x0800
> >
> >
> > --
> > 2.4.6
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Jani Nikula, Intel Open Source Technology Center
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Move scanline_offset and timestamping constant setup to intel_modeset_readout_hw_state()
Hey,
Op 14-09-15 om 16:23 schreef Ville Syrjälä:
> On Mon, Sep 14, 2015 at 01:57:45PM +0200, Maarten Lankhorst wrote:
>> Op 10-09-15 om 17:59 schreef ville.syrj...@linux.intel.com:
>>> From: Ville Syrjälä
>>>
>>> intel_modeset_readout_hw_state() seems like the more appropriate place
>>> for populating the scanline_offset and timestamping constants than
>>> intel_sanitize_crtc() since they are basically part of the state we
>>> read out.
>>>
>>> Cc: Maarten Lankhorst
>>> Cc: Patrik Jakobsson
>>> Signed-off-by: Ville Syrjälä
>>> ---
>>> drivers/gpu/drm/i915/intel_display.c | 5 +++--
>>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>>> b/drivers/gpu/drm/i915/intel_display.c
>>> index 5fed120..88d9466 100644
>>> --- a/drivers/gpu/drm/i915/intel_display.c
>>> +++ b/drivers/gpu/drm/i915/intel_display.c
>>> @@ -14918,8 +14918,6 @@ static void intel_sanitize_crtc(struct intel_crtc
>>> *crtc)
>>> if (crtc->active) {
>>> struct intel_plane *plane;
>>>
>>> - drm_calc_timestamping_constants(&crtc->base,
>>> &crtc->base.hwmode);
>>> - update_scanline_offset(crtc);
>>> drm_crtc_vblank_on(&crtc->base);
>>>
>>> /* Disable everything but the primary plane */
>>> @@ -15216,6 +15214,9 @@ static void intel_modeset_readout_hw_state(struct
>>> drm_device *dev)
>>> * recalculation.
>>> */
>>> crtc->base.state->mode.private_flags =
>>> I915_MODE_FLAG_INHERITED;
>>> +
>>> + drm_calc_timestamping_constants(&crtc->base,
>>> &crtc->base.hwmode);
>>> + update_scanline_offset(crtc);
>>> }
>>> }
>>> }
>> Can you move drm_vblank_reset and drm_vblank_on too?
> I'm not sure I really want to move those. They can actually modify
> the hardware state, so I don't think they really belong in
> intel_modeset_readout_hw_state(). intel_sanitize_crtc() feels like
> a better fit.
Well the changes are all useful and they're blocking other work. So I think
it's better these get in as is.
Reviewed-by: Maarten Lankhorst
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/bxt: Update revision id for BXT C0
On pe, 2015-09-18 at 17:52 +0100, Arun Siluvery wrote:
> Cc: Nick Hoath
> Cc: Imre Deak
> Signed-off-by: Arun Siluvery
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 5e30893..7c50973 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2499,7 +2499,7 @@ struct drm_i915_cmd_table {
>
> #define BXT_REVID_A0 (0x0)
> #define BXT_REVID_B0 (0x3)
> -#define BXT_REVID_C0 (0x6)
> +#define BXT_REVID_C0 (0x9)
>
> /*
> * The genX designation typically refers to the render engine, so render
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/4] NV12 rotation GTT handling prep work
On Mon, Sep 21, 2015 at 10:45:31AM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > GTT page remapping logic for 90/270 rotation needs some > extensions to support NV12 90/270 rotation work which is > currently underway. > > Main thing is really to support building of the rotated > page mapping from two planes instead of one, and adding > appropriate calculations for the half-height UV plane > geometry. > > Those are stored in the existing rotation info data > associated with the rotated view and are also used to > return the appropriate plane start address when queried > from the display code. BTW I started to hatch something to uswe intel_gen4_compute_page_offset() on SKL+, and also start to handle fb offsets[0] somehow. I didn't get too far yet, but I figured I'll post a reference here in case people are intersted in this sort of stuff: git://github.com/vsyrjala/linux.git tile_size > > Tvrtko Ursulin (4): > drm/i915: Support planar formats in tile height calculations > drm/i915: Support appending to the rotated pages mapping > drm/i915: Support NV12 in rotated GGTT mapping > drm/i915: Enable querying offset of UV plane with > intel_plane_obj_offset > > drivers/gpu/drm/i915/i915_gem_gtt.c | 58 > > drivers/gpu/drm/i915/i915_gem_gtt.h | 4 +++ > drivers/gpu/drm/i915/intel_display.c | 48 ++--- > drivers/gpu/drm/i915/intel_drv.h | 6 ++-- > drivers/gpu/drm/i915/intel_sprite.c | 4 +-- > 5 files changed, 93 insertions(+), 27 deletions(-) > > -- > 2.5.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 1/1] drm/i915/bxt: WaGsvDisableTurbo
Disable Turbo on steppings prior to B0 on BXT due to hangs seen during GT CPD
exit.
v3: Explicitly clear the Turbo control register (Akash)
Change-Id: I50c5c03f59f5ba092db19e17234951d89db42c6c
Signed-off-by: Akash Goel
Signed-off-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/intel_pm.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 62de97e..b679e8e 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4479,6 +4479,10 @@ static void gen6_set_rps(struct drm_device *dev, u8 val)
{
struct drm_i915_private *dev_priv = dev->dev_private;
+ /* WaGsvDisableTurbo: Workaround to disable turbo on BXT A* */
+ if (IS_BROXTON(dev) && (INTEL_REVID(dev) < BXT_REVID_B0))
+ return;
+
WARN_ON(!mutex_is_locked(&dev_priv->rps.hw_lock));
WARN_ON(val > dev_priv->rps.max_freq);
WARN_ON(val < dev_priv->rps.min_freq);
@@ -4799,6 +4803,22 @@ static void gen9_enable_rps(struct drm_device *dev)
gen6_init_rps_frequencies(dev);
+ /* WaGsvDisableTurbo: Workaround to disable turbo on BXT A* */
+ if (IS_BROXTON(dev) && (INTEL_REVID(dev) < BXT_REVID_B0)) {
+ /*
+* BIOS could leave the Hw Turbo enabled, so need to explicitly
+* clear out the Control register just to avoid inconsitency
+* with debugfs interface, which will show Turbo as enabled
+* only, which is not expected by the User after adding the
+* WaGsvDisableTurbo. Apart from this there is no problem even
+* if the Turbo is left enabled in the Control register, as the
+* Up/Down interrupts would remain masked.
+*/
+ I915_WRITE(GEN6_RP_CONTROL, 0);
+ intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
+ return;
+ }
+
/* Program defaults and thresholds for RPS*/
I915_WRITE(GEN6_RC_VIDEO_FREQ,
GEN9_FREQUENCY(dev_priv->rps.rp1_freq));
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Enable querying offset of UV plane with intel_plane_obj_offset
On ma, 2015-09-21 at 10:45 +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> v2: Rebase.
>
> Signed-off-by: Tvrtko Ursulin
>
Reviewed-by: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 2 ++
> drivers/gpu/drm/i915/i915_gem_gtt.h | 1 +
> drivers/gpu/drm/i915/intel_display.c | 26 +-
> drivers/gpu/drm/i915/intel_drv.h | 4 +++-
> drivers/gpu/drm/i915/intel_sprite.c | 2 +-
> 5 files changed, 28 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 2df9d16dcefd..4023c86fabf9 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -3322,6 +3322,8 @@ intel_rotate_fb_obj_pages(struct i915_ggtt_view
> *ggtt_view,
> if (offset_in_page(rot_info->uv_offset))
> uv_start_page--;
>
> + rot_info->uv_start_page = uv_start_page;
> +
> rotate_pages(page_addr_list, uv_start_page,
>rot_info->width_pages_uv,
>rot_info->height_pages_uv,
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
> b/drivers/gpu/drm/i915/i915_gem_gtt.h
> index 197183d5c543..430cc283d3c9 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.h
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
> @@ -145,6 +145,7 @@ struct intel_rotation_info {
> uint64_t size;
> unsigned int width_pages_uv, height_pages_uv;
> uint64_t size_uv;
> + unsigned int uv_start_page;
> };
>
> struct i915_ggtt_view {
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 2db7cc42539c..ebfd34beb841 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2891,14 +2891,29 @@ u32 intel_fb_stride_alignment(struct
> drm_device *dev, uint64_t fb_modifier,
> }
>
> unsigned long intel_plane_obj_offset(struct intel_plane
> *intel_plane,
> - struct drm_i915_gem_object
> *obj)
> + struct drm_i915_gem_object
> *obj,
> + unsigned int plane)
> {
> const struct i915_ggtt_view *view = &i915_ggtt_view_normal;
> + struct i915_vma *vma;
> + unsigned char *offset;
>
> if (intel_rotation_90_or_270(intel_plane->base.state
> ->rotation))
> view = &i915_ggtt_view_rotated;
>
> - return i915_gem_obj_ggtt_offset_view(obj, view);
> + vma = i915_gem_obj_to_ggtt_view(obj, view);
> + if (WARN(!vma, "ggtt vma for display object not found!
> (view=%u)\n",
> + view->type))
> + return -1;
> +
> + offset = (unsigned char *)vma->node.start;
> +
> + if (plane == 1) {
> + offset += vma->ggtt_view.rotation_info.uv_start_page
> *
> + PAGE_SIZE;
> + }
> +
> + return (unsigned long)offset;
> }
>
> static void skl_detach_scaler(struct intel_crtc *intel_crtc, int id)
> @@ -3054,7 +3069,7 @@ static void skylake_update_primary_plane(struct
> drm_crtc *crtc,
> obj = intel_fb_obj(fb);
> stride_div = intel_fb_stride_alignment(dev, fb->modifier[0],
> fb->pixel_format);
> - surf_addr = intel_plane_obj_offset(to_intel_plane(plane),
> obj);
> + surf_addr = intel_plane_obj_offset(to_intel_plane(plane),
> obj, 0);
>
> /*
>* FIXME: intel_plane_state->src, dst aren't set when
> transitional
> @@ -11414,8 +11429,9 @@ static int intel_crtc_page_flip(struct
> drm_crtc *crtc,
> if (ret)
> goto cleanup_pending;
>
> - work->gtt_offset =
> intel_plane_obj_offset(to_intel_plane(primary), obj)
> - + intel_crtc
> ->dspaddr_offset;
> + work->gtt_offset =
> intel_plane_obj_offset(to_intel_plane(primary),
> + obj, 0);
> + work->gtt_offset += intel_crtc->dspaddr_offset;
>
> if (mmio_flip) {
> ret = intel_queue_mmio_flip(dev, crtc, fb, obj,
> ring,
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 94dab9bd8ebd..13c64c5ec22b 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1166,7 +1166,9 @@ int skl_update_scaler_crtc(struct
> intel_crtc_state *crtc_state);
> int skl_max_scale(struct intel_crtc *crtc, struct intel_crtc_state
> *crtc_state);
>
> unsigned long intel_plane_obj_offset(struct intel_plane
> *intel_plane,
> - struct drm_i915_gem_object
> *obj);
> + struct drm_i915_gem_object
> *obj,
> + unsigned int plane);
> +
> u32 skl_plane_ctl_format(uint32_t pixel_format);
> u32 skl_plane_ctl_tiling(uint64_t fb_modifier);
> u32 skl_plane_ctl_rotation(unsigned int rotation);
> diff --git a/drivers/gpu/drm/i91
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Support NV12 in rotated GGTT mapping
On ma, 2015-09-21 at 10:45 +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Just adding the rotated UV plane at the end of the rotated Y plane.
>
> v2: Rebase.
>
>
> Signed-off-by: Tvrtko Ursulin
>
One comment below, otherwise.
Reviewed-by: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 37
> ++--
> drivers/gpu/drm/i915/i915_gem_gtt.h | 3 +++
> drivers/gpu/drm/i915/intel_display.c | 12
> 3 files changed, 46 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 59c934fb9230..2df9d16dcefd 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -3272,10 +3272,13 @@ intel_rotate_fb_obj_pages(struct
> i915_ggtt_view *ggtt_view,
> {
> >> struct intel_rotation_info *rot_info = &ggtt_view
> ->rotation_info;
> >> unsigned int size_pages = rot_info->size >> PAGE_SHIFT;
> +>> unsigned int size_pages_uv;
Could be initialized to zero here already as majority of the time it'll
be unchanged.
> >> struct sg_page_iter sg_iter;
> >> unsigned long i;
> >> dma_addr_t *page_addr_list;
> >> struct sg_table *st;
> +>> unsigned int uv_start_page;
> +>> struct scatterlist *sg;
> >> int ret = -ENOMEM;
>
> >> /* Allocate a temporary list of source pages for random
> access. */
> @@ -3284,12 +3287,18 @@ intel_rotate_fb_obj_pages(struct
> i915_ggtt_view *ggtt_view,
> >> if (!page_addr_list)
> >> > return ERR_PTR(ret);
>
> +>> /* Account for UV plane with NV12. */
> +>> if (rot_info->pixel_format == DRM_FORMAT_NV12)
> +>> > size_pages_uv = rot_info->size_uv >> PAGE_SHIFT;
> +>> else
> +>> > size_pages_uv = 0;
> +
> >> /* Allocate target SG list. */
> >> st = kmalloc(sizeof(*st), GFP_KERNEL);
> >> if (!st)
> >> > goto err_st_alloc;
>
> ->> ret = sg_alloc_table(st, size_pages, GFP_KERNEL);
> +>> ret = sg_alloc_table(st, size_pages + size_pages_uv,
> GFP_KERNEL);
> >> if (ret)
> >> > goto err_sg_alloc;
>
> @@ -3301,15 +3310,30 @@ intel_rotate_fb_obj_pages(struct
> i915_ggtt_view *ggtt_view,
> >> }
>
> >> /* Rotate the pages. */
> ->> rotate_pages(page_addr_list, 0,
> +>> sg = rotate_pages(page_addr_list, 0,
> >> > rot_info->width_pages, rot_info->height_pages,
> >> > st, NULL);
>
> +>> /* Append the UV plane if NV12. */
> +>> if (rot_info->pixel_format == DRM_FORMAT_NV12) {
> +>> > uv_start_page = size_pages;
> +
> +>> > /* Check for tile-row un-alignment. */
> +>> > if (offset_in_page(rot_info->uv_offset))
> +>> > > uv_start_page--;
> +
> +>> > rotate_pages(page_addr_list, uv_start_page,
> +>> > > rot_info->width_pages_uv,
> +>> > > rot_info->height_pages_uv,
> +>> > > st, sg);
> +>> }
> +
> >> DRM_DEBUG_KMS(
> ->> > "Created rotated page mapping for object size
> %zu (pitch=%u, height=%u, pixel_format=0x%x, %ux%u tiles, %u
> pages).\n",
> +>> > "Created rotated page mapping for object size
> %zu (pitch=%u, height=%u, pixel_format=0x%x, %ux%u tiles, %u pages
> (%u plane 0)).\n",
> >> > obj->base.size, rot_info->pitch, rot_info
> ->height,
> >> > rot_info->pixel_format, rot_info->width_pages,
> ->> > rot_info->height_pages, size_pages);
> +>> > rot_info->height_pages, size_pages +
> size_pages_uv,
> +>> > size_pages);
>
> >> drm_free_large(page_addr_list);
>
> @@ -3321,10 +3345,11 @@ err_st_alloc:
> >> drm_free_large(page_addr_list);
>
> >> DRM_DEBUG_KMS(
> ->> > "Failed to create rotated mapping for object
> size %zu! (%d) (pitch=%u, height=%u, pixel_format=0x%x, %ux%u tiles,
> %u pages)\n",
> +>> > "Failed to create rotated mapping for object
> size %zu! (%d) (pitch=%u, height=%u, pixel_format=0x%x, %ux%u tiles,
> %u pages (%u plane 0))\n",
> >> > obj->base.size, ret, rot_info->pitch, rot_info
> ->height,
> >> > rot_info->pixel_format, rot_info->width_pages,
> ->> > rot_info->height_pages, size_pages);
> +>> > rot_info->height_pages, size_pages +
> size_pages_uv,
> +>> > size_pages);
> >> return ERR_PTR(ret);
> }
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
> b/drivers/gpu/drm/i915/i915_gem_gtt.h
> index 82750073d5b3..197183d5c543 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.h
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
> @@ -138,10 +138,13 @@ enum i915_ggtt_view_type {
> struct intel_rotation_info {
> >> unsigned int height;
> >> unsigned int pitch;
> +>> unsigned int uv_offset;
> >> uint32_t pixel_format;
Re: [Intel-gfx] [RFC PATCH] drm/i915/skl: Add DC6 disabling as a power well
On Mon, Sep 21, 2015 at 12:43:36PM +0200, Patrik Jakobsson wrote:
> On Thu, Sep 17, 2015 at 02:14:37PM +0300, Ville Syrjälä wrote:
> > On Wed, Sep 16, 2015 at 11:10:07PM +0300, Ville Syrjälä wrote:
> > > On Fri, Sep 11, 2015 at 01:55:22PM +0200, Patrik Jakobsson wrote:
> > > > We need to be able to control if DC6 is allowed or not. Much like
> > > > requesting power to a specific piece of the hardware we need to be able
> > > > to request that we don't enter DC6 during certain hw access.
> > > >
> > > > To solve this without introducing too much infrastructure I'm hooking
> > > > into the power well / power domain framework. DC6 prevention is modeled
> > > > much like an enabled power well. Thus I'm using the terminology on/off
> > > > for DC states instead of enable/disable.
> > > >
> > > > The problem that started this work is the need for DC6 to be disabled
> > > > when accessing DP_AUX_A during CRTC on/off. That is also fixed in this
> > > > patch.
> > > >
> > > > This is posted as an RFC since DMC and DC state handling is being
> > > > reworked and will possibly affect the outcome of this patch. The patch
> > > > has known warnings.
> > > >
> > > > Signed-off-by: Patrik Jakobsson
> > > > ---
> > > > drivers/gpu/drm/i915/intel_ddi.c| 9 +
> > > > drivers/gpu/drm/i915/intel_drv.h| 2 +
> > > > drivers/gpu/drm/i915/intel_runtime_pm.c | 69
> > > > +
> > > > 3 files changed, 64 insertions(+), 16 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > > index 4823184..c2c1ad2 100644
> > > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > > @@ -2288,6 +2288,8 @@ static void intel_ddi_pre_enable(struct
> > > > intel_encoder *intel_encoder)
> > > > if (type == INTEL_OUTPUT_DISPLAYPORT || type ==
> > > > INTEL_OUTPUT_EDP) {
> > > > struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > > >
> > > > + intel_display_power_get(dev_priv, POWER_DOMAIN_AUX_A);
> > > > +
> > >
> > > These I think shouldn't be necessary with my
> > > intel_display_port_aux_power_domain() stuff since intel_dp_aux_ch() will
> > > itself grab the appropriate power domain.
> > >
> > > That's of course assuming that AUX is the only reason why we need to
> > > keep DC6 disabled here.
> > >
> > > > intel_dp_set_link_params(intel_dp, crtc->config);
> > > >
> > > > intel_ddi_init_dp_buf_reg(intel_encoder);
> > > > @@ -2297,6 +2299,8 @@ static void intel_ddi_pre_enable(struct
> > > > intel_encoder *intel_encoder)
> > > > intel_dp_complete_link_train(intel_dp);
> > > > if (port != PORT_A || INTEL_INFO(dev)->gen >= 9)
> > > > intel_dp_stop_link_train(intel_dp);
> > > > +
> > > > + intel_display_power_put(dev_priv, POWER_DOMAIN_AUX_A);
> > > > } else if (type == INTEL_OUTPUT_HDMI) {
> > > > struct intel_hdmi *intel_hdmi =
> > > > enc_to_intel_hdmi(encoder);
> > > >
> > > > @@ -2339,9 +2343,14 @@ static void intel_ddi_post_disable(struct
> > > > intel_encoder *intel_encoder)
> > > >
> > > > if (type == INTEL_OUTPUT_DISPLAYPORT || type ==
> > > > INTEL_OUTPUT_EDP) {
> > > > struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > > > +
> > > > + intel_display_power_get(dev_priv, POWER_DOMAIN_AUX_A);
> > > > +
> > > > intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> > > > intel_edp_panel_vdd_on(intel_dp);
> > > > intel_edp_panel_off(intel_dp);
> > > > +
> > > > + intel_display_power_put(dev_priv, POWER_DOMAIN_AUX_A);
> > > > }
> > > >
> > > > if (IS_SKYLAKE(dev))
> > > > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > > > b/drivers/gpu/drm/i915/intel_drv.h
> > > > index 46484e4..82489ad 100644
> > > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > > @@ -1367,6 +1367,8 @@ void chv_phy_powergate_lanes(struct intel_encoder
> > > > *encoder,
> > > > bool override, unsigned int mask);
> > > > bool chv_phy_powergate_ch(struct drm_i915_private *dev_priv, enum
> > > > dpio_phy phy,
> > > > enum dpio_channel ch, bool override);
> > > > +void skl_enable_dc6(struct drm_i915_private *dev_priv);
> > > > +void skl_disable_dc6(struct drm_i915_private *dev_priv);
> > > >
> > > >
> > > > /* intel_pm.c */
> > > > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > > index 3f682a1..e30c9a6 100644
> > > > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > > @@ -335,6 +335,10 @@ static void hsw_set_power_well(struct
> > > > drm_i915_private *dev_priv,
> > > > SKL_DISPLAY_P
Re: [Intel-gfx] [PATCH 2/4] drm/i915: Support appending to the rotated pages mapping
Hi,
On ma, 2015-09-21 at 10:45 +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> By providing a start offset into the source array of pages, and
> returning the
> end position in the scatter-gather table, we will be able to append
> the UV
> plane to the rotated mapping in later patches.
>
> v2: Rebase.
>
> Signed-off-by: Tvrtko Ursulin
Reviewed-by: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 21 +
> 1 file changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 87862813cfde..59c934fb9230 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -3234,15 +3234,18 @@ i915_gem_obj_lookup_or_create_ggtt_vma(struct
> drm_i915_gem_object *obj,
>
> }
>
> -static void
> -rotate_pages(dma_addr_t *in, unsigned int width, unsigned int
> height,
> - struct sg_table *st)
> +static struct scatterlist *
> +rotate_pages(dma_addr_t *in, unsigned int offset,
> + unsigned int width, unsigned int height,
> + struct sg_table *st, struct scatterlist *sg)
> {
> unsigned int column, row;
> unsigned int src_idx;
> - struct scatterlist *sg = st->sgl;
>
> - st->nents = 0;
> + if (!sg) {
> + st->nents = 0;
> + sg = st->sgl;
> + }
>
> for (column = 0; column < width; column++) {
> src_idx = width * (height - 1) + column;
> @@ -3253,12 +3256,14 @@ rotate_pages(dma_addr_t *in, unsigned int
> width, unsigned int height,
>* The only thing we need are DMA addresses.
>*/
> sg_set_page(sg, NULL, PAGE_SIZE, 0);
> - sg_dma_address(sg) = in[src_idx];
> + sg_dma_address(sg) = in[offset + src_idx];
> sg_dma_len(sg) = PAGE_SIZE;
> sg = sg_next(sg);
> src_idx -= width;
> }
> }
> +
> + return sg;
> }
>
> static struct sg_table *
> @@ -3296,9 +3301,9 @@ intel_rotate_fb_obj_pages(struct i915_ggtt_view
> *ggtt_view,
> }
>
> /* Rotate the pages. */
> - rotate_pages(page_addr_list,
> + rotate_pages(page_addr_list, 0,
>rot_info->width_pages, rot_info->height_pages,
> - st);
> + st, NULL);
>
> DRM_DEBUG_KMS(
> "Created rotated page mapping for object size
> %zu (pitch=%u, height=%u, pixel_format=0x%x, %ux%u tiles, %u
> pages).\n",
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915: Support planar formats in tile height calculations
On ma, 2015-09-21 at 10:45 +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> This will be needed for NV12 support.
>
> v2: Rebase.
>
> Signed-off-by: Tvrtko Ursulin
Reviewed-by: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/intel_display.c | 10 +-
> drivers/gpu/drm/i915/intel_drv.h | 2 +-
> drivers/gpu/drm/i915/intel_sprite.c | 2 +-
> 3 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index fc0086748b71..e19b8e699c00 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2190,7 +2190,7 @@ static bool need_vtd_wa(struct drm_device *dev)
>
> unsigned int
> intel_tile_height(struct drm_device *dev, uint32_t pixel_format,
> - uint64_t fb_format_modifier)
> + uint64_t fb_format_modifier, unsigned int plane)
> {
> unsigned int tile_height;
> uint32_t pixel_bytes;
> @@ -2206,7 +2206,7 @@ intel_tile_height(struct drm_device *dev,
> uint32_t pixel_format,
> tile_height = 32;
> break;
> case I915_FORMAT_MOD_Yf_TILED:
> - pixel_bytes = drm_format_plane_cpp(pixel_format, 0);
> + pixel_bytes = drm_format_plane_cpp(pixel_format,
> plane);
> switch (pixel_bytes) {
> default:
> case 1:
> @@ -2240,7 +2240,7 @@ intel_fb_align_height(struct drm_device *dev,
> unsigned int height,
> uint32_t pixel_format, uint64_t
> fb_format_modifier)
> {
> return ALIGN(height, intel_tile_height(dev, pixel_format,
> -fb_format_modifier));
> +fb_format_modifier,
> 0));
> }
>
> static int
> @@ -2266,7 +2266,7 @@ intel_fill_fb_ggtt_view(struct i915_ggtt_view
> *view, struct drm_framebuffer *fb,
> info->fb_modifier = fb->modifier[0];
>
> tile_height = intel_tile_height(fb->dev, fb->pixel_format,
> - fb->modifier[0]);
> + fb->modifier[0], 0);
> tile_pitch = PAGE_SIZE / tile_height;
> info->width_pages = DIV_ROUND_UP(fb->pitches[0],
> tile_pitch);
> info->height_pages = DIV_ROUND_UP(fb->height, tile_height);
> @@ -3069,7 +3069,7 @@ static void skylake_update_primary_plane(struct
> drm_crtc *crtc,
> if (intel_rotation_90_or_270(rotation)) {
> /* stride = Surface height in tiles */
> tile_height = intel_tile_height(dev, fb
> ->pixel_format,
> - fb->modifier[0]);
> + fb->modifier[0], 0);
> stride = DIV_ROUND_UP(fb->height, tile_height);
> x_offset = stride * tile_height - y - src_h;
> y_offset = x;
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 1df6ebf50146..94dab9bd8ebd 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1085,7 +1085,7 @@ int intel_plane_atomic_calc_changes(struct
> drm_crtc_state *crtc_state,
>
> unsigned int
> intel_tile_height(struct drm_device *dev, uint32_t pixel_format,
> - uint64_t fb_format_modifier);
> + uint64_t fb_format_modifier, unsigned int plane);
>
> static inline bool
> intel_rotation_90_or_270(unsigned int rotation)
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> b/drivers/gpu/drm/i915/intel_sprite.c
> index 79f7cc247ab7..4372fa0b1ec5 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -240,7 +240,7 @@ skl_update_plane(struct drm_plane *drm_plane,
> struct drm_crtc *crtc,
> if (intel_rotation_90_or_270(rotation)) {
> /* stride: Surface height in tiles */
> tile_height = intel_tile_height(dev, fb
> ->pixel_format,
> - fb->modifier[0]);
> + fb->modifier[0], 0);
> stride = DIV_ROUND_UP(fb->height, tile_height);
> plane_size = (src_w << 16) | src_h;
> x_offset = stride * tile_height - y - (src_h + 1);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH] drm/i915/skl: Add DC6 disabling as a power well
On Thu, Sep 17, 2015 at 02:14:37PM +0300, Ville Syrjälä wrote:
> On Wed, Sep 16, 2015 at 11:10:07PM +0300, Ville Syrjälä wrote:
> > On Fri, Sep 11, 2015 at 01:55:22PM +0200, Patrik Jakobsson wrote:
> > > We need to be able to control if DC6 is allowed or not. Much like
> > > requesting power to a specific piece of the hardware we need to be able
> > > to request that we don't enter DC6 during certain hw access.
> > >
> > > To solve this without introducing too much infrastructure I'm hooking
> > > into the power well / power domain framework. DC6 prevention is modeled
> > > much like an enabled power well. Thus I'm using the terminology on/off
> > > for DC states instead of enable/disable.
> > >
> > > The problem that started this work is the need for DC6 to be disabled
> > > when accessing DP_AUX_A during CRTC on/off. That is also fixed in this
> > > patch.
> > >
> > > This is posted as an RFC since DMC and DC state handling is being
> > > reworked and will possibly affect the outcome of this patch. The patch
> > > has known warnings.
> > >
> > > Signed-off-by: Patrik Jakobsson
> > > ---
> > > drivers/gpu/drm/i915/intel_ddi.c| 9 +
> > > drivers/gpu/drm/i915/intel_drv.h| 2 +
> > > drivers/gpu/drm/i915/intel_runtime_pm.c | 69
> > > +
> > > 3 files changed, 64 insertions(+), 16 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > index 4823184..c2c1ad2 100644
> > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > @@ -2288,6 +2288,8 @@ static void intel_ddi_pre_enable(struct
> > > intel_encoder *intel_encoder)
> > > if (type == INTEL_OUTPUT_DISPLAYPORT || type == INTEL_OUTPUT_EDP) {
> > > struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > >
> > > + intel_display_power_get(dev_priv, POWER_DOMAIN_AUX_A);
> > > +
> >
> > These I think shouldn't be necessary with my
> > intel_display_port_aux_power_domain() stuff since intel_dp_aux_ch() will
> > itself grab the appropriate power domain.
> >
> > That's of course assuming that AUX is the only reason why we need to
> > keep DC6 disabled here.
> >
> > > intel_dp_set_link_params(intel_dp, crtc->config);
> > >
> > > intel_ddi_init_dp_buf_reg(intel_encoder);
> > > @@ -2297,6 +2299,8 @@ static void intel_ddi_pre_enable(struct
> > > intel_encoder *intel_encoder)
> > > intel_dp_complete_link_train(intel_dp);
> > > if (port != PORT_A || INTEL_INFO(dev)->gen >= 9)
> > > intel_dp_stop_link_train(intel_dp);
> > > +
> > > + intel_display_power_put(dev_priv, POWER_DOMAIN_AUX_A);
> > > } else if (type == INTEL_OUTPUT_HDMI) {
> > > struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
> > >
> > > @@ -2339,9 +2343,14 @@ static void intel_ddi_post_disable(struct
> > > intel_encoder *intel_encoder)
> > >
> > > if (type == INTEL_OUTPUT_DISPLAYPORT || type == INTEL_OUTPUT_EDP) {
> > > struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > > +
> > > + intel_display_power_get(dev_priv, POWER_DOMAIN_AUX_A);
> > > +
> > > intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> > > intel_edp_panel_vdd_on(intel_dp);
> > > intel_edp_panel_off(intel_dp);
> > > +
> > > + intel_display_power_put(dev_priv, POWER_DOMAIN_AUX_A);
> > > }
> > >
> > > if (IS_SKYLAKE(dev))
> > > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > > b/drivers/gpu/drm/i915/intel_drv.h
> > > index 46484e4..82489ad 100644
> > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > @@ -1367,6 +1367,8 @@ void chv_phy_powergate_lanes(struct intel_encoder
> > > *encoder,
> > >bool override, unsigned int mask);
> > > bool chv_phy_powergate_ch(struct drm_i915_private *dev_priv, enum
> > > dpio_phy phy,
> > > enum dpio_channel ch, bool override);
> > > +void skl_enable_dc6(struct drm_i915_private *dev_priv);
> > > +void skl_disable_dc6(struct drm_i915_private *dev_priv);
> > >
> > >
> > > /* intel_pm.c */
> > > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > index 3f682a1..e30c9a6 100644
> > > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > @@ -335,6 +335,10 @@ static void hsw_set_power_well(struct
> > > drm_i915_private *dev_priv,
> > > SKL_DISPLAY_POWERWELL_1_POWER_DOMAINS | \
> > > BIT(POWER_DOMAIN_PLLS) |\
> > > BIT(POWER_DOMAIN_INIT))
> > > +#define SKL_DISPLAY_DC6_OFF_POWER_DOMAINS ( \
> > > + SKL_DISPLAY_POWERWELL_2_POWER_DOMAINS | \
> > > + BIT(POWER_DOMAIN_AUX_A))
> > > +
> > > #define SKL_DISPLAY_ALWAYS_ON_POWER_DOMAINS (\
> > > (POWER_DOMAIN_MASK & ~(SKL_DISPLAY_POWERWELL_1_POWER_DOMAINS | \
>
Re: [Intel-gfx] [BXT MIPI PATCH v3 05/14] drm/i915/bxt: DSI encoder support in CRTC modeset
>-Original Message-
>From: Nikula, Jani
>Sent: Friday, September 18, 2015 7:48 PM
>To: Shankar, Uma; intel-gfx@lists.freedesktop.org
>Cc: Kumar, Shobhit; Deak, Imre; Sharma, Shashank; Shankar, Uma
>Subject: Re: [BXT MIPI PATCH v3 05/14] drm/i915/bxt: DSI encoder support in
>CRTC modeset
>
>On Tue, 01 Sep 2015, Uma Shankar wrote:
>> From: Shashank Sharma
>>
>> SKL and BXT qualifies the HAS_DDI() check, and hence haswell modeset
>> functions are re-used for modeset sequence. But DDI interface doesn't
>> include support for DSI.
>> This patch adds:
>> 1. cases for DSI encoder, in those modeset functions and allows
>>a CRTC modeset
>> 2. Adds call to pre_pll enabled from CRTC modeset function. Nothing
>>needs to be done as such in CRTC for DSI encoder, as PLL, clock
>>and and transcoder programming will be taken care in encoder's
>>pre_enable and pre_pll_enable function.
>>
>> v2: Fixed Jani's review comments. Added INVALID_PORT for non DDI
>> encoder like DSI for platforms having HAS_DDI as true.
>>
>> v3: Rebased on latest drm-nightly branch. Added a WARN_ON for invalid
>> encoder.
>>
>> Signed-off-by: Shashank Sharma
>> Signed-off-by: Uma Shankar
>> ---
>> drivers/gpu/drm/i915/i915_drv.h |1 +
>> drivers/gpu/drm/i915/intel_ddi.c | 29 -
>> drivers/gpu/drm/i915/intel_display.c | 19 ++-
>> drivers/gpu/drm/i915/intel_dp_mst.c |1 +
>> drivers/gpu/drm/i915/intel_opregion.c |3 ++-
>> 5 files changed, 46 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h
>> b/drivers/gpu/drm/i915/i915_drv.h index fd1de45..78d31c5 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -142,6 +142,7 @@ enum plane {
>> #define sprite_name(p, s) ((p) * INTEL_INFO(dev)->num_sprites[(p)] +
>> (s) + 'A')
>>
>> enum port {
>> +PORT_INVALID = -1,
>> PORT_A = 0,
>> PORT_B,
>> PORT_C,
>> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
>> b/drivers/gpu/drm/i915/intel_ddi.c
>> index cacb07b..5d5aad2 100644
>> --- a/drivers/gpu/drm/i915/intel_ddi.c
>> +++ b/drivers/gpu/drm/i915/intel_ddi.c
>> @@ -227,6 +227,10 @@ static void ddi_get_encoder_port(struct
>intel_encoder *intel_encoder,
>> } else if (type == INTEL_OUTPUT_ANALOG) {
>> *dig_port = NULL;
>> *port = PORT_E;
>> +} else if (type == INTEL_OUTPUT_DSI) {
>> +*dig_port = NULL;
>> +*port = PORT_INVALID;
>> +DRM_DEBUG_KMS("Encoder type: DSI. Returning...\n");
>
>Please remind me again what are the legitimate paths to get here with DSI?
>
>With all the changes and warns across the driver, I'm beginning to think we
>should have a version of this function that accepts DSI, and another one that
>(calls the other one) and WARNS on DSI, and that should be called on all paths
>that should never encounter a DSI encoder.
>
>The proliferation of WARNS all over the place is not very nice.
>
>I'm sorry, I know this is not the review I gave previously on this.
>
>BR,
>Jani.
This is a tricky piece Jani. Our code for BXT extensively uses haswell
functions which was a DDI only implementation.
So many functions just use intel_ddi_get_encoder_port (bxt_ddi_clock_get is one
such example). Currently I have added
WARN_ON in all of these functions, though some may not get called if DSI
encoder is present. We can remove those,
but still this will be a good check to have IMO.
Overall, I feel even if we implement two separate functions, for the generic
functions to pick the correct one, we may have
to have a DSI check there in those generic functions.
Please suggest.
Regards,
Uma Shankar
>> } else {
>> DRM_ERROR("Invalid DDI encoder type %d\n", type);
>> BUG();
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [BXT MIPI PATCH v3 11/14] drm/i915/bxt: Modify BXT BLC according to VBT changes
>-Original Message-
>From: Nikula, Jani
>Sent: Friday, September 18, 2015 7:21 PM
>To: Shankar, Uma; intel-gfx@lists.freedesktop.org
>Cc: Kumar, Shobhit; Deak, Imre; Kamath, Sunil; Kannan, Vandana; Shankar, Uma
>Subject: Re: [BXT MIPI PATCH v3 11/14] drm/i915/bxt: Modify BXT BLC
>according to VBT changes
>
>On Tue, 01 Sep 2015, Uma Shankar wrote:
>> From: Sunil Kamath
>>
>> Latest VBT mentions which set of registers will be used for BLC, as
>> controller number field. Making use of this field in BXT BLC
>> implementation. Also, the registers are used in case control pin
>> indicates display DDI. Adding a check for this.
>> According to Bspec, BLC_PWM_*_2 uses the display utility pin for output.
>> To use backlight 2, enable the utility pin with mode = PWM
>>v2: Jani's review comments
>>addressed
>>- Add a prefix _ to BXT BLC registers definitions.
>>- Add "bxt only" comment for u8 controller
>>- Remove control_pin check for DDI controller
>>- Check for valid controller values
>>- Set pipe bits in UTIL_PIN_CTL
>>- Enable/Disable UTIL_PIN_CTL in enable/disable_backlight()
>>- If BLC 2 is used, read active_low_pwm from UTIL_PIN polarity
>>Satheesh's review comment addressed
>>- If UTIL PIN is already enabled, BIOS would have programmed it. No
>>need to disable and enable again.
>>v3: Jani's review comments
>>- add UTIL_PIN_PIPE_MASK and UTIL_PIN_MODE_MASK
>>- Disable UTIL_PIN if controller 1 is used
>>- Mask out UTIL_PIN_PIPE_MASK and UTIL_PIN_MODE_MASK before
>enabling
>>UTIL_PIN
>>- check valid controller value in intel_bios.c
>>- add backlight.util_pin_active_low
>>- disable util pin before enabling
>>v4: Change for BXT-PO branch:
>>Stubbed unwanted definition which was existing before
>>because of DC6 patch.
>>UTIL_PIN_MODE_PWM (0x1b << 24)
>>
>> v2: Fixed Jani's review comment.
>>
>> v3: Split the backight PWM frequency programming into separate patch,
>> in cases BIOS doesn't initializes it.
>>
>> Signed-off-by: Vandana Kannan
>> Signed-off-by: Sunil Kamath
>> Signed-off-by: Uma Shankar
>> ---
>> drivers/gpu/drm/i915/i915_reg.h| 28
>> drivers/gpu/drm/i915/intel_drv.h |2 +
>> drivers/gpu/drm/i915/intel_panel.c | 84 --
>--
>> 3 files changed, 89 insertions(+), 25 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> b/drivers/gpu/drm/i915/i915_reg.h index e43b053..8407b5c 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -3512,17 +3512,29 @@ enum skl_disp_power_wells {
>> #define UTIL_PIN_CTL0x48400
>> #define UTIL_PIN_ENABLE (1 << 31)
>>
>> void intel_panel_disable_backlight(struct intel_connector *connector)
>> @@ -988,16 +998,39 @@ static void bxt_enable_backlight(struct
>intel_connector *connector)
>> struct drm_device *dev = connector->base.dev;
>> struct drm_i915_private *dev_priv = dev->dev_private;
>> struct intel_panel *panel = &connector->panel;
>> -u32 pwm_ctl;
>> +enum pipe pipe = intel_get_pipe_from_connector(connector);
>> +u32 pwm_ctl, val;
>> +
>> +/* To use 2nd set of backlight registers, utility pin has to be
>> + * enabled with PWM mode.
>> + * The field should only be changed when the utility pin is disabled
>> + */
>> +if (panel->backlight.controller == 1) {
>> +val = I915_READ(UTIL_PIN_CTL);
>> +if (val & UTIL_PIN_ENABLE) {
>> +DRM_DEBUG_KMS("util pin already enabled\n");
>> +val &= ~UTIL_PIN_ENABLE;
>> +I915_WRITE(UTIL_PIN_CTL, val);
>> +}
>> +/* mask out UTIL_PIN_PIPE and UTIL_PIN_MODE */
>> +val &= ~(UTIL_PIN_PIPE_MASK | UTIL_PIN_MODE_MASK);
>
>Please start out with 0 val instead of modifying existing state. This is the
>style
>across backlight enabling, apart from setup which gathers the needed state.
>
>With that fixed,
>
>Reviewed-by: Jani Nikula
>
Thanks for the comment and spotting it out. Will update this in subsequent
patchset.
Regards,
Uma Shankar
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Split alloc from init for lrc
Hi,
On 09/11/2015 12:53 PM, Nick Hoath wrote:
> Extend init/init_hw split to context init.
> - Move context initialisation in to i915_gem_init_hw
> - Move one off initialisation for render ring to
> i915_gem_validate_context
> - Move default context initialisation to logical_ring_init
>
> Rename intel_lr_context_deferred_create to
> intel_lr_context_deferred_alloc, to reflect reduced functionality &
> alloc/init split.
>
> This patch is intended to split out the allocation of resources &
> initialisation to allow easier reuse of code for resume/gpu reset.
>
> v2: Removed function ptr wrapping of do_switch_context (Daniel Vetter)
> Left ->init_context int intel_lr_context_deferred_alloc
> (Daniel Vetter)
> Remove unnecessary init flag & ring type test. (Daniel Vetter)
> Improve commit message (Daniel Vetter)
> v3: On init/reinit, set the hw next sequence number to the sw next
> sequence number. This is set to 1 at driver load time. This prevents
> the seqno being reset on reinit (Chris Wilson)
> v4: Set seqno back to ~0 - 0x1000 at start-of-day, and increment by 0x100
> on reset.
> This makes it obvious which bbs are which after a reset. (David Gordon
> & John Harrison)
> Rebase.
> v5: Rebase. Fixed rebase breakage. Put context pinning in separate
> function. Removed code churn. (Thomas Daniel)
> v6: Cleanup up issues introduced in v2 & v5 (Thomas Daniel)
>
> Issue: VIZ-4798
> Signed-off-by: Nick Hoath
> Cc: Daniel Vetter
> Cc: Chris Wilson
> Cc: John Harrison
> Cc: David Gordon
> Cc: Thomas Daniel
> ---
> drivers/gpu/drm/i915/i915_drv.h| 1 -
> drivers/gpu/drm/i915/i915_gem.c| 22 ++--
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
> drivers/gpu/drm/i915/intel_lrc.c | 164
> ++---
> drivers/gpu/drm/i915/intel_lrc.h | 4 +-
> 5 files changed, 99 insertions(+), 94 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 18859cd..23dd57d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -890,7 +890,6 @@ struct intel_context {
> } legacy_hw_ctx;
>
> /* Execlists */
> - bool rcs_initialized;
> struct {
> struct drm_i915_gem_object *state;
> struct intel_ringbuffer *ringbuf;
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 5859fc4..e7eb325 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4650,14 +4650,8 @@ int i915_gem_init_rings(struct drm_device *dev)
> goto cleanup_vebox_ring;
> }
>
> - ret = i915_gem_set_seqno(dev, ((u32)~0 - 0x1000));
> - if (ret)
> - goto cleanup_bsd2_ring;
> -
> return 0;
>
> -cleanup_bsd2_ring:
> - intel_cleanup_ring_buffer(&dev_priv->ring[VCS2]);
> cleanup_vebox_ring:
> intel_cleanup_ring_buffer(&dev_priv->ring[VECS]);
> cleanup_blt_ring:
> @@ -4743,6 +4737,14 @@ i915_gem_init_hw(struct drm_device *dev)
> goto out;
> }
>
> + /*
> + * Increment the next seqno by 0x100 so we have a visible break
> + * on re-initialisation
> + */
> + ret = i915_gem_set_seqno(dev, dev_priv->next_seqno+0x100);
> + if (ret)
> + goto out;
> +
> /* Now it is safe to go back round and do everything else: */
> for_each_ring(ring, dev_priv, i) {
> struct drm_i915_gem_request *req;
> @@ -4944,6 +4946,14 @@ i915_gem_load(struct drm_device *dev)
> dev_priv->num_fence_regs =
> I915_READ(vgtif_reg(avail_rs.fence_num));
>
> + /*
> + * Set initial sequence number for requests.
> + * Using this number allows the wraparound to happen early,
> + * catching any obvious problems.
> + */
> + dev_priv->next_seqno = ((u32)~0 - 0x1100);
> + dev_priv->last_seqno = ((u32)~0 - 0x1101);
> +
> /* Initialize fence registers to zero */
> INIT_LIST_HEAD(&dev_priv->mm.fence_list);
> i915_gem_restore_fences(dev);
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index a953d49..67ef118 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -1009,7 +1009,7 @@ i915_gem_validate_context(struct drm_device *dev,
> struct drm_file *file,
> }
>
> if (i915.enable_execlists && !ctx->engine[ring->id].state) {
> - int ret = intel_lr_context_deferred_create(ctx, ring);
> + int ret = intel_lr_context_deferred_alloc(ctx, ring);
> if (ret) {
> DRM_DEBUG("Could not create LRC %u: %d\n", ctx_id, ret);
> return ERR_PTR(ret);
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/
Re: [Intel-gfx] [BXT MIPI PATCH v3 14/14] drm/i915: Added BXT DSI backlight support
>-Original Message-
>From: Nikula, Jani
>Sent: Friday, September 18, 2015 7:08 PM
>To: Shankar, Uma; intel-gfx@lists.freedesktop.org
>Cc: Kumar, Shobhit; Deak, Imre; Shankar, Uma
>Subject: Re: [BXT MIPI PATCH v3 14/14] drm/i915: Added BXT DSI backlight
>support
>
>On Tue, 01 Sep 2015, Uma Shankar wrote:
>> DSI backlight support for bxt is added.
>>
>> TODO: There is no support for backlight control in drm panel
>> framework. This will be added as part of VBT version patches
>> fixing the backlight sequence.
>>
>> v2: Fixed Jani's review comments from previous patch. Added the
>> BXT DSI backlight code in this patch. Backlight setup and
>> enable/disable code for backlight is added in intel_dsi.c.
>>
>> v3: Rebased on latest drm-nightly. Fixed Jani's review comments.
>
>I'm not sure why these calls need to be within IS_BROXTON blocks. What
>happens with the current backlight calls? Shouldn't we just have one set of
>calls?
>
>Also, I think we should get this [1] in first, and see how that affects things.
>
>BR,
>Jani.
>
>[1] http://mid.gmane.org/cover.1442227790.git.jani.nik...@intel.com
>
The idea was not to disturb existing platforms and add support for BXT. We can
hold this patch back and get the patch you mentioned merged,
Accordingly if needed we can create a follow up patch to iron things out.
Regards,
Uma Shankar
>>
>> Signed-off-by: Uma Shankar
>> ---
>> drivers/gpu/drm/i915/intel_dsi.c | 20 +++-
>> 1 file changed, 19 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
>> b/drivers/gpu/drm/i915/intel_dsi.c
>> index 08bade2..aee1539 100644
>> --- a/drivers/gpu/drm/i915/intel_dsi.c
>> +++ b/drivers/gpu/drm/i915/intel_dsi.c
>> @@ -438,6 +438,7 @@ static void intel_dsi_enable(struct intel_encoder
>*encoder)
>> struct drm_device *dev = encoder->base.dev;
>> struct drm_i915_private *dev_priv = dev->dev_private;
>> struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
>> +struct intel_connector *intel_connector =
>> +intel_dsi->attached_connector;
>> enum port port;
>>
>> DRM_DEBUG_KMS("\n");
>> @@ -458,6 +459,11 @@ static void intel_dsi_enable(struct intel_encoder
>> *encoder)
>>
>> intel_dsi_port_enable(encoder);
>> }
>> +
>> +if (IS_BROXTON(dev)) {
>> +msleep(intel_dsi->backlight_on_delay);
>> +intel_panel_enable_backlight(intel_connector);
>> +}
>> }
>>
>> static void intel_dsi_pre_enable(struct intel_encoder *encoder) @@
>> -623,10 +629,16 @@ static void intel_dsi_post_disable(struct
>> intel_encoder *encoder) {
>> struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
>> struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
>> +struct intel_connector *intel_connector =
>> +intel_dsi->attached_connector;
>> u32 val;
>>
>> DRM_DEBUG_KMS("\n");
>>
>> +if (IS_BROXTON(dev_priv->dev)) {
>> +intel_panel_disable_backlight(intel_connector);
>> +msleep(intel_dsi->backlight_off_delay);
>> +}
>> +
>> intel_dsi_disable(encoder);
>>
>> intel_dsi_clear_device_ready(encoder);
>> @@ -1226,8 +1238,14 @@ void intel_dsi_init(struct drm_device *dev)
>>
>> intel_panel_init(&intel_connector->panel, fixed_mode, NULL);
>>
>> -return;
>> +/*
>> + * Pipe parameter is not used for BXT.
>> + * Passing INVALID_PIPE to adher to API requirement.
>> + */
>> +if (IS_BROXTON(dev))
>> +intel_panel_setup_backlight(connector, INVALID_PIPE);
>>
>> +return;
>> err:
>> drm_encoder_cleanup(&intel_encoder->base);
>> kfree(intel_dsi);
>> --
>> 1.7.9.5
>>
>
>--
>Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [BXT MIPI PATCH v3 12/14] drm/i915/bxt: Program Backlight PWM frequency
>-Original Message-
>From: Nikula, Jani
>Sent: Friday, September 18, 2015 7:03 PM
>To: Shankar, Uma; intel-gfx@lists.freedesktop.org
>Cc: Kumar, Shobhit; Deak, Imre; Shankar, Uma
>Subject: Re: [BXT MIPI PATCH v3 12/14] drm/i915/bxt: Program Backlight PWM
>frequency
>
>On Tue, 01 Sep 2015, Uma Shankar wrote:
>> In some cases, BIOS doesn't initializes DSI panel.DSI and backlight
>> registers are thereby not initialized. Programming the same in driver
>> backlight setup.
>>
>> Signed-off-by: Uma Shankar
>
>This is probably obsolete now. See current bxt_setup_backlight.
>
>BR,
>Jani.
>
Yeah, we can drop this patch since the values will be updated in VBT. Thanks
Jani for notifying.
>> ---
>> drivers/gpu/drm/i915/i915_reg.h|3 +++
>> drivers/gpu/drm/i915/intel_panel.c | 11 +++
>> 2 files changed, 14 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> b/drivers/gpu/drm/i915/i915_reg.h index 8407b5c..10f73b1 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -7166,6 +7166,9 @@ enum skl_disp_power_wells {
>> #define TRANS_MSA_12_BPC (3<<5)
>> #define TRANS_MSA_16_BPC (4<<5)
>>
>> +/* Max CDCLK freq for BXT in HZ */
>> +#define BXT_CDCLK_MAX 62400
>> +
>> /* LCPLL Control */
>> #define LCPLL_CTL 0x130040
>> #define LCPLL_PLL_DISABLE (1<<31)
>> diff --git a/drivers/gpu/drm/i915/intel_panel.c
>> b/drivers/gpu/drm/i915/intel_panel.c
>> index 9fcf86c..8225cea 100644
>> --- a/drivers/gpu/drm/i915/intel_panel.c
>> +++ b/drivers/gpu/drm/i915/intel_panel.c
>> @@ -1427,6 +1427,17 @@ bxt_setup_backlight(struct intel_connector
>*connector, enum pipe unused)
>> panel->backlight.max = I915_READ(
>> BXT_BLC_PWM_FREQ(panel->backlight.controller));
>>
>> +if (!panel->backlight.max) {
>> +DRM_DEBUG_KMS("PWM freq not programmed by BIOS\n");
>> +DRM_DEBUG_KMS("Programming PWM freq\n");
>> +
>> +/* Max Backlight = Max CD Clock / pwm freq) */
>> +panel->backlight.max = (BXT_CDCLK_MAX /
>> +dev_priv->vbt.backlight.pwm_freq_hz);
>> +I915_WRITE(BXT_BLC_PWM_FREQ(panel->backlight.controller),
>> +panel->backlight.max);
>> +}
>> +
>> val = bxt_get_backlight(connector);
>> panel->backlight.level = intel_panel_compute_brightness(connector,
>> val);
>>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [BXT MIPI PATCH v3 07/14] drm/i915/bxt: Program Tx Rx and Dphy clocks
>-Original Message-
>From: Nikula, Jani
>Sent: Friday, September 18, 2015 6:58 PM
>To: Shankar, Uma; intel-gfx@lists.freedesktop.org
>Cc: Kumar, Shobhit; Deak, Imre; Sharma, Shashank; Shankar, Uma
>Subject: Re: [BXT MIPI PATCH v3 07/14] drm/i915/bxt: Program Tx Rx and Dphy
>clocks
>
>On Tue, 01 Sep 2015, Uma Shankar wrote:
>> From: Shashank Sharma
>>
>> BXT DSI clocks are different than previous platforms. So adding a new
>> function to program following clocks and dividers:
>> 1. Program variable divider to generate input to Tx clock divider
>>(Output value must be < 39.5Mhz)
>> 2. Select divide by 2 option to get < 20Mhz for Tx clock 3. Program
>> 8by3 divider to generate Rx clock
>>
>> v2: Fixed Jani's review comments. Adjusted the Macro definition as
>> per convention. Simplified the logic for bit definitions for
>> MIPI PORT A and PORT C in same registers.
>>
>> v3: Refactored the macros for TX, RX Escape and DPHY clocks as per
>> Jani's suggestion.
>>
>> Signed-off-by: Shashank Sharma
>> Signed-off-by: Uma Shankar
>
>Minor comments below, anyway
Thanks for the comments Jani. Will update while sending next patchset.
>Reviewed-by: Jani Nikula
>
>> ---
>> drivers/gpu/drm/i915/i915_reg.h | 62
>++
>> drivers/gpu/drm/i915/intel_dsi_pll.c | 39 +
>> 2 files changed, 101 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> b/drivers/gpu/drm/i915/i915_reg.h index 57c5dbf..e43b053 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -7362,6 +7362,68 @@ enum skl_disp_power_wells {
>>
>> #define _MIPI_PORT(port, a, c) _PORT3(port, a, 0, c) /* ports A and
>C only */
>>
>> +/* BXT MIPI clock controls */
>> +#define BXT_MAX_VAR_OUTPUT_KHZ 39500
>> +
>> +#define BXT_MIPI_CLOCK_CTL 0x46090
>> +#define BXT_MIPI1_DIV_SHIFT26
>> +#define BXT_MIPI2_DIV_SHIFT10
>> +#define BXT_MIPI_DIV_SHIFT(port) \
>> +_MIPI_PORT(port, BXT_MIPI1_DIV_SHIFT, \
>> +BXT_MIPI2_DIV_SHIFT)
>> +/* Var clock divider to generate TX source. Result must be < 39.5 M */
>> +#define BXT_MIPI1_ESCLK_VAR_DIV_MASK (0x3F << 26)
>> +#define BXT_MIPI2_ESCLK_VAR_DIV_MASK (0x3F << 10)
>> +#define BXT_MIPI_ESCLK_VAR_DIV_MASK(port) \
>> +_MIPI_PORT(port, BXT_MIPI1_ESCLK_VAR_DIV_MASK, \
>> +
> BXT_MIPI2_ESCLK_VAR_DIV_MASK)
>> +
>> +#define BXT_MIPI_ESCLK_VAR_DIV(port, val) \
>> +(val << BXT_MIPI_DIV_SHIFT(port))
>> +/* TX control divider to select actual TX clock output from (8x/var) */
>> +#define BXT_MIPI1_TX_ESCLK_SHIFT 21
>> +#define BXT_MIPI2_TX_ESCLK_SHIFT 5
>> +#define BXT_MIPI_TX_ESCLK_SHIFT(port) \
>> +_MIPI_PORT(port, BXT_MIPI1_TX_ESCLK_SHIFT, \
>> +BXT_MIPI2_TX_ESCLK_SHIFT)
>> +#define BXT_MIPI1_TX_ESCLK_FIXDIV_MASK (3 << 21)
>> +#define BXT_MIPI2_TX_ESCLK_FIXDIV_MASK (3 << 5)
>> +#define BXT_MIPI_TX_ESCLK_FIXDIV_MASK(port)\
>> +_MIPI_PORT(port, BXT_MIPI1_TX_ESCLK_FIXDIV_MASK,
>\
>> +(2 << BXT_MIPI_RX_ESCLK_SHIFT(port))
>> +#define BXT_MIPI_RX_ESCLK_8X_BY4(port) \
>> +(3 << BXT_MIPI_RX_ESCLK_SHIFT(port))
>> +/* BXT: Always prog DPHY dividers to 00 */
>
>Actually BXT A stepping W/A, but I don't know the name for it.
>> +#define BXT_MIPI1_DPHY_DIV_SHIFT 16
>> +#define BXT_MIPI2_DPHY_DIV_SHIFT 0
>> +#define BXT_MIPI_DPHY_DIV_SHIFT(port) \
>> +_MIPI_PORT(port, BXT_MIPI1_DPHY_DIV_SHIFT, \
>> +BXT_MIPI2_DPHY_DIV_SHIFT)
>> +/* Program BXT Mipi clocks and dividers */ static void
>> +bxt_dsi_program_clocks(struct drm_device *dev, enum port port) {
>> +u32 tmp;
>> +u32 divider;
>> +u32 dsi_rate;
>> +u32 pll_ratio;
>> +struct drm_i915_private *dev_priv = dev->dev_private;
>> +
>> +/* Get the current DSI rate(actual) */
>> +pll_ratio = I915_READ(BXT_DSI_PLL_CTL) &
>> +BXT_DSI_PLL_RATIO_MASK;
>> +dsi_rate = (BXT_REF_CLOCK_KHZ * pll_ratio) / 2;
>> +
>> +/* Max possible output of clock is 39.5 MHz, program value -1 */
>> +divider = (dsi_rate / BXT_MAX_VAR_OUTPUT_KHZ) - 1;
>> +tmp |= BXT_MIPI_ESCLK_VAR_DIV(port, divider);
>> +
>> +/* Tx escape clock should be >=20MHz, so select divide by 2 */
>
>Actually the Tx escape clock must be as close as possible to, but not exceed,
>20
>MHz.
>> +tmp |= BXT_MIPI_TX_ESCLK_8XDIV_BY2(port);
>> +
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/skl: handle port E in cpt_digital_port_connected
On Mon, 21 Sep 2015, Mika Kuoppala wrote: > Jani Nikula writes: > >> SKL port E handling was added in >> >> commit 26951caf55d73ceb1967b0bf12f6d0b96853508e >> Author: Xiong Zhang >> Date: Mon Aug 17 15:55:50 2015 +0800 >> >> drm/i915/skl: enable DDI-E hotplug >> >> but the whole function was moved in a another branch in >> >> commit b93433ccf64846820b9448f5ff5dd4348b58a8ed >> Author: Jani Nikula >> Date: Thu Aug 20 10:47:36 2015 +0300 >> >> drm/i915: move ibx_digital_port_connected to intel_dp.c >> >> and the addition was lost at some backmerge that I was unable to >> identify. Put it back in. >> >> Signed-off-by: Jani Nikula > > Reviewed-by: Mika Kuoppala Thanks, pushed to drm-intel-next-queued. BR, Jani. > >> --- >> drivers/gpu/drm/i915/intel_dp.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/drivers/gpu/drm/i915/intel_dp.c >> b/drivers/gpu/drm/i915/intel_dp.c >> index a6872508adec..77e4115fc847 100644 >> --- a/drivers/gpu/drm/i915/intel_dp.c >> +++ b/drivers/gpu/drm/i915/intel_dp.c >> @@ -4583,6 +4583,9 @@ static bool cpt_digital_port_connected(struct >> drm_i915_private *dev_priv, >> case PORT_D: >> bit = SDE_PORTD_HOTPLUG_CPT; >> break; >> +case PORT_E: >> +bit = SDE_PORTE_HOTPLUG_SPT; >> +break; >> default: >> MISSING_CASE(port->port); >> return false; >> -- >> 2.1.4 >> >> ___ >> Intel-gfx mailing list >> Intel-gfx@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915: Support NV12 in rotated GGTT mapping
From: Tvrtko Ursulin
Just adding the rotated UV plane at the end of the rotated Y plane.
v2: Rebase.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 37 ++--
drivers/gpu/drm/i915/i915_gem_gtt.h | 3 +++
drivers/gpu/drm/i915/intel_display.c | 12
3 files changed, 46 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 59c934fb9230..2df9d16dcefd 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3272,10 +3272,13 @@ intel_rotate_fb_obj_pages(struct i915_ggtt_view
*ggtt_view,
{
struct intel_rotation_info *rot_info = &ggtt_view->rotation_info;
unsigned int size_pages = rot_info->size >> PAGE_SHIFT;
+ unsigned int size_pages_uv;
struct sg_page_iter sg_iter;
unsigned long i;
dma_addr_t *page_addr_list;
struct sg_table *st;
+ unsigned int uv_start_page;
+ struct scatterlist *sg;
int ret = -ENOMEM;
/* Allocate a temporary list of source pages for random access. */
@@ -3284,12 +3287,18 @@ intel_rotate_fb_obj_pages(struct i915_ggtt_view
*ggtt_view,
if (!page_addr_list)
return ERR_PTR(ret);
+ /* Account for UV plane with NV12. */
+ if (rot_info->pixel_format == DRM_FORMAT_NV12)
+ size_pages_uv = rot_info->size_uv >> PAGE_SHIFT;
+ else
+ size_pages_uv = 0;
+
/* Allocate target SG list. */
st = kmalloc(sizeof(*st), GFP_KERNEL);
if (!st)
goto err_st_alloc;
- ret = sg_alloc_table(st, size_pages, GFP_KERNEL);
+ ret = sg_alloc_table(st, size_pages + size_pages_uv, GFP_KERNEL);
if (ret)
goto err_sg_alloc;
@@ -3301,15 +3310,30 @@ intel_rotate_fb_obj_pages(struct i915_ggtt_view
*ggtt_view,
}
/* Rotate the pages. */
- rotate_pages(page_addr_list, 0,
+ sg = rotate_pages(page_addr_list, 0,
rot_info->width_pages, rot_info->height_pages,
st, NULL);
+ /* Append the UV plane if NV12. */
+ if (rot_info->pixel_format == DRM_FORMAT_NV12) {
+ uv_start_page = size_pages;
+
+ /* Check for tile-row un-alignment. */
+ if (offset_in_page(rot_info->uv_offset))
+ uv_start_page--;
+
+ rotate_pages(page_addr_list, uv_start_page,
+rot_info->width_pages_uv,
+rot_info->height_pages_uv,
+st, sg);
+ }
+
DRM_DEBUG_KMS(
- "Created rotated page mapping for object size %zu
(pitch=%u, height=%u, pixel_format=0x%x, %ux%u tiles, %u pages).\n",
+ "Created rotated page mapping for object size %zu
(pitch=%u, height=%u, pixel_format=0x%x, %ux%u tiles, %u pages (%u plane
0)).\n",
obj->base.size, rot_info->pitch, rot_info->height,
rot_info->pixel_format, rot_info->width_pages,
- rot_info->height_pages, size_pages);
+ rot_info->height_pages, size_pages + size_pages_uv,
+ size_pages);
drm_free_large(page_addr_list);
@@ -3321,10 +3345,11 @@ err_st_alloc:
drm_free_large(page_addr_list);
DRM_DEBUG_KMS(
- "Failed to create rotated mapping for object size %zu!
(%d) (pitch=%u, height=%u, pixel_format=0x%x, %ux%u tiles, %u pages)\n",
+ "Failed to create rotated mapping for object size %zu!
(%d) (pitch=%u, height=%u, pixel_format=0x%x, %ux%u tiles, %u pages (%u plane
0))\n",
obj->base.size, ret, rot_info->pitch, rot_info->height,
rot_info->pixel_format, rot_info->width_pages,
- rot_info->height_pages, size_pages);
+ rot_info->height_pages, size_pages + size_pages_uv,
+ size_pages);
return ERR_PTR(ret);
}
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 82750073d5b3..197183d5c543 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -138,10 +138,13 @@ enum i915_ggtt_view_type {
struct intel_rotation_info {
unsigned int height;
unsigned int pitch;
+ unsigned int uv_offset;
uint32_t pixel_format;
uint64_t fb_modifier;
unsigned int width_pages, height_pages;
uint64_t size;
+ unsigned int width_pages_uv, height_pages_uv;
+ uint64_t size_uv;
};
struct i915_ggtt_view {
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e19b8e699c00..2db7cc42539c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2263,6 +2263,7 @@ intel_fill_fb_
[Intel-gfx] [PATCH 2/4] drm/i915: Support appending to the rotated pages mapping
From: Tvrtko Ursulin
By providing a start offset into the source array of pages, and returning the
end position in the scatter-gather table, we will be able to append the UV
plane to the rotated mapping in later patches.
v2: Rebase.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 87862813cfde..59c934fb9230 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3234,15 +3234,18 @@ i915_gem_obj_lookup_or_create_ggtt_vma(struct
drm_i915_gem_object *obj,
}
-static void
-rotate_pages(dma_addr_t *in, unsigned int width, unsigned int height,
-struct sg_table *st)
+static struct scatterlist *
+rotate_pages(dma_addr_t *in, unsigned int offset,
+unsigned int width, unsigned int height,
+struct sg_table *st, struct scatterlist *sg)
{
unsigned int column, row;
unsigned int src_idx;
- struct scatterlist *sg = st->sgl;
- st->nents = 0;
+ if (!sg) {
+ st->nents = 0;
+ sg = st->sgl;
+ }
for (column = 0; column < width; column++) {
src_idx = width * (height - 1) + column;
@@ -3253,12 +3256,14 @@ rotate_pages(dma_addr_t *in, unsigned int width,
unsigned int height,
* The only thing we need are DMA addresses.
*/
sg_set_page(sg, NULL, PAGE_SIZE, 0);
- sg_dma_address(sg) = in[src_idx];
+ sg_dma_address(sg) = in[offset + src_idx];
sg_dma_len(sg) = PAGE_SIZE;
sg = sg_next(sg);
src_idx -= width;
}
}
+
+ return sg;
}
static struct sg_table *
@@ -3296,9 +3301,9 @@ intel_rotate_fb_obj_pages(struct i915_ggtt_view
*ggtt_view,
}
/* Rotate the pages. */
- rotate_pages(page_addr_list,
+ rotate_pages(page_addr_list, 0,
rot_info->width_pages, rot_info->height_pages,
-st);
+st, NULL);
DRM_DEBUG_KMS(
"Created rotated page mapping for object size %zu
(pitch=%u, height=%u, pixel_format=0x%x, %ux%u tiles, %u pages).\n",
--
2.5.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/i915: Support planar formats in tile height calculations
From: Tvrtko Ursulin
This will be needed for NV12 support.
v2: Rebase.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_display.c | 10 +-
drivers/gpu/drm/i915/intel_drv.h | 2 +-
drivers/gpu/drm/i915/intel_sprite.c | 2 +-
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index fc0086748b71..e19b8e699c00 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2190,7 +2190,7 @@ static bool need_vtd_wa(struct drm_device *dev)
unsigned int
intel_tile_height(struct drm_device *dev, uint32_t pixel_format,
- uint64_t fb_format_modifier)
+ uint64_t fb_format_modifier, unsigned int plane)
{
unsigned int tile_height;
uint32_t pixel_bytes;
@@ -2206,7 +2206,7 @@ intel_tile_height(struct drm_device *dev, uint32_t
pixel_format,
tile_height = 32;
break;
case I915_FORMAT_MOD_Yf_TILED:
- pixel_bytes = drm_format_plane_cpp(pixel_format, 0);
+ pixel_bytes = drm_format_plane_cpp(pixel_format, plane);
switch (pixel_bytes) {
default:
case 1:
@@ -2240,7 +2240,7 @@ intel_fb_align_height(struct drm_device *dev, unsigned
int height,
uint32_t pixel_format, uint64_t fb_format_modifier)
{
return ALIGN(height, intel_tile_height(dev, pixel_format,
- fb_format_modifier));
+ fb_format_modifier, 0));
}
static int
@@ -2266,7 +2266,7 @@ intel_fill_fb_ggtt_view(struct i915_ggtt_view *view,
struct drm_framebuffer *fb,
info->fb_modifier = fb->modifier[0];
tile_height = intel_tile_height(fb->dev, fb->pixel_format,
- fb->modifier[0]);
+ fb->modifier[0], 0);
tile_pitch = PAGE_SIZE / tile_height;
info->width_pages = DIV_ROUND_UP(fb->pitches[0], tile_pitch);
info->height_pages = DIV_ROUND_UP(fb->height, tile_height);
@@ -3069,7 +3069,7 @@ static void skylake_update_primary_plane(struct drm_crtc
*crtc,
if (intel_rotation_90_or_270(rotation)) {
/* stride = Surface height in tiles */
tile_height = intel_tile_height(dev, fb->pixel_format,
- fb->modifier[0]);
+ fb->modifier[0], 0);
stride = DIV_ROUND_UP(fb->height, tile_height);
x_offset = stride * tile_height - y - src_h;
y_offset = x;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 1df6ebf50146..94dab9bd8ebd 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1085,7 +1085,7 @@ int intel_plane_atomic_calc_changes(struct drm_crtc_state
*crtc_state,
unsigned int
intel_tile_height(struct drm_device *dev, uint32_t pixel_format,
- uint64_t fb_format_modifier);
+ uint64_t fb_format_modifier, unsigned int plane);
static inline bool
intel_rotation_90_or_270(unsigned int rotation)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 79f7cc247ab7..4372fa0b1ec5 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -240,7 +240,7 @@ skl_update_plane(struct drm_plane *drm_plane, struct
drm_crtc *crtc,
if (intel_rotation_90_or_270(rotation)) {
/* stride: Surface height in tiles */
tile_height = intel_tile_height(dev, fb->pixel_format,
- fb->modifier[0]);
+ fb->modifier[0], 0);
stride = DIV_ROUND_UP(fb->height, tile_height);
plane_size = (src_w << 16) | src_h;
x_offset = stride * tile_height - y - (src_h + 1);
--
2.5.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915: Enable querying offset of UV plane with intel_plane_obj_offset
From: Tvrtko Ursulin
v2: Rebase.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 2 ++
drivers/gpu/drm/i915/i915_gem_gtt.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 26 +-
drivers/gpu/drm/i915/intel_drv.h | 4 +++-
drivers/gpu/drm/i915/intel_sprite.c | 2 +-
5 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 2df9d16dcefd..4023c86fabf9 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3322,6 +3322,8 @@ intel_rotate_fb_obj_pages(struct i915_ggtt_view
*ggtt_view,
if (offset_in_page(rot_info->uv_offset))
uv_start_page--;
+ rot_info->uv_start_page = uv_start_page;
+
rotate_pages(page_addr_list, uv_start_page,
rot_info->width_pages_uv,
rot_info->height_pages_uv,
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 197183d5c543..430cc283d3c9 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -145,6 +145,7 @@ struct intel_rotation_info {
uint64_t size;
unsigned int width_pages_uv, height_pages_uv;
uint64_t size_uv;
+ unsigned int uv_start_page;
};
struct i915_ggtt_view {
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 2db7cc42539c..ebfd34beb841 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2891,14 +2891,29 @@ u32 intel_fb_stride_alignment(struct drm_device *dev,
uint64_t fb_modifier,
}
unsigned long intel_plane_obj_offset(struct intel_plane *intel_plane,
-struct drm_i915_gem_object *obj)
+struct drm_i915_gem_object *obj,
+unsigned int plane)
{
const struct i915_ggtt_view *view = &i915_ggtt_view_normal;
+ struct i915_vma *vma;
+ unsigned char *offset;
if (intel_rotation_90_or_270(intel_plane->base.state->rotation))
view = &i915_ggtt_view_rotated;
- return i915_gem_obj_ggtt_offset_view(obj, view);
+ vma = i915_gem_obj_to_ggtt_view(obj, view);
+ if (WARN(!vma, "ggtt vma for display object not found! (view=%u)\n",
+ view->type))
+ return -1;
+
+ offset = (unsigned char *)vma->node.start;
+
+ if (plane == 1) {
+ offset += vma->ggtt_view.rotation_info.uv_start_page *
+ PAGE_SIZE;
+ }
+
+ return (unsigned long)offset;
}
static void skl_detach_scaler(struct intel_crtc *intel_crtc, int id)
@@ -3054,7 +3069,7 @@ static void skylake_update_primary_plane(struct drm_crtc
*crtc,
obj = intel_fb_obj(fb);
stride_div = intel_fb_stride_alignment(dev, fb->modifier[0],
fb->pixel_format);
- surf_addr = intel_plane_obj_offset(to_intel_plane(plane), obj);
+ surf_addr = intel_plane_obj_offset(to_intel_plane(plane), obj, 0);
/*
* FIXME: intel_plane_state->src, dst aren't set when transitional
@@ -11414,8 +11429,9 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
if (ret)
goto cleanup_pending;
- work->gtt_offset = intel_plane_obj_offset(to_intel_plane(primary), obj)
- + intel_crtc->dspaddr_offset;
+ work->gtt_offset = intel_plane_obj_offset(to_intel_plane(primary),
+ obj, 0);
+ work->gtt_offset += intel_crtc->dspaddr_offset;
if (mmio_flip) {
ret = intel_queue_mmio_flip(dev, crtc, fb, obj, ring,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 94dab9bd8ebd..13c64c5ec22b 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1166,7 +1166,9 @@ int skl_update_scaler_crtc(struct intel_crtc_state
*crtc_state);
int skl_max_scale(struct intel_crtc *crtc, struct intel_crtc_state
*crtc_state);
unsigned long intel_plane_obj_offset(struct intel_plane *intel_plane,
-struct drm_i915_gem_object *obj);
+struct drm_i915_gem_object *obj,
+unsigned int plane);
+
u32 skl_plane_ctl_format(uint32_t pixel_format);
u32 skl_plane_ctl_tiling(uint64_t fb_modifier);
u32 skl_plane_ctl_rotation(unsigned int rotation);
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 4372fa0b1ec5..4349fde4b72c 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -235,7 +235,7 @@ skl_update_plane(struct drm_plane *drm_plane, struct
drm_crtc
[Intel-gfx] [PATCH 0/4] NV12 rotation GTT handling prep work
From: Tvrtko Ursulin GTT page remapping logic for 90/270 rotation needs some extensions to support NV12 90/270 rotation work which is currently underway. Main thing is really to support building of the rotated page mapping from two planes instead of one, and adding appropriate calculations for the half-height UV plane geometry. Those are stored in the existing rotation info data associated with the rotated view and are also used to return the appropriate plane start address when queried from the display code. Tvrtko Ursulin (4): drm/i915: Support planar formats in tile height calculations drm/i915: Support appending to the rotated pages mapping drm/i915: Support NV12 in rotated GGTT mapping drm/i915: Enable querying offset of UV plane with intel_plane_obj_offset drivers/gpu/drm/i915/i915_gem_gtt.c | 58 drivers/gpu/drm/i915/i915_gem_gtt.h | 4 +++ drivers/gpu/drm/i915/intel_display.c | 48 ++--- drivers/gpu/drm/i915/intel_drv.h | 6 ++-- drivers/gpu/drm/i915/intel_sprite.c | 4 +-- 5 files changed, 93 insertions(+), 27 deletions(-) -- 2.5.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Revert "sna: Coldplug unknown connections as well"
On Sun, Sep 20, 2015 at 08:20:21PM +0200, Sedat Dilek wrote: > Hi, > > I am here on Ubuntu/precise AMD64 with libdrm v2.4.65 and mesa v10.6.8. > > I cannot see my LightDM login-manager, my system hangs in VT-1. > > When I revert... > > commit 650da13c7257019728cfca361dfcbe34a6c526ef > "sna: Coldplug unknown connections as well" All it is doing is a RRGetInfo() call after 2 seconds if the display manager hasn't already done so. Easiest step forward is to look at the ddx logs to see timings on who calls what and then try and get the lightdm + unity logs to see why they changed behaviour. > ...everything is as usual. Apart from the kernel issue... -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [BXT MIPI PATCH v3 06/14] drm/i915/bxt: DSI enable for BXT
On 9/18/2015 6:47 PM, Jani Nikula wrote:
On Tue, 01 Sep 2015, Uma Shankar wrote:
From: Shashank Sharma
This patch contains following changes:
1. MIPI device ready changes to support dsi_pre_enable. Changes
are specific to BXT device ready sequence. Added check for
ULPS mode(No effects on VLV).
2. Changes in dsi_enable to pick BXT port control register.
3. Changes in dsi_pre_enable to restrict DPIO programming for VLV
v2: Fixed Jani's review comments. Removed the changes in VLV/CHV
code. Fixed the macros to get proper port offsets.
v3: Rebased on latest drm-nightly branch. Fixed Jani's review comments.
Signed-off-by: Shashank Sharma
Signed-off-by: Uma Shankar
Reviewed-by: Jani Nikula
When you look at the commits before sending, you should pay more
attention to what the diffs end up looking like. In this case, the
review becomes unnecessarily hard just because you've moved code
(intel_dsi_port_enable) around for no apparent reason, and the diff
seems like intel_dsi_port_enable is rewritten into
bxt_dsi_device_ready. It should be a hint to *not* combine code movement
into the same patch.
I understand the concern. Will be careful of this in future to avoid such
issues.
---
drivers/gpu/drm/i915/i915_reg.h |7 ++
drivers/gpu/drm/i915/intel_dsi.c | 165 ++
2 files changed, 119 insertions(+), 53 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 997a999..57c5dbf 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7403,6 +7403,13 @@ enum skl_disp_power_wells {
#define _MIPIA_PORT_CTRL (VLV_DISPLAY_BASE + 0x61190)
#define _MIPIC_PORT_CTRL (VLV_DISPLAY_BASE + 0x61700)
#define MIPI_PORT_CTRL(port) _MIPI_PORT(port, _MIPIA_PORT_CTRL,
_MIPIC_PORT_CTRL)
+
+ /* BXT port control */
+#define _BXT_MIPIA_PORT_CTRL 0x6B0C0
+#define _BXT_MIPIC_PORT_CTRL 0x6B8C0
+#define BXT_MIPI_PORT_CTRL(tc) _MIPI_PORT(tc, _BXT_MIPIA_PORT_CTRL, \
+ _BXT_MIPIC_PORT_CTRL)
+
#define DPI_ENABLE (1 << 31) /* A + C */
#define MIPIA_MIPI4DPHY_DELAY_COUNT_SHIFT27
#define MIPIA_MIPI4DPHY_DELAY_COUNT_MASK (0xf << 27)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 6d0c992..5a42f87 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -286,58 +286,46 @@ static bool intel_dsi_compute_config(struct intel_encoder
*encoder,
return true;
}
-static void intel_dsi_port_enable(struct intel_encoder *encoder)
+static void bxt_dsi_device_ready(struct intel_encoder *encoder)
{
- struct drm_device *dev = encoder->base.dev;
- struct drm_i915_private *dev_priv = dev->dev_private;
- struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
+ struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
enum port port;
- u32 temp;
+ u32 val;
- if (intel_dsi->dual_link == DSI_DUAL_LINK_FRONT_BACK) {
- temp = I915_READ(VLV_CHICKEN_3);
- temp &= ~PIXEL_OVERLAP_CNT_MASK |
- intel_dsi->pixel_overlap <<
- PIXEL_OVERLAP_CNT_SHIFT;
- I915_WRITE(VLV_CHICKEN_3, temp);
- }
+ DRM_DEBUG_KMS("\n");
+ /* Exit Low power state in 4 steps*/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/skl: handle port E in cpt_digital_port_connected
Jani Nikula writes: > SKL port E handling was added in > > commit 26951caf55d73ceb1967b0bf12f6d0b96853508e > Author: Xiong Zhang > Date: Mon Aug 17 15:55:50 2015 +0800 > > drm/i915/skl: enable DDI-E hotplug > > but the whole function was moved in a another branch in > > commit b93433ccf64846820b9448f5ff5dd4348b58a8ed > Author: Jani Nikula > Date: Thu Aug 20 10:47:36 2015 +0300 > > drm/i915: move ibx_digital_port_connected to intel_dp.c > > and the addition was lost at some backmerge that I was unable to > identify. Put it back in. > > Signed-off-by: Jani Nikula Reviewed-by: Mika Kuoppala > --- > drivers/gpu/drm/i915/intel_dp.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index a6872508adec..77e4115fc847 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -4583,6 +4583,9 @@ static bool cpt_digital_port_connected(struct > drm_i915_private *dev_priv, > case PORT_D: > bit = SDE_PORTD_HOTPLUG_CPT; > break; > + case PORT_E: > + bit = SDE_PORTE_HOTPLUG_SPT; > + break; > default: > MISSING_CASE(port->port); > return false; > -- > 2.1.4 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH] drm/i915/skl: Add DC6 disabling as a power well
On Mon, Sep 21, 2015 at 11:26:06AM +0300, Jani Nikula wrote:
> On Mon, 21 Sep 2015, Patrik Jakobsson
> wrote:
> > On Wed, Sep 16, 2015 at 11:10:07PM +0300, Ville Syrjälä wrote:
> >> On Fri, Sep 11, 2015 at 01:55:22PM +0200, Patrik Jakobsson wrote:
> >> > We need to be able to control if DC6 is allowed or not. Much like
> >> > requesting power to a specific piece of the hardware we need to be able
> >> > to request that we don't enter DC6 during certain hw access.
> >> >
> >> > To solve this without introducing too much infrastructure I'm hooking
> >> > into the power well / power domain framework. DC6 prevention is modeled
> >> > much like an enabled power well. Thus I'm using the terminology on/off
> >> > for DC states instead of enable/disable.
> >> >
> >> > The problem that started this work is the need for DC6 to be disabled
> >> > when accessing DP_AUX_A during CRTC on/off. That is also fixed in this
> >> > patch.
> >> >
> >> > This is posted as an RFC since DMC and DC state handling is being
> >> > reworked and will possibly affect the outcome of this patch. The patch
> >> > has known warnings.
> >> >
> >> > Signed-off-by: Patrik Jakobsson
> >> > ---
> >> > drivers/gpu/drm/i915/intel_ddi.c| 9 +
> >> > drivers/gpu/drm/i915/intel_drv.h| 2 +
> >> > drivers/gpu/drm/i915/intel_runtime_pm.c | 69
> >> > +
> >> > 3 files changed, 64 insertions(+), 16 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> >> > b/drivers/gpu/drm/i915/intel_ddi.c
> >> > index 4823184..c2c1ad2 100644
> >> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> >> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> >> > @@ -2288,6 +2288,8 @@ static void intel_ddi_pre_enable(struct
> >> > intel_encoder *intel_encoder)
> >> > if (type == INTEL_OUTPUT_DISPLAYPORT || type ==
> >> > INTEL_OUTPUT_EDP) {
> >> > struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> >> >
> >> > +intel_display_power_get(dev_priv, POWER_DOMAIN_AUX_A);
> >> > +
> >>
> >> These I think shouldn't be necessary with my
> >> intel_display_port_aux_power_domain() stuff since intel_dp_aux_ch() will
> >> itself grab the appropriate power domain.
>
> Are you referring to stuff that is merged? Am I missing something?
It's not merged afaik. Ville's patches are at:
https://github.com/vsyrjala/linux/commits/aux_gmbus_power_domains
> >>
> >> That's of course assuming that AUX is the only reason why we need to
> >> keep DC6 disabled here.
> >>
> >
> > The upside with having get/put around bigger aux transfers is that we
> > don't get tons of enable/disable lines in the log. My vote is that we
> > keep this but also have your fine-grained get/puts.
>
> If it works without (and everything Ville is referring to above is
> merged), I'd split these to a separate patch, and we can judge the
> improvement on its own.
Yes, and there are a few other places that I'd like to group so I'll split that
out.
> BR,
> Jani.
>
>
> >
> > We also have an extra enable disable print in skl_disable_dc6() /
> > skl_enable_dc6() which I think should be removed unless various DC on/off
> > hacks
> > are required outside of the power wells framework.
> >
> >> > intel_dp_set_link_params(intel_dp, crtc->config);
> >> >
> >> > intel_ddi_init_dp_buf_reg(intel_encoder);
> >> > @@ -2297,6 +2299,8 @@ static void intel_ddi_pre_enable(struct
> >> > intel_encoder *intel_encoder)
> >> > intel_dp_complete_link_train(intel_dp);
> >> > if (port != PORT_A || INTEL_INFO(dev)->gen >= 9)
> >> > intel_dp_stop_link_train(intel_dp);
> >> > +
> >> > +intel_display_power_put(dev_priv, POWER_DOMAIN_AUX_A);
> >> > } else if (type == INTEL_OUTPUT_HDMI) {
> >> > struct intel_hdmi *intel_hdmi =
> >> > enc_to_intel_hdmi(encoder);
> >> >
> >> > @@ -2339,9 +2343,14 @@ static void intel_ddi_post_disable(struct
> >> > intel_encoder *intel_encoder)
> >> >
> >> > if (type == INTEL_OUTPUT_DISPLAYPORT || type ==
> >> > INTEL_OUTPUT_EDP) {
> >> > struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> >> > +
> >> > +intel_display_power_get(dev_priv, POWER_DOMAIN_AUX_A);
> >> > +
> >> > intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> >> > intel_edp_panel_vdd_on(intel_dp);
> >> > intel_edp_panel_off(intel_dp);
> >> > +
> >> > +intel_display_power_put(dev_priv, POWER_DOMAIN_AUX_A);
> >> > }
> >> >
> >> > if (IS_SKYLAKE(dev))
> >> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> >> > b/drivers/gpu/drm/i915/intel_drv.h
> >> > index 46484e4..82489ad 100644
> >> > --- a/drivers/gpu/drm/i915/intel_drv.h
> >> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> >> > @@ -1367,6 +1367,8 @@ void chv_phy_powergate_lanes(struct intel_encoder
> >> > *encoder,
> >
Re: [Intel-gfx] [PATCH 2/5] drm/i915: Notify user about outdated dmc firmware
Jani Nikula writes:
> On Fri, 18 Sep 2015, Mika Kuoppala wrote:
>> If csr/dmc firmware is known to be outdated, notify
>> user.
>
> What would break if we requested a firmware version that works? Or we've
> made it so that we only request the major version because there's not
> supposed to be changes like this between minor versions...?
>
I guess the question is more of a what should we do
if there is only outdated (known bad) firmware available.
Refuse to load and limb onwards, or return with error code
on driver init.
Latter would force firmware and version to be mandatory and the
version to be tightly coupled to kernel driver version.
-Mika
> BR,
> Jani.
>
>
>
>>
>> Signed-off-by: Mika Kuoppala
>> ---
>> drivers/gpu/drm/i915/intel_csr.c | 9 +
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_csr.c
>> b/drivers/gpu/drm/i915/intel_csr.c
>> index 58edc3f..73807c3 100644
>> --- a/drivers/gpu/drm/i915/intel_csr.c
>> +++ b/drivers/gpu/drm/i915/intel_csr.c
>> @@ -45,6 +45,9 @@
>>
>> MODULE_FIRMWARE(I915_CSR_SKL);
>>
>> +#define RECOMMENDED_FW_MAJOR1
>> +#define RECOMMENDED_FW_MINOR21
>> +
>> /*
>> * SKL CSR registers for DC5 and DC6
>> */
>> @@ -387,6 +390,12 @@ static void finish_csr_load(const struct firmware *fw,
>> void *context)
>>
>> DRM_DEBUG_KMS("Finished loading %s v%u.%u\n", dev_priv->csr.fw_path,
>>csr->dmc_ver_major, csr->dmc_ver_minor);
>> +
>> +if (csr->dmc_ver_major < RECOMMENDED_FW_MAJOR ||
>> +csr->dmc_ver_minor < RECOMMENDED_FW_MINOR)
>> +DRM_INFO("Outdated dmc firmware found, please upgrade to %u.%u
>> or newer\n",
>> + RECOMMENDED_FW_MAJOR, RECOMMENDED_FW_MINOR);
>> +
>> out:
>> if (fw_loaded)
>> intel_runtime_pm_put(dev_priv);
>> --
>> 2.1.4
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH] drm/i915/skl: Add DC6 disabling as a power well
On Mon, 21 Sep 2015, Patrik Jakobsson wrote:
> On Wed, Sep 16, 2015 at 11:10:07PM +0300, Ville Syrjälä wrote:
>> On Fri, Sep 11, 2015 at 01:55:22PM +0200, Patrik Jakobsson wrote:
>> > We need to be able to control if DC6 is allowed or not. Much like
>> > requesting power to a specific piece of the hardware we need to be able
>> > to request that we don't enter DC6 during certain hw access.
>> >
>> > To solve this without introducing too much infrastructure I'm hooking
>> > into the power well / power domain framework. DC6 prevention is modeled
>> > much like an enabled power well. Thus I'm using the terminology on/off
>> > for DC states instead of enable/disable.
>> >
>> > The problem that started this work is the need for DC6 to be disabled
>> > when accessing DP_AUX_A during CRTC on/off. That is also fixed in this
>> > patch.
>> >
>> > This is posted as an RFC since DMC and DC state handling is being
>> > reworked and will possibly affect the outcome of this patch. The patch
>> > has known warnings.
>> >
>> > Signed-off-by: Patrik Jakobsson
>> > ---
>> > drivers/gpu/drm/i915/intel_ddi.c| 9 +
>> > drivers/gpu/drm/i915/intel_drv.h| 2 +
>> > drivers/gpu/drm/i915/intel_runtime_pm.c | 69
>> > +
>> > 3 files changed, 64 insertions(+), 16 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
>> > b/drivers/gpu/drm/i915/intel_ddi.c
>> > index 4823184..c2c1ad2 100644
>> > --- a/drivers/gpu/drm/i915/intel_ddi.c
>> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
>> > @@ -2288,6 +2288,8 @@ static void intel_ddi_pre_enable(struct
>> > intel_encoder *intel_encoder)
>> >if (type == INTEL_OUTPUT_DISPLAYPORT || type == INTEL_OUTPUT_EDP) {
>> >struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
>> >
>> > + intel_display_power_get(dev_priv, POWER_DOMAIN_AUX_A);
>> > +
>>
>> These I think shouldn't be necessary with my
>> intel_display_port_aux_power_domain() stuff since intel_dp_aux_ch() will
>> itself grab the appropriate power domain.
Are you referring to stuff that is merged? Am I missing something?
>>
>> That's of course assuming that AUX is the only reason why we need to
>> keep DC6 disabled here.
>>
>
> The upside with having get/put around bigger aux transfers is that we
> don't get tons of enable/disable lines in the log. My vote is that we
> keep this but also have your fine-grained get/puts.
If it works without (and everything Ville is referring to above is
merged), I'd split these to a separate patch, and we can judge the
improvement on its own.
BR,
Jani.
>
> We also have an extra enable disable print in skl_disable_dc6() /
> skl_enable_dc6() which I think should be removed unless various DC on/off
> hacks
> are required outside of the power wells framework.
>
>> >intel_dp_set_link_params(intel_dp, crtc->config);
>> >
>> >intel_ddi_init_dp_buf_reg(intel_encoder);
>> > @@ -2297,6 +2299,8 @@ static void intel_ddi_pre_enable(struct
>> > intel_encoder *intel_encoder)
>> >intel_dp_complete_link_train(intel_dp);
>> >if (port != PORT_A || INTEL_INFO(dev)->gen >= 9)
>> >intel_dp_stop_link_train(intel_dp);
>> > +
>> > + intel_display_power_put(dev_priv, POWER_DOMAIN_AUX_A);
>> >} else if (type == INTEL_OUTPUT_HDMI) {
>> >struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
>> >
>> > @@ -2339,9 +2343,14 @@ static void intel_ddi_post_disable(struct
>> > intel_encoder *intel_encoder)
>> >
>> >if (type == INTEL_OUTPUT_DISPLAYPORT || type == INTEL_OUTPUT_EDP) {
>> >struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
>> > +
>> > + intel_display_power_get(dev_priv, POWER_DOMAIN_AUX_A);
>> > +
>> >intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
>> >intel_edp_panel_vdd_on(intel_dp);
>> >intel_edp_panel_off(intel_dp);
>> > +
>> > + intel_display_power_put(dev_priv, POWER_DOMAIN_AUX_A);
>> >}
>> >
>> >if (IS_SKYLAKE(dev))
>> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
>> > b/drivers/gpu/drm/i915/intel_drv.h
>> > index 46484e4..82489ad 100644
>> > --- a/drivers/gpu/drm/i915/intel_drv.h
>> > +++ b/drivers/gpu/drm/i915/intel_drv.h
>> > @@ -1367,6 +1367,8 @@ void chv_phy_powergate_lanes(struct intel_encoder
>> > *encoder,
>> > bool override, unsigned int mask);
>> > bool chv_phy_powergate_ch(struct drm_i915_private *dev_priv, enum
>> > dpio_phy phy,
>> > enum dpio_channel ch, bool override);
>> > +void skl_enable_dc6(struct drm_i915_private *dev_priv);
>> > +void skl_disable_dc6(struct drm_i915_private *dev_priv);
>> >
>> >
>> > /* intel_pm.c */
>> > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
>> > b/drivers/gpu/drm/i915/intel_runtime_pm.c
>> > index 3f682a1..e30c9a6 100644
>> > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
>> > +++ b/drivers/gpu/drm/i915/intel_runtime
Re: [Intel-gfx] [RFC PATCH] drm/i915/skl: Add DC6 disabling as a power well
On Wed, Sep 16, 2015 at 11:10:07PM +0300, Ville Syrjälä wrote:
> On Fri, Sep 11, 2015 at 01:55:22PM +0200, Patrik Jakobsson wrote:
> > We need to be able to control if DC6 is allowed or not. Much like
> > requesting power to a specific piece of the hardware we need to be able
> > to request that we don't enter DC6 during certain hw access.
> >
> > To solve this without introducing too much infrastructure I'm hooking
> > into the power well / power domain framework. DC6 prevention is modeled
> > much like an enabled power well. Thus I'm using the terminology on/off
> > for DC states instead of enable/disable.
> >
> > The problem that started this work is the need for DC6 to be disabled
> > when accessing DP_AUX_A during CRTC on/off. That is also fixed in this
> > patch.
> >
> > This is posted as an RFC since DMC and DC state handling is being
> > reworked and will possibly affect the outcome of this patch. The patch
> > has known warnings.
> >
> > Signed-off-by: Patrik Jakobsson
> > ---
> > drivers/gpu/drm/i915/intel_ddi.c| 9 +
> > drivers/gpu/drm/i915/intel_drv.h| 2 +
> > drivers/gpu/drm/i915/intel_runtime_pm.c | 69
> > +
> > 3 files changed, 64 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 4823184..c2c1ad2 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -2288,6 +2288,8 @@ static void intel_ddi_pre_enable(struct intel_encoder
> > *intel_encoder)
> > if (type == INTEL_OUTPUT_DISPLAYPORT || type == INTEL_OUTPUT_EDP) {
> > struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> >
> > + intel_display_power_get(dev_priv, POWER_DOMAIN_AUX_A);
> > +
>
> These I think shouldn't be necessary with my
> intel_display_port_aux_power_domain() stuff since intel_dp_aux_ch() will
> itself grab the appropriate power domain.
>
> That's of course assuming that AUX is the only reason why we need to
> keep DC6 disabled here.
>
The upside with having get/put around bigger aux transfers is that we don't get
tons of enable/disable lines in the log. My vote is that we keep this but also
have your fine-grained get/puts.
We also have an extra enable disable print in skl_disable_dc6() /
skl_enable_dc6() which I think should be removed unless various DC on/off hacks
are required outside of the power wells framework.
> > intel_dp_set_link_params(intel_dp, crtc->config);
> >
> > intel_ddi_init_dp_buf_reg(intel_encoder);
> > @@ -2297,6 +2299,8 @@ static void intel_ddi_pre_enable(struct intel_encoder
> > *intel_encoder)
> > intel_dp_complete_link_train(intel_dp);
> > if (port != PORT_A || INTEL_INFO(dev)->gen >= 9)
> > intel_dp_stop_link_train(intel_dp);
> > +
> > + intel_display_power_put(dev_priv, POWER_DOMAIN_AUX_A);
> > } else if (type == INTEL_OUTPUT_HDMI) {
> > struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
> >
> > @@ -2339,9 +2343,14 @@ static void intel_ddi_post_disable(struct
> > intel_encoder *intel_encoder)
> >
> > if (type == INTEL_OUTPUT_DISPLAYPORT || type == INTEL_OUTPUT_EDP) {
> > struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > +
> > + intel_display_power_get(dev_priv, POWER_DOMAIN_AUX_A);
> > +
> > intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> > intel_edp_panel_vdd_on(intel_dp);
> > intel_edp_panel_off(intel_dp);
> > +
> > + intel_display_power_put(dev_priv, POWER_DOMAIN_AUX_A);
> > }
> >
> > if (IS_SKYLAKE(dev))
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 46484e4..82489ad 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1367,6 +1367,8 @@ void chv_phy_powergate_lanes(struct intel_encoder
> > *encoder,
> > bool override, unsigned int mask);
> > bool chv_phy_powergate_ch(struct drm_i915_private *dev_priv, enum dpio_phy
> > phy,
> > enum dpio_channel ch, bool override);
> > +void skl_enable_dc6(struct drm_i915_private *dev_priv);
> > +void skl_disable_dc6(struct drm_i915_private *dev_priv);
> >
> >
> > /* intel_pm.c */
> > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > index 3f682a1..e30c9a6 100644
> > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > @@ -335,6 +335,10 @@ static void hsw_set_power_well(struct drm_i915_private
> > *dev_priv,
> > SKL_DISPLAY_POWERWELL_1_POWER_DOMAINS | \
> > BIT(POWER_DOMAIN_PLLS) |\
> > BIT(POWER_DOMAIN_INIT))
> > +#define SKL_DISPLAY_DC6_OFF_POWER_DOMAINS (\
> > + SKL_DISPLAY_POWERWELL_2_POWER_DOMAINS | \
> > +
Re: [Intel-gfx] [PATCH 09/43] drm/i915: Parametrize DDI_BUF_TRANS registers
On Fri, 18 Sep 2015, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> FIXME: Should there be a WARN(i != 9) or something, or what does the
> entry 9 comment mean?
Either the code, the comment, or both are bust. Needs to be checked.
However, this patch does not change that part for the better or for
worse, so
Reviewed-by: Jani Nikula
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_reg.h | 3 ++-
> drivers/gpu/drm/i915/intel_ddi.c | 19 +--
> 2 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 13b52f7..61414c8 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7194,7 +7194,8 @@ enum skl_disp_power_wells {
> /* DDI Buffer Translations */
> #define DDI_BUF_TRANS_A 0x64E00
> #define DDI_BUF_TRANS_B 0x64E60
> -#define DDI_BUF_TRANS(port) _PORT(port, DDI_BUF_TRANS_A, DDI_BUF_TRANS_B)
> +#define DDI_BUF_TRANS_LO(port, i) (_PORT(port, DDI_BUF_TRANS_A,
> DDI_BUF_TRANS_B) + (i) * 8)
> +#define DDI_BUF_TRANS_HI(port, i) (_PORT(port, DDI_BUF_TRANS_A,
> DDI_BUF_TRANS_B) + (i) * 8 + 4)
>
> /* Sideband Interface (SBI) is programmed indirectly, via
> * SBI_ADDR, which contains the register offset; and SBI_DATA,
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 5b600bf..9e640ea 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -414,7 +414,6 @@ static void intel_prepare_ddi_buffers(struct drm_device
> *dev, enum port port,
> bool supports_hdmi)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> - u32 reg;
> u32 iboost_bit = 0;
> int i, n_hdmi_entries, n_dp_entries, n_edp_entries, hdmi_default_entry,
> size;
> @@ -505,11 +504,11 @@ static void intel_prepare_ddi_buffers(struct drm_device
> *dev, enum port port,
> BUG();
> }
>
> - for (i = 0, reg = DDI_BUF_TRANS(port); i < size; i++) {
> - I915_WRITE(reg, ddi_translations[i].trans1 | iboost_bit);
> - reg += 4;
> - I915_WRITE(reg, ddi_translations[i].trans2);
> - reg += 4;
> + for (i = 0; i < size; i++) {
> + I915_WRITE(DDI_BUF_TRANS_LO(port, i),
> +ddi_translations[i].trans1 | iboost_bit);
> + I915_WRITE(DDI_BUF_TRANS_HI(port, i),
> +ddi_translations[i].trans2);
> }
>
> if (!supports_hdmi)
> @@ -521,10 +520,10 @@ static void intel_prepare_ddi_buffers(struct drm_device
> *dev, enum port port,
> hdmi_level = hdmi_default_entry;
>
> /* Entry 9 is for HDMI: */
> - I915_WRITE(reg, ddi_translations_hdmi[hdmi_level].trans1 | iboost_bit);
> - reg += 4;
> - I915_WRITE(reg, ddi_translations_hdmi[hdmi_level].trans2);
> - reg += 4;
> + I915_WRITE(DDI_BUF_TRANS_LO(port, i),
> +ddi_translations_hdmi[hdmi_level].trans1 | iboost_bit);
> + I915_WRITE(DDI_BUF_TRANS_HI(port, i),
> +ddi_translations_hdmi[hdmi_level].trans2);
> }
>
> /* Program DDI buffers translations for DP. By default, program ports A-D in
> DP
> --
> 2.4.6
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/43] drm/i915: Parametrize TV luma/chroma filter registers
On Fri, 18 Sep 2015, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_reg.h | 12
> drivers/gpu/drm/i915/intel_tv.c | 8
> 2 files changed, 8 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index b95f7f1..13b52f7 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4079,14 +4079,10 @@ enum skl_disp_power_wells {
> # define TV_CC_DATA_1_MASK 0x007f
> # define TV_CC_DATA_1_SHIFT 0
>
> -#define TV_H_LUMA_0 0x68100
> -#define TV_H_LUMA_59 0x681ec
> -#define TV_H_CHROMA_00x68200
> -#define TV_H_CHROMA_59 0x682ec
> -#define TV_V_LUMA_0 0x68300
> -#define TV_V_LUMA_42 0x683a8
> -#define TV_V_CHROMA_00x68400
> -#define TV_V_CHROMA_42 0x684a8
> +#define TV_H_LUMA(i) (0x68100 + (i) * 4) /* 60 registers */
> +#define TV_H_CHROMA(i) (0x68200 + (i) * 4) /* 60 registers */
> +#define TV_V_LUMA(i) (0x68300 + (i) * 4) /* 43 registers */
> +#define TV_V_CHROMA(i) (0x68400 + (i) * 4) /* 43 registers */
>
> /* Display Port */
> #define DP_A 0x64000 /* eDP */
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
> index 29983cba..6bea789 100644
> --- a/drivers/gpu/drm/i915/intel_tv.c
> +++ b/drivers/gpu/drm/i915/intel_tv.c
> @@ -1138,13 +1138,13 @@ static void intel_tv_pre_enable(struct intel_encoder
> *encoder)
>
> j = 0;
> for (i = 0; i < 60; i++)
> - I915_WRITE(TV_H_LUMA_0 + (i<<2), tv_mode->filter_table[j++]);
> + I915_WRITE(TV_H_LUMA(i), tv_mode->filter_table[j++]);
> for (i = 0; i < 60; i++)
> - I915_WRITE(TV_H_CHROMA_0 + (i<<2), tv_mode->filter_table[j++]);
> + I915_WRITE(TV_H_CHROMA(i), tv_mode->filter_table[j++]);
> for (i = 0; i < 43; i++)
> - I915_WRITE(TV_V_LUMA_0 + (i<<2), tv_mode->filter_table[j++]);
> + I915_WRITE(TV_V_LUMA(i), tv_mode->filter_table[j++]);
> for (i = 0; i < 43; i++)
> - I915_WRITE(TV_V_CHROMA_0 + (i<<2), tv_mode->filter_table[j++]);
> + I915_WRITE(TV_V_CHROMA(i), tv_mode->filter_table[j++]);
> I915_WRITE(TV_DAC, I915_READ(TV_DAC) & TV_DAC_SAVE);
> I915_WRITE(TV_CTL, tv_ctl);
> }
> --
> 2.4.6
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/43] drm/i915: Replace raw numbers with the approproate register name in ILK turbo code
On Fri, 18 Sep 2015, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Signed-off-by: Ville Syrjälä Reviewed-by: Jani Nikula > --- > drivers/gpu/drm/i915/intel_pm.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > index 0320675..dc765eb 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -4305,10 +4305,10 @@ static void ironlake_enable_drps(struct drm_device > *dev) > > ironlake_set_drps(dev, fstart); > > - dev_priv->ips.last_count1 = I915_READ(0x112e4) + I915_READ(0x112e8) + > - I915_READ(0x112e0); > + dev_priv->ips.last_count1 = I915_READ(DMIEC) + > + I915_READ(DDREC) + I915_READ(CSIEC); > dev_priv->ips.last_time1 = jiffies_to_msecs(jiffies); > - dev_priv->ips.last_count2 = I915_READ(0x112f4); > + dev_priv->ips.last_count2 = I915_READ(GFXEC); > dev_priv->ips.last_time2 = ktime_get_raw_ns(); > > spin_unlock_irq(&mchdev_lock); > -- > 2.4.6 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/43] drm/i915: Parametrize ILK turbo registers
On Fri, 18 Sep 2015, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_reg.h | 10 +-
> drivers/gpu/drm/i915/intel_pm.c | 14 +++---
> 2 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index fcd1e81..b95f7f1 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -2576,7 +2576,7 @@ enum skl_disp_power_wells {
> #define TSFS_INTR_MASK 0x00ff
>
> #define CRSTANDVID 0x11100
> -#define PXVFREQ_BASE 0x0 /* P[0-15]VIDFREQ (0x1114c) (Ironlake)
> */
> +#define PXVFREQ(i) (0x0 + (i) * 4) /* P[0-15]VIDFREQ (0x1114c)
> (Ironlake) */
> #define PXVFREQ_PX_MASK0x7f00
> #define PXVFREQ_PX_SHIFT 24
> #define VIDFREQ_BASE 0x0
> @@ -2760,8 +2760,8 @@ enum skl_disp_power_wells {
> #define CSIEW0 0x11250
> #define CSIEW1 0x11254
> #define CSIEW2 0x11258
> -#define PEW 0x1125c
> -#define DEW 0x11270
> +#define PEW(i) (0x1125c + (i) * 4) /* 5 registers */
> +#define DEW(i) (0x11270 + (i) * 4) /* 3 registers */
> #define MCHAFE 0x112c0
> #define CSIEC0x112e0
> #define DMIEC0x112e4
> @@ -2785,8 +2785,8 @@ enum skl_disp_power_wells {
> #define EG5 0x11624
> #define EG6 0x11628
> #define EG7 0x1162c
> -#define PXW 0x11664
> -#define PXWL 0x11680
> +#define PXW(i) (0x11664 + (i) * 4) /* 4 registers */
> +#define PXWL(i) (0x11680 + (i) * 4) /* 8 registers */
> #define LCFUSE02 0x116c0
> #define LCFUSE_HIV_MASK0x00ff
> #define CSIPLL0 0x12c10
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 62de97e..0320675 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4274,7 +4274,7 @@ static void ironlake_enable_drps(struct drm_device *dev)
> fstart = (rgvmodectl & MEMMODE_FSTART_MASK) >>
> MEMMODE_FSTART_SHIFT;
>
> - vstart = (I915_READ(PXVFREQ_BASE + (fstart * 4)) & PXVFREQ_PX_MASK) >>
> + vstart = (I915_READ(PXVFREQ(fstart)) & PXVFREQ_PX_MASK) >>
> PXVFREQ_PX_SHIFT;
>
> dev_priv->ips.fmax = fmax; /* IPS callback will increase this */
> @@ -5877,7 +5877,7 @@ static unsigned long __i915_gfx_val(struct
> drm_i915_private *dev_priv)
>
> assert_spin_locked(&mchdev_lock);
>
> - pxvid = I915_READ(PXVFREQ_BASE + (dev_priv->rps.cur_freq * 4));
> + pxvid = I915_READ(PXVFREQ(dev_priv->rps.cur_freq));
> pxvid = (pxvid >> 24) & 0x7f;
> ext_v = pvid_to_extvid(dev_priv, pxvid);
>
> @@ -6120,13 +6120,13 @@ static void intel_init_emon(struct drm_device *dev)
> I915_WRITE(CSIEW2, 0x0404);
>
> for (i = 0; i < 5; i++)
> - I915_WRITE(PEW + (i * 4), 0);
> + I915_WRITE(PEW(i), 0);
> for (i = 0; i < 3; i++)
> - I915_WRITE(DEW + (i * 4), 0);
> + I915_WRITE(DEW(i), 0);
>
> /* Program P-state weights to account for frequency power adjustment */
> for (i = 0; i < 16; i++) {
> - u32 pxvidfreq = I915_READ(PXVFREQ_BASE + (i * 4));
> + u32 pxvidfreq = I915_READ(PXVFREQ(i));
> unsigned long freq = intel_pxfreq(pxvidfreq);
> unsigned long vid = (pxvidfreq & PXVFREQ_PX_MASK) >>
> PXVFREQ_PX_SHIFT;
> @@ -6147,7 +6147,7 @@ static void intel_init_emon(struct drm_device *dev)
> for (i = 0; i < 4; i++) {
> u32 val = (pxw[i*4] << 24) | (pxw[(i*4)+1] << 16) |
> (pxw[(i*4)+2] << 8) | (pxw[(i*4)+3]);
> - I915_WRITE(PXW + (i * 4), val);
> + I915_WRITE(PXW(i), val);
> }
>
> /* Adjust magic regs to magic values (more experimental results) */
> @@ -6163,7 +6163,7 @@ static void intel_init_emon(struct drm_device *dev)
> I915_WRITE(EG7, 0);
>
> for (i = 0; i < 8; i++)
> - I915_WRITE(PXWL + (i * 4), 0);
> + I915_WRITE(PXWL(i), 0);
>
> /* Enable PMON + select events */
> I915_WRITE(ECR, 0x8019);
> --
> 2.4.6
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/43] drm/i915: Parametrize FBC_TAG registers
On Fri, 18 Sep 2015, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_reg.h | 2 +-
> drivers/gpu/drm/i915/intel_fbc.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index b1cf17a..fcd1e81 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -2013,7 +2013,7 @@ enum skl_disp_power_wells {
> #define FBC_CTL_CPU_FENCE (1<<1)
> #define FBC_CTL_PLANE(plane) ((plane)<<0)
> #define FBC_FENCE_OFF0x03218 /* BSpec typo has 321Bh */
> -#define FBC_TAG 0x03300
> +#define FBC_TAG(i) (0x03300 + (i) * 4)
>
> #define FBC_STATUS2 0x43214
> #define FBC_COMPRESSION_MASK0x7ff
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> b/drivers/gpu/drm/i915/intel_fbc.c
> index 1f97fb5..f8c527f 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -88,7 +88,7 @@ static void i8xx_fbc_enable(struct intel_crtc *crtc)
>
> /* Clear old tags */
> for (i = 0; i < (FBC_LL_SIZE / 32) + 1; i++)
> - I915_WRITE(FBC_TAG + (i * 4), 0);
> + I915_WRITE(FBC_TAG(i), 0);
>
> if (IS_GEN4(dev_priv)) {
> u32 fbc_ctl2;
> --
> 2.4.6
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/43] drm/i915: Parametrize fence registers
On Fri, 18 Sep 2015, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_gem_fence.c | 42
> +--
> drivers/gpu/drm/i915/i915_gpu_error.c | 21 --
> drivers/gpu/drm/i915/i915_reg.h | 12 +-
> 3 files changed, 37 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_fence.c
> b/drivers/gpu/drm/i915/i915_gem_fence.c
> index 6077dff..ff94560 100644
> --- a/drivers/gpu/drm/i915/i915_gem_fence.c
> +++ b/drivers/gpu/drm/i915/i915_gem_fence.c
> @@ -59,19 +59,19 @@ static void i965_write_fence_reg(struct drm_device *dev,
> int reg,
>struct drm_i915_gem_object *obj)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> - int fence_reg;
> + int fence_reg_lo, fence_reg_hi;
> int fence_pitch_shift;
>
> if (INTEL_INFO(dev)->gen >= 6) {
> - fence_reg = FENCE_REG_SANDYBRIDGE_0;
> - fence_pitch_shift = SANDYBRIDGE_FENCE_PITCH_SHIFT;
> + fence_reg_lo = FENCE_REG_GEN6_LO(reg);
> + fence_reg_hi = FENCE_REG_GEN6_HI(reg);
> + fence_pitch_shift = GEN6_FENCE_PITCH_SHIFT;
> } else {
> - fence_reg = FENCE_REG_965_0;
> + fence_reg_lo = FENCE_REG_965_LO(reg);
> + fence_reg_hi = FENCE_REG_965_HI(reg);
> fence_pitch_shift = I965_FENCE_PITCH_SHIFT;
> }
>
> - fence_reg += reg * 8;
> -
> /* To w/a incoherency with non-atomic 64-bit register updates,
>* we split the 64-bit update into two 32-bit writes. In order
>* for a partial fence not to be evaluated between writes, we
> @@ -81,8 +81,8 @@ static void i965_write_fence_reg(struct drm_device *dev,
> int reg,
>* For extra levels of paranoia, we make sure each step lands
>* before applying the next step.
>*/
> - I915_WRITE(fence_reg, 0);
> - POSTING_READ(fence_reg);
> + I915_WRITE(fence_reg_lo, 0);
> + POSTING_READ(fence_reg_lo);
>
> if (obj) {
> u32 size = i915_gem_obj_ggtt_size(obj);
> @@ -103,14 +103,14 @@ static void i965_write_fence_reg(struct drm_device
> *dev, int reg,
> val |= 1 << I965_FENCE_TILING_Y_SHIFT;
> val |= I965_FENCE_REG_VALID;
>
> - I915_WRITE(fence_reg + 4, val >> 32);
> - POSTING_READ(fence_reg + 4);
> + I915_WRITE(fence_reg_hi, val >> 32);
> + POSTING_READ(fence_reg_hi);
>
> - I915_WRITE(fence_reg + 0, val);
> - POSTING_READ(fence_reg);
> + I915_WRITE(fence_reg_lo, val);
> + POSTING_READ(fence_reg_lo);
> } else {
> - I915_WRITE(fence_reg + 4, 0);
> - POSTING_READ(fence_reg + 4);
> + I915_WRITE(fence_reg_hi, 0);
> + POSTING_READ(fence_reg_hi);
> }
> }
>
> @@ -118,7 +118,7 @@ static void i915_write_fence_reg(struct drm_device *dev,
> int reg,
>struct drm_i915_gem_object *obj)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> - u32 val;
> + u32 fence_reg, val;
>
> if (obj) {
> u32 size = i915_gem_obj_ggtt_size(obj);
> @@ -150,12 +150,12 @@ static void i915_write_fence_reg(struct drm_device
> *dev, int reg,
> val = 0;
>
> if (reg < 8)
> - reg = FENCE_REG_830_0 + reg * 4;
> + fence_reg = FENCE_REG_830(reg);
> else
> - reg = FENCE_REG_945_8 + (reg - 8) * 4;
> + fence_reg = FENCE_REG_945_8(reg);
>
> - I915_WRITE(reg, val);
> - POSTING_READ(reg);
> + I915_WRITE(fence_reg, val);
> + POSTING_READ(fence_reg);
> }
>
> static void i830_write_fence_reg(struct drm_device *dev, int reg,
> @@ -186,8 +186,8 @@ static void i830_write_fence_reg(struct drm_device *dev,
> int reg,
> } else
> val = 0;
>
> - I915_WRITE(FENCE_REG_830_0 + reg * 4, val);
> - POSTING_READ(FENCE_REG_830_0 + reg * 4);
> + I915_WRITE(FENCE_REG_830(reg), val);
> + POSTING_READ(FENCE_REG_830(reg));
> }
>
> inline static bool i915_gem_object_needs_mb(struct drm_i915_gem_object *obj)
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
> b/drivers/gpu/drm/i915/i915_gpu_error.c
> index 3379f9c..e873eb4 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> @@ -787,19 +787,16 @@ static void i915_gem_record_fences(struct drm_device
> *dev,
>
> if (IS_GEN3(dev) || IS_GEN2(dev)) {
> for (i = 0; i < 8; i++)
> - error->fence[i] = I915_READ(FENCE_REG_830_0 + (i * 4));
> - if (IS_I945G(dev) || IS_I945GM(dev) || IS_G33(dev))
> - for (i = 0; i < 8; i++)
> - error->fence[i+8] = I915_READ(FENCE_REG_945_8 +
> -
Re: [Intel-gfx] [PATCH 02/43] drm/i915: Parametrize LRC registers
On Fri, 18 Sep 2015, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 8
> drivers/gpu/drm/i915/intel_lrc.c| 8 +++-
> drivers/gpu/drm/i915/intel_lrc.h| 6 --
> 3 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 72ae347..5615d3d 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2069,8 +2069,8 @@ static int i915_execlists(struct seq_file *m, void
> *data)
>
> seq_printf(m, "%s\n", ring->name);
>
> - status = I915_READ(RING_EXECLIST_STATUS(ring));
> - ctx_id = I915_READ(RING_EXECLIST_STATUS(ring) + 4);
> + status = I915_READ(RING_EXECLIST_STATUS_LO(ring));
> + ctx_id = I915_READ(RING_EXECLIST_STATUS_HI(ring));
> seq_printf(m, "\tExeclist status: 0x%08X, context: %u\n",
> status, ctx_id);
>
> @@ -2085,8 +2085,8 @@ static int i915_execlists(struct seq_file *m, void
> *data)
> read_pointer, write_pointer);
>
> for (i = 0; i < 6; i++) {
> - status = I915_READ(RING_CONTEXT_STATUS_BUF(ring) + 8*i);
> - ctx_id = I915_READ(RING_CONTEXT_STATUS_BUF(ring) + 8*i
> + 4);
> + status = I915_READ(RING_CONTEXT_STATUS_BUF_LO(ring, i));
> + ctx_id = I915_READ(RING_CONTEXT_STATUS_BUF_HI(ring, i));
>
> seq_printf(m, "\tStatus buffer %d: 0x%08X, context:
> %u\n",
> i, status, ctx_id);
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index fe06accb0..ca9f161 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -349,7 +349,7 @@ static void execlists_elsp_write(struct
> drm_i915_gem_request *rq0,
> I915_WRITE_FW(RING_ELSP(ring), lower_32_bits(desc[0]));
>
> /* ELSP is a wo register, use another nearby reg for posting */
> - POSTING_READ_FW(RING_EXECLIST_STATUS(ring));
> + POSTING_READ_FW(RING_EXECLIST_STATUS_LO(ring));
> intel_uncore_forcewake_put__locked(dev_priv, FORCEWAKE_ALL);
> spin_unlock(&dev_priv->uncore.lock);
> }
> @@ -519,10 +519,8 @@ void intel_lrc_irq_handler(struct intel_engine_cs *ring)
>
> while (read_pointer < write_pointer) {
> read_pointer++;
> - status = I915_READ(RING_CONTEXT_STATUS_BUF(ring) +
> - (read_pointer % 6) * 8);
> - status_id = I915_READ(RING_CONTEXT_STATUS_BUF(ring) +
> - (read_pointer % 6) * 8 + 4);
> + status = I915_READ(RING_CONTEXT_STATUS_BUF_LO(ring,
> read_pointer % 6));
> + status_id = I915_READ(RING_CONTEXT_STATUS_BUF_HI(ring,
> read_pointer % 6));
>
> if (status & GEN8_CTX_STATUS_IDLE_ACTIVE)
> continue;
> diff --git a/drivers/gpu/drm/i915/intel_lrc.h
> b/drivers/gpu/drm/i915/intel_lrc.h
> index 69d99f0..8a08a27 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.h
> +++ b/drivers/gpu/drm/i915/intel_lrc.h
> @@ -28,12 +28,14 @@
>
> /* Execlists regs */
> #define RING_ELSP(ring) ((ring)->mmio_base+0x230)
> -#define RING_EXECLIST_STATUS(ring) ((ring)->mmio_base+0x234)
> +#define RING_EXECLIST_STATUS_LO(ring)((ring)->mmio_base+0x234)
> +#define RING_EXECLIST_STATUS_HI(ring)((ring)->mmio_base+0x234 + 4)
> #define RING_CONTEXT_CONTROL(ring) ((ring)->mmio_base+0x244)
> #defineCTX_CTRL_INHIBIT_SYN_CTX_SWITCH (1 << 3)
> #defineCTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT (1 << 0)
> #define CTX_CTRL_RS_CTX_ENABLE(1 << 1)
> -#define RING_CONTEXT_STATUS_BUF(ring)((ring)->mmio_base+0x370)
> +#define RING_CONTEXT_STATUS_BUF_LO(ring, i) ((ring)->mmio_base+0x370 + (i)
> * 8)
> +#define RING_CONTEXT_STATUS_BUF_HI(ring, i) ((ring)->mmio_base+0x370 + (i)
> * 8 + 4)
> #define RING_CONTEXT_STATUS_PTR(ring)((ring)->mmio_base+0x3a0)
>
> /* Logical Rings */
> --
> 2.4.6
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/43] drm/i915: Parametrize GEN7_GT_SCRATCH and GEN7_LRA_LIMITS
On Fri, 18 Sep 2015, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_drv.c | 8
> drivers/gpu/drm/i915/i915_reg.h | 4 ++--
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index e2bf9e2..e6d7a69 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1120,7 +1120,7 @@ static void vlv_save_gunit_s0ix_state(struct
> drm_i915_private *dev_priv)
> s->gfx_pend_tlb1= I915_READ(GEN7_GFX_PEND_TLB1);
>
> for (i = 0; i < ARRAY_SIZE(s->lra_limits); i++)
> - s->lra_limits[i] = I915_READ(GEN7_LRA_LIMITS_BASE + i * 4);
> + s->lra_limits[i] = I915_READ(GEN7_LRA_LIMITS(i));
>
> s->media_max_req_count = I915_READ(GEN7_MEDIA_MAX_REQ_COUNT);
> s->gfx_max_req_count= I915_READ(GEN7_GFX_MAX_REQ_COUNT);
> @@ -1164,7 +1164,7 @@ static void vlv_save_gunit_s0ix_state(struct
> drm_i915_private *dev_priv)
> s->pm_ier = I915_READ(GEN6_PMIER);
>
> for (i = 0; i < ARRAY_SIZE(s->gt_scratch); i++)
> - s->gt_scratch[i] = I915_READ(GEN7_GT_SCRATCH_BASE + i * 4);
> + s->gt_scratch[i] = I915_READ(GEN7_GT_SCRATCH(i));
>
> /* GT SA CZ domain, 0x10-0x138124 */
> s->tilectl = I915_READ(TILECTL);
> @@ -1202,7 +1202,7 @@ static void vlv_restore_gunit_s0ix_state(struct
> drm_i915_private *dev_priv)
> I915_WRITE(GEN7_GFX_PEND_TLB1, s->gfx_pend_tlb1);
>
> for (i = 0; i < ARRAY_SIZE(s->lra_limits); i++)
> - I915_WRITE(GEN7_LRA_LIMITS_BASE + i * 4, s->lra_limits[i]);
> + I915_WRITE(GEN7_LRA_LIMITS(i), s->lra_limits[i]);
>
> I915_WRITE(GEN7_MEDIA_MAX_REQ_COUNT, s->media_max_req_count);
> I915_WRITE(GEN7_GFX_MAX_REQ_COUNT, s->gfx_max_req_count);
> @@ -1246,7 +1246,7 @@ static void vlv_restore_gunit_s0ix_state(struct
> drm_i915_private *dev_priv)
> I915_WRITE(GEN6_PMIER, s->pm_ier);
>
> for (i = 0; i < ARRAY_SIZE(s->gt_scratch); i++)
> - I915_WRITE(GEN7_GT_SCRATCH_BASE + i * 4, s->gt_scratch[i]);
> + I915_WRITE(GEN7_GT_SCRATCH(i), s->gt_scratch[i]);
>
> /* GT SA CZ domain, 0x10-0x138124 */
> I915_WRITE(TILECTL, s->tilectl);
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 67bf205..44cedbf 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1527,7 +1527,7 @@ enum skl_disp_power_wells {
> #define GEN7_GFX_PEND_TLB0 0x4034
> #define GEN7_GFX_PEND_TLB1 0x4038
> /* L3, CVS, ZTLB, RCC, CASC LRA min, max values */
> -#define GEN7_LRA_LIMITS_BASE 0x403C
> +#define GEN7_LRA_LIMITS(i) (0x403C + (i) * 4)
> #define GEN7_LRA_LIMITS_REG_NUM 13
> #define GEN7_MEDIA_MAX_REQ_COUNT 0x4070
> #define GEN7_GFX_MAX_REQ_COUNT 0x4074
> @@ -6808,7 +6808,7 @@ enum skl_disp_power_wells {
>GEN6_PM_RP_DOWN_THRESHOLD | \
>GEN6_PM_RP_DOWN_TIMEOUT)
>
> -#define GEN7_GT_SCRATCH_BASE 0x4F100
> +#define GEN7_GT_SCRATCH(i) (0x4F100 + (i) * 4)
> #define GEN7_GT_SCRATCH_REG_NUM 8
>
> #define VLV_GTLC_SURVIVABILITY_REG 0x130098
> --
> 2.4.6
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/43] drm/i915: Don't pass sdvo_reg to intel_sdvo_select_{ddc, i2c}_bus()
On Fri, 18 Sep 2015, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> intel_sdvo_select_ddc_bus() and intel_sdvo_select_i2c_bus() have no used
> for the passed in 'reg', so just drop it.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_sdvo.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
> b/drivers/gpu/drm/i915/intel_sdvo.c
> index ca3dd7c..05521b5 100644
> --- a/drivers/gpu/drm/i915/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> @@ -,7 +,7 @@ intel_sdvo_guess_ddc_bus(struct intel_sdvo *sdvo)
> */
> static void
> intel_sdvo_select_ddc_bus(struct drm_i915_private *dev_priv,
> - struct intel_sdvo *sdvo, u32 reg)
> + struct intel_sdvo *sdvo)
> {
> struct sdvo_device_mapping *mapping;
>
> @@ -2239,7 +2239,7 @@ intel_sdvo_select_ddc_bus(struct drm_i915_private
> *dev_priv,
>
> static void
> intel_sdvo_select_i2c_bus(struct drm_i915_private *dev_priv,
> - struct intel_sdvo *sdvo, u32 reg)
> + struct intel_sdvo *sdvo)
> {
> struct sdvo_device_mapping *mapping;
> u8 pin;
> @@ -2925,7 +2925,7 @@ bool intel_sdvo_init(struct drm_device *dev, uint32_t
> sdvo_reg, bool is_sdvob)
> intel_sdvo->sdvo_reg = sdvo_reg;
> intel_sdvo->is_sdvob = is_sdvob;
> intel_sdvo->slave_addr = intel_sdvo_get_slave_addr(dev, intel_sdvo) >>
> 1;
> - intel_sdvo_select_i2c_bus(dev_priv, intel_sdvo, sdvo_reg);
> + intel_sdvo_select_i2c_bus(dev_priv, intel_sdvo);
> if (!intel_sdvo_init_ddc_proxy(intel_sdvo, dev))
> goto err_i2c_bus;
>
> @@ -2987,7 +2987,7 @@ bool intel_sdvo_init(struct drm_device *dev, uint32_t
> sdvo_reg, bool is_sdvob)
>*/
> intel_sdvo->base.cloneable = 0;
>
> - intel_sdvo_select_ddc_bus(dev_priv, intel_sdvo, sdvo_reg);
> + intel_sdvo_select_ddc_bus(dev_priv, intel_sdvo);
>
> /* Set the input timing to the screen. Assume always input 0. */
> if (!intel_sdvo_set_target_input(intel_sdvo))
> --
> 2.4.6
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] drm/i915: Notify user about outdated dmc firmware
On Fri, 18 Sep 2015, Mika Kuoppala wrote:
> If csr/dmc firmware is known to be outdated, notify
> user.
What would break if we requested a firmware version that works? Or we've
made it so that we only request the major version because there's not
supposed to be changes like this between minor versions...?
BR,
Jani.
>
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_csr.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_csr.c
> b/drivers/gpu/drm/i915/intel_csr.c
> index 58edc3f..73807c3 100644
> --- a/drivers/gpu/drm/i915/intel_csr.c
> +++ b/drivers/gpu/drm/i915/intel_csr.c
> @@ -45,6 +45,9 @@
>
> MODULE_FIRMWARE(I915_CSR_SKL);
>
> +#define RECOMMENDED_FW_MAJOR 1
> +#define RECOMMENDED_FW_MINOR 21
> +
> /*
> * SKL CSR registers for DC5 and DC6
> */
> @@ -387,6 +390,12 @@ static void finish_csr_load(const struct firmware *fw,
> void *context)
>
> DRM_DEBUG_KMS("Finished loading %s v%u.%u\n", dev_priv->csr.fw_path,
> csr->dmc_ver_major, csr->dmc_ver_minor);
> +
> + if (csr->dmc_ver_major < RECOMMENDED_FW_MAJOR ||
> + csr->dmc_ver_minor < RECOMMENDED_FW_MINOR)
> + DRM_INFO("Outdated dmc firmware found, please upgrade to %u.%u
> or newer\n",
> + RECOMMENDED_FW_MAJOR, RECOMMENDED_FW_MINOR);
> +
> out:
> if (fw_loaded)
> intel_runtime_pm_put(dev_priv);
> --
> 2.1.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
