Convert mtk_dpi to a bridge driver with built-in encoder support for
compatibility with existing component drivers.
Signed-off-by: Enric Balletbo i Serra
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 66 +++---
1 file changed, 34 insertions(+), 32 deletions(-)
diff --git a/d
On Mon, May 04, 2020 at 01:17:41PM -0700, Ira Weiny wrote:
> > || * arm: much, much worse. We have several files that pull
> > linux/highmem.h:
> > || arch/arm/mm/cache-feroceon-l2.c, arch/arm/mm/cache-xsc3l2.c,
> > || arch/arm/mm/copypage-*.c, arch/arm/mm/dma-mapping.c, arch/arm/mm/flush.c,
> >
Signed-off-by: Konrad Dybcio
---
.../display/panel/asus,z00t-tm5p5-n35596.yaml | 56 +++
1 file changed, 56 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/asus,z00t-tm5p5-n35596.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel
This is really a cosmetic change just to make a bit more readable the
code after convert the driver to drm_bridge. The bridge variable name
will be used by the encoder drm_bridge, and the chained bridge will be
named next_bridge.
Signed-off-by: Enric Balletbo i Serra
---
drivers/gpu/drm/mediate
The mtk-dpi driver still uses the drm_encoder API which is now somehow
deprecated. We started to move all the Mediatek drivers to the drm_bridge API,
like we did for the mtk-dsi driver [1], this is another small step to be able to
fully convert the DRM Mediatek drivers to the drm_bridge API. A dumm
Hi Nikolaus,
Le lun. 4 mai 2020 à 8:35, H. Nikolaus Schaller a
écrit :
so that the driver can load by matching the device tree
if compiled as module.
Cc: sta...@vger.kernel.org # v5.3+
Fixes: 90b86fcc47b4 ("DRM: Add KMS driver for the Ingenic JZ47xx
SoCs")
Signed-off-by: H. Nikolaus Schall
On 5/4/2020 2:29 AM, Álvaro Fernández Rojas wrote:
> The current code checks that the whole OOB area is erased.
> This is a problem when JFFS2 cleanmarkers are added to the OOB, since it will
> fail due to the usable OOB bytes not being 0xff.
> Correct this by only checking that the ECC aren't 0x
This function does not need to return an error so make it return void.
This fixes the following coccicheck warning:
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c:178:5-8: Unneeded
variable: "ret". Return "0" on line 193
Signed-off-by: Jason Yan
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
This adds support for TMP5P5 NT35596 1080x1920 video
mode panel that can be found on some Asus Zenfone 2
Laser (Z00T) devices.
This panel seems to only be found in this device
and we have no straightforward way of actually
getting the correct model number, as no schematics
are released publicly.
Fix the following coccicheck warning:
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:1574:5-8: Unneeded
variable: "ret". Return "0" on line 1586
Signed-off-by: Jason Yan
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
On 04/05/2020 22:06, Sam Ravnborg wrote:
> Hi Lubomir.
>
> Drivers looks good. I look forward to the day we have moved
> connector stuff to the displaydriver - this will simplify this driver
> even more.
>
> One Q in the following.
>
> Sam
>
> On Fri, Apr 24, 2020 at 11:35:39PM +0200, Lub
On 24/04/2020 23:35, Lubomir Rintel wrote:
> Hi,
>
> chained to this message is another spin of a driver for CH7033.
>
> Compared to the previous submission, the integration with device
> component framework and creation of an encoder on component bind has
> been removed. This means that until t
Hi Douglas,
Thank you for the patch.
On Mon, May 04, 2020 at 09:36:31PM -0700, Douglas Anderson wrote:
> The ti-sn65dsi86 MIPI DSI to eDP bridge chip supports arbitrary
> remapping of eDP lanes and also polarity inversion. Both of these
> features have been described in the device tree bindings
On Wed, Apr 8, 2020 at 9:15 PM Arnd Bergmann wrote:
> I ran into a randconfig link error with debugfs disabled:
>
> arm-linux-gnueabi-ld:
> drivers/gpu/drm/msm/msm_gpu.o: in function `should_dump':
> msm_gpu.c:(.text+0x1cc): undefined reference to `rd_full'
>
> Change the helper to only look at
On 28/04/2020 11:21, Neil Armstrong wrote:
> The Amlogic S805X/Y uses the same die as the S905X, but with more
> limited graphics capabilities.
>
> This adds a soc version detection adding specific limitations on the HDMI
> mode selections.
>
> Here, we limit to HDMI 1.3a max HDMI PHY clock frequ
Dear All,
During the Exynos DRM GEM rework and fixing the issues in the
drm_prime_sg_to_page_addr_arrays() function [1] I've noticed that most
drivers in DRM framework incorrectly use nents and orig_nents entries of
the struct sg_table.
In case of the most DMA-mapping implementations exchanging
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
sg_table->nent
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
sg_table->nent
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
sg_table->nent
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
sg_table->nent
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
sg_table->nent
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
sg_table->nent
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
sg_table->nent
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
sg_table->nent
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
sg_table->nent
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
sg_table->nent
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
sg_table->nent
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
sg_table->nent
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
sg_table->nent
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
sg_table->nent
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
sg_table->nent
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
sg_table->nent
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
sg_table->nent
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
sg_table->nent
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
sg_table->nent
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in
struct sg_table is a common structure used for describing a memory
buffer. It consists of a scatterlist with memory pages and DMA addresses
(sgl entry), as well as the number of scatterlist entries: CPU pages
(orig_nents entry) and DMA pages (nents entry).
It turned out that it was a common mistak
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
sg_table->nent
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
sg_table->nent
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
sg_table->nent
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
sg_table->nent
Refocusing on where I think we still have a bit a disconnnect.
On Mon, May 04, 2020 at 03:22:28PM +0300, Pekka Paalanen wrote:
> On Mon, 4 May 2020 13:00:02 +0200
> Daniel Vetter wrote:
> > On Mon, May 4, 2020 at 11:49 AM Pekka Paalanen wrote:
> > > On Thu, 30 Apr 2020 15:53:23 +0200
> > > Danie
On Tue, May 05, 2020 at 07:55:00AM +0200, Michał Orzeł wrote:
>
>
> On 04.05.2020 13:53, Daniel Vetter wrote:
> > On Fri, May 01, 2020 at 05:49:33PM +0200, Michał Orzeł wrote:
> >>
> >>
> >> On 30.04.2020 20:30, Daniel Vetter wrote:
> >>> On Thu, Apr 30, 2020 at 5:38 PM Sean Paul wrote:
>
>
On Thu, Apr 30, 2020 at 05:33:46PM +0200, Emmanuel Vadot wrote:
> Source file was dual licenced but the header was omitted, fix that.
> Contributors for this file are:
> Daniel Vetter
> Matt Roper
> Maxime Ripard
> Noralf Trønnes
> Thomas Zimmermann
>
> Acked-by: Noralf Trønnes
> Acked-by: M
Hi Marek,
On Tue, May 5, 2020 at 10:48 AM Marek Szyprowski
wrote:
> The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
> numer of the created entries in the DMA address space. However the
> subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
> called with
Done in preparation of embedding the DRM device in struct mga_device.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_main.c | 21 +++--
drivers/gpu/drm/mgag200/mgag200_mode.c | 17 +
2 files changed, 20 insertions(+), 18 deletions(-)
diff --
Mgag200 used dev_private to look up struct mga_device for instances
of struct drm_device. Use of dev_private is deprecated, so hide it in
the macro to_mga_device().
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_cursor.c | 4 ++--
drivers/gpu/drm/mgag200/mgag200_drv.c|
Done to simplify initialization code before embedding the DRM device
instance in struct mga_device.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_main.c | 67 ++
1 file changed, 26 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/mgag200
After receiving reviews on the conversion of mgag200 to atomic mode
setting, I thought it would make sense to embed the DRM device in
struct mga_device first. Several comments in the atomic-conversion
reviews refer to that.
Patches 1 to 3 do some cleanups and preparation work. Patch 4 changes
the
Device initialization is now done in mgag200_device_init(). Specifically,
the function allocates the DRM device and sets up the respective fields
in struct mga_device.
A call to mgag200_device_fini() finalizes struct mga_device.
The old function mgag200_driver_load() and mgag200_driver_unload() w
As it is best practice now, the DRM device instance is now embedded in
struct mga_device. All references to dev_private have been removed.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_cursor.c | 6 +++---
drivers/gpu/drm/mgag200/mgag200_drv.c| 2 +-
drivers/gpu/drm/
Hello all
I am currently working on DRM/KMS driver for Fresco Logic FL2000 USB display
controller [1]. I have already implemented a POC driver [2] which is working for
me, although there are still plenty of things to improve or fix, of course.
So far I have one thing that I somehow cannot find in
Hi Christoph,
On 05.05.2020 12:22, Christoph Hellwig wrote:
>> +static inline int dma_map_sgtable_attrs(struct device *dev,
>> +struct sg_table *sgt, enum dma_data_direction dir, unsigned long attrs)
> Two tab indents for parameter continuation, please.
>
> Can we also skip the separate _attrs
Hi Christoph,
On 05.05.2020 12:15, Christoph Hellwig wrote:
>> -for_each_sg_page(st->sgl, &sg_iter, st->nents, 0)
>> +for_each_sg_page(st->sgl, &sg_iter, st->orig_nents, 0)
> Would it make sense to also add a for_each_sgtable_page helper that
> hides the use of orig_nents?
Hi, Enric:
Enric Balletbo i Serra 於 2020年5月4日 週一 下午10:14寫道：
>
> This is really a cosmetic change just to make a bit more readable the
> code after convert the driver to drm_bridge. The bridge variable name
> will be used by the encoder drm_bridge, and the chained bridge will be
> named next_bridg
https://bugzilla.kernel.org/show_bug.cgi?id=207581
Bug ID: 207581
Summary: [amdgpu] Framebuffer no image CARRIZO and STONEY
Product: Drivers
Version: 2.5
Kernel Version: 5.4.27
Hardware: All
OS: Linux
Tree: Ma
https://bugzilla.kernel.org/show_bug.cgi?id=207581
--- Comment #1 from Jan Burgmeier (jan.burgme...@unicon-software.com) ---
Created attachment 288909
--> https://bugzilla.kernel.org/attachment.cgi?id=288909&action=edit
lspci from lenovo 14w
--
You are receiving this mail because:
You are watc
https://bugzilla.kernel.org/show_bug.cgi?id=207581
--- Comment #2 from Jan Burgmeier (jan.burgme...@unicon-software.com) ---
Created attachment 288911
--> https://bugzilla.kernel.org/attachment.cgi?id=288911&action=edit
lspci from IGEL UD7
--
You are receiving this mail because:
You are watchi
https://bugzilla.kernel.org/show_bug.cgi?id=207581
--- Comment #3 from Jan Burgmeier (jan.burgme...@unicon-software.com) ---
Created attachment 288913
--> https://bugzilla.kernel.org/attachment.cgi?id=288913&action=edit
git bisect log
--
You are receiving this mail because:
You are watching th
Hi, Enric:
Enric Balletbo i Serra 於 2020年5月4日 週一 下午10:14寫道：
>
> Convert mtk_dpi to a bridge driver with built-in encoder support for
> compatibility with existing component drivers.
Reviewed-by: Chun-Kuang Hu
>
> Signed-off-by: Enric Balletbo i Serra
> ---
>
> drivers/gpu/drm/mediatek/mtk_dp
Hi, Enric:
Enric Balletbo i Serra 於 2020年5月4日 週一 下午10:14寫道：
>
> The mtk_dpi driver uses an empty implementation for its encoder. Replace
> the code with the generic simple encoder.
Reviewed-by: Chun-Kuang Hu
>
> Signed-off-by: Enric Balletbo i Serra
> ---
>
> drivers/gpu/drm/mediatek/mtk_dpi
On Mon, 4 May 2020 22:01:00 +0200, Konrad Dybcio wrote:
> Signed-off-by: Konrad Dybcio
> ---
> .../display/panel/asus,z00t-tm5p5-n35596.yaml | 56 +++
> 1 file changed, 56 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/asus,z00t-tm5p5-n3559
https://bugzilla.kernel.org/show_bug.cgi?id=207581
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
On Tue, May 05, 2020 at 11:56:45AM +0200, Thomas Zimmermann wrote:
> Mgag200 used dev_private to look up struct mga_device for instances
> of struct drm_device. Use of dev_private is deprecated, so hide it in
> the macro to_mga_device().
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel V
After the structure was padded to 1024 bytes, it is no longer
suitable for being a local variable, as the function surpasses
the warning limit for 32-bit architectures:
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:587:5: error: stack frame size of 1072
bytes in function 'amdgpu_ras_feature_enable' [-W
With the kcsan changes, __read_once_size() is not inlined, but
clang can decide to emit a version that hardcodes the address, which
in turn triggers a warning for dss_conv_list being __initdata but
__read_once_size() not being __init:
WARNING: modpost: vmlinux.o(.text+0x6e4d7a): Section mismatch i
On Tue, May 05, 2020 at 11:56:46AM +0200, Thomas Zimmermann wrote:
> Done to simplify initialization code before embedding the DRM device
> instance in struct mga_device.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/mgag200/mgag200_main.c | 67 ++
Am 05.05.20 um 16:01 schrieb Arnd Bergmann:
After the structure was padded to 1024 bytes, it is no longer
suitable for being a local variable, as the function surpasses
the warning limit for 32-bit architectures:
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:587:5: error: stack frame size of 1072
byt
On Tue, May 05, 2020 at 11:56:47AM +0200, Thomas Zimmermann wrote:
> Done in preparation of embedding the DRM device in struct mga_device.
>
> Signed-off-by: Thomas Zimmermann
Not exactly sure what the goal is, since mga_vga_init still uses
drm_device and not the mdev struct. *shrug*
Reviewed-b
On Tue, May 05, 2020 at 11:56:48AM +0200, Thomas Zimmermann wrote:
> Device initialization is now done in mgag200_device_init(). Specifically,
> the function allocates the DRM device and sets up the respective fields
> in struct mga_device.
>
> A call to mgag200_device_fini() finalizes struct mga_
Multiplying 10 by four overruns a 'long' variable, as clang
points out:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:4160:53: error: overflow in
expression; result is -294967296 with type 'long' [-Werror,-Winteger-overflow]
expires = ktime_get_mono_fast_ns() + NSEC_PER_SEC *
On Mon, 4 May 2020 at 13:07, Thomas Zimmermann wrote:
>
> Hi Emil
>
> Am 01.05.20 um 15:20 schrieb Emil Velikov:
> > Hi Thomas,
> >
> > Couple of fly-by ideas/suggestions.
> >
> > On Thu, 30 Apr 2020 at 10:13, Thomas Zimmermann wrote:
> >>
> >> Suspending failed because there's no mode if the CRT
Am 05.05.20 um 16:15 schrieb Arnd Bergmann:
Multiplying 10 by four overruns a 'long' variable, as clang
points out:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:4160:53: error: overflow in
expression; result is -294967296 with type 'long' [-Werror,-Winteger-overflow]
expi
On Tue, May 05, 2020 at 11:56:49AM +0200, Thomas Zimmermann wrote:
> As it is best practice now, the DRM device instance is now embedded in
> struct mga_device. All references to dev_private have been removed.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/mgag200/mgag200_cursor.c
Clang does not appear to care, and instead prints a warning:
clang: warning: argument unused during compilation: '-mhard-float'
[-Wunused-command-line-argument]
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/display/dc/calcs/Makefile | 5 +++--
drivers/gpu/drm/amd/display/dc/dcn20/Makefi
https://bugzilla.kernel.org/show_bug.cgi?id=207581
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
Attachment #288915|0 |1
is obsole
On Thu, 9 Apr 2020 at 15:46, Sam Ravnborg wrote:
>
> Hi Emil.
>
> Thanks for your feedback!
>
> On Thu, Apr 09, 2020 at 03:13:28PM +0100, Emil Velikov wrote:
> > On Thu, 9 Apr 2020 at 12:53, Sam Ravnborg wrote:
> > >
> > > The samsung-s6e63j0x03 had a local way to handle backlight.
> > >
> > > Up
On Sat, May 2, 2020 at 4:35 AM Nathan Chancellor
wrote:
>
> When building with Clang:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:4160:53: warning: overflow in
> expression; result is -294967296 with type 'long' [-Winteger-overflow]
> expires = ktime_get_mono_fast_ns() + NSEC_PE
On Tue, May 5, 2020 at 2:59 AM ChenTao wrote:
>
> Fixes warning because pipe is unsigned long and can never be negtative
>
> vers/gpu/drm/radeon/radeon_kms.c:831:11: warning:
> comparison of unsigned expression < 0 is always false [-Wtype-limits]
> if (pipe < 0 || pipe >= rdev->num_crtc) {
> dri
On Tue, May 5, 2020 at 4:12 PM 'Marco Elver' via Clang Built Linux
wrote:
> On Tue, 5 May 2020 at 16:04, Arnd Bergmann wrote:
> > With the kcsan changes, __read_once_size() is not inlined, but
> > clang can decide to emit a version that hardcodes the address, which
> > in turn triggers a warning
From: Emil Velikov
The function vop_cfg_done() is a simple VOP_REG_SET(). As such it should
be done under a reg_lock. A quick look through the driver shows that all
other instances (apart from driver init) have the lock. Do the same here
Cc: Sandy Huang
Cc: Heiko Stübner
Signed-off-by: Emil Ve
On Tue, May 5, 2020 at 10:07 AM Christian König
wrote:
>
> Am 05.05.20 um 16:01 schrieb Arnd Bergmann:
> > After the structure was padded to 1024 bytes, it is no longer
> > suitable for being a local variable, as the function surpasses
> > the warning limit for 32-bit architectures:
> >
> > driver
On Wed, 29 Apr 2020 11:15:15 +0530, Harigovindan P wrote:
> Documenting compatible string vendor "visionox" in vendor-prefix yaml file.
>
> Signed-off-by: Harigovindan P
> ---
> Changes in v11:
> - Added compatible string in vendor-prefix yaml file
>
> Changes in v12:
> - Fixed the s
On Fri, Apr 24, 2020 at 10:34:04PM +0200, H. Nikolaus Schaller wrote:
> The Imagination PVR/SGX GPU is part of several SoC from
> multiple vendors, e.g. TI OMAP, Ingenic JZ4780, Intel Poulsbo,
> Allwinner A83 and others.
>
> With this binding, we describe how the SGX processor is
> interfaced to t
From: Emil Velikov
The helper uses the MIPI_DCS_SET_TEAR_SCANLINE, although it's currently
using the generic write. This does not look right.
Perhaps some platforms don't distinguish between the two writers?
Cc: Robert Chiras
Cc: Vinay Simha BN
Cc: Jani Nikula
Cc: Thierry Reding
Fixes: e839
Currently the function heap allocates when we have any payload. Where in
many case the payload is 1 byte - ouch.
>From casual observation, vast majority of the payloads are smaller than
8 bytes - so use a stack array tx[8] to avoid the senseless kmalloc and
kfree dance.
Cc: Jani Nikula
Cc: Thier
From: Emil Velikov
A few of the new panels create a local macro wrapping around
mipi_dsi_dcs_write. At the same time, they don't really care about the
command/payload split.
mipi_dsi_dcs_write does a kmalloc/memcpy/kfree for payload > 7 bytes.
kmalloc - avoid that all together by using the _buff
Hi Thomas.
On Tue, May 05, 2020 at 11:56:44AM +0200, Thomas Zimmermann wrote:
> After receiving reviews on the conversion of mgag200 to atomic mode
> setting, I thought it would make sense to embed the DRM device in
> struct mga_device first. Several comments in the atomic-conversion
> reviews ref
Hi Thomas.
On Tue, May 05, 2020 at 11:56:45AM +0200, Thomas Zimmermann wrote:
> Mgag200 used dev_private to look up struct mga_device for instances
> of struct drm_device. Use of dev_private is deprecated, so hide it in
> the macro to_mga_device().
>
> Signed-off-by: Thomas Zimmermann
Reviewed-b
On Tue, May 05, 2020 at 11:56:46AM +0200, Thomas Zimmermann wrote:
> Done to simplify initialization code before embedding the DRM device
> instance in struct mga_device.
And replace DRM_ERROR with drm_err
And replace r with ret.
I could not follow all the code re-shuffeling, but I expect it to be
Hi Thomas.
On Tue, May 05, 2020 at 11:56:47AM +0200, Thomas Zimmermann wrote:
> Done in preparation of embedding the DRM device in struct mga_device.
>
> Signed-off-by: Thomas Zimmermann
Trivial, one nit you can fix while applying, or ignore.
Reviewed-by: Sam Ravnborg
> ---
> drivers/gpu/drm/
Hi Thomas.
On Tue, May 05, 2020 at 11:56:48AM +0200, Thomas Zimmermann wrote:
> Device initialization is now done in mgag200_device_init(). Specifically,
> the function allocates the DRM device and sets up the respective fields
> in struct mga_device.
>
> A call to mgag200_device_fini() finalizes
Date: Mon, 4 May 2020 12:41:55 +0100
Subject: [PATCH 01/16] dt-bindings: mali-midgard: Allow dma-coherent
Add the boolean dma-coherent property to the list of allowed properties,
since some boards (Arm Juno) integrate the GPU this way.
Signed-off-by: Andre Przywara
---
Documentation/devicetree/
Mario or Nick any thoughts?
Alex
On Mon, May 4, 2020 at 1:35 PM Matt Coffin wrote:
>
> Hey guys,
>
> This is still an issue for me, and I'm still having to run a patch to
> revert this as of 5.7-rc4. To avoid breaking a lot of people's Navi
> setups in 5.7, is there any news on this? Has anyone
Can you file a full bug report on the gitlab tracker?
FreeSync is still working on my Navi setups with this patch applied, and
this patch is essentially just a revert of another patch already (where
FreeSync worked before).
I can understand the v2 of this series causing issues, but the v1
sh
Hi,
On Tue, May 5, 2020 at 1:24 AM Laurent Pinchart
wrote:
>
> Hi Douglas,
>
> Thank you for the patch.
>
> On Mon, May 04, 2020 at 09:36:31PM -0700, Douglas Anderson wrote:
> > The ti-sn65dsi86 MIPI DSI to eDP bridge chip supports arbitrary
> > remapping of eDP lanes and also polarity inversion.
On Wed, Apr 29, 2020 at 12:20 PM Ramalingam C wrote:
>
> On 2020-04-29 at 10:46:29 -0400, Sean Paul wrote:
> > On Wed, Apr 29, 2020 at 10:22 AM Ramalingam C
> > wrote:
> > >
> > > On 2020-04-29 at 09:58:16 -0400, Sean Paul wrote:
> > > > On Wed, Apr 29, 2020 at 9:50 AM Ramalingam C
> > > > wro
Sure, I'll file one after work today.
To clarify though, FreeSync still "works" as in the monitor refresh rate
is updating, but it constantly bounces between the maximum and minimum
freesync refresh rates, causing it to look VERY stuttery.
Thanks for the attention, I'll file the but tonight. If y
On 2020-05-05 5:51 pm, Andre Przywara wrote:
Date: Mon, 4 May 2020 12:41:55 +0100
Subject: [PATCH 01/16] dt-bindings: mali-midgard: Allow dma-coherent
Add the boolean dma-coherent property to the list of allowed properties,
since some boards (Arm Juno) integrate the GPU this way.
The same comm
From: Jason Yan
Date: Tue, 5 May 2020 15:46:08 +0800
> Fix the following coccicheck warning:
>
> drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c:1991:5-46: WARNING:
> Comparison to bool
> drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c:1993:10-54: WARNING:
> Comparison to bool
> drivers/net/
1 - 100 of 118 matches
Mail list logo
