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 u
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 w
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 poi
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 th
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
Documentation/devicetree/
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?
>
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 somewhat
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.
>
> Signed
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 unmap_mapping_range
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 th
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)
> - * p
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 with
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. A
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
Documentation/devicetree/
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 had
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:
https://lkml.org/lkml
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
> +++ b/Doc
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, inval
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 p
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 p
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
--- a/drivers/dma-
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 Dani
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: Revo
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 a/drivers/dma-
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 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 Vetter
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 pretty
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
> > VK_FORMAT_R10X6G10X6B10X6A1
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
>
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 with
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 ear
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.
>>
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)
> > - dro
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 hel
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 +++---
drivers
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 +--
dr
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 +
drivers/gpu/drm/n
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 +-
drivers/
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
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 block
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-randc
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
--- a/drivers
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 a/drivers/gpu/drm/drm_prime.
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 +---
drivers/gp
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
---
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 w
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 b
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 +--
drivers/
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: Dani
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 having
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 c
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 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: Chri
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
b/drivers/gpu/
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 poweri
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 a/drivers/gpu/drm/amd/amdgpu/amdgpu
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
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 fi
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 +-
>
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 appli
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
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 o
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 dyn
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 0xff
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, 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 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() an
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 th
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 ha
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 a/arch/arm64/boot/dts/qcom/sc7180.dts
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 a/drivers/
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 their
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 | 2
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 insertion
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
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 05c4196a8212..65d172
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 a/drivers/gpu/drm/radeon/radeon_
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.
https://ko
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 +---
drivers/gpu/drm/e
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]
https://www.kernel.org/doc/html/v5.7/process/deprecated.html?hig
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: kerne
drm_dbg(&kmb->drm,
+ "LAYER3:GL1 DMA OVERFLOW val = 0x%lx", val);
+ }
+
+ if (status & LCD_INT_LAYER) {
+ /* Clear layer interrupts */
+ kmb_write_lcd(kmb, LCD_INT_CLEAR, LCD_INT_LAYER)
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
Documentation/devicetree/bindings/di
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
Signed
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:
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:
git://people.freedeskto
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 ove
NACK for the entire lack of any form of commit description.
Am 08.10.20 um 20:16 schrieb sandy.8...@gmail.com:
> Signed-off-by: Sandeep Raghuraman
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mai
atches F:
> drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
>
> This patch cleanly applies on next-20201008 and resolves the issue above.
Generally after 2-3 weeks a patch is lost and unfortunately needs to be
resend. Please do that next time around instead of waiting.
Patch que
93 matches
Mail list logo
