Still keep this function because directly using dev->dma_io_tlb_mem
will cause issues for memory allocation for existing devices. The pool
can't support atomic coherent allocation so we need to distinguish the
per device pool and the default pool in swiotlb_alloc.
On 5/17/21 12:57 PM, Jani Nikula wrote:
On Tue, 11 May 2021, Thomas Hellström wrote:
The internal ttm_bo_util memcpy uses vmap functionality, and while it
probably might be possible to use it for copying in- and out of
sglist represented io memory, using io_mem_reserve() / io_mem_free()
callb
I didn't move this to a separate file because I feel it might be
confusing for swiotlb_alloc/free (and need more functions to be
non-static).
Maybe instead of moving to a separate file, we can try to come up with
a better naming?
On 5/17/21 11:46 PM, Thomas Hellström wrote:
On 5/17/21 3:11 PM, Christoph Hellwig wrote:
On Mon, May 17, 2021 at 04:09:42PM +0300, Serge Belyshev wrote:
Christoph Hellwig writes:
As an ad-hoc experiment: can you replace the call to remap_pfn_range
with remap_pfn_range_notrack (and expor
If a device is not behind an IOMMU, we look up the device node and set
up the restricted DMA when the restricted-dma-pool is presented.
Signed-off-by: Claire Chang
---
drivers/of/address.c| 25 +
drivers/of/device.c | 3 +++
drivers/of/of_private.h | 5 +
3
Introduce the new compatible string, restricted-dma-pool, for restricted
DMA. One can specify the address and length of the restricted DMA memory
region by restricted-dma-pool in the reserved-memory node.
Signed-off-by: Claire Chang
---
.../reserved-memory/reserved-memory.txt | 27
The restricted DMA pool is preferred if available.
The restricted DMA pools provide a basic level of protection against the
DMA overwriting buffer contents at unexpected times. However, to protect
against general data leakage and system memory corruption, the system
needs to provide a way to lock
Add the functions, swiotlb_{alloc,free} to support the memory allocation
from restricted DMA pool.
Signed-off-by: Claire Chang
---
include/linux/swiotlb.h | 4
kernel/dma/swiotlb.c| 35 +--
2 files changed, 37 insertions(+), 2 deletions(-)
diff --git a/
Add a new wrapper __dma_direct_free_pages() that will be useful later
for swiotlb_free().
Signed-off-by: Claire Chang
---
kernel/dma/direct.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 078f7087e466..eb409832
Add a new function, release_slots, to make the code reusable for supporting
different bounce buffer pools, e.g. restricted DMA pool.
Signed-off-by: Claire Chang
---
kernel/dma/swiotlb.c | 35 ---
1 file changed, 20 insertions(+), 15 deletions(-)
diff --git a/kern
Move the maintenance of alloc_size to find_slots for better code
reusability later.
Signed-off-by: Claire Chang
---
kernel/dma/swiotlb.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 95f482c4408c..2ec6711071de 100
Regardless of swiotlb setting, the restricted DMA pool is preferred if
available.
The restricted DMA pools provide a basic level of protection against the
DMA overwriting buffer contents at unexpected times. However, to protect
against general data leakage and system memory corruption, the system
Update is_swiotlb_buffer to add a struct device argument. This will be
useful later to allow for restricted DMA pool.
Signed-off-by: Claire Chang
---
drivers/iommu/dma-iommu.c | 12 ++--
drivers/xen/swiotlb-xen.c | 2 +-
include/linux/swiotlb.h | 6 +++---
kernel/dma/direct.c |
Update is_swiotlb_active to add a struct device argument. This will be
useful later to allow for restricted DMA pool.
Signed-off-by: Claire Chang
---
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_ttm.c| 2 +-
drivers/pci/xen-pcifront.c
Add a new getter, get_io_tlb_mem, to help select the io_tlb_mem struct.
The restricted DMA pool is preferred if available.
Signed-off-by: Claire Chang
---
include/linux/swiotlb.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
in
Add the initialization function to create restricted DMA pools from
matching reserved-memory nodes.
Signed-off-by: Claire Chang
---
include/linux/device.h | 4 +++
include/linux/swiotlb.h | 3 +-
kernel/dma/swiotlb.c| 76 +
3 files changed, 82 inser
Add a new kconfig symbol, DMA_RESTRICTED_POOL, for restricted DMA pool.
Signed-off-by: Claire Chang
---
kernel/dma/Kconfig | 14 ++
1 file changed, 14 insertions(+)
diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
index 77b405508743..3e961dc39634 100644
--- a/kernel/dma/Kconfig
Split the debugfs creation to make the code reusable for supporting
different bounce buffer pools, e.g. restricted DMA pool.
Signed-off-by: Claire Chang
---
kernel/dma/swiotlb.c | 25 +++--
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/kernel/dma/swiotlb.c b/
Add a new function, swiotlb_init_io_tlb_mem, for the io_tlb_mem struct
initialization to make the code reusable.
Note that we now also call set_memory_decrypted in swiotlb_init_with_tbl.
Signed-off-by: Claire Chang
---
kernel/dma/swiotlb.c | 51 ++--
1 fi
This series implements mitigations for lack of DMA access control on
systems without an IOMMU, which could result in the DMA accessing the
system memory at unexpected times and/or unexpected addresses, possibly
leading to data leakage or corruption.
For example, we plan to use the PCI-e bus for Wi
On Tue, May 18, 2021 at 12:49 AM Jason Ekstrand wrote:
>
> On Mon, May 17, 2021 at 3:15 PM Daniel Vetter wrote:
> >
> > On Mon, May 17, 2021 at 9:38 PM Christian König
> > wrote:
> > >
> > > Am 17.05.21 um 17:04 schrieb Daniel Vetter:
> > > > On Mon, May 17, 2021 at 04:11:18PM +0200, Christian K
On Mon, May 17, 2021 at 06:35:24PM -0700, Linus Torvalds wrote:
> On Mon, May 17, 2021 at 6:09 PM Sasha Levin wrote:
> >
> > From: Tetsuo Handa
> >
> > [ Upstream commit ffb324e6f874121f7dce5bdae5e05d02baae7269 ]
>
> So I think the commit is fine, and yes, it should be applied to
> stable, but i
Hi Gerd,
> > [Kasireddy, Vivek] Correct, that is exactly what I want -- make the Guest
> > wait
> > until it gets notified that the Host is completely done processing/using
> > the fb.
> > However, there can be two resources the guest can be made to wait on: wait
> > for
> > the new/current fb
Hi Paul,
Thank you for your review.
I will update all of this in V2.
Thanks,
Quanyang
On 5/18/21 1:09 AM, Paul Cercueil wrote:
Hi,
Le jeu., mai 13 2021 at 19:45:40 +0800, quanyang.w...@windriver.com a
écrit :
From: Quanyang Wang
For now, the functions zynqmp_disp_avbuf_enable/disable_audio
Hi Paul,
Thank you for your review.
I will update these in V2 patch.
Thanks,
Quanyang
On 5/18/21 12:48 AM, Paul Cercueil wrote:
Hi Quanyang,
Le jeu., mai 13 2021 at 19:45:39 +0800, quanyang.w...@windriver.com a
écrit :
From: Quanyang Wang
Add a new function is_layer_vid() to simplify the c
On Mon, 2021-05-17 at 17:25 +, Wei Liu wrote:
> On Mon, May 17, 2021 at 04:59:22AM -0700, Deepak Rawat wrote:
> > Maintainer for hyperv synthetic video device.
> >
> > Signed-off-by: Deepak Rawat
> > ---
> > MAINTAINERS | 16
> > 1 file changed, 16 insertions(+)
> >
> > dif
On Thu, Apr 29, 2021 at 12:28 PM Hsin-Yi Wang wrote:
>
> drm_dev_register() sets connector->registration_state to
> DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> drm_connector_set_panel_orientation() is first called after
> drm_dev_register(), it will fail several checks and results i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Some nouveau debug, amdgpu tests, and a regression fix from 105.
Releasing so 105 doesn't end up being used a lot with a regression.
Bas Nieuwenhuizen (1):
Revert "xf86drmMode: set FB_MODIFIERS flag when modifiers are supplied"
Dave Airlie (
On Wed, Apr 07, 2021 at 06:42:31PM +1000, Alistair Popple wrote:
> +static inline struct page *pfn_swap_entry_to_page(swp_entry_t entry)
> +{
> + struct page *p = pfn_to_page(swp_offset(entry));
> +
> + /*
> + * Any use of migration entries may only occur while the
> + * correspon
Hi, Alistair,
The overall patch looks good to me, however I have a few comments or questions
inlined below.
On Wed, Apr 07, 2021 at 06:42:35PM +1000, Alistair Popple wrote:
> Some devices require exclusive write access to shared virtual
> memory (SVM) ranges to perform atomic operations on that m
On Mon, May 17, 2021 at 6:09 PM Sasha Levin wrote:
>
> From: Tetsuo Handa
>
> [ Upstream commit ffb324e6f874121f7dce5bdae5e05d02baae7269 ]
So I think the commit is fine, and yes, it should be applied to
stable, but it's one of those "there were three different patches in
as many days to fix the
From: Tetsuo Handa
[ Upstream commit ffb324e6f874121f7dce5bdae5e05d02baae7269 ]
syzbot is reporting OOB write at vga16fb_imageblit() [1], for
resize_screen() from ioctl(VT_RESIZE) returns 0 without checking whether
requested rows/columns fit the amount of memory reserved for the graphical
screen
From: xinhui pan
[ Upstream commit ad2c28bd9a4083816fa45a7e90c2486cde8a9873 ]
BO would be added into swap list if it is validated into system domain.
If BO is validated again into non-system domain, say, VRAM domain. It
actually should not be in the swap list.
Signed-off-by: xinhui pan
Acked-b
On Tue, May 11, 2021 at 04:54:48PM +, Corentin Labbe wrote:
> Converts display/faraday,tve200.txt to yaml.
>
> Signed-off-by: Corentin Labbe
> ---
> .../bindings/display/faraday,tve200.txt | 54 ---
> .../bindings/display/faraday,tve200.yaml | 92 +++
> 2 f
And another thing:
On Tue, May 18, 2021 at 02:02:24AM +0300, Laurent Pinchart wrote:
> On Sat, May 15, 2021 at 10:46:55PM +0200, Marek Vasut wrote:
> > Decoder input LVDS format is a property of the decoder chip or even
> > its strapping. Add DT property data-mapping the same way lvds-panel
> > do
Hi Marek,
Thank you for the patch.
On Sat, May 15, 2021 at 10:46:56PM +0200, Marek Vasut wrote:
> Decoder input LVDS format is a property of the decoder chip or even
> its strapping. Handle data-mapping the same way lvds-panel does. In
> case data-mapping is not present, do nothing, since there a
Hi Marek,
Thank you for the patch.
On Sat, May 15, 2021 at 10:46:55PM +0200, Marek Vasut wrote:
> Decoder input LVDS format is a property of the decoder chip or even
> its strapping. Add DT property data-mapping the same way lvds-panel
> does, to define the LVDS data mapping.
The information cou
Hi Marek,
Thank you for the patch.
On Tue, May 18, 2021 at 12:43:36AM +0200, Marek Vasut wrote:
> Add missing spaces to make the diagrams readable, no functional change.
>
> Signed-off-by: Marek Vasut
> Cc: Laurent Pinchart
> Cc: Rob Herring
> Cc: Sam Ravnborg
> Cc: devicet...@vger.kernel.or
On Mon, May 17, 2021 at 3:15 PM Daniel Vetter wrote:
>
> On Mon, May 17, 2021 at 9:38 PM Christian König
> wrote:
> >
> > Am 17.05.21 um 17:04 schrieb Daniel Vetter:
> > > On Mon, May 17, 2021 at 04:11:18PM +0200, Christian König wrote:
> > >> We had a long outstanding problem in amdgpu that buff
Add missing spaces to make the diagrams readable, no functional change.
Signed-off-by: Marek Vasut
Cc: Laurent Pinchart
Cc: Rob Herring
Cc: Sam Ravnborg
Cc: devicet...@vger.kernel.org
To: dri-devel@lists.freedesktop.org
---
V2: Replace all the other tabs too
---
.../bindings/display/panel/lvd
Hi Daniel,
On Mon, 17 May 2021 17:29:35 +0200 Daniel Vetter wrote:
>
> On Mon, May 10, 2021 at 9:30 AM Christoph Hellwig wrote:
> >
> > On Mon, May 10, 2021 at 09:16:58AM +0200, Daniel Vetter wrote:
> > > > End result: not pulling it, unless somebody can explain to me in small
> > > > words wh
On 5/17/21 3:11 PM, Christoph Hellwig wrote:
On Mon, May 17, 2021 at 04:09:42PM +0300, Serge Belyshev wrote:
Christoph Hellwig writes:
As an ad-hoc experiment: can you replace the call to remap_pfn_range
with remap_pfn_range_notrack (and export it if you build i915 modular)
in remap_io_sg
On Mon, May 10, 2021 at 11:18:51PM -0500, Bjorn Andersson wrote:
> From: Rob Clark
>
> Add SC8180x to the hardware catalog, for initial support for the
> platform. Due to limitations in the DP driver only one of the four DP
> interfaces is left enabled.
>
> The SC8180x platform supports the newl
On Tue, 18 May 2021 at 06:10, Thomas Zimmermann wrote:
>
> Hi
>
> Am 17.05.21 um 21:32 schrieb Daniel Stone:
> > Hi,
> >
> > On Mon, 17 May 2021 at 20:12, Thomas Zimmermann wrote:
> >> Am 17.05.21 um 09:40 schrieb Daniel Vetter:
> >>> We have, it's called drivers/gpu. Feel free to rename to drive
On Mon, May 17, 2021 at 10:10 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 17.05.21 um 21:32 schrieb Daniel Stone:
> > Hi,
> >
> > On Mon, 17 May 2021 at 20:12, Thomas Zimmermann wrote:
> >> Am 17.05.21 um 09:40 schrieb Daniel Vetter:
> >>> We have, it's called drivers/gpu. Feel free to rename to dr
On Mon, May 17, 2021 at 04:11:27PM +0200, Christian König wrote:
> Add usage flags for shared fences and improve the documentation.
>
> This allows driver to better specify what shared fences
> are doing with the resource.
>
> Signed-off-by: Christian König
> diff --git a/drivers/gpu/drm/ttm/tt
Hi,
On Tue, May 11, 2021 at 4:17 PM Doug Anderson wrote:
>
> Hi,
>
> On Tue, May 11, 2021 at 11:12 AM wrote:
> >
> > On 01-05-2021 03:08, Doug Anderson wrote:
> > > Hi,
> > >
> > > On Fri, Apr 30, 2021 at 8:10 AM wrote:
> > >>
> > >> On 30-04-2021 02:33, Doug Anderson wrote:
> > >> > Hi,
> > >>
Hi,
On Fri, May 14, 2021 at 4:16 AM Jani Nikula wrote:
>
> On Fri, 07 May 2021, Lyude Paul wrote:
> > On Fri, 2021-05-07 at 17:00 -0500, Bjorn Andersson wrote:
> >> On Fri 07 May 16:18 CDT 2021, Lyude Paul wrote:
> >>
> >> > Adding ville from Intel to also get their take on this.
> >> >
> >> > I
Hi,
On Mon, May 3, 2021 at 2:59 PM Douglas Anderson wrote:
>
> The of_find_i2c_adapter_by_node() could end up failing to find an
> adapter in certain conditions. Specifically it's possible that
> of_dev_or_parent_node_match() could end up finding an I2C client in
> the list and cause bus_find_dev
On Mon, May 17, 2021 at 9:38 PM Christian König
wrote:
>
> Am 17.05.21 um 17:04 schrieb Daniel Vetter:
> > On Mon, May 17, 2021 at 04:11:18PM +0200, Christian König wrote:
> >> We had a long outstanding problem in amdgpu that buffers exported to
> >> user drivers by DMA-buf serialize all command s
Hi
Am 17.05.21 um 22:00 schrieb Daniel Vetter:
Sharing common code among subsystems is not a problem. Many of our
more-sophisticated helpers are located in DRM because no other
subsystems have the requirements yet. Maybe AI now has and we can move
the rsp shareable code to a common location. Bu
On Mon, May 17, 2021 at 2:38 PM Christian König
wrote:
>
> Am 17.05.21 um 17:04 schrieb Daniel Vetter:
> > On Mon, May 17, 2021 at 04:11:18PM +0200, Christian König wrote:
> >> We had a long outstanding problem in amdgpu that buffers exported to
> >> user drivers by DMA-buf serialize all command s
Hi
Am 17.05.21 um 21:32 schrieb Daniel Stone:
Hi,
On Mon, 17 May 2021 at 20:12, Thomas Zimmermann wrote:
Am 17.05.21 um 09:40 schrieb Daniel Vetter:
We have, it's called drivers/gpu. Feel free to rename to drivers/xpu or
think G as in General, not Graphisc.
I hope this was a joke.
Just so
This is really just a revert of commit 58074b08c04a ("drm/bridge:
ti-sn65dsi86: Read EDID blob over DDC"), resolving conflicts.
The old code failed to read the EDID properly in a very important
case: before the bridge's pre_enable() was called. The way things need
to work:
1. Read the EDID.
2. Bas
We want to provide our panel with access to the DP AUX channel. The
way to do this is to let our panel be a child of ours using the fancy
new DP AUX bus support.
Signed-off-by: Douglas Anderson
---
Changes in v7:
- Patch to support for DP AUX bus on ti-sn65dsi86 new for v7.
drivers/gpu/drm/bri
If panel-simple is instantiated as a DP AUX bus endpoint then we have
access to the DP AUX bus. Let's stash it in the panel-simple
structure, leaving it NULL for the cases where the panel is
instantiated in other ways.
If we happen to have access to the DP AUX bus and we weren't provided
the ddc-i
Putting the panel under the bridge chip (under the aux-bus node)
allows the panel driver to get access to the DP AUX bus, enabling all
sorts of fabulous new features.
While we're at this, get rid of a level of hierarchy for the panel
node. It doesn't need "ports / port" and can just have a "port"
Historically "simple" eDP panels have been handled by panel-simple
which is a basic platform_device. In the device tree, the panel node
was at the top level and not connected to anything else.
Let's change it so that, instead, panels can be represented as being
children of the "DP AUX bus". Essent
We want to be able to list an eDP panel as a child of a ti-sn65dsi86
node to represent the fact that the panel is connected to the bridge's
DP AUX bus. Though the panel and the bridge chip are connected in
several ways, the DP AUX bus is the primary control interface between
the two and thus makes
On its own, this change looks a little strange and doesn't do too much
useful. To understand why we're doing this we need to look forward to
future patches where we're going to probe our panel using the new DP
AUX bus. See the patch ("drm/bridge: ti-sn65dsi86: Add support for the
DP AUX bus").
Let
The panel-simple driver can already have devices instantiated as
platform devices or MIPI DSI devices. Let's add a 3rd way to
instantiate it: as DP AUX endpoint devices.
At the moment there is no benefit to instantiating it in this way,
but:
- In the next patch we'll give it access to the DDC chan
These are described in panel-common.yaml but if I don't list them in
panel-simple then I get yells when running 'dt_binding_check' in a
future patch. List them along with other properties that seem to be
listed in panel-simple for similar reasons.
Signed-off-by: Douglas Anderson
---
I didn't spen
The PM Runtime docs specifically call out the need to call
pm_runtime_dont_use_autosuspend() in the remove() callback if
pm_runtime_use_autosuspend() was called in probe():
> Drivers in ->remove() callback should undo the runtime PM changes done
> in ->probe(). Usually this means calling pm_runtim
The primary goal of this series is to try to properly fix EDID reading
for eDP panels using the ti-sn65dsi86 bridge.
Previously we had a patch that added EDID reading but it turned out
not to work at bootup. This caused some extra churn at bootup as we
tried (and failed) to read the EDID several t
On Mon, May 17, 2021 at 9:49 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 17.05.21 um 21:23 schrieb Alex Deucher:
> > On Mon, May 17, 2021 at 3:12 PM Thomas Zimmermann
> wrote:
> >>
> >> Hi
> >>
> >> Am 17.05.21 um 09:40 schrieb Daniel Vetter:
> >>> On Fri, May 14, 2021 at 11:00:38AM +0200, Arnd Ber
Ok, then putting that on my TODO list for tomorrow.
I've already found a problem with how we finish of fences, going to
write more on this tomorrow.
Christian.
Am 17.05.21 um 21:46 schrieb Andrey Grodzovsky:
Yep, you can take a look.
Andrey
On 2021-05-17 3:39 p.m., Christian König wrote:
Hi
Am 17.05.21 um 21:23 schrieb Alex Deucher:
On Mon, May 17, 2021 at 3:12 PM Thomas Zimmermann
wrote:
Hi
Am 17.05.21 um 09:40 schrieb Daniel Vetter:
On Fri, May 14, 2021 at 11:00:38AM +0200, Arnd Bergmann wrote:
On Fri, May 14, 2021 at 10:34 AM Greg Kroah-Hartman
wrote:
On Thu, May 13,
Yep, you can take a look.
Andrey
On 2021-05-17 3:39 p.m., Christian König wrote:
You need to note who you are pinging here.
I'm still assuming you wait for feedback from Daniel. Or should I take a
look?
Christian.
Am 17.05.21 um 16:40 schrieb Andrey Grodzovsky:
Ping
Andrey
On 2021-05-14
You need to note who you are pinging here.
I'm still assuming you wait for feedback from Daniel. Or should I take a
look?
Christian.
Am 17.05.21 um 16:40 schrieb Andrey Grodzovsky:
Ping
Andrey
On 2021-05-14 10:42 a.m., Andrey Grodzovsky wrote:
Ping
Andrey
On 2021-05-12 10:26 a.m., Andre
On Mon, May 17, 2021 at 9:23 PM Alex Deucher wrote:
>
> On Mon, May 17, 2021 at 3:12 PM Thomas Zimmermann wrote:
> >
> > Hi
> >
> > Am 17.05.21 um 09:40 schrieb Daniel Vetter:
> > > On Fri, May 14, 2021 at 11:00:38AM +0200, Arnd Bergmann wrote:
> > >> On Fri, May 14, 2021 at 10:34 AM Greg Kroah-H
On 2021-05-17 12:48 p.m., Sebastian Wick wrote:
On 2021-05-17 10:57, Pekka Paalanen wrote:
On Fri, 14 May 2021 17:05:11 -0400
Harry Wentland wrote:
On 2021-04-27 10:50 a.m., Pekka Paalanen wrote:
> On Mon, 26 Apr 2021 13:38:49 -0400
> Harry Wentland wrote:
...
>> ## Mastering Luminance
Am 17.05.21 um 17:04 schrieb Daniel Vetter:
On Mon, May 17, 2021 at 04:11:18PM +0200, Christian König wrote:
We had a long outstanding problem in amdgpu that buffers exported to
user drivers by DMA-buf serialize all command submissions using them.
In other words we can't compose the buffer with
Hi,
On Mon, 17 May 2021 at 20:12, Thomas Zimmermann wrote:
> Am 17.05.21 um 09:40 schrieb Daniel Vetter:
> > We have, it's called drivers/gpu. Feel free to rename to drivers/xpu or
> > think G as in General, not Graphisc.
>
> I hope this was a joke.
>
> Just some thoughts:
>
> AFAICT AI first cam
Access to those must be prevented post pci_remove
v6: Drop BOs list, unampping VRAM BAR is enough.
v8:
Add condition of xgmi.connected_to_cpu to MTTR
handling and remove MTTR handling from the old place.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 26 ++
On Mon, May 17, 2021 at 3:12 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 17.05.21 um 09:40 schrieb Daniel Vetter:
> > On Fri, May 14, 2021 at 11:00:38AM +0200, Arnd Bergmann wrote:
> >> On Fri, May 14, 2021 at 10:34 AM Greg Kroah-Hartman
> >> wrote:
> >>> On Thu, May 13, 2021 at 01:00:26PM +0200, M
On 2021-05-17 2:56 p.m., Alex Deucher wrote:
On Mon, May 17, 2021 at 2:46 PM Andrey Grodzovsky
wrote:
On 2021-05-17 1:43 p.m., Alex Deucher wrote:
On Wed, May 12, 2021 at 10:27 AM Andrey Grodzovsky
wrote:
Access to those must be prevented post pci_remove
v6: Drop BOs list, unampping VRA
Am 17.05.21 um 16:30 schrieb Daniel Vetter:
[SNIP]
Could be that i915 has some special code for that, but on my laptop
I only see the X server under the "clients" debugfs file.
Yes we have special code in i915 for this. Part of this series we are
discussing here.
Ah, yeah you should mention th
Hi
Am 17.05.21 um 09:40 schrieb Daniel Vetter:
On Fri, May 14, 2021 at 11:00:38AM +0200, Arnd Bergmann wrote:
On Fri, May 14, 2021 at 10:34 AM Greg Kroah-Hartman
wrote:
On Thu, May 13, 2021 at 01:00:26PM +0200, Maciej Kwapulinski wrote:
Dear kernel maintainers,
This submission is a kernel d
On Monday, May 17th, 2021 at 8:16 PM, Nieto, David M
wrote:
> Btw is DRM_MAJOR 226 consider uapi? I don't see it in uapi headers.
It's not in the headers, but it's de facto uAPI, as seen in libdrm:
> git grep 226
xf86drm.c
99:#define DRM_MAJOR 226 /* Linux */
On Mon, May 17, 2021 at 2:46 PM Andrey Grodzovsky
wrote:
>
>
>
> On 2021-05-17 1:43 p.m., Alex Deucher wrote:
> > On Wed, May 12, 2021 at 10:27 AM Andrey Grodzovsky
> > wrote:
> >>
> >> Access to those must be prevented post pci_remove
> >>
> >> v6: Drop BOs list, unampping VRAM BAR is enough.
>
On 2021-05-17 1:43 p.m., Alex Deucher wrote:
On Wed, May 12, 2021 at 10:27 AM Andrey Grodzovsky
wrote:
Access to those must be prevented post pci_remove
v6: Drop BOs list, unampping VRAM BAR is enough.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 24
On Mon, May 17, 2021 at 7:05 PM Jason Ekstrand wrote:
>
> On Mon, May 17, 2021 at 8:40 AM Daniel Vetter wrote:
> >
> > On Fri, May 14, 2021 at 02:13:57PM -0500, Jason Ekstrand wrote:
> > > On Tue, May 4, 2021 at 3:33 PM Daniel Vetter wrote:
> > > >
> > > > On Mon, May 03, 2021 at 10:57:40AM -050
https://bugzilla.kernel.org/show_bug.cgi?id=212019
Bernie Innocenti (ber...@codewiz.org) changed:
What|Removed |Added
CC||ber...@codewiz.org
[Public]
Cycling some of the Nvidia/nouveau guys here too.
I think there is a benefit on trying to estandarize how fdinfo can be used to
expose per engine and device memory utilization.
Another of the advantages of going the /proc/ way instead of the sysfs debugfs
approach is that you inherit
On Mon, 17 May 2021 at 19:12, Daniel Vetter wrote:
>
> On Mon, May 17, 2021 at 10:55 AM Greg Kroah-Hartman
> wrote:
> >
> > On Mon, May 17, 2021 at 10:49:09AM +0200, Daniel Vetter wrote:
> > > On Mon, May 17, 2021 at 10:00 AM Greg Kroah-Hartman
> > > wrote:
> > > >
> > > > On Mon, May 17, 2021 a
[AMD Official Use Only]
The format is simple:
: %
we also have entries for the memory mapped:
mem : KiB
On my submission
https://lists.freedesktop.org/archives/amd-gfx/2021-May/063149.html I added a
python script to print out the info. It has a CPU usage lower that top, for
example.
To b
On Mon, May 17, 2021 at 03:55:59PM +0200, Daniel Vetter wrote:
> On Fri, May 14, 2021 at 01:05:33PM -0700, Matthew Brost wrote:
> > On Wed, May 12, 2021 at 10:34:59AM +0200, Daniel Vetter wrote:
> > > On Tue, May 11, 2021 at 11:44:28AM -0700, Matthew Brost wrote:
> > > > On Tue, May 11, 2021 at 05:
On Wed, May 12, 2021 at 10:27 AM Andrey Grodzovsky
wrote:
>
> Access to those must be prevented post pci_remove
>
> v6: Drop BOs list, unampping VRAM BAR is enough.
>
> Signed-off-by: Andrey Grodzovsky
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 24 +++---
> drivers/gpu/
Reviewed-by: Alex Deucher
On Mon, May 17, 2021 at 10:40 AM Andrey Grodzovsky
wrote:
>
> Ping
>
> Andrey
>
> On 2021-05-14 10:42 a.m., Andrey Grodzovsky wrote:
> > Ping
> >
> > Andrey
> >
> > On 2021-05-12 10:26 a.m., Andrey Grodzovsky wrote:
> >> If removing while commands in flight you cannot w
On 2021-05-14 23:07, Harry Wentland wrote:
Use the new DRM RFC doc section to capture the RFC previously only
described in the cover letter at
https://patchwork.freedesktop.org/series/89506/
Update the RFC based on feedback received:
* don't use color_encoding property to define color space
*
On Mon, May 17, 2021 at 04:59:22AM -0700, Deepak Rawat wrote:
> Maintainer for hyperv synthetic video device.
>
> Signed-off-by: Deepak Rawat
> ---
> MAINTAINERS | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index bd7aff0c120f..2613425514
On Sun, May 16, 2021 at 06:14:32PM +0100, Emil Velikov wrote:
> From: Vivek Das Mohapatra
>
> This patch is to do with seamless handover, eg when the sequence is
> bootloader → plymouth → desktop.
>
> It switches the vga arbiter from the "other" GPU to the default one
> (intel in this case), so
On Sat, May 15, 2021 at 1:01 PM Joe Perches wrote:
>
> /n should be \n
>
> Signed-off-by: Joe Perches
Applied. Thanks!
Alex
> ---
> drivers/gpu/drm/amd/display/dc/dcn30/dcn30_resource.c | 2 +-
> drivers/gpu/drm/amd/display/dc/dcn301/dcn301_resource.c | 2 +-
> drivers/gpu/drm/amd/display/
Hi,
Le jeu., mai 13 2021 at 19:45:40 +0800, quanyang.w...@windriver.com a
écrit :
From: Quanyang Wang
For now, the functions zynqmp_disp_avbuf_enable/disable_audio and
zynqmp_disp_avbuf_enable/disable_video are all programming the
register
AV_BUF_OUTPUT_AUDIO_VIDEO_SELECT to select the outpu
On Mon, 17 May 2021 at 14:11, Christoph Hellwig wrote:
>
> On Mon, May 17, 2021 at 04:09:42PM +0300, Serge Belyshev wrote:
> > Christoph Hellwig writes:
> >
> > > As an ad-hoc experiment: can you replace the call to remap_pfn_range
> > > with remap_pfn_range_notrack (and export it if you build i
On Mon, May 17, 2021 at 8:40 AM Daniel Vetter wrote:
>
> On Fri, May 14, 2021 at 02:13:57PM -0500, Jason Ekstrand wrote:
> > On Tue, May 4, 2021 at 3:33 PM Daniel Vetter wrote:
> > >
> > > On Mon, May 03, 2021 at 10:57:40AM -0500, Jason Ekstrand wrote:
> > > > This means that the proto-context ne
On 2021-05-17 10:57, Pekka Paalanen wrote:
On Fri, 14 May 2021 17:05:11 -0400
Harry Wentland wrote:
On 2021-04-27 10:50 a.m., Pekka Paalanen wrote:
> On Mon, 26 Apr 2021 13:38:49 -0400
> Harry Wentland wrote:
...
>> ## Mastering Luminances
>>
>> Now we are able to use the PQ 2084 EOTF to
Hi Quanyang,
Le jeu., mai 13 2021 at 19:45:39 +0800, quanyang.w...@windriver.com a
écrit :
From: Quanyang Wang
Add a new function is_layer_vid() to simplify the code that
judges if a layer is the video layer.
Signed-off-by: Quanyang Wang
---
drivers/gpu/drm/xlnx/zynqmp_disp.c | 39
+++
On 2021-05-17 10:27, Joerg Roedel wrote:
On Fri, Apr 30, 2021 at 08:20:10PM +0800, Kevin Tang wrote:
Cc Robin & Joerg
This is just some GPU internal MMU being used here, it seems. It doesn't
use the IOMMU core code, so no Ack needed from the IOMMU side.
Except the actual MMU being used is d
Hi,
On 5/16/21 4:27 PM, Anirudh Rayabharam wrote:
The return value of hga_card_detect() is not properly handled causing
the probe to succeed even though hga_card_detect() failed. Since probe
succeeds, hgafb_open() can be called which will end up operating on an
unmapped hga_vram. This results in
1 - 100 of 201 matches
Mail list logo
