Hi
Am 18.08.20 um 22:28 schrieb Randy Dunlap:
> From: Randy Dunlap
>
> sparse complains about having 2 "__iomem" attributes on the same line
> where only one is needed since the first one applies to everything
> up to the ending ';'.
> However, to make it clear(er) that both of these pointers ar
> -Original Message-
> From: Intel-gfx On Behalf Of Pankaj
> Bharadiya
> Sent: Monday, August 3, 2020 10:00 AM
> To: jani.nik...@linux.intel.com; dan...@ffwll.ch;
> intel-...@lists.freedesktop.org;
> dri-devel@lists.freedesktop.org; ville.syrj...@linux.intel.com;
> dani...@collabora.co
> -Original Message-
> From: dri-devel On Behalf Of Pankaj
> Bharadiya
> Sent: Monday, August 3, 2020 10:00 AM
> To: jani.nik...@linux.intel.com; dan...@ffwll.ch;
> intel-...@lists.freedesktop.org;
> dri-devel@lists.freedesktop.org; ville.syrj...@linux.intel.com;
> dani...@collabora.co
> -Original Message-
> From: dri-devel On Behalf Of Pankaj
> Bharadiya
> Sent: Monday, August 3, 2020 10:00 AM
> To: jani.nik...@linux.intel.com; dan...@ffwll.ch;
> intel-...@lists.freedesktop.org;
> dri-devel@lists.freedesktop.org; ville.syrj...@linux.intel.com;
> dani...@collabora.co
> -Original Message-
> From: Intel-gfx On Behalf Of Pankaj
> Bharadiya
> Sent: Monday, August 3, 2020 10:00 AM
> To: jani.nik...@linux.intel.com; dan...@ffwll.ch;
> intel-...@lists.freedesktop.org;
> dri-devel@lists.freedesktop.org; ville.syrj...@linux.intel.com;
> dani...@collabora.co
> -Original Message-
> From: Laxminarayan Bharadiya, Pankaj
>
> Sent: Monday, August 3, 2020 10:00 AM
> To: jani.nik...@linux.intel.com; dan...@ffwll.ch;
> intel-...@lists.freedesktop.org;
> dri-devel@lists.freedesktop.org; ville.syrj...@linux.intel.com;
> dani...@collabora.com; Lattan
lwahn
Reviewed-by: Christian König
---
applies cleanly on current master and next-20200819
Alex, Christian, please pick this minor non-urgent cleanup patch.
Alex is usually the one picking those up. If he misses something feel
free to ping us once more.
Thanks,
Christian.
Dennis, Jerry,
On 2020-07-22 7:12 p.m., Alex Deucher wrote:
> On Wed, Jul 22, 2020 at 10:25 AM Michel Dänzer wrote:
>> On 2020-07-22 3:10 p.m., Kazlauskas, Nicholas wrote:
>>> On 2020-07-22 8:51 a.m., Daniel Vetter wrote:
On Wed, Jul 22, 2020 at 2:38 PM Michel Dänzer wrote:
>
> From: Michel Dänzer
Hello,
First of all, I'd like to thank everyone for the great work
on ingenic-drm. The driver is in very good shape
and a pleasure to work with.
Yesterday, I checked out branch "paulb-jz4780-ci20-hdmi-5.8-rc5",
from git.goldelico.com/letux-kernel.git, rebased it on v5.9-rc1,
and then run weston o
On Wed, Aug 19, 2020 at 11:04:56AM +0800, Dinghao Liu wrote:
> When of_property_read_u32_array() returns an error code, a
> pairing refcount decrement is needed to keep np's refcount
> balanced.
>
> Fixes: f705806c9f355 ("backlight: Add support Skyworks SKY81452 backlight
> driver")
> Signed-off-
From: Liwei Cai
The use of synchronization mechanisms to deal with the display of
buffer, to solve the problem of display tearing.
Signed-off-by: Wanchun Zheng
Signed-off-by: Liwei Cai
Signed-off-by: John Stultz
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/gpu/dw_drm_ds
From: John Stultz
Update the driver to work with v4.9 kernels
Signed-off-by: John Stultz
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/gpu/dw_drm_dsi.c | 4 +-
drivers/staging/hikey9xx/gpu/kirin_dpe_reg.h | 1 +
drivers/staging/hikey9xx/gpu/kirin_drm_drv.c | 3 +-
From: Xiubin Zhang
Add some debug prints on adv7535 and kirin_drm_drv.
Signed-off-by: Xiubin Zhang
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/gpu/hdmi/adv7535.c | 40 ++--
drivers/staging/hikey9xx/gpu/kirin_drm_drv.c | 2 +-
2 files changed, 37 inserti
Currently, the method is empty. However, looking at the driver,
it sounds it shouldn't be hard to implement it.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/hik
The logich which sets the MIPI parameters is currently wrong:
it is using a value stored at cur_client, with actually points
to the active location, and not to the one that it is about
to be initialized.
The entire logic sounds buggy, but for now let's just keep
following it, by adding an extra va
From: Xiubin Zhang
Add HDMI/DSS power on&off in the SR flow.
Signed-off-by: Xiubin Zhang
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/gpu/Makefile | 1 -
drivers/staging/hikey9xx/gpu/dw_drm_dsi.c | 10 +--
.../staging/hikey9xx/gpu/kirin970_dpe_reg.h | 9 ++
From: Xiubin Zhang
Add suspend and resume interface to solve SR Cannot Display Problems.
Signed-off-by: Xiubin Zhang
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/gpu/dw_drm_dsi.c | 32 +++
drivers/staging/hikey9xx/gpu/hdmi/adv7535.c | 14 +-
.../staging/hikey9xx/g
This function has a too generic name to export it as a
symbol. Also, we should likely use some other macro instead.
So, for now, just copy it into the Kirin9xx dsi module, in order
for the driver to build.
Signed-off-by: Mauro Carvalho Chehab
---
.../staging/hikey9xx/gpu/kirin9xx_dw_drm_dsi.c
This is part of support for a panel display. Those don't come
with the Hikey 960 or 970 boards. As I don't have any of
those for tests, and we didn't port another required driver
for this to work, for now, let's drop it.
This patch can be reversed later, if one would be adding
support for it.
Sig
We don't need to implement legacy fbdev support. Just use
the FB emulation instead.
Signed-off-by: Mauro Carvalho Chehab
---
.../staging/hikey9xx/gpu/kirin9xx_drm_drv.c | 9 +-
.../staging/hikey9xx/gpu/kirin9xx_drm_drv.h | 2 -
drivers/staging/hikey9xx/gpu/kirin9xx_fb.c| 94
dr
The logic there is more complex than it needs. It also places
the device with a wrong setting if the flags are missed.
This currently happens on Kirin970 for HDMI, as there's a bug
at the part of the driver which selects between PANEL or
OUTPUT at encoder init code.
Signed-off-by: Mauro Carvalho
There are some #ifdefs there for non-existing CONFIG_ options
(nor even at the downstream code).
Let's get rid of those. It can be re-added later if ever needed.
Signed-off-by: Mauro Carvalho Chehab
---
.../hikey9xx/gpu/kirin9xx_drm_dpe_utils.c | 36 ---
.../hikey9xx/gpu/kir
From: Liwei Cai
There is an error at wait for vactive end flags, waiting
vactive flag in 1ms maybe too rough, but it's not good to
control the waiting grain size, there is no way to get the
waiting unit, so the interrupt mechanism is the best way to
solve this problem.
Each frame would report ha
Add a description of the bindings used by Kirin 960/970 Display
Serial Interface (DSI) controller and by its Display Engine (DPE).
Signed-off-by: Mauro Carvalho Chehab
---
.../display/hisilicon,hi3660-dpe.yaml | 99 +
.../display/hisilicon,hi3660-dsi.yaml | 102 +
There are some things inside struct dss_hw_ctx that are unused.
Get rid of them.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/gpu/kirin960_dpe_reg.h | 2 --
drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h | 3 ---
drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c | 2 --
3 fil
This is needed for the DRM to work. Ok, right now, this is
enabled on default fastboot logic, but, as soon as we enable
the proper SPMI driver, such code is needed.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h | 4 +---
drivers/staging/hikey9xx/g
call drm_connector_register() when initializing the connector.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/gpu/kirin9xx_dw_drm_dsi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_dw_drm_dsi.c
b/drivers/staging/hikey9xx/gpu/kiri
From: Xiubin Zhang
Adjust pixel clock for compatibility with 10.1 inch special displays.
Signed-off-by: Xiubin Zhang
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/gpu/kirin_drm_dss.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/staging/hikey9xx/gpu/kirin
This is not used anymore on this version, so let's get rid
of them.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/gpu/kirin960_dpe_reg.h | 3 ---
drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h | 3 ---
drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.h | 2 --
3 files changed,
There are several pinctrl settings that are missing at this
DT file.
Also, the entries are out of order.
Add the missing bits, as they'll be required by the DRM driver - and
probably by other drivers not upstreamed yet.
Reorder the entres, adding the missing bits.
Signed-off-by: Mauro Carvalho
Use the same standard as used on other Hisilicon DRM
config vars for kirin9xx.
Signed-off-by: Mauro Carvalho Chehab
---
.../staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.c| 2 +-
.../staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.h| 2 +-
drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c
There were several changes at the upstream kAPIs since
Kernel 4.4. Update the driver for it to build with the
upstream Kernel.
Signed-off-by: Mauro Carvalho Chehab
---
.../staging/hikey9xx/gpu/kirin9xx_drm_drv.c | 28 +++---
.../staging/hikey9xx/gpu/kirin9xx_drm_dss.c | 26 +++---
.../hikey9
The DPE headers define several macros for I/O. Get rid of
them by replacing by the Linux ones.
In the specific case of outp32(), I used this small
coccinelle script to change them to writel():
@ rule1 @
expression addr, val;
@@
-outp32(addr, val)
+writel(va
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/gpu/kirin9xx_dw_drm_dsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_dw_drm_dsi.c
b/drivers/staging/hikey9xx/gpu/kirin9xx_dw_drm_dsi.c
index 09d035038c1a..99be8dfe05e6
There's already a driver with the same namespace
for an older Kirin chipset. Rename this one, in order
to make it clearer that this is the driver for
Kirin 960/970.
Signed-off-by: Mauro Carvalho Chehab
---
.../staging/hikey9xx/gpu/{kirin_dpe_reg.h => kirin9xx_dpe_reg.h} | 0
.../gpu/{kirin_drm_
From: Xiubin Zhang
Modfiy pix_clk and dsi lanes to improve HDMI compatibility for hikey970.
Signed-off-by: Xiubin Zhang
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/gpu/dw_drm_dsi.c | 53 ++-
drivers/staging/hikey9xx/gpu/hdmi/adv7535.c | 9 +-
.../hikey9xx/gp
There are lots of coding style issues on this driver, as
reported by checkpatch.
Address most of them.
Signed-off-by: Mauro Carvalho Chehab
---
.../staging/hikey9xx/gpu/kirin960_dpe_reg.h | 340 +++--
.../staging/hikey9xx/gpu/kirin970_dpe_reg.h | 1199 -
.../hikey9xx/gpu/ki
There are a few typedefs inside this driver. Get rid of them.
Signed-off-by: Mauro Carvalho Chehab
---
.../staging/hikey9xx/gpu/kirin960_dpe_reg.h | 126 +-
.../staging/hikey9xx/gpu/kirin970_dpe_reg.h | 117
.../hikey9xx/gpu/kirin9xx_drm_dpe_utils.c | 4
Those methods belong to crtc fops
Signed-off-by: Mauro Carvalho Chehab
---
.../staging/hikey9xx/gpu/kirin9xx_drm_dss.c | 21 ++-
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c
b/drivers/staging/hikey9xx/gpu/kirin
Place both adv7535 and panel logic at the same routine,
cleaning up things a little bit and fixing the includes.
Signed-off-by: Mauro Carvalho Chehab
---
.../hikey9xx/gpu/kirin9xx_dw_drm_dsi.c| 58 ++-
1 file changed, 31 insertions(+), 27 deletions(-)
diff --git a/driver
Now that everything is in place, add the driver to the
building system.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/Kconfig | 3 ++
drivers/staging/hikey9xx/Makefile | 1 +
drivers/staging/hikey9xx/gpu/Kconfig | 52 ++-
drivers/staging/hi
The includes there reflect a downstream version back on v4.4
times. change them to reflect the current upstream and to
avoid the need of using a -I flag at the Makefile.
Signed-off-by: Mauro Carvalho Chehab
---
...{kirin9xx_dpe_reg.h => kirin960_dpe_reg.h} | 3 +++
.../staging/hikey9xx/gpu/kiri
Do some cleanups at the mode validation code. Right now, there
is a known issue with this driver which makes it to set up
some invalid modes, depending on the display.
We don't know yet what the issue is, so, instead, let's add
a table with the modes which are known to work.
Signed-off-by: Mauro
There are lots of ifdefs checking if the SoC version is
960 or 970. Replace them all by runtime definitions.
With that, the same DRM driver should work with both versions.
The behavior will dynamically change depending on the
OF compatible strings.
Signed-off-by: Mauro Carvalho Chehab
---
driv
From: Xiubin Zhang
Modfiy mipi dsi lanes to improve HDMI compatibility.
Signed-off-by: Xiubin Zhang
Signed-off-by: Liuyao An
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/gpu/dw_drm_dsi.c | 24 ---
drivers/staging/hikey9xx/gpu/hdmi/adv7535.c | 4 ---
Add the needed bits for the DRM driver to work with the
Hikey 970 board.
Signed-off-by: Mauro Carvalho Chehab
---
.../boot/dts/hisilicon/hi3670-hikey970.dts| 52 +++
arch/arm64/boot/dts/hisilicon/hi3670.dtsi | 6 +
.../boot/dts/hisilicon/hikey970-drm.dtsi | 130 ++
Allocate the framebuffer memory via CMA, as otherwise the
drm driver may not work properly with X11.
Part of the changes here were based on a patch originally
authored by:
alik
The original version can be found at:
https://github.com/Bigcountry907/linux/commit/046e29834ef1c523c
- Get rid of a global var meant to store one of its priv
structs;
- Change the name of the driver, in order to not be confused with
the kirin6220;
- Remove some unneeded ifdef;
- use drm_of.h helper.
Signed-off-by: Mauro Carvalho Chehab
---
.../staging/hikey9xx/gpu/kirin9xx_drm_drv.c | 81
At least on current upstream Kernels, forcing an event parse
during init time isn't needed anymore.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c
b/
The I2C buses are not declared at the device tree. As this will
be needed by further patches, add them, keeping all in
disabled state. Per-board settings can override it.
Signed-off-by: Mauro Carvalho Chehab
---
arch/arm64/boot/dts/hisilicon/hi3670.dtsi | 71 +++
1 file chang
The OOT had a fork of adv7535 with some changes for it to
work with a failing EDID retrival I/O.
Get rid of it, as we'll be using the upstream driver.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/gpu/hdmi/adv7535.c | 1678 -
drivers/staging/hikey9xx/gpu/hd
Those aren't needed anymore.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/gpu/kirin960_dpe_reg.h | 1 -
drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h | 1 -
drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.h | 2 --
3 files changed, 4 deletions(-)
diff --git a/drivers/stagin
Add a device tree for the HiSilicon 6421v600 SPMI PMIC, used
on HiKey970 board.
As we now have support for it, change the fixed regulators
used by the SD I/O to use the proper LDO supplies.
Signed-off-by: Mauro Carvalho Chehab
---
.../boot/dts/hisilicon/hi3670-hikey970.dts| 22 +-
.../boot
This patch series port the out-of-tree driver for Hikey 970 (which
should also support Hikey 960) from the official 96boards tree:
https://github.com/96boards-hikey/linux/tree/hikey970-v4.9
Based on his history, this driver seems to be originally written
for Kernel 4.4, and was later ported to
Instead of implementing it at the code, use the default
methods from CMA helper
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_drm_dr
While this driver apparently supports both IOMMU and no-IOMMU
access, it always enable the IOMMU via some code, at the
downstream version.
Apparently, the downstream iommu is there just to get the
physical address of the logical IOMMU address. Based on
the downstream code, it sounds that the IOMMU
Use SPMI headers to identify the license of each file.
Signed-off-by: Mauro Carvalho Chehab
---
.../staging/hikey9xx/gpu/kirin960_dpe_reg.h | 1 +
.../staging/hikey9xx/gpu/kirin970_dpe_reg.h | 1 +
.../hikey9xx/gpu/kirin9xx_drm_dpe_utils.c | 4 ++-
.../hikey9xx/gpu/kirin9xx_drm_dpe_ut
Hi Dinghao,
Thank you for the patch.
On Wed, Aug 19, 2020 at 04:22:28PM +0800, Dinghao Liu wrote:
> When verify_crc_source() fails, source needs to be freed.
> However, current code is returning directly and ends up
> leaking memory.
>
> Fixes: c0811a7d5befe ("drm/crc: Cleanup crtc_crc_open func
Quoting Andy Shevchenko (2020-08-19 12:53:53)
> In preparation for unconditionally passing the struct tasklet_struct
> pointer to all tasklet callbacks, switch to using the new tasklet_setup()
> and from_tasklet() to pass the tasklet pointer explicitly.
>
> Signed-off-by: Andy Shevchenko
Reviewed
Hi Tomi,
Thank you for the patch.
On Wed, Aug 19, 2020 at 01:30:21PM +0300, Tomi Valkeinen wrote:
> After commit 92cc68e35863c1c61c449efa2b2daef6e9926048 ("drm/vblank: Use
> spin_(un)lock_irq() in drm_crtc_vblank_on()") omapdrm locking is broken:
>
> WARNING: inconsistent lock state
> 5.8.0-rc2-
On Wed, 19 Aug 2020, Chris Wilson wrote:
> Quoting Andy Shevchenko (2020-08-19 12:53:53)
>> In preparation for unconditionally passing the struct tasklet_struct
>> pointer to all tasklet callbacks, switch to using the new tasklet_setup()
>> and from_tasklet() to pass the tasklet pointer explicitly
On 09. 07. 20, 14:33, Daniel Vetter wrote:
> Exactly matches the one in the helpers.
It's not that exact. The order of modeset_enables and planes is
different. And this causes a regression -- no fb in qemu.
So if I run drm-tip, no fb.
If I revert 73f15a9, it works.
If I then switch the two calls
Quoting Jani Nikula (2020-08-19 13:34:41)
> On Wed, 19 Aug 2020, Chris Wilson wrote:
> > Quoting Andy Shevchenko (2020-08-19 12:53:53)
> >> In preparation for unconditionally passing the struct tasklet_struct
> >> pointer to all tasklet callbacks, switch to using the new tasklet_setup()
> >> and f
On 19. 08. 20, 14:43, Jiri Slaby wrote:
> On 09. 07. 20, 14:33, Daniel Vetter wrote:
>> Exactly matches the one in the helpers.
>
> It's not that exact. The order of modeset_enables and planes is
> different. And this causes a regression -- no fb in qemu.
>
> So if I run drm-tip, no fb.
> If I re
On Wed, Aug 19, 2020 at 07:00:53AM -0600, Jens Axboe wrote:
> On 8/18/20 1:00 PM, James Bottomley wrote:
> > On Mon, 2020-08-17 at 13:02 -0700, Jens Axboe wrote:
> >> On 8/17/20 12:48 PM, Kees Cook wrote:
> >>> On Mon, Aug 17, 2020 at 12:44:34PM -0700, Jens Axboe wrote:
> On 8/17/20 12:29 PM,
Hi KyongHo,
On Wed, Aug 19, 2020 at 12:46:26PM +0900, Cho KyongHo wrote:
> I have seriously considered CPA in our product but we developed our own
> because of the pool in CPA.
Oh good, I'm glad you considered it :-)
> The high-order pages are required by some specific users like Netflix
> app.
On Wed, Aug 19, 2020 at 02:43:28PM +0200, Jiri Slaby wrote:
> On 09. 07. 20, 14:33, Daniel Vetter wrote:
> > Exactly matches the one in the helpers.
>
> It's not that exact. The order of modeset_enables and planes is
> different. And this causes a regression -- no fb in qemu.
Does https://patchwo
On Wed, Aug 19, 2020 at 07:17:19AM -0600, Jens Axboe wrote:
> On 8/19/20 6:11 AM, Greg KH wrote:
> > On Wed, Aug 19, 2020 at 07:00:53AM -0600, Jens Axboe wrote:
> >> On 8/18/20 1:00 PM, James Bottomley wrote:
> >>> On Mon, 2020-08-17 at 13:02 -0700, Jens Axboe wrote:
> On 8/17/20 12:48 PM, Kee
On Wed, Aug 5, 2020 at 10:59 PM wrote:
>
> From: Tom Rix
>
> Reviewing this block of code in cdv_intel_dp_init()
>
> ret = cdv_intel_dp_aux_native_read(gma_encoder, DP_DPCD_REV, ...
>
> cdv_intel_edp_panel_vdd_off(gma_encoder);
> if (ret == 0) {
> /* if this fails, presume the device is a
drm-next reverted the changes to ttm_tt_create() to do the
NULL check inside the function, but drm-misc-next adds new
users of this approach.
Re-apply the NULL check change inside the function to fix this.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 2 +-
drivers/gpu/drm/t
On Fri, Jul 3, 2020 at 3:01 PM Linus Walleij wrote:
>
> Finalize he conversion of GMA500 to use only GPIO descriptors.
> The GPIO look-up-table is associated with the device directly
> in the GMA500 Medfield chip driver since no explicit platform
> type device (such as in x86/platform/intel-mid) e
On Wed, Aug 19, 2020 at 5:08 AM Michel Dänzer wrote:
>
> On 2020-07-22 7:12 p.m., Alex Deucher wrote:
> > On Wed, Jul 22, 2020 at 10:25 AM Michel Dänzer wrote:
> >> On 2020-07-22 3:10 p.m., Kazlauskas, Nicholas wrote:
> >>> On 2020-07-22 8:51 a.m., Daniel Vetter wrote:
> On Wed, Jul 22, 2020
From: Sean Paul
Used to query whether an MST stream is encrypted or not.
Cc: Lyude Paul
Reviewed-by: Anshuman Gupta
Reviewed-by: Lyude Paul
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-14-s...@poorly.run
#v4
Link:
https://patchwork.fr
After commit 92cc68e35863c1c61c449efa2b2daef6e9926048 ("drm/vblank: Use
spin_(un)lock_irq() in drm_crtc_vblank_on()") omapdrm locking is broken:
WARNING: inconsistent lock state
5.8.0-rc2-00483-g92cc68e35863 #13 Tainted: GW
inconsistent {HARDIRQ-ON-W} -> {I
Hi,
On 13/08/2020 11:36, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in omapdrm.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/omap
On Wed, 2020-08-19 at 07:00 -0600, Jens Axboe wrote:
> On 8/18/20 1:00 PM, James Bottomley wrote:
[...]
> > Since both threads seem to have petered out, let me suggest in
> > kernel.h:
> >
> > #define cast_out(ptr, container, member) \
> > container_of(ptr, typeof(*container), member)
> >
> >
On Tue, Aug 11, 2020 at 04:04:46PM -0400, Lyude Paul wrote:
> Just a tiny drive-by cleanup, we can consolidate i915's code for
> checking for MST support into a helper to be shared across drivers.
>
Reviewed-by: Sean Paul
> Signed-off-by: Lyude Paul
> ---
> drivers/gpu/drm/i915/display/intel_
Hi Andy,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v5.9-rc1 next-20200819]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as
On Tue, Aug 11, 2020 at 04:04:50PM -0400, Lyude Paul wrote:
> We're going to be doing the same probing process in nouveau for
> determining downstream DP port capabilities, so let's deduplicate the
> work by moving i915's code for handling this into a shared helper:
> drm_dp_downstream_read_info().
On Tue, Aug 11, 2020 at 04:04:52PM -0400, Lyude Paul wrote:
> Since other drivers are also going to need to be aware of the sink count
> in order to do proper dongle detection, we might as well steal i915's
> DP_SINK_COUNT helpers and move them into DRM helpers so that other
> dirvers can use them
Hi Mauro.
On Wed, Aug 19, 2020 at 01:45:28PM +0200, Mauro Carvalho Chehab wrote:
> This patch series port the out-of-tree driver for Hikey 970 (which
> should also support Hikey 960) from the official 96boards tree:
>
>https://github.com/96boards-hikey/linux/tree/hikey970-v4.9
>
> Based on h
On Tue, Aug 11, 2020 at 04:04:53PM -0400, Lyude Paul wrote:
> And of course, we'll also need to read the sink count from other drivers
> as well if we're checking whether or not it's supported. So, let's
> extract the code for this into another helper.
>
> Signed-off-by: Lyude Paul
> ---
> drive
On Tue, Aug 11, 2020 at 04:04:56PM -0400, Lyude Paul wrote:
> Since DP 1.3, it's been possible for DP receivers to specify an
> additional set of DPCD capabilities, which can take precedence over the
> capabilities reported at DP_DPCD_REV.
>
> Basically any device supporting DP is going to need to
On Wed, Aug 19, 2020 at 05:21:20PM +0200, Sam Ravnborg wrote:
> Hi Mauro.
>
> On Wed, Aug 19, 2020 at 01:45:28PM +0200, Mauro Carvalho Chehab wrote:
> > This patch series port the out-of-tree driver for Hikey 970 (which
> > should also support Hikey 960) from the official 96boards tree:
> >
> >
From: CK Hu
mtk_hdmi_phy is currently placed inside mediatek drm driver, but it's
more suitable to place a phy driver into phy driver folder, so move
mtk_hdmi_phy driver into phy driver folder.
Signed-off-by: CK Hu
Signed-off-by: Chun-Kuang Hu
Reviewed-by: Chunfeng Yun
Reviewed-by: Matthias B
mtk_hdmi_phy is currently placed inside mediatek drm driver, but it's
more suitable to place a phy driver into phy driver folder, so move
mtk_hdmi_phy driver into phy driver folder.
Changes in v4:
- Rebase onto 5.9-rc1
- Remove mtk_hdmi_conf_mt8173.
Changes in v3:
- Modify [PATCH v2 3/4] prefix.
From: CK Hu
tz_disabled is used to control mtk_hdmi output signal, but this variable
is stored in mtk_hdmi_phy and mtk_hdmi_phy does not use it. So move
tz_disabled to mtk_hdmi where it's used.
Signed-off-by: CK Hu
Signed-off-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/mtk_hdmi.c
From: CK Hu
mtk_hdmi_phy is a part of mtk_hdmi module, but phy driver should be an
independent module rather than be part of drm module, so separate the phy
driver to an independent module.
Signed-off-by: CK Hu
Signed-off-by: Chun-Kuang Hu
Reviewed-by: Chunfeng Yun
---
drivers/gpu/drm/mediat
Mediatek HDMI phy driver is moved from drivers/gpu/drm/mediatek to
drivers/phy/mediatek, so add the new folder to the Mediatek DRM drivers'
information.
Signed-off-by: Chun-Kuang Hu
Reviewed-by: Matthias Brugger
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/M
Hi Chun-Kuang
Two small details below.
Sam
On Wed, Aug 19, 2020 at 11:44:20PM +0800, Chun-Kuang Hu wrote:
> From: CK Hu
>
> mtk_hdmi_phy is currently placed inside mediatek drm driver, but it's
> more suitable to place a phy driver into phy driver folder, so move
> mtk_hdmi_phy driver
On Wed, 19 Aug 2020, Markus Elfring wrote:
> > When of_property_read_u32_array() returns an error code,
> > a pairing refcount decrement is needed to keep np's refcount balanced.
>
> Can another imperative wording be helpful for the change description?
> https://git.kernel.org/pub/scm/linux/kerne
Hi,
On Mon, Aug 17, 2020 at 3:03 PM Rob Clark wrote:
>
> From: Jordan Crouse
>
> Every Qcom Adreno GPU has an embedded SMMU for its own use. These
> devices depend on unique features such as split pagetables,
> different stall/halt requirements and other settings. Identify them
> with a compatib
On 19/08/2020 10:17, Frank Wunderlich wrote:
From: chunhui dai
disable tmds on phy on mt2701 to support other resolutions like 1280x1024
Isn't that worth a Fixes tag?
Regards,
Matthias
Signed-off-by: chunhui dai
Signed-off-by: Frank Wunderlich
Tested-by: Frank Wunderlich
---
drive
On 19/08/2020 10:17, Frank Wunderlich wrote:
From: Jitao Shi
For current mediatek dsi encoder, its possible crtc is fixed in crtc
0, and mediatek dpi encoder's possible crtc is fixed in crtc 1. In
some SoC the possible crtc is not fixed in this case, so call
mtk_drm_find_possible_crtc_by_com
On Wed, 2020-08-19 at 11:15 -0400, Sean Paul wrote:
> On Tue, Aug 11, 2020 at 04:04:50PM -0400, Lyude Paul wrote:
> > We're going to be doing the same probing process in nouveau for
> > determining downstream DP port capabilities, so let's deduplicate the
> > work by moving i915's code for handling
On Wed, Aug 19, 2020 at 10:03 AM Doug Anderson wrote:
>
> Hi,
>
> On Mon, Aug 17, 2020 at 3:03 PM Rob Clark wrote:
> >
> > From: Jordan Crouse
> >
> > Every Qcom Adreno GPU has an embedded SMMU for its own use. These
> > devices depend on unique features such as split pagetables,
> > different s
Fix W=1 compile warnings (invalid kerneldoc):
drivers/dma-buf/dma-fence-chain.c:233: warning: Function parameter or
member 'seqno' not described in 'dma_fence_chain_init'
Signed-off-by: Krzysztof Kozlowski
---
drivers/dma-buf/dma-fence-chain.c | 1 +
1 file changed, 1 insertion(+)
diff --
Fix W=1 compile warnings (invalid kerneldoc):
drivers/dma-buf/dma-buf.c:328: warning: Function parameter or member
'dmabuf' not described in 'dma_buf_set_name'
Signed-off-by: Krzysztof Kozlowski
---
drivers/dma-buf/dma-buf.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff
Hi
Am 19.08.20 um 11:23 schrieb Tian Tao:
> patch #1 is using the drm_err instead of DRM_ERROR in hibmc_ttm.c
> patch #2 is using the drm_err instead of DRM_ERROR in hibmc_drm_vdac.c
> patch #3 is using the drm_err and drm_dbg_atomic instead of DRM_ERROR
> and DRM_DEBUG_ATOMIC in hibmc_drm_de.c
>
Hi Paul.
On Wed, Aug 19, 2020 at 08:14:12PM +0200, Paul Cercueil wrote:
> There is already a 'struct device' pointer in the drm_panel structure,
> that we can access easily from our priv structure, so there's no need
> for a separate 'dev' field there.
>
> This also allows drm_panel_of_backlight(
1 - 100 of 152 matches
Mail list logo
