[radeon-alex:drm-next 448/499] drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_hw_lock_mgr.c:36:8: warning: missing braces around initializer
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next
head: 7aebbbd59a2ee62e3b75d7e8e3617171c3c6a208
commit: 4dc079787b23524c4d88a21bc25db29e9e525eb2 [448/499] drm/amd/display: Use
dmub fw to lock pipe, cursor, dig
config: i386-randconfig-a014-20200624 (attached as .config)
compiler: gcc-4.9 (Ubuntu 4.9.3-13ubuntu2) 4.9.3
reproduce (this is a W=1 build):
git checkout 4dc079787b23524c4d88a21bc25db29e9e525eb2
# save the attached .config to linux build tree
make W=1 ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
In file included from
drivers/gpu/drm/amd/amdgpu/../display/dmub/dmub_srv.h:67:0,
from
drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dmub_srv.h:30,
from
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_hw_lock_mgr.h:29,
from
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_hw_lock_mgr.c:26:
drivers/gpu/drm/amd/amdgpu/../display/dmub/inc/dmub_cmd.h: In function
'dmub_rb_flush_pending':
drivers/gpu/drm/amd/amdgpu/../display/dmub/inc/dmub_cmd.h:752:12: warning:
variable 'temp' set but not used [-Wunused-but-set-variable]
uint64_t temp;
^
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_hw_lock_mgr.c: In function
'dmub_hw_lock_mgr_cmd':
>> drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_hw_lock_mgr.c:36:8:
>> warning: missing braces around initializer [-Wmissing-braces]
union dmub_rb_cmd cmd = { 0 };
^
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_hw_lock_mgr.c:36:8:
warning: (near initialization for 'cmd.lock_hw') [-Wmissing-braces]
--
In file included from
drivers/gpu/drm/amd/amdgpu/../display/dmub/dmub_srv.h:67:0,
from
drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dmub_srv.h:30,
from
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_hwseq.c:52:
drivers/gpu/drm/amd/amdgpu/../display/dmub/inc/dmub_cmd.h: In function
'dmub_rb_flush_pending':
drivers/gpu/drm/amd/amdgpu/../display/dmub/inc/dmub_cmd.h:752:12: warning:
variable 'temp' set but not used [-Wunused-but-set-variable]
uint64_t temp;
^
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_hwseq.c: At top level:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_hwseq.c:1081:6:
warning: no previous prototype for 'dcn20_enable_plane' [-Wmissing-prototypes]
void dcn20_enable_plane(
^
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_hwseq.c: In function
'dcn20_pipe_control_lock':
>> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_hwseq.c:1200:9:
>> warning: missing braces around initializer [-Wmissing-braces]
union dmub_hw_lock_flags hw_locks = { 0 };
^
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_hwseq.c:1200:9:
warning: (near initialization for 'hw_locks.bits') [-Wmissing-braces]
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_hwseq.c: In function
'dcn20_update_dchubp_dpp':
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_hwseq.c:1369:7:
warning: variable 'viewport_changed' set but not used
[-Wunused-but-set-variable]
bool viewport_changed = false;
^
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_hwseq.c: At top level:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_hwseq.c:2200:6:
warning: no previous prototype for 'dcn20_get_mpctree_visual_confirm_color'
[-Wmissing-prototypes]
void dcn20_get_mpctree_visual_confirm_color(
^
--
In file included from
drivers/gpu/drm/amd/amdgpu/../display/dmub/dmub_srv.h:67:0,
from
drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dmub_srv.h:30,
from drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:61:
drivers/gpu/drm/amd/amdgpu/../display/dmub/inc/dmub_cmd.h: In function
'dmub_rb_flush_pending':
drivers/gpu/drm/amd/amdgpu/../display/dmub/inc/dmub_cmd.h:752:12: warning:
variable 'temp' set but not used [-Wunused-but-set-variable]
uint64_t temp;
^
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c: At top level:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:777:6: warning: no
previous prototype for 'apply_ctx_interdependent_lock' [-Wmissing-prototypes]
void apply_ctx_interdependent_lock(struct dc *dc, struct dc_state *context,
struct dc_stream_state *stream, bool lock)
^
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c: In function
'commit_planes_for_stream':
>> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:2328:11: warning: missing
>> braces around initializer [-Wmissing-braces]
union dmub_hw_lock_flags hw_locks = { 0 };
^
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:2328:11: warning: (near
initialization for 'hw_locks.bits') [-Wmissing-braces]
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:2513:11: warning: missi
Re: [Intel-gfx] [PATCH 1/2] Revert "dma-buf: Report signaled links inside dma-fence-chain"
On Fri, 26 Jun 2020 at 01:24, Daniel Vetter wrote: > > Ignoring everything else ... > > On Thu, Jun 25, 2020 at 9:28 PM Jani Nikula > wrote: > > As a side note, there seem to be extra checks in place for acks when > > applying non-i915 patches to drm-intel; there are no such checks for > > drm-misc. > > One option to generalize that that I pondered is to consult > get_maintainers.pl asking for git repo link, and if that returns > something else, then insist that there's an ack from a relevant > maintainer. It's a bit of typing, but I think the bigger problem is > that there's a ton of false positives. Right; for the particular patch, I wasn't even in the to: or cc: field and that made it slip from my radar. I would definitely ask any one sending patches for dma-buf directory to follow the get_maintainers.pl religiously. > > But maybe that's a good thing, would give some motivation to keep > MAINTAINERS updated. > > The other issue is though that drm-misc is plenty used to merge > patches even when the respective maintainers are absent for weeks, or > unresponsive. If we just blindly implement that rule, then the only > possible Ack for these would be Dave&me as subsystem maintainers, and > I don't want to be in the business of stamping approvals for all this > stuff. Much better if people just collaborate. > > So I think an ack check would be nice, but probably not practical. > > Plus in this situation here drm-misc.git actually is the main repo, > and we wont ever be able to teach a script to make a judgement call of > whether that patch has the right amount of review on it. > -Daniel Best, Sumit. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm fixes for v5.8-rc3
Hi Linus, Usual rc3 pickup, lots of little fixes all over, The core VT registration regression fix is probably the largest, otherwise ttm, amdgpu and tegra are the bulk, with some minor driver fixes. No i915 pull this week which may or may not mean I get 2x of it next week, we'll see how it goes. Regards, Dave. drm-fixes-2020-06-26: drm fixes for v5.8-rc3 core: - fix VT registration regression ttm: - fix two fence leaks amdgpu: - Fix missed mutex unlock in DC error path - Fix firmware leak for sdma5 - DC bpc property fixes amdkfd: - Fix memleak in an error path radeon: - Fix copy paste typo in NI DPM spll validation rcar-du: - build fix tegra: - add missing zpos property - child driver registration fix - debugfs cleanup fix - doc fix mcde: - reorder fbdev setup panel: - fix connector type - fix orientation for some panels sun4i: - fix dma/iommu configuration uvesafb: - respect blank flag The following changes since commit 48778464bb7d346b47157d21ffde2af6b2d39110: Linux 5.8-rc2 (2020-06-21 15:45:29 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-06-26 for you to fetch changes up to 687a0ed337367be5267652af5f6dbcfc954b8732: Merge tag 'drm-misc-fixes-2020-06-25' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2020-06-26 13:49:17 +1000) drm fixes for v5.8-rc3 core: - fix VT registration regression ttm: - fix two fence leaks amdgpu: - Fix missed mutex unlock in DC error path - Fix firmware leak for sdma5 - DC bpc property fixes amdkfd: - Fix memleak in an error path radeon: - Fix copy paste typo in NI DPM spll validation rcar-du: - build fix tegra: - add missing zpos property - child driver registration fix - debugfs cleanup fix - doc fix mcde: - reorder fbdev setup panel: - fix connector type - fix orientation for some panels sun4i: - fix dma/iommu configuration uvesafb: - respect blank flag Adam Ford (1): drm/panel-simple: fix connector type for LogicPD Type28 Display Bartlomiej Zolnierkiewicz (1): video: fbdev: uvesafb: fix "noblank" option handling Bernard Zhao (1): drm/amd: fix potential memleak in err branch Christophe JAILLET (1): gpu: host1x: Clean up debugfs in error handling path Colton Lewis (1): gpu: host1x: Correct trivial kernel-doc inconsistencies Daniel Gomez (1): drm: rcar-du: Fix build error Daniel Vetter (1): drm/fb-helper: Fix vt restore Dave Airlie (4): Merge tag 'du-fixes-20200621' of git://linuxtv.org/pinchartl/media into drm-fixes Merge tag 'drm/tegra/for-5.8-rc3' of git://anongit.freedesktop.org/tegra/linux into drm-fixes Merge tag 'amd-drm-fixes-5.8-2020-06-24' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Merge tag 'drm-misc-fixes-2020-06-25' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Denis Efremov (1): drm/radeon: fix fb_div check in ni_init_smc_spll_table() Hans de Goede (2): drm: panel-orientation-quirks: Add quirk for Asus T101HA panel drm: panel-orientation-quirks: Use generic orientation-data for Acer S1003 John van der Kamp (1): drm/amdgpu/display: Unlock mutex on error Linus Walleij (2): drm: mcde: Fix display initialization problem drm: mcde: Fix forgotten user of drm->dev_private Maxime Ripard (1): drm/sun4i: mixer: Call of_dma_configure if there's an IOMMU Nicolin Chen (1): drm/tegra: hub: Do not enable orphaned window group Stylon Wang (2): drm/amd/display: Enable output_bpc property on all outputs drm/amd/display: Fix ineffective setting of max bpc property Thierry Reding (4): gpu: host1x: Register child devices drm/tegra: hub: Register child devices gpu: host1x: Detach driver on unregister drm/tegra: Add zpos property for cursor planes Thomas Zimmermann (1): Merge v5.8-rc1 into drm-misc-fixes Tomi Valkeinen (1): drm/panel-simple: fix connector type for newhaven_nhd_43_480272ef_atxl Wenhui Sheng (1): drm/amdgpu: add fw release for sdma v5_0 Xiyu Yang (2): drm/ttm: Fix dma_fence refcnt leak in ttm_bo_vm_fault_reserved drm/ttm: Fix dma_fence refcnt leak when adding move fence drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c | 6 ++- drivers/gpu/drm/amd/amdkfd/kfd_process.c | 1 + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +- .../drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 4 +- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_hdcp.c | 6 ++- drivers/gpu/drm/drm_fb_helper.c| 63 +- drivers/gpu/drm/drm_panel_orientation_quirks.c | 14 ++--- drivers/gpu/drm/mcde/mcde_display.c| 2 +- drivers/gpu/drm/mcde/mcde_drv.c| 3 +- drivers/gpu/drm/panel/panel-simple.c | 2 + drivers/gpu/drm/radeon/n
Re: linux-next: build failure after merge of the amdgpu tree
Hi all,
On Fri, 12 Jun 2020 10:25:52 +1000 Stephen Rothwell
wrote:
>
> After merging the amdgpu tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_process.c: In function
> 'kfd_sdma_activity_worker':
> drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_process.c:118:2: error: implicit
> declaration of function 'use_mm' [-Werror=implicit-function-declaration]
> 118 | use_mm(mm);
> | ^~
> drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_process.c:145:2: error: implicit
> declaration of function 'unuse_mm' [-Werror=implicit-function-declaration]
> 145 | unuse_mm(mm);
> | ^~~~
>
> Caused by commit
>
> 32cb59f31362 ("drm/amdkfd: Track SDMA utilization per process")
>
> interacting with commit
>
> f5678e7f2ac3 ("kernel: better document the use_mm/unuse_mm API contract")
>
> from Linus' tree.
>
> I have applied the following merge fix for today (that was previously
> part of the akpm tree).
The merge fix patch now looks like:
From: Stephen Rothwell
Date: Thu, 28 May 2020 20:15:34 +1000
Subject: [PATCH] drm/amdkfd: fix up for {un}use_mm() rename
Signed-off-by: Stephen Rothwell
---
drivers/gpu/drm/amd/amdkfd/kfd_process.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
index 013c2b018edc..40695d52e9a8 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
@@ -184,7 +184,7 @@ static void kfd_sdma_activity_worker(struct work_struct
*work)
if (!mm)
goto cleanup;
- use_mm(mm);
+ kthread_use_mm(mm);
list_for_each_entry(sdma_q, &sdma_q_list.list, list) {
val = 0;
@@ -198,7 +198,7 @@ static void kfd_sdma_activity_worker(struct work_struct
*work)
}
}
- unuse_mm(mm);
+ kthread_unuse_mm(mm);
mmput(mm);
/*
--
Cheers,
Stephen Rothwell
pgpOrH7Wvr6Ws.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: manual merge of the drm-misc tree with Linus' tree
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c
between commit:
eaad0c3aa978 ("drm/amdgpu: rename direct to immediate for VM updates")
from the Linus' and commit:
b1a8ef952a25 ("drm/amdgpu: move ttm bo->offset to amdgpu_bo")
from the drm-misc tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c
index 28bdfb3ac33d,2a7a6f62d627..
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c
@@@ -144,8 -141,8 +144,8 @@@ static void amdgpu_vm_sdma_copy_ptes(st
src += p->num_dw_left * 4;
- pe += amdgpu_gmc_sign_extend(bo->tbo.offset);
+ pe += amdgpu_bo_gpu_offset_no_check(bo);
- trace_amdgpu_vm_copy_ptes(pe, src, count, p->direct);
+ trace_amdgpu_vm_copy_ptes(pe, src, count, p->immediate);
amdgpu_vm_copy_pte(p->adev, ib, pe, src, count);
}
@@@ -171,8 -168,8 +171,8 @@@ static void amdgpu_vm_sdma_set_ptes(str
{
struct amdgpu_ib *ib = p->job->ibs;
- pe += amdgpu_gmc_sign_extend(bo->tbo.offset);
+ pe += amdgpu_bo_gpu_offset_no_check(bo);
- trace_amdgpu_vm_set_ptes(pe, addr, count, incr, flags, p->direct);
+ trace_amdgpu_vm_set_ptes(pe, addr, count, incr, flags, p->immediate);
if (count < 3) {
amdgpu_vm_write_pte(p->adev, ib, pe, addr | flags,
count, incr);
pgp_2IxchcT6T.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 1/2] Revert "dma-buf: Report signaled links inside dma-fence-chain"
On Fri, 26 Jun 2020 at 05:27, Jani Nikula wrote: > > On Fri, 26 Jun 2020, Dave Airlie wrote: > > WTUF? > > > > How did this ever land in my tree, there is no ACK on this from anyone > > in core dma-buf, > > > > Intel team, clean your house up here, I'm going to have to ask you to > > stop Chris merging stuff without oversight, if this sort of thing > > happens, this is totally unacceptable. > > There's no argument, an ack is required. > > In fairness to the i915 maintainers, though, this particular commit was > merged via drm-misc-next [1]. > > As a side note, there seem to be extra checks in place for acks when > applying non-i915 patches to drm-intel; there are no such checks for > drm-misc. Sorry Jani, thanks for chasing that down. drm-misc we need to oversight a bit more, I don't think we should be landing things that affect core code with single company acks. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-staging-drm-next 9951/9999] drivers/gpu/drm/amd/amdgpu/uvd_v3_1.c:243:16: sparse: sparse: cast to restricted __le32
Hi Sonny, First bad commit (maybe != root cause): tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next head: cd5dd023c24f097393cd351bfaaba81284d1a15b commit: 788c2ef8c423ccd8c62a471c7e7debe115b3e124 [9951/] drm amdgpu: SI UVD add uvd_v3_1 to makefile config: s390-randconfig-s032-20200624 (attached as .config) compiler: s390-linux-gcc (GCC) 9.3.0 reproduce: # apt-get install sparse # sparse version: v0.6.2-dirty git checkout 788c2ef8c423ccd8c62a471c7e7debe115b3e124 # save the attached .config to linux build tree make W=1 C=1 ARCH=s390 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) drivers/gpu/drm/amd/amdgpu/../include/asic_reg/oss/oss_1_0_sh_mask.h:26:9: sparse: sparse: preprocessor token CC_DRM_ID_STRAPS__ATI_REV_ID_MASK redefined drivers/gpu/drm/amd/amdgpu/sid.h:2471:9: sparse: this was the original definition drivers/gpu/drm/amd/amdgpu/../include/asic_reg/oss/oss_1_0_sh_mask.h:27:9: sparse: sparse: preprocessor token CC_DRM_ID_STRAPS__ATI_REV_ID__SHIFT redefined drivers/gpu/drm/amd/amdgpu/sid.h:2472:9: sparse: this was the original definition drivers/gpu/drm/amd/amdgpu/../include/asic_reg/oss/oss_1_0_sh_mask.h:744:9: sparse: sparse: preprocessor token IH_RB_CNTL__WPTR_OVERFLOW_CLEAR_MASK redefined drivers/gpu/drm/amd/amdgpu/sid.h:2345:9: sparse: this was the original definition drivers/gpu/drm/amd/amdgpu/../include/asic_reg/oss/oss_1_0_sh_mask.h:760:9: sparse: sparse: preprocessor token IH_RB_WPTR__RB_OVERFLOW_MASK redefined drivers/gpu/drm/amd/amdgpu/sid.h:2344:9: sparse: this was the original definition drivers/gpu/drm/amd/amdgpu/../include/asic_reg/oss/oss_1_0_sh_mask.h:988:9: sparse: sparse: preprocessor token SRBM_SOFT_RESET__SOFT_RESET_IH_MASK redefined drivers/gpu/drm/amd/amdgpu/sid.h:2347:9: sparse: this was the original definition drivers/gpu/drm/amd/amdgpu/../include/asic_reg/oss/oss_1_0_sh_mask.h:1028:9: sparse: sparse: preprocessor token SRBM_STATUS__IH_BUSY_MASK redefined drivers/gpu/drm/amd/amdgpu/sid.h:2346:9: sparse: this was the original definition drivers/gpu/drm/amd/amdgpu/../include/asic_reg/oss/oss_1_0_sh_mask.h:1032:9: sparse: sparse: preprocessor token SRBM_STATUS__MCB_BUSY_MASK redefined drivers/gpu/drm/amd/amdgpu/sid.h:2435:9: sparse: this was the original definition drivers/gpu/drm/amd/amdgpu/../include/asic_reg/oss/oss_1_0_sh_mask.h:1033:9: sparse: sparse: preprocessor token SRBM_STATUS__MCB_BUSY__SHIFT redefined drivers/gpu/drm/amd/amdgpu/sid.h:2436:9: sparse: this was the original definition drivers/gpu/drm/amd/amdgpu/../include/asic_reg/oss/oss_1_0_sh_mask.h:1034:9: sparse: sparse: preprocessor token SRBM_STATUS__MCB_NON_DISPLAY_BUSY_MASK redefined drivers/gpu/drm/amd/amdgpu/sid.h:2437:9: sparse: this was the original definition drivers/gpu/drm/amd/amdgpu/../include/asic_reg/oss/oss_1_0_sh_mask.h:1035:9: sparse: sparse: preprocessor token SRBM_STATUS__MCB_NON_DISPLAY_BUSY__SHIFT redefined drivers/gpu/drm/amd/amdgpu/sid.h:2438:9: sparse: this was the original definition drivers/gpu/drm/amd/amdgpu/../include/asic_reg/oss/oss_1_0_sh_mask.h:1036:9: sparse: sparse: preprocessor token SRBM_STATUS__MCC_BUSY_MASK redefined drivers/gpu/drm/amd/amdgpu/sid.h:2439:9: sparse: this was the original definition drivers/gpu/drm/amd/amdgpu/../include/asic_reg/oss/oss_1_0_sh_mask.h:1037:9: sparse: sparse: preprocessor token SRBM_STATUS__MCC_BUSY__SHIFT redefined drivers/gpu/drm/amd/amdgpu/sid.h:2440:9: sparse: this was the original definition drivers/gpu/drm/amd/amdgpu/../include/asic_reg/oss/oss_1_0_sh_mask.h:1038:9: sparse: sparse: preprocessor token SRBM_STATUS__MCD_BUSY_MASK redefined drivers/gpu/drm/amd/amdgpu/sid.h:2441:9: sparse: this was the original definition drivers/gpu/drm/amd/amdgpu/../include/asic_reg/oss/oss_1_0_sh_mask.h:1039:9: sparse: sparse: preprocessor token SRBM_STATUS__MCD_BUSY__SHIFT redefined drivers/gpu/drm/amd/amdgpu/sid.h:2442:9: sparse: this was the original definition drivers/gpu/drm/amd/amdgpu/../include/asic_reg/oss/oss_1_0_sh_mask.h:1048:9: sparse: sparse: preprocessor token SRBM_STATUS__VMC_BUSY_MASK redefined drivers/gpu/drm/amd/amdgpu/sid.h:2443:9: sparse: this was the original definition drivers/gpu/drm/amd/amdgpu/../include/asic_reg/oss/oss_1_0_sh_mask.h:1049:9: sparse: sparse: preprocessor token SRBM_STATUS__VMC_BUSY__SHIFT redefined drivers/gpu/drm/amd/amdgpu/sid.h:2444:9: sparse: this was the original definition >> drivers/gpu/drm/amd/amdgpu/uvd_v3_1.c:243:16: sparse: sparse: cast to >> restricted __le32 >> drivers/gpu/drm/amd/amdgpu/uvd_v3_1.c:243:16: sparse: sparse: cast to >> restricted __le32 >> drivers/gpu/drm/amd/amdgpu/uvd_v3_1.c:243:16: sparse: sparse: cast to >> restricted __le32 >> drivers/gpu/drm/amd/amdgp
[PATCH] backlight: lms501kf03: Drop unused include
This driver includes but does not use any symbols from that file, drop the include. Signed-off-by: Linus Walleij --- drivers/video/backlight/lms501kf03.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/video/backlight/lms501kf03.c b/drivers/video/backlight/lms501kf03.c index 8ae32e3573c1..52d3ee6c3f7f 100644 --- a/drivers/video/backlight/lms501kf03.c +++ b/drivers/video/backlight/lms501kf03.c @@ -9,7 +9,6 @@ #include #include #include -#include #include #include #include -- 2.25.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5] backlight: lms283gf05: Convert to GPIO descriptors
This converts the lms283gf05 backlight driver to use GPIO
descriptors and switches the single PXA Palm Z2 device
over to defining these.
Since the platform data was only used to convey GPIO
information we can delete the platform data header.
Notice that we define the proper active low semantics in
the board file GPIO descriptor table (active low) and
assert the reset line by bringing it to "1" (asserted).
Cc: Marek Vasut
Cc: Daniel Mack
Cc: Haojian Zhuang
Cc: Robert Jarzmik
Reviewed-by: Daniel Thompson
Signed-off-by: Linus Walleij
---
ChangeLog v4->v5:
- Rebase on v5.8-rc1
- Collected Daniel's Reviewed-by tag.
ChangeLog v3->v4:
- Check IS_ERR() on the returned GPIO descriptor.
- Unconditionally set consumer name since the API tolerates NULL.
ChangeLog v2->v3:
- Fix a use-before-allocated bug discovered by compile tests.
- Remove unused ret variable as autobuilders complained.
ChangeLog v1->v2:
- Bring up the GPIO de-asserted in probe()
Marek: I saw this was written by you, are you regularly
testing the Z2 device?
---
arch/arm/mach-pxa/z2.c | 12 +---
drivers/video/backlight/lms283gf05.c | 43 +++-
include/linux/spi/lms283gf05.h | 16 ---
3 files changed, 25 insertions(+), 46 deletions(-)
delete mode 100644 include/linux/spi/lms283gf05.h
diff --git a/arch/arm/mach-pxa/z2.c b/arch/arm/mach-pxa/z2.c
index 21fd76bb09cd..89eb5243c85f 100644
--- a/arch/arm/mach-pxa/z2.c
+++ b/arch/arm/mach-pxa/z2.c
@@ -20,7 +20,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -578,8 +577,13 @@ static struct pxa2xx_spi_chip lms283_chip_info = {
.gpio_cs= GPIO88_ZIPITZ2_LCD_CS,
};
-static const struct lms283gf05_pdata lms283_pdata = {
- .reset_gpio = GPIO19_ZIPITZ2_LCD_RESET,
+static struct gpiod_lookup_table lms283_gpio_table = {
+ .dev_id = "spi2.0", /* SPI bus 2 chip select 0 */
+ .table = {
+ GPIO_LOOKUP("gpio-pxa", GPIO19_ZIPITZ2_LCD_RESET,
+ "reset", GPIO_ACTIVE_LOW),
+ { },
+ },
};
static struct spi_board_info spi_board_info[] __initdata = {
@@ -595,7 +599,6 @@ static struct spi_board_info spi_board_info[] __initdata = {
{
.modalias = "lms283gf05",
.controller_data= &lms283_chip_info,
- .platform_data = &lms283_pdata,
.max_speed_hz = 40,
.bus_num= 2,
.chip_select= 0,
@@ -615,6 +618,7 @@ static void __init z2_spi_init(void)
{
pxa2xx_set_spi_info(1, &pxa_ssp1_master_info);
pxa2xx_set_spi_info(2, &pxa_ssp2_master_info);
+ gpiod_add_lookup_table(&lms283_gpio_table);
spi_register_board_info(spi_board_info, ARRAY_SIZE(spi_board_info));
}
#else
diff --git a/drivers/video/backlight/lms283gf05.c
b/drivers/video/backlight/lms283gf05.c
index 0e45685bcc1c..36856962ed83 100644
--- a/drivers/video/backlight/lms283gf05.c
+++ b/drivers/video/backlight/lms283gf05.c
@@ -9,16 +9,16 @@
#include
#include
#include
-#include
+#include
#include
#include
-#include
#include
struct lms283gf05_state {
struct spi_device *spi;
struct lcd_device *ld;
+ struct gpio_desc*reset;
};
struct lms283gf05_seq {
@@ -90,13 +90,13 @@ static const struct lms283gf05_seq disp_pdwnseq[] = {
};
-static void lms283gf05_reset(unsigned long gpio, bool inverted)
+static void lms283gf05_reset(struct gpio_desc *gpiod)
{
- gpio_set_value(gpio, !inverted);
+ gpiod_set_value(gpiod, 0); /* De-asserted */
mdelay(100);
- gpio_set_value(gpio, inverted);
+ gpiod_set_value(gpiod, 1); /* Asserted */
mdelay(20);
- gpio_set_value(gpio, !inverted);
+ gpiod_set_value(gpiod, 0); /* De-asserted */
mdelay(20);
}
@@ -125,18 +125,15 @@ static int lms283gf05_power_set(struct lcd_device *ld,
int power)
{
struct lms283gf05_state *st = lcd_get_data(ld);
struct spi_device *spi = st->spi;
- struct lms283gf05_pdata *pdata = dev_get_platdata(&spi->dev);
if (power <= FB_BLANK_NORMAL) {
- if (pdata)
- lms283gf05_reset(pdata->reset_gpio,
- pdata->reset_inverted);
+ if (st->reset)
+ lms283gf05_reset(st->reset);
lms283gf05_toggle(spi, disp_initseq, ARRAY_SIZE(disp_initseq));
} else {
lms283gf05_toggle(spi, disp_pdwnseq, ARRAY_SIZE(disp_pdwnseq));
- if (pdata)
- gpio_set_value(pdata->reset_gpio,
- pdata->reset_inverted);
+ if (st->reset)
+ gpiod_set_value(st->reset, 1); /* Asserted */
}
return 0;
@@ -150,24 +147,18 @@ static struct lcd_ops lms_ops = {
static int lms283gf05_probe(struct spi_device *spi)
{
Re: [v9 2/3] drm/debug: Expose connector VRR monitor range via debugfs
Thanks Bhanu for the patch, merged to drm-misc
Manasi
On Mon, Jun 22, 2020 at 07:55:18PM +0530, Bhanuprakash Modem wrote:
> [Why]
> It's useful to know the min and max vrr range for IGT testing.
>
> [How]
> Expose the min and max vfreq for the connector via a debugfs file
> on the connector, "vrr_range".
>
> Example usage: cat /sys/kernel/debug/dri/0/DP-1/vrr_range
>
> v2:
> * Fix the typo in max_vfreq (Manasi)
> * Change the name of node to i915_vrr_info so we can add
> other vrr info for more debug info (Manasi)
> * Change the VRR capable to display Yes or No (Manasi)
> * Fix indentation checkpatch errors (Manasi)
> v3:
> * Remove the unnecessary debug print (Manasi)
> v4:
> * Rebase
> v5:
> * Rename to vrr_range to match AMD debugfs
> v6:
> * Rebase (manasi)
> v7:
> * Fix cmpilation due to rebase
> v8:
> * Move debugfs node creation logic to DRM (Emil)
> * Remove AMD specific logic (Emil)
> v9:
> * Seperate patch for removal of AMD specific logic (Manasi)
>
> Signed-off-by: Bhanuprakash Modem
> Signed-off-by: Manasi Navare
> Cc: Jani Nikula
> Cc: Ville Syrjälä
> Cc: Harry Wentland
> CC: Emil Velikov
> ---
> drivers/gpu/drm/drm_debugfs.c | 22 ++
> 1 file changed, 22 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> index bfe4602f206b..3d7182001004 100644
> --- a/drivers/gpu/drm/drm_debugfs.c
> +++ b/drivers/gpu/drm/drm_debugfs.c
> @@ -376,6 +376,24 @@ static ssize_t edid_write(struct file *file, const char
> __user *ubuf,
> return (ret) ? ret : len;
> }
>
> +/*
> + * Returns the min and max vrr vfreq through the connector's debugfs file.
> + * Example usage: cat /sys/kernel/debug/dri/0/DP-1/vrr_range
> + */
> +static int vrr_range_show(struct seq_file *m, void *data)
> +{
> + struct drm_connector *connector = m->private;
> +
> + if (connector->status != connector_status_connected)
> + return -ENODEV;
> +
> + seq_printf(m, "Min: %u\n",
> (u8)connector->display_info.monitor_range.min_vfreq);
> + seq_printf(m, "Max: %u\n",
> (u8)connector->display_info.monitor_range.max_vfreq);
> +
> + return 0;
> +}
> +DEFINE_SHOW_ATTRIBUTE(vrr_range);
> +
> static const struct file_operations drm_edid_fops = {
> .owner = THIS_MODULE,
> .open = edid_open,
> @@ -413,6 +431,10 @@ void drm_debugfs_connector_add(struct drm_connector
> *connector)
> /* edid */
> debugfs_create_file("edid_override", S_IRUGO | S_IWUSR, root, connector,
> &drm_edid_fops);
> +
> + /* vrr range */
> + debugfs_create_file("vrr_range", S_IRUGO, root, connector,
> + &vrr_range_fops);
> }
>
> void drm_debugfs_connector_remove(struct drm_connector *connector)
> --
> 2.20.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-staging-drm-next 9928/9999] drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:2522:26: sparse: sparse: incorrect type in assignment (different base types)
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next head: cd5dd023c24f097393cd351bfaaba81284d1a15b commit: e060721131c59a375125f7e5202d8e2cd7462406 [9928/] drm/powerplay: label internally used symbols as static config: s390-randconfig-s032-20200624 (attached as .config) compiler: s390-linux-gcc (GCC) 9.3.0 reproduce: # apt-get install sparse # sparse version: v0.6.2-dirty git checkout e060721131c59a375125f7e5202d8e2cd7462406 # save the attached .config to linux build tree make W=1 C=1 ARCH=s390 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1479:36: sparse: expected unsigned int [usertype] McArbDramTiming drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1479:36: sparse: got restricted __be32 [usertype] drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1480:36: sparse: sparse: incorrect type in assignment (different base types) @@ expected unsigned int [usertype] McArbDramTiming2 @@ got restricted __be32 [usertype] @@ drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1480:36: sparse: expected unsigned int [usertype] McArbDramTiming2 drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1480:36: sparse: got restricted __be32 [usertype] drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1568:9: sparse: sparse: incorrect type in assignment (different base types) @@ expected unsigned short [usertype] BootMVdd @@ got restricted __be16 [usertype] @@ drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1568:9: sparse: expected unsigned short [usertype] BootMVdd drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1568:9: sparse: got restricted __be16 [usertype] drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1673:37: sparse: sparse: cast to restricted __be32 drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1689:9: sparse: sparse: incorrect type in assignment (different base types) @@ expected unsigned short [usertype] minFreq @@ got restricted __be16 [usertype] @@ drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1689:9: sparse: expected unsigned short [usertype] minFreq drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1689:9: sparse: got restricted __be16 [usertype] drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1691:9: sparse: sparse: incorrect type in assignment (different base types) @@ expected unsigned short [usertype] maxFreq @@ got restricted __be16 [usertype] @@ drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1691:9: sparse: expected unsigned short [usertype] maxFreq drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1691:9: sparse: got restricted __be16 [usertype] drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1717:38: sparse: sparse: cast to restricted __be32 drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1732:17: sparse: sparse: incorrect type in assignment (different base types) @@ expected unsigned short [usertype] setting @@ got restricted __be16 [usertype] @@ drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1732:17: sparse: expected unsigned short [usertype] setting drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1732:17: sparse: got restricted __be16 [usertype] drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1838:31: sparse: sparse: incorrect type in assignment (different base types) @@ expected unsigned short [usertype] DefaultTdp @@ got restricted __be16 [usertype] @@ drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1838:31: sparse: expected unsigned short [usertype] DefaultTdp drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1838:31: sparse: got restricted __be16 [usertype] drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1840:30: sparse: sparse: incorrect type in assignment (different base types) @@ expected unsigned short [usertype] TargetTdp @@ got restricted __be16 [usertype] @@ drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1840:30: sparse: expected unsigned short [usertype] TargetTdp drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1840:30: sparse: got restricted __be16 [usertype] drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1852:39: sparse: sparse: incorrect type in assignment (different base types) @@ expected unsigned int [usertype] BAPM_TEMP_GRADIENT @@ got restricted __be32 [usertype] @@ drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.c:1852:39:
Re: [v2] drm/msm/dpu: add support for dither block in display
Hi, On Thu, Jun 25, 2020 at 5:17 AM Kalyan Thota wrote: > > This change enables dither block for primary interface > in display. > > Enabled for 6bpc in the current version. > > Changes in v1: > - Remove redundant error checks (Rob). > > Signed-off-by: Kalyan Thota > --- > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 39 +++ > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 63 > + > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h | 28 +++ > 3 files changed, 121 insertions(+), 9 deletions(-) Tested-by: Douglas Anderson ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 1/2] Revert "dma-buf: Report signaled links inside dma-fence-chain"
Ignoring everything else ... On Thu, Jun 25, 2020 at 9:28 PM Jani Nikula wrote: > As a side note, there seem to be extra checks in place for acks when > applying non-i915 patches to drm-intel; there are no such checks for > drm-misc. One option to generalize that that I pondered is to consult get_maintainers.pl asking for git repo link, and if that returns something else, then insist that there's an ack from a relevant maintainer. It's a bit of typing, but I think the bigger problem is that there's a ton of false positives. But maybe that's a good thing, would give some motivation to keep MAINTAINERS updated. The other issue is though that drm-misc is plenty used to merge patches even when the respective maintainers are absent for weeks, or unresponsive. If we just blindly implement that rule, then the only possible Ack for these would be Dave&me as subsystem maintainers, and I don't want to be in the business of stamping approvals for all this stuff. Much better if people just collaborate. So I think an ack check would be nice, but probably not practical. Plus in this situation here drm-misc.git actually is the main repo, and we wont ever be able to teach a script to make a judgement call of whether that patch has the right amount of review on it. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 1/2] Revert "dma-buf: Report signaled links inside dma-fence-chain"
On Fri, 26 Jun 2020, Dave Airlie wrote:
> WTUF?
>
> How did this ever land in my tree, there is no ACK on this from anyone
> in core dma-buf,
>
> Intel team, clean your house up here, I'm going to have to ask you to
> stop Chris merging stuff without oversight, if this sort of thing
> happens, this is totally unacceptable.
There's no argument, an ack is required.
In fairness to the i915 maintainers, though, this particular commit was
merged via drm-misc-next [1].
As a side note, there seem to be extra checks in place for acks when
applying non-i915 patches to drm-intel; there are no such checks for
drm-misc.
BR,
Jani.
[1] http://lore.kernel.org/r/20200414090738.GA16827@linux-uq9g
>
> Dave.
>
>
> Signed-off-by: Chris Wilson
> Tested-by: Venkata Sandeep Dhanalakota
> Reviewed-by: Venkata Sandeep Dhanalakota
>
>
> On Thu, 25 Jun 2020 at 22:43, Christian König
> wrote:
>>
>> Am 25.06.20 um 14:34 schrieb Lionel Landwerlin:
>> > This reverts commit 5de376bb434f80a13138f0ebedc8351ab73d8b0d.
>> >
>> > This change breaks synchronization of a timeline.
>> > dma_fence_chain_find_seqno() might be a bit of a confusing name but
>> > this function is not trying to find a particular seqno, is supposed to
>> > give a fence to wait on for a particular point in the timeline.
>> >
>> > In a timeline, a particular value is reached when all the points up to
>> > and including that value have signaled.
>> >
>> > Signed-off-by: Lionel Landwerlin
>>
>> Reviewed-by: Christian König
>>
>> > ---
>> > drivers/dma-buf/dma-fence-chain.c | 7 ---
>> > 1 file changed, 7 deletions(-)
>> >
>> > diff --git a/drivers/dma-buf/dma-fence-chain.c
>> > b/drivers/dma-buf/dma-fence-chain.c
>> > index c435bbba851c..3d123502ff12 100644
>> > --- a/drivers/dma-buf/dma-fence-chain.c
>> > +++ b/drivers/dma-buf/dma-fence-chain.c
>> > @@ -99,12 +99,6 @@ int dma_fence_chain_find_seqno(struct dma_fence
>> > **pfence, uint64_t seqno)
>> > return -EINVAL;
>> >
>> > dma_fence_chain_for_each(*pfence, &chain->base) {
>> > - if ((*pfence)->seqno < seqno) { /* already signaled */
>> > - dma_fence_put(*pfence);
>> > - *pfence = NULL;
>> > - break;
>> > - }
>> > -
>> > if ((*pfence)->context != chain->base.context ||
>> > to_dma_fence_chain(*pfence)->prev_seqno < seqno)
>> > break;
>> > @@ -228,7 +222,6 @@ EXPORT_SYMBOL(dma_fence_chain_ops);
>> >* @chain: the chain node to initialize
>> >* @prev: the previous fence
>> >* @fence: the current fence
>> > - * @seqno: the sequence number (syncpt) of the fence within the chain
>> >*
>> >* Initialize a new chain node and either start a new chain or add the
>> > node to
>> >* the existing chain of the previous fence.
>>
>> ___
>> Intel-gfx mailing list
>> intel-...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/8] Fix a bunch of W=1 warnings in Backlight
Hi Lee. On Thu, Jun 25, 2020 at 09:03:37AM +0100, Lee Jones wrote: > On Wed, 24 Jun 2020, Sam Ravnborg wrote: > > > Hi Lee. > > > > On Wed, Jun 24, 2020 at 04:43:21PM +0100, Lee Jones wrote: > > > On Wed, 24 Jun 2020, Sam Ravnborg wrote: > > > > > > > Hi Lee. > > > > > > > > On Wed, Jun 24, 2020 at 03:57:13PM +0100, Lee Jones wrote: > > > > > Attempting to clean-up W=1 kernel builds, which are currently > > > > > overwhelmingly riddled with niggly little warnings. > > > > > > > > > > Lee Jones (8): > > > > > backlight: lms501kf03: Remove unused const variables > > > > > backlight: lcd: Add missing kerneldoc entry for 'struct device > > > > > parent' > > > > > > > > > > > > > backlight: ili922x: Add missing kerneldoc descriptions for > > > > > CHECK_FREQ_REG() args > > > > > backlight: ili922x: Remove invalid use of kerneldoc syntax > > > > > backlight: ili922x: Add missing kerneldoc description for > > > > > ili922x_reg_dump()'s arg > > > > I wonder why these warnings show up as nothing pulls in this .c file. > > > > Anyway I would suggest to drop using kerneldoc syntax for single drivers > > > > like this - and the benefit here is low. > > > > Now they are typed, otherwise this ahd been fine in a single patch. > > > > > > What do you mean by 'nothing pulls it in'? > > There are no .rst files that includes any: > > .. kernel-doc:: drivers/video/backlight/ili922x.c > > > > so I do not see how the kernel-doc comments will be used by any > > of the generated kernel-docs. > > Looks like a common problem (if it is actually a problem): > > $ ./scripts/find-unused-docs.sh . | wc -l > 1476 > > The role of this patch-set is not to eradicate unused kerneldoc > headers, but to ensure they are formatted correctly. W=1 builds > currently complain of ill formatted kerneldocs, which is currently > littering the build-log and masking some more important issues (which > I'm also trying to fix en route). My point is that I do not see why we should maintain correct kernel-doc style comments for files that are not used to to generate kernel-doc. It would serve us better to drop the kernel-doc style comments. But thats just my opinion, feel free to ignore. I digged a little and can see we run kernel-doc on all .c files when we specify W=1 - which was a suprise to me. That explains why I had not seen said warnings in my regular make htmldocs runs. Sam > > > > > > backlight: backlight: Supply description for function args in > > > > > existing > > > > > Kerneldocs > > > > > backlight: lm3630a_bl: Remove invalid checks for unsigned int < 0 > > > > > backlight: qcom-wled: Remove unused configs for LED3 and LED4 > > > > > > > > The other fixes looks good. > > > > They are all: > > > > Acked-by: Sam Ravnborg > > > > > > Thanks (although this should be Reviewed-by). > > > > > > > > drivers/video/backlight/backlight.c | 2 ++ > > > > > drivers/video/backlight/ili922x.c| 8 ++-- > > > > > drivers/video/backlight/lcd.c| 1 + > > > > > drivers/video/backlight/lm3630a_bl.c | 4 ++-- > > > > > drivers/video/backlight/lms501kf03.c | 8 > > > > > drivers/video/backlight/qcom-wled.c | 8 > > > > > 6 files changed, 11 insertions(+), 20 deletions(-) > > > > > > > > > > -- > Lee Jones [李琼斯] > Senior Technical Lead - Developer Services > Linaro.org │ Open source software for Arm SoCs > Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/3] gpu: ipu-v3: image-convert: Wait for all EOFs before completing a tile
Use a bit-mask of EOF irqs to determine when all required idmac
channel EOFs have been received for a tile conversion, and only do
tile completion processing after all EOFs have been received. Otherwise
it was found that a conversion would stall after the completion of a
tile and the start of the next tile, because the input/read idmac
channel had not completed and entered idle state, thus locking up the
channel when attempting to re-start it for the next tile.
Fixes: 0537db801bb01 ("gpu: ipu-v3: image-convert: reconfigure IC per tile")
Signed-off-by: Steve Longerbeam
---
Changes in v2:
- need to clear eof_mask at completion of every tile, not just in
convert_start().
---
drivers/gpu/ipu-v3/ipu-image-convert.c | 109 +++--
1 file changed, 82 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-image-convert.c
b/drivers/gpu/ipu-v3/ipu-image-convert.c
index f8b031ded3cf..aa1d4b6d278f 100644
--- a/drivers/gpu/ipu-v3/ipu-image-convert.c
+++ b/drivers/gpu/ipu-v3/ipu-image-convert.c
@@ -137,6 +137,17 @@ struct ipu_image_convert_ctx;
struct ipu_image_convert_chan;
struct ipu_image_convert_priv;
+enum eof_irq_mask {
+ EOF_IRQ_IN = BIT(0),
+ EOF_IRQ_ROT_IN = BIT(1),
+ EOF_IRQ_OUT = BIT(2),
+ EOF_IRQ_ROT_OUT = BIT(3),
+};
+
+#define EOF_IRQ_COMPLETE (EOF_IRQ_IN | EOF_IRQ_OUT)
+#define EOF_IRQ_ROT_COMPLETE (EOF_IRQ_IN | EOF_IRQ_OUT | \
+ EOF_IRQ_ROT_IN | EOF_IRQ_ROT_OUT)
+
struct ipu_image_convert_ctx {
struct ipu_image_convert_chan *chan;
@@ -173,6 +184,9 @@ struct ipu_image_convert_ctx {
/* where to place converted tile in dest image */
unsigned int out_tile_map[MAX_TILES];
+ /* mask of completed EOF irqs at every tile conversion */
+ enum eof_irq_mask eof_mask;
+
struct list_head list;
};
@@ -189,6 +203,8 @@ struct ipu_image_convert_chan {
struct ipuv3_channel *rotation_out_chan;
/* the IPU end-of-frame irqs */
+ int in_eof_irq;
+ int rot_in_eof_irq;
int out_eof_irq;
int rot_out_eof_irq;
@@ -1380,6 +1396,9 @@ static int convert_start(struct ipu_image_convert_run
*run, unsigned int tile)
dev_dbg(priv->ipu->dev, "%s: task %u: starting ctx %p run %p tile %u ->
%u\n",
__func__, chan->ic_task, ctx, run, tile, dst_tile);
+ /* clear EOF irq mask */
+ ctx->eof_mask = 0;
+
if (ipu_rot_mode_is_irt(ctx->rot_mode)) {
/* swap width/height for resizer */
dest_width = d_image->tile[dst_tile].height;
@@ -1615,7 +1634,7 @@ static bool ic_settings_changed(struct
ipu_image_convert_ctx *ctx)
}
/* hold irqlock when calling */
-static irqreturn_t do_irq(struct ipu_image_convert_run *run)
+static irqreturn_t do_tile_complete(struct ipu_image_convert_run *run)
{
struct ipu_image_convert_ctx *ctx = run->ctx;
struct ipu_image_convert_chan *chan = ctx->chan;
@@ -1700,6 +1719,7 @@ static irqreturn_t do_irq(struct ipu_image_convert_run
*run)
ctx->cur_buf_num ^= 1;
}
+ ctx->eof_mask = 0; /* clear EOF irq mask for next tile */
ctx->next_tile++;
return IRQ_HANDLED;
done:
@@ -1715,8 +1735,9 @@ static irqreturn_t eof_irq(int irq, void *data)
struct ipu_image_convert_priv *priv = chan->priv;
struct ipu_image_convert_ctx *ctx;
struct ipu_image_convert_run *run;
+ irqreturn_t ret = IRQ_HANDLED;
+ bool tile_complete = false;
unsigned long flags;
- irqreturn_t ret;
spin_lock_irqsave(&chan->irqlock, flags);
@@ -1729,27 +1750,33 @@ static irqreturn_t eof_irq(int irq, void *data)
ctx = run->ctx;
- if (irq == chan->out_eof_irq) {
- if (ipu_rot_mode_is_irt(ctx->rot_mode)) {
- /* this is a rotation op, just ignore */
- ret = IRQ_HANDLED;
- goto out;
- }
- } else if (irq == chan->rot_out_eof_irq) {
+ if (irq == chan->in_eof_irq) {
+ ctx->eof_mask |= EOF_IRQ_IN;
+ } else if (irq == chan->out_eof_irq) {
+ ctx->eof_mask |= EOF_IRQ_OUT;
+ } else if (irq == chan->rot_in_eof_irq ||
+ irq == chan->rot_out_eof_irq) {
if (!ipu_rot_mode_is_irt(ctx->rot_mode)) {
/* this was NOT a rotation op, shouldn't happen */
dev_err(priv->ipu->dev,
"Unexpected rotation interrupt\n");
- ret = IRQ_HANDLED;
goto out;
}
+ ctx->eof_mask |= (irq == chan->rot_in_eof_irq) ?
+ EOF_IRQ_ROT_IN : EOF_IRQ_ROT_OUT;
} else {
dev_err(priv->ipu->dev, "Received unknown irq %d\n", irq);
ret = IRQ_NONE;
goto out;
}
- ret = do_irq(run);
+ i
[Bug 201139] amdgpu: [drm] enabling link 1 failed: 15 (vega)
https://bugzilla.kernel.org/show_bug.cgi?id=201139 --- Comment #11 from Adarion from userland (h_mailingli...@posteo.de) --- Potentially related https://bugzilla.kernel.org/show_bug.cgi?id=208115 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] RFC: i915: Drop relocation support on Gen12+
On Fri, 8 May 2020 at 15:58, Joonas Lahtinen wrote: > > Quoting Dave Airlie (2020-05-07 21:27:27) > > On Fri, 8 May 2020 at 01:44, Chris Wilson wrote: > > > > > > Quoting Jason Ekstrand (2020-05-07 16:36:00) > > > > The Vulkan driver in Mesa for Intel hardware never uses relocations if > > > > it's running on a version of i915 that supports at least softpin which > > > > all versions of i915 supporting Gen12 do. On the OpenGL side, Gen12 is > > > > only supported by iris which never uses relocations. The older i965 > > > > driver in Mesa does use relocations but it only supports Intel hardware > > > > through Gen11 and has been deprecated for all hardware Gen9+. The entire > > > > relocation UAPI and related infrastructure, therefore, doesn't have any > > > > open-source userspace consumer starting with Gen12. > > > > > > > > Rejecting relocations starting with Gen12 has the benefit that we don't > > > > have to bother supporting it on platforms with local memory. Given how > > > > much CPU touching of memory is required for relocations, not having to > > > > do so on platforms where not all memory is directly CPU-accessible > > > > carries significant advantages. > > > > > > You are not supplying them, the kernel is not checking them [as they > > > don't exist], so there is no material benefit. The only question is > > > maintainability. > > > > > > How confident are you that you will never use them and rewrite the > > > media-driver? The code exists, will be tested, and can just as easily > > > expire with the rest of execbuffer2. > > > > From an upstream POV I say hell yes, if the hw isn't generally available > > yet, > > and the media-driver/intel-compute-runtime people are warned in advance, > > > > I'm all in on ripping it out for new GENs. > > There have been discussions with our media driver team about eliminating > any relocations, but today they are still being used. They have started > partially using soft-pinning, which is a great first step to that > direction. > > The compute driver does not rely on relocations, they use soft-pinning > everywhere and explicitly manage the address space. > > Be assured that I'm also in favor of eliminating relocations (just like > execbuffer2, userptr and couple other things), just that we still need > to have a functional stack before they can be dropped for new hardware. > > Like Chris mentioned, enough optimization have been put in the code so > that there is zero impact from the relocations to the exclusively > soft-pinning drivers. So the sole benefit would be being able to drop > the relocations code in the future when the Gen11 hardware has gone > exctinct and that is a worthy goal, too. > > But for now the feature is still needed for Gen12, so forcefully > disabling it is untimely. > I'm going to ask that this be revisited for DG1. DG1 is a discrete GPU,a brand new thing that in no way requires relocations. If relocations are required for legacy software, that software is being updated to add local memory support, relocations should be removed at the same time. The main reason for this is I believe a lot of effort is being put into making relocations faster and better that is impacting all over the i915 driver. instead of just fixing userspace to not require them anymore moving forward. I'd rather DG1 support gets upstream in a sane fashion without having to worry about how super-optimised the relocation paths are for some corner case userspace code that if it was part of the mesa project would have been updated by now. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1] drm/amd/powerplay: Fix NULL dereference in lock_bus() on Vega20 w/o RAS
Applied. Thanks!
Alex
On Thu, Jun 25, 2020 at 1:14 PM Ivan Mironov wrote:
>
> I updated my system with Radeon VII from kernel 5.6 to kernel 5.7, and
> following started to happen on each boot:
>
> ...
> BUG: kernel NULL pointer dereference, address: 0128
> ...
> CPU: 9 PID: 1940 Comm: modprobe Tainted: GE
> 5.7.2-200.im0.fc32.x86_64 #1
> Hardware name: System manufacturer System Product Name/PRIME X570-P,
> BIOS 1407 04/02/2020
> RIP: 0010:lock_bus+0x42/0x60 [amdgpu]
> ...
> Call Trace:
> i2c_smbus_xfer+0x3d/0xf0
> i2c_default_probe+0xf3/0x130
> i2c_detect.isra.0+0xfe/0x2b0
> ? kfree+0xa3/0x200
> ? kobject_uevent_env+0x11f/0x6a0
> ? i2c_detect.isra.0+0x2b0/0x2b0
> __process_new_driver+0x1b/0x20
> bus_for_each_dev+0x64/0x90
> ? 0xc0f34000
> i2c_register_driver+0x73/0xc0
> do_one_initcall+0x46/0x200
> ? _cond_resched+0x16/0x40
> ? kmem_cache_alloc_trace+0x167/0x220
> ? do_init_module+0x23/0x260
> do_init_module+0x5c/0x260
> __do_sys_init_module+0x14f/0x170
> do_syscall_64+0x5b/0xf0
> entry_SYSCALL_64_after_hwframe+0x44/0xa9
> ...
>
> Error appears when some i2c device driver tries to probe for devices
> using adapter registered by `smu_v11_0_i2c_eeprom_control_init()`.
> Code supporting this adapter requires `adev->psp.ras.ras` to be not
> NULL, which is true only when `amdgpu_ras_init()` detects HW support by
> calling `amdgpu_ras_check_supported()`.
>
> Before 9015d60c9ee1, adapter was registered by
>
> -> amdgpu_device_ip_init()
> -> amdgpu_ras_recovery_init()
> -> amdgpu_ras_eeprom_init()
> -> smu_v11_0_i2c_eeprom_control_init()
>
> after verifying that `adev->psp.ras.ras` is not NULL in
> `amdgpu_ras_recovery_init()`. Currently it is registered
> unconditionally by
>
> -> amdgpu_device_ip_init()
> -> pp_sw_init()
> -> hwmgr_sw_init()
> -> vega20_smu_init()
> -> smu_v11_0_i2c_eeprom_control_init()
>
> Fix simply adds HW support check (ras == NULL => no support) before
> calling `smu_v11_0_i2c_eeprom_control_{init,fini}()`.
>
> Please note that there is a chance that similar fix is also required for
> CHIP_ARCTURUS. I do not know whether any actual Arcturus hardware without
> RAS exist, and whether calling `smu_i2c_eeprom_init()` makes any sense
> when there is no HW support.
>
> Cc: sta...@vger.kernel.org
> Fixes: 9015d60c9ee1 ("drm/amdgpu: Move EEPROM I2C adapter to amdgpu_device")
> Signed-off-by: Ivan Mironov
> Tested-by: Bjorn Nostvold
> ---
> Changelog:
>
> v1:
> - Added "Tested-by" for another user who used this patch to fix the
> same issue.
>
> v0:
> - Patch introduced.
> ---
> drivers/gpu/drm/amd/powerplay/smumgr/vega20_smumgr.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/vega20_smumgr.c
> b/drivers/gpu/drm/amd/powerplay/smumgr/vega20_smumgr.c
> index 2fb97554134f..c2e0fbbccf56 100644
> --- a/drivers/gpu/drm/amd/powerplay/smumgr/vega20_smumgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/vega20_smumgr.c
> @@ -522,9 +522,11 @@ static int vega20_smu_init(struct pp_hwmgr *hwmgr)
> priv->smu_tables.entry[TABLE_ACTIVITY_MONITOR_COEFF].version = 0x01;
> priv->smu_tables.entry[TABLE_ACTIVITY_MONITOR_COEFF].size =
> sizeof(DpmActivityMonitorCoeffInt_t);
>
> - ret = smu_v11_0_i2c_eeprom_control_init(&adev->pm.smu_i2c);
> - if (ret)
> - goto err4;
> + if (adev->psp.ras.ras) {
> + ret = smu_v11_0_i2c_eeprom_control_init(&adev->pm.smu_i2c);
> + if (ret)
> + goto err4;
> + }
>
> return 0;
>
> @@ -560,7 +562,8 @@ static int vega20_smu_fini(struct pp_hwmgr *hwmgr)
> (struct vega20_smumgr *)(hwmgr->smu_backend);
> struct amdgpu_device *adev = hwmgr->adev;
>
> - smu_v11_0_i2c_eeprom_control_fini(&adev->pm.smu_i2c);
> + if (adev->psp.ras.ras)
> + smu_v11_0_i2c_eeprom_control_fini(&adev->pm.smu_i2c);
>
> if (priv) {
>
> amdgpu_bo_free_kernel(&priv->smu_tables.entry[TABLE_PPTABLE].handle,
> --
> 2.26.2
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 1/2] Revert "dma-buf: Report signaled links inside dma-fence-chain"
WTUF?
How did this ever land in my tree, there is no ACK on this from anyone
in core dma-buf,
Intel team, clean your house up here, I'm going to have to ask you to
stop Chris merging stuff without oversight, if this sort of thing
happens, this is totally unacceptable.
Dave.
Signed-off-by: Chris Wilson
Tested-by: Venkata Sandeep Dhanalakota
Reviewed-by: Venkata Sandeep Dhanalakota
On Thu, 25 Jun 2020 at 22:43, Christian König wrote:
>
> Am 25.06.20 um 14:34 schrieb Lionel Landwerlin:
> > This reverts commit 5de376bb434f80a13138f0ebedc8351ab73d8b0d.
> >
> > This change breaks synchronization of a timeline.
> > dma_fence_chain_find_seqno() might be a bit of a confusing name but
> > this function is not trying to find a particular seqno, is supposed to
> > give a fence to wait on for a particular point in the timeline.
> >
> > In a timeline, a particular value is reached when all the points up to
> > and including that value have signaled.
> >
> > Signed-off-by: Lionel Landwerlin
>
> Reviewed-by: Christian König
>
> > ---
> > drivers/dma-buf/dma-fence-chain.c | 7 ---
> > 1 file changed, 7 deletions(-)
> >
> > diff --git a/drivers/dma-buf/dma-fence-chain.c
> > b/drivers/dma-buf/dma-fence-chain.c
> > index c435bbba851c..3d123502ff12 100644
> > --- a/drivers/dma-buf/dma-fence-chain.c
> > +++ b/drivers/dma-buf/dma-fence-chain.c
> > @@ -99,12 +99,6 @@ int dma_fence_chain_find_seqno(struct dma_fence
> > **pfence, uint64_t seqno)
> > return -EINVAL;
> >
> > dma_fence_chain_for_each(*pfence, &chain->base) {
> > - if ((*pfence)->seqno < seqno) { /* already signaled */
> > - dma_fence_put(*pfence);
> > - *pfence = NULL;
> > - break;
> > - }
> > -
> > if ((*pfence)->context != chain->base.context ||
> > to_dma_fence_chain(*pfence)->prev_seqno < seqno)
> > break;
> > @@ -228,7 +222,6 @@ EXPORT_SYMBOL(dma_fence_chain_ops);
> >* @chain: the chain node to initialize
> >* @prev: the previous fence
> >* @fence: the current fence
> > - * @seqno: the sequence number (syncpt) of the fence within the chain
> >*
> >* Initialize a new chain node and either start a new chain or add the
> > node to
> >* the existing chain of the previous fence.
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/atomic_helper: duplicate state for drm_private_obj
On Thu, Jun 25, 2020 at 8:55 AM Daniel Vetter wrote: > > On Thu, Jun 25, 2020 at 4:17 PM Rob Clark wrote: > > > > On Thu, Jun 25, 2020 at 5:35 AM Daniel Vetter > > wrote: > > > > > > On Thu, Jun 25, 2020 at 1:58 PM Shawn Guo wrote: > > > > > > > > From: Shawn Guo > > > > > > > > The msm/mdp5 driver uses drm_private_obj as its global atomic state, > > > > which keeps the assignment of hwpipe to plane. With drm_private_obj > > > > missing from duplicate state call, mdp5 suspend works with no problem > > > > only for the very first time. Any subsequent suspend will hit the > > > > following warning, because hwpipe assignment doesn't get duplicated for > > > > suspend state. Adding drm_private_obj handling for duplicate state call > > > > fixes the problem. > > > > > > If the driver needs a private state, it's supposed to duplicate that > > > in its atomic_check functionality. This isn't the helper's job. > > > > > > If this is a bug in msm code, then pretty sure if you try hard enough, > > > you can hit the exact same bug from userspace too. Maybe good idea to > > > try and reproduce this with igt or something. > > > > The problem is how duplicate_state is used by the atomic > > suspend/resume helpers. They duplicate the running state on suspend, > > forgetting to duplicate the global state. Then everything is > > disabled, the driver correctly duplicates and updates it's global > > atomic state releasing the hwpipe. > > > > But then on resume, we are re-applying plane state that thinks it > > already has a hwpipe assigned (because that is part of the plane state > > that was duplicated), without reapplying the matching global state. > > > > On a normal atomic commit, we would duplicate the plane state that has > > the hwpipe disabled, which would be in sync with the drivers global > > state. But since that is not what the atomic resume helper does, we > > hit the situation where the plane state and the global state are out > > of sync. > > > > So the driver is dtrt, the problem really is with the helpers. I > > think this patch is the right thing to do. It is incorrect for the > > suspend/resume helpers to assume that they can re-apply duplicated > > state without including the global state. > > Hm, this is a bit awkward. Generally the assumption is that you should > be recomputing the derived state (like hwpipe) no matter what. If your > driver doesn't do that, then all kinds of things can leak from the > pre-resume to the post-resume side of things, that's kinda why I'm not > thrilled with this patch, I think it has good potential to open up a > can of worms. Iirc this patch has come up in the past, and in those > cases it was a driver bug. > > For this case, why is msm reusing a hw pipe assignment of a disabled plane? Because it is part of the plane state that is being restored. Since resume uses the old state saved before the drm_atomic_helper_disable_all(), rather than duplicating the current state, we end up with this mismatch between global and plane state. I think stashing away the old state is probably ok, but we can't just do it piecemeal without including the global state. I suppose part of the problem is the hwpipe (and other such dynamically assigned resources) touch both private and plane (and crtc) state. The global state object knows which resources are assigned to which plane/crtc. But the plane/crtc state knows which of the (potentially) two hwpipe/mixers is "left" (primary) and "right" (secondary). > > Unfortunately we can't copy the drm state into the overall structure > to solve this, since that would miss driver-private properties. So > unfortunately we can't make this match a real atomic commit from > userspace perfectly. I'm not sure I understand this? The driver private properties would/should be part of one of the state objs (plane/crtc/global)? If the atomic state (including global) represents the entirety of the hw state, you should be able to stash off N different versions of them and re-apply them in any order you want because they are all self-consistent. > > Another option would be if msm just copies the private state it needs > to not go boom. > > Doing this unconditionally might break other drivers that rely on > private state not being duplicated, but I guess that would also be > somewhat of a driver bug. I guess we could duplicate our own version of drm_atomic_helper_suspend().. or maybe add a 'duplicate_global' param to drm_atomic_helper_suspend(). I'm not too sure how many drivers these days are using global atomic state, so not sure how many would be potentially broken, but opting in to duplicating global state seems reasonable if necessary. BR, -R > -Daniel > > > > > BR, > > -R > > > > > -Daniel > > > > > > > > > > $ echo mem > /sys/power/state > > > > [ 38.44] PM: suspend entry (deep) > > > > [ 38.85] PM: Syncing filesystems ... done. > > > > [ 38.114630] Freezing user space processes ... (elapsed 0.001 > > > > seconds) done
Re: [RESEND] [PATCH v6 0/8] do not store GPU address in TTM
Am 25.06.20 um 17:52 schrieb Christian König: Am 25.06.20 um 17:44 schrieb Daniel Vetter: On Thu, Jun 25, 2020 at 11:50 AM Christian König wrote: I've pushed patches #1, #2 and #5-#8 of this series to drm-misc-next. I think you left an unresolved conflict behind in drm-tip, please resolve per https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdrm.pages.freedesktop.org%2Fmaintainer-tools%2Fdrm-tip.html%23resolving-conflicts-when-rebuilding-drm-tip&data=02%7C01%7Cchristian.koenig%40amd.com%7Cc1441a81e9dc4fa4507208d8191ea0f6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637286966631595300&sdata=pfWS4VgDvU8IsR2638MDr7fYWE0nefa3b6XxyPCCsOU%3D&reserved=0 The script should have told you that already, so maybe reinvent that in whatever thing you're using :-) Jani has reported this on #dri-devel, this also holds up CI testing since we're running on top of drm-tip. Well I used dim push-branch. I even had to rebase once more because I forgot a signed-of on one of the patches, so I'm pretty sure of that. Haven't seen anything problematic except for that while doing so. Ok, anyway that one was trivial to fix. Thanks, Christian. Regards, Christian. -Daniel Only VMGFX and Nouveau are missing and I'm pretty close to just push them with my Acked-by since they should not contain any functional change. Any objections? Thanks, Christian. Am 24.06.20 um 20:26 schrieb Nirmoy Das: With this patch series I am trying to remove GPU address dependency in TTM and moving GPU address calculation to individual drm drivers. This cleanup will simplify introduction of drm_mem_region/domain work started by Brian Welty[1]. It would be nice if someone test this for nouveau. Rest of the drivers are already tested. v2: * set bo->offset = 0 for drm/nouveau if bo->mem.mm_node == NULL v3: * catch return value of drm_gem_vram_offset() in drm/bochs * introduce drm_gem_vram_pg_offset() in vram helper * improve nbo->offset calculation for nouveau v4: * minor coding style fixes in amdgpu and radeon * remove unnecessary kerneldoc for internal function v5: * rebase on top of drm-misc-next * fix return value of drm_gem_vram_pg_offset() * add a comment in drm_gem_vram_pg_offset() to clearify why we return 0. v6: * rebase to drm-misc-next * removed acked for vmwgfx as there was a small conflict Nirmoy Das (8): drm/amdgpu: move ttm bo->offset to amdgpu_bo drm/radeon: don't use ttm bo->offset drm/vmwgfx: don't use ttm bo->offset drm/nouveau: don't use ttm bo->offset v3 drm/qxl: don't use ttm bo->offset drm/vram-helper: don't use ttm bo->offset v4 drm/bochs: use drm_gem_vram_offset to get bo offset v2 drm/ttm: do not keep GPU dependent addresses drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 23 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 30 - drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c | 4 +-- drivers/gpu/drm/bochs/bochs_kms.c | 7 - drivers/gpu/drm/drm_gem_vram_helper.c | 11 +++- drivers/gpu/drm/nouveau/dispnv04/crtc.c | 6 ++--- drivers/gpu/drm/nouveau/dispnv04/disp.c | 3 ++- drivers/gpu/drm/nouveau/dispnv04/overlay.c | 6 ++--- drivers/gpu/drm/nouveau/dispnv50/base507c.c | 2 +- drivers/gpu/drm/nouveau/dispnv50/core507d.c | 2 +- drivers/gpu/drm/nouveau/dispnv50/ovly507e.c | 2 +- drivers/gpu/drm/nouveau/dispnv50/wndw.c | 2 +- drivers/gpu/drm/nouveau/dispnv50/wndwc37e.c | 2 +- drivers/gpu/drm/nouveau/nouveau_abi16.c | 8 +++--- drivers/gpu/drm/nouveau/nouveau_bo.c | 8 ++ drivers/gpu/drm/nouveau/nouveau_bo.h | 3 +++ drivers/gpu/drm/nouveau/nouveau_chan.c | 2 +- drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +- drivers/gpu/drm/nouveau/nouveau_fbcon.c | 2 +- drivers/gpu/drm/nouveau/nouveau_gem.c | 10 +++ drivers/gpu/drm/qxl/qxl_drv.h | 6 ++--- drivers/gpu/drm/qxl/qxl_kms.c | 5 ++-- drivers/gpu/drm/qxl/qxl_object.h | 5 drivers/gpu/drm/qxl/qxl_ttm.c | 9 --- drivers/gpu/drm/radeon/radeon.h | 1 + drivers/gpu/drm/radeon/radeon_object.h | 16 ++- drivers/gpu/drm/radeon/radeon_ttm.c | 4 +-- drivers/gpu/drm/ttm/ttm_bo.c | 7 - drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 4 +-- drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 -- include/drm/ttm/ttm_bo_api.h | 2 -- include/drm/ttm/ttm_bo_driver.h | 1 - 36 files changed, 125 insertions(+), 78 deletions(-) -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedes
Re: [PATCH] drm/atomic_helper: duplicate state for drm_private_obj
On Thu, Jun 25, 2020 at 4:17 PM Rob Clark wrote: > > On Thu, Jun 25, 2020 at 5:35 AM Daniel Vetter wrote: > > > > On Thu, Jun 25, 2020 at 1:58 PM Shawn Guo wrote: > > > > > > From: Shawn Guo > > > > > > The msm/mdp5 driver uses drm_private_obj as its global atomic state, > > > which keeps the assignment of hwpipe to plane. With drm_private_obj > > > missing from duplicate state call, mdp5 suspend works with no problem > > > only for the very first time. Any subsequent suspend will hit the > > > following warning, because hwpipe assignment doesn't get duplicated for > > > suspend state. Adding drm_private_obj handling for duplicate state call > > > fixes the problem. > > > > If the driver needs a private state, it's supposed to duplicate that > > in its atomic_check functionality. This isn't the helper's job. > > > > If this is a bug in msm code, then pretty sure if you try hard enough, > > you can hit the exact same bug from userspace too. Maybe good idea to > > try and reproduce this with igt or something. > > The problem is how duplicate_state is used by the atomic > suspend/resume helpers. They duplicate the running state on suspend, > forgetting to duplicate the global state. Then everything is > disabled, the driver correctly duplicates and updates it's global > atomic state releasing the hwpipe. > > But then on resume, we are re-applying plane state that thinks it > already has a hwpipe assigned (because that is part of the plane state > that was duplicated), without reapplying the matching global state. > > On a normal atomic commit, we would duplicate the plane state that has > the hwpipe disabled, which would be in sync with the drivers global > state. But since that is not what the atomic resume helper does, we > hit the situation where the plane state and the global state are out > of sync. > > So the driver is dtrt, the problem really is with the helpers. I > think this patch is the right thing to do. It is incorrect for the > suspend/resume helpers to assume that they can re-apply duplicated > state without including the global state. Hm, this is a bit awkward. Generally the assumption is that you should be recomputing the derived state (like hwpipe) no matter what. If your driver doesn't do that, then all kinds of things can leak from the pre-resume to the post-resume side of things, that's kinda why I'm not thrilled with this patch, I think it has good potential to open up a can of worms. Iirc this patch has come up in the past, and in those cases it was a driver bug. For this case, why is msm reusing a hw pipe assignment of a disabled plane? Unfortunately we can't copy the drm state into the overall structure to solve this, since that would miss driver-private properties. So unfortunately we can't make this match a real atomic commit from userspace perfectly. Another option would be if msm just copies the private state it needs to not go boom. Doing this unconditionally might break other drivers that rely on private state not being duplicated, but I guess that would also be somewhat of a driver bug. -Daniel > > BR, > -R > > > -Daniel > > > > > > > $ echo mem > /sys/power/state > > > [ 38.44] PM: suspend entry (deep) > > > [ 38.85] PM: Syncing filesystems ... done. > > > [ 38.114630] Freezing user space processes ... (elapsed 0.001 seconds) > > > done. > > > [ 38.115912] OOM killer disabled. > > > [ 38.115914] Freezing remaining freezable tasks ... (elapsed 0.001 > > > seconds) done. > > > [ 38.122170] [ cut here ] > > > [ 38.122212] WARNING: CPU: 0 PID: 1747 at > > > drivers/gpu/drm/msm/disp/mdp5/mdp5_pipe.c:145 mdp5_pipe_release+0x90/0xc0 > > > [ 38.122215] Modules linked in: > > > [ 38.12] CPU: 0 PID: 1747 Comm: sh Not tainted > > > 4.19.107-00515-g9d5e4d7a33ed-dirty #323 > > > [ 38.14] Hardware name: Square, Inc. T2 Devkit (DT) > > > [ 38.18] pstate: 4005 (nZcv daif -PAN -UAO) > > > [ 38.122230] pc : mdp5_pipe_release+0x90/0xc0 > > > [ 38.122233] lr : mdp5_pipe_release+0x90/0xc0 > > > [ 38.122235] sp : 0d13b7f0 > > > [ 38.122236] x29: 0d13b7f0 x28: > > > [ 38.122240] x27: 0002 x26: 800079adce00 > > > [ 38.122243] x25: 800079405200 x24: > > > [ 38.122246] x23: 80007a78cc08 x22: 80007b1cc018 > > > [ 38.122249] x21: 80007b1cc000 x20: 80007b317080 > > > [ 38.122252] x19: 80007a78ce80 x18: 0002 > > > [ 38.122255] x17: x16: > > > [ 38.122258] x15: fff0 x14: 08c3fb48 > > > [ 38.122261] x13: 08cdac4a x12: 08c3f000 > > > [ 38.122264] x11: x10: 08cda000 > > > [ 38.122267] x9 : x8 : 08ce4a40 > > > [ 38.122269] x7 : x6 : 39ea41a9 > > > [ 38.122272] x5 : x4 : > > > [ 38.122275] x3 : x
Re: [RESEND] [PATCH v6 0/8] do not store GPU address in TTM
Am 25.06.20 um 17:44 schrieb Daniel Vetter: On Thu, Jun 25, 2020 at 11:50 AM Christian König wrote: I've pushed patches #1, #2 and #5-#8 of this series to drm-misc-next. I think you left an unresolved conflict behind in drm-tip, please resolve per https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdrm.pages.freedesktop.org%2Fmaintainer-tools%2Fdrm-tip.html%23resolving-conflicts-when-rebuilding-drm-tip&data=02%7C01%7Cchristian.koenig%40amd.com%7Cc1441a81e9dc4fa4507208d8191ea0f6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637286966631595300&sdata=pfWS4VgDvU8IsR2638MDr7fYWE0nefa3b6XxyPCCsOU%3D&reserved=0 The script should have told you that already, so maybe reinvent that in whatever thing you're using :-) Jani has reported this on #dri-devel, this also holds up CI testing since we're running on top of drm-tip. Well I used dim push-branch. I even had to rebase once more because I forgot a signed-of on one of the patches, so I'm pretty sure of that. Haven't seen anything problematic except for that while doing so. Regards, Christian. -Daniel Only VMGFX and Nouveau are missing and I'm pretty close to just push them with my Acked-by since they should not contain any functional change. Any objections? Thanks, Christian. Am 24.06.20 um 20:26 schrieb Nirmoy Das: With this patch series I am trying to remove GPU address dependency in TTM and moving GPU address calculation to individual drm drivers. This cleanup will simplify introduction of drm_mem_region/domain work started by Brian Welty[1]. It would be nice if someone test this for nouveau. Rest of the drivers are already tested. v2: * set bo->offset = 0 for drm/nouveau if bo->mem.mm_node == NULL v3: * catch return value of drm_gem_vram_offset() in drm/bochs * introduce drm_gem_vram_pg_offset() in vram helper * improve nbo->offset calculation for nouveau v4: * minor coding style fixes in amdgpu and radeon * remove unnecessary kerneldoc for internal function v5: * rebase on top of drm-misc-next * fix return value of drm_gem_vram_pg_offset() * add a comment in drm_gem_vram_pg_offset() to clearify why we return 0. v6: * rebase to drm-misc-next * removed acked for vmwgfx as there was a small conflict Nirmoy Das (8): drm/amdgpu: move ttm bo->offset to amdgpu_bo drm/radeon: don't use ttm bo->offset drm/vmwgfx: don't use ttm bo->offset drm/nouveau: don't use ttm bo->offset v3 drm/qxl: don't use ttm bo->offset drm/vram-helper: don't use ttm bo->offset v4 drm/bochs: use drm_gem_vram_offset to get bo offset v2 drm/ttm: do not keep GPU dependent addresses drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 23 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 30 - drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c | 4 +-- drivers/gpu/drm/bochs/bochs_kms.c | 7 - drivers/gpu/drm/drm_gem_vram_helper.c | 11 +++- drivers/gpu/drm/nouveau/dispnv04/crtc.c | 6 ++--- drivers/gpu/drm/nouveau/dispnv04/disp.c | 3 ++- drivers/gpu/drm/nouveau/dispnv04/overlay.c | 6 ++--- drivers/gpu/drm/nouveau/dispnv50/base507c.c | 2 +- drivers/gpu/drm/nouveau/dispnv50/core507d.c | 2 +- drivers/gpu/drm/nouveau/dispnv50/ovly507e.c | 2 +- drivers/gpu/drm/nouveau/dispnv50/wndw.c | 2 +- drivers/gpu/drm/nouveau/dispnv50/wndwc37e.c | 2 +- drivers/gpu/drm/nouveau/nouveau_abi16.c | 8 +++--- drivers/gpu/drm/nouveau/nouveau_bo.c| 8 ++ drivers/gpu/drm/nouveau/nouveau_bo.h| 3 +++ drivers/gpu/drm/nouveau/nouveau_chan.c | 2 +- drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +- drivers/gpu/drm/nouveau/nouveau_fbcon.c | 2 +- drivers/gpu/drm/nouveau/nouveau_gem.c | 10 +++ drivers/gpu/drm/qxl/qxl_drv.h | 6 ++--- drivers/gpu/drm/qxl/qxl_kms.c | 5 ++-- drivers/gpu/drm/qxl/qxl_object.h| 5 drivers/gpu/drm/qxl/qxl_ttm.c | 9 --- drivers/gpu/drm/radeon/radeon.h | 1 + drivers/gpu/drm/radeon/radeon_object.h | 16 ++- drivers/gpu/drm/radeon/radeon_ttm.c | 4 +-- drivers/gpu/drm/ttm/ttm_bo.c| 7 - drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 4 +-- drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c| 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 -- include/drm/ttm/ttm_bo_api.h| 2 -- include/drm/ttm/ttm_bo_driver.h | 1 - 36 files changed, 125 insertions(+), 78 deletions(-) -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND] [PATCH v6 0/8] do not store GPU address in TTM
On Thu, Jun 25, 2020 at 11:50 AM Christian König wrote: > > I've pushed patches #1, #2 and #5-#8 of this series to drm-misc-next. I think you left an unresolved conflict behind in drm-tip, please resolve per https://drm.pages.freedesktop.org/maintainer-tools/drm-tip.html#resolving-conflicts-when-rebuilding-drm-tip The script should have told you that already, so maybe reinvent that in whatever thing you're using :-) Jani has reported this on #dri-devel, this also holds up CI testing since we're running on top of drm-tip. -Daniel > Only VMGFX and Nouveau are missing and I'm pretty close to just push > them with my Acked-by since they should not contain any functional change. > > Any objections? > > Thanks, > Christian. > > Am 24.06.20 um 20:26 schrieb Nirmoy Das: > > With this patch series I am trying to remove GPU address dependency in > > TTM and moving GPU address calculation to individual drm drivers. This > > cleanup will simplify introduction of drm_mem_region/domain work started > > by Brian Welty[1]. > > > > > > It would be nice if someone test this for nouveau. Rest of the drivers > > are already tested. > > > > v2: > > * set bo->offset = 0 for drm/nouveau if bo->mem.mm_node == NULL > > > > v3: > > * catch return value of drm_gem_vram_offset() in drm/bochs > > * introduce drm_gem_vram_pg_offset() in vram helper > > * improve nbo->offset calculation for nouveau > > > > v4: > > * minor coding style fixes in amdgpu and radeon > > * remove unnecessary kerneldoc for internal function > > > > v5: > > * rebase on top of drm-misc-next > > * fix return value of drm_gem_vram_pg_offset() > > * add a comment in drm_gem_vram_pg_offset() to clearify why we return 0. > > > > v6: > > * rebase to drm-misc-next > > * removed acked for vmwgfx as there was a small conflict > > > > Nirmoy Das (8): > >drm/amdgpu: move ttm bo->offset to amdgpu_bo > >drm/radeon: don't use ttm bo->offset > >drm/vmwgfx: don't use ttm bo->offset > >drm/nouveau: don't use ttm bo->offset v3 > >drm/qxl: don't use ttm bo->offset > >drm/vram-helper: don't use ttm bo->offset v4 > >drm/bochs: use drm_gem_vram_offset to get bo offset v2 > >drm/ttm: do not keep GPU dependent addresses > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 23 ++-- > > drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 1 + > > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 30 - > > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 1 + > > drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c | 4 +-- > > drivers/gpu/drm/bochs/bochs_kms.c | 7 - > > drivers/gpu/drm/drm_gem_vram_helper.c | 11 +++- > > drivers/gpu/drm/nouveau/dispnv04/crtc.c | 6 ++--- > > drivers/gpu/drm/nouveau/dispnv04/disp.c | 3 ++- > > drivers/gpu/drm/nouveau/dispnv04/overlay.c | 6 ++--- > > drivers/gpu/drm/nouveau/dispnv50/base507c.c | 2 +- > > drivers/gpu/drm/nouveau/dispnv50/core507d.c | 2 +- > > drivers/gpu/drm/nouveau/dispnv50/ovly507e.c | 2 +- > > drivers/gpu/drm/nouveau/dispnv50/wndw.c | 2 +- > > drivers/gpu/drm/nouveau/dispnv50/wndwc37e.c | 2 +- > > drivers/gpu/drm/nouveau/nouveau_abi16.c | 8 +++--- > > drivers/gpu/drm/nouveau/nouveau_bo.c| 8 ++ > > drivers/gpu/drm/nouveau/nouveau_bo.h| 3 +++ > > drivers/gpu/drm/nouveau/nouveau_chan.c | 2 +- > > drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +- > > drivers/gpu/drm/nouveau/nouveau_fbcon.c | 2 +- > > drivers/gpu/drm/nouveau/nouveau_gem.c | 10 +++ > > drivers/gpu/drm/qxl/qxl_drv.h | 6 ++--- > > drivers/gpu/drm/qxl/qxl_kms.c | 5 ++-- > > drivers/gpu/drm/qxl/qxl_object.h| 5 > > drivers/gpu/drm/qxl/qxl_ttm.c | 9 --- > > drivers/gpu/drm/radeon/radeon.h | 1 + > > drivers/gpu/drm/radeon/radeon_object.h | 16 ++- > > drivers/gpu/drm/radeon/radeon_ttm.c | 4 +-- > > drivers/gpu/drm/ttm/ttm_bo.c| 7 - > > drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 4 +-- > > drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 2 +- > > drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c| 2 +- > > drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 -- > > include/drm/ttm/ttm_bo_api.h| 2 -- > > include/drm/ttm/ttm_bo_driver.h | 1 - > > 36 files changed, 125 insertions(+), 78 deletions(-) > > > > -- > > 2.27.0 > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 207901] Nouveau: In a 4 monitor setup, 1-2 displays remains black after boot
https://bugzilla.kernel.org/show_bug.cgi?id=207901 --- Comment #21 from Maurice Gale (mauricega...@gmail.com) --- Created attachment 289887 --> https://bugzilla.kernel.org/attachment.cgi?id=289887&action=edit Log after Nouveau Patch -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 207901] Nouveau: In a 4 monitor setup, 1-2 displays remains black after boot
https://bugzilla.kernel.org/show_bug.cgi?id=207901 --- Comment #20 from Maurice Gale (mauricega...@gmail.com) --- Hi, I tried the patch, but I am still missing two displays. I have attached the new log. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/5] drm/etnaviv: Ignore MC bit when checking for runtime suspend
Hi, On Tue, Mar 03, 2020 at 12:55:04PM +0100, Lucas Stach wrote: > On Mo, 2020-03-02 at 20:13 +0100, Guido Günther wrote: > > At least GC7000 fails to enter runtime suspend for long periods of time > > since > > the MC becomes busy again even when the FE is idle. The rest of the series > > makes detecting similar issues easier to debug in the future by checking > > all known bits in debugfs and also warning in the EBUSY case. > > Thanks, series applied to etnaviv/next. > > > Tested on GC7000 with a reduced runtime delay of 50ms. Patches are > > against next-20200226. > > I've already wondered if 200ms is too long, 50ms sounds more > reasonable. Do you have any numbers on the power draw on the i.MX8M > with idle GPU, vs. being fully power gated? The difference is at least 250mW. It makes a huge difference over here. We hit https://lore.kernel.org/dri-devel/20200614064601.7872-1-navid.emamdo...@gmail.com/ recently and you notice instantly when that happens when looking at the SoC temperature. Cheers, -- Guido > > Regards, > Lucas > > > Thanks to Lucas Stach for pointing me in the right direction. > > > > Guido Günther (5): > > drm/etnaviv: Fix typo in comment > > drm/etnaviv: Update idle bits > > drm/etnaviv: Consider all kwnown idle bits in debugfs > > drm/etnaviv: Ignore MC when checking runtime suspend idleness > > drm/etnaviv: Warn when GPU doesn't idle fast enough > > > > drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 26 ++ > > drivers/gpu/drm/etnaviv/state_hi.xml.h | 7 +++ > > 2 files changed, 29 insertions(+), 4 deletions(-) > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 02/17] drm/i915: Clear the repeater bit on HDCP disable
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: ee5e5e7a5e0f ("drm/i915: Add HDCP framework + base
implementation").
The bot has tested the following trees: v5.7.5, v5.4.48, v4.19.129.
v5.7.5: Build OK!
v5.4.48: Failed to apply! Possible dependencies:
692059318c0fc ("drm/i915/hdcp: Enable HDCP 1.4 and 2.2 on Gen12+")
v4.19.129: Failed to apply! Possible dependencies:
0e39037b31655 ("drm/i915: Cache the error string")
16e4dd0342a80 ("drm/i915: Markup paired operations on wakerefs")
39e2f501c1b43 ("drm/i915: Split struct intel_context definition to its own
header")
408bd91786665 ("drm/i915: extract intel_hdcp.h from intel_drv.h")
52c0fdb25c7c9 ("drm/i915: Replace global breadcrumbs with per-context
interrupt tracking")
538ef96b9dae7 ("drm/i915/gem: Track the rpm wakerefs")
692059318c0fc ("drm/i915/hdcp: Enable HDCP 1.4 and 2.2 on Gen12+")
6b048706f407f ("drm/i915: Forcibly flush unwanted requests in drop-caches")
87f1ef225242d ("drm/i915: Record the sseu configuration per-context &
engine")
95fd94a645f75 ("drm/i915: avoid rebuilding i915_gpu_error.o on version
string updates")
c0a6aa7ec2c36 ("drm/i915: Show actual alongside requested frequency in
debugfs/i915_rps_boost_info")
c2400ec3b6d15 ("drm/i915: add Makefile magic for testing headers are
self-contained")
c44301fce6146 ("drm/i915: Allow control of PSR at runtime through debugfs,
v6")
e0516e83640e1 ("drm/i915: Move sandybride pcode access to intel_sideband.c")
e1ef734eaec54 ("drm/i915: make intel_frontbuffer.h self-contained")
e6154e4cb8b0d ("drm/i915: Skip the ERR_PTR error state")
eb8d0f5af4ec2 ("drm/i915: Remove GPU reset dependence on struct_mutex")
fb6f0b64e455b ("drm/i915: Prevent machine hang from Broxton's vtd w/a and
error capture")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks
Sasha
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 01/17] drm/i915: Fix sha_text population code
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: ee5e5e7a5e0f ("drm/i915: Add HDCP framework + base
implementation").
The bot has tested the following trees: v5.7.5, v5.4.48, v4.19.129.
v5.7.5: Build OK!
v5.4.48: Failed to apply! Possible dependencies:
65833c463886f ("drm/i915/hdcp: conversion to struct drm_device based
logging macros.")
667944ad77f19 ("drm/i915/hdcp: use intel_de_*() functions for register
access")
692059318c0fc ("drm/i915/hdcp: Enable HDCP 1.4 and 2.2 on Gen12+")
v4.19.129: Failed to apply! Possible dependencies:
04707f9716363 ("drm/i915: Initialize HDCP2.2")
09d56393c1d8d ("drm/i915: hdcp1.4 CP_IRQ handling and SW encryption
tracking")
2f80d7bd8d93c ("drm/i915: drop all drmP.h includes")
33b7f3ee6e008 ("drm/i915: Add CRTC output format YCBCR 4:2:0")
340a44bef2342 ("drm/i915/icl: program MG_DP_MODE")
342ac601df642 ("drm/i915: hdcp_check_link only on CP_IRQ")
47658556da857 ("drm/i915/dp: Do not grab crtc modeset lock in
intel_dp_detect()")
667944ad77f19 ("drm/i915/hdcp: use intel_de_*() functions for register
access")
668b6c176c33f ("drm/i915: Add YCBCR 4:2:0/4:4:4 support for LSPCON")
7b610f1fbed2a ("drm/i915/dp: Add DSC params and DSC config to
intel_crtc_state")
9055aac76589c ("drm/i915: MEI interface implementation")
9844bc87cb7a5 ("drm/i915/dp: Fix duplication of DEVICE_SERVICE_IRQ
handling")
bdc93fe0eb82f ("drm/i915/debugfs: hdcp capability of a sink")
cbfa8ac835cb4 ("drm/i915/dp: Kill intel_dp->detect_done flag")
d3dacc70797b8 ("drm/i915: wrapping all hdcp var into intel_hdcp")
d5acd97f55711 ("drm/i915/dp: Use a local variable for intel_encoder *")
d78aa650670d2 ("drm: Add drm/drm_util.h header file")
de25eb7f3075f ("drm/i915: introduce dp_to_i915() helper")
f106d1005ac72 ("drm/i915: Pullout the bksv read and validation")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks
Sasha
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/atomic_helper: duplicate state for drm_private_obj
On Thu, Jun 25, 2020 at 5:35 AM Daniel Vetter wrote: > > On Thu, Jun 25, 2020 at 1:58 PM Shawn Guo wrote: > > > > From: Shawn Guo > > > > The msm/mdp5 driver uses drm_private_obj as its global atomic state, > > which keeps the assignment of hwpipe to plane. With drm_private_obj > > missing from duplicate state call, mdp5 suspend works with no problem > > only for the very first time. Any subsequent suspend will hit the > > following warning, because hwpipe assignment doesn't get duplicated for > > suspend state. Adding drm_private_obj handling for duplicate state call > > fixes the problem. > > If the driver needs a private state, it's supposed to duplicate that > in its atomic_check functionality. This isn't the helper's job. > > If this is a bug in msm code, then pretty sure if you try hard enough, > you can hit the exact same bug from userspace too. Maybe good idea to > try and reproduce this with igt or something. The problem is how duplicate_state is used by the atomic suspend/resume helpers. They duplicate the running state on suspend, forgetting to duplicate the global state. Then everything is disabled, the driver correctly duplicates and updates it's global atomic state releasing the hwpipe. But then on resume, we are re-applying plane state that thinks it already has a hwpipe assigned (because that is part of the plane state that was duplicated), without reapplying the matching global state. On a normal atomic commit, we would duplicate the plane state that has the hwpipe disabled, which would be in sync with the drivers global state. But since that is not what the atomic resume helper does, we hit the situation where the plane state and the global state are out of sync. So the driver is dtrt, the problem really is with the helpers. I think this patch is the right thing to do. It is incorrect for the suspend/resume helpers to assume that they can re-apply duplicated state without including the global state. BR, -R > -Daniel > > > > $ echo mem > /sys/power/state > > [ 38.44] PM: suspend entry (deep) > > [ 38.85] PM: Syncing filesystems ... done. > > [ 38.114630] Freezing user space processes ... (elapsed 0.001 seconds) > > done. > > [ 38.115912] OOM killer disabled. > > [ 38.115914] Freezing remaining freezable tasks ... (elapsed 0.001 > > seconds) done. > > [ 38.122170] [ cut here ] > > [ 38.122212] WARNING: CPU: 0 PID: 1747 at > > drivers/gpu/drm/msm/disp/mdp5/mdp5_pipe.c:145 mdp5_pipe_release+0x90/0xc0 > > [ 38.122215] Modules linked in: > > [ 38.12] CPU: 0 PID: 1747 Comm: sh Not tainted > > 4.19.107-00515-g9d5e4d7a33ed-dirty #323 > > [ 38.14] Hardware name: Square, Inc. T2 Devkit (DT) > > [ 38.18] pstate: 4005 (nZcv daif -PAN -UAO) > > [ 38.122230] pc : mdp5_pipe_release+0x90/0xc0 > > [ 38.122233] lr : mdp5_pipe_release+0x90/0xc0 > > [ 38.122235] sp : 0d13b7f0 > > [ 38.122236] x29: 0d13b7f0 x28: > > [ 38.122240] x27: 0002 x26: 800079adce00 > > [ 38.122243] x25: 800079405200 x24: > > [ 38.122246] x23: 80007a78cc08 x22: 80007b1cc018 > > [ 38.122249] x21: 80007b1cc000 x20: 80007b317080 > > [ 38.122252] x19: 80007a78ce80 x18: 0002 > > [ 38.122255] x17: x16: > > [ 38.122258] x15: fff0 x14: 08c3fb48 > > [ 38.122261] x13: 08cdac4a x12: 08c3f000 > > [ 38.122264] x11: x10: 08cda000 > > [ 38.122267] x9 : x8 : 08ce4a40 > > [ 38.122269] x7 : x6 : 39ea41a9 > > [ 38.122272] x5 : x4 : > > [ 38.122275] x3 : x2 : c7580c109cae4500 > > [ 38.122278] x1 : x0 : 0024 > > [ 38.122281] Call trace: > > [ 38.122285] mdp5_pipe_release+0x90/0xc0 > > [ 38.122288] mdp5_plane_atomic_check+0x2c0/0x448 > > [ 38.122294] drm_atomic_helper_check_planes+0xd0/0x208 > > [ 38.122298] drm_atomic_helper_check+0x38/0xa8 > > [ 38.122302] drm_atomic_check_only+0x3e8/0x630 > > [ 38.122305] drm_atomic_commit+0x18/0x58 > > [ 38.122309] __drm_atomic_helper_disable_all.isra.12+0x15c/0x1a8 > > [ 38.122312] drm_atomic_helper_suspend+0x80/0xf0 > > [ 38.122316] msm_pm_suspend+0x4c/0x70 > > [ 38.122320] dpm_run_callback.isra.6+0x20/0x68 > > [ 38.122323] __device_suspend+0x110/0x308 > > [ 38.122326] dpm_suspend+0x100/0x1f0 > > [ 38.122329] dpm_suspend_start+0x64/0x70 > > [ 38.122334] suspend_devices_and_enter+0x110/0x500 > > [ 38.122336] pm_suspend+0x268/0x2c0 > > [ 38.122339] state_store+0x88/0x110 > > [ 38.122345] kobj_attr_store+0x14/0x28 > > [ 38.122352] sysfs_kf_write+0x3c/0x50 > > [ 38.122355] kernfs_fop_write+0x118/0x1e0 > > [ 38.122360] __vfs_write+0x30/0x168 > > [ 38.122363] vfs_write+0xa4/0x1a8 > > [ 38.122366] ksys_write+0x64/
Re: [Intel-gfx] [PATCH 2/2] dma-buf: fix dma-fence-chain out of order test
On Thu, Jun 25, 2020 at 3:23 PM Lionel Landwerlin wrote: > > On 25/06/2020 16:18, Chris Wilson wrote: > > Quoting Lionel Landwerlin (2020-06-25 13:34:43) > >> There was probably a misunderstand on how the dma-fence-chain is > >> supposed to work or what dma_fence_chain_find_seqno() is supposed to > >> return. > >> > >> dma_fence_chain_find_seqno() is here to give us the fence to wait upon > >> for a particular point in the timeline. The timeline progresses only > >> when all the points prior to a given number have completed. > > Hmm, the question was what point is it supposed to wait for. > > > > For the simple chain of [1, 3], does 1 being signaled imply that all > > points up to 3 are signaled, or does 3 not being signaled imply that all > > points after 1 are not. If that's mentioned already somewhere, my bad. > > If not, could you put the answer somewhere. > > -Chris > > In [1, 3], if 1 is signaled, the timeline value is 1. And find_seqno(2) > should return NULL. > > > In the out_of_order selftest the chain was [1, 2, 3], 2 was signaled and > the test was expecting no fence to be returned by find_seqno(2). > > But we still have to wait on 1 to complete before find_seqno(2) can > return NULL (as in you don't have to wait on anything). > > > Hope that answer the question. I asked Christian to document why timeline works like this, but I can't find it in the kerneldoc right now. If it's missing I think we should fix that and add the explanation, iirc it was around gpu reset creating too much havoc otherwise. -Daniel > > > -Lionel > > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/2] dma-buf: fix dma-fence-chain out of order test
On 25/06/2020 16:47, Chris Wilson wrote: Quoting Lionel Landwerlin (2020-06-25 14:23:25) On 25/06/2020 16:18, Chris Wilson wrote: Quoting Lionel Landwerlin (2020-06-25 13:34:43) There was probably a misunderstand on how the dma-fence-chain is supposed to work or what dma_fence_chain_find_seqno() is supposed to return. dma_fence_chain_find_seqno() is here to give us the fence to wait upon for a particular point in the timeline. The timeline progresses only when all the points prior to a given number have completed. Hmm, the question was what point is it supposed to wait for. For the simple chain of [1, 3], does 1 being signaled imply that all points up to 3 are signaled, or does 3 not being signaled imply that all points after 1 are not. If that's mentioned already somewhere, my bad. If not, could you put the answer somewhere. -Chris In [1, 3], if 1 is signaled, the timeline value is 1. And find_seqno(2) should return NULL. In the out_of_order selftest the chain was [1, 2, 3], 2 was signaled and the test was expecting no fence to be returned by find_seqno(2). But we still have to wait on 1 to complete before find_seqno(2) can return NULL (as in you don't have to wait on anything). * scratches head I thought it was meant to be expecting fc.chain[1] to still be present as the chain at that point was not yet signaled. You're right that the point is not yet signaled. But it doesn't need to stay in the chain if you can wait on a previous point. chain[1] gets removed as we walk the chain backward in dma_fence_chain_walk. -Lionel Oh well, a mistake compounded. :| -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/2] dma-buf: fix dma-fence-chain out of order test
Quoting Lionel Landwerlin (2020-06-25 14:23:25) > On 25/06/2020 16:18, Chris Wilson wrote: > > Quoting Lionel Landwerlin (2020-06-25 13:34:43) > >> There was probably a misunderstand on how the dma-fence-chain is > >> supposed to work or what dma_fence_chain_find_seqno() is supposed to > >> return. > >> > >> dma_fence_chain_find_seqno() is here to give us the fence to wait upon > >> for a particular point in the timeline. The timeline progresses only > >> when all the points prior to a given number have completed. > > Hmm, the question was what point is it supposed to wait for. > > > > For the simple chain of [1, 3], does 1 being signaled imply that all > > points up to 3 are signaled, or does 3 not being signaled imply that all > > points after 1 are not. If that's mentioned already somewhere, my bad. > > If not, could you put the answer somewhere. > > -Chris > > In [1, 3], if 1 is signaled, the timeline value is 1. And find_seqno(2) > should return NULL. > > > In the out_of_order selftest the chain was [1, 2, 3], 2 was signaled and > the test was expecting no fence to be returned by find_seqno(2). > > But we still have to wait on 1 to complete before find_seqno(2) can > return NULL (as in you don't have to wait on anything). * scratches head I thought it was meant to be expecting fc.chain[1] to still be present as the chain at that point was not yet signaled. Oh well, a mistake compounded. :| -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 7/9] drm/simplekms: Acquire regulators from DT device node
Hi Thomas,
On Thu, Jun 25, 2020 at 2:00 PM Thomas Zimmermann wrote:
> Make sure required hardware regulators are enabled while the firmware
> framebuffer is in use.
>
> The basic code has been taken from the simplefb driver and adapted
> to DRM. Regulators are released automatically via devres helpers.
>
> Signed-off-by: Thomas Zimmermann
Thanks for your patch!
> --- a/drivers/gpu/drm/tiny/simplekms.c
> +++ b/drivers/gpu/drm/tiny/simplekms.c
> @@ -4,6 +4,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -198,6 +199,11 @@ struct simplekms_device {
> unsigned int clk_count;
> struct clk **clks;
> #endif
> + /* regulators */
> +#if defined CONFIG_OF && defined CONFIG_REGULATOR
> + unsigned int regulator_count;
> + struct regulator **regulators;
> +#endif
>
> /* simplefb settings */
> struct drm_display_mode mode;
> @@ -315,6 +321,125 @@ static int simplekms_device_init_clocks(struct
> simplekms_device *sdev)
> }
> #endif
>
> +#if defined CONFIG_OF && defined CONFIG_REGULATOR
> +
> +#define SUPPLY_SUFFIX "-supply"
> +
> +/*
> + * Regulator handling code.
> + *
> + * Here we handle the num-supplies and vin*-supply properties of our
> + * "simple-framebuffer" dt node. This is necessary so that we can make sure
> + * that any regulators needed by the display hardware that the bootloader
> + * set up for us (and for which it provided a simplefb dt node), stay up,
> + * for the life of the simplefb driver.
Looks like there's a bulk regulator API, too?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/9] drm/simplekms: Acquire clocks from DT device node
Hi Thomas,
On Thu, Jun 25, 2020 at 2:00 PM Thomas Zimmermann wrote:
> Make sure required hardware clocks are enabled while the firmware
> framebuffer is in use.
>
> The basic code has been taken from the simplefb driver and adapted
> to DRM. Clocks are released automatically via devres helpers.
>
> Signed-off-by: Thomas Zimmermann
Thanks for your patch!
> --- a/drivers/gpu/drm/tiny/simplekms.c
> +++ b/drivers/gpu/drm/tiny/simplekms.c
> @@ -210,6 +218,103 @@ static struct simplekms_device
> *simplekms_device_of_dev(struct drm_device *dev)
> return container_of(dev, struct simplekms_device, dev);
> }
>
> +/*
> + * Hardware
> + */
> +
> +#if defined CONFIG_OF && defined CONFIG_COMMON_CLK
> +/*
> + * Clock handling code.
> + *
> + * Here we handle the clocks property of our "simple-framebuffer" dt node.
> + * This is necessary so that we can make sure that any clocks needed by
> + * the display engine that the bootloader set up for us (and for which it
> + * provided a simplefb dt node), stay up, for the life of the simplefb
> + * driver.
> + *
> + * When the driver unloads, we cleanly disable, and then release the clocks.
> + *
> + * We only complain about errors here, no action is taken as the most likely
> + * error can only happen due to a mismatch between the bootloader which set
> + * up simplefb, and the clock definitions in the device tree. Chances are
> + * that there are no adverse effects, and if there are, a clean teardown of
> + * the fb probe will not help us much either. So just complain and carry on,
> + * and hope that the user actually gets a working fb at the end of things.
> + */
> +
> +static void simplekms_device_release_clocks(void *res)
> +{
> + struct simplekms_device *sdev = simplekms_device_of_dev(res);
> + unsigned int i;
> +
> + for (i = 0; i < sdev->clk_count; ++i) {
> + if (sdev->clks[i]) {
> + clk_disable_unprepare(sdev->clks[i]);
> + clk_put(sdev->clks[i]);
> + }
> + }
> +}
> +
> +static int simplekms_device_init_clocks(struct simplekms_device *sdev)
> +{
> + struct drm_device *dev = &sdev->dev;
> + struct platform_device *pdev = sdev->pdev;
> + struct device_node *of_node = pdev->dev.of_node;
> + struct clk *clock;
> + unsigned int i;
> + int ret;
> +
> + if (dev_get_platdata(&pdev->dev) || !of_node)
> + return 0;
> +
> + sdev->clk_count = of_clk_get_parent_count(of_node);
> + if (!sdev->clk_count)
> + return 0;
> +
> + sdev->clks = drmm_kzalloc(dev, sdev->clk_count *
> sizeof(sdev->clks[0]),
> + GFP_KERNEL);
> + if (!sdev->clks)
> + return -ENOMEM;
> +
> + for (i = 0; i < sdev->clk_count; ++i) {
> + clock = of_clk_get(of_node, i);
clk_bulk_get_all()?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/2] dma-buf: fix dma-fence-chain out of order test
On 25/06/2020 16:18, Chris Wilson wrote: Quoting Lionel Landwerlin (2020-06-25 13:34:43) There was probably a misunderstand on how the dma-fence-chain is supposed to work or what dma_fence_chain_find_seqno() is supposed to return. dma_fence_chain_find_seqno() is here to give us the fence to wait upon for a particular point in the timeline. The timeline progresses only when all the points prior to a given number have completed. Hmm, the question was what point is it supposed to wait for. For the simple chain of [1, 3], does 1 being signaled imply that all points up to 3 are signaled, or does 3 not being signaled imply that all points after 1 are not. If that's mentioned already somewhere, my bad. If not, could you put the answer somewhere. -Chris In [1, 3], if 1 is signaled, the timeline value is 1. And find_seqno(2) should return NULL. In the out_of_order selftest the chain was [1, 2, 3], 2 was signaled and the test was expecting no fence to be returned by find_seqno(2). But we still have to wait on 1 to complete before find_seqno(2) can return NULL (as in you don't have to wait on anything). Hope that answer the question. -Lionel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/2] dma-buf: fix dma-fence-chain out of order test
Quoting Lionel Landwerlin (2020-06-25 13:34:43) > There was probably a misunderstand on how the dma-fence-chain is > supposed to work or what dma_fence_chain_find_seqno() is supposed to > return. > > dma_fence_chain_find_seqno() is here to give us the fence to wait upon > for a particular point in the timeline. The timeline progresses only > when all the points prior to a given number have completed. Hmm, the question was what point is it supposed to wait for. For the simple chain of [1, 3], does 1 being signaled imply that all points up to 3 are signaled, or does 3 not being signaled imply that all points after 1 are not. If that's mentioned already somewhere, my bad. If not, could you put the answer somewhere. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] Revert "dma-buf: Report signaled links inside dma-fence-chain"
Am 25.06.20 um 14:34 schrieb Lionel Landwerlin:
This reverts commit 5de376bb434f80a13138f0ebedc8351ab73d8b0d.
This change breaks synchronization of a timeline.
dma_fence_chain_find_seqno() might be a bit of a confusing name but
this function is not trying to find a particular seqno, is supposed to
give a fence to wait on for a particular point in the timeline.
In a timeline, a particular value is reached when all the points up to
and including that value have signaled.
Signed-off-by: Lionel Landwerlin
Reviewed-by: Christian König
---
drivers/dma-buf/dma-fence-chain.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/dma-buf/dma-fence-chain.c
b/drivers/dma-buf/dma-fence-chain.c
index c435bbba851c..3d123502ff12 100644
--- a/drivers/dma-buf/dma-fence-chain.c
+++ b/drivers/dma-buf/dma-fence-chain.c
@@ -99,12 +99,6 @@ int dma_fence_chain_find_seqno(struct dma_fence **pfence,
uint64_t seqno)
return -EINVAL;
dma_fence_chain_for_each(*pfence, &chain->base) {
- if ((*pfence)->seqno < seqno) { /* already signaled */
- dma_fence_put(*pfence);
- *pfence = NULL;
- break;
- }
-
if ((*pfence)->context != chain->base.context ||
to_dma_fence_chain(*pfence)->prev_seqno < seqno)
break;
@@ -228,7 +222,6 @@ EXPORT_SYMBOL(dma_fence_chain_ops);
* @chain: the chain node to initialize
* @prev: the previous fence
* @fence: the current fence
- * @seqno: the sequence number (syncpt) of the fence within the chain
*
* Initialize a new chain node and either start a new chain or add the node to
* the existing chain of the previous fence.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] dma-buf: fix dma-fence-chain out of order test
Am 25.06.20 um 14:34 schrieb Lionel Landwerlin:
There was probably a misunderstand on how the dma-fence-chain is
supposed to work or what dma_fence_chain_find_seqno() is supposed to
return.
dma_fence_chain_find_seqno() is here to give us the fence to wait upon
for a particular point in the timeline. The timeline progresses only
when all the points prior to a given number have completed.
Signed-off-by: Lionel Landwerlin
Fixes: dc2f7e67a28a5c ("dma-buf: Exercise dma-fence-chain under selftests")
Acked-by: Christian König
---
drivers/dma-buf/st-dma-fence-chain.c | 43 ++--
1 file changed, 21 insertions(+), 22 deletions(-)
diff --git a/drivers/dma-buf/st-dma-fence-chain.c
b/drivers/dma-buf/st-dma-fence-chain.c
index 5d45ba7ba3cd..9525f7f56119 100644
--- a/drivers/dma-buf/st-dma-fence-chain.c
+++ b/drivers/dma-buf/st-dma-fence-chain.c
@@ -318,15 +318,16 @@ static int find_out_of_order(void *arg)
goto err;
}
- if (fence && fence != fc.chains[1]) {
+ /*
+* We signaled the middle fence (2) of the 1-2-3 chain. The behavior
+* of the dma-fence-chain is to make us wait for all the fences up to
+* the point we want. Since fence 1 is still not signaled, this what
+* we should get as fence to wait upon (fence 2 being garbage
+* collected during the traversal of the chain).
+*/
+ if (fence != fc.chains[0]) {
pr_err("Incorrect chain-fence.seqno:%lld reported for completed
seqno:2\n",
- fence->seqno);
-
- dma_fence_get(fence);
- err = dma_fence_chain_find_seqno(&fence, 2);
- dma_fence_put(fence);
- if (err)
- pr_err("Reported %d for finding self!\n", err);
+ fence ? fence->seqno : 0);
err = -EINVAL;
}
@@ -415,20 +416,18 @@ static int __find_race(void *arg)
if (!fence)
goto signal;
- err = dma_fence_chain_find_seqno(&fence, seqno);
- if (err) {
- pr_err("Reported an invalid fence for find-self:%d\n",
- seqno);
- dma_fence_put(fence);
- break;
- }
-
- if (fence->seqno < seqno) {
- pr_err("Reported an earlier fence.seqno:%lld for
seqno:%d\n",
- fence->seqno, seqno);
- err = -EINVAL;
- dma_fence_put(fence);
- break;
+ /*
+* We can only find ourselves if we are on fence we were
+* looking for.
+*/
+ if (fence->seqno == seqno) {
+ err = dma_fence_chain_find_seqno(&fence, seqno);
+ if (err) {
+ pr_err("Reported an invalid fence for
find-self:%d\n",
+ seqno);
+ dma_fence_put(fence);
+ break;
+ }
}
dma_fence_put(fence);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/atomic_helper: duplicate state for drm_private_obj
On Thu, Jun 25, 2020 at 1:58 PM Shawn Guo wrote:
>
> From: Shawn Guo
>
> The msm/mdp5 driver uses drm_private_obj as its global atomic state,
> which keeps the assignment of hwpipe to plane. With drm_private_obj
> missing from duplicate state call, mdp5 suspend works with no problem
> only for the very first time. Any subsequent suspend will hit the
> following warning, because hwpipe assignment doesn't get duplicated for
> suspend state. Adding drm_private_obj handling for duplicate state call
> fixes the problem.
If the driver needs a private state, it's supposed to duplicate that
in its atomic_check functionality. This isn't the helper's job.
If this is a bug in msm code, then pretty sure if you try hard enough,
you can hit the exact same bug from userspace too. Maybe good idea to
try and reproduce this with igt or something.
-Daniel
> $ echo mem > /sys/power/state
> [ 38.44] PM: suspend entry (deep)
> [ 38.85] PM: Syncing filesystems ... done.
> [ 38.114630] Freezing user space processes ... (elapsed 0.001 seconds) done.
> [ 38.115912] OOM killer disabled.
> [ 38.115914] Freezing remaining freezable tasks ... (elapsed 0.001 seconds)
> done.
> [ 38.122170] [ cut here ]
> [ 38.122212] WARNING: CPU: 0 PID: 1747 at
> drivers/gpu/drm/msm/disp/mdp5/mdp5_pipe.c:145 mdp5_pipe_release+0x90/0xc0
> [ 38.122215] Modules linked in:
> [ 38.12] CPU: 0 PID: 1747 Comm: sh Not tainted
> 4.19.107-00515-g9d5e4d7a33ed-dirty #323
> [ 38.14] Hardware name: Square, Inc. T2 Devkit (DT)
> [ 38.18] pstate: 4005 (nZcv daif -PAN -UAO)
> [ 38.122230] pc : mdp5_pipe_release+0x90/0xc0
> [ 38.122233] lr : mdp5_pipe_release+0x90/0xc0
> [ 38.122235] sp : 0d13b7f0
> [ 38.122236] x29: 0d13b7f0 x28:
> [ 38.122240] x27: 0002 x26: 800079adce00
> [ 38.122243] x25: 800079405200 x24:
> [ 38.122246] x23: 80007a78cc08 x22: 80007b1cc018
> [ 38.122249] x21: 80007b1cc000 x20: 80007b317080
> [ 38.122252] x19: 80007a78ce80 x18: 0002
> [ 38.122255] x17: x16:
> [ 38.122258] x15: fff0 x14: 08c3fb48
> [ 38.122261] x13: 08cdac4a x12: 08c3f000
> [ 38.122264] x11: x10: 08cda000
> [ 38.122267] x9 : x8 : 08ce4a40
> [ 38.122269] x7 : x6 : 39ea41a9
> [ 38.122272] x5 : x4 :
> [ 38.122275] x3 : x2 : c7580c109cae4500
> [ 38.122278] x1 : x0 : 0024
> [ 38.122281] Call trace:
> [ 38.122285] mdp5_pipe_release+0x90/0xc0
> [ 38.122288] mdp5_plane_atomic_check+0x2c0/0x448
> [ 38.122294] drm_atomic_helper_check_planes+0xd0/0x208
> [ 38.122298] drm_atomic_helper_check+0x38/0xa8
> [ 38.122302] drm_atomic_check_only+0x3e8/0x630
> [ 38.122305] drm_atomic_commit+0x18/0x58
> [ 38.122309] __drm_atomic_helper_disable_all.isra.12+0x15c/0x1a8
> [ 38.122312] drm_atomic_helper_suspend+0x80/0xf0
> [ 38.122316] msm_pm_suspend+0x4c/0x70
> [ 38.122320] dpm_run_callback.isra.6+0x20/0x68
> [ 38.122323] __device_suspend+0x110/0x308
> [ 38.122326] dpm_suspend+0x100/0x1f0
> [ 38.122329] dpm_suspend_start+0x64/0x70
> [ 38.122334] suspend_devices_and_enter+0x110/0x500
> [ 38.122336] pm_suspend+0x268/0x2c0
> [ 38.122339] state_store+0x88/0x110
> [ 38.122345] kobj_attr_store+0x14/0x28
> [ 38.122352] sysfs_kf_write+0x3c/0x50
> [ 38.122355] kernfs_fop_write+0x118/0x1e0
> [ 38.122360] __vfs_write+0x30/0x168
> [ 38.122363] vfs_write+0xa4/0x1a8
> [ 38.122366] ksys_write+0x64/0xe8
> [ 38.122368] __arm64_sys_write+0x18/0x20
> [ 38.122374] el0_svc_common+0x6c/0x178
> [ 38.122377] el0_svc_compat_handler+0x1c/0x28
> [ 38.122381] el0_svc_compat+0x8/0x18
> [ 38.122383] ---[ end trace 24145b7d8545345b ]---
> [ 38.491552] Disabling non-boot CPUs ...
>
> Signed-off-by: Shawn Guo
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 85d163f16801..024985a92156 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3140,6 +3140,7 @@ drm_atomic_helper_duplicate_state(struct drm_device
> *dev,
> struct drm_atomic_state *state;
> struct drm_connector *conn;
> struct drm_connector_list_iter conn_iter;
> + struct drm_private_obj *priv_obj;
> struct drm_plane *plane;
> struct drm_crtc *crtc;
> int err = 0;
> @@ -3184,6 +3185,16 @@ drm_atomic_helper_duplicate_state(struct drm_device
> *dev,
> }
> drm_connector_list_iter_end(&conn_iter);
>
> + drm_for_each_privobj(priv_obj, dev) {
> + struct drm_private_state *priv_stat
[PATCH 1/2] Revert "dma-buf: Report signaled links inside dma-fence-chain"
This reverts commit 5de376bb434f80a13138f0ebedc8351ab73d8b0d.
This change breaks synchronization of a timeline.
dma_fence_chain_find_seqno() might be a bit of a confusing name but
this function is not trying to find a particular seqno, is supposed to
give a fence to wait on for a particular point in the timeline.
In a timeline, a particular value is reached when all the points up to
and including that value have signaled.
Signed-off-by: Lionel Landwerlin
---
drivers/dma-buf/dma-fence-chain.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/dma-buf/dma-fence-chain.c
b/drivers/dma-buf/dma-fence-chain.c
index c435bbba851c..3d123502ff12 100644
--- a/drivers/dma-buf/dma-fence-chain.c
+++ b/drivers/dma-buf/dma-fence-chain.c
@@ -99,12 +99,6 @@ int dma_fence_chain_find_seqno(struct dma_fence **pfence,
uint64_t seqno)
return -EINVAL;
dma_fence_chain_for_each(*pfence, &chain->base) {
- if ((*pfence)->seqno < seqno) { /* already signaled */
- dma_fence_put(*pfence);
- *pfence = NULL;
- break;
- }
-
if ((*pfence)->context != chain->base.context ||
to_dma_fence_chain(*pfence)->prev_seqno < seqno)
break;
@@ -228,7 +222,6 @@ EXPORT_SYMBOL(dma_fence_chain_ops);
* @chain: the chain node to initialize
* @prev: the previous fence
* @fence: the current fence
- * @seqno: the sequence number (syncpt) of the fence within the chain
*
* Initialize a new chain node and either start a new chain or add the node to
* the existing chain of the previous fence.
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] dma-buf: fix dma-fence-chain out of order test
There was probably a misunderstand on how the dma-fence-chain is
supposed to work or what dma_fence_chain_find_seqno() is supposed to
return.
dma_fence_chain_find_seqno() is here to give us the fence to wait upon
for a particular point in the timeline. The timeline progresses only
when all the points prior to a given number have completed.
Signed-off-by: Lionel Landwerlin
Fixes: dc2f7e67a28a5c ("dma-buf: Exercise dma-fence-chain under selftests")
---
drivers/dma-buf/st-dma-fence-chain.c | 43 ++--
1 file changed, 21 insertions(+), 22 deletions(-)
diff --git a/drivers/dma-buf/st-dma-fence-chain.c
b/drivers/dma-buf/st-dma-fence-chain.c
index 5d45ba7ba3cd..9525f7f56119 100644
--- a/drivers/dma-buf/st-dma-fence-chain.c
+++ b/drivers/dma-buf/st-dma-fence-chain.c
@@ -318,15 +318,16 @@ static int find_out_of_order(void *arg)
goto err;
}
- if (fence && fence != fc.chains[1]) {
+ /*
+* We signaled the middle fence (2) of the 1-2-3 chain. The behavior
+* of the dma-fence-chain is to make us wait for all the fences up to
+* the point we want. Since fence 1 is still not signaled, this what
+* we should get as fence to wait upon (fence 2 being garbage
+* collected during the traversal of the chain).
+*/
+ if (fence != fc.chains[0]) {
pr_err("Incorrect chain-fence.seqno:%lld reported for completed
seqno:2\n",
- fence->seqno);
-
- dma_fence_get(fence);
- err = dma_fence_chain_find_seqno(&fence, 2);
- dma_fence_put(fence);
- if (err)
- pr_err("Reported %d for finding self!\n", err);
+ fence ? fence->seqno : 0);
err = -EINVAL;
}
@@ -415,20 +416,18 @@ static int __find_race(void *arg)
if (!fence)
goto signal;
- err = dma_fence_chain_find_seqno(&fence, seqno);
- if (err) {
- pr_err("Reported an invalid fence for find-self:%d\n",
- seqno);
- dma_fence_put(fence);
- break;
- }
-
- if (fence->seqno < seqno) {
- pr_err("Reported an earlier fence.seqno:%lld for
seqno:%d\n",
- fence->seqno, seqno);
- err = -EINVAL;
- dma_fence_put(fence);
- break;
+ /*
+* We can only find ourselves if we are on fence we were
+* looking for.
+*/
+ if (fence->seqno == seqno) {
+ err = dma_fence_chain_find_seqno(&fence, seqno);
+ if (err) {
+ pr_err("Reported an invalid fence for
find-self:%d\n",
+ seqno);
+ dma_fence_put(fence);
+ break;
+ }
}
dma_fence_put(fence);
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/9] drm/simplekms: Add fbdev emulation
This displays a console on the simplefb framebuffer. The default framebuffer format is being used. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/tiny/simplekms.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/tiny/simplekms.c b/drivers/gpu/drm/tiny/simplekms.c index dc7cf3983945..ac2ebfcedd22 100644 --- a/drivers/gpu/drm/tiny/simplekms.c +++ b/drivers/gpu/drm/tiny/simplekms.c @@ -8,6 +8,7 @@ #include #include #include +#include #include #include #include @@ -469,6 +470,8 @@ static int simplekms_probe(struct platform_device *pdev) if (ret) return ret; + drm_fbdev_generic_setup(dev, 0); + return 0; } -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/9] drm: Add simplekms driver
The simplekms driver is a DRM driver for simplefb framebuffers as
provided by the kernel's boot code. This driver enables basic
graphical output on many different graphics devices that are provided
by the platform (e.g., EFI, VESA, embedded framebuffers).
With the kernel's simplefb infrastructure, the kernel receives a
pre-configured framebuffer from the system (i.e., firmware, boot
loader). It creates a platform device to which simplekms attaches.
The system's framebuffer consists of a memory range, size and format.
Based on these values, simplekms creates a DRM devices. No actual
modesetting is possible.
Signed-off-by: Thomas Zimmermann
---
MAINTAINERS | 6 +
drivers/gpu/drm/tiny/Kconfig | 16 +
drivers/gpu/drm/tiny/Makefile| 1 +
drivers/gpu/drm/tiny/simplekms.c | 495 +++
4 files changed, 518 insertions(+)
create mode 100644 drivers/gpu/drm/tiny/simplekms.c
diff --git a/MAINTAINERS b/MAINTAINERS
index f17d99164a77..ac517dc8d05d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5505,6 +5505,12 @@ S: Orphan / Obsolete
F: drivers/gpu/drm/savage/
F: include/uapi/drm/savage_drm.h
+DRM DRIVER FOR SIMPLE FRAMEBUFFERS
+M: Thomas Zimmermann
+S: Maintained
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F: drivers/gpu/drm/tiny/simplekms.c
+
DRM DRIVER FOR SIS VIDEO CARDS
S: Orphan / Obsolete
F: drivers/gpu/drm/sis/
diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
index 2b6414f0fa75..50dbde8bdcb2 100644
--- a/drivers/gpu/drm/tiny/Kconfig
+++ b/drivers/gpu/drm/tiny/Kconfig
@@ -28,6 +28,22 @@ config DRM_GM12U320
This is a KMS driver for projectors which use the GM12U320 chipset
for video transfer over USB2/3, such as the Acer C120 mini projector.
+config DRM_SIMPLEKMS
+ tristate "Simple framebuffer driver"
+ depends on DRM
+ select DRM_GEM_SHMEM_HELPER
+ select DRM_KMS_HELPER
+ help
+ DRM driver for simple platform-provided framebuffers.
+
+ This driver assumes that the display hardware has been initialized
+ by the firmware or bootloader before the kernel boots. Scanout
+ buffer, size, and display format must be provided via device tree,
+ UEFI, VESA, etc.
+
+ On x86 and compatible, you should also select CONFIG_X86_SYSFB to
+ use UEFI and VESA framebuffers.
+
config TINYDRM_HX8357D
tristate "DRM support for HX8357D display panels"
depends on DRM && SPI
diff --git a/drivers/gpu/drm/tiny/Makefile b/drivers/gpu/drm/tiny/Makefile
index 6ae4e9e5a35f..e83fbbfa7344 100644
--- a/drivers/gpu/drm/tiny/Makefile
+++ b/drivers/gpu/drm/tiny/Makefile
@@ -2,6 +2,7 @@
obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus.o
obj-$(CONFIG_DRM_GM12U320) += gm12u320.o
+obj-$(CONFIG_DRM_SIMPLEKMS)+= simplekms.o
obj-$(CONFIG_TINYDRM_HX8357D) += hx8357d.o
obj-$(CONFIG_TINYDRM_ILI9225) += ili9225.o
obj-$(CONFIG_TINYDRM_ILI9341) += ili9341.o
diff --git a/drivers/gpu/drm/tiny/simplekms.c b/drivers/gpu/drm/tiny/simplekms.c
new file mode 100644
index ..dc7cf3983945
--- /dev/null
+++ b/drivers/gpu/drm/tiny/simplekms.c
@@ -0,0 +1,495 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_NAME"simplekms"
+#define DRIVER_DESC"DRM driver for simple-framebuffer platform devices"
+#define DRIVER_DATE"20200625"
+#define DRIVER_MAJOR 1
+#define DRIVER_MINOR 0
+
+/*
+ * Assume a monitor resolution of 96 dpi to
+ * get a somewhat reasonable screen size.
+ */
+#define RES_MM(d) \
+ (((d) * 254ul) / (96ul * 10ul))
+
+#define SIMPLEKMS_MODE(hd, vd) \
+ DRM_SIMPLE_MODE(hd, vd, RES_MM(hd), RES_MM(vd))
+
+/*
+ * Helpers for simplefb
+ */
+
+static int
+simplefb_get_validated_int(struct drm_device *dev, const char *name,
+ uint32_t value)
+{
+ if (value > INT_MAX) {
+ drm_err(dev, "simplefb: invalid framebuffer %s of %u\n",
+ name, value);
+ return -EINVAL;
+ }
+ return (int)value;
+}
+
+static int
+simplefb_get_validated_int0(struct drm_device *dev, const char *name,
+ uint32_t value)
+{
+ if (!value) {
+ drm_err(dev, "simplefb: invalid framebuffer %s of %u\n",
+ name, value);
+ return -EINVAL;
+ }
+ return simplefb_get_validated_int(dev, name, value);
+}
+
+static const struct drm_format_info *
+simplefb_get_validated_format(struct drm_device *dev, const char *format_name)
+{
+ static const struct simplefb_format formats[] = SIMPLEFB_FORMATS;
+
[PATCH 9/9] drm/simplekms: Acquire memory aperture for framebuffer
We register the simplekms device with the DRM platform helpers. A
native driver for the graphics hardware will kickout the simplekms
driver before taking over the device.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/Kconfig | 1 +
drivers/gpu/drm/tiny/simplekms.c | 94 +++-
2 files changed, 92 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
index 50dbde8bdcb2..a47ed337a7fe 100644
--- a/drivers/gpu/drm/tiny/Kconfig
+++ b/drivers/gpu/drm/tiny/Kconfig
@@ -33,6 +33,7 @@ config DRM_SIMPLEKMS
depends on DRM
select DRM_GEM_SHMEM_HELPER
select DRM_KMS_HELPER
+ select DRM_PLATFORM_HELPER
help
DRM driver for simple platform-provided framebuffers.
diff --git a/drivers/gpu/drm/tiny/simplekms.c b/drivers/gpu/drm/tiny/simplekms.c
index ae5d3cbadbe8..a903a4e0100a 100644
--- a/drivers/gpu/drm/tiny/simplekms.c
+++ b/drivers/gpu/drm/tiny/simplekms.c
@@ -5,6 +5,7 @@
#include
#include
#include
+#include
#include
#include
@@ -17,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
@@ -36,6 +38,12 @@
#define SIMPLEKMS_MODE(hd, vd) \
DRM_SIMPLE_MODE(hd, vd, RES_MM(hd), RES_MM(vd))
+/*
+ * Protects the platform device's drvdata against
+ * concurrent manipulation.
+ */
+static DEFINE_SPINLOCK(simplekms_drvdata_lock);
+
/*
* Helpers for simplefb
*/
@@ -211,6 +219,7 @@ struct simplekms_device {
unsigned int pitch;
/* memory management */
+ struct drm_aperture *aperture;
struct resource *mem;
void __iomem *screen_base;
@@ -224,6 +233,8 @@ static struct simplekms_device
*simplekms_device_of_dev(struct drm_device *dev)
return container_of(dev, struct simplekms_device, dev);
}
+static void simplekms_device_cleanup(struct simplekms_device *sdev);
+
/*
* Hardware
*/
@@ -514,22 +525,72 @@ static int simplekms_device_init_fb(struct
simplekms_device *sdev)
* Memory management
*/
+static void simplekms_aperture_kickout(struct drm_aperture *ap)
+{
+ struct drm_device *dev = ap->dev;
+ struct simplekms_device *sdev = simplekms_device_of_dev(dev);
+ struct platform_device *pdev = sdev->pdev;
+
+ if (WARN_ON(!sdev->aperture))
+ return; /* BUG: driver already got kicked out */
+
+ drm_dev_unregister(dev);
+
+ sdev->aperture = NULL; /* memory is released by platform helpers */
+
+ spin_lock(&simplekms_drvdata_lock);
+ sdev = platform_get_drvdata(pdev);
+ platform_set_drvdata(pdev, NULL); /* required; see simplekms_remove() */
+ spin_unlock(&simplekms_drvdata_lock);
+
+ /*
+* Return if a concurrent simplekms_remove() cleans up the
+* device. See simplekms_remove().
+*/
+ if (!sdev)
+ return;
+
+ /*
+* After the aperture has been released, there's no reason
+* to keep the DRM device around.
+*/
+ simplekms_device_cleanup(sdev);
+}
+
+static const struct drm_aperture_funcs simplekms_aperture_funcs = {
+ .kickout = simplekms_aperture_kickout,
+};
+
static int simplekms_device_init_mm(struct simplekms_device *sdev)
{
+ struct drm_device *dev = &sdev->dev;
struct platform_device *pdev = sdev->pdev;
struct resource *mem;
+ struct drm_aperture *ap;
void __iomem *screen_base;
+ int ret;
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!mem)
return -EINVAL;
+ ap = drmm_aperture_acquire(dev, mem->start, resource_size(mem),
+ &simplekms_aperture_funcs);
+ if (IS_ERR(ap)) {
+ ret = PTR_ERR(ap);
+ drm_err(dev,
+ "could not acquire memory range [0x%llx:0x%llx]: "
+ "error %d\n", mem->start, mem->end, ret);
+ return ret;
+ }
+
screen_base = devm_ioremap_wc(&pdev->dev, mem->start,
resource_size(mem));
if (!screen_base)
return -ENOMEM;
sdev->mem = mem;
+ sdev->aperture = ap;
sdev->screen_base = screen_base;
return 0;
@@ -625,6 +686,9 @@ simplekms_simple_display_pipe_enable(struct
drm_simple_display_pipe *pipe,
struct drm_framebuffer *fb = state->fb;
void *vmap;
+ if (!sdev->aperture)
+ return;
+
vmap = drm_gem_shmem_vmap(fb->obj[0]);
if (!vmap)
return;
@@ -645,6 +709,9 @@ simplekms_simple_display_pipe_update(struct
drm_simple_display_pipe *pipe,
struct drm_rect clip;
void *vmap;
+ if (!sdev->aperture)
+ return;
+
if (!drm_atomic_helper_damage_merged(old_plane_state, state, &clip))
return;
@@ -716,11 +783,12 @@ static int simplekms_device_init_modeset(struct
simplekms_device
[PATCH 8/9] drm: Add infrastructure for platform devices
Platform devices might operate on firmware framebuffers, such as VESA or
EFI. Before a native driver for the graphics hardware can take over the
device, it has to remove any platform driver that operates on the firmware
framebuffer. Platform helpers provide the infrastructure for platform
drivers to acquire firmware framebuffers, and for native drivers to remove
them lateron.
It works similar to the related fbdev mechanism. During initialization, the
platform driver acquires the firmware framebuffer's I/O memory and provides
a callback to be removed. The native driver later uses this inforamtion to
remove any platform driver for it's framebuffer I/O memory.
The platform helper's removal code is integrated into the existing code for
removing conflicting fraembuffers, so native drivers use it automatically.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/Kconfig| 6 ++
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/drm_platform.c | 118 +
include/drm/drm_fb_helper.h| 18 -
include/drm/drm_platform.h | 42
5 files changed, 184 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/drm_platform.c
create mode 100644 include/drm/drm_platform.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index c4fd57d8b717..e9d6892f9d38 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -229,6 +229,12 @@ config DRM_SCHED
tristate
depends on DRM
+config DRM_PLATFORM_HELPER
+ bool
+ depends on DRM
+ help
+ Helpers for DRM platform devices
+
source "drivers/gpu/drm/i2c/Kconfig"
source "drivers/gpu/drm/arm/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 2c0e5a7e5953..8ceb21d0770a 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -32,6 +32,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o
drm-$(CONFIG_PCI) += drm_pci.o
drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
+drm-$(CONFIG_DRM_PLATFORM_HELPER) += drm_platform.o
drm_vram_helper-y := drm_gem_vram_helper.o
obj-$(CONFIG_DRM_VRAM_HELPER) += drm_vram_helper.o
diff --git a/drivers/gpu/drm/drm_platform.c b/drivers/gpu/drm/drm_platform.c
new file mode 100644
index ..09a2f2a31aa5
--- /dev/null
+++ b/drivers/gpu/drm/drm_platform.c
@@ -0,0 +1,118 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+
+#include
+#include
+
+#include
+#include
+#include
+
+static LIST_HEAD(drm_apertures);
+
+static DEFINE_MUTEX(drm_apertures_lock);
+
+static bool overlap(resource_size_t base1, resource_size_t end1,
+ resource_size_t base2, resource_size_t end2)
+{
+ return (base1 < end2) && (end1 > base2);
+}
+
+static struct drm_aperture *
+drm_aperture_acquire(struct drm_device *dev,
+resource_size_t base, resource_size_t size,
+const struct drm_aperture_funcs *funcs)
+{
+ size_t end = base + size;
+ struct list_head *pos;
+ struct drm_aperture *ap;
+
+ mutex_lock(&drm_apertures_lock);
+
+ list_for_each(pos, &drm_apertures) {
+ ap = container_of(pos, struct drm_aperture, lh);
+ if (overlap(base, end, ap->base, ap->base + ap->size))
+ return ERR_PTR(-EBUSY);
+ }
+
+ ap = drmm_kzalloc(dev, sizeof(*ap), GFP_KERNEL);
+ if (!ap)
+ return ERR_PTR(-ENOMEM);
+
+ ap->dev = dev;
+ ap->base = base;
+ ap->size = size;
+ ap->funcs = funcs;
+ INIT_LIST_HEAD(&ap->lh);
+
+ list_add(&ap->lh, &drm_apertures);
+
+ mutex_unlock(&drm_apertures_lock);
+
+ return ap;
+}
+
+static void drm_aperture_release(struct drm_aperture *ap)
+{
+ bool kicked_out = ap->kicked_out;
+
+ if (!kicked_out)
+ mutex_lock(&drm_apertures_lock);
+
+ list_del(&ap->lh);
+ if (ap->funcs->release)
+ ap->funcs->release(ap);
+
+ if (!kicked_out)
+ mutex_unlock(&drm_apertures_lock);
+}
+
+static void drm_aperture_acquire_release(struct drm_device *dev, void *ptr)
+{
+ struct drm_aperture *ap = ptr;
+
+ drm_aperture_release(ap);
+}
+
+struct drm_aperture *
+drmm_aperture_acquire(struct drm_device *dev,
+ resource_size_t base, resource_size_t size,
+ const struct drm_aperture_funcs *funcs)
+{
+ struct drm_aperture *ap;
+ int ret;
+
+ ap = drm_aperture_acquire(dev, base, size, funcs);
+ if (IS_ERR(ap))
+ return ap;
+ ret = drmm_add_action_or_reset(dev, drm_aperture_acquire_release, ap);
+ if (ret)
+ return ERR_PTR(ret);
+
+ return ap;
+}
+EXPORT_SYMBOL(drmm_aperture_acquire);
+
+void drm_kickout_apertures_at(resource_size_t base, resource_size_t size)
+{
+ resource_size_t end = base + size;
+ struct list_head *pos, *n;
+
+
[PATCH 5/9] drm/simplekms: Initialize framebuffer data from device-tree node
A firmware framebuffer might also be specified via device-tree files. If
no device platform data is given, try the DT device node.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/simplekms.c | 84
1 file changed, 84 insertions(+)
diff --git a/drivers/gpu/drm/tiny/simplekms.c b/drivers/gpu/drm/tiny/simplekms.c
index ac2ebfcedd22..87636307aa4f 100644
--- a/drivers/gpu/drm/tiny/simplekms.c
+++ b/drivers/gpu/drm/tiny/simplekms.c
@@ -113,6 +113,76 @@ simplefb_get_format_pd(struct drm_device *dev,
return simplefb_get_validated_format(dev, pd->format);
}
+static int
+simplefb_read_u32_of(struct drm_device *dev, struct device_node *of_node,
+const char* name, u32 *value)
+{
+ int ret = of_property_read_u32(of_node, name, value);
+ if (ret)
+ drm_err(dev, "simplefb: can't parse framebuffer %s: error %d\n",
+ name, ret);
+ return ret;
+}
+
+static int
+simplefb_read_string_of(struct drm_device *dev, struct device_node *of_node,
+ const char* name, const char **value)
+{
+ int ret = of_property_read_string(of_node, name, value);
+ if (ret)
+ drm_err(dev, "simplefb: can't parse framebuffer %s: error %d\n",
+ name, ret);
+ return ret;
+}
+
+static int
+simplefb_get_width_of(struct drm_device *dev, struct device_node *of_node)
+{
+ int ret;
+ u32 width;
+
+ ret = simplefb_read_u32_of(dev, of_node, "width", &width);
+ if (ret)
+ return ret;
+ return simplefb_get_validated_int0(dev, "width", width);
+}
+
+static int
+simplefb_get_height_of(struct drm_device *dev, struct device_node *of_node)
+{
+ int ret;
+ u32 height;
+
+ ret = simplefb_read_u32_of(dev, of_node, "height", &height);
+ if (ret)
+ return ret;
+ return simplefb_get_validated_int0(dev, "height", height);
+}
+
+static int
+simplefb_get_stride_of(struct drm_device *dev, struct device_node *of_node)
+{
+ int ret;
+ u32 stride;
+
+ ret = simplefb_read_u32_of(dev, of_node, "stride", &stride);
+ if (ret)
+ return ret;
+ return simplefb_get_validated_int(dev, "stride", stride);
+}
+
+static const struct drm_format_info *
+simplefb_get_format_of(struct drm_device *dev, struct device_node *of_node)
+{
+ int ret;
+ const char *format;
+
+ ret = simplefb_read_string_of(dev, of_node, "format", &format);
+ if (ret)
+ return ERR_PTR(ret);
+ return simplefb_get_validated_format(dev, format);
+}
+
/*
* Simple Framebuffer device
*/
@@ -163,6 +233,7 @@ static int simplekms_device_init_fb(struct simplekms_device
*sdev)
struct drm_device *dev = &sdev->dev;
struct platform_device *pdev = sdev->pdev;
const struct simplefb_platform_data *pd = dev_get_platdata(&pdev->dev);
+ struct device_node *of_node = pdev->dev.of_node;
if (pd) {
width = simplefb_get_width_pd(dev, pd);
@@ -177,6 +248,19 @@ static int simplekms_device_init_fb(struct
simplekms_device *sdev)
format = simplefb_get_format_pd(dev, pd);
if (IS_ERR(format))
return PTR_ERR(format);
+ } else if (of_node) {
+ width = simplefb_get_width_of(dev, of_node);
+ if (width < 0)
+ return width;
+ height = simplefb_get_height_of(dev, of_node);
+ if (height < 0)
+ return height;
+ stride = simplefb_get_stride_of(dev, of_node);
+ if (stride < 0)
+ return stride;
+ format = simplefb_get_format_of(dev, of_node);
+ if (IS_ERR(format))
+ return PTR_ERR(format);
} else {
drm_err(dev, "no simplefb configuration found\n");
return -ENODEV;
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/9] drm/format-helper: Add blitter functions
The blitter functions copy a framebuffer to I/O memory using one of
the existing conversion functions.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_format_helper.c | 87 +
include/drm/drm_format_helper.h | 8 +++
2 files changed, 95 insertions(+)
diff --git a/drivers/gpu/drm/drm_format_helper.c
b/drivers/gpu/drm/drm_format_helper.c
index 8d5a683afea7..0e885cd34107 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -344,3 +344,90 @@ void drm_fb_xrgb_to_gray8(u8 *dst, void *vaddr, struct
drm_framebuffer *fb,
}
EXPORT_SYMBOL(drm_fb_xrgb_to_gray8);
+/**
+ * drm_fb_blit_rect_dstclip - Copy parts of a framebuffer to display memory
+ * @dst: The display memory to copy to
+ * @dst_pitch: Number of bytes between two consecutive scanlines within dst
+ * @dst_format:FOURCC code of the display's color format
+ * @vmap: The framebuffer memory to copy from
+ * @fb:The framebuffer to copy from
+ * @clip: Clip rectangle area to copy
+ *
+ * This function copies parts of a framebuffer to display memory. If the
+ * formats of the display and the framebuffer mismatch, the blit function
+ * will attempt to convert between them.
+ *
+ * Use drm_fb_blit_dstclip() to copy the full framebuffer.
+ *
+ * Returns:
+ * 0 on success, or
+ * -EINVAL if the color-format conversion failed, or
+ * a negative error code otherwise.
+ */
+int drm_fb_blit_rect_dstclip(void __iomem *dst, unsigned int dst_pitch,
+uint32_t dst_format, void *vmap,
+struct drm_framebuffer *fb,
+struct drm_rect *clip)
+{
+ uint32_t fb_format = fb->format->format;
+
+ /* treat alpha channel like filler bits */
+ if (fb_format == DRM_FORMAT_ARGB)
+ fb_format = DRM_FORMAT_XRGB;
+ if (dst_format == DRM_FORMAT_ARGB)
+ dst_format = DRM_FORMAT_XRGB;
+
+ if (dst_format == fb_format) {
+ drm_fb_memcpy_dstclip(dst, dst_pitch, vmap, fb, clip);
+ return 0;
+
+ } else if (dst_format == DRM_FORMAT_RGB565) {
+ if (fb_format == DRM_FORMAT_XRGB) {
+ drm_fb_xrgb_to_rgb565_dstclip(dst, dst_pitch,
+ vmap, fb, clip,
+ false);
+ return 0;
+ }
+ } else if (dst_format == DRM_FORMAT_RGB888) {
+ if (fb_format == DRM_FORMAT_XRGB) {
+ drm_fb_xrgb_to_rgb888_dstclip(dst, dst_pitch,
+ vmap, fb, clip);
+ return 0;
+ }
+ }
+
+ return -EINVAL;
+}
+EXPORT_SYMBOL(drm_fb_blit_rect_dstclip);
+
+/**
+ * drm_fb_blit_dstclip - Copy framebuffer to display memory
+ * @dst: The display memory to copy to
+ * @dst_pitch: Number of bytes between two consecutive scanlines within dst
+ * @dst_format:FOURCC code of the display's color format
+ * @vmap: The framebuffer memory to copy from
+ * @fb:The framebuffer to copy from
+ *
+ * This function copies a full framebuffer to display memory. If the formats
+ * of the display and the framebuffer mismatch, the copy function will
+ * attempt to convert between them.
+ *
+ * See drm_fb_blit_rect_dstclip() for more inforamtion.
+ *
+ * Returns:
+ * 0 on success, or a negative error code otherwise.
+ */
+int drm_fb_blit_dstclip(void __iomem *dst, unsigned int dst_pitch,
+ uint32_t dst_format, void *vmap,
+ struct drm_framebuffer *fb)
+{
+ struct drm_rect fullscreen = {
+ .x1 = 0,
+ .x2 = fb->width,
+ .y1 = 0,
+ .y2 = fb->height,
+ };
+ return drm_fb_blit_rect_dstclip(dst, dst_pitch, dst_format, vmap, fb,
+ &fullscreen);
+}
+EXPORT_SYMBOL(drm_fb_blit_dstclip);
diff --git a/include/drm/drm_format_helper.h b/include/drm/drm_format_helper.h
index 2b5036a5fbe7..4e0258a61311 100644
--- a/include/drm/drm_format_helper.h
+++ b/include/drm/drm_format_helper.h
@@ -28,4 +28,12 @@ void drm_fb_xrgb_to_rgb888_dstclip(void __iomem *dst,
unsigned int dst_pitch
void drm_fb_xrgb_to_gray8(u8 *dst, void *vaddr, struct drm_framebuffer *fb,
struct drm_rect *clip);
+int drm_fb_blit_rect_dstclip(void __iomem *dst, unsigned int dst_pitch,
+uint32_t dst_format, void *vmap,
+struct drm_framebuffer *fb,
+struct drm_rect *rect);
+int drm_fb_blit_dstclip(void __iomem *dst, unsigned int dst_pitch,
+ uint32_t dst_format, void *vmap,
+ struct drm_framebuffer *fb);
+
#endif /* __
[PATCH 7/9] drm/simplekms: Acquire regulators from DT device node
Make sure required hardware regulators are enabled while the firmware
framebuffer is in use.
The basic code has been taken from the simplefb driver and adapted
to DRM. Regulators are released automatically via devres helpers.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/simplekms.c | 128 +++
1 file changed, 128 insertions(+)
diff --git a/drivers/gpu/drm/tiny/simplekms.c b/drivers/gpu/drm/tiny/simplekms.c
index aca186decb48..ae5d3cbadbe8 100644
--- a/drivers/gpu/drm/tiny/simplekms.c
+++ b/drivers/gpu/drm/tiny/simplekms.c
@@ -4,6 +4,7 @@
#include
#include
#include
+#include
#include
#include
@@ -198,6 +199,11 @@ struct simplekms_device {
unsigned int clk_count;
struct clk **clks;
#endif
+ /* regulators */
+#if defined CONFIG_OF && defined CONFIG_REGULATOR
+ unsigned int regulator_count;
+ struct regulator **regulators;
+#endif
/* simplefb settings */
struct drm_display_mode mode;
@@ -315,6 +321,125 @@ static int simplekms_device_init_clocks(struct
simplekms_device *sdev)
}
#endif
+#if defined CONFIG_OF && defined CONFIG_REGULATOR
+
+#define SUPPLY_SUFFIX "-supply"
+
+/*
+ * Regulator handling code.
+ *
+ * Here we handle the num-supplies and vin*-supply properties of our
+ * "simple-framebuffer" dt node. This is necessary so that we can make sure
+ * that any regulators needed by the display hardware that the bootloader
+ * set up for us (and for which it provided a simplefb dt node), stay up,
+ * for the life of the simplefb driver.
+ *
+ * When the driver unloads, we cleanly disable, and then release the
+ * regulators.
+ *
+ * We only complain about errors here, no action is taken as the most likely
+ * error can only happen due to a mismatch between the bootloader which set
+ * up simplefb, and the regulator definitions in the device tree. Chances are
+ * that there are no adverse effects, and if there are, a clean teardown of
+ * the fb probe will not help us much either. So just complain and carry on,
+ * and hope that the user actually gets a working fb at the end of things.
+ */
+
+static void simplekms_device_release_regulators(void *res)
+{
+ struct simplekms_device *sdev = simplekms_device_of_dev(res);
+ unsigned int i;
+
+ for (i = 0; i < sdev->regulator_count; ++i) {
+ if (sdev->regulators[i]) {
+ regulator_disable(sdev->regulators[i]);
+ regulator_put(sdev->regulators[i]);
+ }
+ }
+}
+
+static int simplekms_device_init_regulators(struct simplekms_device *sdev)
+{
+ struct drm_device *dev = &sdev->dev;
+ struct platform_device *pdev = sdev->pdev;
+ struct device_node *of_node = pdev->dev.of_node;
+ struct property *prop;
+ struct regulator *regulator;
+ const char *p;
+ unsigned int count = 0, i = 0;
+ int ret;
+
+ if (dev_get_platdata(&pdev->dev) || !of_node)
+ return 0;
+
+ /* Count the number of regulator supplies */
+ for_each_property_of_node(of_node, prop) {
+ p = strstr(prop->name, SUPPLY_SUFFIX);
+ if (p && p != prop->name)
+ ++count;
+ }
+
+ if (!count)
+ return 0;
+
+ sdev->regulators = drmm_kzalloc(dev,
+ count * sizeof(sdev->regulators[0]),
+ GFP_KERNEL);
+ if (!sdev->regulators)
+ return -ENOMEM;
+
+ for_each_property_of_node(of_node, prop) {
+ char name[32]; /* 32 is max size of property name */
+ size_t len;
+
+ p = strstr(prop->name, SUPPLY_SUFFIX);
+ if (!p || p == prop->name)
+ continue;
+ len = strlen(prop->name) - strlen(SUPPLY_SUFFIX) + 1;
+ strlcpy(name, prop->name, len);
+
+ regulator = regulator_get_optional(&pdev->dev, name);
+ if (IS_ERR(regulator)) {
+ ret = PTR_ERR(regulator);
+ if (ret == -EPROBE_DEFER)
+ goto err;
+ drm_err(dev, "regulator %s not found: %d\n",
+ name, ret);
+ continue;
+ }
+
+ ret = regulator_enable(regulator);
+ if (ret) {
+ drm_err(dev, "failed to enable regulator %u: %d\n",
+ i, ret);
+ regulator_put(regulator);
+ }
+
+ sdev->regulators[i++] = regulator;
+ }
+ sdev->regulator_count = i;
+
+ return devm_add_action_or_reset(&pdev->dev,
+ simplekms_device_release_regulators,
+ sdev);
+
+err:
+ while (i) {
+ --i;
+ if (sdev->regulators[i]
[PATCH 6/9] drm/simplekms: Acquire clocks from DT device node
Make sure required hardware clocks are enabled while the firmware
framebuffer is in use.
The basic code has been taken from the simplefb driver and adapted
to DRM. Clocks are released automatically via devres helpers.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/simplekms.c | 108 +++
1 file changed, 108 insertions(+)
diff --git a/drivers/gpu/drm/tiny/simplekms.c b/drivers/gpu/drm/tiny/simplekms.c
index 87636307aa4f..aca186decb48 100644
--- a/drivers/gpu/drm/tiny/simplekms.c
+++ b/drivers/gpu/drm/tiny/simplekms.c
@@ -1,5 +1,7 @@
// SPDX-License-Identifier: GPL-2.0-only
+#include
+#include
#include
#include
@@ -191,6 +193,12 @@ struct simplekms_device {
struct drm_device dev;
struct platform_device *pdev;
+ /* clocks */
+#if defined CONFIG_OF && defined CONFIG_COMMON_CLK
+ unsigned int clk_count;
+ struct clk **clks;
+#endif
+
/* simplefb settings */
struct drm_display_mode mode;
const struct drm_format_info *format;
@@ -210,6 +218,103 @@ static struct simplekms_device
*simplekms_device_of_dev(struct drm_device *dev)
return container_of(dev, struct simplekms_device, dev);
}
+/*
+ * Hardware
+ */
+
+#if defined CONFIG_OF && defined CONFIG_COMMON_CLK
+/*
+ * Clock handling code.
+ *
+ * Here we handle the clocks property of our "simple-framebuffer" dt node.
+ * This is necessary so that we can make sure that any clocks needed by
+ * the display engine that the bootloader set up for us (and for which it
+ * provided a simplefb dt node), stay up, for the life of the simplefb
+ * driver.
+ *
+ * When the driver unloads, we cleanly disable, and then release the clocks.
+ *
+ * We only complain about errors here, no action is taken as the most likely
+ * error can only happen due to a mismatch between the bootloader which set
+ * up simplefb, and the clock definitions in the device tree. Chances are
+ * that there are no adverse effects, and if there are, a clean teardown of
+ * the fb probe will not help us much either. So just complain and carry on,
+ * and hope that the user actually gets a working fb at the end of things.
+ */
+
+static void simplekms_device_release_clocks(void *res)
+{
+ struct simplekms_device *sdev = simplekms_device_of_dev(res);
+ unsigned int i;
+
+ for (i = 0; i < sdev->clk_count; ++i) {
+ if (sdev->clks[i]) {
+ clk_disable_unprepare(sdev->clks[i]);
+ clk_put(sdev->clks[i]);
+ }
+ }
+}
+
+static int simplekms_device_init_clocks(struct simplekms_device *sdev)
+{
+ struct drm_device *dev = &sdev->dev;
+ struct platform_device *pdev = sdev->pdev;
+ struct device_node *of_node = pdev->dev.of_node;
+ struct clk *clock;
+ unsigned int i;
+ int ret;
+
+ if (dev_get_platdata(&pdev->dev) || !of_node)
+ return 0;
+
+ sdev->clk_count = of_clk_get_parent_count(of_node);
+ if (!sdev->clk_count)
+ return 0;
+
+ sdev->clks = drmm_kzalloc(dev, sdev->clk_count * sizeof(sdev->clks[0]),
+ GFP_KERNEL);
+ if (!sdev->clks)
+ return -ENOMEM;
+
+ for (i = 0; i < sdev->clk_count; ++i) {
+ clock = of_clk_get(of_node, i);
+ if (IS_ERR(clock)) {
+ ret = PTR_ERR(clock);
+ if (ret == -EPROBE_DEFER)
+ goto err;
+ drm_err(dev, "clock %u not found: %d\n", i, ret);
+ continue;
+ }
+ ret = clk_prepare_enable(clock);
+ if (ret) {
+ drm_err(dev, "failed to enable clock %u: %d\n",
+ i, ret);
+ clk_put(clock);
+ }
+ sdev->clks[i] = clock;
+ }
+
+ return devm_add_action_or_reset(&pdev->dev,
+ simplekms_device_release_clocks,
+ sdev);
+
+err:
+ while (i) {
+ --i;
+ if (sdev->clks[i]) {
+ clk_disable_unprepare(sdev->clks[i]);
+ clk_put(sdev->clks[i]);
+ }
+ }
+ return ret;
+}
+#else
+static int simplekms_device_init_clocks(struct simplekms_device *sdev)
+{
+ return 0;
+}
+#endif
+
/*
* Simplefb settings
*/
@@ -505,6 +610,9 @@ simplekms_device_create(struct drm_driver *drv, struct
platform_device *pdev)
return ERR_CAST(sdev);
sdev->pdev = pdev;
+ ret = simplekms_device_init_clocks(sdev);
+ if (ret)
+ return ERR_PTR(ret);
ret = simplekms_device_init_fb(sdev);
if (ret)
return ERR_PTR(ret);
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.o
[RFC][PATCH 0/9] drm: Support simple-framebuffer devices and firmware fbs
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 simplekms, binds to a simple-frambuffer platform device. The kernel's boot code creates such devices for firmware-provided framebuffers, such as EFI-GOP or VESA. Typically the BIOS, UEFI or boot loader sets up the framebuffers. Description via device tree is also an option. Simplekms is small enough to be linked into the kernel. The driver's main purpose is to provide graphical output during the early phases of the boot process, before the native DRM drivers are available. Native drivers are typically loaded from an initrd ram disk. Occationally simplekms can also serve as interim solution on graphics hardware without native DRM driver. So far distributions rely on fbdev drivers, such as efifb, vesafb or simplefb, for early-boot graphical output. However fbdev is deprecated and the drivers do not provide DRM interfaces for modern userspace. Patches 1 and 2 prepare the DRM format helpers for simplekms. Patches 3 to 7 add the simplekms driver. It's build on simple DRM helpers and SHMEM. It supports 16-bit, 24-bit and 32-bit RGB framebuffers. During pageflips, SHMEM buffers are copied into the framebuffer memory, similar to cirrus or mgag200. The code in patches 6 and 7 handles clocks and regulators. It's based on the simplefb drivers, but has been modified for DRM. Patches 8 and 9 add a hand-over mechanism. Simplekms acquires it's framebuffer's I/O-memory range and provides a callback function to be removed by a native driver. The native driver will remove simplekms before taking over the hardware. The removal is integrated into existing helpers, so drivers use it automatically. I tested simplekms with x86 EFI and VESA framebuffers, which both work reliably. The fbdev console and Weston work automatically. Xorg requires manual configuration of the device. Xorgs current modesetting driver does not work with both, platform and PCI device, for the same physical hardware. Once configured, X11 works. One cosmetical issue is that simplekms's device file is card0 and the native driver's device file is card1. After simplekms has been kicked out, only card1 is left. This does not seem to be a practical problem however. TODO/IDEAS: * provide deferred takeover * provide bootsplash DRM client * make simplekms usable with ARM-EFI fbs Thomas Zimmermann (9): drm/format-helper: Pass destination pitch to drm_fb_memcpy_dstclip() drm/format-helper: Add blitter functions drm: Add simplekms driver drm/simplekms: Add fbdev emulation drm/simplekms: Initialize framebuffer data from device-tree node drm/simplekms: Acquire clocks from DT device node drm/simplekms: Acquire regulators from DT device node drm: Add infrastructure for platform devices drm/simplekms: Acquire memory aperture for framebuffer MAINTAINERS| 6 + drivers/gpu/drm/Kconfig| 6 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/drm_format_helper.c| 96 ++- drivers/gpu/drm/drm_platform.c | 118 drivers/gpu/drm/mgag200/mgag200_mode.c | 2 +- drivers/gpu/drm/tiny/Kconfig | 17 + drivers/gpu/drm/tiny/Makefile | 1 + drivers/gpu/drm/tiny/cirrus.c | 2 +- drivers/gpu/drm/tiny/simplekms.c | 906 + include/drm/drm_fb_helper.h| 18 +- include/drm/drm_format_helper.h| 10 +- include/drm/drm_platform.h | 42 ++ 13 files changed, 1217 insertions(+), 8 deletions(-) create mode 100644 drivers/gpu/drm/drm_platform.c create mode 100644 drivers/gpu/drm/tiny/simplekms.c create mode 100644 include/drm/drm_platform.h -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/9] drm/format-helper: Pass destination pitch to drm_fb_memcpy_dstclip()
The memcpy's destination buffer might have a different pitch than the
source. Support different pitches as function argument.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_format_helper.c| 9 +
drivers/gpu/drm/mgag200/mgag200_mode.c | 2 +-
drivers/gpu/drm/tiny/cirrus.c | 2 +-
include/drm/drm_format_helper.h| 2 +-
4 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_format_helper.c
b/drivers/gpu/drm/drm_format_helper.c
index c043ca364c86..8d5a683afea7 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -52,6 +52,7 @@ EXPORT_SYMBOL(drm_fb_memcpy);
/**
* drm_fb_memcpy_dstclip - Copy clip buffer
* @dst: Destination buffer (iomem)
+ * @dst_pitch: Number of bytes between two consecutive scanlines within dst
* @vaddr: Source buffer
* @fb: DRM framebuffer
* @clip: Clip rectangle area to copy
@@ -59,12 +60,12 @@ EXPORT_SYMBOL(drm_fb_memcpy);
* This function applies clipping on dst, i.e. the destination is a
* full (iomem) framebuffer but only the clip rect content is copied over.
*/
-void drm_fb_memcpy_dstclip(void __iomem *dst, void *vaddr,
- struct drm_framebuffer *fb,
+void drm_fb_memcpy_dstclip(void __iomem *dst, unsigned int dst_pitch,
+ void *vaddr, struct drm_framebuffer *fb,
struct drm_rect *clip)
{
unsigned int cpp = fb->format->cpp[0];
- unsigned int offset = clip_offset(clip, fb->pitches[0], cpp);
+ unsigned int offset = clip_offset(clip, dst_pitch, cpp);
size_t len = (clip->x2 - clip->x1) * cpp;
unsigned int y, lines = clip->y2 - clip->y1;
@@ -73,7 +74,7 @@ void drm_fb_memcpy_dstclip(void __iomem *dst, void *vaddr,
for (y = 0; y < lines; y++) {
memcpy_toio(dst, vaddr, len);
vaddr += fb->pitches[0];
- dst += fb->pitches[0];
+ dst += dst_pitch;
}
}
EXPORT_SYMBOL(drm_fb_memcpy_dstclip);
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index f16bd278ab7e..7d4f3a62d885 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -1586,7 +1586,7 @@ mgag200_handle_damage(struct mga_device *mdev, struct
drm_framebuffer *fb,
if (drm_WARN_ON(dev, !vmap))
return; /* BUG: SHMEM BO should always be vmapped */
- drm_fb_memcpy_dstclip(mdev->vram, vmap, fb, clip);
+ drm_fb_memcpy_dstclip(mdev->vram, fb->pitches[0], vmap, fb, clip);
drm_gem_shmem_vunmap(fb->obj[0], vmap);
diff --git a/drivers/gpu/drm/tiny/cirrus.c b/drivers/gpu/drm/tiny/cirrus.c
index 744a8e337e41..2dd9e5e31e3d 100644
--- a/drivers/gpu/drm/tiny/cirrus.c
+++ b/drivers/gpu/drm/tiny/cirrus.c
@@ -327,7 +327,7 @@ static int cirrus_fb_blit_rect(struct drm_framebuffer *fb,
goto out_dev_exit;
if (cirrus->cpp == fb->format->cpp[0])
- drm_fb_memcpy_dstclip(cirrus->vram,
+ drm_fb_memcpy_dstclip(cirrus->vram, fb->pitches[0],
vmap, fb, rect);
else if (fb->format->cpp[0] == 4 && cirrus->cpp == 2)
diff --git a/include/drm/drm_format_helper.h b/include/drm/drm_format_helper.h
index 5f9e37032468..2b5036a5fbe7 100644
--- a/include/drm/drm_format_helper.h
+++ b/include/drm/drm_format_helper.h
@@ -11,7 +11,7 @@ struct drm_rect;
void drm_fb_memcpy(void *dst, void *vaddr, struct drm_framebuffer *fb,
struct drm_rect *clip);
-void drm_fb_memcpy_dstclip(void __iomem *dst, void *vaddr,
+void drm_fb_memcpy_dstclip(void __iomem *dst, unsigned int dst_pitch, void
*vaddr,
struct drm_framebuffer *fb,
struct drm_rect *clip);
void drm_fb_swab(void *dst, void *src, struct drm_framebuffer *fb,
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/atomic_helper: duplicate state for drm_private_obj
From: Shawn Guo
The msm/mdp5 driver uses drm_private_obj as its global atomic state,
which keeps the assignment of hwpipe to plane. With drm_private_obj
missing from duplicate state call, mdp5 suspend works with no problem
only for the very first time. Any subsequent suspend will hit the
following warning, because hwpipe assignment doesn't get duplicated for
suspend state. Adding drm_private_obj handling for duplicate state call
fixes the problem.
$ echo mem > /sys/power/state
[ 38.44] PM: suspend entry (deep)
[ 38.85] PM: Syncing filesystems ... done.
[ 38.114630] Freezing user space processes ... (elapsed 0.001 seconds) done.
[ 38.115912] OOM killer disabled.
[ 38.115914] Freezing remaining freezable tasks ... (elapsed 0.001 seconds)
done.
[ 38.122170] [ cut here ]
[ 38.122212] WARNING: CPU: 0 PID: 1747 at
drivers/gpu/drm/msm/disp/mdp5/mdp5_pipe.c:145 mdp5_pipe_release+0x90/0xc0
[ 38.122215] Modules linked in:
[ 38.12] CPU: 0 PID: 1747 Comm: sh Not tainted
4.19.107-00515-g9d5e4d7a33ed-dirty #323
[ 38.14] Hardware name: Square, Inc. T2 Devkit (DT)
[ 38.18] pstate: 4005 (nZcv daif -PAN -UAO)
[ 38.122230] pc : mdp5_pipe_release+0x90/0xc0
[ 38.122233] lr : mdp5_pipe_release+0x90/0xc0
[ 38.122235] sp : 0d13b7f0
[ 38.122236] x29: 0d13b7f0 x28:
[ 38.122240] x27: 0002 x26: 800079adce00
[ 38.122243] x25: 800079405200 x24:
[ 38.122246] x23: 80007a78cc08 x22: 80007b1cc018
[ 38.122249] x21: 80007b1cc000 x20: 80007b317080
[ 38.122252] x19: 80007a78ce80 x18: 0002
[ 38.122255] x17: x16:
[ 38.122258] x15: fff0 x14: 08c3fb48
[ 38.122261] x13: 08cdac4a x12: 08c3f000
[ 38.122264] x11: x10: 08cda000
[ 38.122267] x9 : x8 : 08ce4a40
[ 38.122269] x7 : x6 : 39ea41a9
[ 38.122272] x5 : x4 :
[ 38.122275] x3 : x2 : c7580c109cae4500
[ 38.122278] x1 : x0 : 0024
[ 38.122281] Call trace:
[ 38.122285] mdp5_pipe_release+0x90/0xc0
[ 38.122288] mdp5_plane_atomic_check+0x2c0/0x448
[ 38.122294] drm_atomic_helper_check_planes+0xd0/0x208
[ 38.122298] drm_atomic_helper_check+0x38/0xa8
[ 38.122302] drm_atomic_check_only+0x3e8/0x630
[ 38.122305] drm_atomic_commit+0x18/0x58
[ 38.122309] __drm_atomic_helper_disable_all.isra.12+0x15c/0x1a8
[ 38.122312] drm_atomic_helper_suspend+0x80/0xf0
[ 38.122316] msm_pm_suspend+0x4c/0x70
[ 38.122320] dpm_run_callback.isra.6+0x20/0x68
[ 38.122323] __device_suspend+0x110/0x308
[ 38.122326] dpm_suspend+0x100/0x1f0
[ 38.122329] dpm_suspend_start+0x64/0x70
[ 38.122334] suspend_devices_and_enter+0x110/0x500
[ 38.122336] pm_suspend+0x268/0x2c0
[ 38.122339] state_store+0x88/0x110
[ 38.122345] kobj_attr_store+0x14/0x28
[ 38.122352] sysfs_kf_write+0x3c/0x50
[ 38.122355] kernfs_fop_write+0x118/0x1e0
[ 38.122360] __vfs_write+0x30/0x168
[ 38.122363] vfs_write+0xa4/0x1a8
[ 38.122366] ksys_write+0x64/0xe8
[ 38.122368] __arm64_sys_write+0x18/0x20
[ 38.122374] el0_svc_common+0x6c/0x178
[ 38.122377] el0_svc_compat_handler+0x1c/0x28
[ 38.122381] el0_svc_compat+0x8/0x18
[ 38.122383] ---[ end trace 24145b7d8545345b ]---
[ 38.491552] Disabling non-boot CPUs ...
Signed-off-by: Shawn Guo
---
drivers/gpu/drm/drm_atomic_helper.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 85d163f16801..024985a92156 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3140,6 +3140,7 @@ drm_atomic_helper_duplicate_state(struct drm_device *dev,
struct drm_atomic_state *state;
struct drm_connector *conn;
struct drm_connector_list_iter conn_iter;
+ struct drm_private_obj *priv_obj;
struct drm_plane *plane;
struct drm_crtc *crtc;
int err = 0;
@@ -3184,6 +3185,16 @@ drm_atomic_helper_duplicate_state(struct drm_device *dev,
}
drm_connector_list_iter_end(&conn_iter);
+ drm_for_each_privobj(priv_obj, dev) {
+ struct drm_private_state *priv_state;
+
+ priv_state = drm_atomic_get_private_obj_state(state, priv_obj);
+ if (IS_ERR(priv_state)) {
+ err = PTR_ERR(priv_state);
+ goto free;
+ }
+ }
+
/* clear the acquire context so that it isn't accidentally reused */
state->acquire_ctx = NULL;
@@ -3278,6 +3289,8 @@ int drm_atomic_helper_commit_duplicated_state(struct
drm_atomic_state *state,
struct drm_connector_state *new_conn_state;
struct drm_crtc *crtc;
struct drm_crtc_state *new_
Re: [PATCH v6 3/3] drm/i915: Send hotplug event if edid had changed
On Thu, Jun 25, 2020 at 10:36:28AM +0200, Maarten Lankhorst wrote:
> Op 23-06-2020 om 20:57 schreef Kunal Joshi:
> > From: Stanislav Lisovskiy
> >
> > Added epoch counter checking to intel_encoder_hotplug
> > in order to be able process all the connector changes,
> > besides connection status. Also now any change in connector
> > would result in epoch counter change, so no multiple checks
> > are needed.
> >
> > v2: Renamed change counter to epoch counter. Fixed type name.
> >
> > v3: Fixed rebase conflict
> >
> > v4: Remove duplicate drm_edid_equal checks from hdmi and dp,
> > lets use only once edid property is getting updated and
> > increment epoch counter from there.
> > Also lets now call drm_connector_update_edid_property
> > right after we get edid always to make sure there is a
> > unified way to handle edid change, without having to
> > change tons of source code as currently
> > drm_connector_update_edid_property is called only in
> > certain cases like reprobing and not right after edid is
> > actually updated.
> >
> > v5: Fixed const modifiers, removed blank line
> >
> > v6: Removed drm specific part from this patch, leaving only
> > i915 specific changes here.
> >
> > Signed-off-by: Stanislav Lisovskiy
> > ---
>
> Much better!
>
> Reviewed-by: Maarten Lankhorst
>
> for whole series
I think it had been for year in that state already :)
At some point I was just distracted by some other things.
Stan
>
> > drivers/gpu/drm/i915/display/intel_hotplug.c | 26 +++-
> > 1 file changed, 15 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c
> > b/drivers/gpu/drm/i915/display/intel_hotplug.c
> > index 2e94c1413c02..393813494523 100644
> > --- a/drivers/gpu/drm/i915/display/intel_hotplug.c
> > +++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
> > @@ -283,6 +283,8 @@ intel_encoder_hotplug(struct intel_encoder *encoder,
> > {
> > struct drm_device *dev = connector->base.dev;
> > enum drm_connector_status old_status;
> > +u64 old_epoch_counter;
> > +bool ret = false;
> >
> > drm_WARN_ON(dev, !mutex_is_locked(&dev->mode_config.mutex));
> > old_status = connector->base.status;
> > @@ -290,17 +292,19 @@ intel_encoder_hotplug(struct intel_encoder *encoder,
> > connector->base.status =
> > drm_helper_probe_detect(&connector->base, NULL, false);
> >
> > - if (old_status == connector->base.status)
> > - return INTEL_HOTPLUG_UNCHANGED;
> > -
> > - drm_dbg_kms(&to_i915(dev)->drm,
> > - "[CONNECTOR:%d:%s] status updated from %s to %s\n",
> > - connector->base.base.id,
> > - connector->base.name,
> > - drm_get_connector_status_name(old_status),
> > - drm_get_connector_status_name(connector->base.status));
> > -
> > - return INTEL_HOTPLUG_CHANGED;
> > +if (old_epoch_counter != connector->base.epoch_counter)
> > +ret = true;
> > +
> > +if(ret) {
> > + DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %s to
> > %s(epoch counter %llu)\n",
> > + connector->base.base.id,
> > + connector->base.name,
> > + drm_get_connector_status_name(old_status),
> > +
> > drm_get_connector_status_name(connector->base.status),
> > + connector->base.epoch_counter);
> > + return INTEL_HOTPLUG_CHANGED;
> > +}
> > +return INTEL_HOTPLUG_UNCHANGED;
> > }
> >
> > static bool intel_encoder_has_hpd_pulse(struct intel_encoder *encoder)
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 27/27] drm: Add default modes for connectors in unknown state
On Thu, Jun 25, 2020 at 12:32 PM Pekka Paalanen wrote:
>
> On Thu, 25 Jun 2020 09:57:44 +0200
> Daniel Vetter wrote:
>
> > On Thu, Jun 25, 2020 at 9:56 AM Daniel Vetter wrote:
> > >
> > > On Wed, Jun 24, 2020 at 03:40:42PM -0400, Alex Deucher wrote:
> > > > On Wed, Jun 24, 2020 at 3:31 PM Daniel Vetter wrote:
> > > > >
> > > > > On Wed, Jun 24, 2020 at 5:24 PM Alex Deucher
> > > > > wrote:
> > > > > >
> > > > > > On Wed, Jun 24, 2020 at 3:23 AM Daniel Vetter
> > > > > > wrote:
> > > > > > >
> > > > > > > On Wed, Jun 24, 2020 at 04:12:09AM +0300, Laurent Pinchart wrote:
> > > > > > > > Hi Sam,
> > > > > > > >
> > > > > > > > On Sun, Jun 21, 2020 at 10:40:00AM +0200, Sam Ravnborg wrote:
> > > > > > > > > On Tue, May 26, 2020 at 04:15:05AM +0300, Laurent Pinchart
> > > > > > > > > wrote:
> > > > > > > > > > The DRM CRTC helpers add default modes to connectors in the
> > > > > > > > > > connected
> > > > > > > > > > state if no mode can be retrieved from the connector. This
> > > > > > > > > > behaviour is
> > > > > > > > > > useful for VGA or DVI outputs that have no connected DDC
> > > > > > > > > > bus. However,
> > > > > > > > > > in such cases, the status of the output usually can't be
> > > > > > > > > > retrieved and
> > > > > > > > > > is reported as connector_status_unknown.
> > > > > > > > > >
> > > > > > > > > > Extend the addition of default modes to connectors in an
> > > > > > > > > > unknown state
> > > > > > > > > > to support outputs that can retrieve neither the modes nor
> > > > > > > > > > the
> > > > > > > > > > connection status.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Laurent Pinchart
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > From your description sounds like an OK approach.
> > > > > > > > > But this is not something I feel too familiar with.
> > > > > > > > > Acked-by: Sam Ravnborg
> > > > > > > >
> > > > > > > > Thanks for the ack. I'd like to have Daniel's (CC'ed) feedback
> > > > > > > > on this
> > > > > > > > too.
> > > > > > >
> > > > > > > Makes sense, and at least pre-coffee me can't immediately think
> > > > > > > of a
> > > > > > > scenario where we're going to regret this. _unknown status is
> > > > > > > pretty much
> > > > > > > limited to old VGA and similar things where load detect somehow
> > > > > > > isn't well
> > > > > > > supported by the hw.
> > > > > > >
> > > > > > > Reviewed-by: Daniel Vetter
> > > > > > >
> > > > > > > >
> > > > > > > > > > ---
> > > > > > > > > > drivers/gpu/drm/drm_probe_helper.c | 3 ++-
> > > > > > > > > > include/drm/drm_modeset_helper_vtables.h | 8 +++-
> > > > > > > > > > 2 files changed, 9 insertions(+), 2 deletions(-)
> > > > > > > > > >
> > > > > > > > > > diff --git a/drivers/gpu/drm/drm_probe_helper.c
> > > > > > > > > > b/drivers/gpu/drm/drm_probe_helper.c
> > > > > > > > > > index f5d141e0400f..9055d9573c90 100644
> > > > > > > > > > --- a/drivers/gpu/drm/drm_probe_helper.c
> > > > > > > > > > +++ b/drivers/gpu/drm/drm_probe_helper.c
> > > > > > > > > > @@ -491,7 +491,8 @@ int
> > > > > > > > > > drm_helper_probe_single_connector_modes(struct
> > > > > > > > > > drm_connector *connector,
> > > > > > > > > > if (count == 0 && connector->status ==
> > > > > > > > > > connector_status_connected)
> > > > > > > > > > count = drm_add_override_edid_modes(connector);
> > > > > > > > > >
> > > > > > > > > > - if (count == 0 && connector->status ==
> > > > > > > > > > connector_status_connected)
> > > > > > > > > > + if (count == 0 && (connector->status ==
> > > > > > > > > > connector_status_connected ||
> > > > > > > > > > +connector->status ==
> > > > > > > > > > connector_status_unknown))
> > > > > > > > > > count = drm_add_modes_noedid(connector, 1024,
> > > > > > > > > > 768);
> > > > > > > > > > count += drm_helper_probe_add_cmdline_mode(connector);
> > > > > > > > > > if (count == 0)
> > > > > > > > > > diff --git a/include/drm/drm_modeset_helper_vtables.h
> > > > > > > > > > b/include/drm/drm_modeset_helper_vtables.h
> > > > > > > > > > index 421a30f08463..afe55e2e93d2 100644
> > > > > > > > > > --- a/include/drm/drm_modeset_helper_vtables.h
> > > > > > > > > > +++ b/include/drm/drm_modeset_helper_vtables.h
> > > > > > > > > > @@ -876,13 +876,19 @@ struct drm_connector_helper_funcs {
> > > > > > > > > >* The usual way to implement this is to cache the EDID
> > > > > > > > > > retrieved in the
> > > > > > > > > >* probe callback somewhere in the driver-private
> > > > > > > > > > connector structure.
> > > > > > > > > >* In this function drivers then parse the modes in the
> > > > > > > > > > EDID and add
> > > > > > > > > > - * them by calling drm_add_edid_modes(). But connectors
> > > > > > > > > > that driver a
> > > > > > > > > > + * them by calling drm_add_edid_modes(). But connectors
> > > > > > > > > > that drive a
> > > > > > > > > >* fixed panel can also manually add specific modes u
Re: [PATCH 3/8] backlight: ili922x: Add missing kerneldoc descriptions for CHECK_FREQ_REG() args
On Thu, 25 Jun 2020, Daniel Thompson wrote: > On Wed, Jun 24, 2020 at 03:57:16PM +0100, Lee Jones wrote: > > Kerneldoc syntax is used, but not complete. Descriptions required. > > > > Prevents warnings like: > > > > drivers/video/backlight/ili922x.c:116: warning: Function parameter or > > member 's' not described in 'CHECK_FREQ_REG' > > drivers/video/backlight/ili922x.c:116: warning: Function parameter or > > member 'x' not described in 'CHECK_FREQ_REG' > > > > Cc: > > Cc: Bartlomiej Zolnierkiewicz > > Cc: Software Engineering > > Signed-off-by: Lee Jones > > --- > > drivers/video/backlight/ili922x.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/video/backlight/ili922x.c > > b/drivers/video/backlight/ili922x.c > > index 9c5aa3fbb2842..8cb4b9d3c3bba 100644 > > --- a/drivers/video/backlight/ili922x.c > > +++ b/drivers/video/backlight/ili922x.c > > @@ -107,6 +107,8 @@ > > * lower frequency when the registers are read/written. > > * The macro sets the frequency in the spi_transfer structure if > > * the frequency exceeds the maximum value. > > + * @s: pointer to controller side proxy for an SPI slave device > > What's wrong with "a pointer to an SPI device"? > > I am aware, having looked it up to find out what the above actually > means, that this is how struct spi_device is described in its own kernel > doc but quoting at that level of detail of both overkill and confusing. I figured that using the official description would be better than making something up. However if you think it's better to KISS, then I can change it. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 27/27] drm: Add default modes for connectors in unknown state
On Thu, 25 Jun 2020 09:57:44 +0200
Daniel Vetter wrote:
> On Thu, Jun 25, 2020 at 9:56 AM Daniel Vetter wrote:
> >
> > On Wed, Jun 24, 2020 at 03:40:42PM -0400, Alex Deucher wrote:
> > > On Wed, Jun 24, 2020 at 3:31 PM Daniel Vetter wrote:
> > > >
> > > > On Wed, Jun 24, 2020 at 5:24 PM Alex Deucher
> > > > wrote:
> > > > >
> > > > > On Wed, Jun 24, 2020 at 3:23 AM Daniel Vetter
> > > > > wrote:
> > > > > >
> > > > > > On Wed, Jun 24, 2020 at 04:12:09AM +0300, Laurent Pinchart wrote:
> > > > > > > Hi Sam,
> > > > > > >
> > > > > > > On Sun, Jun 21, 2020 at 10:40:00AM +0200, Sam Ravnborg wrote:
> > > > > > > > On Tue, May 26, 2020 at 04:15:05AM +0300, Laurent Pinchart
> > > > > > > > wrote:
> > > > > > > > > The DRM CRTC helpers add default modes to connectors in the
> > > > > > > > > connected
> > > > > > > > > state if no mode can be retrieved from the connector. This
> > > > > > > > > behaviour is
> > > > > > > > > useful for VGA or DVI outputs that have no connected DDC bus.
> > > > > > > > > However,
> > > > > > > > > in such cases, the status of the output usually can't be
> > > > > > > > > retrieved and
> > > > > > > > > is reported as connector_status_unknown.
> > > > > > > > >
> > > > > > > > > Extend the addition of default modes to connectors in an
> > > > > > > > > unknown state
> > > > > > > > > to support outputs that can retrieve neither the modes nor the
> > > > > > > > > connection status.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Laurent Pinchart
> > > > > > > > >
> > > > > > > >
> > > > > > > > From your description sounds like an OK approach.
> > > > > > > > But this is not something I feel too familiar with.
> > > > > > > > Acked-by: Sam Ravnborg
> > > > > > >
> > > > > > > Thanks for the ack. I'd like to have Daniel's (CC'ed) feedback on
> > > > > > > this
> > > > > > > too.
> > > > > >
> > > > > > Makes sense, and at least pre-coffee me can't immediately think of a
> > > > > > scenario where we're going to regret this. _unknown status is
> > > > > > pretty much
> > > > > > limited to old VGA and similar things where load detect somehow
> > > > > > isn't well
> > > > > > supported by the hw.
> > > > > >
> > > > > > Reviewed-by: Daniel Vetter
> > > > > >
> > > > > > >
> > > > > > > > > ---
> > > > > > > > > drivers/gpu/drm/drm_probe_helper.c | 3 ++-
> > > > > > > > > include/drm/drm_modeset_helper_vtables.h | 8 +++-
> > > > > > > > > 2 files changed, 9 insertions(+), 2 deletions(-)
> > > > > > > > >
> > > > > > > > > diff --git a/drivers/gpu/drm/drm_probe_helper.c
> > > > > > > > > b/drivers/gpu/drm/drm_probe_helper.c
> > > > > > > > > index f5d141e0400f..9055d9573c90 100644
> > > > > > > > > --- a/drivers/gpu/drm/drm_probe_helper.c
> > > > > > > > > +++ b/drivers/gpu/drm/drm_probe_helper.c
> > > > > > > > > @@ -491,7 +491,8 @@ int
> > > > > > > > > drm_helper_probe_single_connector_modes(struct drm_connector
> > > > > > > > > *connector,
> > > > > > > > > if (count == 0 && connector->status ==
> > > > > > > > > connector_status_connected)
> > > > > > > > > count = drm_add_override_edid_modes(connector);
> > > > > > > > >
> > > > > > > > > - if (count == 0 && connector->status ==
> > > > > > > > > connector_status_connected)
> > > > > > > > > + if (count == 0 && (connector->status ==
> > > > > > > > > connector_status_connected ||
> > > > > > > > > +connector->status ==
> > > > > > > > > connector_status_unknown))
> > > > > > > > > count = drm_add_modes_noedid(connector, 1024, 768);
> > > > > > > > > count += drm_helper_probe_add_cmdline_mode(connector);
> > > > > > > > > if (count == 0)
> > > > > > > > > diff --git a/include/drm/drm_modeset_helper_vtables.h
> > > > > > > > > b/include/drm/drm_modeset_helper_vtables.h
> > > > > > > > > index 421a30f08463..afe55e2e93d2 100644
> > > > > > > > > --- a/include/drm/drm_modeset_helper_vtables.h
> > > > > > > > > +++ b/include/drm/drm_modeset_helper_vtables.h
> > > > > > > > > @@ -876,13 +876,19 @@ struct drm_connector_helper_funcs {
> > > > > > > > >* The usual way to implement this is to cache the EDID
> > > > > > > > > retrieved in the
> > > > > > > > >* probe callback somewhere in the driver-private connector
> > > > > > > > > structure.
> > > > > > > > >* In this function drivers then parse the modes in the
> > > > > > > > > EDID and add
> > > > > > > > > - * them by calling drm_add_edid_modes(). But connectors
> > > > > > > > > that driver a
> > > > > > > > > + * them by calling drm_add_edid_modes(). But connectors
> > > > > > > > > that drive a
> > > > > > > > >* fixed panel can also manually add specific modes using
> > > > > > > > >* drm_mode_probed_add(). Drivers which manually add modes
> > > > > > > > > should also
> > > > > > > > >* make sure that the &drm_connector.display_info,
> > > > > > > > >* &drm_connector.width_mm and &drm_connector.height_mm
> > > > > > > > > fields
Re: [RESEND PATCH v5 3/5] drivers core: allow probe_err accept integer and pointer types
On 25.06.2020 10:41, Andy Shevchenko wrote: > On Wed, Jun 24, 2020 at 10:40 PM Andrzej Hajda wrote: >> On 24.06.2020 17:16, Robin Murphy wrote: > ... > >> I have proposed such thing in my previous iteration[1], except it was >> macro because of variadic arguments. > You may have a function with variadic arguments. Macros are beasts and > make in some cases more harm than help. What harm it can do in this particular case? With macro we have simple straightforward one-liner, with quite good type-checking. Maybe I am wrong, but I suspect creation of variadic function would require much more coding. Regards Andrzej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206475] amdgpu under load drop signal to monitor until hard reset
https://bugzilla.kernel.org/show_bug.cgi?id=206475 --- Comment #17 from Andrew Ammerlaan (andrewammerl...@riseup.net) --- (In reply to Alex Deucher from comment #16) > When the GPU is in reset all reads to the MMIO BAR return 1s so you are just > getting all ones until the reset succeeds. 511 is just all ones. This > patch will fix that issue: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/ > ?id=9271dfd9e0f79e2969dcbe28568bce0fdc4f8f73 Well there goes my hypotheses of the broken thermal sensor xD. I did discover yesterday that the fan of my GPU spins relatively slow under high load. When the GPU reached ~80 degrees Celsius, the fan didn't even spin at half the maximum RPM! I used the pwmconfig script and the fancontrol service from lm_sensors to force the fan to go to the maximum RPM just before reaching 80 degrees Celsius. It's very noisy, *but* the GPU stays well below 70 degrees Celsius now, even under heavy load. As this issue seems to occur only when the GPU is hotter then ~75 degrees Celsius, I'm hoping that this will help in preventing the problem. I'm still confused as to why this is at all necessary, the critical temperature is 91, so why do I encounter these issues at ~80? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND] [PATCH v6 0/8] do not store GPU address in TTM
On Thu, Jun 25, 2020 at 11:50 AM Christian König wrote: > > I've pushed patches #1, #2 and #5-#8 of this series to drm-misc-next. > > Only VMGFX and Nouveau are missing and I'm pretty close to just push > them with my Acked-by since they should not contain any functional change. > > Any objections? Sounds good to me, I just suggested to Alex on irc you do just that. These patches have been floating for long enough that there's stalling for driver maintainers is imo not needed for longer. -Daniel > > Thanks, > Christian. > > Am 24.06.20 um 20:26 schrieb Nirmoy Das: > > With this patch series I am trying to remove GPU address dependency in > > TTM and moving GPU address calculation to individual drm drivers. This > > cleanup will simplify introduction of drm_mem_region/domain work started > > by Brian Welty[1]. > > > > > > It would be nice if someone test this for nouveau. Rest of the drivers > > are already tested. > > > > v2: > > * set bo->offset = 0 for drm/nouveau if bo->mem.mm_node == NULL > > > > v3: > > * catch return value of drm_gem_vram_offset() in drm/bochs > > * introduce drm_gem_vram_pg_offset() in vram helper > > * improve nbo->offset calculation for nouveau > > > > v4: > > * minor coding style fixes in amdgpu and radeon > > * remove unnecessary kerneldoc for internal function > > > > v5: > > * rebase on top of drm-misc-next > > * fix return value of drm_gem_vram_pg_offset() > > * add a comment in drm_gem_vram_pg_offset() to clearify why we return 0. > > > > v6: > > * rebase to drm-misc-next > > * removed acked for vmwgfx as there was a small conflict > > > > Nirmoy Das (8): > >drm/amdgpu: move ttm bo->offset to amdgpu_bo > >drm/radeon: don't use ttm bo->offset > >drm/vmwgfx: don't use ttm bo->offset > >drm/nouveau: don't use ttm bo->offset v3 > >drm/qxl: don't use ttm bo->offset > >drm/vram-helper: don't use ttm bo->offset v4 > >drm/bochs: use drm_gem_vram_offset to get bo offset v2 > >drm/ttm: do not keep GPU dependent addresses > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 23 ++-- > > drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 1 + > > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 30 - > > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 1 + > > drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c | 4 +-- > > drivers/gpu/drm/bochs/bochs_kms.c | 7 - > > drivers/gpu/drm/drm_gem_vram_helper.c | 11 +++- > > drivers/gpu/drm/nouveau/dispnv04/crtc.c | 6 ++--- > > drivers/gpu/drm/nouveau/dispnv04/disp.c | 3 ++- > > drivers/gpu/drm/nouveau/dispnv04/overlay.c | 6 ++--- > > drivers/gpu/drm/nouveau/dispnv50/base507c.c | 2 +- > > drivers/gpu/drm/nouveau/dispnv50/core507d.c | 2 +- > > drivers/gpu/drm/nouveau/dispnv50/ovly507e.c | 2 +- > > drivers/gpu/drm/nouveau/dispnv50/wndw.c | 2 +- > > drivers/gpu/drm/nouveau/dispnv50/wndwc37e.c | 2 +- > > drivers/gpu/drm/nouveau/nouveau_abi16.c | 8 +++--- > > drivers/gpu/drm/nouveau/nouveau_bo.c| 8 ++ > > drivers/gpu/drm/nouveau/nouveau_bo.h| 3 +++ > > drivers/gpu/drm/nouveau/nouveau_chan.c | 2 +- > > drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +- > > drivers/gpu/drm/nouveau/nouveau_fbcon.c | 2 +- > > drivers/gpu/drm/nouveau/nouveau_gem.c | 10 +++ > > drivers/gpu/drm/qxl/qxl_drv.h | 6 ++--- > > drivers/gpu/drm/qxl/qxl_kms.c | 5 ++-- > > drivers/gpu/drm/qxl/qxl_object.h| 5 > > drivers/gpu/drm/qxl/qxl_ttm.c | 9 --- > > drivers/gpu/drm/radeon/radeon.h | 1 + > > drivers/gpu/drm/radeon/radeon_object.h | 16 ++- > > drivers/gpu/drm/radeon/radeon_ttm.c | 4 +-- > > drivers/gpu/drm/ttm/ttm_bo.c| 7 - > > drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 4 +-- > > drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 2 +- > > drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c| 2 +- > > drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 -- > > include/drm/ttm/ttm_bo_api.h| 2 -- > > include/drm/ttm/ttm_bo_driver.h | 1 - > > 36 files changed, 125 insertions(+), 78 deletions(-) > > > > -- > > 2.27.0 > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND] [PATCH v6 0/8] do not store GPU address in TTM
I've pushed patches #1, #2 and #5-#8 of this series to drm-misc-next. Only VMGFX and Nouveau are missing and I'm pretty close to just push them with my Acked-by since they should not contain any functional change. Any objections? Thanks, Christian. Am 24.06.20 um 20:26 schrieb Nirmoy Das: With this patch series I am trying to remove GPU address dependency in TTM and moving GPU address calculation to individual drm drivers. This cleanup will simplify introduction of drm_mem_region/domain work started by Brian Welty[1]. It would be nice if someone test this for nouveau. Rest of the drivers are already tested. v2: * set bo->offset = 0 for drm/nouveau if bo->mem.mm_node == NULL v3: * catch return value of drm_gem_vram_offset() in drm/bochs * introduce drm_gem_vram_pg_offset() in vram helper * improve nbo->offset calculation for nouveau v4: * minor coding style fixes in amdgpu and radeon * remove unnecessary kerneldoc for internal function v5: * rebase on top of drm-misc-next * fix return value of drm_gem_vram_pg_offset() * add a comment in drm_gem_vram_pg_offset() to clearify why we return 0. v6: * rebase to drm-misc-next * removed acked for vmwgfx as there was a small conflict Nirmoy Das (8): drm/amdgpu: move ttm bo->offset to amdgpu_bo drm/radeon: don't use ttm bo->offset drm/vmwgfx: don't use ttm bo->offset drm/nouveau: don't use ttm bo->offset v3 drm/qxl: don't use ttm bo->offset drm/vram-helper: don't use ttm bo->offset v4 drm/bochs: use drm_gem_vram_offset to get bo offset v2 drm/ttm: do not keep GPU dependent addresses drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 23 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 30 - drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c | 4 +-- drivers/gpu/drm/bochs/bochs_kms.c | 7 - drivers/gpu/drm/drm_gem_vram_helper.c | 11 +++- drivers/gpu/drm/nouveau/dispnv04/crtc.c | 6 ++--- drivers/gpu/drm/nouveau/dispnv04/disp.c | 3 ++- drivers/gpu/drm/nouveau/dispnv04/overlay.c | 6 ++--- drivers/gpu/drm/nouveau/dispnv50/base507c.c | 2 +- drivers/gpu/drm/nouveau/dispnv50/core507d.c | 2 +- drivers/gpu/drm/nouveau/dispnv50/ovly507e.c | 2 +- drivers/gpu/drm/nouveau/dispnv50/wndw.c | 2 +- drivers/gpu/drm/nouveau/dispnv50/wndwc37e.c | 2 +- drivers/gpu/drm/nouveau/nouveau_abi16.c | 8 +++--- drivers/gpu/drm/nouveau/nouveau_bo.c| 8 ++ drivers/gpu/drm/nouveau/nouveau_bo.h| 3 +++ drivers/gpu/drm/nouveau/nouveau_chan.c | 2 +- drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +- drivers/gpu/drm/nouveau/nouveau_fbcon.c | 2 +- drivers/gpu/drm/nouveau/nouveau_gem.c | 10 +++ drivers/gpu/drm/qxl/qxl_drv.h | 6 ++--- drivers/gpu/drm/qxl/qxl_kms.c | 5 ++-- drivers/gpu/drm/qxl/qxl_object.h| 5 drivers/gpu/drm/qxl/qxl_ttm.c | 9 --- drivers/gpu/drm/radeon/radeon.h | 1 + drivers/gpu/drm/radeon/radeon_object.h | 16 ++- drivers/gpu/drm/radeon/radeon_ttm.c | 4 +-- drivers/gpu/drm/ttm/ttm_bo.c| 7 - drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 4 +-- drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c| 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 -- include/drm/ttm/ttm_bo_api.h| 2 -- include/drm/ttm/ttm_bo_driver.h | 1 - 36 files changed, 125 insertions(+), 78 deletions(-) -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 8/8] backlight: qcom-wled: Remove unused configs for LED3 and LED4
On Wed, Jun 24, 2020 at 03:57:21PM +0100, Lee Jones wrote:
> Fixes W=1 warnings:
>
> drivers/video/backlight/qcom-wled.c:1294:34: warning: ‘wled4_string_cfg’
> defined but not used [-Wunused-const-variable=]
> 1294 | static const struct wled_var_cfg wled4_string_cfg = {
> | ^~~~
> drivers/video/backlight/qcom-wled.c:1290:34: warning: ‘wled3_string_cfg’
> defined but not used [-Wunused-const-variable=]
> 1290 | static const struct wled_var_cfg wled3_string_cfg = {
> | ^~~~
>
> Cc:
> Cc: Andy Gross
> Cc: Bjorn Andersson
> Cc: Bartlomiej Zolnierkiewicz
> Cc: linux-arm-...@vger.kernel.org
> Signed-off-by: Lee Jones
Reviewed-by: Daniel Thompson
> ---
> drivers/video/backlight/qcom-wled.c | 8
> 1 file changed, 8 deletions(-)
>
> diff --git a/drivers/video/backlight/qcom-wled.c
> b/drivers/video/backlight/qcom-wled.c
> index 4c8c34b994414..c25c31199952c 100644
> --- a/drivers/video/backlight/qcom-wled.c
> +++ b/drivers/video/backlight/qcom-wled.c
> @@ -1287,14 +1287,6 @@ static const struct wled_var_cfg
> wled4_string_i_limit_cfg = {
> .size = ARRAY_SIZE(wled4_string_i_limit_values),
> };
>
> -static const struct wled_var_cfg wled3_string_cfg = {
> - .size = 8,
> -};
> -
> -static const struct wled_var_cfg wled4_string_cfg = {
> - .size = 16,
> -};
> -
> static const struct wled_var_cfg wled5_mod_sel_cfg = {
> .size = 2,
> };
> --
> 2.25.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 7/8] backlight: lm3630a_bl: Remove invalid checks for unsigned int < 0
On Wed, Jun 24, 2020 at 03:57:20PM +0100, Lee Jones wrote:
> unsigned ints 'sources' and 'bank' cannot be less than LM3630A_SINK_0 (0)
> and LM3630A_BANK_0 (0) respecitively, so change the logic to only check
> for thier two possible valid values.
>
> Fixes W=1 warnings:
>
> drivers/video/backlight/lm3630a_bl.c: In function
> ‘lm3630a_parse_led_sources’:
> drivers/video/backlight/lm3630a_bl.c:394:18: warning: comparison of unsigned
> expression < 0 is always false [-Wtype-limits]
> 394 | if (sources[i] < LM3630A_SINK_0 || sources[i] > LM3630A_SINK_1)
> | ^
> drivers/video/backlight/lm3630a_bl.c: In function ‘lm3630a_parse_bank’:
> drivers/video/backlight/lm3630a_bl.c:415:11: warning: comparison of unsigned
> expression < 0 is always false [-Wtype-limits]
> 415 | if (bank < LM3630A_BANK_0 || bank > LM3630A_BANK_1)
> | ^
>
> Cc:
> Cc: Bartlomiej Zolnierkiewicz
> Cc: Daniel Jeong
> Cc: LDD MLP
> Signed-off-by: Lee Jones
Reviewed-by: Daniel Thompson
> ---
> drivers/video/backlight/lm3630a_bl.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/backlight/lm3630a_bl.c
> b/drivers/video/backlight/lm3630a_bl.c
> index ee320883b7108..e88a2b0e59046 100644
> --- a/drivers/video/backlight/lm3630a_bl.c
> +++ b/drivers/video/backlight/lm3630a_bl.c
> @@ -391,7 +391,7 @@ static int lm3630a_parse_led_sources(struct fwnode_handle
> *node,
> return ret;
>
> for (i = 0; i < num_sources; i++) {
> - if (sources[i] < LM3630A_SINK_0 || sources[i] > LM3630A_SINK_1)
> + if (sources[i] != LM3630A_SINK_0 && sources[i] !=
> LM3630A_SINK_1)
> return -EINVAL;
>
> ret |= BIT(sources[i]);
> @@ -412,7 +412,7 @@ static int lm3630a_parse_bank(struct
> lm3630a_platform_data *pdata,
> if (ret)
> return ret;
>
> - if (bank < LM3630A_BANK_0 || bank > LM3630A_BANK_1)
> + if (bank != LM3630A_BANK_0 && bank != LM3630A_BANK_1)
> return -EINVAL;
>
> led_sources = lm3630a_parse_led_sources(node, BIT(bank));
> --
> 2.25.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/8] backlight: ili922x: Add missing kerneldoc description for ili922x_reg_dump()'s arg
On Wed, Jun 24, 2020 at 03:57:18PM +0100, Lee Jones wrote:
> Kerneldoc syntax is used, but not complete. Descriptions required.
>
> Prevents warnings like:
>
> drivers/video/backlight/ili922x.c:298: warning: Function parameter or member
> 'spi' not described in 'ili922x_reg_dump'
>
> Cc:
> Cc: Bartlomiej Zolnierkiewicz
> Cc: Software Engineering
> Signed-off-by: Lee Jones
> ---
> drivers/video/backlight/ili922x.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/video/backlight/ili922x.c
> b/drivers/video/backlight/ili922x.c
> index cd41433b87aeb..26193f38234e7 100644
> --- a/drivers/video/backlight/ili922x.c
> +++ b/drivers/video/backlight/ili922x.c
> @@ -295,6 +295,8 @@ static int ili922x_write(struct spi_device *spi, u8 reg,
> u16 value)
> #ifdef DEBUG
> /**
> * ili922x_reg_dump - dump all registers
> + *
> + * @spi: pointer to the controller side proxy for an SPI slave device
Similar to previous... and I also noticed that there are several other
existing @spi descriptions in this file and it would be good to make
them consistent.
Daniel.
> */
> static void ili922x_reg_dump(struct spi_device *spi)
> {
> --
> 2.25.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/8] backlight: backlight: Supply description for function args in existing Kerneldocs
On Wed, Jun 24, 2020 at 03:57:19PM +0100, Lee Jones wrote: > Kerneldoc syntax is used, but not complete. Descriptions required. > > Prevents warnings like: > > drivers/video/backlight/backlight.c:329: warning: Function parameter or > member 'reason' not described in 'backlight_force_update' > drivers/video/backlight/backlight.c:354: warning: Function parameter or > member 'props' not described in 'backlight_device_register' > > Cc: > Cc: Bartlomiej Zolnierkiewicz > Cc: Jamey Hicks > Cc: Andrew Zabolotny > Signed-off-by: Lee Jones Reviewed-by: Daniel Thompson > --- > drivers/video/backlight/backlight.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/video/backlight/backlight.c > b/drivers/video/backlight/backlight.c > index 92d80aa0c0ef1..744ba58488e01 100644 > --- a/drivers/video/backlight/backlight.c > +++ b/drivers/video/backlight/backlight.c > @@ -320,6 +320,7 @@ ATTRIBUTE_GROUPS(bl_device); > * backlight_force_update - tell the backlight subsystem that hardware state > * has changed > * @bd: the backlight device to update > + * @reason: reason for update > * > * Updates the internal state of the backlight in response to a hardware > event, > * and generate a uevent to notify userspace > @@ -344,6 +345,7 @@ EXPORT_SYMBOL(backlight_force_update); > * @devdata: an optional pointer to be stored for private driver use. The > * methods may retrieve it by using bl_get_data(bd). > * @ops: the backlight operations structure. > + * @props: pointer to backlight's properties structure. > * > * Creates and registers new backlight device. Returns either an > * ERR_PTR() or a pointer to the newly allocated device. > -- > 2.25.1 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/8] backlight: ili922x: Remove invalid use of kerneldoc syntax
On Wed, Jun 24, 2020 at 03:57:17PM +0100, Lee Jones wrote:
> Kerneldoc is for documenting function arguments and return values.
>
> Prevents warnings like:
>
> drivers/video/backlight/ili922x.c:127: warning: cannot understand function
> prototype: 'int ili922x_id = 1; '
> drivers/video/backlight/ili922x.c:136: warning: cannot understand function
> prototype: 'struct ili922x '
>
> Cc:
> Cc: Bartlomiej Zolnierkiewicz
> Cc: Software Engineering
> Signed-off-by: Lee Jones
Reviewed-by: Daniel Thompson
> ---
> drivers/video/backlight/ili922x.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/backlight/ili922x.c
> b/drivers/video/backlight/ili922x.c
> index 8cb4b9d3c3bba..cd41433b87aeb 100644
> --- a/drivers/video/backlight/ili922x.c
> +++ b/drivers/video/backlight/ili922x.c
> @@ -123,7 +123,7 @@
>
> #define set_tx_byte(b) (tx_invert ? ~(b) : b)
>
> -/**
> +/*
> * ili922x_id - id as set by manufacturer
> */
> static int ili922x_id = 1;
> @@ -132,7 +132,7 @@ module_param(ili922x_id, int, 0);
> static int tx_invert;
> module_param(tx_invert, int, 0);
>
> -/**
> +/*
> * driver's private structure
> */
> struct ili922x {
> --
> 2.25.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/8] backlight: ili922x: Add missing kerneldoc descriptions for CHECK_FREQ_REG() args
On Wed, Jun 24, 2020 at 03:57:16PM +0100, Lee Jones wrote:
> Kerneldoc syntax is used, but not complete. Descriptions required.
>
> Prevents warnings like:
>
> drivers/video/backlight/ili922x.c:116: warning: Function parameter or member
> 's' not described in 'CHECK_FREQ_REG'
> drivers/video/backlight/ili922x.c:116: warning: Function parameter or member
> 'x' not described in 'CHECK_FREQ_REG'
>
> Cc:
> Cc: Bartlomiej Zolnierkiewicz
> Cc: Software Engineering
> Signed-off-by: Lee Jones
> ---
> drivers/video/backlight/ili922x.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/video/backlight/ili922x.c
> b/drivers/video/backlight/ili922x.c
> index 9c5aa3fbb2842..8cb4b9d3c3bba 100644
> --- a/drivers/video/backlight/ili922x.c
> +++ b/drivers/video/backlight/ili922x.c
> @@ -107,6 +107,8 @@
> * lower frequency when the registers are read/written.
> * The macro sets the frequency in the spi_transfer structure if
> * the frequency exceeds the maximum value.
> + * @s: pointer to controller side proxy for an SPI slave device
What's wrong with "a pointer to an SPI device"?
I am aware, having looked it up to find out what the above actually
means, that this is how struct spi_device is described in its own kernel
doc but quoting at that level of detail of both overkill and confusing.
Daniel.
> + * @x: pointer to the read/write buffer pair
> */
> #define CHECK_FREQ_REG(s, x) \
> do {\
> --
> 2.25.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/8] backlight: lcd: Add missing kerneldoc entry for 'struct device parent'
On Wed, Jun 24, 2020 at 03:57:15PM +0100, Lee Jones wrote: > This has been missing since the conversion to 'struct device' in 2007. > > Cc: > Cc: Bartlomiej Zolnierkiewicz > Cc: Jamey Hicks > Cc: Andrew Zabolotny > Signed-off-by: Lee Jones Reviewed-by: Daniel Thompson > --- > drivers/video/backlight/lcd.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/video/backlight/lcd.c b/drivers/video/backlight/lcd.c > index 78b0333586258..db56e465aaff3 100644 > --- a/drivers/video/backlight/lcd.c > +++ b/drivers/video/backlight/lcd.c > @@ -179,6 +179,7 @@ ATTRIBUTE_GROUPS(lcd_device); > * lcd_device_register - register a new object of lcd_device class. > * @name: the name of the new object(must be the same as the name of the > * respective framebuffer device). > + * @parent: pointer to the parent's struct device . > * @devdata: an optional pointer to be stored in the device. The > * methods may retrieve it by using lcd_get_data(ld). > * @ops: the lcd operations structure. > -- > 2.25.1 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Host1x/TegraDRM UAPI
On 6/25/20 1:33 AM, Dmitry Osipenko wrote:
23.06.2020 15:09, Mikko Perttunen пишет:
struct drm_tegra_submit_relocation {
/* [in] Index of GATHER or GATHER_UPTR command in commands. */
__u32 gather_command_index;
/*
* [in] Mapping handle (obtained through CHANNEL_MAP) of the memory
* the address of which will be patched in.
*/
__u32 mapping_id;
/*
* [in] Offset in the gather that will be patched.
*/
__u64 gather_offset;
/*
* [in] Offset in target buffer whose paddr/IOVA will be written
* to the gather.
*/
__u64 target_offset;
/*
* [in] Number of bits the resulting address will be logically
* shifted right before writing to gather.
*/
__u32 shift;
__u32 reserved[1];
};
We will also need read/write direction flag here for the
DMA-reservations set up, it will be used for the implicit BO fencing by
the job's scheduler.
Ideally on newer chips with context isolation, we no longer know what
DMA-BUFs are being used by the job at submit time - they would just be
pointers after being MAPped.
Do you know how other GPUs deal with DMA reservations - I expect
separate MAP and SUBMIT steps would be pretty common? Do you have to
pass the DMA-BUF to both steps (i.e. do IOMMU mapping during MAP, and
manage reservations at SUBMIT)?
Mikko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/8] backlight: lms501kf03: Remove unused const variables
On Wed, Jun 24, 2020 at 03:57:14PM +0100, Lee Jones wrote:
> W=1 kernel build reports:
>
> drivers/video/backlight/lms501kf03.c:96:28: warning: ‘seq_sleep_in’ defined
> but not used [-Wunused-const-variable=]
> 96 | static const unsigned char seq_sleep_in[] = {
> | ^~~~
> drivers/video/backlight/lms501kf03.c:92:28: warning: ‘seq_up_dn’ defined but
> not used [-Wunused-const-variable=]
> 92 | static const unsigned char seq_up_dn[] = {
> | ^
>
> Either 'seq_sleep_in' nor 'seq_up_dn' have been used since the
> driver first landed in 2013.
>
> Cc:
> Cc: Bartlomiej Zolnierkiewicz
> Signed-off-by: Lee Jones
Reviewed-by: Daniel Thompson
> ---
> drivers/video/backlight/lms501kf03.c | 8
> 1 file changed, 8 deletions(-)
>
> diff --git a/drivers/video/backlight/lms501kf03.c
> b/drivers/video/backlight/lms501kf03.c
> index 8ae32e3573c1a..c1bd02bb8b2ee 100644
> --- a/drivers/video/backlight/lms501kf03.c
> +++ b/drivers/video/backlight/lms501kf03.c
> @@ -89,14 +89,6 @@ static const unsigned char seq_rgb_gamma[] = {
> 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> };
>
> -static const unsigned char seq_up_dn[] = {
> - 0x36, 0x10,
> -};
> -
> -static const unsigned char seq_sleep_in[] = {
> - 0x10,
> -};
> -
> static const unsigned char seq_sleep_out[] = {
> 0x11,
> };
> --
> 2.25.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Host1x/TegraDRM UAPI
On 6/25/20 3:47 AM, Dmitry Osipenko wrote: 23.06.2020 15:09, Mikko Perttunen пишет: #define DRM_TEGRA_SUBMIT_CREATE_POST_SYNC_FILE (1<<0) #define DRM_TEGRA_SUBMIT_CREATE_POST_SYNCOBJ (1<<1) The sync object shouldn't be created by the kernel driver and we shouldn't need the sync-file FD. Please consider this example of how syncobj may be used: 1. Syncobj is created by userspace. 2. Syncobj's handle (post_fence) is passed with the job to the kernel driver. 3. Userspace waits on syncobj for the job's submission. 4. Kernel driver attaches job-completion dma-fence(s) to the syncobj after starting to execute the job. 5. Userspace waits on syncobj for the job's completion. Syncobj is a superset of the sync-file fence: a) Syncobj doesn't have a backing file descriptor when it's created. For example, why would you need an FD if you're not going to share fence with other processes. It's possible to get FD out of syncobj later on, please see [1][2]. b) Syncobj is designed to be used with a GPU jobs. For example, userspace passes job to the GPU driver's scheduler and then waits until job has been started to execute on hardware, this is already supported by syncobj. c) It is possible to attach sync-file's fence to a syncobj [1][2][3] and now: - Userspace may attach sync-file's fence to a syncobj. - Userspace may use this syncobj for the job's pre-fence. - Kernel driver will take out the pre-fence from the syncobj during of the job's submission and reset the syncobj's fence to NULL. - Job's scheduler will wait on this pre-fence before starting to execute job. - Once the job is started to execute, the job's scheduler will attach the job's completion-fence to the syncobj. Now syncobj has a post-fence! d) It is possible to get sync-file FD out of syncobj [1][2][4]. [1] https://elixir.bootlin.com/linux/v5.7.2/source/include/uapi/drm/drm.h#L730 [2] https://elixir.bootlin.com/linux/v5.7.2/source/include/uapi/drm/drm.h#L933 [3] https://elixir.bootlin.com/linux/v5.7.2/source/drivers/gpu/drm/drm_syncobj.c#L653 [4] https://elixir.bootlin.com/linux/v5.7.2/source/drivers/gpu/drm/drm_syncobj.c#L674 === So, sync object can carry both pre-fence and post-fence, and they could be sync-file FDs! The corollary is that we can get away by using a single syncobj handle for the job's submission IOCTL. Ah, clearly I hadn't understood syncobjs properly :) Last time I spent significant time with this they didn't exist yet.. I'll check this out. Mikko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Host1x/TegraDRM UAPI
On 6/25/20 2:23 AM, Dmitry Osipenko wrote:
23.06.2020 15:09, Mikko Perttunen пишет:
struct drm_tegra_channel_submit {
__u32 channel_id;
__u32 flags;
/**
* [in] Timeout in microseconds after which the kernel may
* consider the job to have hung and may reap it and
* fast-forward its syncpoint increments.
*
* The value may be capped by the kernel.
*/
__u32 timeout;
What about to rename this to timeout_us? For clarity.
__u32 num_syncpt_incrs;
__u32 num_relocations;
__u32 num_commands;
__u64 syncpt_incrs;
__u64 relocations;
__u64 commands;
Let's also add "_ptr" postfix to all usrptr names, again for clarity.
It's always nice to have meaningful names :)
Yep, good point. I'll fix this for next revision :)
Mikko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Host1x/TegraDRM UAPI
On 6/24/20 11:55 PM, Dmitry Osipenko wrote: 23.06.2020 15:09, Mikko Perttunen пишет: ... * Previously present GEM IOCTLs (GEM_CREATE, GEM_MMAP) are not present. Not sure if they are still needed. Hello Mikko! A quick comment for the starter. Switching away from the Tegra-specific GEM IOCTLs to the dma-buf heaps is a such radical change! But I like it! Previously I was curious about whether we could have multiple CMA regions (one shared/reusable and other private, for example) for the Tegra DRM driver and at a quick glance the dma-buf heaps could be a nice solution that avoids re-inventing a driver-specific things for that. I'm instantly foreseeing these types of heaps: 1. Large reusable CMA heap. 2. Smaller non-reusable common CMA that could be used when allocation from a reusable CMA fails. Or vice versa, when we want to reduce the chance to block for a long time on allocation, for example. 3. Sparse (system) memory heap. It's the first time I'm looking at the dma-buf heaps and it sounds like a very nice idea to utilize them! The https://lkml.org/lkml/2019/11/18/787 says that the system-contiguous and carveout heaps we not added because they were not needed, but they will be needed for the Tegra20 drivers and for the case where IOMMU is disabled. It shouldn't be difficult to add these types of heaps. I'll continue to examine the dma-buf heaps in a more details. Sure, let's go with this for now. We can anyway add GEM IOCTLs later if they are needed, without any compatibility issues. Mikko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Host1x/TegraDRM UAPI
On 6/25/20 2:11 AM, Dmitry Osipenko wrote: 23.06.2020 15:09, Mikko Perttunen пишет: /* Command is an opcode gather from a GEM handle */ #define DRM_TEGRA_SUBMIT_COMMAND_GATHER 0 /* Command is an opcode gather from a user pointer */ #define DRM_TEGRA_SUBMIT_COMMAND_GATHER_UPTR 1 I'm a bit dubious about whether we really need to retain the non-UPTR variant. The memory-copying overhead is negligible because cmdstream's data usually is hot in CPU's cache IIRC, the most (if not all) of the modern DRM drivers drivers use the usrptr-only for the cmdstream. At least there is no any real-world userspace example today that could benefit from a non-UPTR variant. I'm suggesting to leave out the non-UPTR gather variant for now, keeping it in mind as a potential future extension of the submission UAPI. Any objections? Sure, we should be able to drop it. Downstream userspace is using it, but we should be able to fix that. I was thinking that we can directly map the user pages and point the gather to them without copying - that way we wouldn't need to make DMA allocations inside the driver for every submit. (On early Tegras we could just copy into the pushbuffer but that won't work for newer ones). Mikko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/27] Converter R-Car DU to the DRM bridge connector helper
Hi Sam, On Tue, 2020-06-23 at 20:55 +0200, Sam Ravnborg wrote: > Hi Laurent. > > On Tue, May 26, 2020 at 04:14:38AM +0300, Laurent Pinchart wrote: > > Hello, > > > > This patch series converts the R-Car DU driver to use the DRM > > bridge > > connector helper drm_bridge_connector_init(). > > > > The bulk of the series is conversion of the adv7511, simple-bridge, > > rcar-lbds and dw-hdmi drivers to make connector creation optional > > (through the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag). > > > > The series starts with the adv7511 driver, previously posted as > > "[PATCH > > 0/4] drm: bridge: adv7511: Enable usage with DRM bridge connector > > helper" ([1]). Patches 01/27 to 04/27 incorporate all the received > > review comments. > > > > The next three patches address the simple-bridge driver, previously > > posted as "[PATCH 0/2] drm: bridge: simple-bridge: Enable usage > > with DRM > > bridge connector helper". Patch 05/27 is an additional fix that > > stems > > from the review, and patches 06/27 and 07/27 incorporate all the > > received review comments. > > > > Patch 08/27 is a new patch that addresses the rcar-lvds driver. > > Instead > > of implementing direct support for DRM_BRIDGE_ATTACH_NO_CONNECTOR, > > it > > simply removes code that shouldn't have been in the driver in the > > first > > place by switching to the panel bridge helper. > > > > Patches 09/27 to 22/27 then address the dw-hdmi driver. That's a > > more > > sizeable rework, due to the fact that the driver implements a mid- > > layer > > for platform-specific glue, with the internal drm_connector being > > used > > throughout the whole code. There's no rocket science there, but > > patch > > 10/27 should be noted for adding a new argument to the > > drm_bridge_funcs.mode_valid() function. Please see individual > > patches > > for details. > > > > Patch 23/27 adds support to the dw-hdmi driver to attach to a > > downstream > > bridge if one is specified in DT. As the DT port number > > corresponding to > > the video output differs between platforms that integrate the dw- > > hdmi > > (some of them even don't have a video output port, which should > > probably > > be fixed, but that's out of scope for this series), the port number > > has > > to be specified by the platform glue layer. Patch 24/27 does so for > > the > > R-Car dw-hdmi driver. > > > > Patch 25/27 is a drive-by fix for an error path issue in the rcar- > > du > > driver. Patch 26/27 finally makes use of the > > drm_bridge_connector_init() > > helper. > > > > Unfortunately, this breaks the VGA output on R-Car Gen3 platforms. > > On > > those platforms, the VGA DDC lines are not connected, and there is > > no > > mean for software to detect the VGA output connection status. When > > the > > simple-bridge driver creates a connector, it automatically adds > > default > > modes when no DDC is available. This behavious is also present int > > the > > DRM probe helper drm_helper_probe_single_connector_modes(), but > > only > > when the connector status is connector_status_connected. As the > > driver > > (rightfully) reports connector_status_unconnected, no modes are > > added. > > Patch 27/27 fixes this issue by extending addition of default modes > > in > > drm_helper_probe_single_connector_modes() when the output status is > > unknown. An alternative approach would be to implement this > > behaviour in > > the bridge connector helper (drm_bridge_connector.c). > > > > All the modified drivers have been compile-tested, and the series > > has > > been tested on a Renesas R-Car Salvator-XS board with the VGA, HDMI > > and > > LVDS outputs. > > > > [1] > > https://lore.kernel.org/dri-devel/20200409004610.12346-1-laurent.pinchart+rene...@ideasonboard.com/ > > [2] > > https://lore.kernel.org/dri-devel/20200409003636.11792-1-laurent.pinchart+rene...@ideasonboard.com/ > > As we briefly discussed on IRC the first 21 patches are now applied > to > drm-misc-next. I see patch '[22/27] drm: bridge: dw-hdmi: Make connector creation optional' is applied to drm-misc-next. That patch would introduce an uninitialized mutex accessing issue as I mentioned in the patch[1]. And, the patch intends to fix the issue in the first place. [1] https://patchwork.freedesktop.org/patch/370560/ Regards, Liu Ying > The rcar-du specific patches was left out and the last patch was > likewise not applied in this round- mostly because it was the coming > after several rcar-du patches and I was not sure if there was some > dependencies to consider. > > With this set in we have more examples in the tree how to do proper > bridges which is good. > > While applying the new r-bs was ofc added. > > Sam > > > > > Laurent Pinchart (27): > > drm: bridge: adv7511: Split EDID read to a separate function > > drm: bridge: adv7511: Split connector creation to a separate > > function > > drm: bridge: adv7511: Implement bridge connector operations > > drm: bridge: adv7511: Make connector creation
Re: [RESEND PATCH v5 3/5] drivers core: allow probe_err accept integer and pointer types
On Wed, Jun 24, 2020 at 10:40 PM Andrzej Hajda wrote: > On 24.06.2020 17:16, Robin Murphy wrote: ... > I have proposed such thing in my previous iteration[1], except it was > macro because of variadic arguments. You may have a function with variadic arguments. Macros are beasts and make in some cases more harm than help. -- With Best Regards, Andy Shevchenko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 3/3] drm/i915: Send hotplug event if edid had changed
Op 23-06-2020 om 20:57 schreef Kunal Joshi:
> From: Stanislav Lisovskiy
>
> Added epoch counter checking to intel_encoder_hotplug
> in order to be able process all the connector changes,
> besides connection status. Also now any change in connector
> would result in epoch counter change, so no multiple checks
> are needed.
>
> v2: Renamed change counter to epoch counter. Fixed type name.
>
> v3: Fixed rebase conflict
>
> v4: Remove duplicate drm_edid_equal checks from hdmi and dp,
> lets use only once edid property is getting updated and
> increment epoch counter from there.
> Also lets now call drm_connector_update_edid_property
> right after we get edid always to make sure there is a
> unified way to handle edid change, without having to
> change tons of source code as currently
> drm_connector_update_edid_property is called only in
> certain cases like reprobing and not right after edid is
> actually updated.
>
> v5: Fixed const modifiers, removed blank line
>
> v6: Removed drm specific part from this patch, leaving only
> i915 specific changes here.
>
> Signed-off-by: Stanislav Lisovskiy
> ---
Much better!
Reviewed-by: Maarten Lankhorst
for whole series
> drivers/gpu/drm/i915/display/intel_hotplug.c | 26 +++-
> 1 file changed, 15 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c
> b/drivers/gpu/drm/i915/display/intel_hotplug.c
> index 2e94c1413c02..393813494523 100644
> --- a/drivers/gpu/drm/i915/display/intel_hotplug.c
> +++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
> @@ -283,6 +283,8 @@ intel_encoder_hotplug(struct intel_encoder *encoder,
> {
> struct drm_device *dev = connector->base.dev;
> enum drm_connector_status old_status;
> +u64 old_epoch_counter;
> +bool ret = false;
>
> drm_WARN_ON(dev, !mutex_is_locked(&dev->mode_config.mutex));
> old_status = connector->base.status;
> @@ -290,17 +292,19 @@ intel_encoder_hotplug(struct intel_encoder *encoder,
> connector->base.status =
> drm_helper_probe_detect(&connector->base, NULL, false);
>
> - if (old_status == connector->base.status)
> - return INTEL_HOTPLUG_UNCHANGED;
> -
> - drm_dbg_kms(&to_i915(dev)->drm,
> - "[CONNECTOR:%d:%s] status updated from %s to %s\n",
> - connector->base.base.id,
> - connector->base.name,
> - drm_get_connector_status_name(old_status),
> - drm_get_connector_status_name(connector->base.status));
> -
> - return INTEL_HOTPLUG_CHANGED;
> +if (old_epoch_counter != connector->base.epoch_counter)
> +ret = true;
> +
> +if(ret) {
> + DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %s to
> %s(epoch counter %llu)\n",
> + connector->base.base.id,
> + connector->base.name,
> + drm_get_connector_status_name(old_status),
> +
> drm_get_connector_status_name(connector->base.status),
> + connector->base.epoch_counter);
> + return INTEL_HOTPLUG_CHANGED;
> +}
> +return INTEL_HOTPLUG_UNCHANGED;
> }
>
> static bool intel_encoder_has_hpd_pulse(struct intel_encoder *encoder)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-fixes
Hi Dave and Daniel, there's the PR for the current patches in drm-misc-fixes. Besides the fixes there's also a merge of v.5.8-rc1. Best regards Thomas drm-misc-fixes-2020-06-25: Short summary of fixes pull (less than what git shortlog provides): * In mcde, set up fbdev after device registration and removde the last access to dev->dev_private. Fixes an error message and a segmentation fault. * Set the connector type for LogicPT Type 28 and newhaven_nhd_43_480272ef_atxl panels. * In uvesafb, fix the handling of the noblank option. * Fix panel orientation for Asus T101HA and Acer S1003. * Fix DMA configuration for sun4i if IOMMU is present. * Fix regression in VT restoration. Unbreaks userspace (i.e., Xorg) VT handling. The following changes since commit b3a9e3b9622ae10064826dccb4f7a52bd88c7407: Linux 5.8-rc1 (2020-06-14 12:45:04 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2020-06-25 for you to fetch changes up to dc5bdb68b5b369d5bc7d1de96fa64cc1737a6320: drm/fb-helper: Fix vt restore (2020-06-24 21:34:11 +0200) Short summary of fixes pull (less than what git shortlog provides): * In mcde, set up fbdev after device registration and removde the last access to dev->dev_private. Fixes an error message and a segmentation fault. * Set the connector type for LogicPT Type 28 and newhaven_nhd_43_480272ef_atxl panels. * In uvesafb, fix the handling of the noblank option. * Fix panel orientation for Asus T101HA and Acer S1003. * Fix DMA configuration for sun4i if IOMMU is present. * Fix regression in VT restoration. Unbreaks userspace (i.e., Xorg) VT handling. Adam Ford (1): drm/panel-simple: fix connector type for LogicPD Type28 Display Bartlomiej Zolnierkiewicz (1): video: fbdev: uvesafb: fix "noblank" option handling Daniel Vetter (1): drm/fb-helper: Fix vt restore Hans de Goede (2): drm: panel-orientation-quirks: Add quirk for Asus T101HA panel drm: panel-orientation-quirks: Use generic orientation-data for Acer S1003 Linus Walleij (2): drm: mcde: Fix display initialization problem drm: mcde: Fix forgotten user of drm->dev_private Maxime Ripard (1): drm/sun4i: mixer: Call of_dma_configure if there's an IOMMU Thomas Zimmermann (1): Merge v5.8-rc1 into drm-misc-fixes Tomi Valkeinen (1): drm/panel-simple: fix connector type for newhaven_nhd_43_480272ef_atxl Xiyu Yang (2): drm/ttm: Fix dma_fence refcnt leak in ttm_bo_vm_fault_reserved drm/ttm: Fix dma_fence refcnt leak when adding move fence drivers/gpu/drm/drm_fb_helper.c| 63 -- drivers/gpu/drm/drm_panel_orientation_quirks.c | 14 +++--- drivers/gpu/drm/mcde/mcde_display.c| 2 +- drivers/gpu/drm/mcde/mcde_drv.c| 3 +- drivers/gpu/drm/panel/panel-simple.c | 2 + drivers/gpu/drm/sun4i/sun8i_mixer.c| 13 ++ drivers/gpu/drm/ttm/ttm_bo.c | 4 +- drivers/gpu/drm/ttm/ttm_bo_vm.c| 2 + drivers/video/fbdev/core/fbcon.c | 3 +- drivers/video/fbdev/uvesafb.c | 2 +- include/uapi/linux/fb.h| 1 + 11 files changed, 83 insertions(+), 26 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/8] Fix a bunch of W=1 warnings in Backlight
On Wed, 24 Jun 2020, Sam Ravnborg wrote: > Hi Lee. > > On Wed, Jun 24, 2020 at 04:43:21PM +0100, Lee Jones wrote: > > On Wed, 24 Jun 2020, Sam Ravnborg wrote: > > > > > Hi Lee. > > > > > > On Wed, Jun 24, 2020 at 03:57:13PM +0100, Lee Jones wrote: > > > > Attempting to clean-up W=1 kernel builds, which are currently > > > > overwhelmingly riddled with niggly little warnings. > > > > > > > > Lee Jones (8): > > > > backlight: lms501kf03: Remove unused const variables > > > > backlight: lcd: Add missing kerneldoc entry for 'struct device parent' > > > > > > > > > > backlight: ili922x: Add missing kerneldoc descriptions for > > > > CHECK_FREQ_REG() args > > > > backlight: ili922x: Remove invalid use of kerneldoc syntax > > > > backlight: ili922x: Add missing kerneldoc description for > > > > ili922x_reg_dump()'s arg > > > I wonder why these warnings show up as nothing pulls in this .c file. > > > Anyway I would suggest to drop using kerneldoc syntax for single drivers > > > like this - and the benefit here is low. > > > Now they are typed, otherwise this ahd been fine in a single patch. > > > > What do you mean by 'nothing pulls it in'? > There are no .rst files that includes any: > .. kernel-doc:: drivers/video/backlight/ili922x.c > > so I do not see how the kernel-doc comments will be used by any > of the generated kernel-docs. Looks like a common problem (if it is actually a problem): $ ./scripts/find-unused-docs.sh . | wc -l 1476 The role of this patch-set is not to eradicate unused kerneldoc headers, but to ensure they are formatted correctly. W=1 builds currently complain of ill formatted kerneldocs, which is currently littering the build-log and masking some more important issues (which I'm also trying to fix en route). > > > > backlight: backlight: Supply description for function args in existing > > > > Kerneldocs > > > > backlight: lm3630a_bl: Remove invalid checks for unsigned int < 0 > > > > backlight: qcom-wled: Remove unused configs for LED3 and LED4 > > > > > > The other fixes looks good. > > > They are all: > > > Acked-by: Sam Ravnborg > > > > Thanks (although this should be Reviewed-by). > > > > > > drivers/video/backlight/backlight.c | 2 ++ > > > > drivers/video/backlight/ili922x.c| 8 ++-- > > > > drivers/video/backlight/lcd.c| 1 + > > > > drivers/video/backlight/lm3630a_bl.c | 4 ++-- > > > > drivers/video/backlight/lms501kf03.c | 8 > > > > drivers/video/backlight/qcom-wled.c | 8 > > > > 6 files changed, 11 insertions(+), 20 deletions(-) > > > > > > -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 27/27] drm: Add default modes for connectors in unknown state
On Thu, Jun 25, 2020 at 9:56 AM Daniel Vetter wrote:
>
> On Wed, Jun 24, 2020 at 03:40:42PM -0400, Alex Deucher wrote:
> > On Wed, Jun 24, 2020 at 3:31 PM Daniel Vetter wrote:
> > >
> > > On Wed, Jun 24, 2020 at 5:24 PM Alex Deucher
> > > wrote:
> > > >
> > > > On Wed, Jun 24, 2020 at 3:23 AM Daniel Vetter wrote:
> > > > >
> > > > > On Wed, Jun 24, 2020 at 04:12:09AM +0300, Laurent Pinchart wrote:
> > > > > > Hi Sam,
> > > > > >
> > > > > > On Sun, Jun 21, 2020 at 10:40:00AM +0200, Sam Ravnborg wrote:
> > > > > > > On Tue, May 26, 2020 at 04:15:05AM +0300, Laurent Pinchart wrote:
> > > > > > > > The DRM CRTC helpers add default modes to connectors in the
> > > > > > > > connected
> > > > > > > > state if no mode can be retrieved from the connector. This
> > > > > > > > behaviour is
> > > > > > > > useful for VGA or DVI outputs that have no connected DDC bus.
> > > > > > > > However,
> > > > > > > > in such cases, the status of the output usually can't be
> > > > > > > > retrieved and
> > > > > > > > is reported as connector_status_unknown.
> > > > > > > >
> > > > > > > > Extend the addition of default modes to connectors in an
> > > > > > > > unknown state
> > > > > > > > to support outputs that can retrieve neither the modes nor the
> > > > > > > > connection status.
> > > > > > > >
> > > > > > > > Signed-off-by: Laurent Pinchart
> > > > > > > >
> > > > > > >
> > > > > > > From your description sounds like an OK approach.
> > > > > > > But this is not something I feel too familiar with.
> > > > > > > Acked-by: Sam Ravnborg
> > > > > >
> > > > > > Thanks for the ack. I'd like to have Daniel's (CC'ed) feedback on
> > > > > > this
> > > > > > too.
> > > > >
> > > > > Makes sense, and at least pre-coffee me can't immediately think of a
> > > > > scenario where we're going to regret this. _unknown status is pretty
> > > > > much
> > > > > limited to old VGA and similar things where load detect somehow isn't
> > > > > well
> > > > > supported by the hw.
> > > > >
> > > > > Reviewed-by: Daniel Vetter
> > > > >
> > > > > >
> > > > > > > > ---
> > > > > > > > drivers/gpu/drm/drm_probe_helper.c | 3 ++-
> > > > > > > > include/drm/drm_modeset_helper_vtables.h | 8 +++-
> > > > > > > > 2 files changed, 9 insertions(+), 2 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/drivers/gpu/drm/drm_probe_helper.c
> > > > > > > > b/drivers/gpu/drm/drm_probe_helper.c
> > > > > > > > index f5d141e0400f..9055d9573c90 100644
> > > > > > > > --- a/drivers/gpu/drm/drm_probe_helper.c
> > > > > > > > +++ b/drivers/gpu/drm/drm_probe_helper.c
> > > > > > > > @@ -491,7 +491,8 @@ int
> > > > > > > > drm_helper_probe_single_connector_modes(struct drm_connector
> > > > > > > > *connector,
> > > > > > > > if (count == 0 && connector->status ==
> > > > > > > > connector_status_connected)
> > > > > > > > count = drm_add_override_edid_modes(connector);
> > > > > > > >
> > > > > > > > - if (count == 0 && connector->status ==
> > > > > > > > connector_status_connected)
> > > > > > > > + if (count == 0 && (connector->status ==
> > > > > > > > connector_status_connected ||
> > > > > > > > +connector->status ==
> > > > > > > > connector_status_unknown))
> > > > > > > > count = drm_add_modes_noedid(connector, 1024, 768);
> > > > > > > > count += drm_helper_probe_add_cmdline_mode(connector);
> > > > > > > > if (count == 0)
> > > > > > > > diff --git a/include/drm/drm_modeset_helper_vtables.h
> > > > > > > > b/include/drm/drm_modeset_helper_vtables.h
> > > > > > > > index 421a30f08463..afe55e2e93d2 100644
> > > > > > > > --- a/include/drm/drm_modeset_helper_vtables.h
> > > > > > > > +++ b/include/drm/drm_modeset_helper_vtables.h
> > > > > > > > @@ -876,13 +876,19 @@ struct drm_connector_helper_funcs {
> > > > > > > >* The usual way to implement this is to cache the EDID
> > > > > > > > retrieved in the
> > > > > > > >* probe callback somewhere in the driver-private connector
> > > > > > > > structure.
> > > > > > > >* In this function drivers then parse the modes in the EDID
> > > > > > > > and add
> > > > > > > > - * them by calling drm_add_edid_modes(). But connectors that
> > > > > > > > driver a
> > > > > > > > + * them by calling drm_add_edid_modes(). But connectors that
> > > > > > > > drive a
> > > > > > > >* fixed panel can also manually add specific modes using
> > > > > > > >* drm_mode_probed_add(). Drivers which manually add modes
> > > > > > > > should also
> > > > > > > >* make sure that the &drm_connector.display_info,
> > > > > > > >* &drm_connector.width_mm and &drm_connector.height_mm
> > > > > > > > fields are
> > > > > > > >* filled in.
> > > > > > > >*
> > > > > > > > + * Note that the caller function will automatically add
> > > > > > > > standard VESA
> > > > > > > > + * DMT modes up to 1024x768 if the .get_modes() helper
> > > > > > > > operation returns
> > > > > > > > + * no mode and if th
Re: [PATCH 27/27] drm: Add default modes for connectors in unknown state
On Wed, Jun 24, 2020 at 03:40:42PM -0400, Alex Deucher wrote:
> On Wed, Jun 24, 2020 at 3:31 PM Daniel Vetter wrote:
> >
> > On Wed, Jun 24, 2020 at 5:24 PM Alex Deucher wrote:
> > >
> > > On Wed, Jun 24, 2020 at 3:23 AM Daniel Vetter wrote:
> > > >
> > > > On Wed, Jun 24, 2020 at 04:12:09AM +0300, Laurent Pinchart wrote:
> > > > > Hi Sam,
> > > > >
> > > > > On Sun, Jun 21, 2020 at 10:40:00AM +0200, Sam Ravnborg wrote:
> > > > > > On Tue, May 26, 2020 at 04:15:05AM +0300, Laurent Pinchart wrote:
> > > > > > > The DRM CRTC helpers add default modes to connectors in the
> > > > > > > connected
> > > > > > > state if no mode can be retrieved from the connector. This
> > > > > > > behaviour is
> > > > > > > useful for VGA or DVI outputs that have no connected DDC bus.
> > > > > > > However,
> > > > > > > in such cases, the status of the output usually can't be
> > > > > > > retrieved and
> > > > > > > is reported as connector_status_unknown.
> > > > > > >
> > > > > > > Extend the addition of default modes to connectors in an unknown
> > > > > > > state
> > > > > > > to support outputs that can retrieve neither the modes nor the
> > > > > > > connection status.
> > > > > > >
> > > > > > > Signed-off-by: Laurent Pinchart
> > > > > > >
> > > > > >
> > > > > > From your description sounds like an OK approach.
> > > > > > But this is not something I feel too familiar with.
> > > > > > Acked-by: Sam Ravnborg
> > > > >
> > > > > Thanks for the ack. I'd like to have Daniel's (CC'ed) feedback on this
> > > > > too.
> > > >
> > > > Makes sense, and at least pre-coffee me can't immediately think of a
> > > > scenario where we're going to regret this. _unknown status is pretty
> > > > much
> > > > limited to old VGA and similar things where load detect somehow isn't
> > > > well
> > > > supported by the hw.
> > > >
> > > > Reviewed-by: Daniel Vetter
> > > >
> > > > >
> > > > > > > ---
> > > > > > > drivers/gpu/drm/drm_probe_helper.c | 3 ++-
> > > > > > > include/drm/drm_modeset_helper_vtables.h | 8 +++-
> > > > > > > 2 files changed, 9 insertions(+), 2 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/gpu/drm/drm_probe_helper.c
> > > > > > > b/drivers/gpu/drm/drm_probe_helper.c
> > > > > > > index f5d141e0400f..9055d9573c90 100644
> > > > > > > --- a/drivers/gpu/drm/drm_probe_helper.c
> > > > > > > +++ b/drivers/gpu/drm/drm_probe_helper.c
> > > > > > > @@ -491,7 +491,8 @@ int
> > > > > > > drm_helper_probe_single_connector_modes(struct drm_connector
> > > > > > > *connector,
> > > > > > > if (count == 0 && connector->status ==
> > > > > > > connector_status_connected)
> > > > > > > count = drm_add_override_edid_modes(connector);
> > > > > > >
> > > > > > > - if (count == 0 && connector->status ==
> > > > > > > connector_status_connected)
> > > > > > > + if (count == 0 && (connector->status ==
> > > > > > > connector_status_connected ||
> > > > > > > +connector->status ==
> > > > > > > connector_status_unknown))
> > > > > > > count = drm_add_modes_noedid(connector, 1024, 768);
> > > > > > > count += drm_helper_probe_add_cmdline_mode(connector);
> > > > > > > if (count == 0)
> > > > > > > diff --git a/include/drm/drm_modeset_helper_vtables.h
> > > > > > > b/include/drm/drm_modeset_helper_vtables.h
> > > > > > > index 421a30f08463..afe55e2e93d2 100644
> > > > > > > --- a/include/drm/drm_modeset_helper_vtables.h
> > > > > > > +++ b/include/drm/drm_modeset_helper_vtables.h
> > > > > > > @@ -876,13 +876,19 @@ struct drm_connector_helper_funcs {
> > > > > > >* The usual way to implement this is to cache the EDID
> > > > > > > retrieved in the
> > > > > > >* probe callback somewhere in the driver-private connector
> > > > > > > structure.
> > > > > > >* In this function drivers then parse the modes in the EDID
> > > > > > > and add
> > > > > > > - * them by calling drm_add_edid_modes(). But connectors that
> > > > > > > driver a
> > > > > > > + * them by calling drm_add_edid_modes(). But connectors that
> > > > > > > drive a
> > > > > > >* fixed panel can also manually add specific modes using
> > > > > > >* drm_mode_probed_add(). Drivers which manually add modes
> > > > > > > should also
> > > > > > >* make sure that the &drm_connector.display_info,
> > > > > > >* &drm_connector.width_mm and &drm_connector.height_mm fields
> > > > > > > are
> > > > > > >* filled in.
> > > > > > >*
> > > > > > > + * Note that the caller function will automatically add
> > > > > > > standard VESA
> > > > > > > + * DMT modes up to 1024x768 if the .get_modes() helper
> > > > > > > operation returns
> > > > > > > + * no mode and if the connector status is
> > > > > > > connector_status_connected or
> > > > > > > + * connector_status_unknown. There is no need to call
> > > > > > > + * drm_add_edid_modes() manually in that case.
> > > >
> > > > Hm calling drm_add_edid_modes if you have no edid is a bit a fun
Re: [PATCH] drm/bridge: dw-mipi-dsi.c: remove unused header file
On Wed, Jun 24, 2020 at 03:08:22PM +, Yannick FERTRE wrote: > Hello Angelo, > thank for patch. > > Reviewed-by: Yannick Fertre Patch applied, thanks. -Daniel > > > > On 4/3/20 3:30 PM, Angelo Ribeiro wrote: > > dw-mipi-dsi does not use any definition from drm_probe_helper. > > > > Coverity output: > > Event unnecessary_header: > > Including .../include/drm/drm_probe_helper.h does not provide any > > needed symbols. > > > > Cc: Gustavo Pimentel > > Cc: Joao Pinto > > Cc: Jose Abreu > > Signed-off-by: Angelo Ribeiro > > --- > > drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c > > b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c > > index 024acad..582635d 100644 > > --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c > > +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c > > @@ -27,7 +27,6 @@ > > #include > > #include > > #include > > -#include > > > > #define HWVER_131 0x31333100 /* IP version 1.31 */ > > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Host1x/TegraDRM UAPI
23.06.2020 15:09, Mikko Perttunen пишет:
> struct drm_tegra_channel_submit {
> __u32 channel_id;
> __u32 flags;
>
> /**
> * [in] Timeout in microseconds after which the kernel may
> * consider the job to have hung and may reap it and
> * fast-forward its syncpoint increments.
> *
> * The value may be capped by the kernel.
> */
> __u32 timeout;
>
> __u32 num_syncpt_incrs;
> __u32 num_relocations;
> __u32 num_commands;
>
> __u64 syncpt_incrs;
> __u64 relocations;
> __u64 commands;
Do we really need to retain the multi-gather support? The code-bloat
(both userspace and kernel driver) is very significant just for
preparing and patching of the multi-buffer cmdstreams.
If userspace runs out of a free space within the pushbuffer, then it
should simply reallocate a larger pushbuffer.
I'm suggesting that we should have a single gather per-job, any objections?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/8] drm/qxl: don't use ttm bo->offset
This patch removes slot->gpu_offset which is not required as
VRAM and PRIV slot are in separate PCI bar.
This patch also removes unused qxl_bo_gpu_offset()
Signed-off-by: Nirmoy Das
Acked-by: Christian König
Acked-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_drv.h| 6 ++
drivers/gpu/drm/qxl/qxl_kms.c| 5 ++---
drivers/gpu/drm/qxl/qxl_object.h | 5 -
drivers/gpu/drm/qxl/qxl_ttm.c| 9 -
4 files changed, 4 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
index 31e35f787df2..9691449aefdb 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.h
+++ b/drivers/gpu/drm/qxl/qxl_drv.h
@@ -134,7 +134,6 @@ struct qxl_memslot {
uint64_tstart_phys_addr;
uint64_tsize;
uint64_thigh_bits;
- uint64_tgpu_offset;
};
enum {
@@ -307,10 +306,9 @@ qxl_bo_physical_address(struct qxl_device *qdev, struct
qxl_bo *bo,
(bo->tbo.mem.mem_type == TTM_PL_VRAM)
? &qdev->main_slot : &qdev->surfaces_slot;
- WARN_ON_ONCE((bo->tbo.offset & slot->gpu_offset) != slot->gpu_offset);
+ /* TODO - need to hold one of the locks to read bo->tbo.mem.start */
- /* TODO - need to hold one of the locks to read tbo.offset */
- return slot->high_bits | (bo->tbo.offset - slot->gpu_offset + offset);
+ return slot->high_bits | ((bo->tbo.mem.start << PAGE_SHIFT) + offset);
}
/* qxl_display.c */
diff --git a/drivers/gpu/drm/qxl/qxl_kms.c b/drivers/gpu/drm/qxl/qxl_kms.c
index a6d873052cd4..dc5b3850a4d4 100644
--- a/drivers/gpu/drm/qxl/qxl_kms.c
+++ b/drivers/gpu/drm/qxl/qxl_kms.c
@@ -87,11 +87,10 @@ static void setup_slot(struct qxl_device *qdev,
high_bits <<= (64 - (qdev->rom->slot_gen_bits +
qdev->rom->slot_id_bits));
slot->high_bits = high_bits;
- DRM_INFO("slot %d (%s): base 0x%08lx, size 0x%08lx, gpu_offset 0x%lx\n",
+ DRM_INFO("slot %d (%s): base 0x%08lx, size 0x%08lx\n",
slot->index, slot->name,
(unsigned long)slot->start_phys_addr,
-(unsigned long)slot->size,
-(unsigned long)slot->gpu_offset);
+(unsigned long)slot->size);
}
void qxl_reinit_memslots(struct qxl_device *qdev)
diff --git a/drivers/gpu/drm/qxl/qxl_object.h b/drivers/gpu/drm/qxl/qxl_object.h
index 8ae54ba7857c..21fa81048f4f 100644
--- a/drivers/gpu/drm/qxl/qxl_object.h
+++ b/drivers/gpu/drm/qxl/qxl_object.h
@@ -48,11 +48,6 @@ static inline void qxl_bo_unreserve(struct qxl_bo *bo)
ttm_bo_unreserve(&bo->tbo);
}
-static inline u64 qxl_bo_gpu_offset(struct qxl_bo *bo)
-{
- return bo->tbo.offset;
-}
-
static inline unsigned long qxl_bo_size(struct qxl_bo *bo)
{
return bo->tbo.num_pages << PAGE_SHIFT;
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index f09a712b1ed2..52eaa2d22745 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -51,11 +51,6 @@ static struct qxl_device *qxl_get_qdev(struct ttm_bo_device
*bdev)
static int qxl_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
struct ttm_mem_type_manager *man)
{
- struct qxl_device *qdev = qxl_get_qdev(bdev);
- unsigned int gpu_offset_shift =
- 64 - (qdev->rom->slot_gen_bits + qdev->rom->slot_id_bits + 8);
- struct qxl_memslot *slot;
-
switch (type) {
case TTM_PL_SYSTEM:
/* System memory */
@@ -66,11 +61,7 @@ static int qxl_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
case TTM_PL_VRAM:
case TTM_PL_PRIV:
/* "On-card" video ram */
- slot = (type == TTM_PL_VRAM) ?
- &qdev->main_slot : &qdev->surfaces_slot;
- slot->gpu_offset = (uint64_t)type << gpu_offset_shift;
man->func = &ttm_bo_manager_func;
- man->gpu_offset = slot->gpu_offset;
man->flags = TTM_MEMTYPE_FLAG_FIXED |
TTM_MEMTYPE_FLAG_MAPPABLE;
man->available_caching = TTM_PL_MASK_CACHING;
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/8] drm/vram-helper: don't use ttm bo->offset v4
Calculate GEM VRAM bo's offset within vram-helper without depending on
bo->offset.
Signed-off-by: Nirmoy Das
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem_vram_helper.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 0023ce1d2cf7..ad096600d89f 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -281,6 +281,15 @@ u64 drm_gem_vram_mmap_offset(struct drm_gem_vram_object
*gbo)
}
EXPORT_SYMBOL(drm_gem_vram_mmap_offset);
+static u64 drm_gem_vram_pg_offset(struct drm_gem_vram_object *gbo)
+{
+ /* Keep TTM behavior for now, remove when drivers are audited */
+ if (WARN_ON_ONCE(!gbo->bo.mem.mm_node))
+ return 0;
+
+ return gbo->bo.mem.start;
+}
+
/**
* drm_gem_vram_offset() - \
Returns a GEM VRAM object's offset in video memory
@@ -297,7 +306,7 @@ s64 drm_gem_vram_offset(struct drm_gem_vram_object *gbo)
{
if (WARN_ON_ONCE(!gbo->pin_count))
return (s64)-ENODEV;
- return gbo->bo.offset;
+ return drm_gem_vram_pg_offset(gbo) << PAGE_SHIFT;
}
EXPORT_SYMBOL(drm_gem_vram_offset);
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/8] drm/radeon: don't use ttm bo->offset
Calculate GPU offset in radeon_bo_gpu_offset without depending on
bo->offset.
Signed-off-by: Nirmoy Das
Reviewed-and-tested-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h| 1 +
drivers/gpu/drm/radeon/radeon_object.h | 16 +++-
drivers/gpu/drm/radeon/radeon_ttm.c| 4 +---
3 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 30e32adc1fc6..b7c3fb2bfb54 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -2828,6 +2828,7 @@ extern void radeon_ttm_set_active_vram_size(struct
radeon_device *rdev, u64 size
extern void radeon_program_register_sequence(struct radeon_device *rdev,
const u32 *registers,
const u32 array_size);
+struct radeon_device *radeon_get_rdev(struct ttm_bo_device *bdev);
/*
* vm
diff --git a/drivers/gpu/drm/radeon/radeon_object.h
b/drivers/gpu/drm/radeon/radeon_object.h
index d23f2ed4126e..60275b822f79 100644
--- a/drivers/gpu/drm/radeon/radeon_object.h
+++ b/drivers/gpu/drm/radeon/radeon_object.h
@@ -90,7 +90,21 @@ static inline void radeon_bo_unreserve(struct radeon_bo *bo)
*/
static inline u64 radeon_bo_gpu_offset(struct radeon_bo *bo)
{
- return bo->tbo.offset;
+ struct radeon_device *rdev;
+ u64 start = 0;
+
+ rdev = radeon_get_rdev(bo->tbo.bdev);
+
+ switch (bo->tbo.mem.mem_type) {
+ case TTM_PL_TT:
+ start = rdev->mc.gtt_start;
+ break;
+ case TTM_PL_VRAM:
+ start = rdev->mc.vram_start;
+ break;
+ }
+
+ return (bo->tbo.mem.start << PAGE_SHIFT) + start;
}
static inline unsigned long radeon_bo_size(struct radeon_bo *bo)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 5d50c9edbe80..357e8e98cca9 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -56,7 +56,7 @@
static int radeon_ttm_debugfs_init(struct radeon_device *rdev);
static void radeon_ttm_debugfs_fini(struct radeon_device *rdev);
-static struct radeon_device *radeon_get_rdev(struct ttm_bo_device *bdev)
+struct radeon_device *radeon_get_rdev(struct ttm_bo_device *bdev)
{
struct radeon_mman *mman;
struct radeon_device *rdev;
@@ -82,7 +82,6 @@ static int radeon_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
break;
case TTM_PL_TT:
man->func = &ttm_bo_manager_func;
- man->gpu_offset = rdev->mc.gtt_start;
man->available_caching = TTM_PL_MASK_CACHING;
man->default_caching = TTM_PL_FLAG_CACHED;
man->flags = TTM_MEMTYPE_FLAG_MAPPABLE | TTM_MEMTYPE_FLAG_CMA;
@@ -104,7 +103,6 @@ static int radeon_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
case TTM_PL_VRAM:
/* "On-card" video ram */
man->func = &ttm_bo_manager_func;
- man->gpu_offset = rdev->mc.vram_start;
man->flags = TTM_MEMTYPE_FLAG_FIXED |
TTM_MEMTYPE_FLAG_MAPPABLE;
man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Host1x/TegraDRM UAPI
23.06.2020 15:09, Mikko Perttunen пишет: > #define DRM_TEGRA_SUBMIT_CREATE_POST_SYNC_FILE (1<<0) > #define DRM_TEGRA_SUBMIT_CREATE_POST_SYNCOBJ (1<<1) The sync object shouldn't be created by the kernel driver and we shouldn't need the sync-file FD. Please consider this example of how syncobj may be used: 1. Syncobj is created by userspace. 2. Syncobj's handle (post_fence) is passed with the job to the kernel driver. 3. Userspace waits on syncobj for the job's submission. 4. Kernel driver attaches job-completion dma-fence(s) to the syncobj after starting to execute the job. 5. Userspace waits on syncobj for the job's completion. Syncobj is a superset of the sync-file fence: a) Syncobj doesn't have a backing file descriptor when it's created. For example, why would you need an FD if you're not going to share fence with other processes. It's possible to get FD out of syncobj later on, please see [1][2]. b) Syncobj is designed to be used with a GPU jobs. For example, userspace passes job to the GPU driver's scheduler and then waits until job has been started to execute on hardware, this is already supported by syncobj. c) It is possible to attach sync-file's fence to a syncobj [1][2][3] and now: - Userspace may attach sync-file's fence to a syncobj. - Userspace may use this syncobj for the job's pre-fence. - Kernel driver will take out the pre-fence from the syncobj during of the job's submission and reset the syncobj's fence to NULL. - Job's scheduler will wait on this pre-fence before starting to execute job. - Once the job is started to execute, the job's scheduler will attach the job's completion-fence to the syncobj. Now syncobj has a post-fence! d) It is possible to get sync-file FD out of syncobj [1][2][4]. [1] https://elixir.bootlin.com/linux/v5.7.2/source/include/uapi/drm/drm.h#L730 [2] https://elixir.bootlin.com/linux/v5.7.2/source/include/uapi/drm/drm.h#L933 [3] https://elixir.bootlin.com/linux/v5.7.2/source/drivers/gpu/drm/drm_syncobj.c#L653 [4] https://elixir.bootlin.com/linux/v5.7.2/source/drivers/gpu/drm/drm_syncobj.c#L674 === So, sync object can carry both pre-fence and post-fence, and they could be sync-file FDs! The corollary is that we can get away by using a single syncobj handle for the job's submission IOCTL. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/8] drm/vmwgfx: don't use ttm bo->offset
Calculate GPU offset within vmwgfx driver itself without depending on
bo->offset.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 4 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c| 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 --
4 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
index 8b71bf6b58ef..1e59c019affa 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
@@ -258,7 +258,7 @@ int vmw_bo_pin_in_start_of_vram(struct vmw_private
*dev_priv,
ret = ttm_bo_validate(bo, &placement, &ctx);
/* For some reason we didn't end up at the start of vram */
- WARN_ON(ret == 0 && bo->offset != 0);
+ WARN_ON(ret == 0 && bo->mem.start != 0);
if (!ret)
vmw_bo_pin_reserved(buf, true);
@@ -317,7 +317,7 @@ void vmw_bo_get_guest_ptr(const struct ttm_buffer_object
*bo,
{
if (bo->mem.mem_type == TTM_PL_VRAM) {
ptr->gmrId = SVGA_GMR_FRAMEBUFFER;
- ptr->offset = bo->offset;
+ ptr->offset = bo->mem.start << PAGE_SHIFT;
} else {
ptr->gmrId = bo->mem.start;
ptr->offset = 0;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index 367d5b87ee6a..4284c4bd444d 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -3696,7 +3696,7 @@ static void vmw_apply_relocations(struct vmw_sw_context
*sw_context)
bo = &reloc->vbo->base;
switch (bo->mem.mem_type) {
case TTM_PL_VRAM:
- reloc->location->offset += bo->offset;
+ reloc->location->offset += bo->mem.start << PAGE_SHIFT;
reloc->location->gmrId = SVGA_GMR_FRAMEBUFFER;
break;
case VMW_PL_GMR:
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
index 6941689085ed..a95156fc5db7 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
@@ -610,7 +610,7 @@ static int vmw_fifo_emit_dummy_legacy_query(struct
vmw_private *dev_priv,
if (bo->mem.mem_type == TTM_PL_VRAM) {
cmd->body.guestResult.gmrId = SVGA_GMR_FRAMEBUFFER;
- cmd->body.guestResult.offset = bo->offset;
+ cmd->body.guestResult.offset = bo->mem.start << PAGE_SHIFT;
} else {
cmd->body.guestResult.gmrId = bo->mem.start;
cmd->body.guestResult.offset = 0;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
index bf0bc4697959..fbcd11a7b215 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
@@ -750,7 +750,6 @@ static int vmw_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
case TTM_PL_VRAM:
/* "On-card" video ram */
man->func = &vmw_thp_func;
- man->gpu_offset = 0;
man->flags = TTM_MEMTYPE_FLAG_FIXED | TTM_MEMTYPE_FLAG_MAPPABLE;
man->available_caching = TTM_PL_FLAG_CACHED;
man->default_caching = TTM_PL_FLAG_CACHED;
@@ -763,7 +762,6 @@ static int vmw_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
* slots as well as the bo size.
*/
man->func = &vmw_gmrid_manager_func;
- man->gpu_offset = 0;
man->flags = TTM_MEMTYPE_FLAG_CMA | TTM_MEMTYPE_FLAG_MAPPABLE;
man->available_caching = TTM_PL_FLAG_CACHED;
man->default_caching = TTM_PL_FLAG_CACHED;
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/8] drm/vc4: Use __drm_atomic_helper_crtc_reset
On Fri, Jun 12, 2020 at 06:00:53PM +0200, Daniel Vetter wrote: > Now also comes with the added benefit of doing a drm_crtc_vblank_off(), > which means vblank state isn't ill-defined and fail-y at driver load > before the first modeset on each crtc. > > Signed-off-by: Daniel Vetter > Cc: Eric Anholt Reviewed-by: Maxime Ripard Maxime ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 7/8] drm/bochs: use drm_gem_vram_offset to get bo offset v2
Switch over to GEM VRAM's implementation to retrieve bo->offset.
Signed-off-by: Nirmoy Das
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/bochs/bochs_kms.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
b/drivers/gpu/drm/bochs/bochs_kms.c
index 05d8373888e8..853081d186d5 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -29,16 +29,21 @@ static void bochs_plane_update(struct bochs_device *bochs,
struct drm_plane_state *state)
{
struct drm_gem_vram_object *gbo;
+ s64 gpu_addr;
if (!state->fb || !bochs->stride)
return;
gbo = drm_gem_vram_of_gem(state->fb->obj[0]);
+ gpu_addr = drm_gem_vram_offset(gbo);
+ if (WARN_ON_ONCE(gpu_addr < 0))
+ return; /* Bug: we didn't pin the BO to VRAM in prepare_fb. */
+
bochs_hw_setbase(bochs,
state->crtc_x,
state->crtc_y,
state->fb->pitches[0],
-state->fb->offsets[0] + gbo->bo.offset);
+state->fb->offsets[0] + gpu_addr);
bochs_hw_setformat(bochs, state->fb->format);
}
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 8/8] drm/ttm: do not keep GPU dependent addresses
GPU address handling is device specific and should be handle by its device
driver.
Signed-off-by: Nirmoy Das
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c| 7 ---
include/drm/ttm/ttm_bo_api.h| 2 --
include/drm/ttm/ttm_bo_driver.h | 1 -
3 files changed, 10 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index f73b81c2576e..f78cfc76ad78 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -85,7 +85,6 @@ static void ttm_mem_type_debug(struct ttm_bo_device *bdev,
struct drm_printer *p
drm_printf(p, "has_type: %d\n", man->has_type);
drm_printf(p, "use_type: %d\n", man->use_type);
drm_printf(p, "flags: 0x%08X\n", man->flags);
- drm_printf(p, "gpu_offset: 0x%08llX\n", man->gpu_offset);
drm_printf(p, "size: %llu\n", man->size);
drm_printf(p, "available_caching: 0x%08X\n",
man->available_caching);
drm_printf(p, "default_caching: 0x%08X\n", man->default_caching);
@@ -343,12 +342,6 @@ static int ttm_bo_handle_move_mem(struct ttm_buffer_object
*bo,
moved:
bo->evicted = false;
- if (bo->mem.mm_node)
- bo->offset = (bo->mem.start << PAGE_SHIFT) +
- bdev->man[bo->mem.mem_type].gpu_offset;
- else
- bo->offset = 0;
-
ctx->bytes_moved += bo->num_pages << PAGE_SHIFT;
return 0;
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 0a9d042e075a..a6ec6101d9ec 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -213,8 +213,6 @@ struct ttm_buffer_object {
* either of these locks held.
*/
- uint64_t offset; /* GPU address space is independent of CPU word size */
-
struct sg_table *sg;
};
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 54a527aa79cc..aa1f398c2ea7 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -177,7 +177,6 @@ struct ttm_mem_type_manager {
bool has_type;
bool use_type;
uint32_t flags;
- uint64_t gpu_offset; /* GPU address space is independent of CPU word
size */
uint64_t size;
uint32_t available_caching;
uint32_t default_caching;
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm/dpu: add support for dither block in display
This change enables dither block for primary interface
in display.
Enabled for 6bpc in the current version.
Signed-off-by: Kalyan Thota
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 45 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 66 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h | 28 +++
3 files changed, 130 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 63976dc..26e870a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -208,6 +208,42 @@ struct dpu_encoder_virt {
#define to_dpu_encoder_virt(x) container_of(x, struct dpu_encoder_virt, base)
+static u32 dither_matrix[DITHER_MATRIX_SZ] = {
+ 15, 7, 13, 5, 3, 11, 1, 9, 12, 4, 14, 6, 0, 8, 2, 10
+};
+
+static void _dpu_encoder_setup_dither(struct dpu_encoder_phys *phys)
+{
+ struct dpu_hw_dither_cfg dither_cfg = { 0 };
+ struct drm_display_info *info;
+
+ if (!phys || !phys->connector || !phys->hw_pp ||
+ !phys->hw_pp->ops.setup_dither)
+ return;
+
+ info = &phys->connector->display_info;
+ if (!info)
+ return;
+
+ switch (phys->connector->display_info.bpc) {
+ case 6:
+ dither_cfg.c0_bitdepth = 6;
+ dither_cfg.c1_bitdepth = 6;
+ dither_cfg.c2_bitdepth = 6;
+ dither_cfg.c3_bitdepth = 6;
+ dither_cfg.temporal_en = 0;
+ break;
+ default:
+ phys->hw_pp->ops.setup_dither(phys->hw_pp, NULL);
+ return;
+ }
+
+ memcpy(&dither_cfg.matrix, dither_matrix,
+ sizeof(u32) * DITHER_MATRIX_SZ);
+
+ phys->hw_pp->ops.setup_dither(phys->hw_pp, &dither_cfg);
+}
+
void dpu_encoder_helper_report_irq_timeout(struct dpu_encoder_phys *phys_enc,
enum dpu_intr_idx intr_idx)
{
@@ -1082,6 +1118,7 @@ static void _dpu_encoder_virt_enable_helper(struct
drm_encoder *drm_enc)
struct dpu_encoder_virt *dpu_enc = NULL;
struct msm_drm_private *priv;
struct dpu_kms *dpu_kms;
+ int i;
if (!drm_enc || !drm_enc->dev) {
DPU_ERROR("invalid parameters\n");
@@ -1104,6 +1141,14 @@ static void _dpu_encoder_virt_enable_helper(struct
drm_encoder *drm_enc)
dpu_kms->catalog);
_dpu_encoder_update_vsync_source(dpu_enc, &dpu_enc->disp_info);
+
+ if (dpu_enc->disp_info.intf_type == DRM_MODE_ENCODER_DSI) {
+ for (i = 0; i < dpu_enc->num_phys_encs; i++) {
+ struct dpu_encoder_phys *phys = dpu_enc->phys_encs[i];
+
+ _dpu_encoder_setup_dither(phys);
+ }
+ }
}
void dpu_encoder_virt_runtime_resume(struct drm_encoder *drm_enc)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
index d110a40..cf7603d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
@@ -28,6 +28,16 @@
#define PP_FBC_BUDGET_CTL 0x038
#define PP_FBC_LOSSY_MODE 0x03C
+#define PP_DITHER_EN 0x000
+#define PP_DITHER_BITDEPTH 0x004
+#define PP_DITHER_MATRIX 0x008
+
+#define DITHER_DEPTH_MAP_INDEX 9
+
+static u32 dither_depth_map[DITHER_DEPTH_MAP_INDEX] = {
+ 0, 0, 0, 0, 0, 0, 0, 1, 2
+};
+
static const struct dpu_pingpong_cfg *_pingpong_offset(enum dpu_pingpong pp,
const struct dpu_mdss_cfg *m,
void __iomem *addr,
@@ -49,6 +59,40 @@ static const struct dpu_pingpong_cfg *_pingpong_offset(enum
dpu_pingpong pp,
return ERR_PTR(-EINVAL);
}
+static void dpu_hw_pp_setup_dither(struct dpu_hw_pingpong *pp,
+ struct dpu_hw_dither_cfg *cfg)
+{
+ struct dpu_hw_blk_reg_map *c;
+ u32 i, base, data = 0;
+
+ if (!pp)
+ return;
+
+ c = &pp->hw;
+ base = pp->caps->sblk->dither.base;
+ if (!cfg) {
+ DPU_REG_WRITE(c, base + PP_DITHER_EN, 0);
+ return;
+ }
+
+ data = dither_depth_map[cfg->c0_bitdepth] & REG_MASK(2);
+ data |= (dither_depth_map[cfg->c1_bitdepth] & REG_MASK(2)) << 2;
+ data |= (dither_depth_map[cfg->c2_bitdepth] & REG_MASK(2)) << 4;
+ data |= (dither_depth_map[cfg->c3_bitdepth] & REG_MASK(2)) << 6;
+ data |= (cfg->temporal_en) ? (1 << 8) : 0;
+
+ DPU_REG_WRITE(c, base + PP_DITHER_BITDEPTH, data);
+
+ for (i = 0; i < DITHER_MATRIX_SZ - 3; i += 4) {
+ data = (cfg->matrix[i] & REG_MASK(4)) |
+ ((cfg->matrix[i + 1] & REG_MASK(4)) << 4) |
+ ((cfg->matrix[i + 2] & REG_MASK(4)) << 8) |
+ ((cfg->matrix[i + 3] & REG_MASK(
Re: [PATCH 1/8] drm/atomic-helper: reset vblank on crtc reset
On Fri, Jun 12, 2020 at 06:00:49PM +0200, Daniel Vetter wrote: > Only when vblanks are supported ofc. > > Some drivers do this already, but most unfortunately missed it. This > opens up bugs after driver load, before the crtc is enabled for the > first time. syzbot spotted this when loading vkms as a secondary > output. Given how many drivers are buggy it's best to solve this once > and for all in shared helper code. > > Aside from moving the few existing calls to drm_crtc_vblank_reset into > helpers (i915 doesn't use helpers, so keeps its own) I think the > regression risk is minimal: atomic helpers already rely on drivers > calling drm_crtc_vblank_on/off correctly in their hooks when they > support vblanks. And driver that's failing to handle vblanks after > this is missing those calls already, and vblanks could only work by > accident when enabling a CRTC for the first time right after boot. > > Big thanks to Tetsuo for helping track down what's going wrong here. > > There's only a few drivers which already had the necessary call and > needed some updating: > - komeda, atmel and tidss also needed to be changed to call > __drm_atomic_helper_crtc_reset() intead of open coding it > - tegra and msm even had it in the same place already, just code > motion, and malidp already uses __drm_atomic_helper_crtc_reset(). > > Only call left is in i915, which doesn't use drm_mode_config_reset, > but has its own fastboot infrastructure. So that's the only case where > we actually want this in the driver still. > > I've also reviewed all other drivers which set up vblank support with > drm_vblank_init. After the previous patch fixing mxsfb all atomic > drivers do call drm_crtc_vblank_on/off as they should, the remaining > drivers are either legacy kms or legacy dri1 drivers, so not affected > by this change to atomic helpers. > > v2: Use the drm_dev_has_vblank() helper. > > v3: Laurent pointed out that omap and rcar-du used drm_crtc_vblank_off > instead of drm_crtc_vblank_reset. Adjust them too. > > v4: Laurent noticed that rcar-du and omap open-code their crtc reset > and hence would actually be broken by this patch now. So fix them up > by reusing the helpers, which brings the drm_crtc_vblank_reset() back. > > Cc: Laurent Pinchart > Reviewed-by: Boris Brezillon > Acked-by: Liviu Dudau > Acked-by: Thierry Reding > Link: > https://syzkaller.appspot.com/bug?id=0ba17d70d062b2595e1f061231474800f076c7cb > Reported-by: Tetsuo Handa > Reported-by: syzbot+0871b14ca2e2fb64f...@syzkaller.appspotmail.com > Cc: Tetsuo Handa > Cc: "James (Qian) Wang" > Cc: Liviu Dudau > Cc: Mihail Atanassov > Cc: Brian Starkey > Cc: Sam Ravnborg > Cc: Boris Brezillon > Cc: Nicolas Ferre > Cc: Alexandre Belloni > Cc: Ludovic Desroches > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: Thomas Zimmermann > Cc: David Airlie > Cc: Daniel Vetter > Cc: Thierry Reding > Cc: Jonathan Hunter > Cc: Jyri Sarha > Cc: Tomi Valkeinen > Cc: Rob Clark > Cc: Sean Paul > Cc: Brian Masney > Cc: Emil Velikov > Cc: zhengbin > Cc: Thomas Gleixner > Cc: linux-te...@vger.kernel.org > Cc: Kieran Bingham > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-renesas-...@vger.kernel.org > Signed-off-by: Daniel Vetter Acked-by: Maxime Ripard Maxime ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Host1x/TegraDRM UAPI
23.06.2020 15:09, Mikko Perttunen пишет: > /* Command is an opcode gather from a GEM handle */ > #define DRM_TEGRA_SUBMIT_COMMAND_GATHER 0 > /* Command is an opcode gather from a user pointer */ > #define DRM_TEGRA_SUBMIT_COMMAND_GATHER_UPTR 1 I'm a bit dubious about whether we really need to retain the non-UPTR variant. The memory-copying overhead is negligible because cmdstream's data usually is hot in CPU's cache IIRC, the most (if not all) of the modern DRM drivers drivers use the usrptr-only for the cmdstream. At least there is no any real-world userspace example today that could benefit from a non-UPTR variant. I'm suggesting to leave out the non-UPTR gather variant for now, keeping it in mind as a potential future extension of the submission UAPI. Any objections? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/8] drm/nouveau: don't use ttm bo->offset v3
Store ttm bo->offset in struct nouveau_bo instead.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 6 +++---
drivers/gpu/drm/nouveau/dispnv04/disp.c | 3 ++-
drivers/gpu/drm/nouveau/dispnv04/overlay.c | 6 +++---
drivers/gpu/drm/nouveau/dispnv50/base507c.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/core507d.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/ovly507e.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/wndwc37e.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_abi16.c | 8
drivers/gpu/drm/nouveau/nouveau_bo.c| 8
drivers/gpu/drm/nouveau/nouveau_bo.h| 3 +++
drivers/gpu/drm/nouveau/nouveau_chan.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_gem.c | 10 +-
15 files changed, 36 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
index 27f511b9987b..cc6ab3c2eec7 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
@@ -845,7 +845,7 @@ nv04_crtc_do_mode_set_base(struct drm_crtc *crtc,
fb = nouveau_framebuffer(crtc->primary->fb);
}
- nv_crtc->fb.offset = fb->nvbo->bo.offset;
+ nv_crtc->fb.offset = fb->nvbo->offset;
if (nv_crtc->lut.depth != drm_fb->format->depth) {
nv_crtc->lut.depth = drm_fb->format->depth;
@@ -1013,7 +1013,7 @@ nv04_crtc_cursor_set(struct drm_crtc *crtc, struct
drm_file *file_priv,
nv04_cursor_upload(dev, cursor, nv_crtc->cursor.nvbo);
nouveau_bo_unmap(cursor);
- nv_crtc->cursor.offset = nv_crtc->cursor.nvbo->bo.offset;
+ nv_crtc->cursor.offset = nv_crtc->cursor.nvbo->offset;
nv_crtc->cursor.set_offset(nv_crtc, nv_crtc->cursor.offset);
nv_crtc->cursor.show(nv_crtc, true);
out:
@@ -1191,7 +1191,7 @@ nv04_crtc_page_flip(struct drm_crtc *crtc, struct
drm_framebuffer *fb,
/* Initialize a page flip struct */
*s = (struct nv04_page_flip_state)
{ { }, event, crtc, fb->format->cpp[0] * 8, fb->pitches[0],
- new_bo->bo.offset };
+ new_bo->offset };
/* Keep vblanks on during flip, for the target crtc of this flip */
drm_crtc_vblank_get(crtc);
diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c
b/drivers/gpu/drm/nouveau/dispnv04/disp.c
index 44ee82d0c9b6..9272135998aa 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
@@ -151,7 +151,8 @@ nv04_display_init(struct drm_device *dev, bool resume, bool
runtime)
continue;
if (nv_crtc->cursor.set_offset)
- nv_crtc->cursor.set_offset(nv_crtc,
nv_crtc->cursor.nvbo->bo.offset);
+ nv_crtc->cursor.set_offset(nv_crtc,
+
nv_crtc->cursor.nvbo->offset);
nv_crtc->cursor.set_pos(nv_crtc, nv_crtc->cursor_saved_x,
nv_crtc->cursor_saved_y);
}
diff --git a/drivers/gpu/drm/nouveau/dispnv04/overlay.c
b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
index a3a0a73ae8ab..9529bd9053e7 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/overlay.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
@@ -150,7 +150,7 @@ nv10_update_plane(struct drm_plane *plane, struct drm_crtc
*crtc,
nvif_mask(dev, NV_PCRTC_ENGINE_CTRL + soff2, NV_CRTC_FSEL_OVERLAY, 0);
nvif_wr32(dev, NV_PVIDEO_BASE(flip), 0);
- nvif_wr32(dev, NV_PVIDEO_OFFSET_BUFF(flip), nv_fb->nvbo->bo.offset);
+ nvif_wr32(dev, NV_PVIDEO_OFFSET_BUFF(flip), nv_fb->nvbo->offset);
nvif_wr32(dev, NV_PVIDEO_SIZE_IN(flip), src_h << 16 | src_w);
nvif_wr32(dev, NV_PVIDEO_POINT_IN(flip), src_y << 16 | src_x);
nvif_wr32(dev, NV_PVIDEO_DS_DX(flip), (src_w << 20) / crtc_w);
@@ -172,7 +172,7 @@ nv10_update_plane(struct drm_plane *plane, struct drm_crtc
*crtc,
if (format & NV_PVIDEO_FORMAT_PLANAR) {
nvif_wr32(dev, NV_PVIDEO_UVPLANE_BASE(flip), 0);
nvif_wr32(dev, NV_PVIDEO_UVPLANE_OFFSET_BUFF(flip),
- nv_fb->nvbo->bo.offset + fb->offsets[1]);
+ nv_fb->nvbo->offset + fb->offsets[1]);
}
nvif_wr32(dev, NV_PVIDEO_FORMAT(flip), format | fb->pitches[0]);
nvif_wr32(dev, NV_PVIDEO_STOP, 0);
@@ -396,7 +396,7 @@ nv04_update_plane(struct drm_plane *plane, struct drm_crtc
*crtc,
for (i = 0; i < 2; i++) {
nvif_wr32(dev, NV_PVIDEO_BUFF0_START_ADDRESS + 4 * i,
- nv_fb->nvbo->bo.offset);
+ nv_fb->nvbo->offset);
nvif_wr32(dev, NV_PVIDEO_BUFF0_PITCH_LENGTH + 4 * i,
fb->pitches[0]);
[PATCH 1/8] drm/amdgpu: move ttm bo->offset to amdgpu_bo
GPU address should belong to driver not in memory management.
This patch moves ttm bo.offset and gpu_offset calculation to amdgpu driver.
Signed-off-by: Nirmoy Das
Acked-by: Huang Rui
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 23 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 30 -
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c | 4 +--
5 files changed, 48 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index c687f5415b3f..a27b6a692119 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -918,7 +918,8 @@ int amdgpu_bo_pin_restricted(struct amdgpu_bo *bo, u32
domain,
bo->pin_count++;
if (max_offset != 0) {
- u64 domain_start =
bo->tbo.bdev->man[mem_type].gpu_offset;
+ u64 domain_start = amdgpu_ttm_domain_start(adev,
+ mem_type);
WARN_ON_ONCE(max_offset <
(amdgpu_bo_gpu_offset(bo) - domain_start));
}
@@ -1484,7 +1485,25 @@ u64 amdgpu_bo_gpu_offset(struct amdgpu_bo *bo)
WARN_ON_ONCE(bo->tbo.mem.mem_type == TTM_PL_VRAM &&
!(bo->flags & AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS));
- return amdgpu_gmc_sign_extend(bo->tbo.offset);
+ return amdgpu_bo_gpu_offset_no_check(bo);
+}
+
+/**
+ * amdgpu_bo_gpu_offset_no_check - return GPU offset of bo
+ * @bo:amdgpu object for which we query the offset
+ *
+ * Returns:
+ * current GPU offset of the object without raising warnings.
+ */
+u64 amdgpu_bo_gpu_offset_no_check(struct amdgpu_bo *bo)
+{
+ struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
+ uint64_t offset;
+
+ offset = (bo->tbo.mem.start << PAGE_SHIFT) +
+amdgpu_ttm_domain_start(adev, bo->tbo.mem.mem_type);
+
+ return amdgpu_gmc_sign_extend(offset);
}
/**
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
index 5e39ecd8cc28..32edd35d2ccf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
@@ -282,6 +282,7 @@ int amdgpu_bo_sync_wait_resv(struct amdgpu_device *adev,
struct dma_resv *resv,
bool intr);
int amdgpu_bo_sync_wait(struct amdgpu_bo *bo, void *owner, bool intr);
u64 amdgpu_bo_gpu_offset(struct amdgpu_bo *bo);
+u64 amdgpu_bo_gpu_offset_no_check(struct amdgpu_bo *bo);
int amdgpu_bo_validate(struct amdgpu_bo *bo);
int amdgpu_bo_restore_shadow(struct amdgpu_bo *shadow,
struct dma_fence **fence);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 6309ff72bd78..c2e13e1ec53e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -96,7 +96,6 @@ static int amdgpu_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
case TTM_PL_TT:
/* GTT memory */
man->func = &amdgpu_gtt_mgr_func;
- man->gpu_offset = adev->gmc.gart_start;
man->available_caching = TTM_PL_MASK_CACHING;
man->default_caching = TTM_PL_FLAG_CACHED;
man->flags = TTM_MEMTYPE_FLAG_MAPPABLE | TTM_MEMTYPE_FLAG_CMA;
@@ -104,7 +103,6 @@ static int amdgpu_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
case TTM_PL_VRAM:
/* "On-card" video ram */
man->func = &amdgpu_vram_mgr_func;
- man->gpu_offset = adev->gmc.vram_start;
man->flags = TTM_MEMTYPE_FLAG_FIXED |
TTM_MEMTYPE_FLAG_MAPPABLE;
man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
@@ -115,7 +113,6 @@ static int amdgpu_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
case AMDGPU_PL_OA:
/* On-chip GDS memory*/
man->func = &ttm_bo_manager_func;
- man->gpu_offset = 0;
man->flags = TTM_MEMTYPE_FLAG_FIXED | TTM_MEMTYPE_FLAG_CMA;
man->available_caching = TTM_PL_FLAG_UNCACHED;
man->default_caching = TTM_PL_FLAG_UNCACHED;
@@ -263,7 +260,8 @@ static uint64_t amdgpu_mm_node_addr(struct
ttm_buffer_object *bo,
if (mm_node->start != AMDGPU_BO_INVALID_OFFSET) {
addr = mm_node->start << PAGE_SHIFT;
- addr += bo->bdev->man[mem->mem_type].gpu_offset;
+ addr += amdgpu_ttm_domain_start(amdgpu_ttm_adev(bo->bdev),
+ mem->mem_type);
}
return addr;
}
@@ -750,6 +748,27 @@ static un
Re: [RESEND][PATCH v8 4/8] PM / EM: add support for other devices than CPUs in Energy Model
On 6/24/20 4:21 PM, Rafael J. Wysocki wrote:
On Wed, Jun 10, 2020 at 12:12 PM Lukasz Luba wrote:
Add support for other devices than CPUs. The registration function
does not require a valid cpumask pointer and is ready to handle new
devices. Some of the internal structures has been reorganized in order to
keep consistent view (like removing per_cpu pd pointers).
Signed-off-by: Lukasz Luba
---
Hi all,
This is just a small change compared to v8 addressing Rafael's
comments an Dan's static analyzes.
Here are the changes:
- added comment about mutex usage in the unregister function
- changed 'dev' into @dev in the kerneldoc comments
- removed 'else' statement from em_create_pd() to calm down static analizers
I've applied the series as 5.9 material with patch [4/8] replaced with this one.
Sorry for the delays in handling this!
No worries. Thank you very much!
Regards,
Lukasz
Thanks!
include/linux/device.h | 5 +
include/linux/energy_model.h | 29 -
kernel/power/energy_model.c | 244 ---
3 files changed, 194 insertions(+), 84 deletions(-)
diff --git a/include/linux/device.h b/include/linux/device.h
index ac8e37cd716a..7023d3ea189b 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -13,6 +13,7 @@
#define _DEVICE_H_
#include
+#include
#include
#include
#include
@@ -559,6 +560,10 @@ struct device {
struct dev_pm_info power;
struct dev_pm_domain*pm_domain;
+#ifdef CONFIG_ENERGY_MODEL
+ struct em_perf_domain *em_pd;
+#endif
+
#ifdef CONFIG_GENERIC_MSI_IRQ_DOMAIN
struct irq_domain *msi_domain;
#endif
diff --git a/include/linux/energy_model.h b/include/linux/energy_model.h
index 7076cb22b247..2d4689964029 100644
--- a/include/linux/energy_model.h
+++ b/include/linux/energy_model.h
@@ -12,8 +12,10 @@
/**
* em_perf_state - Performance state of a performance domain
- * @frequency: The CPU frequency in KHz, for consistency with CPUFreq
- * @power: The power consumed by 1 CPU at this level, in milli-watts
+ * @frequency: The frequency in KHz, for consistency with CPUFreq
+ * @power: The power consumed at this level, in milli-watts (by 1 CPU or
+ by a registered device). It can be a total power: static and
+ dynamic.
* @cost: The cost coefficient associated with this level, used during
* energy calculation. Equal to: power * max_frequency / frequency
*/
@@ -27,12 +29,16 @@ struct em_perf_state {
* em_perf_domain - Performance domain
* @table: List of performance states, in ascending order
* @nr_perf_states:Number of performance states
- * @cpus: Cpumask covering the CPUs of the domain
+ * @cpus: Cpumask covering the CPUs of the domain. It's here
+ * for performance reasons to avoid potential cache
+ * misses during energy calculations in the scheduler
+ * and simplifies allocating/freeing that memory region.
*
- * A "performance domain" represents a group of CPUs whose performance is
- * scaled together. All CPUs of a performance domain must have the same
- * micro-architecture. Performance domains often have a 1-to-1 mapping with
- * CPUFreq policies.
+ * In case of CPU device, a "performance domain" represents a group of CPUs
+ * whose performance is scaled together. All CPUs of a performance domain
+ * must have the same micro-architecture. Performance domains often have
+ * a 1-to-1 mapping with CPUFreq policies. In case of other devices the @cpus
+ * field is unused.
*/
struct em_perf_domain {
struct em_perf_state *table;
@@ -71,10 +77,12 @@ struct em_data_callback {
#define EM_DATA_CB(_active_power_cb) { .active_power = &_active_power_cb }
struct em_perf_domain *em_cpu_get(int cpu);
+struct em_perf_domain *em_pd_get(struct device *dev);
int em_register_perf_domain(cpumask_t *span, unsigned int nr_states,
struct em_data_callback *cb);
int em_dev_register_perf_domain(struct device *dev, unsigned int nr_states,
struct em_data_callback *cb, cpumask_t *span);
+void em_dev_unregister_perf_domain(struct device *dev);
/**
* em_pd_energy() - Estimates the energy consumed by the CPUs of a perf.
domain
@@ -184,10 +192,17 @@ int em_dev_register_perf_domain(struct device *dev,
unsigned int nr_states,
{
return -EINVAL;
}
+static inline void em_dev_unregister_perf_domain(struct device *dev)
+{
+}
static inline struct em_perf_domain *em_cpu_get(int cpu)
{
return NULL;
}
+static inline struct em_perf_domain *em_pd_get(struct device *dev)
+{
+ return NULL;
+}
static inline unsigned long em_pd_energy(struct em_perf_domain *pd,
unsigned long max_util, unsigned long sum_util)
{
diff --git a/kernel/power/energy_model.c b/kernel/pow
Re: [RFC] Host1x/TegraDRM UAPI
23.06.2020 15:09, Mikko Perttunen пишет:
>
> struct drm_tegra_channel_submit {
> __u32 channel_id;
> __u32 flags;
>
> /**
> * [in] Timeout in microseconds after which the kernel may
> * consider the job to have hung and may reap it and
> * fast-forward its syncpoint increments.
> *
> * The value may be capped by the kernel.
> */
> __u32 timeout;
What about to rename this to timeout_us? For clarity.
> __u32 num_syncpt_incrs;
> __u32 num_relocations;
> __u32 num_commands;
>
> __u64 syncpt_incrs;
> __u64 relocations;
> __u64 commands;
Let's also add "_ptr" postfix to all usrptr names, again for clarity.
It's always nice to have meaningful names :)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v3] arm64: dts: sc7180: add nodes for idp display
Quoting Harigovindan P (2020-02-17 00:58:42)
> diff --git a/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> index 388f50ad4fde..349db8fe78a5 100644
> --- a/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> +++ b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> @@ -232,6 +233,57 @@ vreg_bob: bob {
> };
> };
>
> +&dsi0 {
> + status = "okay";
> +
> + vdda-supply = <&vreg_l3c_1p2>;
> +
> + panel@0 {
> + compatible = "visionox,rm69299-1080p-display";
> + reg = <0>;
> +
> + vdda-supply = <&vreg_l8c_1p8>;
> + vdd3p3-supply = <&vreg_l18a_2p8>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&disp_pins>;
> +
> + reset-gpios = <&pm6150l_gpio 3 GPIO_ACTIVE_HIGH>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port@0 {
> + reg = <0>;
> + panel0_in: endpoint {
> + remote-endpoint = <&dsi0_out>;
> + };
> + };
> + };
> + };
> +
> + ports {
> + port@1 {
> + endpoint {
> + remote-endpoint = <&panel0_in>;
> + data-lanes = <0 1 2 3>;
Is this property needed? If it's the default assumption it would be nice
to omit it so that we don't have to think about it.
> + };
> + };
> + };
> +};
> +
> +&dsi_phy {
> + status = "okay";
> +};
> +
> +&mdp {
> + status = "okay";
> +};
> +
> +&mdss {
> + status = "okay";
> +};
> +
> &qspi {
> status = "okay";
> pinctrl-names = "default";
> @@ -289,6 +341,17 @@ &usb_1_qmpphy {
>
> /* PINCTRL - additions to nodes defined in sc7180.dtsi */
>
> +&pm6150l_gpio {
> + disp_pins: disp-pins {
Curious how this works. It looks like PMIC GPIOS are expecting the node
to look like:
disp_pins: disp-pins {
pinconf {
pins = "gpio3";
function = PMIC_GPIO_FUNC_FUNC1;
qcom,drive-strength = ;
power-source = ;
bias-disable;
output-low;
};
but this doesn't use the macros or the subnode for pinconf. Why? Also,
the PM6150_GPIO_VPH macro doesn't exist.
> + pins = "gpio3";
> + function = "func1";
> + qcom,drive-strength = <2>;
> + power-source = <0>;
> + bias-disable;
> + output-low;
> + };
> +};
> +
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
