Re: [PATCH v2 3/4] drm/plane: add drmm_universal_plane_alloc()

[kernel test robot]

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 Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Descript

Re: Printing bitfields in the kernel (Re: [PATCH] drm: Parse Colorimetry data block from EDID)

[Joe Perches]

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, );


___
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()

[kernel test robot]

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 _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

[Dave Airlie]

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 

Re: Aw: Re: [PATCH v5 3/7] drm/mediatek: disable tmds on mt2701

[Chun-Kuang Hu]

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

[Chun-Kuang Hu]

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(>encoder, _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(>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(>encoder, >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

[Chun-Kuang Hu]

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 = _mmsys_driver_data},
> +   { .compatible = "mediatek,mt7623-mmsys",
> + .data = _mmsys_driver_data},
> { .compatible = "mediatek,mt2712-mmsys",
>   .data = _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

[Chun-Kuang Hu]

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
>  - 

Re: [PATCH v2 10/24] drm/panel: novatek-nt35510: Backlight update

[Linus Walleij]

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

[bugzilla-daemon]

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=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

[Tanmay Shah]

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)
 {
-   

[PATCH v12 5/5] drm/msm/dp: Add Display Port HPD feature

[Tanmay Shah]

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 

[PATCH v12 4/5] drm/msm/dpu: add display port support in DPU

[Tanmay Shah]

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

[Tanmay Shah]

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 

[PATCH v12 1/5] drm: add constant N value in helper file

[Tanmay Shah]

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

[bugzilla-daemon]

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

[John Stultz]

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

[trix]

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, _lim))
return;
nouveau_hw_get_pllvals(dev, pll, );

shadows a similar check in nouveau_hw_get_pllvals()

ret = nvbios_pll_parse(bios, plltype, _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 = >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, _lim))
+   if (nouveau_hw_get_pllvals(dev, pll, ))
return;
-   nouveau_hw_get_pllvals(dev, pll, );
 
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

[Robin Murphy]

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

[Greg Kroah-Hartman]

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"

[Ville Syrjälä]

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(_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(_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()

[Philipp Zabel]

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 = >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 = ptr;

[PATCH v2 1/4] drm: add drmm_encoder_alloc()

[Philipp Zabel]

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 _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 _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_encoder 

[PATCH v2 4/4] drm/crtc: add drmm_crtc_alloc_with_planes()

[Philipp Zabel]

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 = >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()

[Philipp Zabel]

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,
+   _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 _encoder
+ * @member: the name of the _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

[Greg Kroah-Hartman]

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

[Colin King]

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

[Thierry Reding]

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

[Thierry Reding]

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

[Simon Ser]

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

[Matthias Brugger]

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()

[Jani Nikula]

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

[Alex Deucher]

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()

[Jani Nikula]

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, _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(_dp->aux, DP_MSTM_CAP, _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(_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 =
>   _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(_dp->aux, intel_dp->dpcd);
>  
>   drm_dbg_kms(>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

[Alex Deucher]

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

[Alex Deucher]

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

[Sandeep Raghuraman]

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

[Matthias Brugger]

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

[Greg Kroah-Hartman]

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: 

Re: [PATCH v4 0/2] staging: android: Remove BUG/BUG_ON from ion

[Greg Kroah-Hartman]

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.

[Christian König]

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-cleanupdata=02%7C01%7Cchristian.koenig%40amd.com%7C84fd18e47b124259c45a08d849619a9a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637340030838885795sdata=WyDLcpJp07bSNxYPWovsnDkUIRDDmK3OlakW%2Fwy9HX4%3Dreserved=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.

[Christian König]

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, 

Re: [PATCH 07/23] drm/radeon/ttm: move to driver binding/destroy functions.

[Christian König]

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 

Re: [v4,04/15] drm/bridge: tc358764: add drm_panel_bridge support

[Marek Szyprowski]

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 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

[Sandeep Raghuraman]

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

[Christian König]

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

[Ville Syrjälä]

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 = >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

[Simon Ser]

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

[Stefan Wahren]

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"

[Thomas Zimmermann]

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

[Thomas Zimmermann]

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

[Tomi Valkeinen]

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(>bridge);
>>  drm_dp_aux_unregister(>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

[Thomas Zimmermann]

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

[Jani Nikula]

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

[Linus Walleij]

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

[Matthias Brugger]

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)

[Pekka Paalanen]

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 = >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 

[PATCH 1/2] drm/mcde: Fix handling of platform_get_irq() error

[Krzysztof Kozlowski]

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

[Krzysztof Kozlowski]

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

Re: [PATCH] block: convert tasklets to use new tasklet_setup() API

[Allen]

On Wed, Aug 26, 2020 at 8:43 PM Kees Cook  wrote:
>
> On Wed, Aug 26, 2020 at 12:55:28PM +0300, Dan Carpenter wrote:
> > On Wed, Aug 26, 2020 at 07:21:35AM +0530, Allen Pais wrote:
> > > On Thu, Aug 20, 2020 at 3:09 AM James Bottomley
> > >  wrote:
> > > >
> > > > On Wed, 2020-08-19 at 21:54 +0530, Allen wrote:
> > > > > > [...]
> > > > > > > > Since both threads seem to have petered out, let me suggest in
> > > > > > > > kernel.h:
> > > > > > > >
> > > > > > > > #define cast_out(ptr, container, member) \
> > > > > > > > container_of(ptr, typeof(*container), member)
> > > > > > > >
> > > > > > > > It does what you want, the argument order is the same as
> > > > > > > > container_of with the only difference being you name the
> > > > > > > > containing structure instead of having to specify its type.
> > > > > > >
> > > > > > > Not to incessantly bike shed on the naming, but I don't like
> > > > > > > cast_out, it's not very descriptive. And it has connotations of
> > > > > > > getting rid of something, which isn't really true.
> > > > > >
> > > > > > Um, I thought it was exactly descriptive: you're casting to the
> > > > > > outer container.  I thought about following the C++ dynamic casting
> > > > > > style, so out_cast(), but that seemed a bit pejorative.  What about
> > > > > > outer_cast()?
> > > > > >
> > > > > > > FWIW, I like the from_ part of the original naming, as it has
> > > > > > > some clues as to what is being done here. Why not just
> > > > > > > from_container()? That should immediately tell people what it
> > > > > > > does without having to look up the implementation, even before
> > > > > > > this becomes a part of the accepted coding norm.
> > > > > >
> > > > > > I'm not opposed to container_from() but it seems a little less
> > > > > > descriptive than outer_cast() but I don't really care.  I always
> > > > > > have to look up container_of() when I'm using it so this would just
> > > > > > be another macro of that type ...
> > > > > >
> > > > >
> > > > >  So far we have a few which have been suggested as replacement
> > > > > for from_tasklet()
> > > > >
> > > > > - out_cast() or outer_cast()
> > > > > - from_member().
> > > > > - container_from() or from_container()
> > > > >
> > > > > from_container() sounds fine, would trimming it a bit work? like
> > > > > from_cont().
> > > >
> > > > I'm fine with container_from().  It's the same form as container_of()
> > > > and I think we need urgent agreement to not stall everything else so
> > > > the most innocuous name is likely to get the widest acceptance.
> > >
> > > Kees,
> > >
> > >   Will you be  sending the newly proposed API to Linus? I have V2
> > > which uses container_from()
> > > ready to be sent out.
> >
> > I liked that James swapped the first two arguments so that it matches
> > container_of().  Plus it's nice that when you have:
> >
> >   struct whatever *foo = container_from(ptr, foo, member);
> >
> > Then it means that "ptr == >member".
>
> I'm a bit stalled right now -- the merge window was keeping me busy, and
> this week is the Linux Plumbers Conference. This is on my list, but I
> haven't gotten back around to it. If you want, feel free to send the
> container_from() patch; you might be able to unblock this faster than me
> right now. :)
>

Sure, Thanks.



-- 
   - Allen
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915/lspcon: Limits to 8 bpc for RGB/YCbCr444

[Kai Heng Feng]

Hi Ville,

> On Aug 27, 2020, at 12:24 AM, Ville Syrjälä  
> wrote:
> 
> On Wed, Aug 26, 2020 at 01:21:15PM +0800, Kai-Heng Feng wrote:
>> LSPCON only supports 8 bpc for RGB/YCbCr444.
>> 
>> Set the correct bpp otherwise it renders blank screen.
> 
> Hmm. Does 
> git://github.com/vsyrjala/linux.git dp_downstream_ports_5
> work?
> 
> Actually better make that dp_downstream_ports_5^^^ aka.
> 54d846ce62a2 ("drm/i915: Do YCbCr 444->420 conversion via DP protocol
> converters") to avoid the experiments and hacks I have sitting on top.

Can you please rebase it to mainline master or drm-tip?

I am getting errors on the branch:

  DESCEND  objtool
  CALLscripts/atomic/check-atomics.sh
  CALLscripts/checksyscalls.sh
  CHK include/generated/compile.h
  Building modules, stage 2.
  MODPOST 166 modules
  LD  arch/x86/boot/compressed/vmlinux
ld: arch/x86/boot/compressed/pgtable_64.o:(.bss+0x0): multiple definition of 
`__force_order'; arch/x86/boot/compressed/kaslr_64.o:(.bss+0x0): first defined 
here
ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only 
section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
make[2]: *** [arch/x86/boot/compressed/Makefile:119: 
arch/x86/boot/compressed/vmlinux] Error 1
make[1]: *** [arch/x86/boot/Makefile:113: arch/x86/boot/compressed/vmlinux] 
Error 2
make: *** [arch/x86/Makefile:284: bzImage] Error 2
make: *** Waiting for unfinished jobs

Kai-Heng

> 
>> 
>> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2195
>> Signed-off-by: Kai-Heng Feng 
>> ---
>> drivers/gpu/drm/i915/display/intel_lspcon.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c 
>> b/drivers/gpu/drm/i915/display/intel_lspcon.c
>> index b781bf469644..c7a44fcaade8 100644
>> --- a/drivers/gpu/drm/i915/display/intel_lspcon.c
>> +++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
>> @@ -196,7 +196,8 @@ void lspcon_ycbcr420_config(struct drm_connector 
>> *connector,
>>  crtc_state->port_clock /= 2;
>>  crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR444;
>>  crtc_state->lspcon_downsampling = true;
>> -}
>> +} else
>> +crtc_state->pipe_bpp = 24;
>> }
>> 
>> static bool lspcon_probe(struct intel_lspcon *lspcon)
>> -- 
>> 2.17.1
> 
> -- 
> Ville Syrjälä
> Intel

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/amd/display: Fix memleak in amdgpu_dm_mode_config_init

[Dinghao Liu]

When amdgpu_display_modeset_create_props() fails, state and
state->context should be freed to prevent memleak. It's the
same when amdgpu_dm_audio_init() fails.

Signed-off-by: Dinghao Liu 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index df9338257ae0..2476e40c67ef 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2834,12 +2834,18 @@ static int amdgpu_dm_mode_config_init(struct 
amdgpu_device *adev)
_atomic_state_funcs);
 
r = amdgpu_display_modeset_create_props(adev);
-   if (r)
+   if (r) {
+   dc_release_state(state->context);
+   kfree(state);
return r;
+   }
 
r = amdgpu_dm_audio_init(adev);
-   if (r)
+   if (r) {
+   dc_release_state(state->context);
+   kfree(state);
return r;
+   }
 
return 0;
 }
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V2 1/2] i2c: i2c-qcom-geni: Store DMA mapping data in geni_i2c_dev struct

[Akash Asthana]

Hi Roja,

On 8/20/2020 4:05 PM, Roja Rani Yarubandi wrote:

Store DMA mapping data in geni_i2c_dev struct to enhance DMA mapping
data scope. For example during shutdown callback to unmap DMA mapping,
this stored DMA mapping data can be used to call geni_se_tx_dma_unprep
and geni_se_rx_dma_unprep functions.

Signed-off-by: Roja Rani Yarubandi 
---
Changes in V2:
  - As per Stephen's comments, changed commit text, fixed minor nitpicks.

  drivers/i2c/busses/i2c-qcom-geni.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/drivers/i2c/busses/i2c-qcom-geni.c 
b/drivers/i2c/busses/i2c-qcom-geni.c
index 7f130829bf01..1fda5c7c2cfc 100644
--- a/drivers/i2c/busses/i2c-qcom-geni.c
+++ b/drivers/i2c/busses/i2c-qcom-geni.c
@@ -86,6 +86,9 @@ struct geni_i2c_dev {
u32 clk_freq_out;
const struct geni_i2c_clk_fld *clk_fld;
int suspended;
+   dma_addr_t tx_dma;
+   dma_addr_t rx_dma;
+   size_t xfer_len;
  };
  
  struct geni_i2c_err_log {

@@ -358,6 +361,7 @@ static int geni_i2c_rx_one_msg(struct geni_i2c_dev *gi2c, 
struct i2c_msg *msg,
struct geni_se *se = >se;
size_t len = msg->len;
  
+	gi2c->xfer_len = msg->len;


nit: gi2c->xfer = len, for tx_one_msg as well.

Regards,

Akash


if (!of_machine_is_compatible("lenovo,yoga-c630"))
dma_buf = i2c_get_dma_safe_msg_buf(msg, 32);
  
@@ -384,6 +388,7 @@ static int geni_i2c_rx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg,

if (dma_buf) {
if (gi2c->err)
geni_i2c_rx_fsm_rst(gi2c);
+   gi2c->rx_dma = rx_dma;
geni_se_rx_dma_unprep(se, rx_dma, len);
i2c_put_dma_safe_msg_buf(dma_buf, msg, !gi2c->err);
}
@@ -400,6 +405,7 @@ static int geni_i2c_tx_one_msg(struct geni_i2c_dev *gi2c, 
struct i2c_msg *msg,
struct geni_se *se = >se;
size_t len = msg->len;
  
+	gi2c->xfer_len = msg->len;

if (!of_machine_is_compatible("lenovo,yoga-c630"))
dma_buf = i2c_get_dma_safe_msg_buf(msg, 32);
  
@@ -429,6 +435,7 @@ static int geni_i2c_tx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg,

if (dma_buf) {
if (gi2c->err)
geni_i2c_tx_fsm_rst(gi2c);
+   gi2c->tx_dma = tx_dma;
geni_se_tx_dma_unprep(se, tx_dma, len);
i2c_put_dma_safe_msg_buf(dma_buf, msg, !gi2c->err);
}


--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,\na 
Linux Foundation Collaborative Project

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/4] dyndbg: POC use dynamic_debug_exec_queries in DRM

[Jim Cromie]

This patchset tests/demonstrates using dynamic_debug_exec_queries() to
alter 2 drivers' pr_debugs without a user directly using >control.

For drm.core, I copied drm.debug module parameter model, adding
drm.debug2 as a POC user interface to control 2 pr_debug additions to
drm_printk:drm_dbg,dev_dbg, allowing both category and >control to
work in parallel.  This patch makes no attempt to integrate drm's
category mechanism with the "format=^class" callsite selection; thats
the "theory", but it needs testing.

For i915/gvt, I repeated the pattern.  I focussed on gvt only, because
it had the most compelling use of format strings as pr_debug classes;
~120 pr_debugs in 9 classes.  These are mapped onto bits of the param.

bash-5.0# echo 0x0 > /sys/module/i915/parameters/debug_dyn 
[ 3137.044185] set_dyndbg: result:0x0 from 0x0
[ 3137.044185] 
[ 3137.047370] dyndbg: query 0: "format='^gvt: cmd: ' -p"
[ 3137.050302] dyndbg: entry, buf:'format='^gvt: cmd: ' -p'
[ 3137.053331] dyndbg: start-of-word:0 'format='^gvt: cmd: ' -p'

These patches were the test/use case for-59 fixes:
https://lore.kernel.org/lkml/20200825173339.2082585-1-jim.cro...@gmail.com/


Jim Cromie (4):
  drm-printk: POC caller of dynamic-debug-exec-queries
  drm-printk: call pr_debug() from drm_dev_dbg, __drm_dbg
  i915: add -DDYNAMIC_DEBUG_MODULE to i915/gvt/Makefile
  i915: POC use dynamic_debug_exec_queries to control pr_debugs in gvt

 drivers/gpu/drm/drm_print.c| 54 ++---
 drivers/gpu/drm/i915/gvt/Makefile  |  5 +-
 drivers/gpu/drm/i915/i915_params.c | 76 ++
 3 files changed, 127 insertions(+), 8 deletions(-)

-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] docs: fb: Correcting the location of FRAMEBUFFER_CONSOLE option.

[Bilal Wasim]

Hi All, 

On Mon, 24 Aug 2020 19:51:55 +0500
Bilal Wasim  wrote:

> fbcon doc mentions FRAMEBUFFER_CONSOLE option to be under
> Device Drivers->Graphics Support->Frame buffer Devices->
> Console display driver support->Framebuffer Console Support,
> while its under Device Drivers->Graphics Support->
> Console display driver support->Framebuffer Console Support.
> 
> Correcting it in the docs.
> 
> Signed-off-by: Bilal Wasim 
> ---
>  Documentation/fb/fbcon.rst | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/fb/fbcon.rst b/Documentation/fb/fbcon.rst
> index e57a3d1d085a..a7b487cba307 100644
> --- a/Documentation/fb/fbcon.rst
> +++ b/Documentation/fb/fbcon.rst
> @@ -20,8 +20,8 @@ A. Configuration
>  
>  
>  The framebuffer console can be enabled by using your favorite kernel
> -configuration tool.  It is under Device Drivers->Graphics
> Support->Frame -buffer Devices->Console display driver
> support->Framebuffer Console Support. +configuration tool.  It is
> under Device Drivers->Graphics Support-> +Console display driver
> support->Framebuffer Console Support. Select 'y' to compile support
> statically or 'm' for module support.  The module will be fbcon.
>  

Can this simple patch be merged? 

-Bilal
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/ingenic: Fix driver not probing when IPU port is missing

[Paul Cercueil]

Even if support for the IPU was compiled in, we may run on a device
(e.g. the Qi LB60) where the IPU is not available, or simply with an old
devicetree without the IPU node. In that case the ingenic-drm refused to
probe.

Fix the driver so that it will probe even if the IPU node is not present
in devicetree (but then IPU support is disabled of course).

Fixes: fc1acf317b01 ("drm/ingenic: Add support for the IPU")
Signed-off-by: Paul Cercueil 
---
 drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 23 ---
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c 
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index ada990a7f911..216b67f1672e 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -673,6 +673,18 @@ static void ingenic_drm_unbind_all(void *d)
component_unbind_all(priv->dev, >drm);
 }
 
+static inline struct device_node *ingenic_drm_get_ipu_node(struct device *dev)
+{
+   /* IPU is at port address 8 */
+   return of_graph_get_remote_node(dev->of_node, 8, 0);
+}
+
+static inline bool ingenic_drm_has_ipu(struct device *dev)
+{
+   return IS_ENABLED(CONFIG_DRM_INGENIC_IPU) &&
+   !!ingenic_drm_get_ipu_node(dev);
+}
+
 static int ingenic_drm_bind(struct device *dev)
 {
struct platform_device *pdev = to_platform_device(dev);
@@ -808,7 +820,7 @@ static int ingenic_drm_bind(struct device *dev)
return ret;
}
 
-   if (IS_ENABLED(CONFIG_DRM_INGENIC_IPU)) {
+   if (ingenic_drm_has_ipu(dev)) {
ret = component_bind_all(dev, drm);
if (ret) {
if (ret != -EPROBE_DEFER)
@@ -970,12 +982,9 @@ static int ingenic_drm_probe(struct platform_device *pdev)
if (!IS_ENABLED(CONFIG_DRM_INGENIC_IPU))
return ingenic_drm_bind(dev);
 
-   /* IPU is at port address 8 */
-   np = of_graph_get_remote_node(dev->of_node, 8, 0);
-   if (!np) {
-   dev_err(dev, "Unable to get IPU node\n");
-   return -EINVAL;
-   }
+   np = ingenic_drm_get_ipu_node(dev);
+   if (!np)
+   return ingenic_drm_bind(dev);
 
drm_of_component_match_add(dev, , compare_of, np);
 
-- 
2.28.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RESEND PATCH v2 0/2] Convert mtk-dpi to drm_bridge API

[Enric Balletbo i Serra]

The mtk-dpi driver still uses the drm_encoder API which is now somewhat
deprecated. We started to move all the Mediatek drivers to the drm_bridge API,
like we did for the mtk-dsi driver [1], this is another small step to be able to
fully convert the DRM Mediatek drivers to the drm_bridge API. A dummy
drm_encoder is maintained in the mtk-dpi driver but the end goal is move all the
dummy drm_encoder (mtk-dsi, mtk-dpi, etc) to the main mtk_drm_drv driver.

[1] https://lore.kernel.org/patchwork/project/lkml/list/?series=441559

Changes in v2:
- Maintain error message when attach to bridge fails. (Boris)

Enric Balletbo i Serra (2):
  drm/mediatek: mtk_dpi: Rename bridge to next_bridge
  drm/mediatek: mtk_dpi: Convert to bridge driver

 drivers/gpu/drm/mediatek/mtk_dpi.c | 77 +-
 1 file changed, 45 insertions(+), 32 deletions(-)

-- 
2.28.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 00/49] DRM driver for Hikey 970

[Nicolas Dufresne]

Le mardi 25 août 2020 à 13:30 +0200, Mauro Carvalho Chehab a écrit :
> Em Tue, 25 Aug 2020 05:29:29 +1000
> Dave Airlie  escreveu:
> 
> > On Thu, 20 Aug 2020 at 20:02, Laurent Pinchart
> >  wrote:
> > > Hi Mauro,
> > > 
> > > On Thu, Aug 20, 2020 at 09:03:26AM +0200, Mauro Carvalho Chehab wrote:  
> > > > Em Wed, 19 Aug 2020 12:52:06 -0700 John Stultz escreveu:  
> > > > > On Wed, Aug 19, 2020 at 8:31 AM Laurent Pinchart wrote:  
> > > > > > On Wed, Aug 19, 2020 at 05:21:20PM +0200, Sam Ravnborg wrote:  
> > > > > > > On Wed, Aug 19, 2020 at 01:45:28PM +0200, Mauro Carvalho Chehab 
> > > > > > > wrote:  
> > > > > > > > This patch series port the out-of-tree driver for Hikey 970 
> > > > > > > > (which
> > > > > > > > should also support Hikey 960) from the official 96boards tree:
> > > > > > > > 
> > > > > > > >https://github.com/96boards-hikey/linux/tree/hikey970-v4.9
> > > > > > > > 
> > > > > > > > Based on his history, this driver seems to be originally written
> > > > > > > > for Kernel 4.4, and was later ported to Kernel 4.9. The original
> > > > > > > > driver used to depend on ION (from Kernel 4.4) and had its own
> > > > > > > > implementation for FB dev API.
> > > > > > > > 
> > > > > > > > As I need to preserve the original history (with has patches 
> > > > > > > > from
> > > > > > > > both HiSilicon and from Linaro),  I'm starting from the original
> > > > > > > > patch applied there. The remaining patches are incremental,
> > > > > > > > and port this driver to work with upstream Kernel.
> > > > > > > >  
> > > > > ...  
> > > > > > > > - Due to legal reasons, I need to preserve the authorship of
> > > > > > > >   each one responsbile for each patch. So, I need to start from
> > > > > > > >   the original patch from Kernel 4.4;  
> > > > > ...  
> > > > > > > I do acknowledge you need to preserve history and all -
> > > > > > > but this patchset is not easy to review.  
> > > > > > 
> > > > > > Why do we need to preserve history ? Adding relevant Signed-off-by 
> > > > > > and
> > > > > > Co-developed-by should be enough, shouldn't it ? Having a public 
> > > > > > branch
> > > > > > that contains the history is useful if anyone is interested, but I 
> > > > > > don't
> > > > > > think it's required in mainline.  
> > > > > 
> > > > > Yea. I concur with Laurent here. I'm not sure what legal reasoning you
> > > > > have on this but preserving the "absolute" history here is actively
> > > > > detrimental for review and understanding of the patch set.
> > > > > 
> > > > > Preserving Authorship, Signed-off-by lines and adding Co-developed-by
> > > > > lines should be sufficient to provide both atribution credit and DCO
> > > > > history.  
> > > > 
> > > > I'm not convinced that, from legal standpoint, folding things would
> > > > be enough. See, there are at least 3 legal systems involved here
> > > > among the different patch authors:
> > > > 
> > > >   - civil law;
> > > >   - common law;
> > > >   - customary law + common law.
> > > > 
> > > > Merging stuff altogether from different law systems can be problematic,
> > > > and trying to discuss this with experienced IP property lawyers will
> > > > for sure take a lot of time and efforts. I also bet that different
> > > > lawyers will have different opinions, because laws are subject to
> > > > interpretation. With that matter I'm not aware of any court rules
> > > > with regards to folded patches. So, it sounds to me that folding
> > > > patches is something that has yet to be proofed in courts around
> > > > the globe.
> > > > 
> > > > At least for US legal system, it sounds that the Country of
> > > > origin of a patch is relevant, as they have a concept of
> > > > "national technology" that can be subject to export regulations.
> > > > 
> > > > From my side, I really prefer to play safe and stay out of any such
> > > > legal discussions.  
> > > 
> > > Let's be serious for a moment. If you think there are legal issues in
> > > taking GPL-v2.0-only patches and squashing them while retaining
> > > authorship information through tags, the Linux kernel if *full* of that.
> > > You also routinely modify patches that you commit to the media subsystem
> > > to fix "small issues".
> > > 
> > > The country of origin argument makes no sense either, the kernel code
> > > base if full of code coming from pretty much all country on the planet.
> > > 
> > > Keeping the patches separate make this hard to review. Please squash
> > > them.  
> > 
> > I'm inclined to agree with Laurent here.
> > 
> > Patches submitted as GPL-v2 with DCO lines and author names/companies
> > should be fine to be squashed and rearranged,
> > as long as the DCO and Authorship is kept somewhere in the new patch
> > that is applied.
> > 
> > Review is more important here.
> 
> Sorry, but I can't agree that review is more important than to be able
> to properly indicate copyrights in a valid way at the legal systems that
> it would apply ;-)

Regardless of the 

Re: [PATCH v2 1/5] drm/bridge_connector: Set default status connected for eDP connectors

[Bilal Wasim]

On Wed, 26 Aug 2020 10:15:22 +0200
Enric Balletbo i Serra  wrote:

> In an eDP application, HPD is not required and on most bridge chips
> useless. If HPD is not used, we need to set initial status as
> connected, otherwise the connector created by the
> drm_bridge_connector API remains in an unknown state.
> 
> Reviewed-by: Laurent Pinchart 
> Acked-by: Sam Ravnborg 
> Signed-off-by: Enric Balletbo i Serra 
> ---
> 
> Changes in v2:
> - Included the patch `drm/bridge_connector: Set default status
> connected for eDP connectors`
> 
>  drivers/gpu/drm/drm_bridge_connector.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/drm_bridge_connector.c
> b/drivers/gpu/drm/drm_bridge_connector.c index
> c6994fe673f3..a58cbde59c34 100644 ---
> a/drivers/gpu/drm/drm_bridge_connector.c +++
> b/drivers/gpu/drm/drm_bridge_connector.c @@ -187,6 +187,7 @@
> drm_bridge_connector_detect(struct drm_connector *connector, bool
> force) case DRM_MODE_CONNECTOR_DPI: case DRM_MODE_CONNECTOR_LVDS:
>   case DRM_MODE_CONNECTOR_DSI:
> + case DRM_MODE_CONNECTOR_eDP:
>   status = connector_status_connected;
>   break;
>   default:

Reviewed-by: Bilal Wasim 
Tested-by: Bilal Wasim 

-Bilal
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 5/5] drm/bridge: ps8640: Rework power state handling

[Bilal Wasim]

On Wed, 26 Aug 2020 10:15:26 +0200
Enric Balletbo i Serra  wrote:

> The get_edid() callback can be triggered anytime by an ioctl, i.e
> 
>   drm_mode_getconnector (ioctl)
> -> drm_helper_probe_single_connector_modes
>-> drm_bridge_connector_get_modes
>   -> ps8640_bridge_get_edid  
> 
> Actually if the bridge pre_enable() function was not called before
> get_edid(), the driver will not be able to get the EDID properly and
> display will not work until a second get_edid() call is issued and if
> pre_enable() is called before. The side effect of this, for example,
> is that you see anything when `Frecon` starts, neither the splash
> screen, until the graphical session manager starts.
> 
> To fix this we need to make sure that all we need is enabled before
> reading the EDID. This means the following:
> 
> 1. If get_edid() is called before having the device powered we need to
>power on the device. In such case, the driver will power off again
> the device.
> 
> 2. If get_edid() is called after having the device powered, all should
>just work. We added a powered flag in order to avoid recurrent
> calls to ps8640_bridge_poweron() and unneeded delays.
> 
> 3. This seems to be specific for this device, but we need to make sure
>the panel is powered on before do a power on cycle on this device.
>Otherwise the device fails to retrieve the EDID.
> 
> Signed-off-by: Enric Balletbo i Serra 
> ---
> 
> Changes in v2:
> - Use drm_bridge_chain_pre_enable/post_disable() helpers (Sam
> Ravnborg)
> 
>  drivers/gpu/drm/bridge/parade-ps8640.c | 64
> +++--- 1 file changed, 58 insertions(+), 6
> deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
> b/drivers/gpu/drm/bridge/parade-ps8640.c index
> 9f7b7a9c53c5..c5d76e209bda 100644 ---
> a/drivers/gpu/drm/bridge/parade-ps8640.c +++
> b/drivers/gpu/drm/bridge/parade-ps8640.c @@ -65,6 +65,7 @@ struct
> ps8640 { struct regulator_bulk_data supplies[2];
>   struct gpio_desc *gpio_reset;
>   struct gpio_desc *gpio_powerdown;
> + bool powered;
>  };
>  
>  static inline struct ps8640 *bridge_to_ps8640(struct drm_bridge *e)
> @@ -91,13 +92,15 @@ static int ps8640_bridge_vdo_control(struct
> ps8640 *ps_bridge, return 0;
>  }
>  
> -static void ps8640_pre_enable(struct drm_bridge *bridge)
> +static void ps8640_bridge_poweron(struct ps8640 *ps_bridge)
>  {
> - struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
>   struct i2c_client *client = ps_bridge->page[PAGE2_TOP_CNTL];
>   unsigned long timeout;
>   int ret, status;
>  
> + if (ps_bridge->powered)
> + return;
> +
>   ret = regulator_bulk_enable(ARRAY_SIZE(ps_bridge->supplies),
>   ps_bridge->supplies);
>   if (ret < 0) {
> @@ -164,6 +167,8 @@ static void ps8640_pre_enable(struct drm_bridge
> *bridge) goto err_regulators_disable;
>   }
>  
> + ps_bridge->powered = true;
> +
>   return;
>  
>  err_regulators_disable:
> @@ -171,12 +176,12 @@ static void ps8640_pre_enable(struct drm_bridge
> *bridge) ps_bridge->supplies);
>  }
>  
> -static void ps8640_post_disable(struct drm_bridge *bridge)
> +static void ps8640_bridge_poweroff(struct ps8640 *ps_bridge)
>  {
> - struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
>   int ret;
>  
> - ps8640_bridge_vdo_control(ps_bridge, DISABLE);
> + if (!ps_bridge->powered)
> + return;
>  
>   gpiod_set_value(ps_bridge->gpio_reset, 1);
>   gpiod_set_value(ps_bridge->gpio_powerdown, 1);
> @@ -184,6 +189,28 @@ static void ps8640_post_disable(struct
> drm_bridge *bridge) ps_bridge->supplies);
>   if (ret < 0)
>   DRM_ERROR("cannot disable regulators %d\n", ret);
> +
> + ps_bridge->powered = false;
> +}
> +
> +static void ps8640_pre_enable(struct drm_bridge *bridge)
> +{
> + struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
> + int ret;
> +
> + ps8640_bridge_poweron(ps_bridge);
> +
> + ret = ps8640_bridge_vdo_control(ps_bridge, DISABLE);
> + if (ret < 0)
> + ps8640_bridge_poweroff(ps_bridge);
> +}
> +
> +static void ps8640_post_disable(struct drm_bridge *bridge)
> +{
> + struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
> +
> + ps8640_bridge_vdo_control(ps_bridge, DISABLE);
> + ps8640_bridge_poweroff(ps_bridge);
>  }
>  
>  static int ps8640_bridge_attach(struct drm_bridge *bridge,
> @@ -249,9 +276,34 @@ static struct edid
> *ps8640_bridge_get_edid(struct drm_bridge *bridge, struct
> drm_connector *connector) {
>   struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
> + bool poweroff = !ps_bridge->powered;
> + struct edid *edid;
> +
> + /*
> +  * When we end calling get_edid() triggered by an ioctl, i.e
> +  *
> +  *   drm_mode_getconnector (ioctl)
> +  * -> drm_helper_probe_single_connector_modes
> +  *-> drm_bridge_connector_get_modes
> +  *   -> ps8640_bridge_get_edid
> 

Re: [PATCH RFC v6 1/6] dt-bindings: display: add Unisoc's drm master bindings

[Kevin Tang]

Sam Ravnborg  于2020年7月29日周三 上午4:27写道：
>
> Hi Kevin
>
> On Tue, Jul 28, 2020 at 06:07:54PM +0800, Kevin Tang wrote:
> > From: Kevin Tang 
> >
> > The Unisoc DRM master device is a virtual device needed to list all
> > DPU devices or other display interface nodes that comprise the
> > graphics subsystem
> >
> > Cc: Orson Zhai 
> > Cc: Chunyan Zhang 
> > Signed-off-by: Kevin Tang 
> > ---
> >  .../devicetree/bindings/display/sprd/drm.yaml  | 36 
> > ++
> >  1 file changed, 36 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/display/sprd/drm.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/display/sprd/drm.yaml 
> > b/Documentation/devicetree/bindings/display/sprd/drm.yaml
> > new file mode 100644
> > index 000..b5792c0
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/sprd/drm.yaml
> drm seems like a sub-optimal name.
> How about usign the compatible name "display-subsystem" as it is a bit
> more specific (but not good).
You're right, maybe "sprd,drm.yaml" or "sprd-drm.yaml" will be better
>
> > @@ -0,0 +1,36 @@
> > +# SPDX-License-Identifier: GPL-2.0
>
> Any chance this can be (GPL-2.0-only OR BSD-2-Clause).
> I noticed that for example clock/sprd,sc9863a-clk.yaml uses this license
> so I hope this is OK.
I will add GPL-2.0-only to it.
>
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/sprd/drm.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Unisoc DRM master device
> > +
> > +maintainers:
> > +  - Mark Rutland 
> > +
> > +description: |
> > +  The Unisoc DRM master device is a virtual device needed to list all
> > +  DPU devices or other display interface nodes that comprise the
> > +  graphics subsystem.
> > +
> > +properties:
> > +  compatible:
> > +const: sprd,display-subsystem
> > +
> > +  ports:
> > +description:
> > +  Should contain a list of phandles pointing to display interface port
> > +  of DPU devices.
> Add type - like this:
> $ref: /schemas/types.yaml#/definitions/phandle-array
>
> See for example display/rockchip/rockchip-drm.yaml
>
> Any specific reason why this is not a ports node like used by many other
> display bindings?
> In other words - I think this is too simple.
We only support one display pipeline now, other interface, like
DP(DisplayPort), HDMI...will be add later...

  ports:
$ref: /schemas/types.yaml#/definitions/phandle-array
description: |
  Should contain a list of phandles pointing to display interface port
  of dpu devices.. dpu definitions as defined in
  Documentation/devicetree/bindings/display/sprd/sprd,dpu.yaml


>
> > +
> > +required:
> > +  - compatible
> > +  - ports
> > +
>
> Add:
> additionalProperties: false
>
> so we catch if other properties sneak in.
>
> > +examples:
> > +  - |
> > +display-subsystem {
> > +compatible = "sprd,display-subsystem";
> > +ports = <_out>;
> > +};
> > +
> > --
> > 2.7.4
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/8] Convert the intel iommu driver to the dma-iommu api

[Tom Murphy]

That would be great!

On Wed., Aug. 26, 2020, 2:14 p.m. Robin Murphy, 
wrote:

> Hi Tom,
>
> On 2019-12-21 15:03, Tom Murphy wrote:
> > This patchset converts the intel iommu driver to the dma-iommu api.
> >
> > While converting the driver I exposed a bug in the intel i915 driver
> which causes a huge amount of artifacts on the screen of my laptop. You can
> see a picture of it here:
> >
> https://github.com/pippy360/kernelPatches/blob/master/IMG_20191219_225922.jpg
> >
> > This issue is most likely in the i915 driver and is most likely caused
> by the driver not respecting the return value of the dma_map_ops::map_sg
> function. You can see the driver ignoring the return value here:
> >
> https://github.com/torvalds/linux/blob/7e0165b2f1a912a06e381e91f0f4e495f4ac3736/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c#L51
> >
> > Previously this didn’t cause issues because the intel map_sg always
> returned the same number of elements as the input scatter gather list but
> with the change to this dma-iommu api this is no longer the case. I wasn’t
> able to track the bug down to a specific line of code unfortunately.
> >
> > Could someone from the intel team look at this?
> >
> >
> > I have been testing on a lenovo x1 carbon 5th generation. Let me know if
> there’s any more information you need.
> >
> > To allow my patch set to be tested I have added a patch (patch 8/8) in
> this series to disable combining sg segments in the dma-iommu api which
> fixes the bug but it doesn't fix the actual problem.
> >
> > As part of this patch series I copied the intel bounce buffer code to
> the dma-iommu path. The addition of the bounce buffer code took me by
> surprise. I did most of my development on this patch series before the
> bounce buffer code was added and my reimplementation in the dma-iommu path
> is very rushed and not properly tested but I’m running out of time to work
> on this patch set.
> >
> > On top of that I also didn’t port over the intel tracing code from this
> commit:
> >
> https://github.com/torvalds/linux/commit/3b53034c268d550d9e8522e613a14ab53b8840d8#diff-6b3e7c4993f05e76331e463ab1fc87e1
> > So all the work in that commit is now wasted. The code will need to be
> removed and reimplemented in the dma-iommu path. I would like to take the
> time to do this but I really don’t have the time at the moment and I want
> to get these changes out before the iommu code changes any more.
>
> Further to what we just discussed at LPC, I've realised that tracepoints
> are actually something I could do with *right now* for debugging my Arm
> DMA ops series, so if I'm going to hack something up anyway I may as
> well take responsibility for polishing it into a proper patch as well :)
>
> Robin.
>
> >
> > Tom Murphy (8):
> >iommu/vt-d: clean up 32bit si_domain assignment
> >iommu/vt-d: Use default dma_direct_* mapping functions for direct
> >  mapped devices
> >iommu/vt-d: Remove IOVA handling code from non-dma_ops path
> >iommu: Handle freelists when using deferred flushing in iommu drivers
> >iommu: Add iommu_dma_free_cpu_cached_iovas function
> >iommu: allow the dma-iommu api to use bounce buffers
> >iommu/vt-d: Convert intel iommu driver to the iommu ops
> >DO NOT MERGE: iommu: disable list appending in dma-iommu
> >
> >   drivers/iommu/Kconfig   |   1 +
> >   drivers/iommu/amd_iommu.c   |  14 +-
> >   drivers/iommu/arm-smmu-v3.c |   3 +-
> >   drivers/iommu/arm-smmu.c|   3 +-
> >   drivers/iommu/dma-iommu.c   | 183 +--
> >   drivers/iommu/exynos-iommu.c|   3 +-
> >   drivers/iommu/intel-iommu.c | 936 
> >   drivers/iommu/iommu.c   |  39 +-
> >   drivers/iommu/ipmmu-vmsa.c  |   3 +-
> >   drivers/iommu/msm_iommu.c   |   3 +-
> >   drivers/iommu/mtk_iommu.c   |   3 +-
> >   drivers/iommu/mtk_iommu_v1.c|   3 +-
> >   drivers/iommu/omap-iommu.c  |   3 +-
> >   drivers/iommu/qcom_iommu.c  |   3 +-
> >   drivers/iommu/rockchip-iommu.c  |   3 +-
> >   drivers/iommu/s390-iommu.c  |   3 +-
> >   drivers/iommu/tegra-gart.c  |   3 +-
> >   drivers/iommu/tegra-smmu.c  |   3 +-
> >   drivers/iommu/virtio-iommu.c|   3 +-
> >   drivers/vfio/vfio_iommu_type1.c |   2 +-
> >   include/linux/dma-iommu.h   |   3 +
> >   include/linux/intel-iommu.h |   1 -
> >   include/linux/iommu.h   |  32 +-
> >   23 files changed, 345 insertions(+), 908 deletions(-)
> >
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/dp: For MST hub, Get max_link_rate_lane from extended rx capability field if EXTENDED_RECEIVER_CAPABILITY_FILED_PRESENT is set.

[Koba Ko]

Currently, DRM get the capability of the mst hub only from DP_DPCD_REV and
get the slower speed even the mst hub can run in the faster speed.

As per DP-1.3, First check DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT.
If DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT is 1, read the DP_DP13_DPCD_REV to
get the faster capability.
If DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT is 0, read DP_DPCD_REV.

Signed-off-by: Koba Ko 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 67dd72ea200e..3b84c6801281 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3497,6 +3497,8 @@ static int drm_dp_get_vc_payload_bw(u8 dp_link_bw, u8  
dp_link_count)
 int drm_dp_mst_topology_mgr_set_mst(struct drm_dp_mst_topology_mgr *mgr, bool 
mst_state)
 {
int ret = 0;
+   u8 dpcd_ext = 0;
+   unsigned int dpcd_offset = 0;
struct drm_dp_mst_branch *mstb = NULL;
 
mutex_lock(>payload_lock);
@@ -3510,9 +3512,15 @@ int drm_dp_mst_topology_mgr_set_mst(struct 
drm_dp_mst_topology_mgr *mgr, bool ms
struct drm_dp_payload reset_pay;
 
WARN_ON(mgr->mst_primary);
+   drm_dp_dpcd_read(mgr->aux,
+DP_TRAINING_AUX_RD_INTERVAL,
+_ext, sizeof(dpcd_ext));
+
+   dpcd_offset =
+   ((dpcd_ext & DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT) ?  
DP_DP13_DPCD_REV : DP_DPCD_REV);
 
/* get dpcd info */
-   ret = drm_dp_dpcd_read(mgr->aux, DP_DPCD_REV, mgr->dpcd, 
DP_RECEIVER_CAP_SIZE);
+   ret = drm_dp_dpcd_read(mgr->aux, dpcd_offset, mgr->dpcd, 
DP_RECEIVER_CAP_SIZE);
if (ret != DP_RECEIVER_CAP_SIZE) {
DRM_DEBUG_KMS("failed to read DPCD\n");
goto out_unlock;
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: virtio: fix kconfig dependency warning

[Randy Dunlap]

From: Randy Dunlap 

Fix kconfig dependency warning by using a different Kconfig symbol.

WARNING: unmet direct dependencies detected for VIRTIO_DMA_SHARED_BUFFER
  Depends on [n]: VIRTIO_MENU [=n] && DMA_SHARED_BUFFER [=y]
  Selected by [y]:
  - DRM_VIRTIO_GPU [=y] && HAS_IOMEM [=y] && DRM [=y] && VIRTIO [=y] && MMU [=y]

Signed-off-by: Randy Dunlap 
Cc: David Airlie 
Cc: Gerd Hoffmann 
Cc: dri-devel@lists.freedesktop.org
Cc: virtualizat...@lists.linux-foundation.org
---
Found in linux-next but applies to mainline.

 drivers/gpu/drm/virtio/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20200826.orig/drivers/gpu/drm/virtio/Kconfig
+++ linux-next-20200826/drivers/gpu/drm/virtio/Kconfig
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0-only
 config DRM_VIRTIO_GPU
tristate "Virtio GPU driver"
-   depends on DRM && VIRTIO && MMU
+   depends on DRM && VIRTIO_MENU && MMU
select DRM_KMS_HELPER
select DRM_GEM_SHMEM_HELPER
select VIRTIO_DMA_SHARED_BUFFER

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 3/5] drm/bridge: ps8640: Return an error for incorrect attach flags

[Enric Balletbo i Serra]

Bridge drivers that implement the new model only shall return an error
from their attach() handler when the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag
is not set. So make sure we return an error because only the new
drm_bridge model is supported.

Reviewed-by: Sam Ravnborg 
Signed-off-by: Enric Balletbo i Serra 
---

Changes in v2: None

 drivers/gpu/drm/bridge/parade-ps8640.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
b/drivers/gpu/drm/bridge/parade-ps8640.c
index 13755d278db6..ce3e8b2da8c9 100644
--- a/drivers/gpu/drm/bridge/parade-ps8640.c
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -200,6 +200,10 @@ static int ps8640_bridge_attach(struct drm_bridge *bridge,
   .channel = 0,
   .node = NULL,
 };
+
+   if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR))
+   return -EINVAL;
+
/* port@0 is ps8640 dsi input port */
in_ep = of_graph_get_endpoint_by_regs(dev->of_node, 0, -1);
if (!in_ep)
-- 
2.28.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 2/5] drm/bridge: ps8640: Get the EDID from eDP control

[Enric Balletbo i Serra]

The PS8640 DSI-to-eDP bridge can retrieve the EDID, so implement the
.get_edid callback and set the flag to indicate the core to use it.

Reviewed-by: Laurent Pinchart 
Acked-by: Sam Ravnborg 
Signed-off-by: Enric Balletbo i Serra 
---

Changes in v2:
- Included the patch `drm/bridge: ps8640: Get the EDID from eDP control`

 drivers/gpu/drm/bridge/parade-ps8640.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
b/drivers/gpu/drm/bridge/parade-ps8640.c
index 4b099196afeb..13755d278db6 100644
--- a/drivers/gpu/drm/bridge/parade-ps8640.c
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -242,8 +242,18 @@ static int ps8640_bridge_attach(struct drm_bridge *bridge,
return ret;
 }
 
+static struct edid *ps8640_bridge_get_edid(struct drm_bridge *bridge,
+  struct drm_connector *connector)
+{
+   struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+
+   return drm_get_edid(connector,
+   ps_bridge->page[PAGE0_DP_CNTL]->adapter);
+}
+
 static const struct drm_bridge_funcs ps8640_bridge_funcs = {
.attach = ps8640_bridge_attach,
+   .get_edid = ps8640_bridge_get_edid,
.post_disable = ps8640_post_disable,
.pre_enable = ps8640_pre_enable,
 };
@@ -294,6 +304,8 @@ static int ps8640_probe(struct i2c_client *client)
 
ps_bridge->bridge.funcs = _bridge_funcs;
ps_bridge->bridge.of_node = dev->of_node;
+   ps_bridge->bridge.ops = DRM_BRIDGE_OP_EDID;
+   ps_bridge->bridge.type = DRM_MODE_CONNECTOR_eDP;
 
ps_bridge->page[PAGE0_DP_CNTL] = client;
 
-- 
2.28.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 3/5] drm/bridge: ps8640: Return an error for incorrect attach flags

[Bilal Wasim]

On Wed, 26 Aug 2020 10:15:24 +0200
Enric Balletbo i Serra  wrote:

> Bridge drivers that implement the new model only shall return an error
> from their attach() handler when the DRM_BRIDGE_ATTACH_NO_CONNECTOR
> flag is not set. So make sure we return an error because only the new
> drm_bridge model is supported.
> 
> Reviewed-by: Sam Ravnborg 
> Signed-off-by: Enric Balletbo i Serra 
> ---
> 
> Changes in v2: None
> 
>  drivers/gpu/drm/bridge/parade-ps8640.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
> b/drivers/gpu/drm/bridge/parade-ps8640.c index
> 13755d278db6..ce3e8b2da8c9 100644 ---
> a/drivers/gpu/drm/bridge/parade-ps8640.c +++
> b/drivers/gpu/drm/bridge/parade-ps8640.c @@ -200,6 +200,10 @@ static
> int ps8640_bridge_attach(struct drm_bridge *bridge, .channel = 0,
>  .node = NULL,
>};
> +
> + if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR))
> + return -EINVAL;
> +
>   /* port@0 is ps8640 dsi input port */
>   in_ep = of_graph_get_endpoint_by_regs(dev->of_node, 0, -1);
>   if (!in_ep)

Reviewed-by: Bilal Wasim 
Tested-by: Bilal Wasim 

-Bilal
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/4] i915: POC use dynamic_debug_exec_queries to control pr_debugs in gvt

[Jim Cromie]

The gvt component of this driver has ~120 pr_debugs, in 9 "classes".
Add a "knob", like drm.debug, to map bits to these classes.

bash-5.0# echo 0x01 > /sys/module/i915/parameters/debug_dyn
 set_dyndbg: result:0x1 from 0x01
 dyndbg: query 0: "format='^gvt: cmd: ' +p"
 dyndbg: entry, buf:'format='^gvt: cmd: ' +p'
 dyndbg: start-of-word:0 'format='^gvt: cmd: ' +p'
 dyndbg: start-of-word:1 ''^gvt: cmd: ' +p'
 dyndbg: start-of-word:2 '+p'
 dyndbg: split into words: "format" "^gvt: cmd: " "+p"
 dyndbg: op='+'
 dyndbg: flags=0x1
 dyndbg: *flagsp=0x1 *maskp=0x
 dyndbg: key:'format' arg:'^gvt: cmd: '
 dyndbg: parsed: func="" file="" module="i915" format="^gvt: cmd: " lineno=0-0
 dyndbg: changed drivers/gpu/drm/i915/gvt/cmd_parser.c:3081 
[i915]init_cmd_table =p
 dyndbg: changed drivers/gpu/drm/i915/gvt/cmd_parser.c:1376 
[i915]gen8_check_mi_display_flip =p
 dyndbg: changed drivers/gpu/drm/i915/gvt/cmd_parser.c:1373 
[i915]gen8_check_mi_display_flip =p
 dyndbg: changed drivers/gpu/drm/i915/gvt/cmd_parser.c:745 
[i915]parser_exec_state_dump =p
 dyndbg: changed drivers/gpu/drm/i915/gvt/cmd_parser.c:744 
[i915]parser_exec_state_dump =p
 dyndbg: changed drivers/gpu/drm/i915/gvt/cmd_parser.c:742 
[i915]parser_exec_state_dump =p
 dyndbg: changed drivers/gpu/drm/i915/gvt/cmd_parser.c:733 
[i915]parser_exec_state_dump =p
 dyndbg: changed drivers/gpu/drm/i915/gvt/cmd_parser.c:729 
[i915]parser_exec_state_dump =p
 dyndbg: changed drivers/gpu/drm/i915/gvt/cmd_parser.c:722 
[i915]parser_exec_state_dump =p
 dyndbg: changed drivers/gpu/drm/i915/gvt/cmd_parser.c:716 
[i915]parser_exec_state_dump =p
 dyndbg: changed drivers/gpu/drm/i915/gvt/cmd_parser.c:691 [i915]print_opcode =p
 dyndbg: applied: func="" file="" module="i915" format="^gvt: cmd: " lineno=0-0
 dyndbg: processed 1 queries, with 11 matches, 0 errs
 change ct:11 on format='gvt: cmd: '
 change ct:11

Signed-off-by: Jim Cromie 
---
 drivers/gpu/drm/i915/i915_params.c | 76 ++
 1 file changed, 76 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 8d8db9ff0a48..4e1f01ab4865 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -255,3 +255,79 @@ void i915_params_free(struct i915_params *params)
I915_PARAMS_FOR_EACH(FREE);
 #undef FREE
 }
+
+/* POC for callback -> dynamic_debug_exec_queries */
+unsigned long __new_knob;
+EXPORT_SYMBOL(__new_knob);
+
+static char *pr_debug_classes[] = {
+   "gvt: cmd: ",
+   "gvt: core: ",
+   "gvt: dpy: ",
+   "gvt: el: ",
+   "gvt: irq: ",
+   "gvt: mm: ",
+   "gvt: mmio: ",
+   "gvt: render: ",
+   "gvt: sched: "
+};
+#define NUM_CLASSESARRAY_SIZE(pr_debug_classes)
+#define OUR_QUERY_SIZE 128 /* we need about 20 */
+
+#include 
+
+static int param_set_dyndbg(const char *instr, const struct kernel_param *kp)
+{
+   static unsigned long int old_val;
+unsigned int val;
+   unsigned long int changes, result;
+   int rc, chgct = 0, totct = 0, bitpos;
+   char query[OUR_QUERY_SIZE];
+
+   rc = kstrtouint(instr, 0, );
+   if (rc) {
+   pr_err("set_dyndbg: failed\n");
+   return -EINVAL;
+   }
+   result = val;
+   pr_info("set_dyndbg: result:0x%lx from %s\n", result, instr);
+
+   changes = result ^ old_val;
+
+   for_each_set_bit(bitpos, , NUM_CLASSES) {
+
+   sprintf(query, "format='^%s' %cp", pr_debug_classes[bitpos],
+   test_bit(bitpos, ) ? '+' : '-');
+
+   chgct = dynamic_debug_exec_queries(query, "i915");
+   totct += chgct;
+   pr_info("change ct:%d on format='%s'\n", chgct,
+   pr_debug_classes[bitpos]);
+   }
+   old_val = result;
+   pr_info("change ct:%d\n", totct);
+   return 0;
+}
+static int param_get_dyndbg(char *buffer, const struct kernel_param *kp)
+{
+   return scnprintf(buffer, PAGE_SIZE, "%u\n",
+*((unsigned int *)kp->arg));
+}
+static const struct kernel_param_ops param_ops_dyndbg = {
+   .set = param_set_dyndbg,
+   .get = param_get_dyndbg,
+};
+
+MODULE_PARM_DESC(debug_dyn, " enable dynamic-debug by format-string 
classifications.\n"
+"\t\twhich are:"
+"\n\t\t gvt: cmd:"
+"\n\t\t gvt: core:"
+"\n\t\t gvt: dpy:"
+"\n\t\t gvt: el:"
+"\n\t\t gvt: irq:"
+"\n\t\t gvt: mm:"
+"\n\t\t gvt: mmio:"
+"\n\t\t gvt: render:"
+"\n\t\t gvt: sched:" "\n");
+
+module_param_cb(debug_dyn, _ops_dyndbg, &__new_knob, 0644);
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Is: virtio_gpu_object_shmem_init issues? Was:Re: upstream boot error: general protection fault in swiotlb_map

[Thomas Tai]

Hello,
I had a similiar panic when booting an ARM VM with kernel v5.9-rc1. git 
bisect identified following bad commit. After reverting the bad commit, 
the VM boot ok. Maybe we should look into the following commit.


d323bb44e4d23802eb25d13de1f93f2335bd60d0 is the first bad commit
commit d323bb44e4d23802eb25d13de1f93f2335bd60d0
Author: Daniel Vetter 
Date:   Mon May 11 11:35:49 2020 +0200

drm/virtio: Call the right shmem helpers

drm_gem_shmem_get_sg_table is meant to implement
obj->funcs->get_sg_table, for prime exporting. The one we want is
drm_gem_shmem_get_pages_sgt, which also handles imported dma-buf, not
just native objects.

v2: Rebase, this stuff moved around in

commit 2f2aa13724d56829d910b2fa8e80c502d388f106
Author: Gerd Hoffmann 
Date:   Fri Feb 7 08:46:38 2020 +0100

drm/virtio: move virtio_gpu_mem_entry initialization to new 
function


Acked-by: Thomas Zimmermann 
Signed-off-by: Daniel Vetter 
Cc: David Airlie 
Cc: Gerd Hoffmann 
Cc: virtualizat...@lists.linux-foundation.org
Link: 
https://patchwork.freedesktop.org/patch/msgid/20200511093554.211493-5-daniel.vet...@ffwll.ch


Thank you,
Thomas


On 2020-08-24 11:06 a.m., Konrad Rzeszutek Wilk wrote:

On Thu, Aug 06, 2020 at 03:46:23AM -0700, syzbot wrote:

Hello,

syzbot found the following issue on:

HEAD commit:47ec5303 Merge git://git.kernel.org/pub/scm/linux/kernel/g..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=16fe1dea90
kernel config:  https://syzkaller.appspot.com/x/.config?x=7c06047f622c5724
dashboard link: https://syzkaller.appspot.com/bug?extid=3f86afd0b1e4bf1cb64c
compiler:   gcc (GCC) 10.1.0-syz 20200507

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+3f86afd0b1e4bf1cb...@syzkaller.appspotmail.com

ceph: loaded (mds proto 32)
NET: Registered protocol family 38
async_tx: api initialized (async)
Key type asymmetric registered
Asymmetric key parser 'x509' registered
Asymmetric key parser 'pkcs8' registered
Key type pkcs7_test registered
Asymmetric key parser 'tpm_parser' registered
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 243)
io scheduler mq-deadline registered
io scheduler kyber registered
io scheduler bfq registered
hgafb: HGA card not detected.
hgafb: probe of hgafb.0 failed with error -22
usbcore: registered new interface driver udlfb
uvesafb: failed to execute /sbin/v86d
uvesafb: make sure that the v86d helper is installed and executable
uvesafb: Getting VBE info block failed (eax=0x4f00, err=-2)
uvesafb: vbe_init() failed with -22
uvesafb: probe of uvesafb.0 failed with error -22
vga16fb: mapped to 0x8aac772d
Console: switching to colour frame buffer device 80x30
fb0: VGA16 VGA frame buffer device
input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
ACPI: Power Button [PWRF]
ioatdma: Intel(R) QuickData Technology Driver 5.00
PCI Interrupt Link [GSIF] enabled at IRQ 21
PCI Interrupt Link [GSIG] enabled at IRQ 22
PCI Interrupt Link [GSIH] enabled at IRQ 23
N_HDLC line discipline registered with maxframe=4096
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
00:05: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
Cyclades driver 2.6
Initializing Nozomi driver 2.1d
RocketPort device driver module, version 2.09, 12-June-2003
No rocketport ports found; unloading driver
Non-volatile memory driver v1.3
Linux agpgart interface v0.103
[drm] Initialized vgem 1.0.0 20120112 for vgem on minor 0
[drm] Initialized vkms 1.0.0 20180514 for vkms on minor 1
usbcore: registered new interface driver udl
[drm] pci: virtio-vga detected at :00:01.0
fb0: switching to virtiodrmfb from VGA16 VGA
Console: switching to colour VGA+ 80x25
virtio-pci :00:01.0: vgaarb: deactivate vga console
Console: switching to colour dummy device 80x25
[drm] features: -virgl +edid
[drm] number of scanouts: 1
[drm] number of cap sets: 0
[drm] Initialized virtio_gpu 0.1.0 0 for virtio0 on minor 2
general protection fault, probably for non-canonical address 
0xdc00:  [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x-0x0007]
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.8.0-syzkaller #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
RIP: 0010:swiotlb_map+0x5ac/0x700 kernel/dma/swiotlb.c:683
Code: 28 04 00 00 48 c1 ea 03 80 3c 02 00 0f 85 4d 01 00 00 4c 8b a5 18 04 00 00 48 
b8 00 00 00 00 00 fc ff df 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 0f 85 1e 01 00 00 
48 8d 7d 50 4d 8b 24 24 48 b8 00 00
RSP: :c934f3e0 EFLAGS: 00010246
RAX: dc00 RBX:  RCX: 8162cc1d
RDX:  RSI: 8162cc98 RDI: 88802971a470
RBP: 88802971a048 R08: 0001 R09: 8c5dba77
R10:  R11:  R12: 
R13: 7ac0 R14: 

Re: [PATCH v2 4/5] drm/bridge: ps8640: Print an error if VDO control fails

[Bilal Wasim]

On Wed, 26 Aug 2020 10:15:25 +0200
Enric Balletbo i Serra  wrote:

> Print an error message inside ps8640_bridge_vdo_control() function
> when it fails so we can simplify a bit the callers, they will only
> need to check the error code.
> 
> Reviewed-by: Sam Ravnborg 
> Signed-off-by: Enric Balletbo i Serra 
> ---
> 
> Changes in v2: None
> 
>  drivers/gpu/drm/bridge/parade-ps8640.c | 13 ++---
>  1 file changed, 6 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
> b/drivers/gpu/drm/bridge/parade-ps8640.c index
> ce3e8b2da8c9..9f7b7a9c53c5 100644 ---
> a/drivers/gpu/drm/bridge/parade-ps8640.c +++
> b/drivers/gpu/drm/bridge/parade-ps8640.c @@ -82,8 +82,11 @@ static
> int ps8640_bridge_vdo_control(struct ps8640 *ps_bridge, ret =
> i2c_smbus_write_i2c_block_data(client, PAGE3_SET_ADD,
> sizeof(vdo_ctrl_buf), vdo_ctrl_buf);
> - if (ret < 0)
> + if (ret < 0) {
> + DRM_ERROR("failed to %sable VDO: %d\n",
> +   ctrl == ENABLE ? "en" : "dis", ret);
>   return ret;
> + }
>  
>   return 0;
>  }
> @@ -150,10 +153,8 @@ static void ps8640_pre_enable(struct drm_bridge
> *bridge) }
>  
>   ret = ps8640_bridge_vdo_control(ps_bridge, ENABLE);
> - if (ret) {
> - DRM_ERROR("failed to enable VDO: %d\n", ret);
> + if (ret)
>   goto err_regulators_disable;
> - }
>  
>   /* Switch access edp panel's edid through i2c */
>   ret = i2c_smbus_write_byte_data(client, PAGE2_I2C_BYPASS,
> @@ -175,9 +176,7 @@ static void ps8640_post_disable(struct drm_bridge
> *bridge) struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
>   int ret;
>  
> - ret = ps8640_bridge_vdo_control(ps_bridge, DISABLE);
> - if (ret < 0)
> - DRM_ERROR("failed to disable VDO: %d\n", ret);
> + ps8640_bridge_vdo_control(ps_bridge, DISABLE);
>  
>   gpiod_set_value(ps_bridge->gpio_reset, 1);
>   gpiod_set_value(ps_bridge->gpio_powerdown, 1);

Reviewed-by: Bilal Wasim 
Tested-by: Bilal Wasim 

-Bilal
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 0/7] Convert mtk-dsi to drm_bridge API and get EDID for ps8640 bridge

[Enric Balletbo i Serra]

Hi Bilal,

On 24/8/20 21:01, Bilal Wasim wrote:
> Hi Chun-Kuan, Enric,
> 
> Is there any plan to merge the following commits in this series to the 
> mainline?
> 
>   drm/bridge: ps8640: Get the EDID from eDP control
>   drm/bridge_connector: Set default status connected for eDP connectors
> 

Just sent a new series including this patches:
https://lore.kernel.org/patchwork/project/lkml/list/?series=459760

Thanks,
 Enric

> I see that rest of the patchset is already merged and available in 5.9-RC2. 
> 
> Thanks,
> Bilal
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: Parse Colorimetry data block from EDID

[Algea Cao]

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_BLOCK  0x04
+#define COLORIMETRY_DATA_BLOCK 0x5
 #define HDR_STATIC_METADATA_BLOCK  0x6
 #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 = >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_SIZE  4
 
-- 
2.25.1



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] coccinelle: api: fix kobj_to_dev.cocci warnings

[Julia Lawall]

From: kernel test robot 

 Use kobj_to_dev() instead of container_of()

Generated by: scripts/coccinelle/api/kobj_to_dev.cocci

Fixes: a2fc3718bc22 ("coccinelle: api: add kobj_to_dev.cocci script")
CC: Denis Efremov 
Signed-off-by: kernel test robot 
Signed-off-by: Julia Lawall 

---

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/jlawall/linux.git 
for-5.10
head:   a2fc3718bc22e85378085568ecc5765fb28cabce
commit: a2fc3718bc22e85378085568ecc5765fb28cabce [3/3] coccinelle: api: add 
kobj_to_dev.cocci script
:: branch date: 5 days ago
:: commit date: 5 days ago

 udlfb.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/video/fbdev/udlfb.c
+++ b/drivers/video/fbdev/udlfb.c
@@ -1457,7 +1457,7 @@ static ssize_t edid_show(
struct file *filp,
struct kobject *kobj, struct bin_attribute *a,
 char *buf, loff_t off, size_t count) {
-   struct device *fbdev = container_of(kobj, struct device, kobj);
+   struct device *fbdev = kobj_to_dev(kobj);
struct fb_info *fb_info = dev_get_drvdata(fbdev);
struct dlfb_data *dlfb = fb_info->par;

@@ -1479,7 +1479,7 @@ static ssize_t edid_store(
struct file *filp,
struct kobject *kobj, struct bin_attribute *a,
char *src, loff_t src_off, size_t src_size) {
-   struct device *fbdev = container_of(kobj, struct device, kobj);
+   struct device *fbdev = kobj_to_dev(kobj);
struct fb_info *fb_info = dev_get_drvdata(fbdev);
struct dlfb_data *dlfb = fb_info->par;
int ret;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 0/7] make hdmi work on bananapi-r2

[Frank Wunderlich]

Just a gentle ping...any opinions?
regards Frank
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 0/5] drm/bridge: ps8640: Make sure all needed is powered to get the EDID

[Enric Balletbo i Serra]

The first patch was initially part of the series [1] but for some reason
was not picked when the series were merged, so I included in this series
because it is needed to make the others to work properly.

The same happened for the second patch, was part of series [1] but not
merged.

The third patch and next are part of the original series and are to rework
the power handling to get the EDID. Basically, we need to make sure all the
needed is powered to be able to get the EDID. Before, we saw that getting
the EDID failed as explained in the third patch.

[1] https://lkml.org/lkml/2020/6/15/1208

Changes in v2:
- Included the patch `drm/bridge_connector: Set default status connected for 
eDP connectors`
- Included the patch `drm/bridge: ps8640: Get the EDID from eDP control`
- Use drm_bridge_chain_pre_enable/post_disable() helpers (Sam Ravnborg)

Enric Balletbo i Serra (5):
  drm/bridge_connector: Set default status connected for eDP connectors
  drm/bridge: ps8640: Get the EDID from eDP control
  drm/bridge: ps8640: Return an error for incorrect attach flags
  drm/bridge: ps8640: Print an error if VDO control fails
  drm/bridge: ps8640: Rework power state handling

 drivers/gpu/drm/bridge/parade-ps8640.c | 89 ++
 drivers/gpu/drm/drm_bridge_connector.c |  1 +
 2 files changed, 79 insertions(+), 11 deletions(-)

-- 
2.28.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/4] i915: add -DDYNAMIC_DEBUG_MODULE to i915/gvt/Makefile

[Jim Cromie]

This addition to cflags enables dyndbg in the gvt component of the
i915 module, on a CONFIG_DYNAMIC_DEBUG_CORE build.

So here are the message classifications that the gvt driver uses.

   cut -d= -f2 | cut -d\  -f2,3 | \
   perl -ne 'chomp $_ && $h{$_}++; END{print "$_\" \tseen $h{$_}\n" for sort 
keys %h}'

"gvt: cmd:" seen 11
"gvt: core:"seen 48
"gvt: dpy:" seen 4
"gvt: el:"  seen 21
"gvt: irq:" seen 1
"gvt: mm:"  seen 6
"gvt: mmio:"seen 9
"gvt: render:"  seen 1
"gvt: sched:"   seen 15

Signed-off-by: Jim Cromie 
---
 drivers/gpu/drm/i915/gvt/Makefile | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/Makefile 
b/drivers/gpu/drm/i915/gvt/Makefile
index ea8324abc784..2c581e910688 100644
--- a/drivers/gpu/drm/i915/gvt/Makefile
+++ b/drivers/gpu/drm/i915/gvt/Makefile
@@ -5,5 +5,6 @@ GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o 
trace_points.o firmware.o \
execlist.o scheduler.o sched_policy.o mmio_context.o cmd_parser.o 
debugfs.o \
fb_decoder.o dmabuf.o page_track.o
 
-ccflags-y  += -I $(srctree)/$(src) -I 
$(srctree)/$(src)/$(GVT_DIR)/
-i915-y += $(addprefix $(GVT_DIR)/, 
$(GVT_SOURCE))
+ccflags-y  += -I $(srctree)/$(src) -I $(srctree)/$(src)/$(GVT_DIR)/
+ccflags-y  += -DDYNAMIC_DEBUG_MODULE
+i915-y += $(addprefix $(GVT_DIR)/, $(GVT_SOURCE))
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 4/5] drm/bridge: ps8640: Print an error if VDO control fails

[Enric Balletbo i Serra]

Print an error message inside ps8640_bridge_vdo_control() function when
it fails so we can simplify a bit the callers, they will only need to
check the error code.

Reviewed-by: Sam Ravnborg 
Signed-off-by: Enric Balletbo i Serra 
---

Changes in v2: None

 drivers/gpu/drm/bridge/parade-ps8640.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
b/drivers/gpu/drm/bridge/parade-ps8640.c
index ce3e8b2da8c9..9f7b7a9c53c5 100644
--- a/drivers/gpu/drm/bridge/parade-ps8640.c
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -82,8 +82,11 @@ static int ps8640_bridge_vdo_control(struct ps8640 
*ps_bridge,
ret = i2c_smbus_write_i2c_block_data(client, PAGE3_SET_ADD,
 sizeof(vdo_ctrl_buf),
 vdo_ctrl_buf);
-   if (ret < 0)
+   if (ret < 0) {
+   DRM_ERROR("failed to %sable VDO: %d\n",
+ ctrl == ENABLE ? "en" : "dis", ret);
return ret;
+   }
 
return 0;
 }
@@ -150,10 +153,8 @@ static void ps8640_pre_enable(struct drm_bridge *bridge)
}
 
ret = ps8640_bridge_vdo_control(ps_bridge, ENABLE);
-   if (ret) {
-   DRM_ERROR("failed to enable VDO: %d\n", ret);
+   if (ret)
goto err_regulators_disable;
-   }
 
/* Switch access edp panel's edid through i2c */
ret = i2c_smbus_write_byte_data(client, PAGE2_I2C_BYPASS,
@@ -175,9 +176,7 @@ static void ps8640_post_disable(struct drm_bridge *bridge)
struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
int ret;
 
-   ret = ps8640_bridge_vdo_control(ps_bridge, DISABLE);
-   if (ret < 0)
-   DRM_ERROR("failed to disable VDO: %d\n", ret);
+   ps8640_bridge_vdo_control(ps_bridge, DISABLE);
 
gpiod_set_value(ps_bridge->gpio_reset, 1);
gpiod_set_value(ps_bridge->gpio_powerdown, 1);
-- 
2.28.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RESEND PATCH v2 2/2] drm/mediatek: mtk_dpi: Convert to bridge driver

[Enric Balletbo i Serra]

Convert mtk_dpi to a bridge driver with built-in encoder support for
compatibility with existing component drivers.

Reviewed-by: Chun-Kuang Hu 
Signed-off-by: Enric Balletbo i Serra 
---

Changes in v2:
- Maintain error message when attach to bridge fails. (Boris)

 drivers/gpu/drm/mediatek/mtk_dpi.c | 71 ++
 1 file changed, 42 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index f7372dbdac0e..589ef33a1780 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -64,6 +64,7 @@ enum mtk_dpi_out_color_format {
 struct mtk_dpi {
struct mtk_ddp_comp ddp_comp;
struct drm_encoder encoder;
+   struct drm_bridge bridge;
struct drm_bridge *next_bridge;
void __iomem *regs;
struct device *dev;
@@ -83,9 +84,9 @@ struct mtk_dpi {
int refcount;
 };
 
-static inline struct mtk_dpi *mtk_dpi_from_encoder(struct drm_encoder *e)
+static inline struct mtk_dpi *bridge_to_dpi(struct drm_bridge *b)
 {
-   return container_of(e, struct mtk_dpi, encoder);
+   return container_of(b, struct mtk_dpi, bridge);
 }
 
 enum mtk_dpi_polarity {
@@ -521,50 +522,53 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
return 0;
 }
 
-static bool mtk_dpi_encoder_mode_fixup(struct drm_encoder *encoder,
-  const struct drm_display_mode *mode,
-  struct drm_display_mode *adjusted_mode)
+static void mtk_dpi_encoder_destroy(struct drm_encoder *encoder)
 {
-   return true;
+   drm_encoder_cleanup(encoder);
 }
 
-static void mtk_dpi_encoder_mode_set(struct drm_encoder *encoder,
-struct drm_display_mode *mode,
-struct drm_display_mode *adjusted_mode)
+static const struct drm_encoder_funcs mtk_dpi_encoder_funcs = {
+   .destroy = mtk_dpi_encoder_destroy,
+};
+
+static int mtk_dpi_bridge_attach(struct drm_bridge *bridge,
+enum drm_bridge_attach_flags flags)
 {
-   struct mtk_dpi *dpi = mtk_dpi_from_encoder(encoder);
+   struct mtk_dpi *dpi = bridge_to_dpi(bridge);
+
+   return drm_bridge_attach(bridge->encoder, dpi->next_bridge,
+>bridge, flags);
+}
+
+static void mtk_dpi_bridge_mode_set(struct drm_bridge *bridge,
+   const struct drm_display_mode *mode,
+   const struct drm_display_mode *adjusted_mode)
+{
+   struct mtk_dpi *dpi = bridge_to_dpi(bridge);
 
drm_mode_copy(>mode, adjusted_mode);
 }
 
-static void mtk_dpi_encoder_disable(struct drm_encoder *encoder)
+static void mtk_dpi_bridge_disable(struct drm_bridge *bridge)
 {
-   struct mtk_dpi *dpi = mtk_dpi_from_encoder(encoder);
+   struct mtk_dpi *dpi = bridge_to_dpi(bridge);
 
mtk_dpi_power_off(dpi);
 }
 
-static void mtk_dpi_encoder_enable(struct drm_encoder *encoder)
+static void mtk_dpi_bridge_enable(struct drm_bridge *bridge)
 {
-   struct mtk_dpi *dpi = mtk_dpi_from_encoder(encoder);
+   struct mtk_dpi *dpi = bridge_to_dpi(bridge);
 
mtk_dpi_power_on(dpi);
mtk_dpi_set_display_mode(dpi, >mode);
 }
 
-static int mtk_dpi_atomic_check(struct drm_encoder *encoder,
-   struct drm_crtc_state *crtc_state,
-   struct drm_connector_state *conn_state)
-{
-   return 0;
-}
-
-static const struct drm_encoder_helper_funcs mtk_dpi_encoder_helper_funcs = {
-   .mode_fixup = mtk_dpi_encoder_mode_fixup,
-   .mode_set = mtk_dpi_encoder_mode_set,
-   .disable = mtk_dpi_encoder_disable,
-   .enable = mtk_dpi_encoder_enable,
-   .atomic_check = mtk_dpi_atomic_check,
+static const struct drm_bridge_funcs mtk_dpi_bridge_funcs = {
+   .attach = mtk_dpi_bridge_attach,
+   .mode_set = mtk_dpi_bridge_mode_set,
+   .disable = mtk_dpi_bridge_disable,
+   .enable = mtk_dpi_bridge_enable,
 };
 
 static void mtk_dpi_start(struct mtk_ddp_comp *comp)
@@ -605,12 +609,11 @@ static int mtk_dpi_bind(struct device *dev, struct device 
*master, void *data)
dev_err(dev, "Failed to initialize decoder: %d\n", ret);
goto err_unregister;
}
-   drm_encoder_helper_add(>encoder, _dpi_encoder_helper_funcs);
 
/* Currently DPI0 is fixed to be driven by OVL1 */
dpi->encoder.possible_crtcs = BIT(1);
 
-   ret = drm_bridge_attach(>encoder, dpi->next_bridge, NULL, 0);
+   ret = drm_bridge_attach(>encoder, >bridge, NULL, 0);
if (ret) {
dev_err(dev, "Failed to attach bridge: %d\n", ret);
goto err_cleanup;
@@ -791,8 +794,15 @@ static int mtk_dpi_probe(struct platform_device *pdev)
 
platform_set_drvdata(pdev, dpi);
 
+   dpi->bridge.funcs = _dpi_bridge_funcs;
+   dpi->bridge.of_node = 

[PATCH v2 5/5] drm/bridge: ps8640: Rework power state handling

[Enric Balletbo i Serra]

The get_edid() callback can be triggered anytime by an ioctl, i.e

  drm_mode_getconnector (ioctl)
-> drm_helper_probe_single_connector_modes
   -> drm_bridge_connector_get_modes
  -> ps8640_bridge_get_edid

Actually if the bridge pre_enable() function was not called before
get_edid(), the driver will not be able to get the EDID properly and
display will not work until a second get_edid() call is issued and if
pre_enable() is called before. The side effect of this, for example, is
that you see anything when `Frecon` starts, neither the splash screen,
until the graphical session manager starts.

To fix this we need to make sure that all we need is enabled before
reading the EDID. This means the following:

1. If get_edid() is called before having the device powered we need to
   power on the device. In such case, the driver will power off again the
   device.

2. If get_edid() is called after having the device powered, all should
   just work. We added a powered flag in order to avoid recurrent calls
   to ps8640_bridge_poweron() and unneeded delays.

3. This seems to be specific for this device, but we need to make sure
   the panel is powered on before do a power on cycle on this device.
   Otherwise the device fails to retrieve the EDID.

Signed-off-by: Enric Balletbo i Serra 
---

Changes in v2:
- Use drm_bridge_chain_pre_enable/post_disable() helpers (Sam Ravnborg)

 drivers/gpu/drm/bridge/parade-ps8640.c | 64 +++---
 1 file changed, 58 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
b/drivers/gpu/drm/bridge/parade-ps8640.c
index 9f7b7a9c53c5..c5d76e209bda 100644
--- a/drivers/gpu/drm/bridge/parade-ps8640.c
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -65,6 +65,7 @@ struct ps8640 {
struct regulator_bulk_data supplies[2];
struct gpio_desc *gpio_reset;
struct gpio_desc *gpio_powerdown;
+   bool powered;
 };
 
 static inline struct ps8640 *bridge_to_ps8640(struct drm_bridge *e)
@@ -91,13 +92,15 @@ static int ps8640_bridge_vdo_control(struct ps8640 
*ps_bridge,
return 0;
 }
 
-static void ps8640_pre_enable(struct drm_bridge *bridge)
+static void ps8640_bridge_poweron(struct ps8640 *ps_bridge)
 {
-   struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
struct i2c_client *client = ps_bridge->page[PAGE2_TOP_CNTL];
unsigned long timeout;
int ret, status;
 
+   if (ps_bridge->powered)
+   return;
+
ret = regulator_bulk_enable(ARRAY_SIZE(ps_bridge->supplies),
ps_bridge->supplies);
if (ret < 0) {
@@ -164,6 +167,8 @@ static void ps8640_pre_enable(struct drm_bridge *bridge)
goto err_regulators_disable;
}
 
+   ps_bridge->powered = true;
+
return;
 
 err_regulators_disable:
@@ -171,12 +176,12 @@ static void ps8640_pre_enable(struct drm_bridge *bridge)
   ps_bridge->supplies);
 }
 
-static void ps8640_post_disable(struct drm_bridge *bridge)
+static void ps8640_bridge_poweroff(struct ps8640 *ps_bridge)
 {
-   struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
int ret;
 
-   ps8640_bridge_vdo_control(ps_bridge, DISABLE);
+   if (!ps_bridge->powered)
+   return;
 
gpiod_set_value(ps_bridge->gpio_reset, 1);
gpiod_set_value(ps_bridge->gpio_powerdown, 1);
@@ -184,6 +189,28 @@ static void ps8640_post_disable(struct drm_bridge *bridge)
 ps_bridge->supplies);
if (ret < 0)
DRM_ERROR("cannot disable regulators %d\n", ret);
+
+   ps_bridge->powered = false;
+}
+
+static void ps8640_pre_enable(struct drm_bridge *bridge)
+{
+   struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+   int ret;
+
+   ps8640_bridge_poweron(ps_bridge);
+
+   ret = ps8640_bridge_vdo_control(ps_bridge, DISABLE);
+   if (ret < 0)
+   ps8640_bridge_poweroff(ps_bridge);
+}
+
+static void ps8640_post_disable(struct drm_bridge *bridge)
+{
+   struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+
+   ps8640_bridge_vdo_control(ps_bridge, DISABLE);
+   ps8640_bridge_poweroff(ps_bridge);
 }
 
 static int ps8640_bridge_attach(struct drm_bridge *bridge,
@@ -249,9 +276,34 @@ static struct edid *ps8640_bridge_get_edid(struct 
drm_bridge *bridge,
   struct drm_connector *connector)
 {
struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+   bool poweroff = !ps_bridge->powered;
+   struct edid *edid;
+
+   /*
+* When we end calling get_edid() triggered by an ioctl, i.e
+*
+*   drm_mode_getconnector (ioctl)
+* -> drm_helper_probe_single_connector_modes
+*-> drm_bridge_connector_get_modes
+*   -> ps8640_bridge_get_edid
+*
+* We need to make sure that what we need is enabled before reading
+* EDID, 

[PATCH 2/4] drm-printk: call pr_debug() from drm_dev_dbg, __drm_dbg

[Jim Cromie]

Put the pr_debug() after the vaf setup work, so as to use it.  And
move the if-category-disabled-return after both, so the pr_debug()
runs unconditionally.

This lets both debug-printers execute independently, according to
their respective controls, allowing later comparison to each other.

 #> echo module=drm +pmftl > /proc/dynamic_debug/control
yields logging like:

 [1772] drm:drm_dev_dbg:305: i915 :00:02.0: 
[drm:intel_atomic_get_global_obj_state [i915]]
   Cat:16 Added new global object 6fa51dd6 state bbddcf9d to 
5f6e1bc3
 [1772] drm:drm_dev_dbg:305: i915 :00:02.0: 
[drm:intel_atomic_get_global_obj_state [i915]]
   Cat:16 Added new global object 2a5e020a state 2b3685ed to 
5f6e1bc3
 [198] drm:drm_dev_dbg:305: i915 :00:02.0: [drm:drm_update_vblank_count 
[drm]]
   Cat:32 updating vblank count on crtc 0: current=260920, diff=0, hw=192024 
hw_last=192024
 [1772] drm:__drm_dbg:331: [drm:drm_atomic_nonblocking_commit [drm]] Cat:16 
committing 5f6e1bc3 nonblocking
 [1772] drm:__drm_dbg:331: [drm:drm_mode_object_put.part.0 [drm]] Cat:1 OBJ ID: 
113 (4)
 [1772] drm:__drm_dbg:331: [drm:drm_ioctl [drm]] Cat:1 comm="gnome-shell" 
pid=1772, dev=0xe200, auth=1, I915_GEM_CREATE
 [1772] drm:__drm_dbg:331: [drm:drm_ioctl [drm]] Cat:1 comm="gnome-shell" 
pid=1772, dev=0xe200, auth=1, I915_GEM_SET_DOMAIN
 [1772] drm:__drm_dbg:331: [drm:drm_ioctl [drm]] Cat:1 comm="gnome-shell" 
pid=1772, dev=0xe200, auth=1, I915_GEM_SET_TILING
 [1772] drm:__drm_dbg:331: [drm:drm_ioctl [drm]] Cat:1 comm="gnome-shell" 
pid=1772, dev=0xe200, auth=1, I915_GEM_MMAP_OFFSET

Clearly, the mflt flags arent very helpful here, and callsite control
is all or nothing (since theres only 2 callsites handling all the
categories).  We are 1 below the function layer of interest, but
theres room for optimism.

Signed-off-by: Jim Cromie 
---
 drivers/gpu/drm/drm_print.c | 27 +--
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 52abaf2ae053..fa2bcf4ec475 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -27,6 +27,7 @@
 
 #include 
 
+#define DYNAMIC_DEBUG_MODULE
 #include 
 #include 
 #include 
@@ -61,17 +62,17 @@ EXPORT_SYMBOL(__drm_debug2);
 
 static int param_set_dyndbg(const char *val, const struct kernel_param *kp)
 {
-   int chgct, result;
+   int chgct, rc, result;
 
-   result = kstrtouint(val, 0, (unsigned int *)kp->arg);
-   pr_warn("set_dyndbg: result:%d from %s\n", result, val);
+   rc = kstrtouint(val, 0, );
+   pr_debug("set_dyndbg: rc:%d got:%d from %s\n", rc, result, val);
 
if (result)
chgct = dynamic_debug_exec_queries("module=drm* +p", NULL);
else
chgct = dynamic_debug_exec_queries("module=drm* -p", NULL);
 
-   pr_warn("change ct:%d\n", chgct);
+   pr_debug("change ct:%d\n", chgct);
return 0;
 }
 static int param_get_dyndbg(char *buffer, const struct kernel_param *kp)
@@ -297,13 +298,16 @@ void drm_dev_dbg(const struct device *dev, enum 
drm_debug_category category,
struct va_format vaf;
va_list args;
 
-   if (!drm_debug_enabled(category))
-   return;
-
va_start(args, format);
vaf.fmt = format;
vaf.va = 
 
+   dev_dbg(dev, "[" DRM_NAME ":%ps] Cat:%d %pV",
+   __builtin_return_address(0), category, );
+
+   if (!drm_debug_enabled(category))
+   return;
+
if (dev)
dev_printk(KERN_DEBUG, dev, "[" DRM_NAME ":%ps] %pV",
   __builtin_return_address(0), );
@@ -320,13 +324,16 @@ void __drm_dbg(enum drm_debug_category category, const 
char *format, ...)
struct va_format vaf;
va_list args;
 
-   if (!drm_debug_enabled(category))
-   return;
-
va_start(args, format);
vaf.fmt = format;
vaf.va = 
 
+   pr_debug("[" DRM_NAME ":%ps] Cat:%d %pV",
+__builtin_return_address(0), category, );
+
+   if (!drm_debug_enabled(category))
+   return;
+
printk(KERN_DEBUG "[" DRM_NAME ":%ps] %pV",
   __builtin_return_address(0), );
 
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/4] drm-printk: POC caller of dynamic-debug-exec-queries

[Jim Cromie]

Export of dynamic-debug-exec-queries exists for users like drm.

This commit is a 1st user-test; it adds a 2nd knob, __drm_debug2,
similar in function to __drm_debug.  module_param_cb wires it to a
callback which maps the input value to one of: "module=drm* +/-p".

The include is needed to see the exported function prototype.

Notes:

The define DEBUG at top of drm-printk enables all pr_debug()s,
independent of CONFIG_DYNAMIC_DEBUG_CORE.

drm-printk is an independent print control system using __drm_debug
bits.  The plan is to find the low-level macros in which to insert a
pr_debug call, their eventual callsites will have distinct METADATA,
so will be itemized in control, and individually selectable.

Signed-off-by: Jim Cromie 
---
 drivers/gpu/drm/drm_print.c | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 111b932cf2a9..52abaf2ae053 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -27,6 +27,7 @@
 
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -54,6 +55,40 @@ MODULE_PARM_DESC(debug, "Enable debug output, where each bit 
enables a debug cat
 "\t\tBit 8 (0x100) will enable DP messages (displayport code)");
 module_param_named(debug, __drm_debug, int, 0600);
 
+/* POC for callback -> ddebug_exec_queries */
+unsigned int __drm_debug2;
+EXPORT_SYMBOL(__drm_debug2);
+
+static int param_set_dyndbg(const char *val, const struct kernel_param *kp)
+{
+   int chgct, result;
+
+   result = kstrtouint(val, 0, (unsigned int *)kp->arg);
+   pr_warn("set_dyndbg: result:%d from %s\n", result, val);
+
+   if (result)
+   chgct = dynamic_debug_exec_queries("module=drm* +p", NULL);
+   else
+   chgct = dynamic_debug_exec_queries("module=drm* -p", NULL);
+
+   pr_warn("change ct:%d\n", chgct);
+   return 0;
+}
+static int param_get_dyndbg(char *buffer, const struct kernel_param *kp)
+{
+   return scnprintf(buffer, PAGE_SIZE, "%u\n",
+*((unsigned int *)kp->arg));
+}
+static const struct kernel_param_ops param_ops_dyndbg = {
+   .set = param_set_dyndbg,
+   .get = param_get_dyndbg,
+};
+
+MODULE_PARM_DESC(debug_dyn, "Enable debug output, where each bit enables a 
debug category.\n"
+"\t\tthese wont work yet\n");
+module_param_cb(debug_dyn, _ops_dyndbg, &__drm_debug2, 0644);
+
+
 void __drm_puts_coredump(struct drm_printer *p, const char *str)
 {
struct drm_print_iterator *iterator = p->arg;
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RESEND PATCH v2 1/2] drm/mediatek: mtk_dpi: Rename bridge to next_bridge

[Enric Balletbo i Serra]

This is really a cosmetic change just to make a bit more readable the
code after convert the driver to drm_bridge. The bridge variable name
will be used by the encoder drm_bridge, and the chained bridge will be
named next_bridge.

Reviewed-by: Chun-Kuang Hu 
Signed-off-by: Enric Balletbo i Serra 
---

Changes in v2: None

 drivers/gpu/drm/mediatek/mtk_dpi.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index d4f0fb7ad312..f7372dbdac0e 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -64,7 +64,7 @@ enum mtk_dpi_out_color_format {
 struct mtk_dpi {
struct mtk_ddp_comp ddp_comp;
struct drm_encoder encoder;
-   struct drm_bridge *bridge;
+   struct drm_bridge *next_bridge;
void __iomem *regs;
struct device *dev;
struct clk *engine_clk;
@@ -610,7 +610,7 @@ static int mtk_dpi_bind(struct device *dev, struct device 
*master, void *data)
/* Currently DPI0 is fixed to be driven by OVL1 */
dpi->encoder.possible_crtcs = BIT(1);
 
-   ret = drm_bridge_attach(>encoder, dpi->bridge, NULL, 0);
+   ret = drm_bridge_attach(>encoder, dpi->next_bridge, NULL, 0);
if (ret) {
dev_err(dev, "Failed to attach bridge: %d\n", ret);
goto err_cleanup;
@@ -770,11 +770,11 @@ static int mtk_dpi_probe(struct platform_device *pdev)
}
 
ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0,
- NULL, >bridge);
+ NULL, >next_bridge);
if (ret)
return ret;
 
-   dev_info(dev, "Found bridge node: %pOF\n", dpi->bridge->of_node);
+   dev_info(dev, "Found bridge node: %pOF\n", dpi->next_bridge->of_node);
 
comp_id = mtk_ddp_comp_get_id(dev->of_node, MTK_DPI);
if (comp_id < 0) {
-- 
2.28.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] dt-bindings: msm: disp: add yaml schemas for DPU and DSI bindings

[mkrishn]

On 2020-08-25 04:27, Rob Herring wrote:

On Mon, Aug 10, 2020 at 07:08:02PM +0530, Krishna Manikandan wrote:

MSM Mobile Display Subsytem (MDSS) encapsulates sub-blocks
like DPU display controller, DSI etc. Add YAML schema
for the device tree bindings for the same.

Signed-off-by: Krishna Manikandan 

Changes in v2:
- Changed dpu to DPU (Sam Ravnborg)
- Fixed indentation issues (Sam Ravnborg)
- Added empty line between different properties (Sam Ravnborg)
- Replaced reference txt files with  their corresponding
  yaml files (Sam Ravnborg)
- Modified the file to use "|" only when it is
  necessary (Sam Ravnborg)

Changes in v3:
- Corrected the license used (Rob Herring)
- Added maxItems for properties (Rob Herring)
- Dropped generic descriptions (Rob Herring)
- Added ranges property (Rob Herring)
- Corrected the indendation (Rob Herring)
- Added additionalProperties (Rob Herring)
- Split dsi file into two, one for dsi controller
  and another one for dsi phy per target (Rob Herring)
- Corrected description for pinctrl-names (Rob Herring)
- Corrected the examples used in yaml file (Rob Herring)
- Delete dsi.txt and dpu.txt (Rob Herring)

Changes in v4:
- Move schema up by one level (Rob Herring)
- Add patternProperties for mdp node (Rob Herring)
- Corrected description of some properties (Rob Herring)

Changes in v5:
- Correct the indentation (Rob Herring)
- Remove unnecessary description from properties (Rob Herring)
- Correct the number of interconnect entries (Rob Herring)
- Add interconnect names for sc7180 (Rob Herring)
- Add description for ports (Rob Herring)
- Remove common properties (Rob Herring)
- Add unevalutatedProperties (Rob Herring)
- Reference existing dsi controller yaml in the common
  dsi controller file (Rob Herring)
- Correct the description of clock names to include only the
  clocks that are required (Rob Herring)
- Remove properties which are already covered under the common
  binding (Rob Herring)
- Add dsi phy supply nodes which are required for sc7180 and
  sdm845 targets (Rob Herring)
- Add type ref for syscon-sfpb (Rob Herring)

Changes in v6:
- Fixed errors during dt_binding_check (Rob Herring)
- Add maxItems for phys and phys-names (Rob Herring)
- Use unevaluatedProperties wherever required (Rob Herring)
- Removed interrupt controller from required properties for
  dsi controller (Rob Herring)
- Add constraints for dsi-phy reg-names based on the compatible
  phy version (Rob Herring)
- Add constraints for dsi-phy supply nodes based on the
  compatible phy version (Rob Herring)

Changes in v7:
- Add default value for qcom,mdss-mdp-transfer-time-us (Rob 
Herring)

- Modify the schema for data-lanes (Rob Herring)
- Split the phy schema into separate schemas based on
  the phy version (Rob Herring)

Changes in v8:
- Resolve merge conflicts with latest dsi.txt file
- Include dp yaml change also in the same series


I'm done reviewing this because I'm tired of repeating myself and 
you're

just throwing crap at the wall and seeing what sticks. Get someone else
working on QCom stuff to review because I'm done until someone I know
and trust reviews it.


---
 .../bindings/display/msm/dpu-sc7180.yaml   | 236 
+++
 .../bindings/display/msm/dpu-sdm845.yaml   | 216 
++

 .../devicetree/bindings/display/msm/dpu.txt| 141 
 .../display/msm/dsi-common-controller.yaml | 249 
+

 .../display/msm/dsi-controller-sc7180.yaml | 120 ++
 .../display/msm/dsi-controller-sdm845.yaml | 120 ++


Once again, what's the difference between dsi-controller-sc7180.yaml 
and

dsi-controller-sdm845.yaml? I don't see one. If there's not a
difference, why do we have msm/dsi-common-controller.yaml? If there is 
a

difference dsi-controller-sc7180.yaml and dsi-controller-sdm845.yaml
should *only* have what's different because
msm/dsi-common-controller.yaml should have everything that is the same.


Rob, The dsi yaml files were split into dsi controller and dsi phy based 
on your comments on patch v2.
As per the comments, I added one common yaml file for controller with 
all the mandatory and optional properties along with their constraints 
and only the required properties for each target is mentioned in the 
target specific dsi-controller yaml file.


Thanks,
Krishna


 .../bindings/display/msm/dsi-phy-10nm.yaml |  62 +
 .../bindings/display/msm/dsi-phy-14nm.yaml |  62 +
 .../bindings/display/msm/dsi-phy-20nm.yaml |  66 ++
 .../bindings/display/msm/dsi-phy-28nm.yaml |  62 +
 .../bindings/display/msm/dsi-phy-sc7180.yaml   |  80 +++
 .../bindings/display/msm/dsi-phy-sdm845.yaml   |  82 +++
 

RE: [PATCH v6 2/3] drm: bridge: Add support for Cadence MHDP DPI/DP bridge

[Yuti Suresh Amonkar]

Hi Laurent, 

> -Original Message-
> From: Laurent Pinchart 
> Sent: Tuesday, August 11, 2020 5:30
> To: Yuti Suresh Amonkar 
> Cc: linux-ker...@vger.kernel.org; dri-devel@lists.freedesktop.org;
> devicet...@vger.kernel.org; robh...@kernel.org; max...@cerno.tech;
> airl...@linux.ie; dan...@ffwll.ch; mark.rutl...@arm.com;
> a.ha...@samsung.com; narmstr...@baylibre.com; jo...@kwiboo.se;
> jernej.skra...@siol.net; prane...@ti.com; jsa...@ti.com;
> tomi.valkei...@ti.com; Milind Parab ; Swapnil
> Kashinath Jakhade 
> Subject: Re: [PATCH v6 2/3] drm: bridge: Add support for Cadence MHDP
> DPI/DP bridge
> 
> EXTERNAL MAIL
> 
> 
> Hi Yuti,
> 
> On Fri, May 01, 2020 at 07:32:58AM +, Yuti Suresh Amonkar wrote:
> > Hi Laurent,
> >
> > Thank you so much for reviewing the patch and providing valuable
> > comments. Apologies for the delayed response. We are working on your
> > review comments and will send the next version of the driver for
> > review soon. Please see the responses to comments inline below.
> 
> Thank you for the answers. I was reviewing v8 and realized there were a
> few things I didn't fully understand related to communication with the
> firmware, so I have a few questions here.
> 
> > On Thursday, March 12, 2020 3:51, Laurent Pinchart wrote:
> > > On Wed, Feb 26, 2020 at 11:22:58AM +0100, Yuti Amonkar wrote:
> > > > This patch adds new DRM driver for Cadence MHDP DPTX IP used on
> J721e SoC.
> > >
> > > s/DRM driver/DRM bridge driver.
> > >
> > > > MHDP DPTX IP is the component that complies with VESA DisplayPort
> (DP) and
> > > > embedded Display Port (eDP) standards. It integrates uCPU running the
> > > > embedded Firmware(FW) interfaced over APB interface.
> > > > Basically, it takes a DPI stream as input and output it encoded in DP
> > >
> > > s/output/outputs/
> > >
> > > > format. Currently, it supports only SST mode.
> > > >
> > > > Signed-off-by: Yuti Amonkar 
> > > > Signed-off-by: Jyri Sarha 
> > > > Signed-off-by: Quentin Schulz 
> > > > Signed-off-by: Swapnil Jakhade 
> > > > Signed-off-by: Tomi Valkeinen 
> > > > ---
> > > >  drivers/gpu/drm/bridge/Kconfig  |   11 +
> > > >  drivers/gpu/drm/bridge/Makefile |2 +
> > > >  drivers/gpu/drm/bridge/cdns-mhdp-core.c | 2196
> +++
> > > >  drivers/gpu/drm/bridge/cdns-mhdp-core.h |  380 
> > > >  4 files changed, 2589 insertions(+)
> > > >  create mode 100644 drivers/gpu/drm/bridge/cdns-mhdp-core.c
> > > >  create mode 100644 drivers/gpu/drm/bridge/cdns-mhdp-core.h
> > > >
> > > > diff --git a/drivers/gpu/drm/bridge/Kconfig
> b/drivers/gpu/drm/bridge/Kconfig
> > > > index 20a439199cb8..3bfabb76f2bb 100644
> > > > --- a/drivers/gpu/drm/bridge/Kconfig
> > > > +++ b/drivers/gpu/drm/bridge/Kconfig
> > > > @@ -27,6 +27,17 @@ config DRM_CDNS_DSI
> > > >   Support Cadence DPI to DSI bridge. This is an internal
> > > >   bridge and is meant to be directly embedded in a SoC.
> > > >
> > > > +config DRM_CDNS_MHDP
> > > > +   tristate "Cadence DPI/DP bridge"
> > > > +   select DRM_KMS_HELPER
> > > > +   select DRM_PANEL_BRIDGE
> > > > +   depends on OF
> > > > +   help
> > > > + Support Cadence DPI to DP bridge. This is an internal
> > > > + bridge and is meant to be directly embedded in a SoC.
> > > > + It takes a DPI stream as input and output it encoded
> > >
> > > s/output/outputs/
> > >
> > > > + in DP format.
> > > > +
> > > >  config DRM_DUMB_VGA_DAC
> > > > tristate "Dumb VGA DAC Bridge support"
> > > > depends on OF
> > > > diff --git a/drivers/gpu/drm/bridge/Makefile
> b/drivers/gpu/drm/bridge/Makefile
> > > > index b0d5c3af0b5a..2e2c5be7c714 100644
> > > > --- a/drivers/gpu/drm/bridge/Makefile
> > > > +++ b/drivers/gpu/drm/bridge/Makefile
> > > > @@ -16,6 +16,8 @@ obj-$(CONFIG_DRM_TOSHIBA_TC358768) +=
> tc358768.o
> > > >  obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
> > > >  obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
> > > >  obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
> > > > +obj-$(CONFIG_DRM_CDNS_MHDP) += cdns-mhdp.o
> > >
> > > Should this be kept alphabetically sorted ?
> > >
> > > > +cdns-mhdp-objs := cdns-mhdp-core.o
> > > >
> > > >  obj-y += analogix/
> > > >  obj-y += synopsys/
> > > > diff --git a/drivers/gpu/drm/bridge/cdns-mhdp-core.c
> b/drivers/gpu/drm/bridge/cdns-mhdp-core.c
> > > > new file mode 100644
> > > > index ..cc642893baa8
> > > > --- /dev/null
> > > > +++ b/drivers/gpu/drm/bridge/cdns-mhdp-core.c
> > > > @@ -0,0 +1,2196 @@
> > > > +// SPDX-License-Identifier: GPL-2.0
> > > > +/*
> > > > + * Cadence MHDP DP bridge driver.
> > > > + *
> > > > + * Copyright: 2019 Cadence Design Systems, Inc.
> > > > + *
> > > > + * Author: Quentin Schulz 
> > > > + */
> > > > +
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > >

[PATCH v2 1/5] drm/bridge_connector: Set default status connected for eDP connectors

[Enric Balletbo i Serra]

In an eDP application, HPD is not required and on most bridge chips
useless. If HPD is not used, we need to set initial status as connected,
otherwise the connector created by the drm_bridge_connector API remains
in an unknown state.

Reviewed-by: Laurent Pinchart 
Acked-by: Sam Ravnborg 
Signed-off-by: Enric Balletbo i Serra 
---

Changes in v2:
- Included the patch `drm/bridge_connector: Set default status connected for 
eDP connectors`

 drivers/gpu/drm/drm_bridge_connector.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/drm_bridge_connector.c 
b/drivers/gpu/drm/drm_bridge_connector.c
index c6994fe673f3..a58cbde59c34 100644
--- a/drivers/gpu/drm/drm_bridge_connector.c
+++ b/drivers/gpu/drm/drm_bridge_connector.c
@@ -187,6 +187,7 @@ drm_bridge_connector_detect(struct drm_connector 
*connector, bool force)
case DRM_MODE_CONNECTOR_DPI:
case DRM_MODE_CONNECTOR_LVDS:
case DRM_MODE_CONNECTOR_DSI:
+   case DRM_MODE_CONNECTOR_eDP:
status = connector_status_connected;
break;
default:
-- 
2.28.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/hisilicon: Removed the dependency on the mmu

[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 
---
 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
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V2 2/2] i2c: i2c-qcom-geni: Add shutdown callback for i2c

[Akash Asthana]

Hi Roja,

On 8/20/2020 4:05 PM, Roja Rani Yarubandi wrote:

If the hardware is still accessing memory after SMMU translation
is disabled (as part of smmu shutdown callback), then the
IOVAs (I/O virtual address) which it was using will go on the bus
as the physical addresses which will result in unknown crashes
like NoC/interconnect errors.

So, implement shutdown callback to i2c driver to unmap DMA mappings
during system "reboot" or "shutdown".

Signed-off-by: Roja Rani Yarubandi 
---
Changes in V2:
  - As per Stephen's comments added seperate function for stop transfer,
fixed minor nitpicks.

  drivers/i2c/busses/i2c-qcom-geni.c | 43 ++
  include/linux/qcom-geni-se.h   |  5 
  2 files changed, 48 insertions(+)

diff --git a/drivers/i2c/busses/i2c-qcom-geni.c 
b/drivers/i2c/busses/i2c-qcom-geni.c
index 1fda5c7c2cfc..d07f2f33bb75 100644
--- a/drivers/i2c/busses/i2c-qcom-geni.c
+++ b/drivers/i2c/busses/i2c-qcom-geni.c
@@ -486,6 +486,28 @@ static int geni_i2c_xfer(struct i2c_adapter *adap,
return ret;
  }
  
+static void geni_i2c_stop_xfer(struct geni_i2c_dev *gi2c)

+{
+   u32 val;
+   struct geni_se *se = >se;
+
+   val = readl_relaxed(gi2c->se.base + SE_DMA_DEBUG_REG0);
+   if (val & DMA_TX_ACTIVE) {
+   geni_i2c_abort_xfer(gi2c);
+   gi2c->cur_wr = 0;
+   if (gi2c->err)
+   geni_i2c_tx_fsm_rst(gi2c);
+   geni_se_tx_dma_unprep(se, gi2c->tx_dma, gi2c->xfer_len);
+   }

should be 'else if', because TX and RX can't happen parallel.

+   if (val & DMA_RX_ACTIVE) {
+   geni_i2c_abort_xfer(gi2c);
+   gi2c->cur_rd = 0;
+   if (gi2c->err)
+   geni_i2c_rx_fsm_rst(gi2c);
+   geni_se_rx_dma_unprep(se, gi2c->rx_dma, gi2c->xfer_len);
+   }
+}
+
  static u32 geni_i2c_func(struct i2c_adapter *adap)
  {
return I2C_FUNC_I2C | (I2C_FUNC_SMBUS_EMUL & ~I2C_FUNC_SMBUS_QUICK);
@@ -617,6 +639,26 @@ static int geni_i2c_remove(struct platform_device *pdev)
return 0;
  }
  
+static void geni_i2c_shutdown(struct platform_device *pdev)

+{
+   int ret;
+   u32 dma;
+   struct geni_i2c_dev *gi2c = platform_get_drvdata(pdev);
+   struct geni_se *se = >se;
+
+   ret = pm_runtime_get_sync(gi2c->se.dev);
+   if (ret < 0) {
+   dev_err(gi2c->se.dev, "Failed to resume device: %d\n", ret);
+   return;
+   }
+
+   dma = readl_relaxed(se->base + SE_GENI_DMA_MODE_EN);


Wrt to current issue context it may be suffice to stop just DMA mode 
transfers but why not stop all mode of active transfer during shutdown 
in a generic way.


Regards,

Akash


+   if (dma)
+   geni_i2c_stop_xfer(gi2c);
+
+   pm_runtime_put_sync_suspend(gi2c->se.dev);
+}
+
  static int __maybe_unused geni_i2c_runtime_suspend(struct device *dev)
  {
int ret;
@@ -677,6 +719,7 @@ MODULE_DEVICE_TABLE(of, geni_i2c_dt_match);
  static struct platform_driver geni_i2c_driver = {
.probe  = geni_i2c_probe,
.remove = geni_i2c_remove,
+   .shutdown = geni_i2c_shutdown,
.driver = {
.name = "geni_i2c",
.pm = _i2c_pm_ops,
diff --git a/include/linux/qcom-geni-se.h b/include/linux/qcom-geni-se.h
index dd464943f717..c3c016496d98 100644
--- a/include/linux/qcom-geni-se.h
+++ b/include/linux/qcom-geni-se.h
@@ -77,6 +77,7 @@ struct geni_se {
  #define SE_DMA_RX_FSM_RST 0xd58
  #define SE_HW_PARAM_0 0xe24
  #define SE_HW_PARAM_1 0xe28
+#define SE_DMA_DEBUG_REG0  0xe40
  
  /* GENI_FORCE_DEFAULT_REG fields */

  #define FORCE_DEFAULT BIT(0)
@@ -207,6 +208,10 @@ struct geni_se {
  #define RX_GENI_CANCEL_IRQBIT(11)
  #define RX_GENI_GP_IRQ_EXTGENMASK(13, 12)
  
+/* SE_DMA_DEBUG_REG0 Register fields */

+#define DMA_TX_ACTIVE  BIT(0)
+#define DMA_RX_ACTIVE  BIT(1)
+
  /* SE_HW_PARAM_0 fields */
  #define TX_FIFO_WIDTH_MSK GENMASK(29, 24)
  #define TX_FIFO_WIDTH_SHFT24


--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,\na 
Linux Foundation Collaborative Project

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel