Re: [PATCH 1/6] drm/i915: export the stolen region as a resource

[Joonas Lahtinen]

+ Ville to comment if the removed code loses some meaningful comments
or not. I already went through the code doing consolidations, about a
year ago, so I may be blind to it.

On Wed, 2017-11-22 at 21:19 +, Matthew Auld wrote:
> We duplicate the stolen discovery code in early-quirks and in i915,
> however if we just export the region as a resource from early-quirks we
> can nuke the duplication.
> 
> Suggested-by: Joonas Lahtinen 
> Suggested-by: Chris Wilson 
> Signed-off-by: Matthew Auld 
> Cc: Joonas Lahtinen 
> Cc: Chris Wilson 
> Cc: Paulo Zanoni 
> Cc: Ingo Molnar 
> Cc: H. Peter Anvin 
> Cc: dri-devel@lists.freedesktop.org
> Cc: x...@kernel.org



> @@ -548,6 +551,9 @@ intel_graphics_stolen(int num, int slot, int func,
>   printk(KERN_INFO "Reserving Intel graphics memory at %pa-%pa\n",
>  , );
>  
> + intel_graphics_stolen_res.start = base;
> + intel_graphics_stolen_res.end = end;

You can take advantage of the newly establisted resource by using %pR
in the printk.

I sent a patch to convert the function signatures to resource_size_t
for a less painful future.

Maybe squash just the early quirks/header change portion of this patch
to that patch, then we can iterate on the i915 changes on a reminder of
the series on top of that. 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103370] `vblank_mode=0 DRI_PRIME=1 glxgears` will introduce GPU lock up on Intel Graphics [8086:5917] + AMD Graphics [1002:6665] (rev c3)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103370

--- Comment #41 from Robert Liu  ---
So far, setting max_sclk to 6 and max_mclk to 8, the system passed a
24hours burn-in test (vblank_mode=0 DRI_PRIME=1 glmark2 --run-forever).

Another issue found is when removing the adapter, the system goes to suspend.
After I wake it up, it continues running the benchmark.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 4.9.62: intermittent flicker after upgrade from 4.9.61

[Greg KH]

On Thu, Nov 23, 2017 at 10:09:25PM +0100, Rainer Fiebig wrote:
> Rainer Fiebig wrote:
> > Maarten Lankhorst wrote:
> >> Op 20-11-17 om 09:51 schreef Rainer Fiebig:
> >>> Jani Nikula wrote:
>  On Sun, 19 Nov 2017, Greg KH  wrote:
> > On Sun, Nov 19, 2017 at 01:44:06PM +0100, Rainer Fiebig wrote:
> >> Greg KH wrote:
> >>> On Sun, Nov 19, 2017 at 12:56:26PM +0100, Rainer Fiebig wrote:
>  Greg KH wrote:
> > On Sat, Nov 18, 2017 at 05:08:20PM +0100, Rainer Fiebig wrote:
> >> Greg KH wrote:
> >>> On Sat, Nov 18, 2017 at 01:47:32PM +0100, Rainer Fiebig wrote:
>  Hi!
> 
>  Hopefully the right addressee.
> 
>  Encountered two bad backports which cause screen-flicker.
>  dmesg shows:
> 
>  ...
>  [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe A FIFO 
>  underrun
>  [drm:ironlake_irq_handler [i915]] *ERROR* PCH transcoder A FIFO 
>  underrun
>  [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe B FIFO 
>  underrun
>  [drm:ironlake_irq_handler [i915]] *ERROR* PCH transcoder B FIFO 
>  underrun
>  ...
> 
>  CPU: Intel Core i3 (Clarkdale/Ironlake)
> 
>  The backports are:
> 
>  - diff --git a/drivers/gpu/drm/i915/intel_pm.c
>  b/drivers/gpu/drm/i915/intel_pm.c
>  index 49de476..277a802 100644
>  - diff --git a/drivers/gpu/drm/i915/intel_drv.h
>  b/drivers/gpu/drm/i915/intel_drv.h
>  index a19ec06..3ce9ba3 100644
> 
>  After reversing them the flicker is gone, no more messages in 
>  dmesg. All
>  else OK so far.
> >>> So which commit was the one that caused the problem?  I will be 
> >>> glad to
> >>> revert it.
> >>>
> >>> thanks,
> >>>
> >>> greg k-h
> >>>
> >>>
> >> I started by reverting the more complex one first ("index
> >> 49de476..277a802100644"). But the kernel wouldn't compile then.
> > What git commit id is that?  I don't see those ids in the 4.9-stable
> > tree.
> >
> >> So I also reverted "index a19ec06..3ce9ba3 100644". After that the
> >> kernel compiled just fine and the problems were gone (still are).
> > Same here, what git commit id was this?
> >
> > thanks,
> >
> > greg k-h
> >
>  OK, no mistake. IIRC, I took the patches (and the IDs) from the
>  changelog for patch-4.9.62. I've attached both, so you can check 
>  yourself.
> 
>  I've also applied a freshly downloaded patch-4.9.62 to a freshly
>  expanded 4.9 and re-compiled. The flicker is there. I haven't yet
>  reverted the two patches but I'm confident that after having done so 
>  the
>  flicker will be gone. If not I'll let you know.
> 
>  As a good news: 4.14 is *not* affected. So to me it seems those two
>  patches are part of sort of a package and can not be backported 
>  alone.
> 
>  So long!
>  Rainer Fiebig
>  diff --git a/drivers/gpu/drm/i915/intel_pm.c 
>  b/drivers/gpu/drm/i915/intel_pm.c
>  index 49de476..277a802 100644
>  --- a/drivers/gpu/drm/i915/intel_pm.c
>  +++ b/drivers/gpu/drm/i915/intel_pm.c
>  @@ -27,6 +27,7 @@
>   
>   #include 
>   #include 
>  +#include 
>   #include "i915_drv.h"
>   #include "intel_drv.h"
>   #include "../../../platform/x86/intel_ips.h"
>  @@ -2017,9 +2018,9 @@ static void ilk_compute_wm_level(const struct 
>  drm_i915_private *dev_priv,
>    const struct intel_crtc *intel_crtc,
>    int level,
>    struct intel_crtc_state *cstate,
>  - struct intel_plane_state *pristate,
>  - struct intel_plane_state *sprstate,
>  - struct intel_plane_state *curstate,
>  + const struct intel_plane_state 
>  *pristate,
>  + const struct intel_plane_state 
>  *sprstate,
>  + const struct intel_plane_state 
>  *curstate,
>    struct intel_wm_level *result)
>   {
>   uint16_t pri_latency = dev_priv->wm.pri_latency[level];
>  @@ -2341,28 +2342,24 @@ static int ilk_compute_pipe_wm(struct 
>  intel_crtc_state *cstate)
>   

[git pull] drm for 4.15 part 2 (updated)

[Dave Airlie]

Hi Linus,

This is an incremental pull on top of yesterdays, it contains all of that,

Summary from first pull:
This is just some bits and pieces for the second half of the merge window,

1. Remove the MSM dt-bindings file Rob managed to push in the previous pull.
2. Add a property/edid quirk to denote HMD devices, I had these
hanging around for a few weeks and Keith had done some work on them,
they are fairly self contained and small, and only affect people using
HTC Vive VR headsets so far.
3. amdgpu, tegra, tilcdc, fsl fixes
4. some imx-drm cleanups I missed, these seemed pretty small, and no
reason to hold off.

Extras:
TTM regression fix for running on bochs vga (Fedora reported)
Some i915 fixes headed for stable
One vc4 fix
One EDID fix
One new uapi fix.

Dave.

The following changes since commit f150891fd9878ef0d9197c4e8451ce67c3bdd014:

  Merge tag 'exynos-drm-next-for-v4.15' of
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into
drm-next (2017-11-14 14:12:43 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-for-v4.15-part2-fixes

for you to fetch changes up to c209101fc1c91a318422733a3721ff6a9ff7899f:

  Merge tag 'drm-misc-fixes-2017-11-20' of
git://anongit.freedesktop.org/drm/drm-misc into drm-next (2017-11-24
11:33:29 +1000)


previous part 2 tag + ttm regression fix, i915,vc4,core,uapi fixes


Alex Deucher (2):
  Revert "drm/radeon: dont switch vt on suspend"
  drm/amdgpu: don't skip attributes when powerplay is enabled

Chris Wilson (2):
  drm/i915: Clear breadcrumb node when cancelling signaling
  drm/i915: Mark the userptr invalidate workqueue as WQ_MEM_RECLAIM

Christian König (2):
  drm/amdgpu: make AMDGPU_VA_RESERVED_SIZE 64bit
  drm/amdgpu: set f_mapping on exported DMA-bufs

Cihangir Akturk (1):
  drm/imx: switch to drm_*_get(), drm_*_put() helpers

Colin Ian King (2):
  drm/amd/powerplay: fix copy-n-paste error on vddci_buf index
  drm/i915/gvt: ensure -ve return value is handled correctly

Dave Airlie (13):
  Merge branch 'drm-next-4.15' of
git://people.freedesktop.org/~agd5f/linux into drm-next
  Merge tag 'drm-fsl-dcu-fixes-for-v4.15' of
http://git.agner.ch/git/linux-drm-fsl-dcu into drm-next
  Merge tag 'drm/tegra/for-4.15-rc1-fixes' of
git://anongit.freedesktop.org/tegra/linux into drm-next
  Merge tag 'imx-drm-next-2017-10-18' of
git://git.pengutronix.de/git/pza/linux into drm-next
  Merge branch 'drm-next-4.15' of
git://people.freedesktop.org/~agd5f/linux into drm-next
  Merge tag 'tilcdc-4.15-fixes' of https://github.com/jsarha/linux
into drm-next
  drm: add connector info/property for non-desktop displays [v2]
  drm/fb: add support for not enabling fbcon on non-desktop displays [v2]
  drm/edid: quirk HTC vive headset as non-desktop. [v2]
  drm/ttm: don't attempt to use hugepages if dma32 requested (v2)
  Merge tag 'drm-misc-next-fixes-2017-11-23' of
git://anongit.freedesktop.org/drm/drm-misc into drm-next
  Merge tag 'drm-intel-next-fixes-2017-11-23' of
git://anongit.freedesktop.org/drm/drm-intel into drm-next
  Merge tag 'drm-misc-fixes-2017-11-20' of
git://anongit.freedesktop.org/drm/drm-misc into drm-next

Emily Deng (1):
  drm/amdgpu: Fix null pointer issue in amdgpu_cs_wait_any_fence

Eric Huang (1):
  drm/amd/powerplay: fix unfreeze level smc message for smu7

Fabio Estevam (1):
  gpu: ipu-v3: ipu-dc: Remove unused 'di' variable

Hans de Goede (2):
  drm/i915: Fix false-positive assert_rpm_wakelock_held in
i915_pmic_bus_access_notifier v2
  drm/i915: Re-register PMIC bus access notifier on runtime resume

Jyri Sarha (1):
  drm/tilcdc: Remove obsolete "ti,tilcdc,slave" dts binding support

Ken Wang (2):
  drm/amdgpu: Remove check which is not valid for certain VBIOS
  drm/amdgpu: Add common golden settings for GFX9

Laurent Pinchart (1):
  drm/fsl-dcu: Don't set connector DPMS property

Lucas Stach (1):
  drm/imx: parallel-display: use correct connector enum

Maarten Lankhorst (1):
  drm/vblank: Pass crtc_id to page_flip_ioctl.

Marco Franchi (1):
  dt-bindings: fsl-imx-drm: Remove incorrect "@di0" usage

Monk Liu (2):
  drm/amdgpu:fix memleak in takedown
  drm/amdgpu:fix memleak

Nicolai Hähnle (1):
  drm/amdgpu/gfx9: implement wave VGPR reading

Rex Zhu (2):
  drm/amd/pp: fix dpm randomly failed on Vega10
  drm/amd/pp: fix typecast error in powerplay.

Rob Clark (1):
  dt-bindings: remove file that was added accidentally

Roger He (2):
  drm/amd/amdgpu: if visible VRAM allocation fail, fall back to
invisible try again
  drm/amd/amdgpu: fix over-bound accessing in amdgpu_cs_wait_any_fence

Stefan Agner (2):
  drm/fsl-dcu: avoid disabling pixel clock twice on suspend
  drm/fsl-dcu: enable IRQ before 

[Bug 103874] The Witcher 3: flickering regression with radeonsi

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103874

Bug ID: 103874
   Summary: The Witcher 3: flickering regression with radeonsi
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: shtetl...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

With latest Mesa master, The Witcher 3 in Wine started performing worse and it
also introduced noticeable flickering (once in a few seconds).

I was able to narrow down this flickering to these commits by Marek:

adab7f16ffd3ea4c52e8d07f40ca6ae4868c3706 2017-11-06 radeonsi: don't map big
VRAM buffers for the first upload directly

4b0dc098b2561c07c59f7dab2813640a25789bf1 2017-11-06 gallium/u_threaded: don't
map big VRAM buffers for the first upload directly

a5d3999c31e2460f690b561b41170bb7bc24fc65 2017-11-06 gallium/u_threaded: clean
up tc_improve_map_buffer_flags and prevent reentry

One commit before them this flickering doesn't occur:

OpenGL renderer string: AMD Radeon (TM) RX 480 Graphics (POLARIS10 / DRM 3.18.0
/ 4.13.0-1-amd64, LLVM 5.0.0)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.4.0-devel
(git-60a9705e00)

And with them, it does:

OpenGL renderer string: AMD Radeon (TM) RX 480 Graphics (POLARIS10 / DRM 3.18.0
/ 4.13.0-1-amd64, LLVM 5.0.0)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.4.0-devel
(git-adab7f16ff)

I'm running The Witcher3 with mesa_glthread and csmt enabled (both). You can
use latest Wine staging to test it.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 8/8] drm/msm/gpu: Add devfreq support for the GPU

[kbuild test robot]

Hi Jordan,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on robclark/msm-next]
[also build test ERROR on next-20171122]
[cannot apply to v4.14]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Jordan-Crouse/msm-gpu-devfreq-support/20171124-022911
base:   git://people.freedesktop.org/~robclark/linux msm-next
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

>> ERROR: "__aeabi_uldivmod" [drivers/gpu/drm/msm/msm.ko] undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

linux-next: manual merge of the drm tree with Linus' tree

[Stephen Rothwell]

Hi all,

FIXME: Add owner of second tree to To:
   Add author(s)/SOB of conflicting commits.

Today's linux-next merge of the drm tree got a conflict in:

  drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c

between commits:

  0290c4ca2536 ("of: overlay: rename identifiers to more reflect what they do")
  24789c5ce5a3 ("of: overlay: detect cases where device tree may become 
corrupt")
  f948d6d8b792 ("of: overlay: avoid race condition between applying multiple 
overlays")

from Linus' tree and commit:

  739acd85ffdb ("drm/tilcdc: Remove obsolete "ti,tilcdc,slave" dts binding 
support")

from the drm tree.

I fixed it up (the latter removed the file, so I did that) and can
carry the fix as necessary. This is now fixed as far as linux-next is
concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging.  You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.

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

Re: [PATCH] drm/msm: add missing MODULE_FIRMWARE declarations

[Rob Clark]

On Thu, Nov 23, 2017 at 2:49 PM, Nicolas Dechesne
 wrote:
> * some a5xx files were missing
> * fixup for an existing typo
>
> Signed-off-by: Nicolas Dechesne 

Thanks

Reviewed-by: Rob Clark 

> ---
>  drivers/gpu/drm/msm/adreno/adreno_device.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c 
> b/drivers/gpu/drm/msm/adreno/adreno_device.c
> index 3c1d23b9ddc3..ef4baa919135 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
> @@ -96,8 +96,13 @@ MODULE_FIRMWARE("qcom/a330_pm4.fw");
>  MODULE_FIRMWARE("qcom/a330_pfp.fw");
>  MODULE_FIRMWARE("qcom/a420_pm4.fw");
>  MODULE_FIRMWARE("qcom/a420_pfp.fw");
> -MODULE_FIRMWARE("qcom/a530_fm4.fw");
> +MODULE_FIRMWARE("qcom/a530_pm4.fw");
>  MODULE_FIRMWARE("qcom/a530_pfp.fw");
> +MODULE_FIRMWARE("qcom/a530v3_gpmu.fw2");
> +MODULE_FIRMWARE("qcom/a530_zap.mdt");
> +MODULE_FIRMWARE("qcom/a530_zap.b00");
> +MODULE_FIRMWARE("qcom/a530_zap.b01");
> +MODULE_FIRMWARE("qcom/a530_zap.b02");
>
>  static inline bool _rev_match(uint8_t entry, uint8_t id)
>  {
> --
> 2.15.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/4] drm/ttm: add page order in page pool

[kbuild test robot]

Hi Roger,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on drm/drm-next]
[also build test ERROR on next-20171122]
[cannot apply to v4.14]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Roger-He/drm-ttm-add-page-order-in-page-pool/20171124-032341
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: tile-allmodconfig (attached as .config)
compiler: tilegx-linux-gcc (GCC) 4.6.2
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=tile 

All errors (new ones prefixed by >>):

   drivers/gpu//drm/ttm/ttm_page_alloc.c: In function 'ttm_page_alloc_init':
>> drivers/gpu//drm/ttm/ttm_page_alloc.c:979:18: error: call to 
>> '__compiletime_assert_979' declared with attribute error: BUILD_BUG failed
   drivers/gpu//drm/ttm/ttm_page_alloc.c:983:20: error: call to 
'__compiletime_assert_983' declared with attribute error: BUILD_BUG failed

vim +/__compiletime_assert_979 +979 drivers/gpu//drm/ttm/ttm_page_alloc.c

   956  
   957  int ttm_page_alloc_init(struct ttm_mem_global *glob, unsigned max_pages)
   958  {
   959  int ret;
   960  
   961  WARN_ON(_manager);
   962  
   963  pr_info("Initializing pool allocator\n");
   964  
   965  _manager = kzalloc(sizeof(*_manager), GFP_KERNEL);
   966  
   967  ttm_page_pool_init_locked(&_manager->wc_pool, GFP_HIGHUSER, 
"wc", 0);
   968  
   969  ttm_page_pool_init_locked(&_manager->uc_pool, GFP_HIGHUSER, 
"uc", 0);
   970  
   971  ttm_page_pool_init_locked(&_manager->wc_pool_dma32,
   972GFP_USER | GFP_DMA32, "wc dma", 0);
   973  
   974  ttm_page_pool_init_locked(&_manager->uc_pool_dma32,
   975GFP_USER | GFP_DMA32, "uc dma", 0);
   976  
   977  ttm_page_pool_init_locked(&_manager->wc_pool_huge,
   978GFP_TRANSHUGE & ~(__GFP_MOVABLE | 
__GFP_COMP),
 > 979"wc huge", HPAGE_PMD_ORDER);
   980  
   981  ttm_page_pool_init_locked(&_manager->uc_pool_huge,
   982GFP_TRANSHUGE & ~(__GFP_MOVABLE | 
__GFP_COMP)
   983, "uc huge", HPAGE_PMD_ORDER);
   984  
   985  _manager->options.max_size = max_pages;
   986  _manager->options.small = SMALL_ALLOCATION;
   987  _manager->options.alloc_size = NUM_PAGES_TO_ALLOC;
   988  
   989  ret = kobject_init_and_add(&_manager->kobj, _pool_kobj_type,
   990 >kobj, "pool");
   991  if (unlikely(ret != 0)) {
   992  kobject_put(&_manager->kobj);
   993  _manager = NULL;
   994  return ret;
   995  }
   996  
   997  ttm_pool_mm_shrink_init(_manager);
   998  
   999  return 0;
  1000  }
  1001  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 8/8] drm/msm/gpu: Add devfreq support for the GPU

[kbuild test robot]

Hi Jordan,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on robclark/msm-next]
[also build test ERROR on next-20171122]
[cannot apply to v4.14]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Jordan-Crouse/msm-gpu-devfreq-support/20171124-022911
base:   git://people.freedesktop.org/~robclark/linux msm-next
config: arm-multi_v7_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/msm/msm_gpu.o: In function `msm_devfreq_get_dev_status':
>> msm_gpu.c:(.text+0x558): undefined reference to `__aeabi_uldivmod'

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/5] drm/ttm: add page order in page pool

[kbuild test robot]

Hi Roger,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm/drm-next]
[also build test WARNING on next-20171122]
[cannot apply to v4.14]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Roger-He/drm-ttm-add-page-order-in-page-pool/20171124-035121
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: i386-randconfig-x008-201747 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/ttm/ttm_page_alloc.c:963:0: warning: "HPAGE_PMD_ORDER" 
>> redefined
#define HPAGE_PMD_ORDER 9

   In file included from include/linux/mm.h:451:0,
from include/linux/highmem.h:7,
from drivers/gpu/drm/ttm/ttm_page_alloc.c:38:
   include/linux/huge_mm.h:78:0: note: this is the location of the previous 
definition
#define HPAGE_PMD_ORDER (HPAGE_PMD_SHIFT-PAGE_SHIFT)

   In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/linux/list.h:4,
from drivers/gpu/drm/ttm/ttm_page_alloc.c:36:
   include/linux/compiler.h:162:4: warning: '__f' is static but declared in 
inline function 'strcpy' which is not static
   __f = { \
   ^
   include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
  ^~
   include/linux/string.h:421:2: note: in expansion of macro 'if'
 if (p_size == (size_t)-1 && q_size == (size_t)-1)
 ^~
   include/linux/compiler.h:162:4: warning: '__f' is static but declared in 
inline function 'kmemdup' which is not static
   __f = { \
   ^
   include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
  ^~
   include/linux/string.h:411:2: note: in expansion of macro 'if'
 if (p_size < size)
 ^~
   include/linux/compiler.h:162:4: warning: '__f' is static but declared in 
inline function 'kmemdup' which is not static
   __f = { \
   ^
   include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
  ^~
   include/linux/string.h:409:2: note: in expansion of macro 'if'
 if (__builtin_constant_p(size) && p_size < size)
 ^~
   include/linux/compiler.h:162:4: warning: '__f' is static but declared in 
inline function 'memchr_inv' which is not static
   __f = { \
   ^
   include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
  ^~
   include/linux/string.h:400:2: note: in expansion of macro 'if'
 if (p_size < size)
 ^~
   include/linux/compiler.h:162:4: warning: '__f' is static but declared in 
inline function 'memchr_inv' which is not static
   __f = { \
   ^
   include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
  ^~
   include/linux/string.h:398:2: note: in expansion of macro 'if'
 if (__builtin_constant_p(size) && p_size < size)
 ^~
   include/linux/compiler.h:162:4: warning: '__f' is static but declared in 
inline function 'memchr' which is not static
   __f = { \
   ^
   include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
  ^~
   include/linux/string.h:389:2: note: in expansion of macro 'if'
 if (p_size < size)
 ^~
   include/linux/compiler.h:162:4: warning: '__f' is static but declared in 
inline function 'memchr' which is not static
   __f = { \
   ^
   include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
  ^~
   include/linux/string.h:387:2: note: in expansion of macro 'if'
 if (__builtin_constant_p(size) && p_size < size)
 ^~
   include/linux/compiler.h:162:4: warning: '__f' is static but declared in 
inline function 'memcmp' which is not static
   __f = { \
   ^
   include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## 

Re: [PATCH libdrm] tests: fix MAKE_RGBA macro for 10bpp modes

[Ilia Mirkin]

On Thu, Nov 23, 2017 at 2:09 PM, Ville Syrjälä
 wrote:
> On Thu, Nov 23, 2017 at 01:59:28PM -0500, Ilia Mirkin wrote:
>> We need to shift the values up, otherwise we'd end up with a negative
>> shift. This works for up-to 16-bit components, which is fine for now.
>
> Shouldn't we actually replicate the high bits in the low bits?

Not entirely sure what you're proposing...

Ideally we wouldn't be lazy and pass e.g. 16-bit values to MAKE_RGBA
which would then shift down as necessary (and even there, you could
end up with off-by-1's maybe?). For e.g. 0xff, that should become
0x3ff but with my code will become 0x3fc. But for other values, it's
less clear what to do with the low bits. I figured it didn't really
matter.

Do you have a concrete proposal?

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

Re: [PATCH] drm/exynos: mixer: avoid Oops in vp_video_buffer()

[kbuild test robot]

Hi Tobias,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on next-20171122]
[cannot apply to drm-exynos/exynos-drm/for-next v4.14 v4.14-rc8 v4.14-rc7 v4.14]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Tobias-Jakobi/drm-exynos-mixer-avoid-Oops-in-vp_video_buffer/20171124-012413
config: arm-exynos_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/exynos/exynos_mixer.c: In function 'vp_video_buffer':
>> drivers/gpu/drm/exynos/exynos_mixer.c:518:16: error: 'res' undeclared (first 
>> use in this function)
  vp_reg_write(res, VP_SRC_HEIGHT, state->src.h / 2);
   ^~~
   drivers/gpu/drm/exynos/exynos_mixer.c:518:16: note: each undeclared 
identifier is reported only once for each function it appears in

vim +/res +518 drivers/gpu/drm/exynos/exynos_mixer.c

   463  
   464  static void vp_video_buffer(struct mixer_context *ctx,
   465  struct exynos_drm_plane *plane)
   466  {
   467  struct exynos_drm_plane_state *state =
   468  
to_exynos_plane_state(plane->base.state);
   469  struct drm_framebuffer *fb = state->base.fb;
   470  unsigned int priority = state->base.normalized_zpos + 1;
   471  unsigned long flags;
   472  dma_addr_t luma_addr[2], chroma_addr[2];
   473  bool is_tiled, is_nv21;
   474  u32 val;
   475  
   476  is_nv21 = (fb->format->format == DRM_FORMAT_NV21);
   477  is_tiled = (fb->modifier == DRM_FORMAT_MOD_SAMSUNG_64_32_TILE);
   478  
   479  luma_addr[0] = exynos_drm_fb_dma_addr(fb, 0);
   480  chroma_addr[0] = exynos_drm_fb_dma_addr(fb, 1);
   481  
   482  if (test_bit(MXR_BIT_INTERLACE, >flags)) {
   483  if (is_tiled) {
   484  luma_addr[1] = luma_addr[0] + 0x40;
   485  chroma_addr[1] = chroma_addr[0] + 0x40;
   486  } else {
   487  luma_addr[1] = luma_addr[0] + fb->pitches[0];
   488  chroma_addr[1] = chroma_addr[0] + 
fb->pitches[1];
   489  }
   490  } else {
   491  luma_addr[1] = 0;
   492  chroma_addr[1] = 0;
   493  }
   494  
   495  spin_lock_irqsave(>reg_slock, flags);
   496  
   497  /* interlace or progressive scan mode */
   498  val = (test_bit(MXR_BIT_INTERLACE, >flags) ? ~0 : 0);
   499  vp_reg_writemask(ctx, VP_MODE, val, VP_MODE_LINE_SKIP);
   500  
   501  /* setup format */
   502  val = (is_nv21 ? VP_MODE_NV21 : VP_MODE_NV12);
   503  val |= (is_tiled ? VP_MODE_MEM_TILED : VP_MODE_MEM_LINEAR);
   504  vp_reg_writemask(ctx, VP_MODE, val, VP_MODE_FMT_MASK);
   505  
   506  /* setting size of input image */
   507  vp_reg_write(ctx, VP_IMG_SIZE_Y, VP_IMG_HSIZE(fb->pitches[0]) |
   508  VP_IMG_VSIZE(fb->height));
   509  /* chroma plane for NV12/NV21 is half the height of the luma 
plane */
   510  vp_reg_write(ctx, VP_IMG_SIZE_C, VP_IMG_HSIZE(fb->pitches[1]) |
   511  VP_IMG_VSIZE(fb->height / 2));
   512  
   513  vp_reg_write(ctx, VP_SRC_WIDTH, state->src.w);
   514  vp_reg_write(ctx, VP_SRC_H_POSITION,
   515  VP_SRC_H_POSITION_VAL(state->src.x));
   516  
   517  if (test_bit(MXR_BIT_INTERLACE, >flags)) {
 > 518  vp_reg_write(res, VP_SRC_HEIGHT, state->src.h / 2);
   519  vp_reg_write(res, VP_SRC_V_POSITION, state->src.y / 2);
   520  } else {
   521  vp_reg_write(res, VP_SRC_HEIGHT, state->src.h);
   522  vp_reg_write(res, VP_SRC_V_POSITION, state->src.y);
   523  }
   524  
   525  vp_reg_write(res, VP_DST_WIDTH, state->crtc.w);
   526  vp_reg_write(res, VP_DST_H_POSITION, state->crtc.x);
   527  vp_reg_write(res, VP_DST_HEIGHT, state->crtc.h);
   528  vp_reg_write(res, VP_DST_V_POSITION, state->crtc.y);
   529  
   530  vp_reg_write(ctx, VP_H_RATIO, state->h_ratio);
   531  vp_reg_write(ctx, VP_V_RATIO, state->v_ratio);
   532  
   533  vp_reg_write(ctx, VP_ENDIAN_MODE, VP_ENDIAN_MODE_LITTLE);
   534  
   535  /* set buffer address to vp */
   536  vp_reg_write(ctx, VP_TOP_Y_PTR, luma_addr[0]);
   537  vp_reg_write(ctx, VP_BOT_Y_PTR, luma_addr[1]);
   538  vp_reg_write(ctx, VP_TOP_C_PTR, 

Re: [PATCH 1/4] drm/ttm: add page order in page pool

[kbuild test robot]

Hi Roger,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on drm/drm-next]
[also build test ERROR on next-20171122]
[cannot apply to v4.14]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Roger-He/drm-ttm-add-page-order-in-page-pool/20171124-032341
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: x86_64-randconfig-x007-201747 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All error/warnings (new ones prefixed by >>):

   In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/linux/list.h:4,
from drivers/gpu/drm/ttm/ttm_page_alloc.c:36:
   drivers/gpu/drm/ttm/ttm_page_alloc.c: In function 'ttm_page_alloc_init':
>> include/linux/compiler.h:576:38: error: call to '__compiletime_assert_979' 
>> declared with attribute error: BUILD_BUG failed
 _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
 ^
   include/linux/compiler.h:556:4: note: in definition of macro 
'__compiletime_assert'
   prefix ## suffix();\
   ^~
   include/linux/compiler.h:576:2: note: in expansion of macro 
'_compiletime_assert'
 _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
 ^~~
   include/linux/build_bug.h:46:37: note: in expansion of macro 
'compiletime_assert'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~
   include/linux/build_bug.h:80:21: note: in expansion of macro 
'BUILD_BUG_ON_MSG'
#define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
^~~~
   include/linux/huge_mm.h:248:28: note: in expansion of macro 'BUILD_BUG'
#define HPAGE_PMD_SHIFT ({ BUILD_BUG(); 0; })
   ^
   include/linux/huge_mm.h:78:26: note: in expansion of macro 'HPAGE_PMD_SHIFT'
#define HPAGE_PMD_ORDER (HPAGE_PMD_SHIFT-PAGE_SHIFT)
 ^~~
>> drivers/gpu/drm/ttm/ttm_page_alloc.c:979:18: note: in expansion of macro 
>> 'HPAGE_PMD_ORDER'
  "wc huge", HPAGE_PMD_ORDER);
 ^~~
   include/linux/compiler.h:576:38: error: call to '__compiletime_assert_983' 
declared with attribute error: BUILD_BUG failed
 _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
 ^
   include/linux/compiler.h:556:4: note: in definition of macro 
'__compiletime_assert'
   prefix ## suffix();\
   ^~
   include/linux/compiler.h:576:2: note: in expansion of macro 
'_compiletime_assert'
 _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
 ^~~
   include/linux/build_bug.h:46:37: note: in expansion of macro 
'compiletime_assert'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~
   include/linux/build_bug.h:80:21: note: in expansion of macro 
'BUILD_BUG_ON_MSG'
#define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
^~~~
   include/linux/huge_mm.h:248:28: note: in expansion of macro 'BUILD_BUG'
#define HPAGE_PMD_SHIFT ({ BUILD_BUG(); 0; })
   ^
   include/linux/huge_mm.h:78:26: note: in expansion of macro 'HPAGE_PMD_SHIFT'
#define HPAGE_PMD_ORDER (HPAGE_PMD_SHIFT-PAGE_SHIFT)
 ^~~
   drivers/gpu/drm/ttm/ttm_page_alloc.c:983:20: note: in expansion of macro 
'HPAGE_PMD_ORDER'
  , "uc huge", HPAGE_PMD_ORDER);
   ^~~
--
   In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/linux/list.h:4,
from drivers/gpu//drm/ttm/ttm_page_alloc.c:36:
   drivers/gpu//drm/ttm/ttm_page_alloc.c: In function 'ttm_page_alloc_init':
>> include/linux/compiler.h:576:38: error: call to '__compiletime_assert_979' 
>> declared with attribute error: BUILD_BUG failed
 _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
 ^
   include/linux/compiler.h:556:4: note: in definition of macro 
'__compiletime_assert'
   prefix ## suffix();\
   

[Bug 103850] "Quern" game crashes on start-up

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103850

--- Comment #5 from yunt...@gmail.com ---
(In reply to Michel Dänzer from comment #2)
> Looks like there might be memory corruption, can you run one of these games
> in valgrind and attach the output from valgrind?

Valgrind output attached. Looks quite useless to me...

Interestingly, Quern actually shows the main menu when run under valgrind.
A duplicate of https://bugs.freedesktop.org/show_bug.cgi?id=101675 then?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/msm: add missing MODULE_FIRMWARE declarations

[Nicolas Dechesne]

* some a5xx files were missing
* fixup for an existing typo

Signed-off-by: Nicolas Dechesne 
---
 drivers/gpu/drm/msm/adreno/adreno_device.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c 
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index 3c1d23b9ddc3..ef4baa919135 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -96,8 +96,13 @@ MODULE_FIRMWARE("qcom/a330_pm4.fw");
 MODULE_FIRMWARE("qcom/a330_pfp.fw");
 MODULE_FIRMWARE("qcom/a420_pm4.fw");
 MODULE_FIRMWARE("qcom/a420_pfp.fw");
-MODULE_FIRMWARE("qcom/a530_fm4.fw");
+MODULE_FIRMWARE("qcom/a530_pm4.fw");
 MODULE_FIRMWARE("qcom/a530_pfp.fw");
+MODULE_FIRMWARE("qcom/a530v3_gpmu.fw2");
+MODULE_FIRMWARE("qcom/a530_zap.mdt");
+MODULE_FIRMWARE("qcom/a530_zap.b00");
+MODULE_FIRMWARE("qcom/a530_zap.b01");
+MODULE_FIRMWARE("qcom/a530_zap.b02");
 
 static inline bool _rev_match(uint8_t entry, uint8_t id)
 {
-- 
2.15.0

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

[Bug 103850] "Quern" game crashes on start-up

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103850

--- Comment #3 from yunt...@gmail.com ---
Created attachment 135687
  --> https://bugs.freedesktop.org/attachment.cgi?id=135687=edit
Quern - valgrind output

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103850] "Quern" game crashes on start-up

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103850

--- Comment #4 from yunt...@gmail.com ---
Created attachment 135688
  --> https://bugs.freedesktop.org/attachment.cgi?id=135688=edit
Unturned - valgrind output

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PULL] drm-misc-next-fixes

[Daniel Vetter]

Hi Dave,

drm-misc-next-fixes-2017-11-23:
Fix crtc_id in page_flip event.

One tiny uapi fix, cc: stable, for a small oversight. Shouldn't matter
much since we added this for atomic, but yay for OCD and making igt happy
:-)

Cheers, Daniel

The following changes since commit f150891fd9878ef0d9197c4e8451ce67c3bdd014:

  Merge tag 'exynos-drm-next-for-v4.15' of 
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next 
(2017-11-14 14:12:43 +1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2017-11-23

for you to fetch changes up to b8a3365a30c463e9105969ab1bf8674b763e3408:

  drm/vblank: Pass crtc_id to page_flip_ioctl. (2017-11-23 13:04:19 +0100)


Fix crtc_id in page_flip event.


Maarten Lankhorst (1):
  drm/vblank: Pass crtc_id to page_flip_ioctl.

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

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103863] Screen doesn't light up with "amdgpu.dc=1"

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103863

Benjamin Bellec  changed:

   What|Removed |Added

 Resolution|--- |WORKSFORME
 Status|NEW |RESOLVED

--- Comment #4 from Benjamin Bellec  ---
I reinstalled Fedora 26 (instead of 27) on my computer, and reinstalled the
kernel 4.15.0-0.rc0.git7.1.fc28.x86_64 on it, and I haven't the error
anymore...

Now I have a display and the HDMI audio on my second screen (TV in fact) is
working.

Also, my F27 computer was on a new Ryzen config, which I finally reverted to
old Core i5 due to global instability.

So I don't know where the problem was...

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[radeon-alex:amd-mainline-dkms-4.13 2023/2065] ci_smc.c:(.text+0xa60): multiple definition of `ci_send_msg_to_smc'

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-mainline-dkms-4.13
head:   59aa856b7672d465443305a3fd7a6956f9567ea6
commit: b3be11d6288525da016bec7d50a11476d6ff1089 [2023/2065] drm/amdgpu: Fix 
for amd_pm_funcs moved to struct amd_powerplay
config: i386-allyesconfig (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
git checkout b3be11d6288525da016bec7d50a11476d6ff1089
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/amd/powerplay/smumgr/ci_smc.o: In function 
`ci_send_msg_to_smc':
>> ci_smc.c:(.text+0xa60): multiple definition of `ci_send_msg_to_smc'
   drivers/gpu/drm/radeon/ci_smc.o:ci_smc.c:(.text+0x320): first defined here

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm] tests: fix MAKE_RGBA macro for 10bpp modes

[Ville Syrjälä]

On Thu, Nov 23, 2017 at 01:59:28PM -0500, Ilia Mirkin wrote:
> We need to shift the values up, otherwise we'd end up with a negative
> shift. This works for up-to 16-bit components, which is fine for now.

Shouldn't we actually replicate the high bits in the low bits?

> 
> Signed-off-by: Ilia Mirkin 
> ---
>  tests/util/pattern.c | 14 ++
>  1 file changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/tests/util/pattern.c b/tests/util/pattern.c
> index 41fb541b..2f9bb384 100644
> --- a/tests/util/pattern.c
> +++ b/tests/util/pattern.c
> @@ -64,11 +64,17 @@ struct color_yuv {
> .u = MAKE_YUV_601_U(r, g, b), \
> .v = MAKE_YUV_601_V(r, g, b) }
>  
> +static inline uint32_t shiftcolor(const struct util_color_component *comp,
> +   uint32_t value)
> +{
> + return ((value << 8) >> (16 - comp->length)) << comp->offset;
> +}
> +
>  #define MAKE_RGBA(rgb, r, g, b, a) \
> - r) >> (8 - (rgb)->red.length)) << (rgb)->red.offset) | \
> -  (((g) >> (8 - (rgb)->green.length)) << (rgb)->green.offset) | \
> -  (((b) >> (8 - (rgb)->blue.length)) << (rgb)->blue.offset) | \
> -  (((a) >> (8 - (rgb)->alpha.length)) << (rgb)->alpha.offset))
> + (shiftcolor(&(rgb)->red, (r)) | \
> +  shiftcolor(&(rgb)->green, (g)) | \
> +  shiftcolor(&(rgb)->blue, (b)) | \
> +  shiftcolor(&(rgb)->alpha, (a)))
>  
>  #define MAKE_RGB24(rgb, r, g, b) \
>   { .value = MAKE_RGBA(rgb, r, g, b, 0) }
> -- 
> 2.13.6
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 15/15] drm: Don't pass clip to drm_atomic_helper_check_plane_state()

[Ville Syrjala]

From: Ville Syrjälä 

Move the plane clip rectangle handling into
drm_atomic_helper_check_plane_state(). Drivers no longer
have to worry about such mundane details.

Cc: Laurent Pinchart 
Cc: Daniel Vetter 
Suggested-by: Daniel Vetter 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/arm/hdlcd_crtc.c|  7 +--
 drivers/gpu/drm/arm/malidp_planes.c |  7 +--
 drivers/gpu/drm/armada/armada_overlay.c |  6 +-
 drivers/gpu/drm/drm_atomic_helper.c | 12 +++-
 drivers/gpu/drm/drm_plane_helper.c  | 11 +++
 drivers/gpu/drm/drm_simple_kms_helper.c |  6 --
 drivers/gpu/drm/i915/intel_display.c| 12 
 drivers/gpu/drm/imx/ipuv3-plane.c   |  7 +--
 drivers/gpu/drm/mediatek/mtk_drm_plane.c|  7 +--
 drivers/gpu/drm/meson/meson_plane.c |  7 +--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   | 14 ++
 drivers/gpu/drm/nouveau/nv50_display.c  | 12 
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  7 +--
 drivers/gpu/drm/tegra/dc.c  |  7 +--
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |  7 +--
 drivers/gpu/drm/zte/zx_plane.c  | 13 +
 include/drm/drm_atomic_helper.h |  1 -
 include/drm/drm_plane_helper.h  |  1 -
 18 files changed, 22 insertions(+), 122 deletions(-)

diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index fa852fc1c9e6..93c503b754ba 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -229,7 +229,6 @@ static const struct drm_crtc_helper_funcs 
hdlcd_crtc_helper_funcs = {
 static int hdlcd_plane_atomic_check(struct drm_plane *plane,
struct drm_plane_state *state)
 {
-   struct drm_rect clip = { 0 };
struct drm_crtc_state *crtc_state;
u32 src_h = state->src_h >> 16;
 
@@ -249,11 +248,7 @@ static int hdlcd_plane_atomic_check(struct drm_plane 
*plane,
return -EINVAL;
}
 
-   if (crtc_state->enable)
-   drm_mode_get_hv_timing(_state->mode,
-  , );
-
-   return drm_atomic_helper_check_plane_state(state, crtc_state, ,
+   return drm_atomic_helper_check_plane_state(state, crtc_state,
   DRM_PLANE_HELPER_NO_SCALING,
   DRM_PLANE_HELPER_NO_SCALING,
   false, true);
diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
b/drivers/gpu/drm/arm/malidp_planes.c
index 2f6d608d6eaf..e630c0218aaf 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -141,18 +141,13 @@ static int malidp_se_check_scaling(struct malidp_plane 
*mp,
struct drm_crtc_state *crtc_state =
drm_atomic_get_existing_crtc_state(state->state, state->crtc);
struct malidp_crtc_state *mc;
-   struct drm_rect clip = { 0 };
u32 src_w, src_h;
int ret;
 
if (!crtc_state)
return -EINVAL;
 
-   if (crtc_state->enable)
-   drm_mode_get_hv_timing(_state->mode,
-  , );
-
-   ret = drm_atomic_helper_check_plane_state(state, crtc_state, ,
+   ret = drm_atomic_helper_check_plane_state(state, crtc_state,
  0, INT_MAX, true, true);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/armada/armada_overlay.c 
b/drivers/gpu/drm/armada/armada_overlay.c
index b411b608821a..564bd63a5f6a 100644
--- a/drivers/gpu/drm/armada/armada_overlay.c
+++ b/drivers/gpu/drm/armada/armada_overlay.c
@@ -111,10 +111,6 @@ armada_ovl_plane_update(struct drm_plane *plane, struct 
drm_crtc *crtc,
.x2 = crtc_x + crtc_w,
.y2 = crtc_y + crtc_h,
};
-   const struct drm_rect clip = {
-   .x2 = crtc->mode.hdisplay,
-   .y2 = crtc->mode.vdisplay,
-   };
uint32_t val, ctrl0;
unsigned idx = 0;
bool visible;
@@ -124,7 +120,7 @@ armada_ovl_plane_update(struct drm_plane *plane, struct 
drm_crtc *crtc,
 crtc_x, crtc_y, crtc_w, crtc_h,
 src_x, src_y, src_w, src_h);
 
-   ret = drm_plane_helper_check_update(plane, crtc, fb, , , ,
+   ret = drm_plane_helper_check_update(plane, crtc, fb, , ,
DRM_MODE_ROTATE_0,
0, INT_MAX, true, false, );
if (ret)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 2f80377101a1..d25eaf6f62a9 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ 

[PATCH 12/15] drm/tegra/dc: Use drm_mode_get_hv_timing() to populate plane clip rectangle

[Ville Syrjala]

From: Ville Syrjälä 

Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.

No functional changes as the code already uses crtc_state->mode
to populate the clip, which is also what drm_mode_get_hv_timing()
uses.

Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().

Cc: Laurent Pinchart 
Cc: Thierry Reding 
Cc: linux-te...@vger.kernel.org
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/tegra/dc.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index fc70351b9017..93b47e0e038b 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -477,7 +477,7 @@ static int tegra_plane_state_add(struct tegra_plane *plane,
 {
struct drm_crtc_state *crtc_state;
struct tegra_dc_state *tegra;
-   struct drm_rect clip;
+   struct drm_rect clip = {};
int err;
 
/* Propagate errors from allocation or locking failures. */
@@ -485,10 +485,9 @@ static int tegra_plane_state_add(struct tegra_plane *plane,
if (IS_ERR(crtc_state))
return PTR_ERR(crtc_state);
 
-   clip.x1 = 0;
-   clip.y1 = 0;
-   clip.x2 = crtc_state->mode.hdisplay;
-   clip.y2 = crtc_state->mode.vdisplay;
+   if (crtc_state->enable)
+   drm_mode_get_hv_timing(_state->mode,
+  , );
 
/* Check plane state for visibility and calculate clipping bounds */
err = drm_atomic_helper_check_plane_state(state, crtc_state, ,
-- 
2.13.6

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

[PATCH 09/15] drm/msm/mdp5: Use drm_mode_get_hv_timing() to populate plane clip rectangle

[Ville Syrjala]

From: Ville Syrjälä 

Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.

Note that this replaces crtc_state->adjusted_mode usage with
crtc_state->mode. The latter is the correct choice since that's the
mode the user provided and it matches the plane crtc coordinates
the user also provided.

Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().

Cc: Laurent Pinchart 
Cc: Rob Clark 
Cc: Archit Taneja 
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index ee41423baeb7..09f758e7bb1b 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -286,7 +286,7 @@ static int mdp5_plane_atomic_check_with_state(struct 
drm_crtc_state *crtc_state,
uint32_t max_width, max_height;
bool out_of_bounds = false;
uint32_t caps = 0;
-   struct drm_rect clip;
+   struct drm_rect clip = {};
int min_scale, max_scale;
int ret;
 
@@ -320,13 +320,13 @@ static int mdp5_plane_atomic_check_with_state(struct 
drm_crtc_state *crtc_state,
return -ERANGE;
}
 
-   clip.x1 = 0;
-   clip.y1 = 0;
-   clip.x2 = crtc_state->adjusted_mode.hdisplay;
-   clip.y2 = crtc_state->adjusted_mode.vdisplay;
min_scale = FRAC_16_16(1, 8);
max_scale = FRAC_16_16(8, 1);
 
+   if (crtc_state->enable)
+   drm_mode_get_hv_timing(_state->mode,
+  , );
+
ret = drm_atomic_helper_check_plane_state(state, crtc_state, ,
  min_scale, max_scale,
  true, true);
@@ -471,7 +471,7 @@ static int mdp5_plane_atomic_async_check(struct drm_plane 
*plane,
 {
struct mdp5_plane_state *mdp5_state = to_mdp5_plane_state(state);
struct drm_crtc_state *crtc_state;
-   struct drm_rect clip;
+   struct drm_rect clip = {};
int min_scale, max_scale;
int ret;
 
@@ -499,13 +499,13 @@ static int mdp5_plane_atomic_async_check(struct drm_plane 
*plane,
plane->state->fb != state->fb)
return -EINVAL;
 
-   clip.x1 = 0;
-   clip.y1 = 0;
-   clip.x2 = crtc_state->adjusted_mode.hdisplay;
-   clip.y2 = crtc_state->adjusted_mode.vdisplay;
min_scale = FRAC_16_16(1, 8);
max_scale = FRAC_16_16(8, 1);
 
+   if (crtc_state->enable)
+   drm_mode_get_hv_timing(_state->mode,
+  , );
+
ret = drm_atomic_helper_check_plane_state(state, crtc_state, ,
  min_scale, max_scale,
  true, true);
-- 
2.13.6

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

[PATCH 13/15] drm/vmwgfx: Use drm_mode_get_hv_timing() to populate plane clip rectangle

[Ville Syrjala]

From: Ville Syrjälä 

Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.

Note that this replaces crtc_state->adjusted_mode usage with
crtc_state->mode. The latter is the correct choice since that's the
mode the user provided and it matches the plane crtc coordinates
the user also provided.

Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().

Cc: Laurent Pinchart 
Cc: VMware Graphics 
Cc: Sinclair Yeh 
Cc: Thomas Hellstrom 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index a2a93d7e2a04..25d96560180b 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -449,10 +449,9 @@ int vmw_du_primary_plane_atomic_check(struct drm_plane 
*plane,
if (state->crtc)
crtc_state = drm_atomic_get_new_crtc_state(state->state, 
state->crtc);
 
-   if (crtc_state && crtc_state->enable) {
-   clip.x2 = crtc_state->adjusted_mode.hdisplay;
-   clip.y2 = crtc_state->adjusted_mode.vdisplay;
-   }
+   if (crtc_state && crtc_state->enable)
+   drm_mode_get_hv_timing(_state->mode,
+  , );
 
ret = drm_atomic_helper_check_plane_state(state, crtc_state, ,
  DRM_PLANE_HELPER_NO_SCALING,
-- 
2.13.6

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

[PATCH 14/15] drm/zte: Use drm_mode_get_hv_timing() to populate plane clip rectangle

[Ville Syrjala]

From: Ville Syrjälä 

Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.

Note that this replaces crtc_state->adjusted_mode usage with
crtc_state->mode. The latter is the correct choice since that's the
mode the user provided and it matches the plane crtc coordinates
the user also provided.

Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().

Cc: Laurent Pinchart 
Cc: Shawn Guo 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/zte/zx_plane.c | 18 --
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/zte/zx_plane.c b/drivers/gpu/drm/zte/zx_plane.c
index 68fd2e2dc78a..8e1f34274e24 100644
--- a/drivers/gpu/drm/zte/zx_plane.c
+++ b/drivers/gpu/drm/zte/zx_plane.c
@@ -55,7 +55,7 @@ static int zx_vl_plane_atomic_check(struct drm_plane *plane,
struct drm_framebuffer *fb = plane_state->fb;
struct drm_crtc *crtc = plane_state->crtc;
struct drm_crtc_state *crtc_state;
-   struct drm_rect clip;
+   struct drm_rect clip = {};
int min_scale = FRAC_16_16(1, 8);
int max_scale = FRAC_16_16(8, 1);
 
@@ -75,10 +75,9 @@ static int zx_vl_plane_atomic_check(struct drm_plane *plane,
if (!plane_state->crtc)
return -EINVAL;
 
-   clip.x1 = 0;
-   clip.y1 = 0;
-   clip.x2 = crtc_state->adjusted_mode.hdisplay;
-   clip.y2 = crtc_state->adjusted_mode.vdisplay;
+   if (crtc_state->enable)
+   drm_mode_get_hv_timing(_state->mode,
+  , );
 
return drm_atomic_helper_check_plane_state(plane_state, crtc_state,
   , min_scale, max_scale,
@@ -292,7 +291,7 @@ static int zx_gl_plane_atomic_check(struct drm_plane *plane,
struct drm_framebuffer *fb = plane_state->fb;
struct drm_crtc *crtc = plane_state->crtc;
struct drm_crtc_state *crtc_state;
-   struct drm_rect clip;
+   struct drm_rect clip = {};
 
if (!crtc || !fb)
return 0;
@@ -310,10 +309,9 @@ static int zx_gl_plane_atomic_check(struct drm_plane 
*plane,
if (!plane_state->crtc)
return -EINVAL;
 
-   clip.x1 = 0;
-   clip.y1 = 0;
-   clip.x2 = crtc_state->adjusted_mode.hdisplay;
-   clip.y2 = crtc_state->adjusted_mode.vdisplay;
+   if (crtc_state->enable)
+   drm_mode_get_hv_timing(_state->mode,
+  , );
 
return drm_atomic_helper_check_plane_state(plane_state, crtc_state,
   ,
-- 
2.13.6

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

[PATCH 11/15] drm/rockchip: Use drm_mode_get_hv_timing() to populate plane clip rectangle

[Ville Syrjala]

From: Ville Syrjälä 

Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.

Note that this replaces crtc_state->adjusted_mode usage with
crtc_state->mode. The latter is the correct choice since that's the
mode the user provided and it matches the plane crtc coordinates
the user also provided.

Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().

Cc: Laurent Pinchart 
Cc: Mark Yao 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index ba7505292b78..cd2c72389629 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -641,7 +641,7 @@ static int vop_plane_atomic_check(struct drm_plane *plane,
struct vop_win *vop_win = to_vop_win(plane);
const struct vop_win_data *win = vop_win->data;
int ret;
-   struct drm_rect clip;
+   struct drm_rect clip = {};
int min_scale = win->phy->scl ? FRAC_16_16(1, 8) :
DRM_PLANE_HELPER_NO_SCALING;
int max_scale = win->phy->scl ? FRAC_16_16(8, 1) :
@@ -654,10 +654,9 @@ static int vop_plane_atomic_check(struct drm_plane *plane,
if (WARN_ON(!crtc_state))
return -EINVAL;
 
-   clip.x1 = 0;
-   clip.y1 = 0;
-   clip.x2 = crtc_state->adjusted_mode.hdisplay;
-   clip.y2 = crtc_state->adjusted_mode.vdisplay;
+   if (crtc_state->enable)
+   drm_mode_get_hv_timing(_state->mode,
+  , );
 
ret = drm_atomic_helper_check_plane_state(state, crtc_state, ,
  min_scale, max_scale,
-- 
2.13.6

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

[PATCH 10/15] drm/nouveau/kms/nv50: Use drm_mode_get_hv_timing() to populate plane clip rectangle

[Ville Syrjala]

From: Ville Syrjälä 

Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.

No functional changes as the code already uses crtc_state->mode
to populate the clip, which is also what drm_mode_get_hv_timing()
uses.

Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().

Cc: Laurent Pinchart 
Cc: Ben Skeggs 
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/nouveau/nv50_display.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nv50_display.c 
b/drivers/gpu/drm/nouveau/nv50_display.c
index 65336948e807..7d8307ec442c 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -228,8 +228,6 @@ struct nv50_wndw_atom {
struct drm_plane_state state;
u8 interval;
 
-   struct drm_rect clip;
-
struct {
u32  handle;
u16  offset:12;
@@ -840,10 +838,6 @@ nv50_wndw_atomic_check_acquire(struct nv50_wndw *wndw,
int ret;
 
NV_ATOMIC(drm, "%s acquire\n", wndw->plane.name);
-   asyw->clip.x1 = 0;
-   asyw->clip.y1 = 0;
-   asyw->clip.x2 = asyh->state.mode.hdisplay;
-   asyw->clip.y2 = asyh->state.mode.vdisplay;
 
asyw->image.w = fb->base.width;
asyw->image.h = fb->base.height;
@@ -1141,10 +1135,15 @@ static int
 nv50_curs_acquire(struct nv50_wndw *wndw, struct nv50_wndw_atom *asyw,
  struct nv50_head_atom *asyh)
 {
+   struct drm_rect clip = {};
int ret;
 
+   if (asyh->state.enable)
+   drm_mode_get_hv_timing(>state.mode,
+  , );
+
ret = drm_atomic_helper_check_plane_state(>state, >state,
- >clip,
+ ,
  DRM_PLANE_HELPER_NO_SCALING,
  DRM_PLANE_HELPER_NO_SCALING,
  true, true);
@@ -1428,13 +1427,18 @@ nv50_base_acquire(struct nv50_wndw *wndw, struct 
nv50_wndw_atom *asyw,
  struct nv50_head_atom *asyh)
 {
const struct drm_framebuffer *fb = asyw->state.fb;
+   struct drm_rect clip = {};
int ret;
 
if (!fb->format->depth)
return -EINVAL;
 
+   if (asyh->state.enable)
+   drm_mode_get_hv_timing(>state.mode,
+  , );
+
ret = drm_atomic_helper_check_plane_state(>state, >state,
- >clip,
+ ,
  DRM_PLANE_HELPER_NO_SCALING,
  DRM_PLANE_HELPER_NO_SCALING,
  false, true);
-- 
2.13.6

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

[PATCH 07/15] drm/mediatek: Use drm_mode_get_hv_timing() to populate plane clip rectangle

[Ville Syrjala]

From: Ville Syrjälä 

Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.

No functional changes as the code already uses crtc_state->mode
to populate the clip, which is also what drm_mode_get_hv_timing()
uses.

Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().

Cc: Laurent Pinchart 
Cc: CK Hu 
Cc: Philipp Zabel 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/mediatek/mtk_drm_plane.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c 
b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
index 5ef898b93d8d..b5c6eec9a584 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
@@ -108,8 +108,9 @@ static int mtk_plane_atomic_check(struct drm_plane *plane,
if (IS_ERR(crtc_state))
return PTR_ERR(crtc_state);
 
-   clip.x2 = crtc_state->mode.hdisplay;
-   clip.y2 = crtc_state->mode.vdisplay;
+   if (crtc_state->enable)
+   drm_mode_get_hv_timing(_state->mode,
+  , );
 
return drm_atomic_helper_check_plane_state(state, crtc_state, ,
   DRM_PLANE_HELPER_NO_SCALING,
-- 
2.13.6

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

[PATCH 08/15] drm/meson: Use drm_mode_get_hv_timing() to populate plane clip rectangle

[Ville Syrjala]

From: Ville Syrjälä 

Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.

No functional changes as the code already uses crtc_state->mode
to populate the clip, which is also what drm_mode_get_hv_timing()
uses.

Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().

Cc: Laurent Pinchart 
Cc: Neil Armstrong 
Cc: linux-amlo...@lists.infradead.org
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/meson/meson_plane.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_plane.c 
b/drivers/gpu/drm/meson/meson_plane.c
index d0a6ac8390f3..3801bee1f9e6 100644
--- a/drivers/gpu/drm/meson/meson_plane.c
+++ b/drivers/gpu/drm/meson/meson_plane.c
@@ -58,8 +58,9 @@ static int meson_plane_atomic_check(struct drm_plane *plane,
if (IS_ERR(crtc_state))
return PTR_ERR(crtc_state);
 
-   clip.x2 = crtc_state->mode.hdisplay;
-   clip.y2 = crtc_state->mode.vdisplay;
+   if (crtc_state->enable)
+   drm_mode_get_hv_timing(_state->mode,
+  , );
 
return drm_atomic_helper_check_plane_state(state, crtc_state, ,
   DRM_PLANE_HELPER_NO_SCALING,
-- 
2.13.6

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

[PATCH 02/15] drm/i915: Use drm_mode_get_hv_timing() to populate plane clip rectangle

[Ville Syrjala]

From: Ville Syrjälä 

Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.
No functional changes since pipe_src_w/h are already filled via
drm_mode_get_hv_timing().

Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().

Cc: Laurent Pinchart 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_atomic_plane.c |  8 
 drivers/gpu/drm/i915/intel_display.c  | 14 --
 drivers/gpu/drm/i915/intel_drv.h  |  1 -
 drivers/gpu/drm/i915/intel_sprite.c   |  8 ++--
 4 files changed, 18 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index 8e6dc159f64d..c7984a80706e 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -129,14 +129,6 @@ int intel_plane_atomic_check_with_state(const struct 
intel_crtc_state *old_crtc_
if (!intel_state->base.crtc && !old_plane_state->base.crtc)
return 0;
 
-   /* Clip all planes to CRTC size, or 0x0 if CRTC is disabled */
-   intel_state->clip.x1 = 0;
-   intel_state->clip.y1 = 0;
-   intel_state->clip.x2 =
-   crtc_state->base.enable ? crtc_state->pipe_src_w : 0;
-   intel_state->clip.y2 =
-   crtc_state->base.enable ? crtc_state->pipe_src_h : 0;
-
if (state->fb && drm_rotation_90_or_270(state->rotation)) {
struct drm_format_name_buf format_name;
 
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 959d21157328..4eeec590b722 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9267,13 +9267,18 @@ static int intel_check_cursor(struct intel_crtc_state 
*crtc_state,
  struct intel_plane_state *plane_state)
 {
const struct drm_framebuffer *fb = plane_state->base.fb;
+   struct drm_rect clip = {};
int src_x, src_y;
u32 offset;
int ret;
 
+   if (crtc_state->base.enable)
+   drm_mode_get_hv_timing(_state->base.mode,
+  , );
+
ret = drm_atomic_helper_check_plane_state(_state->base,
  _state->base,
- _state->clip,
+ ,
  DRM_PLANE_HELPER_NO_SCALING,
  DRM_PLANE_HELPER_NO_SCALING,
  true, true);
@@ -12832,6 +12837,7 @@ intel_check_primary_plane(struct intel_plane *plane,
int min_scale = DRM_PLANE_HELPER_NO_SCALING;
int max_scale = DRM_PLANE_HELPER_NO_SCALING;
bool can_position = false;
+   struct drm_rect clip = {};
int ret;
 
if (INTEL_GEN(dev_priv) >= 9) {
@@ -12843,9 +12849,13 @@ intel_check_primary_plane(struct intel_plane *plane,
can_position = true;
}
 
+   if (crtc_state->base.enable)
+   drm_mode_get_hv_timing(_state->base.mode,
+  , );
+
ret = drm_atomic_helper_check_plane_state(>base,
  _state->base,
- >clip,
+ ,
  min_scale, max_scale,
  can_position, true);
if (ret)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 635a96fcd788..06017de4a29c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -403,7 +403,6 @@ struct intel_atomic_state {
 
 struct intel_plane_state {
struct drm_plane_state base;
-   struct drm_rect clip;
struct i915_vma *vma;
 
struct {
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index dd485f59eb1d..cffa7a8b0f9c 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -864,7 +864,7 @@ intel_check_sprite_plane(struct intel_plane *plane,
uint32_t src_x, src_y, src_w, src_h;
struct drm_rect *src = >base.src;
struct drm_rect *dst = >base.dst;
-   const struct drm_rect *clip = >clip;
+   struct drm_rect clip = {};
int hscale, vscale;
int max_scale, min_scale;
bool can_scale;
@@ -922,7 +922,11 @@ intel_check_sprite_plane(struct intel_plane *plane,
vscale = drm_rect_calc_vscale_relaxed(src, dst, min_scale, max_scale);
BUG_ON(vscale < 0);
 
-   state->base.visible = drm_rect_clip_scaled(src, dst, clip, hscale, 
vscale);
+   if 

[PATCH 06/15] drm/imx: Use drm_mode_get_hv_timing() to populate plane clip rectangle

[Ville Syrjala]

From: Ville Syrjälä 

Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.

Note that this replaces crtc_state->adjusted_mode usage with
crtc_state->mode. The latter is the correct choice since that's the
mode the user provided and it matches the plane crtc coordinates
the user also provided.

Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().

Cc: Laurent Pinchart 
Cc: Philipp Zabel 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/imx/ipuv3-plane.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 5a67daedcf4d..c0662503571b 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -322,7 +322,7 @@ static int ipu_plane_atomic_check(struct drm_plane *plane,
struct drm_framebuffer *old_fb = old_state->fb;
unsigned long eba, ubo, vbo, old_ubo, old_vbo, alpha_eba;
bool can_position = (plane->type == DRM_PLANE_TYPE_OVERLAY);
-   struct drm_rect clip;
+   struct drm_rect clip = {};
int hsub, vsub;
int ret;
 
@@ -338,10 +338,10 @@ static int ipu_plane_atomic_check(struct drm_plane *plane,
if (WARN_ON(!crtc_state))
return -EINVAL;
 
-   clip.x1 = 0;
-   clip.y1 = 0;
-   clip.x2 = crtc_state->adjusted_mode.hdisplay;
-   clip.y2 = crtc_state->adjusted_mode.vdisplay;
+   if (crtc_state->enable)
+   drm_mode_get_hv_timing(_state->mode,
+  , );
+
ret = drm_atomic_helper_check_plane_state(state, crtc_state, ,
  DRM_PLANE_HELPER_NO_SCALING,
  DRM_PLANE_HELPER_NO_SCALING,
-- 
2.13.6

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

[PATCH 04/15] drm/arm/mali-dp: Use drm_mode_get_hv_timing() to populate plane clip rectangle

[Ville Syrjala]

From: Ville Syrjälä 

Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.

Note that this replaces crtc_state->adjusted_mode usage with
crtc_state->mode. The latter is the correct choice since that's the
mode the user provided and it matches the plane crtc coordinates
the user also provided.

Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().

Cc: Laurent Pinchart 
Cc: Liviu Dudau 
Cc: Brian Starkey 
Cc: Mali DP Maintainers 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/arm/malidp_planes.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
b/drivers/gpu/drm/arm/malidp_planes.c
index 72a07950167e..2f6d608d6eaf 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -148,8 +148,10 @@ static int malidp_se_check_scaling(struct malidp_plane *mp,
if (!crtc_state)
return -EINVAL;
 
-   clip.x2 = crtc_state->adjusted_mode.hdisplay;
-   clip.y2 = crtc_state->adjusted_mode.vdisplay;
+   if (crtc_state->enable)
+   drm_mode_get_hv_timing(_state->mode,
+  , );
+
ret = drm_atomic_helper_check_plane_state(state, crtc_state, ,
  0, INT_MAX, true, true);
if (ret)
-- 
2.13.6

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

[PATCH 00/15] drm: More plane clipping polish

[Ville Syrjala]

From: Ville Syrjälä 

This series first unifies all users of drm_atomic_helper_check_plane_state()
to populate the clip rectangle with drm_mode_get_hv_timing(), and once
everything is unified the clip rectangle handling is sucked into
drm_atomic_helper_check_plane_state() away from driver code.

Entire series available here:
git://github.com/vsyrjala/linux.git atomic_plane_helper_clip

Cc: Archit Taneja 
Cc: Ben Skeggs 
Cc: Brian Starkey 
Cc: CK Hu 
Cc: Daniel Vetter 
Cc: freedr...@lists.freedesktop.org
Cc: Laurent Pinchart 
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-...@vger.kernel.org
Cc: linux-te...@vger.kernel.org
Cc: Liviu Dudau 
Cc: Mali DP Maintainers 
Cc: Mark Yao 
Cc: Neil Armstrong 
Cc: Noralf Trønnes 
Cc: nouv...@lists.freedesktop.org
Cc: Philipp Zabel 
Cc: Rob Clark 
Cc: Shawn Guo 
Cc: Sinclair Yeh 
Cc: Thierry Reding 
Cc: Thomas Hellstrom 
Cc: VMware Graphics 

Ville Syrjälä (15):
  drm/i915: Reject odd pipe source width with double wide/dual link
  drm/i915: Use drm_mode_get_hv_timing() to populate plane clip
rectangle
  drm/arm/hdlcd: Use drm_mode_get_hv_timing() to populate plane clip
rectangle
  drm/arm/mali-dp: Use drm_mode_get_hv_timing() to populate plane clip
rectangle
  drm/simple_kms_helper: Use drm_mode_get_hv_timing() to populate plane
clip rectangle
  drm/imx: Use drm_mode_get_hv_timing() to populate plane clip rectangle
  drm/mediatek: Use drm_mode_get_hv_timing() to populate plane clip
rectangle
  drm/meson: Use drm_mode_get_hv_timing() to populate plane clip
rectangle
  drm/msm/mdp5: Use drm_mode_get_hv_timing() to populate plane clip
rectangle
  drm/nouveau/kms/nv50: Use drm_mode_get_hv_timing() to populate plane
clip rectangle
  drm/rockchip: Use drm_mode_get_hv_timing() to populate plane clip
rectangle
  drm/tegra/dc: Use drm_mode_get_hv_timing() to populate plane clip
rectangle
  drm/vmwgfx: Use drm_mode_get_hv_timing() to populate plane clip
rectangle
  drm/zte: Use drm_mode_get_hv_timing() to populate plane clip rectangle
  drm: Don't pass clip to drm_atomic_helper_check_plane_state()

 drivers/gpu/drm/arm/hdlcd_crtc.c|  6 +-
 drivers/gpu/drm/arm/malidp_planes.c |  5 +
 drivers/gpu/drm/armada/armada_overlay.c |  2 +-
 drivers/gpu/drm/drm_atomic_helper.c | 12 +++-
 drivers/gpu/drm/drm_plane_helper.c  | 11 +++
 drivers/gpu/drm/drm_simple_kms_helper.c |  5 -
 drivers/gpu/drm/i915/intel_atomic_plane.c   |  8 
 drivers/gpu/drm/i915/intel_display.c| 12 +++-
 drivers/gpu/drm/i915/intel_drv.h|  1 -
 drivers/gpu/drm/i915/intel_sprite.c |  8 ++--
 drivers/gpu/drm/imx/ipuv3-plane.c   |  7 +--
 drivers/gpu/drm/mediatek/mtk_drm_plane.c|  6 +-
 drivers/gpu/drm/meson/meson_plane.c |  6 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   | 14 ++
 drivers/gpu/drm/nouveau/nv50_display.c  |  8 
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  8 +---
 drivers/gpu/drm/tegra/dc.c  |  8 +---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |  8 +---
 drivers/gpu/drm/zte/zx_plane.c  | 15 +--
 include/drm/drm_atomic_helper.h |  1 -
 include/drm/drm_plane_helper.h  |  1 -
 21 files changed, 35 insertions(+), 117 deletions(-)

-- 
2.13.6

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

[PATCH 05/15] drm/simple_kms_helper: Use drm_mode_get_hv_timing() to populate plane clip rectangle

[Ville Syrjala]

From: Ville Syrjälä 

Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.

Note that this replaces crtc_state->adjusted_mode usage with
crtc_state->mode. The latter is the correct choice since that's the
mode the user provided and it matches the plane crtc coordinates
the user also provided.

Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().

Cc: Laurent Pinchart 
Cc: Noralf Trønnes 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_simple_kms_helper.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
b/drivers/gpu/drm/drm_simple_kms_helper.c
index 9f3b1c94802b..9d3f6b70812c 100644
--- a/drivers/gpu/drm/drm_simple_kms_helper.c
+++ b/drivers/gpu/drm/drm_simple_kms_helper.c
@@ -100,8 +100,9 @@ static int drm_simple_kms_plane_atomic_check(struct 
drm_plane *plane,
if (!crtc_state->enable)
return 0; /* nothing to check when disabling or disabled */
 
-   clip.x2 = crtc_state->adjusted_mode.hdisplay;
-   clip.y2 = crtc_state->adjusted_mode.vdisplay;
+   if (crtc_state->enable)
+   drm_mode_get_hv_timing(_state->mode,
+  , );
 
ret = drm_atomic_helper_check_plane_state(plane_state, crtc_state,
  ,
-- 
2.13.6

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

[PATCH 03/15] drm/arm/hdlcd: Use drm_mode_get_hv_timing() to populate plane clip rectangle

[Ville Syrjala]

From: Ville Syrjälä 

Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.

Note that this replaces crtc_state->adjusted_mode usage with
crtc_state->mode. The latter is the correct choice since that's the
mode the user provided and it matches the plane crtc coordinates
the user also provided.

Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().

Cc: Laurent Pinchart 
Cc: Liviu Dudau 
Cc: Brian Starkey 
Cc: Mali DP Maintainers 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/arm/hdlcd_crtc.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index 63511a3bbf6c..fa852fc1c9e6 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -249,8 +249,9 @@ static int hdlcd_plane_atomic_check(struct drm_plane *plane,
return -EINVAL;
}
 
-   clip.x2 = crtc_state->adjusted_mode.hdisplay;
-   clip.y2 = crtc_state->adjusted_mode.vdisplay;
+   if (crtc_state->enable)
+   drm_mode_get_hv_timing(_state->mode,
+  , );
 
return drm_atomic_helper_check_plane_state(state, crtc_state, ,
   DRM_PLANE_HELPER_NO_SCALING,
-- 
2.13.6

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

[PATCH 01/15] drm/i915: Reject odd pipe source width with double wide/dual link

[Ville Syrjala]

From: Ville Syrjälä 

In order to guarantee that pipe_src_w/h matches the user mode h/vdisplay
we must not adjust pipe_src_w to accommodate double wide/dual link.
Instead just reject the mode outright.

This will allows us to rely on crtc_state->mode for plane clipping.

Cc: Laurent Pinchart 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index d67c7c498b34..959d21157328 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6332,9 +6332,18 @@ static int intel_crtc_compute_config(struct intel_crtc 
*crtc,
 * - LVDS dual channel mode
 * - Double wide pipe
 */
-   if ((intel_crtc_has_type(pipe_config, INTEL_OUTPUT_LVDS) &&
-intel_is_dual_link_lvds(dev)) || pipe_config->double_wide)
-   pipe_config->pipe_src_w &= ~1;
+   if (pipe_config->pipe_src_w & 1) {
+   if (pipe_config->double_wide) {
+   DRM_DEBUG_KMS("Odd pipe source width not supported with 
double wide pipe\n");
+   return -EINVAL;
+   }
+
+   if (intel_crtc_has_type(pipe_config, INTEL_OUTPUT_LVDS) &&
+   intel_is_dual_link_lvds(dev)) {
+   DRM_DEBUG_KMS("Odd pipe source width not supported with 
dual link LVDS\n");
+   return -EINVAL;
+   }
+   }
 
/* Cantiga+ cannot handle modes with a hsync front porch of 0.
 * WaPruneModeWithIncorrectHsyncOffset:ctg,elk,ilk,snb,ivb,vlv,hsw.
-- 
2.13.6

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

[PATCH libdrm] tests: fix MAKE_RGBA macro for 10bpp modes

[Ilia Mirkin]

We need to shift the values up, otherwise we'd end up with a negative
shift. This works for up-to 16-bit components, which is fine for now.

Signed-off-by: Ilia Mirkin 
---
 tests/util/pattern.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/tests/util/pattern.c b/tests/util/pattern.c
index 41fb541b..2f9bb384 100644
--- a/tests/util/pattern.c
+++ b/tests/util/pattern.c
@@ -64,11 +64,17 @@ struct color_yuv {
  .u = MAKE_YUV_601_U(r, g, b), \
  .v = MAKE_YUV_601_V(r, g, b) }
 
+static inline uint32_t shiftcolor(const struct util_color_component *comp,
+ uint32_t value)
+{
+   return ((value << 8) >> (16 - comp->length)) << comp->offset;
+}
+
 #define MAKE_RGBA(rgb, r, g, b, a) \
-   r) >> (8 - (rgb)->red.length)) << (rgb)->red.offset) | \
-(((g) >> (8 - (rgb)->green.length)) << (rgb)->green.offset) | \
-(((b) >> (8 - (rgb)->blue.length)) << (rgb)->blue.offset) | \
-(((a) >> (8 - (rgb)->alpha.length)) << (rgb)->alpha.offset))
+   (shiftcolor(&(rgb)->red, (r)) | \
+shiftcolor(&(rgb)->green, (g)) | \
+shiftcolor(&(rgb)->blue, (b)) | \
+shiftcolor(&(rgb)->alpha, (a)))
 
 #define MAKE_RGB24(rgb, r, g, b) \
{ .value = MAKE_RGBA(rgb, r, g, b, 0) }
-- 
2.13.6

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

[radeon-alex:amd-mainline-dkms-4.13 2016/2065] drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smc.c:579:62: warning: 'tmp' may be used uninitialized in this function

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-mainline-dkms-4.13
head:   59aa856b7672d465443305a3fd7a6956f9567ea6
commit: 9c2014d08693830897cad6bbd359d905825d8a18 [2016/2065] drm/amd/powerplay: 
add CI asics support to smumgr
config: i386-allyesconfig (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
git checkout 9c2014d08693830897cad6bbd359d905825d8a18
# save the attached .config to linux build tree
make ARCH=i386 

Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smc.c: In function 
'ci_init_smc_table':
>> drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smc.c:579:62: warning: 
>> 'tmp' may be used uninitialized in this function [-Wmaybe-uninitialized]
 smu_data->power_tune_table.FuzzyFan_PwmSetDelta = 
CONVERT_FROM_HOST_TO_SMC_US(tmp);

~^~~   
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smc.c:571:11: note: 'tmp' 
was declared here
 uint16_t tmp;
  ^~~

vim +/tmp +579 drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smc.c

   568  
   569  static int ci_populate_fuzzy_fan(struct pp_hwmgr *hwmgr, uint32_t 
fuse_table_offset)
   570  {
   571  uint16_t tmp;
   572  struct ci_smumgr *smu_data = (struct ci_smumgr 
*)(hwmgr->smumgr->backend);
   573  
   574  if 
((hwmgr->thermal_controller.advanceFanControlParameters.usFanOutputSensitivity 
& (1 << 15))
   575  || 0 == 
hwmgr->thermal_controller.advanceFanControlParameters.usFanOutputSensitivity)
   576  tmp = 
hwmgr->thermal_controller.advanceFanControlParameters.usFanOutputSensitivity
   577  = 
hwmgr->thermal_controller.advanceFanControlParameters.usDefaultFanOutputSensitivity;
   578  
 > 579  smu_data->power_tune_table.FuzzyFan_PwmSetDelta = 
 > CONVERT_FROM_HOST_TO_SMC_US(tmp);
   580  
   581  return 0;
   582  }
   583  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103863] Screen doesn't light up with "amdgpu.dc=1"

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103863

--- Comment #3 from Jordan L  ---
Hi Benjamin,

Do you have a full dmesg log?

Also, would you be able to try with a different cable? It looks like a link
training failure.

Thanks

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/msm: update adreno firmware path in MODULE_FIRMWARE

[Rob Clark]

On Thu, Nov 23, 2017 at 10:09 AM, Nicolas Dechesne
 wrote:
> On Thu, Nov 23, 2017 at 3:54 PM, Rob Clark  wrote:
>> On Thu, Nov 23, 2017 at 5:32 AM, Nicolas Dechesne
>>  wrote:
>>> The preferred location for Adreno firmware files is now in qcom/ subfolder,
>>> especially now that we are adding some of them in linux-firmware.
>>>
>>> Reported-by: Ben Hutchings 
>>> Signed-off-by: Nicolas Dechesne 
>>
>> Thanks, I was wondering if we should perhaps list both old and new
>> paths?  I'm not sure, maybe we don't need to care about dracut or
>> initrd generation for the legacy case (since mostly there you are
>> using fastboot).
>
> I've been going back and forth on that too. and i decided to ignore
> the legacy paths... alternatively we could use the legacy paths for
> a3xx and the new path for a5xx since we have links for a3xx files...
> but i thought it was too much noise..
>
>>
>> Also, I noticed we are missing a few a5xx fw files, but perhaps that
>> should be fixed with a separate patch.
>
> as you want. I can include them if you prefer and resend.

I think based on what Ben pointed out, let's not include legacy paths.
But if you could send an additional patch to add the missing a5xx fw
that would be appreciated

BR,
-R


>>
>> Either way,
>>
>> Reviewed-by: Rob Clark 
>>
>>> ---
>>>  drivers/gpu/drm/msm/adreno/adreno_device.c | 16 
>>>  1 file changed, 8 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c 
>>> b/drivers/gpu/drm/msm/adreno/adreno_device.c
>>> index 05022ea2a007..3c1d23b9ddc3 100644
>>> --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
>>> +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
>>> @@ -90,14 +90,14 @@ static const struct adreno_info gpulist[] = {
>>> },
>>>  };
>>>
>>> -MODULE_FIRMWARE("a300_pm4.fw");
>>> -MODULE_FIRMWARE("a300_pfp.fw");
>>> -MODULE_FIRMWARE("a330_pm4.fw");
>>> -MODULE_FIRMWARE("a330_pfp.fw");
>>> -MODULE_FIRMWARE("a420_pm4.fw");
>>> -MODULE_FIRMWARE("a420_pfp.fw");
>>> -MODULE_FIRMWARE("a530_fm4.fw");
>>> -MODULE_FIRMWARE("a530_pfp.fw");
>>> +MODULE_FIRMWARE("qcom/a300_pm4.fw");
>>> +MODULE_FIRMWARE("qcom/a300_pfp.fw");
>>> +MODULE_FIRMWARE("qcom/a330_pm4.fw");
>>> +MODULE_FIRMWARE("qcom/a330_pfp.fw");
>>> +MODULE_FIRMWARE("qcom/a420_pm4.fw");
>>> +MODULE_FIRMWARE("qcom/a420_pfp.fw");
>>> +MODULE_FIRMWARE("qcom/a530_fm4.fw");
>>> +MODULE_FIRMWARE("qcom/a530_pfp.fw");
>>>
>>>  static inline bool _rev_match(uint8_t entry, uint8_t id)
>>>  {
>>> --
>>> 2.15.0
>>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/msm: update adreno firmware path in MODULE_FIRMWARE

[Rob Clark]

On Thu, Nov 23, 2017 at 12:09 PM, Ben Hutchings  wrote:
> On Thu, 2017-11-23 at 16:09 +0100, Nicolas Dechesne wrote:
>> On Thu, Nov 23, 2017 at 3:54 PM, Rob Clark  wrote:
>> > On Thu, Nov 23, 2017 at 5:32 AM, Nicolas Dechesne
>> >  wrote:
>> > > The preferred location for Adreno firmware files is now in qcom/ 
>> > > subfolder,
>> > > especially now that we are adding some of them in linux-firmware.
>> > >
>> > > Reported-by: Ben Hutchings 
>> > > Signed-off-by: Nicolas Dechesne 
>> >
>> > Thanks, I was wondering if we should perhaps list both old and new
>> > paths?  I'm not sure, maybe we don't need to care about dracut or
>> > initrd generation for the legacy case (since mostly there you are
>> > using fastboot).
>>
>> I've been going back and forth on that too. and i decided to ignore
>> the legacy paths... alternatively we could use the legacy paths for
>> a3xx and the new path for a5xx since we have links for a3xx files...
>> but i thought it was too much noise..
>>
>> >
>> > Also, I noticed we are missing a few a5xx fw files, but perhaps that
>> > should be fixed with a separate patch.
>>
>> as you want. I can include them if you prefer and resend.
>
> Whenever I've added MODULE_FIRMWARE information I've listed only the
> first-choice firmware paths.
>
> initramfs-tools will warn when including a module if some of the listed
> firmware is not available, so listing multiple paths for the same
> firmware will likely mean it always warns about one of them.
>

Ok, that sounds like good reason to not to list legacy paths.

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

Re: [PATCH] drm/msm: update adreno firmware path in MODULE_FIRMWARE

[Ben Hutchings]

On Thu, 2017-11-23 at 16:09 +0100, Nicolas Dechesne wrote:
> On Thu, Nov 23, 2017 at 3:54 PM, Rob Clark  wrote:
> > On Thu, Nov 23, 2017 at 5:32 AM, Nicolas Dechesne
> >  wrote:
> > > The preferred location for Adreno firmware files is now in qcom/ 
> > > subfolder,
> > > especially now that we are adding some of them in linux-firmware.
> > > 
> > > Reported-by: Ben Hutchings 
> > > Signed-off-by: Nicolas Dechesne 
> > 
> > Thanks, I was wondering if we should perhaps list both old and new
> > paths?  I'm not sure, maybe we don't need to care about dracut or
> > initrd generation for the legacy case (since mostly there you are
> > using fastboot).
> 
> I've been going back and forth on that too. and i decided to ignore
> the legacy paths... alternatively we could use the legacy paths for
> a3xx and the new path for a5xx since we have links for a3xx files...
> but i thought it was too much noise..
> 
> > 
> > Also, I noticed we are missing a few a5xx fw files, but perhaps that
> > should be fixed with a separate patch.
> 
> as you want. I can include them if you prefer and resend.

Whenever I've added MODULE_FIRMWARE information I've listed only the
first-choice firmware paths.

initramfs-tools will warn when including a module if some of the listed
firmware is not available, so listing multiple paths for the same
firmware will likely mean it always warns about one of them.

Ben.

-- 
Ben Hutchings
When in doubt, use brute force. - Ken Thompson



signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] staging: vboxvideo: adapt to new TTM interface

[Hans de Goede]

Hi,

On 23-11-17 17:14, Christian König wrote:

I missed this driver because it is in the staging area.

Signed-off-by: Christian König 


Thank you, looks good to me.

Can you please re-send this with Greh KH (the staging maintainer)
added in the To: list and my:

Reviewed-by: Hans de Goede 

Added?

Regards,

Hans



---
  drivers/staging/vboxvideo/vbox_ttm.c | 17 ++---
  1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/vboxvideo/vbox_ttm.c 
b/drivers/staging/vboxvideo/vbox_ttm.c
index 4eb410a2a1a8..231c89e0699c 100644
--- a/drivers/staging/vboxvideo/vbox_ttm.c
+++ b/drivers/staging/vboxvideo/vbox_ttm.c
@@ -183,13 +183,6 @@ static void vbox_ttm_io_mem_free(struct ttm_bo_device 
*bdev,
  {
  }
  
-static int vbox_bo_move(struct ttm_buffer_object *bo,

-   bool evict, bool interruptible,
-   bool no_wait_gpu, struct ttm_mem_reg *new_mem)
-{
-   return ttm_bo_move_memcpy(bo, interruptible, no_wait_gpu, new_mem);
-}
-
  static void vbox_ttm_backend_destroy(struct ttm_tt *tt)
  {
ttm_tt_fini(tt);
@@ -237,7 +230,6 @@ static struct ttm_bo_driver vbox_bo_driver = {
.init_mem_type = vbox_bo_init_mem_type,
.eviction_valuable = ttm_bo_eviction_valuable,
.evict_flags = vbox_bo_evict_flags,
-   .move = vbox_bo_move,
.verify_access = vbox_bo_verify_access,
.io_mem_reserve = _ttm_io_mem_reserve,
.io_mem_free = _ttm_io_mem_free,
@@ -374,6 +366,7 @@ static inline u64 vbox_bo_gpu_offset(struct vbox_bo *bo)
  
  int vbox_bo_pin(struct vbox_bo *bo, u32 pl_flag, u64 *gpu_addr)

  {
+   struct ttm_operation_ctx ctx = { false, false };
int i, ret;
  
  	if (bo->pin_count) {

@@ -389,7 +382,7 @@ int vbox_bo_pin(struct vbox_bo *bo, u32 pl_flag, u64 
*gpu_addr)
for (i = 0; i < bo->placement.num_placement; i++)
bo->placements[i].flags |= TTM_PL_FLAG_NO_EVICT;
  
-	ret = ttm_bo_validate(>bo, >placement, false, false);

+   ret = ttm_bo_validate(>bo, >placement, );
if (ret)
return ret;
  
@@ -403,6 +396,7 @@ int vbox_bo_pin(struct vbox_bo *bo, u32 pl_flag, u64 *gpu_addr)
  
  int vbox_bo_unpin(struct vbox_bo *bo)

  {
+   struct ttm_operation_ctx ctx = { false, false };
int i, ret;
  
  	if (!bo->pin_count) {

@@ -416,7 +410,7 @@ int vbox_bo_unpin(struct vbox_bo *bo)
for (i = 0; i < bo->placement.num_placement; i++)
bo->placements[i].flags &= ~TTM_PL_FLAG_NO_EVICT;
  
-	ret = ttm_bo_validate(>bo, >placement, false, false);

+   ret = ttm_bo_validate(>bo, >placement, );
if (ret)
return ret;
  
@@ -430,6 +424,7 @@ int vbox_bo_unpin(struct vbox_bo *bo)

   */
  int vbox_bo_push_sysram(struct vbox_bo *bo)
  {
+   struct ttm_operation_ctx ctx = { false, false };
int i, ret;
  
  	if (!bo->pin_count) {

@@ -448,7 +443,7 @@ int vbox_bo_push_sysram(struct vbox_bo *bo)
for (i = 0; i < bo->placement.num_placement; i++)
bo->placements[i].flags |= TTM_PL_FLAG_NO_EVICT;
  
-	ret = ttm_bo_validate(>bo, >placement, false, false);

+   ret = ttm_bo_validate(>bo, >placement, );
if (ret) {
DRM_ERROR("pushing to VRAM failed\n");
return ret;


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

[PATCH] staging: vboxvideo: adapt to new TTM interface

[Christian König]

I missed this driver because it is in the staging area.

Signed-off-by: Christian König 
---
 drivers/staging/vboxvideo/vbox_ttm.c | 17 ++---
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/vboxvideo/vbox_ttm.c 
b/drivers/staging/vboxvideo/vbox_ttm.c
index 4eb410a2a1a8..231c89e0699c 100644
--- a/drivers/staging/vboxvideo/vbox_ttm.c
+++ b/drivers/staging/vboxvideo/vbox_ttm.c
@@ -183,13 +183,6 @@ static void vbox_ttm_io_mem_free(struct ttm_bo_device 
*bdev,
 {
 }
 
-static int vbox_bo_move(struct ttm_buffer_object *bo,
-   bool evict, bool interruptible,
-   bool no_wait_gpu, struct ttm_mem_reg *new_mem)
-{
-   return ttm_bo_move_memcpy(bo, interruptible, no_wait_gpu, new_mem);
-}
-
 static void vbox_ttm_backend_destroy(struct ttm_tt *tt)
 {
ttm_tt_fini(tt);
@@ -237,7 +230,6 @@ static struct ttm_bo_driver vbox_bo_driver = {
.init_mem_type = vbox_bo_init_mem_type,
.eviction_valuable = ttm_bo_eviction_valuable,
.evict_flags = vbox_bo_evict_flags,
-   .move = vbox_bo_move,
.verify_access = vbox_bo_verify_access,
.io_mem_reserve = _ttm_io_mem_reserve,
.io_mem_free = _ttm_io_mem_free,
@@ -374,6 +366,7 @@ static inline u64 vbox_bo_gpu_offset(struct vbox_bo *bo)
 
 int vbox_bo_pin(struct vbox_bo *bo, u32 pl_flag, u64 *gpu_addr)
 {
+   struct ttm_operation_ctx ctx = { false, false };
int i, ret;
 
if (bo->pin_count) {
@@ -389,7 +382,7 @@ int vbox_bo_pin(struct vbox_bo *bo, u32 pl_flag, u64 
*gpu_addr)
for (i = 0; i < bo->placement.num_placement; i++)
bo->placements[i].flags |= TTM_PL_FLAG_NO_EVICT;
 
-   ret = ttm_bo_validate(>bo, >placement, false, false);
+   ret = ttm_bo_validate(>bo, >placement, );
if (ret)
return ret;
 
@@ -403,6 +396,7 @@ int vbox_bo_pin(struct vbox_bo *bo, u32 pl_flag, u64 
*gpu_addr)
 
 int vbox_bo_unpin(struct vbox_bo *bo)
 {
+   struct ttm_operation_ctx ctx = { false, false };
int i, ret;
 
if (!bo->pin_count) {
@@ -416,7 +410,7 @@ int vbox_bo_unpin(struct vbox_bo *bo)
for (i = 0; i < bo->placement.num_placement; i++)
bo->placements[i].flags &= ~TTM_PL_FLAG_NO_EVICT;
 
-   ret = ttm_bo_validate(>bo, >placement, false, false);
+   ret = ttm_bo_validate(>bo, >placement, );
if (ret)
return ret;
 
@@ -430,6 +424,7 @@ int vbox_bo_unpin(struct vbox_bo *bo)
  */
 int vbox_bo_push_sysram(struct vbox_bo *bo)
 {
+   struct ttm_operation_ctx ctx = { false, false };
int i, ret;
 
if (!bo->pin_count) {
@@ -448,7 +443,7 @@ int vbox_bo_push_sysram(struct vbox_bo *bo)
for (i = 0; i < bo->placement.num_placement; i++)
bo->placements[i].flags |= TTM_PL_FLAG_NO_EVICT;
 
-   ret = ttm_bo_validate(>bo, >placement, false, false);
+   ret = ttm_bo_validate(>bo, >placement, );
if (ret) {
DRM_ERROR("pushing to VRAM failed\n");
return ret;
-- 
2.11.0

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

Re: [PATCH] drm: Introduce RGB 64-bit 16:16:16:16 float format

[Ville Syrjälä]

On Thu, Nov 23, 2017 at 04:56:56PM +0800, Tina Zhang wrote:
> The RGB 64-bit 16:16:16:16 float pixel format is needed by some Apps in
> windows. The float format in each component is 1:5:10 MSb-sign:exponent:
> fraction.
> 
> This patch is to introduce the format to drm, so that the windows guest's
> framebuffer in this kind of format can be recognized and used by linux
> host.
> 
> v14:
> - add some details about the float pixel format. (Daniel)
> - add F suffix to the defined name. (Daniel)
> 
> v12:
> - send to dri-devel at lists.freedesktop.org. (Ville)
> 
> v9:
> - separated from framebuffer decoder patch. (Zhenyu) (Xiaoguang)
> 
> Signed-off-by: Tina Zhang 
> Cc: Ville Syrjälä 
> Cc: Dave Airlie 
> Cc: Daniel Vetter 
> ---
>  include/uapi/drm/drm_fourcc.h | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 3ad838d..391d2e6 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -113,6 +113,10 @@ extern "C" {
>  
>  #define DRM_FORMAT_AYUV  fourcc_code('A', 'Y', 'U', 'V') /* 
> [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
>  
> +/* 64 bpp RGB 16:16:16:16 Floating Point */

As before this is still extremely vague. Stating that each component is
a IEEE-754 half-precision float (binary16) should cover it. Well, assuming
that it really is one.

> +#define DRM_FORMAT_XRGB161616F  fourcc_code('X', 'R', '3', 'F') /* [63:0] 
> x:R:G:B 16:16:16:16 little endian */
> +#define DRM_FORMAT_XBGR161616F  fourcc_code('X', 'B', '3', 'F') /* [63:0] 
> x:B:G:R 16:16:16:16 little endian */

Missing one 16 from that name to be consistent with the non-float stuff.

Also maybe it should be (... '4', 'F')? '3' would seem to imply a 48 bit
pixel.

And of course it's still missing the actual implemntation for any driver.

> +
>  /*
>   * 2 plane RGB + A
>   * index 0 = RGB plane, same format as the corresponding non _A8 format has
> -- 
> 2.7.4

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/msm: update adreno firmware path in MODULE_FIRMWARE

[Nicolas Dechesne]

On Thu, Nov 23, 2017 at 3:54 PM, Rob Clark  wrote:
> On Thu, Nov 23, 2017 at 5:32 AM, Nicolas Dechesne
>  wrote:
>> The preferred location for Adreno firmware files is now in qcom/ subfolder,
>> especially now that we are adding some of them in linux-firmware.
>>
>> Reported-by: Ben Hutchings 
>> Signed-off-by: Nicolas Dechesne 
>
> Thanks, I was wondering if we should perhaps list both old and new
> paths?  I'm not sure, maybe we don't need to care about dracut or
> initrd generation for the legacy case (since mostly there you are
> using fastboot).

I've been going back and forth on that too. and i decided to ignore
the legacy paths... alternatively we could use the legacy paths for
a3xx and the new path for a5xx since we have links for a3xx files...
but i thought it was too much noise..

>
> Also, I noticed we are missing a few a5xx fw files, but perhaps that
> should be fixed with a separate patch.

as you want. I can include them if you prefer and resend.

>
> Either way,
>
> Reviewed-by: Rob Clark 
>
>> ---
>>  drivers/gpu/drm/msm/adreno/adreno_device.c | 16 
>>  1 file changed, 8 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c 
>> b/drivers/gpu/drm/msm/adreno/adreno_device.c
>> index 05022ea2a007..3c1d23b9ddc3 100644
>> --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
>> +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
>> @@ -90,14 +90,14 @@ static const struct adreno_info gpulist[] = {
>> },
>>  };
>>
>> -MODULE_FIRMWARE("a300_pm4.fw");
>> -MODULE_FIRMWARE("a300_pfp.fw");
>> -MODULE_FIRMWARE("a330_pm4.fw");
>> -MODULE_FIRMWARE("a330_pfp.fw");
>> -MODULE_FIRMWARE("a420_pm4.fw");
>> -MODULE_FIRMWARE("a420_pfp.fw");
>> -MODULE_FIRMWARE("a530_fm4.fw");
>> -MODULE_FIRMWARE("a530_pfp.fw");
>> +MODULE_FIRMWARE("qcom/a300_pm4.fw");
>> +MODULE_FIRMWARE("qcom/a300_pfp.fw");
>> +MODULE_FIRMWARE("qcom/a330_pm4.fw");
>> +MODULE_FIRMWARE("qcom/a330_pfp.fw");
>> +MODULE_FIRMWARE("qcom/a420_pm4.fw");
>> +MODULE_FIRMWARE("qcom/a420_pfp.fw");
>> +MODULE_FIRMWARE("qcom/a530_fm4.fw");
>> +MODULE_FIRMWARE("qcom/a530_pfp.fw");
>>
>>  static inline bool _rev_match(uint8_t entry, uint8_t id)
>>  {
>> --
>> 2.15.0
>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/5] drm/panel: Add support for the EDT ETM0700G0BDH6

[Fabio Estevam]

Hi Jan,

On Thu, Nov 23, 2017 at 10:55 AM, Jan Tuerk  wrote:
> The Emerging Display Technology ETM0700G0BDH6 is exactly
> the same display as the ETM0700G0DH6, exept the pixelclock
> polarity. Therefore re-use the ETM0700G0DH6 modes. It is
> used by default on emtrion Avari based development kits.
>
> Signed-off-by: Jan Tuerk 

Please run ./scripts/checkpatch.pl on your patch. Currently it gives:
total: 18 errors, 13 warnings, 39 lines checked

Please fix and resend. Also, you could try git send-email in the next time.

Regards,

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

Re: [PATCH] drm/msm: update adreno firmware path in MODULE_FIRMWARE

[Rob Clark]

On Thu, Nov 23, 2017 at 5:32 AM, Nicolas Dechesne
 wrote:
> The preferred location for Adreno firmware files is now in qcom/ subfolder,
> especially now that we are adding some of them in linux-firmware.
>
> Reported-by: Ben Hutchings 
> Signed-off-by: Nicolas Dechesne 

Thanks, I was wondering if we should perhaps list both old and new
paths?  I'm not sure, maybe we don't need to care about dracut or
initrd generation for the legacy case (since mostly there you are
using fastboot).

Also, I noticed we are missing a few a5xx fw files, but perhaps that
should be fixed with a separate patch.

Either way,

Reviewed-by: Rob Clark 

> ---
>  drivers/gpu/drm/msm/adreno/adreno_device.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c 
> b/drivers/gpu/drm/msm/adreno/adreno_device.c
> index 05022ea2a007..3c1d23b9ddc3 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
> @@ -90,14 +90,14 @@ static const struct adreno_info gpulist[] = {
> },
>  };
>
> -MODULE_FIRMWARE("a300_pm4.fw");
> -MODULE_FIRMWARE("a300_pfp.fw");
> -MODULE_FIRMWARE("a330_pm4.fw");
> -MODULE_FIRMWARE("a330_pfp.fw");
> -MODULE_FIRMWARE("a420_pm4.fw");
> -MODULE_FIRMWARE("a420_pfp.fw");
> -MODULE_FIRMWARE("a530_fm4.fw");
> -MODULE_FIRMWARE("a530_pfp.fw");
> +MODULE_FIRMWARE("qcom/a300_pm4.fw");
> +MODULE_FIRMWARE("qcom/a300_pfp.fw");
> +MODULE_FIRMWARE("qcom/a330_pm4.fw");
> +MODULE_FIRMWARE("qcom/a330_pfp.fw");
> +MODULE_FIRMWARE("qcom/a420_pm4.fw");
> +MODULE_FIRMWARE("qcom/a420_pfp.fw");
> +MODULE_FIRMWARE("qcom/a530_fm4.fw");
> +MODULE_FIRMWARE("qcom/a530_pfp.fw");
>
>  static inline bool _rev_match(uint8_t entry, uint8_t id)
>  {
> --
> 2.15.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm/exynos: mixer: avoid Oops in vp_video_buffer()

[Tobias Jakobi]

If an interlaced video mode is selected, a IOMMU pagefault is
triggered by vp_video_buffer().

Fix the most apparent bugs:
- pitch value for chroma plane
- divide by two of height and vpos

This is more like a band-aid at this point. The VP plane is
still corrupted, but at least there are no more pagefaults.

Signed-off-by: Tobias Jakobi 
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index dc5d79465f9b..a18426379e57 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -485,7 +485,7 @@ static void vp_video_buffer(struct mixer_context *ctx,
chroma_addr[1] = chroma_addr[0] + 0x40;
} else {
luma_addr[1] = luma_addr[0] + fb->pitches[0];
-   chroma_addr[1] = chroma_addr[0] + fb->pitches[0];
+   chroma_addr[1] = chroma_addr[0] + fb->pitches[1];
}
} else {
luma_addr[1] = 0;
@@ -507,25 +507,26 @@ static void vp_video_buffer(struct mixer_context *ctx,
vp_reg_write(ctx, VP_IMG_SIZE_Y, VP_IMG_HSIZE(fb->pitches[0]) |
VP_IMG_VSIZE(fb->height));
/* chroma plane for NV12/NV21 is half the height of the luma plane */
-   vp_reg_write(ctx, VP_IMG_SIZE_C, VP_IMG_HSIZE(fb->pitches[0]) |
+   vp_reg_write(ctx, VP_IMG_SIZE_C, VP_IMG_HSIZE(fb->pitches[1]) |
VP_IMG_VSIZE(fb->height / 2));
 
vp_reg_write(ctx, VP_SRC_WIDTH, state->src.w);
-   vp_reg_write(ctx, VP_SRC_HEIGHT, state->src.h);
vp_reg_write(ctx, VP_SRC_H_POSITION,
VP_SRC_H_POSITION_VAL(state->src.x));
-   vp_reg_write(ctx, VP_SRC_V_POSITION, state->src.y);
 
-   vp_reg_write(ctx, VP_DST_WIDTH, state->crtc.w);
-   vp_reg_write(ctx, VP_DST_H_POSITION, state->crtc.x);
if (test_bit(MXR_BIT_INTERLACE, >flags)) {
-   vp_reg_write(ctx, VP_DST_HEIGHT, state->crtc.h / 2);
-   vp_reg_write(ctx, VP_DST_V_POSITION, state->crtc.y / 2);
+   vp_reg_write(ctx, VP_SRC_HEIGHT, state->src.h / 2);
+   vp_reg_write(ctx, VP_SRC_V_POSITION, state->src.y / 2);
} else {
-   vp_reg_write(ctx, VP_DST_HEIGHT, state->crtc.h);
-   vp_reg_write(ctx, VP_DST_V_POSITION, state->crtc.y);
+   vp_reg_write(ctx, VP_SRC_HEIGHT, state->src.h);
+   vp_reg_write(ctx, VP_SRC_V_POSITION, state->src.y);
}
 
+   vp_reg_write(ctx, VP_DST_WIDTH, state->crtc.w);
+   vp_reg_write(ctx, VP_DST_H_POSITION, state->crtc.x);
+   vp_reg_write(ctx, VP_DST_HEIGHT, state->crtc.h);
+   vp_reg_write(ctx, VP_DST_V_POSITION, state->crtc.y);
+
vp_reg_write(ctx, VP_H_RATIO, state->h_ratio);
vp_reg_write(ctx, VP_V_RATIO, state->v_ratio);
 
-- 
2.13.5

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

Re: [PATCH] drm/exynos: mixer: avoid Oops in vp_video_buffer()

[Tobias Jakobi]

Please disregard this one, need to rebase. v2 in a minute...

- Tobias


Tobias Jakobi wrote:
> If an interlaced video mode is selected, a IOMMU pagefault is
> triggered by vp_video_buffer().
> 
> Fix the most apparent bugs:
> - pitch value for chroma plane
> - divide by two of height and vpos
> 
> This is more like a band-aid at this point. The VP plane is
> still corrupted, but at least there are no more pagefaults.
> 
> Signed-off-by: Tobias Jakobi 
> ---
>  drivers/gpu/drm/exynos/exynos_mixer.c | 21 +++--
>  1 file changed, 11 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index dc5d79465f9b..c382f99e0f5b 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -485,7 +485,7 @@ static void vp_video_buffer(struct mixer_context *ctx,
>   chroma_addr[1] = chroma_addr[0] + 0x40;
>   } else {
>   luma_addr[1] = luma_addr[0] + fb->pitches[0];
> - chroma_addr[1] = chroma_addr[0] + fb->pitches[0];
> + chroma_addr[1] = chroma_addr[0] + fb->pitches[1];
>   }
>   } else {
>   luma_addr[1] = 0;
> @@ -507,25 +507,26 @@ static void vp_video_buffer(struct mixer_context *ctx,
>   vp_reg_write(ctx, VP_IMG_SIZE_Y, VP_IMG_HSIZE(fb->pitches[0]) |
>   VP_IMG_VSIZE(fb->height));
>   /* chroma plane for NV12/NV21 is half the height of the luma plane */
> - vp_reg_write(ctx, VP_IMG_SIZE_C, VP_IMG_HSIZE(fb->pitches[0]) |
> + vp_reg_write(ctx, VP_IMG_SIZE_C, VP_IMG_HSIZE(fb->pitches[1]) |
>   VP_IMG_VSIZE(fb->height / 2));
>  
>   vp_reg_write(ctx, VP_SRC_WIDTH, state->src.w);
> - vp_reg_write(ctx, VP_SRC_HEIGHT, state->src.h);
>   vp_reg_write(ctx, VP_SRC_H_POSITION,
>   VP_SRC_H_POSITION_VAL(state->src.x));
> - vp_reg_write(ctx, VP_SRC_V_POSITION, state->src.y);
>  
> - vp_reg_write(ctx, VP_DST_WIDTH, state->crtc.w);
> - vp_reg_write(ctx, VP_DST_H_POSITION, state->crtc.x);
>   if (test_bit(MXR_BIT_INTERLACE, >flags)) {
> - vp_reg_write(ctx, VP_DST_HEIGHT, state->crtc.h / 2);
> - vp_reg_write(ctx, VP_DST_V_POSITION, state->crtc.y / 2);
> + vp_reg_write(res, VP_SRC_HEIGHT, state->src.h / 2);
> + vp_reg_write(res, VP_SRC_V_POSITION, state->src.y / 2);
>   } else {
> - vp_reg_write(ctx, VP_DST_HEIGHT, state->crtc.h);
> - vp_reg_write(ctx, VP_DST_V_POSITION, state->crtc.y);
> + vp_reg_write(res, VP_SRC_HEIGHT, state->src.h);
> + vp_reg_write(res, VP_SRC_V_POSITION, state->src.y);
>   }
>  
> + vp_reg_write(res, VP_DST_WIDTH, state->crtc.w);
> + vp_reg_write(res, VP_DST_H_POSITION, state->crtc.x);
> + vp_reg_write(res, VP_DST_HEIGHT, state->crtc.h);
> + vp_reg_write(res, VP_DST_V_POSITION, state->crtc.y);
> +
>   vp_reg_write(ctx, VP_H_RATIO, state->h_ratio);
>   vp_reg_write(ctx, VP_V_RATIO, state->v_ratio);
>  
> 

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

[PATCH] drm/exynos: mixer: avoid Oops in vp_video_buffer()

[Tobias Jakobi]

If an interlaced video mode is selected, a IOMMU pagefault is
triggered by vp_video_buffer().

Fix the most apparent bugs:
- pitch value for chroma plane
- divide by two of height and vpos

This is more like a band-aid at this point. The VP plane is
still corrupted, but at least there are no more pagefaults.

Signed-off-by: Tobias Jakobi 
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index dc5d79465f9b..c382f99e0f5b 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -485,7 +485,7 @@ static void vp_video_buffer(struct mixer_context *ctx,
chroma_addr[1] = chroma_addr[0] + 0x40;
} else {
luma_addr[1] = luma_addr[0] + fb->pitches[0];
-   chroma_addr[1] = chroma_addr[0] + fb->pitches[0];
+   chroma_addr[1] = chroma_addr[0] + fb->pitches[1];
}
} else {
luma_addr[1] = 0;
@@ -507,25 +507,26 @@ static void vp_video_buffer(struct mixer_context *ctx,
vp_reg_write(ctx, VP_IMG_SIZE_Y, VP_IMG_HSIZE(fb->pitches[0]) |
VP_IMG_VSIZE(fb->height));
/* chroma plane for NV12/NV21 is half the height of the luma plane */
-   vp_reg_write(ctx, VP_IMG_SIZE_C, VP_IMG_HSIZE(fb->pitches[0]) |
+   vp_reg_write(ctx, VP_IMG_SIZE_C, VP_IMG_HSIZE(fb->pitches[1]) |
VP_IMG_VSIZE(fb->height / 2));
 
vp_reg_write(ctx, VP_SRC_WIDTH, state->src.w);
-   vp_reg_write(ctx, VP_SRC_HEIGHT, state->src.h);
vp_reg_write(ctx, VP_SRC_H_POSITION,
VP_SRC_H_POSITION_VAL(state->src.x));
-   vp_reg_write(ctx, VP_SRC_V_POSITION, state->src.y);
 
-   vp_reg_write(ctx, VP_DST_WIDTH, state->crtc.w);
-   vp_reg_write(ctx, VP_DST_H_POSITION, state->crtc.x);
if (test_bit(MXR_BIT_INTERLACE, >flags)) {
-   vp_reg_write(ctx, VP_DST_HEIGHT, state->crtc.h / 2);
-   vp_reg_write(ctx, VP_DST_V_POSITION, state->crtc.y / 2);
+   vp_reg_write(res, VP_SRC_HEIGHT, state->src.h / 2);
+   vp_reg_write(res, VP_SRC_V_POSITION, state->src.y / 2);
} else {
-   vp_reg_write(ctx, VP_DST_HEIGHT, state->crtc.h);
-   vp_reg_write(ctx, VP_DST_V_POSITION, state->crtc.y);
+   vp_reg_write(res, VP_SRC_HEIGHT, state->src.h);
+   vp_reg_write(res, VP_SRC_V_POSITION, state->src.y);
}
 
+   vp_reg_write(res, VP_DST_WIDTH, state->crtc.w);
+   vp_reg_write(res, VP_DST_H_POSITION, state->crtc.x);
+   vp_reg_write(res, VP_DST_HEIGHT, state->crtc.h);
+   vp_reg_write(res, VP_DST_V_POSITION, state->crtc.y);
+
vp_reg_write(ctx, VP_H_RATIO, state->h_ratio);
vp_reg_write(ctx, VP_V_RATIO, state->v_ratio);
 
-- 
2.13.5

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

[PATCH i-g-t] tests/kms_vblank: Add test to ensure DRM_CAP_CRTC_IN_VBLANK_EVENT works correctly

[Maarten Lankhorst]

This was implemented correctly only on the atomic ioctl before, but
it should really be working on all 3 ioctl's involved, so ensure we
always set crtc_id correctly with a testcase.

Signed-off-by: Maarten Lankhorst 
---
 tests/kms_vblank.c | 60 ++
 1 file changed, 56 insertions(+), 4 deletions(-)

diff --git a/tests/kms_vblank.c b/tests/kms_vblank.c
index 47fd10fb9078..004f0e6104ee 100644
--- a/tests/kms_vblank.c
+++ b/tests/kms_vblank.c
@@ -121,7 +121,6 @@ static void run_test(data_t *data, int fd, void 
(*testfunc)(data_t *, int, int))
igt_display_t *display = >display;
igt_output_t *output;
enum pipe p;
-   unsigned int valid_tests = 0;
 
for_each_pipe_with_valid_output(display, p, output) {
igt_hang_t hang;
@@ -170,11 +169,60 @@ static void run_test(data_t *data, int fd, void 
(*testfunc)(data_t *, int, int))
 
/* cleanup what prepare_crtc() has done */
cleanup_crtc(data, fd, output);
-   valid_tests++;
}
+}
+
+static void crtc_id_subtest(data_t *data, int fd)
+{
+   igt_display_t *display = >display;
+   igt_output_t *output;
+   enum pipe p;
+
+   for_each_pipe_with_valid_output(display, p, output) {
+   struct drm_event_vblank buf;
+   const uint32_t pipe_id_flag = kmstest_get_vbl_flag(p);
+   unsigned crtc_id, expected_crtc_id;
+   uint64_t val;
+   union drm_wait_vblank vbl;
+
+   crtc_id = display->pipes[p].crtc_id;
+   if (drmGetCap(display->drm_fd, DRM_CAP_CRTC_IN_VBLANK_EVENT, 
) == 0)
+   expected_crtc_id = crtc_id;
+   else
+   expected_crtc_id = 0;
+
+   data->pipe = p;
+   prepare_crtc(data, fd, output);
+
+   memset(, 0, sizeof(vbl));
+   vbl.request.type = DRM_VBLANK_RELATIVE | DRM_VBLANK_EVENT;
+   vbl.request.type |= pipe_id_flag;
+   vbl.request.sequence = 1;
+   igt_assert_eq(wait_vblank(fd, ), 0);
+
+   igt_assert_eq(read(fd, , sizeof(buf)), sizeof(buf));
+   igt_assert_eq(buf.crtc_id, expected_crtc_id);
+
+   do_or_die(drmModePageFlip(fd, crtc_id,
+ data->primary_fb.fb_id,
+ DRM_MODE_PAGE_FLIP_EVENT, NULL));
+
+   igt_assert_eq(read(fd, , sizeof(buf)), sizeof(buf));
+   igt_assert_eq(buf.crtc_id, expected_crtc_id);
+
+   if (display->is_atomic) {
+   igt_plane_t *primary = igt_output_get_plane(output, 0);
+
+   igt_plane_set_fb(primary, >primary_fb);
+   igt_display_commit_atomic(display, 
DRM_MODE_PAGE_FLIP_EVENT, NULL);
 
-   igt_require_f(valid_tests,
- "no valid crtc/connector combinations found\n");
+   igt_assert_eq(read(fd, , sizeof(buf)), sizeof(buf));
+   igt_assert_eq(buf.crtc_id, expected_crtc_id);
+   }
+
+   cleanup_crtc(data, fd, output);
+   return;
+   }
 }
 
 static void accuracy(data_t *data, int fd, int nchildren)
@@ -307,8 +355,12 @@ igt_main
fd = drm_open_driver(DRIVER_ANY);
kmstest_set_vt_graphics_mode();
igt_display_init(, fd);
+   igt_display_require_output();
}
 
+   igt_subtest("crtc-id")
+   crtc_id_subtest(, fd);
+
for (f = funcs; f->name; f++) {
for (m = modes; m->name; m++) {
if (m->flags & ~f->valid)
-- 
2.15.0

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

Re: [PATCH v2] drm/exynos: gem: Drop NONCONTIG flag for buffers allocated without IOMMU

[Tobias Jakobi]

Inki Dae wrote:
> 
> 
> 2017년 11월 22일 22:14에 Marek Szyprowski 이(가) 쓴 글:
>> When no IOMMU is available, all GEM buffers allocated by Exynos DRM driver
>> are contiguous, because of the underlying dma_alloc_attrs() function
>> provides only such buffers. In such case it makes no sense to keep
>> BO_NONCONTIG flag for the allocated GEM buffers. This allows to avoid
>> failures for buffer contiguity checks in the subsequent operations on GEM
>> objects.
>>
>> Signed-off-by: Marek Szyprowski 
>> CC: sta...@vger.kernel.org # v4.4+
>> ---
>> This issue is there since commit 0519f9a12d011 ("drm/exynos: add iommu
>> support for exynos drm framework"), but this patch applies cleanly
>> only to v4.4+ kernel releases due changes in the surrounding code.
>>
>> Changelog:
>> v2:
>> - added warning message when buffer flags are updadated (requested by Inki)
>>
>> v1: https://patchwork.kernel.org/patch/10034919/
>> - initial version
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_gem.c | 9 +
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> index 077de014d610..4400efe3974a 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> @@ -247,6 +247,15 @@ struct exynos_drm_gem *exynos_drm_gem_create(struct 
>> drm_device *dev,
>>  if (IS_ERR(exynos_gem))
>>  return exynos_gem;
>>  
>> +if (!is_drm_iommu_supported(dev) && (flags & EXYNOS_BO_NONCONTIG)) {
>> +/*
>> + * when no IOMMU is available, all allocated buffers are
>> + * contiguous anyway, so drop EXYNOS_BO_NONCONTIG flag
>> + */
>> +flags &= ~EXYNOS_BO_NONCONTIG;
>> +DRM_WARN("Non-contiguous allocation is not supported without 
>> IOMMU, falling back to contiguous buffer\n");
> 
> WARNING: line over 80 characters
That warning is bogus. Message strings are not supposed to be split.


> I wil change above a warning like below if you are ok,
>   DRM_WARN("Changed to CONTIG buffer due to no IOMMU support.\n");
I think Marek's message is more descriptive.

- Tobias

> 
> 
> Thanks,
> Inki Dae
> 
>> +}
>> +
>>  /* set memory type and cache attribute from user side. */
>>  exynos_gem->flags = flags;
>>  
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

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

[PATCH] MAINTAINERS: Remove Jani as drm-misc co-maintainer

[Jani Nikula]

I'm juggling too many things, and drm-misc maintenance is one that I
keep dropping on the floor. Admit reality and remove myself as
maintainer. This still leaves us with a nice team of three who are
actually doing the drm-misc work, while I focus on drm-intel.

Cc: Daniel Vetter 
Cc: Gustavo Padovan 
Cc: Sean Paul 
Cc: Dave Airlie 
Signed-off-by: Jani Nikula 
---
 MAINTAINERS | 1 -
 1 file changed, 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 9a9d3fdc55ef..fb8820458a7f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4490,7 +4490,6 @@ F:include/linux/vga*
 
 DRM DRIVERS AND MISC GPU PATCHES
 M: Daniel Vetter 
-M: Jani Nikula 
 M: Gustavo Padovan 
 M: Sean Paul 
 W: https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-misc.html
-- 
2.11.0

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

Re: [PATCH 1/2] drivers/video/hdmi: allow for larger-than-needed vendor IF

[Hans Verkuil]

On 11/21/17 16:27, Ville Syrjälä wrote:
> On Mon, Nov 20, 2017 at 04:02:14PM +0100, Hans Verkuil wrote:
>> On 11/20/2017 03:51 PM, Ville Syrjälä wrote:
>>> On Mon, Nov 20, 2017 at 02:41:28PM +0100, Hans Verkuil wrote:
 From: Hans Verkuil 

 Some devices (Windows Intel driver!) send a Vendor InfoFrame that
 uses a payload length of 0x1b instead of the length of 5 or 6
 that the unpack code expects. The InfoFrame is padded with 0 by
 the source.
>>>
>>> So it doesn't put any 3D_Metadata stuff in there? We don't see to
>>> have code to parse/generate any of that.
>>
>> I can't remember if it puts any 3D stuff in there. Let me know if you
>> want me to check this later this week.
> 
> Would be nice to know.
> 
> I guess we should really add code to parse/generate that stuff too,
> otherwise we're going to be lying when we unpack an infoframe with that
> stuff present.
> 

Hmm, I can't reproduce this anymore. We did observe it but I can't
remember with which hardware or graphics driver version.

Testing with a Windows 10 Intel laptop with recent drivers just showed
either an empty vendor InfoFrame with a 1080p EDID or a vendor InfoFrame
that sets the HDMI VIC to 1 for a 4kp30 EDID.

The length is 5 in both cases.

Testing with a different laptop gave a vendor InfoFrame with HDMI VIC 1 and
a length of 6.

Regards,

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

[PATCH] video: fbdev: remove redundant self assignment of 'height'

[Colin King]

From: Colin Ian King 

The assignment of height to itself is redundant and can be removed.
Detected with Coccinelle.

Signed-off-by: Colin Ian King 
---
 drivers/video/fbdev/vga16fb.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/video/fbdev/vga16fb.c b/drivers/video/fbdev/vga16fb.c
index 5f0690c8fc93..2c6a576ed84c 100644
--- a/drivers/video/fbdev/vga16fb.c
+++ b/drivers/video/fbdev/vga16fb.c
@@ -1055,7 +1055,6 @@ static void vga16fb_copyarea(struct fb_info *info, const 
struct fb_copyarea *are
case FB_TYPE_VGA_PLANES:
if (info->fix.type_aux == FB_AUX_VGA_PLANES_VGA4) {
width = width/8;
-   height = height;
line_ofs = info->fix.line_length - width;
 
setmode(1);
-- 
2.14.1

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

Re: [PATCH] dma-buf: Fix ifnullfree.cocci warnings

[Sumit Semwal]

Hello Vasyl,

On 22 November 2017 at 20:52, Vasyl Gomonovych  wrote:
> NULL check before some freeing functions is not needed.
> drivers/dma-buf/dma-buf.c:1183:2-26: WARNING: NULL check before freeing 
> debugfs_remove_recursive
> Generated by: scripts/coccinelle/free/ifnullfree.cocci

Thank you for your patch; applied to drm-misc-next.
>
> Signed-off-by: Vasyl Gomonovych 
> ---
>  drivers/dma-buf/dma-buf.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 4a038dcf5361..048827b06c03 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -1179,8 +1179,7 @@ static int dma_buf_init_debugfs(void)
>
>  static void dma_buf_uninit_debugfs(void)
>  {
> -   if (dma_buf_debugfs_dir)
> -   debugfs_remove_recursive(dma_buf_debugfs_dir);
> +   debugfs_remove_recursive(dma_buf_debugfs_dir);
>  }
>  #else
>  static inline int dma_buf_init_debugfs(void)
> --
> 1.9.1
>



-- 
Thanks and regards,

Sumit Semwal
Linaro Mobile Group - Kernel Team Lead
Linaro.org │ Open source software for ARM SoCs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/vblank: Pass crtc_id to page_flip_ioctl.

[Maarten Lankhorst]

We added crtc_id to the atomic ioctl, but forgot to add it for vblank
and page flip events. Commit bd386e518056 ("drm: Reorganize
drm_pending_event to support future event types [v2]") added it to
the vblank event, but page flip event was still missing.

Correct this and add a test for making sure we always set crtc_id correctly.

Fixes: bd386e518056 ("drm: Reorganize drm_pending_event to support future event 
types [v2]")
Fixes: 5db06a8a98f5 ("drm: Pass CRTC ID in userspace vblank events")
Cc: Daniel Stone 
Cc: Daniel Vetter 
Cc: Gustavo Padovan 
Cc: Sean Paul 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v4.12+

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_plane.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 19404e34cd59..37a93cdffb4a 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -1030,6 +1030,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
e->event.base.type = DRM_EVENT_FLIP_COMPLETE;
e->event.base.length = sizeof(e->event);
e->event.vbl.user_data = page_flip->user_data;
+   e->event.vbl.crtc_id = crtc->base.id;
ret = drm_event_reserve_init(dev, file_priv, >base, 
>event.base);
if (ret) {
kfree(e);
-- 
2.15.0

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

[PATCH] drm/msm: update adreno firmware path in MODULE_FIRMWARE

[Nicolas Dechesne]

The preferred location for Adreno firmware files is now in qcom/ subfolder,
especially now that we are adding some of them in linux-firmware.

Reported-by: Ben Hutchings 
Signed-off-by: Nicolas Dechesne 
---
 drivers/gpu/drm/msm/adreno/adreno_device.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c 
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index 05022ea2a007..3c1d23b9ddc3 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -90,14 +90,14 @@ static const struct adreno_info gpulist[] = {
},
 };
 
-MODULE_FIRMWARE("a300_pm4.fw");
-MODULE_FIRMWARE("a300_pfp.fw");
-MODULE_FIRMWARE("a330_pm4.fw");
-MODULE_FIRMWARE("a330_pfp.fw");
-MODULE_FIRMWARE("a420_pm4.fw");
-MODULE_FIRMWARE("a420_pfp.fw");
-MODULE_FIRMWARE("a530_fm4.fw");
-MODULE_FIRMWARE("a530_pfp.fw");
+MODULE_FIRMWARE("qcom/a300_pm4.fw");
+MODULE_FIRMWARE("qcom/a300_pfp.fw");
+MODULE_FIRMWARE("qcom/a330_pm4.fw");
+MODULE_FIRMWARE("qcom/a330_pfp.fw");
+MODULE_FIRMWARE("qcom/a420_pm4.fw");
+MODULE_FIRMWARE("qcom/a420_pfp.fw");
+MODULE_FIRMWARE("qcom/a530_fm4.fw");
+MODULE_FIRMWARE("qcom/a530_pfp.fw");
 
 static inline bool _rev_match(uint8_t entry, uint8_t id)
 {
-- 
2.15.0

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

Re: [PATCH 0/5] drm: drm_plane_helper_check_state() related stuff

[Laurent Pinchart]

Hi Ville,

On Monday, 20 November 2017 21:36:46 EET Ville Syrjälä wrote:
> On Mon, Nov 20, 2017 at 09:32:56AM -0800, Sinclair Yeh wrote:
> > On Mon, Nov 20, 2017 at 08:34:50AM +0100, Daniel Vetter wrote:
> >> On Fri, Nov 10, 2017 at 11:42:59PM +0200, Ville Syrjälä wrote:
> >>> On Fri, Nov 10, 2017 at 01:26:47PM -0800, Sinclair Yeh wrote:
> >>> > Sorry this took so long.
> >>> 
> >>> No worries.
> >>> 
>  The vmwgfx part:  Reviewed-by: Sinclair Yeh 
>  
>  I've done some testing and the vmwgfx part looks good.  Has Daniel
>  already taken these or should I put them in my next request?
> >>> 
> >>> You can take them, or I can push them to drm-misc-next. Whatever
> >>> works best for you.
> >>> 
> >>> And I'll want to revisit this topic soonish and move the clip
> >>> handling into the helper as discussed with Daniel. But that can
> >>> wait a bit until we get this round merged somewhere.
> >> 
> >> Because we're still in the merge window I think it's probably best if we
> >> push the entire series in through drm-misc. Tree-coordination in the
> >> merge window is always a bit a pain.
> > 
> > Ok, so I'll leave this series to you then.
> 
> All right. Series pushed to drm-misc-next. Thanks for the reviews.

And I now realize my review comments aren't very useful (apart possibly the 
one about adding a comment to the drm_plane_helper_check_update() function, 
feel free to submit a patch for that if you think it's useful) as the series 
has been merged already :-/ I should really start reading mails in the reverse 
chronological order.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 2/5] drm/vmwgfx: Use drm_plane_helper_check_state()

[Laurent Pinchart]

Hi Ville,

Thank you for the patch.

On Wednesday, 1 November 2017 20:29:17 EET Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Atomic drivers have no reason to use drm_plane_helper_check_update()
> instead of drm_plane_helper_check_state(). So let's switch over.
> 
> Cc: VMware Graphics 
> Cc: Sinclair Yeh 
> Cc: Thomas Hellstrom 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 17 +++--
>  1 file changed, 3 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c index a4b56699679a..515b67783a41
> 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> @@ -442,29 +442,18 @@ int vmw_du_primary_plane_atomic_check(struct drm_plane
> *plane, struct drm_plane_state *state)
>  {
>   struct drm_framebuffer *new_fb = state->fb;
> - bool visible;
> -
> - struct drm_rect src = {
> - .x1 = state->src_x,
> - .y1 = state->src_y,
> - .x2 = state->src_x + state->src_w,
> - .y2 = state->src_y + state->src_h,
> - };
> - struct drm_rect dest = {
> + struct drm_rect clip = {
>   .x1 = state->crtc_x,
>   .y1 = state->crtc_y,
>   .x2 = state->crtc_x + state->crtc_w,
>   .y2 = state->crtc_y + state->crtc_h,
>   };
> - struct drm_rect clip = dest;
>   int ret;
> 
> - ret = drm_plane_helper_check_update(plane, state->crtc, new_fb,
> - , , ,
> - DRM_MODE_ROTATE_0,
> + ret = drm_plane_helper_check_state(state, ,
>   DRM_PLANE_HELPER_NO_SCALING,
>   DRM_PLANE_HELPER_NO_SCALING,
> - false, true, );
> + false, true);
> 
> 
>   if (!ret && new_fb) {


-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 1/5] drm/vmwgfx: Remove bogus crtc coords vs fb size check

[Laurent Pinchart]

Hi Ville,

Thank you for the patch.

On Wednesday, 1 November 2017 20:29:16 EET Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Throw away the bugs crtc coords vs. fb size check. Crtc coords don't
> define the viewport inside the fb, that's a job for the src coords,
> which have been checked by the core already.
> 
> Cc: VMware Graphics 
> Cc: Sinclair Yeh 
> Cc: Thomas Hellstrom 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 6 --
>  1 file changed, 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c index 0545740b3724..a4b56699679a
> 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> @@ -476,12 +476,6 @@ int vmw_du_primary_plane_atomic_check(struct drm_plane
> *plane,
> 
>   vcs = vmw_connector_state_to_vcs(du->connector.state);
> 
> - if ((dest.x2 > new_fb->width ||
> -  dest.y2 > new_fb->height)) {
> - DRM_ERROR("CRTC area outside of framebuffer\n");
> - return -EINVAL;
> - }
> -
>   /* Only one active implicit framebuffer at a time. */
>   mutex_lock(_priv->global_kms_state_mutex);
>   if (vcs->is_implicit && dev_priv->implicit_fb &&


-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 5/5] drm: Move drm_plane_helper_check_state() into drm_atomic_helper.c

[Laurent Pinchart]

Hi Ville,

Thank you for the patch.

On Wednesday, 1 November 2017 20:29:20 EET Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> drm_plane_helper_check_update() isn't a transitional helper, so let's
> rename it to drm_atomic_helper_check_plane_state() and move it into
> drm_atomic_helper.c.
> 
> Cc: Daniel Vetter 
> Suggested-by: Daniel Vetter 
> Signed-off-by: Ville Syrjälä 

I would move this patch before 4/5 to make it easier to revert 4/5 (for the 
reason explaining as a reply to that patch).

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/arm/hdlcd_crtc.c|   8 +--
>  drivers/gpu/drm/arm/malidp_planes.c |   4 +-
>  drivers/gpu/drm/drm_atomic_helper.c |  95 +
>  drivers/gpu/drm/drm_plane_helper.c  | 103 +---
>  drivers/gpu/drm/drm_simple_kms_helper.c |   9 +--
>  drivers/gpu/drm/i915/intel_display.c|  22 +++---
>  drivers/gpu/drm/imx/ipuv3-plane.c   |   8 +--
>  drivers/gpu/drm/mediatek/mtk_drm_plane.c|   8 +--
>  drivers/gpu/drm/meson/meson_plane.c |   8 +--
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   |   5 +-
>  drivers/gpu/drm/nouveau/nv50_display.c  |  20 +++---
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   6 +-
>  drivers/gpu/drm/tegra/dc.c  |   4 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |   8 +--
>  drivers/gpu/drm/zte/zx_plane.c  |  15 ++--
>  include/drm/drm_atomic_helper.h |   7 ++
>  include/drm/drm_plane_helper.h  |   6 --
>  17 files changed, 170 insertions(+), 166 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c
> b/drivers/gpu/drm/arm/hdlcd_crtc.c index 14721723fa8a..63511a3bbf6c 100644
> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> @@ -252,10 +252,10 @@ static int hdlcd_plane_atomic_check(struct drm_plane
> *plane, clip.x2 = crtc_state->adjusted_mode.hdisplay;
>   clip.y2 = crtc_state->adjusted_mode.vdisplay;
> 
> - return drm_plane_helper_check_state(state, crtc_state, ,
> - DRM_PLANE_HELPER_NO_SCALING,
> - DRM_PLANE_HELPER_NO_SCALING,
> - false, true);
> + return drm_atomic_helper_check_plane_state(state, crtc_state, ,
> +DRM_PLANE_HELPER_NO_SCALING,
> +DRM_PLANE_HELPER_NO_SCALING,
> +false, true);
>  }
> 
>  static void hdlcd_plane_atomic_update(struct drm_plane *plane,
> diff --git a/drivers/gpu/drm/arm/malidp_planes.c
> b/drivers/gpu/drm/arm/malidp_planes.c index 492d99dd55d4..72a07950167e
> 100644
> --- a/drivers/gpu/drm/arm/malidp_planes.c
> +++ b/drivers/gpu/drm/arm/malidp_planes.c
> @@ -150,8 +150,8 @@ static int malidp_se_check_scaling(struct malidp_plane
> *mp,
> 
>   clip.x2 = crtc_state->adjusted_mode.hdisplay;
>   clip.y2 = crtc_state->adjusted_mode.vdisplay;
> - ret = drm_plane_helper_check_state(state, crtc_state, ,
> -0, INT_MAX, true, true);
> + ret = drm_atomic_helper_check_plane_state(state, crtc_state, ,
> +   0, INT_MAX, true, true);
>   if (ret)
>   return ret;
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c index 71d712f1b56a..7595ad8ad2f3
> 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -696,6 +696,101 @@ drm_atomic_helper_check_modeset(struct drm_device
> *dev, EXPORT_SYMBOL(drm_atomic_helper_check_modeset);
> 
>  /**
> + * drm_atomic_helper_check_plane_state() - Check plane state for validity
> + * @plane_state: plane state to check
> + * @crtc_state: crtc state to check
> + * @clip: integer clipping coordinates
> + * @min_scale: minimum @src:@dest scaling factor in 16.16 fixed point
> + * @max_scale: maximum @src:@dest scaling factor in 16.16 fixed point
> + * @can_position: is it legal to position the plane such that it
> + *doesn't cover the entire crtc?  This will generally
> + *only be false for primary planes.
> + * @can_update_disabled: can the plane be updated while the crtc
> + *   is disabled?
> + *
> + * Checks that a desired plane update is valid, and updates various
> + * bits of derived state (clipped coordinates etc.). Drivers that provide
> + * their own plane handling rather than helper-provided implementations may
> + * still wish to call this function to avoid duplication of error checking
> + * code.
> + *
> + * RETURNS:
> + * Zero if update appears valid, error code on failure
> + */
> +int drm_atomic_helper_check_plane_state(struct 

Re: [PATCH 4/5] drm: Check crtc_state->enable rather than crtc->enabled in drm_plane_helper_check_state()

[Laurent Pinchart]

Hi Ville,

Thank you for the patch.

On Wednesday, 1 November 2017 20:29:19 EET Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> drm_plane_helper_check_state() is supposed to do things the atomic way,
> so it should not be inspecting crtc->enabled. Rather we should be
> looking at crtc_state->enable.
> 
> We have a slight complication due to drm_plane_helper_check_update()
> reusing drm_plane_helper_check_state() for non-atomic drivers. Thus
> we'll have to pass the crtc_state in manally and construct a fake
> crtc_state in drm_plane_helper_check_update().

The only user of drm_plane_helper_check_update() apart from vmwgfx which you 
converted in patch 2/5 is the armada driver. It would be nice to convert it to 
atomic modesetting and drop this function :-) At the very least, I'd add a 
comment to drm_plane_helper_check_update() that this change should be reverted 
when the function is dropped, otherwise we'll carry the CRTC state argument 
for a long time without realizing it's not needed anymore.

Apart from that,

Reviewed-by: Laurent Pinchart 

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/arm/hdlcd_crtc.c|  2 +-
>  drivers/gpu/drm/arm/malidp_planes.c |  3 +-
>  drivers/gpu/drm/drm_plane_helper.c  | 52 ++
>  drivers/gpu/drm/drm_simple_kms_helper.c |  2 +-
>  drivers/gpu/drm/i915/intel_display.c|  2 ++
>  drivers/gpu/drm/imx/ipuv3-plane.c   |  2 +-
>  drivers/gpu/drm/mediatek/mtk_drm_plane.c|  2 +-
>  drivers/gpu/drm/meson/meson_plane.c |  2 +-
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   |  4 +--
>  drivers/gpu/drm/nouveau/nv50_display.c  |  6 ++--
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  2 +-
>  drivers/gpu/drm/tegra/dc.c  |  4 +--
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |  2 +-
>  drivers/gpu/drm/zte/zx_plane.c  |  4 +--
>  include/drm/drm_plane_helper.h  |  3 +-
>  15 files changed, 53 insertions(+), 39 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c
> b/drivers/gpu/drm/arm/hdlcd_crtc.c index 72b22b805412..14721723fa8a 100644
> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> @@ -252,7 +252,7 @@ static int hdlcd_plane_atomic_check(struct drm_plane
> *plane, clip.x2 = crtc_state->adjusted_mode.hdisplay;
>   clip.y2 = crtc_state->adjusted_mode.vdisplay;
> 
> - return drm_plane_helper_check_state(state, ,
> + return drm_plane_helper_check_state(state, crtc_state, ,
>   DRM_PLANE_HELPER_NO_SCALING,
>   DRM_PLANE_HELPER_NO_SCALING,
>   false, true);
> diff --git a/drivers/gpu/drm/arm/malidp_planes.c
> b/drivers/gpu/drm/arm/malidp_planes.c index 94e7e3fa3408..492d99dd55d4
> 100644
> --- a/drivers/gpu/drm/arm/malidp_planes.c
> +++ b/drivers/gpu/drm/arm/malidp_planes.c
> @@ -150,7 +150,8 @@ static int malidp_se_check_scaling(struct malidp_plane
> *mp,
> 
>   clip.x2 = crtc_state->adjusted_mode.hdisplay;
>   clip.y2 = crtc_state->adjusted_mode.vdisplay;
> - ret = drm_plane_helper_check_state(state, , 0, INT_MAX, true, 
> true);
> + ret = drm_plane_helper_check_state(state, crtc_state, ,
> +0, INT_MAX, true, true);
>   if (ret)
>   return ret;
> 
> diff --git a/drivers/gpu/drm/drm_plane_helper.c
> b/drivers/gpu/drm/drm_plane_helper.c index 759ed93f4ba8..adb8d94484f2
> 100644
> --- a/drivers/gpu/drm/drm_plane_helper.c
> +++ b/drivers/gpu/drm/drm_plane_helper.c
> @@ -101,7 +101,8 @@ static int get_connectors_for_crtc(struct drm_crtc
> *crtc,
> 
>  /**
>   * drm_plane_helper_check_state() - Check plane state for validity
> - * @state: plane state to check
> + * @plane_state: plane state to check
> + * @crtc_state: crtc state to check
>   * @clip: integer clipping coordinates
>   * @min_scale: minimum @src:@dest scaling factor in 16.16 fixed point
>   * @max_scale: maximum @src:@dest scaling factor in 16.16 fixed point
> @@ -120,35 +121,38 @@ static int get_connectors_for_crtc(struct drm_crtc
> *crtc, * RETURNS:
>   * Zero if update appears valid, error code on failure
>   */
> -int drm_plane_helper_check_state(struct drm_plane_state *state,
> +int drm_plane_helper_check_state(struct drm_plane_state *plane_state,
> +  const struct drm_crtc_state *crtc_state,
>const struct drm_rect *clip,
>int min_scale,
>int max_scale,
>bool can_position,
>bool can_update_disabled)
>  {
> - struct drm_crtc *crtc = state->crtc;
> - struct drm_framebuffer *fb = state->fb;
> - struct drm_rect *src = >src;
> - struct drm_rect *dst = 

Re: [Intel-gfx] [PATCH 3/5] drm/vmwgfx: Try to fix plane clipping

[Laurent Pinchart]

Hi Ville,

On Monday, 6 November 2017 20:04:38 EET Ville Syrjälä wrote:
> On Thu, Nov 02, 2017 at 03:19:30PM +0200, Ville Syrjälä wrote:
> > On Thu, Nov 02, 2017 at 11:12:09AM +0100, Daniel Vetter wrote:
> >> On Wed, Nov 01, 2017 at 08:29:18PM +0200, Ville Syrjala wrote:
> >>> From: Ville Syrjälä 
> >>> 
> >>> Try to fix the code to actually clip the plane to the crtc bounds
> >>> instead of the user provided crtc coordinates (which would be a no-op
> >>> since those are exactly the coordinates before clipping).
> >>> 
> >>> Cc: VMware Graphics 
> >>> Cc: Sinclair Yeh 
> >>> Cc: Thomas Hellstrom 
> >>> Signed-off-by: Ville Syrjälä 
> >> 
> >> I kinda wonder whether we shouldn't push this down into the helper ...

I think that would be nice.

> > Would require quite going through all drivers making sure they are
> > happy with using the adjusted_mode.crtc_ timings. I think most drivers
> > use the other adjusted_mode timings currently, and some even use the
> > user mode timings (which could be an actual bug).
> 
> Let me take that back. What we want is to clip to the user mode
> timings. Stereo 3D needs the special treatment from
> drm_mode_get_hv_timing(). I'm getting confused by all these
> different timings we have all over the place.
> 
> I think for i915 all we would need is to change the double wide/dual
> link adjustent for pipe_src_w to simply reject odd widths instead.
> That would guarantee that the user mode timings match the pipe_src_w/h
> 100%.
> 
> For the other driver we'd need to figure out why they're using
> adjusted_mode timings for clipping. I guess that's just a mistake,
> which I repeated here with vmwgfx after getting confused by looking
> at the other drivers.

I suppose it's a mix of cargo-cult and the fact that adjusted_mode hints that 
it contains the timings that should be applied to the hardware. That's why I 
use it in rcar-du.

Are drivers allowed to adjust the hdisplay and vdisplay values though ? I 
thought unsupported values there had to be rejected with an error at atomic 
check time, not adjusted.

> I guess I just volunteered myself to do this. Just needs plenty of
> acks from driver maintainers I suppose.

I'll review and test the rcar-du patch :-)

-- 
Regards,

Laurent Pinchart

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

[Bug 103863] Screen doesn't light up with "amdgpu.dc=1"

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103863

Michel Dänzer  changed:

   What|Removed |Added

  Component|Driver/AMDgpu   |DRM/AMDgpu
 QA Contact|xorg-t...@lists.x.org   |
Version|git |unspecified
   Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop
   ||.org
 CC||harry.wentl...@amd.com,
   ||jordan.laz...@amd.com
Product|xorg|DRI

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PULL] drm-intel-next-fixes

[Jani Nikula]

Hi Dave, some early fixes for v4.15 and stable.

BR,
Jani.

The following changes since commit e8c49fa96838101435b9e4884d49b30da7a4e0c6:

  drm/i915: Reorder context-close to avoid calling i915_vma_close() under RCU 
(2017-11-09 16:18:37 +0200)

are available in the git repository at:

  git://anongit.freedesktop.org/drm/drm-intel 
tags/drm-intel-next-fixes-2017-11-23

for you to fetch changes up to 3572f04c69ed4369da5d3c65d84fb18774aa60b6:

  drm/i915: Fix init_clock_gating for resume (2017-11-21 11:40:12 +0200)


drm/i915 fixes for v4.15


Chris Wilson (2):
  drm/i915: Clear breadcrumb node when cancelling signaling
  drm/i915: Mark the userptr invalidate workqueue as WQ_MEM_RECLAIM

Colin Ian King (1):
  drm/i915/gvt: ensure -ve return value is handled correctly

Hans de Goede (2):
  drm/i915: Fix false-positive assert_rpm_wakelock_held in 
i915_pmic_bus_access_notifier v2
  drm/i915: Re-register PMIC bus access notifier on runtime resume

Ville Syrjälä (1):
  drm/i915: Fix init_clock_gating for resume

 drivers/gpu/drm/i915/gvt/cmd_parser.c|  2 +-
 drivers/gpu/drm/i915/i915_drv.c  |  3 +++
 drivers/gpu/drm/i915/i915_gem_userptr.c  |  6 --
 drivers/gpu/drm/i915/intel_breadcrumbs.c |  1 +
 drivers/gpu/drm/i915/intel_uncore.c  | 13 +
 drivers/gpu/drm/i915/intel_uncore.h  |  1 +
 6 files changed, 23 insertions(+), 3 deletions(-)

-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/mediatek: Use ERR_CAST instead of ERR_PTR(PTR_ERR())

[Philipp Zabel]

On Tue, 2017-11-21 at 23:31 +0100, Vasyl Gomonovych wrote:
> Use ERR_CAST inlined function instead of ERR_PTR(PTR_ERR(...)).
> 
> drivers/gpu/drm/mediatek/mtk_drm_gem.c:223:9-16: WARNING: ERR_CAST can be 
> used with mtk_gem
> Generated by: scripts/coccinelle/api/err_cast.cocci
> 
> Signed-off-by: Vasyl Gomonovych 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_gem.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
> index f595ac816b55..5766b42fc174 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
> @@ -220,7 +220,7 @@ struct drm_gem_object 
> *mtk_gem_prime_import_sg_table(struct drm_device *dev,
>   mtk_gem = mtk_drm_gem_init(dev, attach->dmabuf->size);
>  
>   if (IS_ERR(mtk_gem))
> - return ERR_PTR(PTR_ERR(mtk_gem));
> + return ERR_CAST(mtk_gem));
>  
>   expected = sg_dma_address(sg->sgl);
>   for_each_sg(sg->sgl, s, sg->nents, i) {

Acked-by: Philipp Zabel 

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

Re: [PATCH 6/8] drm/mediatek: Add mfd support for mt8173

[Philipp Zabel]

On Tue, 2017-11-14 at 22:41 +0100, Matthias Brugger wrote:
> Use the MFD device for SoC mt8173. Probing via devicetree
> is no longer needed for any SoC, so delete it.
> 
> Signed-off-by: Matthias Brugger 

Apart from the mmsys_private issue noted in previous patches,

Reviewed-by: Philipp Zabel 

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

Re: [PATCH 5/8] mfd: mtk-mmsys: Add mt8173 nodes

[Philipp Zabel]

On Tue, 2017-11-14 at 22:41 +0100, Matthias Brugger wrote:
> Add devices for the mt8173 SoC.
> 
> Signed-off-by: Matthias Brugger 

Reviewed-by: Philipp Zabel 

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

Re: [PATCH 3/8] drm/mediatek: mt2701: switch to mfd probing.

[Philipp Zabel]

On Tue, 2017-11-14 at 22:41 +0100, Matthias Brugger wrote:
> With the mtk-mmsys MFD device in place, we switch the probing for
> mt2701 from device-tree to mfd.
> 
> Signed-off-by: Matthias Brugger 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c | 32 +---
>  1 file changed, 25 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index dd249cf5121e..5a263aa3ab6e 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -21,6 +21,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -392,9 +393,10 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = 
> {
>  
>  static int mtk_drm_probe(struct platform_device *pdev)
>  {
> + struct mmsys_dev *mmsys_private;
>   struct device *dev = >dev;
>   struct mtk_drm_private *private;
> - struct device_node *node;
> + struct device_node *node, *parent_node;
>   struct component_match *match = NULL;
>   int ret;
>   int i;
> @@ -407,12 +409,23 @@ static int mtk_drm_probe(struct platform_device *pdev)
>   INIT_WORK(>commit.work, mtk_atomic_work);
>   private->data = of_device_get_match_data(dev);
>  
> - private->config_regs = syscon_node_to_regmap(dev->of_node);
> - if (IS_ERR(private->config_regs))
> - return PTR_ERR(private->config_regs);
> + /* Check if called from mfd */
> + if (!dev->of_node) {
> + mmsys_private = dev_get_drvdata(pdev->dev.parent);
> + private->data = (struct mtk_mmsys_driver_data *)
> + platform_get_device_id(pdev)->driver_data;
> + private->config_regs =
> + syscon_node_to_regmap(mmsys_private->of_node);
> + parent_node = mmsys_private->of_node->parent;

I think this could be just:

mmsys_node = pdev->dev.parent->of_node;
private->data = (struct mtk_mmsys_driver_data *)> + 
platform_get_device_id(pdev)->driver_data;
private->config_regs = syscon_node_to_regmap(mmsys_node);
parent_node = mmsys_node->parent;

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

Re: [PATCH 2/8] mfd: mtk-mmsys: Add mmsys driver

[Philipp Zabel]

Hi Matthias,

On Tue, 2017-11-14 at 22:41 +0100, Matthias Brugger wrote:
> The MMSYS subsystem includes clocks and drm components.
> This patch adds a MFD device to probe both drivers from the same
> device tree compatible.
> 
> Signed-off-by: Matthias Brugger 
> ---
>  drivers/mfd/Kconfig   |  9 +
>  drivers/mfd/Makefile  |  2 ++
>  drivers/mfd/mtk-mmsys.c   | 91 
> +++
>  include/linux/mfd/mmsys.h | 18 ++
>  4 files changed, 120 insertions(+)
>  create mode 100644 drivers/mfd/mtk-mmsys.c
>  create mode 100644 include/linux/mfd/mmsys.h
> 
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index fc5e4fef89d2..3250ce5d205a 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -368,6 +368,15 @@ config MFD_MC13XXX_I2C
>   help
> Select this if your MC13xxx is connected via an I2C bus.
>  
> +config MFD_MEDIATEK_MMSYS
> + tristate "Mediatek MMSYS interface"
> + select MDF_CORE
> + select REGMAP_MMIO
> + help
> +   Select this if you have a MMSYS subsystem in your SoC. The
> +   MMSYS subsystem has at least a clock driver part and some
> +   DRM components.
> +
>  config MFD_MXS_LRADC
>   tristate "Freescale i.MX23/i.MX28 LRADC"
>   depends on ARCH_MXS || COMPILE_TEST
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 8703ff17998e..d4fc99df784c 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -100,6 +100,8 @@ obj-$(CONFIG_MFD_MC13XXX) += mc13xxx-core.o
>  obj-$(CONFIG_MFD_MC13XXX_SPI)+= mc13xxx-spi.o
>  obj-$(CONFIG_MFD_MC13XXX_I2C)+= mc13xxx-i2c.o
>  
> +obj-$(CONFIG_MFD_MEDIATEK_MMSYS) += mtk-mmsys.o
> +
>  obj-$(CONFIG_MFD_CORE)   += mfd-core.o
>  
>  obj-$(CONFIG_EZX_PCAP)   += ezx-pcap.o
> diff --git a/drivers/mfd/mtk-mmsys.c b/drivers/mfd/mtk-mmsys.c
> new file mode 100644
> index ..102b491aa28f
> --- /dev/null
> +++ b/drivers/mfd/mtk-mmsys.c
> @@ -0,0 +1,91 @@
> +/*
> + * mtk-mmsys.c  --  Mediatek MMSYS multi-function driver
> + *
> + *  Copyright (c) 2017 Matthias Brugger 
> + *
> + * Author: Matthias Brugger 
> + *
> + * For licencing details see kernel-base/COPYING
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +enum {
> + MMSYS_MT2701 = 1,
> +};
> +
> +static const struct mfd_cell mmsys_mt2701_devs[] = {
> + { .name = "clk-mt2701-mm", },
> + { .name = "drm-mt2701-mm", },
> +};
> +
> +static int mmsys_probe(struct platform_device *pdev)
> +{
> + struct mmsys_dev *private;
> + const struct mfd_cell *mmsys_cells;
> + int nr_cells;
> + long id;
> + int ret;
> +
> + id = (long) of_device_get_match_data(>dev);
> + if (!id) {
> + dev_err(>dev, "of_device_get match_data() failed\n");
> + return -EINVAL;
> + }
> +
> + switch (id) {
> + case MMSYS_MT2701:
> + mmsys_cells = mmsys_mt2701_devs;
> + nr_cells = ARRAY_SIZE(mmsys_mt2701_devs);
> + break;
> + default:
> + return -ENODEV;
> + }
> +
> + private = devm_kzalloc(>dev, sizeof(*private), GFP_KERNEL);
> + if (!private)
> + return -ENOMEM;
> +
> + private->dev = >dev;
> + dev_set_drvdata(private->dev, private);
> +
> + private->of_node = pdev->dev.of_node;

This seems superfluous to me. The of_node can be obtained from the
device, and the device itself is already needed to get to the drvdata.

Instead of

mmsys_private = drv_get_drvdata(pdev->dev.parent);
mmsys_dev = mmsys_private.dev;
mmsys_of_node = mmsys_private.of_node;

couldn't the mfd children just do

mmsys_dev = pdev->dev.parent;
mmsys_of_node = pdev->dev.parent->of_node;

?

> +
> + ret = devm_mfd_add_devices(private->dev, 0, mmsys_cells, nr_cells,
> + NULL, 0, NULL);
> + if (ret) {
> + dev_err(>dev, "failed to add MFD devices %d\n", ret);
> + return ret;
> + }
> +
> + return 0;
> +};
> +
> +static const struct of_device_id of_match_mmsys[] = {
> + { .compatible = "mediatek,mt2701-mmsys",
> +   .data = (void *) MMSYS_MT2701,
> + },
> + { /* sentinel */ },
> +};
> +
> +static struct platform_driver mmsys_drv = {
> + .probe = mmsys_probe,
> + .driver = {
> + .name = "mediatek-mmysys",
> + .of_match_table = of_match_ptr(of_match_mmsys),
> + },
> +};
> +
> +builtin_platform_driver(mmsys_drv);
> +
> +MODULE_DESCRIPTION("Mediatek MMSYS multi-function driver");
> +MODULE_LICENSE("GPL");
> diff --git a/include/linux/mfd/mmsys.h b/include/linux/mfd/mmsys.h
> new file mode 100644
> index ..274b9ee03ada
> --- /dev/null
> +++ b/include/linux/mfd/mmsys.h
> @@ -0,0 +1,18 @@
> +/* Header of MMSYS MFD 

Re: [PATCH 2/8] mfd: mtk-mmsys: Add mmsys driver

[CK Hu]

Hi, Matthias:

On Tue, 2017-11-14 at 22:41 +0100, Matthias Brugger wrote:
> The MMSYS subsystem includes clocks and drm components.
> This patch adds a MFD device to probe both drivers from the same
> device tree compatible.
> 
> Signed-off-by: Matthias Brugger 
> ---
>  drivers/mfd/Kconfig   |  9 +
>  drivers/mfd/Makefile  |  2 ++
>  drivers/mfd/mtk-mmsys.c   | 91 
> +++
>  include/linux/mfd/mmsys.h | 18 ++
>  4 files changed, 120 insertions(+)
>  create mode 100644 drivers/mfd/mtk-mmsys.c
>  create mode 100644 include/linux/mfd/mmsys.h
> 
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index fc5e4fef89d2..3250ce5d205a 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -368,6 +368,15 @@ config MFD_MC13XXX_I2C
>   help
> Select this if your MC13xxx is connected via an I2C bus.
>  
> +config MFD_MEDIATEK_MMSYS
> + tristate "Mediatek MMSYS interface"
> + select MDF_CORE
> + select REGMAP_MMIO
> + help
> +   Select this if you have a MMSYS subsystem in your SoC. The
> +   MMSYS subsystem has at least a clock driver part and some
> +   DRM components.
> +
>  config MFD_MXS_LRADC
>   tristate "Freescale i.MX23/i.MX28 LRADC"
>   depends on ARCH_MXS || COMPILE_TEST
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 8703ff17998e..d4fc99df784c 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -100,6 +100,8 @@ obj-$(CONFIG_MFD_MC13XXX) += mc13xxx-core.o
>  obj-$(CONFIG_MFD_MC13XXX_SPI)+= mc13xxx-spi.o
>  obj-$(CONFIG_MFD_MC13XXX_I2C)+= mc13xxx-i2c.o
>  
> +obj-$(CONFIG_MFD_MEDIATEK_MMSYS) += mtk-mmsys.o
> +
>  obj-$(CONFIG_MFD_CORE)   += mfd-core.o
>  
>  obj-$(CONFIG_EZX_PCAP)   += ezx-pcap.o
> diff --git a/drivers/mfd/mtk-mmsys.c b/drivers/mfd/mtk-mmsys.c
> new file mode 100644
> index ..102b491aa28f
> --- /dev/null
> +++ b/drivers/mfd/mtk-mmsys.c
> @@ -0,0 +1,91 @@
> +/*
> + * mtk-mmsys.c  --  Mediatek MMSYS multi-function driver
> + *
> + *  Copyright (c) 2017 Matthias Brugger 
> + *
> + * Author: Matthias Brugger 
> + *
> + * For licencing details see kernel-base/COPYING
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +enum {
> + MMSYS_MT2701 = 1,
> +};
> +
> +static const struct mfd_cell mmsys_mt2701_devs[] = {
> + { .name = "clk-mt2701-mm", },
> + { .name = "drm-mt2701-mm", },
> +};
> +
> +static int mmsys_probe(struct platform_device *pdev)
> +{
> + struct mmsys_dev *private;
> + const struct mfd_cell *mmsys_cells;
> + int nr_cells;
> + long id;
> + int ret;
> +
> + id = (long) of_device_get_match_data(>dev);
> + if (!id) {
> + dev_err(>dev, "of_device_get match_data() failed\n");
> + return -EINVAL;
> + }
> +
> + switch (id) {
> + case MMSYS_MT2701:
> + mmsys_cells = mmsys_mt2701_devs;
> + nr_cells = ARRAY_SIZE(mmsys_mt2701_devs);
> + break;
> + default:
> + return -ENODEV;
> + }
> +
> + private = devm_kzalloc(>dev, sizeof(*private), GFP_KERNEL);
> + if (!private)
> + return -ENOMEM;
> +
> + private->dev = >dev;
> + dev_set_drvdata(private->dev, private);
> +
> + private->of_node = pdev->dev.of_node;
> +
> + ret = devm_mfd_add_devices(private->dev, 0, mmsys_cells, nr_cells,
> + NULL, 0, NULL);
> + if (ret) {
> + dev_err(>dev, "failed to add MFD devices %d\n", ret);
> + return ret;
> + }
> +
> + return 0;
> +};
> +
> +static const struct of_device_id of_match_mmsys[] = {
> + { .compatible = "mediatek,mt2701-mmsys",

Because this driver replace the original "mediatek,mt2701-mmsys" driver,
could you modify the binding document of "mediatek,mt2701-mmsys" [1]?

[1]
https://www.kernel.org/doc/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt

Regards,
CK

> +   .data = (void *) MMSYS_MT2701,
> + },
> + { /* sentinel */ },
> +};
> +
> +static struct platform_driver mmsys_drv = {
> + .probe = mmsys_probe,
> + .driver = {
> + .name = "mediatek-mmysys",
> + .of_match_table = of_match_ptr(of_match_mmsys),
> + },
> +};
> +
> +builtin_platform_driver(mmsys_drv);
> +
> +MODULE_DESCRIPTION("Mediatek MMSYS multi-function driver");
> +MODULE_LICENSE("GPL");
> diff --git a/include/linux/mfd/mmsys.h b/include/linux/mfd/mmsys.h
> new file mode 100644
> index ..274b9ee03ada
> --- /dev/null
> +++ b/include/linux/mfd/mmsys.h
> @@ -0,0 +1,18 @@
> +/* Header of MMSYS MFD core driver for Mediatek platforms
> + *
> + * Copyright (c) 2017 Matthias Brugger 
> + *
> + * This program is free software; you can 

[PATCH] drm: Introduce RGB 64-bit 16:16:16:16 float format

[Tina Zhang]

The RGB 64-bit 16:16:16:16 float pixel format is needed by some Apps in
windows. The float format in each component is 1:5:10 MSb-sign:exponent:
fraction.

This patch is to introduce the format to drm, so that the windows guest's
framebuffer in this kind of format can be recognized and used by linux
host.

v14:
- add some details about the float pixel format. (Daniel)
- add F suffix to the defined name. (Daniel)

v12:
- send to dri-devel at lists.freedesktop.org. (Ville)

v9:
- separated from framebuffer decoder patch. (Zhenyu) (Xiaoguang)

Signed-off-by: Tina Zhang 
Cc: Ville Syrjälä 
Cc: Dave Airlie 
Cc: Daniel Vetter 
---
 include/uapi/drm/drm_fourcc.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 3ad838d..391d2e6 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -113,6 +113,10 @@ extern "C" {
 
 #define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V') /* 
[31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
 
+/* 64 bpp RGB 16:16:16:16 Floating Point */
+#define DRM_FORMAT_XRGB161616F  fourcc_code('X', 'R', '3', 'F') /* [63:0] 
x:R:G:B 16:16:16:16 little endian */
+#define DRM_FORMAT_XBGR161616F  fourcc_code('X', 'B', '3', 'F') /* [63:0] 
x:B:G:R 16:16:16:16 little endian */
+
 /*
  * 2 plane RGB + A
  * index 0 = RGB plane, same format as the corresponding non _A8 format has
-- 
2.7.4

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

[Bug 103850] "Quern" game crashes on start-up

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103850

--- Comment #2 from Michel Dänzer  ---
Looks like there might be memory corruption, can you run one of these games in
valgrind and attach the output from valgrind?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: Introduce RGB 64-bit 16:16:16:16 float format

[Tina Zhang]

This patch is from "[PATCH v19 0/6] drm/i915/gvt: Dma-buf support for GVT-g":
https://lists.freedesktop.org/archives/intel-gvt-dev/2017-November/002508.html

The RGB 64-bit 16:16:16:16 float pixel format is needed by some Apps in
windows. The float format in each component is 1:5:10 MSb-sign:exponent:
fraction.

This patch is to introduce the format to drm, so that the windows guest's
framebuffer in this kind of format can be recognized and used by linux
host.

Tina Zhang (1):
  drm: Introduce RGB 64-bit 16:16:16:16 float format

 include/uapi/drm/drm_fourcc.h | 4 
 1 file changed, 4 insertions(+)

-- 
2.7.4

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

[Bug 100745] amdgpu fails to wake up DisplayPort DELL monitors with 'clock recovery failed'

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100745

--- Comment #9 from Michel Dänzer  ---
(In reply to Benjamin Bellec from comment #8)
> I hit the same problem today after enabling amdgpu.dc=1
> The screen doesn't light up at all if I boot the kernel with amdgpu.dc=1

AFAICT this report is about the non-DC code, please file your own report about
the issue with DC.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/8] drm/mediatek: Use regmap for register access

[Philipp Zabel]

Hi Matthias,

On Tue, 2017-11-14 at 22:41 +0100, Matthias Brugger wrote:
> The mmsys memory space is shared between the drm and the
> clk driver. Use regmap to access it.
> 
> Signed-off-by: Matthias Brugger 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c |  4 ++--
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.c  | 30 +-
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.h  |  4 ++--
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c  | 13 -
>  drivers/gpu/drm/mediatek/mtk_drm_drv.h  |  2 +-
>  5 files changed, 26 insertions(+), 27 deletions(-)
[...]
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 8130f3dab661..1227d6db07da 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -185,16 +185,16 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id 
> cur,
>   return value;
>  }
>  
> -static void mtk_ddp_sout_sel(void __iomem *config_regs,
> +static void mtk_ddp_sout_sel(struct regmap *config_regs,
>enum mtk_ddp_comp_id cur,
>enum mtk_ddp_comp_id next)
>  {
>   if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DSI0)
> - writel_relaxed(BLS_TO_DSI_RDMA1_TO_DPI1,
> -config_regs + DISP_REG_CONFIG_OUT_SEL);
> + regmap_write(config_regs, DISP_REG_CONFIG_OUT_SEL,
> + BLS_TO_DSI_RDMA1_TO_DPI1);
>  }
>  
> -void mtk_ddp_add_comp_to_path(void __iomem *config_regs,
> +void mtk_ddp_add_comp_to_path(struct regmap *config_regs,
> enum mtk_ddp_comp_id cur,
> enum mtk_ddp_comp_id next)
>  {
> @@ -202,20 +202,22 @@ void mtk_ddp_add_comp_to_path(void __iomem *config_regs,
>  
>   value = mtk_ddp_mout_en(cur, next, );
>   if (value) {
> - reg = readl_relaxed(config_regs + addr) | value;
> - writel_relaxed(reg, config_regs + addr);
> + regmap_read(config_regs, addr, );
> + reg |= value;
> + regmap_write(config_regs, addr, reg);

You can use

regmap_update_bits(config_regs, addr, value, value);

here and drop the local variable reg.

>   }
>  
>   mtk_ddp_sout_sel(config_regs, cur, next);
>  
>   value = mtk_ddp_sel_in(cur, next, );
>   if (value) {
> - reg = readl_relaxed(config_regs + addr) | value;
> - writel_relaxed(reg, config_regs + addr);
> + regmap_read(config_regs, addr, );
> + reg |= value;
> + regmap_write(config_regs, addr, reg);

regmap_update_bits(config_regs, addr, value, value);

>   }
>  }
>  
> -void mtk_ddp_remove_comp_from_path(void __iomem *config_regs,
> +void mtk_ddp_remove_comp_from_path(struct regmap *config_regs,
>  enum mtk_ddp_comp_id cur,
>  enum mtk_ddp_comp_id next)
>  {
> @@ -223,14 +225,16 @@ void mtk_ddp_remove_comp_from_path(void __iomem 
> *config_regs,
>  
>   value = mtk_ddp_mout_en(cur, next, );
>   if (value) {
> - reg = readl_relaxed(config_regs + addr) & ~value;
> - writel_relaxed(reg, config_regs + addr);
> + regmap_read(config_regs, addr, );
> + reg &= ~value;
> + regmap_write(config_regs, addr, reg);

regmap_update_bits(config_regs, addr, value, 0);

>   }
>  
>   value = mtk_ddp_sel_in(cur, next, );
>   if (value) {
> - reg = readl_relaxed(config_regs + addr) & ~value;
> - writel_relaxed(reg, config_regs + addr);
> + regmap_read(config_regs, addr, );
> + reg &= ~value;
> + regmap_write(config_regs, addr, reg);

regmap_update_bits(config_regs, addr, value, 0);

Reviewed-by: Philipp Zabel 

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

[Bug 100745] amdgpu fails to wake up DisplayPort DELL monitors with 'clock recovery failed'

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100745

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #130957|text/x-log  |text/plain
  mime type||

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 6/8] drm/mediatek: Add mfd support for mt8173

[CK Hu]

Hi, Matthias:

On Tue, 2017-11-14 at 22:41 +0100, Matthias Brugger wrote:
> Use the MFD device for SoC mt8173. Probing via devicetree
> is no longer needed for any SoC, so delete it.
> 
> Signed-off-by: Matthias Brugger 

Acked-by: CK Hu 

> ---
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c | 28 +++-
>  1 file changed, 7 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index 5a263aa3ab6e..1eb02acf229a 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -409,20 +409,12 @@ static int mtk_drm_probe(struct platform_device *pdev)
>   INIT_WORK(>commit.work, mtk_atomic_work);
>   private->data = of_device_get_match_data(dev);
>  
> - /* Check if called from mfd */
> - if (!dev->of_node) {
> - mmsys_private = dev_get_drvdata(pdev->dev.parent);
> - private->data = (struct mtk_mmsys_driver_data *)
> - platform_get_device_id(pdev)->driver_data;
> - private->config_regs =
> - syscon_node_to_regmap(mmsys_private->of_node);
> - parent_node = mmsys_private->of_node->parent;
> - } else {
> - private->config_regs = syscon_node_to_regmap(dev->of_node);
> - if (IS_ERR(private->config_regs))
> - return PTR_ERR(private->config_regs);
> - parent_node = dev->of_node->parent;
> - }
> + mmsys_private = dev_get_drvdata(pdev->dev.parent);
> + private->data = (struct mtk_mmsys_driver_data *)
> + platform_get_device_id(pdev)->driver_data;
> + private->config_regs =
> + syscon_node_to_regmap(mmsys_private->of_node);
> + parent_node = mmsys_private->of_node->parent;
>  
>   /* Iterate over sibling DISP function blocks */
>   for_each_child_of_node(parent_node, node) {
> @@ -565,14 +557,9 @@ static int mtk_drm_sys_resume(struct device *dev)
>  static SIMPLE_DEV_PM_OPS(mtk_drm_pm_ops, mtk_drm_sys_suspend,
>mtk_drm_sys_resume);
>  
> -static const struct of_device_id mtk_drm_of_ids[] = {
> - { .compatible = "mediatek,mt8173-mmsys",
> -   .data = _mmsys_driver_data},
> - { }
> -};
> -
>  static const struct platform_device_id mtk_drm_ids[] = {
>   { "drm-mt2701-mm", (kernel_ulong_t)_mmsys_driver_data },
> + { "drm-mt8173-mm", (kernel_ulong_t)_mmsys_driver_data },
>   { /* sentinel */ },
>  };
>  MODULE_DEVICE_TABLE(platform, mtk_drm_ids);
> @@ -582,7 +569,6 @@ static struct platform_driver mtk_drm_platform_driver = {
>   .remove = mtk_drm_remove,
>   .driver = {
>   .name   = "mediatek-drm",
> - .of_match_table = mtk_drm_of_ids,
>   .pm = _drm_pm_ops,
>   },
>   .id_table = mtk_drm_ids,


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

Re: [PATCH 3/8] drm/mediatek: mt2701: switch to mfd probing.

[CK Hu]

Hi, Matthias:

On Thu, 2017-11-23 at 09:30 +0100, Matthias Brugger wrote:
> 
> On 11/23/2017 06:48 AM, CK Hu wrote:
> > Hi, Matthias:
> > 
> > On Tue, 2017-11-14 at 22:41 +0100, Matthias Brugger wrote:
> >> With the mtk-mmsys MFD device in place, we switch the probing for
> >> mt2701 from device-tree to mfd.
> >>
> >> Signed-off-by: Matthias Brugger 
> >> ---
> >>  drivers/gpu/drm/mediatek/mtk_drm_drv.c | 32 
> >> +---
> >>  1 file changed, 25 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
> >> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> >> index dd249cf5121e..5a263aa3ab6e 100644
> >> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> >> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> >> @@ -21,6 +21,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>  #include 
> >>  #include 
> >>  #include 
> >> @@ -392,9 +393,10 @@ static const struct of_device_id 
> >> mtk_ddp_comp_dt_ids[] = {
> >>  
> >>  static int mtk_drm_probe(struct platform_device *pdev)
> >>  {
> >> +  struct mmsys_dev *mmsys_private;
> >>struct device *dev = >dev;
> >>struct mtk_drm_private *private;
> >> -  struct device_node *node;
> >> +  struct device_node *node, *parent_node;
> >>struct component_match *match = NULL;
> >>int ret;
> >>int i;
> >> @@ -407,12 +409,23 @@ static int mtk_drm_probe(struct platform_device 
> >> *pdev)
> >>INIT_WORK(>commit.work, mtk_atomic_work);
> >>private->data = of_device_get_match_data(dev);
> >>  
> >> -  private->config_regs = syscon_node_to_regmap(dev->of_node);
> >> -  if (IS_ERR(private->config_regs))
> >> -  return PTR_ERR(private->config_regs);
> >> +  /* Check if called from mfd */
> >> +  if (!dev->of_node) {
> >> +  mmsys_private = dev_get_drvdata(pdev->dev.parent);
> > 
> > Why do you directly access parent's driver data? You just need the
> > device node of mmsys, maybe you could refer to [1].
> > 
> > [1]
> > https://elixir.free-electrons.com/linux/latest/source/drivers/reset/reset-berlin.c#L78
> > 
> 
> The difference is, that the driver you mentioned gets probed via device tree
> matching, while we get invoked here through the id_table. So there is no 
> device
> node (the if actually checkes for pdev->dev.of_node to identify exactly this 
> case).
> 
> Regards,
> Matthias

Yes, you are right. So

Acked-by: CK Hu 

Regards,
CK
> 
> ___
> 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 V2 09/29] drm/i915: deprecate pci_get_bus_and_slot()

[Sinan Kaya]

On 11/22/2017 5:49 PM, Sinan Kaya wrote:
>  static int i915_get_bridge_dev(struct drm_i915_private *dev_priv)
>  {
> - dev_priv->bridge_dev = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
> + u32 domain = pci_domain_nr(dev_priv->drm.pdev->bus);

I'll convert domain type to int on the next version across the series.

I tried to convert most of the drivers to use pci_domain_nr() per feedback
from Greg KH. I'll hold onto posting a new version until I gather feedback
with the approach I have taken.

I just did a build test with the series.

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, 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

[PATCH] dma-buf: Fix ifnullfree.cocci warnings

[Vasyl Gomonovych]

NULL check before some freeing functions is not needed.
drivers/dma-buf/dma-buf.c:1183:2-26: WARNING: NULL check before freeing 
debugfs_remove_recursive
Generated by: scripts/coccinelle/free/ifnullfree.cocci

Signed-off-by: Vasyl Gomonovych 
---
 drivers/dma-buf/dma-buf.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 4a038dcf5361..048827b06c03 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1179,8 +1179,7 @@ static int dma_buf_init_debugfs(void)
 
 static void dma_buf_uninit_debugfs(void)
 {
-   if (dma_buf_debugfs_dir)
-   debugfs_remove_recursive(dma_buf_debugfs_dir);
+   debugfs_remove_recursive(dma_buf_debugfs_dir);
 }
 #else
 static inline int dma_buf_init_debugfs(void)
-- 
1.9.1

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

Re: [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

[Boris Ostrovsky]

On 11/22/2017 05:09 AM, Christian König wrote:
> Am 21.11.2017 um 23:26 schrieb Boris Ostrovsky:
>> On 11/21/2017 08:34 AM, Christian König wrote:
>>> Hi Boris,
>>>
>>> attached are two patches.
>>>
>>> The first one is a trivial fix for the infinite loop issue, it now
>>> correctly aborts the fixup when it can't find address space for the
>>> root window.
>>>
>>> The second is a workaround for your board. It simply checks if there
>>> is exactly one Processor Function to apply this fix on.
>>>
>>> Both are based on linus current master branch. Please test if they fix
>>> your issue.
>>
>> Yes, they do fix it but that's because the feature is disabled.
>>
>> Do you know what the actual problem was (on Xen)?
>
> I still haven't understood what you actually did with Xen.
>
> When you used PCI pass through with those devices then you have made a
> major configuration error.
>
> When the problem happened on dom0 then the explanation is most likely
> that some PCI device ended up in the configured space, but the routing
> was only setup correctly on one CPU socket.

The problem is that dom0 can be (and was in my case() booted with less
than full physical memory and so the "rest" of the host memory is not
necessarily reflected in iomem. Your patch then tried to configure that
memory for MMIO and the system hang.

And so my guess is that this patch will break dom0 on a single-socket
system as well.

-boris

>
> Regards,
> Christian.
>
>>
>> Thanks.
>> -boris
>>
>>> Thanks for the help,
>>> Christian.
>>>
>>> Am 20.11.2017 um 17:33 schrieb Boris Ostrovsky:
 On 11/20/2017 11:07 AM, Christian König wrote:
> Am 20.11.2017 um 16:51 schrieb Boris Ostrovsky:
>> (and then it breaks differently as a Xen guest --- we hung on the
>> last
>> pci_read_config_dword(), I haven't looked at this at all yet)
> Hui? How does this fix applies to a Xen guest in the first place?
>
> Please provide the output of "lspci -nn" and explain further what is
> your config with Xen.
>
>
 This is dom0.

 -bash-4.1# lspci -nn
 00:00.0 Host bridge [0600]: ATI Technologies Inc RD890 Northbridge
 only
 dual slot (2x16) PCI-e GFX Hydra part [1002:5a10] (rev 02)
 00:00.2 Generic system peripheral [0806]: ATI Technologies Inc Device
 [1002:5a23]
 00:0d.0 PCI bridge [0604]: ATI Technologies Inc RD890 PCI to PCI
 bridge
 (external gfx1 port B) [1002:5a1e]
 00:11.0 SATA controller [0106]: ATI Technologies Inc SB700/SB800 SATA
 Controller [AHCI mode] [1002:4391]
 00:12.0 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB
 OHCI0 Controller [1002:4397]
 00:12.1 USB Controller [0c03]: ATI Technologies Inc SB700 USB OHCI1
 Controller [1002:4398]
 00:12.2 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB
 EHCI
 Controller [1002:4396]
 00:13.0 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB
 OHCI0 Controller [1002:4397]
 00:13.1 USB Controller [0c03]: ATI Technologies Inc SB700 USB OHCI1
 Controller [1002:4398]
 00:13.2 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB
 EHCI
 Controller [1002:4396]
 00:14.0 SMBus [0c05]: ATI Technologies Inc SBx00 SMBus Controller
 [1002:4385] (rev 3d)
 00:14.3 ISA bridge [0601]: ATI Technologies Inc SB700/SB800 LPC host
 controller [1002:439d]
 00:14.4 PCI bridge [0604]: ATI Technologies Inc SBx00 PCI to PCI
 Bridge
 [1002:4384]
 00:14.5 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB
 OHCI2 Controller [1002:4399]
 00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] Device
 [1022:1600]
 00:18.1 Host bridge [0600]: Advanced Micro Devices [AMD] Device
 [1022:1601]
 00:18.2 Host bridge [0600]: Advanced Micro Devices [AMD] Device
 [1022:1602]
 00:18.3 Host bridge [0600]: Advanced Micro Devices [AMD] Device
 [1022:1603]
 00:18.4 Host bridge [0600]: Advanced Micro Devices [AMD] Device
 [1022:1604]
 00:18.5 Host bridge [0600]: Advanced Micro Devices [AMD] Device
 [1022:1605]
 00:19.0 Host bridge [0600]: Advanced Micro Devices [AMD] Device
 [1022:1600]
 00:19.1 Host bridge [0600]: Advanced Micro Devices [AMD] Device
 [1022:1601]
 00:19.2 Host bridge [0600]: Advanced Micro Devices [AMD] Device
 [1022:1602]
 00:19.3 Host bridge [0600]: Advanced Micro Devices [AMD] Device
 [1022:1603]
 00:19.4 Host bridge [0600]: Advanced Micro Devices [AMD] Device
 [1022:1604]
 00:19.5 Host bridge [0600]: Advanced Micro Devices [AMD] Device
 [1022:1605]
 01:04.0 VGA compatible controller [0300]: Matrox Graphics, Inc. MGA
 G200eW WPCM450 [102b:0532] (rev 0a)
 02:00.0 Ethernet controller [0200]: Intel Corporation 82576 Gigabit
 Network Connection [8086:10c9] (rev 01)
 02:00.1 Ethernet controller [0200]: Intel Corporation 82576 Gigabit
 Network Connection [8086:10c9] (rev 01)
 -bash-4.1#

Re: [BUG] drm: vc4: refcount_t: increment on 0; use-after-free.

[Stefan Wahren]

Hi Boris,

> Boris Brezillon  hat am 22. November 2017 
> um 18:51 geschrieben:
> 
> 
> Hi Stefan,
> 
> On Wed, 22 Nov 2017 17:43:35 +0100 (CET)
> Stefan Wahren  wrote:
> ...
> 
> Looks like I didn't test this code with CONFIG_REFCOUNT_FULL enabled :-/.
> 
> Anyway, can you try to apply the following diff and let me know if it
> fixes the problem?

yes, this fixes the problem.

> 
> Thanks,
> 
> Boris
> 
> --->8---
> diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
> index 4ae45d7dac42..2decc8e2c79f 100644
> --- a/drivers/gpu/drm/vc4/vc4_bo.c
> +++ b/drivers/gpu/drm/vc4/vc4_bo.c
> @@ -637,7 +637,8 @@ int vc4_bo_inc_usecnt(struct vc4_bo *bo)
> mutex_lock(>madv_lock);
> switch (bo->madv) {
> case VC4_MADV_WILLNEED:
> -   refcount_inc(>usecnt);
> +   if (!refcount_inc_not_zero(>usecnt))
> +   refcount_set(>usecnt, 1);
> ret = 0;
> break;
> case VC4_MADV_DONTNEED:
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[BUG] drm: vc4: refcount_t: increment on 0; use-after-free.

[Stefan Wahren]

Hi Boris,
if i boot Raspberry Pi 3 (ARM64, defconfig, linux-next-20171122) with 
sufficient CMA memory (32 MB), i'll get this warning during boot:

[7.623510] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops [vc4])
[7.632453] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops [vc4])
[7.639707] vc4-drm soc:gpu: bound 3f40.hvs (ops vc4_hvs_ops [vc4])
[7.647364] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops 
[vc4])
[7.655451] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops 
[vc4])
[7.663415] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops 
[vc4])
[7.730580] vc4-drm soc:gpu: bound 3fc0.v3d (ops vc4_v3d_ops [vc4])
[7.743965] [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on minor 0
[7.750841] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[7.757620] [drm] Driver supports precise vblank timestamp query.
[7.811775] [ cut here ]
[7.811780] refcount_t: increment on 0; use-after-free.
[7.811881] WARNING: CPU: 2 PID: 2188 at lib/refcount.c:153 
refcount_inc+0x44/0x50
[7.811884] Modules linked in: vc4(+) cfg80211 cec drm_kms_helper smsc95xx 
usbnet drm rfkill brcmutil bcm2835_rng rng_core bcm2835_dma crc32_ce 
i2c_bcm2835 pwm_bcm2835 ip_tables x_tables ipv6
[7.811950] CPU: 2 PID: 2188 Comm: systemd-udevd Not tainted 
4.14.0-next-20171122 #1
[7.811953] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)
[7.811958] task: 800036b91c00 task.stack: 0d6f
[7.811967] pstate: 2005 (nzCv daif -PAN -UAO)
[7.811974] pc : refcount_inc+0x44/0x50
[7.811981] lr : refcount_inc+0x44/0x50
[7.811984] sp : 0d6f3300
[7.811988] x29: 0d6f3300 x28:  
[7.811996] x27: 0003 x26: 800037107800 
[7.812004] x25: 0001 x24: 800035afdc00 
[7.812012] x23:  x22: 800035dfa600 
[7.812020] x21: 800035afd9b0 x20: 800035afd9a4 
[7.812027] x19:  x18:  
[7.812034] x17: 0001 x16: 0019 
[7.812042] x15: 0001 x14: fff0 
[7.812049] x13: 090ae840 x12: 08fa2d50 
[7.812057] x11: 08fa2000 x10: 090ad000 
[7.812064] x9 :  x8 : 090b5c2f 
[7.812072] x7 :  x6 : 0015ee00 
[7.812079] x5 :  x4 :  
[7.812087] x3 :  x2 : 800030047000 
[7.812094] x1 : 800036b91c00 x0 : 002b 
[7.812102] Call trace:
[7.812109]  refcount_inc+0x44/0x50
[7.812226]  vc4_bo_inc_usecnt+0x84/0x88 [vc4]
[7.812310]  vc4_prepare_fb+0x40/0xf0 [vc4]
[7.812460]  drm_atomic_helper_prepare_planes+0x54/0xf0 [drm_kms_helper]
[7.812543]  vc4_atomic_commit+0x88/0x130 [vc4]
[7.812868]  drm_atomic_commit+0x48/0x68 [drm]
[7.813002]  restore_fbdev_mode_atomic+0x1d8/0x1e8 [drm_kms_helper]
[7.813113]  restore_fbdev_mode+0x28/0x160 [drm_kms_helper]
[7.813223]  drm_fb_helper_restore_fbdev_mode_unlocked.part.24+0x28/0x90 
[drm_kms_helper]
[7.813331]  drm_fb_helper_set_par+0x54/0xa8 [drm_kms_helper]
[7.813346]  fbcon_init+0x4e8/0x538
[7.813357]  visual_init+0xb4/0x108
[7.813366]  do_bind_con_driver+0x1b8/0x3a0
[7.813373]  do_take_over_console+0x150/0x1d0
[7.813380]  do_fbcon_takeover+0x6c/0xf0
[7.813387]  fbcon_event_notify+0x8fc/0x928
[7.813399]  notifier_call_chain+0x50/0x90
[7.813406]  __blocking_notifier_call_chain+0x4c/0x90
[7.813413]  blocking_notifier_call_chain+0x14/0x20
[7.813420]  fb_notifier_call_chain+0x1c/0x28
[7.813426]  register_framebuffer+0x1d0/0x2d8
[7.813533]  __drm_fb_helper_initial_config_and_unlock+0x1e8/0x350 
[drm_kms_helper]
[7.813639]  drm_fb_helper_initial_config+0x40/0x58 [drm_kms_helper]
[7.813747]  drm_fbdev_cma_init_with_funcs+0x88/0x158 [drm_kms_helper]
[7.813855]  drm_fbdev_cma_init+0x14/0x28 [drm_kms_helper]
[7.813943]  vc4_kms_load+0xa4/0xf0 [vc4]
[7.814026]  vc4_drm_bind+0x100/0x168 [vc4]
[7.814038]  try_to_bring_up_master+0x144/0x1a8
[7.814044]  component_master_add_with_match+0x9c/0xe0
[7.814128]  vc4_platform_drm_probe+0xb4/0xf0 [vc4]
[7.814137]  platform_drv_probe+0x58/0xc0
[7.814146]  driver_probe_device+0x224/0x308
[7.814153]  __driver_attach+0xac/0xb0
[7.814161]  bus_for_each_dev+0x64/0xa0
[7.814169]  driver_attach+0x20/0x28
[7.814177]  bus_add_driver+0x108/0x228
[7.814184]  driver_register+0x60/0xf8
[7.814190]  __platform_driver_register+0x40/0x48
[7.814274]  vc4_drm_register+0x38/0x1000 [vc4]
[7.814283]  do_one_initcall+0x38/0x120
[7.814295]  do_init_module+0x58/0x1b8
[7.814304]  load_module+0x1fa8/0x2280
[7.814311]  SyS_finit_module+0xc0/0xd0
[7.814318]  __sys_trace_return+0x0/0x4
[7.814325] ---[ end trace 3348554eb91e19a1 ]---

[PATCH V2 09/29] drm/i915: deprecate pci_get_bus_and_slot()

[Sinan Kaya]

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.

Getting ready to remove pci_get_bus_and_slot() function in favor of
pci_get_domain_bus_and_slot().

Extract the domain number from drm_device and pass it into
pci_get_domain_bus_and_slot() function.

Signed-off-by: Sinan Kaya 
---
 drivers/gpu/drm/i915/i915_drv.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 9f45cfe..fea2b5e 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -419,7 +419,10 @@ static int i915_getparam(struct drm_device *dev, void 
*data,
 
 static int i915_get_bridge_dev(struct drm_i915_private *dev_priv)
 {
-   dev_priv->bridge_dev = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
+   u32 domain = pci_domain_nr(dev_priv->drm.pdev->bus);
+
+   dev_priv->bridge_dev =
+   pci_get_domain_bus_and_slot(domain, 0, PCI_DEVFN(0, 0));
if (!dev_priv->bridge_dev) {
DRM_ERROR("bridge device not found\n");
return -1;
-- 
1.9.1

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

[PATCH V2 10/29] drm/nouveau: deprecate pci_get_bus_and_slot()

[Sinan Kaya]

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.

Getting ready to remove pci_get_bus_and_slot() function in favor of
pci_get_domain_bus_and_slot().

Replace pci_get_bus_and_slot() with pci_get_domain_bus_and_slot()
and extract the domain number from
1. struct pci_dev
2. struct pci_dev through drm_device->pdev
3. struct pci_dev through fb->subdev->drm_device->pdev

Signed-off-by: Sinan Kaya 
---
 drivers/gpu/drm/nouveau/dispnv04/arb.c   |  4 +++-
 drivers/gpu/drm/nouveau/dispnv04/hw.c| 10 +++---
 drivers/gpu/drm/nouveau/nouveau_drm.c|  3 ++-
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c | 10 +-
 4 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv04/arb.c 
b/drivers/gpu/drm/nouveau/dispnv04/arb.c
index 90075b6..e7455f7 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/arb.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/arb.c
@@ -213,8 +213,10 @@ struct nv_sim_state {
if ((dev->pdev->device & 0x) == 0x01a0 /*CHIPSET_NFORCE*/ ||
(dev->pdev->device & 0x) == 0x01f0 /*CHIPSET_NFORCE2*/) {
uint32_t type;
+   u32 domain = pci_domain_nr(dev->pdev->bus);
 
-   pci_read_config_dword(pci_get_bus_and_slot(0, 1), 0x7c, );
+   pci_read_config_dword(pci_get_domain_bus_and_slot(domain, 0, 1),
+ 0x7c, );
 
sim_data.memory_type = (type >> 12) & 1;
sim_data.memory_width = 64;
diff --git a/drivers/gpu/drm/nouveau/dispnv04/hw.c 
b/drivers/gpu/drm/nouveau/dispnv04/hw.c
index b985990..8806b1b 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/hw.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/hw.c
@@ -216,12 +216,15 @@
 {
struct nvkm_pll_vals pllvals;
int ret;
+   u32 domain;
+
+   domain = pci_domain_nr(dev->pdev->bus);
 
if (plltype == PLL_MEMORY &&
(dev->pdev->device & 0x0ff0) == CHIPSET_NFORCE) {
uint32_t mpllP;
-
-   pci_read_config_dword(pci_get_bus_and_slot(0, 3), 0x6c, );
+   pci_read_config_dword(pci_get_domain_bus_and_slot(domain, 0, 3),
+ 0x6c, );
mpllP = (mpllP >> 8) & 0xf;
if (!mpllP)
mpllP = 4;
@@ -232,7 +235,8 @@
(dev->pdev->device & 0xff0) == CHIPSET_NFORCE2) {
uint32_t clock;
 
-   pci_read_config_dword(pci_get_bus_and_slot(0, 5), 0x4c, );
+   pci_read_config_dword(pci_get_domain_bus_and_slot(domain, 0, 5),
+ 0x4c, );
return clock / 1000;
}
 
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 595630d..0b6c639 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -406,7 +406,8 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
}
 
/* subfunction one is a hdmi audio device? */
-   drm->hdmi_device = pci_get_bus_and_slot((unsigned int)pdev->bus->number,
+   drm->hdmi_device = pci_get_domain_bus_and_slot(pci_domain_nr(pdev->bus),
+   (unsigned int)pdev->bus->number,

PCI_DEVFN(PCI_SLOT(pdev->devfn), 1));
 
if (!drm->hdmi_device) {
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c
index 3c6a871..273a632 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c
@@ -28,8 +28,16 @@
 {
struct pci_dev *bridge;
u32 mem, mib;
+   u32 domain = 0;
+   struct pci_dev *pdev = NULL;
 
-   bridge = pci_get_bus_and_slot(0, PCI_DEVFN(0, 1));
+   if (dev_is_pci(fb->subdev.device->dev))
+   pdev = to_pci_dev(fb->subdev.device->dev);
+
+   if (pdev)
+   domain = pci_domain_nr(pdev->bus);
+
+   bridge = pci_get_domain_bus_and_slot(domain, 0, PCI_DEVFN(0, 1));
if (!bridge) {
nvkm_error(>subdev, "no bridge device\n");
return -ENODEV;
-- 
1.9.1

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

Re: [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

[Boris Ostrovsky]

On 11/22/2017 11:54 AM, Christian König wrote:
> Am 22.11.2017 um 17:24 schrieb Boris Ostrovsky:
>> On 11/22/2017 05:09 AM, Christian König wrote:
>>> Am 21.11.2017 um 23:26 schrieb Boris Ostrovsky:
 On 11/21/2017 08:34 AM, Christian König wrote:
> Hi Boris,
>
> attached are two patches.
>
> The first one is a trivial fix for the infinite loop issue, it now
> correctly aborts the fixup when it can't find address space for the
> root window.
>
> The second is a workaround for your board. It simply checks if there
> is exactly one Processor Function to apply this fix on.
>
> Both are based on linus current master branch. Please test if they
> fix
> your issue.
 Yes, they do fix it but that's because the feature is disabled.

 Do you know what the actual problem was (on Xen)?
>>> I still haven't understood what you actually did with Xen.
>>>
>>> When you used PCI pass through with those devices then you have made a
>>> major configuration error.
>>>
>>> When the problem happened on dom0 then the explanation is most likely
>>> that some PCI device ended up in the configured space, but the routing
>>> was only setup correctly on one CPU socket.
>> The problem is that dom0 can be (and was in my case() booted with less
>> than full physical memory and so the "rest" of the host memory is not
>> necessarily reflected in iomem. Your patch then tried to configure that
>> memory for MMIO and the system hang.
>>
>> And so my guess is that this patch will break dom0 on a single-socket
>> system as well.
>
> Oh, thanks!
>
> I've thought about that possibility before, but wasn't able to find a
> system which actually does that.
>
> May I ask why the rest of the memory isn't reported to the OS?

That memory doesn't belong to the OS (dom0), it is owned by the hypervisor.

>
> Sounds like I can't trust Linux resource management and probably need
> to read the DRAM config to figure things out after all.


My question is whether what you are trying to do should ever be done for
a guest at all (any guest, not necessarily Xen).

-boris

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

[PATCH] drm/i915: Avoid enum conversion warning

[Nick Desaulniers]

Fixes the following enum conversion warning:

drivers/gpu/drm/i915/intel_ddi.c:1481:30: error: implicit conversion
from enumeration type 'enum port' to different enumeration type 'enum
intel_dpll_id' [-Werror,-Wenum-conversion]
enum intel_dpll_id pll_id = port;
   ~~   ^~~~

Signed-off-by: Nick Desaulniers 
---
 drivers/gpu/drm/i915/intel_ddi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 933c18fd4258..f9de45316901 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1478,7 +1478,7 @@ static void bxt_ddi_clock_get(struct intel_encoder 
*encoder,
 {
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
enum port port = intel_ddi_get_encoder_port(encoder);
-   enum intel_dpll_id pll_id = port;
+   uint32_t pll_id = port;
 
pipe_config->port_clock = bxt_calc_pll_link(dev_priv, pll_id);
 
-- 
2.14.1

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

Re: Autoselect patches for stable (Was: Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV)

[alexander . levin]

On Tue, Nov 21, 2017 at 05:55:29PM +, Emil Velikov wrote:
>On 21 November 2017 at 15:07,   wrote:
>> On Mon, Nov 20, 2017 at 11:21:52AM +, Emil Velikov wrote:
>>> - Document the autoselect process
>>>Information about about What, Why, and [ideally] How - analogous to
>>>the normal stable nominations.
>>>Insert reference to the process in the patch notification email.
>>
>> I agree with this one, and it'll definitely happen. The story behind
>> this is that this is all based on Julia Lawall's work which is well
>> documented in a published paper here:
>>
>> 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__soarsmu.github.io_papers_icse12-2Dpatch.pdf=DwIBaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=bUtaaC9mlBij4OjEG_D-KPul_335azYzfC4Rjgomobo=fv1wuXCQm6WYyxCaomxaGGxNXY-K4gUrTY4VOx24NXw=9BjAjAQOia0gDJdPjQJYuyj3vYKPJ3RXNRQaA-Y7eug=
>>
>> I have modified inputs and process, but it essentially is very similar
>> to what's described in that paper.
>>
>> While I have no problem with sharing what I have so far, this is
>> still very much work in progress, and things keep constantly changing
>> based on comments I receive from reviewers and Greg, so I want to
>> reach a more stable point before trying to explain things and change
>> my mind the day after :)
>>
>> If anyone is really interested in seeing the guts of this mess I
>> currently have I can push it to github, but bear in mind that in it's
>> current state it's very custom to the configuration I have, and is
>> a borderline unreadable mix of bash scripts and LUA.
>>
>> Ideally it'll all get cleaned up and pushed anyways once I feel
>> comfortable with the quality of the process.
>>
>At first I would focus on What and Why. Getting that information out
>and publicising it via that blogs, G+, meetings, etc. is essential.
>Reference to the current [WIP or not] heuristics is nice but can
>follow-up in due time. A placeholder must be available though.

I ended up getting a few more requests to dig into this, and I'm
always happy to get more eyes on it, so I'll clean it up slightly and
push whatever code I have to github and let anyone who wants see how
it works and improve it.

Should be done shortly after the upcoming holiday :)

>>> - Make the autoselect nominations _more_ distinct than the normal stable 
>>> ones.
>>>Maintainers will want to put more cognitive effort into the patches.
>>
>> So this came up before, and the participants of that thread agreed
>> that adding "AUTOSEL" in the patch prefix is sufficient. What else
>> would you suggest adding?
>>
>Being consistent [with existing stable nominations style] is good, but
>first focus* should be on making it noticeable and distinct.
>In other words - do _not_ be consistent.
>
>Flipping the order AUTOSEL PATCH, using WARN, NOTE or just dropping
>PATCH should help.
>People tend to read PATC. /xx: ... last words of commit message.
>
>Additionally, different template + a big note/warning in the email
>body is a good idea. Say:
>WARNING: This patch is nominated via the autosel procedure as defined at $ref.
>
>HTH
>Emil
>
>* Regardless if autosel patches default to "ACK to merge" or not.

I really didn't want to mess with the usual patch tagging ("[PATCH*")
since I'm afraid it'll interfere with people's mail rules (it would,
at least, in my case) and may cause people to miss this mail.

-- 

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

[PATCH] 4.15 vmgfx boot warning

[Woody Suwalski]

The 4.15 vmwgfx driver shows a warning during boot (32 bit x86)
It is caused by a mismatch between the result of vmw_enable_vblank() and 
what the drm_atomic_helper expects:

   /...
   ret = drm_crtc_vblank_get(crtc);
   WARN_ONCE(ret != -EINVAL, "driver forgot to call 
drm_crtc_vblank_off()\n");

   /...

Signed-off by: Woody Suwalski 

--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c    2017-11-22 
15:29:46.511674079 -0500
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c    2017-11-22 
15:30:35.344559592 -0500

@@ -1869,7 +1869,7 @@ u32 vmw_get_vblank_counter(struct drm_de
  */
 int vmw_enable_vblank(struct drm_device *dev, unsigned int pipe)
 {
-    return -ENOSYS;
+    return -EINVAL;
 }

 /**

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

Re: [PATCH 1/6] drm/i915: export the stolen region as a resource

[Ingo Molnar]

* Joonas Lahtinen  wrote:

> + Dave as a heads-up
> 
> On Thu, 2017-11-23 at 07:17 +0100, Ingo Molnar wrote:
> > * Matthew Auld  wrote:
> > 
> > > We duplicate the stolen discovery code in early-quirks and in i915,
> > > however if we just export the region as a resource from early-quirks we
> > > can nuke the duplication.
> > > 
> > > Suggested-by: Joonas Lahtinen 
> > > Suggested-by: Chris Wilson 
> > > Signed-off-by: Matthew Auld 
> > > Cc: Joonas Lahtinen 
> > > Cc: Chris Wilson 
> > > Cc: Paulo Zanoni 
> > > Cc: Ingo Molnar 
> > > Cc: H. Peter Anvin 
> > > Cc: dri-devel@lists.freedesktop.org
> > > Cc: x...@kernel.org
> > > ---
> > >  arch/x86/kernel/early-quirks.c |   6 ++
> > >  drivers/gpu/drm/i915/i915_gem_gtt.c|  51 +--
> > >  drivers/gpu/drm/i915/i915_gem_stolen.c | 109 
> > > +
> > >  include/drm/i915_drm.h |   3 +
> > >  4 files changed, 13 insertions(+), 156 deletions(-)
> > 
> > If it's truly identical:
> > 
> >   Acked-by: Ingo Molnar 
> 
> Are you fine with us merging this together with the rest of the series
> through the DRM tree once it's all reviewed?
> 
> That'd help not requiring so many backmerges.

Yes, sure, feel free - that's also where most of the relevant testing is done 
for 
the affected hardware.

Thanks,

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

[PATCH] drm/rockchip: dma-mapping: Use vma_pages helper

[Vasyl Gomonovych]

Use vma_pages function on vma object instead of explicit computation.
./drivers/gpu/drm/rockchip/rockchip_drm_gem.c:223:34-40: WARNING: Consider 
using vma_pages helper on vma
Generated by: scripts/coccinelle/api/vma_pages.cocci

Signed-off-by: Vasyl Gomonovych 
---
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index 1869c8bb76c8..1d9655576b6e 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -220,7 +220,7 @@ static int rockchip_drm_gem_object_mmap_iommu(struct 
drm_gem_object *obj,
 {
struct rockchip_gem_object *rk_obj = to_rockchip_obj(obj);
unsigned int i, count = obj->size >> PAGE_SHIFT;
-   unsigned long user_count = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
+   unsigned long user_count = vma_pages(vma);
unsigned long uaddr = vma->vm_start;
unsigned long offset = vma->vm_pgoff;
unsigned long end = user_count + offset;
-- 
1.9.1

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

Re: [PATCH 1/6] drm/i915: export the stolen region as a resource

[Ingo Molnar]

* Matthew Auld  wrote:

> We duplicate the stolen discovery code in early-quirks and in i915,
> however if we just export the region as a resource from early-quirks we
> can nuke the duplication.
> 
> Suggested-by: Joonas Lahtinen 
> Suggested-by: Chris Wilson 
> Signed-off-by: Matthew Auld 
> Cc: Joonas Lahtinen 
> Cc: Chris Wilson 
> Cc: Paulo Zanoni 
> Cc: Ingo Molnar 
> Cc: H. Peter Anvin 
> Cc: dri-devel@lists.freedesktop.org
> Cc: x...@kernel.org
> ---
>  arch/x86/kernel/early-quirks.c |   6 ++
>  drivers/gpu/drm/i915/i915_gem_gtt.c|  51 +--
>  drivers/gpu/drm/i915/i915_gem_stolen.c | 109 
> +
>  include/drm/i915_drm.h |   3 +
>  4 files changed, 13 insertions(+), 156 deletions(-)

If it's truly identical:

  Acked-by: Ingo Molnar 

Thanks,

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

Re: [PATCH] drm/vc4: Fix false positive WARN() backtrace on refcount_inc() usage

[Boris Brezillon]

On Wed, 22 Nov 2017 16:13:31 -0800
Eric Anholt  wrote:

> Boris Brezillon  writes:
> 
> > On Wed, 22 Nov 2017 13:16:08 -0800
> > Eric Anholt  wrote:
> >  
> >> Boris Brezillon  writes:
> >>   
> >> > With CONFIG_REFCOUNT_FULL enabled, refcount_inc() complains when it's
> >> > passed a refcount object that has its counter set to 0. In this driver,
> >> > this is a valid use case since we want to increment ->usecnt only when
> >> > the BO object starts to be used by real HW components and this is
> >> > definitely not the case when the BO is created.
> >> >
> >> > Fix the problem by using refcount_inc_not_zero() instead of
> >> > refcount_inc() and fallback to refcount_set(1) when
> >> > refcount_inc_not_zero() returns false. Note that this 2-steps operation
> >> > is not racy here because the whole section is protected by a mutex
> >> > which guarantees that the counter does not change between the
> >> > refcount_inc_not_zero() and refcount_set() calls.
> >> 
> >> If we're not following the model, and protecting the refcount by a
> >> mutex, shouldn't we just be using addition and subtraction instead of
> >> refcount's atomics?  
> >
> > Actually, this mutex is protecting the bo->madv value which has to be
> > checked when the counter reaches 0 (when decrementing) or 1 (when
> > incrementing). We just benefit from this protection here, but ideally
> > it would be better to have an refcount_inc_allow_zero() as suggested by
> > Daniel.  
> 
> Let me restate this to see if it makes sense: The refcount is always >=
> 0, this is is the only path that increases the refcount from 0 to 1, and
> it's (incidentally) protected by a mutex, so there's no race between the
> attempted increase from nonzero and the set from nonzero to 1.

Yep.

> 
> This seems fine to me as a bugfix.

The discussion is going on in the other thread, let's wait a bit
before taking a decision.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/ttm: don't attempt to use hugepages if dma32 requested (v2)

[Christian König]

Am 23.11.2017 um 03:41 schrieb Dave Airlie:

From: Dave Airlie 

The commit below introduced thp support for ttm allocations, however it didn't
take into account the case where dma32 was requested. Some drivers always 
request
dma32, and the bochs driver is one of those.

This fixes an oops:

[   30.108507] [ cut here ]
[   30.108920] kernel BUG at ./include/linux/gfp.h:408!
[   30.109356] invalid opcode:  [#1] SMP
[   30.109700] Modules linked in: fuse nf_conntrack_netbios_ns 
nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 
xt_conntrack devlink ip_set nfnetlink ebtable_nat ebtable_broute bridge 
ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle 
ip6table_raw ip6table_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 
nf_nat_ipv4 nf_nat nf_conntrack libcrc32c iptable_mangle iptable_raw 
iptable_security ebtable_filter ebtables ip6table_filter ip6_tables 
snd_hda_codec_generic kvm_intel kvm snd_hda_intel snd_hda_codec irqbypass ppdev 
snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm bochs_drm ttm joydev 
drm_kms_helper virtio_balloon snd_timer snd parport_pc drm soundcore parport 
i2c_piix4 nls_utf8 isofs squashfs zstd_decompress xxhash 8021q garp mrp stp llc 
virtio_net
[   30.115605]  virtio_console virtio_scsi crct10dif_pclmul crc32_pclmul 
crc32c_intel ghash_clmulni_intel serio_raw virtio_pci virtio_ring virtio 
ata_generic pata_acpi qemu_fw_cfg sunrpc scsi_transport_iscsi loop
[   30.117425] CPU: 0 PID: 1347 Comm: gnome-shell Not tainted 
4.15.0-0.rc0.git6.1.fc28.x86_64 #1
[   30.118141] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-2.fc27 04/01/2014
[   30.118866] task: 923a77e03380 task.stack: a78182228000
[   30.119366] RIP: 0010:__alloc_pages_nodemask+0x35e/0x430
[   30.119810] RSP: :a7818222bba8 EFLAGS: 00010202
[   30.120250] RAX: 0001 RBX: 014382c6 RCX: 0006
[   30.120840] RDX:  RSI: 0009 RDI: 
[   30.121443] RBP: 923a760d6000 R08:  R09: 0006
[   30.122039] R10: 0040 R11: 0300 R12: 923a729273c0
[   30.122629] R13:  R14:  R15: 923a7483d400
[   30.123223] FS:  7fe48da7dac0() GS:923a7cc0() 
knlGS:
[   30.123896] CS:  0010 DS:  ES:  CR0: 80050033
[   30.124373] CR2: 7fe457b73000 CR3: 78313000 CR4: 06f0
[   30.124968] Call Trace:
[   30.125186]  ttm_pool_populate+0x19b/0x400 [ttm]
[   30.125578]  ttm_bo_vm_fault+0x325/0x570 [ttm]
[   30.125964]  __do_fault+0x19/0x11e
[   30.126255]  __handle_mm_fault+0xcd3/0x1260
[   30.126609]  handle_mm_fault+0x14c/0x310
[   30.126947]  __do_page_fault+0x28c/0x530
[   30.127282]  do_page_fault+0x32/0x270
[   30.127593]  async_page_fault+0x22/0x30
[   30.127922] RIP: 0033:0x7fe48aae39a8
[   30.128225] RSP: 002b:7ffc21c4d928 EFLAGS: 00010206
[   30.128664] RAX: 7fe457b73000 RBX: 55cd4c1041a0 RCX: 7fe457b73040
[   30.129259] RDX: 0030 RSI:  RDI: 7fe457b73000
[   30.129855] RBP: 0300 R08: 000c R09: 0001
[   30.130457] R10: 0001 R11: 0246 R12: 55cd4c1041a0
[   30.131054] R13: 55cd4bdfe990 R14: 55cd4c104110 R15: 0400
[   30.131648] Code: 11 01 00 0f 84 a9 00 00 00 65 ff 0d 6d cc dd 44 e9 0f ff ff ff 
40 80 cd 80 e9 99 fe ff ff 48 89 c7 e8 e7 f6 01 00 e9 b7 fe ff ff <0f> 0b 0f ff 
e9 40 fd ff ff 65 48 8b 04 25 80 d5 00 00 8b 40 4c
[   30.133245] RIP: __alloc_pages_nodemask+0x35e/0x430 RSP: a7818222bba8
[   30.133836] ---[ end trace d4f1deb60784f40a ]---

v2: handle free path as well.

Reported-by: Laura Abbott 
Reported-by: Adam Williamson 
Fixes: 0284f1ead87463bc17cf5e81a24fc65c052486f3 (drm/ttm: add transparent huge 
page support for cached allocations v2)
Signed-off-by: Dave Airlie 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/ttm/ttm_page_alloc.c | 36 
  1 file changed, 20 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 316f831..b0551aa 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -744,12 +744,14 @@ static void ttm_put_pages(struct page **pages, unsigned 
npages, int flags,
}
  
  #ifdef CONFIG_TRANSPARENT_HUGEPAGE

-   for (j = 0; j < HPAGE_PMD_NR; ++j)
-   if (p++ != pages[i + j])
-   break;
+   if (!(flags & TTM_PAGE_FLAG_DMA32)) {
+   for (j = 0; j < HPAGE_PMD_NR; ++j)
+   if (p++ != pages[i + j])
+

Re: [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

[Christian König]

Am 22.11.2017 um 18:27 schrieb Boris Ostrovsky:

On 11/22/2017 11:54 AM, Christian König wrote:

Am 22.11.2017 um 17:24 schrieb Boris Ostrovsky:

On 11/22/2017 05:09 AM, Christian König wrote:

Am 21.11.2017 um 23:26 schrieb Boris Ostrovsky:

On 11/21/2017 08:34 AM, Christian König wrote:

Hi Boris,

attached are two patches.

The first one is a trivial fix for the infinite loop issue, it now
correctly aborts the fixup when it can't find address space for the
root window.

The second is a workaround for your board. It simply checks if there
is exactly one Processor Function to apply this fix on.

Both are based on linus current master branch. Please test if they
fix
your issue.

Yes, they do fix it but that's because the feature is disabled.

Do you know what the actual problem was (on Xen)?

I still haven't understood what you actually did with Xen.

When you used PCI pass through with those devices then you have made a
major configuration error.

When the problem happened on dom0 then the explanation is most likely
that some PCI device ended up in the configured space, but the routing
was only setup correctly on one CPU socket.

The problem is that dom0 can be (and was in my case() booted with less
than full physical memory and so the "rest" of the host memory is not
necessarily reflected in iomem. Your patch then tried to configure that
memory for MMIO and the system hang.

And so my guess is that this patch will break dom0 on a single-socket
system as well.

Oh, thanks!

I've thought about that possibility before, but wasn't able to find a
system which actually does that.

May I ask why the rest of the memory isn't reported to the OS?

That memory doesn't belong to the OS (dom0), it is owned by the hypervisor.


Sounds like I can't trust Linux resource management and probably need
to read the DRAM config to figure things out after all.


My question is whether what you are trying to do should ever be done for
a guest at all (any guest, not necessarily Xen).


The issue is probably that I don't know enough about Xen: What exactly 
is dom0? My understanding was that dom0 is the hypervisor, but that 
seems to be incorrect.


The issue is that under no circumstances *EVER* a virtualized guest 
should have access to the PCI devices marked as "Processor Function" on 
AMD platforms. Otherwise it is trivial to break out of the virtualization.


When dom0 is something like the system domain with all hardware access 
then the approach seems legitimate, but then the hypervisor should 
report the stolen memory to the OS using the e820 table.


When the hypervisor doesn't do that and the Linux kernel isn't aware 
that there is memory at a given location mapping PCI space there will 
obviously crash the hypervisor.


Possible solutions as far as I can see are either disabling this feature 
when we detect that we are a Xen dom0, scanning the DRAM settings to 
update Linux resource handling or fixing Xen to report stolen memory to 
the dom0 OS as reserved.


Opinions?

Thanks,
Christian.



-boris



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