[PATCH 3/4] drm/radeon: consolidate uvd/vce initialization, resume and suspend.

[Dave Airlie]

Just an aside,

So is there no way to do hibernate with these blocks?

Like can you not cleanly shut them down without doing a power cycle.

I have to say UVD is a real pain in the ass from a stability pov, I'd
kinda wished I'd enforced AMD creating something like intel-gpu-tools
and having tests to make sure GPU reset etc stayed working before
merging it.

Dave.

[PATCH v12 2/2] drm/bridge: Add I2C based driver for ps8640 bridge

[kbuild test robot]

Hi Jitao,

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

url:
https://github.com/0day-ci/linux/commits/Jitao-Shi/Documentation-bridge-Add-documentation-for-ps8640-DT-properties/20160316-213031
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: x86_64-allmodconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   include/linux/compiler.h:228:8: sparse: attribute 'no_sanitize_address': 
unknown attribute
   drivers/gpu/drm/bridge/parade-ps8640.c:114:30: sparse: invalid initializer
   drivers/gpu/drm/bridge/parade-ps8640.c:430:24: sparse: undefined identifier 
'of_find_mipi_dsi_host_by_node'
   drivers/gpu/drm/bridge/parade-ps8640.c:114:37: warning: excess elements in 
scalar initializer
static const u8 hw_chip_id = {0x00, 0x0a, 0x00, 0x30};
^
   drivers/gpu/drm/bridge/parade-ps8640.c:114:37: note: (near initialization 
for 'hw_chip_id')
   drivers/gpu/drm/bridge/parade-ps8640.c:114:43: warning: excess elements in 
scalar initializer
static const u8 hw_chip_id = {0x00, 0x0a, 0x00, 0x30};
  ^
   drivers/gpu/drm/bridge/parade-ps8640.c:114:43: note: (near initialization 
for 'hw_chip_id')
   drivers/gpu/drm/bridge/parade-ps8640.c:114:49: warning: excess elements in 
scalar initializer
static const u8 hw_chip_id = {0x00, 0x0a, 0x00, 0x30};
^
   drivers/gpu/drm/bridge/parade-ps8640.c:114:49: note: (near initialization 
for 'hw_chip_id')
   drivers/gpu/drm/bridge/parade-ps8640.c: In function 'ps8640_bridge_attach':
   drivers/gpu/drm/bridge/parade-ps8640.c:430:10: error: implicit declaration 
of function 'of_find_mipi_dsi_host_by_node' 
[-Werror=implicit-function-declaration]
  host = of_find_mipi_dsi_host_by_node(dsi_node);
 ^
   drivers/gpu/drm/bridge/parade-ps8640.c:430:8: warning: assignment makes 
pointer from integer without a cast [-Wint-conversion]
  host = of_find_mipi_dsi_host_by_node(dsi_node);
   ^
   drivers/gpu/drm/bridge/parade-ps8640.c: In function 'ps8640_check_chip_id':
>> drivers/gpu/drm/bridge/parade-ps8640.c:717:21: warning: passing argument 2 
>> of 'memcmp' makes pointer from integer without a cast [-Wint-conversion]
 return memcmp(buf, hw_chip_id, sizeof(buf));
^
   In file included from include/linux/bitmap.h:8:0,
from include/linux/cpumask.h:11,
from arch/x86/include/asm/cpumask.h:4,
from arch/x86/include/asm/msr.h:10,
from arch/x86/include/asm/processor.h:20,
from arch/x86/include/asm/thread_info.h:52,
from include/linux/thread_info.h:54,
from arch/x86/include/asm/preempt.h:6,
from include/linux/preempt.h:59,
from include/linux/spinlock.h:50,
from include/linux/mmzone.h:7,
from include/linux/gfp.h:5,
from include/linux/firmware.h:6,
from drivers/gpu/drm/bridge/parade-ps8640.c:16:
   include/linux/string.h:112:12: note: expected 'const void *' but argument is 
of type 'u8 {aka const unsigned char}'
extern int memcmp(const void *,const void *,__kernel_size_t);
   ^
   cc1: some warnings being treated as errors

sparse warnings: (new ones prefixed by >>)

   include/linux/compiler.h:228:8: sparse: attribute 'no_sanitize_address': 
unknown attribute
>> drivers/gpu/drm/bridge/parade-ps8640.c:114:30: sparse: invalid initializer
   drivers/gpu/drm/bridge/parade-ps8640.c:430:24: sparse: undefined identifier 
'of_find_mipi_dsi_host_by_node'
   drivers/gpu/drm/bridge/parade-ps8640.c:114:37: warning: excess elements in 
scalar initializer
static const u8 hw_chip_id = {0x00, 0x0a, 0x00, 0x30};
^
   drivers/gpu/drm/bridge/parade-ps8640.c:114:37: note: (near initialization 
for 'hw_chip_id')
   drivers/gpu/drm/bridge/parade-ps8640.c:114:43: warning: excess elements in 
scalar initializer
static const u8 hw_chip_id = {0x00, 0x0a, 0x00, 0x30};
  ^
   drivers/gpu/drm/bridge/parade-ps8640.c:114:43: note: (near initialization 
for 'hw_chip_id')
   drivers/gpu/drm/bridge/parade-ps8640.c:114:49: warning: excess elements in 
scalar initializer
static const u8 hw_chip_id = {0x00, 0x0a, 0x00, 0x30};
^
   drivers/gpu/drm/bridge/parade-ps8640.c:114:49: note: (near initialization 
for 'hw_chip_id')
   drivers/gpu/drm/bridge/parade-ps8640.c: In function 'ps8640_bridge_attach':
   

[Bug 94581] Red flood in dmesg when running applications

[bugzilla-dae...@freedesktop.org]

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

Bug ID: 94581
   Summary: Red flood in dmesg when running applications
   Product: Mesa
   Version: 11.0
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: mazahakaforever at ya.ru
QA Contact: dri-devel at lists.freedesktop.org

Hi there. Im using laptop with hybrid graphics. Intel Core i5-2450m with
integrated videocard and AMD Radeon HD 6650m as discrete.
My glxinfo output

glxinfo | grep OpenGL
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile 
OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.0.4
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 11.0.4
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 11.0.4
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:


And output with DRI_PRIME set.

DRI_PRIME=1 glxinfo | grep OpenGL
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD TURKS (DRM 2.43.0, LLVM 3.6.2)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.0.4
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 11.0.4
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 11.0.4
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:


So, i guess when im using DRI_PRIME environmental variable as one - kernel
tries to use discrete videocard. And when im trying to launch applications
(glxgears, etracer, steam) i got many messages in dmesg like this
[ 1376.309602] [drm:radeon_cs_parser_relocs [radeon]] *ERROR* gem object lookup
failed 0xe
[ 1376.309620] [drm:radeon_cs_ioctl [radeon]] *ERROR* Failed to parse
relocation -2!
[ 1376.822639] [drm:radeon_cs_parser_relocs [radeon]] *ERROR* gem object lookup
failed 0xe
[ 1376.822661] [drm:radeon_cs_ioctl [radeon]] *ERROR* Failed to parse
relocation -2!


Looking forward to some discussion.

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

[Bug 94581] Red flood in dmesg when running applications

[bugzilla-dae...@freedesktop.org]

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

--- Comment #1 from Vladislav Kamenev  ---
Also im using
uname -r
4.5.0-040500-generic
from kernel.ubuntu.com

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

[PATCH 0/8] drm: atmel-hlcdc: various fixes/improvements

[Dave Airlie]

On 1 March 2016 at 20:55, Boris Brezillon
 wrote:
> On Wed,  6 Jan 2016 11:19:21 +0100
> Boris Brezillon  wrote:
>
>> Hello,
>>
>> This series is a collection of fixes and improvements for the
>> atmel-hlcdc driver.
>>
>> The main feature added here is the support for external RGB -> XXX
>> bridges (patch 6 and 7).
>>
>> The first patch is a fix preventing a potential memory leak.
>> Patch 2 is adding support for asynchronous mode setting, which was
>> supported before the migration to atomic mode setting.
>>
>> Patch 3 is just a minor fix to expose the real encoder and connector
>> types (we are currently exposing an LVDS encoder/connector, which is
>> wrong since the display controller output the pixel stream in raw
>> RGB).
>>
>> Patch 4 is removing useless fields and functions which were left
>> when moving to atomic modesetting.
>>
>> And patch 8 is just a cosmetic patch moving the mode checking code
>> from ->atomic_check() to ->mode_fixup().
>
> Dave, Daniel, any comment on this series (AKA ping)?

On internal driver stuff, I'd usually only look on a git pull :-)

Dave.

[PATCH] drm/exynos: fimd: fix broken dp_clock control

[Marek Szyprowski]

Commit 1feafd3afd294b03dbbedb8e8f94e0c4db526f10 ("drm/exynos: add
exynos5420 support for fimd") add support for Exynos 5420 SoC, but it
broke enabling display clock feature because of incorrect condition
check. This patch fixes it, so display is working again on platforms
requiring display clock control (i.e. Exynos5250-based SNOW platform).

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 0a44511..c65fe79 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -889,7 +889,7 @@ static void fimd_dp_clock_enable(struct exynos_drm_crtc 
*crtc, bool enable)
 * clock. On these SoCs the bootloader may enable it but any
 * power domain off/on will reset it to disable state.
 */
-   if (ctx->driver_data != _fimd_driver_data ||
+   if (ctx->driver_data != _fimd_driver_data &&
ctx->driver_data != _fimd_driver_data)
return;

-- 
1.9.2

[PATCH] drm/exynos: fimd: fix broken dp_clock control

[Krzysztof Kozlowski]

On 17.03.2016 15:53, Marek Szyprowski wrote:
> Commit 1feafd3afd294b03dbbedb8e8f94e0c4db526f10 ("drm/exynos: add

The commit exists only in next so the SHA might be useless in case of
rebase of drm-exynos tree.

> exynos5420 support for fimd") add support for Exynos 5420 SoC, but it
> broke enabling display clock feature because of incorrect condition
> check. This patch fixes it, so display is working again on platforms
> requiring display clock control (i.e. Exynos5250-based SNOW platform).
> 
> Signed-off-by: Marek Szyprowski 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Krzysztof Kozlowski 



Best regards,

Krzysztof

[PATCH 3/4] drm/radeon: consolidate uvd/vce initialization, resume and suspend.

[Daniel Vetter]

On Thu, Mar 17, 2016 at 06:41:14AM +1000, Dave Airlie wrote:
> Just an aside,
> 
> So is there no way to do hibernate with these blocks?
> 
> Like can you not cleanly shut them down without doing a power cycle.
> 
> I have to say UVD is a real pain in the ass from a stability pov, I'd
> kinda wished I'd enforced AMD creating something like intel-gpu-tools
> and having tests to make sure GPU reset etc stayed working before
> merging it.

igt already supports running on any kind of drm device, and it has a bunch
of vc4 specific testcases on top. If anyone finds offence in the "intel"
part, we can rename it to igt gpu tools/tests ;-)

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm/i915: Fix race condition in intel_dp_destroy_mst_connector()

[Daniel Vetter]

On Wed, Mar 16, 2016 at 09:39:49PM +0200, Ville Syrjälä wrote:
> On Wed, Mar 16, 2016 at 03:18:04PM -0400, Lyude wrote:
> > After unplugging a DP MST display from the system, we have to go through
> > and destroy all of the DRM connectors associated with it since none of
> > them are valid anymore. Unfortunately, intel_dp_destroy_mst_connector()
> > doesn't do a good enough job of ensuring that throughout the destruction
> > process that no modesettings can be done with the connectors. As it is
> > right now, intel_dp_destroy_mst_connector() works like this:
> > 
> > * Take all modeset locks
> > * Clear the configuration of the crtc on the connector, if there is one
> > * Drop all modeset locks, this is required because of circular
> >   dependency issues that arise with trying to remove the connector from
> >   sysfs with modeset locks held
> > * Unregister the connector
> > * Take all modeset locks, again
> > * Do the rest of the required cleaning for destroying the connector
> > * Finally drop all modeset locks for good
> 
> So pretty much what I suspected
> https://lists.freedesktop.org/archives/intel-gfx/2016-February/087734.html
> 
> > 
> > This only works sometimes. During the destruction process, it's very
> > possible that a userspace application will attempt to do a modesetting
> > using the connector. When we drop the modeset locks, an ioctl handler
> > such as drm_mode_setcrtc has the oppurtunity to take all of the modeset
> > locks from us. When this happens, one thing leads to another and
> > eventually we end up committing a mode with the non-existent connector:
> > 
> > [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* failed to 
> > enable link training
> > [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7cf0001f
> > [drm:intel_dp_start_link_train [i915]] *ERROR* failed to start channel 
> > equalization
> > [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7cf0001f
> > [drm:intel_mst_pre_enable_dp [i915]] *ERROR* failed to allocate vcpi
> > 
> > And in some cases, such as with the T460s using an MST dock, this
> > results in breaking modesetting and/or panicking the system.
> 
> Are these just kernel oopses etc.? If the hardware gets upset from
> modesetting when the sink is gone, well, then we still have a problem
> because the user can of course yank the cable while the modeset is already
> underway.
> 
> > 
> > To work around this, we now unregister the connector at the very
> > beginning of intel_dp_destroy_mst_connector(), grab all the modesetting
> > locks, and then hold them until we finish the rest of the function.
> > 
> > CC: stable at vger.kernel.org
> > Signed-off-by: Lyude 
> > Signed-off-by: Rob Clark 
> 
> These sobs don't make much sense to me.
> 
> Patch itself does make sense to me, so 
> Reviewed-by: Ville Syrjälä 

Applied, thanks.
-Daniel

> 
> > ---
> >  drivers/gpu/drm/i915/intel_dp_mst.c | 6 ++
> >  1 file changed, 2 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> > b/drivers/gpu/drm/i915/intel_dp_mst.c
> > index fa0dabf..b21ac88 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > @@ -499,6 +499,8 @@ static void intel_dp_destroy_mst_connector(struct 
> > drm_dp_mst_topology_mgr *mgr,
> > struct intel_connector *intel_connector = to_intel_connector(connector);
> > struct drm_device *dev = connector->dev;
> >  
> > +   intel_connector->unregister(intel_connector);
> > +
> > /* need to nuke the connector */
> > drm_modeset_lock_all(dev);
> > if (connector->state->crtc) {
> > @@ -512,11 +514,7 @@ static void intel_dp_destroy_mst_connector(struct 
> > drm_dp_mst_topology_mgr *mgr,
> >  
> > WARN(ret, "Disabling mst crtc failed with %i\n", ret);
> > }
> > -   drm_modeset_unlock_all(dev);
> >  
> > -   intel_connector->unregister(intel_connector);
> > -
> > -   drm_modeset_lock_all(dev);
> > intel_connector_remove_from_fbdev(intel_connector);
> > drm_connector_cleanup(connector);
> > drm_modeset_unlock_all(dev);
> > -- 
> > 2.5.0
> > 
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Ville Syrjälä
> Intel OTC
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 0/8] drm: atmel-hlcdc: various fixes/improvements

[Boris Brezillon]

On Thu, 17 Mar 2016 12:43:11 +1000
Dave Airlie  wrote:

> On 1 March 2016 at 20:55, Boris Brezillon
>  wrote:
> > On Wed,  6 Jan 2016 11:19:21 +0100
> > Boris Brezillon  wrote:
> >
> >> Hello,
> >>
> >> This series is a collection of fixes and improvements for the
> >> atmel-hlcdc driver.
> >>
> >> The main feature added here is the support for external RGB -> XXX
> >> bridges (patch 6 and 7).
> >>
> >> The first patch is a fix preventing a potential memory leak.
> >> Patch 2 is adding support for asynchronous mode setting, which was
> >> supported before the migration to atomic mode setting.
> >>
> >> Patch 3 is just a minor fix to expose the real encoder and connector
> >> types (we are currently exposing an LVDS encoder/connector, which is
> >> wrong since the display controller output the pixel stream in raw
> >> RGB).
> >>
> >> Patch 4 is removing useless fields and functions which were left
> >> when moving to atomic modesetting.
> >>
> >> And patch 8 is just a cosmetic patch moving the mode checking code
> >> from ->atomic_check() to ->mode_fixup().
> >
> > Dave, Daniel, any comment on this series (AKA ping)?
> 
> On internal driver stuff, I'd usually only look on a git pull :-)

Yep, Daniel told me that both of you usually don't review internal
driver changes. I'll send a PR soon (after the merge window of course).

Thanks,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[PATCH v2 1/9] drm: atmel-hlcdc: add a ->cleanup_fb() operation

[Boris Brezillon]

Hi Daniel,

On Wed, 16 Mar 2016 16:17:38 +0100
Daniel Vetter  wrote:

> On Wed, Mar 16, 2016 at 02:57:35PM +0100, Boris Brezillon wrote:
> > Add a ->cleanup_fb() operation to avoid memory leaks when the atomic
> > operation is interrupted after the ->prepare_fb() call.
> > 
> > Signed-off-by: Boris Brezillon 
> > Fixes 2389fc1 ("drm: atmel-hlcdc: Atomic mode-setting conversion")
> > Reviewed-by: Nicolas Ferre 
> > Tested-by: Nicolas Ferre 
> > ---
> >  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h|  2 ++
> >  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 22 +++---
> >  2 files changed, 21 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h 
> > b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
> > index fed517f..ec64140 100644
> > --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
> > +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
> > @@ -81,11 +81,13 @@ struct atmel_hlcdc_plane_properties {
> >   * @layer: HLCDC layer structure
> >   * @properties: pointer to the property definitions structure
> >   * @rotation: current rotation status
> > + * @prepared: flagging the plane has prepared for an atomic update
> >   */
> >  struct atmel_hlcdc_plane {
> > struct drm_plane base;
> > struct atmel_hlcdc_layer layer;
> > struct atmel_hlcdc_plane_properties *properties;
> > +   bool prepared;
> >  };
> >  
> >  static inline struct atmel_hlcdc_plane *
> > diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c 
> > b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> > index 1ffe9c3..35027d0 100644
> > --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> > +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> > @@ -715,11 +715,25 @@ static int atmel_hlcdc_plane_prepare_fb(struct 
> > drm_plane *p,
> > const struct drm_plane_state *new_state)
> >  {
> > struct atmel_hlcdc_plane *plane = drm_plane_to_atmel_hlcdc_plane(p);
> > +   int ret;
> >  
> > -   if (!new_state->fb)
> > -   return 0;
> > +   ret = atmel_hlcdc_layer_update_start(>layer);
> > +   if (!ret)
> > +   plane->prepared = true;
> 
> Atomic helpers will keep track of this for you, and only call ->cleanup_fb
> on a plane combo where it did (successfully) call ->prepare_fb.

Hm, it's not exactly encoding the same thing. What I want to do here is
call atmel_hlcdc_layer_update_rollback() only if the atomic update has
failed (see below, I set ->prepared back to false in the
->atomic_update() method). AFAICT, ->cleanup_fb() is also called
when the whole operation succeed (and in this case I don't want to
call atmel_hlcdc_layer_update_rollback()).

Let me know if you see a better approach to do that.

Thanks,

Boris

> -Daniel
> 
> > +
> > +   return ret;
> > +}
> > +
> > +static void atmel_hlcdc_plane_cleanup_fb(struct drm_plane *p,
> > +   const struct drm_plane_state *old_state)
> > +{
> > +   struct atmel_hlcdc_plane *plane = drm_plane_to_atmel_hlcdc_plane(p);
> > +
> > +   if (!plane->prepared)
> > +   return;
> >  
> > -   return atmel_hlcdc_layer_update_start(>layer);
> > +   atmel_hlcdc_layer_update_rollback(>layer);
> > +   plane->prepared = false;
> >  }
> >  
> >  static void atmel_hlcdc_plane_atomic_update(struct drm_plane *p,
> > @@ -739,6 +753,7 @@ static void atmel_hlcdc_plane_atomic_update(struct 
> > drm_plane *p,
> > atmel_hlcdc_plane_update_disc_area(plane, state);
> >  
> > atmel_hlcdc_layer_update_commit(>layer);
> > +   plane->prepared = false;
> >  }
> >  
> >  static void atmel_hlcdc_plane_atomic_disable(struct drm_plane *p,
> > @@ -844,6 +859,7 @@ static void atmel_hlcdc_plane_init_properties(struct 
> > atmel_hlcdc_plane *plane,
> >  
> >  static struct drm_plane_helper_funcs atmel_hlcdc_layer_plane_helper_funcs 
> > = {
> > .prepare_fb = atmel_hlcdc_plane_prepare_fb,
> > +   .cleanup_fb = atmel_hlcdc_plane_cleanup_fb,
> > .atomic_check = atmel_hlcdc_plane_atomic_check,
> > .atomic_update = atmel_hlcdc_plane_atomic_update,
> > .atomic_disable = atmel_hlcdc_plane_atomic_disable,
> > -- 
> > 2.5.0
> > 
> 



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[PATCH] drm/sti: restore mode_fixup callback

[Arnd Bergmann]

Commit 8a2fa38fddd3 removed the mode_fixup because it was empty,
but 652353e6e561 modified it to call drm_mode_set_crtcinfo()
instead.

Both commits are correct, but the merge of the two kept the nonempty
version without the reference to it, as shown by the gcc warning:

 drm/sti/sti_crtc.c:54:13: error: 'sti_crtc_mode_fixup' defined but not used

This restores the callback pointer to fix the merge.

Signed-off-by: Arnd Bergmann 
Reverts: 8a2fa38fddd3 ("drm/sti: removed optional dummy crtc mode_fixup 
function.")
Fixes: 652353e6e561 ("drm/sti: set CRTC modesetting parameters")
Fixes: cf481068cdd4 ("Merge branch '2016-02-26-st-drm-next' of 
http://git.linaro.org/people/benjamin.gaignard/kernel into drm-next")
---
 drivers/gpu/drm/sti/sti_crtc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/sti/sti_crtc.c b/drivers/gpu/drm/sti/sti_crtc.c
index fa47f63b5316..505620c7c2c8 100644
--- a/drivers/gpu/drm/sti/sti_crtc.c
+++ b/drivers/gpu/drm/sti/sti_crtc.c
@@ -230,6 +230,7 @@ static void sti_crtc_atomic_flush(struct drm_crtc *crtc,
 static const struct drm_crtc_helper_funcs sti_crtc_helper_funcs = {
.enable = sti_crtc_enable,
.disable = sti_crtc_disabling,
+   .mode_fixup = sti_crtc_mode_fixup,
.mode_set = drm_helper_crtc_mode_set,
.mode_set_nofb = sti_crtc_mode_set_nofb,
.mode_set_base = drm_helper_crtc_mode_set_base,
-- 
2.7.0

[PATCH v7 3/6] ASoC: hdmi-codec: Add audio abort() callback for video side to use

[Jyri Sarha]

Add audio abort() callback, that is provided at audio stream start,
for video side. This is for video side to use in case there is a
pressing need to tear down the audio playback for some reason.

Signed-off-by: Jyri Sarha 
---
 include/sound/hdmi-codec.h|  8 ++--
 sound/soc/codecs/hdmi-codec.c | 20 +++-
 2 files changed, 25 insertions(+), 3 deletions(-)

diff --git a/include/sound/hdmi-codec.h b/include/sound/hdmi-codec.h
index fc3a481..15fe70f 100644
--- a/include/sound/hdmi-codec.h
+++ b/include/sound/hdmi-codec.h
@@ -55,10 +55,14 @@ struct hdmi_codec_params {

 struct hdmi_codec_ops {
/*
-* Called when ASoC starts an audio stream setup.
+* Called when ASoC starts an audio stream setup. The call
+* provides an audio abort callback for stoping an ongoing
+* stream from video side driver if the HDMI audio becomes
+* unavailable.
 * Optional
 */
-   int (*audio_startup)(struct device *dev);
+   int (*audio_startup)(struct device *dev,
+void (*abort_cb)(struct device *dev));

/*
 * Configures HDMI-encoder for audio stream.
diff --git a/sound/soc/codecs/hdmi-codec.c b/sound/soc/codecs/hdmi-codec.c
index bc47b9a..cc08097 100644
--- a/sound/soc/codecs/hdmi-codec.c
+++ b/sound/soc/codecs/hdmi-codec.c
@@ -47,6 +47,23 @@ enum {
DAI_ID_SPDIF,
 };

+static void hdmi_codec_abort(struct device *dev)
+{
+   struct hdmi_codec_priv *hcp = dev_get_drvdata(dev);
+
+   dev_dbg(dev, "%s()\n", __func__);
+
+   mutex_lock(>current_stream_lock);
+   if (hcp->current_stream && hcp->current_stream->runtime &&
+   snd_pcm_running(hcp->current_stream)) {
+   dev_info(dev, "HDMI audio playback aborted\n");
+   snd_pcm_stream_lock_irq(hcp->current_stream);
+   snd_pcm_stop(hcp->current_stream, SNDRV_PCM_STATE_DISCONNECTED);
+   snd_pcm_stream_unlock_irq(hcp->current_stream);
+   }
+   mutex_unlock(>current_stream_lock);
+}
+
 static int hdmi_codec_new_stream(struct snd_pcm_substream *substream,
 struct snd_soc_dai *dai)
 {
@@ -78,7 +95,8 @@ static int hdmi_codec_startup(struct snd_pcm_substream 
*substream,
return ret;

if (hcp->hcd.ops->audio_startup) {
-   ret = hcp->hcd.ops->audio_startup(dai->dev->parent);
+   ret = hcp->hcd.ops->audio_startup(dai->dev->parent,
+ hdmi_codec_abort);
if (ret) {
mutex_lock(>current_stream_lock);
hcp->current_stream = NULL;
-- 
1.9.1

[PATCH v7 2/6] ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders

[Jyri Sarha]

The hdmi-codec is a platform device driver to be registered from
drivers of external HDMI encoders with I2S and/or spdif interface. The
driver in turn registers an ASoC codec for the HDMI encoder's audio
functionality.

The structures and definitions in the API header are mostly redundant
copies of similar structures in ASoC headers. This is on purpose to
avoid direct dependencies to ASoC structures in video side driver.

Signed-off-by: Jyri Sarha 
Acked-by: Arnaud Pouliquen 
Tested-by: Philipp Zabel 
---
 include/sound/hdmi-codec.h| 100 +++
 sound/soc/codecs/Kconfig  |   6 +
 sound/soc/codecs/Makefile |   2 +
 sound/soc/codecs/hdmi-codec.c | 393 ++
 4 files changed, 501 insertions(+)
 create mode 100644 include/sound/hdmi-codec.h
 create mode 100644 sound/soc/codecs/hdmi-codec.c

diff --git a/include/sound/hdmi-codec.h b/include/sound/hdmi-codec.h
new file mode 100644
index 000..fc3a481
--- /dev/null
+++ b/include/sound/hdmi-codec.h
@@ -0,0 +1,100 @@
+/*
+ * hdmi-codec.h - HDMI Codec driver API
+ *
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Author: Jyri Sarha 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ */
+
+#ifndef __HDMI_CODEC_H__
+#define __HDMI_CODEC_H__
+
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * Protocol between ASoC cpu-dai and HDMI-encoder
+ */
+struct hdmi_codec_daifmt {
+   enum {
+   HDMI_I2S,
+   HDMI_RIGHT_J,
+   HDMI_LEFT_J,
+   HDMI_DSP_A,
+   HDMI_DSP_B,
+   HDMI_AC97,
+   HDMI_SPDIF,
+   } fmt;
+   int bit_clk_inv:1;
+   int frame_clk_inv:1;
+   int bit_clk_master:1;
+   int frame_clk_master:1;
+};
+
+/*
+ * HDMI audio parameters
+ */
+struct hdmi_codec_params {
+   struct hdmi_audio_infoframe cea;
+   struct snd_aes_iec958 iec;
+   int sample_rate;
+   int sample_width;
+   int channels;
+};
+
+struct hdmi_codec_ops {
+   /*
+* Called when ASoC starts an audio stream setup.
+* Optional
+*/
+   int (*audio_startup)(struct device *dev);
+
+   /*
+* Configures HDMI-encoder for audio stream.
+* Mandatory
+*/
+   int (*hw_params)(struct device *dev,
+struct hdmi_codec_daifmt *fmt,
+struct hdmi_codec_params *hparms);
+
+   /*
+* Shuts down the audio stream.
+* Mandatory
+*/
+   void (*audio_shutdown)(struct device *dev);
+
+   /*
+* Mute/unmute HDMI audio stream.
+* Optional
+*/
+   int (*digital_mute)(struct device *dev, bool enable);
+
+   /*
+* Provides EDID-Like-Data from connected HDMI device.
+* Optional
+*/
+   int (*get_eld)(struct device *dev, uint8_t *buf, size_t len);
+};
+
+/* HDMI codec initalization data */
+struct hdmi_codec_pdata {
+   const struct hdmi_codec_ops *ops;
+   uint i2s:1;
+   uint spdif:1;
+   int max_i2s_channels;
+};
+
+#define HDMI_CODEC_DRV_NAME "hdmi-audio-codec"
+
+#endif /* __HDMI_CODEC_H__ */
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 50693c8..62b62fe 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -86,6 +86,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_MC13783 if MFD_MC13XXX
select SND_SOC_ML26124 if I2C
select SND_SOC_NAU8825 if I2C
+   select SND_SOC_HDMI_CODEC
select SND_SOC_PCM1681 if I2C
select SND_SOC_PCM179X if SPI_MASTER
select SND_SOC_PCM3008
@@ -473,6 +474,11 @@ config SND_SOC_BT_SCO
 config SND_SOC_DMIC
tristate

+config SND_SOC_HDMI_CODEC
+   tristate
+   select SND_PCM_ELD
+   select SND_PCM_IEC958
+
 config SND_SOC_ES8328
tristate "Everest Semi ES8328 CODEC"

diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index d44f7d3..5f7b002 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -79,6 +79,7 @@ snd-soc-max9850-objs := max9850.o
 snd-soc-mc13783-objs := mc13783.o
 snd-soc-ml26124-objs := ml26124.o
 snd-soc-nau8825-objs := nau8825.o
+snd-soc-hdmi-codec-objs := hdmi-codec.o
 snd-soc-pcm1681-objs := pcm1681.o
 snd-soc-pcm179x-codec-objs := pcm179x.o
 snd-soc-pcm3008-objs := pcm3008.o
@@ -283,6 +284,7 @@ obj-$(CONFIG_SND_SOC_MAX9850)   += snd-soc-max9850.o
 obj-$(CONFIG_SND_SOC_MC13783)  += snd-soc-mc13783.o
 obj-$(CONFIG_SND_SOC_ML26124)  += snd-soc-ml26124.o
 obj-$(CONFIG_SND_SOC_NAU8825)   += snd-soc-nau8825.o

[PATCH v7 0/6] Implement generic ASoC HDMI codec and use it in tda998x

[Jyri Sarha]

Not much have changed since v6[1] patch series. I did everything
addressed every comment, mostly by robots :), to previous series and
there was one bug fixed in tda998x side. Unless there is any
significant reaction to this series, I am going to put it to rest for
a while now. I have other things to do.

There is currently two other patch series[2][3] that depend on the
first two (ALSA-) patches of this series. The third ("ASoC:
hdmi-codec: Add audio abort() callback for video side to use") is
currently not used and can be dropped if so decided. The rest depends
on those the first two and adds hdmi-audio support for
Beaglebone-black.

Best regards,
Jyri

[1] "[PATCH v6 0/6] Implement generic ASoC HDMI codec and use it in tda998x"
http://mailman.alsa-project.org/pipermail/alsa-devel/2016-March/105524.html
[2] "[PATCH v6 00/10] ASoC: Add mediatek HDMI codec support" by Philipp Zabel 
http://mailman.alsa-project.org/pipermail/alsa-devel/2016-March/105509.html
[3] "[RFC v2 0/6] sti: add audio interface to the hdmi driver"

http://mailman.alsa-project.org/pipermail/alsa-devel/2016-January/103374.html
and "[PATCH v4 0/6] add IEC958 channel status control helpers"
http://mailman.alsa-project.org/pipermail/alsa-devel/2016-March/105502.html
by Arnaud Pouliquen

Changes since v6
* "ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders"
 - Add "Acked-by: Arnaud Pouliquen " and
   "Tested-by: Philipp Zabel ", no other changes
* "ALSA: pcm: add IEC958 channel status helper for hw_param"
 - Added kernel-doc for snd_pcm_create_iec958_consumer_hw_params()
* "drm/i2c: tda998x: Register ASoC hdmi-codec and add audio DT binding"
 - Use PTR_ERR_OR_ZERO() in tda998x_audio_codec_init()
 - Fix possible uninitialized use of 'size' in tda998x_get_audio_ports()
 - Store audio configuration in tda998x_audio_hw_params() instead of
   tda998x_configure_audio().

Changes since v5
 - Rebased on top of the latest drm-next branch
 - Allow 32 bit samplewidth in snd_pcm_create_iec958_consumer() and
   snd_pcm_create_iec958_consumer_hw_params()
 - Propose new simpler DT binding for tda998x audio
 - Squash tda998x audio DT binding together with hdmi-codec integration

Changes since RFC v4,
 - Rebased on top of the latest drm-next branch
 - Split the hdmi-codec abort functionality into a separate patch for
   better visibility of what it is all about
   - This does not affect the tda998x patches as the abort
 functionality is not used
 - Drop S18_3* formats from I2S_FORMATS and add a comment about formats
   not supported by HDMI

Changes since RFC v3,
 ASoC side:
 - Add "ALSA: pcm: add IEC958 channel status helper for hw_params"
 - Add "tda998x: Improve tda998x_configure_audio() audio related pdata"
 - use snd_pcm_create_iec958_consumer_hw_params() to construct the stream header
 - Remove set_clk() callback from hdmi-codec. It is not needed for now.
 - Refer to stream header in AIF as specified in HDMI standard
 - Set current_stream to NULL only after video side audio_shutdown() has
   been called. Avoid potential race if video side attempts to abort audio
   at the same time.
 - No need to have video side device pointer in the hdmi codec's pdata as
   it is found from dev->parent.
 - Fix hdmi-codec enum: DAI_ID_I2C > DAI_ID_I2S
 - Improve audio_startup API comment
 - Make improved checkpatch happy 
   - BUG_ON > WARN_ON
   - put */ ending the block comment to a separate line

 DRM side:
 - Fix tda998x get_eld() locking
 - Change tda998x audio parameters in pdata to more generic, that can
   be readily used in tda998x_audio_config()
 - Rename and restructure audio port related private data members to
   be more descriptive
 - Require audio configuration trough ASoC hdmi-codec if HDMI audio is
   configured trough DT binding. 

 DTS:
 - Increase McASP fifo usage form 1 to 32


Jyri Sarha (6):
  ALSA: pcm: add IEC958 channel status helper for hw_params
  ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders
  ASoC: hdmi-codec: Add audio abort() callback for video side to use
  drm/i2c: tda998x: Improve tda998x_configure_audio() audio related
pdata
  drm/i2c: tda998x: Register ASoC hdmi-codec and add audio DT binding
  ARM: dts: am335x-boneblack: Add HDMI audio support

 .../devicetree/bindings/display/bridge/tda998x.txt |  18 +
 arch/arm/boot/dts/am335x-boneblack.dts |  71 +++-
 drivers/gpu/drm/i2c/Kconfig|   1 +
 drivers/gpu/drm/i2c/tda998x_drv.c  | 276 --
 include/drm/i2c/tda998x.h  |  24 +-
 include/dt-bindings/display/tda998x.h  |   7 +
 include/sound/hdmi-codec.h | 104 ++
 include/sound/pcm_iec958.h |   2 +
 sound/core/pcm_iec958.c|  65 +++-
 sound/soc/codecs/Kconfig   |   6 +
 sound/soc/codecs/Makefile  |   2 +
 sound/soc/codecs/hdmi-codec.c  | 411 

[PATCH v7 1/6] ALSA: pcm: add IEC958 channel status helper for hw_params

[Jyri Sarha]

Add IEC958 channel status helper that gets the audio properties from
snd_pcm_hw_params instead of snd_pcm_runtime. This is needed to
produce the channel status bits already in audio stream configuration
phase.

Signed-off-by: Jyri Sarha 
---
 include/sound/pcm_iec958.h |  2 ++
 sound/core/pcm_iec958.c| 65 ++
 2 files changed, 50 insertions(+), 17 deletions(-)

diff --git a/include/sound/pcm_iec958.h b/include/sound/pcm_iec958.h
index 0eed397..36f023a 100644
--- a/include/sound/pcm_iec958.h
+++ b/include/sound/pcm_iec958.h
@@ -6,4 +6,6 @@
 int snd_pcm_create_iec958_consumer(struct snd_pcm_runtime *runtime, u8 *cs,
size_t len);

+int snd_pcm_create_iec958_consumer_hw_params(struct snd_pcm_hw_params *params,
+u8 *cs, size_t len);
 #endif
diff --git a/sound/core/pcm_iec958.c b/sound/core/pcm_iec958.c
index 36b2d7a..5e6aed6 100644
--- a/sound/core/pcm_iec958.c
+++ b/sound/core/pcm_iec958.c
@@ -9,30 +9,18 @@
 #include 
 #include 
 #include 
+#include 
 #include 

-/**
- * snd_pcm_create_iec958_consumer - create consumer format IEC958 channel 
status
- * @runtime: pcm runtime structure with ->rate filled in
- * @cs: channel status buffer, at least four bytes
- * @len: length of channel status buffer
- *
- * Create the consumer format channel status data in @cs of maximum size
- * @len corresponding to the parameters of the PCM runtime @runtime.
- *
- * Drivers may wish to tweak the contents of the buffer after creation.
- *
- * Returns: length of buffer, or negative error code if something failed.
- */
-int snd_pcm_create_iec958_consumer(struct snd_pcm_runtime *runtime, u8 *cs,
-   size_t len)
+static int create_iec958_consumer(uint rate, uint sample_width,
+ u8 *cs, size_t len)
 {
unsigned int fs, ws;

if (len < 4)
return -EINVAL;

-   switch (runtime->rate) {
+   switch (rate) {
case 32000:
fs = IEC958_AES3_CON_FS_32000;
break;
@@ -59,7 +47,7 @@ int snd_pcm_create_iec958_consumer(struct snd_pcm_runtime 
*runtime, u8 *cs,
}

if (len > 4) {
-   switch (snd_pcm_format_width(runtime->format)) {
+   switch (sample_width) {
case 16:
ws = IEC958_AES4_CON_WORDLEN_20_16;
break;
@@ -71,6 +59,7 @@ int snd_pcm_create_iec958_consumer(struct snd_pcm_runtime 
*runtime, u8 *cs,
 IEC958_AES4_CON_MAX_WORDLEN_24;
break;
case 24:
+   case 32: /* Assume 24-bit width for 32-bit samples. */
ws = IEC958_AES4_CON_WORDLEN_24_20 |
 IEC958_AES4_CON_MAX_WORDLEN_24;
break;
@@ -92,4 +81,46 @@ int snd_pcm_create_iec958_consumer(struct snd_pcm_runtime 
*runtime, u8 *cs,

return len;
 }
+
+/**
+ * snd_pcm_create_iec958_consumer - create consumer format IEC958 channel 
status
+ * @runtime: pcm runtime structure with ->rate filled in
+ * @cs: channel status buffer, at least four bytes
+ * @len: length of channel status buffer
+ *
+ * Create the consumer format channel status data in @cs of maximum size
+ * @len corresponding to the parameters of the PCM runtime @runtime.
+ *
+ * Drivers may wish to tweak the contents of the buffer after creation.
+ *
+ * Returns: length of buffer, or negative error code if something failed.
+ */
+int snd_pcm_create_iec958_consumer(struct snd_pcm_runtime *runtime, u8 *cs,
+   size_t len)
+{
+   return create_iec958_consumer(runtime->rate,
+ snd_pcm_format_width(runtime->format),
+ cs, len);
+}
 EXPORT_SYMBOL(snd_pcm_create_iec958_consumer);
+
+/**
+ * snd_pcm_create_iec958_consumer_hw_params - create IEC958 channel status
+ * @hw_params: the hw_params instance for extracting rate and sample format
+ * @cs: channel status buffer, at least four bytes
+ * @len: length of channel status buffer
+ *
+ * Create the consumer format channel status data in @cs of maximum size
+ * @len corresponding to the parameters of the PCM runtime @runtime.
+ *
+ * Drivers may wish to tweak the contents of the buffer after creation.
+ *
+ * Returns: length of buffer, or negative error code if something failed.
+ */
+int snd_pcm_create_iec958_consumer_hw_params(struct snd_pcm_hw_params *params,
+u8 *cs, size_t len)
+{
+   return create_iec958_consumer(params_rate(params), params_width(params),
+ cs, len);
+}
+EXPORT_SYMBOL(snd_pcm_create_iec958_consumer_hw_params);
-- 
1.9.1

[PATCH v7 4/6] drm/i2c: tda998x: Improve tda998x_configure_audio() audio related pdata

[Jyri Sarha]

Define struct tda998x_audio_params in include/drm/i2c/tda998x.h and
use it in pdata and for tda998x_configure_audio() parameters. Also
updates tda998x_write_aif() to take struct hdmi_audio_infoframe *
directly as a parameter.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/i2c/tda998x_drv.c | 77 ---
 include/drm/i2c/tda998x.h | 24 +++-
 2 files changed, 53 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index f4315bc..f97b748 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -41,7 +41,7 @@ struct tda998x_priv {
u8 vip_cntrl_0;
u8 vip_cntrl_1;
u8 vip_cntrl_2;
-   struct tda998x_encoder_params params;
+   struct tda998x_audio_params audio_params;

wait_queue_head_t wq_edid;
volatile int wq_edid_wait;
@@ -666,26 +666,16 @@ tda998x_write_if(struct tda998x_priv *priv, u8 bit, u16 
addr,
reg_set(priv, REG_DIP_IF_FLAGS, bit);
 }

-static void
-tda998x_write_aif(struct tda998x_priv *priv, struct tda998x_encoder_params *p)
+static int tda998x_write_aif(struct tda998x_priv *priv,
+struct hdmi_audio_infoframe *cea)
 {
union hdmi_infoframe frame;

-   hdmi_audio_infoframe_init();
-
-   frame.audio.channels = p->audio_frame[1] & 0x07;
-   frame.audio.channel_allocation = p->audio_frame[4];
-   frame.audio.level_shift_value = (p->audio_frame[5] & 0x78) >> 3;
-   frame.audio.downmix_inhibit = (p->audio_frame[5] & 0x80) >> 7;
-
-   /*
-* L-PCM and IEC61937 compressed audio shall always set sample
-* frequency to "refer to stream".  For others, see the HDMI
-* specification.
-*/
-   frame.audio.sample_frequency = (p->audio_frame[2] & 0x1c) >> 2;
+   frame.audio = *cea;

tda998x_write_if(priv, DIP_IF_FLAGS_IF4, REG_IF4_HB0, );
+
+   return 0;
 }

 static void
@@ -710,20 +700,21 @@ static void tda998x_audio_mute(struct tda998x_priv *priv, 
bool on)
}
 }

-static void
+static int
 tda998x_configure_audio(struct tda998x_priv *priv,
-   struct drm_display_mode *mode, struct tda998x_encoder_params *p)
+   struct tda998x_audio_params *params,
+   unsigned mode_clock)
 {
u8 buf[6], clksel_aip, clksel_fs, cts_n, adiv;
u32 n;

/* Enable audio ports */
-   reg_write(priv, REG_ENA_AP, p->audio_cfg);
-   reg_write(priv, REG_ENA_ACLK, p->audio_clk_cfg);
+   reg_write(priv, REG_ENA_AP, params->config);

/* Set audio input source */
-   switch (p->audio_format) {
+   switch (params->format) {
case AFMT_SPDIF:
+   reg_write(priv, REG_ENA_ACLK, 0);
reg_write(priv, REG_MUX_AP, MUX_AP_SELECT_SPDIF);
clksel_aip = AIP_CLKSEL_AIP_SPDIF;
clksel_fs = AIP_CLKSEL_FS_FS64SPDIF;
@@ -731,15 +722,29 @@ tda998x_configure_audio(struct tda998x_priv *priv,
break;

case AFMT_I2S:
+   reg_write(priv, REG_ENA_ACLK, 1);
reg_write(priv, REG_MUX_AP, MUX_AP_SELECT_I2S);
clksel_aip = AIP_CLKSEL_AIP_I2S;
clksel_fs = AIP_CLKSEL_FS_ACLK;
-   cts_n = CTS_N_M(3) | CTS_N_K(3);
+   switch (params->sample_width) {
+   case 16:
+   cts_n = CTS_N_M(3) | CTS_N_K(1);
+   break;
+   case 18:
+   case 20:
+   case 24:
+   cts_n = CTS_N_M(3) | CTS_N_K(2);
+   break;
+   default:
+   case 32:
+   cts_n = CTS_N_M(3) | CTS_N_K(3);
+   break;
+   }
break;

default:
BUG();
-   return;
+   return -EINVAL;
}

reg_write(priv, REG_AIP_CLKSEL, clksel_aip);
@@ -755,11 +760,11 @@ tda998x_configure_audio(struct tda998x_priv *priv,
 * assume 100MHz requires larger divider.
 */
adiv = AUDIO_DIV_SERCLK_8;
-   if (mode->clock > 10)
+   if (mode_clock > 10)
adiv++; /* AUDIO_DIV_SERCLK_16 */

/* S/PDIF asks for a larger divider */
-   if (p->audio_format == AFMT_SPDIF)
+   if (params->format == AFMT_SPDIF)
adiv++; /* AUDIO_DIV_SERCLK_16 or _32 */

reg_write(priv, REG_AUDIO_DIV, adiv);
@@ -768,7 +773,7 @@ tda998x_configure_audio(struct tda998x_priv *priv,
 * This is the approximate value of N, which happens to be
 * the recommended values for non-coherent clocks.
 */
-   n = 128 * p->audio_sample_rate / 1000;
+   n = 128 * params->sample_rate / 1000;

/* Write the CTS and N values */
buf[0] = 0x44;
@@ -787,19 +792,13 @@ 

[PATCH v7 5/6] drm/i2c: tda998x: Register ASoC hdmi-codec and add audio DT binding

[Jyri Sarha]

Register ASoC HDMI codec for audio functionality and adds device tree
binding for audio configuration.

With the registered HDMI codec the tda998x node can be used like a
regular codec node in ASoC card configurations. HDMI audio info-frame
and audio stream header is generated by the ASoC HDMI codec. The codec
also applies constraints for available sample-rates based on Edid Like
Data from the display. The device tree binding document has been
updated [1].

Part of this patch has been inspired by Jean Francoise's "drm/i2c: tda998x:
Add support of a DT graph of ports"-patch [2]. There may still be some
identical lines left from the original patch and some of the ideas
have come from there.

[1] Documentation/devicetree/bindings/display/bridge/tda998x.txt
[2] http://mailman.alsa-project.org/pipermail/alsa-devel/2015-July/095255.html

Signed-off-by: Jyri Sarha 
---
 .../devicetree/bindings/display/bridge/tda998x.txt |  18 ++
 drivers/gpu/drm/i2c/Kconfig|   1 +
 drivers/gpu/drm/i2c/tda998x_drv.c  | 199 -
 include/drm/i2c/tda998x.h  |   4 +-
 include/dt-bindings/display/tda998x.h  |   7 +
 5 files changed, 224 insertions(+), 5 deletions(-)
 create mode 100644 include/dt-bindings/display/tda998x.h

diff --git a/Documentation/devicetree/bindings/display/bridge/tda998x.txt 
b/Documentation/devicetree/bindings/display/bridge/tda998x.txt
index e178e6b..24cc246 100644
--- a/Documentation/devicetree/bindings/display/bridge/tda998x.txt
+++ b/Documentation/devicetree/bindings/display/bridge/tda998x.txt
@@ -21,8 +21,19 @@ Optional properties:
   - video-ports: 24 bits value which defines how the video controller
output is wired to the TDA998x input - default: <0x230145>

+  - audio-ports: array of 8-bit values, 2 values per one DAI[1].
+   The first value defines the DAI type: TDA998x_SPDIF or TDA998x_I2S[2].
+   The second value defines the tda998x AP_ENA reg content when the DAI
+   in question is used. The implementation allows one or two DAIs. If two
+   DAIs are defined, they must be of different type.
+
+[1] Documentation/sound/alsa/soc/DAI.txt
+[2] include/dt-bindings/display/tda998x.h
+
 Example:

+#include 
+
tda998x: hdmi-encoder {
compatible = "nxp,tda998x";
reg = <0x70>;
@@ -30,4 +41,11 @@ Example:
interrupts = <27 2>;/* falling edge */
pinctrl-0 = <_camera>;
pinctrl-names = "default";
+   video-ports = <0x230145>;
+
+   #sound-dai-cells = <2>;
+/* DAI-format  AP_ENA reg value */
+   audio-ports = < TDA998x_SPDIF   0x04
+   TDA998x_I2S 0x03>;
+
};
diff --git a/drivers/gpu/drm/i2c/Kconfig b/drivers/gpu/drm/i2c/Kconfig
index 22c7ed6..088f278 100644
--- a/drivers/gpu/drm/i2c/Kconfig
+++ b/drivers/gpu/drm/i2c/Kconfig
@@ -28,6 +28,7 @@ config DRM_I2C_SIL164
 config DRM_I2C_NXP_TDA998X
tristate "NXP Semiconductors TDA998X HDMI encoder"
default m if DRM_TILCDC
+   select SND_SOC_HDMI_CODEC if SND_SOC
help
  Support for NXP Semiconductors TDA998X HDMI encoders.

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index f97b748..a0dccf9 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
@@ -30,6 +31,11 @@

 #define DBG(fmt, ...) DRM_DEBUG(fmt"\n", ##__VA_ARGS__)

+struct tda998x_audio_port {
+   u8 format;  /* AFMT_xxx */
+   u8 config;  /* AP value */
+};
+
 struct tda998x_priv {
struct i2c_client *cec;
struct i2c_client *hdmi;
@@ -43,6 +49,8 @@ struct tda998x_priv {
u8 vip_cntrl_2;
struct tda998x_audio_params audio_params;

+   struct platform_device *audio_pdev;
+
wait_queue_head_t wq_edid;
volatile int wq_edid_wait;

@@ -53,6 +61,8 @@ struct tda998x_priv {

struct drm_encoder encoder;
struct drm_connector connector;
+
+   struct tda998x_audio_port audio_port[2];
 };

 #define conn_to_tda998x_priv(x) \
@@ -707,6 +717,7 @@ tda998x_configure_audio(struct tda998x_priv *priv,
 {
u8 buf[6], clksel_aip, clksel_fs, cts_n, adiv;
u32 n;
+   int ret;

/* Enable audio ports */
reg_write(priv, REG_ENA_AP, params->config);
@@ -743,7 +754,7 @@ tda998x_configure_audio(struct tda998x_priv *priv,
break;

default:
-   BUG();
+   dev_err(>hdmi->dev, "Unsupported I2S format\n");
return -EINVAL;
}

@@ -1160,6 +1171,8 @@ static int tda998x_connector_get_modes(struct 
drm_connector *connector)
drm_mode_connector_update_edid_property(connector, edid);
n = drm_add_edid_modes(connector, edid);

[PATCH v7 6/6] ARM: dts: am335x-boneblack: Add HDMI audio support

[Jyri Sarha]

Add HDMI audio support. Adds mcasp0_pins, clk_mcasp0_fixed,
clk_mcasp0, mcasp0, sound node, and updates the tda19988 node to
follow the new binding.

Signed-off-by: Jyri Sarha 
---
 arch/arm/boot/dts/am335x-boneblack.dts | 71 --
 1 file changed, 67 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-boneblack.dts 
b/arch/arm/boot/dts/am335x-boneblack.dts
index 55c0e95..2bae4d1 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -9,6 +9,7 @@

 #include "am33xx.dtsi"
 #include "am335x-bone-common.dtsi"
+#include 

 / {
model = "TI AM335x BeagleBone Black";
@@ -64,6 +65,16 @@
AM33XX_IOPAD(0x9b0, PIN_OUTPUT_PULLDOWN | MUX_MODE3)
/* xdma_event_intr0 */
>;
};
+
+   mcasp0_pins: mcasp0_pins {
+   pinctrl-single,pins = <
+   AM33XX_IOPAD(0x9ac, PIN_INPUT_PULLUP | MUX_MODE0) /* 
mcasp0_ahcklx.mcasp0_ahclkx */
+   AM33XX_IOPAD(0x99c, PIN_OUTPUT_PULLDOWN | MUX_MODE2) /* 
mcasp0_ahclkr.mcasp0_axr2*/
+   AM33XX_IOPAD(0x994, PIN_OUTPUT_PULLUP | MUX_MODE0) /* 
mcasp0_fsx.mcasp0_fsx */
+   AM33XX_IOPAD(0x990, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* 
mcasp0_aclkx.mcasp0_aclkx */
+   AM33XX_IOPAD(0x86c, PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* 
gpmc_a11.GPIO1_27 */
+   >;
+   };
 };

  {
@@ -76,16 +87,22 @@
 };

  {
-   tda19988 {
+   tda19988: tda19988 {
compatible = "nxp,tda998x";
reg = <0x70>;
+
pinctrl-names = "default", "off";
pinctrl-0 = <_hdmi_bonelt_pins>;
pinctrl-1 = <_hdmi_bonelt_off_pins>;

-   port {
-   hdmi_0: endpoint at 0 {
-   remote-endpoint = <_0>;
+   #sound-dai-cells = <0>;
+   audio-ports = < AFMT_I2S0x03>;
+
+   ports {
+   port at 0 {
+   hdmi_0: endpoint at 0 {
+   remote-endpoint = <_0>;
+   };
};
};
};
@@ -94,3 +111,49 @@
  {
system-power-controller;
 };
+
+{
+   #sound-dai-cells = <0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   status = "okay";
+   op-mode = <0>;  /* MCASP_IIS_MODE */
+   tdm-slots = <2>;
+   serial-dir = <  /* 0: INACTIVE, 1: TX, 2: RX */
+   0 0 1 0
+   >;
+   tx-num-evt = <32>;
+   rx-num-evt = <32>;
+};
+
+/ {
+   clk_mcasp0_fixed: clk_mcasp0_fixed {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <24576000>;
+   };
+
+   clk_mcasp0: clk_mcasp0 {
+   #clock-cells = <0>;
+   compatible = "gpio-gate-clock";
+   clocks = <_mcasp0_fixed>;
+   enable-gpios = < 27 0>; /* BeagleBone Black Clk enable on 
GPIO1_27 */
+   };
+
+   sound {
+   compatible = "simple-audio-card";
+   simple-audio-card,name = "TI BeagleBone Black";
+   simple-audio-card,format = "i2s";
+   simple-audio-card,bitclock-master = <_master>;
+   simple-audio-card,frame-master = <_master>;
+
+   dailink0_master: simple-audio-card,cpu {
+   sound-dai = <>;
+   clocks = <_mcasp0>;
+   };
+
+   simple-audio-card,codec {
+   sound-dai = <>;
+   };
+   };
+};
-- 
1.9.1

[PATCH v7 5/6] drm/i2c: tda998x: Register ASoC hdmi-codec and add audio DT binding

[kbuild test robot]

Hi Jyri,

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

url:
https://github.com/0day-ci/linux/commits/Jyri-Sarha/Implement-generic-ASoC-HDMI-codec-and-use-it-in-tda998x/20160317-180926
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: x86_64-randconfig-x019-201611 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/i2c/tda998x_drv.c: In function 'tda998x_configure_audio':
>> drivers/gpu/drm/i2c/tda998x_drv.c:720:6: warning: unused variable 'ret' 
>> [-Wunused-variable]
 int ret;
 ^

vim +/ret +720 drivers/gpu/drm/i2c/tda998x_drv.c

   704  if (on) {
   705  reg_set(priv, REG_SOFTRESET, SOFTRESET_AUDIO);
   706  reg_clear(priv, REG_SOFTRESET, SOFTRESET_AUDIO);
   707  reg_set(priv, REG_AIP_CNTRL_0, AIP_CNTRL_0_RST_FIFO);
   708  } else {
   709  reg_clear(priv, REG_AIP_CNTRL_0, AIP_CNTRL_0_RST_FIFO);
   710  }
   711  }
   712  
   713  static int
   714  tda998x_configure_audio(struct tda998x_priv *priv,
   715  struct tda998x_audio_params *params,
   716  unsigned mode_clock)
   717  {
   718  u8 buf[6], clksel_aip, clksel_fs, cts_n, adiv;
   719  u32 n;
 > 720  int ret;
   721  
   722  /* Enable audio ports */
   723  reg_write(priv, REG_ENA_AP, params->config);
   724  
   725  /* Set audio input source */
   726  switch (params->format) {
   727  case AFMT_SPDIF:
   728  reg_write(priv, REG_ENA_ACLK, 0);

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 22599 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160317/b17f9bd2/attachment-0001.obj>

[patch 1/2] drm/exynos: mic: fix an error code

[Dan Carpenter]

We accidentally return success instead of a negative error code here.

Signed-off-by: Dan Carpenter 
---
This is the common problem introduced by do nothing gotos.  The other
issue with do nothing gotos is that they are annoying and don't actually
prevent people from putting a direct return in the middle of functions.

diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c 
b/drivers/gpu/drm/exynos/exynos_drm_mic.c
index 9869d70..890c9b1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
@@ -457,6 +457,7 @@ static int exynos_mic_probe(struct platform_device *pdev)
"samsung,disp-syscon");
if (IS_ERR(mic->sysreg)) {
DRM_ERROR("mic: Failed to get system register.\n");
+   ret = PTR_ERR(mic->sysreg);
goto err;
}

[patch 2/2] drm/exynos: mic: remove some dead code

[Dan Carpenter]

We know "ret" is zero and the test makes static checkers complain so
let's delete this printk.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c 
b/drivers/gpu/drm/exynos/exynos_drm_mic.c
index 890c9b1..12db353 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
@@ -130,8 +130,6 @@ static void mic_set_path(struct exynos_mic *mic, bool 
enable)
val &= ~(MIC0_RGB_MUX | MIC0_I80_MUX | MIC0_ON_MUX);

regmap_write(mic->sysreg, DSD_CFG_MUX, val);
-   if (ret)
-   DRM_ERROR("mic: Failed to read system register\n");
 }

 static int mic_sw_reset(struct exynos_mic *mic)

[PATCH] drm/fb_cma_helper: Implement fb_mmap callback

[Robin Murphy]

On 16/03/16 19:14, Russell King - ARM Linux wrote:
> On Wed, Mar 16, 2016 at 04:28:25PM +0100, Daniel Vetter wrote:
>> On Wed, Mar 16, 2016 at 02:57:49PM +, Robin Murphy wrote:
>>> In the absence of an fb_mmap callback, the fbdev code falls back to a
>>> naive implementation which relies upon the DMA address being the same
>>> as the physical address, and the buffer being physically contiguous
>>> from there. Whilst this often holds for standard CMA allocations via
>>> the platform's regular DMA ops, if the allocation is provided by an
>>> IOMMU then such assumptions can fall apart spectacularly.
>>>
>>> To resolve this, reroute the fb_mmap call to the appropriate DMA API
>>> implementation, as per the other cma_helper calls.
>>>
>>> Signed-off-by: Robin Murphy 
>>> ---
>>>
>>> Hi dri-devel,
>>>
>>> This is an empirical fix for something I tickled via the newly-added
>>> ARM HDLCD driver on a Juno platform - I have no idea whatsoever about
>>> how "proper" it is in terms of the DRM infrastructure, so feel free to
>>> treat this as a bug report rather than an actual patch if appropriate ;)
>>
>> I think the best case would be if we could have a generic fbdev helper
>> that remaps to dumb mmap support. But that's a bit tricky to pull of:
>> 1. from fb_info we can get at the fbdev drm_framebuffer.
>> 2. from a drm_framebuffer we can get at the underlying backing storage
>> object using fb->funcs->get_handle.
>> 3. With that handle we could go into the dumb mmap support (using als the
>> vma) and create the mmap.
>>
>> Except that ->get_handle needs a file_priv, and that just exist for the
>> fbdev emulation kms client. I guess we could fix that by creating a
>> minimal fake drm file_priv for the fbdev emulation (and treat it more like
>> any other kms client), but I think that's way too much work when this
>> simple patch here gets the job done.
>
> I think first, a different question needs to be answered:
>
> include/uapi/linux/fb.h:
>
> struct fb_fix_screeninfo {
>  char id[16];/* identification string eg "TT 
> Builtin" */
>  unsigned long smem_start;   /* Start of frame buffer mem */
>  /* (physical address) */
>
> Should a DMA address be exposed through smem_start, rather than a
> physical address as the long-standing documentation quoted above
> has stated?
>
> Is it, in fact, a driver bug to store something that isn't a physical
> address there?

We could also go into whether it's right to store even a physical 
address in something which isn't necessarily big enough...

After the time I spent in the bowels of the fbdev code figuring out this 
crash, I fear that if we dig too deep we may awaken something in the 
darkness ;)

Robin.

[PATCH 1/3] dt-bindings: Add binding docs for V3D.

[Rob Herring]

On Fri, Mar 04, 2016 at 12:32:06PM -0800, Eric Anholt wrote:
> This was missed in the upstreaming process.
> 
> Signed-off-by: Eric Anholt 
> ---
>  Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt | 12 
>  1 file changed, 12 insertions(+)

Acked-by: Rob Herring 

[PATCH v8 1/6] ALSA: pcm: add IEC958 channel status helper for hw_params

[Jyri Sarha]

Add IEC958 channel status helper that gets the audio properties from
snd_pcm_hw_params instead of snd_pcm_runtime. This is needed to
produce the channel status bits already in audio stream configuration
phase.

Signed-off-by: Jyri Sarha 
---
 include/sound/pcm_iec958.h |  2 ++
 sound/core/pcm_iec958.c| 65 ++
 2 files changed, 50 insertions(+), 17 deletions(-)

diff --git a/include/sound/pcm_iec958.h b/include/sound/pcm_iec958.h
index 0eed397..36f023a 100644
--- a/include/sound/pcm_iec958.h
+++ b/include/sound/pcm_iec958.h
@@ -6,4 +6,6 @@
 int snd_pcm_create_iec958_consumer(struct snd_pcm_runtime *runtime, u8 *cs,
size_t len);

+int snd_pcm_create_iec958_consumer_hw_params(struct snd_pcm_hw_params *params,
+u8 *cs, size_t len);
 #endif
diff --git a/sound/core/pcm_iec958.c b/sound/core/pcm_iec958.c
index 36b2d7a..5e6aed6 100644
--- a/sound/core/pcm_iec958.c
+++ b/sound/core/pcm_iec958.c
@@ -9,30 +9,18 @@
 #include 
 #include 
 #include 
+#include 
 #include 

-/**
- * snd_pcm_create_iec958_consumer - create consumer format IEC958 channel 
status
- * @runtime: pcm runtime structure with ->rate filled in
- * @cs: channel status buffer, at least four bytes
- * @len: length of channel status buffer
- *
- * Create the consumer format channel status data in @cs of maximum size
- * @len corresponding to the parameters of the PCM runtime @runtime.
- *
- * Drivers may wish to tweak the contents of the buffer after creation.
- *
- * Returns: length of buffer, or negative error code if something failed.
- */
-int snd_pcm_create_iec958_consumer(struct snd_pcm_runtime *runtime, u8 *cs,
-   size_t len)
+static int create_iec958_consumer(uint rate, uint sample_width,
+ u8 *cs, size_t len)
 {
unsigned int fs, ws;

if (len < 4)
return -EINVAL;

-   switch (runtime->rate) {
+   switch (rate) {
case 32000:
fs = IEC958_AES3_CON_FS_32000;
break;
@@ -59,7 +47,7 @@ int snd_pcm_create_iec958_consumer(struct snd_pcm_runtime 
*runtime, u8 *cs,
}

if (len > 4) {
-   switch (snd_pcm_format_width(runtime->format)) {
+   switch (sample_width) {
case 16:
ws = IEC958_AES4_CON_WORDLEN_20_16;
break;
@@ -71,6 +59,7 @@ int snd_pcm_create_iec958_consumer(struct snd_pcm_runtime 
*runtime, u8 *cs,
 IEC958_AES4_CON_MAX_WORDLEN_24;
break;
case 24:
+   case 32: /* Assume 24-bit width for 32-bit samples. */
ws = IEC958_AES4_CON_WORDLEN_24_20 |
 IEC958_AES4_CON_MAX_WORDLEN_24;
break;
@@ -92,4 +81,46 @@ int snd_pcm_create_iec958_consumer(struct snd_pcm_runtime 
*runtime, u8 *cs,

return len;
 }
+
+/**
+ * snd_pcm_create_iec958_consumer - create consumer format IEC958 channel 
status
+ * @runtime: pcm runtime structure with ->rate filled in
+ * @cs: channel status buffer, at least four bytes
+ * @len: length of channel status buffer
+ *
+ * Create the consumer format channel status data in @cs of maximum size
+ * @len corresponding to the parameters of the PCM runtime @runtime.
+ *
+ * Drivers may wish to tweak the contents of the buffer after creation.
+ *
+ * Returns: length of buffer, or negative error code if something failed.
+ */
+int snd_pcm_create_iec958_consumer(struct snd_pcm_runtime *runtime, u8 *cs,
+   size_t len)
+{
+   return create_iec958_consumer(runtime->rate,
+ snd_pcm_format_width(runtime->format),
+ cs, len);
+}
 EXPORT_SYMBOL(snd_pcm_create_iec958_consumer);
+
+/**
+ * snd_pcm_create_iec958_consumer_hw_params - create IEC958 channel status
+ * @hw_params: the hw_params instance for extracting rate and sample format
+ * @cs: channel status buffer, at least four bytes
+ * @len: length of channel status buffer
+ *
+ * Create the consumer format channel status data in @cs of maximum size
+ * @len corresponding to the parameters of the PCM runtime @runtime.
+ *
+ * Drivers may wish to tweak the contents of the buffer after creation.
+ *
+ * Returns: length of buffer, or negative error code if something failed.
+ */
+int snd_pcm_create_iec958_consumer_hw_params(struct snd_pcm_hw_params *params,
+u8 *cs, size_t len)
+{
+   return create_iec958_consumer(params_rate(params), params_width(params),
+ cs, len);
+}
+EXPORT_SYMBOL(snd_pcm_create_iec958_consumer_hw_params);
-- 
1.9.1

[PATCH v8 0/6] Implement generic ASoC HDMI codec and use it in tda998x

[Jyri Sarha]

The only change to v7: Remove the unused variable from
tda998x_configure_audio().

Not much have changed since v6[1] patch series. I did everything
addressed every comment, mostly by robots :), to previous series and
there was one bug fixed in tda998x side. Unless there is any
significant reaction to this series, I am going to put it to rest for
a while now. I have other things to do.

There is currently two other patch series[2][3] that depend on the
first two (ALSA-) patches of this series. The third ("ASoC:
hdmi-codec: Add audio abort() callback for video side to use") is
currently not used and can be dropped if so decided. The rest depends
on those the first two and adds hdmi-audio support for
Beaglebone-black.

Best regards,
Jyri

[1] "[PATCH v6 0/6] Implement generic ASoC HDMI codec and use it in tda998x"
http://mailman.alsa-project.org/pipermail/alsa-devel/2016-March/105524.html
[2] "[PATCH v6 00/10] ASoC: Add mediatek HDMI codec support" by Philipp Zabel 
http://mailman.alsa-project.org/pipermail/alsa-devel/2016-March/105509.html
[3] "[RFC v2 0/6] sti: add audio interface to the hdmi driver"

http://mailman.alsa-project.org/pipermail/alsa-devel/2016-January/103374.html
and "[PATCH v4 0/6] add IEC958 channel status control helpers"
http://mailman.alsa-project.org/pipermail/alsa-devel/2016-March/105502.html
by Arnaud Pouliquen

Changes since v7
* "drm/i2c: tda998x: Register ASoC hdmi-codec and add audio DT binding"
  - Remove the unused "int ret" variable from tda998x_configure_audio()

Changes since v6
* "ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders"
 - Add "Acked-by: Arnaud Pouliquen " and
   "Tested-by: Philipp Zabel ", no other changes
* "ALSA: pcm: add IEC958 channel status helper for hw_param"
 - Added kernel-doc for snd_pcm_create_iec958_consumer_hw_params()
* "drm/i2c: tda998x: Register ASoC hdmi-codec and add audio DT binding"
 - Use PTR_ERR_OR_ZERO() in tda998x_audio_codec_init()
 - Fix possible uninitialized use of 'size' in tda998x_get_audio_ports()
 - Store audio configuration in tda998x_audio_hw_params() instead of
   tda998x_configure_audio().

Changes since v5
 - Rebased on top of the latest drm-next branch
 - Allow 32 bit samplewidth in snd_pcm_create_iec958_consumer() and
   snd_pcm_create_iec958_consumer_hw_params()
 - Propose new simpler DT binding for tda998x audio
 - Squash tda998x audio DT binding together with hdmi-codec integration

Changes since RFC v4,
 - Rebased on top of the latest drm-next branch
 - Split the hdmi-codec abort functionality into a separate patch for
   better visibility of what it is all about
   - This does not affect the tda998x patches as the abort
 functionality is not used
 - Drop S18_3* formats from I2S_FORMATS and add a comment about formats
   not supported by HDMI

Changes since RFC v3,
 ASoC side:
 - Add "ALSA: pcm: add IEC958 channel status helper for hw_params"
 - Add "tda998x: Improve tda998x_configure_audio() audio related pdata"
 - use snd_pcm_create_iec958_consumer_hw_params() to construct the stream header
 - Remove set_clk() callback from hdmi-codec. It is not needed for now.
 - Refer to stream header in AIF as specified in HDMI standard
 - Set current_stream to NULL only after video side audio_shutdown() has
   been called. Avoid potential race if video side attempts to abort audio
   at the same time.
 - No need to have video side device pointer in the hdmi codec's pdata as
   it is found from dev->parent.
 - Fix hdmi-codec enum: DAI_ID_I2C > DAI_ID_I2S
 - Improve audio_startup API comment
 - Make improved checkpatch happy 
   - BUG_ON > WARN_ON
   - put */ ending the block comment to a separate line

 DRM side:
 - Fix tda998x get_eld() locking
 - Change tda998x audio parameters in pdata to more generic, that can
   be readily used in tda998x_audio_config()
 - Rename and restructure audio port related private data members to
   be more descriptive
 - Require audio configuration trough ASoC hdmi-codec if HDMI audio is
   configured trough DT binding. 

 DTS:
 - Increase McASP fifo usage form 1 to 32

Jyri Sarha (6):
  ALSA: pcm: add IEC958 channel status helper for hw_params
  ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders
  ASoC: hdmi-codec: Add audio abort() callback for video side to use
  drm/i2c: tda998x: Improve tda998x_configure_audio() audio related
pdata
  drm/i2c: tda998x: Register ASoC hdmi-codec and add audio DT binding
  ARM: dts: am335x-boneblack: Add HDMI audio support

 .../devicetree/bindings/display/bridge/tda998x.txt |  18 +
 arch/arm/boot/dts/am335x-boneblack.dts |  71 +++-
 drivers/gpu/drm/i2c/Kconfig|   1 +
 drivers/gpu/drm/i2c/tda998x_drv.c  | 275 --
 include/drm/i2c/tda998x.h  |  24 +-
 include/dt-bindings/display/tda998x.h  |   7 +
 include/sound/hdmi-codec.h | 104 ++
 include/sound/pcm_iec958.h |   2 +

[PATCH v8 2/6] ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders

[Jyri Sarha]

The hdmi-codec is a platform device driver to be registered from
drivers of external HDMI encoders with I2S and/or spdif interface. The
driver in turn registers an ASoC codec for the HDMI encoder's audio
functionality.

The structures and definitions in the API header are mostly redundant
copies of similar structures in ASoC headers. This is on purpose to
avoid direct dependencies to ASoC structures in video side driver.

Signed-off-by: Jyri Sarha 
Acked-by: Arnaud Pouliquen 
Tested-by: Philipp Zabel 
---
 include/sound/hdmi-codec.h| 100 +++
 sound/soc/codecs/Kconfig  |   6 +
 sound/soc/codecs/Makefile |   2 +
 sound/soc/codecs/hdmi-codec.c | 393 ++
 4 files changed, 501 insertions(+)
 create mode 100644 include/sound/hdmi-codec.h
 create mode 100644 sound/soc/codecs/hdmi-codec.c

diff --git a/include/sound/hdmi-codec.h b/include/sound/hdmi-codec.h
new file mode 100644
index 000..fc3a481
--- /dev/null
+++ b/include/sound/hdmi-codec.h
@@ -0,0 +1,100 @@
+/*
+ * hdmi-codec.h - HDMI Codec driver API
+ *
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Author: Jyri Sarha 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ */
+
+#ifndef __HDMI_CODEC_H__
+#define __HDMI_CODEC_H__
+
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * Protocol between ASoC cpu-dai and HDMI-encoder
+ */
+struct hdmi_codec_daifmt {
+   enum {
+   HDMI_I2S,
+   HDMI_RIGHT_J,
+   HDMI_LEFT_J,
+   HDMI_DSP_A,
+   HDMI_DSP_B,
+   HDMI_AC97,
+   HDMI_SPDIF,
+   } fmt;
+   int bit_clk_inv:1;
+   int frame_clk_inv:1;
+   int bit_clk_master:1;
+   int frame_clk_master:1;
+};
+
+/*
+ * HDMI audio parameters
+ */
+struct hdmi_codec_params {
+   struct hdmi_audio_infoframe cea;
+   struct snd_aes_iec958 iec;
+   int sample_rate;
+   int sample_width;
+   int channels;
+};
+
+struct hdmi_codec_ops {
+   /*
+* Called when ASoC starts an audio stream setup.
+* Optional
+*/
+   int (*audio_startup)(struct device *dev);
+
+   /*
+* Configures HDMI-encoder for audio stream.
+* Mandatory
+*/
+   int (*hw_params)(struct device *dev,
+struct hdmi_codec_daifmt *fmt,
+struct hdmi_codec_params *hparms);
+
+   /*
+* Shuts down the audio stream.
+* Mandatory
+*/
+   void (*audio_shutdown)(struct device *dev);
+
+   /*
+* Mute/unmute HDMI audio stream.
+* Optional
+*/
+   int (*digital_mute)(struct device *dev, bool enable);
+
+   /*
+* Provides EDID-Like-Data from connected HDMI device.
+* Optional
+*/
+   int (*get_eld)(struct device *dev, uint8_t *buf, size_t len);
+};
+
+/* HDMI codec initalization data */
+struct hdmi_codec_pdata {
+   const struct hdmi_codec_ops *ops;
+   uint i2s:1;
+   uint spdif:1;
+   int max_i2s_channels;
+};
+
+#define HDMI_CODEC_DRV_NAME "hdmi-audio-codec"
+
+#endif /* __HDMI_CODEC_H__ */
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 50693c8..62b62fe 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -86,6 +86,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_MC13783 if MFD_MC13XXX
select SND_SOC_ML26124 if I2C
select SND_SOC_NAU8825 if I2C
+   select SND_SOC_HDMI_CODEC
select SND_SOC_PCM1681 if I2C
select SND_SOC_PCM179X if SPI_MASTER
select SND_SOC_PCM3008
@@ -473,6 +474,11 @@ config SND_SOC_BT_SCO
 config SND_SOC_DMIC
tristate

+config SND_SOC_HDMI_CODEC
+   tristate
+   select SND_PCM_ELD
+   select SND_PCM_IEC958
+
 config SND_SOC_ES8328
tristate "Everest Semi ES8328 CODEC"

diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index d44f7d3..5f7b002 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -79,6 +79,7 @@ snd-soc-max9850-objs := max9850.o
 snd-soc-mc13783-objs := mc13783.o
 snd-soc-ml26124-objs := ml26124.o
 snd-soc-nau8825-objs := nau8825.o
+snd-soc-hdmi-codec-objs := hdmi-codec.o
 snd-soc-pcm1681-objs := pcm1681.o
 snd-soc-pcm179x-codec-objs := pcm179x.o
 snd-soc-pcm3008-objs := pcm3008.o
@@ -283,6 +284,7 @@ obj-$(CONFIG_SND_SOC_MAX9850)   += snd-soc-max9850.o
 obj-$(CONFIG_SND_SOC_MC13783)  += snd-soc-mc13783.o
 obj-$(CONFIG_SND_SOC_ML26124)  += snd-soc-ml26124.o
 obj-$(CONFIG_SND_SOC_NAU8825)   += snd-soc-nau8825.o

[PATCH v8 4/6] drm/i2c: tda998x: Improve tda998x_configure_audio() audio related pdata

[Jyri Sarha]

Define struct tda998x_audio_params in include/drm/i2c/tda998x.h and
use it in pdata and for tda998x_configure_audio() parameters. Also
updates tda998x_write_aif() to take struct hdmi_audio_infoframe *
directly as a parameter.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/i2c/tda998x_drv.c | 77 ---
 include/drm/i2c/tda998x.h | 24 +++-
 2 files changed, 53 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index f4315bc..f97b748 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -41,7 +41,7 @@ struct tda998x_priv {
u8 vip_cntrl_0;
u8 vip_cntrl_1;
u8 vip_cntrl_2;
-   struct tda998x_encoder_params params;
+   struct tda998x_audio_params audio_params;

wait_queue_head_t wq_edid;
volatile int wq_edid_wait;
@@ -666,26 +666,16 @@ tda998x_write_if(struct tda998x_priv *priv, u8 bit, u16 
addr,
reg_set(priv, REG_DIP_IF_FLAGS, bit);
 }

-static void
-tda998x_write_aif(struct tda998x_priv *priv, struct tda998x_encoder_params *p)
+static int tda998x_write_aif(struct tda998x_priv *priv,
+struct hdmi_audio_infoframe *cea)
 {
union hdmi_infoframe frame;

-   hdmi_audio_infoframe_init();
-
-   frame.audio.channels = p->audio_frame[1] & 0x07;
-   frame.audio.channel_allocation = p->audio_frame[4];
-   frame.audio.level_shift_value = (p->audio_frame[5] & 0x78) >> 3;
-   frame.audio.downmix_inhibit = (p->audio_frame[5] & 0x80) >> 7;
-
-   /*
-* L-PCM and IEC61937 compressed audio shall always set sample
-* frequency to "refer to stream".  For others, see the HDMI
-* specification.
-*/
-   frame.audio.sample_frequency = (p->audio_frame[2] & 0x1c) >> 2;
+   frame.audio = *cea;

tda998x_write_if(priv, DIP_IF_FLAGS_IF4, REG_IF4_HB0, );
+
+   return 0;
 }

 static void
@@ -710,20 +700,21 @@ static void tda998x_audio_mute(struct tda998x_priv *priv, 
bool on)
}
 }

-static void
+static int
 tda998x_configure_audio(struct tda998x_priv *priv,
-   struct drm_display_mode *mode, struct tda998x_encoder_params *p)
+   struct tda998x_audio_params *params,
+   unsigned mode_clock)
 {
u8 buf[6], clksel_aip, clksel_fs, cts_n, adiv;
u32 n;

/* Enable audio ports */
-   reg_write(priv, REG_ENA_AP, p->audio_cfg);
-   reg_write(priv, REG_ENA_ACLK, p->audio_clk_cfg);
+   reg_write(priv, REG_ENA_AP, params->config);

/* Set audio input source */
-   switch (p->audio_format) {
+   switch (params->format) {
case AFMT_SPDIF:
+   reg_write(priv, REG_ENA_ACLK, 0);
reg_write(priv, REG_MUX_AP, MUX_AP_SELECT_SPDIF);
clksel_aip = AIP_CLKSEL_AIP_SPDIF;
clksel_fs = AIP_CLKSEL_FS_FS64SPDIF;
@@ -731,15 +722,29 @@ tda998x_configure_audio(struct tda998x_priv *priv,
break;

case AFMT_I2S:
+   reg_write(priv, REG_ENA_ACLK, 1);
reg_write(priv, REG_MUX_AP, MUX_AP_SELECT_I2S);
clksel_aip = AIP_CLKSEL_AIP_I2S;
clksel_fs = AIP_CLKSEL_FS_ACLK;
-   cts_n = CTS_N_M(3) | CTS_N_K(3);
+   switch (params->sample_width) {
+   case 16:
+   cts_n = CTS_N_M(3) | CTS_N_K(1);
+   break;
+   case 18:
+   case 20:
+   case 24:
+   cts_n = CTS_N_M(3) | CTS_N_K(2);
+   break;
+   default:
+   case 32:
+   cts_n = CTS_N_M(3) | CTS_N_K(3);
+   break;
+   }
break;

default:
BUG();
-   return;
+   return -EINVAL;
}

reg_write(priv, REG_AIP_CLKSEL, clksel_aip);
@@ -755,11 +760,11 @@ tda998x_configure_audio(struct tda998x_priv *priv,
 * assume 100MHz requires larger divider.
 */
adiv = AUDIO_DIV_SERCLK_8;
-   if (mode->clock > 10)
+   if (mode_clock > 10)
adiv++; /* AUDIO_DIV_SERCLK_16 */

/* S/PDIF asks for a larger divider */
-   if (p->audio_format == AFMT_SPDIF)
+   if (params->format == AFMT_SPDIF)
adiv++; /* AUDIO_DIV_SERCLK_16 or _32 */

reg_write(priv, REG_AUDIO_DIV, adiv);
@@ -768,7 +773,7 @@ tda998x_configure_audio(struct tda998x_priv *priv,
 * This is the approximate value of N, which happens to be
 * the recommended values for non-coherent clocks.
 */
-   n = 128 * p->audio_sample_rate / 1000;
+   n = 128 * params->sample_rate / 1000;

/* Write the CTS and N values */
buf[0] = 0x44;
@@ -787,19 +792,13 @@ 

[PATCH v8 5/6] drm/i2c: tda998x: Register ASoC hdmi-codec and add audio DT binding

[Jyri Sarha]

Register ASoC HDMI codec for audio functionality and adds device tree
binding for audio configuration.

With the registered HDMI codec the tda998x node can be used like a
regular codec node in ASoC card configurations. HDMI audio info-frame
and audio stream header is generated by the ASoC HDMI codec. The codec
also applies constraints for available sample-rates based on Edid Like
Data from the display. The device tree binding document has been
updated [1].

Part of this patch has been inspired by Jean Francoise's "drm/i2c: tda998x:
Add support of a DT graph of ports"-patch [2]. There may still be some
identical lines left from the original patch and some of the ideas
have come from there.

[1] Documentation/devicetree/bindings/display/bridge/tda998x.txt
[2] http://mailman.alsa-project.org/pipermail/alsa-devel/2015-July/095255.html

Signed-off-by: Jyri Sarha 
---
 .../devicetree/bindings/display/bridge/tda998x.txt |  18 ++
 drivers/gpu/drm/i2c/Kconfig|   1 +
 drivers/gpu/drm/i2c/tda998x_drv.c  | 198 -
 include/drm/i2c/tda998x.h  |   4 +-
 include/dt-bindings/display/tda998x.h  |   7 +
 5 files changed, 223 insertions(+), 5 deletions(-)
 create mode 100644 include/dt-bindings/display/tda998x.h

diff --git a/Documentation/devicetree/bindings/display/bridge/tda998x.txt 
b/Documentation/devicetree/bindings/display/bridge/tda998x.txt
index e178e6b..24cc246 100644
--- a/Documentation/devicetree/bindings/display/bridge/tda998x.txt
+++ b/Documentation/devicetree/bindings/display/bridge/tda998x.txt
@@ -21,8 +21,19 @@ Optional properties:
   - video-ports: 24 bits value which defines how the video controller
output is wired to the TDA998x input - default: <0x230145>

+  - audio-ports: array of 8-bit values, 2 values per one DAI[1].
+   The first value defines the DAI type: TDA998x_SPDIF or TDA998x_I2S[2].
+   The second value defines the tda998x AP_ENA reg content when the DAI
+   in question is used. The implementation allows one or two DAIs. If two
+   DAIs are defined, they must be of different type.
+
+[1] Documentation/sound/alsa/soc/DAI.txt
+[2] include/dt-bindings/display/tda998x.h
+
 Example:

+#include 
+
tda998x: hdmi-encoder {
compatible = "nxp,tda998x";
reg = <0x70>;
@@ -30,4 +41,11 @@ Example:
interrupts = <27 2>;/* falling edge */
pinctrl-0 = <_camera>;
pinctrl-names = "default";
+   video-ports = <0x230145>;
+
+   #sound-dai-cells = <2>;
+/* DAI-format  AP_ENA reg value */
+   audio-ports = < TDA998x_SPDIF   0x04
+   TDA998x_I2S 0x03>;
+
};
diff --git a/drivers/gpu/drm/i2c/Kconfig b/drivers/gpu/drm/i2c/Kconfig
index 22c7ed6..088f278 100644
--- a/drivers/gpu/drm/i2c/Kconfig
+++ b/drivers/gpu/drm/i2c/Kconfig
@@ -28,6 +28,7 @@ config DRM_I2C_SIL164
 config DRM_I2C_NXP_TDA998X
tristate "NXP Semiconductors TDA998X HDMI encoder"
default m if DRM_TILCDC
+   select SND_SOC_HDMI_CODEC if SND_SOC
help
  Support for NXP Semiconductors TDA998X HDMI encoders.

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index f97b748..9d37493 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
@@ -30,6 +31,11 @@

 #define DBG(fmt, ...) DRM_DEBUG(fmt"\n", ##__VA_ARGS__)

+struct tda998x_audio_port {
+   u8 format;  /* AFMT_xxx */
+   u8 config;  /* AP value */
+};
+
 struct tda998x_priv {
struct i2c_client *cec;
struct i2c_client *hdmi;
@@ -43,6 +49,8 @@ struct tda998x_priv {
u8 vip_cntrl_2;
struct tda998x_audio_params audio_params;

+   struct platform_device *audio_pdev;
+
wait_queue_head_t wq_edid;
volatile int wq_edid_wait;

@@ -53,6 +61,8 @@ struct tda998x_priv {

struct drm_encoder encoder;
struct drm_connector connector;
+
+   struct tda998x_audio_port audio_port[2];
 };

 #define conn_to_tda998x_priv(x) \
@@ -743,7 +753,7 @@ tda998x_configure_audio(struct tda998x_priv *priv,
break;

default:
-   BUG();
+   dev_err(>hdmi->dev, "Unsupported I2S format\n");
return -EINVAL;
}

@@ -1160,6 +1170,8 @@ static int tda998x_connector_get_modes(struct 
drm_connector *connector)
drm_mode_connector_update_edid_property(connector, edid);
n = drm_add_edid_modes(connector, edid);
priv->is_hdmi_sink = drm_detect_hdmi_monitor(edid);
+   drm_edid_to_eld(connector, edid);
+
kfree(edid);

return n;
@@ -1181,6 +1193,9 @@ static void tda998x_destroy(struct tda998x_priv *priv)
cec_write(priv, 

[PATCH v8 6/6] ARM: dts: am335x-boneblack: Add HDMI audio support

[Jyri Sarha]

Add HDMI audio support. Adds mcasp0_pins, clk_mcasp0_fixed,
clk_mcasp0, mcasp0, sound node, and updates the tda19988 node to
follow the new binding.

Signed-off-by: Jyri Sarha 
---
 arch/arm/boot/dts/am335x-boneblack.dts | 71 --
 1 file changed, 67 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-boneblack.dts 
b/arch/arm/boot/dts/am335x-boneblack.dts
index 55c0e95..2bae4d1 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -9,6 +9,7 @@

 #include "am33xx.dtsi"
 #include "am335x-bone-common.dtsi"
+#include 

 / {
model = "TI AM335x BeagleBone Black";
@@ -64,6 +65,16 @@
AM33XX_IOPAD(0x9b0, PIN_OUTPUT_PULLDOWN | MUX_MODE3)
/* xdma_event_intr0 */
>;
};
+
+   mcasp0_pins: mcasp0_pins {
+   pinctrl-single,pins = <
+   AM33XX_IOPAD(0x9ac, PIN_INPUT_PULLUP | MUX_MODE0) /* 
mcasp0_ahcklx.mcasp0_ahclkx */
+   AM33XX_IOPAD(0x99c, PIN_OUTPUT_PULLDOWN | MUX_MODE2) /* 
mcasp0_ahclkr.mcasp0_axr2*/
+   AM33XX_IOPAD(0x994, PIN_OUTPUT_PULLUP | MUX_MODE0) /* 
mcasp0_fsx.mcasp0_fsx */
+   AM33XX_IOPAD(0x990, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* 
mcasp0_aclkx.mcasp0_aclkx */
+   AM33XX_IOPAD(0x86c, PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* 
gpmc_a11.GPIO1_27 */
+   >;
+   };
 };

  {
@@ -76,16 +87,22 @@
 };

  {
-   tda19988 {
+   tda19988: tda19988 {
compatible = "nxp,tda998x";
reg = <0x70>;
+
pinctrl-names = "default", "off";
pinctrl-0 = <_hdmi_bonelt_pins>;
pinctrl-1 = <_hdmi_bonelt_off_pins>;

-   port {
-   hdmi_0: endpoint at 0 {
-   remote-endpoint = <_0>;
+   #sound-dai-cells = <0>;
+   audio-ports = < AFMT_I2S0x03>;
+
+   ports {
+   port at 0 {
+   hdmi_0: endpoint at 0 {
+   remote-endpoint = <_0>;
+   };
};
};
};
@@ -94,3 +111,49 @@
  {
system-power-controller;
 };
+
+{
+   #sound-dai-cells = <0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   status = "okay";
+   op-mode = <0>;  /* MCASP_IIS_MODE */
+   tdm-slots = <2>;
+   serial-dir = <  /* 0: INACTIVE, 1: TX, 2: RX */
+   0 0 1 0
+   >;
+   tx-num-evt = <32>;
+   rx-num-evt = <32>;
+};
+
+/ {
+   clk_mcasp0_fixed: clk_mcasp0_fixed {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <24576000>;
+   };
+
+   clk_mcasp0: clk_mcasp0 {
+   #clock-cells = <0>;
+   compatible = "gpio-gate-clock";
+   clocks = <_mcasp0_fixed>;
+   enable-gpios = < 27 0>; /* BeagleBone Black Clk enable on 
GPIO1_27 */
+   };
+
+   sound {
+   compatible = "simple-audio-card";
+   simple-audio-card,name = "TI BeagleBone Black";
+   simple-audio-card,format = "i2s";
+   simple-audio-card,bitclock-master = <_master>;
+   simple-audio-card,frame-master = <_master>;
+
+   dailink0_master: simple-audio-card,cpu {
+   sound-dai = <>;
+   clocks = <_mcasp0>;
+   };
+
+   simple-audio-card,codec {
+   sound-dai = <>;
+   };
+   };
+};
-- 
1.9.1

[PATCH v8 3/6] ASoC: hdmi-codec: Add audio abort() callback for video side to use

[Jyri Sarha]

Add audio abort() callback, that is provided at audio stream start,
for video side. This is for video side to use in case there is a
pressing need to tear down the audio playback for some reason.

Signed-off-by: Jyri Sarha 
---
 include/sound/hdmi-codec.h|  8 ++--
 sound/soc/codecs/hdmi-codec.c | 20 +++-
 2 files changed, 25 insertions(+), 3 deletions(-)

diff --git a/include/sound/hdmi-codec.h b/include/sound/hdmi-codec.h
index fc3a481..15fe70f 100644
--- a/include/sound/hdmi-codec.h
+++ b/include/sound/hdmi-codec.h
@@ -55,10 +55,14 @@ struct hdmi_codec_params {

 struct hdmi_codec_ops {
/*
-* Called when ASoC starts an audio stream setup.
+* Called when ASoC starts an audio stream setup. The call
+* provides an audio abort callback for stoping an ongoing
+* stream from video side driver if the HDMI audio becomes
+* unavailable.
 * Optional
 */
-   int (*audio_startup)(struct device *dev);
+   int (*audio_startup)(struct device *dev,
+void (*abort_cb)(struct device *dev));

/*
 * Configures HDMI-encoder for audio stream.
diff --git a/sound/soc/codecs/hdmi-codec.c b/sound/soc/codecs/hdmi-codec.c
index bc47b9a..cc08097 100644
--- a/sound/soc/codecs/hdmi-codec.c
+++ b/sound/soc/codecs/hdmi-codec.c
@@ -47,6 +47,23 @@ enum {
DAI_ID_SPDIF,
 };

+static void hdmi_codec_abort(struct device *dev)
+{
+   struct hdmi_codec_priv *hcp = dev_get_drvdata(dev);
+
+   dev_dbg(dev, "%s()\n", __func__);
+
+   mutex_lock(>current_stream_lock);
+   if (hcp->current_stream && hcp->current_stream->runtime &&
+   snd_pcm_running(hcp->current_stream)) {
+   dev_info(dev, "HDMI audio playback aborted\n");
+   snd_pcm_stream_lock_irq(hcp->current_stream);
+   snd_pcm_stop(hcp->current_stream, SNDRV_PCM_STATE_DISCONNECTED);
+   snd_pcm_stream_unlock_irq(hcp->current_stream);
+   }
+   mutex_unlock(>current_stream_lock);
+}
+
 static int hdmi_codec_new_stream(struct snd_pcm_substream *substream,
 struct snd_soc_dai *dai)
 {
@@ -78,7 +95,8 @@ static int hdmi_codec_startup(struct snd_pcm_substream 
*substream,
return ret;

if (hcp->hcd.ops->audio_startup) {
-   ret = hcp->hcd.ops->audio_startup(dai->dev->parent);
+   ret = hcp->hcd.ops->audio_startup(dai->dev->parent,
+ hdmi_codec_abort);
if (ret) {
mutex_lock(>current_stream_lock);
hcp->current_stream = NULL;
-- 
1.9.1

[PATCH] drm/sti: restore mode_fixup callback

[Vincent ABRIOU]

Thank you Arnd for highlighting this.

Acked-by: Vincent ABRIOU 

On 03/17/2016 10:02 AM, Arnd Bergmann wrote:
> Commit 8a2fa38fddd3 removed the mode_fixup because it was empty,
> but 652353e6e561 modified it to call drm_mode_set_crtcinfo()
> instead.
>
> Both commits are correct, but the merge of the two kept the nonempty
> version without the reference to it, as shown by the gcc warning:
>
>   drm/sti/sti_crtc.c:54:13: error: 'sti_crtc_mode_fixup' defined but not used
>
> This restores the callback pointer to fix the merge.
>
> Signed-off-by: Arnd Bergmann 
> Reverts: 8a2fa38fddd3 ("drm/sti: removed optional dummy crtc mode_fixup 
> function.")
> Fixes: 652353e6e561 ("drm/sti: set CRTC modesetting parameters")
> Fixes: cf481068cdd4 ("Merge branch '2016-02-26-st-drm-next' of 
> http://git.linaro.org/people/benjamin.gaignard/kernel into drm-next")
> ---
>   drivers/gpu/drm/sti/sti_crtc.c | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/sti/sti_crtc.c b/drivers/gpu/drm/sti/sti_crtc.c
> index fa47f63b5316..505620c7c2c8 100644
> --- a/drivers/gpu/drm/sti/sti_crtc.c
> +++ b/drivers/gpu/drm/sti/sti_crtc.c
> @@ -230,6 +230,7 @@ static void sti_crtc_atomic_flush(struct drm_crtc *crtc,
>   static const struct drm_crtc_helper_funcs sti_crtc_helper_funcs = {
>   .enable = sti_crtc_enable,
>   .disable = sti_crtc_disabling,
> + .mode_fixup = sti_crtc_mode_fixup,
>   .mode_set = drm_helper_crtc_mode_set,
>   .mode_set_nofb = sti_crtc_mode_set_nofb,
>   .mode_set_base = drm_helper_crtc_mode_set_base,
>

[Bug 91656] [APITRACE] [bisected] Pillars of Eternity glitch in maps

[bugzilla-dae...@freedesktop.org]

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

--- Comment #15 from Daniel Scharrer  ---
Looks like this has been fixed in the latest beta for Pillars of Eternity (what
will become 3.02) along with the black spots (caused by denormals) in the water
shader.

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

[PATCH 1/3] pinctrl: Intel: add RX invertion config

[Linus Walleij]

On Wed, Mar 16, 2016 at 2:34 PM, Daniel Vetter  wrote:
> On Wed, Mar 16, 2016 at 01:27:49PM +0100, Linus Walleij wrote:

>> - What is a HPD interrupt?
>
> hotplug interrupt, fires when you plug in a cable.
>
>> - What is a Type-C DP HPD?
>
> usb type C connector can multiplex both DisplayPort and USB, you need to
> renegotiate the lane splitting every time the sink changes, i.e. on each
> hotplug.

OK I understand, thanks a lot!

>> - Again why can't you just use a notifier or function call?
>
> Because windows sucks, hence all that coordination happens through hw
> forwarded interrupts and magic registers. Same horror story on the sound
> side, where the sound driver needs to know what kind of PCM stream the
> monitor can take. It's hilarious. Except when they screw up the design and
> then need to fake parts of it in software.

So the story is something like that these IRQs have been put into
hardware in order to compensate for flaws in Windows device driver
model, I see.

If there are such special registers in some hardware I guess I'm all for
implementing some generic quirk in gpiolib for people who need to
software-trigger GPIO IRQs. Could be good for testing too, as there
are such registers in ARMs PL061 GPIO controller for test, just so as
to simulate a GPIO IRQ.

gpiod_trig_irq() would work with me, I'm happy to support whatever
the GPIO hardware can do usually.

> In sound we've switched over to a proper sw interface, and we tie the
> different parts (drm graphics driver and alsa snd driver) using the
> component.c framework.

Hm is that solution or something similar proper for USB connector
as well I wonder... I was thinking about just adding $random_notifier
but maybe that is a bit ugly :/

>> What is VPG? Now it seems Intel's internal organization is being used as
>> part of the argument to get this change in and that makes me a bit
>> annoyed.
(...)
> There was chat of usb type C support for forever, but I was always
> promised that we don't need any interactions on the sw side and it's all
> magic in hw. There hasn't been any real design discussions in the open
> source group. VPG is the hw/windows group and generally comes up with
> "interesting" designs not suitable for upstream.
>
> Feel free to just nack this stuff, and please cc intel-gfx/dri-devel in
> the future (since I tend to ignore everything that's not cc'ed to mailing
> lists I don't care about, even when I'm on cc personally). I've added them
> all to cc.

Thanks a lot Daniel, I understand better now. I'm not really against
adding this "interesting" workaround if that is how Windows works,
we usually have to go by their standards. From the GPIO point
of view it is OK, just something the GPIO can do. I would be more
worried about what the USB PHY maintainer (Felipe) is going to say
about this.

Yours,
Linus Walleij

[Bug 94445] Tonga llvm assert since RegisterCoalescer: Need to check DstReg+SrcReg for missing undef flags

[bugzilla-dae...@freedesktop.org]

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

Vedran Miletić  changed:

   What|Removed |Added

 CC||rivanvx at gmail.com

--- Comment #4 from Vedran Miletić  ---
Happens on Bonaire and Kabini as well when running GROMACS OpenCL. I can
provide .ll if useful.

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

[Intel-gfx] [PATCH 1/3] pinctrl: Intel: add RX invertion config

[Jani Nikula]

On Thu, 17 Mar 2016, Linus Walleij  wrote:
> On Wed, Mar 16, 2016 at 2:34 PM, Daniel Vetter  wrote:
>> On Wed, Mar 16, 2016 at 01:27:49PM +0100, Linus Walleij wrote:
>
>>> - What is a HPD interrupt?
>>
>> hotplug interrupt, fires when you plug in a cable.
>>
>>> - What is a Type-C DP HPD?
>>
>> usb type C connector can multiplex both DisplayPort and USB, you need to
>> renegotiate the lane splitting every time the sink changes, i.e. on each
>> hotplug.
>
> OK I understand, thanks a lot!
>
>>> - Again why can't you just use a notifier or function call?
>>
>> Because windows sucks, hence all that coordination happens through hw
>> forwarded interrupts and magic registers. Same horror story on the sound
>> side, where the sound driver needs to know what kind of PCM stream the
>> monitor can take. It's hilarious. Except when they screw up the design and
>> then need to fake parts of it in software.
>
> So the story is something like that these IRQs have been put into
> hardware in order to compensate for flaws in Windows device driver
> model, I see.
>
> If there are such special registers in some hardware I guess I'm all for
> implementing some generic quirk in gpiolib for people who need to
> software-trigger GPIO IRQs. Could be good for testing too, as there
> are such registers in ARMs PL061 GPIO controller for test, just so as
> to simulate a GPIO IRQ.
>
> gpiod_trig_irq() would work with me, I'm happy to support whatever
> the GPIO hardware can do usually.
>
>> In sound we've switched over to a proper sw interface, and we tie the
>> different parts (drm graphics driver and alsa snd driver) using the
>> component.c framework.
>
> Hm is that solution or something similar proper for USB connector
> as well I wonder... I was thinking about just adding $random_notifier
> but maybe that is a bit ugly :/
>
>>> What is VPG? Now it seems Intel's internal organization is being used as
>>> part of the argument to get this change in and that makes me a bit
>>> annoyed.
> (...)
>> There was chat of usb type C support for forever, but I was always
>> promised that we don't need any interactions on the sw side and it's all
>> magic in hw. There hasn't been any real design discussions in the open
>> source group. VPG is the hw/windows group and generally comes up with
>> "interesting" designs not suitable for upstream.
>>
>> Feel free to just nack this stuff, and please cc intel-gfx/dri-devel in
>> the future (since I tend to ignore everything that's not cc'ed to mailing
>> lists I don't care about, even when I'm on cc personally). I've added them
>> all to cc.
>
> Thanks a lot Daniel, I understand better now. I'm not really against
> adding this "interesting" workaround if that is how Windows works,
> we usually have to go by their standards. From the GPIO point
> of view it is OK, just something the GPIO can do. I would be more
> worried about what the USB PHY maintainer (Felipe) is going to say
> about this.

Adding Felipe's current address. Considering the new domain part of the
address, I'm hopeful we can sort this out. ;)

BR,
Jani.

>
> Yours,
> Linus Walleij
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH 2/2] drm/i915: Get rid of intel_dp_dpcd_read_wake()

[Lyude]

Since we've fixed up drm_dp_dpcd_read() to allow for retries when things
timeout, there's no use for having this function anymore. Good riddens.

Signed-off-by: Lyude 
---
 drivers/gpu/drm/i915/intel_dp.c | 79 -
 1 file changed, 22 insertions(+), 57 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index cdc2c15..fb4cbbe5 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3190,47 +3190,14 @@ static void chv_dp_post_pll_disable(struct 
intel_encoder *encoder)
 }

 /*
- * Native read with retry for link status and receiver capability reads for
- * cases where the sink may still be asleep.
- *
- * Sinks are *supposed* to come up within 1ms from an off state, but we're also
- * supposed to retry 3 times per the spec.
- */
-static ssize_t
-intel_dp_dpcd_read_wake(struct drm_dp_aux *aux, unsigned int offset,
-   void *buffer, size_t size)
-{
-   ssize_t ret;
-   int i;
-
-   /*
-* Sometime we just get the same incorrect byte repeated
-* over the entire buffer. Doing just one throw away read
-* initially seems to "solve" it.
-*/
-   drm_dp_dpcd_read(aux, DP_DPCD_REV, buffer, 1);
-
-   for (i = 0; i < 3; i++) {
-   ret = drm_dp_dpcd_read(aux, offset, buffer, size);
-   if (ret == size)
-   return ret;
-   msleep(1);
-   }
-
-   return ret;
-}
-
-/*
  * Fetch AUX CH registers 0x202 - 0x207 which contain
  * link status information
  */
 bool
 intel_dp_get_link_status(struct intel_dp *intel_dp, uint8_t 
link_status[DP_LINK_STATUS_SIZE])
 {
-   return intel_dp_dpcd_read_wake(_dp->aux,
-  DP_LANE0_1_STATUS,
-  link_status,
-  DP_LINK_STATUS_SIZE) == 
DP_LINK_STATUS_SIZE;
+   return drm_dp_dpcd_read(_dp->aux, DP_LANE0_1_STATUS, link_status,
+   DP_LINK_STATUS_SIZE) == DP_LINK_STATUS_SIZE;
 }

 /* These are source-specific values. */
@@ -3865,8 +3832,8 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
struct drm_i915_private *dev_priv = dev->dev_private;
uint8_t rev;

-   if (intel_dp_dpcd_read_wake(_dp->aux, 0x000, intel_dp->dpcd,
-   sizeof(intel_dp->dpcd)) < 0)
+   if (drm_dp_dpcd_read(_dp->aux, 0x000, intel_dp->dpcd,
+sizeof(intel_dp->dpcd)) < 0)
return false; /* aux transfer failed */

DRM_DEBUG_KMS("DPCD: %*ph\n", (int) sizeof(intel_dp->dpcd), 
intel_dp->dpcd);
@@ -3877,9 +3844,9 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
/* Check if the panel supports PSR */
memset(intel_dp->psr_dpcd, 0, sizeof(intel_dp->psr_dpcd));
if (is_edp(intel_dp)) {
-   intel_dp_dpcd_read_wake(_dp->aux, DP_PSR_SUPPORT,
-   intel_dp->psr_dpcd,
-   sizeof(intel_dp->psr_dpcd));
+   drm_dp_dpcd_read(_dp->aux, DP_PSR_SUPPORT,
+intel_dp->psr_dpcd,
+sizeof(intel_dp->psr_dpcd));
if (intel_dp->psr_dpcd[0] & DP_PSR_IS_SUPPORTED) {
dev_priv->psr.sink_support = true;
DRM_DEBUG_KMS("Detected EDP PSR Panel.\n");
@@ -3890,9 +3857,9 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
uint8_t frame_sync_cap;

dev_priv->psr.sink_support = true;
-   intel_dp_dpcd_read_wake(_dp->aux,
-   DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
-   _sync_cap, 1);
+   drm_dp_dpcd_read(_dp->aux,
+DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
+_sync_cap, 1);
dev_priv->psr.aux_frame_sync = frame_sync_cap ? true : 
false;
/* PSR2 needs frame sync as well */
dev_priv->psr.psr2_support = 
dev_priv->psr.aux_frame_sync;
@@ -3908,15 +3875,13 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
/* Intermediate frequency support */
if (is_edp(intel_dp) &&
(intel_dp->dpcd[DP_EDP_CONFIGURATION_CAP] & 
DP_DPCD_DISPLAY_CONTROL_CAPABLE) &&
-   (intel_dp_dpcd_read_wake(_dp->aux, DP_EDP_DPCD_REV, , 1) 
== 1) &&
+   (drm_dp_dpcd_read(_dp->aux, DP_EDP_DPCD_REV, , 1) == 1) &&
(rev >= 0x03)) { /* eDp v1.4 or higher */
__le16 sink_rates[DP_MAX_SUPPORTED_RATES];
int i;

-   intel_dp_dpcd_read_wake(_dp->aux,
-   DP_SUPPORTED_LINK_RATES,
-   sink_rates,
-   sizeof(sink_rates));
+   

[PATCH 1/2] drm/dp_helper: retry on -ETIMEDOUT in drm_dp_dpcd_access()

[Lyude]

Some sinks need some time during the process of resuming the system from
sleep before they're ready to handle transactions. While it would be
nice if they responded with NACKs in these scenarios, this isn't always
the case as a few sinks will just timeout on all of the transactions
they receive.

This patch was originally intended to be a workaround for a very
mysterious bug on the T560, where any monitors connected to the dock
would fail to turn back on after resume. When resuming the laptop, it
appears that there's a short period of time where we're unable to
complete any aux transactions, as they all immediately timeout. The only
machine I'm able to reproduce this on is the T560 as other production
Skylake models seem to be fine. The period during which AUX transactions
fail appears to be around 22ms long. AFAIK, the dock for the T560 never
actually turns off, the only difference is that it's in SST mode at the
start of the resume process, so it's unclear as to why it would need so
much time to come back up.

There's been a discussion on this issue going on for a while on the
intel-gfx mailing list about this that has, in addition to including
developers from Intel, also had the correspondence of one of the
hardware engineers for Intel:

http://www.spinics.net/lists/intel-gfx/msg88831.html
http://www.spinics.net/lists/intel-gfx/msg88410.html

We've already looked into a couple of possible explanations for the
problem:

- Calling intel_dp_mst_resume() before right fix.
  intel_runtime_pm_enable_interrupts(). This was the first fix I tried,
  and while it worked it definitely wasn't the right fix. This worked
  because DP aux transactions don't actually require interrupts to work:

static uint32_t
intel_dp_aux_wait_done(struct intel_dp *intel_dp, bool has_aux_irq)
{
struct intel_digital_port *intel_dig_port = 
dp_to_dig_port(intel_dp);
struct drm_device *dev = intel_dig_port->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
i915_reg_t ch_ctl = intel_dp->aux_ch_ctl_reg;
uint32_t status;
bool done;

#define C (((status = I915_READ_NOTRACE(ch_ctl)) & 
DP_AUX_CH_CTL_SEND_BUSY) == 0)
if (has_aux_irq)
done = wait_event_timeout(dev_priv->gmbus_wait_queue, C,
  msecs_to_jiffies_timeout(10));
else
done = wait_for_atomic(C, 10) == 0;
if (!done)
DRM_ERROR("dp aux hw did not signal timeout (has irq: 
%i)!\n",
  has_aux_irq);
#undef C

return status;
}

  When there's no interrupts enabled, we end up timing out on the
  wait_event_timeout() call, which causes us to check the DP status
  register once to see if the transaction was successful or not. Since
  this adds a 10ms delay to each aux transaction, it ends up adding a
  long enough delay to the resume process for aux transactions to become
  functional again. This gave us the illusion that enabling interrupts
  had something to do with making things work again, and put me on the
  wrong track for a while.

- Interrupts occurring when we try to perform the aux transactions
  required to put the dock back into MST mode. This isn't the problem,
  as the only interrupts I've observed that come during this timeout
  period are from the snd_hda_intel driver, and disabling that driver
  doesn't appear to change the behavior at all.

- Skylake's PSR block causing issues by performing aux transactions
  while we try to bring the dock out of MST mode. Disabling PSR through
  i915's command line options doesn't seem to change the behavior
  either, nor does preventing the DMC firmware from being loaded.

Since this investigation went on for about 2 weeks, we decided it would
be better for the time being to just workaround this issue until we find
a better fix. This patch adds some behavior we want in
drm_dp_dpcd_access() anyway, since DP aux transactions aren't exactly
robust and this will probably fix quite a few other issues with DP MST
hardware not responding in time. Plus, this is something we already do
in the i915 driver with intel_dp_dpcd_read_wake(), except that that
function is somewhat of a hack and DRM helpers can't make use of it.

Changes since v1

- Patch has been reworked to take the retry logic out of
  intel_dp_mst_resume() and into drm_dp_dpcd_access(), based off a
  suggestion from Daniel Vetter

- Commit message is much longer and gives a better description of the
  issue this was originally intended to workaround.

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

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 9535c5b..38dd969 100644
--- 

[Bug 94595] [Mesa AMD] Texture views attached as framebuffers return their viewed tecture's color encoding and render incorrectly

[bugzilla-dae...@freedesktop.org]

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

Bug ID: 94595
   Summary: [Mesa AMD] Texture views attached as
framebuffers return their viewed tecture's color
encoding and render incorrectly
   Product: Mesa
   Version: git
  Hardware: Other
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: esmith at feralinteractive.com
QA Contact: dri-devel at lists.freedesktop.org

As seen in the example given, when attaching an SRGB/RGB texture view is
created from an alternate RGB/SRGB texture, then attached as a framebuffer,
rendering will gamma correct wrongly and querying
GL_FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING will return GL_LINEAR for an SRGB
backed frame buffer.

This is causing AA renders to be too dark as in our unreleased project, among
many other subtle colour issues.

Tested on latest 11.3 (git-9d9965c from oibaf) and seen on older drivers as
well.
$ g++ TextureViewFramebufferSRGBTest.cpp.cpp $( sdl2-config --cflags --libs )
-lGL
This reproduces on Mesa AMD and swrast.

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

[PATCH 02/23] ARM: dts: n950: add display support

[Laurent Pinchart]

Hi Sebastian,

Thank you for the patch.

On Tuesday 08 March 2016 17:39:34 Sebastian Reichel wrote:
> Signed-off-By: Sebastian Reichel 
> ---
>  arch/arm/boot/dts/omap3-n950.dts | 71 +
>  1 file changed, 71 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/omap3-n950.dts
> b/arch/arm/boot/dts/omap3-n950.dts index 0885b34d5d7d..41b8fb585272 100644
> --- a/arch/arm/boot/dts/omap3-n950.dts
> +++ b/arch/arm/boot/dts/omap3-n950.dts
> @@ -17,6 +17,26 @@
>   compatible = "nokia,omap3-n950", "ti,omap36xx", "ti,omap3";
>  };
> 
> +_pmx_core {
> + dsi_pins: pinmux_dsi_pins {
> + pinctrl-single,pins = <
> + OMAP3_CORE1_IOPAD(0x20dc, PIN_OUTPUT | MUX_MODE1) /* 
> dsi_dx0 -
> data0+ */
> + OMAP3_CORE1_IOPAD(0x20de, PIN_OUTPUT | MUX_MODE1) /* 
> dsi_dy0 -
> data0- */
> + OMAP3_CORE1_IOPAD(0x20e0, PIN_OUTPUT | MUX_MODE1) /* 
> dsi_dx1 -
> clk+   */
> + OMAP3_CORE1_IOPAD(0x20e2, PIN_OUTPUT | MUX_MODE1) /* 
> dsi_dy1 -
> clk-   */
> + OMAP3_CORE1_IOPAD(0x20e4, PIN_OUTPUT | MUX_MODE1) /* 
> dsi_dx2 -
> data1+ */
> + OMAP3_CORE1_IOPAD(0x20e6, PIN_OUTPUT | MUX_MODE1) /* 
> dsi_dy2 -
> data1- */
> + >;
> + };
> +
> + display_pins: pinmux_display_pins {
> + pinctrl-single,pins = <
> + OMAP3_CORE1_IOPAD(0x20ca, PIN_INPUT | MUX_MODE4) /* 
> gpio 62 -
> display te */
> + OMAP3_CORE1_IOPAD(0x20fe, PIN_OUTPUT | MUX_MODE4) /* 
> gpio 87 -
> display reset */
> + >;
> + };
> +};
> +
>   {
>   smia_1: camera at 10 {
>   compatible = "nokia,smia";
> @@ -53,3 +73,54 @@
>   };
>   };
>  };
> +
> + {
> + status = "ok";
> +
> + vdda_video-supply = <>;
> +};
> +
> + {
> + status = "ok";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> +
> + vdd-supply = <>;
> +
> + port {
> + dsi_out_ep: endpoint {
> + remote-endpoint = <_in>;
> + lanes = <2 3 0 1 4 5>;
> + };
> + };
> +
> + lcd0: display {
> + compatible = "nokia,himalaya", "panel-dsi-cm";
> + label = "lcd0";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> +
> + vpnl-supply = <>;
> + vddi-supply = <>;
> +
> + reset-gpios = < 23 GPIO_ACTIVE_HIGH>; /* 87 */
> + te-gpios = < 30 GPIO_ACTIVE_HIGH>;/* 62 */
> +
> + has-dsi-backlight;
> +
> + /* panel is 480x464 with top and bottom 5 lines not visible */

I assume you mean 480x864 ?

> + /* physical dimensions: 48960µm x 88128µm */
> + resolution-x = <480>;
> + resolution-y = <854>;
> + offset-x = <0>;
> + offset-y = <5>;
> +
> + port {
> + lcd0_in: endpoint {
> + remote-endpoint = <_out_ep>;
> + };
> + };
> + };
> +};

-- 
Regards,

Laurent Pinchart

[Bug 94484] Kernel BUG with latest radeon driver

[bugzilla-dae...@freedesktop.org]

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

--- Comment #2 from Tyler Brock  ---
Created attachment 122382
  --> https://bugs.freedesktop.org/attachment.cgi?id=122382=edit
Output from journalctl -ab

I'm running wayland so there is no xorg.log but I can provide the output of
journalctl

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

[Bug 94484] Kernel BUG with latest radeon driver

[bugzilla-dae...@freedesktop.org]

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

--- Comment #3 from Tyler Brock  ---
Created attachment 122383
  --> https://bugs.freedesktop.org/attachment.cgi?id=122383=edit
dmesg output

Adding dmesg output

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

[Bug 94484] Kernel BUG with latest radeon driver

[bugzilla-dae...@freedesktop.org]

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

--- Comment #4 from Tyler Brock  ---
Created attachment 122384
  --> https://bugs.freedesktop.org/attachment.cgi?id=122384=edit
journalctl output showing error

Ugh sorry, this is the one you want. The other two attachments were for this
boot (which is fine) and not the prior one.

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

[Bug 91656] [APITRACE] [bisected] Pillars of Eternity glitch in maps

[bugzilla-dae...@freedesktop.org]

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

Nicolai H�hnle  changed:

   What|Removed |Added

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

--- Comment #16 from Nicolai H�hnle  ---
For what it's worth, a comment in the hack posted on the forum says

"PoE tries to read from and render to a texture at the same time when rendering
the minimap. This happens directly after clearing the fbo to (0, 0, 0, 0) so
bind a dummy texture with that value instead."

So this was either a PoE bug (so-called "feedback loop") or possibly a driver
bug related to clearing a currently bound texture that was fixed recently. In
any case, this seems to be fixed now, so closing this report.

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

[Bug 94595] [Mesa AMD] Texture views attached as framebuffers return their viewed tecture's color encoding and render incorrectly

[bugzilla-dae...@freedesktop.org]

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

--- Comment #1 from Nicolai H�hnle  ---
Thanks for the report - did you forget to attach a source file?

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

[PATCH v9 1/3] staging/android: remove redundant comments on sync_merge_data

[Gustavo Padovan]

From: Gustavo Padovan 

struct sync_merge_data already have documentation on top of the
struct definition. No need to duplicate it.

Signed-off-by: Gustavo Padovan 
Reviewed-by: Maarten Lankhorst 
---
 drivers/staging/android/uapi/sync.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/android/uapi/sync.h 
b/drivers/staging/android/uapi/sync.h
index a0cf357..4467c76 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -21,9 +21,9 @@
  * @fence: returns the fd of the new fence to userspace
  */
 struct sync_merge_data {
-   __s32   fd2; /* fd of second fence */
-   charname[32]; /* name of new fence */
-   __s32   fence; /* fd on newly created fence */
+   __s32   fd2;
+   charname[32];
+   __s32   fence;
 };

 /**
-- 
2.5.0

[PATCH v9 2/3] kernel.h: add to_user_ptr()

[Gustavo Padovan]

From: Gustavo Padovan 

This function had copies in 3 different files. Unify them in kernel.h.

Cc: Andrew Morton 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Rob Clark 
Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 5 -
 drivers/gpu/drm/i915/i915_drv.h  | 5 -
 drivers/gpu/drm/msm/msm_gem_submit.c | 5 -
 include/linux/kernel.h   | 5 +
 4 files changed, 5 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
index 1aba01a..b1fafb6 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
@@ -28,11 +28,6 @@
 #define BO_LOCKED   0x4000
 #define BO_PINNED   0x2000

-static inline void __user *to_user_ptr(u64 address)
-{
-   return (void __user *)(uintptr_t)address;
-}
-
 static struct etnaviv_gem_submit *submit_create(struct drm_device *dev,
struct etnaviv_gpu *gpu, size_t nr)
 {
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b0847b9..c446895 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3564,11 +3564,6 @@ static inline i915_reg_t i915_vgacntrl_reg(struct 
drm_device *dev)
return VGACNTRL;
 }

-static inline void __user *to_user_ptr(u64 address)
-{
-   return (void __user *)(uintptr_t)address;
-}
-
 static inline unsigned long msecs_to_jiffies_timeout(const unsigned int m)
 {
unsigned long j = msecs_to_jiffies(m);
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c 
b/drivers/gpu/drm/msm/msm_gem_submit.c
index 6d7cd3f..e9c8b96 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -28,11 +28,6 @@
 #define BO_LOCKED   0x4000
 #define BO_PINNED   0x2000

-static inline void __user *to_user_ptr(u64 address)
-{
-   return (void __user *)(uintptr_t)address;
-}
-
 static struct msm_gem_submit *submit_create(struct drm_device *dev,
struct msm_gpu *gpu, int nr)
 {
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index f31638c..c0a6001 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -53,6 +53,11 @@

 #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))

+static inline void __user *to_user_ptr(u64 address)
+{
+   return (void __user *)(uintptr_t)address;
+}
+
 /*
  * This looks more complex than it should be. But we need to
  * get the type for the ~ right in round_down (it needs to be
-- 
2.5.0

[PATCH v9 3/3] staging/android: refactor SYNC IOCTLs

[Gustavo Padovan]

From: Gustavo Padovan 

Change SYNC_IOC_FILE_INFO (former SYNC_IOC_FENCE_INFO) behaviour to avoid
future API breaks and optimize buffer allocation.

Now num_fences can be filled by the caller to inform how many fences it
wants to retrieve from the kernel. If the num_fences passed is greater
than zero info->sync_fence_info should point to a buffer with enough space
to fit all fences.

However if num_fences passed to the kernel is 0, the kernel will reply
with number of fences of the sync_file.

Sending first an ioctl with num_fences = 0 can optimize buffer allocation,
in a first call with num_fences = 0 userspace will receive the actual
number of fences in the num_fences filed.

Then it can allocate a buffer with the correct size on sync_fence_info and
call SYNC_IOC_FILE_INFO again, but now with the actual value of num_fences
in the sync_file.

info->sync_fence_info was converted to __u64 pointer to prevent 32bit
compatibility issues. And a flags member was added.

An example userspace code for the later would be:

struct sync_file_info *info;
int err, size, num_fences;

info = malloc(sizeof(*info));

info.flags = 0;
err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
num_fences = info->num_fences;

if (num_fences) {
info.flags = 0;
size = sizeof(struct sync_fence_info) * num_fences;
info->num_fences = num_fences;
info->sync_fence_info = (uint64_t) calloc(num_fences,
  sizeof(struct 
sync_fence_info));

err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
}

Finally the IOCTLs numbers were changed to avoid any potential old
userspace running the old API to get weird errors. Changing the opcodes
will make them fail right away. This is just a precaution, there no
upstream users of these interfaces yet and the only user is Android, but
we don't expect anyone trying to run android userspace and all it
dependencies on top of upstream kernels.

Signed-off-by: Gustavo Padovan 
Reviewed-by: Maarten Lankhorst 
Acked-by: Greg Hackmann 
Acked-by: Rob Clark 
Acked-by: Daniel Vetter 

---
v2: fix fence_info memory leak

v3: Comments from Emil Velikov
- improve commit message
- remove __u64 cast
- remove check for output fields in file_info
- clean up sync_fill_fence_info()

Comments from Maarten Lankhorst
- remove in.num_fences && !in.sync_fence_info check
- remove info->len and use only num_fences to calculate size

Comments from Dan Carpenter
- fix info->sync_fence_info documentation

v4: remove allocated struct sync_file_info (comment from Maarten)

v5: merge all commits that were changing the ABI

v6: fix -Wint-to-pointer-cast error on info.sync_fence_info
---
 drivers/staging/android/sync.c  | 75 -
 drivers/staging/android/uapi/sync.h | 36 +-
 2 files changed, 66 insertions(+), 45 deletions(-)

diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 3a8f210..1d9c530 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -445,6 +445,11 @@ static long sync_file_ioctl_merge(struct sync_file 
*sync_file,
goto err_put_fd;
}

+   if (data.flags || data.pad) {
+   err = -EINVAL;
+   goto err_put_fd;
+   }
+
fence2 = sync_file_fdget(data.fd2);
if (!fence2) {
err = -ENOENT;
@@ -479,13 +484,9 @@ err_put_fd:
return err;
 }

-static int sync_fill_fence_info(struct fence *fence, void *data, int size)
+static void sync_fill_fence_info(struct fence *fence,
+   struct sync_fence_info *info)
 {
-   struct sync_fence_info *info = data;
-
-   if (size < sizeof(*info))
-   return -ENOMEM;
-
strlcpy(info->obj_name, fence->ops->get_timeline_name(fence),
sizeof(info->obj_name));
strlcpy(info->driver_name, fence->ops->get_driver_name(fence),
@@ -495,58 +496,62 @@ static int sync_fill_fence_info(struct fence *fence, void 
*data, int size)
else
info->status = 0;
info->timestamp_ns = ktime_to_ns(fence->timestamp);
-
-   return sizeof(*info);
 }

 static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
unsigned long arg)
 {
-   struct sync_file_info *info;
+   struct sync_file_info info;
+   struct sync_fence_info *fence_info = NULL;
__u32 size;
-   __u32 len = 0;
int ret, i;

-   if (copy_from_user(, (void __user *)arg, sizeof(size)))
+   if (copy_from_user(, (void __user *)arg, sizeof(info)))
return -EFAULT;

-   if (size < sizeof(struct sync_file_info))
+   if (info.flags || info.pad)
return -EINVAL;

-   if (size 

[Bug 94445] Tonga llvm assert since RegisterCoalescer: Need to check DstReg+SrcReg for missing undef flags

[bugzilla-dae...@freedesktop.org]

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

--- Comment #5 from Nicolai H�hnle  ---
Created attachment 122385
  --> https://bugs.freedesktop.org/attachment.cgi?id=122385=edit
Failing shader

The shader still fails to compile. I've contacted Matthias about this.

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

[PATCH v9 2/3] kernel.h: add to_user_ptr()

[Joe Perches]

On Thu, 2016-03-17 at 14:30 -0300, Gustavo Padovan wrote:
> This function had copies in 3 different files. Unify them in
> kernel.h.

This is only used by gpu/drm.

I think this is a poor name for a generic function
that would be in kernel.h.

Isn't there an include file in linux/drm that's
appropriate for this.  Maybe drmP.h

Maybe prefix this function name with drm_ too.

Also, there's this that might conflict:

arch/powerpc/kernel/signal_32.c:#define to_user_ptr(p)          
ptr_to_compat(p)
arch/powerpc/kernel/signal_32.c:#define to_user_ptr(p)          
((unsigned long)(p))

[PATCH 2/2] drm/i915: Get rid of intel_dp_dpcd_read_wake()

[Jani Nikula]

On Thu, 17 Mar 2016, Lyude  wrote:
> Since we've fixed up drm_dp_dpcd_read() to allow for retries when things
> timeout, there's no use for having this function anymore. Good riddens.
>
> Signed-off-by: Lyude 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 79 
> -
>  1 file changed, 22 insertions(+), 57 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index cdc2c15..fb4cbbe5 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3190,47 +3190,14 @@ static void chv_dp_post_pll_disable(struct 
> intel_encoder *encoder)
>  }
>  
>  /*
> - * Native read with retry for link status and receiver capability reads for
> - * cases where the sink may still be asleep.
> - *
> - * Sinks are *supposed* to come up within 1ms from an off state, but we're 
> also
> - * supposed to retry 3 times per the spec.
> - */
> -static ssize_t
> -intel_dp_dpcd_read_wake(struct drm_dp_aux *aux, unsigned int offset,
> - void *buffer, size_t size)
> -{
> - ssize_t ret;
> - int i;
> -
> - /*
> -  * Sometime we just get the same incorrect byte repeated
> -  * over the entire buffer. Doing just one throw away read
> -  * initially seems to "solve" it.
> -  */
> - drm_dp_dpcd_read(aux, DP_DPCD_REV, buffer, 1);

Last time around I dug out the commit adding the line above, which fixed
a bug, and said it should be accounted for somehow. But I've had a
change of heart. I want this function gone already. We've improved the
dp helpers considerably, and if this regresses, we need to look at
fixing this either at the drm level or in our ->transfer hook.

Acked-by: Jani Nikula 


> -
> - for (i = 0; i < 3; i++) {
> - ret = drm_dp_dpcd_read(aux, offset, buffer, size);
> - if (ret == size)
> - return ret;
> - msleep(1);
> - }
> -
> - return ret;
> -}
> -
> -/*
>   * Fetch AUX CH registers 0x202 - 0x207 which contain
>   * link status information
>   */
>  bool
>  intel_dp_get_link_status(struct intel_dp *intel_dp, uint8_t 
> link_status[DP_LINK_STATUS_SIZE])
>  {
> - return intel_dp_dpcd_read_wake(_dp->aux,
> -DP_LANE0_1_STATUS,
> -link_status,
> -DP_LINK_STATUS_SIZE) == 
> DP_LINK_STATUS_SIZE;
> + return drm_dp_dpcd_read(_dp->aux, DP_LANE0_1_STATUS, link_status,
> + DP_LINK_STATUS_SIZE) == DP_LINK_STATUS_SIZE;
>  }
>  
>  /* These are source-specific values. */
> @@ -3865,8 +3832,8 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   uint8_t rev;
>  
> - if (intel_dp_dpcd_read_wake(_dp->aux, 0x000, intel_dp->dpcd,
> - sizeof(intel_dp->dpcd)) < 0)
> + if (drm_dp_dpcd_read(_dp->aux, 0x000, intel_dp->dpcd,
> +  sizeof(intel_dp->dpcd)) < 0)
>   return false; /* aux transfer failed */
>  
>   DRM_DEBUG_KMS("DPCD: %*ph\n", (int) sizeof(intel_dp->dpcd), 
> intel_dp->dpcd);
> @@ -3877,9 +3844,9 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
>   /* Check if the panel supports PSR */
>   memset(intel_dp->psr_dpcd, 0, sizeof(intel_dp->psr_dpcd));
>   if (is_edp(intel_dp)) {
> - intel_dp_dpcd_read_wake(_dp->aux, DP_PSR_SUPPORT,
> - intel_dp->psr_dpcd,
> - sizeof(intel_dp->psr_dpcd));
> + drm_dp_dpcd_read(_dp->aux, DP_PSR_SUPPORT,
> +  intel_dp->psr_dpcd,
> +  sizeof(intel_dp->psr_dpcd));
>   if (intel_dp->psr_dpcd[0] & DP_PSR_IS_SUPPORTED) {
>   dev_priv->psr.sink_support = true;
>   DRM_DEBUG_KMS("Detected EDP PSR Panel.\n");
> @@ -3890,9 +3857,9 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
>   uint8_t frame_sync_cap;
>  
>   dev_priv->psr.sink_support = true;
> - intel_dp_dpcd_read_wake(_dp->aux,
> - DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
> - _sync_cap, 1);
> + drm_dp_dpcd_read(_dp->aux,
> +  DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
> +  _sync_cap, 1);
>   dev_priv->psr.aux_frame_sync = frame_sync_cap ? true : 
> false;
>   /* PSR2 needs frame sync as well */
>   dev_priv->psr.psr2_support = 
> dev_priv->psr.aux_frame_sync;
> @@ -3908,15 +3875,13 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
>   /* Intermediate frequency support */
>   if (is_edp(intel_dp) &&
>   (intel_dp->dpcd[DP_EDP_CONFIGURATION_CAP] & 
> 

[PATCH] prime_mmap_coherency: Add return error tests for prime sync ioctl

[Tiago Vignatti]

This patch adds ioctl-errors subtest to be used for exercising prime sync ioctl
errors.

The subtest constantly interrupts via signals a function doing concurrent blit
to stress out the right usage of prime_sync_*, making sure these ioctl errors
are handled accordingly. Important to note that in case of failure (e.g. in a
case where the ioctl wouldn't try again in a return error) this test does not
reliably catch the problem with 100% of accuracy.

Cc: Chris Wilson 
Signed-off-by: Tiago Vignatti 
---

Chris, your unpolished dma-buf patch for adding return error into the ioctl
calls lgtm. Let me know if you think this kind of test is useful now in igt.

Thanks

Tiago

 tests/prime_mmap_coherency.c | 87 
 1 file changed, 87 insertions(+)

diff --git a/tests/prime_mmap_coherency.c b/tests/prime_mmap_coherency.c
index 180d8a4..bae2144 100644
--- a/tests/prime_mmap_coherency.c
+++ b/tests/prime_mmap_coherency.c
@@ -180,6 +180,88 @@ static void test_write_flush(bool expect_stale_cache)
munmap(ptr_cpu, width * height);
 }

+static void blit_and_cmp(void)
+{
+   drm_intel_bo *bo_1;
+   drm_intel_bo *bo_2;
+   uint32_t *ptr_cpu;
+   uint32_t *ptr2_cpu;
+   int dma_buf_fd, dma_buf2_fd, i;
+   int local_fd;
+   drm_intel_bufmgr *local_bufmgr;
+   struct intel_batchbuffer *local_batch;
+
+   /* recreate process local variables */
+   local_fd = drm_open_driver(DRIVER_INTEL);
+   local_bufmgr = drm_intel_bufmgr_gem_init(local_fd, 4096);
+   igt_assert(local_bufmgr);
+
+   local_batch = intel_batchbuffer_alloc(local_bufmgr, 
intel_get_drm_devid(local_fd));
+   igt_assert(local_batch);
+
+   bo_1 = drm_intel_bo_alloc(local_bufmgr, "BO 1", width * height * 4, 
4096);
+   dma_buf_fd = prime_handle_to_fd_for_mmap(local_fd, bo_1->handle);
+   igt_skip_on(errno == EINVAL);
+
+   ptr_cpu = mmap(NULL, width * height, PROT_READ | PROT_WRITE,
+   MAP_SHARED, dma_buf_fd, 0);
+   igt_assert(ptr_cpu != MAP_FAILED);
+
+   bo_2 = drm_intel_bo_alloc(local_bufmgr, "BO 2", width * height * 4, 
4096);
+   dma_buf2_fd = prime_handle_to_fd_for_mmap(local_fd, bo_2->handle);
+
+   ptr2_cpu = mmap(NULL, width * height, PROT_READ | PROT_WRITE,
+   MAP_SHARED, dma_buf2_fd, 0);
+   igt_assert(ptr2_cpu != MAP_FAILED);
+
+   /* Fill up BO 1 with '1's and BO 2 with '0's */
+   prime_sync_start(dma_buf_fd, true);
+   memset(ptr_cpu, 0x11, width * height);
+   prime_sync_end(dma_buf_fd, true);
+
+   prime_sync_start(dma_buf2_fd, true);
+   memset(ptr2_cpu, 0x00, width * height);
+   prime_sync_end(dma_buf2_fd, true);
+
+   /* Copy BO 1 into BO 2, using blitter. */
+   intel_copy_bo(local_batch, bo_2, bo_1, width * height);
+   usleep(0); /* let someone else claim the mutex */
+
+   /* Compare BOs. If prime_sync_* were executed properly, the caches
+* should be synced. */
+   prime_sync_start(dma_buf2_fd, true);
+   for (i = 0; i < (width * height) / 4; i++)
+   igt_fail_on_f(ptr2_cpu[i] != 0x, "Found 0x%08x at 
offset 0x%08x\n", ptr2_cpu[i], i);
+   prime_sync_end(dma_buf2_fd, true);
+
+   drm_intel_bo_unreference(bo_1);
+   drm_intel_bo_unreference(bo_2);
+   munmap(ptr_cpu, width * height);
+   munmap(ptr2_cpu, width * height);
+}
+
+/*
+ * Constantly interrupt concurrent blits to stress out prime_sync_* and make
+ * sure these ioctl errors are handled accordingly.
+ *
+ * Important to note that in case of failure (e.g. in a case where the ioctl
+ * wouldn't try again in a return error) this test does not reliably catch the
+ * problem with 100% of accuracy.
+ */
+static void test_ioctl_errors(void)
+{
+   int i;
+   int num_children = 8*sysconf(_SC_NPROCESSORS_ONLN);
+
+   igt_fork_signal_helper();
+   igt_fork(child, num_children) {
+   for (i = 0; i < ROUNDS; i++)
+   blit_and_cmp();
+   }
+   igt_waitchildren();
+   igt_stop_signal_helper();
+}
+
 int main(int argc, char **argv)
 {
int i;
@@ -235,6 +317,11 @@ int main(int argc, char **argv)
igt_fail_on_f(!stale, "couldn't find any stale cache lines\n");
}

+   igt_subtest("ioctl-errors") {
+   igt_info("exercising concurrent blit to get ioctl errors\n");
+   test_ioctl_errors();
+   }
+
igt_fixture {
intel_batchbuffer_free(batch);
drm_intel_bufmgr_destroy(bufmgr);
-- 
2.1.4

[PATCH v9 2/3] kernel.h: add to_user_ptr()

[Gustavo Padovan]

2016-03-17 Gustavo Padovan :

> 2016-03-17 Joe Perches :
> 
> > On Thu, 2016-03-17 at 14:30 -0300, Gustavo Padovan wrote:
> > > This function had copies in 3 different files. Unify them in
> > > kernel.h.
> > 
> > This is only used by gpu/drm.
> > 
> > I think this is a poor name for a generic function
> > that would be in kernel.h.
> > 
> > Isn't there an include file in linux/drm that's
> > appropriate for this.  Maybe drmP.h
> > 
> > Maybe prefix this function name with drm_ too.
> 
> No, the next patch adds a user to drivers/staging (which will be moved
> to drivers/dma-buf) soon. Maybe move to a different header in
> include/linux/? not sure which one.
> 
> > Also, there's this that might conflict:
> > 
> > arch/powerpc/kernel/signal_32.c:#define to_user_ptr(p)          
> > ptr_to_compat(p)
> > arch/powerpc/kernel/signal_32.c:#define to_user_ptr(p)          
> > ((unsigned long)(p))
> 
> Right, I'll figure out how to replace these two too.

The powerpc to_user_ptr has a different meaning from the one I'm adding
in this patch. I propose we just rename powerpc's to_user_ptr to
__to_user_ptr and leave the rest as is.

Gustavo

[pull] radeon and amdgpu drm-next-4.6

[Alex Deucher]

Hi Dave,

A few other misc cleanups and bug fixes for 4.6.  Highlights:
- unify endian handling in powerplay
- powerplay fixes
- fix a regression in 4.5 on boards with no display connectors
- fence cleanups and locking fixes
- whitespace cleanups and code refactoring in radeon

The majority of the changes are the whitespace and refactoring in radeon.

The following changes since commit 00b7c4ff7d482d287a591f047e0963d494569b46:

  drm/amdgpu: split pipeline sync out of SDMA vm_flush() as well (2016-03-10 
10:36:13 -0500)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-next-4.6

for you to fetch changes up to b9c743b85dc378510ef0e5ebe3c2e4ac1495c410:

  drm/amdgpu/gfx7: add MTYPE definition (2016-03-17 13:15:43 -0400)


Alex Deucher (4):
  drm/radeon: rework fbdev handling on chips with no connectors
  drm/amd/powerplay: add a common pp endian header
  drm/amd/powerplay: use pp_endian.h for Fiji
  drm/amd/powerplay: use pp_endian.h for Tonga

Christian König (19):
  drm/amdgpu: allow write access to mapped userptrs
  drm/amdgpu: always wait before kmap a BO
  drm/amdgpu: stop waiting on UVD messages before mapping them
  drm/amdgpu: stop using the ring index in the SA
  drm/amdgpu: remove amdgpu_ring_from_fence
  drm/amdgpu: remove amdgpu_fence_wait_next
  drm/amdgpu: move fence structure into amdgpu_fence.c
  drm/amdgpu: cleanup amdgpu_fence_activity
  drm/amdgpu: merge amdgpu_fence_process and _activity
  drm/amdgpu: RCU protected amdgpu_fence_release
  drm/amdgpu: RCU protected amd_sched_fence_release
  drm/amdgpu: add number of hardware submissions to 
amdgpu_fence_driver_init_ring
  drm/amdgpu: keep all fences in an RCU protected array v2
  drm/amdgpu: cleanup amdgpu_fence_wait_empty v2
  drm/amdgpu: signal fences directly in amdgpu_fence_process
  drm/amdgpu: drop the extra fence range check v2
  drm/amdgpu: remove amdgpu_fence_is_signaled
  drm/amdgpu: switch back to 32bit hw fences v2
  drm/amdgpu: removing BO_VAs shouldn't be interruptible

Eric Huang (1):
  drm/amd/powerplay: add uvd/vce dpm enabling flag to fix the performance 
issue for CZ

Flora Cui (1):
  drm/amdgpu/gfx7: add MTYPE definition

Josh Poimboeuf (2):
  drm/radeon: refactor CIK tiling table initialization
  drm/radeon: refactor SI tiling table initialization

Jérome Glisse (1):
  drm/radeon: fix indentation.

Ken Wang (1):
  drm/amdgpu: include the right version of gmc header files for iceland

Monk Liu (3):
  drm/amdgpu: give a fence param to ib_free
  drm/amdgpu: move ib.fence to job.fence
  drm/amdgpu: use sched fence if possible

Rex Zhu (2):
  drm/amd/powerplay: show uvd/vce power gate info for fiji
  drm/amd/powerplay: show uvd/vce power gate enablement for tonga.

rezhu (1):
  drm/amd/powerplay: mv avfs status to smumgr.h

 drivers/gpu/drm/amd/amdgpu/amdgpu.h|   47 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c  |  375 ++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c|   10 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c |   11 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_job.c|7 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c |   16 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c   |   27 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c |   53 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c|8 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c|2 +
 drivers/gpu/drm/amd/amdgpu/cik_sdma.c  |3 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c  |3 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  |6 +-
 drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c |7 +-
 drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c |3 +-
 .../drm/amd/include/asic_reg/gca/gfx_7_2_enum.h|6 +
 drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c |5 +
 drivers/gpu/drm/amd/powerplay/hwmgr/fiji_hwmgr.c   |5 +-
 drivers/gpu/drm/amd/powerplay/hwmgr/fiji_hwmgr.h   |   12 +-
 drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.c  |4 +-
 drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.h  |   12 +-
 drivers/gpu/drm/amd/powerplay/inc/pp_endian.h  |   38 +
 drivers/gpu/drm/amd/powerplay/inc/smumgr.h |   21 +
 drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.h |   18 -
 drivers/gpu/drm/amd/scheduler/sched_fence.c|   23 +-
 drivers/gpu/drm/radeon/atom.c  |7 +-
 drivers/gpu/drm/radeon/atombios_crtc.c |6 +-
 drivers/gpu/drm/radeon/atombios_dp.c   |4 +-
 drivers/gpu/drm/radeon/btc_dpm.c   |   41 +-
 drivers/gpu/drm/radeon/ci_dpm.c|   42 +-
 drivers/gpu/drm/radeon/ci_smc.c|8 +-
 drivers/gpu/drm/radeon/cik.c   | 1697 

[PATCH v3 7/7] dt-bindings: drm/bridge: Update bindings for ADV7533

[Rob Herring]

On Wed, Mar 09, 2016 at 04:27:18PM +0530, Archit Taneja wrote:
> Add description of ADV7533. Add the required and optional properties that
> are specific to it.
> 
> Cc: devicetree at vger.kernel.org
> Cc: Rob Herring 
> 
> Signed-off-by: Archit Taneja 
> ---
>  .../bindings/display/bridge/adi,adv7511.txt| 25 
> +-
>  1 file changed, 20 insertions(+), 5 deletions(-)

Acked-by: Rob Herring 

[PATCH] drm/amdgpu: allow write access to mapped userptrs

[Jerome Glisse]

On Fri, Mar 11, 2016 at 3:29 PM, Christian König
 wrote:
> From: Christian König 
>
> With the updated MMU notifier we should also be able to
> handle the writeback case correctly.
>

Out of curiosity what are you refering too ? I do not see anything
special on amdgpu_mn.c logs and i do not see why you could not use
then for write before.

[PATCH] drm/amdgpu: allow write access to mapped userptrs

[Christian König]

Am 17.03.2016 um 20:18 schrieb Jerome Glisse:
> On Fri, Mar 11, 2016 at 3:29 PM, Christian König
>  wrote:
>> From: Christian König 
>>
>> With the updated MMU notifier we should also be able to
>> handle the writeback case correctly.
>>
> Out of curiosity what are you refering too ? I do not see anything
> special on amdgpu_mn.c logs and i do not see why you could not use
> then for write before.

We moved the get_user_pages() outside of reserving the BO and tested 
that quite extensively.

And don't ask me why that shouldn't have worked. It was you who gave the 
advise to not allow it.

I think the rational was something like that the writeback code disables 
CPU writes, compute a CRC and start to write the page to disk. When the 
GPU could write to the page in that moment the CRC won't match any more 
and we would get errors reported from the disk driver.

But I think that the MMU notifier should catch that case as well.

Cheers,
Christian.

[PATCH v9 2/3] kernel.h: add to_user_ptr()

[Joe Perches]

On Thu, 2016-03-17 at 15:43 -0300, Gustavo Padovan wrote:
> 2016-03-17 Gustavo Padovan :
> > 2016-03-17 Joe Perches :
> > > On Thu, 2016-03-17 at 14:30 -0300, Gustavo Padovan wrote:
> > > > 
> > > > This function had copies in 3 different files. Unify them in
> > > > kernel.h.
> > > This is only used by gpu/drm.
> > > 
> > > I think this is a poor name for a generic function
> > > that would be in kernel.h.
> > > 
> > > Isn't there an include file in linux/drm that's
> > > appropriate for this.  Maybe drmP.h
> > > 
> > > Maybe prefix this function name with drm_ too.
> > No, the next patch adds a user to drivers/staging (which will be moved
> > to drivers/dma-buf) soon. Maybe move to a different header in
> > include/linux/? not sure which one.
> > 
> > > 
> > > Also, there's this that might conflict:
> > > 
> > > arch/powerpc/kernel/signal_32.c:#define to_user_ptr(p)          
> > > ptr_to_compat(p)
> > > arch/powerpc/kernel/signal_32.c:#define to_user_ptr(p)          
> > > ((unsigned long)(p))
> > Right, I'll figure out how to replace these two too.
> The powerpc to_user_ptr has a different meaning from the one I'm adding
> in this patch. I propose we just rename powerpc's to_user_ptr to
> __to_user_ptr and leave the rest as is.

I think that's not a good idea, and you should really check
this concept with the powerpc folk (added to to:s and cc:ed)

If it were really added, then the function meaning is incorrect.

This is taking a u64, casting that to (unsigned long/uint_ptr_t),
then converting that to a user pointer.

Does that naming and use make sense on x86-32 or arm32?

[PATCH v9 2/3] kernel.h: add to_user_ptr()

[Rob Clark]

On Thu, Mar 17, 2016 at 4:22 PM, Joe Perches  wrote:
> On Thu, 2016-03-17 at 15:43 -0300, Gustavo Padovan wrote:
>> 2016-03-17 Gustavo Padovan :
>> > 2016-03-17 Joe Perches :
>> > > On Thu, 2016-03-17 at 14:30 -0300, Gustavo Padovan wrote:
>> > > >
>> > > > This function had copies in 3 different files. Unify them in
>> > > > kernel.h.
>> > > This is only used by gpu/drm.
>> > >
>> > > I think this is a poor name for a generic function
>> > > that would be in kernel.h.
>> > >
>> > > Isn't there an include file in linux/drm that's
>> > > appropriate for this.  Maybe drmP.h
>> > >
>> > > Maybe prefix this function name with drm_ too.
>> > No, the next patch adds a user to drivers/staging (which will be moved
>> > to drivers/dma-buf) soon. Maybe move to a different header in
>> > include/linux/? not sure which one.
>> >
>> > >
>> > > Also, there's this that might conflict:
>> > >
>> > > arch/powerpc/kernel/signal_32.c:#define to_user_ptr(p)  
>> > > ptr_to_compat(p)
>> > > arch/powerpc/kernel/signal_32.c:#define to_user_ptr(p)  
>> > > ((unsigned long)(p))
>> > Right, I'll figure out how to replace these two too.
>> The powerpc to_user_ptr has a different meaning from the one I'm adding
>> in this patch. I propose we just rename powerpc's to_user_ptr to
>> __to_user_ptr and leave the rest as is.
>
> I think that's not a good idea, and you should really check
> this concept with the powerpc folk (added to to:s and cc:ed)
>
> If it were really added, then the function meaning is incorrect.
>
> This is taking a u64, casting that to (unsigned long/uint_ptr_t),
> then converting that to a user pointer.
>
> Does that naming and use make sense on x86-32 or arm32?
>

fwiw Gustavo's version of to_user_ptr() is in use on arm32 and arm64..
Not entirely sure what doesn't make sense about it

BR,
-R

[PATCH v9 2/3] kernel.h: add to_user_ptr()

[Joe Perches]

On Thu, 2016-03-17 at 16:33 -0400, Rob Clark wrote:
> On Thu, Mar 17, 2016 at 4:22 PM, Joe Perches  wrote:
> > On Thu, 2016-03-17 at 15:43 -0300, Gustavo Padovan wrote:
> > > 2016-03-17 Gustavo Padovan :
> > > > 2016-03-17 Joe Perches :
> > > > > On Thu, 2016-03-17 at 14:30 -0300, Gustavo Padovan wrote:
> > > > > > This function had copies in 3 different files. Unify them in
> > > > > > kernel.h.
> > > > > This is only used by gpu/drm.
> > > > > 
> > > > > I think this is a poor name for a generic function
> > > > > that would be in kernel.h.
> > > > > 
> > > > > Isn't there an include file in linux/drm that's
> > > > > appropriate for this.  Maybe drmP.h
> > > > > 
> > > > > Maybe prefix this function name with drm_ too.
> > > > No, the next patch adds a user to drivers/staging (which will be moved
> > > > to drivers/dma-buf) soon. Maybe move to a different header in
> > > > include/linux/? not sure which one.
> > > > 
> > > > > 
> > > > > 
> > > > > Also, there's this that might conflict:
> > > > > 
> > > > > arch/powerpc/kernel/signal_32.c:#define to_user_ptr(p)        
> > > > >   ptr_to_compat(p)
> > > > > arch/powerpc/kernel/signal_32.c:#define to_user_ptr(p)        
> > > > >   ((unsigned long)(p))
> > > > Right, I'll figure out how to replace these two too.
> > > The powerpc to_user_ptr has a different meaning from the one I'm adding
> > > in this patch. I propose we just rename powerpc's to_user_ptr to
> > > __to_user_ptr and leave the rest as is.
> > I think that's not a good idea, and you should really check
> > this concept with the powerpc folk (added to to:s and cc:ed)
> > 
> > If it were really added, then the function meaning is incorrect.
> > 
> > This is taking a u64, casting that to (unsigned long/uint_ptr_t),
> > then converting that to a user pointer.
> > 
> > Does that naming and use make sense on x86-32 or arm32?
> > 
> fwiw Gustavo's version of to_user_ptr() is in use on arm32 and arm64..
> Not entirely sure what doesn't make sense about it

It's a name that seems like it should be a straightforward
cast of a kernel pointer to a __user pointer like:

static inline void __user *to_user_ptr(void *p)
{
return (void __user *)p;
}

As a static function in a single file, it's not
great, but OK, fine, it's static.

As a global function in kernel.h, it's misleading.

[PATCH v9 2/3] kernel.h: add to_user_ptr()

[Rob Clark]

On Thu, Mar 17, 2016 at 4:40 PM, Joe Perches  wrote:
> On Thu, 2016-03-17 at 16:33 -0400, Rob Clark wrote:
>> On Thu, Mar 17, 2016 at 4:22 PM, Joe Perches  wrote:
>> > On Thu, 2016-03-17 at 15:43 -0300, Gustavo Padovan wrote:
>> > > 2016-03-17 Gustavo Padovan :
>> > > > 2016-03-17 Joe Perches :
>> > > > > On Thu, 2016-03-17 at 14:30 -0300, Gustavo Padovan wrote:
>> > > > > > This function had copies in 3 different files. Unify them in
>> > > > > > kernel.h.
>> > > > > This is only used by gpu/drm.
>> > > > >
>> > > > > I think this is a poor name for a generic function
>> > > > > that would be in kernel.h.
>> > > > >
>> > > > > Isn't there an include file in linux/drm that's
>> > > > > appropriate for this.  Maybe drmP.h
>> > > > >
>> > > > > Maybe prefix this function name with drm_ too.
>> > > > No, the next patch adds a user to drivers/staging (which will be moved
>> > > > to drivers/dma-buf) soon. Maybe move to a different header in
>> > > > include/linux/? not sure which one.
>> > > >
>> > > > >
>> > > > >
>> > > > > Also, there's this that might conflict:
>> > > > >
>> > > > > arch/powerpc/kernel/signal_32.c:#define to_user_ptr(p)  
>> > > > > ptr_to_compat(p)
>> > > > > arch/powerpc/kernel/signal_32.c:#define to_user_ptr(p)  
>> > > > > ((unsigned long)(p))
>> > > > Right, I'll figure out how to replace these two too.
>> > > The powerpc to_user_ptr has a different meaning from the one I'm adding
>> > > in this patch. I propose we just rename powerpc's to_user_ptr to
>> > > __to_user_ptr and leave the rest as is.
>> > I think that's not a good idea, and you should really check
>> > this concept with the powerpc folk (added to to:s and cc:ed)
>> >
>> > If it were really added, then the function meaning is incorrect.
>> >
>> > This is taking a u64, casting that to (unsigned long/uint_ptr_t),
>> > then converting that to a user pointer.
>> >
>> > Does that naming and use make sense on x86-32 or arm32?
>> >
>> fwiw Gustavo's version of to_user_ptr() is in use on arm32 and arm64..
>> Not entirely sure what doesn't make sense about it
>
> It's a name that seems like it should be a straightforward
> cast of a kernel pointer to a __user pointer like:
>
> static inline void __user *to_user_ptr(void *p)
> {
> return (void __user *)p;
> }

ahh, ok.  I guess I was used to using it in the context of ioctl
structs..  in that context u64 -> (void __user *) made more sense.

Maybe uapi_to_ptr()?  (ok, not super-creative.. maybe someone has a better idea)

BR,
-R

> As a static function in a single file, it's not
> great, but OK, fine, it's static.
>
> As a global function in kernel.h, it's misleading.
>
>

[PATCH] prime_mmap_coherency: Add return error tests for prime sync ioctl

[Chris Wilson]

On Thu, Mar 17, 2016 at 03:18:03PM -0300, Tiago Vignatti wrote:
> This patch adds ioctl-errors subtest to be used for exercising prime sync 
> ioctl
> errors.
> 
> The subtest constantly interrupts via signals a function doing concurrent blit
> to stress out the right usage of prime_sync_*, making sure these ioctl errors
> are handled accordingly. Important to note that in case of failure (e.g. in a
> case where the ioctl wouldn't try again in a return error) this test does not
> reliably catch the problem with 100% of accuracy.
> 
> Cc: Chris Wilson 
> Signed-off-by: Tiago Vignatti 
> ---
> 
> Chris, your unpolished dma-buf patch for adding return error into the ioctl
> calls lgtm. Let me know if you think this kind of test is useful now in igt.
> 
> Thanks
> 
> Tiago
> 
>  tests/prime_mmap_coherency.c | 87 
> 
>  1 file changed, 87 insertions(+)
> 
> diff --git a/tests/prime_mmap_coherency.c b/tests/prime_mmap_coherency.c
> index 180d8a4..bae2144 100644
> --- a/tests/prime_mmap_coherency.c
> +++ b/tests/prime_mmap_coherency.c
> @@ -180,6 +180,88 @@ static void test_write_flush(bool expect_stale_cache)
>   munmap(ptr_cpu, width * height);
>  }
>  
> +static void blit_and_cmp(void)
> +{
> + drm_intel_bo *bo_1;
> + drm_intel_bo *bo_2;
> + uint32_t *ptr_cpu;
> + uint32_t *ptr2_cpu;
> + int dma_buf_fd, dma_buf2_fd, i;
> + int local_fd;
> + drm_intel_bufmgr *local_bufmgr;
> + struct intel_batchbuffer *local_batch;
> +
> + /* recreate process local variables */
> + local_fd = drm_open_driver(DRIVER_INTEL);
> + local_bufmgr = drm_intel_bufmgr_gem_init(local_fd, 4096);
> + igt_assert(local_bufmgr);
> +
> + local_batch = intel_batchbuffer_alloc(local_bufmgr, 
> intel_get_drm_devid(local_fd));
> + igt_assert(local_batch);
> +
> + bo_1 = drm_intel_bo_alloc(local_bufmgr, "BO 1", width * height * 4, 
> 4096);
> + dma_buf_fd = prime_handle_to_fd_for_mmap(local_fd, bo_1->handle);
> + igt_skip_on(errno == EINVAL);
> +
> + ptr_cpu = mmap(NULL, width * height, PROT_READ | PROT_WRITE,
> + MAP_SHARED, dma_buf_fd, 0);
> + igt_assert(ptr_cpu != MAP_FAILED);
> +
> + bo_2 = drm_intel_bo_alloc(local_bufmgr, "BO 2", width * height * 4, 
> 4096);
> + dma_buf2_fd = prime_handle_to_fd_for_mmap(local_fd, bo_2->handle);
> +
> + ptr2_cpu = mmap(NULL, width * height, PROT_READ | PROT_WRITE,
> + MAP_SHARED, dma_buf2_fd, 0);
> + igt_assert(ptr2_cpu != MAP_FAILED);
> +
> + /* Fill up BO 1 with '1's and BO 2 with '0's */
> + prime_sync_start(dma_buf_fd, true);
> + memset(ptr_cpu, 0x11, width * height);
> + prime_sync_end(dma_buf_fd, true);
> +
> + prime_sync_start(dma_buf2_fd, true);
> + memset(ptr2_cpu, 0x00, width * height);
> + prime_sync_end(dma_buf2_fd, true);
> +
> + /* Copy BO 1 into BO 2, using blitter. */
> + intel_copy_bo(local_batch, bo_2, bo_1, width * height);
> + usleep(0); /* let someone else claim the mutex */
> +
> + /* Compare BOs. If prime_sync_* were executed properly, the caches
> +  * should be synced. */
> + prime_sync_start(dma_buf2_fd, true);

Maybe false here? Note that it makes any difference for the driver atm.

> + for (i = 0; i < (width * height) / 4; i++)
> + igt_fail_on_f(ptr2_cpu[i] != 0x, "Found 0x%08x at 
> offset 0x%08x\n", ptr2_cpu[i], i);
> + prime_sync_end(dma_buf2_fd, true);
> +
> + drm_intel_bo_unreference(bo_1);
> + drm_intel_bo_unreference(bo_2);
> + munmap(ptr_cpu, width * height);
> + munmap(ptr2_cpu, width * height);

Do we have anything that verifies that dmabuf maps persist beyond
gem_close() on the original bo?

Yes, that test should hit all interruptible paths we have in dmabuf and
would be a great addition to igt.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH v9 2/3] kernel.h: add to_user_ptr()

[Joe Perches]

On Thu, 2016-03-17 at 16:50 -0400, Rob Clark wrote:
> On Thu, Mar 17, 2016 at 4:40 PM, Joe Perches  wrote:
[]
> > It's a name that seems like it should be a straightforward
> > cast of a kernel pointer to a __user pointer like:
> > 
> > static inline void __user *to_user_ptr(void *p)
> > {
> >         return (void __user *)p;
> > }
> ahh, ok.  I guess I was used to using it in the context of ioctl
> structs..  in that context u64 -> (void __user *) made more sense.
> 
> Maybe uapi_to_ptr()?  (ok, not super-creative.. maybe someone has a
> better idea)

Maybe u64_to_user_ptr?

[PATCH] prime_mmap_coherency: Add return error tests for prime sync ioctl

[Tiago Vignatti]

On 03/17/2016 06:01 PM, Chris Wilson wrote:
> On Thu, Mar 17, 2016 at 03:18:03PM -0300, Tiago Vignatti wrote:
>> This patch adds ioctl-errors subtest to be used for exercising prime sync 
>> ioctl
>> errors.
>>
>> The subtest constantly interrupts via signals a function doing concurrent 
>> blit
>> to stress out the right usage of prime_sync_*, making sure these ioctl errors
>> are handled accordingly. Important to note that in case of failure (e.g. in a
>> case where the ioctl wouldn't try again in a return error) this test does not
>> reliably catch the problem with 100% of accuracy.
>>
>> Cc: Chris Wilson 
>> Signed-off-by: Tiago Vignatti 
>> ---
>>
>> Chris, your unpolished dma-buf patch for adding return error into the ioctl
>> calls lgtm. Let me know if you think this kind of test is useful now in igt.
>>
>> Thanks
>>
>> Tiago
>>
>>   tests/prime_mmap_coherency.c | 87 
>> 
>>   1 file changed, 87 insertions(+)
>>
>> diff --git a/tests/prime_mmap_coherency.c b/tests/prime_mmap_coherency.c
>> index 180d8a4..bae2144 100644
>> --- a/tests/prime_mmap_coherency.c
>> +++ b/tests/prime_mmap_coherency.c
>> @@ -180,6 +180,88 @@ static void test_write_flush(bool expect_stale_cache)
>>  munmap(ptr_cpu, width * height);
>>   }
>>
>> +static void blit_and_cmp(void)
>> +{
>> +drm_intel_bo *bo_1;
>> +drm_intel_bo *bo_2;
>> +uint32_t *ptr_cpu;
>> +uint32_t *ptr2_cpu;
>> +int dma_buf_fd, dma_buf2_fd, i;
>> +int local_fd;
>> +drm_intel_bufmgr *local_bufmgr;
>> +struct intel_batchbuffer *local_batch;
>> +
>> +/* recreate process local variables */
>> +local_fd = drm_open_driver(DRIVER_INTEL);
>> +local_bufmgr = drm_intel_bufmgr_gem_init(local_fd, 4096);
>> +igt_assert(local_bufmgr);
>> +
>> +local_batch = intel_batchbuffer_alloc(local_bufmgr, 
>> intel_get_drm_devid(local_fd));
>> +igt_assert(local_batch);
>> +
>> +bo_1 = drm_intel_bo_alloc(local_bufmgr, "BO 1", width * height * 4, 
>> 4096);
>> +dma_buf_fd = prime_handle_to_fd_for_mmap(local_fd, bo_1->handle);
>> +igt_skip_on(errno == EINVAL);
>> +
>> +ptr_cpu = mmap(NULL, width * height, PROT_READ | PROT_WRITE,
>> +MAP_SHARED, dma_buf_fd, 0);
>> +igt_assert(ptr_cpu != MAP_FAILED);
>> +
>> +bo_2 = drm_intel_bo_alloc(local_bufmgr, "BO 2", width * height * 4, 
>> 4096);
>> +dma_buf2_fd = prime_handle_to_fd_for_mmap(local_fd, bo_2->handle);
>> +
>> +ptr2_cpu = mmap(NULL, width * height, PROT_READ | PROT_WRITE,
>> +MAP_SHARED, dma_buf2_fd, 0);
>> +igt_assert(ptr2_cpu != MAP_FAILED);
>> +
>> +/* Fill up BO 1 with '1's and BO 2 with '0's */
>> +prime_sync_start(dma_buf_fd, true);
>> +memset(ptr_cpu, 0x11, width * height);
>> +prime_sync_end(dma_buf_fd, true);
>> +
>> +prime_sync_start(dma_buf2_fd, true);
>> +memset(ptr2_cpu, 0x00, width * height);
>> +prime_sync_end(dma_buf2_fd, true);
>> +
>> +/* Copy BO 1 into BO 2, using blitter. */
>> +intel_copy_bo(local_batch, bo_2, bo_1, width * height);
>> +usleep(0); /* let someone else claim the mutex */
>> +
>> +/* Compare BOs. If prime_sync_* were executed properly, the caches
>> + * should be synced. */
>> +prime_sync_start(dma_buf2_fd, true);
>
> Maybe false here? Note that it makes any difference for the driver atm.

oh, my bad.

>> +for (i = 0; i < (width * height) / 4; i++)
>> +igt_fail_on_f(ptr2_cpu[i] != 0x, "Found 0x%08x at 
>> offset 0x%08x\n", ptr2_cpu[i], i);
>> +prime_sync_end(dma_buf2_fd, true);
>> +
>> +drm_intel_bo_unreference(bo_1);
>> +drm_intel_bo_unreference(bo_2);
>> +munmap(ptr_cpu, width * height);
>> +munmap(ptr2_cpu, width * height);
>
> Do we have anything that verifies that dmabuf maps persist beyond
> gem_close() on the original bo?

that's test_refcounting in prime_mmap.c


> Yes, that test should hit all interruptible paths we have in dmabuf and
> would be a great addition to igt.

cool, thanks. I'm resending now v2.

Tiago

[PATCH v2] prime_mmap_coherency: Add return error tests for prime sync ioctl

[Tiago Vignatti]

This patch adds ioctl-errors subtest to be used for exercising prime sync ioctl
errors.

The subtest constantly interrupts via signals a function doing concurrent blit
to stress out the right usage of prime_sync_*, making sure these ioctl errors
are handled accordingly. Important to note that in case of failure (e.g. in a
case where the ioctl wouldn't try again in a return error) this test does not
reliably catch the problem with 100% of accuracy.

v2: fix prime sync direction when reading mmap'ed file.

Cc: Chris Wilson 
Signed-off-by: Tiago Vignatti 
---
 tests/prime_mmap_coherency.c | 87 
 1 file changed, 87 insertions(+)

diff --git a/tests/prime_mmap_coherency.c b/tests/prime_mmap_coherency.c
index 180d8a4..80d1c1f 100644
--- a/tests/prime_mmap_coherency.c
+++ b/tests/prime_mmap_coherency.c
@@ -180,6 +180,88 @@ static void test_write_flush(bool expect_stale_cache)
munmap(ptr_cpu, width * height);
 }

+static void blit_and_cmp(void)
+{
+   drm_intel_bo *bo_1;
+   drm_intel_bo *bo_2;
+   uint32_t *ptr_cpu;
+   uint32_t *ptr2_cpu;
+   int dma_buf_fd, dma_buf2_fd, i;
+   int local_fd;
+   drm_intel_bufmgr *local_bufmgr;
+   struct intel_batchbuffer *local_batch;
+
+   /* recreate process local variables */
+   local_fd = drm_open_driver(DRIVER_INTEL);
+   local_bufmgr = drm_intel_bufmgr_gem_init(local_fd, 4096);
+   igt_assert(local_bufmgr);
+
+   local_batch = intel_batchbuffer_alloc(local_bufmgr, 
intel_get_drm_devid(local_fd));
+   igt_assert(local_batch);
+
+   bo_1 = drm_intel_bo_alloc(local_bufmgr, "BO 1", width * height * 4, 
4096);
+   dma_buf_fd = prime_handle_to_fd_for_mmap(local_fd, bo_1->handle);
+   igt_skip_on(errno == EINVAL);
+
+   ptr_cpu = mmap(NULL, width * height, PROT_READ | PROT_WRITE,
+   MAP_SHARED, dma_buf_fd, 0);
+   igt_assert(ptr_cpu != MAP_FAILED);
+
+   bo_2 = drm_intel_bo_alloc(local_bufmgr, "BO 2", width * height * 4, 
4096);
+   dma_buf2_fd = prime_handle_to_fd_for_mmap(local_fd, bo_2->handle);
+
+   ptr2_cpu = mmap(NULL, width * height, PROT_READ | PROT_WRITE,
+   MAP_SHARED, dma_buf2_fd, 0);
+   igt_assert(ptr2_cpu != MAP_FAILED);
+
+   /* Fill up BO 1 with '1's and BO 2 with '0's */
+   prime_sync_start(dma_buf_fd, true);
+   memset(ptr_cpu, 0x11, width * height);
+   prime_sync_end(dma_buf_fd, true);
+
+   prime_sync_start(dma_buf2_fd, true);
+   memset(ptr2_cpu, 0x00, width * height);
+   prime_sync_end(dma_buf2_fd, true);
+
+   /* Copy BO 1 into BO 2, using blitter. */
+   intel_copy_bo(local_batch, bo_2, bo_1, width * height);
+   usleep(0); /* let someone else claim the mutex */
+
+   /* Compare BOs. If prime_sync_* were executed properly, the caches
+* should be synced. */
+   prime_sync_start(dma_buf2_fd, false);
+   for (i = 0; i < (width * height) / 4; i++)
+   igt_fail_on_f(ptr2_cpu[i] != 0x, "Found 0x%08x at 
offset 0x%08x\n", ptr2_cpu[i], i);
+   prime_sync_end(dma_buf2_fd, false);
+
+   drm_intel_bo_unreference(bo_1);
+   drm_intel_bo_unreference(bo_2);
+   munmap(ptr_cpu, width * height);
+   munmap(ptr2_cpu, width * height);
+}
+
+/*
+ * Constantly interrupt concurrent blits to stress out prime_sync_* and make
+ * sure these ioctl errors are handled accordingly.
+ *
+ * Important to note that in case of failure (e.g. in a case where the ioctl
+ * wouldn't try again in a return error) this test does not reliably catch the
+ * problem with 100% of accuracy.
+ */
+static void test_ioctl_errors(void)
+{
+   int i;
+   int num_children = 8*sysconf(_SC_NPROCESSORS_ONLN);
+
+   igt_fork_signal_helper();
+   igt_fork(child, num_children) {
+   for (i = 0; i < ROUNDS; i++)
+   blit_and_cmp();
+   }
+   igt_waitchildren();
+   igt_stop_signal_helper();
+}
+
 int main(int argc, char **argv)
 {
int i;
@@ -235,6 +317,11 @@ int main(int argc, char **argv)
igt_fail_on_f(!stale, "couldn't find any stale cache lines\n");
}

+   igt_subtest("ioctl-errors") {
+   igt_info("exercising concurrent blit to get ioctl errors\n");
+   test_ioctl_errors();
+   }
+
igt_fixture {
intel_batchbuffer_free(batch);
drm_intel_bufmgr_destroy(bufmgr);
-- 
2.1.4

[PATCH v9 2/3] kernel.h: add to_user_ptr()

[Gustavo Padovan]

2016-03-17 Joe Perches :

> On Thu, 2016-03-17 at 16:50 -0400, Rob Clark wrote:
> > On Thu, Mar 17, 2016 at 4:40 PM, Joe Perches  wrote:
> []
> > > It's a name that seems like it should be a straightforward
> > > cast of a kernel pointer to a __user pointer like:
> > > 
> > > static inline void __user *to_user_ptr(void *p)
> > > {
> > >         return (void __user *)p;
> > > }
> > ahh, ok.  I guess I was used to using it in the context of ioctl
> > structs..  in that context u64 -> (void __user *) made more sense.
> > 
> > Maybe uapi_to_ptr()?  (ok, not super-creative.. maybe someone has a
> > better idea)
> 
> Maybe u64_to_user_ptr?

That is a good name. If everyone agrees I can resend this patch
changing it to u64_to_user_ptr. Then should we still keep it on
kernel.h?

Gustavo

[PATCH v9 2/3] kernel.h: add to_user_ptr()

[Rob Clark]

On Thu, Mar 17, 2016 at 5:19 PM, Gustavo Padovan  wrote:
> 2016-03-17 Joe Perches :
>
>> On Thu, 2016-03-17 at 16:50 -0400, Rob Clark wrote:
>> > On Thu, Mar 17, 2016 at 4:40 PM, Joe Perches  wrote:
>> []
>> > > It's a name that seems like it should be a straightforward
>> > > cast of a kernel pointer to a __user pointer like:
>> > >
>> > > static inline void __user *to_user_ptr(void *p)
>> > > {
>> > > return (void __user *)p;
>> > > }
>> > ahh, ok.  I guess I was used to using it in the context of ioctl
>> > structs..  in that context u64 -> (void __user *) made more sense.
>> >
>> > Maybe uapi_to_ptr()?  (ok, not super-creative.. maybe someone has a
>> > better idea)
>>
>> Maybe u64_to_user_ptr?
>
> That is a good name. If everyone agrees I can resend this patch
> changing it to u64_to_user_ptr. Then should we still keep it on
> kernel.h?


works for me

BR,
-R

[Bug 80419] XCOM: Enemy Unknown Causes lockup

[bugzilla-dae...@freedesktop.org]

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

--- Comment #120 from Daniel Exner <dex+fdobugzilla at dragonslave.de> ---
Using xorg 1.18.2, Kernel 4.5 and

OpenGL renderer string: Gallium 0.4 on AMD PITCAIRN (DRM 2.43.0, LLVM 3.8.0)
OpenGL core profile version string: 4.1 (Core Profile) Mesa 11.3.0-devel
(git-84b961d)

I was able to play about 2hours without crash.

But that worked in the past also, at least sometimes. I'll see if I find some
more testing time.

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

[PATCH v9 2/3] kernel.h: add to_user_ptr()

[Joe Perches]

On Thu, 2016-03-17 at 18:19 -0300, Gustavo Padovan wrote:
> 2016-03-17 Joe Perches :
> > On Thu, 2016-03-17 at 16:50 -0400, Rob Clark wrote:
> > > On Thu, Mar 17, 2016 at 4:40 PM, Joe Perches  wrote:
> > []
> > > > It's a name that seems like it should be a straightforward
> > > > cast of a kernel pointer to a __user pointer like:
> > > > 
> > > > static inline void __user *to_user_ptr(void *p)
> > > > {
> > > >         return (void __user *)p;
> > > > }
> > > ahh, ok.  I guess I was used to using it in the context of ioctl
> > > structs..  in that context u64 -> (void __user *) made more sense.
> > > 
> > > Maybe uapi_to_ptr()?  (ok, not super-creative.. maybe someone has a
> > > better idea)
> > Maybe u64_to_user_ptr?
> That is a good name. If everyone agrees I can resend this patch
> changing it to u64_to_user_ptr. Then should we still keep it on
> kernel.h?

I've no particular opinion about location,
but maybe compat.h might be appropriate.

Maybe add all variants:

void __user *u32_to_user_ptr(u32 val)
void __user *u64_to_user_ptr(u64 val)
u32 user_ptr_to_u32(void __user *p)
u64 user_ptr_to_u64(void __user *p)

Maybe there's something about 32 bit userspace on
64 OS that should be done too.

[PATCH libdrm] tests: add virtio_gpu to the driver list

[Gustavo Padovan]

From: Gustavo Padovan 

modetest was failing to work with driver because it wasn't in the
module list.

Signed-off-by: Gustavo Padovan 
---
 tests/util/kms.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/util/kms.c b/tests/util/kms.c
index ce8aaab..650b23b 100644
--- a/tests/util/kms.c
+++ b/tests/util/kms.c
@@ -141,6 +141,7 @@ static const char * const modules[] = {
"atmel-hlcdc",
"fsl-dcu-drm",
"vc4",
+   "virtio_gpu",
 };

 int util_open(const char *device, const char *module)
-- 
2.5.0

[RFC 1/5] drm: Add DRM support for tiny LCD displays

[Noralf Trønnes]

Den 16.03.2016 16:11, skrev Daniel Vetter:
> On Wed, Mar 16, 2016 at 02:34:15PM +0100, Noralf Trønnes wrote:
>> tinydrm provides a very simplified view of DRM for displays that has
>> onboard video memory and is connected through a slow bus like SPI/I2C.
>>
>> Signed-off-by: Noralf Trønnes 
> Yay, it finally happens! I already made a comment on the cover letter
> about the fbdev stuff, I think that's the biggest part to split out from
> tinydrm here. I'm not entirely sure a detailed code review makes sense
> before that part is done (and hey we can start merging already), so just a
> high level review for now:
>
> The big story in kms/drm in the past years is that we've rejecting
> anything that remotely looks like a midlayer. Instead the preferred design
> pattern is a library of helper functions to implement useful default
> behaviour, or sometimes just building blocks for useful default behaviour.
> And then build up real drivers using these pieces. The benefit of that is
> two-fold:
> - easier to share code with other drivers that only need part of the
>behaviour (e.g. fbdev deferred io support).
> - easier to adapt to special hw that needs exceptions since worst case you
>can just copypaste an entire hook. Or implement the special case and
>call the default helper for the normal cases.
>
> lwn has a good article on this pattern:
>
> https://lwn.net/Articles/336262/

I was afraid you would say "midlayer" :-)

How about creating macros like SIMPLE_DEV_PM_OPS and friends to simplify
the drm_driver boilerplate and use that in the drivers?

#define SET_DRM_DRIVER_GEM_CMA_OPS \
 .gem_free_object= drm_gem_cma_free_object, \
 .gem_vm_ops= _gem_cma_vm_ops, \
 .prime_handle_to_fd= drm_gem_prime_handle_to_fd, \
 .prime_fd_to_handle= drm_gem_prime_fd_to_handle, \
 .gem_prime_import= drm_gem_prime_import, \
 .gem_prime_export= drm_gem_prime_export, \
 .gem_prime_get_sg_table= drm_gem_cma_prime_get_sg_table, \
 .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table, \
 .gem_prime_vmap= drm_gem_cma_prime_vmap, \
 .gem_prime_vunmap= drm_gem_cma_prime_vunmap, \
 .gem_prime_mmap= drm_gem_cma_prime_mmap, \
 .dumb_create= drm_gem_cma_dumb_create, \
 .dumb_map_offset= drm_gem_cma_dumb_map_offset, \
 .dumb_destroy= drm_gem_dumb_destroy,

#define TINYDRM_DRM_DRIVER(name_struct, name_str, desc_str, date_str) \
static struct drm_driver name_struct = { \
 .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME \
 | DRIVER_ATOMIC, \
 .load= tinydrm_load, \
 .unload= tinydrm_unload, \
 .lastclose= tinydrm_lastclose, \
 SET_DRM_DRIVER_GEM_CMA_OPS \
 .fops= _fops, \
 .name= name_str, \
 .desc= desc_str, \
 .date= date_str, \
 .major= 1, \
 .minor= 0, \
}

Now the driver can do this:
TINYDRM_DRM_DRIVER(adafruit_tft, "adafruit-tft", Adafruit TFT", "20160317");

In addition to that, the tinydrm specific parts that make up
tinydrm_load/unload can be exported if someone wants it slightly different.


> In the case of tinydrm I think that means we should have a bunch of new
> drm helpers, or extensions for existing ones:
> - fbdev deferred io support using ->dirtyfb in drm_fb_helper.c.

Are you thinking something like this?

struct drm_fb_helper_funcs {
 int (*dirtyfb)(struct drm_fb_helper *fb_helper,
struct drm_clip_rect *clip);
};

struct drm_fb_helper {
 spinlock_t dirty_lock;
 struct drm_clip_rect *dirty_clip;
};


Should I extend drm_fb_helper_sys_* or make it explicit with
drm_fb_helper_sys_*_deferred functions?

#ifdef CONFIG_FB_DEFERRED_IO
/* Will just return if info->fbdefio is not set */
void drm_fb_helper_sys_deferred(struct fb_info *info, u32 x, u32 y,
 u32 width, u32 height);
#else
static inline void drm_fb_helper_sys_deferred(struct fb_info *info, u32 
x, u32 y,
   u32 width, u32 height)
{ }
#endif

void drm_fb_helper_sys_imageblit(struct fb_info *info,
  const struct fb_image *image)
{
 sys_imageblit(info, image);
 drm_fb_helper_sys_deferred(info, image->dx, image->dy, image->width,
image->height);
}

OR

void drm_fb_helper_sys_imageblit_deferred(struct fb_info *info,
   const struct fb_image *image)
{
 drm_fb_helper_sys_imageblit(info, image);
 drm_fb_helper_sys_deferred(info, image->dx, image->dy, image->width,
image->height);
}


Initially I used drm_fb_cma_helper.c with some added deferred code.
This worked fine for fbcon, but the deferred 

[PATCH v9 2/3] kernel.h: add to_user_ptr()

[Gustavo Padovan]

2016-03-17 Joe Perches :

> On Thu, 2016-03-17 at 18:19 -0300, Gustavo Padovan wrote:
> > 2016-03-17 Joe Perches :
> > > On Thu, 2016-03-17 at 16:50 -0400, Rob Clark wrote:
> > > > On Thu, Mar 17, 2016 at 4:40 PM, Joe Perches  wrote:
> > > []
> > > > > It's a name that seems like it should be a straightforward
> > > > > cast of a kernel pointer to a __user pointer like:
> > > > > 
> > > > > static inline void __user *to_user_ptr(void *p)
> > > > > {
> > > > >         return (void __user *)p;
> > > > > }
> > > > ahh, ok.  I guess I was used to using it in the context of ioctl
> > > > structs..  in that context u64 -> (void __user *) made more sense.
> > > > 
> > > > Maybe uapi_to_ptr()?  (ok, not super-creative.. maybe someone has a
> > > > better idea)
> > > Maybe u64_to_user_ptr?
> > That is a good name. If everyone agrees I can resend this patch
> > changing it to u64_to_user_ptr. Then should we still keep it on
> > kernel.h?
> 
> I've no particular opinion about location,
> but maybe compat.h might be appropriate.

I don't think this is really related to compat. I'd keep kernel.h.

The problem I'm trying to solve here is:

CC  drivers/dma-buf/sync_file.o
drivers/dma-buf/sync_file.c: In function ‘sync_file_ioctl_fence_info’:
drivers/dma-buf/sync_file.c:341:19: warning: cast to pointer from
integer of different size [-Wint-to-pointer-cast]
  if (copy_to_user((void __user *)info.sync_fence_info, fence_info,

where info.sync_fence_info is __u64.

Gustavo

[PATCH v14.1 04/17] drm: bridge: analogix/dp: fix some obvious code style

[Heiko Stübner]

Fix some obvious alignment problems, like alignment and line
over 80 characters problems, make this easy to be maintained
later.

Signed-off-by: Yakir Yang 
Acked-by: Jingoo Han 
Reviewed-by: Krzysztof Kozlowski 
Tested-by: Javier Martinez Canillas 
---
Changes in v14.1:
- Rebase against drm-next from 2016-03-17

Changes in v14: None
Changes in v13: None
Changes in v12:
- Add the ack from Jingoo

Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5:
- Resequence this patch after analogix_dp driver have been split
  from exynos_dp code, and rephrase reasonable commit message, and
  remove some controversial style (Krzysztof)
-   analogix_dp_write_byte_to_dpcd(
-   dp, DP_TEST_RESPONSE,
+   analogix_dp_write_byte_to_dpcd(dp,
+   DP_TEST_RESPONSE,
DP_TEST_EDID_CHECKSUM_WRITE);

Changes in v4: None
Changes in v3: None
Changes in v2:
- Improved commit message more readable, and avoid using some
  uncommon style like bellow: (Joe Preches)
-  retval = exynos_dp_read_bytes_from_i2c(...
  ...);
+  retval =
+  exynos_dp_read_bytes_from_i2c(..);

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 129 ++---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  72 ++--
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 124 ++--
 drivers/gpu/drm/exynos/exynos_dp.c |   4 +-
 4 files changed, 165 insertions(+), 164 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 392c296..6901a6f 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -64,7 +64,7 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device 
*dp)

while (analogix_dp_get_plug_in_status(dp) != 0) {
timeout_loop++;
-   if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
+   if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
dev_err(dp->dev, "failed to get hpd plug status\n");
return -ETIMEDOUT;
}
@@ -101,8 +101,8 @@ static int analogix_dp_read_edid(struct analogix_dp_device 
*dp)

/* Read Extension Flag, Number of 128-byte EDID extension blocks */
retval = analogix_dp_read_byte_from_i2c(dp, I2C_EDID_DEVICE_ADDR,
-   EDID_EXTENSION_FLAG,
-   _block);
+   EDID_EXTENSION_FLAG,
+   _block);
if (retval)
return retval;

@@ -110,7 +110,8 @@ static int analogix_dp_read_edid(struct analogix_dp_device 
*dp)
dev_dbg(dp->dev, "EDID data includes a single extension!\n");

/* Read EDID data */
-   retval = analogix_dp_read_bytes_from_i2c(dp, 
I2C_EDID_DEVICE_ADDR,
+   retval = analogix_dp_read_bytes_from_i2c(dp,
+   I2C_EDID_DEVICE_ADDR,
EDID_HEADER_PATTERN,
EDID_BLOCK_LENGTH,
[EDID_HEADER_PATTERN]);
@@ -141,7 +142,7 @@ static int analogix_dp_read_edid(struct analogix_dp_device 
*dp)
}

analogix_dp_read_byte_from_dpcd(dp, DP_TEST_REQUEST,
-   _vector);
+   _vector);
if (test_vector & DP_TEST_LINK_EDID_READ) {
analogix_dp_write_byte_to_dpcd(dp,
DP_TEST_EDID_CHECKSUM,
@@ -155,10 +156,8 @@ static int analogix_dp_read_edid(struct analogix_dp_device 
*dp)

/* Read EDID data */
retval = analogix_dp_read_bytes_from_i2c(dp,
-   I2C_EDID_DEVICE_ADDR,
-   EDID_HEADER_PATTERN,
-   EDID_BLOCK_LENGTH,
-   [EDID_HEADER_PATTERN]);
+   I2C_EDID_DEVICE_ADDR, EDID_HEADER_PATTERN,
+   EDID_BLOCK_LENGTH, [EDID_HEADER_PATTERN]);
if (retval != 0) {
dev_err(dp->dev, "EDID Read failed!\n");
return -EIO;
@@ -169,16 +168,13 @@ static int analogix_dp_read_edid(struct 
analogix_dp_device *dp)
return -EIO;
}

-   analogix_dp_read_byte_from_dpcd(dp,
-   DP_TEST_REQUEST,
-   _vector);
+   analogix_dp_read_byte_from_dpcd(dp, DP_TEST_REQUEST,
+   

[PATCH v13 2/2] drm/bridge: Add I2C based driver for ps8640 bridge

[Jitao Shi]

This patch adds drm_bridge driver for parade DSI to eDP bridge chip.

Signed-off-by: Jitao Shi 
---
Changes since v12:
 - fix hw_chip_id build warning

Changes since v11:
 - Remove depends on I2C, add DRM depends
 - Reuse ps8640_write_bytes() in ps8640_write_byte()
 - Use timer check for polling like the routines in 
 - Fix no drm_connector_unregister/drm_connector_cleanup when 
ps8640_bridge_attach fail
 - Check the ps8640 hardware id in ps8640_validate_firmware
 - Remove fw_version check
 - Move ps8640_validate_firmware before ps8640_enter_bl
 - Add ddc_i2c unregister when probe fail and ps8640_remove

The following patches are needed to support dsi host through none dsi bus:
https://patchwork.kernel.org/patch/8289181/ ("drm/dsi: check for CONFIG_OF when 
defining")
https://patchwork.kernel.org/patch/8289051/ ("drm/dsi: Use 
mipi_dsi_device_register_full for DSI device")
https://patchwork.kernel.org/patch/8289081/ ("drm/dsi: Try to match non-DT DSI 
devices")
https://patchwork.kernel.org/patch/8289121/ ("drm/dsi: Add routine to 
unregister a DSI device")
https://patchwork.kernel.org/patch/8289091/ ("drm/dsi: Get DSI host by DT 
device node")
---
 drivers/gpu/drm/bridge/Kconfig |   12 +
 drivers/gpu/drm/bridge/Makefile|1 +
 drivers/gpu/drm/bridge/parade-ps8640.c | 1073 
 3 files changed, 1086 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/parade-ps8640.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 27e2022..be6084e 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -40,4 +40,16 @@ config DRM_PARADE_PS8622
---help---
  Parade eDP-LVDS bridge chip driver.

+config DRM_PARADE_PS8640
+   tristate "Parade PS8640 MIPI DSI to eDP Converter"
+   depends on DRM
+   depends on OF
+   select DRM_KMS_HELPER
+   select DRM_MIPI_DSI
+   select DRM_PANEL
+   ---help---
+ Choose this option if you have PS8640 for display
+ The PS8640 is a high-performance and low-power
+ MIPI DSI to eDP converter
+
 endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index f13c33d..fbe38dc 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
 obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
+obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o
diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
b/drivers/gpu/drm/bridge/parade-ps8640.c
new file mode 100644
index 000..7bd5c12
--- /dev/null
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -0,0 +1,1073 @@
+/*
+ * Copyright (c) 2014 MediaTek Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PAGE2_SPI_CFG3 0x82
+#define I2C_TO_SPI_RESET   0x20
+#define PAGE2_ROMADD_BYTE1 0x8e
+#define PAGE2_ROMADD_BYTE2 0x8f
+#define PAGE2_SWSPI_WDATA  0x90
+#define PAGE2_SWSPI_RDATA  0x91
+#define PAGE2_SWSPI_LEN0x92
+#define PAGE2_SWSPI_CTL0x93
+#define TRIGGER_NO_READBACK0x05
+#define TRIGGER_READBACK   0x01
+#define PAGE2_SPI_STATUS   0x9e
+#define PAGE2_GPIO_L   0xa6
+#define PAGE2_GPIO_H   0xa7
+#define PS_GPIO9   BIT(1)
+#define PAGE2_IROM_CTRL0xb0
+#define IROM_ENABLE0xc0
+#define IROM_DISABLE   0x80
+#define PAGE2_SW_REST  0xbc
+#define SPI_SW_RESET   BIT(7)
+#define MPU_SW_RESET   BIT(6)
+#define PAGE2_ENCTLSPI_WR  0xda
+#define PAGE2_I2C_BYPASS   0xea
+#define I2C_BYPASS_EN  0xd0
+#define PAGE3_SET_ADD  0xfe
+#define PAGE3_SET_VAL  0xff
+#define VDO_CTL_ADD0x13
+#define VDO_DIS0x18
+#define VDO_EN 0x1c
+#define PAGE4_REV_L0xf0
+#define PAGE4_REV_H0xf1
+#define PAGE4_CHIP_L   0xf2
+#define PAGE4_CHIP_H   0xf3
+
+/* Firmware */
+#define SPI_MAX_RETRY_CNT  8
+#define PS_FW_NAME "ps864x_fw.bin"
+
+#define FW_CHIP_ID_OFFSET  0
+#define FW_VERSION_OFFSET  2
+#define EDID_I2C_ADDR  0x50
+
+#define WRITE_STATUS_REG_CMD   0x01
+#define 

[PATCH v14.1 01/17] drm: bridge: analogix/dp: split exynos dp driver to bridge directory

[Heiko Stübner]

Split the dp core driver from exynos directory to bridge directory,
and rename the core driver to analogix_dp_*, rename the platform
code to exynos_dp.

Beside the new analogix_dp driver would export six hooks.
"analogix_dp_bind()" and "analogix_dp_unbind()"
"analogix_dp_suspned()" and "analogix_dp_resume()"
"analogix_dp_detect()" and "analogix_dp_get_modes()"

The bind/unbind symbols is used for analogix platform driver to connect
with analogix_dp core driver. And the detect/get_modes is used for analogix
platform driver to init the connector.

They reason why connector need register in helper driver is rockchip drm
haven't implement the atomic API, but Exynos drm have implement it, so
there would need two different connector helper functions, that's why we
leave the connector register in helper driver.

Signed-off-by: Yakir Yang 
---
Changes in v14.1:
- Rebase against drm-next from 2016-03-17
  (adapt to another round of exynos-dp changes)

Changes in v14:
- Rebase the new changes in imx-dp driver
- Split up this patch into 3 parts, make this easy to review (Heiko)

Changes in v13: None
Changes in v12:
- Move the connector init to analogix_dp driver, and using ATOMIC helper (Heiko)

Changes in v11:
- Uses tabs to fix the indentation issues in analogix_dp_core.h (Heiko)

Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6:
- Fix the Kconfig recursive dependency (Javier)

Changes in v5:
- Correct the check condition of gpio_is_valid when driver try to get
  the "hpd-gpios" DT propery. (Heiko)
- Move the platform attach callback in the front of core driver bridge
  attch function. Cause once platform failed at attach, core driver should
  still failed, so no need to init connector before platform attached 
(Krzysztof)
- Keep code style no changes with the previous exynos_dp_code.c in this
  patch, and update commit message about the new export symbol (Krzysztof)
- Gather the device type patch (v4 11/16) into this one. (Krzysztof)
- leave out the connector registration to analogix platform driver. (Thierry)

Changes in v4:
- Update "analogix,hpd-gpios" to "hpd-gpios" DT propery. (Rob)
- Rename "analogix_dp-exynos.c" file name to "exynos_dp.c" (Jingoo)
- Create a separate folder for analogix code in bridge/ (Archit)

Changes in v3:
- Move exynos's video_timing code to analogix_dp-exynos platform driver,
  add get_modes method to struct analogix_dp_plat_data. (Thierry)
- Rename some "samsung*" dts propery to "analogix*". (Heiko)

Changes in v2:
- Remove new copyright (Jingoo)
- Fix compiled failed due to analogix_dp_device misspell


 drivers/gpu/drm/bridge/Kconfig |2 +
 drivers/gpu/drm/bridge/Makefile|1 +
 drivers/gpu/drm/bridge/analogix/Kconfig|3 +
 drivers/gpu/drm/bridge/analogix/Makefile   |1 +
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 1351 +++
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  277 
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 1263 ++
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h  |  366 ++
 drivers/gpu/drm/exynos/Kconfig |3 +-
 drivers/gpu/drm/exynos/Makefile|2 +-
 drivers/gpu/drm/exynos/exynos_dp_core.c| 1353 ++--
 drivers/gpu/drm/exynos/exynos_dp_core.h|  282 
 drivers/gpu/drm/exynos/exynos_dp_reg.c | 1263 --
 drivers/gpu/drm/exynos/exynos_dp_reg.h |  366 --
 include/drm/bridge/analogix_dp.h   |   40 +
 15 files changed, 3391 insertions(+), 3182 deletions(-)
 create mode 100644 drivers/gpu/drm/bridge/analogix/Kconfig
 create mode 100644 drivers/gpu/drm/bridge/analogix/Makefile
 create mode 100644 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
 create mode 100644 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
 create mode 100644 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
 create mode 100644 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
 delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_core.h
 delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_reg.c
 delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_reg.h
 create mode 100644 include/drm/bridge/analogix_dp.h

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 27e2022..efd94e0 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -40,4 +40,6 @@ config DRM_PARADE_PS8622
---help---
  Parade eDP-LVDS bridge chip driver.

+source "drivers/gpu/drm/bridge/analogix/Kconfig"
+
 endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index f13c33d..ff821f4 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
 obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
 obj-$(CONFIG_DRM_NXP_PTN3460) 

[PATCH v14.1 09/17] drm: rockchip: dp: add rockchip platform dp driver

[Heiko Stübner]

Rockchip have three clocks for dp controller, we leave pclk_edp
to analogix_dp driver control, and keep the sclk_edp_24m and
sclk_edp in platform driver.

Signed-off-by: Yakir Yang 
Tested-by: Javier Martinez Canillas 
---
Changes in v14.1:
- replace rockchip_drm_encoder_get_mux_id with the new
  drm_of_encoder_active_endpoint_id

Changes in v14: None
Changes in v13:
- Use .enable instead of preprare/commit in encoder_helper_funcs (Heiko)
- Fix the missing parameters with drm_encoder_init() helper function. (Heiko)

Changes in v12: None
Changes in v11: None
Changes in v10:
- Correct the ROCKCHIP_ANALOGIX_DP indentation in Kconfig to tabs here (Heiko)

Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5:
- Remove the empty line at the end of document, and correct the endpoint
  numbers in the example DT node, and remove the regulator iomux setting
  in driver code while using the pinctl in devicetree instead. (Heiko)
- Add device type declared, cause the previous "platform device type
  support (v4 11/16)" already merge into (v5 02/14).
- Implement connector registration code. (Thierry)

Changes in v4:
- Remove some deprecated DT properties in rockchip dp document.

Changes in v3:
- 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". (Thierry & Heiko)
- Add devicetree binding document. (Heiko)
- Remove "rockchip,panel" DT property, take use of remote point to get panel
  node. (Heiko)
- Add the new function point dp_platdata->get_modes() init.

Changes in v2:
- Get panel node with remote-endpoint method, and create devicetree binding
  for driver. (Heiko)
- Remove the clock enable/disbale with "sclk_edp" & "sclk_edp_24m",
  leave those clock to rockchip dp phy driver.

 drivers/gpu/drm/rockchip/Kconfig|   9 +
 drivers/gpu/drm/rockchip/Makefile   |   1 +
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 384 
 include/drm/bridge/analogix_dp.h|   1 +
 4 files changed, 395 insertions(+)
 create mode 100644 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 76b3362..d30bdc3 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -16,6 +16,15 @@ config DRM_ROCKCHIP
  2D or 3D acceleration; acceleration is performed by other
  IP found on the SoC.

+config ROCKCHIP_ANALOGIX_DP
+   tristate "Rockchip specific extensions for Analogix DP driver"
+   depends on DRM_ROCKCHIP
+   select DRM_ANALOGIX_DP
+   help
+ This selects support for Rockchip SoC specific extensions
+ for the Analogix Core DP driver. If you want to enable DP
+ on RK3288 based SoC, you should selet this option.
+
 config ROCKCHIP_DW_HDMI
 tristate "Rockchip specific extensions for Synopsys DW HDMI"
 depends on DRM_ROCKCHIP
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index df8fbef..05d0713 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -6,6 +6,7 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
rockchip_drm_gem.o rockchip_drm_vop.o
 rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o

+obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
 obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
 obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
 obj-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
new file mode 100644
index 000..a1d94d8
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -0,0 +1,384 @@
+/*
+ * Rockchip SoC DP (Display Port) interface driver.
+ *
+ * Copyright (C) Fuzhou Rockchip Electronics Co., Ltd.
+ * Author: Andy Yan 
+ * Yakir Yang 
+ * Jeff Chen 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+
+#include "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+
+#define to_dp(nm)  container_of(nm, struct rockchip_dp_device, nm)
+
+/* dp grf register offset */
+#define GRF_SOC_CON60x025c
+#define GRF_EDP_LCD_SEL_MASKBIT(5)
+#define GRF_EDP_SEL_VOP_LIT BIT(5)
+#define GRF_EDP_SEL_VOP_BIG 0
+
+struct rockchip_dp_device {
+   struct drm_device   

[PATCH v14 04/17] drm: bridge: analogix/dp: fix some obvious code style

[Heiko Stübner]

Fix some obvious alignment problems, like alignment and line
over 80 characters problems, make this easy to be maintained
later.

Signed-off-by: Yakir Yang 
Acked-by: Jingoo Han 
Reviewed-by: Krzysztof Kozlowski 
Tested-by: Javier Martinez Canillas 
---
Changes in v14.1:
- Rebase against drm-next from 2016-03-17

Changes in v14: None
Changes in v13: None
Changes in v12:
- Add the ack from Jingoo

Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5:
- Resequence this patch after analogix_dp driver have been split
  from exynos_dp code, and rephrase reasonable commit message, and
  remove some controversial style (Krzysztof)
-   analogix_dp_write_byte_to_dpcd(
-   dp, DP_TEST_RESPONSE,
+   analogix_dp_write_byte_to_dpcd(dp,
+   DP_TEST_RESPONSE,
DP_TEST_EDID_CHECKSUM_WRITE);

Changes in v4: None
Changes in v3: None
Changes in v2:
- Improved commit message more readable, and avoid using some
  uncommon style like bellow: (Joe Preches)
-  retval = exynos_dp_read_bytes_from_i2c(...
  ...);
+  retval =
+  exynos_dp_read_bytes_from_i2c(..);

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 129 ++---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  72 ++--
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 124 ++--
 drivers/gpu/drm/exynos/exynos_dp.c |   4 +-
 4 files changed, 165 insertions(+), 164 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 392c296..6901a6f 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -64,7 +64,7 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device 
*dp)

while (analogix_dp_get_plug_in_status(dp) != 0) {
timeout_loop++;
-   if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
+   if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
dev_err(dp->dev, "failed to get hpd plug status\n");
return -ETIMEDOUT;
}
@@ -101,8 +101,8 @@ static int analogix_dp_read_edid(struct analogix_dp_device 
*dp)

/* Read Extension Flag, Number of 128-byte EDID extension blocks */
retval = analogix_dp_read_byte_from_i2c(dp, I2C_EDID_DEVICE_ADDR,
-   EDID_EXTENSION_FLAG,
-   _block);
+   EDID_EXTENSION_FLAG,
+   _block);
if (retval)
return retval;

@@ -110,7 +110,8 @@ static int analogix_dp_read_edid(struct analogix_dp_device 
*dp)
dev_dbg(dp->dev, "EDID data includes a single extension!\n");

/* Read EDID data */
-   retval = analogix_dp_read_bytes_from_i2c(dp, 
I2C_EDID_DEVICE_ADDR,
+   retval = analogix_dp_read_bytes_from_i2c(dp,
+   I2C_EDID_DEVICE_ADDR,
EDID_HEADER_PATTERN,
EDID_BLOCK_LENGTH,
[EDID_HEADER_PATTERN]);
@@ -141,7 +142,7 @@ static int analogix_dp_read_edid(struct analogix_dp_device 
*dp)
}

analogix_dp_read_byte_from_dpcd(dp, DP_TEST_REQUEST,
-   _vector);
+   _vector);
if (test_vector & DP_TEST_LINK_EDID_READ) {
analogix_dp_write_byte_to_dpcd(dp,
DP_TEST_EDID_CHECKSUM,
@@ -155,10 +156,8 @@ static int analogix_dp_read_edid(struct analogix_dp_device 
*dp)

/* Read EDID data */
retval = analogix_dp_read_bytes_from_i2c(dp,
-   I2C_EDID_DEVICE_ADDR,
-   EDID_HEADER_PATTERN,
-   EDID_BLOCK_LENGTH,
-   [EDID_HEADER_PATTERN]);
+   I2C_EDID_DEVICE_ADDR, EDID_HEADER_PATTERN,
+   EDID_BLOCK_LENGTH, [EDID_HEADER_PATTERN]);
if (retval != 0) {
dev_err(dp->dev, "EDID Read failed!\n");
return -EIO;
@@ -169,16 +168,13 @@ static int analogix_dp_read_edid(struct 
analogix_dp_device *dp)
return -EIO;
}

-   analogix_dp_read_byte_from_dpcd(dp,
-   DP_TEST_REQUEST,
-   _vector);
+   analogix_dp_read_byte_from_dpcd(dp, DP_TEST_REQUEST,
+   

[PATCH v13 1/2] Documentation: bridge: Add documentation for ps8640 DT properties

[Jitao Shi]

Add documentation for DT properties supported by
ps8640 DSI-eDP converter.

Signed-off-by: Jitao Shi 
Acked-by: Rob Herring 
Reviewed-by: Philipp Zabel 
---
Changes since v12:
 - No change
---
 .../devicetree/bindings/display/bridge/ps8640.txt  |   43 
 1 file changed, 43 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/ps8640.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/ps8640.txt 
b/Documentation/devicetree/bindings/display/bridge/ps8640.txt
new file mode 100644
index 000..022b33f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ps8640.txt
@@ -0,0 +1,43 @@
+ps8640-bridge bindings
+
+Required properties:
+   - compatible: "parade,ps8640"
+   - reg: first page address of the bridge.
+   - sleep-gpios: OF device-tree gpio specification for PD pin.
+   - reset-gpios: OF device-tree gpio specification for reset pin.
+   - mode-sel-gpios: OF device-tree gpio specification for mode-sel pin.
+   - vdd12-supply: OF device-tree regulator specification for 1.2V power.
+   - vdd33-supply: OF device-tree regulator specification for 3.3V power.
+   - ports: The device node can contain video interface port nodes per
+the video-interfaces bind[1]. For port at 0,set the reg = <0> 
as
+ps8640 dsi in and port at 1,set the reg = <1> as ps8640 eDP 
out.
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+   edp-bridge at 18 {
+   compatible = "parade,ps8640";
+   reg = <0x18>;
+   sleep-gpios = < 116 GPIO_ACTIVE_LOW>;
+   reset-gpios = < 115 GPIO_ACTIVE_LOW>;
+   mode-sel-gpios = < 92 GPIO_ACTIVE_HIGH>;
+   vdd12-supply = <_fixed_1v2>;
+   vdd33-supply = <_vgp2_reg>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   port at 0 {
+   reg = <0>;
+   ps8640_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   port at 1 {
+   reg = <1>;
+   ps8640_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
-- 
1.7.9.5

[PATCH 02/23] ARM: dts: n950: add display support

[Sebastian Reichel]

Hi Laurent,

On Thu, Mar 17, 2016 at 02:14:26PM +0200, Laurent Pinchart wrote:
> [...]
> > +
> > +   /* panel is 480x464 with top and bottom 5 lines not visible */
> 
> I assume you mean 480x864 ?

Yes, nice catch. Basically the screen is 480x864, but only
480x854 are visible.

> > +   /* physical dimensions: 48960µm x 88128µm */
> > +   resolution-x = <480>;
> > +   resolution-y = <854>;
> > +   offset-x = <0>;
> > +   offset-y = <5>;
> [...]

-- Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160317/5345a5c0/attachment-0001.sig>

[PATCH 1/4 v3] drm: Add support of ARC PGU display controller

[Alexey Brodkin]

Hi Daniel,

On Tue, 2016-03-15 at 16:59 +0100, Daniel Vetter wrote:
> On Tue, Mar 15, 2016 at 03:24:46PM +, Alexey Brodkin wrote:
> > On Tue, 2016-03-15 at 09:10 +0100, Daniel Vetter wrote:
> > > On Mon, Mar 14, 2016 at 11:15:59AM +, Alexey Brodkin wrote:
> > > > On Mon, 2016-03-14 at 08:00 +0100, Daniel Vetter wrote:
> > > > > On Fri, Mar 11, 2016 at 06:42:36PM +0300, Alexey Brodkin wrote:
> > > > > > 
> > > > > > +static struct drm_driver arcpgu_drm_driver = {
> > > > > > +   .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME |
> > > > > > +      DRIVER_ATOMIC,
> > > > > > +   .preclose = arcpgu_preclose,
> > > > > > +   .lastclose = arcpgu_lastclose,
> > > > > > +   .name = "drm-arcpgu",
> > > > > > +   .desc = "ARC PGU Controller",
> > > > > > +   .date = "20160219",
> > > > > > +   .major = 1,
> > > > > > +   .minor = 0,
> > > > > > +   .patchlevel = 0,
> > > > > > +   .fops = _drm_ops,
> > > > > > +   .load = arcpgu_load,
> > > > > > +   .unload = arcpgu_unload,
> > > > > Load and unload hooks are deprecated (it's a classic midlayer 
> > > > > mistake).
> > > > > Please use drm_dev_alloc/register pairs directly instead, and put your
> > > > > device setup code in-between. Similar for unloading. There's a bunch 
> > > > > of
> > > > > example drivers converted already.
> > > > Ok I took "atmel-hlcdc" as example.
> > > > And that's interesting.
> > > > 
> > > > If I put my arcpgu_load() in between drm_dev_alloc() and
> > > > drm_dev_register() then I'm getting this on the driver probe:
> > > > -->8---
> > > > [drm] Initialized drm 1.1.0 20060810
> > > > arcpgu e0017000.pgu: arc_pgu ID: 0xabbabaab
> > > > [ cut here ]
> > > > WARNING: CPU: 0 PID: 1 at lib/kobject.c:244 
> > > > kobject_add_internal+0x17c/0x498()
> > > > kobject_add_internal failed for card0-HDMI-A-1 (error: -2 parent: card0)
> > > > Modules linked in:
> > > > CPU: 0 PID: 1 Comm: swapper Not tainted 4.5.0-rc3-01062-ga447822-dirty 
> > > > #17
> > > > 
> > > > Stack Trace:
> > > >   arc_unwind_core.constprop.1+0xa4/0x110
> > > >   warn_slowpath_fmt+0x6e/0xfc
> > > >   kobject_add_internal+0x17c/0x498
> > > >   kobject_add+0x98/0xe4
> > > >   device_add+0xc6/0x734
> > > >   device_create_with_groups+0x12a/0x144
> > > >   drm_sysfs_connector_add+0x54/0xe8
> > > >   arcpgu_drm_hdmi_init+0xd4/0x17c
> > > >   arcpgu_probe+0x138/0x24c
> > > >   platform_drv_probe+0x2e/0x6c
> > > >   really_probe+0x212/0x35c
> > > >   __driver_attach+0x90/0x94
> > > >   bus_for_each_dev+0x46/0x80
> > > >   bus_add_driver+0x14e/0x1b4
> > > >   driver_register+0x64/0x108
> > > >   do_one_initcall+0x86/0x194
> > > >   kernel_init_freeable+0xf0/0x188
> > > > ---[ end trace c67166ad43ddcce2 ]---
> > > > [drm:drm_sysfs_connector_add] adding "HDMI-A-1" to sysfs
> > > > [drm:drm_sysfs_connector_add] *ERROR* failed to register connector 
> > > > device: -2
> > > > arcpgu e0017000.pgu: failed to regiter DRM connector and helper funcs
> > > > arcpgu: probe of e0017000.pgu failed with error -2
> > > > -->8---
> > > > 
> > > > But if I move arcpgu_load() after drm_dev_register() then everything
> > > > starts properly and I may see HDMI screen works perfectly fine.
> > > > 
> > > > Any thoughts?
> > > Oops, yeah missed that detail. If you look at atmel it has a loop to
> > > register all the drm connectors _after_ calling drm_dev_register().
> > > Totally forgot about that. Can you pls
> > > - Extract a new drm_connector_register_all() function
> > >   (atmel_hlcdc_dc_connector_plug_all seems to be the best template),
> > >   including kerneldoc.
> > > - Adjust kerneldoc of drm_dev_register() to mention
> > >   drm_connector_register_all() and that ordering constraint.
> > > - Roll that helper out to all the drivers that currently hand-roll it (one
> > >   patch per driver).
> > > 
> > > I know a bit of work but imo not too much, and by doing some small
> > > refactoring every time someone stumbles over a drm pitfall we keep the
> > > subsystem clean to understand. You're up for this? Would be a prep
> > > series, I'll happily review it to get it merged fast. Just a few weeks ago
> > > I merged 20+ patches to make ->mode_fixup hooks optional and remove dummy
> > > ones all over the subsystem, in other words: You'll have my full attention
> > > ;-)
> > Sure, I'm ready to pay that price :)
> > Stay tuned and patches will follow.
> Awesome, looking forward to your patches.

Sorry it took longer for me to finally put my hands on that work but anyways.

I'm looking now at how drivers use existing drm_connector_unplug_all() and
their implementation of what would be drm_connector_plug_all() and see
in some implementations people wraps both helpers with
mutex_{lock|unlock}(>mode_config.mutex). But not everybody does this.

So essentially my questions are:
 [1] If it's 

[PATCH v15 1/3] drm: rockchip: Add basic drm driver

[Tomeu Vizoso]

On 16 March 2016 at 16:23, Tomeu Vizoso  wrote:
> On 15 March 2016 at 02:30, Mark yao  wrote:
>> On 2016年03月14日 21:35, Tomeu Vizoso wrote:
>>>
>>> On 2 December 2014 at 10:15, Mark Yao  wrote:
>>>>
>>>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>>>> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>>>> new file mode 100644
>>>> index 000..e7ca25b
>>>> --- /dev/null
>>>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>>>> @@ -0,0 +1,1455 @@
>>>
>>> ...
>>>>
>>>> +static bool vop_crtc_mode_fixup(struct drm_crtc *crtc,
>>>> +   const struct drm_display_mode *mode,
>>>> +   struct drm_display_mode *adjusted_mode)
>>>> +{
>>>> +   if (adjusted_mode->htotal == 0 || adjusted_mode->vtotal == 0)
>>>> +   return false;
>>>
>>> Hi Mark,
>>>
>>> what's the rationale for this?
>>>
>>> Disabling a CRTC as in [0] will cause mode_fixup() to be called with
>>> an empty mode, failing that test.
>>>
>>> Removing the check seems to get things working fine for a short while,
>>> but a later modeset invariably gets the VOP to hang (as reported by
>>> [1]).
>>>
>>> Do you know why that check was put in place and what exactly could be
>>> causing the hw to hang?
>>>
>>> [0]
>>> https://cgit.freedesktop.org/xorg/app/intel-gpu-tools/tree/lib/igt_kms.c#n1616
>>> [1]
>>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/rockchip/rockchip_drm_vop.c#n873
>>>
>>> Thanks,
>>>
>>> Tomeu
>>>
>> Hi Tomeu
>>
>> Just thinking that "adjusted_mode->htotal == 0 || adjusted_mode->vtotal ==
>> 0" is not a good mode for vop.
>
> Ah, ok. Guess it should be removed then so we don't break userspace?
>
>> And you said VOP hang, only WARN_ON error message? or system hang, die?
>
> Sorry, the symptom was only the warning, I just went a bit too far and
> assumed the VOP had stopped working at all.
>
>> I think maybe crtc disable too fast, vblank is off, then no one can feed the
>> wait_update_complete.
>> Can you test it again with following patch?
>
> Actually, in today's testing I don't see that happening any more,
> sorry about that :/
>
> What I have been looking at today is a related issue when running the
> kms_flip_event_leak test from intel-gpu-tools. If I remove the check
> mentioned above so CRTCs can be disabled with the SetCRTC IOCTL, I see
> this page fault the second and subsequent times I run the test.
>
> [   75.809031] rk_iommu ff930300.iommu: Page fault at 0x0100 of type read
> [   75.809035] rk_iommu ff930300.iommu: iova = 0x0100: dte_index:
> 0x4 pte_index: 0x0 page_offset: 0x0
> [   75.809040] rk_iommu ff930300.iommu: mmu_dte_addr: 0x2c258000
> dte at 0x2c258010: 0x2c561001 valid: 1 pte at 0x2c561000: 0x2a06 valid:
> 0 page at 0x flags: 0x0
> [   76.951288] rk_iommu ff930300.iommu: Enable stall request timed
> out, status: 0x4b
>
> I have written a smaller standalone test that is attached in case you
> want to check it out, but I haven't been able to find out why it only
> happens when the test is rerun.
>
> Apparently the VOP is still trying to read a BO (0x0100) right
> when the kernel frees it, but from what I can see, it should be
> scanning another BO at that point.
>
> Do you have any ideas on what could be happening?

Apparently, when the VOP is re-enabled, it will start scanning from
the framebuffer address that had been set last.

Because DMA addresses are recycled and there's going to be a low
number of framebuffers, this isn't going to be obvious unless we make
sure that there isn't a FB allocated at that DMA address any more.

The attached test case does just that.

Regards,

Tomeu

> Thanks,
>
> Tomeu
>
>> drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> @@ -503,6 +503,8 @@ static void vop_crtc_disable(struct drm_crtc *crtc)
>> if (!vop->is_enabled)
>> return;
>>  +   vop_crtc_wait_for_update(crtc);
>> +
>> drm_crtc_vblank_off(crtc);
>>
>> Thanks.
>>
>> --
>> ï¼­ark Yao
>>
>>
-- next part --
A non-text attachment was scrubbed...
Name: page_fault.c
Type: text/x-csrc
Size: 3588 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160317/dcb50599/attachment-0001.c>

[PATCH v9 2/3] kernel.h: add to_user_ptr()

[Gustavo Padovan]

2016-03-17 Joe Perches :

> On Thu, 2016-03-17 at 14:30 -0300, Gustavo Padovan wrote:
> > This function had copies in 3 different files. Unify them in
> > kernel.h.
> 
> This is only used by gpu/drm.
> 
> I think this is a poor name for a generic function
> that would be in kernel.h.
> 
> Isn't there an include file in linux/drm that's
> appropriate for this.  Maybe drmP.h
> 
> Maybe prefix this function name with drm_ too.

No, the next patch adds a user to drivers/staging (which will be moved
to drivers/dma-buf) soon. Maybe move to a different header in
include/linux/? not sure which one.

> Also, there's this that might conflict:
> 
> arch/powerpc/kernel/signal_32.c:#define to_user_ptr(p)          
> ptr_to_compat(p)
> arch/powerpc/kernel/signal_32.c:#define to_user_ptr(p)          
> ((unsigned long)(p))

Right, I'll figure out how to replace these two too.

Gustavo