Hi Peter,
> Similar things go on in:
>
> drivers/hwmon/lm90.c
> drivers/leds/leds-is31fl319x.c
> drivers/of/unittest.c
Right. I'll fix them, too.
> And drivers/rtc/rtc-fm3130.c has a couple of these:
These are fixed in patch 26 of this series.
Thanks and happy hacking,
Wolfram
signature
https://bugs.freedesktop.org/show_bug.cgi?id=110871
Bug ID: 110871
Summary: hello
Product: DRI
Version: DRI git
Hardware: Other
OS: Windows (All)
Status: NEW
Severity: normal
Priority: medium
https://bugs.freedesktop.org/show_bug.cgi?id=110871
Juby changed:
What|Removed |Added
Summary|hello |hellobugzilla
--
You are receiving this mail be
https://bugs.freedesktop.org/show_bug.cgi?id=110871
Juby changed:
What|Removed |Added
Status|NEW |ASSIGNED
--
You are receiving this mail because
We've moved the override and firmware EDID (simply "override EDID" from
now on) handling to the low level drm_do_get_edid() function in order to
transparently use the override throughout the stack. The idea is that
you get the override EDID via the ->get_modes() hook.
Unfortunately, there are scen
On Sat, 08 Jun 2019, Paul Wise wrote:
> On Sat, 2019-06-08 at 13:10 +0800, Paul Wise wrote:
>
>> I've tested these two patches on top of Linux v5.2-rc3 and the EDID
>> override works correctly on an Intel Ironlake GPU with a monitor that
>> lost its EDID a while ago.
>
> While testing I noticed a
Hi Linus,
On 2019-06-10 01:13, Linus Walleij wrote:
> This converts the Analogix display port to use GPIO descriptors
> instead of DT-extracted numbers.
>
> Cc: Douglas Anderson
> Cc: Sean Paul
> Cc: Marek Szyprowski
> Cc: Enric Balletbo i Serra
> Signed-off-by: Linus Walleij
Tested-by: Mare
On Fri, Jun 07, 2019 at 05:46:36PM +0800, Liviu Dudau wrote:
> Hi James,
>
> On Mon, May 20, 2019 at 11:44:47AM +0100, james qian wang (Arm Technology
> China) wrote:
> > To achieve same caling effect compare with none split, the texel
> > calculation need to use the same scaling ratio before spl
https://bugs.freedesktop.org/show_bug.cgi?id=110871
Andre Klapper changed:
What|Removed |Added
Component|General |Two
Product|DRI
Introduce a new component komeda_merger, because D71 HW supports to split
a whole image to two half parts and does the scaling independently. Merger
merges two separate results to one, and output it to compositor or wb_layer
For this patch:
- Add the definition of komeda_merger/merger_state
- Repor
To achieve same caling effect compare with none split, the texel
calculation need to use the same scaling ratio before split, so add
"total_xxx" to pipeline to describe the hsize/vsize before split.
Update pipeline and d71_scaler_update accordingly.
v2: Rebase and addressed Liviu's comments
Signe
This patch series add laye split support for komeda.
For layer split, a plane state will be split to two data flows and handled
by two separated komeda layer input pipelines. komeda supports two types of
layer split:
- none-scaling split:
/ layer-left -> \
plane_state
Komeda supports two types of layer split:
- none-scaling split
- scaling split
Since D71 merger only support scaler as input, so for none-scaling split,
the two layer dflow will be output to compiz directly. for scaling_split,
the data flow will be merged by merger firstly, then output the merged
d
https://bugs.freedesktop.org/show_bug.cgi?id=109607
--- Comment #13 from CI Bug Log ---
A CI Bug Log filter associated to this bug has been updated:
{- fi-kbl-7560u, fi-cfl-8109u, fi-icl-u2, fi-icl-u3: random tests - incomplete
-}
{+ fi-kbl-7560u, fi-cfl-8109u, fi-icl-u2, fi-icl-u3: random tests
https://bugs.freedesktop.org/show_bug.cgi?id=110822
b6khqjq...@ugsbm.anonbox.net changed:
What|Removed |Added
Status|NEW |RESOLVED
Resoluti
https://bugs.freedesktop.org/show_bug.cgi?id=109607
--- Comment #14 from CI Bug Log ---
A CI Bug Log filter associated to this bug has been updated:
{- fi-kbl-7560u, fi-cfl-8109u, fi-icl-u2, fi-icl-u3: random tests - incomplete
-}
{+ fi-kbl-7560u, fi-cfl-8109u, fi-icl-u2, fi-icl-u3: random tests
https://bugs.freedesktop.org/show_bug.cgi?id=110822
--- Comment #14 from b6khqjq...@ugsbm.anonbox.net ---
(In reply to b6khqjqov4 from comment #13)
> Your bug sounds like mine which came after I bought and added a used RX580
> to my system. Since then had random full system freezes (I think only w
https://bugs.freedesktop.org/show_bug.cgi?id=110822
b6khqjq...@ugsbm.anonbox.net changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
--
You are rece
https://bugs.freedesktop.org/show_bug.cgi?id=110813
--- Comment #1 from Sam ---
Related:
https://bugs.freedesktop.org/show_bug.cgi?id=109955
https://bugs.freedesktop.org/show_bug.cgi?id=102322
This seems to be a widespread issue for Vega and 4xx/5xx owners
--
You are receiving this mail beca
https://bugs.freedesktop.org/show_bug.cgi?id=110813
--- Comment #2 from Yury Zhuravlev ---
> This seems to be a widespread issue for Vega and 4xx/5xx owners
I know but looks like the trace call is different.
--
You are receiving this mail because:
You are the assignee for the bug._
On Thu, 6 Jun 2019 at 12:11, Mauro Carvalho Chehab wrote:
>
> Em Thu, 6 Jun 2019 11:46:57 +0200
> Anders Roxell escreveu:
>
> > Hi,
> >
> > This patch set addresses warnings that module names are named the
> > same, this may lead to a problem that wrong module gets loaded or if one
> > of the tw
On Thu, 6 Jun 2019 at 13:00, Mark Brown wrote:
>
> On Thu, Jun 06, 2019 at 11:47:36AM +0200, Anders Roxell wrote:
>
> > obj-$(CONFIG_REGULATOR_88PG86X) += 88pg86x.o
> > -obj-$(CONFIG_REGULATOR_88PM800) += 88pm800.o
> > +obj-$(CONFIG_REGULATOR_88PM800) += 88pm800-regulator.o
> > +88pm800-regulator
https://bugs.freedesktop.org/show_bug.cgi?id=110883
Bug ID: 110883
Summary: [Regression linux 5.2-rc4][bisected] hang on boot
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=110883
--- Comment #1 from Sibren Vasse ---
Created attachment 144492
--> https://bugs.freedesktop.org/attachment.cgi?id=144492&action=edit
dmesg
--
You are receiving this mail because:
You are the assignee for the bug._
On Thu, 6 Jun 2019 at 12:13, Hans Verkuil wrote:
>
> On 6/6/19 11:47 AM, Anders Roxell wrote:
> > When building with CONFIG_VIDEO_CODA and CONFIG_CODA_FS enabled as
> > loadable modules, we see the following warning:
> >
> > warning: same module names found:
> > fs/coda/coda.ko
> > drivers/med
https://bugs.freedesktop.org/show_bug.cgi?id=110883
--- Comment #2 from Sibren Vasse ---
Created attachment 144493
--> https://bugs.freedesktop.org/attachment.cgi?id=144493&action=edit
xorg log
--
You are receiving this mail because:
You are the assignee for the bug.__
commit c16b85559dcfb5a348cc085a7b4c75ed49b05e2c upstream.
Async update callbacks are expected to set the old_fb in the new_state
so prepare/cleanup framebuffers are balanced.
Calling drm_atomic_set_fb_for_plane() (which gets a reference of the new
fb and put the old fb) is not required, as it's t
On Wed, May 29, 2019 at 10:38 AM Tomeu Vizoso wrote:
>
> On Wed, 29 May 2019 at 15:00, Robin Murphy wrote:
> >
> > Hi Tomeu, Rob,
> >
> > On 28/05/2019 08:03, Tomeu Vizoso wrote:
> > > Robin, Steven,
> > >
> > > would you or someone else at Arm be able to run the IGT tests [0] on
> > > 5.2-rc2 wi
On 10/06/2019 14:03, Anders Roxell wrote:
> On Thu, 6 Jun 2019 at 12:13, Hans Verkuil wrote:
>>
>> On 6/6/19 11:47 AM, Anders Roxell wrote:
>>> When building with CONFIG_VIDEO_CODA and CONFIG_CODA_FS enabled as
>>> loadable modules, we see the following warning:
>>>
>>> warning: same module name
Hi Sam,
Thanks for the good catch. Actually it's a typo in email reply. It should be
'len - 1'.
Regards,
-Original Message-
From: Sam Ravnborg
Sent: Saturday, June 8, 2019 7:56 AM
To: Zhang, Dingchen (David)
Cc: dri-devel@lists.freedesktop.org; Li, Sun peng (Leo) ;
Wentland, Harry
On Wed, 29 May 2019 at 19:38, Robin Murphy wrote:
>
> On 29/05/2019 16:09, Tomeu Vizoso wrote:
> > On Tue, 21 May 2019 at 18:11, Clément Péron wrote:
> >>
> > [snip]
> >> [ 345.204813] panfrost 180.gpu: mmu irq status=1
> >> [ 345.209617] panfrost 180.gpu: Unhandled Page fault in AS0 at
commit 89a4aac0ab0e6f5eea10d7bf4869dd15c3de2cd4 upstream.
In the case of a normal sync update, the preparation of framebuffers (be
it calling drm_atomic_helper_prepare_planes() or doing setups with
drm_framebuffer_get()) are performed in the new_state and the respective
cleanups are performed in t
On 6/10/19 10:18 AM, Helen Koike wrote:
> commit c16b85559dcfb5a348cc085a7b4c75ed49b05e2c upstream.
>
> Async update callbacks are expected to set the old_fb in the new_state
> so prepare/cleanup framebuffers are balanced.
>
> Calling drm_atomic_set_fb_for_plane() (which gets a reference of the
Hi,
Correcting the tag, just for the record, is v5 of the patch.
On 6/10/19 10:36 AM, Helen Koike wrote:
> commit 89a4aac0ab0e6f5eea10d7bf4869dd15c3de2cd4 upstream.
>
> In the case of a normal sync update, the preparation of framebuffers (be
> it calling drm_atomic_helper_prepare_planes() or doi
We use delayed_work in HPD handling, and cancel any scheduled work in
tfp410_fini using cancel_delayed_work_sync(). However, we have only
initialized the delayed work if we actually have a HPD interrupt
configured in the DT, but in the tfp410_fini, we always cancel the work,
possibly causing a WARN
We don't free the edid blob allocated by the call to drm_get_edid(),
causing a memleak. Fix this by calling kfree(edid) at the end of the
get_modes().
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/bridge/ti-tfp410.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/dr
userspace may transfer a newline, and this terminating newline
is replaced by a '\0' to avoid followup issues.
'len-1' is the index to replace the newline of CRC source name.
v3: typo fix (Sam)
v2: update patch subject, body and format. (Sam)
Cc: Leo Li
Cc: Harry Wentland
Cc: Sam Ravnborg
Si
+Daniel and David
On Wed, May 29, 2019 at 3:52 AM Boris Brezillon
wrote:
>
> We plan to expose performance counters through 2 driver specific
> ioctls until there's a solution to expose them in a generic way.
> In order to be able to deprecate those ioctls when this new
> infrastructure is in pla
https://bugs.freedesktop.org/show_bug.cgi?id=110822
--- Comment #15 from Gobinda Joy ---
(In reply to b6khqjqov4 from comment #14)
> (In reply to b6khqjqov4 from comment #13)
> > Your bug sounds like mine which came after I bought and added a used RX580
> > to my system. Since then had random ful
From: Qian Cai
Booting up with DMA_API_DEBUG_SG=y generates a warning due to the driver
forgot to set dma_parms appropriately. Set it just after vmw_dma_masks()
in vmw_driver_load().
DMA-API: vmwgfx :00:0f.0: mapping sg segment longer than device
claims to support [len=2097152] [max=65536]
W
https://bugs.freedesktop.org/show_bug.cgi?id=110856
Nicholas Kazlauskas changed:
What|Removed |Added
CC||nicholas.kazlaus...@amd.com
--- C
https://bugs.freedesktop.org/show_bug.cgi?id=110822
Gobinda Joy changed:
What|Removed |Added
Status|VERIFIED|REOPENED
Resolution|WORKSFORME
On Wed, 29 May 2019 at 17:46, Hans de Goede wrote:
>
> Starting with ACPI 6.2 bits 1 and 2 of the BGRT status field are no longer
> reserved. These bits are now used to indicate if the image needs to be
> rotated before being displayed.
>
> The efifb code does not support rotating the image before
On Wed, Jun 5, 2019 at 12:49 PM Ezequiel Garcia wrote:
>
> Panfrost depends on the simple_ondemand governor, and therefore
> it's a required configuration. Select it.
>
> Fixes: f3617b449d ("drm/panfrost: Select devfreq")
> Signed-off-by: Ezequiel Garcia
> ---
> drivers/gpu/drm/panfrost/Kconfig
On Wed, Jun 5, 2019 at 9:02 AM Neil Armstrong wrote:
>
> Devfreq runtime usage was made mandatory, thus making panfrost fail to probe
> on Amlogic S912 SoCs missing the "operating-points-v2" property.
> Make it optional again, leaving PM_DEVFREQ selected by default.
>
> Fixes: f3617b449d ("drm/pan
On Wed, May 22, 2019 at 6:39 AM Steven Price wrote:
>
> On 21/05/2019 19:23, Chris Wilson wrote:
> > Quoting Rob Herring (2019-05-21 16:24:27)
> >> On Mon, May 20, 2019 at 4:23 AM Steven Price wrote:
> >>>
> >>
> >> You forgot to update the subject. I can fixup when applying, but I'd
> >> like an
On Fri, Jun 07, 2019 at 11:58:04AM -0300, Rodrigo Siqueira wrote:
> On Fri, Jun 7, 2019 at 4:48 AM Daniel Vetter wrote:
> >
> > On Thu, Jun 06, 2019 at 07:41:01PM -0300, Rodrigo Siqueira wrote:
> > > This patch implements the necessary functions to add writeback support
> > > for vkms. This featur
On Wed, May 29, 2019 at 12:51 AM Boris Brezillon
wrote:
>
> Right now, the BO is mapped as a cached region when ->vmap() is called
> and the underlying object is not a dmabuf.
> Doing that makes cache management a bit more complicated (you'd need
> to call dma_map/unmap_sg() on the ->sgt field eve
Hi Dingchen.
On Mon, Jun 10, 2019 at 09:47:51AM -0400, Dingchen Zhang wrote:
> userspace may transfer a newline, and this terminating newline
> is replaced by a '\0' to avoid followup issues.
>
> 'len-1' is the index to replace the newline of CRC source name.
>
> v3: typo fix (Sam)
>
> v2: updat
https://bugs.freedesktop.org/show_bug.cgi?id=110822
--- Comment #16 from Gobinda Joy ---
(In reply to b6khqjqov4 from comment #14)
> (In reply to b6khqjqov4 from comment #13)
> > Your bug sounds like mine which came after I bought and added a used RX580
> > to my system. Since then had random ful
In order to increase the chances of using 2MB pages, we need to align the
GPU VA mapping to 2MB. Only do this if the object size is 2MB or more.
Cc: Robin Murphy
Cc: Steven Price
Cc: Tomeu Vizoso
Signed-off-by: Rob Herring
---
drivers/gpu/drm/panfrost/panfrost_gem.c | 8 ++--
1 file chang
The midgard/bifrost GPUs need to allocate GPU memory which is allocated
on GPU page faults and not pinned in memory. The vendor driver calls
this functionality GROW_ON_GPF.
This implementation assumes that BOs allocated with the
PANFROST_BO_NOMAP flag are never mmapped or exported. Both of those m
https://bugs.freedesktop.org/show_bug.cgi?id=109955
--- Comment #30 from Sam ---
Update: I can now confirm, at least in my case, that the freezes DO occur using
the parameters above, and also with all of them (shown below), while doing
another test round on Pillars of Eternity.
amdgpu.dc=1
amdg
Hi,
updating my Pine64+ to the latest drm-misc-next today (427231bc6d5)
started giving me the BUG and Oops below. It's consistently
reproduceable. Without KASAN I still get the Oops.
I was able to bisect it to [50f9495efe308eb25fd921ea7c8c8143ddeeae30]
drm/bridge/synopsys: dw-hdmi: Add "unwedge" f
Hi,
On Mon, Jun 10, 2019 at 10:28 AM Erico Nunes wrote:
>
> Hi,
>
> updating my Pine64+ to the latest drm-misc-next today (427231bc6d5)
> started giving me the BUG and Oops below. It's consistently
> reproduceable. Without KASAN I still get the Oops.
> I was able to bisect it to [50f9495efe308eb2
In commit 50f9495efe30 ("drm/bridge/synopsys: dw-hdmi: Add "unwedge"
for ddc bus") I stupidly used IS_ERR() to check for whether we have an
"unwedge" pinctrl state even though on most flows through the driver
the unwedge state will just be NULL.
Fix it so that we consistently use NULL for no unwed
Hi,
On Mon, Jun 10, 2019 at 10:32 AM Doug Anderson wrote:
>
> Hi,
>
> On Mon, Jun 10, 2019 at 10:28 AM Erico Nunes wrote:
> >
> > Hi,
> >
> > updating my Pine64+ to the latest drm-misc-next today (427231bc6d5)
> > started giving me the BUG and Oops below. It's consistently
> > reproduceable. Wit
On Mon, Jun 10, 2019 at 06:53:27PM +0100, Catalin Marinas wrote:
> On Mon, Jun 03, 2019 at 06:55:04PM +0200, Andrey Konovalov wrote:
> > diff --git a/arch/arm64/include/asm/uaccess.h
> > b/arch/arm64/include/asm/uaccess.h
> > index e5d5f31c6d36..9164ecb5feca 100644
> > --- a/arch/arm64/include/asm
https://bugs.freedesktop.org/show_bug.cgi?id=110883
--- Comment #3 from Sibren Vasse ---
Created attachment 144495
--> https://bugs.freedesktop.org/attachment.cgi?id=144495&action=edit
patch
I've created this patch, which fixes the issue for me.
Can someone take a look at it and consider inclu
On Sat, Jun 8, 2019 at 4:03 AM Sam Ravnborg wrote:
>
> This patchset contains updates to two header files
> in include/drm/.
> The header files caused build errors due to missing dependencies.
> Fixed this so others will not be hit by the same.
>
> The header file drm_os_linux.h is deprecated and
On Sun, Jun 9, 2019 at 6:08 PM Sam Ravnborg wrote:
>
> This patcset drop all uses of drm_os_linux.h and
> drmP.h in drm/amd/.
> The patchset depends on the earlier series removing drmP.h
> from drm/radeon.
> https://lists.freedesktop.org/archives/dri-devel/2019-June/220969.html
>
> The only depend
Hi Alex.
>
> Series is:
> Reviewed-by: Alex Deucher
>
> Feel free to take it through drm-misc if you want, otherwise, let me
> know and I'll take it through my tree.
Applied to drm-misc-next.
I had accidently left a few empty lines that checkpatch complained
about. I fixed these when I applied
https://bugs.freedesktop.org/show_bug.cgi?id=110795
--- Comment #12 from Rolf ---
@Andrew, I'm transitioning from Windows to Linux for software development.
Though not new to Linux, I'm new to running it with a head. Perhaps I'm trying
to do something unnecessary under Ubuntu? I have an ASUS Rade
On Mon, Jun 10, 2019 at 07:53:30PM +0100, Catalin Marinas wrote:
> On Mon, Jun 10, 2019 at 11:07:03AM -0700, Kees Cook wrote:
> > On Mon, Jun 10, 2019 at 06:53:27PM +0100, Catalin Marinas wrote:
> > > diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> > > index 3767fb21a5b8..f
On Mon, Jun 10, 2019 at 1:52 PM Douglas Anderson wrote:
>
> In commit 50f9495efe30 ("drm/bridge/synopsys: dw-hdmi: Add "unwedge"
> for ddc bus") I stupidly used IS_ERR() to check for whether we have an
> "unwedge" pinctrl state even though on most flows through the driver
> the unwedge state will
In data Sunday, June 9, 2019 4:27:06 AM CEST, Mauro Carvalho Chehab ha
scritto:
> Convert the locking documents to ReST and add them to the
> kernel development book where it belongs.
>
> Most of the stuff here is just to make Sphinx to properly
> parse the text file, as they're already in good s
From: David Riley
v2: Updated barriers.
David Riley (4):
drm/virtio: Ensure cached capset entries are valid before copying.
drm/virtio: Wake up all waiters when capset response comes in.
drm/virtio: Fix cache entry creation race.
drm/virtio: Add memory barriers for capset cache.
drive
From: David Riley
If multiple callers occur simultaneously, wake them all up.
Signed-off-by: David Riley
---
drivers/gpu/drm/virtio/virtgpu_vq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index
From: David Riley
After data is copied to the cache entry, atomic_set is used indicate
that the data is the entry is valid without appropriate memory barriers.
Similarly the read side was missing the corresponding memory barriers.
Signed-off-by: David Riley
---
drivers/gpu/drm/virtio/virtgpu_i
From: David Riley
virtio_gpu_get_caps_ioctl could return success with invalid data if a
second caller to the function occurred after the entry was created in
virtio_gpu_cmd_get_capset but prior to the virtio_gpu_cmd_capset_cb
callback being called. This could leak contents of memory as well
sinc
From: David Riley
virtio_gpu_cmd_get_capset would check for the existence of an entry
under lock. If it was not found, it would unlock and call
virtio_gpu_cmd_get_capset to create a new entry. The new entry would
be added it to the list without checking if it was added by another
task during th
https://bugs.freedesktop.org/show_bug.cgi?id=110795
--- Comment #13 from Alex Deucher ---
(In reply to Rolf from comment #12)
> @Andrew, I'm transitioning from Windows to Linux for software development.
> Though not new to Linux, I'm new to running it with a head. Perhaps I'm
> trying to do somet
https://bugs.freedesktop.org/show_bug.cgi?id=110783
--- Comment #2 from Matt Turner ---
Looks like this was reported as a Gentoo bug as well
(https://bugs.gentoo.org/686252)
Have you tried bisecting?
--
You are receiving this mail because:
You are the assignee for the bug._
Hi Alex.
>
> Series is:
> Reviewed-by: Alex Deucher
> I'm fine to have this go through either drm-misc or my tree.
Thanks, pushed to drm-misc-next.
I ended up with a merge error in drm-tip that I dunno how to work with.
Help would be appreciated.
(I also wrote this on irc)
It is getting late he
On 6/7/19 9:56 PM, Kees Cook wrote:
On Mon, Jun 03, 2019 at 06:55:18PM +0200, Andrey Konovalov wrote:
This patch is a part of a series that extends arm64 kernel ABI to allow to
pass tagged user pointers (with the top byte set to something else other
than 0x00) as syscall arguments.
This patch a
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #62 from Richard Thier ---
Added a blog post about the whole issue and its solving process here:
http://ballmerpeak.web.elte.hu/devblog/debugging-mesa-and-the-linux-3d-graphics-stack.html
I have linked to this bug report and every
Add an optional 'max-brightness' property, which is used to specify
the number of brightness levels (max-brightness + 1) when the node
has no 'brightness-levels' table.
Signed-off-by: Matthias Kaehlcke
---
.../devicetree/bindings/leds/backlight/pwm-backlight.txt | 3 +++
1 file changed, 3
Commit 88ba95bedb79 ("backlight: pwm_bl: Compute brightness of LED
linearly to human eye") uses pwm_period / hweight32(pwm_period) as
as heuristic to determine the number of brightness levels when the DT
doesn't provide a brightness level table. This heuristic is broken
and can result in excessivel
https://bugs.freedesktop.org/show_bug.cgi?id=110885
Bug ID: 110885
Summary: [OverDrive] Add option to change acoustic limit
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Currently, all dma-bufs share the same anonymous inode. While we can count
how many dma-buf fds or mappings a process has, we can't get the size of
the backing buffers or tell if two entries point to the same dma-buf. And
in debugfs, we can get a per-buffer breakdown of size and reference count,
bu
From: Greg Hackmann
The show_fdinfo handler exports the same information available through
debugfs on a per-buffer basis.
Signed-off-by: Greg Hackmann
Signed-off-by: Chenbo Feng
---
drivers/dma-buf/dma-buf.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/dma-buf/
From: Greg Hackmann
This patch adds complimentary DMA_BUF_SET_NAME and DMA_BUF_GET_NAME
ioctls, which lets userspace processes attach a free-form name to each
buffer.
This information can be extremely helpful for tracking and accounting
shared buffers. For example, on Android, we know what each
From: Greg Hackmann
The show_fdinfo handler exports the same information available through
debugfs on a per-buffer basis.
Signed-off-by: Greg Hackmann
Signed-off-by: Chenbo Feng
---
drivers/dma-buf/dma-buf.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/dma-buf/
https://bugs.freedesktop.org/show_bug.cgi?id=110885
Andre Klapper changed:
What|Removed |Added
Severity|normal |enhancement
--
You are receiving this
Currently, all dma-bufs share the same anonymous inode. While we can count
how many dma-buf fds or mappings a process has, we can't get the size of
the backing buffers or tell if two entries point to the same dma-buf. And
in debugfs, we can get a per-buffer breakdown of size and reference count,
bu
From: Greg Hackmann
This patch adds complimentary DMA_BUF_SET_NAME and DMA_BUF_GET_NAME
ioctls, which lets userspace processes attach a free-form name to each
buffer.
This information can be extremely helpful for tracking and accounting
shared buffers. For example, on Android, we know what each
This adds to the rotation documentation to explain how drivers should
use the property and gives an example of the property in a devicetree
node.
Signed-off-by: Derek Basehore
---
.../bindings/display/panel/panel.txt | 32 +++
1 file changed, 32 insertions(+)
diff --git
This removes the orientation quirk detection from the code to add
an orientation property to a panel. This is used only for legacy x86
systems, yet we'd like to start using this on device tree systems
where quirk detection like this is not needed.
Signed-off-by: Derek Basehore
---
drivers/gpu/dr
This inits the panel orientation property for the mediatek dsi driver
if the panel orientation (connector.display_info.panel_orientation) is
not DRM_MODE_PANEL_ORIENTATION_UNKNOWN.
Signed-off-by: Derek Basehore
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 8
1 file changed, 8 insertions(+)
This adds a helper function for reading the rotation (panel
orientation) from the device tree.
Signed-off-by: Derek Basehore
---
drivers/gpu/drm/drm_panel.c | 41 +
include/drm/drm_panel.h | 7 +++
2 files changed, 48 insertions(+)
diff --git a/drive
This adds the attach/detach callbacks. These are for setting up
internal state for the connector/panel pair that can't be done at
probe (since the connector doesn't exist) and which don't need to be
repeatedly done for every get/modes, prepare, or enable callback.
Values such as the panel orientati
This adds the plumbing for reading panel rotation from the devicetree
and sets up adding a panel property for the panel orientation on
Mediatek SoCs when a rotation is present.
Derek Basehore (5):
drm/panel: Add helper for reading DT rotation
dt-bindings: display/panel: Expand rotation documen
From: Greg Hackmann
By traversing /proc/*/fd and /proc/*/map_files, processes with CAP_ADMIN
can get a lot of fine-grained data about how shmem buffers are shared
among processes. stat(2) on each entry gives the caller a unique
ID (st_ino), the buffer's size (st_size), and even the number of pag
On Fri, Jun 07, 2019 at 02:37:07PM -0700, Ralph Campbell wrote:
>
> On 6/6/19 11:44 AM, Jason Gunthorpe wrote:
> > From: Jason Gunthorpe
> >
> > hmm_release() is called exactly once per hmm. ops->release() cannot
> > accidentally trigger any action that would recurse back onto
> > hmm->mirrors_s
Hi,
On 10/6/19 1:13, Linus Walleij wrote:
> This converts the Analogix display port to use GPIO descriptors
> instead of DT-extracted numbers.
>
> Cc: Douglas Anderson
> Cc: Sean Paul
> Cc: Marek Szyprowski
> Cc: Enric Balletbo i Serra
> Signed-off-by: Linus Walleij
Reviewed-by: Enric Balle
From: Greg Hackmann
By traversing /proc/*/fd and /proc/*/map_files, processes with CAP_ADMIN
can get a lot of fine-grained data about how shmem buffers are shared
among processes. stat(2) on each entry gives the caller a unique
ID (st_ino), the buffer's size (st_size), and even the number of pag
Hi,
On 10/6/19 0:32, Linus Walleij wrote:
> This include is only used for some gpio drivers and consumers
> that look up GPIO numbers directly from the device tree.
> This driver does not use it and only needs .
> Delete the unused include.
>
> Cc: Enric Balletbo i Serra
> Cc: Jose Abreu
> Sign
On Fri, Jun 07, 2019 at 03:39:06PM -0700, Ralph Campbell wrote:
> > > + range->hmm = hmm;
> > > + kref_get(&hmm->kref);
> > > /* Initialize range to track CPU page table updates. */
> > > mutex_lock(&hmm->lock);
> > >
>
> I forgot to add that I think you can delete the duplicate
On 6/10/19 9:02 AM, Jason Gunthorpe wrote:
On Fri, Jun 07, 2019 at 02:37:07PM -0700, Ralph Campbell wrote:
On 6/6/19 11:44 AM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
hmm_release() is called exactly once per hmm. ops->release() cannot
accidentally trigger any action that would recurse
On 6/8/19 4:41 AM, Jason Gunthorpe wrote:
> On Sat, Jun 08, 2019 at 02:10:08AM -0700, Christoph Hellwig wrote:
>> On Fri, Jun 07, 2019 at 05:14:52PM -0700, Ralph Campbell wrote:
>>> HMM defines its own struct hmm_update which is passed to the
>>> sync_cpu_device_pagetables() callback function. This
1 - 100 of 116 matches
Mail list logo
