[radeon-alex:amd-staging-4.11 1058/1085] cc1: error: unrecognized command line option '-mhard-float'

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-4.11
head:   c285c73f2213f503a93aa142fff186e160b4a371
commit: a37dcf9989ad11333dbbfef57dc4b611ce4d85a9 [1058/1085] 
drm/amdgpu/display: Enable DCN in DC
config: tile-allmodconfig (attached as .config)
compiler: tilegx-linux-gcc (GCC) 4.6.2
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout a37dcf9989ad11333dbbfef57dc4b611ce4d85a9
# save the attached .config to linux build tree
make.cross ARCH=tile 

All errors (new ones prefixed by >>):

>> cc1: error: unrecognized command line option '-mhard-float'
>> cc1: error: unrecognized command line option '-msse'
>> cc1: error: unrecognized command line option '-mpreferred-stack-boundary=4'

---
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: nouveau "eDP-1: EDID is invalid" regression after 4.11 with HP ZBook 15 G3

[Tommi Rantala]

2017-05-15 3:03 GMT+03:00 Ben Skeggs :
> On 05/15/2017 01:10 AM, Tommi Rantala wrote:
>>
>> Hi,
>
> Hey Tommi,
>
> Thanks for bisecting this.  It's rather unexpected that you should be seeing
> problems here, but, the commit makes sense for it at least.
>
> Are you able to get me new kernel logs of both before and after this patch
> with "log_buf_len=8M drm.debug=0x14
> nouveau.debug=disp=trace,i2c=trace,bios=trace" please?

Hi Ben,

Before:
https://www.dropbox.com/s/b2namqtqvzv5ppp/trace.4.10.0-tr-10409-g5c68d91?dl=1

After:
https://www.dropbox.com/s/9url8qdo15959fy/trace.4.10.0-tr-10410-gdf8dc97?dl=1

-Tommi

> Thanks,
> Ben.
>
>
>>
>> Bisected this to:
>>
>> commit df8dc97cd17269474344d73cc02739532c468d04
>> Author: Ben Skeggs 
>> Date:   Wed Mar 1 09:42:04 2017 +1000
>>
>> drm/nouveau/kms/nv50: use drm core i2c-over-aux algorithm
>>
>> I'm not entirely sure NVKM needs to support this now, but I haven't
>> removed it as of yet just in case it's needed from DEVINIT scripts
>> where DRM isn't available.
>>
>> Signed-off-by: Ben Skeggs 
>>
>>
>> dmesg after boot with drm.debug enabled:
>>
>> v4.10-10409-g5c68d91 (still works):
>> http://termbin.com/b0is
>>
>> v4.10-10410-gdf8dc97 (failure):
>> http://termbin.com/j6lq
>>
>>
>> Tommi
>>
>>
>> 2017-05-10 11:24 GMT+03:00 Tommi Rantala :
>>>
>>> Hi,
>>>
>>> The HP ZBook 15 G3 laptop builtin display (eDP-1) does not work
>>> correctly with v4.11-11413-g2868b25.
>>>
>>> When booting the laptop, the resolution seems to be limited to
>>> 1024x768, and gnome-session segfaults.
>>>
>>> Up to 4.11 the display works just fine in 1920x1080 mode.
>>>
>>> I'm seeing this in the kernel logs:
>>>
>>> nouveau :01:00.0: eDP-1: EDID is invalid:
>>>  [00] BAD  00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
>>>  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>>  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff 84 53 54
>>>  [00] BAD  66 69 50 55 57 66 74 49 48 ff ff ff ff ff ff ff
>>>  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>>  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>>  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>>  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff 00 00 ff 00 ff
>>> nouveau :01:00.0: DRM: DDC responded, but no EDID for eDP-1
>>> [drm] Cannot find any crtc or sizes - going 1024x768
>>>
>>>
>>> $ lspci | grep NVIDIA
>>> 01:00.0 VGA compatible controller: NVIDIA Corporation GM107GLM [Quadro
>>> M2000M] (rev a2)
>>>
>>> Any ideas, or should I bisect?
>>>
>>> 4.11 dmesg & xrandr output:
>>> https://pastebin.com/raw/P9LGP7e1
>>>
>>> 4.11-11413-g2868b25 dmesg:
>>> https://pastebin.com/raw/QBT9mMua
>>>
>>> -Tommi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [drm:qxl] BUG: sleeping function called from invalid context - qxl_bo_kmap_atomic_page()...splat

[Gabriel Krisman Bertazi]

Mike Galbraith  writes:

> On Tue, 2017-05-09 at 04:37 +0200, Mike Galbraith wrote:
>> On Mon, 2017-05-08 at 16:48 -0300, Gabriel Krisman Bertazi wrote:
>> 
>> > Thanks for reporting this.  Can you confirm the following patch prevents
>> > the issue?
>> 
>> Nope, it still gripes.
>
> The reason for this gripe is that we find that we don't have memory
> reserved.. a tad too late.
>

Thanks for the info.

Sorry I wasn't able to get back to this last week.  I'll try to get
another patch for -rc2.

> Xorg-2252  [000]    135.409756: qxl_release_map 
> <-qxl_cursor_atomic_update
> Xorg-2252  [000]    135.409756: qxl_bo_kmap_atomic_page 
> <-qxl_release_map
> Xorg-2252  [000]    135.409757: qxl_bo_kmap_atomic_page: ENTER
> Xorg-2252  [000]    135.409757: ttm_mem_io_lock 
> <-qxl_bo_kmap_atomic_page
> Xorg-2252  [000]    135.409757: ttm_mem_io_reserve 
> <-qxl_bo_kmap_atomic_page
> Xorg-2252  [000]    135.409757: qxl_ttm_io_mem_reserve 
> <-ttm_mem_io_reserve
> Xorg-2252  [000]    135.409757: ttm_mem_io_unlock 
> <-qxl_bo_kmap_atomic_page
> Xorg-2252  [000]    135.409757: qxl_bo_kmap_atomic_page: 
> PREEMPTION DISABLED
> Xorg-2252  [000] ...1   135.409758: qxl_bo_kmap 
> <-qxl_cursor_atomic_update
> Xorg-2252  [000] ...1   135.409758: ttm_bo_kmap <-qxl_bo_kmap  
> <== too late
> Xorg-2252  [000] ...1   135.409758: ttm_mem_io_reserve 
> <-ttm_bo_kmap
> Xorg-2252  [000] ...1   135.409758: qxl_ttm_io_mem_reserve 
> <-ttm_mem_io_reserve
> Xorg-2252  [000] ...1   135.409759: ioremap_nocache <-ttm_bo_kmap 
> <== game over
> Xorg-2252  [000] ...1   135.409759: __ioremap_caller 
> <-ioremap_nocache
> Xorg-2252  [000] ...1   135.409759: walk_system_ram_range 
> <-__ioremap_caller
> Xorg-2252  [000] ...1   135.409759: find_next_iomem_res 
> <-walk_system_ram_range
> Xorg-2252  [000] ...1   135.409759: _raw_read_lock 
> <-find_next_iomem_res
> Xorg-2252  [000] ...1   135.409760: reserve_memtype 
> <-__ioremap_caller
> Xorg-2252  [000] ...1   135.409760: pat_pagerange_is_ram 
> <-reserve_memtype
> Xorg-2252  [000] ...1   135.409761: walk_system_ram_range 
> <-pat_pagerange_is_ram
> Xorg-2252  [000] ...1   135.409761: find_next_iomem_res 
> <-walk_system_ram_range
> Xorg-2252  [000] ...1   135.409761: _raw_read_lock 
> <-find_next_iomem_res
> Xorg-2252  [000] ...1   135.409761: kmem_cache_alloc_trace 
> <-reserve_memtype
> Xorg-2252  [000] ...1   135.409761: __might_sleep 
> <-kmem_cache_alloc_trace
> Xorg-2252  [000] ...1   135.409762: ___might_sleep <-__might_sleep

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

Re: [PATCH v2 6/8] drm: Introduce drm_bridge_mode_valid()

[Archit Taneja]

On 05/12/2017 04:31 PM, Laurent Pinchart wrote:

Hi Archit,

On Friday 12 May 2017 16:20:07 Archit Taneja wrote:

On 05/12/2017 03:08 PM, Laurent Pinchart wrote:

On Wednesday 10 May 2017 17:14:33 Daniel Vetter wrote:

On Wed, May 10, 2017 at 04:41:09PM +0300, Ville Syrjälä wrote:

On Tue, May 09, 2017 at 06:00:13PM +0100, Jose Abreu wrote:

Introduce a new helper function which calls mode_valid() callback
for all bridges in an encoder chain.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Alexey Brodkin 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Dave Airlie 
Cc: Andrzej Hajda 
Cc: Archit Taneja 
---

 drivers/gpu/drm/drm_bridge.c | 33 +
 include/drm/drm_bridge.h |  2 ++
 2 files changed, 35 insertions(+)

diff --git a/drivers/gpu/drm/drm_bridge.c
b/drivers/gpu/drm/drm_bridge.c
index 86a7637..dc8cdfe 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -206,6 +206,39 @@ bool drm_bridge_mode_fixup(struct drm_bridge
*bridge,

 EXPORT_SYMBOL(drm_bridge_mode_fixup);

 /**

+ * drm_bridge_mode_valid - validate the mode against all bridges in
the
+ *encoder chain.
+ * @bridge: bridge control structure
+ * @mode: desired mode to be validated
+ *
+ * Calls _bridge_funcs.mode_valid for all the bridges in the
encoder
+ * chain, starting from the first bridge to the last. If at least one
bridge + * does not accept the mode the function returns the error
code.
+ *
+ * Note: the bridge passed should be the one closest to the encoder.
+ *
+ * RETURNS:
+ * MODE_OK on success, drm_mode_status Enum error code on failure
+ */
+enum drm_mode_status drm_bridge_mode_valid(struct drm_bridge *bridge,
+  const struct

drm_display_mode


*mode)


+{
+   enum drm_mode_status ret = MODE_OK;
+
+   if (!bridge)
+   return ret;
+
+   if (bridge->funcs->mode_valid)
+   ret = bridge->funcs->mode_valid(bridge, mode);
+
+   if (ret != MODE_OK)
+   return ret;
+
+   return drm_bridge_mode_valid(bridge->next, mode);


Looks like it should be pretty trivial to avoid the recursion.

Am I correct in interpreting this that bridges have some kind of
a hand rolled linked list implementation? Reusing the standard
linked lists would allow you to use list_for_each() etc.


Yeah it's a hand-rolled list, but current hw also has a bridge nesting
depth of 2, so it really doesn't matter. I guess once we have real long
chains of bridges we can fix this (and just using list_head sounds like a
great idea).


Even if not really needed right now, it's a pretty easy cleanup, if Jose
has time to handle it in v3 of this series let's not postpone it ;-)


jfyi, some of the bridge functions call the ops from the last bridge in the
chain to first, so we'd need to use list_for_each_entry_prev() (or something
like that) for them.


And now that I think about it, for some of the operations (especially
enable/disable) I believe that the bridge should be able to decide whether to
call the next/previous bridge first or to configure its hardware first. I can
image bridges that need the previous bridge in the chain to provide a valid
clock before they get started, as well as bridges that need to be started with
the incoming video signal stopped.


I guess converting into list would be a good start to achieve this. We'd 
probably
need to extend/redo the drm_bridge_attach() API to tweak the order in the which
the ops are called.

Thanks,
Archit

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101044] I915 driver caused VGA got no ignal after plug-out then plug-in the VGA cable

[bugzilla-daemon]

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

Bug ID: 101044
   Summary: I915 driver caused VGA got no ignal after plug-out
then plug-in the VGA cable
   Product: Mesa
   Version: unspecified
  Hardware: Other
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: highest
 Component: Drivers/DRI/i915
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: amy.s...@advantech.com.tw
QA Contact: dri-devel@lists.freedesktop.org
 Group: Mesa Security

Hi Sir,


We have a product which uses Intel Xeon Processor E3 v5 CPU, we found an issue
of I915 graphic driver. The testing OS is CentOS7 with kernel 3.10.0-514.10.2 &
the OS only has the text mode, after boot up we plug-out the VGA cable and then
plug-in the VGA cable again, then the VGA screen shows no signal. On the same
OS we remove the I915 module from initramfs & do the same plug-out & plug-in
test again, the VGA screen can still got the signal back.

We also do the same test on WIN10 PRO X64, it doesn’t have the VGA no signal
issue. It seems the root cause is the I915 driver, could you assist to check it
or do you have newest I915 driver source code for us to do the test? Thank you!

Amy Shih
amy.s...@advantech.com.tw

-- 
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-staging-4.11 954/1085] sound/soc//amd/raven/acp3x-pcm-dma.c:246:3: error: implicit declaration of function 'page_to_phys'

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-4.11
head:   c285c73f2213f503a93aa142fff186e160b4a371
commit: abb115931046498039111820de7b6b578c4cce8d [954/1085] ASoC: AMD: enable 
ACP3x drivers build
config: tile-allmodconfig (attached as .config)
compiler: tilegx-linux-gcc (GCC) 4.6.2
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout abb115931046498039111820de7b6b578c4cce8d
# save the attached .config to linux build tree
make.cross ARCH=tile 

All errors (new ones prefixed by >>):

   In file included from sound/soc//amd/raven/acp3x-pcm-dma.c:26:0:
   sound/soc//amd/raven/acp3x.h: In function 'rv_readl':
   sound/soc//amd/raven/acp3x.h:28:2: error: implicit declaration of function 
'readl'
   sound/soc//amd/raven/acp3x.h: In function 'rv_writel':
   sound/soc//amd/raven/acp3x.h:33:2: error: implicit declaration of function 
'writel'
   sound/soc//amd/raven/acp3x-pcm-dma.c: In function 'config_acp3x_dma':
>> sound/soc//amd/raven/acp3x-pcm-dma.c:246:3: error: implicit declaration of 
>> function 'page_to_phys'
   sound/soc//amd/raven/acp3x-pcm-dma.c: In function 'acp3x_audio_probe':
   sound/soc//amd/raven/acp3x-pcm-dma.c:638:2: error: implicit declaration of 
function 'devm_ioremap'
   sound/soc//amd/raven/acp3x-pcm-dma.c:638:20: warning: assignment makes 
pointer from integer without a cast [enabled by default]
   cc1: some warnings being treated as errors

vim +/page_to_phys +246 sound/soc//amd/raven/acp3x-pcm-dma.c

947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29  230   /* 8 scratch registers 
used to map one 64 bit address.
947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29  231* For 2 pages (4096 * 
2 bytes), it will be 16 registers.
947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29  232*/
947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29  233   if (direction == 
SNDRV_PCM_STREAM_PLAYBACK)
947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29  234   val = 0;
947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29  235   else
947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29  236   val = 16;
947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29  237  
947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29  238   /* Group Enable */
947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29  239   
rv_writel(ACP_SRAM_PTE_OFFSET | BIT(31), rtd->acp3x_base +
947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29  240   
mmACPAXI2AXI_ATU_BASE_ADDR_GRP_1);
947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29  241   
rv_writel(PAGE_SIZE_4K_ENABLE, rtd->acp3x_base +
947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29  242   
mmACPAXI2AXI_ATU_PAGE_SIZE_GRP_1);
947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29  243  
947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29  244   for (page_idx = 0; 
page_idx < rtd->num_pages; page_idx++) {
947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29  245   /* Load the low 
address of page int ACP SRAM through SRBM */
947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29 @246   addr = 
page_to_phys(pg);
947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29  247   low = 
lower_32_bits(addr);
947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29  248   high = 
upper_32_bits(addr);
947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29  249  
947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29  250   rv_writel(low, 
rtd->acp3x_base + mmACP_SCRATCH_REG_0 + val);
947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29  251   high |= BIT(31);
947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29  252   rv_writel(high, 
rtd->acp3x_base + mmACP_SCRATCH_REG_0 + val
947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29  253   
+ 4);
947d2f9f Maruthi Srinivas Bayyavarapu 2017-03-29  254   /* Move to next 
physically contiguos page */

:: The code at line 246 was first introduced by commit
:: 947d2f9fc0cb6379ede8593e3ca0107f87fc4ce9 ASoC: AMD: add ACP3x PCM driver 
DMA ops

:: TO: Maruthi Srinivas Bayyavarapu 
:: CC: Alex Deucher 

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

[git pull] drm fixes for v4.12-rc1

[Dave Airlie]

Hi Linus,

Some fixes that it would be good to have in rc1. It contains the i915
quiet fix that you reported.

It also has an amdgpu fixes pull, with lots of ongoing work on Vega10
which is new in this kernel and is preliminary support so may have a
fair bit of movement.

Otherwise a few non-Vega10 AMD fixes, one EDID fix and some nouveau
regression fixers.

Dave.

The following changes since commit 09d79d103371b1b7ea70ea7f9c05ac207ef22f5d:

  Merge tag 'docs-4.12-2' of git://git.lwn.net/linux (2017-05-11 11:29:52 -0700)

are available in the git repository at:

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

for you to fetch changes up to 7b8cd3363e8a0e6b90a7067f75aaeaae61a7d612:

  drm/i915: Make vblank evade warnings optional (2017-05-12 14:28:02 +1000)


amd, nouveau, one i915 and one EDID fix for v4.12-rc1


Alex Deucher (12):
  drm/amdgpu: fix spelling in header comment
  drm/amdgpu: bump version number to note race fix and new fence
functionality
  Revert "drm/amd/amdgpu: Set VCE/UVD off during late init"
  drm/amdgpu: update revision id settings for BR/ST
  drm/amdgpu/gfx9: use actual gpu num se setting for ngg allocation
  drm/amdgpu/gfx9: fix typo in mpd init
  drm/amdgpu/gfx9: add additional MQD initialization
  drm/amdgpu/gfx: drop max_gs_waves_per_vgt
  drm/amdgpu/gfx9: derive tile pipes from golden settings
  drm/amdgpu/atomfirmware: add function to update engine hang status
  drm/amdgpu/soc15: use atomfirmware for setting bios scratch for reset
  drm/amdgpu: add some additional vega10 pci ids

Alex Xie (8):
  drm/amdgpu: Fix use of interruptible waiting
  drm/amdgpu: Fix use of interruptible waiting
  drm/amdgpu: Fix use of interruptible waiting
  drm/amdgpu: Fix use of interruptible waiting
  drm/amdgpu: Real return value can be over-written when clean up
  drm/amdgpu: Fix use of interruptible waiting
  drm/amdgpu: Fix use of interruptible waiting
  drm/amdgpu: Fix use of interruptible waiting

Ben Skeggs (10):
  drm/nouveau/kms/nv50: remove pointless argument to window
atomic_check_acquire()
  drm/nouveau/kms/nv50: fix source-rect-only plane updates
  drm/nouveau/kms/nv50: skip core channel cursor update on
position-only changes
  drm/nouveau/fb/ram/gf100-: remove 0x10f200 read
  drm/nouveau/core: fix static checker warning
  drm/nouveau/tmr: ack interrupt before processing alarms
  drm/nouveau/tmr: handle races with hw when updating the next alarm time
  drm/nouveau/tmr: fix corruption of the pending list when
rescheduling an alarm
  drm/nouveau/tmr: avoid processing completed alarms when adding a new one
  drm/nouveau/therm: remove ineffective workarounds for alarm bugs

Christian König (14):
  drm/amdgpu: add VMHUB to ring association
  drm/amdgpu: drop VMID per ring tracking
  drm/amdgpu: split VMID management by VMHUB
  drm/amdgpu: invalidate only the currently needed VMHUB v2
  drm/amdgpu: assign VM invalidation engine manually v2
  drm/amdgpu: allow concurrent VM flushes
  drm/amdgpu: trace the vmhub in grab_id as well
  drm/amdgpu: trace vm hub during flush as well v2
  drm/radeon: force the UVD DPB into VRAM as well
  drm/amdgpu: fix coding style and printing in amdgpu_doorbell_init
  drm/amdgpu: fix amdgpu_vm_clear_freed v2
  drm/amdgpu: fix amdgpu_ttm_bo_eviction_valuable
  drm/amdgpu: fix VM clearing in amdgpu_gem_object_close
  drm/amdgpu: remove unused and mostly unimplemented CGS functions v2

Chunming Zhou (8):
  drm/amdgpu: add gtt print like vram when dump mm table V2
  drm/amdgpu: increase gtt size to 3GB by default v2
  drm/amdgpu: fix no-vmid job
  drm/amdgpu: fix gpu reset crash
  drm/amdgpu: fix NULL pointer error
  drm/amdgpu: fix deadlock of reservation between cs and gpu reset v2
  drm/amd: fix init order of sched job
  drm/amdgpu: fix dependency issue

Daniel Wang (2):
  drm/amdgpu/psp: skip loading SDMA/RLCG under SRIOV VF
  drm/amdgpu/vce4: fix a PSP loading VCE issue

Dave Airlie (3):
  Merge tag 'drm-misc-next-fixes-2017-05-05' of
git://anongit.freedesktop.org/git/drm-misc into drm-next
  Merge branch 'drm-next-4.12' of
git://people.freedesktop.org/~agd5f/linux into drm-next
  Merge branch 'linux-4.12' of git://github.com/skeggsb/linux into drm-next

Evan Quan (1):
  drm/amdgpu: update smu9 driver interface

Frank Min (7):
  drm/amdgpu/vce4: update VCE initialization sequence for SRIOV
  drm/amdgpu/vce4: enable ring & ib test for sriov
  drm/amdgpu/vce4: move mm table constructions functions into
mmsch header file
  drm/amdgpu/uvd7: add sriov uvd initialization sequences
  drm/amdgpu/uvd7: add uvd doorbell initialization for sriov
  drm/amdgpu/uvd7: add 

Re: [git pull] drm fixes for v4.12-rc1

[Linus Torvalds]

On Thu, May 11, 2017 at 11:00 PM, Dave Airlie  wrote:
>
> It also has an amdgpu fixes pull, with lots of ongoing work on Vega10
> which is new in this kernel and is preliminary support so may have a
> fair bit of movement.

Note: I will *not* be taking these kinds of pull requests after rc1.

If Vega10 is in such bad shape that it will need this kind of stuff
and isn't worth shipping without them in 4.12, I will take a *oneline*
that just disables it.

So no "thousands of lines of fixes for a new driver".

Being new to 4.12 isn't an excuse for crazy stuff after the merge
window. If it will need more of this kind of attention, all it means
is that it shouldn't have been sent to me at all in the first place.

The drm subsystem is still on my "no more of this shit" list, so I'm
going to be very unforgiving of big pull requests when they aren't
appropriate.

 Linus

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
--
___
Dri-devel mailing list
dri-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v7 10/13] drm/sun4i: tcon: add support for V3s TCON

[Icenowy Zheng]

Allwinner V3s SoC features a TCON without channel 1.

Add support for it.

Signed-off-by: Icenowy Zheng 
Reviewed-by: Chen-Yu Tsai 
---
Changes in v7:
- Added Chen-Yu's Reviewed-by.

 drivers/gpu/drm/sun4i/sun4i_drv.c  | 3 ++-
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 5 +
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 4a979d17ddaa..1dd1948025d2 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -178,7 +178,8 @@ static bool sun4i_drv_node_is_tcon(struct device_node *node)
return of_device_is_compatible(node, "allwinner,sun5i-a13-tcon") ||
of_device_is_compatible(node, "allwinner,sun6i-a31-tcon") ||
of_device_is_compatible(node, "allwinner,sun6i-a31s-tcon") ||
-   of_device_is_compatible(node, "allwinner,sun8i-a33-tcon");
+   of_device_is_compatible(node, "allwinner,sun8i-a33-tcon") ||
+   of_device_is_compatible(node, "allwinner,sun8i-v3s-tcon");
 }
 
 static int compare_of(struct device *dev, void *data)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 288275802f92..add349f5e012 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -601,11 +601,16 @@ static const struct sun4i_tcon_quirks sun8i_a33_quirks = {
/* nothing is supported */
 };
 
+static const struct sun4i_tcon_quirks sun8i_v3s_quirks = {
+   /* nothing is supported */
+};
+
 static const struct of_device_id sun4i_tcon_of_table[] = {
{ .compatible = "allwinner,sun5i-a13-tcon", .data = _a13_quirks },
{ .compatible = "allwinner,sun6i-a31-tcon", .data = _a31_quirks },
{ .compatible = "allwinner,sun6i-a31s-tcon", .data = _a31s_quirks 
},
{ .compatible = "allwinner,sun8i-a33-tcon", .data = _a33_quirks },
+   { .compatible = "allwinner,sun8i-v3s-tcon", .data = _v3s_quirks },
{ }
 };
 MODULE_DEVICE_TABLE(of, sun4i_tcon_of_table);
-- 
2.12.2

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

[PATCH v7 09/13] drm/sun4i: Add compatible string for V3s display engine

[Icenowy Zheng]

Allwinner V3s features the new "Display Engine 2.0", which can now also
be driven with our subdrivers in sun4i-drm.

Add the compatible string for in sun4i_drv.c, in order to make the
display engine and its components probed.

Signed-off-by: Icenowy Zheng 
---
 drivers/gpu/drm/sun4i/sun4i_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 35cad9cb44c5..4a979d17ddaa 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -296,6 +296,7 @@ static const struct of_device_id sun4i_drv_of_table[] = {
{ .compatible = "allwinner,sun6i-a31-display-engine" },
{ .compatible = "allwinner,sun6i-a31s-display-engine" },
{ .compatible = "allwinner,sun8i-a33-display-engine" },
+   { .compatible = "allwinner,sun8i-v3s-display-engine" },
{ }
 };
 MODULE_DEVICE_TABLE(of, sun4i_drv_of_table);
-- 
2.12.2

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

Re: [PATCH v2] drm/tegra: Check size of a submitted command buffer

[Dmitry Osipenko]

On 14.05.2017 15:27, Mikko Perttunen wrote:
> On 05/12/2017 10:29 PM, Dmitry Osipenko wrote:
>> If command buffer claims a number of words that is higher than its BO can
>> fit and a relocation lays past the BO, a kernel OOPS will be fired on that
>> relocation address patching. This was triggered by an opentegra Xorg driver
>> that erroneously pushed too many commands to the pushbuf.
>>
>> [   46.829393] Unable to handle kernel paging request at virtual address 
>> f09b2000
>> ...
>> [] (host1x_job_pin) from [] 
>> (tegra_drm_submit+0x474/0x510)
>> [] (tegra_drm_submit) from [] (tegra_submit+0x50/0x6c)
>> [] (tegra_submit) from [] (drm_ioctl+0x1e4/0x3ec)
>> [] (drm_ioctl) from [] (do_vfs_ioctl+0x9c/0x8e4)
>> [] (do_vfs_ioctl) from [] (SyS_ioctl+0x34/0x5c)
>> [] (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x3c)
>>
>> Signed-off-by: Dmitry Osipenko 
>> ---
>>
>> v2: Take into account the cmdbuf.offset
>>
>>  drivers/gpu/drm/tegra/drm.c | 18 ++
>>  1 file changed, 14 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
>> index 732c8d98044f..9ad4ac7c08d1 100644
>> --- a/drivers/gpu/drm/tegra/drm.c
>> +++ b/drivers/gpu/drm/tegra/drm.c
>> @@ -361,20 +361,30 @@ int tegra_drm_submit(struct tegra_drm_context *context,
>>
>>  while (num_cmdbufs) {
>>  struct drm_tegra_cmdbuf cmdbuf;
>> -struct host1x_bo *bo;
>> +struct drm_gem_object *gem;
>> +struct tegra_bo *bo;
>>
>>  if (copy_from_user(, cmdbufs, sizeof(cmdbuf))) {
>>  err = -EFAULT;
>>  goto fail;
>>  }
>>
>> -bo = host1x_bo_lookup(file, cmdbuf.handle);
>> -if (!bo) {
>> +gem = drm_gem_object_lookup(file, cmdbuf.handle);
>> +if (!gem) {
>>  err = -ENOENT;
>>  goto fail;
>>  }
>>
>> -host1x_job_add_gather(job, bo, cmdbuf.words, cmdbuf.offset);
>> +drm_gem_object_unreference_unlocked(gem);
>> +
>> +if (cmdbuf.offset + cmdbuf.words * 4 > gem->size) {
>> +err = -EINVAL;
>> +goto fail;
>> +}
> 
> Nasty bug! Well found. Two points: the arithmetic here could overflow, so
> userspace could supply some large values for offset/words and this check would
> not catch it. A fix would be to do the arithmetic in 64-bit. Also, looking at
> the code closer, I can't see any bounds checking for relocs either.. That code
> (host1x_reloc_copy_from_user) is the other place using host1x_bo_lookup, so we
> could e.g. change host1x_bo_lookup to take offset and words parameters and
> verify those at the same time.
> 
Good point, unfortunately there are a lot of ways to abuse the staging API on
the IOMMU-less Tegra20 right now.

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

[PATCH v2] drm/tegra: Correct idr_alloc() minimum id

[Dmitry Osipenko]

The client ID 0 is reserved by the host1x/cdma to mark the timeout timer
work as already been scheduled and context ID is used as the clients one.
This fixes spurious CDMA timeouts.

Fixes: bdd2f9cd10eb ("drm/tegra: Don't leak kernel pointer to userspace")
Signed-off-by: Dmitry Osipenko 
---

v2: Changed the commit description, now explains the cause of CDMA timeouts.

 drivers/gpu/drm/tegra/drm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index c5844a065681..489cb32453f7 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -548,7 +548,7 @@ static int tegra_client_open(struct tegra_drm_file *fpriv,
if (err < 0)
return err;
 
-   err = idr_alloc(>contexts, context, 0, 0, GFP_KERNEL);
+   err = idr_alloc(>contexts, context, 1, 0, GFP_KERNEL);
if (err < 0) {
client->ops->close_channel(context);
return err;
-- 
2.13.0

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

[PATCH v7 12/13] ARM: sun8i: v3s: add pinmux for LCD pins of V3s SoC

[Icenowy Zheng]

Allwinner V3s SoC features a set of pins that have functionality of RGB
LCD, the pins are at different pin ban than other SoCs.

Add pinctrl node for them.

Signed-off-by: Icenowy Zheng 
Acked-by: Chen-Yu Tsai 
---
Changes in v7:
- Dropped the trailing "@0" in rgb666 pinmux node name.
- Added Chen-Yu's ACK.

 arch/arm/boot/dts/sun8i-v3s.dtsi | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index b71b35734515..a7026517ed99 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -297,6 +297,15 @@
function = "i2c0";
};
 
+   lcd_rgb666_pins: lcd_rgb666 {
+   pins = "PE0", "PE1", "PE2", "PE3", "PE4",
+  "PE5", "PE6", "PE7", "PE8", "PE9",
+  "PE10", "PE11", "PE12", "PE13", "PE14",
+  "PE15", "PE16", "PE17", "PE18", "PE19",
+  "PE23", "PE24";
+   function = "lcd";
+   };
+
uart0_pins_a: uart0@0 {
pins = "PB8", "PB9";
function = "uart0";
-- 
2.12.2

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

[PATCH 03/13] docs: update old references for DocBook from the documentation

[Mauro Carvalho Chehab]

DocBook is mentioned several times at the documentation. Update
the obsolete references from it at the DocBook.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/PCI/MSI-HOWTO.txt|  2 +-
 Documentation/admin-guide/README.rst   |  6 ---
 Documentation/doc-guide/index.rst  |  1 -
 Documentation/doc-guide/sphinx.rst |  5 ---
 Documentation/fb/api.txt   |  4 +-
 Documentation/gpu/todo.rst |  2 +-
 Documentation/kernel-doc-nano-HOWTO.txt| 65 +-
 Documentation/process/changes.rst  | 26 +++-
 Documentation/process/howto.rst|  8 
 Documentation/process/kernel-docs.rst  | 34 +---
 Documentation/translations/ja_JP/howto.rst |  7 
 Documentation/translations/ko_KR/howto.rst |  7 
 12 files changed, 21 insertions(+), 146 deletions(-)

diff --git a/Documentation/PCI/MSI-HOWTO.txt b/Documentation/PCI/MSI-HOWTO.txt
index 1e37138027a3..618e13d5e276 100644
--- a/Documentation/PCI/MSI-HOWTO.txt
+++ b/Documentation/PCI/MSI-HOWTO.txt
@@ -186,7 +186,7 @@ must disable interrupts while the lock is held.  If the 
device sends
 a different interrupt, the driver will deadlock trying to recursively
 acquire the spinlock.  Such deadlocks can be avoided by using
 spin_lock_irqsave() or spin_lock_irq() which disable local interrupts
-and acquire the lock (see Documentation/DocBook/kernel-locking).
+and acquire the lock (see Documentation/kernel-hacking/locking.rst).
 
 4.5 How to tell whether MSI/MSI-X is enabled on a device
 
diff --git a/Documentation/admin-guide/README.rst 
b/Documentation/admin-guide/README.rst
index b96e80f79e85..b5343c5aa224 100644
--- a/Documentation/admin-guide/README.rst
+++ b/Documentation/admin-guide/README.rst
@@ -55,12 +55,6 @@ Documentation
contains information about the problems, which may result by upgrading
your kernel.
 
- - The Documentation/DocBook/ subdirectory contains several guides for
-   kernel developers and users.  These guides can be rendered in a
-   number of formats:  PostScript (.ps), PDF, HTML, & man-pages, among others.
-   After installation, ``make psdocs``, ``make pdfdocs``, ``make htmldocs``,
-   or ``make mandocs`` will render the documentation in the requested format.
-
 Installing the kernel source
 
 
diff --git a/Documentation/doc-guide/index.rst 
b/Documentation/doc-guide/index.rst
index 6fff4024606e..a7f95d7d3a63 100644
--- a/Documentation/doc-guide/index.rst
+++ b/Documentation/doc-guide/index.rst
@@ -10,7 +10,6 @@ How to write kernel documentation
sphinx.rst
kernel-doc.rst
parse-headers.rst
-   docbook.rst
 
 .. only::  subproject and html
 
diff --git a/Documentation/doc-guide/sphinx.rst 
b/Documentation/doc-guide/sphinx.rst
index 731334de3efd..84e8e8a9cbdb 100644
--- a/Documentation/doc-guide/sphinx.rst
+++ b/Documentation/doc-guide/sphinx.rst
@@ -15,11 +15,6 @@ are used to describe the functions and types and design of 
the code. The
 kernel-doc comments have some special structure and formatting, but beyond that
 they are also treated as reStructuredText.
 
-There is also the deprecated DocBook toolchain to generate documentation from
-DocBook XML template files under ``Documentation/DocBook``. The DocBook files
-are to be converted to reStructuredText, and the toolchain is slated to be
-removed.
-
 Finally, there are thousands of plain text documentation files scattered around
 ``Documentation``. Some of these will likely be converted to reStructuredText
 over time, but the bulk of them will remain in plain text.
diff --git a/Documentation/fb/api.txt b/Documentation/fb/api.txt
index d4ff7de85700..d52cf1e3b975 100644
--- a/Documentation/fb/api.txt
+++ b/Documentation/fb/api.txt
@@ -289,12 +289,12 @@ the FB_CAP_FOURCC bit in the fb_fix_screeninfo 
capabilities field.
 FOURCC definitions are located in the linux/videodev2.h header. However, and
 despite starting with the V4L2_PIX_FMT_prefix, they are not restricted to V4L2
 and don't require usage of the V4L2 subsystem. FOURCC documentation is
-available in Documentation/DocBook/v4l/pixfmt.xml.
+available in Documentation/media/uapi/v4l/pixfmt.rst.
 
 To select a format, applications set the grayscale field to the desired FOURCC.
 For YUV formats, they should also select the appropriate colorspace by setting
 the colorspace field to one of the colorspaces listed in linux/videodev2.h and
-documented in Documentation/DocBook/v4l/colorspaces.xml.
+documented in Documentation/media/uapi/v4l/colorspaces.rst.
 
 The red, green, blue and transp fields are not used with the FOURCC-based API.
 For forward compatibility reasons applications must zero those fields, and
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 1bdb7356a310..6162d0e9dc28 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -228,7 +228,7 @@ The DRM reference documentation is still 

Re: [PATCH] gpu: host1x: Initialize firewall class to the jobs one

[Mikko Perttunen]

Well spotted!

Reviewed-by: Mikko Perttunen 

On 05/14/2017 12:01 AM, Dmitry Osipenko wrote:

The commands stream is prepended by the jobs class on the CDMA submission,
so that explicitly setting a module class in the commands stream isn't
necessary. The firewall initializes its class to 0 and the command stream
that doesn't explicitly specify the class effectively bypasses the firewall.

Signed-off-by: Dmitry Osipenko 
---
 drivers/gpu/host1x/job.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
index 5f5f8ee6143d..d9933828fe87 100644
--- a/drivers/gpu/host1x/job.c
+++ b/drivers/gpu/host1x/job.c
@@ -504,7 +504,7 @@ static inline int copy_gathers(struct host1x_job *job, 
struct device *dev)
fw.dev = dev;
fw.reloc = job->relocarray;
fw.num_relocs = job->num_relocs;
-   fw.class = 0;
+   fw.class = job->class;

for (i = 0; i < job->num_gathers; i++) {
struct host1x_job_gather *g = >gathers[i];


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

Re: [PATCH v2] drm/tegra: Check size of a submitted command buffer

[Mikko Perttunen]

On 05/12/2017 10:29 PM, Dmitry Osipenko wrote:

If command buffer claims a number of words that is higher than its BO can
fit and a relocation lays past the BO, a kernel OOPS will be fired on that
relocation address patching. This was triggered by an opentegra Xorg driver
that erroneously pushed too many commands to the pushbuf.

[   46.829393] Unable to handle kernel paging request at virtual address 
f09b2000
...
[] (host1x_job_pin) from [] (tegra_drm_submit+0x474/0x510)
[] (tegra_drm_submit) from [] (tegra_submit+0x50/0x6c)
[] (tegra_submit) from [] (drm_ioctl+0x1e4/0x3ec)
[] (drm_ioctl) from [] (do_vfs_ioctl+0x9c/0x8e4)
[] (do_vfs_ioctl) from [] (SyS_ioctl+0x34/0x5c)
[] (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x3c)

Signed-off-by: Dmitry Osipenko 
---

v2: Take into account the cmdbuf.offset

 drivers/gpu/drm/tegra/drm.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 732c8d98044f..9ad4ac7c08d1 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -361,20 +361,30 @@ int tegra_drm_submit(struct tegra_drm_context *context,

while (num_cmdbufs) {
struct drm_tegra_cmdbuf cmdbuf;
-   struct host1x_bo *bo;
+   struct drm_gem_object *gem;
+   struct tegra_bo *bo;

if (copy_from_user(, cmdbufs, sizeof(cmdbuf))) {
err = -EFAULT;
goto fail;
}

-   bo = host1x_bo_lookup(file, cmdbuf.handle);
-   if (!bo) {
+   gem = drm_gem_object_lookup(file, cmdbuf.handle);
+   if (!gem) {
err = -ENOENT;
goto fail;
}

-   host1x_job_add_gather(job, bo, cmdbuf.words, cmdbuf.offset);
+   drm_gem_object_unreference_unlocked(gem);
+
+   if (cmdbuf.offset + cmdbuf.words * 4 > gem->size) {
+   err = -EINVAL;
+   goto fail;
+   }


Nasty bug! Well found. Two points: the arithmetic here could overflow, 
so userspace could supply some large values for offset/words and this 
check would not catch it. A fix would be to do the arithmetic in 64-bit. 
Also, looking at the code closer, I can't see any bounds checking for 
relocs either.. That code (host1x_reloc_copy_from_user) is the other 
place using host1x_bo_lookup, so we could e.g. change host1x_bo_lookup 
to take offset and words parameters and verify those at the same time.


Cheers,
Mikko


+
+   bo = to_tegra_bo(gem);
+   host1x_job_add_gather(job, >base,
+ cmdbuf.words, cmdbuf.offset);
num_cmdbufs--;
cmdbufs++;
}


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

[PATCH v7 00/13] Initial Allwinner Display Engine 2.0 Support

[Icenowy Zheng]

This patchset is the initial patchset for Allwinner DE2 support.

It contains the support of clocks in DE2 and the mixers in DE2.

The SoC used to develop this patchset is V3s, as V3s is the simplest
one of the SoCs that have DE2.

(Allwinner V3s features only one mixer, and its only video output is
RGB LCD, which is already supported in our TCON driver)

The last patch is only a testing patch, it shouldn't be merged; and
for the patch to be really usable, the RFC fix of the TCON driver [1]
is needed.

No HDMI, TV encoder or other internal bridges' support is included
in this patchset, which makes it currently not usable on H3. (For TVE
I have some code that made it working; for HDMI there is a driver by
Jernej Skrabec which is based on the dw-hdmi common code.)

Thanks to Jean-Francois Moine and Jernej Skrabec for their efforts
to discover the internal of DE2!

[1] https://lists.freedesktop.org/archives/dri-devel/2016-December/126264.html

Icenowy Zheng (13):
  dt-bindings: add binding for the Allwinner DE2 CCU
  clk: sunxi-ng: add support for DE2 CCU
  dt-bindings: add bindings for DE2 on V3s SoC
  drm/sun4i: return only planes for layers created
  drm/sun4i: abstract a engine type
  drm/sun4i: add a dedicated module for sun4i-backend and sun4i-layer
  drm/sun4i: add a Kconfig option for sun4i-backend
  drm/sun4i: add support for Allwinner DE2 mixers
  drm/sun4i: Add compatible string for V3s display engine
  drm/sun4i: tcon: add support for V3s TCON
  ARM: sun8i: v3s: add device nodes for DE2 display pipeline
  ARM: sun8i: v3s: add pinmux for LCD pins of V3s SoC
  [DO NOT MERGE] ARM: sun8i: v3s: enable LCD panel of Lichee Pi Zero

 .../devicetree/bindings/clock/sun8i-de2.txt|  31 ++
 .../bindings/display/sunxi/sun4i-drm.txt   |  26 +-
 arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts  |  36 ++
 arch/arm/boot/dts/sun8i-v3s.dtsi   |  96 +
 drivers/clk/sunxi-ng/Kconfig   |   5 +
 drivers/clk/sunxi-ng/Makefile  |   1 +
 drivers/clk/sunxi-ng/ccu-sun8i-de2.c   | 260 +
 drivers/clk/sunxi-ng/ccu-sun8i-de2.h   |  28 ++
 drivers/gpu/drm/sun4i/Kconfig  |  20 +
 drivers/gpu/drm/sun4i/Makefile |   9 +-
 drivers/gpu/drm/sun4i/sun4i_backend.c  |  72 ++--
 drivers/gpu/drm/sun4i/sun4i_backend.h  |  17 +-
 drivers/gpu/drm/sun4i/sun4i_crtc.c |  32 +-
 drivers/gpu/drm/sun4i/sun4i_crtc.h |   5 +-
 drivers/gpu/drm/sun4i/sun4i_drv.c  |   6 +-
 drivers/gpu/drm/sun4i/sun4i_drv.h  |   2 +-
 drivers/gpu/drm/sun4i/sun4i_layer.c|  21 +-
 drivers/gpu/drm/sun4i/sun4i_layer.h|   6 +-
 drivers/gpu/drm/sun4i/sun4i_tcon.c |  43 ++-
 drivers/gpu/drm/sun4i/sun4i_tv.c   |   9 +-
 drivers/gpu/drm/sun4i/sun8i_layer.c| 134 +++
 drivers/gpu/drm/sun4i/sun8i_layer.h|  36 ++
 drivers/gpu/drm/sun4i/sun8i_mixer.c| 412 +
 drivers/gpu/drm/sun4i/sun8i_mixer.h| 137 +++
 drivers/gpu/drm/sun4i/sunxi_engine.h   | 111 ++
 include/dt-bindings/clock/sun8i-de2.h  |  18 +
 include/dt-bindings/reset/sun8i-de2.h  |  14 +
 27 files changed, 1485 insertions(+), 102 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/sun8i-de2.txt
 create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-de2.c
 create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-de2.h
 create mode 100644 drivers/gpu/drm/sun4i/sun8i_layer.c
 create mode 100644 drivers/gpu/drm/sun4i/sun8i_layer.h
 create mode 100644 drivers/gpu/drm/sun4i/sun8i_mixer.c
 create mode 100644 drivers/gpu/drm/sun4i/sun8i_mixer.h
 create mode 100644 drivers/gpu/drm/sun4i/sunxi_engine.h
 create mode 100644 include/dt-bindings/clock/sun8i-de2.h
 create mode 100644 include/dt-bindings/reset/sun8i-de2.h

-- 
2.12.2

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

[PATCH v7 05/13] drm/sun4i: abstract a engine type

[Icenowy Zheng]

As we are going to add support for the Allwinner DE2 engine in sun4i-drm
driver, we will finally have two types of display engines -- the DE1
backend and the DE2 mixer. They both do some display blending and feed
graphics data to TCON, and is part of the "Display Engine" called by
Allwinner, so I choose to call them both "engine" here.

Abstract the engine type to a new struct with an ops struct, which contains
functions that should be called outside the engine-specified code (in
TCON, CRTC or TV Encoder code).

Signed-off-by: Icenowy Zheng 
Reviewed-by: Chen-Yu Tsai 
---
Changes in v7:
- Mention "Display Engine" for the name "engine".
- Fixed some small issues found by Chen-Yu and added his ACK.
Changes in v6:
- Rebased on wens's multi-pipeline patchset.
- Split out Makefile changes.
Changes in v5:
- Really made a sunxi_engine struct type, and moved ops pointer
  into it.
- Added checked ops wrappers.
- Changed the second parameter of layers_init from crtc to engine.
Changes in v4:
- Comments to tag the color correction functions as optional.
- Check before calling the optional functions.
- Change layers_init to satisfy new PATCH v4 04/11.

 drivers/gpu/drm/sun4i/sun4i_backend.c |  68 -
 drivers/gpu/drm/sun4i/sun4i_backend.h |  17 +++---
 drivers/gpu/drm/sun4i/sun4i_crtc.c|  11 ++--
 drivers/gpu/drm/sun4i/sun4i_crtc.h|   4 +-
 drivers/gpu/drm/sun4i/sun4i_drv.c |   2 +-
 drivers/gpu/drm/sun4i/sun4i_drv.h |   2 +-
 drivers/gpu/drm/sun4i/sun4i_layer.c   |   9 ++-
 drivers/gpu/drm/sun4i/sun4i_layer.h   |   4 +-
 drivers/gpu/drm/sun4i/sun4i_tcon.c|  38 ++--
 drivers/gpu/drm/sun4i/sun4i_tv.c  |   9 ++-
 drivers/gpu/drm/sun4i/sunxi_engine.h  | 111 ++
 11 files changed, 199 insertions(+), 76 deletions(-)
 create mode 100644 drivers/gpu/drm/sun4i/sunxi_engine.h

diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index e53107418add..611cdcb9c182 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -25,6 +25,8 @@
 
 #include "sun4i_backend.h"
 #include "sun4i_drv.h"
+#include "sun4i_layer.h"
+#include "sunxi_engine.h"
 
 static const u32 sunxi_rgb2yuv_coef[12] = {
0x0107, 0x0204, 0x0064, 0x0108,
@@ -32,41 +34,38 @@ static const u32 sunxi_rgb2yuv_coef[12] = {
0x01c1, 0x3e88, 0x3fb8, 0x0808
 };
 
-void sun4i_backend_apply_color_correction(struct sun4i_backend *backend)
+static void sun4i_backend_apply_color_correction(struct sunxi_engine *engine)
 {
int i;
 
DRM_DEBUG_DRIVER("Applying RGB to YUV color correction\n");
 
/* Set color correction */
-   regmap_write(backend->regs, SUN4I_BACKEND_OCCTL_REG,
+   regmap_write(engine->regs, SUN4I_BACKEND_OCCTL_REG,
 SUN4I_BACKEND_OCCTL_ENABLE);
 
for (i = 0; i < 12; i++)
-   regmap_write(backend->regs, SUN4I_BACKEND_OCRCOEF_REG(i),
+   regmap_write(engine->regs, SUN4I_BACKEND_OCRCOEF_REG(i),
 sunxi_rgb2yuv_coef[i]);
 }
-EXPORT_SYMBOL(sun4i_backend_apply_color_correction);
 
-void sun4i_backend_disable_color_correction(struct sun4i_backend *backend)
+static void sun4i_backend_disable_color_correction(struct sunxi_engine *engine)
 {
DRM_DEBUG_DRIVER("Disabling color correction\n");
 
/* Disable color correction */
-   regmap_update_bits(backend->regs, SUN4I_BACKEND_OCCTL_REG,
+   regmap_update_bits(engine->regs, SUN4I_BACKEND_OCCTL_REG,
   SUN4I_BACKEND_OCCTL_ENABLE, 0);
 }
-EXPORT_SYMBOL(sun4i_backend_disable_color_correction);
 
-void sun4i_backend_commit(struct sun4i_backend *backend)
+static void sun4i_backend_commit(struct sunxi_engine *engine)
 {
DRM_DEBUG_DRIVER("Committing changes\n");
 
-   regmap_write(backend->regs, SUN4I_BACKEND_REGBUFFCTL_REG,
+   regmap_write(engine->regs, SUN4I_BACKEND_REGBUFFCTL_REG,
 SUN4I_BACKEND_REGBUFFCTL_AUTOLOAD_DIS |
 SUN4I_BACKEND_REGBUFFCTL_LOADCTL);
 }
-EXPORT_SYMBOL(sun4i_backend_commit);
 
 void sun4i_backend_layer_enable(struct sun4i_backend *backend,
int layer, bool enable)
@@ -81,7 +80,7 @@ void sun4i_backend_layer_enable(struct sun4i_backend *backend,
else
val = 0;
 
-   regmap_update_bits(backend->regs, SUN4I_BACKEND_MODCTL_REG,
+   regmap_update_bits(backend->engine.regs, SUN4I_BACKEND_MODCTL_REG,
   SUN4I_BACKEND_MODCTL_LAY_EN(layer), val);
 }
 EXPORT_SYMBOL(sun4i_backend_layer_enable);
@@ -144,27 +143,28 @@ int sun4i_backend_update_layer_coord(struct sun4i_backend 
*backend,
if (plane->type == DRM_PLANE_TYPE_PRIMARY) {
DRM_DEBUG_DRIVER("Primary layer, updating global size W: %u H: 
%u\n",
 state->crtc_w, state->crtc_h);
-   

[PATCH v7 02/13] clk: sunxi-ng: add support for DE2 CCU

[Icenowy Zheng]

The "Display Engine 2.0" in Allwinner newer SoCs contains a clock
management unit for its subunits, like the DE CCU in A80.

Add a sunxi-ng style driver for it.

Signed-off-by: Icenowy Zheng 
---
Changes in v7:
- Fixed some parent clocks that are left open if the probe failed.
- Added V3s compatible (only one mixer).
Changes in v5:
- Removed dt-bindings headers (they're now in patch 1).
Changes in v4:
- Fixed the inconsistence between mixer_div clocks' number and real clock.
Changes in v2:
- Rename sunxi-de2-ccu to sun8i-de2-ccu.

 drivers/clk/sunxi-ng/Kconfig |   5 +
 drivers/clk/sunxi-ng/Makefile|   1 +
 drivers/clk/sunxi-ng/ccu-sun8i-de2.c | 260 +++
 drivers/clk/sunxi-ng/ccu-sun8i-de2.h |  28 
 4 files changed, 294 insertions(+)
 create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-de2.c
 create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-de2.h

diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-ng/Kconfig
index b0d551a8efe4..747662565545 100644
--- a/drivers/clk/sunxi-ng/Kconfig
+++ b/drivers/clk/sunxi-ng/Kconfig
@@ -140,6 +140,11 @@ config SUN8I_V3S_CCU
default MACH_SUN8I
depends on MACH_SUN8I || COMPILE_TEST
 
+config SUN8I_DE2_CCU
+   bool "Support for the Allwinner SoCs DE2 CCU"
+   select SUNXI_CCU_DIV
+   select SUNXI_CCU_GATE
+
 config SUN9I_A80_CCU
bool "Support for the Allwinner A80 CCU"
select SUNXI_CCU_DIV
diff --git a/drivers/clk/sunxi-ng/Makefile b/drivers/clk/sunxi-ng/Makefile
index 0ec02fe14c50..be616279450e 100644
--- a/drivers/clk/sunxi-ng/Makefile
+++ b/drivers/clk/sunxi-ng/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_SUN8I_A23_CCU)   += ccu-sun8i-a23.o
 obj-$(CONFIG_SUN8I_A33_CCU)+= ccu-sun8i-a33.o
 obj-$(CONFIG_SUN8I_H3_CCU) += ccu-sun8i-h3.o
 obj-$(CONFIG_SUN8I_V3S_CCU)+= ccu-sun8i-v3s.o
+obj-$(CONFIG_SUN8I_DE2_CCU)+= ccu-sun8i-de2.o
 obj-$(CONFIG_SUN8I_R_CCU)  += ccu-sun8i-r.o
 obj-$(CONFIG_SUN9I_A80_CCU)+= ccu-sun9i-a80.o
 obj-$(CONFIG_SUN9I_A80_CCU)+= ccu-sun9i-a80-de.o
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-de2.c 
b/drivers/clk/sunxi-ng/ccu-sun8i-de2.c
new file mode 100644
index ..15aaa9c4a3af
--- /dev/null
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-de2.c
@@ -0,0 +1,260 @@
+/*
+ * Copyright (c) 2017 Icenowy Zheng 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "ccu_common.h"
+#include "ccu_div.h"
+#include "ccu_gate.h"
+#include "ccu_reset.h"
+
+#include "ccu-sun8i-de2.h"
+
+static SUNXI_CCU_GATE(bus_mixer0_clk,  "bus-mixer0",   "bus-de",
+ 0x04, BIT(0), 0);
+static SUNXI_CCU_GATE(bus_mixer1_clk,  "bus-mixer1",   "bus-de",
+ 0x04, BIT(1), 0);
+static SUNXI_CCU_GATE(bus_wb_clk,  "bus-wb",   "bus-de",
+ 0x04, BIT(2), 0);
+
+static SUNXI_CCU_GATE(mixer0_clk,  "mixer0",   "mixer0-div",
+ 0x00, BIT(0), CLK_SET_RATE_PARENT);
+static SUNXI_CCU_GATE(mixer1_clk,  "mixer1",   "mixer1-div",
+ 0x00, BIT(1), CLK_SET_RATE_PARENT);
+static SUNXI_CCU_GATE(wb_clk,  "wb",   "wb-div",
+ 0x00, BIT(2), CLK_SET_RATE_PARENT);
+
+static SUNXI_CCU_M(mixer0_div_clk, "mixer0-div", "de", 0x0c, 0, 4,
+  CLK_SET_RATE_PARENT);
+static SUNXI_CCU_M(mixer1_div_clk, "mixer1-div", "de", 0x0c, 4, 4,
+  CLK_SET_RATE_PARENT);
+static SUNXI_CCU_M(wb_div_clk, "wb-div", "de", 0x0c, 8, 4,
+  CLK_SET_RATE_PARENT);
+
+static struct ccu_common *sun8i_a83t_de2_clks[] = {
+   _clk.common,
+   _clk.common,
+   _clk.common,
+
+   _mixer0_clk.common,
+   _mixer1_clk.common,
+   _wb_clk.common,
+
+   _div_clk.common,
+   _div_clk.common,
+   _div_clk.common,
+};
+
+static struct ccu_common *sun8i_v3s_de2_clks[] = {
+   _clk.common,
+   _clk.common,
+
+   _mixer0_clk.common,
+   _wb_clk.common,
+
+   _div_clk.common,
+   _div_clk.common,
+};
+
+static struct clk_hw_onecell_data sun8i_a83t_de2_hw_clks = {
+   .hws= {
+   [CLK_MIXER0]= _clk.common.hw,
+   [CLK_MIXER1]= _clk.common.hw,
+   [CLK_WB]= _clk.common.hw,
+
+   [CLK_BUS_MIXER0]= _mixer0_clk.common.hw,
+   [CLK_BUS_MIXER1]= _mixer1_clk.common.hw,
+   [CLK_BUS_WB]= _wb_clk.common.hw,
+
+   

[PATCH] gpu: host1x: Do not leak BO's phys address to userspace

[Dmitry Osipenko]

Do gathers coping before patching them, so the original gathers are left
untouched. That's not as bad as leaking a kernel addresses, but still
doesn't feel right.

Signed-off-by: Dmitry Osipenko 
---
 drivers/gpu/host1x/job.c | 46 ++
 1 file changed, 30 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
index d9933828fe87..8f0d43b8f9a6 100644
--- a/drivers/gpu/host1x/job.c
+++ b/drivers/gpu/host1x/job.c
@@ -137,8 +137,9 @@ static void host1x_syncpt_patch_offset(struct host1x_syncpt 
*sp,
  * avoid a wrap condition in the HW).
  */
 static int do_waitchks(struct host1x_job *job, struct host1x *host,
-  struct host1x_bo *patch)
+  struct host1x_job_gather *g)
 {
+   struct host1x_bo *patch = g->bo;
int i;
 
/* compare syncpt vs wait threshold */
@@ -165,7 +166,8 @@ static int do_waitchks(struct host1x_job *job, struct 
host1x *host,
wait->syncpt_id, sp->name, wait->thresh,
host1x_syncpt_read_min(sp));
 
-   host1x_syncpt_patch_offset(sp, patch, wait->offset);
+   host1x_syncpt_patch_offset(sp, patch,
+  g->offset + wait->offset);
}
 
wait->bo = NULL;
@@ -269,11 +271,12 @@ static unsigned int pin_job(struct host1x *host, struct 
host1x_job *job)
return err;
 }
 
-static int do_relocs(struct host1x_job *job, struct host1x_bo *cmdbuf)
+static int do_relocs(struct host1x_job *job, struct host1x_job_gather *g)
 {
int i = 0;
u32 last_page = ~0;
void *cmdbuf_page_addr = NULL;
+   struct host1x_bo *cmdbuf = g->bo;
 
/* pin & patch the relocs for one gather */
for (i = 0; i < job->num_relocs; i++) {
@@ -286,7 +289,8 @@ static int do_relocs(struct host1x_job *job, struct 
host1x_bo *cmdbuf)
if (cmdbuf != reloc->cmdbuf.bo)
continue;
 
-   if (last_page != reloc->cmdbuf.offset >> PAGE_SHIFT) {
+   if (!IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL) &&
+   last_page != reloc->cmdbuf.offset >> PAGE_SHIFT) {
if (cmdbuf_page_addr)
host1x_bo_kunmap(cmdbuf, last_page,
 cmdbuf_page_addr);
@@ -301,11 +305,20 @@ static int do_relocs(struct host1x_job *job, struct 
host1x_bo *cmdbuf)
}
}
 
+   if (IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL)) {
+   cmdbuf_page_addr = job->gather_copy_mapped;
+   cmdbuf_page_addr += g->offset;
+   }
+
target = cmdbuf_page_addr + (reloc->cmdbuf.offset & ~PAGE_MASK);
+
+   if (IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL))
+   target += (reloc->cmdbuf.offset & PAGE_MASK) >> 2;
+
*target = reloc_addr;
}
 
-   if (cmdbuf_page_addr)
+   if (!IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL) && cmdbuf_page_addr)
host1x_bo_kunmap(cmdbuf, last_page, cmdbuf_page_addr);
 
return 0;
@@ -573,6 +586,14 @@ int host1x_job_pin(struct host1x_job *job, struct device 
*dev)
if (err)
goto out;
 
+   if (IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL) && !err) {
+   err = copy_gathers(job, dev);
+   if (err) {
+   host1x_job_unpin(job);
+   return err;
+   }
+   }
+
/* patch gathers */
for (i = 0; i < job->num_gathers; i++) {
struct host1x_job_gather *g = >gathers[i];
@@ -581,7 +602,8 @@ int host1x_job_pin(struct host1x_job *job, struct device 
*dev)
if (g->handled)
continue;
 
-   g->base = job->gather_addr_phys[i];
+   if (!IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL))
+   g->base = job->gather_addr_phys[i];
 
for (j = i + 1; j < job->num_gathers; j++) {
if (job->gathers[j].bo == g->bo) {
@@ -590,23 +612,15 @@ int host1x_job_pin(struct host1x_job *job, struct device 
*dev)
}
}
 
-   err = do_relocs(job, g->bo);
+   err = do_relocs(job, g);
if (err)
break;
 
-   err = do_waitchks(job, host, g->bo);
+   err = do_waitchks(job, host, g);
if (err)
break;
}
 
-   if (IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL) && !err) {
-   err = copy_gathers(job, dev);
-   if (err) {
-   host1x_job_unpin(job);
-   return err;
-   }
-   }
-
 out:
wmb();
 
-- 
2.13.0

Re: [PATCH 00/13] Get rid of DocBook

[Kees Cook]

On Sun, May 14, 2017 at 8:38 AM, Mauro Carvalho Chehab
 wrote:
> As just one book (lsm) was missing conversion, let's convert it
> and store as if it were a plain text file under Documentation/lsm.txt,
> adding a notice that it requires update.

I could probably fold this change into my rst-ification of
Documentation/security/

https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=kspp/rst

Specifically, the new Documentation/security/LSM.rst was rather short.
I think your lsm.txt and this one could be likely merged.

-Kees

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

[PATCH v7 06/13] drm/sun4i: add a dedicated module for sun4i-backend and sun4i-layer

[Icenowy Zheng]

Currently the direct call from CRTC code to layer code has disappeared,
instead the layer's init function is called via the backend's ops.

Add a dedicated module for sun4i-backend and sun4i-layer, and drop the
EXPORT_SYMBOL from backend code to layer code.

Signed-off-by: Icenowy Zheng 
Reviewed-by: Chen-Yu Tsai 
---
Changes in v7:
- Added Chen-Yu's Reviewed-by.

 drivers/gpu/drm/sun4i/Makefile| 5 +++--
 drivers/gpu/drm/sun4i/sun4i_backend.c | 4 
 2 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index 59b757350a1f..a251fb36c951 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -5,9 +5,10 @@ sun4i-tcon-y += sun4i_tcon.o
 sun4i-tcon-y += sun4i_rgb.o
 sun4i-tcon-y += sun4i_dotclock.o
 sun4i-tcon-y += sun4i_crtc.o
-sun4i-tcon-y += sun4i_layer.o
+
+sun4i-backend-y += sun4i_backend.o sun4i_layer.o
 
 obj-$(CONFIG_DRM_SUN4I)+= sun4i-drm.o sun4i-tcon.o
-obj-$(CONFIG_DRM_SUN4I)+= sun4i_backend.o
+obj-$(CONFIG_DRM_SUN4I)+= sun4i-backend.o
 obj-$(CONFIG_DRM_SUN4I)+= sun6i_drc.o
 obj-$(CONFIG_DRM_SUN4I)+= sun4i_tv.o
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index 611cdcb9c182..fac1a414ba49 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -83,7 +83,6 @@ void sun4i_backend_layer_enable(struct sun4i_backend *backend,
regmap_update_bits(backend->engine.regs, SUN4I_BACKEND_MODCTL_REG,
   SUN4I_BACKEND_MODCTL_LAY_EN(layer), val);
 }
-EXPORT_SYMBOL(sun4i_backend_layer_enable);
 
 static int sun4i_backend_drm_format_to_layer(struct drm_plane *plane,
 u32 format, u32 *mode)
@@ -170,7 +169,6 @@ int sun4i_backend_update_layer_coord(struct sun4i_backend 
*backend,
 
return 0;
 }
-EXPORT_SYMBOL(sun4i_backend_update_layer_coord);
 
 int sun4i_backend_update_layer_formats(struct sun4i_backend *backend,
   int layer, struct drm_plane *plane)
@@ -205,7 +203,6 @@ int sun4i_backend_update_layer_formats(struct sun4i_backend 
*backend,
 
return 0;
 }
-EXPORT_SYMBOL(sun4i_backend_update_layer_formats);
 
 int sun4i_backend_update_layer_buffer(struct sun4i_backend *backend,
  int layer, struct drm_plane *plane)
@@ -246,7 +243,6 @@ int sun4i_backend_update_layer_buffer(struct sun4i_backend 
*backend,
 
return 0;
 }
-EXPORT_SYMBOL(sun4i_backend_update_layer_buffer);
 
 static int sun4i_backend_init_sat(struct device *dev) {
struct sun4i_backend *backend = dev_get_drvdata(dev);
-- 
2.12.2

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

[PATCH v7 07/13] drm/sun4i: add a Kconfig option for sun4i-backend

[Icenowy Zheng]

As sun4i-backend is now a dedicated module, add an Kconfig option for
it to make it optional, since some build may only use other engines.

Signed-off-by: Icenowy Zheng 
---
Changes in v7:
- Adjusted the position of BACKEND makefile item. (It's now after
  common codes shared between sun4i-backend and sun8i-mixer.)

 drivers/gpu/drm/sun4i/Kconfig  | 10 ++
 drivers/gpu/drm/sun4i/Makefile |  3 ++-
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig
index a4b357db8856..5a8227f37cc4 100644
--- a/drivers/gpu/drm/sun4i/Kconfig
+++ b/drivers/gpu/drm/sun4i/Kconfig
@@ -12,3 +12,13 @@ config DRM_SUN4I
  Choose this option if you have an Allwinner SoC with a
  Display Engine. If M is selected the module will be called
  sun4i-drm.
+
+config DRM_SUN4I_BACKEND
+   tristate "Support for Allwinner A10 Display Engine Backend"
+   depends on DRM_SUN4I
+   default DRM_SUN4I
+   help
+ Choose this option if you have an Allwinner SoC with the
+ original Allwinner Display Engine, which has a backend to
+ do some alpha blending and feed graphics to TCON. If M is
+ selected the module will be called sun4i-backend.
diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index a251fb36c951..da561d064ab8 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -9,6 +9,7 @@ sun4i-tcon-y += sun4i_crtc.o
 sun4i-backend-y += sun4i_backend.o sun4i_layer.o
 
 obj-$(CONFIG_DRM_SUN4I)+= sun4i-drm.o sun4i-tcon.o
-obj-$(CONFIG_DRM_SUN4I)+= sun4i-backend.o
 obj-$(CONFIG_DRM_SUN4I)+= sun6i_drc.o
 obj-$(CONFIG_DRM_SUN4I)+= sun4i_tv.o
+
+obj-$(CONFIG_DRM_SUN4I_BACKEND)+= sun4i-backend.o
-- 
2.12.2

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

Re: [PATCH 2/3] drm/tegra: Correct idr_alloc() minimum id

[Mikko Perttunen]

On 05/12/2017 10:00 PM, Dmitry Osipenko wrote:

The start = 0 is invalid and causes weird CDMA channel timeouts, presumably
some memory misuse/corruption is going on.


What makes you think start = 0 is invalid? I can't see anything pointing 
to that in the idr code and there are many users in the kernel passing 0 
as start.




Fixes: bdd2f9cd10eb ("drm/tegra: Don't leak kernel pointer to userspace")
Signed-off-by: Dmitry Osipenko 
---
 drivers/gpu/drm/tegra/drm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 768750226452..732c8d98044f 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -518,7 +518,7 @@ static int tegra_client_open(struct tegra_drm_file *fpriv,
if (err < 0)
return err;

-   err = idr_alloc(>contexts, context, 0, 0, GFP_KERNEL);
+   err = idr_alloc(>contexts, context, 1, 0, GFP_KERNEL);
if (err < 0) {
client->ops->close_channel(context);
return err;


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

[PATCH v7 13/13] [DO NOT MERGE] ARM: sun8i: v3s: enable LCD panel of Lichee Pi Zero

[Icenowy Zheng]

A 480x272 QiaoDian QD43003C0-40-7LED panel is available from Lichee Pi.

This commit connects this panel to Lichee Pi Zero.

Lichee Pi also provides a 800x480 panel without accurate model number,
so do not merge this patch. It will finally come as device tree overlay.

Signed-off-by: Icenowy Zheng 
---
 arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 36 +++
 1 file changed, 36 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts 
b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
index 387fc2aa546d..7ae72bf63cd0 100644
--- a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
+++ b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
@@ -75,6 +75,28 @@
gpios = < 6 2 GPIO_ACTIVE_LOW>; /* PG2 */
};
};
+
+   panel: panel {
+   compatible = "qiaodian,qd43003c0-40", "simple-panel";
+   enable-gpios = < 1 4 GPIO_ACTIVE_HIGH>; /* Should be 
backlight */
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   panel_input: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_out_lcd>;
+   };
+   };
+   };
+};
+
+ {
+   status = "okay";
 };
 
  {
@@ -86,6 +108,20 @@
status = "okay";
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_rgb666_pins>;
+   status = "okay";
+
+};
+
+_out {
+   tcon0_out_lcd: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_input>;
+   };
+};
+
  {
pinctrl-0 = <_pins_a>;
pinctrl-names = "default";
-- 
2.12.2

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

[PATCH v7 08/13] drm/sun4i: add support for Allwinner DE2 mixers

[Icenowy Zheng]

Allwinner have a new "Display Engine 2.0" in their new SoCs, which comes
with mixers to do graphic processing and feed data to TCON, like the old
backends and frontends.

Add support for the mixer on Allwinner V3s SoC; it's the simplest one.

Currently a lot of functions are still missing -- more investigations
are needed to gain enough information for them.

Signed-off-by: Icenowy Zheng 
---
Changes in v7:
- Small fixed advised by Maxime Ripard.
- Added fixup on CRTC destination coordinate.
Changes in v6:
- Rebased on wens's multi-pipeline patchset.
Changes in v5:
- Changed some code alignment.
- Request real 32-bit DMA (prepare for 64-bit SoCs).
Changes in v4:
- Killed some dead code according to Jernej.

 drivers/gpu/drm/sun4i/Kconfig   |  10 +
 drivers/gpu/drm/sun4i/Makefile  |   3 +
 drivers/gpu/drm/sun4i/sun8i_layer.c | 134 
 drivers/gpu/drm/sun4i/sun8i_layer.h |  36 
 drivers/gpu/drm/sun4i/sun8i_mixer.c | 412 
 drivers/gpu/drm/sun4i/sun8i_mixer.h | 137 
 6 files changed, 732 insertions(+)
 create mode 100644 drivers/gpu/drm/sun4i/sun8i_layer.c
 create mode 100644 drivers/gpu/drm/sun4i/sun8i_layer.h
 create mode 100644 drivers/gpu/drm/sun4i/sun8i_mixer.c
 create mode 100644 drivers/gpu/drm/sun4i/sun8i_mixer.h

diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig
index 5a8227f37cc4..15557484520d 100644
--- a/drivers/gpu/drm/sun4i/Kconfig
+++ b/drivers/gpu/drm/sun4i/Kconfig
@@ -22,3 +22,13 @@ config DRM_SUN4I_BACKEND
  original Allwinner Display Engine, which has a backend to
  do some alpha blending and feed graphics to TCON. If M is
  selected the module will be called sun4i-backend.
+
+config DRM_SUN8I_MIXER
+   tristate "Support for Allwinner Display Engine 2.0 Mixer"
+   depends on DRM_SUN4I
+   default MACH_SUN8I
+   help
+ Choose this option if you have an Allwinner SoC with the
+ Allwinner Display Engine 2.0, which has a mixer to do some
+ graphics mixture and feed graphics to TCON, If M is
+ selected the module will be called sun8i-mixer.
diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index da561d064ab8..d81c9319dadf 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -8,8 +8,11 @@ sun4i-tcon-y += sun4i_crtc.o
 
 sun4i-backend-y += sun4i_backend.o sun4i_layer.o
 
+sun8i-mixer-y += sun8i_mixer.o sun8i_layer.o
+
 obj-$(CONFIG_DRM_SUN4I)+= sun4i-drm.o sun4i-tcon.o
 obj-$(CONFIG_DRM_SUN4I)+= sun6i_drc.o
 obj-$(CONFIG_DRM_SUN4I)+= sun4i_tv.o
 
 obj-$(CONFIG_DRM_SUN4I_BACKEND)+= sun4i-backend.o
+obj-$(CONFIG_DRM_SUN8I_MIXER)  += sun8i-mixer.o
diff --git a/drivers/gpu/drm/sun4i/sun8i_layer.c 
b/drivers/gpu/drm/sun4i/sun8i_layer.c
new file mode 100644
index ..e627eeece658
--- /dev/null
+++ b/drivers/gpu/drm/sun4i/sun8i_layer.c
@@ -0,0 +1,134 @@
+/*
+ * Copyright (C) Icenowy Zheng 
+ *
+ * Based on sun4i_layer.h, which is:
+ *   Copyright (C) 2015 Free Electrons
+ *   Copyright (C) 2015 NextThing Co
+ *
+ *   Maxime Ripard 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+
+#include "sun8i_layer.h"
+#include "sun8i_mixer.h"
+
+struct sun8i_plane_desc {
+  enum drm_plane_type type;
+  const uint32_t  *formats;
+  uint32_tnformats;
+};
+
+static void sun8i_mixer_layer_atomic_disable(struct drm_plane *plane,
+  struct drm_plane_state 
*old_state)
+{
+   struct sun8i_layer *layer = plane_to_sun8i_layer(plane);
+   struct sun8i_mixer *mixer = layer->mixer;
+
+   sun8i_mixer_layer_enable(mixer, layer->id, false);
+}
+
+static void sun8i_mixer_layer_atomic_update(struct drm_plane *plane,
+ struct drm_plane_state *old_state)
+{
+   struct sun8i_layer *layer = plane_to_sun8i_layer(plane);
+   struct sun8i_mixer *mixer = layer->mixer;
+
+   sun8i_mixer_update_layer_coord(mixer, layer->id, plane);
+   sun8i_mixer_update_layer_formats(mixer, layer->id, plane);
+   sun8i_mixer_update_layer_buffer(mixer, layer->id, plane);
+   sun8i_mixer_layer_enable(mixer, layer->id, true);
+}
+
+static struct drm_plane_helper_funcs sun8i_mixer_layer_helper_funcs = {
+   .atomic_disable = sun8i_mixer_layer_atomic_disable,
+   .atomic_update  = sun8i_mixer_layer_atomic_update,
+};
+
+static const struct drm_plane_funcs sun8i_mixer_layer_funcs = {
+   .atomic_destroy_state   = drm_atomic_helper_plane_destroy_state,

Re: [PATCH v2] drm/tegra: Check size of a submitted command buffer

[Dmitry Osipenko]

On 12.05.2017 22:29, Dmitry Osipenko wrote:
> If command buffer claims a number of words that is higher than its BO can
> fit and a relocation lays past the BO, a kernel OOPS will be fired on that
> relocation address patching. This was triggered by an opentegra Xorg driver
> that erroneously pushed too many commands to the pushbuf.
> 

For the record, this patch is superseded by the "drm/tegra: Check offsets of a
submitted command buffer and of relocations."

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

[PATCH v7 04/13] drm/sun4i: return only planes for layers created

[Icenowy Zheng]

As we are going to add support for the Allwinner DE2 Mixer in sun4i-drm
driver, we will finally have two types of layers.

Each layer is bound to a drm_plane that is CRTC-specific, so we create
them when initializing CRTC (calling sun4i_layers_init, which will be
generalized in next patch). The drm_plane's will be used when creating
CRTC, but the CRTC initialization code do not care other properties of
the layer, so we let the sun4i_layers_init function return drm_plane's
only.

As we have no need to trace the layers after the CRTC is properly
created, we drop the layers pointer in sun4i_crtc struct.

Doing this uncouples the CRTC code from the type of layer (the
sun4i_layers_init function name is still hardcoded and will be changed
in the next patch), so that we can finally gain support for the
mixer in DE2, which has different layers.

Signed-off-by: Icenowy Zheng 
Reviewed-by: Chen-Yu Tsai 
---
 drivers/gpu/drm/sun4i/sun4i_crtc.c  | 23 ---
 drivers/gpu/drm/sun4i/sun4i_crtc.h  |  1 -
 drivers/gpu/drm/sun4i/sun4i_layer.c | 18 ++
 drivers/gpu/drm/sun4i/sun4i_layer.h |  4 ++--
 4 files changed, 24 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_crtc.c 
b/drivers/gpu/drm/sun4i/sun4i_crtc.c
index 3c876c3a356a..708b3543d4e9 100644
--- a/drivers/gpu/drm/sun4i/sun4i_crtc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_crtc.c
@@ -139,6 +139,7 @@ struct sun4i_crtc *sun4i_crtc_init(struct drm_device *drm,
   struct sun4i_tcon *tcon)
 {
struct sun4i_crtc *scrtc;
+   struct drm_plane **planes;
struct drm_plane *primary = NULL, *cursor = NULL;
int ret, i;
 
@@ -149,22 +150,22 @@ struct sun4i_crtc *sun4i_crtc_init(struct drm_device *drm,
scrtc->tcon = tcon;
 
/* Create our layers */
-   scrtc->layers = sun4i_layers_init(drm, scrtc->backend);
-   if (IS_ERR(scrtc->layers)) {
+   planes = sun4i_layers_init(drm, scrtc);
+   if (IS_ERR(planes)) {
dev_err(drm->dev, "Couldn't create the planes\n");
return NULL;
}
 
/* find primary and cursor planes for drm_crtc_init_with_planes */
-   for (i = 0; scrtc->layers[i]; i++) {
-   struct sun4i_layer *layer = scrtc->layers[i];
+   for (i = 0; planes[i]; i++) {
+   struct drm_plane *plane = planes[i];
 
-   switch (layer->plane.type) {
+   switch (plane->type) {
case DRM_PLANE_TYPE_PRIMARY:
-   primary = >plane;
+   primary = plane;
break;
case DRM_PLANE_TYPE_CURSOR:
-   cursor = >plane;
+   cursor = plane;
break;
default:
break;
@@ -188,12 +189,12 @@ struct sun4i_crtc *sun4i_crtc_init(struct drm_device *drm,
   1);
 
/* Set possible_crtcs to this crtc for overlay planes */
-   for (i = 0; scrtc->layers[i]; i++) {
+   for (i = 0; planes[i]; i++) {
uint32_t possible_crtcs = BIT(drm_crtc_index(>crtc));
-   struct sun4i_layer *layer = scrtc->layers[i];
+   struct drm_plane *plane = planes[i];
 
-   if (layer->plane.type == DRM_PLANE_TYPE_OVERLAY)
-   layer->plane.possible_crtcs = possible_crtcs;
+   if (plane->type == DRM_PLANE_TYPE_OVERLAY)
+   plane->possible_crtcs = possible_crtcs;
}
 
return scrtc;
diff --git a/drivers/gpu/drm/sun4i/sun4i_crtc.h 
b/drivers/gpu/drm/sun4i/sun4i_crtc.h
index 230cb8f0d601..4dae3508424a 100644
--- a/drivers/gpu/drm/sun4i/sun4i_crtc.h
+++ b/drivers/gpu/drm/sun4i/sun4i_crtc.h
@@ -19,7 +19,6 @@ struct sun4i_crtc {
 
struct sun4i_backend*backend;
struct sun4i_tcon   *tcon;
-   struct sun4i_layer  **layers;
 };
 
 static inline struct sun4i_crtc *drm_crtc_to_sun4i_crtc(struct drm_crtc *crtc)
diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.c 
b/drivers/gpu/drm/sun4i/sun4i_layer.c
index f26bde5b9117..e1f03e1cc0ac 100644
--- a/drivers/gpu/drm/sun4i/sun4i_layer.c
+++ b/drivers/gpu/drm/sun4i/sun4i_layer.c
@@ -16,6 +16,7 @@
 #include 
 
 #include "sun4i_backend.h"
+#include "sun4i_crtc.h"
 #include "sun4i_layer.h"
 
 struct sun4i_plane_desc {
@@ -128,15 +129,16 @@ static struct sun4i_layer *sun4i_layer_init_one(struct 
drm_device *drm,
return layer;
 }
 
-struct sun4i_layer **sun4i_layers_init(struct drm_device *drm,
-  struct sun4i_backend *backend)
+struct drm_plane **sun4i_layers_init(struct drm_device *drm,
+struct sun4i_crtc *crtc)
 {
-   struct sun4i_layer **layers;
+   struct drm_plane **planes;
+   struct sun4i_backend *backend = crtc->backend;
int i;
 
- 

[PATCH] gpu: host1x: Initialize firewall class to the jobs one

[Dmitry Osipenko]

The commands stream is prepended by the jobs class on the CDMA submission,
so that explicitly setting a module class in the commands stream isn't
necessary. The firewall initializes its class to 0 and the command stream
that doesn't explicitly specify the class effectively bypasses the firewall.

Signed-off-by: Dmitry Osipenko 
---
 drivers/gpu/host1x/job.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
index 5f5f8ee6143d..d9933828fe87 100644
--- a/drivers/gpu/host1x/job.c
+++ b/drivers/gpu/host1x/job.c
@@ -504,7 +504,7 @@ static inline int copy_gathers(struct host1x_job *job, 
struct device *dev)
fw.dev = dev;
fw.reloc = job->relocarray;
fw.num_relocs = job->num_relocs;
-   fw.class = 0;
+   fw.class = job->class;
 
for (i = 0; i < job->num_gathers; i++) {
struct host1x_job_gather *g = >gathers[i];
-- 
2.12.2

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

[PATCH v7 01/13] dt-bindings: add binding for the Allwinner DE2 CCU

[Icenowy Zheng]

Allwinner "Display Engine 2.0" contains some clock controls in it.

In order to add them as clock drivers, we need a device tree binding.
Add the binding here.

Also add the device tree binding headers.

Signed-off-by: Icenowy Zheng 
Acked-by: Rob Herring 
---
Changes in v7:
- Added V3s compatible.
Changes in v6:
- Added Rob's ACK.
- Droped A64's compatible as it's not appropriate now.
Changes in v5:
- Moved dt-binding headers here.
- Changed dt-binding headers' license header to SPDX license.
Changes in v4:
- Dropped the leading 0 in clock at 100 .
Changes in v3:
- Fill the address space length of DE2 CCU to 0x10, just reach the start of 
mixer0.

 .../devicetree/bindings/clock/sun8i-de2.txt| 31 ++
 include/dt-bindings/clock/sun8i-de2.h  | 18 +
 include/dt-bindings/reset/sun8i-de2.h  | 14 ++
 3 files changed, 63 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/sun8i-de2.txt
 create mode 100644 include/dt-bindings/clock/sun8i-de2.h
 create mode 100644 include/dt-bindings/reset/sun8i-de2.h

diff --git a/Documentation/devicetree/bindings/clock/sun8i-de2.txt 
b/Documentation/devicetree/bindings/clock/sun8i-de2.txt
new file mode 100644
index ..631d27cd89d6
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/sun8i-de2.txt
@@ -0,0 +1,31 @@
+Allwinner Display Engine 2.0 Clock Control Binding
+--
+
+Required properties :
+- compatible: must contain one of the following compatibles:
+   - "allwinner,sun8i-a83t-de2-clk"
+   - "allwinner,sun8i-v3s-de2-clk"
+   - "allwinner,sun50i-h5-de2-clk"
+
+- reg: Must contain the registers base address and length
+- clocks: phandle to the clocks feeding the display engine subsystem.
+ Three are needed:
+  - "mod": the display engine module clock
+  - "bus": the bus clock for the whole display engine subsystem
+- clock-names: Must contain the clock names described just above
+- resets: phandle to the reset control for the display engine subsystem.
+- #clock-cells : must contain 1
+- #reset-cells : must contain 1
+
+Example:
+de2_clocks: clock@100 {
+   compatible = "allwinner,sun8i-a83t-de2-clk";
+   reg = <0x0100 0x10>;
+   clocks = < CLK_BUS_DE>,
+< CLK_DE>;
+   clock-names = "bus",
+ "mod";
+   resets = < RST_BUS_DE>;
+   #clock-cells = <1>;
+   #reset-cells = <1>;
+};
diff --git a/include/dt-bindings/clock/sun8i-de2.h 
b/include/dt-bindings/clock/sun8i-de2.h
new file mode 100644
index ..3bed63b524aa
--- /dev/null
+++ b/include/dt-bindings/clock/sun8i-de2.h
@@ -0,0 +1,18 @@
+/*
+ * Copyright (C) 2016 Icenowy Zheng 
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+#ifndef _DT_BINDINGS_CLOCK_SUN8I_DE2_H_
+#define _DT_BINDINGS_CLOCK_SUN8I_DE2_H_
+
+#define CLK_BUS_MIXER0 0
+#define CLK_BUS_MIXER1 1
+#define CLK_BUS_WB 2
+
+#define CLK_MIXER0 6
+#define CLK_MIXER1 7
+#define CLK_WB 8
+
+#endif /* _DT_BINDINGS_CLOCK_SUN8I_DE2_H_ */
diff --git a/include/dt-bindings/reset/sun8i-de2.h 
b/include/dt-bindings/reset/sun8i-de2.h
new file mode 100644
index ..9526017432f0
--- /dev/null
+++ b/include/dt-bindings/reset/sun8i-de2.h
@@ -0,0 +1,14 @@
+/*
+ * Copyright (C) 2016 Icenowy Zheng 
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+#ifndef _DT_BINDINGS_RESET_SUN8I_DE2_H_
+#define _DT_BINDINGS_RESET_SUN8I_DE2_H_
+
+#define RST_MIXER0 0
+#define RST_MIXER1 1
+#define RST_WB 2
+
+#endif /* _DT_BINDINGS_RESET_SUN8I_DE2_H_ */
-- 
2.12.2

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

Re: [PATCH 2/3] drm/tegra: Correct idr_alloc() minimum id

[Dmitry Osipenko]

On 14.05.2017 14:53, Mikko Perttunen wrote:
> On 05/12/2017 10:00 PM, Dmitry Osipenko wrote:
>> The start = 0 is invalid and causes weird CDMA channel timeouts, presumably
>> some memory misuse/corruption is going on.
> 
> What makes you think start = 0 is invalid? I can't see anything pointing to 
> that
> in the idr code and there are many users in the kernel passing 0 as start.
> 

Well, I can't see either. You are right that there are quite many others with 0
as a start, the 1 probably just masks the bug.

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

Re: [PATCH v2] drm/tegra: Check size of a submitted command buffer

[Mikko Perttunen]

On 05/14/2017 03:45 PM, Dmitry Osipenko wrote:

On 14.05.2017 15:27, Mikko Perttunen wrote:

On 05/12/2017 10:29 PM, Dmitry Osipenko wrote:

If command buffer claims a number of words that is higher than its BO can
fit and a relocation lays past the BO, a kernel OOPS will be fired on that
relocation address patching. This was triggered by an opentegra Xorg driver
that erroneously pushed too many commands to the pushbuf.

[   46.829393] Unable to handle kernel paging request at virtual address 
f09b2000
...
[] (host1x_job_pin) from [] (tegra_drm_submit+0x474/0x510)
[] (tegra_drm_submit) from [] (tegra_submit+0x50/0x6c)
[] (tegra_submit) from [] (drm_ioctl+0x1e4/0x3ec)
[] (drm_ioctl) from [] (do_vfs_ioctl+0x9c/0x8e4)
[] (do_vfs_ioctl) from [] (SyS_ioctl+0x34/0x5c)
[] (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x3c)

Signed-off-by: Dmitry Osipenko 
---

v2: Take into account the cmdbuf.offset

 drivers/gpu/drm/tegra/drm.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 732c8d98044f..9ad4ac7c08d1 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -361,20 +361,30 @@ int tegra_drm_submit(struct tegra_drm_context *context,

 while (num_cmdbufs) {
 struct drm_tegra_cmdbuf cmdbuf;
-struct host1x_bo *bo;
+struct drm_gem_object *gem;
+struct tegra_bo *bo;

 if (copy_from_user(, cmdbufs, sizeof(cmdbuf))) {
 err = -EFAULT;
 goto fail;
 }

-bo = host1x_bo_lookup(file, cmdbuf.handle);
-if (!bo) {
+gem = drm_gem_object_lookup(file, cmdbuf.handle);
+if (!gem) {
 err = -ENOENT;
 goto fail;
 }

-host1x_job_add_gather(job, bo, cmdbuf.words, cmdbuf.offset);
+drm_gem_object_unreference_unlocked(gem);
+
+if (cmdbuf.offset + cmdbuf.words * 4 > gem->size) {
+err = -EINVAL;
+goto fail;
+}


Nasty bug! Well found. Two points: the arithmetic here could overflow, so
userspace could supply some large values for offset/words and this check would
not catch it. A fix would be to do the arithmetic in 64-bit. Also, looking at
the code closer, I can't see any bounds checking for relocs either.. That code
(host1x_reloc_copy_from_user) is the other place using host1x_bo_lookup, so we
could e.g. change host1x_bo_lookup to take offset and words parameters and
verify those at the same time.


Good point, unfortunately there are a lot of ways to abuse the staging API on
the IOMMU-less Tegra20 right now.



Indeed, though I think the relocation issue would be a problem on 
IOMMU-enabled systems as well. The Tegra20 and firewall have always been 
in a bit a bad position, as I'm not sure if the firewall was ever used 
in production during Tegra20's prime time, and of course it was quickly 
abandoned in downstream when we got IOMMUs on later chips.


Thanks for contributing :)

Mikko


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

Re: [PATCH 00/13] Get rid of DocBook

[Mauro Carvalho Chehab]

Em Sun, 14 May 2017 14:05:09 -0700
Kees Cook  escreveu:

> On Sun, May 14, 2017 at 8:38 AM, Mauro Carvalho Chehab
>  wrote:
> > As just one book (lsm) was missing conversion, let's convert it
> > and store as if it were a plain text file under Documentation/lsm.txt,
> > adding a notice that it requires update.
> 
> I could probably fold this change into my rst-ification of
> Documentation/security/
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=kspp/rst
> 
> Specifically, the new Documentation/security/LSM.rst was rather short.
> I think your lsm.txt and this one could be likely merged.

Yeah, makes sense. I'm not sure what would be the best way to
proceed, as, currently, after removing lsm.tmpl, my patch
series remove DocBook, as everything else was already removed.

I see a few ways for us to proceed:

1) You could submit the patches you have so far to docs -next,
to be merged before my patch series;

2) I could send you a patch based on your tree. I'll need to
rebase this series to be applied on the top of your tree + docs-next, 
with would require that your patch series would be merged before,
at docs -next;

3) we can handle both series independently. When both gets
merged at docs -next, a simple patch, either written by you or
me, could merge both files.

IMO, (3) is simpler, but if you prefer, we can do on some other
way.

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

[PATCH v7 03/13] dt-bindings: add bindings for DE2 on V3s SoC

[Icenowy Zheng]

Allwinner V3s SoC have a display engine which have a different pipeline
with older SoCs.

Add document for it (new compatibles and the new "mixer" part).

Signed-off-by: Icenowy Zheng 
Acked-by: Rob Herring 
---
Changes in v7:
- Reduced some text.
Changes in v4:
- Removed the refactor at TCON chapter.
Changes in v3:
- Remove the description of having a BE directly as allwinner,pipeline.

 .../bindings/display/sunxi/sun4i-drm.txt   | 26 --
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index 7acdbf14ae1c..66b85a195ef2 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -41,6 +41,7 @@ Required properties:
* allwinner,sun6i-a31-tcon
* allwinner,sun6i-a31s-tcon
* allwinner,sun8i-a33-tcon
+   * allwinner,sun8i-v3s-tcon
  - reg: base address and size of memory-mapped region
  - interrupts: interrupt associated to this IP
  - clocks: phandles to the clocks feeding the TCON. Three are needed:
@@ -62,7 +63,7 @@ Required properties:
   second the block connected to the TCON channel 1 (usually the TV
   encoder)
 
-On SoCs other than the A33, there is one more clock required:
+On SoCs other than the A33 and V3s, there is one more clock required:
- 'tcon-ch1': The clock driving the TCON channel 1
 
 DRC
@@ -148,6 +149,26 @@ Required properties:
   Documentation/devicetree/bindings/media/video-interfaces.txt. The
   first port should be the input endpoints, the second one the outputs
 
+Display Engine 2.0 Mixer
+
+
+The DE2 mixer have many functionalities, currently only layer blending is
+supported.
+
+Required properties:
+  - compatible: value must be one of:
+* allwinner,sun8i-v3s-de2-mixer
+  - reg: base address and size of the memory-mapped region.
+  - clocks: phandles to the clocks feeding the mixer
+* bus: the mixer interface clock
+* mod: the mixer module clock
+  - clock-names: the clock names mentioned above
+  - resets: phandles to the reset controllers driving the mixer
+
+- ports: A ports node with endpoint definitions as defined in
+  Documentation/devicetree/bindings/media/video-interfaces.txt. The
+  first port should be the input endpoints, the second one the output
+
 
 Display Engine Pipeline
 ---
@@ -162,9 +183,10 @@ Required properties:
 * allwinner,sun6i-a31-display-engine
 * allwinner,sun6i-a31s-display-engine
 * allwinner,sun8i-a33-display-engine
+* allwinner,sun8i-v3s-display-engine
 
   - allwinner,pipelines: list of phandle to the display engine
-frontends available.
+frontends (DE 1.0) or mixers (DE 2.0) available.
 
 Example:
 
-- 
2.12.2

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

Re: [Intel-gfx] [PATCH v7 9/9] drm/i915: Set PWM divider to match desired frequency in vbt

[Puthikorn Voravootivat]

On Fri, May 12, 2017 at 5:12 PM, Pandiyan, Dhinakaran <
dhinakaran.pandi...@intel.com> wrote:

> On Thu, 2017-05-11 at 16:02 -0700, Puthikorn Voravootivat wrote:
> > Read desired PWM frequency from panel vbt and calculate the
> > value for divider in DPCD address 0x724 and 0x728 to have
> > as many bits as possible for PWM duty cyle for granularity of
> > brightness adjustment while the frequency is still within 25%
> > of the desired frequency.
>
> I read a few eDP panel data sheets, the PWM frequencies all start from
> ~200Hz. If the VBT chooses this lowest value to allow for more
> brightness control, and then this patch lowers the value by another 25%,
> we'll end up below the panel allowed PWM frequency.
>
> In fact, one of the systems I checked had PWM frequency as 200Hz in VBT
> and the panel datasheet also had PWM frequency range starting from
> 200Hz. Have you considered this case?
>
> The spec said "A given LCD panel typically has a limited range of
backlight frequency capability.
To limit the programmable frequency range, limitations are placed on the
allowable total divider ratio with the Sink device"
 So I think it should be auto cap to 200Hz in this case.


> -DK
> >
> > Signed-off-by: Puthikorn Voravootivat 
> > ---
> >  drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 81
> +++
> >  1 file changed, 81 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > index 0b48851013cc..6f10a2f1ab76 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > @@ -113,12 +113,86 @@ intel_dp_aux_set_dynamic_backlight_percent(struct
> intel_dp *intel_dp,
> >   }
> >  }
> >
> > +/*
> > + * Set PWM Frequency divider to match desired frequency in vbt.
> > + * The PWM Frequency is calculated as 27Mhz / (F x P).
> > + * - Where F = PWM Frequency Pre-Divider value programmed by field 7:0
> of the
> > + * EDP_BACKLIGHT_FREQ_SET register (DPCD Address 00728h)
> > + * - Where P = 2^Pn, where Pn is the value programmed by field 4:0 of
> the
> > + * EDP_PWMGEN_BIT_COUNT register (DPCD Address 00724h)
> > + */
> > +static void intel_dp_aux_set_pwm_freq(struct intel_connector
> *connector)
> > +{
> > + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> > + struct intel_dp *intel_dp = enc_to_intel_dp(>
> encoder->base);
> > + int freq, fxp, fxp_min, fxp_max, fxp_actual, f = 1;
> > + u8 pn, pn_min, pn_max;
> > +
> > + /* Find desired value of (F x P)
> > +  * Note that, if F x P is out of supported range, the maximum
> value or
> > +  * minimum value will applied automatically. So no need to check
> that.
> > +  */
> > + freq = dev_priv->vbt.backlight.pwm_freq_hz;
> > + DRM_DEBUG_KMS("VBT defined backlight frequency %u Hz\n", freq);
> > + if (!freq) {
> > + DRM_DEBUG_KMS("Use panel default backlight frequency\n");
> > + return;
> > + }
> > +
> > + fxp = KHz(DP_EDP_BACKLIGHT_FREQ_BASE_KHZ) / freq;
> > +
> > + /* Use highest possible value of Pn for more granularity of
> brightness
> > +  * adjustment while satifying the conditions below.
> > +  * - Pn is in the range of Pn_min and Pn_max
> > +  * - F is in the range of 1 and 255
> > +  * - Effective frequency is within 25% of desired frequency.
> > +  */
> > + if (drm_dp_dpcd_readb(_dp->aux,
> > +DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN, _min)
> != 1) {
> > + DRM_DEBUG_KMS("Failed to read pwmgen bit count cap min\n");
> > + return;
> > + }
> > + if (drm_dp_dpcd_readb(_dp->aux,
> > +DP_EDP_PWMGEN_BIT_COUNT_CAP_MAX, _max)
> != 1) {
> > + DRM_DEBUG_KMS("Failed to read pwmgen bit count cap max\n");
> > + return;
> > + }
> > + pn_min &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
> > + pn_max &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
> > +
> > + fxp_min = fxp * 3 / 4;
> > + fxp_max = fxp * 5 / 4;
>
> You are allowing fxp between +/- 25% of the actual. This isn't same as
> the "Effective frequency is within 25% of desired frequency." right? The
> frequency can vary between -20% and +33%.
>
> You are right.
You want me to change commit message to reflect this or change the code to
match the commit message?

>
> > + if (fxp_min < (1 << pn_min) || (255 << pn_max) < fxp_max) {
> > + DRM_DEBUG_KMS("VBT defined backlight frequency out of
> range\n");
> > + return;
> > + }
> > +
> > + for (pn = pn_max; pn > pn_min; pn--) {
> > + f = clamp(fxp >> pn, 1, 255);
> > + fxp_actual = f << pn;
> > + if (fxp_min <= fxp_actual && fxp_actual <= fxp_max)
> > + break;
> > + }
> > +
> > + if (drm_dp_dpcd_writeb(_dp->aux,
> > +

[PATCH 00/13] Get rid of DocBook

[Mauro Carvalho Chehab]

As just one book (lsm) was missing conversion, let's convert it
and store as if it were a plain text file under Documentation/lsm.txt,
adding a notice that it requires update.

This way, as everything is now converted, we can get rid of
the DocBook building system and update places that were
mentioning it.

PS.: We could also remove the parts of the kernel-doc script that
produce DocBook outputs, but, as this might still be useful
for someone, for now let's just keep the functionality there.

-

This patch series is based on my past 00/05 and 00/36 patch series
that convert the other DocBooks to ReST, applied on the top of 
docs tree (next branch).

The full patch series is on this tree is at:

   https://git.linuxtv.org//mchehab/experimental.git/log/?h=docbook2

And the HTML output at:

  http://www.infradead.org/~mchehab/kernel_docs/
  https://mchehab.fedorapeople.org/kernel_docs/ 

Mauro Carvalho Chehab (13):
  docs-rst: convert lsm from DocBook to ReST
  docs: remove DocBook from the building system
  docs: update old references for DocBook from the documentation
  MAINTAINERS: update old references for DocBook directory
  ata: update references for libata documentation
  ia64, scsi: update references for the device-io book
  irq: update genericirq book location
  fs: update location of filesystems documentation
  lib: update location of kgdb documentation
  sound: fix the comments that refers to kernel-doc
  fs: fix the location of the kernel-api book
  usb: fix the comment with regards to DocBook
  docs-rst: get rid of Documentation/sphinx/tmplcvt script

 Documentation/00-INDEX |   6 +-
 Documentation/DocBook/.gitignore   |  17 --
 Documentation/DocBook/Makefile | 276 -
 Documentation/DocBook/lsm.tmpl | 265 ---
 Documentation/DocBook/stylesheet.xsl   |  11 --
 Documentation/Makefile | 125 +
 Documentation/Makefile.sphinx  | 130 --
 Documentation/PCI/MSI-HOWTO.txt|   2 +-
 Documentation/admin-guide/README.rst   |   6 -
 Documentation/doc-guide/docbook.rst|  90 --
 Documentation/doc-guide/index.rst  |   1 -
 Documentation/doc-guide/sphinx.rst |   5 -
 Documentation/fb/api.txt   |   4 +-
 Documentation/gpu/todo.rst |   2 +-
 Documentation/kernel-doc-nano-HOWTO.txt|  65 ++-
 Documentation/lsm.txt  | 201 +
 Documentation/process/changes.rst  |  26 +--
 Documentation/process/howto.rst|   8 -
 Documentation/process/kernel-docs.rst  |  34 +---
 Documentation/sphinx/tmplcvt   |  28 ---
 Documentation/translations/ja_JP/howto.rst |   7 -
 Documentation/translations/ko_KR/howto.rst |   7 -
 MAINTAINERS|   5 +-
 Makefile   |  11 +-
 arch/ia64/include/asm/io.h |   2 +-
 arch/ia64/sn/kernel/iomv.c |   2 +-
 drivers/ata/acard-ahci.c   |   2 +-
 drivers/ata/ahci.c |   2 +-
 drivers/ata/ahci.h |   2 +-
 drivers/ata/ata_piix.c |   2 +-
 drivers/ata/libahci.c  |   2 +-
 drivers/ata/libata-core.c  |   2 +-
 drivers/ata/libata-eh.c|   2 +-
 drivers/ata/libata-scsi.c  |   2 +-
 drivers/ata/libata-sff.c   |   2 +-
 drivers/ata/libata.h   |   2 +-
 drivers/ata/pata_pdc2027x.c|   2 +-
 drivers/ata/pdc_adma.c |   2 +-
 drivers/ata/sata_nv.c  |   2 +-
 drivers/ata/sata_promise.c |   2 +-
 drivers/ata/sata_promise.h |   2 +-
 drivers/ata/sata_qstor.c   |   2 +-
 drivers/ata/sata_sil.c |   2 +-
 drivers/ata/sata_sis.c |   2 +-
 drivers/ata/sata_svw.c |   2 +-
 drivers/ata/sata_sx4.c |   2 +-
 drivers/ata/sata_uli.c |   2 +-
 drivers/ata/sata_via.c |   2 +-
 drivers/ata/sata_vsc.c |   2 +-
 drivers/scsi/qla1280.c |   2 +-
 drivers/usb/gadget/Kconfig |   2 +-
 fs/debugfs/file.c  |   2 +-
 fs/debugfs/inode.c |   2 +-
 include/linux/ata.h|   2 +-
 include/linux/debugfs.h|   2 +-
 include/linux/libata.h |   2 +-
 include/sound/pcm.h|   2 +-
 kernel/irq/chip.c  |   2 +-
 kernel/irq/handle.c|   2 +-
 kernel/irq/irqdesc.c   |   2 +-
 lib/Kconfig.debug  |   2 +-
 lib/Kconfig.kgdb   |   2 +-
 scripts/Makefile   

Re: Notifications about ACPI events in userspace?

[Florian Echtler]

On 14.05.2017 10:11, Lukas Wunner wrote:
> On Sat, May 13, 2017 at 06:47:16PM +0200, Florian Echtler wrote:
>> On 13.05.2017 14:18, Lukas Wunner wrote:
>>>
>>> Then you could switch back and forth via the vga_switcheroo interface.
>>
>> Hm... since there's no power switching of any kind involved, would that
>> still make sense?
> 
> The handler's ->power_state hook would be a no-op.  Obviously not pretty,
> but we just don't have a better abstraction yet.  We represent an egress
> connector on a graphics card as a drm_connector in sysfs.  What we might
> need is a representation of a sink (display) in sysfs with symlinks to the
> sources.  Such a source could be a drm_connector or something else
> entirely (a GPU on another machine in your case).

OK, I think it's the closest thing that's already in the kernel, and before I
add yet another custom sysfs node, vga_switcheroo is probably the easiest route
to get things up and running.

>> AFAICT, the alternative (which maybe would be more sensible, the more I
>> think about it) would be to export applesmc_{read,write}_key as public
>> symbols and just access them from a standalone driver for the APP000C
>> ACPI device. Since that should only be present on a Mac that actually
>> supports TDM, there's also no risk of writing to arbitrary SMC keys on
>> unsupported devices.
> 
> That might make sense if you feel the driver will grow large enough to
> make applesmc.c look messy, or if you feel it just doesn't fit there.

Everything else in applesmc.c is hwmon-related, IMHO it would be a kludge. So
for applesmc, I'd just need a tiny patch to export the main key access
functions, and everything else can (hopefully) be encapsulated in an "apple-tdm"
driver.

> I guess the only reason why Apple integrated the functionality into the
> SMC is because they wanted to support TDM when the machine is powered off.
> The SMC is powered even in S5 (if the iMac is connected to AC), it just
> needs to monitor HPD on the external port and turn on the backlight if
> something is plugged in.  (I'm not sure if TDM is actually supported
> during poweroff but technically it would seem to be supported.)

Hm, interesting, I hadn't yet thought of that. This would of course be
excellent, because right now it looks like a waste of power to run the whole
machine just because of the display.

Does the SMC have control over the backlight? Do you know which keys are
responsible? IIRC the apple_bl.c driver didn't work on my iMac anyway...

Best, Florian
-- 
SENT FROM MY DEC VT50 TERMINAL



signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/tegra: Check whether page belongs to BO in tegra_bo_kmap()

[Dmitry Osipenko]

This fixes an OOPS in case of out-of-bounds accessing of a kmap'ed commands
buffer CMA while patching relocations in do_relocs().

Signed-off-by: Dmitry Osipenko 
---
 drivers/gpu/drm/tegra/gem.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index 424569b53e57..b76d7ac75696 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -74,6 +74,9 @@ static void *tegra_bo_kmap(struct host1x_bo *bo, unsigned int 
page)
 {
struct tegra_bo *obj = host1x_to_tegra_bo(bo);
 
+   if (page * PAGE_SIZE > obj->gem.size)
+   return NULL;
+
if (obj->vaddr)
return obj->vaddr + page * PAGE_SIZE;
else if (obj->gem.import_attach)
-- 
2.13.0

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

Re: [PATCH 1/3] drm/tegra: Fix lockup on a use of staging API

[Mikko Perttunen]

Reviewed-by: Mikko Perttunen 

On 05/12/2017 10:00 PM, Dmitry Osipenko wrote:

Commit bdd2f9cd ("Don't leak kernel pointer to userspace") added a mutex
around staging IOCTL's, some of those mutexes are taken twice.

Fixes: bdd2f9cd10eb ("drm/tegra: Don't leak kernel pointer to userspace")
Signed-off-by: Dmitry Osipenko 
---
 drivers/gpu/drm/tegra/drm.c | 20 
 1 file changed, 4 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index ab2dfd4e4bd9..768750226452 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -430,18 +430,6 @@ int tegra_drm_submit(struct tegra_drm_context *context,


 #ifdef CONFIG_DRM_TEGRA_STAGING
-static struct tegra_drm_context *
-tegra_drm_file_get_context(struct tegra_drm_file *file, u32 id)
-{
-   struct tegra_drm_context *context;
-
-   mutex_lock(>lock);
-   context = idr_find(>contexts, id);
-   mutex_unlock(>lock);
-
-   return context;
-}
-
 static int tegra_gem_create(struct drm_device *drm, void *data,
struct drm_file *file)
 {
@@ -585,7 +573,7 @@ static int tegra_close_channel(struct drm_device *drm, void 
*data,

mutex_lock(>lock);

-   context = tegra_drm_file_get_context(fpriv, args->context);
+   context = idr_find(>contexts, args->context);
if (!context) {
err = -EINVAL;
goto unlock;
@@ -610,7 +598,7 @@ static int tegra_get_syncpt(struct drm_device *drm, void 
*data,

mutex_lock(>lock);

-   context = tegra_drm_file_get_context(fpriv, args->context);
+   context = idr_find(>contexts, args->context);
if (!context) {
err = -ENODEV;
goto unlock;
@@ -639,7 +627,7 @@ static int tegra_submit(struct drm_device *drm, void *data,

mutex_lock(>lock);

-   context = tegra_drm_file_get_context(fpriv, args->context);
+   context = idr_find(>contexts, args->context);
if (!context) {
err = -ENODEV;
goto unlock;
@@ -664,7 +652,7 @@ static int tegra_get_syncpt_base(struct drm_device *drm, 
void *data,

mutex_lock(>lock);

-   context = tegra_drm_file_get_context(fpriv, args->context);
+   context = idr_find(>contexts, args->context);
if (!context) {
err = -ENODEV;
goto unlock;


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

Re: [PATCH v2] drm/tegra: Check size of a submitted command buffer

[Dmitry Osipenko]

On 14.05.2017 15:56, Mikko Perttunen wrote:
> 
> 
> On 05/14/2017 03:45 PM, Dmitry Osipenko wrote:
>> On 14.05.2017 15:27, Mikko Perttunen wrote:
>>> On 05/12/2017 10:29 PM, Dmitry Osipenko wrote:
 If command buffer claims a number of words that is higher than its BO can
 fit and a relocation lays past the BO, a kernel OOPS will be fired on that
 relocation address patching. This was triggered by an opentegra Xorg driver
 that erroneously pushed too many commands to the pushbuf.

 [   46.829393] Unable to handle kernel paging request at virtual address
 f09b2000
 ...
 [] (host1x_job_pin) from [] 
 (tegra_drm_submit+0x474/0x510)
 [] (tegra_drm_submit) from [] (tegra_submit+0x50/0x6c)
 [] (tegra_submit) from [] (drm_ioctl+0x1e4/0x3ec)
 [] (drm_ioctl) from [] (do_vfs_ioctl+0x9c/0x8e4)
 [] (do_vfs_ioctl) from [] (SyS_ioctl+0x34/0x5c)
 [] (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x3c)

 Signed-off-by: Dmitry Osipenko 
 ---

 v2: Take into account the cmdbuf.offset

  drivers/gpu/drm/tegra/drm.c | 18 ++
  1 file changed, 14 insertions(+), 4 deletions(-)

 diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
 index 732c8d98044f..9ad4ac7c08d1 100644
 --- a/drivers/gpu/drm/tegra/drm.c
 +++ b/drivers/gpu/drm/tegra/drm.c
 @@ -361,20 +361,30 @@ int tegra_drm_submit(struct tegra_drm_context 
 *context,

  while (num_cmdbufs) {
  struct drm_tegra_cmdbuf cmdbuf;
 -struct host1x_bo *bo;
 +struct drm_gem_object *gem;
 +struct tegra_bo *bo;

  if (copy_from_user(, cmdbufs, sizeof(cmdbuf))) {
  err = -EFAULT;
  goto fail;
  }

 -bo = host1x_bo_lookup(file, cmdbuf.handle);
 -if (!bo) {
 +gem = drm_gem_object_lookup(file, cmdbuf.handle);
 +if (!gem) {
  err = -ENOENT;
  goto fail;
  }

 -host1x_job_add_gather(job, bo, cmdbuf.words, cmdbuf.offset);
 +drm_gem_object_unreference_unlocked(gem);
 +
 +if (cmdbuf.offset + cmdbuf.words * 4 > gem->size) {
 +err = -EINVAL;
 +goto fail;
 +}
>>>
>>> Nasty bug! Well found. Two points: the arithmetic here could overflow, so
>>> userspace could supply some large values for offset/words and this check 
>>> would
>>> not catch it. A fix would be to do the arithmetic in 64-bit. Also, looking 
>>> at
>>> the code closer, I can't see any bounds checking for relocs either.. That 
>>> code
>>> (host1x_reloc_copy_from_user) is the other place using host1x_bo_lookup, so 
>>> we
>>> could e.g. change host1x_bo_lookup to take offset and words parameters and
>>> verify those at the same time.
>>>
>> Good point, unfortunately there are a lot of ways to abuse the staging API on
>> the IOMMU-less Tegra20 right now.
>>
> 
> Indeed, though I think the relocation issue would be a problem on 
> IOMMU-enabled
> systems as well. The Tegra20 and firewall have always been in a bit a bad
> position, as I'm not sure if the firewall was ever used in production during
> Tegra20's prime time, and of course it was quickly abandoned in downstream 
> when
> we got IOMMUs on later chips.
> 

In the IOMMU case some BO will be corrupted in the worst case and it's a
userspace problem, while in the non-IOMMU it will be an arbitrary phys memory.
Anyway it should be better to fail explicitly in any case.

> Thanks for contributing :)

My pleasure ;)

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

Re: [Intel-gfx] [PATCH v7 9/9] drm/i915: Set PWM divider to match desired frequency in vbt

[Pandiyan, Dhinakaran]

On Thu, 2017-05-11 at 16:02 -0700, Puthikorn Voravootivat wrote:
> Read desired PWM frequency from panel vbt and calculate the
> value for divider in DPCD address 0x724 and 0x728 to have
> as many bits as possible for PWM duty cyle for granularity of
> brightness adjustment while the frequency is still within 25%
> of the desired frequency.

I read a few eDP panel data sheets, the PWM frequencies all start from
~200Hz. If the VBT chooses this lowest value to allow for more
brightness control, and then this patch lowers the value by another 25%,
we'll end up below the panel allowed PWM frequency. 

In fact, one of the systems I checked had PWM frequency as 200Hz in VBT
and the panel datasheet also had PWM frequency range starting from
200Hz. Have you considered this case?

-DK
> 
> Signed-off-by: Puthikorn Voravootivat 
> ---
>  drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 81 
> +++
>  1 file changed, 81 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> index 0b48851013cc..6f10a2f1ab76 100644
> --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> @@ -113,12 +113,86 @@ intel_dp_aux_set_dynamic_backlight_percent(struct 
> intel_dp *intel_dp,
>   }
>  }
>  
> +/*
> + * Set PWM Frequency divider to match desired frequency in vbt.
> + * The PWM Frequency is calculated as 27Mhz / (F x P).
> + * - Where F = PWM Frequency Pre-Divider value programmed by field 7:0 of the
> + * EDP_BACKLIGHT_FREQ_SET register (DPCD Address 00728h)
> + * - Where P = 2^Pn, where Pn is the value programmed by field 4:0 of the
> + * EDP_PWMGEN_BIT_COUNT register (DPCD Address 00724h)
> + */
> +static void intel_dp_aux_set_pwm_freq(struct intel_connector *connector)
> +{
> + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> + struct intel_dp *intel_dp = enc_to_intel_dp(>encoder->base);
> + int freq, fxp, fxp_min, fxp_max, fxp_actual, f = 1;
> + u8 pn, pn_min, pn_max;
> +
> + /* Find desired value of (F x P)
> +  * Note that, if F x P is out of supported range, the maximum value or
> +  * minimum value will applied automatically. So no need to check that.
> +  */
> + freq = dev_priv->vbt.backlight.pwm_freq_hz;
> + DRM_DEBUG_KMS("VBT defined backlight frequency %u Hz\n", freq);
> + if (!freq) {
> + DRM_DEBUG_KMS("Use panel default backlight frequency\n");
> + return;
> + }
> +
> + fxp = KHz(DP_EDP_BACKLIGHT_FREQ_BASE_KHZ) / freq;
> +
> + /* Use highest possible value of Pn for more granularity of brightness
> +  * adjustment while satifying the conditions below.
> +  * - Pn is in the range of Pn_min and Pn_max
> +  * - F is in the range of 1 and 255
> +  * - Effective frequency is within 25% of desired frequency.
> +  */
> + if (drm_dp_dpcd_readb(_dp->aux,
> +DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN, _min) != 1) {
> + DRM_DEBUG_KMS("Failed to read pwmgen bit count cap min\n");
> + return;
> + }
> + if (drm_dp_dpcd_readb(_dp->aux,
> +DP_EDP_PWMGEN_BIT_COUNT_CAP_MAX, _max) != 1) {
> + DRM_DEBUG_KMS("Failed to read pwmgen bit count cap max\n");
> + return;
> + }
> + pn_min &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
> + pn_max &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
> +
> + fxp_min = fxp * 3 / 4;
> + fxp_max = fxp * 5 / 4;

You are allowing fxp between +/- 25% of the actual. This isn't same as
the "Effective frequency is within 25% of desired frequency." right? The
frequency can vary between -20% and +33%.


> + if (fxp_min < (1 << pn_min) || (255 << pn_max) < fxp_max) {
> + DRM_DEBUG_KMS("VBT defined backlight frequency out of range\n");
> + return;
> + }
> +
> + for (pn = pn_max; pn > pn_min; pn--) {
> + f = clamp(fxp >> pn, 1, 255);
> + fxp_actual = f << pn;
> + if (fxp_min <= fxp_actual && fxp_actual <= fxp_max)
> + break;
> + }
> +
> + if (drm_dp_dpcd_writeb(_dp->aux,
> +DP_EDP_PWMGEN_BIT_COUNT, pn) < 0) {
> + DRM_DEBUG_KMS("Failed to write aux pwmgen bit count\n");
> + return;
> + }
> + if (drm_dp_dpcd_writeb(_dp->aux,
> +DP_EDP_BACKLIGHT_FREQ_SET, (u8) f) < 0) {
> + DRM_DEBUG_KMS("Failed to write aux backlight freq\n");
> + return;
> + }
> +}
> +
>  static void intel_dp_aux_enable_backlight(struct intel_connector *connector)
>  {
>   struct intel_dp *intel_dp = enc_to_intel_dp(>encoder->base);
>   uint8_t dpcd_buf = 0;
>   uint8_t new_dpcd_buf = 0;
>   uint8_t edp_backlight_mode = 0;
> + bool freq_cap;
>  
>   if (drm_dp_dpcd_readb(_dp->aux,
>   

[PATCH v7 11/13] ARM: sun8i: v3s: add device nodes for DE2 display pipeline

[Icenowy Zheng]

Allwinner V3s SoC features a "Display Engine 2.0" with only one mixer
and only one TCON connected to this mixer, which have RGB LCD output.

Add device nodes for this display pipeline.

Signed-off-by: Icenowy Zheng 
---
Changes in v7:
- Change DE2 clock compatible to V3s one.
- Mention only one TCON in commit message.
- Changed commit brief.

 arch/arm/boot/dts/sun8i-v3s.dtsi | 87 
 1 file changed, 87 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index 71075969e5e6..b71b35734515 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -41,6 +41,10 @@
  */
 
 #include 
+#include 
+#include 
+#include 
+#include 
 
 / {
#address-cells = <1>;
@@ -59,6 +63,12 @@
};
};
 
+   de: display-engine {
+   compatible = "allwinner,sun8i-v3s-display-engine";
+   allwinner,pipelines = <_mixer0>;
+   status = "disabled";
+   };
+
timer {
compatible = "arm,armv7-timer";
interrupts = ,
@@ -93,6 +103,83 @@
#size-cells = <1>;
ranges;
 
+   de2_clocks: clock@100 {
+   compatible = "allwinner,sun8i-v3s-de2-clk";
+   reg = <0x0100 0x10>;
+   clocks = < CLK_DE>,
+< CLK_BUS_DE>;
+   clock-names = "mod",
+ "bus";
+   resets = < RST_BUS_DE>;
+   #clock-cells = <1>;
+   #reset-cells = <1>;
+   };
+
+   de2_mixer0: mixer@110 {
+   compatible = "allwinner,sun8i-v3s-de2-mixer";
+   reg = <0x0110 0x10>;
+   clocks = <_clocks CLK_MIXER0>,
+<_clocks CLK_BUS_MIXER0>;
+   clock-names = "mod",
+ "bus";
+   resets = <_clocks RST_MIXER0>;
+   assigned-clocks = <_clocks CLK_MIXER0>;
+   assigned-clock-rates = <15000>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   mixer0_out: port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+
+   mixer0_out_tcon0: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = 
<_in_mixer0>;
+   };
+   };
+   };
+   };
+
+   tcon0: lcd-controller@1c0c000 {
+   compatible = "allwinner,sun8i-v3s-tcon";
+   reg = <0x01c0c000 0x1000>;
+   interrupts = ;
+   clocks = < CLK_BUS_TCON0>,
+< CLK_TCON0>;
+   clock-names = "ahb",
+ "tcon-ch0";
+   clock-output-names = "tcon-pixel-clock";
+   resets = < RST_BUS_TCON0>;
+   reset-names = "lcd";
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   tcon0_in: port@0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0>;
+
+   tcon0_in_mixer0: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = 
<_out_tcon0>;
+   };
+   };
+
+   tcon0_out: port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+   };
+   };
+   };
+
+
mmc0: mmc@01c0f000 {
compatible = "allwinner,sun7i-a20-mmc";
reg = <0x01c0f000 0x1000>;
-- 
2.12.2

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

Re: [PATCH 2/3] drm/tegra: Correct idr_alloc() minimum id

[Dmitry Osipenko]

On 14.05.2017 16:02, Dmitry Osipenko wrote:
> On 14.05.2017 14:53, Mikko Perttunen wrote:
>> On 05/12/2017 10:00 PM, Dmitry Osipenko wrote:
>>> The start = 0 is invalid and causes weird CDMA channel timeouts, presumably
>>> some memory misuse/corruption is going on.
>>
>> What makes you think start = 0 is invalid? I can't see anything pointing to 
>> that
>> in the idr code and there are many users in the kernel passing 0 as start.
>>
> 
> Well, I can't see either. You are right that there are quite many others with > 0
> as a start, the 1 probably just masks the bug.
> 

Finally, I found the root of the issue. The job->client is set to the context ID
in the tegra_drm_submit() and the host1x_cdma sets client ID to 0 to mark CDMA
job timeout timer as already armed. I'll send V2 with a new commit description.

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

[PATCH] drm/tegra: Check offsets of a submitted command buffer and of relocations

[Dmitry Osipenko]

If commands buffer claims a number of words that is higher than its BO can
fit, a kernel OOPS will be fired on the out-of-bounds BO access. This was
triggered by an opentegra Xorg driver that erroneously pushed too many
commands to the pushbuf. The CMDA commands buffer address is 4 bytes
aligned, so check the alignment as well.

Add a sanity check for the relocations in a same way.

[   46.829393] Unable to handle kernel paging request at virtual address 
f09b2000
...
[] (host1x_job_pin) from [] (tegra_drm_submit+0x474/0x510)
[] (tegra_drm_submit) from [] (tegra_submit+0x50/0x6c)
[] (tegra_submit) from [] (drm_ioctl+0x1e4/0x3ec)
[] (drm_ioctl) from [] (do_vfs_ioctl+0x9c/0x8e4)
[] (do_vfs_ioctl) from [] (SyS_ioctl+0x34/0x5c)
[] (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x3c)

Signed-off-by: Dmitry Osipenko 
Reviewed-by: Erik Faye-Lund 
---
 drivers/gpu/drm/tegra/drm.c | 30 ++
 drivers/gpu/drm/tegra/gem.c |  5 -
 drivers/gpu/drm/tegra/gem.h |  5 +
 3 files changed, 35 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 768750226452..c5844a065681 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -362,6 +362,8 @@ int tegra_drm_submit(struct tegra_drm_context *context,
while (num_cmdbufs) {
struct drm_tegra_cmdbuf cmdbuf;
struct host1x_bo *bo;
+   struct tegra_bo *obj;
+   u64 offset;
 
if (copy_from_user(, cmdbufs, sizeof(cmdbuf))) {
err = -EFAULT;
@@ -374,6 +376,14 @@ int tegra_drm_submit(struct tegra_drm_context *context,
goto fail;
}
 
+   offset = (u64)cmdbuf.offset + (u64)cmdbuf.words * sizeof(u32);
+   obj = host1x_to_tegra_bo(bo);
+
+   if (offset & 3 || offset > obj->gem.size) {
+   err = -EINVAL;
+   goto fail;
+   }
+
host1x_job_add_gather(job, bo, cmdbuf.words, cmdbuf.offset);
num_cmdbufs--;
cmdbufs++;
@@ -381,11 +391,31 @@ int tegra_drm_submit(struct tegra_drm_context *context,
 
/* copy and resolve relocations from submit */
while (num_relocs--) {
+   struct host1x_reloc *reloc;
+   struct tegra_bo *obj;
+
err = host1x_reloc_copy_from_user(>relocarray[num_relocs],
  [num_relocs], drm,
  file);
if (err < 0)
goto fail;
+
+   reloc = >relocarray[num_relocs];
+   obj = host1x_to_tegra_bo(reloc->cmdbuf.bo);
+
+   if (reloc->cmdbuf.offset & 3 ||
+   reloc->cmdbuf.offset > obj->gem.size) {
+   err = -EINVAL;
+   goto fail;
+   }
+
+   obj = host1x_to_tegra_bo(reloc->target.bo);
+
+   if (reloc->target.offset & 3 ||
+   reloc->target.offset > obj->gem.size) {
+   err = -EINVAL;
+   goto fail;
+   }
}
 
if (copy_from_user(job->waitchk, waitchks,
diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index b76d7ac75696..a0ff30c01ac1 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -20,11 +20,6 @@
 #include "drm.h"
 #include "gem.h"
 
-static inline struct tegra_bo *host1x_to_tegra_bo(struct host1x_bo *bo)
-{
-   return container_of(bo, struct tegra_bo, base);
-}
-
 static void tegra_bo_put(struct host1x_bo *bo)
 {
struct tegra_bo *obj = host1x_to_tegra_bo(bo);
diff --git a/drivers/gpu/drm/tegra/gem.h b/drivers/gpu/drm/tegra/gem.h
index 6c5f12ac0087..8b32a6fd586d 100644
--- a/drivers/gpu/drm/tegra/gem.h
+++ b/drivers/gpu/drm/tegra/gem.h
@@ -52,6 +52,11 @@ static inline struct tegra_bo *to_tegra_bo(struct 
drm_gem_object *gem)
return container_of(gem, struct tegra_bo, gem);
 }
 
+static inline struct tegra_bo *host1x_to_tegra_bo(struct host1x_bo *bo)
+{
+   return container_of(bo, struct tegra_bo, base);
+}
+
 struct tegra_bo *tegra_bo_create(struct drm_device *drm, size_t size,
 unsigned long flags);
 struct tegra_bo *tegra_bo_create_with_handle(struct drm_file *file,
-- 
2.13.0

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

Re: [PATCH v7 3/9] drm/i915: Drop AUX backlight enable check for backlight control

[Pandiyan, Dhinakaran]

On Fri, 2017-05-12 at 11:10 -0700, Puthikorn Voravootivat wrote:
> 
> 
> On Fri, May 12, 2017 at 6:14 AM, Jani Nikula
>  wrote:
> On Fri, 12 May 2017, "Pandiyan, Dhinakaran"
>  wrote:
> > On Thu, 2017-05-11 at 16:02 -0700, Puthikorn Voravootivat
> wrote:
> >> There are some panel that
> >> (1) does not support display backlight enable via AUX
> >> (2) support display backlight adjustment via AUX
> >> (3) support display backlight enable via eDP BL_ENABLE pin
> >>
> >> The current driver required that (1) must be support to
> enable (2).
> >> This patch drops that requirement.
> >>
> >
> > You sent this version before I finished my follow-up
> questions, copying
> > the conversation here for context.
> 
> Puthikorn, please don't send new versions before the review is
> addressed.
> Sorry I thought I was explained it clear enough.  
> 
> Pushed patches 1, 2, 5, and 7. Thanks for the patches and
> review.
> 
> BR,
> Jani.
> 
> > DK: Won't DP_EDP_BACKLIGHT_AUX_ENABLE_CAP be 1 always? The
> code below,
> > in
> > intel_dp_aux_display_control_capable(), makes sure
> > DP_EDP_BACKLIGHT_PIN_ENABLE_CAP=0. The spec says at least
> one of these
> > has to be 1.
> >
> > Puthikorn: We will drop the
> DP_EDP_BACKLIGHT_PIN_ENABLE_CAP != 0 check
> > in next patch set.
> > This patch adds check here to prepare for that.
> >
> >
> > 1) So, this patch does not really fix what the commit
> message claims
> > because it is dependent on the following patch. Does it make
> sense to
> > remove this check in this patch? That way, this patch by
> itself is the
> > fix that the commit message says.
> >
> > -   !((intel_dp->edp_dpcd[1] &
> DP_EDP_BACKLIGHT_PIN_ENABLE_CAP)
> >
> 
> Sure. I can remove this here and adds it in next patch instead.
> 
> 
> >
> > 2) If a panel supports backlight enable via AUX and
> BL_ENABLE pin, this
> > patch (along with the next) enables backlight twice, doesn't
> it?
> > _intel_edp_backlight_on(intel_dp) in intel_dp.c is called
> > unconditionally after intel_dp_aux_enable_backlight(). I
> don't know how
> > likely this configuration is or if it's alright to enable
> via both AUX
> > and BL_ENABLE pin.
> >
> 
> The eDP spec did not mention this case explicitly.
> But it should not hurt to enable backlight twice as we want the
> backlight to be enabled anyway.
>  

Hope so, at least a TODO would be a reasonable warning.

> >
> >
> >
> >> Signed-off-by: Puthikorn Voravootivat 
> >> ---
> >>  drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 5 -
> >>  1 file changed, 4 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> >> index 870c03fc0f3a..c22712762957 100644
> >> --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> >> +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> >> @@ -28,6 +28,10 @@ static void
> set_aux_backlight_enable(struct intel_dp *intel_dp, bool
> enable)
> >>  {
> >>  uint8_t reg_val = 0;
> >>
> >> +   /* Early return when display use other mechanism to
> enable backlight. */
> >> +if (!(intel_dp->edp_dpcd[1] &
> DP_EDP_BACKLIGHT_AUX_ENABLE_CAP))
> >> +return;
> >> +
> >>  if (drm_dp_dpcd_readb(_dp->aux,
> DP_EDP_DISPLAY_CONTROL_REGISTER,
> >>_val) < 0) {
> >>  DRM_DEBUG_KMS("Failed to read DPCD register 0x
> %x\n",
> >> @@ -164,7 +168,6 @@
> intel_dp_aux_display_control_capable(struct intel_connector
> *connector)
> >>   * the panel can support backlight control over the
> aux channel
> >>   */
> >>  if (intel_dp->edp_dpcd[1] &
> DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP &&
> >> -(intel_dp->edp_dpcd[1] &
> DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
> >>  (intel_dp->edp_dpcd[2] &
> DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP) &&
> >>  !((intel_dp->edp_dpcd[1] &
> DP_EDP_BACKLIGHT_PIN_ENABLE_CAP) ||
> >>(intel_dp->edp_dpcd[2] &
> DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))) {
> >
> 
> 
> --

Re: nouveau "eDP-1: EDID is invalid" regression after 4.11 with HP ZBook 15 G3

[Ben Skeggs]

On 05/15/2017 01:10 AM, Tommi Rantala wrote:

Hi,

Hey Tommi,

Thanks for bisecting this.  It's rather unexpected that you should be 
seeing problems here, but, the commit makes sense for it at least.


Are you able to get me new kernel logs of both before and after this 
patch with "log_buf_len=8M drm.debug=0x14 
nouveau.debug=disp=trace,i2c=trace,bios=trace" please?


Thanks,
Ben.



Bisected this to:

commit df8dc97cd17269474344d73cc02739532c468d04
Author: Ben Skeggs 
Date:   Wed Mar 1 09:42:04 2017 +1000

drm/nouveau/kms/nv50: use drm core i2c-over-aux algorithm

I'm not entirely sure NVKM needs to support this now, but I haven't
removed it as of yet just in case it's needed from DEVINIT scripts
where DRM isn't available.

Signed-off-by: Ben Skeggs 


dmesg after boot with drm.debug enabled:

v4.10-10409-g5c68d91 (still works):
http://termbin.com/b0is

v4.10-10410-gdf8dc97 (failure):
http://termbin.com/j6lq


Tommi


2017-05-10 11:24 GMT+03:00 Tommi Rantala :

Hi,

The HP ZBook 15 G3 laptop builtin display (eDP-1) does not work
correctly with v4.11-11413-g2868b25.

When booting the laptop, the resolution seems to be limited to
1024x768, and gnome-session segfaults.

Up to 4.11 the display works just fine in 1920x1080 mode.

I'm seeing this in the kernel logs:

nouveau :01:00.0: eDP-1: EDID is invalid:
 [00] BAD  00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
 [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff 84 53 54
 [00] BAD  66 69 50 55 57 66 74 49 48 ff ff ff ff ff ff ff
 [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 [00] BAD  ff ff ff ff ff ff ff ff ff ff ff 00 00 ff 00 ff
nouveau :01:00.0: DRM: DDC responded, but no EDID for eDP-1
[drm] Cannot find any crtc or sizes - going 1024x768


$ lspci | grep NVIDIA
01:00.0 VGA compatible controller: NVIDIA Corporation GM107GLM [Quadro
M2000M] (rev a2)

Any ideas, or should I bisect?

4.11 dmesg & xrandr output:
https://pastebin.com/raw/P9LGP7e1

4.11-11413-g2868b25 dmesg:
https://pastebin.com/raw/QBT9mMua

-Tommi

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

[Bug 100984] QupZilla crashes at startup after mesa upgrade

[bugzilla-daemon]

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

Alexander Tsoy  changed:

   What|Removed |Added

  Component|Drivers/DRI/i915|Drivers/Gallium/i915g

-- 
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 100984] QupZilla crashes at startup after mesa upgrade

[bugzilla-daemon]

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

--- Comment #7 from Alexander Tsoy  ---
Confirming this issue with i915g driver.

$ DISPLAY=:0 glxinfo | egrep 'renderer string|OpenGL version string'
OpenGL renderer string: Gallium 0.4 on i915 (chipset: 945GM)
OpenGL version string: 2.1 Mesa 17.1.0-rc4

"glxgears" and "mpv --vo=opengl" segfaults:

[35772.915780] mpv/vo[8568]: segfault at 12c ip 7f456c76ae76 sp
7f456dbad880 error 4 in i915g_dri.so[7f456c261000+6a9000]
[35779.817131] mpv/vo[8599]: segfault at 12c ip 7f14033bce76 sp
7f1408b6a880 error 4 in i915g_dri.so[7f1402eb3000+6a9000]
[35792.307840] glxgears[8625]: segfault at 12c ip 7f07ee640e76 sp
7fff2adb5900 error 4 in i915g_dri.so[7f07ee137000+6a9000]
[35874.392980] glxgears[8638]: segfault at 12c ip 7f54a2cfae76 sp
7ffeb5249370 error 4 in i915g_dri.so[7f54a27f1000+6a9000]

-- 
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 v1] drm: Add DRM_ROTATE_ and DRM_REFLECT_ defines to UAPI

[Robert Foss]

Add DRM_ROTATE_ and DRM_REFLECT_ defines to the UAPI as a convenience.

Ideally the DRM_ROTATE_ and DRM_REFLECT_ property ids are looked up
through the atomic API, but realizing that userspace is likely to take
shortcuts and assume that the enum values are what is sent over the
wire.

As a result these defines are provided purely as a convenience to
userspace applications.

Signed-off-by: Robert Foss 
---
 drivers/gpu/drm/drm_rect.c |  1 +
 include/drm/drm_blend.h| 18 
 include/uapi/drm/drm.h | 73 ++
 3 files changed, 74 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c
index bc5575960ebc..bdb27434bb10 100644
--- a/drivers/gpu/drm/drm_rect.c
+++ b/drivers/gpu/drm/drm_rect.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/include/drm/drm_blend.h b/include/drm/drm_blend.h
index 13221cf9b3eb..d149a63b893b 100644
--- a/include/drm/drm_blend.h
+++ b/include/drm/drm_blend.h
@@ -29,24 +29,6 @@
 struct drm_device;
 struct drm_atomic_state;
 
-/*
- * Rotation property bits. DRM_ROTATE_ rotates the image by the
- * specified amount in degrees in counter clockwise direction. DRM_REFLECT_X 
and
- * DRM_REFLECT_Y reflects the image along the specified axis prior to rotation
- *
- * WARNING: These defines are UABI since they're exposed in the rotation
- * property.
- */
-#define DRM_ROTATE_0   BIT(0)
-#define DRM_ROTATE_90  BIT(1)
-#define DRM_ROTATE_180 BIT(2)
-#define DRM_ROTATE_270 BIT(3)
-#define DRM_ROTATE_MASK (DRM_ROTATE_0   | DRM_ROTATE_90 | \
-DRM_ROTATE_180 | DRM_ROTATE_270)
-#define DRM_REFLECT_X  BIT(4)
-#define DRM_REFLECT_Y  BIT(5)
-#define DRM_REFLECT_MASK (DRM_REFLECT_X | DRM_REFLECT_Y)
-
 static inline bool drm_rotation_90_or_270(unsigned int rotation)
 {
return rotation & (DRM_ROTATE_90 | DRM_ROTATE_270);
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 42d9f64ce416..d7140b0091bc 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -697,6 +697,79 @@ struct drm_prime_handle {
__s32 fd;
 };
 
+/** DRM_ROTATE_0
+ *
+ * Signals that a drm plane has been rotated 0 degrees.
+ *
+ * This define is provided as a convenience, looking up the property id
+ * using the name->prop id lookup is the preferred method.
+ */
+#define DRM_ROTATE_0   BIT(0)
+
+/** DRM_ROTATE_90
+ *
+ * Signals that a drm plane has been rotated 90 degrees in counter clockwise
+ * direction.
+ *
+ * This define is provided as a convenience, looking up the property id
+ * using the name->prop id lookup is the preferred method.
+ */
+#define DRM_ROTATE_90  BIT(1)
+
+/** DRM_ROTATE_180
+ *
+ * Signals that a drm plane has been rotated 180 degrees in counter clockwise
+ * direction.
+ *
+ * This define is provided as a convenience, looking up the property id
+ * using the name->prop id lookup is the preferred method.
+ */
+#define DRM_ROTATE_180 BIT(2)
+
+/** DRM_ROTATE_270
+ *
+ * Signals that a drm plane has been rotated 270 degrees in counter clockwise
+ * direction.
+ *
+ * This define is provided as a convenience, looking up the property id
+ * using the name->prop id lookup is the preferred method.
+ */
+#define DRM_ROTATE_270 BIT(3)
+
+
+/** DRM_ROTATE_MASK
+ *
+ * Bitmask used to look for drm plane rotations.
+ */
+#define DRM_ROTATE_MASK (DRM_ROTATE_0   | DRM_ROTATE_90 | \
+DRM_ROTATE_180 | DRM_ROTATE_270)
+
+/** DRM_REFLECT_X
+ *
+ * Signals that a drm plane has been reflected in the X axis.
+ *
+ * This define is provided as a convenience, looking up the property id
+ * using the name->prop id lookup is the preferred method.
+ */
+#define DRM_REFLECT_X  BIT(4)
+
+/** DRM_REFLECT_Y
+ *
+ * Signals that a drm plane has been reflected in the Y axis.
+ *
+ * This define is provided as a convenience, looking up the property id
+ * using the name->prop id lookup is the preferred method.
+ */
+#define DRM_REFLECT_Y  BIT(5)
+
+
+/** DRM_REFLECT_MASK
+ *
+ * Bitmask used to look for drm plane reflections.
+ */
+#define DRM_REFLECT_MASK (DRM_REFLECT_X | DRM_REFLECT_Y)
+
+
 #if defined(__cplusplus)
 }
 #endif
-- 
2.11.0.453.g787f75f05

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

Re: [PATCH 0/6] R-Car DU: Fix IOMMU operation when connected to VSP

[Laurent Pinchart]

Hi Magnus,

On Wednesday 07 Sep 2016 17:01:06 Magnus Damm wrote:
> Hi Laurent,
> 
> Thanks for your help with this. Good to see that the DU driver is
> getting closer to work with the IPMMU hardware! Please see below for
> some feedback from me.
> 
> On Fri, Aug 19, 2016 at 5:39 PM, Laurent Pinchart wrote:
> > Hello,
> > 
> > This patch series fixes the rcar-du-drm driver to support VSP plane
> > sources with an IOMMU. It is available for convenience at
> > 
> > git://linuxtv.org/pinchartl/media.git iommu/devel/du
> > 
> > On R-Car Gen3 the DU has no direct memory access but sources planes
> > through VSP instances. When an IOMMU is inserted between the VSP and
> > memory, the DU framebuffers need to be DMA mapped using the VSP device,
> > not the DU device as currently done. The same situation can also be
> > reproduced on Gen2 hardware by linking the VSP to the DU in DT [1],
> > effectively disabling direct memory access by the DU.
> > 
> > The situation is made quite complex by the fact that different planes can
> > be connected to different DU instances, and thus served by different
> > IOMMUs (or, in practice on existing hardware, by the same IOMMU but
> > through different micro-TLBs). We thus can't allocate and map buffers to
> > the right device in a single dma_alloc_wc() operation as done in the DRM
> > CMA GEM helpers.
> > 
> > However, on such setups, the DU DT node doesn't reference IOMMUs as the DU
> > does not perform any direct memory access. We can thus keep the GEM object
> > allocation unchanged, and the DMA addresses that we receive in the DU
> > driver will be physical addresses. Those buffers then need to be mapped
> > to the VSP device when they are associated with planes. Fortunately the
> > atomic framework provides two plane helper operations, .prepare_fb() and
> > .cleanup_fb() that we can use for this purpose.
> > 
> > The reality is slightly more complex than this on Gen3, as an FCP device
> > instance sits between VSP instances and memory. It is the FCP devices that
> > are connected to the IOMMUs, and buffer mapping thus need to be performed
> > using the FCP devices. This isn't required on Gen2 as the platforms don't
> > have any FCPs.
> > 
> > Patches 1/6 and 2/6 unconstify the state argument to the .prepare_fb() and
> > .cleanup_fb() operations, to allow storing the mapped buffer addresses in
> > the state. Patches 3/6 and 4/6 then extend the rcar-fcp driver API to
> > expose the FCP struct device. Patch 5/6 extends the vsp1 driver API to
> > allow mapping a scatter-gather list to the VSP, with the implementation
> > using the FCP devices instead when available. Patch 6/6 then use the vsp1
> > mapping API in the rcar-du-drm driver to map and unmap buffers when
> > needed.
> > 
> > The series has been tested on Gen2 (Lager) only as the Gen3 IOMMU is known
> > to be broken.
> 
> Slight clarification, the R-Car Gen3 family as a whole does not have
> broken IPMMU hardware. Early R-Car H3 revisions do require some errata
> handling though, but M3-W and later ES versions and MP of H3 will be
> fine. Given the early R-Car H3 errata I agree it makes sense to
> develop and test this series on R-Car Gen2 though.
> 
> > A possible improvement is to modify the GEM object allocation mechanism to
> > use non-contiguous memory when the DU driver detects that all the VSP
> > instances it is connected to use an IOMMU (possibly through FCP devices).
> > 
> > An issue has been noticed with synchronization between page flip and VSP
> > operation. Buffers get unmapped (and possibly freed) before the VSP is
> > done reading them. The problem isn't new, but is much more noticeable with
> > IOMMU support enabled as any hardware access to unmapped memory generates
> > an IOMMU page fault immediately.
> > 
> > The series unfortunately contain a dependency between DRM and V4L2
> > patches, complicating upstream merge. As there's no urgency to merge patch
> > 6/6 due to the IOMMU being broken on Gen3 at the moment, I propose merging
> > patches 1/6-2/6 and 3/6-5/6 independently for the next kernel release.
> > 
> > I would particularly appreciate feedback on the APIs introduced by patches
> > 4/6 and 5/6.
> 
> The code in general looks fine to me. The APIs introduced by patches
> 4/6 and 5/6 seem quite straightforward. Is there something I can do to
> help with those?
> 
> > [1]
> > https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg06589.h
> > tml
> > Laurent Pinchart (6):
> >   drm: Don't implement empty prepare_fb()/cleanup_fb()
> >   drm: Unconstify state argument to prepare_fb()/cleanup_fb()
> >   v4l: rcar-fcp: Don't get/put module reference
> >   v4l: rcar-fcp: Add an API to retrieve the FCP device
> >   v4l: vsp1: Add API to map and unmap DRM buffers through the VSP
> >   drm: rcar-du: Map memory through the VSP device
> >  
> >  drivers/gpu/drm/arc/arcpgu_crtc.c   |  2 -
> >  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c |  4 +-
> >  

[PATCH] fix spelling mistake: "dimesions" -> "dimensions"

[Colin King]

From: Colin Ian King 

Trivial fix to spelling mistake in DRM_ERROR message and split
over two lines to clean up a "line over 80 characters" checkpatch
warning.

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/vc4/vc4_validate.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_validate.c 
b/drivers/gpu/drm/vc4/vc4_validate.c
index da6f1e138e8d..8a9418b28fbb 100644
--- a/drivers/gpu/drm/vc4/vc4_validate.c
+++ b/drivers/gpu/drm/vc4/vc4_validate.c
@@ -172,7 +172,8 @@ vc4_check_tex_size(struct vc4_exec_info *exec, struct 
drm_gem_cma_object *fbo,
 * our math.
 */
if (width > 4096 || height > 4096) {
-   DRM_ERROR("Surface dimesions (%d,%d) too large", width, height);
+   DRM_ERROR("Surface dimensions (%d,%d) too large",
+ width, height);
return false;
}
 
-- 
2.11.0

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

[Bug 100891] failed to send pre message kernel output delays booting/suspending/resuming

[bugzilla-daemon]

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

--- Comment #4 from MichaelLong  ---
Created attachment 131352
  --> https://bugs.freedesktop.org/attachment.cgi?id=131352=edit
dmesg log 4.12-rc1

Still broken on 4.12-rc1

-- 
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: nouveau "eDP-1: EDID is invalid" regression after 4.11 with HP ZBook 15 G3

[Tommi Rantala]

Hi,

Bisected this to:

commit df8dc97cd17269474344d73cc02739532c468d04
Author: Ben Skeggs 
Date:   Wed Mar 1 09:42:04 2017 +1000

   drm/nouveau/kms/nv50: use drm core i2c-over-aux algorithm

   I'm not entirely sure NVKM needs to support this now, but I haven't
   removed it as of yet just in case it's needed from DEVINIT scripts
   where DRM isn't available.

   Signed-off-by: Ben Skeggs 


dmesg after boot with drm.debug enabled:

v4.10-10409-g5c68d91 (still works):
http://termbin.com/b0is

v4.10-10410-gdf8dc97 (failure):
http://termbin.com/j6lq


Tommi


2017-05-10 11:24 GMT+03:00 Tommi Rantala :
> Hi,
>
> The HP ZBook 15 G3 laptop builtin display (eDP-1) does not work
> correctly with v4.11-11413-g2868b25.
>
> When booting the laptop, the resolution seems to be limited to
> 1024x768, and gnome-session segfaults.
>
> Up to 4.11 the display works just fine in 1920x1080 mode.
>
> I'm seeing this in the kernel logs:
>
> nouveau :01:00.0: eDP-1: EDID is invalid:
> [00] BAD  00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
> [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff 84 53 54
> [00] BAD  66 69 50 55 57 66 74 49 48 ff ff ff ff ff ff ff
> [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [00] BAD  ff ff ff ff ff ff ff ff ff ff ff 00 00 ff 00 ff
> nouveau :01:00.0: DRM: DDC responded, but no EDID for eDP-1
> [drm] Cannot find any crtc or sizes - going 1024x768
>
>
> $ lspci | grep NVIDIA
> 01:00.0 VGA compatible controller: NVIDIA Corporation GM107GLM [Quadro
> M2000M] (rev a2)
>
> Any ideas, or should I bisect?
>
> 4.11 dmesg & xrandr output:
> https://pastebin.com/raw/P9LGP7e1
>
> 4.11-11413-g2868b25 dmesg:
> https://pastebin.com/raw/QBT9mMua
>
> -Tommi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Notifications about ACPI events in userspace?

[Lukas Wunner]

On Sun, May 14, 2017 at 11:25:48AM +0200, Florian Echtler wrote:
> On 14.05.2017 10:11, Lukas Wunner wrote:
> > On Sat, May 13, 2017 at 06:47:16PM +0200, Florian Echtler wrote:
> >> On 13.05.2017 14:18, Lukas Wunner wrote:
> >>> Then you could switch back and forth via the vga_switcheroo interface.
> >>
> >> Hm... since there's no power switching of any kind involved, would that
> >> still make sense?
> > 
> > The handler's ->power_state hook would be a no-op.  Obviously not pretty,
> > but we just don't have a better abstraction yet.  We represent an egress
> > connector on a graphics card as a drm_connector in sysfs.  What we might
> > need is a representation of a sink (display) in sysfs with symlinks to the
> > sources.  Such a source could be a drm_connector or something else
> > entirely (a GPU on another machine in your case).
> 
> OK, I think it's the closest thing that's already in the kernel, and before
> I add yet another custom sysfs node, vga_switcheroo is probably the easiest
> route to get things up and running.

Okay.  I'm only just now starting to get a vague idea how all this
may be represented properly.  On pre-Thunderbolt MacBook Pros it's
possible to switch the external DP port between GPUs independently
from the panel.  Right now we're switching both in unison, but if
we had a proper "sink with multiple sources" abstraction, we would
be able to support switching them separately.


> >> AFAICT, the alternative (which maybe would be more sensible, the more I
> >> think about it) would be to export applesmc_{read,write}_key as public
> >> symbols and just access them from a standalone driver for the APP000C
> >> ACPI device. Since that should only be present on a Mac that actually
> >> supports TDM, there's also no risk of writing to arbitrary SMC keys on
> >> unsupported devices.
> > 
> > That might make sense if you feel the driver will grow large enough to
> > make applesmc.c look messy, or if you feel it just doesn't fit there.
> 
> Everything else in applesmc.c is hwmon-related, IMHO it would be a kludge.
> So for applesmc, I'd just need a tiny patch to export the main key access
> functions, and everything else can (hopefully) be encapsulated in an
> "apple-tdm" driver.

Sounds reasonable.  You can probably copy/paste a lot of boilerplate
from apple-gmux.c and just bind to APP000C instead of APP000B.

You may need to add APP000C to acpi_pnp_device_ids[] in
drivers/acpi/acpi_pnp.c for the driver to bind to the device.

The vga_switcheroo "switch" file will appear in sysfs as soon as a
handler and 2 clients have registered.  The handler only needs to
implement the ->switchto and ->get_client_id hooks, all others are
optional.  The ->get_client_id hook should probably return
VGA_SWITCHEROO_IGD for the Nvidia GPU built into the iMac and
VGA_SWITCHEROO_DIS for the external port.

The vga_switcheroo_client is normally a PCI device, I guess you
could use the LPC bridge as a placeholder (the grandparent of the
APP000C device).  The ->set_gpu_state hook would be a no-op and
->can_switch could always return true.  If you register that client
whenever something is plugged in and unregister it on unplug, the
"switch" file in sysfs appears only as long as something is plugged in.


> > I guess the only reason why Apple integrated the functionality into the
> > SMC is because they wanted to support TDM when the machine is powered off.
> > The SMC is powered even in S5 (if the iMac is connected to AC), it just
> > needs to monitor HPD on the external port and turn on the backlight if
> > something is plugged in.  (I'm not sure if TDM is actually supported
> > during poweroff but technically it would seem to be supported.)
> 
> Hm, interesting, I hadn't yet thought of that. This would of course be
> excellent, because right now it looks like a waste of power to run the
> whole machine just because of the display.
> 
> Does the SMC have control over the backlight? Do you know which keys are
> responsible? IIRC the apple_bl.c driver didn't work on my iMac anyway...

The panel is attached to power rails which are only active in S0
(PP12V_S0_LCD and PP3V3_S0_VIDEO).

Conceivably, the SMC could sense HPD and bring up those power rails.
However various other things are hanging off of the same rails,
e.g. fan, memory, optical disk drive, and they would be powered up
as well.  Essentially the whole machine would boot, but perhaps
the EFI firmware senses if powerup was only triggered by DP hotplug
and not boot an OS.  Have you tested what happens if you plug
something in while the iMac is off?

Thanks,

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

[drm-intel:drm-intel-next-queued 4/7] drivers/gpu/drm/i915/i915_syncmap.c:285:45-51: ERROR: application of sizeof to pointer

[kbuild test robot]

tree:   git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head:   49f08598bf7a52eadebda851a5e8e6fa1dc2e15e
commit: 4797948071f607c5b43753cb8f1b7ddcf22e146d [4/7] drm/i915: Squash 
repeated awaits on the same fence


coccinelle warnings: (new ones prefixed by >>)

>> drivers/gpu/drm/i915/i915_syncmap.c:285:45-51: ERROR: application of sizeof 
>> to pointer

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/i915: fix noderef.cocci warnings

[kbuild test robot]

drivers/gpu/drm/i915/i915_syncmap.c:285:45-51: ERROR: application of sizeof to 
pointer

 sizeof when applied to a pointer typed expression gives the size of
 the pointer

Generated by: scripts/coccinelle/misc/noderef.cocci

Signed-off-by: Fengguang Wu 
---

 i915_syncmap.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/i915/i915_syncmap.c
+++ b/drivers/gpu/drm/i915/i915_syncmap.c
@@ -282,7 +282,7 @@ static noinline int __sync_set(struct i9
unsigned int above;
 
/* Insert a join above the current layer */
-   next = kzalloc(sizeof(*next) + KSYNCMAP * sizeof(next),
+   next = kzalloc(sizeof(*next) + KSYNCMAP * sizeof(*next),
   GFP_KERNEL);
if (unlikely(!next))
return -ENOMEM;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 5/8] drm: Use new mode_valid() helpers in connector probe helper

[Laurent Pinchart]

Hi Jose,

On Friday 12 May 2017 17:06:14 Jose Abreu wrote:
> On 12-05-2017 10:35, Laurent Pinchart wrote:
> > On Tuesday 09 May 2017 18:00:12 Jose Abreu wrote:
> >> This changes the connector probe helper function to use the new
> >> encoder->mode_valid() and crtc->mode_valid() helper callbacks to
> >> validate the modes.
> >> 
> >> The new callbacks are optional so the behaviour remains the same
> >> if they are not implemented. If they are, then the code loops
> >> through all the connector's encodersXcrtcs and calls the
> >> callback.
> >> 
> >> If at least a valid encoderXcrtc combination is found which
> >> accepts the mode then the function returns MODE_OK.
> >> 
> >> Signed-off-by: Jose Abreu 
> >> Cc: Carlos Palminha 
> >> Cc: Alexey Brodkin 
> >> Cc: Ville Syrjälä 
> >> Cc: Daniel Vetter 
> >> Cc: Dave Airlie 
> >> Cc: Andrzej Hajda 
> >> Cc: Archit Taneja 
> >> ---
> >> 
> >> Changes v1->v2:
> >>- Use new helpers suggested by Ville
> >>- Change documentation (Daniel)
> >>
> >>  drivers/gpu/drm/drm_probe_helper.c | 60 ++--
> >>  1 file changed, 57 insertions(+), 3 deletions(-)
> >> 
> >> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> >> b/drivers/gpu/drm/drm_probe_helper.c index 1b0c14a..de47413 100644
> >> --- a/drivers/gpu/drm/drm_probe_helper.c
> >> +++ b/drivers/gpu/drm/drm_probe_helper.c

[snip]

> >> +static enum drm_mode_status
> >> +drm_mode_validate_connector(struct drm_connector *connector,
> >> +  struct drm_display_mode *mode)
> > 
> > This does more than validating the mode against the connector, it
> > validates it against the whole pipeline. I would call the function
> > drm_mode_validate_pipeline() (or any other similar name).
> 
> Yeah, in previous version I had something similar but I changed
> in order to address review comments. I can change again though...

Sorry, I haven't seen v1. I think it makes more sense to reflect in its name 
the fact that the function validates the mode against the whole pipeline, but 
I'll let others disagree.

> >> +{
> >> +  struct drm_device *dev = connector->dev;
> >> +  uint32_t *ids = connector->encoder_ids;
> >> +  enum drm_mode_status ret = MODE_OK;
> >> +  unsigned int i;
> >> +
> >> +  /* Step 1: Validate against connector */
> >> +  ret = drm_connector_mode_valid(connector, mode);
> >> +  if (ret != MODE_OK)
> >> +  return ret;
> >> +
> >> +  /* Step 2: Validate against encoders and crtcs */
> >> +  for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) {
> >> +  struct drm_encoder *encoder = drm_encoder_find(dev, ids[i]);
> >> +  struct drm_crtc *crtc;
> >> +
> >> +  if (!encoder)
> >> +  continue;
> >> +
> >> +  ret = drm_encoder_mode_valid(encoder, mode);
> >> +  if (ret != MODE_OK) {
> >> +  /* No point in continuing for crtc check as this
> > 
> > encoder
> > 
> >> +   * will not accept the mode anyway. If all encoders
> >> +   * reject the mode then, at exit, ret will not be
> >> +   * MODE_OK. */
> >> +  continue;
> >> +  }
> >> +
> >> +  drm_for_each_crtc(crtc, dev) {
> >> +  if (!drm_encoder_crtc_ok(encoder, crtc))
> >> +  continue;
> >> +
> >> +  ret = drm_crtc_mode_valid(crtc, mode);
> >> +  if (ret == MODE_OK) {
> >> +  /* If we get to this point there is at least
> >> +   * one combination of encoder+crtc that works
> >> +   * for this mode. Lets return now. */
> >> +  return ret;
> >> +  }
> >> +  }
> >> +  }
> >> +
> >> +  return ret;
> >> +}

[snip]

> >> @@ -428,8 +482,8 @@ int
> >> drm_helper_probe_single_connector_modes(struct drm_connector *connector,
> >> 
> >>if (mode->status == MODE_OK)
> >>
> >>mode->status = drm_mode_validate_flag(mode,
> >> 
> >> mode_flags);
> >> 
> >> -  if (mode->status == MODE_OK && connector_funcs->mode_valid)
> >> -  mode->status = connector_funcs->mode_valid(connector,
> >> +  if (mode->status == MODE_OK)
> >> +  mode->status = drm_mode_validate_connector(connector,
> >> 
> >>   mode);
> > 
> > I would reverse the arguments order to match the style of the other
> > validation functions.
> 
> Hmm, I think it makes more sense to pass connector first and then
> mode ...

I disagree, as this function validates a mode against a pipeline, the same way 
the other validation functions validate a mode against other parameters, but 
it's your patch :-)

-- 
Regards,

Re: [Intel-gfx] [PATCH 1/2] drm/dp: start a DPCD based DP sink/branch device quirk database

[Daniel Vetter]

On Fri, May 12, 2017 at 9:57 AM, Jani Nikula  wrote:
> Personally I don't think enums should be used for defining bits, because
> they are not enumerations. The bits are usually combined to come up with
> values that are not part of the enum.
>
> If we added the quirks to struct intel_dp_desc (and moved to drm
> helpers) we could use enums for defining the bit shifts and add a
> function to query for a specific quirk, say, drm_dp_has_quirk(struct
> drm_dp_desc *desc, enum drm_dpcd_quirk quirk).

It's a bit a gnu-ism afaik, but enums-as-bitfields is very much
standard. gdb even decodes it for you into the individual bits iirc.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101037] nouveau: crash when starting chrome

[bugzilla-daemon]

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

--- Comment #1 from Michal Suchanek  ---
Created attachment 131345
  --> https://bugs.freedesktop.org/attachment.cgi?id=131345=edit
kernel log piieces showiing the error

-- 
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 101037] nouveau: crash when starting chrome

[bugzilla-daemon]

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

Bug ID: 101037
   Summary: nouveau: crash when starting chrome
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/other
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: hramr...@gmail.com

01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G98 [Quadro NVS
295] [10de:06fd] (rev a1)
Linux 4.10.0-trunk-amd64 #1 SMP Debian 4.10.7-1~exp1 (2017-03-30) x86_64 
libdrm-nouveau2 2.4.80-1
libgl1-mesa-dri 17.0.4-1
xserver-xorg-video-nouveau 1:1.0.15-1

May 14 09:34:36 iscsi kernel: [  482.205629] BUG: unable to handle kernel NULL
pointer dereference at 0021
May 14 09:34:36 iscsi kernel: [  482.205629] BUG: unable to handle kernel NULL
pointer dereference at 0021
May 14 09:34:36 iscsi kernel: [  482.205654] IP:
dma_fence_wait_timeout+0x30/0xf0
May 14 09:34:36 iscsi kernel: [  482.205654] IP:
dma_fence_wait_timeout+0x30/0xf0
May 14 09:34:36 iscsi kernel: [  482.205659] PGD 0 
May 14 09:34:36 iscsi kernel: [  482.205659] PGD 0 
May 14 09:34:36 iscsi kernel: [  482.205766] CPU: 1 PID: 1696 Comm: InputThread
Tainted: G   OE   4.10.0-trunk-amd64 #1 Debian 4.10.7-1~exp1
May 14 09:34:36 iscsi kernel: [  482.205772] Hardware name: 
/DQ45CB, BIOS CBQ4510H.86A.0133.2011.0810.1010 08/10/2011
May 14 09:34:36 iscsi kernel: [  482.205777] task: 8a4d2c13afc0 task.stack:
b8c2416e
May 14 09:34:36 iscsi kernel: [  482.205781] RIP:
0010:dma_fence_wait_timeout+0x30/0xf0
May 14 09:34:36 iscsi kernel: [  482.205785] RSP: 0018:b8c2416e3aa0 EFLAGS:
00010206
May 14 09:34:36 iscsi kernel: [  482.205789] RAX: 0001 RBX:
8a4c9a817480 RCX: c07cffa0
May 14 09:34:36 iscsi kernel: [  482.205794] RDX: 7fff RSI:
0001 RDI: 8a4d2c27c600
May 14 09:34:36 iscsi kernel: [  482.205798] RBP: 8a4d2c27c600 R08:
8a4d2c3e9000 R09: 
May 14 09:34:36 iscsi kernel: [  482.205802] R10: 8a4d302763a8 R11:
8a4d314bb600 R12: 0001
May 14 09:34:36 iscsi kernel: [  482.205807] R13: 7fff R14:
0001 R15: 0001
May 14 09:34:36 iscsi kernel: [  482.205811] FS:  7f341c83e700()
GS:8a4d3bc8() knlGS:
May 14 09:34:36 iscsi kernel: [  482.205819] CS:  0010 DS:  ES:  CR0:
80050033
May 14 09:34:36 iscsi kernel: [  482.205823] CR2: 0021 CR3:
00022c2bc000 CR4: 000406e0
May 14 09:34:36 iscsi kernel: [  482.205828] Call Trace:
May 14 09:34:36 iscsi kernel: [  482.205843]  ?
drm_atomic_helper_wait_for_fences+0x48/0x130 [drm_kms_helper]
May 14 09:34:36 iscsi kernel: [  482.205895]  ?
nv50_disp_atomic_commit+0x18e/0x290 [nouveau]
May 14 09:34:36 iscsi kernel: [  482.205902]  ?
drm_atomic_helper_update_plane+0xeb/0x150 [drm_kms_helper]
May 14 09:34:36 iscsi kernel: [  482.205928]  ? __setplane_internal+0x1d9/0x2a0
[drm]
May 14 09:34:36 iscsi kernel: [  482.205939]  ?
drm_mode_cursor_universal+0x11c/0x200 [drm]
May 14 09:34:36 iscsi kernel: [  482.205950]  ?
drm_mode_cursor_common+0x80/0x170 [drm]
May 14 09:34:36 iscsi kernel: [  482.205961]  ? drm_mode_cursor_ioctl+0x54/0x70
[drm]
May 14 09:34:36 iscsi kernel: [  482.205973]  ? drm_ioctl+0x1ea/0x470 [drm]
May 14 09:34:36 iscsi kernel: [  482.205978]  ? __schedule+0x23b/0x6f0
May 14 09:34:36 iscsi kernel: [  482.205989]  ? drm_mode_setplane+0x1a0/0x1a0
[drm]
May 14 09:34:36 iscsi kernel: [  482.205994]  ? _copy_to_user+0x4d/0x60
May 14 09:34:36 iscsi kernel: [  482.206022]  ? nouveau_drm_ioctl+0x66/0xc0
[nouveau]
May 14 09:34:36 iscsi kernel: [  482.206027]  ? do_vfs_ioctl+0x9f/0x600
May 14 09:34:36 iscsi kernel: [  482.206032]  ? __check_object_size+0xfb/0x1d9
May 14 09:34:36 iscsi kernel: [  482.206035]  ? SyS_ioctl+0x74/0x80
May 14 09:34:36 iscsi kernel: [  482.206039]  ?
system_call_fast_compare_end+0xc/0x9b
May 14 09:34:36 iscsi kernel: [  482.206043] Code: 48 85 d2 41 55 41 54 55 53
0f 88 ab 00 00 00 48 89 fd 41 89 f4 49 89 d5 66 66 66 66 90 48 8b 45 08 41 0f
b6 f4 4c 89 ea 48 89 ef  50 20 49 89 c4 66 66 66 66 90 5b 4c 89 e0 5d 41 5c
41 5d c3 
May 14 09:34:36 iscsi kernel: [  482.206069] RIP:
dma_fence_wait_timeout+0x30/0xf0 RSP: b8c2416e3aa0

-- 
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: Notifications about ACPI events in userspace?

[Lukas Wunner]

On Sat, May 13, 2017 at 06:47:16PM +0200, Florian Echtler wrote:
> On 13.05.2017 14:18, Lukas Wunner wrote:
> > 
> > So to sum it up, the built-in panel on the iMac can be driven by a
> > separate machine and we can switch between the two sources via the SMC.
> >
> > [...]
> >
> > I guess you could register a vga_switcheroo handler which controls
> > switching via the SMC.  You'd also have to register a vga_switcheroo
> > client whenever you detect hotplug of an external source (and unregister
> > on unplug).  The client is normally a DRM driver but would in this case
> > just be a pseudo device.
> > 
> > Then you could switch back and forth via the vga_switcheroo interface.
> 
> Hm... since there's no power switching of any kind involved, would that
> still make sense?

The handler's ->power_state hook would be a no-op.  Obviously not pretty,
but we just don't have a better abstraction yet.  We represent an egress
connector on a graphics card as a drm_connector in sysfs.  What we might
need is a representation of a sink (display) in sysfs with symlinks to the
sources.  Such a source could be a drm_connector or something else
entirely (a GPU on another machine in your case).


> > > Since I need to modify the applesmc.c driver anyway, it would probably
> > > make sense to integrate the notify handler there?
> > 
> > Sounds reasonable to me.
> 
> AFAICT, the alternative (which maybe would be more sensible, the more I
> think about it) would be to export applesmc_{read,write}_key as public
> symbols and just access them from a standalone driver for the APP000C
> ACPI device. Since that should only be present on a Mac that actually
> supports TDM, there's also no risk of writing to arbitrary SMC keys on
> unsupported devices.

That might make sense if you feel the driver will grow large enough to
make applesmc.c look messy, or if you feel it just doesn't fit there.

I guess the only reason why Apple integrated the functionality into the
SMC is because they wanted to support TDM when the machine is powered off.
The SMC is powered even in S5 (if the iMac is connected to AC), it just
needs to monitor HPD on the external port and turn on the backlight if
something is plugged in.  (I'm not sure if TDM is actually supported
during poweroff but technically it would seem to be supported.)

Otherwise I've got no opinion on that, adding Nicolas Boichat and Henrik
Rydberg to cc in case they have one.


> > Which iMac model are you developing this on exactly, a 2009/2010 model
> > (without Thunderbolt) or a newer one?  The newer ones can only be driven
> > via DP-over-Thunderbolt tunnels, so the HPD pin is coming from the
> > Thunderbolt controller, not the socket.  We don't have support for
> > setting up DP-over-Thunderbolt tunnels in thunderbolt.ko yet, only
> > PCIe-over-Thunderbolt is supported.  If the external source is already
> > present on boot, the tunnel may be established by the Thunderbolt EFI
> > driver but will be gone after unplug.
> 
> I have a 2009/2010 model, so no Thunderbolt.

Good!  Makes everything a lot simpler.

Thanks,

Lukas

> If someone is feeling adventurous
> with a Thunderbolt iMac, feel free to poke the SMC. I've written a short blog
> post that should be sufficient as background information for some initial
> experiments: http://floe.butterbrot.org/matrix/hacking/tdm/ and
> https://github.com/floe/smc_util (in particular, look at tdm_{on,off}.sh).
> 
> Best, Florian
> -- 
> SENT FROM MY DEC VT50 TERMINAL
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel