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 hmm_r
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 a
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.
> i915_dmem_c
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 a/drivers/gpu/drm
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
> ; Varunkum
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 2019/11
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 provided
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 2
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 chan
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: Da
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
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, simil
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. Shut
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: "Christ
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: "Kiri
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 in
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 be
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 is
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
Cc:
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 vm_area_struct::vm_pa
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 fo
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
include/drm/drm
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 dri
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
off
On Tue, Nov 26, 2019 at 09:27:59PM +0100, Andrzej Pietrasiewicz wrote:
> Hi Daniel,
>
> Thanks for the comments, please see inline
>
> W dniu 25.11.2019 o 09:55, Daniel Vetter pisze:
> > On Thu, Nov 21, 2019 at 06:22:44PM +0100, Andrzej Pietrasiewicz wrote:
> > > These are useful for other users
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 refcounting.
> > > However, mediatek drm defers some work that ac
I don't see the advantage over just increasing the alignment
requirements in the driver side?
That would be a one liner if I'm not completely mistaken.
Regards,
Christian.
Am 27.11.19 um 09:31 schrieb Thomas Hellström (VMware):
From: Thomas Hellstrom
Using huge page-table entries require th
On Wed, Nov 27, 2019 at 07:48:04AM +, Alexey Brodkin wrote:
> Hi David, Daniel!
>
> The following changes since commit 8082731830a0b95f7f7a63b78de67de446013c80:
>
> drm/vram: remove unused declaration (2019-11-27 07:51:49 +0100)
>
> are available in the Git repository at:
>
> g...@githu
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
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridg
From: Yannick Fertré
The pin control must be set to default as soon as possible to
establish a good video link between tv & bridge hdmi
(encoder mode set is call before encoder enable).
Signed-off-by: Yannick Fertre
---
drivers/gpu/drm/stm/ltdc.c | 24 ++--
1 file changed,
From: Yannick Fertré
Read the DSI_INT_ST1 status register to check if
errors occur while reading/writing a command to panel.
In case of error, the transfer is retried 3 times.
Signed-off-by: Yannick Fertre
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 99 +++
1 fi
From: Yannick Fertré
Convert gpio to irq if not already done by gpio lib.
Signed-off-by: Yannick Fertré
#include
#include
+#include
#include
#include
#include
@@ -392,6 +393,13 @@ static void goodix_free_irq(struct goodix_ts_data *ts)
static int goodix_request_irq(struct goodix_ts
Le mer. 13 nov. 2019 à 08:55, Benjamin Gaignard
a écrit :
>
> Fix the warnings that show up with W=1.
> They are all about unused but set variables.
gentle ping to reviewers,
Thanks,
Benjamin
>
> Signed-off-by: Benjamin Gaignard
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 50
> +++
From: Yannick Fertré
Add support for it by adding compatible and supported chip data
(default settings used).
The chip data on GT9147 is similar to GT912, like
- config data register has 0x8047 address
- config data register max len is 240
- config data checksum has 8-bit
Signed-off-by: Yannick
On Tue, 26 Nov 2019, allen wrote:
> 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
On Tue, 26 Nov 2019, Lyude Paul wrote:
> I'm about to post some more review comments for the v2 version of this, but
> some comments down below...
>
> On Tue, 2019-10-08 at 12:19 +0300, Jani Nikula wrote:
>> On Mon, 07 Oct 2019, Adam Jackson wrote:
>> > On Mon, 2019-10-07 at 12:08 +0300, Jani Nik
On Wed, Nov 27, 2019 at 08:31:09AM +0100, Thomas Zimmermann wrote:
> When enabling the CRTC after waking up from a power-saving mode, the
> primary plane's framebuffer might be NULL, which leads to a stack trace
> as shown below.
>
> [ 632.624608] BUG: kernel NULL pointer dereference, address:
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 bri
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 bridge->device
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
> ---
> drivers/gpu/drm/bridge/syno
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: linux-a
On Tue, Nov 26, 2019 at 06:10:36PM -0500, Lyude Paul wrote:
> Hey-this is almost certainly not the right place in this thread to respond,
> but this thread has gotten so deep evolution can't push the subject further to
> the right, heh. So I'll just respond here.
:)
> I've been following this and
On Wed, Nov 27, 2019 at 12:49 PM Mika Westerberg
wrote:
>
> On Tue, Nov 26, 2019 at 06:10:36PM -0500, Lyude Paul wrote:
> > Hey-this is almost certainly not the right place in this thread to respond,
> > but this thread has gotten so deep evolution can't push the subject further
> > to
> > the ri
On 11/27/19 10:12 AM, Christian König wrote:
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
pag
On 11/27/19 11:05 AM, Christian König wrote:
I don't see the advantage over just increasing the alignment
requirements in the driver side?
The advantage is that we don't fail space allocation if we can't match
the alignment. We instead fall back to a lower alignment if it's
compatible with th
Hi Daniel
Am 27.11.19 um 11:49 schrieb Daniel Vetter:
> On Wed, Nov 27, 2019 at 08:31:09AM +0100, Thomas Zimmermann wrote:
>> When enabling the CRTC after waking up from a power-saving mode, the
>> primary plane's framebuffer might be NULL, which leads to a stack trace
>> as shown below.
>>
>> [
On Wed, Nov 27, 2019 at 01:31:25PM +0100, Thomas Zimmermann wrote:
> Hi Daniel
>
> Am 27.11.19 um 11:49 schrieb Daniel Vetter:
> > On Wed, Nov 27, 2019 at 08:31:09AM +0100, Thomas Zimmermann wrote:
> >> When enabling the CRTC after waking up from a power-saving mode, the
> >> primary plane's frame
Am 27.11.19 um 13:38 schrieb Daniel Vetter:
> On Wed, Nov 27, 2019 at 01:31:25PM +0100, Thomas Zimmermann wrote:
>> Hi Daniel
>>
>> Am 27.11.19 um 11:49 schrieb Daniel Vetter:
>>> On Wed, Nov 27, 2019 at 08:31:09AM +0100, Thomas Zimmermann wrote:
When enabling the CRTC after waking up from a
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 wr
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
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 diff
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 ;
>
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 connector->hdr_si
https://bugzilla.kernel.org/show_bug.cgi?id=205675
Pierre-Eric Pelloux-Prayer (pierre-eric.pelloux-pra...@amd.com) changed:
What|Removed |Added
CC|
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 th
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
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 don
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 ring_
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 = &sti_hdmi_bridge_funcs;
> > drm_bridge_attach(encoder, bridge, NULL);
> >
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
C
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 -EOPNOTSUP
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: Repl
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 = &sti_hdmi_br
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 pla
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 b/drivers/vi
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 b/drivers/gpu/drm/d
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.
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 +-
drivers/gpu/drm/
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 b/drivers/
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 1006
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
---
include/linux/
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 0e0f5bbfc5ef..e362d7da8
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 a/drivers/hid/hid-pic
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 +--
drivers/media/platform/
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 a/drivers/video/
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 +-
drivers/video/fbdev/amba-cl
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
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 verify
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, whic
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: Mihai
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
grabage
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 pi
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 Hu
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 +-
drivers/gpu/drm
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 b/Documentation/
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 support
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.
>>
>> Sig
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 pre
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: linux-arm-ker.
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 th
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, whic
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
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 a/drivers/vi
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 pre
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 h
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 insert
1 - 100 of 125 matches
Mail list logo
