[RESEND PATCH v2] drm/gem: Mark pinned pages as unevictable
The gem drivers use shmemfs to allocate backing storage for gem objects.
On Samsung Chromebook Plus, the drm/rockchip driver may call
rockchip_gem_get_pages -> drm_gem_get_pages -> shmem_read_mapping_page
to pin a lot of pages, breaking the page reclaim mechanism and causing
oom-killer invocation.
E.g. when the size of a zone is 3.9 GiB, the inactive_ratio is 5. If
active_anon / inactive_anon < 5 and all pages in the inactive_anon lru
are pinned, page reclaim would keep scanning inactive_anon lru without
reclaiming memory. It breaks page reclaim when the rockchip driver only
pins about 1/6 of the anon lru pages.
Mark these pinned pages as unevictable to avoid the premature oom-killer
invocation. See also similar patch on i915 driver [1].
[1]:
https://patchwork.freedesktop.org/patch/msgid/20181106132324.17390-1-ch...@chris-wilson.co.uk
Signed-off-by: Kuo-Hsin Yang
Cc: Daniel Vetter
Cc: Chris Wilson
Reviewed-by: Chris Wilson
---
Changes for v2:
Updated the commit message.
drivers/gpu/drm/drm_gem.c | 36 +---
1 file changed, 33 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 8b55ece97967f..2896ff60552f5 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -526,6 +527,17 @@ int drm_gem_create_mmap_offset(struct drm_gem_object *obj)
}
EXPORT_SYMBOL(drm_gem_create_mmap_offset);
+/*
+ * Move pages to appropriate lru and release the pagevec, decrementing the
+ * ref count of those pages.
+ */
+static void drm_gem_check_release_pagevec(struct pagevec *pvec)
+{
+ check_move_unevictable_pages(pvec);
+ __pagevec_release(pvec);
+ cond_resched();
+}
+
/**
* drm_gem_get_pages - helper to allocate backing pages for a GEM object
* from shmem
@@ -551,6 +563,7 @@ struct page **drm_gem_get_pages(struct drm_gem_object *obj)
{
struct address_space *mapping;
struct page *p, **pages;
+ struct pagevec pvec;
int i, npages;
/* This is the shared memory object that backs the GEM resource */
@@ -568,6 +581,8 @@ struct page **drm_gem_get_pages(struct drm_gem_object *obj)
if (pages == NULL)
return ERR_PTR(-ENOMEM);
+ mapping_set_unevictable(mapping);
+
for (i = 0; i < npages; i++) {
p = shmem_read_mapping_page(mapping, i);
if (IS_ERR(p))
@@ -586,8 +601,14 @@ struct page **drm_gem_get_pages(struct drm_gem_object *obj)
return pages;
fail:
- while (i--)
- put_page(pages[i]);
+ mapping_clear_unevictable(mapping);
+ pagevec_init();
+ while (i--) {
+ if (!pagevec_add(, pages[i]))
+ drm_gem_check_release_pagevec();
+ }
+ if (pagevec_count())
+ drm_gem_check_release_pagevec();
kvfree(pages);
return ERR_CAST(p);
@@ -605,6 +626,11 @@ void drm_gem_put_pages(struct drm_gem_object *obj, struct
page **pages,
bool dirty, bool accessed)
{
int i, npages;
+ struct address_space *mapping;
+ struct pagevec pvec;
+
+ mapping = file_inode(obj->filp)->i_mapping;
+ mapping_clear_unevictable(mapping);
/* We already BUG_ON() for non-page-aligned sizes in
* drm_gem_object_init(), so we should never hit this unless
@@ -614,6 +640,7 @@ void drm_gem_put_pages(struct drm_gem_object *obj, struct
page **pages,
npages = obj->size >> PAGE_SHIFT;
+ pagevec_init();
for (i = 0; i < npages; i++) {
if (dirty)
set_page_dirty(pages[i]);
@@ -622,8 +649,11 @@ void drm_gem_put_pages(struct drm_gem_object *obj, struct
page **pages,
mark_page_accessed(pages[i]);
/* Undo the reference we took when populating the table */
- put_page(pages[i]);
+ if (!pagevec_add(, pages[i]))
+ drm_gem_check_release_pagevec();
}
+ if (pagevec_count())
+ drm_gem_check_release_pagevec();
kvfree(pages);
}
--
2.20.1.97.g81188d93c3-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] tilcdc changes for 4.22
Hi Dave, Please pull this drm/tilcdc patch for Linux v4.22. Best regards and thanks, Jyri The following changes since commit 8fe28cb58bcb235034b64cbbb7550a8a43fd88be: Linux 4.20 (2018-12-23 15:55:59 -0800) are available in the Git repository at: https://github.com/jsarha/linux tags/tilcdc-4.22 for you to fetch changes up to 432973fd3a20102840d5f7e61af9f1a03c217a4c: drm/tilcdc: Register cpufreq notifier after we have initialized crtc (2019-01-04 18:01:58 +0200) tilcdc pull request for Linux v4.22 Jyri Sarha (1): drm/tilcdc: Register cpufreq notifier after we have initialized crtc drivers/gpu/drm/tilcdc/tilcdc_drv.c | 34 +- 1 file changed, 17 insertions(+), 17 deletions(-) -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [v2 14/14] drivers/video: Constantify function argument for HDMI infoframe log
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Sharma, Shashank
>Sent: Friday, December 21, 2018 2:28 PM
>To: Shankar, Uma ; intel-...@lists.freedesktop.org;
>dri-devel@lists.freedesktop.org
>Cc: Syrjala, Ville ; Lankhorst, Maarten
>
>Subject: Re: [v2 14/14] drivers/video: Constantify function argument for HDMI
>infoframe log
>
>Regards
>
>Shashank
>
>
>On 12/12/2018 2:08 AM, Uma Shankar wrote:
>> From: Ville Syrjälä
>>
>> Function argument for hdmi_drm_infoframe_log is made constant.
>>
>> Signed-off-by: Ville Syrjälä
>> Signed-off-by: Uma Shankar
>> ---
>> drivers/video/hdmi.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c index
>> 0937c8c..7ab8086 100644
>> --- a/drivers/video/hdmi.c
>> +++ b/drivers/video/hdmi.c
>> @@ -1383,8 +1383,8 @@ static void hdmi_audio_infoframe_log(const char
>*level,
>>* @frame: HDMI DRM infoframe
>>*/
>> static void hdmi_drm_infoframe_log(const char *level,
>> - struct device *dev,
>> - struct hdmi_drm_infoframe *frame)
>> + struct device *dev,
>> + const struct hdmi_drm_infoframe *frame)
>Why not merge this patch with 8/14 drm: Enable HDR infoframe support ?
Will update this.
Thanks Shashank for the review and valuable comments.
Regards,
Uma Shankar
>- Shashank
>> {
>> int i;
>>
>
>___
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [v2 04/14] drm: Parse Colorimetry data block from EDID
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Sharma, Shashank
>Sent: Tuesday, January 8, 2019 12:27 PM
>To: Shankar, Uma ; intel-...@lists.freedesktop.org;
>dri-devel@lists.freedesktop.org
>Cc: Syrjala, Ville ; Lankhorst, Maarten
>
>Subject: Re: [v2 04/14] drm: Parse Colorimetry data block from EDID
>
>
>
>On 1/8/2019 12:10 PM, Shankar, Uma wrote:
>>
>>> -Original Message-
>>> From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On
>>> Behalf Of Sharma, Shashank
>>> Sent: Thursday, December 20, 2018 11:54 PM
>>> To: Shankar, Uma ;
>>> intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
>>> Cc: Syrjala, Ville ; Lankhorst, Maarten
>>>
>>> Subject: Re: [v2 04/14] drm: Parse Colorimetry data block from EDID
>>>
>>> Regards
>>>
>>> Shashank
>>>
>>>
>>> On 12/12/2018 2:08 AM, Uma Shankar wrote:
CEA 861.3 spec adds colorimetry data block for HDMI.
Parsing the block to get the colorimetry data from panel.
v2: Rebase
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_edid.c | 24
include/drm/drm_connector.h | 2 ++
2 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index d12b74e..344d8c1 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3818,6 +3818,28 @@ static void
fixup_detailed_cea_mode_clock(struct
>>> drm_display_mode *mode)
mode->clock = clock;
}
+static bool cea_db_is_hdmi_colorimetry_data_block(const u8 *db) {
+ if (cea_db_tag(db) != DATA_BLOCK_EXTENDED_TAG)
+ return false;
+
+ if (db[1] != COLORIMETRY_DATA_BLOCK)
+
>>> Again, the COLORIMETRY_DATA_BLOCK definition should be added into
>>> this patch.
>> Ok, will do that.
>>
return false;
+
+ return true;
+}
+
+static void
+drm_parse_colorimetry_data_block(struct drm_connector *connector,
+const u8 *db) {
+ struct drm_hdmi_info *info = >display_info.hdmi;
+ uint16_t len;
+
+ len = cea_db_payload_len(db);
>>> Again, the return value of this function doesn't account for extended
>>> db tag byte, so what we are looking for is len -1
>> Will update this.
>>
+ info->colorimetry = db[2];
>>> colorimetry block is actually db[2] and db[3].bit7 (which represents
>>> DCI-P3 space), so we probably want to make info->colorimetryuint16_t
>> 3 BT2020RGB BT2020YCC BT2020cYCC AdobeRGB AdobeYCC601 sYCC601
>xvYCC709
>> xvYCC601
>> 4 F47=0 F46=0 F45=0 F44=0 MD3 MD2 MD1 MD0
>>
>> This is how db[2] and db[3] is described in spec. There is not much
>> clarity on F47. Not sure if they are for DCI-P3, can you clarify once.
>Ah, check CEA-861-G table 70, there there is no F47, but I could see
>DCI-P3 in that place, which spec is that you are following right now ?
I am looking to 861-F. So seems like its updated in 861-G ?
Regards,
Uma Shankar
>- Shashank
>> Regards,
>> Uma Shankar
>>
+}
+
+
static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db)
{
if (cea_db_tag(db) != DATA_BLOCK_EXTENDED_TAG) @@ -4513,6
>>> +4535,8
@@ static void drm_parse_cea_ext(struct drm_connector *connector,
drm_parse_y420cmdb_bitmap(connector, db);
if (cea_db_is_hdmi_hdr_metadata_block(db))
drm_parse_hdr_metadata_block(connector, db);
+ if (cea_db_is_hdmi_colorimetry_data_block(db))
+ drm_parse_colorimetry_data_block(connector, db);
}
}
diff --git a/include/drm/drm_connector.h
b/include/drm/drm_connector.h index 2ee45dc..90ce364 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -206,6 +206,8 @@ struct drm_hdmi_info {
/** @y420_dc_modes: bitmap of deep color support index */
u8 y420_dc_modes;
+
>>> Please add a one line description about this variable.
>> Sure will update this.
>>
+ u8 colorimetry;
};
/**
>>> Shashank
>>> ___
>>> dri-devel mailing list
>>> dri-devel@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>___
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v2 04/14] drm: Parse Colorimetry data block from EDID
On 1/8/2019 12:10 PM, Shankar, Uma wrote:
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Sharma, Shashank
Sent: Thursday, December 20, 2018 11:54 PM
To: Shankar, Uma ; intel-...@lists.freedesktop.org;
dri-devel@lists.freedesktop.org
Cc: Syrjala, Ville ; Lankhorst, Maarten
Subject: Re: [v2 04/14] drm: Parse Colorimetry data block from EDID
Regards
Shashank
On 12/12/2018 2:08 AM, Uma Shankar wrote:
CEA 861.3 spec adds colorimetry data block for HDMI.
Parsing the block to get the colorimetry data from panel.
v2: Rebase
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_edid.c | 24
include/drm/drm_connector.h | 2 ++
2 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index d12b74e..344d8c1 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3818,6 +3818,28 @@ static void fixup_detailed_cea_mode_clock(struct
drm_display_mode *mode)
mode->clock = clock;
}
+static bool cea_db_is_hdmi_colorimetry_data_block(const u8 *db) {
+ if (cea_db_tag(db) != DATA_BLOCK_EXTENDED_TAG)
+ return false;
+
+ if (db[1] != COLORIMETRY_DATA_BLOCK)
+
Again, the COLORIMETRY_DATA_BLOCK definition should be added into this
patch.
Ok, will do that.
return false;
+
+ return true;
+}
+
+static void
+drm_parse_colorimetry_data_block(struct drm_connector *connector,
+const u8 *db) {
+ struct drm_hdmi_info *info = >display_info.hdmi;
+ uint16_t len;
+
+ len = cea_db_payload_len(db);
Again, the return value of this function doesn't account for extended db tag
byte,
so what we are looking for is len -1
Will update this.
+ info->colorimetry = db[2];
colorimetry block is actually db[2] and db[3].bit7 (which represents
DCI-P3 space), so we probably want to make info->colorimetryuint16_t
3 BT2020RGB BT2020YCC BT2020cYCC AdobeRGB AdobeYCC601 sYCC601 xvYCC709 xvYCC601
4 F47=0 F46=0 F45=0 F44=0 MD3 MD2 MD1 MD0
This is how db[2] and db[3] is described in spec. There is not much clarity on
F47. Not sure if they
are for DCI-P3, can you clarify once.
Ah, check CEA-861-G table 70, there there is no F47, but I could see
DCI-P3 in that place, which spec is that you are following right now ?
- Shashank
Regards,
Uma Shankar
+}
+
+
static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db)
{
if (cea_db_tag(db) != DATA_BLOCK_EXTENDED_TAG) @@ -4513,6
+4535,8
@@ static void drm_parse_cea_ext(struct drm_connector *connector,
drm_parse_y420cmdb_bitmap(connector, db);
if (cea_db_is_hdmi_hdr_metadata_block(db))
drm_parse_hdr_metadata_block(connector, db);
+ if (cea_db_is_hdmi_colorimetry_data_block(db))
+ drm_parse_colorimetry_data_block(connector, db);
}
}
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 2ee45dc..90ce364 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -206,6 +206,8 @@ struct drm_hdmi_info {
/** @y420_dc_modes: bitmap of deep color support index */
u8 y420_dc_modes;
+
Please add a one line description about this variable.
Sure will update this.
+ u8 colorimetry;
};
/**
Shashank
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [v2 11/14] drm/i915: Add HLG EOTF
>-Original Message-
>From: Sharma, Shashank
>Sent: Friday, December 21, 2018 2:17 PM
>To: Shankar, Uma ; intel-...@lists.freedesktop.org;
>dri-devel@lists.freedesktop.org
>Cc: Lankhorst, Maarten ; Syrjala, Ville
>; brian.star...@arm.com; Ville Syrjälä
>
>Subject: Re: [v2 11/14] drm/i915: Add HLG EOTF
>
>Regards
>
>Shashank
>
>
>On 12/12/2018 2:08 AM, Uma Shankar wrote:
>> From: Ville Syrjälä
>>
>> ADD HLG EOTF to the list of EOTF transfer functions supported.
>Would it be possible to add some details about HLG ?
Sure, will add that.
Regards,
Uma Shankar
>>
>> Signed-off-by: Ville Syrjälä
>> Signed-off-by: Uma Shankar
>> ---
>> drivers/gpu/drm/drm_edid.c | 4 ++--
>> include/linux/hdmi.h | 1 +
>> 2 files changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 5a7fc9b..fa86494 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -3857,8 +3857,8 @@ static uint16_t eotf_supported(const u8 *edid_ext)
>> return edid_ext[2] &
>> (BIT(HDMI_EOTF_TRADITIONAL_GAMMA_SDR) |
>> BIT(HDMI_EOTF_TRADITIONAL_GAMMA_HDR) |
>> - BIT(HDMI_EOTF_SMPTE_ST2084));
>> -
>> + BIT(HDMI_EOTF_SMPTE_ST2084) |
>> + BIT(HDMI_EOTF_BT_2100_HLG));
>> }
>>
>> static uint16_t hdr_metadata_type(const u8 *edid_ext)
>> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
>> index ce00e1e..b5346c3 100644
>> --- a/include/linux/hdmi.h
>> +++ b/include/linux/hdmi.h
>> @@ -146,6 +146,7 @@ enum hdmi_eotf {
>> HDMI_EOTF_TRADITIONAL_GAMMA_SDR,
>> HDMI_EOTF_TRADITIONAL_GAMMA_HDR,
>> HDMI_EOTF_SMPTE_ST2084,
>> +HDMI_EOTF_BT_2100_HLG,
>> };
>>
>> struct hdmi_avi_infoframe {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [v2 09/14] drm/i915: Write HDR infoframe and send to panel
>-Original Message-
>From: Sharma, Shashank
>Sent: Friday, December 21, 2018 2:14 PM
>To: Shankar, Uma ; intel-...@lists.freedesktop.org;
>dri-devel@lists.freedesktop.org
>Cc: Lankhorst, Maarten ; Syrjala, Ville
>; brian.star...@arm.com
>Subject: Re: [v2 09/14] drm/i915: Write HDR infoframe and send to panel
>
>Regards
>
>Shashank
>
>
>On 12/12/2018 2:08 AM, Uma Shankar wrote:
>> Enable writing of HDR metadata infoframe to panel.
>> The data will be provid by usersapace compositors, based on blending
>> policies and passsed to driver through a blob property.
>>
>> v2: Rebase
>>
>> Signed-off-by: Uma Shankar
>> ---
>> drivers/gpu/drm/i915/intel_hdmi.c | 27 +++
>> 1 file changed, 27 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
>> b/drivers/gpu/drm/i915/intel_hdmi.c
>> index 8a1e5cb..6286c4a 100644
>> --- a/drivers/gpu/drm/i915/intel_hdmi.c
>> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
>> @@ -475,6 +475,29 @@ static void intel_write_infoframe(struct intel_encoder
>*encoder,
>> frame->any.type, buffer, len);
>> }
>>
>> +/* Set Dynamic Range and Mastering Infoframe */ static void
>> +intel_hdmi_set_drm_infoframe(struct drm_encoder *encoder,
>> + const struct intel_crtc_state
>> + *crtc_state,
>> + const struct drm_connector_state
>> +
>We will need this function for lspcon too, if you want to add in a different
>series,
>please add a TODO: here.
Sure, will add the same.
Regards,
Uma Shankar
>> *conn_state)
>> +{
>> +union hdmi_infoframe frame;
>> +struct hdr_static_metadata *hdr_metadata;
>> +int ret;
>> +
>> +hdr_metadata = (struct hdr_static_metadata *)
>> +conn_state->hdr_source_metadata_blob_ptr->data;
>> +
>> +ret = drm_hdmi_infoframe_set_hdr_metadata(,
>hdr_metadata);
>> +if (ret < 0) {
>> +DRM_ERROR("couldn't set HDR metadata in infoframe\n");
>> +return;
>> +}
>> +
>> +intel_write_infoframe(encoder, crtc_state, ); }
>> +
>> static void intel_hdmi_set_avi_infoframe(struct intel_encoder *encoder,
>> const struct intel_crtc_state
>*crtc_state,
>> const struct drm_connector_state
>*conn_state) @@ -883,6
>> +906,10 @@ static void hsw_set_infoframes(struct intel_encoder *encoder,
>> intel_hdmi_set_avi_infoframe(encoder, crtc_state, conn_state);
>> intel_hdmi_set_spd_infoframe(encoder, crtc_state);
>> intel_hdmi_set_hdmi_infoframe(encoder, crtc_state, conn_state);
>> +
>> +/* Set Dynamic Range and Mastering Infoframe if supported and changed
>*/
>> +if (conn_state->hdr_metadata_changed)
>> +intel_hdmi_set_drm_infoframe(encoder, crtc_state,
>conn_state);
>> }
>>
>> void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi,
>> bool enable)
>- Shashank
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [v2 08/14] drm: Enable HDR infoframe support
>-Original Message-
>From: Sharma, Shashank
>Sent: Friday, December 21, 2018 2:11 PM
>To: Shankar, Uma ; intel-...@lists.freedesktop.org;
>dri-devel@lists.freedesktop.org
>Cc: Lankhorst, Maarten ; Syrjala, Ville
>; brian.star...@arm.com
>Subject: Re: [v2 08/14] drm: Enable HDR infoframe support
>
>Regards
>
>Shashank
>
>
>On 12/12/2018 2:08 AM, Uma Shankar wrote:
>> Enable Dynamic Range and Mastering Infoframe for HDR content, which is
>> defined in CEA 861.3 spec.
>>
>> The metadata will be computed based on blending policy in userspace
>> compositors and passed as a connector property blob to driver. The
>> same will be sent as infoframe to panel which support HDR.
>>
>> v2: Rebase and added Ville's POC changes.
>>
>> Signed-off-by: Uma Shankar
>> ---
>> drivers/gpu/drm/drm_edid.c | 58
>> drivers/video/hdmi.c | 129
>+
>> include/drm/drm_edid.h | 4 ++
>> include/linux/hdmi.h | 22
>> 4 files changed, 213 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 344d8c1..5a7fc9b 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -4916,6 +4916,64 @@ void drm_set_preferred_mode(struct
>drm_connector *connector,
>> EXPORT_SYMBOL(drm_set_preferred_mode);
>>
>> /**
>> + * drm_hdmi_infoframe_set_hdr_metadata() - fill an HDMI AVI infoframe with
>> + * HDR metadata from userspace
>> + * @frame: HDMI AVI infoframe
>> + * @hdr_source_metadata: hdr_source_metadata info from userspace
>> + *
>> + * Return: 0 on success or a negative error code on failure.
>> + */
>> +int
>> +drm_hdmi_infoframe_set_hdr_metadata(struct hdmi_drm_infoframe *frame,
>> +void *hdr_metadata)
>> +{
>> +struct hdr_static_metadata *hdr_source_metadata;
>> +int err, i;
>> +
>> +if (!frame || !hdr_metadata)
>> +return -EINVAL;
>> +
>> +err = hdmi_drm_infoframe_init(frame);
>> +if (err < 0)
>> +return err;
>> +
>> +DRM_DEBUG_KMS("type = %x\n", frame->type);
>> +
>> +hdr_source_metadata = (struct hdr_static_metadata *)hdr_metadata;
>> +
>> +frame->length = sizeof(struct hdr_static_metadata);
>> +
>> +
>> +frame->eotf = hdr_source_metadata->eotf;
>> +frame->metadata_type = hdr_source_metadata->metadata_type;
>> +
>> +for (i = 0; i < 3; i++) {
>> +frame->display_primaries[i].x =
>> +hdr_source_metadata->display_primaries[i].x;
>> +frame->display_primaries[i].y =
>> +hdr_source_metadata->display_primaries[i].y;
>> +}
>> +
>> +frame->white_point.x = hdr_source_metadata->white_point.x;
>> +frame->white_point.y = hdr_source_metadata->white_point.y;
>> +
>> +frame->max_mastering_display_luminance =
>> +hdr_source_metadata->max_mastering_display_luminance;
>> +frame->min_mastering_display_luminance =
>> +hdr_source_metadata->min_mastering_display_luminance;
>> +
>> +frame->max_cll = hdr_source_metadata->max_cll;
>> +frame->max_fall = hdr_source_metadata->max_fall;
>> +
>> +hdmi_infoframe_log(KERN_CRIT, NULL,
>> + (union hdmi_infoframe *)frame);
>> +
>> +return 0;
>> +}
>> +EXPORT_SYMBOL(drm_hdmi_infoframe_set_hdr_metadata);
>> +
>> +
>> +/**
>>* drm_hdmi_avi_infoframe_from_display_mode() - fill an HDMI AVI infoframe
>with
>>* data from a DRM display
>> mode
>>* @frame: HDMI AVI infoframe
>> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c index
>> 799ae49..0937c8c 100644
>> --- a/drivers/video/hdmi.c
>> +++ b/drivers/video/hdmi.c
>> @@ -650,6 +650,93 @@ ssize_t hdmi_vendor_infoframe_pack(struct
>hdmi_vendor_infoframe *frame,
>> return 0;
>> }
>>
>> +/**
>> + * hdmi_drm_infoframe_init() - initialize an HDMI Dynaminc Range and
>> + * mastering infoframe
>> + * @frame: HDMI DRM infoframe
>> + *
>> + * Returns 0 on success or a negative error code on failure.
>> + */
>> +int hdmi_drm_infoframe_init(struct hdmi_drm_infoframe *frame) {
>> +memset(frame, 0, sizeof(*frame));
>> +
>> +frame->type = HDMI_INFOFRAME_TYPE_DRM;
>> +frame->version = 1;
>> +
>> +return 0;
>> +}
>> +EXPORT_SYMBOL(hdmi_drm_infoframe_init);
>> +
>> +/**
>> + * hdmi_drm_infoframe_pack() - write HDMI DRM infoframe to binary
>> +buffer
>> + * @frame: HDMI DRM infoframe
>> + * @buffer: destination buffer
>> + * @size: size of buffer
>> + *
>> + * Packs the information contained in the @frame structure into a
>> +binary
>> + * representation that can be written into the corresponding
>> +controller
>> + * registers. Also computes the checksum as required by section 5.3.5
>> +of
>> + * the HDMI 1.4 specification.
>> + *
>> + * Returns the number of bytes packed into the binary buffer or a
>> +negative
>> + * error code on failure.
>> + */
>>
RE: [v2 07/14] drm: Implement HDR source metadata set and get property handling
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Sharma, Shashank
>Sent: Friday, December 21, 2018 12:04 AM
>To: Shankar, Uma ; intel-...@lists.freedesktop.org;
>dri-devel@lists.freedesktop.org
>Cc: Syrjala, Ville ; Lankhorst, Maarten
>
>Subject: Re: [v2 07/14] drm: Implement HDR source metadata set and get
>property handling
>
>Regards
>
>Shashank
>
>
>On 12/12/2018 2:08 AM, Uma Shankar wrote:
>> HDR source metadata set and get property implemented in this patch.
>Again, HDR output metadata ? How about re-arranging the line like "This patch
>implements get() and set() functions for HDR output metadata property" just to
>make it more clear ?
Sure, will update this.
>> The blob data is received from userspace and saved in connector state,
>> the same is returned as blob in get property call to userspace.
>>
>> v2: Rebase and added Ville's POC changes
>>
>> Signed-off-by: Uma Shankar
>> ---
>> drivers/gpu/drm/drm_atomic.c | 2 ++
>> drivers/gpu/drm/drm_atomic_uapi.c | 13 +
>> 2 files changed, 15 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic.c
>> b/drivers/gpu/drm/drm_atomic.c index 5eb4013..4e71c6b 100644
>> --- a/drivers/gpu/drm/drm_atomic.c
>> +++ b/drivers/gpu/drm/drm_atomic.c
>> @@ -881,6 +881,8 @@ static void
>> drm_atomic_connector_print_state(struct drm_printer *p,
>>
>> drm_printf(p, "connector[%u]: %s\n", connector->base.id, connector-
>>name);
>> drm_printf(p, "\tcrtc=%s\n", state->crtc ? state->crtc->name :
>> "(null)");
>> +drm_printf(p, "\thdr_metadata_changed=%d\n",
>> +state->hdr_metadata_changed);
>Alignment
Ok, will update.
>>
>> if (connector->connector_type ==
>DRM_MODE_CONNECTOR_WRITEBACK)
>> if (state->writeback_job && state->writeback_job->fb) diff --git
>> a/drivers/gpu/drm/drm_atomic_uapi.c
>> b/drivers/gpu/drm/drm_atomic_uapi.c
>> index c408898..b721b12 100644
>> --- a/drivers/gpu/drm/drm_atomic_uapi.c
>> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
>> @@ -686,6 +686,8 @@ static int drm_atomic_connector_set_property(struct
>drm_connector *connector,
>> {
>> struct drm_device *dev = connector->dev;
>> struct drm_mode_config *config = >mode_config;
>> +bool replaced = false;
>> +int ret;
>>
>> if (property == config->prop_crtc_id) {
>> struct drm_crtc *crtc = drm_crtc_find(dev, NULL, val); @@ -
>734,6
>> +736,14 @@ static int drm_atomic_connector_set_property(struct
>drm_connector *connector,
>> */
>> if (state->link_status != DRM_LINK_STATUS_GOOD)
>> state->link_status = val;
>> +} else if (property == config->hdr_source_metadata_property) {
>> +ret = drm_atomic_replace_property_blob_from_id(dev,
>> +>hdr_source_metadata_blob_ptr,
>> +val,
>> +-1, sizeof(struct hdr_static_metadata),
>> +);
>Alignment, but I know it might be difficult to contain the params within
>80 chars.
Yeah, not sure what is higher priority - 80 character limit or the
alignment here. Currently went with 80 character limit.
Regards,
Uma Shankar
>> +state->hdr_metadata_changed |= replaced;
>> +return ret;
>> } else if (property == config->aspect_ratio_property) {
>> state->picture_aspect_ratio = val;
>> } else if (property == config->content_type_property) { @@ -816,6
>> +826,9 @@ static int drm_atomic_connector_set_property(struct
>drm_connector *connector,
>> *val = state->content_type;
>> } else if (property == connector->scaling_mode_property) {
>> *val = state->scaling_mode;
>> +} else if (property == config->hdr_source_metadata_property) {
>> +*val = (state->hdr_source_metadata_blob_ptr) ?
>> +state->hdr_source_metadata_blob_ptr->base.id : 0;
>> } else if (property == connector->content_protection_property) {
>> *val = state->content_protection;
>> } else if (property == config->writeback_fb_id_property) {
>- Shashank
>___
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [v2 05/14] drm/i915: Attach HDR metadata property to connector
>-Original Message- >From: Sharma, Shashank >Sent: Thursday, December 20, 2018 11:56 PM >To: Shankar, Uma ; intel-...@lists.freedesktop.org; >dri-devel@lists.freedesktop.org >Cc: Lankhorst, Maarten ; Syrjala, Ville >; brian.star...@arm.com >Subject: Re: [v2 05/14] drm/i915: Attach HDR metadata property to connector > >Regards > >Shashank > > >On 12/12/2018 2:08 AM, Uma Shankar wrote: >> Attach HDR metadata property to connector object. >> >> v2: Rebase >> >> Signed-off-by: Uma Shankar >> --- >> drivers/gpu/drm/i915/intel_hdmi.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c >b/drivers/gpu/drm/i915/intel_hdmi.c >> index 07e803a..8a1e5cb 100644 >> --- a/drivers/gpu/drm/i915/intel_hdmi.c >> +++ b/drivers/gpu/drm/i915/intel_hdmi.c >> @@ -2154,6 +2154,8 @@ static void intel_hdmi_destroy(struct drm_connector >*connector) >> intel_attach_aspect_ratio_property(connector); >> drm_connector_attach_content_type_property(connector); >> connector->state->picture_aspect_ratio = >HDMI_PICTURE_ASPECT_NONE; >> +drm_object_attach_property(>base, >> +connector->dev->mode_config.hdr_source_metadata_property, >0); >Alignment with line above missing. It's just to keep it within 80 characters. Hope this is ok. Not sure whether this alignment or 80 character limit takes more priority. Regards, Uma Shankar >- Shashank >> >> if (!HAS_GMCH_DISPLAY(dev_priv)) >> drm_connector_attach_max_bpc_property(connector, 8, 12); ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [v2 04/14] drm: Parse Colorimetry data block from EDID
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Sharma, Shashank
>Sent: Thursday, December 20, 2018 11:54 PM
>To: Shankar, Uma ; intel-...@lists.freedesktop.org;
>dri-devel@lists.freedesktop.org
>Cc: Syrjala, Ville ; Lankhorst, Maarten
>
>Subject: Re: [v2 04/14] drm: Parse Colorimetry data block from EDID
>
>Regards
>
>Shashank
>
>
>On 12/12/2018 2:08 AM, Uma Shankar wrote:
>> CEA 861.3 spec adds colorimetry data block for HDMI.
>> Parsing the block to get the colorimetry data from panel.
>>
>> v2: Rebase
>>
>> Signed-off-by: Uma Shankar
>> ---
>> drivers/gpu/drm/drm_edid.c | 24
>> include/drm/drm_connector.h | 2 ++
>> 2 files changed, 26 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index d12b74e..344d8c1 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -3818,6 +3818,28 @@ static void fixup_detailed_cea_mode_clock(struct
>drm_display_mode *mode)
>> mode->clock = clock;
>> }
>>
>> +static bool cea_db_is_hdmi_colorimetry_data_block(const u8 *db) {
>> +if (cea_db_tag(db) != DATA_BLOCK_EXTENDED_TAG)
>> +return false;
>> +
>> +if (db[1] != COLORIMETRY_DATA_BLOCK)
>> +
>Again, the COLORIMETRY_DATA_BLOCK definition should be added into this
>patch.
Ok, will do that.
>> return false;
>> +
>> +return true;
>> +}
>> +
>> +static void
>> +drm_parse_colorimetry_data_block(struct drm_connector *connector,
>> +const u8 *db) {
>> +struct drm_hdmi_info *info = >display_info.hdmi;
>> +uint16_t len;
>> +
>> +len = cea_db_payload_len(db);
>Again, the return value of this function doesn't account for extended db tag
>byte,
>so what we are looking for is len -1
Will update this.
>> +info->colorimetry = db[2];
>colorimetry block is actually db[2] and db[3].bit7 (which represents
>DCI-P3 space), so we probably want to make info->colorimetryuint16_t
3 BT2020RGB BT2020YCC BT2020cYCC AdobeRGB AdobeYCC601 sYCC601 xvYCC709 xvYCC601
4 F47=0 F46=0 F45=0 F44=0 MD3 MD2 MD1 MD0
This is how db[2] and db[3] is described in spec. There is not much clarity on
F47. Not sure if they
are for DCI-P3, can you clarify once.
Regards,
Uma Shankar
>> +}
>> +
>> +
>> static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db)
>> {
>> if (cea_db_tag(db) != DATA_BLOCK_EXTENDED_TAG) @@ -4513,6
>+4535,8
>> @@ static void drm_parse_cea_ext(struct drm_connector *connector,
>> drm_parse_y420cmdb_bitmap(connector, db);
>> if (cea_db_is_hdmi_hdr_metadata_block(db))
>> drm_parse_hdr_metadata_block(connector, db);
>> +if (cea_db_is_hdmi_colorimetry_data_block(db))
>> +drm_parse_colorimetry_data_block(connector, db);
>> }
>> }
>>
>> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
>> index 2ee45dc..90ce364 100644
>> --- a/include/drm/drm_connector.h
>> +++ b/include/drm/drm_connector.h
>> @@ -206,6 +206,8 @@ struct drm_hdmi_info {
>>
>> /** @y420_dc_modes: bitmap of deep color support index */
>> u8 y420_dc_modes;
>> +
>Please add a one line description about this variable.
Sure will update this.
>> +u8 colorimetry;
>> };
>>
>> /**
>Shashank
>___
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [v2 03/14] drm: Parse HDR metadata info from EDID
>-Original Message-
>From: Sharma, Shashank
>Sent: Tuesday, January 8, 2019 11:26 AM
>To: Shankar, Uma ; intel-...@lists.freedesktop.org;
>dri-devel@lists.freedesktop.org
>Cc: Syrjala, Ville ; Lankhorst, Maarten
>
>Subject: Re: [v2 03/14] drm: Parse HDR metadata info from EDID
>
>Regards
>
>Shashank
>
>
>On 1/8/2019 11:10 AM, Shankar, Uma wrote:
>>
>>> -Original Message-
>>> From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On
>>> Behalf Of Sharma, Shashank
>>> Sent: Thursday, December 20, 2018 11:47 PM
>>> To: Shankar, Uma ;
>>> intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
>>> Cc: Syrjala, Ville ; Lankhorst, Maarten
>>>
>>> Subject: Re: [v2 03/14] drm: Parse HDR metadata info from EDID
>>>
>>> Regards
>>>
>>> Shashank
>>>
>>>
>>> On 12/12/2018 2:08 AM, Uma Shankar wrote:
HDR metadata block is introduced in CEA-861.3 spec.
Parsing the same to get the panel's HDR metadata.
v2: Rebase and added Ville's POC changes to the patch.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_edid.c | 45
>>> +
1 file changed, 45 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 106fd38..d12b74e 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3818,6 +3818,49 @@ static void
fixup_detailed_cea_mode_clock(struct
>>> drm_display_mode *mode)
mode->clock = clock;
}
>>> I guess the previous patch (or a art of previous patch) should be
>>> merged in this patch.
>> Sure, will update this.
>>
+static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db) {
+ if (cea_db_tag(db) != DATA_BLOCK_EXTENDED_TAG)
+ return false;
+
+ if (db[1] != HDR_STATIC_METADATA_BLOCK)
+ return false;
+
+ return true;
+}
+
+static uint16_t eotf_supported(const u8 *edid_ext)
>>> Why uint16 ? why not uint8_t ? this is clearly one byte.
>> Ok, will change this.
>>
+{
+
+ return edid_ext[2] &
+ (BIT(HDMI_EOTF_TRADITIONAL_GAMMA_SDR) |
>>> Should we bother about SDR bit at all ? Why not just check HDR bits ?
>> As per spec, all of these are EOTF types. So lets update whatever is
>> supported.
>> User should put correct EOTF for HDR from this list.
>>
+ BIT(HDMI_EOTF_TRADITIONAL_GAMMA_HDR) |
+ BIT(HDMI_EOTF_SMPTE_ST2084));
+
+}
+
+static uint16_t hdr_metadata_type(const u8 *edid_ext) {
>>> Same uint8_t stuff
>> Ok. Will update.
>>
+
+ return edid_ext[3] &
+ BIT(HDMI_STATIC_METADATA_TYPE1);
+}
+
+static void
+drm_parse_hdr_metadata_block(struct drm_connector *connector, const
+u8 *db) {
+ uint16_t len;
+
+ len = cea_db_payload_len(db);
>>> Length is incorrect here for extended tag blocks, as this function
>>> doesn't account the extended tag byte's size. So the payload length
>>> is looking for is len - 1. May be a good time to add
>>> cea_extended_db_payload_len() ?
>> As per spec, the definition says length after this byte so it factors
>> the extended tag byte well, IIUC. Please correct me if my understanding is
>wrong.
>This is how the data is arranged in a normal CEA DB and Extended CEA DB
>++ +-+
>|Tag|Length= 3 | |Tag|Length=3 |
>++ +-+
>| Data | |Extended tag |
>++ +-+
>| Data | |Data |
>++ +-+
>| Data | |Data |
>++ +-+
>
>This function cea_db_payload_len() was written before the CEA extended blocks
>were introduced, so it is unaware of Extended tag code, and assumes its a part
>of
>data. But in case of extended tag block the actual data length is 3 -1 = 2.
>You can
>have a look at how we are parsing the YCBCR 4:2:0 blocks. That's why I made
>this
>comment "may be a good time to add cea_extended_db_payload_len() function"
>or enhance the existing function to reflect the extended tag.
Oh ok got it, thanks for the explanation. Will update the patch accordingly.
Regards,
Uma Shankar
>- Shashank
>>
>> Regards,
>> Uma Shankar
>>
+ connector->hdr_metadata.eotf = eotf_supported(db);
+ connector->hdr_metadata.metadata_type = hdr_metadata_type(db);
+
+ if (len >= 5)
+ connector->hdr_metadata.max_fall = db[5];
+ if (len >= 4)
+ connector->hdr_metadata.max_cll = db[4]; }
+
static void
drm_parse_hdmi_vsdb_audio(struct drm_connector *connector, const u8
>*db)
{
@@ -4468,6 +4511,8 @@ static void drm_parse_cea_ext(struct
drm_connector
>>> *connector,
Re: [v2 03/14] drm: Parse HDR metadata info from EDID
Regards
Shashank
On 1/8/2019 11:10 AM, Shankar, Uma wrote:
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Sharma, Shashank
Sent: Thursday, December 20, 2018 11:47 PM
To: Shankar, Uma ; intel-...@lists.freedesktop.org;
dri-devel@lists.freedesktop.org
Cc: Syrjala, Ville ; Lankhorst, Maarten
Subject: Re: [v2 03/14] drm: Parse HDR metadata info from EDID
Regards
Shashank
On 12/12/2018 2:08 AM, Uma Shankar wrote:
HDR metadata block is introduced in CEA-861.3 spec.
Parsing the same to get the panel's HDR metadata.
v2: Rebase and added Ville's POC changes to the patch.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_edid.c | 45
+
1 file changed, 45 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 106fd38..d12b74e 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3818,6 +3818,49 @@ static void fixup_detailed_cea_mode_clock(struct
drm_display_mode *mode)
mode->clock = clock;
}
I guess the previous patch (or a art of previous patch) should be merged in this
patch.
Sure, will update this.
+static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db) {
+ if (cea_db_tag(db) != DATA_BLOCK_EXTENDED_TAG)
+ return false;
+
+ if (db[1] != HDR_STATIC_METADATA_BLOCK)
+ return false;
+
+ return true;
+}
+
+static uint16_t eotf_supported(const u8 *edid_ext)
Why uint16 ? why not uint8_t ? this is clearly one byte.
Ok, will change this.
+{
+
+ return edid_ext[2] &
+ (BIT(HDMI_EOTF_TRADITIONAL_GAMMA_SDR) |
Should we bother about SDR bit at all ? Why not just check HDR bits ?
As per spec, all of these are EOTF types. So lets update whatever is supported.
User should put correct EOTF for HDR from this list.
+BIT(HDMI_EOTF_TRADITIONAL_GAMMA_HDR) |
+BIT(HDMI_EOTF_SMPTE_ST2084));
+
+}
+
+static uint16_t hdr_metadata_type(const u8 *edid_ext) {
Same uint8_t stuff
Ok. Will update.
+
+ return edid_ext[3] &
+ BIT(HDMI_STATIC_METADATA_TYPE1);
+}
+
+static void
+drm_parse_hdr_metadata_block(struct drm_connector *connector, const
+u8 *db) {
+ uint16_t len;
+
+ len = cea_db_payload_len(db);
Length is incorrect here for extended tag blocks, as this function doesn't
account
the extended tag byte's size. So the payload length is looking for is len - 1.
May be
a good time to add
cea_extended_db_payload_len() ?
As per spec, the definition says length after this byte so it factors the
extended tag byte
well, IIUC. Please correct me if my understanding is wrong.
This is how the data is arranged in a normal CEA DB and Extended CEA DB
++ +-+
|Tag|Length= 3 | |Tag|Length=3 |
++ +-+
| Data | |Extended tag |
++ +-+
| Data | |Data |
++ +-+
| Data | |Data |
++ +-+
This function cea_db_payload_len() was written before the CEA extended
blocks were introduced, so it is unaware of Extended tag code, and
assumes its a part of data. But in case of extended tag block the actual
data length is 3 -1 = 2. You can have a look at how we are parsing the
YCBCR 4:2:0 blocks. That's why I made this comment "may be a good time
to add cea_extended_db_payload_len() function" or enhance the existing
function to reflect the extended tag.
- Shashank
Regards,
Uma Shankar
+ connector->hdr_metadata.eotf = eotf_supported(db);
+ connector->hdr_metadata.metadata_type = hdr_metadata_type(db);
+
+ if (len >= 5)
+ connector->hdr_metadata.max_fall = db[5];
+ if (len >= 4)
+ connector->hdr_metadata.max_cll = db[4]; }
+
static void
drm_parse_hdmi_vsdb_audio(struct drm_connector *connector, const u8 *db)
{
@@ -4468,6 +4511,8 @@ static void drm_parse_cea_ext(struct drm_connector
*connector,
drm_parse_hdmi_forum_vsdb(connector, db);
if (cea_db_is_y420cmdb(db))
drm_parse_y420cmdb_bitmap(connector, db);
+ if (cea_db_is_hdmi_hdr_metadata_block(db))
+ drm_parse_hdr_metadata_block(connector, db);
}
}
- Shashank
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [v2 03/14] drm: Parse HDR metadata info from EDID
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Sharma, Shashank
>Sent: Thursday, December 20, 2018 11:47 PM
>To: Shankar, Uma ; intel-...@lists.freedesktop.org;
>dri-devel@lists.freedesktop.org
>Cc: Syrjala, Ville ; Lankhorst, Maarten
>
>Subject: Re: [v2 03/14] drm: Parse HDR metadata info from EDID
>
>Regards
>
>Shashank
>
>
>On 12/12/2018 2:08 AM, Uma Shankar wrote:
>> HDR metadata block is introduced in CEA-861.3 spec.
>> Parsing the same to get the panel's HDR metadata.
>>
>> v2: Rebase and added Ville's POC changes to the patch.
>>
>> Signed-off-by: Uma Shankar
>> ---
>> drivers/gpu/drm/drm_edid.c | 45
>+
>> 1 file changed, 45 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 106fd38..d12b74e 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -3818,6 +3818,49 @@ static void fixup_detailed_cea_mode_clock(struct
>drm_display_mode *mode)
>> mode->clock = clock;
>> }
>I guess the previous patch (or a art of previous patch) should be merged in
>this
>patch.
Sure, will update this.
>> +static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db) {
>> +if (cea_db_tag(db) != DATA_BLOCK_EXTENDED_TAG)
>> +return false;
>> +
>> +if (db[1] != HDR_STATIC_METADATA_BLOCK)
>> +return false;
>> +
>> +return true;
>> +}
>> +
>> +static uint16_t eotf_supported(const u8 *edid_ext)
>Why uint16 ? why not uint8_t ? this is clearly one byte.
Ok, will change this.
>> +{
>> +
>> +return edid_ext[2] &
>> +(BIT(HDMI_EOTF_TRADITIONAL_GAMMA_SDR) |
>Should we bother about SDR bit at all ? Why not just check HDR bits ?
As per spec, all of these are EOTF types. So lets update whatever is supported.
User should put correct EOTF for HDR from this list.
>> + BIT(HDMI_EOTF_TRADITIONAL_GAMMA_HDR) |
>> + BIT(HDMI_EOTF_SMPTE_ST2084));
>> +
>> +}
>> +
>> +static uint16_t hdr_metadata_type(const u8 *edid_ext) {
>Same uint8_t stuff
Ok. Will update.
>> +
>> +return edid_ext[3] &
>> +BIT(HDMI_STATIC_METADATA_TYPE1);
>> +}
>> +
>> +static void
>> +drm_parse_hdr_metadata_block(struct drm_connector *connector, const
>> +u8 *db) {
>> +uint16_t len;
>> +
>> +len = cea_db_payload_len(db);
>Length is incorrect here for extended tag blocks, as this function doesn't
>account
>the extended tag byte's size. So the payload length is looking for is len - 1.
>May be
>a good time to add
>cea_extended_db_payload_len() ?
As per spec, the definition says length after this byte so it factors the
extended tag byte
well, IIUC. Please correct me if my understanding is wrong.
Regards,
Uma Shankar
>> +connector->hdr_metadata.eotf = eotf_supported(db);
>> +connector->hdr_metadata.metadata_type = hdr_metadata_type(db);
>> +
>> +if (len >= 5)
>> +connector->hdr_metadata.max_fall = db[5];
>> +if (len >= 4)
>> +connector->hdr_metadata.max_cll = db[4]; }
>> +
>> static void
>> drm_parse_hdmi_vsdb_audio(struct drm_connector *connector, const u8 *db)
>> {
>> @@ -4468,6 +4511,8 @@ static void drm_parse_cea_ext(struct drm_connector
>*connector,
>> drm_parse_hdmi_forum_vsdb(connector, db);
>> if (cea_db_is_y420cmdb(db))
>> drm_parse_y420cmdb_bitmap(connector, db);
>> +if (cea_db_is_hdmi_hdr_metadata_block(db))
>> +drm_parse_hdr_metadata_block(connector, db);
>> }
>> }
>>
>- Shashank
>
>___
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [v2 02/14] drm: Add CEA extended tag blocks and HDR bitfield macros
>-Original Message- >From: Sharma, Shashank >Sent: Thursday, December 20, 2018 11:38 PM >To: Shankar, Uma ; intel-...@lists.freedesktop.org; >dri-devel@lists.freedesktop.org >Cc: Lankhorst, Maarten ; Syrjala, Ville >; brian.star...@arm.com >Subject: Re: [v2 02/14] drm: Add CEA extended tag blocks and HDR bitfield >macros > >Regards > >Shashank > > >On 12/12/2018 2:08 AM, Uma Shankar wrote: >> Add bit field and macro for extended tag in CEA block. Also, declare >> macros for HDR metadata block. >This should have been a part of patch, where these macros are being used, so >that we can see it being used properly. While re-basing can you please merge ? Idea was to define all new block additions and bit fields in 1 patch. But will add to respective patches where they are getting used as you mentioned. >> v2: Rebase >> >> Signed-off-by: Uma Shankar >> --- >> drivers/gpu/drm/drm_edid.c | 16 >> 1 file changed, 16 insertions(+) >> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c >> index b506e36..106fd38 100644 >> --- a/drivers/gpu/drm/drm_edid.c >> +++ b/drivers/gpu/drm/drm_edid.c >> @@ -2843,6 +2843,22 @@ static int drm_cvt_modes(struct drm_connector >*connector, >> #define EDID_CEA_YCRCB422 (1 << 4) >> #define EDID_CEA_VCDB_QS (1 << 6) >> >> +#define DATA_BLOCK_EXTENDED_TAG 0x07 >Alignment should be one tab back, also I think we already have added >extended tag macro (for parsing YCBCR420 blocks) Ok, will drop this. >> +#define VIDEO_CAPABILITY_DATA_BLOCK 0x0 >> +#define VSVD_DATA_BLOCK 0x1 >Alignment one tab back This is some editor issue, change looks ok on applying. Will recheck while rebasing. >> +#define COLORIMETRY_DATA_BLOCK 0x5 >> +#define HDR_STATIC_METADATA_BLOCK 0x6 >> + >> +/* HDR Metadata Block: Bit fields */ >> +#define SUPPORTED_EOTF_MASK0x3f >> +#define TRADITIONAL_GAMMA_SDR (0x1 << 0) >> +#define TRADITIONAL_GAMMA_HDR (0x1 << 1) >> +#define SMPTE_ST2084 (0x1 << 2) >> +#define FUTURE_EOTF(0x1 << 3) >why not properly call it HLG if we are adding a bit for it already ? Ok. Will update. Regards, Uma Shankar >> +#define RESERVED_EOTF (0x3 << 4) >> + >> +#define STATIC_METADATA_TYPE1 (0x1 << 0) >> + >> /* >>* Search EDID for CEA extension block. >>*/ >- Shashank ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [v2 01/14] drm: Add HDR source metadata property
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Sharma, Shashank
>Sent: Thursday, December 20, 2018 11:21 PM
>To: Shankar, Uma ; intel-...@lists.freedesktop.org;
>dri-devel@lists.freedesktop.org
>Cc: Syrjala, Ville ; Lankhorst, Maarten
>
>Subject: Re: [v2 01/14] drm: Add HDR source metadata property
>
>Regards
>
>Shashank
>
>
>On 12/12/2018 2:08 AM, Uma Shankar wrote:
>> This patch adds a blob property to get HDR metadata information from
>> userspace. This will be send as part of AVI Infoframe to panel.
>>
>> v2: Rebase and modified the metadata structure elements as per Ville's
>> POC changes.
>>
>> Signed-off-by: Uma Shankar
>> ---
>> drivers/gpu/drm/drm_connector.c | 6 ++
>> include/drm/drm_connector.h | 10 ++
>> include/drm/drm_mode_config.h | 6 ++
>> include/linux/hdmi.h| 10 ++
>> include/uapi/drm/drm_mode.h | 16
>> 5 files changed, 48 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_connector.c
>> b/drivers/gpu/drm/drm_connector.c index da8ae80..361fcda 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -1027,6 +1027,12 @@ int
>drm_connector_create_standard_properties(struct drm_device *dev)
>> return -ENOMEM;
>> dev->mode_config.non_desktop_property = prop;
>>
>> +prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
>> + "HDR_SOURCE_METADATA", 0);
>I see that the compositor would be using this blob to setup the output HDR
>curve
>post blending, which would be in most of cases, sink HDR. So we should ideally
>call it HDR_OUTPUT_METADATA or output_hdr_metadata.
Ok Sure, will update the property name.
>> +if (!prop)
>> +return -ENOMEM;
>> +dev->mode_config.hdr_source_metadata_property = prop;
>> +
>> return 0;
>> }
>>
>> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
>> index 9be2181..2ee45dc 100644
>> --- a/include/drm/drm_connector.h
>> +++ b/include/drm/drm_connector.h
>> @@ -520,6 +520,13 @@ struct drm_connector_state {
>> * and the connector bpc limitations obtained from edid.
>> */
>> u8 max_bpc;
>> +
>> +/**
>> + * @metadata_blob_ptr:
>> + * DRM blob property for HDR metadata
>> + */
>> +struct drm_property_blob *hdr_source_metadata_blob_ptr;
>Same goes again here, output_hdr_metadata_blob ?
Ok.
>> +u8 hdr_metadata_changed : 1;
>> };
>>
>> /**
>> @@ -1154,6 +1161,9 @@ struct drm_connector {
>> * _mode_config.connector_free_work.
>> */
>> struct llist_node free_node;
>> +
>> +/* HDR metdata */
>> +struct hdr_static_metadata hdr_metadata;
>I think while designing this framework, we should leave the scope for dynamic
>metadata, which would be following up soon. So we should have a union inside
>struct hdr_metedata, which will have option for both static and dynamic type of
>metadata. I will add details to the place where you are adding definition of
>hdr_static_metadata().
I feel since we are not yet targeting beyond HDR10, lets not add dynamic
metadata
definitions as of now. We will add when the same gets enabled. I hope this is
ok.
>> };
>>
>> #define obj_to_connector(x) container_of(x, struct drm_connector,
>> base) diff --git a/include/drm/drm_mode_config.h
>> b/include/drm/drm_mode_config.h index 69ccd27..4b3211b 100644
>> --- a/include/drm/drm_mode_config.h
>> +++ b/include/drm/drm_mode_config.h
>> @@ -836,6 +836,12 @@ struct drm_mode_config {
>> */
>> struct drm_property *writeback_out_fence_ptr_property;
>>
>> +/*
>> + * hdr_metadata_property: Connector property containing hdr metatda
>> + * This will be provided by userspace compositors based on HDR content
>> + */
>> +struct drm_property *hdr_source_metadata_property;
>Again, source->output
Sure, will change it.
>> +
>> /* dumb ioctl parameters */
>> uint32_t preferred_depth, prefer_shadow;
>>
>> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h index
>> d2bacf5..bed3e08 100644
>> --- a/include/linux/hdmi.h
>> +++ b/include/linux/hdmi.h
>> @@ -137,6 +137,16 @@ enum hdmi_content_type {
>> HDMI_CONTENT_TYPE_GAME,
>> };
>>
>> +enum hdmi_metadata_type {
>> +HDMI_STATIC_METADATA_TYPE1 = 1,
>> +};
>> +
>> +enum hdmi_eotf {
>> +HDMI_EOTF_TRADITIONAL_GAMMA_SDR,
>> +HDMI_EOTF_TRADITIONAL_GAMMA_HDR,
>> +HDMI_EOTF_SMPTE_ST2084,
>I guess we are not bothering about HLG now, which is fine actually, less
>complicated for now.
Yeah.
>> +};
>> +
>> struct hdmi_avi_infoframe {
>> enum hdmi_infoframe_type type;
>> unsigned char version;
>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
>> index a439c2e..5012af2 100644
>> --- a/include/uapi/drm/drm_mode.h
>> +++ b/include/uapi/drm/drm_mode.h
>> @@ -630,6 +630,22 @@ struct drm_color_lut {
>> __u16 reserved;
>> };
>>
>> +/*
[Bug 109246] HDMI connected monitors fail to sleep and instead turn back on when amdgpu.dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=109246 --- Comment #1 from tme --- Forgot to mention that I have tested and reproduced this bug on kernel versions 4.18, 4.20, and 5.0-rc1. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109246] HDMI connected monitors fail to sleep and instead turn back on when amdgpu.dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=109246 Bug ID: 109246 Summary: HDMI connected monitors fail to sleep and instead turn back on when amdgpu.dc=1 Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: t00m4nyerr...@gmail.com Original launchpad thread: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1790861 Overview: When my computer tries to suspend my monitors after a period of idleness, they'll suspend for a few seconds before waking back up. Steps to Reproduce: 1) Have a monitor attached over HDMI. 2) Set screen energy saving (in Plasma 5) to 1 minute. 3) After 1 minute has passed, the monitor will try to enter sleep mode. It will fail and turn back on. 4) The monitor will continue to attempt to enter sleep mode every minute until interrupted by the user. Actual Results: The monitors turn back on a few seconds after entering sleep mode. Expected Results: The monitors stay in sleep mode. Additional Information: While I have two monitors, this issue is only triggered when one is connected using HDMI. Connecting only one monitor using HDMI will trigger the problem. Connecting either one using DVI does not trigger the problem. I am unable to test if DisplayPort triggers the problem, as I have no compatible monitors. Setting the kernel parameter amdgpu.dc=0 does not cause the problem to trigger. I haven't confirmed if the other affected users in the launchpad thread are using HDMI, so I'm only reporting my experience. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108464] System fails to reboot after Ctrl-Alt-Del
https://bugs.freedesktop.org/show_bug.cgi?id=108464 --- Comment #15 from Duncan Roe --- Further to attachment 143008: there are lots of calls to dm_dp_aux_transfer with aux=f0bfdb41, but the first call with aux=74cc4227 fails (because the aux_engine pointer is NULL). Then a few more calls with f0bfdb41, 2 more with 74cc4227 and lastly a few with f0bfdb41 again. Does that pattern jog anyone's memory? Is anyone else reproducing this bug? https://bugs.freedesktop.org/show_bug.cgi?id=108139#c5 mentions the name "Stoney" (chipset(?)) in case that is any help. If no-one else is reproducing this, what would be the most helpful thing I could try next? I don't see this behviour in a VM, so can't gdb it. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108464] System fails to reboot after Ctrl-Alt-Del
https://bugs.freedesktop.org/show_bug.cgi?id=108464 --- Comment #14 from Duncan Roe --- Created attachment 143008 --> https://bugs.freedesktop.org/attachment.cgi?id=143008=edit dmesg o/p with attachment 143007 The exception occurs in dc_link_aux_transfer, which is called by dm_dp_aux_transfer which is the top displayed function on the stack after the BUG line in attachment 142063. There is no BUG entry with the patch, instead there is a line Cowardly refusing to call through null pointer after which the patch makes dc_link_aux_transfer return -1. Code somewhere up the stack attempts 2 retries. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108464] System fails to reboot after Ctrl-Alt-Del
https://bugs.freedesktop.org/show_bug.cgi?id=108464 --- Comment #13 from Duncan Roe --- Created attachment 143007 --> https://bugs.freedesktop.org/attachment.cgi?id=143007=edit Diagnostic patches to determine which pointer is null These patches are against Linux 4.19.12, commit 2a7cb228d29c3882c1414c10a44c5f3f59bfa44d in git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108577] Black X laptop screen with cursor if HDMI not plugged in, bisected
https://bugs.freedesktop.org/show_bug.cgi?id=108577 Duncan Roe changed: What|Removed |Added Attachment #143006|1 |0 is patch|| Attachment #143006|0 |1 is obsolete|| --- Comment #41 from Duncan Roe --- Comment on attachment 143006 --> https://bugs.freedesktop.org/attachment.cgi?id=143006 Diagnostic patches to determine which pointer is null Sorry everyone - attachment 143006 belongs to bug 108464 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108577] Black X laptop screen with cursor if HDMI not plugged in, bisected
https://bugs.freedesktop.org/show_bug.cgi?id=108577 --- Comment #40 from Duncan Roe --- Created attachment 143006 --> https://bugs.freedesktop.org/attachment.cgi?id=143006=edit Diagnostic patches to determine which pointer is null These patches are against Linux 4.19.12, commit 2a7cb228d29c3882c1414c10a44c5f3f59bfa44d in git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109229] glLinkProgram locks up for ~30 seconds
https://bugs.freedesktop.org/show_bug.cgi?id=109229 --- Comment #4 from smt --- (In reply to Timothy Arceri from comment #3) > (In reply to smt from comment #2) > > This issue seems to be affecting me too, some people say it's been fixed in > > 18.2.3/.4 however I'm running 18.3.1 and definitely have the same symptoms > > in regards to Godot freezing up, I don't know much so can't be more help, > > there seems to be some discussion relating to the issue here though: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1646888 > > Are you sure that is the same bug? That one wasn't a Mesa bug it was a bug > in GCC. uh yeah sorry, I think that might be right, the symptoms are all very similar and the versions so close it's getting a little confusing for me to figure it all out to be honest -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109140] [KBL-G][GL] KHR-GL43.compute_shader.max test failed
https://bugs.freedesktop.org/show_bug.cgi?id=109140 Hai changed: What|Removed |Added QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Hardware|Other |x86-64 (AMD64) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/amdgpu: Don't ignore rc from drm_dp_mst_topology_mgr_resume()
drm_dp_mst_topology_mgr_resume() returns whether or not it managed to
find the topology in question after a suspend resume cycle, and the
driver is supposed to check this value and disable MST accordingly if
it's gone-in addition to sending a hotplug in order to notify userspace
that something changed during suspend.
Currently, amdgpu just makes the mistake of ignoring the return code
from drm_dp_mst_topology_mgr_resume() which means that if a topology was
removed in suspend, amdgpu never notices and assumes it's still
connected which leads to all sorts of problems.
So, fix this by actually checking the rc from
drm_dp_mst_topology_mgr_resume(). Also, reformat the rest of the
function while we're at it to fix the over-indenting.
Signed-off-by: Lyude Paul
Cc: Jerry Zuo
Cc: # v4.15+
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 32 +--
1 file changed, 23 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 8a626d16e8e3..3f326a2c513b 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -699,22 +699,36 @@ static void s3_handle_mst(struct drm_device *dev, bool
suspend)
{
struct amdgpu_dm_connector *aconnector;
struct drm_connector *connector;
+ struct drm_dp_mst_topology_mgr *mgr;
+ int ret;
+ bool need_hotplug = false;
drm_modeset_lock(>mode_config.connection_mutex, NULL);
- list_for_each_entry(connector, >mode_config.connector_list, head) {
- aconnector = to_amdgpu_dm_connector(connector);
- if (aconnector->dc_link->type == dc_connection_mst_branch &&
- !aconnector->mst_port) {
+ list_for_each_entry(connector, >mode_config.connector_list,
+ head) {
+ aconnector = to_amdgpu_dm_connector(connector);
+ if (aconnector->dc_link->type != dc_connection_mst_branch ||
+ aconnector->mst_port)
+ continue;
+
+ mgr = >mst_mgr;
- if (suspend)
-
drm_dp_mst_topology_mgr_suspend(>mst_mgr);
- else
-
drm_dp_mst_topology_mgr_resume(>mst_mgr);
- }
+ if (suspend) {
+ drm_dp_mst_topology_mgr_suspend(mgr);
+ } else {
+ ret = drm_dp_mst_topology_mgr_resume(mgr);
+ if (ret < 0) {
+ drm_dp_mst_topology_mgr_set_mst(mgr, false);
+ need_hotplug = true;
+ }
+ }
}
drm_modeset_unlock(>mode_config.connection_mutex);
+
+ if (need_hotplug)
+ drm_kms_helper_hotplug_event(dev);
}
/**
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: Block fb changes for async plane updates
Hi, [This is an automated email] This commit has been processed because it contains a "Fixes:" tag, fixing commit: fef9df8b5945 drm/atomic: initial support for asynchronous plane update. The bot has tested the following trees: v4.20.0, v4.19.13, v4.14.91. v4.20.0: Build OK! v4.19.13: Build OK! v4.14.91: Build failed! Errors: drivers/gpu/drm/drm_atomic_helper.c:1421:6: error: âold_plane_stateâ undeclared (first use in this function); did you mean âdrm_plane_stateâ? drivers/gpu/drm/drm_atomic_helper.c:1421:29: error: ânew_plane_stateâ undeclared (first use in this function); did you mean âdrm_plane_stateâ? How should we proceed with this patch? -- Thanks, Sasha ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/amdgpu: Don't fail resume process if resuming atomic state fails
This is an ugly one unfortunately. Currently, all DRM drivers supporting atomic modesetting will save the state that userspace had set before suspending, then attempt to restore that state on resume. This probably worked very well at one point, like many other things, until DP MST came into the picture. While it's easy to restore state on normal display connectors that were disconnected during suspend regardless of their state post-resume, this can't really be done with MST because of the fact that setting up a downstream sink requires performing sideband transactions between the source and the MST hub, sending out the ACT packets, etc. Because of this, there isn't really a guarantee that we can restore the atomic state we had before suspend once we've resumed. This sucks pretty bad, but so far I haven't run into any compositors that this actually causes serious issues with. Most compositors will notice the hotplug we send afterwards, and then reprobe state. Since nouveau and i915 also don't fail the suspend/resume process due to failing to restore the atomic state, let's make amdgpu match this behavior. Better to resume the GPU properly, then to stop the process half way because of a potentially unavoidable atomic commit failure. Eventually, we'll have a real fix for this problem on the DRM level. But we've got some more important low-hanging fruit to deal with first. Signed-off-by: Lyude Paul Cc: Jerry Zuo Cc: # v4.15+ --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 3f326a2c513b..a3e65e457348 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -912,7 +912,6 @@ static int dm_resume(void *handle) struct drm_plane_state *new_plane_state; struct dm_plane_state *dm_new_plane_state; enum dc_connection_type new_connection_type = dc_connection_none; - int ret; int i; /* power on hardware */ @@ -985,13 +984,13 @@ static int dm_resume(void *handle) } } - ret = drm_atomic_helper_resume(ddev, dm->cached_state); + drm_atomic_helper_resume(ddev, dm->cached_state); dm->cached_state = NULL; amdgpu_dm_irq_resume_late(adev); - return ret; + return 0; } /** -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] drm/amdgpu: Fix suspend/resume issues with MST
Fix the suspend/issues that Jerry Zuo found in amdgpu, and add some compiler warnings for drivers ignoring the return code of drm_dp_mst_topology_mgr_resume() to help ensure we don't need to fix this again in the future for someone else's driver. Cc: Jerry Zuo Lyude Paul (3): drm/amdgpu: Don't ignore rc from drm_dp_mst_topology_mgr_resume() drm/amdgpu: Don't fail resume process if resuming atomic state fails drm/dp_mst: Add __must_check to drm_dp_mst_topology_mgr_resume() .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 37 +-- drivers/gpu/drm/drm_dp_mst_topology.c | 3 +- include/drm/drm_dp_mst_helper.h | 3 +- 3 files changed, 29 insertions(+), 14 deletions(-) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/dp_mst: Add __must_check to drm_dp_mst_topology_mgr_resume()
Since I've had to fix two cases of drivers not checking the return code
from this function, let's make the compiler complain so this doesn't
come up again in the future.
Signed-off-by: Lyude Paul
Cc: Jerry Zuo
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_dp_mst_topology.c | 3 ++-
include/drm/drm_dp_mst_helper.h | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 2ab16c9e6243..13a7e497bfe2 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2226,7 +2226,8 @@ EXPORT_SYMBOL(drm_dp_mst_topology_mgr_suspend);
* if the device fails this returns -1, and the driver should do
* a full MST reprobe, in case we were undocked.
*/
-int drm_dp_mst_topology_mgr_resume(struct drm_dp_mst_topology_mgr *mgr)
+int __must_check
+drm_dp_mst_topology_mgr_resume(struct drm_dp_mst_topology_mgr *mgr)
{
int ret = 0;
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 371cc2816477..4355b55d0081 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -614,7 +614,8 @@ void drm_dp_mst_dump_topology(struct seq_file *m,
struct drm_dp_mst_topology_mgr *mgr);
void drm_dp_mst_topology_mgr_suspend(struct drm_dp_mst_topology_mgr *mgr);
-int drm_dp_mst_topology_mgr_resume(struct drm_dp_mst_topology_mgr *mgr);
+int __must_check
+drm_dp_mst_topology_mgr_resume(struct drm_dp_mst_topology_mgr *mgr);
struct drm_dp_mst_topology_state *drm_atomic_get_mst_topology_state(struct
drm_atomic_state *state,
struct
drm_dp_mst_topology_mgr *mgr);
int drm_dp_atomic_find_vcpi_slots(struct drm_atomic_state *state,
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Armada DRM: bridge with componentized devices
On Mon, Jan 07, 2019 at 10:55:15PM +0100, Daniel Vetter wrote: > On Mon, Jan 7, 2019 at 5:13 PM Russell King - ARM Linux > wrote: > > > > On Mon, Jan 07, 2019 at 11:45:32AM +0100, Daniel Vetter wrote: > > > On Thu, Jan 03, 2019 at 01:11:47PM +, Russell King - ARM Linux wrote: > > > > This is the long-standing problem with the conflict between bridge > > > > support and component support, and I'm not sure that there is really > > > > any answer to it. > > > > > > > > I've gone into the details of the two several times on the list, > > > > particularly about the short-comings of the bridge approach, but it > > > > seems no one cares to fix those short-comings. > > > > > > > > You are re-identifying some of the issues that I've already pointed > > > > out - such as what happens to DRM drives when the bridge driver is > > > > unbound (it's really not about modules being unloaded, and the problem > > > > can't be solved by taking a module reference count - all that the > > > > module reference count does is ensure that the module doesn't go > > > > away unexpected, there is no way to ensure that the device isn't > > > > unbound.) > > > > > > > > The issue of unbinding is precisely the issue which the component > > > > support was created to solve - but everyone seems to prefer the buggy > > > > bridge approach, and no one seems willing to do anything about the > > > > bugs or even acknowledge that it's a problem. It's strange - if one > > > > identifies bugs that result in kernel oops in other kernel subsystems, > > > > one is generally taken seriously and the problem is solved. > > > > > > Unbinding is really not the most important feature, especially for SoC. If > > > you feel different, working together with others, getting some agreement, > > > getting the patches reviewed and finding someone to get them merged is > > > very much appreciated. But just complaining won't move this forward. > > > > Sorry, I disagree. Unbinding is important if the current state results > > in crashes and oops - the lack of unbinding support in bridge makes it > > harder to develop without constantly rebooting the target machine. > > > > If all you care about is the end user who probably never removes a > > module, then yes, it's low priority, but if you care about efficient > > development, then the story is rather different. > > Unloading i915 needs a very careful script, or you'll get a rather > bright fireworks. Afaik all other drm drivers (except maybe udl) are > the same. At least if you do anything fancy, where fancy includes: > fbdev emulation, prime buffer sharing, shared dma fences, or well > anything really that goes beyond a dummy boot splash. The lifetimes of > all these things are flat-out broken. udl tries to at least wrap some > duct-tape around it, and Noralf greatly improved the situation in the > past year at least. > > So still not seeing what exactly the massive blocker here is. The fact that I can unload armada drm/tda998x modules without incident today, and have done many times through development, and I don't wish to regress from that position. As far as I'm concerned, this is a solved problem, but the pressure I'm under to convert tda998x to a bridge driver is causing bugs that I've already solved by _not_ using that to be introduced. You've mentioned in your previous mail about me not trying to solve the situation - I have tried, I've proposed a way around the component vs bridge issue but I don't think it went anywhere. If I can't get traction on issues, then I can only state what the current state of affairs is to folk asking about it. That is _not_ "whinging" about it, that is informing people and being helpful. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: build failure after merge of the drm-misc tree
Hi all,
After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In function
'amdgpu_dm_mode_config_init':
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:1695:30: error:
passing argument 1 of 'drm_atomic_private_obj_init' from incompatible pointer
type [-Werror=incompatible-pointer-types]
drm_atomic_private_obj_init(>dm.atomic_obj,
^~~~
In file included from include/drm/drm_dp_mst_helper.h:27,
from drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h:46,
from drivers/gpu/drm/amd/amdgpu/amdgpu.h:57,
from
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:34:
include/drm/drm_atomic.h:437:53: note: expected 'struct drm_device *' but
argument is of type 'struct drm_private_obj *'
void drm_atomic_private_obj_init(struct drm_device *dev,
~~~^~~
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:1696:9: error:
passing argument 2 of 'drm_atomic_private_obj_init' from incompatible pointer
type [-Werror=incompatible-pointer-types]
>base,
^~~~
In file included from include/drm/drm_dp_mst_helper.h:27,
from drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h:46,
from drivers/gpu/drm/amd/amdgpu/amdgpu.h:57,
from
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:34:
include/drm/drm_atomic.h:438:30: note: expected 'struct drm_private_obj *' but
argument is of type 'struct drm_private_state *'
struct drm_private_obj *obj,
^~~
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:1697:9: error:
passing argument 3 of 'drm_atomic_private_obj_init' from incompatible pointer
type [-Werror=incompatible-pointer-types]
_atomic_state_funcs);
^~
In file included from include/drm/drm_dp_mst_helper.h:27,
from drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h:46,
from drivers/gpu/drm/amd/amdgpu/amdgpu.h:57,
from
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:34:
include/drm/drm_atomic.h:439:32: note: expected 'struct drm_private_state *'
but argument is of type 'struct drm_private_state_funcs *'
struct drm_private_state *state,
~~^
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:1695:2: error: too
few arguments to function 'drm_atomic_private_obj_init'
drm_atomic_private_obj_init(>dm.atomic_obj,
^~~
In file included from include/drm/drm_dp_mst_helper.h:27,
from drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h:46,
from drivers/gpu/drm/amd/amdgpu/amdgpu.h:57,
from
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:34:
include/drm/drm_atomic.h:437:6: note: declared here
void drm_atomic_private_obj_init(struct drm_device *dev,
^~~
Caused by commit
b962a12050a3 ("drm/atomic: integrate modeset lock with private objects")
interacting with commit
eb3dc8978596 ("drm/amd/display: Use private obj helpers for dm_atomic_state")
from Linus' tree (merged during the merge window).
Its not obvious how to fix this up, so I have used the drm-misc tree
from next-20190107 for today.
--
Cheers,
Stephen Rothwell
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109229] glLinkProgram locks up for ~30 seconds
https://bugs.freedesktop.org/show_bug.cgi?id=109229 --- Comment #3 from Timothy Arceri --- (In reply to smt from comment #2) > This issue seems to be affecting me too, some people say it's been fixed in > 18.2.3/.4 however I'm running 18.3.1 and definitely have the same symptoms > in regards to Godot freezing up, I don't know much so can't be more help, > there seems to be some discussion relating to the issue here though: > > https://bugzilla.redhat.com/show_bug.cgi?id=1646888 Are you sure that is the same bug? That one wasn't a Mesa bug it was a bug in GCC. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: build warning after merge of the drm-misc tree
Hi all,
After merging the drm-misc tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
drivers/gpu/drm/msm/msm_gem.c: In function 'describe_fence':
drivers/gpu/drm/msm/msm_gem.c:761:36: warning: format '%u' expects argument of
type 'unsigned int', but argument 6 has type 'u64' {aka 'long long unsigned
int'} [-Wformat=]
seq_printf(m, "\t%9s: %s %s seq %u\n", type,
~^
%llu
drivers/gpu/drm/msm/msm_gem.c:764:5:
fence->seqno);
Introduced by commit
b312d8ca3a7c ("dma-buf: make fence sequence numbers 64 bit v2")
--
Cheers,
Stephen Rothwell
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbdev: offb: Fix OF node name handling
On Mon, Jan 7, 2019 at 2:36 PM Mathieu Malaterre wrote:
>
> Hi Rob,
>
> On Mon, Jan 7, 2019 at 9:11 PM Mathieu Malaterre wrote:
> >
> > On Mon, Jan 7, 2019 at 6:31 PM Rob Herring wrote:
> > >
> > > Commit 5c63e407aaab ("fbdev: Convert to using %pOFn instead of
> > > device_node.name") changed how the OF FB driver handles the OF node
> > > name. This missed the case where the node name is passed to
> > > offb_init_palette_hacks(). This results in a NULL ptr dereference
> > > in strncmp and breaks any system except ones using bootx with no display
> > > node.
> > >
> > > Fix this by making offb_init_palette_hacks() use the OF node pointer and
> > > use of_node_name_prefix() helper function instead for node name
> > > comparisons. This helps in moving all OF node name accesses to helper
> > > functions in preparation to remove struct device_node.name pointer.
> > >
> > > Fixes: 5c63e407aaab ("fbdev: Convert to using %pOFn instead of
> > > device_node.name")
> >
> > Looks good to me:
> >
> > ...
> > [0.00] Linux version 5.0.0-rc1+ (ma...@debian.org) (gcc
> > version 6.3.0 20170516 (Debian 6.3.0-18)) #21 Mon Jan 7 21:03:53 CET
> > 2019
> > ...
> >
> > So here is my :
> >
> > Tested-by: Mathieu Malaterre
>
> Just for curiosity, why would you keep:
>
> if (strcmp(dp->name, "valkyrie") == 0)
Mainly just because I already have another patch to do that which I
haven't sent out.
Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: build warnings after merge of the drm-intel tree
Hi all,
After merging the drm-intel tree, today's linux-next build (x86_64
allmodconfig) produced these warnings:
In file included from include/linux/printk.h:7,
from include/linux/kernel.h:14,
from include/asm-generic/bug.h:18,
from arch/x86/include/asm/bug.h:83,
from include/linux/bug.h:5,
from include/linux/mmdebug.h:5,
from include/linux/gfp.h:5,
from include/linux/slab.h:15,
from include/linux/io-mapping.h:22,
from drivers/gpu/drm/i915/i915_drv.h:36,
from drivers/gpu/drm/i915/intel_hangcheck.c:25:
drivers/gpu/drm/i915/selftests/intel_hangcheck.c: In function
'igt_atomic_reset_engine':
include/linux/kern_levels.h:5:18: warning: format '%llx' expects argument of
type 'long long unsigned int', but argument 4 has type 'unsigned int'
[-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^~
include/linux/kern_levels.h:11:18: note: in expansion of macro 'KERN_SOH'
#define KERN_ERR KERN_SOH "3" /* error conditions */
^~~~
include/linux/printk.h:303:9: note: in expansion of macro 'KERN_ERR'
printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
^~~~
drivers/gpu/drm/i915/selftests/intel_hangcheck.c:1564:3: note: in expansion of
macro 'pr_err'
pr_err("%s(%s): Failed to start request %llx, at %x\n",
^~
In file included from drivers/gpu/drm/i915/intel_hangcheck.c:315:
drivers/gpu/drm/i915/selftests/intel_hangcheck.c:1564:46: note: format string
is defined here
pr_err("%s(%s): Failed to start request %llx, at %x\n",
~~~^
%x
Introduced by commit
921f3a60e54e ("drm/i915/selftests: Verify we can perform resets from atomic
context")
--
Cheers,
Stephen Rothwell
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109234] amdgpu random hangs with 4.21+
https://bugs.freedesktop.org/show_bug.cgi?id=109234 --- Comment #5 from bmil...@gmail.com --- got it playing a steam game in wine now, but still can't reproduce reliably: jan 07 21:27:20 mjb kernel: BUG: unable to handle kernel paging request at 8e0b4c00 jan 07 21:27:20 mjb kernel: #PF error: [WRITE] jan 07 21:27:20 mjb kernel: PGD 0 P4D 0 jan 07 21:27:20 mjb kernel: Oops: 0002 [#1] SMP NOPTI jan 07 21:27:20 mjb kernel: CPU: 1 PID: 18040 Comm: Steam.exe Tainted: G O 5.0.0-1-tkg-cfs #1 jan 07 21:27:20 mjb kernel: Hardware name: System manufacturer System Product Name/TUF B450M-PLUS GAMING, BIOS 0604 12/07/2018 jan 07 21:27:20 mjb kernel: RIP: 0010:__memcpy+0x12/0x20 jan 07 21:27:20 mjb kernel: Code: 48 89 c8 e9 f9 fc ff ff 48 89 f0 e9 f1 fc ff ff 90 90 90 90 90 90 90 90 0f 1f 44 00 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 48 a5 89 d1 f3 a4 c3 66> jan 07 21:27:20 mjb kernel: RSP: 0018:c90001b73cc0 EFLAGS: 00210246 jan 07 21:27:20 mjb kernel: RAX: 8e0b4c00 RBX: 888105fd80b0 RCX: 0200 jan 07 21:27:20 mjb kernel: RDX: RSI: 8880d50f RDI: 8e0b4c00 jan 07 21:27:20 mjb kernel: RBP: R08: R09: 0001 jan 07 21:27:20 mjb kernel: R10: ea000d8bf580 R11: 888143d89710 R12: 1000 jan 07 21:27:20 mjb kernel: R13: R14: d50f R15: 8883fcaefd28 jan 07 21:27:20 mjb kernel: FS: 7ffd8000(0063) GS:88840ea4(006b) knlGS:f7b810c0 jan 07 21:27:20 mjb kernel: CS: 0010 DS: 002b ES: 002b CR0: 80050033 jan 07 21:27:20 mjb kernel: CR2: 8e0b4c00 CR3: 00033c70 CR4: 003406e0 jan 07 21:27:20 mjb kernel: Call Trace: jan 07 21:27:20 mjb kernel: dma_direct_unmap_page+0x92/0xa0 jan 07 21:27:20 mjb kernel: ttm_unmap_and_unpopulate_pages+0x148/0x170 [ttm] jan 07 21:27:20 mjb kernel: ttm_tt_destroy+0x81/0xd0 [ttm] jan 07 21:27:20 mjb kernel: ttm_bo_put+0x262/0x2f0 [ttm] jan 07 21:27:20 mjb kernel: amdgpu_bo_unref+0x1a/0x30 [amdgpu] jan 07 21:27:20 mjb kernel: amdgpu_gem_object_free+0x23/0x30 [amdgpu] jan 07 21:27:20 mjb kernel: drm_gem_handle_delete+0x9e/0x130 [drm] jan 07 21:27:20 mjb kernel: ? drm_gem_handle_create+0x40/0x40 [drm] jan 07 21:27:20 mjb kernel: drm_ioctl_kernel+0x8b/0xd0 [drm] jan 07 21:27:20 mjb kernel: drm_ioctl+0x1e5/0x390 [drm] jan 07 21:27:20 mjb kernel: ? drm_gem_handle_create+0x40/0x40 [drm] jan 07 21:27:20 mjb kernel: ? kmem_cache_free+0x18e/0x1b0 jan 07 21:27:20 mjb kernel: ? remove_vma_list+0xe6/0x140 jan 07 21:27:20 mjb kernel: ? __do_munmap.constprop.9+0x263/0x3a0 jan 07 21:27:20 mjb kernel: __se_compat_sys_ioctl+0x2e3/0xe10 jan 07 21:27:20 mjb kernel: ? __ia32_sys_munmap+0x75/0x90 jan 07 21:27:20 mjb kernel: do_fast_syscall_32+0x98/0x210 jan 07 21:27:20 mjb kernel: entry_SYSCALL_compat_after_hwframe+0x45/0x4d jan 07 21:27:20 mjb kernel: Modules linked in: edac_mce_amd kvm_amd kvm snd_hda_codec_realtek amdgpu irqbypass snd_hda_codec_generic ledtrig_audio chash snd_hda_codec_hdmi amd_iommu_v2 gpu> jan 07 21:27:20 mjb kernel: CR2: 8e0b4c00 jan 07 21:27:20 mjb kernel: ---[ end trace b2ffa643a20c80fe ]--- jan 07 21:27:20 mjb kernel: RIP: 0010:__memcpy+0x12/0x20 jan 07 21:27:20 mjb kernel: Code: 48 89 c8 e9 f9 fc ff ff 48 89 f0 e9 f1 fc ff ff 90 90 90 90 90 90 90 90 0f 1f 44 00 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 48 a5 89 d1 f3 a4 c3 66> jan 07 21:27:20 mjb kernel: RSP: 0018:c90001b73cc0 EFLAGS: 00210246 jan 07 21:27:20 mjb kernel: RAX: 8e0b4c00 RBX: 888105fd80b0 RCX: 0200 jan 07 21:27:20 mjb kernel: RDX: RSI: 8880d50f RDI: 8e0b4c00 jan 07 21:27:20 mjb kernel: RBP: R08: R09: 0001 jan 07 21:27:20 mjb kernel: R10: ea000d8bf580 R11: 888143d89710 R12: 1000 jan 07 21:27:20 mjb kernel: R13: R14: d50f R15: 8883fcaefd28 jan 07 21:27:20 mjb kernel: FS: 7ffd8000(0063) GS:88840ea4(006b) knlGS:f7b810c0 jan 07 21:27:20 mjb kernel: CS: 0010 DS: 002b ES: 002b CR0: 80050033 jan 07 21:27:20 mjb kernel: CR2: 8e0b4c00 CR3: 00033c70 CR4: 003406e0 jan 07 21:27:22 mjb kernel: general protection fault: [#2] SMP NOPTI jan 07 21:27:22 mjb kernel: CPU: 0 PID: 649 Comm: Xorg Tainted: G DO 5.0.0-1-tkg-cfs #1 jan 07 21:27:22 mjb kernel: Hardware name: System manufacturer System Product Name/TUF B450M-PLUS GAMING, BIOS 0604 12/07/2018 jan 07 21:27:22 mjb kernel: RIP: 0010:__memcpy+0x12/0x20 jan 07 21:27:22 mjb kernel: Code: 48 89 c8 e9 f9 fc ff ff 48 89 f0 e9 f1 fc ff ff 90 90 90 90 90 90 90 90 0f 1f 44 00 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 48 a5 89 d1 f3 a4 c3 66> jan 07 21:27:22 mjb kernel: RSP: 0018:c90002203c30 EFLAGS: 00010246 jan 07 21:27:22 mjb kernel: RAX: c930ce4031168b49 RBX: 888105fd80b0 RCX: 0200 jan 07 21:27:22
[Bug 109178] Keyboard backlight on Samsung Np900X5N not working due to not loading samsung-laptop.ko module
https://bugs.freedesktop.org/show_bug.cgi?id=109178 Jan changed: What|Removed |Added Resolution|NOTOURBUG |FIXED --- Comment #11 from Jan --- Just for the sake of record I found the solution: The (UEFI based) kernel creates /sys/firmware/efi/efivars with the variable: KBDBacklitLvl-5af56f53-985c-47d5-920c-f1c531d06852 The set immutable flag can be disabled with: chattr -i /sys/firmware/efi/efivars/KBDBacklitLvl-5af56f53-985c-47d5-920c-f1c531d06852 After that the variable can be altered from 00 - 03: echo 070002 | xxd -p -r > /sys/firmware/efi/efivars/KBDBacklitLvl-5af56f53-985c-47d5-920c-f1c531d06852 (GUID dependent on the manufacturer) 00 - Backlight off (always) 01 - Backlight on DIM level (by low ambient light; detected by light sensor) 02 - Backlight on NORM level (by low ambient light) 03 - Backlight on FULL level (by low ambient light) Inspired by: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1203592 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [DPU PATCH v2 3/3] drm/msm/dp: add support for DP PLL driver
Hi Chandan
A few comments in the following.
Mostly nitpicks / style stuff, not a throughly review.
Sam
> +config DRM_MSM_DP_PLL
> + bool "Enable DP PLL driver in MSM DRM"
So DRM_MSM_DP_PLL cannot be 'm'.
> --- a/drivers/gpu/drm/msm/Makefile
> +++ b/drivers/gpu/drm/msm/Makefile
> @@ -137,4 +137,10 @@ msm-$(CONFIG_DRM_MSM_DSI_14NM_PHY) +=
> dsi/pll/dsi_pll_14nm.o
> msm-$(CONFIG_DRM_MSM_DSI_10NM_PHY) += dsi/pll/dsi_pll_10nm.o
> endif
>
> +ifeq ($(CONFIG_DRM_MSM_DP_PLL),y)
> +msm-y += dp/pll/dp_pll.o
> +msm-y += dp/pll/dp_pll_10nm.o
> +msm-y += dp/pll/dp_pll_10nm_util.o
> +endif
Please write this in the Kbuild caninical style like this:
msm-$(DRM_MSM_DP_PLL) += dp/pll/dp_pll.o
msm-$(DRM_MSM_DP_PLL) += dp/pll/dp_pll_10nm.o
etc.
Or even better - descend into msm/dp/pll to build it - this is normal kernel
style.
> + if (!dp_parser) {
> + DRM_ERROR("Parser not initialized.\n");
> + return -EINVAL;
> + }
> +
> + pll_node = of_parse_phandle(pdev->dev.of_node, "pll-node", 0);
> + if (!pll_node) {
> + DRM_DEV_ERROR(>dev, "cannot find pll device\n");
> + return -ENXIO;
> + }
> +
> + pll_pdev = of_find_device_by_node(pll_node);
> + if (pll_pdev)
> + dp_parser->pll = platform_get_drvdata(pll_pdev);
> +
> + of_node_put(pll_node);
> +
> + if (!pll_pdev || !dp_parser->pll) {
> + DRM_DEV_ERROR(>dev, "%s: pll driver is not ready\n",
> __func__);
> + return -EPROBE_DEFER;
> + }
The use of DRM_*ERROR is inconsistent.
In one place DRM_ERROR is used, and string ends with '.'
In one place DRM_DEV_ERROR is used with a simple string.
In one place DRM_DEV_ERROR is used where the __func__ is added as parameter.
When reading the code such inconsistencies makes it harder to follow the code.
> +
> + dp_parser->pll_dev = get_device(_pdev->dev);
> +
> + return 0;
> +}
> +
> static irqreturn_t dp_display_irq(int irq, void *dev_id)
> {
> struct dp_display_private *dp = dev_id;
> @@ -114,6 +156,12 @@ static int dp_display_bind(struct device *dev, struct
> device *master,
> goto end;
> }
>
> + rc = dp_get_pll(dp);
> + if (rc) {
> + DRM_ERROR(" DP get PLL instance failed\n");
Any reason why the error is indented with a space?
Also, is the DRM*ERROR in dp_get_pll() not enough?
> diff --git a/drivers/gpu/drm/msm/dp/dp_power.h
> b/drivers/gpu/drm/msm/dp/dp_power.h
> index 76e2d3b..40d7e73 100644
> --- a/drivers/gpu/drm/msm/dp/dp_power.h
> +++ b/drivers/gpu/drm/msm/dp/dp_power.h
> @@ -14,6 +14,7 @@
> * @init: initializes the regulators/core clocks/GPIOs/pinctrl
> * @deinit: turns off the regulators/core clocks/GPIOs/pinctrl
> * @clk_enable: enable/disable the DP clocks
> + * @set_link_clk_parent: set the parent of DP link clock
> * @set_pixel_clk_parent: set the parent of DP pixel clock
> */
> struct dp_power {
This chunk is unrelated - it just added some missing doc.
Do it belong in another patch?
> diff --git a/drivers/gpu/drm/msm/dp/pll/dp_pll.c
> b/drivers/gpu/drm/msm/dp/pll/dp_pll.c
> new file mode 100644
> index 000..28f0e92
> --- /dev/null
> +++ b/drivers/gpu/drm/msm/dp/pll/dp_pll.c
> @@ -0,0 +1,145 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2016-2019, The Linux Foundation. All rights reserved.
> + */
> +
> +#include "dp_pll.h"
> +
> +int msm_dp_pll_util_parse_dt_clock(struct platform_device *pdev,
> + struct msm_dp_pll *pll)
> +{
> + u32 i = 0, rc = 0;
> + struct dss_module_power *mp = >mp;
> + const char *clock_name;
> + u32 clock_rate;
> +
> + mp->num_clk = of_property_count_strings(pdev->dev.of_node,
> + "clock-names");
> + if (mp->num_clk <= 0) {
> + DRM_ERROR("clocks are not defined\n");
> + goto clk_err;
> + }
You have a pdev->dev, so use DRM_DEV_ERROR()
> +
> +struct msm_dp_pll *msm_dp_pll_init(struct platform_device *pdev,
> + enum msm_dp_pll_type type, int id)
> +{
> + struct device *dev = >dev;
> + struct msm_dp_pll *pll;
> +
> + switch (type) {
> + case MSM_DP_PLL_10NM:
> + pll = msm_dp_pll_10nm_init(pdev, id);
> + break;
> + default:
> + pll = ERR_PTR(-ENXIO);
> + break;
> + }
> +
> + if (IS_ERR(pll)) {
> + DRM_DEV_ERROR(dev, "%s: failed to init DP PLL\n", __func__);
> + return pll;
> + }
> +
> + pll->type = type;
> +
> + DBG("DP:%d PLL registered", id);
Avoid rolling your own DEBUG macros.
> +}
> +
> +static const struct of_device_id dp_pll_dt_match[] = {
> +#ifdef CONFIG_DRM_MSM_DP_10NM_PLL
> + { .compatible = "qcom,dp-pll-10nm" },
> +#endif
> + {}
> +};
We only have one entry here.
> +
> +static int dp_pll_driver_probe(struct platform_device *pdev)
> +{
> + struct msm_dp_pll *pll;
> +
[Bug 109234] amdgpu random hangs with 4.21+
https://bugs.freedesktop.org/show_bug.cgi?id=109234 --- Comment #4 from bmil...@gmail.com --- I havent triggered it again yet in 5.0-rc1 after a bios update, lets see what happens in next few days. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Armada DRM: bridge with componentized devices
On Mon, Jan 7, 2019 at 5:27 PM Andrzej Hajda wrote: > > On 07.01.2019 17:08, Daniel Vetter wrote: > > On Mon, Jan 07, 2019 at 12:26:58PM +0100, Andrzej Hajda wrote: > >> On 07.01.2019 11:45, Daniel Vetter wrote: > >>> On Thu, Jan 03, 2019 at 01:11:47PM +, Russell King - ARM Linux wrote: > On Thu, Jan 03, 2019 at 10:47:27AM +0100, Lubomir Rintel wrote: > > Hello, > > > > lately I've been trying to make the Himax HX8837 chip that drives the > > OLPC > > LCD display work with Armada DRM driver. I've been advised to create a > > bridge driver and not an encoder driver since the silicon is separate > > from > > the LCDC. > > > > The Armada DRM driver (and, I think, the i.MX one) creates the > > drm_device > > once the component infrastructure sees the necessary sub-devices appear. > > The sub-devices being the LCDCs and the encoders (not bridges) that it > > expects to be created externally. > > > > Currently, it seems, the only driver that can actually work with this > > (that > > is -- creates a drm_encoder for a drm_device when the component is > > bound) > > is the tda998x. All other similar drivers create a drm_bridge instead > > and > > not use the component infrastructure at all. (In fact, tilcdc driver > > contains a hack to handle tda998x specially.) > > > > I'm wondering how to reconcile the two? > > > > * The tda998x driver has recently been modified to create a bridge on > > probe > > and eventually encoder on component bind. Is this an okay thing to do > > in > > a new driver? (this probably means the tilcdc hack can be removed...) > > > > * If a non-componentized bridge were to be used (along with a dummy > > encoder), at what point would it make sense to look for the bridge? > > Would it be a good idea to defer the probe of crtc until a bridge can > > be > > looked up and the attach it on component bind? What if the bridge > > goes > > away (a module is unloaded, etc.) in between? > > > > I'd be thankful for opintions and advice before I move ahead with this. > This is the long-standing problem with the conflict between bridge > support and component support, and I'm not sure that there is really > any answer to it. > > I've gone into the details of the two several times on the list, > particularly about the short-comings of the bridge approach, but it > seems no one cares to fix those short-comings. > > You are re-identifying some of the issues that I've already pointed > out - such as what happens to DRM drives when the bridge driver is > unbound (it's really not about modules being unloaded, and the problem > can't be solved by taking a module reference count - all that the > module reference count does is ensure that the module doesn't go > away unexpected, there is no way to ensure that the device isn't > unbound.) > > The issue of unbinding is precisely the issue which the component > support was created to solve - but everyone seems to prefer the buggy > bridge approach, and no one seems willing to do anything about the > bugs or even acknowledge that it's a problem. It's strange - if one > identifies bugs that result in kernel oops in other kernel subsystems, > one is generally taken seriously and the problem is solved. > >>> Unbinding is really not the most important feature, especially for SoC. If > >>> you feel different, working together with others, getting some agreement, > >>> getting the patches reviewed and finding someone to get them merged is > >>> very much appreciated. But just complaining won't move this forward. > >>> > The issue about the encoders is something that I've tried to discuss, > and I've pointed out that moving it into the DRM driver adds additional > complexity there, and I'd hoped that my patch set I posted would've > generated discussion, but alas not. > > What I'm not prepared to do is to introduce _known_ bugs into any > driver that I maintain. > >>> I thought last time around the idea was to use device links (and teach > >>> drm_bridge about them), so that the unloading works correctly. > >> > >> With current device_links implementation registering links in probe of > >> the consumer is just incorrect - it can happen that neither consumer > >> neither provider is fully probed and creating device links in such state > >> is wrong according to docs, and my experiments. See [1] for discussion > >> and [2] for docs. > > We could set up the device link only at drm_dev_register time. At that point > > we know that driver loading has fully succeeded. We do have a list of > > bridges at hand, so that's not going to be an issue. > > > > The only case where this breaks is if a driver is still using the > > deprecated ->load
Re: Armada DRM: bridge with componentized devices
On Mon, Jan 7, 2019 at 5:13 PM Russell King - ARM Linux wrote: > > On Mon, Jan 07, 2019 at 11:45:32AM +0100, Daniel Vetter wrote: > > On Thu, Jan 03, 2019 at 01:11:47PM +, Russell King - ARM Linux wrote: > > > This is the long-standing problem with the conflict between bridge > > > support and component support, and I'm not sure that there is really > > > any answer to it. > > > > > > I've gone into the details of the two several times on the list, > > > particularly about the short-comings of the bridge approach, but it > > > seems no one cares to fix those short-comings. > > > > > > You are re-identifying some of the issues that I've already pointed > > > out - such as what happens to DRM drives when the bridge driver is > > > unbound (it's really not about modules being unloaded, and the problem > > > can't be solved by taking a module reference count - all that the > > > module reference count does is ensure that the module doesn't go > > > away unexpected, there is no way to ensure that the device isn't > > > unbound.) > > > > > > The issue of unbinding is precisely the issue which the component > > > support was created to solve - but everyone seems to prefer the buggy > > > bridge approach, and no one seems willing to do anything about the > > > bugs or even acknowledge that it's a problem. It's strange - if one > > > identifies bugs that result in kernel oops in other kernel subsystems, > > > one is generally taken seriously and the problem is solved. > > > > Unbinding is really not the most important feature, especially for SoC. If > > you feel different, working together with others, getting some agreement, > > getting the patches reviewed and finding someone to get them merged is > > very much appreciated. But just complaining won't move this forward. > > Sorry, I disagree. Unbinding is important if the current state results > in crashes and oops - the lack of unbinding support in bridge makes it > harder to develop without constantly rebooting the target machine. > > If all you care about is the end user who probably never removes a > module, then yes, it's low priority, but if you care about efficient > development, then the story is rather different. Unloading i915 needs a very careful script, or you'll get a rather bright fireworks. Afaik all other drm drivers (except maybe udl) are the same. At least if you do anything fancy, where fancy includes: fbdev emulation, prime buffer sharing, shared dma fences, or well anything really that goes beyond a dummy boot splash. The lifetimes of all these things are flat-out broken. udl tries to at least wrap some duct-tape around it, and Noralf greatly improved the situation in the past year at least. So still not seeing what exactly the massive blocker here is. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109229] glLinkProgram locks up for ~30 seconds
https://bugs.freedesktop.org/show_bug.cgi?id=109229 --- Comment #2 from smt --- This issue seems to be affecting me too, some people say it's been fixed in 18.2.3/.4 however I'm running 18.3.1 and definitely have the same symptoms in regards to Godot freezing up, I don't know much so can't be more help, there seems to be some discussion relating to the issue here though: https://bugzilla.redhat.com/show_bug.cgi?id=1646888 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[DPU PATCH v2 3/3] drm/msm/dp: add support for DP PLL driver
Add the needed DP PLL specific files to support
display port interface on msm targets.
The DP driver calls the DP PLL driver registration.
The DP driver sets the link and pixel clock sources.
Changes in v2:
-- Update copyright markings on all relevant files.
-- Use DRM_DEBUG_DP for debug msgs.
Signed-off-by: Chandan Uddaraju
---
drivers/gpu/drm/msm/Kconfig | 15 +
drivers/gpu/drm/msm/Makefile | 6 +
drivers/gpu/drm/msm/dp/dp_display.c | 50 +++
drivers/gpu/drm/msm/dp/dp_display.h | 3 +
drivers/gpu/drm/msm/dp/dp_parser.h| 3 +
drivers/gpu/drm/msm/dp/dp_power.h | 1 +
drivers/gpu/drm/msm/dp/pll/dp_pll.c | 145 +++
drivers/gpu/drm/msm/dp/pll/dp_pll.h | 56 +++
drivers/gpu/drm/msm/dp/pll/dp_pll_10nm.c | 393 +++
drivers/gpu/drm/msm/dp/pll/dp_pll_10nm.h | 86 +
drivers/gpu/drm/msm/dp/pll/dp_pll_10nm_util.c | 522 ++
11 files changed, 1280 insertions(+)
create mode 100644 drivers/gpu/drm/msm/dp/pll/dp_pll.c
create mode 100644 drivers/gpu/drm/msm/dp/pll/dp_pll.h
create mode 100644 drivers/gpu/drm/msm/dp/pll/dp_pll_10nm.c
create mode 100644 drivers/gpu/drm/msm/dp/pll/dp_pll_10nm.h
create mode 100644 drivers/gpu/drm/msm/dp/pll/dp_pll_10nm_util.c
diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index c6b2e07..2168432 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -58,6 +58,21 @@ config DRM_MSM_DP
display support is enabled through this config option. It can
be primary or secondary display on device.
+config DRM_MSM_DP_PLL
+ bool "Enable DP PLL driver in MSM DRM"
+ depends on DRM_MSM_DP && COMMON_CLK
+ default y
+ help
+ Choose this option to enable DP PLL driver which provides DP
+ source clocks under common clock framework.
+
+config DRM_MSM_DP_10NM_PLL
+ bool "Enable DP 10nm PLL driver in MSM DRM (used by SDM845)"
+ depends on DRM_MSM_DP
+ default y
+ help
+ Choose this option if DP PLL on SDM845 is used on the platform.
+
config DRM_MSM_DSI
bool "Enable DSI support in MSM DRM driver"
depends on DRM_MSM
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 45166ef..77f45b1 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -137,4 +137,10 @@ msm-$(CONFIG_DRM_MSM_DSI_14NM_PHY) +=
dsi/pll/dsi_pll_14nm.o
msm-$(CONFIG_DRM_MSM_DSI_10NM_PHY) += dsi/pll/dsi_pll_10nm.o
endif
+ifeq ($(CONFIG_DRM_MSM_DP_PLL),y)
+msm-y += dp/pll/dp_pll.o
+msm-y += dp/pll/dp_pll_10nm.o
+msm-y += dp/pll/dp_pll_10nm_util.o
+endif
+
obj-$(CONFIG_DRM_MSM) += msm.o
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 1b0682a..212e247 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -61,6 +61,48 @@ struct dp_display_private {
{}
};
+static int dp_get_pll(struct dp_display_private *dp_priv)
+{
+ struct platform_device *pdev = NULL;
+ struct platform_device *pll_pdev;
+ struct device_node *pll_node;
+ struct dp_parser *dp_parser = NULL;
+
+ if (!dp_priv) {
+ DRM_ERROR("Invalid Arguments\n");
+ return -EINVAL;
+ }
+
+ pdev = dp_priv->pdev;
+ dp_parser = dp_priv->parser;
+
+ if (!dp_parser) {
+ DRM_ERROR("Parser not initialized.\n");
+ return -EINVAL;
+ }
+
+ pll_node = of_parse_phandle(pdev->dev.of_node, "pll-node", 0);
+ if (!pll_node) {
+ DRM_DEV_ERROR(>dev, "cannot find pll device\n");
+ return -ENXIO;
+ }
+
+ pll_pdev = of_find_device_by_node(pll_node);
+ if (pll_pdev)
+ dp_parser->pll = platform_get_drvdata(pll_pdev);
+
+ of_node_put(pll_node);
+
+ if (!pll_pdev || !dp_parser->pll) {
+ DRM_DEV_ERROR(>dev, "%s: pll driver is not ready\n",
__func__);
+ return -EPROBE_DEFER;
+ }
+
+ dp_parser->pll_dev = get_device(_pdev->dev);
+
+ return 0;
+}
+
static irqreturn_t dp_display_irq(int irq, void *dev_id)
{
struct dp_display_private *dp = dev_id;
@@ -114,6 +156,12 @@ static int dp_display_bind(struct device *dev, struct
device *master,
goto end;
}
+ rc = dp_get_pll(dp);
+ if (rc) {
+ DRM_ERROR(" DP get PLL instance failed\n");
+ goto end;
+ }
+
rc = dp_aux_register(dp->aux);
if (rc) {
DRM_ERROR("DRM DP AUX register failed\n");
@@ -804,6 +852,7 @@ int __init msm_dp_register(void)
{
int ret;
+ msm_dp_pll_driver_register();
ret = platform_driver_register(_display_driver);
if (ret) {
DRM_ERROR("driver register failed");
@@ -815,6 +864,7 @@ int __init
[DPU PATCH v2 1/3] dt-bindings: msm/dp: add bindings of DP/DP-PLL driver for Snapdragon 845
Add bindings for Snapdragon 845 DisplayPort and display-port PLL driver. Changes in V2: Provide details about sel-gpio Signed-off-by: Chandan Uddaraju --- .../devicetree/bindings/display/msm/dp.txt | 249 + .../devicetree/bindings/display/msm/dpu.txt| 16 +- 2 files changed, 261 insertions(+), 4 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/msm/dp.txt diff --git a/Documentation/devicetree/bindings/display/msm/dp.txt b/Documentation/devicetree/bindings/display/msm/dp.txt new file mode 100644 index 000..38be36d --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/dp.txt @@ -0,0 +1,249 @@ +Qualcomm Technologies, Inc. +DP is the master Display Port device which supports DP host controllers that are compatible with VESA Display Port interface specification. +DP Controller: Required properties: +- compatible: Should be "qcom,dp-display". +- reg: Base address and length of DP hardware's memory mapped regions. +- cell-index: Specifies the controller instance. +- reg-names:A list of strings that name the list of regs. + "dp_ahb" - DP controller memory region. + "dp_aux" - DP AUX memory region. + "dp_link" - DP link layer memory region. + "dp_p0" - DP pixel clock domain memory region. + "dp_phy" - DP PHY memory region. + "dp_ln_tx0" - USB3 DP PHY combo TX-0 lane memory region. + "dp_ln_tx1" - USB3 DP PHY combo TX-1 lane memory region. + "dp_mmss_cc" - Display Clock Control memory region. + "qfprom_physical" - QFPROM Phys memory region. + "dp_pll" - USB3 DP combo PLL memory region. + "usb3_dp_com" - USB3 DP PHY combo memory region. + "hdcp_physical" - DP HDCP memory region. +- interrupt-parent phandle to the interrupt parent device node. +- interrupts: The interrupt signal from the DP block. +- clocks: Clocks required for Display Port operation. See [1] for details on clock bindings. +- clock-names: Names of the clocks corresponding to handles. Following clocks are required: + "core_aux_clk", "core_usb_ref_clk_src","core_usb_ref_clk", "core_usb_cfg_ahb_clk", + "core_usb_pipe_clk", "ctrl_link_clk", "ctrl_link_iface_clk", "ctrl_crypto_clk", + "ctrl_pixel_clk", "pixel_clk_rcg", "pixel_parent". +- pll-node:phandle to DP PLL node. +- vdda-1p2-supply: phandle to vdda 1.2V regulator node. +- vdda-0p9-supply: phandle to vdda 0.9V regulator node. +- qcom,aux-cfg0-settings: Specifies the DP AUX configuration 0 settings. The first + entry in this array corresponds to the register offset + within DP AUX, while the remaining entries indicate the + programmable values. +- qcom,aux-cfg1-settings: Specifies the DP AUX configuration 1 settings. The first + entry in this array corresponds to the register offset + within DP AUX, while the remaining entries indicate the + programmable values. +- qcom,aux-cfg2-settings: Specifies the DP AUX configuration 2 settings. The first + entry in this array corresponds to the register offset + within DP AUX, while the remaining entries indicate the + programmable values. +- qcom,aux-cfg3-settings: Specifies the DP AUX configuration 3 settings. The first + entry in this array corresponds to the register offset + within DP AUX, while the remaining entries indicate the + programmable values. +- qcom,aux-cfg4-settings: Specifies the DP AUX configuration 4 settings. The first + entry in this array corresponds to the register offset + within DP AUX, while the remaining entries indicate the + programmable values. +- qcom,aux-cfg5-settings: Specifies the DP AUX configuration 5 settings. The first + entry in this array corresponds to the register offset + within DP AUX, while the remaining entries indicate the + programmable values. +- qcom,aux-cfg6-settings: Specifies the DP AUX
[DPU PATCH v2 0/3] List of patches for DP drivers on SnapDragon
These patches are to enable DisplayPort driver on SanpDragon. These patches have dependency on clock driver changes that provide DP clock support. Changes in V2: Core Dp driver: -- Update copyright markings on all relevant files. -- Change pr_err() to DRM_ERROR() -- Use APIs directly instead of function pointers. -- Use drm_display_mode structure to store link parameters in the driver. -- Use macros for register definitions instead of hardcoded values in dp_catalog.c file. -- Replace writel_relaxed/readl_relaxed with writel/readl and remove memory barriers. -- Remove unnecessary NULL checks. -- Use drm helper functions for dpcd read/write. -- Use DRM_DEBUG_DP for debug msgs. DP PLL driver: -- Update copyright markings on all relevant files. -- Use DRM_DEBUG_DP for debug msgs. Chandan Uddaraju (3): dt-bindings: msm/dp: add bindings of DP/DP-PLL driver for Snapdragon 845 drm/msm/dp: add displayPort driver support drm/msm/dp: add support for DP PLL driver .../devicetree/bindings/display/msm/dp.txt | 249 +++ .../devicetree/bindings/display/msm/dpu.txt| 16 +- drivers/gpu/drm/msm/Kconfig| 24 + drivers/gpu/drm/msm/Makefile | 18 + drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 20 + drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c|2 + drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.h| 26 + drivers/gpu/drm/msm/dp/dp_aux.c| 548 +++ drivers/gpu/drm/msm/dp/dp_aux.h| 37 + drivers/gpu/drm/msm/dp/dp_catalog.c| 996 drivers/gpu/drm/msm/dp/dp_catalog.h| 108 ++ drivers/gpu/drm/msm/dp/dp_ctrl.c | 1611 drivers/gpu/drm/msm/dp/dp_ctrl.h | 36 + drivers/gpu/drm/msm/dp/dp_display.c| 991 drivers/gpu/drm/msm/dp/dp_display.h| 31 + drivers/gpu/drm/msm/dp/dp_drm.c| 189 +++ drivers/gpu/drm/msm/dp/dp_drm.h| 20 + drivers/gpu/drm/msm/dp/dp_extcon.c | 228 +++ drivers/gpu/drm/msm/dp/dp_extcon.h | 85 ++ drivers/gpu/drm/msm/dp/dp_link.c | 1216 +++ drivers/gpu/drm/msm/dp/dp_link.h | 132 ++ drivers/gpu/drm/msm/dp/dp_panel.c | 504 ++ drivers/gpu/drm/msm/dp/dp_panel.h | 91 ++ drivers/gpu/drm/msm/dp/dp_parser.c | 621 drivers/gpu/drm/msm/dp/dp_parser.h | 199 +++ drivers/gpu/drm/msm/dp/dp_power.c | 733 + drivers/gpu/drm/msm/dp/dp_power.h | 52 + drivers/gpu/drm/msm/dp/dp_reg.h| 475 ++ drivers/gpu/drm/msm/dp/pll/dp_pll.c| 145 ++ drivers/gpu/drm/msm/dp/pll/dp_pll.h| 56 + drivers/gpu/drm/msm/dp/pll/dp_pll_10nm.c | 393 + drivers/gpu/drm/msm/dp/pll/dp_pll_10nm.h | 86 ++ drivers/gpu/drm/msm/dp/pll/dp_pll_10nm_util.c | 522 +++ drivers/gpu/drm/msm/msm_drv.c |2 + drivers/gpu/drm/msm/msm_drv.h | 41 + 35 files changed, 10499 insertions(+), 4 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/msm/dp.txt create mode 100644 drivers/gpu/drm/msm/dp/dp_aux.c create mode 100644 drivers/gpu/drm/msm/dp/dp_aux.h create mode 100644 drivers/gpu/drm/msm/dp/dp_catalog.c create mode 100644 drivers/gpu/drm/msm/dp/dp_catalog.h create mode 100644 drivers/gpu/drm/msm/dp/dp_ctrl.c create mode 100644 drivers/gpu/drm/msm/dp/dp_ctrl.h create mode 100644 drivers/gpu/drm/msm/dp/dp_display.c create mode 100644 drivers/gpu/drm/msm/dp/dp_display.h create mode 100644 drivers/gpu/drm/msm/dp/dp_drm.c create mode 100644 drivers/gpu/drm/msm/dp/dp_drm.h create mode 100644 drivers/gpu/drm/msm/dp/dp_extcon.c create mode 100644 drivers/gpu/drm/msm/dp/dp_extcon.h create mode 100644 drivers/gpu/drm/msm/dp/dp_link.c create mode 100644 drivers/gpu/drm/msm/dp/dp_link.h create mode 100644 drivers/gpu/drm/msm/dp/dp_panel.c create mode 100644 drivers/gpu/drm/msm/dp/dp_panel.h create mode 100644 drivers/gpu/drm/msm/dp/dp_parser.c create mode 100644 drivers/gpu/drm/msm/dp/dp_parser.h create mode 100644 drivers/gpu/drm/msm/dp/dp_power.c create mode 100644 drivers/gpu/drm/msm/dp/dp_power.h create mode 100644 drivers/gpu/drm/msm/dp/dp_reg.h create mode 100644 drivers/gpu/drm/msm/dp/pll/dp_pll.c create mode 100644 drivers/gpu/drm/msm/dp/pll/dp_pll.h create mode 100644 drivers/gpu/drm/msm/dp/pll/dp_pll_10nm.c create mode 100644 drivers/gpu/drm/msm/dp/pll/dp_pll_10nm.h create mode 100644 drivers/gpu/drm/msm/dp/pll/dp_pll_10nm_util.c -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v2 3/3] ARM: dts: s5pv210: Add node for exynos-rotator
On Fri, Dec 28, 2018 at 04:19:04PM +0100, Paweł Chmiel wrote: > This commit adds node for Exynos Rorator device, > so it can be used on all s5pv210 based devices. > > Signed-off-by: Paweł Chmiel > --- > arch/arm/boot/dts/s5pv210.dtsi | 9 + Thanks, applied. Best regards, Krzysztof ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/rockchip: Fix YUV buffers color rendering
On Mon, 2019-01-07 at 14:26 +0100, Heiko Stuebner wrote:
> Hi,
>
> sorry, only now got to test this on actual hardware,
>
> Am Freitag, 14. Dezember 2018, 17:29:20 CET schrieb Ezequiel Garcia:
> > From: Daniele Castagna
> >
> > Currently, YUV hardware overlays are converted to RGB using
> > a color space conversion different than BT.601.
> >
> > The result is that colors of e.g. NV12 buffers don't match
> > colors of YUV hardware overlays.
> >
> > In order to fix this, enable YUV2YUV and set appropriate coefficients
> > for formats such as NV12 to be displayed correctly.
> >
> > This commit was tested using modetest, gstreamer and chromeos (hardware
> > accelerated video playback). Before the commit, tests rendering
> > with NV12 format resulted in colors not displayed correctly.
> >
> > Test examples (RK3399 Ficus board connected to HDMI monitor):
> >
> > $ modetest 39@32:1920x1080@NV12
> > $ gst-launch-1.0 videotestrc ! video/x-raw,format=NV12 ! kmssink
> >
> > Signed-off-by: Daniele Castagna
> > [ezequiel: rebase on linux-next and massage commit log]
> > Signed-off-by: Ezequiel Garcia
> > ---
> > v2:
> > * Addressed feedback from Sean Paul
> > * Rebased on linux-next
> >
> > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 41 -
> > drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 13 +++
> > drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 36 ++
> > 3 files changed, 89 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > index fb70fb486fbf..78c7f63a60c0 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > @@ -52,6 +52,18 @@
> > vop_reg_set(vop, >phy->scl->ext->name, \
> > win->base, ~0, v, #name)
> >
> > +#define VOP_WIN_YUV2YUV_SET(x, win_yuv2yuv, name, v) \
> > + do { \
> > + if (win_yuv2yuv->name.mask) \
> > + vop_reg_set(vop, _yuv2yuv->name, 0, ~0, v, #name); \
> > + } while (0)
> > +
> > +#define VOP_WIN_YUV2YUV_COEFFICIENT_SET(x, win_yuv2yuv, name, v) \
> > + do { \
> > + if (win_yuv2yuv->phy->name.mask) \
> > + vop_reg_set(vop, _yuv2yuv->phy->name,
> > win_yuv2yuv->base, ~0, v, #name); \
> > + } while (0)
> > +
>
> While this seems to work on rk3399, it hangs both my rk3328 (rock64)
> and rk3288 (google-pinky) during rockchip-drm probe.
>
Oh, shame on me, I should've done that.
> Making this something like
>
> if (win_yuv2yuv && win_yuv2yuv->phy->name.mask) \
>
> aka testing for existence of win_yuv2yuv first, makes them boot again,
> so I guess I ran into a (for whatever reason) silent null-ptr-dereference.
>
Sounds good. I'll post a v3.
>
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> > b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> > index 08fc40af52c8..fe752df4e038 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> > @@ -637,6 +637,34 @@ static const struct vop_output rk3399_output = {
> > .mipi_dual_channel_en = VOP_REG(RK3288_SYS_CTRL, 0x1, 3),
> > };
> >
> > +static const struct vop_yuv2yuv_phy rk3399_yuv2yuv_win01_data = {
> > + .y2r_coefficients = {
> > + VOP_REG(RK3399_WIN0_YUV2YUV_Y2R + 0, 0x, 0),
> > + VOP_REG(RK3399_WIN0_YUV2YUV_Y2R + 0, 0x, 16),
> > + VOP_REG(RK3399_WIN0_YUV2YUV_Y2R + 4, 0x, 0),
> > + VOP_REG(RK3399_WIN0_YUV2YUV_Y2R + 4, 0x, 16),
> > + VOP_REG(RK3399_WIN0_YUV2YUV_Y2R + 8, 0x, 0),
> > + VOP_REG(RK3399_WIN0_YUV2YUV_Y2R + 8, 0x, 16),
> > + VOP_REG(RK3399_WIN0_YUV2YUV_Y2R + 12, 0x, 0),
> > + VOP_REG(RK3399_WIN0_YUV2YUV_Y2R + 12, 0x, 16),
> > + VOP_REG(RK3399_WIN0_YUV2YUV_Y2R + 16, 0x, 0),
> > + VOP_REG(RK3399_WIN0_YUV2YUV_Y2R + 20, 0x, 0),
> > + VOP_REG(RK3399_WIN0_YUV2YUV_Y2R + 24, 0x, 0),
> > + VOP_REG(RK3399_WIN0_YUV2YUV_Y2R + 28, 0x, 0),
> > + },
> > +};
> > +
> > +static const struct vop_yuv2yuv_phy rk3399_yuv2yuv_win23_data = { };
>
> looking at the rk3399 TRM it seems that win2+3 also have yuv2rgb
> coefficient registers. I didn't check in depth but are they so different
> that they cannot be supported?
>
> Aka what is the difference between win0/1 and win2/3 ?
>
>
I think Sandy is the best to answer this. I can't say I'm an expert
on the details of this hardware.
Thanks,
Eze
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/2] drm/sched: Refactor ring mirror list handling.
On 01/07/2019 09:13 AM, Christian König wrote:
> Am 03.01.19 um 18:42 schrieb Grodzovsky, Andrey:
>>
>> On 01/03/2019 11:20 AM, Grodzovsky, Andrey wrote:
>>> On 01/03/2019 03:54 AM, Koenig, Christian wrote:
Am 21.12.18 um 21:36 schrieb Grodzovsky, Andrey:
> On 12/21/2018 01:37 PM, Christian König wrote:
>> Am 20.12.18 um 20:23 schrieb Andrey Grodzovsky:
>>> Decauple sched threads stop and start and ring mirror
>>> list handling from the policy of what to do about the
>>> guilty jobs.
>>> When stoppping the sched thread and detaching sched fences
>>> from non signaled HW fenes wait for all signaled HW fences
>>> to complete before rerunning the jobs.
>>>
>>> v2: Fix resubmission of guilty job into HW after refactoring.
>>>
>>> v4:
>>> Full restart for all the jobs, not only from guilty ring.
>>> Extract karma increase into standalone function.
>>>
>>> v5:
>>> Rework waiting for signaled jobs without relying on the job
>>> struct itself as those might already be freed for non 'guilty'
>>> job's schedulers.
>>> Expose karma increase to drivers.
>>>
>>> Suggested-by: Christian Koenig
>>> Signed-off-by: Andrey Grodzovsky
>>> ---
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 18 +--
>>> drivers/gpu/drm/etnaviv/etnaviv_sched.c | 11 +-
>>> drivers/gpu/drm/scheduler/sched_main.c | 188
>>> +++--
>>> drivers/gpu/drm/v3d/v3d_sched.c | 12 +-
>>> include/drm/gpu_scheduler.h | 10 +-
>>> 5 files changed, 151 insertions(+), 88 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>> index 8a078f4..a4bd2d3 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>> @@ -3298,12 +3298,10 @@ static int
>>> amdgpu_device_pre_asic_reset(struct amdgpu_device *adev,
>>> if (!ring || !ring->sched.thread)
>>> continue;
>>> - kthread_park(ring->sched.thread);
>>> + drm_sched_stop(>sched, job ? >base : NULL);
>>> - if (job && job->base.sched != >sched)
>>> - continue;
>>> -
>>> - drm_sched_hw_job_reset(>sched, job ? >base :
>>> NULL);
>>> + if(job)
>>> + drm_sched_increase_karma(>base);
>> Since we dropped the "job && job->base.sched != >sched" check
>> above this will now increase the jobs karma multiple times.
>>
>> Maybe just move that outside of the loop.
>>
>>> /* after all hw jobs are reset, hw fence is
>>> meaningless,
>>> so force_completion */
>>> amdgpu_fence_driver_force_completion(ring);
>>> @@ -3454,14 +3452,10 @@ static void
>>> amdgpu_device_post_asic_reset(struct amdgpu_device *adev,
>>> if (!ring || !ring->sched.thread)
>>> continue;
>>> - /* only need recovery sched of the given job's ring
>>> - * or all rings (in the case @job is NULL)
>>> - * after above amdgpu_reset accomplished
>>> - */
>>> - if ((!job || job->base.sched == >sched) &&
>>> !adev->asic_reset_res)
>>> - drm_sched_job_recovery(>sched);
>>> + if (!adev->asic_reset_res)
>>> + drm_sched_resubmit_jobs(>sched);
>>> - kthread_unpark(ring->sched.thread);
>>> + drm_sched_start(>sched, !adev->asic_reset_res);
>>> }
>>> if (!amdgpu_device_has_dc_support(adev)) {
>>> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
>>> b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
>>> index 49a6763..6f1268f 100644
>>> --- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
>>> +++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
>>> @@ -109,16 +109,19 @@ static void etnaviv_sched_timedout_job(struct
>>> drm_sched_job *sched_job)
>>> }
>>> /* block scheduler */
>>> - kthread_park(gpu->sched.thread);
>>> - drm_sched_hw_job_reset(>sched, sched_job);
>>> + drm_sched_stop(>sched, sched_job);
>>> +
>>> + if(sched_job)
>>> + drm_sched_increase_karma(sched_job);
>>> /* get the GPU back into the init state */
>>> etnaviv_core_dump(gpu);
>>> etnaviv_gpu_recover_hang(gpu);
>>> + drm_sched_resubmit_jobs(>sched);
>>> +
>>> /* restart scheduler after GPU is usable again */
>>> - drm_sched_job_recovery(>sched);
>>> - kthread_unpark(gpu->sched.thread);
>>> + drm_sched_start(>sched, true);
>>> }
>>> static void etnaviv_sched_free_job(struct drm_sched_job
>>> *sched_job)
>>> diff --git a/drivers/gpu/drm/scheduler/sched_main.c
[Bug 109073] AMDGPU Radeon RX540 system freezes and/or crashes; poor performance with ac adapter plugged in
https://bugs.freedesktop.org/show_bug.cgi?id=109073 --- Comment #7 from whoop --- Created attachment 143004 --> https://bugs.freedesktop.org/attachment.cgi?id=143004=edit kern.log using kernel v5.0-rc1 with black screen after login with power adapter plugged in -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] topic/drmp-cleanup for drm-misc-next and drm-intel-next-queued
Hi Jani, On Wed, Jan 02, 2019 at 12:00:49PM +0200, Jani Nikula wrote: > I embarked on removing drmP.h includes from i915, but that requires a > bunch of drm header cleanup to add relevant includes and forward > declarations. Due to the timing, propagating the patches back to i915 > would take eons, so Daniel suggested a topic branch to be merged both to > drm-misc-next and drm-intel-next-queued. So here it is, with $(git > merge-base drm-misc-next drm-intel-next-queued) as the starting point. > > The topic branch has been part of drm-tip since, uh, last year, but I > did just force push it to update the commit messages to reflect > Laurent's review. No code changes. > > I'll merge the same thing to i915 after it's been pulled to > drm-misc-next, and with this, I should be able to get rid of all drmP.h > includes in i915. I merged the PR, and it's on its way to Daniel and Dave now. Thanks Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109073] AMDGPU Radeon RX540 system freezes and/or crashes; poor performance with ac adapter plugged in
https://bugs.freedesktop.org/show_bug.cgi?id=109073 --- Comment #6 from whoop --- With v5.0-rc1 the system hangs with a black screen after I login at gdm when the power adapter is connected -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm/mxsfb: support swapped RGB lanes
Hi Ahmad.
> On 2/1/19 22:37, Sam Ravnborg wrote:
> > The problem with the RED/BLUE lines swapped is something I
> > have encountered while working with DRM support for Atmel at91sam9263 too.
> >
> > The solution selected is to extend the endpoint with
> > a new optional property:
> >
> > - wiring: Wiring of data lines to display.
> > "straight" - normal wiring.
> > "red-blue-reversed" - red and blue lines reversed.
> >
> > (media/video-interfaces.txt)
> >
> >
> > The DT node looks like this:
> >
> >port@0 {
> > reg = <0>;
> > #address-cells = <1>;
> > #size-cells = <0>;
> > lcdc_panel_output: endpoint@0 {
> > reg = <0>;
> > wiring = "red-blue-reversed";
> > remote-endpoint = <_input>;
> > };
> > };
> >
> > This allows us to specify the swapping in the endpoint and
> > not in the panel.
> > So we can use the same panel, with the same bus_format, in several
> > designs some with red-blue swapped (reversed), and some not.
>
> A colleague suggested a property in the endpoint as well, but I shied
> away because of the extra hassle. Seems there's won't be a way around it ^^'..
>
> How do you intend to propagate this different wiring setting?
The way I have it implmented is more or less like this:
First find the wiring property:
1) Look up endpoint using of_graph_get_endpoint_by_regs()
2) Get wiring property
3) of_node_put(endpoint);
And then find and attach the panel:
4) drm_of_find_panel_or_bridge(dev->of_node, 0, 0, , );
5) devm_drm_panel_bridge_add(dev, panel, DRM_MODE_CONNECTOR_DPI);
6) Then based on the wiring property I adjust bus_format
7) drm_simple_display_pipe_init()
8) drm_simple_display_pipe_attach_bridge()
But this is all virgin code that for now can build,
but has not yet seen any testing.
It is a lot of boilerplate for something relatively simple
and I hope there are ways to simplify this.
Relevant parts of the file pasted below.
But the translation of bus_format in a central place may prove a bit
difficult and I assume this as something that can differ
a lot between different HW solutions.
> How about having drm_of_find_panel_or_bridge adjust the
> (*panel)->connector->display_info.bus_formats array to account for the
> different wiring? That way there shouldn't be any need to adjust drivers.
But if you prove me wrong and this fly I am all for it.
Keep in mind that I am novice in the DRM land. So there may be better ways to
do it.
Sam
static int lcdc_get_of_wiring(struct lcdc *lcdc,
const struct device_node *ep)
{
const char *str;
int ret;
ret = of_property_read_string(ep, "wiring", );
if (ret)
return ret;
if (strcmp(str, "red-green-reversed") == 0) {
lcdc->wiring_reversed = true;
} else if (strcmp(str, "straight") == 0) {
/* Use default format */
} else {
DRM_DEV_ERROR(lcdc->dev, "unknown \"wiring\" property: %s",
str);
return -EINVAL;
}
return 0;
}
static int lcdc_display_init(struct lcdc *lcdc, struct drm_device *drm)
{
struct drm_display_info *display_info;
const u32 *formats;
size_t nformats;
int ret;
display_info = >panel->connector->display_info;
if (!display_info->num_bus_formats || !display_info->bus_formats) {
DRM_DEV_ERROR(lcdc->dev, "missing bus_format from panel");
return -EINVAL;
}
switch (display_info->bus_formats[0]) {
case MEDIA_BUS_FMT_RGB888_1X24:
case MEDIA_BUS_FMT_RGB565_1X16:
lcdc->bus_format = display_info->bus_formats[0];
break;
default:
DRM_DEV_ERROR(lcdc->dev, "unsupported bus_format: %d",
display_info->bus_formats[0]);
return -EINVAL;
}
/* Select formats depending on wiring (from bus_formats + from DT) */
if (lcdc->bus_format == MEDIA_BUS_FMT_RGB888_1X24) {
if (!lcdc->wiring_reversed) {
formats = bgr_formats_24;
nformats = ARRAY_SIZE(bgr_formats_24);
} else {
formats = rgb_formats_24;
nformats = ARRAY_SIZE(rgb_formats_24);
}
} else {
if (!lcdc->wiring_reversed) {
formats = bgr_formats_16;
nformats = ARRAY_SIZE(bgr_formats_16);
} else {
formats = rgb_formats_16;
nformats = ARRAY_SIZE(rgb_formats_16);
[PULL] drm-misc-next
Hi Dave, Daniel, Here is the first PR for 5.1 for drm-misc-next. This is my first PR ever for drm-misc, so please let me know if I screwed up somehow :) Thanks! Maxime drm-misc-next-2019-01-07-1: drm-misc-next for 5.1: UAPI Changes: Cross-subsystem Changes: - Turn dma-buf fence sequence numbers into 64 bit numbers Core Changes: - Move to a common helper for the DP MST hotplug for radeon, i915 and amdgpu - i2c improvements for drm_dp_mst - Removal of drm_syncobj_cb - Introduction of an helper to create and attach the TV margin properties Driver Changes: - Improve cache flushes for v3d - Reflection support for vc4 - HDMI overscan support for vc4 - Add implicit fencing support for rockchip and sun4i - Switch to generic fbdev emulation for virtio The following changes since commit 0b258ed1a219a9776e8f6967eb34837ae0332e64: drm: revert "expand replace_fence to support timeline point v2" (2018-12-05 11:01:11 +0100) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2019-01-07-1 for you to fetch changes up to 1c95f662fceeb8ae2f34e3de9478e21fd31f09dd: Merge tag 'topic/drmp-cleanup-2019-01-02' of git://anongit.freedesktop.org/drm/drm-intel into drm-misc-next (2019-01-07 16:43:24 +0100) drm-misc-next for 5.1: UAPI Changes: Cross-subsystem Changes: - Turn dma-buf fence sequence numbers into 64 bit numbers Core Changes: - Move to a common helper for the DP MST hotplug for radeon, i915 and amdgpu - i2c improvements for drm_dp_mst - Removal of drm_syncobj_cb - Introduction of an helper to create and attach the TV margin properties Driver Changes: - Improve cache flushes for v3d - Reflection support for vc4 - HDMI overscan support for vc4 - Add implicit fencing support for rockchip and sun4i - Switch to generic fbdev emulation for virtio Archit Taneja (1): MAINTAINERS: drm: Remove myself as drm-bridge maintainer Boris Brezillon (7): drm/vc4: Fix negative X/Y positioning on SAND planes drm/vc4: Add support for X/Y reflection drm/connector: Fix drm_mode_create_tv_properties() doc drm/connector: Clarify the unit of TV margins drm/connector: Allow creation of margin props alone drm/vc4: Take margin setup into account when updating planes drm/vc4: Attach margin props to the HDMI connector Brajeswar Ghosh (1): drm/drm_drv.c: Remove duplicate header Chris Wilson (1): drm: Reorder set_property_atomic to avoid returning with an active ww_ctx Christian König (4): drm/v3d: fix broken build dma-buf: make fence sequence numbers 64 bit v2 drm/etnaviv: fix for 64bit seqno change drm/syncobj: remove drm_syncobj_cb and cleanup Dan Carpenter (2): drm: Fix an error pointer dereference() drm/ati_pcigart: Fix error code in drm_ati_pcigart_init() Daniel Vetter (3): drm/dp-mst-helper: Remove hotplug callback drm/qxl: Don't set the dpms hook drm/xen: Don't set the dpms hook Eric Anholt (6): drm/v3d: Document cache flushing ABI. drm/v3d: Drop unused v3d_flush_caches(). drm/v3d: Don't bother flushing L1TD at job start. drm/v3d: Drop the wait for L2T flush to complete. drm/v3d: Stop trying to flush L2C on V3D 3.3+ drm/v3d: Invalidate the caches from the outside in. Gerd Hoffmann (3): drm/qxl: add spice-devel list to MAINTAINERS drm/virtio: switch to generic fbdev emulation drm/bochs: add edid present check Heiko Stuebner (1): drm/rockchip: Add implicit fencing support for planes Jani Nikula (5): drm: un-inline drm_legacy_findmap() drm: include kernel.h and agp_backend.h from intel-gtt.h drm: include idr.h from drm_file.h drm: include types.h from drm_hdcp.h drm: forward declare struct drm_file in drm_syncobj.h Kuninori Morimoto (1): drm: dw-hdmi-i2s: convert to SPDX identifiers Lyude Paul (3): drm/dp_mst: Fix memory leak in drm_dp_mst_topology_mgr_destroy() drm/dp_mst: Remove bogus conditional in drm_dp_update_payload_part1() drm/dp_mst: Refactor drm_dp_update_payload_part1() Maxime Ripard (1): Merge tag 'topic/drmp-cleanup-2019-01-02' of git://anongit.freedesktop.org/drm/drm-intel into drm-misc-next Mika Kuoppala (1): drm/i915: Compile fix for 64b dma-fence seqno Rob Clark (1): drm/atomic: integrate modeset lock with private objects Sam Ravnborg (1): drm: move DRM_IF_VERSION to drm_internal.h Shayenne da Luz Moura (2): drm: Rename crtc_idr as object_idr to KMS cleanups drm: Remove complete task from TODO documentation Ville Syrjälä (2): drm/dp/mst: Configure no_stop_bit correctly for remote i2c xfers drm/dp/mst: Validate REMOTE_I2C_READ harder Yangtao Li (1): dma-buf: Change to use
[Bug 109234] amdgpu random hangs with 4.21+
https://bugs.freedesktop.org/show_bug.cgi?id=109234 --- Comment #3 from bmil...@gmail.com --- (In reply to Michel Dänzer from comment #2) > Can you bisect? I could but I don't have a reliable reproduction yet. I don't know what triggers the bug. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm: Block fb changes for async plane updates
The prepare_fb call always happens on new_plane_state.
The drm_atomic_helper_cleanup_planes checks to see if
plane state pointer has changed when deciding to call cleanup_fb on
either the new_plane_state or the old_plane_state.
For a non-async atomic commit the state pointer is swapped, so this
helper calls prepare_fb on the new_plane_state and cleanup_fb on the
old_plane_state. This makes sense, since we want to prepare the
framebuffer we are going to use and cleanup the the framebuffer we are
no longer using.
For the async atomic update helpers this differs. The async atomic
update helpers perform in-place updates on the existing state. They call
drm_atomic_helper_cleanup_planes but the state pointer is not swapped.
This means that prepare_fb is called on the new_plane_state and
cleanup_fb is called on the new_plane_state (not the old).
In the case where old_plane_state->fb == new_plane_state->fb then
there should be no behavioral difference between an async update
and a non-async commit. But there are issues that arise when
old_plane_state->fb != new_plane_state->fb.
The first is that the new_plane_state->fb is immediately cleaned up
after it has been prepared, so we're using a fb that we shouldn't
be.
The second occurs during a sequence of async atomic updates and
non-async regular atomic commits. Suppose there are two framebuffers
being interleaved in a double-buffering scenario, fb1 and fb2:
- Async update, oldfb = NULL, newfb = fb1, prepare fb1, cleanup fb1
- Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb2
- Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2
We call cleanup_fb on fb2 twice in this example scenario, and any
further use will result in use-after-free.
The simple fix to this problem is to block framebuffer changes
in the drm_atomic_helper_async_check function for now.
Cc: Daniel Vetter
Cc: Harry Wentland
Cc: Andrey Grodzovsky
Cc: # v4.14+
Fixes: fef9df8b5945 ("drm/atomic: initial support for asynchronous plane
update")
Signed-off-by: Nicholas Kazlauskas
---
drivers/gpu/drm/drm_atomic_helper.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 54e2ae614dcc..f4290f6b0c38 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1602,6 +1602,15 @@ int drm_atomic_helper_async_check(struct drm_device *dev,
old_plane_state->crtc != new_plane_state->crtc)
return -EINVAL;
+ /*
+* FIXME: Since prepare_fb and cleanup_fb are always called on
+* the new_plane_state for async updates we need to block framebuffer
+* changes. This prevents use of a fb that's been cleaned up and
+* double cleanups from occuring.
+*/
+ if (old_plane_state->fb != new_plane_state->fb)
+ return -EINVAL;
+
funcs = plane->helper_private;
if (!funcs->atomic_async_update)
return -EINVAL;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: offb: Pass actual name in offb_init_palette_hacks
On Wed, Jan 2, 2019 at 2:03 PM Mathieu Malaterre wrote:
>
> Bartlomiej,
>
> Do you need an Acked-by from Rob, or can you take it in the next round
> of fixes for v4.20 ?
Sorry, I missed this.
>
> Just to repeat myself, previous code would call
> offb_init_palette_hacks(), which in turn would do:
>
>if (dp && !strncmp(name, "ATY,Rage128", 11)) {
>
> with name=NULL.
I prefer to fix this properly using node name helper in
offb_init_palette_hacks(). I'll send a patch shortly.
Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] fbdev: offb: Fix OF node name handling
Commit 5c63e407aaab ("fbdev: Convert to using %pOFn instead of
device_node.name") changed how the OF FB driver handles the OF node
name. This missed the case where the node name is passed to
offb_init_palette_hacks(). This results in a NULL ptr dereference
in strncmp and breaks any system except ones using bootx with no display
node.
Fix this by making offb_init_palette_hacks() use the OF node pointer and
use of_node_name_prefix() helper function instead for node name
comparisons. This helps in moving all OF node name accesses to helper
functions in preparation to remove struct device_node.name pointer.
Fixes: 5c63e407aaab ("fbdev: Convert to using %pOFn instead of
device_node.name")
Reported-by: Mathieu Malaterre
Cc: sta...@vger.kernel.org # v4.19+
Cc: Bartlomiej Zolnierkiewicz
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Rob Herring
---
drivers/video/fbdev/offb.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/video/fbdev/offb.c b/drivers/video/fbdev/offb.c
index 31f769d67195..057d3cdef92e 100644
--- a/drivers/video/fbdev/offb.c
+++ b/drivers/video/fbdev/offb.c
@@ -318,28 +318,28 @@ static void __iomem *offb_map_reg(struct device_node *np,
int index,
}
static void offb_init_palette_hacks(struct fb_info *info, struct device_node
*dp,
- const char *name, unsigned long address)
+ unsigned long address)
{
struct offb_par *par = (struct offb_par *) info->par;
- if (dp && !strncmp(name, "ATY,Rage128", 11)) {
+ if (of_node_name_prefix(dp, "ATY,Rage128")) {
par->cmap_adr = offb_map_reg(dp, 2, 0, 0x1fff);
if (par->cmap_adr)
par->cmap_type = cmap_r128;
- } else if (dp && (!strncmp(name, "ATY,RageM3pA", 12)
- || !strncmp(name, "ATY,RageM3p12A", 14))) {
+ } else if (of_node_name_prefix(dp, "ATY,RageM3pA") ||
+ of_node_name_prefix(dp, "ATY,RageM3p12A")) {
par->cmap_adr = offb_map_reg(dp, 2, 0, 0x1fff);
if (par->cmap_adr)
par->cmap_type = cmap_M3A;
- } else if (dp && !strncmp(name, "ATY,RageM3pB", 12)) {
+ } else if (of_node_name_prefix(dp, "ATY,RageM3pB")) {
par->cmap_adr = offb_map_reg(dp, 2, 0, 0x1fff);
if (par->cmap_adr)
par->cmap_type = cmap_M3B;
- } else if (dp && !strncmp(name, "ATY,Rage6", 9)) {
+ } else if (of_node_name_prefix(dp, "ATY,Rage6")) {
par->cmap_adr = offb_map_reg(dp, 1, 0, 0x1fff);
if (par->cmap_adr)
par->cmap_type = cmap_radeon;
- } else if (!strncmp(name, "ATY,", 4)) {
+ } else if (of_node_name_prefix(dp, "ATY,")) {
unsigned long base = address & 0xff00UL;
par->cmap_adr =
ioremap(base + 0x7ff000, 0x1000) + 0xcc0;
@@ -350,7 +350,7 @@ static void offb_init_palette_hacks(struct fb_info *info,
struct device_node *dp
par->cmap_adr = offb_map_reg(dp, 0, 0x6000, 0x1000);
if (par->cmap_adr)
par->cmap_type = cmap_gxt2000;
- } else if (dp && !strncmp(name, "vga,Display-", 12)) {
+ } else if (of_node_name_prefix(dp, "vga,Display-")) {
/* Look for AVIVO initialized by SLOF */
struct device_node *pciparent = of_get_parent(dp);
const u32 *vid, *did;
@@ -438,7 +438,7 @@ static void __init offb_init_fb(const char *name,
par->cmap_type = cmap_unknown;
if (depth == 8)
- offb_init_palette_hacks(info, dp, name, address);
+ offb_init_palette_hacks(info, dp, address);
else
fix->visual = FB_VISUAL_TRUECOLOR;
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109239] Polaris10: Periodic random black screens for 1-2 seconds
https://bugs.freedesktop.org/show_bug.cgi?id=109239 --- Comment #4 from Michel Dänzer --- When you wrote "modesetting", you meant "DC". So the problem is the same with or without DC? Does it also happen with the Xorg modesetting driver instead of xf86-video-amdgpu, or with a Wayland compositor such as GNOME on Wayland? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Expose more EDID fields to userspace
On Mon, Jan 07, 2019 at 07:57:54AM -0800, Keith Packard wrote: > Daniel Vetter writes: > > > Best to pull in some other compositor people and get them to agree. From a > > kernel pov I'm fine with whatever userspace preferes. > > Hrm. It would be good to have everyone using the same interpretation of > EDID data; in particular, where the kernel has quirks that change the > interpretation, user space should be consistent with that. > > Unless we expose all of the EDID data, then user space may still have to > parse EDID. If the kernel has EDID quirks, it might be good to to make > those affect the "raw" EDID data visible to use space so that values the > kernel supplies separately are consistent with values extracted from the > "raw" EDID data. If the quirks can be re-encoded back into an EDID representation, then this sounds like a fairly good approach to me. > > Doing this in the kernel does make it harder to quickly supply fixes for > a specific user space application. This will probably lead to > kludge-arounds in user space that could depend on kernel > version. Perhaps these EDID capabilities in the kernel should be > versioned separately? > > I see good benefits from having user space able to see how the kernel is > interpreting EDID so that it can adapt as appropriate, but we should be > cautious about moving functionality into the kernel that would be more > easily maintained up in user space. > I agree. It seems likely that whatever happens (some) userspace is still going to implement (some) EDID parsing functionality, so it's hard to reason about what belongs where. Shared code in userspace (libdrm?) may well be better than exposing it from the kernel. If it is exposed by the kernel, then it's still non-obvious to me how the kernel exposes that information/interpretation. Adding a property for every potentially-useful field really doesn't scale well, and what fields are useful isn't obvious - e.g. serial string vs serial no., as mentioned by Simon. Uma's recent series: "Add HDR Metadata Parsing and handling in DRM layer"[1] is a good example of more stuff which userspace would want to parse out of the EDID (supported display colorimetry and transfer functions). It would be nice to avoid duplicating all the CEA extension parsing code, but the EDID/CEA data structure is extensible by design. So the kernel API would need to be similarly extensible, or we'll just balloon loads of properties... and then the kernel API would likely just end up just looking similar to the CEA block anyway. Cheers, -Brian [1] https://lists.freedesktop.org/archives/dri-devel/2018-December/200154.html > -- > -keith > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109239] Polaris10: Periodic random black screens for 1-2 seconds
https://bugs.freedesktop.org/show_bug.cgi?id=109239 Michel Dänzer changed: What|Removed |Added Attachment #143000|text/x-log |text/plain mime type|| -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109239] Polaris10: Periodic random black screens for 1-2 seconds
https://bugs.freedesktop.org/show_bug.cgi?id=109239 Michel Dänzer changed: What|Removed |Added Attachment #142998|text/x-log |text/plain mime type|| -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109239] Polaris10: Periodic random black screens for 1-2 seconds
https://bugs.freedesktop.org/show_bug.cgi?id=109239 Michel Dänzer changed: What|Removed |Added Attachment #142999|text/x-log |text/plain mime type|| -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109239] Polaris10: Periodic random black screens for 1-2 seconds
https://bugs.freedesktop.org/show_bug.cgi?id=109239 Michel Dänzer changed: What|Removed |Added Attachment #142997|text/x-log |text/plain mime type|| -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/todo: Better defio support in the generic fbdev emulation
Den 07.01.2019 11.22, skrev Daniel Vetter: > The current one essentially means you need CMA or a vmalloc backed > object, which makes fbdev emulation a special case. > > Since implementing this will be quite a bit of work, capture the idea > in a TODO. > > Cc: Noralf Trønnes > Signed-off-by: Daniel Vetter > --- Acked-by: Noralf Trønnes ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Armada DRM: bridge with componentized devices
On 07.01.2019 17:08, Daniel Vetter wrote: > On Mon, Jan 07, 2019 at 12:26:58PM +0100, Andrzej Hajda wrote: >> On 07.01.2019 11:45, Daniel Vetter wrote: >>> On Thu, Jan 03, 2019 at 01:11:47PM +, Russell King - ARM Linux wrote: On Thu, Jan 03, 2019 at 10:47:27AM +0100, Lubomir Rintel wrote: > Hello, > > lately I've been trying to make the Himax HX8837 chip that drives the OLPC > LCD display work with Armada DRM driver. I've been advised to create a > bridge driver and not an encoder driver since the silicon is separate from > the LCDC. > > The Armada DRM driver (and, I think, the i.MX one) creates the drm_device > once the component infrastructure sees the necessary sub-devices appear. > The sub-devices being the LCDCs and the encoders (not bridges) that it > expects to be created externally. > > Currently, it seems, the only driver that can actually work with this > (that > is -- creates a drm_encoder for a drm_device when the component is bound) > is the tda998x. All other similar drivers create a drm_bridge instead and > not use the component infrastructure at all. (In fact, tilcdc driver > contains a hack to handle tda998x specially.) > > I'm wondering how to reconcile the two? > > * The tda998x driver has recently been modified to create a bridge on > probe > and eventually encoder on component bind. Is this an okay thing to do in > a new driver? (this probably means the tilcdc hack can be removed...) > > * If a non-componentized bridge were to be used (along with a dummy > encoder), at what point would it make sense to look for the bridge? > Would it be a good idea to defer the probe of crtc until a bridge can > be > looked up and the attach it on component bind? What if the bridge goes > away (a module is unloaded, etc.) in between? > > I'd be thankful for opintions and advice before I move ahead with this. This is the long-standing problem with the conflict between bridge support and component support, and I'm not sure that there is really any answer to it. I've gone into the details of the two several times on the list, particularly about the short-comings of the bridge approach, but it seems no one cares to fix those short-comings. You are re-identifying some of the issues that I've already pointed out - such as what happens to DRM drives when the bridge driver is unbound (it's really not about modules being unloaded, and the problem can't be solved by taking a module reference count - all that the module reference count does is ensure that the module doesn't go away unexpected, there is no way to ensure that the device isn't unbound.) The issue of unbinding is precisely the issue which the component support was created to solve - but everyone seems to prefer the buggy bridge approach, and no one seems willing to do anything about the bugs or even acknowledge that it's a problem. It's strange - if one identifies bugs that result in kernel oops in other kernel subsystems, one is generally taken seriously and the problem is solved. >>> Unbinding is really not the most important feature, especially for SoC. If >>> you feel different, working together with others, getting some agreement, >>> getting the patches reviewed and finding someone to get them merged is >>> very much appreciated. But just complaining won't move this forward. >>> The issue about the encoders is something that I've tried to discuss, and I've pointed out that moving it into the DRM driver adds additional complexity there, and I'd hoped that my patch set I posted would've generated discussion, but alas not. What I'm not prepared to do is to introduce _known_ bugs into any driver that I maintain. >>> I thought last time around the idea was to use device links (and teach >>> drm_bridge about them), so that the unloading works correctly. >> >> With current device_links implementation registering links in probe of >> the consumer is just incorrect - it can happen that neither consumer >> neither provider is fully probed and creating device links in such state >> is wrong according to docs, and my experiments. See [1] for discussion >> and [2] for docs. > We could set up the device link only at drm_dev_register time. At that point > we know that driver loading has fully succeeded. We do have a list of > bridges at hand, so that's not going to be an issue. > > The only case where this breaks is if a driver is still using the > deprecated ->load callback. But that ->load callback doesn't mix well with > EDEFER_PROBE/component framework anyway, so I think not going to be a > problem hopefully? drm_dev_register usually is called from bind callback, which is called from probe callback of one of the components or master (depending
Re: Armada DRM: bridge with componentized devices
On Mon, Jan 07, 2019 at 11:45:32AM +0100, Daniel Vetter wrote: > On Thu, Jan 03, 2019 at 01:11:47PM +, Russell King - ARM Linux wrote: > > This is the long-standing problem with the conflict between bridge > > support and component support, and I'm not sure that there is really > > any answer to it. > > > > I've gone into the details of the two several times on the list, > > particularly about the short-comings of the bridge approach, but it > > seems no one cares to fix those short-comings. > > > > You are re-identifying some of the issues that I've already pointed > > out - such as what happens to DRM drives when the bridge driver is > > unbound (it's really not about modules being unloaded, and the problem > > can't be solved by taking a module reference count - all that the > > module reference count does is ensure that the module doesn't go > > away unexpected, there is no way to ensure that the device isn't > > unbound.) > > > > The issue of unbinding is precisely the issue which the component > > support was created to solve - but everyone seems to prefer the buggy > > bridge approach, and no one seems willing to do anything about the > > bugs or even acknowledge that it's a problem. It's strange - if one > > identifies bugs that result in kernel oops in other kernel subsystems, > > one is generally taken seriously and the problem is solved. > > Unbinding is really not the most important feature, especially for SoC. If > you feel different, working together with others, getting some agreement, > getting the patches reviewed and finding someone to get them merged is > very much appreciated. But just complaining won't move this forward. Sorry, I disagree. Unbinding is important if the current state results in crashes and oops - the lack of unbinding support in bridge makes it harder to develop without constantly rebooting the target machine. If all you care about is the end user who probably never removes a module, then yes, it's low priority, but if you care about efficient development, then the story is rather different. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/1] drm/prime: Use sg_dma_len() macro to get sg's length
On Mon, Jan 07, 2019 at 05:37:08PM +0530, Vivek Gautam wrote: > After mapping a sg list the we should use sg_dma_address() and > sg_dma_len() macros to access sg->address and sg->length. Fix > the same for sg->length in drm_prime_sg_to_page_addr_arrays(). > > Signed-off-by: Vivek Gautam > --- > > Changes since v1: > - Fixed compilation error: replaced sg_dma_length() with sg_dma_len(). > > This came while debugging one dmabuf import issue that we are seeing > on sdm845 target. > The dmabuf which is prepared by video (venus in this case), is imported > by drm device. > The import call flow looks like follows: > > drm_gem_prime_import() > - drm_gem_prime_import_dev() >- dma_buf_attach() & dma_buf_map_attachment() > - From dma_buf_map_attachment() >- vb2_dma_sg_dmabuf_ops_map() > - dma_map_sg(): this updates the sg->nents. > > From debugging, the sg table mapping results in sg's 'nents' to be less that > the original nents. Now drm device prepares the page information based on > this sg table, and messes up with the mappings, and we start seeing random > crashes as below from drm's memory space. > > Although this change isn't helping to fix the issue currently, but > this fix seems the right thing to do. > > One thing to notice is that, if we restore the sg->nents to > sg->orig_nents in vb2_dma_sg_dmabuf_ops_map(), we don't see the below > corruptions. > > Any pointers on this will be highly appreciated. > Thanks. > > -- > [ 338.070558] Unable to handle kernel paging request at virtual address > 4038 > [ 338.078751] Mem abort info: > [ 338.081671] ESR = 0x9604 > [ 338.084860] Exception class = DABT (current EL), IL = 32 bits > [ 338.090972] SET = 0, FnV = 0 > [ 338.094139] EA = 0, S1PTW = 0 > [ 338.097393] Data abort info: > [ 338.100375] ISV = 0, ISS = 0x0004 > [ 338.104362] CM = 0, WnR = 0 > [ 338.107446] [4038] address between user and kernel address > ranges > [ 338.114801] Internal error: Oops: 9604 [#1] PREEMPT SMP > [ 338.120527] Modules linked in: rfcomm uinput cdc_ether venus_dec venus_enc > usbnet videobuf2_dma_sg videobuf2_memops hci_uart btqca bluetooth r8152 mii > ath10k_snoc venus_core ath10k_core v4l2_mem2mem videobuf2_v4l2 > videobuf2_common ath mac80211 ecdh_generic qcom_q6v5_mss lzo lzo_compress > qcom_q6v5_adsp qcom_common qcom_q6v5 zram bridge stp llc ipt_MASQUERADE fuse > snd_seq_dummy snd_seq snd_seq_device cfg80211 joydev > [ 338.158192] CPU: 4 PID: 3235 Comm: chrome Tainted: GW > 4.19.0 #2 > [ 338.165700] Hardware name: Google Cheza (rev1) (DT) > [ 338.170720] pstate: 8049 (Nzcv daif +PAN -UAO) > [ 338.175660] pc : drm_mm_insert_node_in_range+0xfc/0x348 > [ 338.181035] lr : drm_mm_insert_node_in_range+0x24/0x348 > [ 338.186407] sp : ff8013033b30 > [ 338.189816] x29: ff8013033bd0 x28: ff8008591894 > [ 338.195275] x27: 0010 x26: > [ 338.200734] x25: x24: > [ 338.206194] x23: x22: ffc0f48b7e08 > [ 338.211656] x21: x20: 005d > [ 338.217118] x19: x18: > [ 338.222581] x17: x16: > [ 338.228046] x15: x14: > [ 338.233511] x13: 0001 x12: ffc0b1da7200 > [ 338.238978] x11: 0010 x10: 0010 > [ 338.244437] x9 : 0008 x8 : 4000 > [ 338.249898] x7 : x6 : > [ 338.255361] x5 : x4 : > [ 338.260823] x3 : x2 : 005d > [ 338.266285] x1 : ffc0b1da7100 x0 : ffc0b0215800 > [ 338.271748] Process chrome (pid: 3235, stack limit = 0x0900f416) > [ 338.278628] Call trace: > [ 338.281151] drm_mm_insert_node_in_range+0xfc/0x348 > [ 338.286168] msm_gem_map_vma+0x60/0xdc > [ 338.290022] msm_gem_get_iova+0xb4/0xf4 > [ 338.293967] msm_ioctl_gem_info+0x90/0xdc > [ 338.298089] drm_ioctl_kernel+0xa8/0xe8 > [ 338.302043] drm_ioctl+0x218/0x384 > [ 338.305547] drm_compat_ioctl+0xd8/0xe8 > [ 338.309503] __arm64_compat_sys_ioctl+0x134/0x20c > [ 338.314339] el0_svc_common+0xa0/0xf0 > [ 338.318108] el0_svc_compat_handler+0x2c/0x38 > [ 338.322588] el0_svc_compat+0x8/0x18 > [ 338.326274] Code: f94066c8 aa1f03e0 321d03e9 321c03ea (f9401d0b) > [ 338.332538] ---[ end trace 5c09e60869887d87 ]--- > [ 338.354633] Kernel panic - not syncing: Fatal exception > [ 338.360018] SMP: stopping secondary CPUs > [ 338.364179] Kernel Offset: disabled > [ 338.367779] CPU features: 0x0,22802a18 > [ 338.371643] Memory Limit: none > -- > > drivers/gpu/drm/drm_prime.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c > index 231e3f6d5f41..aa87ba9c0d7b 100644 > --- a/drivers/gpu/drm/drm_prime.c >
Re: [PATCH v2 13/14] drm/tinydrm: do not reply on drmP.h from drm_gem_cma_helper.h
Den 30.12.2018 18.48, skrev Sam Ravnborg: > drmP.h was the only header file in the past and a lot > of files rely on that drmP.h defines everything. > The goal is to one day to delete drmP.h and > as a step towards this it will no longer be included in the > headers files in include/drm/ > > To prepare tinydrm/ for this add dependencies that > othwewise was pulled in by drmP.h from drm_gem_cma_helper.h > > To avoid that tinydrm.h became "include everything", > push include files to the individual drivers. > > Signed-off-by: Sam Ravnborg > Cc: "Noralf Trønnes" > Cc: David Airlie > Cc: Eric Anholt > Cc: David Lechner > Cc: Daniel Vetter > --- Thanks for doing this dep fix series: Reviewed-by: Noralf Trønnes ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Armada DRM: bridge with componentized devices
On Mon, Jan 07, 2019 at 12:26:58PM +0100, Andrzej Hajda wrote: > On 07.01.2019 11:45, Daniel Vetter wrote: > > On Thu, Jan 03, 2019 at 01:11:47PM +, Russell King - ARM Linux wrote: > >> On Thu, Jan 03, 2019 at 10:47:27AM +0100, Lubomir Rintel wrote: > >>> Hello, > >>> > >>> lately I've been trying to make the Himax HX8837 chip that drives the OLPC > >>> LCD display work with Armada DRM driver. I've been advised to create a > >>> bridge driver and not an encoder driver since the silicon is separate from > >>> the LCDC. > >>> > >>> The Armada DRM driver (and, I think, the i.MX one) creates the drm_device > >>> once the component infrastructure sees the necessary sub-devices appear. > >>> The sub-devices being the LCDCs and the encoders (not bridges) that it > >>> expects to be created externally. > >>> > >>> Currently, it seems, the only driver that can actually work with this > >>> (that > >>> is -- creates a drm_encoder for a drm_device when the component is bound) > >>> is the tda998x. All other similar drivers create a drm_bridge instead and > >>> not use the component infrastructure at all. (In fact, tilcdc driver > >>> contains a hack to handle tda998x specially.) > >>> > >>> I'm wondering how to reconcile the two? > >>> > >>> * The tda998x driver has recently been modified to create a bridge on > >>> probe > >>> and eventually encoder on component bind. Is this an okay thing to do in > >>> a new driver? (this probably means the tilcdc hack can be removed...) > >>> > >>> * If a non-componentized bridge were to be used (along with a dummy > >>> encoder), at what point would it make sense to look for the bridge? > >>> Would it be a good idea to defer the probe of crtc until a bridge can > >>> be > >>> looked up and the attach it on component bind? What if the bridge goes > >>> away (a module is unloaded, etc.) in between? > >>> > >>> I'd be thankful for opintions and advice before I move ahead with this. > >> This is the long-standing problem with the conflict between bridge > >> support and component support, and I'm not sure that there is really > >> any answer to it. > >> > >> I've gone into the details of the two several times on the list, > >> particularly about the short-comings of the bridge approach, but it > >> seems no one cares to fix those short-comings. > >> > >> You are re-identifying some of the issues that I've already pointed > >> out - such as what happens to DRM drives when the bridge driver is > >> unbound (it's really not about modules being unloaded, and the problem > >> can't be solved by taking a module reference count - all that the > >> module reference count does is ensure that the module doesn't go > >> away unexpected, there is no way to ensure that the device isn't > >> unbound.) > >> > >> The issue of unbinding is precisely the issue which the component > >> support was created to solve - but everyone seems to prefer the buggy > >> bridge approach, and no one seems willing to do anything about the > >> bugs or even acknowledge that it's a problem. It's strange - if one > >> identifies bugs that result in kernel oops in other kernel subsystems, > >> one is generally taken seriously and the problem is solved. > > Unbinding is really not the most important feature, especially for SoC. If > > you feel different, working together with others, getting some agreement, > > getting the patches reviewed and finding someone to get them merged is > > very much appreciated. But just complaining won't move this forward. > > > >> The issue about the encoders is something that I've tried to discuss, > >> and I've pointed out that moving it into the DRM driver adds additional > >> complexity there, and I'd hoped that my patch set I posted would've > >> generated discussion, but alas not. > >> > >> What I'm not prepared to do is to introduce _known_ bugs into any > >> driver that I maintain. > > I thought last time around the idea was to use device links (and teach > > drm_bridge about them), so that the unloading works correctly. > > > With current device_links implementation registering links in probe of > the consumer is just incorrect - it can happen that neither consumer > neither provider is fully probed and creating device links in such state > is wrong according to docs, and my experiments. See [1] for discussion > and [2] for docs. We could set up the device link only at drm_dev_register time. At that point we know that driver loading has fully succeeded. We do have a list of bridges at hand, so that's not going to be an issue. The only case where this breaks is if a driver is still using the deprecated ->load callback. But that ->load callback doesn't mix well with EDEFER_PROBE/component framework anyway, so I think not going to be a problem hopefully? -Daniel > > > [1]: https://patchwork.freedesktop.org/patch/218878/ > > [2]: > https://www.kernel.org/doc/html/latest/driver-api/device_link.html#usage > > > Regards > > Andrzej > > > > > > Wrt
[Bug 109238] [DC] Polaris10: Missing modes when enabling DC
https://bugs.freedesktop.org/show_bug.cgi?id=109238 Alex Deucher changed: What|Removed |Added Attachment #142993|text/x-log |text/plain mime type|| -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109238] [DC] Polaris10: Missing modes when enabling DC
https://bugs.freedesktop.org/show_bug.cgi?id=109238 Alex Deucher changed: What|Removed |Added Attachment #142994|text/x-log |text/plain mime type|| -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109238] [DC] Polaris10: Missing modes when enabling DC
https://bugs.freedesktop.org/show_bug.cgi?id=109238 Alex Deucher changed: What|Removed |Added Attachment #142992|text/x-log |text/plain mime type|| -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 14/14] drm: remove drmP.h from drm_gem_cma_helper.h
Den 30.12.2018 18.48, skrev Sam Ravnborg: > With all dependencies fixed we can now remove > drmP.h from drm_gem_cma_helper.h. > It is replaced by the include files required, > or forward declarations as appropritate. > > Signed-off-by: Sam Ravnborg > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: Sean Paul > Cc: David Airlie > Cc: Daniel Vetter > --- Acked-by: Noralf Trønnes ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109238] [DC] Polaris10: Missing modes when enabling DC
https://bugs.freedesktop.org/show_bug.cgi?id=109238 Alex Deucher changed: What|Removed |Added Attachment #142991|text/x-log |text/plain mime type|| -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 12/14] drm/stm: do not reply on drmP.h from drm_gem_cma_helper.h
Den 30.12.2018 18.48, skrev Sam Ravnborg: > drmP.h was the only header file in the past and a lot > of files rely on that drmP.h defines everything. > The goal is to one day to delete drmP.h and > as a step towards this it will no longer be included in the > headers files in include/drm/ > > To prepare stm/ for this add dependencies that > othwewise was pulled in by drmP.h from drm_gem_cma_helper.h > > Sort the include list when we anyway modify it. > > Signed-off-by: Sam Ravnborg > Cc: Yannick Fertre > Cc: Philippe Cornu > Cc: Benjamin Gaignard > Cc: Vincent Abriou > Cc: David Airlie > Cc: Daniel Vetter > --- Acked-by: Noralf Trønnes ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 11/14] drm/arc: do not reply on drmP.h from drm_gem_cma_helper.h
Den 30.12.2018 18.48, skrev Sam Ravnborg: > drmP.h was the only header file in the past and a lot > of files rely on that drmP.h defines everything. > The goal is to one day to delete drmP.h and > as a step towards this it will no longer be included in the > headers files in include/drm/ > > To prepare arc/ for this add dependencies that > othwewise was pulled in by drmP.h from drm_gem_cma_helper.h > > Signed-off-by: Sam Ravnborg > Cc: Alexey Brodkin > Cc: Daniel Vetter > Cc: David Airlie > --- Acked-by: Noralf Trønnes ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Expose more EDID fields to userspace
Daniel Vetter writes: > Best to pull in some other compositor people and get them to agree. From a > kernel pov I'm fine with whatever userspace preferes. Hrm. It would be good to have everyone using the same interpretation of EDID data; in particular, where the kernel has quirks that change the interpretation, user space should be consistent with that. Unless we expose all of the EDID data, then user space may still have to parse EDID. If the kernel has EDID quirks, it might be good to to make those affect the "raw" EDID data visible to use space so that values the kernel supplies separately are consistent with values extracted from the "raw" EDID data. Doing this in the kernel does make it harder to quickly supply fixes for a specific user space application. This will probably lead to kludge-arounds in user space that could depend on kernel version. Perhaps these EDID capabilities in the kernel should be versioned separately? I see good benefits from having user space able to see how the kernel is interpreting EDID so that it can adapt as appropriate, but we should be cautious about moving functionality into the kernel that would be more easily maintained up in user space. -- -keith signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 09/14] drm: remove include of drmP.h from drm_encoder_slave.h
Den 30.12.2018 18.48, skrev Sam Ravnborg: > No further changes required. > > Signed-off-by: Sam Ravnborg > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: Sean Paul > Cc: David Airlie > Cc: Daniel Vetter > --- Acked-by: Noralf Trønnes ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 05/14] drm: make drm_file.h self contained
Den 30.12.2018 18.48, skrev Sam Ravnborg: > drm_file.h embed struct idr, so this file need to know > the full type definition. > > With this change users of drm_file.h are no longer forced > to include idr.h - a file they usually get from drmP.h > > This makes it simpler to remove drmP.h includes > > Signed-off-by: Sam Ravnborg > Cc: Jani Nikula > Cc: Daniel Vetter > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: Sean Paul > Cc: David Airlie > --- Acked-by: Noralf Trønnes ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 04/14] drm: make drm_framebuffer.h self contained
Den 30.12.2018 18.48, skrev Sam Ravnborg: > Add forward declaration and pull in include > file to make drm_framebuffer.h self contained. > > While add it order include files alphabetically. > > The use of TASK_COMM_LEN is the reason for including sched.h. > I could not see any good way to avoid this dependency, > and users of drm_framebuffer.comm already use > TASK_COMM_LEN to check for length etc. We can't avoid including it, the macro is used here after all. > > Signed-off-by: Sam Ravnborg > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: Sean Paul > Cc: David Airlie > Cc: Daniel Vetter > --- > include/drm/drm_framebuffer.h | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/include/drm/drm_framebuffer.h b/include/drm/drm_framebuffer.h > index c94acedfb08e..f639ed527943 100644 > --- a/include/drm/drm_framebuffer.h > +++ b/include/drm/drm_framebuffer.h > @@ -23,13 +23,16 @@ > #ifndef __DRM_FRAMEBUFFER_H__ > #define __DRM_FRAMEBUFFER_H__ > > -#include > #include > +#include > +#include > + > #include > > struct drm_framebuffer; > struct drm_file; > struct drm_device; > +struct drm_clip_rect; I think you can add drm_gem_object to this list. > > /** > * struct drm_framebuffer_funcs - framebuffer hooks > Acked-by: Noralf Trønnes ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199139] System freezes (kernel, amdgpu NULL pointer dereference) when video enters powersafe state
https://bugzilla.kernel.org/show_bug.cgi?id=199139 --- Comment #23 from Nicholas Kazlauskas (nicholas.kazlaus...@amd.com) --- Does this still occur on kernels for 4.21 and higher? It isn't directly related to power management, but there are many of these classes of edge cases with atomic commit flow that get fixed with the following patches: https://patchwork.freedesktop.org/patch/263411/ https://patchwork.freedesktop.org/series/53324/ So I would be interested in knowing whether this is a separate issue. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 07/17] drm/sun4i: sun6i_mipi_dsi: Refactor vertical video start delay
On Mon, Jan 7, 2019 at 7:42 PM Maxime Ripard wrote: > > On Fri, Dec 21, 2018 at 02:26:11AM +0530, Jagan Teki wrote: > > On Tue, Dec 11, 2018 at 10:19 PM Maxime Ripard > > wrote: > > > > > > On Mon, Dec 10, 2018 at 09:47:19PM +0530, Jagan Teki wrote: > > > > Video start delay can be computed by subtracting total vertical > > > > timing with front porch timing and with adding 1 delay line for TCON. > > > > > > > > BSP code form BPI-M64-bsp is computing video start delay as > > > > (from linux-sunxi/ > > > > drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c) > > > > > > > > u32 vfp = panel->lcd_vt - panel->lcd_y - panel->lcd_vbp; > > > > => (panel->lcd_vt) - panel->lcd_y - (panel->lcd_vbp) > > > > => (timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y) > > > >- panel->lcd_y - (panel->lcd_vbp) > > > > => timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y > > > >- panel->lcd_y - panel->lcd_vbp > > > > => timmings->ver_front_porch > > > > > > > > So, update the start delay computation accordingly. > > > > > > > > Signed-off-by: Jagan Teki > > > > > > Even though it's a bit better now on my A33 board and I don't have the > > > white stripes on the bottom of the display, there's still some > > > flickering with your patches applied. > > > > > > Bisecting it seems to point at that patch, but reverting it doesn't > > > make the issue go away, so it's not really clear which one exactly is > > > at fault. > > > > Is reverting this patch, work fine or not? > > As I was saying, it doesn't. > > > This patch is trying to make use of front porch instead of existing > > back porch to compute the delay. Since we revert the VBP fix patch[1] > > to assume VBP as VFP value look like your setup would also require to > > revert this change. But as per BSP or drm_mode details all of my > > displays even work with and w/o reverting these two. > > Again, I cannot help you without the datasheet for the panels you're > trying to submit. The panel bound with Sitronix ST7701 IC http://www.startek-lcd.com/res/starteklcd/pdres/201705/20170512144242904.pdf ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201815] Mouse Pointer Disappears when touching top of the screen
https://bugzilla.kernel.org/show_bug.cgi?id=201815 --- Comment #12 from Nicholas Kazlauskas (nicholas.kazlaus...@amd.com) --- There's a fix for this bug coming soon. The bug only affects Raven systems and was a regression introduced in 4.20. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/10] drm/etnaviv: mmuv2: don't map zero page
Am Montag, den 07.01.2019, 10:13 +0100 schrieb Guido Günther: > Hi, > On Mon, Jan 07, 2019 at 09:50:52AM +0100, Lucas Stach wrote: > > Hi Guido, > > > > Am Sonntag, den 30.12.2018, 16:49 +0100 schrieb Guido Günther: > > > Hi Lucas, > > > On Wed, Dec 19, 2018 at 03:45:38PM +0100, Lucas Stach wrote: > > > > Keep the page at address 0 as faulting to catch any potential state > > > > setup issues early. > > > > > > This is a nice idea! But applying this and making mesa hit that page > > > leads to the process hanging in D state over here on GC7000: > > > > > > # [ 242.726192] INFO: task kworker/u8:2:37 blocked for more than 120 > > > seconds. > > > [ 242.733010] Not tainted 4.18.0-00129-gce2b21074b41 #504 > > > [ 242.738795] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" > > > disables this message. > > > [ 242.746638] kworker/u8:2D037 2 0x0028 > > > [ 242.752144] Workqueue: events_unbound commit_work > > > [ 242.756860] Call trace: > > > [ 242.759318] __switch_to+0x94/0xd0 > > > [ 242.762741] __schedule+0x1c0/0x6b8 > > > [ 242.766239] schedule+0x40/0xa8 > > > [ 242.769380] schedule_timeout+0x2f0/0x428 > > > [ 242.773410] dma_fence_default_wait+0x1cc/0x2b8 > > > [ 242.777951] dma_fence_wait_timeout+0x44/0x1b0 > > > [ 242.782403] drm_atomic_helper_wait_for_fences+0x48/0x108 > > > [ 242.787819] commit_tail+0x30/0x80 > > > [ 242.791229] commit_work+0x20/0x30 > > > [ 242.794642] process_one_work+0x1ec/0x458 > > > [ 242.798659] worker_thread+0x48/0x430 > > > [ 242.802331] kthread+0x130/0x138 > > > [ 242.805557] ret_from_fork+0x10/0x1c > > > > > > This is in dmesg showing that we hit the first page: > > > > > > [ 65.907388] etnaviv-gpu 3800.gpu: MMU fault status 0x0002 > > > [ 65.913497] etnaviv-gpu 3800.gpu: MMU 0 fault addr 0x0e40 > > > > > > Without that patch it's sampling random data from that page but does not > > > hang. > > > > GPU hangs after a MMU fault are expected or more accurately, we > > actively request the GPU to stop by setting the exception bit in the > > page table. > > Yeah. I put that in to show that this the cause for the trouble above. > > > > > A hanging GPU should trigger the scheduler timeout handler, which then > > makes sure to get the GPU back into a working state. So if things don't > > progress after the fault for you either the timeout handler is buggy on > > GC7000, or the fence signaling is broken somehow. I'll take a look at > > this. > > This isn't a top notch linux-next based tree yet so if you're not seeing this > let me forward port our stuff to that and report back again. I've certainly seen the timeout handler working on GC7000, but with the GC7000 support being relatively lightly tested right now, I wouldn't bet on us handling all corner cases correctly. If this is an issue on a recent kernel, I would certainly love to learn what's going wrong. Regards, Lucas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109239] Polaris10: Periodic random black screens for 1-2 seconds
https://bugs.freedesktop.org/show_bug.cgi?id=109239 --- Comment #3 from Raman Gupta --- Created attachment 143000 --> https://bugs.freedesktop.org/attachment.cgi?id=143000=edit dmesg without modesetting -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109239] Polaris10: Periodic random black screens for 1-2 seconds
https://bugs.freedesktop.org/show_bug.cgi?id=109239 --- Comment #2 from Raman Gupta --- Created attachment 142999 --> https://bugs.freedesktop.org/attachment.cgi?id=142999=edit dmesg with modesetting -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/5] Meson (32-bit): add support for the Mali GPU
On 08/12/2018 18:12, Martin Blumenstingl wrote: > This series adds support for the Mali-450 GPU on Meson8 and Meson8b. > Meson6 uses a Mali-400 GPU but since we don't have a clock driver (and > I don't have a device for testing) Meson6 is left out in this series. > > Meson8 uses a Mali-450 MP6 with six pixel processors. Meson8b (as > cost-reduced SoC) uses a Mali-450 MP2 with two pixel processors. > I tested both using the open source lima driver and a patched mesa > from the lima project as well. Since we don't have display support > on the 32-bit SoCs I used off-screen rendering as described in [0]. > The result is (for example): [1] > > The bootloader (at least on my boards) leaves the Mali clock disabled > by default. The board crashes when trying to access the Mali registers > with the "core" clock disabled. > Thus this series also implements the required clock driver changes. The > Mali clock tree on Meson8b and Meson8m2 is almost identical to the one > on GXBB (see the description of patch #3 for more details). Only Meson8 > is slightly different as it doesn't have a glitch-free mux. Patch #2 > prepares the meson8b clock driver so we can have different clocks per > SoC. > > Dependencies: > - the .dts changes depend on my other series "ARM: dts: meson: add the > APB/APB2 busses" from [2] > - the .dts changes from this series have no compile-time dependency on > the clock driver changes because CLKID_MALI was defined in the > dt-bindings since the first version of the clock driver (but it was > not used until now). > - the .dts changes from this series have a runtime dependency on the > clock driver changes (also from this series) if you have a kernel > patched with the lima driver (without the lima driver there's no > runtime dependency) > > Other notes: > By default the GPU runs off the XTAL clock (24MHz). The lima driver > currently does not update the GPU clock rate. Different frequencies > have to be requested by adding the following properties to the Mali > GPU node (to run it at 510MHz for example): > assigned-clocks = < CLKID_MALI>; > assigned-clock-rates = <51000>; > > > [0] https://gitlab.freedesktop.org/lima/web/wikis/home > [1] https://abload.de/img/dump0myic0.png > [2] https://patchwork.kernel.org/cover/10719445/ > > > Martin Blumenstingl (5): > dt-bindings: gpu: mali-utgard: add Amlogic Meson8 and Meson8b > compatible > clk: meson: meson8b: use a separate clock table for Meson8 > clk: meson: meson8b: add the GPU clock tree > ARM: dts: meson8: add the Mali-450 MP6 GPU > ARM: dts: meson8b: add the Mali-450 MP2 GPU > > .../bindings/gpu/arm,mali-utgard.txt | 6 + > arch/arm/boot/dts/meson8.dtsi | 58 +++ > arch/arm/boot/dts/meson8b.dtsi| 46 +++ > drivers/clk/meson/meson8b.c | 349 +- > drivers/clk/meson/meson8b.h | 9 +- > 5 files changed, 461 insertions(+), 7 deletions(-) > Applied patches 2 & 3 to next/drivers for Linux 5.1 Kevin, have fun with the other patches ! Neil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109239] Polaris10: Periodic random black screens for 1-2 seconds
https://bugs.freedesktop.org/show_bug.cgi?id=109239 --- Comment #1 from Raman Gupta --- Created attachment 142998 --> https://bugs.freedesktop.org/attachment.cgi?id=142998=edit Xorg.0.log without modesetting -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109239] Polaris10: Periodic random black screens for 1-2 seconds
https://bugs.freedesktop.org/show_bug.cgi?id=109239 Bug ID: 109239 Summary: Polaris10: Periodic random black screens for 1-2 seconds Product: DRI Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: rocketra...@gmail.com Created attachment 142997 --> https://bugs.freedesktop.org/attachment.cgi?id=142997=edit Xorg.0.log with modesetting I have 3 Dell WQHD Screens (2560x1440) screens, connected to a Radeon RX580 (XFX, RX-580 GTS Black Edition, 1425 MHz 8GB), running on Fedora 29. My kernel is: Linux edison 4.19.13-300.fc29.x86_64 #1 SMP Sat Dec 29 22:54:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux On 2/3 monitors I get periodic random black screens for 1-2 seconds. The display comes back and all appears normal after this happens. I have tried both with and without modesetting enabled. Nothing at all appears in either the kernel log when this happens, or in Xorg.0.log. I have attached complete Xorg.0.log's and the relevant parts of dmesg (from boot to the very last drm-related message). I was sure this was a hardware issue, and after a debugging process with XFX support in which they had me swapping monitors and cables, they RMAed my card and sent me a new one. However, the new card has very similar behavior (the old card seemed to black screen only one monitor, the new seems to do two of them, but in exactly the same way, and I have also updated my kernel and OS since then, so its possible the hardware is completely unrelated to the minor change in behavior). Given the change in hardware, it seems likely to me this is a driver bug rather than a hardware one. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v5 2/3] drm/i915: Move on the new pm runtime interface
On Mon, Jan 7, 2019 at 3:04 PM Vincent Guittot wrote: > > Hi Tvrtko, > > On Mon, 31 Dec 2018 at 13:32, Tvrtko Ursulin > wrote: > > > > > > On 21/12/2018 13:26, Vincent Guittot wrote: > > > On Fri, 21 Dec 2018 at 12:33, Tvrtko Ursulin > > [snip] > > > >> > > >> If it is always monotonic, then worst case we report one wrong sample, > > >> which I guess is still not ideal since someone could be querying the PMU > > >> with quite low frequency. > > >> > > >> There are tests which probably can hit this, but to run them > > >> automatically your patches would need to be rebased on drm-tip and maybe > > >> sent to our trybot. I can do that after the holiday break if you are > > >> okay with having the series waiting until then. > > > > > > yes looks good to me > > > > Looks good to me as well. And our CI agrees with it. So: > > > > Reviewed-by: Tvrtko Ursulin > > Thanks for the review and the test > > > > > I assume you will take the patch through some power related tree and we > > will eventually pull it back to drm-tip. > > Rafael, > How do you want to proceed with this patch and the 2 others of the serie ? I'm going to queue up the whole series for 5.1. Thanks! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/2] drm/sched: Refactor ring mirror list handling.
Am 03.01.19 um 18:42 schrieb Grodzovsky, Andrey:
On 01/03/2019 11:20 AM, Grodzovsky, Andrey wrote:
On 01/03/2019 03:54 AM, Koenig, Christian wrote:
Am 21.12.18 um 21:36 schrieb Grodzovsky, Andrey:
On 12/21/2018 01:37 PM, Christian König wrote:
Am 20.12.18 um 20:23 schrieb Andrey Grodzovsky:
Decauple sched threads stop and start and ring mirror
list handling from the policy of what to do about the
guilty jobs.
When stoppping the sched thread and detaching sched fences
from non signaled HW fenes wait for all signaled HW fences
to complete before rerunning the jobs.
v2: Fix resubmission of guilty job into HW after refactoring.
v4:
Full restart for all the jobs, not only from guilty ring.
Extract karma increase into standalone function.
v5:
Rework waiting for signaled jobs without relying on the job
struct itself as those might already be freed for non 'guilty'
job's schedulers.
Expose karma increase to drivers.
Suggested-by: Christian Koenig
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 18 +--
drivers/gpu/drm/etnaviv/etnaviv_sched.c | 11 +-
drivers/gpu/drm/scheduler/sched_main.c | 188
+++--
drivers/gpu/drm/v3d/v3d_sched.c | 12 +-
include/drm/gpu_scheduler.h | 10 +-
5 files changed, 151 insertions(+), 88 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 8a078f4..a4bd2d3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3298,12 +3298,10 @@ static int
amdgpu_device_pre_asic_reset(struct amdgpu_device *adev,
if (!ring || !ring->sched.thread)
continue;
- kthread_park(ring->sched.thread);
+ drm_sched_stop(>sched, job ? >base : NULL);
- if (job && job->base.sched != >sched)
- continue;
-
- drm_sched_hw_job_reset(>sched, job ? >base : NULL);
+ if(job)
+ drm_sched_increase_karma(>base);
Since we dropped the "job && job->base.sched != >sched" check
above this will now increase the jobs karma multiple times.
Maybe just move that outside of the loop.
/* after all hw jobs are reset, hw fence is meaningless,
so force_completion */
amdgpu_fence_driver_force_completion(ring);
@@ -3454,14 +3452,10 @@ static void
amdgpu_device_post_asic_reset(struct amdgpu_device *adev,
if (!ring || !ring->sched.thread)
continue;
- /* only need recovery sched of the given job's ring
- * or all rings (in the case @job is NULL)
- * after above amdgpu_reset accomplished
- */
- if ((!job || job->base.sched == >sched) &&
!adev->asic_reset_res)
- drm_sched_job_recovery(>sched);
+ if (!adev->asic_reset_res)
+ drm_sched_resubmit_jobs(>sched);
- kthread_unpark(ring->sched.thread);
+ drm_sched_start(>sched, !adev->asic_reset_res);
}
if (!amdgpu_device_has_dc_support(adev)) {
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
index 49a6763..6f1268f 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
@@ -109,16 +109,19 @@ static void etnaviv_sched_timedout_job(struct
drm_sched_job *sched_job)
}
/* block scheduler */
- kthread_park(gpu->sched.thread);
- drm_sched_hw_job_reset(>sched, sched_job);
+ drm_sched_stop(>sched, sched_job);
+
+ if(sched_job)
+ drm_sched_increase_karma(sched_job);
/* get the GPU back into the init state */
etnaviv_core_dump(gpu);
etnaviv_gpu_recover_hang(gpu);
+ drm_sched_resubmit_jobs(>sched);
+
/* restart scheduler after GPU is usable again */
- drm_sched_job_recovery(>sched);
- kthread_unpark(gpu->sched.thread);
+ drm_sched_start(>sched, true);
}
static void etnaviv_sched_free_job(struct drm_sched_job *sched_job)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index dbb6906..b5c5bee 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -60,8 +60,6 @@
static void drm_sched_process_job(struct dma_fence *f, struct
dma_fence_cb *cb);
-static void drm_sched_expel_job_unlocked(struct drm_sched_job
*s_job);
-
/**
* drm_sched_rq_init - initialize a given run queue struct
*
@@ -335,6 +333,42 @@ static void drm_sched_job_timedout(struct
work_struct *work)
spin_unlock_irqrestore(>job_list_lock, flags);
}
Kernel doc here would be nice to have.
+void drm_sched_increase_karma(struct drm_sched_job *bad)
+{
+ int i;
+ struct drm_sched_entity *tmp;
+ struct drm_sched_entity *entity;
+ struct drm_gpu_scheduler *sched = bad->sched;
+
+ /*
Re: [PATCH v5 07/17] drm/sun4i: sun6i_mipi_dsi: Refactor vertical video start delay
On Fri, Dec 21, 2018 at 02:26:11AM +0530, Jagan Teki wrote: > On Tue, Dec 11, 2018 at 10:19 PM Maxime Ripard > wrote: > > > > On Mon, Dec 10, 2018 at 09:47:19PM +0530, Jagan Teki wrote: > > > Video start delay can be computed by subtracting total vertical > > > timing with front porch timing and with adding 1 delay line for TCON. > > > > > > BSP code form BPI-M64-bsp is computing video start delay as > > > (from linux-sunxi/ > > > drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c) > > > > > > u32 vfp = panel->lcd_vt - panel->lcd_y - panel->lcd_vbp; > > > => (panel->lcd_vt) - panel->lcd_y - (panel->lcd_vbp) > > > => (timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y) > > >- panel->lcd_y - (panel->lcd_vbp) > > > => timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y > > >- panel->lcd_y - panel->lcd_vbp > > > => timmings->ver_front_porch > > > > > > So, update the start delay computation accordingly. > > > > > > Signed-off-by: Jagan Teki > > > > Even though it's a bit better now on my A33 board and I don't have the > > white stripes on the bottom of the display, there's still some > > flickering with your patches applied. > > > > Bisecting it seems to point at that patch, but reverting it doesn't > > make the issue go away, so it's not really clear which one exactly is > > at fault. > > Is reverting this patch, work fine or not? As I was saying, it doesn't. > This patch is trying to make use of front porch instead of existing > back porch to compute the delay. Since we revert the VBP fix patch[1] > to assume VBP as VFP value look like your setup would also require to > revert this change. But as per BSP or drm_mode details all of my > displays even work with and w/o reverting these two. Again, I cannot help you without the datasheet for the panels you're trying to submit. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v5 2/3] drm/i915: Move on the new pm runtime interface
Hi Tvrtko, On Mon, 31 Dec 2018 at 13:32, Tvrtko Ursulin wrote: > > > On 21/12/2018 13:26, Vincent Guittot wrote: > > On Fri, 21 Dec 2018 at 12:33, Tvrtko Ursulin [snip] > >> > >> If it is always monotonic, then worst case we report one wrong sample, > >> which I guess is still not ideal since someone could be querying the PMU > >> with quite low frequency. > >> > >> There are tests which probably can hit this, but to run them > >> automatically your patches would need to be rebased on drm-tip and maybe > >> sent to our trybot. I can do that after the holiday break if you are > >> okay with having the series waiting until then. > > > > yes looks good to me > > Looks good to me as well. And our CI agrees with it. So: > > Reviewed-by: Tvrtko Ursulin Thanks for the review and the test > > I assume you will take the patch through some power related tree and we > will eventually pull it back to drm-tip. Rafael, How do you want to proceed with this patch and the 2 others of the serie ? Regards, Vincent > > Regards, > > Tvrtko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/7] drm/komeda: Add d71_enum_resources and d71_cleanup
Hi James,
A few minor comments.
On Mon, Dec 24, 2018 at 08:58:46AM +, james qian wang (Arm Technology
China) wrote:
> D71 consists of a number of Register Blocks, every Block controls a
> specific HW function, every block has a common block_header to represent
> its type and pipeline information.
>
> GCU (Global Control Unit) is the first Block which describe the global
> information of D71 HW, Like number of block contained and the number of
> pipeline supported.
>
> So the d71_enum_resources parsed GCU and create pipeline according
> the GCU configuration, and then iterate and detect the blocks that
> indicated by the GCU and block_header.
>
> And this change also added two struct d71_dev/d71_pipeline to extend
> komeda_dev/komeda_pipeline to add some d71 only members.
>
> Signed-off-by: James (Qian) Wang
> ---
-- snip --
> diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> new file mode 100644
> index ..a43a2410159f
> --- /dev/null
> +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> @@ -0,0 +1,120 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * (C) COPYRIGHT 2018 ARM Limited. All rights reserved.
> + * Author: James.Qian.Wang
> + *
> + */
> +#include "d71_dev.h"
> +#include "komeda_kms.h"
> +#include "malidp_io.h"
> +
> +static int d71_layer_init(struct d71_dev *d71,
> + struct block_header *blk, u32 __iomem *reg)
> +{
> + DRM_INFO("Detect D71_Layer.\n");
I think all of these can be DRM_DEBUG.
-- snip --
>
> static int d71_enum_resources(struct komeda_dev *mdev)
> {
> - /* TODO add enum resources */
> + struct d71_dev *d71;
> + struct komeda_pipeline *pipe;
> + struct block_header blk;
> + u32 __iomem *blk_base;
> + u32 i, value, offset;
> +
> + d71 = devm_kzalloc(mdev->dev, sizeof(*d71), GFP_KERNEL);
> + if (!d71)
> + return -ENOMEM;
> +
> + mdev->chip_data = d71;
> + d71->mdev = mdev;
> + d71->gcu_addr = mdev->reg_base;
> + d71->periph_addr = mdev->reg_base + (D71_BLOCK_OFFSET_PERIPH >> 2);
> +
> + if (d71_reset(d71)) {
> + DRM_ERROR("Fail to reset d71 device.\n");
> + goto err_cleanup;
> + }
> +
> + /* probe GCU */
> + value = malidp_read32(d71->gcu_addr, GLB_CORE_INFO);
> + d71->num_blocks = value & 0xFF;
> + d71->num_pipelines = (value >> 8) & 0x7;
> +
> + if (d71->num_pipelines > D71_MAX_PIPELINE) {
> + DRM_ERROR("d71 supports %d pipelines, but got: %d.\n",
> + D71_MAX_PIPELINE, d71->num_pipelines);
> + goto err_cleanup;
> + }
> +
> + /* probe PERIPH */
> + value = malidp_read32(d71->periph_addr, BLK_BLOCK_INFO);
> + if (BLOCK_INFO_BLK_TYPE(value) != D71_BLK_TYPE_PERIPH) {
> + DRM_ERROR("access blk periph but got blk: %d.\n",
> + BLOCK_INFO_BLK_TYPE(value));
> + goto err_cleanup;
> + }
> +
> + value = malidp_read32(d71->periph_addr, PERIPH_CONFIGURATION_ID);
> +
> + d71->max_line_size = value & PERIPH_MAX_LINE_SIZE ? 4096 : 2048;
> + d71->max_vsize = 4096;
> + d71->num_rich_layers= value & PERIPH_NUM_RICH_LAYERS ? 2 : 1;
> + d71->supports_dual_link = value & PERIPH_SPLIT_EN ? true : false;
> + d71->integrates_tbu = value & PERIPH_TBU_EN ? true : false;
> +
> + for (i = 0; i < d71->num_pipelines; i++) {
> + pipe = komeda_pipeline_add(mdev, sizeof(struct d71_pipeline),
> +NULL);
> + if (!pipe)
> + goto err_cleanup;
> +
> + d71->pipes[i] = to_d71_pipeline(pipe);
> + }
> +
> + /* loop the register blks and probe */
> + i = 2; /* exclude GCU and PERIPH */
> + offset = D71_BLOCK_SIZE; /* skip GCU */
> + while (i < d71->num_blocks) {
> + blk_base = mdev->reg_base + (offset >> 2);
> +
> + d71_read_block_header(blk_base, );
> + if (BLOCK_INFO_BLK_TYPE(blk.block_info) !=
> D71_BLK_TYPE_RESERVED) {
> + if (d71_probe_block(d71, , blk_base))
> + goto err_cleanup;
> + i++;
> + }
> +
> + offset += D71_BLOCK_SIZE;
> + }
> +
> + DRM_INFO("total %d (out of %d) blocks are found.\n",
> + i, d71->num_blocks);
> +
> + return 0;
> +
> +err_cleanup:
> + d71_cleanup(mdev);
> return -1;
-1 isn't a useful error code, and you return -ENOMEM if allocation
fails. It would probably be better to return proper codes everywhere
(e.g. you might get -EINVAL back from d71_probe_block, but you don't
propagate it).
-- snip --
> diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h
> b/drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h
> new file mode 100644
> index ..2d5e6d00b42c
> --- /dev/null
> +++
Re: "flip_done timed out" messages causing huge increase in boot time
On Sat, Jan 05, 2019 at 12:47:12AM +0100, Daniel Kamil Kozar wrote:
> Hello.
> After upgrading the kernel to 4.20, I noticed that the boot time
> increased from about 5 seconds to 25 seconds. My machine is an Asus
> K53SV with an Intel i7-2630QM, i.e. Sandy Bridge. I have an external
> display connected to it via HDMI. If the display is unplugged when
> booting the machine, the boot time stays at its old value.
> The kernel log shows two messages like this :
>
> [ 15.747206] [drm:drm_atomic_helper_wait_for_flip_done
> [drm_kms_helper]] *ERROR* [CRTC:39:pipe A] flip_done timed out
> [ 26.198968] [drm:drm_atomic_helper_wait_for_dependencies
> [drm_kms_helper]] *ERROR* [CRTC:39:pipe A] flip_done timed out
Hrm. With SNB I would be tempted to blame the LP3 watermarks, but
4.20 already has commit 21556350ade3 ("drm/i915: Disable LP3 watermarks
on all SNB machines").
Can you file a bug at
https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel
and attach the full dmesg from the boot with drm.debug=0xe passed to the
kernel cmdline?
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/rockchip: Fix YUV buffers color rendering
Hi,
sorry, only now got to test this on actual hardware,
Am Freitag, 14. Dezember 2018, 17:29:20 CET schrieb Ezequiel Garcia:
> From: Daniele Castagna
>
> Currently, YUV hardware overlays are converted to RGB using
> a color space conversion different than BT.601.
>
> The result is that colors of e.g. NV12 buffers don't match
> colors of YUV hardware overlays.
>
> In order to fix this, enable YUV2YUV and set appropriate coefficients
> for formats such as NV12 to be displayed correctly.
>
> This commit was tested using modetest, gstreamer and chromeos (hardware
> accelerated video playback). Before the commit, tests rendering
> with NV12 format resulted in colors not displayed correctly.
>
> Test examples (RK3399 Ficus board connected to HDMI monitor):
>
> $ modetest 39@32:1920x1080@NV12
> $ gst-launch-1.0 videotestrc ! video/x-raw,format=NV12 ! kmssink
>
> Signed-off-by: Daniele Castagna
> [ezequiel: rebase on linux-next and massage commit log]
> Signed-off-by: Ezequiel Garcia
> ---
> v2:
> * Addressed feedback from Sean Paul
> * Rebased on linux-next
>
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 41 -
> drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 13 +++
> drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 36 ++
> 3 files changed, 89 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index fb70fb486fbf..78c7f63a60c0 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -52,6 +52,18 @@
> vop_reg_set(vop, >phy->scl->ext->name, \
> win->base, ~0, v, #name)
>
> +#define VOP_WIN_YUV2YUV_SET(x, win_yuv2yuv, name, v) \
> + do { \
> + if (win_yuv2yuv->name.mask) \
> + vop_reg_set(vop, _yuv2yuv->name, 0, ~0, v, #name); \
> + } while (0)
> +
> +#define VOP_WIN_YUV2YUV_COEFFICIENT_SET(x, win_yuv2yuv, name, v) \
> + do { \
> + if (win_yuv2yuv->phy->name.mask) \
> + vop_reg_set(vop, _yuv2yuv->phy->name,
> win_yuv2yuv->base, ~0, v, #name); \
> + } while (0)
> +
While this seems to work on rk3399, it hangs both my rk3328 (rock64)
and rk3288 (google-pinky) during rockchip-drm probe.
Making this something like
if (win_yuv2yuv && win_yuv2yuv->phy->name.mask) \
aka testing for existence of win_yuv2yuv first, makes them boot again,
so I guess I ran into a (for whatever reason) silent null-ptr-dereference.
> diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> index 08fc40af52c8..fe752df4e038 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> @@ -637,6 +637,34 @@ static const struct vop_output rk3399_output = {
> .mipi_dual_channel_en = VOP_REG(RK3288_SYS_CTRL, 0x1, 3),
> };
>
> +static const struct vop_yuv2yuv_phy rk3399_yuv2yuv_win01_data = {
> + .y2r_coefficients = {
> + VOP_REG(RK3399_WIN0_YUV2YUV_Y2R + 0, 0x, 0),
> + VOP_REG(RK3399_WIN0_YUV2YUV_Y2R + 0, 0x, 16),
> + VOP_REG(RK3399_WIN0_YUV2YUV_Y2R + 4, 0x, 0),
> + VOP_REG(RK3399_WIN0_YUV2YUV_Y2R + 4, 0x, 16),
> + VOP_REG(RK3399_WIN0_YUV2YUV_Y2R + 8, 0x, 0),
> + VOP_REG(RK3399_WIN0_YUV2YUV_Y2R + 8, 0x, 16),
> + VOP_REG(RK3399_WIN0_YUV2YUV_Y2R + 12, 0x, 0),
> + VOP_REG(RK3399_WIN0_YUV2YUV_Y2R + 12, 0x, 16),
> + VOP_REG(RK3399_WIN0_YUV2YUV_Y2R + 16, 0x, 0),
> + VOP_REG(RK3399_WIN0_YUV2YUV_Y2R + 20, 0x, 0),
> + VOP_REG(RK3399_WIN0_YUV2YUV_Y2R + 24, 0x, 0),
> + VOP_REG(RK3399_WIN0_YUV2YUV_Y2R + 28, 0x, 0),
> + },
> +};
> +
> +static const struct vop_yuv2yuv_phy rk3399_yuv2yuv_win23_data = { };
looking at the rk3399 TRM it seems that win2+3 also have yuv2rgb
coefficient registers. I didn't check in depth but are they so different
that they cannot be supported?
Aka what is the difference between win0/1 and win2/3 ?
Heiko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/omap: fix typo
Fix spelling mistake: "lenght" -> "length" Signed-off-by: Matteo Croce --- drivers/gpu/drm/omapdrm/dss/hdmi4_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c b/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c index 813ba42f2753..e384b95ad857 100644 --- a/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c @@ -708,7 +708,7 @@ int hdmi4_audio_config(struct hdmi_core_data *core, struct hdmi_wp_data *wp, else acore.i2s_cfg.justification = HDMI_AUDIO_JUSTIFY_RIGHT; /* -* The I2S input word length is twice the lenght given in the IEC-60958 +* The I2S input word length is twice the length given in the IEC-60958 * status word. If the word size is greater than * 20 bits, increment by one. */ -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] amdgpu: Allow amdgpu device creation without merging fds.
Am 07.01.19 um 14:05 schrieb Bas Nieuwenhuizen: > On Mon, Jan 7, 2019 at 1:23 PM Christian König > wrote: >> Am 06.01.19 um 21:29 schrieb Bas Nieuwenhuizen: >>> On Sun, Jan 6, 2019 at 9:23 PM Christian König >>> wrote: Am 06.01.19 um 10:46 schrieb Bas Nieuwenhuizen: > For radv we want to be able to pass in a master fd and be sure that > the created libdrm_amdgpu device also uses that master fd, so we can > use it for prioritized submission. > > radv does all interaction with other APIs/processes with dma-bufs, > so we should not need the functionality in libdrm_amdgpu to only have > a single fd for a device in the process. > > Signed-off-by: Bas Nieuwenhuizen Well NAK. This breaks a couple of design assumptions we used for the kernel driver and is strongly discouraged. >>> What assumptions are these? As far as I can tell everything is per drm >>> fd, not process? Instead radv should not use the master fd for command submission. >>> High priority submission needs to be done through a master fd >> That assumption is incorrect. See file >> drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c to answer both your questions >> at the same time. > Hmm, I did not know about the AMDGPU_SCHED ioctl. That would work with > the permissions. However as it stands we cannot use it, as it is for > the entire drm-fd, not per context. > > Would you be open to a patch adding a context parameter to the struct > and a AMDGPU_SCHED_OP_CONTEXT_PRIORITY_OVERRIDE? Certainly yeah. Overriding the whole process priority was never my favorite approach. Regards, Christian. PS: I'm at the start of a bad cold / sinusitis, so sorry if my responses are short and maybe delayed. > >> Additional to the scheduler priority we really don't want more than one >> fd in a process because of SVM binding overhead. >> >> So that whole approach is a really big NAK. >> >> Regards, >> Christian. >> >>> , so not >>> using a master fd is not an option ... >>> Regards, Christian. > --- > amdgpu/amdgpu-symbol-check | 1 + > amdgpu/amdgpu.h| 37 > amdgpu/amdgpu_device.c | 59 -- > 3 files changed, 76 insertions(+), 21 deletions(-) > > diff --git a/amdgpu/amdgpu-symbol-check b/amdgpu/amdgpu-symbol-check > index 6f5e0f95..bbf48985 100755 > --- a/amdgpu/amdgpu-symbol-check > +++ b/amdgpu/amdgpu-symbol-check > @@ -56,6 +56,7 @@ amdgpu_cs_wait_fences > amdgpu_cs_wait_semaphore > amdgpu_device_deinitialize > amdgpu_device_initialize > +amdgpu_device_initialize2 > amdgpu_find_bo_by_cpu_mapping > amdgpu_get_marketing_name > amdgpu_query_buffer_size_alignment > diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h > index dc51659a..e5ed39bb 100644 > --- a/amdgpu/amdgpu.h > +++ b/amdgpu/amdgpu.h > @@ -66,6 +66,13 @@ struct drm_amdgpu_info_hw_ip; > */ > #define AMDGPU_QUERY_FENCE_TIMEOUT_IS_ABSOLUTE (1 << 0) > > +/** > + * Uses in amdgpu_device_initialize2(), meaning that the passed in fd > should > + * not be deduplicated against other libdrm_amdgpu devices referring to > the > + * same kernel device. > + */ > +#define AMDGPU_DEVICE_DEDICATED_FD (1 << 0) > + > > /*--*/ > /* - Enums > */ > > /*--*/ > @@ -526,6 +533,36 @@ int amdgpu_device_initialize(int fd, > uint32_t *minor_version, > amdgpu_device_handle *device_handle); > > +/** > + * > + * \param fd- \c [in] File descriptor for AMD GPU device > + * received previously as the result of > + * e.g. drmOpen() call. > + * For legacy fd type, the DRI2/DRI3 > + * authentication should be done before > + * calling this function. > + * \param flags - \c [in] Bitmask of flags for device > creation. > + * \param major_version - \c [out] Major version of library. It is > assumed > + * that adding new functionality will > cause > + * increase in major version > + * \param minor_version - \c [out] Minor version of library > + * \param device_handle - \c [out] Pointer to opaque context which > should > + * be passed as the first parameter on > each > + *
[PATCH] drm/amd: fix typo
Fix spelling mistake: "lenght" -> "length"
Signed-off-by: Matteo Croce
---
drivers/gpu/drm/amd/include/atombios.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/include/atombios.h
b/drivers/gpu/drm/amd/include/atombios.h
index 7931502fa54f..8ba21747b40a 100644
--- a/drivers/gpu/drm/amd/include/atombios.h
+++ b/drivers/gpu/drm/amd/include/atombios.h
@@ -4106,7 +4106,7 @@ typedef struct _ATOM_LCD_MODE_CONTROL_CAP
typedef struct _ATOM_FAKE_EDID_PATCH_RECORD
{
UCHAR ucRecordType;
- UCHAR ucFakeEDIDLength; // = 128 means EDID lenght is 128 bytes,
otherwise the EDID length = ucFakeEDIDLength*128
+ UCHAR ucFakeEDIDLength; // = 128 means EDID length is 128 bytes,
otherwise the EDID length = ucFakeEDIDLength*128
UCHAR ucFakeEDIDString[1];// This actually has ucFakeEdidLength elements.
} ATOM_FAKE_EDID_PATCH_RECORD;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
