: arm-randconfig-r021-20200925 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
c32e69b2ce7abfb151a87ba363ac9e25abf7d417)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin
Bandwidth code was being used as test link rate. Fix this by converting
bandwidth code to test link rate
Do not reset voltage and pre-emphasis level during IRQ HPD attention
interrupt. Also fix pre-emphasis parsing during test link status process
Signed-off-by: Tanmay Shah
---
drivers/gpu/drm/m
Reuse/abuse the pagepool code from the network 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: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc:
The heap-helpers code was not as generic as initially hoped
and it is now not being used, so remove it from the tree.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequie
While the system heap can return non-contiguous pages,
try to allocate larger order pages if possible.
This will allow slight performance gains and make implementing
page pooling easier.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasa
Since the heap-helpers logic ended up not being as generic as
hoped, move the heap-helpers dma_buf_ops implementations into
the cma_heap directly.
This will allow us to remove the heap_helpers code in a following
patch.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hri
In preparation for some patches to optmize the system
heap code, rework the dmabuf exporter to utilize sgtables rather
then pageslists for tracking the associated pages.
This will allow for large order page allocations, as well as
more efficient page pooling.
In doing so, the system heap stops us
Hey All,
So this patch series contains a series of performance
optimizations to the dma-buf system heap.
Unfortunately, in working these up, I realized the heap-helpers
infrastructure we tried to add to miniimize code duplication is
not as generic as we intended. For some heaps it makes sense to
This patch is basically a port of Ørjan Eide's similar patch for ION
https://lore.kernel.org/lkml/20200414134629.54567-1-orjan.e...@arm.com/
Only sync the sg-list of dma-buf heap attachment when the attachment
is actually mapped on the device.
dma-bufs may be synced at any time. It can be reache
tree: git://people.freedesktop.org/~agd5f/linux.git
amd-staging-drm-next-vangogh
head: 6067a749d66ef3815908c86ee0b08733e391955f
commit: a7479b81da768e2a9022f62c03b51020d59eae6e [35/47] drm/amd/powerplay: add
vangogh ppt into swSMU
config: alpha-allyesconfig (attached as .config)
compiler: alp
transaction
config: x86_64-randconfig-r035-20200925 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
c32e69b2ce7abfb151a87ba363ac9e25abf7d417)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin
Fix the incorrect function prototype for dp_debug_get()
in the dp_debug module to address compilation warning.
Also add prototype for msm_dp_debugfs_init() for fixing compilation
issue with other defconfigs.
changes in v2:
- add prototype for msm_dp_debugfs_init()
Fixes: f913454aae8e ("dr
On Thu, 24 Sep 2020 15:58:42 +0200 Christoph Hellwig wrote:
> this series removes alloc_vm_area, which was left over from the big
> vmalloc interface rework. It is a rather arkane interface, basicaly
> the equivalent of get_vm_area + actually faulting in all PTEs in
> the allocated area. It was
tree: git://people.freedesktop.org/~agd5f/linux.git
amd-staging-drm-next-vangogh
head: 6067a749d66ef3815908c86ee0b08733e391955f
commit: 614e7ac92979c4fe35cca713fa282609839e1be1 [494/544] drm/amdgpu:
Implement new guest side VF2PF message transaction
config: arm-randconfig-r021-20200925
Hi Tobias,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next linus/master v5.9-rc6 next-20200925]
[cannot apply to drm/drm-next]
[If
On Fri, Sep 25, 2020 at 6:08 PM Lyude Paul wrote:
>
> On Tue, 2020-09-22 at 17:22 -0400, Ilia Mirkin wrote:
> > On Tue, Sep 22, 2020 at 5:14 PM Lyude Paul wrote:
> > > On Tue, 2020-09-22 at 17:10 -0400, Ilia Mirkin wrote:
> > > > Can we use 6bpc on arbitrary DP monitors, or is there a capability
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: 8f0ba3310c12c3943a8cac39a774e83f55288424
commit: 614e7ac92979c4fe35cca713fa282609839e1be1 [494/499] drm/amdgpu:
Implement new guest side VF2PF message transaction
config: alpha-allyesconfig (attached as .config)
com
On Tue, 2020-09-22 at 17:22 -0400, Ilia Mirkin wrote:
> On Tue, Sep 22, 2020 at 5:14 PM Lyude Paul wrote:
> > On Tue, 2020-09-22 at 17:10 -0400, Ilia Mirkin wrote:
> > > Can we use 6bpc on arbitrary DP monitors, or is there a capability for
> > > it? Maybe only use 6bpc if display_info.bpc == 6 an
Commit 7c49abb4c2f8 ("drm/rockchip: cdn-dp-core: Make
cdn_dp_core_suspend/resume static")
introduced the following warning in some builds:
cdn-dp-core.c:1124:12: warning: ‘cdn_dp_resume’ defined but not used
1124 | static int cdn_dp_resume(struct device *dev)
|^
Fi
Fix a newly introduced build breakge in drm-misc-next
Patch 1/2 should be applied to drm-misc-next
Also fix a warning in the same driver - the warning is present in v5.8
Patch 2/2 is a drm-misc-fixes candidate
Sam
Sam Ravnborg (2):
drm/rockchip: fix build due to undefined drm_gem_c
Commit 0d590af3140d ("drm/rockchip: Convert to drm_gem_object_funcs")
introduced the following build error:
rockchip_drm_gem.c:304:13: error: ‘drm_gem_cma_vm_ops’ undeclared here
304 | .vm_ops = &drm_gem_cma_vm_ops,
| ^~
| drm_gem_mmap_obj
Fi
Hi everybody,
I think it's time to finally move our wiki from the old infrastructure
over to gitlab pages.
This comes with several benefits:
* full control through git over the ikiwiki pipeline (setup files,
plugins, system packages, ...)
* random users are able to create MRs against the wiki as
On Tue, Sep 22, 2020 at 2:28 AM Marek Szyprowski
wrote:
>
> Hi Alex,
>
> On 22.09.2020 01:15, Alex Goins wrote:
> > Tested-by: Alex Goins
> >
> > This change fixes a regression with drm_prime_sg_to_page_addr_arrays() and
> > AMDGPU in v5.9.
>
> Thanks for testing!
>
> > Commit 39913934 similarly
Tested this on GeForce GT 710
Tested-by: Nirmoy Das
On 9/25/20 4:55 PM, Christian König wrote:
We already implemented the fault handler ourself,
just open code what is necessary here.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 50 ++-
Tested-by: Nirmoy Das
On 9/25/20 4:55 PM, Christian König wrote:
Implement the fault handler ourself using the provided TTM functions.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 20 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +-
driver
Hi Thomas,
On Fri, Sep 25, 2020 at 01:55:57PM +0200, Thomas Zimmermann wrote:
> Dma-buf provides vmap() and vunmap() for retriving and releasing mappings
> of dma-buf memory in kernel address space. The functions operate with plain
> addresses and the assumption is that the memory can be accessed
The pull request you sent on Fri, 25 Sep 2020 11:45:04 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-09-25
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/574ec42e1a9c4bfb8b2eef8d801a77e92bcea76a
Thank you!
--
Deet-doot-dot, I am a bot.
https://k
On Thu, 2020-09-24 at 17:46 -0600, Kevin Chowski wrote:
> cc back a few others who were unintentionally dropped from the thread
> earlier.
>
> Someone (at Google) helped me dig into this a little more and they
> found a document titled "eDP Backlight Brightness bit alignment" sent
> out for review
On Fri, Sep 25, 2020 at 07:02:47PM +0300, Ville Syrjälä wrote:
> On Thu, Sep 24, 2020 at 09:48:03PM +0300, Imre Deak wrote:
> > Add the helpers and register definitions needed to read out the common
> > and per-PHY LTTPR capabilities and perform link training in the LTTPR
> > non-transparent mode.
On 25/09/2020 15:00, Laurent Pinchart wrote:
> On Fri, Sep 25, 2020 at 10:36:44AM +0300, Tomi Valkeinen wrote:
>> On 24/09/2020 14:48, Laurent Pinchart wrote:
>>> Hi Tomi,
>>>
>>> Thank you for the patch.
>>>
>>> On Wed, Sep 23, 2020 at 11:30:57AM +0300, Tomi Valkeinen wrote:
On x64 we get:
>>
On Thu, Sep 24, 2020 at 09:48:03PM +0300, Imre Deak wrote:
> Add the helpers and register definitions needed to read out the common
> and per-PHY LTTPR capabilities and perform link training in the LTTPR
> non-transparent mode.
>
> v2:
> - Add drm_dp_dpcd_read_phy_link_status() and DP_PHY_LTTPR()
Hi all,
Friendly ping: who can take this?
Thanks
--
Gustavo
On 9/10/20 05:21, Gustavo A. R. Silva wrote:
> Fix inconsistent IS_ERR and PTR_ERR in i915_gem_object_copy_blt().
>
> The proper pointer to be passed as argument to PTR_ERR() is vma[1].
>
> This bug was detected with the help of Cocci
Hi Christian
Am 25.09.20 um 16:54 schrieb Christian König:
> Maybe MMU notifiers? But honestly I don't know for sure.
I checked. In my current config MMU_NOTIFIERS is y and DRM_AMDGPU is n.
So it shouldn't have triggered the rebuilds, I guess.
Anyway, thanks for trying to help.
Best regards
Tho
Hi Daniel
Am 29.06.20 um 11:06 schrieb Daniel Vetter:
> On Thu, Jun 25, 2020 at 02:00:05PM +0200, Thomas Zimmermann wrote:
>> The simplekms driver is a DRM driver for simplefb framebuffers as
>> provided by the kernel's boot code. This driver enables basic
>> graphical output on many different gra
Another one bites the dust.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 22 --
include/drm/ttm/ttm_bo_driver.h | 3 ---
2 files changed, 25 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 991ef132e10
We already implemented the fault handler ourself,
just open code what is necessary here.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 50 ++-
drivers/gpu/drm/nouveau/nouveau_bo.h | 1 +
drivers/gpu/drm/nouveau/nouveau_ttm.c | 10 +++---
3 f
Just check earlier if a BO can be page faulted in the first place.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 98a00
Implement the fault handler ourself using the provided TTM functions.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 20 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 40 +++---
3 file
We already implemented the fault handler ourself,
just open code what is necessary here.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_object.c | 22 +++
drivers/gpu/drm/radeon/radeon_object.h | 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c| 29 +++
Hi
Am 29.06.20 um 10:40 schrieb Daniel Vetter:
> On Thu, Jun 25, 2020 at 02:00:03PM +0200, Thomas Zimmermann wrote:
>> The memcpy's destination buffer might have a different pitch than the
>> source. Support different pitches as function argument.
>>
>> Signed-off-by: Thomas Zimmermann
>
> Revie
Maybe MMU notifiers? But honestly I don't know for sure.
Christian.
Am 25.09.20 um 16:29 schrieb Thomas Zimmermann:
Hi,
whenever I change the option CONFIG_AMDGPU, I have to rebuild the whole
kernel. I guess it auto-selects some architecture-specific feature. That
full rebuild might be avoidab
Hi Yannick.
On Fri, Sep 25, 2020 at 12:22:33PM +0200, Yannick Fertre wrote:
> Standardize on the dev_ based logging and drop the include of drm_print.h.
The patchs filas to drop the include mentioned here.
> Remove useless dsi_color_from_mipi function.
IMO the dsi_color_from_mipi() was nice, and
On Fri, Sep 25, 2020 at 01:31:51PM +0200, Arnd Bergmann wrote:
> On Thu, Sep 24, 2020 at 10:54 PM Sam Ravnborg wrote:
> >
> > Hi Daniel/Arnd.
> >
> > On Fri, Sep 18, 2020 at 02:48:08PM +0200, Daniel Vetter wrote:
> > > On Fri, Sep 18, 2020 at 12:08:10PM +0200, Arnd Bergmann wrote:
> > > > The fbde
Hi,
whenever I change the option CONFIG_AMDGPU, I have to rebuild the whole
kernel. I guess it auto-selects some architecture-specific feature. That
full rebuild might be avoidable if I could enable that feature permanently.
Any ideas what this could be and how to avoid the full rebuilt?
Best re
Compute new timings to get a framerate of 50fps with a pixel clock
@54Mhz.
Signed-off-by: Yannick Fertre
---
drivers/gpu/drm/panel/panel-raydium-rm68200.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-raydium-rm68200.c
b/drivers/gpu
On Thu, 24 Sep 2020 at 14:59, Christoph Hellwig wrote:
>
> i915_gem_object_map implements fairly low-level vmap functionality in
> a driver. Split it into two helpers, one for remapping kernel memory
> which can use vmap, and one for I/O memory that uses vmap_pfn.
>
> The only practical differenc
On Fri, Sep 25, 2020 at 3:40 PM Christian König
wrote:
>
> Am 25.09.20 um 15:17 schrieb Daniel Vetter:
> > [SNIP]
> >> Eviction is not a problem because the driver gets asked where to put an
> >> evicted BO and then TTM does all the moving.
> > Hm I guess then I don't quite get where you see the p
On 25/09/2020 14:39, Maor Gottlieb wrote:
On 9/25/2020 3:33 PM, Tvrtko Ursulin wrote:
On 25/09/2020 13:18, Maor Gottlieb wrote:
On 9/25/2020 2:55 PM, Jason Gunthorpe wrote:
On Fri, Sep 25, 2020 at 10:13:30AM +0300, Leon Romanovsky wrote:
diff --git a/tools/testing/scatterlist/main.c
b/tool
Am 25.09.20 um 15:17 schrieb Daniel Vetter:
[SNIP]
Eviction is not a problem because the driver gets asked where to put an
evicted BO and then TTM does all the moving.
Hm I guess then I don't quite get where you see the ping-pong
happening, I thought that only happens for evicting stuff.
No,
Hi Maxime,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[cannot apply to shawnguo/for-next drm-intel/for-linux-next linus/master
anholt/for-next v5.9-rc6 next-20200925]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when
On Fri, Sep 25, 2020 at 06:13:00AM -0400, Peilin Ye wrote:
> Hi all!
>
> On Fri, Sep 25, 2020 at 08:46:04AM +0200, Jiri Slaby wrote:
> > > In order to perform a reliable range check, fbcon_get_font() needs to know
> > > `FONTDATAMAX` for each built-in font under lib/fonts/. Unfortunately, we
> > >
On Fri, Sep 25, 2020 at 11:34 AM Christian König
wrote:
>
> Am 25.09.20 um 10:18 schrieb Daniel Vetter:
> > On Fri, Sep 25, 2020 at 10:16 AM Daniel Vetter wrote:
> >> On Fri, Sep 25, 2020 at 9:39 AM Christian König
> >> wrote:
> >>> Am 25.09.20 um 01:14 schrieb Dave Airlie:
> On Thu, 24 Sep
On 24/09/2020 14:58, Christoph Hellwig wrote:
i915_gem_object_map implements fairly low-level vmap functionality in
a driver. Split it into two helpers, one for remapping kernel memory
which can use vmap, and one for I/O memory that uses vmap_pfn.
The only practical difference is that alloc_v
On 24/09/2020 14:58, Christoph Hellwig wrote:
shmem_pin_map somewhat awkwardly reimplements vmap using
alloc_vm_area and manual pte setup. The only practical difference
is that alloc_vm_area prefeaults the vmalloc area PTEs, which doesn't
seem to be required here (and could be added to vmap us
On 24/09/2020 14:58, Christoph Hellwig wrote:
kmap for !PageHighmem is just a convoluted way to say page_address,
and kunmap is a no-op in that case.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
On 25/09/2020 13:18, Maor Gottlieb wrote:
On 9/25/2020 2:55 PM, Jason Gunthorpe wrote:
On Fri, Sep 25, 2020 at 10:13:30AM +0300, Leon Romanovsky wrote:
diff --git a/tools/testing/scatterlist/main.c
b/tools/testing/scatterlist/main.c
index 0a1464181226..4899359a31ac 100644
+++ b/tools/testing/
On 25/09/2020 12:58, Jason Gunthorpe wrote:
On Fri, Sep 25, 2020 at 12:41:29PM +0100, Tvrtko Ursulin wrote:
On 25/09/2020 08:13, Leon Romanovsky wrote:
On Thu, Sep 24, 2020 at 09:21:20AM +0100, Tvrtko Ursulin wrote:
On 22/09/2020 09:39, Leon Romanovsky wrote:
From: Maor Gottlieb
Extend
From: Swati Sharma
In this patch enabled support for link status and recovery in i915
driver. HDMI link loss indication to upstream DP source is indicated
via IRQ_HPD. This is followed by reading of HDMI link configuration
status (HDMI_TX_LINK_ACTIVE_STATUS). If the PCON → HDMI 2.1 link status
is
From: Swati Sharma
This patch parses MAX_FRL field to get the MAX rate in Gbps that
the HDMI 2.1 panel can support in FRL mode. Source need this
field to determine the optimal rate between the source and sink
during FRL training.
Signed-off-by: Sharma, Swati2
Signed-off-by: Ankit Nautiyal
---
This patch adds support for configuring a PCON device,
connected as a DP branched device to enable FRL Link training
with a HDMI2.1 + sink.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_dp_helper.c | 305
include/drm/drm_dp_helper.h | 81 +
2
From: Swati Sharma
This patch adds support for link status and link recovery. There
are specific DPCD’s defined for link status check and recovery in
case of any issues. PCON will communicate the same using an IRQ_HPD
to source. HDMI sink would have indicated the same to PCON using
SCDC interrupt
From: Swati Sharma
The HDMI2.1 extends HFVSBD (HDMI Forum Vendor Specific
Data block) to have fields related to newly defined methods of FRL
(Fixed Rate Link) levels, number of lanes supported, DSC Color bit
depth, VRR min/max, FVA (Fast Vactive), ALLM etc.
This patch adds the new HFVSDB fields
This patch calls functions to check FRL training requirements
for an HDMI2.1 sink, when connected through PCON.
The call is made before the DP link training. In case FRL is not
required or failure during FRL training, the TMDS mode is selected
for the pcon.
Signed-off-by: Ankit Nautiyal
---
driv
This patch adds functions to start FRL training for an HDMI2.1 sink,
connected via a PCON as a DP branch device.
This patch also adds a new structure for storing frl training related
data, when FRL training is completed.
Signed-off-by: Ankit Nautiyal
---
.../drm/i915/display/intel_display_types.
This patch series attempts to add support for a DP-HDMI2.1 Protocol
Convertor. The VESA spec for the HDMI2.1 PCON are proposed in Errata
E5 to DisplayPort_v2.0:
https://vesa.org/join-vesamemberships/member-downloads/?action=stamp&fileid=42299
The details are mentioned in DP to HDMI2.1 PCON Enum/Con
On Fri, Sep 25, 2020 at 03:05:52PM +0300, Tomi Valkeinen wrote:
> On 25/09/2020 15:00, Laurent Pinchart wrote:
> > On Fri, Sep 25, 2020 at 10:36:44AM +0300, Tomi Valkeinen wrote:
> >> On 24/09/2020 14:48, Laurent Pinchart wrote:
> >>> Hi Tomi,
> >>>
> >>> Thank you for the patch.
> >>>
> >>> On Wed
Hi Maxime
Sorry for the delay.
On Wed, 23 Sep 2020 at 09:40, Maxime Ripard wrote:
>
> The HVS FIFOs are currently assigned each time we have an atomic_check
> for all the enabled CRTCs.
>
> However, if we are running multiple outputs in parallel and we happen to
> disable the first (by index) CR
On Fri, 2020-09-25 at 12:22 +0200, Yannick Fertre wrote:
> Standardize on the dev_ based logging and drop the include of drm_print.h.
> Remove useless dsi_color_from_mipi function.
[]
> diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
[]
> - DRM_DEBU
On Fri, Sep 25, 2020 at 10:36:44AM +0300, Tomi Valkeinen wrote:
> On 24/09/2020 14:48, Laurent Pinchart wrote:
> > Hi Tomi,
> >
> > Thank you for the patch.
> >
> > On Wed, Sep 23, 2020 at 11:30:57AM +0300, Tomi Valkeinen wrote:
> >> On x64 we get:
> >>
> >> drivers/gpu/drm/bridge/cadence/cdns-mh
This patch updates dma_buf_vunmap() and dma-buf's vunmap callback to
use struct dma_buf_map. The interfaces used to receive a buffer address.
This address is now given in an instance of the structure.
Users of the functions are updated accordingly. This is only an interface
change. It is currently
This patch adds struct dma_buf_map and its helpers to the documentation. A
short tutorial is included.
v3:
* update documentation in a separate patch
* expand docs (Daniel)
* carry-over acks from patch 1
Signed-off-by: Thomas Zimmermann
Reviewed-by: Christian König
Revie
The new type struct dma_buf_map represents a mapping of dma-buf memory
into kernel space. It contains a flag, is_iomem, that signals users to
access the mapped memory with I/O operations instead of regular loads
and stores.
It was assumed that DMA buffer memory can be accessed with regular load
an
This patch updates dma_buf_vmap() and dma-buf's vmap callback to use
struct dma_buf_map.
The interfaces used to return a buffer address. This address now gets
stored in an instance of the structure that is given as an additional
argument. The functions return an errno code on errors.
Users of the
Dma-buf provides vmap() and vunmap() for retriving and releasing mappings
of dma-buf memory in kernel address space. The functions operate with plain
addresses and the assumption is that the memory can be accessed with load
and store operations. This is not the case on some architectures (e.g.,
spa
On Fri, 25 Sep 2020 at 12:38, Maxime Ripard wrote:
>
> Hi Dave,
>
> On Wed, Sep 23, 2020 at 03:59:04PM +0100, Dave Stevenson wrote:
> > Hi Maxime
> >
> > On Wed, 23 Sep 2020 at 09:40, Maxime Ripard wrote:
> > >
> > > The current CRTC state reset hook in vc4 allocates a vc4_crtc_state
> > > struct
On 25/09/2020 08:13, Leon Romanovsky wrote:
On Thu, Sep 24, 2020 at 09:21:20AM +0100, Tvrtko Ursulin wrote:
On 22/09/2020 09:39, Leon Romanovsky wrote:
From: Maor Gottlieb
Extend __sg_alloc_table_from_pages to support dynamic allocation of
SG table from pages. It should be used by drivers
On 24/09/2020 14:48, Laurent Pinchart wrote:
> Hi Tomi,
>
> Thank you for the patch.
>
> On Wed, Sep 23, 2020 at 11:30:57AM +0300, Tomi Valkeinen wrote:
>> On x64 we get:
>>
>> drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c:751:10: warning:
>> conversion from 'long unsigned int' to 'unsigne
Hi
Am 23.09.20 um 16:27 schrieb Christian König:
> Am 23.09.20 um 14:32 schrieb Thomas Zimmermann:
>> The new type struct dma_buf_map represents a mapping of dma-buf memory
>> into kernel space. It contains a flag, is_iomem, that signals users to
>> access the mapped memory with I/O operations ins
On Thu, Sep 24, 2020 at 10:54 PM Sam Ravnborg wrote:
>
> Hi Daniel/Arnd.
>
> On Fri, Sep 18, 2020 at 02:48:08PM +0200, Daniel Vetter wrote:
> > On Fri, Sep 18, 2020 at 12:08:10PM +0200, Arnd Bergmann wrote:
> > > The fbdev code uses compat_alloc_user_space in a few of its
> > > compat_ioctl handle
Standardize on the dev_ based logging and drop the include of drm_print.h.
Remove useless dsi_color_from_mipi function.
Signed-off-by: Yannick Fertre
---
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 87 ++-
1 file changed, 45 insertions(+), 42 deletions(-)
diff --git a/driver
On Do, 2020-09-03 at 21:40 +0100, Robin Murphy wrote:
> Since commit 9495b7e92f71 ("driver core: platform: Initialize dma_parms
> for platform devices"), struct platform_device already provides a
> dma_parms structure, so we can save allocating another one.
>
> Signed-off-by: Robin Murphy
Thanks
On Fr, 2020-08-14 at 11:05 +0200, Christian Gmeiner wrote:
> This little patch set adds support for the total bandwidth used by HI. The
> basic hi bandwidth read-out is quite simple but I needed to add some little
> clean-ups to make it nice looking.
>
> Christian Gmeiner (4):
> drm/etnaviv: ren
On Fr, 2020-08-14 at 11:05 +0200, Christian Gmeiner wrote:
> These two perf counters represent the total read and write
> GPU bandwidth in terms of 64bits.
>
> The used sequence was taken from Vivante kernel driver.
>
> Signed-off-by: Christian Gmeiner
> ---
> drivers/gpu/drm/etnaviv/etnaviv_pe
Am 25.09.20 um 10:18 schrieb Daniel Vetter:
On Fri, Sep 25, 2020 at 10:16 AM Daniel Vetter wrote:
On Fri, Sep 25, 2020 at 9:39 AM Christian König
wrote:
Am 25.09.20 um 01:14 schrieb Dave Airlie:
On Thu, 24 Sep 2020 at 22:42, Christian König wrote:
Am 24.09.20 um 07:18 schrieb Dave Airlie:
On Fri, 25 Sep 2020 10:46:51 +0200
Daniel Vetter wrote:
> Hopefully we'll have the drm crash recorder RSN, but meanwhile
> compositors would like to know a bit better why they get an EBUSY.
>
> v2: Move misplaced hunk to the right patch (Pekka)
Hi,
both patches
Acked-by: Pekka Paalanen
Tha
On Fri, Sep 25, 2020 at 04:51:38PM +0800, Tian Tao wrote:
> drm_modeset_lock.h already declares struct drm_device, so there's no
> need to declare it in vc4_drv.h
>
> Signed-off-by: Tian Tao
Just an aside, when submitting patches please use
scripts/get_maintainers.pl to generate the recipient li
On 24.09.20 23:50, Dan Williams wrote:
> On Thu, Sep 24, 2020 at 2:42 PM David Hildenbrand wrote:
>>
>>
>>
>>> Am 24.09.2020 um 23:26 schrieb Dan Williams :
>>>
>>> [..]
> I'm not suggesting to busy the whole "virtio" range, just the portion
> that's about to be passed to add_memory_drive
When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
pull in arbitrary other resources, including CRTCs (e.g. when
reconfiguring global resources).
But in nonblocking mode userspace has then no idea this happened,
which can lead to spurious EBUSY calls, both:
- when that other CR
Hopefully we'll have the drm crash recorder RSN, but meanwhile
compositors would like to know a bit better why they get an EBUSY.
v2: Move misplaced hunk to the right patch (Pekka)
Cc: Sean Paul
Cc: Daniel Stone
Cc: Pekka Paalanen
Cc: Simon Ser
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
On Fri, Sep 25, 2020 at 11:24:46AM +0300, Pekka Paalanen wrote:
> On Wed, 23 Sep 2020 17:18:52 +0200
> Daniel Vetter wrote:
>
> > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> > pull in arbitrary other resources, including CRTCs (e.g. when
> > reconfiguring global resou
Hi
Am 23.09.20 um 16:33 schrieb Christian König:
> Feel free to add an Acked-by: Christian König
> to all patches which I haven't explicitly reviewed.
Done, thanks.
>
> I would say we should just push this to drm-misc-next now.
It's merged now.
Best regards
Thomas
>
> Thanks for the nice c
On Thu, Sep 24, 2020 at 04:09:37PM +0200, Greg Kroah-Hartman wrote:
> On Thu, Sep 24, 2020 at 09:38:22AM -0400, Peilin Ye wrote:
> > Hi all,
> >
> > syzbot has reported [1] a global out-of-bounds read issue in
> > fbcon_get_font(). A malicious user may resize `vc_font.height` to a large
> > value
On Wed, 23 Sep 2020 12:57:37 +0200
Daniel Vetter wrote:
> Hopefully we'll have the drm crash recorder RSN, but meanwhile
> compositors would like to know a bit better why they get an EBUSY.
>
These debug messages will be especially useful with the flight
recorder, but also without. :-)
...
>
On Wed, 23 Sep 2020 17:18:52 +0200
Daniel Vetter wrote:
> When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> pull in arbitrary other resources, including CRTCs (e.g. when
> reconfiguring global resources).
>
> But in nonblocking mode userspace has then no idea this happened
On Thu, Sep 24, 2020 at 05:15:00PM +0100, Qais Yousef wrote:
> On 09/24/20 10:49, Daniel Vetter wrote:
>
> [...]
>
> > > > I also thought kernel threads can be distinguished from others, so
> > > > userspace shouldn't be able to sneak in and get elevated by accident.
> > >
> > > I guess maybe yo
On Fri, Sep 25, 2020 at 10:16 AM Daniel Vetter wrote:
>
> On Fri, Sep 25, 2020 at 9:39 AM Christian König
> wrote:
> >
> > Am 25.09.20 um 01:14 schrieb Dave Airlie:
> > > On Thu, 24 Sep 2020 at 22:42, Christian König
> > > wrote:
> > >> Am 24.09.20 um 07:18 schrieb Dave Airlie:
> > >>> From: Da
On Fri, Sep 25, 2020 at 9:39 AM Christian König
wrote:
>
> Am 25.09.20 um 01:14 schrieb Dave Airlie:
> > On Thu, 24 Sep 2020 at 22:42, Christian König
> > wrote:
> >> Am 24.09.20 um 07:18 schrieb Dave Airlie:
> >>> From: Dave Airlie
> >>>
> >>> All the accel moves do the same pattern here, prov
On Wed, 23 Sep 2020 14:57:24 +0300
Tomi Valkeinen wrote:
> omapdrm supports gamma via GAMMA_LUT property. However, the HW we have
> is:
>
> gamma -> ctm -> out
>
> instead of what the model DRM framework uses:
>
> ctm -> gamma -> out
>
> As the following patches add CTM support for omapdrm, l
On Wed, 23 Sep 2020 14:57:23 +0300
Tomi Valkeinen wrote:
> We currently have drm_atomic_helper_legacy_gamma_set() helper which can
> be used to handle legacy gamma-set ioctl.
> drm_atomic_helper_legacy_gamma_set() sets GAMMA_LUT, and clears
> CTM and DEGAMMA_LUT. This works fine on HW where we ha
Am 25.09.20 um 01:14 schrieb Dave Airlie:
On Thu, 24 Sep 2020 at 22:42, Christian König wrote:
Am 24.09.20 um 07:18 schrieb Dave Airlie:
From: Dave Airlie
All the accel moves do the same pattern here, provide a helper
And exactly that pattern I want to get away from.
Currently this is just
1 - 100 of 131 matches
Mail list logo
