From: Thomas Hellstrom
For graphics drivers needing to modify the page-protection, add
huge page-table entries counterparts to vmf_insert_prn_prot().
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Matthew Wilcox (Oracle)"
Cc: "Kirill A. Shutemov"
Cc: Ralph Campbell
Cc: "Jérôme Glisse"
Cc:
From: Thomas Hellstrom
Start using the helpers that align buffer object user-space addresses and
buffer object vram addresses to huge page boundaries.
This is to improve the chances of allowing huge page-table entries.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Matthew Wilcox (Oracle)"
Cc:
From: Thomas Hellstrom
We currently only do COW and write-notify on the PTE level, so if the
huge_fault() handler returns VM_FAULT_FALLBACK on wp faults,
split the huge pages and page-table entries. Also do this for huge PUDs
if there is no huge_fault() handler and the vma is not anonymous,
From: Thomas Hellstrom
For VM_PFNMAP and VM_MIXEDMAP vmas that want to support transhuge pages
and -page table entries, introduce vma_is_special_huge() that takes the
same codepaths as vma_is_dax().
The use of "special" follows the definition in memory.c, vm_normal_page():
"Special" mappings do
From: Thomas Hellstrom
This helper is used to align user-space buffer object addresses to
huge page boundaries, minimizing the chance of alignment mismatch
between user-space addresses and physical addresses.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Matthew Wilcox (Oracle)"
Cc: "Kirill A.
Add releases() function to fix context imbalance.
Issue detected by sparse tool.
warning: context imbalance in ttm_bo_cleanup_refs - unexpected unlock
Signed-off-by: Jules Irenge
---
drivers/gpu/drm/ttm/ttm_bo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Thanks for the review Ville, please see inline:
> -Original Message-
> From: Ville Syrjälä
> Sent: 26 November 2019 07:15
> To: Devarsh Thakkar
> Cc: dri-devel@lists.freedesktop.org; Hyun Kwon ; vcu-
> team ; Ranganathan Sk ; Dhaval
> Rajeshbhai Shah ; Satish Kumar Nagireddy
> ;
From: Yongqiang Niu
Fix external display issue
Yongqiang Niu (2):
drm/mediatek: Fixup external display black screen issue
drm/mediatek: Fix external display vblank timeout issue
drivers/gpu/drm/mediatek/mtk_dpi.c | 14 +
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 45
On Tue, Nov 19, 2019 at 9:16 PM Jason Wang wrote:
>
> On 2019/11/19 下午10:14, Jason Gunthorpe wrote:
> > On Tue, Nov 19, 2019 at 10:02:08PM +0800, Jason Wang wrote:
> >> On 2019/11/19 下午8:38, Jason Gunthorpe wrote:
> >>> On Tue, Nov 19, 2019 at 10:41:31AM +0800, Jason Wang wrote:
> On
Reviewed-by: Alyssa Rosenzweig
On Mon, Nov 18, 2019 at 05:30:02PM +, Steven Price wrote:
> Currently when setting a frequency in panfrost_devfreq_target the
> returned frequency is the actual frequency that the clock driver reports
> (the return of clk_get_rate()). However, where the
According to VESA ENHANCED EXTENDED DISPLAY IDENTIFICATION DATA STANDARD
(Defines EDID Structure Version 1, Revision 4) page: 39
How to determine whether the monitor support RB timing or not?
EDID 1.4
First: read detailed timing descriptor and make sure byte 0 = 0x00,
byte 1 = 0x00, byte
From: Yongqiang Niu
Fix external display vblank timeout issue
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 14 +-
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 6 ++
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 14 ++
3 files
Hi Daniel, David!
Any chance for this one to be processed sometime soon?
It's been quite some time since July when I initially sent
this pull-request.
-Alexey
> -Original Message-
> From: linux-snps-arc On Behalf
> Of Alexey Brodkin
> Sent: Wednesday, November 13, 2019 2:30 PM
> To:
From: Yongqiang Niu
Problem:
overlay hangup when external display hotplut test
Fix:
disable overlay when crtc disable
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 39 +
1 file changed, 25 insertions(+), 14 deletions(-)
diff --git
ping...
On Thu, Nov 21, 2019 at 12:09 PM Navid Emamdoost
wrote:
>
> On Mon, Oct 21, 2019 at 4:14 PM Navid Emamdoost
> wrote:
> >
> > In the implementation of nouveau_bo_alloc() if it fails to determine the
> > target page size via pi, then the allocated memory for nvbo should be
> > released.
>
On Mon, Nov 25, 2019 at 11:33:27AM -0500, Jerome Glisse wrote:
> On Fri, Nov 22, 2019 at 11:33:12PM +, Jason Gunthorpe wrote:
> > On Fri, Nov 22, 2019 at 12:57:27PM -0800, Niranjana Vishwanathapura wrote:
>
> [...]
>
> > > +static int
> > > +i915_range_fault(struct i915_svm *svm, struct
Add inline function to derive floating value of vertical
refresh rate from pixel clock, horizontal total size and
vertical total size.
Use this function to find suitable mode having vrefresh
value which is matching with user provided vrefresh value.
If user doesn't provide any vrefresh value in
On Mon, Nov 25, 2019 at 08:32:58AM -0800, Niranjan Vishwanathapura wrote:
> > And putting the cpu PFN of a ZONE_DEVICE device page into
> > sg_dma_address still looks very wrong to me
>
> The below call in patch 7 does convert any cpu PFN to device address.
> So, it won't be CPU PFN.
>
Am 26.11.19 um 21:27 schrieb Thomas Hellström (VMware):
From: Thomas Hellstrom
We were using an ugly hack to set the page protection correctly.
Fix that and instead use vmf_insert_mixed_prot() and / or
vmf_insert_pfn_prot().
Also get the default page protection from
struct
From: Thomas Hellstrom
Using huge page-table entries require that the start of a buffer object
is huge page size aligned. So introduce a ttm_bo_man_get_node_huge()
function that attempts to accomplish this for allocations that are larger
than the huge page size, and provide a new range-manager
From: Thomas Hellstrom
Support huge (PMD-size and PUD-size) page-table entries by providing a
huge_fault() callback.
We still support private mappings and write-notify by splitting the huge
page-table entries on write-access.
Note that for huge page-faults to occur, either the kernel needs to
In order to save TLB space and CPU usage this patchset enables huge- and giant
page-table entries for TTM and TTM-enabled graphics drivers.
Patch 1 introduces a vma_is_special_huge() function to make the mm code
take the same path as DAX when splitting huge- and giant page table entries,
(which
Am 26.11.19 um 21:27 schrieb Thomas Hellström (VMware):
From: Thomas Hellstrom
The TTM module today uses a hack to be able to set a different page
protection than struct vm_area_struct::vm_page_prot. To be able to do
this properly, add and export vmf_insert_mixed_prot().
Cc: Andrew Morton
Am 27.11.19 um 09:31 schrieb Thomas Hellström (VMware):
From: Thomas Hellstrom
Support huge (PMD-size and PUD-size) page-table entries by providing a
huge_fault() callback.
We still support private mappings and write-notify by splitting the huge
page-table entries on write-access.
Note that
Tested on qemu, with bochs (vram helpers) and cirrus (shmem helpers).
Cc'ing intel-gfx for CI coverage.
v3: better fake-offset handling in drm_gem_prime_mmap() (Rob)
Gerd Hoffmann (2):
drm: call drm_gem_object_funcs.mmap with fake offset
drm: share address space for dma bufs
The fake offset is going to stay, so change the calling convention for
drm_gem_object_funcs.mmap to include the fake offset. Update all users
accordingly.
Note that this reverts 83b8a6f242ea ("drm/gem: Fix mmap fake offset
handling for drm_gem_object_funcs.mmap") and on top then adds the fake
Use the shared address space of the drm device (see drm_open() in
drm_file.c) for dma-bufs too. That removes a difference betweem drm
device mmap vmas and dma-buf mmap vmas and fixes corner cases like
dropping ptes (using madvise(DONTNEED) for example) not working
properly.
Also remove amdgpu
On Tuesday, 26 November 2019 19:37:40 GMT Sam Ravnborg wrote:
> Hi Mihail.
Hi Sam,
>
> On Tue, Nov 26, 2019 at 01:16:26PM +, Mihail Atanassov wrote:
> > No functional change.
> >
> > Signed-off-by: Mihail Atanassov
> > ---
> > drivers/gpu/drm/sti/sti_dvo.c | 4 +---
> > 1 file changed, 1
On Tuesday, 26 November 2019 19:24:45 GMT Sam Ravnborg wrote:
> Hi Mihail.
Hi Sam,
>
> > Ack, but with one caveat: bridge->dev is the struct drm_device that is
> > the bridge client, we need to add a bridge->device (patch 29 in this
> > series) which is the struct device that will manage the
On Wed, Nov 27, 2019 at 11:05:56AM +, Mihail Atanassov wrote:
> On Tuesday, 26 November 2019 19:24:45 GMT Sam Ravnborg wrote:
> > Hi Mihail.
>
> Hi Sam,
>
> >
> > > Ack, but with one caveat: bridge->dev is the struct drm_device that is
> > > the bridge client, we need to add a
On Wed, Nov 27, 2019 at 11:22:45AM +0100, Yannick Fertre wrote:
> From: Yannick Fertré
>
> Some bridges did not registered the post_disable function.
> To avoid a crash, check it before calling.
>
> Signed-off-by: Yannick Fertre
Reviewed-by: Daniel Vetter
> ---
>
Hi Daniel,
W dniu 15.11.2019 o 10:21, Daniel Vetter pisze:
If rockchip would switch over to the generic fbdev setup we could
grabage collect even more of all this code (all of the remaining fb
handling code really).
Signed-off-by: Daniel Vetter
Cc: Sandy Huang
Cc: "Heiko Stübner"
Cc:
On Wed, Nov 27, 2019 at 06:31:57PM +0200, Jani Nikula wrote:
> Modifying fb_ops directly to override fb_mmap with fb_deferred_io_mmap
> and then resetting it to NULL afterwards causes problems all over the
> place. First, it prevents making the fbops member of struct fb_info a
> const pointer,
Hi Sam,
And thank you for the prompt review comments!
On 26/11/2019 23:26, Sam Ravnborg wrote:
> Hi Jyri.
>
> Took a quick look - looks like a very nice driver.
> Some drive by comments below.
>
> I was left with the impression that there is a lot of code to support
> vblank - and I wonder if
Le mer. 27 nov. 2019 à 17:19, Sam Ravnborg a écrit :
>
> Hi Mihail.
>
> > >
> > > I can see from grepping that bridge.driver_private is used
> > > in a couple of other files in sti/
> > >
> > > Like sti_hdmi.c:
> > > bridge->driver_private = hdmi;
> > > bridge->funcs =
Caused by file removal without adjusting the Makefile.
Fixes: d268f42e6856 ("drm/mediatek: don't open-code drm_gem_fb_create")
Cc: Daniel Vetter
Cc: CK Hu
Cc: Philipp Zabel
Cc: Matthias Brugger
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-media...@lists.infradead.org
Signed-off-by:
On Thu, 21 Nov 2019, Krzysztof Kozlowski wrote:
> Adjust indentation from spaces to tab (+optional two spaces) as in
> coding style with command like:
> $ sed -e 's/^/\t/' -i */Kconfig
Btw have you updated checkpatch.pl to try to keep the Kconfigs from
bitrotting back to having
On Wed, Nov 27, 2019 at 02:42:35PM +, Laurentiu Palcu wrote:
> According to CTA-861 specification, HDR static metadata data block allows a
> sink to indicate which HDR metadata types it supports by setting the SM_0 to
> SM_7 bits. Currently, only Static Metadata Type 1 is supported and this is
Deferred IO now preserves the fb_ops.
Cc: Steve Glendinning
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Jani Nikula
---
drivers/video/fbdev/smscufx.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/fbdev/smscufx.c b/drivers/video/fbdev/smscufx.c
index
Use const for fb_ops to let us make the info->fbops pointer const in the
future.
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Jani Nikula
---
drivers/video/fbdev/core/fbmem.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/core/fbmem.c
Deferred IO now preserves the fb_ops.
Cc: Noralf Trønnes
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_fb_helper.c | 18 ++
1 file changed, 2 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c
So I wanted to quickly move our struct fb_ops to const data because we
don't modify it... and this series is where the rabbit hole ends. Ugh.
The main pain point is deferred IO, which is covered in patch
1. Everything gets easier after that. The last 5 could be merged at
leisure.
BR,
Jani.
Now that the fbops member of struct fb_info is const, we can start
making the ops const as well.
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 2 +-
drivers/gpu/drm/armada/armada_fbdev.c | 2 +-
Avoid modifying the fb_ops via info->fbops to let us make the pointer
const in the future.
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Jani Nikula
---
drivers/video/fbdev/vesafb.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/vesafb.c
Deferred IO now preserves the fb_ops.
Cc: Bernie Thompson
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Jani Nikula
---
drivers/video/fbdev/udlfb.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/fbdev/udlfb.c b/drivers/video/fbdev/udlfb.c
index fe373b63ddd6..07905d385949
Now that we no longer modify the fbops, or hold non-const pointers to
it, we can make it const. With that, also deferred_io_private needs to
be const. After this, we can start making the fbops const all over the
place.
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Jani Nikula
---
Modifying fb_ops directly to override fb_mmap with fb_deferred_io_mmap
and then resetting it to NULL afterwards causes problems all over the
place. First, it prevents making the fbops member of struct fb_info a
const pointer, which means we can't make struct fb_ops const
anywhere. Second, a few
According to CTA-861 specification, HDR static metadata data block allows a
sink to indicate which HDR metadata types it supports by setting the SM_0 to
SM_7 bits. Currently, only Static Metadata Type 1 is supported and this is
indicated by setting the SM_0 bit to 1.
However, the
From: Emil Velikov
Current validation requires that we're authenticated, even though we can
bypass (by design) the authentication when using a render node.
Let's address the former by following the design decision.
v2: Add simpler validation in the ioctls themselves (Boris)
Cc: Alex Deucher
On Wed, 27 Nov 2019 at 07:41, Boris Brezillon
wrote:
>
> Hi Emil,
>
> On Fri, 1 Nov 2019 13:03:13 +
> Emil Velikov wrote:
>
> > From: Emil Velikov
> >
> > As mentioned by Christian, for drivers which support only primary nodes
> > this changes the returned error from -EACCES into
On 2019-11-20 12:22 p.m., Colin King wrote:
> From: Colin Ian King
>
> The msg_id field is being assigned twice. Fix this by replacing the second
> assignment with an assignment to msg_size.
>
> Addresses-Coverity: ("Unused value")
> Fixes: 11a00965d261 ("drm/amd/display: Add PSP block to
https://bugzilla.kernel.org/show_bug.cgi?id=205675
Pierre-Eric Pelloux-Prayer (pierre-eric.pelloux-pra...@amd.com) changed:
What|Removed |Added
CC|
Ping...
Andrey
On 11/26/19 10:36 AM, Andrey Grodzovsky wrote:
On 11/26/19 4:08 AM, Christian König wrote:
Am 25.11.19 um 17:51 schrieb Steven Price:
On 25/11/2019 14:10, Andrey Grodzovsky wrote:
When the sched thread is parked we assume ring_mirror_list is
not accessed from here.
FWIW I
On Wed, Nov 27, 2019 at 07:28:31AM +, Devarsh Thakkar wrote:
> Thanks for the review Ville, please see inline:
>
> > -Original Message-
> > From: Ville Syrjälä
> > Sent: 26 November 2019 07:15
> > To: Devarsh Thakkar
> > Cc: dri-devel@lists.freedesktop.org; Hyun Kwon ; vcu-
> > team
Hi Tony, Thierry, Laurent,
Any thoughts on the below points?
I think yet another option is to write some omap boot time quirks code, which looks at the DT data,
and changes the panel compatible string (for 1), and removes the timings node (for 2).
Tomi
On 14/11/2019 11:39, Tomi Valkeinen
On Wed, Nov 27, 2019 at 2:49 PM Alexey Brodkin
wrote:
>
> Hi Daniel,
>
> > -Original Message-
> > From: Daniel Vetter
> > Sent: Wednesday, November 27, 2019 1:07 PM
> > To: Alexey Brodkin
> > Cc: Daniel Vetter ; David Airlie ; arcml
> > > a...@lists.infradead.org>; Eugeniy Paltsev ;
Am 27.11.19 um 16:32 schrieb Andrey Grodzovsky:
Ping...
Andrey
On 11/26/19 10:36 AM, Andrey Grodzovsky wrote:
On 11/26/19 4:08 AM, Christian König wrote:
Am 25.11.19 um 17:51 schrieb Steven Price:
On 25/11/2019 14:10, Andrey Grodzovsky wrote:
When the sched thread is parked we assume
Hi Thomas,
On Tue, 26 Nov 2019 at 10:15, Thomas Zimmermann wrote:
>
> Adds a conversion function that extracts the device type from the
> PCI id-table flags. Allows for storing additional information in the
> other flag bits.
>
> Signed-off-by: Thomas Zimmermann
> Fixes: 81da87f63a1e ("drm:
Now that the fbops member of struct fb_info is const, we can star making
the ops const as well.
Cc: Bruno Prémont
Cc: linux-in...@vger.kernel.org
Signed-off-by: Jani Nikula
---
drivers/hid/hid-picolcd_fb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
Now that the fbops member of struct fb_info is const, we can star making
the ops const as well.
Cc: Hans Verkuil
Cc: Andy Walls
Cc: linux-me...@vger.kernel.org
Cc: ivtv-de...@ivtvdriver.org
Signed-off-by: Jani Nikula
---
drivers/media/pci/ivtv/ivtvfb.c | 3 +--
Use const for fb_ops to let us make the info->fbops pointer const in the
future.
Cc: linux-fb...@vger.kernel.org
Cc: linux-o...@vger.kernel.org
Signed-off-by: Jani Nikula
---
drivers/video/fbdev/omap/omapfb_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Now that the fbops member of struct fb_info is const, we can star making
the ops const as well.
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Jani Nikula
---
drivers/video/fbdev/68328fb.c | 2 +-
drivers/video/fbdev/acornfb.c | 2 +-
Now that the fbops member of struct fb_info is const, we can star making
the ops const as well.
Cc: Kirti Wankhede
Cc: k...@vger.kernel.org
Signed-off-by: Jani Nikula
---
samples/vfio-mdev/mdpy-fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/samples/vfio-mdev/mdpy-fb.c
Hi Mihail.
> >
> > I can see from grepping that bridge.driver_private is used
> > in a couple of other files in sti/
> >
> > Like sti_hdmi.c:
> > bridge->driver_private = hdmi;
> > bridge->funcs = _hdmi_bridge_funcs;
> > drm_bridge_attach(encoder, bridge, NULL);
> >
> >
If rockchip would switch over to the generic fbdev setup we could
grabage collect even more of all this code (all of the remaining fb
handling code really).
v2: Actually use _with_dirty like the patch subject promised (Andrzej)
Cc: Andrzej Pietrasiewicz
Signed-off-by: Daniel Vetter
Cc: Sandy
On Wed, 27 Nov 2019 at 18:04, Daniel Vetter wrote:
>
> On Wed, Nov 27, 2019 at 04:27:29PM +, Emil Velikov wrote:
> > On Wed, 27 Nov 2019 at 07:41, Boris Brezillon
> > wrote:
> > >
> > > Hi Emil,
> > >
> > > On Fri, 1 Nov 2019 13:03:13 +
> > > Emil Velikov wrote:
> > >
> > > > From:
On Wed, Nov 27, 2019 at 6:33 PM Andrzej Pietrasiewicz
wrote:
>
> Hi Daniel,
>
> After applying this patch there are some slight differences
> in the effective behavior of the code.
>
> I can't tell if they are important, please see below.
>
> Andrzej
>
> W dniu 15.11.2019 o 10:21, Daniel Vetter
On Wed, Nov 27, 2019 at 06:31:59PM +0200, Jani Nikula wrote:
> Deferred IO now preserves the fb_ops.
>
> Cc: Steve Glendinning
> Cc: linux-fb...@vger.kernel.org
> Signed-off-by: Jani Nikula
> ---
> drivers/video/fbdev/smscufx.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git
On Wed, Nov 27, 2019 at 07:17:41PM +0100, Daniel Vetter wrote:
> On Wed, Nov 27, 2019 at 06:31:57PM +0200, Jani Nikula wrote:
> > Modifying fb_ops directly to override fb_mmap with fb_deferred_io_mmap
> > and then resetting it to NULL afterwards causes problems all over the
> > place. First, it
On Wed, Nov 27, 2019 at 06:32:56PM +, Emil Velikov wrote:
> On Wed, 27 Nov 2019 at 18:04, Daniel Vetter wrote:
> >
> > On Wed, Nov 27, 2019 at 04:27:29PM +, Emil Velikov wrote:
> > > On Wed, 27 Nov 2019 at 07:41, Boris Brezillon
> > > wrote:
> > > >
> > > > Hi Emil,
> > > >
> > > > On
On Tue, Nov 26, 2019 at 03:59:31PM +0200, Joonas Lahtinen wrote:
Quoting Niranjan Vishwanathapura (2019-11-25 18:40:57)
On Mon, Nov 25, 2019 at 09:59:37AM +, Chris Wilson wrote:
>Quoting Niranjana Vishwanathapura (2019-11-22 20:57:24)
>> Shared Virtual Memory (SVM) runtime allocator support
Hi Daniel,
After applying this patch there are some slight differences
in the effective behavior of the code.
I can't tell if they are important, please see below.
Andrzej
W dniu 15.11.2019 o 10:21, Daniel Vetter pisze:
If rockchip would switch over to the generic fbdev setup we could
On Wed, Nov 27, 2019 at 04:27:29PM +, Emil Velikov wrote:
> On Wed, 27 Nov 2019 at 07:41, Boris Brezillon
> wrote:
> >
> > Hi Emil,
> >
> > On Fri, 1 Nov 2019 13:03:13 +
> > Emil Velikov wrote:
> >
> > > From: Emil Velikov
> > >
> > > As mentioned by Christian, for drivers which
On Wed, Nov 27, 2019 at 07:01:16PM +0200, Ville Syrjälä wrote:
> On Wed, Nov 27, 2019 at 06:31:57PM +0200, Jani Nikula wrote:
> > Modifying fb_ops directly to override fb_mmap with fb_deferred_io_mmap
> > and then resetting it to NULL afterwards causes problems all over the
> > place. First, it
Hi Emil
Am 27.11.19 um 17:29 schrieb Emil Velikov:
> Hi Thomas,
>
> On Tue, 26 Nov 2019 at 10:15, Thomas Zimmermann wrote:
>>
>> Adds a conversion function that extracts the device type from the
>> PCI id-table flags. Allows for storing additional information in the
>> other flag bits.
>>
>>
On Wed, Nov 27, 2019 at 05:05:32PM +, Mihail Atanassov wrote:
> Caused by file removal without adjusting the Makefile.
>
> Fixes: d268f42e6856 ("drm/mediatek: don't open-code drm_gem_fb_create")
> Cc: Daniel Vetter
> Cc: CK Hu
> Cc: Philipp Zabel
> Cc: Matthias Brugger
> Cc:
On Wed, Nov 27, 2019 at 06:31:58PM +0200, Jani Nikula wrote:
> Deferred IO now preserves the fb_ops.
>
> Cc: Noralf Trønnes
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Jani Nikula
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_fb_helper.c | 18 ++
> 1 file
https://bugzilla.kernel.org/show_bug.cgi?id=205675
--- Comment #2 from freddyrei...@comcast.net ---
Hello! Glad to see there's others looking at this. My mesa is on 19.3.0_rc4,
but the issue is still happening. That related bug in your second link talks
about 5.4 kernel being out but not having
On Wed, Nov 27, 2019 at 06:31:57PM +0200, Jani Nikula wrote:
> Modifying fb_ops directly to override fb_mmap with fb_deferred_io_mmap
> and then resetting it to NULL afterwards causes problems all over the
> place. First, it prevents making the fbops member of struct fb_info a
> const pointer,
On Wed, Nov 27, 2019 at 06:32:09PM +0200, Jani Nikula wrote:
> Now that the fbops member of struct fb_info is const, we can star making
> the ops const as well.
>
> Cc: Kirti Wankhede
> Cc: k...@vger.kernel.org
> Signed-off-by: Jani Nikula
You've missed at least drivers/staging/fbtft in your
Again we could delete a lot more if we'd switch over to the generic
fbdev stuff.
Signed-off-by: Daniel Vetter
---
.../gpu/drm/hisilicon/hibmc/hibmc_drm_de.c| 4 +-
.../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 11 +---
.../gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 5 +-
We're doing a great job for really simple drivers right now, but still
a lot of boilerplate for the bigger ones.
Signed-off-by: Daniel Vetter
---
Documentation/gpu/todo.rst | 26 ++
1 file changed, 26 insertions(+)
diff --git a/Documentation/gpu/todo.rst
On Wed, Nov 27, 2019 at 06:32:00PM +0200, Jani Nikula wrote:
> Deferred IO now preserves the fb_ops.
>
> Cc: Bernie Thompson
> Cc: linux-fb...@vger.kernel.org
> Signed-off-by: Jani Nikula
Reviewed-by: Daniel Vetter
Aside: I wonder whether we should start retiring all the fbdev drivers
which
On Wed, Nov 27, 2019 at 06:32:01PM +0200, Jani Nikula wrote:
> Avoid modifying the fb_ops via info->fbops to let us make the pointer
> const in the future.
>
> Cc: linux-fb...@vger.kernel.org
> Signed-off-by: Jani Nikula
> ---
> drivers/video/fbdev/vesafb.c | 6 +++---
> 1 file changed, 3
Hi Jacopo,
On Wed, Nov 13, 2019 at 11:04 AM Jacopo Mondi wrote:
> Add a driver for the R-Car Display Unit Color Correction Module.
> In most of Gen3 SoCs, each DU output channel is provided with a CMM unit
> to perform image enhancement and color correction.
>
> Add support for CMM through a
Hi all,
On Thu, 10 Oct 2019 12:51:06 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
>
> between commit:
>
> 2850748ef876 ("drm/i915: Pull i915_vma_pin under the vm->mutex")
>
> from the drm
Hi all,
On Wed, 6 Nov 2019 13:53:40 +1100 Stephen Rothwell
wrote:
>
> Hi all,
>
> On Thu, 10 Oct 2019 13:14:48 +1100 Stephen Rothwell
> wrote:
> >
> > I added the following merge fix patch for today:
> >
>
> This patch is now just:
>
> From: Stephen Rothwell
> Date: Thu, 10 Oct 2019
On Thu, 28 Nov 2019 at 11:51, Linus Torvalds
wrote:
>
> On Wed, Nov 27, 2019 at 4:59 PM Dave Airlie wrote:
> >
> > my sample merge is here:
> > https://cgit.freedesktop.org/~airlied/linux/log/?h=drm-next-5.5-merged
>
> Hmm. I think you missed a couple: you left a duplicate
>
Hi Tony,
On 27/11/2019 17:45, Tony Lindgren wrote:
Interestingly, the actual panel at least on my EVMs and ePOSes is not
osd057T0559-34ts, but osd070t1718-19ts. Also, I was unable to find any
information about osd057T0559-34ts. I don't know the history with this,
so it is possible that the
On Tue, Nov 26, 2019 at 03:44:26PM +0200, Joonas Lahtinen wrote:
Quoting Niranjana Vishwanathapura (2019-11-22 22:57:23)
Define UAPI for Shared Virtual Memory (SVM) fucntionality including
SVM capability and configurability.
When there is no GPU page fault support available, add ioctls
to
Unlike other SoCs, MT8183 does not have "shadow"
registers for performaing an atomic video mode
set or page flip at vblank/vsync.
The CMDQ (Commend Queue) in MT8183 is used to help
update all relevant display controller registers
with critical time limation.
Signed-off-by: YT Shen
The state->base.event variable would be access by thread context
in mtk_drm_crtc_atomic_begin() or by interrupt context in
mtk_drm_crtc_finish_page_flip(), so each part should be a critical
section. Fix it.
Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
The CMDQ (Command Queue) in MT8183 is used to help update all
relevant display controller registers with critical time limation.
This patch add cmdq interface in ddp_comp interface, let all
ddp_comp interface can support cpu/cmdq function at the same time.
These patches also can fixup cursor
On Wed, Nov 27, 2019 at 4:59 PM Dave Airlie wrote:
>
> my sample merge is here:
> https://cgit.freedesktop.org/~airlied/linux/log/?h=drm-next-5.5-merged
Hmm. I think you missed a couple: you left a duplicate
intel_update_rawclk() around (it got moved into
intel_power_domains_init_hw() by commit
On Wed, Nov 13, 2019 at 02:34:27PM +0100, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> Sorry for spoiling your v7 ;-)
>
> On Wed, Nov 13, 2019 at 11:04 AM Jacopo Mondi
> wrote:
> > Document the newly added 'cmms' property which accepts a list of phandle
>
> renesas,cmms
Fix applied to my
On Wed, 27 Nov 2019 at 21:14, Jani Nikula wrote:
>
> On Thu, 21 Nov 2019, Krzysztof Kozlowski wrote:
> > Adjust indentation from spaces to tab (+optional two spaces) as in
> > coding style with command like:
> > $ sed -e 's/^/\t/' -i */Kconfig
>
> Btw have you updated checkpatch.pl
On Wed, 2019-11-27 at 17:56 +0800, Daniel Vetter wrote:
> On Wed, Nov 27, 2019 at 09:41:52AM +0800, Bibby Hsieh wrote:
> > On Tue, 2019-11-26 at 09:49 +0100, Daniel Vetter wrote:
> > > On Tue, Nov 26, 2019 at 02:29:26PM +0800, Bibby Hsieh wrote:
> > > > The DRM core takes care of all atomic state
The DRM core atomic helper now supports asynchronous commits natively.
The custom drm implementation isn't needed anymore, remove it.
Signed-off-by: Bibby Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 86 ++
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 7 ---
2 files
The driver currently handles vblank events only when updating planes on
an already enabled CRTC. The atomic update API however allows requesting
an event when enabling or disabling a CRTC. This currently leads to
event objects being leaked in the kernel and to events not being sent
out. Fix it.
Support to async updates of cursors by using the new atomic
interface for that.
Signed-off-by: Bibby Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 35 +
drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 2 +
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 22 ++-
1 - 100 of 125 matches
Mail list logo
