CC Hans Verkuil
Dne petek, 16. april 2021 ob 13:38:59 CEST je Neil Armstrong napisal(a):
> On 16/04/2021 11:58, Laurent Pinchart wrote:
> > Hi Neil,
> >
> > On Fri, Apr 16, 2021 at 11:27:35AM +0200, Neil Armstrong wrote:
> >> This adds DW-HDMI driver a glue option to disable loading of the CEC
>
On Sat, Apr 17, 2021 at 12:08 AM 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 a
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 applied to the wrong git tree, kindly drop us a note.
And when submitting
Hi,
On Wed, Apr 14, 2021 at 9:41 AM Rajeev Nandan wrote:
>
> The backlight level of an eDP panel can be controlled through the AUX
> channel using DPCD registers of the panel.
>
> The capability for the Source device to adjust backlight characteristics
> within the panel, using the Sink device DP
This is really just a revert of commit 58074b08c04a ("drm/bridge:
ti-sn65dsi86: Read EDID blob over DDC"), resolving conflicts.
The old code failed to read the EDID properly in a very important
case: before the bridge's pre_enable() was called. The way things need
to work:
1. Read the EDID.
2. Bas
We'd like to be able to expose the DDC-over-AUX channel bus to our
panel. This gets into a chicken-and-egg problem because:
- The panel wants to get its DDC at probe time.
- The ti-sn65dsi86 MIPI-to-eDP bridge code, which provides the DDC
bus, wants to get the panel at probe time.
By using a sub
Let's make the bridge use autosuspend with a 500ms delay. This is in
preparation for promoting DP AUX transfers to their own sub-driver so
that we're not constantly powering up and down the device as we
transfer all the chunks.
Signed-off-by: Douglas Anderson
---
(no changes since v1)
drivers/
No functional changes--this just makes the diffstat of a future change
easier to understand.
Signed-off-by: Douglas Anderson
---
(no changes since v1)
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 116 +-
1 file changed, 58 insertions(+), 58 deletions(-)
diff --git a/drivers
I don't believe that it ever makes sense to read the EDID when a panel
is not powered and the powering on of the panel is the job of
prepare(). Let's make sure that this happens before we try to read the
EDID. We use the pm_runtime functions directly rather than directly
calling the normal prepare(
Historically simple-panel had code to make sure that if prepare() was
called on an already-prepared panel that it was a no-op. Similarly if
unprepare() was called on an already-unprepared panel it was also a
no-op. Essentially it means that these functions always "forced" the
value to be whatever t
As of commit 5186421cbfe2 ("drm: Introduce epoch counter to
drm_connector") the drm_get_edid() function calls
drm_connector_update_edid_property() for us. There's no reason for us
to call it again.
Signed-off-by: Douglas Anderson
---
As Laurent pointed out [1] this is actually a pretty common
pro
It doesn't make sense to go out to the bus and read the EDID over and
over again. Let's cache it and throw away the cache when we turn power
off from the panel. Autosuspend means that even if there are several
calls to read the EDID before we officially turn the power on then we
should get good use
Let's reorganize how we init and turn on the reference clock in the
code to allow us to turn it on early (even before pre_enable()) so
that we can read the EDID early. This is handy for eDP because:
- We always assume that a panel is there.
- Once we report that a panel is there we get asked to rea
When I added support for the hpd-gpio to simple-panel in commit
48834e6084f1 ("drm/panel-simple: Support hpd-gpios for delaying
prepare()"), I added a special case to handle a circular dependency I
was running into on the ti-sn65dsi86 bridge chip. On my board the
hpd-gpio is actually provided by th
Like the previous patch ("drm/bridge: ti-sn65dsi86: Rename the main
driver data structure") this is just a no-op rename in preparation for
splitting the driver up a bit.
Here I've attempted to rename functions / structures making sure that
anything applicable to the whole chip (instead of just the
This is just code motion of the probe routine to move all the things
that are for the "whole chip" (instead of the GPIO parts or the
MIPI-to-eDP parts) together at the start of probe. This is in
preparation for breaking the driver into sub-drivers.
Since we're using devm for all of the "whole chip
Let's use the newly minted aux bus to break up the driver into sub
drivers. We're not doing a full breakup here: all the code is still in
the same file and remains largely untouched. The big goal here of
using sub-drivers is to allow part of our code to finish probing even
if some other code needs
In preparation for splitting this driver into sub-drivers, let's
rename the main data structure so it's clear that it's holding data
for the whole device and not just the MIPI-eDP bridge part.
This is a no-op change.
Signed-off-by: Douglas Anderson
---
(no changes since v1)
drivers/gpu/drm/br
There's no devm_runtime_enable(), but it's easy to use
devm_add_action_or_reset() and means we don't need to worry about the
disable in our remove() routine or in error paths.
No functional changes intended by this change.
Signed-off-by: Douglas Anderson
---
(no changes since v1)
drivers/gpu/
Tiny cleanup for probe so we don't keep having to specify
"&client->dev" or "pdata->dev". No functional changes intended.
Signed-off-by: Douglas Anderson
---
(no changes since v1)
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 26 --
1 file changed, 12 insertions(+), 14 deleti
Unpreparing and re-preparing a panel can be a really heavy
operation. Panels datasheets often specify something on the order of
500ms as the delay you should insert after turning off the panel
before turning it on again. In addition, turning on a panel can have
delays on the order of 100ms - 200ms
Let's cleanup the debugfs code to:
- Check for errors.
- Use devm to manage freeing, which also means we don't need to store
a pointer in our structure.
Signed-off-by: Douglas Anderson
---
(no changes since v1)
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 32 +--
1 file ch
Let's:
- Set the drvdata as soon as it's allocated. This just sets up a
pointer so there's no downside here.
- Remove the useless call to i2c_set_clientdata() which is literally
the same thing as dev_set_drvdata().
No functional changes intended.
Signed-off-by: Douglas Anderson
---
(no chan
If we just leave the detect() function as NULL then the upper layers
assume we're always connected. There's no reason for a stub.
Signed-off-by: Douglas Anderson
Reviewed-by: Andrzej Hajda
Reviewed-by: Laurent Pinchart
---
(no changes since v1)
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 12
We prepared the panel in pre_enable() so we should unprepare it in
post_disable() to match.
Signed-off-by: Douglas Anderson
Reviewed-by: Andrzej Hajda
Reviewed-by: Laurent Pinchart
---
Changes in v4:
- Reword commit mesage slightly.
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 4 ++--
1 file chan
The drm_bridge_chain_pre_enable() is not the proper opposite of
drm_bridge_chain_post_disable(). It continues along the chain to
_before_ the starting bridge. Let's fix that.
Fixes: 05193dc38197 ("drm/bridge: Make the bridge chain a double-linked list")
Signed-off-by: Douglas Anderson
Reviewed-by
Let's make the remove() function strictly the reverse of the probe()
function so it's easier to reason about.
This patch was created by code inspection and should move us closer to
a proper remove.
Signed-off-by: Douglas Anderson
Reviewed-by: Andrzej Hajda
Reviewed-by: Laurent Pinchart
---
(n
A random comment inside a function had "/**" in front of it. That
doesn't make sense. Remove.
Signed-off-by: Douglas Anderson
Reviewed-by: Andrzej Hajda
Reviewed-by: Laurent Pinchart
---
(no changes since v1)
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +-
1 file changed, 1 insertion(+), 1 del
The clock framework makes it simple to deal with an optional clock.
You can call clk_get_optional() and if the clock isn't specified it'll
just return NULL without complaint. It's valid to pass NULL to
enable/disable/prepare/unprepare. Let's make use of this to simplify
things a tiny bit.
Signed-o
dy.
This patch was developed agains linuxnext (next-20210416) on a
sc7180-trogdor-lazor device. To get things booting for me, I had to
use Stephen's patch [2] to keep from crashing but otherwise all the
patches I needed were here.
Primary change between v2 and v3 is to stop doing the EDID ca
Add an API to take a snapshot of DSI controller registers. This API
will be used by the msm_disp_snapshot module to capture the DSI
snapshot.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dsi/dsi.c | 4
drivers/gpu/drm/msm/dsi/dsi.h | 5 -
drivers/gpu/drm/msm/dsi/dsi_
Add snapshot points across dpu driver to trigger dumps when critical
errors are hit.
changes in v5:
- change the callers to use the snapshot function directly
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 16 +---
drivers/gpu/drm/msm/disp/d
Add support to take the register snapshot of dsi, dp and dpu
modules.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/msm_disp_snapshot.h | 1 +
drivers/gpu/drm/msm/disp/msm_disp_snapshot_util.c | 16
2 files changed, 17 insertions(+)
diff --git a/drivers/gpu/dr
Add the msm_disp_snapshot module which adds supports to dump dpu
registers and capture the drm atomic state which can be used in
case of error conditions.
changes in v5:
- start storing disp_state in msm_kms instead of dpu_kms
- get rid of MSM_DISP_SNAPSHOT_IN_* enum by simplifying the functions
Add an API to take a snapshot of DP controller registers. This API
will be used by the msm_disp_snapshot module to capture the DP
snapshot.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dp/dp_catalog.c | 9 +
drivers/gpu/drm/msm/dp/dp_catalog.h | 4
drivers/gpu/drm/msm/dp/d
Add an API to take a snapshot of DPU controller registers. This API
will be used by the msm_disp_snapshot module to capture the DPU
snapshot.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 50 +
drivers/gpu/drm/msm/msm_kms.h |
This series adds support to use devcoredump for DPU driver. It introduces
the msm_disp_snapshot module which assists in the capturing of register dumps
during
error scenarios. When a display related error happens, the msm_disp_snapshot
module
captures all the relevant register dumps along with th
Currently drm_atomic_print_state() internally allocates and uses a
drm_info printer. Allow it to accept any drm_printer type so that
the API can be leveraged even for taking drm snapshot.
Rename the drm_atomic_print_state() to drm_atomic_print_new_state()
so that it reflects its functionality bett
Some dongle may generate more than one irq_hpd events in a short period of
time. This patch will treat those irq_hpd events as single one and service
only one irq_hpd event.
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_display.c | 9 +
1 file changed, 9 insertions(+)
diff -
Daniel Vetter writes:
> On Fri, Apr 16, 2021 at 12:25 AM Ian Romanick wrote:
>> Since we just had a big discussion about this on mesa-dev w.r.t. Mesa
>> code and documentation... does the kernel have a policy about which
>> flavor (pun intended) of English should be used?
>
> I'm not finding it
Reviewed-by: Jason Ekstrand
On April 16, 2021 05:37:55 Matthew Auld wrote:
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.
Sugg
On Fri, Apr 16, 2021 at 2:53 PM Takashi Iwai wrote:
>
> Currently the DRM fbcon helper for console blank,
> drm_fb_helper_blank(), simply calls drm_fb_helper_dpms() and always
> returns zero, supposing the driver dealing with DPMS or atomic
> crtc->active flip to handle blanking the screen. It wo
On April 16, 2021 05:37:52 Matthew Auld wrote:
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
Suggested-by: Daniel Vetter
Signed-off-by: Matthew Auld
Hi Takashi,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next linus/master v5.12-rc7 next-20210416]
[cannot apply to drm/drm-next]
[If your patch is
Hi Takashi,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next linus/master v5.12-rc7 next-20210416]
[cannot apply to drm/drm-next]
[If your patch is
Maybe when the cable is disconnected the DP phy should be shutdown and
some bit in the phy could effectively "cut off" the aux channel and then
NAKs would start coming through here in the DP controller I/O register
space. This patch have DP aux channel read/write to return NAK immediately
if DP con
Initialize audio_comp when audio starts and wait for audio_comp at
dp_display_disable(). This will take care of both dongle unplugged
and display off (suspend) cases.
Changes in v2:
-- add dp_display_signal_audio_start()
Changes in v3:
-- restore dp_display_handle_plugged_change() at dp_hpd_unplu
On 4/16/2021 10:02 AM, Daniel Vetter wrote:
On Fri, Apr 16, 2021 at 6:38 PM 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 di
On Fri, Apr 16, 2021 at 06:27:23PM +0200, Mario Kleiner wrote:
> On Mon, Mar 22, 2021 at 4:52 PM Ville Syrjälä
> wrote:
> >
> > On Fri, Mar 19, 2021 at 10:03:12PM +0100, Mario Kleiner wrote:
> > > Hi,
> > >
> > > this patch series adds the fourcc's for 16 bit fixed point unorm
> > > framebuffers t
On Fri, Apr 16, 2021 at 6:38 PM 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
https://bugzilla.kernel.org/show_bug.cgi?id=13170
--- Comment #76 from morten vermund (mortenverm...@gmail.com) ---
(In reply to danny.piccirillo from comment #34)
> I ran into this installing Ubuntu on a friend's machine (the newer MacBook
> 5,2 http://en.wikipedia.org/wiki/MacBook#Model_specific
https://bugzilla.kernel.org/show_bug.cgi?id=13170
--- Comment #75 from morten vermund (mortenverm...@gmail.com) ---
(In reply to danny.piccirillo from comment #34)
> I ran into this installing Ubuntu on a friend's machine (the newer MacBook
> 5,2 http://en.wikipedia.org/wiki/MacBook#Model_specific
https://bugzilla.kernel.org/show_bug.cgi?id=13170
--- Comment #74 from morten vermund (mortenverm...@gmail.com) ---
(In reply to morten vermund from comment #71)
> (In reply to dentament from comment #64)
> > Hi,
> > I boot with 2 cpus, acpi and everything working on ubuntu 10.04 using grub
> > 1.
https://bugzilla.kernel.org/show_bug.cgi?id=13170
--- Comment #73 from morten vermund (mortenverm...@gmail.com) ---
(In reply to Alex Murray from comment #40)
> It may not be relevant, but apparently the same non-bootable issue has been
> seen on the MacBook Air 2,1 - which was solved (ie. without
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 suggestions from Daniel
> v3:
> (Daniel)
>
Friendly ping to the AMD people. Nicholas, Harry, Alex, any feedback?
Would be great to get this in sooner than later.
Thanks and have a nice weekend,
-mario
On Fri, Mar 19, 2021 at 10:03 PM Mario Kleiner
wrote:
>
> Hi,
>
> this patch series adds the fourcc's for 16 bit fixed point unorm
> frame
On Mon, Mar 22, 2021 at 4:52 PM Ville Syrjälä
wrote:
>
> On Fri, Mar 19, 2021 at 10:03:12PM +0100, Mario Kleiner wrote:
> > Hi,
> >
> > this patch series adds the fourcc's for 16 bit fixed point unorm
> > framebuffers to the core, and then an implementation for AMD gpu's
> > with DisplayCore.
> >
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 applications that have problems.
Signed-off-by: Peter Enderborg
---
Am 16.04.21 um 16:37 schrieb Lee Jones:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:685: warning: expecting prototype for
cs_parser_fini(). Prototype was for amdgpu_cs_parser_fini() instead
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:1502: warning: exp
Am 16.04.21 um 16:37 schrieb Lee Jones:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:169: warning: Function parameter or
member 'sched_score' not described in 'amdgpu_ring_init'
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel
Am 16.04.21 um 16:37 schrieb Lee Jones:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:311: warning: expecting prototype for
amdgpu_copy_ttm_mem_to_mem(). Prototype was for amdgpu_ttm_copy_mem_to_mem()
instead
Cc: Alex Deucher
Cc: "Christian König"
Am 16.04.21 um 16:37 schrieb Lee Jones:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c:73: warning: expecting prototype for
amdgpu_dummy_page_init(). Prototype was for amdgpu_gart_dummy_page_init()
instead
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c:
Am 16.04.21 um 16:37 schrieb Lee Jones:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:444: warning: Function parameter or
member 'sched_score' not described in 'amdgpu_fence_driver_init_ring'
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airl
Am 16.04.21 um 16:37 schrieb Lee Jones:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/radeon_device.c:1101: warning: This comment starts
with '/**', but isn't a kernel-doc comment. Refer
Documentation/doc-guide/kernel-doc.rst
Cc: Alex Deucher
Cc: "Christian König"
Reviewed-by: Nirmoy Das
On 4/16/21 4:37 PM, Lee Jones wrote:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c:73: warning: expecting prototype for
amdgpu_dummy_page_init(). Prototype was for amdgpu_gart_dummy_page_init()
instead
drivers/gpu/drm/am
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/drm/ttm/ttm_tt.c:398: warning: Function parameter or member
'num_dm
Am 16.04.21 um 16:37 schrieb Lee Jones:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/ttm/ttm_device.c:42: warning: Function parameter or member
'ttm_global_mutex' not described in 'DEFINE_MUTEX'
drivers/gpu/drm/ttm/ttm_device.c:42: warning: expecting prototype for
ttm_g
Am 16.04.21 um 16:37 schrieb Lee Jones:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/ttm/ttm_bo.c:293: warning: expecting prototype for function
ttm_bo_cleanup_refs(). Prototype was for ttm_bo_cleanup_refs() instead
Cc: Christian Koenig
Cc: Huang Rui
Cc: David Airlie
C
Hey Adrien,
On Fri, 16 Apr 2021 at 14:02, Adrien Grassein wrote:
>
> Hi Robert,
>
> Could you please have a look at this patch?
> It has been reviewed by the bug reporter and another person.
>
> I don't receive any "merged" message.
>
> Thanks a lot,
> Adrien
>
> Le mer. 31 mars 2021 à 16:42, Dan
The pull request you sent on Fri, 16 Apr 2021 15:32:40 +0200:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-04-16
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/2f7b98d1e55ccd34e4998bf5f321ec7b9d6b451b
Thank you!
--
Deet-doot-dot, I am a bot.
https://k
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_info/drm_dbg; userspace likely doesn't care
On Fri, 16 Apr 2021, Krzysztof Kozlowski wrote:
> On 16/04/2021 16:37, Lee Jones wrote:
> > Fixes the following W=1 kernel build warning(s):
> >
> > drivers/gpu/drm/exynos/exynos_drm_fimd.c:734: warning: expecting prototype
> > for shadow_protect_win(). Prototype was for fimd_shadow_protect_win
Hi Lee,
Thank you for the patch.
On Fri, Apr 16, 2021 at 03:37:06PM +0100, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/xlnx/zynqmp_dp.c:806: warning: expecting prototype for
> zynqmp_dp_link_train(). Prototype was for zynqmp_dp_train() instead
>
> C
Hi Lee,
Thank you for the patch.
On Fri, Apr 16, 2021 at 03:37:05PM +0100, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/xlnx/zynqmp_disp.c:101: warning: expecting prototype for
> enum zynqmp_disp_id. Prototype was for enum zynqmp_disp_layer_id instead
On 16/04/2021 16:37, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/exynos/exynos_drm_ipp.c:105: warning: expecting prototype
> for exynos_drm_ipp_ioctl_get_res_ioctl(). Prototype was for
> exynos_drm_ipp_get_res_ioctl() instead
> drivers/gpu/drm/exynos
+Cc: Greg.
Greg, can you pick up this one?
The subsystem seems orphaned and I see your name in the git history for the
recent submissions against that driver.
Id is 20210409164140.17337-1-andriy.shevche...@linux.intel.com
On Fri, Apr 09, 2021 at 07:41:40PM +0300, Andy Shevchenko wrote:
> After
On 16/04/2021 16:37, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/exynos/exynos7_drm_decon.c:355: warning: expecting prototype
> for shadow_protect_win(). Prototype was for decon_shadow_protect_win() instead
>
> Cc: Inki Dae
> Cc: Joonyoung Shim
> Cc
On 16/04/2021 16:37, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/exynos/exynos_drm_fimd.c:734: warning: expecting prototype
> for shadow_protect_win(). Prototype was for fimd_shadow_protect_win() instead
>
> Cc: Inki Dae
> Cc: Joonyoung Shim
> Cc: S
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:685: warning: expecting prototype for
cs_parser_fini(). Prototype was for amdgpu_cs_parser_fini() instead
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:1502: warning: expecting prototype for
amdgpu_cs_wait_all_fen
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/exynos/exynos_drm_fimd.c:734: warning: expecting prototype for
shadow_protect_win(). Prototype was for fimd_shadow_protect_win() instead
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: David Airlie
Cc:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c:33: warning: This
comment starts with '/**', but isn't a kernel-doc comment. Refer
Documentation/doc-guide/kernel-doc.rst
Cc: Thierry Reding
Cc: Sam Ravnborg
Cc: David Airlie
Cc: Daniel Ve
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/exynos/exynos_drm_ipp.c:105: warning: expecting prototype for
exynos_drm_ipp_ioctl_get_res_ioctl(). Prototype was for
exynos_drm_ipp_get_res_ioctl() instead
drivers/gpu/drm/exynos/exynos_drm_ipp.c:153: warning: expecting prototyp
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/vgem/vgem_drv.c:29: warning: This comment starts with '/**',
but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
Cc: David Airlie
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: "Christian König"
Cc: Adam Jacks
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/ttm/ttm_device.c:42: warning: Function parameter or member
'ttm_global_mutex' not described in 'DEFINE_MUTEX'
drivers/gpu/drm/ttm/ttm_device.c:42: warning: expecting prototype for
ttm_global_mutex(). Prototype was for DEFINE_MUTE
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/panel/panel-sitronix-st7701.c:42: warning: This comment starts
with '/**', but isn't a kernel-doc comment. Refer
Documentation/doc-guide/kernel-doc.rst
Cc: Jagan Teki
Cc: Thierry Reding
Cc: Sam Ravnborg
Cc: David Airlie
Cc: D
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c:73: warning: expecting prototype for
amdgpu_dummy_page_init(). Prototype was for amdgpu_gart_dummy_page_init()
instead
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c:96: warning: expecting prototype for
amdgpu
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:169: warning: Function parameter or
member 'sched_score' not described in 'amdgpu_ring_init'
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: amd-...@list
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c: In function
‘amdgpu_device_suspend’:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:3733:6: warning: variable ‘r’ set
but not used [-Wunused-but-set-variable]
Cc: Alex Deucher
Cc: "Christian König"
Cc:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:311: warning: expecting prototype for
amdgpu_copy_ttm_mem_to_mem(). Prototype was for amdgpu_ttm_copy_mem_to_mem()
instead
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/sti/sti_hdmi.c:193: warning: expecting prototype for HDMI
interrupt handler threaded(). Prototype was for hdmi_irq_thread() instead
drivers/gpu/drm/sti/sti_hdmi.c:225: warning: expecting prototype for HDMI
interrupt handler(). Pr
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/exynos/exynos7_drm_decon.c:355: warning: expecting prototype
for shadow_protect_win(). Prototype was for decon_shadow_protect_win() instead
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: David Airlie
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/mediatek/mtk_disp_ccorr.c:46: warning: Function parameter or
member 'clk' not described in 'mtk_disp_ccorr'
drivers/gpu/drm/mediatek/mtk_disp_ccorr.c:46: warning: Function parameter or
member 'regs' not described in 'mtk_disp_cco
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/drm/ttm/ttm_tt.c:398: warning: Function parameter or member
'num_dma32_pages' not described in 'ttm_tt_mgr_init'
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/radeon_device.c:1101: warning: This comment starts with
'/**', but isn't a kernel-doc comment. Refer
Documentation/doc-guide/kernel-doc.rst
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:444: warning: Function parameter or
member 'sched_score' not described in 'amdgpu_fence_driver_init_ring'
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/scheduler/sched_entity.c:204: warning: expecting prototype for
drm_sched_entity_kill_jobs(). Prototype was for drm_sched_entity_kill_jobs_cb()
instead
drivers/gpu/drm/scheduler/sched_entity.c:262: warning: expecting prototype for
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/ttm/ttm_bo.c:293: warning: expecting prototype for function
ttm_bo_cleanup_refs(). Prototype was for ttm_bo_cleanup_refs() instead
Cc: Christian Koenig
Cc: Huang Rui
Cc: David Airlie
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: dri
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/xlnx/zynqmp_dp.c:806: warning: expecting prototype for
zynqmp_dp_link_train(). Prototype was for zynqmp_dp_train() instead
Cc: Hyun Kwon
Cc: Laurent Pinchart
Cc: David Airlie
Cc: Daniel Vetter
Cc: Michal Simek
Cc: Philipp Zab
Fixes the following W=1 kernel build warning(s):
drivers/gpu/host1x/bus.c:774: warning: Excess function parameter 'key'
description in '__host1x_client_register'
Cc: Thierry Reding
Cc: dri-devel@lists.freedesktop.org
Cc: linux-te...@vger.kernel.org
Signed-off-by: Lee Jones
---
drivers/gpu/ho
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/omapdrm/omap_gem.c:619: warning: expecting prototype for
omap_gem_dumb_map(). Prototype was for omap_gem_dumb_map_offset() instead
Cc: Tomi Valkeinen
Cc: David Airlie
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: "Christian König"
C
1 - 100 of 199 matches
Mail list logo
