[Bug 108937] [radeonsi, RX480] VAAPI H.264 decoder produces garbage on YouTube in Chromium with h264ify
https://bugs.freedesktop.org/show_bug.cgi?id=108937 --- Comment #6 from Christopher Snowhill --- I don't control the application, and it's already the latest version currently available. It's already a feature implemented by a patch that hasn't been accepted by upstream since it was submitted over a year ago. I've already emailed the maintainer of the PPA that I'm installing the Chromium beta from, and hoping they can point me where I should report it for inclusion in the patch set. -- 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 1/4] drm/edid: Pass connector to AVI inforframe functions
On 04.12.2018 20:02, Ville Syrjälä wrote:
> On Tue, Dec 04, 2018 at 08:03:53AM +0100, Andrzej Hajda wrote:
>> On 03.12.2018 22:48, Ville Syrjälä wrote:
>>> On Thu, Nov 29, 2018 at 09:46:16AM +0100, Andrzej Hajda wrote:
Quite late, hopefully not too late.
On 21.11.2018 12:51, Ville Syrjälä wrote:
> On Wed, Nov 21, 2018 at 01:40:43PM +0200, Jani Nikula wrote:
>>> return;
>>> diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c
>>> b/drivers/gpu/drm/bridge/sil-sii8620.c
>>> index a6e8f4591e63..0cc293a6ac24 100644
>>> --- a/drivers/gpu/drm/bridge/sil-sii8620.c
>>> +++ b/drivers/gpu/drm/bridge/sil-sii8620.c
>>> @@ -1104,8 +1104,7 @@ static void sii8620_set_infoframes(struct sii8620
>>> *ctx,
>>> int ret;
>>>
>>> ret = drm_hdmi_avi_infoframe_from_display_mode(,
>>> - mode,
>>> - true);
>>> + NULL, mode);
>>> if (ctx->use_packed_pixel)
>>> frm.avi.colorspace = HDMI_COLORSPACE_YUV422;
>>>
>>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> index 64c3cf027518..88b720b63126 100644
>>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> @@ -1344,7 +1344,8 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi,
>>> struct drm_display_mode *mode)
>>> u8 val;
>>>
>>> /* Initialise info frame from DRM mode */
>>> - drm_hdmi_avi_infoframe_from_display_mode(, mode, false);
>>> + drm_hdmi_avi_infoframe_from_display_mode(,
>>> +>connector,
>>> mode);
>>>
>>> if (hdmi_bus_fmt_is_yuv444(hdmi->hdmi_data.enc_out_bus_format))
>>> frame.colorspace = HDMI_COLORSPACE_YUV444;
>>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>>> index b506e3622b08..501ac05ba7da 100644
>>> --- a/drivers/gpu/drm/drm_edid.c
>>> +++ b/drivers/gpu/drm/drm_edid.c
>>> @@ -4830,19 +4830,32 @@ void drm_set_preferred_mode(struct
>>> drm_connector *connector,
>>> }
>>> EXPORT_SYMBOL(drm_set_preferred_mode);
>>>
>>> +static bool is_hdmi2_sink(struct drm_connector *connector)
>> You're usually known for adding const all around, why not const pointer
>> here and in all the other drm_* functions that call this?
> My current approach is to constify states/fbs/etc. but not so much
> crtcs/connectors/etc. Too much const can sometimes get in the way
> of things requiring that you remove the const later. But I guess
> in this case the const shouldn't really get in the way of anything
> because these are pretty much supposed to be pure functions.
>
>>> +{
>>> + /*
>>> +* FIXME: sil-sii8620 doesn't have a connector around when
>>> +* we need one, so we have to be prepared for a NULL connector.
>>> +*/
>>> + if (!connector)
>>> + return false;
>> This actually changes the is_hdmi2_sink value for sil-sii8620.
> Hmm. No idea why they would have set that to true when everyone else is
> passing false.
Because false does not work :) More precisely MHLv3 (used in Sii8620)
uses CTA-861-F standard for infoframes, which is specific to HDMI2.0.
Unfortunately I have no access to MHL specs, but my experiments and
vendor drivers strongly suggests it is done this way.
This is important in case of 4K modes which are handled differently by
HDMI 1.4 and HDMI2.0.
>>> HDMI 2.0 handles 4k just like 1.4 handled it when you use one of
>>> the 4k modes defined in 1.4. Only if you use features beyond 1.4 do we
>>> switch over to the HDMI 2.0 specific signalling.
>>
>> The difference is in infoframes:
>>
>> HDMI 1.4 sets AVI infoframe VIC to 0, and sends HDMI_VIC in VSI.
>>
>> HDMI 2.0 sets AVI infoframe to non zero VICs introduced by
>> HDMI2.0/CEA-861-F, VSI can be omitted if I remember correctly, unless 3d
>> is in use.
> Like I said, The HDMI 1.4 method is used even with HDMI 2.0 sinks unless
> some feature gets used which can't be signalled via the HDMI 1.4 vendor
> specific infoframe.
Do you mean that 4K VICs 95, 94, 93, 98 defined in CEA-861-F are not
used at all for non-3d video in HDMI 2.0?
Chapter 10.1 of HDMI2.0 spec says clearly:
> When transmitting any additional Video Format for which a VIC value
> has been defined in
> CEA-861-F tables 1, 2, and 3, an HDMI Source shall set the VIC field
> to the Video Code for
> that format.
It contradicts your statement, or am I missing something?
>
>>
>> So setting VICs to non-zero in case of HDMI1.4 sinks and 4k modes seems
>>
[Bug 108937] [radeonsi, RX480] VAAPI H.264 decoder produces garbage on YouTube in Chromium with h264ify
https://bugs.freedesktop.org/show_bug.cgi?id=108937 Christian König changed: What|Removed |Added Resolution|NOTOURBUG |DUPLICATE --- Comment #5 from Christian König --- *** This bug has been marked as a duplicate of bug 104597 *** -- 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 104597] [bisected] Compton weird colors
https://bugs.freedesktop.org/show_bug.cgi?id=104597 Christian König changed: What|Removed |Added CC||kod...@gmail.com --- Comment #18 from Christian König --- *** Bug 108937 has been marked as a duplicate of this 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
[Bug 108937] [radeonsi, RX480] VAAPI H.264 decoder produces garbage on YouTube in Chromium with h264ify
https://bugs.freedesktop.org/show_bug.cgi?id=108937 Christian König changed: What|Removed |Added Resolution|--- |NOTOURBUG Status|NEW |RESOLVED --- Comment #4 from Christian König --- Alternatively update the applications. The problem is that the driver exposes 10bit RGB and the applications selects that for some reason but actually can't handle it correctly. -- 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 1/4] drm/edid: Pass connector to AVI inforframe functions
Hi Ville, On Tuesday, 4 December 2018 21:13:20 EET Ville Syrjälä wrote: > On Tue, Dec 04, 2018 at 08:46:53AM +0100, Andrzej Hajda wrote: > > On 03.12.2018 22:38, Ville Syrjälä wrote: > >> On Thu, Nov 29, 2018 at 10:08:07AM +0100, Andrzej Hajda wrote: > >>> On 21.11.2018 19:19, Laurent Pinchart wrote: > On Tuesday, 20 November 2018 18:13:42 EET Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Make life easier for drivers by simply passing the connector > > to drm_hdmi_avi_infoframe_from_display_mode() and > > drm_hdmi_avi_infoframe_quant_range(). That way drivers don't > > need to worry about is_hdmi2_sink mess. > > While this is good for display controller drivers, the change isn't > great for bridge drivers. Down the road we're looking at moving > connector support out of the bridge drivers. Adding an additional > dependency to connectors in the bridges will make that more > difficult. Ideally bridges should retrieve the information from their > sink, regardless of whether it is a connector or another bridge. > >>> > >>> I agree with it, and case of sii8620 shows that there are cases where > >>> bridge has no direct access to the connector. > >> > >> It's just a matter of plumbing it through. > > > > What do you mean exactly? > > void bridge_foo(... > + ,struct drm_connector *connector); > > >>> On the other side, since you are passing connector to > >>> drm_hdmi_avi_infoframe_from_display_mode(), you could drop mode > >>> parameter and rename the function to > >>> drm_hdmi_avi_infoframe_from_connector() then, unless mode passed and > >>> mode set on the connector differs? > >> > >> Connectors don't have a mode. > > > > As they are passing video stream they should have it, even if not > > directly, for example: > > > > connector->state->crtc->mode > > That's not really how atomic works. One shouldn't go digging > through the obj->state pointers when we're not holding the > relevant locks anymore. The atomic way would be to pass either > both crtc state and connector state, or drm_atomic_state + > crtc/connector. Or a bridge state ? With chained bridges the mode can vary along the pipeline, the CRTC adjusted mode will only cover the link between the CRTC and the first bridge. It's only a matter of time until we need to store other intermediate modes in states. I'd rather prepare for that instead of passing the CRTC state to bridges. > > In moment of creating infoframe it should be set properly. > > > Please see below for an additional comment. > > > Cc: Alex Deucher > > Cc: "Christian König" > > Cc: "David (ChunMing) Zhou" > > Cc: Archit Taneja > > Cc: Andrzej Hajda > > Cc: Laurent Pinchart > > Cc: Inki Dae > > Cc: Joonyoung Shim > Cc: Seung-Woo Kim > > Cc: Kyungmin Park > > Cc: Russell King > > Cc: CK Hu > > Cc: Philipp Zabel > > Cc: Rob Clark > > Cc: Ben Skeggs > > Cc: Tomi Valkeinen > > Cc: Sandy Huang > > Cc: "Heiko Stübner" > > Cc: Benjamin Gaignard > > Cc: Vincent Abriou > > Cc: Thierry Reding > > Cc: Eric Anholt > > Cc: Shawn Guo > > Cc: Ilia Mirkin > > Cc: amd-...@lists.freedesktop.org > > Cc: linux-arm-...@vger.kernel.org > > Cc: freedr...@lists.freedesktop.org > > Cc: nouv...@lists.freedesktop.org > > Cc: linux-te...@vger.kernel.org > > Signed-off-by: Ville Syrjälä > > --- > > > > drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 2 +- > > drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 2 +- > > drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 3 ++- > > drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 +- > > drivers/gpu/drm/bridge/analogix-anx78xx.c | 5 ++-- > > drivers/gpu/drm/bridge/sii902x.c | 3 ++- > > drivers/gpu/drm/bridge/sil-sii8620.c | 3 +-- > > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 3 ++- > > drivers/gpu/drm/drm_edid.c| 33 > > drivers/gpu/drm/exynos/exynos_hdmi.c | 3 ++- > > drivers/gpu/drm/i2c/tda998x_drv.c | 3 ++- > > drivers/gpu/drm/i915/intel_hdmi.c | 14 +- > > drivers/gpu/drm/i915/intel_lspcon.c | 15 ++- > > drivers/gpu/drm/i915/intel_sdvo.c | 10 --- > > drivers/gpu/drm/mediatek/mtk_hdmi.c | 3 ++- > > drivers/gpu/drm/msm/hdmi/hdmi_bridge.c| 3 ++- > > drivers/gpu/drm/nouveau/dispnv50/disp.c | 7 +++-- > > drivers/gpu/drm/omapdrm/omap_encoder.c| 5 ++-- > > drivers/gpu/drm/radeon/radeon_audio.c | 2 +- > > drivers/gpu/drm/rockchip/inno_hdmi.c | 4 ++- > > drivers/gpu/drm/sti/sti_hdmi.c| 3 ++- > > drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c| 3 ++- > > drivers/gpu/drm/tegra/hdmi.c | 3 ++- > > drivers/gpu/drm/tegra/sor.c | 3 ++- > >
[PATCH v2 3/3] mm/mmu_notifier: contextual information for event triggering invalidation v2
From: Jérôme Glisse
CPU page table update can happens for many reasons, not only as a result
of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also
as a result of kernel activities (memory compression, reclaim, migration,
...).
Users of mmu notifier API track changes to the CPU page table and take
specific action for them. While current API only provide range of virtual
address affected by the change, not why the changes is happening.
This patchset adds event information so that users of mmu notifier can
differentiate among broad category:
- UNMAP: munmap() or mremap()
- CLEAR: page table is cleared (migration, compaction, reclaim, ...)
- PROTECTION_VMA: change in access protections for the range
- PROTECTION_PAGE: change in access protections for page in the range
- SOFT_DIRTY: soft dirtyness tracking
Being able to identify munmap() and mremap() from other reasons why the
page table is cleared is important to allow user of mmu notifier to
update their own internal tracking structure accordingly (on munmap or
mremap it is not longer needed to track range of virtual address as it
becomes invalid).
Changes since v1:
- use mmu_notifier_range_init() helper to to optimize out the case
when mmu notifier is not enabled
- use kernel doc format for describing the enum values
Signed-off-by: Jérôme Glisse
Acked-by: Christian König
Cc: Andrew Morton
Cc: Matthew Wilcox
Cc: Ross Zwisler
Cc: Jan Kara
Cc: Dan Williams
Cc: Paolo Bonzini
Cc: Radim Krčmář
Cc: Michal Hocko
Cc: Felix Kuehling
Cc: Ralph Campbell
Cc: John Hubbard
Cc: k...@vger.kernel.org
Cc: linux-r...@vger.kernel.org
Cc: linux-fsde...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
---
fs/dax.c | 7 +++
fs/proc/task_mmu.c | 3 ++-
include/linux/mmu_notifier.h | 35 +--
kernel/events/uprobes.c | 3 ++-
mm/huge_memory.c | 12
mm/hugetlb.c | 10 ++
mm/khugepaged.c | 3 ++-
mm/ksm.c | 6 --
mm/madvise.c | 3 ++-
mm/memory.c | 18 --
mm/migrate.c | 5 +++--
mm/mprotect.c| 3 ++-
mm/mremap.c | 3 ++-
mm/oom_kill.c| 2 +-
mm/rmap.c| 6 --
15 files changed, 90 insertions(+), 29 deletions(-)
diff --git a/fs/dax.c b/fs/dax.c
index 874085bacaf5..6056b03a1626 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -768,6 +768,13 @@ static void dax_entry_mkclean(struct address_space
*mapping, pgoff_t index,
address = pgoff_address(index, vma);
+ /*
+* All the field are populated by follow_pte_pmd() except
+* the event field.
+*/
+ mmu_notifier_range_init(, NULL, 0, -1UL,
+ MMU_NOTIFY_PROTECTION_PAGE);
+
/*
* Note because we provide start/end to follow_pte_pmd it will
* call mmu_notifier_invalidate_range_start() on our behalf
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index b3ddceb003bc..f68a9ebb0218 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -1141,7 +1141,8 @@ static ssize_t clear_refs_write(struct file *file, const
char __user *buf,
break;
}
- mmu_notifier_range_init(, mm, 0, -1UL);
+ mmu_notifier_range_init(, mm, 0, -1UL,
+ MMU_NOTIFY_SOFT_DIRTY);
mmu_notifier_invalidate_range_start();
}
walk_page_range(0, mm->highest_vm_end, _refs_walk);
diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
index 39b06772427f..d249e24acea5 100644
--- a/include/linux/mmu_notifier.h
+++ b/include/linux/mmu_notifier.h
@@ -25,10 +25,39 @@ struct mmu_notifier_mm {
spinlock_t lock;
};
+/**
+ * enum mmu_notifier_event - reason for the mmu notifier callback
+ * @MMU_NOTIFY_UNMAP: either munmap() that unmap the range or a mremap() that
+ * move the range
+ *
+ * @MMU_NOTIFY_CLEAR: clear page table entry (many reasons for this like
+ * madvise() or replacing a page by another one, ...).
+ *
+ * @MMU_NOTIFY_PROTECTION_VMA: update is due to protection change for the range
+ * ie using the vma access permission (vm_page_prot) to update the whole range
+ * is enough no need to inspect changes to the CPU page table (mprotect()
+ * syscall)
+ *
+ * @MMU_NOTIFY_PROTECTION_PAGE: update is due to change in read/write flag for
+ * pages in the range so to mirror those changes the user must inspect the CPU
+ * page table (from the end callback).
+ *
+ * @MMU_NOTIFY_SOFT_DIRTY: soft dirty accounting (still same page and same
+ * access flags)
+ */
+enum mmu_notifier_event {
+ MMU_NOTIFY_UNMAP = 0,
+
[PATCH v2 1/3] mm/mmu_notifier: use structure for invalidate_range_start/end callback
From: Jérôme Glisse
To avoid having to change many callback definition everytime we want
to add a parameter use a structure to group all parameters for the
mmu_notifier invalidate_range_start/end callback. No functional changes
with this patch.
Signed-off-by: Jérôme Glisse
Cc: Andrew Morton
Cc: Matthew Wilcox
Cc: Ross Zwisler
Cc: Jan Kara
Cc: Dan Williams
Cc: Paolo Bonzini
Cc: Radim Krčmář
Cc: Michal Hocko
Cc: Christian Koenig
Cc: Felix Kuehling
Cc: Ralph Campbell
Cc: John Hubbard
Cc: k...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-r...@vger.kernel.org
Cc: linux-fsde...@vger.kernel.org
---
drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c | 43 +++--
drivers/gpu/drm/i915/i915_gem_userptr.c | 14
drivers/gpu/drm/radeon/radeon_mn.c | 16 -
drivers/infiniband/core/umem_odp.c | 20 +---
drivers/infiniband/hw/hfi1/mmu_rb.c | 13 +++-
drivers/misc/mic/scif/scif_dma.c| 11 ++-
drivers/misc/sgi-gru/grutlbpurge.c | 14
drivers/xen/gntdev.c| 12 +++
include/linux/mmu_notifier.h| 14 +---
mm/hmm.c| 23 ++---
mm/mmu_notifier.c | 21 ++--
virt/kvm/kvm_main.c | 14 +++-
12 files changed, 102 insertions(+), 113 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
index e55508b39496..5bc7e59a05a1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
@@ -246,36 +246,34 @@ static void amdgpu_mn_invalidate_node(struct
amdgpu_mn_node *node,
* potentially dirty.
*/
static int amdgpu_mn_invalidate_range_start_gfx(struct mmu_notifier *mn,
-struct mm_struct *mm,
-unsigned long start,
-unsigned long end,
-bool blockable)
+ const struct mmu_notifier_range *range)
{
struct amdgpu_mn *amn = container_of(mn, struct amdgpu_mn, mn);
struct interval_tree_node *it;
+ unsigned long end;
/* notification is exclusive, but interval is inclusive */
- end -= 1;
+ end = range->end - 1;
/* TODO we should be able to split locking for interval tree and
* amdgpu_mn_invalidate_node
*/
- if (amdgpu_mn_read_lock(amn, blockable))
+ if (amdgpu_mn_read_lock(amn, range->blockable))
return -EAGAIN;
- it = interval_tree_iter_first(>objects, start, end);
+ it = interval_tree_iter_first(>objects, range->start, end);
while (it) {
struct amdgpu_mn_node *node;
- if (!blockable) {
+ if (!range->blockable) {
amdgpu_mn_read_unlock(amn);
return -EAGAIN;
}
node = container_of(it, struct amdgpu_mn_node, it);
- it = interval_tree_iter_next(it, start, end);
+ it = interval_tree_iter_next(it, range->start, end);
- amdgpu_mn_invalidate_node(node, start, end);
+ amdgpu_mn_invalidate_node(node, range->start, end);
}
return 0;
@@ -294,39 +292,38 @@ static int amdgpu_mn_invalidate_range_start_gfx(struct
mmu_notifier *mn,
* are restorted in amdgpu_mn_invalidate_range_end_hsa.
*/
static int amdgpu_mn_invalidate_range_start_hsa(struct mmu_notifier *mn,
-struct mm_struct *mm,
-unsigned long start,
-unsigned long end,
-bool blockable)
+ const struct mmu_notifier_range *range)
{
struct amdgpu_mn *amn = container_of(mn, struct amdgpu_mn, mn);
struct interval_tree_node *it;
+ unsigned long end;
/* notification is exclusive, but interval is inclusive */
- end -= 1;
+ end = range->end - 1;
- if (amdgpu_mn_read_lock(amn, blockable))
+ if (amdgpu_mn_read_lock(amn, range->blockable))
return -EAGAIN;
- it = interval_tree_iter_first(>objects, start, end);
+ it = interval_tree_iter_first(>objects, range->start, end);
while (it) {
struct amdgpu_mn_node *node;
struct amdgpu_bo *bo;
- if (!blockable) {
+ if (!range->blockable) {
amdgpu_mn_read_unlock(amn);
return -EAGAIN;
}
node = container_of(it, struct amdgpu_mn_node, it);
- it = interval_tree_iter_next(it, start, end);
+ it = interval_tree_iter_next(it, range->start, end);
[PATCH v2 2/3] mm/mmu_notifier: use structure for invalidate_range_start/end calls v2
From: Jérôme Glisse
To avoid having to change many call sites everytime we want to add a
parameter use a structure to group all parameters for the mmu_notifier
invalidate_range_start/end cakks. No functional changes with this
patch.
Changes since v1:
- introduce mmu_notifier_range_init() as an helper to initialize
the range structure allowing to optimize out the case when mmu
notifier is not enabled
- fix mm/migrate.c migrate_vma_collect()
Signed-off-by: Jérôme Glisse
Acked-by: Christian König
Cc: Andrew Morton
Cc: Matthew Wilcox
Cc: Ross Zwisler
Cc: Jan Kara
Cc: Dan Williams
Cc: Paolo Bonzini
Cc: Radim Krčmář
Cc: Michal Hocko
Cc: Felix Kuehling
Cc: Ralph Campbell
Cc: John Hubbard
Cc: k...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-r...@vger.kernel.org
Cc: linux-fsde...@vger.kernel.org
---
fs/dax.c | 8 +--
fs/proc/task_mmu.c | 7 ++-
include/linux/mm.h | 4 +-
include/linux/mmu_notifier.h | 87 +---
kernel/events/uprobes.c | 10 ++--
mm/huge_memory.c | 54 ++--
mm/hugetlb.c | 52 ++-
mm/khugepaged.c | 10 ++--
mm/ksm.c | 21
mm/madvise.c | 21
mm/memory.c | 97 ++--
mm/migrate.c | 25 +-
mm/mmu_notifier.c| 35 +++--
mm/mprotect.c| 15 +++---
mm/mremap.c | 10 ++--
mm/oom_kill.c| 17 ---
mm/rmap.c| 30 ++-
17 files changed, 258 insertions(+), 245 deletions(-)
diff --git a/fs/dax.c b/fs/dax.c
index 9bcce89ea18e..874085bacaf5 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -758,7 +758,8 @@ static void dax_entry_mkclean(struct address_space
*mapping, pgoff_t index,
i_mmap_lock_read(mapping);
vma_interval_tree_foreach(vma, >i_mmap, index, index) {
- unsigned long address, start, end;
+ struct mmu_notifier_range range;
+ unsigned long address;
cond_resched();
@@ -772,7 +773,8 @@ static void dax_entry_mkclean(struct address_space
*mapping, pgoff_t index,
* call mmu_notifier_invalidate_range_start() on our behalf
* before taking any lock.
*/
- if (follow_pte_pmd(vma->vm_mm, address, , , ,
, ))
+ if (follow_pte_pmd(vma->vm_mm, address, ,
+ , , ))
continue;
/*
@@ -814,7 +816,7 @@ static void dax_entry_mkclean(struct address_space
*mapping, pgoff_t index,
pte_unmap_unlock(ptep, ptl);
}
- mmu_notifier_invalidate_range_end(vma->vm_mm, start, end);
+ mmu_notifier_invalidate_range_end();
}
i_mmap_unlock_read(mapping);
}
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 47c3764c469b..b3ddceb003bc 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -1096,6 +1096,7 @@ static ssize_t clear_refs_write(struct file *file, const
char __user *buf,
return -ESRCH;
mm = get_task_mm(task);
if (mm) {
+ struct mmu_notifier_range range;
struct clear_refs_private cp = {
.type = type,
};
@@ -1139,11 +1140,13 @@ static ssize_t clear_refs_write(struct file *file,
const char __user *buf,
downgrade_write(>mmap_sem);
break;
}
- mmu_notifier_invalidate_range_start(mm, 0, -1);
+
+ mmu_notifier_range_init(, mm, 0, -1UL);
+ mmu_notifier_invalidate_range_start();
}
walk_page_range(0, mm->highest_vm_end, _refs_walk);
if (type == CLEAR_REFS_SOFT_DIRTY)
- mmu_notifier_invalidate_range_end(mm, 0, -1);
+ mmu_notifier_invalidate_range_end();
tlb_finish_mmu(, 0, -1);
up_read(>mmap_sem);
out_mm:
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 5411de93a363..e7b6f2b30713 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1397,6 +1397,8 @@ struct mm_walk {
void *private;
};
+struct mmu_notifier_range;
+
int walk_page_range(unsigned long addr, unsigned long end,
struct mm_walk *walk);
int walk_page_vma(struct vm_area_struct *vma, struct mm_walk *walk);
@@ -1405,7 +1407,7 @@ void free_pgd_range(struct mmu_gather *tlb, unsigned long
addr,
int copy_page_range(struct mm_struct *dst, struct mm_struct *src,
struct vm_area_struct *vma);
int follow_pte_pmd(struct mm_struct *mm, unsigned long address,
-unsigned long *start, unsigned
[Bug 108771] [amdgpu] *ERROR* ring gfx timeout
https://bugs.freedesktop.org/show_bug.cgi?id=108771 --- Comment #4 from John --- Created attachment 142730 --> https://bugs.freedesktop.org/attachment.cgi?id=142730=edit dolphin save for the last story This includes a save right before the crash (for the US version of the game). Start the autosave, go through the door, a cinematic will start and the system should freeze when Zael turns around. To freeze the system with OGL, the GPU settings must be pretty high, I last used 4x IR, Max Aniso and MSAA + FXAA, and also standard Ubershaders. -- 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 108771] [amdgpu] *ERROR* ring gfx timeout
https://bugs.freedesktop.org/show_bug.cgi?id=108771 John changed: What|Removed |Added Summary|[amdgpu]] *ERROR* ring gfx |[amdgpu] *ERROR* ring gfx |timeout |timeout -- 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 108771] [amdgpu]] *ERROR* ring gfx timeout
https://bugs.freedesktop.org/show_bug.cgi?id=108771 --- Comment #3 from John --- Here's a trace that crashes my system: https://mega.nz/#!plBngY4B!zQ8P24a84PsHWym-5hAGUMjiMKv1CKQB7EFnlPorrx4 I don't know why the trace is all black and does not display anything, but the end result is the same, so I hope it's enough for debugging purposes. Thank you! -- 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/rockchip: Allow driver to be shutdown on reboot/kexec
+ others
Hi,
On Sun, Aug 05, 2018 at 01:48:07PM +0100, Marc Zyngier wrote:
> Leaving the DRM driver enabled on reboot or kexec has the annoying
> effect of leaving the display generating transactions whilst the
> IOMMU has been shut down.
>
> In turn, the IOMMU driver (which shares its interrupt line with
> the VOP) starts warning either on shutdown or when entering the
> secondary kernel in the kexec case (nothing is expected on that
> front).
>
> A cheap way of ensuring that things are nicely shut down is to
> register a shutdown callback in the platform driver.
>
> Signed-off-by: Marc Zyngier
> ---
This patch made it into 4.20-rc1 as well as -stable, and it has caused
regressions for me, on the Kevin and Scarlet [1] RK3399 platforms. On
shutdown/reboot, I see this:
[ 94.742559] WARNING: CPU: 4 PID: 2035 at
drivers/gpu/drm/drm_mode_config.c:477 drm_mode_config_cleanup+0x1c4/0x294
...
[ 94.775904] CPU: 4 PID: 2035 Comm: reboot Tainted: GW
4.20.0-rc5+ #83
[ 94.784651] Hardware name: Google Scarlet (DT)
[ 94.789611] pstate: 2005 (nzCv daif -PAN -UAO)
[ 94.794959] pc : drm_mode_config_cleanup+0x1c4/0x294
[ 94.800500] lr : drm_mode_config_cleanup+0x108/0x294
...
[ 94.898683] Call trace:
[ 94.901410] drm_mode_config_cleanup+0x1c4/0x294
[ 94.906565] rockchip_drm_unbind+0x4c/0x8c
[ 94.911138] component_master_del+0x88/0xb8
[ 94.915807] rockchip_drm_platform_remove+0x2c/0x44
[ 94.921243] rockchip_drm_platform_shutdown+0x20/0x2c
[ 94.926881] platform_drv_shutdown+0x2c/0x38
[ 94.931647] device_shutdown+0x164/0x1b8
[ 94.936016] kernel_restart_prepare+0x40/0x48
[ 94.940878] kernel_restart+0x20/0x68
[ 94.944964] __se_sys_reboot+0x1ac/0x204
[ 94.949331] __arm64_sys_reboot+0x2c/0x38
[ 94.953806] el0_svc_common+0xa4/0xec
[ 94.957891] el0_svc_compat_handler+0x30/0x3c
[ 94.962753] el0_svc_compat+0x8/0x18
[ 94.966740] ---[ end trace b9ba2e701f4fb233 ]---
[ 95.255169] Memory manager not clean during takedown.
[ 95.260824] WARNING: CPU: 4 PID: 2035 at drivers/gpu/drm/drm_mm.c:950
drm_mm_takedown+0x34/0x44
...
[ 95.292314] CPU: 4 PID: 2035 Comm: reboot Tainted: GW
4.20.0-rc5+ #83
[ 95.301061] Hardware name: Google Scarlet (DT)
[ 95.306020] pstate: 6005 (nZCv daif -PAN -UAO)
[ 95.311369] pc : drm_mm_takedown+0x34/0x44
[ 95.315940] lr : drm_mm_takedown+0x34/0x44
...
[ 95.415857] drm_mm_takedown+0x34/0x44
[ 95.420042] rockchip_drm_unbind+0x64/0x8c
[ 95.424613] component_master_del+0x88/0xb8
[ 95.429283] rockchip_drm_platform_remove+0x2c/0x44
[ 95.434728] rockchip_drm_platform_shutdown+0x20/0x2c
[ 95.440360] platform_drv_shutdown+0x2c/0x38
[ 95.445127] device_shutdown+0x164/0x1b8
[ 95.449504] kernel_restart_prepare+0x40/0x48
[ 95.454358] kernel_restart+0x20/0x68
[ 95.458436] __se_sys_reboot+0x1ac/0x204
[ 95.462812] __arm64_sys_reboot+0x2c/0x38
[ 95.467287] el0_svc_common+0xa4/0xec
[ 95.471373] el0_svc_compat_handler+0x30/0x3c
[ 95.476235] el0_svc_compat+0x8/0x18
[ 95.480215] ---[ end trace b9ba2e701f4fb234 ]---
It's especially bad on -stable kernels, where I believe the remove()
paths were even worse. This triggers a variety of OOPSes, and it's not
clear if those are simply because of backports (e.g., RK3399 did not
have support in 4.4.y, but our downstream has merged all sorts of
backports to make it work).
Anyway, the above warnings occur on v4.20-rc, which I think is
justification enough for a revert.
I plan to submit a revert which I hope can go to 4.20 as well as
-stable. I'd hope the remove()/shutdown() paths should be fixed before
this gets applied again, and that it does not get shipped to -stable
kernels.
Brian
[1] Technically Scarlet needed a few patches from -next to work at all,
but Kevin is a similar platform that has been working for several
releases.
> drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> index f814d37b1db2..05368fa4f956 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> @@ -442,6 +442,11 @@ static int rockchip_drm_platform_remove(struct
> platform_device *pdev)
> return 0;
> }
>
> +static void rockchip_drm_platform_shutdown(struct platform_device *pdev)
> +{
> + rockchip_drm_platform_remove(pdev);
> +}
> +
> static const struct of_device_id rockchip_drm_dt_ids[] = {
> { .compatible = "rockchip,display-subsystem", },
> { /* sentinel */ },
> @@ -451,6 +456,7 @@ MODULE_DEVICE_TABLE(of, rockchip_drm_dt_ids);
> static struct platform_driver rockchip_drm_platform_driver = {
> .probe = rockchip_drm_platform_probe,
> .remove = rockchip_drm_platform_remove,
> + .shutdown = rockchip_drm_platform_shutdown,
> .driver = {
> .name = "rockchip-drm",
>
[Bug 105111] amdgpu 0000:00:01.0: Invalid ROM contents (with A8-7600)
https://bugzilla.kernel.org/show_bug.cgi?id=105111 fin4...@hotmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |CODE_FIX -- 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
[Bug 192161] Amdgpu UVD init failures at boot
https://bugzilla.kernel.org/show_bug.cgi?id=192161 fin4...@hotmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |CODE_FIX -- 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
[Bug 178281] wine-staging apps freezes the machine with RX460
https://bugzilla.kernel.org/show_bug.cgi?id=178281 fin4...@hotmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |CODE_FIX -- 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
[Bug 193651] Amdgpu error messages at boot with Amd RX460
https://bugzilla.kernel.org/show_bug.cgi?id=193651 fin4...@hotmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |CODE_FIX -- 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
[Bug 201439] Amdgpu: system freeze when waking up from monitor blanking
https://bugzilla.kernel.org/show_bug.cgi?id=201439 fin4...@hotmail.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |CODE_FIX --- Comment #12 from fin4...@hotmail.com --- I did buy a Asus 4K display port monitor and close this bug. -- 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 v6] arm64: dts: qcom: sdm845: Add dpu to sdm845 dts file
Hi, On Tue, Dec 4, 2018 at 3:54 PM Jeykumar Sankaran wrote: > > DPU is short for the Display Processing Unit. It is the display > controller on Qualcomm SDM845 chips. > > This change adds MDSS and DSI nodes to enable display on the > target device. > > Changes in v2: > - Beefed up commit message > - Use SoC specific compatibles for mdss and dpu (Rob H) > - Use assigned-clocks to set initial clock frequency(Rob H) > Changes in v3: > - added IOMMU node > - Fix device naming (remove _phys) > - Use correct IRQ_TYPE in interrupt specifiers > Changes in v4: > - move mdss node to preserve the unit address sort order > - remove _clk suffix from dsi clocks > (both the comments are from Doug Anderson) > Changes in v5: > - Keep the device status "disabled" by default (Bjorn Andersson) > - Use MDSS_GDSC macro (Jordan) > - Fix phy-names (Jordan) > - List reg ranges in numerical order (Jordan) > Changes in v6: > - Separating this patch out of the series > - fix phy-names > > Signed-off-by: Jeykumar Sankaran > Signed-off-by: Sean Paul > --- > arch/arm64/boot/dts/qcom/sdm845.dtsi | 203 > +++ > 1 file changed, 203 insertions(+) With my admittedly limited understanding of the device tree for graphics, this looks good to me. Reviewed-by: Douglas Anderson ...this works for me on sdm845-cheza. Specifically I tested it on our 4.19 branch which has some display backports and a few picks from the mailing list. Anyone specifically interested in the tree I tested with can see https://crrev.com/c/1327901, which includes this patch. Thus: Tested-by: Douglas Anderson ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 0/4] ARM: dts: ccimx6ulsbcpro: Add 10" AUO/Goodix LVDS panel accessory kit
On Thu, Oct 25, 2018 at 05:09:29PM +0200, Alex Gonzalez wrote: > Alex Gonzalez (4): > drm/panel: simple: Add AUO G101EVN010 panel support > ARM: dts: ccimx6ulsbcpro: Enable AUO G101EVN010 lcdif panel > ARM: imx_v6_v7_defconfig: Select TOUCHSCREEN_GOODIX > ARM: dts: ccimx6ulsbcpro: Add support for Goodix touch controller Applied #2 ~ #4, thanks. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108937] [radeonsi, RX480] VAAPI H.264 decoder produces garbage on YouTube in Chromium with h264ify
https://bugs.freedesktop.org/show_bug.cgi?id=108937 --- Comment #3 from Christopher Snowhill --- Yes, that dodges the issue. Should I be enabling this setting system-wide, possibly for other applications? I recall Totem having the same issue with H.264 hardware decoding. -- 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 v6] arm64: dts: qcom: sdm845: Add dpu to sdm845 dts file
DPU is short for the Display Processing Unit. It is the display
controller on Qualcomm SDM845 chips.
This change adds MDSS and DSI nodes to enable display on the
target device.
Changes in v2:
- Beefed up commit message
- Use SoC specific compatibles for mdss and dpu (Rob H)
- Use assigned-clocks to set initial clock frequency(Rob H)
Changes in v3:
- added IOMMU node
- Fix device naming (remove _phys)
- Use correct IRQ_TYPE in interrupt specifiers
Changes in v4:
- move mdss node to preserve the unit address sort order
- remove _clk suffix from dsi clocks
(both the comments are from Doug Anderson)
Changes in v5:
- Keep the device status "disabled" by default (Bjorn Andersson)
- Use MDSS_GDSC macro (Jordan)
- Fix phy-names (Jordan)
- List reg ranges in numerical order (Jordan)
Changes in v6:
- Separating this patch out of the series
- fix phy-names
Signed-off-by: Jeykumar Sankaran
Signed-off-by: Sean Paul
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 203 +++
1 file changed, 203 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 1419b00..fa7023e 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -1256,6 +1256,209 @@
};
};
+ mdss: mdss@ae0 {
+ compatible = "qcom,sdm845-mdss";
+ reg = <0xae0 0x1000>;
+ reg-names = "mdss";
+
+ power-domains = < MDSS_GDSC>;
+
+ clocks = < GCC_DISP_AHB_CLK>,
+< GCC_DISP_AXI_CLK>,
+< DISP_CC_MDSS_MDP_CLK>;
+ clock-names = "iface", "bus", "core";
+
+ assigned-clocks = < DISP_CC_MDSS_MDP_CLK>;
+ assigned-clock-rates = <3>;
+
+ interrupts = ;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ iommus = <_smmu 0x880 0x8>,
+<_smmu 0xc80 0x8>;
+
+ status = "disabled";
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ mdss_mdp: mdp@ae01000 {
+ compatible = "qcom,sdm845-dpu";
+ reg = <0x0ae01000 0x8f000>,
+ <0x0aeb 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = < DISP_CC_MDSS_AHB_CLK>,
+< DISP_CC_MDSS_AXI_CLK>,
+< DISP_CC_MDSS_MDP_CLK>,
+< DISP_CC_MDSS_VSYNC_CLK>;
+ clock-names = "iface", "bus", "core", "vsync";
+
+ assigned-clocks = <
DISP_CC_MDSS_MDP_CLK>,
+ <
DISP_CC_MDSS_VSYNC_CLK>;
+ assigned-clock-rates = <3>,
+ <1920>;
+
+ interrupt-parent = <>;
+ interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
+
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dpu_intf1_out: endpoint {
+ remote-endpoint =
<_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dpu_intf2_out: endpoint {
+ remote-endpoint =
<_in>;
+ };
+ };
+ };
+ };
+
+ dsi0: dsi@ae94000 {
+ compatible = "qcom,mdss-dsi-ctrl";
+ reg = <0xae94000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <>;
+ interrupts = <4 IRQ_TYPE_LEVEL_HIGH>;
+
+ clocks = < DISP_CC_MDSS_BYTE0_CLK>,
+<
Re: [Freedreno] [PATCH v2] drm/msm/dpu: add display port support in DPU
On 2018-12-03 06:47, Sean Paul wrote:
On Tue, Nov 27, 2018 at 02:28:30PM -0800, Jeykumar Sankaran wrote:
Add display port support in DPU by creating hooks
for DP encoder enumeration and encoder mode
initialization.
This change is based on the SDM845 Display port
driver changes[1].
changes in v2:
- rebase on [2] (Sean Paul)
- remove unwanted error checks and
switch cases (Jordan Crouse)
[1] https://lwn.net/Articles/768265/
[2] https://lkml.org/lkml/2018/11/17/87
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 8 ++---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 47
+
2 files changed, 45 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index d3f4501..1f6b4b1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -2015,7 +2015,7 @@ static int dpu_encoder_setup_display(struct
dpu_encoder_virt *dpu_enc,
{
int ret = 0;
int i = 0;
- enum dpu_intf_type intf_type;
+ enum dpu_intf_type intf_type = INTF_NONE;
dpu_intf_type seems unnecessary, you could just use the
DRM_MODE_ENCODER_*
value
directly?
enum dpu_intf_type enumerates HW interface types the SOC has. Below
switch
case maps the DRM_MODE_ENCODER_* to HW dpu_intf_type it should reserve.
Note that DRM_MODE_ENCODER_* and dpu_intf_type are not mapped 1-to-1.
e.g. DRM_MODE_ENCODER_TMDS can be mapped to HDMI or DisplayPort.
Thanks,
Jeykumar S.
struct dpu_enc_phys_init_params phys_params;
if (!dpu_enc || !dpu_kms) {
@@ -2038,9 +2038,9 @@ static int dpu_encoder_setup_display(struct
dpu_encoder_virt *dpu_enc,
case DRM_MODE_ENCODER_DSI:
intf_type = INTF_DSI;
break;
- default:
- DPU_ERROR_ENC(dpu_enc, "unsupported display interface
type\n");
- return -EINVAL;
+ case DRM_MODE_ENCODER_TMDS:
+ intf_type = INTF_DP;
+ break;
}
WARN_ON(disp_info->num_of_h_tiles < 1);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 985c855..7d931ae 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -473,6 +473,32 @@ static void _dpu_kms_initialize_dsi(struct
drm_device *dev,
}
}
+static void _dpu_kms_initialize_displayport(struct drm_device *dev,
+ struct msm_drm_private *priv,
+ struct dpu_kms *dpu_kms)
+{
+ struct drm_encoder *encoder = NULL;
+ int rc;
+
+ if (!priv->dp)
+ return;
+
+ encoder = dpu_encoder_init(dev, DRM_MODE_ENCODER_TMDS);
+ if (IS_ERR(encoder)) {
+ DPU_ERROR("encoder init failed for dsi display\n");
+ return;
+ }
+
+ rc = msm_dp_modeset_init(priv->dp, dev, encoder);
+ if (rc) {
+ DPU_ERROR("modeset_init failed for DP, rc = %d\n", rc);
+ drm_encoder_cleanup(encoder);
+ return;
+ }
+
+ priv->encoders[priv->num_encoders++] = encoder;
No need to keep track of drm resources at the driver level, the core
will
do
this for you. So can you please add a patch preceding this one to
remove
the
priv->encoders/crtc/planes/connectors arrays?
+}
+
/**
* _dpu_kms_setup_displays - create encoders, bridges and connectors
* for underlying displays
@@ -487,6 +513,8 @@ static void _dpu_kms_setup_displays(struct
drm_device *dev,
Why are these functions voids? Seems like there are plenty of places
for
them to
fail :)
Let's add a patch to the beginning of this series to properly handle
failures in
setup_displays and initialize_dsi
{
_dpu_kms_initialize_dsi(dev, priv, dpu_kms);
+ _dpu_kms_initialize_displayport(dev, priv, dpu_kms);
+
/**
* Extend this function to initialize other
* types of displays
@@ -723,13 +751,20 @@ static void _dpu_kms_set_encoder_mode(struct
msm_kms *kms,
info.capabilities = cmd_mode ? MSM_DISPLAY_CAP_CMD_MODE :
MSM_DISPLAY_CAP_VID_MODE;
- /* TODO: No support for DSI swap */
- for (i = 0; i < ARRAY_SIZE(priv->dsi); i++) {
- if (priv->dsi[i]) {
- info.h_tile_instance[info.num_of_h_tiles] = i;
- info.num_of_h_tiles++;
+ switch (info.intf_type) {
+ case DRM_MODE_ENCODER_DSI:
+ /* TODO: No support for DSI swap */
+ for (i = 0; i < ARRAY_SIZE(priv->dsi); i++) {
+ if (priv->dsi[i]) {
+ info.h_tile_instance[info.num_of_h_tiles]
= i;
+ info.num_of_h_tiles++;
+ }
}
-
Re: [PATCH 3/3] mm/mmu_notifier: contextual information for event triggering invalidation
On Mon, 3 Dec 2018 15:18:17 -0500 jgli...@redhat.com wrote:
> CPU page table update can happens for many reasons, not only as a result
> of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also
> as a result of kernel activities (memory compression, reclaim, migration,
> ...).
>
> Users of mmu notifier API track changes to the CPU page table and take
> specific action for them. While current API only provide range of virtual
> address affected by the change, not why the changes is happening.
>
> This patchset adds event information so that users of mmu notifier can
> differentiate among broad category:
> - UNMAP: munmap() or mremap()
> - CLEAR: page table is cleared (migration, compaction, reclaim, ...)
> - PROTECTION_VMA: change in access protections for the range
> - PROTECTION_PAGE: change in access protections for page in the range
> - SOFT_DIRTY: soft dirtyness tracking
>
> Being able to identify munmap() and mremap() from other reasons why the
> page table is cleared is important to allow user of mmu notifier to
> update their own internal tracking structure accordingly (on munmap or
> mremap it is not longer needed to track range of virtual address as it
> becomes invalid).
>
> ...
>
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -519,6 +519,7 @@ bool __oom_reap_task_mm(struct mm_struct *mm)
> struct mmu_notifier_range range;
> struct mmu_gather tlb;
>
> + range.event = MMU_NOTIFY_CLEAR;
> range.start = vma->vm_start;
> range.end = vma->vm_end;
> range.mm = mm;
mmu_notifier_range and MMU_NOTIFY_CLEAR aren't defined if
CONFIG_MMU_NOTIFIER=n.
I'll try a temporary bodge:
+++ a/include/linux/mmu_notifier.h
@@ -10,8 +10,6 @@
struct mmu_notifier;
struct mmu_notifier_ops;
-#ifdef CONFIG_MMU_NOTIFIER
-
/*
* The mmu notifier_mm structure is allocated and installed in
* mm->mmu_notifier_mm inside the mm_take_all_locks() protected
@@ -32,6 +30,8 @@ struct mmu_notifier_range {
bool blockable;
};
+#ifdef CONFIG_MMU_NOTIFIER
+
struct mmu_notifier_ops {
/*
* Called either by mmu_notifier_unregister or when the mm is
But this new code should vanish altogether if CONFIG_MMU_NOTIFIER=n,
please. Or at least, we shouldn't be unnecessarily initializing .mm
and .event. Please take a look at debloating this code.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows
https://bugs.freedesktop.org/show_bug.cgi?id=106175 --- Comment #74 from Brandon Wright --- Is anyone from the AMD driver team still following this? Could we please have a review of Nicholas's patch and try to get it into 4.20? It's not that disruptive code-wise, but it makes a big smoothness difference. I can quickly compile a kernel/module for myself pretty easily, but most users aren't going to be that technical or even know why things are so stuttery. -- 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 200695] Blank screen on RX 580 with amdgpu.dc=1 enabled (no displays detected)
https://bugzilla.kernel.org/show_bug.cgi?id=200695 Claude Heiland-Allen (cla...@mathr.co.uk) changed: What|Removed |Added Kernel Version|4.17.19, 4.18.5 through |4.17.19, 4.18.5 through |4.18.19, 4.19-rc1 through |4.18.20, 4.19-rc1 through |4.19.2, 4.20-rc1 through|4.19.6, 4.20-rc1 through |4.20-rc3|4.20-rc5 --- Comment #21 from Claude Heiland-Allen (cla...@mathr.co.uk) --- still an issue in 4.18.20 4.19.3 4.19.4 4.19.5 4.19.6 4.20-rc4 4.20-rc5 -- 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
[PATCH v4 7/8] arm64: dts: sdm845: Set 'bi_tcxo' as ref clock of the DSI PHYs
Add 'bi_tcxo' as ref clock for the DSI PHYs, it was previously
hardcoded in the PLL 'driver' for the 10nm PHY.
Signed-off-by: Matthias Kaehlcke
Reviewed-by: Douglas Anderson
Reviewed-by: Stephen Boyd
---
based on "[v4,1/3] arm64: dts: qcom: sdm845: Add dpu to sdm845 dts file"
(https://patchwork.kernel.org/patch/10666253/)
Changes in v4:
- added 'Reviewed-by: Stephen Boyd ' tag
Changes in v3:
- added 'Reviewed-by: Douglas Anderson ' tag
Changes in v2:
- patch added to the series
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 5728b4cfae269..cdb5a9bb23e69 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -1372,8 +1372,9 @@
#clock-cells = <1>;
#phy-cells = <0>;
- clocks = < DISP_CC_MDSS_AHB_CLK>;
- clock-names = "iface";
+ clocks = < DISP_CC_MDSS_AHB_CLK>,
+< RPMH_CXO_CLK>;
+ clock-names = "iface", "ref";
};
dsi1: dsi@ae96000 {
@@ -1434,8 +1435,9 @@
#clock-cells = <1>;
#phy-cells = <0>;
- clocks = < DISP_CC_MDSS_AHB_CLK>;
- clock-names = "iface";
+ clocks = < DISP_CC_MDSS_AHB_CLK>,
+< RPMH_CXO_CLK>;
+ clock-names = "iface", "ref";
};
};
--
2.20.0.rc1.387.gf8505762e3-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/8] drm/msm/dsi: 28nm 8960 PHY: Get ref clock from the DT
Get the ref clock of the PHY from the device tree instead of
hardcoding its name and rate.
Signed-off-by: Matthias Kaehlcke
---
Changes in v4:
- always use parent rate in dsi_pll_28nm_clk_set_rate()
- pass name of VCO ref clock to pll_28nm_register() instead of
storing it in a struct field
- updated commit message
Changes in v3:
- use default name and rate if the ref clock is not specified
in the DT
- store vco_ref_clk_name instead of vco_ref_clk
- fixed check for EPROBE_DEFER
- renamed VCO_REF_CLK_RATE to VCO_REF_CLK_DEFAULT_RATE
Changes in v2:
- patch added to the series
---
.../gpu/drm/msm/dsi/pll/dsi_pll_28nm_8960.c | 24 +++
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm_8960.c
b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm_8960.c
index 49008451085b8..76e5188169b91 100644
--- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm_8960.c
+++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm_8960.c
@@ -47,7 +47,6 @@
#define NUM_PROVIDED_CLKS 2
-#define VCO_REF_CLK_RATE 2700
#define VCO_MIN_RATE 6
#define VCO_MAX_RATE 12
@@ -125,7 +124,7 @@ static int dsi_pll_28nm_clk_set_rate(struct clk_hw *hw,
unsigned long rate,
DBG("rate=%lu, parent's=%lu", rate, parent_rate);
temp = rate / 10;
- val = VCO_REF_CLK_RATE / 10;
+ val = parent_rate / 10;
fb_divider = (temp * VCO_PREF_DIV_RATIO) / val;
fb_divider = fb_divider / 2 - 1;
pll_write(base + REG_DSI_28nm_8960_PHY_PLL_CTRL_1,
@@ -406,11 +405,12 @@ static void dsi_pll_28nm_destroy(struct msm_dsi_pll *pll)
pll_28nm->clks, pll_28nm->num_clks);
}
-static int pll_28nm_register(struct dsi_pll_28nm *pll_28nm)
+static int pll_28nm_register(struct dsi_pll_28nm *pll_28nm,
+const char *ref_clk_name)
{
char *clk_name, *parent_name, *vco_name;
struct clk_init_data vco_init = {
- .parent_names = (const char *[]){ "pxo" },
+ .parent_names = _clk_name,
.num_parents = 1,
.flags = CLK_IGNORE_UNUSED,
.ops = _ops_dsi_pll_28nm_vco,
@@ -494,6 +494,8 @@ struct msm_dsi_pll *msm_dsi_pll_28nm_8960_init(struct
platform_device *pdev,
{
struct dsi_pll_28nm *pll_28nm;
struct msm_dsi_pll *pll;
+ struct clk *vco_ref_clk;
+ const char *vco_ref_clk_name;
int ret;
if (!pdev)
@@ -506,6 +508,18 @@ struct msm_dsi_pll *msm_dsi_pll_28nm_8960_init(struct
platform_device *pdev,
pll_28nm->pdev = pdev;
pll_28nm->id = id + 1;
+ vco_ref_clk = devm_clk_get(>dev, "ref");
+ if (!IS_ERR(vco_ref_clk)) {
+ vco_ref_clk_name = __clk_get_name(vco_ref_clk);
+ } else {
+ ret = PTR_ERR(vco_ref_clk);
+ if (ret == -EPROBE_DEFER)
+ return ERR_PTR(ret);
+
+ dev_warn(>dev, "'ref' clock is not specified, using
default name\n");
+ vco_ref_clk_name = "pxo";
+ }
+
pll_28nm->mmio = msm_ioremap(pdev, "dsi_pll", "DSI_PLL");
if (IS_ERR_OR_NULL(pll_28nm->mmio)) {
dev_err(>dev, "%s: failed to map pll base\n", __func__);
@@ -524,7 +538,7 @@ struct msm_dsi_pll *msm_dsi_pll_28nm_8960_init(struct
platform_device *pdev,
pll->en_seq_cnt = 1;
pll->enable_seqs[0] = dsi_pll_28nm_enable_seq;
- ret = pll_28nm_register(pll_28nm);
+ ret = pll_28nm_register(pll_28nm, vco_ref_clk_name);
if (ret) {
dev_err(>dev, "failed to register PLL: %d\n", ret);
return ERR_PTR(ret);
--
2.20.0.rc1.387.gf8505762e3-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 6/8] arm64: dts: qcom: msm8916: Set 'xo_board' as ref clock of the DSI PHY
Add 'xo_board' as ref clock for the DSI PHYs, it was previously hardcoded in the PLL 'driver' for the 28nm PHY. Signed-off-by: Matthias Kaehlcke Reviewed-by: Douglas Anderson Reviewed-by: Stephen Boyd --- Changes in v4: - added 'Reviewed-by: Stephen Boyd ' tag Changes in v3: - added 'Reviewed-by: Douglas Anderson ' tag Changes in v2: - patch added to the series --- arch/arm64/boot/dts/qcom/msm8916.dtsi | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi index d302d8d639a12..89f30f34ff896 100644 --- a/arch/arm64/boot/dts/qcom/msm8916.dtsi +++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi @@ -959,8 +959,9 @@ #clock-cells = <1>; #phy-cells = <0>; - clocks = < GCC_MDSS_AHB_CLK>; - clock-names = "iface"; + clocks = < GCC_MDSS_AHB_CLK>, +<_board>; + clock-names = "iface", "ref"; }; }; -- 2.20.0.rc1.387.gf8505762e3-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/8] dt-bindings: msm/dsi: Add ref clock for PHYs
Allow the PHY drivers to get the ref clock from the DT. Signed-off-by: Matthias Kaehlcke Reviewed-by: Stephen Boyd Reviewed-by: Douglas Anderson --- Chnages in v4: - added "Reviewed-by" tags from Stephen and Doug Changes in v3: - added note that the ref clock is only required for new DTS files/entries Changes in v2: - add the ref clock for all PHYs, not only the 10nm one - updated commit message --- Documentation/devicetree/bindings/display/msm/dsi.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt b/Documentation/devicetree/bindings/display/msm/dsi.txt index dfc743219bd88..9ae9469427207 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi.txt +++ b/Documentation/devicetree/bindings/display/msm/dsi.txt @@ -106,6 +106,7 @@ Required properties: - clocks: Phandles to device clocks. See [1] for details on clock bindings. - clock-names: the following clocks are required: * "iface" + * "ref" (only required for new DTS files/entries) For 28nm HPM/LP, 28nm 8960 PHYs: - vddio-supply: phandle to vdd-io regulator device node For 20nm PHY: -- 2.20.0.rc1.387.gf8505762e3-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/8] drm/msm/dsi: Get PHY ref clocks from the DT
The MSM DSI PHY drivers currently hardcode the name and the rate of the PHY ref clock. Get the ref clock from the device tree instead. Note: testing of this series was limited to SDM845 and the 10nm PHY Major changes in v4: - always use parent rate for 28nm and 28nm 8960 PHYs Major changes in v3: - keep supporting DTs without ref clock for the 28nm and the 28nm 8960 PHYs - added patch to add ref clock to qcom-apq8064.dtsi Major changes in v2: - apply to all MSM DSI PHY drivers, not only 10nm Matthias Kaehlcke (8): dt-bindings: msm/dsi: Add ref clock for PHYs drm/msm/dsi: 28nm 8960 PHY: Get ref clock from the DT drm/msm/dsi: 28nm PHY: Get ref clock from the DT drm/msm/dsi: 14nm PHY: Get ref clock from the DT drm/msm/dsi: 10nm PHY: Get ref clock from the DT arm64: dts: qcom: msm8916: Set 'xo_board' as ref clock of the DSI PHY arm64: dts: sdm845: Set 'bi_tcxo' as ref clock of the DSI PHYs ARM: dts: qcom-apq8064: Set 'xo_board' as ref clock of the DSI PHY .../devicetree/bindings/display/msm/dsi.txt | 1 + arch/arm/boot/dts/qcom-apq8064.dtsi | 5 +-- arch/arm64/boot/dts/qcom/msm8916.dtsi | 5 +-- arch/arm64/boot/dts/qcom/sdm845.dtsi | 10 +++--- drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c| 13 ++- drivers/gpu/drm/msm/dsi/pll/dsi_pll_14nm.c| 16 +++-- drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm.c| 36 +-- .../gpu/drm/msm/dsi/pll/dsi_pll_28nm_8960.c | 24 ++--- 8 files changed, 82 insertions(+), 28 deletions(-) -- 2.20.0.rc1.387.gf8505762e3-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 5/8] drm/msm/dsi: 10nm PHY: Get ref clock from the DT
Get the ref clock of the PHY from the device tree instead of
hardcoding its name and rate.
Note: This change could break old out-of-tree DTS files that
use the 10nm PHY
Signed-off-by: Matthias Kaehlcke
Reviewed-by: Douglas Anderson
---
Changes in v4:
- none
Changes in v3:
- fixed check for EPROBE_DEFER
- added note to commit message about breaking old DTS files
- added 'Reviewed-by: Douglas Anderson ' tag
Changes in v2:
- remove anonymous array in clk_init_data assignment
- log error code if devm_clk_get() fails
- don't log devm_clk_get() failures for -EPROBE_DEFER
- updated commit message
---
drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
index 4c03f0b7343ed..2d23372acd20d 100644
--- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
+++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
@@ -91,6 +91,7 @@ struct dsi_pll_10nm {
void __iomem *phy_cmn_mmio;
void __iomem *mmio;
+ struct clk *vco_ref_clk;
u64 vco_ref_clk_rate;
u64 vco_current_rate;
@@ -629,8 +630,9 @@ static int pll_10nm_register(struct dsi_pll_10nm *pll_10nm)
{
char clk_name[32], parent[32], vco_name[32];
char parent2[32], parent3[32], parent4[32];
+ const char *ref_clk_name = __clk_get_name(pll_10nm->vco_ref_clk);
struct clk_init_data vco_init = {
- .parent_names = (const char *[]){ "xo" },
+ .parent_names = _clk_name,
.num_parents = 1,
.name = vco_name,
.flags = CLK_IGNORE_UNUSED,
@@ -786,6 +788,15 @@ struct msm_dsi_pll *msm_dsi_pll_10nm_init(struct
platform_device *pdev, int id)
pll_10nm->id = id;
pll_10nm_list[id] = pll_10nm;
+ pll_10nm->vco_ref_clk = devm_clk_get(>dev, "ref");
+ if (IS_ERR(pll_10nm->vco_ref_clk)) {
+ ret = PTR_ERR(pll_10nm->vco_ref_clk);
+ if (ret != -EPROBE_DEFER)
+ dev_err(>dev, "couldn't get 'ref' clock: %d\n",
+ ret);
+ return ERR_PTR(ret);
+ }
+
pll_10nm->phy_cmn_mmio = msm_ioremap(pdev, "dsi_phy", "DSI_PHY");
if (IS_ERR_OR_NULL(pll_10nm->phy_cmn_mmio)) {
dev_err(>dev, "failed to map CMN PHY base\n");
--
2.20.0.rc1.387.gf8505762e3-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 4/8] drm/msm/dsi: 14nm PHY: Get ref clock from the DT
Get the ref clock of the PHY from the device tree instead of
hardcoding its name and rate.
Note: This change could break old out-of-tree DTS files that
use the 14nm PHY.
Signed-off-by: Matthias Kaehlcke
Reviewed-by: Douglas Anderson
---
Changes in v4:
- none
Changes in v3:
- fixed check for EPROBE_DEFER
- added note to commit message about breaking old DTS files
- added 'Reviewed-by: Douglas Anderson ' tag
Changes in v2:
- patch added to the series
---
drivers/gpu/drm/msm/dsi/pll/dsi_pll_14nm.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_14nm.c
b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_14nm.c
index 71fe60e5f01f1..032bf3e8614bd 100644
--- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_14nm.c
+++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_14nm.c
@@ -40,7 +40,6 @@
#define NUM_PROVIDED_CLKS 2
-#define VCO_REF_CLK_RATE 1920
#define VCO_MIN_RATE 13UL
#define VCO_MAX_RATE 26UL
@@ -139,6 +138,7 @@ struct dsi_pll_14nm {
/* protects REG_DSI_14nm_PHY_CMN_CLK_CFG0 register */
spinlock_t postdiv_lock;
+ struct clk *vco_ref_clk;
u64 vco_current_rate;
u64 vco_ref_clk_rate;
@@ -591,7 +591,7 @@ static int dsi_pll_14nm_vco_set_rate(struct clk_hw *hw,
unsigned long rate,
parent_rate);
pll_14nm->vco_current_rate = rate;
- pll_14nm->vco_ref_clk_rate = VCO_REF_CLK_RATE;
+ pll_14nm->vco_ref_clk_rate = parent_rate;
dsi_pll_14nm_input_init(pll_14nm);
@@ -950,8 +950,9 @@ static struct clk_hw *pll_14nm_postdiv_register(struct
dsi_pll_14nm *pll_14nm,
static int pll_14nm_register(struct dsi_pll_14nm *pll_14nm)
{
char clk_name[32], parent[32], vco_name[32];
+ const char *ref_clk_name = __clk_get_name(pll_14nm->vco_ref_clk);
struct clk_init_data vco_init = {
- .parent_names = (const char *[]){ "xo" },
+ .parent_names = _clk_name,
.num_parents = 1,
.name = vco_name,
.flags = CLK_IGNORE_UNUSED,
@@ -1065,6 +1066,15 @@ struct msm_dsi_pll *msm_dsi_pll_14nm_init(struct
platform_device *pdev, int id)
pll_14nm->id = id;
pll_14nm_list[id] = pll_14nm;
+ pll_14nm->vco_ref_clk = devm_clk_get(>dev, "ref");
+ if (IS_ERR(pll_14nm->vco_ref_clk)) {
+ ret = PTR_ERR(pll_14nm->vco_ref_clk);
+ if (ret != -EPROBE_DEFER)
+ dev_err(>dev, "couldn't get 'ref' clock: %d\n",
+ ret);
+ return ERR_PTR(ret);
+ }
+
pll_14nm->phy_cmn_mmio = msm_ioremap(pdev, "dsi_phy", "DSI_PHY");
if (IS_ERR_OR_NULL(pll_14nm->phy_cmn_mmio)) {
dev_err(>dev, "failed to map CMN PHY base\n");
--
2.20.0.rc1.387.gf8505762e3-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 3/8] drm/msm/dsi: 28nm PHY: Get ref clock from the DT
Get the ref clock of the PHY from the device tree instead of
hardcoding its name and rate.
Signed-off-by: Matthias Kaehlcke
---
Changes in v4:
- always use parent rate in dsi_pll_28nm_clk_set_rate() and
dsi_pll_28nm_clk_recalc_rate()
- pass name of VCO ref clock to pll_28nm_register() instead of
storing it in a struct field
- updated commit message
Changes in v3:
- use default name and rate if the ref clock is not specified
in the DT
- store vco_ref_clk_name instead of vco_ref_clk
- dsi_pll_28nm_clk_set_rate: changed data type of ref_clk_rate to
unsigned long
- fixed check for EPROBE_DEFER
- renamed VCO_REF_CLK_RATE to VCO_REF_CLK_DEFAULT_RATE
Changes in v2:
- patch added to the series
---
drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm.c | 36 +++---
1 file changed, 25 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm.c
b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm.c
index 26e3a01a99c2b..340b03e8d 100644
--- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm.c
+++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm.c
@@ -40,7 +40,6 @@
#define NUM_PROVIDED_CLKS 2
-#define VCO_REF_CLK_RATE 1920
#define VCO_MIN_RATE 35000
#define VCO_MAX_RATE 75000
@@ -166,17 +165,17 @@ static int dsi_pll_28nm_clk_set_rate(struct clk_hw *hw,
unsigned long rate,
pll_write(base + REG_DSI_28nm_PHY_PLL_LPFC1_CFG, 0x70);
pll_write(base + REG_DSI_28nm_PHY_PLL_LPFC2_CFG, 0x15);
- rem = rate % VCO_REF_CLK_RATE;
+ rem = rate % parent_rate;
if (rem) {
refclk_cfg = DSI_28nm_PHY_PLL_REFCLK_CFG_DBLR;
frac_n_mode = 1;
- div_fbx1000 = rate / (VCO_REF_CLK_RATE / 500);
- gen_vco_clk = div_fbx1000 * (VCO_REF_CLK_RATE / 500);
+ div_fbx1000 = rate / (parent_rate / 500);
+ gen_vco_clk = div_fbx1000 * (parent_rate / 500);
} else {
refclk_cfg = 0x0;
frac_n_mode = 0;
- div_fbx1000 = rate / (VCO_REF_CLK_RATE / 1000);
- gen_vco_clk = div_fbx1000 * (VCO_REF_CLK_RATE / 1000);
+ div_fbx1000 = rate / (parent_rate / 1000);
+ gen_vco_clk = div_fbx1000 * (parent_rate / 1000);
}
DBG("refclk_cfg = %d", refclk_cfg);
@@ -265,7 +264,7 @@ static unsigned long dsi_pll_28nm_clk_recalc_rate(struct
clk_hw *hw,
void __iomem *base = pll_28nm->mmio;
u32 sdm0, doubler, sdm_byp_div;
u32 sdm_dc_off, sdm_freq_seed, sdm2, sdm3;
- u32 ref_clk = VCO_REF_CLK_RATE;
+ u32 ref_clk = parent_rate;
unsigned long vco_rate;
VERB("parent_rate=%lu", parent_rate);
@@ -273,7 +272,7 @@ static unsigned long dsi_pll_28nm_clk_recalc_rate(struct
clk_hw *hw,
/* Check to see if the ref clk doubler is enabled */
doubler = pll_read(base + REG_DSI_28nm_PHY_PLL_REFCLK_CFG) &
DSI_28nm_PHY_PLL_REFCLK_CFG_DBLR;
- ref_clk += (doubler * VCO_REF_CLK_RATE);
+ ref_clk += (doubler * ref_clk);
/* see if it is integer mode or sdm mode */
sdm0 = pll_read(base + REG_DSI_28nm_PHY_PLL_SDM_CFG0);
@@ -514,11 +513,12 @@ static void dsi_pll_28nm_destroy(struct msm_dsi_pll *pll)
pll_28nm->clk_data.clk_num = 0;
}
-static int pll_28nm_register(struct dsi_pll_28nm *pll_28nm)
+static int pll_28nm_register(struct dsi_pll_28nm *pll_28nm,
+const char *ref_clk_name)
{
char clk_name[32], parent1[32], parent2[32], vco_name[32];
struct clk_init_data vco_init = {
- .parent_names = (const char *[]){ "xo" },
+ .parent_names = _clk_name,
.num_parents = 1,
.name = vco_name,
.flags = CLK_IGNORE_UNUSED,
@@ -593,6 +593,8 @@ struct msm_dsi_pll *msm_dsi_pll_28nm_init(struct
platform_device *pdev,
{
struct dsi_pll_28nm *pll_28nm;
struct msm_dsi_pll *pll;
+ struct clk *vco_ref_clk;
+ const char *vco_ref_clk_name;
int ret;
if (!pdev)
@@ -605,6 +607,18 @@ struct msm_dsi_pll *msm_dsi_pll_28nm_init(struct
platform_device *pdev,
pll_28nm->pdev = pdev;
pll_28nm->id = id;
+ vco_ref_clk = devm_clk_get(>dev, "ref");
+ if (!IS_ERR(vco_ref_clk)) {
+ vco_ref_clk_name = __clk_get_name(vco_ref_clk);
+ } else {
+ ret = PTR_ERR(vco_ref_clk);
+ if (ret == -EPROBE_DEFER)
+ ERR_PTR(ret);
+
+ dev_warn(>dev, "'ref' clock is not specified, using
default name\n");
+ vco_ref_clk_name = "xo";
+ }
+
pll_28nm->mmio = msm_ioremap(pdev, "dsi_pll", "DSI_PLL");
if (IS_ERR_OR_NULL(pll_28nm->mmio)) {
dev_err(>dev, "%s: failed to map pll base\n", __func__);
@@ -637,7 +651,7 @@ struct msm_dsi_pll *msm_dsi_pll_28nm_init(struct
platform_device *pdev,
[PATCH v4 8/8] ARM: dts: qcom-apq8064: Set 'xo_board' as ref clock of the DSI PHY
Add 'xo_board' as ref clock for the DSI PHY, it was previously hardcoded in the PLL 'driver' for the 28nm 8960 PHY. Signed-off-by: Matthias Kaehlcke Reviewed-by: Stephen Boyd --- Changes in v4: - added 'Reviewed-by: Stephen Boyd ' tag Changes in v3: - patch added to the series --- arch/arm/boot/dts/qcom-apq8064.dtsi | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi b/arch/arm/boot/dts/qcom-apq8064.dtsi index 48c3cf4276101..d337ae9326cd8 100644 --- a/arch/arm/boot/dts/qcom-apq8064.dtsi +++ b/arch/arm/boot/dts/qcom-apq8064.dtsi @@ -1338,8 +1338,9 @@ <0x04700300 0x200>, <0x04700500 0x5c>; reg-names = "dsi_pll", "dsi_phy", "dsi_phy_regulator"; - clock-names = "iface_clk"; - clocks = < DSI_M_AHB_CLK>; + clock-names = "iface_clk", "ref"; + clocks = < DSI_M_AHB_CLK>, +<_board>; }; -- 2.20.0.rc1.387.gf8505762e3-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] of/device: add blacklist for iommu dma_ops
On Sat, Dec 1, 2018 at 10:54 AM Rob Clark wrote:
>
> This solves a problem we see with drm/msm, caused by getting
> iommu_dma_ops while we attach our own domain and manage it directly at
> the iommu API level:
>
> [0038] user address but active_mm is swapper
> Internal error: Oops: 9605 [#1] PREEMPT SMP
> Modules linked in:
> CPU: 7 PID: 70 Comm: kworker/7:1 Tainted: GW 4.19.3 #90
> Hardware name: xxx (DT)
> Workqueue: events deferred_probe_work_func
> pstate: 80c9 (Nzcv daif +PAN +UAO)
> pc : iommu_dma_map_sg+0x7c/0x2c8
> lr : iommu_dma_map_sg+0x40/0x2c8
> sp : ff80095eb4f0
> x29: ff80095eb4f0 x28:
> x27: ffc0f9431578 x26:
> x25: x24: 0003
> x23: 0001 x22: ffc0fa9ac010
> x21: x20: ffc0fab40980
> x19: ffc0fab40980 x18: 0003
> x17: 01c4 x16: 0007
> x15: 000e x14:
> x13: x12: 0028
> x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f
> x9 : x8 : ffc0fab409a0
> x7 : x6 : 0002
> x5 : 0001 x4 :
> x3 : 0001 x2 : 0002
> x1 : ffc0f9431578 x0 :
> Process kworker/7:1 (pid: 70, stack limit = 0x17d08ffb)
> Call trace:
>iommu_dma_map_sg+0x7c/0x2c8
>__iommu_map_sg_attrs+0x70/0x84
>get_pages+0x170/0x1e8
>msm_gem_get_iova+0x8c/0x128
>_msm_gem_kernel_new+0x6c/0xc8
>msm_gem_kernel_new+0x4c/0x58
>dsi_tx_buf_alloc_6g+0x4c/0x8c
>msm_dsi_host_modeset_init+0xc8/0x108
>msm_dsi_modeset_init+0x54/0x18c
>_dpu_kms_drm_obj_init+0x430/0x474
>dpu_kms_hw_init+0x5f8/0x6b4
>msm_drm_bind+0x360/0x6c8
>try_to_bring_up_master.part.7+0x28/0x70
>component_master_add_with_match+0xe8/0x124
>msm_pdev_probe+0x294/0x2b4
>platform_drv_probe+0x58/0xa4
>really_probe+0x150/0x294
>driver_probe_device+0xac/0xe8
>__device_attach_driver+0xa4/0xb4
>bus_for_each_drv+0x98/0xc8
>__device_attach+0xac/0x12c
>device_initial_probe+0x24/0x30
>bus_probe_device+0x38/0x98
>deferred_probe_work_func+0x78/0xa4
>process_one_work+0x24c/0x3dc
>worker_thread+0x280/0x360
>kthread+0x134/0x13c
>ret_from_fork+0x10/0x18
> Code: d284 91000725 6b17039f 5400048a (f9401f40)
> ---[ end trace f22dda57f3648e2c ]---
> Kernel panic - not syncing: Fatal exception
> SMP: stopping secondary CPUs
> Kernel Offset: disabled
> CPU features: 0x0,22802a18
> Memory Limit: none
>
> The problem is that when drm/msm does it's own iommu_attach_device(),
> now the domain returned by iommu_get_domain_for_dev() is drm/msm's
> domain, and it doesn't have domain->iova_cookie.
>
> We kind of avoided this problem prior to sdm845/dpu because the iommu
> was attached to the mdp node in dt, which is a child of the toplevel
> mdss node (which corresponds to the dev passed in dma_map_sg()). But
> with sdm845, now the iommu is attached at the mdss level so we hit the
> iommu_dma_ops in dma_map_sg().
>
> But auto allocating/attaching a domain before the driver is probed was
> already a blocking problem for enabling per-context pagetables for the
> GPU. This problem is also now solved with this patch.
>
> Fixes: 97890ba9289c dma-mapping: detect and configure IOMMU in
> of_dma_configure
> Tested-by: Douglas Anderson
> Signed-off-by: Rob Clark
> ---
> This is an alternative/replacement for [1]. What it lacks in elegance
> it makes up for in practicality ;-)
>
> [1] https://patchwork.freedesktop.org/patch/264930/
>
> drivers/of/device.c | 22 ++
> 1 file changed, 22 insertions(+)
>
> diff --git a/drivers/of/device.c b/drivers/of/device.c
> index 5957cd4fa262..15ffee00fb22 100644
> --- a/drivers/of/device.c
> +++ b/drivers/of/device.c
> @@ -72,6 +72,14 @@ int of_device_add(struct platform_device *ofdev)
> return device_add(>dev);
> }
>
> +static const struct of_device_id iommu_blacklist[] = {
> + { .compatible = "qcom,mdp4" },
> + { .compatible = "qcom,mdss" },
> + { .compatible = "qcom,sdm845-mdss" },
> + { .compatible = "qcom,adreno" },
> + {}
> +};
Not completely clear to whether this is still needed or not, but this
really won't scale. Why can't the driver for these devices override
whatever has been setup by default?
Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108710] Since 4.20 kernel Vega 56 hangs when I surf pages in steam client
https://bugs.freedesktop.org/show_bug.cgi?id=108710 --- Comment #12 from mikhail.v.gavri...@gmail.com --- Created attachment 142726 --> https://bugs.freedesktop.org/attachment.cgi?id=142726=edit 4.20 g94f371cb7394 + mesa 18.3.0-rc5 -- 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 108710] Since 4.20 kernel Vega 56 hangs when I surf pages in steam client
https://bugs.freedesktop.org/show_bug.cgi?id=108710 --- Comment #11 from mikhail.v.gavri...@gmail.com --- I am was able reproduce this issue again with mesa 18.3.0-rc5 -- 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 108937] [radeonsi, RX480] VAAPI H.264 decoder produces garbage on YouTube in Chromium with h264ify
https://bugs.freedesktop.org/show_bug.cgi?id=108937 --- Comment #2 from Christoph Haag --- Try setting allow_rgb10_configs to false for chromium in drirc or starting chromium with the env var allow_rgb10_configs=false chromium see also bug #104597 -- 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: [RFC v3 11/19] kunit: add Python libraries for handing KUnit config and kernel
On Mon, Dec 03, 2018 at 03:50:48PM -0800, Brendan Higgins wrote: > On Thu, Nov 29, 2018 at 7:44 PM Luis Chamberlain wrote: > > > > On Wed, Nov 28, 2018 at 11:36:28AM -0800, Brendan Higgins wrote: > > > The ultimate goal is to create minimal isolated test binaries; in the > > > meantime we are using UML to provide the infrastructure to run tests, so > > > define an abstract way to configure and run tests that allow us to > > > change the context in which tests are built without affecting the user. > > > This also makes pretty and dynamic error reporting, and a lot of other > > > nice features easier. > > > > > > kunit_config.py: > > > - parse .config and Kconfig files. > > > > > > > > > kunit_kernel.py: provides helper functions to: > > > - configure the kernel using kunitconfig. > > > > We get the tools to run the config stuff, build, etc, but not a top > > level 'make kunitconfig' or whatever. We have things like 'make > > kvmconfig' and 'make xenconfig', I think it would be reasonable to > > add similar for this. > > Are you just asking for a defconfig for KUnit, or are you asking for a > way to run KUnit from make? At least the first. The later seems intrusive as a top level Makefile thing. Luis ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v3 11/19] kunit: add Python libraries for handing KUnit config and kernel
On Mon, Dec 03, 2018 at 03:48:15PM -0800, Brendan Higgins wrote: > On Thu, Nov 29, 2018 at 5:54 AM Kieran Bingham > wrote: > > > > Hi Brendan, > > > > Thanks again for this series! > > > > On 28/11/2018 19:36, Brendan Higgins wrote: > > > The ultimate goal is to create minimal isolated test binaries; in the > > > meantime we are using UML to provide the infrastructure to run tests, so > > > define an abstract way to configure and run tests that allow us to > > > change the context in which tests are built without affecting the user. > > > This also makes pretty and dynamic error reporting, and a lot of other > > > nice features easier. > > > > > > I wonder if we could somehow generate a shared library object > > 'libkernel' or 'libumlinux' from a UM configured set of headers and > > objects so that we could create binary targets directly ? > > That's an interesting idea. I think it would be difficult to figure > out exactly where to draw the line of what goes in there and what > needs to be built specific to a test a priori. Of course, that leads > into the biggest problem in general, needed to know what I need to > build to test the thing that I want to test. > > Nevertheless, I could definitely imagine that being useful in a lot of cases. Whether or not we can abstract away the kernel into such a mechanism with uml libraries is a good question worth exploring. Developers working upstream do modify their kernels a lot, so we'd have to update such libraries quite a bit, but I think that's fine too. The *real* value I think from the above suggestion would be enterprise / mobile distros or stable kernel maintainers which have a static kernel they need to support for a relatively *long time*, consider a 10 year time frame. Running unit tests without qemu with uml and libraries for respective kernels seems real worthy. The overhead for testing a unit test for said targets, *ideally*, would just be to to reboot into the system with such libraries available, a unit test would just look for the respective uname -r library and mimic that kernel, much the same way enterprise distributions today rely on having debugging symbols available to run against crash / gdb. Having debug modules / kernel for crash requires such effort already, so this would just be an extra layer of other prospect tests. All ideaware for now, but the roadmap seems to be paving itself. Luis ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND PATCH v3] drm/msm: Move fence put to where failure occurs
On Tue, Dec 4, 2018 at 11:56 AM Robert Foss wrote:
>
> If dma_fence_wait fails to wait for a supplied in-fence in
> msm_ioctl_gem_submit, make sure we release that in-fence.
>
> Also remove this dma_fence_put() from the 'out' label.
>
> Signed-off-by: Robert Foss
> Reviewed-by: Chris Wilson
> Cc: sta...@vger.kernel.org
Fyi, this is queued up in msm-next/fixes
BR,
-R
> ---
> drivers/gpu/drm/msm/msm_gem_submit.c | 15 ---
> 1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
> b/drivers/gpu/drm/msm/msm_gem_submit.c
> index a90aedd6883a..d5e6665a4c8f 100644
> --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> @@ -411,7 +411,6 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
> *data,
> struct msm_file_private *ctx = file->driver_priv;
> struct msm_gem_submit *submit;
> struct msm_gpu *gpu = priv->gpu;
> - struct dma_fence *in_fence = NULL;
> struct sync_file *sync_file = NULL;
> struct msm_gpu_submitqueue *queue;
> struct msm_ringbuffer *ring;
> @@ -444,6 +443,8 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
> *data,
> ring = gpu->rb[queue->prio];
>
> if (args->flags & MSM_SUBMIT_FENCE_FD_IN) {
> + struct dma_fence *in_fence;
> +
> in_fence = sync_file_get_fence(args->fence_fd);
>
> if (!in_fence)
> @@ -453,11 +454,13 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
> *data,
> * Wait if the fence is from a foreign context, or if the
> fence
> * array contains any fence from a foreign context.
> */
> - if (!dma_fence_match_context(in_fence, ring->fctx->context)) {
> + ret = 0;
> + if (!dma_fence_match_context(in_fence, ring->fctx->context))
> ret = dma_fence_wait(in_fence, true);
> - if (ret)
> - return ret;
> - }
> +
> + dma_fence_put(in_fence);
> + if (ret)
> + return ret;
> }
>
> ret = mutex_lock_interruptible(>struct_mutex);
> @@ -583,8 +586,6 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
> *data,
> }
>
> out:
> - if (in_fence)
> - dma_fence_put(in_fence);
> submit_cleanup(submit);
> if (ret)
> msm_gem_submit_free(submit);
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm: Only add available components
On Tue, Dec 4, 2018 at 1:04 PM Douglas Anderson wrote: > > When trying to get the display up on my sdm845 board I noticed that > the display wouldn't probe if I had the dsi1 node marked as "disabled" > even though my board doesn't use dsi1. It looks like the msm code > adds all nodes to its list of components even if they are disabled. I > believe this doesn't work because all registered components need to > come up before we finish probing. Let's do like other DRM code and > only add available components. > > Signed-off-by: Douglas Anderson yeah, that seems like a reasonable thing to do Reviewed-by: Rob Clark > --- > > drivers/gpu/drm/msm/msm_drv.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c > index b1577e960889..0b828822117b 100644 > --- a/drivers/gpu/drm/msm/msm_drv.c > +++ b/drivers/gpu/drm/msm/msm_drv.c > @@ -1190,8 +1190,10 @@ static int add_components_mdp(struct device *mdp_dev, > if (!intf) > continue; > > - drm_of_component_match_add(master_dev, matchptr, compare_of, > - intf); > + if (of_device_is_available(intf)) > + drm_of_component_match_add(master_dev, matchptr, > + compare_of, intf); > + > of_node_put(intf); > } > > -- > 2.20.0.rc1.387.gf8505762e3-goog > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dt-bindings: display: add binding for Innolux ee101ia-01d panel
On Tue, 13 Nov 2018 13:42:05 +0100, Heiko Stuebner wrote: > From: Heiko Stuebner > > This is a panel handled through the generic lvds-panel binding, > so only needs its additional compatible specified. > > Signed-off-by: Heiko Stuebner > --- > .../bindings/display/panel/innolux,ee101ia-01d.txt | 7 +++ > 1 file changed, 7 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.txt > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: rcar-du: dw-hdmi: Reject modes with a too high clock frequency
Hi Geert,
On Tuesday, 4 December 2018 21:45:10 EET Geert Uytterhoeven wrote:
> On Tue, Dec 4, 2018 at 7:51 PM Laurent Pinchart wrote:
> > On Tuesday, 4 December 2018 20:42:53 EET Geert Uytterhoeven wrote:
> > > On Tue, Dec 4, 2018 at 7:12 PM Laurent Pinchart wrote:
> > > > On Tuesday, 4 December 2018 19:30:25 EET Geert Uytterhoeven wrote:
> > > >> On Tue, Dec 4, 2018 at 5:36 PM Laurent Pinchart wrote:
> > > >>> Implement a .mode_valid() handler in the R-Car glue layer to reject
> > > >>> modes with an unsupported clock frequency.
> > > >>>
> > > >>> Signed-off-by: Laurent Pinchart
> > > >>>
> > > >>
> > > >> Thanks for your patch!
> > > >>
> > > >>> --- a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> > > >>> +++ b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> > > >>> @@ -35,6 +35,20 @@ static const struct rcar_hdmi_phy_params
> > > >>> rcar_hdmi_phy_params[] = {
> > > >>>
> > > >>> { ~0UL, 0x, 0x, 0x },
> > > >>>
> > > >>> };
> > > >>>
> > > >>> +static enum drm_mode_status
> > > >>> +rcar_hdmi_mode_valid(struct drm_connector *connector,
> > > >>> +const struct drm_display_mode *mode)
> > > >>> +{
> > > >>> + /*
> > > >>> +* The maximum supported clock frequency is 297 MHz, as
> > > >>> shown
> > > >>> in the PHY
> > > >>> +* parameters table.
> > > >>> +*/
> > > >>> + if (mode->clock > 297000)
> > > >>> + return MODE_CLOCK_HIGH;
> > > >>
> > > >> Perhaps you need a check for the lower limit (25 MHz), too?
> > > >
> > > > There's no lower limit implied by the rcar_hdmi_phy_params table.
> > >
> > > Oh, you mean the table in the driver, not a table in the Hardware User's
> > > Manual?
> >
> > Correct, I mean the table in the driver. This patch was prompted by an
> > error returned from rcar_hdmi_phy_configure() when the mode frequency was
> > too high, making mode setting failed. I've thus added a .mode_valid()
> > handler to ensure that invalid modes don't get exposed to upper layers,
> > fixing such use cases as fbvon on a 4K monitor (where the fbcon was
> > picking a mode advertised as supported by the driver while its frequency
> > was too high).
> >
> > > That's why I couldn't find the table, but only a short notice in the
> > > HDMI section of the Hardware User's Manual, stating:
> > >
> > > Pixel clock from 25MHz up to 297MHz
> >
> > Well, the IP core vendor doesn't allow us to submit patches based on the
> > content of non-public documentation, so I'm afraid I won't sign such a
> > patch without being given explicit permission. It's a very stupid game
> > really, but I don't set the rules :-(
>
> https://en.wikipedia.org/wiki/HDMI claims 25 MHz is the minimum TMDS rate
> for HDMI anyway. Anything below that needs to use pixel replication.
>
> So you can reject < 25 MHz for sure.
That should then be performed in the common dw_hdmi_bridge_mode_valid()
handler, in drivers/gpu/drm/bridge/synopsys/dw-hdmi.c.
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107946] AMDGPU regression, multi-head not working on 4.18, 4.19RC3, but does on 4.16
https://bugs.freedesktop.org/show_bug.cgi?id=107946 Alex Deucher changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED -- 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 107946] AMDGPU regression, multi-head not working on 4.18, 4.19RC3, but does on 4.16
https://bugs.freedesktop.org/show_bug.cgi?id=107946 --- Comment #7 from Dave Johnson --- This has been resolved for me in the current 4.19 stable build. Thanks! -- 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 v2] drm: rcar-du: dw-hdmi: Reject modes with a too high clock frequency
Hi Laurent,
On Tue, Dec 4, 2018 at 7:51 PM Laurent Pinchart
wrote:
> On Tuesday, 4 December 2018 20:42:53 EET Geert Uytterhoeven wrote:
> > On Tue, Dec 4, 2018 at 7:12 PM Laurent Pinchart wrote:
> > > On Tuesday, 4 December 2018 19:30:25 EET Geert Uytterhoeven wrote:
> > >> On Tue, Dec 4, 2018 at 5:36 PM Laurent Pinchart wrote:
> > >>> Implement a .mode_valid() handler in the R-Car glue layer to reject
> > >>> modes with an unsupported clock frequency.
> > >>>
> > >>> Signed-off-by: Laurent Pinchart
> > >>>
> > >>
> > >> Thanks for your patch!
> > >>
> > >>> --- a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> > >>> +++ b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> > >>> @@ -35,6 +35,20 @@ static const struct rcar_hdmi_phy_params
> > >>> rcar_hdmi_phy_params[] = {
> > >>> { ~0UL, 0x, 0x, 0x },
> > >>> };
> > >>>
> > >>> +static enum drm_mode_status
> > >>> +rcar_hdmi_mode_valid(struct drm_connector *connector,
> > >>> +const struct drm_display_mode *mode)
> > >>> +{
> > >>> + /*
> > >>> +* The maximum supported clock frequency is 297 MHz, as shown
> > >>> in the PHY
> > >>> +* parameters table.
> > >>> +*/
> > >>> + if (mode->clock > 297000)
> > >>> + return MODE_CLOCK_HIGH;
> > >>
> > >> Perhaps you need a check for the lower limit (25 MHz), too?
> > >
> > > There's no lower limit implied by the rcar_hdmi_phy_params table.
> >
> > Oh, you mean the table in the driver, not a table in the Hardware User's
> > Manual?
>
> Correct, I mean the table in the driver. This patch was prompted by an error
> returned from rcar_hdmi_phy_configure() when the mode frequency was too high,
> making mode setting failed. I've thus added a .mode_valid() handler to ensure
> that invalid modes don't get exposed to upper layers, fixing such use cases as
> fbvon on a 4K monitor (where the fbcon was picking a mode advertised as
> supported by the driver while its frequency was too high).
>
> > That's why I couldn't find the table, but only a short notice in the HDMI
> > section of the Hardware User's Manual, stating:
> >
> > Pixel clock from 25MHz up to 297MHz
>
> Well, the IP core vendor doesn't allow us to submit patches based on the
> content of non-public documentation, so I'm afraid I won't sign such a patch
> without being given explicit permission. It's a very stupid game really, but I
> don't set the rules :-(
https://en.wikipedia.org/wiki/HDMI claims 25 MHz is the minimum TMDS rate
for HDMI anyway. Anything below that needs to use pixel replication.
So you can reject < 25 MHz for sure.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201067] [bisected] [4.19-rc2 regression] Display corruption with Vega 64 in 4.19-rc2
https://bugzilla.kernel.org/show_bug.cgi?id=201067 --- Comment #12 from Dave Johnson (d...@locochino.com) --- This is fixed for me in 4.19-stable -- 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 v3 2/4] drm/i915: Fix platform coverage for HDCP1.4
On Tue, Dec 04, 2018 at 11:37:05PM +0530, Ramalingam C wrote:
> HDCP1.4 is enabled and validated only on GEN9+ platforms.
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/i915/intel_hdcp.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index c16bffcce3b0..bccfb001340a 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -769,8 +769,7 @@ static void intel_hdcp_prop_work(struct work_struct *work)
> bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port)
> {
> /* PORT E doesn't have HDCP, and PORT F is disabled */
> - return ((INTEL_GEN(dev_priv) >= 8 || IS_HASWELL(dev_priv)) &&
> - !IS_CHERRYVIEW(dev_priv) && port < PORT_E);
> + return ((INTEL_GEN(dev_priv) >= 9) && port < PORT_E);
Drive-by: Lots of pointless parens floating around here.
> }
>
> int intel_hdcp_init(struct intel_connector *connector,
> --
> 2.7.4
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/edid: Pass connector to AVI inforframe functions
On Tue, Dec 04, 2018 at 08:46:53AM +0100, Andrzej Hajda wrote: > On 03.12.2018 22:38, Ville Syrjälä wrote: > > On Thu, Nov 29, 2018 at 10:08:07AM +0100, Andrzej Hajda wrote: > >> On 21.11.2018 19:19, Laurent Pinchart wrote: > >>> Hi Ville, > >>> > >>> Thank you for the patch. > >>> > >>> On Tuesday, 20 November 2018 18:13:42 EET Ville Syrjala wrote: > From: Ville Syrjälä > > Make life easier for drivers by simply passing the connector > to drm_hdmi_avi_infoframe_from_display_mode() and > drm_hdmi_avi_infoframe_quant_range(). That way drivers don't > need to worry about is_hdmi2_sink mess. > >>> While this is good for display controller drivers, the change isn't great > >>> for > >>> bridge drivers. Down the road we're looking at moving connector support > >>> out of > >>> the bridge drivers. Adding an additional dependency to connectors in the > >>> bridges will make that more difficult. Ideally bridges should retrieve > >>> the > >>> information from their sink, regardless of whether it is a connector or > >>> another bridge. > >> > >> I agree with it, and case of sii8620 shows that there are cases where > >> bridge has no direct access to the connector. > > It's just a matter of plumbing it through. > > > What do you mean exactly? void bridge_foo(... + ,struct drm_connector *connector); > > > > > >> On the other side, since you are passing connector to > >> drm_hdmi_avi_infoframe_from_display_mode(), you could drop mode > >> parameter and rename the function to > >> drm_hdmi_avi_infoframe_from_connector() then, unless mode passed and > >> mode set on the connector differs? > > Connectors don't have a mode. > > > As they are passing video stream they should have it, even if not > directly, for example: > > connector->state->crtc->mode That's not really how atomic works. One shouldn't go digging through the obj->state pointers when we're not holding the relevant locks anymore. The atomic way would be to pass either both crtc state and connector state, or drm_atomic_state + crtc/connector. > > In moment of creating infoframe it should be set properly. > > > Regards > > Andrzej > > > > > >> > >> Regards > >> > >> Andrzej > >> > >> > >>> Please see below for an additional comment. > >>> > Cc: Alex Deucher > Cc: "Christian König" > Cc: "David (ChunMing) Zhou" > Cc: Archit Taneja > Cc: Andrzej Hajda > Cc: Laurent Pinchart > Cc: Inki Dae > Cc: Joonyoung Shim > Cc: Seung-Woo Kim > Cc: Kyungmin Park > Cc: Russell King > Cc: CK Hu > Cc: Philipp Zabel > Cc: Rob Clark > Cc: Ben Skeggs > Cc: Tomi Valkeinen > Cc: Sandy Huang > Cc: "Heiko Stübner" > Cc: Benjamin Gaignard > Cc: Vincent Abriou > Cc: Thierry Reding > Cc: Eric Anholt > Cc: Shawn Guo > Cc: Ilia Mirkin > Cc: amd-...@lists.freedesktop.org > Cc: linux-arm-...@vger.kernel.org > Cc: freedr...@lists.freedesktop.org > Cc: nouv...@lists.freedesktop.org > Cc: linux-te...@vger.kernel.org > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 2 +- > drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 2 +- > drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 3 ++- > drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 +- > drivers/gpu/drm/bridge/analogix-anx78xx.c | 5 ++-- > drivers/gpu/drm/bridge/sii902x.c | 3 ++- > drivers/gpu/drm/bridge/sil-sii8620.c | 3 +-- > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 3 ++- > drivers/gpu/drm/drm_edid.c| 33 ++- > drivers/gpu/drm/exynos/exynos_hdmi.c | 3 ++- > drivers/gpu/drm/i2c/tda998x_drv.c | 3 ++- > drivers/gpu/drm/i915/intel_hdmi.c | 14 +- > drivers/gpu/drm/i915/intel_lspcon.c | 15 ++- > drivers/gpu/drm/i915/intel_sdvo.c | 10 --- > drivers/gpu/drm/mediatek/mtk_hdmi.c | 3 ++- > drivers/gpu/drm/msm/hdmi/hdmi_bridge.c| 3 ++- > drivers/gpu/drm/nouveau/dispnv50/disp.c | 7 +++-- > drivers/gpu/drm/omapdrm/omap_encoder.c| 5 ++-- > drivers/gpu/drm/radeon/radeon_audio.c | 2 +- > drivers/gpu/drm/rockchip/inno_hdmi.c | 4 ++- > drivers/gpu/drm/sti/sti_hdmi.c| 3 ++- > drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c| 3 ++- > drivers/gpu/drm/tegra/hdmi.c | 3 ++- > drivers/gpu/drm/tegra/sor.c | 3 ++- > drivers/gpu/drm/vc4/vc4_hdmi.c| 11 +--- > drivers/gpu/drm/zte/zx_hdmi.c | 4 ++- > include/drm/drm_edid.h| 8 +++--- > 27 files changed, 94 insertions(+), 66 deletions(-) > >>> For dw-hdmi and omapdrm, > >>> > >>> Reviewed-by: Laurent Pinchart > >>> -- Ville Syrjälä Intel
Re: [PATCH 1/4] drm/edid: Pass connector to AVI inforframe functions
On Tue, Dec 04, 2018 at 08:03:53AM +0100, Andrzej Hajda wrote:
> On 03.12.2018 22:48, Ville Syrjälä wrote:
> > On Thu, Nov 29, 2018 at 09:46:16AM +0100, Andrzej Hajda wrote:
> >> Quite late, hopefully not too late.
> >>
> >>
> >> On 21.11.2018 12:51, Ville Syrjälä wrote:
> >>> On Wed, Nov 21, 2018 at 01:40:43PM +0200, Jani Nikula wrote:
> > return;
> > diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c
> > b/drivers/gpu/drm/bridge/sil-sii8620.c
> > index a6e8f4591e63..0cc293a6ac24 100644
> > --- a/drivers/gpu/drm/bridge/sil-sii8620.c
> > +++ b/drivers/gpu/drm/bridge/sil-sii8620.c
> > @@ -1104,8 +1104,7 @@ static void sii8620_set_infoframes(struct sii8620
> > *ctx,
> > int ret;
> >
> > ret = drm_hdmi_avi_infoframe_from_display_mode(,
> > - mode,
> > - true);
> > + NULL, mode);
> > if (ctx->use_packed_pixel)
> > frm.avi.colorspace = HDMI_COLORSPACE_YUV422;
> >
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > index 64c3cf027518..88b720b63126 100644
> > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > @@ -1344,7 +1344,8 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi,
> > struct drm_display_mode *mode)
> > u8 val;
> >
> > /* Initialise info frame from DRM mode */
> > - drm_hdmi_avi_infoframe_from_display_mode(, mode, false);
> > + drm_hdmi_avi_infoframe_from_display_mode(,
> > +>connector,
> > mode);
> >
> > if (hdmi_bus_fmt_is_yuv444(hdmi->hdmi_data.enc_out_bus_format))
> > frame.colorspace = HDMI_COLORSPACE_YUV444;
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index b506e3622b08..501ac05ba7da 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -4830,19 +4830,32 @@ void drm_set_preferred_mode(struct
> > drm_connector *connector,
> > }
> > EXPORT_SYMBOL(drm_set_preferred_mode);
> >
> > +static bool is_hdmi2_sink(struct drm_connector *connector)
> You're usually known for adding const all around, why not const pointer
> here and in all the other drm_* functions that call this?
> >>> My current approach is to constify states/fbs/etc. but not so much
> >>> crtcs/connectors/etc. Too much const can sometimes get in the way
> >>> of things requiring that you remove the const later. But I guess
> >>> in this case the const shouldn't really get in the way of anything
> >>> because these are pretty much supposed to be pure functions.
> >>>
> > +{
> > + /*
> > +* FIXME: sil-sii8620 doesn't have a connector around when
> > +* we need one, so we have to be prepared for a NULL connector.
> > +*/
> > + if (!connector)
> > + return false;
> This actually changes the is_hdmi2_sink value for sil-sii8620.
> >>> Hmm. No idea why they would have set that to true when everyone else is
> >>> passing false.
> >>
> >> Because false does not work :) More precisely MHLv3 (used in Sii8620)
> >> uses CTA-861-F standard for infoframes, which is specific to HDMI2.0.
> >>
> >> Unfortunately I have no access to MHL specs, but my experiments and
> >> vendor drivers strongly suggests it is done this way.
> >>
> >> This is important in case of 4K modes which are handled differently by
> >> HDMI 1.4 and HDMI2.0.
> > HDMI 2.0 handles 4k just like 1.4 handled it when you use one of
> > the 4k modes defined in 1.4. Only if you use features beyond 1.4 do we
> > switch over to the HDMI 2.0 specific signalling.
>
>
> The difference is in infoframes:
>
> HDMI 1.4 sets AVI infoframe VIC to 0, and sends HDMI_VIC in VSI.
>
> HDMI 2.0 sets AVI infoframe to non zero VICs introduced by
> HDMI2.0/CEA-861-F, VSI can be omitted if I remember correctly, unless 3d
> is in use.
Like I said, The HDMI 1.4 method is used even with HDMI 2.0 sinks unless
some feature gets used which can't be signalled via the HDMI 1.4 vendor
specific infoframe.
>
>
> So setting VICs to non-zero in case of HDMI1.4 sinks and 4k modes seems
> risky.
That is not what I was proposing.
>
>
> Regards
>
> Andrzej
>
>
> >
> >> The pipeline looks like (in parenthesis HDMI version on the stream):
> >>
> >> exynos_hdmi --(1.4)--> SII8620 --(2.0)--> MHL_dongle --(1.4)--> TV
> >>
> >>
> >>> I guess I can change this to true to not change it. IIRC
> >>> that was the only driver that didn't have a connector around.
> >>>
> >>> That said, I was actually thinking of removing this hdmi2 vs. not
> >>> stuff from
Re: [PATCH v2] drm: rcar-du: dw-hdmi: Reject modes with a too high clock frequency
Hi Geert,
On Tuesday, 4 December 2018 20:42:53 EET Geert Uytterhoeven wrote:
> On Tue, Dec 4, 2018 at 7:12 PM Laurent Pinchart wrote:
> > On Tuesday, 4 December 2018 19:30:25 EET Geert Uytterhoeven wrote:
> >> On Tue, Dec 4, 2018 at 5:36 PM Laurent Pinchart wrote:
> >>> Implement a .mode_valid() handler in the R-Car glue layer to reject
> >>> modes with an unsupported clock frequency.
> >>>
> >>> Signed-off-by: Laurent Pinchart
> >>>
> >>
> >> Thanks for your patch!
> >>
> >>> --- a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> >>> +++ b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> >>> @@ -35,6 +35,20 @@ static const struct rcar_hdmi_phy_params
> >>> rcar_hdmi_phy_params[] = {
> >>> { ~0UL, 0x, 0x, 0x },
> >>> };
> >>>
> >>> +static enum drm_mode_status
> >>> +rcar_hdmi_mode_valid(struct drm_connector *connector,
> >>> +const struct drm_display_mode *mode)
> >>> +{
> >>> + /*
> >>> +* The maximum supported clock frequency is 297 MHz, as shown
> >>> in the PHY
> >>> +* parameters table.
> >>> +*/
> >>> + if (mode->clock > 297000)
> >>> + return MODE_CLOCK_HIGH;
> >>
> >> Perhaps you need a check for the lower limit (25 MHz), too?
> >
> > There's no lower limit implied by the rcar_hdmi_phy_params table.
>
> Oh, you mean the table in the driver, not a table in the Hardware User's
> Manual?
Correct, I mean the table in the driver. This patch was prompted by an error
returned from rcar_hdmi_phy_configure() when the mode frequency was too high,
making mode setting failed. I've thus added a .mode_valid() handler to ensure
that invalid modes don't get exposed to upper layers, fixing such use cases as
fbvon on a 4K monitor (where the fbcon was picking a mode advertised as
supported by the driver while its frequency was too high).
> That's why I couldn't find the table, but only a short notice in the HDMI
> section of the Hardware User's Manual, stating:
>
> Pixel clock from 25MHz up to 297MHz
Well, the IP core vendor doesn't allow us to submit patches based on the
content of non-public documentation, so I'm afraid I won't sign such a patch
without being given explicit permission. It's a very stupid game really, but I
don't set the rules :-(
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: rcar-du: dw-hdmi: Reject modes with a too high clock frequency
Hi Laurent,
On Tue, Dec 4, 2018 at 7:12 PM Laurent Pinchart
wrote:
> On Tuesday, 4 December 2018 19:30:25 EET Geert Uytterhoeven wrote:
> > On Tue, Dec 4, 2018 at 5:36 PM Laurent Pinchart wrote:
> > > Implement a .mode_valid() handler in the R-Car glue layer to reject
> > > modes with an unsupported clock frequency.
> > >
> > > Signed-off-by: Laurent Pinchart
> > >
> >
> > Thanks for your patch!
> >
> > > --- a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> > > +++ b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> > > @@ -35,6 +35,20 @@ static const struct rcar_hdmi_phy_params
> > > rcar_hdmi_phy_params[] = {
> > > { ~0UL, 0x, 0x, 0x },
> > > };
> > >
> > > +static enum drm_mode_status
> > > +rcar_hdmi_mode_valid(struct drm_connector *connector,
> > > +const struct drm_display_mode *mode)
> > > +{
> > > + /*
> > > +* The maximum supported clock frequency is 297 MHz, as shown in
> > > the PHY +* parameters table.
> > > +*/
> > > + if (mode->clock > 297000)
> > > + return MODE_CLOCK_HIGH;
> >
> > Perhaps you need a check for the lower limit (25 MHz), too?
>
> There's no lower limit implied by the rcar_hdmi_phy_params table.
Oh, you mean the table in the driver, not a table in the Hardware User's
Manual?
That's why I couldn't find the table, but only a short notice in the HDMI
section of the Hardware User's Manual, stating:
Pixel clock from 25MHz up to 297MHz
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108940] QHD bug? drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:1613 core_link_enable_stream+0xc14/0x1040
https://bugs.freedesktop.org/show_bug.cgi?id=108940 Alex Deucher changed: What|Removed |Added Attachment #142710|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
[PATCH v3 2/4] drm/i915: Fix platform coverage for HDCP1.4
HDCP1.4 is enabled and validated only on GEN9+ platforms.
Signed-off-by: Ramalingam C
Reviewed-by: Sean Paul
---
drivers/gpu/drm/i915/intel_hdcp.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index c16bffcce3b0..bccfb001340a 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -769,8 +769,7 @@ static void intel_hdcp_prop_work(struct work_struct *work)
bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port)
{
/* PORT E doesn't have HDCP, and PORT F is disabled */
- return ((INTEL_GEN(dev_priv) >= 8 || IS_HASWELL(dev_priv)) &&
- !IS_CHERRYVIEW(dev_priv) && port < PORT_E);
+ return ((INTEL_GEN(dev_priv) >= 9) && port < PORT_E);
}
int intel_hdcp_init(struct intel_connector *connector,
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: rcar-du: dw-hdmi: Reject modes with a too high clock frequency
Hi Geert,
On Tuesday, 4 December 2018 19:30:25 EET Geert Uytterhoeven wrote:
> On Tue, Dec 4, 2018 at 5:36 PM Laurent Pinchart wrote:
> > Implement a .mode_valid() handler in the R-Car glue layer to reject
> > modes with an unsupported clock frequency.
> >
> > Signed-off-by: Laurent Pinchart
> >
>
> Thanks for your patch!
>
> > --- a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> > @@ -35,6 +35,20 @@ static const struct rcar_hdmi_phy_params
> > rcar_hdmi_phy_params[] = {
> > { ~0UL, 0x, 0x, 0x },
> > };
> >
> > +static enum drm_mode_status
> > +rcar_hdmi_mode_valid(struct drm_connector *connector,
> > +const struct drm_display_mode *mode)
> > +{
> > + /*
> > +* The maximum supported clock frequency is 297 MHz, as shown in
> > the PHY +* parameters table.
> > +*/
> > + if (mode->clock > 297000)
> > + return MODE_CLOCK_HIGH;
>
> Perhaps you need a check for the lower limit (25 MHz), too?
There's no lower limit implied by the rcar_hdmi_phy_params table.
> > +
> > + return MODE_OK;
> > +}
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/4] HDCP1.4 Fixes - II
Couple of more HDCP1.4 fixes on - Key load process for CFL - Encryption status change time - debug log addition - active platform coverage v1 and v2 went into old series https://patchwork.freedesktop.org/series/38978/ as v8 and v9, due to the same series title. Now changed the title. Thanks Sean Paul for the reviews. Ramalingam C (4): drm/i915: Fix GEN9 HDCP1.4 key load process drm/i915: Fix platform coverage for HDCP1.4 drm/i915: debug log for REPLY_ACK missing drm/i915: Increase timeout for Encrypt status change drivers/gpu/drm/i915/intel_dp.c | 7 ++- drivers/gpu/drm/i915/intel_hdcp.c | 16 +--- 2 files changed, 15 insertions(+), 8 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/4] drm/i915: debug log for REPLY_ACK missing
Adding a debug log when the DP_AUX_NATIVE_REPLY_ACK is missing
for aksv write. This helps to locate the possible non responding
DP HDCP sinks.
v2:
Rewritten for readability [Sean Paul]
Signed-off-by: Ramalingam C
Reviewed-by: Sean Paul
---
drivers/gpu/drm/i915/intel_dp.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 38a6e82153fd..9f75ca04a344 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5579,7 +5579,12 @@ int intel_dp_hdcp_write_an_aksv(struct
intel_digital_port *intel_dig_port,
}
reply = (rxbuf[0] >> 4) & DP_AUX_NATIVE_REPLY_MASK;
- return reply == DP_AUX_NATIVE_REPLY_ACK ? 0 : -EIO;
+ if (reply != DP_AUX_NATIVE_REPLY_ACK) {
+ DRM_DEBUG_KMS("Aksv write: no DP_AUX_NATIVE_REPLY_ACK %x\n",
+ reply);
+ return -EIO;
+ }
+ return 0;
}
static int intel_dp_hdcp_read_bksv(struct intel_digital_port *intel_dig_port,
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 4/4] drm/i915: Increase timeout for Encrypt status change
At enable/disable of the HDCP encryption, for encryption status change
we need minimum one frame duration. And we might program this bit any
point(start/End) in the previous frame.
With 20mSec, observed the timeout for change in encryption status.
Since this is not time critical operation and we need to hold on
until the status is changed, fixing the timeout to 50mSec. (Based on
trial and error method!)
v2:
%s/TIME_FOR_ENCRYPT_STATUS_CHANGE/ENCRYPT_STATUS_CHANGE_TIMEOUT_MS
[Sean Paul]
Signed-off-by: Ramalingam C
Reviewed-by: Sean Paul
---
drivers/gpu/drm/i915/intel_hdcp.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index bccfb001340a..42541b50e575 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -15,6 +15,7 @@
#include "i915_reg.h"
#define KEY_LOAD_TRIES 5
+#define ENCRYPT_STATUS_CHANGE_TIMEOUT_MS 50
static
bool intel_hdcp_is_ksv_valid(u8 *ksv)
@@ -637,7 +638,8 @@ static int intel_hdcp_auth(struct intel_digital_port
*intel_dig_port,
/* Wait for encryption confirmation */
if (intel_wait_for_register(dev_priv, PORT_HDCP_STATUS(port),
- HDCP_STATUS_ENC, HDCP_STATUS_ENC, 20)) {
+ HDCP_STATUS_ENC, HDCP_STATUS_ENC,
+ ENCRYPT_STATUS_CHANGE_TIMEOUT_MS)) {
DRM_ERROR("Timed out waiting for encryption\n");
return -ETIMEDOUT;
}
@@ -667,7 +669,7 @@ static int _intel_hdcp_disable(struct intel_connector
*connector)
I915_WRITE(PORT_HDCP_CONF(port), 0);
if (intel_wait_for_register(dev_priv, PORT_HDCP_STATUS(port), ~0, 0,
- 20)) {
+ ENCRYPT_STATUS_CHANGE_TIMEOUT_MS)) {
DRM_ERROR("Failed to disable HDCP, timeout clearing status\n");
return -ETIMEDOUT;
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/4] drm/i915: Fix GEN9 HDCP1.4 key load process
HDCP1.4 key load process varies between Intel platform to platform.
For Gen9 platforms except BXT and GLK, HDCP1.4 key is loaded using
the GT Driver Mailbox interface. So all GEN9_BC platforms will use
the GT Driver Mailbox interface for HDCP1.4 key load.
v2:
Using the IS_GEN9_BC for filtering the platforms [Ville]
Signed-off-by: Ramalingam C
Reviewed-by: Sean Paul
---
drivers/gpu/drm/i915/intel_hdcp.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index 1bf487f94254..c16bffcce3b0 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -157,10 +157,11 @@ static int intel_hdcp_load_keys(struct drm_i915_private
*dev_priv)
/*
* Initiate loading the HDCP key from fuses.
*
-* BXT+ platforms, HDCP key needs to be loaded by SW. Only SKL and KBL
-* differ in the key load trigger process from other platforms.
+* BXT+ platforms, HDCP key needs to be loaded by SW. Only Gen 9
+* platforms except BXT and GLK, differ in the key load trigger process
+* from other platforms. So GEN9_BC uses the GT Driver Mailbox i/f.
*/
- if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)) {
+ if (IS_GEN9_BC(dev_priv)) {
mutex_lock(_priv->pcu_lock);
ret = sandybridge_pcode_write(dev_priv,
SKL_PCODE_LOAD_HDCP_KEYS, 1);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/3] arm64: dts: qcom: sdm845: Add dpu to sdm845 dts file
Hi,
On Mon, Dec 3, 2018 at 6:41 PM Jeykumar Sankaran wrote:
> >> + dsi1: dsi@ae96000 {
> >> + compatible = "qcom,mdss-dsi-ctrl";
> >> + reg = <0xae96000 0x400>;
> >> + reg-names = "dsi_ctrl";
> >> +
> >> + interrupt-parent = <>;
> >> + interrupts = <5 IRQ_TYPE_LEVEL_HIGH>;
> >> +
> >> + clocks = <
> >> DISP_CC_MDSS_BYTE1_CLK>,
> >> +<
> >> DISP_CC_MDSS_BYTE1_INTF_CLK>,
> >> +<
> >> DISP_CC_MDSS_PCLK1_CLK>,
> >> +<
> >> DISP_CC_MDSS_ESC1_CLK>,
> >> +<
> >> DISP_CC_MDSS_AHB_CLK>,
> >> +<
> >> DISP_CC_MDSS_AXI_CLK>;
> >> + clock-names = "byte",
> >> + "byte_intf",
> >> + "pixel",
> >> + "core",
> >> + "iface",
> >> + "bus";
> >> +
> >> + phys = <_phy>;
> >> + phy-names = "dsi1";
> >> +
> >> + status = "disabled";
> >
> > This "disabled" is causing me problems. I don't actually need "dsi1"
> > but if I don't enable "dsi1" then my display doesn't come up. :( I
> > ran out of time to debug but I wonder if this is this the standard
> > thing where DRM needs to wait for all the components to probe until it
> > can finish? If nobody on this list just knows I'll dig tomorrow and
> > confirm that my memory isn't faulty and see what we've done about this
> > in the past.
> >
> https://patchwork.kernel.org/patch/10467895/
>
> Can you try out with this change (reviewed but not merged yet). It
> validates
> the nodes before adding to the DSI list.
No, that doesn't fix it. I also don't see your printout.
OK, found the problem and posted a patch. See
.
Please test and review if you are able.
> > One last note: it's pretty weird that you sent out only 1/3 and not
> > 2/3 and 3/3. If you're not ready to send out MTP stuff yet then you
> > should send out v6 as just a singleton patch.
> Yes. I was trying to separate this one out as an independent change.
> Sandeep
> is working on the comments on removing the pinctrl nodes and updated
> mtp nodes. He should be posting 2/3 and 3/3 in the next couple of days.
OK, good to know. Probably 2/3 and 3/3 will be squashed anyway since
(as I suggested in the review) they should both be touching the MTP
device tree file.
...in any case, you should send yours out as a singleton patch and
then you don't have to guess how many patches might or might not be
sent out later. Sandeep can send out his patch and say it depends on
yours.
-Doug
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm: Only add available components
When trying to get the display up on my sdm845 board I noticed that the display wouldn't probe if I had the dsi1 node marked as "disabled" even though my board doesn't use dsi1. It looks like the msm code adds all nodes to its list of components even if they are disabled. I believe this doesn't work because all registered components need to come up before we finish probing. Let's do like other DRM code and only add available components. Signed-off-by: Douglas Anderson --- drivers/gpu/drm/msm/msm_drv.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c index b1577e960889..0b828822117b 100644 --- a/drivers/gpu/drm/msm/msm_drv.c +++ b/drivers/gpu/drm/msm/msm_drv.c @@ -1190,8 +1190,10 @@ static int add_components_mdp(struct device *mdp_dev, if (!intf) continue; - drm_of_component_match_add(master_dev, matchptr, compare_of, - intf); + if (of_device_is_available(intf)) + drm_of_component_match_add(master_dev, matchptr, + compare_of, intf); + of_node_put(intf); } -- 2.20.0.rc1.387.gf8505762e3-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-next
Hi Dave, last i915 changes for -next. drm-intel-next-2018-12-04: Final drm/i915 changes for v4.21: - ICL DSI video mode enabling (Madhav, Vandita, Jani, Imre) - eDP sink count fix (José) - PSR fixes (José) - DRM DP helper and i915 DSC enabling (Manasi, Gaurav, Anusha) - DP FEC enabling (Anusha) - SKL+ watermark/ddb programming improvements (Ville) - Pixel format fixes (Ville) - Selftest updates (Chris, Tvrtko) - GT and engine workaround improvements (Tvrtko) BR, Jani. The following changes since commit b4bf44d2dcbd6c35d9651bc6286e4940b8b3df95: drm/i915: Update DRIVER_DATE to 20181122 (2018-11-22 16:49:47 +0200) are available in the git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2018-12-04 for you to fetch changes up to 4377d4e0d3d511986033ba7b4182d5a80b7f9ea2: drm/i915: Update DRIVER_DATE to 20181204 (2018-12-04 19:26:17 +0200) Final drm/i915 changes for v4.21: - ICL DSI video mode enabling (Madhav, Vandita, Jani, Imre) - eDP sink count fix (José) - PSR fixes (José) - DRM DP helper and i915 DSC enabling (Manasi, Gaurav, Anusha) - DP FEC enabling (Anusha) - SKL+ watermark/ddb programming improvements (Ville) - Pixel format fixes (Ville) - Selftest updates (Chris, Tvrtko) - GT and engine workaround improvements (Tvrtko) Anusha Srivatsa (4): i915/dp/fec: Add fec_enable to the crtc state. drm/i915/fec: Set FEC_READY in FEC_CONFIGURATION i915/dp/fec: Configure the Forward Error Correction bits. drm/i915/fec: Disable FEC state. Chris Wilson (12): drm/i915: Cache the error string drm/i915/ringbuffer: 2-step restart drm/i915: Skip engine serialisation for no-op seqno reset drm/i915: Mark up early pre-production Kabylakes drm/i915: Fixup stub definitions for intel_opregion_suspend|resume drm/i915/ringbuffer: Clear semaphore sync registers on ring init drm/i915/selftests: Terminate hangcheck sanitycheck forcibly drm/i915/breadcrumbs: Reduce missed-breadcrumb false positive rate drm/i915/vgpu: Disallow loading on old vGPU hosts drm/i915/dp: Fix inconsistent indenting drm/i915: Complete the fences as they are cancelled due to wedging drm/i915: Allocate a common scratch page Gaurav K Singh (3): drm/i915/dsc: Define & Compute VESA DSC params drm/i915/dsc: Compute Rate Control parameters for DSC drm/i915/dp: Enable/Disable DSC in DP Sink Imre Deak (1): drm/i915/icl: Sanitize DDI port clock gating for DSI ports Jani Nikula (7): drm/i915/icl: push pll to port mapping/unmapping to ddi encoder hooks drm/i915/icl: add dummy DSI GPIO element execution function drm/i915/icl: add pll mapping for DSI sysfs: constify sysfs create/remove files harder drm/i915/sysfs: make attrs arrays const drm/i915/icl: fix transcoder state readout drm/i915: Update DRIVER_DATE to 20181204 Jonathan Gray (1): drm/i915: change i915_sw_fence license to MIT José Roberto de Souza (9): drm/i915: Avoid a full port detection in the first eDP short pulse drm/i915: Check PSR errors instead of retrain while PSR is enabled drm/i915: Do not enable PSR in the next modeset after a error drm/i915: Disable PSR when a PSR aux error happen drm/i915: Keep PSR disabled after a driver reload after a PSR error drm/i915/hsw: Drop the stereo 3D enabled check in psr_compute_config() drm/i915/psr: Get pipe id following atomic guidelines drm/i915: Add HAS_DISPLAY() and use it drm/i915: Move display device info capabilities to its own struct Lyude Paul (1): drm/i915: Synchronize hpd work in i915_hpd_storm_ctl_show() Madhav Chauhan (14): drm/i915/icl: Calculate DPLL params for DSI drm/i915/icl: Allocate DSI encoder/connector drm/i915/icl: Fill DSI ports info drm/i915/icl: Allocate DSI hosts and imlement host transfer drm/i915/icl: Get HW state for DSI encoder drm/i915/icl: Add DSI encoder compute config hook drm/i915/icl: Configure DSI Dual link mode drm/i915/icl: Consider DSI for getting transcoder state drm/i915/icl: Get pipe timings for DSI drm/i915/icl: Define missing bitfield for shortplug reg drm/i915/icl: Define Panel power ctrl register drm/i915/icl: Define display GPIO pins for DSI drm/i915/icl: Gate clocks for DSI drm/i915/icl: Ungate DSI clocks Manasi Navare (16): drm/dsc: Modify DRM helper to return complete DSC color depth capabilities drm/dsc: Define Display Stream Compression PPS infoframe drm/dsc: Define VESA Display Stream Compression Capabilities drm/dsc: Add helpers for DSC picture parameter set infoframes drm/dsc: Define the DSC 1.1 and 1.2 Line Buffer depth constants drm/i915/dp: Add DSC params and DSC co
Re: [RFC v3 AFBC 12/12] drm/arm/malidp: Added support for AFBC modifiers for all layers except DE_SMART
On Mon, Dec 03, 2018 at 11:32:06AM +, Ayan Halder wrote:
> The list of modifiers to be supported for each plane has been dynamically
> generated
> from 'malidp_format_modifiers[]' and 'malidp_hw_regmap->features'.
>
> Changes from v1:-
> 1. Replaced DRM_ERROR() with DRM_DEBUG_KMS() in malidp_format_mod_supported()
> to report unsupported modifiers.
>
> Changes from v2:-
> 1. Removed malidp_format_mod_supported() from the current patch. This has
> been added
> in "PATCH 7/12"
> 2. Dynamically generate the list of modifiers (to be supported for each
> plane) from
> 'malidp_format_modifiers' and features.
>
> Signed-off-by: Ayan Kumar halder
Reviewed-by: Liviu Dudau
Best regards,
Liviu
> ---
> drivers/gpu/drm/arm/malidp_drv.c| 1 +
> drivers/gpu/drm/arm/malidp_planes.c | 28 ++--
> 2 files changed, 27 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c
> b/drivers/gpu/drm/arm/malidp_drv.c
> index b2b97db..be45703 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -388,6 +388,7 @@ static int malidp_init(struct drm_device *drm)
> drm->mode_config.max_height = hwdev->max_line_size;
> drm->mode_config.funcs = _mode_config_funcs;
> drm->mode_config.helper_private = _mode_config_helpers;
> + drm->mode_config.allow_fb_modifiers = true;
>
> ret = malidp_crtc_init(drm);
> if (ret)
> diff --git a/drivers/gpu/drm/arm/malidp_planes.c
> b/drivers/gpu/drm/arm/malidp_planes.c
> index eec0442..01037d0 100644
> --- a/drivers/gpu/drm/arm/malidp_planes.c
> +++ b/drivers/gpu/drm/arm/malidp_planes.c
> @@ -934,6 +934,25 @@ int malidp_de_planes_init(struct drm_device *drm)
> BIT(DRM_MODE_BLEND_COVERAGE);
> u32 *formats;
> int ret, i, j, n;
> + u64 supported_modifiers[MODIFIERS_COUNT_MAX];
> + const u64 *modifiers;
> +
> + modifiers = malidp_format_modifiers;
> +
> + if (!(map->features & MALIDP_DEVICE_AFBC_SUPPORT_SPLIT)) {
> + /*
> + * Since our hardware does not support SPLIT, so build the list
> of
> + * supported modifiers excluding SPLIT ones.
> + */
> + while (*modifiers != DRM_FORMAT_MOD_INVALID) {
> + if (!(*modifiers & AFBC_SPLIT))
> + supported_modifiers[j++] = *modifiers;
> +
> + modifiers++;
> + }
> + supported_modifiers[j++] = DRM_FORMAT_MOD_INVALID;
> + modifiers = supported_modifiers;
> + }
>
> formats = kcalloc(map->n_pixel_formats, sizeof(*formats), GFP_KERNEL);
> if (!formats) {
> @@ -958,9 +977,14 @@ int malidp_de_planes_init(struct drm_device *drm)
>
> plane_type = (i == 0) ? DRM_PLANE_TYPE_PRIMARY :
> DRM_PLANE_TYPE_OVERLAY;
> +
> + /*
> + * All the layers except smart layer supports AFBC modifiers.
> + */
> ret = drm_universal_plane_init(drm, >base, crtcs,
> -_de_plane_funcs, formats,
> -n, NULL, plane_type, NULL);
> + _de_plane_funcs, formats, n,
> + (id == DE_SMART) ? NULL : modifiers,
> plane_type, NULL);
> +
> if (ret < 0)
> goto cleanup;
>
> --
> 2.7.4
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC AFBC 11/12] drm/arm/malidp:- Disregard the pitch alignment constraint for AFBC framebuffer.
On Mon, Dec 03, 2018 at 11:32:05AM +, Ayan Halder wrote:
> Considering the fact that some of the AFBC specific pixel formats are
> expressed
> in bits per pixel (ie bpp which is not byte aligned), the pitch (ie width *
> bpp)
> is not guaranteed to be aligned to burst size (ie 8 or 16 bytes).
> For example, DRM_FORMAT_VUY101010 is 30 bits per pixel. For a framebuffer of
> width 32 pixels, the pitch will be 120 bytes which is not aligned to burst
> size
> (ie 16 bytes) for DP650.
>
> Signed-off-by: Ayan Kumar halder
Acked-by: Liviu Dudau
> ---
> drivers/gpu/drm/arm/malidp_planes.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_planes.c
> b/drivers/gpu/drm/arm/malidp_planes.c
> index d0a00ee..eec0442 100644
> --- a/drivers/gpu/drm/arm/malidp_planes.c
> +++ b/drivers/gpu/drm/arm/malidp_planes.c
> @@ -529,8 +529,8 @@ static int malidp_de_plane_check(struct drm_plane *plane,
> for (i = 0; i < ms->n_planes; i++) {
> u8 alignment = malidp_hw_get_pitch_align(mp->hwdev, rotated);
>
> - if ((fb->pitches[i] * drm_format_info_block_height(fb->format,
> i))
> - & (alignment - 1)) {
> + if (((fb->pitches[i] * drm_format_info_block_height(fb->format,
> i))
> + & (alignment - 1)) && !(fb->modifier)) {
> DRM_DEBUG_KMS("Invalid pitch %u for plane %d\n",
> fb->pitches[i], i);
> return -EINVAL;
> --
> 2.7.4
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC AFBC 10/12] drm/arm/malidp:- Use the newly introduced malidp_format_get_bpp() instead of relying on cpp for calculating framebuffer size
On Mon, Dec 03, 2018 at 11:32:04AM +, Ayan Halder wrote:
> Formats like DRM_FORMAT_VUY101010, DRM_FORMAT_YUV420_8BIT and
> DRM_FORMAT_YUV420_10BIT are expressed in bits per pixel as they have a non
> integer value of cpp (thus denoted as '0' in drm_format_info[]). Therefore,
> the calculation of AFBC framebuffer size needs to use malidp_format_get_bpp().
>
> Signed-off-by: Ayan Kumar halder
Reviewed-by: Liviu Dudau
Best regards,
Liviu
> ---
> drivers/gpu/drm/arm/malidp_drv.c | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c
> b/drivers/gpu/drm/arm/malidp_drv.c
> index 2f0b553..b2b97db 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -297,6 +297,7 @@ malidp_verify_afbc_framebuffer_size(struct drm_device
> *dev,
> struct drm_gem_object *objs = NULL;
> u32 afbc_superblock_size = 0, afbc_superblock_height = 0;
> u32 afbc_superblock_width = 0, afbc_size = 0;
> + int bpp = 0;
>
> switch (mode_cmd->modifier[0] & AFBC_SIZE_MASK) {
> case AFBC_SIZE_16X16:
> @@ -313,15 +314,17 @@ malidp_verify_afbc_framebuffer_size(struct drm_device
> *dev,
> n_superblocks = (mode_cmd->width / afbc_superblock_width) *
> (mode_cmd->height / afbc_superblock_height);
>
> - afbc_superblock_size = info->cpp[0] * afbc_superblock_width *
> - afbc_superblock_height;
> + bpp = malidp_format_get_bpp(info->format);
> +
> + afbc_superblock_size = (bpp * afbc_superblock_width *
> afbc_superblock_height) / BITS_PER_BYTE;
>
> afbc_size = ALIGN(n_superblocks * AFBC_HEADER_SIZE,
> AFBC_SUPERBLK_ALIGNMENT);
> afbc_size += n_superblocks * ALIGN(afbc_superblock_size,
> AFBC_SUPERBLK_ALIGNMENT);
>
> - if (mode_cmd->width * info->cpp[0] != mode_cmd->pitches[0]) {
> - DRM_DEBUG_KMS("Invalid value of pitch (=%u) should be same as
> width (=%u) * cpp (=%u)\n",
> - mode_cmd->pitches[0], mode_cmd->width,
> info->cpp[0]);
> + if ((mode_cmd->width * bpp) != (mode_cmd->pitches[0] * BITS_PER_BYTE)) {
> + DRM_DEBUG_KMS("Invalid value of (pitch * BITS_PER_BYTE) (=%u) "
> + "should be same as width (=%u) * bpp (=%u)\n",
> + (mode_cmd->pitches[0] * BITS_PER_BYTE),
> mode_cmd->width, bpp);
> return false;
> }
>
> --
> 2.7.4
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC AFBC 09/12] drm/arm/malidp:- Writeback framebuffer does not support any modifiers
On Mon, Dec 03, 2018 at 11:32:03AM +, Ayan Halder wrote:
> In malidp, the writeback pipeline does not support writing crtc output
> to a framebuffer with modifiers ie the memory writeback content is
> devoid of any compression or tiling, etc.
> So we have added a commit check in memory writeback encoder helper function
> to validate if the framebuffer has any modifier and if so, return EINVAL.
>
> Signed-off-by: Ayan Kumar halder
Acked-by: Liviu Dudau
> ---
> drivers/gpu/drm/arm/malidp_mw.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c
> index 0484744..90c964a 100644
> --- a/drivers/gpu/drm/arm/malidp_mw.c
> +++ b/drivers/gpu/drm/arm/malidp_mw.c
> @@ -141,6 +141,11 @@ malidp_mw_encoder_atomic_check(struct drm_encoder
> *encoder,
> return -EINVAL;
> }
>
> + if (fb->modifier) {
> + DRM_DEBUG_KMS("Writeback framebuffer does not support
> modifiers\n");
> + return -EINVAL;
> + }
> +
> mw_state->format =
> malidp_hw_get_format_id(>dev->hw->map, SE_MEMWRITE,
> fb->format->format, !!fb->modifier);
> --
> 2.7.4
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC AFBC 08/12] drm/arm/malidp: Specified the rotation memory requirements for AFBC YUV formats
On Mon, Dec 03, 2018 at 11:32:02AM +, Ayan Halder wrote:
> The newly supported AFBC YUV formats have the following rotation memory
> constraints (in DP550/DP650).
> 1. DRM_FORMAT_VUY888/DRM_FORMAT_VUY101010 :- It can rotate upto 8
> horizontal lines in the AFBC output buffer.
> 2. DRM_FORMAT_YUV420_8BIT :- It can rotate upto 16 horizontal lines
> in the AFBC output buffer.
>
> Also some of the pixel formats are specified in bits per pixel (rather
> than bytes per pixel), so the calculation needs to take note of this.
>
> Besides there are some difference between DP550 and DP650 and these are
> as follows:-
> 1. DRM_FORMAT_X0L2 (in uncompressed format) does not support rotation in
> DP550.
> For DP650, it can rotate upto 16 horizontal lines in the AFBC output buffer,
> whereas in DP550 (with AFBC), it can rotate upto 8 horizontal lines.
> 2. DRM_FORMAT_YUV420_10BIT :- It can rotate upto 8 horizontal lines in
> dp550 and 16 horizontal lines in DP650.
>
> Signed-off-by: Ayan Kumar halder
Reviewed-by: Liviu Dudau
Best regards,
Liviu
> ---
> drivers/gpu/drm/arm/malidp_hw.c | 101
>
> drivers/gpu/drm/arm/malidp_hw.h | 5 +-
> drivers/gpu/drm/arm/malidp_planes.c | 3 +-
> 3 files changed, 98 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
> index 4a774be..d9866a8 100644
> --- a/drivers/gpu/drm/arm/malidp_hw.c
> +++ b/drivers/gpu/drm/arm/malidp_hw.c
> @@ -375,14 +375,39 @@ static void malidp500_modeset(struct malidp_hw_device
> *hwdev, struct videomode *
> malidp_hw_clearbits(hwdev, MALIDP_DISP_FUNC_ILACED,
> MALIDP_DE_DISPLAY_FUNC);
> }
>
> -static int malidp500_rotmem_required(struct malidp_hw_device *hwdev, u16 w,
> u16 h, u32 fmt)
> +int malidp_format_get_bpp(u32 fmt)
> +{
> + int bpp = drm_format_plane_cpp(fmt, 0) * 8;
> +
> + if (bpp == 0) {
> + switch (fmt) {
> + case DRM_FORMAT_VUY101010:
> + bpp = 30;
> + case DRM_FORMAT_YUV420_10BIT:
> + bpp = 15;
> + break;
> + case DRM_FORMAT_YUV420_8BIT:
> + bpp = 12;
> + break;
> + default:
> + bpp = 0;
> + }
> + }
> +
> + return bpp;
> +}
> +
> +static int malidp500_rotmem_required(struct malidp_hw_device *hwdev, u16 w,
> + u16 h, u32 fmt, bool has_modifier)
> {
> /*
>* Each layer needs enough rotation memory to fit 8 lines
>* worth of pixel data. Required size is then:
>*size = rotated_width * (bpp / 8) * 8;
>*/
> - return w * drm_format_plane_cpp(fmt, 0) * 8;
> + int bpp = malidp_format_get_bpp(fmt);
> +
> + return w * bpp;
> }
>
> static void malidp500_se_write_pp_coefftab(struct malidp_hw_device *hwdev,
> @@ -660,9 +685,9 @@ static void malidp550_modeset(struct malidp_hw_device
> *hwdev, struct videomode *
> malidp_hw_clearbits(hwdev, MALIDP_DISP_FUNC_ILACED,
> MALIDP_DE_DISPLAY_FUNC);
> }
>
> -static int malidp550_rotmem_required(struct malidp_hw_device *hwdev, u16 w,
> u16 h, u32 fmt)
> +static int malidpx50_get_bytes_per_column(u32 fmt)
> {
> - u32 bytes_per_col;
> + u32 bytes_per_column;
>
> switch (fmt) {
> /* 8 lines at 4 bytes per pixel */
> @@ -688,19 +713,77 @@ static int malidp550_rotmem_required(struct
> malidp_hw_device *hwdev, u16 w, u16
> case DRM_FORMAT_UYVY:
> case DRM_FORMAT_YUYV:
> case DRM_FORMAT_X0L0:
> - case DRM_FORMAT_X0L2:
> - bytes_per_col = 32;
> + bytes_per_column = 32;
> break;
> /* 16 lines at 1.5 bytes per pixel */
> case DRM_FORMAT_NV12:
> case DRM_FORMAT_YUV420:
> - bytes_per_col = 24;
> + /* 8 lines at 3 bytes per pixel */
> + case DRM_FORMAT_VUY888:
> + /* 16 lines at 12 bits per pixel */
> + case DRM_FORMAT_YUV420_8BIT:
> + /* 8 lines at 3 bytes per pixel */
> + case DRM_FORMAT_P010:
> + bytes_per_column = 24;
> + break;
> + /* 8 lines at 30 bits per pixel */
> + case DRM_FORMAT_VUY101010:
> + /* 16 lines at 15 bits per pixel */
> + case DRM_FORMAT_YUV420_10BIT:
> + bytes_per_column = 30;
> break;
> default:
> return -EINVAL;
> }
>
> - return w * bytes_per_col;
> + return bytes_per_column;
> +}
> +
> +static int malidp550_rotmem_required(struct malidp_hw_device *hwdev, u16 w,
> + u16 h, u32 fmt, bool has_modifier)
> +{
> + int bytes_per_column = 0;
> +
> + switch (fmt) {
> + /* 8 lines at 15 bits per pixel */
> + case DRM_FORMAT_YUV420_10BIT:
> + bytes_per_column = 15;
> + break;
> + /* Uncompressed YUV 420 10 bit single plane cannot be rotated */
> +
Re: [RFC AFBC 07/12] drm/arm/malidp: Define the constraints on each supported drm_fourcc format for the AFBC modifiers.
On Mon, Dec 03, 2018 at 11:32:01AM +, Ayan Halder wrote:
> The constraints are as follows (for Mali-DP 500, 550, 650) :-
>
> 1. AFBC is not supported for the formats defined in
> malidp_hw_format_is_linear_only()
>
> 2. Some of the formats are supported only with AFBC modifiers. Thus we have
> introduced a new function 'malidp_hw_format_is_afbc_only()' which verifies
> the same.
>
> 3. AFBC_FORMAT_MOD_YTR needs to be provided for any RGB format.
>
> 4. Formats <= 16bpp cannot support AFBC_FORMAT_MOD_SPLIT.
>
> 5. CBR should not be set for non-subsampled formats.
>
> 6. SMART layer does not support framebuffer with AFBC modifiers.
> Return -EINVAL for such a scenario.
>
> 7. AFBC_FORMAT_MOD_YTR is not supported for any YUV formats.
>
> 8. Formats which are subsampled cannot support AFBC_FORMAT_MOD_SPLIT. However
> in
> DP550, YUV_420_10BIT is supported with AFBC_FORMAT_MOD_SPLIT. This feature has
> been identified with MALIDP_DEVICE_AFBC_YUV_420_10_SUPPORT_SPLIT.
>
> 9. In DP550 and DP650, for YUYV, the hardware supports different format-ids to
> be used with and without AFBC modifier. We have used the feature
> 'MALIDP_DEVICE_AFBC_YUYV_USE_422_P2' to identify this characteristic.
>
> Signed-off-by: Ayan Kumar halder
> ---
> drivers/gpu/drm/arm/malidp_drv.c| 23 +--
> drivers/gpu/drm/arm/malidp_drv.h| 6 ++
> drivers/gpu/drm/arm/malidp_hw.c | 71 +++--
> drivers/gpu/drm/arm/malidp_hw.h | 5 +-
> drivers/gpu/drm/arm/malidp_mw.c | 2 +-
> drivers/gpu/drm/arm/malidp_planes.c | 124
> +++-
> 6 files changed, 199 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c
> b/drivers/gpu/drm/arm/malidp_drv.c
> index b8db92f..2f0b553 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -264,29 +264,8 @@ static bool
> malidp_verify_afbc_framebuffer_caps(struct drm_device *dev,
> const struct drm_mode_fb_cmd2 *mode_cmd)
> {
> - const struct drm_format_info *info;
> -
> - if ((mode_cmd->modifier[0] >> 56) != DRM_FORMAT_MOD_VENDOR_ARM) {
> - DRM_DEBUG_KMS("Unknown modifier (not Arm)\n");
> + if (malidp_format_mod_supported(dev, mode_cmd->pixel_format,
> mode_cmd->modifier[0]) == false)
> return false;
> - }
> -
> - if (mode_cmd->modifier[0] &
> - ~DRM_FORMAT_MOD_ARM_AFBC(AFBC_MOD_VALID_BITS)) {
> - DRM_DEBUG_KMS("Unsupported modifiers\n");
> - return false;
> - }
> -
> - info = drm_get_format_info(dev, mode_cmd);
> - if (!info) {
> - DRM_DEBUG_KMS("Unable to get the format information\n");
> - return false;
> - }
> -
> - if (info->num_planes != 1) {
> - DRM_DEBUG_KMS("AFBC buffers expect one plane\n");
> - return false;
> - }
>
> if (mode_cmd->offsets[0] != 0) {
> DRM_DEBUG_KMS("AFBC buffers' plane offset should be 0\n");
> diff --git a/drivers/gpu/drm/arm/malidp_drv.h
> b/drivers/gpu/drm/arm/malidp_drv.h
> index b76c86f..019a682 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.h
> +++ b/drivers/gpu/drm/arm/malidp_drv.h
> @@ -90,6 +90,12 @@ struct malidp_crtc_state {
> int malidp_de_planes_init(struct drm_device *drm);
> int malidp_crtc_init(struct drm_device *drm);
>
> +bool malidp_hw_format_is_linear_only(u32 format);
> +bool malidp_hw_format_is_afbc_only(u32 format);
> +
> +bool malidp_format_mod_supported(struct drm_device *drm,
> + u32 format, u64 modifier);
> +
> #ifdef CONFIG_DEBUG_FS
> void malidp_error(struct malidp_drm *malidp,
> struct malidp_error_stats *error_stats, u32 status,
> diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
> index 25ac5890..4a774be 100644
> --- a/drivers/gpu/drm/arm/malidp_hw.c
> +++ b/drivers/gpu/drm/arm/malidp_hw.c
> @@ -60,6 +60,8 @@ static const struct malidp_format_id malidp500_de_formats[]
> = {
> #define MALIDP_ID(__group, __format) \
> __group) & 0x7) << 3) | ((__format) & 0x7))
>
> +#define AFBC_YUV_422_FORMAT_ID MALIDP_ID(5, 1)
> +
> #define MALIDP_COMMON_FORMATS \
> /*fourcc, layers supporting the format, internal id */ \
> { DRM_FORMAT_ARGB2101010, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2 |
> SE_MEMWRITE, MALIDP_ID(0, 0) }, \
> @@ -887,7 +889,10 @@ const struct malidp_hw malidp_device[MALIDP_MAX_DEVICES]
> = {
> .se_base = MALIDP550_SE_BASE,
> .dc_base = MALIDP550_DC_BASE,
> .out_depth_base = MALIDP550_DE_OUTPUT_DEPTH,
> - .features = MALIDP_REGMAP_HAS_CLEARIRQ |
> MALIDP_DEVICE_AFBC_SUPPORT_SPLIT | AFBC_SUPPORT_SPLIT_WITH_YUV_420_10,
> + .features = MALIDP_REGMAP_HAS_CLEARIRQ |
> + MALIDP_DEVICE_AFBC_SUPPORT_SPLIT |
> +
[Bug 105113] [hawaii, radeonsi, clover] Running Piglit cl/program/execute/{, tail-}calls{, -struct, -workitem-id}.cl cause GPU VM error and ring stalled GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=105113 --- Comment #11 from Jan Vesely --- (In reply to Maciej S. Szmigiero from comment #10) > (In reply to Jan Vesely from comment #9) > > (In reply to Maciej S. Szmigiero from comment #8) > > > Aren't program@execute@calls-struct and program@execute@tail-calls tests > > > from comment 4 examples of this behavior? > > > These seem to run but return wrong results, or am I not parsing the piglit > > > test results correctly? > > > > This is more of a piglit problem. piglit uses a combination of enqueue and > > clFinish. However, the error happens on kernel launch. thus; > > 1.) clEnqueueNDRangeKernel -- success > > 2.) The driver tries to launch the kernel and fails on relocations > > 3.) application(piglit) calls clFinish > > > > depending on the order of 2. and 3. clFinish can either see an empty queue > > and succeed or try to wait for kernel execution and fail. > > > > The following series should address that: > > https://patchwork.freedesktop.org/series/52857/ > > Thanks for the detailed explanation and the patches. > > I can confirm that with them applied program@execute@calls-struct and > program@execute@tail-calls exit with > CL_EXEC_STATUS_ERROR_FOR_EVENTS_IN_WAIT_LIST, so I guess they work > (or rather, fail) as expected. > > Feel free to add > "Tested-by: Maciej S. Szmigiero " tag if you > would > like. Thanks. I pushed the piglit patches. I'll keep this bug open until mesa properly supports relocations. -- 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 4/5] arm64: dts: renesas: r8a77995: draak: Add backlight
On Sun, Nov 25, 2018 at 3:40 PM Laurent Pinchart
wrote:
> Add the backlight device for the LVDS1 output, in preparation for panel
> support.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/8] drm/msm/dsi: 28nm 8960 PHY: Get ref clock from the DT
On Tue, Dec 04, 2018 at 08:44:00AM -0800, Stephen Boyd wrote:
> Quoting Matthias Kaehlcke (2018-11-30 16:52:48)
> > Get the ref clock of the PHY from the device tree instead of
> > hardcoding its name and rate. Use default values if the ref
> > clock is not specified.
> >
> > Signed-off-by: Matthias Kaehlcke
> > ---
> > Changes in v3:
> > - use default name and rate if the ref clock is not specified
> > in the DT
> > - store vco_ref_clk_name instead of vco_ref_clk
> > - fixed check for EPROBE_DEFER
> > - renamed VCO_REF_CLK_RATE to VCO_REF_CLK_DEFAULT_RATE
> >
> > Changes in v2:
> > - patch added to the series
> > ---
> > .../gpu/drm/msm/dsi/pll/dsi_pll_28nm_8960.c | 28 +++
> > 1 file changed, 23 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm_8960.c
> > b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm_8960.c
> > index 49008451085b8..3af678d3317f6 100644
> > --- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm_8960.c
> > +++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm_8960.c
> > @@ -47,9 +47,9 @@
> >
> > #define NUM_PROVIDED_CLKS 2
> >
> > -#define VCO_REF_CLK_RATE 2700
> > -#define VCO_MIN_RATE 6
> > -#define VCO_MAX_RATE 12
> > +#define VCO_REF_CLK_DEFAULT_RATE 2700
> > +#define VCO_MIN_RATE 6
> > +#define VCO_MAX_RATE 12
> >
> > #define DSI_BYTE_PLL_CLK 0
> > #define DSI_PIXEL_PLL_CLK 1
> > @@ -75,6 +75,8 @@ struct dsi_pll_28nm {
> > struct platform_device *pdev;
> > void __iomem *mmio;
> >
> > + const char *vco_ref_clk_name;
>
> Can this be passed around during clk registration so we don't have to
> store it away in the structure?
makes sense, will do
> > +
> > /* custom byte clock divider */
> > struct clk_bytediv *bytediv;
> >
> > @@ -125,7 +127,10 @@ static int dsi_pll_28nm_clk_set_rate(struct clk_hw
> > *hw, unsigned long rate,
> > DBG("rate=%lu, parent's=%lu", rate, parent_rate);
> >
> > temp = rate / 10;
> > - val = VCO_REF_CLK_RATE / 10;
> > + if (parent_rate)
> > + val = parent_rate / 10;
> > + else
> > + val = VCO_REF_CLK_DEFAULT_RATE / 10;
>
> Is the clk not properly hooked up to a parent sometimes so parent_rate
> is 0? That sounds odd given the fact that it used to be 'pxo' and that
> has always existed on the system as 27 MHz. So I'd remove this and just
> use parent_rate all the time.
I wondered about this, but since I don't have hardware for testing I
kept the previous hardcoded rate. If we know for sure that 'pxo'
always exists it should indeed be fine to use the parent rate.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: rcar-du: dw-hdmi: Reject modes with a too high clock frequency
Hi Laurent,
On Tue, Dec 4, 2018 at 5:36 PM Laurent Pinchart
wrote:
> Implement a .mode_valid() handler in the R-Car glue layer to reject
> modes with an unsupported clock frequency.
>
> Signed-off-by: Laurent Pinchart
Thanks for your patch!
> --- a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> @@ -35,6 +35,20 @@ static const struct rcar_hdmi_phy_params
> rcar_hdmi_phy_params[] = {
> { ~0UL, 0x, 0x, 0x },
> };
>
> +static enum drm_mode_status
> +rcar_hdmi_mode_valid(struct drm_connector *connector,
> +const struct drm_display_mode *mode)
> +{
> + /*
> +* The maximum supported clock frequency is 297 MHz, as shown in the
> PHY
> +* parameters table.
> +*/
> + if (mode->clock > 297000)
> + return MODE_CLOCK_HIGH;
Perhaps you need a check for the lower limit (25 MHz), too?
> +
> + return MODE_OK;
> +}
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 8/8] ARM: dts: qcom-apq8064: Set 'xo_board' as ref clock of the DSI PHY
On Tue, Dec 04, 2018 at 08:48:22AM -0800, Stephen Boyd wrote: > Quoting Matthias Kaehlcke (2018-11-30 16:52:54) > > Add 'xo_board' as ref clock for the DSI PHY, it was previously > > hardcoded in the PLL 'driver' for the 28nm 8960 PHY. > > Why is driver in quotes? It's not really a full fledged driver, but part of the 28nm 8960 PHY driver. > > > > Signed-off-by: Matthias Kaehlcke > > Reviewed-by: Stephen Boyd Thanks for the review! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/8] dt-bindings: msm/dsi: Add ref clock for PHYs
Hi, On Fri, Nov 30, 2018 at 4:53 PM Matthias Kaehlcke wrote: > > Allow the PHY drivers to get the ref clock from the DT. > > Signed-off-by: Matthias Kaehlcke > --- > Changes in V3: > - added note that the ref clock is only required for new DTS > files/entries > > Changes in v2: > - add the ref clock for all PHYs, not only the 10nm one > - updated commit message > --- > Documentation/devicetree/bindings/display/msm/dsi.txt | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Douglas Anderson ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC AFBC 06/12] drm/arm/malidp:- Added support for new YUV formats for DP500, DP550 and DP650
On Mon, Dec 03, 2018 at 11:32:00AM +, Ayan Halder wrote:
> We have added some new formats to be supported on DP500/DP550/DP650.
Make a bit more descriptive commit message here, please!
>
> Signed-off-by: Ayan Kumar Halder
>
> Depends on :- https://patchwork.kernel.org/patch/10460063/
Reviewed-by: Liviu Dudau
Best regards,
Liviu
> ---
> drivers/gpu/drm/arm/malidp_hw.c | 22 +-
> 1 file changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
> index 55d379b..25ac5890 100644
> --- a/drivers/gpu/drm/arm/malidp_hw.c
> +++ b/drivers/gpu/drm/arm/malidp_hw.c
> @@ -49,6 +49,12 @@ static const struct malidp_format_id
> malidp500_de_formats[] = {
> { DRM_FORMAT_YUYV, DE_VIDEO1, 13 },
> { DRM_FORMAT_NV12, DE_VIDEO1 | SE_MEMWRITE, 14 },
> { DRM_FORMAT_YUV420, DE_VIDEO1, 15 },
> + { DRM_FORMAT_XYUV, DE_VIDEO1, 16 },
> + /* These are supported with AFBC only */
> + { DRM_FORMAT_YUV420_8BIT, DE_VIDEO1, 14 },
> + { DRM_FORMAT_VUY888, DE_VIDEO1, 16 },
> + { DRM_FORMAT_VUY101010, DE_VIDEO1, 17 },
> + { DRM_FORMAT_YUV420_10BIT, DE_VIDEO1, 18 }
> };
>
> #define MALIDP_ID(__group, __format) \
> @@ -74,11 +80,25 @@ static const struct malidp_format_id
> malidp500_de_formats[] = {
> { DRM_FORMAT_ABGR1555, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2,
> MALIDP_ID(4, 1) }, \
> { DRM_FORMAT_RGB565, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2, MALIDP_ID(4,
> 2) }, \
> { DRM_FORMAT_BGR565, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2, MALIDP_ID(4,
> 3) }, \
> + /* This is only supported with linear modifier */ \
> + { DRM_FORMAT_XYUV, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 0) },\
> + /* This is only supported with AFBC modifier */ \
> + { DRM_FORMAT_VUY888, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 0) }, \
> { DRM_FORMAT_YUYV, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 2) },\
> + /* This is only supported with linear modifier */ \
> { DRM_FORMAT_UYVY, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 3) },\
> { DRM_FORMAT_NV12, DE_VIDEO1 | DE_VIDEO2 | SE_MEMWRITE, MALIDP_ID(5, 6)
> }, \
> + /* This is only supported with AFBC modifier */ \
> + { DRM_FORMAT_YUV420_8BIT, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 6) }, \
> { DRM_FORMAT_YUV420, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 7) }, \
> - { DRM_FORMAT_X0L2, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 6)}
> + /* This is only supported with linear modifier */ \
> + { DRM_FORMAT_XVYU2101010, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 0)}, \
> + /* This is only supported with AFBC modifier */ \
> + { DRM_FORMAT_VUY101010, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 0)}, \
> + { DRM_FORMAT_X0L2, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 6)}, \
> + /* This is only supported with AFBC modifier */ \
> + { DRM_FORMAT_YUV420_10BIT, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 7)}, \
> + { DRM_FORMAT_P010, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 7)}
>
> static const struct malidp_format_id malidp550_de_formats[] = {
> MALIDP_COMMON_FORMATS,
> --
> 2.7.4
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/panel: simple: Add support for VXT VL050-8048NT-C01 panel
Add support for the VXT VL050-8048NT-C01 800x480 panel to the
panel-simple driver.
This panel is used on some boards manufactured by TechNexion, such as
imx7d-pico.
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/panel/panel-simple.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 5fbee83..2e76e95 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2410,6 +2410,30 @@ static const struct panel_desc urt_umsh_8596md_parallel
= {
.bus_format = MEDIA_BUS_FMT_RGB666_1X18,
};
+static const struct drm_display_mode vl050_8048nt_c01_mode = {
+ .clock = 3,
+ .hdisplay = 800,
+ .hsync_start = 800 + 210,
+ .hsync_end = 800 + 210 + 20,
+ .htotal = 800 + 210 + 20 + 46,
+ .vdisplay = 480,
+ .vsync_start = 480 + 22,
+ .vsync_end = 480 + 22 + 10,
+ .vtotal = 480 + 22 + 10 + 23,
+ .vrefresh = 60,
+};
+
+static const struct panel_desc vl050_8048nt_c01 = {
+ .modes = _8048nt_c01_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 120,
+ .height = 76,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+};
+
static const struct drm_display_mode winstar_wf35ltiacd_mode = {
.clock = 6410,
.hdisplay = 320,
@@ -2725,6 +2749,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "urt,umsh-8596md-20t",
.data = _umsh_8596md_parallel,
}, {
+ .compatible = "vxt,vl050-8048nt-c01",
+ .data = _8048nt_c01,
+ }, {
.compatible = "winstar,wf35ltiacd",
.data = _wf35ltiacd,
}, {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] dt-bindings: Add VXT VL050-8048NT-C01 panel bindings
The VXT VL050-8048NT-C01 is a TFT LCD panel with a 800x480 resolution connected via 24 width parallel interface. Signed-off-by: Fabio Estevam --- .../devicetree/bindings/display/panel/vl050_8048nt_c01.txt | 12 1 file changed, 12 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/vl050_8048nt_c01.txt diff --git a/Documentation/devicetree/bindings/display/panel/vl050_8048nt_c01.txt b/Documentation/devicetree/bindings/display/panel/vl050_8048nt_c01.txt new file mode 100644 index 000..b42bf06 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/vl050_8048nt_c01.txt @@ -0,0 +1,12 @@ +VXT 800x480 color TFT LCD panel + +Required properties: +- compatible: should be "vxt,vl050-8048nt-c01" +- power-supply: as specified in the base binding + +Optional properties: +- backlight: as specified in the base binding +- enable-gpios: as specified in the base binding + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] dt-bindings: Add vendor prefix for VXT Ltd
VXT Ltd is a manufacturer of projected capacitive touch panel and display solutions: http://www.vxt.com.tw/ Signed-off-by: Fabio Estevam --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 3bbe3b8..16a2a97 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -426,6 +426,7 @@ vivante Vivante Corporation vocore VoCore Studio voipac Voipac Technologies s.r.o. votVision Optical Technology Co., Ltd. +vxtVXT Ltd wd Western Digital Corp. wetek WeTek Electronics, limited. wexler Wexler -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC AFBC 05/12] drm/arm/malidp:- Define a common list of AFBC format modifiers supported for DP500, DP550 and DP650
On Mon, Dec 03, 2018 at 11:31:59AM +, Ayan Halder wrote:
> We need to define a common list of format modifiers supported by each of the
> Mali
> display processors. The difference between DP500 from DP550/650 is that DP500
> does not support block split mode (ie AFBC_FORMAT_MOD_SPLIT) and DP550
> supports
> YUV420 with split mode. We noted these special cases by defining
> MALIDP_DEVICE_AFBC_SUPPORT_SPLIT
> and AFBC_SUPPORT_SPLIT_WITH_YUV_420_10 for malidp_hw_regmap.features
>
> Also we have defined a set of meaningful macros to shorten the modifier names
>
> Signed-off-by: Ayan Kumar halder
>
> Change-Id: I09fba2032a7474e6ce45af230e0ed18fc1f4c1df
> ---
> drivers/gpu/drm/arm/malidp_drv.c | 8
> drivers/gpu/drm/arm/malidp_hw.c | 30 --
> drivers/gpu/drm/arm/malidp_hw.h | 20 +++-
> 3 files changed, 47 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c
> b/drivers/gpu/drm/arm/malidp_drv.c
> index 505f316..b8db92f 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -293,8 +293,8 @@ malidp_verify_afbc_framebuffer_caps(struct drm_device
> *dev,
> return false;
> }
>
> - switch (mode_cmd->modifier[0] & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK) {
> - case AFBC_FORMAT_MOD_BLOCK_SIZE_16x16:
> + switch (mode_cmd->modifier[0] & AFBC_SIZE_MASK) {
> + case AFBC_SIZE_16X16:
> if ((mode_cmd->width % 16) || (mode_cmd->height % 16)) {
> DRM_DEBUG_KMS("AFBC buffers must be aligned to 16
> pixels\n");
> return false;
> @@ -319,8 +319,8 @@ malidp_verify_afbc_framebuffer_size(struct drm_device
> *dev,
> u32 afbc_superblock_size = 0, afbc_superblock_height = 0;
> u32 afbc_superblock_width = 0, afbc_size = 0;
>
> - switch (mode_cmd->modifier[0] & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK) {
> - case AFBC_FORMAT_MOD_BLOCK_SIZE_16x16:
> + switch (mode_cmd->modifier[0] & AFBC_SIZE_MASK) {
> + case AFBC_SIZE_16X16:
> afbc_superblock_height = 16;
> afbc_superblock_width = 16;
> break;
> diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
> index 87b7b12..55d379b 100644
> --- a/drivers/gpu/drm/arm/malidp_hw.c
> +++ b/drivers/gpu/drm/arm/malidp_hw.c
> @@ -137,6 +137,32 @@ static const struct malidp_layer malidp650_layers[] = {
> ROTATE_NONE, 0 },
> };
>
> +const u64 malidp_format_modifiers[] = {
> + /* All RGB formats (except XRGB, RGBX, XBGR, BGRX) */
> + DRM_FORMAT_MOD_ARM_AFBC(AFBC_SIZE_16X16 | AFBC_YTR | AFBC_SPARSE),
> + DRM_FORMAT_MOD_ARM_AFBC(AFBC_SIZE_16X16 | AFBC_YTR),
> +
> + /* All RGB formats > 16bpp (except XRGB, RGBX, XBGR, BGRX) */
> + DRM_FORMAT_MOD_ARM_AFBC(AFBC_SIZE_16X16 | AFBC_YTR | AFBC_SPARSE |
> AFBC_SPLIT),
> +
> + /* All 8 or 10 bit YUV 444 formats. */
> + /* In DP550, 10 bit YUV 420 format also supported */
> + DRM_FORMAT_MOD_ARM_AFBC(AFBC_SIZE_16X16 | AFBC_SPARSE | AFBC_SPLIT),
> +
> + /* YUV 420, 422 P1 8 bit and YUV 444 8 bit/10 bit formats */
> + DRM_FORMAT_MOD_ARM_AFBC(AFBC_SIZE_16X16 | AFBC_SPARSE),
> + DRM_FORMAT_MOD_ARM_AFBC(AFBC_SIZE_16X16),
> +
> + /* YUV 420, 422 P1 8, 10 bit formats */
> + DRM_FORMAT_MOD_ARM_AFBC(AFBC_SIZE_16X16 | AFBC_CBR | AFBC_SPARSE),
> + DRM_FORMAT_MOD_ARM_AFBC(AFBC_SIZE_16X16 | AFBC_CBR),
> +
> + /* All formats */
> + DRM_FORMAT_MOD_LINEAR,
> +
> + DRM_FORMAT_MOD_INVALID
> +};
> +
> #define SE_N_SCALING_COEFFS 96
> static const u16 dp500_se_scaling_coeffs[][SE_N_SCALING_COEFFS] = {
> [MALIDP_UPSCALING_COEFFS - 1] = {
> @@ -841,7 +867,7 @@ const struct malidp_hw malidp_device[MALIDP_MAX_DEVICES]
> = {
> .se_base = MALIDP550_SE_BASE,
> .dc_base = MALIDP550_DC_BASE,
> .out_depth_base = MALIDP550_DE_OUTPUT_DEPTH,
> - .features = MALIDP_REGMAP_HAS_CLEARIRQ,
> + .features = MALIDP_REGMAP_HAS_CLEARIRQ |
> MALIDP_DEVICE_AFBC_SUPPORT_SPLIT | AFBC_SUPPORT_SPLIT_WITH_YUV_420_10,
> .n_layers = ARRAY_SIZE(malidp550_layers),
> .layers = malidp550_layers,
> .de_irq_map = {
> @@ -887,7 +913,7 @@ const struct malidp_hw malidp_device[MALIDP_MAX_DEVICES]
> = {
> .se_base = MALIDP550_SE_BASE,
> .dc_base = MALIDP550_DC_BASE,
> .out_depth_base = MALIDP550_DE_OUTPUT_DEPTH,
> - .features = MALIDP_REGMAP_HAS_CLEARIRQ,
> + .features = MALIDP_REGMAP_HAS_CLEARIRQ |
> MALIDP_DEVICE_AFBC_SUPPORT_SPLIT,
> .n_layers = ARRAY_SIZE(malidp650_layers),
> .layers = malidp650_layers,
> .de_irq_map = {
> diff --git a/drivers/gpu/drm/arm/malidp_hw.h
[RESEND PATCH v3] drm/msm: Move fence put to where failure occurs
If dma_fence_wait fails to wait for a supplied in-fence in
msm_ioctl_gem_submit, make sure we release that in-fence.
Also remove this dma_fence_put() from the 'out' label.
Signed-off-by: Robert Foss
Reviewed-by: Chris Wilson
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/msm/msm_gem_submit.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
b/drivers/gpu/drm/msm/msm_gem_submit.c
index a90aedd6883a..d5e6665a4c8f 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -411,7 +411,6 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
struct msm_file_private *ctx = file->driver_priv;
struct msm_gem_submit *submit;
struct msm_gpu *gpu = priv->gpu;
- struct dma_fence *in_fence = NULL;
struct sync_file *sync_file = NULL;
struct msm_gpu_submitqueue *queue;
struct msm_ringbuffer *ring;
@@ -444,6 +443,8 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
ring = gpu->rb[queue->prio];
if (args->flags & MSM_SUBMIT_FENCE_FD_IN) {
+ struct dma_fence *in_fence;
+
in_fence = sync_file_get_fence(args->fence_fd);
if (!in_fence)
@@ -453,11 +454,13 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
*data,
* Wait if the fence is from a foreign context, or if the fence
* array contains any fence from a foreign context.
*/
- if (!dma_fence_match_context(in_fence, ring->fctx->context)) {
+ ret = 0;
+ if (!dma_fence_match_context(in_fence, ring->fctx->context))
ret = dma_fence_wait(in_fence, true);
- if (ret)
- return ret;
- }
+
+ dma_fence_put(in_fence);
+ if (ret)
+ return ret;
}
ret = mutex_lock_interruptible(>struct_mutex);
@@ -583,8 +586,6 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
}
out:
- if (in_fence)
- dma_fence_put(in_fence);
submit_cleanup(submit);
if (ret)
msm_gem_submit_free(submit);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] arm64: dts: renesas: r8a77995: draak: Add backlight
Hi Simon,
Could you please consider taking this patch in your tree ? It's independent
from the rest of the series.
On Sunday, 25 November 2018 16:40:30 EET Laurent Pinchart wrote:
> Add the backlight device for the LVDS1 output, in preparation for panel
> support.
>
> Signed-off-by: Laurent Pinchart
> ---
> .../arm64/boot/dts/renesas/r8a77995-draak.dts | 20 +++
> 1 file changed, 20 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts index
> 2405eaad0296..cd067319e6f3 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> @@ -24,6 +24,17 @@
> stdout-path = "serial0:115200n8";
> };
>
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + pwms = < 0 5>;
> +
> + brightness-levels = <256 128 64 16 8 4 0>;
> + default-brightness-level = <6>;
> +
> + power-supply = <_12p0v>;
> + enable-gpios = < 0 GPIO_ACTIVE_HIGH>;
> + };
> +
> composite-in {
> compatible = "composite-video-connector";
>
> @@ -104,6 +115,15 @@
> regulator-always-on;
> };
>
> + reg_12p0v: regulator1 {
> + compatible = "regulator-fixed";
> + regulator-name = "D12.0V";
> + regulator-min-microvolt = <1200>;
> + regulator-max-microvolt = <1200>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> vga {
> compatible = "vga-connector";
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 0/4] ARM: dts: ccimx6ulsbcpro: Add 10" AUO/Goodix LVDS panel accessory kit
On Sun, Nov 04, 2018 at 08:54:26AM +, Shawn Guo wrote: >On Thu, Oct 25, 2018 at 05:09:29PM +0200, Alex Gonzalez wrote: >> Alex Gonzalez (4): >> drm/panel: simple: Add AUO G101EVN010 panel support >> ARM: dts: ccimx6ulsbcpro: Enable AUO G101EVN010 lcdif panel >> ARM: imx_v6_v7_defconfig: Select TOUCHSCREEN_GOODIX >> ARM: dts: ccimx6ulsbcpro: Add support for Goodix touch controller > >It looks good to me. Ping me when the patch #1 gets accepted and I >will apply the test then. > >Shawn Hi Shawn, Patch #1 is already applied to drm-misc-next (thanks to Thierry for fixing it up for me) Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v3 AFBC 04/12] drm/arm/malidp: Set the AFBC register bits if the framebuffer has AFBC modifier
On Mon, Dec 03, 2018 at 11:31:58AM +, Ayan Halder wrote:
> Added the AFBC decoder registers for DP500 , DP550 and DP650.
> These registers control the processing of AFBC buffers. It controls various
> features like AFBC decoder enable, lossless transformation and block split
> as well as setting of the left, right, top and bottom cropping of AFBC buffers
> (in number of pixels).
> All the layers (except DE_SMART) support framebuffers with AFBC modifiers.
> One needs to set the pixel values of the top, left, bottom and right cropping
> for the AFBC framebuffer.
> Cropping an AFBC framebuffer is controlled by the AFBC crop registers.
> In that case, the layer input size registers should be configured with
> framebuffer's dimensions and not with drm_plane_state source width/height
> values (which is used for non AFBC framebuffer to denote cropping).
>
> Changes from v1:
> - Removed the "if (fb->modifier)" check from malidp_de_plane_update()
> and added it in malidp_de_set_plane_afbc(). This will consolidate all the
> AFBC specific register configurations in a single function ie
> malidp_de_set_plane_afbc().
>
> Changes from v2:
> - For AFBC framebuffer, layer input size register should be set to
> framebuffer's
> width and height
>
> Signed-off-by: Ayan Kumar Halder
> ---
> drivers/gpu/drm/arm/malidp_hw.c | 25 +
> drivers/gpu/drm/arm/malidp_hw.h | 2 +
> drivers/gpu/drm/arm/malidp_planes.c | 109
> +++-
> drivers/gpu/drm/arm/malidp_regs.h | 20 +++
> 4 files changed, 130 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
> index b9bed11..87b7b12 100644
> --- a/drivers/gpu/drm/arm/malidp_hw.c
> +++ b/drivers/gpu/drm/arm/malidp_hw.c
> @@ -94,11 +94,12 @@ static const struct malidp_layer malidp500_layers[] = {
>* yuv2rgb matrix offset, mmu control register offset,
> rotation_features
>*/
> { DE_VIDEO1, MALIDP500_DE_LV_BASE, MALIDP500_DE_LV_PTR_BASE,
> - MALIDP_DE_LV_STRIDE0, MALIDP500_LV_YUV2RGB, 0, ROTATE_ANY },
> + MALIDP_DE_LV_STRIDE0, MALIDP500_LV_YUV2RGB, 0, ROTATE_ANY,
> + MALIDP500_DE_LV_AD_CTRL },
> { DE_GRAPHICS1, MALIDP500_DE_LG1_BASE, MALIDP500_DE_LG1_PTR_BASE,
> - MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY },
> + MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY, MALIDP500_DE_LG1_AD_CTRL
> },
> { DE_GRAPHICS2, MALIDP500_DE_LG2_BASE, MALIDP500_DE_LG2_PTR_BASE,
> - MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY },
> + MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY, MALIDP500_DE_LG2_AD_CTRL
> },
> };
>
> static const struct malidp_layer malidp550_layers[] = {
> @@ -106,13 +107,15 @@ static const struct malidp_layer malidp550_layers[] = {
>* yuv2rgb matrix offset, mmu control register offset,
> rotation_features
>*/
> { DE_VIDEO1, MALIDP550_DE_LV1_BASE, MALIDP550_DE_LV1_PTR_BASE,
> - MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB, 0, ROTATE_ANY },
> + MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB, 0, ROTATE_ANY,
> + MALIDP550_DE_LV1_AD_CTRL },
> { DE_GRAPHICS1, MALIDP550_DE_LG_BASE, MALIDP550_DE_LG_PTR_BASE,
> - MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY },
> + MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY, MALIDP550_DE_LG_AD_CTRL
> },
> { DE_VIDEO2, MALIDP550_DE_LV2_BASE, MALIDP550_DE_LV2_PTR_BASE,
> - MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB, 0, ROTATE_ANY },
> + MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB, 0, ROTATE_ANY,
> + MALIDP550_DE_LV2_AD_CTRL },
> { DE_SMART, MALIDP550_DE_LS_BASE, MALIDP550_DE_LS_PTR_BASE,
> - MALIDP550_DE_LS_R1_STRIDE, 0, 0, ROTATE_NONE },
> + MALIDP550_DE_LS_R1_STRIDE, 0, 0, ROTATE_NONE, 0 },
> };
>
> static const struct malidp_layer malidp650_layers[] = {
> @@ -122,16 +125,16 @@ static const struct malidp_layer malidp650_layers[] = {
>*/
> { DE_VIDEO1, MALIDP550_DE_LV1_BASE, MALIDP550_DE_LV1_PTR_BASE,
> MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB,
> - MALIDP650_DE_LV_MMU_CTRL, ROTATE_ANY },
> + MALIDP650_DE_LV_MMU_CTRL, ROTATE_ANY, MALIDP550_DE_LV1_AD_CTRL
> },
> { DE_GRAPHICS1, MALIDP550_DE_LG_BASE, MALIDP550_DE_LG_PTR_BASE,
> MALIDP_DE_LG_STRIDE, 0, MALIDP650_DE_LG_MMU_CTRL,
> - ROTATE_COMPRESSED },
> + ROTATE_COMPRESSED, MALIDP550_DE_LG_AD_CTRL },
> { DE_VIDEO2, MALIDP550_DE_LV2_BASE, MALIDP550_DE_LV2_PTR_BASE,
> MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB,
> - MALIDP650_DE_LV_MMU_CTRL, ROTATE_ANY },
> + MALIDP650_DE_LV_MMU_CTRL, ROTATE_ANY, MALIDP550_DE_LV2_AD_CTRL
> },
> { DE_SMART, MALIDP550_DE_LS_BASE, MALIDP550_DE_LS_PTR_BASE,
> MALIDP550_DE_LS_R1_STRIDE, 0, MALIDP650_DE_LS_MMU_CTRL,
> - ROTATE_NONE },
> +
[Bug 108359] amdgpu-pro rpm packages cyclical dependencies
https://bugs.freedesktop.org/show_bug.cgi?id=108359 --- Comment #1 from Jeremy Newton --- This should have been fixed. Can you retest using a newer version? -- 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 97759] compile error bandwidth_calcs.c : array subscript is above array bounds [-Werror=array-bounds]
https://bugs.freedesktop.org/show_bug.cgi?id=97759 Jeremy Newton changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Jeremy Newton --- Closing, as this is pretty old, and only Ubuntu LTS is supported (e.g. 16.04, 18.04). -- 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: rcar-du: dw-hdmi: Reject modes with a too high clock frequency
Implement a .mode_valid() handler in the R-Car glue layer to reject
modes with an unsupported clock frequency.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 15 +++
1 file changed, 15 insertions(+)
Changes since v1:
- Add a comment to explain where the limit comes from
diff --git a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
index 75490a3e0a2a..603bb340e8cf 100644
--- a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
+++ b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
@@ -35,6 +35,20 @@ static const struct rcar_hdmi_phy_params
rcar_hdmi_phy_params[] = {
{ ~0UL, 0x, 0x, 0x },
};
+static enum drm_mode_status
+rcar_hdmi_mode_valid(struct drm_connector *connector,
+const struct drm_display_mode *mode)
+{
+ /*
+* The maximum supported clock frequency is 297 MHz, as shown in the PHY
+* parameters table.
+*/
+ if (mode->clock > 297000)
+ return MODE_CLOCK_HIGH;
+
+ return MODE_OK;
+}
+
static int rcar_hdmi_phy_configure(struct dw_hdmi *hdmi,
const struct dw_hdmi_plat_data *pdata,
unsigned long mpixelclock)
@@ -59,6 +73,7 @@ static int rcar_hdmi_phy_configure(struct dw_hdmi *hdmi,
}
static const struct dw_hdmi_plat_data rcar_dw_hdmi_plat_data = {
+ .mode_valid = rcar_hdmi_mode_valid,
.configure_phy = rcar_hdmi_phy_configure,
};
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108883] Vulkan support broken in amdgpu-pro-18.40-676022-rhel-6 driver in CentOS 6.10
https://bugs.freedesktop.org/show_bug.cgi?id=108883 --- Comment #1 from Jeremy Newton --- Unfortunately, we don't support Vulkan on RHEL 6. If you can't update the OS, you could try building our Vulkan driver from source. Note that it's not tested on RHEL 6, so it might not work: https://github.com/GPUOpen-Drivers/AMDVLK Elsewise, there is a community supported driver in Mesa, but we cannot provide any support for that. -- 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: [RFC AFBC 02/12] drm: Added a new format DRM_FORMAT_XVYU2101010
On Mon, Dec 03, 2018 at 11:31:56AM +, Ayan Halder wrote:
> We have added a new format ie DRM_FORMAT_XVYU2101010 which is supported
> by mali display driver.
>
> Signed-off-by: Ayan Kumar halder
Reviewed-by: Liviu Dudau
Best regards,
Liviu
> ---
> drivers/gpu/drm/drm_fourcc.c | 1 +
> include/uapi/drm/drm_fourcc.h | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index 6b7a62e..d31e1ae 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -229,6 +229,7 @@ const struct drm_format_info *__drm_format_info(u32
> format)
> { .format = DRM_FORMAT_VUY888, .depth = 0,
> .num_planes = 1, .cpp = { 3, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
> { .format = DRM_FORMAT_Y410,.depth = 0,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true,
> .is_yuv = true },
> { .format = DRM_FORMAT_AYUV,.depth = 0,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true,
> .is_yuv = true },
> + { .format = DRM_FORMAT_XVYU2101010, .depth = 0,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
> { .format = DRM_FORMAT_P010,.depth = 0,
> .num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
> { .format = DRM_FORMAT_P012,.depth = 0,
> .num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
> { .format = DRM_FORMAT_P016,.depth = 0,
> .num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 71b2bc7..75c4b5a 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -153,6 +153,7 @@ extern "C" {
>
> #define DRM_FORMAT_AYUV fourcc_code('A', 'Y', 'U', 'V') /*
> [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
> #define DRM_FORMAT_XYUV fourcc_code('X', 'Y', 'U', 'V') /* [31:0]
> X:Y:Cb:Cr 8:8:8:8 little endian */
> +#define DRM_FORMAT_XVYU2101010 fourcc_code('X', 'V', '3', '0') /*
> [31:0] X:Cr:Y:Cb 2:10:10:10 little endian */
> #define DRM_FORMAT_VUY888fourcc_code('V', 'U', '2', '4') /* [23:0]
> Cr:Cb:Y 8:8:8 little endian */
> #define DRM_FORMAT_Y410 fourcc_code('Y', '4', '1', '0') /*
> [31:0] A:Cr:Y:Cb 2:10:10:10 little endian */
> #define DRM_FORMAT_VUY101010 fourcc_code('V', 'U', '3', '0') /* Y followed
> by U then V, 10:10:10. Non-linear modifier only */
> --
> 2.7.4
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm: dpu: Allocate proper amount for dpu_crtc_state
On Tue, Dec 04, 2018 at 10:51:42AM -0500, Bruce Wang wrote:
> On Mon, Dec 3, 2018 at 2:56 PM Sean Paul wrote:
> >
> > From: Sean Paul
> >
> > Since dpu_crtc subclasses crtc_state, we need a custom .reset hook in
> > order to allocate the right amount of memory to accommodate the
> > additional struct members in dpu_crtc_state. So bring it [partially]
> > back.
> >
> > Relevant KASAN splat:
> > [ 10.82]
> > ==
> > [ 10.344288] BUG: KASAN: slab-out-of-bounds in kmemdup+0x50/0x80
> > [ 10.350390] Read of size 736 at addr ffc0d9f06080 by task frecon/394
> >
> > [ 10.358861] CPU: 6 PID: 394 Comm: frecon Tainted: GW
> > 4.19.4 #121
> > [ 10.366476] Hardware name: Google Cheza (rev2) (DT)
> > [ 10.371514] Call trace:
> > [ 10.374087] dump_backtrace+0x0/0x194
> > [ 10.377878] show_stack+0x20/0x28
> > [ 10.381330] dump_stack+0xa0/0xc8
> > [ 10.384783] print_address_description+0x78/0x2e0
> > [ 10.389639] kasan_report+0x290/0x2d0
> > [ 10.393428] check_memory_region+0x20/0x14c
> > [ 10.397740] __asan_loadN+0x14/0x1c
> > [ 10.401345] kmemdup+0x50/0x80
> > [ 10.404524] dpu_crtc_duplicate_state+0x58/0xa0
> > [ 10.409228] drm_atomic_get_crtc_state+0xac/0x178
> > [ 10.414095] __drm_atomic_helper_set_config+0x54/0x4a4
> > [ 10.419393] drm_atomic_helper_set_config+0x60/0xb4
> > [ 10.424435] drm_mode_setcrtc+0x720/0x760
> > [ 10.428570] drm_ioctl_kernel+0xd8/0x13c
> > [ 10.432617] drm_ioctl+0x380/0x4f4
> > [ 10.436150] drm_compat_ioctl+0x54/0x13c
> > [ 10.440219] __arm64_compat_sys_ioctl+0x1d8/0xef4
> > [ 10.445086] el0_svc_common+0xd8/0x138
> > [ 10.448961] el0_svc_compat_handler+0x58/0x68
> > [ 10.453463] el0_svc_compat+0x8/0x18
> >
> > [ 10.458712] Allocated by task 56:
> > [ 10.462148] kasan_kmalloc.part.4+0x48/0xf4
> > [ 10.466465] kasan_kmalloc+0x8c/0xa0
> > [ 10.470165] kmem_cache_alloc_trace+0x25c/0x27c
> > [ 10.474848] drm_atomic_helper_crtc_reset+0x68/0x98
> > [ 10.479877] drm_mode_config_reset+0xc4/0x19c
> > [ 10.484383] msm_drm_bind+0x814/0x8dc
> > [ 10.488169] try_to_bring_up_master.part.7+0x48/0xac
> > [ 10.493282] component_master_add_with_match+0x158/0x198
> > [ 10.498758] msm_pdev_probe+0x328/0x348
> > [ 10.502736] platform_drv_probe+0x74/0xc8
> > [ 10.506877] really_probe+0x1ac/0x35c
> > [ 10.510659] driver_probe_device+0xd4/0x118
> > [ 10.514975] __device_attach_driver+0xc8/0xf4
> > [ 10.519477] bus_for_each_drv+0xb4/0xe4
> > [ 10.523439] __device_attach+0xd0/0x158
> > [ 10.527394] device_initial_probe+0x24/0x30
> > [ 10.531715] bus_probe_device+0x50/0xe4
> > [ 10.535681] deferred_probe_work_func+0xac/0xdc
> > [ 10.540376] process_one_work+0x3f0/0x6d4
> > [ 10.544521] worker_thread+0x3f4/0x520
> > [ 10.548399] kthread+0x1b4/0x1c8
> > [ 10.551740] ret_from_fork+0x10/0x18
> >
> > [ 10.556986] Freed by task 0:
> > [ 10.559967] (stack is not available)
> >
> > [ 10.565216] The buggy address belongs to the object at ffc0d9f06080
> > which belongs to the cache kmalloc-1024 of size 1024
> > [ 10.578268] The buggy address is located 0 bytes inside of
> > 1024-byte region [ffc0d9f06080, ffc0d9f06480)
> > [ 10.590248] The buggy address belongs to the page:
> > [ 10.595195] page:ffbf0367c000 count:1 mapcount:0
> > mapping:ffc0de40f680 index:0x0 compound_mapcount: 0
> > [ 10.605321] flags: 0x40008100(slab|head)
> > [ 10.610100] raw: 40008100 ffbf0369fa08 ffbf0367f008
> > ffc0de40f680
> > [ 10.618077] raw: 00150015 0001
> >
> > [ 10.626049] page dumped because: kasan: bad access detected
> >
> > [ 10.633341] Memory state around the buggy address:
> > [ 10.638282] ffc0d9f06180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 00 00
> > [ 10.645710] ffc0d9f06200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 00 00
> > [ 10.653139] >ffc0d9f06280: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc
> > fc fc
> > [ 10.660571] ^
> > [ 10.665774] ffc0d9f06300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > fc fc
> > [ 10.673210] ffc0d9f06380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > fc fc
> > [ 10.680639]
> > ==
> >
> > Fixes: a6ba45afda41 ("drm/msm/dpu: Replace dpu_crtc_reset by atomic helper")
> > Cc: Sean Paul
> > Cc: Bruce Wang
> > Cc: Rob Clark
> > Signed-off-by: Sean Paul
>
> Reviewed-by: Bruce Wang
Thanks for the review, this has been pushed to dpu-staging/for-next
Sean
>
> > ---
> > drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 14 +-
> > 1 file changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> >
Re: [PATCH v2 4/9] phy: dphy: Add configuration helpers
On Tue, Dec 04, 2018 at 11:28:37AM +0530, Kishon Vijay Abraham I wrote:
> Hi Maxime,
>
> On 21/11/18 3:03 PM, Maxime Ripard wrote:
> > Hi Sakari,
> >
> > Thanks for your review.
> >
> > On Mon, Nov 19, 2018 at 03:43:57PM +0200, Sakari Ailus wrote:
> >>> +/*
> >>> + * Minimum D-PHY timings based on MIPI D-PHY specification. Derived
> >>> + * from the valid ranges specified in Section 6.9, Table 14, Page 41
> >>> + * of the D-PHY specification (v2.1).
> >>
> >> I assume these values are compliant with the earlier spec releases.
> >
> > I have access to the versions 1.2 and 2.1 of the spec and as far as I
> > can tell, they match here. I can't really say for other releases, but
> > I wouldn't expect any changes (and it can always be adjusted later on
> > if needed).
> >
> >>> + */
> >>> +int phy_mipi_dphy_get_default_config(unsigned long pixel_clock,
> >>
> >> How about using the bus frequency instead of the pixel clock? Chances are
> >> that the caller already has that information, instead of calculating it
> >> here?
> >
> > I went for the pixel clock since it's something that all drivers will
> > have access too without any computation. The bus frequency can be
> > available as well in v4l2, but won't be in DRM, and that would require
> > for all drivers to duplicate that computation, which doesn't seem like
> > a good choice.
> >
> >>> + unsigned int bpp,
> >>> + unsigned int lanes,
> >>> + struct phy_configure_opts_mipi_dphy *cfg)
> >>> +{
> >>> + unsigned long hs_clk_rate;
> >>> + unsigned long ui;
> >>> +
> >>> + if (!cfg)
> >>> + return -EINVAL;
> >>> +
> >>> + hs_clk_rate = pixel_clock * bpp / lanes;
> >>> + ui = DIV_ROUND_UP(NSEC_PER_SEC, hs_clk_rate);
> >>
> >> Nanoseconds may not be precise enough for practical computations on these
> >> values. At 1 GHz, this ends up being precisely 1. At least Intel hardware
> >> has some more precision, I presume others do, too. How about using
> >> picoseconds instead?
> >
> > Sounds like a good idea.
>
> Would you be fixing this? Or this can be a later patch?
I have fixed this locally, but I wanted to wait a bit for more
feedback. I can send a new version if you prefer.
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 201867] Nouveau + discrete GPU (GP104M = GTX 1070 M) Driver Crashes, System freezes, dual screen not working
https://bugzilla.kernel.org/show_bug.cgi?id=201867 --- Comment #1 from david.kremer...@gmail.com --- I must add that the symptom as well as the concerned hardware starts to be pretty well documented. The problem arises with - recent nvidia mobile cards - optimus technology built in - intel integrated GPU (what else) ? You can arrive to the same result using the `bbswitch` module or the `acpi_call` module, trying to switch off the graphic card, *BUT*, since it's really the `nouveau` driver job to do the work, and since it is already trying to do it, I see no point in reporting bug for those modules. See also: - https://bugzilla.kernel.org/show_bug.cgi?id=156341 - https://github.com/Bumblebee-Project/Bumblebee/issues/1007 - https://github.com/Bumblebee-Project/Bumblebee/issues/764#issuecomment-234494238 for consistent ways of reproducing the undesired behaviour. The cheap hack to provide specific options for the `acpi_osi` driver should be discouraged as it is not consistent across GPU models and Laptop models. -- 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 v3 15/21] drm/sun4i: drv: Allow framebuffer modifiers in mode config
On Tue, Dec 04, 2018 at 03:22:12PM +0100, Paul Kocialkowski wrote: > This is the final step to indicate to the core that our driver > supports framebuffer modifiers. > > Signed-off-by: Paul Kocialkowski Acked-by: Maxime Ripard 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: [PATCH v3 21/21] drm/sun4i: frontend: Add A20-specific device-tree compatible and quirks
On Tue, Dec 04, 2018 at 03:22:18PM +0100, Paul Kocialkowski wrote: > This adds the appropriate device-tree compatible and quirk data for > hooking frontend support for the A20. It supports the FIR coefficients > ready bit but not the access control bit. It also takes different phase > values than the A33 for these coefficients. > > The compatible is already used in the A20 device-tree and already > documented in the device-tree bindings. > > Signed-off-by: Paul Kocialkowski Acked-by: Maxime Ripard 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: [PATCH v3 12/21] drm/sun4i: Add buffer stride and offset configuration for tiling mode
On Tue, Dec 04, 2018 at 03:22:09PM +0100, Paul Kocialkowski wrote:
> This introduces stride and offset configuration for the VPU tiling mode.
> Stride is calculated differently than it is for linear formats and an
> offset is calculated, for which new register definitions are introduced.
>
> Signed-off-by: Paul Kocialkowski
> ---
> drivers/gpu/drm/sun4i/sun4i_frontend.c | 60 --
> drivers/gpu/drm/sun4i/sun4i_frontend.h | 8
> 2 files changed, 65 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c
> b/drivers/gpu/drm/sun4i/sun4i_frontend.c
> index 3dcb05147e41..151b78d3c02e 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_frontend.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c
> @@ -125,21 +125,75 @@ void sun4i_frontend_update_buffer(struct sun4i_frontend
> *frontend,
> {
> struct drm_plane_state *state = plane->state;
> struct drm_framebuffer *fb = state->fb;
> + unsigned int strides[3] = {};
> +
> dma_addr_t paddr;
> bool swap;
>
> + if (fb->modifier == DRM_FORMAT_MOD_ALLWINNER_TILED) {
> + unsigned int width = state->src_w >> 16;
> + unsigned int offset;
> +
> + /*
> + * In MB32 tiled mode, the stride is defined as the distance
> + * between the start of the end line of the current tile and
> + * the start of the first line in the next vertical tile.
> + *
> + * Tiles are represented in row-major order, thus the end line
> + * of current tile starts at: 31 * 32 (31 lines of 32 cols),
> + * the next vertical tile starts at: 32-bit-aligned-width * 32
> + * and the distance is: 32 * (32-bit-aligned-width - 31).
> + */
It'd be better if that comment was next to the macro definition where
the code is.
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: [PATCH v3 14/21] drm/sun4i: layer: Add tiled modifier support and helper
On Tue, Dec 04, 2018 at 03:22:11PM +0100, Paul Kocialkowski wrote: > This introduces a list of supported modifiers for the driver, that > includes the Allwinner tiled modifier, as well as a format_mod_supported > callback. > > The callback uses both the backend and frontend helpers to indicate > per-format modifier support (including for the linear modifier). > > Signed-off-by: Paul Kocialkowski Acked-by: Maxime Ripard 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: [PATCH v3 13/21] drm/sun4i: frontend: Add and use helper for checking tiling support
On Tue, Dec 04, 2018 at 03:22:10PM +0100, Paul Kocialkowski wrote: > This introduces a helper to check whether a frontend input format > supports tiling mode. This helper is used when tiling is requested in > the frontend format support helper. > > Only semiplanar and planar YUV formats are supported by the hardware. > > Signed-off-by: Paul Kocialkowski Acked-by: Maxime Ripard 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: [PATCH v3 11/21] drm/sun4i: frontend: Add support for tiled YUV input mode configuration
On Tue, Dec 04, 2018 at 03:22:08PM +0100, Paul Kocialkowski wrote: > This introduces the data input mode definitions for the tiled YUV mode, > that are used in the input mode helper if tiling is requested. > > The modifier is passed to the helper from the framebuffer to determine > if tiling is requested. > > Only semiplanar and planar YUV formats are supported for tiling mode. > > Signed-off-by: Paul Kocialkowski Acked-by: Maxime Ripard 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: [PATCH v3 09/21] drm/sun4i: frontend: Add support for planar YUV input formats
On Tue, Dec 04, 2018 at 03:22:06PM +0100, Paul Kocialkowski wrote: > Planar YUV formats come with 3 distinct planes, which requires > configuring the frontend line stride and address registers for the > third plane. > > Our hardware only supports the YUV planes order and in order to support > formats with a YVU plane order, a helper is introduced to indicate > whether to invert the address of the two chroma planes. > > Missing definitions for YUV411 and YUV444 input format configuration are > also introduced as support is added for these formats. For the input > sequence part, no configuration is required for planar YUV formats so > zero is returned in that case. > > Signed-off-by: Paul Kocialkowski Acked-by: Maxime Ripard 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
