Am 04.02.21 um 19:38 schrieb Jason Gunthorpe:
On Thu, Feb 04, 2021 at 06:16:27PM +0100, Daniel Vetter wrote:
On Thu, Feb 4, 2021 at 5:13 PM Jason Gunthorpe wrote:
On Wed, Feb 03, 2021 at 10:19:48PM +0100, Daniel Vetter wrote:
tldr; DMA buffers aren't normal memory, expecting that you can use
This series is starting to get long, so I figured I'd add a
short cover letter for context.
The point of this series is trying to add both deferred-freeing
logic as well as a page pool to the DMA-BUF system heap.
This is desired, as the combination of deferred freeing along
with the page pool all
This adds a shrinker controlled page pool, closely
following the ttm_pool logic, which is abstracted out
a bit so it can be used by other non-ttm drivers.
Cc: Daniel Vetter
Cc: Christian Koenig
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Chris Goldsworthy
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridy
This patch simply renames the ttm_pool_dma structure to
ttm_pool_page_dat, as we will extend it to store more then just
dma related info in it.
Cc: Daniel Vetter
Cc: Christian Koenig
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Chris Goldsworthy
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
This refactors ttm_pool_free_page(), and by adding extra entries
to ttm_pool_page_dat, we then use it for all allocations, which
allows us to simplify the arguments needed to be passed to
ttm_pool_free_page().
This is critical for allowing the free function to be called
by the sharable drm_page_po
This patch reworks the ttm_pool logic to utilize the recently
added drm_page_pool code.
Basically all the ttm_pool_type structures are replaced with
drm_page_pool pointers, and since the drm_page_pool logic has
its own shrinker, we can remove all of the ttm_pool shrinker
logic.
NOTE: There is one
This patch provides infrastructure for deferring buffer frees.
This is a feature ION provided which when used with some form
of a page pool, provides a nice performance boost in an
allocation microbenchmark. The reason it helps is it allows the
page-zeroing to be done out of the normal allocation/
Utilize the drm pagepool code to speed up allocation
performance.
This is similar to the ION pagepool usage, but tries to
utilize generic code instead of a custom implementation.
Cc: Daniel Vetter
Cc: Christian Koenig
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Chris Goldsworthy
Cc: Laura Abbott
Cc:
Utilize the deferred free helper library in the system heap.
This provides a nice performance bump and puts the
system heap performance on par with ION.
Cc: Daniel Vetter
Cc: Christian Koenig
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Chris Goldsworthy
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya
Hi Sebastian,
Am Freitag, 5. Februar 2021, 07:43:35 CET schrieb Sebastian Fricke:
> On 03.02.2021 20:54, Heiko Stübner wrote:
> >Am Mittwoch, 3. Februar 2021, 19:14:22 CET schrieb Sebastian Fricke:
> >> I have tested your patch set on my nanoPC-T4, here is a complete log
> >> with:
> >> - relevant
https://bugzilla.kernel.org/show_bug.cgi?id=211425
Andreas (icedragon...@web.de) changed:
What|Removed |Added
Kernel Version|5.10.12 |5.10.13
--- Comment #3 fr
Am 05.02.21 um 09:06 schrieb John Stultz:
This refactors ttm_pool_free_page(), and by adding extra entries
to ttm_pool_page_dat, we then use it for all allocations, which
allows us to simplify the arguments needed to be passed to
ttm_pool_free_page().
This is a clear NAK since the peer page dat
+CC the other Komeda maintainers
On 04/02/2021 13:11, carsten.haitz...@foss.arm.com wrote:
From: Carsten Haitzler
Another issue found by KASAN. The bit finding is buried inside the
dp_for_each_set_bit() macro (that passes on to for_each_set_bit() that
calls the bit stuff. These bit functions w
On Fri, Feb 5, 2021 at 4:50 AM Marek Vasut wrote:
>
> On 2/4/21 11:29 PM, Laurent Pinchart wrote:
> > Hi Jagan,
> >
> > Thank you for the patch.
> >
> > On Wed, Feb 03, 2021 at 12:42:56PM +0530, Jagan Teki wrote:
> >> SN65DSI84 is a Single Channel DSI to Dual-link LVDS bridge from
> >> Texas Instr
On 2/4/21 6:23 PM, Kalesh Singh wrote:
> If a FD refers to a DMA buffer add the DMA buffer inode number to
> /proc//fdinfo/ and /proc//task//fdindo/.
>
> The dmabuf inode number allows userspace to uniquely identify the buffer
> and avoids a dependency on /proc//fd/* when accounting per-process
>
On 2/4/21 3:28 PM, Kalesh Singh wrote:
> If a FD refers to a DMA buffer add the DMA buffer inode number to
> /proc//fdinfo/ and /proc//task//fdindo/.
>
> The dmabuf inode number allows userspace to uniquely identify the buffer
> and avoids a dependency on /proc//fd/* when accounting per-process
>
This patch adds an initial DRM driver for the Loongson LS7A1000
bridge chip(LS7A). The LS7A bridge chip contains two display
controllers, support dual display output. The maximum support for
each channel display is to 1920x1080@60Hz.
At present, DC device detection and DRM driver registration are
c
Use DRM_FOURCC_STANDALONE to include drm_fourcc.h without drm.h.
Copy type definitions from drm.h to drm_fourcc.h, and wrap with
DRM_BASIC_TYPED_DEFINED to avoid redundant inclusion.
This will allow code to avoid unnecessary definitions.
Signed-off-by: James Park
---
include/uapi/drm/drm.h
Hey Heiko,
On 03.02.2021 20:54, Heiko Stübner wrote:
Hi Sebastian,
Am Mittwoch, 3. Februar 2021, 19:14:22 CET schrieb Sebastian Fricke:
Hey Heiko,
I have tested your patch set on my nanoPC-T4, here is a complete log
with:
- relevant kernel log entries
- system information
- media ctl output
-
Am 05.02.21 um 09:06 schrieb John Stultz:
This adds a shrinker controlled page pool, closely
following the ttm_pool logic, which is abstracted out
a bit so it can be used by other non-ttm drivers.
Cc: Daniel Vetter
Cc: Christian Koenig
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Chris Goldsworthy
Cc
Am 05.02.21 um 09:06 schrieb John Stultz:
This patch reworks the ttm_pool logic to utilize the recently
added drm_page_pool code.
Basically all the ttm_pool_type structures are replaced with
drm_page_pool pointers, and since the drm_page_pool logic has
its own shrinker, we can remove all of the
Hi, Chenyang,
On Fri, Feb 5, 2021 at 4:33 PM Chenyang Li wrote:
>
> This patch adds an initial DRM driver for the Loongson LS7A1000
> bridge chip(LS7A). The LS7A bridge chip contains two display
> controllers, support dual display output. The maximum support for
> each channel display is to 1920x
On Fri, Feb 05, 2021 at 08:29:32AM +, Steven Price wrote:
> +CC the other Komeda maintainers
>
> On 04/02/2021 13:11, carsten.haitz...@foss.arm.com wrote:
> > From: Carsten Haitzler
> >
> > Another issue found by KASAN. The bit finding is buried inside the
> > dp_for_each_set_bit() macro (th
On Thu, Feb 04, 2021 at 02:38:28PM +0800, Jiapeng Chong wrote:
> Fix the following coccicheck warning:
>
> ./drivers/gpu/drm/arm/display/komeda/komeda_dev.c:97:8-16: WARNING: use
> scnprintf or sprintf.
>
> ./drivers/gpu/drm/arm/display/komeda/komeda_dev.c:88:8-16: WARNING: use
> scnprintf or spr
Hi,
> I smoke-tested the code by running fbdev, Xorg and weston with the
> converted mgag200 driver.
Looks sane to me.
Survived cirrus smoke test too.
Tested-by: Gerd Hoffmann
Acked-by: Gerd Hoffmann
take care,
Gerd
___
dri-devel mailing list
d
s/confguration/configuration/
s/Regsiters/Registers/
Signed-off-by: Bhaskar Chowdhury
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.h
On 21-02-04 19:15, Oliver Graute wrote:
> On 02/02/21, Marco Felsch wrote:
> > Hi Oliver,
> >
> > On 21-02-02 18:35, Oliver Graute wrote:
> > > Add support for the Solomon Goldentek Display Model: GKTW70SDAD1SD
> > > to panel-simple.
> > >
> > > The panel spec from Variscite can be found at:
> >
On Thu, Feb 4, 2021 at 9:59 PM Jason Gunthorpe wrote:
>
> On Thu, Feb 04, 2021 at 09:19:57PM +0100, Daniel Vetter wrote:
> > On Thu, Feb 4, 2021 at 9:09 PM Jason Gunthorpe wrote:
> > >
> > > On Thu, Feb 04, 2021 at 08:59:59PM +0100, Daniel Vetter wrote:
> > >
> > > > So I think just checking for
On Thu, Feb 4, 2021 at 10:50 PM Bjorn Helgaas wrote:
>
> [+cc Oliver, Pali, Krzysztof]
>
> s/also/Also/ in subject
>
> On Thu, Feb 04, 2021 at 05:58:30PM +0100, Daniel Vetter wrote:
> > We are already doing this for all the regular sysfs files on PCI
> > devices, but not yet on the legacy io files
According to Documentation/timers/timers-howto.rst, usleep_range is
preffered over udelay for >=10us delay.
Signed-off-by: Mayank Suman
---
drivers/staging/fbtft/fb_agm1264k-fl.c | 2 +-
drivers/staging/fbtft/fb_ra8875.c | 4 ++--
drivers/staging/fbtft/fb_tinylcd.c | 4 ++--
drivers/
On Fri, Feb 5, 2021 at 5:33 AM Alex Deucher wrote:
>
> On Thu, Feb 4, 2021 at 6:52 PM Dave Airlie wrote:
> >
> > On Thu, 4 Feb 2021 at 14:57, Alex Deucher wrote:
> > >
> > > Hi Dave, Daniel,
> > >
> > > More fixes for 5.12. Same PR from last week with the issue Felix reported
> > > fixed and a
On Fri, Feb 05, 2021 at 02:41:13PM +0530, Mayank Suman wrote:
> According to Documentation/timers/timers-howto.rst, usleep_range is
> preffered over udelay for >=10us delay.
>
> Signed-off-by: Mayank Suman
ALWAYS test build your patches before sending them out to the world for
review. You don't
Hello Russell, hello Greg,
On Thu, Feb 04, 2021 at 07:15:51PM +0100, Uwe Kleine-König wrote:
> On Thu, Feb 04, 2021 at 04:59:51PM +, Russell King - ARM Linux admin
> wrote:
> > On Thu, Feb 04, 2021 at 05:56:50PM +0100, Greg Kroah-Hartman wrote:
> > > On Thu, Feb 04, 2021 at 04:52:24PM +,
On Thu, 4 Feb 2021 at 23:25, Nicolas Boichat wrote:
>
> On Thu, Feb 4, 2021 at 8:59 PM Andrzej Hajda wrote:
> >
> >
> > W dniu 04.02.2021 o 13:34, Nicolas Boichat pisze:
> > > On Thu, Feb 4, 2021 at 8:07 PM Robert Foss wrote:
> > >> Hi Xin,
> > >>
> > >> Thanks for the patch.
> > >>
> > >> On Th
Alex how do we want to merge this?
I've just pushed the first patch to drm-misc-next since that needed a
rebase because it touches other drivers as well.
But the rest is really AMD specific and I'm not sure if the dependent
stuff is already in there as well.
So if I push it to drm-misc-next
Hi
Am 05.02.21 um 10:05 schrieb Gerd Hoffmann:
Hi,
I smoke-tested the code by running fbdev, Xorg and weston with the
converted mgag200 driver.
Looks sane to me.
Survived cirrus smoke test too.
Tested-by: Gerd Hoffmann
Acked-by: Gerd Hoffmann
Thanks a lot! I have on small change to t
On Fri, Feb 05, 2021 at 10:37:44AM +0100, Uwe Kleine-König wrote:
> Hello Russell, hello Greg,
>
> On Thu, Feb 04, 2021 at 07:15:51PM +0100, Uwe Kleine-König wrote:
> > On Thu, Feb 04, 2021 at 04:59:51PM +, Russell King - ARM Linux admin
> > wrote:
> > > On Thu, Feb 04, 2021 at 05:56:50PM +01
Am 05.02.21 um 09:06 schrieb John Stultz:
This series is starting to get long, so I figured I'd add a
short cover letter for context.
The point of this series is trying to add both deferred-freeing
logic as well as a page pool to the DMA-BUF system heap.
This is desired, as the combination of d
On Fri, Feb 05, 2021 at 11:18:17AM +0100, Greg Kroah-Hartman wrote:
> On Fri, Feb 05, 2021 at 10:37:44AM +0100, Uwe Kleine-König wrote:
> > Hello Russell, hello Greg,
> >
> > On Thu, Feb 04, 2021 at 07:15:51PM +0100, Uwe Kleine-König wrote:
> > > On Thu, Feb 04, 2021 at 04:59:51PM +, Russell K
On Fri, Feb 05, 2021 at 11:56:15AM +0100, Uwe Kleine-König wrote:
> On Fri, Feb 05, 2021 at 11:18:17AM +0100, Greg Kroah-Hartman wrote:
> > On Fri, Feb 05, 2021 at 10:37:44AM +0100, Uwe Kleine-König wrote:
> > > Hello Russell, hello Greg,
> > >
> > > On Thu, Feb 04, 2021 at 07:15:51PM +0100, Uwe K
On Thu, Feb 4, 2021 at 11:04 AM Andy Shevchenko
wrote:
>> Today's linux-next merge of the drivers-x86 tree got a conflict in:
>
> Thanks. I already asked Patrik yesterday day if DRM missed to pull an
> immutable tag I provided. I think they can pull and resolve conflicts
> themselves. Alternativ
On Fri, Feb 5, 2021 at 12:07 PM Andy Shevchenko
wrote:
>
> On Thu, Feb 4, 2021 at 11:04 AM Andy Shevchenko
> wrote:
> >> Today's linux-next merge of the drivers-x86 tree got a conflict in:
> >
> > Thanks. I already asked Patrik yesterday day if DRM missed to pull an
> > immutable tag I provided.
Hello,
Here are 2 fixes and one improvement for the page fault handling. Those
bugs were found while working on indirect draw supports which requires
the allocation of a big heap buffer for varyings, and the vertex/tiler
shaders seem to have access pattern that trigger those issues. I
remember dis
When a fault is handled it will unblock the GPU which will continue
executing its shader and might fault almost immediately on a different
page. If we clear interrupts after handling the fault we might miss new
faults, so clear them before.
Cc:
Fixes: 187d2929206e ("drm/panfrost: Add support for
Doing a hw-irq -> threaded-irq round-trip is counter-productive, stay
in the threaded irq handler as long as we can.
v2:
* Rework the loop to avoid a goto
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panfrost/panfrost_mmu.c | 26 +
1 file changed, 14 insertions(+),
We allocate 2MB chunks at a time, so it might appear that a page fault
has already been handled by a previous page fault when we reach
panfrost_mmu_map_fault_addr(). Bail out in that case to avoid mapping the
same area twice.
Cc:
Fixes: 187d2929206e ("drm/panfrost: Add support for GPU heap alloca
Hi Mayank,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on staging/staging-testing]
url:
https://github.com/0day-ci/linux/commits/Mayank-Suman/staging-fbtft-replaced-udelay-with-usleep_range/20210205-171807
base: https://git.kernel.org/pub/scm/linux/kernel/git
On 05/02/2021 11:17, Boris Brezillon wrote:
Doing a hw-irq -> threaded-irq round-trip is counter-productive, stay
in the threaded irq handler as long as we can.
v2:
* Rework the loop to avoid a goto
Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/pa
On 05/02/2021, Eric Anholt wrote:
> On Thu, Feb 4, 2021 at 10:09 AM Chema Casanova
> wrote:
>>
>> On 3/9/20 18:48, Yukimasa Sugizaki wrote:
>> > From: Yukimasa Sugizaki
>> >
>> > The default timeout is 500 ms which is too short for some workloads
>> > including Piglit. Adding this parameter wil
Hey Xin,
On Thu, 28 Jan 2021 at 04:12, Xin Ji wrote:
>
> Add MIPI rx DPI input support
>
> Reported-by: kernel test robot
> Signed-off-by: Xin Ji
> ---
> drivers/gpu/drm/bridge/analogix/anx7625.c | 326
> --
> drivers/gpu/drm/bridge/analogix/anx7625.h | 20 +-
> 2
On Thu, Feb 4, 2021 at 7:55 AM Alex Deucher wrote:
>
> On Thu, Feb 4, 2021 at 3:16 AM Christian König
> wrote:
> >
> > Am 03.02.21 um 22:41 schrieb Suren Baghdasaryan:
> > > [SNIP]
> > >>> How many semi-unrelated buffer accounting schemes does google come up
> > >>> with?
> > >>>
> > >>> We're
Android captures per-process system memory state when certain low memory
events (e.g a foreground app kill) occur, to identify potential memory
hoggers. In order to measure how much memory a process actually consumes,
it is necessary to include the DMA buffer sizes for that process in the
memory ac
Android captures per-process system memory state when certain low memory
events (e.g a foreground app kill) occur, to identify potential memory
hoggers. In order to measure how much memory a process actually consumes,
it is necessary to include the DMA buffer sizes for that process in the
memory ac
Hi Mayank,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on staging/staging-testing]
url:
https://github.com/0day-ci/linux/commits/Mayank-Suman/staging-fbtft-replaced-udelay-with-usleep_range/20210205-171807
base: https://git.kernel.org/pub/scm/linux/kernel/git
s/fucking/messing/
Signed-off-by: Bhaskar Chowdhury
---
drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
index 9de74f41dcd2..bc
gallium (iris) depends on os_same_file_description() to disambiguate
screens and so avoid importing the same screen fd twice as two distinct
entities (that share all the kernel resources, so actions on screen
affect the other and would cause random faiure). As they depend on it,
so must we. os_same
s/fuck/heck/
Signed-off-by: Bhaskar Chowdhury
---
drivers/gpu/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc
b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc
index
On Fri, Feb 5, 2021 at 12:14 PM Patrik Jakobsson
wrote:
>
> On Fri, Feb 5, 2021 at 12:07 PM Andy Shevchenko
> wrote:
> >
> > On Thu, Feb 4, 2021 at 11:04 AM Andy Shevchenko
> > wrote:
> > >> Today's linux-next merge of the drivers-x86 tree got a conflict in:
> > >
> > > Thanks. I already asked P
On Thu, Feb 04, 2021 at 04:29:14PM -0800, Jianxin Xiong wrote:
> Compilation of pyverbs/dmabuf_alloc.c depends on a few DRM headers
> that are installed by either the kernel-header or the libdrm package.
> The installation is optional and the location is not unique.
>
> Check the presence of the h
On Fri, Feb 05, 2021 at 04:17:51PM +1100, Sam McNally wrote:
> On Thu, 4 Feb 2021 at 21:19, Hans Verkuil wrote:
> >
> > On 01/02/2021 23:13, Ville Syrjälä wrote:
> > > On Wed, Sep 23, 2020 at 12:13:53PM +1000, Sam McNally wrote:
> > >> From: Hans Verkuil
> > >>
> > >> For adapters behind an MST h
We are already doing this for all the regular sysfs files on PCI
devices, but not yet on the legacy io files on the PCI buses. Thus far
no problem, but in the next patch I want to wire up iomem revoke
support. That needs the vfs up and running already to make sure that
iomem_get_mapping() works.
W
tldr; DMA buffers aren't normal memory, expecting that you can use
them like that (like calling get_user_pages works, or that they're
accounting like any other normal memory) cannot be guaranteed.
Since some userspace only runs on integrated devices, where all
buffers are actually all resident sys
On Fri, Feb 05, 2021 at 10:43:14AM +0100, Robert Foss wrote:
> On Thu, 4 Feb 2021 at 23:25, Nicolas Boichat wrote:
> >
> > On Thu, Feb 4, 2021 at 8:59 PM Andrzej Hajda wrote:
> > >
> > >
> > > W dniu 04.02.2021 o 13:34, Nicolas Boichat pisze:
> > > > On Thu, Feb 4, 2021 at 8:07 PM Robert Foss
>
Hi Linus,
This is first part of Intel MID outdated platforms removal. It's collected into
immutable branch with a given tag, please pull to yours subsystems.
(All changes are tagged by the respective maintainers)
Thanks,
With Best Regards,
Andy Shevchenko
The following changes since commit 5c8
On Thu, Feb 04, 2021 at 01:28:30PM +0100, Robert Foss wrote:
> Hi Xin,
>
> On Thu, 28 Jan 2021 at 04:12, Xin Ji wrote:
> >
> > At some time, the original code may return non zero value, force return 0
> > if operation finished
>
> Missing "." at end of line.
Hi Rob, OK, thanks, I'll add it in th
On Fri, Feb 05, 2021 at 12:30:45PM +0100, Robert Foss wrote:
> Hey Xin,
>
> Thanks for the quick response. I think this is ok.
>
> But going forward it is easier for maintainers to keep track of
> patches if they're submitted with a version tag. [PATCH] -> [PATCH v2]
> -> [PATCH v3] etc.
>
> git
On 2021-02-04 03:16, Will Deacon wrote:
On Tue, Feb 02, 2021 at 11:56:27AM +0530, Sai Prakash Ranjan wrote:
On 2021-02-01 23:50, Jordan Crouse wrote:
> On Mon, Feb 01, 2021 at 08:20:44AM -0800, Rob Clark wrote:
> > On Mon, Feb 1, 2021 at 3:16 AM Will Deacon wrote:
> > > On Fri, Jan 29, 2021 at
Enable DSI EOTP feature for fixing some panel screen constant shift issue.
Removing MIPI flag MIPI_DSI_MODE_EOT_PACKET to enable DSI EOTP.
Reviewed-by: Robert Foss
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/
Am 05.02.21 um 14:41 schrieb Daniel Vetter:
tldr; DMA buffers aren't normal memory, expecting that you can use
them like that (like calling get_user_pages works, or that they're
accounting like any other normal memory) cannot be guaranteed.
Since some userspace only runs on integrated devices, w
On Thu, Feb 04, 2021 at 01:38:36PM +0100, Robert Foss wrote:
> Hey Xin,
>
> On Thu, 28 Jan 2021 at 04:10, Xin Ji wrote:
> >
> > Add 'bus-type' and 'data-lanes' define for port0, add HDCP support
> > flag and DP tx lane0 and lane1 swing register array define.
> >
> > Signed-off-by: Xin Ji
> > ---
This was non-trivial to get right because commits
c23bc382ef0e ("coresight: etm4x: Refactor probing routine") and
5214b563588e ("coresight: etm4x: Add support for sysreg only devices")
changed the code flow considerably. With this change the driver can be
built again.
Fixes: 0573d3fa4864 ("Merge b
On 05/02/2021 14:24, Ville Syrjälä wrote:
> On Fri, Feb 05, 2021 at 04:17:51PM +1100, Sam McNally wrote:
>> On Thu, 4 Feb 2021 at 21:19, Hans Verkuil wrote:
>>>
>>> On 01/02/2021 23:13, Ville Syrjälä wrote:
On Wed, Sep 23, 2020 at 12:13:53PM +1000, Sam McNally wrote:
> From: Hans Verkuil
Hi Kenny
On Wed, Feb 3, 2021 at 8:01 PM Kenny Ho wrote:
>
> Daniel,
>
> I will have to get back to you later on the details of this because my
> head is currently context switched to some infrastructure and
> Kubernetes/golang work, so I am having a hard time digesting what you
> are saying. I a
On Fri, Feb 5, 2021 at 2:22 PM Jason Gunthorpe wrote:
>
> On Thu, Feb 04, 2021 at 04:29:14PM -0800, Jianxin Xiong wrote:
> > Compilation of pyverbs/dmabuf_alloc.c depends on a few DRM headers
> > that are installed by either the kernel-header or the libdrm package.
> > The installation is optional
On Fri, Feb 05, 2021 at 02:46:44PM +0100, Hans Verkuil wrote:
> On 05/02/2021 14:24, Ville Syrjälä wrote:
> > On Fri, Feb 05, 2021 at 04:17:51PM +1100, Sam McNally wrote:
> >> On Thu, 4 Feb 2021 at 21:19, Hans Verkuil wrote:
> >>>
> >>> On 01/02/2021 23:13, Ville Syrjälä wrote:
> On Wed, Sep
On Fri, Feb 5, 2021 at 3:05 PM Daniel Vetter wrote:
> On Fri, Feb 5, 2021 at 12:14 PM Patrik Jakobsson
> wrote:
> >
> > On Fri, Feb 5, 2021 at 12:07 PM Andy Shevchenko
> > wrote:
> > >
> > > On Thu, Feb 4, 2021 at 11:04 AM Andy Shevchenko
> > > wrote:
> > > >> Today's linux-next merge of the dr
On Fri, Feb 05, 2021 at 02:08:47PM +0100, Uwe Kleine-König wrote:
> This was non-trivial to get right because commits
> c23bc382ef0e ("coresight: etm4x: Refactor probing routine") and
> 5214b563588e ("coresight: etm4x: Add support for sysreg only devices")
> changed the code flow considerably. With
Runtime PM doesn't seem to work correctly on this driver. On top of
that, commit 8b6864e3e138 (drm/v3d/v3d_drv: Remove unused static
variable 'v3d_v3d_pm_ops') hints that it most likely never did properly
as the driver's PM ops were not hooked-up.
So, in order to support regular operation with V3D
Add compatible string and Kconfig options for bcm2711.
Signed-off-by: Nicolas Saenz Julienne
---
drivers/gpu/drm/v3d/Kconfig | 2 +-
drivers/gpu/drm/v3d/v3d_drv.c | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/v3d/Kconfig b/drivers/gpu/drm/v3d/Kconfig
inde
This series attempts to enable V3D on BCM2711, the SoC available on the
Raspberry Pi 4 family of boards.
Due to the lack of documentation some things are taken as it from
testing/downstream implementation[1], which I'm hilighting here:
- It's not clear that the following is 100% true, maybe someo
Am 05.02.21 um 14:22 schrieb Thomas Zimmermann:
All errors (new ones prefixed by >>, old ones prefixed by <<):
ERROR: modpost: "drm_gem_vunmap" [drivers/gpu/drm/drm_kms_helper.ko]
undefined!
ERROR: modpost: "drm_gem_vmap" [drivers/gpu/drm/drm_kms_helper.ko]
undefined!
These are in drm_gem.c
Merged.
Am 04.02.21 um 20:11 schrieb Colin King:
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 29 bytes:
Before:
text data bss dechex filename
34736 4552 0 39288
[AMD Official Use Only - Internal Distribution Only]
Good question. I think push it to drm-misc-next for upstream. We can carry it
internally in amd-staging-drm-next for internal testing and I can coordinate
with drm-next. I think the amdgpu changes are pretty straightforward, so
shouldn't b
The alternative is to wait till drm-misc-next is merged into drm-next,
then rebase amd-staging-drm-next on top of that (or directly
drm-misc-next) and push then.
Would give us at least a clean history. Question is rather if we want it
in 5.12?
Christian.
Am 05.02.21 um 15:50 schrieb Deucher
Hi Sebastian,
I did some tests myself today as well and can confirm your
hdmi related finding - at least when plugged in on boot.
I tried some combinations of camera vs. hdmi and it seems
really only when hdmi is plugged in on boot
(1)
- boot
- camera
--> works
(2)
- boot
- camera
- hdmi plugge
Vmap operations may acquire the dmabuf reservation lock, which is not
allowed within atomic commit-tail functions. Therefore move vmap and
vunmap from the damage handler into prepare_fb and cleanup_fb callbacks.
The mapping is provided as GEM shadow-buffered plane. The functions in
the commit tail
The symbols will be required by the upcoming helpers for shadow-buffered
planes.
Signed-off-by: Thomas Zimmermann
Reported-by: kernel test robot
---
drivers/gpu/drm/drm_gem.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index c2ce78
Several drivers use GEM buffer objects as shadow buffers for the actual
framebuffer memory. Right now, drivers do these vmap operations in their
commit tail, which is actually not allowed by the locking rules for
the dma-buf reservation lock. The involved BO has to be vmapped in the
plane's prepare
Vmap operations may acquire the dmabuf reservation lock, which is not
allowed within atomic commit-tail functions. Therefore move vmap and
vunmap from the damage handler into prepare_fb and cleanup_fb callbacks.
The mapping is provided as GEM shadow-buffered plane. The functions in
the commit tail
Vmap operations may acquire the dmabuf reservation lock, which is not
allowed within atomic commit-tail functions. Therefore move vmap and
vunmap from the damage handler into prepare_fb and cleanup_fb callbacks.
The mapping is provided as GEM shadow-buffered plane. The functions in
the commit tail
Vmap operations may acquire the dmabuf reservation lock, which is not
allowed within atomic commit-tail functions. Therefore move vmap and
vunmap from the damage handler into prepare_fb and cleanup_fb callbacks.
The mapping is provided as GEM shadow-buffered plane. The functions in
the commit tail
Several SHMEM-based drivers use the BO as shadow buffer for the real
framebuffer memory. Damage handling requires a vmap of the BO memory.
But vmap/vunmap can acquire the dma-buf reservation lock, which is not
allowed in commit tails.
This patchset introduces a set of helpers that implement vmap/v
Just like regular plane-state helpers, drivers can use these new
callbacks to create and destroy private plane state.
v2:
* make duplicate_state interface compatible with
struct drm_plane_funcs
Signed-off-by: Thomas Zimmermann
Tested-by: Gerd Hoffmann
Acked-by: Gerd Hoffmann
[AMD Official Use Only - Internal Distribution Only]
I think the virt team probably wants it in amd-staging-drm-next so they can
start testing it. 5.12 is getting pretty tight. I'm not sure if there will be
another drm-misc PR or not for 5.12. Rebasing amd-staging-drm-next is turning
into a
On Feb 5, 2021, at 2:43 AM, Gerd Hoffmann wrote:
>
> On Thu, Feb 04, 2021 at 11:30:50AM -0500, Tong Zhang wrote:
>> if qxl_device_init() fail, drm device will not be registered,
>> in this case, do not run qxl_drm_release()
>
> How do you trigger this?
>
This can be triggered by changing the Q
On Thu, Feb 04, 2021 at 11:00:32AM -0800, John Hubbard wrote:
> On 2/4/21 10:44 AM, Alex Deucher wrote:
> ...
> > > > The argument is that vram is a scarce resource, but I don't know if
> > > > that is really the case these days. At this point, we often have as
> > > > much vram as system ram if n
https://bugzilla.kernel.org/show_bug.cgi?id=210849
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
On Fri, Feb 05, 2021 at 04:39:47PM +0100, Daniel Vetter wrote:
> > And again, for slightly older hardware, without pinning to VRAM there is
> > no way to use this solution here for peer-to-peer. So I'm glad to see that
> > so far you're not ruling out the pinning option.
>
> Since HMM and ZONE_DE
On Thu, Feb 04, 2021 at 05:55:28PM +0200, Ville Syrjälä wrote:
> On Thu, Feb 04, 2021 at 04:32:16PM +0100, Daniel Vetter wrote:
> > On Thu, Feb 04, 2021 at 04:04:00AM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > drm_vblank_restore() exists because certain power saving states
On Fri, Feb 05, 2021 at 11:43:19AM -0400, Jason Gunthorpe wrote:
> On Fri, Feb 05, 2021 at 04:39:47PM +0100, Daniel Vetter wrote:
>
> > > And again, for slightly older hardware, without pinning to VRAM there is
> > > no way to use this solution here for peer-to-peer. So I'm glad to see that
> > >
1 - 100 of 176 matches
Mail list logo
