On Thu, Oct 08, 2020 at 06:04:01PM -0700, Anitha Chrisanthus wrote:
> This is a basic KMS atomic modesetting display driver for KeemBay family of
> SOCs. Driver has no 2D or 3D graphics.It calls into the ADV bridge
> driver at the connector level.
>
> Single CRTC with LCD controller->mipi DSI-> AD
Am 08.10.20 um 16:23 schrieb Gustavo A. R. Silva:
Make use of the new struct_size() helper instead of the offsetof() idiom.
Signed-off-by: Gustavo A. R. Silva
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 3 +--
1 file changed, 1 insertion(+), 2 del
Am 08.10.20 um 16:34 schrieb Gustavo A. R. Silva:
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 delet
Hi
Am 09.10.20 um 08:47 schrieb Thomas Zimmermann:
> NACK for the entire lack of any form of commit description.
Please see the documentation at [1] on how to describe the changes and
getting your patches merged.
Best regards
Thomas
[1]
https://dri.freedesktop.org/docs/drm/process/submitting-pa
Am 08.10.20 um 16:12 schrieb Daniel Vetter:
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/d
If the CRTC driver ever needs to access the full DRM state, it can't do so
at atomic_enable / atomic_disable time since drm_atomic_helper_swap_state
will have cleared the pointer from the struct drm_crtc_state to the struct
drm_atomic_state before calling those hooks.
In order to allow that, let's
On Tue, Oct 06, 2020 at 08:23:06AM +0100, Christoph Hellwig wrote:
> If people want to use the "raw" IOMMU API with not cache coherent
> devices we'll need a cache maintainance API that goes along with it.
> It could either be formally part of the IOMMU API or be separate.
The IOMMU-API does not c
If a CRTC is enabled but not active, and that we're then doing a page flip
on another CRTC, drm_atomic_get_crtc_state will bring the first CRTC state
into the global state, and will make us wait for its vblank as well, even
though that might never occur.
Fix this by considering all the enabled CRT
On Thu, Oct 08, 2020 at 12:49:54AM -0700, Dan Williams wrote:
> > This is what got me thinking maybe this needs to be a bit bigger
> > generic infrastructure - eg enter this scheme from fops mmap and
> > everything else is in mm/user_iomem.c
>
> It still requires every file that can map physical
Hi Dave, sorry for the late reply.
On Tue, 2020-10-06 at 18:14 +0100, Dave Stevenson wrote:
> Hi Maxime
>
> On Tue, 6 Oct 2020 at 16:26, Maxime Ripard wrote:
> > Hi Dave,
> >
> > On Fri, Oct 02, 2020 at 04:57:05PM +0100, Dave Stevenson wrote:
> > > Hi Maxime
> > >
> > > On Fri, 2 Oct 2020 at 1
Hi,
Here's some patches to enable the HDR output in the RPi4 HDMI controller.
This needed a quite intrusive rework in the first patch to allow a CRTC to
have access to the whole DRM state at atomic_enable / atomic_disable time.
Let me know what you think,
Maxime
Changes from v1:
- Added the c
The current HVS muxing code will consider the CRTCs in a given state to
setup their muxing in the HVS, and disable the other CRTCs muxes.
However, it's valid to only update a single CRTC with a state, and in this
situation we would mux out a CRTC that was enabled but left untouched by
the new stat
The pixel rate is for now quite simple to compute, but with more features
(30 and 36 bits output, YUV output, etc.) will depend on a bunch of
connectors properties.
Let's store the rate we have to run the pixel clock at in our custom
connector state, and compute it in atomic_check.
Signed-off-by:
On Wed, Sep 16, 2020 at 06:57:05PM +0200, Maxime Ripard wrote:
> On Mon, Sep 14, 2020 at 07:14:11PM +0900, Hoegeun Kwon wrote:
> > Hi Maxime,
> >
> > On 9/8/20 9:00 PM, Maxime Ripard wrote:
> > > Hi Hoegeun,
> > >
> > > On Mon, Sep 07, 2020 at 08:49:12PM +0900, Hoegeun Kwon wrote:
> > >> On 9/3/20
When run with a higher bpc than 8, the clock of the HDMI controller needs
to be adjusted. Let's create a connector state that will be used at
atomic_check and atomic_enable to compute and store the clock rate
associated to the state.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.
The BCM2711 supports higher bpc count than just 8, so let's support it in
our driver.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 68 +-
drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +-
drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 9 -
3 files cha
We've had a number of muxing corner-cases with specific ways to reproduce
them, so let's document them to make sure they aren't lost and introduce
regressions later on.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_kms.c | 22 ++
1 file changed, 22 insertions(+)
d
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/gpu/drm/i915/gem/i915_gem_mman.c | 4 ++--
The code that assigns HVS channels during atomic_check is starting to grow
a bit big, let's move it into a separate function.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_kms.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vc4
On Wed, 1 Jul 2020, Ondrej Jirman wrote:
> The driver was renamed, change the path in the MAINTAINERS file.
>
> Signed-off-by: Ondrej Jirman
This minor non-urgent cleanup patch has not been picked up yet by anyone.
Hence, ./scripts/get_maintainers.pl --self-test=patterns continues to
compla
Since the CRTC setup in vc4 is split between the PixelValves/TXP and the
HVS, only the PV/TXP atomic hooks were updated in the previous commits, but
it makes sense to update the HVS ones too.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 4 +---
drivers/gpu/drm/vc4/vc4_drv.h
We'll need to access the connector state in our encoder setup, so let's
just pass the whole DRM state to our private encoder hooks.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 18 ++
drivers/gpu/drm/vc4/vc4_drv.h | 10 +-
drivers/gpu/drm/vc4/vc4_hdm
I found some typos related to "arbitrary".
s/abitrary/arbitrary/
s/arbitary/arbitrary/
This series fixes them.
These typos have been reported in the past in other codes, but
correction 'abitrary||arbitrary' wasn't added to scripts/spelling.txt.
Therefore, PATCH #6 adds it to spelling.txt.
Naok
Kevin Chowski said he would be geting to working on upstreaming a version
of that which was in the ChromeOS tree here:
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2344844
when I last spoke to hi
(This was two weeks ago.)
Kevin - do you have any input on this?
Sata
Fix comment typo.
s/arbitary/arbitrary/
Signed-off-by: Naoki Hayama
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index c6404b8d067f..5077004f7fbf 100644
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 memory nowadays, invalidating
> ptes with unmap_mapping_range when b
This is a note to let you know that I've just added the patch titled
drm/nouveau/device: return error for unknown chipsets
to the 5.8-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
d
Am 08.10.20 um 23:49 schrieb John Hubbard:
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
This is a note to let you know that I've just added the patch titled
drm/nouveau/mem: guard against NULL pointer access in mem_del
to the 5.8-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is
On 10/9/20 12:33 AM, Christian König wrote:
Am 08.10.20 um 23:49 schrieb John Hubbard:
On 10/8/20 4:23 AM, Christian König wrote:
...
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 3d69e51f3e4d..c9d5f1a38af3 100644
--- a/drivers/gpu/drm/
Am 08.10.20 um 16:14 schrieb Daniel Vetter:
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
This is a note to let you know that I've just added the patch titled
drm/nouveau/mem: guard against NULL pointer access in mem_del
to the 4.19-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch i
This is a note to let you know that I've just added the patch titled
drm/nouveau/mem: guard against NULL pointer access in mem_del
to the 5.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is
On 10/9/20 12:44 PM, Thomas Zimmermann wrote:
> Hi
>
> Am 09.10.20 um 08:47 schrieb Thomas Zimmermann:
>> NACK for the entire lack of any form of commit description.
>
> Please see the documentation at [1] on how to describe the changes and
> getting your patches merged.
Yes, I tried to use g
On Fri, Oct 09, 2020 at 09:16:49AM +0200, Christian König wrote:
> Am 08.10.20 um 16:12 schrieb Daniel Vetter:
> > 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.
> > >
On Fri, Oct 09, 2020 at 09:36:41AM +0200, Christian König wrote:
> Am 08.10.20 um 16:14 schrieb Daniel Vetter:
> > 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 be
This patch adds a callback for reporting vddc, to the dpm field of the
radeon_asic structure.
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 cc4f58
Add implementation of get_current_vddc() callback for Sumo.
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 --gi
On Mon, 24 Feb 2020 at 00:06, Andrew Jeffery wrote:
>
>
>
> On Sun, 23 Feb 2020, at 10:21, Ondrej Jirman wrote:
> > Arguments to GENMASK should be msb >= lsb.
> >
> > Signed-off-by: Ondrej Jirman
> > ---
> > I just grepped the whole kernel tree for GENMASK argument order issues,
> > and this is o
Create hwmon attribute for vddc, that uses previously declared
get_current_vddc() callback if there's an implementation available.
Also hides vddc, if there is no implementation for the current chipset (as per
Alexander Deucher's suggestion).
Signed-off-by: Sandeep Raghuraman
---
drivers/gpu/
Hi
Am 09.10.20 um 09:38 schrieb Sandeep Raghuraman:
>
>
> On 10/9/20 12:44 PM, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 09.10.20 um 08:47 schrieb Thomas Zimmermann:
>>> NACK for the entire lack of any form of commit description.
>>
>> Please see the documentation at [1] on how to describe the cha
On Fri, 22 May 2020 at 13:52, Thomas Zimmermann wrote:
>
> DRM_GEM_CMA_DRIVER_OPS sets the functions in struct drm_driver
> to their defaults. No functional changes are made.
>
> Signed-off-by: Thomas Zimmermann
I just found this in my inbox. I assume it has not been applied as you
were after a
All we need are a pages array, pin_user_pages_fast can give us that
directly. Plus this avoids the entire raw pfn side of get_vaddr_frames.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.
Hi all,
Round two of my patch series to clamp down a bunch of races and gaps
around follow_pfn and other access to iomem mmaps. Previous version:
v1:
https://lore.kernel.org/dri-devel/20201007164426.1812530-1-daniel.vet...@ffwll.ch/
And the discussion that sparked this journey:
https://lore.ke
The exynos g2d interface is very unusual, but it looks like the
userptr objects are persistent. Hence they need FOLL_LONGTERM.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc: And
This is used by media/videbuf2 for persistent dma mappings, not just
for a single dma operation and then freed again, so needs
FOLL_LONGTERM.
Unfortunately current pup_locked doesn't support FOLL_LONGTERM due to
locking issues. Rework the code to pull the pup path out from the
mmap_sem critical se
These are persistent, not just for the duration of a dma operation.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.
All we need are a pages array, pin_user_pages_fast can give us that
directly. Plus this avoids the entire raw pfn side of get_vaddr_frames.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: Kukjin Kim
Cc: Krzysztof Kozlo
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 when buffers get moved
- contiguous dma allocations have moved from dedic
It's the only user. This also garbage collects the CONFIG_FRAME_VECTOR
symbol from all over the tree (well just one place, somehow omap media
driver still had this in its Kconfig, despite not using it).
Reviewed-by: John Hubbard
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Pawel Osciak
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 when buffers get moved
- contiguous dma allocations have moved from dedic
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 when buffers get moved
- contiguous dma allocations have moved from ded
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
CONFIG_STRICT_FOLLOW_PFN, these will be rejected.
Real fix is to wire u
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. And with CONFIG_IO_STRICT_DEVMEM, this is
the default for all driver uses.
Except there's two more ways to access PCI BARs: sysfs and
We want all iomem mmaps to consistently revoke ptes when the kernel
takes over and CONFIG_IO_STRICT_DEVMEM is enabled. This includes the
pci bar mmaps available through procfs and sysfs, which currently do
not revoke mappings.
To prepare for this, move the code from the /dev/kmem driver to
kernel/
There's three ways to access PCI BARs from userspace: /dev/mem, sysfs
files, and the old proc interface. Two check against
iomem_is_exclusive, proc never did. And with CONFIG_IO_STRICT_DEVMEM,
this starts to matter, since we don't want random userspace having
access to PCI BARs while a driver is lo
When we care about pagecache maintenance, we need to make sure that
both f_mapping and i_mapping point at the right mapping.
But for iomem mappings we only care about the virtual/pte side of
things, so f_mapping is enough. Also setting inode->i_mapping was
confusing me as a driver maintainer, sinc
The media model assumes that buffers are all preallocated, so that
when a media pipeline is running we never miss a deadline because the
buffers aren't allocated or available.
This means we cannot fix the v4l follow_pfn usage through
mmu_notifier, without breaking how this all works. The only real
When trying to test my CONFIG_IO_STRICT_DEVMEM changes I realized they
do nothing for i915. Because i915 doesn't request any regions, like
pretty much all drm pci drivers. I guess this is some very old
remnants from the userspace modesetting days, when we wanted to
co-exist with the fbdev driver. W
We want to be able to revoke pci mmaps so that the same access rules
applies as for /dev/kmem. Revoke support for devmem was added in
3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims the
region").
The simplest way to achieve this is by having the same filp->f_mapping
for all mappings,
Hi
Am 09.10.20 um 09:54 schrieb Joel Stanley:
> On Fri, 22 May 2020 at 13:52, Thomas Zimmermann wrote:
>>
>> DRM_GEM_CMA_DRIVER_OPS sets the functions in struct drm_driver
>> to their defaults. No functional changes are made.
>>
>> Signed-off-by: Thomas Zimmermann
>
> I just found this in my in
On Fri, 9 Oct 2020 at 08:01, Thomas Zimmermann wrote:
>
> Hi
>
> Am 09.10.20 um 09:54 schrieb Joel Stanley:
> > On Fri, 22 May 2020 at 13:52, Thomas Zimmermann wrote:
> >>
> >> DRM_GEM_CMA_DRIVER_OPS sets the functions in struct drm_driver
> >> to their defaults. No functional changes are made.
>
Hi
Am 09.10.20 um 10:06 schrieb Joel Stanley:
> On Fri, 9 Oct 2020 at 08:01, Thomas Zimmermann wrote:
>>
>> Hi
>>
>> Am 09.10.20 um 09:54 schrieb Joel Stanley:
>>> On Fri, 22 May 2020 at 13:52, Thomas Zimmermann wrote:
DRM_GEM_CMA_DRIVER_OPS sets the functions in struct drm_driver
Hi Rodrigo,
How do we get W/A and rc6 changes in, do you have any details?
Thanks,
Srinivas
-Original Message-
From: Souza, Jose
Sent: 06 October 2020 23:33
To: Vivi, Rodrigo ; ch...@chris-wilson.co.uk
Cc: Ausmus, James ; Nikula, Jani
; Pandey, Hariom ; Roper,
Matthew D ; intel-...@
Hi,
On 09/10/2020 03:03, Anitha Chrisanthus wrote:
> 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
User-space should avoid parsing EDIDs for metadata already exposed via
other KMS interfaces and properties. For instance, user-space should not
try to extract a list of modes from the EDID: the kernel might mutate
the mode list (because of link capabilities or quirks for instance).
Other metadata
On Fri, Oct 9, 2020 at 11:24 AM Simon Ser wrote:
>
> User-space should avoid parsing EDIDs for metadata already exposed via
> other KMS interfaces and properties. For instance, user-space should not
> try to extract a list of modes from the EDID: the kernel might mutate
> the mode list (because of
On Fri, Oct 09, 2020 at 09:59:34AM +0200, Daniel Vetter wrote:
> When trying to test my CONFIG_IO_STRICT_DEVMEM changes I realized they
> do nothing for i915. Because i915 doesn't request any regions, like
> pretty much all drm pci drivers. I guess this is some very old
> remnants from the userspac
Hi
Am 09.10.20 um 11:24 schrieb Simon Ser:
> User-space should avoid parsing EDIDs for metadata already exposed via
> other KMS interfaces and properties. For instance, user-space should not
> try to extract a list of modes from the EDID: the kernel might mutate
> the mode list (because of link ca
Hi
Am 09.10.20 um 11:48 schrieb Thomas Zimmermann:
> Hi
>
> Am 09.10.20 um 11:24 schrieb Simon Ser:
>> User-space should avoid parsing EDIDs for metadata already exposed via
>> other KMS interfaces and properties. For instance, user-space should not
>> try to extract a list of modes from the EDID
On Fri, Oct 9, 2020 at 11:47 AM Ville Syrjälä
wrote:
>
> On Fri, Oct 09, 2020 at 09:59:34AM +0200, Daniel Vetter wrote:
> > When trying to test my CONFIG_IO_STRICT_DEVMEM changes I realized they
> > do nothing for i915. Because i915 doesn't request any regions, like
> > pretty much all drm pci dri
Em Fri, 9 Oct 2020 09:59:23 +0200
Daniel Vetter escreveu:
> It's the only user. This also garbage collects the CONFIG_FRAME_VECTOR
> symbol from all over the tree (well just one place, somehow omap media
> driver still had this in its Kconfig, despite not using it).
>
> Reviewed-by: John Hubbar
vgem is a minimalistic driver that provides shmemfs objects to
userspace that may then be used as an in-memory surface and transported
across dma-buf to other drivers. Since it's introduction,
drm_gem_shmem_helper now provides the same shmemfs facilities and so we
can trim vgem to wrap the helper.
On Fri, Oct 09, 2020 at 09:24:01AM +, Simon Ser wrote:
> User-space should avoid parsing EDIDs for metadata already exposed via
> other KMS interfaces and properties. For instance, user-space should not
> try to extract a list of modes from the EDID: the kernel might mutate
> the mode list (bec
On Fri, 9 Oct 2020 11:48:44 +0200
Thomas Zimmermann wrote:
> Hi
>
> Am 09.10.20 um 11:24 schrieb Simon Ser:
> > User-space should avoid parsing EDIDs for metadata already exposed via
> > other KMS interfaces and properties. For instance, user-space should not
> > try to extract a list of modes f
Hi,
Em Fri, 9 Oct 2020 09:59:26 +0200
Daniel Vetter escreveu:
> 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_rang
On Fri, Oct 09, 2020 at 12:01:39PM +0200, Daniel Vetter wrote:
> On Fri, Oct 9, 2020 at 11:47 AM Ville Syrjälä
> wrote:
> >
> > On Fri, Oct 09, 2020 at 09:59:34AM +0200, Daniel Vetter wrote:
> > > When trying to test my CONFIG_IO_STRICT_DEVMEM changes I realized they
> > > do nothing for i915. Bec
On Fri, 9 Oct 2020 at 08:26, Thomas Zimmermann wrote:
>
> Hi
>
> Am 09.10.20 um 10:06 schrieb Joel Stanley:
> > On Fri, 9 Oct 2020 at 08:01, Thomas Zimmermann wrote:
> >>
> >> Hi
> >>
> >> Am 09.10.20 um 09:54 schrieb Joel Stanley:
> >>> On Fri, 22 May 2020 at 13:52, Thomas Zimmermann
> >>> wro
On Fri, Oct 09, 2020 at 09:59:32AM +0200, Daniel Vetter wrote:
> We want to be able to revoke pci mmaps so that the same access rules
> applies as for /dev/kmem. Revoke support for devmem was added in
> 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims the
> region").
>
> The simplest
On Fri, Oct 09, 2020 at 09:59:31AM +0200, Daniel Vetter wrote:
> We want all iomem mmaps to consistently revoke ptes when the kernel
> takes over and CONFIG_IO_STRICT_DEVMEM is enabled. This includes the
> pci bar mmaps available through procfs and sysfs, which currently do
> not revoke mappings.
>
Hi,
On Fri, 9 Oct 2020 at 10:24, Simon Ser wrote:
> User-space should avoid parsing EDIDs for metadata already exposed via
> other KMS interfaces and properties. For instance, user-space should not
> try to extract a list of modes from the EDID: the kernel might mutate
> the mode list (because of
Am 09.10.20 um 14:12 schrieb Jason Gunthorpe:
On Fri, Oct 09, 2020 at 09:39:00AM +0200, Daniel Vetter wrote:
I just noticed this here in the patch because everyone else does not do
this. But looking at the mmap_region() code in mmap.c we seem to indeed
have this problem for the error path:
unma
Em Fri, 9 Oct 2020 09:21:11 -0300
Jason Gunthorpe escreveu:
> On Fri, Oct 09, 2020 at 12:34:21PM +0200, Mauro Carvalho Chehab wrote:
> > Hi,
> >
> > Em Fri, 9 Oct 2020 09:59:26 +0200
> > Daniel Vetter escreveu:
> >
> > > Way back it was a reasonable assumptions that iomem mappings never
> >
Em Fri, 9 Oct 2020 14:37:23 +0200
Mauro Carvalho Chehab escreveu:
> Em Fri, 9 Oct 2020 09:21:11 -0300
> Jason Gunthorpe escreveu:
>
> > On Fri, Oct 09, 2020 at 12:34:21PM +0200, Mauro Carvalho Chehab wrote:
> > > Hi,
> > >
> > > Em Fri, 9 Oct 2020 09:59:26 +0200
> > > Daniel Vetter escreve
Add clock configuration for 154MHz pixelclock to Exynos542x HDMIPHY,
which is required for 1920x1200@60Hz mode. The PLL configuration data
has been taken from the vendor's kernel tree for the Odroid XU4 board.
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 9 +
On Fri, Oct 09, 2020 at 01:07:20PM +0100, Daniel Stone wrote:
> Hi,
>
> On Fri, 9 Oct 2020 at 10:24, Simon Ser wrote:
> > User-space should avoid parsing EDIDs for metadata already exposed via
> > other KMS interfaces and properties. For instance, user-space should not
> > try to extract a list o
Hi Matteo, +Joe to Cc
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: Matte
> On Oct 9, 2020, at 1:31 AM, K, SrinivasX wrote:
>
> Hi Rodrigo,
>
> How do we get W/A and rc6 changes in, do you have any details?
I told based on what I was seeing on
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip-alt.html?
focusing on the issues that are exclusively for ehl and not hap
On Fri, Oct 09, 2020 at 09:08:51AM +0200, Christian König wrote:
> Am 08.10.20 um 16:34 schrieb Gustavo A. R. Silva:
> > 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
> > ---
> >
On Fri, 9 Oct 2020 16:10:25 +0300
Ville Syrjälä wrote:
> On Fri, Oct 09, 2020 at 01:07:20PM +0100, Daniel Stone wrote:
> > Hi,
> >
> > On Fri, 9 Oct 2020 at 10:24, Simon Ser wrote:
> > > User-space should avoid parsing EDIDs for metadata already exposed via
> > > other KMS interfaces and prop
On Wed, 07 Oct 2020 17:49:14 +, Caleb Connolly wrote:
> 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
On Wed, Oct 07, 2020 at 05:49:14PM +, Caleb Connolly wrote:
> 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
On Fri, Oct 9, 2020 at 12:42 PM Ville Syrjälä
wrote:
>
> On Fri, Oct 09, 2020 at 12:01:39PM +0200, Daniel Vetter wrote:
> > On Fri, Oct 9, 2020 at 11:47 AM Ville Syrjälä
> > wrote:
> > >
> > > On Fri, Oct 09, 2020 at 09:59:34AM +0200, Daniel Vetter wrote:
> > > > When trying to test my CONFIG_IO_
On Fri, Oct 09, 2020 at 04:56:51PM +0300, Pekka Paalanen wrote:
> On Fri, 9 Oct 2020 16:10:25 +0300
> Ville Syrjälä wrote:
>
> > On Fri, Oct 09, 2020 at 01:07:20PM +0100, Daniel Stone wrote:
> > > Hi,
> > >
> > > On Fri, 9 Oct 2020 at 10:24, Simon Ser wrote:
> > > > User-space should avoid pa
On Fri, Oct 9, 2020 at 2:31 PM Jason Gunthorpe wrote:
>
> On Fri, Oct 09, 2020 at 09:59:31AM +0200, Daniel Vetter wrote:
>
> > +struct address_space *iomem_get_mapping(void)
> > +{
> > + return iomem_inode->i_mapping;
>
> This should pair an acquire with the release below
>
> > + /*
> > +
Am 09.10.20 um 15:54 schrieb Gustavo A. R. Silva:
On Fri, Oct 09, 2020 at 09:08:51AM +0200, Christian König wrote:
Am 08.10.20 um 16:34 schrieb Gustavo A. R. Silva:
Make use of the new struct_size() helper instead of the offsetof() idiom.
Also, use kmalloc() instead of kcalloc().
Signed-off-by
On Fri, Oct 09, 2020 at 04:29:55PM +0200, Christian König wrote:
> > > > - entity = kcalloc(1, offsetof(typeof(*entity),
> > > > fences[amdgpu_sched_jobs]),
> > > > + entity = kmalloc(struct_size(entity, fences, amdgpu_sched_jobs),
> > > NAK. You could use kzalloc() here, but kmalloc w
> -Original Message-
> From: Neil Armstrong
> Sent: Friday, October 9, 2020 2:10 AM
> To: Chrisanthus, Anitha ; dri-
> de...@lists.freedesktop.org; devicet...@vger.kernel.org; Vetter, Daniel
>
> Cc: Dea, Edmund J ; s...@ravnborg.org
> Subject: Re: [PATCH v9 1/5] dt-bindings: display: A
On Tue, 06 Oct 2020 18:17:22 +0200,
Kai Vehmanen wrote:
>
> From: Takashi Iwai
>
> Current hdac_i915 uses a static completion instance to wait
> for i915 driver to complete the component bind.
>
> This design is not safe if multiple HDA controllers are active and
> communicating with different
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
---
1 - 100 of 209 matches
Mail list logo
