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
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
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
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
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:
> > > >
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
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
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
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
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
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/hfi1/user_pages.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/hfi1/user_pages.
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
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:
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
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._
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=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 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
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
https://bugs.freedesktop.org/show_bug.cgi?id=109650
Dieter Nützel changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
You are receiving this mail
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
--- 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.
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
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
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 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
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.__
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 #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
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
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
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
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
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:
> > > >
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
>
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: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 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 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 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 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 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 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
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 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
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 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/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
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 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
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 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 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
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 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 wrote:
> > > >
> > > > From: Jérôme Glisse
> > > >
> > > > Since last
On 2/19/19 9:21 AM, John Stultz wrote:
On Mon, Feb 18, 2019 at 3:51 AM Brian Starkey wrote:
On Fri, Feb 15, 2019 at 12:24:08PM -0800, 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 rabi
On Tue, Feb 19, 2019 at 12:41 PM Jason Gunthorpe wrote:
>
> On Tue, Feb 19, 2019 at 03:30:33PM -0500, 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 wrote:
> > > >
> > > > From: Jérôme Glisse
> > > >
> > > > Since las
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 version interface.
Cc: Laura Abbott
Cc: Sumit Semwal
Cc: Liam Mark
Cc:
On 2/15/19 11:01 AM, John Stultz wrote:
On Fri, Feb 15, 2019 at 2:51 AM Brian Starkey wrote:
Hi John,
On Thu, Feb 14, 2019 at 09:38:29AM -0800, John Stultz wrote:
[snip]
Some thoughts, as this ABI break has the potential to be pretty painful.
1) Unfortunately, this ABI is exposed *throu
On Thu, Jan 24, 2019 at 10:45:04AM +0100, Daniel Vetter wrote:
> On Thu, Jan 24, 2019 at 09:56:51AM +1300, Christopher James Halse Rogers
> wrote:
> > On 24 January 2019 6:18:32 am NZDT, Emil Velikov
> > wrote:
> > >On Wed, 23 Jan 2019 at 04:39, Christopher James Halse Rogers
> > > 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 wrote:
> > >
> > > From: Jérôme Glisse
> > >
> > > Since last version [4] i added the extra bits needed for the change_pte
> > > optimizati
https://bugs.freedesktop.org/show_bug.cgi?id=109206
--- Comment #15 from Harry Wentland ---
Can you see if this patch fixes it:
https://patchwork.freedesktop.org/patch/277181/
--
You are receiving this mail because:
You are the assignee for the bug.__
On Tue, Feb 19, 2019 at 12:15:55PM -0800, Dan Williams wrote:
> On Tue, Feb 19, 2019 at 12:04 PM wrote:
> >
> > From: Jérôme Glisse
> >
> > Since last version [4] i added the extra bits needed for the change_pte
> > optimization (which is a KSM thing). Here i am not posting users of
> > this, the
On Tue, Feb 19, 2019 at 12:04 PM wrote:
>
> From: Jérôme Glisse
>
> Since last version [4] i added the extra bits needed for the change_pte
> optimization (which is a KSM thing). Here i am not posting users of
> this, they will be posted to the appropriate sub-systems (KVM, GPU,
> RDMA, ...) once
On 2/19/19 1:51 PM, Alex Deucher wrote:
> On Tue, Feb 19, 2019 at 1:55 PM Gustavo A. R. Silva
> wrote:
>>
>> One of the more common cases of allocation size calculations is finding
>> the size of a structure that has a zero-sized array at the end, along
>> with memory for some number of elements
From: Jérôme Glisse
When notifying change for a range use MMU_NOTIFIER_USE_CHANGE_PTE flag
for page table update that use set_pte_at_notify() and where the we are
going either from read and write to read only with same pfn or read only
to read and write with new pfn.
Note that set_pte_at_notify(
From: Jérôme Glisse
Helper to test if a range is updated to read only (it is still valid
to read from the range). This is useful for device driver or anyone
who wish to optimize out update when they know that they already have
the range map read only.
Signed-off-by: Jérôme Glisse
Cc: Christian
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 p
From: Jérôme Glisse
Use the mmu_notifier_range_blockable() helper function instead of
directly dereferencing the range->blockable field. This is done to
make it easier to change the mmu_notifier range field.
This patch is the outcome of the following coccinelle patch:
%<
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,
...).
This patch introduce a set of enums that can be asso
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 p
From: Jérôme Glisse
Since last version [4] i added the extra bits needed for the change_pte
optimization (which is a KSM thing). Here i am not posting users of
this, they will be posted to the appropriate sub-systems (KVM, GPU,
RDMA, ...) once this serie get upstream. If you want to look at users
From: Jérôme Glisse
This update each existing invalidation to use the correct mmu notifier
event that represent what is happening to the CPU page table. See the
patch which introduced the events to see the rational behind this.
Signed-off-by: Jérôme Glisse
Cc: Christian König
Cc: Joonas Lahtin
From: Jérôme Glisse
Simple helpers to test if range invalidation is blockable. Latter
patches use cocinnelle to convert all direct dereference of range->
blockable to use this function instead so that we can convert the
blockable field to an unsigned for more flags.
Signed-off-by: Jérôme Glisse
From: Jérôme Glisse
Use an unsigned field for flags other than blockable and convert
the blockable field to be one of those flags.
Signed-off-by: Jérôme Glisse
Cc: Christian König
Cc: Joonas Lahtinen
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Jan Kara
Cc: Andrea Arcangeli
Cc: Peter Xu
Cc: Feli
On Tue, Feb 19, 2019 at 1:55 PM Gustavo A. R. Silva
wrote:
>
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
>
https://bugs.freedesktop.org/show_bug.cgi?id=109206
--- Comment #14 from Harry Wentland ---
I'd recommend updating the System BIOS.
Early BIOSes on HP Envy x360 (and possibly other Raven laptops) had trouble
loading the DMCU FW.
--
You are receiving this mail because:
You are the assignee for
https://bugzilla.kernel.org/show_bug.cgi?id=202537
--- Comment #22 from Paul Menzel (pmenzel+bugzilla.kernel@molgen.mpg.de) ---
Ok, being back at the system after some days, I see the kmemleaks are still
present with Linux 5.0-rc6+.
Bernd, what triggers this on your system? What is your test
https://bugs.freedesktop.org/show_bug.cgi?id=109679
Easwar Hariharan changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop |stuart.summ...@intel.com
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
struct boo entry[];
};
size = sizeof(struct foo) + cou
Currently the IOMMU code calls pm_runtime_get/put on the GPU or display
device before doing a IOMMU operation. This was because usually the
IOMMU driver didn't do power control of its own and since the hardware
used the same clocks and power as the respective multimedia device it
was a easy way to
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
struct boo entry[];
};
size = sizeof(struct foo) + cou
(Resend since there was a compile error that I forgot to commit before sending)
If there is a error while doing a copy_from_user() for MSM_INFO_SET_NAME
make sure to truncate the object name so that there isn't a chance that
we'll have random data in the string.
This is on top of [1] reported and
If there is a error while doing a copy_from_user() for MSM_INFO_SET_NAME
make sure to truncate the object name so that there isn't a chance that
we'll have random data in the string.
This is on top of [1] reported and fixed by Dan Carpenter.
[1] https://patchwork.freedesktop.org/series/56656/
Fi
https://bugs.freedesktop.org/show_bug.cgi?id=109679
--- Comment #4 from Stuart Summers ---
Sent that previous comment a little too quickly... It looks like we aren't
actually sending those 0's in the first place, in addition to my off-by-one
(given we are taking 0 - 1, not 0) miss:
(w && h) ? "
https://bugs.freedesktop.org/show_bug.cgi?id=109679
--- Comment #3 from Stuart Summers ---
Agree this looks like an issue in IGT or possibly in the chameleond daemon. At
a quick glance, there aren't a whole lot of places in the CaptureVideo path
that might trigger this exception in chameleond. It
On Tue, Feb 19, 2019 at 09:36:14AM -0800, Rodrigo Vivi wrote:
> On Mon, Feb 18, 2019 at 04:54:34PM +1100, Jonathan Gray wrote:
> > Compared to linux and libdrm Mesa is missing a VLV and ICL id.
> >
> > 0x0f30
> > ff049b6ce21d2814451afd4a116d001712e0116b
> > drm/i915: bind driver to ValleyView chip
On Mon, Feb 18, 2019 at 04:54:34PM +1100, Jonathan Gray wrote:
> Compared to linux and libdrm Mesa is missing a VLV and ICL id.
>
> 0x0f30
> ff049b6ce21d2814451afd4a116d001712e0116b
> drm/i915: bind driver to ValleyView chipsets
>
> 0x8A70
> d55cb4fa2cf0105bfb16b60a2846737b91fdc173
> drm/i915/icl
https://bugzilla.kernel.org/show_bug.cgi?id=201273
--- Comment #35 from quirin.blae...@freenet.de ---
Bug is still alive. v4.20.9
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lis
On Mon, Feb 18, 2019 at 3:51 AM Brian Starkey wrote:
> On Fri, Feb 15, 2019 at 12:24:08PM -0800, 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
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:
Another good question is also why the heck the acc_size counts
tow
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:
> > > > On Tue, Feb 19, 2019 at 12:57 PM Emil Velikov
> > > > w
This patch attaches the colorspace connector property to the
hdmi connector. Based on colorspace change, modeset will be
triggered to switch to new colorspace.
Based on colorspace property value create an infoframe
with appropriate colorspace. This can be used to send an
infoframe packet with prop
This adds colorspace information to HDMI AVI infoframe.
A helper function is added to program the same.
v2: Moved this to drm core instead of i915 driver.
v3: Exported the helper function.
v4: Added separate HDMI specific macro as per CTA spec.
This is separate from user exposed enum values. Thi
Create a new connector property to program colorspace to sink
devices. Modern sink devices support more than 1 type of
colorspace like 601, 709, BT2020 etc. This helps to switch
based on content type which is to be displayed. The decision
lies with compositors as to in which scenarios, a particular
This patch series creates a new connector property to program
colorspace to sink devices. Modern sink devices support more
than 1 type of colorspace like 601, 709, BT2020 etc. This helps
to switch based on content type which is to be displayed. The
decision lies with compositors as to in which scen
1 - 100 of 158 matches
Mail list logo
