Re: [PATCH v2] drm/bridge: sil_sii8620: make remote control optional.
On 04.03.2019 03:13, Life is hard, and then you die wrote: > On Thu, Jan 24, 2019 at 05:33:55PM -0800, Ronald Tschalär wrote: >> commit d6abe6df706c (drm/bridge: sil_sii8620: do not have a dependency >> of RC_CORE) changed the driver to select both RC_CORE and INPUT. >> However, this causes problems with other drivers, in particular an input >> driver that depends on MFD_INTEL_LPSS_PCI (to be added in a separate >> commit): >> >> drivers/clk/Kconfig:9:error: recursive dependency detected! >> drivers/clk/Kconfig:9:symbol COMMON_CLK is selected by >> MFD_INTEL_LPSS >> drivers/mfd/Kconfig:566: symbol MFD_INTEL_LPSS is selected by >> MFD_INTEL_LPSS_PCI >> drivers/mfd/Kconfig:580: symbol MFD_INTEL_LPSS_PCI is implied by >> KEYBOARD_APPLESPI >> drivers/input/keyboard/Kconfig:73:symbol KEYBOARD_APPLESPI depends on >> INPUT >> drivers/input/Kconfig:8: symbol INPUT is selected by DRM_SIL_SII8620 >> drivers/gpu/drm/bridge/Kconfig:83:symbol DRM_SIL_SII8620 depends on >> DRM_BRIDGE >> drivers/gpu/drm/bridge/Kconfig:1: symbol DRM_BRIDGE is selected by >> DRM_PL111 >> drivers/gpu/drm/pl111/Kconfig:1: symbol DRM_PL111 depends on >> COMMON_CLK >> >> According to the docs and general consensus, select should only be used >> for non user-visible symbols, but both RC_CORE and INPUT are >> user-visible. Furthermore almost all other references to INPUT >> throughout the kernel config are depends, not selects. For this reason >> the first part of this change reverts commit d6abe6df706c. >> >> In order to address the original reason for commit d6abe6df706c, namely >> that not all boards use the remote controller functionality and hence >> should not need have to deal with RC_CORE, the second part of this >> change now makes the remote control support in the driver optional and >> contingent on RC_CORE being defined. And with this the hard dependency >> on INPUT also goes away as that is only needed if RC_CORE is defined >> (which in turn already depends on INPUT). >> >> CC: Inki Dae >> CC: Andrzej Hajda >> CC: Laurent Pinchart >> CC: Dmitry Torokhov >> Signed-off-by: Ronald Tschalär >> --- >> Resending this, as I somehow managed to forget to cc dri-devel. >> Apologies for the duplication. >> >> Changes in v2: >> - completely remove dependencies on both RC_CORE and INPUT in Kconfig, >> - make remote control functionality in driver contingent on RC_CORE >>being defined >> >> drivers/gpu/drm/bridge/Kconfig | 2 -- >> drivers/gpu/drm/bridge/sil-sii8620.c | 17 + >> 2 files changed, 17 insertions(+), 2 deletions(-) > [snip] > > Is there anything I can do to help get this reviewed and moved forward? Addressing my comments [1] ? :) Ah I see, for some reasons (my mistake apparently) my response was not sent to you, sorry. [1]: https://lkml.org/lkml/2019/1/28/258 Regards Andrzej > > > Cheers, > > Ronald > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] drm/amd/powerplay: fix memdup.cocci warnings
Reviewed-by: Likun Gao
-Original Message-
From: Julia Lawall
Sent: Saturday, March 02, 2019 2:51 PM
To: Gao, Likun
Cc: Deucher, Alexander ; Wang, Kevin(Yang)
; Quan, Evan ; Koenig, Christian
; David Airlie ; Daniel Vetter
; Huang, Ray ;
amd-...@lists.freedesktop.org; kbuild test robot ;
dri-devel@lists.freedesktop.org; kbuild-...@01.org
Subject: [PATCH] drm/amd/powerplay: fix memdup.cocci warnings
From: kbuild test robot
Simplify the code a bit by using kmemdup instead of kzalloc and memcpy.
Generated by: scripts/coccinelle/api/memdup.cocci
Fixes: 76760fe3c00d ("drm/amd/powerplay: add function to store overdrive
information for smu11")
CC: Likun Gao
Signed-off-by: kbuild test robot
Signed-off-by: Julia Lawall
---
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-5.2-wip
head: 25752e1fc83e9f983b11d680fc7bfc129b4eaae6
commit: 76760fe3c00d04f25cc1a6115294310d4effeb77 [161/226] drm/amd/powerplay:
add function to store overdrive information for smu11
:: branch date: 6 hours ago
:: commit date: 6 hours ago
vega20_ppt.c | 24 +---
1 file changed, 9 insertions(+), 15 deletions(-)
--- a/drivers/gpu/drm/amd/amdgpu/../powerplay/vega20_ppt.c
+++ b/drivers/gpu/drm/amd/amdgpu/../powerplay/vega20_ppt.c
@@ -173,14 +173,12 @@ static int vega20_setup_od8_information(
if (table_context->od_feature_capabilities)
return -EINVAL;
- table_context->od_feature_capabilities =
kzalloc(od_feature_array_size, GFP_KERNEL);
+ table_context->od_feature_capabilities =
kmemdup(_table->OverDrive8Table.ODFeatureCapabilities,
+
od_feature_array_size,
+GFP_KERNEL);
if (!table_context->od_feature_capabilities)
return -ENOMEM;
- memcpy(table_context->od_feature_capabilities,
- _table->OverDrive8Table.ODFeatureCapabilities,
- od_feature_array_size);
-
/* Setup correct ODSettingCount, and store ODSettingArray from
* powerplay table to od_settings_max and od_setting_min */
od_setting_count =
@@ -194,7 +192,9 @@ static int vega20_setup_od8_information(
if (table_context->od_settings_max)
return -EINVAL;
- table_context->od_settings_max = kzalloc(od_setting_array_size,
GFP_KERNEL);
+ table_context->od_settings_max =
kmemdup(_table->OverDrive8Table.ODSettingsMax,
+od_setting_array_size,
+GFP_KERNEL);
if (!table_context->od_settings_max) {
kfree(table_context->od_feature_capabilities);
@@ -202,14 +202,12 @@ static int vega20_setup_od8_information(
return -ENOMEM;
}
- memcpy(table_context->od_settings_max,
- _table->OverDrive8Table.ODSettingsMax,
- od_setting_array_size);
-
if (table_context->od_settings_min)
return -EINVAL;
- table_context->od_settings_min = kzalloc(od_setting_array_size,
GFP_KERNEL);
+ table_context->od_settings_min =
kmemdup(_table->OverDrive8Table.ODSettingsMin,
+od_setting_array_size,
+GFP_KERNEL);
if (!table_context->od_settings_min) {
kfree(table_context->od_feature_capabilities);
@@ -218,10 +216,6 @@ static int vega20_setup_od8_information(
table_context->od_settings_max = NULL;
return -ENOMEM;
}
-
- memcpy(table_context->od_settings_min,
- _table->OverDrive8Table.ODSettingsMin,
- od_setting_array_size);
}
return 0;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu/powerplay: Fix missing break in switch statement
On Fri, Mar 01, 2019 at 03:29:43PM -0600, Gustavo A. R. Silva wrote:
> Add missing break statement in order to prevent the code from falling
> through to case SMU_Discrete_DpmTable.
>
> This bug was found thanks to the ongoing efforts to enable
> -Wimplicit-fallthrough.
>
> Fixes: 34a564eaf528 ("drm/amd/powerplay: implement fw image related smum
> interface for Polaris.")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Gustavo A. R. Silva
Reviewed-by: Huang Rui
> ---
> drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c
> b/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c
> index 52abca065764..222fb79d319e 100644
> --- a/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c
> @@ -2330,6 +2330,7 @@ static uint32_t polaris10_get_offsetof(uint32_t type,
> uint32_t member)
> case DRAM_LOG_BUFF_SIZE:
> return offsetof(SMU74_SoftRegisters,
> DRAM_LOG_BUFF_SIZE);
> }
> + break;
> case SMU_Discrete_DpmTable:
> switch (member) {
> case UvdBootLevel:
> --
> 2.21.0
>
> ___
> 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: [PATCH libdrm] libkms: update list of intel_drivers for Android build
ping! On 2/21/19 8:56 AM, Tapani Pälli wrote: Add new iris driver, remove deprecated ilo driver. Signed-off-by: Tapani Pälli --- libkms/Android.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libkms/Android.mk b/libkms/Android.mk index 0be72054..a8b9489f 100644 --- a/libkms/Android.mk +++ b/libkms/Android.mk @@ -1,6 +1,6 @@ DRM_GPU_DRIVERS := $(strip $(filter-out swrast, $(BOARD_GPU_DRIVERS))) -intel_drivers := i915 i965 i915g ilo +intel_drivers := i915 i965 i915g iris radeon_drivers := r300g r600g radeonsi nouveau_drivers := nouveau virgl_drivers := virgl ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [radeon-alex:drm-next-5.2-wip 214/226] drivers/gpu/drm/amd/amdgpu/../powerplay/vega20_ppt.c:1204:3-9: preceding lock on line 1065 (fwd)
Hi julia,
Thanks for your reminder, I will submit another patch to fix it soon.
Regards,
Likun
-Original Message-
From: Julia Lawall
Sent: Saturday, March 02, 2019 2:44 PM
To: Gao, Likun
Cc: Deucher, Alexander ; Gui, Jack
; dri-devel@lists.freedesktop.org; kbuild-...@01.org
Subject: [radeon-alex:drm-next-5.2-wip 214/226]
drivers/gpu/drm/amd/amdgpu/../powerplay/vega20_ppt.c:1204:3-9: preceding lock
on line 1065 (fwd)
Hello,
It looks like line 1204 needs a break rather than a return, like in the aborts
from the other cases.
julia
-- Forwarded message --
Date: Sat, 2 Mar 2019 14:36:31 +0800
From: kbuild test robot
To: kbu...@01.org
Cc: Julia Lawall
Subject: [radeon-alex:drm-next-5.2-wip 214/226]
drivers/gpu/drm/amd/amdgpu/../powerplay/vega20_ppt.c:1204:3-9: preceding
lock on line 1065
CC: kbuild-...@01.org
CC: dri-devel@lists.freedesktop.org
TO: Likun Gao
CC: Alex Deucher
CC: Gui Chengming
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-5.2-wip
head: 25752e1fc83e9f983b11d680fc7bfc129b4eaae6
commit: e85bae378020046f53f18a61ac6bd5cdb798a079 [214/226] drm/amd/powerplay:
support sysfs to set/get pcie
:: branch date: 7 hours ago
:: commit date: 7 hours ago
>> drivers/gpu/drm/amd/amdgpu/../powerplay/vega20_ppt.c:1204:3-9:
>> preceding lock on line 1065
git remote add radeon-alex git://people.freedesktop.org/~agd5f/linux.git
git remote update radeon-alex
git checkout e85bae378020046f53f18a61ac6bd5cdb798a079
vim +1204 drivers/gpu/drm/amd/amdgpu/../powerplay/vega20_ppt.c
1d5da59b Likun Gao 2019-01-07 1050
7b0f60df Likun Gao 2019-01-07 1051 static int vega20_force_clk_levels(struct
smu_context *smu,
7b0f60df Likun Gao 2019-01-07 1052 enum pp_clock_type
type, uint32_t mask)
7b0f60df Likun Gao 2019-01-07 1053 {
7b0f60df Likun Gao 2019-01-07 1054 struct vega20_dpm_table *dpm_table;
7b0f60df Likun Gao 2019-01-07 1055 struct vega20_single_dpm_table
*single_dpm_table;
db129665 Likun Gao 2019-02-20 1056 uint32_t soft_min_level,
soft_max_level, hard_min_level;
72ee8378 Likun Gao 2019-01-23 1057 struct smu_dpm_context *smu_dpm =
>smu_dpm;
72ee8378 Likun Gao 2019-01-23 1058 int ret = 0;
72ee8378 Likun Gao 2019-01-23 1059
72ee8378 Likun Gao 2019-01-23 1060 if (smu_dpm->dpm_level !=
AMD_DPM_FORCED_LEVEL_MANUAL) {
72ee8378 Likun Gao 2019-01-23 1061 pr_info("force clock level is
for dpm manual mode only.\n");
72ee8378 Likun Gao 2019-01-23 1062 return -EINVAL;
72ee8378 Likun Gao 2019-01-23 1063 }
72ee8378 Likun Gao 2019-01-23 1064
72ee8378 Likun Gao 2019-01-23 @1065 mutex_lock(&(smu->mutex));
7b0f60df Likun Gao 2019-01-07 1066
7b0f60df Likun Gao 2019-01-07 1067 soft_min_level = mask ? (ffs(mask) - 1)
: 0;
7b0f60df Likun Gao 2019-01-07 1068 soft_max_level = mask ? (fls(mask) - 1)
: 0;
7b0f60df Likun Gao 2019-01-07 1069
7b0f60df Likun Gao 2019-01-07 1070 dpm_table = smu->smu_dpm.dpm_context;
7b0f60df Likun Gao 2019-01-07 1071
7b0f60df Likun Gao 2019-01-07 1072 switch (type) {
7b0f60df Likun Gao 2019-01-07 1073 case PP_SCLK:
7b0f60df Likun Gao 2019-01-07 1074 single_dpm_table =
&(dpm_table->gfx_table);
7b0f60df Likun Gao 2019-01-07 1075
7b0f60df Likun Gao 2019-01-07 1076 if (soft_max_level >=
single_dpm_table->count) {
7b0f60df Likun Gao 2019-01-07 1077 pr_err("Clock level
specified %d is over max allowed %d\n",
7b0f60df Likun Gao 2019-01-07 1078
soft_max_level, single_dpm_table->count - 1);
72ee8378 Likun Gao 2019-01-23 1079 ret = -EINVAL;
72ee8378 Likun Gao 2019-01-23 1080 break;
7b0f60df Likun Gao 2019-01-07 1081 }
7b0f60df Likun Gao 2019-01-07 1082
7b0f60df Likun Gao 2019-01-07 1083
single_dpm_table->dpm_state.soft_min_level =
7b0f60df Likun Gao 2019-01-07 1084
single_dpm_table->dpm_levels[soft_min_level].value;
7b0f60df Likun Gao 2019-01-07 1085
single_dpm_table->dpm_state.soft_max_level =
7b0f60df Likun Gao 2019-01-07 1086
single_dpm_table->dpm_levels[soft_max_level].value;
7b0f60df Likun Gao 2019-01-07 1087
db129665 Likun Gao 2019-02-20 1088 ret =
vega20_upload_dpm_level(smu, false, FEATURE_DPM_GFXCLK_MASK);
7b0f60df Likun Gao 2019-01-07 1089 if (ret) {
7b0f60df Likun Gao 2019-01-07 1090 pr_err("Failed to
upload boot level to lowest!\n");
72ee8378 Likun Gao 2019-01-23 1091 break;
7b0f60df Likun Gao 2019-01-07 1092 }
7b0f60df Likun Gao 2019-01-07 1093
db129665 Likun Gao 2019-02-20 1094 ret =
vega20_upload_dpm_level(smu, true, FEATURE_DPM_GFXCLK_MASK);
72ee8378 Likun Gao 2019-01-23 1095 if (ret)
7b0f60df Likun Gao 2019-01-07 1096 pr_err("Failed to
upload dpm max level to
[Bug 201539] AMDGPU R9 390 automatic fan speed control in Linux 4.19/4.20/5.0
https://bugzilla.kernel.org/show_bug.cgi?id=201539 Jan Ziak (http://atom-symbol.net) (0xe2.0x9a.0...@gmail.com) changed: What|Removed |Added Kernel Version|4.19|4.19, 4.20, 5.0 Summary|AMDGPU R9 390 automatic fan |AMDGPU R9 390 automatic fan |speed control in Linux |speed control in Linux |4.19/4.20 |4.19/4.20/5.0 -- 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 109763] [radeonsi] Enable framerate capping
https://bugs.freedesktop.org/show_bug.cgi?id=109763 --- Comment #12 from Shmerl --- >From what gathered, wrappers like libstrangle aren't working consistently (especially for radv), so having even such minimal limiting upstream would already useful. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109763] [radeonsi] Enable framerate capping
https://bugs.freedesktop.org/show_bug.cgi?id=109763 --- Comment #11 from smoki --- I guess that Chill is what people wants actually, as FRTC-like one can do already via mentioned wrappers anyway. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: manual merge of the drm tree with the drm-fixes tree
Hi Dave,
On Fri, 1 Mar 2019 18:29:58 -0500 Alex Deucher wrote:
>
> On Thu, Feb 28, 2019 at 9:24 PM Stephen Rothwell
> wrote:
> >
> > Today's linux-next merge of the drm tree got a conflict in:
> >
> > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> >
> > between commit:
> >
> > d63716658ac1 ("drm/amd/display: Use vrr friendly pageflip throttling in
> > DC.")
> >
> > from the drm-fixes tree and commits:
> >
> > 8a48b44cd00f ("drm/amd/display: Call into DC once per multiplane flip")
> > bc7f670ee04c ("drm/amd/display: Perform plane updates only when needed")
> >
> > from the drm tree.
> >
> > I had no idea how to resolve this, so I just effectively reverted the
> > drm-fixes commit.
> >
> > I fixed it up (see above) 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.
>
> d63716658ac1 ("drm/amd/display: Use vrr friendly pageflip throttling
> in DC.") should be reverted and this should be applied instead for
> drm-next:
> https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-5.2-wip=5d5f43c235d02e4d8e9d50d012f3b21f380486eb
Maybe you should merge the drm-fixes tree into the drm tree and apply
the above ...
--
Cheers,
Stephen Rothwell
pgpW9IyusSwWY.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109763] [radeonsi] Enable framerate capping
https://bugs.freedesktop.org/show_bug.cgi?id=109763 --- Comment #10 from Shmerl --- If I understand correctly, Chills is doing some dynamic implicit framerate management, which can be useful too, but it would be good to have a hard limit option as well. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109763] [radeonsi] Enable framerate capping
https://bugs.freedesktop.org/show_bug.cgi?id=109763 --- Comment #9 from Shmerl --- I suppose both use cases are important, since there are monitors with and without FreeSync support. I haven't used AMD on Windows (or their closed driver or Linux), so I was not familiar with Chill and FRTC. But yes, that's exactly what this is about. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109763] [radeonsi] Enable framerate capping
https://bugs.freedesktop.org/show_bug.cgi?id=109763 --- Comment #8 from smoki --- Just say, i wanna something like AMD FRTC for non FreeSync users and something like AMD Chill for FreeSync users :D Both these could caps framerate just in a different enviroments and this is where this become complicated as it depends what kind of screen you have these days. If you are VRR capable you wanna something like Chill, otherwise FRTC :D -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109763] [radeonsi] Enable framerate capping
https://bugs.freedesktop.org/show_bug.cgi?id=109763 --- Comment #7 from Shmerl --- (In reply to smoki from comment #6) > Shmerl i guess wants something in driver like AMD FRTC: > > https://www.amd.com/en/technologies/frtc > > So not to use something external like libstrangle: > Yes, something built into radeonsi (and radv) would be nice. Limiting it by GPU clocks isn't really the same, as in "limit it with not exceeding 80 fps" for example. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vkms: Add overlay plane support
Hi Mamta,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.0-rc8 next-20190301]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Mamta-Shukla/drm-vkms-Add-overlay-plane-support/20190304-034802
config: nds32-allyesconfig (attached as .config)
compiler: nds32le-linux-gcc (GCC) 6.4.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=6.4.0 make.cross ARCH=nds32
All warnings (new ones prefixed by >>):
drivers/gpu/drm/vkms/vkms_plane.c: In function 'vkms_overlay_init':
>> drivers/gpu/drm/vkms/vkms_plane.c:182:10: warning: return makes pointer from
>> integer without a cast [-Wint-conversion]
return -ENOMEM;
^
vim +182 drivers/gpu/drm/vkms/vkms_plane.c
169
170 struct drm_plane *vkms_overlay_init(struct vkms_device *vkmsdev)
171 {
172 struct drm_device *dev = >drm;
173 const struct drm_plane_helper_funcs *funcs;
174 struct drm_plane *overlay;
175 const u32 *formats;
176 int ret, nformats;
177 unsigned int blend_caps = BIT(DRM_MODE_BLEND_PIXEL_NONE) |
178 BIT(DRM_MODE_BLEND_PREMULTI);
179
180 overlay = kzalloc(sizeof(*overlay), GFP_KERNEL);
181 if (!overlay)
> 182 return -ENOMEM;
183
184 formats = vkms_overlay_formats;
185 nformats = ARRAY_SIZE(vkms_overlay_formats);
186 funcs = _primary_helper_funcs;
187 drm_plane_helper_add(overlay, funcs);
188 drm_plane_create_alpha_property(overlay);
189 drm_plane_create_blend_mode_property(overlay, blend_caps);
190
191 ret = drm_universal_plane_init(dev, overlay, 0,
192 _plane_funcs,
193 formats, nformats,
194 NULL,
195 DRM_PLANE_TYPE_OVERLAY, NULL);
196 if (ret){
197 kfree(overlay);
198 return ERR_PTR(ret);
199 }
200
201 return overlay;
202 }
203
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vkms: Add overlay plane support
Hi Mamta,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.0-rc8 next-20190301]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Mamta-Shukla/drm-vkms-Add-overlay-plane-support/20190304-034802
config: i386-randconfig-x006-201909 (attached as .config)
compiler: gcc-8 (Debian 8.2.0-20) 8.2.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
drivers/gpu/drm/vkms/vkms_plane.c: In function 'vkms_overlay_init':
>> drivers/gpu/drm/vkms/vkms_plane.c:182:10: warning: returning 'int' from a
>> function with return type 'struct drm_plane *' makes pointer from integer
>> without a cast [-Wint-conversion]
return -ENOMEM;
^
vim +182 drivers/gpu/drm/vkms/vkms_plane.c
169
170 struct drm_plane *vkms_overlay_init(struct vkms_device *vkmsdev)
171 {
172 struct drm_device *dev = >drm;
173 const struct drm_plane_helper_funcs *funcs;
174 struct drm_plane *overlay;
175 const u32 *formats;
176 int ret, nformats;
177 unsigned int blend_caps = BIT(DRM_MODE_BLEND_PIXEL_NONE) |
178 BIT(DRM_MODE_BLEND_PREMULTI);
179
180 overlay = kzalloc(sizeof(*overlay), GFP_KERNEL);
181 if (!overlay)
> 182 return -ENOMEM;
183
184 formats = vkms_overlay_formats;
185 nformats = ARRAY_SIZE(vkms_overlay_formats);
186 funcs = _primary_helper_funcs;
187 drm_plane_helper_add(overlay, funcs);
188 drm_plane_create_alpha_property(overlay);
189 drm_plane_create_blend_mode_property(overlay, blend_caps);
190
191 ret = drm_universal_plane_init(dev, overlay, 0,
192 _plane_funcs,
193 formats, nformats,
194 NULL,
195 DRM_PLANE_TYPE_OVERLAY, NULL);
196 if (ret){
197 kfree(overlay);
198 return ERR_PTR(ret);
199 }
200
201 return overlay;
202 }
203
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109763] [radeonsi] Enable framerate capping
https://bugs.freedesktop.org/show_bug.cgi?id=109763 --- Comment #6 from smoki --- Shmerl i guess wants something in driver like AMD FRTC: https://www.amd.com/en/technologies/frtc So not to use something external like libstrangle: https://gitlab.com/torkel104/libstrangle That could limit framerate for most of GL or VK apps. For Nine and D3D9 games under WINE one could use this d3d9-wrapper: https://github.com/ThirteenAG/d3d9-wrapper Both could be used by (if possible) just dropping wrapper in game dir and set what you want via variables, config file, etc... -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109808] ROCm OpenCL segfaults on drm-next-5.1-wip
https://bugs.freedesktop.org/show_bug.cgi?id=109808 bmil...@gmail.com changed: What|Removed |Added Resolution|--- |NOTABUG Status|NEW |RESOLVED --- Comment #2 from bmil...@gmail.com --- Thanks for the answer, it was indeed a previous outdated config. Tested with CONFIG_ZONE_DEVICE=y and issue is gone, closing this. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/4] drm: rockchip: introduce rk3066 hdmi
Hi Johan.
Thanks for this nive driver.
A few review comments follows.
Sam
On Sat, Mar 02, 2019 at 11:41:13AM +0100, Johan Jonker wrote:
> From: Zheng Yang
>
> Introduce rk3066 hdmi.
A little more info would be good here.
Do not assume all reader knows as much as you do.
>
> Signed-off-by: Zheng Yang
> Signed-off-by: Johan Jonker
> ---
> diff --git a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
> b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
> new file mode 100644
> index 0..3c5b702dc
> --- /dev/null
> +++ b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
> @@ -0,0 +1,911 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
> + *Zheng Yang
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
Please do not use drmP.h in new files. The usage of drmP.h is deprecated.
Also please sort the include files, but keep the nice grouping.
> +
> +#include "rockchip_drm_drv.h"
> +#include "rockchip_drm_vop.h"
> +
> +#include "rk3066_hdmi.h"
> +
> +#define DEFAULT_PLLA_RATE 3000
> +
> +struct hdmi_data_info {
> + int vic;
vic is used so much. It deserves an explanation.
> + bool sink_is_hdmi;
> + unsigned int enc_in_format;
enc_in_format is in this patch only assinged.
aybe drop it (if not used in later patches)
> + unsigned int enc_out_format;
> + unsigned int colorimetry;
> +};
> +
> +struct rk3066_hdmi_i2c {
> + struct i2c_adapter adap;
> +
> + u8 ddc_addr;
> + u8 segment_addr;
The two members above are only used in rk3066_hdmi_i2c_write()
Maybe they can be made local variables?
> + u8 stat;
> +
> + struct mutex lock; /*for i2c operation*/
Name the lock after what is protects, to avoid mis-use.
> + struct completion cmp;
cmp is shorthand for "compare" - as we have a command named so.
Find a better name.
> +};
> +
> +struct rk3066_hdmi {
> + struct device *dev;
> + struct drm_device *drm_dev;
The new way to do this is to embed the device.
See latest patches by Noralf in drm-misc-next, which include a nice example.
> + struct regmap *regmap;
+1 for using regmap.
But then there is still several readl_relaxed() writel_relaxed() calls?
They are in hdmi_readb() and hdmi_writeb(). Should a regmap had been used here
too?
> + int irq;
> + struct clk *hclk;
> + void __iomem *regs;
> +
> + struct drm_connector connector;
> + struct drm_encoder encoder;
> +
> + struct rk3066_hdmi_i2c *i2c;
> + struct i2c_adapter *ddc;
> +
> + unsigned int tmdsclk;
> +
> + struct hdmi_data_info hdmi_data;
> + struct drm_display_mode previous_mode;
> +};
> +
> +#define to_rk3066_hdmi(x) container_of(x, struct rk3066_hdmi, x)
> +
> +static inline u8 hdmi_readb(struct rk3066_hdmi *hdmi, u16 offset)
> +{
> + return readl_relaxed(hdmi->regs + offset);
> +}
> +
> +static inline void hdmi_writeb(struct rk3066_hdmi *hdmi, u16 offset, u32 val)
> +{
> + writel_relaxed(val, hdmi->regs + offset);
> +}
> +
> +static inline void hdmi_modb(struct rk3066_hdmi *hdmi, u16 offset,
> + u32 msk, u32 val)
> +{
> + u8 temp = hdmi_readb(hdmi, offset) & ~msk;
> +
> + temp |= val & msk;
> + hdmi_writeb(hdmi, offset, temp);
> +}
> +
> +static void rk3066_hdmi_i2c_init(struct rk3066_hdmi *hdmi)
> +{
> + int ddc_bus_freq;
> +
> + ddc_bus_freq = (hdmi->tmdsclk >> 2) / HDMI_SCL_RATE;
> +
> + hdmi_writeb(hdmi, HDMI_DDC_BUS_FREQ_L, ddc_bus_freq & 0xFF);
> + hdmi_writeb(hdmi, HDMI_DDC_BUS_FREQ_H, (ddc_bus_freq >> 8) & 0xFF);
> +
> + /* Clear the EDID interrupt flag and mute the interrupt */
> + hdmi_modb(hdmi, HDMI_INTR_MASK1, HDMI_INTR_EDID_MASK, 0);
> + hdmi_writeb(hdmi, HDMI_INTR_STATUS1, HDMI_INTR_EDID_MASK);
> +}
> +
> +static inline u8 rk3066_hdmi_get_power_mode(struct rk3066_hdmi *hdmi)
> +{
> + return hdmi_readb(hdmi, HDMI_SYS_CTRL) & HDMI_SYS_POWER_MODE_MASK;
> +}
> +
> +static void rk3066_hdmi_set_power_mode(struct rk3066_hdmi *hdmi, int mode)
> +{
> + u8 current_mode, next_mode;
> + u8 i = 0;
> +
> + current_mode = rk3066_hdmi_get_power_mode(hdmi);
> +
> + dev_dbg(hdmi->dev, "mode :%d\n", mode);
> + dev_dbg(hdmi->dev, "current_mode :%d\n", current_mode);
> +
> + if (current_mode == mode)
> + return;
> +
> + do {
> + if (current_mode > mode)
> + next_mode = current_mode / 2;
> + else {
> + if (current_mode < HDMI_SYS_POWER_MODE_A)
> + next_mode = HDMI_SYS_POWER_MODE_A;
> + else
> + next_mode = current_mode * 2;
> + }
> +
> + dev_dbg(hdmi->dev, "%d: next_mode :%d\n", i, next_mode);
> +
> + if (next_mode != HDMI_SYS_POWER_MODE_D) {
> + hdmi_modb(hdmi, HDMI_SYS_CTRL,
> + HDMI_SYS_POWER_MODE_MASK, next_mode);
> +
[Bug 109206] Kernel 4.20 amdgpu fails to load firmware on Ryzen 2500U
https://bugs.freedesktop.org/show_bug.cgi?id=109206 --- Comment #20 from Gavin A. --- I changed my kernel to the linux-amd-staging-drm-next-git which already has patch applied. System boots, X starts fine, and I am able to run intensive 3d app without any performance/rendering issues, no special kernel commandline required. I get same error message as comment #19, but no “scrambled pixels.” NB For users with HP Envy x360 15m-bq1 model laptops, the latest BIOS is F.20 which is not listed in the downloads section of HP support site, but rather under Advisories, https://support.hp.com/us-en/product/hp-envy-15m-bq100-x360-convertible-pc/16851057/model/18967057/document/c06219875 . NB2 For system stability, I added kernel option idle=nomwait which seems to have made the laptop far less crashy, YMMV. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/4] drm/panel: Add Novatek NT35596 panel driver
This patch set support Microtech MTF050FHDI-03 MIPI DSI panel, which has Novatek NT35596 controller IC. Since there is no proper programming guide for NT35596 IC, the driver init sequence is referenced from [1] but analyzed based on datasheet. NT35596 support several regulators on the chip, among those ony 4 regulators like VCI, VDDI/DVDD, AVDD, AVEE are used during power-on sequence. Right now driver added code for 3-regulator based power-on sequence since MTF050FHDI-03 panel support. This power-on sequence may be moved to panel_desc in future, if there is any new panel would come up with other type of sequence. [1] https://android.googlesource.com/kernel/msm/+/android-msm-shamu-3.10-lollipop-mr1/arch/arm/boot/dts/qcom/dsi-panel-nt35596-1080p-video.dtsi Any inputs? Jagan. Jagan Teki (4): dt-bindings: Add vendor prefix for novatek dt-bindings: Add vendor prefix for microtech dt-bindings: display: Add Novatek NT35596 panel documentation drm/panel: Add Novatek NT35596 panel driver .../display/panel/novatek,nt35596.txt | 32 + .../devicetree/bindings/vendor-prefixes.txt | 2 + MAINTAINERS | 6 + drivers/gpu/drm/panel/Kconfig | 13 + drivers/gpu/drm/panel/Makefile| 1 + drivers/gpu/drm/panel/panel-novatek-nt35596.c | 860 ++ 6 files changed, 914 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/novatek,nt35596.txt create mode 100644 drivers/gpu/drm/panel/panel-novatek-nt35596.c -- 2.18.0.321.gffc6fa0e3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] dt-bindings: display: Add Novatek NT35596 panel documentation
Novatek NT35596 is a single-chip IC solution for small or medium-sized
LTPS TFT LCD panels. NT35596 provides several system interfaces like
MIPI/SPI/I2C.
Microtech MTF050FHDI-03 is 1080x1920, 4-lane MIPI DSI LCD panel which
has inbuilt NT35596 IC chip.
NT35596 support several regulators on the chip, among those ony 4 regulators
like VCI, VDDI/DVDD, AVDD, AVEE are used during power-on sequence. Since
MTF050FHDI-03 panel do support 3-regulator based power-on sequence, this
patch document only needful regulators and rest can be add while supporting
new panels on the similar chip IC.
Signed-off-by: Jagan Teki
---
.../display/panel/novatek,nt35596.txt | 32 +++
1 file changed, 32 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/novatek,nt35596.txt
diff --git
a/Documentation/devicetree/bindings/display/panel/novatek,nt35596.txt
b/Documentation/devicetree/bindings/display/panel/novatek,nt35596.txt
new file mode 100644
index ..d336cd41e177
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/novatek,nt35596.txt
@@ -0,0 +1,32 @@
+Novatek NT35596 based LCD panels
+
+Novatek NT35596 is a single-chip IC solution for small or medium-sized
+LTPS TFT LCD panels. NT35596 provides several system interfaces like
+MIPI/SPI/I2C.
+
+Microtech MTF050FHDI-03 is 1080x1920, 4-lane MIPI DSI LCD panel which
+has inbuilt NT35596 IC chip.
+
+Required properties:
+- compatible: must be "novatek,nt35596" and one of
+ * "microtech,mtf050fhdi-03"
+- reset-gpios: a GPIO phandle for the reset pin
+
+Required properties for microtech,mtf050fhdi-03:
+- reg: DSI virtual channel used by that screen
+- dvdd-supply: I/O system regulator
+- avdd-supply: analog regulator for MIPI circuit
+- avee-supply: analog regulator for MIPI circuit
+
+Optional properties:
+- backlight: phandle for the backlight control.
+
+panel@0 {
+ compatible = "microtech,mtf050fhdi-03", "novatek,nt35596";
+ reg = <0>;
+ dvdd-supply = <_dldo2>; /* VCC-MIPI */
+ avdd-supply = <_dc1sw>; /* AVDD_5V0 */
+ avee-supply = <_dc1sw>; /* AVEE_5V */
+ reset-gpios = < 3 24 GPIO_ACTIVE_HIGH>; /* LCD-RST: PD24 */
+ backlight = <>;
+};
--
2.18.0.321.gffc6fa0e3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm/panel: Add Novatek NT35596 panel driver
Novatek NT35596 is a single-chip IC solution for small or medium-sized
LTPS TFT LCD panels. NT35596 provides several system interfaces like
MIPI/SPI/I2C.
Currently added support for Microtech MTF050FHDI-03 is 1080x1920,
4-lane MIPI DSI LCD panel which has inbuilt NT35596 IC chip.
NT35596 support several regulators on the chip, among those only 4
regulators like VCI, VDDI/DVDD, AVDD, AVEE are used during power-on
sequence. Right now driver added code for 3-regulator based power-on
sequence since MTF050FHDI-03 panel support. This power-on sequence may
be moved to panel_desc in future, if there is any new panel would come
up with other type of sequence.
Signed-off-by: Jagan Teki
---
MAINTAINERS | 6 +
drivers/gpu/drm/panel/Kconfig | 13 +
drivers/gpu/drm/panel/Makefile| 1 +
drivers/gpu/drm/panel/panel-novatek-nt35596.c | 860 ++
4 files changed, 880 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-novatek-nt35596.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 125d87a23374..d560f1bdd504 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4840,6 +4840,12 @@ S: Maintained
F: drivers/gpu/drm/tinydrm/hx8357d.c
F: Documentation/devicetree/bindings/display/himax,hx8357d.txt
+DRM DRIVER FOR NOVATEK NT35596 MIPI-DSI LCD PANELS
+M: Jagan Teki
+S: Maintained
+F: drivers/gpu/drm/panel/panel-novatek-nt35596.c
+F: Documentation/devicetree/bindings/display/panel/novatek,nt35596.txt
+
DRM DRIVER FOR INTEL I810 VIDEO CARDS
S: Orphan / Obsolete
F: drivers/gpu/drm/i810/
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 5c2c7e8e6ade..c39aaf40445c 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -119,6 +119,19 @@ config DRM_PANEL_LG_LG4573
Say Y here if you want to enable support for LG4573 RGB panel.
To compile this driver as a module, choose M here.
+config DRM_PANEL_NOVATEK_NT35596
+ tristate "Novatek NT35596 panel driver"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for the Novatek NT35596
+ panel controller driver.
+
+ Novatek NT35596 is a single-chip IC solution for small or medium
+ sized LTPS TFT LCD panels. NT35596 provides several system interfaces
+ like MIPI/SPI/I2C.
+
config DRM_PANEL_OLIMEX_LCD_OLINUXINO
tristate "Olimex LCD-OLinuXino panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 3a853ea5cff9..05bc93348345 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) +=
panel-innolux-p079zca.o
obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
obj-$(CONFIG_DRM_PANEL_KINGDISPLAY_KD097D04) += panel-kingdisplay-kd097d04.o
obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
+obj-$(CONFIG_DRM_PANEL_NOVATEK_NT35596) += panel-novatek-nt35596.o
obj-$(CONFIG_DRM_PANEL_OLIMEX_LCD_OLINUXINO) += panel-olimex-lcd-olinuxino.o
obj-$(CONFIG_DRM_PANEL_ORISETECH_OTM8009A) += panel-orisetech-otm8009a.o
obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) +=
panel-panasonic-vvx10f034n00.o
diff --git a/drivers/gpu/drm/panel/panel-novatek-nt35596.c
b/drivers/gpu/drm/panel/panel-novatek-nt35596.c
new file mode 100644
index ..ad740ee891fb
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-novatek-nt35596.c
@@ -0,0 +1,860 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Amarula Solutions
+ * Author: Jagan Teki
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#define NT35596_CMD_LEN2
+
+struct nt35596_panel_desc {
+ const struct drm_display_mode *mode;
+ unsigned intlanes;
+ unsigned long flags;
+ enum mipi_dsi_pixel_format format;
+ const struct nt35596_init_cmd *panel_cmds;
+ unsigned intnum_panel_cmds;
+};
+
+struct nt35596 {
+ struct drm_panelpanel;
+ struct mipi_dsi_device *dsi;
+ const struct nt35596_panel_desc *desc;
+
+ struct backlight_device *backlight;
+ struct regulator*dvdd;
+ struct regulator*avdd;
+ struct regulator*avee;
+ struct gpio_desc*reset;
+};
+
+static inline struct nt35596 *panel_to_nt35596(struct drm_panel *panel)
+{
+ return container_of(panel, struct nt35596, panel);
+}
+
+struct nt35596_init_cmd {
+ u8 data[NT35596_CMD_LEN];
+};
+
+static const struct nt35596_init_cmd microtech_mtf050fhdi_cmds[] = {
+ { .data = { 0xFF, 0xEE } },
+ { .data = { 0xFB, 0x01 }
[PATCH 2/4] dt-bindings: Add vendor prefix for microtech
Add vendor prefix for microtech, known as Microtech Technology Company Limited. a known producer for Liquid Crytal Display modules and Touch Panels. Signed-off-by: Jagan Teki --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 87d556472729..b84f27f077be 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -242,6 +242,7 @@ micrel Micrel Inc. microchip Microchip Technology Inc. microcrystal Micro Crystal AG micron Micron Technology Inc. +microtech Microtech Technology Company Limited mikroe MikroElektronika d.o.o. minix MINIX Technology Ltd. miramems MiraMEMS Sensing Technology Co., Ltd. -- 2.18.0.321.gffc6fa0e3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] dt-bindings: Add vendor prefix for novatek
Add vendor prefix for novatek. Novatek Microelectronics Corp. is a leading fabless chip design company specializing in the design, development and sales of a wide range of display driver ICs & SoC solutions. Signed-off-by: Jagan Teki --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 4f225ce815d8..87d556472729 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -274,6 +274,7 @@ nintendoNintendo nltNLT Technologies, Ltd. nokia Nokia nordic Nordic Semiconductor +novatekNovatek Microelectronics Corp. nutsboard NutsBoard nuvotonNuvoton Technology Corporation nvdNew Vision Display -- 2.18.0.321.gffc6fa0e3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] [v2, 1/2] dt-bindings: panel: Add Boe Himax8279d is 1200x1920, 4-lane MIPI-DSI LCD panel
Hi Jerry. Thanks for the nice patch. On Fri, Mar 01, 2019 at 04:50:48PM +0800, Jerry Han wrote: > Add dt-bingings for it. > > Signed-off-by: Jerry Han One general comment. In the kernel (at least in drm sub-system) the changelog should be complete. Do not expect the reader to read $subject and continue with the changelog. It is better to repeat yourself a little. And then please be a bit more verbose - so the cangelog capture what you are doing (and why). Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] [v2, 2/2] drm/panel: Add Boe Himax8279d MIPI-DSI LCD panel
Hi Jerry
One more small comment.
> +
> + pinfo->reset_gpio = devm_gpiod_get_optional(dev, "enable",
> + GPIOD_OUT_LOW);
> + if (IS_ERR(pinfo->reset_gpio)) {
> + err = PTR_ERR(pinfo->reset_gpio);
> + dev_err(dev, "failed to get enable gpio: %d\n", err);
> + pinfo->reset_gpio = NULL;
> + }
It is confusing that in the binding the name is "enable" but
the gpio is named "reset_gpio".
If you had used "enable_gpio" then this had been more obvious.
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] [v2, 2/2] drm/panel: Add Boe Himax8279d MIPI-DSI LCD panel
Hi Jerry.
Thanks for this nice patch.
It triggered a few review comments, please see below.
In general it is considered good style to prefix all local function,
to avoid name clash with global function and to make it obvious
when the local function is called direct.
So
panel_unprepare() becomes boe_panel_unprepare() etc.
(boe_ is just a suggestion)
Sam
On Fri, Mar 01, 2019 at 04:54:12PM +0800, Jerry Han wrote:
> Add panel driver for it.
>
> Signed-off-by: Jerry Han
> Cc: Jitao Shi
> Cc: Nick Sanders
> Cc: YH Lin
> Cc: Rock wang
> ---
> MAINTAINERS |6 +
> drivers/gpu/drm/panel/Kconfig| 11 +
> drivers/gpu/drm/panel/Makefile |1 +
> drivers/gpu/drm/panel/panel-boe-himax8279d.c | 1074
> ++
> 4 files changed, 1092 insertions(+)
> create mode 100644 drivers/gpu/drm/panel/panel-boe-himax8279d.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b2f710e..38e2881 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4636,6 +4636,12 @@ S: Maintained
> F: drivers/gpu/drm/tinydrm/ili9225.c
> F: Documentation/devicetree/bindings/display/ilitek,ili9225.txt
>
> +DRM DRIVER FOR BOE HIMAX8279D PANELS
> +M: Jerry Han
> +S: Maintained
> +F: drivers/gpu/drm/panel/panel-boe-himax8279d.c
> +F: Documentation/devicetree/bindings/display/panel/boe,himax8279d.txt
> +
Please add new entries in alphabetic order.
> DRM DRIVER FOR INTEL I810 VIDEO CARDS
> S: Orphan / Obsolete
> F: drivers/gpu/drm/i810/
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 6020c30..e5dcfd1 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -186,4 +186,15 @@ config DRM_PANEL_SITRONIX_ST7789V
> Say Y here if you want to enable support for the Sitronix
> ST7789V controller for 240x320 LCD panels
>
> +config DRM_PANEL_BOE_HIMAX8279D
> + tristate "Boe Himax8279d panel"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + depends on BACKLIGHT_CLASS_DEVICE
> + help
> + Say Y here if you want to enable support for Same type
The help text talks about a "Same" TFT-LCD module, but the driver
is named boe. Is the help text correct?
> + TFT-LCD modules. The panel has a 1200x1920 resolution and uses
> + 24 bit RGB per pixel. It provides a MIPI DSI interface to
> + the host and has a built-in LED backlight.
> +
> endmenu
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index 5ccaaa9..8a36543 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -19,3 +19,4 @@ obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) +=
> panel-seiko-43wvf1g.o
> obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
> obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
> obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
> +obj-$(CONFIG_DRM_PANEL_BOE_HIMAX8279D) += panel-boe-himax8279d.o
Entries in the makefile must be sorted alphabetically.
> diff --git a/drivers/gpu/drm/panel/panel-boe-himax8279d.c
> b/drivers/gpu/drm/panel/panel-boe-himax8279d.c
> new file mode 100644
> index 000..836a9cb
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-boe-himax8279d.c
> @@ -0,0 +1,1074 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2019, Huaqin Telecom Technology Co., Ltd
> + *
> + * Author: Jerry Han
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
Please sort include lines alphabetically.
But keep the nice grouping.
> +
> +#include
> +
> +struct panel_cmd {
> + size_t len;
> + const char *data;
> +};
> +
> +#define _INIT_CMD(...) { \
> + .len = sizeof((char[]){__VA_ARGS__}), \
> + .data = (char[]){__VA_ARGS__} }
> +
> +struct panel_desc {
> + const struct drm_display_mode *display_mode;
> + unsigned int bpc;
> + unsigned int width;
> + unsigned int height;
Use width_mm, height_mm like in display_info - this is less confusing.
> +
> + unsigned int delay_t1;
> + unsigned int reset_delay_t2;
> + unsigned int reset_delay_t3;
> + unsigned int reset_delay_t4;
> +
> + unsigned long flags;
In struct mipi_dsi_device this member is named mode_flags,
and all other members have same name. Consider renaming
this to match struct mipi_dsi_device too.
> + enum mipi_dsi_pixel_format format;
> + unsigned int lanes;
> + const struct panel_cmd *on_cmds;
> + const struct panel_cmd *off_cmds;
> +};
> +
> +struct panel_info {
> + struct drm_panel base;
> + struct mipi_dsi_device *link;
> + const struct panel_desc *desc;
> +
> + struct backlight_device *backlight;
> + struct gpio_desc *reset_gpio;
> + struct gpio_desc *pp33_gpio;
> + struct gpio_desc
[Bug 109820] Lockup on simple vulkan example.
https://bugs.freedesktop.org/show_bug.cgi?id=109820 --- Comment #1 from Mike Mestnik --- Here is an description of my setup https://bugs.freedesktop.org/show_bug.cgi?id=109445 I did install zram-tools since that report. I.E. SwapTotal: 8260572 kB -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109820] Lockup on simple vulkan example.
https://bugs.freedesktop.org/show_bug.cgi?id=109820 Bug ID: 109820 Summary: Lockup on simple vulkan example. Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: cheako+bugs_freedesktop_...@mikemestnik.net https://pastebin.com/yCynk3hP Here is an strace of a simple vulkan app https://github.com/cheako/cheako-vulkan/blob/v0.1/0002lighting/vulkan.c that locksup the X11 desktop. It may be useful to note that 0001uniform-buffer-object and 0003index-buffer do not lockup. There are a number of other issues with these example applications and I'll open other bugs for those. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109808] ROCm OpenCL segfaults on drm-next-5.1-wip
https://bugs.freedesktop.org/show_bug.cgi?id=109808 --- Comment #1 from Philip Yang --- Error code -19 means NODEV, please check if the running kernel enables the kernel config option CONFIG_ZONE_DEVICE (read kernel config from file /proc/config.gz). init_user_pages return -NODEV if userptr support is not enabled, userptr support depends on kernel option CONFIG_HMM_MIRROR/CONFIG_HMM, which depends on kernel option CONFIG_ZONE_DEVICE. CONFIG_ZONE_DEVICE, CONFIG_HMM is by default ON, but kernel config file may not select to set CONFIG_ZONE_DEVICE if the kernel config file is from old kernel. If userptr support is not enabled, then clinfo and KFD usreptr support will return error -19. Please correct kernel config file by adding CONFIG_ZONE_DEVICE=y -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] [v2,2/2] drm/panel: Add Boe Himax8279d MIPI-DSI LCD panel
Add panel driver for it.
Signed-off-by: Jerry Han
Cc: Jitao Shi
Cc: Nick Sanders
Cc: YH Lin
Cc: Rock wang
---
MAINTAINERS |6 +
drivers/gpu/drm/panel/Kconfig| 11 +
drivers/gpu/drm/panel/Makefile |1 +
drivers/gpu/drm/panel/panel-boe-himax8279d.c | 1074 ++
4 files changed, 1092 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-boe-himax8279d.c
diff --git a/MAINTAINERS b/MAINTAINERS
index b2f710e..38e2881 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4636,6 +4636,12 @@ S: Maintained
F: drivers/gpu/drm/tinydrm/ili9225.c
F: Documentation/devicetree/bindings/display/ilitek,ili9225.txt
+DRM DRIVER FOR BOE HIMAX8279D PANELS
+M: Jerry Han
+S: Maintained
+F: drivers/gpu/drm/panel/panel-boe-himax8279d.c
+F: Documentation/devicetree/bindings/display/panel/boe,himax8279d.txt
+
DRM DRIVER FOR INTEL I810 VIDEO CARDS
S: Orphan / Obsolete
F: drivers/gpu/drm/i810/
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 6020c30..e5dcfd1 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -186,4 +186,15 @@ config DRM_PANEL_SITRONIX_ST7789V
Say Y here if you want to enable support for the Sitronix
ST7789V controller for 240x320 LCD panels
+config DRM_PANEL_BOE_HIMAX8279D
+ tristate "Boe Himax8279d panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for Same type
+ TFT-LCD modules. The panel has a 1200x1920 resolution and uses
+ 24 bit RGB per pixel. It provides a MIPI DSI interface to
+ the host and has a built-in LED backlight.
+
endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 5ccaaa9..8a36543 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -19,3 +19,4 @@ obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) += panel-seiko-43wvf1g.o
obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
+obj-$(CONFIG_DRM_PANEL_BOE_HIMAX8279D) += panel-boe-himax8279d.o
diff --git a/drivers/gpu/drm/panel/panel-boe-himax8279d.c
b/drivers/gpu/drm/panel/panel-boe-himax8279d.c
new file mode 100644
index 000..836a9cb
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-boe-himax8279d.c
@@ -0,0 +1,1074 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019, Huaqin Telecom Technology Co., Ltd
+ *
+ * Author: Jerry Han
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+struct panel_cmd {
+ size_t len;
+ const char *data;
+};
+
+#define _INIT_CMD(...) { \
+ .len = sizeof((char[]){__VA_ARGS__}), \
+ .data = (char[]){__VA_ARGS__} }
+
+struct panel_desc {
+ const struct drm_display_mode *display_mode;
+ unsigned int bpc;
+ unsigned int width;
+ unsigned int height;
+
+ unsigned int delay_t1;
+ unsigned int reset_delay_t2;
+ unsigned int reset_delay_t3;
+ unsigned int reset_delay_t4;
+
+ unsigned long flags;
+ enum mipi_dsi_pixel_format format;
+ unsigned int lanes;
+ const struct panel_cmd *on_cmds;
+ const struct panel_cmd *off_cmds;
+};
+
+struct panel_info {
+ struct drm_panel base;
+ struct mipi_dsi_device *link;
+ const struct panel_desc *desc;
+
+ struct backlight_device *backlight;
+ struct gpio_desc *reset_gpio;
+ struct gpio_desc *pp33_gpio;
+ struct gpio_desc *pp18_gpio;
+
+ bool prepared;
+ bool enabled;
+};
+
+void set_gpios(struct panel_info *pinfo, int enable)
+{
+ gpiod_set_value(pinfo->reset_gpio, enable);
+ gpiod_set_value(pinfo->pp33_gpio, enable);
+ gpiod_set_value(pinfo->pp18_gpio, enable);
+}
+
+static inline struct panel_info *to_panel_info(struct drm_panel *panel)
+{
+ return container_of(panel, struct panel_info, base);
+}
+
+static int panel_disable(struct drm_panel *panel)
+{
+ struct panel_info *pinfo = to_panel_info(panel);
+
+ backlight_disable(pinfo->backlight);
+
+ pinfo->enabled = false;
+
+ return 0;
+}
+
+static int panel_unprepare(struct drm_panel *panel)
+{
+ struct panel_info *pinfo = to_panel_info(panel);
+ int err;
+
+ if (!pinfo->prepared)
+ return 0;
+
+ /* send off code */
+ if (pinfo->desc->off_cmds) {
+ const struct panel_cmd *cmds = pinfo->desc->off_cmds;
+ unsigned int i;
+
+ for (i = 0; cmds[i].len != 0; i++) {
+ const struct panel_cmd *cmd = [i];
+
+
[PATCH] [v2, 1/2] dt-bindings: panel: Add Boe Himax8279d is 1200x1920, 4-lane MIPI-DSI LCD panel
Add dt-bingings for it.
Signed-off-by: Jerry Han
Cc: Jitao Shi
Cc: Nick Sanders
Cc: YH Lin
Cc: Rock wang
---
.../bindings/display/panel/boe,himax8279d.txt | 24 ++
1 file changed, 24 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/boe,himax8279d.txt
diff --git a/Documentation/devicetree/bindings/display/panel/boe,himax8279d.txt
b/Documentation/devicetree/bindings/display/panel/boe,himax8279d.txt
new file mode 100644
index 000..3caea21
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/boe,himax8279d.txt
@@ -0,0 +1,24 @@
+Boe Himax8279d 1200x1920 TFT LCD panel
+
+Required properties:
+- compatible: should be "boe,himax8279d8p" and one of: "boe,himax8279d10p"
+- reg: DSI virtual channel of the peripheral
+- enable-gpios: panel enable gpio
+- pp33-gpios: a GPIO phandle for the 3.3v pin that provides the supply voltage
+- pp18-gpios: a GPIO phandle for the 1.8v pin that provides the supply voltage
+
+Optional properties:
+- backlight: phandle of the backlight device attached to the panel
+
+Example:
+
+ _dsi {
+ panel {
+ compatible = "boe,himax8279d8p", "boe,himax8279d10p";
+ reg = <0>;
+ backlight = <>;
+ enable-gpios = < 45 GPIO_ACTIVE_HIGH>;
+ pp33-gpios = < 35 GPIO_ACTIVE_HIGH>;
+ pp18-gpios = < 36 GPIO_ACTIVE_HIGH>;
+ };
+ };
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 3/7] drm/leases: Don't init to 0 in drm_master_create
Daniel Vetter writes: > We kzalloc. > > Cc: Keith Packard > Signed-off-by: Daniel Vetter Reviewed-by: Mika Kuoppala > --- > drivers/gpu/drm/drm_auth.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c > index 1669c42c40ed..bcf0a5a1018f 100644 > --- a/drivers/gpu/drm/drm_auth.c > +++ b/drivers/gpu/drm/drm_auth.c > @@ -109,8 +109,6 @@ struct drm_master *drm_master_create(struct drm_device > *dev) > master->dev = dev; > > /* initialize the tree of output resource lessees */ > - master->lessor = NULL; > - master->lessee_id = 0; > INIT_LIST_HEAD(>lessees); > INIT_LIST_HEAD(>lessee_list); > idr_init(>leases); > -- > 2.14.4 > > ___ > 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
[PATCH] drm: add __user attribute to ptr_to_compat()
The ptr_to_compat() call takes a "void __user *", so cast
the compat drm calls that use it to avoid the following
warnings from sparse:
drivers/gpu/drm/drm_ioc32.c:188:39: warning: incorrect type in argument 1
(different address spaces)
drivers/gpu/drm/drm_ioc32.c:188:39:expected void [noderef] *uptr
drivers/gpu/drm/drm_ioc32.c:188:39:got void *[addressable] [assigned] handle
drivers/gpu/drm/drm_ioc32.c:529:41: warning: incorrect type in argument 1
(different address spaces)
drivers/gpu/drm/drm_ioc32.c:529:41:expected void [noderef] *uptr
drivers/gpu/drm/drm_ioc32.c:529:41:got void *[addressable] [assigned] handle
Signed-off-by: Ben Dooks
---
drivers/gpu/drm/drm_ioc32.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_ioc32.c b/drivers/gpu/drm/drm_ioc32.c
index 67b1fca39aa6..0e3043e08c69 100644
--- a/drivers/gpu/drm/drm_ioc32.c
+++ b/drivers/gpu/drm/drm_ioc32.c
@@ -185,7 +185,7 @@ static int compat_drm_getmap(struct file *file, unsigned
int cmd,
m32.size = map.size;
m32.type = map.type;
m32.flags = map.flags;
- m32.handle = ptr_to_compat(map.handle);
+ m32.handle = ptr_to_compat((void __user *)map.handle);
m32.mtrr = map.mtrr;
if (copy_to_user(argp, , sizeof(m32)))
return -EFAULT;
@@ -216,7 +216,7 @@ static int compat_drm_addmap(struct file *file, unsigned
int cmd,
m32.offset = map.offset;
m32.mtrr = map.mtrr;
- m32.handle = ptr_to_compat(map.handle);
+ m32.handle = ptr_to_compat((void __user *)map.handle);
if (map.handle != compat_ptr(m32.handle))
pr_err_ratelimited("compat_drm_addmap truncated handle %p for
type %d offset %x\n",
map.handle, m32.type, m32.offset);
@@ -526,7 +526,7 @@ static int compat_drm_getsareactx(struct file *file,
unsigned int cmd,
if (err)
return err;
- req32.handle = ptr_to_compat(req.handle);
+ req32.handle = ptr_to_compat((void __user *)req.handle);
if (copy_to_user(argp, , sizeof(req32)))
return -EFAULT;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] DRM: Add KMS driver for the Ingenic JZ47xx SoCs
Hi,
Le ven. 1 mars 2019 à 18:00, Sam Ravnborg a écrit :
Hi Paul.
Driver looks good and is a very nice piece of work.
In the following a number of minor issues.
One area that jumped at me was framedesc and the use of
dma_alloc_coherent()
I hope someone that knows the memory handling better can give some
advice here.
To me it looks like something drm should be able to help you with.
Sam
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -94,6 +94,7 @@ obj-$(CONFIG_DRM_TEGRA) += tegra/
obj-$(CONFIG_DRM_STM) += stm/
obj-$(CONFIG_DRM_STI) += sti/
obj-$(CONFIG_DRM_IMX) += imx/
+obj-y += ingenic/
To avoid visiting ingenic/ dir for every build use:
obj-$(CONFIG_DRM_INGENIC) += ingennic/
And accept that you need to do this also in ingenic/Makefile
OK.
obj-$(CONFIG_DRM_MEDIATEK) += mediatek/
obj-$(CONFIG_DRM_MESON) += meson/
obj-y += i2c/
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "../drm_internal.h"
No other drivers needs drm_internal.h - what makes this driver
special?
Or do we have something in drm_internal that should be moved to
include/drm/ ?
I needed to include it for drm_vblank_cleanup().
But I guess I don't need to call that function? It's not obvious to me
how the error handling and driver removal should be done.
+struct ingenic_framedesc {
+ uint32_t next;
+ uint32_t addr;
+ uint32_t id;
+ uint32_t cmd;
+} __packed;
For internel types u32 is the typical use.
uint32_t is usually used in uapi.
Consider to use dma_addr_t for addresses - we see this in other
drivers.
If there are alignemnt constraints then add these.
So 'ingenic_framedesc' represents a DMA descriptor, in the format that
the hardware expects it. The fields must be 32-bit. Is a dma_addr_t
the best option in that case?
+
+struct jz_soc_info {
+ bool needs_dev_clk;
+};
+
+struct ingenic_drm {
+ struct device *dev;
+ void __iomem *base;
+ struct regmap *map;
+ struct clk *lcd_clk, *pix_clk;
+
+ u32 lcd_mode;
+
+ struct ingenic_framedesc *framedesc;
+ dma_addr_t framedesc_phys;
+
+ struct drm_device *drm;
+ struct drm_plane primary;
+ struct drm_crtc crtc;
+ struct drm_connector connector;
+ struct drm_encoder encoder;
+ struct drm_panel *panel;
+
+ struct device_node *panel_node;
panel_node is not used outside ingenic_drm_probe() so no need
to have it here.
Noted.
+
+ unsigned short ps_start, ps_end, cls_start,
+ cls_end, spl_start, spl_end, rev_start;
I do not see these used, they can all be dropped.
+};
+
+
+static const struct regmap_config ingenic_drm_regmap_config = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+
+ .max_register = JZ_REG_LCD_CMD1,
+ .writeable_reg = ingenic_drm_writeable_reg,
+};
+1 for using regmap.
+
+static inline bool ingenic_drm_lcd_is_special_mode(u32 mode)
+{
+ switch (mode) {
+ case JZ_DRM_LCD_SPECIAL_TFT_1:
+ case JZ_DRM_LCD_SPECIAL_TFT_2:
+ case JZ_DRM_LCD_SPECIAL_TFT_3:
+ return true;
+ default:
+ return false;
+ }
+}
Does it make sense to support these modes today?
If it is not used in practice then no need to carry it in the driver.
Yes, I have a board that uses such a panel.
+
+static inline bool ingenic_drm_lcd_is_stn_mode(u32 mode)
+{
+ switch (mode) {
+ case JZ_DRM_LCD_SINGLE_COLOR_STN:
+ case JZ_DRM_LCD_SINGLE_MONOCHROME_STN:
+ case JZ_DRM_LCD_DUAL_COLOR_STN:
+ case JZ_DRM_LCD_DUAL_MONOCHROME_STN:
+ return true;
+ default:
+ return false;
+ }
+}
This function is not used and can be deleted.
stn display are not really worth it these days anyway.
+static void ingenic_drm_crtc_atomic_flush(struct drm_crtc *crtc,
+struct drm_crtc_state *oldstate)
+{
+ struct ingenic_drm *priv = drm_crtc_get_priv(crtc);
+ struct drm_crtc_state *state = crtc->state;
+ struct drm_pending_vblank_event *event = state->event;
+ struct drm_framebuffer *drm_fb = crtc->primary->state->fb;
+ const struct drm_format_info *finfo;
+ unsigned int width, height;
+
+ if (drm_atomic_crtc_needs_modeset(state)) {
+ finfo = drm_format_info(drm_fb->format->format);
+ width = state->adjusted_mode.hdisplay;
+ height = state->adjusted_mode.vdisplay;
width and height are unused and can be dropped.
+
+ ingenic_drm_crtc_update_timings(priv, >mode);
+
+ ingenic_drm_crtc_update_ctrl(priv, finfo->depth);
+ ingenic_drm_crtc_update_cfg(priv, >adjusted_mode);
+
+ clk_set_rate(priv->pix_clk,
[PATCH] [v2,2/2] drm/panel: Add Boe Himax8279d MIPI-DSI LCD panel
Add panel driver for it.
Signed-off-by: Jerry Han
Cc: Jitao Shi
Cc: Nick Sanders
Cc: YH Lin
Cc: Rock wang
---
MAINTAINERS |6 +
drivers/gpu/drm/panel/Kconfig| 11 +
drivers/gpu/drm/panel/Makefile |1 +
drivers/gpu/drm/panel/panel-boe-himax8279d.c | 1077 ++
4 files changed, 1095 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-boe-himax8279d.c
diff --git a/MAINTAINERS b/MAINTAINERS
index b2f710e..38e2881 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4636,6 +4636,12 @@ S: Maintained
F: drivers/gpu/drm/tinydrm/ili9225.c
F: Documentation/devicetree/bindings/display/ilitek,ili9225.txt
+DRM DRIVER FOR BOE HIMAX8279D PANELS
+M: Jerry Han
+S: Maintained
+F: drivers/gpu/drm/panel/panel-boe-himax8279d.c
+F: Documentation/devicetree/bindings/display/panel/boe,himax8279d.txt
+
DRM DRIVER FOR INTEL I810 VIDEO CARDS
S: Orphan / Obsolete
F: drivers/gpu/drm/i810/
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 6020c30..e5dcfd1 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -186,4 +186,15 @@ config DRM_PANEL_SITRONIX_ST7789V
Say Y here if you want to enable support for the Sitronix
ST7789V controller for 240x320 LCD panels
+config DRM_PANEL_BOE_HIMAX8279D
+ tristate "Boe Himax8279d panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for Same type
+ TFT-LCD modules. The panel has a 1200x1920 resolution and uses
+ 24 bit RGB per pixel. It provides a MIPI DSI interface to
+ the host and has a built-in LED backlight.
+
endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 5ccaaa9..8a36543 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -19,3 +19,4 @@ obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) += panel-seiko-43wvf1g.o
obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
+obj-$(CONFIG_DRM_PANEL_BOE_HIMAX8279D) += panel-boe-himax8279d.o
diff --git a/drivers/gpu/drm/panel/panel-boe-himax8279d.c
b/drivers/gpu/drm/panel/panel-boe-himax8279d.c
new file mode 100644
index 000..60f5f8b
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-boe-himax8279d.c
@@ -0,0 +1,1077 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019, Huaqin Telecom Technology Co., Ltd
+ *
+ * Author: Jerry Han
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+struct panel_cmd {
+ size_t len;
+ const char *data;
+};
+
+#define _INIT_CMD(...) { \
+ .len = sizeof((char[]){__VA_ARGS__}), \
+ .data = (char[]){__VA_ARGS__} }
+
+struct panel_desc {
+ const struct drm_display_mode *display_mode;
+ unsigned int bpc;
+ unsigned int width;
+ unsigned int height;
+
+ unsigned int delay_t1;
+ unsigned int reset_delay_t2;
+ unsigned int reset_delay_t3;
+ unsigned int reset_delay_t4;
+
+ unsigned long flags;
+ enum mipi_dsi_pixel_format format;
+ unsigned int lanes;
+ const struct panel_cmd *on_cmds;
+ const struct panel_cmd *off_cmds;
+};
+
+struct panel_info {
+ struct drm_panel base;
+ struct mipi_dsi_device *link;
+ const struct panel_desc *desc;
+
+ struct backlight_device *backlight;
+ struct gpio_desc *reset_gpio;
+ struct gpio_desc *pp33_gpio;
+ struct gpio_desc *pp18_gpio;
+
+ bool prepared;
+ bool enabled;
+};
+
+void set_gpios(struct panel_info *pinfo, int enable)
+{
+ gpiod_set_value(pinfo->reset_gpio, enable);
+ gpiod_set_value(pinfo->pp33_gpio, enable);
+ gpiod_set_value(pinfo->pp18_gpio, enable);
+}
+
+static inline struct panel_info *to_panel_info(struct drm_panel *panel)
+{
+ return container_of(panel, struct panel_info, base);
+}
+
+static int panel_disable(struct drm_panel *panel)
+{
+ struct panel_info *pinfo = to_panel_info(panel);
+
+ backlight_disable(pinfo->backlight);
+
+ pinfo->enabled = false;
+
+ return 0;
+}
+
+static int panel_unprepare(struct drm_panel *panel)
+{
+ struct panel_info *pinfo = to_panel_info(panel);
+ int err;
+
+ if (!pinfo->prepared)
+ return 0;
+
+ /* send off code */
+ if (pinfo->desc->off_cmds) {
+ const struct panel_cmd *cmds = pinfo->desc->off_cmds;
+ unsigned int i;
+
+ for (i = 0; cmds[i].len != 0; i++) {
+ const struct panel_cmd *cmd = [i];
+
+
Re: [PATCH 6/7] drm: atmel-hlcdc: enable sys_clk during initalization.
On 28.02.2019 23:55, Sam Ravnborg wrote:
> Hi Claudiu
>
> On Wed, Feb 27, 2019 at 04:24:40PM +, claudiu.bez...@microchip.com wrote:
>> From: Sandeep Sheriker Mallikarjun
>>
>>
>> For SAM9X60 SoC, sys_clk is through lcd_gclk clock source and this
>> needs to be enabled before enabling lcd_clk.
>
> We have "ownership" of the clocks in the mfd device.
> So it would make more sense to let the mfd device handle
> the base clocks.
> In other words - what about pushing enable of perigh_clk and sys_clk to
> the mfd driver.
I think this could be achieved, but how is better? To have individual
drivers (in this care I would say, child drivers, like e.g. this lcd
driver) taking decisions on their own for their resources (even if shared)
or to have parents taking decisions for them? Just asking.
>
> This may have the nice side-effect that we avoid
> that both the drm driver and the pwm driver enable/disable the periph_clk
> as it is today.
>
> Another comment - fixed_clksrc is used to determine if sys_clk is enabled.
> But that flag is about the clksource selection, and it is just a coincidence
> that the same flag can be used here.
Yes, agree on this, I took advantage of fixed_clksrc to also enable the
sys_clk based on fixed_clksrc to avoid introducing another member in struct
atmel_hlcdc_dc_desc. At this moment this is valid only for SAM9X60 and I
was thinking that in case some other scenario will appear I will do the
appropriate changes.
> Why we cannot always enable sys_clk? Do we need to do this only
> for sam9x60?
Only SAM9X60 requires this explicitly at probe.
> IF yes, then add a new falg. If no, then skip the flag.
>
> Sam
>
>
>>
>> Signed-off-by: Sandeep Sheriker Mallikarjun
>>
>> [claudiu.bez...@microchip.com: add fixed_clksrc checks]
>> Signed-off-by: Claudiu Beznea
>> ---
>> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 19 ++-
>> 1 file changed, 18 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
>> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
>> index 0be13eceedba..8bf51f853721 100644
>> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
>> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
>> @@ -625,10 +625,18 @@ static int atmel_hlcdc_dc_load(struct drm_device *dev)
>> dc->hlcdc = dev_get_drvdata(dev->dev->parent);
>> dev->dev_private = dc;
>>
>> +if (dc->desc->fixed_clksrc) {
>> +ret = clk_prepare_enable(dc->hlcdc->sys_clk);
>> +if (ret) {
>> +dev_err(dev->dev, "failed to enable sys_clk\n");
>> +goto err_destroy_wq;
>> +}
>> +}
>> +
>> ret = clk_prepare_enable(dc->hlcdc->periph_clk);
>> if (ret) {
>> dev_err(dev->dev, "failed to enable periph_clk\n");
>> -goto err_destroy_wq;
>> +goto err_sys_clk_disable;
>> }
>>
>> pm_runtime_enable(dev->dev);
>> @@ -664,6 +672,9 @@ static int atmel_hlcdc_dc_load(struct drm_device *dev)
>> err_periph_clk_disable:
>> pm_runtime_disable(dev->dev);
>> clk_disable_unprepare(dc->hlcdc->periph_clk);
>> +err_sys_clk_disable:
>> +if (dc->desc->fixed_clksrc)
>> +clk_disable_unprepare(dc->hlcdc->sys_clk);
>>
>> err_destroy_wq:
>> destroy_workqueue(dc->wq);
>> @@ -688,6 +699,8 @@ static void atmel_hlcdc_dc_unload(struct drm_device *dev)
>>
>> pm_runtime_disable(dev->dev);
>> clk_disable_unprepare(dc->hlcdc->periph_clk);
>> +if (dc->desc->fixed_clksrc)
>> +clk_disable_unprepare(dc->hlcdc->sys_clk);
>> destroy_workqueue(dc->wq);
>> }
>>
>> @@ -805,6 +818,8 @@ static int atmel_hlcdc_dc_drm_suspend(struct device *dev)
>> regmap_read(regmap, ATMEL_HLCDC_IMR, >suspend.imr);
>> regmap_write(regmap, ATMEL_HLCDC_IDR, dc->suspend.imr);
>> clk_disable_unprepare(dc->hlcdc->periph_clk);
>> +if (dc->desc->fixed_clksrc)
>> +clk_disable_unprepare(dc->hlcdc->sys_clk);
>>
>> return 0;
>> }
>> @@ -814,6 +829,8 @@ static int atmel_hlcdc_dc_drm_resume(struct device *dev)
>> struct drm_device *drm_dev = dev_get_drvdata(dev);
>> struct atmel_hlcdc_dc *dc = drm_dev->dev_private;
>>
>> +if (dc->desc->fixed_clksrc)
>> +clk_prepare_enable(dc->hlcdc->sys_clk);
>> clk_prepare_enable(dc->hlcdc->periph_clk);
>> regmap_write(dc->hlcdc->regmap, ATMEL_HLCDC_IER, dc->suspend.imr);
>>
>> --
>> 2.7.4
>>
>> ___
>> 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
[PATCH v3 3/4] ARM: dts: rockchip: rk3066a-mk808: enable vop0 and hdmi nodes
This patch enables the vop0 and hdmi nodes
for a MK808 with rk3066 processor.
Signed-off-by: Johan Jonker
---
arch/arm/boot/dts/rk3066a-mk808.dts | 29 +
1 file changed, 29 insertions(+)
diff --git a/arch/arm/boot/dts/rk3066a-mk808.dts
b/arch/arm/boot/dts/rk3066a-mk808.dts
index 9d2216d71..8bc259d3e 100644
--- a/arch/arm/boot/dts/rk3066a-mk808.dts
+++ b/arch/arm/boot/dts/rk3066a-mk808.dts
@@ -30,6 +30,17 @@
};
};
+ hdmi_con {
+ compatible = "hdmi-connector";
+ type = "c";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <_out_con>;
+ };
+ };
+ };
+
vcc_io: vcc-io {
compatible = "regulator-fixed";
regulator-name = "vcc_io";
@@ -91,6 +102,20 @@
};
};
+ {
+ status = "okay";
+};
+
+_in_vop1 {
+ status = "disabled";
+};
+
+_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <_con_in>;
+ };
+};
+
{
bus-width = <4>;
cap-mmc-highspeed;
@@ -150,6 +175,10 @@
status = "okay";
};
+ {
+ status = "okay";
+};
+
{
status = "okay";
};
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] [v2, 1/2] dt-bindings: panel: Add Boe Himax8279d is 1200x1920, 4-lane MIPI-DSI LCD panel
Add dt-bingings for it.
Signed-off-by: Jerry Han
Cc: Jitao Shi
Cc: Nick Sanders
Cc: YH Lin
Cc: Rock wang
---
.../bindings/display/panel/boe,himax8279d.txt | 24 ++
1 file changed, 24 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/boe,himax8279d.txt
diff --git a/Documentation/devicetree/bindings/display/panel/boe,himax8279d.txt
b/Documentation/devicetree/bindings/display/panel/boe,himax8279d.txt
new file mode 100644
index 000..3caea21
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/boe,himax8279d.txt
@@ -0,0 +1,24 @@
+Boe Himax8279d 1200x1920 TFT LCD panel
+
+Required properties:
+- compatible: should be "boe,himax8279d8p" and one of: "boe,himax8279d10p"
+- reg: DSI virtual channel of the peripheral
+- enable-gpios: panel enable gpio
+- pp33-gpios: a GPIO phandle for the 3.3v pin that provides the supply voltage
+- pp18-gpios: a GPIO phandle for the 1.8v pin that provides the supply voltage
+
+Optional properties:
+- backlight: phandle of the backlight device attached to the panel
+
+Example:
+
+ _dsi {
+ panel {
+ compatible = "boe,himax8279d8p", "boe,himax8279d10p";
+ reg = <0>;
+ backlight = <>;
+ enable-gpios = < 45 GPIO_ACTIVE_HIGH>;
+ pp33-gpios = < 35 GPIO_ACTIVE_HIGH>;
+ pp18-gpios = < 36 GPIO_ACTIVE_HIGH>;
+ };
+ };
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm: Fix NULL pointer dereference
[3.707412] Unable to handle kernel NULL pointer dereference at virtual address 009c [3.714511] pgd = (ptrval) [3.722742] [009c] *pgd= [3.725238] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [3.728968] Modules linked in: [3.734265] CPU: 3 PID: 112 Comm: kworker/3:2 Tainted: GW 5.0.0-rc7-00183-g06a1c31df9eb #4 [3.737142] Hardware name: Generic DT based system [3.746778] Workqueue: events deferred_probe_work_func [3.751542] PC is at msm_gem_map_vma+0x3c/0xac [3.756669] LR is at msm_gem_get_and_pin_iova+0xd8/0x134 [3.761086] pc : []lr : []psr: 6013 [3.766560] sp : ee297be8 ip : ed9ab1c0 fp : ed93b800 [3.772546] r10: ee35e180 r9 : r8 : ee297c80 [3.52] r7 : r6 : 7c10 r5 : r4 : ee35e180 [3.782968] r3 : 0001 r2 : 0003 r1 : ee35e180 r0 : [3.789562] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [3.796079] Control: 10c5787d Table: 2e3a806a DAC: 0051 [3.803282] Process kworker/3:2 (pid: 112, stack limit = 0x(ptrval)) [3.809006] Stack: (0xee297be8 to 0xee298000) [3.815445] 7be0: c1108c48 eda8c000 0003 eda8c0fc c1108c48 [3.819715] 7c00: eda8c000 0003 eda8c0fc c07d14f8 0001 c07d1100 7c10 [3.827873] 7c20: eda8c000 bb7ffb78 eda8c000 c0c8b1d4 ee3bfa00 [3.836037] 7c40: ee3b9800 c07d1684 c1108c48 ee0d7810 ee3b9800 c0c8b1d4 c07d222c [3.844193] 7c60: ee3bfd84 ee297c80 c0b1d5b0 ee3bfc40 c07dcfd8 ee3bfd84 ee297c80 [3.852357] 7c80: 006d ee3bfc40 ee0d7810 bb7ffb78 c0c8b1d4 ee3bfc40 c07ddb48 [3.860516] 7ca0: 2004 c0eba384 ee3bfc40 c079eba0 ee3bd040 ee3b9800 0001 ed93b800 [3.868673] 7cc0: ed9aa100 c07db7e8 ee3bf240 ed9a6500 0001 ee3b9800 ee3bf2d4 c07a0a30 [3.876834] 7ce0: ed93b800 7d10 c1108c48 ee0d7610 ee3b9800 ed93b800 c1108c48 [3.884991] 7d00: [3.893151] 7d20: bb7ffb78 [3.901310] 7d40: c12113c4 ed93b800 ee3b9800 c1108c48 ee9eec10 ed93b800 7d10 [3.909472] 7d60: eff7b000 c07cf748 7d10 c0e9a350 c0b1d5b0 c12113c4 c0961e40 [3.917633] 7d80: c12113c4 4113 eeff4bec c0ebe004 0019 c0b1d230 ee9eeda8 6113 [3.925791] 7da0: ee35d300 ee9eeda8 c07ce260 bb7ffb78 c07ce260 ee35d2c0 0028 0002 [3.933950] 7dc0: eeb76280 c118f884 ee0be640 c11c6128 c07ce260 c07ea4ac c0962b48 [3.942108] 7de0: c118f868 0001 c0ebbc98 ee35d2c0 eeb76280 c118f87c [3.950270] 7e00: ee35d2c0 c11c63e0 c118f694 0019 c07ea5d0 ee0d7810 [3.958430] 7e20: c118f694 c07f2b0c c120f55c ee0d7810 c120f560 [3.966590] 7e40: c07f08c4 c07f0e8c ee0d7810 c11ba3d0 ee0d7810 c118f694 c07f0e8c [3.974748] 7e60: c1108c48 0001 c0ebc3cc c11c63f8 c11ba3d0 c07f0c08 0001 c07f2f8c [3.982908] 7e80: c118f694 ee297ed4 c07f0e8c c1108c48 0001 c0ebc3cc c11c63f8 [3.991068] 7ea0: c11ba3d0 c07ee8a0 c11ba3d0 ee82686c ee0baf38 bb7ffb78 ee0d7810 ee0d7810 [3.999227] 7ec0: c1108c48 ee0d7844 c118faac c07f05b0 ee0d7810 ee0d7810 0001 bb7ffb78 [4.007389] 7ee0: ee0d7810 ee0d7810 c118fd18 c118faac c11c63e0 c07ef7d0 ee0d7810 c118fa90 [4.015548] 7f00: c118fa90 c07efd68 c118fac8 ee27fe00 eefd9c80 eefdcd00 c118facc [4.023708] 7f20: c033c038 eefd9c80 eefd9c80 0008 ee27fe00 ee27fe14 eefd9c80 [4.031866] 7f40: 0008 c1103d00 eefd9c98 ee296000 eefd9c80 c033ce54 ee907eac c0b1d230 [4.040026] 7f60: ee907eac eea24440 ee285000 ee296000 ee27fe00 c033ce24 eea2445c [4.048188] 7f80: ee907eac c0341db0 ee285000 c0341c8c [4.056346] 7fa0: c03010e8 [4.064505] 7fc0: [4.072665] 7fe0: 0013 [4.080828] [] (msm_gem_map_vma) from [] (msm_gem_get_and_pin_iova+0xd8/0x134) [4.088983] [] (msm_gem_get_and_pin_iova) from [] (_msm_gem_kernel_new+0x38/0xac) [4.097839] [] (_msm_gem_kernel_new) from [] (msm_gem_kernel_new+0x24/0x2c) [4.107130] [] (msm_gem_kernel_new) from [] (dsi_tx_buf_alloc_6g+0x44/0x90) [4.115631] [] (dsi_tx_buf_alloc_6g) from [] (msm_dsi_host_modeset_init+0x80/0x104) [4.124313] [] (msm_dsi_host_modeset_init) from [] (msm_dsi_modeset_init+0x34/0x1c0) [4.133691] [] (msm_dsi_modeset_init) from [] (mdp5_kms_init+0x764/0x7e0) [4.143409] [] (mdp5_kms_init) from [] (msm_drm_bind+0x56c/0x740) [4.151824] [] (msm_drm_bind) from []
[PATCH v3 4/4] dt-bindings: display: rockchip: add document for rk3066 hdmi
This patch adds a binding that describes the HDMI controller for
rk3066.
Signed-off-by: Johan Jonker
---
.../bindings/display/rockchip/rk3066-hdmi.txt | 72 ++
1 file changed, 72 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/rockchip/rk3066-hdmi.txt
diff --git a/Documentation/devicetree/bindings/display/rockchip/rk3066-hdmi.txt
b/Documentation/devicetree/bindings/display/rockchip/rk3066-hdmi.txt
new file mode 100644
index 0..d1ad31bca
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/rk3066-hdmi.txt
@@ -0,0 +1,72 @@
+Rockchip specific extensions for rk3066 HDMI
+
+
+Required properties:
+- compatible:
+ "rockchip,rk3066-hdmi";
+- reg:
+ Physical base address and length of the controller's registers.
+- clocks, clock-names:
+ Phandle to HDMI controller clock, name should be "hclk".
+- interrupts:
+ HDMI interrupt number.
+- power-domains:
+ Phandle to the RK3066_PD_VIO power domain.
+- rockchip,grf:
+ This soc uses GRF regs to switch the HDMI TX input between vop0 and
vop1.
+- ports:
+ Contains one port node with two endpoints, numbered 0 and 1,
+ connected respectively to vop0 and vop1.
+ Contains one port node with one endpoint
+ connected to a hdmi-connector node.
+- pinctrl-0, pinctrl-name:
+ Switch the iomux for the HPD/I2C pins to HDMI function.
+
+Example:
+ hdmi: hdmi@10116000 {
+ compatible = "rockchip,rk3066-hdmi";
+ reg = <0x10116000 0x2000>;
+ interrupts = ;
+ clocks = < HCLK_HDMI>;
+ clock-names = "hclk";
+ power-domains = < RK3066_PD_VIO>;
+ rockchip,grf = <>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_xfer>, <_hpd>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ hdmi_in: port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ hdmi_in_vop0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <_out_hdmi>;
+ };
+ hdmi_in_vop1: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <_out_hdmi>;
+ };
+ };
+ hdmi_out: port@1 {
+ reg = <1>;
+ hdmi_out_con: endpoint {
+ remote-endpoint = <_con_in>;
+ };
+ };
+ };
+ };
+
+ {
+ hdmi {
+ hdmi_hpd: hdmi-hpd {
+ rockchip,pins = <0 RK_PA0 1 _pull_default>;
+ };
+ hdmii2c_xfer: hdmii2c-xfer {
+ rockchip,pins = <0 RK_PA1 1 _pull_none>,
+ <0 RK_PA2 1 _pull_none>;
+ };
+ };
+};
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/panel: simple: Add Sharp LS020B1DD01D panel support
Hi,
Le ven. 1 mars 2019 à 19:24, Sam Ravnborg a écrit :
Hi Paul.
On Thu, Feb 28, 2019 at 03:58:52PM -0300, Paul Cercueil wrote:
The Sharp LS020B1DD01D is a simple 2.0" 240x160 16-bit TFT panel.
Signed-off-by: Paul Cercueil
Tested-by: Artur Rojek
---
drivers/gpu/drm/panel/panel-simple.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 9e8218f6a3f2..3ab604f5477e 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2278,6 +2278,31 @@ static const struct panel_desc
sharp_lq150x1lg11 = {
.bus_format = MEDIA_BUS_FMT_RGB565_1X16,
};
+static const struct display_timing sharp_ls020b1dd01d_timing = {
+ .pixelclock = { 200, 420, 500 },
+ .hactive = { 240, 240, 240 },
+ .hfront_porch = { 66, 66, 66 },
+ .hback_porch = { 1, 1, 1 },
+ .hsync_len = { 1, 1, 1 },
+ .vactive = { 160, 160, 160 },
+ .vfront_porch = { 52, 52, 52 },
+ .vback_porch = { 6, 6, 6 },
+ .vsync_len = { 10, 10, 10 },
+ .flags = DISPLAY_FLAGS_HSYNC_HIGH | DISPLAY_FLAGS_VSYNC_LOW,
+};
+
+static const struct panel_desc sharp_ls020b1dd01d = {
+ .timings = _ls020b1dd01d_timing,
+ .num_timings = 1,
+ .bpc = 6,
+ .size = {
+ .width = 42,
+ .height = 28,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB565_1X16,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_NEGEDGE,
+};
+
static const struct drm_display_mode shelly_sca07010_bfn_lnn_mode
= {
.clock = 33300,
.hdisplay = 800,
@@ -2767,6 +2792,9 @@ static const struct of_device_id
platform_of_match[] = {
.compatible = "sharp,lq150x1lg11",
.data = _lq150x1lg11,
}, {
+ .compatible = "sharp,ls020b1dd01d",
+ .data = _ls020b1dd01d,
+ }, {
For all three patches I am missing dt-bindings documentation.
Yes, I looked at
Documentation/devicetree/bindings/display/panel/simple-panel.txt,
and saw that it was never documented with new compatible strings, so I
thought
that for this driver it wasn't needed. I didn't see the other files.
I'll add
the dt-bindings doc in V2.
also for all three patches you get a "+1" for adding all of
.flags, .bus_format, .bus_flags.
Sam
Thanks,
-Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/4] drm: rockchip: introduce rk3066 hdmi
From: Zheng Yang
Introduce rk3066 hdmi.
Signed-off-by: Zheng Yang
Signed-off-by: Johan Jonker
---
drivers/gpu/drm/rockchip/Kconfig| 8 +
drivers/gpu/drm/rockchip/Makefile | 1 +
drivers/gpu/drm/rockchip/rk3066_hdmi.c | 911
drivers/gpu/drm/rockchip/rk3066_hdmi.h | 226 +++
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +
drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 1 +
6 files changed, 1149 insertions(+)
create mode 100644 drivers/gpu/drm/rockchip/rk3066_hdmi.c
create mode 100644 drivers/gpu/drm/rockchip/rk3066_hdmi.h
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 1e75196f9..2cdf3b62d 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -77,4 +77,12 @@ config ROCKCHIP_RGB
Some Rockchip CRTCs, like rv1108, can directly output parallel
and serial RGB format to panel or connect to a conversion chip.
say Y to enable its driver.
+
+config ROCKCHIP_RK3066_HDMI
+ bool "Rockchip specific extensions for RK3066 HDMI"
+ depends on DRM_ROCKCHIP
+ help
+ This selects support for Rockchip SoC specific extensions
+ for the RK3066 HDMI driver. If you want to enable
+ HDMI on RK3066 based SoC, you should select this option.
endif
diff --git a/drivers/gpu/drm/rockchip/Makefile
b/drivers/gpu/drm/rockchip/Makefile
index f6fc9d5dd..524684ba7 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -15,5 +15,6 @@ rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) +=
dw-mipi-dsi-rockchip.o
rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
rockchipdrm-$(CONFIG_ROCKCHIP_LVDS) += rockchip_lvds.o
rockchipdrm-$(CONFIG_ROCKCHIP_RGB) += rockchip_rgb.o
+rockchipdrm-$(CONFIG_ROCKCHIP_RK3066_HDMI) += rk3066_hdmi.o
obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o
diff --git a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
new file mode 100644
index 0..3c5b702dc
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
@@ -0,0 +1,911 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ *Zheng Yang
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+
+#include "rk3066_hdmi.h"
+
+#define DEFAULT_PLLA_RATE 3000
+
+struct hdmi_data_info {
+ int vic;
+ bool sink_is_hdmi;
+ unsigned int enc_in_format;
+ unsigned int enc_out_format;
+ unsigned int colorimetry;
+};
+
+struct rk3066_hdmi_i2c {
+ struct i2c_adapter adap;
+
+ u8 ddc_addr;
+ u8 segment_addr;
+ u8 stat;
+
+ struct mutex lock; /*for i2c operation*/
+ struct completion cmp;
+};
+
+struct rk3066_hdmi {
+ struct device *dev;
+ struct drm_device *drm_dev;
+ struct regmap *regmap;
+ int irq;
+ struct clk *hclk;
+ void __iomem *regs;
+
+ struct drm_connector connector;
+ struct drm_encoder encoder;
+
+ struct rk3066_hdmi_i2c *i2c;
+ struct i2c_adapter *ddc;
+
+ unsigned int tmdsclk;
+
+ struct hdmi_data_info hdmi_data;
+ struct drm_display_mode previous_mode;
+};
+
+#define to_rk3066_hdmi(x) container_of(x, struct rk3066_hdmi, x)
+
+static inline u8 hdmi_readb(struct rk3066_hdmi *hdmi, u16 offset)
+{
+ return readl_relaxed(hdmi->regs + offset);
+}
+
+static inline void hdmi_writeb(struct rk3066_hdmi *hdmi, u16 offset, u32 val)
+{
+ writel_relaxed(val, hdmi->regs + offset);
+}
+
+static inline void hdmi_modb(struct rk3066_hdmi *hdmi, u16 offset,
+u32 msk, u32 val)
+{
+ u8 temp = hdmi_readb(hdmi, offset) & ~msk;
+
+ temp |= val & msk;
+ hdmi_writeb(hdmi, offset, temp);
+}
+
+static void rk3066_hdmi_i2c_init(struct rk3066_hdmi *hdmi)
+{
+ int ddc_bus_freq;
+
+ ddc_bus_freq = (hdmi->tmdsclk >> 2) / HDMI_SCL_RATE;
+
+ hdmi_writeb(hdmi, HDMI_DDC_BUS_FREQ_L, ddc_bus_freq & 0xFF);
+ hdmi_writeb(hdmi, HDMI_DDC_BUS_FREQ_H, (ddc_bus_freq >> 8) & 0xFF);
+
+ /* Clear the EDID interrupt flag and mute the interrupt */
+ hdmi_modb(hdmi, HDMI_INTR_MASK1, HDMI_INTR_EDID_MASK, 0);
+ hdmi_writeb(hdmi, HDMI_INTR_STATUS1, HDMI_INTR_EDID_MASK);
+}
+
+static inline u8 rk3066_hdmi_get_power_mode(struct rk3066_hdmi *hdmi)
+{
+ return hdmi_readb(hdmi, HDMI_SYS_CTRL) & HDMI_SYS_POWER_MODE_MASK;
+}
+
+static void rk3066_hdmi_set_power_mode(struct rk3066_hdmi *hdmi, int mode)
+{
+ u8 current_mode, next_mode;
+ u8 i = 0;
+
+ current_mode = rk3066_hdmi_get_power_mode(hdmi);
+
+ dev_dbg(hdmi->dev, "mode :%d\n", mode);
+ dev_dbg(hdmi->dev, "current_mode :%d\n", current_mode);
+
+ if (current_mode == mode)
+ return;
+
+ do {
+ if (current_mode > mode)
+
[PATCH] drm/vkms: Add overlay plane support
Add overlay plane support in vkms aligned with cursor and primary
plane with module option 'enable_overlay' to enable/disable overlay
plane while testing.
This currently passes plane-position-covered-pipe-A-plane subtest
from IGT kms_plane test.
Signed-off-by: Mamta Shukla
---
drivers/gpu/drm/vkms/vkms_crc.c | 36 +++
drivers/gpu/drm/vkms/vkms_drv.c | 4
drivers/gpu/drm/vkms/vkms_drv.h | 8 +++
drivers/gpu/drm/vkms/vkms_plane.c | 36 ++-
4 files changed, 79 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_crc.c b/drivers/gpu/drm/vkms/vkms_crc.c
index 5135642fb204..a07c50484b3d 100644
--- a/drivers/gpu/drm/vkms/vkms_crc.c
+++ b/drivers/gpu/drm/vkms/vkms_crc.c
@@ -108,6 +108,25 @@ static void blend(void *vaddr_dst, void *vaddr_src,
}
}
+static void compose_overlay(struct vkms_crc_data *overlay_crc,
+ struct vkms_crc_data *primary_crc, void *vaddr_out)
{
+ struct drm_gem_object *overlay_obj;
+ struct vkms_gem_object *overlay_vkms_obj;
+
+ overlay_obj = drm_gem_fb_get_obj(_crc->fb, 0);
+ overlay_vkms_obj = drm_gem_to_vkms_gem(overlay_obj);
+ mutex_lock(_vkms_obj->pages_lock);
+ if(!overlay_vkms_obj->vaddr){
+ DRM_WARN("overlay palne vaddr is NULL");
+ goto out;
+ }
+
+ blend(vaddr_out, overlay_vkms_obj->vaddr, primary_crc, overlay_crc);
+
+out:
+ mutex_unlock(_vkms_obj->pages_lock);
+}
+
static void compose_cursor(struct vkms_crc_data *cursor_crc,
struct vkms_crc_data *primary_crc, void *vaddr_out)
{
@@ -130,7 +149,8 @@ static void compose_cursor(struct vkms_crc_data *cursor_crc,
}
static uint32_t _vkms_get_crc(struct vkms_crc_data *primary_crc,
- struct vkms_crc_data *cursor_crc)
+ struct vkms_crc_data *cursor_crc,
+ struct vkms_crc_data *overlay_crc)
{
struct drm_framebuffer *fb = _crc->fb;
struct drm_gem_object *gem_obj = drm_gem_fb_get_obj(fb, 0);
@@ -153,6 +173,8 @@ static uint32_t _vkms_get_crc(struct vkms_crc_data
*primary_crc,
memcpy(vaddr_out, vkms_obj->vaddr, vkms_obj->gem.size);
mutex_unlock(_obj->pages_lock);
+ if (overlay_crc)
+ compose_overlay(overlay_crc, primary_crc, vaddr_out);
if (cursor_crc)
compose_cursor(cursor_crc, primary_crc, vaddr_out);
@@ -183,6 +205,7 @@ void vkms_crc_work_handle(struct work_struct *work)
output);
struct vkms_crc_data *primary_crc = NULL;
struct vkms_crc_data *cursor_crc = NULL;
+ struct vkms_crc_data *overlay_crc = NULL;
struct drm_plane *plane;
u32 crc32 = 0;
u64 frame_start, frame_end;
@@ -209,12 +232,17 @@ void vkms_crc_work_handle(struct work_struct *work)
if (plane->type == DRM_PLANE_TYPE_PRIMARY)
primary_crc = crc_data;
- else
+
+ if (plane->type == DRM_PLANE_TYPE_CURSOR)
cursor_crc = crc_data;
+
+ if (plane->type == DRM_PLANE_TYPE_OVERLAY)
+ overlay_crc = crc_data;
}
- if (primary_crc)
- crc32 = _vkms_get_crc(primary_crc, cursor_crc);
+ if (primary_crc){
+ crc32 = _vkms_get_crc(primary_crc, cursor_crc, overlay_crc);
+ }
frame_end = drm_crtc_accurate_vblank_count(crtc);
diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index b13f99a5c849..90b730b6aa0e 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -34,6 +34,10 @@ bool enable_cursor;
module_param_named(enable_cursor, enable_cursor, bool, 0444);
MODULE_PARM_DESC(enable_cursor, "Enable/Disable cursor support");
+bool enable_overlay;
+module_param_named(enable_overlay, enable_overlay, bool, 0444);
+MODULE_PARM_DESC(enable_overlay, "Enable/Disable overlay support");
+
static const struct file_operations vkms_driver_fops = {
.owner = THIS_MODULE,
.open = drm_open,
diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
index e4469cd3d254..4b1ef94e5bf8 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.h
+++ b/drivers/gpu/drm/vkms/vkms_drv.h
@@ -18,6 +18,8 @@
extern bool enable_cursor;
+extern bool enable_overlay;
+
static const u32 vkms_formats[] = {
DRM_FORMAT_XRGB,
};
@@ -26,6 +28,10 @@ static const u32 vkms_cursor_formats[] = {
DRM_FORMAT_ARGB,
};
+static const u32 vkms_overlay_formats[] ={
+ DRM_FORMAT_ARGB,
+};
+
struct vkms_crc_data {
struct drm_framebuffer fb;
struct drm_rect src, dst;
@@ -116,6 +122,8 @@ int vkms_output_init(struct vkms_device *vkmsdev);
struct drm_plane *vkms_plane_init(struct vkms_device *vkmsdev,
Re: [PATCH 0/7] add LCD support for SAM9X60
On 28.02.2019 23:13, Sam Ravnborg wrote: > Hi Alexandre. > These patches adds support for SAM9X60's LCD controller. >>> Can you elaborate a little more which chips that are relevant. >>> To be able to look into the right data-sheet, while reviewing. >>> Link to data-sheet would be nice too. >>> >> >> sam9x60 is the chip name (i.e. x is not a wildcard). I don't think the >> datasheet is finished/public yet. > > Thanks. I will take a look at the patches but not knowing > the specifics of the implementation/IP will makes this less valueable. At this moment, as Alexandre specified, the datasheet is not published. Thank you, Claudiu Beznea > > Sam > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] omapfb: Fix potential NULL pointer dereference in kmalloc
Memory allocated, using kmalloc, for new_compat may fail. This patch checks for such an error and prevents potential NULL pointer dereference. Signed-off-by: Aditya Pakki --- drivers/video/fbdev/omap2/omapfb/dss/omapdss-boot-init.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/video/fbdev/omap2/omapfb/dss/omapdss-boot-init.c b/drivers/video/fbdev/omap2/omapfb/dss/omapdss-boot-init.c index 136d30484d02..0592c436b2da 100644 --- a/drivers/video/fbdev/omap2/omapfb/dss/omapdss-boot-init.c +++ b/drivers/video/fbdev/omap2/omapfb/dss/omapdss-boot-init.c @@ -111,6 +111,8 @@ static void __init omapdss_omapify_node(struct device_node *node) new_len = prop->length + strlen(prefix) * num_strs; new_compat = kmalloc(new_len, GFP_KERNEL); + if (!new_compat) + return; omapdss_prefix_strcpy(new_compat, new_len, prop->value, prop->length); -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/4] ARM: dts: rockchip: add rk3066 hdmi nodes
From: Zheng Yang
This patch adds the hdmi nodes to rk3066.
Signed-off-by: Zheng Yang
Signed-off-by: Johan Jonker
---
arch/arm/boot/dts/rk3066a.dtsi | 52 ++
1 file changed, 52 insertions(+)
diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
index 653127a37..9c43b985a 100644
--- a/arch/arm/boot/dts/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rk3066a.dtsi
@@ -80,6 +80,10 @@
vop0_out: port {
#address-cells = <1>;
#size-cells = <0>;
+ vop0_out_hdmi: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <_in_vop0>;
+ };
};
};
@@ -101,6 +105,44 @@
vop1_out: port {
#address-cells = <1>;
#size-cells = <0>;
+ vop1_out_hdmi: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <_in_vop1>;
+ };
+ };
+ };
+
+ hdmi: hdmi@10116000 {
+ compatible = "rockchip,rk3066-hdmi";
+ reg = <0x10116000 0x2000>;
+ interrupts = ;
+ clocks = < HCLK_HDMI>;
+ clock-names = "hclk";
+ power-domains = < RK3066_PD_VIO>;
+ rockchip,grf = <>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_xfer>, <_hpd>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ hdmi_in: port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ hdmi_in_vop0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <_out_hdmi>;
+ };
+ hdmi_in_vop1: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <_out_hdmi>;
+ };
+ };
+ hdmi_out: port@1 {
+ reg = <1>;
+ };
};
};
@@ -415,6 +457,16 @@
};
};
+ hdmi {
+ hdmi_hpd: hdmi-hpd {
+ rockchip,pins = <0 RK_PA0 1 _pull_default>;
+ };
+ hdmii2c_xfer: hdmii2c-xfer {
+ rockchip,pins = <0 RK_PA1 1 _pull_none>,
+ <0 RK_PA2 1 _pull_none>;
+ };
+ };
+
pwm0 {
pwm0_out: pwm0-out {
rockchip,pins = ;
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/4] Enable rk3066 VOP and HDMI for MK808
Version: V3 Title: Enable rk3066 VOP and HDMI for MK808. This patch serie only works in combination with a MK808 TV stick and a rk3066 processor. Other boxes and tablets with a rk3066 need extra software for power management and lcd's. What does it do: With these kernel patches a MK808 can show 2 penguins and a console on a DVI-D monitor in combination with a framebuffer. Not tested: HDMI TV DRM Xorg Display managers Android etc. Problems: DRM functions keep changing every rc With v5.0-rc8 the monitor doesn't blank on poweroff, it freezes Fixed screen size for DVI-D. HDMI sound not included. etc. /// Changes V2 > V3: updated to v5.0-rc8 removed patches that are already added to linux-next rk3066_hdmi.c removed gpl text small style changes removed unused includes add include for: drm_helper_hpd_irq_event drm_helper_probe_single_connector_modes update drm_hdmi_avi_infoframe_from_display_mode function call rk3066_hdmi.h removed gpl text rk3066a.dtsi add extra port for hdmi connector node rk3066a-mk808.dts add hdmi connector node connect hdmi_out with hdmi_con_in rk3066-hdmi.txt add extra port for hdmi connector node /// # How to make rkfs.cpio find . | cpio -o --format=newc > ../rkfs.cpio # How to compile/flash make menuconfig ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- make -j4 ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- cp ./arch/arm/boot/zImage ../zImage-dtb cat ./arch/arm/boot/dts/rk3066a-mk808.dtb >> ../zImage-dtb ../tools/rkcrc -k ../zImage-dtb ../mk808.img sudo ../tools/rkflashtool w 0x4000 0x8000 < ../mk808.img sudo ../tools/rkflashtool b /// Johan Jonker (2): ARM: dts: rockchip: rk3066a-mk808: enable vop0 and hdmi nodes dt-bindings: display: rockchip: add document for rk3066 hdmi Zheng Yang (2): drm: rockchip: introduce rk3066 hdmi ARM: dts: rockchip: add rk3066 hdmi nodes .../bindings/display/rockchip/rk3066-hdmi.txt | 72 ++ arch/arm/boot/dts/rk3066a-mk808.dts| 29 + arch/arm/boot/dts/rk3066a.dtsi | 52 ++ drivers/gpu/drm/rockchip/Kconfig | 8 + drivers/gpu/drm/rockchip/Makefile | 1 + drivers/gpu/drm/rockchip/rk3066_hdmi.c | 911 + drivers/gpu/drm/rockchip/rk3066_hdmi.h | 226 + drivers/gpu/drm/rockchip/rockchip_drm_drv.c| 2 + drivers/gpu/drm/rockchip/rockchip_drm_drv.h| 1 + 9 files changed, 1302 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/rockchip/rk3066-hdmi.txt create mode 100644 drivers/gpu/drm/rockchip/rk3066_hdmi.c create mode 100644 drivers/gpu/drm/rockchip/rk3066_hdmi.h -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/7] drm: atmel-hlcdc: add config option for clock selection
On 28.02.2019 23:38, Sam Ravnborg wrote:
> Hi Claudiu
>
> One more reply to this patch...
>
> On Wed, Feb 27, 2019 at 04:24:16PM +, claudiu.bez...@microchip.com wrote:
>> From: Claudiu Beznea
>>
>> SAM9x60 LCD Controller has no option to select clock source as previous
>> controllers have. To be able to use the same driver even for this LCD
>> controller add a config option to know if controller supports this.
>>
>> Signed-off-by: Claudiu Beznea
>> ---
>> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 12 +++-
>> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 2 ++
>> 2 files changed, 9 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
>> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
>> index 8070a558d7b1..17a7a18f6a07 100644
>> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
>> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
>> @@ -78,7 +78,8 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct drm_crtc
>> *c)
>> unsigned long mode_rate;
>> struct videomode vm;
>> unsigned long prate;
>> -unsigned int cfg;
>> +unsigned int mask = ATMEL_HLCDC_CLKDIV_MASK | ATMEL_HLCDC_CLKPOL;
>> +unsigned int cfg = 0;
>> int div;
>>
>> vm.vfront_porch = adj->crtc_vsync_start - adj->crtc_vdisplay;
>> @@ -101,7 +102,10 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct
>> drm_crtc *c)
>> (adj->crtc_hdisplay - 1) |
>> ((adj->crtc_vdisplay - 1) << 16));
>>
>> -cfg = ATMEL_HLCDC_CLKSEL;
>> +if (!crtc->dc->desc->fixed_clksrc) {
>> +cfg = ATMEL_HLCDC_CLKSEL;
>> +mask |= ATMEL_HLCDC_CLKSEL;
>> +}
> Maybe this is just too late to look at code, but I do not get this.
> If the sam9x60 do not support selecting the clk rate then I assume it is
> either
> fixed to used system clock or 2 x system clock.
SAM9X60's LCD controller has no support for selecting clock source (and for
the moment, yes, as Alexandre specified, the datasheet is not public). If
you look at e.g. SAM9X35 datasheet , chapter 45.7, at LCD Controller
Configuration Register 0 [1], you will see this CLKSEL bit. On SAM9X60 you
don't have this option, but you have only one clock source, fixed one. You
still have the option to divide this clock to get LCD pixel clock using
CLKDIV field of LCD Controller Configuration Register 0, and the formula is
the same as in SAM9X35 case: the only difference is that the formula uses
the fixed clock in case of SAM9X60 apart from SAM9X35 which uses the
selected clock:
SAM9X60: LCDPCLK = source clock / (CLKDIV+2)
SAM9X35: pixel_clock = selected_clock / (CLKDIV + 2).
[1]
http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-11055-32-bit-ARM926EJ-S-Microcontroller-SAM9X35_Datasheet.pdf#G38.1471048
>
> And we have in the driver code to adjust the "div" value.
> The value of div depends on the CLKSEL configuration, so there must
> be one part of this that is not valid when fixed_clksrc is true.
When fixed_clksrc is true you still have to option to divide the source clock.
I hope I was clear.
>
>>
>> prate = 2 * clk_get_rate(crtc->dc->hlcdc->sys_clk);
>> mode_rate = adj->crtc_clock * 1000;
>> @@ -132,9 +136,7 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct
>> drm_crtc *c)
>>
>> cfg |= ATMEL_HLCDC_CLKDIV(div);
>
> It is the following code (not visible in this patch I talk about:
>if (div < 2) {
> div = 2;
> } else if (ATMEL_HLCDC_CLKDIV(div) & ~ATMEL_HLCDC_CLKDIV_MASK) {
> /* The divider ended up too big, try a lower base rate. */
> cfg &= ~ATMEL_HLCDC_CLKSEL;
> prate /= 2;
> div = DIV_ROUND_UP(prate, mode_rate);
> if (ATMEL_HLCDC_CLKDIV(div) & ~ATMEL_HLCDC_CLKDIV_MASK)
> div = ATMEL_HLCDC_CLKDIV_MASK;
> } else {
> int div_low = prate / mode_rate;
>
> if (div_low >= 2 &&
> ((prate / div_low - mode_rate) <
> 10 * (mode_rate - prate / div)))
> /*
> * At least 10 times better when using a higher
> * frequency than requested, instead of a lower.
> * So, go with that.
> */
> div = div_low;
> }
>
> Am I missing something obvious?
>
>> -regmap_update_bits(regmap, ATMEL_HLCDC_CFG(0),
>> - ATMEL_HLCDC_CLKSEL | ATMEL_HLCDC_CLKDIV_MASK |
>> - ATMEL_HLCDC_CLKPOL, cfg);
>> +regmap_update_bits(regmap, ATMEL_HLCDC_CFG(0), mask, cfg);
>>
>> cfg = 0;
>>
>> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
>> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
>> index 70bd540d644e..0155efb9c443 100644
>> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
>> +++
Re: [PATCH 1/7] drm: atmel-hlcdc: add config option for clock selection
On 28.02.2019 23:25, Sam Ravnborg wrote:
> Hi Claudiu
>
> On Wed, Feb 27, 2019 at 04:24:16PM +, claudiu.bez...@microchip.com wrote:
>> From: Claudiu Beznea
>>
>> SAM9x60 LCD Controller has no option to select clock source as previous
>> controllers have. To be able to use the same driver even for this LCD
>> controller add a config option to know if controller supports this.
>>
>> Signed-off-by: Claudiu Beznea
>> ---
>> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 12 +++-
>> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 2 ++
>> 2 files changed, 9 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
>> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
>> index 8070a558d7b1..17a7a18f6a07 100644
>> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
>> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
>> @@ -78,7 +78,8 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct drm_crtc
>> *c)
>> unsigned long mode_rate;
>> struct videomode vm;
>> unsigned long prate;
>> -unsigned int cfg;
>> +unsigned int mask = ATMEL_HLCDC_CLKDIV_MASK | ATMEL_HLCDC_CLKPOL;
>> +unsigned int cfg = 0;
>> int div;
> Here cfg and mask has initial values.
>
>>
>> vm.vfront_porch = adj->crtc_vsync_start - adj->crtc_vdisplay;
>> @@ -101,7 +102,10 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct
>> drm_crtc *c)
>> (adj->crtc_hdisplay - 1) |
>> ((adj->crtc_vdisplay - 1) << 16));
>>
>> -cfg = ATMEL_HLCDC_CLKSEL;
>> +if (!crtc->dc->desc->fixed_clksrc) {
>> +cfg = ATMEL_HLCDC_CLKSEL;
>> +mask |= ATMEL_HLCDC_CLKSEL;
>> +}
> And here mask is bitwise or with ATMEL_HLCDC_CLKSEL - fine.
> But cfg is directly assigned.
I directly assigned it here because it was the first time it was used.
I will use a "|" operation as you suggest in next version.
> If cfg was bitwise or the ATMEL_HLCDC_CLKSEL value then the code was prepared
> to have extra flags added above these lines.
>
> Only a small change and no functional difference.
>
> With or without this change:
> Reviewed-by: Sam Ravnborg
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] DRM: Add KMS driver for the Ingenic JZ47xx SoCs
Hi Daniel, Le ven. 1 mars 2019 à 5:26, Daniel Vetter a écrit : On Thu, Feb 28, 2019 at 07:07:56PM -0300, Paul Cercueil wrote: Add a KMS driver for the Ingenic JZ47xx family of SoCs. This driver is meant to replace the aging jz4740-fb driver. Signed-off-by: Paul Cercueil Tested-by: Artur Rojek Yay, more fbdev drivers moving to atmic! Going on vacations for a week now, so just a few quick high-level comments below. Those should make the driver even smaller and cleaner. Alright, no problem, there's no rush. --- drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/ingenic/Kconfig | 16 + drivers/gpu/drm/ingenic/Makefile | 1 + drivers/gpu/drm/ingenic/ingenic-drm.c | 896 ++ 5 files changed, 916 insertions(+) create mode 100644 drivers/gpu/drm/ingenic/Kconfig create mode 100644 drivers/gpu/drm/ingenic/Makefile create mode 100644 drivers/gpu/drm/ingenic/ingenic-drm.c diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index bd943a71756c..f1929112e559 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -303,6 +303,8 @@ source "drivers/gpu/drm/sti/Kconfig" source "drivers/gpu/drm/imx/Kconfig" +source "drivers/gpu/drm/ingenic/Kconfig" + source "drivers/gpu/drm/v3d/Kconfig" source "drivers/gpu/drm/vc4/Kconfig" diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 1ac55c65eac0..9666c0767f44 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -94,6 +94,7 @@ obj-$(CONFIG_DRM_TEGRA) += tegra/ obj-$(CONFIG_DRM_STM) += stm/ obj-$(CONFIG_DRM_STI) += sti/ obj-$(CONFIG_DRM_IMX) += imx/ +obj-y += ingenic/ obj-$(CONFIG_DRM_MEDIATEK) += mediatek/ obj-$(CONFIG_DRM_MESON) += meson/ obj-y += i2c/ diff --git a/drivers/gpu/drm/ingenic/Kconfig b/drivers/gpu/drm/ingenic/Kconfig new file mode 100644 index ..d82c3d37ec9c --- /dev/null +++ b/drivers/gpu/drm/ingenic/Kconfig @@ -0,0 +1,16 @@ +config DRM_INGENIC + tristate "DRM Support for Ingenic SoCs" + depends on MIPS || COMPILE_TEST + depends on DRM + depends on CMA + depends on OF + select DRM_BRIDGE + select DRM_PANEL_BRIDGE + select DRM_KMS_HELPER + select DRM_KMS_CMA_HELPER + select DRM_GEM_CMA_HELPER + select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE + help +Choose this option for DRM support for the Ingenic SoCs. + +If M is selected the module will be called ingenic-drm. diff --git a/drivers/gpu/drm/ingenic/Makefile b/drivers/gpu/drm/ingenic/Makefile new file mode 100644 index ..11cac42ce0bb --- /dev/null +++ b/drivers/gpu/drm/ingenic/Makefile @@ -0,0 +1 @@ +obj-$(CONFIG_DRM_INGENIC) += ingenic-drm.o diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c b/drivers/gpu/drm/ingenic/ingenic-drm.c new file mode 100644 index ..18120deea96f --- /dev/null +++ b/drivers/gpu/drm/ingenic/ingenic-drm.c @@ -0,0 +1,896 @@ +// SPDX-License-Identifier: GPL-2.0 +// +// Ingenic JZ47xx KMS driver +// +// Copyright (C) 2019, Paul Cercueil + +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#include "../drm_internal.h" + +#define JZ_REG_LCD_CFG0x00 +#define JZ_REG_LCD_VSYNC 0x04 +#define JZ_REG_LCD_HSYNC 0x08 +#define JZ_REG_LCD_VAT0x0C +#define JZ_REG_LCD_DAH0x10 +#define JZ_REG_LCD_DAV0x14 +#define JZ_REG_LCD_PS 0x18 +#define JZ_REG_LCD_CLS0x1C +#define JZ_REG_LCD_SPL0x20 +#define JZ_REG_LCD_REV0x24 +#define JZ_REG_LCD_CTRL 0x30 +#define JZ_REG_LCD_STATE 0x34 +#define JZ_REG_LCD_IID0x38 +#define JZ_REG_LCD_DA00x40 +#define JZ_REG_LCD_SA00x44 +#define JZ_REG_LCD_FID0 0x48 +#define JZ_REG_LCD_CMD0 0x4C +#define JZ_REG_LCD_DA10x50 +#define JZ_REG_LCD_SA10x54 +#define JZ_REG_LCD_FID1 0x58 +#define JZ_REG_LCD_CMD1 0x5C + +#define JZ_LCD_CFG_SLCD BIT(31) +#define JZ_LCD_CFG_PS_DISABLE BIT(23) +#define JZ_LCD_CFG_CLS_DISABLEBIT(22) +#define JZ_LCD_CFG_SPL_DISABLEBIT(21) +#define JZ_LCD_CFG_REV_DISABLEBIT(20) +#define JZ_LCD_CFG_HSYNCM BIT(19) +#define JZ_LCD_CFG_PCLKM BIT(18) +#define JZ_LCD_CFG_INVBIT(17) +#define JZ_LCD_CFG_SYNC_DIR BIT(16) +#define JZ_LCD_CFG_PS_POLARITYBIT(15) +#define
Re: [PATCH 1/3] dt-bindings: Add doc for the ingenic-drm driver
Hi Sam, thanks for the feedback. Le ven. 1 mars 2019 à 17:16, Sam Ravnborg a écrit : Hi Paul. Good to see work migrating fbdev => drm. Following comments is based on experience while working on migrating another driver from fbdev => drm. On Thu, Feb 28, 2019 at 07:07:54PM -0300, Paul Cercueil wrote: Add documentation for the devicetree bindings of the DRM driver for the JZ47xx family of SoCs from Ingenic. Signed-off-by: Paul Cercueil Tested-by: Artur Rojek --- .../devicetree/bindings/display/ingenic,drm.txt| 30 ++ 1 file changed, 30 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/ingenic,drm.txt diff --git a/Documentation/devicetree/bindings/display/ingenic,drm.txt b/Documentation/devicetree/bindings/display/ingenic,drm.txt new file mode 100644 index ..52a368ec35cd --- /dev/null +++ b/Documentation/devicetree/bindings/display/ingenic,drm.txt @@ -0,0 +1,30 @@ +Ingenic JZ47xx DRM driver + +Required properties: +- compatible: one of: + * ingenic,jz4740-drm + * ingenic,jz4725b-drm +- reg: LCD registers location and length The fbdev way of doing this was to hardcode register setttings. In the drm world we read the configuration of the panel and let this decide the actual configuration. Note that no drm drivers supports stn displays and that there is really no use for this these days. So you can skip the STN parts. STN panels aren't really my problem; but I have a board with a Sharp LS020B1DD01D panel, which requires the LCD IP to be configured for a "special 2" panel. I also have a board with a "smart" panel (ili9331) that needs a special configuration in the IP. There is nothing in the drm_panel interface that tells me what mode I should use for what panel... Also the modern way to specify a panel in the DT is using OF graph bindings. You can find many examples how to do this. Ok, I was looking at the Tegra driver, which uses a "nvidia,panel" DT property. I will change it to use the graph thing. I was there with the atmel LCDC driver (not in the kernel yet), and had some challenges with this. Sam Thanks, -Paul ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v1 09/15] drm/msm/gpu: Move address space setup to the GPU targets
There is an error in the a2xx part of this patch: 0xfff in adreno_gpu.c
became 0xff in a2xx_gpu.c
On 3/1/19 2:38 PM, Jordan Crouse wrote:
Move the address space steup code out of the generic msm GPU code to
to the individual GPU targets. This allows us to do target specific
setup such as gpummu for a2xx or split pagetables and per-instance
pagetables for newer a5xx and a6xx targets. All this is at the
expense of duplicated code in some of the target files but I think
it pays for itself in improved code flow and flexibility.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a2xx_gpu.c | 37 --
drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 50 ++
drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 51 +++
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 37 +++---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 37 +++---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 7 -
drivers/gpu/drm/msm/msm_gem.h | 1 +
drivers/gpu/drm/msm/msm_gpu.c | 54 ++---
drivers/gpu/drm/msm/msm_gpu.h | 2 ++
9 files changed, 173 insertions(+), 103 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
index 1f83bc1..49241d0 100644
--- a/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
@@ -401,6 +401,30 @@ static struct msm_gpu_state *a2xx_gpu_state_get(struct
msm_gpu *gpu)
return state;
}
+static struct msm_gem_address_space *
+a2xx_create_address_space(struct msm_gpu *gpu)
+{
+ struct msm_gem_address_space *aspace;
+ int ret;
+
+ aspace = msm_gem_address_space_create_a2xx(>pdev->dev, gpu,
+ "gpu", SZ_16M, SZ_16M + 0xff * SZ_64K);
+ if (IS_ERR(aspace)) {
+ DRM_DEV_ERROR(gpu->dev->dev,
+ "No memory protection without MMU\n");
+ return ERR_PTR(-ENXIO);
+ }
+
+ ret = aspace->mmu->funcs->attach(aspace->mmu, NULL, 0);
+ if (ret) {
+ msm_gem_address_space_put(aspace);
+ return ERR_PTR(ret);
+ }
+
+ return aspace;
+}
+
+
/* Register offset defines for A2XX - copy of A3XX */
static const unsigned int a2xx_register_offsets[REG_ADRENO_REGISTER_MAX] = {
REG_ADRENO_DEFINE(REG_ADRENO_CP_RB_BASE, REG_AXXX_CP_RB_BASE),
@@ -429,6 +453,7 @@ static const struct adreno_gpu_funcs funcs = {
#endif
.gpu_state_get = a2xx_gpu_state_get,
.gpu_state_put = adreno_gpu_state_put,
+ .create_address_space = a2xx_create_address_space,
},
};
@@ -473,16 +498,8 @@ struct msm_gpu *a2xx_gpu_init(struct drm_device *dev)
adreno_gpu->reg_offsets = a2xx_register_offsets;
ret = adreno_gpu_init(dev, pdev, adreno_gpu, , 1);
- if (ret)
- goto fail;
-
- if (!gpu->aspace) {
- dev_err(dev->dev, "No memory protection without MMU\n");
- ret = -ENXIO;
- goto fail;
- }
-
- return gpu;
+ if (!ret)
+ return gpu;
fail:
if (a2xx_gpu)
diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index c3b4bc6..33ab5e8 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -21,6 +21,7 @@
# include
#endif
+#include "msm_gem.h"
#include "a3xx_gpu.h"
#define A3XX_INT0_MASK \
@@ -433,6 +434,41 @@ static struct msm_gpu_state *a3xx_gpu_state_get(struct
msm_gpu *gpu)
return state;
}
+static struct msm_gem_address_space *
+a3xx_create_address_space(struct msm_gpu *gpu)
+{
+ struct msm_gem_address_space *aspace;
+ struct iommu_domain *iommu;
+ int ret;
+
+ iommu = iommu_domain_alloc(_bus_type);
+ if (!iommu) {
+ DRM_DEV_ERROR(gpu->dev->dev,
+ "No memory protection without IOMMU\n");
+ return ERR_PTR(-ENXIO);
+ }
+
+ iommu->geometry.aperture_start = SZ_16M;
+ iommu->geometry.aperture_end = 0x;
+
+ aspace = msm_gem_address_space_create(>pdev->dev, iommu, "gpu");
+ if (IS_ERR(aspace)) {
+ iommu_domain_free(iommu);
+ DRM_DEV_ERROR(gpu->dev->dev, "failed to init mmu: %ld\n",
+ PTR_ERR(aspace));
+ return aspace;
+ }
+
+ ret = aspace->mmu->funcs->attach(aspace->mmu, NULL, 0);
+ if (ret) {
+ msm_gem_address_space_put(aspace);
+ return ERR_PTR(ret);
+ }
+
+ return aspace;
+}
+
+
/* Register offset defines for A3XX */
static const unsigned int a3xx_register_offsets[REG_ADRENO_REGISTER_MAX] = {
REG_ADRENO_DEFINE(REG_ADRENO_CP_RB_BASE, REG_AXXX_CP_RB_BASE),
@@ -461,6 +497,7 @@ static const struct adreno_gpu_funcs funcs = {
#endif
Re: [PATCH v3 1/7] dt-bindings: interconnect: Add a dma interconnect name
Hi Maxime, On 2/11/19 17:02, Maxime Ripard wrote: > The current DT bindings assume that the DMA will be performed by the > devices through their parent DT node, and rely on that assumption for the > address translation using dma-ranges. > > However, some SoCs have devices that will perform DMA through another bus, > with separate address translation rules. We therefore need to express that > relationship, through the special interconnect name "dma". > > Signed-off-by: Maxime Ripard > --- > Documentation/devicetree/bindings/interconnect/interconnect.txt | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/Documentation/devicetree/bindings/interconnect/interconnect.txt > b/Documentation/devicetree/bindings/interconnect/interconnect.txt > index 5a3c575b387a..e69fc2d992c3 100644 > --- a/Documentation/devicetree/bindings/interconnect/interconnect.txt > +++ b/Documentation/devicetree/bindings/interconnect/interconnect.txt > @@ -51,6 +51,9 @@ interconnect-names : List of interconnect path name strings > sorted in the same >interconnect-names to match interconnect paths with > interconnect >specifier pairs. > > + Reserved interconnect names: > + * dma: Path from the device to the main memory of > the system Bikeshed: As it's from the device to the main memory, maybe here we can also denote this my calling the path dma-mem or dma-memory. For other paths, we are trying to mention both the source and the destination and maybe it would be good to be consistent although this is special one. Thanks, Georgi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] fbdev: omap2: omapfb: trivial code cleanup
On 2019/3/1 22:50, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On 03/01/2019 02:53 AM, Yue Haibing wrote:
>> From: YueHaibing
>>
>> After commit 60d2fa0dad06 ("fbdev: omap2: no need to check
>> return value of debugfs_create functions"), there are corner
>> code need to be cleaned.
>>
>> Signed-off-by: YueHaibing
>
> Thanks but I've already applied earlier patch from Anders Roxell:
>
> https://marc.info/?l=linux-fbdev=155004766902831=2
Good to know this, Thanks!
>
>> ---
>> drivers/video/fbdev/omap2/omapfb/dss/core.c | 3 ---
>> 1 file changed, 3 deletions(-)
>>
>> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/core.c
>> b/drivers/video/fbdev/omap2/omapfb/dss/core.c
>> index 7e6a3eb..b5956a1 100644
>> --- a/drivers/video/fbdev/omap2/omapfb/dss/core.c
>> +++ b/drivers/video/fbdev/omap2/omapfb/dss/core.c
>> @@ -136,7 +136,6 @@ static inline void dss_uninitialize_debugfs(void)
>> }
>> void dss_debugfs_create_file(const char *name, void (*write)(struct
>> seq_file *))
>> {
>> -return 0;
>> }
>> #endif /* CONFIG_FB_OMAP2_DSS_DEBUGFS */
>>
>> @@ -169,8 +168,6 @@ static struct notifier_block omap_dss_pm_notif_block = {
>>
>> static int __init omap_dss_probe(struct platform_device *pdev)
>> {
>> -int r;
>> -
>> core.pdev = pdev;
>>
>> dss_features_init(omapdss_get_version());
>
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R Institute Poland
> Samsung Electronics
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 2/5] drm/sun4i: sun6i_mipi_dsi: Fix TCON DRQ set bits
TCON DRQ for non-burst DSI mode can computed based on horizontal
front porch value, but the current driver trying to include sync
timings along with front porch resulting wrong drq.
This patch is trying to update the drq by subtracting hsync_start
with hdisplay, which is horizontal front porch.
Current code:
mode->hsync_end - mode->hdisplay => horizontal front porch + sync
With this patch:
mode->hsync_start - mode->hdisplay => horizontal front porch
BSP code form BPI-M64-bsp is computing TCON DRQ set bits
for non-burts as (from linux-sunxi/
drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
=> panel->lcd_ht -panel->lcd_x - panel->lcd_hbp
=> (timmings->hor_front_porch + panel->lcd_hbp + panel->lcd_x)
- panel->lcd_x - panel->hbp
=> timmings->hor_front_porch
=> mode->hsync_start - mode->hdisplay
So, update the DRQ set bits accordingly.
Signed-off-by: Jagan Teki
Tested-by: Merlijn Wajer
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 465e7fc57899..140e55f5ed2e 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -436,9 +436,9 @@ static void sun6i_dsi_setup_burst(struct sun6i_dsi *dsi,
SUN6I_DSI_BURST_LINE_SYNC_POINT(SUN6I_DSI_SYNC_POINT));
val = SUN6I_DSI_TCON_DRQ_ENABLE_MODE;
- } else if ((mode->hsync_end - mode->hdisplay) > 20) {
+ } else if ((mode->hsync_start - mode->hdisplay) > 20) {
/* Maagic */
- u16 drq = (mode->hsync_end - mode->hdisplay) - 20;
+ u16 drq = (mode->hsync_start - mode->hdisplay) - 20;
drq *= mipi_dsi_pixel_format_to_bpp(device->format);
drq /= 32;
--
2.18.0.321.gffc6fa0e3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 5/5] drm/sun4i: sun6i_mipi_dsi: Simplify dsi setup timings code
DSI timings are varies between burst/non-burst devices and
current driver is handling this support via if, else statements
which would difficult to read.
Simplify it by using goto to make code more readable.
Signed-off-by: Jagan Teki
Tested-by: Merlijn Wajer
---
Note: This change is created based on previous version burst
changes [1] by addressing comment from [2] by Maxime to make
code readable.
[1] https://patchwork.kernel.org/cover/10813623/
[2] https://patchwork.kernel.org/patch/1007/
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 79 ++
1 file changed, 42 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 31ec4048804d..898f32319c2d 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -550,7 +550,8 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi,
{
struct mipi_dsi_device *device = dsi->device;
unsigned int Bpp = mipi_dsi_pixel_format_to_bpp(device->format) / 8;
- u16 hbp = 0, hfp = 0, hsa = 0, hblk = 0, vblk = 0;
+ u16 hbp, hfp, hsa, hblk;
+ u16 vblk = 0;
u32 basic_ctl = 0;
size_t bytes;
u8 *buffer;
@@ -558,6 +559,7 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi,
/* Do all timing calculations up front to allocate buffer space */
if (device->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) {
+ hbp = hfp = hsa = 0;
hblk = mode->hdisplay * Bpp;
basic_ctl = SUN6I_DSI_BASIC_CTL_VIDEO_BURST |
SUN6I_DSI_BASIC_CTL_HSA_HSE_DIS |
@@ -566,48 +568,51 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi,
if (device->lanes == 4)
basic_ctl |= SUN6I_DSI_BASIC_CTL_TRAIL_FILL |
SUN6I_DSI_BASIC_CTL_TRAIL_INV(0xc);
- } else {
- /*
-* A sync period is composed of a blanking packet (4
-* bytes + payload + 2 bytes) and a sync event packet
-* (4 bytes). Its minimal size is therefore 10 bytes
-*/
+
+ goto alloc_buf;
+ }
+
+ /*
+* A sync period is composed of a blanking packet (4
+* bytes + payload + 2 bytes) and a sync event packet
+* (4 bytes). Its minimal size is therefore 10 bytes
+*/
#define HSA_PACKET_OVERHEAD10
- hsa = max((unsigned int)HSA_PACKET_OVERHEAD,
- (mode->hsync_end - mode->hsync_start) * Bpp -
HSA_PACKET_OVERHEAD);
-
- /*
-* The backporch is set using a blanking packet (4
-* bytes + payload + 2 bytes). Its minimal size is
-* therefore 6 bytes
-*/
+ hsa = max((unsigned int)HSA_PACKET_OVERHEAD,
+ (mode->hsync_end - mode->hsync_start) * Bpp -
HSA_PACKET_OVERHEAD);
+
+ /*
+* The backporch is set using a blanking packet (4
+* bytes + payload + 2 bytes). Its minimal size is
+* therefore 6 bytes
+*/
#define HBP_PACKET_OVERHEAD6
- hbp = max((unsigned int)HBP_PACKET_OVERHEAD,
- (mode->htotal - mode->hsync_end) * Bpp -
HBP_PACKET_OVERHEAD);
-
- /*
-* The frontporch is set using a blanking packet (4
-* bytes + payload + 2 bytes). Its minimal size is
-* therefore 6 bytes
-*/
+ hbp = max((unsigned int)HBP_PACKET_OVERHEAD,
+ (mode->htotal - mode->hsync_end) * Bpp - HBP_PACKET_OVERHEAD);
+
+ /*
+* The frontporch is set using a blanking packet (4
+* bytes + payload + 2 bytes). Its minimal size is
+* therefore 6 bytes
+*/
#define HFP_PACKET_OVERHEAD6
- hfp = max((unsigned int)HFP_PACKET_OVERHEAD,
- (mode->hsync_start - mode->hdisplay) * Bpp -
HFP_PACKET_OVERHEAD);
-
- /*
-* The blanking is set using a sync event (4 bytes)
-* and a blanking packet (4 bytes + payload + 2
-* bytes). Its minimal size is therefore 10 bytes.
-*/
+ hfp = max((unsigned int)HFP_PACKET_OVERHEAD,
+ (mode->hsync_start - mode->hdisplay) * Bpp -
HFP_PACKET_OVERHEAD);
+
+ /*
+* The blanking is set using a sync event (4 bytes)
+* and a blanking packet (4 bytes + payload + 2
+* bytes). Its minimal size is therefore 10 bytes.
+*/
#define HBLK_PACKET_OVERHEAD 10
- hblk = max((unsigned int)HBLK_PACKET_OVERHEAD,
- (mode->htotal - (mode->hsync_end -
mode->hsync_start)) * Bpp -
- HBLK_PACKET_OVERHEAD);
+ hblk = max((unsigned int)HBLK_PACKET_OVERHEAD,
+ (mode->htotal - (mode->hsync_end -
[PATCH v9 1/5] drm/sun4i: sun6i_mipi_dsi: Fix hsync_porch overflow
Loop N1 instruction delay for burst mode devices are computed
based on horizontal sync and porch timing values.
The current driver is using u16 type for computing this hsync_porch
value, which would failed to fit within the u16 type for large sync
and porch timings devices. This would result in hsync_porch overflow
and eventually computed wrong instruction delay value.
Example, timings, where it produces the overflow
{
.hdisplay = 1080,
.hsync_start= 1080 + 408,
.hsync_end = 1080 + 408 + 4,
.htotal = 1080 + 408 + 4 + 38,
}
It reproduces the desired delay value 65487 but the correct working
value should be 7.
So, Fix it by computing hsync_porch value separately with u32 type.
Fixes: 1c1a7aa3663c ("drm/sun4i: dsi: Add burst support")
Signed-off-by: Jagan Teki
Tested-by: Merlijn Wajer
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 6ff585055a07..465e7fc57899 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -457,8 +457,9 @@ static void sun6i_dsi_setup_inst_loop(struct sun6i_dsi *dsi,
u16 delay = 50 - 1;
if (device->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) {
- delay = (mode->htotal - mode->hdisplay) * 150;
- delay /= (mode->clock / 1000) * 8;
+ u32 hsync_porch = (mode->htotal - mode->hdisplay);
+
+ delay = ((hsync_porch * 150) / ((mode->clock / 1000) * 8));
delay -= 50;
}
--
2.18.0.321.gffc6fa0e3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 4/5] drm/sun4i: sun6i_mipi_dsi: Support DSI GENERIC_SHORT_WRITE_2 transfer
Some DSI panels do use GENERIC_SHORT_WRITE_2 transfer protocol to host
DSI driver and which is similar to GENERIC_SHORT_WRITE.
Add support for the same transfer, so-that so-that the panels which are
requesting similar transfer type will process properly.
Signed-off-by: Jagan Teki
Tested-by: Merlijn Wajer
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index b38358465d87..31ec4048804d 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -993,6 +993,7 @@ static ssize_t sun6i_dsi_transfer(struct mipi_dsi_host
*host,
switch (msg->type) {
case MIPI_DSI_DCS_SHORT_WRITE:
case MIPI_DSI_DCS_SHORT_WRITE_PARAM:
+ case MIPI_DSI_GENERIC_SHORT_WRITE_2_PARAM:
ret = sun6i_dsi_dcs_write_short(dsi, msg);
break;
--
2.18.0.321.gffc6fa0e3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 3/5] drm/sun4i: sun6i_mipi_dsi: Support vblk timing for 4-lane devices
Like other dsi setup timings, or hblk for that matter vblk would
also require compute the timings based payload equation along with
packet overhead.
But, on the other hand vblk computation is also depends on device
lane number.
- for 4 lane devices, it is computed based on vtotal, packet overhead
along with hblk value.
- for others devices, it is simply 0
BSP code from BPI-M64-bsp is computing vblk as for 4-lane devices
(from linux-sunxi
drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
tmp = (ht*dsi_pixel_bits[format]/8)*vt-(4+dsi_hblk+2);
dsi_vblk = (lane-tmp%lane);
So, update the vblk timing calculation to support all type of
devices.
Tested on 2-lane, 4-lane MIPI-DSI LCD panels.
Signed-off-by: Jagan Teki
Tested-by: Merlijn Wajer
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 27 +++---
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 140e55f5ed2e..b38358465d87 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -527,6 +527,24 @@ static void sun6i_dsi_setup_format(struct sun6i_dsi *dsi,
SUN6I_DSI_PIXEL_CTL0_FORMAT(fmt));
}
+static u16 sun6i_dsi_get_timings_vblk(struct sun6i_dsi *dsi,
+ struct drm_display_mode *mode, u16 hblk)
+{
+ struct mipi_dsi_device *device = dsi->device;
+ unsigned int Bpp = mipi_dsi_pixel_format_to_bpp(device->format) / 8;
+ int tmp;
+
+ /*
+* The vertical blank is set using a blanking packet (4 bytes +
+* payload + 2 bytes). Its minimal size is therefore 6 bytes
+*/
+#define VBLK_PACKET_OVERHEAD 6
+ tmp = (mode->htotal * Bpp) * mode->vtotal -
+ (hblk + VBLK_PACKET_OVERHEAD);
+
+ return (device->lanes - tmp % device->lanes);
+}
+
static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi,
struct drm_display_mode *mode)
{
@@ -586,13 +604,8 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi,
(mode->htotal - (mode->hsync_end -
mode->hsync_start)) * Bpp -
HBLK_PACKET_OVERHEAD);
- /*
-* And I'm not entirely sure what vblk is about. The driver in
-* Allwinner BSP is using a rather convoluted calculation
-* there only for 4 lanes. However, using 0 (the !4 lanes
-* case) even with a 4 lanes screen seems to work...
-*/
- vblk = 0;
+ if (device->lanes == 4)
+ vblk = sun6i_dsi_get_timings_vblk(dsi, mode, hblk);
}
/* How many bytes do we need to send all payloads? */
--
2.18.0.321.gffc6fa0e3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 0/5] drm/sun4i: sun6i_mipi_dsi: Fixes/updates
Unfortunately due to various reasons[3] the previous fixes[1] and burst[2] changes are failed to apply. So, this series is filtered version of previous [1] and [2] changes on top of drm-misc. patch-1: Fix for burst mode instruction delay computation patch-2: Fix for TCOn DRQ set bits patch-3: Support vblk timing for 4-lane devices patch-4: GENERIC_SHORT_WRITE_2 dsi transfer support patch-5: Code simplification for dsi timings Changes for v9: - rebase on drm-misc - update commit messages - add hsync_porch overflow patch Changes for v8: - rebase on master - rework on commit messages - rework video start delay - include drq changes from previous version Changes for v7: - rebase on master - collect Merlijn Wajer Tested-by credits. Changes for v6: - fixed all burst mode patches as per previous version comments - rebase on master - update proper commit message - dropped unneeded comments - order the patches that make review easy Changes for v5, v4, v3, v2: - use existing driver code construct for hblk computation - create separate function for vblk computation - cleanup commit messages - update proper commit messages - fixed checkpatch warnings/errors - use proper return value for tcon0 probe - add logic to get tcon0 divider values - simplify timings code to support burst mode - fix drq computation return values - rebase on master [1] https://patchwork.kernel.org/cover/10813573/ [2] https://patchwork.kernel.org/cover/10813623/ [3] https://patchwork.kernel.org/cover/10805995/ Any inputs? Jagan. Jagan Teki (5): drm/sun4i: sun6i_mipi_dsi: Fix hsync_porch overflow drm/sun4i: sun6i_mipi_dsi: Fix TCON DRQ set bits drm/sun4i: sun6i_mipi_dsi: Support vblk timing for 4-lane devices drm/sun4i: sun6i_mipi_dsi: Support DSI GENERIC_SHORT_WRITE_2 transfer drm/sun4i: sun6i_mipi_dsi: Simplify dsi setup timings code drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 114 +++-- 1 file changed, 67 insertions(+), 47 deletions(-) -- 2.18.0.321.gffc6fa0e3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109819] Shadow of Mordor causes gpu freeze ryzen 2200g
https://bugs.freedesktop.org/show_bug.cgi?id=109819 Bug ID: 109819 Summary: Shadow of Mordor causes gpu freeze ryzen 2200g Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: dominic.l...@berlin.de Created attachment 143516 --> https://bugs.freedesktop.org/attachment.cgi?id=143516=edit dumps from dmesg, glxinfo and xorg Using Kernel 4.20.13 (on Ubuntu 18.04.2) the game Shadow of Mordor installed from steam will freeze the screen after 5-120 minutes. SSH'ing into the machine still works. I'm attaching glxinfo, Xorg.log, and dmesg log from the crash for reference. Btw. I've added "drm.debug=0x1e log_buf_len=1M" to grub but wasn't able so far to catch anything writting to /sys/class/drm/card0/error Let me know if there is anything I can do to help debugging. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 2/2] drm/lima: driver for ARM Mali4xx GPUs
Hi Qiang. Good to see you do prompt follow-up on the feedback you get. I applied the patch and noticed that git compains about a few whitespace errors. So for good measure I throw checkpatch after it. $ scripts/checkpatch.pl --max-line-length=120 ~/lima ... total: 45 errors, 36 warnings, 4197 lines checked Several (most) of these looks like legitimate issues and should be fixed. It is much easier to do it now, rather than handle the trivial patches later. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109763] [radeonsi] Enable framerate capping
https://bugs.freedesktop.org/show_bug.cgi?id=109763 --- Comment #5 from Shmerl --- (In reply to fin4478 from comment #4) > Many games have a built in frame rate limiter. This is obviously intended for those which don't have it (which are many as well). -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109763] [radeonsi] Enable framerate capping
https://bugs.freedesktop.org/show_bug.cgi?id=109763 --- Comment #4 from fin4...@hotmail.com --- Many games have a built in frame rate limiter. Your GPU will not wear if temperatures are OK. Increase cooling in your computer case. There is no sense to duplicate features that are in games or can be solved otherwise. The amgpu driver code is complex already. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109763] [radeonsi] Enable framerate capping
https://bugs.freedesktop.org/show_bug.cgi?id=109763 --- Comment #3 from Shmerl --- That's not really the same as hard limiting the framerate, though can be useful as well. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109763] [radeonsi] Enable framerate capping
https://bugs.freedesktop.org/show_bug.cgi?id=109763 --- Comment #2 from fin4...@hotmail.com --- You can use a selected engine clock range to lower performance. You can use my python app for that. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108916] polaris11 d3d9 rendering issue
https://bugs.freedesktop.org/show_bug.cgi?id=108916 --- Comment #5 from Roman Elshin --- >hd7770 with amdgpu it is the same with radeon. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109763] [radeonsi] Enable framerate capping
https://bugs.freedesktop.org/show_bug.cgi?id=109763 --- Comment #1 from fin4...@hotmail.com --- Created attachment 143515 --> https://bugs.freedesktop.org/attachment.cgi?id=143515=edit a simple python app for the amdgpu sysfs API -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108916] polaris11 d3d9 rendering issue
https://bugs.freedesktop.org/show_bug.cgi?id=108916 --- Comment #4 from Roman Elshin --- > I can't reproduce this on CIK (Kabini) using provided trace. > > So, this sounds like hardware specific bug somewhere, probably llvm. There are similar distorsions with verde (hd7770 with amdgpu), but it less noticeable there. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
