https://bugzilla.kernel.org/show_bug.cgi?id=202537
--- Comment #23 from Bernd Steinhauser (li...@bernd-steinhauser.de) ---
(In reply to Paul Menzel from comment #22)
> Bernd, what triggers this on your system? What is your test case? Start some
> program?
basically start the system, log in, ensuri
On 2/15/19 12:24 PM, John Stultz wrote:
The per-device heaps don't support HEAP_QUERY ioctl, since
the name is provided in the devnode path and the heapid isn't
useful with the new interface (one uses the fd of heapdevice).
But, one missing bit of functionality is a way to find the
heap type. So
On 2/15/19 12:24 PM, John Stultz wrote:
One of the issues w/ the /dev/ion interface is that we have to
provide the complexity of a heap query interface and we end up
multiplexing all the heap access through that one interface via
a bit mask (which currently limits the heaps to 32).
There has bee
On 1/31/19 10:59 PM, Qing Xia wrote:
In the first loop, gfp_flags will be modified to high_order_gfp_flags,
and there will be no chance to change back to low_order_gfp_flags.
Fixes: e7f63771 ("ION: Sys_heap: Add cached pool to spead up cached buffer
alloc")
Signed-off-by: Qing Xia
---
driver
On Tue, Feb 19, 2019 at 12:58 PM Jerome Glisse wrote:
>
> On Tue, Feb 19, 2019 at 12:40:37PM -0800, Dan Williams wrote:
> > On Tue, Feb 19, 2019 at 12:30 PM Jerome Glisse wrote:
> > >
> > > On Tue, Feb 19, 2019 at 12:15:55PM -0800, Dan Williams wrote:
> > > > On Tue, Feb 19, 2019 at 12:04 PM wro
https://bugs.freedesktop.org/show_bug.cgi?id=108514
--- Comment #32 from Paul Dufresne ---
Created attachment 143413
--> https://bugs.freedesktop.org/attachment.cgi?id=143413&action=edit
patch radeon-display.c for latest kernel (5.0.0-rc7)
--
You are receiving this mail because:
You are the a
On 2/15/19 12:24 PM, John Stultz wrote:
This is a *very early RFC* (it builds, that's all I'll say :)
but I wanted to share it to get some initial feedback before I
go down the rabit hole of trying to adapt the Android userland
code to get this fully validated.
This patchset tries to implement t
On Tue, Feb 19, 2019 at 12:46 PM Laura Abbott wrote:
>
> On 2/15/19 12:24 PM, John Stultz wrote:
> > With all the slight interface changes ion has had
> > through its time in staging, keeping userland working
> > properly has been a pain. Assuming more churn going
> > forward, provide a proper ver
On 2/19/19 3:25 PM, Laura Abbott wrote:
> On 2/15/19 12:24 PM, John Stultz wrote:
>> This is a *very early RFC* (it builds, that's all I'll say :)
>> but I wanted to share it to get some initial feedback before I
>> go down the rabit hole of trying to adapt the Android userland
>> code to get this
On Tue, Feb 19, 2019 at 01:19:09PM -0800, Dan Williams wrote:
> On Tue, Feb 19, 2019 at 12:58 PM Jerome Glisse wrote:
> >
> > On Tue, Feb 19, 2019 at 12:40:37PM -0800, Dan Williams wrote:
> > > On Tue, Feb 19, 2019 at 12:30 PM Jerome Glisse wrote:
> > > >
> > > > On Tue, Feb 19, 2019 at 12:15:55P
https://bugs.freedesktop.org/show_bug.cgi?id=109073
--- Comment #10 from Utku Helvacı (tuxutku) ---
hey i have opened a bug report here:
https://bugzilla.kernel.org/show_bug.cgi?id=201077
and i want to let you know that you can use 4.16 or 4.15 kernels for temporary
solution and all the people ef
On Tue, Feb 19, 2019 at 6:54 AM Rob Herring wrote:
> > I believe using eDP connector binding wouldn't help much in my case
> > and it won't improve accuracy of hardware description while adding
> > unnecessary code duplication (edp-connector will be pretty much
> > simple-panel).
> >
> > Since cu
On Tue, Feb 19, 2019 at 1:17 PM Laura Abbott wrote:
>
> On 2/15/19 12:24 PM, John Stultz wrote:
> > One of the issues w/ the /dev/ion interface is that we have to
> > provide the complexity of a heap query interface and we end up
> > multiplexing all the heap access through that one interface via
On 1/24/19 8:44 AM, Brian Starkey wrote:
On Thu, Jan 24, 2019 at 10:04:46AM -0600, Andrew F. Davis wrote:
On 1/23/19 11:11 AM, Brian Starkey wrote:
[snip]
I'm very new to all this, so any pointers to history in this area are
appreciated.
[snip]
In case you didn't come across it alrea
On 2/19/19 3:13 PM, Laura Abbott wrote:
> On 2/15/19 12:24 PM, John Stultz wrote:
>> The per-device heaps don't support HEAP_QUERY ioctl, since
>> the name is provided in the devnode path and the heapid isn't
>> useful with the new interface (one uses the fd of heapdevice).
>>
>> But, one missing b
On 2/19/19 1:39 PM, Andrew F. Davis wrote:
On 2/19/19 3:13 PM, Laura Abbott wrote:
On 2/15/19 12:24 PM, John Stultz wrote:
The per-device heaps don't support HEAP_QUERY ioctl, since
the name is provided in the devnode path and the heapid isn't
useful with the new interface (one uses the fd of h
On Tue, Feb 19, 2019 at 1:13 PM Laura Abbott wrote:
>
> On 2/15/19 12:24 PM, John Stultz wrote:
> > The per-device heaps don't support HEAP_QUERY ioctl, since
> > the name is provided in the devnode path and the heapid isn't
> > useful with the new interface (one uses the fd of heapdevice).
> >
>
On Tue, Feb 19, 2019 at 1:46 PM Laura Abbott wrote:
>
> On 2/19/19 1:39 PM, Andrew F. Davis wrote:
> > On 2/19/19 3:13 PM, Laura Abbott wrote:
> >> On 2/15/19 12:24 PM, John Stultz wrote:
> >>> The per-device heaps don't support HEAP_QUERY ioctl, since
> >>> the name is provided in the devnode pat
On 2/19/19 1:30 PM, Andrew F. Davis wrote:
On 2/19/19 3:25 PM, Laura Abbott wrote:
On 2/15/19 12:24 PM, John Stultz wrote:
This is a *very early RFC* (it builds, that's all I'll say :)
but I wanted to share it to get some initial feedback before I
go down the rabit hole of trying to adapt the A
On Tue, Feb 19, 2019 at 1:25 PM Laura Abbott wrote:
>
> On 2/15/19 12:24 PM, John Stultz wrote:
> > This is a *very early RFC* (it builds, that's all I'll say :)
> > but I wanted to share it to get some initial feedback before I
> > go down the rabit hole of trying to adapt the Android userland
>
Quoting Emil Velikov (2019-02-19 08:51:18)
> On Tue, 19 Feb 2019 at 15:36, Dylan Baker wrote:
> >
> > Quoting Daniel Vetter (2019-02-19 07:20:12)
> > > On Tue, Feb 19, 2019 at 3:02 PM Eric Engestrom
> > > wrote:
> > > >
> > > > On Tuesday, 2019-02-19 13:53:25 +0100, Daniel Vetter wrote:
> > > >
Hi Dave,
Reasonably smaller this time around, but still rockin the negative diffstat.
On the display side, cleanups and fixes to enabled modifiers
(QCOM_COMPRESSED). And otherwise mostly misc fixes all around.
There is a6xx GMU reset support pending, but looks like a bit more
discussion about d
On Fri, Feb 15, 2019 at 12:54 PM Stephen Boyd wrote:
>
> Quoting Brendan Higgins (2019-02-14 13:37:22)
> > diff --git a/kunit/test-test.c b/kunit/test-test.c
> > index 0b4ad6690310d..bb34431398526 100644
> > --- a/kunit/test-test.c
> > +++ b/kunit/test-test.c
> [...]
> > +
> > +#define KUNIT_RESOU
On Fri, Feb 15, 2019 at 1:01 PM Stephen Boyd wrote:
>
> Quoting Brendan Higgins (2019-02-14 13:37:14)
> > @@ -104,6 +167,7 @@ struct kunit {
> > const char *name; /* Read only after initialization! */
> > spinlock_t lock; /* Gaurds all mutable test state. */
> > bool succes
Hey Dave,
Various fixes/cleanups, along with initial support for SVM features
utilising HMM address-space mirroring and device memory migration.
There's a lot more work to do in these areas, both in terms of
features and efficiency, but these can slowly trickle in later down
the track.
Jerome and
https://bugs.freedesktop.org/show_bug.cgi?id=109102
--- Comment #5 from Gert vd Kraats ---
Some more investigation, understanding and adding 2 other possible fixes for
the problem.
The problem occurs at Ubuntu 18.10 only at gdm3 with wayland using dual
monitor.
It is not occuring with wayland at
https://bugs.freedesktop.org/show_bug.cgi?id=109102
--- Comment #6 from Gert vd Kraats ---
Created attachment 143414
--> https://bugs.freedesktop.org/attachment.cgi?id=143414&action=edit
fix intel_blit.c
fix error_patch2
--
You are receiving this mail because:
You are the assignee for the bu
https://bugs.freedesktop.org/show_bug.cgi?id=109102
--- Comment #7 from Gert vd Kraats ---
Created attachment 143415
--> https://bugs.freedesktop.org/attachment.cgi?id=143415&action=edit
libdrm_ignore_deadlock
--
You are receiving this mail because:
You are the assignee for the bug.__
Add support for Rec.709 encoding and inverse encoding.
The determination of the CSC coefficients based on the input/output
colorspace parameters are moved to a new function calc_csc_coeffs().
Reported-by: Tim Harvey
Signed-off-by: Steve Longerbeam
---
Changes in v5:
- moved API changes to a pre
The saturation bit was being set at bit 9 in the second 32-bit word
of the TPMEM CSC. This isn't correct, the saturation bit is bit 42,
which is bit 10 of the second word.
Fixes: 1aa8ea0d2bd5d ("gpu: ipu-v3: Add Image Converter unit")
Signed-off-by: Steve Longerbeam
Cc: sta...@vger.kernel.org
--
Only providing the input and output RGB/YUV space to the IC task init
functions is not sufficient. To fully characterize a colorspace
conversion, the colorspace (chromaticities), Y'CbCr encoding standard,
and quantization also need to be specified.
Define a 'struct ipu_ic_colorspace' that includes
Add support for the following conversions:
- YUV full-range to YUV limited-range
- YUV limited-range to YUV full-range
- YUV limited-range to RGB full-range
- RGB full-range to YUV limited-range
The last two conversions require operating on the YUV full-range
encoding and inverse encoding coeffic
The ycbcr2rgb and inverse rgb2ycbcr tables define the BT.601 Y'CbCr
encoding coefficients.
The rgb2ycbcr table specifically describes the BT.601 encoding from
full range RGB to full range YUV. Add table comments to make this more
clear.
The ycbcr2rgb inverse table describes encoding YUV limited r
Hi all,
Commits
f180bf12ac06 ("drm/nouveau/svm: new ioctl to migrate process memory to GPU
memory")
5be73b690875 ("drm/nouveau/dmem: device memory helpers for SVM")
are missing a Signed-off-by from their committer.
--
Cheers,
Stephen Rothwell
pgp3r2RUZ_x6N.pgp
Description: OpenPGP digit
https://bugs.freedesktop.org/show_bug.cgi?id=109650
--- Comment #2 from Alex Deucher ---
Patch reverted.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.
https://bugs.freedesktop.org/show_bug.cgi?id=109650
Dieter Nützel changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=109650
Dieter Nützel changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
You are receiving this mail
On Fri, Feb 15, 2019 at 4:24 PM Frank Rowand wrote:
>
> On 2/14/19 1:37 PM, Brendan Higgins wrote:
> > Migrate tests without any cleanup, or modifying test logic in anyway to
> > run under KUnit using the KUnit expectation and assertion API.
> >
> > Signed-off-by: Brendan Higgins
> > ---
> > dri
On Mon, Feb 18, 2019 at 11:52 AM Frank Rowand wrote:
>
> On 2/14/19 1:37 PM, Brendan Higgins wrote:
> > Add support for aborting/bailing out of test cases. Needed for
> > implementing assertions.
> >
> > Signed-off-by: Brendan Higgins
> > ---
> > Changes Since Last Version
> > - This patch is ne
https://bugs.freedesktop.org/show_bug.cgi?id=109561
--- Comment #7 from Marek Olšák ---
The fix doesn't apply to master. Also, it would be nice to get it into 19.0
before it's released. (originally it should have been released today)
--
You are receiving this mail because:
You are the assignee
On 2019年02月19日 19:32, Koenig, Christian wrote:
Hi David,
Could you have a look if it's reasonable?
Patch #1 is also something I already fixed on my local branch.
But patch #2 won't work like this.
We can't return an error from drm_syncobj_add_point() because we
already submitted work to
https://bugs.freedesktop.org/show_bug.cgi?id=109206
--- Comment #16 from Matrix ---
Is it possible to upgrade the Bios from Linux? I think it's just a windows-only
bios upgrade from HP right? Will it work in Freedos?
--
You are receiving this mail because:
You are the assignee for the bug._
Hi,
ping?
... to the dc folks?
best
Mathias
On Wednesday, 13 February 2019 21:38:03 CET Alex Deucher wrote:
> Add amd-gfx and some DC people.
>
> Alex
>
> On Sun, Feb 10, 2019 at 5:13 AM wrote:
> >
> > From: Mathias Fröhlich
> >
> > Reference counting in amdgpu_dm_connector for amdgpu_dm_con
From: Ira Weiny
Resending these as I had only 1 minor comment which I believe we have covered
in this series. I was anticipating these going through the mm tree as they
depend on a cleanup patch there and the IB changes are very minor. But they
could just as well go through the IB tree.
NOTE:
From: Ira Weiny
Use the new FOLL_LONGTERM to get_user_pages_fast() to protect against
FS DAX pages being mapped.
Signed-off-by: Ira Weiny
---
drivers/infiniband/hw/mthca/mthca_memfree.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/mthca/mthca_memf
From: Ira Weiny
Use the new FOLL_LONGTERM to get_user_pages_fast() to protect against
FS DAX pages being mapped.
Signed-off-by: Ira Weiny
---
drivers/infiniband/hw/hfi1/user_pages.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/hfi1/user_pages.
From: Ira Weiny
In order to support more options in the GUP fast walk, change
the write parameter to flags throughout the call stack.
This patch does not change functionality and passes FOLL_WRITE
where write was previously used.
Signed-off-by: Ira Weiny
---
mm/gup.c | 52
From: Ira Weiny
Use the new FOLL_LONGTERM to get_user_pages_fast() to protect against
FS DAX pages being mapped.
Signed-off-by: Ira Weiny
---
drivers/infiniband/hw/qib/qib_user_sdma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/qib/qib_user_sdma.c
From: Ira Weiny
DAX pages were previously unprotected from longterm pins when users
called get_user_pages_fast().
Use the new FOLL_LONGTERM flag to check for DEVMAP pages and fall
back to regular GUP processing if a DEVMAP page is encountered.
Signed-off-by: Ira Weiny
---
mm/gup.c | 24 ++
From: Ira Weiny
To facilitate additional options to get_user_pages_fast() change the
singular write parameter to be gup_flags.
This patch does not change any functionality. New functionality will
follow in subsequent patches.
Some of the get_user_pages_fast() call sites were unchanged because
From: Ira Weiny
Rather than have a separate get_user_pages_longterm() call,
introduce FOLL_LONGTERM and change the longterm callers to use
it.
This patch does not change any functionality.
FOLL_LONGTERM can only be supported with get_user_pages() as it
requires vmas to determine if DAX is in us
Hi, Jitao:
On Tue, 2019-02-19 at 17:14 +0800, Jitao Shi wrote:
> Different IC has different mipi_tx setting of dsi.
> This patch separates the mipi_tx hardware relate part for mt8173.
>
> Signed-off-by: Jitao Shi
> ---
> drivers/gpu/drm/mediatek/Makefile | 1 +
> drivers/gpu/drm/m
On Mon, Feb 18, 2019 at 12:02 PM Frank Rowand wrote:
> I have not read through the patches in any detail. I have read some of
> the code to try to understand the patches to the devicetree unit tests.
> So that may limit how valid my comments below are.
No problem.
>
> I found the code difficul
On Tue, 2019-02-19 at 17:06 +, Kuehling, Felix wrote:
> On 2019-02-18 3:39 p.m., Thomas Hellstrom wrote:
> > On Mon, 2019-02-18 at 18:07 +0100, Christian König wrote:
> > > Am 18.02.19 um 10:47 schrieb Thomas Hellstrom:
> > > > On Mon, 2019-02-18 at 09:20 +, Koenig, Christian wrote:
> > > >
Hi all,
After merging the akpm-current tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/nouveau/nouveau_dmem.c:299:11: error: initialization of
'vm_fault_t (*)(struct hmm_devmem *, struct vm_area_struct *, long unsigned
int, const struct page *, unsigned i
Ping ..
>-Original Message-
>From: amd-gfx On Behalf Of Deng,
>Emily
>Sent: Monday, February 18, 2019 10:17 AM
>To: Alex Deucher ; Maling list - DRI developers de...@lists.freedesktop.org>
>Cc: amd-gfx list
>Subject: RE: [PATCH libdrm] libdrm: Fix issue about differrent domainID but
The Rockchip RK3288 SoC (v2.00a) and RK3328/RK3399 SoCs (v2.11a) have
also been identified as needing this workaround with a single iteration.
Fixes: be41fc55f1aa ("drm: bridge: dw-hdmi: Handle overflow workaround based on
device version")
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/bridge
Am 20.02.19 um 05:53 schrieb zhoucm1:
On 2019年02月19日 19:32, Koenig, Christian wrote:
Hi David,
Could you have a look if it's reasonable?
Patch #1 is also something I already fixed on my local branch.
But patch #2 won't work like this.
We can't return an error from drm_syncobj_add_point() beca
101 - 158 of 158 matches
Mail list logo
