Re: [PATCH 3/3] drm/vc4: hdmi: Add pixel bvb clock control
On 8/27/20 6:49 PM, Stefan Wahren wrote:
> Am 27.08.20 um 06:35 schrieb Hoegeun Kwon:
>> Hi Stefan,
>>
>> Thank you for your review.
>>
>>
>> On 8/26/20 7:04 PM, Stefan Wahren wrote:
>>> Hi Hoeguen,
>>>
>>> Am 21.08.20 um 09:10 schrieb Hoegeun Kwon:
There is a problem that the output does not work at a resolution
exceeding FHD. To solve this, we need to adjust the bvb clock at a
resolution exceeding FHD.
>>> this patch introduces a mandatory clock, please update
>>> brcm,bcm2835-hdmi.yaml first.
>>>
>>> Is this clock physically available on BCM283x or only on BCM2711?
>> As far as I know, BCM2711 raspberry pi 4 supports 4k,
>>
>> don't supported on pi 3 and pi 3+.
>>
>> Since 4k is not supported in versions prior to Raspberry Pi 4,
>>
>> I don't think we need to modify the bvb clock.
>>
>>
>> So I think it is better to update 'brcm,bcm2711-hdmi.yaml'
>>
>> instead of 'brcm,bcm2835-hdmi.yaml'.
> You are correct please update only brcm,bcm2711-hdmi.yaml.
>
> My concern was that the function vc4_hdmi_encoder_pre_crtc_configure()
> is called on a non-bcm2711 platform or on a Raspberry Pi 4 with an older
> DTB. So making the BVB clock optional might be better?
You are right, if use old dtb, we have a problem with the hdmi driver.
So how about modifying it like this?
@@ -1614,8 +1614,8 @@ static int vc5_hdmi_init_resources(struct vc4_hdmi
*vc4_hdmi)
vc4_hdmi->pixel_bvb_clock = devm_clk_get(dev, "bvb");
if (IS_ERR(vc4_hdmi->pixel_bvb_clock)) {
- DRM_ERROR("Failed to get pixel bvb clock\n");
- return PTR_ERR(vc4_hdmi->pixel_bvb_clock);
+ DRM_WARN("Failed to get pixel bvb clock\n");
+ vc4_hdmi->pixel_bvb_clock = NULL;
}
vc4_hdmi->reset = devm_reset_control_get(dev, NULL);
If we modify like this, if there is no bvb clock in dtb, then
pixel_bvb_clock will be null
and it will not affect the clk control function below.
- clk_set_rate()
- clk_prepare_enable()
- clk_disable_unprepare()
Best regards
Hoegeun
>
>> Please comment, what do you think?
>>
>>> I'm a little bit afraid, this change could break with older firmware
>>> versions on BCM283x.
>> Tested it several times with libdrm modetest.
>>
>> I expect there will be no problem.
>>
>>
>> Best regards,
>>
>> Hoegeun
>>
>>> Best regards
>>> Stefan
>>>
Signed-off-by: Hoegeun Kwon
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 25 +
drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +
2 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c
b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 95ec5eedea39..eb3192d1fd86 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -80,6 +80,7 @@
# define VC4_HD_M_ENABLEBIT(0)
#define CEC_CLOCK_FREQ 4
+#define VC4_HSM_MID_CLOCK 149985000
static int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused)
{
@@ -380,6 +381,7 @@ static void
vc4_hdmi_encoder_post_crtc_powerdown(struct drm_encoder *encoder)
HDMI_WRITE(HDMI_VID_CTL,
HDMI_READ(HDMI_VID_CTL) & ~VC4_HD_VID_CTL_ENABLE);
+ clk_disable_unprepare(vc4_hdmi->pixel_bvb_clock);
clk_disable_unprepare(vc4_hdmi->hsm_clock);
clk_disable_unprepare(vc4_hdmi->pixel_clock);
@@ -638,6 +640,23 @@ static void
vc4_hdmi_encoder_pre_crtc_configure(struct drm_encoder *encoder)
return;
}
+ ret = clk_set_rate(vc4_hdmi->pixel_bvb_clock,
+ (hsm_rate > VC4_HSM_MID_CLOCK ? 15000 : 7500));
+ if (ret) {
+ DRM_ERROR("Failed to set pixel bvb clock rate: %d\n", ret);
+ clk_disable_unprepare(vc4_hdmi->hsm_clock);
+ clk_disable_unprepare(vc4_hdmi->pixel_clock);
+ return;
+ }
+
+ ret = clk_prepare_enable(vc4_hdmi->pixel_bvb_clock);
+ if (ret) {
+ DRM_ERROR("Failed to turn on pixel bvb clock: %d\n", ret);
+ clk_disable_unprepare(vc4_hdmi->hsm_clock);
+ clk_disable_unprepare(vc4_hdmi->pixel_clock);
+ return;
+ }
+
if (vc4_hdmi->variant->reset)
vc4_hdmi->variant->reset(vc4_hdmi);
@@ -1593,6 +1612,12 @@ static int vc5_hdmi_init_resources(struct vc4_hdmi
*vc4_hdmi)
return PTR_ERR(vc4_hdmi->audio_clock);
}
+ vc4_hdmi->pixel_bvb_clock = devm_clk_get(dev, "bvb");
+ if (IS_ERR(vc4_hdmi->pixel_bvb_clock)) {
+ DRM_ERROR("Failed to get pixel bvb clock\n");
+ return PTR_ERR(vc4_hdmi->pixel_bvb_clock);
+ }
+
vc4_hdmi->reset = devm_reset_control_get(dev, NULL);
if (IS_ERR(
Re: [PATCH v2 3/4] drm/plane: add drmm_universal_plane_alloc()
Hi Philipp,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip linus/master v5.9-rc2 next-20200827]
[cannot apply to drm/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Philipp-Zabel/drm-add-drmm_encoder_alloc/20200828-000957
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: arm-randconfig-r003-20200827 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
c10e63677f5d20f18010f8f68c631ddc97546f7d)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm cross compiling tool for clang build
# apt-get install binutils-arm-linux-gnueabi
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/drm_plane.c:301:6: warning: variable 'ap' is used
>> uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
if (name)
^~~~
drivers/gpu/drm/drm_plane.c:305:19: note: uninitialized use occurs here
type, name, ap);
^~
drivers/gpu/drm/drm_plane.c:301:2: note: remove the 'if' if its condition is
always true
if (name)
^
drivers/gpu/drm/drm_plane.c:298:2: note: variable 'ap' is declared here
va_list ap;
^
drivers/gpu/drm/drm_plane.c:344:6: warning: variable 'ap' is used
uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
if (name)
^~~~
drivers/gpu/drm/drm_plane.c:348:19: note: uninitialized use occurs here
type, name, ap);
^~
drivers/gpu/drm/drm_plane.c:344:2: note: remove the 'if' if its condition is
always true
if (name)
^
drivers/gpu/drm/drm_plane.c:332:2: note: variable 'ap' is declared here
va_list ap;
^
2 warnings generated.
#
https://github.com/0day-ci/linux/commit/5f2373dfa20624f32ff28097eb734511ed8ca13e
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Philipp-Zabel/drm-add-drmm_encoder_alloc/20200828-000957
git checkout 5f2373dfa20624f32ff28097eb734511ed8ca13e
vim +301 drivers/gpu/drm/drm_plane.c
271
272 /**
273 * drm_universal_plane_init - Initialize a new universal plane object
274 * @dev: DRM device
275 * @plane: plane object to init
276 * @possible_crtcs: bitmask of possible CRTCs
277 * @funcs: callbacks for the new plane
278 * @formats: array of supported formats (DRM_FORMAT\_\*)
279 * @format_count: number of elements in @formats
280 * @format_modifiers: array of struct drm_format modifiers terminated by
281 *DRM_FORMAT_MOD_INVALID
282 * @type: type of plane (overlay, primary, cursor)
283 * @name: printf style format string for the plane name, or NULL for
default name
284 *
285 * Initializes a plane object of type @type.
286 *
287 * Returns:
288 * Zero on success, error code on failure.
289 */
290 int drm_universal_plane_init(struct drm_device *dev, struct drm_plane
*plane,
291 uint32_t possible_crtcs,
292 const struct drm_plane_funcs *funcs,
293 const uint32_t *formats, unsigned int
format_count,
294 const uint64_t *format_modifiers,
295 enum drm_plane_type type,
296 const char *name, ...)
297 {
298 va_list ap;
299 int ret;
300
> 301 if (name)
302 va_start(ap, name);
303 ret = __drm_universal_plane_init(dev, plane, possible_crtcs,
funcs,
304 formats, format_count,
format_modifiers,
305 type, name, ap);
306 if (name)
307 va_end(ap);
308 return ret;
309 }
310 EXPORT_SYMBOL(drm_universal_plane_init);
311
---
0-DAY CI Kernel Test Service, Intel Corp
Re: Printing bitfields in the kernel (Re: [PATCH] drm: Parse Colorimetry data block from EDID)
On Thu, 2020-08-27 at 10:34 +0300, Pekka Paalanen wrote:
> On Wed, 26 Aug 2020 22:23:28 +0800
> Algea Cao wrote:
>
> > CEA 861.3 spec adds colorimetry data block for HDMI.
> > Parsing the block to get the colorimetry data from
> > panel.
If flags are int, I could imagine another %p extension
where %*p is used like:
printk("flags: %*pn", flags, bitstrings)
where flags is:
BIT(0)
BIT(1)
...
BIT(last)
and
char *bitstrings[] = {
"bit 0 description",
"bit 1 description",
...
"last bit description"
};
Or define YA struct with 2 entries as the struct members
and use that.
struct foo {
unsigned long flags,
char ** descriptions,
};
struct foo bar = {.flags = .descriptions = bitstrings};
printk("flags: %p\n, &bar);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/4] drm: add drmm_encoder_alloc()
Hi Philipp,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip linus/master v5.9-rc2 next-20200827]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Philipp-Zabel/drm-add-drmm_encoder_alloc/20200828-000957
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: arm-randconfig-r003-20200827 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
c10e63677f5d20f18010f8f68c631ddc97546f7d)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm cross compiling tool for clang build
# apt-get install binutils-arm-linux-gnueabi
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/drm_encoder.c:160:6: warning: variable 'ap' is used
>> uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
if (name)
^~~~
drivers/gpu/drm/drm_encoder.c:162:68: note: uninitialized use occurs here
ret = __drm_encoder_init(dev, encoder, funcs, encoder_type, name,
ap);
^~
drivers/gpu/drm/drm_encoder.c:160:2: note: remove the 'if' if its condition
is always true
if (name)
^
drivers/gpu/drm/drm_encoder.c:157:2: note: variable 'ap' is declared here
va_list ap;
^
drivers/gpu/drm/drm_encoder.c:227:6: warning: variable 'ap' is used
uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
if (name)
^~~~
drivers/gpu/drm/drm_encoder.c:229:68: note: uninitialized use occurs here
ret = __drm_encoder_init(dev, encoder, funcs, encoder_type, name,
ap);
^~
drivers/gpu/drm/drm_encoder.c:227:2: note: remove the 'if' if its condition
is always true
if (name)
^
drivers/gpu/drm/drm_encoder.c:215:2: note: variable 'ap' is declared here
va_list ap;
^
2 warnings generated.
#
https://github.com/0day-ci/linux/commit/582208cffad6661715216bc2fd36f382012f8419
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Philipp-Zabel/drm-add-drmm_encoder_alloc/20200828-000957
git checkout 582208cffad6661715216bc2fd36f382012f8419
vim +160 drivers/gpu/drm/drm_encoder.c
136
137 /**
138 * drm_encoder_init - Init a preallocated encoder
139 * @dev: drm device
140 * @encoder: the encoder to init
141 * @funcs: callbacks for this encoder
142 * @encoder_type: user visible type of the encoder
143 * @name: printf style format string for the encoder name, or NULL for
default name
144 *
145 * Initializes a preallocated encoder. Encoder should be subclassed as
part of
146 * driver encoder objects. At driver unload time drm_encoder_cleanup()
should be
147 * called from the driver's &drm_encoder_funcs.destroy hook.
148 *
149 * Returns:
150 * Zero on success, error code on failure.
151 */
152 int drm_encoder_init(struct drm_device *dev,
153 struct drm_encoder *encoder,
154 const struct drm_encoder_funcs *funcs,
155 int encoder_type, const char *name, ...)
156 {
157 va_list ap;
158 int ret;
159
> 160 if (name)
161 va_start(ap, name);
162 ret = __drm_encoder_init(dev, encoder, funcs, encoder_type,
name, ap);
163 if (name)
164 va_end(ap);
165
166 return ret;
167 }
168 EXPORT_SYMBOL(drm_encoder_init);
169
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm fixes for 5.9-rc3
Hey Linus, As expected a bit of an rc3 uptick, amdgpu and msm are the main ones, one msm patch was from the merge window, but had dependencies and we dropped it until the other tree had landed. Otherwise it's a couple of fixes for core, and etnaviv, and single i915, exynos, omap fixes. I'm still tracking the Sandybridge gpu relocations issue, if we don't see much movement I might just queue up the reverts. I'll talk to Daniel next week once he's back from holidays. Dave. drm-fixes-2020-08-28: drm fixes for 5.9-rc3 core: - Take modeset bkl for legacy drivers. dp_mst: - Allow null crtc in dp_mst. i915: - Fix command parser desc matching with masks amdgpu: - Misc display fixes - Backlight fixes - MPO fix for DCN1 - Fixes for Sienna Cichlid - Fixes for Navy Flounder - Vega SW CTF fixes - SMU fix for Raven - Fix a possible overflow in INFO ioctl - Gfx10 clockgating fix msm: - opp/bw scaling patch followup - frequency restoring fux - vblank in atomic commit fix - dpu modesetting fixes - fencing fix etnaviv: - scheduler interaction fix - gpu init regression fix exynos: - Just drop __iommu annotation to fix sparse warning. omap: - locking state fix. The following changes since commit d012a7190fc1fd72ed48911e77ca97ba4521bccd: Linux 5.9-rc2 (2020-08-23 14:08:43 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-08-28 for you to fetch changes up to 2a3f9da32de4616f0104209194e9bd3dfae092c9: Merge tag 'drm-intel-fixes-2020-08-27' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2020-08-28 11:02:53 +1000) drm fixes for 5.9-rc3 core: - Take modeset bkl for legacy drivers. dp_mst: - Allow null crtc in dp_mst. i915: - Fix command parser desc matching with masks amdgpu: - Misc display fixes - Backlight fixes - MPO fix for DCN1 - Fixes for Sienna Cichlid - Fixes for Navy Flounder - Vega SW CTF fixes - SMU fix for Raven - Fix a possible overflow in INFO ioctl - Gfx10 clockgating fix msm: - opp/bw scaling patch followup - frequency restoring fux - vblank in atomic commit fix - dpu modesetting fixes - fencing fix etnaviv: - scheduler interaction fix - gpu init regression fix exynos: - Just drop __iommu annotation to fix sparse warning. omap: - locking state fix. Alex Deucher (1): drm/amdgpu: Fix buffer overflow in INFO ioctl Alexander Monakov (1): drm/amd/display: use correct scale for actual_brightness Bhawanpreet Lakha (1): drm/dp_mst: Don't return error code when crtc is null Brandon Syu (1): drm/amd/display: Keep current gain when ABM disable immediately Christian Gmeiner (1): drm/etnaviv: fix external abort seen on GC600 rev 0x19 Daniel Vetter (1): drm/modeset-lock: Take the modeset BKL for legacy drivers Dave Airlie (6): Merge tag 'exynos-drm-fixes-v5.9-rc3' of git://git.kernel.org/.../daeinki/drm-exynos into drm-fixes Merge branch 'etnaviv/fixes' of https://git.pengutronix.de/git/lst/linux into drm-fixes Merge tag 'drm-msm-fixes-2020-08-24' of https://gitlab.freedesktop.org/drm/msm into drm-fixes Merge tag 'amd-drm-fixes-5.9-2020-08-26' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Merge tag 'drm-misc-fixes-2020-08-26' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Merge tag 'drm-intel-fixes-2020-08-27' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Dinghao Liu (1): drm/amd/display: Fix memleak in amdgpu_dm_mode_config_init Dmitry Baryshkov (1): drm/msm/a6xx: fix gmu start on newer firmware Evan Quan (4): drm/amd/pm: correct Vega10 swctf limit setting drm/amd/pm: correct Vega12 swctf limit setting drm/amd/pm: correct Vega20 swctf limit setting drm/amd/pm: correct the thermal alert temperature limit settings Furquan Shaikh (1): drivers: gpu: amd: Initialize amdgpu_dm_backlight_caps object to 0 in amdgpu_dm_update_backlight_caps Jaehyun Chung (1): drm/amd/display: Revert HDCP disable sequence change Jiansong Chen (5): drm/amd/pm: enable run_btc callback for sienna_cichlid drm/amd/pm: set VCN pg per instances drm/amdgpu/gfx10: refine mgcg setting drm/amdgpu: use MODE1 reset for navy_flounder by default drm/amdgpu: disable runtime pm for navy_flounder Jonathan Marek (1): drm/msm/a6xx: fix frequency not always being restored on GMU resume Kalyan Thota (2): drm/msm/dpu: Fix reservation failures in modeset drm/msm/dpu: Fix scale params in plane validation Krishna Manikandan (1): drm/msm: add shutdown support for display platform_driver Lucas Stach (1): drm/etnaviv: always start/stop scheduler in timeout processing Maarten Lankhorst (1): Merge tag 'v5.9-rc2' into drm-misc-fixes Marek Szyprowski (1): drm/exynos: gem: Fix sparse warning Mika Kuoppala (1):
Re: Aw: Re: [PATCH v5 3/7] drm/mediatek: disable tmds on mt2701
Hi, Frank: Matthias Brugger 於 2020年8月27日 週四 下午10:28寫道： > > > > On 27/08/2020 15:41, Frank Wunderlich wrote: > > Hi Matthias, > > > > any opinions about the dts-changes? > > > > they look good to me. > > > maybe series except the tmds-Patch get merged...so i add it only to my own > > repo till we find a better way? > > currently mainline does not support hdmi at all for the board. the > > tmds-patch is only a fix for specific resolutions which have a "flickering" > > without this Patch. > > > > Well let's see what CK's opinion. > Because no one has comment on this patch, I could apply this patch but I need you to add more experiment information so if someone meets another bug, he could fix his bug and consider your problem. Regards, Chun-Kuang. > Regards, > Matthias ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 5/7] drm/mediatek: dpi/dsi: change the getting possible_crtc way
Hi,
Matthias Brugger 於 2020年8月20日 週四 上午1:14寫道：
>
>
>
> On 19/08/2020 10:17, Frank Wunderlich wrote:
> > From: Jitao Shi
> >
> > For current mediatek dsi encoder, its possible crtc is fixed in crtc
> > 0, and mediatek dpi encoder's possible crtc is fixed in crtc 1. In
> > some SoC the possible crtc is not fixed in this case, so call
> > mtk_drm_find_possible_crtc_by_comp() to find out the correct possible
> > crtc.
> >
>
> Hm, shouldn't we stash this int 4/7, otherwise we will have not used functions
> in 4/7.
Agree with Matthias, so squash this patch into 4/7, and applied to
mediatek-drm-next [1], thanks.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next
Regards,
Chun-Kuang.
>
> Regards,
> Matthias
>
> > Signed-off-by: Jitao Shi
> > Signed-off-by: Frank Wunderlich
> > Reviewed-by: Chun-Kuang Hu
> > ---
> > drivers/gpu/drm/mediatek/mtk_dpi.c | 3 ++-
> > drivers/gpu/drm/mediatek/mtk_dsi.c | 3 ++-
> > 2 files changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
> > b/drivers/gpu/drm/mediatek/mtk_dpi.c
> > index d4f0fb7ad312..e43977015843 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> > @@ -608,7 +608,8 @@ static int mtk_dpi_bind(struct device *dev, struct
> > device *master, void *data)
> > drm_encoder_helper_add(&dpi->encoder, &mtk_dpi_encoder_helper_funcs);
> >
> > /* Currently DPI0 is fixed to be driven by OVL1 */
> > - dpi->encoder.possible_crtcs = BIT(1);
> > + dpi->encoder.possible_crtcs =
> > + mtk_drm_find_possible_crtc_by_comp(drm_dev, dpi->ddp_comp);
> >
> > ret = drm_bridge_attach(&dpi->encoder, dpi->bridge, NULL, 0);
> > if (ret) {
> > diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> > b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > index 16fd99dcdacf..c9f4ad029cb1 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > @@ -974,7 +974,8 @@ static int mtk_dsi_encoder_init(struct drm_device *drm,
> > struct mtk_dsi *dsi)
> >* Currently display data paths are statically assigned to a crtc
> > each.
> >* crtc 0 is OVL0 -> COLOR0 -> AAL -> OD -> RDMA0 -> UFOE -> DSI0
> >*/
> > - dsi->encoder.possible_crtcs = 1;
> > + dsi->encoder.possible_crtcs =
> > + mtk_drm_find_possible_crtc_by_comp(drm, dsi->ddp_comp);
> >
> > ret = drm_bridge_attach(&dsi->encoder, &dsi->bridge, NULL,
> > DRM_BRIDGE_ATTACH_NO_CONNECTOR);
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 2/7] drm/mediatek: add ddp routing for mt7623
Hi, Frank:
Frank Wunderlich 於 2020年8月19日 週三 下午4:18寫道：
>
> From: Frank Wunderlich
>
> on BPi-R2/mt7623 main-path have to be routed to DPI0 (hdmi) instead of DSI0
> using compatible "mt7623-mmsys" already defined in dts
>
For this patch, applied to mediatek-drm-next [1], thanks.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next
Regards,
Chun-Kuang.
> Signed-off-by: Frank Wunderlich
> Reviewed-by: Chun-Kuang Hu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 23 +++
> 1 file changed, 23 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index 040a8f393fe2..2350e3200b59 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -74,6 +74,19 @@ static const enum mtk_ddp_comp_id mt2701_mtk_ddp_ext[] = {
> DDP_COMPONENT_DPI0,
> };
>
> +static const enum mtk_ddp_comp_id mt7623_mtk_ddp_main[] = {
> + DDP_COMPONENT_OVL0,
> + DDP_COMPONENT_RDMA0,
> + DDP_COMPONENT_COLOR0,
> + DDP_COMPONENT_BLS,
> + DDP_COMPONENT_DPI0,
> +};
> +
> +static const enum mtk_ddp_comp_id mt7623_mtk_ddp_ext[] = {
> + DDP_COMPONENT_RDMA1,
> + DDP_COMPONENT_DSI0,
> +};
> +
> static const enum mtk_ddp_comp_id mt2712_mtk_ddp_main[] = {
> DDP_COMPONENT_OVL0,
> DDP_COMPONENT_COLOR0,
> @@ -127,6 +140,14 @@ static const struct mtk_mmsys_driver_data
> mt2701_mmsys_driver_data = {
> .shadow_register = true,
> };
>
> +static const struct mtk_mmsys_driver_data mt7623_mmsys_driver_data = {
> + .main_path = mt7623_mtk_ddp_main,
> + .main_len = ARRAY_SIZE(mt7623_mtk_ddp_main),
> + .ext_path = mt7623_mtk_ddp_ext,
> + .ext_len = ARRAY_SIZE(mt7623_mtk_ddp_ext),
> + .shadow_register = true,
> +};
> +
> static const struct mtk_mmsys_driver_data mt2712_mmsys_driver_data = {
> .main_path = mt2712_mtk_ddp_main,
> .main_len = ARRAY_SIZE(mt2712_mtk_ddp_main),
> @@ -422,6 +443,8 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
> static const struct of_device_id mtk_drm_of_ids[] = {
> { .compatible = "mediatek,mt2701-mmsys",
> .data = &mt2701_mmsys_driver_data},
> + { .compatible = "mediatek,mt7623-mmsys",
> + .data = &mt7623_mmsys_driver_data},
> { .compatible = "mediatek,mt2712-mmsys",
> .data = &mt2712_mmsys_driver_data},
> { .compatible = "mediatek,mt8173-mmsys",
> --
> 2.25.1
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/7] dt-bindings: mediatek: add mt7623 display-nodes
Hi, Frank: Frank Wunderlich 於 2020年8月19日 週三 下午4:18寫道： > > From: Frank Wunderlich > > mt7623 uses mt2701/mt8173 for drm, but have own compatibles > For this patch, applied to mediatek-drm-next [1], thanks. [1] https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next Regards, Chun-Kuang. > Signed-off-by: Frank Wunderlich > Acked-by: Rob Herring > Reviewed-by: Chun-Kuang Hu > --- > .../devicetree/bindings/display/mediatek/mediatek,disp.txt| 2 +- > .../devicetree/bindings/display/mediatek/mediatek,dpi.txt | 2 +- > .../devicetree/bindings/display/mediatek/mediatek,dsi.txt | 4 ++-- > .../devicetree/bindings/display/mediatek/mediatek,hdmi.txt| 4 > 4 files changed, 8 insertions(+), 4 deletions(-) > > diff --git > a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt > b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt > index b91e709db7a4..121220745d46 100644 > --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt > +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt > @@ -43,7 +43,7 @@ Required properties (all function blocks): > "mediatek,-dpi" - DPI controller, see > mediatek,dpi.txt > "mediatek,-disp-mutex"- display mutex > "mediatek,-disp-od" - overdrive > - the supported chips are mt2701, mt2712 and mt8173. > + the supported chips are mt2701, mt7623, mt2712 and mt8173. > - reg: Physical base address and length of the function block register space > - interrupts: The interrupt signal from the function block (required, except > for >merge and split function blocks). > diff --git > a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt > b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt > index 77def4456706..dc1ebd13cc88 100644 > --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt > +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt > @@ -7,7 +7,7 @@ output bus. > > Required properties: > - compatible: "mediatek,-dpi" > - the supported chips are mt2701 , mt8173 and mt8183. > + the supported chips are mt2701, mt7623, mt8173 and mt8183. > - reg: Physical base address and length of the controller's registers > - interrupts: The interrupt signal from the function block. > - clocks: device clocks > diff --git > a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt > b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt > index 8e4729de8c85..f06f24d405a5 100644 > --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt > +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt > @@ -7,7 +7,7 @@ channel output. > > Required properties: > - compatible: "mediatek,-dsi" > - the supported chips are mt2701, mt8173 and mt8183. > +- the supported chips are mt2701, mt7623, mt8173 and mt8183. > - reg: Physical base address and length of the controller's registers > - interrupts: The interrupt signal from the function block. > - clocks: device clocks > @@ -26,7 +26,7 @@ The MIPI TX configuration module controls the MIPI D-PHY. > > Required properties: > - compatible: "mediatek,-mipi-tx" > - the supported chips are mt2701, mt8173 and mt8183. > +- the supported chips are mt2701, 7623, mt8173 and mt8183. > - reg: Physical base address and length of the controller's registers > - clocks: PLL reference clock > - clock-output-names: name of the output clock line to the DSI encoder > diff --git > a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt > b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt > index 7b124242b0c5..6b1c586403e4 100644 > --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt > +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt > @@ -6,6 +6,7 @@ its parallel input. > > Required properties: > - compatible: Should be "mediatek,-hdmi". > +- the supported chips are mt2701, mt7623 and mt8173 > - reg: Physical base address and length of the controller's registers > - interrupts: The interrupt signal from the function block. > - clocks: device clocks > @@ -32,6 +33,7 @@ The HDMI CEC controller handles hotplug detection and CEC > communication. > > Required properties: > - compatible: Should be "mediatek,-cec" > +- the supported chips are mt7623 and mt8173 > - reg: Physical base address and length of the controller's registers > - interrupts: The interrupt signal from the function block. > - clocks: device clock > @@ -44,6 +46,7 @@ The Mediatek's I2C controller is used to interface with I2C > devices. > > Required properties: > - compatible: Should be "mediatek,-hdmi-ddc" > +- the supported chips are mt7623 and mt8173 > - reg: Physical base address and length of the controller's registers > - clocks: device clock > - clock-
Re: [PATCH v2 10/24] drm/panel: novatek-nt35510: Backlight update
On Sun, Aug 23, 2020 at 12:46 PM Sam Ravnborg wrote: > - Replace direct access to backlight_properties with > backlight_get_brightness(). > - Drop debug printout > - Use macro for initialization > > Signed-off-by: Sam Ravnborg > Cc: Linus Walleij > Cc: Thierry Reding > Cc: Sam Ravnborg Looks good to me! Reviewed-by: Linus Walleij Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 209015] Clocks are no longer reported for R9 390 GPU
https://bugzilla.kernel.org/show_bug.cgi?id=209015 --- Comment #5 from Alex Deucher (alexdeuc...@gmail.com) --- Fixed with this patch: https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next&id=177e38a48168f9e70faaec34df053d2f8134ede6 -- 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
[PATCH v12 3/5] drm/msm/dp: add support for DP PLL driver
From: Chandan Uddaraju
Add the needed DP PLL specific files to support
display port interface on msm targets.
The DP driver calls the DP PLL driver registration.
The DP driver sets the link and pixel clock sources.
Changes in v2:
-- Update copyright markings on all relevant files.
-- Use DRM_DEBUG_DP for debug msgs.
Changes in v4:
-- Update the DP link clock provider names
Changes in V5:
-- Addressed comments from Stephen Boyd, Rob clark.
Changes in V6:
-- Remove PLL as separate driver and include PLL as DP module
-- Remove redundant clock parsing from PLL module and make DP as
clock provider
-- Map USB3 DPCOM and PHY IO using hardcoded register address and
move mapping form parser to PLL module
-- Access DP PHY modules from same base address using offsets instead of
deriving base address of individual module from device tree.
-- Remove dp_pll_10nm_util.c and include its functionality in
dp_pll_10nm.c
-- Introduce new data structures private to PLL module
Changes in v7:
-- Remove DRM_MSM_DP_PLL config from Makefile and Kconfig
-- Remove set_parent from determin_rate API
-- Remove phy_pll_vco_div_clk from parent list
-- Remove flag CLK_DIVIDER_ONE_BASED
-- Remove redundant cell-index property parsing
Changes in v8:
-- Unregister hardware clocks during driver cleanup
Changes in v9:
-- Remove redundant Kconfig option DRM_MSM_DP_10NM_PLL
Changes in v10:
-- Limit 10nm PLL function scope
Signed-off-by: Chandan Uddaraju
Signed-off-by: Vara Reddy
Signed-off-by: Tanmay Shah
---
drivers/gpu/drm/msm/Kconfig | 1 +
drivers/gpu/drm/msm/Makefile| 4 +-
drivers/gpu/drm/msm/dp/dp_catalog.c | 31 +-
drivers/gpu/drm/msm/dp/dp_display.c | 18 +-
drivers/gpu/drm/msm/dp/dp_display.h | 3 +
drivers/gpu/drm/msm/dp/dp_parser.c | 2 +
drivers/gpu/drm/msm/dp/dp_parser.h | 7 +-
drivers/gpu/drm/msm/dp/dp_pll.c | 99 +++
drivers/gpu/drm/msm/dp/dp_pll.h | 61 ++
drivers/gpu/drm/msm/dp/dp_pll_10nm.c| 930
drivers/gpu/drm/msm/dp/dp_pll_private.h | 89 +++
drivers/gpu/drm/msm/dp/dp_power.c | 10 +
drivers/gpu/drm/msm/dp/dp_power.h | 40 +-
drivers/gpu/drm/msm/dp/dp_reg.h | 16 +
14 files changed, 1294 insertions(+), 17 deletions(-)
create mode 100644 drivers/gpu/drm/msm/dp/dp_pll.c
create mode 100644 drivers/gpu/drm/msm/dp/dp_pll.h
create mode 100644 drivers/gpu/drm/msm/dp/dp_pll_10nm.c
create mode 100644 drivers/gpu/drm/msm/dp/dp_pll_private.h
diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index 0b59e4f184fb..8e6ca119ea94 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -60,6 +60,7 @@ config DRM_MSM_HDMI_HDCP
config DRM_MSM_DP
bool "Enable DisplayPort support in MSM DRM driver"
depends on DRM_MSM
+ default y
help
Compile in support for DP driver in MSM DRM driver. DP external
display support is enabled through this config option. It can
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index af868e791210..6d31188cc776 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -109,7 +109,9 @@ msm-$(CONFIG_DRM_MSM_DP)+= dp/dp_aux.o \
dp/dp_link.o \
dp/dp_panel.o \
dp/dp_parser.o \
- dp/dp_power.o
+ dp/dp_power.o \
+ dp/dp_pll.o \
+ dp/dp_pll_10nm.o
msm-$(CONFIG_DRM_FBDEV_EMULATION) += msm_fbdev.o
msm-$(CONFIG_COMMON_CLK) += disp/mdp4/mdp4_lvds_pll.o
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index 0ffde1a74852..d27e17d7d18c 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -5,6 +5,7 @@
#define pr_fmt(fmt)"[drm-dp] %s: " fmt, __func__
+#include
#include
#include
#include
@@ -131,51 +132,58 @@ static inline void dp_write_ahb(struct dp_catalog_private
*catalog,
static inline void dp_write_phy(struct dp_catalog_private *catalog,
u32 offset, u32 data)
{
+ offset += DP_PHY_REG_OFFSET;
/*
* To make sure phy reg writes happens before any other operation,
* this function uses writel() instread of writel_relaxed()
*/
- writel(data, catalog->io->phy_io.base + offset);
+ writel(data, catalog->io->phy_reg.base + offset);
}
static inline u32 dp_read_phy(struct dp_catalog_private *catalog,
u32 offset)
{
+ offset += DP_PHY_REG_OFFSET;
/*
* To make sure phy reg writes happens before any other operation,
* this function uses writel() instread of writel_relaxed()
*/
- return readl_relaxed(catalog->io->phy_io.base + offset);
+ return readl_relaxed(catalog->io->phy_reg.base + offset);
}
static inline void dp_write_pll(struct dp_catalog_private *catalog,
u32 offset, u32 data)
{
- wri
[PATCH v12 5/5] drm/msm/dp: Add Display Port HPD feature
Configure HPD registers in DP controller and
enable HPD interrupt.
Add interrupt to handle HPD connect and disconnect events.
Changes in v8: None
Signed-off-by: Tanmay Shah
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 18
drivers/gpu/drm/msm/dp/dp_catalog.c | 67 +--
drivers/gpu/drm/msm/dp/dp_catalog.h | 5 +-
drivers/gpu/drm/msm/dp/dp_ctrl.c| 1 -
drivers/gpu/drm/msm/dp/dp_display.c | 108 ++--
drivers/gpu/drm/msm/dp/dp_reg.h | 12 +++
drivers/gpu/drm/msm/msm_drv.h | 6 ++
7 files changed, 182 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 62bc33cb0d3a..5e977d5ff341 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -752,6 +752,23 @@ static void dpu_irq_preinstall(struct msm_kms *kms)
dpu_core_irq_preinstall(dpu_kms);
}
+static int dpu_irq_postinstall(struct msm_kms *kms)
+{
+ struct msm_drm_private *priv;
+ struct dpu_kms *dpu_kms = to_dpu_kms(kms);
+
+ if (!dpu_kms || !dpu_kms->dev)
+ return -EINVAL;
+
+ priv = dpu_kms->dev->dev_private;
+ if (!priv)
+ return -EINVAL;
+
+ msm_dp_irq_postinstall(priv->dp);
+
+ return 0;
+}
+
static void dpu_irq_uninstall(struct msm_kms *kms)
{
struct dpu_kms *dpu_kms = to_dpu_kms(kms);
@@ -762,6 +779,7 @@ static void dpu_irq_uninstall(struct msm_kms *kms)
static const struct msm_kms_funcs kms_funcs = {
.hw_init = dpu_kms_hw_init,
.irq_preinstall = dpu_irq_preinstall,
+ .irq_postinstall = dpu_irq_postinstall,
.irq_uninstall = dpu_irq_uninstall,
.irq = dpu_irq,
.enable_commit = dpu_kms_enable_commit,
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index d27e17d7d18c..c16072630d40 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -17,7 +17,6 @@
#define POLLING_SLEEP_US 1000
#define POLLING_TIMEOUT_US 1
-#define REFTIMER_DEFAULT_VALUE 0x2
#define SCRAMBLER_RESET_COUNT_VALUE0xFC
#define DP_INTERRUPT_STATUS_ACK_SHIFT 1
@@ -746,35 +745,51 @@ void dp_catalog_ctrl_enable_irq(struct dp_catalog
*dp_catalog,
}
}
-void dp_catalog_ctrl_hpd_config(struct dp_catalog *dp_catalog, bool en)
+void dp_catalog_hpd_config_intr(struct dp_catalog *dp_catalog,
+ u32 intr_mask, bool en)
{
struct dp_catalog_private *catalog = container_of(dp_catalog,
struct dp_catalog_private, dp_catalog);
- if (en) {
- u32 reftimer = dp_read_aux(catalog, REG_DP_DP_HPD_REFTIMER);
-
- dp_write_aux(catalog, REG_DP_DP_HPD_INT_ACK,
- DP_DP_HPD_PLUG_INT_ACK |
- DP_DP_IRQ_HPD_INT_ACK |
- DP_DP_HPD_REPLUG_INT_ACK |
- DP_DP_HPD_UNPLUG_INT_ACK);
- dp_write_aux(catalog, REG_DP_DP_HPD_INT_MASK,
- DP_DP_HPD_PLUG_INT_MASK |
- DP_DP_IRQ_HPD_INT_MASK |
- DP_DP_HPD_REPLUG_INT_MASK |
- DP_DP_HPD_UNPLUG_INT_MASK);
-
- /* Configure REFTIMER */
- reftimer |= REFTIMER_DEFAULT_VALUE;
- dp_write_aux(catalog, REG_DP_DP_HPD_REFTIMER, reftimer);
- /* Enable HPD */
- dp_write_aux(catalog, REG_DP_DP_HPD_CTRL,
- DP_DP_HPD_CTRL_HPD_EN);
- } else {
- /* Disable HPD */
- dp_write_aux(catalog, REG_DP_DP_HPD_CTRL, 0x0);
- }
+ u32 config = dp_read_aux(catalog, REG_DP_DP_HPD_INT_MASK);
+
+ config = (en ? config | intr_mask : config & ~intr_mask);
+
+ dp_write_aux(catalog, REG_DP_DP_HPD_INT_MASK,
+ config & DP_DP_HPD_INT_MASK);
+}
+
+void dp_catalog_ctrl_hpd_config(struct dp_catalog *dp_catalog)
+{
+ struct dp_catalog_private *catalog = container_of(dp_catalog,
+ struct dp_catalog_private, dp_catalog);
+
+ u32 reftimer = dp_read_aux(catalog, REG_DP_DP_HPD_REFTIMER);
+
+ /* enable HPD interrupts */
+ dp_catalog_hpd_config_intr(dp_catalog,
+ DP_DP_HPD_PLUG_INT_MASK | DP_DP_IRQ_HPD_INT_MASK
+ | DP_DP_HPD_UNPLUG_INT_MASK, true);
+
+ /* Configure REFTIMER and enable it */
+ reftimer |= DP_DP_HPD_REFTIMER_ENABLE;
+ dp_write_aux(catalog, REG_DP_DP_HPD_REFTIMER, reftimer);
+
+ /* Enable HPD */
+ dp_write_aux(catalog, REG_DP_DP_HPD_CTRL, DP_DP_HPD_CTRL_HPD_EN);
+}
+
+u32 dp_catalog_hpd_get_intr_status(struct dp_catalog *dp_catalog)
+{
+ struct dp_cata
[PATCH v12 4/5] drm/msm/dpu: add display port support in DPU
From: Jeykumar Sankaran
Add display port support in DPU by creating hooks
for DP encoder enumeration and encoder mode
initialization.
changes in v2:
- rebase on [2] (Sean Paul)
- remove unwanted error checks and
switch cases (Jordan Crouse)
[1] https://lwn.net/Articles/768265/
[2] https://lkml.org/lkml/2018/11/17/87
changes in V3:
-- Moved this change as part of the DP driver changes.
-- Addressed compilation issues on the latest code base.
Changes in v6:
-- Fix checkpatch.pl warning
Changes in v7: Remove depends-on tag from commit message.
Changes in v8: None
Changes in v9: None
Signed-off-by: Jeykumar Sankaran
Signed-off-by: Chandan Uddaraju
Signed-off-by: Vara Reddy
Signed-off-by: Tanmay Shah
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 8 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 65 +
2 files changed, 58 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 8b14d7c42f37..6a9e257d2fe6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -2025,7 +2025,7 @@ static int dpu_encoder_setup_display(struct
dpu_encoder_virt *dpu_enc,
{
int ret = 0;
int i = 0;
- enum dpu_intf_type intf_type;
+ enum dpu_intf_type intf_type = INTF_NONE;
struct dpu_enc_phys_init_params phys_params;
if (!dpu_enc) {
@@ -2047,9 +2047,9 @@ static int dpu_encoder_setup_display(struct
dpu_encoder_virt *dpu_enc,
case DRM_MODE_ENCODER_DSI:
intf_type = INTF_DSI;
break;
- default:
- DPU_ERROR_ENC(dpu_enc, "unsupported display interface type\n");
- return -EINVAL;
+ case DRM_MODE_ENCODER_TMDS:
+ intf_type = INTF_DP;
+ break;
}
WARN_ON(disp_info->num_of_h_tiles < 1);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index c0a4d4e16d82..62bc33cb0d3a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -479,6 +479,33 @@ static int _dpu_kms_initialize_dsi(struct drm_device *dev,
return rc;
}
+static int _dpu_kms_initialize_displayport(struct drm_device *dev,
+ struct msm_drm_private *priv,
+ struct dpu_kms *dpu_kms)
+{
+ struct drm_encoder *encoder = NULL;
+ int rc = 0;
+
+ if (!priv->dp)
+ return rc;
+
+ encoder = dpu_encoder_init(dev, DRM_MODE_ENCODER_TMDS);
+ if (IS_ERR(encoder)) {
+ DPU_ERROR("encoder init failed for dsi display\n");
+ return PTR_ERR(encoder);
+ }
+
+ rc = msm_dp_modeset_init(priv->dp, dev, encoder);
+ if (rc) {
+ DPU_ERROR("modeset_init failed for DP, rc = %d\n", rc);
+ drm_encoder_cleanup(encoder);
+ return rc;
+ }
+
+ priv->encoders[priv->num_encoders++] = encoder;
+ return rc;
+}
+
/**
* _dpu_kms_setup_displays - create encoders, bridges and connectors
* for underlying displays
@@ -491,12 +518,21 @@ static int _dpu_kms_setup_displays(struct drm_device *dev,
struct msm_drm_private *priv,
struct dpu_kms *dpu_kms)
{
- /**
-* Extend this function to initialize other
-* types of displays
-*/
+ int rc = 0;
+
+ rc = _dpu_kms_initialize_dsi(dev, priv, dpu_kms);
+ if (rc) {
+ DPU_ERROR("initialize_dsi failed, rc = %d\n", rc);
+ return rc;
+ }
- return _dpu_kms_initialize_dsi(dev, priv, dpu_kms);
+ rc = _dpu_kms_initialize_displayport(dev, priv, dpu_kms);
+ if (rc) {
+ DPU_ERROR("initialize_DP failed, rc = %d\n", rc);
+ return rc;
+ }
+
+ return rc;
}
static void _dpu_kms_drm_obj_destroy(struct dpu_kms *dpu_kms)
@@ -681,13 +717,20 @@ static void _dpu_kms_set_encoder_mode(struct msm_kms *kms,
info.capabilities = cmd_mode ? MSM_DISPLAY_CAP_CMD_MODE :
MSM_DISPLAY_CAP_VID_MODE;
- /* TODO: No support for DSI swap */
- for (i = 0; i < ARRAY_SIZE(priv->dsi); i++) {
- if (priv->dsi[i]) {
- info.h_tile_instance[info.num_of_h_tiles] = i;
- info.num_of_h_tiles++;
+ switch (info.intf_type) {
+ case DRM_MODE_ENCODER_DSI:
+ /* TODO: No support for DSI swap */
+ for (i = 0; i < ARRAY_SIZE(priv->dsi); i++) {
+ if (priv->dsi[i]) {
+ info.h_tile_instance[info.num_of_h_tiles] = i;
+ info.num_of_h_tiles++;
+ }
}
- }
+
[PATCH v12 0/5] Add support for DisplayPort driver on SnapDragon
These patches add Display-Port driver on SnapDragon/msm hardware. This series also contains device-tree bindings for msm DP driver. It also contains Makefile and Kconfig changes to compile msm DP driver. The block diagram of DP driver is shown below: +-+ |DRM FRAMEWORK| +--+--+ | +v+ | DP DRM | +++ | +v+ ++| DP+--++--+ ++---+| DISPLAY |+---+ | | |++-+-+-+| | | || | | | | | || | | | | | || | | | | | vv v v v v v +--+ +--+ +---+ ++ ++ +---+ +-+ | DP | | DP | |DP | | DP | | DP | |DP | | DP | |PARSER| | HPD | |AUX| |LINK| |CTRL| |PHY| |POWER| +--+---+ +---+--+ +---+ ++ +--+-+ +-+-+ +-+ | | | +--v---+ +v-v+ |DEVICE| | DP | | TREE | |CATALOG| +--+ +---+---+ | +---v+ |CTRL/PHY| | HW | ++ Changes in v12: -- Add support of pm ops in display port driver -- Clear bpp depth bits before writing to MISC register -- Fix edid read Previous change log: https://lkml.kernel.org/lkml/20200818051137.21478-1-tan...@codeaurora.org/ Chandan Uddaraju (4): dt-bindings: msm/dp: add bindings of DP/DP-PLL driver for Snapdragon drm: add constant N value in helper file drm/msm/dp: add displayPort driver support drm/msm/dp: add support for DP PLL driver Jeykumar Sankaran (1): drm/msm/dpu: add display port support in DPU Tanmay Shah (1): drm/msm/dp: Add Display Port HPD feature drivers/gpu/drm/i915/display/intel_display.c |2 +- drivers/gpu/drm/msm/Kconfig |9 + drivers/gpu/drm/msm/Makefile | 14 + drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 27 +- .../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c |8 + drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 83 +- drivers/gpu/drm/msm/dp/dp_aux.c | 535 ++ drivers/gpu/drm/msm/dp/dp_aux.h | 30 + drivers/gpu/drm/msm/dp/dp_catalog.c | 1045 ++ drivers/gpu/drm/msm/dp/dp_catalog.h | 105 + drivers/gpu/drm/msm/dp/dp_ctrl.c | 1693 + drivers/gpu/drm/msm/dp/dp_ctrl.h | 35 + drivers/gpu/drm/msm/dp/dp_display.c | 1046 ++ drivers/gpu/drm/msm/dp/dp_display.h | 31 + drivers/gpu/drm/msm/dp/dp_drm.c | 168 ++ drivers/gpu/drm/msm/dp/dp_drm.h | 18 + drivers/gpu/drm/msm/dp/dp_hpd.c | 69 + drivers/gpu/drm/msm/dp/dp_hpd.h | 79 + drivers/gpu/drm/msm/dp/dp_link.c | 1214 drivers/gpu/drm/msm/dp/dp_link.h | 132 ++ drivers/gpu/drm/msm/dp/dp_panel.c | 486 + drivers/gpu/drm/msm/dp/dp_panel.h | 95 + drivers/gpu/drm/msm/dp/dp_parser.c| 267 +++ drivers/gpu/drm/msm/dp/dp_parser.h| 138 ++ drivers/gpu/drm/msm/dp/dp_pll.c | 99 + drivers/gpu/drm/msm/dp/dp_pll.h | 61 + drivers/gpu/drm/msm/dp/dp_pll_10nm.c | 930 + drivers/gpu/drm/msm/dp/dp_pll_private.h | 89 + drivers/gpu/drm/msm/dp/dp_power.c | 373 drivers/gpu/drm/msm/dp/dp_power.h | 103 + drivers/gpu/drm/msm/dp/dp_reg.h | 518 + drivers/gpu/drm/msm/msm_drv.c |2 + drivers/gpu/drm/msm/msm_drv.h | 59 +- include/drm/drm_dp_helper.h |1 + 34 files changed, 9545 insertions(+), 19 deletions(-) create mode 100644 drivers/gpu/drm/msm/dp/dp_aux.c create mode 100644 drivers/gpu/drm/msm/dp/dp_aux.h create mode 100644 drivers/gpu/drm/msm/dp/dp_catalog.c create mode 100644 drivers/gpu/drm/msm/dp/dp_catalog.h create mode 100644 drivers/gpu/drm/msm/dp/dp_ctrl.c create mode 100644 drivers/gpu/drm/msm/dp/dp_ctrl.h create mode 100644 drivers/gpu/drm/msm/dp/dp_display.c create mode 100644 drivers/gpu/drm/msm/dp/dp_display.h create mode 100644 drivers/gpu/drm/msm/dp/dp_drm.c create mode 100644 drivers/gpu/drm/msm/dp/dp_drm.h create mode 100644 drivers/gpu/drm/msm/dp/dp_hpd.c create mode 100644 drivers/gpu/drm/msm/dp/dp_hpd.h create mode 100644 drivers/gpu/drm/msm/dp/dp_link.c create mode 100644 drivers/gpu/drm/msm/dp/dp_link.h create mode 100644 drivers/gpu/drm/msm/dp/dp_panel.c create mode 100644 drivers/gpu/drm
[PATCH v12 1/5] drm: add constant N value in helper file
From: Chandan Uddaraju The constant N value (0x8000) is used by i915 DP driver. Define this value in dp helper header file to use in multiple Display Port drivers. Change i915 driver accordingly. Change in v6: Change commit message Signed-off-by: Chandan Uddaraju Signed-off-by: Vara Reddy Signed-off-by: Tanmay Shah Reviewed-by: Stephen Boyd Acked-by: Jani Nikula --- drivers/gpu/drm/i915/display/intel_display.c | 2 +- include/drm/drm_dp_helper.h | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index b2ec3a5141cc..db959d9f8ebc 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -8114,7 +8114,7 @@ static void compute_m_n(unsigned int m, unsigned int n, * which the devices expect also in synchronous clock mode. */ if (constant_n) - *ret_n = 0x8000; + *ret_n = DP_LINK_CONSTANT_N_VALUE; else *ret_n = min_t(unsigned int, roundup_pow_of_two(n), DATA_LINK_N_MAX); diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index e47dc22ebf50..a31d7aebb8b8 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -1134,6 +1134,7 @@ #define DP_MST_PHYSICAL_PORT_0 0 #define DP_MST_LOGICAL_PORT_0 8 +#define DP_LINK_CONSTANT_N_VALUE 0x8000 #define DP_LINK_STATUS_SIZE 6 bool drm_dp_channel_eq_ok(const u8 link_status[DP_LINK_STATUS_SIZE], int lane_count); -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 209015] Clocks are no longer reported for R9 390 GPU
https://bugzilla.kernel.org/show_bug.cgi?id=209015 --- Comment #4 from HenryJiM (henryjm11...@gmail.com) --- I just retested, clocks actually are reported correctly with the Radeon driver. this issue is specific to the AMDGPU driver AMDGPU was loading regardless of kernel cmdline before: "radeon :29:00.0: CIK support disabled by module param" -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] staging: ion: remove from the tree
On Thu, Aug 27, 2020 at 10:17 AM Greg Kroah-Hartman wrote: > On Thu, Aug 27, 2020 at 10:31:41PM +0530, Amit Pundir wrote: > > I don't know what is the right thing to do here. I just want to > > highlight that AOSP's audio (codec2) HAL depends on the ION system > > heap and it will break AOSP for people who boot mainline on their > > devices, even for just testing purpose like we do in Linaro. Right now > > we need only 1 (Android specific out-of-tree) patch to boot AOSP with > > mainline and Sumit is already trying to upstream that vma naming > > patch. Removal of in-kernel ION, will just add more to that delta. > > As AOSP will continue to rely on ION after December of this year, all > you are doing is postponing the inevitable a few more months. > > Push back on the Android team to fix up the code to not use ION, they > know this needs to happen. The point though, is your main premise that no one is using this isn't true. I'm actively working with Hridya and folks on the codec2 HAL side to transition this on the userland side: https://android-review.googlesource.com/c/platform/frameworks/av/+/1368918/3 I'd like AOSP to not use ION after September (though being external I can't promise anything), much less continuing after December. I want this migration to happen as much as anyone. But I'd prefer to keep ION in staging until after the LTS is announced. Having both around helps development for the transition, which helps us have a reliable solution, which helps vendors to migrate and be able to do comparative performance testing. I do appreciate that keeping it isn't free, but I also don't feel the chaos-monkey approach here is really motivational in the way you intend. thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau: remove redundant check
From: Tom Rix clang static analysis flags this problem hw.c:271:12: warning: The left operand of '>=' is a garbage value if (pv.M1 >= pll_lim.vco1.min_m ... ~ ^ This is mostly not a problem because an early check in nouveau_hw_fix_bad_vpll() if (nvbios_pll_parse(bios, pll, &pll_lim)) return; nouveau_hw_get_pllvals(dev, pll, &pv); shadows a similar check in nouveau_hw_get_pllvals() ret = nvbios_pll_parse(bios, plltype, &pll_lim); if (ret || !(reg1 = pll_lim.reg)) return -ENOENT; Since the first check is redundant, remove it and check the status of nouveau_hw_get_pllvals(). Signed-off-by: Tom Rix --- drivers/gpu/drm/nouveau/dispnv04/hw.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/nouveau/dispnv04/hw.c b/drivers/gpu/drm/nouveau/dispnv04/hw.c index b674d68ef28a..b96c5628c33b 100644 --- a/drivers/gpu/drm/nouveau/dispnv04/hw.c +++ b/drivers/gpu/drm/nouveau/dispnv04/hw.c @@ -259,14 +259,12 @@ nouveau_hw_fix_bad_vpll(struct drm_device *dev, int head) struct nouveau_drm *drm = nouveau_drm(dev); struct nvif_device *device = &drm->client.device; struct nvkm_clk *clk = nvxx_clk(device); - struct nvkm_bios *bios = nvxx_bios(device); struct nvbios_pll pll_lim; struct nvkm_pll_vals pv; enum nvbios_pll_type pll = head ? PLL_VPLL1 : PLL_VPLL0; - if (nvbios_pll_parse(bios, pll, &pll_lim)) + if (nouveau_hw_get_pllvals(dev, pll, &pv)) return; - nouveau_hw_get_pllvals(dev, pll, &pv); if (pv.M1 >= pll_lim.vco1.min_m && pv.M1 <= pll_lim.vco1.max_m && pv.N1 >= pll_lim.vco1.min_n && pv.N1 <= pll_lim.vco1.max_n && -- 2.18.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 13/18] iommu/tegra: Add IOMMU_DOMAIN_DMA support
On 2020-08-27 16:45, Thierry Reding wrote: On Thu, Aug 20, 2020 at 04:08:32PM +0100, Robin Murphy wrote: Now that arch/arm is wired up for default domains and iommu-dma, implement the corresponding driver-side support for DMA domains. Signed-off-by: Robin Murphy --- drivers/iommu/tegra-smmu.c | 37 + 1 file changed, 21 insertions(+), 16 deletions(-) We can't do that yet because it will currently still break for use-cases such as display where we don't properly set up identity mappings during boot. The result is that the dma-iommu code will enable translations before the driver gets a chance to set up any mappings and if the display controller was left on by the bootloader, scanning out a splash screen, this causes faults between the point where dma-iommu is being set up for the display controller and where the display controller starts mapping its own buffers (rather than the ones mapped by the bootloader). Rest assured that I understand the situation all too well ;) As with tegra-gart, the unspoken point here is that since tegra-smmu implements of_xlate(), then arm_setup_iommu_dma_ops() must already be causing the exact same problem, no? This patch only seeks to move any existing behaviour over to the common backend, regardless of whether it was ever really appropriate in the first place. That said, I do have a series that I've been carrying around for longer than I've wanted that does exactly this for Tegra SMMU and I'd prefer if you could drop this particular change from your series so that I can keep working on resolving the identity mapping issues first. That would mean you'd see a functional change from the final patch, wherein nothing would ever be able to get translation unless drivers do their own explicit IOMMU API management. If you definitely want that change then OK, but it would still be nice to do it "properly" with IOMMU_DOMAIN_IDENTITY support, rather than just forcibly failing default domain allocation. I'm having a go at reworking the tegra-gart patch in that direction, so I can certainly try it for tegra-smmu as well. Robin. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] staging: ion: remove from the tree
On Thu, Aug 27, 2020 at 10:31:41PM +0530, Amit Pundir wrote: > On Thu, 27 Aug 2020 at 21:34, Greg Kroah-Hartman > wrote: > > > > On Thu, Aug 27, 2020 at 09:31:27AM -0400, Laura Abbott wrote: > > > On 8/27/20 8:36 AM, Greg Kroah-Hartman wrote: > > > > The ION android code has long been marked to be removed, now that we > > > > dma-buf support merged into the real part of the kernel. > > > > > > > > It was thought that we could wait to remove the ion kernel at a later > > > > time, but as the out-of-tree Android fork of the ion code has diverged > > > > quite a bit, and any Android device using the ion interface uses that > > > > forked version and not this in-tree version, the in-tree copy of the > > > > code is abandonded and not used by anyone. > > > > > > > > Combine this abandoned codebase with the need to make changes to it in > > > > order to keep the kernel building properly, which then causes merge > > > > issues when merging those changes into the out-of-tree Android code, and > > > > you end up with two different groups of people (the in-kernel-tree > > > > developers, and the Android kernel developers) who are both annoyed at > > > > the current situation. Because of this problem, just drop the in-kernel > > > > copy of the ion code now, as it's not used, and is only causing problems > > > > for everyone involved. > > > > > > > > Cc: "Arve Hjønnevåg" > > > > Cc: "Christian König" > > > > Cc: Christian Brauner > > > > Cc: Christoph Hellwig > > > > Cc: Hridya Valsaraju > > > > Cc: Joel Fernandes > > > > Cc: John Stultz > > > > Cc: Laura Abbott > > > > Cc: Martijn Coenen > > > > Cc: Shuah Khan > > > > Cc: Sumit Semwal > > > > Cc: Suren Baghdasaryan > > > > Cc: Todd Kjos > > > > Cc: de...@driverdev.osuosl.org > > > > Cc: dri-devel@lists.freedesktop.org > > > > Cc: linaro-mm-...@lists.linaro.org > > > > Signed-off-by: Greg Kroah-Hartman > > > > > > We discussed this at the Android MC on Monday and the plan was to > > > remove it after the next LTS release. > > > > I know it was discussed, my point is that it is actually causing > > problems now (with developers who want to change the internal kernel api > > hitting issues, and newbies trying to clean up code in ways that isn't > > exactly optimal wasting maintainer cycles), and that anyone who uses > > this code, is not actually using this version of the code. Everyone who > > relies on ion right now, is using the version that is in the Android > > common kernel tree, which has diverged from this in-kernel way quite a > > bit now for the reason that we didn't want to take any of those new > > features in the in-kernel version. > > > > So this is a problem that we have caused by just wanting to wait, no one > > is using this code, combined with it causing problems for the upstream > > developers. > > > > There is nothing "magic" about the last kernel of the year that requires > > this code to sit here until then. At that point in time, all users > > will, again, be using the forked Android kernel version, and if we > > delete this now here, that fork can remain just fine, with the added > > benifit of it reducing developer workloads here in-kernel. > > > > So why wait? > > Hi, > > I don't know what is the right thing to do here. I just want to > highlight that AOSP's audio (codec2) HAL depends on the ION system > heap and it will break AOSP for people who boot mainline on their > devices, even for just testing purpose like we do in Linaro. Right now > we need only 1 (Android specific out-of-tree) patch to boot AOSP with > mainline and Sumit is already trying to upstream that vma naming > patch. Removal of in-kernel ION, will just add more to that delta. As AOSP will continue to rely on ION after December of this year, all you are doing is postponing the inevitable a few more months. Push back on the Android team to fix up the code to not use ION, they know this needs to happen. thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915/vlv_dsi_pll: fix spelling mistake "Cant" -> "Can't"
On Mon, Aug 10, 2020 at 10:59:52AM +0100, Colin King wrote:
> From: Colin Ian King
>
> There is a spelling mistake in a drm_err message. Fix it.
Thanks. Applied to dinq.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/i915/display/vlv_dsi_pll.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/vlv_dsi_pll.c
> b/drivers/gpu/drm/i915/display/vlv_dsi_pll.c
> index d0a514301575..4070b00c3690 100644
> --- a/drivers/gpu/drm/i915/display/vlv_dsi_pll.c
> +++ b/drivers/gpu/drm/i915/display/vlv_dsi_pll.c
> @@ -483,7 +483,7 @@ int bxt_dsi_pll_compute(struct intel_encoder *encoder,
>
> if (dsi_ratio < dsi_ratio_min || dsi_ratio > dsi_ratio_max) {
> drm_err(&dev_priv->drm,
> - "Cant get a suitable ratio from DSI PLL ratios\n");
> + "Can't get a suitable ratio from DSI PLL ratios\n");
> return -ECHRNG;
> } else
> drm_dbg_kms(&dev_priv->drm, "DSI PLL calculation is Done!!\n");
> --
> 2.27.0
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/4] drm/plane: add drmm_universal_plane_alloc()
Add an alternative to drm_universal_plane_init() that allocates
and initializes a plane and registers drm_plane_cleanup() with
drmm_add_action_or_reset().
Signed-off-by: Philipp Zabel
---
Changes since v1:
- add __printf annotation to __drm_universal_plane_init() and make it static
---
drivers/gpu/drm/drm_plane.c | 130
include/drm/drm_plane.h | 42
2 files changed, 143 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index b7b90b3a2e38..ddf7f0724260 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include "drm_crtc_internal.h"
@@ -152,31 +153,16 @@ static int create_in_format_blob(struct drm_device *dev,
struct drm_plane *plane
return 0;
}
-/**
- * drm_universal_plane_init - Initialize a new universal plane object
- * @dev: DRM device
- * @plane: plane object to init
- * @possible_crtcs: bitmask of possible CRTCs
- * @funcs: callbacks for the new plane
- * @formats: array of supported formats (DRM_FORMAT\_\*)
- * @format_count: number of elements in @formats
- * @format_modifiers: array of struct drm_format modifiers terminated by
- *DRM_FORMAT_MOD_INVALID
- * @type: type of plane (overlay, primary, cursor)
- * @name: printf style format string for the plane name, or NULL for default
name
- *
- * Initializes a plane object of type @type.
- *
- * Returns:
- * Zero on success, error code on failure.
- */
-int drm_universal_plane_init(struct drm_device *dev, struct drm_plane *plane,
-uint32_t possible_crtcs,
-const struct drm_plane_funcs *funcs,
-const uint32_t *formats, unsigned int format_count,
-const uint64_t *format_modifiers,
-enum drm_plane_type type,
-const char *name, ...)
+__printf(9, 0)
+static int __drm_universal_plane_init(struct drm_device *dev,
+ struct drm_plane *plane,
+ uint32_t possible_crtcs,
+ const struct drm_plane_funcs *funcs,
+ const uint32_t *formats,
+ unsigned int format_count,
+ const uint64_t *format_modifiers,
+ enum drm_plane_type type,
+ const char *name, va_list ap)
{
struct drm_mode_config *config = &dev->mode_config;
unsigned int format_modifier_count = 0;
@@ -237,11 +223,7 @@ int drm_universal_plane_init(struct drm_device *dev,
struct drm_plane *plane,
}
if (name) {
- va_list ap;
-
- va_start(ap, name);
plane->name = kvasprintf(GFP_KERNEL, name, ap);
- va_end(ap);
} else {
plane->name = kasprintf(GFP_KERNEL, "plane-%d",
drm_num_planes(dev));
@@ -286,8 +268,98 @@ int drm_universal_plane_init(struct drm_device *dev,
struct drm_plane *plane,
return 0;
}
+
+/**
+ * drm_universal_plane_init - Initialize a new universal plane object
+ * @dev: DRM device
+ * @plane: plane object to init
+ * @possible_crtcs: bitmask of possible CRTCs
+ * @funcs: callbacks for the new plane
+ * @formats: array of supported formats (DRM_FORMAT\_\*)
+ * @format_count: number of elements in @formats
+ * @format_modifiers: array of struct drm_format modifiers terminated by
+ *DRM_FORMAT_MOD_INVALID
+ * @type: type of plane (overlay, primary, cursor)
+ * @name: printf style format string for the plane name, or NULL for default
name
+ *
+ * Initializes a plane object of type @type.
+ *
+ * Returns:
+ * Zero on success, error code on failure.
+ */
+int drm_universal_plane_init(struct drm_device *dev, struct drm_plane *plane,
+uint32_t possible_crtcs,
+const struct drm_plane_funcs *funcs,
+const uint32_t *formats, unsigned int format_count,
+const uint64_t *format_modifiers,
+enum drm_plane_type type,
+const char *name, ...)
+{
+ va_list ap;
+ int ret;
+
+ if (name)
+ va_start(ap, name);
+ ret = __drm_universal_plane_init(dev, plane, possible_crtcs, funcs,
+formats, format_count,
format_modifiers,
+type, name, ap);
+ if (name)
+ va_end(ap);
+ return ret;
+}
EXPORT_SYMBOL(drm_universal_plane_init);
+static void drmm_universal_plane_alloc_release(struct drm_device *dev, void
*ptr)
+{
+ struct drm_plane *plane =
[PATCH v2 1/4] drm: add drmm_encoder_alloc()
Add an alternative to drm_encoder_init() that allocates and initializes
an encoder and registers drm_encoder_cleanup() with
drmm_add_action_or_reset().
Signed-off-by: Philipp Zabel
---
Changes since v1:
- add __printf annotation to __drm_encoder_init()
---
drivers/gpu/drm/drm_encoder.c | 105 ++
include/drm/drm_encoder.h | 30 ++
2 files changed, 112 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
index e555281f43d4..de8c59087721 100644
--- a/drivers/gpu/drm/drm_encoder.c
+++ b/drivers/gpu/drm/drm_encoder.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include "drm_crtc_internal.h"
@@ -91,25 +92,11 @@ void drm_encoder_unregister_all(struct drm_device *dev)
}
}
-/**
- * drm_encoder_init - Init a preallocated encoder
- * @dev: drm device
- * @encoder: the encoder to init
- * @funcs: callbacks for this encoder
- * @encoder_type: user visible type of the encoder
- * @name: printf style format string for the encoder name, or NULL for default
name
- *
- * Initialises a preallocated encoder. Encoder should be subclassed as part of
- * driver encoder objects. At driver unload time drm_encoder_cleanup() should
be
- * called from the driver's &drm_encoder_funcs.destroy hook.
- *
- * Returns:
- * Zero on success, error code on failure.
- */
-int drm_encoder_init(struct drm_device *dev,
-struct drm_encoder *encoder,
-const struct drm_encoder_funcs *funcs,
-int encoder_type, const char *name, ...)
+__printf(5, 0)
+static int __drm_encoder_init(struct drm_device *dev,
+ struct drm_encoder *encoder,
+ const struct drm_encoder_funcs *funcs,
+ int encoder_type, const char *name, va_list ap)
{
int ret;
@@ -125,11 +112,7 @@ int drm_encoder_init(struct drm_device *dev,
encoder->encoder_type = encoder_type;
encoder->funcs = funcs;
if (name) {
- va_list ap;
-
- va_start(ap, name);
encoder->name = kvasprintf(GFP_KERNEL, name, ap);
- va_end(ap);
} else {
encoder->name = kasprintf(GFP_KERNEL, "%s-%d",
drm_encoder_enum_list[encoder_type].name,
@@ -150,6 +133,38 @@ int drm_encoder_init(struct drm_device *dev,
return ret;
}
+
+/**
+ * drm_encoder_init - Init a preallocated encoder
+ * @dev: drm device
+ * @encoder: the encoder to init
+ * @funcs: callbacks for this encoder
+ * @encoder_type: user visible type of the encoder
+ * @name: printf style format string for the encoder name, or NULL for default
name
+ *
+ * Initializes a preallocated encoder. Encoder should be subclassed as part of
+ * driver encoder objects. At driver unload time drm_encoder_cleanup() should
be
+ * called from the driver's &drm_encoder_funcs.destroy hook.
+ *
+ * Returns:
+ * Zero on success, error code on failure.
+ */
+int drm_encoder_init(struct drm_device *dev,
+struct drm_encoder *encoder,
+const struct drm_encoder_funcs *funcs,
+int encoder_type, const char *name, ...)
+{
+ va_list ap;
+ int ret;
+
+ if (name)
+ va_start(ap, name);
+ ret = __drm_encoder_init(dev, encoder, funcs, encoder_type, name, ap);
+ if (name)
+ va_end(ap);
+
+ return ret;
+}
EXPORT_SYMBOL(drm_encoder_init);
/**
@@ -181,6 +196,50 @@ void drm_encoder_cleanup(struct drm_encoder *encoder)
}
EXPORT_SYMBOL(drm_encoder_cleanup);
+static void drmm_encoder_alloc_release(struct drm_device *dev, void *ptr)
+{
+ struct drm_encoder *encoder = ptr;
+
+ if (WARN_ON(!encoder->dev))
+ return;
+
+ drm_encoder_cleanup(encoder);
+}
+
+void *__drmm_encoder_alloc(struct drm_device *dev, size_t size, size_t offset,
+ const struct drm_encoder_funcs *funcs,
+ int encoder_type, const char *name, ...)
+{
+ void *container;
+ struct drm_encoder *encoder;
+ va_list ap;
+ int ret;
+
+ if (WARN_ON(!funcs || funcs->destroy))
+ return ERR_PTR(-EINVAL);
+
+ container = drmm_kzalloc(dev, size, GFP_KERNEL);
+ if (!container)
+ return ERR_PTR(-EINVAL);
+
+ encoder = container + offset;
+
+ if (name)
+ va_start(ap, name);
+ ret = __drm_encoder_init(dev, encoder, funcs, encoder_type, name, ap);
+ if (name)
+ va_end(ap);
+ if (ret)
+ return ERR_PTR(ret);
+
+ ret = drmm_add_action_or_reset(dev, drmm_encoder_alloc_release,
encoder);
+ if (ret)
+ return ERR_PTR(ret);
+
+ return container;
+}
+EXPORT_SYMBOL(__drmm_encoder_alloc);
+
static struct drm_crtc *drm_encoder_get_crtc(struct drm_en
[PATCH v2 4/4] drm/crtc: add drmm_crtc_alloc_with_planes()
Add an alternative to drm_crtc_init_with_planes() that allocates
and initializes a crtc and registers drm_crtc_cleanup() with
drmm_add_action_or_reset().
Signed-off-by: Philipp Zabel
---
Changes since v1:
- fix drm_crtc_init_with_planes() to actually call
__drm_crtc_init_with_planes() instead of itself
- add __printf annotation to __drm_crtc_init_with_planes()
---
drivers/gpu/drm/drm_crtc.c | 120 -
include/drm/drm_crtc.h | 33 ++
2 files changed, 125 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 283bcc4362ca..c245746ccc46 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -231,30 +232,12 @@ struct dma_fence *drm_crtc_create_fence(struct drm_crtc
*crtc)
* Setting MODE_ID to 0 will release reserved resources for the CRTC.
*/
-/**
- * drm_crtc_init_with_planes - Initialise a new CRTC object with
- *specified primary and cursor planes.
- * @dev: DRM device
- * @crtc: CRTC object to init
- * @primary: Primary plane for CRTC
- * @cursor: Cursor plane for CRTC
- * @funcs: callbacks for the new CRTC
- * @name: printf style format string for the CRTC name, or NULL for default
name
- *
- * Inits a new object created as base part of a driver crtc object. Drivers
- * should use this function instead of drm_crtc_init(), which is only provided
- * for backwards compatibility with drivers which do not yet support universal
- * planes). For really simple hardware which has only 1 plane look at
- * drm_simple_display_pipe_init() instead.
- *
- * Returns:
- * Zero on success, error code on failure.
- */
-int drm_crtc_init_with_planes(struct drm_device *dev, struct drm_crtc *crtc,
- struct drm_plane *primary,
- struct drm_plane *cursor,
- const struct drm_crtc_funcs *funcs,
- const char *name, ...)
+__printf(6, 0)
+static int __drm_crtc_init_with_planes(struct drm_device *dev, struct drm_crtc
*crtc,
+ struct drm_plane *primary,
+ struct drm_plane *cursor,
+ const struct drm_crtc_funcs *funcs,
+ const char *name, va_list ap)
{
struct drm_mode_config *config = &dev->mode_config;
int ret;
@@ -282,11 +265,7 @@ int drm_crtc_init_with_planes(struct drm_device *dev,
struct drm_crtc *crtc,
return ret;
if (name) {
- va_list ap;
-
- va_start(ap, name);
crtc->name = kvasprintf(GFP_KERNEL, name, ap);
- va_end(ap);
} else {
crtc->name = kasprintf(GFP_KERNEL, "crtc-%d",
drm_num_crtcs(dev));
@@ -330,8 +309,93 @@ int drm_crtc_init_with_planes(struct drm_device *dev,
struct drm_crtc *crtc,
return 0;
}
+
+/**
+ * drm_crtc_init_with_planes - Initialise a new CRTC object with
+ *specified primary and cursor planes.
+ * @dev: DRM device
+ * @crtc: CRTC object to init
+ * @primary: Primary plane for CRTC
+ * @cursor: Cursor plane for CRTC
+ * @funcs: callbacks for the new CRTC
+ * @name: printf style format string for the CRTC name, or NULL for default
name
+ *
+ * Inits a new object created as base part of a driver crtc object. Drivers
+ * should use this function instead of drm_crtc_init(), which is only provided
+ * for backwards compatibility with drivers which do not yet support universal
+ * planes). For really simple hardware which has only 1 plane look at
+ * drm_simple_display_pipe_init() instead.
+ *
+ * Returns:
+ * Zero on success, error code on failure.
+ */
+int drm_crtc_init_with_planes(struct drm_device *dev, struct drm_crtc *crtc,
+ struct drm_plane *primary,
+ struct drm_plane *cursor,
+ const struct drm_crtc_funcs *funcs,
+ const char *name, ...)
+{
+ va_list ap;
+ int ret;
+
+ if (name)
+ va_start(ap, name);
+ ret = __drm_crtc_init_with_planes(dev, crtc, primary, cursor, funcs,
+ name, ap);
+ if (name)
+ va_end(ap);
+
+ return ret;
+}
EXPORT_SYMBOL(drm_crtc_init_with_planes);
+static void drmm_crtc_alloc_with_planes_cleanup(struct drm_device *dev,
+ void *ptr)
+{
+ struct drm_crtc *crtc = ptr;
+
+ drm_crtc_cleanup(crtc);
+}
+
+void *__drmm_crtc_alloc_with_planes(struct drm_device *dev,
+ size_t size, size_t offset,
+ struct drm_plane *primary,
+ struct drm_plane *cursor,
[PATCH v2 2/4] drm/simple_kms_helper: add drmm_simple_encoder_alloc()
Add an alternative to drm_simple_encoder_init() that allocates and
initializes a simple encoder and registers drm_encoder_cleanup() with
drmm_add_action_or_reset().
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/drm_simple_kms_helper.c | 12
include/drm/drm_simple_kms_helper.h | 24
2 files changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
b/drivers/gpu/drm/drm_simple_kms_helper.c
index 74946690aba4..3cbbfb0f9b51 100644
--- a/drivers/gpu/drm/drm_simple_kms_helper.c
+++ b/drivers/gpu/drm/drm_simple_kms_helper.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -71,6 +72,17 @@ int drm_simple_encoder_init(struct drm_device *dev,
}
EXPORT_SYMBOL(drm_simple_encoder_init);
+static const struct drm_encoder_funcs drmm_simple_encoder_funcs_empty = { };
+
+void *__drmm_simple_encoder_alloc(struct drm_device *dev, size_t size,
+ size_t offset, int encoder_type)
+{
+ return __drmm_encoder_alloc(dev, size, offset,
+ &drmm_simple_encoder_funcs_empty,
+ encoder_type, NULL);
+}
+EXPORT_SYMBOL(__drmm_simple_encoder_alloc);
+
static enum drm_mode_status
drm_simple_kms_crtc_mode_valid(struct drm_crtc *crtc,
const struct drm_display_mode *mode)
diff --git a/include/drm/drm_simple_kms_helper.h
b/include/drm/drm_simple_kms_helper.h
index a026375464ff..e6dbf3161c2f 100644
--- a/include/drm/drm_simple_kms_helper.h
+++ b/include/drm/drm_simple_kms_helper.h
@@ -185,4 +185,28 @@ int drm_simple_encoder_init(struct drm_device *dev,
struct drm_encoder *encoder,
int encoder_type);
+void *__drmm_simple_encoder_alloc(struct drm_device *dev, size_t size,
+ size_t offset, int encoder_type);
+
+/**
+ * drmm_simple_encoder_alloc - Allocate and initialize an encoder with basic
+ * functionality.
+ * @dev: drm device
+ * @type: the type of the struct which contains struct &drm_encoder
+ * @member: the name of the &drm_encoder within @type.
+ * @encoder_type: user visible type of the encoder
+ *
+ * Allocates and initializes an encoder that has no further functionality.
+ * Settings for possible CRTC and clones are left to their initial values.
+ * Cleanup is automatically handled through registering drm_encoder_cleanup()
+ * with drmm_add_action().
+ *
+ * Returns:
+ * Pointer to new encoder, or ERR_PTR on failure.
+ */
+#define drmm_simple_encoder_alloc(dev, type, member, encoder_type) \
+ ((type *)__drmm_simple_encoder_alloc(dev, sizeof(type), \
+offsetof(type, member), \
+encoder_type))
+
#endif /* __LINUX_DRM_SIMPLE_KMS_HELPER_H */
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] staging: ion: remove from the tree
On Thu, Aug 27, 2020 at 09:31:27AM -0400, Laura Abbott wrote: > On 8/27/20 8:36 AM, Greg Kroah-Hartman wrote: > > The ION android code has long been marked to be removed, now that we > > dma-buf support merged into the real part of the kernel. > > > > It was thought that we could wait to remove the ion kernel at a later > > time, but as the out-of-tree Android fork of the ion code has diverged > > quite a bit, and any Android device using the ion interface uses that > > forked version and not this in-tree version, the in-tree copy of the > > code is abandonded and not used by anyone. > > > > Combine this abandoned codebase with the need to make changes to it in > > order to keep the kernel building properly, which then causes merge > > issues when merging those changes into the out-of-tree Android code, and > > you end up with two different groups of people (the in-kernel-tree > > developers, and the Android kernel developers) who are both annoyed at > > the current situation. Because of this problem, just drop the in-kernel > > copy of the ion code now, as it's not used, and is only causing problems > > for everyone involved. > > > > Cc: "Arve Hjønnevåg" > > Cc: "Christian König" > > Cc: Christian Brauner > > Cc: Christoph Hellwig > > Cc: Hridya Valsaraju > > Cc: Joel Fernandes > > Cc: John Stultz > > Cc: Laura Abbott > > Cc: Martijn Coenen > > Cc: Shuah Khan > > Cc: Sumit Semwal > > Cc: Suren Baghdasaryan > > Cc: Todd Kjos > > Cc: de...@driverdev.osuosl.org > > Cc: dri-devel@lists.freedesktop.org > > Cc: linaro-mm-...@lists.linaro.org > > Signed-off-by: Greg Kroah-Hartman > > We discussed this at the Android MC on Monday and the plan was to > remove it after the next LTS release. I know it was discussed, my point is that it is actually causing problems now (with developers who want to change the internal kernel api hitting issues, and newbies trying to clean up code in ways that isn't exactly optimal wasting maintainer cycles), and that anyone who uses this code, is not actually using this version of the code. Everyone who relies on ion right now, is using the version that is in the Android common kernel tree, which has diverged from this in-kernel way quite a bit now for the reason that we didn't want to take any of those new features in the in-kernel version. So this is a problem that we have caused by just wanting to wait, no one is using this code, combined with it causing problems for the upstream developers. There is nothing "magic" about the last kernel of the year that requires this code to sit here until then. At that point in time, all users will, again, be using the forked Android kernel version, and if we delete this now here, that fork can remain just fine, with the added benifit of it reducing developer workloads here in-kernel. So why wait? thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH][next] drm/amdgpu/swsmu: fix potential uint32_t multiplication overflow
From: Colin Ian King
The calculation of tmp64 is performed using a 32 bit multiply and then
is stored in the uint64_t variable tmp64. This indicates that a 64 bit
result may be expected, so cast crystal_clock_freq to a uint64_t
to ensure a 64 bit multiplication is being performed to avoid any
potential 32 bit overflow.
Addresses-Coverity: ("Unintentional integer overflow)"
Fixes: 13819ef6453c ("drm/amdgpu/swsmu: add smu11 helpers to get manual fan
speeds")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c
b/drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c
index d2a15e6f48be..0a5161d09722 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c
@@ -1218,7 +1218,7 @@ int smu_v11_0_get_fan_speed_rpm(struct smu_context *smu,
crystal_clock_freq = amdgpu_asic_get_xclk(adev);
- tmp64 = 60 * crystal_clock_freq * 1;
+ tmp64 = (uint64_t)crystal_clock_freq * 60 * 1;
do_div(tmp64, (tach_period * 8));
*speed = (uint32_t)tmp64;
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 16/18] staging/media/tegra-vde: Clean up IOMMU workaround
On Thu, Aug 27, 2020 at 10:05:14AM +0300, Dmitry Osipenko wrote: > 24.08.2020 17:01, Robin Murphy пишет: > ... > >> Robin, thank you very much for the clarifications! > >> > >> In accordance to yours comments, this patch can't be applied until Tegra > >> SMMU will support IOMMU_DOMAIN_IDENTITY and implement def_domain_type() > >> callback that returns IOMMU_DOMAIN_IDENTITY for the VDE device. > >> > >> Otherwise you're breaking the VDE driver because > >> dma_buf_map_attachment() [1] returns the IOMMU SGT of the implicit > >> domain which is then mapped into the VDE's explicit domain [2], and this > >> is a nonsense. > > > > It's true that iommu_dma_ops will do some work in the unattached default > > domain, but non-coherent cache maintenance will still be performed > > correctly on the underlying memory, which is really all that you care > > about for this case. As for tegra_vde_iommu_map(), that seems to do the > > right thing in only referencing the physical side of the scatterlist > > (via iommu_map_sg()) and ignoring the DMA side, so things ought to work > > out OK even if it is a little non-obvious. > > I'll need to double-check this, it's indeed not clear to me right now. > > I see that if Tegra DRM driver uses implicit IOMMU domain, then when VDE > driver imports DMA-buf from Terga DRM and the imported buffer will be > auto-mapped to the implicit VDE IOVA [1]. > > [1] > https://elixir.bootlin.com/linux/v5.9-rc2/source/drivers/gpu/drm/tegra/gem.c#L574 > > >> Hence, either VDE driver should bypass iommu_dma_ops from the start or > >> it needs a way to kick out the ops, like it does this using ARM's > >> arm_iommu_detach_device(). > >> > >> > >> The same applies to the Tegra GPU devices, otherwise you're breaking > >> them as well because Tegra DRM is sensible to implicit vs explicit > >> domain. > > > > Note that Tegra DRM will only be as broken as its current state on > > arm64, and I was under the impression that that was OK now - at least I > > don't recall seeing any complaints since 43c5bf11a610. Although that > > commit and the one before it are resolving the scalability issue that > > they describe, it was very much in my mind at the time that they also > > have the happy side-effect described above - the default domain isn't > > *completely* out of the way, but it's far enough that sensible cases > > should be able to work as expected. > > The Tegra DRM has a very special quirk for ARM32 that was added in this > commit [2] and driver relies on checking of whether explicit or implicit > IOMMU is used in order to activate the quirk. > > [2] > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=273da5a046965ccf0ec79eb63f2d5173467e20fa > > Once the implicit IOMMU is used for the DRM driver, the quirk no longer > works (if I'm not missing something). This problem needs to be resolved > before implicit IOMMU could be used by the Tegra DRM on ARM32. > > >> BTW, I tried to apply this series and T30 doesn't boot anymore. I don't > >> have more info for now. > > > > Yeah, I'm still trying to get to the bottom of whether it's actually > > working as intended at all, even on my RK3288. So far my debugging > > instrumentation has been confusingly inconclusive :/ > > Surely it will take some time to resolve all the problems and it's great > that you're pushing this work! > > I'll try to help with fixing the ARM32 Tegra side of the problems. I > added this to my "TODO" list and should be able to take a closer look > during of this/next weeks! I do have a patch lying around somewhere that implements the mapping cache that was referenced in the above commit. Let me know if I should dig that up and send it out. Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 13/18] iommu/tegra: Add IOMMU_DOMAIN_DMA support
On Thu, Aug 20, 2020 at 04:08:32PM +0100, Robin Murphy wrote: > Now that arch/arm is wired up for default domains and iommu-dma, > implement the corresponding driver-side support for DMA domains. > > Signed-off-by: Robin Murphy > --- > drivers/iommu/tegra-smmu.c | 37 + > 1 file changed, 21 insertions(+), 16 deletions(-) We can't do that yet because it will currently still break for use-cases such as display where we don't properly set up identity mappings during boot. The result is that the dma-iommu code will enable translations before the driver gets a chance to set up any mappings and if the display controller was left on by the bootloader, scanning out a splash screen, this causes faults between the point where dma-iommu is being set up for the display controller and where the display controller starts mapping its own buffers (rather than the ones mapped by the bootloader). That said, I do have a series that I've been carrying around for longer than I've wanted that does exactly this for Tegra SMMU and I'd prefer if you could drop this particular change from your series so that I can keep working on resolving the identity mapping issues first. Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Experimental DMA-BUF Device Heaps
On Thursday, August 20, 2020 10:15 AM, Ezequiel Garcia wrote: > > I'm rather interested on where this goes, as I was toying with using > > some sort of heap ID as a basis for a "device-local" constraint in the > > memory constraints proposals Simon and I will be discussing at XDC this > > year. It would be rather elegant if there was one type of heap ID used > > universally throughout the kernel that could provide a unique handle for > > the shared system memory heap(s), as well as accelerator-local heaps on > > fancy NICs, GPUs, NN accelerators, capture devices, etc. so apps could > > negotiate a location among themselves. This patch seems to be a step > > towards that in a way, but I agree it would be counterproductive if a > > bunch of devices that were using the same underlying system memory ended > > up each getting their own heap ID just because they used some SW > > framework that worked that way. > > Would appreciate it if you could send along a pointer to your BoF if it > > happens! > > Here is it: > > https://linuxplumbersconf.org/event/7/contributions/818/ > > It would be great to see you there and discuss this, > given I was hoping we could talk about how to meet a > userspace allocator library expectations as well. Unfortunately there's no livestream for BoFs. Would be very interested in having a summary of the discussions once the BoF is over! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Aw: Re: [PATCH v5 3/7] drm/mediatek: disable tmds on mt2701
On 27/08/2020 15:41, Frank Wunderlich wrote: Hi Matthias, any opinions about the dts-changes? they look good to me. maybe series except the tmds-Patch get merged...so i add it only to my own repo till we find a better way? currently mainline does not support hdmi at all for the board. the tmds-patch is only a fix for specific resolutions which have a "flickering" without this Patch. Well let's see what CK's opinion. Regards, Matthias ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 13/20] drm/i915/dp: Extract drm_dp_read_downstream_info()
On Wed, 26 Aug 2020, Lyude Paul wrote:
> We're going to be doing the same probing process in nouveau for
> determining downstream DP port capabilities, so let's deduplicate the
> work by moving i915's code for handling this into a shared helper:
> drm_dp_read_downstream_info().
>
> Note that when we do this, we also do make some functional changes while
> we're at it:
> * We always clear the downstream port info before trying to read it,
> just to make things easier for the caller
> * We skip reading downstream port info if the DPCD indicates that we
> don't support downstream port info
> * We only read as many bytes as needed for the reported number of
> downstream ports, no sense in reading the whole thing every time
>
> v2:
> * Fixup logic for calculating the downstream port length to account for
> the fact that downstream port caps can be either 1 byte or 4 bytes
> long. We can actually skip fixing the max_clock/max_bpc helpers here
> since they all check for DP_DETAILED_CAP_INFO_AVAILABLE anyway.
> * Fix ret code check for drm_dp_dpcd_read
> v5:
> * Change name from drm_dp_downstream_read_info() to
> drm_dp_read_downstream_info()
> * Also, add "See Also" sections for the various downstream info
> functions (drm_dp_read_downstream_info(), drm_dp_downstream_max_clock(),
> drm_dp_downstream_max_bpc())
>
> Reviewed-by: Sean Paul
> Signed-off-by: Lyude Paul
>
> squash! drm/i915/dp: Extract drm_dp_read_downstream_info()
Whoops!
>
> Signed-off-by: Lyude Paul
> ---
> drivers/gpu/drm/drm_dp_helper.c | 62 -
> drivers/gpu/drm/i915/display/intel_dp.c | 14 +-
> include/drm/drm_dp_helper.h | 3 ++
> 3 files changed, 65 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 4c21cf69dad5a..f3643894ad951 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -423,6 +423,56 @@ bool drm_dp_send_real_edid_checksum(struct drm_dp_aux
> *aux,
> }
> EXPORT_SYMBOL(drm_dp_send_real_edid_checksum);
>
> +static u8 drm_dp_downstream_port_count(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
> +{
> + u8 port_count = dpcd[DP_DOWN_STREAM_PORT_COUNT] & DP_PORT_COUNT_MASK;
> +
> + if (dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DETAILED_CAP_INFO_AVAILABLE &&
> port_count > 4)
> + port_count = 4;
> +
> + return port_count;
> +}
> +
> +/**
> + * drm_dp_read_downstream_info() - read DPCD downstream port info if
> available
> + * @aux: DisplayPort AUX channel
> + * @dpcd: A cached copy of the port's DPCD
> + * @downstream_ports: buffer to store the downstream port info in
> + *
> + * See also:
> + * drm_dp_downstream_max_clock()
> + * drm_dp_downstream_max_bpc()
> + *
> + * Returns: 0 if either the downstream port info was read successfully or
> + * there was no downstream info to read, or a negative error code otherwise.
> + */
> +int drm_dp_read_downstream_info(struct drm_dp_aux *aux,
> + const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> + u8 downstream_ports[DP_MAX_DOWNSTREAM_PORTS])
> +{
> + int ret;
> + u8 len;
> +
> + memset(downstream_ports, 0, DP_MAX_DOWNSTREAM_PORTS);
> +
> + /* No downstream info to read */
> + if (!drm_dp_is_branch(dpcd) ||
> + dpcd[DP_DPCD_REV] < DP_DPCD_REV_10 ||
> + !(dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT))
> + return 0;
Generally I think stuff like this is easier and faster to read with
multiple if statements and early returns, but *shrug*.
I really hope we didn't have a reason to not check
DP_DWN_STRM_PORT_PRESENT here... there's been a lot of junk branch
devices in the past. Fingers crossed.
Reviewed-by: Jani Nikula
> +
> + len = drm_dp_downstream_port_count(dpcd);
> + if (dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DETAILED_CAP_INFO_AVAILABLE)
> + len *= 4;
> +
> + ret = drm_dp_dpcd_read(aux, DP_DOWNSTREAM_PORT_0, downstream_ports,
> len);
> + if (ret < 0)
> + return ret;
> +
> + return ret == len ? 0 : -EIO;
> +}
> +EXPORT_SYMBOL(drm_dp_read_downstream_info);
> +
> /**
> * drm_dp_downstream_max_clock() - extract branch device max
> * pixel rate for legacy VGA
> @@ -431,7 +481,11 @@ EXPORT_SYMBOL(drm_dp_send_real_edid_checksum);
> * @dpcd: DisplayPort configuration data
> * @port_cap: port capabilities
> *
> - * Returns max clock in kHz on success or 0 if max clock not defined
> + * See also:
> + * drm_dp_read_downstream_info()
> + * drm_dp_downstream_max_bpc()
> + *
> + * Returns: Max clock in kHz on success or 0 if max clock not defined
> */
> int drm_dp_downstream_max_clock(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> const u8 port_cap[4])
> @@ -462,7 +516,11 @@ EXPORT_SYMBOL(drm_dp_downstream_max_clock);
> * @dpcd: DisplayPort configuration data
> * @port_cap: port capabilities
> *
Re: [PATCH] drm/radeon: Prefer lower feedback dividers
Applied. Thanks!
Alex
On Thu, Aug 27, 2020 at 7:18 AM Christian König
wrote:
>
> Am 25.08.20 um 19:33 schrieb Kai-Heng Feng:
> > Commit 2e26ccb119bd ("drm/radeon: prefer lower reference dividers")
> > fixed screen flicker for HP Compaq nx9420 but breaks other laptops like
> > Asus X50SL.
> >
> > Turns out we also need to favor lower feedback dividers.
>
> Mhm, let's hope that this works out for all others as well :)
>
> >
> > Users confirmed this change fixes the regression and doesn't regress the
> > original fix.
> >
> > Fixes: 2e26ccb119bd ("drm/radeon: prefer lower reference dividers")
> > BugLink: https://bugs.launchpad.net/bugs/1791312
> > BugLink: https://bugs.launchpad.net/bugs/1861554
> > Signed-off-by: Kai-Heng Feng
>
> Reviewed-by: Christian König
>
> > ---
> > drivers/gpu/drm/radeon/radeon_display.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/radeon/radeon_display.c
> > b/drivers/gpu/drm/radeon/radeon_display.c
> > index e0ae911ef427..7b69d6dfe44a 100644
> > --- a/drivers/gpu/drm/radeon/radeon_display.c
> > +++ b/drivers/gpu/drm/radeon/radeon_display.c
> > @@ -933,7 +933,7 @@ static void avivo_get_fb_ref_div(unsigned nom, unsigned
> > den, unsigned post_div,
> >
> > /* get matching reference and feedback divider */
> > *ref_div = min(max(den/post_div, 1u), ref_div_max);
> > - *fb_div = DIV_ROUND_CLOSEST(nom * *ref_div * post_div, den);
> > + *fb_div = max(nom * *ref_div * post_div / den, 1u);
> >
> > /* limit fb divider to its maximum */
> > if (*fb_div > fb_div_max) {
>
> ___
> 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
Re: [PATCH v5 09/20] drm/i915/dp: Extract drm_dp_read_mst_cap()
On Wed, 26 Aug 2020, Lyude Paul wrote:
> Just a tiny drive-by cleanup, we can consolidate i915's code for
> checking for MST support into a helper to be shared across drivers.
>
> v5:
> * Drop !!()
> * Move drm_dp_has_mst() out of header
> * Change name from drm_dp_has_mst() to drm_dp_read_mst_cap()
>
> Signed-off-by: Lyude Paul
> Reviewed-by: Sean Paul
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 22 ++
> drivers/gpu/drm/i915/display/intel_dp.c | 18 ++
> include/drm/drm_dp_mst_helper.h | 3 +--
> 3 files changed, 25 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 67dd72ea200e0..17dbed0a9800d 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -3486,6 +3486,28 @@ static int drm_dp_get_vc_payload_bw(u8 dp_link_bw, u8
> dp_link_count)
> return dp_link_bw * dp_link_count / 2;
> }
>
> +/**
> + * drm_dp_read_mst_cap() - check whether or not a sink supports MST
> + * @aux: The DP AUX channel to use
> + * @dpcd: A cached copy of the DPCD capabilities for this sink
> + *
> + * Returns: %True if the sink supports MST, %false otherwise
> + */
> +bool drm_dp_read_mst_cap(struct drm_dp_aux *aux,
> + const u8 dpcd[DP_RECEIVER_CAP_SIZE])
> +{
> + u8 mstm_cap;
> +
> + if (dpcd[DP_DPCD_REV] < DP_DPCD_REV_12)
> + return false;
> +
> + if (drm_dp_dpcd_readb(aux, DP_MSTM_CAP, &mstm_cap) != 1)
> + return false;
> +
> + return mstm_cap & DP_MST_CAP;
> +}
> +EXPORT_SYMBOL(drm_dp_read_mst_cap);
> +
> /**
> * drm_dp_mst_topology_mgr_set_mst() - Set the MST state for a topology
> manager
> * @mgr: manager to set state for
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 79c27f91f42c0..4c7314b7a84e4 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4699,20 +4699,6 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
> return true;
> }
>
> -static bool
> -intel_dp_sink_can_mst(struct intel_dp *intel_dp)
> -{
> - u8 mstm_cap;
> -
> - if (intel_dp->dpcd[DP_DPCD_REV] < 0x12)
> - return false;
> -
> - if (drm_dp_dpcd_readb(&intel_dp->aux, DP_MSTM_CAP, &mstm_cap) != 1)
> - return false;
> -
> - return mstm_cap & DP_MST_CAP;
> -}
> -
> static bool
> intel_dp_can_mst(struct intel_dp *intel_dp)
> {
> @@ -4720,7 +4706,7 @@ intel_dp_can_mst(struct intel_dp *intel_dp)
>
> return i915->params.enable_dp_mst &&
> intel_dp->can_mst &&
> - intel_dp_sink_can_mst(intel_dp);
> + drm_dp_read_mst_cap(&intel_dp->aux, intel_dp->dpcd);
> }
>
> static void
> @@ -4729,7 +4715,7 @@ intel_dp_configure_mst(struct intel_dp *intel_dp)
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> struct intel_encoder *encoder =
> &dp_to_dig_port(intel_dp)->base;
> - bool sink_can_mst = intel_dp_sink_can_mst(intel_dp);
> + bool sink_can_mst = drm_dp_read_mst_cap(&intel_dp->aux, intel_dp->dpcd);
>
> drm_dbg_kms(&i915->drm,
> "[ENCODER:%d:%s] MST support: port: %s, sink: %s, modparam:
> %s\n",
> diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
> index 8b9eb4db3381c..6ae5860d8644e 100644
> --- a/include/drm/drm_dp_mst_helper.h
> +++ b/include/drm/drm_dp_mst_helper.h
> @@ -728,10 +728,9 @@ int drm_dp_mst_topology_mgr_init(struct
> drm_dp_mst_topology_mgr *mgr,
>
> void drm_dp_mst_topology_mgr_destroy(struct drm_dp_mst_topology_mgr *mgr);
>
> -
> +bool drm_dp_read_mst_cap(struct drm_dp_aux *aux, const u8
> dpcd[DP_RECEIVER_CAP_SIZE]);
> int drm_dp_mst_topology_mgr_set_mst(struct drm_dp_mst_topology_mgr *mgr,
> bool mst_state);
>
> -
> int drm_dp_mst_hpd_irq(struct drm_dp_mst_topology_mgr *mgr, u8 *esi, bool
> *handled);
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/1] AMDGPU : Fix bug in reporting voltage for CIK
Applied with some minor whitespace fixes. Thanks! Alex On Thu, Aug 27, 2020 at 9:13 AM Sandeep Raghuraman wrote: > > On my R9 390, the voltage was reported as a constant 1000 mV. This was due to > a bug in smu7_hwmgr.c, in the smu7_read_sensor() function, where some magic > constants were used in a condition, to determine whether the voltage should > be read from PLANE2_VID or PLANE1_VID. The VDDC mask was incorrectly used, > instead of the VDDGFX mask. > > This patch changes the code to use the correct defined constants (and apply > the correct bitshift), thus resulting in correct voltage reporting. > > Signed-off-by: Sandeep Raghuraman > --- > drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c > b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c > index 753cb2cf6b77..2be006dd2eb3 100644 > --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c > +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c > @@ -3587,7 +3587,7 @@ static int smu7_read_sensor(struct pp_hwmgr *hwmgr, int > idx, > case AMDGPU_PP_SENSOR_GPU_POWER: > return smu7_get_gpu_power(hwmgr, (uint32_t *)value); > case AMDGPU_PP_SENSOR_VDDGFX: > - if ((data->vr_config & 0xff) == 0x2) > + if ((data->vr_config & VRCONF_VDDGFX_MASK) == > VR_SVI2_PLANE_2< val_vid = PHM_READ_INDIRECT_FIELD(hwmgr->device, > CGS_IND_REG__SMC, PWR_SVI2_STATUS, > PLANE2_VID); > else > -- > ___ > 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
Re: [PATCH 1/1] AMDGPU: Specify get_argument function for ci_smu_funcs
Applied. Thanks!
Alex
On Thu, Aug 27, 2020 at 7:37 AM Sandeep Raghuraman wrote:
>
> Starting in Linux 5.8, the graphics and memory clock frequency were not being
> reported for CIK cards. This is a regression, since they were reported
> correctly in Linux 5.7. This was due to changes in commit
> a0ec225633d9f681e393a1827f29f02c837deb84.
>
> After investigation, I discovered that the smum_send_msg_to_smc() function,
> attempts to call the corresponding get_argument() function of ci_smu_funcs.
> However, the get_argument() function is not defined in ci_smu_funcs.
>
> This patch fixes the bug by specifying the correct get_argument() function.
>
> Signed-off-by: Sandeep Raghuraman
>
> ---
> drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c
> b/drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c
> index ad54f4500af1..63016c14b942 100644
> --- a/drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c
> @@ -37,6 +37,7 @@
> #include "cgs_common.h"
> #include "atombios.h"
> #include "pppcielanes.h"
> +#include "smu7_smumgr.h"
>
> #include "smu/smu_7_0_1_d.h"
> #include "smu/smu_7_0_1_sh_mask.h"
> @@ -2948,6 +2949,7 @@ const struct pp_smumgr_func ci_smu_funcs = {
> .request_smu_load_specific_fw = NULL,
> .send_msg_to_smc = ci_send_msg_to_smc,
> .send_msg_to_smc_with_parameter = ci_send_msg_to_smc_with_parameter,
> + .get_argument = smu7_get_argument,
> .download_pptable_settings = NULL,
> .upload_pptable_settings = NULL,
> .get_offsetof = ci_get_offsetof,
> --
> ___
> 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 1/1] AMDGPU : Fix bug in reporting voltage for CIK
On my R9 390, the voltage was reported as a constant 1000 mV. This was due to a bug in smu7_hwmgr.c, in the smu7_read_sensor() function, where some magic constants were used in a condition, to determine whether the voltage should be read from PLANE2_VID or PLANE1_VID. The VDDC mask was incorrectly used, instead of the VDDGFX mask. This patch changes the code to use the correct defined constants (and apply the correct bitshift), thus resulting in correct voltage reporting. Signed-off-by: Sandeep Raghuraman --- drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c index 753cb2cf6b77..2be006dd2eb3 100644 --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c @@ -3587,7 +3587,7 @@ static int smu7_read_sensor(struct pp_hwmgr *hwmgr, int idx, case AMDGPU_PP_SENSOR_GPU_POWER: return smu7_get_gpu_power(hwmgr, (uint32_t *)value); case AMDGPU_PP_SENSOR_VDDGFX: - if ((data->vr_config & 0xff) == 0x2) + if ((data->vr_config & VRCONF_VDDGFX_MASK) == VR_SVI2_PLANE_2
Re: Aw: [PATCH 00/18] Convert arch/arm to use iommu-dma
On 27/08/2020 14:31, Frank Wunderlich wrote: Tested full series on bananapi r2 (mt7623/mt2701, 5.9-rc1 + hdmi-patches), works so far fbcon+x without issues Tested-by: Frank Wunderlich Thanks for testing. Robin this is especially relevant for: [PATCH 09/18] iommu/mediatek-v1: Add IOMMU_DOMAIN_DMA support Regards, Matthias ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] staging: ion: remove from the tree
The ION android code has long been marked to be removed, now that we dma-buf support merged into the real part of the kernel. It was thought that we could wait to remove the ion kernel at a later time, but as the out-of-tree Android fork of the ion code has diverged quite a bit, and any Android device using the ion interface uses that forked version and not this in-tree version, the in-tree copy of the code is abandonded and not used by anyone. Combine this abandoned codebase with the need to make changes to it in order to keep the kernel building properly, which then causes merge issues when merging those changes into the out-of-tree Android code, and you end up with two different groups of people (the in-kernel-tree developers, and the Android kernel developers) who are both annoyed at the current situation. Because of this problem, just drop the in-kernel copy of the ion code now, as it's not used, and is only causing problems for everyone involved. Cc: "Arve Hjønnevåg" Cc: "Christian König" Cc: Christian Brauner Cc: Christoph Hellwig Cc: Hridya Valsaraju Cc: Joel Fernandes Cc: John Stultz Cc: Laura Abbott Cc: Martijn Coenen Cc: Shuah Khan Cc: Sumit Semwal Cc: Suren Baghdasaryan Cc: Todd Kjos Cc: de...@driverdev.osuosl.org Cc: dri-devel@lists.freedesktop.org Cc: linaro-mm-...@lists.linaro.org Signed-off-by: Greg Kroah-Hartman --- MAINTAINERS | 10 - drivers/staging/android/Kconfig | 2 - drivers/staging/android/Makefile | 2 - drivers/staging/android/TODO | 5 - drivers/staging/android/ion/Kconfig | 27 - drivers/staging/android/ion/Makefile | 4 - drivers/staging/android/ion/ion.c | 649 -- drivers/staging/android/ion/ion.h | 302 drivers/staging/android/ion/ion_cma_heap.c| 138 drivers/staging/android/ion/ion_heap.c| 286 drivers/staging/android/ion/ion_page_pool.c | 155 - drivers/staging/android/ion/ion_system_heap.c | 377 -- drivers/staging/android/uapi/ion.h| 127 tools/testing/selftests/Makefile | 3 +- tools/testing/selftests/android/Makefile | 39 -- tools/testing/selftests/android/config| 5 - .../testing/selftests/android/ion/.gitignore | 4 - tools/testing/selftests/android/ion/Makefile | 20 - tools/testing/selftests/android/ion/README| 101 --- tools/testing/selftests/android/ion/ion.h | 134 .../testing/selftests/android/ion/ion_test.sh | 58 -- .../selftests/android/ion/ionapp_export.c | 127 .../selftests/android/ion/ionapp_import.c | 79 --- .../selftests/android/ion/ionmap_test.c | 136 .../testing/selftests/android/ion/ionutils.c | 253 --- .../testing/selftests/android/ion/ionutils.h | 55 -- .../testing/selftests/android/ion/ipcsocket.c | 227 -- .../testing/selftests/android/ion/ipcsocket.h | 35 - tools/testing/selftests/android/run.sh| 3 - 29 files changed, 1 insertion(+), 3362 deletions(-) delete mode 100644 drivers/staging/android/ion/Kconfig delete mode 100644 drivers/staging/android/ion/Makefile delete mode 100644 drivers/staging/android/ion/ion.c delete mode 100644 drivers/staging/android/ion/ion.h delete mode 100644 drivers/staging/android/ion/ion_cma_heap.c delete mode 100644 drivers/staging/android/ion/ion_heap.c delete mode 100644 drivers/staging/android/ion/ion_page_pool.c delete mode 100644 drivers/staging/android/ion/ion_system_heap.c delete mode 100644 drivers/staging/android/uapi/ion.h delete mode 100644 tools/testing/selftests/android/Makefile delete mode 100644 tools/testing/selftests/android/config delete mode 100644 tools/testing/selftests/android/ion/.gitignore delete mode 100644 tools/testing/selftests/android/ion/Makefile delete mode 100644 tools/testing/selftests/android/ion/README delete mode 100644 tools/testing/selftests/android/ion/ion.h delete mode 100755 tools/testing/selftests/android/ion/ion_test.sh delete mode 100644 tools/testing/selftests/android/ion/ionapp_export.c delete mode 100644 tools/testing/selftests/android/ion/ionapp_import.c delete mode 100644 tools/testing/selftests/android/ion/ionmap_test.c delete mode 100644 tools/testing/selftests/android/ion/ionutils.c delete mode 100644 tools/testing/selftests/android/ion/ionutils.h delete mode 100644 tools/testing/selftests/android/ion/ipcsocket.c delete mode 100644 tools/testing/selftests/android/ion/ipcsocket.h delete mode 100755 tools/testing/selftests/android/run.sh diff --git a/MAINTAINERS b/MAINTAINERS index 0edac88f4a84..5df6fb4403fb 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1200,16 +1200,6 @@ S: Supported F: Documentation/devicetree/bindings/rtc/google,goldfish-rtc.txt F: drivers/rtc/rtc-goldfish.c -ANDROID ION DRIVER -M: Laura Abbott -M: Sumit Semwal -L: de...@driverdev.osuosl.org -L: dri-devel@li
Re: [PATCH v4 0/2] staging: android: Remove BUG/BUG_ON from ion
On Thu, Aug 27, 2020 at 08:16:54AM +0100, Christoph Hellwig wrote: > On Tue, Aug 25, 2020 at 08:52:29AM +0200, Greg Kroah-Hartman wrote: > > On Tue, Aug 25, 2020 at 07:47:29AM +0100, Christoph Hellwig wrote: > > > On Fri, Aug 21, 2020 at 06:27:04PM +0300, Tomer Samara wrote: > > > > Remove BUG/BUG_ON from androind/ion > > > > > > Please just remove ion. It has been rejected and we have developed > > > proper kernel subsystens to replace it. Don't waste your time on it. > > > > It is going to be removed at the end of this year. Why we keep it > > around until then, I really don't know, but John and Laura have this as > > the plan. > > It keeps getting in the way of various projects and has no path > going upstream properly. Seems weird to keep this dead and not all > that great code around. In looking at the mess of ion changes that are currently in the AOSP kernel tree (where android devices are pulled from), it looks almost nothing like what we currently have here in the mainline kernel tree. So if what we have here, today, is not of use to anyone who actually wants to use this interface, why are we keeping it around? John, why can't we just drop all of this code from the kernel today, and then Android will keep their own copy for their next LTS release anyway. It doesn't look like what we have here, and the merge issues it causes is a pain (as I know from having to do them...) So keeping this around in-tree any longer feels pointless to me, and actively causes me, and others, more work for no gain. I'll go make a patch set to just drop this code now... thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [00/23] ttm tt refactoring.
A repeating style nit pick that {} can be dropped on single line if and
empty line between declaration and code.
Apart from that looks mostly good to me :)
Patches #1-#4, #6, #10, #12-#15 are Reviewed-by: Christian König
Patch #5, #8, #9, #11 are Acked-by: Christian König
A few nits on patch #7.
Regarding patch #16 I'm not sure if the sub-classing into ttm_tt and
ttm_dma_tt is really worth it. I mean we can provide allocation helpers
for drivers which don't need the DMA address array. But apart from that
I'm pretty sure keeping the all fields in ttm_tt is the way to go.
Patch #17 has one little style comment.
I really need to take an in deep look at patches #18-#23, but the
general approach sounds like the right thing to do.
Christian.
Am 26.08.20 um 03:44 schrieb Dave Airlie:
This is based on top of misc-next with Christians io rework for nouveau.
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fairlied%2Flinux%2Ftree%2Fttm-tt-cleanup&data=02%7C01%7Cchristian.koenig%40amd.com%7C84fd18e47b124259c45a08d849619a9a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637340030838885795&sdata=WyDLcpJp07bSNxYPWovsnDkUIRDDmK3OlakW%2Fwy9HX4%3D&reserved=0
(is a complete tree)
The idea is to move towards ttm_tt being just a backing store for system
allocated pages + dma info, and not be anything to do with a global TT.
First is a couple of minor cleanups, then drops bdev from ttm_tt,
and moves the func table into the bdev driver table instead, makes
drivers deal with the agp differences, then cleans up the mess.
It tries to cleanup ttm_tt a bit more as well, in the end ttm_tt
is getting to what I'd like it to represent, the next step is tackling
the whole bind/unbind/move stuff I think.
Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 17/23] drm/ttm: split populated/bound state flags.
Am 26.08.20 um 03:44 schrieb Dave Airlie:
From: Dave Airlie
Get bound out is the next step.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo.c | 4 ++--
drivers/gpu/drm/radeon/radeon_mn.c | 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c| 4 ++--
drivers/gpu/drm/ttm/ttm_bo_util.c | 2 +-
drivers/gpu/drm/ttm/ttm_page_alloc.c | 6 +++---
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 6 +++---
drivers/gpu/drm/ttm/ttm_tt.c | 19 +--
drivers/gpu/drm/vmwgfx/vmwgfx_blit.c | 4 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 +-
include/drm/ttm/ttm_tt.h | 10 --
11 files changed, 30 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index adac24625191..c1c3691c3b9f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1301,7 +1301,7 @@ static int amdgpu_ttm_tt_populate(struct ttm_bo_device
*bdev,
return -ENOMEM;
ttm->page_flags |= TTM_PAGE_FLAG_SG;
- ttm->state = tt_unbound;
+ ttm->populated = true;
return 0;
}
@@ -1321,7 +1321,7 @@ static int amdgpu_ttm_tt_populate(struct ttm_bo_device *bdev,
drm_prime_sg_to_page_addr_arrays(gtt->ttm.sg, ttm->pages,
gtt->ttm.dma_address,
ttm->num_pages);
- ttm->state = tt_unbound;
+ ttm->populated = true;
return 0;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 478e498da965..e9de922ae921 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1264,14 +1264,14 @@ nouveau_ttm_tt_populate(struct ttm_bo_device *bdev,
struct device *dev;
bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
- if (ttm->state != tt_unpopulated)
+ if (ttm->populated)
return 0;
if (slave && ttm_dma->sg) {
/* make userspace faulting work */
drm_prime_sg_to_page_addr_arrays(ttm_dma->sg, ttm->pages,
ttm_dma->dma_address,
ttm->num_pages);
- ttm->state = tt_unbound;
+ ttm->populated = true;
return 0;
}
diff --git a/drivers/gpu/drm/radeon/radeon_mn.c b/drivers/gpu/drm/radeon/radeon_mn.c
index f93829f08a4d..5f57df7e6f08 100644
--- a/drivers/gpu/drm/radeon/radeon_mn.c
+++ b/drivers/gpu/drm/radeon/radeon_mn.c
@@ -53,7 +53,7 @@ static bool radeon_mn_invalidate(struct mmu_interval_notifier
*mn,
struct ttm_operation_ctx ctx = { false, false };
long r;
- if (!bo->tbo.ttm || bo->tbo.ttm->state != tt_bound)
+ if (!bo->tbo.ttm || bo->tbo.ttm->bound == false)
I think using ! instead of "== false" would look better here.
Christian.
return true;
if (!mmu_notifier_range_blockable(range))
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index f5cbe5d13d33..f9e4e64a6d64 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -615,14 +615,14 @@ static int radeon_ttm_tt_populate(struct ttm_bo_device
*bdev,
return -ENOMEM;
ttm->page_flags |= TTM_PAGE_FLAG_SG;
- ttm->state = tt_unbound;
+ ttm->populated = true;
return 0;
}
if (slave && gtt->ttm.sg) {
drm_prime_sg_to_page_addr_arrays(gtt->ttm.sg, ttm->pages,
gtt->ttm.dma_address,
ttm->num_pages);
- ttm->state = tt_unbound;
+ ttm->populated = true;
return 0;
}
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 3b17fe3cb57a..d5d841270e38 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -251,7 +251,7 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
* Don't move nonexistent data. Clear destination instead.
*/
if (old_iomap == NULL &&
- (ttm == NULL || (ttm->state == tt_unpopulated &&
+ (ttm == NULL || (!ttm->populated &&
!(ttm->page_flags & TTM_PAGE_FLAG_SWAPPED {
memset_io(new_iomap, 0, new_mem->num_pages*PAGE_SIZE);
goto out2;
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index b40a4678c296..2d30a2deadb5 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -1044,7 +1044,7 @@ ttm_pool_unpopulate_helper(struct ttm_tt *ttm, unsig
Re: [PATCH 07/23] drm/radeon/ttm: move to driver binding/destroy functions.
Am 26.08.20 um 03:44 schrieb Dave Airlie:
From: Dave Airlie
Do agp decision in the driver, instead of special binding funcs
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/radeon.h| 7 +-
drivers/gpu/drm/radeon/radeon_cs.c | 2 +-
drivers/gpu/drm/radeon/radeon_gem.c| 6 +-
drivers/gpu/drm/radeon/radeon_object.c | 2 +-
drivers/gpu/drm/radeon/radeon_prime.c | 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c| 92 --
drivers/gpu/drm/radeon/radeon_vm.c | 2 +-
7 files changed, 81 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index cc4f58d16589..df6f0b49836b 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -2815,10 +2815,11 @@ extern void radeon_legacy_set_clock_gating(struct
radeon_device *rdev, int enabl
extern void radeon_atom_set_clock_gating(struct radeon_device *rdev, int
enable);
extern void radeon_ttm_placement_from_domain(struct radeon_bo *rbo, u32
domain);
extern bool radeon_ttm_bo_is_radeon_bo(struct ttm_buffer_object *bo);
-extern int radeon_ttm_tt_set_userptr(struct ttm_tt *ttm, uint64_t addr,
+extern int radeon_ttm_tt_set_userptr(struct radeon_device *rdev,
+struct ttm_tt *ttm, uint64_t addr,
uint32_t flags);
-extern bool radeon_ttm_tt_has_userptr(struct ttm_tt *ttm);
-extern bool radeon_ttm_tt_is_readonly(struct ttm_tt *ttm);
+extern bool radeon_ttm_tt_has_userptr(struct radeon_device *rdev, struct
ttm_tt *ttm);
+extern bool radeon_ttm_tt_is_readonly(struct radeon_device *rdev, struct
ttm_tt *ttm);
extern void radeon_vram_location(struct radeon_device *rdev, struct radeon_mc
*mc, u64 base);
extern void radeon_gtt_location(struct radeon_device *rdev, struct radeon_mc
*mc);
extern int radeon_resume_kms(struct drm_device *dev, bool resume, bool fbcon);
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 33ae1b883268..21ce2f9502c0 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -160,7 +160,7 @@ static int radeon_cs_parser_relocs(struct radeon_cs_parser
*p)
p->relocs[i].allowed_domains = domain;
}
- if (radeon_ttm_tt_has_userptr(p->relocs[i].robj->tbo.ttm)) {
+ if (radeon_ttm_tt_has_userptr(p->rdev,
p->relocs[i].robj->tbo.ttm)) {
uint32_t domain = p->relocs[i].preferred_domains;
if (!(domain & RADEON_GEM_DOMAIN_GTT)) {
DRM_ERROR("Only RADEON_GEM_DOMAIN_GTT is "
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index 7f5dfe04789e..e5c4271e64ed 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -331,7 +331,7 @@ int radeon_gem_userptr_ioctl(struct drm_device *dev, void
*data,
goto handle_lockup;
bo = gem_to_radeon_bo(gobj);
- r = radeon_ttm_tt_set_userptr(bo->tbo.ttm, args->addr, args->flags);
+ r = radeon_ttm_tt_set_userptr(rdev, bo->tbo.ttm, args->addr,
args->flags);
if (r)
goto release_object;
@@ -420,7 +420,7 @@ int radeon_mode_dumb_mmap(struct drm_file *filp,
return -ENOENT;
}
robj = gem_to_radeon_bo(gobj);
- if (radeon_ttm_tt_has_userptr(robj->tbo.ttm)) {
+ if (radeon_ttm_tt_has_userptr(robj->rdev, robj->tbo.ttm)) {
drm_gem_object_put(gobj);
return -EPERM;
}
@@ -721,7 +721,7 @@ int radeon_gem_op_ioctl(struct drm_device *dev, void *data,
robj = gem_to_radeon_bo(gobj);
r = -EPERM;
- if (radeon_ttm_tt_has_userptr(robj->tbo.ttm))
+ if (radeon_ttm_tt_has_userptr(robj->rdev, robj->tbo.ttm))
goto out;
r = radeon_bo_reserve(robj, false);
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index bb7582afd803..3fcd15d21ddc 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -331,7 +331,7 @@ int radeon_bo_pin_restricted(struct radeon_bo *bo, u32
domain, u64 max_offset,
struct ttm_operation_ctx ctx = { false, false };
int r, i;
- if (radeon_ttm_tt_has_userptr(bo->tbo.ttm))
+ if (radeon_ttm_tt_has_userptr(bo->rdev, bo->tbo.ttm))
return -EPERM;
if (bo->pin_count) {
diff --git a/drivers/gpu/drm/radeon/radeon_prime.c
b/drivers/gpu/drm/radeon/radeon_prime.c
index b906e8fbd5f3..d6d9c8b46ab4 100644
--- a/drivers/gpu/drm/radeon/radeon_prime.c
+++ b/drivers/gpu/drm/radeon/radeon_prime.c
@@ -121,7 +121,7 @@ struct dma_buf *radeon_gem_prime_export(struct
drm_gem_object *gobj,
int flags)
{
struct radeon_bo *bo = gem_to_radeon_bo(gobj);
- if (radeon_ttm_tt_has_userptr(bo->tbo
Re: [v4,04/15] drm/bridge: tc358764: add drm_panel_bridge support
Hi Sam, On 26.07.2020 22:33, Sam Ravnborg wrote: > Prepare the tc358764 bridge driver for use in a chained setup by > replacing direct use of drm_panel with drm_panel_bridge support. > > The bridge panel will use the connector type reported by the panel, > where the connector for this driver hardcodes DRM_MODE_CONNECTOR_LVDS. > > The tc358764 did not any additional info the the connector so the > connector creation is passed to the bridge panel driver. > > v3: >- Merge with patch to make connector creation optional to avoid > creating two connectors (Laurent) >- Pass connector creation to bridge panel, as this bridge driver > did not add any extra info to the connector. >- Set bridge.type to DRM_MODE_CONNECTOR_LVDS. > > v2: >- Use PTR_ERR_OR_ZERO() (kbuild test robot) > > Signed-off-by: Sam Ravnborg > Cc: Laurent Pinchart > Cc: kbuild test robot > Cc: Andrzej Hajda > Cc: Neil Armstrong > Cc: Jonas Karlman > Cc: Jernej Skrabec > Reviewed-by: Laurent Pinchart I've noticed that this patch has been merged recently to linux-next. Sadly it causes regression on Samsung Exynos5250-based Arndale board. It can be observed by the following warning during boot: [ cut here ] WARNING: CPU: 1 PID: 1 at drivers/gpu/drm/drm_atomic_state_helper.c:494 drm_atomic_helper_connector_duplicate_state+0x60/0x68 Modules linked in: CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.8.0-rc2-00501-g1644127f83bc #1526 Hardware name: Samsung Exynos (Flattened Device Tree) [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (dump_stack+0xbc/0xe8) [] (dump_stack) from [] (__warn+0xf0/0x108) [] (__warn) from [] (warn_slowpath_fmt+0xb0/0xb8) [] (warn_slowpath_fmt) from [] (drm_atomic_helper_connector_duplicate_state+0x60/0x68) [] (drm_atomic_helper_connector_duplicate_state) from [] (drm_atomic_get_connector_state+0xfc/0x184) [] (drm_atomic_get_connector_state) from [] (__drm_atomic_helper_set_config+0x2a0/0x368) [] (__drm_atomic_helper_set_config) from [] (drm_client_modeset_commit_atomic+0x180/0x284) [] (drm_client_modeset_commit_atomic) from [] (drm_client_modeset_commit_locked+0x64/0x1cc) [] (drm_client_modeset_commit_locked) from [] (drm_client_modeset_commit+0x24/0x40) [] (drm_client_modeset_commit) from [] (drm_fb_helper_restore_fbdev_mode_unlocked+0x50/0x94) [] (drm_fb_helper_restore_fbdev_mode_unlocked) from [] (drm_fb_helper_set_par+0x30/0x5c) [] (drm_fb_helper_set_par) from [] (fbcon_init+0x5c8/0x65c) [] (fbcon_init) from [] (visual_init+0xc0/0x108) [] (visual_init) from [] (do_bind_con_driver+0x180/0x39c) [] (do_bind_con_driver) from [] (do_take_over_console+0x140/0x1cc) [] (do_take_over_console) from [] (do_fbcon_takeover+0x84/0xe0) [] (do_fbcon_takeover) from [] (register_framebuffer+0x1cc/0x2dc) [] (register_framebuffer) from [] (__drm_fb_helper_initial_config_and_unlock+0x3f0/0x5e8) [] (__drm_fb_helper_initial_config_and_unlock) from [] (drm_kms_helper_hotplug_event+0x24/0x30) [] (drm_kms_helper_hotplug_event) from [] (exynos_dsi_host_attach+0x184/0x2d8) [] (exynos_dsi_host_attach) from [] (tc358764_probe+0x13c/0x1ac) [] (tc358764_probe) from [] (really_probe+0x200/0x48c) [] (really_probe) from [] (driver_probe_device+0x78/0x1fc) [] (driver_probe_device) from [] (device_driver_attach+0x58/0x60) [] (device_driver_attach) from [] (__driver_attach+0xdc/0x174) [] (__driver_attach) from [] (bus_for_each_dev+0x68/0xb4) [] (bus_for_each_dev) from [] (bus_add_driver+0x158/0x214) [] (bus_add_driver) from [] (driver_register+0x78/0x110) [] (driver_register) from [] (do_one_initcall+0x8c/0x424) [] (do_one_initcall) from [] (kernel_init_freeable+0x190/0x204) [] (kernel_init_freeable) from [] (kernel_init+0x8/0x118) [] (kernel_init) from [] (ret_from_fork+0x14/0x20) Exception stack(0xee8ddfb0 to 0xee8ddff8) dfa0: dfc0: dfe0: 0013 irq event stamp: 171647 hardirqs last enabled at (171653): [] vprintk_emit+0x2ac/0x2ec hardirqs last disabled at (171658): [] vprintk_emit+0x164/0x2ec softirqs last enabled at (171486): [] __do_softirq+0x50c/0x608 softirqs last disabled at (171473): [] irq_exit+0x168/0x16c ---[ end trace 33117a16f066466a ]--- Then calling modetest end with segmentation fault. I'm not able to check currently if there is anything on the display because of having only remote access to the board. If this is important I will try to ask someone to help checking at the board's display at the office. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/1] AMDGPU: Specify get_argument function for ci_smu_funcs
Starting in Linux 5.8, the graphics and memory clock frequency were not being
reported for CIK cards. This is a regression, since they were reported
correctly in Linux 5.7. This was due to changes in commit
a0ec225633d9f681e393a1827f29f02c837deb84.
After investigation, I discovered that the smum_send_msg_to_smc() function,
attempts to call the corresponding get_argument() function of ci_smu_funcs.
However, the get_argument() function is not defined in ci_smu_funcs.
This patch fixes the bug by specifying the correct get_argument() function.
Signed-off-by: Sandeep Raghuraman
---
drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c
b/drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c
index ad54f4500af1..63016c14b942 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c
@@ -37,6 +37,7 @@
#include "cgs_common.h"
#include "atombios.h"
#include "pppcielanes.h"
+#include "smu7_smumgr.h"
#include "smu/smu_7_0_1_d.h"
#include "smu/smu_7_0_1_sh_mask.h"
@@ -2948,6 +2949,7 @@ const struct pp_smumgr_func ci_smu_funcs = {
.request_smu_load_specific_fw = NULL,
.send_msg_to_smc = ci_send_msg_to_smc,
.send_msg_to_smc_with_parameter = ci_send_msg_to_smc_with_parameter,
+ .get_argument = smu7_get_argument,
.download_pptable_settings = NULL,
.upload_pptable_settings = NULL,
.get_offsetof = ci_get_offsetof,
--
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: Prefer lower feedback dividers
Am 25.08.20 um 19:33 schrieb Kai-Heng Feng:
Commit 2e26ccb119bd ("drm/radeon: prefer lower reference dividers")
fixed screen flicker for HP Compaq nx9420 but breaks other laptops like
Asus X50SL.
Turns out we also need to favor lower feedback dividers.
Mhm, let's hope that this works out for all others as well :)
Users confirmed this change fixes the regression and doesn't regress the
original fix.
Fixes: 2e26ccb119bd ("drm/radeon: prefer lower reference dividers")
BugLink: https://bugs.launchpad.net/bugs/1791312
BugLink: https://bugs.launchpad.net/bugs/1861554
Signed-off-by: Kai-Heng Feng
Reviewed-by: Christian König
---
drivers/gpu/drm/radeon/radeon_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index e0ae911ef427..7b69d6dfe44a 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -933,7 +933,7 @@ static void avivo_get_fb_ref_div(unsigned nom, unsigned
den, unsigned post_div,
/* get matching reference and feedback divider */
*ref_div = min(max(den/post_div, 1u), ref_div_max);
- *fb_div = DIV_ROUND_CLOSEST(nom * *ref_div * post_div, den);
+ *fb_div = max(nom * *ref_div * post_div / den, 1u);
/* limit fb divider to its maximum */
if (*fb_div > fb_div_max) {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Parse Colorimetry data block from EDID
On Wed, Aug 26, 2020 at 10:23:28PM +0800, Algea Cao wrote:
> CEA 861.3 spec adds colorimetry data block for HDMI.
> Parsing the block to get the colorimetry data from
> panel.
And what exactly do you want to do with that data?
>
> Signed-off-by: Algea Cao
> ---
>
> drivers/gpu/drm/drm_edid.c | 45 +
> include/drm/drm_connector.h | 3 +++
> include/drm/drm_edid.h | 14
> 3 files changed, 62 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 31496b6cfc56..67e607c04492 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3223,6 +3223,7 @@ add_detailed_modes(struct drm_connector *connector,
> struct edid *edid,
> #define VIDEO_BLOCK 0x02
> #define VENDOR_BLOCK0x03
> #define SPEAKER_BLOCK0x04
> +#define COLORIMETRY_DATA_BLOCK 0x5
> #define HDR_STATIC_METADATA_BLOCK0x6
> #define USE_EXTENDED_TAG 0x07
> #define EXT_VIDEO_CAPABILITY_BLOCK 0x00
> @@ -4309,6 +4310,48 @@ static void fixup_detailed_cea_mode_clock(struct
> drm_display_mode *mode)
> mode->clock = clock;
> }
>
> +static bool cea_db_is_hdmi_colorimetry_data_block(const u8 *db)
> +{
> + if (cea_db_tag(db) != USE_EXTENDED_TAG)
> + return false;
> +
> + if (db[1] != COLORIMETRY_DATA_BLOCK)
> + return false;
> +
> + if (cea_db_payload_len(db) < 2)
> + return false;
> +
> + return true;
> +}
> +
> +static void
> +drm_parse_colorimetry_data_block(struct drm_connector *connector, const u8
> *db)
> +{
> + struct drm_hdmi_info *info = &connector->display_info.hdmi;
> +
> + if (db[2] & DRM_EDID_CLRMETRY_xvYCC_601)
> + info->colorimetry |= DRM_EDID_CLRMETRY_xvYCC_601;
> + if (db[2] & DRM_EDID_CLRMETRY_xvYCC_709)
> + info->colorimetry |= DRM_EDID_CLRMETRY_xvYCC_709;
> + if (db[2] & DRM_EDID_CLRMETRY_sYCC_601)
> + info->colorimetry |= DRM_EDID_CLRMETRY_sYCC_601;
> + if (db[2] & DRM_EDID_CLRMETRY_ADBYCC_601)
> + info->colorimetry |= DRM_EDID_CLRMETRY_ADBYCC_601;
> + if (db[2] & DRM_EDID_CLRMETRY_ADB_RGB)
> + info->colorimetry |= DRM_EDID_CLRMETRY_ADB_RGB;
> + if (db[2] & DRM_EDID_CLRMETRY_BT2020_CYCC)
> + info->colorimetry |= DRM_EDID_CLRMETRY_BT2020_CYCC;
> + if (db[2] & DRM_EDID_CLRMETRY_BT2020_YCC)
> + info->colorimetry |= DRM_EDID_CLRMETRY_BT2020_YCC;
> + if (db[2] & DRM_EDID_CLRMETRY_BT2020_RGB)
> + info->colorimetry |= DRM_EDID_CLRMETRY_BT2020_RGB;
> + /* Byte 4 Bit 7: DCI-P3 */
> + if (db[3] & BIT(7))
> + info->colorimetry |= DRM_EDID_CLRMETRY_DCI_P3;
> +
> + DRM_DEBUG_KMS("Supported Colorimetry 0x%x\n", info->colorimetry);
> +}
> +
> static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db)
> {
> if (cea_db_tag(db) != USE_EXTENDED_TAG)
> @@ -4994,6 +5037,8 @@ static void drm_parse_cea_ext(struct drm_connector
> *connector,
> drm_parse_vcdb(connector, db);
> if (cea_db_is_hdmi_hdr_metadata_block(db))
> drm_parse_hdr_metadata_block(connector, db);
> + if (cea_db_is_hdmi_colorimetry_data_block(db))
> + drm_parse_colorimetry_data_block(connector, db);
> }
> }
>
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index af145608b5ed..d599c3b9e881 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -207,6 +207,9 @@ struct drm_hdmi_info {
>
> /** @y420_dc_modes: bitmap of deep color support index */
> u8 y420_dc_modes;
> +
> + /* @colorimetry: bitmap of supported colorimetry modes */
> + u16 colorimetry;
> };
>
> /**
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index cfa4f5af49af..98fa78c2f82d 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -229,6 +229,20 @@ struct detailed_timing {
> DRM_EDID_YCBCR420_DC_36 | \
> DRM_EDID_YCBCR420_DC_30)
>
> +/*
> + * Supported Colorimetry from colorimetry data block
> + * as per CEA 861-G spec
> + */
> +#define DRM_EDID_CLRMETRY_xvYCC_601 (1 << 0)
> +#define DRM_EDID_CLRMETRY_xvYCC_709 (1 << 1)
> +#define DRM_EDID_CLRMETRY_sYCC_601(1 << 2)
> +#define DRM_EDID_CLRMETRY_ADBYCC_601 (1 << 3)
> +#define DRM_EDID_CLRMETRY_ADB_RGB (1 << 4)
> +#define DRM_EDID_CLRMETRY_BT2020_CYCC (1 << 5)
> +#define DRM_EDID_CLRMETRY_BT2020_YCC (1 << 6)
> +#define DRM_EDID_CLRMETRY_BT2020_RGB (1 << 7)
> +#define DRM_EDID_CLRMETRY_DCI_P3 (1 << 15)
> +
> /* ELD Header Block */
> #define DRM_ELD_HEADER_BLOCK_SIZE4
>
> --
> 2.25.1
>
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
_
Re: [RFC] Experimental DMA-BUF Device Heaps
On Tuesday, August 25, 2020 10:26 PM, Nicolas Dufresne wrote: > > I don't think we can do this in a system-agnostic way. What I'd like to > > see is an API for the kernel to expose opaque constraints for each > > Please, take into consideration that constraints can also come from > userspace. These days, there exist things we may want to do using the > CPU, but the SIMD instructions and the associated algorithm will > introduce constraints too. If these constraints comes too opaque, but > you will also potentially limit some valid CPU interaction with HW in > term of buffer access. CPU constraints todays are fairly small and one > should be able to express them I believe. Of course, these are not > media agnostic, some constraints may depends on the media (like an > image buffer, a matrix buffer or audio buffer) and the associated > algorithm to be used. > > An example would be an image buffers produced or modified on CPU but > encoded with HW. Actually, in the proposal we're working on, constraints may come from user-space too. Rendering APIs (ie. mesa) will need to expose constraints for buffers they can render on or texture from. Constraints would be opaque for users like compositors (ie. programs that merely pass constraints around and merge them don't need to understand them), but not for user-space drivers. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/vc4: hdmi: Add pixel bvb clock control
Am 27.08.20 um 06:35 schrieb Hoegeun Kwon:
> Hi Stefan,
>
> Thank you for your review.
>
>
> On 8/26/20 7:04 PM, Stefan Wahren wrote:
>> Hi Hoeguen,
>>
>> Am 21.08.20 um 09:10 schrieb Hoegeun Kwon:
>>> There is a problem that the output does not work at a resolution
>>> exceeding FHD. To solve this, we need to adjust the bvb clock at a
>>> resolution exceeding FHD.
>> this patch introduces a mandatory clock, please update
>> brcm,bcm2835-hdmi.yaml first.
>>
>> Is this clock physically available on BCM283x or only on BCM2711?
> As far as I know, BCM2711 raspberry pi 4 supports 4k,
>
> don't supported on pi 3 and pi 3+.
>
> Since 4k is not supported in versions prior to Raspberry Pi 4,
>
> I don't think we need to modify the bvb clock.
>
>
> So I think it is better to update 'brcm,bcm2711-hdmi.yaml'
>
> instead of 'brcm,bcm2835-hdmi.yaml'.
You are correct please update only brcm,bcm2711-hdmi.yaml.
My concern was that the function vc4_hdmi_encoder_pre_crtc_configure()
is called on a non-bcm2711 platform or on a Raspberry Pi 4 with an older
DTB. So making the BVB clock optional might be better?
>
> Please comment, what do you think?
>
>> I'm a little bit afraid, this change could break with older firmware
>> versions on BCM283x.
> Tested it several times with libdrm modetest.
>
> I expect there will be no problem.
>
>
> Best regards,
>
> Hoegeun
>
>> Best regards
>> Stefan
>>
>>> Signed-off-by: Hoegeun Kwon
>>> ---
>>> drivers/gpu/drm/vc4/vc4_hdmi.c | 25 +
>>> drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +
>>> 2 files changed, 26 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
>>> index 95ec5eedea39..eb3192d1fd86 100644
>>> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
>>> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
>>> @@ -80,6 +80,7 @@
>>> # define VC4_HD_M_ENABLE BIT(0)
>>>
>>> #define CEC_CLOCK_FREQ 4
>>> +#define VC4_HSM_MID_CLOCK 149985000
>>>
>>> static int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused)
>>> {
>>> @@ -380,6 +381,7 @@ static void vc4_hdmi_encoder_post_crtc_powerdown(struct
>>> drm_encoder *encoder)
>>> HDMI_WRITE(HDMI_VID_CTL,
>>>HDMI_READ(HDMI_VID_CTL) & ~VC4_HD_VID_CTL_ENABLE);
>>>
>>> + clk_disable_unprepare(vc4_hdmi->pixel_bvb_clock);
>>> clk_disable_unprepare(vc4_hdmi->hsm_clock);
>>> clk_disable_unprepare(vc4_hdmi->pixel_clock);
>>>
>>> @@ -638,6 +640,23 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct
>>> drm_encoder *encoder)
>>> return;
>>> }
>>>
>>> + ret = clk_set_rate(vc4_hdmi->pixel_bvb_clock,
>>> + (hsm_rate > VC4_HSM_MID_CLOCK ? 15000 : 7500));
>>> + if (ret) {
>>> + DRM_ERROR("Failed to set pixel bvb clock rate: %d\n", ret);
>>> + clk_disable_unprepare(vc4_hdmi->hsm_clock);
>>> + clk_disable_unprepare(vc4_hdmi->pixel_clock);
>>> + return;
>>> + }
>>> +
>>> + ret = clk_prepare_enable(vc4_hdmi->pixel_bvb_clock);
>>> + if (ret) {
>>> + DRM_ERROR("Failed to turn on pixel bvb clock: %d\n", ret);
>>> + clk_disable_unprepare(vc4_hdmi->hsm_clock);
>>> + clk_disable_unprepare(vc4_hdmi->pixel_clock);
>>> + return;
>>> + }
>>> +
>>> if (vc4_hdmi->variant->reset)
>>> vc4_hdmi->variant->reset(vc4_hdmi);
>>>
>>> @@ -1593,6 +1612,12 @@ static int vc5_hdmi_init_resources(struct vc4_hdmi
>>> *vc4_hdmi)
>>> return PTR_ERR(vc4_hdmi->audio_clock);
>>> }
>>>
>>> + vc4_hdmi->pixel_bvb_clock = devm_clk_get(dev, "bvb");
>>> + if (IS_ERR(vc4_hdmi->pixel_bvb_clock)) {
>>> + DRM_ERROR("Failed to get pixel bvb clock\n");
>>> + return PTR_ERR(vc4_hdmi->pixel_bvb_clock);
>>> + }
>>> +
>>> vc4_hdmi->reset = devm_reset_control_get(dev, NULL);
>>> if (IS_ERR(vc4_hdmi->reset)) {
>>> DRM_ERROR("Failed to get HDMI reset line\n");
>>> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
>>> index 0806c6d9f24e..63c6f8bddf1d 100644
>>> --- a/drivers/gpu/drm/vc4/vc4_hdmi.h
>>> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
>>> @@ -147,6 +147,7 @@ struct vc4_hdmi {
>>> struct clk *pixel_clock;
>>> struct clk *hsm_clock;
>>> struct clk *audio_clock;
>>> + struct clk *pixel_bvb_clock;
>>>
>>> struct reset_control *reset;
>>>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mgag200: fix spelling mistake "expeced" -> "expected"
Hi
Am 26.08.20 um 10:47 schrieb Colin King:
> From: Colin Ian King
>
> There is a spelling mistake in a drm_warn message. Fix it.
>
> Signed-off-by: Colin Ian King
Thanks! Applied to drm-misc-next.
Best regards
Thomas
> ---
> drivers/gpu/drm/mgag200/mgag200_drv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c
> b/drivers/gpu/drm/mgag200/mgag200_drv.c
> index b282b0e42c2d..771b26aeee19 100644
> --- a/drivers/gpu/drm/mgag200/mgag200_drv.c
> +++ b/drivers/gpu/drm/mgag200/mgag200_drv.c
> @@ -168,7 +168,7 @@ static void mgag200_g200_interpret_bios(struct mga_device
> *mdev,
> return;
> }
> if (pins_len != expected_length[version]) {
> - drm_warn(dev, "Unexpected BIOS PInS size: %d expeced: %d\n",
> + drm_warn(dev, "Unexpected BIOS PInS size: %d expected: %d\n",
>pins_len, expected_length[version]);
> return;
> }
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/hisilicon: Removed the dependency on the mmu
Hi Am 26.08.20 um 09:55 schrieb Tian Tao: > hibmc can only be used in ARM64 architectures, and mmu defaults to y > in arch/arm64/Kconfig, so there is no need to add a dependency on mmu > in hibmc's kconfig. > > Signed-off-by: Tian Tao Reviewed-by: Thomas Zimmermann > --- > drivers/gpu/drm/hisilicon/hibmc/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/hisilicon/hibmc/Kconfig > b/drivers/gpu/drm/hisilicon/hibmc/Kconfig > index dfc5aef..43943e9 100644 > --- a/drivers/gpu/drm/hisilicon/hibmc/Kconfig > +++ b/drivers/gpu/drm/hisilicon/hibmc/Kconfig > @@ -1,7 +1,7 @@ > # SPDX-License-Identifier: GPL-2.0-only > config DRM_HISI_HIBMC > tristate "DRM Support for Hisilicon Hibmc" > - depends on DRM && PCI && MMU && ARM64 > + depends on DRM && PCI && ARM64 > select DRM_KMS_HELPER > select DRM_VRAM_HELPER > select DRM_TTM > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: tc358767: fix EDID memory leak
On 27/08/2020 02:23, Laurent Pinchart wrote: > Hi Tomi, > > Thank you for the patch. > > On Wed, Aug 26, 2020 at 04:40:17PM +0300, Tomi Valkeinen wrote: >> The current EDID allocated with drm_get_edid() is freed when the driver >> gets a new EDID, but it is not freed when the driver is removed, causing >> a leak. >> >> Free the EDID (if any) on driver remove. >> >> Signed-off-by: Tomi Valkeinen >> --- >> drivers/gpu/drm/bridge/tc358767.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/drivers/gpu/drm/bridge/tc358767.c >> b/drivers/gpu/drm/bridge/tc358767.c >> index c2777b226c75..dbb18a86beaf 100644 >> --- a/drivers/gpu/drm/bridge/tc358767.c >> +++ b/drivers/gpu/drm/bridge/tc358767.c >> @@ -1695,6 +1695,8 @@ static int tc_remove(struct i2c_client *client) >> drm_bridge_remove(&tc->bridge); >> drm_dp_aux_unregister(&tc->aux); >> >> +kfree(tc->edid); >> + > > tc->edid is gone in drm-misc-next, problem solved already :-) Well, indeed. Should have looked at the latest... =). The leak only happens on driver remove, so I don't think it's worth sending for stable kernels. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 1/4] drm/ast: Only set format registers if primary plane's format changes
Hi
Am 26.08.20 um 15:54 schrieb Sasha Levin:
> Hi
>
> [This is an automated email]
>
> This commit has been processed because it contains a "Fixes:" tag
> fixing commit: 4961eb60f145 ("drm/ast: Enable atomic modesetting").
>
> The bot has tested the following trees: v5.8.2, v5.7.16.
>
> v5.8.2: Failed to apply! Possible dependencies:
> 05f13f5b5996 ("drm/ast: Remove unused code paths for AST 1180")
> fa7dbd768884 ("drm/ast: Upcast from DRM device to ast structure via
> to_ast_private()")
>
> v5.7.16: Failed to apply! Possible dependencies:
> 05f13f5b5996 ("drm/ast: Remove unused code paths for AST 1180")
> 3a53230e1c4b ("drm/ast: Make ast_primary_plane_helper_atomic_update
> static")
> fa7dbd768884 ("drm/ast: Upcast from DRM device to ast structure via
> to_ast_private()")
>
>
> NOTE: The patch will not be queued to stable trees until it is upstream.
>
> How should we proceed with this patch?
Please drop this patch and the rest of the series.
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-fixes
Hi Dave & Daniel, just one fix for -rc3. BR, Jani. The following changes since commit d012a7190fc1fd72ed48911e77ca97ba4521bccd: Linux 5.9-rc2 (2020-08-23 14:08:43 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2020-08-27 for you to fetch changes up to e5f10d6385cda083037915c12b130887c8831d2b: drm/i915: Fix cmd parser desc matching with masks (2020-08-25 11:01:34 +0300) drm/i915 fixes for v5.9-rc3: - Fix command parser desc matching with masks Mika Kuoppala (1): drm/i915: Fix cmd parser desc matching with masks drivers/gpu/drm/i915/i915_cmd_parser.c | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/4] drm/panel: s6e63m0: Add DSI transport
On Tue, Aug 18, 2020 at 7:10 PM Sam Ravnborg wrote: > How does this patchset relate to the patchset posted by Paul? > https://lore.kernel.org/dri-devel/20200727164613.19744-1-p...@crapouillou.net/ Not much. S6E63M0 uses "spi" as it is right now and is not using the existing DBI code. So it would require it to start using the DBI core to begin with. If it can. Which is kind of an orthogonal task. What would be the defining character for it to be "DBI"? I do see that the driver sends MIPI standard commands over SPI. I suspect this is another standard without public specs... > Seems that two different approcahes are used for the same type of > problem. This approach is based on the approach from IIO, se e.g.: drivers/iio/accel/bmc150-accel-core.c drivers/iio/accel/bmc150-accel.h drivers/iio/accel/bmc150-accel-i2c.c drivers/iio/accel/bmc150-accel-spi.c > Is it possible to find a common solution? I'm happy to rework it any direction. If the other patch set is going to take time to finalize (as in: will not merge it the coming week, need to hack and stuff) then I'd prefer to apply this so I know my display works in v5.10. I can certainly rework it into Paul's framework when that arrives. Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Aw: [PATCH v5 3/7] drm/mediatek: disable tmds on mt2701
On 21/08/2020 09:17, Frank Wunderlich wrote: diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c index 5223498502c4..edadb7a700f1 100644 --- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c @@ -184,6 +184,9 @@ static int mtk_hdmi_phy_probe(struct platform_device *pdev) return PTR_ERR(phy_provider); } + if (hdmi_phy->conf->pll_default_off) + hdmi_phy->conf->hdmi_phy_disable_tmds(hdmi_phy); + return of_clk_add_provider(dev->of_node, of_clk_src_simple_get, hdmi_phy->pll); } tried modifying mtk_hdmi_phy_power_on using the new flag to not enable tmds instead of enabling and later disabling it, but this does not work... --- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c @@ -62,7 +62,8 @@ static int mtk_hdmi_phy_power_on(struct phy *phy) if (ret < 0) return ret; - hdmi_phy->conf->hdmi_phy_enable_tmds(hdmi_phy); + if (!hdmi_phy->conf->pll_default_off) + hdmi_phy->conf->hdmi_phy_enable_tmds(hdmi_phy); return 0; } @@ -184,8 +185,8 @@ static int mtk_hdmi_phy_probe(struct platform_device *pdev) return PTR_ERR(phy_provider); } - if (hdmi_phy->conf->pll_default_off) - hdmi_phy->conf->hdmi_phy_disable_tmds(hdmi_phy); + //if (hdmi_phy->conf->pll_default_off) + // hdmi_phy->conf->hdmi_phy_disable_tmds(hdmi_phy); return of_clk_add_provider(dev->of_node, of_clk_src_simple_get, hdmi_phy->pll); same problem as without this Patch (horizontally distorted image flickering on 1280x1024) any idea CK Hu? I'll leave it to CK to decide how to go forward with this. Would be interesting to understand why we need to disable the phy. Someone would need to verify that this holds for mt2701 as well, and not only for mt7623, otherwise we would break mt2701. Regards, Matthias ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Printing bitfields in the kernel (Re: [PATCH] drm: Parse Colorimetry data block from EDID)
On Wed, 26 Aug 2020 22:23:28 +0800
Algea Cao wrote:
> CEA 861.3 spec adds colorimetry data block for HDMI.
> Parsing the block to get the colorimetry data from
> panel.
>
> Signed-off-by: Algea Cao
> ---
>
> drivers/gpu/drm/drm_edid.c | 45 +
> include/drm/drm_connector.h | 3 +++
> include/drm/drm_edid.h | 14
> 3 files changed, 62 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 31496b6cfc56..67e607c04492 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3223,6 +3223,7 @@ add_detailed_modes(struct drm_connector *connector,
> struct edid *edid,
> #define VIDEO_BLOCK 0x02
> #define VENDOR_BLOCK0x03
> #define SPEAKER_BLOCK0x04
> +#define COLORIMETRY_DATA_BLOCK 0x5
> #define HDR_STATIC_METADATA_BLOCK0x6
> #define USE_EXTENDED_TAG 0x07
> #define EXT_VIDEO_CAPABILITY_BLOCK 0x00
> @@ -4309,6 +4310,48 @@ static void fixup_detailed_cea_mode_clock(struct
> drm_display_mode *mode)
> mode->clock = clock;
> }
>
> +static bool cea_db_is_hdmi_colorimetry_data_block(const u8 *db)
> +{
> + if (cea_db_tag(db) != USE_EXTENDED_TAG)
> + return false;
> +
> + if (db[1] != COLORIMETRY_DATA_BLOCK)
> + return false;
> +
> + if (cea_db_payload_len(db) < 2)
> + return false;
> +
> + return true;
> +}
> +
> +static void
> +drm_parse_colorimetry_data_block(struct drm_connector *connector, const u8
> *db)
> +{
> + struct drm_hdmi_info *info = &connector->display_info.hdmi;
> +
> + if (db[2] & DRM_EDID_CLRMETRY_xvYCC_601)
> + info->colorimetry |= DRM_EDID_CLRMETRY_xvYCC_601;
> + if (db[2] & DRM_EDID_CLRMETRY_xvYCC_709)
> + info->colorimetry |= DRM_EDID_CLRMETRY_xvYCC_709;
> + if (db[2] & DRM_EDID_CLRMETRY_sYCC_601)
> + info->colorimetry |= DRM_EDID_CLRMETRY_sYCC_601;
> + if (db[2] & DRM_EDID_CLRMETRY_ADBYCC_601)
> + info->colorimetry |= DRM_EDID_CLRMETRY_ADBYCC_601;
> + if (db[2] & DRM_EDID_CLRMETRY_ADB_RGB)
> + info->colorimetry |= DRM_EDID_CLRMETRY_ADB_RGB;
> + if (db[2] & DRM_EDID_CLRMETRY_BT2020_CYCC)
> + info->colorimetry |= DRM_EDID_CLRMETRY_BT2020_CYCC;
> + if (db[2] & DRM_EDID_CLRMETRY_BT2020_YCC)
> + info->colorimetry |= DRM_EDID_CLRMETRY_BT2020_YCC;
> + if (db[2] & DRM_EDID_CLRMETRY_BT2020_RGB)
> + info->colorimetry |= DRM_EDID_CLRMETRY_BT2020_RGB;
> + /* Byte 4 Bit 7: DCI-P3 */
> + if (db[3] & BIT(7))
> + info->colorimetry |= DRM_EDID_CLRMETRY_DCI_P3;
> +
> + DRM_DEBUG_KMS("Supported Colorimetry 0x%x\n", info->colorimetry);
Hi,
taking a tangent here, printing bitfields as hex is hard to read. How
about using something like nvkm_snprintbf()? Of course not literally
that function since it's Nouveau internal, but as an end user I would be
happy to see DRM core or the kernel generics have similar functionality
that actually decodes the bits and prints their proper names.
Does such facility not exist yet?
Thanks,
pq
> +}
> +
> static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db)
> {
> if (cea_db_tag(db) != USE_EXTENDED_TAG)
> @@ -4994,6 +5037,8 @@ static void drm_parse_cea_ext(struct drm_connector
> *connector,
> drm_parse_vcdb(connector, db);
> if (cea_db_is_hdmi_hdr_metadata_block(db))
> drm_parse_hdr_metadata_block(connector, db);
> + if (cea_db_is_hdmi_colorimetry_data_block(db))
> + drm_parse_colorimetry_data_block(connector, db);
> }
> }
>
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index af145608b5ed..d599c3b9e881 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -207,6 +207,9 @@ struct drm_hdmi_info {
>
> /** @y420_dc_modes: bitmap of deep color support index */
> u8 y420_dc_modes;
> +
> + /* @colorimetry: bitmap of supported colorimetry modes */
> + u16 colorimetry;
> };
>
> /**
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index cfa4f5af49af..98fa78c2f82d 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -229,6 +229,20 @@ struct detailed_timing {
> DRM_EDID_YCBCR420_DC_36 | \
> DRM_EDID_YCBCR420_DC_30)
>
> +/*
> + * Supported Colorimetry from colorimetry data block
> + * as per CEA 861-G spec
> + */
> +#define DRM_EDID_CLRMETRY_xvYCC_601 (1 << 0)
> +#define DRM_EDID_CLRMETRY_xvYCC_709 (1 << 1)
> +#define DRM_EDID_CLRMETRY_sYCC_601(1 << 2)
> +#define DRM_EDID_CLRMETRY_ADBYCC_601 (1 << 3)
> +#define DRM_EDID_CLRMETRY_ADB_RGB (1 << 4)
> +#define DRM_EDID_CLRMETRY_BT2020_CYCC (1 << 5)
> +#define DRM_EDID_CLRMETRY_BT2020_YCC (1 << 6)
> +#define DRM_EDID_CLRMETRY_BT2020_RGB (1 << 7)
> +#define DRM
[PATCH 1/2] drm/mcde: Fix handling of platform_get_irq() error
platform_get_irq() returns -ERRNO on error. In such case comparison
to 0 would pass the check.
Fixes: 5fc537bfd000 ("drm/mcde: Add new driver for ST-Ericsson MCDE")
Signed-off-by: Krzysztof Kozlowski
---
drivers/gpu/drm/mcde/mcde_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mcde/mcde_drv.c b/drivers/gpu/drm/mcde/mcde_drv.c
index c592957ed07f..f9b5f450a9cb 100644
--- a/drivers/gpu/drm/mcde/mcde_drv.c
+++ b/drivers/gpu/drm/mcde/mcde_drv.c
@@ -331,8 +331,8 @@ static int mcde_probe(struct platform_device *pdev)
}
irq = platform_get_irq(pdev, 0);
- if (!irq) {
- ret = -EINVAL;
+ if (irq < 0) {
+ ret = irq;
goto clk_disable;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/tve200: Fix handling of platform_get_irq() error
platform_get_irq() returns -ERRNO on error. In such case comparison
to 0 would pass the check.
Fixes: 179c02fe90a4 ("drm/tve200: Add new driver for TVE200")
Signed-off-by: Krzysztof Kozlowski
---
drivers/gpu/drm/tve200/tve200_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tve200/tve200_drv.c
b/drivers/gpu/drm/tve200/tve200_drv.c
index c3aa39bd38ec..b5259cb1383f 100644
--- a/drivers/gpu/drm/tve200/tve200_drv.c
+++ b/drivers/gpu/drm/tve200/tve200_drv.c
@@ -200,8 +200,8 @@ static int tve200_probe(struct platform_device *pdev)
}
irq = platform_get_irq(pdev, 0);
- if (!irq) {
- ret = -EINVAL;
+ if (irq < 0) {
+ ret = irq;
goto clk_disable;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
