Changes in the series since v1:
- no changes to patch 1 (Xen shared code)
- ALSA: fix comment from Takashi (NULL stream->buffer)
- DRM: removed display buffer flush workaround
(proper fix is on review [1])
Thank you,
Oleksandr
On 11/30/18 9:42 AM, Oleksandr Andrushchenko wrote:
From:
From: Oleksandr Andrushchenko
Use page directory based shared buffer implementation
now available as common code for Xen frontend drivers.
Remove flushing of shared buffer on page flip as this
workaround needs a proper fix.
Signed-off-by: Oleksandr Andrushchenko
---
From: Oleksandr Andrushchenko
based frontends. Currently the frontends which implement
similar code for sharing big buffers between frontend and
backend are para-virtualized DRM and sound drivers.
Both define the same way to share grant references of a
data buffer with the corresponding backend
From: Oleksandr Andrushchenko
Use page directory based shared buffer implementation
now available as common code for Xen frontend drivers.
Signed-off-by: Oleksandr Andrushchenko
---
sound/xen/Kconfig | 1 +
sound/xen/Makefile | 1 -
sound/xen/xen_snd_front.c
Could you move this one to dma-fence as you said? Which will be used in
other place as well.
-David
On 2018年11月28日 22:50, Christian König wrote:
Extract of useful code from the timeline work. Let's use just a single
stub fence instance instead of allocating a new one all the time.
On 2018年11月28日 22:50, Christian König wrote:
From: Chunming Zhou
v2: symbos are stored in lexical order.
v3: drop export/import and extra query indirection
Signed-off-by: Chunming Zhou
Signed-off-by: Christian König
---
amdgpu/amdgpu-symbol-check | 2 ++
amdgpu/amdgpu.h|
On 11/30/18 8:50 AM, Juergen Gross wrote:
On 29/11/2018 12:22, Oleksandr Andrushchenko wrote:
ping
On 11/22/18 12:02 PM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
based frontends. Currently the frontends which implement
similar code for sharing big buffers between
Quoting Matthias Brugger (2018-11-21 09:09:52)
>
>
> On 21/11/2018 17:46, Stephen Boyd wrote:
> > Quoting Rob Herring (2018-11-19 11:15:16)
> >> On Sun, Nov 18, 2018 at 11:12 AM Matthias Brugger
> >> wrote:
> >>> On 11/17/18 12:15 AM, Rob Herring wrote:
> On Fri, Nov 16, 2018 at 01:54:45PM
https://bugs.freedesktop.org/show_bug.cgi?id=108912
Bug ID: 108912
Summary: Null PTR deref on amd-staging-drm-next since rebase
for rc3
Product: DRI
Version: XOrg git
Hardware: Other
OS: All
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #55 from bmil...@gmail.com ---
(In reply to Alex Deucher from comment #53)
> Created attachment 142662 [details] [review]
> possible fix
>
> How about this patch?
for me it still flickers after sleep/wake @75hz unless I lock mclck
On Wed, Nov 28, 2018 at 11:36:33AM -0800, Brendan Higgins wrote:
> Make UML unflatten any present device trees when running KUnit tests.
>
> Signed-off-by: Brendan Higgins
> ---
> arch/um/kernel/um_arch.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/um/kernel/um_arch.c
On Thu, Nov 29, 2018 at 01:56:37PM +, Kieran Bingham wrote:
> Hi Brendan,
>
> Please excuse the top posting, but I'm replying here as I'm following
> the section "Creating a kunitconfig" in Documentation/kunit/start.rst.
>
> Could the three line kunitconfig file live under say
>
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
On Wed, Nov 28, 2018 at 11:36:25AM -0800, Brendan Higgins wrote:
> +static void segv_run_catcher(jmp_buf *catcher, void *fault_addr)
> +{
> + current->thread.fault_addr = fault_addr;
> + UML_LONGJMP(catcher, 1);
> +}
Some documentation about what this does exactly would be appreciated.
On Wed, Nov 28, 2018 at 11:36:24AM -0800, Brendan Higgins wrote:
> Add a test for string stream along with a simpler example.
>
> Signed-off-by: Brendan Higgins
> ---
> kunit/Kconfig | 12 ++
> kunit/Makefile | 4 ++
> kunit/example-test.c | 88
On Wed, Nov 28, 2018 at 03:26:03PM -0600, Rob Herring wrote:
> On Wed, Nov 28, 2018 at 1:37 PM Brendan Higgins
> wrote:
> >
> > Make minimum number of changes outside of the KUnit directories for
> > KUnit to build and run using UML.
>
> There's nothing in this patch limiting this to UML.
Not
On Wed, Nov 28, 2018 at 11:36:25AM -0800, Brendan Higgins wrote:
> diff --git a/arch/um/kernel/trap.c b/arch/um/kernel/trap.c
> index cced829460427..bf90e678b3d71 100644
> --- a/arch/um/kernel/trap.c
> +++ b/arch/um/kernel/trap.c
> @@ -201,6 +201,12 @@ void segv_handler(int sig, struct siginfo
On Wed, Nov 28, 2018 at 11:36:23AM -0800, Brendan Higgins wrote:
> Make minimum number of changes outside of the KUnit directories for
> KUnit to build and run using UML.
>
> Signed-off-by: Brendan Higgins
> ---
> Kconfig | 2 ++
> Makefile | 2 +-
> 2 files changed, 3 insertions(+), 1
On Wed, Nov 28, 2018 at 11:36:20AM -0800, Brendan Higgins wrote:
> A number of test features need to do pretty complicated string printing
> where it may not be possible to rely on a single preallocated string
> with parameters.
>
> So provide a library for constructing the string as you go
> +static void kunit_run_case_internal(struct kunit *test,
> + struct kunit_module *module,
> + struct kunit_case *test_case)
> +{
> + int ret;
> +
> + if (module->init) {
> + ret = module->init(test);
> +
https://bugs.freedesktop.org/show_bug.cgi?id=108685
Samantha McVey changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=108668
Samantha McVey changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
On Wed, Nov 28, 2018 at 11:36:18AM -0800, Brendan Higgins wrote:
> +#define module_test(module) \
> + static int module_kunit_init##module(void) \
> + { \
> + return kunit_run_tests(); \
> + } \
> +
Hi Linus,
This weeks instalment of fixes. Looks fairly like business as usual
and everything seems to rolling along. There was one MST fix applied
and reverted in the misc tree, but otherwise nothing too strange in
here.
core: incorrect master setting on error fix
i915: only GVT fixes this week,
As we have a else block for the 'if (dev_priv->psr.psr2_enabled) {'
and this bit is only set for PSR1 move it to that block to make it
more easy to read.
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/intel_psr.c | 5 +++--
1 file
i915 yet don't support PSR in Apple panels, so lets keep it disabled
while we work on that.
v2: Renamed DP_DPCD_QUIRK_PSR_NOT_CURRENTLY_SUPPORTED to
DP_DPCD_QUIRK_NO_PSR (Ville)
Fixes: 598c6cfe0690 (drm/i915/psr: Enable PSR1 on gen-9+ HW)
Cc: Ville Syrjälä
Cc: Rodrigo Vivi
Cc: Dhinakaran
For PSR2 there is no register to tell HW to keep main link enabled
while PSR2 is active, so don't configure sink DPCD with a
misleading value.
v2: Moving the set of DP_PSR_CRC_VERIFICATION to the else block
of 'if (dev_priv->psr.psr2_enabled)' to another patch. (Rodrigo)
Cc: Dhinakaran Pandiyan
Our frontbuffer tracking improved over the years + the WA #0884
helped us keep PSR2 enabled while triggering screen updates when
necessary so this FIXME is not valid anymore.
Acked-by: Dhinakaran Pandiyan
Reviewed-by: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
Selective updates have a default granularity requirements as stated
by eDP spec, so check if HW can match those requirements before
enable PSR2.
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/intel_psr.c | 12
1 file
EDP_PSR2_FRAME_BEFORE_SU() is the number of frames that PSR2 HW will
wait before enter in PSR2 activation state, important to note here is
that it will wait for X frames not X idle frames.
So lets reuse the previous approch to get the maximum number of
frames between 6 and sink_sync_latency to
Source is required to comply to sink SU granularity when
DP_PSR2_SU_GRANULARITY_REQUIRED is set in DP_PSR_CAPS,
so adding the registers offsets.
v2: Also adding DP_PSR2_SU_Y_GRANULARITY(Rodrigo)
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
eDP spec states 2 different bits to enable sink to trigger a
interruption when there is a CRC mismatch.
DP_PSR_CRC_VERIFICATION is for PSR only and
DP_PSR_IRQ_HPD_WITH_CRC_ERRORS is for PSR2 only.
Cc: Dhinakaran Pandiyan
Reviewed-by: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
According to eDP spec, sink can required specific selective update
granularity that source must comply.
Here caching the value if required and checking if source supports
it.
Cc: Rodrigo Vivi
Cc: Dhinakaran Pandiyan
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_drv.h |
For ICL the bit 12 of CHICKEN_TRANS is reserved so we should not
touch it and as by default VSC_DATA_SEL_SOFTWARE_CONTROL is already
unset in gen10 + GLK we can just drop it and fix for both gens.
Cc: Dhinakaran Pandiyan
Reviewed-by: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
- Reusing the EDP_PSR2_FRAME_BEFORE_SU_SHIFT in EDP_PSR2_FRAME_BEFORE_SU
- Removing unused EDP_PSR2_FRAME_BEFORE_SU_MASK
- Adding EDP_PSR2_FRAME_BEFORE_SU_MAX
- Adding EDP_PSR2_IDLE_FRAME()
- Adding EDP_PSR2_IDLE_FRAME_MAX
In the next patch the new macros will be used.
Cc: Dhinakaran Pandiyan
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #33 from Alex Deucher ---
With respect to pci(e) devices, acpi=off and pci=noacpi are equivalent I think.
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #32 from Robert Strube ---
Hi Alex,
I just tested acpi=off independently and not amdgpu.dpm=0 independently.
In regards to the other user, yes he had the exact same PCI resource issues as
me, what I'm curious to find out though,
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #31 from Alex Deucher ---
(In reply to Robert Strube from comment #30)
> Hi Alex,
>
> Thanks for the reply. I wanted to clarify an important point: When I
> disabled PM completely and ACPI completely, I did not see any PCI
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #30 from Robert Strube ---
Hi Alex,
Thanks for the reply. I wanted to clarify an important point: When I disabled
PM completely and ACPI completely, I did not see any PCI resource issues AND
the eGPU initialized successfully.
https://bugs.freedesktop.org/show_bug.cgi?id=96868
Alex Deucher changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=102646
Alex Deucher changed:
What|Removed |Added
CC||almo...@gmail.com
--- Comment #54 from
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #53 from Alex Deucher ---
Created attachment 142662
--> https://bugs.freedesktop.org/attachment.cgi?id=142662=edit
possible fix
How about this patch?
--
You are receiving this mail because:
You are the assignee for the
On Thu, Nov 29, 2018 at 10:57 AM Christoph Hellwig wrote:
>
> On Thu, Nov 29, 2018 at 03:43:50PM +0100, Daniel Vetter wrote:
> > Yeah we had patches to add manual cache management code to drm, so we
> > don't have to abuse the dma streaming api anymore. Got shouted down.
> > Abusing the dma
On Wed, Nov 28, 2018 at 12:13:30PM -0800, Souza, Jose wrote:
> On Wed, 2018-11-28 at 11:02 -0800, Rodrigo Vivi wrote:
> > On Mon, Nov 26, 2018 at 04:37:03PM -0800, José Roberto de Souza
> > wrote:
> > > For PSR2 there is no register to tell HW to keep main link enabled
> > > while PSR2 is active,
On Wed, Nov 28, 2018 at 01:50:01PM -0700, shuah wrote:
> On 11/28/18 12:54 PM, Knut Omang wrote:
> > On Mon, 2018-11-26 at 17:41 -0800, Brendan Higgins wrote:
> > Both approaches provide assertion macros for running tests inside the
> > kernel,
> > I doubt the kernel community would like to see
On Thu, 2018-11-29 at 15:10 -0800, Rodrigo Vivi wrote:
> On Mon, Nov 26, 2018 at 04:37:09PM -0800, José Roberto de Souza
> wrote:
> > EDP_PSR2_IDLE_FRAMES_TO_DEEP_SLEEP() was being set with the number
> > of
> > frames that it should wait to enter PSR, what is wrong.
> > Here it is setting this
On Thu, Nov 29, 2018 at 12:03 PM Robin Murphy wrote:
>
> On 29/11/2018 19:57, Tomasz Figa wrote:
> > On Thu, Nov 29, 2018 at 11:40 AM Jordan Crouse
> > wrote:
> >>
> >> On Thu, Nov 29, 2018 at 01:48:15PM -0500, Rob Clark wrote:
> >>> On Thu, Nov 29, 2018 at 10:54 AM Christoph Hellwig wrote:
>
On Thu, 2018-11-29 at 15:25 -0800, Dhinakaran Pandiyan wrote:
> On Thu, 2018-11-29 at 15:07 -0800, Rodrigo Vivi wrote:
> > On Mon, Nov 26, 2018 at 04:37:08PM -0800, José Roberto de Souza
> > wrote:
> > > The first 8 bits of PSR2_CTL have 2 fields to set frames count,
> > > the
> > > first one is
Daniel Vetter writes:
> Cc: Keith Packard
Reviewed-by: Keith Packard
--
-keith
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Thu, 2018-11-29 at 15:03 -0800, Rodrigo Vivi wrote:
> On Mon, Nov 26, 2018 at 04:37:07PM -0800, José Roberto de Souza
> wrote:
> > According to eDP spec, sink can required specific selective update
> > granularity that source must comply.
> > Here caching the value if required and checking
Daniel Vetter writes:
> On Wed, Nov 28, 2018 at 01:52:56PM -0800, Eric Anholt wrote:
>> Daniel Vetter writes:
>>
>> > On Tue, Nov 27, 2018 at 12:38:44PM -0800, Eric Anholt wrote:
>> >> Daniel Vetter writes:
>> >>
>> >> > On Mon, Nov 26, 2018 at 04:36:21PM -0800, Eric Anholt wrote:
>> >> >>
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #29 from Alex Deucher ---
(In reply to Robert Strube from comment #28)
> Quick update:
>
> I heard back from the ACPI BIOS kernel developers (see:
> https://bugzilla.kernel.org/show_bug.cgi?id=201527) and they seem to imply
> that
On Thu, 2018-11-29 at 14:15 -0800, Rodrigo Vivi wrote:
> On Mon, Nov 26, 2018 at 04:37:05PM -0800, José Roberto de Souza
> wrote:
> > For ICL the bit 12 of CHICKEN_TRANS is reserved so we should not
> > touch it and as by default VSC_DATA_SEL_SOFTWARE_CONTROL is already
> > unset in gen10 + GLK we
On Tue, 2018-11-27 at 13:55 -0800, Souza, Jose wrote:
> On Tue, 2018-11-27 at 15:38 +0200, Ville Syrjälä wrote:
> > On Mon, Nov 26, 2018 at 04:37:02PM -0800, José Roberto de Souza
> > wrote:
> > > i915 yet don't support PSR in Apple panels, so lets keep
Replace "Apple" with specific model name?
>
From: Colin Ian King
Don't populate the const array m_div_val on the stack but instead
make it static. Makes the object code smaller by 60 bytes:
Before:
textdata bss dec hex filename
323391728 0 340678513 mgag200/mgag200_mode.o
After:
textdata
On Thu, 2018-11-29 at 14:04 -0800, Rodrigo Vivi wrote:
> On Mon, Nov 26, 2018 at 04:37:04PM -0800, José Roberto de Souza
> wrote:
> > eDP spec states 2 different bits to enable sink to trigger a
> > interruption when there is a CRC mismatch.
> > DP_PSR_CRC_VERIFICATION is for PSR only and
> >
On Thu, 2018-11-29 at 15:11 -0800, Rodrigo Vivi wrote:
> On Mon, Nov 26, 2018 at 04:37:10PM -0800, José Roberto de Souza
> wrote:
> > Our frontbuffer tracking improved over the years + the WA #0884
> > helped us keep PSR2 enabled while triggering screen updates when
> > necessary so this FIXME is
On Thu, 2018-11-29 at 15:07 -0800, Rodrigo Vivi wrote:
> On Mon, Nov 26, 2018 at 04:37:08PM -0800, José Roberto de Souza
> wrote:
> > The first 8 bits of PSR2_CTL have 2 fields to set frames count, the
> > first one is to set how many idle frames PSR2 HW needs to wait
> > before
> > enter in deep
On Mon, Nov 26, 2018 at 04:37:10PM -0800, José Roberto de Souza wrote:
> Our frontbuffer tracking improved over the years + the WA #0884
> helped us keep PSR2 enabled while triggering screen updates when
> necessary so this FIXME is not valid anymore.
>
> Cc: Dhinakaran Pandiyan
> Cc: Rodrigo
On Mon, Nov 26, 2018 at 04:37:09PM -0800, José Roberto de Souza wrote:
> EDP_PSR2_IDLE_FRAMES_TO_DEEP_SLEEP() was being set with the number of
> frames that it should wait to enter PSR, what is wrong.
> Here it is setting this field with the highest value to avoid PSR2
> exits frequently, as when
On Mon, Nov 26, 2018 at 04:37:08PM -0800, José Roberto de Souza wrote:
> The first 8 bits of PSR2_CTL have 2 fields to set frames count, the
> first one is to set how many idle frames PSR2 HW needs to wait before
> enter in deep sleep and the second one it is how many frames(it don't
> need to be
On Mon, Nov 26, 2018 at 04:37:07PM -0800, José Roberto de Souza wrote:
> According to eDP spec, sink can required specific selective update
> granularity that source must comply.
> Here caching the value if required and checking source supports it.
>
> Cc: Rodrigo Vivi
> Cc: Dhinakaran Pandiyan
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #28 from Robert Strube ---
Quick update:
I heard back from the ACPI BIOS kernel developers (see:
https://bugzilla.kernel.org/show_bug.cgi?id=201527) and they seem to imply that
the PCI resource issues showing up in the dmseg log
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #52 from tempel.jul...@gmail.com ---
It still flickers with 4.21-wip build including this patch.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel
On Thu, Nov 29, 2018 at 10:42 AM Daniel Vetter wrote:
>
> Sending the exact same hotplug event is not great uapi. Luckily the
> only already merged implementation of leases (in the -modesetting
> driver) doesn't care about what kind of uevent it gets, and
> unconditionally processes both hotplug
On Mon, Nov 26, 2018 at 04:37:06PM -0800, José Roberto de Souza wrote:
> Source is required to comply to sink SU granularity when
> DP_PSR2_SU_GRANULARITY_REQUIRED is set in DP_PSR_CAPS,
> so adding the register here.
>
> Cc: Dhinakaran Pandiyan
> Cc: Rodrigo Vivi
> Signed-off-by: José Roberto
On Tue, Nov 20, 2018 at 02:04:14PM -0800, Jeykumar Sankaran wrote:
> On 2018-11-07 07:55, Sean Paul wrote:
> > On Tue, Nov 06, 2018 at 02:36:30PM -0800, Jeykumar Sankaran wrote:
> > > msm maintains a separate structure to define vblank
> > > work definitions and a list to track events submitted
>
On Mon, Nov 26, 2018 at 04:37:05PM -0800, José Roberto de Souza wrote:
> For ICL the bit 12 of CHICKEN_TRANS is reserved so we should not
> touch it and as by default VSC_DATA_SEL_SOFTWARE_CONTROL is already
> unset in gen10 + GLK we can just drop it and fix for both gens.
>
> Cc: Dhinakaran
On Mon, Nov 26, 2018 at 04:37:04PM -0800, José Roberto de Souza wrote:
> eDP spec states 2 different bits to enable sink to trigger a
> interruption when there is a CRC mismatch.
> DP_PSR_CRC_VERIFICATION is for PSR only and
> DP_PSR_IRQ_HPD_WITH_CRC_ERRORS is for PSR2 only.
>
> Cc: Dhinakaran
Ville Syrjälä wrote:
> On Wed, Nov 28, 2018 at 10:38:10PM -0800, Kevin Strasser wrote:
>> This series defines new formats and adds a plane property to be used for
>> floating point framebuffer content. Implementation is then added to i915.
>>
>> I have shared an IGT branch which adds test coverage
Ville Syrjälä wrote:
> On Wed, Nov 28, 2018 at 10:38:13PM -0800, Kevin Strasser wrote:
>> 64 bpp half float formats are supported on hdr planes only and are subject
>> to the following restrictions:
>> * 90/270 rotation not supported
>> * Yf Tiling not supported
>> * Frame Buffer Compression
Ville Syrjälä wrote:
> On Wed, Nov 28, 2018 at 10:38:12PM -0800, Kevin Strasser wrote:
>> Add an optional property to allow applications to indicate what range their
>> floating point pixel data is normalized to. Drivers are free to choose what
>> ranges they want to support and can attach this
Ville Syrjälä wrote:
> On Wed, Nov 28, 2018 at 10:38:11PM -0800, Kevin Strasser wrote:
>> + { .format = DRM_FORMAT_XRGB16161616H, .depth = 48,
>> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_fp = true },
>> + { .format = DRM_FORMAT_XBGR16161616H,
https://bugs.freedesktop.org/show_bug.cgi?id=108753
--- Comment #7 from baracl...@gmail.com ---
Well, I'm having trouble compiling a bootable kernel v4.15, so I can't pinpoint
it excactly. The last kernel that shows the error that I was able to compile
was 4.16 and the last good kernel without
Hi all,
On Thu, 29 Nov 2018 09:09:25 -0800 Randy Dunlap wrote:
>
> on i386:
>
> 248 "multiple definition of ...". E.g.:
>
> LD [M] drivers/gpu/drm/i915/i915.o
> ld: drivers/gpu/drm/i915/i915_irq.o: in function `intel_opregion_resume':
> i915_irq.c:(.text+0x58f0): multiple definition of
pushed the latest version of this series
(https://patchwork.freedesktop.org/series/53184/) and
first 5 from https://patchwork.freedesktop.org/series/53113/ to dinq
Thanks for the patches and reviews!
Manasi
On Tue, Nov 20, 2018 at 10:37:13AM -0800, Manasi Navare wrote:
> This patch series
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #51 from Alex Deucher ---
Does this patch help?
https://patchwork.freedesktop.org/patch/264781/
or this patch for older kernels:
https://bugs.freedesktop.org/attachment.cgi?id=142660
--
You are receiving this mail because:
You are
https://bugs.freedesktop.org/show_bug.cgi?id=96868
--- Comment #36 from Alex Deucher ---
Created attachment 142660
--> https://bugs.freedesktop.org/attachment.cgi?id=142660=edit
possible fix
Does this patch help?
https://patchwork.freedesktop.org/patch/264781/
Attached is a backport to older
From: Sean Paul
Kbuild was complaining about:
>> drivers/gpu/drm/drm_atomic_helper.c:3169:27: warning: 'state' may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
Now state can't actually be used uninitialized, but we'll assign a value
anyways so it stops bellyaching.
Fixes:
On Thu, Nov 29, 2018 at 02:58:33PM -0500, Sean Paul wrote:
> From: Sean Paul
>
> We should also get the drivers using the helpers. Seems like a good
> intermediate TODO item.
>
> Changes in v2:
> - Add line about replacing drm_modest_lock_all() (Daniel)
>
> Acked-by: Daniel Vetter
Pushed
https://bugs.freedesktop.org/show_bug.cgi?id=108907
Bug ID: 108907
Summary: Display corruption on multi-monitor when the largest
panel is not on the left (and amdgpu.dc=1)
Product: DRI
Version: unspecified
Hardware: x86-64
On 29/11/2018 19:57, Tomasz Figa wrote:
On Thu, Nov 29, 2018 at 11:40 AM Jordan Crouse wrote:
On Thu, Nov 29, 2018 at 01:48:15PM -0500, Rob Clark wrote:
On Thu, Nov 29, 2018 at 10:54 AM Christoph Hellwig wrote:
On Thu, Nov 29, 2018 at 09:42:50AM -0500, Rob Clark wrote:
Maybe the thing we
From: Sean Paul
We should also get the drivers using the helpers. Seems like a good
intermediate TODO item.
Changes in v2:
- Add line about replacing drm_modest_lock_all() (Daniel)
Acked-by: Daniel Vetter
Signed-off-by: Sean Paul
---
Documentation/gpu/todo.rst | 15 +++
1 file
On Thu, Nov 29, 2018 at 11:40 AM Jordan Crouse wrote:
>
> On Thu, Nov 29, 2018 at 01:48:15PM -0500, Rob Clark wrote:
> > On Thu, Nov 29, 2018 at 10:54 AM Christoph Hellwig wrote:
> > >
> > > On Thu, Nov 29, 2018 at 09:42:50AM -0500, Rob Clark wrote:
> > > > Maybe the thing we need to do is just
From: Sean Paul
Fixes the following sphinx warnings:
../drivers/gpu/drm/drm_dp_helper.c:1362: warning: Function parameter or member
'dsc_dpcd' not described in 'drm_dp_dsc_sink_max_slice_count'
../drivers/gpu/drm/drm_dp_helper.c:1362: warning: Function parameter or member
'is_edp' not
On Thu, Nov 29, 2018 at 01:48:15PM -0500, Rob Clark wrote:
> On Thu, Nov 29, 2018 at 10:54 AM Christoph Hellwig wrote:
> >
> > On Thu, Nov 29, 2018 at 09:42:50AM -0500, Rob Clark wrote:
> > > Maybe the thing we need to do is just implement a blacklist of
> > > compatible strings for devices which
On Wed, Nov 28, 2018 at 10:38:10PM -0800, Kevin Strasser wrote:
> This series defines new formats and adds a plane property to be used for
> floating point framebuffer content. Implementation is then added to i915.
>
> I have shared an IGT branch which adds test coverage for the new formats:
>
https://bugs.freedesktop.org/show_bug.cgi?id=108891
--- Comment #5 from Casey Bowman ---
(In reply to Chris Wilson from comment #4)
> Just a very misleading bisect.
Agreed, the commit found would probably just cause the gem -hang tests to fail
in the kernel we're using as you mentioned earlier.
On Thu, 2018-11-29 at 13:09 +0200, Stanislav Lisovskiy wrote:
> Currently kernel might allocate different connector ids
> for the same outputs in case of DP MST, which seems to
> confuse userspace. There are can be different connector
> ids in the list, which could be assigned to the same
>
On Thu, Nov 29, 2018 at 12:24 PM Tomasz Figa wrote:
>
> [CC Marek]
>
> On Thu, Nov 29, 2018 at 9:09 AM Daniel Vetter wrote:
> >
> > On Thu, Nov 29, 2018 at 5:57 PM Christoph Hellwig wrote:
> > >
> > > Note that one thing I'd like to avoid is exposing these funtions directly
> > > to drivers, as
On Wed, Nov 28, 2018 at 10:38:13PM -0800, Kevin Strasser wrote:
> 64 bpp half float formats are supported on hdr planes only and are subject
> to the following restrictions:
> * 90/270 rotation not supported
> * Yf Tiling not supported
> * Frame Buffer Compression not supported
> * Color
On Thu, Nov 29, 2018 at 9:51 AM Logan Gunthorpe wrote:
>
>
>
> On 2018-11-29 10:30 a.m., Dan Williams wrote:
> > Oh! Yes, nice find. We need to wait for the percpu-ref to be dead and
> > all outstanding references dropped before we can proceed to
> > arch_remove_memory(), and I think this problem
On Thu, Nov 29, 2018 at 10:54 AM Christoph Hellwig wrote:
>
> On Thu, Nov 29, 2018 at 09:42:50AM -0500, Rob Clark wrote:
> > Maybe the thing we need to do is just implement a blacklist of
> > compatible strings for devices which should skip the automatic
> > iommu/dma hookup. Maybe a bit ugly,
On Wed, Nov 28, 2018 at 10:38:12PM -0800, Kevin Strasser wrote:
> Add an optional property to allow applications to indicate what range their
> floating point pixel data is normalized to. Drivers are free to choose what
> ranges they want to support and can attach this property to each plane that
On Thu, Nov 29, 2018 at 10:53 AM Christoph Hellwig wrote:
>
> On Thu, Nov 29, 2018 at 09:25:43AM -0500, Rob Clark wrote:
> > > As I told you before: hell no. If you spent the slightest amount of
> > > actually trying to understand what you are doing here you'd know this
> > > can't work. Just
On Wed, Nov 28, 2018 at 10:38:11PM -0800, Kevin Strasser wrote:
> Add 64 bpp 16:16:16:16 half float pixel formats. Each 16 bit component is
> formatted in IEEE-754 half-precision float (binary16) 1:5:10
> MSb-sign:exponent:fraction form.
>
> An 'is_fp' attribute is added to drm_format_info so
On Wed, Nov 28, 2018 at 5:12 PM Daniel Vetter wrote:
>
> When everyone implements it exactly the same way, among all 4
> implementations, there's not really a need to overwrite this at all.
>
> Aside: drm_kms_helper_hotplug_event is pretty much core functionality
> at this point. Probably should
On Thu, Nov 29, 2018 at 05:33:03PM +, Brian Starkey wrote:
> This sounds very useful for ion, to avoid CPU cache maintenance as
> long as the buffer stays in device-land.
>
> One question though: How would you determine "the last user to unmap"
> to know when to do the final "make visible to
On Thu, Nov 29, 2018 at 09:24:17AM -0800, Tomasz Figa wrote:
> Whether the cache maintenance operation needs to actually do anything
> or not is a function of `dev`. We can have some devices that are
> coherent with CPU caches, and some that are not, on the same system.
Yes, but that part is not
On Thu, Nov 29, 2018 at 06:09:05PM +0100, Daniel Vetter wrote:
> What kind of abuse do you expect? It could very well be that gpu folks
> call that "standard use case" ... At least on x86 with the i915 driver
> we pretty much rely on architectural guarantees for how cache flushes
> work very much.
1 - 100 of 252 matches
Mail list logo
