[RFC PATCH v1 0/4] Add Rockchip RGA support

[Heiko Stübner]

Am Montag, 28. März 2016, 23:07:59 schrieb Emil Velikov:
> On 28 March 2016 at 22:46, Heiko Stübner  wrote:
> > Am Montag, 28. März 2016, 22:35:36 schrieb Emil Velikov:
> >> On 28 March 2016 at 19:44, Heiko Stübner  wrote:
> >> > Am Montag, 28. März 2016, 13:21:02 schrieb Emil Velikov:
> >> >> On 22 March 2016 at 00:42, Heiko Stuebner  wrote:
> >> >> > Hi Yakir,
> >> >> > 
> >> >> > Am Montag, 21. März 2016, 20:17:46 schrieb Yakir Yang:
> >> >> >> On 03/21/2016 07:29 PM, Heiko Stübner wrote:
> >> >> >> > Am Montag, 21. März 2016, 17:28:38 schrieb Yakir Yang:
> >> >> >> >> This patch set would add the RGA direct rendering based 2d
> >> >> >> >> graphics
> >> >> >> >> acceleration module.
> >> >> >> > 
> >> >> >> > very cool to see that.
> >> >> >> 
> >> >> >> ;)
> >> >> >> 
> >> >> >> >> This patch set is based on git repository below:
> >> >> >> >> git://people.freedesktop.org/~airlied/linux drm-next
> >> >> >> >> commit id: 568d7c764ae01f3706085ac8f0d8a8ac7e826bd7
> >> >> >> >> 
> >> >> >> >> And the RGA driver is based on Exynos G2D driver, it only
> >> >> >> >> manages
> >> >> >> >> the
> >> >> >> >> command lists received from user, so user should make the
> >> >> >> >> command
> >> >> >> >> list
> >> >> >> >> to data and registers needed by operation to use.
> >> >> >> >> 
> >> >> >> >> I have prepared an userspace demo application for testing:
> >> >> >> >>https://github.com/yakir-Yang/libdrm-rockchip
> >> >> >> >> 
> >> >> >> >> That is a rockchip libdrm library, and I have write a simple
> >> >> >> >> test
> >> >> >> >> case
> >> >> >> >> "rockchip_rga_test" that would test the below RGA features:
> >> >> >> >> - solid
> >> >> >> >> - copy
> >> >> >> >> - rotation
> >> >> >> >> - flip
> >> >> >> >> - window clip
> >> >> >> >> - dithering
> >> >> >> > 
> >> >> >> > Did you submit your libdrm changes as well?
> >> >> >> > 
> >> >> >> > Userspace-interfaces need to be stable so the other side must
> >> >> >> > also
> >> >> >> > get
> >> >> >> > accepted - even before the kernel change if I remember correctly.
> >> >> >> 
> >> >> >> Got it, and I just saw exynos_fimg2d already landed at mainline
> >> >> >> libdrm.
> >> >> >> But I don't find the way to submit patches to libdrm, would you
> >> >> >> like
> >> >> >> share some helps here ;)
> >> >> > 
> >> >> > Looking at the libdrm sources on cgit.freedesktop.org, I did not
> >> >> > find
> >> >> > any
> >> >> > specific manual on submitting patches.
> >> >> > 
> >> >> > But looking at the dri-list archive, dri-devel at 
> >> >> > lists.freedesktop.org
> >> >> > is
> >> >> > the
> >> >> > right list and looking at the libdrm history it looks like Emil
> >> >> > Velikov
> >> >> >  seems to be doing maintenance-stuff in
> >> >> > libdrm.
> >> >> > And as a 3rd recipient, please also include the linux-rockchip list.
> >> >> > 
> >> >> > @Emil, please shout if I read that wrong :-)
> >> >> 
> >> >> You got it spot on Heiko. There are a few notes though...
> >> >> 
> >> >> As one reuses the existing hardware/IP block, it would be better to
> >> >> avoid copy/pasting code around.
> >> >> 
> >> >> Namely:
> >> >>  - (if possible) factor out the exynos g2d kernel functionality to a
> >> >> 
> >> >> separate kernel module and wire up the rockhip (via dt ?) to use it
> >> >> 
> >> >>  - factor out the g2d specifics out of exynos_drm.h (into
> >> >> 
> >> >> exynos_g2d_drm.h perhaps ?) and make sure exynos_drm.h includes the
> >> >> new header
> >> > 
> >> > I think the IP blocks themself are quite different between Rockchip's
> >> > RGA
> >> > and Samsung's g2d and I guess the similarities are more along the lines
> >> > on how that gets integrated into the respective drm driver and
> >> > userspace.
> >> 
> >> In this case, the exynos_g2d_drm.h seems like a good idea. As I'm
> >> obviously biased, it's better to check how others feel on the topic.
> >> 
> >> >>  - if neither of these are possible, then please ensure that the new
> >> >> 
> >> >> header uses correct types (see the docs [1]), use MIT/X11 license (if
> >> >> possible) and link where upstream userspace is happy with the
> >> >> interface (ideally more than a simple test app like libdrm)
> >> >> These might sound like an overkill, although getting UAPI right and
> >> >> maintaining it forever forces us to do so.
> >> > 
> >> > As for a real-world usecase, maybe the armsoc xserver might be somewhat
> >> > easy to use. While the core changes I did are in the core project
> >> > already, I'm still keeping the actual Rockchip support separate [0] due
> >> > to the not-yet- resolved create_gem ioctl.
> >> > 
> >> > Anyway, the armsoc xserver has some exa implementation hooks were I
> >> > guess
> >> > it might be relatively easy to hook up soc-specific things.
> >> 
> >> Ouch the armsoc ddx... Last time I've checked it felt like a place
> >> where everyone is doing his own thing, with no actual reviews and/or
> >> maintainer.
> > 
> > The development rate is pretty low and maintainership is un

[PATCH 0/3] drm/exynos: Kconfig dependency fixes

[Inki Dae]

Hi Javier,

Thanks for your patch set.

Will merge them if there is no issue.

Thanks,
Inki Dae

2016년 03월 29일 10:28에 Javier Martinez Canillas 이(가) 쓴 글:
> Hello Inki,
> 
> This patch series contains some fixes for the Kconfig symbol dependencies
> of the Exynos DRM driver. They make sure that the Exynos DRM components
> and the media platform drivers that makes use of the same HW IP block are
> not enabled at the same time.
> 
> Best regards,
> Javier
> 
> 
> Javier Martinez Canillas (3):
>   drm/exynos: Use VIDEO_SAMSUNG_S5P_G2D=n as G2D Kconfig dependency
>   drm/exynos: Use VIDEO_SAMSUNG_EXYNOS_GSC=n as GSC Kconfig dependency
>   drm/exynos: Make DRM_EXYNOS_FIMC depend on VIDEO_S5P_FIMC=n
> 
>  drivers/gpu/drm/exynos/Kconfig | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 

[Bug 115431] New: radeon 0000:01:00.0: VCE init error (-22).

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

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

Bug ID: 115431
   Summary: radeon :01:00.0: VCE init error (-22).
   Product: Drivers
   Version: 2.5
Kernel Version: 4.4.6-300.fc23.x86_64
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: luya at fedoraproject.org
Regression: No

Created attachment 210941
  --> https://bugzilla.kernel.org/attachment.cgi?id=210941&action=edit
dmesg boot report

The issue occurred at the boot:

[25494.592428] radeon :01:00.0: VCE init error (-22).

The bug was originally reported on Red Hat Bugzilla.
https://bugzilla.redhat.com/show_bug.cgi?id=1295627

Hardware used is a ASUS X550ZE powered by am APU Kaveri chipset.

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

[PATCH 0/3] drm/exynos: Kconfig dependency fixes

[Seung-Woo Kim]

Hi Javier,

On 2016년 03월 29일 10:28, Javier Martinez Canillas wrote:
> Hello Inki,
> 
> This patch series contains some fixes for the Kconfig symbol dependencies
> of the Exynos DRM driver. They make sure that the Exynos DRM components
> and the media platform drivers that makes use of the same HW IP block are
> not enabled at the same time.
> 
> Best regards,
> Javier
> 
> 
> Javier Martinez Canillas (3):
>   drm/exynos: Use VIDEO_SAMSUNG_S5P_G2D=n as G2D Kconfig dependency
>   drm/exynos: Use VIDEO_SAMSUNG_EXYNOS_GSC=n as GSC Kconfig dependency
>   drm/exynos: Make DRM_EXYNOS_FIMC depend on VIDEO_S5P_FIMC=n

In G2D case, there is only one instance, but for the other cases, there
are several instances and in my environment, I enable both drivers on
v4l2 and drm FIMC/GSC.

So, IMHO, the not-enabled v4l2 dependency is not really required for drm
fimc and drm gsc.

Best Regards,
- Seung-Woo Kim

> 
>  drivers/gpu/drm/exynos/Kconfig | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 

-- 
Seung-Woo Kim
Samsung Software R&D Center
--

[RFC 0/6] drm/fences: add in-fences to DRM

[Inki Dae]

Hi Daniel,

2016년 03월 28일 22:26에 Daniel Stone 이(가) 쓴 글:
> Hi Inki,
> 
> On 28 March 2016 at 02:26, Inki Dae  wrote:
>> 2016년 03월 25일 21:10에 Daniel Stone 이(가) 쓴 글:
>>> Second, really. Vulkan avoids implicit sync entirely, and exposes
>>> fence-like primitives throughout its whole API. These include being
>>> able to pass prerequisite fences for display (what Gustavo is adding
>>> here: something to block on before display), and also when the user
>>> acquires a buffer as a render target, it is given another prerequisite
>>> fence (the other side of what Gustavo is suggesting, i.e. the fence
>>> triggers when the buffer is no longer displayed and becomes available
>>> for rendering).
>>>
>>> In order to implement this correctly, and avoid performance bubbles,
>>> we need a primitive like this exposed through the KMS API, from both
>>> sides. This is especially important when you take the case of
>>> userspace suballocation, where userspace allocates larger blocks and
>>> divides the allocation internally for different uses. Implicit sync
>>> does not work at all for that case.
>>
>> Can you give me more details why implicit sync cannot take care of the case 
>> of userspace suballocation?
> 
> Implicit sync does not know about suballocation, so implicit will
> operate for every range in the buffer, not just the one you want.
> 
> Say you have one kernel buffer, which userspace subdivides into four
> independent buffers. It can perform operations on these buffers which
> are completely independent of each other, and an explicit sync model
> allows this independence to be kept. Implicit sync ties them together,
> so that you cannot do any operations on buffer 1 until all operations
> on buffer 2 have completed.
> 
>> And is there any reason that fence fd shouldn't dependent of DMABUF - now 
>> fence fd is a new file, not DMABUF fd?
> 
> Because dmabuf is for buffer sharing, and fences aren't buffers (they
> will never export page ranges). Is there any particular benefit you
> think you would get from doing this?

Just for consistency. As you know, implicit sync hangs DMA fence up on dmabuf 
object through reservation object so dmabuf independent explicit sync looked 
strange to me.
As you mentioned above, the suballocation would be why explicit sync should be 
indepenent of DMABUF.

In addition, I wonder how explicit and implicit fences could coexist together.
Rob said,
"Implicit sync ofc remains the default, but userspace could opt-in to explicit 
sync instead"

This would mean that if we use explicit sync for user-space then it coexists 
with implicit sync. However, these two sync fences can't see same DMA buffer 
because explicit fence has a different file object from implicit one.
So in this case, I think explicit fence would need to be hung up on the 
reservation object of dmabuf object somehow. Otherwise, although they coexist 
together, are these fences - explicit and implicit - used for differenct 
purpose separately? 

Thanks,
Inki Dae

> 
>>> good thing. This is also the model that ChromeOS is moving towards, so
>>> it becomes more important from that point of view as well.
>>
>> I think Gustavo should had explaned this path series enough to other people 
>> when posting them - ie, what relationship explict and implicit fences have, 
>> and why implicit fence - which is independent of DMABUF - is required, and 
>> what use cases there are in real users, and etc.
> 
> Fair enough, the summary could perhaps contain something like this.
> 
> Cheers,
> Daniel
> 
> 

[Powerpc] Sam460ex Canyonlands issue -Kernel 4.4.6-rc1

[Michel Dänzer]

On 29.03.2016 08:47, Julian Margetson wrote:
> 
> Seeing the following when booting kernel 4.6-rc1 on Acube Sam460ex 
> Canyonlands board.
> This loops for a few times then the kernel boots.
> No problem with the 4.6-rc1 with an A-eon Tabor Freescale e500v2 board.
> 
> Regards
> 
> Julian
> 
> 
>  [2.197839] [ cut here ]
>  [2.197850] WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/drm_irq.c:1368 
> drm_vblank_off+0x2c/0x1e0

That's

if (WARN_ON(pipe >= dev->num_crtcs))

My best guess is that drm_vblank_off is called before drm_vblank_init,
so dev->num_crtcs is still 0.


Please provide the full dmesg output corresponding to the problem.


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

[GIT PULL]: drm: bridge: add analogix_dp driver

[Yakir Yang]

Hi Dave,

This pull request want to land the analogix_dp driver into drm/bridge 
directory,
which reused the Exynos DP code, and add Rockchip DP support. And those
patches have been:
- Acked-by: Inki Dae 
- Acked-by: Mark Yao 
- Acked-by: Rob Herring 
- Acked-by: Jingoo Han 
- Reviewed-by: Krzysztof Kozlowski 
- Tested-by: Caesar Wang 
- Tested-by: Douglas Anderson 
- Tested-by: Heiko Stuebner 
- Tested-by: Javier Martinez Canillas 

Just like you mentioned at email thread [0], I just send the pull 
request directly,
not via another maintainer layer, wish you could land them.

[0]: https://lkml.org/lkml/2016/3/22/846

Thanks


The following changes since commit 4604202ca8d2a5e33b4bca0812b5d92975ed1bd8:

   Merge branch 'drm-next-4.6' of 
git://people.freedesktop.org/~agd5f/linux into drm-next (2016-03-25 
16:02:06 +1000)

are available in the git repository at:


   git at github.com:yakir-Yang/linux.git drm-next-analogix-dp

for you to fetch changes up to 5a6387f2b878e3ae23b22626d9a7c72a760b55fc:

   drm: bridge: analogix/dp: Fix the possible dead lock in bridge 
disable time (2016-03-29 11:09:45 +0800)


Heiko Stuebner (2):
   drm/exynos: dp: rename implementation specific driver part
   drm: bridge: analogix/dp: rename register constants

Yakir Yang (15):
   drm: bridge: analogix/dp: split exynos dp driver to bridge directory
   drm: bridge: analogix/dp: fix some obvious code style
   drm: bridge: analogix/dp: remove duplicate configuration of link 
rate and link count
   drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & 
dynamic_range
   dt-bindings: add document for analogix display port driver
   ARM: dts: exynos/dp: remove some properties that deprecated by 
analogix_dp driver
   drm: rockchip: dp: add rockchip platform dp driver
   dt-bindings: add document for rockchip variant of analogix_dp
   drm: bridge: analogix/dp: add some rk3288 special registers setting
   drm: bridge: analogix/dp: add max link rate and lane count limit 
for RK3288
   drm: bridge: analogix/dp: try force hpd after plug in lookup failed
   drm: bridge: analogix/dp: move hpd detect to connector detect 
function
   drm: bridge: analogix/dp: add edid modes parse in get_modes method
   drm: bridge: analogix/dp: add panel prepare/unprepare in 
suspend/resume time
   drm: bridge: analogix/dp: Fix the possible dead lock in bridge 
disable time

  Documentation/devicetree/bindings/display/bridge/analogix_dp.txt |   
52 
  Documentation/devicetree/bindings/display/exynos/exynos_dp.txt |   93 
++-
  Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt | 
  92 +++
  arch/arm/boot/dts/exynos5250-arndale.dts |2 -
  arch/arm/boot/dts/exynos5250-smdk5250.dts |2 -
  arch/arm/boot/dts/exynos5250-snow-common.dtsi |4 +-
  arch/arm/boot/dts/exynos5250-spring.dts |4 +-
  arch/arm/boot/dts/exynos5420-peach-pit.dts |4 +-
  arch/arm/boot/dts/exynos5420-smdk5420.dts |2 -
  arch/arm/boot/dts/exynos5800-peach-pi.dts |2 -
  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 | 1430 
++
  drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  281 

  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 1320 
++
  drivers/gpu/drm/{exynos/exynos_dp_reg.h => 
bridge/analogix/analogix_dp_reg.h} |  270 ++-
  drivers/gpu/drm/exynos/Kconfig |3 +-
  drivers/gpu/drm/exynos/Makefile |2 +-
  drivers/gpu/drm/exynos/exynos_dp.c |  314 ++
  drivers/gpu/drm/exynos/exynos_dp_core.c | 1499 
---
  drivers/gpu/drm/exynos/exynos_dp_core.h |  282 
  drivers/gpu/drm/exynos/exynos_dp_reg.c | 1263 
--
  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 |   41 +++
  28 files changed, 4105 insertions(+), 3258 deletions(-)
  create mode 100644 
Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
  create mode 100644 
Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
  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

[PATCH 0/3] drm/exynos: Kconfig dependency fixes

[Seung-Woo Kim]

Hello Javier,

On 2016년 03월 29일 11:41, Javier Martinez Canillas wrote:
> Hello Seung-Woo,
> 
> Thanks a lot for your feedback.
> 
> On 03/28/2016 09:46 PM, Seung-Woo Kim wrote:
>> Hi Javier,
>>
>> On 2016년 03월 29일 10:28, Javier Martinez Canillas wrote:
>>> Hello Inki,
>>>
>>> This patch series contains some fixes for the Kconfig symbol dependencies
>>> of the Exynos DRM driver. They make sure that the Exynos DRM components
>>> and the media platform drivers that makes use of the same HW IP block are
>>> not enabled at the same time.
>>>
>>> Best regards,
>>> Javier
>>>
>>>
>>> Javier Martinez Canillas (3):
>>>   drm/exynos: Use VIDEO_SAMSUNG_S5P_G2D=n as G2D Kconfig dependency
>>>   drm/exynos: Use VIDEO_SAMSUNG_EXYNOS_GSC=n as GSC Kconfig dependency
>>>   drm/exynos: Make DRM_EXYNOS_FIMC depend on VIDEO_S5P_FIMC=n
>>
>> In G2D case, there is only one instance, but for the other cases, there
>> are several instances and in my environment, I enable both drivers on
>> v4l2 and drm FIMC/GSC.
>>
>> So, IMHO, the not-enabled v4l2 dependency is not really required for drm
>> fimc and drm gsc.
>>
> 
> I'm confused, it was you who added the depends on !VIDEO_SAMSUNG_EXYNOS_GSC
> for DRM_EXYNOS_GSC in commit aeefb36832e5 ("drm/exynos: gsc: add device tree
> support and remove usage of static mappings").

Yes, you are right. Originally, my goal on the GSC was bringing optional
flag for setting isp mode or wb mode like FIMC in tizen.org git tree.

https://review.tizen.org/git/?p=platform/kernel/linux-exynos.git;a=blobdiff;f=Documentation/devicetree/bindings/media/exynos5-gsc.txt;h=d526777a3abd04d244c46fdd729e3df93bb86917;hp=0604d42f38d1941526d47ad11a958a2a83797f97;hb=751cd6d88d9620c83042641b52fdd244408a3947;hpb=7c7ab44f86d64ba6a6733da8f201a26a6c0e807f

But only devicetree part of GSC was upstreamed and simultaneous enabling
both v4l2 gsc and drm gsc driver is removed. The only reason I set both
driver simultaneously was enabling video codec, exynos-mfc with gsc to
convert RGB plane.

I know Marek already has plan to integrate yuv plane feature of GSC to
DRM KMS. Also, for GSC, simultaneous setup is alredy remove, so your
patch seems better.

> 
>>From the commit message "The driver cannot be used simultaneously with V4L2
> Mem2Mem GScaller driver thought". Did that assumption changed and the depend
> should be removed then? or maybe I misunderstood what you meant.
> 
> Now, I'm not really sure about FIMC either, it was feedback I got from this
> patch [0]. Could you please take a look to that and let me know if enabling
> these drivers simultaneously makes sense then?

About FIMC, there is still simultaneous setup for both v4l2 and drm
driver with devicetree binding flags, samsung,isp-wb and samsung,lcd-wb.

If on the FIMC instance of dt node, samsung,lcd-wb is set, then drm
driver is probed, otherwise v4l2 driver is probed.

Simultaneous FIMC driver is also only for RGB converting of video codec
planes like GSC at least to me.

Marek, do you have any idea about the simultaneous setup for fimc and gsc?

Best Regards,
- Seung-Woo Kim

> 
>> Best Regards,
>> - Seung-Woo Kim
>>
>>>
>>>  drivers/gpu/drm/exynos/Kconfig | 6 +++---
>>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>>
>>
> 
> [0]: https://lkml.org/lkml/2016/3/23/292
> 
> Best regards,
> 

-- 
Seung-Woo Kim
Samsung Software R&D Center
--

[PATCHv14 01/18] dts: exynos4*: add HDMI CEC pin definition to pinctrl

[Krzysztof Kozlowski]

On Fri, Mar 25, 2016 at 10:09 PM, Hans Verkuil  wrote:
> From: Kamil Debski 
>
> Add pinctrl nodes for the HDMI CEC device to the Exynos4210 and
> Exynos4x12 SoCs. These are required by the HDMI CEC device.
>
> Signed-off-by: Kamil Debski 
> Signed-off-by: Hans Verkuil 
> Acked-by: Krzysztof Kozlowski 
> ---
>  arch/arm/boot/dts/exynos4210-pinctrl.dtsi | 7 +++
>  arch/arm/boot/dts/exynos4x12-pinctrl.dtsi | 7 +++
>  2 files changed, 14 insertions(+)

Applied for v4.7 with a little bit different subject:
https://git.kernel.org/cgit/linux/kernel/git/krzk/linux.git/log/?h=next/dt
(but tell me if you need to base on this so I would prepare a tag)

Best regards,

[PATCHv14 02/18] dts: exynos4: add node for the HDMI CEC device

[Krzysztof Kozlowski]

On Fri, Mar 25, 2016 at 10:10 PM, Hans Verkuil  wrote:
> From: Kamil Debski 
>
> This patch adds HDMI CEC node specific to the Exynos4210/4x12 SoC series.
>
> Signed-off-by: Kamil Debski 
> Signed-off-by: Hans Verkuil 
> Acked-by: Krzysztof Kozlowski 
> ---
>  arch/arm/boot/dts/exynos4.dtsi | 12 
>  1 file changed, 12 insertions(+)

Applied for v4.7 with a little bit different subject.

Best regards,
Krzysztof

[PATCHv14 03/18] dts: exynos4412-odroid*: enable the HDMI CEC device

[Krzysztof Kozlowski]

On Fri, Mar 25, 2016 at 10:10 PM, Hans Verkuil  wrote:
> From: Marek Szyprowski 
>
> Add a dts node entry and enable the HDMI CEC device present in the Exynos4
> family of SoCs.
>
> Signed-off-by: Marek Szyprowski 
> Signed-off-by: Hans Verkuil 
> ---
>  arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 4 
>  1 file changed, 4 insertions(+)

Applied for v4.7 with a little bit different subject and the new node
put in alphabetical order. Please don't include your original patch in
your tree because any merging will probably end with having these
nodes twice.

https://git.kernel.org/cgit/linux/kernel/git/krzk/linux.git/log/?h=next/dt
(but tell me if you need to base on this so I would prepare a tag)

Best regards,
Krzysztof

[PATCH] drm: bridge: Make (pre/post) enable/disable callbacks optional

[Daniel Vetter]

On Thu, Mar 24, 2016 at 12:19:32PM +0530, Archit Taneja wrote:
> 
> 
> On 02/26/2016 03:21 PM, Laurent Pinchart wrote:
> >Instead of forcing bridges to implement empty callbacks make them all
> >optional.
> 
> Acked-by: Archit Taneja 

Applied to drm-misc. Still hoping for follow-ups to nuke the now
redundant dummy funcs.

Thanks, Daniel

> 
> >
> >Signed-off-by: Laurent Pinchart  >ideasonboard.com>
> >---
> >  drivers/gpu/drm/drm_bridge.c | 12 
> >  include/drm/drm_crtc.h   |  8 
> >  2 files changed, 16 insertions(+), 4 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> >index bd93453afa61..b3654404abd0 100644
> >--- a/drivers/gpu/drm/drm_bridge.c
> >+++ b/drivers/gpu/drm/drm_bridge.c
> >@@ -186,7 +186,8 @@ void drm_bridge_disable(struct drm_bridge *bridge)
> >
> > drm_bridge_disable(bridge->next);
> >
> >-bridge->funcs->disable(bridge);
> >+if (bridge->funcs->disable)
> >+bridge->funcs->disable(bridge);
> >  }
> >  EXPORT_SYMBOL(drm_bridge_disable);
> >
> >@@ -206,7 +207,8 @@ void drm_bridge_post_disable(struct drm_bridge *bridge)
> > if (!bridge)
> > return;
> >
> >-bridge->funcs->post_disable(bridge);
> >+if (bridge->funcs->post_disable)
> >+bridge->funcs->post_disable(bridge);
> >
> > drm_bridge_post_disable(bridge->next);
> >  }
> >@@ -256,7 +258,8 @@ void drm_bridge_pre_enable(struct drm_bridge *bridge)
> >
> > drm_bridge_pre_enable(bridge->next);
> >
> >-bridge->funcs->pre_enable(bridge);
> >+if (bridge->funcs->pre_enable)
> >+bridge->funcs->pre_enable(bridge);
> >  }
> >  EXPORT_SYMBOL(drm_bridge_pre_enable);
> >
> >@@ -276,7 +279,8 @@ void drm_bridge_enable(struct drm_bridge *bridge)
> > if (!bridge)
> > return;
> >
> >-bridge->funcs->enable(bridge);
> >+if (bridge->funcs->enable)
> >+bridge->funcs->enable(bridge);
> >
> > drm_bridge_enable(bridge->next);
> >  }
> >diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> >index 7fad193dc645..fbc225414f01 100644
> >--- a/include/drm/drm_crtc.h
> >+++ b/include/drm/drm_crtc.h
> >@@ -1584,6 +1584,8 @@ struct drm_bridge_funcs {
> >  *
> >  * The bridge can assume that the display pipe (i.e. clocks and timing
> >  * signals) feeding it is still running when this callback is called.
> >+ *
> >+ * The disable callback is optional.
> >  */
> > void (*disable)(struct drm_bridge *bridge);
> >
> >@@ -1600,6 +1602,8 @@ struct drm_bridge_funcs {
> >  * The bridge must assume that the display pipe (i.e. clocks and timing
> >  * singals) feeding it is no longer running when this callback is
> >  * called.
> >+ *
> >+ * The post_disable callback is optional.
> >  */
> > void (*post_disable)(struct drm_bridge *bridge);
> >
> >@@ -1628,6 +1632,8 @@ struct drm_bridge_funcs {
> >  * will not yet be running when this callback is called. The bridge must
> >  * not enable the display link feeding the next bridge in the chain (if
> >  * there is one) when this callback is called.
> >+ *
> >+ * The pre_enable callback is optional.
> >  */
> > void (*pre_enable)(struct drm_bridge *bridge);
> >
> >@@ -1645,6 +1651,8 @@ struct drm_bridge_funcs {
> >  * signals) feeding it is running when this callback is called. This
> >  * callback must enable the display link feeding the next bridge in the
> >  * chain if there is one.
> >+ *
> >+ * The enable callback is optional.
> >  */
> > void (*enable)(struct drm_bridge *bridge);
> >  };
> >
> 
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
> ___
> 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 v2 6/8] drm/fsl-dcu: add TCON driver

[Alexander Stein]

Hi,

some comments below.

On Monday 28 March 2016 19:00:00, Stefan Agner wrote:
> Add driver for the TCON (timing controller) module. The TCON module
> is a separate module attached after the DCU (display controller
> unit). Each DCU instance has its own, directly connected TCON
> instance. The DCU's RGB and timing signals are passing through
> the TCON module. TCON can provide timing signals for raw TFT panels
> or operate in a bypass mode which leaves all signals unaltered.
> 
> The driver currently only supports the bypass mode.
> 
> Signed-off-by: Stefan Agner 

> --- a/Documentation/devicetree/bindings/display/fsl,dcu.txt
> +++ b/Documentation/devicetree/bindings/display/fsl,dcu.txt
> @@ -14,6 +14,7 @@ Required properties:
>  Optional properties:
>  - clocks:Second handle for pixel clock.
>  - clock-names:   Second name "pix" for pixel clock.
> +- fsl,tcon:  The phandle to the timing controller node.

Maybe a comment this is (currently) only for Vybrid, but not LS1021A.

> --- /dev/null
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_tcon.c
> [...]
> +struct fsl_tcon *fsl_tcon_init(struct device *dev)
> +{
> + struct fsl_tcon *tcon;
> + struct device_node *np;
> + int ret;
> +
> + tcon = devm_kzalloc(dev, sizeof(*tcon), GFP_KERNEL);
> + if (!tcon)
> + return NULL;
> +
> + np = of_parse_phandle(dev->of_node, "fsl,tcon", 0);
> + if (!np) {
> + dev_warn(dev, "Couldn't find the tcon node\n");
> + return NULL;
> + }

Maybe check for device tree node before allocating struct fsl_tcon? Also this 
should not be a warning, as on LS1021A this is to be expected.

Best regards,
Alexander

[PATCH 1/1] drm: fsl-dcu: Use flat cache

[Alexander Stein]

On Friday 25 March 2016 09:24:28, Stefan Agner wrote:
> Hi Alexander,
> 
> On 2016-03-24 06:33, Alexander Stein wrote:
> > Using REGCACHE_RBTREE for MMIO regmap is not valid as spinlock's will be
> > used during cache allocation.
> > 
> > This fixes the following bug:
> > BUG: sleeping function called from invalid context at mm/slab.h:388
> > in_atomic(): 1, irqs_disabled(): 128, pid: 192, name: udevd
> > [...]
> > 
> > Signed-off-by: Alexander Stein 
> > ---
> > Please refer also to the discussion at
> > https://lists.freedesktop.org/archives/dri-devel/2016-January/098696.html
> > 
> >  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> > b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> > index e8d9337..ea65140 100644
> > --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> > +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> > @@ -40,7 +40,7 @@ static const struct regmap_config fsl_dcu_regmap_config
> > = {> 
> > .reg_bits = 32,
> > .reg_stride = 4,
> > .val_bits = 32,
> > 
> > -   .cache_type = REGCACHE_RBTREE,
> > +   .cache_type = REGCACHE_FLAT,
> 
> To use flat regcache you also need to set the max_register.

Ah, thanks for that hint, I was not aware of that. I wondered why my kernel 
crashed using flat cache. Seems cache allocation is too small when 
max_register=0.
Just sent a patch enforcing setting max_register.

> I already have such a patch, see:
> https://lists.freedesktop.org/archives/dri-devel/2016-January/099121.html

Thanks, meanwhile this will do for me. I think.

> However, the current suspend/resume implementation (which uses the
> regcache) is anyway flawed. I currently prepare a patchset to remove the
> regmap cache entirely and use Thierry's new generic suspend/resume
> functions.

Feel free to cc me.
Best regards,
Alexander

[PATCH v2 6/8] drm/fsl-dcu: add TCON driver

[Stefan Agner]

On 2016-03-28 23:45, Alexander Stein wrote:
> Hi,
> 
> some comments below.
> 
> On Monday 28 March 2016 19:00:00, Stefan Agner wrote:
>> Add driver for the TCON (timing controller) module. The TCON module
>> is a separate module attached after the DCU (display controller
>> unit). Each DCU instance has its own, directly connected TCON
>> instance. The DCU's RGB and timing signals are passing through
>> the TCON module. TCON can provide timing signals for raw TFT panels
>> or operate in a bypass mode which leaves all signals unaltered.
>>
>> The driver currently only supports the bypass mode.
>>
>> Signed-off-by: Stefan Agner 
> 
>> --- a/Documentation/devicetree/bindings/display/fsl,dcu.txt
>> +++ b/Documentation/devicetree/bindings/display/fsl,dcu.txt
>> @@ -14,6 +14,7 @@ Required properties:
>>  Optional properties:
>>  - clocks:   Second handle for pixel clock.
>>  - clock-names:  Second name "pix" for pixel clock.
>> +- fsl,tcon: The phandle to the timing controller node.
> 
> Maybe a comment this is (currently) only for Vybrid, but not LS1021A.
> 

IMHO, such references to SoCs in a peripheral binding is somewhat
misplaced. If we would start doing this, we would end up in lots of SoC
references, and nobody knows whether they are actually accurate and up
to date... And I think we should add tcon to LS1021a, more on that
below...

>> --- /dev/null
>> +++ b/drivers/gpu/drm/fsl-dcu/fsl_tcon.c
>> [...]
>> +struct fsl_tcon *fsl_tcon_init(struct device *dev)
>> +{
>> +struct fsl_tcon *tcon;
>> +struct device_node *np;
>> +int ret;
>> +
>> +tcon = devm_kzalloc(dev, sizeof(*tcon), GFP_KERNEL);
>> +if (!tcon)
>> +return NULL;
>> +
>> +np = of_parse_phandle(dev->of_node, "fsl,tcon", 0);
>> +if (!np) {
>> +dev_warn(dev, "Couldn't find the tcon node\n");
>> +return NULL;
>> +}
> 
> Maybe check for device tree node before allocating struct fsl_tcon? Also this 
> should not be a warning, as on LS1021A this is to be expected.

Agreed, definitely the smarter sequence.

Afact LS1021a has also a TCON. At least in Jianwei Wangs initial patches
it was part of the driver, see:
https://lkml.org/lkml/2015/7/13/242

Not sure how that driver can work without TCON support on LS1021a, maybe
the bootloader sets the TCON to bypass?

Since I do not have a LS1021a, I hesitated to just add it to the LS1021s
dt's, but it should be fairly straight forward.

--
Stefan

[PATCH v2 6/8] drm/fsl-dcu: add TCON driver

[Alexander Stein]

On Tuesday 29 March 2016 00:11:13, Stefan Agner wrote:
> >> --- a/Documentation/devicetree/bindings/display/fsl,dcu.txt
> >> +++ b/Documentation/devicetree/bindings/display/fsl,dcu.txt
> >> 
> >> @@ -14,6 +14,7 @@ Required properties:
> >>  Optional properties:
> >>  - clocks: Second handle for pixel clock.
> >>  - clock-names:Second name "pix" for pixel clock.
> >> 
> >> +- fsl,tcon:   The phandle to the timing controller node.
> > 
> > Maybe a comment this is (currently) only for Vybrid, but not LS1021A.
> 
> IMHO, such references to SoCs in a peripheral binding is somewhat
> misplaced. If we would start doing this, we would end up in lots of SoC
> references, and nobody knows whether they are actually accurate and up
> to date... And I think we should add tcon to LS1021a, more on that
> below...

Well, I don't mind after all.

> >> --- /dev/null
> >> +++ b/drivers/gpu/drm/fsl-dcu/fsl_tcon.c
> >> [...]
> >> +struct fsl_tcon *fsl_tcon_init(struct device *dev)
> >> +{
> >> +  struct fsl_tcon *tcon;
> >> +  struct device_node *np;
> >> +  int ret;
> >> +
> >> +  tcon = devm_kzalloc(dev, sizeof(*tcon), GFP_KERNEL);
> >> +  if (!tcon)
> >> +  return NULL;
> >> +
> >> +  np = of_parse_phandle(dev->of_node, "fsl,tcon", 0);
> >> +  if (!np) {
> >> +  dev_warn(dev, "Couldn't find the tcon node\n");
> >> +  return NULL;
> >> +  }
> > 
> > Maybe check for device tree node before allocating struct fsl_tcon? Also
> > this should not be a warning, as on LS1021A this is to be expected.
> 
> Agreed, definitely the smarter sequence.
> 
> Afact LS1021a has also a TCON. At least in Jianwei Wangs initial patches
> it was part of the driver, see:
> https://lkml.org/lkml/2015/7/13/242
> 
> Not sure how that driver can work without TCON support on LS1021a, maybe
> the bootloader sets the TCON to bypass?
> 
> Since I do not have a LS1021a, I hesitated to just add it to the LS1021s
> dt's, but it should be fairly straight forward.

Interesting, but in Patch 3 
(https://lists.freedesktop.org/archives/dri-devel/2015-July/086381.html) no 
TCON node is added and using is still 
optional. Yet, I don't find any TCON hardware in the LS1021A reference manual, 
e.g. in the memory map. I hard guess is that it doesn't require/use one. 
Without memory address it would be pretty hard to add one.

Alexander

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

[Daniel Vetter]

On Fri, Mar 25, 2016 at 11:41:44AM +0100, Noralf Trønnes wrote:
> 
> Den 23.03.2016 18:28, skrev Daniel Vetter:
> >On Wed, Mar 23, 2016 at 06:07:56PM +0100, Noralf Trønnes wrote:
> >>Den 18.03.2016 18:47, skrev Daniel Vetter:
> >>>On Thu, Mar 17, 2016 at 10:51:55PM +0100, Noralf Trønnes wrote:
> 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:
> >>[...]
> >>>
> >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);
> >>>We already have a dirty_fb function in
> >>>dev->mode_config->funcs->dirty_fb(). This is the official interface native
> >>>drm/kms userspace is supposed to use to flush frontbuffer rendering. The
> >>>xfree86-video-modesetting driver uses it.
> >>I couldn't find this dirty_fb() function, but I assume you mean
> >>drm_framebuffer_funcs.dirty().
> >Yup.
> >
> };
> 
> struct drm_fb_helper {
>  spinlock_t dirty_lock;
>  struct drm_clip_rect *dirty_clip;
> };
> >>>Yeah, this part is needed for the delayed work for the fbdev helper.
> >>>struct work dirty_fb_work; is missing.
> >>This confuses me.
> >>If we have this then there's no need for a fb->funcs->dirty() call,
> >>the driver can just add a work function here instead.
> >>
> >>Possible fb dirty() call chain:
> >>Calls to drm_fb_helper_sys_* or mmap page writes will schedule
> >>fb_info->deferred_work. The worker func fb_deferred_io_work() calls
> >>fb_info->fbdefio->deferred_io().
> >>Then deferred_io() can call fb_helper->fb->funcs->dirty().
> >>
> >>In my use-case this dirty() function would schedule a delayed_work to run
> >>immediately since it has already been deferred collecting changes.
> >>The regular drm side framebuffer dirty() collects damage and schedules
> >>the same worker to run deferred.
> >>
> >>I don't see an easy way for a driver to set the dirty() function in
> >>drm_fb_cma_helper apart from doing this:
> >>
> >>  struct drm_fbdev_cma {
> >>  struct drm_fb_helperfb_helper;
> >>  struct drm_fb_cma   *fb;
> >>+int (*dirty)(struct drm_framebuffer *framebuffer,
> >>+ struct drm_file *file_priv, unsigned flags,
> >>+ unsigned color, struct drm_clip_rect *clips,
> >>+ unsigned num_clips);
> >>  };
> >Well my point is that drm core already has a canonical interface
> >(drm_framebuffer_funcs.dirty) to flush out rendering. And it's supposed to
> >be called from process context, and userspace is supposed to batch up
> >dirty updates.
> 
> Batched up into one ioctl call?
> If that's the case, then I don't have to use delayed_work like I do now.
> I can just queue a work_struct to run immediately.
> 
> This comment in include/uapi/drm/drm_mode.h made me think that I might
> receive multiple calls:
> 
>  * The kernel or hardware is free to update more then just the
>  * region specified by the clip rects. The kernel or hardware
>  * may also delay and/or coalesce several calls to dirty into a
>  * single update.

This just means that userspace must ensure that the entire buffer is still
valid, specifically that regions outside of the cliprects are not garabge.
This way drivers can increase the area that's uploaded (e.g. upload the
entire screen or only 1 rect spanning all cliprects in case that's the
only thing the hw can do).

Userspace otoh is supposed to batch up updates into one ioctl call (and
not one per drawn glyph or something silly like that).

> I have assumed that I can't run the whole display update from the ioctl
> call since one full display update on the "worst" display takes ~200ms.
> But maybe it's fine to run all this in the ioctl call?

Hm, thus far all drivers do their updating synchronously. But then none
yet took 200ms to do that - most have hw dma for the upload itself.

Short term I'd just do the update synchronously, async dirty with this
slow display has all kinds of fun problems I guess with X rendering
getting ahead and reducing interactivity even more. Long term there's talk
about adding cliprects to atomic, and then we c

[PATCHv14 03/18] dts: exynos4412-odroid*: enable the HDMI CEC device

[Hans Verkuil]

Hi Krzysztof,

On 03/29/2016 08:28 AM, Krzysztof Kozlowski wrote:
> On Fri, Mar 25, 2016 at 10:10 PM, Hans Verkuil  wrote:
>> From: Marek Szyprowski 
>>
>> Add a dts node entry and enable the HDMI CEC device present in the Exynos4
>> family of SoCs.
>>
>> Signed-off-by: Marek Szyprowski 
>> Signed-off-by: Hans Verkuil 
>> ---
>>  arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 4 
>>  1 file changed, 4 insertions(+)
> 
> Applied for v4.7 with a little bit different subject and the new node
> put in alphabetical order. Please don't include your original patch in
> your tree because any merging will probably end with having these
> nodes twice.

Thanks for merging these three via your tree. I've dropped these three patches
from my tree to avoid any merge issues.

Regards,

Hans

> 
> https://git.kernel.org/cgit/linux/kernel/git/krzk/linux.git/log/?h=next/dt
> (but tell me if you need to base on this so I would prepare a tag)
> 
> Best regards,
> Krzysztof
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

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

[Daniel Vetter]

On Sat, Mar 26, 2016 at 08:11:08PM +0100, Noralf Trønnes wrote:
> 
> Den 18.03.2016 18:48, skrev Daniel Vetter:
> >On Thu, Mar 17, 2016 at 11:00:00PM +0100, Noralf Trønnes wrote:
> >>Den 16.03.2016 19:26, skrev Eric Anholt:
> >>>Noralf Trønnes  writes:
> >>>
> This is an attempt at providing a DRM version of drivers/staging/fbtft.
> I'm sending this early before cleaning up the code hoping to get some
> feedback in case there are better ways to structure this.
> 
> The tinydrm module provides a very simplified view of DRM for displays 
> that
> has onboard video memory and is connected through a slow bus like SPI/I2C.
> A driver using tinydrm has to provide a function that will be called from
> the dirtyfb ioctl and optionally drm_panel functions which can be used to
> set up the display controller and control backlight.
> 
> tinydrm also has fbdev support using fb_deferred_io which is tied in 
> through
> the dirtyfb function call. A driver can use the provided deferred work 
> code
> to collect dirtyfb calls and schedule display memory updates if it 
> whishes.
> The various display controllers can have library modules that handles
> display updates.
> Display controllers that have a similar register interface as the MIPI 
> DBI/DCS
> controllers can use the lcdreg module for register access.
> 
> struct tinydrm_device {
>   struct drm_device *base;
>   u32 width, height;
>   struct drm_panel panel;
> [...]
>   int (*dirtyfb)(struct drm_framebuffer *fb, void *vmem, unsigned flags,
>  unsigned color, struct drm_clip_rect *clips,
>  unsigned num_clips);
> };
> >>>This is awesome!
> >>>
> >>>I was wondering, have you considered what it would take to DMA
> >>>framebuffer contents from somewhere in memory to these displays?  Does
> >>>that look doable to you?
> >>The vast majory of these displays are connected through SPI and the SPI
> >>subsystem maps the buffers using the DMA streaming API including support
> >>for vmalloc buffers. I have some more details in my reply to Daniel.
> >>
> >>>I'd love to be able to do something PRIME-like where vc4's doing the
> >>>rendering and we're periodically updating the TFT with the result.
> >>I think I read somewhere that one drm device could do the rendering and
> >>another could scan out the buffer. It would be great if this could be done.
> >>Some use these displays on handhold game emulators and the emulator only
> >>supports OpenGL or some library needing hw rendering. Currently on the
> >>Raspberry Pi this is solved by having a program take snapshots of the gpu
> >>framebuffer and copy this into the fbtft fbdev framebuffer.
> >Yeah, this is definitely perfect use-case for prime buffer sharing.
> >CMA/dma buffer support for tinydrm would be great to make this work
> >seamlessly.
> 
> I have looked at cma prime and it looks like vaddr is not set.
> How do I get the virtual address?
> 
> drm_prime_fd_to_handle_ioctl
>   -> drm_gem_prime_fd_to_handle
>  -> drm_gem_prime_import
> -> drm_gem_cma_prime_import_sg_table:
> 
> cma_obj = __drm_gem_cma_create(dev, attach->dmabuf->size);
> cma_obj->paddr = sg_dma_address(sgt->sgl);
> cma_obj->sgt = sgt;

sg table is supposed to be for device dma, for kernel access either use
vmap or the kmap functions dma-buf provides. Since no one yet bothered
with kmap I'd just go with vmap ;-)

The reason for this split is that the dma-buf might wrap something that's
totally not normal memory (not struct page backed at least) and hence
kernel mmmaps need special attention.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH v2 6/8] drm/fsl-dcu: add TCON driver

[Stefan Agner]

On 2016-03-29 00:26, Alexander Stein wrote:
> On Tuesday 29 March 2016 00:11:13, Stefan Agner wrote:
>> >> --- a/Documentation/devicetree/bindings/display/fsl,dcu.txt
>> >> +++ b/Documentation/devicetree/bindings/display/fsl,dcu.txt
>> >>
>> >> @@ -14,6 +14,7 @@ Required properties:
>> >>  Optional properties:
>> >>  - clocks:Second handle for pixel clock.
>> >>  - clock-names:   Second name "pix" for pixel clock.
>> >>
>> >> +- fsl,tcon:  The phandle to the timing controller node.
>> >
>> > Maybe a comment this is (currently) only for Vybrid, but not LS1021A.
>>
>> IMHO, such references to SoCs in a peripheral binding is somewhat
>> misplaced. If we would start doing this, we would end up in lots of SoC
>> references, and nobody knows whether they are actually accurate and up
>> to date... And I think we should add tcon to LS1021a, more on that
>> below...
> 
> Well, I don't mind after all.
> 
>> >> --- /dev/null
>> >> +++ b/drivers/gpu/drm/fsl-dcu/fsl_tcon.c
>> >> [...]
>> >> +struct fsl_tcon *fsl_tcon_init(struct device *dev)
>> >> +{
>> >> + struct fsl_tcon *tcon;
>> >> + struct device_node *np;
>> >> + int ret;
>> >> +
>> >> + tcon = devm_kzalloc(dev, sizeof(*tcon), GFP_KERNEL);
>> >> + if (!tcon)
>> >> + return NULL;
>> >> +
>> >> + np = of_parse_phandle(dev->of_node, "fsl,tcon", 0);
>> >> + if (!np) {
>> >> + dev_warn(dev, "Couldn't find the tcon node\n");
>> >> + return NULL;
>> >> + }
>> >
>> > Maybe check for device tree node before allocating struct fsl_tcon? Also
>> > this should not be a warning, as on LS1021A this is to be expected.
>>
>> Agreed, definitely the smarter sequence.
>>
>> Afact LS1021a has also a TCON. At least in Jianwei Wangs initial patches
>> it was part of the driver, see:
>> https://lkml.org/lkml/2015/7/13/242
>>
>> Not sure how that driver can work without TCON support on LS1021a, maybe
>> the bootloader sets the TCON to bypass?
>>
>> Since I do not have a LS1021a, I hesitated to just add it to the LS1021s
>> dt's, but it should be fairly straight forward.
> 
> Interesting, but in Patch 3
> (https://lists.freedesktop.org/archives/dri-devel/2015-July/086381.html)
> no TCON node is added and using is still
> optional. Yet, I don't find any TCON hardware in the LS1021A reference 
> manual, 
> e.g. in the memory map. I hard guess is that it doesn't require/use one. 
> Without memory address it would be pretty hard to add one.

Ok, maybe I am completely wrong on that. I thought I have seen it...

It could be that Jianwei added TCON support for Vybrid only, in this
case I agree there shouldn't be a warning if TCON is missing. Maybe even
the other way around, write a info message in case TCON has been found.

--
Stefan

i915 4.5 bugfix backport and release management issue?

[Daniel Vetter]

On Tue, Mar 29, 2016 at 4:39 AM, Andy Lutomirski  wrote:
> AFAICT something got rather screwed up in i915 land for 4.5.
>
> $ git log --oneline --grep='Pretend cursor is always on' v4.5
> drivers/gpu/drm/i915/
> e2e407dc093f drm/i915: Pretend cursor is always on for ILK-style WM
> calculations (v2)
>
> $ git log --oneline --grep='Pretend cursor is always on' v4.6-rc1
> drivers/gpu/drm/i915/
> e2e407dc093f drm/i915: Pretend cursor is always on for ILK-style WM
> calculations (v2)
> b2435692dbb7 drm/i915: Pretend cursor is always on for ILK-style WM
> calculations (v2)
>
> The two patches there are almost, but not quite, the same thing, which
> makes me wonder how they both ended up in Linus' tree without an
> obvious merge conflict.
>
> I have no idea what caused this.  However, I think (on very little
> inspection, but it's consistent with problems I have with 4.5 on my
> laptop) that the first one is an *incorrect* fix for a regression in
> 4.5 and the second is a correct fix for the same regression.  4.6-rc1
> seems okay.
>
> I reported the regression and everyone involved has known about it for
> weeks.  Nonetheless, 4.5 final is busted.

Quoting from e2e407dc093f

"(cherry picked from commit b2435692dbb709d4c8ff3b2f2815c9b8423b72bb)"

i.e. this is intentionally twice in the history. We started to soak
bugfixes in -next and then cherry pick them because we had too much
fun with things blowing up, and also too much fun with really messy
conflicts. It's not a botched patch in 4.5 or anything else nefarious
at all.

Which just means that there's another bugfix in 4.6-rc1 that needs to
be backported to 4.5 but hasn't arrived in there yet. Two possible
cases:
- Greg is too slow with cc: stable patches - especially around
releases we occasionally put the patch into the wrong branch at first,
or it simply misses the last pull. 4.6 closes for drm drivers already
at 4.5-rc5, so there's a sizeable overlap where placing patches
correctly requires some juggling.

- We've genuinely failed to cherry-pick a bugfix over. It happens,
despite our best efforts (which of course includes running stuff on
Linus' tree). Please do a reverse bisect so we know which precise
commit fell through the cracks.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

i915 4.5 bugfix backport and release management issue?

[Andy Lutomirski]

On Tue, Mar 29, 2016 at 12:43 AM, Daniel Vetter  
wrote:
> On Tue, Mar 29, 2016 at 4:39 AM, Andy Lutomirski  
> wrote:
>> AFAICT something got rather screwed up in i915 land for 4.5.
>>
>> $ git log --oneline --grep='Pretend cursor is always on' v4.5
>> drivers/gpu/drm/i915/
>> e2e407dc093f drm/i915: Pretend cursor is always on for ILK-style WM
>> calculations (v2)
>>
>> $ git log --oneline --grep='Pretend cursor is always on' v4.6-rc1
>> drivers/gpu/drm/i915/
>> e2e407dc093f drm/i915: Pretend cursor is always on for ILK-style WM
>> calculations (v2)
>> b2435692dbb7 drm/i915: Pretend cursor is always on for ILK-style WM
>> calculations (v2)
>>
>> The two patches there are almost, but not quite, the same thing, which
>> makes me wonder how they both ended up in Linus' tree without an
>> obvious merge conflict.
>>
>> I have no idea what caused this.  However, I think (on very little
>> inspection, but it's consistent with problems I have with 4.5 on my
>> laptop) that the first one is an *incorrect* fix for a regression in
>> 4.5 and the second is a correct fix for the same regression.  4.6-rc1
>> seems okay.
>>
>> I reported the regression and everyone involved has known about it for
>> weeks.  Nonetheless, 4.5 final is busted.
>
> Quoting from e2e407dc093f
>
> "(cherry picked from commit b2435692dbb709d4c8ff3b2f2815c9b8423b72bb)"
>
> i.e. this is intentionally twice in the history. We started to soak
> bugfixes in -next and then cherry pick them because we had too much
> fun with things blowing up, and also too much fun with really messy
> conflicts. It's not a botched patch in 4.5 or anything else nefarious
> at all.

Bah, sorry, I read it wrong.  They have the same final state but they
were on different bases.  I somehow reversed this in my head and
thought they had the same initial state and different final states.

>
> - We've genuinely failed to cherry-pick a bugfix over. It happens,
> despite our best efforts (which of course includes running stuff on
> Linus' tree). Please do a reverse bisect so we know which precise
> commit fell through the cracks.

If I find some time, I'll try.  I've already failed miserably at
bisecting this thing once.

--Andy

[PATCH 1/3 v2] drm/i2c/adv7511: Add audio support

[Archit Taneja]

Hi,

On 03/28/2016 08:06 PM, Jose Abreu wrote:
> This patch adds audio support for the ADV7511 HDMI transmitter
> using ALSA SoC.
>
> The code was ported from Analog Devices linux tree from
> commit 1770c4a1e32b ("Merge remote-tracking branch
> 'xilinx/master' into xcomm_zynq"), which is available at:
>   - https://github.com/analogdevicesinc/linux/
>
> The main core file was renamed from adv7511.c to adv7511_core.c
> so that audio and video compile into a single adv7511.ko module
> and to keep up with Analog Devices kernel tree.
>
> The audio can be disabled using menu-config so it is possible
> to use only video mode.
>
> The HDMI mode is automatically started at boot and the audio
> (when enabled) registers as a codec into ALSA.

Is there a reason why we set the mode to HDMI at probe itself?
Shouldn't it be okay to set the mode later once we read the
EDID off the panel?

Some more comments below.

>
> SPDIF DAI format was also added to ASoC as it is required
> by adv7511 audio.
>
> Signed-off-by: Jose Abreu 
> ---
>
> No changes v1 -> v2.
>
>   drivers/gpu/drm/i2c/Kconfig |   11 +
>   drivers/gpu/drm/i2c/Makefile|2 +
>   drivers/gpu/drm/i2c/adv7511.c   | 1024 
> ---
>   drivers/gpu/drm/i2c/adv7511.h   |   41 ++
>   drivers/gpu/drm/i2c/adv7511_audio.c |  310 +++
>   drivers/gpu/drm/i2c/adv7511_core.c  | 1005 
> ++
>   include/sound/soc-dai.h |1 +
>   7 files changed, 1370 insertions(+), 1024 deletions(-)
>   delete mode 100644 drivers/gpu/drm/i2c/adv7511.c
>   create mode 100644 drivers/gpu/drm/i2c/adv7511_audio.c
>   create mode 100644 drivers/gpu/drm/i2c/adv7511_core.c



> +
> +static int adv7511_probe(struct i2c_client *i2c, const struct i2c_device_id 
> *id)
> +{
> + struct adv7511_link_config link_config;
> + struct adv7511 *adv7511;
> + struct device *dev = &i2c->dev;
> + unsigned int val;
> + int ret;
> +
> + if (!dev->of_node)
> + return -EINVAL;
> +
> + adv7511 = devm_kzalloc(dev, sizeof(*adv7511), GFP_KERNEL);
> + if (!adv7511)
> + return -ENOMEM;
> +
> + adv7511->powered = false;
> + adv7511->status = connector_status_disconnected;
> +
> + ret = adv7511_parse_dt(dev->of_node, &link_config);
> + if (ret)
> + return ret;
> +
> + /*
> +  * The power down GPIO is optional. If present, toggle it from active to
> +  * inactive to wake up the encoder.
> +  */
> + adv7511->gpio_pd = devm_gpiod_get_optional(dev, "pd", GPIOD_OUT_HIGH);
> + if (IS_ERR(adv7511->gpio_pd))
> + return PTR_ERR(adv7511->gpio_pd);
> +
> + if (adv7511->gpio_pd) {
> + mdelay(5);
> + gpiod_set_value_cansleep(adv7511->gpio_pd, 0);
> + }
> +
> + adv7511->regmap = devm_regmap_init_i2c(i2c, &adv7511_regmap_config);
> + if (IS_ERR(adv7511->regmap))
> + return PTR_ERR(adv7511->regmap);
> +
> + ret = regmap_read(adv7511->regmap, ADV7511_REG_CHIP_REVISION, &val);
> + if (ret)
> + return ret;
> + dev_dbg(dev, "Rev. %d\n", val);
> +
> + ret = regmap_register_patch(adv7511->regmap, adv7511_fixed_registers,
> + ARRAY_SIZE(adv7511_fixed_registers));
> + if (ret)
> + return ret;
> +
> + regmap_write(adv7511->regmap, ADV7511_REG_EDID_I2C_ADDR, edid_i2c_addr);
> + regmap_write(adv7511->regmap, ADV7511_REG_PACKET_I2C_ADDR,
> +  packet_i2c_addr);
> + regmap_write(adv7511->regmap, ADV7511_REG_CEC_I2C_ADDR, cec_i2c_addr);
> + adv7511_packet_disable(adv7511, 0x);
> +
> + adv7511->i2c_main = i2c;
> + adv7511->i2c_edid = i2c_new_dummy(i2c->adapter, edid_i2c_addr >> 1);
> + if (!adv7511->i2c_edid)
> + return -ENOMEM;
> +
> + if (i2c->irq) {
> + init_waitqueue_head(&adv7511->wq);
> +
> + ret = devm_request_threaded_irq(dev, i2c->irq, NULL,
> + adv7511_irq_handler,
> + IRQF_ONESHOT, dev_name(dev),
> + adv7511);
> + if (ret)
> + goto err_i2c_unregister_device;
> + }
> +
> + /* CEC is unused for now */
> + regmap_write(adv7511->regmap, ADV7511_REG_CEC_CTRL,
> +  ADV7511_CEC_CTRL_POWER_DOWN);
> +
> + adv7511_power_off(adv7511);
> +
> + i2c_set_clientdata(i2c, adv7511);
> +
> +#ifdef CONFIG_DRM_I2C_ADV7511_AUDIO
> + adv7511_audio_init(&i2c->dev);
> +#endif

If we intend to have more audio funcs being used by the core in the
future, it would be nice to have NOP audio funcs rather than having
multiple #ifdef checks in the driver when CONFIG_DRM_I2C_ADV7511_AUDIO
isn't set.

> +
> + adv7511_set_link_config(adv7511, &link_config);
> +
> + /* Enable HDMI mode */
> + regmap_update_bits(adv7511->regmap, ADV

[PATCH 3/5] drm: Add an encoder and connector type enum for DPI.

[Daniel Vetter]

On Thu, Mar 24, 2016 at 05:23:49PM -0700, Eric Anholt wrote:
> Right now exynos is exposing DPI as a TMDS encoder and VGA connector,
> which seems rather misleading.  This isn't just an internal detail,
> since xrandr actually exposes "VGA" as the output name.  Define some
> new enums so that vc4's DPI can have a more informative name.
> 
> I considered other names for the connector as well.  For VC4, the
> Adafruit DPI kippah takes the 28 GPIO pins and routes them to a
> standard-ish 40-pin FPC connector, but "40-pin FPC" doesn't uniquely
> identify an ordering of pins (apparently some other orderings exist),
> doesn't explain things as well for the user (who, if anything, knows
> their product is a DPI kippah/panel combo), and actually doesn't have
> to exist (one could connect the 28 GPIOs directly to something else).
> Simply "DPI" seems like a good compromise name to distinguish from the
> HDMI, DSI, and TV connectors .
> 
> Signed-off-by: Eric Anholt 

Follow-up patch to fix up existing drivers? Either way

Reviewed-by: Daniel Vetter  + ack for merging
through a vc4 pull request (Dave has recently okayed that I can do such
acks for non-i915 trees).

Cheers, Daniel

> ---
>  drivers/gpu/drm/drm_crtc.c  | 2 ++
>  include/uapi/drm/drm_mode.h | 2 ++
>  2 files changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index f619121..64bd954 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -168,6 +168,7 @@ static struct drm_conn_prop_enum_list 
> drm_connector_enum_list[] = {
>   { DRM_MODE_CONNECTOR_eDP, "eDP" },
>   { DRM_MODE_CONNECTOR_VIRTUAL, "Virtual" },
>   { DRM_MODE_CONNECTOR_DSI, "DSI" },
> + { DRM_MODE_CONNECTOR_DPI, "DPI" },
>  };
>  
>  static const struct drm_prop_enum_list drm_encoder_enum_list[] = {
> @@ -179,6 +180,7 @@ static const struct drm_prop_enum_list 
> drm_encoder_enum_list[] = {
>   { DRM_MODE_ENCODER_VIRTUAL, "Virtual" },
>   { DRM_MODE_ENCODER_DSI, "DSI" },
>   { DRM_MODE_ENCODER_DPMST, "DP MST" },
> + { DRM_MODE_ENCODER_DPI, "DPI" },
>  };
>  
>  static const struct drm_prop_enum_list drm_subpixel_enum_list[] = {
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 50adb46..1eb85f7 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -202,6 +202,7 @@ struct drm_mode_get_plane_res {
>  #define DRM_MODE_ENCODER_VIRTUAL 5
>  #define DRM_MODE_ENCODER_DSI 6
>  #define DRM_MODE_ENCODER_DPMST   7
> +#define DRM_MODE_ENCODER_DPI 8
>  
>  struct drm_mode_get_encoder {
>   __u32 encoder_id;
> @@ -241,6 +242,7 @@ struct drm_mode_get_encoder {
>  #define DRM_MODE_CONNECTOR_eDP   14
>  #define DRM_MODE_CONNECTOR_VIRTUAL  15
>  #define DRM_MODE_CONNECTOR_DSI   16
> +#define DRM_MODE_CONNECTOR_DPI   17
>  
>  struct drm_mode_get_connector {
>  
> -- 
> 2.7.0
> 
> ___
> 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 2/4 v3] drm: Introduce drm_connector_register_all() helper

[Daniel Vetter]

On Wed, Mar 23, 2016 at 01:41:05PM +, Alexey Brodkin wrote:
> Hi David,
> 
> On Wed, 2016-03-23 at 12:13 +0100, David Herrmann wrote:
> > Hi
> > 
> > On Wed, Mar 23, 2016 at 9:42 AM, Alexey Brodkin
> >  wrote:
> > > 
> > > As a pair to already existing drm_connector_unregister_all() we're adding
> > > generic implementation of what is already done in some drivers.
> > > 
> > > Once this helper is implemented we'll be ready to switch existing
> > > driver-specific implementations with the generic one.
> > > 
> > > Signed-off-by: Alexey Brodkin 
> > > Cc: Daniel Vetter 
> > > Cc: David Airlie 
> > > ---
> > > 
> > > Changes v2 -> v3:
> > >  * Updated title with capital after colon
> > >  * Simplified failure path with direct and unconditional invocation of
> > >    unregister_all()
> > >  * Updated kerneldoc description of the drm_connector_register_all()
> > > 
> > > Changes v1 -> v2:
> > >  * Rename drm_connector_unplug_all() to drm_connector_unregister_all()
> > >  * Use drm_for_each_connector() instead of list_for_each_entry()
> > >  * Updated kerneldoc for drm_dev_register()
> > > 
> > >  drivers/gpu/drm/drm_crtc.c | 43 
> > > +++
> > >  drivers/gpu/drm/drm_drv.c  |  6 +-
> > >  include/drm/drm_crtc.h     |  3 ++-
> > >  3 files changed, 50 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > > index 65488a6..21eea11 100644
> > > --- a/drivers/gpu/drm/drm_crtc.c
> > > +++ b/drivers/gpu/drm/drm_crtc.c
> > > @@ -1081,6 +1081,49 @@ void drm_connector_unregister(struct drm_connector 
> > > *connector)
> > >  EXPORT_SYMBOL(drm_connector_unregister);
> > > 
> > >  /**
> > > + * drm_connector_register_all - register all connectors
> > > + * @dev: drm device
> > > + *
> > > + * This function registers all connectors in sysfs and other places so 
> > > that
> > > + * userspace can start to access them. Drivers can call it after calling
> > > + * drm_dev_register() to complete the device registration, if they don't 
> > > call
> > > + * drm_connector_register() on each connector individually.
> > > + *
> > > + * When a device is unplugged and should be removed from userspace 
> > > access,
> > > + * call drm_connector_unregister_all(), which is the inverse of this
> > > + * function.
> > > + *
> > > + * Returns:
> > > + * Zero on success, error code on failure.
> > > + */
> > > +int drm_connector_register_all(struct drm_device *dev)
> > > +{
> > > +       struct drm_connector *connector;
> > > +       int ret;
> > > +
> > > +       mutex_lock(&dev->mode_config.mutex);
> > > +
> > > +       drm_for_each_connector(connector, dev) {
> > > +               ret = drm_connector_register(connector);
> > > +               if (ret) {
> > > +                       /*
> > > +                        * We may safely call 
> > > unregister_all() here within
> > > +                        * area locked with mutex 
> > > because unregister_all()
> > > +                        * doesn't use locks 
> > > inside (see a comment in that
> > > +                        * function).
> > > +                        */
> > Ugh? unregister_all() says:
> > 
> > /* FIXME: taking the mode config mutex ends up in a clash with sysfs */
> > 
> > This strongly contradicts your comment. Anyway, regardless how you
> > want to fix it: You better unlock the mode-config mutex before
> > returning below.
> 
> So good catch.
> But what I really meant since we didn't get any further after registering
> all "good" connections (see we're not releasing mutex still) the will be
> no clashes with sysfs.
> 
> Still I;d like Daniel to comment on that separately.

I think doing the unregister_all outside of the loop&locked section is
better for future-proofing. My long-term plan for connector lifetimes and
the connector list is:
- refcounting for connectors (Dave has wip patches already).
- separate lock for the connector list (and only that).

Doing it entirely separate would make things easier and more robust.

I merged patch 1 meanwhile to drm-misc.

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

[PATCH v4 RESEND 1/5] drm/dp_helper: Increase retry interval to 1000us

[Daniel Vetter]

On Mon, Mar 28, 2016 at 10:33:22AM -0400, Lyude wrote:
> This is part of a patch series to migrate all of the workarounds for
> commonly seen behavior from bad sinks in intel_dp_dpcd_read_wake() to
> drm's DP helper.
> 
> 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 7d58f59..d1128fb 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -160,7 +160,7 @@ int drm_dp_bw_code_to_link_rate(u8 link_bw)
>  }
>  EXPORT_SYMBOL(drm_dp_bw_code_to_link_rate);
>  
> -#define AUX_RETRY_INTERVAL 500 /* us */
> +#define AUX_RETRY_INTERVAL 1000 /* us */

Was this to adapt to the msleep(1) in the i915 function? If so it's kinda
wrong anyway, since an msleep(1) actually sleeps 1 jiffy, and on most
systems that's a lot more than 1 ms. If it all still works, I'd just drop
this patch here. I suspect that the magic is all in the more aggressive
retrying and the throwaway read, not in how long we actually wait.

On patches 2-5: Reviewed-by: Daniel Vetter 

>  
>  /**
>   * DOC: dp helpers
> -- 
> 2.5.5
> 
> ___
> 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 v8 1/6] ALSA: pcm: add IEC958 channel status helper for hw_params

[Takashi Iwai]

On Thu, 17 Mar 2016 13:22:29 +0100,
Jyri Sarha wrote:
> 
> 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 

This patch looks almost good to me, but...

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

... this change is silently slipped in.  It should be mentioned in the
changelog, or split to another patch, as this is basically an
orthogonal change.


thanks,

Takashi

[PATCH 2/4 v3] drm: Introduce drm_connector_register_all() helper

[Alexey Brodkin]

Hi Daniel,

On Tue, 2016-03-29 at 10:19 +0200, Daniel Vetter wrote:
> On Wed, Mar 23, 2016 at 01:41:05PM +, Alexey Brodkin wrote:
> > 
> > Hi David,
> > 
> > On Wed, 2016-03-23 at 12:13 +0100, David Herrmann wrote:
> > > 
> > > Hi
> > > 
> > > On Wed, Mar 23, 2016 at 9:42 AM, Alexey Brodkin
> > >  wrote:
> > > > 
> > > > 
> > > > As a pair to already existing drm_connector_unregister_all() we're 
> > > > adding
> > > > generic implementation of what is already done in some drivers.
> > > > 
> > > > Once this helper is implemented we'll be ready to switch existing
> > > > driver-specific implementations with the generic one.
> > > > 
> > > > Signed-off-by: Alexey Brodkin 
> > > > Cc: Daniel Vetter 
> > > > Cc: David Airlie 
> > > > ---
> > > > 
> > > > Changes v2 -> v3:
> > > >  * Updated title with capital after colon
> > > >  * Simplified failure path with direct and unconditional invocation of
> > > >    unregister_all()
> > > >  * Updated kerneldoc description of the drm_connector_register_all()
> > > > 
> > > > Changes v1 -> v2:
> > > >  * Rename drm_connector_unplug_all() to drm_connector_unregister_all()
> > > >  * Use drm_for_each_connector() instead of list_for_each_entry()
> > > >  * Updated kerneldoc for drm_dev_register()
> > > > 
> > > >  drivers/gpu/drm/drm_crtc.c | 43 
> > > > +++
> > > >  drivers/gpu/drm/drm_drv.c  |  6 +-
> > > >  include/drm/drm_crtc.h     |  3 ++-
> > > >  3 files changed, 50 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > > > index 65488a6..21eea11 100644
> > > > --- a/drivers/gpu/drm/drm_crtc.c
> > > > +++ b/drivers/gpu/drm/drm_crtc.c
> > > > @@ -1081,6 +1081,49 @@ void drm_connector_unregister(struct 
> > > > drm_connector *connector)
> > > >  EXPORT_SYMBOL(drm_connector_unregister);
> > > > 
> > > >  /**
> > > > + * drm_connector_register_all - register all connectors
> > > > + * @dev: drm device
> > > > + *
> > > > + * This function registers all connectors in sysfs and other places so 
> > > > that
> > > > + * userspace can start to access them. Drivers can call it after 
> > > > calling
> > > > + * drm_dev_register() to complete the device registration, if they 
> > > > don't call
> > > > + * drm_connector_register() on each connector individually.
> > > > + *
> > > > + * When a device is unplugged and should be removed from userspace 
> > > > access,
> > > > + * call drm_connector_unregister_all(), which is the inverse of this
> > > > + * function.
> > > > + *
> > > > + * Returns:
> > > > + * Zero on success, error code on failure.
> > > > + */
> > > > +int drm_connector_register_all(struct drm_device *dev)
> > > > +{
> > > > +       struct drm_connector *connector;
> > > > +       int ret;
> > > > +
> > > > +       mutex_lock(&dev->mode_config.mutex);
> > > > +
> > > > +       drm_for_each_connector(connector, dev) {
> > > > +               ret = drm_connector_register(connector);
> > > > +               if (ret) {
> > > > +                       /*
> > > > +                        * We may safely call 
> > > > unregister_all() here within
> > > > +                        * area locked with 
> > > > mutex because unregister_all()
> > > > +                        * doesn't use locks 
> > > > inside (see a comment in that
> > > > +                        * function).
> > > > +                        */
> > > Ugh? unregister_all() says:
> > > 
> > > /* FIXME: taking the mode config mutex ends up in a clash with sysfs */
> > > 
> > > This strongly contradicts your comment. Anyway, regardless how you
> > > want to fix it: You better unlock the mode-config mutex before
> > > returning below.
> > So good catch.
> > But what I really meant since we didn't get any further after registering
> > all "good" connections (see we're not releasing mutex still) the will be
> > no clashes with sysfs.
> > 
> > Still I;d like Daniel to comment on that separately.
> I think doing the unregister_all outside of the loop&locked section is
> better for future-proofing. My long-term plan for connector lifetimes and
> the connector list is:
> - refcounting for connectors (Dave has wip patches already).
> - separate lock for the connector list (and only that).
> 
> Doing it entirely separate would make things easier and more robust.

Ok makes sense.

> I merged patch 1 meanwhile to drm-misc.

So may I re-send only patches 2-4 then (using "drm-misc" as a base)?

-Alexey

[PATCH] dma-buf: Update docs for SYNC ioctl

[David Herrmann]

Hi

On Mon, Mar 28, 2016 at 9:42 PM, Tiago Vignatti
 wrote:
> Do we have an agreement here after all? David? I need to know whether this
> fixup is okay to go cause I'll need to submit to Chrome OS then.

Sure it is fine. The code is already there, we cannot change it.

Thanks
David

[linux-sunxi] [PATCH v3 08/19] ARM: sun5i: Add DRAM gates

[Maxime Ripard]

On Thu, Mar 24, 2016 at 12:31:13PM +0800, Chen-Yu Tsai wrote:
> On Thu, Mar 24, 2016 at 12:38 AM, Maxime Ripard
>  wrote:
> > The DRAM gates control whether the image / display devices on the SoC have
> > access to the DRAM clock or not.
> >
> > Enable it.
> >
> > Signed-off-by: Maxime Ripard 
> 
> Acked-by: Chen-Yu Tsai 
> 
> I assume you'll add another version for A10s, or move the whole thing
> to sun5i.dtsi later?

Indeed.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160329/af9a1542/attachment.sig>

[PATCH 1/3 v4] drm: Introduce drm_connector_register_all() helper

[David Herrmann]

Hi

On Tue, Mar 29, 2016 at 12:02 PM, Alexey Brodkin
 wrote:
> As a pair to already existing drm_connector_unregister_all() we're adding
> generic implementation of what is already done in some drivers.
>
> Once this helper is implemented we'll be ready to switch existing
> driver-specific implementations with the generic one.
>
> Signed-off-by: Alexey Brodkin 
> Cc: Daniel Vetter 
> Cc: David Airlie 
> Cc: David Herrmann 
> ---
>
> Changes v3 -> v4:
>  * In drm_connector_register_all() fail path which calls unregister_all()
>is moved outside of loop&locked section (as suggested by Daniel)
>
> Changes v2 -> v3:
>  * Updated title with capital after colon
>  * Simplified failure path with direct and unconditional invocation of
>unregister_all()
>  * Updated kerneldoc description of the drm_connector_register_all()
>
> Changes v1 -> v2:
>  * Rename drm_connector_unplug_all() to drm_connector_unregister_all()
>  * Use drm_for_each_connector() instead of list_for_each_entry()
>  * Updated kerneldoc for drm_dev_register()
>
>  drivers/gpu/drm/drm_crtc.c | 39 +++
>  drivers/gpu/drm/drm_drv.c  |  6 +-
>  include/drm/drm_crtc.h |  3 ++-
>  3 files changed, 46 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 7675826..3e4cdb1 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1079,6 +1079,45 @@ void drm_connector_unregister(struct drm_connector 
> *connector)
>  EXPORT_SYMBOL(drm_connector_unregister);
>
>  /**
> + * drm_connector_register_all - register all connectors
> + * @dev: drm device
> + *
> + * This function registers all connectors in sysfs and other places so that
> + * userspace can start to access them. Drivers can call it after calling
> + * drm_dev_register() to complete the device registration, if they don't call
> + * drm_connector_register() on each connector individually.
> + *
> + * When a device is unplugged and should be removed from userspace access,
> + * call drm_connector_unregister_all(), which is the inverse of this
> + * function.
> + *
> + * Returns:
> + * Zero on success, error code on failure.
> + */
> +int drm_connector_register_all(struct drm_device *dev)
> +{
> +   struct drm_connector *connector;
> +   int ret;
> +
> +   mutex_lock(&dev->mode_config.mutex);
> +
> +   drm_for_each_connector(connector, dev) {
> +   ret = drm_connector_register(connector);
> +   if (ret)
> +   goto err;
> +   }
> +
> +   mutex_unlock(&dev->mode_config.mutex);
> +
> +   return 0;
> +
> +err:
> +   drm_connector_unregister_all(dev);

You _must_ unlock the mutex before returning.

Thanks
David

> +   return ret;
> +}
> +EXPORT_SYMBOL(drm_connector_register_all);
> +
> +/**
>   * drm_connector_unregister_all - unregister connector userspace interfaces
>   * @dev: drm device
>   *
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 167c8d3..2c9a2b6 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -715,7 +715,11 @@ EXPORT_SYMBOL(drm_dev_unref);
>   *
>   * Register the DRM device @dev with the system, advertise device to 
> user-space
>   * and start normal device operation. @dev must be allocated via 
> drm_dev_alloc()
> - * previously.
> + * previously. Right after drm_dev_register() the driver should call
> + * drm_connector_register_all() to register all connectors in sysfs. This is
> + * a separate call for backward compatibility with drivers still using
> + * the deprecated ->load() callback, where connectors are registered from 
> within
> + * the ->load() callback.
>   *
>   * Never call this twice on any device!
>   *
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 12f2bd4..6231f6c 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -2253,7 +2253,8 @@ void drm_connector_unregister(struct drm_connector 
> *connector);
>
>  extern void drm_connector_cleanup(struct drm_connector *connector);
>  extern unsigned int drm_connector_index(struct drm_connector *connector);
> -/* helper to unregister all connectors from sysfs for device */
> +/* helpers to {un}register all connectors from sysfs for device */
> +extern int drm_connector_register_all(struct drm_device *dev);
>  extern void drm_connector_unregister_all(struct drm_device *dev);
>
>  extern int drm_bridge_add(struct drm_bridge *bridge);
> --
> 2.5.0
>

[Powerpc] Sam460ex Canyonlands issue -Kernel 4.4.6-rc1

[Julian Margetson]

On 3/28/2016 11:15 PM, Michel Dänzer wrote:
> On 29.03.2016 08:47, Julian Margetson wrote:
>> Seeing the following when booting kernel 4.6-rc1 on Acube Sam460ex 
>> Canyonlands board.
>> This loops for a few times then the kernel boots.
>> No problem with the 4.6-rc1 with an A-eon Tabor Freescale e500v2 board.
>>
>> Regards
>>
>> Julian
>>
>>
>>   [2.197839] [ cut here ]
>>   [2.197850] WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/drm_irq.c:1368 
>> drm_vblank_off+0x2c/0x1e0
> That's
>
>   if (WARN_ON(pipe >= dev->num_crtcs))
>
> My best guess is that drm_vblank_off is called before drm_vblank_init,
> so dev->num_crtcs is still 0.
>
>
> Please provide the full dmesg output corresponding to the problem.
>
>
Attached

-- next part --
[0.00] Using Canyonlands machine description
[0.00] Linux version 4.6.0-rc1-sam460ex-jm (root at julian-VirtualBox) 
(gcc version 5.3.1 20160205 (Ubuntu 5.3.1-8ubuntu2) ) #23 PREEMPT Mon Mar 28 
18:52:14 AST 2016
[0.00] Zone ranges:
[0.00]   DMA  [mem 0x-0x2fff]
[0.00]   Normal   empty
[0.00]   HighMem  [mem 0x3000-0x7fff]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x-0x7fff]
[0.00] Initmem setup node 0 [mem 0x-0x7fff]
[0.00] MMU: Allocated 1088 bytes of context maps for 255 contexts
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 522752
[0.00] Kernel command line: root=/dev/sda8 console=ttyS0,115200 
console=tty0
[0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
[0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[0.00] Sorting __ex_table...
[0.00] allocated 2097152 bytes of page_ext
[0.00] Memory: 1997104K/2097152K available (8428K kernel code, 344K 
rwdata, 4220K rodata, 256K init, 1410K bss, 100048K reserved, 0K cma-reserved, 
1310720K highmem)
[0.00] Kernel virtual memory layout:
[0.00]   * 0xfffcf000..0xf000  : fixmap
[0.00]   * 0xffc0..0xffe0  : highmem PTEs
[0.00]   * 0xffa0..0xffc0  : consistent mem
[0.00]   * 0xffa0..0xffa0  : early ioremap
[0.00]   * 0xf100..0xffa0  : vmalloc & ioremap
[0.00] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[0.00] Preemptible hierarchical RCU implementation.
[0.00] Build-time adjustment of leaf fanout to 32.
[0.00] NR_IRQS:512 nr_irqs:512 16
[0.00] UIC0 (32 IRQ sources) at DCR 0xc0
[0.00] UIC1 (32 IRQ sources) at DCR 0xd0
[0.00] UIC2 (32 IRQ sources) at DCR 0xe0
[0.00] UIC3 (32 IRQ sources) at DCR 0xf0
[0.12] clocksource: timebase: mask: 0x max_cycles: 
0x10a60dda894, max_idle_ns: 440795207041 ns
[0.22] clocksource: timebase mult[dda520] shift[24] registered
[0.000142] Console: colour dummy device 80x25
[0.000706] console [tty0] enabled
[0.000742] pid_max: default: 32768 minimum: 301
[0.000850] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[0.000874] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
[0.003481] devtmpfs: initialized
[0.006192] clocksource: jiffies: mask: 0x max_cycles: 0x, 
max_idle_ns: 1911260446275000 ns
[0.006656] xor: measuring software checksum speed
[0.016653]8regs :   900.000 MB/sec
[0.026469]8regs_prefetch:   800.000 MB/sec
[0.036517]32regs:  1232.000 MB/sec
[0.046586]32regs_prefetch:  1084.000 MB/sec
[0.046620] xor: using function: 32regs (1232.000 MB/sec)
[0.046670] prandom: seed boundary self test passed
[0.048727] prandom: 100 self tests passed
[0.049561] NET: Registered protocol family 16
[0.054878] cpuidle: using governor ladder
[0.056960] cpuidle: using governor menu
[0.057399] 256k L2-cache enabled
[0.057534] PCIE0: Checking link...
[0.057551] PCIE0: Device detected, waiting for link...
[0.057570] PCIE0: link is up !
[0.159785] PCI host bridge /plb/pciex at d (primary) ranges:
[0.159835]  MEM 0x000e..0x000e7fff -> 
0x8000 
[0.159871]  MEM 0x000f..0x000f000f -> 
0x 
[0.159903]   IO 0x000f8000..0x000f8000 -> 0x
[0.159940] 4xx PCI DMA offset set to 0x
[0.159958] 4xx PCI DMA window base to 0x
[0.159977] DMA window size 0x8000
[0.160011] PCIE0: successfully set as root-complex
[0.160060] PCIE1: Checking link...
[0.160076] PCIE1: Device detected, waiting for link...
[0.160095] PCIE1: link i

[PATCH 0/3 v4] drm: Introduce drm_connector_register_all() helper

[Alexey Brodkin]

As a pair to already existing drm_connector_unplug_all()
(which we'll rename in this series to drm_connector_unregister_all())
we're adding generic implementation of what is already done in some drivers
for registering all connectors.

After implementation of that new helper we're updating 2 drivers
that used to use it's own implementation:
 [1] atmel_hlcdc
 [2] rcar_du

Other drivers still use load() callback and so should be first modified so
their load() gets called from their probe() explicitly.

Build- and run-tested on yet to be upstreamed ARC PGU (part of AXS10x board).

Changes v3 -> v4:
 * Based on current drm-intel/topic/drm-misc
   It's now on commit 6c87e5c3ec6db052f3744804a517b6fb003906e1
   And since thet new base already has
   "drm: Rename drm_connector_unplug_all() to drm_connector_unregister_all()"
   this series now only includes 3 subsequent patches.

 * In drm_connector_register_all() fail path which calls unregister_all()
   is moved outside of loop&locked section (as suggested by Daniel)

Changes v2 -> v3:
 * Added acks for 1, 3 and 4 patches
 * Updated kerneldoc descriptins of both register_ and unregister_all()
 * Updated commit messages (mostly spellos and grammar issues)

Changes v1 -> v2:
 * Rename drm_connector_unplug_all() to drm_connector_unregister_all()
 * Use drm_for_each_connector() instead of list_for_each_entry()
 * Updated kerneldoc for drm_dev_register()

Alexey Brodkin (3):
  drm: Introduce drm_connector_register_all() helper
  drm: atmel_hldc: Use generic drm_connector_register_all() helper
  drm: rcar-du: Use generic drm_connector_register_all() helper

Cc: Daniel Vetter 
Cc: David Airlie 
Cc: Boris Brezillon 
Cc: Laurent Pinchart 
Cc: linux-renesas-soc at vger.kernel.org
Cc: David Herrmann 

 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 39 ++--
 drivers/gpu/drm/drm_crtc.c   | 39 
 drivers/gpu/drm/drm_drv.c|  6 -
 drivers/gpu/drm/rcar-du/rcar_du_drv.c|  9 +--
 include/drm/drm_crtc.h   |  3 ++-
 5 files changed, 49 insertions(+), 47 deletions(-)

-- 
2.5.0

[PATCH 1/3 v4] drm: Introduce drm_connector_register_all() helper

[Alexey Brodkin]

As a pair to already existing drm_connector_unregister_all() we're adding
generic implementation of what is already done in some drivers.

Once this helper is implemented we'll be ready to switch existing
driver-specific implementations with the generic one.

Signed-off-by: Alexey Brodkin 
Cc: Daniel Vetter 
Cc: David Airlie 
Cc: David Herrmann 
---

Changes v3 -> v4:
 * In drm_connector_register_all() fail path which calls unregister_all()
   is moved outside of loop&locked section (as suggested by Daniel)

Changes v2 -> v3:
 * Updated title with capital after colon
 * Simplified failure path with direct and unconditional invocation of
   unregister_all()
 * Updated kerneldoc description of the drm_connector_register_all()

Changes v1 -> v2:
 * Rename drm_connector_unplug_all() to drm_connector_unregister_all()
 * Use drm_for_each_connector() instead of list_for_each_entry()
 * Updated kerneldoc for drm_dev_register()

 drivers/gpu/drm/drm_crtc.c | 39 +++
 drivers/gpu/drm/drm_drv.c  |  6 +-
 include/drm/drm_crtc.h |  3 ++-
 3 files changed, 46 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 7675826..3e4cdb1 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1079,6 +1079,45 @@ void drm_connector_unregister(struct drm_connector 
*connector)
 EXPORT_SYMBOL(drm_connector_unregister);

 /**
+ * drm_connector_register_all - register all connectors
+ * @dev: drm device
+ *
+ * This function registers all connectors in sysfs and other places so that
+ * userspace can start to access them. Drivers can call it after calling
+ * drm_dev_register() to complete the device registration, if they don't call
+ * drm_connector_register() on each connector individually.
+ *
+ * When a device is unplugged and should be removed from userspace access,
+ * call drm_connector_unregister_all(), which is the inverse of this
+ * function.
+ *
+ * Returns:
+ * Zero on success, error code on failure.
+ */
+int drm_connector_register_all(struct drm_device *dev)
+{
+   struct drm_connector *connector;
+   int ret;
+
+   mutex_lock(&dev->mode_config.mutex);
+
+   drm_for_each_connector(connector, dev) {
+   ret = drm_connector_register(connector);
+   if (ret)
+   goto err;
+   }
+
+   mutex_unlock(&dev->mode_config.mutex);
+
+   return 0;
+
+err:
+   drm_connector_unregister_all(dev);
+   return ret;
+}
+EXPORT_SYMBOL(drm_connector_register_all);
+
+/**
  * drm_connector_unregister_all - unregister connector userspace interfaces
  * @dev: drm device
  *
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 167c8d3..2c9a2b6 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -715,7 +715,11 @@ EXPORT_SYMBOL(drm_dev_unref);
  *
  * Register the DRM device @dev with the system, advertise device to user-space
  * and start normal device operation. @dev must be allocated via 
drm_dev_alloc()
- * previously.
+ * previously. Right after drm_dev_register() the driver should call
+ * drm_connector_register_all() to register all connectors in sysfs. This is
+ * a separate call for backward compatibility with drivers still using
+ * the deprecated ->load() callback, where connectors are registered from 
within
+ * the ->load() callback.
  *
  * Never call this twice on any device!
  *
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 12f2bd4..6231f6c 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -2253,7 +2253,8 @@ void drm_connector_unregister(struct drm_connector 
*connector);

 extern void drm_connector_cleanup(struct drm_connector *connector);
 extern unsigned int drm_connector_index(struct drm_connector *connector);
-/* helper to unregister all connectors from sysfs for device */
+/* helpers to {un}register all connectors from sysfs for device */
+extern int drm_connector_register_all(struct drm_device *dev);
 extern void drm_connector_unregister_all(struct drm_device *dev);

 extern int drm_bridge_add(struct drm_bridge *bridge);
-- 
2.5.0

[PATCH 2/3 v4] drm: atmel_hldc: Use generic drm_connector_register_all() helper

[Alexey Brodkin]

This driver used to have its own implementation of connector_register_all()
which actually was taken as a prototype of drm_connector_register_all().

Now when drm_connector_register_all() exists reusing it here.

And while at it replace atmel_hlcdc_dc_connector_unplug_all()
with generic drm_connector_unregister_all().

Signed-off-by: Alexey Brodkin 
Cc: Daniel Vetter 
Cc: David Airlie 
Acked-by: Boris Brezillon 
---

No changes v3 -> v4.

Changes v2 -> v3:
 * Updated title with capital after colon
 * Added ack from Boris

No changes v1 -> v2.

 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 39 ++--
 1 file changed, 2 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 3d8d164..1c537e4 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -584,41 +584,6 @@ static void atmel_hlcdc_dc_unload(struct drm_device *dev)
destroy_workqueue(dc->wq);
 }

-static int atmel_hlcdc_dc_connector_plug_all(struct drm_device *dev)
-{
-   struct drm_connector *connector, *failed;
-   int ret;
-
-   mutex_lock(&dev->mode_config.mutex);
-   list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
-   ret = drm_connector_register(connector);
-   if (ret) {
-   failed = connector;
-   goto err;
-   }
-   }
-   mutex_unlock(&dev->mode_config.mutex);
-   return 0;
-
-err:
-   list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
-   if (failed == connector)
-   break;
-
-   drm_connector_unregister(connector);
-   }
-   mutex_unlock(&dev->mode_config.mutex);
-
-   return ret;
-}
-
-static void atmel_hlcdc_dc_connector_unplug_all(struct drm_device *dev)
-{
-   mutex_lock(&dev->mode_config.mutex);
-   drm_connector_unplug_all(dev);
-   mutex_unlock(&dev->mode_config.mutex);
-}
-
 static void atmel_hlcdc_dc_lastclose(struct drm_device *dev)
 {
struct atmel_hlcdc_dc *dc = dev->dev_private;
@@ -736,7 +701,7 @@ static int atmel_hlcdc_dc_drm_probe(struct platform_device 
*pdev)
if (ret)
goto err_unload;

-   ret = atmel_hlcdc_dc_connector_plug_all(ddev);
+   ret = drm_connector_register_all(ddev);
if (ret)
goto err_unregister;

@@ -758,7 +723,7 @@ static int atmel_hlcdc_dc_drm_remove(struct platform_device 
*pdev)
 {
struct drm_device *ddev = platform_get_drvdata(pdev);

-   atmel_hlcdc_dc_connector_unplug_all(ddev);
+   drm_connector_unregister_all(ddev);
drm_dev_unregister(ddev);
atmel_hlcdc_dc_unload(ddev);
drm_dev_unref(ddev);
-- 
2.5.0

[PATCH 3/3 v4] drm: rcar-du: Use generic drm_connector_register_all() helper

[Alexey Brodkin]

Now that a generic drm_connector_register_all() helper exists we may safely
substitute it for the driver-specific implementation of connectors plugging
in sysfs.

Signed-off-by: Alexey Brodkin 
Cc: Daniel Vetter 
Cc: David Airlie 
Cc: linux-renesas-soc at vger.kernel.org
Acked-by: Laurent Pinchart 
---

No changes v3 -> v4.

Changes v2 -> v3:
 * Updated title with capital after colon
 * Updated commit message with fixes of spellos and grammar issues
 * Added ack from Laurent

No changes v1 -> v2.

 drivers/gpu/drm/rcar-du/rcar_du_drv.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 644db36..0f251dc 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -361,14 +361,7 @@ static int rcar_du_probe(struct platform_device *pdev)
if (ret)
goto error;

-   mutex_lock(&ddev->mode_config.mutex);
-   drm_for_each_connector(connector, ddev) {
-   ret = drm_connector_register(connector);
-   if (ret < 0)
-   break;
-   }
-   mutex_unlock(&ddev->mode_config.mutex);
-
+   ret = drm_connector_register_all(ddev);
if (ret < 0)
goto error;

-- 
2.5.0

[PATCH 1/3 v4] drm: Introduce drm_connector_register_all() helper

[Alexey Brodkin]

Hi David,

On Tue, 2016-03-29 at 12:08 +0200, David Herrmann wrote:
> Hi
> 
> On Tue, Mar 29, 2016 at 12:02 PM, Alexey Brodkin
>  wrote:
> > 
> > As a pair to already existing drm_connector_unregister_all() we're adding
> > generic implementation of what is already done in some drivers.
> > 
> > Once this helper is implemented we'll be ready to switch existing
> > driver-specific implementations with the generic one.
> > 
> > Signed-off-by: Alexey Brodkin 
> > Cc: Daniel Vetter 
> > Cc: David Airlie 
> > Cc: David Herrmann 
> > ---
> > 
> > Changes v3 -> v4:
> >  * In drm_connector_register_all() fail path which calls unregister_all()
> >    is moved outside of loop&locked section (as suggested by Daniel)
> > 
> > Changes v2 -> v3:
> >  * Updated title with capital after colon
> >  * Simplified failure path with direct and unconditional invocation of
> >    unregister_all()
> >  * Updated kerneldoc description of the drm_connector_register_all()
> > 
> > Changes v1 -> v2:
> >  * Rename drm_connector_unplug_all() to drm_connector_unregister_all()
> >  * Use drm_for_each_connector() instead of list_for_each_entry()
> >  * Updated kerneldoc for drm_dev_register()
> > 
> >  drivers/gpu/drm/drm_crtc.c | 39 +++
> >  drivers/gpu/drm/drm_drv.c  |  6 +-
> >  include/drm/drm_crtc.h     |  3 ++-
> >  3 files changed, 46 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index 7675826..3e4cdb1 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -1079,6 +1079,45 @@ void drm_connector_unregister(struct drm_connector 
> > *connector)
> >  EXPORT_SYMBOL(drm_connector_unregister);
> > 
> >  /**
> > + * drm_connector_register_all - register all connectors
> > + * @dev: drm device
> > + *
> > + * This function registers all connectors in sysfs and other places so that
> > + * userspace can start to access them. Drivers can call it after calling
> > + * drm_dev_register() to complete the device registration, if they don't 
> > call
> > + * drm_connector_register() on each connector individually.
> > + *
> > + * When a device is unplugged and should be removed from userspace access,
> > + * call drm_connector_unregister_all(), which is the inverse of this
> > + * function.
> > + *
> > + * Returns:
> > + * Zero on success, error code on failure.
> > + */
> > +int drm_connector_register_all(struct drm_device *dev)
> > +{
> > +       struct drm_connector *connector;
> > +       int ret;
> > +
> > +       mutex_lock(&dev->mode_config.mutex);
> > +
> > +       drm_for_each_connector(connector, dev) {
> > +               ret = drm_connector_register(connector);
> > +               if (ret)
> > +                       goto err;
> > +       }
> > +
> > +       mutex_unlock(&dev->mode_config.mutex);
> > +
> > +       return 0;
> > +
> > +err:
> > +       drm_connector_unregister_all(dev);
> You _must_ unlock the mutex before returning.

So true!

BTW that's why I liked the previous solution - code was much cleaner
with only 1 branch of execution.

Will resend v5 in a minute.

-Alexey

[PATCH v3 13/19] drm: sun4i: Add DT bindings documentation

[Maxime Ripard]

backend interface clock
> > +* mod: the backend module clock
> > +* ram: the backend DRAM clock
> > +  - clock-names: the clock names mentioned above
> > +  - resets: phandles to the reset controllers driving the backend
> > +
> > +- ports: A ports node with endpoint definitions as defined in
> > +  Documentation/devicetree/bindings/media/video-interfaces.txt. The
> > +  first port should be the input endpoints, the second one the output
> > +
> > +Display Engine Frontend
> > +---
> > +
> > +The display engine frontend does formats conversion, scaling,
> > +deinterlacing and color space conversion.
> > +
> > +Required properties:
> > +  - compatible: value must be one of:
> > +* allwinner,sun5i-a13-display-frontend
> > +  - reg: base address and size of the memory-mapped region.
> > +  - interrupts: interrupt associated to this IP
> > +  - clocks: phandles to the clocks feeding the frontend and backend
> > +* ahb: the backend interface clock
> > +* mod: the backend module clock
> > +* ram: the backend DRAM clock
> > +  - clock-names: the clock names mentioned above
> > +  - resets: phandles to the reset controllers driving the backend
> > +
> > +Display Engine Pipeline
> > +---
> > +
> > +The display engine pipeline (and its entry point, since it can be
> > +either directly the backend or the frontend) is represented as an
> > +extra node.
> > +
> > +Required properties:
> > +  - compatible: value must be one of:
> > +* allwinner,sun5i-a13-display-engine
> > +  - allwinner,pipelines: list of phandle to the entry points of the
> > +pipelines (either to the frontend or backend)
> 
> Seems like using FE or BE would be a function of your framebuffers' 
> formats and shouldn't be defined in DT.

Well, they are different IP blocks, so it should be defined in DT,
shouldn't it?

> 
> > +
> > +Example:
> > +
> > +panel: panel {
> > +   compatible = "olimex,lcd-olinuxino-43-ts";
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +
> > +   port at 0 {
> > +   reg = <0>;
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +
> > +   panel_input: endpoint at 0 {
> > +   reg = <0>;
> > +   remote-endpoint = <&tcon0_out_panel>;
> 
> You can drop the unit-addresses and reg when there is only 1 (or 
> leaving is fine too).
> 
> > +   };
> > +   };
> > +};
> > +
> > +tve0: tv-encoder at 01c0a000 {
> 
> Drop the leading 0.

Ok.

> 
> > +   compatible = "allwinner,sun4i-a10-tv-encoder";
> > +   reg = <0x01c0a000 0x1000>;
> > +   clocks = <&ahb_gates 34>;
> > +   resets = <&tcon_ch0_clk 0>;
> > +
> > +   port {
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +
> > +   tve0_in_tcon0: endpoint at 0 {
> > +   reg = <0>;
> > +   remote-endpoint = <&tcon0_out_tve0>;
> > +   };
> > +   };
> > +};
> > +
> > +tcon0: lcd-controller at 01c0c000 {
> 
> ditto...

Ok.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160329/ba0881f7/attachment.sig>

[PATCH] Revert "drm: Don't pass negative delta to ktime_sub_ns()"

[Daniel Vetter]

This reverts commit e91abf80a0998f326107874c88d549f94839f13c.

Since

commit 24e4a8c3e8868874835b0f1ad6dd417341e99822
Author: John Stultz 
Date:   Wed Jul 16 21:03:53 2014 +

ktime: Kill non-scalar ktime_t implementation for 2038

there is no longer a 32bit version that's unsigned, and we don't have
to jump through ridiculous hoops to make the calculations correct.

I didn't look whether there's more of this pattern in the kernel.

Cc: John Stultz 
Cc: Thomas Gleixner 
Cc: Michel Dänzer 
Cc: Imre Deak 
Cc: Dave Airlie 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_irq.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index f77653562fac..4d06cf41df96 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -863,10 +863,7 @@ int drm_calc_vbltimestamp_from_scanoutpos(struct 
drm_device *dev,
/* Subtract time delta from raw timestamp to get final
 * vblank_time timestamp for end of vblank.
 */
-   if (delta_ns < 0)
-   etime = ktime_add_ns(etime, -delta_ns);
-   else
-   etime = ktime_sub_ns(etime, delta_ns);
+   etime = ktime_sub_ns(etime, delta_ns);
*vblank_time = ktime_to_timeval(etime);

DRM_DEBUG_VBL("crtc %u : v 0x%x p(%d,%d)@ %ld.%ld -> %ld.%ld [e %d us, 
%d rep]\n",
-- 
2.8.0.rc3

[RFC PATCH v1 0/4] Add Rockchip RGA support

[Yakir Yang]

Hi Emil & Heiko,


On 03/29/2016 05:35 AM, Emil Velikov wrote:
> On 28 March 2016 at 19:44, Heiko Stübner  wrote:
>> Am Montag, 28. März 2016, 13:21:02 schrieb Emil Velikov:
>>> On 22 March 2016 at 00:42, Heiko Stuebner  wrote:
 Hi Yakir,

 Am Montag, 21. März 2016, 20:17:46 schrieb Yakir Yang:
> On 03/21/2016 07:29 PM, Heiko Stübner wrote:
>> Am Montag, 21. März 2016, 17:28:38 schrieb Yakir Yang:
>>> This patch set would add the RGA direct rendering based 2d graphics
>>> acceleration module.
>> very cool to see that.
> ;)
>
>>> This patch set is based on git repository below:
>>> git://people.freedesktop.org/~airlied/linux drm-next
>>> commit id: 568d7c764ae01f3706085ac8f0d8a8ac7e826bd7
>>>
>>> And the RGA driver is based on Exynos G2D driver, it only manages the
>>> command lists received from user, so user should make the command list
>>> to data and registers needed by operation to use.
>>>
>>> I have prepared an userspace demo application for testing:
>>> https://github.com/yakir-Yang/libdrm-rockchip
>>>
>>> That is a rockchip libdrm library, and I have write a simple test case
>>> "rockchip_rga_test" that would test the below RGA features:
>>> - solid
>>> - copy
>>> - rotation
>>> - flip
>>> - window clip
>>> - dithering
>> Did you submit your libdrm changes as well?
>>
>> Userspace-interfaces need to be stable so the other side must also get
>> accepted - even before the kernel change if I remember correctly.
> Got it, and I just saw exynos_fimg2d already landed at mainline libdrm.
> But I don't find the way to submit patches to libdrm, would you like
> share some helps here ;)
 Looking at the libdrm sources on cgit.freedesktop.org, I did not find any
 specific manual on submitting patches.

 But looking at the dri-list archive, dri-devel at lists.freedesktop.org is
 the
 right list and looking at the libdrm history it looks like Emil Velikov
  seems to be doing maintenance-stuff in 
 libdrm.
 And as a 3rd recipient, please also include the linux-rockchip list.

 @Emil, please shout if I read that wrong :-)
>>> You got it spot on Heiko. There are a few notes though...
>>>
>>> As one reuses the existing hardware/IP block, it would be better to
>>> avoid copy/pasting code around.
>>> Namely:
>>>   - (if possible) factor out the exynos g2d kernel functionality to a
>>> separate kernel module and wire up the rockhip (via dt ?) to use it
>>>   - factor out the g2d specifics out of exynos_drm.h (into
>>> exynos_g2d_drm.h perhaps ?) and make sure exynos_drm.h includes the
>>> new header
>> I think the IP blocks themself are quite different between Rockchip's RGA and
>> Samsung's g2d and I guess the similarities are more along the lines on how
>> that gets integrated into the respective drm driver and userspace.
>>

Yes, the hardware IP blocks is quite different. I just reference two things
from Exynos g2d code:
1. UAPI side: let userspace pass the detail mode tranform register setting
 to kernel directly, so we don't need to pass the rendering 
parameters to
 kernel, just simplify the ioctl parameters.

2. Kernel side: reference the cmdlist manager method. Two simply task: one
 for collecting the userspace register setting, another start 
rendering process.

> In this case, the exynos_g2d_drm.h seems like a good idea. As I'm
> obviously biased, it's better to check how others feel on the topic.

Do you mean that just create an exynos_g2d_drm.h, so both exynos_drm.h
and rockchip_drm.h could include them ? It's good to reuse code, but in this
case I thought it's better to keep both exist.

I have try to do that, split the common 'exynos_g2d_drm.h'. But I 
thought it may
caused some name confusion. For example, the drm rockchip code need call the
EXYNOS_G2D_SET_CMDLIST ioctl to send command list. This may like drm 
rockchip
is calling the Exynos G2D hardware, but actually it just the name conflict.

Actually the head file is much simple, just contained 60 lines.

So, is it okay not to split the head file, just keep the data structure 
define both
rockchip_drm.h and exynos_drm.h

>>>   - if neither of these are possible, then please ensure that the new
>>> header uses correct types (see the docs [1]), use MIT/X11 license (if
>>> possible) and link where upstream userspace is happy with the
>>> interface (ideally more than a simple test app like libdrm)
>>> These might sound like an overkill, although getting UAPI right and
>>> maintaining it forever forces us to do so.
>> As for a real-world usecase, maybe the armsoc xserver might be somewhat easy
>> to use. While the core changes I did are in the core project already, I'm
>> still keeping the actual Rockchip support separate [0] due to the not-yet-
>> resolved create_gem ioctl.
>>
>> Anyway, the armsoc xserver has some exa implementation hooks were I gue

[RFC PATCH v1 0/4] Add Rockchip RGA support

[Yakir Yang]

Hi Emil,

On 03/28/2016 08:21 PM, Emil Velikov wrote:
> On 22 March 2016 at 00:42, Heiko Stuebner  wrote:
>> Hi Yakir,
>>
>> Am Montag, 21. März 2016, 20:17:46 schrieb Yakir Yang:
>>> On 03/21/2016 07:29 PM, Heiko Stübner wrote:
 Am Montag, 21. März 2016, 17:28:38 schrieb Yakir Yang:
> This patch set would add the RGA direct rendering based 2d graphics
> acceleration module.
 very cool to see that.
>>> ;)
>>>
> This patch set is based on git repository below:
> git://people.freedesktop.org/~airlied/linux drm-next
> commit id: 568d7c764ae01f3706085ac8f0d8a8ac7e826bd7
>
> And the RGA driver is based on Exynos G2D driver, it only manages the
> command lists received from user, so user should make the command list
> to data and registers needed by operation to use.
>
> I have prepared an userspace demo application for testing:
> https://github.com/yakir-Yang/libdrm-rockchip
>
> That is a rockchip libdrm library, and I have write a simple test case
> "rockchip_rga_test" that would test the below RGA features:
> - solid
> - copy
> - rotation
> - flip
> - window clip
> - dithering
 Did you submit your libdrm changes as well?

 Userspace-interfaces need to be stable so the other side must also get
 accepted - even before the kernel change if I remember correctly.
>>> Got it, and I just saw exynos_fimg2d already landed at mainline libdrm.
>>> But I don't find the way to submit patches to libdrm, would you like
>>> share some helps here ;)
>> Looking at the libdrm sources on cgit.freedesktop.org, I did not find any
>> specific manual on submitting patches.
>>
>> But looking at the dri-list archive, dri-devel at lists.freedesktop.org is 
>> the
>> right list and looking at the libdrm history it looks like Emil Velikov
>>  seems to be doing maintenance-stuff in libdrm.
>> And as a 3rd recipient, please also include the linux-rockchip list.
>>
>> @Emil, please shout if I read that wrong :-)
>>
> You got it spot on Heiko. There are a few notes though...
>
> As one reuses the existing hardware/IP block, it would be better to
> avoid copy/pasting code around.
> Namely:
>   - (if possible) factor out the exynos g2d kernel functionality to a
> separate kernel module and wire up the rockhip (via dt ?) to use it
>   - factor out the g2d specifics out of exynos_drm.h (into
> exynos_g2d_drm.h perhaps ?) and make sure exynos_drm.h includes the
> new header
>   - if neither of these are possible, then please ensure that the new
> header uses correct types (see the docs [1]), use MIT/X11 license (if
> possible) and link where upstream userspace is happy with the
> interface (ideally more than a simple test app like libdrm)

Whops... you have provided the third choice, nice  :-D

And I got little idea about license, where should I use the MIT/X11
license, should I declare the MIT/X11 license in kernel uapi head
file, but Andreas just remind that kernel do not allow to no GUN
license. Or may be I can:
1. Use GUN license in kernel rockchip_drm.h uapi head file
2. Use MIT/X11 license in libdrm rockchip_drm.h head file.

And I don't understand the "link where upstream userspace is happy
with the interface", could you reference small example here.

Thanks,
- Yakir

> These might sound like an overkill, although getting UAPI right and
> maintaining it forever forces us to do so.
>
> Regards,
> Emil
>
> [1] 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/ioctl/botching-up-ioctls.txt
>
>
>

[RFC PATCH v1 0/4] Add Rockchip RGA support

[Yakir Yang]

Hi Andreas,

On 03/22/2016 06:24 PM, Andreas Färber wrote:
> Hi Yakir,
>
> Am 21.03.2016 um 13:17 schrieb Yakir Yang:
>> On 03/21/2016 07:29 PM, Heiko Stübner wrote:
>>> Am Montag, 21. März 2016, 17:28:38 schrieb Yakir Yang:
 This patch set would add the RGA direct rendering based 2d graphics
 acceleration module.
>>> very cool to see that.
>> ;)
 This patch set is based on git repository below:
 git://people.freedesktop.org/~airlied/linux drm-next
 commit id: 568d7c764ae01f3706085ac8f0d8a8ac7e826bd7

 And the RGA driver is based on Exynos G2D driver, it only manages the
 command lists received from user, so user should make the command list
 to data and registers needed by operation to use.

 I have prepared an userspace demo application for testing:
  https://github.com/yakir-Yang/libdrm-rockchip
 That is a rockchip libdrm library, and I have write a simple test case
 "rockchip_rga_test" that would test the below RGA features:
 - solid
 - copy
 - rotation
 - flip
 - window clip
 - dithering
>>> Did you submit your libdrm changes as well?
>>>
>>> Userspace-interfaces need to be stable so the other side must also get
>>> accepted - even before the kernel change if I remember correctly.
>> Got it, and I just saw exynos_fimg2d already landed at mainline libdrm.
>> But I don't find the way to submit patches to libdrm, would you like
>> share some helps here ;)
> If you're using Exynos as an example, please keep in mind that the
> libdrm license is MIT/X11, not GPL as the kernel. For our Linux distro
> we had to disable some Exynos parts because they snuck some GPL code in
> there and redistributing libdrm under GPL would cause a big headache
> (review of all packages directly or indirectly linking against it).

Hmmm... I just saw exynos_drm.h still declared the GNU license,
is it convince for you to share some specific example here ;)

Thanks,
- Yakir
> Thanks,
> Andreas
>

[RFC PATCH v1 0/4] Add Rockchip RGA support

[Heiko Stübner]

Am Dienstag, 29. März 2016, 19:17:12 schrieb Yakir Yang:
> Hi Emil & Heiko,
> 
> On 03/29/2016 05:35 AM, Emil Velikov wrote:
> > On 28 March 2016 at 19:44, Heiko Stübner  wrote:
> >> Am Montag, 28. März 2016, 13:21:02 schrieb Emil Velikov:
> >>> On 22 March 2016 at 00:42, Heiko Stuebner  wrote:
>  Hi Yakir,
>  
>  Am Montag, 21. März 2016, 20:17:46 schrieb Yakir Yang:
> > On 03/21/2016 07:29 PM, Heiko Stübner wrote:
> >> Am Montag, 21. März 2016, 17:28:38 schrieb Yakir Yang:
> >>> This patch set would add the RGA direct rendering based 2d graphics
> >>> acceleration module.
> >> 
> >> very cool to see that.
> > 
> > ;)
> > 
> >>> This patch set is based on git repository below:
> >>> git://people.freedesktop.org/~airlied/linux drm-next
> >>> commit id: 568d7c764ae01f3706085ac8f0d8a8ac7e826bd7
> >>> 
> >>> And the RGA driver is based on Exynos G2D driver, it only manages
> >>> the
> >>> command lists received from user, so user should make the command
> >>> list
> >>> to data and registers needed by operation to use.
> >>> 
> >>> I have prepared an userspace demo application for testing:
> >>> https://github.com/yakir-Yang/libdrm-rockchip
> >>> 
> >>> That is a rockchip libdrm library, and I have write a simple test
> >>> case
> >>> "rockchip_rga_test" that would test the below RGA features:
> >>> - solid
> >>> - copy
> >>> - rotation
> >>> - flip
> >>> - window clip
> >>> - dithering
> >> 
> >> Did you submit your libdrm changes as well?
> >> 
> >> Userspace-interfaces need to be stable so the other side must also
> >> get
> >> accepted - even before the kernel change if I remember correctly.
> > 
> > Got it, and I just saw exynos_fimg2d already landed at mainline
> > libdrm.
> > But I don't find the way to submit patches to libdrm, would you like
> > share some helps here ;)
>  
>  Looking at the libdrm sources on cgit.freedesktop.org, I did not find
>  any
>  specific manual on submitting patches.
>  
>  But looking at the dri-list archive, dri-devel at lists.freedesktop.org 
>  is
>  the
>  right list and looking at the libdrm history it looks like Emil Velikov
>   seems to be doing maintenance-stuff in
>  libdrm.
>  And as a 3rd recipient, please also include the linux-rockchip list.
>  
>  @Emil, please shout if I read that wrong :-)
> >>> 
> >>> You got it spot on Heiko. There are a few notes though...
> >>> 
> >>> As one reuses the existing hardware/IP block, it would be better to
> >>> avoid copy/pasting code around.
> >>> 
> >>> Namely:
> >>>   - (if possible) factor out the exynos g2d kernel functionality to a
> >>> 
> >>> separate kernel module and wire up the rockhip (via dt ?) to use it
> >>> 
> >>>   - factor out the g2d specifics out of exynos_drm.h (into
> >>> 
> >>> exynos_g2d_drm.h perhaps ?) and make sure exynos_drm.h includes the
> >>> new header
> >> 
> >> I think the IP blocks themself are quite different between Rockchip's RGA
> >> and Samsung's g2d and I guess the similarities are more along the lines
> >> on how that gets integrated into the respective drm driver and
> >> userspace.
> Yes, the hardware IP blocks is quite different. I just reference two things
> from Exynos g2d code:
> 1. UAPI side: let userspace pass the detail mode tranform register setting
>  to kernel directly, so we don't need to pass the rendering
> parameters to
>  kernel, just simplify the ioctl parameters.
> 
> 2. Kernel side: reference the cmdlist manager method. Two simply task: one
>  for collecting the userspace register setting, another start
> rendering process.
> 
> > In this case, the exynos_g2d_drm.h seems like a good idea. As I'm
> > obviously biased, it's better to check how others feel on the topic.
> 
> Do you mean that just create an exynos_g2d_drm.h, so both exynos_drm.h
> and rockchip_drm.h could include them ? It's good to reuse code, but in this
> case I thought it's better to keep both exist.
> 
> I have try to do that, split the common 'exynos_g2d_drm.h'. But I
> thought it may
> caused some name confusion. For example, the drm rockchip code need call the
> EXYNOS_G2D_SET_CMDLIST ioctl to send command list. This may like drm
> rockchip
> is calling the Exynos G2D hardware, but actually it just the name conflict.
> 
> Actually the head file is much simple, just contained 60 lines.
> 
> So, is it okay not to split the head file, just keep the data structure
> define both
> rockchip_drm.h and exynos_drm.h
> 
> >>>   - if neither of these are possible, then please ensure that the new
> >>> 
> >>> header uses correct types (see the docs [1]), use MIT/X11 license (if
> >>> possible) and link where upstream userspace is happy with the
> >>> interface (ideally more than a simple test app like libdrm)
> >>> These might sound like an overkill, 

[RFC PATCH v1 2/4] drm: rockchip: add RGA driver support

[Yakir Yang]

Hi Rob,

+ rockchip / dri email list back

On 03/23/2016 10:20 PM, Rob Herring wrote:
> On Mon, Mar 21, 2016 at 05:40:06PM +0800, Yakir Yang wrote:
>> Rockchip RGA is a separate 2D raster graphic acceleration unit. It
>> accelerates 2D graphics operations, such as point/line drawing, image
>> scaling, rotation, BitBLT, alpha blending and image blur/sharpness.
>>
>> The RGA driver is based on Exynos G2D driver, it is performed by two
>> tasks simply.
>> 1. Configures the rendering parameters, such as foreground color and
>> coordinates data by setting the drawing context registers.
>> 2. Start the rendering process by calling rga_exec() ioctl.
>>
>> The RGA supports DMA mode as host interface. User can make command list
>> to reduce HOST(ARM) loads. The contents of The command list is setted to
>> relevant registers of RGA by DMA.
>>
>> The command list is composed Header and command sets and Tail.
>> - Header: The number of command set(4Bytes)
>> - Command set: Register offset(4Bytes) + Register data(4Bytes)
>> - Tail: Pointer of base address of the other command list(4Bytes)
>>
>> By Tail field, the G2D can process many command lists without halt at
>> one go.
>>
>> The G2D has following the rendering pipeline.
>> ---> Color Fill --->
>> |  |
>> --> DMA (read) ---> Src Bitmap Process > Alpha/ROP ---> Format convert 
>> ---> DMA (Write)
>> |  |
>> ---> Dst Bitmap Process --->
>>
>> And supports various operations from the rendering pipeline.
>> - copy
>> - fast solid color fill
>> - rotation
>> - flip
>> - 4 operand raster operation(ROP4)
>> - alpha blending
>> - color key
>> - dithering
>> - etc
>>
>> User should make the command list to data and registers needed by
>> operation to use. The Rockchip RGA driver only manages the command lists
>> received from user. Some registers needs memory base address(physical
>> address) of image. User doesn't know its physical address, so fills the
>> gem handle of that memory than address to command sets, then RGA driver
>> converts it to memory base address.
>>
>> We adds three ioctls for Rockchip RGA.
>>
>> - ioctls
>> DRM_ROCKCHIP_RGA_GET_VER: get the RGA hardware version
>> DRM_ROCKCHIP_RGA_SET_CMDLIST: set the command list from user to driver
>> DRM_ROCKCHIP_RGA_EXEC: execute the command lists setted to driver
>>
>> Signed-off-by: Yakir Yang 
>> ---
>>   .../bindings/display/rockchip/rockchip-rga.txt |  36 +
>>   drivers/gpu/drm/rockchip/Kconfig   |   9 +
>>   drivers/gpu/drm/rockchip/Makefile  |   1 +
>>   drivers/gpu/drm/rockchip/rockchip_drm_drv.c|  35 +-
>>   drivers/gpu/drm/rockchip/rockchip_drm_drv.h|   4 +
>>   drivers/gpu/drm/rockchip/rockchip_drm_rga.c| 977 
>> +
>>   drivers/gpu/drm/rockchip/rockchip_drm_rga.h| 108 +++
>>   include/uapi/drm/rockchip_drm.h|  63 ++
>>   8 files changed, 1232 insertions(+), 1 deletion(-)
>>   create mode 100644 
>> Documentation/devicetree/bindings/display/rockchip/rockchip-rga.txt
>>   create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_rga.c
>>   create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_rga.h
>>   create mode 100644 include/uapi/drm/rockchip_drm.h
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/display/rockchip/rockchip-rga.txt 
>> b/Documentation/devicetree/bindings/display/rockchip/rockchip-rga.txt
>> new file mode 100644
>> index 000..0c606cb
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-rga.txt
>> @@ -0,0 +1,36 @@
>> +device-tree bindings for rockchip 2D raster graphic acceleration controller 
>> (RGA)
> s/rockchip/RockChip/
Done
>> +
>> +RGA is a separate 2D raster graphic acceleration unit. It accelerates 2D
>> +graphics operations, such as point/line drawing, image scaling, rotation,
>> +BitBLT, alpha blending and image blur/sharpness.
>> +
>> +Required properties:
>> +- compatible: value should be one of the following
>> +"rockchip,rk3228-rga";
>> +"rockchip,rk3288-rga";
>> +"rockchip,rk3399-rga";
>> +
>> +- interrupts: RGA interrupt number.
>> +
>> +- clocks: phandle to RGA sclk/hclk/aclk clocks
>> +
>> +- clock-names: should be "aclk" "hclk" and "sclk"
> comma ^
>
> You have different orders for clocks and clock-names. Please be clear
> what the order is.
>
Okay
>> +
>> +- resets: Must contain an entry for each entry in reset-names.
>> +  See ../reset/reset.txt for details.
>> +- reset-names: should be "aclk" "hclk" and "sclk"
> Same as clocks?
I should rename them to "core", "axi" and "ahb"
>> +
>> +Example:
>> +SoC specific DT entry:
>> +rga: rga at ff68 {
> gpu at ... to be generic
Done
>> +compatible = "rockchip,rk3399-rga";
>> +reg = <0xff68 0x1>;
>> +interrupts = ;
>> +inter

[Bug 92258] [regression] Opening menu in Steam running via DRI_PRIME with enabled DRI3 could lead to radeon kernel module crash

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

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

--- Comment #18 from Vladislav Kamenev  ---
(In reply to Maarten Lankhorst from comment #10)
> Created attachment 119927 [details] [review]
> Use reservation_object_wait_timeout_rcu
> 
> I have no idea what can go wrong, lets find out if adding refcounts during
> wait helps..
> 
> Could you check the output with this patch? ^

Checked a 4.5.0 kernel with this patch.
No changes. Suffering kernel freezes. I built package and sent to OP to help
him make some logs of 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/20160329/f802b402/attachment.html>

blank screen on boot with i915/DRM_FBDEV_EMULATION

[Daniel Vetter]

On Sat, Mar 26, 2016 at 12:21:23PM +0100, Florian Zumbiehl wrote:
> Hi,
> 
> I just compiled a new kernel version 4.4.5, replacing a previous 4.1.9 for
> my thinkpad x40, which replaced CONFIG_DRM_I915_FBDEV with
> CONFIG_DRM_FBDEV_EMULATION--now, when the i915 and fbcon modules get loaded
> during boot, the screen goes blank (with backlight still on), which didn't
> happen with the old kernel.
> 
> The funny thing is that starting an X server makes text reappear on the
> console!? (And the X server also works just fine, as far as I can tell so
> far ...)
> 
> i915 is loaded with modeset=1 (I remember I had some problem without it
> with some earlier kernels, I don't really remember the details anymore
> ...).
> 
> Any hints what to try? Any further information that could be useful?

FBDEV_EMULATION vs. I915_FBDEV is probably a read herring, more likely is
that for some odd reason the very first modeset fails. Once X has
resurrect the screen, can you then switch to fbcon? Also please check in
/sys/class/vtconsole whether the fbdev driver is loaded and bound (check
the name and bind files). And make sure there's that dmesg still says it
initialized the "inteldrmfb" driver.

If that all indicates fbcon is running properly, then it's time to bisect
what exactly broke the initial modeset for your system.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm/atmel: Fixup drm_connector_/unplug/unregister/_all

[Daniel Vetter]

Accidentally fell through the cracks in

commit 6c87e5c3ec6db052f3744804a517b6fb003906e1
Author: Alexey Brodkin 
Date:   Wed Mar 23 11:42:54 2016 +0300

drm: Rename drm_connector_unplug_all() to drm_connector_unregister_all()

despite that Boris acked that patch.

Cc: Boris Brezillon 
Cc: Alexey Brodkin 
Acked-by: Boris Brezillon 
Reported-by: kbuild test robot 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 3d8d16402d07..8ab4318e57a1 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -615,7 +615,7 @@ err:
 static void atmel_hlcdc_dc_connector_unplug_all(struct drm_device *dev)
 {
mutex_lock(&dev->mode_config.mutex);
-   drm_connector_unplug_all(dev);
+   drm_connector_unregister_all(dev);
mutex_unlock(&dev->mode_config.mutex);
 }

-- 
2.8.0.rc3

[Intel-gfx] [PATCH 1/5] drm: Add new DCS commands in the enum list

[Jani Nikula]

On Mon, 28 Mar 2016, Deepak M  wrote:
> Adding new DCS commands which are specified in the
> DCS 1.3 spec related to CABC.
>
> v2: Sorted the Macro`s by value (Andrzej)

Yeah, well, the *new* ones are now sorted, but I'm pretty sure Andrzej
did mean to keep the whole enum sorted.

While at it, the comment could be /* MIPI DCS 1.3 */ to be specific and
useful.

>
> Cc: Andrzej Hajda 
> Cc: Thierry Reding 
> Cc: David Airlie 
> Cc: Ville Syrjälä 
> Cc: Daniel Vetter 
> Suggested-by: Jani Nikula 
> Signed-off-by: Deepak M 
> ---
>  include/video/mipi_display.h | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/include/video/mipi_display.h b/include/video/mipi_display.h
> index ddcc8ca..6831c84 100644
> --- a/include/video/mipi_display.h
> +++ b/include/video/mipi_display.h
> @@ -117,6 +117,14 @@ enum {
>   MIPI_DCS_GET_SCANLINE   = 0x45,
>   MIPI_DCS_READ_DDB_START = 0xA1,
>   MIPI_DCS_READ_DDB_CONTINUE  = 0xA8,
> + MIPI_DCS_SET_DISPLAY_BRIGHTNESS = 0x51, /*Spec 1.3*/
> + MIPI_DCS_GET_DISPLAY_BRIGHTNESS = 0x52, /*Spec 1.3*/
> + MIPI_DCS_WRITE_CONTROL_DISPLAY  = 0x53, /*Spec 1.3*/
> + MIPI_DCS_GET_CONTROL_DISPLAY= 0x54, /*Spec 1.3*/
> + MIPI_DCS_WRITE_POWER_SAVE   = 0x55, /*Spec 1.3*/
> + MIPI_DCS_GET_POWER_SAVE = 0x56, /*Spec 1.3*/
> + MIPI_DCS_SET_CABC_MIN_BRIGHTNESS = 0x5E, /*Spec 1.3*/
> + MIPI_DCS_GET_CABC_MIN_BRIGHTNESS = 0x5F, /*Spec 1.3*/
>  };
>  
>  /* MIPI DCS pixel formats */

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH 0/3 v5] drm: Introduce drm_connector_register_all() helper

[Boris Brezillon]

Hi Alexey,

On Tue, 29 Mar 2016 13:22:49 +0300
Alexey Brodkin  wrote:

> As a pair to already existing drm_connector_unplug_all()
> (which we'll rename in this series to drm_connector_unregister_all())
> we're adding generic implementation of what is already done in some drivers
> for registering all connectors.
> 
> After implementation of that new helper we're updating 2 drivers
> that used to use it's own implementation:
>  [1] atmel_hlcdc
>  [2] rcar_du
> 
> Other drivers still use load() callback and so should be first modified so
> their load() gets called from their probe() explicitly.
> 
> Build- and run-tested on yet to be upstreamed ARC PGU (part of AXS10x board).
> 
> Changes v4 -> v5:
>  * Added missing mutex unlock on a fail path in drm_connector_register_all()
>Thanks David for his attention and patience!
> 
> Changes v3 -> v4:
>  * Based on current drm-intel/topic/drm-misc
>It's now on commit 6c87e5c3ec6db052f3744804a517b6fb003906e1
>And since thet new base already has
>"drm: Rename drm_connector_unplug_all() to drm_connector_unregister_all()"
>this series now only includes 3 subsequent patches.
> 
>  * In drm_connector_register_all() fail path which calls unregister_all()
>is moved outside of loop&locked section (as suggested by Daniel)
> 
> Changes v2 -> v3:
>  * Added acks for 1, 3 and 4 patches
>  * Updated kerneldoc descriptins of both register_ and unregister_all()
>  * Updated commit messages (mostly spellos and grammar issues)
> 
> Changes v1 -> v2:
>  * Rename drm_connector_unplug_all() to drm_connector_unregister_all()
>  * Use drm_for_each_connector() instead of list_for_each_entry()
>  * Updated kerneldoc for drm_dev_register()
> 
> Cc: Daniel Vetter 
> Cc: David Airlie 
> Cc: Boris Brezillon 

Next time, can you please send all the patches of the series, not
only the cover letter.

Thanks,

Boris

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

[PATCH] drm/atmel: Fixup drm_connector_/unplug/unregister/_all

[Boris Brezillon]

On Tue, 29 Mar 2016 12:25:55 +
Alexey Brodkin  wrote:

> Hi Daniel,
> 
> On Tue, 2016-03-29 at 14:21 +0200, Daniel Vetter wrote:
> > Accidentally fell through the cracks in
> > 
> > commit 6c87e5c3ec6db052f3744804a517b6fb003906e1
> > Author: Alexey Brodkin 
> > Date:   Wed Mar 23 11:42:54 2016 +0300
> > 
> >     drm: Rename drm_connector_unplug_all() to 
> > drm_connector_unregister_all()
> > 
> > despite that Boris acked that patch.

My apologies for putting my ack on something I didn't even compile test.

> > 
> > Cc: Boris Brezillon 
> > Cc: Alexey Brodkin 
> > Acked-by: Boris Brezillon 
> > Reported-by: kbuild test robot 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
> > b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> > index 3d8d16402d07..8ab4318e57a1 100644
> > --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> > +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> > @@ -615,7 +615,7 @@ err:
> >  static void atmel_hlcdc_dc_connector_unplug_all(struct drm_device *dev)
> >  {
> >    mutex_lock(&dev->mode_config.mutex);
> > -   drm_connector_unplug_all(dev);
> > +   drm_connector_unregister_all(dev);
> >    mutex_unlock(&dev->mode_config.mutex);
> >  }
> 
> Isn't done in my "[PATCH 2/3 v5] drm: atmel_hldc: Use generic 
> drm_connector_register_all() helper"?

This is fixing v3 of your series. Apparently this problem is fixed in
v4 and v5.


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

[PATCH 2/4 v3] drm: Introduce drm_connector_register_all() helper

[Daniel Vetter]

On Tue, Mar 29, 2016 at 09:12:38AM +, Alexey Brodkin wrote:
> Hi Daniel,
> 
> On Tue, 2016-03-29 at 10:19 +0200, Daniel Vetter wrote:
> > On Wed, Mar 23, 2016 at 01:41:05PM +, Alexey Brodkin wrote:
> > > 
> > > Hi David,
> > > 
> > > On Wed, 2016-03-23 at 12:13 +0100, David Herrmann wrote:
> > > > 
> > > > Hi
> > > > 
> > > > On Wed, Mar 23, 2016 at 9:42 AM, Alexey Brodkin
> > > >  wrote:
> > > > > 
> > > > > 
> > > > > As a pair to already existing drm_connector_unregister_all() we're 
> > > > > adding
> > > > > generic implementation of what is already done in some drivers.
> > > > > 
> > > > > Once this helper is implemented we'll be ready to switch existing
> > > > > driver-specific implementations with the generic one.
> > > > > 
> > > > > Signed-off-by: Alexey Brodkin 
> > > > > Cc: Daniel Vetter 
> > > > > Cc: David Airlie 
> > > > > ---
> > > > > 
> > > > > Changes v2 -> v3:
> > > > >  * Updated title with capital after colon
> > > > >  * Simplified failure path with direct and unconditional invocation 
> > > > > of
> > > > >    unregister_all()
> > > > >  * Updated kerneldoc description of the drm_connector_register_all()
> > > > > 
> > > > > Changes v1 -> v2:
> > > > >  * Rename drm_connector_unplug_all() to 
> > > > > drm_connector_unregister_all()
> > > > >  * Use drm_for_each_connector() instead of list_for_each_entry()
> > > > >  * Updated kerneldoc for drm_dev_register()
> > > > > 
> > > > >  drivers/gpu/drm/drm_crtc.c | 43 
> > > > > +++
> > > > >  drivers/gpu/drm/drm_drv.c  |  6 +-
> > > > >  include/drm/drm_crtc.h     |  3 ++-
> > > > >  3 files changed, 50 insertions(+), 2 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > > > > index 65488a6..21eea11 100644
> > > > > --- a/drivers/gpu/drm/drm_crtc.c
> > > > > +++ b/drivers/gpu/drm/drm_crtc.c
> > > > > @@ -1081,6 +1081,49 @@ void drm_connector_unregister(struct 
> > > > > drm_connector *connector)
> > > > >  EXPORT_SYMBOL(drm_connector_unregister);
> > > > > 
> > > > >  /**
> > > > > + * drm_connector_register_all - register all connectors
> > > > > + * @dev: drm device
> > > > > + *
> > > > > + * This function registers all connectors in sysfs and other places 
> > > > > so that
> > > > > + * userspace can start to access them. Drivers can call it after 
> > > > > calling
> > > > > + * drm_dev_register() to complete the device registration, if they 
> > > > > don't call
> > > > > + * drm_connector_register() on each connector individually.
> > > > > + *
> > > > > + * When a device is unplugged and should be removed from userspace 
> > > > > access,
> > > > > + * call drm_connector_unregister_all(), which is the inverse of this
> > > > > + * function.
> > > > > + *
> > > > > + * Returns:
> > > > > + * Zero on success, error code on failure.
> > > > > + */
> > > > > +int drm_connector_register_all(struct drm_device *dev)
> > > > > +{
> > > > > +       struct drm_connector *connector;
> > > > > +       int ret;
> > > > > +
> > > > > +       mutex_lock(&dev->mode_config.mutex);
> > > > > +
> > > > > +       drm_for_each_connector(connector, dev) {
> > > > > +               ret = 
> > > > > drm_connector_register(connector);
> > > > > +               if (ret) {
> > > > > +                       /*
> > > > > +                        * We may safely call 
> > > > > unregister_all() here within
> > > > > +                        * area locked with 
> > > > > mutex because unregister_all()
> > > > > +                        * doesn't use locks 
> > > > > inside (see a comment in that
> > > > > +                        * function).
> > > > > +                        */
> > > > Ugh? unregister_all() says:
> > > > 
> > > > /* FIXME: taking the mode config mutex ends up in a clash with sysfs */
> > > > 
> > > > This strongly contradicts your comment. Anyway, regardless how you
> > > > want to fix it: You better unlock the mode-config mutex before
> > > > returning below.
> > > So good catch.
> > > But what I really meant since we didn't get any further after registering
> > > all "good" connections (see we're not releasing mutex still) the will be
> > > no clashes with sysfs.
> > > 
> > > Still I;d like Daniel to comment on that separately.
> > I think doing the unregister_all outside of the loop&locked section is
> > better for future-proofing. My long-term plan for connector lifetimes and
> > the connector list is:
> > - refcounting for connectors (Dave has wip patches already).
> > - separate lock for the connector list (and only that).
> > 
> > Doing it entirely separate would make things easier and more robust.
> 
> Ok makes sense.
> 
> > I merged patch 1 meanwhile to drm-misc.
> 
> So may I re-send only patches 2-4

[PATCH] drm/atmel: Fixup drm_connector_/unplug/unregister/_all

[Daniel Vetter]

On Tue, Mar 29, 2016 at 12:25:55PM +, Alexey Brodkin wrote:
> Hi Daniel,
> 
> On Tue, 2016-03-29 at 14:21 +0200, Daniel Vetter wrote:
> > Accidentally fell through the cracks in
> > 
> > commit 6c87e5c3ec6db052f3744804a517b6fb003906e1
> > Author: Alexey Brodkin 
> > Date:   Wed Mar 23 11:42:54 2016 +0300
> > 
> >     drm: Rename drm_connector_unplug_all() to 
> > drm_connector_unregister_all()
> > 
> > despite that Boris acked that patch.
> > 
> > Cc: Boris Brezillon 
> > Cc: Alexey Brodkin 
> > Acked-by: Boris Brezillon 
> > Reported-by: kbuild test robot 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
> > b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> > index 3d8d16402d07..8ab4318e57a1 100644
> > --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> > +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> > @@ -615,7 +615,7 @@ err:
> >  static void atmel_hlcdc_dc_connector_unplug_all(struct drm_device *dev)
> >  {
> >    mutex_lock(&dev->mode_config.mutex);
> > -   drm_connector_unplug_all(dev);
> > +   drm_connector_unregister_all(dev);
> >    mutex_unlock(&dev->mode_config.mutex);
> >  }
> 
> Isn't done in my "[PATCH 2/3 v5] drm: atmel_hldc: Use generic 
> drm_connector_register_all() helper"?

Yes, but splitting it like that breaks bisectability, which isn't good.
Also your atmel change drops the mode_config.mutex. We might want to have
that part in a separate patch, so that the atmel patch only switches over
to the register_all helper.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[RFC PATCH v1 0/4] Add Rockchip RGA support

[Emil Velikov]

On 28 March 2016 at 23:13, Heiko Stübner  wrote:

> I have the feeling we're going quite a bit off-topic right now :-) .
> The binary-driver-crazyness, hasn't really anything to do with Yakir's support
> for the RGA (which is about raster-graphics-acceleration, so 2d stuff).
>
> And me mentioning the armsoc-ddx was merely a means to allow some sort of
> different userspace user, as requested in your original mail ;-) .
>
Seems like I forgot to state the obvious - for all the reasons
mentioned, the armsoc ddx seems like a bad example.

> Maybe you know a better use-case on where to demonstrate the viability of the
> userspace API for it as originally requested.
I'm afraid that my RockChip-foo is extremely limited. Perhaps the
actual user of these should be mentioned ? xf86-video-rockhip (is
there one ?) or any other effort/project that lacks some (all?) of the
criticism listed.

(Sort of) the bottom line - either reuse the existing interfaces or
provide an approved, full blown userspace (libdrm demos/programs do
not count) that uses the new interfaces.

I haven't made these rules, just a fool^Wguy that repeats them so that
people don't abuse them much. If in doubt check with Dave and Daniel V
- they had enough repeating these.

-Emil

[RFC 0/6] drm/fences: add in-fences to DRM

[Rob Clark]

On Mon, Mar 28, 2016 at 10:18 PM, Inki Dae  wrote:
>
> In addition, I wonder how explicit and implicit fences could coexist together.
> Rob said,
> "Implicit sync ofc remains the default, but userspace could opt-in to 
> explicit sync instead"
>
> This would mean that if we use explicit sync for user-space then it coexists 
> with implicit sync. However, these two sync fences can't see same DMA buffer 
> because explicit fence has a different file object from implicit one.
> So in this case, I think explicit fence would need to be hung up on the 
> reservation object of dmabuf object somehow. Otherwise, although they coexist 
> together, are these fences - explicit and implicit - used for differenct 
> purpose separately?
>

I'm not entirely sure about coexistance at the same time.  It ofc
shouldn't be a problem for one kernel to support both kinds of
userspace (pure explicit and pure implicit).  And how this would work
on kms atomic ioctl (compositor/consumer) side seems clear enough..
ie. some sort of flag, which if set user provides an explicit fence
fd, and if not set we fall back to current behaviour (ie. get fences
from resv object).

On the gpu/producer side, I think what makes sense is to both attach
the fence to the resv objects and (optionally, specified by an submit
ioctl flag) return a fence fd.  The other option is to add a new ioctl
to convert an internal per-ring fence/seqno (that is already returned
by submit ioctl) to a fence fd.. but I think that would end up with
duplicate 'struct fence' objects on the kernel side (not sure if that
would cause issues somehow), and might be unneeded since with
EGL_ANDROID_native_fence_sync since we should know before glFlush() is
called whether we want an fd or not.  But main thing I'm pondering
here is how to sanely support the old way of userspace gl driver
internal synchronization with new userspace on old kernel, but also
conditionally support EGL_ANDROID_native_fence_sync if you have a new
enough kernel.

BR,
-R

[RFC PATCH v1 0/4] Add Rockchip RGA support

[Emil Velikov]

Hi Yakir,

On 29 March 2016 at 12:40, Yakir Yang  wrote:
> Hi Emil,
>
> On 03/28/2016 08:21 PM, Emil Velikov wrote:
>>
>> On 22 March 2016 at 00:42, Heiko Stuebner  wrote:
>>>
>>> Hi Yakir,
>>>
>>> Am Montag, 21. März 2016, 20:17:46 schrieb Yakir Yang:

 On 03/21/2016 07:29 PM, Heiko Stübner wrote:
>
> Am Montag, 21. März 2016, 17:28:38 schrieb Yakir Yang:
>>
>> This patch set would add the RGA direct rendering based 2d graphics
>> acceleration module.
>
> very cool to see that.

 ;)

>> This patch set is based on git repository below:
>> git://people.freedesktop.org/~airlied/linux drm-next
>> commit id: 568d7c764ae01f3706085ac8f0d8a8ac7e826bd7
>>
>> And the RGA driver is based on Exynos G2D driver, it only manages the
>> command lists received from user, so user should make the command list
>> to data and registers needed by operation to use.
>>
>> I have prepared an userspace demo application for testing:
>> https://github.com/yakir-Yang/libdrm-rockchip
>>
>> That is a rockchip libdrm library, and I have write a simple test case
>> "rockchip_rga_test" that would test the below RGA features:
>> - solid
>> - copy
>> - rotation
>> - flip
>> - window clip
>> - dithering
>
> Did you submit your libdrm changes as well?
>
> Userspace-interfaces need to be stable so the other side must also get
> accepted - even before the kernel change if I remember correctly.

 Got it, and I just saw exynos_fimg2d already landed at mainline libdrm.
 But I don't find the way to submit patches to libdrm, would you like
 share some helps here ;)
>>>
>>> Looking at the libdrm sources on cgit.freedesktop.org, I did not find any
>>> specific manual on submitting patches.
>>>
>>> But looking at the dri-list archive, dri-devel at lists.freedesktop.org is
>>> the
>>> right list and looking at the libdrm history it looks like Emil Velikov
>>>  seems to be doing maintenance-stuff in libdrm.
>>> And as a 3rd recipient, please also include the linux-rockchip list.
>>>
>>> @Emil, please shout if I read that wrong :-)
>>>
>> You got it spot on Heiko. There are a few notes though...
>>
>> As one reuses the existing hardware/IP block, it would be better to
>> avoid copy/pasting code around.
>> Namely:
>>   - (if possible) factor out the exynos g2d kernel functionality to a
>> separate kernel module and wire up the rockhip (via dt ?) to use it
>>   - factor out the g2d specifics out of exynos_drm.h (into
>> exynos_g2d_drm.h perhaps ?) and make sure exynos_drm.h includes the
>> new header
>>   - if neither of these are possible, then please ensure that the new
>> header uses correct types (see the docs [1]), use MIT/X11 license (if
>> possible) and link where upstream userspace is happy with the
>> interface (ideally more than a simple test app like libdrm)
>
>
> Whops... you have provided the third choice, nice  :-D
>
> And I got little idea about license, where should I use the MIT/X11
> license, should I declare the MIT/X11 license in kernel uapi head
> file, but Andreas just remind that kernel do not allow to no GUN
> license. Or may be I can:
Now that's a lovely typo - (GNU vs GUN) :-)

But seriously - what makes you think that the kernel does not allow
MIT/X11 licensed code ? Most of the DRM subsystem uses it.

> 1. Use GUN license in kernel rockchip_drm.h uapi head file
> 2. Use MIT/X11 license in libdrm rockchip_drm.h head file.
>
I would suggest keeping the license the same in both places (the
libdrm ones should be a direct copy of the kernel one produced with
`make headers_install`), regardless of which one you opt for.

> And I don't understand the "link where upstream userspace is happy
> with the interface", could you reference small example here.
>
Already mentioned elsewhere but for posterity:

If designing a new interface one should provide a reference to a
maintained upstream project, where the design was approved. Reason
being is that unlike ChromeOS's kernel upstream one gets to keep its
interfaces forever. And yes, I realise that CrOS folks are trying
really hard to upstream things and use vanilla kernel.

Regards,
Emil

[PATCH] drm/core: Add drm_accurate_vblank_count_and_time.

[Maarten Lankhorst]

This function is useful for gen2 intel devices which have no frame
counter, but need a way to determine the current vblank count without
racing with the vblank interrupt handler.

intel_pipe_update_start checks if no vblank interrupt will occur
during vblank evasion, but cannot check whether the vblank handler has
run to completion. This function uses the timestamps to determine
when the last vblank has happened, and interpolates from there.

Cc: Mario Kleiner 
Cc: Ville Syrjälä 
Signed-off-by: Maarten Lankhorst 
---
Unfortunately only compile time tested, I don't have a gen2 to test with.

 drivers/gpu/drm/drm_irq.c | 90 +++
 include/drm/drmP.h|  2 ++
 2 files changed, 69 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 881c5a6c180c..44d8f9607ccd 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -155,24 +155,10 @@ static void drm_reset_vblank_timestamp(struct drm_device 
*dev, unsigned int pipe
spin_unlock(&dev->vblank_time_lock);
 }

-/**
- * drm_update_vblank_count - update the master vblank counter
- * @dev: DRM device
- * @pipe: counter to update
- *
- * Call back into the driver to update the appropriate vblank counter
- * (specified by @pipe).  Deal with wraparound, if it occurred, and
- * update the last read value so we can deal with wraparound on the next
- * call if necessary.
- *
- * Only necessary when going from off->on, to account for frames we
- * didn't get an interrupt for.
- *
- * Note: caller must hold dev->vbl_lock since this reads & writes
- * device vblank fields.
- */
-static void drm_update_vblank_count(struct drm_device *dev, unsigned int pipe,
-   unsigned long flags)
+static u32 __drm_accurate_vblank_count_and_time(struct drm_device *dev, 
unsigned int pipe,
+   const struct timeval *t_old,
+   unsigned long flags, u32 *pdiff,
+   struct timeval *tv_ret)
 {
struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
u32 cur_vblank, diff;
@@ -202,10 +188,8 @@ static void drm_update_vblank_count(struct drm_device 
*dev, unsigned int pipe,
/* trust the hw counter when it's around */
diff = (cur_vblank - vblank->last) & dev->max_vblank_count;
} else if (rc && framedur_ns) {
-   const struct timeval *t_old;
u64 diff_ns;

-   t_old = &vblanktimestamp(dev, pipe, vblank->count);
diff_ns = timeval_to_ns(&t_vblank) - timeval_to_ns(t_old);

/*
@@ -286,9 +270,13 @@ static void drm_update_vblank_count(struct drm_device 
*dev, unsigned int pipe,
  " current=%u, diff=%u, hw=%u hw_last=%u\n",
  pipe, vblank->count, diff, cur_vblank, vblank->last);

+   *pdiff = diff;
+   *tv_ret = t_vblank;
+
if (diff == 0) {
WARN_ON_ONCE(cur_vblank != vblank->last);
-   return;
+
+   return cur_vblank;
}

/*
@@ -298,9 +286,65 @@ static void drm_update_vblank_count(struct drm_device 
*dev, unsigned int pipe,
 * for now, to mark the vblanktimestamp as invalid.
 */
if (!rc && (flags & DRM_CALLED_FROM_VBLIRQ) == 0)
-   t_vblank = (struct timeval) {0, 0};
+   *tv_ret = (struct timeval) {0, 0};
+
+   return cur_vblank;
+}
+
+/**
+ * drm_accurate_vblank_count_and_time - retrieve the master vblank counter
+ * @crtc: which counter to retrieve
+ * @tv_ret: last time counter was updated
+ *
+ * This function is similar to @drm_update_vblank_count_and_time but
+ * this function interpolates to handle a race with vblank irq's, and
+ * is only useful for crtc's that have no hw vblank counter.
+ */
+
+u32 drm_accurate_vblank_count_and_time(struct drm_crtc *crtc,
+  struct timeval *tv_ret)
+{
+   struct drm_device *dev = crtc->dev;
+   u32 pdiff, old_vblank;
+   struct timeval tv_old = {};
+
+   WARN(dev->max_vblank_count, "This function is only useful when a hw 
counter is unavailable.");
+
+   old_vblank = drm_crtc_vblank_count_and_time(crtc, &tv_old);
+
+   __drm_accurate_vblank_count_and_time(dev, drm_crtc_index(crtc),
+&tv_old, 0, &pdiff, tv_ret);
+
+   return old_vblank + pdiff;
+}
+EXPORT_SYMBOL(drm_accurate_vblank_count_and_time);
+
+/**
+ * drm_update_vblank_count - update the master vblank counter
+ * @dev: DRM device
+ * @pipe: counter to update
+ *
+ * Call back into the driver to update the appropriate vblank counter
+ * (specified by @pipe).  Deal with wraparound, if it occurred, and
+ * update the last read value so we can deal with wraparound on the next
+ * call if necessary.
+ *
+ * Only necessary when going from off->on, 

[PATCH v4 RESEND 1/5] drm/dp_helper: Increase retry interval to 1000us

[Lyude Paul]

Yep, the rest of the patchset works fine without this patch

On Tue, 2016-03-29 at 10:27 +0200, Daniel Vetter wrote:
> On Mon, Mar 28, 2016 at 10:33:22AM -0400, Lyude wrote:
> > 
> > This is part of a patch series to migrate all of the workarounds for
> > commonly seen behavior from bad sinks in intel_dp_dpcd_read_wake() to
> > drm's DP helper.
> > 
> > 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 7d58f59..d1128fb 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -160,7 +160,7 @@ int drm_dp_bw_code_to_link_rate(u8 link_bw)
> >  }
> >  EXPORT_SYMBOL(drm_dp_bw_code_to_link_rate);
> >  
> > -#define AUX_RETRY_INTERVAL 500 /* us */
> > +#define AUX_RETRY_INTERVAL 1000 /* us */
> Was this to adapt to the msleep(1) in the i915 function? If so it's kinda
> wrong anyway, since an msleep(1) actually sleeps 1 jiffy, and on most
> systems that's a lot more than 1 ms. If it all still works, I'd just drop
> this patch here. I suspect that the magic is all in the more aggressive
> retrying and the throwaway read, not in how long we actually wait.
> 
> On patches 2-5: Reviewed-by: Daniel Vetter 
> 
> > 
> >  
> >  /**
> >   * DOC: dp helpers
> > -- 
> > 2.5.5
> > 
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
-- 
Cheers,
Lyude

[Intel-gfx] [PATCH 1/2] drm/i915: Call intel_dp_mst_resume() before resuming displays

[Lyude Paul]

bump

Could we get a reviewed-by for this patch? It's needed in addition to the patch
series I sent for removing intel_dp_dpcd_read_wake() for the T560 to have it's
monitors work properly on resume.

On Wed, 2016-03-16 at 17:49 -0400, Lyude Paul wrote:
> On Sun, 2016-03-13 at 19:45 +0100, Daniel Vetter wrote:
> > 
> > On Fri, Mar 11, 2016 at 10:57:01AM -0500, Lyude wrote:
> > > 
> > > 
> > > Since we need MST devices ready before we try to resume displays,
> > > calling this after intel_display_resume() can result in some issues with
> > > various laptop docks where the monitor won't turn back on after
> > > suspending the system.
> > > 
> > > This order was originally changed in
> > > 
> > >   commit e7d6f7d70829 ("drm/i915: resume MST after reading back hw state")
> > > 
> > > In order to fix some unclaimed register errors, however the actual cause
> > > of those has since been fixed.
> > > 
> > > CC: stable at vger.kernel.org
> > > Signed-off-by: Lyude 
> > Don't we need to first apply patch 2/2 to avoid breaking systems
> > in-between?
> > -Daniel
> AFAICT the warns don't appear even with this patch, so no.
> > 
> > 
> > > 
> > > 
> > > ---
> > >  drivers/gpu/drm/i915/i915_drv.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > > b/drivers/gpu/drm/i915/i915_drv.c
> > > index f357058..08854ae 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > @@ -761,12 +761,12 @@ static int i915_drm_resume(struct drm_device *dev)
> > >  dev_priv->display.hpd_irq_setup(dev);
> > >  spin_unlock_irq(&dev_priv->irq_lock);
> > >  
> > > + intel_dp_mst_resume(dev);
> > > +
> > >  drm_modeset_lock_all(dev);
> > >  intel_display_resume(dev);
> > >  drm_modeset_unlock_all(dev);
> > >  
> > > - intel_dp_mst_resume(dev);
> > > -
> > >  /*
> > >   * ... but also need to make sure that hotplug processing
> > >   * doesn't cause havoc. Like in the driver load code we don't
> > > -- 
> > > 2.5.0
> > > 
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx at lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
-- 
Cheers,
Lyude

[Bug 115011] [drm:radeon_acpi_init [radeon]] *ERROR* Cannot find a backlight controller

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

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

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

--- Comment #10 from Alex Deucher  ---
(In reply to Luya Tshimbalanga from comment #7)
> Created attachment 210281 [details]
> dmesg with 4.6.0-0.rc0.git13.1
> 
> dmesg report using latest git kernel i.e. 4.6.0-0. Same result:
> 
> [7.498283] [drm:radeon_acpi_init [radeon]] *ERROR* Cannot find a
> backlight controller

This message is harmless.  Your laptop has two GPUs.  The ATIF ACPI method is
used to notify the driver of backlight change events so the driver checks to
see if it exists.  Depending on the board configuration, the secondary GPU may
or may not have access to the backlight controller.  In this case it does not.

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

[PATCH] Revert "drm: Don't pass negative delta to ktime_sub_ns()"

[Imre Deak]

On Tue, 2016-03-29 at 13:12 +0200, Daniel Vetter wrote:
> This reverts commit e91abf80a0998f326107874c88d549f94839f13c.
> 
> Since
> 
> commit 24e4a8c3e8868874835b0f1ad6dd417341e99822
> Author: John Stultz 
> Date:   Wed Jul 16 21:03:53 2014 +
> 
>     ktime: Kill non-scalar ktime_t implementation for 2038
> 
> there is no longer a 32bit version that's unsigned, and we don't have
> to jump through ridiculous hoops to make the calculations correct.
> 
> I didn't look whether there's more of this pattern in the kernel.
> 
> Cc: John Stultz 
> Cc: Thomas Gleixner 
> Cc: Michel Dänzer 
> Cc: Imre Deak 
> Cc: Dave Airlie 
> Signed-off-by: Daniel Vetter 

Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/drm_irq.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index f77653562fac..4d06cf41df96 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -863,10 +863,7 @@ int drm_calc_vbltimestamp_from_scanoutpos(struct
> drm_device *dev,
>  /* Subtract time delta from raw timestamp to get final
>   * vblank_time timestamp for end of vblank.
>   */
> - if (delta_ns < 0)
> - etime = ktime_add_ns(etime, -delta_ns);
> - else
> - etime = ktime_sub_ns(etime, delta_ns);
> + etime = ktime_sub_ns(etime, delta_ns);
>  *vblank_time = ktime_to_timeval(etime);
>  
>  DRM_DEBUG_VBL("crtc %u : v 0x%x p(%d,%d)@ %ld.%ld -> %ld.%ld
> [e %d us, %d rep]\n",b

[PATCH 0/3] drm/exynos: Kconfig dependency fixes

[Javier Martinez Canillas]

Hello Seung-Woo,

On 03/29/2016 12:25 AM, Seung-Woo Kim wrote:
> Hello Javier,
> 
> On 2016년 03월 29일 11:41, Javier Martinez Canillas wrote:
>> Hello Seung-Woo,
>>
>> Thanks a lot for your feedback.
>>
>> On 03/28/2016 09:46 PM, Seung-Woo Kim wrote:
>>> Hi Javier,
>>>
>>> On 2016년 03월 29일 10:28, Javier Martinez Canillas wrote:
 Hello Inki,

 This patch series contains some fixes for the Kconfig symbol dependencies
 of the Exynos DRM driver. They make sure that the Exynos DRM components
 and the media platform drivers that makes use of the same HW IP block are
 not enabled at the same time.

 Best regards,
 Javier


 Javier Martinez Canillas (3):
   drm/exynos: Use VIDEO_SAMSUNG_S5P_G2D=n as G2D Kconfig dependency
   drm/exynos: Use VIDEO_SAMSUNG_EXYNOS_GSC=n as GSC Kconfig dependency
   drm/exynos: Make DRM_EXYNOS_FIMC depend on VIDEO_S5P_FIMC=n
>>>
>>> In G2D case, there is only one instance, but for the other cases, there
>>> are several instances and in my environment, I enable both drivers on
>>> v4l2 and drm FIMC/GSC.
>>>
>>> So, IMHO, the not-enabled v4l2 dependency is not really required for drm
>>> fimc and drm gsc.
>>>
>>
>> I'm confused, it was you who added the depends on !VIDEO_SAMSUNG_EXYNOS_GSC
>> for DRM_EXYNOS_GSC in commit aeefb36832e5 ("drm/exynos: gsc: add device tree
>> support and remove usage of static mappings").
> 
> Yes, you are right. Originally, my goal on the GSC was bringing optional
> flag for setting isp mode or wb mode like FIMC in tizen.org git tree.
> 
> https://review.tizen.org/git/?p=platform/kernel/linux-exynos.git;a=blobdiff;f=Documentation/devicetree/bindings/media/exynos5-gsc.txt;h=d526777a3abd04d244c46fdd729e3df93bb86917;hp=0604d42f38d1941526d47ad11a958a2a83797f97;hb=751cd6d88d9620c83042641b52fdd244408a3947;hpb=7c7ab44f86d64ba6a6733da8f201a26a6c0e807f
> 
> But only devicetree part of GSC was upstreamed and simultaneous enabling
> both v4l2 gsc and drm gsc driver is removed. The only reason I set both
> driver simultaneously was enabling video codec, exynos-mfc with gsc to
> convert RGB plane.
> 
> I know Marek already has plan to integrate yuv plane feature of GSC to
> DRM KMS. Also, for GSC, simultaneous setup is alredy remove, so your
> patch seems better.
>

Ok, thanks for the confirmation. So at least patch 1/3 and 3/3 are needed then.

>>
>> >From the commit message "The driver cannot be used simultaneously with V4L2
>> Mem2Mem GScaller driver thought". Did that assumption changed and the depend
>> should be removed then? or maybe I misunderstood what you meant.
>>
>> Now, I'm not really sure about FIMC either, it was feedback I got from this
>> patch [0]. Could you please take a look to that and let me know if enabling
>> these drivers simultaneously makes sense then?
> 
> About FIMC, there is still simultaneous setup for both v4l2 and drm
> driver with devicetree binding flags, samsung,isp-wb and samsung,lcd-wb.
> 
> If on the FIMC instance of dt node, samsung,lcd-wb is set, then drm
> driver is probed, otherwise v4l2 driver is probed.
> 

Interesting, I didn't know about these DT properties. I see that some FIMC nodes
are using both though like in arch/arm/boot/dts/exynos4x12.dtsi. Is that a bug?

So if both the DRM and V4L2 drivers can be enabled at the same time for FIMC,
then patch 3/3 should be dropped and instead the exynos_defconfig patch that
enables CONFIG_VIDEO_S5P_FIMC should be picked IMHO.

> Simultaneous FIMC driver is also only for RGB converting of video codec
> planes like GSC at least to me.
> 
> Marek, do you have any idea about the simultaneous setup for fimc and gsc?
> 
> Best Regards,
> - Seung-Woo Kim
> 
>>
>>> Best Regards,
>>> - Seung-Woo Kim
>>>

  drivers/gpu/drm/exynos/Kconfig | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

>>>
>>
>> [0]: https://lkml.org/lkml/2016/3/23/292
>>
>> Best regards,
>>
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

[Bug 94667] Artifacts on applications on discrete and kernel freezes

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

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

Vladislav Kamenev  changed:

   What|Removed |Added

 Attachment #122521|text/plain  |image/png
  mime type||

-- 
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/20160329/b40cb967/attachment.html>

[PATCH 06/10] x86/cpufeature: Kill cpu_has_clflush

[Borislav Petkov]

From: Borislav Petkov 

Use the fast variant in the DRM code.

Signed-off-by: Borislav Petkov 
Cc: dri-devel at lists.freedesktop.org
Cc: intel-gfx at lists.freedesktop.org
---
 arch/x86/include/asm/cpufeature.h  | 1 -
 arch/x86/kernel/cpu/intel.c| 2 +-
 arch/x86/kernel/tce_64.c   | 2 +-
 arch/x86/mm/pageattr.c | 2 +-
 drivers/gpu/drm/drm_cache.c| 6 +++---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
 6 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/arch/x86/include/asm/cpufeature.h 
b/arch/x86/include/asm/cpufeature.h
index 693b4aa43908..a75154232db5 100644
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -129,7 +129,6 @@ extern const char * const x86_bug_flags[NBUGINTS*32];
 #define cpu_has_aesboot_cpu_has(X86_FEATURE_AES)
 #define cpu_has_avxboot_cpu_has(X86_FEATURE_AVX)
 #define cpu_has_avx2   boot_cpu_has(X86_FEATURE_AVX2)
-#define cpu_has_clflushboot_cpu_has(X86_FEATURE_CLFLUSH)
 #define cpu_has_patboot_cpu_has(X86_FEATURE_PAT)
 #define cpu_has_xsave  boot_cpu_has(X86_FEATURE_XSAVE)
 #define cpu_has_xsaves boot_cpu_has(X86_FEATURE_XSAVES)
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 1f7fdb91a818..628a9f853b84 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -468,7 +468,7 @@ static void init_intel(struct cpuinfo_x86 *c)
set_cpu_cap(c, X86_FEATURE_PEBS);
}

-   if (c->x86 == 6 && cpu_has_clflush &&
+   if (c->x86 == 6 && boot_cpu_has(X86_FEATURE_CLFLUSH) &&
(c->x86_model == 29 || c->x86_model == 46 || c->x86_model == 47))
set_cpu_bug(c, X86_BUG_CLFLUSH_MONITOR);

diff --git a/arch/x86/kernel/tce_64.c b/arch/x86/kernel/tce_64.c
index ab40954e113e..f386bad0984e 100644
--- a/arch/x86/kernel/tce_64.c
+++ b/arch/x86/kernel/tce_64.c
@@ -40,7 +40,7 @@
 static inline void flush_tce(void* tceaddr)
 {
/* a single tce can't cross a cache line */
-   if (cpu_has_clflush)
+   if (boot_cpu_has(X86_FEATURE_CLFLUSH))
clflush(tceaddr);
else
wbinvd();
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index fb20c2ee0092..bbf462ff9745 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -1460,7 +1460,7 @@ static int change_page_attr_set_clr(unsigned long *addr, 
int numpages,
 * error case we fall back to cpa_flush_all (which uses
 * WBINVD):
 */
-   if (!ret && cpu_has_clflush) {
+   if (!ret && boot_cpu_has(X86_FEATURE_CLFLUSH)) {
if (cpa.flags & (CPA_PAGES_ARRAY | CPA_ARRAY)) {
cpa_flush_array(addr, numpages, cache,
cpa.flags, pages);
diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index 6743ff7dccfa..059f7c39c582 100644
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -72,7 +72,7 @@ drm_clflush_pages(struct page *pages[], unsigned long 
num_pages)
 {

 #if defined(CONFIG_X86)
-   if (cpu_has_clflush) {
+   if (static_cpu_has(X86_FEATURE_CLFLUSH)) {
drm_cache_flush_clflush(pages, num_pages);
return;
}
@@ -105,7 +105,7 @@ void
 drm_clflush_sg(struct sg_table *st)
 {
 #if defined(CONFIG_X86)
-   if (cpu_has_clflush) {
+   if (static_cpu_has(X86_FEATURE_CLFLUSH)) {
struct sg_page_iter sg_iter;

mb();
@@ -129,7 +129,7 @@ void
 drm_clflush_virt_range(void *addr, unsigned long length)
 {
 #if defined(CONFIG_X86)
-   if (cpu_has_clflush) {
+   if (static_cpu_has(X86_FEATURE_CLFLUSH)) {
const int size = boot_cpu_data.x86_clflush_size;
void *end = addr + length;
addr = (void *)(((unsigned long)addr) & -size);
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 1328bc5021b4..b845f468dd74 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -488,7 +488,7 @@ i915_gem_execbuffer_relocate_entry(struct 
drm_i915_gem_object *obj,
ret = relocate_entry_cpu(obj, reloc, target_offset);
else if (obj->map_and_fenceable)
ret = relocate_entry_gtt(obj, reloc, target_offset);
-   else if (cpu_has_clflush)
+   else if (static_cpu_has(X86_FEATURE_CLFLUSH))
ret = relocate_entry_clflush(obj, reloc, target_offset);
else {
WARN_ONCE(1, "Impossible case in relocation handling\n");
-- 
2.7.3

[PATCH] hsakmt: allow building with gcc 4.x

[Bridgman, John]

The hsakmt code requires c99 support, however gcc 4.x defaults to
c89 while gcc 5 defaults to c11. Adding this macro provides c99
support on older gcc while not forcing gcc 5 back from c11 to c99.

Signed-off-by: John Bridgman 
---
 configure.ac | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configure.ac b/configure.ac
index b8e9bea..8f32cbb 100644
--- a/configure.ac
+++ b/configure.ac
@@ -66,6 +66,7 @@ AC_CANONICAL_HOST
 AC_PROG_AWK
 test_CFLAGS=${CFLAGS+set} # We may override autoconf default CFLAGS.
 AC_PROG_CC
+AC_PROG_CC_STDC
 AC_PROG_INSTALL
 AC_PROG_LIBTOOL
 AC_PROG_MAKE_SET
-- 
1.9.1

i915 4.5 bugfix backport and release management issue?

[Andy Lutomirski]

On Tue, Mar 29, 2016 at 12:49 AM, Andy Lutomirski  
wrote:
> On Tue, Mar 29, 2016 at 12:43 AM, Daniel Vetter  
> wrote:
>> On Tue, Mar 29, 2016 at 4:39 AM, Andy Lutomirski  
>> wrote:
>>> AFAICT something got rather screwed up in i915 land for 4.5.
>>>
>>> $ git log --oneline --grep='Pretend cursor is always on' v4.5
>>> drivers/gpu/drm/i915/
>>> e2e407dc093f drm/i915: Pretend cursor is always on for ILK-style WM
>>> calculations (v2)
>>>
>>> $ git log --oneline --grep='Pretend cursor is always on' v4.6-rc1
>>> drivers/gpu/drm/i915/
>>> e2e407dc093f drm/i915: Pretend cursor is always on for ILK-style WM
>>> calculations (v2)
>>> b2435692dbb7 drm/i915: Pretend cursor is always on for ILK-style WM
>>> calculations (v2)
>>>
>>> The two patches there are almost, but not quite, the same thing, which
>>> makes me wonder how they both ended up in Linus' tree without an
>>> obvious merge conflict.
>>>
>>> I have no idea what caused this.  However, I think (on very little
>>> inspection, but it's consistent with problems I have with 4.5 on my
>>> laptop) that the first one is an *incorrect* fix for a regression in
>>> 4.5 and the second is a correct fix for the same regression.  4.6-rc1
>>> seems okay.
>>>
>>> I reported the regression and everyone involved has known about it for
>>> weeks.  Nonetheless, 4.5 final is busted.
>>
>> Quoting from e2e407dc093f
>>
>> "(cherry picked from commit b2435692dbb709d4c8ff3b2f2815c9b8423b72bb)"
>>
>> i.e. this is intentionally twice in the history. We started to soak
>> bugfixes in -next and then cherry pick them because we had too much
>> fun with things blowing up, and also too much fun with really messy
>> conflicts. It's not a botched patch in 4.5 or anything else nefarious
>> at all.
>
> Bah, sorry, I read it wrong.  They have the same final state but they
> were on different bases.  I somehow reversed this in my head and
> thought they had the same initial state and different final states.
>

Also, sorry for the excessive diatribe.  I plead sleepiness and
mis-reading of code.

--Andy

[PATCH 0/3 v2] Add I2S/ADV7511 audio support for ARC AXS10x boards

[Mark Brown]

On Mon, Mar 28, 2016 at 03:36:08PM +0100, Jose Abreu wrote:
> ARC AXS10x platforms consist of a mainboard with several peripherals.
> One of those peripherals is an HDMI output port controlled by the ADV7511
> transmitter.

I'm going to tell you the same thing I tell everyone else working on
HDMI audio integration: you all need to talk to each other and review
each other's code and unless there is a very good reason for it there
should be at least some code sharing.  For example take a look at the
patches Jyri Sarha has been posting recently.  I don't have detailed
knowledge of HDMI and the range of hardware that's out there for it but
I am seeing a number of different people posting patch serieses that
look a lot like each other and like they should be sharing things.

Please also try to keep your CC lists reasonable, the set of people
you've copied on this stuff is enormous and I'm having trouble seeing
why a lot of tehm are included.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160329/e963f8cf/attachment.sig>

[PATCH 1/3 v2] drm/i2c/adv7511: Add audio support

[Archit Taneja]

On 3/29/2016 4:22 PM, Jose Abreu wrote:
> Hi Archit,
>
> On 29-03-2016 09:05, Archit Taneja wrote:
>> Hi,
>>
>> On 03/28/2016 08:06 PM, Jose Abreu wrote:
>>> This patch adds audio support for the ADV7511 HDMI transmitter
>>> using ALSA SoC.
>>>
>>> The code was ported from Analog Devices linux tree from
>>> commit 1770c4a1e32b ("Merge remote-tracking branch
>>> 'xilinx/master' into xcomm_zynq"), which is available at:
>>>  - https://github.com/analogdevicesinc/linux/
>>>
>>> The main core file was renamed from adv7511.c to adv7511_core.c
>>> so that audio and video compile into a single adv7511.ko module
>>> and to keep up with Analog Devices kernel tree.
>>>
>>> The audio can be disabled using menu-config so it is possible
>>> to use only video mode.
>>>
>>> The HDMI mode is automatically started at boot and the audio
>>> (when enabled) registers as a codec into ALSA.
>>
>> Is there a reason why we set the mode to HDMI at probe itself?
>> Shouldn't it be okay to set the mode later once we read the
>> EDID off the panel?
>>
>> Some more comments below.
>>
>
> Well, when I was using this in kernel 3.18 (with an older version of the 
> driver)
> I noticed that DVI mode was being used even when HDMI was connected so I 
> forced
> the driver to start in HDMI mode. There were some changes in the driver so it 
> is
> possible that this is no longer needed. Should I drop it?

Mode selection works fine with ADV7533 on a 4.5 kernel. I'm assuming it
should work out of the box for ADV7511 too. We should drop this.


>
>>>
>>> SPDIF DAI format was also added to ASoC as it is required
>>> by adv7511 audio.
>>>
>>> Signed-off-by: Jose Abreu 
>>> ---
>>>
>>> No changes v1 -> v2.
>>>
>>>drivers/gpu/drm/i2c/Kconfig |   11 +
>>>drivers/gpu/drm/i2c/Makefile|2 +
>>>drivers/gpu/drm/i2c/adv7511.c   | 1024 
>>> ---
>>>drivers/gpu/drm/i2c/adv7511.h   |   41 ++
>>>drivers/gpu/drm/i2c/adv7511_audio.c |  310 +++
>>>drivers/gpu/drm/i2c/adv7511_core.c  | 1005 
>>> ++
>>>include/sound/soc-dai.h |1 +
>>>7 files changed, 1370 insertions(+), 1024 deletions(-)
>>>delete mode 100644 drivers/gpu/drm/i2c/adv7511.c
>>>create mode 100644 drivers/gpu/drm/i2c/adv7511_audio.c
>>>create mode 100644 drivers/gpu/drm/i2c/adv7511_core.c
>>
>> 
>>
>>> +
>>> +static int adv7511_probe(struct i2c_client *i2c, const struct i2c_device_id
>>> *id)
>>> +{
>>> +struct adv7511_link_config link_config;
>>> +struct adv7511 *adv7511;
>>> +struct device *dev = &i2c->dev;
>>> +unsigned int val;
>>> +int ret;
>>> +
>>> +if (!dev->of_node)
>>> +return -EINVAL;
>>> +
>>> +adv7511 = devm_kzalloc(dev, sizeof(*adv7511), GFP_KERNEL);
>>> +if (!adv7511)
>>> +return -ENOMEM;
>>> +
>>> +adv7511->powered = false;
>>> +adv7511->status = connector_status_disconnected;
>>> +
>>> +ret = adv7511_parse_dt(dev->of_node, &link_config);
>>> +if (ret)
>>> +return ret;
>>> +
>>> +/*
>>> + * The power down GPIO is optional. If present, toggle it from active 
>>> to
>>> + * inactive to wake up the encoder.
>>> + */
>>> +adv7511->gpio_pd = devm_gpiod_get_optional(dev, "pd", GPIOD_OUT_HIGH);
>>> +if (IS_ERR(adv7511->gpio_pd))
>>> +return PTR_ERR(adv7511->gpio_pd);
>>> +
>>> +if (adv7511->gpio_pd) {
>>> +mdelay(5);
>>> +gpiod_set_value_cansleep(adv7511->gpio_pd, 0);
>>> +}
>>> +
>>> +adv7511->regmap = devm_regmap_init_i2c(i2c, &adv7511_regmap_config);
>>> +if (IS_ERR(adv7511->regmap))
>>> +return PTR_ERR(adv7511->regmap);
>>> +
>>> +ret = regmap_read(adv7511->regmap, ADV7511_REG_CHIP_REVISION, &val);
>>> +if (ret)
>>> +return ret;
>>> +dev_dbg(dev, "Rev. %d\n", val);
>>> +
>>> +ret = regmap_register_patch(adv7511->regmap, adv7511_fixed_registers,
>>> +ARRAY_SIZE(adv7511_fixed_registers));
>>> +if (ret)
>>> +return ret;
>>> +
>>> +regmap_write(adv7511->regmap, ADV7511_REG_EDID_I2C_ADDR, 
>>> edid_i2c_addr);
>>> +regmap_write(adv7511->regmap, ADV7511_REG_PACKET_I2C_ADDR,
>>> + packet_i2c_addr);
>>> +regmap_write(adv7511->regmap, ADV7511_REG_CEC_I2C_ADDR, cec_i2c_addr);
>>> +adv7511_packet_disable(adv7511, 0x);
>>> +
>>> +adv7511->i2c_main = i2c;
>>> +adv7511->i2c_edid = i2c_new_dummy(i2c->adapter, edid_i2c_addr >> 1);
>>> +if (!adv7511->i2c_edid)
>>> +return -ENOMEM;
>>> +
>>> +if (i2c->irq) {
>>> +init_waitqueue_head(&adv7511->wq);
>>> +
>>> +ret = devm_request_threaded_irq(dev, i2c->irq, NULL,
>>> +adv7511_irq_handler,
>>> +IRQF_ONESHOT, dev_name(dev),
>>> +adv7511);
>>> +if (ret)
>>> +goto err_i2c_unregister_device;
>>> +}
>>> +
>>> +/* CEC is unused for now */
>>>

[PATCH] dma-buf: Update docs for SYNC ioctl

[Tiago Vignatti]

On 03/29/2016 06:47 AM, David Herrmann wrote:
> Hi
>
> On Mon, Mar 28, 2016 at 9:42 PM, Tiago Vignatti
>  wrote:
>> Do we have an agreement here after all? David? I need to know whether this
>> fixup is okay to go cause I'll need to submit to Chrome OS then.
>
> Sure it is fine. The code is already there, we cannot change it.

ah true. Only now that I've noticed it's already in Linus tree. Thanks 
anyway!

Tiago

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

[Russell King - ARM Linux]

On Tue, Mar 29, 2016 at 10:54:08AM +0200, Takashi Iwai wrote:
> On Thu, 17 Mar 2016 13:22:29 +0100,
> Jyri Sarha wrote:
> > 
> > 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 
> 
> This patch looks almost good to me, but...
> 
> > @@ -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;
> 
> ... this change is silently slipped in.  It should be mentioned in the
> changelog, or split to another patch, as this is basically an
> orthogonal change.

Does it even make sense - AES doesn't have support for 32-bit samples,
it can only ever truncate them down to 24-bit.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[Bug 115011] [drm:radeon_acpi_init [radeon]] *ERROR* Cannot find a backlight controller

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

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

--- Comment #11 from Luya Tshimbalanga  ---
(In reply to Alex Deucher from comment #10)
> (In reply to Luya Tshimbalanga from comment #7)
> > Created attachment 210281 [details]
> > dmesg with 4.6.0-0.rc0.git13.1
> > 
> > dmesg report using latest git kernel i.e. 4.6.0-0. Same result:
> > 
> > [7.498283] [drm:radeon_acpi_init [radeon]] *ERROR* Cannot find a
> > backlight controller
> 
> This message is harmless.  Your laptop has two GPUs.  The ATIF ACPI method
> is used to notify the driver of backlight change events so the driver checks
> to see if it exists.  Depending on the board configuration, the secondary
> GPU may or may not have access to the backlight controller.  In this case it
> does not.

Thank you for explaining the meaning of the message related to dual GPUs. It
will be nice to improve the mechanism where one of GPU cannot access to the
backlight controller.

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

[PATCH 2/3 v2] ASoC: dwc: Add I2S HDMI audio support

[Mark Brown]

On Mon, Mar 28, 2016 at 03:36:10PM +0100, Jose Abreu wrote:
> HDMI audio support was added to the AXS board using an
> I2S cpu driver and a custom platform driver.
> 
> The platform driver supports two channels @ 16 bits with
> rates 32k, 44.1k and 48k. ALSA Simple audio card is used to
> glue the cpu, platform and codec driver (adv7511).

>  sound/soc/dwc/Kconfig  |   1 +
>  sound/soc/dwc/designware_i2s.c | 385 
> +++--

Your changelog appears to describe the writing of a machine driver but
this is a large patch adding code to an I2S controller driver.  This
means I can't review your patch since I can't tell what it is supposed
to do.  If you've added functionality to this driver you need to send
one or more patches each of which adds a single feature to the driver
together with a changelog which describes what that feature is.

Glancing at the patch I'm not 100% sure that the features you're adding
are part of the Synopsis device but I'm not entirely sure.

>  2 files changed, 373 insertions(+), 13 deletions(-)
> 
> diff --git a/sound/soc/dwc/Kconfig b/sound/soc/dwc/Kconfig
> index d50e085..bc3fae7 100644
> --- a/sound/soc/dwc/Kconfig
> +++ b/sound/soc/dwc/Kconfig
> @@ -2,6 +2,7 @@ config SND_DESIGNWARE_I2S
>   tristate "Synopsys I2S Device Driver"
>   depends on CLKDEV_LOOKUP
>   select SND_SOC_GENERIC_DMAENGINE_PCM
> + select SND_SIMPLE_CARD

No, this doesn't make sense - the fact that someone has used a Synopsis
I2S controller doesn't mean that they have a system which uses
simple-card.  If the user wants to use simple-card they need to enable
it separately, this is the same pattern we follow for all CPU controller
drivers.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160329/4f161eee/attachment.sig>

[PATCH 2/3 v2] ASoC: dwc: Add I2S HDMI audio support

[Mark Brown]

On Tue, Mar 29, 2016 at 07:03:01PM +0100, Jose Abreu wrote:

> The major part of this patch is the adding of an ALSA platform driver so that
> audio comes out of the box in AXS boards but we also added functionalities to
> the i2s driver and performed one bug fix related with the mask/unmask of
> interrupts. I will split the patches but they will depend on each other.

If you want to add a new platform driver you need to add a new platform
driver, not shove the code into an existing driver for a seperate IP.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160329/020e90b1/attachment.sig>

[PATCH v3 13/19] drm: sun4i: Add DT bindings documentation

[Rob Herring]

On Tue, Mar 29, 2016 at 12:33:14PM +0200, Maxime Ripard wrote:
> Hi Rob,
> 
> On Fri, Mar 25, 2016 at 09:11:18AM -0500, Rob Herring wrote:
> > On Wed, Mar 23, 2016 at 05:38:36PM +0100, Maxime Ripard wrote:
> > > The display pipeline of the Allwinner A10 is involving several loosely
> > > coupled components.
> > > 
> > > Add a documentation for the bindings.
> > > 
> > > Signed-off-by: Maxime Ripard 
> > > ---
> > >  .../bindings/display/sunxi/sun4i-drm.txt   | 254 
> > > +
> > >  1 file changed, 254 insertions(+)
> > >  create mode 100644 
> > > Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > > 
> > > diff --git 
> > > a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
> > > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > > new file mode 100644
> > > index ..378edb919eae
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > > @@ -0,0 +1,254 @@
> > > +Allwinner A10 Display Pipeline
> > > +==
> > > +
> > > +The Allwinner A10 Display pipeline is composed of several components
> > > +that are going to be documented below:
> > > +
> > > +TV Encoder
> > > +--
> > > +
> > > +The TV Encoder supports the composite and VGA output. It is one end of
> > > +the pipeline.
> > > +
> > > +Required properties:
> > > + - compatible: value should be "allwinner,sun4i-a10-tv-encoder".
> > > + - reg: base address and size of memory-mapped region
> > > + - clocks: the clocks driving the TV encoder
> > > + - resets: phandle to the reset controller driving the encoder
> > > +
> > > +- ports: A ports node with endpoint definitions as defined in
> > > +  Documentation/devicetree/bindings/media/video-interfaces.txt. The
> > > +  first port should be the input endpoint.
> > > +
> > > +TCON
> > > +
> > > +
> > > +The TCON acts as a timing controller for RGB, LVDS and TV interfaces.
> > > +
> > > +Required properties:
> > > + - compatible: value should be "allwinner,sun5i-a13-tcon".
> > > + - reg: base address and size of memory-mapped region
> > > + - interrupts: interrupt associated to this IP
> > > + - clocks: phandles to the clocks feeding the TCON. Three are needed:
> > > +   - 'ahb': the interface clocks
> > > +   - 'tcon-ch0': The clock driving the TCON channel 0
> > > +   - 'tcon-ch1': The clock driving the TCON channel 1
> > > + - resets: phandles to the reset controllers driving the encoder
> > > +   - "lcd": the reset line for the TCON channel 0
> > > +
> > > + - clock-names: the clock names mentioned above
> > > + - reset-names: the reset names mentioned above
> > > + - clock-output-names: Name of the pixel clock created
> > > +
> > > +- ports: A ports node with endpoint definitions as defined in
> > > +  Documentation/devicetree/bindings/media/video-interfaces.txt. The
> > > +  first port should be the input endpoint, the second one the output
> > 
> > The example shows 2 output endpoints. Your diagram shows up to 4 
> > outputs. The number should be how ever many could coexist in a given h/w 
> > design. In other words, I'm assuming all 4 can't be used simultaneously, 
> > but can all 4 be wired up in a h/w design and switched in s/w? 
> > 
> > Just be clear on the numbering.
> 
> Yes, each TCON has two channels, the first one being usable for
> RGB/LVDS, the second one for TV/VGA. HDMI is basically implemented
> using an in-SoC RGB-to-HDMI bridge, so it would use the first channel
> as well.

So I think you should have 2 ports (1 per channel) and then 2 endpoints 
for 1st (RGB/LVDS/ExtBridge and HDMI) and 1 endpoint (TV/VGA) for 2nd 
port.

> I don't see how a particular design could use several devices on the
> first channel, because they would share the same timings, and I don't
> really see how it would work out.
> 
> > > +
> > > +Endpoints optional property:
> > > +  - allwinner,panel: boolean to indicate that the endpoint is a panel
> > 
> > This can be determined by the endpoint not being TV Encoder (or HDMI).
> 
> It wouldn't really scale if you start to consider the bridges
> too. Then, you would have to duplicate and maintain a list of all the
> bridges supported in Linux and a list of all the panels supported in
> Linux, and try to match that to see if it's a panel, a bridge or an
> element of our pipeline.

So my concern is that no one else has needed this, so why do you? Based 
on the above, you know that a panel is always connected to port 0, 
endpoint 0. If it is an external bridge instead, then that can be 
determined when the bridge driver is bound.


> > > +Display Engine Backend
> > > +--
> > > +
> > > +The display engine backend exposes layers and sprites to the
> > > +system.
> > > +
> > > +Required properties:
> > > +  - compatible: value must be one of:
> > > +* allwinner,sun5i-a13-display-backend
> > > +  - reg: base address and size of the memory-mapped region.
> > > +  - clocks: phandles to the clocks

[Bug 93652] Random crashes/freezing with amdgpu Fury X mesa 11.1

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

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

Sebastian Jensen  changed:

   What|Removed |Added

Version|11.0|git

-- 
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/20160329/d11c352f/attachment.html>

[PATCH] hsakmt: allow building with gcc 4.x

[Emil Velikov]

Hi John,

On 29 March 2016 at 16:39, Bridgman, John  wrote:
> The hsakmt code requires c99 support, however gcc 4.x defaults to
> c89 while gcc 5 defaults to c11. Adding this macro provides c99
> support on older gcc while not forcing gcc 5 back from c11 to c99.
>
> Signed-off-by: John Bridgman 
> ---
>  configure.ac | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/configure.ac b/configure.ac
> index b8e9bea..8f32cbb 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -66,6 +66,7 @@ AC_CANONICAL_HOST
>  AC_PROG_AWK
>  test_CFLAGS=${CFLAGS+set} # We may override autoconf default CFLAGS.
>  AC_PROG_CC
> +AC_PROG_CC_STDC
Some versions of autoconf have AC_PROG_CC_STDC as obsolete, while
others will silently fall back to C89 (according to the autoconf ML).

I've used AC_PROG_CC_C99 and $ac_cv_prog_cc_c99 for libdrm [1]. Did
not have old enough compiler to test it against though :-\

-Emil

[1] 
https://cgit.freedesktop.org/mesa/drm/commit/?id=e59f00fb43c2b83bdadb17fa35c3018f817a3806

[PATCH v5 4/5] drm/dp_helper: Perform throw-away read before actual read in drm_dp_dpcd_read()

[Lyude]

This is part of a patch series to migrate all of the workarounds for
commonly seen behavior from bad sinks in intel_dp_dpcd_read_wake() to drm's
DP helper.

Some sinks will just return garbage for the first aux tranaction they
receive when coming out of sleep mode, so we need to perform an additional
read before the actual read to workaround this.

Changes since v5
- If the throwaway read in drm_dp_dpcd_read() fails, return the error
  from that instead of continuing. This follows the same logic we do in
  drm_dp_dpcd_access() (e.g. the error from the first transaction may
  differ from the errors that proceeding attempts might return).

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

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 86656ca..daf261d 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -244,6 +244,18 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 
request,
 ssize_t drm_dp_dpcd_read(struct drm_dp_aux *aux, unsigned int offset,
 void *buffer, size_t size)
 {
+   int ret;
+
+   /*
+* Sometimes we just get the same incorrect byte repeated over the
+* entire buffer. Doing one throw away read initially seems to "solve"
+* it.
+*/
+   ret = drm_dp_dpcd_access(aux, DP_AUX_NATIVE_READ, DP_DPCD_REV, buffer,
+1);
+   if (ret != 1)
+   return ret;
+
return drm_dp_dpcd_access(aux, DP_AUX_NATIVE_READ, offset, buffer,
  size);
 }
-- 
2.5.5

[PATCH] drm/i915/vlv: Enable/disable VGA hotplugging properly

[Lyude]

On Valleyview, VGA hotplugging is controlled through a seperate register
than everything else, VLV_ADPA, which must be explicitly set.

While VGA hotplugging worked(ish) before, it looks like that was mainly
because we'd unintentionally enable it in
valleyview_crt_detect_hotplug() when we did a force trigger. This
doesn't work reliably enough because whenever the display powerwell on
vlv gets disabled, the values set in VLV_ADPA get cleared and
consequently VGA hotplugging gets disabled. This causes bugs such as one
we found on an Intel NUC, where doing the following sequence of
hotplugs:

- Disconnect all monitors
- Connect VGA
- Disconnect VGA
- Connect HDMI

Would result in hotplugging getting disabled, due to the display
powerwells getting toggled in the process of connecting HDMI.

CC: stable at vger.kernel.org
Signed-off-by: Lyude 
---
 drivers/gpu/drm/i915/i915_irq.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 5aa4239..60592a4 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3611,6 +3611,7 @@ static void valleyview_display_irqs_install(struct 
drm_i915_private *dev_priv)
 {
u32 pipestat_mask;
u32 iir_mask;
+   u32 adpa_reg;
enum pipe pipe;

pipestat_mask = PIPESTAT_INT_STATUS_MASK |
@@ -3627,6 +3628,12 @@ static void valleyview_display_irqs_install(struct 
drm_i915_private *dev_priv)
for_each_pipe(dev_priv, pipe)
  i915_enable_pipestat(dev_priv, pipe, pipestat_mask);

+   if (IS_VALLEYVIEW(dev_priv)) {
+   adpa_reg = I915_READ(VLV_ADPA);
+   adpa_reg |= ADPA_CRT_HOTPLUG_ENABLE;
+   I915_WRITE(VLV_ADPA, adpa_reg);
+   }
+
iir_mask = I915_DISPLAY_PORT_INTERRUPT |
   I915_DISPLAY_PIPE_A_EVENT_INTERRUPT |
   I915_DISPLAY_PIPE_B_EVENT_INTERRUPT;
@@ -3645,8 +3652,15 @@ static void valleyview_display_irqs_uninstall(struct 
drm_i915_private *dev_priv)
 {
u32 pipestat_mask;
u32 iir_mask;
+   u32 adpa_reg;
enum pipe pipe;

+   if (IS_VALLEYVIEW(dev_priv)) {
+   adpa_reg = I915_READ(VLV_ADPA);
+   adpa_reg &= ~ADPA_CRT_HOTPLUG_ENABLE;
+   I915_WRITE(VLV_ADPA, adpa_reg);
+   }
+
iir_mask = I915_DISPLAY_PORT_INTERRUPT |
   I915_DISPLAY_PIPE_A_EVENT_INTERRUPT |
   I915_DISPLAY_PIPE_B_EVENT_INTERRUPT;
-- 
2.5.5

[Bug 94708] Open source radeon drivers not working properly with Radeon HD 8550M

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

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

Marko Tikvic  changed:

   What|Removed |Added

   Priority|medium  |high

-- 
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/20160329/e3a28426/attachment.html>

[PATCH] hsakmt: allow building with gcc 4.x

[Bridgman, John]

>-Original Message-
>From: Emil Velikov [mailto:emil.l.velikov at gmail.com]
>Sent: Tuesday, March 29, 2016 4:08 PM
>To: Bridgman, John
>Cc: dri-devel at lists.freedesktop.org
>Subject: Re: [PATCH] hsakmt: allow building with gcc 4.x
>
>Hi John,
>
>On 29 March 2016 at 16:39, Bridgman, John 
>wrote:
>> The hsakmt code requires c99 support, however gcc 4.x defaults to
>> c89 while gcc 5 defaults to c11. Adding this macro provides c99
>> support on older gcc while not forcing gcc 5 back from c11 to c99.
>>
>> Signed-off-by: John Bridgman 
>> ---
>>  configure.ac | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/configure.ac b/configure.ac index b8e9bea..8f32cbb 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -66,6 +66,7 @@ AC_CANONICAL_HOST
>>  AC_PROG_AWK
>>  test_CFLAGS=${CFLAGS+set} # We may override autoconf default CFLAGS.
>>  AC_PROG_CC
>> +AC_PROG_CC_STDC
>Some versions of autoconf have AC_PROG_CC_STDC as obsolete, while
>others will silently fall back to C89 (according to the autoconf ML).
>
>I've used AC_PROG_CC_C99 and $ac_cv_prog_cc_c99 for libdrm [1]. Did not
>have old enough compiler to test it against though :-\

Hi Emil,

I looked at both AC_PROG_CC_STDC and _C99 options, but found more anecdotal 
concerns about _C99 so went with _STDC for the patch... but after sending it 
out I realized that the concerns I found seemed to apply to both STDC and C99 
equally. I read about _STDC being obsoleted but also noticed that it was 
"unobsoleted" in autoconf 2.60, the same release where AC_PROG_CC_C99 was 
apparently added.

I did run across a 2013 email suggesting that _C99 and _STDC were *both* going 
to be obsoleted, but was not able to find any further discussion and did not 
see any mention of either macro in subsequent autoconf release notes. 

Anyways, if you are using AC_PROG_CC_C99 in libdrm then I think it makes sense 
to do the same in libhsakmt. I will spin a v2 of the patch.

Thanks,
John
>
>-Emil
>
>[1]
>https://cgit.freedesktop.org/mesa/drm/commit/?id=e59f00fb43c2b83bdadb1
>7fa35c3018f817a3806

[PATCH] hsakmt: allow building with gcc 4.x v2

[Bridgman, John]

The hsakmt code requires C99 compiler support, however gcc 4.x
defaults to C89 (gcc 5 defaults to C11). v2 patch copies code
from libdrm, using AC_PROG_CC_C99 and checking success.

v1 used AC_PROG_CC_STDC and did not check C99 was enabled.

Signed-off-by: John Bridgman 
---
 configure.ac | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/configure.ac b/configure.ac
index b8e9bea..0111067 100644
--- a/configure.ac
+++ b/configure.ac
@@ -66,6 +66,12 @@ AC_CANONICAL_HOST
 AC_PROG_AWK
 test_CFLAGS=${CFLAGS+set} # We may override autoconf default CFLAGS.
 AC_PROG_CC
+AC_PROG_CC_C99
+
+if test "x$ac_cv_prog_cc_c99" = xno; then
+   AC_MSG_ERROR([Building hsakmt requires C99 enabled compiler])
+fi
+
 AC_PROG_INSTALL
 AC_PROG_LIBTOOL
 AC_PROG_MAKE_SET
-- 
1.9.1

[Bug 94667] Artifacts on applications on discrete and kernel freezes

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

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

--- Comment #11 from Vladislav Kamenev  ---
Made a video demonstrating the artifacts.
As u can see its somehow like driver sends "old frame" to the screen (X-COM at
loading and WoW at gameplay)
https://youtu.be/DnC_UD0ZCTc

-- 
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/20160329/8cb87564/attachment.html>

[Bug 94667] Artifacts on applications on discrete and kernel freezes

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

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

Vladislav Kamenev  changed:

   What|Removed |Added

 Depends on||92258

-- 
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/20160329/95fbf774/attachment-0001.html>

[Bug 92258] [regression] Opening menu in Steam running via DRI_PRIME with enabled DRI3 could lead to radeon kernel module crash

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

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

Vladislav Kamenev  changed:

   What|Removed |Added

 Blocks||94667

-- 
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/20160329/d8be9ceb/attachment.html>

[PATCH 2/3 v5] drm: atmel_hldc: Use generic drm_connector_register_all() helper

[Alexey Brodkin]

This driver used to have its own implementation of connector_register_all()
which actually was taken as a prototype of drm_connector_register_all().

Now when drm_connector_register_all() exists reusing it here.

And while at it replace atmel_hlcdc_dc_connector_unplug_all()
with generic drm_connector_unregister_all().

Signed-off-by: Alexey Brodkin 
Cc: Daniel Vetter 
Cc: David Airlie 
Acked-by: Boris Brezillon 
---

No changes v4 -> v5.

No changes v3 -> v4.

Changes v2 -> v3:
 * Updated title with capital after colon
 * Added ack from Boris

No changes v1 -> v2.

 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 39 ++--
 1 file changed, 2 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 3d8d164..1c537e4 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -584,41 +584,6 @@ static void atmel_hlcdc_dc_unload(struct drm_device *dev)
destroy_workqueue(dc->wq);
 }

-static int atmel_hlcdc_dc_connector_plug_all(struct drm_device *dev)
-{
-   struct drm_connector *connector, *failed;
-   int ret;
-
-   mutex_lock(&dev->mode_config.mutex);
-   list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
-   ret = drm_connector_register(connector);
-   if (ret) {
-   failed = connector;
-   goto err;
-   }
-   }
-   mutex_unlock(&dev->mode_config.mutex);
-   return 0;
-
-err:
-   list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
-   if (failed == connector)
-   break;
-
-   drm_connector_unregister(connector);
-   }
-   mutex_unlock(&dev->mode_config.mutex);
-
-   return ret;
-}
-
-static void atmel_hlcdc_dc_connector_unplug_all(struct drm_device *dev)
-{
-   mutex_lock(&dev->mode_config.mutex);
-   drm_connector_unplug_all(dev);
-   mutex_unlock(&dev->mode_config.mutex);
-}
-
 static void atmel_hlcdc_dc_lastclose(struct drm_device *dev)
 {
struct atmel_hlcdc_dc *dc = dev->dev_private;
@@ -736,7 +701,7 @@ static int atmel_hlcdc_dc_drm_probe(struct platform_device 
*pdev)
if (ret)
goto err_unload;

-   ret = atmel_hlcdc_dc_connector_plug_all(ddev);
+   ret = drm_connector_register_all(ddev);
if (ret)
goto err_unregister;

@@ -758,7 +723,7 @@ static int atmel_hlcdc_dc_drm_remove(struct platform_device 
*pdev)
 {
struct drm_device *ddev = platform_get_drvdata(pdev);

-   atmel_hlcdc_dc_connector_unplug_all(ddev);
+   drm_connector_unregister_all(ddev);
drm_dev_unregister(ddev);
atmel_hlcdc_dc_unload(ddev);
drm_dev_unref(ddev);
-- 
2.5.0

[PATCH 2/3 v2] ASoC: dwc: Add I2S HDMI audio support

[Jose Abreu]

Hi Mark,

On 29-03-2016 18:31, Mark Brown wrote:
> On Mon, Mar 28, 2016 at 03:36:10PM +0100, Jose Abreu wrote:
>> HDMI audio support was added to the AXS board using an
>> I2S cpu driver and a custom platform driver.
>>
>> The platform driver supports two channels @ 16 bits with
>> rates 32k, 44.1k and 48k. ALSA Simple audio card is used to
>> glue the cpu, platform and codec driver (adv7511).
>>  sound/soc/dwc/Kconfig  |   1 +
>>  sound/soc/dwc/designware_i2s.c | 385 
>> +++--
> Your changelog appears to describe the writing of a machine driver but
> this is a large patch adding code to an I2S controller driver.  This
> means I can't review your patch since I can't tell what it is supposed
> to do.  If you've added functionality to this driver you need to send
> one or more patches each of which adds a single feature to the driver
> together with a changelog which describes what that feature is.
>
> Glancing at the patch I'm not 100% sure that the features you're adding
> are part of the Synopsis device but I'm not entirely sure.
>

The major part of this patch is the adding of an ALSA platform driver so that
audio comes out of the box in AXS boards but we also added functionalities to
the i2s driver and performed one bug fix related with the mask/unmask of
interrupts. I will split the patches but they will depend on each other.

>>  2 files changed, 373 insertions(+), 13 deletions(-)
>>
>> diff --git a/sound/soc/dwc/Kconfig b/sound/soc/dwc/Kconfig
>> index d50e085..bc3fae7 100644
>> --- a/sound/soc/dwc/Kconfig
>> +++ b/sound/soc/dwc/Kconfig
>> @@ -2,6 +2,7 @@ config SND_DESIGNWARE_I2S
>>  tristate "Synopsys I2S Device Driver"
>>  depends on CLKDEV_LOOKUP
>>  select SND_SOC_GENERIC_DMAENGINE_PCM
>> +select SND_SIMPLE_CARD
> No, this doesn't make sense - the fact that someone has used a Synopsis
> I2S controller doesn't mean that they have a system which uses
> simple-card.  If the user wants to use simple-card they need to enable
> it separately, this is the same pattern we follow for all CPU controller
> drivers.
>

I will remove this.

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

Best regards,
Jose Miguel Abreu
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160329/5c00d945/attachment-0001.html>

[PATCH 0/3 v5] drm: Introduce drm_connector_register_all() helper

[Alexey Brodkin]

As a pair to already existing drm_connector_unplug_all()
(which we'll rename in this series to drm_connector_unregister_all())
we're adding generic implementation of what is already done in some drivers
for registering all connectors.

After implementation of that new helper we're updating 2 drivers
that used to use it's own implementation:
 [1] atmel_hlcdc
 [2] rcar_du

Other drivers still use load() callback and so should be first modified so
their load() gets called from their probe() explicitly.

Build- and run-tested on yet to be upstreamed ARC PGU (part of AXS10x board).

Changes v4 -> v5:
 * Added missing mutex unlock on a fail path in drm_connector_register_all()
   Thanks David for his attention and patience!

Changes v3 -> v4:
 * Based on current drm-intel/topic/drm-misc
   It's now on commit 6c87e5c3ec6db052f3744804a517b6fb003906e1
   And since thet new base already has
   "drm: Rename drm_connector_unplug_all() to drm_connector_unregister_all()"
   this series now only includes 3 subsequent patches.

 * In drm_connector_register_all() fail path which calls unregister_all()
   is moved outside of loop&locked section (as suggested by Daniel)

Changes v2 -> v3:
 * Added acks for 1, 3 and 4 patches
 * Updated kerneldoc descriptins of both register_ and unregister_all()
 * Updated commit messages (mostly spellos and grammar issues)

Changes v1 -> v2:
 * Rename drm_connector_unplug_all() to drm_connector_unregister_all()
 * Use drm_for_each_connector() instead of list_for_each_entry()
 * Updated kerneldoc for drm_dev_register()

Cc: Daniel Vetter 
Cc: David Airlie 
Cc: Boris Brezillon 
Cc: Laurent Pinchart 
Cc: linux-renesas-soc at vger.kernel.org
Cc: David Herrmann 

Alexey Brodkin (3):
  drm: Introduce drm_connector_register_all() helper
  drm: atmel_hldc: Use generic drm_connector_register_all() helper
  drm: rcar-du: Use generic drm_connector_register_all() helper

 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 39 ++-
 drivers/gpu/drm/drm_crtc.c   | 40 
 drivers/gpu/drm/drm_drv.c|  6 -
 drivers/gpu/drm/rcar-du/rcar_du_drv.c|  9 +--
 include/drm/drm_crtc.h   |  3 ++-
 5 files changed, 50 insertions(+), 47 deletions(-)

-- 
2.5.0

[PATCH 1/3 v5] drm: Introduce drm_connector_register_all() helper

[Alexey Brodkin]

As a pair to already existing drm_connector_unregister_all() we're adding
generic implementation of what is already done in some drivers.

Once this helper is implemented we'll be ready to switch existing
driver-specific implementations with the generic one.

Signed-off-by: Alexey Brodkin 
Cc: Daniel Vetter 
Cc: David Airlie 
Cc: David Herrmann 
---

Changes v4 -> v5:
 * Added missing mutex unlock on a fail path in drm_connector_register_all().
   Thanks David for his attention and patience!

Changes v3 -> v4:
 * In drm_connector_register_all() fail path which calls unregister_all()
   is moved outside of loop&locked section (as suggested by Daniel)

Changes v2 -> v3:
 * Updated title with capital after colon
 * Simplified failure path with direct and unconditional invocation of
   unregister_all()
 * Updated kerneldoc description of the drm_connector_register_all()

Changes v1 -> v2:
 * Rename drm_connector_unplug_all() to drm_connector_unregister_all()
 * Use drm_for_each_connector() instead of list_for_each_entry()
 * Updated kerneldoc for drm_dev_register()

 drivers/gpu/drm/drm_crtc.c | 40 
 drivers/gpu/drm/drm_drv.c  |  6 +-
 include/drm/drm_crtc.h |  3 ++-
 3 files changed, 47 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 7675826..af6e7ae 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1079,6 +1079,46 @@ void drm_connector_unregister(struct drm_connector 
*connector)
 EXPORT_SYMBOL(drm_connector_unregister);

 /**
+ * drm_connector_register_all - register all connectors
+ * @dev: drm device
+ *
+ * This function registers all connectors in sysfs and other places so that
+ * userspace can start to access them. Drivers can call it after calling
+ * drm_dev_register() to complete the device registration, if they don't call
+ * drm_connector_register() on each connector individually.
+ *
+ * When a device is unplugged and should be removed from userspace access,
+ * call drm_connector_unregister_all(), which is the inverse of this
+ * function.
+ *
+ * Returns:
+ * Zero on success, error code on failure.
+ */
+int drm_connector_register_all(struct drm_device *dev)
+{
+   struct drm_connector *connector;
+   int ret;
+
+   mutex_lock(&dev->mode_config.mutex);
+
+   drm_for_each_connector(connector, dev) {
+   ret = drm_connector_register(connector);
+   if (ret)
+   goto err;
+   }
+
+   mutex_unlock(&dev->mode_config.mutex);
+
+   return 0;
+
+err:
+   mutex_unlock(&dev->mode_config.mutex);
+   drm_connector_unregister_all(dev);
+   return ret;
+}
+EXPORT_SYMBOL(drm_connector_register_all);
+
+/**
  * drm_connector_unregister_all - unregister connector userspace interfaces
  * @dev: drm device
  *
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 167c8d3..2c9a2b6 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -715,7 +715,11 @@ EXPORT_SYMBOL(drm_dev_unref);
  *
  * Register the DRM device @dev with the system, advertise device to user-space
  * and start normal device operation. @dev must be allocated via 
drm_dev_alloc()
- * previously.
+ * previously. Right after drm_dev_register() the driver should call
+ * drm_connector_register_all() to register all connectors in sysfs. This is
+ * a separate call for backward compatibility with drivers still using
+ * the deprecated ->load() callback, where connectors are registered from 
within
+ * the ->load() callback.
  *
  * Never call this twice on any device!
  *
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 12f2bd4..6231f6c 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -2253,7 +2253,8 @@ void drm_connector_unregister(struct drm_connector 
*connector);

 extern void drm_connector_cleanup(struct drm_connector *connector);
 extern unsigned int drm_connector_index(struct drm_connector *connector);
-/* helper to unregister all connectors from sysfs for device */
+/* helpers to {un}register all connectors from sysfs for device */
+extern int drm_connector_register_all(struct drm_device *dev);
 extern void drm_connector_unregister_all(struct drm_device *dev);

 extern int drm_bridge_add(struct drm_bridge *bridge);
-- 
2.5.0

[PATCH 3/3 v5] drm: rcar-du: Use generic drm_connector_register_all() helper

[Alexey Brodkin]

Now that a generic drm_connector_register_all() helper exists we may safely
substitute it for the driver-specific implementation of connectors plugging
in sysfs.

Signed-off-by: Alexey Brodkin 
Cc: Daniel Vetter 
Cc: David Airlie 
Cc: linux-renesas-soc at vger.kernel.org
Acked-by: Laurent Pinchart 
---

No changes v4 -> v5.

No changes v3 -> v4.

Changes v2 -> v3:
 * Updated title with capital after colon
 * Updated commit message with fixes of spellos and grammar issues
 * Added ack from Laurent

No changes v1 -> v2.

 drivers/gpu/drm/rcar-du/rcar_du_drv.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 644db36..0f251dc 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -361,14 +361,7 @@ static int rcar_du_probe(struct platform_device *pdev)
if (ret)
goto error;

-   mutex_lock(&ddev->mode_config.mutex);
-   drm_for_each_connector(connector, ddev) {
-   ret = drm_connector_register(connector);
-   if (ret < 0)
-   break;
-   }
-   mutex_unlock(&ddev->mode_config.mutex);
-
+   ret = drm_connector_register_all(ddev);
if (ret < 0)
goto error;

-- 
2.5.0

[PATCH 1/3 v2] drm/i2c/adv7511: Add audio support

[Jose Abreu]

Hi Archit,

On 29-03-2016 09:05, Archit Taneja wrote:
> Hi,
>
> On 03/28/2016 08:06 PM, Jose Abreu wrote:
>> This patch adds audio support for the ADV7511 HDMI transmitter
>> using ALSA SoC.
>>
>> The code was ported from Analog Devices linux tree from
>> commit 1770c4a1e32b ("Merge remote-tracking branch
>> 'xilinx/master' into xcomm_zynq"), which is available at:
>> - https://github.com/analogdevicesinc/linux/
>>
>> The main core file was renamed from adv7511.c to adv7511_core.c
>> so that audio and video compile into a single adv7511.ko module
>> and to keep up with Analog Devices kernel tree.
>>
>> The audio can be disabled using menu-config so it is possible
>> to use only video mode.
>>
>> The HDMI mode is automatically started at boot and the audio
>> (when enabled) registers as a codec into ALSA.
>
> Is there a reason why we set the mode to HDMI at probe itself?
> Shouldn't it be okay to set the mode later once we read the
> EDID off the panel?
>
> Some more comments below.
>

Well, when I was using this in kernel 3.18 (with an older version of the driver)
I noticed that DVI mode was being used even when HDMI was connected so I forced
the driver to start in HDMI mode. There were some changes in the driver so it is
possible that this is no longer needed. Should I drop it?

>>
>> SPDIF DAI format was also added to ASoC as it is required
>> by adv7511 audio.
>>
>> Signed-off-by: Jose Abreu 
>> ---
>>
>> No changes v1 -> v2.
>>
>>   drivers/gpu/drm/i2c/Kconfig |   11 +
>>   drivers/gpu/drm/i2c/Makefile|2 +
>>   drivers/gpu/drm/i2c/adv7511.c   | 1024 
>> ---
>>   drivers/gpu/drm/i2c/adv7511.h   |   41 ++
>>   drivers/gpu/drm/i2c/adv7511_audio.c |  310 +++
>>   drivers/gpu/drm/i2c/adv7511_core.c  | 1005 
>> ++
>>   include/sound/soc-dai.h |1 +
>>   7 files changed, 1370 insertions(+), 1024 deletions(-)
>>   delete mode 100644 drivers/gpu/drm/i2c/adv7511.c
>>   create mode 100644 drivers/gpu/drm/i2c/adv7511_audio.c
>>   create mode 100644 drivers/gpu/drm/i2c/adv7511_core.c
>
> 
>
>> +
>> +static int adv7511_probe(struct i2c_client *i2c, const struct i2c_device_id
>> *id)
>> +{
>> +struct adv7511_link_config link_config;
>> +struct adv7511 *adv7511;
>> +struct device *dev = &i2c->dev;
>> +unsigned int val;
>> +int ret;
>> +
>> +if (!dev->of_node)
>> +return -EINVAL;
>> +
>> +adv7511 = devm_kzalloc(dev, sizeof(*adv7511), GFP_KERNEL);
>> +if (!adv7511)
>> +return -ENOMEM;
>> +
>> +adv7511->powered = false;
>> +adv7511->status = connector_status_disconnected;
>> +
>> +ret = adv7511_parse_dt(dev->of_node, &link_config);
>> +if (ret)
>> +return ret;
>> +
>> +/*
>> + * The power down GPIO is optional. If present, toggle it from active to
>> + * inactive to wake up the encoder.
>> + */
>> +adv7511->gpio_pd = devm_gpiod_get_optional(dev, "pd", GPIOD_OUT_HIGH);
>> +if (IS_ERR(adv7511->gpio_pd))
>> +return PTR_ERR(adv7511->gpio_pd);
>> +
>> +if (adv7511->gpio_pd) {
>> +mdelay(5);
>> +gpiod_set_value_cansleep(adv7511->gpio_pd, 0);
>> +}
>> +
>> +adv7511->regmap = devm_regmap_init_i2c(i2c, &adv7511_regmap_config);
>> +if (IS_ERR(adv7511->regmap))
>> +return PTR_ERR(adv7511->regmap);
>> +
>> +ret = regmap_read(adv7511->regmap, ADV7511_REG_CHIP_REVISION, &val);
>> +if (ret)
>> +return ret;
>> +dev_dbg(dev, "Rev. %d\n", val);
>> +
>> +ret = regmap_register_patch(adv7511->regmap, adv7511_fixed_registers,
>> +ARRAY_SIZE(adv7511_fixed_registers));
>> +if (ret)
>> +return ret;
>> +
>> +regmap_write(adv7511->regmap, ADV7511_REG_EDID_I2C_ADDR, edid_i2c_addr);
>> +regmap_write(adv7511->regmap, ADV7511_REG_PACKET_I2C_ADDR,
>> + packet_i2c_addr);
>> +regmap_write(adv7511->regmap, ADV7511_REG_CEC_I2C_ADDR, cec_i2c_addr);
>> +adv7511_packet_disable(adv7511, 0x);
>> +
>> +adv7511->i2c_main = i2c;
>> +adv7511->i2c_edid = i2c_new_dummy(i2c->adapter, edid_i2c_addr >> 1);
>> +if (!adv7511->i2c_edid)
>> +return -ENOMEM;
>> +
>> +if (i2c->irq) {
>> +init_waitqueue_head(&adv7511->wq);
>> +
>> +ret = devm_request_threaded_irq(dev, i2c->irq, NULL,
>> +adv7511_irq_handler,
>> +IRQF_ONESHOT, dev_name(dev),
>> +adv7511);
>> +if (ret)
>> +goto err_i2c_unregister_device;
>> +}
>> +
>> +/* CEC is unused for now */
>> +regmap_write(adv7511->regmap, ADV7511_REG_CEC_CTRL,
>> + ADV7511_CEC_CTRL_POWER_DOWN);
>> +
>> +adv7511_power_off(adv7511);
>> +
>> +i2c_set_clientdata(i2c, adv7511);
>> +
>> +#ifdef CONFIG_DRM_I2C_ADV7511_AUDIO
>> +adv7511_audio_init(&i2c->dev);
>> +#endif
>
> If we intend to have more audio funcs being used by the core in

blank screen on boot with i915/DRM_FBDEV_EMULATION

[Florian Zumbiehl]

Hi,

> FBDEV_EMULATION vs. I915_FBDEV is probably a read herring, more likely is
> that for some odd reason the very first modeset fails. Once X has
> resurrect the screen, can you then switch to fbcon? Also please check in
> /sys/class/vtconsole whether the fbdev driver is loaded and bound (check
> the name and bind files). And make sure there's that dmesg still says it
> initialized the "inteldrmfb" driver.

Trying to collect that information actually solved the problem: fbcon
didn't actually get loaded during boot, only the graphics drivers, which
caused the screen to go blank, loading fbcon happened only when starting
the X server ... seems weird to me, but I guess there is some non-obvious
logic behind that, and in any case it seems to be a change in behaviour.
Well, thanks for the pointer anyway, I guess! ;-)

Now, while at it: I also have a bunch of WARN_ONs and ERRORs happening (the
former primarily when an Xv window disappears from the screen, it seems,
the latter primarily during boot), which don't seem to have any immediate
negative effects at the surface, like this:

| [   14.815467] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU 
pipe A FIFO underrun
| [   14.815642] [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* 
pipe B underrun
| [   14.815806] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU 
pipe B FIFO underrun
| [   14.823686] [drm] initialized overlay support
| [   14.873165] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU 
pipe A FIFO underrun

| [ 2520.457732] WARNING: CPU: 0 PID: 3193 at 
drivers/gpu/drm/i915/i915_gem.c:4508 i915_gem_free_object+0x277/0x280 [i915]()
| [ 2520.457736] WARN_ON(obj->frontbuffer_bits)

Also, I have occasional X server crashes (every few weeks or so) which
started with 4.1.9, I think (I had 3.11.0 before that), and I had some kind
of problem with Xv not working anymore until reboot with 4.1.9 which hasn't
happened with 4.4.5 yet ... do you think any of those would be worth
further investigation? If so, any suggestions as to how to split it all
into separate issues/how to go about it?

Regards, Florian

[PATCH 0/3 v5] drm: Introduce drm_connector_register_all() helper

[Alexey Brodkin]

Hi Boris,

On Tue, 2016-03-29 at 14:43 +0200, Boris Brezillon wrote:
> Hi Alexey,
> 
> On Tue, 29 Mar 2016 13:22:49 +0300
> Alexey Brodkin  wrote:
> 
> > 
> > As a pair to already existing drm_connector_unplug_all()
> > (which we'll rename in this series to drm_connector_unregister_all())
> > we're adding generic implementation of what is already done in some drivers
> > for registering all connectors.
> > 
> > After implementation of that new helper we're updating 2 drivers
> > that used to use it's own implementation:
> >  [1] atmel_hlcdc
> >  [2] rcar_du
> > 
> > Other drivers still use load() callback and so should be first modified so
> > their load() gets called from their probe() explicitly.
> > 
> > Build- and run-tested on yet to be upstreamed ARC PGU (part of AXS10x 
> > board).
> > 
> > Changes v4 -> v5:
> >  * Added missing mutex unlock on a fail path in 
> > drm_connector_register_all()
> >    Thanks David for his attention and patience!
> > 
> > Changes v3 -> v4:
> >  * Based on current drm-intel/topic/drm-misc
> >    It's now on commit 6c87e5c3ec6db052f3744804a517b6fb003906e1
> >    And since thet new base already has
> >    "drm: Rename drm_connector_unplug_all() to 
> > drm_connector_unregister_all()"
> >    this series now only includes 3 subsequent patches.
> > 
> >  * In drm_connector_register_all() fail path which calls unregister_all()
> >    is moved outside of loop&locked section (as suggested by Daniel)
> > 
> > Changes v2 -> v3:
> >  * Added acks for 1, 3 and 4 patches
> >  * Updated kerneldoc descriptins of both register_ and unregister_all()
> >  * Updated commit messages (mostly spellos and grammar issues)
> > 
> > Changes v1 -> v2:
> >  * Rename drm_connector_unplug_all() to drm_connector_unregister_all()
> >  * Use drm_for_each_connector() instead of list_for_each_entry()
> >  * Updated kerneldoc for drm_dev_register()
> > 
> > Cc: Daniel Vetter 
> > Cc: David Airlie 
> > Cc: Boris Brezillon 
> Next time, can you please send all the patches of the series, not
> only the cover letter.

Sure.

It would be so much more convenient if git may add all people mentioned
in any patch of series to Cc list for all other patches (+ cover letter).
Without that feature one has to add all people in Cc explicitly in each patch.

-Alexey

[PATCH] drm/atmel: Fixup drm_connector_/unplug/unregister/_all

[Alexey Brodkin]

Hi Daniel,

On Tue, 2016-03-29 at 14:21 +0200, Daniel Vetter wrote:
> Accidentally fell through the cracks in
> 
> commit 6c87e5c3ec6db052f3744804a517b6fb003906e1
> Author: Alexey Brodkin 
> Date:   Wed Mar 23 11:42:54 2016 +0300
> 
>     drm: Rename drm_connector_unplug_all() to 
> drm_connector_unregister_all()
> 
> despite that Boris acked that patch.
> 
> Cc: Boris Brezillon 
> Cc: Alexey Brodkin 
> Acked-by: Boris Brezillon 
> Reported-by: kbuild test robot 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> index 3d8d16402d07..8ab4318e57a1 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> @@ -615,7 +615,7 @@ err:
>  static void atmel_hlcdc_dc_connector_unplug_all(struct drm_device *dev)
>  {
>  mutex_lock(&dev->mode_config.mutex);
> - drm_connector_unplug_all(dev);
> + drm_connector_unregister_all(dev);
>  mutex_unlock(&dev->mode_config.mutex);
>  }

Isn't done in my "[PATCH 2/3 v5] drm: atmel_hldc: Use generic 
drm_connector_register_all() helper"?

-Alexey