Hi,
Maxime Ripard 于2021年4月15日周四 下午5:03写道：
>
> Hi,
>
> On Thu, Apr 15, 2021 at 08:18:52AM +0800, Kevin Tang wrote:
> > Maxime Ripard 于2021年3月24日周三 下午7:10写道：
> > > > +static struct sprd_dpu *sprd_crtc_init(struct drm_device *drm,
> > > > + struct drm_plane *primary)
> > > > +{
> -Original Message-
> From: Dominique MARTINET
> Sent: 2021年4月19日 13:03
> To: Alice Guo (OSS)
> Subject: Re: [RFC v1 PATCH 3/3] driver: update all the code that use
> soc_device_match
>
> Alice Guo (OSS) wrote on Mon, Apr 19, 2021 at 12:27:22PM +0800:
> > From: Alice Guo
> >
> > Upda
The IT66121 is a high-performance and low-power single channel HDMI
transmitter, fully compliant with HDMI 1.3a, HDCP 1.2 and backward
compatible to DVI 1.0 specifications.
It supports pixel rates from 25MHz to 165MHz.
This series contains document bindings, add vendor prefix, Kconfig to
enable or
From: Phong LE
Add the ITE bridge HDMI it66121 bindings.
Signed-off-by: Phong LE
Signed-off-by: Neil Armstrong
Reviewed-by: Rob Herring
Reviewed-by: Laurent Pinchart
---
.../bindings/display/bridge/ite,it66121.yaml | 124 ++
1 file changed, 124 insertions(+)
create mode 10
From: Phong LE
This commit is a simple driver for bridge HMDI it66121.
The input format is RBG and there is no color conversion.
Audio, HDCP and CEC are not supported yet.
Signed-off-by: Phong LE
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/bridge/Kconfig |8 +
drivers/gpu/drm/
From: Phong LE
Add Neil Armstrong and myself as maintainers
Signed-off-by: Phong LE
Signed-off-by: Neil Armstrong
Reviewed-by: Robert Foss
---
MAINTAINERS | 8
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9ae8444c96b4..313b3374a51e 100644
--- a/MAINT
On Mon, 19 Apr 2021, ChiYuan Huang wrote:
> Hi, Linux mfd reviewers:
>It's been three weeks not to get any response from you.
> Is there something wrong about this mfd patch?
> If yes, please feel free to let me know.
Couple of things:
First, if you think a patch had fallen through the gaps,
On Mon, 19 Apr 2021, Lee Jones wrote:
> On Mon, 19 Apr 2021, ChiYuan Huang wrote:
>
> > Hi, Linux mfd reviewers:
> >It's been three weeks not to get any response from you.
> > Is there something wrong about this mfd patch?
> > If yes, please feel free to let me know.
>
> Couple of things:
>
On Mon, 19 Apr 2021, Lee Jones wrote:
> On Mon, 19 Apr 2021, Lee Jones wrote:
>
> > On Mon, 19 Apr 2021, ChiYuan Huang wrote:
> >
> > > Hi, Linux mfd reviewers:
> > >It's been three weeks not to get any response from you.
> > > Is there something wrong about this mfd patch?
> > > If yes, ple
On Fri, 16 Apr 2021, Christian König wrote:
>
>
> Am 16.04.21 um 16:37 schrieb Lee Jones:
> > Fixes the following W=1 kernel build warning(s):
> >
> > drivers/gpu/drm/ttm/ttm_tt.c:398: warning: Function parameter or member
> > 'num_pages' not described in 'ttm_tt_mgr_init'
> > drivers/gpu/
The MT8167 SoC have a hard limit on the maximal supported HDMI TMDS clock,
and is not validated and supported for HDMI modes out of HDMI CEA modes.
To achieve this:
- switch the mediatek HDMI bindings to YAML
- add the MT8167 compatible
- add a boolean to discard the non-CEA modes
- add a value to
Update the mediatek,dpi binding to use the graph schema.
Signed-off-by: Neil Armstrong
---
.../display/mediatek/mediatek,cec.yaml| 51 +++
.../display/mediatek/mediatek,hdmi-ddc.yaml | 57
.../display/mediatek/mediatek,hdmi.txt| 136 --
.../displa
Add mt8167 SoC compatible to Mediatek hdmi, hdmi-ddc and cec schema bindings.
Signed-off-by: Neil Armstrong
---
.../devicetree/bindings/display/mediatek/mediatek,cec.yaml | 1 +
.../devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml | 1 +
.../devicetree/bindings/display/mediatek
Some SoCs like the MT8167 are not validated and supported for HDMI modes
out of HDMI CEA modes, so add a configuration boolean to filter out
non-CEA modes.
Signed-off-by: Fabien Parent
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 4
1 file changed, 4 insertions(+
Some SoCs like the MT8167 have a hard limit on the maximal supported HDMI TMDS
clock, so add a configuration value to filter out those modes.
Signed-off-by: Fabien Parent
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 5 +
1 file changed, 5 insertions(+)
diff --git
The MT8167 SoC have a hard limit on the maximal supported HDMI TMDS clock,
and is not validated and supported for HDMI modes out of HDMI CEA modes,
so add a configuration entry linked to the MT8167 compatible.
Signed-off-by: Fabien Parent
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/mediat
Hi Thomas,
On Fri, Apr 16, 2021 at 11:00 AM Thomas Zimmermann wrote:
> This patchset adds support for simple-framebuffer platform devices and
> a handover mechanism for native drivers to take-over control of the
> hardware.
>
> The new driver, called simpledrm, binds to a simple-frambuffer platfo
Correct kerneldoc (remove wrong /** marker and adjust function name) to
fix W=1 warnings:
drivers/gpu/drm/gma500/cdv_intel_lvds.c:27: warning:
expecting prototype for LVDS I2C backlight control macros(). Prototype was
for BRIGHTNESS_MAX_LEVEL() instead
drivers/gpu/drm/gma500/intel_gmbus.
Remove trailing whitespaces. No functional change.
Signed-off-by: Krzysztof Kozlowski
---
drivers/gpu/drm/gma500/backlight.c| 4 +--
drivers/gpu/drm/gma500/cdv_intel_dp.c | 50 +--
2 files changed, 26 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/gma5
Hi Alice,
CC Arnd (soc_device_match() author)
On Mon, Apr 19, 2021 at 6:28 AM Alice Guo (OSS) wrote:
> From: Alice Guo
>
> In i.MX8M boards, the registration of SoC device is later than caam
> driver which needs it. Caam driver needs soc_device_match to provide
> -EPROBE_DEFER when no SoC devic
The DRM_SIL_SII8620 kconfig has a weak `imply` dependency
on EXTCON, which causes issues when sii8620 is built
as a builtin and EXTCON is built as a module.
The symptoms are 'undefined reference' errors caused
by the symbols in EXTCON not being available
to the sii8620 driver.
Fixes: 688838442147
Hi Dominique,
CC Arnd (soc_device_match() author)
On Mon, Apr 19, 2021 at 7:03 AM Dominique MARTINET
wrote:
> Alice Guo (OSS) wrote on Mon, Apr 19, 2021 at 12:27:22PM +0800:
> > From: Alice Guo
> > Update all the code that use soc_device_match
>
> A single patch might be difficult to accept for
vmwgfx is the only driver actually using this. Move the handling into
the driver instead.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 11 ---
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 10 ++
include/drm/ttm/ttm_bo_api.h | 19 ---
3 fil
Geert Uytterhoeven wrote on Mon, Apr 19, 2021 at 11:03:24AM +0200:
> > This is going to need quite some more work to be acceptable, in my
> > opinion, but I think it should be possible.
>
> In general, this is very hard to do, IMHO. Some drivers may be used on
> multiple platforms, some of them
Hey Neil,
Thanks for the quick respin.
Reviewed-by: Robert Foss
On Mon, 19 Apr 2021 at 09:12, Neil Armstrong wrote:
>
> From: Phong LE
>
> This commit is a simple driver for bridge HMDI it66121.
> The input format is RBG and there is no color conversion.
> Audio, HDCP and CEC are not supporte
Hi Joonas and Rodrigo -
Here's the gen to ver conversion topic branch to be merged to both
drm-intel-next and drm-intel-gt-next.
Lots of Cc's for heads up.
BR,
Jani.
topic/intel-gen-to-ver-2021-04-19:
Gen to ver conversions across the driver
The main change is Lucas' series [1], with Ville'
Lee Jones 於 2021年4月19日 週一 下午3:24寫道：
>
> On Mon, 19 Apr 2021, Lee Jones wrote:
>
> > On Mon, 19 Apr 2021, Lee Jones wrote:
> >
> > > On Mon, 19 Apr 2021, ChiYuan Huang wrote:
> > >
> > > > Hi, Linux mfd reviewers:
> > > >It's been three weeks not to get any response from you.
> > > > Is there s
Hi,
This is our initial proposal for explicit fences everywhere and new memory
management that doesn't use BO fences. It's a redesign of how Linux
graphics drivers work, and it can coexist with what we have now.
*1. Introduction*
(skip this if you are already sold on explicit fences)
The curren
Fix the cases where it is almost already valid kernel doc, for the
others just nerf the warnings for now.
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Jordan Justen
Cc: Daniel Vetter
Cc: Kenneth Graunke
Cc: Jason Ekstrand
Cc: Dave Airlie
Cc: dri-devel@lists.freedesktop.org
Cc: mesa-.
Add section for drm/i915 uAPI and pull in i915_drm.h.
Suggested-by: Daniel Vetter
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Jordan Justen
Cc: Daniel Vetter
Cc: Kenneth Graunke
Cc: Jason Ekstrand
Cc: Dave Airlie
Cc: dri-devel@lists.freedesktop.org
Cc: mesa-...@lists.freedesktop.or
Add some example usage for the extension chaining also, which is quite
nifty.
v2: (Daniel)
- clarify that the name is just some integer, also document that the
name space is not global
v3: prefer kernel-doc references for structs
Suggested-by: Daniel Vetter
Signed-off-by: Matthew Auld
Cc:
Add a note about the two-step process.
v2(Tvrtko):
- Also document the other method of just passing in a buffer which is
large enough, which avoids two ioctl calls. Can make sense for
smaller query items.
v3: prefer kernel-doc references for structs and members
Suggested-by: Daniel Vett
struct tegra_dc is declared at 13rd line.
The declaration here is unnecessary. Remove it.
Signed-off-by: Wan Jiabing
---
drivers/gpu/drm/tegra/hub.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/tegra/hub.h b/drivers/gpu/drm/tegra/hub.h
index 3efa1be07ff8..23c4b2115ed1 10064
On 15/04/2021 12:05, Tvrtko Ursulin wrote:
On 15/04/2021 10:23, Matthew Auld wrote:
On Thu, 15 Apr 2021 at 09:21, Tvrtko Ursulin
wrote:
On 14/04/2021 17:20, Matthew Auld wrote:
On Wed, 14 Apr 2021 at 16:22, Tvrtko Ursulin
wrote:
On 12/04/2021 10:05, Matthew Auld wrote:
From: Venkata S
Reviewed-by: Karol Herbst
On Fri, Apr 16, 2021 at 4:37 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:584: warning: Function
> parameter or member 'init' not described in 'init_reserved'
> drivers/gpu/drm/nouveau/nv
On Fri, Apr 16, 2021 at 4:37 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/dispnv50/disp.c:1381:6: warning: variable ‘ret’ set
> but not used [-Wunused-but-set-variable]
>
not a big fan of just ignoring return codes, I'd rather see it handl
Reviewed-by: Karol Herbst
On Fri, Apr 16, 2021 at 4:37 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:992: warning: Function
> parameter or member 'gr' not described in 'gf100_gr_wait_idle'
>
> Cc: Ben Skeggs
> Cc: D
Reviewed-by: Karol Herbst
On Fri, Apr 16, 2021 at 4:37 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:53: warning: Function
> parameter or member 'speedo' not described in 'gk20a_volt_get_cvb_voltage'
> drivers/gpu
Reviewed-by: Karol Herbst
On Fri, Apr 16, 2021 at 4:37 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/nouveau_bo.c: In function ‘nouveau_ttm_tt_populate’:
> drivers/gpu/drm/nouveau/nouveau_bo.c:1228:17: warning: variable ‘dev’ set
> but no
Reviewed-by: Karol Herbst
On Fri, Apr 16, 2021 at 4:38 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/dispnv04/crtc.c:462: warning: Function parameter or
> member 'crtc' not described in 'nv_crtc_mode_set_regs'
> drivers/gpu/drm/nouveau/di
On Fri, Apr 16, 2021 at 4:38 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/dispnv50/disp.c: In function ‘nv50_mstm_cleanup’:
> drivers/gpu/drm/nouveau/dispnv50/disp.c:1357:6: warning: variable ‘ret’ set
> but not used [-Wunused-but-set-vari
Reviewed-by: Karol Herbst
On Fri, Apr 16, 2021 at 4:38 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/dispnv50/headc57d.c:173:1: warning: no previous
> prototype for ‘headc57d_olut’ [-Wmissing-prototypes]
>
> Cc: Ben Skeggs
> Cc: David Air
Reviewed-by: Karol Herbst
On Fri, Apr 16, 2021 at 4:38 PM Lee Jones wrote:
>
> Fixes the following build error:
>
> drivers/gpu/drm/nouveau/dispnv50/disp.c:2530:1: error: conflicting types for
> ‘nv50_display_fini’
> In file included from drivers/gpu/drm/nouveau/dispnv50/disp.c:71:
> drivers
On Fri, Apr 16, 2021 at 4:38 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/nouveau_svm.c: In function ‘nouveau_pfns_map’:
> drivers/gpu/drm/nouveau/nouveau_svm.c:810:6: warning: variable ‘ret’ set but
> not used [-Wunused-but-set-variable]
Reviewed-by: Karol Herbst
On Fri, Apr 16, 2021 at 4:38 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/nouveau_ioc32.c:52: warning: Function parameter or
> member 'filp' not described in 'nouveau_compat_ioctl'
> drivers/gpu/drm/nouveau/nouv
Reviewed-by: Karol Herbst
On Fri, Apr 16, 2021 at 4:38 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/nouveau_ioc32.c:2: warning: Cannot understand *
> file mga_ioc32.c
>
> Cc: Ben Skeggs
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri
Reviewed-by: Karol Herbst
On Fri, Apr 16, 2021 at 4:38 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/dispnv50/disp.c:2599:1: warning: no previous
> prototype for ‘nv50_display_create’ [-Wmissing-prototypes]
>
> Cc: Ben Skeggs
> Cc: David
On 16/04/2021 17:38, Jason Ekstrand wrote:
On Thu, Apr 15, 2021 at 11:04 AM Matthew Auld wrote:
Add an entry for the new uAPI needed for DG1.
v2(Daniel):
- include the overall upstreaming plan
- add a note for mmap, there are differences here for TTM vs i915
- bunch of other suggesti
Hi all,
I'm working on a Wayland extension [1] that, among other things, allows
compositors to advertise the preferred device to be used by Wayland
clients.
In general, compositors will send a render node. However, in the case
of split render/display SoCs, things get a little bit complicated.
Th
On Mon, Apr 19, 2021 at 11:33 AM Dominique MARTINET
wrote:
> Geert Uytterhoeven wrote on Mon, Apr 19, 2021 at 11:03:24AM +0200:
>
> > soc_device_match() should only be used as a last resort, to identify
> > systems that cannot be identified otherwise. Typically this is used for
> > quirks, which
According to the TODO list of the DRM subsystem, replace the deprecated
drm_modeset_*_all() with DRM_MODESET_LOCK_ALL_*().
Fabio M. De Francesco (2):
drm/amd/amdgpu/amdgpu_device.c: Replace drm_modeset_*_all with
DRM_MODESET_LOCK_ALL_*
drm/amd/amdgpu/amdgpu_drv.c: Replace drm_modeset_*_all
Replace the deprecated API with new helpers, according to the TODO list
of the DRM subsystem.
Signed-off-by: Fabio M. De Francesco
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amd
Replace the deprecated API with new helpers, according to the TODO list
of the DRM subsystem.
Signed-off-by: Fabio M. De Francesco
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/driv
On 4/19/21 2:16 PM, Michal Hocko wrote:
> On Sat 17-04-21 12:40:32, Peter Enderborg wrote:
>> This adds a total used dma-buf memory. Details
>> can be found in debugfs, however it is not for everyone
>> and not always available. dma-buf are indirect allocated by
>> userspace. So with this value we
On Mon, 19 Apr 2021, Fabio M. De Francesco wrote:
> Replace the deprecated API with new helpers, according to the TODO list
> of the DRM subsystem.
The commit message will perhaps not be very meaningful one year from now.
You could say for example DRM_MODESET_LOCK_ALL_BEGIN was introduced in
c
From: Zack Rusin
commit ab4d9913632b1e5ffcf3365783e98718b3c83c7f upstream.
We were not correctly unpinning no longer needed buffers. In particular
vmw_buffer_object, which is internally often pinned on creation wasn't
unpinned on destruction and none of the internal MOB buffers were
unpinned bef
On Mon, Apr 19, 2021 at 05:28:53PM +0800, Christian König wrote:
> vmwgfx is the only driver actually using this. Move the handling into
> the driver instead.
>
> Signed-off-by: Christian König
Acked-by: Huang Rui
> ---
> drivers/gpu/drm/ttm/ttm_bo.c | 11 ---
> drivers/gpu/drm/
On 4/18/21 9:27 PM, Alice Guo (OSS) wrote:
> From: Alice Guo
>
> Update all the code that use soc_device_match because add support for
> soc_device_match returning -EPROBE_DEFER.
>
> Signed-off-by: Alice Guo
> ---
[ ... ]
> drivers/watchdog/renesas_wdt.c| 2 +-
> 48 files chan
On Monday, April 19, 2021 3:08:51 PM CEST Julia Lawall wrote:
> On Mon, 19 Apr 2021, Fabio M. De Francesco wrote:
> > Replace the deprecated API with new helpers, according to the TODO list
> > of the DRM subsystem.
>
> The commit message will perhaps not be very meaningful one year from now.
> Yo
On 19/04/2021 12:30, Matthew Auld wrote:
On 15/04/2021 12:05, Tvrtko Ursulin wrote:
On 15/04/2021 10:23, Matthew Auld wrote:
On Thu, 15 Apr 2021 at 09:21, Tvrtko Ursulin
wrote:
On 14/04/2021 17:20, Matthew Auld wrote:
On Wed, 14 Apr 2021 at 16:22, Tvrtko Ursulin
wrote:
On 12/04/2021
On 16/04/2021 16:04, Matthew Auld wrote:
On 14/04/2021 16:01, Tvrtko Ursulin wrote:
On 12/04/2021 10:05, Matthew Auld wrote:
From: CQ Tang
Add "REGION_STOLEN" device info to dg1, create stolen memory
region from upper portion of local device memory, starting
from DSMBASE.
v2:
- s/drm_
On 16/04/2021 15:25, Matthew Auld wrote:
On 14/04/2021 16:33, Tvrtko Ursulin wrote:
On 12/04/2021 10:05, Matthew Auld wrote:
From: Anusha Srivatsa
In the scenario where local memory is available, we have
rely on CPU access via lmem directly instead of aperture.
v2:
gmch is only relevant fo
On 19/04/2021 15:07, Tvrtko Ursulin wrote:
On 19/04/2021 12:30, Matthew Auld wrote:
On 15/04/2021 12:05, Tvrtko Ursulin wrote:
On 15/04/2021 10:23, Matthew Auld wrote:
On Thu, 15 Apr 2021 at 09:21, Tvrtko Ursulin
wrote:
On 14/04/2021 17:20, Matthew Auld wrote:
On Wed, 14 Apr 2021 at 16:
On Mon, 19 Apr 2021, Fabio M. De Francesco wrote:
> On Monday, April 19, 2021 3:08:51 PM CEST Julia Lawall wrote:
> > On Mon, 19 Apr 2021, Fabio M. De Francesco wrote:
> > > Replace the deprecated API with new helpers, according to the TODO list
> > > of the DRM subsystem.
> >
> > The commit me
On 19/04/2021 15:37, Matthew Auld wrote:
On 19/04/2021 15:07, Tvrtko Ursulin wrote:
On 19/04/2021 12:30, Matthew Auld wrote:
On 15/04/2021 12:05, Tvrtko Ursulin wrote:
On 15/04/2021 10:23, Matthew Auld wrote:
On Thu, 15 Apr 2021 at 09:21, Tvrtko Ursulin
wrote:
On 14/04/2021 17:20, Matt
Replace the deprecated API with new helpers, according to the TODO list
of the DRM subsystem. The new API has been introduced with commit
b7ea04d299c7: DRM_MODESET_LOCK_ALL_BEGIN() simplifies grabbing all modeset
locks using a local context. This has the advantage of reducing boilerplate.
Change
Replace the deprecated API with new helpers, according to the TODO list
of the DRM subsystem. The new API has been introduced with commit
b7ea04d299c7: DRM_MODESET_LOCK_ALL_BEGIN() simplifies grabbing all modeset
locks using a local context and has the advantage of reducing boilerplate.
Signed-off
Replace the deprecated API with new helpers, according to the TODO list
of the DRM subsystem. The new API has been introduced with commit
b7ea04d299c7: DRM_MODESET_LOCK_ALL_BEGIN() simplifies grabbing all modeset
locks using a local context and has the advantage of reducing boilerplate.
Signed-off
On Mon, Apr 19, 2021 at 7:02 AM Matthew Auld wrote:
>
> On 16/04/2021 17:38, Jason Ekstrand wrote:
> > On Thu, Apr 15, 2021 at 11:04 AM Matthew Auld
> > wrote:
> >>
> >> Add an entry for the new uAPI needed for DG1.
> >>
> >> v2(Daniel):
> >>- include the overall upstreaming plan
> >>- a
Hi,
On Fri, Apr 16, 2021 at 7:32 PM kernel test robot wrote:
>
> Hi Douglas,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on next-20210416]
> [cannot apply to wsa/i2c/for-next robh/for-next linus/master v5.12-rc7
> v5.12-rc6 v5.12-rc5 v5.12-rc7]
> [If your patch is
Am 19.04.21 um 17:19 schrieb peter.enderb...@sony.com:
On 4/19/21 5:00 PM, Michal Hocko wrote:
On Mon 19-04-21 12:41:58, peter.enderb...@sony.com wrote:
On 4/19/21 2:16 PM, Michal Hocko wrote:
On Sat 17-04-21 12:40:32, Peter Enderborg wrote:
This adds a total used dma-buf memory. Details
can
Not going to comment on everything on the first pass...
On Mon, Apr 19, 2021 at 5:48 AM Marek Olšák wrote:
>
> Hi,
>
> This is our initial proposal for explicit fences everywhere and new memory
> management that doesn't use BO fences. It's a redesign of how Linux graphics
> drivers work, and it
On 4/19/21 5:00 PM, Michal Hocko wrote:
> On Mon 19-04-21 12:41:58, peter.enderb...@sony.com wrote:
>> On 4/19/21 2:16 PM, Michal Hocko wrote:
>>> On Sat 17-04-21 12:40:32, Peter Enderborg wrote:
This adds a total used dma-buf memory. Details
can be found in debugfs, however it is not for
On Sat 17-04-21 12:40:32, Peter Enderborg wrote:
> This adds a total used dma-buf memory. Details
> can be found in debugfs, however it is not for everyone
> and not always available. dma-buf are indirect allocated by
> userspace. So with this value we can monitor and detect
> userspace application
Am 19.04.21 um 18:11 schrieb Michal Hocko:
On Mon 19-04-21 17:44:13, Christian König wrote:
Am 19.04.21 um 17:19 schrieb peter.enderb...@sony.com:
On 4/19/21 5:00 PM, Michal Hocko wrote:
On Mon 19-04-21 12:41:58, peter.enderb...@sony.com wrote:
On 4/19/21 2:16 PM, Michal Hocko wrote:
On Sa
Tested-by: Nirmoy Das
On 4/19/21 11:28 AM, Christian König wrote:
vmwgfx is the only driver actually using this. Move the handling into
the driver instead.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 11 ---
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 10 ++
Add support for the 10.3" E Ink panel described at:
https://www.eink.com/product.html?type=productdetail&id=7
Signed-off-by: Alistair Francis
---
drivers/gpu/drm/panel/panel-simple.c | 29
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-sim
Add the E Ink Corporation to the vendor bindings.
Signed-off-by: Alistair Francis
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml
b/Documentation/devicetree/bindings/vendor-pr
I can not remember why the original code did return 0 rather than an error, but
-ENOMEM seems indeed way more fitting.
Reviewed-by: Pierre Moreau
On 2021-04-14 — 08:58, Dan Carpenter wrote:
> If nouveau_get_backlight_name() fails then this should return -ENOMEM
> but currently it returns success
Add an entry for the new uAPI needed for DG1. Also add the overall
upstream plan, including some notes for the TTM conversion.
v2(Daniel):
- include the overall upstreaming plan
- add a note for mmap, there are differences here for TTM vs i915
- bunch of other suggestions from Daniel
v3:
(D
On 4/19/21 2:01 AM, Robert Foss wrote:
> The DRM_SIL_SII8620 kconfig has a weak `imply` dependency
> on EXTCON, which causes issues when sii8620 is built
> as a builtin and EXTCON is built as a module.
>
> The symptoms are 'undefined reference' errors caused
> by the symbols in EXTCON not being av
On Mon, Apr 19, 2021, 19:11 Randy Dunlap wrote:
> On 4/19/21 2:01 AM, Robert Foss wrote:
> > The DRM_SIL_SII8620 kconfig has a weak `imply` dependency
> > on EXTCON, which causes issues when sii8620 is built
> > as a builtin and EXTCON is built as a module.
> >
> > The symptoms are 'undefined ref
On 4/19/21 10:10 AM, Randy Dunlap wrote:
> On 4/19/21 2:01 AM, Robert Foss wrote:
>> The DRM_SIL_SII8620 kconfig has a weak `imply` dependency
>> on EXTCON, which causes issues when sii8620 is built
>> as a builtin and EXTCON is built as a module.
>>
>> The symptoms are 'undefined reference' errors
On Sun, Apr 18, 2021 at 1:03 AM Dave Airlie wrote:
>
> Hi Zack,
>
> Please make sure to always cc dri-devel and/or Daniel on these so if
> I'm away they don't get lost, but also so that they make it into
> patchwork for processing.
>
> If you have a chance can you resend it, I'll see if we can pro
On Mon 19-04-21 12:41:58, peter.enderb...@sony.com wrote:
> On 4/19/21 2:16 PM, Michal Hocko wrote:
> > On Sat 17-04-21 12:40:32, Peter Enderborg wrote:
> >> This adds a total used dma-buf memory. Details
> >> can be found in debugfs, however it is not for everyone
> >> and not always available. dm
On Mon 19-04-21 17:44:13, Christian König wrote:
> Am 19.04.21 um 17:19 schrieb peter.enderb...@sony.com:
> > On 4/19/21 5:00 PM, Michal Hocko wrote:
> > > On Mon 19-04-21 12:41:58, peter.enderb...@sony.com wrote:
> > > > On 4/19/21 2:16 PM, Michal Hocko wrote:
> > > > > On Sat 17-04-21 12:40:32, P
Since it's been asked quite a few times on some of the various DP
related patch series I've submitted to use the new DRM printk helpers,
and it technically wasn't really trivial to do this before due to the
lack of a consistent way to find a drm_device for an AUX channel, this
patch series aims to
While working on moving i2c device registration into drm_dp_aux_init() - I
realized that in order to do so we need to make sure that drivers calling
drm_dp_aux_init() handle any errors it could possibly return. In the
process of doing that, I noticed that the majority of AMD's code for DP
connector
Since we're about to make it so that drm_dp_aux_init() can fail (and thus -
should have it's return value checked) - we should require that callers of
drm_dp_aux_register() also check it's return value since drm_dp_aux_init()
can be called from there.
Signed-off-by: Lyude Paul
---
include/drm/dr
When moving around drm_dp_aux_register() calls, it turned out we
accidentally managed to cause issues with the Tegra driver due to the fact
the Tegra driver would attempt to retrieve a reference to the AUX channel's
i2c adapter - which wouldn't be initialized until drm_dp_aux_register() is
called.
Just adds some missing calls to
drm_dp_aux_register()/drm_dp_aux_unregister() for when we attach/detach the
bridge.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/br
Since AUX adapters on nouveau have their respective DRM connectors as
parents, we need to make sure that we register then after their connectors.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
This is something that we've wanted for a while now: the ability to
actually look up the respective drm_device for a given drm_dp_aux struct.
This will also allow us to transition over to using the drm_dbg_*() helpers
for debug message printing, as we'll finally have a drm_device to reference
for d
The docs we had for drm_dp_aux_init() and drm_dp_aux_register() were mostly
correct, except for the fact that they made the assumption that all AUX
devices were grandchildren of their respective DRM devices. This is the
case for most normal GPUs, but is almost never the case with SoCs and
display b
So that we can start using drm_dbg_*() in
drm_dp_link_train_clock_recovery_delay().
Signed-off-by: Lyude Paul
Reviewed-by: Laurent Pinchart
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 2 +-
drivers/gpu/drm/drm_dp_helper.c | 3 ++-
So that we can start using drm_dbg_*() for
drm_dp_link_train_channel_eq_delay() and
drm_dp_lttpr_link_train_channel_eq_delay().
Signed-off-by: Lyude Paul
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 2 +-
drivers/gpu/drm/drm_dp_helper.c
Since we're about to convert everything in drm_dp_helper.c over to using
drm_dbg_*(), let's also make our logging more consistent in drm_dp_helper.c
while we're at it to ensure that we always print the name of the AUX
channel in question.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_help
Another function that we'll need to pass a drm_device (and not drm_dp_aux)
down to so that we can move over to using drm_dbg_*().
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 3 ++-
drivers/gpu/drm/i915/display/intel_hdmi.c | 3 +--
include/drm/drm_dp_dual_mode_helpe
Another function we need to pass drm_device down to in order to start using
drm_dbg_*().
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 3 ++-
drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +-
include/drm/drm_dp_dual_mode_helper.h | 2 +-
3 files changed, 4 inserti
Another function to pass drm_device * down to so we can start using the
drm_dbg_*() in the DRM DP helpers.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 5 +++--
include/drm/drm_dp_dual_mode_helper.h | 2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
diff -
1 - 100 of 114 matches
Mail list logo
