[radeon-alex:drm-next-4.17-wip 148/164] drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vega12_smumgr.c:281:56: sparse: constant 0xFFFFFFFF00000000 is so big it is unsigned long

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git drm-next-4.17-wip
head:   a611dd16c69025b6df115427af0a5d63ae9f5145
commit: 2cac05dee6e309bb21424c7d59c62f662d01309e [148/164] drm/amd/powerplay: 
add the hw manager for vega12 (v4)
reproduce:
# apt-get install sparse
git checkout 2cac05dee6e309bb21424c7d59c62f662d01309e
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vega12_smumgr.c:281:56: 
>> sparse: constant 0x is so big it is unsigned long
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vega12_smumgr.c:332:85: 
sparse: constant 0x is so big it is unsigned long
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vega12_smumgr.c:93:5: sparse: 
symbol 'vega12_send_msg_to_smc_without_waiting' was not declared. Should it be 
static?
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vega12_smumgr.c:111:5: 
sparse: symbol 'vega12_send_msg_to_smc' was not declared. Should it be static?
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vega12_smumgr.c:136:5: 
sparse: symbol 'vega12_send_msg_to_smc_with_parameter' was not declared. Should 
it be static?
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vega12_smumgr.c:167:5: 
sparse: symbol 'vega12_send_msg_to_smc_with_parameter_without_waiting' was not 
declared. Should it be static?
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vega12_smumgr.c:551:29: 
sparse: symbol 'vega12_smu_funcs' was not declared. Should it be static?
--
>> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega12_processpptables.c:312:25:
>>  sparse: cast to restricted __le32
   
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega12_processpptables.c:294:5: 
sparse: symbol 'vega12_pp_tables_initialize' was not declared. Should it be 
static?
--
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega12_hwmgr.c:61:27: sparse: 
symbol 'cast_phw_vega12_power_state' was not declared. Should it be static?
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega12_hwmgr.c:71:33: sparse: 
symbol 'cast_const_phw_vega12_power_state' was not declared. Should it be 
static?
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega12_hwmgr.c:1333:5: sparse: 
symbol 'vega12_display_clock_voltage_request' was not declared. Should it be 
static?
>> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega12_hwmgr.c:1846:69: 
>> sparse: incorrect type in assignment (different base types) @@expected 
>> unsigned short [unsigned] [usertype] MinClock @@got  short [unsigned] 
>> [usertype] MinClock @@
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega12_hwmgr.c:1846:69:
expected unsigned short [unsigned] [usertype] MinClock
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega12_hwmgr.c:1846:69:got 
restricted __le16 [usertype] 
>> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega12_hwmgr.c:1850:69: 
>> sparse: incorrect type in assignment (different base types) @@expected 
>> unsigned short [unsigned] [usertype] MaxClock @@got  short [unsigned] 
>> [usertype] MaxClock @@
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega12_hwmgr.c:1850:69:
expected unsigned short [unsigned] [usertype] MaxClock
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega12_hwmgr.c:1850:69:got 
restricted __le16 [usertype] 
>> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega12_hwmgr.c:1854:68: 
>> sparse: incorrect type in assignment (different base types) @@expected 
>> unsigned short [unsigned] [usertype] MinUclk @@got  short [unsigned] 
>> [usertype] MinUclk @@
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega12_hwmgr.c:1854:68:
expected unsigned short [unsigned] [usertype] MinUclk
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega12_hwmgr.c:1854:68:got 
restricted __le16 [usertype] 
>> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega12_hwmgr.c:1858:68: 
>> sparse: incorrect type in assignment (different base types) @@expected 
>> unsigned short [unsigned] [usertype] MaxUclk @@got  short [unsigned] 
>> [usertype] MaxUclk @@
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega12_hwmgr.c:1858:68:
expected unsigned short [unsigned] [usertype] MaxUclk
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega12_hwmgr.c:1858:68:got 
restricted __le16 [usertype] 
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega12_hwmgr.c:1867:68: 
sparse: incorrect type in assignment (different base types) @@expected 
unsigned short [unsigned] [usertype] MinClock @@got  short [unsigned] 
[usertype] MinClock @@
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega12_hwmgr.c:1867:68:
expected unsigned short [unsigned] [usertype] MinClock
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega12_hwmgr.c:1867:68:got 
restricted __le16 [usertype] 
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega12_hwmgr.c:1871:68: 
sparse: incorrect type in assignment (different base types) @@expected 
unsigned 

[radeon-alex:amd-staging-drm-next 699/993] sound/soc/amd/raven/acp3x-pcm-dma.c:246:10: error: implicit declaration of function 'page_to_phys'; did you mean 'page_to_pfn'?

[kbuild test robot]

Hi Maruthi,

FYI, the error/warning still remains.

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   2b50aeab552432fab618856c1721cb2bfc7d4c1a
commit: 944b5289c92d9c1aad3760c012daf4cf2478381f [699/993] ASoC: AMD: enable 
ACP3x drivers build
config: tile-allyesconfig (attached as .config)
compiler: tilegx-linux-gcc (GCC) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 944b5289c92d9c1aad3760c012daf4cf2478381f
# 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:9: error: implicit declaration of function 
'readl'; did you mean 'vread'? [-Werror=implicit-function-declaration]
 return readl(base_addr - ACP3x_PHY_BASE_ADDRESS);
^
vread
   sound/soc/amd/raven/acp3x.h: In function 'rv_writel':
   sound/soc/amd/raven/acp3x.h:33:2: error: implicit declaration of function 
'writel'; did you mean 'vwrite'? [-Werror=implicit-function-declaration]
 writel(val, base_addr - ACP3x_PHY_BASE_ADDRESS);
 ^~
 vwrite
   sound/soc/amd/raven/acp3x-pcm-dma.c: In function 'config_acp3x_dma':
>> sound/soc/amd/raven/acp3x-pcm-dma.c:246:10: error: implicit declaration of 
>> function 'page_to_phys'; did you mean 'page_to_pfn'? 
>> [-Werror=implicit-function-declaration]
  addr = page_to_phys(pg);
 ^~~~
 page_to_pfn
   sound/soc/amd/raven/acp3x-pcm-dma.c: In function 'acp3x_audio_probe':
   sound/soc/amd/raven/acp3x-pcm-dma.c:638:22: error: implicit declaration of 
function 'devm_ioremap'; did you mean 'devm_kmemdup'? 
[-Werror=implicit-function-declaration]
 adata->acp3x_base = devm_ioremap(>dev, res->start,
 ^~~~
 devm_kmemdup
   sound/soc/amd/raven/acp3x-pcm-dma.c:638:20: warning: assignment makes 
pointer from integer without a cast [-Wint-conversion]
 adata->acp3x_base = devm_ioremap(>dev, res->start,
   ^
   cc1: some warnings being treated as errors

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

68f9fb0c Maruthi Srinivas Bayyavarapu 2017-03-30  222  
afdf7669 Maruthi Srinivas Bayyavarapu 2017-03-29  223  static void 
config_acp3x_dma(struct i2s_stream_instance *rtd, int direction)
afdf7669 Maruthi Srinivas Bayyavarapu 2017-03-29  224  {
afdf7669 Maruthi Srinivas Bayyavarapu 2017-03-29  225   u16 page_idx;
afdf7669 Maruthi Srinivas Bayyavarapu 2017-03-29  226   u64 addr;
afdf7669 Maruthi Srinivas Bayyavarapu 2017-03-29  227   u32 low, high, val, 
acp_fifo_addr;
afdf7669 Maruthi Srinivas Bayyavarapu 2017-03-29  228   struct page *pg = 
rtd->pg;
afdf7669 Maruthi Srinivas Bayyavarapu 2017-03-29  229  
afdf7669 Maruthi Srinivas Bayyavarapu 2017-03-29  230   /* 8 scratch registers 
used to map one 64 bit address.
afdf7669 Maruthi Srinivas Bayyavarapu 2017-03-29  231* For 2 pages (4096 * 
2 bytes), it will be 16 registers.
afdf7669 Maruthi Srinivas Bayyavarapu 2017-03-29  232*/
afdf7669 Maruthi Srinivas Bayyavarapu 2017-03-29  233   if (direction == 
SNDRV_PCM_STREAM_PLAYBACK)
afdf7669 Maruthi Srinivas Bayyavarapu 2017-03-29  234   val = 0;
afdf7669 Maruthi Srinivas Bayyavarapu 2017-03-29  235   else
afdf7669 Maruthi Srinivas Bayyavarapu 2017-03-29  236   val = 16;
afdf7669 Maruthi Srinivas Bayyavarapu 2017-03-29  237  
afdf7669 Maruthi Srinivas Bayyavarapu 2017-03-29  238   /* Group Enable */
afdf7669 Maruthi Srinivas Bayyavarapu 2017-03-29  239   
rv_writel(ACP_SRAM_PTE_OFFSET | BIT(31), rtd->acp3x_base +
afdf7669 Maruthi Srinivas Bayyavarapu 2017-03-29  240   
mmACPAXI2AXI_ATU_BASE_ADDR_GRP_1);
afdf7669 Maruthi Srinivas Bayyavarapu 2017-03-29  241   
rv_writel(PAGE_SIZE_4K_ENABLE, rtd->acp3x_base +
afdf7669 Maruthi Srinivas Bayyavarapu 2017-03-29  242   
mmACPAXI2AXI_ATU_PAGE_SIZE_GRP_1);
afdf7669 Maruthi Srinivas Bayyavarapu 2017-03-29  243  
afdf7669 Maruthi Srinivas Bayyavarapu 2017-03-29  244   for (page_idx = 0; 
page_idx < rtd->num_pages; page_idx++) {
afdf7669 Maruthi Srinivas Bayyavarapu 2017-03-29  245   /* Load the low 
address of page int ACP SRAM through SRBM */
afdf7669 Maruthi Srinivas Bayyavarapu 2017-03-29 @246   addr = 
page_to_phys(pg);
afdf7669 Maruthi Srinivas Bayyavarapu 2017-03-29  247   low = 
lower_32_bits(addr);
afdf7669 Maruthi Srinivas Bayyavarapu 2017-03-29  248   high = 
upper_32_bits(addr);
afdf7669 Maruthi Srinivas Bayyavarapu 2017-03-29  249  
afdf7669 Maruthi Srinivas Bayyavarapu 2017-03-29  250   rv_writel(low, 
rtd->acp3x_base + mmACP_SCRATCH_REG_0 + val);
afdf7669 Maruthi Srinivas Bayyavarapu 2017-03-29  251   high |= BIT(31);

[Bug 104082] amdgpu 0000:07:00.0: swiotlb buffer is full (sz: 2097152 bytes)

[bugzilla-daemon]

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

mikhail.v.gavri...@gmail.com changed:

   What|Removed |Added

 Attachment #138301|dmesh 4.16-rc6  |dmesg 4.16-rc6
description||

-- 
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 104082] amdgpu 0000:07:00.0: swiotlb buffer is full (sz: 2097152 bytes)

[bugzilla-daemon]

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

--- Comment #37 from mikhail.v.gavri...@gmail.com ---
Created attachment 138301
  --> https://bugs.freedesktop.org/attachment.cgi?id=138301=edit
dmesh 4.16-rc6

-- 
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 104082] amdgpu 0000:07:00.0: swiotlb buffer is full (sz: 2097152 bytes)

[bugzilla-daemon]

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

--- Comment #36 from mikhail.v.gavri...@gmail.com ---
In which kernel mainline version merged patch for this issue?
I see that on `amd-staging-drm-next` branch which branched from 4.16-rc1 this
issue not happens now, but on mainline 4.16-rc6 still actively occurred again
and again.

-- 
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 199157] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=199157

--- Comment #3 from Kyle De'Vir (kyle.de...@mykolab.com) ---
GPU-wise, I have an RX580 8GB. This morning, I started to wonder whether the
issue was not even be a driver bug, but actually related to the whole
"Performance Marginality Problem", as my AMD 1600X is one of the CPUs affected
by Ryzen hardware bug. A while ago, I started getting random MCEs, which I
suspected were related to the Ryzen bug. They stopped a while later,
mysteriously... then it was occasional hard-lockups, then this issue. 

I'm trying to save up money for Ryzen 2, so hopefully this issue won't pop up
again.

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

[Bug 199157] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=199157

--- Comment #2 from Kyle De'Vir (kyle.de...@mykolab.com) ---
Created attachment 274891
  --> https://bugzilla.kernel.org/attachment.cgi?id=274891=edit
dmesg log

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

[Bug 105684] Loading amdgpu hits general protection fault: 0000 [#1] SMP NOPTI

[bugzilla-daemon]

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

--- Comment #13 from jian-h...@endlessm.com ---
Because system hangs up after loading amdgpu module, I cannot get dmesg
directly at that time.
Therefore, I load efi-pstore module to store the dmesg in efi before panic
happens.

The attachments:
"dmesg before loading amdgpu module": dmesg before loading amdgpu module
"Oops1~7 after loading amdgpu module": I gather the dmesg stored in efi-pstore,
which is during the panic happening.  I concatenate them with the Oops number
and order by the part number.

-- 
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 105684] Loading amdgpu hits general protection fault: 0000 [#1] SMP NOPTI

[bugzilla-daemon]

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

--- Comment #12 from jian-h...@endlessm.com ---
Created attachment 138300
  --> https://bugs.freedesktop.org/attachment.cgi?id=138300=edit
Oops7 after loading amdgpu module

-- 
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 105684] Loading amdgpu hits general protection fault: 0000 [#1] SMP NOPTI

[bugzilla-daemon]

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

--- Comment #11 from jian-h...@endlessm.com ---
Created attachment 138299
  --> https://bugs.freedesktop.org/attachment.cgi?id=138299=edit
Oops6 after loading amdgpu module

-- 
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 105684] Loading amdgpu hits general protection fault: 0000 [#1] SMP NOPTI

[bugzilla-daemon]

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

--- Comment #10 from jian-h...@endlessm.com ---
Created attachment 138298
  --> https://bugs.freedesktop.org/attachment.cgi?id=138298=edit
Oops5 after loading amdgpu module

-- 
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 105684] Loading amdgpu hits general protection fault: 0000 [#1] SMP NOPTI

[bugzilla-daemon]

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

--- Comment #9 from jian-h...@endlessm.com ---
Created attachment 138297
  --> https://bugs.freedesktop.org/attachment.cgi?id=138297=edit
Oops4 after loading amdgpu module

-- 
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 105684] Loading amdgpu hits general protection fault: 0000 [#1] SMP NOPTI

[bugzilla-daemon]

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

--- Comment #7 from jian-h...@endlessm.com ---
Created attachment 138295
  --> https://bugs.freedesktop.org/attachment.cgi?id=138295=edit
Oops2 after loading amdgpu module

-- 
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 105684] Loading amdgpu hits general protection fault: 0000 [#1] SMP NOPTI

[bugzilla-daemon]

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

--- Comment #8 from jian-h...@endlessm.com ---
Created attachment 138296
  --> https://bugs.freedesktop.org/attachment.cgi?id=138296=edit
Oops3 after loading amdgpu module

-- 
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 105684] Loading amdgpu hits general protection fault: 0000 [#1] SMP NOPTI

[bugzilla-daemon]

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

--- Comment #6 from jian-h...@endlessm.com ---
Created attachment 138294
  --> https://bugs.freedesktop.org/attachment.cgi?id=138294=edit
Oops1 after loading amdgpu module

-- 
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 105684] Loading amdgpu hits general protection fault: 0000 [#1] SMP NOPTI

[bugzilla-daemon]

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

--- Comment #5 from jian-h...@endlessm.com ---
Created attachment 138293
  --> https://bugs.freedesktop.org/attachment.cgi?id=138293=edit
dmesg before loading amdgpu module

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

Re: [PATCH] drm/i915/gvt/scheduler: Remove unnecessary NULL checks in sr_oa_regs

[Zhenyu Wang]

On 2018.03.22 21:31:33 +, Chris Wilson wrote:
> Quoting Gustavo A. R. Silva (2018-03-22 18:21:54)
> > The checks are misleading and not required [1].
> > 
> > [1] https://lkml.org/lkml/2018/3/19/1792
> > 
> > Addresses-Coverity-ID: 1466017
> > Cc: Chris Wilson 
> > Signed-off-by: Gustavo A. R. Silva 
> Reviewed-by: Chris Wilson 
> 

Looks good to me, I will pick this up, thanks!

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


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

[Bug 104193] [radeonsi] The Witcher 3 freezes the system with no attachments calls & transform feedback Wine patch

[bugzilla-daemon]

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

--- Comment #8 from Shmerl  ---
I got a new Sapphire Pulse Vega 56, and when using it - no freezes, I tested
multiple times. It's possible, that with RX 480 it exposed some kind of
hardware defect, hard to tell.

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

Re: [Patch 2/4] dt-bindings: display/ti: Add plane binding to dispc node

[Rob Herring]

On Mon, Mar 19, 2018 at 2:15 AM, Tomi Valkeinen  wrote:
> Hi Rob,
>
> On 19/03/18 02:06, Rob Herring wrote:
>> On Wed, Mar 14, 2018 at 6:23 AM, Tomi Valkeinen  
>> wrote:
>>> On 09/03/18 20:27, Benoit Parrot wrote:
>>>
> Is logical plane a h/w concept?

 It does represent a hardware resource.
>>>
>>> Logical plane is not a hw concept, it just describes a group of one or
>>> two HW planes. Then again, in the context of 2k+ displays, two HW planes
>>> must always be used together, so that way it could be considered a
>>> single HW resource.
>>>
> Really, I'm skeptical that any of this belongs in DT. For example,
> can't you figure out you need 2 physical planes whenever your
> panel/timing width is greater than 2048?

 As stated in the description I added above, we cannot have resources
 exposed to user-space which can "disappear" dynamically.
 Doing so would break user-space applications which rely on these
 resources.
>>
>> Isn't this the point of atomic mode setting? If you have 2 planes
>> free, then you can support the mode, otherwise you fail. How would a
>> plane be in use if you are doing modesetting unless it is on another
>> display?
>>
>>> The question is, if not in DT, then where? I agree that this is not
>>> exactly describing the HW. But it can't be done dynamically either (or
>>> at least we have not figured out a way). And it must be user configurable.
>>
>> If you are plugging in a monitor, doesn't it have to be dynamic?
>>
>>> Module parameters are an option, but it would be somewhat difficult to
>>> give all this information there. And also, if your board has a 2k+
>>> display, you must have these configurations given to the driver, it's
>>> not optional.
>>
>> Can't you look at the panel size on boot or module load and determine
>> if you need to combine planes or not. The main difference I see is
>> that the driver would have to figure out which planes to use rather
>> than DT telling it what planes to use. Is deciding which planes a hard
>> problem?
>
> Ok, I think the description was a bit unclear. So, the driver can do
> this just fine, it can reserve hw planes dynamically when needed. The
> problem is the userspace.
>
> When a DRM application starts, it sees a bunch of planes, and can see on
> which crtcs each plane can be used. The expectation is, of course, that
> these planes can be used normally. If the driver would dynamically
> reserve an additional, currently unused plane, the userspace would be
> totally baffled, as it fails to configure basic plane setups.
>
> For example, the userspace could see that there are two planes, usable
> on LCD and HDMI crtcs. But mysteriously modesetting would sometimes fail
> if the HDMI is 2k+ display. Setting up a plane on the HDMI would work,
> except when the LCD already has a plane. Setting up two planes on the
> LCD would work, but moving one or both planes to the HDMI would fail. Etc.

I suspect this is a common problem. Not because the h/w requires
different allocation of planes, but because the memory bandwidth can't
handle having a 2nd plane if the resolution is above a certain
size/depth. So while the plane doesn't disappear, the effect is the
same. How does DRM handle this?

> We could, of course, convey this information to the userspace at runtime
> via the DRM properties, but then it would mean we'd need customized
> applications.
>
> So, as far as I can see, keeping normal DRM behavior with 2k+ displays
> on OMAP DSS requires a static virtual plane setup. The most simple setup
> would be to just split the number of available planes by 2, but then in
> many use cases that wastes one hw plane.

For HDMI, you can't know in advance what resolution will be. So I
think you always need to reserve 2 planes. Now, if you want to reduce
the max resolution for some reason, I guess we could have properties
for that. That would be more generic and work whether you need to
change plane allocation or have a limit for other reasons.

For attached panels, you know the resolution up front and can allocate
planes before the userspace interface is up.

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

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

[Stephen Rothwell]

Hi all,

On Thu, 22 Mar 2018 13:21:29 +1100 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the drm-intel tree got a conflict in:
> 
>   drivers/gpu/drm/i915/gvt/scheduler.c
> 
> between commit:
> 
>   fa3dd623e559 ("drm/i915/gvt: keep oa config in shadow ctx")
> 
> from Linus' tree and commit:
> 
>   b20c0d5ce104 ("drm/i915/gvt: Update PDPs after a vGPU mm object is pinned.")
> 
> from the drm-intel tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/gpu/drm/i915/gvt/scheduler.c
> index 068126404151,a55b4975c154..
> --- a/drivers/gpu/drm/i915/gvt/scheduler.c
> +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
> @@@ -52,54 -52,29 +52,77 @@@ static void set_context_pdp_root_pointe
>   pdp_pair[i].val = pdp[7 - i];
>   }
>   
>  +/*
>  + * when populating shadow ctx from guest, we should not overrride oa related
>  + * registers, so that they will not be overlapped by guest oa configs. Thus
>  + * made it possible to capture oa data from host for both host and guests.
>  + */
>  +static void sr_oa_regs(struct intel_vgpu_workload *workload,
>  +u32 *reg_state, bool save)
>  +{
>  +struct drm_i915_private *dev_priv = workload->vgpu->gvt->dev_priv;
>  +u32 ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
>  +u32 ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
>  +int i = 0;
>  +u32 flex_mmio[] = {
>  +i915_mmio_reg_offset(EU_PERF_CNTL0),
>  +i915_mmio_reg_offset(EU_PERF_CNTL1),
>  +i915_mmio_reg_offset(EU_PERF_CNTL2),
>  +i915_mmio_reg_offset(EU_PERF_CNTL3),
>  +i915_mmio_reg_offset(EU_PERF_CNTL4),
>  +i915_mmio_reg_offset(EU_PERF_CNTL5),
>  +i915_mmio_reg_offset(EU_PERF_CNTL6),
>  +};
>  +
>  +if (!workload || !reg_state || workload->ring_id != RCS)
>  +return;
>  +
>  +if (save) {
>  +workload->oactxctrl = reg_state[ctx_oactxctrl + 1];
>  +
>  +for (i = 0; i < ARRAY_SIZE(workload->flex_mmio); i++) {
>  +u32 state_offset = ctx_flexeu0 + i * 2;
>  +
>  +workload->flex_mmio[i] = reg_state[state_offset + 1];
>  +}
>  +} else {
>  +reg_state[ctx_oactxctrl] =
>  +i915_mmio_reg_offset(GEN8_OACTXCONTROL);
>  +reg_state[ctx_oactxctrl + 1] = workload->oactxctrl;
>  +
>  +for (i = 0; i < ARRAY_SIZE(workload->flex_mmio); i++) {
>  +u32 state_offset = ctx_flexeu0 + i * 2;
>  +u32 mmio = flex_mmio[i];
>  +
>  +reg_state[state_offset] = mmio;
>  +reg_state[state_offset + 1] = workload->flex_mmio[i];
>  +}
>  +}
>  +}
>  +
> + static void update_shadow_pdps(struct intel_vgpu_workload *workload)
> + {
> + struct intel_vgpu *vgpu = workload->vgpu;
> + int ring_id = workload->ring_id;
> + struct i915_gem_context *shadow_ctx = vgpu->submission.shadow_ctx;
> + struct drm_i915_gem_object *ctx_obj =
> + shadow_ctx->engine[ring_id].state->obj;
> + struct execlist_ring_context *shadow_ring_context;
> + struct page *page;
> + 
> + if (WARN_ON(!workload->shadow_mm))
> + return;
> + 
> + if (WARN_ON(!atomic_read(>shadow_mm->pincount)))
> + return;
> + 
> + page = i915_gem_object_get_page(ctx_obj, LRC_STATE_PN);
> + shadow_ring_context = kmap(page);
> + set_context_pdp_root_pointer(shadow_ring_context,
> + (void *)workload->shadow_mm->ppgtt_mm.shadow_pdps);
> + kunmap(page);
> + }
> + 
>   static int populate_shadow_context(struct intel_vgpu_workload *workload)
>   {
>   struct intel_vgpu *vgpu = workload->vgpu;

This is now a conflict between the drm tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell


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

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

[Stephen Rothwell]

Hi all,

On Thu, 15 Mar 2018 14:14:25 +1100 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the drm-misc tree got a conflict in:
> 
>   sound/pci/hda/hda_intel.c
> 
> between commits:
> 
>   1ba8f9d30817 ("ALSA: hda: Add a power_save blacklist")
>   40088dc4e1ea ("ALSA: hda - Revert power_save option default value")
> 
> from Linus' tree and commit:
> 
>   07f4f97d7b4b ("vga_switcheroo: Use device link for HDA controller")
> 
> from the drm-misc tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc sound/pci/hda/hda_intel.c
> index d5017adf9feb,ec4e6b829ee2..
> --- a/sound/pci/hda/hda_intel.c
> +++ b/sound/pci/hda/hda_intel.c
> @@@ -2219,8 -2201,8 +2223,9 @@@ static int azx_probe_continue(struct az
>   struct hda_intel *hda = container_of(chip, struct hda_intel, chip);
>   struct hdac_bus *bus = azx_bus(chip);
>   struct pci_dev *pci = chip->pci;
> + struct hda_codec *codec;
>   int dev = chip->dev_index;
>  +int val;
>   int err;
>   
>   hda->probe_continued = 1;
> @@@ -2302,21 -2284,16 +2307,30 @@@
>   chip->running = 1;
>   azx_add_card_list(chip);
>   
>  +val = power_save;
>  +#ifdef CONFIG_PM
>  +if (pm_blacklist) {
>  +const struct snd_pci_quirk *q;
>  +
>  +q = snd_pci_quirk_lookup(chip->pci, power_save_blacklist);
>  +if (q && val) {
>  +dev_info(chip->card->dev, "device %04x:%04x is on the 
> power_save blacklist, forcing power_save to 0\n",
>  + q->subvendor, q->subdevice);
>  +val = 0;
>  +}
>  +}
>  +#endif /* CONFIG_PM */
> ++
> + /*
> +  * The discrete GPU cannot power down unless the HDA controller runtime
> +  * suspends, so activate runtime PM on codecs even if power_save == 0.
> +  */
> + if (use_vga_switcheroo(hda))
> + list_for_each_codec(codec, >bus)
> + codec->auto_runtime_pm = 1;
> + 
>  -snd_hda_set_power_save(>bus, power_save * 1000);
>  +snd_hda_set_power_save(>bus, val * 1000);
> - if (azx_has_pm_runtime(chip) || hda->use_vga_switcheroo)
> + if (azx_has_pm_runtime(chip))
>   pm_runtime_put_autosuspend(>dev);
>   
>   out_free:

This is now a conflict between the drm tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell


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

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

[Stephen Rothwell]

Hi all,

On Tue, 20 Mar 2018 12:08:41 +1100 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the drm-misc tree got a conflict in:
> 
>   drivers/gpu/drm/sun4i/sun4i_tcon.h
> 
> between commit:
> 
>   e742a17cd360 ("drm/sun4i: tcon: Reduce the scope of the LVDS error a bit")
> 
> from Linus' tree and commit:
> 
>   6664e9dc5383 ("drm/sun4i: Add support for A80 TCONs")
> 
> from the drm-misc tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/gpu/drm/sun4i/sun4i_tcon.h
> index abdc6ad6b384,d3a945b7bb60..
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
> @@@ -176,7 -176,7 +176,8 @@@ struct sun4i_tcon_quirks 
>   boolhas_channel_1;  /* a33 does not have channel 1 */
>   boolhas_lvds_alt;   /* Does the LVDS clock have a parent other than 
> the TCON clock? */
>   boolneeds_de_be_mux; /* sun6i needs mux to select backend */
>  +boolsupports_lvds;   /* Does the TCON support an LVDS output? */
> + boolneeds_edp_reset; /* a80 edp reset needed for tcon0 access */
>   
>   /* callback to handle tcon muxing options */
>   int (*set_mux)(struct sun4i_tcon *, const struct drm_encoder *);

This is now a conflict between the drm tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell


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

[git pull] drm fixes for 4.16-rc7

[Dave Airlie]

Hi Linus,

A bunch of fixes all over the place, nothing too serious or worrying
at this stage.

One uapi fix to stop multi-planar images with getfb,
Sun4i error path and clock fixes
udl driver mmap offset fix
i915 DP MST and GPU reset fixes
vmwgfx mutex and black screen fixes
imx array underflow fix and vblank fix
amdgpu: display fixes
exynos devicetree fix
ast mode fix.

Thanks,
Dave.

The following changes since commit c698ca5278934c0ae32297a8725ced2e27585d7f:

  Linux 4.16-rc6 (2018-03-18 17:48:42 -0700)

are available in the Git repository at:

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

for you to fetch changes up to 5a9f698feb11b198f17b2acebbfe0e2716a3beed:

  drm/ast: Fixed 1280x800 Display Issue (2018-03-23 09:50:54 +1000)


core, i915, amdgpu, imx, sun4i, ast, tegra, vmwgfx fixes.


Arnd Bergmann (1):
  gpu: ipu-v3: prg: avoid possible array underflow

Chris Wilson (1):
  drm/i915: Specify which engines to reset following semaphore/event lockups

Christophe JAILLET (3):
  drm/sun4i: Fix an error handling path in 'sun4i_drv_bind()'
  drm/sun4i: hdmi: Fix an error handling path in 'sun4i_hdmi_bind()'
  drm/sun4i: hdmi: Fix another error handling path in 'sun4i_hdmi_bind()'

Clark Zheng (1):
  drm/amd/display: Refine disable VGA

Daniel Stone (1):
  drm: Reject getfb for multi-plane framebuffers

Dave Airlie (7):
  Merge tag 'drm/tegra/for-4.16-rc7-fixes' of
git://anongit.freedesktop.org/tegra/linux into drm-fixes
  Merge tag 'exynos-drm-fixes-for-v4.16-rc6' of
git://git.kernel.org/.../daeinki/drm-exynos into drm-fixes
  Merge branch 'drm-fixes-4.16' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes
  Merge tag 'imx-drm-fixes-2018-03-22' of
git://git.pengutronix.de/git/pza/linux into drm-fixes
  Merge branch 'vmwgfx-fixes-4.16' of
git://people.freedesktop.org/~thomash/linux into drm-fixes
  Merge tag 'drm-intel-fixes-2018-03-21' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
  Merge tag 'drm-misc-fixes-2018-03-22' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes

Dhinakaran Pandiyan (1):
  drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.

Dmitry Osipenko (1):
  drm/tegra: plane: Correct legacy blending

Fabio Estevam (2):
  drm/imx: ipuv3-plane: Make functions static when possible
  drm/imx: ipuv3-plane: Include "imx-drm.h" header file

Greg Kroah-Hartman (1):
  drm: udl: Properly check framebuffer mmap offsets

Harry Wentland (2):
  drm/amd/display: We shouldn't set format_default on plane as atomic driver
  drm/amd/display: Add one to EDID's audio channel count when passing to DC

Lucas Stach (1):
  drm/imx: move arming of the vblank event to atomic_flush

Michel Dänzer (1):
  drm/radeon: Don't turn off DP sink when disconnected

Mikita Lipski (3):
  drm/amdgpu: Use atomic function to disable crtcs with dc enabled
  drm/amd/display: Allow truncation to 10 bits
  drm/amd/display: Fix FMT truncation programming

Ondrej Jirman (1):
  drm/sun4i: Fix exclusivity of the TCON clocks

Shirish S (1):
  drm/amd/display: fix dereferencing possible ERR_PTR()

Sylwester Nawrocki (1):
  dt-bindings: exynos: Document #sound-dai-cells property of the HDMI node

Thierry Reding (4):
  drm/tegra: plane: Fix RGB565 format on older Tegra
  drm/tegra: dc: Detach IOMMU group from domain only once
  drm/tegra: dsi: Don't disable regulator on ->exit()
  drm/tegra: Shutdown on driver unbind

Thomas Hellstrom (2):
  drm/vmwgfx: Fix black screen and device errors when running without fbdev
  drm/vmwgfx: Fix a destoy-while-held mutex problem.

Y.C. Chen (1):
  drm/ast: Fixed 1280x800 Display Issue

 .../bindings/display/exynos/exynos_hdmi.txt|  1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  9 +++--
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  |  5 +--
 .../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c  |  2 +-
 drivers/gpu/drm/amd/display/dc/dce/dce_hwseq.h |  8 -
 drivers/gpu/drm/amd/display/dc/dce/dce_opp.c   |  9 +++--
 .../drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c  | 20 ---
 drivers/gpu/drm/ast/ast_tables.h   |  4 +--
 drivers/gpu/drm/drm_framebuffer.c  |  7 
 drivers/gpu/drm/i915/intel_ddi.c   |  7 ++--
 drivers/gpu/drm/i915/intel_hangcheck.c |  4 +--
 drivers/gpu/drm/imx/ipuv3-crtc.c   |  5 +++
 drivers/gpu/drm/imx/ipuv3-plane.c  | 10 +++---
 drivers/gpu/drm/radeon/radeon_connectors.c | 31 +++--
 drivers/gpu/drm/sun4i/sun4i_drv.c  |  3 +-
 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c |  6 ++--
 drivers/gpu/drm/sun4i/sun4i_tcon.c |  5 +--
 drivers/gpu/drm/tegra/dc.c  

Re: [PATCH 2/2] drm/tinydrm: Make fb_dirty into a lower level hook

[Noralf Trønnes]

Den 22.03.2018 21.27, skrev Ville Syrjala:

From: Ville Syrjälä 

mipi_dbi_enable_flush() wants to call the fb->dirty() hook from the
bowels of the .atomic_enable() hook. That prevents us from taking the
plane mutex in fb->dirty() unless we also plumb down the acquire
context.

Instead it seems simpler to split the fb->dirty() into a tinydrm
specific lower level hook that can be called from
mipi_dbi_enable_flush() and from a generic higher level
tinydrm_fb_dirty() helper. As we don't have a tinydrm specific
vfuncs table we'll just stick it into tinydrm_device directly
for now.


The long term goal is to try and get rid of tinydrm.ko by moving stuff
elsewhere as it's kind of a middle layer. So I'd really like to avoid
adding a callback like this.
Hopefully we can work out a solution based on my suggestion in the
'drm: Eliminate plane->fb/crtc usage for atomic drivers' thread.

If we do need a hook, I prefer that we add it to
drm_simple_display_pipe_funcs.

Noralf.


Cc: "Noralf Trønnes" 
Cc: David Lechner 
Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 30 ++
  drivers/gpu/drm/tinydrm/ili9225.c  | 23 ++--
  drivers/gpu/drm/tinydrm/mi0283qt.c |  2 +-
  drivers/gpu/drm/tinydrm/mipi-dbi.c | 30 ++
  drivers/gpu/drm/tinydrm/repaper.c  | 28 
  drivers/gpu/drm/tinydrm/st7586.c   | 23 ++--
  drivers/gpu/drm/tinydrm/st7735r.c  |  2 +-
  include/drm/tinydrm/mipi-dbi.h |  4 +++-
  include/drm/tinydrm/tinydrm-helpers.h  |  5 +
  include/drm/tinydrm/tinydrm.h  |  4 
  10 files changed, 76 insertions(+), 75 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
index d1c3ce9ab294..dcd390163a4a 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
@@ -78,6 +78,36 @@ bool tinydrm_merge_clips(struct drm_clip_rect *dst,
  }
  EXPORT_SYMBOL(tinydrm_merge_clips);
  
+int tinydrm_fb_dirty(struct drm_framebuffer *fb,

+struct drm_file *file_priv,
+unsigned int flags, unsigned int color,
+struct drm_clip_rect *clips,
+unsigned int num_clips)
+{
+   struct tinydrm_device *tdev = fb->dev->dev_private;
+   struct drm_plane *plane = >pipe.plane;
+   int ret = 0;
+
+   drm_modeset_lock(>mutex, NULL);
+
+   /* fbdev can flush even when we're not interested */
+   if (plane->state->fb == fb) {
+   mutex_lock(>dirty_lock);
+   ret = tdev->fb_dirty(fb, file_priv, flags,
+color, clips, num_clips);
+   mutex_unlock(>dirty_lock);
+   }
+
+   drm_modeset_unlock(>mutex);
+
+   if (ret)
+   dev_err_once(fb->dev->dev,
+"Failed to update display %d\n", ret);
+
+   return ret;
+}
+EXPORT_SYMBOL(tinydrm_fb_dirty);
+
  /**
   * tinydrm_memcpy - Copy clip buffer
   * @dst: Destination buffer
diff --git a/drivers/gpu/drm/tinydrm/ili9225.c 
b/drivers/gpu/drm/tinydrm/ili9225.c
index 089d22798c8b..0874e877b111 100644
--- a/drivers/gpu/drm/tinydrm/ili9225.c
+++ b/drivers/gpu/drm/tinydrm/ili9225.c
@@ -88,14 +88,8 @@ static int ili9225_fb_dirty(struct drm_framebuffer *fb,
bool full;
void *tr;
  
-	mutex_lock(>dirty_lock);

-
if (!mipi->enabled)
-   goto out_unlock;
-
-   /* fbdev can flush even when we're not interested */
-   if (tdev->pipe.plane.fb != fb)
-   goto out_unlock;
+   return 0;
  
  	full = tinydrm_merge_clips(, clips, num_clips, flags,

   fb->width, fb->height);
@@ -108,7 +102,7 @@ static int ili9225_fb_dirty(struct drm_framebuffer *fb,
tr = mipi->tx_buf;
ret = mipi_dbi_buf_copy(mipi->tx_buf, fb, , swap);
if (ret)
-   goto out_unlock;
+   return ret;
} else {
tr = cma_obj->vaddr;
}
@@ -159,20 +153,13 @@ static int ili9225_fb_dirty(struct drm_framebuffer *fb,
ret = mipi_dbi_command_buf(mipi, ILI9225_WRITE_DATA_TO_GRAM, tr,
(clip.x2 - clip.x1) * (clip.y2 - clip.y1) * 2);
  
-out_unlock:

-   mutex_unlock(>dirty_lock);
-
-   if (ret)
-   dev_err_once(fb->dev->dev, "Failed to update display %d\n",
-ret);
-
return ret;
  }
  
  static const struct drm_framebuffer_funcs ili9225_fb_funcs = {

.destroy= drm_gem_fb_destroy,
.create_handle  = drm_gem_fb_create_handle,
-   .dirty  = 

[PATCH] drm/amd/display: don't pass large struct stream_res by value

[Colin King]

From: Colin Ian King 

Passing stream_res by value is inefficient as it requires a large copy
of 320 bytes.  Instead, pass it by reference and also use a pointer to
stream_res->tg and also stream_res->abm to clean up the code a little.

Detected by CoverityScan, CID#1466432 ("Big parameter passed by value")

Signed-off-by: Colin Ian King 
---
 .../drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c  | 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c 
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
index 8b0f6b8a5627..222d78fc733d 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
@@ -1812,32 +1812,32 @@ static void update_dchubp_dpp(
 
 static void dcn10_otg_blank(
struct dc *dc,
-   struct stream_resource stream_res,
+   struct stream_resource *stream_res,
struct dc_stream_state *stream,
bool blank)
 {
enum dc_color_space color_space;
struct tg_color black_color = {0};
+   struct timing_generator *tg = stream_res->tg;
+   struct abm *abm = stream_res->abm;
 
/* program otg blank color */
color_space = stream->output_color_space;
color_space_to_black_color(dc, color_space, _color);
 
-   if (stream_res.tg->funcs->set_blank_color)
-   stream_res.tg->funcs->set_blank_color(
-   stream_res.tg,
-   _color);
+   if (tg->funcs->set_blank_color)
+   tg->funcs->set_blank_color(tg, _color);
 
if (!blank) {
-   if (stream_res.tg->funcs->set_blank)
-   stream_res.tg->funcs->set_blank(stream_res.tg, blank);
-   if (stream_res.abm)
-   stream_res.abm->funcs->set_abm_level(stream_res.abm, 
stream->abm_level);
+   if (tg->funcs->set_blank)
+   tg->funcs->set_blank(tg, blank);
+   if (abm)
+   abm->funcs->set_abm_level(abm, stream->abm_level);
} else if (blank) {
-   if (stream_res.abm)
-   
stream_res.abm->funcs->set_abm_immediate_disable(stream_res.abm);
-   if (stream_res.tg->funcs->set_blank)
-   stream_res.tg->funcs->set_blank(stream_res.tg, blank);
+   if (abm)
+   abm->funcs->set_abm_immediate_disable(abm);
+   if (tg->funcs->set_blank)
+   tg->funcs->set_blank(tg, blank);
}
 }
 
@@ -1876,7 +1876,7 @@ static void program_all_pipe_in_tree(
pipe_ctx->stream_res.tg->funcs->program_global_sync(
pipe_ctx->stream_res.tg);
 
-   dcn10_otg_blank(dc, pipe_ctx->stream_res,
+   dcn10_otg_blank(dc, _ctx->stream_res,
pipe_ctx->stream, blank);
}
 
@@ -1996,7 +1996,7 @@ static void dcn10_apply_ctx_for_surface(
 
if (num_planes == 0) {
/* OTG blank before remove all front end */
-   dcn10_otg_blank(dc, top_pipe_to_program->stream_res, 
top_pipe_to_program->stream, true);
+   dcn10_otg_blank(dc, _pipe_to_program->stream_res, 
top_pipe_to_program->stream, true);
}
 
/* Disconnect unused mpcc */
-- 
2.15.1

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

Re: [PATCH 00/23] drm: Eliminate plane->fb/crtc usage for atomic drivers

[Noralf Trønnes]

Den 22.03.2018 19.49, skrev Ville Syrjälä:

On Thu, Mar 22, 2018 at 05:51:35PM +0100, Noralf Trønnes wrote:

tinydrm is also using plane->fb:

$ grep -r "plane\.fb" drivers/gpu/drm/tinydrm/
drivers/gpu/drm/tinydrm/repaper.c:  if (tdev->pipe.plane.fb != fb)
drivers/gpu/drm/tinydrm/mipi-dbi.c: if (tdev->pipe.plane.fb != fb)
drivers/gpu/drm/tinydrm/mipi-dbi.c: struct drm_framebuffer *fb =
mipi->tinydrm.pipe.plane.fb;

Oh dear, and naturally it's the most annoying one of the bunch. So we
want to take the plane lock in the fb.dirty() hook to look at the fb,
but mipi-dbi.c calls that directly from the bowels of its
.atomic_enable() hook. So that would deadlock pretty neatly if the
commit happens while already holding the lock.

So we'd either need to plumb an acquire context into fb.dirty(),
or maybe have tinydrm provide a lower level lockless dirty() hook
that gets called by both (there are just too many layers in this
particular cake to immediately see where such a hook would be best
placed). Or maybe there's some other solution I didn't think of.

Looking at this I'm also left wondering how this is supposed
handle fb.dirty() getting called concurrently with a modeset.
The dirty_mutex only seems to offer any protection for
fb.dirty() against another fb.dirty()...



I have been waiting for the 'page-flip with damage'[1] work to come to
fruition so I could handle all flushing during atomic commit.
The idea is to use the same damage rect for a generic dirtyfb callback.

Maybe a temporary tinydrm specific solution is possible until that work
lands, but I don't know enough about how to implement such a dirtyfb
callback.

I imagine it could look something like this:

 struct tinydrm_device {
+    struct drm_clip_rect dirtyfb_rect;
 };

static int tinydrm_fb_dirty(struct drm_framebuffer *fb,
                struct drm_file *file_priv,
                unsigned int flags, unsigned int color,
                struct drm_clip_rect *clips,
                unsigned int num_clips)
{
    struct tinydrm_device *tdev = fb->dev->dev_private;
    struct drm_framebuffer *planefb;

    /* Grab whatever lock needed to check this */
    planefb = tdev->pipe.plane.state->fb;

    /* fbdev can flush even when we're not interested */
    if (fb != planefb)
        return 0;

    /* Protect dirtyfb_rect with a lock */
    tinydrm_merge_clips(>dirty_rectfb, clips, num_clips, flags,
                fb->width, fb->height);

    /*
     * Somehow do an atomic commit that results in the atomic update
     * callback being called
     */
    ret = drm_atomic_commit(state);
...
}

static void mipi_dbi_flush(struct drm_framebuffer *fb,
               struct drm_clip_rect *clip)
{
    /* Flush out framebuffer */
}

void mipi_dbi_pipe_update(struct drm_simple_display_pipe *pipe,
              struct drm_plane_state *old_state)
{
    struct tinydrm_device *tdev = pipe_to_tinydrm(pipe);
    struct mipi_dbi *mipi = mipi_dbi_from_tinydrm(tdev);
    struct drm_framebuffer *fb = pipe->plane.state->fb;
    struct drm_crtc *crtc = >pipe.crtc;

    if (!fb || (fb == old_state->fb && !tdev->dirty_rect.x2))
        goto out_vblank;

    /* Don't flush if the controller isn't initialized yet */
    if (!mipi->enabled)
        goto out_vblank;

    if (fb != old_state->fb) { /* Page flip or new, flush all */
        mipi_dbi_flush(fb, NULL);
    } else { /* dirtyfb ioctl */
        mipi_dbi_flush(fb, >dirtyfb_rect);
        memset(>dirtyfb_rect, 0, sizeof(tdev->dirtyfb_rect));
    }

out_vblank:
    if (crtc->state->event) {
        spin_lock_irq(>dev->event_lock);
        drm_crtc_send_vblank_event(crtc, crtc->state->event);
        spin_unlock_irq(>dev->event_lock);
        crtc->state->event = NULL;
    }
}

This is called from the driver pipe enable callback after the controller
has been initialized:

 void mipi_dbi_pipe_enable(struct drm_simple_display_pipe *pipe,
           struct drm_crtc_state *crtc_state)
 {
 struct tinydrm_device *tdev = pipe_to_tinydrm(pipe);
 struct mipi_dbi *mipi = mipi_dbi_from_tinydrm(tdev);
-     struct drm_framebuffer *fb = pipe->plane.fb;
+    struct drm_framebuffer *fb = pipe->plane.state->fb;

 DRM_DEBUG_KMS("\n");

 mipi->enabled = true;
-     if (fb)
-         fb->funcs->dirty(fb, NULL, 0, 0, NULL, 0);
+    mipi_dbi_flush(fb, NULL);
 tinydrm_enable_backlight(mipi->backlight);
 }

I can make patches if this makes any sense and you can help me with the
dirtyfb implementation.

Noralf.

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


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

[PATCH][next] drm/amd/pp: don't dereference hwmgr until after it is null checked

[Colin King]

From: Colin Ian King 

Pointer hwmgr is dereferenced before it is null checked, hence there
is a possibility of a null pointer dereference.  Fix this by only
dereferencing hwmgr once it is null checked.

Detected by CoverityScan, CID#1466428 ("Dereference before null check")

Fixes: 59156faf810e ("drm/amd/pp: Remove the cgs wrapper for notify smu version 
on APU")
Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c 
b/drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c
index 8c49704b81af..6e88ed67e291 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c
@@ -698,18 +698,18 @@ static int smu8_start_smu(struct pp_hwmgr *hwmgr)
 {
int ret = 0;
uint32_t fw_to_check = 0;
-   struct amdgpu_device *adev = hwmgr->adev;
+   struct amdgpu_device *adev;
 
uint32_t index = SMN_MP1_SRAM_START_ADDR +
 SMU8_FIRMWARE_HEADER_LOCATION +
 offsetof(struct SMU8_Firmware_Header, Version);
 
-
if (hwmgr == NULL || hwmgr->device == NULL)
return -EINVAL;
 
cgs_write_register(hwmgr->device, mmMP0PUB_IND_INDEX, index);
hwmgr->smu_version = cgs_read_register(hwmgr->device, 
mmMP0PUB_IND_DATA);
+   adev = hwmgr->adev;
adev->pm.fw_version = hwmgr->smu_version >> 8;
 
fw_to_check = UCODE_ID_RLC_G_MASK |
-- 
2.15.1

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

Re: [PATCH] drm/gem: Document that handle_create must be the last step

[Oleksandr Andrushchenko]

On 03/22/2018 10:02 AM, Daniel Vetter wrote:

It published

s/It/If

  the gem object to userspace, by that point other threads
can guess the id and start using it. And gem IDs are _very_ easy to
guess (it's just an idr).

Since gem objects is the only thing we allow drivers to create
themselves (all the kms/prime/syncobj stuff is handled by the core) no
other functions seem to be in need of this clarification.

Motivated by reviewing the xen-front kms driver.

Cc: Oleksandr Andrushchenko 
Signed-off-by: Daniel Vetter 
---
  drivers/gpu/drm/drm_gem.c | 9 ++---
  1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 4975ba9a7bc8..4a16d7b26c89 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -436,9 +436,12 @@ drm_gem_handle_create_tail(struct drm_file *file_priv,
   * @obj: object to register
   * @handlep: pionter to return the created handle to the caller
   *
- * Create a handle for this object. This adds a handle reference
- * to the object, which includes a regular reference count. Callers
- * will likely want to dereference the object afterwards.
+ * Create a handle for this object. This adds a handle reference to the object,
+ * which includes a regular reference count. Callers will likely want to
+ * dereference the object afterwards.
+ *
+ * Since this publishes @obj to userspace it must be fully set up by this 
point,
+ * drivers must call this last in their buffer object creation callbacks.
   */
  int drm_gem_handle_create(struct drm_file *file_priv,
  struct drm_gem_object *obj,


Reviewed-by: Oleksandr Andrushchenko 

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

[PATCH 0/2] drm/sun4i: Fix some error handling paths in 'sun4i_hdmi_bind()'

[Christophe JAILLET]

I've splitted these fixes into 2 patches becasue they do not fixe the same
commit.

Christophe JAILLET (2):
  drm/sun4i: hdmi: Fix an error handling path in 'sun4i_hdmi_bind()'
  drm/sun4i: hdmi: Fix another error handling path in
'sun4i_hdmi_bind()'

 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

-- 
2.14.1

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

[PATCH 05/10] drm/sun4i: Explicitly list and check formats supported by the frontend

[Paul Kocialkowski]

In order to check whether the frontend supports a specific format, an
explicit list and a related helper are introduced.

They are then used to determine whether the frontend can actually support
the requested format when it was selected to be used.

Signed-off-by: Paul Kocialkowski 
---
 drivers/gpu/drm/sun4i/sun4i_backend.c  |  5 
 drivers/gpu/drm/sun4i/sun4i_frontend.c | 44 ++
 drivers/gpu/drm/sun4i/sun4i_frontend.h |  1 +
 3 files changed, 50 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index 7703ba989743..1fad0714c70e 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -532,6 +532,11 @@ static int sun4i_backend_atomic_check(struct sunxi_engine 
*engine,
struct drm_format_name_buf format_name;
 
if (sun4i_backend_plane_uses_frontend(plane_state)) {
+   if 
(!sun4i_frontend_format_is_supported(fb->format->format)) {
+   DRM_DEBUG_DRIVER("Frontend plane check 
failed\n");
+   return -EINVAL;
+   }
+
DRM_DEBUG_DRIVER("Using the frontend for plane %d\n",
 plane->index);
 
diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c 
b/drivers/gpu/drm/sun4i/sun4i_frontend.c
index 3ea925584891..2dc33383be22 100644
--- a/drivers/gpu/drm/sun4i/sun4i_frontend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c
@@ -128,6 +128,50 @@ static int 
sun4i_frontend_drm_format_to_output_fmt(uint32_t fmt, u32 *val)
}
 }
 
+static const uint32_t sun4i_frontend_formats[] = {
+   /* RGB */
+   DRM_FORMAT_XRGB,
+   DRM_FORMAT_BGRX,
+   /* YUV444 */
+   DRM_FORMAT_YUV444,
+   DRM_FORMAT_YVU444,
+   /* YUV422 */
+   DRM_FORMAT_YUYV,
+   DRM_FORMAT_YVYU,
+   DRM_FORMAT_UYVY,
+   DRM_FORMAT_VYUY,
+   DRM_FORMAT_NV16,
+   DRM_FORMAT_NV61,
+   DRM_FORMAT_YUV422,
+   DRM_FORMAT_YVU422,
+   /* YUV420 */
+   DRM_FORMAT_NV12,
+   DRM_FORMAT_NV21,
+   DRM_FORMAT_YUV420,
+   DRM_FORMAT_YVU420,
+   /* YUV411 */
+   DRM_FORMAT_YUV411,
+   DRM_FORMAT_YVU411,
+};
+
+bool sun4i_frontend_format_is_supported(uint32_t fmt)
+{
+   bool found = false;
+   unsigned int i;
+
+   for (i = 0; i < ARRAY_SIZE(sun4i_frontend_formats); i++) {
+   if (sun4i_frontend_formats[i] == fmt) {
+   found = true;
+   break;
+   }
+   }
+
+   if (!found)
+   return false;
+
+   return true;
+}
+
 int sun4i_frontend_update_formats(struct sun4i_frontend *frontend,
  struct drm_plane *plane, uint32_t out_fmt)
 {
diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.h 
b/drivers/gpu/drm/sun4i/sun4i_frontend.h
index 02661ce81f3e..a9cb908ced16 100644
--- a/drivers/gpu/drm/sun4i/sun4i_frontend.h
+++ b/drivers/gpu/drm/sun4i/sun4i_frontend.h
@@ -95,5 +95,6 @@ void sun4i_frontend_update_coord(struct sun4i_frontend 
*frontend,
 struct drm_plane *plane);
 int sun4i_frontend_update_formats(struct sun4i_frontend *frontend,
  struct drm_plane *plane, uint32_t out_fmt);
+bool sun4i_frontend_format_is_supported(uint32_t fmt);
 
 #endif /* _SUN4I_FRONTEND_H_ */
-- 
2.16.2

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

[PATCH 00/10] drm/sun4i: Frontend YUV and MB32 tile modifier support

[Paul Kocialkowski]

This introduces support for YUV formats in the sun4i DRM driver, through
the frontend. In addition to regular YUV formats, a modifier for the
Allwinner MB32 tiling format is introduced along with a dedicated ioctl
for allocating buffers (through CMA) with the appropriate constraints.

This ioctl must always be used when allocating buffers to be used with
the MB32 tiling modifier, as dumb GEM buffer allocation is reserved for
linear planes.

This series is based on (and requires) the following series:
* drm/sun4i: backend: Support interleaved YUV planes,
  from Maxime Ripard: https://patchwork.freedesktop.org/series/39232/
* drm/sun4i: Support the Display Engine frontend,
  from Maxime Ripard: https://patchwork.freedesktop.org/series/35292/
* drm/sun4i: Support more planes, zpos and plane-wide alpha,
  from Maxime Ripard: https://patchwork.freedesktop.org/series/36183/

Paul Kocialkowski (10):
  drm/sun4i: Disable frontend video channel before enabling a layer
  drm/sun4i: Disable YUV channel when using the frontend and set
interlace
  drm/sun4i: Don't pretend to handle ARGB with the frontend
  drm/sun4i: Explicitly list and check formats supported by the backend
  drm/sun4i: Explicitly list and check formats supported by the frontend
  drm/sun4i: Move and extend format-related helpers and tables
  drm/sun4i: Add support for YUV formats through the frontend
  drm/fourcc: Add definitions for Allwinner vendor and MB32 tiled format
  drm/sun4i: Add a dedicated ioctl call for allocating tiled buffers
  drm/sun4i: Add support for YUV-based formats in MB32 tiles

 drivers/gpu/drm/sun4i/Makefile |   1 +
 drivers/gpu/drm/sun4i/sun4i_backend.c  | 148 +-
 drivers/gpu/drm/sun4i/sun4i_backend.h  |   6 +-
 drivers/gpu/drm/sun4i/sun4i_drv.c  | 108 +-
 drivers/gpu/drm/sun4i/sun4i_drv.h  |   6 +
 drivers/gpu/drm/sun4i/sun4i_format.c   | 193 ++
 drivers/gpu/drm/sun4i/sun4i_format.h   |  35 
 drivers/gpu/drm/sun4i/sun4i_frontend.c | 359 +
 drivers/gpu/drm/sun4i/sun4i_frontend.h |  50 -
 drivers/gpu/drm/sun4i/sun4i_layer.c|  58 --
 include/uapi/drm/drm_fourcc.h  |  10 +
 include/uapi/drm/sun4i_drm.h   |  42 
 12 files changed, 910 insertions(+), 106 deletions(-)
 create mode 100644 drivers/gpu/drm/sun4i/sun4i_format.c
 create mode 100644 drivers/gpu/drm/sun4i/sun4i_format.h
 create mode 100644 include/uapi/drm/sun4i_drm.h

-- 
2.16.2

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

[PATCH 10/10] drm/sun4i: Add support for YUV-based formats in MB32 tiles

[Paul Kocialkowski]

This adds all the required configuration and support for handling YUV
formats tiled with the Allwinner MB32 modifier. This newly-introduced
YUV support should be in as good a shape as RGB support.

While this implementation covers most MB32-capable formats supported
by the frontend, only NV12-based formats were actually tested.
Since most of the logic is common, it is likely that other formats will
work just as well.

Signed-off-by: Paul Kocialkowski 
---
 drivers/gpu/drm/sun4i/sun4i_backend.c  |  10 +++-
 drivers/gpu/drm/sun4i/sun4i_backend.h  |   2 +-
 drivers/gpu/drm/sun4i/sun4i_drv.c  |   1 +
 drivers/gpu/drm/sun4i/sun4i_frontend.c | 100 -
 drivers/gpu/drm/sun4i/sun4i_frontend.h |   3 +-
 drivers/gpu/drm/sun4i/sun4i_layer.c|  16 +-
 6 files changed, 113 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index 3de7f3a427c3..335c444b1547 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -147,11 +147,14 @@ static const uint32_t sun4i_backend_formats[] = {
DRM_FORMAT_VYUY,
 };
 
-bool sun4i_backend_format_is_supported(uint32_t fmt)
+bool sun4i_backend_format_is_supported(uint32_t fmt, uint64_t modifier)
 {
bool found = false;
unsigned int i;
 
+   if (modifier == DRM_FORMAT_MOD_ALLWINNER_MB32_TILED)
+   return false;
+
for (i = 0; i < ARRAY_SIZE(sun4i_backend_formats); i++) {
if (sun4i_backend_formats[i] == fmt) {
found = true;
@@ -437,7 +440,8 @@ static bool sun4i_backend_plane_uses_frontend(struct 
drm_plane_state *state)
 * not supported by either. There is still room to check this later in
 * the atomic check process.
 */
-   if (!sun4i_backend_format_is_supported(fb->format->format))
+   if (!sun4i_backend_format_is_supported(fb->format->format,
+  fb->modifier))
return true;
 
/*
@@ -489,7 +493,7 @@ static int sun4i_backend_atomic_check(struct sunxi_engine 
*engine,
struct drm_format_name_buf format_name;
 
if (sun4i_backend_plane_uses_frontend(plane_state)) {
-   if 
(!sun4i_frontend_format_is_supported(fb->format->format)) {
+   if (!sun4i_frontend_plane_check(plane_state)) {
DRM_DEBUG_DRIVER("Frontend plane check 
failed\n");
return -EINVAL;
}
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.h 
b/drivers/gpu/drm/sun4i/sun4i_backend.h
index a7bfc38f12bd..bd93808c3ee7 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.h
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.h
@@ -207,6 +207,6 @@ int sun4i_backend_update_layer_zpos(struct sun4i_backend 
*backend,
int layer, struct drm_plane *plane);
 void sun4i_backend_disable_layer_frontend(struct sun4i_backend *backend,
  int layer);
-bool sun4i_backend_format_is_supported(uint32_t fmt);
+bool sun4i_backend_format_is_supported(uint32_t fmt, uint64_t modifier);
 
 #endif /* _SUN4I_BACKEND_H_ */
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index e9cb03d34b44..41888743722a 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -208,6 +208,7 @@ static int sun4i_drv_bind(struct device *dev)
}
 
drm_mode_config_init(drm);
+   drm->mode_config.allow_fb_modifiers = true;
 
ret = component_bind_all(drm->dev, drm);
if (ret) {
diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c 
b/drivers/gpu/drm/sun4i/sun4i_frontend.c
index d9e58e96119c..85f75046712c 100644
--- a/drivers/gpu/drm/sun4i/sun4i_frontend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c
@@ -99,16 +99,56 @@ void sun4i_frontend_update_buffer(struct sun4i_frontend 
*frontend,
width = state->src_w >> 16;
height = state->src_h >> 16;
 
-   regmap_write(frontend->regs, SUN4I_FRONTEND_LINESTRD0_REG,
-fb->pitches[0]);
+   if (fb->modifier == DRM_FORMAT_MOD_ALLWINNER_MB32_TILED) {
+   /*
+* In MB32 tiled mode, the stride is defined as the distance
+* between the start of the end line of the current tile and
+* the start of the first line in the next vertical tile.
+*
+* Tiles are represented linearly in memory, thus the end line
+* of current tile starts at: 31 * 32 (31 lines of 32 cols),
+* the next vertical tile starts at: 32-bit-aligned-width * 32
+* and the distance is: 32 * (32-bit-aligned-width - 31).
+*/
+
+   stride = (fb->pitches[0] - 31) * 32;
+   regmap_write(frontend->regs, 

Re: [PATCH] [RFC] drm: rcar-du: keep temporary dtb files around during build

[Masahiro Yamada]

2018-03-23 0:13 GMT+09:00 Geert Uytterhoeven :
> Hi Laurent,
>
> CC Yamada-san
>
> On Thu, Mar 22, 2018 at 3:50 PM, Laurent Pinchart
>  wrote:
>> On Thursday, 22 March 2018 16:26:22 EET Geert Uytterhoeven wrote:
>>> On Fri, Mar 16, 2018 at 2:39 AM,   wrote:
>>> > On Thursday, March 15, 2018 8:37 AM, Arnd Bergmann wrote:
>>> >> The *.dtb and *.dtb.S files get removed by 'make' during the build
>>> >> process, and later seem to be missed during the 'modpost' stage:
>>> >>
>>> >> rm drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dtb
>>> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dtb
>>> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dtb.S
>>> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dtb.S
>>> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dtb.S
>>> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dtb
>>> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dtb
>>> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dtb
>>> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dtb.S
>>> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dtb.S
>>> >> WARNING: could not open
>>> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dtb.S: No such file or
>>> >> directory
>>> >>
>>> >> As a workaround, this adds all those files to the 'extra-y' target list,
>>> >> but that's really ugly. Any ideas for a better fix?
>>> >
>>> > Does this work for you (untested, but the way it is done in
>>> > drivers/of/unittest-data/Makefile):
>>> >
>>> > .PRECIOUS: \
>>> >
>>> > $(obj)/%.dtb.S \
>>> > $(obj)/%.dtb
>>>
>>> Shouldn't that just be moved to scripts/Makefile.lib, just above the rule
>>> to make dtb.S, like is done for other precious objects?
>>
>> Without any implied acknowledgment that keeping those intermediate files is
>> the right solution (I don't claim to master the kernel build system), I think
>
> Me neither, but I think it is.
>
> Cfr. .y => .tab.c => .tab.o with .tab.c marked PRECIOUS.
>
>> such a rule would indeed be better in a core Makefile, as the rules to build
>> the .dtb.o file comes from the core too. Could another option be to create a
>> rule to compile a .dtb.o from the .dts file directly without going through
>> intermediate files that will be removed automatically ?
>
> Such a rules needs to execute two commands, which is more tricky, considering
> error handling.
> It's easier (to get right) to have two separate rules, and let make chain them
> automatically.
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds



This has been in my TODO list for a while,
but I have not had time to finish it.


Some people use .PRECIOUS to suppress file removal,
but it is wrong IMO.

.SECONDARY is the right one, but one problem is,
this does not work with pattern rules.

I will send a patch soon for the core improvement.


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

RE: [PATCH v2 2/2] drivers: remove force dma flag from buses

[Nipun Gupta]

> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Wednesday, March 21, 2018 15:05
> To: Nipun Gupta 
> Cc: robin.mur...@arm.com; h...@lst.de; li...@armlinux.org.uk;
> m.szyprow...@samsung.com; bhelg...@google.com; zaj...@gmail.com;
> andy.gr...@linaro.org; david.br...@linaro.org; dan.j.willi...@intel.com;
> vinod.k...@intel.com; thierry.red...@gmail.com; robh...@kernel.org;
> frowand.l...@gmail.com; jarkko.sakki...@linux.intel.com;
> rafael.j.wyso...@intel.com; dmitry.torok...@gmail.com; jo...@kernel.org;
> msucha...@suse.de; linux-ker...@vger.kernel.org; iommu@lists.linux-
> foundation.org; linux-wirel...@vger.kernel.org; linux-arm-
> m...@vger.kernel.org; linux-...@vger.kernel.org; dmaeng...@vger.kernel.org;
> dri-devel@lists.freedesktop.org; linux-te...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-...@vger.kernel.org; Bharat Bhushan
> ; Leo Li 
> Subject: Re: [PATCH v2 2/2] drivers: remove force dma flag from buses
> 
> On Wed, Mar 21, 2018 at 12:25:23PM +0530, Nipun Gupta wrote:
> > With each bus implementing its own DMA configuration callback,
> > there is no need for bus to explicitly have force_dma in its
> > global structure. This patch modifies of_dma_configure API to
> > accept an input parameter which specifies if implicit DMA
> > configuration is required even when it is not described by the
> > firmware.
> 
> Having to "remember" what that bool variable means on the end of the
> function call is a royal pain over time, right?
> 
> Why not just create a new function:
>   dma_common_configure_force(dma)
> that always does this?  Leave "dma_common_configure()" alone, and then
> wrap the old code with these two helper functions that call the 'core'
> code with the bool set properly?
> 
> That way you do not have to "know" what that parameter is, the function
> name just documents it automatically, so when you see it in the
> bus-specific code, no need to go and have to hunt for anything.  And if
> you are reading the dma core code, it's obvious what is happening as the
> functions are all right there.

How about we do not pass any flag in 'dma_common_configure()', and inside this
API we pass "true" to 'of_dma_configure()'? I am saying this because currently
both the busses (platform and AMBA) which uses 'dma_common_configure()' passes
"true" value. If we create additional 'dma_common_configure_force()', then
'dma_common_configure()' will not be used anytime and will become redundant.

If someday new busses come and they needs to use similar functionality which
'dma_common_configure()' provides, but with passing "false" to 
'of_dma_configure()',
then what you suggests of having two separate such API's will be more reasonable
and can be implemented?

Thanks,
Nipun

> 
> thanks,
> 
> greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH v2 1/2] dma-mapping: move dma configuration to bus infrastructure

[Nipun Gupta]

> -Original Message-
> From: Christoph Hellwig [mailto:h...@lst.de]
> Sent: Thursday, March 22, 2018 13:46
> To: Nipun Gupta 
> 
> > +static int amba_dma_configure(struct device *dev)
> > +{
> > +   return dma_common_configure(dev);
> > +}
> 
> So it turns out we only end with two callers of dma_common_configure
> after this series.  Based ont hat I'm tempted with the suggestion
> from Robin to just have amba call platform_dma_configure, and move
> the code from dma_common_configure to platform_dma_configure.

okay, that would be fine, trivial query - will it be okay to include
'linux/platform_device.h' in the AMBA bus? I am reluctant for this change
because of including platform file.

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

[PATCH] drm/i915/gvt/scheduler: Remove unnecessary NULL checks in sr_oa_regs

[Gustavo A. R. Silva]

The checks are misleading and not required [1].

[1] https://lkml.org/lkml/2018/3/19/1792

Addresses-Coverity-ID: 1466017
Cc: Chris Wilson 
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/gpu/drm/i915/gvt/scheduler.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
b/drivers/gpu/drm/i915/gvt/scheduler.c
index 78588ef..b6da223 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -74,7 +74,7 @@ static void sr_oa_regs(struct intel_vgpu_workload *workload,
i915_mmio_reg_offset(EU_PERF_CNTL6),
};
 
-   if (!workload || !reg_state || workload->ring_id != RCS)
+   if (workload->ring_id != RCS)
return;
 
if (save) {
-- 
2.7.4

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

Re: [PATCH] drm/i915/gvt/scheduler: fix potential NULL pointer dereference

[Gustavo A. R. Silva]

Hi Chris,

On 03/19/2018 03:38 PM, Chris Wilson wrote:

Quoting Gustavo A. R. Silva (2018-03-19 19:30:53)

_workload_ is being dereferenced before it is null checked, hence
there is a potential null pointer dereference.

Fix this by moving the pointer dereference after _workload_ has
been null checked.


The checks are misleading and not required.


All of them?

if (!workload || !reg_state || workload->ring_id != RCS)
return;

or just the null check on workload ?

Thanks for the feedback.
--
Gustavo

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

[PATCH 06/10] drm/sun4i: Move and extend format-related helpers and tables

[Paul Kocialkowski]

This moves the various helpers and tables related to format detection
and conversion to a dedicated file, while adding a bunch of new helpers
(especially for YUV and tiling support) along the way.

Signed-off-by: Paul Kocialkowski 
---
 drivers/gpu/drm/sun4i/Makefile|   1 +
 drivers/gpu/drm/sun4i/sun4i_backend.c |  54 ++
 drivers/gpu/drm/sun4i/sun4i_format.c  | 193 ++
 drivers/gpu/drm/sun4i/sun4i_format.h  |  35 ++
 4 files changed, 235 insertions(+), 48 deletions(-)
 create mode 100644 drivers/gpu/drm/sun4i/sun4i_format.c
 create mode 100644 drivers/gpu/drm/sun4i/sun4i_format.h

diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index 582607c0c488..c89c42ff803e 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -4,6 +4,7 @@ sun4i-frontend-y+= sun4i_frontend.o
 
 sun4i-drm-y+= sun4i_drv.o
 sun4i-drm-y+= sun4i_framebuffer.o
+sun4i-drm-y+= sun4i_format.o
 
 sun4i-drm-hdmi-y   += sun4i_hdmi_ddc_clk.o
 sun4i-drm-hdmi-y   += sun4i_hdmi_enc.o
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index 1fad0714c70e..e8af9f3cf20b 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -29,6 +29,7 @@
 #include "sun4i_drv.h"
 #include "sun4i_frontend.h"
 #include "sun4i_layer.h"
+#include "sun4i_format.h"
 #include "sunxi_engine.h"
 
 struct sun4i_backend_quirks {
@@ -36,50 +37,6 @@ struct sun4i_backend_quirks {
bool needs_output_muxing;
 };
 
-static const u32 sunxi_rgb2yuv_coef[12] = {
-   0x0107, 0x0204, 0x0064, 0x0108,
-   0x3f69, 0x3ed6, 0x01c1, 0x0808,
-   0x01c1, 0x3e88, 0x3fb8, 0x0808
-};
-
-static const u32 sunxi_bt601_yuv2rgb_coef[12] = {
-   0x04a7, 0x1e6f, 0x1cbf, 0x0877,
-   0x04a7, 0x, 0x0662, 0x3211,
-   0x04a7, 0x0812, 0x, 0x2eb1,
-};
-
-static inline bool sun4i_backend_format_is_planar_yuv(uint32_t format)
-{
-   switch (format) {
-   case DRM_FORMAT_YUV411:
-   case DRM_FORMAT_YUV422:
-   case DRM_FORMAT_YUV444:
-   return true;
-   default:
-   return false;
-   }
-}
-
-static inline bool sun4i_backend_format_is_packed_yuv422(uint32_t format)
-{
-   switch (format) {
-   case DRM_FORMAT_YUYV:
-   case DRM_FORMAT_YVYU:
-   case DRM_FORMAT_UYVY:
-   case DRM_FORMAT_VYUY:
-   return true;
-
-   default:
-   return false;
-   }
-}
-
-static inline bool sun4i_backend_format_is_yuv(uint32_t format)
-{
-   return sun4i_backend_format_is_planar_yuv(format) ||
-   sun4i_backend_format_is_packed_yuv422(format);
-}
-
 static void sun4i_backend_apply_color_correction(struct sunxi_engine *engine)
 {
int i;
@@ -259,7 +216,7 @@ static int sun4i_backend_update_yuv_format(struct 
sun4i_backend *backend,
   SUN4I_BACKEND_ATTCTL_REG0_LAY_YUVEN,
   SUN4I_BACKEND_ATTCTL_REG0_LAY_YUVEN);
 
-   if (sun4i_backend_format_is_packed_yuv422(format))
+   if (sun4i_format_is_packed_yuv422(format))
val |= SUN4I_BACKEND_IYUVCTL_FBFMT_PACKED_YUV422;
else
DRM_DEBUG_DRIVER("Unknown YUV format\n");
@@ -310,7 +267,7 @@ int sun4i_backend_update_layer_formats(struct sun4i_backend 
*backend,
DRM_DEBUG_DRIVER("Switching display backend interlaced mode %s\n",
 interlaced ? "on" : "off");
 
-   if (sun4i_backend_format_is_yuv(fb->format->format))
+   if (sun4i_format_is_yuv(fb->format->format))
return sun4i_backend_update_yuv_format(backend, layer, plane);
 
ret = sun4i_backend_drm_format_to_layer(fb->format->format, );
@@ -404,7 +361,7 @@ int sun4i_backend_update_layer_buffer(struct sun4i_backend 
*backend,
 */
paddr -= PHYS_OFFSET;
 
-   if (sun4i_backend_format_is_yuv(fb->format->format))
+   if (sun4i_format_is_yuv(fb->format->format))
return sun4i_backend_update_yuv_buffer(backend, fb, paddr);
 
/* Write the 32 lower bits of the address (in bits) */
@@ -549,10 +506,11 @@ static int sun4i_backend_atomic_check(struct sunxi_engine 
*engine,
DRM_DEBUG_DRIVER("Plane FB format is %s\n",
 drm_get_format_name(fb->format->format,
 _name));
+
if (fb->format->has_alpha)
num_alpha_planes++;
 
-   if (sun4i_backend_format_is_yuv(fb->format->format)) {
+   if (sun4i_format_is_yuv(fb->format->format)) {
DRM_DEBUG_DRIVER("Plane FB format is YUV\n");
num_yuv_planes++;

[PATCH 02/10] drm/sun4i: Disable YUV channel when using the frontend and set interlace

[Paul Kocialkowski]

The YUV channel was only disabled in sun4i_backend_update_layer_formats,
which is not called when the frontend is selected.

Thus, creating a layer with a YUV format handled by the backend and then
switching to a format that requires the frontend would keep the YUV
channel enabled for the layer.

This explicitly disables the YUV channel for the layer when using the
frontend as well. It also sets the relevant interlace bit, which was
missing in the frontend path as well.

Signed-off-by: Paul Kocialkowski 
---
 drivers/gpu/drm/sun4i/sun4i_backend.c | 17 -
 drivers/gpu/drm/sun4i/sun4i_backend.h |  3 ++-
 drivers/gpu/drm/sun4i/sun4i_layer.c   |  2 +-
 3 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index e07a33adc51d..b98dafda52f8 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -294,8 +294,10 @@ int sun4i_backend_update_layer_formats(struct 
sun4i_backend *backend,
 }
 
 int sun4i_backend_update_layer_frontend(struct sun4i_backend *backend,
-   int layer, uint32_t fmt)
+   int layer, struct drm_plane *plane,
+   uint32_t fmt)
 {
+   bool interlaced = false;
u32 val;
int ret;
 
@@ -305,11 +307,24 @@ int sun4i_backend_update_layer_frontend(struct 
sun4i_backend *backend,
return ret;
}
 
+   /* Clear the YUV mode */
+   regmap_update_bits(backend->engine.regs,
+  SUN4I_BACKEND_ATTCTL_REG0(layer),
+  SUN4I_BACKEND_ATTCTL_REG0_LAY_YUVEN, 0);
+
regmap_update_bits(backend->engine.regs,
   SUN4I_BACKEND_ATTCTL_REG0(layer),
   SUN4I_BACKEND_ATTCTL_REG0_LAY_VDOEN,
   SUN4I_BACKEND_ATTCTL_REG0_LAY_VDOEN);
 
+   if (plane->state->crtc)
+   interlaced = plane->state->crtc->state->adjusted_mode.flags
+   & DRM_MODE_FLAG_INTERLACE;
+
+   regmap_update_bits(backend->engine.regs, SUN4I_BACKEND_MODCTL_REG,
+  SUN4I_BACKEND_MODCTL_ITLMOD_EN,
+  interlaced ? SUN4I_BACKEND_MODCTL_ITLMOD_EN : 0);
+
regmap_update_bits(backend->engine.regs,
   SUN4I_BACKEND_ATTCTL_REG1(layer),
   SUN4I_BACKEND_ATTCTL_REG1_LAY_FBFMT, val);
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.h 
b/drivers/gpu/drm/sun4i/sun4i_backend.h
index 7ae0f0ffec8c..cb6df2b690c0 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.h
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.h
@@ -201,7 +201,8 @@ int sun4i_backend_update_layer_formats(struct sun4i_backend 
*backend,
 int sun4i_backend_update_layer_buffer(struct sun4i_backend *backend,
  int layer, struct drm_plane *plane);
 int sun4i_backend_update_layer_frontend(struct sun4i_backend *backend,
-   int layer, uint32_t in_fmt);
+   int layer, struct drm_plane *plane,
+   uint32_t fmt);
 int sun4i_backend_update_layer_zpos(struct sun4i_backend *backend,
int layer, struct drm_plane *plane);
 void sun4i_backend_disable_layer_frontend(struct sun4i_backend *backend,
diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.c 
b/drivers/gpu/drm/sun4i/sun4i_layer.c
index 224bb1811e0a..eb93df445a10 100644
--- a/drivers/gpu/drm/sun4i/sun4i_layer.c
+++ b/drivers/gpu/drm/sun4i/sun4i_layer.c
@@ -101,7 +101,7 @@ static void sun4i_backend_layer_atomic_update(struct 
drm_plane *plane,
sun4i_frontend_update_buffer(frontend, plane);
sun4i_frontend_update_formats(frontend, plane,
  DRM_FORMAT_ARGB);
-   sun4i_backend_update_layer_frontend(backend, layer->id,
+   sun4i_backend_update_layer_frontend(backend, layer->id, plane,
DRM_FORMAT_ARGB);
sun4i_frontend_enable(frontend);
} else {
-- 
2.16.2

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

[PATCH] Allow non-desktop displays when not in strict mode

[Charles Lohr]

Considering the lukewarm reception of my last past request and Keith's 
recommendation, I've created and tested a new patch, to bring the intended 
functionality back, only prohibiting non-desktop devices if a regular desktop 
screen is present.

Previous email chain: 
https://lists.freedesktop.org/archives/dri-devel/2018-March/169558.html

I believe I've finally found a way of sending emails with word wrap turned off.

Thank you for your time and help understanding how this submission process 
works.

Charles



Signed-off-by: Charles Lohr 

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 035784ddd..ed08153ee 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2109,7 +2109,7 @@ static bool drm_connector_enabled(struct drm_connector 
*connector, bool strict)
 {
     bool enable;

-    if (connector->display_info.non_desktop)
+    if (connector->display_info.non_desktop && strict)
         return false;

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

[PATCH v2 1/2] dma-mapping: move dma configuration to bus infrastructure

[Nipun Gupta]

It's bus specific aspect to map a given device on the bus and
relevant firmware description of its DMA configuration.
So, this change introduces '/dma_configure/' as bus callback
giving flexibility to busses for implementing its own dma
configuration function.

The change eases the addition of new busses w.r.t. adding the dma
configuration functionality.

This patch also updates the PCI, Platform, ACPI and host1x bus to
use new introduced callbacks.

Suggested-by: Christoph Hellwig 
Signed-off-by: Nipun Gupta 
---
 - The patches are based on the comments on:
   https://patchwork.kernel.org/patch/10259087/

Changes in v2:
  - Do not have dma_deconfigure callback
  - Have '/dma_common_configure/' API to provide a common DMA
configuration which can be used by busses if it suits them.
  - Platform and ACPI bus to use '/dma_common_configure/' in
'/dma_configure/' callback.
  - Updated commit message
  - Updated pci_dma_configure API with changes suggested by Robin

 drivers/amba/bus.c  |  7 +++
 drivers/base/dma-mapping.c  | 35 +++
 drivers/base/platform.c |  6 ++
 drivers/gpu/host1x/bus.c|  9 +
 drivers/pci/pci-driver.c| 32 
 include/linux/device.h  |  4 
 include/linux/dma-mapping.h |  1 +
 7 files changed, 74 insertions(+), 20 deletions(-)

diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index 594c228..2fa1e8b 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -171,6 +172,11 @@ static int amba_pm_runtime_resume(struct device *dev)
 }
 #endif /* CONFIG_PM */
 
+static int amba_dma_configure(struct device *dev)
+{
+   return dma_common_configure(dev);
+}
+
 static const struct dev_pm_ops amba_pm = {
.suspend= pm_generic_suspend,
.resume = pm_generic_resume,
@@ -194,6 +200,7 @@ struct bus_type amba_bustype = {
.dev_groups = amba_dev_groups,
.match  = amba_match,
.uevent = amba_uevent,
+   .dma_configure  = amba_dma_configure,
.pm = _pm,
.force_dma  = true,
 };
diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
index 3b11835..48f9af0 100644
--- a/drivers/base/dma-mapping.c
+++ b/drivers/base/dma-mapping.c
@@ -331,38 +331,33 @@ void dma_common_free_remap(void *cpu_addr, size_t size, 
unsigned long vm_flags)
 #endif
 
 /*
- * Common configuration to enable DMA API use for a device
+ * Common configuration to enable DMA API use for a device.
+ * A bus can use this function in its 'dma_configure' callback, if
+ * suitable for the bus.
  */
-#include 
-
-int dma_configure(struct device *dev)
+int dma_common_configure(struct device *dev)
 {
-   struct device *bridge = NULL, *dma_dev = dev;
enum dev_dma_attr attr;
int ret = 0;
 
-   if (dev_is_pci(dev)) {
-   bridge = pci_get_host_bridge_device(to_pci_dev(dev));
-   dma_dev = bridge;
-   if (IS_ENABLED(CONFIG_OF) && dma_dev->parent &&
-   dma_dev->parent->of_node)
-   dma_dev = dma_dev->parent;
-   }
-
-   if (dma_dev->of_node) {
-   ret = of_dma_configure(dev, dma_dev->of_node);
-   } else if (has_acpi_companion(dma_dev)) {
-   attr = acpi_get_dma_attr(to_acpi_device_node(dma_dev->fwnode));
+   if (dev->of_node) {
+   ret = of_dma_configure(dev, dev->of_node);
+   } else if (has_acpi_companion(dev)) {
+   attr = acpi_get_dma_attr(to_acpi_device_node(dev->fwnode));
if (attr != DEV_DMA_NOT_SUPPORTED)
ret = acpi_dma_configure(dev, attr);
}
 
-   if (bridge)
-   pci_put_host_bridge_device(bridge);
-
return ret;
 }
 
+int dma_configure(struct device *dev)
+{
+   if (dev->bus->dma_configure)
+   return dev->bus->dma_configure(dev);
+
+   return 0;
+}
 void dma_deconfigure(struct device *dev)
 {
of_dma_deconfigure(dev);
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index f1bf7b3..d2d5891 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -1130,6 +1130,11 @@ int platform_pm_restore(struct device *dev)
 
 #endif /* CONFIG_HIBERNATE_CALLBACKS */
 
+static int platform_dma_configure(struct device *dev)
+{
+   return dma_common_configure(dev);
+}
+
 static const struct dev_pm_ops platform_dev_pm_ops = {
.runtime_suspend = pm_generic_runtime_suspend,
.runtime_resume = pm_generic_runtime_resume,
@@ -1141,6 +1146,7 @@ struct bus_type platform_bus_type = {
.dev_groups = platform_dev_groups,
.match  = platform_match,
.uevent = platform_uevent,
+   .dma_configure  = platform_dma_configure,
.pm = _dev_pm_ops,
.force_dma  = 

[PATCH v2] drm/dp/mst: Fix off-by-one typo when dump payload table

[Andy Shevchenko]

It seems there is a classical off-by-one typo from the beginning
when commit

  ad7f8a1f9ced ("drm/helper: add Displayport multi-stream helper (v0.6)")

introduced a new helper.

Fix a typo by introducing a macro constant.

Cc: Dave Airlie 
Signed-off-by: Andy Shevchenko 
---
- use macro for buffer length on stack

 drivers/gpu/drm/drm_dp_mst_topology.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 6fac4129e6a2..658830620ca3 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2941,12 +2941,14 @@ static void drm_dp_mst_dump_mstb(struct seq_file *m,
}
 }
 
+#define DP_PAYLOAD_TABLE_SIZE  64
+
 static bool dump_dp_payload_table(struct drm_dp_mst_topology_mgr *mgr,
  char *buf)
 {
int i;
 
-   for (i = 0; i < 64; i += 16) {
+   for (i = 0; i < DP_PAYLOAD_TABLE_SIZE; i += 16) {
if (drm_dp_dpcd_read(mgr->aux,
 DP_PAYLOAD_TABLE_UPDATE_STATUS + i,
 [i], 16) != 16)
@@ -3015,7 +3017,7 @@ void drm_dp_mst_dump_topology(struct seq_file *m,
 
mutex_lock(>lock);
if (mgr->mst_primary) {
-   u8 buf[64];
+   u8 buf[DP_PAYLOAD_TABLE_SIZE];
int ret;
 
ret = drm_dp_dpcd_read(mgr->aux, DP_DPCD_REV, buf, 
DP_RECEIVER_CAP_SIZE);
@@ -3033,8 +3035,7 @@ void drm_dp_mst_dump_topology(struct seq_file *m,
seq_printf(m, " revision: hw: %x.%x sw: %x.%x\n",
   buf[0x9] >> 4, buf[0x9] & 0xf, buf[0xa], buf[0xb]);
if (dump_dp_payload_table(mgr, buf))
-   seq_printf(m, "payload table: %*ph\n", 63, buf);
-
+   seq_printf(m, "payload table: %*ph\n", 
DP_PAYLOAD_TABLE_SIZE, buf);
}
 
mutex_unlock(>lock);
-- 
2.16.2

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

Re: [PATCHv2 2/8] drm/omap: add manual update detection helper

[Tony Lindgren]

* Sebastian Reichel  [180208 18:31]:
> In preparation for manually updated display support, such as DSI
> command mode panels, this adds a simple helper to see if a connector
> is manually updated.

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

[PATCH 07/10] drm/sun4i: Add support for YUV formats through the frontend

[Paul Kocialkowski]

The frontend supports many YUV formats as input and also contains a
color-space converter (CSC) block that can convert YUV input into
RGB output. It also allows scaling between the input and output for
every possible combination of supported formats.

This adds support for all the (untiled) YUV video formats supported by
the frontend, with associated changes in the backend and layer
management.

A specific dumb GEM create function translates a hardware constraint,
that the stride must be an even number, when allocating dumb (linear)
buffers.

Signed-off-by: Paul Kocialkowski 
---
 drivers/gpu/drm/sun4i/sun4i_backend.c  |  10 +-
 drivers/gpu/drm/sun4i/sun4i_drv.c  |  11 +-
 drivers/gpu/drm/sun4i/sun4i_drv.h  |   4 +
 drivers/gpu/drm/sun4i/sun4i_frontend.c | 234 -
 drivers/gpu/drm/sun4i/sun4i_frontend.h |  48 ++-
 drivers/gpu/drm/sun4i/sun4i_layer.c|  34 +++--
 6 files changed, 293 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index e8af9f3cf20b..3de7f3a427c3 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -500,6 +500,11 @@ static int sun4i_backend_atomic_check(struct sunxi_engine 
*engine,
layer_state->uses_frontend = true;
num_frontend_planes++;
} else {
+   if (sun4i_format_is_yuv(fb->format->format)) {
+   DRM_DEBUG_DRIVER("Plane FB format is YUV\n");
+   num_yuv_planes++;
+   }
+
layer_state->uses_frontend = false;
}
 
@@ -510,11 +515,6 @@ static int sun4i_backend_atomic_check(struct sunxi_engine 
*engine,
if (fb->format->has_alpha)
num_alpha_planes++;
 
-   if (sun4i_format_is_yuv(fb->format->format)) {
-   DRM_DEBUG_DRIVER("Plane FB format is YUV\n");
-   num_yuv_planes++;
-   }
-
DRM_DEBUG_DRIVER("Plane zpos is %d\n",
 plane_state->normalized_zpos);
 
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 3957c2ff6870..d374bb61c565 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -42,7 +42,7 @@ static struct drm_driver sun4i_drv_driver = {
.minor  = 0,
 
/* GEM Operations */
-   .dumb_create= drm_gem_cma_dumb_create,
+   .dumb_create= drm_sun4i_gem_dumb_create,
.gem_free_object_unlocked = drm_gem_cma_free_object,
.gem_vm_ops = _gem_cma_vm_ops,
 
@@ -60,6 +60,15 @@ static struct drm_driver sun4i_drv_driver = {
/* Frame Buffer Operations */
 };
 
+int drm_sun4i_gem_dumb_create(struct drm_file *file_priv,
+ struct drm_device *drm,
+ struct drm_mode_create_dumb *args)
+{
+   args->pitch = ALIGN(DIV_ROUND_UP(args->width * args->bpp, 8), 2);
+
+   return drm_gem_cma_dumb_create_internal(file_priv, drm, args);
+}
+
 static void sun4i_remove_framebuffers(void)
 {
struct apertures_struct *ap;
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.h 
b/drivers/gpu/drm/sun4i/sun4i_drv.h
index 5750b8ce8b31..47969711a889 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.h
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.h
@@ -23,4 +23,8 @@ struct sun4i_drv {
struct list_headtcon_list;
 };
 
+int drm_sun4i_gem_dumb_create(struct drm_file *file_priv,
+ struct drm_device *drm,
+ struct drm_mode_create_dumb *args);
+
 #endif /* _SUN4I_DRV_H_ */
diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c 
b/drivers/gpu/drm/sun4i/sun4i_frontend.c
index 2dc33383be22..d9e58e96119c 100644
--- a/drivers/gpu/drm/sun4i/sun4i_frontend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c
@@ -16,6 +16,7 @@
 #include 
 
 #include "sun4i_drv.h"
+#include "sun4i_format.h"
 #include "sun4i_frontend.h"
 
 static const u32 sun4i_frontend_vert_coef[32] = {
@@ -89,26 +90,135 @@ void sun4i_frontend_update_buffer(struct sun4i_frontend 
*frontend,
 {
struct drm_plane_state *state = plane->state;
struct drm_framebuffer *fb = state->fb;
+   uint32_t format = fb->format->format;
+   uint32_t width, height;
+   uint32_t stride, offset;
+   bool swap;
dma_addr_t paddr;
 
-   /* Set the line width */
-   DRM_DEBUG_DRIVER("Frontend stride: %d bytes\n", fb->pitches[0]);
+   width = state->src_w >> 16;
+   height = state->src_h >> 16;
+
regmap_write(frontend->regs, SUN4I_FRONTEND_LINESTRD0_REG,
 fb->pitches[0]);
 
+   if (drm_format_num_planes(format) > 1)
+   regmap_write(frontend->regs, SUN4I_FRONTEND_LINESTRD1_REG,
+   

Re: [PATCH v4 1/3] drm/panel: refactor INNOLUX P079ZCA panel driver

[hl]

Hi


On Tuesday, March 20, 2018 06:20 PM, Emil Velikov wrote:

On 20 March 2018 at 06:24, hl  wrote:

Hi Emil,



On Monday, March 19, 2018 09:09 PM, Emil Velikov wrote:

On 15 March 2018 at 02:35, hl  wrote:

Hi Emil,



On Wednesday, March 14, 2018 08:02 PM, Emil Velikov wrote:

Hi Lin,

On 14 March 2018 at 09:12, Lin Huang  wrote:

From: huang lin 

Refactor Innolux P079ZCA panel driver, let it support
multi panel.

Change-Id: If89be5e56dba8cb498e2d50c1bbeb0e8016123a2
Signed-off-by: Lin Huang 
---
Changes in v2:
- Change regulator property name to meet the panel datasheet
Changes in v3:
- this patch only refactor P079ZCA panel to support multi panel,
support
P097PFG panel in another patch
Changes in v4:
- Modify the patch which suggest by Thierry


Thanks for splitting this up. I think there's another piece that fell
through the cracks.
I'm not deeply familiar with the driver, so just sharing some quick
notes.



struct innolux_panel {
   struct drm_panel base;
   struct mipi_dsi_device *link;
+   const struct panel_desc *desc;

   struct backlight_device *backlight;
-   struct regulator *supply;
+   struct regulator *vddi;
+   struct regulator *avdd;
+   struct regulator *avee;

These two seem are new addition, as opposed to a dummy refactor.
Are they optional, does one need them for the existing panel (separate
patch?) or only for the new one (squash with the new panel code)?



   struct gpio_desc *enable_gpio;

   bool prepared;
@@ -77,9 +93,9 @@ static int innolux_panel_unprepare(struct drm_panel
*panel)
   /* T8: 80ms - 1000ms */
   msleep(80);

-   err = regulator_disable(innolux->supply);
-   if (err < 0)
-   return err;

Good call on dropping the early return here.



@@ -207,19 +248,28 @@ static const struct drm_panel_funcs
innolux_panel_funcs = {
-   innolux->supply = devm_regulator_get(dev, "power");
-   if (IS_ERR(innolux->supply))
-   return PTR_ERR(innolux->supply);
+   innolux = devm_kzalloc(dev, sizeof(*innolux), GFP_KERNEL);
+   if (!innolux)
+   return -ENOMEM;
+
+   innolux->desc = desc;
+   innolux->vddi = devm_regulator_get(dev, "power");
+   innolux->avdd = devm_regulator_get(dev, "avdd");
+   innolux->avee = devm_regulator_get(dev, "avee");


AFAICT devm_regulator_get returns a pointer which is unsuitable to be
passed into regulator_{enable,disable}.
Hence, the IS_ERR check should stay. If any of the regulators are
optional, you want to call regulator_{enable,disable} only as
applicable.


devm_regulator_get() will use dummy_regulator if there not regulator pass
to
driver, so it not affect regulator_{enable, disable}.

One of us is getting confused here:
devm_regulator_get does not _use_ a regulator, it returns a pointer to
a regulator, right?

According to the 4.16-rc6 codebase - one error
returns a ERR_PTR [1].

devm_regulator_get() will not reurn a ERR_PTR,  it will pass NORMAL_GET mode
to
_regulator_get() when you call devm_regulator_get(), and with following
code:


Just before the _regulator_get() call we have "return ERR_PTR(-ENOMEM);"
See 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/regulator/devres.c?h=v4.16-rc6#n34
Okay, i got what you concern now, yes, you are right, i will keep IS_ERR 
checking here.



With the pointer dereferenced in regulator_enable [2], without a
IS_ERR check, hence thing will go boom(?)


These three regulator are
optional,
the p079zca will use "power" and ,
so i think it better not to check ERR here.


What should happen if p079zca is missing "power" or p097pgf - "avdd" and
"avee"?
Obviously the latter two should be introduced with the p097pgf support.

i think it need dts to make sure configure the power node correct, if
missing
"power" node fo p079zca or "avdd" "avee" node for p097pgf, the panel can
not work, but do not affcet other driver, the kernel do not crash(as i
explain before and i also test it).


If you know it won't work just don't continue? And yes, it will crash ;-)
Either way, if you don't like my feedback so be it.

HTH
Emil
P.S. As a non native English speaker to another - spell checker helps a lot ;-)






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

Re: [GIT PULL] drm/tegra: Changes for v4.17-rc1

[Marcel Ziswiler]

On Mon, 2018-03-19 at 17:52 +0100, Thierry Reding wrote:
> On Mon, Mar 19, 2018 at 02:32:08PM +, Marcel Ziswiler wrote:
> > Hi Thierry
> > 
> > On Mon, 2018-03-19 at 10:59 +0100, Thierry Reding wrote:
> > > Hi Dave,
> > > 
> > > The following changes since commit
> > > 7928b2cbe55b2a410a0f5c1f154610059c57b1b2:
> > > 
> > >   Linux 4.16-rc1 (2018-02-11 15:04:29 -0800)
> > > 
> > > are available in the Git repository at:
> > > 
> > >   git://anongit.freedesktop.org/tegra/linux tags/drm/tegra/for-
> > > 4.17-
> > > rc1
> > > 
> > > for you to fetch changes up to
> > > 27e92f1f1600c214bf649daddb9b88b68330a8d1:
> > > 
> > >   drm/tegra: prime: Implement ->{begin,end}_cpu_access() (2018-
> > > 03-17
> > > 00:04:20 +0100)
> > > 
> > > Apologies for the delay. I originally wanted to send this out on
> > > Friday
> > > but then ran into a pair of bugs that I thought might be caused
> > > by
> > > this
> > > branch. Turns out that they were both already broken in v4.16-rc1 
> > > and
> > > I
> > > just hadn't tested for the corner case, so I caught them only
> > > very
> > > late
> > > in the release cycle.
> > > 
> > > Anyway, the fixes for that are on the drm/tegra/fixes branch for
> > > which
> > > I sent an updated pull request earlier. The stuff here's fairly
> > > trivial
> > > and incremental improvements.
> > 
> > Both linux-next as of Friday and today as well as your
> > tags/drm/tegra/for-4.17-rc1 fail for me on TK1 as follows:
> > 
> > [3.609146] +V1.05_AVDD_HDMI_PLL: supplied by +V1.05
> > [3.614294] +V3.3_AVDD_HDMI: supplied by +V1.05
> > [3.622078] [ cut here ]
> > [3.626719] WARNING: CPU: 2 PID: 87 at
> > /run/media/zim/Build/Sources/linux-
> > tegra.git/drivers/gpu/drm/drm_fourcc.c:204
> > drm_format_info+0x48/0x50
> > [3.639588] Modules linked in:
> > [3.642673] CPU: 2 PID: 87 Comm: kworker/2:1 Not tainted 4.16.0-
> > rc1
> > #2
> > [3.649213] Hardware name: NVIDIA Tegra SoC (Flattened Device
> > Tree)
> > [3.655495] Workqueue: events deferred_probe_work_func
> > [3.660672] [] (unwind_backtrace) from []
> > (show_stack+0x10/0x14)
> > [3.668430] [] (show_stack) from []
> > (dump_stack+0x8c/0xa0)
> > [3.675684] [] (dump_stack) from []
> > (__warn+0xe0/0xf8)
> > [3.682587] [] (__warn) from []
> > (warn_slowpath_null+0x40/0x48)
> > [3.690189] [] (warn_slowpath_null) from []
> > (drm_format_info+0x48/0x50)
> > [3.698551] [] (drm_format_info) from []
> > (tegra_plane_format_mod_supported+0x14/0x30)
> > [3.708150] [] (tegra_plane_format_mod_supported) from
> > [] (drm_universal_plane_init+0x2ec/0x59c)
> > [3.718703] [] (drm_universal_plane_init) from
> > [] (tegra_dc_init+0x1b8/0x510)
> > [3.727611] [] (tegra_dc_init) from []
> > (host1x_device_init+0x44/0xd0)
> > [3.735821] [] (host1x_device_init) from []
> > (tegra_drm_load+0x228/0x308)
> > [3.744291] [] (tegra_drm_load) from []
> > (drm_dev_register+0x138/0x1d0)
> > [3.752588] [] (drm_dev_register) from []
> > (host1x_drm_probe+0x34/0x58)
> > [3.760883] [] (host1x_drm_probe) from []
> > (driver_probe_device+0x254/0x32c)
> > [3.769612] [] (driver_probe_device) from []
> > (bus_for_each_drv+0x58/0xb8)
> > [3.778145] [] (bus_for_each_drv) from []
> > (__device_attach+0xd0/0x138)
> > [3.786436] [] (__device_attach) from []
> > (bus_probe_device+0x84/0x8c)
> > [3.794645] [] (bus_probe_device) from []
> > (device_add+0x3b4/0x5b8)
> > [3.802599] [] (device_add) from []
> > (host1x_subdev_register+0xac/0xd4)
> > [3.810897] [] (host1x_subdev_register) from
> > []
> > (host1x_client_register+0x108/0x128)
> > [3.820412] [] (host1x_client_register) from
> > []
> > (tegra_hdmi_probe+0x1e4/0x2d0)
> > [3.829406] [] (tegra_hdmi_probe) from []
> > (platform_drv_probe+0x50/0xac)
> > [3.837855] [] (platform_drv_probe) from []
> > (driver_probe_device+0x254/0x32c)
> > [3.846756] [] (driver_probe_device) from []
> > (bus_for_each_drv+0x58/0xb8)
> > [3.855309] [] (bus_for_each_drv) from []
> > (__device_attach+0xd0/0x138)
> > [3.863603] [] (__device_attach) from []
> > (bus_probe_device+0x84/0x8c)
> > [3.871809] [] (bus_probe_device) from []
> > (deferred_probe_work_func+0x4c/0x148)
> > [3.880885] [] (deferred_probe_work_func) from
> > [] (process_one_work+0x1ec/0x55c)
> > [3.890047] [] (process_one_work) from []
> > (worker_thread+0x29c/0x598)
> > [3.898237] [] (worker_thread) from []
> > (kthread+0x14c/0x154)
> > [3.905662] [] (kthread) from []
> > (ret_from_fork+0x14/0x2c)
> > [3.912901] Exception stack(0xee2b1fb0 to 0xee2b1ff8)
> > [3.917958] 1fa0: 
> >   
> > [3.926153] 1fc0:     
> >   
> > [3.934348] 1fe0:     0013
> > 
> > [3.941050] ---[ end trace f2913c9fb893aca6 ]---
> > ...
> > [4.594476] 

[PATCH 1/4] GPU: drm: Fixed Spacing issue

[Paul McQuade]

"foo * bar" should be "foo *bar"

Signed-off-by: Paul McQuade 
---
 drivers/gpu/drm/drm_bufs.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index 1ee84dd802d4..83b3d0801262 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -129,7 +129,7 @@ static int drm_map_handle(struct drm_device *dev, struct 
drm_hash_item *hash,
  * type.  Adds the map to the map list drm_device::maplist. Adds MTRR's where
  * applicable and if supported by the kernel.
  */
-static int drm_addmap_core(struct drm_device * dev, resource_size_t offset,
+static int drm_addmap_core(struct drm_device *dev, resource_size_t offset,
   unsigned int size, enum drm_map_type type,
   enum drm_map_flags flags,
   struct drm_map_list ** maplist)
@@ -361,7 +361,7 @@ static int drm_addmap_core(struct drm_device * dev, 
resource_size_t offset,
return 0;
 }
 
-int drm_legacy_addmap(struct drm_device * dev, resource_size_t offset,
+int drm_legacy_addmap(struct drm_device *dev, resource_size_t offset,
  unsigned int size, enum drm_map_type type,
  enum drm_map_flags flags, struct drm_local_map **map_ptr)
 {
@@ -637,8 +637,8 @@ int drm_legacy_rmmap_ioctl(struct drm_device *dev, void 
*data,
  *
  * Frees any pages and buffers associated with the given entry.
  */
-static void drm_cleanup_buf_error(struct drm_device * dev,
- struct drm_buf_entry * entry)
+static void drm_cleanup_buf_error(struct drm_device *dev,
+ struct drm_buf_entry *entry)
 {
int i;
 
-- 
2.16.2

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

[PATCH 2/2] drm/sun4i: hdmi: Fix another error handling path in 'sun4i_hdmi_bind()'

[Christophe JAILLET]

If we can not get the HDMI DDC clock, we still need to free some
resources before returning.

Fixes: 939d749ad664 ("drm/sun4i: hdmi: Add support for controller hardware 
variants")
Signed-off-by: Christophe JAILLET 
---
 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c 
b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
index d2839727bb0b..fa4bcd092eaf 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
@@ -552,7 +552,8 @@ static int sun4i_hdmi_bind(struct device *dev, struct 
device *master,
hdmi->ddc_parent_clk = devm_clk_get(dev, "ddc");
if (IS_ERR(hdmi->ddc_parent_clk)) {
dev_err(dev, "Couldn't get the HDMI DDC clock\n");
-   return PTR_ERR(hdmi->ddc_parent_clk);
+   ret = PTR_ERR(hdmi->ddc_parent_clk);
+   goto err_disable_mod_clk;
}
} else {
hdmi->ddc_parent_clk = hdmi->tmds_clk;
-- 
2.14.1

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

Re: [GIT PULL] drm/tegra: Changes for v4.17-rc1

[Marcel Ziswiler]

Hi Thierry

On Mon, 2018-03-19 at 10:59 +0100, Thierry Reding wrote:
> Hi Dave,
> 
> The following changes since commit
> 7928b2cbe55b2a410a0f5c1f154610059c57b1b2:
> 
>   Linux 4.16-rc1 (2018-02-11 15:04:29 -0800)
> 
> are available in the Git repository at:
> 
>   git://anongit.freedesktop.org/tegra/linux tags/drm/tegra/for-4.17-
> rc1
> 
> for you to fetch changes up to
> 27e92f1f1600c214bf649daddb9b88b68330a8d1:
> 
>   drm/tegra: prime: Implement ->{begin,end}_cpu_access() (2018-03-17
> 00:04:20 +0100)
> 
> Apologies for the delay. I originally wanted to send this out on
> Friday
> but then ran into a pair of bugs that I thought might be caused by
> this
> branch. Turns out that they were both already broken in v4.16-rc1 and
> I
> just hadn't tested for the corner case, so I caught them only very
> late
> in the release cycle.
> 
> Anyway, the fixes for that are on the drm/tegra/fixes branch for
> which
> I sent an updated pull request earlier. The stuff here's fairly
> trivial
> and incremental improvements.

Both linux-next as of Friday and today as well as your
tags/drm/tegra/for-4.17-rc1 fail for me on TK1 as follows:

[3.609146] +V1.05_AVDD_HDMI_PLL: supplied by +V1.05
[3.614294] +V3.3_AVDD_HDMI: supplied by +V1.05
[3.622078] [ cut here ]
[3.626719] WARNING: CPU: 2 PID: 87 at
/run/media/zim/Build/Sources/linux-
tegra.git/drivers/gpu/drm/drm_fourcc.c:204 drm_format_info+0x48/0x50
[3.639588] Modules linked in:
[3.642673] CPU: 2 PID: 87 Comm: kworker/2:1 Not tainted 4.16.0-rc1
#2
[3.649213] Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
[3.655495] Workqueue: events deferred_probe_work_func
[3.660672] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[3.668430] [] (show_stack) from []
(dump_stack+0x8c/0xa0)
[3.675684] [] (dump_stack) from []
(__warn+0xe0/0xf8)
[3.682587] [] (__warn) from []
(warn_slowpath_null+0x40/0x48)
[3.690189] [] (warn_slowpath_null) from []
(drm_format_info+0x48/0x50)
[3.698551] [] (drm_format_info) from []
(tegra_plane_format_mod_supported+0x14/0x30)
[3.708150] [] (tegra_plane_format_mod_supported) from
[] (drm_universal_plane_init+0x2ec/0x59c)
[3.718703] [] (drm_universal_plane_init) from
[] (tegra_dc_init+0x1b8/0x510)
[3.727611] [] (tegra_dc_init) from []
(host1x_device_init+0x44/0xd0)
[3.735821] [] (host1x_device_init) from []
(tegra_drm_load+0x228/0x308)
[3.744291] [] (tegra_drm_load) from []
(drm_dev_register+0x138/0x1d0)
[3.752588] [] (drm_dev_register) from []
(host1x_drm_probe+0x34/0x58)
[3.760883] [] (host1x_drm_probe) from []
(driver_probe_device+0x254/0x32c)
[3.769612] [] (driver_probe_device) from []
(bus_for_each_drv+0x58/0xb8)
[3.778145] [] (bus_for_each_drv) from []
(__device_attach+0xd0/0x138)
[3.786436] [] (__device_attach) from []
(bus_probe_device+0x84/0x8c)
[3.794645] [] (bus_probe_device) from []
(device_add+0x3b4/0x5b8)
[3.802599] [] (device_add) from []
(host1x_subdev_register+0xac/0xd4)
[3.810897] [] (host1x_subdev_register) from []
(host1x_client_register+0x108/0x128)
[3.820412] [] (host1x_client_register) from []
(tegra_hdmi_probe+0x1e4/0x2d0)
[3.829406] [] (tegra_hdmi_probe) from []
(platform_drv_probe+0x50/0xac)
[3.837855] [] (platform_drv_probe) from []
(driver_probe_device+0x254/0x32c)
[3.846756] [] (driver_probe_device) from []
(bus_for_each_drv+0x58/0xb8)
[3.855309] [] (bus_for_each_drv) from []
(__device_attach+0xd0/0x138)
[3.863603] [] (__device_attach) from []
(bus_probe_device+0x84/0x8c)
[3.871809] [] (bus_probe_device) from []
(deferred_probe_work_func+0x4c/0x148)
[3.880885] [] (deferred_probe_work_func) from
[] (process_one_work+0x1ec/0x55c)
[3.890047] [] (process_one_work) from []
(worker_thread+0x29c/0x598)
[3.898237] [] (worker_thread) from []
(kthread+0x14c/0x154)
[3.905662] [] (kthread) from []
(ret_from_fork+0x14/0x2c)
[3.912901] Exception stack(0xee2b1fb0 to 0xee2b1ff8)
[3.917958] 1fa0: 
  
[3.926153] 1fc0:     
  
[3.934348] 1fe0:     0013

[3.941050] ---[ end trace f2913c9fb893aca6 ]---
...
[4.594476] Unable to handle kernel NULL pointer dereference at
virtual address 0005
[4.602584] pgd = b237c3d6
[4.605293] [0005] *pgd=
[4.608895] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[4.614209] Modules linked in:
[4.617274] CPU: 2 PID: 87 Comm: kworker/2:1 Tainted:
GW4.16.0-rc1 #2
[4.625105] Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
[4.631376] Workqueue: events deferred_probe_work_func
[4.636525] PC is at tegra_plane_format_mod_supported+0x18/0x30
[4.642448] LR is at warn_slowpath_null+0x40/0x48
[4.647153] pc : []lr : []psr: 2113
[4.653419] sp : ee2b1be0  ip 

Re: [PATCH RESEND v2 0/2] drm/xen-front: Add support for Xen PV display frontend

[Boris Ostrovsky]

On 03/13/2018 12:21 PM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko 
>
> Hello!
>
> Resending with all the patches squashed on Daniel's request.

Which of the two series are we supposed to review? The 8-patch one or
this? (I hope it's the former)

-boris



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

[PATCH DRM] drm/zte: Replace include drmP.h with drm_print.h

[Haneen Mohammed]

Remove drmP.h as it is not needed anymore since nothing it defines is
used in these files and use drm_print.h instead as these files are using
the debug macros defined there.

Signed-off-by: Haneen Mohammed 
---
 drivers/gpu/drm/zte/zx_drm_drv.c | 2 +-
 drivers/gpu/drm/zte/zx_hdmi.c| 2 +-
 drivers/gpu/drm/zte/zx_plane.c   | 2 +-
 drivers/gpu/drm/zte/zx_tvenc.c   | 2 +-
 drivers/gpu/drm/zte/zx_vga.c | 2 +-
 drivers/gpu/drm/zte/zx_vou.c | 2 +-
 6 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/zte/zx_drm_drv.c b/drivers/gpu/drm/zte/zx_drm_drv.c
index 6f4205e8..f375cb0 100644
--- a/drivers/gpu/drm/zte/zx_drm_drv.c
+++ b/drivers/gpu/drm/zte/zx_drm_drv.c
@@ -24,7 +24,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "zx_drm_drv.h"
 #include "zx_vou.h"
diff --git a/drivers/gpu/drm/zte/zx_hdmi.c b/drivers/gpu/drm/zte/zx_hdmi.c
index 13ea90f..4cc9ebd 100644
--- a/drivers/gpu/drm/zte/zx_hdmi.c
+++ b/drivers/gpu/drm/zte/zx_hdmi.c
@@ -23,7 +23,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include 
 
diff --git a/drivers/gpu/drm/zte/zx_plane.c b/drivers/gpu/drm/zte/zx_plane.c
index 68fd2e2..a99 100644
--- a/drivers/gpu/drm/zte/zx_plane.c
+++ b/drivers/gpu/drm/zte/zx_plane.c
@@ -14,7 +14,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "zx_common_regs.h"
 #include "zx_drm_drv.h"
diff --git a/drivers/gpu/drm/zte/zx_tvenc.c b/drivers/gpu/drm/zte/zx_tvenc.c
index 0de1a71..355b7fb 100644
--- a/drivers/gpu/drm/zte/zx_tvenc.c
+++ b/drivers/gpu/drm/zte/zx_tvenc.c
@@ -15,7 +15,7 @@
 
 #include 
 #include 
-#include 
+#include 
 
 #include "zx_drm_drv.h"
 #include "zx_tvenc_regs.h"
diff --git a/drivers/gpu/drm/zte/zx_vga.c b/drivers/gpu/drm/zte/zx_vga.c
index 3e7e33c..9d18e8a 100644
--- a/drivers/gpu/drm/zte/zx_vga.c
+++ b/drivers/gpu/drm/zte/zx_vga.c
@@ -14,7 +14,7 @@
 
 #include 
 #include 
-#include 
+#include 
 
 #include "zx_drm_drv.h"
 #include "zx_vga_regs.h"
diff --git a/drivers/gpu/drm/zte/zx_vou.c b/drivers/gpu/drm/zte/zx_vou.c
index 7491813..7f49c1f 100644
--- a/drivers/gpu/drm/zte/zx_vou.c
+++ b/drivers/gpu/drm/zte/zx_vou.c
@@ -21,7 +21,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "zx_common_regs.h"
 #include "zx_drm_drv.h"
-- 
2.7.4

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

[PATCH] video: fbdev: aty128fb: use true and false for boolean values

[Gustavo A. R. Silva]

Assign true or false to boolean variables instead of an integer value.

This issue was detected with the help of Coccinelle.

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/video/fbdev/aty/aty128fb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/aty/aty128fb.c 
b/drivers/video/fbdev/aty/aty128fb.c
index db18474..09b0e55 100644
--- a/drivers/video/fbdev/aty/aty128fb.c
+++ b/drivers/video/fbdev/aty/aty128fb.c
@@ -1716,7 +1716,7 @@ static int aty128fb_setup(char *options)
continue;
}
if(!strncmp(this_opt, "nomtrr", 6)) {
-   mtrr = 0;
+   mtrr = false;
continue;
}
 #ifdef CONFIG_PPC_PMAC
-- 
2.7.4

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

Re: [PATCH v4 1/3] drm/panel: refactor INNOLUX P079ZCA panel driver

[hl]

Hi Emil,


On Monday, March 19, 2018 09:09 PM, Emil Velikov wrote:

On 15 March 2018 at 02:35, hl  wrote:

Hi Emil,



On Wednesday, March 14, 2018 08:02 PM, Emil Velikov wrote:

Hi Lin,

On 14 March 2018 at 09:12, Lin Huang  wrote:

From: huang lin 

Refactor Innolux P079ZCA panel driver, let it support
multi panel.

Change-Id: If89be5e56dba8cb498e2d50c1bbeb0e8016123a2
Signed-off-by: Lin Huang 
---
Changes in v2:
- Change regulator property name to meet the panel datasheet
Changes in v3:
- this patch only refactor P079ZCA panel to support multi panel, support
P097PFG panel in another patch
Changes in v4:
- Modify the patch which suggest by Thierry


Thanks for splitting this up. I think there's another piece that fell
through the cracks.
I'm not deeply familiar with the driver, so just sharing some quick notes.



   struct innolux_panel {
  struct drm_panel base;
  struct mipi_dsi_device *link;
+   const struct panel_desc *desc;

  struct backlight_device *backlight;
-   struct regulator *supply;
+   struct regulator *vddi;
+   struct regulator *avdd;
+   struct regulator *avee;

These two seem are new addition, as opposed to a dummy refactor.
Are they optional, does one need them for the existing panel (separate
patch?) or only for the new one (squash with the new panel code)?



  struct gpio_desc *enable_gpio;

  bool prepared;
@@ -77,9 +93,9 @@ static int innolux_panel_unprepare(struct drm_panel
*panel)
  /* T8: 80ms - 1000ms */
  msleep(80);

-   err = regulator_disable(innolux->supply);
-   if (err < 0)
-   return err;

Good call on dropping the early return here.



@@ -207,19 +248,28 @@ static const struct drm_panel_funcs
innolux_panel_funcs = {
-   innolux->supply = devm_regulator_get(dev, "power");
-   if (IS_ERR(innolux->supply))
-   return PTR_ERR(innolux->supply);
+   innolux = devm_kzalloc(dev, sizeof(*innolux), GFP_KERNEL);
+   if (!innolux)
+   return -ENOMEM;
+
+   innolux->desc = desc;
+   innolux->vddi = devm_regulator_get(dev, "power");
+   innolux->avdd = devm_regulator_get(dev, "avdd");
+   innolux->avee = devm_regulator_get(dev, "avee");


AFAICT devm_regulator_get returns a pointer which is unsuitable to be
passed into regulator_{enable,disable}.
Hence, the IS_ERR check should stay. If any of the regulators are
optional, you want to call regulator_{enable,disable} only as
applicable.


devm_regulator_get() will use dummy_regulator if there not regulator pass to
driver, so it not affect regulator_{enable, disable}.

One of us is getting confused here:
devm_regulator_get does not _use_ a regulator, it returns a pointer to
a regulator, right?

According to the 4.16-rc6 codebase - one error
returns a ERR_PTR [1].
devm_regulator_get() will not reurn a ERR_PTR,  it will pass NORMAL_GET 
mode to
_regulator_get() when you call devm_regulator_get(), and with following 
code:



rdev = regulator_dev_lookup(dev, id);
    if (IS_ERR(rdev)) {
.
..
    switch (get_type) {
        case NORMAL_GET:
            /*
             * Assume that a regulator is physically present and
             * enabled, even if it isn't hooked up, and just
             * provide a dummy.
             */
            dev_warn(dev,
                 "%s supply %s not found, using dummy regulator\n",
                 devname, id);
            rdev = dummy_regulator_rdev;
            get_device(>dev);
            break;
...
...
}

regulator = create_regulator(rdev, dev, id);
...

it wil get a dummy_regulator for it.




With the pointer dereferenced in regulator_enable [2], without a
IS_ERR check, hence thing will go boom(?)


These three regulator are
optional,
the p079zca will use "power" and ,
so i think it better not to check ERR here.


What should happen if p079zca is missing "power" or p097pgf - "avdd" and "avee"?
Obviously the latter two should be introduced with the p097pgf support.
i think it need dts to make sure configure the power node correct, if 
missing

"power" node fo p079zca or "avdd" "avee" node for p097pgf, the panel can
not work, but do not affcet other driver, the kernel do not crash(as i 
explain before and i also test it).


HTH
Emil

[1] 
https://elixir.bootlin.com/linux/v4.16-rc6/source/drivers/regulator/devres.c#L27
[2] 
https://elixir.bootlin.com/linux/v4.16-rc6/source/drivers/regulator/core.c#L2189






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

RE: [PATCH v2 2/2] drivers: remove force dma flag from buses

[Nipun Gupta]

> -Original Message-
> From: Christoph Hellwig [mailto:h...@lst.de]
> Sent: Thursday, March 22, 2018 13:49
> To: Nipun Gupta 
> 
> > --- a/drivers/dma/qcom/hidma_mgmt.c
> > +++ b/drivers/dma/qcom/hidma_mgmt.c
> > @@ -398,7 +398,7 @@ static int __init
> hidma_mgmt_of_populate_channels(struct device_node *np)
> > }
> > of_node_get(child);
> > new_pdev->dev.of_node = child;
> > -   of_dma_configure(_pdev->dev, child);
> > +   of_dma_configure(_pdev->dev, child, true);
> > /*
> >  * It is assumed that calling of_msi_configure is safe on
> >  * platforms with or without MSI support.
> 
> Where did we mark this bus as force_dma before?

I thought these devices to be on the platform bus as the device is of type
'struct platform_device', though I am not sure then why 'of_dma_configure()'
is called here. Is this not on platform bus?

> 
> > diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
> > index 9a4f4246..895c83e 100644
> > --- a/drivers/of/of_reserved_mem.c
> > +++ b/drivers/of/of_reserved_mem.c
> > @@ -353,7 +353,7 @@ int of_reserved_mem_device_init_by_idx(struct device
> *dev,
> > /* ensure that dma_ops is set for virtual devices
> >  * using reserved memory
> >  */
> > -   of_dma_configure(dev, np);
> > +   of_dma_configure(dev, np, true);
> 
> Did all the callers of this one really force dma?  I have a hard time
> untangling the call stacks unfortunately.

I see this API being called indirectly from NXP DPAA device driver which
is for platform bus devices. So I marked 'true' out here. There are more places
from where it is being called.

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

[PATCH v2 2/2] drivers: remove force dma flag from buses

[Nipun Gupta]

With each bus implementing its own DMA configuration callback,
there is no need for bus to explicitly have force_dma in its
global structure. This patch modifies of_dma_configure API to
accept an input parameter which specifies if implicit DMA
configuration is required even when it is not described by the
firmware.

Signed-off-by: Nipun Gupta 
---

Changes in v2:
  - This is a new change suggested by Robin and Christoph
and is added to the series.

 drivers/amba/bus.c| 3 +--
 drivers/base/dma-mapping.c| 4 ++--
 drivers/base/platform.c   | 3 +--
 drivers/bcma/main.c   | 2 +-
 drivers/dma/qcom/hidma_mgmt.c | 2 +-
 drivers/gpu/host1x/bus.c  | 5 ++---
 drivers/of/device.c   | 6 --
 drivers/of/of_reserved_mem.c  | 2 +-
 drivers/pci/pci-driver.c  | 3 +--
 include/linux/device.h| 4 
 include/linux/dma-mapping.h   | 2 +-
 include/linux/of_device.h | 4 +++-
 12 files changed, 18 insertions(+), 22 deletions(-)

diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index 2fa1e8b..1d58348 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -174,7 +174,7 @@ static int amba_pm_runtime_resume(struct device *dev)
 
 static int amba_dma_configure(struct device *dev)
 {
-   return dma_common_configure(dev);
+   return dma_common_configure(dev, true);
 }
 
 static const struct dev_pm_ops amba_pm = {
@@ -202,7 +202,6 @@ struct bus_type amba_bustype = {
.uevent = amba_uevent,
.dma_configure  = amba_dma_configure,
.pm = _pm,
-   .force_dma  = true,
 };
 
 static int __init amba_init(void)
diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
index 48f9af0..03f8584 100644
--- a/drivers/base/dma-mapping.c
+++ b/drivers/base/dma-mapping.c
@@ -335,13 +335,13 @@ void dma_common_free_remap(void *cpu_addr, size_t size, 
unsigned long vm_flags)
  * A bus can use this function in its 'dma_configure' callback, if
  * suitable for the bus.
  */
-int dma_common_configure(struct device *dev)
+int dma_common_configure(struct device *dev, bool force_dma)
 {
enum dev_dma_attr attr;
int ret = 0;
 
if (dev->of_node) {
-   ret = of_dma_configure(dev, dev->of_node);
+   ret = of_dma_configure(dev, dev->of_node, force_dma);
} else if (has_acpi_companion(dev)) {
attr = acpi_get_dma_attr(to_acpi_device_node(dev->fwnode));
if (attr != DEV_DMA_NOT_SUPPORTED)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index d2d5891..154707c 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -1132,7 +1132,7 @@ int platform_pm_restore(struct device *dev)
 
 static int platform_dma_configure(struct device *dev)
 {
-   return dma_common_configure(dev);
+   return dma_common_configure(dev, true);
 }
 
 static const struct dev_pm_ops platform_dev_pm_ops = {
@@ -1148,7 +1148,6 @@ struct bus_type platform_bus_type = {
.uevent = platform_uevent,
.dma_configure  = platform_dma_configure,
.pm = _dev_pm_ops,
-   .force_dma  = true,
 };
 EXPORT_SYMBOL_GPL(platform_bus_type);
 
diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
index e6986c7..fc1f4ac 100644
--- a/drivers/bcma/main.c
+++ b/drivers/bcma/main.c
@@ -207,7 +207,7 @@ static void bcma_of_fill_device(struct device *parent,
 
core->irq = bcma_of_get_irq(parent, core, 0);
 
-   of_dma_configure(>dev, node);
+   of_dma_configure(>dev, node, false);
 }
 
 unsigned int bcma_core_irq(struct bcma_device *core, int num)
diff --git a/drivers/dma/qcom/hidma_mgmt.c b/drivers/dma/qcom/hidma_mgmt.c
index 000c7019..d64edeb 100644
--- a/drivers/dma/qcom/hidma_mgmt.c
+++ b/drivers/dma/qcom/hidma_mgmt.c
@@ -398,7 +398,7 @@ static int __init hidma_mgmt_of_populate_channels(struct 
device_node *np)
}
of_node_get(child);
new_pdev->dev.of_node = child;
-   of_dma_configure(_pdev->dev, child);
+   of_dma_configure(_pdev->dev, child, true);
/*
 * It is assumed that calling of_msi_configure is safe on
 * platforms with or without MSI support.
diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
index fa9896d..211eb6b 100644
--- a/drivers/gpu/host1x/bus.c
+++ b/drivers/gpu/host1x/bus.c
@@ -317,7 +317,7 @@ static int host1x_device_match(struct device *dev, struct 
device_driver *drv)
 static int host1x_dma_configure(struct device *dev)
 {
if (dev->of_node)
-   return of_dma_configure(dev, dev->of_node);
+   return of_dma_configure(dev, dev->of_node, true);
 
return 0;
 }
@@ -336,7 +336,6 @@ struct bus_type host1x_bus_type = {
.match = host1x_device_match,
.dma_configure  = host1x_dma_configure,
.pm = _device_pm_ops,
-   .force_dma = true,
 };
 
 static void 

[PATCH 01/10] drm/sun4i: Disable frontend video channel before enabling a layer

[Paul Kocialkowski]

This adds a dedicated function for disabling the layer video channel
from the frontend to the backend. It is called automatically on an
atomic update, as to disable the frontend by default (it will be enabled
later on in the atomic update if necessary).

It fixes an issue when enabling a layer that uses the frontend (e.g. for
scaling) and then reusing the same layer without the frontend. Since the
video channel to the frontend was never disabled, the backend was still
trying to get data from there.

Signed-off-by: Paul Kocialkowski 
---
 drivers/gpu/drm/sun4i/sun4i_backend.c | 8 
 drivers/gpu/drm/sun4i/sun4i_backend.h | 2 ++
 drivers/gpu/drm/sun4i/sun4i_layer.c   | 2 ++
 3 files changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index 7e647044cbed..e07a33adc51d 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -395,6 +395,14 @@ int sun4i_backend_update_layer_zpos(struct sun4i_backend 
*backend, int layer,
return 0;
 }
 
+void sun4i_backend_disable_layer_frontend(struct sun4i_backend *backend,
+ int layer)
+{
+   regmap_update_bits(backend->engine.regs,
+  SUN4I_BACKEND_ATTCTL_REG0(layer),
+  SUN4I_BACKEND_ATTCTL_REG0_LAY_VDOEN, 0);
+}
+
 static bool sun4i_backend_plane_uses_scaler(struct drm_plane_state *state)
 {
u16 src_h = state->src_h >> 16;
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.h 
b/drivers/gpu/drm/sun4i/sun4i_backend.h
index 316f2179e9e1..7ae0f0ffec8c 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.h
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.h
@@ -204,5 +204,7 @@ int sun4i_backend_update_layer_frontend(struct 
sun4i_backend *backend,
int layer, uint32_t in_fmt);
 int sun4i_backend_update_layer_zpos(struct sun4i_backend *backend,
int layer, struct drm_plane *plane);
+void sun4i_backend_disable_layer_frontend(struct sun4i_backend *backend,
+ int layer);
 
 #endif /* _SUN4I_BACKEND_H_ */
diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.c 
b/drivers/gpu/drm/sun4i/sun4i_layer.c
index 2949a3c912c1..224bb1811e0a 100644
--- a/drivers/gpu/drm/sun4i/sun4i_layer.c
+++ b/drivers/gpu/drm/sun4i/sun4i_layer.c
@@ -93,6 +93,8 @@ static void sun4i_backend_layer_atomic_update(struct 
drm_plane *plane,
struct sun4i_backend *backend = layer->backend;
struct sun4i_frontend *frontend = backend->frontend;
 
+   sun4i_backend_disable_layer_frontend(backend, layer->id);
+
if (layer_state->uses_frontend) {
sun4i_frontend_init(frontend);
sun4i_frontend_update_coord(frontend, plane);
-- 
2.16.2

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

[PATCH 09/10] drm/sun4i: Add a dedicated ioctl call for allocating tiled buffers

[Paul Kocialkowski]

This introduces a dedicated ioctl for allocating tiled buffers in the
Allwinner MB32 format, that comes with a handful of specific
constraints. In particular, the stride of the buffers is expected to be
aligned to 32 bytes.

Signed-off-by: Paul Kocialkowski 
---
 drivers/gpu/drm/sun4i/sun4i_drv.c | 96 +++
 drivers/gpu/drm/sun4i/sun4i_drv.h |  2 +
 include/uapi/drm/sun4i_drm.h  | 42 +
 3 files changed, 140 insertions(+)
 create mode 100644 include/uapi/drm/sun4i_drm.h

diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index d374bb61c565..e9cb03d34b44 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -21,11 +21,18 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "sun4i_drv.h"
 #include "sun4i_frontend.h"
 #include "sun4i_framebuffer.h"
 #include "sun4i_tcon.h"
+#include "sun4i_format.h"
+
+static const struct drm_ioctl_desc sun4i_drv_ioctls[] = {
+   DRM_IOCTL_DEF_DRV(SUN4I_GEM_CREATE_TILED, drm_sun4i_gem_create_tiled,
+ DRM_AUTH | DRM_RENDER_ALLOW),
+};
 
 DEFINE_DRM_GEM_CMA_FOPS(sun4i_drv_fops);
 
@@ -34,6 +41,8 @@ static struct drm_driver sun4i_drv_driver = {
 
/* Generic Operations */
.lastclose  = drm_fb_helper_lastclose,
+   .ioctls = sun4i_drv_ioctls,
+   .num_ioctls = ARRAY_SIZE(sun4i_drv_ioctls),
.fops   = _drv_fops,
.name   = "sun4i-drm",
.desc   = "Allwinner sun4i Display Engine",
@@ -69,6 +78,93 @@ int drm_sun4i_gem_dumb_create(struct drm_file *file_priv,
return drm_gem_cma_dumb_create_internal(file_priv, drm, args);
 }
 
+int drm_sun4i_gem_create_tiled(struct drm_device *drm, void *data,
+  struct drm_file *file_priv)
+{
+   struct drm_sun4i_gem_create_tiled *args = data;
+   struct drm_gem_cma_object *cma_obj;
+   struct drm_gem_object *gem_obj;
+   uint32_t luma_stride, chroma_stride;
+   uint32_t luma_height, chroma_height;
+   int ret;
+
+   if (!sun4i_format_supports_tiling(args->format))
+   return -EINVAL;
+
+   memset(args->pitches, 0, sizeof(args->pitches));
+   memset(args->offsets, 0, sizeof(args->offsets));
+
+   /* Stride and height are aligned to 32 bytes for MB32 tiled format. */
+   luma_stride = ALIGN(args->width, 32);
+   luma_height = ALIGN(args->height, 32);
+
+   if (sun4i_format_is_semiplanar(args->format)) {
+   chroma_stride = luma_stride;
+
+   if (sun4i_format_is_yuv420(args->format))
+   chroma_height = ALIGN(DIV_ROUND_UP(args->height, 2), 
32);
+   else if (sun4i_format_is_yuv422(args->format))
+   chroma_height = luma_height;
+   else
+   return -EINVAL;
+
+   args->pitches[0] = luma_stride;
+   args->pitches[1] = chroma_stride;
+
+   args->offsets[0] = 0;
+   args->offsets[1] = luma_stride * luma_height;
+
+   args->size = luma_stride * luma_height +
+chroma_stride * chroma_height;
+   } else if (sun4i_format_is_planar(args->format)) {
+   if (sun4i_format_is_yuv411(args->format)) {
+   chroma_stride = ALIGN(DIV_ROUND_UP(args->width, 4), 32);
+   chroma_height = luma_height;
+   } if (sun4i_format_is_yuv420(args->format)) {
+   chroma_stride = ALIGN(DIV_ROUND_UP(args->width, 2), 32);
+   chroma_height = ALIGN(DIV_ROUND_UP(args->height, 2), 
32);
+   } else if (sun4i_format_is_yuv422(args->format)) {
+   chroma_stride = ALIGN(DIV_ROUND_UP(args->width, 2), 32);
+   chroma_height = luma_height;
+   } else {
+   return -EINVAL;
+   }
+
+   args->pitches[0] = luma_stride;
+   args->pitches[1] = chroma_stride;
+   args->pitches[2] = chroma_stride;
+
+   args->offsets[0] = 0;
+   args->offsets[1] = luma_stride * luma_height;
+   args->offsets[2] = luma_stride * luma_height +
+  chroma_stride * chroma_height;
+
+   args->size = luma_stride * luma_height +
+chroma_stride * chroma_height * 2;
+   } else {
+   /* No support for packed formats in tiled mode. */
+   return -EINVAL;
+   }
+
+   cma_obj = drm_gem_cma_create(drm, args->size);
+   if (IS_ERR(cma_obj))
+   return PTR_ERR(cma_obj);
+
+   gem_obj = _obj->base;
+
+   /*
+* allocate a id of idr table where the obj is registered
+* and handle has the id what user can see.
+*/
+  

Re: [PATCHv2 1/8] drm/omap: add framedone interrupt support

[Tony Lindgren]

* Sebastian Reichel  [180208 18:31]:
> This prepares framedone interrupt handling for
> manual display update support.
> 
> Signed-off-by: Sebastian Reichel 

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

[PATCH DRM] drm: Remove drm_property_{un/reference}_blob aliases

[Haneen Mohammed]

This patch remove the compatibility aliases
drm_property_{reference/unreference}_blob of
drm_property_blob_{get/put} since all callers have been converted to the
prefered _{get/put}.

Remove the helpers from the semantic patch drm-get-put-cocci.

Signed-off-by: Haneen Mohammed 
---
 include/drm/drm_property.h   | 26 --
 scripts/coccinelle/api/drm-get-put.cocci | 10 --
 2 files changed, 36 deletions(-)

diff --git a/include/drm/drm_property.h b/include/drm/drm_property.h
index 8a522b4..08d5dbb 100644
--- a/include/drm/drm_property.h
+++ b/include/drm/drm_property.h
@@ -279,32 +279,6 @@ struct drm_property_blob *drm_property_blob_get(struct 
drm_property_blob *blob);
 void drm_property_blob_put(struct drm_property_blob *blob);
 
 /**
- * drm_property_reference_blob - acquire a blob property reference
- * @blob: DRM blob property
- *
- * This is a compatibility alias for drm_property_blob_get() and should not be
- * used by new code.
- */
-static inline struct drm_property_blob *
-drm_property_reference_blob(struct drm_property_blob *blob)
-{
-   return drm_property_blob_get(blob);
-}
-
-/**
- * drm_property_unreference_blob - release a blob property reference
- * @blob: DRM blob property
- *
- * This is a compatibility alias for drm_property_blob_put() and should not be
- * used by new code.
- */
-static inline void
-drm_property_unreference_blob(struct drm_property_blob *blob)
-{
-   drm_property_blob_put(blob);
-}
-
-/**
  * drm_property_find - find property object
  * @dev: DRM device
  * @file_priv: drm file to check for lease against.
diff --git a/scripts/coccinelle/api/drm-get-put.cocci 
b/scripts/coccinelle/api/drm-get-put.cocci
index ceb71ea..3a09c97 100644
--- a/scripts/coccinelle/api/drm-get-put.cocci
+++ b/scripts/coccinelle/api/drm-get-put.cocci
@@ -40,12 +40,6 @@ expression object;
 - drm_gem_object_unreference_unlocked(object)
 + drm_gem_object_put_unlocked(object)
 |
-- drm_property_reference_blob(object)
-+ drm_property_blob_get(object)
-|
-- drm_property_unreference_blob(object)
-+ drm_property_blob_put(object)
-|
 - drm_dev_unref(object)
 + drm_dev_put(object)
 )
@@ -72,10 +66,6 @@ __drm_gem_object_unreference(object)
 |
 drm_gem_object_unreference_unlocked(object)
 |
-drm_property_unreference_blob@p(object)
-|
-drm_property_reference_blob@p(object)
-|
 drm_dev_unref@p(object)
 )
 
-- 
2.7.4

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

Re: [PATCHv2 0/8] omapdrm: DSI command mode panel support

[Tony Lindgren]

Tomi,

* Sebastian Reichel  [180208 10:31]:
> Hi,
> 
> These are the remaining patches from my previous patchset to get
> Droid 4 (omap4) display working. The patches have been rebased to
> current master branch from Torvalds (581e400ff935). Since N950
> (omap3) is broken even with the workaround I moved it to the end,
> so that it can be skipped.

Seems like the first three patches of these could be applied
for v4.17 separate from the rotation and omap3 related issues?

Regards,

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

[PATCH 4/4] GPU: drm: Fixed Coding issue

[Paul McQuade]

code indent should use tabs where possible

Signed-off-by: Paul McQuade 
---
 drivers/gpu/drm/drm_bufs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index 8e345ba16858..ba8cfe65c65b 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -1446,8 +1446,8 @@ int drm_legacy_freebufs(struct drm_device *dev, void 
*data,
 int __drm_legacy_mapbufs(struct drm_device *dev, void *data, int *p,
 void __user **v,
 int (*f)(void *, int, unsigned long,
- struct drm_buf *),
-struct drm_file *file_priv)
+struct drm_buf *),
+struct drm_file *file_priv)
 {
struct drm_device_dma *dma = dev->dma;
int retcode = 0;
-- 
2.16.2

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

Re: [PATCHv2 3/8] drm/omap: add support for manually updated displays

[Tony Lindgren]

* Sebastian Reichel  [180208 18:31]:
> This adds the required infrastructure for manually
> updated displays, such as DSI command mode panels.
> 
> While those panels often support partial updates
> we currently always do a full refresh. Display
> will be refreshed when something calls the dirty
> callback, such as libdrm's drmModeDirtyFB().
> 
> This is currently being implemented for the kernel
> console and for Xorg. Weston currently does not
> implement this and is known not to work on manually
> updated displays.

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

[PATCH 03/10] drm/sun4i: Don't pretend to handle ARGB8888 with the frontend

[Paul Kocialkowski]

It turns out that the frontend is not capable of preserving the alpha
component (that is always set to 0xff), so only support XRGB
instead.

Signed-off-by: Paul Kocialkowski 
---
 drivers/gpu/drm/sun4i/sun4i_backend.c  | 4 
 drivers/gpu/drm/sun4i/sun4i_frontend.c | 3 +--
 drivers/gpu/drm/sun4i/sun4i_layer.c| 4 ++--
 3 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index b98dafda52f8..274a1db6fa8e 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -440,6 +440,10 @@ static bool sun4i_backend_plane_uses_frontend(struct 
drm_plane_state *state)
if (IS_ERR(backend->frontend))
return false;
 
+   /*
+* TODO: Don't use the frontend for x2/x4 scaling and allow RGB formats
+* with an alpha component then.
+*/
return sun4i_backend_plane_uses_scaler(state);
 }
 
diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c 
b/drivers/gpu/drm/sun4i/sun4i_frontend.c
index ddf6cfa6dd23..3ea925584891 100644
--- a/drivers/gpu/drm/sun4i/sun4i_frontend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c
@@ -107,7 +107,7 @@ EXPORT_SYMBOL(sun4i_frontend_update_buffer);
 static int sun4i_frontend_drm_format_to_input_fmt(uint32_t fmt, u32 *val)
 {
switch (fmt) {
-   case DRM_FORMAT_ARGB:
+   case DRM_FORMAT_XRGB:
*val = 5;
return 0;
 
@@ -120,7 +120,6 @@ static int sun4i_frontend_drm_format_to_output_fmt(uint32_t 
fmt, u32 *val)
 {
switch (fmt) {
case DRM_FORMAT_XRGB:
-   case DRM_FORMAT_ARGB:
*val = 2;
return 0;
 
diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.c 
b/drivers/gpu/drm/sun4i/sun4i_layer.c
index eb93df445a10..15238211a61a 100644
--- a/drivers/gpu/drm/sun4i/sun4i_layer.c
+++ b/drivers/gpu/drm/sun4i/sun4i_layer.c
@@ -100,9 +100,9 @@ static void sun4i_backend_layer_atomic_update(struct 
drm_plane *plane,
sun4i_frontend_update_coord(frontend, plane);
sun4i_frontend_update_buffer(frontend, plane);
sun4i_frontend_update_formats(frontend, plane,
- DRM_FORMAT_ARGB);
+ DRM_FORMAT_XRGB);
sun4i_backend_update_layer_frontend(backend, layer->id, plane,
-   DRM_FORMAT_ARGB);
+   DRM_FORMAT_XRGB);
sun4i_frontend_enable(frontend);
} else {
sun4i_backend_update_layer_formats(backend, layer->id, plane);
-- 
2.16.2

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

[PATCH 2/4] GPU: drm: Fixed Spacing issue

[Paul McQuade]

"foo ** bar" should be "foo **bar"

Signed-off-by: Paul McQuade 
---
 drivers/gpu/drm/drm_bufs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index 83b3d0801262..9af9efd84ee7 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -132,7 +132,7 @@ static int drm_map_handle(struct drm_device *dev, struct 
drm_hash_item *hash,
 static int drm_addmap_core(struct drm_device *dev, resource_size_t offset,
   unsigned int size, enum drm_map_type type,
   enum drm_map_flags flags,
-  struct drm_map_list ** maplist)
+  struct drm_map_list **maplist)
 {
struct drm_local_map *map;
struct drm_map_list *list;
-- 
2.16.2

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

RE: [PATCH v2 1/2] dma-mapping: move dma configuration to bus infrastructure

[Bharat Bhushan]

> -Original Message-
> From: Nipun Gupta
> Sent: Wednesday, March 21, 2018 12:25 PM
> To: robin.mur...@arm.com; h...@lst.de; li...@armlinux.org.uk;
> gre...@linuxfoundation.org; m.szyprow...@samsung.com
> Cc: bhelg...@google.com; zaj...@gmail.com; andy.gr...@linaro.org;
> david.br...@linaro.org; dan.j.willi...@intel.com; vinod.k...@intel.com;
> thierry.red...@gmail.com; robh...@kernel.org; frowand.l...@gmail.com;
> jarkko.sakki...@linux.intel.com; rafael.j.wyso...@intel.com;
> dmitry.torok...@gmail.com; jo...@kernel.org; msucha...@suse.de; linux-
> ker...@vger.kernel.org; io...@lists.linux-foundation.org; linux-
> wirel...@vger.kernel.org; linux-arm-...@vger.kernel.org; linux-
> s...@vger.kernel.org; dmaeng...@vger.kernel.org; dri-
> de...@lists.freedesktop.org; linux-te...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-...@vger.kernel.org; Bharat Bhushan
> ; Leo Li ; Nipun Gupta
> 
> Subject: [PATCH v2 1/2] dma-mapping: move dma configuration to bus
> infrastructure
> 
> It's bus specific aspect to map a given device on the bus and relevant 
> firmware
> description of its DMA configuration.
> So, this change introduces '/dma_configure/' as bus callback giving 
> flexibility to
> busses for implementing its own dma configuration function.
> 
> The change eases the addition of new busses w.r.t. adding the dma
> configuration functionality.
> 
> This patch also updates the PCI, Platform, ACPI and host1x bus to use new
> introduced callbacks.
> 
> Suggested-by: Christoph Hellwig 
> Signed-off-by: Nipun Gupta 
> ---
>  - The patches are based on the comments on:
>https://patchwork.kernel.org/patch/10259087/
> 
> Changes in v2:
>   - Do not have dma_deconfigure callback
>   - Have '/dma_common_configure/' API to provide a common DMA
> configuration which can be used by busses if it suits them.
>   - Platform and ACPI bus to use '/dma_common_configure/' in
> '/dma_configure/' callback.
>   - Updated commit message
>   - Updated pci_dma_configure API with changes suggested by Robin
> 
>  drivers/amba/bus.c  |  7 +++
>  drivers/base/dma-mapping.c  | 35 +++
>  drivers/base/platform.c |  6 ++
>  drivers/gpu/host1x/bus.c|  9 +
>  drivers/pci/pci-driver.c| 32 
>  include/linux/device.h  |  4 
>  include/linux/dma-mapping.h |  1 +
>  7 files changed, 74 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c index 594c228..2fa1e8b
> 100644
> --- a/drivers/amba/bus.c
> +++ b/drivers/amba/bus.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #include 
> 
> @@ -171,6 +172,11 @@ static int amba_pm_runtime_resume(struct device
> *dev)  }  #endif /* CONFIG_PM */
> 
> +static int amba_dma_configure(struct device *dev) {
> + return dma_common_configure(dev);
> +}
> +
>  static const struct dev_pm_ops amba_pm = {
>   .suspend= pm_generic_suspend,
>   .resume = pm_generic_resume,
> @@ -194,6 +200,7 @@ struct bus_type amba_bustype = {
>   .dev_groups = amba_dev_groups,
>   .match  = amba_match,
>   .uevent = amba_uevent,
> + .dma_configure  = amba_dma_configure,
>   .pm = _pm,
>   .force_dma  = true,
>  };
> diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c index
> 3b11835..48f9af0 100644
> --- a/drivers/base/dma-mapping.c
> +++ b/drivers/base/dma-mapping.c
> @@ -331,38 +331,33 @@ void dma_common_free_remap(void *cpu_addr,
> size_t size, unsigned long vm_flags)  #endif
> 
>  /*
> - * Common configuration to enable DMA API use for a device
> + * Common configuration to enable DMA API use for a device.
> + * A bus can use this function in its 'dma_configure' callback, if
> + * suitable for the bus.
>   */
> -#include 
> -
> -int dma_configure(struct device *dev)
> +int dma_common_configure(struct device *dev)
>  {
> - struct device *bridge = NULL, *dma_dev = dev;
>   enum dev_dma_attr attr;
>   int ret = 0;
> 
> - if (dev_is_pci(dev)) {
> - bridge = pci_get_host_bridge_device(to_pci_dev(dev));
> - dma_dev = bridge;
> - if (IS_ENABLED(CONFIG_OF) && dma_dev->parent &&
> - dma_dev->parent->of_node)
> - dma_dev = dma_dev->parent;
> - }
> -
> - if (dma_dev->of_node) {
> - ret = of_dma_configure(dev, dma_dev->of_node);
> - } else if (has_acpi_companion(dma_dev)) {
> - attr = acpi_get_dma_attr(to_acpi_device_node(dma_dev-
> >fwnode));
> + if (dev->of_node) {
> + ret = of_dma_configure(dev, dev->of_node);
> + } else if (has_acpi_companion(dev)) {
> + attr = acpi_get_dma_attr(to_acpi_device_node(dev->fwnode));
>   if (attr != DEV_DMA_NOT_SUPPORTED)
>   ret 

[PATCH 04/10] drm/sun4i: Explicitly list and check formats supported by the backend

[Paul Kocialkowski]

In order to check whether the backend supports a specific format, an
explicit list and a related helper are introduced.

They are then used to determine whether the frontend should be used for
a layer, when the format is not supported by the backend.

Signed-off-by: Paul Kocialkowski 
---
 drivers/gpu/drm/sun4i/sun4i_backend.c | 48 ++-
 drivers/gpu/drm/sun4i/sun4i_backend.h |  1 +
 2 files changed, 48 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index 274a1db6fa8e..7703ba989743 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -172,6 +172,39 @@ static int sun4i_backend_drm_format_to_layer(u32 format, 
u32 *mode)
return 0;
 }
 
+static const uint32_t sun4i_backend_formats[] = {
+   /* RGB */
+   DRM_FORMAT_ARGB,
+   DRM_FORMAT_RGBA,
+   DRM_FORMAT_ARGB1555,
+   DRM_FORMAT_RGBA5551,
+   DRM_FORMAT_RGB565,
+   DRM_FORMAT_RGB888,
+   DRM_FORMAT_XRGB,
+   DRM_FORMAT_BGRX,
+   DRM_FORMAT_ARGB,
+   /* YUV422 */
+   DRM_FORMAT_YUYV,
+   DRM_FORMAT_YVYU,
+   DRM_FORMAT_UYVY,
+   DRM_FORMAT_VYUY,
+};
+
+bool sun4i_backend_format_is_supported(uint32_t fmt)
+{
+   bool found = false;
+   unsigned int i;
+
+   for (i = 0; i < ARRAY_SIZE(sun4i_backend_formats); i++) {
+   if (sun4i_backend_formats[i] == fmt) {
+   found = true;
+   break;
+   }
+   }
+
+   return found;
+}
+
 int sun4i_backend_update_layer_coord(struct sun4i_backend *backend,
 int layer, struct drm_plane *plane)
 {
@@ -436,15 +469,28 @@ static bool sun4i_backend_plane_uses_frontend(struct 
drm_plane_state *state)
 {
struct sun4i_layer *layer = plane_to_sun4i_layer(state->plane);
struct sun4i_backend *backend = layer->backend;
+   struct drm_framebuffer *fb = state->fb;
 
if (IS_ERR(backend->frontend))
return false;
 
+   /*
+* Let's pretend that every format is either supported by the backend or
+* the frontend. This is not true in practice, as some tiling modes are
+* not supported by either. There is still room to check this later in
+* the atomic check process.
+*/
+   if (!sun4i_backend_format_is_supported(fb->format->format))
+   return true;
+
/*
 * TODO: Don't use the frontend for x2/x4 scaling and allow RGB formats
 * with an alpha component then.
 */
-   return sun4i_backend_plane_uses_scaler(state);
+   if (sun4i_backend_plane_uses_scaler(state))
+   return true;
+
+   return false;
 }
 
 static void sun4i_backend_atomic_begin(struct sunxi_engine *engine,
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.h 
b/drivers/gpu/drm/sun4i/sun4i_backend.h
index cb6df2b690c0..a7bfc38f12bd 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.h
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.h
@@ -207,5 +207,6 @@ int sun4i_backend_update_layer_zpos(struct sun4i_backend 
*backend,
int layer, struct drm_plane *plane);
 void sun4i_backend_disable_layer_frontend(struct sun4i_backend *backend,
  int layer);
+bool sun4i_backend_format_is_supported(uint32_t fmt);
 
 #endif /* _SUN4I_BACKEND_H_ */
-- 
2.16.2

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

[PATCH -next] drm/meson: Fix potential NULL dereference in meson_drv_bind_master()

[Wei Yongjun]

platform_get_resource_byname() may fail and return NULL, so we should
better check it's return value to avoid a NULL pointer dereference
a bit later in the code.

This is detected by Coccinelle semantic patch.

@@
expression pdev, res, n, t, e, e1, e2;
@@

res = platform_get_resource_byname(pdev, t, n);
+ if (!res)
+   return -EINVAL;
... when != res == NULL
e = devm_ioremap(e1, res->start, e2);

Signed-off-by: Wei Yongjun 
---
 drivers/gpu/drm/meson/meson_drv.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/meson/meson_drv.c 
b/drivers/gpu/drm/meson/meson_drv.c
index 3baceb7..32b1a6c 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -197,6 +197,8 @@ static int meson_drv_bind_master(struct device *dev, bool 
has_components)
priv->io_base = regs;
 
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "hhi");
+   if (!res)
+   return -EINVAL;
/* Simply ioremap since it may be a shared register zone */
regs = devm_ioremap(dev, res->start, resource_size(res));
if (!regs) {
@@ -213,6 +215,8 @@ static int meson_drv_bind_master(struct device *dev, bool 
has_components)
}
 
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dmc");
+   if (!res)
+   return -EINVAL;
/* Simply ioremap since it may be a shared register zone */
regs = devm_ioremap(dev, res->start, resource_size(res));
if (!regs) {

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

RE: [PATCH v2 1/2] dma-mapping: move dma configuration to bus infrastructure

[Nipun Gupta]

> -Original Message-
> From: Bharat Bhushan
> Sent: Wednesday, March 21, 2018 12:49

> >
> > +int dma_configure(struct device *dev)
> > +{
> > +   if (dev->bus->dma_configure)
> > +   return dev->bus->dma_configure(dev);
> 
> What if dma_common_configure() is called in case "bus->dma_configure" is
> not defined?
> 
> Thanks
> -Bharat

I think it is cleaner for bus to call '/dma_common_configure/' rather
than this been called implicitly, but Robin/Christoph can comment
better on this.

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

[PATCH] drm/i915/gvt/scheduler: fix potential NULL pointer dereference

[Gustavo A. R. Silva]

_workload_ is being dereferenced before it is null checked, hence
there is a potential null pointer dereference.

Fix this by moving the pointer dereference after _workload_ has
been null checked.

Addresses-Coverity-ID: 1430136 ("Dereference before null check")
Fixes: fa3dd623e559 ("drm/i915/gvt: keep oa config in shadow ctx")
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/gpu/drm/i915/gvt/scheduler.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
b/drivers/gpu/drm/i915/gvt/scheduler.c
index 0681264..be1a297 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -60,9 +60,9 @@ static void set_context_pdp_root_pointer(
 static void sr_oa_regs(struct intel_vgpu_workload *workload,
u32 *reg_state, bool save)
 {
-   struct drm_i915_private *dev_priv = workload->vgpu->gvt->dev_priv;
-   u32 ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
-   u32 ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
+   struct drm_i915_private *dev_priv;
+   u32 ctx_oactxctrl;
+   u32 ctx_flexeu0;
int i = 0;
u32 flex_mmio[] = {
i915_mmio_reg_offset(EU_PERF_CNTL0),
@@ -77,6 +77,10 @@ static void sr_oa_regs(struct intel_vgpu_workload *workload,
if (!workload || !reg_state || workload->ring_id != RCS)
return;
 
+   dev_priv = workload->vgpu->gvt->dev_priv;
+   ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
+   ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
+
if (save) {
workload->oactxctrl = reg_state[ctx_oactxctrl + 1];
 
-- 
2.7.4

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

Re: [PATCH v3] drm/xen-front: Add support for Xen PV display frontend

[Boris Ostrovsky]

On 03/21/2018 10:58 AM, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

Add support for Xen para-virtualized frontend display driver.
Accompanying backend [1] is implemented as a user-space application
and its helper library [2], capable of running as a Weston client
or DRM master.
Configuration of both backend and frontend is done via
Xen guest domain configuration options [3].



I won't claim that I really understand what's going on here as far as 
DRM stuff is concerned but I didn't see any obvious issues with Xen bits.


So for that you can tack on my
Reviewed-by: Boris Ostrovsky 

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

Re: [v2 PATCH 0/2] arm64: dts: Add sdm845 GPU/GMU and SMMU

[Viresh Kumar]

On 16-03-18, 12:51, Jordan Crouse wrote:
> (resend because I forgot to CC everybody on the patches)
> 
> Add DT nodes for the sdm845 GPU/GMU (graphics management unit) and the 
> companion
> arm-smmu-v2 compatible SMMU.
> 
> This builds on the following dependencies -
> https://patchwork.kernel.org/patch/10286369/ - bindings for qcom,level
> https://patchwork.kernel.org/patch/10281599/ - qcom,smmu-v2 bindings
> 
> Please refer to https://patchwork.freedesktop.org/series/37428/ for the driver
> code.
> 
> [v2 - changed qcom,arc-level to qcom,level following discussion with Viresh;
> change gmu phandle to qcom,gmu per Rob]
> 
> Jordan Crouse (2):
>   dt-bindings: Document qcom,adreno-gmu
>   arm64: dts: sdm845: Add gpu and gmu device nodes

Acked-by: Viresh Kumar 

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

[PATCH 08/10] drm/fourcc: Add definitions for Allwinner vendor and MB32 tiled format

[Paul Kocialkowski]

This introduces specific definitions for vendor Allwinner and its
specific MB32 tiled format, an NV12-based format with 32x32 tiles.

This format is the default output format used by the VPU on most
Allwinner platforms.

Signed-off-by: Paul Kocialkowski 
---
 include/uapi/drm/drm_fourcc.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index e04613d30a13..1b7ef9102582 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -183,6 +183,7 @@ extern "C" {
 #define DRM_FORMAT_MOD_VENDOR_QCOM0x05
 #define DRM_FORMAT_MOD_VENDOR_VIVANTE 0x06
 #define DRM_FORMAT_MOD_VENDOR_BROADCOM 0x07
+#define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x08
 /* add more to the end as needed */
 
 #define DRM_FORMAT_RESERVED  ((1ULL << 56) - 1)
@@ -405,6 +406,15 @@ extern "C" {
  */
 #define DRM_FORMAT_MOD_BROADCOM_VC4_T_TILED fourcc_mod_code(BROADCOM, 1)
 
+/*
+ * Allwinner "MB32" tiled format
+ *
+ * This is the primary layout coming out of the VPU, where pixels are tiled
+ * 32x32.
+ */
+#define DRM_FORMAT_MOD_ALLWINNER_MB32_TILED fourcc_mod_code(ALLWINNER, 1)
+
+
 #if defined(__cplusplus)
 }
 #endif
-- 
2.16.2

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

Re: [PATCHv2 6/7] cec-pin-error-inj.rst: document CEC Pin Error Injection

[Mauro Carvalho Chehab]

Em Mon,  5 Mar 2018 14:51:38 +0100
Hans Verkuil  escreveu:

> From: Hans Verkuil 
> 
> The CEC Pin framework adds support for Error Injection.
> 
> Document all the error injections commands and how to use it.

Please notice that all debugfs/sysfs entries should *also* be
documented at the standard way, e. g. by adding the corresponding
documentation at Documentation/ABI.

Please see Documentation/ABI/README.

Additionally, there are a few minor nitpicks on this patch.
See below.

The remaining patches looked ok on my eyes.

I'll wait for a v3 with the debugfs ABI documentation in order to merge
it. Feel free to put it on a separate patch.

Regards,
Mauro

> 
> Signed-off-by: Hans Verkuil 
> ---
>  .../media/cec-drivers/cec-pin-error-inj.rst| 322 
> +
>  Documentation/media/cec-drivers/index.rst  |   1 +
>  MAINTAINERS|   1 +
>  3 files changed, 324 insertions(+)
>  create mode 100644 Documentation/media/cec-drivers/cec-pin-error-inj.rst
> 
> diff --git a/Documentation/media/cec-drivers/cec-pin-error-inj.rst 
> b/Documentation/media/cec-drivers/cec-pin-error-inj.rst
> new file mode 100644
> index ..21bda831d3fb
> --- /dev/null
> +++ b/Documentation/media/cec-drivers/cec-pin-error-inj.rst
> @@ -0,0 +1,322 @@
> +CEC Pin Framework Error Injection
> +=
> +
> +The CEC Pin Framework is a core CEC framework for CEC hardware that only
> +has low-level support for the CEC bus. Most hardware today will have
> +high-level CEC support where the hardware deals with driving the CEC bus,
> +but some older devices aren't that fancy. However, this framework also
> +allows you to connect the CEC pin to a GPIO on e.g. a Raspberry Pi and
> +you can become an instant CEC adapter.
> +
> +What makes doing this so interesting is that since we have full control
> +over the bus it is easy to support error injection. This is ideal to
> +test how well CEC adapters can handle error conditions.
> +
> +Currently only the cec-gpio driver (when the CEC line is directly
> +connected to a pull-up GPIO line) and the AllWinner A10/A20 drm driver
> +support this framework.
> +
> +If ``CONFIG_CEC_PIN_ERROR_INJ`` is enabled, then error injection is available
> +through debugfs. Specifically, in ``/sys/kernel/debug/cec/cecX/`` there is
> +now an ``error-inj`` file.
> +
> +With ``cat error-inj`` you can see both the possible commands and the current
> +error injection status:
> +
> +.. code-block:: none

It is usually better to use "::" instead of ".. code-block".

> +
> + $ cat /sys/kernel/debug/cec/cec0/error-inj
> + # Clear error injections:
> + #   clear  clear all rx and tx error injections
> + #   rx-clear   clear all rx error injections
> + #   tx-clear   clear all tx error injections
> + #clear clear all rx and tx error injections for 
> + #rx-clear  clear all rx error injections for 
> + #tx-clear  clear all tx error injections for 
> + #
> + # RX error injection:
> + #   [,] rx-nack  NACK the message instead of 
> sending an ACK
> + #   [,] rx-low-driveforce a low-drive condition at 
> this bit position
> + #   [,] rx-add-byte  add a spurious byte to the 
> received CEC message
> + #   [,] rx-remove-byte   remove the last byte from the 
> received CEC message
> + #   [,] rx-arb-lostgenerate a POLL message to 
> trigger an arbitration lost
> + #
> + # TX error injection settings:
> + #   tx-ignore-nack-until-eom   ignore early NACKs until EOM
> + #   tx-custom-low-usecs define the 'low' time for the 
> custom pulse
> + #   tx-custom-high-usecsdefine the 'high' time for the 
> custom pulse
> + #   tx-custom-pulsetransmit the custom pulse once 
> the bus is idle
> + #
> + # TX error injection:
> + #   [,] tx-no-eomdon't set the EOM bit
> + #   [,] tx-early-eom set the EOM bit one byte too soon
> + #   [,] tx-add-bytesappend  (1-255) spurious 
> bytes to the message
> + #   [,] tx-remove-byte   drop the last byte from the 
> message
> + #   [,] tx-short-bitmake this bit shorter than 
> allowed
> + #   [,] tx-long-bit make this bit longer than allowed
> + #   [,] tx-custom-bit   send the custom pulse instead of 
> this bit
> + #   [,] tx-short-start   send a start pulse that's too 
> short
> + #   [,] tx-long-startsend a start pulse that's too 
> long
> + #   [,] tx-custom-start  send the custom pulse instead of 
> the start pulse
> + #   [,] tx-last-bit stop sending after this bit
> + #   [,] tx-low-driveforce a low-drive condition at 
> this bit position
> + #
> + #CEC message opcode (0-255) or 'any'
> + #  'once' (default), 

RE: [PATCH v2 1/2] dma-mapping: move dma configuration to bus infrastructure

[Nipun Gupta]

> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Wednesday, March 21, 2018 15:00



> > +int dma_configure(struct device *dev)
> > +{
> > +   if (dev->bus->dma_configure)
> > +   return dev->bus->dma_configure(dev);
> > +
> > +   return 0;
> > +}
> >  void dma_deconfigure(struct device *dev)
> 
> Empty line after this new function?  Sorry, couldn't help it :)
> 
> >  {
> > of_dma_deconfigure(dev);
> > diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> > index f1bf7b3..d2d5891 100644
> > --- a/drivers/base/platform.c
> > +++ b/drivers/base/platform.c
> > @@ -1130,6 +1130,11 @@ int platform_pm_restore(struct device *dev)
> >
> >  #endif /* CONFIG_HIBERNATE_CALLBACKS */
> >



> > +
> > const struct dev_pm_ops *pm;
> >
> > const struct iommu_ops *iommu_ops;
> > diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> > index eb9eab4..c15986b 100644
> > --- a/include/linux/dma-mapping.h
> > +++ b/include/linux/dma-mapping.h
> > @@ -761,6 +761,7 @@ void *dma_mark_declared_memory_occupied(struct
> device *dev,
> >  }
> >  #endif /* CONFIG_HAVE_GENERIC_DMA_COHERENT */
> >
> > +int dma_common_configure(struct device *dev);
> >  #ifdef CONFIG_HAS_DMA
> 
> Blank line after the new function declaration?
> 
> Other than those very minor things, nice job, this looks good:
> 
> Reviewed-by: Greg Kroah-Hartman 

Thank you for the review :). I will fix your comments in next version.

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

[PATCH v2] drm/tegra: dc: use correct format array for Tegra124.

[Marcel Ziswiler]

From: Stefan Agner 

Use tegra124_(primary|overlay)_formats for Tegra124.

Fixes: 511c7023cf23 ("drm/tegra: dc: Support more formats")

Signed-off-by: Stefan Agner 
Acked-by: Marcel Ziswiler 

---

Changes in v2:
- re-based on top of today's next
- added my ACK

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

diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 71152776b04c..e0ea5a46ecc9 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -2015,9 +2015,9 @@ static const struct tegra_dc_soc_info 
tegra124_dc_soc_info = {
.coupled_pm = false,
.has_nvdisplay = false,
.num_primary_formats = ARRAY_SIZE(tegra124_primary_formats),
-   .primary_formats = tegra114_primary_formats,
+   .primary_formats = tegra124_primary_formats,
.num_overlay_formats = ARRAY_SIZE(tegra124_overlay_formats),
-   .overlay_formats = tegra114_overlay_formats,
+   .overlay_formats = tegra124_overlay_formats,
.modifiers = tegra124_modifiers,
 };
 
-- 
2.14.3

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

[PATCH] drm/i915/gvt: Mark expected switch fall-through in handle_g2v_notification

[Gustavo A. R. Silva]

In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.

Addresses-Coverity-ID: 1466154 ("Missing break in switch")
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/gpu/drm/i915/gvt/handlers.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/gvt/handlers.c 
b/drivers/gpu/drm/i915/gvt/handlers.c
index 8c5d5d0..a33c1c3e 100644
--- a/drivers/gpu/drm/i915/gvt/handlers.c
+++ b/drivers/gpu/drm/i915/gvt/handlers.c
@@ -1150,6 +1150,7 @@ static int handle_g2v_notification(struct intel_vgpu 
*vgpu, int notification)
switch (notification) {
case VGT_G2V_PPGTT_L3_PAGE_TABLE_CREATE:
root_entry_type = GTT_TYPE_PPGTT_ROOT_L3_ENTRY;
+   /* fall through */
case VGT_G2V_PPGTT_L4_PAGE_TABLE_CREATE:
mm = intel_vgpu_get_ppgtt_mm(vgpu, root_entry_type, pdps);
return PTR_ERR_OR_ZERO(mm);
-- 
2.7.4

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

[PATCH 3/4] GPU: drm: Fixed Spacing issue

[Paul McQuade]

space prohibited after that open parenthesis '('

Signed-off-by: Paul McQuade 
---
 drivers/gpu/drm/drm_bufs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index 9af9efd84ee7..8e345ba16858 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -224,7 +224,7 @@ static int drm_addmap_core(struct drm_device *dev, 
resource_size_t offset,
case _DRM_SHM:
list = drm_find_matching_map(dev, map);
if (list != NULL) {
-   if(list->map->size != map->size) {
+   if (list->map->size != map->size) {
DRM_DEBUG("Matching maps of type %d with "
  "mismatched sizes, (%ld vs %ld)\n",
  map->type, map->size, 
list->map->size);
-- 
2.16.2

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

[PATCH 1/2] drm/sun4i: hdmi: Fix an error handling path in 'sun4i_hdmi_bind()'

[Christophe JAILLET]

If we can not allocate the HDMI encoder regmap, we still need to free some
resources before returning.

Fixes: 4b1c924b1fc1 ("drm/sun4i: hdmi: create a regmap for later use")
Signed-off-by: Christophe JAILLET 
---
 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c 
b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
index 500b6fb3e028..d2839727bb0b 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
@@ -538,7 +538,8 @@ static int sun4i_hdmi_bind(struct device *dev, struct 
device *master,
 _hdmi_regmap_config);
if (IS_ERR(hdmi->regmap)) {
dev_err(dev, "Couldn't create HDMI encoder regmap\n");
-   return PTR_ERR(hdmi->regmap);
+   ret = PTR_ERR(hdmi->regmap);
+   goto err_disable_mod_clk;
}
 
ret = sun4i_tmds_create(hdmi);
-- 
2.14.1

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

[PATCH DRM] drm: remove drm_mode_object_{un/reference} aliases

[Haneen Mohammed]

This patch remove the compatibility aliases
drm_mode_object_{reference/unreference} of drm_mode_object_{get/put}
since all callers have been converted to the prefered _{get/put}.

Remove the helpers from the semantic patch drm-get-put-cocci.

Signed-off-by: Haneen Mohammed 
---
 include/drm/drm_mode_object.h| 24 
 scripts/coccinelle/api/drm-get-put.cocci | 10 --
 2 files changed, 34 deletions(-)

diff --git a/include/drm/drm_mode_object.h b/include/drm/drm_mode_object.h
index 7ba3913..c34a3e8 100644
--- a/include/drm/drm_mode_object.h
+++ b/include/drm/drm_mode_object.h
@@ -120,30 +120,6 @@ struct drm_mode_object *drm_mode_object_find(struct 
drm_device *dev,
 void drm_mode_object_get(struct drm_mode_object *obj);
 void drm_mode_object_put(struct drm_mode_object *obj);
 
-/**
- * drm_mode_object_reference - acquire a mode object reference
- * @obj: DRM mode object
- *
- * This is a compatibility alias for drm_mode_object_get() and should not be
- * used by new code.
- */
-static inline void drm_mode_object_reference(struct drm_mode_object *obj)
-{
-   drm_mode_object_get(obj);
-}
-
-/**
- * drm_mode_object_unreference - release a mode object reference
- * @obj: DRM mode object
- *
- * This is a compatibility alias for drm_mode_object_put() and should not be
- * used by new code.
- */
-static inline void drm_mode_object_unreference(struct drm_mode_object *obj)
-{
-   drm_mode_object_put(obj);
-}
-
 int drm_object_property_set_value(struct drm_mode_object *obj,
  struct drm_property *property,
  uint64_t val);
diff --git a/scripts/coccinelle/api/drm-get-put.cocci 
b/scripts/coccinelle/api/drm-get-put.cocci
index 91fceb8..ceb71ea 100644
--- a/scripts/coccinelle/api/drm-get-put.cocci
+++ b/scripts/coccinelle/api/drm-get-put.cocci
@@ -16,12 +16,6 @@ expression object;
 @@
 
 (
-- drm_mode_object_reference(object)
-+ drm_mode_object_get(object)
-|
-- drm_mode_object_unreference(object)
-+ drm_mode_object_put(object)
-|
 - drm_connector_reference(object)
 + drm_connector_get(object)
 |
@@ -62,10 +56,6 @@ position p;
 @@
 
 (
-drm_mode_object_unreference@p(object)
-|
-drm_mode_object_reference@p(object)
-|
 drm_connector_unreference@p(object)
 |
 drm_connector_reference@p(object)
-- 
2.7.4

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

Re: [PATCH] drm/i915/gvt/scheduler: fix potential NULL pointer dereference

[Gustavo A. R. Silva]

On 03/19/2018 04:23 PM, Chris Wilson wrote:

Quoting Gustavo A. R. Silva (2018-03-19 20:50:12)

Hi Chris,

On 03/19/2018 03:38 PM, Chris Wilson wrote:

Quoting Gustavo A. R. Silva (2018-03-19 19:30:53)

_workload_ is being dereferenced before it is null checked, hence
there is a potential null pointer dereference.

Fix this by moving the pointer dereference after _workload_ has
been null checked.


The checks are misleading and not required.


All of them?

if (!workload || !reg_state || workload->ring_id != RCS)
 return;


workload can not be NULL (dereference in caller), reg_state can not be
NULL (by construct from kmap()).

It may be not an RCS ring through


I got it.

I'll send the following patch then:

--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -74,7 +74,7 @@ static void sr_oa_regs(struct intel_vgpu_workload 
*workload,

i915_mmio_reg_offset(EU_PERF_CNTL6),
};

-   if (!workload || !reg_state || workload->ring_id != RCS)
+   if(workload->ring_id != RCS)
return;

if (save) {


Thanks
--
Gustavo






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

Re: [PATCH] drm/i915/gvt/scheduler: Remove unnecessary NULL checks in sr_oa_regs

[Chris Wilson]

Quoting Gustavo A. R. Silva (2018-03-22 18:21:54)
> The checks are misleading and not required [1].
> 
> [1] https://lkml.org/lkml/2018/3/19/1792
> 
> Addresses-Coverity-ID: 1466017
> Cc: Chris Wilson 
> Signed-off-by: Gustavo A. R. Silva 
Reviewed-by: Chris Wilson 

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

[PATCH v6] ARM: dts: wheat: Fix ADV7513 address usage

[Kieran Bingham]

The r8a7792 Wheat board has two ADV7513 devices sharing a single I2C
bus, however in low power mode the ADV7513 will reset it's slave maps to
use the hardware defined default addresses.

The ADV7511 driver was adapted to allow the two devices to be registered
correctly - but it did not take into account the fault whereby the
devices reset the addresses.

This results in an address conflict between the device using the default
addresses, and the other device if it is in low-power-mode.

Repair this issue by moving both devices away from the default address
definitions.

Signed-off-by: Kieran Bingham 
Reviewed-by: Laurent Pinchart 
---
v2:
 - Addition to series

v3:
 - Split map register addresses into individual declarations.

v4:
 - Normalise I2C usage

v5:
 - Repost without [RFT] now that it has been tested

v6:
 - s/low power power/low power/ correction from Laurent.

Testing on a wheat board shows the addresses correctly assigned, and the
default addresses (0x38, 0x3e, 0x3f which would otherwise conflict) are
shown as actively returning data in low power mode during the scan.
(they return 0)

 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:  -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- UU -- -- -- UU -- --
30: -- -- -- -- -- -- -- -- 38 UU -- -- -- UU 3e 3f
40: -- -- -- -- -- -- -- -- -- UU -- -- -- UU -- --
50: -- -- -- -- -- -- -- -- -- UU -- -- -- UU -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

 arch/arm/boot/dts/r8a7792-wheat.dts | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7792-wheat.dts 
b/arch/arm/boot/dts/r8a7792-wheat.dts
index 293b9e3b3e70..db01de7a3811 100644
--- a/arch/arm/boot/dts/r8a7792-wheat.dts
+++ b/arch/arm/boot/dts/r8a7792-wheat.dts
@@ -245,9 +245,15 @@
status = "okay";
clock-frequency = <40>;
 
+   /*
+* The adv75xx resets its addresses to defaults during low power mode.
+* Because we have two ADV7513 devices on the same bus, we must change
+* both of them away from the defaults so that they do not conflict.
+*/
hdmi@3d {
compatible = "adi,adv7513";
-   reg = <0x3d>;
+   reg = <0x3d>, <0x2d>, <0x4d>, <0x5d>;
+   reg-names = "main", "cec", "edid", "packet";
 
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
@@ -277,7 +283,8 @@
 
hdmi@39 {
compatible = "adi,adv7513";
-   reg = <0x39>;
+   reg = <0x39>, <0x29>, <0x49>, <0x59>;
+   reg-names = "main", "cec", "edid", "packet";
 
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
-- 
2.7.4

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

[PATCH v5] ARM: dts: wheat: Fix ADV7513 address usage

[Kieran Bingham]

The r8a7792 Wheat board has two ADV7513 devices sharing a single I2C
bus, however in low power mode the ADV7513 will reset it's slave maps to
use the hardware defined default addresses.

The ADV7511 driver was adapted to allow the two devices to be registered
correctly - but it did not take into account the fault whereby the
devices reset the addresses.

This results in an address conflict between the device using the default
addresses, and the other device if it is in low-power-mode.

Repair this issue by moving both devices away from the default address
definitions.

Signed-off-by: Kieran Bingham 
Reviewed-by: Laurent Pinchart 
---
v2:
 - Addition to series

v3:
 - Split map register addresses into individual declarations.

v4:
 - Normalise I2C usage

v5:
 - No change from v4 except to repost and drop the [RFT] now that it's tested


Testing on a wheat board shows the addresses correctly assigned, and the
default addresses (0x38, 0x3e, 0x3f which would otherwise conflict) are
shown as actively returning data in low power mode during the scan.
(they return 0)

 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:  -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- UU -- -- -- UU -- --
30: -- -- -- -- -- -- -- -- 38 UU -- -- -- UU 3e 3f
40: -- -- -- -- -- -- -- -- -- UU -- -- -- UU -- --
50: -- -- -- -- -- -- -- -- -- UU -- -- -- UU -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
---
 arch/arm/boot/dts/r8a7792-wheat.dts | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7792-wheat.dts 
b/arch/arm/boot/dts/r8a7792-wheat.dts
index 293b9e3b3e70..3e9f70e87a60 100644
--- a/arch/arm/boot/dts/r8a7792-wheat.dts
+++ b/arch/arm/boot/dts/r8a7792-wheat.dts
@@ -245,9 +245,16 @@
status = "okay";
clock-frequency = <40>;
 
+   /*
+* The adv75xx resets its addresses to defaults during low power power
+* mode. Because we have two ADV7513 devices on the same bus, we must
+* change both of them away from the defaults so that they do not
+* conflict.
+*/
hdmi@3d {
compatible = "adi,adv7513";
-   reg = <0x3d>;
+   reg = <0x3d>, <0x2d>, <0x4d>, <0x5d>;
+   reg-names = "main", "cec", "edid", "packet";
 
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
@@ -277,7 +284,8 @@
 
hdmi@39 {
compatible = "adi,adv7513";
-   reg = <0x39>;
+   reg = <0x39>, <0x29>, <0x49>, <0x59>;
+   reg-names = "main", "cec", "edid", "packet";
 
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
-- 
2.7.4

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

[PATCH 2/2] drm/tinydrm: Make fb_dirty into a lower level hook

[Ville Syrjala]

From: Ville Syrjälä 

mipi_dbi_enable_flush() wants to call the fb->dirty() hook from the
bowels of the .atomic_enable() hook. That prevents us from taking the
plane mutex in fb->dirty() unless we also plumb down the acquire
context.

Instead it seems simpler to split the fb->dirty() into a tinydrm
specific lower level hook that can be called from
mipi_dbi_enable_flush() and from a generic higher level
tinydrm_fb_dirty() helper. As we don't have a tinydrm specific
vfuncs table we'll just stick it into tinydrm_device directly
for now.

Cc: "Noralf Trønnes" 
Cc: David Lechner 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 30 ++
 drivers/gpu/drm/tinydrm/ili9225.c  | 23 ++--
 drivers/gpu/drm/tinydrm/mi0283qt.c |  2 +-
 drivers/gpu/drm/tinydrm/mipi-dbi.c | 30 ++
 drivers/gpu/drm/tinydrm/repaper.c  | 28 
 drivers/gpu/drm/tinydrm/st7586.c   | 23 ++--
 drivers/gpu/drm/tinydrm/st7735r.c  |  2 +-
 include/drm/tinydrm/mipi-dbi.h |  4 +++-
 include/drm/tinydrm/tinydrm-helpers.h  |  5 +
 include/drm/tinydrm/tinydrm.h  |  4 
 10 files changed, 76 insertions(+), 75 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
index d1c3ce9ab294..dcd390163a4a 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
@@ -78,6 +78,36 @@ bool tinydrm_merge_clips(struct drm_clip_rect *dst,
 }
 EXPORT_SYMBOL(tinydrm_merge_clips);
 
+int tinydrm_fb_dirty(struct drm_framebuffer *fb,
+struct drm_file *file_priv,
+unsigned int flags, unsigned int color,
+struct drm_clip_rect *clips,
+unsigned int num_clips)
+{
+   struct tinydrm_device *tdev = fb->dev->dev_private;
+   struct drm_plane *plane = >pipe.plane;
+   int ret = 0;
+
+   drm_modeset_lock(>mutex, NULL);
+
+   /* fbdev can flush even when we're not interested */
+   if (plane->state->fb == fb) {
+   mutex_lock(>dirty_lock);
+   ret = tdev->fb_dirty(fb, file_priv, flags,
+color, clips, num_clips);
+   mutex_unlock(>dirty_lock);
+   }
+
+   drm_modeset_unlock(>mutex);
+
+   if (ret)
+   dev_err_once(fb->dev->dev,
+"Failed to update display %d\n", ret);
+
+   return ret;
+}
+EXPORT_SYMBOL(tinydrm_fb_dirty);
+
 /**
  * tinydrm_memcpy - Copy clip buffer
  * @dst: Destination buffer
diff --git a/drivers/gpu/drm/tinydrm/ili9225.c 
b/drivers/gpu/drm/tinydrm/ili9225.c
index 089d22798c8b..0874e877b111 100644
--- a/drivers/gpu/drm/tinydrm/ili9225.c
+++ b/drivers/gpu/drm/tinydrm/ili9225.c
@@ -88,14 +88,8 @@ static int ili9225_fb_dirty(struct drm_framebuffer *fb,
bool full;
void *tr;
 
-   mutex_lock(>dirty_lock);
-
if (!mipi->enabled)
-   goto out_unlock;
-
-   /* fbdev can flush even when we're not interested */
-   if (tdev->pipe.plane.fb != fb)
-   goto out_unlock;
+   return 0;
 
full = tinydrm_merge_clips(, clips, num_clips, flags,
   fb->width, fb->height);
@@ -108,7 +102,7 @@ static int ili9225_fb_dirty(struct drm_framebuffer *fb,
tr = mipi->tx_buf;
ret = mipi_dbi_buf_copy(mipi->tx_buf, fb, , swap);
if (ret)
-   goto out_unlock;
+   return ret;
} else {
tr = cma_obj->vaddr;
}
@@ -159,20 +153,13 @@ static int ili9225_fb_dirty(struct drm_framebuffer *fb,
ret = mipi_dbi_command_buf(mipi, ILI9225_WRITE_DATA_TO_GRAM, tr,
(clip.x2 - clip.x1) * (clip.y2 - clip.y1) * 2);
 
-out_unlock:
-   mutex_unlock(>dirty_lock);
-
-   if (ret)
-   dev_err_once(fb->dev->dev, "Failed to update display %d\n",
-ret);
-
return ret;
 }
 
 static const struct drm_framebuffer_funcs ili9225_fb_funcs = {
.destroy= drm_gem_fb_destroy,
.create_handle  = drm_gem_fb_create_handle,
-   .dirty  = ili9225_fb_dirty,
+   .dirty  = tinydrm_fb_dirty,
 };
 
 static void ili9225_pipe_enable(struct drm_simple_display_pipe *pipe,
@@ -269,7 +256,7 @@ static void ili9225_pipe_enable(struct 
drm_simple_display_pipe *pipe,
 
ili9225_command(mipi, ILI9225_DISPLAY_CONTROL_1, 0x1017);
 
-   mipi_dbi_enable_flush(mipi);
+   mipi_dbi_enable_flush(mipi, crtc_state, plane_state);
 }
 
 static void ili9225_pipe_disable(struct drm_simple_display_pipe 

[PATCH 1/2] drm/simple-kms-helper: Plumb plane state to the enable hook

[Ville Syrjala]

From: Ville Syrjälä 

We'll need access to the plane state during .atomic_enable().

Performed with coccinelle:
@r1@
identifier F =~ ".*enable$";
identifier P, CS;
@@
F(
struct drm_simple_display_pipe *P
,struct drm_crtc_state *CS
+   ,struct drm_plane_state *plane_state
)
{
...
}

@@
struct drm_simple_display_pipe *P;
expression E;
@@
{
+ struct drm_plane *plane;
...
+ plane = >plane;
P->funcs->enable(P
,E
+   ,plane->state
);
...
}

@@
identifier P, CS;
@@
struct drm_simple_display_pipe_funcs {
...
void (*enable)(struct drm_simple_display_pipe *P
,struct drm_crtc_state *CS
+   ,struct drm_plane_state *plane_state
);
...
};

Cc: Marek Vasut 
Cc: Eric Anholt 
Cc: David Lechner 
Cc: "Noralf Trønnes" 
Cc: Linus Walleij 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_simple_kms_helper.c | 4 +++-
 drivers/gpu/drm/mxsfb/mxsfb_drv.c   | 3 ++-
 drivers/gpu/drm/pl111/pl111_display.c   | 3 ++-
 drivers/gpu/drm/tinydrm/ili9225.c   | 3 ++-
 drivers/gpu/drm/tinydrm/mi0283qt.c  | 3 ++-
 drivers/gpu/drm/tinydrm/repaper.c   | 3 ++-
 drivers/gpu/drm/tinydrm/st7586.c| 3 ++-
 drivers/gpu/drm/tinydrm/st7735r.c   | 3 ++-
 drivers/gpu/drm/tve200/tve200_display.c | 3 ++-
 include/drm/drm_simple_kms_helper.h | 3 ++-
 10 files changed, 21 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
b/drivers/gpu/drm/drm_simple_kms_helper.c
index 987a353c7f72..7a00455ca568 100644
--- a/drivers/gpu/drm/drm_simple_kms_helper.c
+++ b/drivers/gpu/drm/drm_simple_kms_helper.c
@@ -64,13 +64,15 @@ static int drm_simple_kms_crtc_check(struct drm_crtc *crtc,
 static void drm_simple_kms_crtc_enable(struct drm_crtc *crtc,
   struct drm_crtc_state *old_state)
 {
+   struct drm_plane *plane;
struct drm_simple_display_pipe *pipe;
 
pipe = container_of(crtc, struct drm_simple_display_pipe, crtc);
if (!pipe->funcs || !pipe->funcs->enable)
return;
 
-   pipe->funcs->enable(pipe, crtc->state);
+   plane = >plane;
+   pipe->funcs->enable(pipe, crtc->state, plane->state);
 }
 
 static void drm_simple_kms_crtc_disable(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c 
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index 5cae8db9dcd4..b9c7507813db 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -99,7 +99,8 @@ static const struct drm_mode_config_funcs 
mxsfb_mode_config_funcs = {
 };
 
 static void mxsfb_pipe_enable(struct drm_simple_display_pipe *pipe,
- struct drm_crtc_state *crtc_state)
+ struct drm_crtc_state *crtc_state,
+ struct drm_plane_state *plane_state)
 {
struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
 
diff --git a/drivers/gpu/drm/pl111/pl111_display.c 
b/drivers/gpu/drm/pl111/pl111_display.c
index 310646427907..1fee578e05b0 100644
--- a/drivers/gpu/drm/pl111/pl111_display.c
+++ b/drivers/gpu/drm/pl111/pl111_display.c
@@ -120,7 +120,8 @@ static int pl111_display_check(struct 
drm_simple_display_pipe *pipe,
 }
 
 static void pl111_display_enable(struct drm_simple_display_pipe *pipe,
-struct drm_crtc_state *cstate)
+struct drm_crtc_state *cstate,
+struct drm_plane_state *plane_state)
 {
struct drm_crtc *crtc = >crtc;
struct drm_plane *plane = >plane;
diff --git a/drivers/gpu/drm/tinydrm/ili9225.c 
b/drivers/gpu/drm/tinydrm/ili9225.c
index a0759502b81a..089d22798c8b 100644
--- a/drivers/gpu/drm/tinydrm/ili9225.c
+++ b/drivers/gpu/drm/tinydrm/ili9225.c
@@ -176,7 +176,8 @@ static const struct drm_framebuffer_funcs ili9225_fb_funcs 
= {
 };
 
 static void ili9225_pipe_enable(struct drm_simple_display_pipe *pipe,
-   struct drm_crtc_state *crtc_state)
+   struct drm_crtc_state *crtc_state,
+   struct drm_plane_state *plane_state)
 {
struct tinydrm_device *tdev = pipe_to_tinydrm(pipe);
struct mipi_dbi *mipi = mipi_dbi_from_tinydrm(tdev);
diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c 
b/drivers/gpu/drm/tinydrm/mi0283qt.c
index d8ed6e6f8e05..82ad9b61898e 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
@@ -49,7 +49,8 @@
 #define ILI9341_MADCTL_MY  BIT(7)
 
 static void mi0283qt_enable(struct drm_simple_display_pipe *pipe,
-   struct drm_crtc_state *crtc_state)
+   struct drm_crtc_state *crtc_state,
+   struct 

[Bug 105697] gcc -static-libgcc -static-libstdc++ support is broken by libtool for dri drivers

[bugzilla-daemon]

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

Bug ID: 105697
   Summary: gcc -static-libgcc -static-libstdc++ support is broken
by libtool for dri drivers
   Product: Mesa
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: sylvain.bertr...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

When building mesa with gcc -static-libgcc -static-libstdc++ options, I noticed
that
libtool is linking in a weird way the dri drivers (gallium and mesa), hence
making them dependent on the shared libstdc++.
I did work around it by hiding the shared libstdc++ while I was building mesa.

-- 
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 2/2] drm: Add DP last received PSR SDP VSC register and bits

[José Roberto de Souza]

This is a register to help debug what is in the last SDP VSC
packet revived by sink.

Signed-off-by: José Roberto de Souza 
---
 include/drm/drm_dp_helper.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 0bac0c7d0dec..91c9bcd4196f 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -795,6 +795,15 @@
 # define DP_LAST_ACTUAL_SYNCHRONIZATION_LATENCY_MASK   (0xf << 4)
 # define DP_LAST_ACTUAL_SYNCHRONIZATION_LATENCY_SHIFT  4
 
+#define DP_LAST_RECEIVED_PSR_SDP   0x200a /* eDP 1.2 */
+# define DP_PSR_STATE_BIT  (1 << 0) /* eDP 1.2 */
+# define DP_UPDATE_RFB_BIT (1 << 1) /* eDP 1.2 */
+# define DP_CRC_VALID_BIT  (1 << 2) /* eDP 1.2 */
+# define DP_SU_VALID   (1 << 3) /* eDP 1.4 */
+# define DP_FIRST_SCAN_LINE_SU_REGION  (1 << 4) /* eDP 1.4 */
+# define DP_LAST_SCAN_LINE_SU_REGION   (1 << 5) /* eDP 1.4 */
+# define DP_Y_COORDINATE_VALID (1 << 6) /* eDP 1.4a */
+
 #define DP_RECEIVER_ALPM_STATUS0x200b  /* eDP 1.4 */
 # define DP_ALPM_LOCK_TIMEOUT_ERROR(1 << 0)
 
-- 
2.16.2

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

[PATCH 1/2] drm: Add DP PSR2 sink enable bit

[José Roberto de Souza]

To comply with eDP1.4a this bit should be set when enabling PSR2.

Signed-off-by: José Roberto de Souza 
---
 include/drm/drm_dp_helper.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 62903bae0221..0bac0c7d0dec 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -478,6 +478,7 @@
 # define DP_PSR_FRAME_CAPTURE  (1 << 3)
 # define DP_PSR_SELECTIVE_UPDATE   (1 << 4)
 # define DP_PSR_IRQ_HPD_WITH_CRC_ERRORS (1 << 5)
+# define DP_PSR_ENABLE_PSR2(1 << 6) /* eDP 1.4a */
 
 #define DP_ADAPTER_CTRL0x1a0
 # define DP_ADAPTER_CTRL_FORCE_LOAD_SENSE   (1 << 0)
-- 
2.16.2

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

[PULL] drm-misc-fixes

[Gustavo Padovan]

Hi Dave,

A few fixes for 4.16. Main thing here is getting getfb to reject
multiplanar fbs. I should have sent some of these before but conference
and traveling got in the way.

Thanks,

Gustavo

drm-misc-fixes-2018-03-22:
Main change is a patch to reject getfb call for multiplanar framebuffers,
then we have a couple of error path fixes on the sun4i driver. Still on that
driver there is a clk fix and finally a mmap offset fix on the udl driver.
The following changes since commit b0655d668fc4faf0c1985e828820f9b9ca13abe6:

  Merge branch 'drm-fixes-4.16' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes (2018-03-09 09:23:02 +1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2018-03-22

for you to fetch changes up to 3b82a4db8eaccce735dffd50b4d4e1578099b8e8:

  drm: udl: Properly check framebuffer mmap offsets (2018-03-22 07:59:01 +0100)


Main change is a patch to reject getfb call for multiplanar framebuffers,
then we have a couple of error path fixes on the sun4i driver. Still on that
driver there is a clk fix and finally a mmap offset fix on the udl driver.


Christophe JAILLET (3):
  drm/sun4i: Fix an error handling path in 'sun4i_drv_bind()'
  drm/sun4i: hdmi: Fix an error handling path in 'sun4i_hdmi_bind()'
  drm/sun4i: hdmi: Fix another error handling path in 'sun4i_hdmi_bind()'

Daniel Stone (1):
  drm: Reject getfb for multi-plane framebuffers

Greg Kroah-Hartman (1):
  drm: udl: Properly check framebuffer mmap offsets

Ondrej Jirman (1):
  drm/sun4i: Fix exclusivity of the TCON clocks

 drivers/gpu/drm/drm_framebuffer.c  | 7 +++
 drivers/gpu/drm/sun4i/sun4i_drv.c  | 3 +--
 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 6 --
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 5 +++--
 drivers/gpu/drm/udl/udl_fb.c   | 9 +++--
 5 files changed, 22 insertions(+), 8 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 00/23] drm: Eliminate plane->fb/crtc usage for atomic drivers

[Ville Syrjälä]

On Thu, Mar 22, 2018 at 05:51:35PM +0100, Noralf Trønnes wrote:
> tinydrm is also using plane->fb:
> 
> $ grep -r "plane\.fb" drivers/gpu/drm/tinydrm/
> drivers/gpu/drm/tinydrm/repaper.c:  if (tdev->pipe.plane.fb != fb)
> drivers/gpu/drm/tinydrm/mipi-dbi.c: if (tdev->pipe.plane.fb != fb)
> drivers/gpu/drm/tinydrm/mipi-dbi.c: struct drm_framebuffer *fb = 
> mipi->tinydrm.pipe.plane.fb;

Oh dear, and naturally it's the most annoying one of the bunch. So we
want to take the plane lock in the fb.dirty() hook to look at the fb,
but mipi-dbi.c calls that directly from the bowels of its
.atomic_enable() hook. So that would deadlock pretty neatly if the
commit happens while already holding the lock.

So we'd either need to plumb an acquire context into fb.dirty(),
or maybe have tinydrm provide a lower level lockless dirty() hook
that gets called by both (there are just too many layers in this
particular cake to immediately see where such a hook would be best
placed). Or maybe there's some other solution I didn't think of.

Looking at this I'm also left wondering how this is supposed
handle fb.dirty() getting called concurrently with a modeset.
The dirty_mutex only seems to offer any protection for
fb.dirty() against another fb.dirty()...

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

Re: [PATCH 00/23] drm: Eliminate plane->fb/crtc usage for atomic drivers

[Emil Velikov]

On 22 March 2018 at 18:03, Harry Wentland  wrote:
> On 2018-03-22 01:54 PM, Emil Velikov wrote:
>> Hi Ville,
>>
>> On 22 March 2018 at 15:22, Ville Syrjala  
>> wrote:
>>> From: Ville Syrjälä 
>>>
>>> I really just wanted to fix i915 to re-enable its planes afer load
>>> detection (a two line patch). This is what I actually ended up with
>>> after I ran into a framebuffer refcount leak with said two line patch.
>>>
>>> I've tested this on a few i915 boxes and so far it's looking
>>> good. Everything else is just compile tested.
>>>
>> Mostly thinking out loud:
>>
>> Wondering if one cannot somehow (re)move plane->fb/crtc altogether.
>> Otherwise drivers will reintroduce similar code, despite the WARNs and
>> beefy documentation :-\
>
> Wouldn't that require an atomic conversion of all remaining drivers?
>
That or maybe move into plane->legacy->{fb,crtc}. Feel free to swap
'legacy' with flashier name.

Hmm back in 2015 we had a GSoC that updated BOCHS and CIRRUS drivers,
but they never got merged.
Don't recall the details - from memory the conversion seemed fine, but
there was either shortage on review/other.

Might be worth reviving that... regardless it's getting a bit off-topic.
-Emil

[1] 
https://www.google-melange.com/archive/gsoc/2015/orgs/xorg/projects/johnhunter.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Maxime Ripard]

On Wed, Mar 21, 2018 at 09:03:13PM +0100, Giulio Benetti wrote:
> The A20-Linova1-7 HMI, also called Q027_2_F which is printed on production
> label, is an industrial Human Machine Interface.
> It features:
> - 512MB DDR RAM
> - 1 Sd-card >= 4GB
> - 1 Usb otg(programmable via software) with A-Usb Connector
> - 1 Usb host
> - 1 Buzzer
> - 1 Input for LiPo
> - 1 Relay to signal absence of power supply
> - 1 External Rtc with 56 bytes of ram + CR2032 battery
> - 1 7" 24-bits Tft 800x480 with PCap on
> - 1 Mono audio 1-watt amplifier
> - 1 RS485 port
> - 1 Power On Line through +12Vdc reaching 57.600baud,
>   from where it can be supplied and placed in a network of 50 units
> - exposed jtag pins
> 
> HMI is supplied from +12Vdc.
> Ethernet is absent, so for debugging, need to enable rndis on Usb otg
> port through an A-A usb cable.
> It comes in different flavours for connector types and can be found with
> umounted features as requested by customers.

So this is essentially the same board than in patch 6, but with a
different screen?

You should have a single DT then, and handle the two different panels
using DT overlays.

> Signed-off-by: Giulio Benetti 
> ---
>  .../devicetree/bindings/arm/micronova.txt  |   4 +
>  arch/arm/boot/dts/Makefile |   1 +
>  arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts | 192 
> +
>  3 files changed, 197 insertions(+)
>  create mode 100644 arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts
> 
> diff --git a/Documentation/devicetree/bindings/arm/micronova.txt 
> b/Documentation/devicetree/bindings/arm/micronova.txt
> index 35c4127..9f5ac72 100644
> --- a/Documentation/devicetree/bindings/arm/micronova.txt
> +++ b/Documentation/devicetree/bindings/arm/micronova.txt
> @@ -4,3 +4,7 @@ Micronova Device Tree Bindings
>  A20-LiNova1-4_3 HMI
>  Required root node properties:
>  - compatible = "micronova,a20-linova1-ctp-4_3i", "allwinner,sun7i-a20";
> +
> +A20-LiNova1-7 HMI
> +Required root node properties:
> +- compatible = "micronova,a20-linova1-ctp-7i", "allwinner,sun7i-a20";

These bindings are unnecessary, but the panel-simple bindings should
be sent to the DT maintainers as well.

> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index c45a4f25..eafa7cb 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -942,6 +942,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
>   sun7i-a20-m3.dtb \
>   sun7i-a20-mk808c.dtb \
>   sun7i-a20-linova1-ctp-4_3i.dtb\
> + sun7i-a20-linova1-ctp-7i.dtb\

You should have a space after dtb, and it should be ordered
alphabetically.

>   sun7i-a20-olimex-som-evb.dtb \
>   sun7i-a20-olinuxino-lime.dtb \
>   sun7i-a20-olinuxino-lime2.dtb \
> diff --git a/arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts 
> b/arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts
> new file mode 100644
> index 000..7fd0d98
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts
> @@ -0,0 +1,192 @@
> +/*
> + * This is based on sun7i-a20-linova1-ctp-7i.dts
> + *
> + * Copyright 2014 - Hans de Goede 
> + * Copyright (c) 2014 FUKAUMI Naoki 
> + * Copyright (c) 2018 Giulio Benetti 
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file 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.
> + *
> + * This file 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.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A 

Re: [PATCH v4.5 1/8] cgroup: Allow registration and lookup of cgroup private data (v3)

[Chris Wilson]

Quoting Matt Roper (2018-03-21 23:23:37)
> There are cases where other parts of the kernel may wish to store data
> associated with individual cgroups without building a full cgroup
> controller.  Let's add interfaces to allow them to register and lookup
> this private data for individual cgroups.
> 
> A kernel system (e.g., a driver) that wishes to register private data
> for a cgroup should start by obtaining a unique private data key by
> calling cgroup_priv_getkey().  It may then associate private data
> with a cgroup by calling cgroup_priv_install(cgrp, key, ref) where 'ref'
> is a pointer to a kref field inside the private data structure.  The
> private data may later be looked up by calling cgroup_priv_get(cgrp,
> key) to obtain a new reference to the private data.  Private data may be
> unregistered via cgroup_priv_release(cgrp, key).
> 
> If a cgroup is removed, the reference count for all private data objects
> will be decremented.
> 
> v2:  Significant overhaul suggested by Tejun, Alexei, and Roman
>  - Rework interface to make consumers obtain an ida-based key rather
>than supplying their own arbitrary void*
>  - Internal implementation now uses per-cgroup radixtrees which should
>allow much faster lookup than the previous hashtable approach
>  - Private data is registered via kref, allowing a single private data
>structure to potentially be assigned to multiple cgroups.
> 
> v3:
>  - Spare warning fixes (kbuild test robot)
> 
> Cc: Tejun Heo 
> Cc: Alexei Starovoitov 
> Cc: Roman Gushchin 
> Cc: cgro...@vger.kernel.org
> Signed-off-by: Matt Roper 
> 
> fixup! cgroup: Allow registration and lookup of cgroup private data (v2)
> ---
>  include/linux/cgroup-defs.h |  10 +++
>  include/linux/cgroup.h  |   7 ++
>  kernel/cgroup/cgroup.c  | 183 
> +++-
>  3 files changed, 198 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/cgroup-defs.h b/include/linux/cgroup-defs.h
> index 9f242b876fde..9086d963cc0a 100644
> --- a/include/linux/cgroup-defs.h
> +++ b/include/linux/cgroup-defs.h
> @@ -427,6 +427,16 @@ struct cgroup {
> /* used to store eBPF programs */
> struct cgroup_bpf bpf;
>  
> +   /*
> +* cgroup private data registered by other non-controller parts of the
> +* kernel.  Insertions are protected by privdata_lock, lookups by
> +* rcu_read_lock().
> +*/
> +   struct radix_tree_root privdata;
> +
> +   /* Protect against concurrent insertions/deletions to privdata */
> +   spinlock_t privdata_lock;
> +
> /* ids of the ancestors at each level including self */
> int ancestor_ids[];
>  };
> diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
> index 473e0c0abb86..63d22dfa00bd 100644
> --- a/include/linux/cgroup.h
> +++ b/include/linux/cgroup.h
> @@ -833,4 +833,11 @@ static inline void put_cgroup_ns(struct cgroup_namespace 
> *ns)
> free_cgroup_ns(ns);
>  }
>  
> +/* cgroup private data handling */
> +int cgroup_priv_getkey(void (*free)(struct kref *));
> +void cgroup_priv_destroykey(int key);
> +int cgroup_priv_install(struct cgroup *cgrp, int key, struct kref *ref);
> +struct kref *cgroup_priv_get(struct cgroup *cgrp, int key);
> +void cgroup_priv_release(struct cgroup *cgrp, int key);
> +
>  #endif /* _LINUX_CGROUP_H */
> diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
> index 8cda3bc3ae22..3268a21e8158 100644
> --- a/kernel/cgroup/cgroup.c
> +++ b/kernel/cgroup/cgroup.c
> @@ -81,8 +81,15 @@ EXPORT_SYMBOL_GPL(css_set_lock);
>  #endif
>  
>  /*
> - * Protects cgroup_idr and css_idr so that IDs can be released without
> - * grabbing cgroup_mutex.
> + * ID allocator for cgroup private data keys; the ID's allocated here will
> + * be used to index all per-cgroup radix trees.  The radix tree built into
> + * the IDR itself will store a key-specific function to be passed to 
> kref_put.
> + */
> +static DEFINE_IDR(cgroup_priv_idr);

Fun two radixtrees, one to hold the (*free)() and the other the void*.

Would not just a
struct cgroup_privdata {
struct rcu_head rcu;
void (*free)(struct kref *);
}
suffice for subclassing? (Also this is a prime candidate for switching
to XArray.)

> +struct kref *
> +cgroup_priv_get(struct cgroup *cgrp, int key)
> +{
> +   struct kref *ref;
> +
> +   WARN_ON(cgrp->root != _dfl_root);
> +   WARN_ON(key == 0);
> +
> +   rcu_read_lock();
> +
> +   ref = radix_tree_lookup(>privdata, key);
> +   if (ref)
> +   kref_get(ref);

This is not safe, you need

if (ref && !kref_get_unless_zero(ref))
ref = NULL;

otherwise the cgroup_priv_release() may drop the last reference prior to
you obtaining yours. Also requires the privdata to be RCU protected.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org

Re: [PATCH 00/23] drm: Eliminate plane->fb/crtc usage for atomic drivers

[Harry Wentland]

On 2018-03-22 01:54 PM, Emil Velikov wrote:
> Hi Ville,
> 
> On 22 March 2018 at 15:22, Ville Syrjala  
> wrote:
>> From: Ville Syrjälä 
>>
>> I really just wanted to fix i915 to re-enable its planes afer load
>> detection (a two line patch). This is what I actually ended up with
>> after I ran into a framebuffer refcount leak with said two line patch.
>>
>> I've tested this on a few i915 boxes and so far it's looking
>> good. Everything else is just compile tested.
>>
> Mostly thinking out loud:
> 
> Wondering if one cannot somehow (re)move plane->fb/crtc altogether.
> Otherwise drivers will reintroduce similar code, despite the WARNs and
> beefy documentation :-\

Wouldn't that require an atomic conversion of all remaining drivers?

Harry

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

Re: [PATCH libdrm] xf86drmMode: merge successive mutually-exclusive #ifs

[Emil Velikov]

Reviewed-by: Emil Velikov 

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

Re: [PATCH 00/23] drm: Eliminate plane->fb/crtc usage for atomic drivers

[Emil Velikov]

Hi Ville,

On 22 March 2018 at 15:22, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> I really just wanted to fix i915 to re-enable its planes afer load
> detection (a two line patch). This is what I actually ended up with
> after I ran into a framebuffer refcount leak with said two line patch.
>
> I've tested this on a few i915 boxes and so far it's looking
> good. Everything else is just compile tested.
>
Mostly thinking out loud:

Wondering if one cannot somehow (re)move plane->fb/crtc altogether.
Otherwise drivers will reintroduce similar code, despite the WARNs and
beefy documentation :-\

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

Re: [PATCH 14/23] drm/atmel-hlcdc: Stop using plane->fb

[Ville Syrjälä]

On Thu, Mar 22, 2018 at 05:14:08PM +0100, Maarten Lankhorst wrote:
> Op 22-03-18 om 16:23 schreef Ville Syrjala:
> > From: Ville Syrjälä 
> >
> > We want to get rid of plane->fb on atomic drivers. Stop looking at it.
> >
> > Cc: Boris Brezillon 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 12 +---
> >  1 file changed, 1 insertion(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c 
> > b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> > index e18800ed7cd1..0dd9fb617c28 100644
> > --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> > +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> > @@ -819,16 +819,6 @@ static void atmel_hlcdc_plane_atomic_disable(struct 
> > drm_plane *p,
> > atmel_hlcdc_layer_read_reg(>layer, ATMEL_HLCDC_LAYER_ISR);
> >  }
> >  
> > -static void atmel_hlcdc_plane_destroy(struct drm_plane *p)
> > -{
> > -   struct atmel_hlcdc_plane *plane = drm_plane_to_atmel_hlcdc_plane(p);
> > -
> > -   if (plane->base.fb)
> > -   drm_framebuffer_put(plane->base.fb);
> > -
> > -   drm_plane_cleanup(p);
> > -}
> > -
> >  static int atmel_hlcdc_plane_atomic_set_property(struct drm_plane *p,
> >  struct drm_plane_state *s,
> >  struct drm_property *property,
> > @@ -1038,7 +1028,7 @@ static void 
> > atmel_hlcdc_plane_atomic_destroy_state(struct drm_plane *p,
> >  static const struct drm_plane_funcs layer_plane_funcs = {
> > .update_plane = drm_atomic_helper_update_plane,
> > .disable_plane = drm_atomic_helper_disable_plane,
> > -   .destroy = atmel_hlcdc_plane_destroy,
> > +   .destroy = drm_plane_cleanup,
> > .reset = atmel_hlcdc_plane_reset,
> > .atomic_duplicate_state = atmel_hlcdc_plane_atomic_duplicate_state,
> > .atomic_destroy_state = atmel_hlcdc_plane_atomic_destroy_state,
> 
> This patch should probably be after 'drm: Stop updating plane->crtc/fb/old_fb 
> on atomic drivers'?

Yeah, that does seem like a better order.

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

[PATCH v2 23/23] drm/i915: Make force_load_detect effective even w/ DMI quirks/hotplug

[Ville Syrjala]

From: Ville Syrjälä 

When doing forced load detection testing we should totally ignore any
hotplug status for the connector. This is mostly relevant for machines
where we already ignore the hotplug status based on the DMI quirks. On
other machines we would currently skip the force load detection tests
on account of the connector already being connected.

v2: Drop the other force_load_detect check since it's useless now (Maarten)

Cc: Maarten Lankhorst 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_crt.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index c0a8805b277f..de0e22322c76 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -748,6 +748,11 @@ intel_crt_detect(struct drm_connector *connector,
  connector->base.id, connector->name,
  force);
 
+   if (i915_modparams.load_detect_test) {
+   intel_display_power_get(dev_priv, intel_encoder->power_domain);
+   goto load_detect;
+   }
+
/* Skip machines without VGA that falsely report hotplug events */
if (dmi_check_system(intel_spurious_crt_detect))
return connector_status_disconnected;
@@ -776,11 +781,12 @@ intel_crt_detect(struct drm_connector *connector,
 * broken monitor (without edid) to work behind a broken kvm (that fails
 * to have the right resistors for HP detection) needs to fix this up.
 * For now just bail out. */
-   if (I915_HAS_HOTPLUG(dev_priv) && !i915_modparams.load_detect_test) {
+   if (I915_HAS_HOTPLUG(dev_priv)) {
status = connector_status_disconnected;
goto out;
}
 
+load_detect:
if (!force) {
status = connector->status;
goto out;
-- 
2.16.1

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

[PATCH v2 20/23] drm/virtio: Stop updating plane->crtc

[Ville Syrjala]

From: Ville Syrjälä 

We want to get rid of plane->crtc on atomic drivers. Stop setting it.

v2: s/fb/crtc/ in the commit message (Gerd)

Cc: David Airlie 
Cc: Gerd Hoffmann 
Cc: virtualizat...@lists.linux-foundation.org
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/virtio/virtgpu_display.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c 
b/drivers/gpu/drm/virtio/virtgpu_display.c
index 8cc8c34d67f5..42e842ceb53c 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -302,8 +302,6 @@ static int vgdev_output_init(struct virtio_gpu_device 
*vgdev, int index)
drm_crtc_init_with_planes(dev, crtc, primary, cursor,
  _gpu_crtc_funcs, NULL);
drm_crtc_helper_add(crtc, _gpu_crtc_helper_funcs);
-   primary->crtc = crtc;
-   cursor->crtc = crtc;
 
drm_connector_init(dev, connector, _gpu_connector_funcs,
   DRM_MODE_CONNECTOR_VIRTUAL);
-- 
2.16.1

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

[PATCH v2 13/23] drm/zte: Stop consulting plane->fb

[Ville Syrjala]

From: Ville Syrjälä 

We want to get rid of plane->fb on atomic drivers. Stop looking at it.

v2: Use old_state->crtc (Maarten)

Cc: Shawn Guo 
Cc: Maarten Lankhorst 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/zte/zx_plane.c | 2 +-
 drivers/gpu/drm/zte/zx_vou.c   | 5 +++--
 drivers/gpu/drm/zte/zx_vou.h   | 3 ++-
 3 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/zte/zx_plane.c b/drivers/gpu/drm/zte/zx_plane.c
index 94545adac50d..d1931f5ea0b2 100644
--- a/drivers/gpu/drm/zte/zx_plane.c
+++ b/drivers/gpu/drm/zte/zx_plane.c
@@ -268,7 +268,7 @@ static void zx_plane_atomic_disable(struct drm_plane *plane,
struct zx_plane *zplane = to_zx_plane(plane);
void __iomem *hbsc = zplane->hbsc;
 
-   zx_vou_layer_disable(plane);
+   zx_vou_layer_disable(plane, old_state);
 
/* Disable HBSC block */
zx_writel_mask(hbsc + HBSC_CTRL0, HBSC_CTRL_EN, 0);
diff --git a/drivers/gpu/drm/zte/zx_vou.c b/drivers/gpu/drm/zte/zx_vou.c
index 7491813131f3..442311d31110 100644
--- a/drivers/gpu/drm/zte/zx_vou.c
+++ b/drivers/gpu/drm/zte/zx_vou.c
@@ -627,9 +627,10 @@ void zx_vou_layer_enable(struct drm_plane *plane)
zx_writel_mask(vou->osd + OSD_CTRL0, bits->enable, bits->enable);
 }
 
-void zx_vou_layer_disable(struct drm_plane *plane)
+void zx_vou_layer_disable(struct drm_plane *plane,
+ struct drm_plane_state *old_state)
 {
-   struct zx_crtc *zcrtc = to_zx_crtc(plane->crtc);
+   struct zx_crtc *zcrtc = to_zx_crtc(old_state->crtc);
struct zx_vou_hw *vou = zcrtc->vou;
struct zx_plane *zplane = to_zx_plane(plane);
const struct vou_layer_bits *bits = zplane->bits;
diff --git a/drivers/gpu/drm/zte/zx_vou.h b/drivers/gpu/drm/zte/zx_vou.h
index 97d72bfce982..5b7f84fbb112 100644
--- a/drivers/gpu/drm/zte/zx_vou.h
+++ b/drivers/gpu/drm/zte/zx_vou.h
@@ -62,6 +62,7 @@ void zx_vou_config_dividers(struct drm_crtc *crtc,
struct vou_div_config *configs, int num);
 
 void zx_vou_layer_enable(struct drm_plane *plane);
-void zx_vou_layer_disable(struct drm_plane *plane);
+void zx_vou_layer_disable(struct drm_plane *plane,
+ struct drm_plane_state *old_state);
 
 #endif /* __ZX_VOU_H__ */
-- 
2.16.1

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