date:20150820

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

--- Comment #3 from Andy Furniss  ---
Created attachment 117831
  --> https://bugs.freedesktop.org/attachment.cgi?id=117831=edit
xorg log modesetting aiglx fails

When I say OK for modesetting there are still errors with dri2 and AIGLX falls
back to s/w.

Which makes me a bit confused as to why xonotic-linux64-glx is working OK - in
fact it benchmarks 20% faster than I've seen so far on tonga. I can't be using
llvm with this test - it's set everything as high as it will go and I get 64
fps on the big keybench.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150820/235fa9ac/attachment.html>

[PATCH 3/3] ASoC: AMD: add AMD ASoC ACP-I2S driver [v4]

On Thu, Aug 20, 2015 at 8:10 PM, Mark Brown  wrote:
> On Thu, Aug 20, 2015 at 07:50:34PM -0400, Alex Deucher wrote:
>> On Thu, Aug 20, 2015 at 7:45 PM, Mark Brown  wrote:
>
>> > This is not a DRM driver, it is an ASoC driver, and like I say DRM is a
>> > bit special.  I do note that AMD has contributed at least its CCP and
>> > cpufreq drivers (indeed all their non-DRM code I could find with
>> > explicit license statements) under a normal kernel license.  As far as I
>> > can tell this licensing is entirely confined to the DRM drivers.
>
>> > I am not readily able to convince myself that this is compatible with
>> > the intent of exporting the ASoC APIs _GPL(), this looks like it can be
>> > used as the basis for a shim layer for non-GPL code (the licensing
>> > strategy seems very similar).  I'd need to think through this carefully.
>
>> If you have strong concerns, I can double check with our lawyers and
>> see about changing it, I'm just not sure how long that will take :(
>
> I at the very least need to think about this, it's really important to
> me that we don't want to see proprietary drivers.

That's definitely not our intention.  Historically on the GPU side,
we've preferred the X11/MIT license because it lets other projects
like the BSDs more easily leverage our code.

>
>> The licensing tends to vary based on the teams involved.  The ACP
>> audio and i2s was developed by the GPU teams and we've mostly worked
>> on drm and Xorg stuff until now.
>
> For reference the GPL code in the kernel includes at least:
>
>   drivers/crypto/ccp/ccp-crypto-*.c
>   drivers/cpufreq/powernow-k8.c
>   drivers/pinctrl/pinctrl-amd.c
>
> and there's direct contributions from AMD there AFAICT, not just outside
> developers contributing support for AMD chips.

Right, different teams within AMD.  My team has historically only
worked on GPU stuff and since we contributed to Xorg and the drm we've
been approved to release code under the X11/MIT license.

Alex

about mmap dma-buf and sync

On 08/20/2015 04:53 PM, Jerome Glisse wrote:
> On Thu, Aug 20, 2015 at 08:48:23AM +0200, Thomas Hellstrom wrote:
>> Hi, Tiago!
>>
>> On 08/20/2015 12:33 AM, Tiago Vignatti wrote:
>>> Hey Thomas, you haven't answered my email about making SYNC_* mandatory:
>>>
>>> http://lists.freedesktop.org/archives/dri-devel/2015-August/088376.html
>> Hmm, for some reason it doesn't show up in my mail app, but I found it
>> in the archives. An attempt to explain the situation from the vmwgfx
>> perspective.
>>
>> The fact that the interface is generic means that people will start
>> using it for the zero-copy case. There has been a couple of more or less
>> hackish attempts to do this before, and if it's a _driver_ interface we
>> don't need to be that careful but if it is a _generic_ interface we need
>> to be very careful to make it fit *all* the hardware out there and that
>> we make all potential users use the interface in a way that conforms
>> with the interface specification.
>>
>> What will happen otherwise is that apps written for coherent fast
>> hardware might, for example, ignore calling the SYNC api, just because
>> the app writer only cared about his own hardware on which the app works
>> fine. That would fail miserably if the same app was run on incoherent
>> hardware, or the incoherent hardware driver maintainers would be forced
>> to base an implementation on page-faults which would be very slow.
>>
>> So assume the following use case: An app updates a 10x10 area using the
>> CPU on a 1600x1200 dma-buf, and it will then use the dma-buf for
>> texturing. On some hardware the dma-buf might be tiled in a very
>> specific way, on vmwgfx the dma-buf is a GPU buffer on the host, only
>> accessible using DMA. On vmwgfx the SYNC operation must carry out a
>> 10x10 DMA from the host GPU buffer to a guest CPU buffer before the CPU
>> write and a DMA back again after the write, before GPU usage. On the
>> tiled architecture the SYNC operation must untile before CPU access and
>> probably tile again before GPU access.
>>
>> If we now have a one-dimensional SYNC api, in this particular case we'd
>> either need to sync a far too large area (1600x10) or call SYNC 10 times
>> before writing, and then again after writing. If the app forgot to call
>> SYNC we must error.
>>
>> So to summarize, the fact that the interface is generic IMO means:
>>
>> 1) Any user must be able to make valid assumptions about the internal
>> format of the dma-buf. (untiled, color format, stride etc.)
>> 2) Any user *must* call SYNC before and after CPU access. On coherent
>> architectures, the SYNC is a NULL operation anyway, and that should be
>> documented somewhere so that maintainers of drivers of uncoherent
>> architectures have somewhere to point their fingers.
>> 3) Driver-specific implementations must be allowed to error (segfault)
>> if SYNC has not been used.
> I think here you are too lax, the common code must segfault or
> error badly if SYNC has not been use in all cases even on cache
> coherent arch. The device driver sync callback can still be a
> no operation. But i think that we need to insist strongly on a
> proper sync call being made (and we should forbid empty area
> sync call). This would be the only way to make sure userspace
> behave properly as otherwise we endup in the situation you were
> describing above, where the app is design on a cache coherent
> arch and works fine there but broke in subtle way on non cache
> coherent arch and app developer is clueless of why.
>
> I just do not trust userspace.
I agree and ideally i'd want it this way as well. The question is, is it
possible? Can this be done without a fault() handler in the generic
kernel code?

>
>> 4) The use-case stated above clearly shows the benefit of a
>> 2-dimensional sync interface (we want to sync the 10x10 region), but
>> what if someone in the future wants to use this interface for a 3D
>> texture? Will a 2D sync suffice? Can we make the SYNC interface
>> extendable in a way that an enum sync_type member defines the layout of
>> the argument, and initially we implement only 1d, 2d sync, leaving 3d
>> for the future?
>>
>> Also, I agree there is probably no good way to generically implement an
>> error if SYNC has not been called. That needs to be left as an option to
>> drivers.
> I think there is, just forbid any further use of the dma buffer, mark
> it as invalid and printk a big error. Userspace app developer will
> quickly see that something is wrong and looking at kernel log should
> explain why.

The problem is if someone calls mmap() and then decides to not access
the buffer before munmap() or GPU usage. How do we recognize that case
and separate it from a CPU access occured outside a sync? We could, as
mentioned above have a fault() handler in the generic kernel code and
make sure drivers don't populate PTEs until the first fault(). Another
option would be to scan all PTEs for an "accessed" flag, but I'm not
even sure all CPU architectures

about mmap dma-buf and sync

On 08/20/2015 09:27 PM, Thomas Hellstrom wrote:
> On 08/20/2015 04:33 PM, Rob Clark wrote:
>> On Thu, Aug 20, 2015 at 2:48 AM, Thomas Hellstrom  
>> wrote:
>>> Hi, Tiago!
>>>
>>> On 08/20/2015 12:33 AM, Tiago Vignatti wrote:
 Hey Thomas, you haven't answered my email about making SYNC_* mandatory:

 http://lists.freedesktop.org/archives/dri-devel/2015-August/088376.html
>>> Hmm, for some reason it doesn't show up in my mail app, but I found it
>>> in the archives. An attempt to explain the situation from the vmwgfx
>>> perspective.
>>>
>>> The fact that the interface is generic means that people will start
>>> using it for the zero-copy case. There has been a couple of more or less
>>> hackish attempts to do this before, and if it's a _driver_ interface we
>>> don't need to be that careful but if it is a _generic_ interface we need
>>> to be very careful to make it fit *all* the hardware out there and that
>>> we make all potential users use the interface in a way that conforms
>>> with the interface specification.
>>>
>>> What will happen otherwise is that apps written for coherent fast
>>> hardware might, for example, ignore calling the SYNC api, just because
>>> the app writer only cared about his own hardware on which the app works
>>> fine. That would fail miserably if the same app was run on incoherent
>>> hardware, or the incoherent hardware driver maintainers would be forced
>>> to base an implementation on page-faults which would be very slow.
>>>
>>> So assume the following use case: An app updates a 10x10 area using the
>>> CPU on a 1600x1200 dma-buf, and it will then use the dma-buf for
>>> texturing. On some hardware the dma-buf might be tiled in a very
>>> specific way, on vmwgfx the dma-buf is a GPU buffer on the host, only
>>> accessible using DMA. On vmwgfx the SYNC operation must carry out a
>>> 10x10 DMA from the host GPU buffer to a guest CPU buffer before the CPU
>>> write and a DMA back again after the write, before GPU usage. On the
>>> tiled architecture the SYNC operation must untile before CPU access and
>>> probably tile again before GPU access.
>>>
>>> If we now have a one-dimensional SYNC api, in this particular case we'd
>>> either need to sync a far too large area (1600x10) or call SYNC 10 times
>>> before writing, and then again after writing. If the app forgot to call
>>> SYNC we must error.
>> just curious, but couldn't you batch up the 10 10x1 sync's?
> Yes that would work up to the first CPU access. Subsequent syncs would
> need to be carried out immediately or all ptes would need to be unmapped
> to detect the next CPU access. Write only syncs could probably be
> batched unconditionally.
>
> /Thomas

But aside from the problem of subsequent syncs after first CPU access,
does user-space really want to call sync for each line? Probably not,
but that's a problem that can be postponed (2D sync getting a separate
IOCTL) until someone gets tired of calling 1D syncs. My feeling is,
however that that will happen rather quickly and at least 2D syncs will
be a common usecase.

/Thomas





>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

about mmap dma-buf and sync

On 08/20/2015 04:33 PM, Rob Clark wrote:
> On Thu, Aug 20, 2015 at 2:48 AM, Thomas Hellstrom  
> wrote:
>> Hi, Tiago!
>>
>> On 08/20/2015 12:33 AM, Tiago Vignatti wrote:
>>> Hey Thomas, you haven't answered my email about making SYNC_* mandatory:
>>>
>>> http://lists.freedesktop.org/archives/dri-devel/2015-August/088376.html
>> Hmm, for some reason it doesn't show up in my mail app, but I found it
>> in the archives. An attempt to explain the situation from the vmwgfx
>> perspective.
>>
>> The fact that the interface is generic means that people will start
>> using it for the zero-copy case. There has been a couple of more or less
>> hackish attempts to do this before, and if it's a _driver_ interface we
>> don't need to be that careful but if it is a _generic_ interface we need
>> to be very careful to make it fit *all* the hardware out there and that
>> we make all potential users use the interface in a way that conforms
>> with the interface specification.
>>
>> What will happen otherwise is that apps written for coherent fast
>> hardware might, for example, ignore calling the SYNC api, just because
>> the app writer only cared about his own hardware on which the app works
>> fine. That would fail miserably if the same app was run on incoherent
>> hardware, or the incoherent hardware driver maintainers would be forced
>> to base an implementation on page-faults which would be very slow.
>>
>> So assume the following use case: An app updates a 10x10 area using the
>> CPU on a 1600x1200 dma-buf, and it will then use the dma-buf for
>> texturing. On some hardware the dma-buf might be tiled in a very
>> specific way, on vmwgfx the dma-buf is a GPU buffer on the host, only
>> accessible using DMA. On vmwgfx the SYNC operation must carry out a
>> 10x10 DMA from the host GPU buffer to a guest CPU buffer before the CPU
>> write and a DMA back again after the write, before GPU usage. On the
>> tiled architecture the SYNC operation must untile before CPU access and
>> probably tile again before GPU access.
>>
>> If we now have a one-dimensional SYNC api, in this particular case we'd
>> either need to sync a far too large area (1600x10) or call SYNC 10 times
>> before writing, and then again after writing. If the app forgot to call
>> SYNC we must error.
> just curious, but couldn't you batch up the 10 10x1 sync's?

Yes that would work up to the first CPU access. Subsequent syncs would
need to be carried out immediately or all ptes would need to be unmapped
to detect the next CPU access. Write only syncs could probably be
batched unconditionally.

/Thomas

[Bug 91704] Tonga startx fails since mesa/drm 56d8dd6 amdgpu: make vamgr per device v2

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

--- Comment #2 from Andy Furniss  ---
Further testing - booting into a pre existing drm-fixes-4.2 has the same issue.

The modesetting ddx works OK and using that I still have OpenGL, though uvd
will fail with dmesg errors as above.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150820/d7b6923b/attachment.html>

[Bug 91540] slow rendering & fullscreen results in stale images

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

Bas Nieuwenhuizen  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Bas Nieuwenhuizen  ---
I tested this again with the agd5f/linux drm-next-4.3 branch and this bug did
not occur anymore.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150820/03ec6889/attachment.html>

[Bug 91708] Tonga boots to terminal with drm-next-4.3, va conflict

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

Alex Deucher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Alex Deucher  ---


*** This bug has been marked as a duplicate of bug 91704 ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150820/6890073f/attachment-0001.html>

[Bug 91704] Tonga startx fails since mesa/drm 56d8dd6 amdgpu: make vamgr per device v2

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

Alex Deucher  changed:

   What|Removed |Added

 CC||master.homer at gmail.com

--- Comment #1 from Alex Deucher  ---
*** Bug 91708 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150820/40ac5ac2/attachment.html>

[Bug 91708] Tonga boots to terminal with drm-next-4.3, va conflict

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

Bug ID: 91708
   Summary: Tonga boots to terminal with drm-next-4.3, va conflict
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: master.homer at gmail.com

Created attachment 117829
  --> https://bugs.freedesktop.org/attachment.cgi?id=117829=edit
Kernel log when failing to boot normally

I've been having problems booting when using a self-compiled kernel of the
drm-next-4.3 branch from the agd5f repo. The amdgpu kernel driver complains
that some va (virtual address?) conflicts with another, which makes it boot to
a terminal.
You can see the conflict in the kernel log:
Aug 20 22:29:14 homer-desktop kernel: [6.762949] amdgpu :01:00.0: bo
880620b34800 va 0x10-0x100400 conflict with
0x10-0x100400
Aug 20 22:29:14 homer-desktop kernel: [6.763693] amdgpu :01:00.0: bo
880620b34800 va 0x10-0x100400 conflict with
0x10-0x100400
Aug 20 22:29:14 homer-desktop kernel: [6.764357] amdgpu :01:00.0: bo
880620b34800 va 0x10-0x100400 conflict with
0x10-0x100400
Aug 20 22:29:14 homer-desktop kernel: [6.765032] amdgpu :01:00.0: bo
880620b34800 va 0x10-0x100400 conflict with
0x10-0x100400

I do not have these problems when using a self-compiled kernel from the
drm-next-4.2 or drm-fixes-4.2 branch, so something must have changed from 4.2
to 4.3 that causes the conflict.

Using a Radeon R9 285 (TONGA) on Kubuntu vivid with mesa 11 from the oibaf ppa
and a self-compiled xf86-video-amdgpu.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150820/78d393f1/attachment.html>

[Bug 91707] Hibernation doesn't work with AMD Radeon R7 265

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

Bug ID: 91707
Summary: Hibernation doesn't work with AMD Radeon R7 265
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: DRM/Radeon
Assignee: dri-devel at lists.freedesktop.org
Reporter: rogutes+freedesktop at gmail.com

Created attachment 117828
--> https://bugs.freedesktop.org/attachment.cgi?id=117828=edit
dmesg output

Hibernation works perfectly when using the integrated Intel GPU, but
it only works once when using the discrete AMD Radeon R7 265.

I am testing different GPUs by changing the primary GPU in BIOS.

When trying to hibernate for the second time, I see one of 2 outcomes:
1. Display powers off, but the system stays on and stops responding to
ICMP pings and sysrq; after reset the system boots afresh and fsck
is run.
2. System powers off, but doesn't resume on next boot: boots afresh and
fsck is run.

More observations:
* Suspend to RAM works every time.
* Hibernation works every time as long as X has not been started.
* I am running Arch Linux, swap is on an SSD and not encrypted. I usually start
hibernation with `systemctl hibernate`, but writing to /sys/power/state has the
same effect.

I have no idea how to debug this issue, but would be happy to do it with your
help.

--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150820/73acbcb0/attachment.html>

[PATCH 3/3] ASoC: AMD: add AMD ASoC ACP-I2S driver [v4]

On Thu, Aug 20, 2015 at 7:45 PM, Mark Brown  wrote:
> On Thu, Aug 20, 2015 at 07:11:22PM -0400, Alex Deucher wrote:
>> On Thu, Aug 20, 2015 at 6:31 PM, Mark Brown  wrote:
>
>> > DRM is a special case here since there has always been work to share
>> > bits of the code with other operating systems, the licensing for DRM is
>> > very unusual within the kernel.  A quick sampling of drivers suggests
>> > that this license is not universally used there either.
>
>> > There is also the issue I raised with the fact that your non-GPL license
>> > statement does not appear to correspond to the MODULE_LICENSE() that
>> > you've included which claims the code is GPLed.
>
>> Once again this is exactly what the other drm drivers and support
>> modules do.  AMD generally prefers to contribute code licensed under
>> an MIT/X11 style licence which is why we've done this.  IANAL, but I
>> think that is compatible with "GPL and additional rights".
>
> This is not a DRM driver, it is an ASoC driver, and like I say DRM is a
> bit special.  I do note that AMD has contributed at least its CCP and
> cpufreq drivers (indeed all their non-DRM code I could find with
> explicit license statements) under a normal kernel license.  As far as I
> can tell this licensing is entirely confined to the DRM drivers.
>
> I am not readily able to convince myself that this is compatible with
> the intent of exporting the ASoC APIs _GPL(), this looks like it can be
> used as the basis for a shim layer for non-GPL code (the licensing
> strategy seems very similar).  I'd need to think through this carefully.

If you have strong concerns, I can double check with our lawyers and
see about changing it, I'm just not sure how long that will take :(
The licensing tends to vary based on the teams involved.  The ACP
audio and i2s was developed by the GPU teams and we've mostly worked
on drm and Xorg stuff until now.

Alex

[PATCH V5 3/3] ASoC: AMD: add AMD ASoC ACP-I2S driver

On Thu, Aug 20, 2015 at 7:18 PM, Mark Brown  wrote:
> On Thu, Aug 20, 2015 at 05:36:34PM -0400, Alex Deucher wrote:
>> From: Maruthi Srinivas Bayyavarapu 
>>
>> ACP IP block consists of dedicated DMA and I2S blocks. The PCM driver
>> provides the DMA and CPU DAI components to ALSA core.
>
> This is flagged as patch 3/3 but appears to be sent as a single patch.
> Please don't do this, the purpose of numbering patches is to help people
> tell which order they are in.  Numbering only makes sense when you send
> more than one patch, if you are sending a single patch there is no need
> to number.

Sorry, I just saw this reply now.  I just resent the patch with an
improved change log.  You an ignore that one.

Maruthi, can you comment on the points below and respin the patches as
necessary?

Thanks,

Alex

>
>> +++ b/sound/soc/amd/Kconfig
>> @@ -0,0 +1,5 @@
>> +config SND_SOC_AMD_ACP
>> + tristate "AMD Audio Coprocessor support"
>> + depends on MFD_CORE
>
> What is the dependency on the MFD core?
>
>> +/*
>> + * AMD ALSA SoC PCM Driver
>> + *
>> + * Copyright 2014-2015 Advanced Micro Devices, Inc.
>> + *
>> + * 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 PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
>> + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
>> + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
>> + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> + * OTHER DEALINGS IN THE SOFTWARE.
>
> Still not happy with the licensing.
>
>> +static const struct snd_soc_component_driver dw_i2s_component = {
>> + .name = "dw-i2s",
>> +};
>
> We already have a driver for the DesignWare I2S controller.  To repeat
> the concern I raised in a slightly different bit of the code last time:
>
> | This doesn't appear to be a designware-i2s driver, we already have one
> | of those?
>
> Like I say please stop ignoring review comments.  The hw_params()
> certainly seems to bear more than a passing resemblance.
>
>> +static void acp_pcm_period_elapsed(struct device *dev, u16 play_intr,
>> + u16 capture_intr)
>> +{
>> + struct snd_pcm_substream *substream;
>> + struct audio_drv_data *irq_data = dev_get_drvdata(dev);
>> +
>> + /* Inform ALSA about the period elapsed (one out of two periods) */
>> + if (play_intr)
>> + substream = irq_data->play_stream;
>> + else
>> + substream = irq_data->capture_stream;
>
> So you've replaced the two if statements with an if/else which means
> subsstream is now guaranteed to be initialized but perhaps not in the
> way the caller intended...  I did find the caller (which got moved into
> another patch in this version) and it appears that the two u16s are
> actually used to pass boolean flags.  The whole interface here now
> seems odd, what is going on here?
>
>> + if (NULL != pg) {
>
> We still normally write these checks more like (pg != NULL) or even just
> (pg).
>
>> + /* Save for runtime private data */
>> + rtd->pg = pg;
>> + rtd->order = get_order(size);
>> +
>> + /* Let ACP know the Allocated memory */
>> + num_of_pages = PAGE_ALIGN(size) >> PAGE_SHIFT;
>> +
>> + /* Fill the page table entries in ACP SRAM */
>> + rtd->pg = pg;
>> + rtd->size = size;
>> + rtd->num_of_pages = num_of_pages;
>> + rtd->direction = substream->stream;
>> +
>> + acp_dev->config_dma(acp_dev, rtd);
>> + status = 0;
>> + } else {
>> + status = -ENOMEM;
>> + }
>> + return status;
>> +}
>> +
>> +static int acp_dma_hw_free(struct snd_pcm_substream *substream)
>> +{
>> + return snd_pcm_lib_free_pages(substream);
>> +}
>
> hw_free() doesn't seem to undo everything that we did on allocation?
>
>> + /* Now configure DMA to transfer only first half of System RAM
>> +  * buffer before playback is triggered. This will overwrite
>> +  * zero-ed second half of SRAM buffer */
>> + acp_dev->config_dma_channel(acp_dev, SYSRAM_TO_ACP_CH_NUM,
>> +

[PATCH V6] ASoC: AMD: add AMD ASoC ACP-I2S driver

From: Maruthi Srinivas Bayyavarapu 

ACP IP block consists of dedicated DMA and I2S blocks. The PCM driver
provides the DMA and CPU DAI components to ALSA core.

Signed-off-by: Maruthi Bayyavarapu 
Reviewed-by: Alex Deucher 
Reviewed-by: Murali Krishna Vemuri 
Signed-off-by: Alex Deucher 
---

v2:
- squash in Kconfig fix
v3:
- squash in the following patches:
ASoC: AMD: add suspend/resume for ACP PCM driver
ASoC: AMD: add ACP PCM driver runtime PM
- Keep the Makefile sorted
- Fix the Kconfig whitespace
- drop RT286 changes to rework it using ACPI as a separate patch.
The gpio stuff we need to handle this with ACPI was not added to the
kernel until 4.2.  This patch was originally developed much earlier.
- put headers in include
- remove static structure initialization
- fix component name
- remove casts from void
- fix handling of combinations of play_intr and capture_intr
- fix coding style with {}
- switch to dev_ prints
- remove substream checks handled by subsystem
- fix whitespace in comments
- pass return code directly on error from acp_dev->dma_start
- drop references to designware
- fix codeing style (STATUS_SUCCESS)
- drop left over debugging messages
- drop stuff that is already set in the dai_link
- convert from using the amd_gnb_bus to an mfd cell
v4:
- change MODULE_ALIAS to platform:acp-i2s-audio
v5:
- failed attempt at a patch revision changelog
v6:
- respin the patch with a proper patch change log

The module licensing follows the model used in the drm drivers.
AMD prefers to contribute code under an MIT/X11 license. IANAL,
but "GPL and additional rights" as the MODULE_LICENSE seems to be
compatible with that and is exactly what most of the drm drivers
do.

 sound/soc/Kconfig   |   1 +
 sound/soc/Makefile  |   1 +
 sound/soc/amd/Kconfig   |   5 +
 sound/soc/amd/Makefile  |   3 +
 sound/soc/amd/acp-pcm-dma.c | 676 
 5 files changed, 686 insertions(+)
 create mode 100644 sound/soc/amd/Kconfig
 create mode 100644 sound/soc/amd/Makefile
 create mode 100644 sound/soc/amd/acp-pcm-dma.c

diff --git a/sound/soc/Kconfig b/sound/soc/Kconfig
index 2ae9619..1b9ce31 100644
--- a/sound/soc/Kconfig
+++ b/sound/soc/Kconfig
@@ -32,6 +32,7 @@ config SND_SOC_GENERIC_DMAENGINE_PCM

 # All the supported SoCs
 source "sound/soc/adi/Kconfig"
+source "sound/soc/amd/Kconfig"
 source "sound/soc/atmel/Kconfig"
 source "sound/soc/au1x/Kconfig"
 source "sound/soc/bcm/Kconfig"
diff --git a/sound/soc/Makefile b/sound/soc/Makefile
index e189903..a6cbb99 100644
--- a/sound/soc/Makefile
+++ b/sound/soc/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_SND_SOC) += snd-soc-core.o
 obj-$(CONFIG_SND_SOC)  += codecs/
 obj-$(CONFIG_SND_SOC)  += generic/
 obj-$(CONFIG_SND_SOC)  += adi/
+obj-$(CONFIG_SND_SOC)  += amd/
 obj-$(CONFIG_SND_SOC)  += atmel/
 obj-$(CONFIG_SND_SOC)  += au1x/
 obj-$(CONFIG_SND_SOC)  += bcm/
diff --git a/sound/soc/amd/Kconfig b/sound/soc/amd/Kconfig
new file mode 100644
index 000..ce39979
--- /dev/null
+++ b/sound/soc/amd/Kconfig
@@ -0,0 +1,5 @@
+config SND_SOC_AMD_ACP
+   tristate "AMD Audio Coprocessor support"
+   depends on MFD_CORE
+   help
+This option enables ACP support (DMA,I2S) on AMD platforms.
diff --git a/sound/soc/amd/Makefile b/sound/soc/amd/Makefile
new file mode 100644
index 000..1a66ec0
--- /dev/null
+++ b/sound/soc/amd/Makefile
@@ -0,0 +1,3 @@
+snd-soc-acp-pcm-objs   := acp-pcm-dma.o
+
+obj-$(CONFIG_SND_SOC_AMD_ACP) += snd-soc-acp-pcm.o
diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
new file mode 100644
index 000..18cc60c
--- /dev/null
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -0,0 +1,676 @@
+/*
+ * AMD ALSA SoC PCM Driver
+ *
+ * Copyright 2014-2015 Advanced Micro Devices, Inc.
+ *
+ * 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 PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include

[PATCH 3/3] ASoC: AMD: add AMD ASoC ACP-I2S driver [v4]

On Thu, Aug 20, 2015 at 6:31 PM, Mark Brown  wrote:
> On Thu, Aug 20, 2015 at 05:30:27PM -0400, Alex Deucher wrote:
>> On Thu, Aug 20, 2015 at 5:13 PM, Mark Brown  wrote:
>
>> >> v4: squash in naming fixes
>
>> > To repeat what I said last time:
>
>> > | Please follow the patch submission process in SubmittingPatches: put any
>> > | versioning in the subject line inside the [] and put noise like inter
>> > | version changelogs after the ---.
>
>> I addressed this in my coverletter.  Some subsystems prefer to retain
>> that information.  If you'd prefer to not have them in the audio patch
>> I will remove them.
>
> When I said to follow the standard process here that's what I meant,
> yes.  It's basically just the graphics subsystem that does something
> different here, and note that if you are going to include a changelog
> (either in the normal place or the DRM place) it really ought to
> actually describe the changes that have been made - the above doesn't
> reflect the changes that were made at all.

OK.  I'll respin the patch.

>
>> > I also remain very concerned about this non-GPL license you are using.
>> > Please do not ignore review comments like this :(
>
>> I mentioned this in the cover letter as well.  Most if not all of the
>> drm drivers are licensed the same way.  IANAL, but I am not aware of
>> any concerns about them.
>
> DRM is a special case here since there has always been work to share
> bits of the code with other operating systems, the licensing for DRM is
> very unusual within the kernel.  A quick sampling of drivers suggests
> that this license is not universally used there either.
>
> There is also the issue I raised with the fact that your non-GPL license
> statement does not appear to correspond to the MODULE_LICENSE() that
> you've included which claims the code is GPLed.

Once again this is exactly what the other drm drivers and support
modules do.  AMD generally prefers to contribute code licensed under
an MIT/X11 style licence which is why we've done this.  IANAL, but I
think that is compatible with "GPL and additional rights".

Alex

[Bug 91704] Tonga startx fails since mesa/drm 56d8dd6 amdgpu: make vamgr per device v2

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

Bug ID: 91704
   Summary: Tonga startx fails since mesa/drm 56d8dd6 amdgpu: make
vamgr per device v2
   Product: DRI
   Version: DRI git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: adf.lists at gmail.com

Created attachment 117820
  --> https://bugs.freedesktop.org/attachment.cgi?id=117820=edit
xorg log

With latest libdrm git I can't startx due to a segfault shown in attached xorg
log.

dmesg logs several -

amdgpu :01:00.0: bo 8800bd34b800 va 0x10-0x100400 conflict
with 0x10-0x100400

This happens with mesa/drm on commit 

56d8dd6 amdgpu: make vamgr per device v2

On the commit before that -

ffa305d amdgpu: add flag to support 32bit VA address v4

I can startx without error but performance is broken eg. scrolling in xterm
takes about a second to refresh the screen.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150820/1bb80cf8/attachment.html>

[PATCH V5 3/3] ASoC: AMD: add AMD ASoC ACP-I2S driver

From: Maruthi Srinivas Bayyavarapu 

ACP IP block consists of dedicated DMA and I2S blocks. The PCM driver
provides the DMA and CPU DAI components to ALSA core.

Signed-off-by: Maruthi Bayyavarapu 
Reviewed-by: Alex Deucher 
Reviewed-by: Murali Krishna Vemuri 
Signed-off-by: Alex Deucher 
---

v2: squash in Kconfig fix
v3: squash additional commits, convert to mfd, drop rt286 changes
v4: squash in naming fixes
v5: move patch versioning out of commit message

The module licensing follows the model used in the drm drivers.

 sound/soc/Kconfig   |   1 +
 sound/soc/Makefile  |   1 +
 sound/soc/amd/Kconfig   |   5 +
 sound/soc/amd/Makefile  |   3 +
 sound/soc/amd/acp-pcm-dma.c | 676 
 5 files changed, 686 insertions(+)
 create mode 100644 sound/soc/amd/Kconfig
 create mode 100644 sound/soc/amd/Makefile
 create mode 100644 sound/soc/amd/acp-pcm-dma.c

diff --git a/sound/soc/Kconfig b/sound/soc/Kconfig
index 2ae9619..1b9ce31 100644
--- a/sound/soc/Kconfig
+++ b/sound/soc/Kconfig
@@ -32,6 +32,7 @@ config SND_SOC_GENERIC_DMAENGINE_PCM

 # All the supported SoCs
 source "sound/soc/adi/Kconfig"
+source "sound/soc/amd/Kconfig"
 source "sound/soc/atmel/Kconfig"
 source "sound/soc/au1x/Kconfig"
 source "sound/soc/bcm/Kconfig"
diff --git a/sound/soc/Makefile b/sound/soc/Makefile
index e189903..a6cbb99 100644
--- a/sound/soc/Makefile
+++ b/sound/soc/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_SND_SOC) += snd-soc-core.o
 obj-$(CONFIG_SND_SOC)  += codecs/
 obj-$(CONFIG_SND_SOC)  += generic/
 obj-$(CONFIG_SND_SOC)  += adi/
+obj-$(CONFIG_SND_SOC)  += amd/
 obj-$(CONFIG_SND_SOC)  += atmel/
 obj-$(CONFIG_SND_SOC)  += au1x/
 obj-$(CONFIG_SND_SOC)  += bcm/
diff --git a/sound/soc/amd/Kconfig b/sound/soc/amd/Kconfig
new file mode 100644
index 000..ce39979
--- /dev/null
+++ b/sound/soc/amd/Kconfig
@@ -0,0 +1,5 @@
+config SND_SOC_AMD_ACP
+   tristate "AMD Audio Coprocessor support"
+   depends on MFD_CORE
+   help
+This option enables ACP support (DMA,I2S) on AMD platforms.
diff --git a/sound/soc/amd/Makefile b/sound/soc/amd/Makefile
new file mode 100644
index 000..1a66ec0
--- /dev/null
+++ b/sound/soc/amd/Makefile
@@ -0,0 +1,3 @@
+snd-soc-acp-pcm-objs   := acp-pcm-dma.o
+
+obj-$(CONFIG_SND_SOC_AMD_ACP) += snd-soc-acp-pcm.o
diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
new file mode 100644
index 000..18cc60c
--- /dev/null
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -0,0 +1,676 @@
+/*
+ * AMD ALSA SoC PCM Driver
+ *
+ * Copyright 2014-2015 Advanced Micro Devices, Inc.
+ *
+ * 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 PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#define PLAYBACK_MIN_NUM_PERIODS2
+#define PLAYBACK_MAX_NUM_PERIODS2
+#define PLAYBACK_MAX_PERIOD_SIZE16384
+#define PLAYBACK_MIN_PERIOD_SIZE1024
+#define CAPTURE_MIN_NUM_PERIODS 2
+#define CAPTURE_MAX_NUM_PERIODS 2
+#define CAPTURE_MAX_PERIOD_SIZE 16384
+#define CAPTURE_MIN_PERIOD_SIZE 1024
+
+#define NUM_DSCRS_PER_CHANNEL 2
+
+#define MAX_BUFFER (PLAYBACK_MAX_PERIOD_SIZE * PLAYBACK_MAX_NUM_PERIODS)
+#define MIN_BUFFER MAX_BUFFER
+
+#define TWO_CHANNEL_SUPPORT 2  /* up to 2.0 */
+#define FOUR_CHANNEL_SUPPORT4  /* up to 3.1 */
+#define SIX_CHANNEL_SUPPORT 6  /* up to 5.1 */
+#define EIGHT_CHANNEL_SUPPORT   8  /* up to 7.1 */
+
+
+static const struct snd_pcm_hardware acp_pcm_hardware_playback = {
+   .info = SNDRV_PCM_INFO_INTERLEAVED |
+   SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_MMAP |
+   SNDRV_PCM_INFO_MMAP_VALID | SNDRV_PCM_INFO_BATCH |
+   SNDRV_PCM_INFO_PAUSE | SNDRV_PCM_INFO_RESUME,
+   /* formats,rates,channels  based on i2s doc. */
+   .formats = SNDRV_PCM_FMTBIT_S16_LE |

[PATCH 3/3] ASoC: AMD: add AMD ASoC ACP-I2S driver [v4]

On Thu, Aug 20, 2015 at 5:13 PM, Mark Brown  wrote:
> On Thu, Aug 20, 2015 at 04:09:21PM -0400, Alex Deucher wrote:
>> From: Maruthi Srinivas Bayyavarapu 
>>
>> ACP IP block consists of dedicated DMA and I2S blocks. The PCM driver
>> provides the DMA and CPU DAI components to ALSA core.
>>
>> v2: squash in Kconfig fix
>> v3: squash additional commits, convert to mfd, drop rt286 changes
>> v4: squash in naming fixes
>
> To repeat what I said last time:
>
> | Please follow the patch submission process in SubmittingPatches: put any
> | versioning in the subject line inside the [] and put noise like inter
> | version changelogs after the ---.

I addressed this in my coverletter.  Some subsystems prefer to retain
that information.  If you'd prefer to not have them in the audio patch
I will remove them.

>
>> +/*
>> + * AMD ALSA SoC PCM Driver
>> + *
>> + * Copyright 2014-2015 Advanced Micro Devices, Inc.
>> + *
>> + * 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 PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
>> + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
>> + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
>> + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> + * OTHER DEALINGS IN THE SOFTWARE.
>
> I also remain very concerned about this non-GPL license you are using.
> Please do not ignore review comments like this :(

I mentioned this in the cover letter as well.  Most if not all of the
drm drivers are licensed the same way.  IANAL, but I am not aware of
any concerns about them.

Alex

[PATCH 1/4] drm: add interface to get drm devices on the system v3

On 20 August 2015 at 04:02, Zhou, Jammy  wrote:
> Hi Emil,
>
> Can I get you RB now? It looks like there was no more comment from others.
>
I'll ping (again) one the possible users and if we haven't heard any
objection by tomorrow midday I'll commit it to master.

Cheers,
Emil

[PATCH 3/6] xf86drmMode: Make atomic request structures visible

On 19 August 2015 at 01:58, Hyungwon Hwang  wrote:
> This patch makes 'struct _drmModeAtomicReqItem' and 'struct
> _drmModeAtomicReq' visible from outside. This is needed for userspace
> applications to use those structures when calling drmModeAtomicCommit().
>
Hmmm what is missing in the current API, that one needs direct access
to the structs ? If we expose these to the user we'll be putting a
(ABI) hedgehog down our pants (i.e. it might be ok, but will likely
result in a very painful experience).

Thanks
Emil

[PATCH 2/6] xf86drmMode: separate drmModeAtomicCommit() and drmModeAtomicCleanup()

Hi Hyungwon,

On 19 August 2015 at 01:58, Hyungwon Hwang  wrote:
> This patch seprates the code, which sorts proprty sets and eliminates
> duplicate properties, from drmModeAtomicCommit(). Now
> drmModeAtomicCleanup() has to do the job before calling
> drmModeAtomicCommit(), and drmModeAtomicCommit() just converts the cleaned
> request to IOCTL argument.
>
Afaict the commit message should say why we want this, rather than
rewording what the patch does.

I'm not sure about the atomic status for wayland and others but this
commit might cause issues there. Additionally, with this patch we'll
send a lot of useless information to the kernel if one omits
drmModeAtomicCleanup(). The kernel will likely discard it but still
this doesn't seem like a good idea imho.

-Emil

[PATCH 3/3] ASoC: AMD: add AMD ASoC ACP-I2S driver [v4]

On Thu, Aug 20, 2015 at 07:50:34PM -0400, Alex Deucher wrote:
> On Thu, Aug 20, 2015 at 7:45 PM, Mark Brown  wrote:

> > This is not a DRM driver, it is an ASoC driver, and like I say DRM is a
> > bit special.  I do note that AMD has contributed at least its CCP and
> > cpufreq drivers (indeed all their non-DRM code I could find with
> > explicit license statements) under a normal kernel license.  As far as I
> > can tell this licensing is entirely confined to the DRM drivers.

> > I am not readily able to convince myself that this is compatible with
> > the intent of exporting the ASoC APIs _GPL(), this looks like it can be
> > used as the basis for a shim layer for non-GPL code (the licensing
> > strategy seems very similar).  I'd need to think through this carefully.

> If you have strong concerns, I can double check with our lawyers and
> see about changing it, I'm just not sure how long that will take :(

I at the very least need to think about this, it's really important to
me that we don't want to see proprietary drivers.

> The licensing tends to vary based on the teams involved.  The ACP
> audio and i2s was developed by the GPU teams and we've mostly worked
> on drm and Xorg stuff until now.

For reference the GPL code in the kernel includes at least:

  drivers/crypto/ccp/ccp-crypto-*.c
  drivers/cpufreq/powernow-k8.c
  drivers/pinctrl/pinctrl-amd.c

and there's direct contributions from AMD there AFAICT, not just outside
developers contributing support for AMD chips.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150820/4e04ac30/attachment-0001.sig>

[PATCH 1/2] amdgpu: add Makefile.sources

Seems like git send-email went awol when formatting this, and git am
wasn't able to pick it up :(

On the good side, I've noticed that we can/should drop amdgpu.h from
the LIBDRM_AMDGPU_FILES list. So I've amended that and pushed these
two.

Thank you Mauro.
Emil

[PATCH 1/2] amdgpu: add Makefile.sources

Seems like git send-email went awol when formatting this, and git am
wasn't able to pick it up :(

On the good side, I've noticed that we can/should drop amdgpu.h from
the LIBDRM_AMDGPU_FILES list. So I've amended that and pushed these
two.

Thank you Mauro.
Emil

amdgpu 32-bit arm warnings

On Wed, Aug 19, 2015 at 11:38 PM, Michel DÃ¤nzer  wrote:
> On 20.08.2015 08:50, Dave Airlie wrote:
>>   CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.o
>> /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:
>> In function âamdgpu_cs_parser_initâ:
>> /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:211:21:
>> warning: cast to pointer from integer of different size
>> [-Wint-to-pointer-cast]
>>   chunk_array_user = (uint64_t __user *)(cs->in.chunks);
>>  ^
>> /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:231:15:
>> warning: cast to pointer from integer of different size
>> [-Wint-to-pointer-cast]
>>chunk_ptr = (void __user *)chunk_array[i];
>>^
>> /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:241:11:
>> warning: cast to pointer from integer of different size
>> [-Wint-to-pointer-cast]
>>cdata = (void __user *)user_chunk.chunk_data;
>>^
>
> Looks like the (unsigned long) casts removed by commit e60b344f
> ("drm/amdgpu: optimize amdgpu_parser_init") need to stay.
>

Attached patch should fix it.

Alex
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-amdgpu-fix-warnings-on-32bit-ARM.patch
Type: text/x-patch
Size: 1777 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150820/66ed9070/attachment.bin>

[PATCH v3 13/14] drm: bridge/analogix_dp: move hpd detect to connector detect function

On 2015. 8. 19., at PM 11:52, Yakir Yang  wrote:
> 


What is the reason to make this patch?

Please make commit message including the reason.

Best regards,
Jingoo Han

> Signed-off-by: Yakir Yang 
> ---
> Changes in v3:
> - move dp hpd detect to connector detect function.
> 
> Changes in v2: None
> 
> drivers/gpu/drm/bridge/analogix_dp_core.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/analogix_dp_core.c 
> b/drivers/gpu/drm/bridge/analogix_dp_core.c
> index 75dd44a..052b9b3 100644
> --- a/drivers/gpu/drm/bridge/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix_dp_core.c
> @@ -915,12 +915,6 @@ static void analogix_dp_commit(struct analogix_dp_device 
> *dp)
>DRM_ERROR("failed to disable the panel\n");
>}
> 
> -ret = analogix_dp_detect_hpd(dp);
> -if (ret) {
> -/* Cable has been disconnected, we're done */
> -return;
> -}
> -
>ret = analogix_dp_handle_edid(dp);
>if (ret) {
>dev_err(dp->dev, "unable to handle edid\n");
> @@ -953,6 +947,12 @@ static void analogix_dp_commit(struct analogix_dp_device 
> *dp)
> static enum drm_connector_status analogix_dp_detect(
>struct drm_connector *connector, bool force)
> {
> +struct analogix_dp_device *dp = connector_to_dp(connector);
> +
> +if (analogix_dp_detect_hpd(dp))
> +/* Cable has been disconnected, we're done */
> +return connector_status_disconnected;
> +
>return connector_status_connected;
> }
> 
> -- 
> 1.9.1
> 
>

[PATCH 3/3] ASoC: AMD: add AMD ASoC ACP-I2S driver [v4]

On Thu, Aug 20, 2015 at 07:11:22PM -0400, Alex Deucher wrote:
> On Thu, Aug 20, 2015 at 6:31 PM, Mark Brown  wrote:

> > DRM is a special case here since there has always been work to share
> > bits of the code with other operating systems, the licensing for DRM is
> > very unusual within the kernel.  A quick sampling of drivers suggests
> > that this license is not universally used there either.

> > There is also the issue I raised with the fact that your non-GPL license
> > statement does not appear to correspond to the MODULE_LICENSE() that
> > you've included which claims the code is GPLed.

> Once again this is exactly what the other drm drivers and support
> modules do.  AMD generally prefers to contribute code licensed under
> an MIT/X11 style licence which is why we've done this.  IANAL, but I
> think that is compatible with "GPL and additional rights".

This is not a DRM driver, it is an ASoC driver, and like I say DRM is a
bit special.  I do note that AMD has contributed at least its CCP and
cpufreq drivers (indeed all their non-DRM code I could find with
explicit license statements) under a normal kernel license.  As far as I
can tell this licensing is entirely confined to the DRM drivers.

I am not readily able to convince myself that this is compatible with
the intent of exporting the ASoC APIs _GPL(), this looks like it can be
used as the basis for a shim layer for non-GPL code (the licensing
strategy seems very similar).  I'd need to think through this carefully.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150820/70b01bb0/attachment-0001.sig>

about mmap dma-buf and sync

2015-08-20 Thread Jerome Glisse

On Thu, Aug 20, 2015 at 09:39:12PM +0200, Thomas Hellstrom wrote:
> On 08/20/2015 04:53 PM, Jerome Glisse wrote:
> > On Thu, Aug 20, 2015 at 08:48:23AM +0200, Thomas Hellstrom wrote:
> >> Hi, Tiago!
> >>
> >> On 08/20/2015 12:33 AM, Tiago Vignatti wrote:
> >>> Hey Thomas, you haven't answered my email about making SYNC_* mandatory:
> >>>
> >>> http://lists.freedesktop.org/archives/dri-devel/2015-August/088376.html
> >> Hmm, for some reason it doesn't show up in my mail app, but I found it
> >> in the archives. An attempt to explain the situation from the vmwgfx
> >> perspective.
> >>
> >> The fact that the interface is generic means that people will start
> >> using it for the zero-copy case. There has been a couple of more or less
> >> hackish attempts to do this before, and if it's a _driver_ interface we
> >> don't need to be that careful but if it is a _generic_ interface we need
> >> to be very careful to make it fit *all* the hardware out there and that
> >> we make all potential users use the interface in a way that conforms
> >> with the interface specification.
> >>
> >> What will happen otherwise is that apps written for coherent fast
> >> hardware might, for example, ignore calling the SYNC api, just because
> >> the app writer only cared about his own hardware on which the app works
> >> fine. That would fail miserably if the same app was run on incoherent
> >> hardware, or the incoherent hardware driver maintainers would be forced
> >> to base an implementation on page-faults which would be very slow.
> >>
> >> So assume the following use case: An app updates a 10x10 area using the
> >> CPU on a 1600x1200 dma-buf, and it will then use the dma-buf for
> >> texturing. On some hardware the dma-buf might be tiled in a very
> >> specific way, on vmwgfx the dma-buf is a GPU buffer on the host, only
> >> accessible using DMA. On vmwgfx the SYNC operation must carry out a
> >> 10x10 DMA from the host GPU buffer to a guest CPU buffer before the CPU
> >> write and a DMA back again after the write, before GPU usage. On the
> >> tiled architecture the SYNC operation must untile before CPU access and
> >> probably tile again before GPU access.
> >>
> >> If we now have a one-dimensional SYNC api, in this particular case we'd
> >> either need to sync a far too large area (1600x10) or call SYNC 10 times
> >> before writing, and then again after writing. If the app forgot to call
> >> SYNC we must error.
> >>
> >> So to summarize, the fact that the interface is generic IMO means:
> >>
> >> 1) Any user must be able to make valid assumptions about the internal
> >> format of the dma-buf. (untiled, color format, stride etc.)
> >> 2) Any user *must* call SYNC before and after CPU access. On coherent
> >> architectures, the SYNC is a NULL operation anyway, and that should be
> >> documented somewhere so that maintainers of drivers of uncoherent
> >> architectures have somewhere to point their fingers.
> >> 3) Driver-specific implementations must be allowed to error (segfault)
> >> if SYNC has not been used.
> > I think here you are too lax, the common code must segfault or
> > error badly if SYNC has not been use in all cases even on cache
> > coherent arch. The device driver sync callback can still be a
> > no operation. But i think that we need to insist strongly on a
> > proper sync call being made (and we should forbid empty area
> > sync call). This would be the only way to make sure userspace
> > behave properly as otherwise we endup in the situation you were
> > describing above, where the app is design on a cache coherent
> > arch and works fine there but broke in subtle way on non cache
> > coherent arch and app developer is clueless of why.
> >
> > I just do not trust userspace.
> I agree and ideally i'd want it this way as well. The question is, is it
> possible? Can this be done without a fault() handler in the generic
> kernel code?
> 
> >
> >> 4) The use-case stated above clearly shows the benefit of a
> >> 2-dimensional sync interface (we want to sync the 10x10 region), but
> >> what if someone in the future wants to use this interface for a 3D
> >> texture? Will a 2D sync suffice? Can we make the SYNC interface
> >> extendable in a way that an enum sync_type member defines the layout of
> >> the argument, and initially we implement only 1d, 2d sync, leaving 3d
> >> for the future?
> >>
> >> Also, I agree there is probably no good way to generically implement an
> >> error if SYNC has not been called. That needs to be left as an option to
> >> drivers.
> > I think there is, just forbid any further use of the dma buffer, mark
> > it as invalid and printk a big error. Userspace app developer will
> > quickly see that something is wrong and looking at kernel log should
> > explain why.
> 
> The problem is if someone calls mmap() and then decides to not access
> the buffer before munmap() or GPU usage. How do we recognize that case
> and separate it from a CPU access occured outside a sync? We could, as

[RFC 11/13] drm/dp: Add helper to dump DPCD

2015-08-20 Thread Rafael Antognolli

On Mon, Aug 17, 2015 at 10:02:04AM +0300, Jani Nikula wrote:
> On Fri, 14 Aug 2015, Rafael Antognolli  wrote:
> > On Fri, Aug 14, 2015 at 02:56:55PM +0300, Jani Nikula wrote:
> >> On Wed, 12 Aug 2015, Thierry Reding  wrote:
> >> > From: Thierry Reding 
> >> >
> >> > The new drm_dp_dpcd_dump() helper dumps the contents of a DPCD to a
> >> > seq_file and can be used to make the DPCD available via debugfs for
> >> > example.
> >> 
> >> See i915/i915_debugfs.c for one DPCD dump implementation.
> >> 
> >> Around the time that was added, there was also some discussion (and
> >> patches [1]) to expose a read/write debugfs interface to DPCD, letting
> >> userspace access arbitrary DPCD registers.
> >> 
> >> Just this week there was some discussion about revisiting that. It was
> >> about accessing some proprietary panel features, but there's also the
> >> ease of debugging without having to keep updating the kernel to dump
> >> more.
> >> 
> >> I think it would be great to agree on a common debugfs interface to
> >> access DPCD arbitrarily. Last time I checked, the blocker to that was
> >> access to the aux channel from generic code; it's always driver
> >> specific. SMOP. ;)
> >
> > Do you mean it would require the generic code/interface to somehow route
> > this to the driver specific code? I am not sure yet how this works (if
> > there's something like it around), but I'll take a look.
> 
> Drivers can choose to support DP AUX any way they like, and they don't
> have to use the common helpers to do so. It's pretty much an
> implementation detail. I think we could require the use of the common
> helpers to support generic DPCD access from debugfs, but we'd still have
> to come up with a way to get hold of struct drm_dp_aux (again, driver
> internals) given a drm_connector in generic debugfs code.

I was under the assumption they always used the helpers, but I
understand that's not always the case.

Anyway, I was going to propose a new helper to "store" the drm_dp_aux
inside the drm_connector. And just expose something on debugfs if it was
used. Something like:

int drm_dp_aux_store(struct drm_dp_aux *aux,
 struct drm_connector *connector);

The helpers don't seem to know about drm_connector's though, so I'm not sure
this is a good approach.

> Thierry, do you see any problems with having a connector function to get
> hold of its drm_dp_aux?

Would this be a new function pointer inside struct drm_connector_funcs?
If so, I'm fine with this approach too.

Regarding the interface, you mentioned that you didn't like it because
it had a state. What about just dumping the content of the register into
dmesg when one tries to read it, and use a different sintaxe for
writing, passing both the register addr and the value?

Daniel had another suggestion, regarding an ioctl in debugfs, but I'm
not sure I clearly understand that yet.

Thanks,
Rafael

[PATCH v3 05/14] drm: bridge/analogix_dp: fix link_rate & lane_count bug

On 2015. 8. 19., at PM 11:50, Yakir Yang  wrote:
> 
> link_rate and lane_count already configed in analogix_dp_set_link_train(),

s/configed/configured

Also, the commit name such as "fix ... bug" is not good.
How about following?

drm: bridge/analogix_dp: remove duplicate configuration of link rate and link 
count

Best regards,
Jingoo Han

> so we don't need to config those repeatly after training finished, just
> remove them out.
> 
> Beside Display Port 1.2 already support 5.4Gbps link rate, the maximum sets
> would change from {1.62Gbps, 2.7Gbps} to {1.62Gbps, 2.7Gbps, 5.4Gbps}.
> 
> Signed-off-by: Yakir Yang 
> ---
> Changes in v3:
> - Take Thierry Reding suggest, link_rate and lane_count shouldn't config to
>  the DT property value directly, but we can take those as hardware limite.
>  For example, RK3288 only support 4 physical lanes of 2.7/1.62 Gbps/lane,
>  so DT property would like "link-rate = 0x0a" "lane-count = 4".
> 
> Changes in v2: None
> 
> drivers/gpu/drm/bridge/analogix_dp_core.c | 16 
> drivers/gpu/drm/bridge/analogix_dp_core.h |  9 +
> 2 files changed, 13 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/analogix_dp_core.c 
> b/drivers/gpu/drm/bridge/analogix_dp_core.c
> index 480cc13..1778e0a 100644
> --- a/drivers/gpu/drm/bridge/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix_dp_core.c
> @@ -635,6 +635,8 @@ static void analogix_dp_get_max_rx_bandwidth(struct 
> analogix_dp_device *dp,
>/*
> * For DP rev.1.1, Maximum link rate of Main Link lanes
> * 0x06 = 1.62 Gbps, 0x0a = 2.7 Gbps
> + * For DP rev.1.2, Maximum link rate of Main Link lanes
> + * 0x06 = 1.62 Gbps, 0x0a = 2.7 Gbps, 0x14 = 5.4Gbps
> */
>analogix_dp_read_byte_from_dpcd(dp, DP_MAX_LINK_RATE, );
>*bandwidth = data;
> @@ -668,7 +670,8 @@ static void analogix_dp_init_training(struct 
> analogix_dp_device *dp,
>analogix_dp_get_max_rx_lane_count(dp, >link_train.lane_count);
> 
>if ((dp->link_train.link_rate != LINK_RATE_1_62GBPS) &&
> -(dp->link_train.link_rate != LINK_RATE_2_70GBPS)) {
> +(dp->link_train.link_rate != LINK_RATE_2_70GBPS) &&
> +(dp->link_train.link_rate != LINK_RATE_5_40GBPS)) {
>dev_err(dp->dev, "Rx Max Link Rate is abnormal :%x !\n",
>dp->link_train.link_rate);
>dp->link_train.link_rate = LINK_RATE_1_62GBPS;
> @@ -901,8 +904,8 @@ static void analogix_dp_commit(struct analogix_dp_device 
> *dp)
>return;
>}
> 
> -ret = analogix_dp_set_link_train(dp, dp->video_info->lane_count,
> - dp->video_info->link_rate);
> +ret = analogix_dp_set_link_train(dp, dp->video_info->max_lane_count,
> + dp->video_info->max_link_rate);
>if (ret) {
>dev_err(dp->dev, "unable to do link train\n");
>return;
> @@ -912,9 +915,6 @@ static void analogix_dp_commit(struct analogix_dp_device 
> *dp)
>analogix_dp_enable_rx_to_enhanced_mode(dp, 1);
>analogix_dp_enable_enhanced_mode(dp, 1);
> 
> -analogix_dp_set_lane_count(dp, dp->video_info->lane_count);
> -analogix_dp_set_link_bandwidth(dp, dp->video_info->link_rate);
> -
>analogix_dp_init_video(dp);
>ret = analogix_dp_config_video(dp);
>if (ret)
> @@ -1198,13 +1198,13 @@ static struct video_info 
> *analogix_dp_dt_parse_pdata(struct device *dev)
>}
> 
>if (of_property_read_u32(dp_node, "analogix,link-rate",
> - _video_config->link_rate)) {
> + _video_config->max_link_rate)) {
>dev_err(dev, "failed to get link-rate\n");
>return ERR_PTR(-EINVAL);
>}
> 
>if (of_property_read_u32(dp_node, "analogix,lane-count",
> - _video_config->lane_count)) {
> + _video_config->max_lane_count)) {
>dev_err(dev, "failed to get lane-count\n");
>return ERR_PTR(-EINVAL);
>}
> diff --git a/drivers/gpu/drm/bridge/analogix_dp_core.h 
> b/drivers/gpu/drm/bridge/analogix_dp_core.h
> index 2cefde9..941b34f 100644
> --- a/drivers/gpu/drm/bridge/analogix_dp_core.h
> +++ b/drivers/gpu/drm/bridge/analogix_dp_core.h
> @@ -21,8 +21,9 @@
> #define MAX_EQ_LOOP 5
> 
> enum link_rate_type {
> -LINK_RATE_1_62GBPS = 0x06,
> -LINK_RATE_2_70GBPS = 0x0a
> +LINK_RATE_1_62GBPS = DP_LINK_BW_1_62,
> +LINK_RATE_2_70GBPS = DP_LINK_BW_2_7,
> +LINK_RATE_5_40GBPS = DP_LINK_BW_5_4,
> };
> 
> enum link_lane_count_type {
> @@ -128,8 +129,8 @@ struct video_info {
>enum color_coefficient ycbcr_coeff;
>enum color_depth color_depth;
> 
> -enum link_rate_type link_rate;
> -enum link_lane_count_type lane_count;
> +enum link_rate_type   max_link_rate;
> +enum link_lane_count_type max_lane_count;
> };
> 
> struct link_train {
> -- 
> 1.9.1
> 
>

[PATCH V5 3/3] ASoC: AMD: add AMD ASoC ACP-I2S driver


| Why?  The comments describe what's happening but it's not clear why it's
| happening.

> +static struct snd_soc_dai_driver i2s_dai_driver = {
> + .playback = {
> +  .stream_name = "I2S Playback",
> +  .channels_min = 2,
> +  .channels_max = 2,

Elsewhere support for 8 channels was declared and handled.

> +  .rates = SNDRV_PCM_RATE_8000_96000,
> +  .formats = SNDRV_PCM_FMTBIT_S24_LE |
> + SNDRV_PCM_FMTBIT_S32_LE,

Elsewhere there was 16 bit support declared and handled.

> + pm_rts = pm_runtime_status_suspended(dev);
> + if (pm_rts == true) {

There seem to be a lot of variables in here that have only one
assignment and one user immediately next to them.  I'm not sure it's
adding much.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150820/03ad110f/attachment-0001.sig>

[PATCH 3/3] ASoC: AMD: add AMD ASoC ACP-I2S driver [v4]

From: Maruthi Srinivas Bayyavarapu 

ACP IP block consists of dedicated DMA and I2S blocks. The PCM driver
provides the DMA and CPU DAI components to ALSA core.

v2: squash in Kconfig fix
v3: squash additional commits, convert to mfd, drop rt286 changes
v4: squash in naming fixes

Signed-off-by: Maruthi Bayyavarapu 
Reviewed-by: Alex Deucher 
Reviewed-by: Murali Krishna Vemuri 
Signed-off-by: Alex Deucher 
---
 sound/soc/Kconfig   |   1 +
 sound/soc/Makefile  |   1 +
 sound/soc/amd/Kconfig   |   5 +
 sound/soc/amd/Makefile  |   3 +
 sound/soc/amd/acp-pcm-dma.c | 676 
 5 files changed, 686 insertions(+)
 create mode 100644 sound/soc/amd/Kconfig
 create mode 100644 sound/soc/amd/Makefile
 create mode 100644 sound/soc/amd/acp-pcm-dma.c

diff --git a/sound/soc/Kconfig b/sound/soc/Kconfig
index 2ae9619..1b9ce31 100644
--- a/sound/soc/Kconfig
+++ b/sound/soc/Kconfig
@@ -32,6 +32,7 @@ config SND_SOC_GENERIC_DMAENGINE_PCM

 # All the supported SoCs
 source "sound/soc/adi/Kconfig"
+source "sound/soc/amd/Kconfig"
 source "sound/soc/atmel/Kconfig"
 source "sound/soc/au1x/Kconfig"
 source "sound/soc/bcm/Kconfig"
diff --git a/sound/soc/Makefile b/sound/soc/Makefile
index e189903..a6cbb99 100644
--- a/sound/soc/Makefile
+++ b/sound/soc/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_SND_SOC) += snd-soc-core.o
 obj-$(CONFIG_SND_SOC)  += codecs/
 obj-$(CONFIG_SND_SOC)  += generic/
 obj-$(CONFIG_SND_SOC)  += adi/
+obj-$(CONFIG_SND_SOC)  += amd/
 obj-$(CONFIG_SND_SOC)  += atmel/
 obj-$(CONFIG_SND_SOC)  += au1x/
 obj-$(CONFIG_SND_SOC)  += bcm/
diff --git a/sound/soc/amd/Kconfig b/sound/soc/amd/Kconfig
new file mode 100644
index 000..ce39979
--- /dev/null
+++ b/sound/soc/amd/Kconfig
@@ -0,0 +1,5 @@
+config SND_SOC_AMD_ACP
+   tristate "AMD Audio Coprocessor support"
+   depends on MFD_CORE
+   help
+This option enables ACP support (DMA,I2S) on AMD platforms.
diff --git a/sound/soc/amd/Makefile b/sound/soc/amd/Makefile
new file mode 100644
index 000..1a66ec0
--- /dev/null
+++ b/sound/soc/amd/Makefile
@@ -0,0 +1,3 @@
+snd-soc-acp-pcm-objs   := acp-pcm-dma.o
+
+obj-$(CONFIG_SND_SOC_AMD_ACP) += snd-soc-acp-pcm.o
diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
new file mode 100644
index 000..18cc60c
--- /dev/null
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -0,0 +1,676 @@
+/*
+ * AMD ALSA SoC PCM Driver
+ *
+ * Copyright 2014-2015 Advanced Micro Devices, Inc.
+ *
+ * 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 PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#define PLAYBACK_MIN_NUM_PERIODS2
+#define PLAYBACK_MAX_NUM_PERIODS2
+#define PLAYBACK_MAX_PERIOD_SIZE16384
+#define PLAYBACK_MIN_PERIOD_SIZE1024
+#define CAPTURE_MIN_NUM_PERIODS 2
+#define CAPTURE_MAX_NUM_PERIODS 2
+#define CAPTURE_MAX_PERIOD_SIZE 16384
+#define CAPTURE_MIN_PERIOD_SIZE 1024
+
+#define NUM_DSCRS_PER_CHANNEL 2
+
+#define MAX_BUFFER (PLAYBACK_MAX_PERIOD_SIZE * PLAYBACK_MAX_NUM_PERIODS)
+#define MIN_BUFFER MAX_BUFFER
+
+#define TWO_CHANNEL_SUPPORT 2  /* up to 2.0 */
+#define FOUR_CHANNEL_SUPPORT4  /* up to 3.1 */
+#define SIX_CHANNEL_SUPPORT 6  /* up to 5.1 */
+#define EIGHT_CHANNEL_SUPPORT   8  /* up to 7.1 */
+
+
+static const struct snd_pcm_hardware acp_pcm_hardware_playback = {
+   .info = SNDRV_PCM_INFO_INTERLEAVED |
+   SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_MMAP |
+   SNDRV_PCM_INFO_MMAP_VALID | SNDRV_PCM_INFO_BATCH |
+   SNDRV_PCM_INFO_PAUSE | SNDRV_PCM_INFO_RESUME,
+   /* formats,rates,channels  based on i2s doc. */
+   .formats = SNDRV_PCM_FMTBIT_S16_LE |
+   SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S32_LE,
+   .channels_min = 1,
+

[PATCH 2/3] drm/amd: add ACP driver support [v6]

From: Maruthi Bayyavarapu 

This adds the ACP (Audio CoProcessor) IP driver and wires
it up to the amdgpu driver.  The ACP block provides the DMA
engine and bus for the i2s codec which is supported by an
alsa driver.  This is required for audio on APUs that
utilize an i2s codec.

v2: integrate i2s/az check patch
v3: s/amd_acp/amdgpu_acp/
v4: update copyright notice
v5: squash multiple patches, convert to mfd
v6: squash in dynamic cell allocation from Maruthi

Reviewed-by: Jammy Zhou 
Reviewed-by: Maruthi Bayyavarapu 
Reviewed-by: Alex Deucher 
Reviewed-by: Murali Krishna Vemuri 
Signed-off-by: Maruthi Bayyavarapu 
Signed-off-by: Chunming Zhou 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/Kconfig  |2 +
 drivers/gpu/drm/amd/acp/Kconfig  |   10 +
 drivers/gpu/drm/amd/acp/Makefile |9 +
 drivers/gpu/drm/amd/acp/acp_hw.c | 1133 ++
 drivers/gpu/drm/amd/acp/acp_hw.h |   91 +++
 drivers/gpu/drm/amd/acp/include/acp_gfx_if.h |   49 ++
 drivers/gpu/drm/amd/amdgpu/Makefile  |   13 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu.h  |5 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c  |  208 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_acp.h  |   40 +
 drivers/gpu/drm/amd/amdgpu/vi.c  |   12 +
 drivers/gpu/drm/amd/include/amd_shared.h |1 +
 include/linux/mfd/amd_acp.h  |  211 +
 13 files changed, 1783 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/amd/acp/Kconfig
 create mode 100644 drivers/gpu/drm/amd/acp/Makefile
 create mode 100644 drivers/gpu/drm/amd/acp/acp_hw.c
 create mode 100644 drivers/gpu/drm/amd/acp/acp_hw.h
 create mode 100644 drivers/gpu/drm/amd/acp/include/acp_gfx_if.h
 create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
 create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_acp.h
 create mode 100644 include/linux/mfd/amd_acp.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index df99b01..2e3df0e 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -161,6 +161,8 @@ config DRM_AMDGPU

 source "drivers/gpu/drm/amd/amdgpu/Kconfig"

+source "drivers/gpu/drm/amd/acp/Kconfig"
+
 source "drivers/gpu/drm/nouveau/Kconfig"

 config DRM_I810
diff --git a/drivers/gpu/drm/amd/acp/Kconfig b/drivers/gpu/drm/amd/acp/Kconfig
new file mode 100644
index 000..1de4fe7
--- /dev/null
+++ b/drivers/gpu/drm/amd/acp/Kconfig
@@ -0,0 +1,10 @@
+menu "ACP Configuration"
+
+config DRM_AMD_ACP
+   bool "Enable ACP IP support"
+   default y
+   depends on MFD_CORE
+   help
+   Choose this option to enable ACP IP support for AMD SOCs.
+
+endmenu
diff --git a/drivers/gpu/drm/amd/acp/Makefile b/drivers/gpu/drm/amd/acp/Makefile
new file mode 100644
index 000..c8c3303
--- /dev/null
+++ b/drivers/gpu/drm/amd/acp/Makefile
@@ -0,0 +1,9 @@
+#
+# Makefile for the ACP, which is a sub-component
+# of AMDSOC/AMDGPU drm driver.
+# It provides the HW control for ACP related functionalities.
+
+ccflags-y += -Idrivers/gpu/drm/amd/include/asic_reg/acp
+subdir-ccflags-y += -I$(AMDACPPATH)/ -I$(AMDACPPATH)/include
+
+AMD_ACP_FILES := $(AMDACPPATH)/acp_hw.o
diff --git a/drivers/gpu/drm/amd/acp/acp_hw.c b/drivers/gpu/drm/amd/acp/acp_hw.c
new file mode 100644
index 000..4178aa9
--- /dev/null
+++ b/drivers/gpu/drm/amd/acp/acp_hw.c
@@ -0,0 +1,1133 @@
+/*
+ * Copyright 2015 Advanced Micro Devices, Inc.
+ *
+ * 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 PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * NOTE:
+ * Certain pieces were reused from Synopsis I2S IP related code,
+ * which otherwise can also be found at:
+ * sound/soc/dwc/designware_i2s.c
+ *
+ * Copyright notice as appears in the above file:
+ *
+ * Copyright (C) 2010 ST Microelectronics
+ * Rajeev Kumar 
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ *

[PATCH 0/3] Add ASoC support for AMD APUs [v2]

This patch set implements support for i2s audio and new AMD GPUs.
The i2s codec is fed by a DMA engine on the GPU.  To handle this
we create an mfd cell which we can hang the i2s codec on.  Because
of this, this patch set covers two subsystems: drm and alsa.  The
drm patches add support for the ACP hw block which provides the DMA
engine for the i2s codec.  The alsa patches add the ASoC driver for
the i2s codec.  Since the alsa changes depend on the drm changes in
this patch set as well as some other drm changes queued for 4.3, I'd
like to take the alsa patches in via the drm tree.

V2 changes:
- Use the MFD subsystem rather than adding our own bus
- Squash all sub-feature patches together
- fix comments mentioned in previous review

There was a question about the code and the module licensing.
IANAL, but this follows the same pattern that most if not all
drm drivers use.

There was also a comment about the patch changelog.  I think this
is more of a subsystem preference kind of thing.  Generally in the
drm we include the patch changelog and versions in the commit
messages so we have a history of the patch if we need to reference
it in the future.  If you have a strong preference for the audio
patch, we can drop that.

Patch 1 adds the register headers for the ACP block which is a
pretty big patch so I've excluded it from email.  The entire patch
set can be viewed here:
http://cgit.freedesktop.org/~agd5f/linux/log/?h=acp-upstream2

Thanks,

Alex

Chunming Zhou (1):
  drm/amd: add ACP 2.x register headers

Maruthi Bayyavarapu (1):
  drm/amd: add ACP driver support [v6]

Maruthi Srinivas Bayyavarapu (1):
  ASoC: AMD: add AMD ASoC ACP-I2S driver [v4]

 drivers/gpu/drm/Kconfig|2 +
 drivers/gpu/drm/amd/acp/Kconfig|   10 +
 drivers/gpu/drm/amd/acp/Makefile   |9 +
 drivers/gpu/drm/amd/acp/acp_hw.c   | 1133 ++
 drivers/gpu/drm/amd/acp/acp_hw.h   |   91 +
 drivers/gpu/drm/amd/acp/include/acp_gfx_if.h   |   49 +
 drivers/gpu/drm/amd/amdgpu/Makefile|   13 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu.h|5 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c|  208 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_acp.h|   40 +
 drivers/gpu/drm/amd/amdgpu/vi.c|   12 +
 drivers/gpu/drm/amd/include/amd_shared.h   |1 +
 .../gpu/drm/amd/include/asic_reg/acp/acp_2_1_d.h   |  437 
 .../drm/amd/include/asic_reg/acp/acp_2_1_enum.h| 1198 ++
 .../drm/amd/include/asic_reg/acp/acp_2_1_sh_mask.h | 1568 +
 .../gpu/drm/amd/include/asic_reg/acp/acp_2_2_d.h   |  609 ++
 .../drm/amd/include/asic_reg/acp/acp_2_2_enum.h| 1068 +
 .../drm/amd/include/asic_reg/acp/acp_2_2_sh_mask.h | 2292 
 .../gpu/drm/amd/include/asic_reg/acp/acp_2_3_d.h   |  582 +
 .../drm/amd/include/asic_reg/acp/acp_2_3_enum.h| 1079 +
 .../drm/amd/include/asic_reg/acp/acp_2_3_sh_mask.h | 2192 +++
 include/linux/mfd/amd_acp.h|  211 ++
 sound/soc/Kconfig  |1 +
 sound/soc/Makefile |1 +
 sound/soc/amd/Kconfig  |5 +
 sound/soc/amd/Makefile |3 +
 sound/soc/amd/acp-pcm-dma.c|  676 ++
 27 files changed, 13494 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/amd/acp/Kconfig
 create mode 100644 drivers/gpu/drm/amd/acp/Makefile
 create mode 100644 drivers/gpu/drm/amd/acp/acp_hw.c
 create mode 100644 drivers/gpu/drm/amd/acp/acp_hw.h
 create mode 100644 drivers/gpu/drm/amd/acp/include/acp_gfx_if.h
 create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
 create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_acp.h
 create mode 100644 drivers/gpu/drm/amd/include/asic_reg/acp/acp_2_1_d.h
 create mode 100644 drivers/gpu/drm/amd/include/asic_reg/acp/acp_2_1_enum.h
 create mode 100644 drivers/gpu/drm/amd/include/asic_reg/acp/acp_2_1_sh_mask.h
 create mode 100644 drivers/gpu/drm/amd/include/asic_reg/acp/acp_2_2_d.h
 create mode 100644 drivers/gpu/drm/amd/include/asic_reg/acp/acp_2_2_enum.h
 create mode 100644 drivers/gpu/drm/amd/include/asic_reg/acp/acp_2_2_sh_mask.h
 create mode 100644 drivers/gpu/drm/amd/include/asic_reg/acp/acp_2_3_d.h
 create mode 100644 drivers/gpu/drm/amd/include/asic_reg/acp/acp_2_3_enum.h
 create mode 100644 drivers/gpu/drm/amd/include/asic_reg/acp/acp_2_3_sh_mask.h
 create mode 100644 include/linux/mfd/amd_acp.h
 create mode 100644 sound/soc/amd/Kconfig
 create mode 100644 sound/soc/amd/Makefile
 create mode 100644 sound/soc/amd/acp-pcm-dma.c

-- 
1.8.3.1

[PATCH v3 0/14] Add Analogix Core Display Port Driver

On 2015. 8. 20., at PM 3:23, Yakir Yang  wrote:
> 
> Hi Jingoo & Archit,
> 
> 
>> On 08/20/2015 12:54 AM, Jingoo Han wrote:
>>> On 2015. 8. 20., at PM 1:29, Archit Taneja  
>>> wrote:
>>> Hi,
>>> 
 On 08/19/2015 08:18 PM, Yakir Yang wrote:
 
 Hi all,
The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
 share the same IP, so a lot of parts can be re-used. I split the common
 code into bridge directory, then rk3288 and exynos only need to keep
 some platform code. Cause I can't find the exact IP name of exynos dp
 controller, so I decide to name dp core driver with "analogix" which I
 find in rk3288 eDP TRM ;)
 
 Beyond that, there are three light registers setting differents bewteen
 exynos and rk3288.
 1. RK3288 have five special pll resigters which not indicata in exynos
dp controller.
 2. The address of DP_PHY_PD(dp phy power manager register) are different
between rk3288 and exynos.
 3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug
register).
 
 I have verified this series on two kinds of rockchip platform board, one
 is rk3288 sdk board which connect with a 2K display port monitor, the other
 is google jerry chromebook which connect with a eDP screen 
 "cnm,n116bgeea2",
 both of them works rightlly.
 
 I haven't verified the dp function on samsung platform, cause I haven't got
 exynos boards. I can only ensure that there are no build error on samsung
 platform, wish some samsung guys help to test. ;)
 
 Thanks,
 - Yakir
 
 Changes in v3:
 - Take Thierry Reding suggest, move exynos's video_timing code
   to analogix_dp-exynos platform driver, add get_modes method
   to struct analogix_dp_plat_data.
 - Take Heiko suggest, rename some "samsung*" dts propery to "analogix*".
 - Take Thierry Reding suggest, dynamic parse video timing info from
   struct drm_display_mode and struct drm_display_info.
 - Take Thierry Reding suggest, link_rate and lane_count shouldn't config to
   the DT property value directly, but we can take those as hardware limite.
   For example, RK3288 only support 4 physical lanes of 2.7/1.62 Gbps/lane,
   so DT property would like "link-rate = 0x0a" "lane-count = 4".
 - Take Heiko suggest, add devicetree binding documents.
 - Take Thierry Reding suggest, remove sync pol & colorimetry properies
   from the new analogix dp driver devicetree binding.
 - Update the exist exynos dtsi file with the latest DP DT properies.
 - Take Thierry Reding and Heiko suggest, leave "sclk_edp_24m" to rockchip
   dp phy driver which name to "24m", and leave "sclk_edp" to analogix dp
   core driver which name to "dp", and leave "pclk_edp" to rockchip dp 
 platform
   driver which name to "pclk".
 - Take Heiko suggest, add devicetree binding document.
 - Take Heiko suggest, remove "rockchip,panel" DT property, take use of 
 remote
   point to get panel node.
 - Add the new function point analogix_dp_platdata.get_modes init.
 - Take Heiko suggest, add rockchip dp phy driver,
   collect the phy clocks and power control.
 - Add "analogix,need-force-hpd" to indicate whether driver need foce
   hpd when hpd detect failed.
 - move dp hpd detect to connector detect function.
 - Add edid modes parse support
 
 Changes in v2:
 - Take Joe Preches advise, improved commit message more readable, and
   avoid using some uncommon style like bellow:
   -  retval = exynos_dp_read_bytes_from_i2c(...
...)
   +  retval =
   +  exynos_dp_read_bytes_from_i2c(..);
 - Take Jingoo Han suggest, just remove my name from author list.
 - Take Jingoo Han suggest, remove new copyright
 - Fix compiled failed dut to analogix_dp_device misspell
 - Take Heiko suggest, get panel node with remote-endpoint method,
   and create devicetree binding for driver.
 - Remove the clock enable/disbale with "sclk_edp" & "sclk_edp_24m",
   leave those clock to rockchip dp phy driver.
 - Add GNU license v2 declared and samsung copyright
 - Fix compile failed dut to phy_pd_addr variable misspell error
 
 Yakir Yang (14):
   drm: exynos/dp: fix code style
   drm: exynos/dp: convert to drm bridge mode
   drm: bridge: analogix_dp: split exynos dp driver to bridge dir
   drm: bridge/analogix_dp: dynamic parse sync_pol & interlace &
 colorimetry
   drm: bridge/analogix_dp: fix link_rate & lane_count bug
   Documentation: drm/bridge: add document for analogix_dp
   drm: rockchip/dp: add rockchip platform dp driver
   phy: Add driver for rockchip Display Port PHY
   drm: bridge/analogix_dp: add platform device type support
   drm: bridge: analogix_dp: add some rk3288 special registers setting
   drm: bridge:

[PATCH 3/3] ASoC: AMD: add AMD ASoC ACP-I2S driver [v4]

On Thu, Aug 20, 2015 at 05:30:27PM -0400, Alex Deucher wrote:
> On Thu, Aug 20, 2015 at 5:13 PM, Mark Brown  wrote:

> >> v4: squash in naming fixes

> > To repeat what I said last time:

> > | Please follow the patch submission process in SubmittingPatches: put any
> > | versioning in the subject line inside the [] and put noise like inter
> > | version changelogs after the ---.

> I addressed this in my coverletter.  Some subsystems prefer to retain
> that information.  If you'd prefer to not have them in the audio patch
> I will remove them.

When I said to follow the standard process here that's what I meant,
yes.  It's basically just the graphics subsystem that does something
different here, and note that if you are going to include a changelog
(either in the normal place or the DRM place) it really ought to
actually describe the changes that have been made - the above doesn't
reflect the changes that were made at all.

> > I also remain very concerned about this non-GPL license you are using.
> > Please do not ignore review comments like this :(

> I mentioned this in the cover letter as well.  Most if not all of the
> drm drivers are licensed the same way.  IANAL, but I am not aware of
> any concerns about them.

DRM is a special case here since there has always been work to share
bits of the code with other operating systems, the licensing for DRM is
very unusual within the kernel.  A quick sampling of drivers suggests
that this license is not universally used there either.

There is also the issue I raised with the fact that your non-GPL license
statement does not appear to correspond to the MODULE_LICENSE() that
you've included which claims the code is GPLed.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150820/5050f3f4/attachment-0001.sig>

[PATCH v3 12/14] drm: bridge/analogix_dp: expand the delay time for hpd detect

On 2015. 8. 19., at PM 11:52, Yakir Yang  wrote:
> 
> Some edp screen with no hpd signal would need some delay time
> to ensure that screen would be ready for work, so we can expand
> the delay time in hpd detect function, it works prefectly on my
> rk3288 sdk board.

Then, this delay has a dependency on the "rk3288 sdk" board.
Also, if the delay time is expanded, the booting time of some Exybos boards 
will be increased unnecessarily. :-(

So, please add new DT property such as 'hpd-delay' that can be added to board 
DT files.

If there is not that DT property in DT files, the default value '10' will 
written to a variable such as 'unsigned int hpd_delay'.
If there is the DT property in DT files, the delay value will written to the 
variable when parsing DT values
and will be used in analogix_dp_detect_hpd().

What I want to say is that there should not be harmful effect on the existing 
Exynos boards, due to unrelated reasons.

Best regards,
Jingoo Han

> Signed-off-by: Yakir Yang 
> ---
> Changes in v3: None
> Changes in v2: None
> 
> drivers/gpu/drm/bridge/analogix_dp_core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/bridge/analogix_dp_core.c 
> b/drivers/gpu/drm/bridge/analogix_dp_core.c
> index 99870f7..75dd44a 100644
> --- a/drivers/gpu/drm/bridge/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix_dp_core.c
> @@ -68,7 +68,7 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device 
> *dp)
>return 0;
> 
>timeout_loop++;
> -usleep_range(10, 11);
> +usleep_range(100, 110);
>}
> 
>/*
> -- 
> 1.9.1
> 
>

[PATCH v3 0/14] Add Analogix Core Display Port Driver

On 2015. 8. 20., at PM 1:29, Archit Taneja  wrote:
> 
> Hi,
> 
>> On 08/19/2015 08:18 PM, Yakir Yang wrote:
>> 
>> Hi all,
>>The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
>> share the same IP, so a lot of parts can be re-used. I split the common
>> code into bridge directory, then rk3288 and exynos only need to keep
>> some platform code. Cause I can't find the exact IP name of exynos dp
>> controller, so I decide to name dp core driver with "analogix" which I
>> find in rk3288 eDP TRM ;)
>> 
>> Beyond that, there are three light registers setting differents bewteen
>> exynos and rk3288.
>> 1. RK3288 have five special pll resigters which not indicata in exynos
>>dp controller.
>> 2. The address of DP_PHY_PD(dp phy power manager register) are different
>>between rk3288 and exynos.
>> 3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug
>>register).
>> 
>> I have verified this series on two kinds of rockchip platform board, one
>> is rk3288 sdk board which connect with a 2K display port monitor, the other
>> is google jerry chromebook which connect with a eDP screen "cnm,n116bgeea2",
>> both of them works rightlly.
>> 
>> I haven't verified the dp function on samsung platform, cause I haven't got
>> exynos boards. I can only ensure that there are no build error on samsung
>> platform, wish some samsung guys help to test. ;)
>> 
>> Thanks,
>> - Yakir
>> 
>> Changes in v3:
>> - Take Thierry Reding suggest, move exynos's video_timing code
>>   to analogix_dp-exynos platform driver, add get_modes method
>>   to struct analogix_dp_plat_data.
>> - Take Heiko suggest, rename some "samsung*" dts propery to "analogix*".
>> - Take Thierry Reding suggest, dynamic parse video timing info from
>>   struct drm_display_mode and struct drm_display_info.
>> - Take Thierry Reding suggest, link_rate and lane_count shouldn't config to
>>   the DT property value directly, but we can take those as hardware limite.
>>   For example, RK3288 only support 4 physical lanes of 2.7/1.62 Gbps/lane,
>>   so DT property would like "link-rate = 0x0a" "lane-count = 4".
>> - Take Heiko suggest, add devicetree binding documents.
>> - Take Thierry Reding suggest, remove sync pol & colorimetry properies
>>   from the new analogix dp driver devicetree binding.
>> - Update the exist exynos dtsi file with the latest DP DT properies.
>> - Take Thierry Reding and Heiko suggest, leave "sclk_edp_24m" to rockchip
>>   dp phy driver which name to "24m", and leave "sclk_edp" to analogix dp
>>   core driver which name to "dp", and leave "pclk_edp" to rockchip dp 
>> platform
>>   driver which name to "pclk".
>> - Take Heiko suggest, add devicetree binding document.
>> - Take Heiko suggest, remove "rockchip,panel" DT property, take use of remote
>>   point to get panel node.
>> - Add the new function point analogix_dp_platdata.get_modes init.
>> - Take Heiko suggest, add rockchip dp phy driver,
>>   collect the phy clocks and power control.
>> - Add "analogix,need-force-hpd" to indicate whether driver need foce
>>   hpd when hpd detect failed.
>> - move dp hpd detect to connector detect function.
>> - Add edid modes parse support
>> 
>> Changes in v2:
>> - Take Joe Preches advise, improved commit message more readable, and
>>   avoid using some uncommon style like bellow:
>>   -  retval = exynos_dp_read_bytes_from_i2c(...
>>...)
>>   +  retval =
>>   +  exynos_dp_read_bytes_from_i2c(..);
>> - Take Jingoo Han suggest, just remove my name from author list.
>> - Take Jingoo Han suggest, remove new copyright
>> - Fix compiled failed dut to analogix_dp_device misspell
>> - Take Heiko suggest, get panel node with remote-endpoint method,
>>   and create devicetree binding for driver.
>> - Remove the clock enable/disbale with "sclk_edp" & "sclk_edp_24m",
>>   leave those clock to rockchip dp phy driver.
>> - Add GNU license v2 declared and samsung copyright
>> - Fix compile failed dut to phy_pd_addr variable misspell error
>> 
>> Yakir Yang (14):
>>   drm: exynos/dp: fix code style
>>   drm: exynos/dp: convert to drm bridge mode
>>   drm: bridge: analogix_dp: split exynos dp driver to bridge dir
>>   drm: bridge/analogix_dp: dynamic parse sync_pol & interlace &
>> colorimetry
>>   drm: bridge/analogix_dp: fix link_rate & lane_count bug
>>   Documentation: drm/bridge: add document for analogix_dp
>>   drm: rockchip/dp: add rockchip platform dp driver
>>   phy: Add driver for rockchip Display Port PHY
>>   drm: bridge/analogix_dp: add platform device type support
>>   drm: bridge: analogix_dp: add some rk3288 special registers setting
>>   drm: bridge: analogix_dp: try force hpd after plug in lookup failed
>>   drm: bridge/analogix_dp: expand the delay time for hpd detect
>>   drm: bridge/analogix_dp: move hpd detect to connector detect function
>>   drm: bridge/analogix_dp: add edid modes parse in get_modes method
>> 
>>  .../devicetree/bindings/drm/bridge/analogix_dp.txt |   73 +

[PATCH 3/3] ASoC: AMD: add AMD ASoC ACP-I2S driver [v4]

On Thu, Aug 20, 2015 at 04:09:21PM -0400, Alex Deucher wrote:
> From: Maruthi Srinivas Bayyavarapu 
> 
> ACP IP block consists of dedicated DMA and I2S blocks. The PCM driver
> provides the DMA and CPU DAI components to ALSA core.
> 
> v2: squash in Kconfig fix
> v3: squash additional commits, convert to mfd, drop rt286 changes
> v4: squash in naming fixes

To repeat what I said last time:

| Please follow the patch submission process in SubmittingPatches: put any
| versioning in the subject line inside the [] and put noise like inter
| version changelogs after the ---.

> +/*
> + * AMD ALSA SoC PCM Driver
> + *
> + * Copyright 2014-2015 Advanced Micro Devices, Inc.
> + *
> + * 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 PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
> + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.

I also remain very concerned about this non-GPL license you are using.
Please do not ignore review comments like this :(
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150820/d783c843/attachment.sig>

[PATCH v2] drm/qxl: validate monitors config modes

2015-08-20 Thread Jonathon Jongsma

Due to some recent changes in
drm_helper_probe_single_connector_modes_merge_bits(), old custom modes
were not being pruned properly. In current kernels,
drm_mode_validate_basic() is called to sanity-check each mode in the
list. If the sanity-check passes, the mode's status gets set to to
MODE_OK. In older kernels this check was not done, so old custom modes
would still have a status of MODE_UNVERIFIED at this point, and would
therefore be pruned later in the function.

As a result of this new behavior, the list of modes for a device always
includes every custom mode ever configured for the device, with the
largest one listed first. Since desktop environments usually choose the
first preferred mode when a hotplug event is emitted, this had the
result of making it very difficult for the user to reduce the size of
the display.

The qxl driver did implement the mode_valid connector function, but it
was empty. In order to restore the old behavior where old custom modes
are pruned, we implement a proper mode_valid function for the qxl
driver. This function now checks each mode against the last configured
custom mode and the list of standard modes. If the mode doesn't match
any of these, its status is set to MODE_BAD so that it will be pruned as
expected.

Signed-off-by: Jonathon Jongsma 
Cc: stable at vger.kernel.org
---

Changes from v1:
- add signed-off-by
- cc stable

 drivers/gpu/drm/qxl/qxl_display.c | 66 ---
 drivers/gpu/drm/qxl/qxl_drv.h |  2 ++
 2 files changed, 42 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index a8dbb3e..7c6225c 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -160,9 +160,35 @@ static int qxl_add_monitors_config_modes(struct 
drm_connector *connector,
*pwidth = head->width;
*pheight = head->height;
drm_mode_probed_add(connector, mode);
+   /* remember the last custom size for mode validation */
+   qdev->monitors_config_width = mode->hdisplay;
+   qdev->monitors_config_height = mode->vdisplay;
return 1;
 }

+static struct mode_size {
+   int w;
+   int h;
+} common_modes[] = {
+   { 640,  480},
+   { 720,  480},
+   { 800,  600},
+   { 848,  480},
+   {1024,  768},
+   {1152,  768},
+   {1280,  720},
+   {1280,  800},
+   {1280,  854},
+   {1280,  960},
+   {1280, 1024},
+   {1440,  900},
+   {1400, 1050},
+   {1680, 1050},
+   {1600, 1200},
+   {1920, 1080},
+   {1920, 1200}
+};
+
 static int qxl_add_common_modes(struct drm_connector *connector,
 unsigned pwidth,
 unsigned pheight)
@@ -170,29 +196,6 @@ static int qxl_add_common_modes(struct drm_connector 
*connector,
struct drm_device *dev = connector->dev;
struct drm_display_mode *mode = NULL;
int i;
-   struct mode_size {
-   int w;
-   int h;
-   } common_modes[] = {
-   { 640,  480},
-   { 720,  480},
-   { 800,  600},
-   { 848,  480},
-   {1024,  768},
-   {1152,  768},
-   {1280,  720},
-   {1280,  800},
-   {1280,  854},
-   {1280,  960},
-   {1280, 1024},
-   {1440,  900},
-   {1400, 1050},
-   {1680, 1050},
-   {1600, 1200},
-   {1920, 1080},
-   {1920, 1200}
-   };
-
for (i = 0; i < ARRAY_SIZE(common_modes); i++) {
mode = drm_cvt_mode(dev, common_modes[i].w, common_modes[i].h,
60, false, false, false);
@@ -823,11 +826,22 @@ static int qxl_conn_get_modes(struct drm_connector 
*connector)
 static int qxl_conn_mode_valid(struct drm_connector *connector,
   struct drm_display_mode *mode)
 {
+   struct drm_device *ddev = connector->dev;
+   struct qxl_device *qdev = ddev->dev_private;
+   int i;
+
/* TODO: is this called for user defined modes? (xrandr --add-mode)
 * TODO: check that the mode fits in the framebuffer */
-   DRM_DEBUG("%s: %dx%d status=%d\n", mode->name, mode->hdisplay,
- mode->vdisplay, mode->status);
-   return MODE_OK;
+
+   if(qdev->monitors_config_width == mode->hdisplay &&
+  qdev->monitors_config_height == mode->vdisplay)
+   return MODE_OK;
+
+   for (i = 0; i < ARRAY_SIZE(common_modes); i++) {
+   if (common_modes[i].w == mode->hdisplay && common_modes[i].h == 
mode->vdisplay)
+   return MODE_OK;
+   }
+   return MODE_BAD;
 }

 static struct drm_encoder *qxl_best_encoder(struct drm_connector *connector)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
index d854969..01a8694 100644
---

[RFC 0/2] drm/dsi: DSI for devices with different control bus

2015-08-20 Thread Thierry Reding

e is still addressable from the DSI
> >host controller, if for nothing else than for routing the video stream.
> >
> >>>>If you need to model connections between devices that are not reflected
> >>>>through the control bus hierarchy you should really consider using the
> >>>>standardized of-graph bindings.
> >>>>(Documentation/devicetree/bindings/graph.txt)
> >>>
> >>>The problem is that the original proposal would instantiate a dummy
> >>>device, so it wouldn't be represented in DT at all. So unless you do add
> >>>two logical devices to DT (one for each bus interface), you don't have
> >>>anything to glue together with an OF graph.
> >>>
> >>I see that the having dummy device is the least desirable solution. But
> >>if there is only one control bus to the device I think it should be one
> >>device sitting beneath the control bus.
> >>
> >>You can then use of-graph to model the data path between the DSI encoder
> >>and device.
> >
> >But you will be needing a device below the DSI host controller to
> >represent that endpoint of the connection. The DSI host controller
> >itself is in no way connected to the I2C adapter. You would have to
> >add some sort of quirk to the DSI controller binding to allow it to
> 
> Thanks for the review.
> 
> I implemented this to support ADV7533 DSI to HDMI encoder chip, which
> has a DSI video bus and an i2c control bus.
> 
> There weren't any quirks as such in the device tree when I tried to
> implement this. The DT seems to manage fine without a node
> corresponding to a mipi_dsi_device:
> 
> i2c_adap at .. {
>   adv7533 at .. {
> 
>   port {
>   adv_in: endpoint {
>   remote-endpoint = <_out>;
>   };
>   };
>   };
> };
> 
> dsi_host at .. {
>   ...
>   ...
> 
>   port {
>   dsi_out: endpoint {
>   remote-endpoint = <_in>;
>   }
>   };
> };
> 
> It's the i2c driver's job to parse the graph and retrieve the
> phandle to the dsi host. Using this, it can proceed with
> registering itself to this host using the new dsi funcs. This
> patch does the same for the adv7533 i2c driver:
> 
> http://www.spinics.net/lists/dri-devel/msg86840.html
> 
> >hook up with a control endpoint. And then you'll need more quirks
> >to describe what kind of DSI device this is.
> 
> Could you explain what you meant by this? I.e. describing the kind
> of DSI device?

Describing the number of lanes, specifying the virtual channel, mode
flags, etc. You could probably set the number of lanes and mode flags
via the I2C driver, but especially the virtual channel cannot be set
because it isn't known to the I2C DT branch of the device.

> The dsi device created isn't really a dummy device as such. It's
> dummy in the sense that there isn't a real dsi driver associated
> with it. The dsi device is still used to attach to a mipi dsi host,
> the way normal dsi devices do.

I understand, but I don't see why it has to be instantiated by the I2C
driver, that's what I find backwards. There is already a standard way
for instantiating DSI devices, why not use it?

> >On the other hand if you properly instantiate the DSI device you can
> >easily write a driver for it, and the driver will set up the correct
> >properties as implied by the compatible string. Once you have that you
> >can easily hook it up to the I2C control interface in whatever way you
> >like, be that an OF graph or just a simple unidirectional link by
> >phandle.
> >
> 
> With the fused approach you suggested, we would have 2 drivers: one i2c
> and the other dsi. The i2c client driver would be more or less minimal,
> preparing an i2c_client device for the dsi driver to use. Is my
> understanding correct?

Correct. That's kind of similar to the way an HDMI encoder driver would
use an I2C adapter to query EDID. The i2c_client device would be a means
for the DSI driver to access the control interface.

> We can do without dummy dsi devices with this method. But, representing
> a device with 2 DT nodes seems a bit off. We'd also need to compatible
> strings for the same device, one for the i2c part, and the other for
> the dsi part.

I agree that this somewhat stretches the capabilities of device tree.
Another alternative I guess would be to not have a compatible string for
the I2C device at all (that's technically not valid, I guess) because we
really don't need an I2C driver for the device. What we really need is a
DSI driver with a means to talk over some I2C bus with some other part
of its device.

> From an adv75xx driver perspective, it should also support the ADV7511
> chip, which is a RGB/DPI to HDMI encoder. For adv7511, we don't need a
> DSI DT node. It would be a bit inconsistent to have the bindings
> require both DSI and I2C nodes for one chip, and only I2C node for the
> other, with both chips being supported by the same driver.

Why would that be inconsistent? That sounds like the most accurate
representation of the hardware to me.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150820/ffa63d2d/attachment.sig>

[Bug 91588] [LLVM] (bisected) Unigine Valley: High + AA = incorrect rendering

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

Kai  changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED

--- Comment #8 from Kai  ---
I can confirm, that this bug is gone with a stack including a LLVM build of SVN
revision 245329 or later.

My current stack (Debian testing as a base):
GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1)
Mesa: Git:master/f6c622f584
libdrm: 2.4.63-1
LLVM: SVN:trunk/r245487 (3.8 devel)
X.Org: 2:1.17.2-1.1
Linux: 4.1.6
Firmware: <https://secure.freedesktop.org/~agd5f/radeon_ucode/hawaii/>
> 286640da3d90d7b51bdb038b65addc47  hawaii_ce.bin
> 161105a73f7dfb2fca513327491c32d6  hawaii_mc.bin
> d6195059ea724981c9acd3abd6ee5166  hawaii_me.bin
> ad511d31a4fe3147c8d80b8f6770b8d5  hawaii_mec.bin
> 63eae3f33c77aadbc6ed1a09a2aed81e  hawaii_pfp.bin
> 5b72c73acf0cbd0cbb639302f65bc7dc  hawaii_rlc.bin
> f00de91c24b3520197e1ddb85d99c34a  hawaii_sdma1.bin
> 8e16f749d62b150d0d1f580d71bc4348  hawaii_sdma.bin
> 7b6ca5302b56bd35bf52804919d57e63  hawaii_smc.bin
> 9f2ba7e720e2af4d7605a9a4fd903513  hawaii_uvd.bin
> b0f2a043e72fbf265b2f858b8ddbdb09  hawaii_vce.bin
libclc: Git:master/7958b0202b
DDX: Git:master/b6d871bf29

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150820/47c780b1/attachment.html>

[PATCH v3 10/24] drm/omap: Use new drm_fb_helper functions

2015-08-20 Thread Tomi Valkeinen


On 31/07/15 13:51, Archit Taneja wrote:
> Use the newly created wrapper drm_fb_helper functions instead of calling
> core fbdev functions directly. They also simplify the fb_info creation.
> 
> v3:
> - Update error handling for new drm_fb_helper funcs. Check using IS_ERR()
>   instead of checking for NULL.
> 
> Reported-by: Dan Carpenter 
> 
> v2:
> - No changes
> 
> Cc: Tomi Valkeinen 
> Cc: Laurent Pinchart 
> 
> Signed-off-by: Archit Taneja 
> ---
>  drivers/gpu/drm/omapdrm/omap_fbdev.c | 38 
> 
>  1 file changed, 13 insertions(+), 25 deletions(-)

Acked-by: Tomi Valkeinen 

 Tomi

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150820/5e4a5cae/attachment-0001.sig>

[PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT

2015-08-20 Thread Eric B Munson

On Thu, 20 Aug 2015, Michal Hocko wrote:

> On Wed 19-08-15 17:33:45, Eric B Munson wrote:
> [...]
> > The group which asked for this feature here
> > wants the ability to distinguish between LOCKED and LOCKONFAULT regions
> > and without the VMA flag there isn't a way to do that.
> 
> Could you be more specific on why this is needed?

They want to keep metrics on the amount of memory used in a LOCKONFAULT
region versus the address space of the region.

> 
> > Do we know that these last two open flags are needed right now or is
> > this speculation that they will be and that none of the other VMA flags
> > can be reclaimed?
> 
> I do not think they are needed by anybody right now but that is not a
> reason why it should be used without a really strong justification.
> If the discoverability is really needed then fair enough but I haven't
> seen any justification for that yet.

To be completely clear you believe that if the metrics collection is
not a strong enough justification, it is better to expand the mm_struct
by another unsigned long than to use one of these bits right?

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150820/28fda8d8/attachment-0001.sig>

amdgpu 32-bit arm warnings

2015-08-20 Thread Michel Dänzer

On 20.08.2015 08:50, Dave Airlie wrote:
>   CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.o
> /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:
> In function âamdgpu_cs_parser_initâ:
> /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:211:21:
> warning: cast to pointer from integer of different size
> [-Wint-to-pointer-cast]
>   chunk_array_user = (uint64_t __user *)(cs->in.chunks);
>  ^
> /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:231:15:
> warning: cast to pointer from integer of different size
> [-Wint-to-pointer-cast]
>chunk_ptr = (void __user *)chunk_array[i];
>^
> /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:241:11:
> warning: cast to pointer from integer of different size
> [-Wint-to-pointer-cast]
>cdata = (void __user *)user_chunk.chunk_data;
>^

Looks like the (unsigned long) casts removed by commit e60b344f
("drm/amdgpu: optimize amdgpu_parser_init") need to stay.


-- 
Earthling Michel DÃ¤nzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

[PATCH] drm/tilcdc: panel: Add tilcdc- prefix to driver name

2015-08-20 Thread Tomi Valkeinen


On 29/07/15 13:12, Thierry Reding wrote:
> From: Thierry Reding 
> 
> The current driver name, "panel", is very generic. This causes problems
> when the driver is enabled on non-TI device tree platforms if the panel
> node is called "panel". This causes the driver name match fall-back in
> platform_match() to succeed, even if some other driver would precisely
> match using the OF device ID table, for example.
> 
> Currently there don't seem to be any in-tree users that rely on the
> driver name match, so adding the prefix should be safe.
> 
> Signed-off-by: Thierry Reding 
> ---
>  drivers/gpu/drm/tilcdc/tilcdc_panel.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
> index 7a0315855e90..375505caf9c7 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
> @@ -460,7 +460,7 @@ struct platform_driver panel_driver = {
>   .remove = panel_remove,
>   .driver = {
>   .owner = THIS_MODULE,
> - .name = "panel",
> + .name = "tilcdc-panel",
>   .of_match_table = panel_of_match,
>   },
>  };

I didn't know we do matching based on the node name also...

This looks fine, I believe the tilcdc is only used with DT based
systems. I'll pick this up.

 Tomi

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150820/2d958dbf/attachment.sig>

[PATCH 2/2] drm/exynos: implement atomic_{begin/flush} of FIMD and DECON

2015-08-20 Thread Hyungwon Hwang

Each CRTC's atomic_{begin/flush} must stop/start the update of shadow
registers to active register in the functions. This patch achieves these
purpose by moving the setting of protection bits to those functions from
{fimd/decon}_update_plane.

Signed-off-by: Hyungwon Hwang 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 47 +---
 drivers/gpu/drm/exynos/exynos7_drm_decon.c| 47 
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 51 ++-
 3 files changed, 103 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 484e312..fef0333 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -31,6 +31,7 @@ struct decon_context {
struct drm_device   *drm_dev;
struct exynos_drm_crtc  *crtc;
struct exynos_drm_plane planes[WINDOWS_NR];
+   unsigned intupdated_plane;
void __iomem*addr;
struct clk  *clks[6];
unsigned intdefault_win;
@@ -204,17 +205,17 @@ static void decon_win_set_pixfmt(struct decon_context 
*ctx, unsigned int win,
writel(val, ctx->addr + DECON_WINCONx(win));
 }

-static void decon_shadow_protect_win(struct decon_context *ctx, int win,
-   bool protect)
+static void decon_shadow_protect_win(struct decon_context *ctx,
+   unsigned int win_bits, bool protect)
 {
u32 val;

val = readl(ctx->addr + DECON_SHADOWCON);

if (protect)
-   val |= SHADOWCON_Wx_PROTECT(win);
+   val |= win_bits;
else
-   val &= ~SHADOWCON_Wx_PROTECT(win);
+   val &= ~win_bits;

writel(val, ctx->addr + DECON_SHADOWCON);
 }
@@ -232,8 +233,6 @@ static void decon_update_plane(struct exynos_drm_crtc *crtc,
if (ctx->suspended)
return;

-   decon_shadow_protect_win(ctx, win, true);
-
val = COORDINATE_X(plane->crtc_x) | COORDINATE_Y(plane->crtc_y);
writel(val, ctx->addr + DECON_VIDOSDxA(win));

@@ -265,15 +264,12 @@ static void decon_update_plane(struct exynos_drm_crtc 
*crtc,
val |= WINCONx_ENWIN_F;
writel(val, ctx->addr + DECON_WINCONx(win));

-   decon_shadow_protect_win(ctx, win, false);
-
/* standalone update */
val = readl(ctx->addr + DECON_UPDATE);
val |= STANDALONE_UPDATE_F;
writel(val, ctx->addr + DECON_UPDATE);

-   if (ctx->i80_if)
-   atomic_set(>win_updated, 1);
+   ctx->updated_plane |= SHADOWCON_Wx_PROTECT(win);
 }

 static void decon_disable_plane(struct exynos_drm_crtc *crtc,
@@ -286,14 +282,14 @@ static void decon_disable_plane(struct exynos_drm_crtc 
*crtc,
if (ctx->suspended)
return;

-   decon_shadow_protect_win(ctx, win, true);
+   decon_shadow_protect_win(ctx, SHADOWCON_Wx_PROTECT(win), true);

/* window disable */
val = readl(ctx->addr + DECON_WINCONx(win));
val &= ~WINCONx_ENWIN_F;
writel(val, ctx->addr + DECON_WINCONx(win));

-   decon_shadow_protect_win(ctx, win, false);
+   decon_shadow_protect_win(ctx, SHADOWCON_Wx_PROTECT(win), false);

/* standalone update */
val = readl(ctx->addr + DECON_UPDATE);
@@ -405,6 +401,31 @@ void decon_te_irq_handler(struct exynos_drm_crtc *crtc)
drm_crtc_handle_vblank(>crtc->base);
 }

+static void decon_begin(struct exynos_drm_crtc *crtc)
+{
+   struct decon_context *ctx = crtc->ctx;
+   int i;
+   unsigned int val = 0;
+
+   for (i = 0; i < WINDOWS_NR; i++)
+   val |= SHADOWCON_Wx_PROTECT(i);
+
+   /* protect windows */
+   decon_shadow_protect_win(ctx, val, true);
+}
+
+static void decon_flush(struct exynos_drm_crtc *crtc)
+{
+   struct decon_context *ctx = crtc->ctx;
+
+   if (ctx->updated_plane) {
+   decon_shadow_protect_win(ctx, ctx->updated_plane, false);
+
+   if (ctx->i80_if)
+   atomic_set(>win_updated, 1);
+   }
+}
+
 static void decon_clear_channels(struct exynos_drm_crtc *crtc)
 {
struct decon_context *ctx = crtc->ctx;
@@ -458,6 +479,8 @@ static struct exynos_drm_crtc_ops decon_crtc_ops = {
.update_plane   = decon_update_plane,
.disable_plane  = decon_disable_plane,
.te_handler = decon_te_irq_handler,
+   .atomic_begin   = decon_begin,
+   .atomic_flush   = decon_flush,
 };

 static int decon_bind(struct device *dev, struct device *master, void *data)
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 0792654..c81de86 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++

[PATCH 1/2] drm/exynos: implement exynos_crtc_atomic_{begin/flush}

2015-08-20 Thread Hyungwon Hwang

All chagnes in CRTCs of Exynos are applied in H/W, only when the protection
for shadow register update is not enabled. Using these protection, every
change can be applied at once. Now exynos_crtc_atomic_{begin/flush} stops
or starts the update of shadow registers by calling each CRTC specific
atomic_{begin/flush}.

Signed-off-by: Hyungwon Hwang 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c | 7 +++
 drivers/gpu/drm/exynos/exynos_drm_drv.h  | 6 ++
 2 files changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index c478997..0201b54 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -88,11 +88,18 @@ static void exynos_crtc_atomic_begin(struct drm_crtc *crtc,
WARN_ON(drm_crtc_vblank_get(crtc) != 0);
exynos_crtc->event = crtc->state->event;
}
+
+   if (exynos_crtc->ops->atomic_begin)
+   exynos_crtc->ops->atomic_begin(exynos_crtc);
 }

 static void exynos_crtc_atomic_flush(struct drm_crtc *crtc,
 struct drm_crtc_state *old_crtc_state)
 {
+   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
+
+   if (exynos_crtc->ops->atomic_flush)
+   exynos_crtc->ops->atomic_flush(exynos_crtc);
 }

 static struct drm_crtc_helper_funcs exynos_crtc_helper_funcs = {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 6b8a30f..887922d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -95,6 +95,10 @@ struct exynos_drm_plane {
  * called from exynos-dp driver before powering up (with
  * 'enable' argument as true) and after powering down (with
  * 'enable' as false).
+ * @atomic_begin: stop the changes in the CRTC shadow registers to being
+ * updated the CRTC active registers
+ * @atomic_flush: start the changes in the CRTC shadow registers to being
+ * updated the CRTC active registers
  */
 struct exynos_drm_crtc;
 struct exynos_drm_crtc_ops {
@@ -113,6 +117,8 @@ struct exynos_drm_crtc_ops {
  struct exynos_drm_plane *plane);
void (*te_handler)(struct exynos_drm_crtc *crtc);
void (*clock_enable)(struct exynos_drm_crtc *crtc, bool enable);
+   void (*atomic_begin)(struct exynos_drm_crtc *crtc);
+   void (*atomic_flush)(struct exynos_drm_crtc *crtc);
 };

 /*
-- 
2.4.3

[PULL] drm-intel-fixes

2015-08-20 Thread Jani Nikula


Hi Dave, one more batch of i915 fixes for v4.2.

Revert of a VBT parsing commit that should've been queued for drm-next,
not v4.2. The revert unbreaks Braswell among other things.

Also on Braswell removal of DP HBR2/TP3 and intermediate eDP frequency
support. The code was optimistically added based on incorrect
documentation; the platform does not support them. These are cc: stable.

Finally a gpu state fix from Chris, also cc: stable.

BR,
Jani.

The following changes since commit d2944cf21305c754fa8b2d6c1eea05ad5dad7944:

  drm/i915: Commit planes on each crtc separately. (2015-08-13 12:09:18 +0300)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2015-08-20

for you to fetch changes up to ed63baaf849e91c84ac3e042b1fd6a0af07c16f3:

  drm/i915: Avoid TP3 on CHV (2015-08-19 11:13:59 +0300)


Chris Wilson (1):
  drm/i915: Flag the execlists context object as dirty after every use

Jani Nikula (1):
  Revert "drm/i915: Allow parsing of variable size child device entries 
from VBT"

Thulasimani,Sivakumar (3):
  Revert "drm/i915: Add eDP intermediate frequencies for CHV"
  drm/i915: remove HBR2 from chv supported list
  drm/i915: Avoid TP3 on CHV

 drivers/gpu/drm/i915/intel_bios.c | 27 ---
 drivers/gpu/drm/i915/intel_dp.c   | 35 ++-
 drivers/gpu/drm/i915/intel_lrc.c  |  2 ++
 3 files changed, 28 insertions(+), 36 deletions(-)

-- 
Jani Nikula, Intel Open Source Technology Center

about mmap dma-buf and sync

2015-08-20 Thread Jerome Glisse

On Thu, Aug 20, 2015 at 08:48:23AM +0200, Thomas Hellstrom wrote:
> Hi, Tiago!
> 
> On 08/20/2015 12:33 AM, Tiago Vignatti wrote:
> > Hey Thomas, you haven't answered my email about making SYNC_* mandatory:
> >
> > http://lists.freedesktop.org/archives/dri-devel/2015-August/088376.html
> 
> Hmm, for some reason it doesn't show up in my mail app, but I found it
> in the archives. An attempt to explain the situation from the vmwgfx
> perspective.
> 
> The fact that the interface is generic means that people will start
> using it for the zero-copy case. There has been a couple of more or less
> hackish attempts to do this before, and if it's a _driver_ interface we
> don't need to be that careful but if it is a _generic_ interface we need
> to be very careful to make it fit *all* the hardware out there and that
> we make all potential users use the interface in a way that conforms
> with the interface specification.
> 
> What will happen otherwise is that apps written for coherent fast
> hardware might, for example, ignore calling the SYNC api, just because
> the app writer only cared about his own hardware on which the app works
> fine. That would fail miserably if the same app was run on incoherent
> hardware, or the incoherent hardware driver maintainers would be forced
> to base an implementation on page-faults which would be very slow.
> 
> So assume the following use case: An app updates a 10x10 area using the
> CPU on a 1600x1200 dma-buf, and it will then use the dma-buf for
> texturing. On some hardware the dma-buf might be tiled in a very
> specific way, on vmwgfx the dma-buf is a GPU buffer on the host, only
> accessible using DMA. On vmwgfx the SYNC operation must carry out a
> 10x10 DMA from the host GPU buffer to a guest CPU buffer before the CPU
> write and a DMA back again after the write, before GPU usage. On the
> tiled architecture the SYNC operation must untile before CPU access and
> probably tile again before GPU access.
> 
> If we now have a one-dimensional SYNC api, in this particular case we'd
> either need to sync a far too large area (1600x10) or call SYNC 10 times
> before writing, and then again after writing. If the app forgot to call
> SYNC we must error.
> 
> So to summarize, the fact that the interface is generic IMO means:
> 
> 1) Any user must be able to make valid assumptions about the internal
> format of the dma-buf. (untiled, color format, stride etc.)
> 2) Any user *must* call SYNC before and after CPU access. On coherent
> architectures, the SYNC is a NULL operation anyway, and that should be
> documented somewhere so that maintainers of drivers of uncoherent
> architectures have somewhere to point their fingers.
> 3) Driver-specific implementations must be allowed to error (segfault)
> if SYNC has not been used.

I think here you are too lax, the common code must segfault or
error badly if SYNC has not been use in all cases even on cache
coherent arch. The device driver sync callback can still be a
no operation. But i think that we need to insist strongly on a
proper sync call being made (and we should forbid empty area
sync call). This would be the only way to make sure userspace
behave properly as otherwise we endup in the situation you were
describing above, where the app is design on a cache coherent
arch and works fine there but broke in subtle way on non cache
coherent arch and app developer is clueless of why.

I just do not trust userspace.

> 4) The use-case stated above clearly shows the benefit of a
> 2-dimensional sync interface (we want to sync the 10x10 region), but
> what if someone in the future wants to use this interface for a 3D
> texture? Will a 2D sync suffice? Can we make the SYNC interface
> extendable in a way that an enum sync_type member defines the layout of
> the argument, and initially we implement only 1d, 2d sync, leaving 3d
> for the future?
> 
> Also, I agree there is probably no good way to generically implement an
> error if SYNC has not been called. That needs to be left as an option to
> drivers.

I think there is, just forbid any further use of the dma buffer, mark
it as invalid and printk a big error. Userspace app developer will
quickly see that something is wrong and looking at kernel log should
explain why.

Cheers,
JÃ©rÃ´me

about mmap dma-buf and sync

2015-08-20 Thread Rob Clark

On Thu, Aug 20, 2015 at 2:48 AM, Thomas Hellstrom  
wrote:
> Hi, Tiago!
>
> On 08/20/2015 12:33 AM, Tiago Vignatti wrote:
>> Hey Thomas, you haven't answered my email about making SYNC_* mandatory:
>>
>> http://lists.freedesktop.org/archives/dri-devel/2015-August/088376.html
>
> Hmm, for some reason it doesn't show up in my mail app, but I found it
> in the archives. An attempt to explain the situation from the vmwgfx
> perspective.
>
> The fact that the interface is generic means that people will start
> using it for the zero-copy case. There has been a couple of more or less
> hackish attempts to do this before, and if it's a _driver_ interface we
> don't need to be that careful but if it is a _generic_ interface we need
> to be very careful to make it fit *all* the hardware out there and that
> we make all potential users use the interface in a way that conforms
> with the interface specification.
>
> What will happen otherwise is that apps written for coherent fast
> hardware might, for example, ignore calling the SYNC api, just because
> the app writer only cared about his own hardware on which the app works
> fine. That would fail miserably if the same app was run on incoherent
> hardware, or the incoherent hardware driver maintainers would be forced
> to base an implementation on page-faults which would be very slow.
>
> So assume the following use case: An app updates a 10x10 area using the
> CPU on a 1600x1200 dma-buf, and it will then use the dma-buf for
> texturing. On some hardware the dma-buf might be tiled in a very
> specific way, on vmwgfx the dma-buf is a GPU buffer on the host, only
> accessible using DMA. On vmwgfx the SYNC operation must carry out a
> 10x10 DMA from the host GPU buffer to a guest CPU buffer before the CPU
> write and a DMA back again after the write, before GPU usage. On the
> tiled architecture the SYNC operation must untile before CPU access and
> probably tile again before GPU access.
>
> If we now have a one-dimensional SYNC api, in this particular case we'd
> either need to sync a far too large area (1600x10) or call SYNC 10 times
> before writing, and then again after writing. If the app forgot to call
> SYNC we must error.

just curious, but couldn't you batch up the 10 10x1 sync's?

BR,
-R

>
> So to summarize, the fact that the interface is generic IMO means:
>
> 1) Any user must be able to make valid assumptions about the internal
> format of the dma-buf. (untiled, color format, stride etc.)
> 2) Any user *must* call SYNC before and after CPU access. On coherent
> architectures, the SYNC is a NULL operation anyway, and that should be
> documented somewhere so that maintainers of drivers of uncoherent
> architectures have somewhere to point their fingers.
> 3) Driver-specific implementations must be allowed to error (segfault)
> if SYNC has not been used.
> 4) The use-case stated above clearly shows the benefit of a
> 2-dimensional sync interface (we want to sync the 10x10 region), but
> what if someone in the future wants to use this interface for a 3D
> texture? Will a 2D sync suffice? Can we make the SYNC interface
> extendable in a way that an enum sync_type member defines the layout of
> the argument, and initially we implement only 1d, 2d sync, leaving 3d
> for the future?
>
> Also, I agree there is probably no good way to generically implement an
> error if SYNC has not been called. That needs to be left as an option to
> drivers.
>
> Thanks,
> Thomas
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

4.2-rc7: mutex-related crash on boot (radeon?)

2015-08-20 Thread Meelis Roos

> On 19 August 2015 at 00:28, Meelis Roos  wrote:
> > Hi, I tried 4.2-rc7 and todays 4.2-rc7+git on a P4 PC with Intel 850
> > chipset and old Radeon graphics. The machine crashes during boot and
> > starts spamming dmesg as fast as it scrolls. Netconsole caught the
> > dmesg. 4.1.0 worked fine.
> >
> > The first crash seems to be related to radeon_hotplug_work_func during
> > radeon initialization.
> 
> Looks like a race at startup, I've sent a fix to dri-devel that should work.

Thank you - found it. Will test tomorrow.

-- 
Meelis Roos (mroos at linux.ee)

4.2-rc7: mutex-related crash on boot (radeon?)

On 19 August 2015 at 00:28, Meelis Roos  wrote:
> Hi, I tried 4.2-rc7 and todays 4.2-rc7+git on a P4 PC with Intel 850
> chipset and old Radeon graphics. The machine crashes during boot and
> starts spamming dmesg as fast as it scrolls. Netconsole caught the
> dmesg. 4.1.0 worked fine.
>
> The first crash seems to be related to radeon_hotplug_work_func during
> radeon initialization.

Looks like a race at startup, I've sent a fix to dri-devel that should work.

Dave.

[PATCH] drm/radeon: fix hotplug race at startup

From: Dave Airlie 

We apparantly get a hotplug irq before we've initialised
modesetting,

[drm] Loading R100 Microcode
BUG: unable to handle kernel NULL pointer dereference at   (null)
IP: [] __mutex_lock_slowpath+0x23/0x91
*pde = 
Oops: 0002 [#1]
Modules linked in: radeon(+) drm_kms_helper ttm drm i2c_algo_bit backlight 
pcspkr psmouse evdev sr_mod input_leds led_class cdrom sg parport_pc parport 
floppy intel_agp intel_gtt lpc_ich acpi_cpufreq processor button mfd_core 
agpgart uhci_hcd ehci_hcd rng_core snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm 
usbcore usb_common i2c_i801 i2c_core snd_timer snd soundcore thermal_sys
CPU: 0 PID: 15 Comm: kworker/0:1 Not tainted 4.2.0-rc7-00015-gbf67402 #111
Hardware name: MicroLink   /D850MV  
   , BIOS MV85010A.86A.0067.P24.0304081124 04/08/2003
Workqueue: events radeon_hotplug_work_func [radeon]
task: f6ca5900 ti: f6d3e000 task.ti: f6d3e000
EIP: 0060:[] EFLAGS: 00010282 CPU: 0
EIP is at __mutex_lock_slowpath+0x23/0x91
EAX:  EBX: f5e900fc ECX:  EDX: fffe
ESI: f6ca5900 EDI: f5e90100 EBP: f5e9 ESP: f6d3ff0c
 DS: 007b ES: 007b FS:  GS:  SS: 0068
CR0: 8005003b CR2:  CR3: 36f61000 CR4: 06d0
Stack:
 f5e90100  c103c4c1 f6d2a5a0 f5e900fc f6df394c c125f162 f8b0faca
 f6d2a5a0 c138ca00 f6df394c f7395600 c1034741 00d4  f6d2a5a0
 c138ca00 f6d2a5b8 c138ca10 c1034b58 0001 f6d4 f6ca5900 f6d0c940
Call Trace:
 [] ? dequeue_task_fair+0xa4/0xb7
 [] ? mutex_lock+0x9/0xa
 [] ? radeon_hotplug_work_func+0x17/0x57 [radeon]
 [] ? process_one_work+0xfc/0x194
 [] ? worker_thread+0x18d/0x218
 [] ? rescuer_thread+0x1d5/0x1d5
 [] ? kthread+0x7b/0x80
 [] ? ret_from_kernel_thread+0x20/0x30
 [] ? init_completion+0x18/0x18
Code: 42 08 e8 8e a6 dd ff c3 57 56 53 83 ec 0c 8b 35 48 f7 37 c1 8b 10 4a 74 
1a 89 c3 8d 78 04 8b 40 08 89 63

Reported-by: Meelis Roos 
Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/radeon/radeon_irq_kms.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c 
b/drivers/gpu/drm/radeon/radeon_irq_kms.c
index 1162bfa..171d3e4 100644
--- a/drivers/gpu/drm/radeon/radeon_irq_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_irq_kms.c
@@ -79,6 +79,11 @@ static void radeon_hotplug_work_func(struct work_struct 
*work)
struct drm_mode_config *mode_config = >mode_config;
struct drm_connector *connector;

+   /* we can race here at startup, some boards seem to trigger
+* hotplug irqs when they shouldn't. */
+   if (!rdev->mode_info.mode_config_initialized)
+   return;
+
mutex_lock(_config->mutex);
if (mode_config->num_connector) {
list_for_each_entry(connector, _config->connector_list, 
head)
-- 
2.4.3

[PATCH v3 08/14] phy: Add driver for rockchip Display Port PHY

2015-08-20 Thread Kishon Vijay Abraham I

Hi,

On Wednesday 19 August 2015 08:21 PM, Yakir Yang wrote:
> Signed-off-by: Yakir Yang 

where's the commit message?
> ---
> Changes in v3:
> - Take Heiko suggest, add rockchip dp phy driver,
>   collect the phy clocks and power control.
> 
> Changes in v2: None
> 
>  .../devicetree/bindings/phy/rockchip-dp-phy.txt|  26 +++
>  drivers/phy/Kconfig|   7 +
>  drivers/phy/Makefile   |   1 +
>  drivers/phy/phy-rockchip-dp.c  | 185 
> +
>  4 files changed, 219 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
>  create mode 100644 drivers/phy/phy-rockchip-dp.c
> 
> diff --git a/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt 
> b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
> new file mode 100644
> index 000..5de1088
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
> @@ -0,0 +1,26 @@
> +Rockchip Soc Seroes Display Port PHY
> +
> +
> +Required properties:
> +- compatible : should be one of the following supported values:
> +  - "rockchip.rk3288-dp-phy"
> +
> +- reg : a list of registers used by phy driver
> +- clocks: from common clock binding: handle to dp clock.
> + of memory mapped region.
> +- clock-names: from common clock binding:
> + Required elements: "sclk_dp" "sclk_dp_24m"
> +
> +- rockchip,grf: this soc should set GRF regs, so need get grf here.
> +- #phy-cells : from the generic PHY bindings, must be 0;
> +
> +Example:
> +
> +edp_phy: phy at ff770274 {
> + compatilble = "rockchip,rk3288-dp-phy";
> + reg = <0xff770274 4>;
> + rockchip,grf = <>;
> + clocks = < SCLK_EDP_24M>;
> + clock-names = "24m";
> + #phy-cells = <0>;
> +}
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 6b8dd16..da00440 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -297,6 +297,13 @@ config PHY_ROCKCHIP_USB
>   help
> Enable this to support the Rockchip USB 2.0 PHY.
>  
> +config PHY_ROCKCHIP_DP
> + tristate "Rockchip Display Port PHY Driver"
> + depends on ARCH_ROCKCHIP && OF
> + select GENERIC_PHY
> + help
> +   Enable this to support the Rockchip Display Port PHY.
> +
>  config PHY_ST_SPEAR1310_MIPHY
>   tristate "ST SPEAR1310-MIPHY driver"
>   select GENERIC_PHY
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index f344e1b..35e3ce6 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -33,6 +33,7 @@ phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2)  += 
> phy-s5pv210-usb2.o
>  obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
>  obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)  += phy-qcom-apq8064-sata.o
>  obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
> +obj-$(CONFIG_PHY_ROCKCHIP_DP)+= phy-rockchip-dp.o
>  obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)  += phy-qcom-ipq806x-sata.o
>  obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY) += phy-spear1310-miphy.o
>  obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY) += phy-spear1340-miphy.o
> diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
> new file mode 100644
> index 000..4759111
> --- /dev/null
> +++ b/drivers/phy/phy-rockchip-dp.c
> @@ -0,0 +1,185 @@
> +/*
> + * Rockchip DP PHY driver
> + *
> + * Copyright (C) 2015 FuZhou Rockchip Co., Ltd.
> + * Author: Yakir Yang 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define GRF_SOC_CON12   0x0274
> +#define GRF_EDP_REF_CLK_SEL_INTER   BIT(4)
> +
> +#define DP_PHY_SIDDQ_WRITE_EN   BIT(21)
> +#define DP_PHY_SIDDQ_ON 0
> +#define DP_PHY_SIDDQ_OFFBIT(5)
> +
> +struct rockchip_dp_phy {
> + struct device  *dev;
> + struct regmap  *grf;
> + void __iomem   *regs;
> + struct clk *phy_24m;
> +};
> +
> +static int rockchip_dp_phy_clk_enable(struct rockchip_dp_phy *dp)
> +{
> + int ret = 0;
> +
> + ret = clk_set_rate(dp->phy_24m, 2400);
> + if (ret < 0) {
> + dev_err(dp->dev, "cannot set clock phy_24m %d\n", ret);
> + return ret;
> + }
> +
> + ret = clk_prepare_enable(dp->phy_24m);
> + if (ret < 0) {
> + dev_err(dp->dev, "cannot enable clock phy_24m %d\n", ret);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int rockchip_dp_phy_clk_disable(struct rockchip_dp_phy *dp)
> +{
> + clk_disable_unprepare(dp->phy_24m);
> +
> + return 0;
> +}
> +
> +static int rockchip_set_phy_state(struct phy *phy, bool enable)
> +{
> + struct

[PATCH v3 0/14] Add Analogix Core Display Port Driver

2015-08-20 Thread Archit Taneja

Hi,

On 08/19/2015 08:18 PM, Yakir Yang wrote:
>
> Hi all,
> The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
> share the same IP, so a lot of parts can be re-used. I split the common
> code into bridge directory, then rk3288 and exynos only need to keep
> some platform code. Cause I can't find the exact IP name of exynos dp
> controller, so I decide to name dp core driver with "analogix" which I
> find in rk3288 eDP TRM ;)
>
> Beyond that, there are three light registers setting differents bewteen
> exynos and rk3288.
> 1. RK3288 have five special pll resigters which not indicata in exynos
> dp controller.
> 2. The address of DP_PHY_PD(dp phy power manager register) are different
> between rk3288 and exynos.
> 3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug
> register).
>
> I have verified this series on two kinds of rockchip platform board, one
> is rk3288 sdk board which connect with a 2K display port monitor, the other
> is google jerry chromebook which connect with a eDP screen "cnm,n116bgeea2",
> both of them works rightlly.
>
> I haven't verified the dp function on samsung platform, cause I haven't got
> exynos boards. I can only ensure that there are no build error on samsung
> platform, wish some samsung guys help to test. ;)
>
> Thanks,
> - Yakir
>
> Changes in v3:
> - Take Thierry Reding suggest, move exynos's video_timing code
>to analogix_dp-exynos platform driver, add get_modes method
>to struct analogix_dp_plat_data.
> - Take Heiko suggest, rename some "samsung*" dts propery to "analogix*".
> - Take Thierry Reding suggest, dynamic parse video timing info from
>struct drm_display_mode and struct drm_display_info.
> - Take Thierry Reding suggest, link_rate and lane_count shouldn't config to
>the DT property value directly, but we can take those as hardware limite.
>For example, RK3288 only support 4 physical lanes of 2.7/1.62 Gbps/lane,
>so DT property would like "link-rate = 0x0a" "lane-count = 4".
> - Take Heiko suggest, add devicetree binding documents.
> - Take Thierry Reding suggest, remove sync pol & colorimetry properies
>from the new analogix dp driver devicetree binding.
> - Update the exist exynos dtsi file with the latest DP DT properies.
> - Take Thierry Reding and Heiko suggest, leave "sclk_edp_24m" to rockchip
>dp phy driver which name to "24m", and leave "sclk_edp" to analogix dp
>core driver which name to "dp", and leave "pclk_edp" to rockchip dp 
> platform
>driver which name to "pclk".
> - Take Heiko suggest, add devicetree binding document.
> - Take Heiko suggest, remove "rockchip,panel" DT property, take use of remote
>point to get panel node.
> - Add the new function point analogix_dp_platdata.get_modes init.
> - Take Heiko suggest, add rockchip dp phy driver,
>collect the phy clocks and power control.
> - Add "analogix,need-force-hpd" to indicate whether driver need foce
>hpd when hpd detect failed.
> - move dp hpd detect to connector detect function.
> - Add edid modes parse support
>
> Changes in v2:
> - Take Joe Preches advise, improved commit message more readable, and
>avoid using some uncommon style like bellow:
>-  retval = exynos_dp_read_bytes_from_i2c(...
>   ...)
>+  retval =
>+  exynos_dp_read_bytes_from_i2c(..);
> - Take Jingoo Han suggest, just remove my name from author list.
> - Take Jingoo Han suggest, remove new copyright
> - Fix compiled failed dut to analogix_dp_device misspell
> - Take Heiko suggest, get panel node with remote-endpoint method,
>and create devicetree binding for driver.
> - Remove the clock enable/disbale with "sclk_edp" & "sclk_edp_24m",
>leave those clock to rockchip dp phy driver.
> - Add GNU license v2 declared and samsung copyright
> - Fix compile failed dut to phy_pd_addr variable misspell error
>
> Yakir Yang (14):
>drm: exynos/dp: fix code style
>drm: exynos/dp: convert to drm bridge mode
>drm: bridge: analogix_dp: split exynos dp driver to bridge dir
>drm: bridge/analogix_dp: dynamic parse sync_pol & interlace &
>  colorimetry
>drm: bridge/analogix_dp: fix link_rate & lane_count bug
>Documentation: drm/bridge: add document for analogix_dp
>drm: rockchip/dp: add rockchip platform dp driver
>phy: Add driver for rockchip Display Port PHY
>drm: bridge/analogix_dp: add platform device type support
>drm: bridge: analogix_dp: add some rk3288 special registers setting
>drm: bridge: analogix_dp: try force hpd after plug in lookup failed
>drm: bridge/analogix_dp: expand the delay time for hpd detect
>drm: bridge/analogix_dp: move hpd detect to connector detect function
>drm: bridge/analogix_dp: add edid modes parse in get_modes method
>
>   .../devicetree/bindings/drm/bridge/analogix_dp.txt |   73 +
>   .../devicetree/bindings/phy/rockchip-dp-phy.txt|   26 +
>   .../bindings/video/analogix_dp-rockchip.txt

[PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT

2015-08-20 Thread Michal Hocko

On Wed 19-08-15 17:33:45, Eric B Munson wrote:
[...]
> The group which asked for this feature here
> wants the ability to distinguish between LOCKED and LOCKONFAULT regions
> and without the VMA flag there isn't a way to do that.

Could you be more specific on why this is needed?

> Do we know that these last two open flags are needed right now or is
> this speculation that they will be and that none of the other VMA flags
> can be reclaimed?

I do not think they are needed by anybody right now but that is not a
reason why it should be used without a really strong justification.
If the discoverability is really needed then fair enough but I haven't
seen any justification for that yet.

-- 
Michal Hocko
SUSE Labs

[PATCH v3 0/14] Add Analogix Core Display Port Driver

On 20 August 2015 at 00:48, Yakir Yang  wrote:
>
> Hi all,
>The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
> share the same IP, so a lot of parts can be re-used. I split the common
> code into bridge directory, then rk3288 and exynos only need to keep
> some platform code. Cause I can't find the exact IP name of exynos dp
> controller, so I decide to name dp core driver with "analogix" which I
> find in rk3288 eDP TRM ;)
>
> Beyond that, there are three light registers setting differents bewteen
> exynos and rk3288.
> 1. RK3288 have five special pll resigters which not indicata in exynos
>dp controller.
> 2. The address of DP_PHY_PD(dp phy power manager register) are different
>between rk3288 and exynos.
> 3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug
>register).
>
> I have verified this series on two kinds of rockchip platform board, one
> is rk3288 sdk board which connect with a 2K display port monitor, the other
> is google jerry chromebook which connect with a eDP screen "cnm,n116bgeea2",
> both of them works rightlly.
>
> I haven't verified the dp function on samsung platform, cause I haven't got
> exynos boards. I can only ensure that there are no build error on samsung
> platform, wish some samsung guys help to test. ;)

I'd like to pull this in, but it probably needs an ack from Samsung,

Inki can you guys find some time to test this?

Dave.

[PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT

2015-08-20 Thread Vlastimil Babka

On 08/19/2015 11:33 PM, Eric B Munson wrote:
> On Wed, 12 Aug 2015, Michal Hocko wrote:
>
>> On Sun 09-08-15 01:22:53, Eric B Munson wrote:
>>
>> I do not like this very much to be honest. We have only few bits
>> left there and it seems this is not really necessary. I thought that
>> LOCKONFAULT acts as a modifier to the mlock call to tell whether to
>> poppulate or not. The only place we have to persist it is
>> mlockall(MCL_FUTURE) AFAICS. And this can be handled by an additional
>> field in the mm_struct. This could be handled at __mm_populate level.
>> So unless I am missing something this would be much more easier
>> in the end we no new bit in VM flags would be necessary.
>>
>> This would obviously mean that the LOCKONFAULT couldn't be exported to
>> the userspace but is this really necessary?
>
> Sorry for the latency here, I was on vacation and am now at plumbers.
>
> I am not sure that growing the mm_struct by another flags field instead
> of using available bits in the vm_flags is the right choice.

I was making the same objection on one of the earlier versions and since 
you sticked with a new vm flag, I thought it doesn't matter, as we could 
change it later if we run out of bits. But now I realize that since you 
export this difference to userspace (and below you say that it's by 
request), we won't be able to change it later. So it's a more difficult 
choice.

> After this
> patch, we still have 3 free bits on 32 bit architectures (2 after the
> userfaultfd set IIRC).  The group which asked for this feature here
> wants the ability to distinguish between LOCKED and LOCKONFAULT regions
> and without the VMA flag there isn't a way to do that.
>
> Do we know that these last two open flags are needed right now or is
> this speculation that they will be and that none of the other VMA flags
> can be reclaimed?

I think it's the latter, we can expect that flags will be added rather 
than removed, as removal is hard or impossible.

[PATCH] drm/qxl: validate monitors config modes

> Due to some recent changes in
> drm_helper_probe_single_connector_modes_merge_bits(), old custom modes
> were not being pruned properly. In current kernels,
> drm_mode_validate_basic() is called to sanity-check each mode in the
> list. If the sanity-check passes, the mode's status gets set to to
> MODE_OK. In older kernels this check was not done, so old custom modes
> would still have a status of MODE_UNVERIFIED at this point, and would
> therefore be pruned later in the function.
>
> As a result of this new behavior, the list of modes for a device always
> includes every custom mode ever configured for the device, with the
> largest one listed first. Since desktop environments usually choose the
> first preferred mode when a hotplug event is emitted, this had the
> result of making it very difficult for the user to reduce the size of
> the display.
>
> The qxl driver did implement the mode_valid connector function, but it
> was empty. In order to restore the old behavior where old custom modes
> are pruned, we implement a proper mode_valid function for the qxl
> driver. This function now checks each mode against the last configured
> custom mode and the list of standard modes. If the mode doesn't match
> any of these, its status is set to MODE_BAD so that it will be pruned as
> expected.

Hi Jonathon,

this seems reasonable, it is missing a Signed-off-by line though, and we should
probably also cc stable for it.

Dave.
> ---
>  drivers/gpu/drm/qxl/qxl_display.c | 66 
> ---
>  drivers/gpu/drm/qxl/qxl_drv.h |  2 ++
>  2 files changed, 42 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
> b/drivers/gpu/drm/qxl/qxl_display.c
> index a8dbb3e..7c6225c 100644
> --- a/drivers/gpu/drm/qxl/qxl_display.c
> +++ b/drivers/gpu/drm/qxl/qxl_display.c
> @@ -160,9 +160,35 @@ static int qxl_add_monitors_config_modes(struct 
> drm_connector *connector,
> *pwidth = head->width;
> *pheight = head->height;
> drm_mode_probed_add(connector, mode);
> +   /* remember the last custom size for mode validation */
> +   qdev->monitors_config_width = mode->hdisplay;
> +   qdev->monitors_config_height = mode->vdisplay;
> return 1;
>  }
>
> +static struct mode_size {
> +   int w;
> +   int h;
> +} common_modes[] = {
> +   { 640,  480},
> +   { 720,  480},
> +   { 800,  600},
> +   { 848,  480},
> +   {1024,  768},
> +   {1152,  768},
> +   {1280,  720},
> +   {1280,  800},
> +   {1280,  854},
> +   {1280,  960},
> +   {1280, 1024},
> +   {1440,  900},
> +   {1400, 1050},
> +   {1680, 1050},
> +   {1600, 1200},
> +   {1920, 1080},
> +   {1920, 1200}
> +};
> +
>  static int qxl_add_common_modes(struct drm_connector *connector,
>  unsigned pwidth,
>  unsigned pheight)
> @@ -170,29 +196,6 @@ static int qxl_add_common_modes(struct drm_connector 
> *connector,
> struct drm_device *dev = connector->dev;
> struct drm_display_mode *mode = NULL;
> int i;
> -   struct mode_size {
> -   int w;
> -   int h;
> -   } common_modes[] = {
> -   { 640,  480},
> -   { 720,  480},
> -   { 800,  600},
> -   { 848,  480},
> -   {1024,  768},
> -   {1152,  768},
> -   {1280,  720},
> -   {1280,  800},
> -   {1280,  854},
> -   {1280,  960},
> -   {1280, 1024},
> -   {1440,  900},
> -   {1400, 1050},
> -   {1680, 1050},
> -   {1600, 1200},
> -   {1920, 1080},
> -   {1920, 1200}
> -   };
> -
> for (i = 0; i < ARRAY_SIZE(common_modes); i++) {
> mode = drm_cvt_mode(dev, common_modes[i].w, common_modes[i].h,
> 60, false, false, false);
> @@ -823,11 +826,22 @@ static int qxl_conn_get_modes(struct drm_connector 
> *connector)
>  static int qxl_conn_mode_valid(struct drm_connector *connector,
>struct drm_display_mode *mode)
>  {
> +   struct drm_device *ddev = connector->dev;
> +   struct qxl_device *qdev = ddev->dev_private;
> +   int i;
> +
> /* TODO: is this called for user defined modes? (xrandr --add-mode)
>  * TODO: check that the mode fits in the framebuffer */
> -   DRM_DEBUG("%s: %dx%d status=%d\n", mode->name, mode->hdisplay,
> - mode->vdisplay, mode->status);
> -   return MODE_OK;
> +
> +   if(qdev->monitors_config_width == mode->hdisplay &&
> +  qdev->monitors_config_height == mode->vdisplay)
> +   return MODE_OK;
> +
> +   for (i = 0; i < ARRAY_SIZE(common_modes); i++) {
> +   if (common_modes[i].w == mode->hdisplay && common_modes[i].h 
> == mode->vdisplay)
>

amdgpu 32-bit arm warnings

  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.o
/home/airlied/devel/kernel/drm-next/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:
In function âamdgpu_cs_parser_initâ:
/home/airlied/devel/kernel/drm-next/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:211:21:
warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
  chunk_array_user = (uint64_t __user *)(cs->in.chunks);
 ^
/home/airlied/devel/kernel/drm-next/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:231:15:
warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
   chunk_ptr = (void __user *)chunk_array[i];
   ^
/home/airlied/devel/kernel/drm-next/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:241:11:
warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
   cdata = (void __user *)user_chunk.chunk_data;
   ^

Dave.

[RFC 0/2] drm/dsi: DSI for devices with different control bus

2015-08-20 Thread Archit Taneja

Hi Thierry, Lucas,


On 08/19/2015 08:32 PM, Thierry Reding wrote:
> On Wed, Aug 19, 2015 at 04:52:24PM +0200, Lucas Stach wrote:
>> Am Mittwoch, den 19.08.2015, 16:34 +0200 schrieb Thierry Reding:
>>> On Wed, Aug 19, 2015 at 04:17:08PM +0200, Lucas Stach wrote:
 Hi Thierry, Archit,

>> [...]
> Perhaps a better way would be to invert this relationship. According to
> your proposal we'd have to have DT like this:
>
>   i2c at ... {
>   ...
>
>   dsi-device at ... {
>   ...
>   dsi-bus = <>;
>   ...
>   };
>
>   ...
>   };
>
>   dsi at ... {
>   ...
>   };
>
> Inversing the relationship would become something like this:
>
>   i2c at ... {
>   ...
>   };
>
>   dsi at ... {
>   ...
>
>   peripheral at ... {
>   ...
>   i2c-bus = <>;
>   ...
>   };
>
>   ...
>   };
>
> Both of those aren't fundamentally different, and they both have the
> disavantage of lacking ways to transport configuration data that the
> other bus needs to instantiate the dummy device (such as the reg
> property for example, denoting the I2C slave address or the DSI VC).
>
> So how about we create two devices in the device tree and fuse them at
> the driver level:
>
>   i2c at ... {
>   ...
>
>   i2cdsi: dsi-device at ... {
>   ...
>   };
>
>   ...
>   };
>
>   dsi at ... {
>   ...
>
>   peripheral at ... {
>   ...
>   control = <>;
>   ...
>   };
>
>   ...
>   };
>
> This way we'll get both an I2C device and a DSI device that we can fully
> describe using the standard device tree bindings. At driver time we can
> get the I2C device from the phandle in the control property of the DSI
> device and use it to execute I2C transactions.
>
 I don't really like to see that you are inventing yet-another-way to
 handle devices connected to multiple buses.

 Devicetree is structured along the control buses, even if the devices
 are connected to multiple buses, in the DT they are always children of
 the bus that is used to control their registers from the CPUs
 perspective. So a DSI encoder that is controlled through i2c is clearly
 a child of the i2c master controller and only of that one.
>>>
>>> I think that's a flawed interpretation of what's going on here. The
>>> device in fact has two interfaces: one is I2C, the other is DSI. In my
>>> opinion that's reason enough to represent it as two logical devices.
>>>
>> Does it really have 2 control interfaces that are used at the same time?
>> Or is the DSI connection a passive data bus if the register control
>> happens through i2c?
>
> The interfaces may not be used at the same time, and the DSI interface
> may even be crippled, but the device is still addressable from the DSI
> host controller, if for nothing else than for routing the video stream.
>
 If you need to model connections between devices that are not reflected
 through the control bus hierarchy you should really consider using the
 standardized of-graph bindings.
 (Documentation/devicetree/bindings/graph.txt)
>>>
>>> The problem is that the original proposal would instantiate a dummy
>>> device, so it wouldn't be represented in DT at all. So unless you do add
>>> two logical devices to DT (one for each bus interface), you don't have
>>> anything to glue together with an OF graph.
>>>
>> I see that the having dummy device is the least desirable solution. But
>> if there is only one control bus to the device I think it should be one
>> device sitting beneath the control bus.
>>
>> You can then use of-graph to model the data path between the DSI encoder
>> and device.
>
> But you will be needing a device below the DSI host controller to
> represent that endpoint of the connection. The DSI host controller
> itself is in no way connected to the I2C adapter. You would have to
> add some sort of quirk to the DSI controller binding to allow it to

Thanks for the review.

I implemented this to support ADV7533 DSI to HDMI encoder chip, which
has a DSI video bus and an i2c control bus.

There weren't any quirks as such in the device tree when I tried to
implement this. The DT seems to manage fine without a node
corresponding to a mipi_dsi_device:

i2c_adap at .. {
adv7533 at .. {

port {
adv_in: endpoint {
remote-endpoint = <_out>;
};
};
};
};

dsi_host at .. {
...
...

[PULL] Add Freescale DCU DRM driver

> Hi Dave,
>
> Warnings are fixed.  The pull request...

Close but no cigar,


CC [M]  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.o
/home/airlied/devel/kernel/drm-next/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c:
In function âfsl_dcu_drm_probeâ:
/home/airlied/devel/kernel/drm-next/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c:321:5:
warning: âretâ may be used uninitialized in this function
[-Wmaybe-uninitialized]
  if (ret < 0) {
 ^

this looks like a real bug as well.

Dave.

about mmap dma-buf and sync

Hi, Tiago!

On 08/20/2015 12:33 AM, Tiago Vignatti wrote:
> Hey Thomas, you haven't answered my email about making SYNC_* mandatory:
>
> http://lists.freedesktop.org/archives/dri-devel/2015-August/088376.html

Hmm, for some reason it doesn't show up in my mail app, but I found it
in the archives. An attempt to explain the situation from the vmwgfx
perspective.

The fact that the interface is generic means that people will start
using it for the zero-copy case. There has been a couple of more or less
hackish attempts to do this before, and if it's a _driver_ interface we
don't need to be that careful but if it is a _generic_ interface we need
to be very careful to make it fit *all* the hardware out there and that
we make all potential users use the interface in a way that conforms
with the interface specification.

What will happen otherwise is that apps written for coherent fast
hardware might, for example, ignore calling the SYNC api, just because
the app writer only cared about his own hardware on which the app works
fine. That would fail miserably if the same app was run on incoherent
hardware, or the incoherent hardware driver maintainers would be forced
to base an implementation on page-faults which would be very slow.

So assume the following use case: An app updates a 10x10 area using the
CPU on a 1600x1200 dma-buf, and it will then use the dma-buf for
texturing. On some hardware the dma-buf might be tiled in a very
specific way, on vmwgfx the dma-buf is a GPU buffer on the host, only
accessible using DMA. On vmwgfx the SYNC operation must carry out a
10x10 DMA from the host GPU buffer to a guest CPU buffer before the CPU
write and a DMA back again after the write, before GPU usage. On the
tiled architecture the SYNC operation must untile before CPU access and
probably tile again before GPU access.

If we now have a one-dimensional SYNC api, in this particular case we'd
either need to sync a far too large area (1600x10) or call SYNC 10 times
before writing, and then again after writing. If the app forgot to call
SYNC we must error.

So to summarize, the fact that the interface is generic IMO means:

1) Any user must be able to make valid assumptions about the internal
format of the dma-buf. (untiled, color format, stride etc.)
2) Any user *must* call SYNC before and after CPU access. On coherent
architectures, the SYNC is a NULL operation anyway, and that should be
documented somewhere so that maintainers of drivers of uncoherent
architectures have somewhere to point their fingers.
3) Driver-specific implementations must be allowed to error (segfault)
if SYNC has not been used.
4) The use-case stated above clearly shows the benefit of a
2-dimensional sync interface (we want to sync the 10x10 region), but
what if someone in the future wants to use this interface for a 3D
texture? Will a 2D sync suffice? Can we make the SYNC interface
extendable in a way that an enum sync_type member defines the layout of
the argument, and initially we implement only 1d, 2d sync, leaving 3d
for the future?

Also, I agree there is probably no good way to generically implement an
error if SYNC has not been called. That needs to be left as an option to
drivers.

Thanks,
Thomas

HOW TO MAKE SAMPLES DIR IN THE MAINLINE KERNEL TO BE COMPILED AND CREATED ".KO" FILE IN THE SAME DIRECTORY

Hi Ravi,

I'm wondering is your e-mail come from eDP thread ? cause I see lots of 
cc guys some as eDP emails :)

And for your question, I am not sure I understand rightly. Do you mean 
that your ".ko" module not in
the same directory with driver source code?

If it's your question, I think you can fix it by add SUBDIRS flag in 
your driver makefile.
I test it on kernel 3.14, but I think it would be okay on mainline 
kernel, it works good
in my side, I see hello.ko in my hello/

[~/work/kernel-3.14/hello] 7392h41m $ ls
hello.c  hello.ko  hello.mod.c  hello.mod.o  hello.o  Makefile 
modules.order  Module.symvers

# My test makefile
obj-m := hello.o

KERNEL_DIR := ~/work/kernel-3.14
PWD := $(shell pwd)

all:
 make -C $(KERNEL_DIR) SUBDIRS=$(PWD) modules

clean:
 rm *.o *.ko *.mod.c

.PHONY:clean

Wish can help,
- Yakir

On 08/20/2015 03:45 AM, ravi ranjan Mishra wrote:
> Hi ,
>
> i did make in the kernel directory but sample directory is not able to 
> compiled and generating .ko file in the same directory.
>
> can you please tell.
>
> Thanks,
> Ravi

[Bug 91540] slow rendering & fullscreen results in stale images

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

--- Comment #3 from Michel DÃ¤nzer  ---
Looks like the amdgpu driver doesn't properly wait for rendering to the back
buffer to finish before flipping scanout to it.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150820/28acc5bb/attachment.html>

[Bug 66384] VDPAU playback hangs when moving window between xrandr monitors

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

Michel DÃ¤nzer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Michel DÃ¤nzer  ---
Fixed in xf86-video-ati Git master:

commit 0288a4b87b65ba54f37fbeeea3cb32238deee92e
Author: Michel DÃ¤nzer 
Date:   Wed Aug 19 16:54:14 2015 +0900

DRI2: Keep MSC monotonic when moving window between CRTCs

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150820/1eaf6fbe/attachment-0001.html>

[PATCH v3 13/14] drm: bridge/analogix_dp: move hpd detect to connector detect function

Hi Jingoo,

On 08/20/2015 02:49 AM, Jingoo Han wrote:
> On 2015. 8. 19., at PM 11:52, Yakir Yang  wrote:
>
> What is the reason to make this patch?
>
> Please make commit message including the reason.

Okay, I think the below words would be okay :)

"This change just make a little clean to make code more like
drm core expect, move hdp detect code from bridge->enable(),
and place them into connector->detect()."

Thanks,
- Yakir

> Best regards,
> Jingoo Han
>
>> Signed-off-by: Yakir Yang 
>> ---
>> Changes in v3:
>> - move dp hpd detect to connector detect function.
>>
>> Changes in v2: None
>>
>> drivers/gpu/drm/bridge/analogix_dp_core.c | 12 ++--
>> 1 file changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/analogix_dp_core.c 
>> b/drivers/gpu/drm/bridge/analogix_dp_core.c
>> index 75dd44a..052b9b3 100644
>> --- a/drivers/gpu/drm/bridge/analogix_dp_core.c
>> +++ b/drivers/gpu/drm/bridge/analogix_dp_core.c
>> @@ -915,12 +915,6 @@ static void analogix_dp_commit(struct 
>> analogix_dp_device *dp)
>> DRM_ERROR("failed to disable the panel\n");
>> }
>>
>> -ret = analogix_dp_detect_hpd(dp);
>> -if (ret) {
>> -/* Cable has been disconnected, we're done */
>> -return;
>> -}
>> -
>> ret = analogix_dp_handle_edid(dp);
>> if (ret) {
>> dev_err(dp->dev, "unable to handle edid\n");
>> @@ -953,6 +947,12 @@ static void analogix_dp_commit(struct 
>> analogix_dp_device *dp)
>> static enum drm_connector_status analogix_dp_detect(
>> struct drm_connector *connector, bool force)
>> {
>> +struct analogix_dp_device *dp = connector_to_dp(connector);
>> +
>> +if (analogix_dp_detect_hpd(dp))
>> +/* Cable has been disconnected, we're done */
>> +return connector_status_disconnected;
>> +
>> return connector_status_connected;
>> }
>>
>> -- 
>> 1.9.1
>>
>>
>
>

[Bug 91588] [LLVM] (bisected) Unigine Valley: High + AA = incorrect rendering

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

Michel DÃ¤nzer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Michel DÃ¤nzer  ---
Seems fixed by LLVM SVN r245329.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150820/518ebe87/attachment.html>

[PATCH v3 05/14] drm: bridge/analogix_dp: fix link_rate & lane_count bug

Hi Jingoo,

On 08/20/2015 02:22 AM, Jingoo Han wrote:
> On 2015. 8. 19., at PM 11:50, Yakir Yang  wrote:
>> link_rate and lane_count already configed in analogix_dp_set_link_train(),
> s/configed/configured
>
> Also, the commit name such as "fix ... bug" is not good.
> How about following?
>
> drm: bridge/analogix_dp: remove duplicate configuration of link rate and link 
> count

Thanks, done, it's more readable.

- Yakir
> Best regards,
> Jingoo Han
>
>> so we don't need to config those repeatly after training finished, just
>> remove them out.
>>
>> Beside Display Port 1.2 already support 5.4Gbps link rate, the maximum sets
>> would change from {1.62Gbps, 2.7Gbps} to {1.62Gbps, 2.7Gbps, 5.4Gbps}.
>>
>> Signed-off-by: Yakir Yang 
>> ---
>> Changes in v3:
>> - Take Thierry Reding suggest, link_rate and lane_count shouldn't config to
>>   the DT property value directly, but we can take those as hardware limite.
>>   For example, RK3288 only support 4 physical lanes of 2.7/1.62 Gbps/lane,
>>   so DT property would like "link-rate = 0x0a" "lane-count = 4".
>>
>> Changes in v2: None
>>
>> drivers/gpu/drm/bridge/analogix_dp_core.c | 16 
>> drivers/gpu/drm/bridge/analogix_dp_core.h |  9 +
>> 2 files changed, 13 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/analogix_dp_core.c 
>> b/drivers/gpu/drm/bridge/analogix_dp_core.c
>> index 480cc13..1778e0a 100644
>> --- a/drivers/gpu/drm/bridge/analogix_dp_core.c
>> +++ b/drivers/gpu/drm/bridge/analogix_dp_core.c
>> @@ -635,6 +635,8 @@ static void analogix_dp_get_max_rx_bandwidth(struct 
>> analogix_dp_device *dp,
>> /*
>>  * For DP rev.1.1, Maximum link rate of Main Link lanes
>>  * 0x06 = 1.62 Gbps, 0x0a = 2.7 Gbps
>> + * For DP rev.1.2, Maximum link rate of Main Link lanes
>> + * 0x06 = 1.62 Gbps, 0x0a = 2.7 Gbps, 0x14 = 5.4Gbps
>>  */
>> analogix_dp_read_byte_from_dpcd(dp, DP_MAX_LINK_RATE, );
>> *bandwidth = data;
>> @@ -668,7 +670,8 @@ static void analogix_dp_init_training(struct 
>> analogix_dp_device *dp,
>> analogix_dp_get_max_rx_lane_count(dp, >link_train.lane_count);
>>
>> if ((dp->link_train.link_rate != LINK_RATE_1_62GBPS) &&
>> -(dp->link_train.link_rate != LINK_RATE_2_70GBPS)) {
>> +(dp->link_train.link_rate != LINK_RATE_2_70GBPS) &&
>> +(dp->link_train.link_rate != LINK_RATE_5_40GBPS)) {
>> dev_err(dp->dev, "Rx Max Link Rate is abnormal :%x !\n",
>> dp->link_train.link_rate);
>> dp->link_train.link_rate = LINK_RATE_1_62GBPS;
>> @@ -901,8 +904,8 @@ static void analogix_dp_commit(struct analogix_dp_device 
>> *dp)
>> return;
>> }
>>
>> -ret = analogix_dp_set_link_train(dp, dp->video_info->lane_count,
>> - dp->video_info->link_rate);
>> +ret = analogix_dp_set_link_train(dp, dp->video_info->max_lane_count,
>> + dp->video_info->max_link_rate);
>> if (ret) {
>> dev_err(dp->dev, "unable to do link train\n");
>> return;
>> @@ -912,9 +915,6 @@ static void analogix_dp_commit(struct analogix_dp_device 
>> *dp)
>> analogix_dp_enable_rx_to_enhanced_mode(dp, 1);
>> analogix_dp_enable_enhanced_mode(dp, 1);
>>
>> -analogix_dp_set_lane_count(dp, dp->video_info->lane_count);
>> -analogix_dp_set_link_bandwidth(dp, dp->video_info->link_rate);
>> -
>> analogix_dp_init_video(dp);
>> ret = analogix_dp_config_video(dp);
>> if (ret)
>> @@ -1198,13 +1198,13 @@ static struct video_info 
>> *analogix_dp_dt_parse_pdata(struct device *dev)
>> }
>>
>> if (of_property_read_u32(dp_node, "analogix,link-rate",
>> - _video_config->link_rate)) {
>> + _video_config->max_link_rate)) {
>> dev_err(dev, "failed to get link-rate\n");
>> return ERR_PTR(-EINVAL);
>> }
>>
>> if (of_property_read_u32(dp_node, "analogix,lane-count",
>> - _video_config->lane_count)) {
>> + _video_config->max_lane_count)) {
>> dev_err(dev, "failed to get lane-count\n");
>> return ERR_PTR(-EINVAL);
>> }
>> diff --git a/drivers/gpu/drm/bridge/analogix_dp_core.h 
>> b/drivers/gpu/drm/bridge/analogix_dp_core.h
>> index 2cefde9..941b34f 100644
>> --- a/drivers/gpu/drm/bridge/analogix_dp_core.h
>> +++ b/drivers/gpu/drm/bridge/analogix_dp_core.h
>> @@ -21,8 +21,9 @@
>> #define MAX_EQ_LOOP 5
>>
>> enum link_rate_type {
>> -LINK_RATE_1_62GBPS = 0x06,
>> -LINK_RATE_2_70GBPS = 0x0a
>> +LINK_RATE_1_62GBPS = DP_LINK_BW_1_62,
>> +LINK_RATE_2_70GBPS = DP_LINK_BW_2_7,
>> +LINK_RATE_5_40GBPS = DP_LINK_BW_5_4,
>> };
>>
>> enum link_lane_count_type {
>> @@ -128,8 +129,8 @@ struct video_info {
>> enum color_coefficient ycbcr_coeff;
>> enum color_depth color_depth;
>>
>> -enum link_rate_type link_rate;
>> -enum link_lane_count_type lane_count;
>> +enum link_rate_type   max_link_rate;
>> +enum link_lane_count_type max_lane_count;
>>

[PATCH v3 0/14] Add Analogix Core Display Port Driver

Hi Jingoo,

On 08/20/2015 01:55 AM, Jingoo Han wrote:
> On 2015. 8. 20., at PM 3:23, Yakir Yang  wrote:
>> Hi Jingoo & Archit,
>>
>>
>>> On 08/20/2015 12:54 AM, Jingoo Han wrote:
 On 2015. 8. 20., at PM 1:29, Archit Taneja  
 wrote:
 Hi,

> On 08/19/2015 08:18 PM, Yakir Yang wrote:
>
> Hi all,
> The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
> share the same IP, so a lot of parts can be re-used. I split the common
> code into bridge directory, then rk3288 and exynos only need to keep
> some platform code. Cause I can't find the exact IP name of exynos dp
> controller, so I decide to name dp core driver with "analogix" which I
> find in rk3288 eDP TRM ;)
>
> Beyond that, there are three light registers setting differents bewteen
> exynos and rk3288.
> 1. RK3288 have five special pll resigters which not indicata in exynos
> dp controller.
> 2. The address of DP_PHY_PD(dp phy power manager register) are different
> between rk3288 and exynos.
> 3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug
> register).
>
> I have verified this series on two kinds of rockchip platform board, one
> is rk3288 sdk board which connect with a 2K display port monitor, the 
> other
> is google jerry chromebook which connect with a eDP screen 
> "cnm,n116bgeea2",
> both of them works rightlly.
>
> I haven't verified the dp function on samsung platform, cause I haven't 
> got
> exynos boards. I can only ensure that there are no build error on samsung
> platform, wish some samsung guys help to test. ;)
>
> Thanks,
> - Yakir
>
> Changes in v3:
> - Take Thierry Reding suggest, move exynos's video_timing code
>to analogix_dp-exynos platform driver, add get_modes method
>to struct analogix_dp_plat_data.
> - Take Heiko suggest, rename some "samsung*" dts propery to "analogix*".
> - Take Thierry Reding suggest, dynamic parse video timing info from
>struct drm_display_mode and struct drm_display_info.
> - Take Thierry Reding suggest, link_rate and lane_count shouldn't config 
> to
>the DT property value directly, but we can take those as hardware 
> limite.
>For example, RK3288 only support 4 physical lanes of 2.7/1.62 
> Gbps/lane,
>so DT property would like "link-rate = 0x0a" "lane-count = 4".
> - Take Heiko suggest, add devicetree binding documents.
> - Take Thierry Reding suggest, remove sync pol & colorimetry properies
>from the new analogix dp driver devicetree binding.
> - Update the exist exynos dtsi file with the latest DP DT properies.
> - Take Thierry Reding and Heiko suggest, leave "sclk_edp_24m" to rockchip
>dp phy driver which name to "24m", and leave "sclk_edp" to analogix dp
>core driver which name to "dp", and leave "pclk_edp" to rockchip dp 
> platform
>driver which name to "pclk".
> - Take Heiko suggest, add devicetree binding document.
> - Take Heiko suggest, remove "rockchip,panel" DT property, take use of 
> remote
>point to get panel node.
> - Add the new function point analogix_dp_platdata.get_modes init.
> - Take Heiko suggest, add rockchip dp phy driver,
>collect the phy clocks and power control.
> - Add "analogix,need-force-hpd" to indicate whether driver need foce
>hpd when hpd detect failed.
> - move dp hpd detect to connector detect function.
> - Add edid modes parse support
>
> Changes in v2:
> - Take Joe Preches advise, improved commit message more readable, and
>avoid using some uncommon style like bellow:
>-  retval = exynos_dp_read_bytes_from_i2c(...
> ...)
>+  retval =
>+  exynos_dp_read_bytes_from_i2c(..);
> - Take Jingoo Han suggest, just remove my name from author list.
> - Take Jingoo Han suggest, remove new copyright
> - Fix compiled failed dut to analogix_dp_device misspell
> - Take Heiko suggest, get panel node with remote-endpoint method,
>and create devicetree binding for driver.
> - Remove the clock enable/disbale with "sclk_edp" & "sclk_edp_24m",
>leave those clock to rockchip dp phy driver.
> - Add GNU license v2 declared and samsung copyright
> - Fix compile failed dut to phy_pd_addr variable misspell error
>
> Yakir Yang (14):
>drm: exynos/dp: fix code style
>drm: exynos/dp: convert to drm bridge mode
>drm: bridge: analogix_dp: split exynos dp driver to bridge dir
>drm: bridge/analogix_dp: dynamic parse sync_pol & interlace &
>  colorimetry
>drm: bridge/analogix_dp: fix link_rate & lane_count bug
>Documentation: drm/bridge: add document for analogix_dp
>drm: rockchip/dp: add rockchip platform dp driver
>

[PATCH v3 12/14] drm: bridge/analogix_dp: expand the delay time for hpd detect

Hi Jingoo,

On 08/20/2015 01:11 AM, Jingoo Han wrote:
> On 2015. 8. 19., at PM 11:52, Yakir Yang  wrote:
>> Some edp screen with no hpd signal would need some delay time
>> to ensure that screen would be ready for work, so we can expand
>> the delay time in hpd detect function, it works prefectly on my
>> rk3288 sdk board.
> Then, this delay has a dependency on the "rk3288 sdk" board.
> Also, if the delay time is expanded, the booting time of some Exybos boards 
> will be increased unnecessarily. :-(
>
> So, please add new DT property such as 'hpd-delay' that can be added to board 
> DT files.
>
> If there is not that DT property in DT files, the default value '10' will 
> written to a variable such as 'unsigned int hpd_delay'.
> If there is the DT property in DT files, the delay value will written to the 
> variable when parsing DT values
> and will be used in analogix_dp_detect_hpd().
>
> What I want to say is that there should not be harmful effect on the existing 
> Exynos boards, due to unrelated reasons.

Yeah, you are right, I made an mistake here.

And I want to put this delay to "need-force-hpd" code, cause
this property is for the no-hpd-signal eDP screen.

But strangely, with my this series, I don't need the expand delay
any more, I am not sure which change improved this, I guess
those delay time should come from drm core ?

Whatever seems we don't need this delay for now, and if I can
find the exact reason and realize I still need this delay, I prefer
to add those delay in "need-force-hpd" code.

Thanks,
- Yakir
> Best regards,
> Jingoo Han
>
>> Signed-off-by: Yakir Yang 
>> ---
>> Changes in v3: None
>> Changes in v2: None
>>
>> drivers/gpu/drm/bridge/analogix_dp_core.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/analogix_dp_core.c 
>> b/drivers/gpu/drm/bridge/analogix_dp_core.c
>> index 99870f7..75dd44a 100644
>> --- a/drivers/gpu/drm/bridge/analogix_dp_core.c
>> +++ b/drivers/gpu/drm/bridge/analogix_dp_core.c
>> @@ -68,7 +68,7 @@ static int analogix_dp_detect_hpd(struct 
>> analogix_dp_device *dp)
>> return 0;
>>
>> timeout_loop++;
>> -usleep_range(10, 11);
>> +usleep_range(100, 110);
>> }
>>
>> /*
>> -- 
>> 1.9.1
>>
>>
>
>

[PATCH 1/4] drm: add interface to get drm devices on the system v3

2015-08-20 Thread Zhou, Jammy

Hi Emil,

Can I get you RB now? It looks like there was no more comment from others.

Regards,
Jammy

-Original Message-
From: Emil Velikov [mailto:emil.l.veli...@gmail.com] 
Sent: Monday, August 17, 2015 10:13 PM
To: Zhou, Jammy
Cc: ML dri-devel
Subject: Re: [PATCH 1/4] drm: add interface to get drm devices on the system v3

On 17 August 2015 at 04:09, Jammy Zhou  wrote:
> From: Emil Velikov 
>
> For mutiple GPU support, the devices on the system should be 
> enumerated to get necessary information about each device, and the 
> drmGetDevices interface is added for this. Currently only PCI devices 
> are supported for the enumeration.
>
> Typical usage:
> int count;
> drmDevicePtr *foo;
> count = drmGetDevices(NULL, 0);
> foo = calloc(count, sizeof(drmDevicePtr)); count = drmGetDevices(foo, 
> count);
> /* find proper device, open correct device node, etc */ 
> drmFreeDevices(foo, count); free(foo);
>
> v2: change according to feedback from Emil
> v3: fix the signed extension for PCI device info
>
Thanks Jammy. That's better.

As I would suspect the amdgpu changes to be urgent, can we leave this around 
for a few more days. I'd suspect some (potential) users will want to like to 
take a look.

-Emil

[PATCH v3 08/14] phy: Add driver for rockchip Display Port PHY

Hi Kishon,

On 08/20/2015 01:56 AM, Yakir Yang wrote:
> Hi Kishon,
>
> On 08/19/2015 11:40 PM, Kishon Vijay Abraham I wrote:
> [...]
>>> [...]
>>> +MODULE_DEVICE_TABLE(of, rockchip_dp_phy_dt_ids);
>>> +
>>> +static struct platform_driver rockchip_dp_phy_driver = {
>>> +   .probe  = rockchip_dp_phy_probe,
>>> +   .driver = {
>>> +   .name   = "rockchip-dp-phy",
>>> +   .owner  = THIS_MODULE,
>> owner is not required here.

Whoops, forget to reply this one.

Done.

- Yakir
>>
>> Thanks
>> Kishon
>>
>>
>>
>

------ next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150820/1c59cc4f/attachment-0001.html>

[Bug 102401] Radeon Displayport Audio Warping

2015-08-20 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #8 from Maxqia  ---
It works with fglrx, also in the dmesg log it says
"[drm:drm_detect_monitor_audio] Monitor has basic audio support"
Which is when it should output true

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 102401] Radeon Displayport Audio Warping

2015-08-20 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #7 from Maxqia  ---
Created attachment 185301
  --> https://bugzilla.kernel.org/attachment.cgi?id=185301=edit
dmesg log

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH v3 0/14] Add Analogix Core Display Port Driver