Hi Linus,
Fixes trickling in this week, Alex had a final fix for the newest GPU
they introduced in rc1, along with one build regression and one
crasher fix.
Cross my fingers that's it for 5.9.
Dave.
drm-fixes-2020-10-09:
drm amdgpu fixes for 5.9 final
amdgpu:
- Fix a crash on renoir if you
Hi Dave, Daniel,
Some important last minute fixes for 5.9.
The following changes since commit d10285a25e29f13353bbf7760be8980048c1ef2f:
drm/nouveau/mem: guard against NULL pointer access in mem_del (2020-10-07
15:33:09 +1000)
are available in the Git repository at:
This is a new DRM driver for Intel's KeemBay SOC.
The SoC couples an ARM Cortex A53 CPU with an Intel
Movidius VPU.
This driver is tested with the KMB EVM board which is the refernce baord
for Keem Bay SOC. The SOC's display pipeline is as follows
+--++-+
Register definitions for Keem Bay display driver
v2: removed license text (Sam)
v3: Squashed all 59 commits to one
v4: review changes from Sam Ravnborg
renamed dev_p to kmb
v5: corrected spellings
v6: corrected checkpatch warnings
v7: removed redundant definitions
Cc: Sam Ravnborg
v2: Added Maintainer entry
v3: Added one more Maintainer entry
Cc: Sam Ravnborg
Signed-off-by: Anitha Chrisanthus
Reviewed-by: Bob Paauwe
---
MAINTAINERS | 7 +++
drivers/gpu/drm/Kconfig | 2 ++
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/kmb/Kconfig | 13
Initializes Mipi DSI and sets up connects to ADV bridge
v2: removed license text
upclassed dev_private, removed HAVE_IRQ. (Sam)
v3: Squashed all 59 commits to one
v4: review changes from Sam Ravnborg
renamed dev_p to kmb
v5: corrected spellings
v6: corrected checkpatch warnings
v7:
if (status & LCD_INT_LAYER) {
+ /* Clear layer interrupts */
+ kmb_write_lcd(kmb, LCD_INT_CLEAR, LCD_INT_LAYER);
+ }
+
+ /* Clear all interrupts */
+ kmb_set_bitmask_lcd(kmb, LCD_INT_CLEAR, 1);
+ return IRQ_HANDLED;
+}
+
+/* IRQ ha
This patch adds bindings for Intel KeemBay Display
v2: review changes from Rob Herring
Signed-off-by: Anitha Chrisanthus
---
.../bindings/display/intel,keembay-display.yaml| 99 ++
1 file changed, 99 insertions(+)
create mode 100644
FYI, I applied this patch to amd-staging-drm-next. Sorry for the delay,
I finally caught up with my vacation backlog.
Regards,
Felix
Am 2020-09-22 um 10:28 p.m. schrieb kernel test robot:
> Fixes: 0b54e1e30e9f ("drm/amdgpu: Fix handling of KFD initialization
> failures")
> Signed-off-by:
In order to enable -Wimplicit-fallthrough for Clang[1], replace the
existing /* fall through */ comments with the new pseudo-keyword
macro fallthrough[2].
[1] https://git.kernel.org/linus/e2079e93f562c7f7a030eb7642017ee5eabaaa10
[2]
On 10/8/20 4:23 AM, Christian König wrote:
Add the new vma_set_file() function to allow changing
vma->vm_file with the necessary refcount dance.
v2: add more users of this.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 16 +---
The pull request you sent on Thu, 8 Oct 2020 13:35:59 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-10-08
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/3d006ee42dde0b08b7b47697def6f50fd849c996
Thank you!
--
Deet-doot-dot, I am a bot.
From: Sandeep Raghuraman
Signed-off-by: Sandeep Raghuraman
---
drivers/gpu/drm/radeon/radeon_asic.c | 1 +
drivers/gpu/drm/radeon/radeon_asic.h | 1 +
drivers/gpu/drm/radeon/sumo_dpm.c| 20
3 files changed, 22 insertions(+)
diff --git
From: Sandeep Raghuraman
Signed-off-by: Sandeep Raghuraman
---
drivers/gpu/drm/radeon/radeon_pm.c | 29 -
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index
From: Sandeep Raghuraman
Signed-off-by: Sandeep Raghuraman
---
drivers/gpu/drm/radeon/radeon.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index cc4f58d16589..85a1cafdf303 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++
Signed-off-by: Sandeep Raghuraman
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Applied. Thanks!
Alex
On Thu, Oct 8, 2020 at 10:17 AM Gustavo A. R. Silva
wrote:
>
> Make use of the new struct_size() helper instead of the offsetof() idiom.
>
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 3 +--
> 1 file changed, 1
Applied. Thanks!
Alex
On Thu, Oct 8, 2020 at 10:29 AM Gustavo A. R. Silva
wrote:
>
> Make use of the new struct_size() helper instead of the offsetof() idiom.
> Also, use kmalloc() instead of kcalloc().
>
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c |
On Thu, Oct 8, 2020 at 6:44 PM Gerald Schaefer
wrote:
>
> On Wed, 7 Oct 2020 18:44:21 +0200
> Daniel Vetter wrote:
>
> > Way back it was a reasonable assumptions that iomem mappings never
> > change the pfn range they point at. But this has changed:
> >
> > - gpu drivers dynamically manage
Register GPU as a devfreq cooling device so that it can be passively
cooled by the thermal framework.
Signed-off-by: Akhil P Oommen
---
drivers/gpu/drm/msm/msm_gpu.c | 13 -
drivers/gpu/drm/msm/msm_gpu.h | 2 ++
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git
Add cooling-cells property and the cooling maps for the gpu tzones
to support GPU cooling.
Signed-off-by: Akhil P Oommen
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 29 ++---
1 file changed, 22 insertions(+), 7 deletions(-)
diff --git
oh hold on, I misspoke. Here's the patch I was thinking of:
https://patchwork.freedesktop.org/series/82041/
On Thu, 2020-10-08 at 10:32 +0800, Kai-Heng Feng wrote:
> Hi Lyude,
>
> > On Oct 8, 2020, at 05:53, Lyude Paul wrote:
> >
> > Hi! I thought this patch rang a bell, we actually already
Acked-by: Lyude Paul
On Thu, 2020-10-08 at 19:46 +0300, Imre Deak wrote:
> Hi Dave et all,
>
> On Wed, Oct 07, 2020 at 08:09:15PM +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
Hi Dave et all,
On Wed, Oct 07, 2020 at 08:09:15PM +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()
On Thu, 2020-10-08 at 10:32 +0800, Kai-Heng Feng wrote:
> Hi Lyude,
>
> > On Oct 8, 2020, at 05:53, Lyude Paul wrote:
> >
> > Hi! I thought this patch rang a bell, we actually already had some
> > discussion
> > about this since there's a couple of other systems this was causing issues
> > for.
Hi "Christian,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on staging/staging-testing linux/master linus/master
v5.9-rc8 next-20201008]
[cannot apply to mmotm/master]
[If your patch is applied to the wrong git
On Thu, Oct 08, 2020 at 03:33:50PM +0100, Matteo Franchin wrote:
> Add ABGR format with 10-bit components packed in 64-bit per pixel.
> This format can be used to handle
> VK_FORMAT_R10X6G10X6B10X6A10X6_UNORM_4PACK16 on little-endian
> architectures.
>
> Signed-off-by: Matteo Franchin
Ok so
On Thu, Oct 8, 2020 at 3:20 AM Christian König wrote:
>
> Am 07.10.20 um 18:01 schrieb Gustavo A. R. Silva:
> > Hi all,
> >
> > This series aims to replace one-element arrays with flexible-array
> > members.
> >
> > There is a regular need in the kernel to provide a way to declare having
> > a
On Wed, Oct 7, 2020 at 12:05 PM Gustavo A. R. Silva
wrote:
>
> There is a regular need in the kernel to provide a way to declare having
> a dynamically sized set of trailing elements in a structure. Kernel code
> should always use “flexible array members”[1] for these cases. The older
> style of
Both vmwgxf patches look good to me too.
Reviewed-by: Roland Scheidegger
Am 06.10.20 um 02:06 schrieb Dave Airlie:
> From: Dave Airlie
>
> This just copies the fallback to vmwgfx, I'm going to iterate on this
> a bit until it's not the same as the fallback path.
>
> Signed-off-by: Dave Airlie
Hi "Christian,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on hnaz-linux-mm/master staging/staging-testing
linux/master linus/master v5.9-rc8 next-20201008]
[cannot apply to mmotm/master]
[If your patch is ap
On Thu, Oct 8, 2020 at 10:29 AM Daniel Vetter wrote:
>
> It's the only ioctl handler purely for legacy drivers that didn't have
> this yet.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/drm_internal.h | 8
> drivers/gpu/drm/drm_ioctl.c| 2 +-
Add ABGR format with 10-bit components packed in 64-bit per pixel.
This format can be used to handle
VK_FORMAT_R10X6G10X6B10X6A10X6_UNORM_4PACK16 on little-endian
architectures.
Signed-off-by: Matteo Franchin
---
drivers/gpu/drm/drm_fourcc.c | 1 +
include/uapi/drm/drm_fourcc.h | 6 ++
2
It's the only ioctl handler purely for legacy drivers that didn't have
this yet.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_internal.h | 8
drivers/gpu/drm/drm_ioctl.c| 2 +-
drivers/gpu/drm/drm_pci.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff
Make use of the new struct_size() helper instead of the offsetof() idiom.
Also, use kmalloc() instead of kcalloc().
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Amlogic SoC devices report the following errors frequently causing excessive
dmesg log spam and early log rotataion, although the errors appear to be
harmless as everything works fine:
[7.202702] panfrost ffe4.gpu: error powering up gpu L2
[7.203760] panfrost ffe4.gpu: error
Make use of the new struct_size() helper instead of the offsetof() idiom.
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
On Thu, Oct 08, 2020 at 04:09:14PM +0200, Daniel Vetter wrote:
> On Thu, Oct 08, 2020 at 01:23:40PM +0200, Christian König wrote:
> > We have reoccurring requests on this so better document that
> > this approach doesn't work and dma_buf_mmap() needs to be used instead.
> >
> > Signed-off-by:
On Thu, Oct 08, 2020 at 01:23:39PM +0200, Christian König wrote:
> Add the new vma_set_file() function to allow changing
> vma->vm_file with the necessary refcount dance.
>
> v2: add more users of this.
>
> Signed-off-by: Christian König
> ---
> drivers/dma-buf/dma-buf.c | 16
On Thu, Oct 08, 2020 at 01:23:40PM +0200, Christian König wrote:
> We have reoccurring requests on this so better document that
> this approach doesn't work and dma_buf_mmap() needs to be used instead.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/drm_prime.c | 7 ++-
> 1 file
On Thu, Oct 08, 2020 at 09:19:47AM +0200, Christian König wrote:
> Am 07.10.20 um 18:01 schrieb Gustavo A. R. Silva:
> > Hi all,
> >
> > This series aims to replace one-element arrays with flexible-array
> > members.
> >
> > There is a regular need in the kernel to provide a way to declare
On Thu, Oct 08, 2020 at 10:40:10AM +0200, Christian König wrote:
> Am 08.10.20 um 10:17 schrieb Daniel Vetter:
> > On Thu, Oct 8, 2020 at 10:10 AM Christian König
> > wrote:
> > > Instead of manually calculating the structure size.
> > >
> > > Signed-off-by: Christian König
> > Reviewed-by:
Am 08.10.20 um 13:39 schrieb Matthew Wilcox:
On Thu, Oct 08, 2020 at 01:23:39PM +0200, Christian König wrote:
drivers/dma-buf/dma-buf.c | 16 +---
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 4 +---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 3 +--
On Sat, Oct 03, 2020 at 04:02:57AM +, John Stultz wrote:
> This adds a heap that allocates non-contiguous buffers that are
> marked as writecombined, so they are not cached by the CPU.
>
> This is useful, as most graphics buffers are usually not touched
> by the CPU or only written into once
Hi John,
On Sat, Oct 03, 2020 at 04:02:50AM +, John Stultz wrote:
> Hey All,
...
>
> I did add to this series a reworked version of my uncached
> system heap implementation I was submitting a few weeks back.
> Since it duplicated a lot of the now reworked system heap code,
> I realized it
This is deprecated.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 399961035ae6..ac463e706b19 100644
---
Add the new vma_set_file() function to allow changing
vma->vm_file with the necessary refcount dance.
v2: add more users of this.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 16 +---
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 4 +---
This is deprecated.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_ttm.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 63e38b05a5bc..4b92cdbcd29b 100644
---
We have reoccurring requests on this so better document that
this approach doesn't work and dma_buf_mmap() needs to be used instead.
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_prime.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git
patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Mikko-Perttunen/Host1x-TegraDRM-UAPI/20201008-034403
base: git://anongit.freedesktop.org/tegra/linux.git drm/tegra/for-next
config: arm64-randconfig-r021
On 02/10/2020 13:25, Boris Brezillon wrote:
If more than two jobs end up timeout-ing concurrently, only one of them
(the one attached to the scheduler acquiring the lock) is fully handled.
The other one remains in a dangling state where it's no longer part of
the scheduling queue, but still
On Thu, Oct 8, 2020 at 11:25 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 02.10.20 um 20:44 schrieb Daniel Vetter:
> > On Fri, Oct 2, 2020 at 8:05 PM Daniel Vetter wrote:
> >>
> >> On Tue, Sep 29, 2020 at 05:14:36PM +0200, Thomas Zimmermann wrote:
> >>> At least sparc64 requires I/O-specific access
Instead of the placement flags use the caching of the bus
mapping or tt object for the page protection flags.
Signed-off-by: Christian König
Reviewed-by: Michael J. Ruhl
---
drivers/gpu/drm/ttm/ttm_bo_util.c| 23 ++-
drivers/gpu/drm/ttm/ttm_bo_vm.c | 2 +-
All drivers can determine the tt caching state at creation time,
no need to do this on the fly during every validation.
Signed-off-by: Christian König
Reviewed-by: Michael J. Ruhl
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 11 +--
And implement setting it up correctly in the drivers.
This allows getting rid of the placement flags for this.
Signed-off-by: Christian König
Reviewed-by: Michael J. Ruhl
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 1 +
drivers/gpu/drm/drm_gem_vram_helper.c | 1 +
Changing the caching on the fly never really worked
flawlessly.
So stop this completely and just let drivers specific the
desired caching in the tt or bus object.
Signed-off-by: Christian König
Reviewed-by: Michael J. Ruhl
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 20 +++---
On Tue, Sep 29, 2020 at 04:48:39PM +0100, Daniel Stone wrote:
> Hi,
>
> On Fri, 25 Sep 2020 at 09:46, 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.
>
> Thanks a lot, this is super
On Thu, Oct 8, 2020 at 11:22 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 07.10.20 um 15:30 schrieb Daniel Vetter:
> > We didn't take the kernel_fb_helper_lock mutex, which protects that
> > code. While at it, simplify the code
> > - inline the function (originally shared with kgdb I think)
> > -
Hi
Am 02.10.20 um 20:44 schrieb Daniel Vetter:
> On Fri, Oct 2, 2020 at 8:05 PM Daniel Vetter wrote:
>>
>> On Tue, Sep 29, 2020 at 05:14:36PM +0200, Thomas Zimmermann wrote:
>>> At least sparc64 requires I/O-specific access to framebuffers. This
>>> patch updates the fbdev console accordingly.
Hi
Am 07.10.20 um 15:30 schrieb Daniel Vetter:
> We didn't take the kernel_fb_helper_lock mutex, which protects that
> code. While at it, simplify the code
> - inline the function (originally shared with kgdb I think)
> - drop the error tracking and all the complications
> - drop the pointless
On Wed, Oct 07, 2020 at 05:30:10PM +0100, Qais Yousef wrote:
> On 10/07/20 08:57, Rob Clark wrote:
> > Yeah, I think we will end up making some use of uclamp.. there is
> > someone else working on that angle
> >
> > But without it, this is a case that exposes legit prioritization
> > problems
Hi
Am 07.10.20 um 16:30 schrieb Daniel Vetter:
> On Wed, Oct 7, 2020 at 3:25 PM Christian König
> wrote:
>>
>> Am 07.10.20 um 15:20 schrieb Thomas Zimmermann:
>>> Hi
>>>
>>> Am 07.10.20 um 15:10 schrieb Daniel Vetter:
On Wed, Oct 7, 2020 at 2:57 PM Thomas Zimmermann
wrote:
> Hi
Hi Joe,
Thanks for looking at this.
On Wed, Oct 07, 2020 at 11:47:57PM +0100, Joe Perches wrote:
> On Wed, 2020-10-07 at 10:27 +0100, Matteo Franchin wrote:
> > Add ABGR format with 10-bit components packed in 64-bit per pixel.
> > This format can be used to handle
> >
Am 08.10.20 um 10:17 schrieb Daniel Vetter:
On Thu, Oct 8, 2020 at 10:10 AM Christian König
wrote:
Instead of manually calculating the structure size.
Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
Thanks, could anybody (not me) come up with a cocci script for this?
I'm
On Thu, Oct 8, 2020 at 1:13 AM Daniel Vetter wrote:
>
> On Thu, Oct 8, 2020 at 9:50 AM Dan Williams wrote:
> >
> > On Wed, Oct 7, 2020 at 4:25 PM Jason Gunthorpe wrote:
> > >
> > > On Wed, Oct 07, 2020 at 12:33:06PM -0700, Dan Williams wrote:
> > > > On Wed, Oct 7, 2020 at 11:11 AM Daniel
On Wed, Oct 07, 2020 at 09:44:09AM -0700, Rob Clark wrote:
> On Mon, Oct 5, 2020 at 5:15 AM Ville Syrjälä
> wrote:
> >
> > On Fri, Oct 02, 2020 at 10:55:52AM -0700, Rob Clark wrote:
> > > On Fri, Oct 2, 2020 at 4:05 AM Ville Syrjälä
> > > wrote:
> > > >
> > > > On Fri, Oct 02, 2020 at 01:52:56PM
On Thu, Oct 8, 2020 at 10:10 AM Christian König
wrote:
>
> Instead of manually calculating the structure size.
>
> Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
> ---
> drivers/dma-buf/dma-resv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On Thu, Oct 8, 2020 at 9:50 AM Dan Williams wrote:
>
> On Wed, Oct 7, 2020 at 4:25 PM Jason Gunthorpe wrote:
> >
> > On Wed, Oct 07, 2020 at 12:33:06PM -0700, Dan Williams wrote:
> > > On Wed, Oct 7, 2020 at 11:11 AM Daniel Vetter
> > > wrote:
> > > >
> > > > Since 3234ac664a87 ("/dev/mem:
Instead of manually calculating the structure size.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index 1c8f2581cb09..bb5a42b10c29 100644
---
On Thu, Oct 8, 2020 at 12:29 AM Dan Williams wrote:
>
> On Wed, Oct 7, 2020 at 3:23 PM Dan Williams wrote:
> >
> > On Wed, Oct 7, 2020 at 12:49 PM Daniel Vetter
> > wrote:
> > >
> > > On Wed, Oct 7, 2020 at 9:33 PM Dan Williams
> > > wrote:
> > > >
> > > > On Wed, Oct 7, 2020 at 11:11 AM
On Wed, Oct 7, 2020 at 4:25 PM Jason Gunthorpe wrote:
>
> On Wed, Oct 07, 2020 at 12:33:06PM -0700, Dan Williams wrote:
> > On Wed, Oct 7, 2020 at 11:11 AM Daniel Vetter
> > wrote:
> > >
> > > Since 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims
> > > the region") /dev/kmem zaps
On Thu, Oct 8, 2020 at 1:24 AM Jason Gunthorpe wrote:
>
> On Wed, Oct 07, 2020 at 12:33:06PM -0700, Dan Williams wrote:
> > On Wed, Oct 7, 2020 at 11:11 AM Daniel Vetter
> > wrote:
> > >
> > > Since 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims
> > > the region") /dev/kmem zaps
On Thu, Oct 8, 2020 at 2:44 AM John Hubbard wrote:
>
> On 10/7/20 9:44 AM, Daniel Vetter wrote:
> > Way back it was a reasonable assumptions that iomem mappings never
> > change the pfn range they point at. But this has changed:
> >
> > - gpu drivers dynamically manage their memory nowadays,
On Wed, Oct 07, 2020 at 08:14:06PM +0200, Daniel Vetter wrote:
> Hm, but wouldn't need that the semi-nasty vma_open trick to make sure
> that vma doesn't untimely disappear? Or is the idea to look up the
> underlying vfio object, and refcount that directly?
Ah, the patches Alex was working on
Hi Tomeu,
On Wed, 7 Oct 2020 at 10:58, Tomeu Vizoso wrote:
>
> Hi Clément,
>
> Have just noticed that my Pine H64 board hangs when I try to set the
> performance governor for the GPU devfreq.
>
> Is this a known bug?
Yes it is.
I try to summarize everything in this message:
Hi,
On 05/10/2020 13:38:27-0500, Rob Herring wrote:
> diff --git a/Documentation/devicetree/bindings/rtc/ingenic,rtc.yaml
> b/Documentation/devicetree/bindings/rtc/ingenic,rtc.yaml
> index bc2c7e53a28e..60e93e86ad9d 100644
> --- a/Documentation/devicetree/bindings/rtc/ingenic,rtc.yaml
> +++
On Wed, Oct 07, 2020 at 12:33:06PM -0700, Dan Williams wrote:
> On Wed, Oct 7, 2020 at 11:11 AM Daniel Vetter wrote:
> >
> > Since 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims
> > the region") /dev/kmem zaps ptes when the kernel requests exclusive
> > acccess to an iomem region.
Document the OnePlus 6/T common panel driver, example from
arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
Signed-off-by: Caleb Connolly
---
.../display/panel/panel-oneplus6.yaml | 73 +++
1 file changed, 73 insertions(+)
create mode 100644
On Wed, Oct 07, 2020 at 06:44:20PM +0200, Daniel Vetter wrote:
> Way back it was a reasonable assumptions that iomem mappings never
> change the pfn range they point at. But this has changed:
>
> - gpu drivers dynamically manage their memory nowadays, invalidating
> ptes with
This commit adds support for the display panels used in the OnePlus 6 /
T devices.
The OnePlus 6/T devices use different panels however they are
functionally identical with much of the commands being shared. The
panels don't appear to be used by any other devices some combine them as
one driver
On Wed, Oct 07, 2020 at 07:12:24PM +0200, Daniel Vetter wrote:
> On Wed, Oct 7, 2020 at 6:53 PM Jason Gunthorpe wrote:
> >
> > On Wed, Oct 07, 2020 at 06:44:18PM +0200, Daniel Vetter wrote:
> > >
> > > - /*
> > > - * While get_vaddr_frames() could be used for transient (kernel
> > > -
On Wed, Oct 07, 2020 at 06:44:26PM +0200, Daniel Vetter wrote:
> The code seems to stuff these pfns into iommu pts (or something like
> that, I didn't follow), but there's no mmu_notifier to ensure that
> access is synchronized with pte updates.
>
> Hence mark these as unsafe. This means that
On Wed, Oct 07, 2020 at 08:01:42PM +0200, Daniel Vetter wrote:
> I think it'd fix the bug, until someone wires ->access up for
> drivers/gpu, or the next subsystem. This is also just for ptrace, so
> we really don't care when we stall the vm badly and other silly
> things. So I figured the
On 05/10/2020 13:38:30-0500, Rob Herring wrote:
> In order to add meta-schema checks for additional/unevaluatedProperties
> being present, all schema need to make this explicit. As common/shared
> schema are included by other schemas, they should always allow for
> additionalProperties.
>
>
On Wed, Oct 07, 2020 at 06:44:18PM +0200, Daniel Vetter wrote:
>
> - /*
> - * While get_vaddr_frames() could be used for transient (kernel
> - * controlled lifetime) pinning of memory pages all current
> - * users establish long term (userspace controlled lifetime)
> - *
Hi Lyude,
> On Oct 8, 2020, at 05:53, Lyude Paul wrote:
>
> Hi! I thought this patch rang a bell, we actually already had some discussion
> about this since there's a couple of other systems this was causing issues
> for.
> Unfortunately it never seems like that patch got sent out. Satadru?
>
This commit adds support for the display panels used in the OnePlus 6 /
T devices.
The OnePlus 6/T devices use different panels however they are
functionally identical with much of the commands being shared. The
panels don't appear to be used by any other devices some combine them as
one driver
Document the OnePlus 6/T common panel driver, example from
arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
Signed-off-by: Caleb Connolly
---
.../display/panel/panel-oneplus6.yaml | 73 +++
1 file changed, 73 insertions(+)
create mode 100644
On Wed, Oct 07, 2020 at 06:44:24PM +0200, Daniel Vetter wrote:
> Way back it was a reasonable assumptions that iomem mappings never
> change the pfn range they point at. But this has changed:
>
> - gpu drivers dynamically manage their memory nowadays, invalidating
> ptes with unmap_mapping_range
On Wed, Oct 07, 2020 at 08:10:34PM +0200, Daniel Vetter wrote:
> On Wed, Oct 7, 2020 at 7:36 PM Jason Gunthorpe wrote:
> >
> > On Wed, Oct 07, 2020 at 06:44:24PM +0200, Daniel Vetter wrote:
> > > Way back it was a reasonable assumptions that iomem mappings never
> > > change the pfn range they
Am 07.10.20 um 18:01 schrieb Gustavo A. R. Silva:
Hi all,
This series aims to replace one-element arrays with flexible-array
members.
There is a regular need in the kernel to provide a way to declare having
a dynamically sized set of trailing elements in a structure. Kernel code
should always
91 matches
Mail list logo
