Hi John
Am 07.11.19 um 23:14 schrieb John Donnelly:
>
>
>> On Nov 7, 2019, at 10:13 AM, John Donnelly
>> wrote:
>>
>>
>>
>>> On Nov 7, 2019, at 7:42 AM, Thomas Zimmermann wrote:
>>>
>>> Hi John
>>>
>>> Am 07.11.19 um 14:12 schrieb John Donnelly:
Hi Thomas ; Thank you for reaching out.
Hi Böszörményi
Am 07.11.19 um 16:10 schrieb Böszörményi Zoltán:
> Hi,
>
> 2019. 11. 07. 10:43 keltezéssel, Thomas Zimmermann írta:
>> Udl's GEM implementation is mostly SHMEM and we should attempt to
>> replace it with the latter.
>>
>> Patches #1 and #2 update udl to simplify the conversion. In
Hi Linus,
Weekly fixes for drm, summary below, amdgpu has a few but they are
pretty scattered fixes, the fbdev one is a build regression fix that
we didn't want to risk leaving out, otherwise a couple of i915, one
radeon and a core atomic fix.
Dave.
The following changes since commit a99d8080aaf
https://bugs.freedesktop.org/show_bug.cgi?id=111482
--- Comment #41 from Robert ---
(In reply to Shmerl from comment #39)
> With kernel 5.4-rc6 I'm now seeing such errors once in 20 minutes or so:
>
I don't see it that often but I also getting it from time to time. I don't use
any patches. It's
2019. 11. 07. 16:10 keltezéssel, Böszörményi Zoltán írta:
what's the trick to actually enable the UDL device?
With 5.3.8, 5.3.9 or 5.4-rc6 + drm-next and this patchset, I get this:
[long messages]
I didn't mention that the system is 32-bit, using a PAE kernel.
Is it a problem for swiotlb?
The
On Fri, Nov 08, 2019 at 12:32:25AM +, Jason Gunthorpe wrote:
> On Thu, Nov 07, 2019 at 04:04:08PM -0500, Jerome Glisse wrote:
> > On Thu, Nov 07, 2019 at 08:11:06PM +, Jason Gunthorpe wrote:
> > > On Wed, Nov 06, 2019 at 09:08:07PM -0500, Jerome Glisse wrote:
> > >
> > > > >
> > > > > Ext
https://bugs.freedesktop.org/show_bug.cgi?id=111482
--- Comment #39 from Shmerl ---
With kernel 5.4-rc6 I'm now seeing such errors once in 20 minutes or so:
[37947.927301] WARNING: CPU: 5 PID: 992 at
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_resource.c:2806
dcn20_validate_bandwidth+0x
https://bugs.freedesktop.org/show_bug.cgi?id=111482
--- Comment #40 from Shmerl ---
To correct, it's 5.4-rc6 plus these patches:
https://cgit.freedesktop.org/~agd5f/linux/diff/?h=drm-fixes-5.4-2019-11-06&id=2c409ba81be25516afe05ae27a4a15da01740b01&id2=a99d8080aaf358d5d23581244e5da23b35e340b9
--
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: 270209307880ec946cfe9b98a6a58d285dbc5a2e
commit: f2157ab0fa53831e3575bfcbf0e92448c6943b9e [717/721] drm/sched: Use
completion to wait for sched->thread idle v2.
config: sh-allmodconfig (attached as .config)
compiler
Hi all,
This is now a conflict between the drm tree and Linus' tree.
On Thu, 31 Oct 2019 11:33:15 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the drm tree got a conflict in:
>
> drivers/gpu/drm/i915/i915_drv.h
>
> between commit:
>
> 59cd826fb5e7 ("drm/i915: Fix PCH ref
19. 8. 1. 오전 1:58에 Andrzej Pietrasiewicz 이(가) 쓴 글:
> Switch to using the ddc provided by the generic connector.
>
> Signed-off-by: Andrzej Pietrasiewicz
> Acked-by: Sam Ravnborg
> Reviewed-by: Emil Velikov
Acked-by: Inki Dae
Thanks,
Inki Dae
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c |
https://bugzilla.kernel.org/show_bug.cgi?id=205393
--- Comment #8 from tempel.jul...@gmail.com ---
Small correction: It's actually $mod (meta/win key by default) + shift + e.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
https://bugzilla.kernel.org/show_bug.cgi?id=205393
tempel.jul...@gmail.com changed:
What|Removed |Added
CC||tempel.jul...@gmail.com
--- Com
https://bugs.freedesktop.org/show_bug.cgi?id=111555
--- Comment #8 from Shmerl ---
I don't get these errors anymore when using radeon-profile with kernel 5.4-rc6.
But with ksysguard, Failed to export SMU metrics table! message is still
occurring, though it's not causing any stalls or hangs now.
On 11/7/19 3:36 PM, Jason Gunthorpe wrote:
> On Tue, Nov 05, 2019 at 10:16:46AM -0500, Boris Ostrovsky wrote:
>
>>> So, I suppose it can be relaxed to a null test and a WARN_ON that it
>>> hasn't changed?
>> You mean
>>
>> if (use_ptemod) {
>> WARN_ON(map->vma != vma);
>> ...
>>
>>
> -Original Message-
> From: amd-gfx On Behalf Of
> Bjorn Helgaas
> Sent: Thursday, November 7, 2019 5:21 PM
> To: Deucher, Alexander ; Koenig, Christian
> ; Zhou, David(ChunMing)
> ; David Airlie ; Daniel Vetter
>
> Cc: Bjorn Helgaas ; dri-devel@lists.freedesktop.org;
> amd-...@lists.fre
On Thu, Nov 7, 2019 at 5:21 PM Bjorn Helgaas wrote:
> diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
> index 29d6e93fd15e..03446be8a7be 100644
> --- a/include/uapi/linux/pci_regs.h
> +++ b/include/uapi/linux/pci_regs.h
> @@ -673,6 +673,8 @@
> #define PCI_EXP_LNKCTL2_T
From: Bjorn Helgaas
Replace hard-coded magic numbers with the descript PCI_EXP_LNKCTL2
definitions. No functional change intended.
---
drivers/gpu/drm/amd/amdgpu/cik.c | 8
drivers/gpu/drm/amd/amdgpu/si.c | 8
drivers/gpu/drm/radeon/cik.c | 8
drivers/gpu/drm/rad
From: Bjorn Helgaas
Add definitions for these PCIe Link Control 2 register fields:
Enter Compliance
Transmit Margin
and use them in amdgpu and radeon.
NOTE: This is a functional change because "7 << 9" looks like it might be a
typo. That mask includes the high order bit of Transmit Margin
From: Bjorn Helgaas
amdgpu and radeon do a bit of mucking with the PCIe Link Control 2
register, some of it using hard-coded magic numbers. The idea here is to
replace those with #defines.
I haven't signed off on these because the first one actually changes the
bits involved because the existin
Hi Fabrizio,
On Thu, Nov 07, 2019 at 08:02:25PM +, Fabrizio Castro wrote:
> Hi Jacopo,
>
> Thank you for your feedback!
>
> > From: Jacopo Mondi
> > Sent: 07 November 2019 18:19
> > Subject: Re: [PATCH v2 1/4] drm/bridge: Repurpose lvds-encoder.c
> >
> > Hi Fabrizio,
> > thanks for the patc
> On Nov 7, 2019, at 10:13 AM, John Donnelly wrote:
>
>
>
>> On Nov 7, 2019, at 7:42 AM, Thomas Zimmermann wrote:
>>
>> Hi John
>>
>> Am 07.11.19 um 14:12 schrieb John Donnelly:
>>> Hi Thomas ; Thank you for reaching out.
>>>
>>> See inline:
>>>
On Nov 7, 2019, at 1:54 AM, Thoma
On Thu, Nov 07, 2019 at 08:11:06PM +, Jason Gunthorpe wrote:
> On Wed, Nov 06, 2019 at 09:08:07PM -0500, Jerome Glisse wrote:
>
> > >
> > > Extra credit: IMHO, this clearly deserves to all be in a new
> > > mmu_range_notifier.h
> > > header file, but I know that's extra work. Maybe later as
From: Sean Paul
Add tracing which tracks important connector_state events through the atomic
core.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/drm_atomic.c | 12 -
drivers/gpu/drm/drm_trace.h | 101 +++
2 files changed, 112 insertions(+), 1 deletion(-)
d
From: Sean Paul
Add tracing which tracks important plane_state events through the atomic
core.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/drm_atomic.c | 16 +++-
drivers/gpu/drm/drm_trace.h | 143 +++
2 files changed, 158 insertions(+), 1 deletion(-)
diff -
From: Sean Paul
Add tracing which tracks important crtc_state events through the atomic
core.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/drm_atomic.c | 14 +
drivers/gpu/drm/drm_trace.h | 109 +++
2 files changed, 123 insertions(+)
diff --git a/drivers/
From: Sean Paul
We can use an event class to remove some boilerplate for the event
queued/delivered trace events.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/drm_trace.h | 27 +--
1 file changed, 9 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/drm_trace.
From: Sean Paul
Hey all,
I'm back with another trace events patchset. My first attempt [1] went
better than expected, with enthusiasm for the idea and distain for the
implementation.
As promised, I went through and added proper trace events.
Before I get _too_ far, I wanted to post this set to
From: Sean Paul
Mirror some atomic debug messages which track a state through
allocation/clear/check/commit/free
Change-Id: I0387ddf4b2f1d84137a5b471e347878c04c6d0af
Signed-off-by: Sean Paul
---
drivers/gpu/drm/drm_atomic.c | 19 +---
drivers/gpu/drm/drm_trace.h | 84 +
From: Sean Paul
This patch is the first step in expanding trace events in drm. It
introduces a new enum used to classify trace events as well as a couple
helper macros to issue trace events from around drm.
It's a bit of a toy right now since we're just converting one class
(vblank) and there ar
On 11/7/19 12:06 PM, Jason Gunthorpe wrote:
...
Also, it is best moved down to be next to the new MNR structs, so that all the
MNR stuff is in one group.
I agree with Jerome, this enum is part of the 'struct
mmu_notifier_range' (ie the description of the invalidation) and it
doesn't really mat
Hi Fabrizio,
Thank you for the patch.
On Thu, Nov 07, 2019 at 08:11:03PM +, Fabrizio Castro wrote:
> The iwg20d comes with an LCD panel from Emerging Display
> Technologies Corporation (EDT), therefore enable what's
> required to support it.
>
> Signed-off-by: Fabrizio Castro
>
> ---
> v2-
Hi Fabrizio,
Thank you for the patch.
On Thu, Nov 07, 2019 at 08:11:02PM +, Fabrizio Castro wrote:
> The iwg20d comes with a 7" capacitive touch screen, therefore
> add support for it.
>
> Signed-off-by: Fabrizio Castro
>
> ---
> v2->v3:
> * No change
> v1->v2:
> * No change
> ---
> arch/
Hi Fabrizio,
Thank you for the patch.
On Thu, Nov 07, 2019 at 08:11:01PM +, Fabrizio Castro wrote:
> Add connector type for the etm0700g0dh6 from Emerging Display
> Technologies (EDT).
>
> Signed-off-by: Fabrizio Castro
>
> ---
> v2->v3:
> * New patch
> ---
> drivers/gpu/drm/panel/panel-s
Hi Fabrizio,
(CC'ing Sam)
Thank you for the patch.
On Thu, Nov 07, 2019 at 08:11:00PM +, Fabrizio Castro wrote:
> The existing DRM_MODE_CONNECTOR_ definitions don't seem to
> describe the connector for RGB/Parallel embedded displays,
> hence add DRM_MODE_CONNECTOR_PARALLEL.
Please, no. We a
https://bugzilla.kernel.org/show_bug.cgi?id=205393
--- Comment #6 from har...@gmx.de ---
(In reply to Alex Deucher from comment #5)
> (In reply to haro41 from comment #4)
> > Yes, your patch works and has the same effect, apparently.
> >
> > What confused me and the reason why i prefered to leave
Hi Fabrizio,
Thank you for the patch.
On Thu, Nov 07, 2019 at 08:10:59PM +, Fabrizio Castro wrote:
> In an effort to repurpose lvds-encoder.c to also serve the
> function of LVDS decoders, we ended up defining a new "generic"
> compatible string, therefore adapt the dt-bindings to fit the
> n
Hi Fabrizio,
Thank you for the patch.
On Thu, Nov 07, 2019 at 08:10:58PM +, Fabrizio Castro wrote:
> lvds-encoder.c implementation is also suitable for LVDS decoders,
> not just LVDS encoders.
> Instead of creating a new driver for addressing support for
> transparent LVDS decoders, repurpose
Hi Fabrizio,
Thank you for the patch.
On Thu, Nov 07, 2019 at 08:10:57PM +, Fabrizio Castro wrote:
> Convert the lvds-transmitter binding to DT schema format using
> json-schema.
>
> Signed-off-by: Fabrizio Castro
>
> ---
> v2->v3:
> * Extracted conversion to dt-schema as per Rob's comment
https://bugzilla.kernel.org/show_bug.cgi?id=205393
--- Comment #5 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to haro41 from comment #4)
> Yes, your patch works and has the same effect, apparently.
>
> What confused me and the reason why i prefered to leave the
> vega10_update_avfs()
Hi Fabrizio,
Thank you for the patch.
On Wed, Aug 28, 2019 at 07:36:39PM +0100, Fabrizio Castro wrote:
> No need to report the input bus mode through bridge timings
> anymore, that's now done through the DT, as specified by the
> dt-bindings.
Doesn't this break backward compatibility with older
Hi Fabrizio,
Thank you for the patch.
On Wed, Aug 28, 2019 at 07:36:38PM +0100, Fabrizio Castro wrote:
> The driver doesn't support dual-link LVDS displays, and the way
> it identifies bridges won't allow for dual-LVDS displays to be
> connected. Also, it's not possible to swap even and odd pixel
On Thu, Nov 07, 2019 at 09:26:21PM +0200, Laurent Pinchart wrote:
> Hi Fabrizio,
>
> Thank you for the patch.
>
> On Wed, Aug 28, 2019 at 07:36:37PM +0100, Fabrizio Castro wrote:
> > Helper to provide bus timing information.
>
> You may want to expand this a bit. And actually fix it too, as the
On Thu, Nov 07, 2019 at 05:49:14PM +, Brian Starkey wrote:
> Hi Daniel,
>
> On Thu, Nov 07, 2019 at 06:32:01PM +0100, Daniel Vetter wrote:
> > On Thu, Nov 7, 2019 at 6:20 PM Brian Starkey wrote:
> > >
> > > Hi Daniel,
> > >
> > > On Tue, Nov 05, 2019 at 11:26:36PM +, Daniel Stone wrote:
>
Hi Fabrizio,
Thank you for the patch.
On Wed, Aug 28, 2019 at 07:36:37PM +0100, Fabrizio Castro wrote:
> Helper to provide bus timing information.
You may want to expand this a bit. And actually fix it too, as the
helper you introduce isn't related to timings (same for the subject
line).
> Sign
https://bugs.freedesktop.org/show_bug.cgi?id=111762
--- Comment #9 from tempel.jul...@gmail.com ---
Thank you, I'll try it out at some point.
I also got an email by fin4478 with the suggestion to try out
amdgpu.ppfeaturemask=0xfffd7fff.
--
You are receiving this mail because:
You are the assign
https://bugs.freedesktop.org/show_bug.cgi?id=111762
--- Comment #8 from Matt Coffin ---
(In reply to Matt Coffin from comment #7)
> This patch should take care of the problem by treating navi10's TDPODLimit
> the same as vega20 does: https://patchwork.freedesktop.org/series/69090/
Sorry for the
https://bugs.freedesktop.org/show_bug.cgi?id=111762
--- Comment #7 from Matt Coffin ---
This patch should take care of the problem by treating navi10's TDPODLimit the
same as vega20 does: https://patchwork.freedesktop.org/series/69090/
--
You are receiving this mail because:
You are the assigne
There is no need for brackets for a single line inside the 'if' block,
so remove the unneeded brackets.
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Fix typo in commit log
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/driver
https://bugzilla.kernel.org/show_bug.cgi?id=205393
--- Comment #4 from har...@gmx.de ---
Yes, your patch works and has the same effect, apparently.
What confused me and the reason why i prefered to leave the
vega10_update_avfs() call before the flag modification, was the code inside
vega10_update
There is no need for brackets when for a single line inside
the 'if' block, so remove the unneeded brackets.
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
b/drivers
Hi Fabrizio,
thanks for the patch.
On Mon, Nov 04, 2019 at 04:58:00PM +, Fabrizio Castro wrote:
> lvds-encoder.c implementation is also suitable for LVDS decoders,
> not just LVDS encoders.
> Instead of creating a new driver for addressing support for
> transparent LVDS decoders, repurpose l
Hi Fabrizio,
Thank you for the patch.
On Wed, Aug 28, 2019 at 07:36:36PM +0100, Fabrizio Castro wrote:
> Add binding for the idk-2121wr LVDS panel from Advantech.
>
> Some panel-specific documentation can be found here:
> https://buy.advantech.eu/Displays/Embedded-LCD-Kits-High-Brightness/model-
Hello Fabrizio,
On Thu, Aug 29, 2019 at 02:38:06PM +, Fabrizio Castro wrote:
> On 29 August 2019 15:03 Rob Herring wrote:
> > On Wed, Aug 28, 2019 at 1:36 PM Fabrizio Castro wrote:
> >>
> >> Dual-LVDS connections need markers in the DT, this patch adds
> >> some common documentation to be refe
Hi Daniel,
On Thu, Nov 07, 2019 at 06:32:01PM +0100, Daniel Vetter wrote:
> On Thu, Nov 7, 2019 at 6:20 PM Brian Starkey wrote:
> >
> > Hi Daniel,
> >
> > On Tue, Nov 05, 2019 at 11:26:36PM +, Daniel Stone wrote:
> > > Hi Andrzej,
> > > Thanks for taking this on! It's looking better than v1 f
On Thu, Nov 07, 2019 at 09:30:50AM -0800, Eric Anholt wrote:
> Rob Clark writes:
> > On Wed, Nov 6, 2019 at 3:26 PM Fritz Koenig wrote:
> >>
> >> Hardware only natively supports BGR UBWC.
> >> UBWC support for RGB can be had by pretending
> >> that the buffer is BGR.
> >
> > Just to expan
On Thu, Nov 07, 2019 at 05:17:14PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> This thing can get called several thousand times per LUT
> so seems like we want to inline it to:
> - avoid the function call overhead
> - allow constant folding
>
> A quick synthetic test (w/o any hardware
On Thu, Nov 07, 2019 at 04:24:13PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Annoyingly __drm_atomic_helper_crtc_reset() does two
> totally separate things:
> a) reset the state to defaults values
> b) assign the crtc->state pointer
>
> I just want a) without the b) so let's split ou
On Thu, Nov 7, 2019 at 6:20 PM Brian Starkey wrote:
>
> Hi Daniel,
>
> On Tue, Nov 05, 2019 at 11:26:36PM +, Daniel Stone wrote:
> > Hi Andrzej,
> > Thanks for taking this on! It's looking better than v1 for sure. A few
> > things below:
> >
> > On Mon, 2019-11-04 at 23:12 +0100, Andrzej Pietr
On Thu, Nov 07, 2019 at 05:17:00PM +, Chris Wilson wrote:
> Quoting Daniel Vetter (2019-11-07 08:39:24)
> > On Wed, Nov 06, 2019 at 02:24:30PM +, Chris Wilson wrote:
> > > As drm now exports a method to create an anonymous struct file around a
> > > drm_device for internal use, make use of
Rob Clark writes:
> On Wed, Nov 6, 2019 at 3:26 PM Fritz Koenig wrote:
>>
>> Hardware only natively supports BGR UBWC.
>> UBWC support for RGB can be had by pretending
>> that the buffer is BGR.
>
> Just to expand, this aligns with how we handle RGB component order in
> mesa for tiled or
On Wed, 6 Nov 2019 at 14:24, Chris Wilson wrote:
>
> As drm now exports a method to create an anonymous struct file around a
> drm_device for internal use, make use of it to avoid our horrible hacks.
>
> Signed-off-by: Chris Wilson
As per your eventual plan, fwiw,
Reviewed-by: Matthew Auld
https://bugs.freedesktop.org/show_bug.cgi?id=112226
--- Comment #5 from Alex Deucher ---
(In reply to Eero Tamminen from comment #3)
>
> AFAIK reset should affect only the context running in the GPU when it was
> reseted, not the others [1], and in this case the problematic client should
> be Gf
Hi Daniel,
On Tue, Nov 05, 2019 at 11:26:36PM +, Daniel Stone wrote:
> Hi Andrzej,
> Thanks for taking this on! It's looking better than v1 for sure. A few
> things below:
>
> On Mon, 2019-11-04 at 23:12 +0100, Andrzej Pietrasiewicz wrote:
> > +bool drm_afbc_check_offset(struct drm_device *dev
https://bugzilla.kernel.org/show_bug.cgi?id=205393
--- Comment #3 from Alex Deucher (alexdeuc...@gmail.com) ---
Created attachment 285821
--> https://bugzilla.kernel.org/attachment.cgi?id=285821&action=edit
possible fix
Does this patch work? I think it would be better to move the change above
Quoting Daniel Vetter (2019-11-07 08:39:24)
> On Wed, Nov 06, 2019 at 02:24:30PM +, Chris Wilson wrote:
> > As drm now exports a method to create an anonymous struct file around a
> > drm_device for internal use, make use of it to avoid our horrible hacks.
> >
> > Signed-off-by: Chris Wilson
https://bugs.freedesktop.org/show_bug.cgi?id=109955
--- Comment #133 from Wilko Bartels ---
(In reply to haro41 from comment #132)
> (In reply to Wilko Bartels from comment #131)
> > Thank you. I already tried exactly that. And the unit unable to autostart
> > (permission denied). Only manual sys
On Wed, Nov 6, 2019 at 3:26 PM Fritz Koenig wrote:
>
> Hardware only natively supports BGR UBWC.
> UBWC support for RGB can be had by pretending
> that the buffer is BGR.
Just to expand, this aligns with how we handle RGB component order in
mesa for tiled or tiled+ubwc. If uncompressed t
On Thu, Nov 7, 2019 at 3:10 AM Brian Masney wrote:
>
> On Wed, Nov 06, 2019 at 08:58:59AM -0800, Rob Clark wrote:
> > On Wed, Nov 6, 2019 at 8:47 AM Jeffrey Hugo
> > wrote:
> > >
> > > On Wed, Nov 6, 2019 at 9:30 AM Rob Clark wrote:
> > > >
> > > > On Wed, Nov 6, 2019 at 1:13 AM Brian Masney
> On Nov 7, 2019, at 7:42 AM, Thomas Zimmermann wrote:
>
> Hi John
>
> Am 07.11.19 um 14:12 schrieb John Donnelly:
>> Hi Thomas ; Thank you for reaching out.
>>
>> See inline:
>>
>>> On Nov 7, 2019, at 1:54 AM, Thomas Zimmermann wrote:
>>>
>>> Hi John,
>>>
>>> apparently the vgaarb wa
On Thu, Nov 07, 2019 at 11:11:03PM +0800, Jason Wang wrote:
> Hi all:
>
> There are hardwares that can do virtio datapath offloading while
> having its own control path. This path tries to implement a mdev based
> unified API to support using kernel virtio driver to drive those
> devices. This is
On 2019-11-07 10:43 a.m., Ville Syrjälä wrote:
> On Thu, Nov 07, 2019 at 03:31:28PM +, Kazlauskas, Nicholas wrote:
>> On 2019-11-07 10:17 a.m., Ville Syrjala wrote:
>>> From: Ville Syrjälä
>>>
>>> This thing can get called several thousand times per LUT
>>> so seems like we want to inline it t
On Thu, Nov 07, 2019 at 03:31:28PM +, Kazlauskas, Nicholas wrote:
> On 2019-11-07 10:17 a.m., Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > This thing can get called several thousand times per LUT
> > so seems like we want to inline it to:
> > - avoid the function call overhead
> > - a
On Mon, Nov 04, 2019 at 04:42:49PM +0800, allen wrote:
> According to VESA ENHANCED EXTENDED DISPLAY IDENTIFICATION DATA STANDARD
> (Defines EDID Structure Version 1, Revision 4) page: 39
> How to determine whether the monitor support RB timing or not?
> EDID 1.4
> First: read detailed timing desc
On Thu, 7 Nov 2019 23:11:06 +0800
Jason Wang wrote:
> Currently, except for the create and remove, the rest of
> mdev_parent_ops is designed for vfio-mdev driver only and may not help
> for kernel mdev driver. With the help of class id, this patch
> introduces device specific callbacks inside md
On Thu, 7 Nov 2019 23:11:09 +0800
Jason Wang wrote:
> This sample driver creates mdev device that simulate virtio net device
> over virtio mdev transport. The device is implemented through vringh
> and workqueue. A device specific dma ops is to make sure HVA is used
> directly as the IOVA. This
From: David Francis
Add drm_dp_mst_dsc_aux_for_port. To enable DSC, the DSC_ENABLED
register might have to be written on the leaf port's DPCD,
its parent's DPCD, or the MST manager's DPCD. This function
finds the correct aux for the job.
As part of this, add drm_dp_mst_is_virtual_dpcd. Virtual D
From: David Francis
If there is limited link bandwidth on a MST network,
it must be divided fairly between the streams on that network
Implement an algorithm to determine the correct DSC config
for each stream
The algorithm:
This
[ ] ( )
represents the range of b
From: Mikita Lipski
Since for DSC MST connector's PBN is claculated differently
due to compression, we have to recalculate both PBN and
VCPI slots for that connector.
The function iterates through all the active streams to
find, which have DSC enabled, then recalculates PBN for
it and calls drm_
From: David Francis
Instead of having drm_dp_dpcd_read/write and
drm_dp_mst_dpcd_read/write as entry points into the
aux code, have drm_dp_dpcd_read/write handle both.
This means that DRM drivers can make MST DPCD read/writes.
v2: Fix spacing
v3: Dump dpcd access on MST read/writes
v4: Fix call
From: David Francis
With DSC, bpp can be fractional in multiples of 1/16.
Change drm_dp_calc_pbn_mode to reflect this, adding a new
parameter bool dsc. When this parameter is true, treat the
bpp parameter as having units not of bits per pixel, but
1/16 of a bit per pixel
v2: Don't add separate
From: David Francis
This field on drm_dp_mst_branch was never filled
It is initialized to zero when the port is kzallocced.
When a port is added to the list, increment num_ports,
and when a port is removed from the list, decrement num_ports.
v2: remember to decrement on port removal
v3: don't e
From: David Francis
Rework the dm_helpers_write_dsc_enable callback to
handle the MST case.
Use the cached dsc_aux field.
Reviewed-by: Wenjing Liu
Signed-off-by: David Francis
---
.../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 19 ++-
1 file changed, 18 insertions(+), 1 dele
From: David Francis
As of DP1.4, ENUM_PATH_RESOURCES returns a bit indicating
if FEC can be supported up to that point in the MST network.
The bit is the first byte of the ENUM_PATH_RESOURCES ack reply,
bottom-most bit (refer to section 2.11.9.4 of DP standard,
v1.4)
That value is needed for FE
From: David Francis
During MST mode enumeration, if a new dc_sink is created,
populate it with dsc caps as appropriate.
Use drm_dp_mst_dsc_aux_for_port to get the raw caps,
then parse them onto dc_sink with dc_dsc_parse_dsc_dpcd.
Reviewed-by: Wenjing Liu
Signed-off-by: David Francis
---
.../
From: Mikita Lipski
Adding a helper function to be called by
drivers outside of DRM to enable DSC on
the MST ports.
Function is called to recalculate VCPI allocation
if DSC is enabled and raise the DSC flag to enable.
In case of disabling DSC the flag is set to false
and recalculation of VCPI sl
From: Mikita Lipski
Adding PBN attribute to drm_dp_vcpi_allocation structure to
keep track of how much bandwidth each Port requires.
Adding drm_dp_mst_atomic_check_bw_limit to verify that
state's bandwidth needs doesn't exceed available bandwidth.
The funtion is called in drm_dp_mst_atomic_check
From: Mikita Lipski
Patches are based of amd-staging-drm-next, the follow up
set of patches will be sent for drm-tip
This set of patches is a continuation of DSC enablement
patches for AMDGPU. This set enables DSC on MST. It also
contains implementation of both encoder and connector
atomic check
From: David Francis
For DSC MST, sometimes monitors would break out
in full-screen static. The issue traced back to the
PPS generation code, where these variables were being used
uninitialized and were picking up garbage.
memset to 0 to avoid this
Reviewed-by: Nicholas Kazlauskas
Signed-off-by
From: Mikita Lipski
Synaptics DP1.4 hubs (BRANCH_ID 0x90CC24) do not
support virtual DPCD registers, but do support DSC.
The DSC caps can be read from the physical aux,
like in SST DSC. These hubs have many different
DEVICE_IDs. Add a new quirk to detect this case.
Reviewed-by: Wenjing Liu
Rev
On 2019-11-07 10:17 a.m., Ville Syrjala wrote:
> From: Ville Syrjälä
>
> This thing can get called several thousand times per LUT
> so seems like we want to inline it to:
> - avoid the function call overhead
> - allow constant folding
>
> A quick synthetic test (w/o any hardware interaction) wit
psbfb_probe performs an evaluation of the required size from the stolen
GTT memory, but gets it wrong in two distinct ways:
- The resulting size must be page-size-aligned;
- The size to allocate is derived from the surface dimensions, not the fb
dimensions.
When two connectors are connected with
Hello,
On Tue, Nov 05, 2019 at 04:08:22PM -0800, Brian Welty wrote:
> I was more interested in hearing your thoughts on whether you like
> the approach to have a set of controls that are consistent with
> some subset of the existing CPU/MEM ones. Any feedback on this?
> Didn't really mean to sug
From: Ville Syrjälä
Extract all the 'hw value -> LUT entry' stuff into small helpers
to make the main 'read out the entire LUT' loop less bogged down
by such mundane details.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 128 ++---
1 file changed
From: Ville Syrjälä
chv_read_cgm_lut() specifically reads the CGM _gamma_ LUT so
let's rename it to reflect that fact. This also mirrors
the other direction's chv_load_cgm_gamma().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 4 ++--
1 file changed, 2 insertion
From: Ville Syrjälä
We have a nice little helper to compute a single LUT entry
for everything except the 8bpc legacy gamma mode. Let's
complete the set.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 12
1 file changed, 8 insertions(+), 4 deletions(-
From: Ville Syrjälä
PIPEGCMAX is a 11.6 (or 1.16 if you will) value. Ie. it can
represent a value of 1.0 when the maximum we can store in the
software LUT is 0.. Clamp the value so that it gets
saturated to the max the uapi supports.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/di
From: Ville Syrjälä
A variable called 'i' having an unsigned type is just looking for
trouble, and using a sized type generally makes no sense either.
Change all of them to just plain old int. And do the same for some
'lut_size' variables which generally provide the loop end codition
for 'i'.
Si
From: Ville Syrjälä
To mirror the load_luts path let's clone an ilk+ version
from i9xx_read_lut_8(). I guess the extra branch isn't a huge
issue but feels better to make a clean split.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 41 ++
1 fi
From: Ville Syrjälä
We're talking about LUT contents here so let's call the thing
'lut' rather than 'blob_data'. This is the name the load_lut()
code used before already.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 66 +++---
1 file changed, 33
1 - 100 of 217 matches
Mail list logo
