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
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
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
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
---
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
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
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
Small Page NAND uses byte 6 for BBI and Large Page NAND uses first 2 bytes.
Signed-off-by: Álvaro Fernández Rojas
---
drivers/mtd/nand/raw/brcmnand/brcmnand.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
Quoting Douglas Anderson (2020-05-04 21:36:31)
> 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 for the
> device since the beginning but were never
From: Christoph Hellwig
> Sent: 04 May 2020 17:03
>
> On Sun, May 03, 2020 at 09:20:19PM +0100, Chris Wilson wrote:
> > > Err, why does i915 implements its own uncached memcpy instead of relying
> > > on core functionality to start with?
> >
> > What is this core functionality that provides
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,
On 5/4/20 12:38 PM, Konrad Dybcio wrote:
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index a1723c1b5fbf8..3aa57a927c4bd 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -18,6 +18,16 @@ config DRM_PANEL_ARM_VERSATILE
>
> On May 4, 2020, at 8:39 AM, Thomas Zimmermann wrote:
>
> Hi John
>
> Am 30.04.20 um 02:11 schrieb John Donnelly:
>> On 4/29/20 9:32 AM, Thomas Zimmermann wrote:
>>> This patchset converts mgag200 to atomic modesetting. It uses simple
>>> KMS helpers and SHMEM.
>>>
>>> Patches 1 to 4
changes since v2:
- fix Kconfig indentation
changes since v1:
- make `backlight_properties props` constant
- a couple of line breaks
- change name and compatible to reflect ASUS being the vendor
- remove a redundant TODO
Konrad Dybcio (2):
drivers: drm: panel: Add ASUS TM5P5 NT35596 panel
Hello there,
linux-5.7-rc4/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c:1393:63:
style: Unsigned expression 'j' can't be negative so it is unnecessary to test
it. [unsignedPositive]
Source code is
for (closest_clk_lvl = 0, j = dcn2_1_soc.num_states - 1; j >= 0;
j--) {
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 0xff.
Signed-off-by: Álvaro Fernández Rojas
---
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.
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) {
drivers/gpu/drm/radeon/radeon_kms.c:857:11: warning:
Maximum allowed bandwidth has no dependency on the type
of panel used. Hence, cleanup the code to use max_bw_high
as the threshold value for bandwidth checks.
Update the maximum allowed bandwidth as 6.8Gbps for
SC7180 target.
Signed-off-by: Krishna Manikandan
---
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
The current code generates 8 oob sections:
S1 1-5
ECC 6-8
S2 9-15
S3 16-21
ECC 22-24
S4 25-31
S5 32-37
ECC 38-40
S6 41-47
S7 48-53
ECC 54-56
S8 57-63
Change it by merging continuous sections:
S1 1-5
ECC 6-8
S2 9-21
ECC
Hi Maxime, as always, thanks for the series!
Some extra context, and comments below.
On Fri, 2020-04-24 at 17:34 +0200, Maxime Ripard wrote:
> The RaspberryPi4 firmware actually exposes more clocks than are currently
> handled by the driver and we will need to change some of them directly
> based
changes since v1:
- make `backlight_properties props` constant
- a couple of line breaks
- change name and compatible to reflect ASUS being the vendor
- remove a redundant TODO
Konrad Dybcio (2):
drivers: drm: panel: Add ASUS TM5P5 NT35596 panel driver
dt-bindings: display: Document ASUS Z00T
The current code generates 8 oob sections:
S1 1-5
ECC 6-8
S2 9-15
S3 16-21
ECC 22-24
S4 25-31
S5 32-37
ECC 38-40
S6 41-47
S7 48-53
ECC 54-56
S8 57-63
Change it by merging continuous sections:
S1 1-5
ECC 6-8
S2 9-21
ECC
Fix the following coccicheck warning:
drivers/gpu/drm/zte/zx_vga.c:158:2-3: Unneeded semicolon
drivers/gpu/drm/zte/zx_vga.c:171:2-3: Unneeded semicolon
drivers/gpu/drm/zte/zx_vga.c:179:2-3: Unneeded semicolon
Signed-off-by: Jason Yan
---
drivers/gpu/drm/zte/zx_vga.c | 6 +++---
1 file changed,
Quoting Douglas Anderson (2020-05-04 21:32:29)
> If the rate in our table is _equal_ to the rate we want then it's OK
> to pick it. It doesn't need to be greater than the one we want.
>
> Fixes: a095f15c00e2 ("drm/bridge: add support for sn65dsi86 bridge driver")
> Signed-off-by: Douglas
On Tue, Apr 28, 2020 at 11:50:51PM +0200, Arnd Bergmann wrote:
> Older compilers warn about initializers with incorrect curly
> braces:
>
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c: In function
> 'sun6i_dsi_encoder_enable':
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:720:8: error: missing braces
No one uses the return value of this function, so make it return void.
This fixes the following coccicheck warning:
drivers/gpu/drm/vc4/vc4_gem.c:1029:5-8: Unneeded variable: "ret". Return
"0" on line 1044
Signed-off-by: Jason Yan
---
drivers/gpu/drm/vc4/vc4_drv.h | 6 +++---
The mtk_dpi driver uses an empty implementation for its encoder. Replace
the code with the generic simple encoder.
Signed-off-by: Enric Balletbo i Serra
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git
I just sent out a v3. Hope it solves the issue.
Konrad
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Fix the following coccicheck warning:
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h:307:2-3: Unneeded
semicolon
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c:583:2-3: Unneeded
semicolon
Signed-off-by: Jason Yan
---
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c | 2 +-
…
> The proper pointer to be passed as argument is ce.
>
> This bug was detected with the help of Coccinelle.
My software development attention was caught also by your commit message.
…
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -1325,7 +1325,7 @@ static int
First 2 bytes are used in large-page nand.
Signed-off-by: Álvaro Fernández Rojas
---
v2: extend original comment
drivers/mtd/nand/raw/brcmnand/brcmnand.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
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
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:
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
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
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
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
> > >
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
>
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
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()
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 +-
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
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
> ---
>
>
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
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
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 +++--
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
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
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
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
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
> ---
>
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
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
> > > >
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()
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
---
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
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
>
On Thu, 23 Apr 2020 21:03:36 +0530, Kiran Gunda wrote:
> Add WLED5 specific bindings.
>
> Signed-off-by: Kiran Gunda
> Signed-off-by: Subbaraman Narayanamurthy
> Acked-by: Daniel Thompson
> ---
> .../bindings/leds/backlight/qcom-wled.yaml | 59
> --
> 1 file
Hi Artem.
On Tue, May 05, 2020 at 01:24:16PM +0300, Artem Mygaiev wrote:
> 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
On Thu, 23 Apr 2020 21:03:34 +0530, Kiran Gunda wrote:
> Convert the qcom-wled bindings from .txt to .yaml format.
> Also replace PM8941 to WLED3 and PMI8998 to WLED4.
>
> Signed-off-by: Kiran Gunda
> Signed-off-by: Subbaraman Narayanamurthy
> Acked-by: Daniel Thompson
> ---
>
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
Hi
On Mon, May 4, 2020 at 10:44 PM Stephen Boyd wrote:
>
> Quoting Douglas Anderson (2020-05-04 21:36:31)
> > 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
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
> ---
>
>
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() +
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
1 - 100 of 143 matches
Mail list logo
