"Fixes" for page flipping under PRIME on AMD & nouveau

[Mario Kleiner]

On 08/18/2016 09:21 PM, Marek Olšák wrote:
> On Thu, Aug 18, 2016 at 4:23 AM, Michel Dänzer  wrote:
>> Maybe the rasterization as two triangles results in bad PCIe bandwidth
>> utilization. Using the asynchronous DMA engine for these transfers would
>> probably be ideal, but having the 3D engine rasterize a single rectangle
>> (either using the rectangle primitive or a large triangle with scissor)
>> might already help.
>
> There is only one thing that's bad for PCIe when the surface is
> linear: the 3D engine. Disabling all but the first shader engine and
> all but the first 2 RBs should improve performance for blits from VRAM
> to GTT. The closed driver does that, but I don't remember if the
> destination must be linear, must be in GTT, or both. In any case, SDMA
> should still be the best for VRAM->GTT blits.
>
> Marek
>

Friday evening education question:

So if you have multiple render backends active they compete for PCIe bus 
access and some kind of "trashing" happens in the arbitration, 
drastically reducing the bandwidth?

thanks,
-mario

"Fixes" for page flipping under PRIME on AMD & nouveau

[Mario Kleiner]

On 08/18/2016 04:32 AM, Michel Dänzer wrote:
> On 18/08/16 08:51 AM, Mario Kleiner wrote:
>>
>> That's what the ati-ddx/amdgpu-ddx does at the moment, as it detects the
>> mismatch in tiling flags and uses the DRI3/Present copy path instead of
>> the pageflip path. The problem is that the servers Present
>> implementation doesn't request a vsync'ed start of the copy operation [...]
>
> It waits for vblank before starting the copy.
>

Yes, a vblank event triggers the present_execute in the server. But all 
the latency from vblank event dispatch to the copy command packet 
hitting the gpu is still way too bad to avoid tearing. I tried again and 
couldn't find a single intel/amd/nvidia gpu here that doesn't tear more 
or less badly depending on load with DRI3/Present Copyswaps. Even 
tearfree wouldn't be good enough for my kind of applications as crucial 
timing/timestamps could still be off frequently by at least 1 frame.

>
>> There is this other approach from NVidia's Alex Goins for their
>> proprietary driver, whose patches landed in the X-Server 1.19 master
>> branch a couple of weeks ago. I haven't read his patches in detail yet,
>> and i so far couldn't successfully test them with the reference
>> implementation in modesetting ddx 1.19. Afaik there the display gpu
>> exports a pair of scanout friendly, page flipping compatible dmabufs (i
>> assume linear, contiguous, accessible by the display engines),
>
> FWIW, that wouldn't be possible with our "older" GPUs which can't scan
> out from GTT: A BO can be either shared with another GPU or scanout
> friendly, not both at the same time.
>

Ok, good to know.

>
>> and the offload gpu imports those and renders into them. That saves
>> one extra copy, so should be somewhat more efficient.
>
> Using two shared buffers actually isn't as efficient as possible wrt
> inter-GPU bandwidth.
>

Out of interest, why? You'd have only one detiling copy VRAM -> RAM? Or 
is it about switching some kind of GTT mappings with two buffers that is 
inefficient?

>
>> Setting it up seems to be more involved and less flexible though. So far
>> i couldn't make it work here for testing. Maybe bugs, maybe mistakes on
>> my side, maybe i just have the wrong hardware for it.
>
> Yeah, my impression has been it's a rather complicated solution geared
> towards the Intel iGPU + proprietary nVidia use case.
>
>

Setting up output source/output sink is not fun, as i learned now, 
rather clumsy and complex compared to render offload. I hope the real 
thing will come with some fool-proof one-click setup GUI, otherwise i 
don't have great hopes, given the technical skill level of my users. I 
still didn't manage to get it working, not even with the new Nvidia 
proprietary beta drivers on a real Optimus laptop.

-mario

"Fixes" for page flipping under PRIME on AMD & nouveau

[Mario Kleiner]

To pick this up again after a week of manic testing :)

On 08/18/2016 04:23 AM, Michel Dänzer wrote:
> On 18/08/16 01:12 AM, Mario Kleiner wrote:
>>
>> Intel as display gpu + nouveau for render offload worked nicely
>> on intel-ddx with page flipping, proper timing, dmabuf fence sync
>> and all.
>
> How about with AMD instead of nouveau in this case?
>

I don't have any real AMD Enduro laptop with either Intel + AMD or AMD + 
AMD atm., so i tested with my hacked up setups, but there things look 
very good:

a) A standard PC with Intel Haswell + AMD Tonga Pro R9 380. Seems to 
work correctly, page-flipping used, no visual artifacts or other 
problems, my measurement equipment also shows perfect timing and no 
glitches. Performance is very good, even without Marek's recent SDMA + 
PRIME patch series. Seems though with his patches some of the many 
criterions for using it doesn't get satisfied so it uses a fallback path 
on my machine.

One thing that confuses me so far is that visual results and measurment 
suggest it works nicely, properly serializing the rendering/detiling 
blit and the pageflip. But when i ftrace the Intel drivers 
reservation_object_wait_timeout_rcu() call where it normally waits for 
the dmabuf fence to complete then i never see it blocking for more than 
a few dozen microseconds, and i couldn't find any other place where it 
blocks on detiling blit completion yet. Iow. it seems to work correctly 
in practice, but i don't know where it actually blocks. Could also be 
that the flip work func in intels driver just executes after the 
detiling blit has already completed.

b) A MacPro with dual Radeon HD-5770 and NVidia GeForce, and my pageflip 
hacks applied. I ported Marek's Mesa SDMA patch to r600, and with that i 
get very good performance for AMD Evergreen as renderoffload gpu both 
for the NVidia + AMD and AMD + AMD combo. So this solved the performance 
problems on the older gpus. I assume Intel + old radeon-kms would just 
behave equally well. So thanks Marek, that was perfect!

I guess that means we are really good now wrt. renderoffload whenever an 
Intel iGPU is used for display, regardless if nouveau or AMD is used as 
dGPU :)

>
>> Turns out that prime + page flipping currently doesn't work
>> on nouveau and amd. The first offload rendered images from
>> the imported dmabufs show up properly, but then the display
>> is stuck alternating between the first two or three rendered
>> frames.
>>
>> The problem is that during the pageflip ioctl we pin the
>> dmabuf into VRAM in preparation for scanout, then unpin it
>> when we are done with it at next flip, but the buffer stays
>> in the VRAM memory domain.
>
> Sounds like you found a bug here: BOs which are being shared between
> different GPUs should always be pinned to GTT, moving them to VRAM (and
> consequently the page flip) should fail.
>

Seems so, although i hoped i was fixing a bug, not exploiting a 
loophole. In practice i haven't observed trouble with the hack so far. I 
havent't looked deeply enough into how the dma api below dmabuf 
operates, so this is just guesswork, but i suspect the reason that this 
doesn't blow up in an obvious way is that if the render offload gpu 
exports the dmabuf then the pages get pinned/locked into system RAM, so 
the pages can't move around or get paged out to swap, as long as the 
dmabuf stays exported. When the dmabuf importing AMD or nouveau display 
gpu then moves the bo from GTT to VRAM (or pseudo-moves it back with my 
hack) all that changes is some pin refcount for the RAM pages, but the 
refcount always stays non-zero and system RAM isn't freed or moved 
around during the session. I just wonder if this bug couldn't somehow be 
turned into a proper feature?

I'm tempted to keep my patches as a temporary stop gap measure in some 
kernel on GitHub, so my users could use them to get NVidia+NVidia or at 
least old AMD+AMD setups with radeon-kms + ati-ddx working well enough 
for their research work until some proper solution comes around. But if 
you think there is some major way how this could blow up, corrupt data, 
hang/crash during normal use then better not. I don't know how many of 
my users have such systems, as my advice to them so far was to "stay the 
hell away from anything with hybrid graphics/Optimus/Enduro in its name 
if they value their work". Now i could change my purchase advice to 
"anything hybrid with a Intel iGPU is probably ok in terms of 
correctness/timing/performance for not too demanding performance needs".

> The latest versions of DCE support scanning out from GTT, so that might
> be a good solution at least for Carrizo and newer APUs, not sure it
> makes sense for dGPUs though.

That would be good to have. But that means DCE-11 or later only? What is 
the constraint on older parts, does it need contiguous memory? I 
personally don't care about the dGPU case, i only use these dGPUs for 
testing because i don't have access to any real Enduro laptops with 

[PATCH v2 2/7] drm/tilcdc: Add blue-and-red-crossed devicetree property

[Jyri Sarha]

On 08/26/16 15:51, Rob Herring wrote:
>> --- a/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
>> > +++ b/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
>> > @@ -17,6 +17,8 @@ Optional properties:
>> > the lcd controller.
>> >   - max-pixelclock: The maximum pixel clock that can be supported
>> > by the lcd controller in KHz.
>> > + - blue-and-red-crossed: Boolean property, set this of blue and red wires
>> > +   for LCD_DATA are crossed for 24-bit RGB support (and 16-bit BGR mode). 
>> > [1]
> Doesn't this need to be blue-and-red-straight for compatibility?
> 

There is no way to be backward compatible with all am3 based devices.
This choice keeps the compatibility with Beaglebone-Black as far as it
can be kept and it is more logical choice for the binding. After all BBB
is way more common device than am335x-evm and am335x-evmsk are together.

I don't think there is any problems with the boards that have dts file
in the mainline source tree, like these three boards, as if the user
uses the latest mainline kernel, he probably uses the latest dtb file too.

The problem is the custom boards with custom dts files. I can not think
of any way to deal with this problem while still being 100% compatible
with all the dtb out there. This default setting is compatible with
standard colour wiring that does not take the colour errata into account.

BR,
Jyri

Plan to support Rockchip VPU in DRM, is it a good idea

[Randy Li]

On 08/26/2016 06:56 PM, Hans Verkuil wrote:
> On 08/26/2016 12:05 PM, Randy Li wrote:
>>
>> On 08/26/2016 05:34 PM, Hans Verkuil wrote:
>>> Hi Randi,
>>>
>>> On 08/26/2016 04:13 AM, Randy Li wrote:
 Hello,
 We always use some kind of hack work to make our Video Process
 Unit(Multi-format Video Encoder/Decoder) work in kernel. From a
 customize driver(vpu service) to the customize V4L2 driver. The V4L2
 subsystem is really not suitable for the stateless Video process or it
 could make driver too fat.
 After talking to some kindness Intel guys and moving our userspace
 library to VA-API driver, I find the DRM may the good choice for us.
 But I don't know whether it is welcome to to submit a video driver in
 DRM subsystem?
 Also our VPU(Video process unit) is not just like the Intel's, we
 don't have VCS, we based on registers to set the encoder/decoder. I
 think we may need a lots of IOCTL then. Also we do have a IOMMU in VPU
 but also not a isolated memory for VPU, I don't know I should use TT
 memory or GEM memory.
 I am actually not a member of the department in charge of VPU, and I
 am just beginning to learning DRM(thank the help from Intel again), I am
 not so good at memory part as well(I am more familiar with CMA not the
 IOMMU way), I may need know guide about the implementations when I am
 going to submit driver, I hope I could get help from someone.

>>> It makes no sense to do this in the DRM subsystem IMHO. There are already
>>> quite a few HW codecs implemented in the V4L2 subsystem and more are in the
>>> pipeline. Putting codec support in different subsystems will just make
>>> userspace software much harder to write.
>>>
>>> One of the codecs that was posted to linux-media was actually from Rockchip:
>>>
>>> https://lkml.org/lkml/2016/2/29/861
>>>
>>> There is also a libVA driver (I think) that sits on top of it:
>>>
>>> https://github.com/rockchip-linux/rockchip-va-driver/tree/v4l2-libvpu
>> It is old version, I am the author of this
>> https://github.com/rockchip-linux/rockchip-va-driver
>>> For the Allwinner a patch series was posted yesterday:
>>>
>>> https://lkml.org/lkml/2016/8/25/246
>>>
>>> They created a pretty generic libVA userspace that looks very promising at
>>> first glance.
>>>
>>> What these have in common is that they depend on the Request API and Frame 
>>> API,
>>> neither of which has been merged. The problem is that the Request API 
>>> requires
>>> more work since not only controls have to be part of a request, but also 
>>> formats,
>>> selection rectangles, and even dynamic routing changes. While that is not 
>>> relevant
>>> for codecs, it is relevant for Android CameraHAL in general and complex 
>>> devices
>>> like Google's Project Ara.
>> Actually just as the Intel did, our hardware decoder/encoder need full
>> settings for them, most of them are relevant to the codec. You may
>> notice that there is four extra control need to be set before. If the
>> libvpu(a helper library we offered to parse each slice to generate
>> decoder settings) is remove(in process now, only three decoder settings
>> can't got from VA-API directly), it would be more clearly.
>> We really a lots decoder settings information to make the decoder work.
>>> This is being worked on, but it is simply not yet ready. The core V4L2 
>>> developers
>>> involved in this plan to discuss this on the Monday before the ELCE in 
>>> Berlin,
>>> to see if we can fast track this work somehow so this support can be merged.
>>>
>> I am glad to hear that. I hope that I could have an opportunity to show
>> our problems.
>>> If there are missing features in V4L2 (other that the two APIs discussed 
>>> above)
>>> that prevent you from creating a good driver, then please discuss that with 
>>> us.
>>> We are always open to suggestions and improvements and want to work with 
>>> you on
>>> that.
>> I have a few experience with the s5p-mfc, and I do wrote a V4L2 encoder
>> plugin for Gstreamer.  I don't think the V4L2 is good place for us
>> stateless video processor, unless it would break the present implementation.
>>
>> The stateful and stateless are operated quite differently. The
>> stateless must parse the header and set those settings for every frames.
>> The request data may quite different from vendor to vendor, even chip to
>> chip. It is impossible to make a common way to send those settings to
>> driver.For the samsung MFC, you don't need to do any parse work at all.
>> Anyway, I would like to follow what Intel does now, we are both
>> stateless video processor.
> I don't see the problem. As I understand it what the hardware needs is the
> video data and settings (i.e. 'state'). It will process the video data (encode
> or decode) and return the result (probably with additional settings/state).
>
> V4L2 + Request API does exactly that. What does DRM offer you that makes life
Actually I don't 

[PATCH v5 1/4] drm: two more (drm_)printk() wrapper macros

[Chris Wilson]

On Fri, Aug 26, 2016 at 06:50:56PM +0100, Dave Gordon wrote:
> We had only DRM_INFO() and DRM_ERROR(), whereas the underlying printk()
> provides several other useful intermediate levels such as NOTICE and
> WARNING. So this patch fills out the set by providing simple macros for
> the additional levels. We don't provide _DEV_ or _ONCE or RATELIMITED
> versions yet as it seems unlikely that they'll be as useful.
> 
> v2:
> Fix whitespace, missing ## (Eric Engestrom)
> v5:
> Much simplified after underlying functions were reworked.
> 
> Signed-off-by: Dave Gordon 
> Previously-Reviewed-by: Eric Engestrom  (v2)
> Cc: Eric Engestrom 
> Cc: dri-devel at lists.freedesktop.org

Reviewed-by: Chris Wilson 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH v5 1/4] drm: two more (drm_)printk() wrapper macros

[Dave Gordon]

We had only DRM_INFO() and DRM_ERROR(), whereas the underlying printk()
provides several other useful intermediate levels such as NOTICE and
WARNING. So this patch fills out the set by providing simple macros for
the additional levels. We don't provide _DEV_ or _ONCE or RATELIMITED
versions yet as it seems unlikely that they'll be as useful.

v2:
Fix whitespace, missing ## (Eric Engestrom)
v5:
Much simplified after underlying functions were reworked.

Signed-off-by: Dave Gordon 
Previously-Reviewed-by: Eric Engestrom  (v2)
Cc: Eric Engestrom 
Cc: dri-devel at lists.freedesktop.org
---
 include/drm/drmP.h | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 94eb138..cd52624 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -168,6 +168,13 @@ void drm_printk(const char *level, unsigned int category,
 /** \name Macros to make printk easier */
 /*@{*/

+#define DRM_INFO(fmt, ...) \
+   drm_printk(KERN_INFO, DRM_UT_NONE, __func__, "", fmt, ##__VA_ARGS__)
+#define DRM_NOTE(fmt, ...) \
+   drm_printk(KERN_NOTICE, DRM_UT_NONE, __func__, "", fmt, ##__VA_ARGS__)
+#define DRM_WARN(fmt, ...) \
+   drm_printk(KERN_WARNING, DRM_UT_NONE, __func__, "", fmt, ##__VA_ARGS__)
+
 /**
  * Error output.
  *
@@ -202,8 +209,6 @@ void drm_printk(const char *level, unsigned int category,
 #define DRM_DEV_INFO(dev, fmt, ...)\
drm_dev_printk(dev, KERN_INFO, DRM_UT_NONE, __func__, "", fmt,  \
   ##__VA_ARGS__)
-#define DRM_INFO(fmt, ...) \
-   drm_printk(KERN_INFO, DRM_UT_NONE, __func__, "", fmt, ##__VA_ARGS__)

 #define DRM_DEV_INFO_ONCE(dev, fmt, ...)   \
 ({ \
-- 
1.9.1

[PATCH] drm/i915/skl: Don't try to update plane watermarks if they haven't changed

[Lyude]

i915 sometimes needs to disable planes in the middle of an atomic
commit, and then reenable them later in the same commit. Because of
this, we can't make the assumption that the state of the plane actually
changed. Since the state of the plane hasn't actually changed, neither
have it's watermarks. And if the watermarks hasn't changed then we
haven't populated skl_results with anything, which means we'll end up
zeroing out a plane's watermarks in the middle of the atomic commit
without restoring them later.

Signed-off-by: Lyude 
Cc: Maarten Lankhorst 
Fixes: 62e0fb880123 ("drm/i915/skl: Update plane watermarks atomically
during plane updates")

Signed-off-by: Lyude 
---
 drivers/gpu/drm/i915/intel_display.c |  8 +++-
 drivers/gpu/drm/i915/intel_sprite.c  | 10 --
 2 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e4e6141..8faf738 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3448,7 +3448,13 @@ static void skylake_disable_primary_plane(struct 
drm_plane *primary,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
int pipe = intel_crtc->pipe;

-   skl_write_plane_wm(intel_crtc, _priv->wm.skl_results, 0);
+   /*
+* We only populate skl_results on watermark updates, and if the
+* plane's visiblity isn't actually changing neither is it's
+* watermarks.
+*/
+   if (!crtc->primary->state->visible)
+   skl_write_plane_wm(intel_crtc, _priv->wm.skl_results, 0);

I915_WRITE(PLANE_CTL(pipe, 0), 0);
I915_WRITE(PLANE_SURF(pipe, 0), 0);
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 0df783a..f51a70c 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -292,8 +292,14 @@ skl_disable_plane(struct drm_plane *dplane, struct 
drm_crtc *crtc)
const int pipe = intel_plane->pipe;
const int plane = intel_plane->plane + 1;

-   skl_write_plane_wm(to_intel_crtc(crtc), _priv->wm.skl_results,
-  plane);
+   /*
+* We only populate skl_results on watermark updates, and if the
+* plane's visiblity isn't actually changing neither is it's
+* watermarks.
+*/
+   if (!dplane->state->visible)
+   skl_write_plane_wm(to_intel_crtc(crtc),
+  _priv->wm.skl_results, plane);

I915_WRITE(PLANE_CTL(pipe, plane), 0);

-- 
2.7.4

[PATCH V2] drm/panel: simple: Fix bus flags for ortustech com43h4m85ulc

[Marek Vasut]

This display expects DE pin and data lines to be active high,
add the necessary flags.

Signed-off-by: Marek Vasut 
Cc: Philipp Zabel 
Cc: Thierry Reding 
---
V2: Add DRM_BUS_FLAG_PIXDATA_POSEDGE to cater for the video data.
---
 drivers/gpu/drm/panel/panel-simple.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 3a7bdf1..cb34f95 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1198,6 +1198,7 @@ static const struct panel_desc ortustech_com43h4m85ulc = {
.height = 93,
},
.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+   .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_POSEDGE,
 };

 static const struct drm_display_mode qd43003c0_40_mode = {
-- 
2.9.3

[PATCH] drm/bridge: analogix_dp: detect Sink PSR state after configuring the PSR

[Yakir Yang]

Make sure the request PSR state could effect in analogix_dp_send_psr_spd()
function, or printing the error Sink PSR state if we failed to effect
the request PSR setting.

Signed-off-by: Yakir Yang 
---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  6 ++---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  4 ++--
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 26 --
 3 files changed, 28 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index efac8ab..5a37de8 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -115,8 +115,7 @@ int analogix_dp_enable_psr(struct device *dev)
psr_vsc.DB0 = 0;
psr_vsc.DB1 = EDP_VSC_PSR_STATE_ACTIVE | EDP_VSC_PSR_CRC_VALUES_VALID;

-   analogix_dp_send_psr_spd(dp, _vsc);
-   return 0;
+   return analogix_dp_send_psr_spd(dp, _vsc);
 }
 EXPORT_SYMBOL_GPL(analogix_dp_enable_psr);

@@ -138,8 +137,7 @@ int analogix_dp_disable_psr(struct device *dev)
psr_vsc.DB0 = 0;
psr_vsc.DB1 = 0;

-   analogix_dp_send_psr_spd(dp, _vsc);
-   return 0;
+   return analogix_dp_send_psr_spd(dp, _vsc);
 }
 EXPORT_SYMBOL_GPL(analogix_dp_disable_psr);

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index 473b980..f617a9d 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -283,7 +283,7 @@ void analogix_dp_config_video_slave_mode(struct 
analogix_dp_device *dp);
 void analogix_dp_enable_scrambling(struct analogix_dp_device *dp);
 void analogix_dp_disable_scrambling(struct analogix_dp_device *dp);
 void analogix_dp_enable_psr_crc(struct analogix_dp_device *dp);
-void analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
- struct edp_vsc_psr *vsc);
+int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
+struct edp_vsc_psr *vsc);

 #endif /* _ANALOGIX_DP_CORE_H */
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 52c1b6b..505e9d8 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -1328,9 +1328,11 @@ void analogix_dp_enable_psr_crc(struct 
analogix_dp_device *dp)
writel(PSR_VID_CRC_ENABLE, dp->reg_base + ANALOGIX_DP_CRC_CON);
 }

-void analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
- struct edp_vsc_psr *vsc)
+int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
+struct edp_vsc_psr *vsc)
 {
+   unsigned long timeout;
+   unsigned char sink;
unsigned int val;

/* don't send info frame */
@@ -1372,4 +1374,24 @@ void analogix_dp_send_psr_spd(struct analogix_dp_device 
*dp,
val = readl(dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
val |= IF_EN;
writel(val, dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
+
+   timeout = jiffies + msecs_to_jiffies(100);
+   while (1) {
+   analogix_dp_read_byte_from_dpcd(dp, DP_PSR_STATUS, );
+
+   if (vsc->DB1 && sink == DP_PSR_SINK_ACTIVE_RFB)
+   break;
+
+   if (!vsc->DB1 && sink == DP_PSR_SINK_INACTIVE)
+   break;
+
+   if (time_after(jiffies, timeout)) {
+   dev_warn(dp->dev, "Failed to effect PSR: %x", sink);
+   return -EBUSY;
+   }
+
+   usleep_range(1000, 1500);
+   }
+
+   return 0;
 }
-- 
1.9.1

[PATCH] drm/panel: simple: Fix bus flags for ortustech com43h4m85ulc

[Marek Vasut]

On 08/26/2016 05:58 PM, Philipp Zabel wrote:
> Hi Marek,
> 
> Am Freitag, den 26.08.2016, 16:24 +0200 schrieb Marek Vasut:
>> This display expects DE pin to be active high, add the necessary flag.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: Philipp Zabel 
>> Cc: Thierry Reding 
>> ---
>>  drivers/gpu/drm/panel/panel-simple.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
>> b/drivers/gpu/drm/panel/panel-simple.c
>> index 3a7bdf1..f4c546d 100644
>> --- a/drivers/gpu/drm/panel/panel-simple.c
>> +++ b/drivers/gpu/drm/panel/panel-simple.c
>> @@ -1198,6 +1198,7 @@ static const struct panel_desc ortustech_com43h4m85ulc 
>> = {
>>  .height = 93,
>>  },
>>  .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
>> +.bus_flags = DRM_BUS_FLAG_DE_HIGH,
> 
> Reviewed-by: Philipp Zabel 
> 
> While at it, you could also add DRM_BUS_FLAG_PIXDATA_POSEDGE. The panel
> expects pixel data to be driven with the rising edge of the pixel clock,
> it samples on the falling edge.

Ah, let me add the flag and repost then.

-- 
Best regards,
Marek Vasut

Plan to support Rockchip VPU in DRM, is it a good idea

[Randy Li]

On 08/26/2016 05:34 PM, Hans Verkuil wrote:
> Hi Randi,
>
> On 08/26/2016 04:13 AM, Randy Li wrote:
>> Hello,
>>We always use some kind of hack work to make our Video Process
>> Unit(Multi-format Video Encoder/Decoder) work in kernel. From a
>> customize driver(vpu service) to the customize V4L2 driver. The V4L2
>> subsystem is really not suitable for the stateless Video process or it
>> could make driver too fat.
>>After talking to some kindness Intel guys and moving our userspace
>> library to VA-API driver, I find the DRM may the good choice for us.
>> But I don't know whether it is welcome to to submit a video driver in
>> DRM subsystem?
>>Also our VPU(Video process unit) is not just like the Intel's, we
>> don't have VCS, we based on registers to set the encoder/decoder. I
>> think we may need a lots of IOCTL then. Also we do have a IOMMU in VPU
>> but also not a isolated memory for VPU, I don't know I should use TT
>> memory or GEM memory.
>>I am actually not a member of the department in charge of VPU, and I
>> am just beginning to learning DRM(thank the help from Intel again), I am
>> not so good at memory part as well(I am more familiar with CMA not the
>> IOMMU way), I may need know guide about the implementations when I am
>> going to submit driver, I hope I could get help from someone.
>>
>
> It makes no sense to do this in the DRM subsystem IMHO. There are already
> quite a few HW codecs implemented in the V4L2 subsystem and more are in the
> pipeline. Putting codec support in different subsystems will just make
> userspace software much harder to write.
>
> One of the codecs that was posted to linux-media was actually from Rockchip:
>
> https://lkml.org/lkml/2016/2/29/861
>
> There is also a libVA driver (I think) that sits on top of it:
>
> https://github.com/rockchip-linux/rockchip-va-driver/tree/v4l2-libvpu
It is old version, I am the author of this
https://github.com/rockchip-linux/rockchip-va-driver
>
> For the Allwinner a patch series was posted yesterday:
>
> https://lkml.org/lkml/2016/8/25/246
>
> They created a pretty generic libVA userspace that looks very promising at
> first glance.
>
> What these have in common is that they depend on the Request API and Frame 
> API,
> neither of which has been merged. The problem is that the Request API requires
> more work since not only controls have to be part of a request, but also 
> formats,
> selection rectangles, and even dynamic routing changes. While that is not 
> relevant
> for codecs, it is relevant for Android CameraHAL in general and complex 
> devices
> like Google's Project Ara.
Actually just as the Intel did, our hardware decoder/encoder need full 
settings for them, most of them are relevant to the codec. You may 
notice that there is four extra control need to be set before. If the 
libvpu(a helper library we offered to parse each slice to generate 
decoder settings) is remove(in process now, only three decoder settings 
can't got from VA-API directly), it would be more clearly.
We really a lots decoder settings information to make the decoder work.
>
> This is being worked on, but it is simply not yet ready. The core V4L2 
> developers
> involved in this plan to discuss this on the Monday before the ELCE in Berlin,
> to see if we can fast track this work somehow so this support can be merged.
>
I am glad to hear that. I hope that I could have an opportunity to show 
our problems.
> If there are missing features in V4L2 (other that the two APIs discussed 
> above)
> that prevent you from creating a good driver, then please discuss that with 
> us.
> We are always open to suggestions and improvements and want to work with you 
> on
> that.
I have a few experience with the s5p-mfc, and I do wrote a V4L2 encoder 
plugin for Gstreamer.  I don't think the V4L2 is good place for us 
stateless video processor, unless it would break the present implementation.

   The stateful and stateless are operated quite differently. The 
stateless must parse the header and set those settings for every frames.
The request data may quite different from vendor to vendor, even chip to 
chip. It is impossible to make a common way to send those settings to 
driver.For the samsung MFC, you don't need to do any parse work at all.
   Anyway, I would like to follow what Intel does now, we are both 
stateless video processor.
>
> Regards,
>
>   Hans
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>

-- 
Randy Li
The third produce department

[PATCH] drm/panel: simple: Fix bus flags for ortustech com43h4m85ulc

[Philipp Zabel]

Hi Marek,

Am Freitag, den 26.08.2016, 16:24 +0200 schrieb Marek Vasut:
> This display expects DE pin to be active high, add the necessary flag.
> 
> Signed-off-by: Marek Vasut 
> Cc: Philipp Zabel 
> Cc: Thierry Reding 
> ---
>  drivers/gpu/drm/panel/panel-simple.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> b/drivers/gpu/drm/panel/panel-simple.c
> index 3a7bdf1..f4c546d 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -1198,6 +1198,7 @@ static const struct panel_desc ortustech_com43h4m85ulc 
> = {
>   .height = 93,
>   },
>   .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
> + .bus_flags = DRM_BUS_FLAG_DE_HIGH,

Reviewed-by: Philipp Zabel 

While at it, you could also add DRM_BUS_FLAG_PIXDATA_POSEDGE. The panel
expects pixel data to be driven with the rising edge of the pixel clock,
it samples on the falling edge.

regards
Philipp

[PATCH 1/2] net: fec: don't ack masked interrupt events

[Lucas Stach]

Sorry, please ignore the FEC patches. Those are test patches still
residing in my to-send folder. Sorry for the noise.

Am Freitag, den 26.08.2016, 17:49 +0200 schrieb Lucas Stach:
> The FEC doesn't have a real interrupt status register, that takes
> into account the mask status of the IRQ. The driver reads the raw
> interrupt event register, which also reports events for masked
> IRQs.
> 
> The driver needs to apply the current mask itself, to avoid acking
> IRQs that are currently masked, as NAPI relies on the masking to
> hide the IRQs. The current behavior of just acking all interrupts
> regardless of their mask status opens the driver up the "rotting
> packet" race-window, as described in the original NAPI-HOWTO, which
> has been observed in the wild.
> 
> Signed-off-by: Lucas Stach 
> ---
>  drivers/net/ethernet/freescale/fec_main.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/freescale/fec_main.c 
> b/drivers/net/ethernet/freescale/fec_main.c
> index 01f7e811739b..498264969e89 100644
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -1572,7 +1572,8 @@ fec_enet_interrupt(int irq, void *dev_id)
>   uint int_events;
>   irqreturn_t ret = IRQ_NONE;
>  
> - int_events = readl(fep->hwp + FEC_IEVENT);
> + int_events = readl_relaxed(fep->hwp + FEC_IEVENT) &
> +  readl_relaxed(fep->hwp + FEC_IMASK);
>   writel(int_events, fep->hwp + FEC_IEVENT);
>   fec_enet_collect_events(fep, int_events);
>  

[PATCH v2] drm/fsl-dcu: Fix endian issue when using clk_register_divider

[Meng Yi]

While clk_register_divider will write register as little endian,
Modified the param "shift" from 0 to 24 since DCU is big endian.
Or reg "DCU_DIV_RATIO" will be seted as a incorrect value which
will cause vblank timing issue etc.

Signed-off-by: Meng Yi 
---
Changes in V2:
-check the soc name to decide the "shift" value
 since vf610's divider reg is little endian while
 ls1021a's divider reg is big endian
---
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 3 ++-
 1 file changed, 2 insertions(+), 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 7882387..a590ce8 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
@@ -386,7 +386,8 @@ static int fsl_dcu_drm_probe(struct platform_device *pdev)
snprintf(pix_clk_name, sizeof(pix_clk_name), "%s_pix", pix_clk_in_name);
fsl_dev->pix_clk = clk_register_divider(dev, pix_clk_name,
pix_clk_in_name, 0, base + DCU_DIV_RATIO,
-   0, 8, CLK_DIVIDER_ROUND_CLOSEST, NULL);
+   !strcmp(fsl_dev->soc->name, "ls1021a")?24:0, 8,
+   CLK_DIVIDER_ROUND_CLOSEST, NULL);
if (IS_ERR(fsl_dev->pix_clk)) {
dev_err(dev, "failed to register pix clk\n");
ret = PTR_ERR(fsl_dev->pix_clk);
-- 
2.1.0.27.g96db324

[PATCH 2/2] net: fec: optimize IRQ handler

[Lucas Stach]

fep->work_rx and fep->work_tx are both non-zero, as long as the NAPI
softirq hasn't finished its work. So if the current IRQ does not
signal any RX or TX completion, but some unrelated event, the path to
schedule the NAPI context is still entered.

The handler works correctly as in this case napi_schedule_prep() will
reject the scheduling attempt, but the flow can still be optimized by
not trying to schedule if the IRQ doesn't signal RX or TX completion.

Signed-off-by: Lucas Stach 
---
 drivers/net/ethernet/freescale/fec_main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/freescale/fec_main.c 
b/drivers/net/ethernet/freescale/fec_main.c
index 498264969e89..fee5783a4dc6 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -1575,14 +1575,14 @@ fec_enet_interrupt(int irq, void *dev_id)
int_events = readl_relaxed(fep->hwp + FEC_IEVENT) &
 readl_relaxed(fep->hwp + FEC_IMASK);
writel(int_events, fep->hwp + FEC_IEVENT);
-   fec_enet_collect_events(fep, int_events);

-   if ((fep->work_tx || fep->work_rx) && fep->link) {
+   if ((int_events & (FEC_ENET_RXF | FEC_ENET_TXF)) && fep->link) {
ret = IRQ_HANDLED;

if (napi_schedule_prep(>napi)) {
/* Disable the NAPI interrupts */
writel(FEC_NAPI_IMASK, fep->hwp + FEC_IMASK);
+   fec_enet_collect_events(fep, int_events);
__napi_schedule(>napi);
}
}
-- 
2.8.1

[PATCH 1/2] net: fec: don't ack masked interrupt events

[Lucas Stach]

The FEC doesn't have a real interrupt status register, that takes
into account the mask status of the IRQ. The driver reads the raw
interrupt event register, which also reports events for masked
IRQs.

The driver needs to apply the current mask itself, to avoid acking
IRQs that are currently masked, as NAPI relies on the masking to
hide the IRQs. The current behavior of just acking all interrupts
regardless of their mask status opens the driver up the "rotting
packet" race-window, as described in the original NAPI-HOWTO, which
has been observed in the wild.

Signed-off-by: Lucas Stach 
---
 drivers/net/ethernet/freescale/fec_main.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/freescale/fec_main.c 
b/drivers/net/ethernet/freescale/fec_main.c
index 01f7e811739b..498264969e89 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -1572,7 +1572,8 @@ fec_enet_interrupt(int irq, void *dev_id)
uint int_events;
irqreturn_t ret = IRQ_NONE;

-   int_events = readl(fep->hwp + FEC_IEVENT);
+   int_events = readl_relaxed(fep->hwp + FEC_IEVENT) &
+readl_relaxed(fep->hwp + FEC_IMASK);
writel(int_events, fep->hwp + FEC_IEVENT);
fec_enet_collect_events(fep, int_events);

-- 
2.8.1

[PATCH 1/2] drm/etnaviv: fail probe if core or bus clock are absent

[Lucas Stach]

The devicetree documentation states that those are required properties,
so the driver should refuse to probe if those are absent to be
consistent. This will also allow to drop some error checking from the
clock enable/disable paths.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index b851809d29b3..ec14aaaf6dd7 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1684,12 +1684,12 @@ static int etnaviv_gpu_platform_probe(struct 
platform_device *pdev)
gpu->clk_bus = devm_clk_get(>dev, "bus");
DBG("clk_bus: %p", gpu->clk_bus);
if (IS_ERR(gpu->clk_bus))
-   gpu->clk_bus = NULL;
+   return PTR_ERR(gpu->clk_bus);

gpu->clk_core = devm_clk_get(>dev, "core");
DBG("clk_core: %p", gpu->clk_core);
if (IS_ERR(gpu->clk_core))
-   gpu->clk_core = NULL;
+   return PTR_ERR(gpu->clk_core);

gpu->clk_shader = devm_clk_get(>dev, "shader");
DBG("clk_shader: %p", gpu->clk_shader);
-- 
2.8.1

[PATCH 1/2] net: fec: don't ack masked interrupt events

[Russell King - ARM Linux]

On Fri, Aug 26, 2016 at 05:53:38PM +0200, Lucas Stach wrote:
> Sorry, please ignore the FEC patches. Those are test patches still
> residing in my to-send folder. Sorry for the noise.

This patch actually looks correct: you are indeed correct that the
driver can end up with a packet sitting waiting to be received.
All it will take is a correctly timed MII interrupt event with a
NAPI just coming to the end of its processing.

So, I'd encourage this to be applied - but obviously when sent to
netdev rather than the DRI mailing list!

> 
> Am Freitag, den 26.08.2016, 17:49 +0200 schrieb Lucas Stach:
> > The FEC doesn't have a real interrupt status register, that takes
> > into account the mask status of the IRQ. The driver reads the raw
> > interrupt event register, which also reports events for masked
> > IRQs.
> > 
> > The driver needs to apply the current mask itself, to avoid acking
> > IRQs that are currently masked, as NAPI relies on the masking to
> > hide the IRQs. The current behavior of just acking all interrupts
> > regardless of their mask status opens the driver up the "rotting
> > packet" race-window, as described in the original NAPI-HOWTO, which
> > has been observed in the wild.
> > 
> > Signed-off-by: Lucas Stach 
> > ---
> >  drivers/net/ethernet/freescale/fec_main.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/net/ethernet/freescale/fec_main.c 
> > b/drivers/net/ethernet/freescale/fec_main.c
> > index 01f7e811739b..498264969e89 100644
> > --- a/drivers/net/ethernet/freescale/fec_main.c
> > +++ b/drivers/net/ethernet/freescale/fec_main.c
> > @@ -1572,7 +1572,8 @@ fec_enet_interrupt(int irq, void *dev_id)
> > uint int_events;
> > irqreturn_t ret = IRQ_NONE;
> >  
> > -   int_events = readl(fep->hwp + FEC_IEVENT);
> > +   int_events = readl_relaxed(fep->hwp + FEC_IEVENT) &
> > +readl_relaxed(fep->hwp + FEC_IMASK);
> > writel(int_events, fep->hwp + FEC_IEVENT);
> > fec_enet_collect_events(fep, int_events);
> >  
> 
> 

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

[PATCH 1/2] drm/etnaviv: fail probe if core or bus clock are absent

[Russell King - ARM Linux]

On Fri, Aug 26, 2016 at 05:49:54PM +0200, Lucas Stach wrote:
> The devicetree documentation states that those are required properties,
> so the driver should refuse to probe if those are absent to be
> consistent. This will also allow to drop some error checking from the
> clock enable/disable paths.

NAK.

Thanks for reviewing the existing DT files before proposing this change
and noticing that you're going to wilfully end up breaking existing users.
A simple grep would have sufficed.

The DT binding doc is wrong: there is only one documented clock on Dove
and that's for the GPU core.  (The Dove documentation as far as clocks
go is very poor.)  So, what's Dove supposed to do - make up some
ficticious clock?

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

[PATCH] drm/etnaviv: Always init gpu->memory_base

[Russell King - ARM Linux]

On Fri, Aug 26, 2016 at 04:25:13PM +0200, Marek Vasut wrote:
> The content of gpu->memory_base should point to start of RAM, not zero.
> 
> Signed-off-by: Marek Vasut 
> Cc: Lucas Stach 
> Cc: Christian Gmeiner 
> Cc: Russell King 
> ---
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index ff6aa5d..a168532 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -588,6 +588,8 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
>   gpu->memory_base = PHYS_OFFSET;
>   else
>   gpu->memory_base = dma_mask - SZ_2G + 1;
> + } else {
> + gpu->memory_base = PHYS_OFFSET;
>   }

The code is correct as-is.  Etnaviv GPUs are not without their own
weirdness.

For MC1.0 3D GPUs (eg, GC600 as found on Dove), there is an issue
where _most_ GPU accesses go through a memory offsetting via the
memory base, but accesses by the tiler do not: they bypass the
memory base offsetting.

We have two options to work around that:

1. Maintain two GPU address spaces, and mark relocations according
   to their use.  This is error prone: we would have to have the
   kernel verify the relocation type is valid for the load state
   address to avoid obvious security issues, and the maintanence
   of these different address spaces becomes more complex.

2. Force the address offset to zero so all GPU accesses map through
   the same method irrespective of which GPU block is performing the
   access.

We've chosen (2) because it is much simpler, and less error prone,
plus it fits with the platforms that we're aware of at the moment.
I did push for the relocations to have an additional member which
can be used to flag the type of the relocation if necessary in the
future without changing the interface structure layouts, so we do
have that option if we really need to do it - but we'd all prefer
to avoid it.

Also, iirc, the GPU tiler with MC1.0 is unable to access addresses
>= 2GiB no matter what - if you do have a 3D GPU with MC1.0, and
you have physical memory above 2GiB... there's no currently known
solution... you lose.

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

[PATCH 0/3] drm/tilcdc: Some fixes for LCDC rev1

[Karl Beldan]

Hi,

On Tue, Aug 23, 2016 at 07:24:42PM +0300, Jyri Sarha wrote:
> Thanks a lot!
> This is very helpful as I do not have LCDC rev1 HW my self, but only
> am335x based boards.
> 
> On 08/23/16 15:56, Karl Beldan wrote:
> > Hi,
> > 
> > I found some missing bits for rev1 of the LCDC and here are some of the
> > changes I am using to use the DRM driver on an LCDCK (which has a rev1).
> > 1/3 seems required by rev1 of the IP and without it my the LCDC on my
> > LCDK keeps can't sync, 2/3 is required by the driver logic, while 3/3
> > is less of a requirement.
> 
> I'll drop 3/3, because my recent patches should take care of that:
> http://www.spinics.net/lists/devicetree/msg138885.html
> 

They do indeed.

> However, there will be v2 round of those patches. Only the DT binding
> and its default value should change.
> 
> > Although 1,2/3 would have fitted drm-fixes I based them on drm-next as
> > 2/3 would conflict with the recent changes in drm-next.
> > 
> 
> I'll pick these two up for my next pull request. Thanks!
> 
> > Another thing which is also an absolute requirement for the rev1 but 
> > with which rev2 seems to cope fine is the palette loading (even if the DRM
> > uses >= 16bpp formats), dixit the TRM:
> > "12-, 16-, and 24-BPP modes do not need a palette; i.e., the pixel data is
> > the desired RGB value. However, the first 32 bytes are still considered a
> > palette. The first entry should be 4000h (bit 14 is 1) while the remaining
> > entries must be filled with 0.".
> > ATM I am using a local crude way of loading the palette to verify the
> > missing bits to get the DRM driver properly working on the LCDK (as I
> > haven't seen how things work in the DRM subsystem I can't post any proper
> > change for that).
> > 
> 
> I see. Reading from the TRM, that should be done for rev2 too. I'll try
> to come up with a patch for that at some point, unless you send me one
> first.
> 

That would be nice. I didn't look at how to integrate my local changes
but instead I tried to see what prevented modetest to work, (with the
posted changes and the palette loading the framebuffer was operational
but not modetest). It appears that when modetesting the LCDC loses its
sync, and I guess that's because the framebuffer addresses are changed
while the raster is still on, which seems inappropriate. Since the v2s
seem to cope with framebuffer ceiling boundaries that are off, my first
guess would be they don't use it and directly use the raster timings
and the bpp format for the boundary and sees the framebuffer addresses
changes (base + ceiling) as atomic. My local changes try to cope with
that by handling the sync loss irq and it gives me a working modetest,
however it is not enough to get modetest -v (ie. with vsynced page
flipping) working.
My impression would be that to work with v1, the following would be in
order (in addition to the palette):
- make changes to the controller with the raster disabled
- handle FRAME_DONE and SYNC_LOST with v1 as well (the driver assumes it
  is only valid for v2, which is false)

> > The posted changes and the above mentioned palette loading missing bit 
> > are specific to the DRM driver.
> > 
> > However there are other shortcomings to the proper functioning of the 
> > LCDC on some platforms (I am currently focusing on the LCDK but I guess 
> > it should be true for all da850 based systems), which are not inherent to
> > the DRM driver driver but which strongly relate to it:
> > 
> > - The pixel clock rate setting (eg. currently the davinci clk can't cope
> > properly with the DRM driver way of setting the clock and doesn't use
> > the common clock framework)
> > - The memory bandwidth/latency requirements for the LCDC are not met 
> > with the default priority settings (apparently there is a fix in
> > da850_lcd_hw_init of: 
> > http://arago-project.org/git/projects/linux-davinci.git?p=projects/linux-davinci.git;a=blob;f=arch/arm/mach-davinci/board-omapl138-lcdk.c;h=689b4f304011e09e262782cf8c4b96eba00ac28b;hb=HEAD).
> > Of course this one affects both the DRM and framebuffer systems.
> > 
> 
> There is also memory bandwidth issues on am335x and we are still looking
> for a proper system level fix.
> 
> > Hence to test the LCDK my crude local changes include (ie. on top of the
> > posted changes and some dts or sync_lost recovery bits):
> > - palette loading
> > - tweak of the pixel clock to cope with davinci clk
> 
> If you have proper a fixes for these, please send a patch. The palette
> loading is something I can probably do myself too, but the clock thing
> is something that I at least can not test.
> 

Why not behave as da8xx-fb ? It doesn't touch the fck clock rate but
only adjusts the clkdiv of the LCDC for pixel clock, plus it seems to
fit well with cpufreq.

> > - adjustment of the memory master priorities
> > 
> 
> That would be a system level fix and I can not say whether or not to
> take such a fix.
> 
> > 
> > BTW, with the recent changes of tilcdc from drm-next, I 

[PATCH v4 3/5] drm: add SimpleDRM driver

[Daniel Vetter]

On Fri, Aug 26, 2016 at 12:11 AM, Noralf Trønnes  wrote:
> I'm really walking in the dark here. I have deleted drm_driver.gem_vm_ops
> and used this function:
>
> int sdrm_drm_mmap(struct file *filp, struct vm_area_struct *vma)
> {
> struct drm_file *priv = filp->private_data;
> struct drm_device *dev = priv->minor->dev;
> struct drm_gem_object *obj = NULL;
> struct drm_vma_offset_node *node;
> int ret;
>
> drm_vma_offset_lock_lookup(dev->vma_offset_manager);
> node = drm_vma_offset_exact_lookup_locked(dev->vma_offset_manager,
>   vma->vm_pgoff,
>   vma_pages(vma));
> if (likely(node)) {
> obj = container_of(node, struct drm_gem_object, vma_node);
> /*
> * When the object is being freed, after it hits 0-refcnt it
> * proceeds to tear down the object. In the process it will
> * attempt to remove the VMA offset and so acquire this
> * mgr->vm_lock.  Therefore if we find an object with a 0-refcnt
> * that matches our range, we know it is in the process of being
> * destroyed and will be freed as soon as we release the lock -
> * so we have to check for the 0-refcnted object and treat it as
> * invalid.
> */
> if (!kref_get_unless_zero(>refcount))
> obj = NULL;
> }
> drm_vma_offset_unlock_lookup(dev->vma_offset_manager);
>
> if (!obj)
> return -EINVAL;
>
> if (!drm_vma_node_is_allowed(node, filp)) {
> drm_gem_object_unreference_unlocked(obj);
> return -EACCES;
> }
>
> /* redirect to shmem mmap */
> vma->vm_file = obj->filp;
> vma->vm_pgoff = 0;
>
> ret = obj->filp->f_op->mmap(obj->filp, vma);
>
> drm_gem_object_unreference_unlocked(obj);
>
> return ret;
> }

Yup, this looks good.

> But that works only partly. Using modetest I get a picture, but fbdev
> doesn't return.
> Turning on drm debug the two variants are identical up to
> DRM_IOCTL_MODE_DESTROY_DUMB.
>
> The shmem mmap version:
> [identical]
> [   74.939660] [drm:drm_ioctl] pid=721, dev=0xe200, auth=1,
> DRM_IOCTL_MODE_DESTROY_DUMB
> And nothing more

Hm, what does your fbdev support code now look like? fbdev doesn't do
paging, so for that you still need the get_pages(); vmap; thing at
setup time, and then when you tear down the fbdev stuff a vunmap();
and put_pages();

And of course the dirty stuff all needs to be wired up, but since it
works for modeset I think we can assume it's in good shape.
-Daniel

> Whereas the working one gives me this:
> [identical]
> [   70.373029] [drm:drm_ioctl] pid=721, dev=0xe200, auth=1,
> DRM_IOCTL_MODE_DESTROY_DUMB
> [   70.393401] [drm:drm_release] open_count = 1
> [   70.393429] [drm:drm_release] pid = 721, device = 0xe200, open_count = 1
> [   70.393468] [drm:drm_lastclose]
> [   70.393501] [drm:drm_atomic_state_init] Allocated atomic state dad61e00
> [   70.393521] [drm:drm_atomic_get_plane_state] Added [PLANE:24:plane-0]
> dad61e40 state to dad61e00
> [   70.393543] [drm:drm_atomic_get_crtc_state] Added [CRTC:25:crtc-0]
> dad73a00 state to dad61e00
> [   70.393588] [drm:drm_atomic_set_mode_for_crtc] Set [MODE:1824x984] for
> CRTC state dad73a00
> [   70.393604] [drm:drm_atomic_set_crtc_for_plane] Link plane state dad61e40
> to [CRTC:25:crtc-0]
> [   70.393619] [drm:drm_mode_object_reference] OBJ ID: 29 (1)
> [   70.393629] [drm:drm_atomic_set_fb_for_plane] Set [FB:29] for plane state
> dad61e40
> [   70.393643] [drm:drm_atomic_add_affected_connectors] Adding all current
> connectors for [CRTC:25:crtc-0] to dad61e00
> [   70.393662] [drm:drm_mode_object_reference] OBJ ID: 23 (2)
> [   70.393674] [drm:drm_atomic_get_connector_state] Added [CONNECTOR:23]
> dad613c0 state to dad61e00
> [   70.393835] [drm:drm_mode_object_reference] OBJ ID: 23 (3)
> [   70.393848] [drm:drm_atomic_set_crtc_for_connector] Link connector state
> dad613c0 to [CRTC:25:crtc-0]
> [   70.393859] [drm:drm_atomic_check_only] checking dad61e00
> [   70.393873] [drm:drm_atomic_helper_check_modeset] [CRTC:25:crtc-0] mode
> changed
> [   70.393881] [drm:drm_atomic_helper_check_modeset] [CRTC:25:crtc-0] enable
> changed
> [   70.403886] [drm:update_connector_routing] Updating routing for
> [CONNECTOR:23:Virtual-1]
> [   70.403916] [drm:update_connector_routing] [CONNECTOR:23:Virtual-1] using
> [ENCODER:26:None-26] on [CRTC:25:crtc-0]
> [   70.403926] [drm:drm_atomic_helper_check_modeset] [CRTC:25:crtc-0] active
> changed
> [   70.403956] [drm:drm_atomic_helper_check_modeset] [CRTC:25:crtc-0] needs
> all connectors, enable: y, active: y
> [   70.403972] [drm:drm_atomic_add_affected_connectors] Adding all current
> connectors for [CRTC:25:crtc-0] to dad61e00
> [   70.404006] [drm:drm_atomic_commit] commiting dad61e00
> [   70.404043] [drm:crtc_set_mode] modeset on [ENCODER:26:None-26]
> [   70.422427] [drm:drm_atomic_helper_commit_modeset_enables] enabling
> [CRTC:25:crtc-0]
> [   70.422465] 

[PATCH] drm/etnaviv: Always init gpu->memory_base

[Marek Vasut]

On 08/26/2016 04:35 PM, Lucas Stach wrote:
> Am Freitag, den 26.08.2016, 16:25 +0200 schrieb Marek Vasut:
>> The content of gpu->memory_base should point to start of RAM, not zero.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: Lucas Stach 
>> Cc: Christian Gmeiner 
>> Cc: Russell King 
> 
> NACK. This will cause memory corruption when used with a MC10 GPU. The
> checks are there for a reason. ;)
> 
> I'll have to think about a proper solution for MX6SX.

Oh ok, thanks.

>> ---
>>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
>> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
>> index ff6aa5d..a168532 100644
>> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
>> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
>> @@ -588,6 +588,8 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
>>  gpu->memory_base = PHYS_OFFSET;
>>  else
>>  gpu->memory_base = dma_mask - SZ_2G + 1;
>> +} else {
>> +gpu->memory_base = PHYS_OFFSET;
>>  }
>>  
>>  ret = etnaviv_hw_reset(gpu);
> 
> 


-- 
Best regards,
Marek Vasut

[PATCH] drm/etnaviv: Always init gpu->memory_base

[Lucas Stach]

Am Freitag, den 26.08.2016, 16:25 +0200 schrieb Marek Vasut:
> The content of gpu->memory_base should point to start of RAM, not zero.
> 
> Signed-off-by: Marek Vasut 
> Cc: Lucas Stach 
> Cc: Christian Gmeiner 
> Cc: Russell King 

NACK. This will cause memory corruption when used with a MC10 GPU. The
checks are there for a reason. ;)

I'll have to think about a proper solution for MX6SX.

> ---
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index ff6aa5d..a168532 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -588,6 +588,8 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
>   gpu->memory_base = PHYS_OFFSET;
>   else
>   gpu->memory_base = dma_mask - SZ_2G + 1;
> + } else {
> + gpu->memory_base = PHYS_OFFSET;
>   }
>  
>   ret = etnaviv_hw_reset(gpu);

"Fixes" for page flipping under PRIME on AMD & nouveau

[Alex Deucher]

On Fri, Aug 26, 2016 at 4:10 PM, Mario Kleiner
 wrote:
> On 08/18/2016 09:21 PM, Marek Olšák wrote:
>>
>> On Thu, Aug 18, 2016 at 4:23 AM, Michel Dänzer  
>> wrote:
>>>
>>> Maybe the rasterization as two triangles results in bad PCIe bandwidth
>>> utilization. Using the asynchronous DMA engine for these transfers would
>>> probably be ideal, but having the 3D engine rasterize a single rectangle
>>> (either using the rectangle primitive or a large triangle with scissor)
>>> might already help.
>>
>>
>> There is only one thing that's bad for PCIe when the surface is
>> linear: the 3D engine. Disabling all but the first shader engine and
>> all but the first 2 RBs should improve performance for blits from VRAM
>> to GTT. The closed driver does that, but I don't remember if the
>> destination must be linear, must be in GTT, or both. In any case, SDMA
>> should still be the best for VRAM->GTT blits.
>>
>> Marek
>>
>
> Friday evening education question:
>
> So if you have multiple render backends active they compete for PCIe bus
> access and some kind of "trashing" happens in the arbitration, drastically
> reducing the bandwidth?

I think it has more to do with the access patterns.  The requests
can't be scheduled as efficiently compared to contiguous linear
accesses.

Alex

[PATCH 2/2] drm: Add new driver for MXSFB controller

[Marek Vasut]

Add new driver for the MXSFB controller found in i.MX23/28/6SX .
The MXSFB controller is a simple framebuffer controller with one
parallel LCD output. Unlike the MXSFB fbdev driver that is used
on these systems now, this driver uses the DRM/KMS framework.

Signed-off-by: Marek Vasut 
Cc: Lucas Stach 
Cc: Fabio Estevam 
Cc: Shawn Guo 
---
 MAINTAINERS|   6 +
 drivers/gpu/drm/Kconfig|   2 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/mxsfb/Kconfig  |  18 ++
 drivers/gpu/drm/mxsfb/Makefile |   2 +
 drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 395 +
 drivers/gpu/drm/mxsfb/mxsfb_drv.c  | 324 ++
 drivers/gpu/drm/mxsfb/mxsfb_drv.h  |  58 ++
 drivers/gpu/drm/mxsfb/mxsfb_out.c  | 264 +
 drivers/gpu/drm/mxsfb/mxsfb_regs.h | 112 +++
 10 files changed, 1182 insertions(+)
 create mode 100644 drivers/gpu/drm/mxsfb/Kconfig
 create mode 100644 drivers/gpu/drm/mxsfb/Makefile
 create mode 100644 drivers/gpu/drm/mxsfb/mxsfb_crtc.c
 create mode 100644 drivers/gpu/drm/mxsfb/mxsfb_drv.c
 create mode 100644 drivers/gpu/drm/mxsfb/mxsfb_drv.h
 create mode 100644 drivers/gpu/drm/mxsfb/mxsfb_out.c
 create mode 100644 drivers/gpu/drm/mxsfb/mxsfb_regs.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 8c20323..39b16b4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7781,6 +7781,12 @@ T:   git git://linuxtv.org/mkrufky/tuners.git
 S: Maintained
 F: drivers/media/tuners/mxl5007t.*

+MXSFB DRM DRIVER
+M: Marek Vasut 
+S: Supported
+F: drivers/gpu/drm/mxsfb/
+F: Documentation/devicetree/bindings/display/mxsfb-drm.txt
+
 MYRICOM MYRI-10G 10GbE DRIVER (MYRI10GE)
 M: Hyong-Youb Kim 
 L: netdev at vger.kernel.org
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index fc35731..5b1e7bc 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -290,3 +290,5 @@ source "drivers/gpu/drm/arc/Kconfig"
 source "drivers/gpu/drm/hisilicon/Kconfig"

 source "drivers/gpu/drm/mediatek/Kconfig"
+
+source "drivers/gpu/drm/mxsfb/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index be43afb..cbb638d 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -82,3 +82,4 @@ obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
 obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/
 obj-$(CONFIG_DRM_ARCPGU)+= arc/
 obj-y  += hisilicon/
+obj-$(CONFIG_DRM_MXSFB)+= mxsfb/
diff --git a/drivers/gpu/drm/mxsfb/Kconfig b/drivers/gpu/drm/mxsfb/Kconfig
new file mode 100644
index 000..0b6cb59
--- /dev/null
+++ b/drivers/gpu/drm/mxsfb/Kconfig
@@ -0,0 +1,18 @@
+config DRM_MXS
+   bool
+   help
+ Choose this option to select drivers for MXS FB devices
+
+config DRM_MXSFB
+   tristate "i.MX23/i.MX28/i.MX6SX MXSFB LCD controller"
+   depends on DRM && OF
+   depends on COMMON_CLK
+   select DRM_MXS
+   select DRM_KMS_HELPER
+   select DRM_KMS_FB_HELPER
+   select DRM_KMS_CMA_HELPER
+   help
+ Choose this option if you have an i.MX23/i.MX28/i.MX6SX MXSFB
+ LCD controller.
+
+ If M is selected the module will be called mxsfb.
diff --git a/drivers/gpu/drm/mxsfb/Makefile b/drivers/gpu/drm/mxsfb/Makefile
new file mode 100644
index 000..857f3a4
--- /dev/null
+++ b/drivers/gpu/drm/mxsfb/Makefile
@@ -0,0 +1,2 @@
+mxsfb-y := mxsfb_drv.o mxsfb_crtc.o mxsfb_out.o
+obj-$(CONFIG_DRM_MXSFB)+= mxsfb.o
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c 
b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
new file mode 100644
index 000..5d2e2a1
--- /dev/null
+++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
@@ -0,0 +1,395 @@
+/*
+ * Copyright (C) 2016 Marek Vasut 
+ *
+ * This code is based on drivers/video/fbdev/mxsfb.c :
+ * Copyright (C) 2010 Juergen Beisert, Pengutronix
+ * Copyright (C) 2008-2009 Freescale Semiconductor, Inc. All Rights Reserved.
+ * Copyright (C) 2008 Embedded Alley Solutions, Inc All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "mxsfb_drv.h"
+#include "mxsfb_regs.h"
+
+static void mxsfb_enable_axi_clk(struct mxsfb_drm_private *mxsfb)
+{
+   if (mxsfb->clk_axi)
+   clk_prepare_enable(mxsfb->clk_axi);
+}
+
+static void mxsfb_disable_axi_clk(struct mxsfb_drm_private *mxsfb)
+{
+   if (mxsfb->clk_axi)
+  

[PATCH 1/2] dt-bindings: mxsfb: Add bindings for the MXSFB KMS/DRM driver

[Marek Vasut]

Add DT bindings for new MXSFB driver using the DRM framework.
The old MXSFB fbdev driver bindings are preserved in mxsfb.txt .

Signed-off-by: Marek Vasut 
Cc: devicetree at vger.kernel.org
Cc: Rob Herring 
Cc: Lucas Stach 
Cc: Fabio Estevam 
Cc: Shawn Guo 
---
 .../devicetree/bindings/display/mxsfb-drm.txt  | 33 ++
 1 file changed, 33 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/mxsfb-drm.txt

diff --git a/Documentation/devicetree/bindings/display/mxsfb-drm.txt 
b/Documentation/devicetree/bindings/display/mxsfb-drm.txt
new file mode 100644
index 000..e70d337
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/mxsfb-drm.txt
@@ -0,0 +1,33 @@
+* Freescale MXS LCD Interface (LCDIF) with KMS/DRM support
+
+Required properties:
+- compatible:  Should be "fsl,imx23-lcdif" for i.MX23.
+   Should be "fsl,imx28-lcdif" for i.MX28 and i.MX6SX.
+- reg: Address and length of the register set for lcdif
+- interrupts:  Should contain lcdif interrupts
+- clocks:  A list of phandle + clock-specifier pairs, one for each
+   entry in 'clock-names'.
+- clock-names: A list of clock names. For MXSFB it should contain:
+- "pix" for the MXSFB block clock
+- (optional) "axi", "disp_axi" for the bus interface clock on MX6SX
+
+Required sub-nodes:
+  - port: The connection to an encoder chip.
+
+Example:
+
+   lcdif1: lcdif at 0222 {
+   compatible = "fsl,imx6sx-lcdif", "fsl,imx28-lcdif";
+   reg = <0x0222 0x4000>;
+   interrupts = ;
+   clocks = < IMX6SX_CLK_LCDIF1_PIX>,
+< IMX6SX_CLK_LCDIF_APB>,
+< IMX6SX_CLK_DISPLAY_AXI>;
+   clock-names = "pix", "axi", "disp_axi";
+
+   port {
+   parallel_out: endpoint {
+   remote-endpoint = <_in_parallel>;
+   };
+   };
+   };
-- 
2.9.3

[PATCH] drm/etnaviv: Always init gpu->memory_base

[Marek Vasut]

The content of gpu->memory_base should point to start of RAM, not zero.

Signed-off-by: Marek Vasut 
Cc: Lucas Stach 
Cc: Christian Gmeiner 
Cc: Russell King 
---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index ff6aa5d..a168532 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -588,6 +588,8 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
gpu->memory_base = PHYS_OFFSET;
else
gpu->memory_base = dma_mask - SZ_2G + 1;
+   } else {
+   gpu->memory_base = PHYS_OFFSET;
}

ret = etnaviv_hw_reset(gpu);
-- 
2.9.3

[PATCH] drm/panel: simple: Fix bus flags for ortustech com43h4m85ulc

[Marek Vasut]

This display expects DE pin to be active high, add the necessary flag.

Signed-off-by: Marek Vasut 
Cc: Philipp Zabel 
Cc: Thierry Reding 
---
 drivers/gpu/drm/panel/panel-simple.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 3a7bdf1..f4c546d 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1198,6 +1198,7 @@ static const struct panel_desc ortustech_com43h4m85ulc = {
.height = 93,
},
.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+   .bus_flags = DRM_BUS_FLAG_DE_HIGH,
 };

 static const struct drm_display_mode qd43003c0_40_mode = {
-- 
2.9.3

[PATCH v8 18/18] drm/virtio: kconfig: Fixup white space.

[Peter Griffin]

Use tabs instead of spaces.

Signed-off-by: Peter Griffin 
---
 drivers/gpu/drm/virtio/Kconfig | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/virtio/Kconfig b/drivers/gpu/drm/virtio/Kconfig
index 90357d9..2d83932 100644
--- a/drivers/gpu/drm/virtio/Kconfig
+++ b/drivers/gpu/drm/virtio/Kconfig
@@ -2,10 +2,10 @@ config DRM_VIRTIO_GPU
tristate "Virtio GPU driver"
depends on DRM
select VIRTIO
-select DRM_KMS_HELPER
-select DRM_TTM
+   select DRM_KMS_HELPER
+   select DRM_TTM
help
   This is the virtual GPU driver for virtio.  It can be used with
-   QEMU based VMMs (like KVM or Xen).
+  QEMU based VMMs (like KVM or Xen).

   If unsure say M.
-- 
1.9.1

[PATCH v8 17/18] drm/virtio: kconfig: Fix recursive dependency.

[Peter Griffin]

[..]
drivers/video/fbdev/Kconfig:5:error: recursive dependency detected!
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:5:  symbol FB is selected by DRM_KMS_FB_HELPER
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/Kconfig:42: symbol DRM_KMS_FB_HELPER depends on 
DRM_KMS_HELPER
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/Kconfig:36: symbol DRM_KMS_HELPER is selected by 
DRM_VIRTIO_GPU
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/virtio/Kconfig:1:   symbol DRM_VIRTIO_GPU depends on VIRTIO
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/virtio/Kconfig:1:   symbol VIRTIO is selected by REMOTEPROC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/remoteproc/Kconfig:4:   symbol REMOTEPROC is selected by 
ST_SLIM_REMOTEPROC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/remoteproc/Kconfig:103: symbol ST_SLIM_REMOTEPROC is selected by ST_FDMA
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/dma/Kconfig:440:symbol ST_FDMA depends on DMADEVICES
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/dma/Kconfig:5:  symbol DMADEVICES is selected by SND_SOC_SH4_SIU
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
sound/soc/sh/Kconfig:29:symbol SND_SOC_SH4_SIU is selected by 
SND_SIU_MIGOR
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
sound/soc/sh/Kconfig:64:symbol SND_SIU_MIGOR depends on I2C
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/i2c/Kconfig:7:  symbol I2C is selected by FB_DDC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:63: symbol FB_DDC is selected by FB_CYBER2000_DDC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:378:symbol FB_CYBER2000_DDC depends on 
FB_CYBER2000
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:366:symbol FB_CYBER2000 depends on FB

Signed-off-by: Peter Griffin 
---
 drivers/gpu/drm/virtio/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/virtio/Kconfig b/drivers/gpu/drm/virtio/Kconfig
index e1afc3d..90357d9 100644
--- a/drivers/gpu/drm/virtio/Kconfig
+++ b/drivers/gpu/drm/virtio/Kconfig
@@ -1,6 +1,7 @@
 config DRM_VIRTIO_GPU
tristate "Virtio GPU driver"
-   depends on DRM && VIRTIO
+   depends on DRM
+   select VIRTIO
 select DRM_KMS_HELPER
 select DRM_TTM
help
-- 
1.9.1

[PATCH v8 16/18] ARM: DT: STi: stihxxx-b2120: Add DT nodes for STi audio card

[Peter Griffin]

This patch enables the uniperif players 2 & 3 for b2120 boards
and also adds the "simple-audio-card" device node to interconnect
the SoC sound device and the codec.

Signed-off-by: Arnaud Pouliquen 
Signed-off-by: Peter Griffin 
---
 arch/arm/boot/dts/stihxxx-b2120.dtsi | 45 
 1 file changed, 45 insertions(+)

diff --git a/arch/arm/boot/dts/stihxxx-b2120.dtsi 
b/arch/arm/boot/dts/stihxxx-b2120.dtsi
index 722c63f..1f64bb6 100644
--- a/arch/arm/boot/dts/stihxxx-b2120.dtsi
+++ b/arch/arm/boot/dts/stihxxx-b2120.dtsi
@@ -131,5 +131,50 @@
dvb-card= ;
};
};
+
+   sti_uni_player2: sti-uni-player at 2 {
+   status = "okay";
+   };
+
+   sti_uni_player3: sti-uni-player at 3 {
+   status = "okay";
+   };
+
+   sti_sasg_codec: sti-sasg-codec {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_spdif_out>;
+   };
+
+   sound {
+   compatible = "simple-audio-card";
+   simple-audio-card,name = "sti audio card";
+   status = "okay";
+
+   simple-audio-card,dai-link at 0 {
+   /* DAC */
+   format = "i2s";
+   mclk-fs = <256>;
+   cpu {
+   sound-dai = <_uni_player2>;
+   };
+
+   codec {
+   sound-dai = <_sasg_codec 1>;
+   };
+   };
+   simple-audio-card,dai-link at 1 {
+   /* SPDIF */
+   format = "left_j";
+   mclk-fs = <128>;
+   cpu {
+   sound-dai = <_uni_player3>;
+   };
+
+   codec {
+   sound-dai = <_sasg_codec 0>;
+   };
+   };
+   };
};
 };
-- 
1.9.1

[PATCH v8 15/18] ARM: STi: DT: STiH407: Add uniperif reader dt nodes

[Peter Griffin]

This patch adds the DT node for the uniperif reader
IP block found on STiH407 family silicon.

Signed-off-by: Arnaud Pouliquen 
Signed-off-by: Peter Griffin 
---
 arch/arm/boot/dts/stih407-family.dtsi | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm/boot/dts/stih407-family.dtsi 
b/arch/arm/boot/dts/stih407-family.dtsi
index d263c96..bdddf2c 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -956,5 +956,31 @@
st,version = <5>;
st,mode = "SPDIF";
};
+
+   sti_uni_reader0: sti-uni-reader at 0 {
+   compatible = "st,sti-uni-reader";
+   status = "disabled";
+   #sound-dai-cells = <0>;
+   st,syscfg = <_core>;
+   reg = <0x8D83000 0x158>;
+   interrupts = ;
+   dmas = < 5 0 1>;
+   dma-names = "rx";
+   dai-name = "Uni Reader #0 (PCM IN)";
+   st,version = <3>;
+   };
+
+   sti_uni_reader1: sti-uni-reader at 1 {
+   compatible = "st,sti-uni-reader";
+   status = "disabled";
+   #sound-dai-cells = <0>;
+   st,syscfg = <_core>;
+   reg = <0x8D84000 0x158>;
+   interrupts = ;
+   dmas = < 6 0 1>;
+   dma-names = "rx";
+   dai-name = "Uni Reader #1 (HDMI RX)";
+   st,version = <3>;
+   };
};
 };
-- 
1.9.1

[PATCH v8 14/18] ARM: STi: DT: STiH407: Add uniperif player dt nodes

[Peter Griffin]

This patch adds the DT nodes for the uniperif player
IP blocks found on STiH407 family silicon.

Signed-off-by: Arnaud Pouliquen 
Signed-off-by: Peter Griffin 
---
 arch/arm/boot/dts/stih407-family.dtsi | 76 +++
 1 file changed, 76 insertions(+)

diff --git a/arch/arm/boot/dts/stih407-family.dtsi 
b/arch/arm/boot/dts/stih407-family.dtsi
index d1258d5..d263c96 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -880,5 +880,81 @@
status = "disabled";
st,syscfg = <_core>;
};
+
+   sti_uni_player0: sti-uni-player at 0 {
+   compatible = "st,sti-uni-player";
+   status = "disabled";
+   #sound-dai-cells = <0>;
+   st,syscfg = <_core>;
+   clocks = <_s_d0_flexgen CLK_PCM_0>;
+   assigned-clocks = <_s_d0_quadfs 0>, 
<_s_d0_flexgen CLK_PCM_0>;
+   assigned-clock-parents = <0>, <_s_d0_quadfs 0>;
+   assigned-clock-rates = <5000>;
+   reg = <0x8D8 0x158>;
+   interrupts = ;
+   dmas = < 2 0 1>;
+   dai-name = "Uni Player #0 (HDMI)";
+   dma-names = "tx";
+   st,uniperiph-id = <0>;
+   st,version = <5>;
+   st,mode = "HDMI";
+   };
+
+   sti_uni_player1: sti-uni-player at 1 {
+   compatible = "st,sti-uni-player";
+   status = "disabled";
+   #sound-dai-cells = <0>;
+   st,syscfg = <_core>;
+   clocks = <_s_d0_flexgen CLK_PCM_1>;
+   assigned-clocks = <_s_d0_quadfs 1>, 
<_s_d0_flexgen CLK_PCM_1>;
+   assigned-clock-parents = <0>, <_s_d0_quadfs 1>;
+   assigned-clock-rates = <5000>;
+   reg = <0x8D81000 0x158>;
+   interrupts = ;
+   dmas = < 3 0 1>;
+   dai-name = "Uni Player #1 (PIO)";
+   dma-names = "tx";
+   st,uniperiph-id = <1>;
+   st,version = <5>;
+   st,mode = "PCM";
+   };
+
+   sti_uni_player2: sti-uni-player at 2 {
+   compatible = "st,sti-uni-player";
+   status = "disabled";
+   #sound-dai-cells = <0>;
+   st,syscfg = <_core>;
+   clocks = <_s_d0_flexgen CLK_PCM_2>;
+   assigned-clocks = <_s_d0_quadfs 2>, 
<_s_d0_flexgen CLK_PCM_2>;
+   assigned-clock-parents = <0>, <_s_d0_quadfs 2>;
+   assigned-clock-rates = <5000>;
+   reg = <0x8D82000 0x158>;
+   interrupts = ;
+   dmas = < 4 0 1>;
+   dai-name = "Uni Player #1 (DAC)";
+   dma-names = "tx";
+   st,uniperiph-id = <2>;
+   st,version = <5>;
+   st,mode = "PCM";
+   };
+
+   sti_uni_player3: sti-uni-player at 3 {
+   compatible = "st,sti-uni-player";
+   status = "disabled";
+   #sound-dai-cells = <0>;
+   st,syscfg = <_core>;
+   clocks = <_s_d0_flexgen CLK_SPDIFF>;
+   assigned-clocks = <_s_d0_quadfs 3>, 
<_s_d0_flexgen CLK_SPDIFF>;
+   assigned-clock-parents = <0>, <_s_d0_quadfs 3>;
+   assigned-clock-rates = <5000>;
+   reg = <0x8D85000 0x158>;
+   interrupts = ;
+   dmas = < 7 0 1>;
+   dma-names = "tx";
+   dai-name = "Uni Player #1 (PIO)";
+   st,uniperiph-id = <3>;
+   st,version = <5>;
+   st,mode = "SPDIF";
+   };
};
 };
-- 
1.9.1

[PATCH v8 13/18] ARM: STi: DT: STiH407: Add sti-sasg-codec dt node

[Peter Griffin]

This patch adds the dt node for the internal audio
codec IP.

Signed-off-by: Arnaud Pouliquen 
Signed-off-by: Peter Griffin 
---
 arch/arm/boot/dts/stih407-family.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/stih407-family.dtsi 
b/arch/arm/boot/dts/stih407-family.dtsi
index 45cab30..d1258d5 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -873,5 +873,12 @@
<_s_c0_flexgen CLK_TX_ICN_DISP_0>,
<_s_c0_flexgen CLK_EXT2F_A9>;
};
+
+   sti_sasg_codec: sti-sasg-codec {
+   compatible = "st,stih407-sas-codec";
+   #sound-dai-cells = <1>;
+   status = "disabled";
+   st,syscfg = <_core>;
+   };
};
 };
-- 
1.9.1

[PATCH v8 12/18] ARM: DT: STiH407: Add spdif_out pinctrl config

[Peter Griffin]

This patch adds the pinctrl config for the spidf out
pins used by the sasg codec IP.

Signed-off-by: Arnaud Pouliquen 
Signed-off-by: Peter Griffin 
---
 arch/arm/boot/dts/stih407-pinctrl.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/stih407-pinctrl.dtsi 
b/arch/arm/boot/dts/stih407-pinctrl.dtsi
index 537db7e..598dbab 100644
--- a/arch/arm/boot/dts/stih407-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stih407-pinctrl.dtsi
@@ -1114,6 +1114,14 @@
};
};

+   spdif_out {
+   pinctrl_spdif_out: spdif_out{
+   st,pins {
+   spdif_out = < 7 ALT1 OUT>;
+   };
+   };
+   };
+
serial3 {
pinctrl_serial3: serial3-0 {
st,pins {
-- 
1.9.1

[PATCH v8 11/18] ARM: DT: STiH407: Add i2s_in pinctrl configuration

[Peter Griffin]

This patch adds the pinctrl config for the i2s_in pins
used by the uniperif reader IP.

Signed-off-by: Arnaud Pouliquen 
Signed-off-by: Peter Griffin 
---
 arch/arm/boot/dts/stih407-pinctrl.dtsi | 24 
 1 file changed, 24 insertions(+)

diff --git a/arch/arm/boot/dts/stih407-pinctrl.dtsi 
b/arch/arm/boot/dts/stih407-pinctrl.dtsi
index 0fb5c8a..537db7e 100644
--- a/arch/arm/boot/dts/stih407-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stih407-pinctrl.dtsi
@@ -1090,6 +1090,30 @@
};
};

+   i2s_in {
+   pinctrl_i2s_8ch_in: i2s_8ch_in{
+   st,pins {
+   mclk = < 5 ALT1 IN>;
+   lrclk = < 7 ALT1 IN>;
+   sclk = < 6 ALT1 IN>;
+   data0 = < 4 ALT1 IN>;
+   data1 = < 0 ALT1 IN>;
+   data2 = < 1 ALT1 IN>;
+   data3 = < 2 ALT1 IN>;
+   data4 = < 3 ALT1 IN>;
+   };
+   };
+
+   pinctrl_i2s_2ch_in: i2s_2ch_in{
+   st,pins {
+   mclk = < 5 ALT1 IN>;
+   lrclk = < 7 ALT1 IN>;
+   sclk = < 6 ALT1 IN>;
+   data0 = < 4 ALT1 IN>;
+   };
+   };
+   };
+
serial3 {
pinctrl_serial3: serial3-0 {
st,pins {
-- 
1.9.1

[PATCH v8 10/18] ARM: DT: STiH407: Add i2s_out pinctrl configuration

[Peter Griffin]

This patch adds the pinctrl config for the i2s_out pins
used by the uniperif player IP.

Signed-off-by: Arnaud Pouliquen 
Signed-off-by: Peter Griffin 
---
 arch/arm/boot/dts/stih407-pinctrl.dtsi | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm/boot/dts/stih407-pinctrl.dtsi 
b/arch/arm/boot/dts/stih407-pinctrl.dtsi
index a538ae5..0fb5c8a 100644
--- a/arch/arm/boot/dts/stih407-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stih407-pinctrl.dtsi
@@ -1067,6 +1067,29 @@
};
};

+   i2s_out {
+   pinctrl_i2s_8ch_out: i2s_8ch_out{
+   st,pins {
+   mclk = < 5 ALT1 OUT>;
+   lrclk = < 7 ALT1 OUT>;
+   sclk = < 6 ALT1 OUT>;
+   data0 = < 4 ALT1 OUT>;
+   data1 = < 0 ALT1 OUT>;
+   data2 = < 1 ALT1 OUT>;
+   data3 = < 2 ALT1 OUT>;
+   };
+   };
+
+   pinctrl_i2s_2ch_out: i2s_2ch_out{
+   st,pins {
+   mclk = < 5 ALT1 OUT>;
+   lrclk = < 7 ALT1 OUT>;
+   sclk = < 6 ALT1 OUT>;
+   data0 = < 4 ALT1 OUT>;
+   };
+   };
+   };
+
serial3 {
pinctrl_serial3: serial3-0 {
st,pins {
-- 
1.9.1

[PATCH v8 09/18] ARM: multi_v7_defconfig: Enable STi and simple-card drivers.

[Peter Griffin]

This patch enables the STi ALSA drivers found on STi platforms
as well as the simple-card driver which is a dependency to have
working sound.

Signed-off-by: Peter Griffin 
Cc: arnaud.pouliquen at st.com
Cc: broonie at kernel.org
---
 arch/arm/configs/multi_v7_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 998578a..51a38b1 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -644,6 +644,9 @@ CONFIG_SND_SOC_AK4642=m
 CONFIG_SND_SOC_SGTL5000=m
 CONFIG_SND_SOC_SPDIF=m
 CONFIG_SND_SOC_WM8978=m
+CONFIG_SND_SOC_STI=m
+CONFIG_SND_SOC_STI_SAS=m
+CONFIG_SND_SIMPLE_CARD=m
 CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_MVEBU=y
-- 
1.9.1

[PATCH v8 08/18] ARM: multi_v7_defconfig: Enable STi FDMA driver

[Peter Griffin]

This DMA controller is found on all STi chipsets.

Signed-off-by: Peter Griffin 
Acked-by: Lee Jones 
---
 arch/arm/configs/multi_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index ea23250..998578a 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -784,6 +784,7 @@ CONFIG_DMA_OMAP=y
 CONFIG_QCOM_BAM_DMA=y
 CONFIG_XILINX_VDMA=y
 CONFIG_DMA_SUN6I=y
+CONFIG_ST_FDMA=m
 CONFIG_STAGING=y
 CONFIG_SENSORS_ISL29018=y
 CONFIG_SENSORS_ISL29028=y
-- 
1.9.1

[PATCH v8 07/18] MAINTAINERS: Add FDMA driver files to STi section.

[Peter Griffin]

This patch adds the FDMA driver files to the STi
section of the maintainers file.

Signed-off-by: Peter Griffin 
Acked-by: Lee Jones 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5dd3b24..d21a7b5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1739,6 +1739,7 @@ F:drivers/char/hw_random/st-rng.c
 F: drivers/clocksource/arm_global_timer.c
 F: drivers/clocksource/clksrc_st_lpc.c
 F: drivers/cpufreq/sti-cpufreq.c
+F: drivers/dma/st_fdma*
 F: drivers/i2c/busses/i2c-st.c
 F: drivers/media/rc/st_rc.c
 F: drivers/media/platform/sti/c8sectpfe/
-- 
1.9.1

[PATCH v8 06/18] ARM: STi: DT: STiH407: Add FDMA driver dt nodes.

[Peter Griffin]

These nodes are required to get the fdma driver working
on STiH407 based silicon.

Signed-off-by: Peter Griffin 
---
 arch/arm/boot/dts/stih407-family.dtsi | 52 +++
 1 file changed, 52 insertions(+)

diff --git a/arch/arm/boot/dts/stih407-family.dtsi 
b/arch/arm/boot/dts/stih407-family.dtsi
index d294e82..45cab30 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -821,5 +821,57 @@
clock-frequency = <6>;
st,syscfg   = <_core 0x224>;
};
+
+   /* fdma audio */
+   fdma0: dma-controller at 8e2 {
+   compatible = "st,stih407-fdma-mpe31-11", 
"st,slim-rproc";
+   reg = <0x8e2 0x8000>,
+ <0x8e3 0x3000>,
+ <0x8e37000 0x1000>,
+ <0x8e38000 0x8000>;
+   reg-names = "slimcore", "dmem", "peripherals", "imem";
+   clocks = <_s_c0_flexgen CLK_FDMA>,
+<_s_c0_flexgen CLK_EXT2F_A9>,
+<_s_c0_flexgen CLK_EXT2F_A9>,
+<_s_c0_flexgen CLK_EXT2F_A9>;
+   interrupts = ;
+   dma-channels = <16>;
+   #dma-cells = <3>;
+   };
+
+   /* fdma app */
+   fdma1: dma-controller at 8e4 {
+   compatible = "st,stih407-fdma-mpe31-12", 
"st,slim-rproc";
+   reg = <0x8e4 0x8000>,
+ <0x8e5 0x3000>,
+ <0x8e57000 0x1000>,
+ <0x8e58000 0x8000>;
+   reg-names = "slimcore", "dmem", "peripherals", "imem";
+   clocks = <_s_c0_flexgen CLK_FDMA>,
+   <_s_c0_flexgen CLK_TX_ICN_DMU>,
+   <_s_c0_flexgen CLK_TX_ICN_DMU>,
+   <_s_c0_flexgen CLK_EXT2F_A9>;
+
+   interrupts = ;
+   dma-channels = <16>;
+   #dma-cells = <3>;
+   };
+
+   /* fdma free running */
+   fdma2: dma-controller at 8e6 {
+   compatible = "st,stih407-fdma-mpe31-13", 
"st,slim-rproc";
+   reg = <0x8e6 0x8000>,
+ <0x8e7 0x3000>,
+ <0x8e77000 0x1000>,
+ <0x8e78000 0x8000>;
+   reg-names = "slimcore", "dmem", "peripherals", "imem";
+   interrupts = ;
+   dma-channels = <16>;
+   #dma-cells = <3>;
+   clocks = <_s_c0_flexgen CLK_FDMA>,
+   <_s_c0_flexgen CLK_EXT2F_A9>,
+   <_s_c0_flexgen CLK_TX_ICN_DISP_0>,
+   <_s_c0_flexgen CLK_EXT2F_A9>;
+   };
};
 };
-- 
1.9.1

[PATCH v8 05/18] dmaengine: st_fdma: Add STMicroelectronics FDMA engine driver support

[Peter Griffin]

This patch adds support for the Flexible Direct Memory Access (FDMA) core
driver. The FDMA is a slim core CPU with a dedicated firmware.
It is a general purpose DMA controller capable of supporting 16
independent DMA channels. Data moves maybe from memory to memory
or between memory and paced latency critical real time targets and it
is found on al STi based chipsets.

Signed-off-by: Ludovic Barre 
Signed-off-by: Peter Griffin 
---
 drivers/dma/Kconfig   |  14 +-
 drivers/dma/Makefile  |   1 +
 drivers/dma/st_fdma.c | 880 ++
 3 files changed, 894 insertions(+), 1 deletion(-)
 create mode 100644 drivers/dma/st_fdma.c

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 739f797..5b5a341 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -437,6 +437,19 @@ config STE_DMA40
help
  Support for ST-Ericsson DMA40 controller

+config ST_FDMA
+   tristate "ST FDMA dmaengine support"
+   depends on ARCH_STI
+   select ST_SLIM_REMOTEPROC
+   select DMA_ENGINE
+   select DMA_VIRTUAL_CHANNELS
+   help
+ Enable support for ST FDMA controller.
+ It supports 16 independent DMA channels, accepts up to 32 DMA requests
+
+ Say Y here if you have such a chipset.
+ If unsure, say N.
+
 config STM32_DMA
bool "STMicroelectronics STM32 DMA support"
depends on ARCH_STM32
@@ -567,7 +580,6 @@ config ZX_DMA
help
  Support the DMA engine for ZTE ZX296702 platform devices.

-
 # driver files
 source "drivers/dma/bestcomm/Kconfig"

diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index e4dc9ca..a4fa336 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_TI_DMA_CROSSBAR) += ti-dma-crossbar.o
 obj-$(CONFIG_TI_EDMA) += edma.o
 obj-$(CONFIG_XGENE_DMA) += xgene-dma.o
 obj-$(CONFIG_ZX_DMA) += zx296702_dma.o
+obj-$(CONFIG_ST_FDMA) += st_fdma.o

 obj-y += qcom/
 obj-y += xilinx/
diff --git a/drivers/dma/st_fdma.c b/drivers/dma/st_fdma.c
new file mode 100644
index 000..bb8d8a7
--- /dev/null
+++ b/drivers/dma/st_fdma.c
@@ -0,0 +1,880 @@
+/*
+ * st_fdma.c
+ *
+ * Copyright (C) 2014 STMicroelectronics
+ * Author: Ludovic Barre 
+ *Peter Griffin 
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "st_fdma.h"
+
+static inline struct st_fdma_chan *to_st_fdma_chan(struct dma_chan *c)
+{
+   return container_of(c, struct st_fdma_chan, vchan.chan);
+}
+
+static struct st_fdma_desc *to_st_fdma_desc(struct virt_dma_desc *vd)
+{
+   return container_of(vd, struct st_fdma_desc, vdesc);
+}
+
+static int st_fdma_dreq_get(struct st_fdma_chan *fchan)
+{
+   struct st_fdma_dev *fdev = fchan->fdev;
+   u32 req_line_cfg = fchan->cfg.req_line;
+   u32 dreq_line;
+   int try = 0;
+
+   /*
+* dreq_mask is shared for n channels of fdma, so all accesses must be
+* atomic. if the dreq_mask is changed between ffz and set_bit,
+* we retry
+*/
+   do {
+   if (fdev->dreq_mask == ~0L) {
+   dev_err(fdev->dev, "No req lines available\n");
+   return -EINVAL;
+   }
+
+   if (try || req_line_cfg >= ST_FDMA_NR_DREQS) {
+   dev_err(fdev->dev, "Invalid or used req line\n");
+   return -EINVAL;
+   } else {
+   dreq_line = req_line_cfg;
+   }
+
+   try++;
+   } while (test_and_set_bit(dreq_line, >dreq_mask));
+
+   dev_dbg(fdev->dev, "get dreq_line:%d mask:%#lx\n",
+   dreq_line, fdev->dreq_mask);
+
+   return dreq_line;
+}
+
+static void st_fdma_dreq_put(struct st_fdma_chan *fchan)
+{
+   struct st_fdma_dev *fdev = fchan->fdev;
+
+   dev_dbg(fdev->dev, "put dreq_line:%#x\n", fchan->dreq_line);
+   clear_bit(fchan->dreq_line, >dreq_mask);
+}
+
+static void st_fdma_xfer_desc(struct st_fdma_chan *fchan)
+{
+   struct virt_dma_desc *vdesc;
+   unsigned long nbytes, ch_cmd, cmd;
+
+   vdesc = vchan_next_desc(>vchan);
+   if (!vdesc)
+   return;
+
+   fchan->fdesc = to_st_fdma_desc(vdesc);
+   nbytes = fchan->fdesc->node[0].desc->nbytes;
+   cmd = FDMA_CMD_START(fchan->vchan.chan.chan_id);
+   ch_cmd = fchan->fdesc->node[0].pdesc | FDMA_CH_CMD_STA_START;
+
+   /* start the channel for the descriptor */
+   fnode_write(fchan, nbytes, FDMA_CNTN_OFST);
+   fchan_write(fchan, ch_cmd, FDMA_CH_CMD_OFST);
+   writel(cmd,
+   fchan->fdev->slim_rproc->peri + FDMA_CMD_SET_OFST);
+
+   dev_dbg(fchan->fdev->dev, "start chan:%d\n", fchan->vchan.chan.chan_id);
+}
+
+static void st_fdma_ch_sta_update(struct st_fdma_chan *fchan,
+ unsigned long int_sta)
+{
+   unsigned long ch_sta, ch_err;
+   

[PATCH v8 04/18] dmaengine: st_fdma: Add STMicroelectronics FDMA driver header file

[Peter Griffin]

This header file will also be used by the dma xbar driver in the
future.

Signed-off-by: Ludovic Barre 
Signed-off-by: Peter Griffin 
---
 drivers/dma/st_fdma.h | 244 ++
 1 file changed, 244 insertions(+)
 create mode 100644 drivers/dma/st_fdma.h

diff --git a/drivers/dma/st_fdma.h b/drivers/dma/st_fdma.h
new file mode 100644
index 000..16fa6f5
--- /dev/null
+++ b/drivers/dma/st_fdma.h
@@ -0,0 +1,244 @@
+/*
+ * st_fdma.h
+ *
+ * Copyright (C) 2014 STMicroelectronics
+ * Author: Ludovic Barre 
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+#ifndef __DMA_ST_FDMA_H
+#define __DMA_ST_FDMA_H
+
+#include 
+#include 
+#include 
+#include 
+#include "virt-dma.h"
+
+#define ST_FDMA_NR_DREQS 32
+
+#define FW_NAME_SIZE 30
+
+/**
+ * struct st_fdma_generic_node - Free running/paced generic node
+ *
+ * @length: Length in bytes of a line in a 2D mem to mem
+ * @sstride: Stride, in bytes, between source lines in a 2D data move
+ * @dstride: Stride, in bytes, between destination lines in a 2D data move
+ */
+struct st_fdma_generic_node {
+   u32 length;
+   u32 sstride;
+   u32 dstride;
+};
+
+/**
+ * struct st_fdma_hw_node - Node structure used by fdma hw
+ *
+ * @next: Pointer to next node
+ * @control: Transfer Control Parameters
+ * @nbytes: Number of Bytes to read
+ * @saddr: Source address
+ * @daddr: Destination address
+ *
+ * @generic: generic node for free running/paced transfert type
+ * 2 others transfert type are possible, but not yet implemented
+ *
+ * The NODE structures must be aligned to a 32 byte boundary
+ */
+struct st_fdma_hw_node {
+   u32 next;
+   u32 control;
+   u32 nbytes;
+   u32 saddr;
+   u32 daddr;
+   union {
+   struct st_fdma_generic_node generic;
+   };
+} __aligned(32);
+
+/*
+ * node control parameters
+ */
+#define FDMA_NODE_CTRL_REQ_MAP_MASKGENMASK(4, 0)
+#define FDMA_NODE_CTRL_REQ_MAP_FREE_RUN0x0
+#define FDMA_NODE_CTRL_REQ_MAP_DREQ(n) ((n)_NODE_CTRL_REQ_MAP_MASK)
+#define FDMA_NODE_CTRL_REQ_MAP_EXT FDMA_NODE_CTRL_REQ_MAP_MASK
+#define FDMA_NODE_CTRL_SRC_MASKGENMASK(6, 5)
+#define FDMA_NODE_CTRL_SRC_STATIC  BIT(5)
+#define FDMA_NODE_CTRL_SRC_INCRBIT(6)
+#define FDMA_NODE_CTRL_DST_MASKGENMASK(8, 7)
+#define FDMA_NODE_CTRL_DST_STATIC  BIT(7)
+#define FDMA_NODE_CTRL_DST_INCRBIT(8)
+#define FDMA_NODE_CTRL_SECURE  BIT(15)
+#define FDMA_NODE_CTRL_PAUSE_EON   BIT(30)
+#define FDMA_NODE_CTRL_INT_EON BIT(31)
+
+/**
+ * struct st_fdma_sw_node - descriptor structure for link list
+ *
+ * @pdesc: Physical address of desc
+ * @node: link used for putting this into a channel queue
+ */
+struct st_fdma_sw_node {
+   dma_addr_t pdesc;
+   struct st_fdma_hw_node *desc;
+};
+
+#define NAME_SZ 10
+
+struct st_fdma_driverdata {
+   u32 id;
+   char name[NAME_SZ];
+};
+
+struct st_fdma_desc {
+   struct virt_dma_desc vdesc;
+   struct st_fdma_chan *fchan;
+   bool iscyclic;
+   unsigned int n_nodes;
+   struct st_fdma_sw_node node[];
+};
+
+enum st_fdma_type {
+   ST_FDMA_TYPE_FREE_RUN,
+   ST_FDMA_TYPE_PACED,
+};
+
+struct st_fdma_cfg {
+   struct device_node *of_node;
+   enum st_fdma_type type;
+   dma_addr_t dev_addr;
+   enum dma_transfer_direction dir;
+   int req_line; /* request line */
+   long req_ctrl; /* Request control */
+};
+
+struct st_fdma_chan {
+   struct st_fdma_dev *fdev;
+   struct dma_pool *node_pool;
+   struct dma_slave_config scfg;
+   struct st_fdma_cfg cfg;
+
+   int dreq_line;
+
+   struct virt_dma_chan vchan;
+   struct st_fdma_desc *fdesc;
+   enum dma_status status;
+};
+
+struct st_fdma_dev {
+   struct device *dev;
+   const struct st_fdma_driverdata *drvdata;
+   struct dma_device dma_device;
+
+   struct st_slim_rproc *slim_rproc;
+
+   int irq;
+
+   struct st_fdma_chan *chans;
+
+   spinlock_t dreq_lock;
+   unsigned long dreq_mask;
+
+   u32 nr_channels;
+   char fw_name[FW_NAME_SIZE];
+};
+
+/* Peripheral Registers*/
+
+#define FDMA_CMD_STA_OFST  0xFC0
+#define FDMA_CMD_SET_OFST  0xFC4
+#define FDMA_CMD_CLR_OFST  0xFC8
+#define FDMA_CMD_MASK_OFST 0xFCC
+#define FDMA_CMD_START(ch) (0x1 << (ch << 1))
+#define FDMA_CMD_PAUSE(ch) (0x2 << (ch << 1))
+#define FDMA_CMD_FLUSH(ch) (0x3 << (ch << 1))
+
+#define FDMA_INT_STA_OFST  0xFD0
+#define FDMA_INT_STA_CH0x1
+#define FDMA_INT_STA_ERR   0x2
+
+#define FDMA_INT_SET_OFST  0xFD4
+#define FDMA_INT_CLR_OFST  0xFD8
+#define FDMA_INT_MASK_OFST 0xFDC
+
+#define fdma_read(fdev, name) \
+   readl((fdev)->slim_rproc->peri + name)
+
+#define fdma_write(fdev, val, name) \
+   writel((val), (fdev)->slim_rproc->peri + name)
+
+/* fchan interface 

[PATCH v8 03/18] dmaengine: st_fdma: Add STMicroelectronics FDMA DT binding documentation

[Peter Griffin]

This patch adds the DT binding documentation for the FDMA constroller
found on STi based chipsets from STMicroelectronics.

Signed-off-by: Ludovic Barre 
Signed-off-by: Peter Griffin 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/dma/st_fdma.txt | 87 +++
 1 file changed, 87 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/st_fdma.txt

diff --git a/Documentation/devicetree/bindings/dma/st_fdma.txt 
b/Documentation/devicetree/bindings/dma/st_fdma.txt
new file mode 100644
index 000..495d853
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/st_fdma.txt
@@ -0,0 +1,87 @@
+* STMicroelectronics Flexible Direct Memory Access Device Tree bindings
+
+The FDMA is a general-purpose direct memory access controller capable of
+supporting 16 independent DMA channels. It accepts up to 32 DMA requests.
+The FDMA is based on a Slim processor which requires a firmware.
+
+* FDMA Controller
+
+Required properties:
+- compatible   : Should be one of
+- st,stih407-fdma-mpe31-11, "st,slim-rproc";
+- st,stih407-fdma-mpe31-12, "st,slim-rproc";
+- st,stih407-fdma-mpe31-13, "st,slim-rproc";
+- reg  : Should contain an entry for each name in reg-names
+- reg-names: Must contain "slimcore", "dmem", "peripherals", "imem" entries
+- interrupts   : Should contain one interrupt shared by all channels
+- dma-channels : Number of channels supported by the controller
+- #dma-cells   : Must be <3>. See DMA client section below
+- clocks   : Must contain an entry for each clock
+See: Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+
+Example:
+
+   fdma0: dma-controller at 8e2 {
+   compatible = "st,stih407-fdma-mpe31-11", "st,slim-rproc";
+   reg = <0x8e2 0x8000>,
+ <0x8e3 0x3000>,
+ <0x8e37000 0x1000>,
+ <0x8e38000 0x8000>;
+   reg-names = "slimcore", "dmem", "peripherals", "imem";
+   clocks = <_s_c0_flexgen CLK_FDMA>,
+<_s_c0_flexgen CLK_EXT2F_A9>,
+<_s_c0_flexgen CLK_EXT2F_A9>,
+<_s_c0_flexgen CLK_EXT2F_A9>;
+   interrupts = ;
+   dma-channels = <16>;
+   #dma-cells = <3>;
+   };
+
+* DMA client
+
+Required properties:
+- dmas: Comma separated list of dma channel requests
+- dma-names: Names of the aforementioned requested channels
+
+Each dmas request consists of 4 cells:
+1. A phandle pointing to the FDMA controller
+2. The request line number
+3. A 32bit mask specifying (see include/linux/platform_data/dma-st-fdma.h)
+ -bit 2-0: Holdoff value, dreq will be masked for
+   0x0: 0-0.5us
+   0x1: 0.5-1us
+   0x2: 1-1.5us
+ -bit 17: data swap
+   0x0: disabled
+   0x1: enabled
+ -bit 21: Increment Address
+   0x0: no address increment between transfers
+   0x1: increment address between transfers
+ -bit 22: 2 STBus Initiator Coprocessor interface
+   0x0: high priority port
+   0x1: low priority port
+4. transfers type
+ 0 free running
+ 1 paced
+
+Example:
+
+   sti_uni_player2: sti-uni-player at 2 {
+   compatible = "st,sti-uni-player";
+   status = "disabled";
+   #sound-dai-cells = <0>;
+   st,syscfg = <_core>;
+   clocks = <_s_d0_flexgen CLK_PCM_2>;
+   assigned-clocks = <_s_d0_flexgen CLK_PCM_2>;
+   assigned-clock-parents = <_s_d0_quadfs 2>;
+   assigned-clock-rates = <5000>;
+   reg = <0x8D82000 0x158>;
+   interrupts = ;
+   dmas = < 4 0 1>;
+   dai-name = "Uni Player #1 (DAC)";
+   dma-names = "tx";
+   st,uniperiph-id = <2>;
+   st,version = <5>;
+   st,mode = "PCM";
+   };
-- 
1.9.1

[PATCH v8 02/18] MAINTAINERS: Add st slim core rproc driver to STi section.

[Peter Griffin]

This patch adds the slim core rproc driver to the STi section
of the MAINTAINERS file.

Signed-off-by: Peter Griffin 
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 0bbe4b1..5dd3b24 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1749,6 +1749,7 @@ F:drivers/phy/phy-stih407-usb.c
 F: drivers/phy/phy-stih41x-usb.c
 F: drivers/pinctrl/pinctrl-st.c
 F: drivers/remoteproc/st_remoteproc.c
+F: drivers/remoteproc/st_slim_rproc.c
 F: drivers/reset/sti/
 F: drivers/rtc/rtc-st-lpc.c
 F: drivers/tty/serial/st-asc.c
@@ -1757,6 +1758,7 @@ F:drivers/usb/host/ehci-st.c
 F: drivers/usb/host/ohci-st.c
 F: drivers/watchdog/st_lpc_wdt.c
 F: drivers/ata/ahci_st.c
+F: include/linux/remoteproc/st_slim_rproc.h

 ARM/STM32 ARCHITECTURE
 M: Maxime Coquelin 
-- 
1.9.1

[PATCH v8 01/18] remoteproc: st_slim_rproc: add a slimcore rproc driver

[Peter Griffin]

slim core is used as a basis for many IPs in the STi
chipsets such as fdma and demux. To avoid duplicating
the elf loading code in each device driver a slim
rproc driver has been created.

This driver is designed to be used by other device drivers
such as fdma, or demux whose IP is based around a slim core.
The device driver can call slim_rproc_alloc() to allocate
a slim rproc and slim_rproc_put() when finished.

This driver takes care of ioremapping the slim
registers (dmem, imem, slimcore, peripherals), whose offsets
and sizes can change between IP's. It also obtains and enables
any clocks used by the device. This approach avoids having
a double mapping of the registers as slim_rproc does not register
its own platform device. It also maps well to device tree
abstraction as it allows us to have one dt node for the whole
device.

All of the generic rproc elf loading code can be reused, and
we provide start() stop() hooks to start and stop the slim
core once the firmware has been loaded. This has been tested
successfully with fdma driver.

Signed-off-by: Peter Griffin 
---
 drivers/remoteproc/Kconfig   |   8 +
 drivers/remoteproc/Makefile  |   1 +
 drivers/remoteproc/st_slim_rproc.c   | 364 +++
 include/linux/remoteproc/st_slim_rproc.h |  53 +
 4 files changed, 426 insertions(+)
 create mode 100644 drivers/remoteproc/st_slim_rproc.c
 create mode 100644 include/linux/remoteproc/st_slim_rproc.h

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 1a8bf76a..06765e0 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -100,4 +100,12 @@ config ST_REMOTEPROC
  processor framework.
  This can be either built-in or a loadable module.

+config ST_SLIM_REMOTEPROC
+   tristate "ST Slim remoteproc support"
+   select REMOTEPROC
+   help
+ Say y here to support firmware loading on IP based around
+ the Slim core.
+ If unsure say N.
+
 endmenu
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 92d3758..db1dae7 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -14,3 +14,4 @@ obj-$(CONFIG_DA8XX_REMOTEPROC)+= 
da8xx_remoteproc.o
 obj-$(CONFIG_QCOM_MDT_LOADER)  += qcom_mdt_loader.o
 obj-$(CONFIG_QCOM_Q6V5_PIL)+= qcom_q6v5_pil.o
 obj-$(CONFIG_ST_REMOTEPROC)+= st_remoteproc.o
+obj-$(CONFIG_ST_SLIM_REMOTEPROC)   += st_slim_rproc.o
diff --git a/drivers/remoteproc/st_slim_rproc.c 
b/drivers/remoteproc/st_slim_rproc.c
new file mode 100644
index 000..f4bf2d7
--- /dev/null
+++ b/drivers/remoteproc/st_slim_rproc.c
@@ -0,0 +1,364 @@
+/*
+ * st_slim_rproc.c
+ *
+ * Copyright (C) 2016 STMicroelectronics
+ * Author: Peter Griffin 
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "remoteproc_internal.h"
+
+/* slimcore registers */
+#define SLIM_ID_OFST   0x0
+#define SLIM_VER_OFST  0x4
+
+#define SLIM_EN_OFST   0x8
+#define SLIM_EN_RUNBIT(0)
+
+#define SLIM_CLK_GATE_OFST 0xC
+#define SLIM_CLK_GATE_DIS  BIT(0)
+#define SLIM_CLK_GATE_RESETBIT(2)
+
+#define SLIM_SLIM_PC_OFST  0x20
+
+/* dmem registers */
+#define SLIM_REV_ID_OFST   0x0
+#define SLIM_REV_ID_MIN_MASK   GENMASK(15, 8)
+#define SLIM_REV_ID_MIN(id)((id & SLIM_REV_ID_MIN_MASK) >> 8)
+#define SLIM_REV_ID_MAJ_MASK   GENMASK(23, 16)
+#define SLIM_REV_ID_MAJ(id)((id & SLIM_REV_ID_MAJ_MASK) >> 16)
+
+
+/* peripherals registers */
+#define SLIM_STBUS_SYNC_OFST   0xF88
+#define SLIM_STBUS_SYNC_DISBIT(0)
+
+#define SLIM_INT_SET_OFST  0xFD4
+#define SLIM_INT_CLR_OFST  0xFD8
+#define SLIM_INT_MASK_OFST 0xFDC
+
+#define SLIM_CMD_CLR_OFST  0xFC8
+#define SLIM_CMD_MASK_OFST 0xFCC
+
+static const char *mem_names[ST_SLIM_MEM_MAX] = {
+   [ST_SLIM_DMEM]  = "dmem",
+   [ST_SLIM_IMEM]  = "imem",
+};
+
+static int slim_clk_get(struct st_slim_rproc *slim_rproc, struct device *dev)
+{
+   int clk, err;
+
+   for (clk = 0; clk < ST_SLIM_MAX_CLK; clk++) {
+   slim_rproc->clks[clk] = of_clk_get(dev->of_node, clk);
+   if (IS_ERR(slim_rproc->clks[clk])) {
+   err = PTR_ERR(slim_rproc->clks[clk]);
+   if (err == -EPROBE_DEFER)
+   goto err_put_clks;
+   slim_rproc->clks[clk] = NULL;
+   break;
+   }
+   }
+
+   return 0;
+
+err_put_clks:
+   while (--clk >= 0)
+   clk_put(slim_rproc->clks[clk]);
+
+   return err;
+}
+
+static void slim_clk_disable(struct st_slim_rproc *slim_rproc)
+{
+   int clk;
+
+   for (clk = 0; clk < ST_SLIM_MAX_CLK && slim_rproc->clks[clk]; clk++)
+  

[PATCH v8 00/18] Add support for FDMA DMA controller and slim core rproc found on STi chipsets

[Peter Griffin]

Hi Vinod, Bjorn, Patrice,

This patchset adds support for the Flexible Direct Memory Access (FDMA) core
found on STi chipsets from STMicroelectronics. The FDMA is a slim core CPU
with a dedicated firmware. It is a general purpose DMA controller supporting
16 independent channels and data can be moved from memory to memory or between
memory and paced latency critical real time targets.

After quite a few review rounds, I'm hoping this series can get taken for v4.9.

After some discussion with the DT maintainers I've removed the firmware
name from DT, and now generate the name based on the compatible string.

I've also dropped the dma xbar support for the moment, as I believe it should be
re-worked based on some of the xbar API's that TI recently added.

V3 also included some updates to the ASoC st,sti-asoc-card.txt DT documentation
to make the doc align with the driver code. These patches have already been 
applied
and are now dropped from this series. Other changes included enabling the ASoC 
drivers
in multi_v7 defconfig and adding DT patches for Patrices STi DT tree to enable 
ASoC
on STiH407/10 based platforms using the fdma driver.

v4 includes a new slim core rproc driver for loading the slim elf firmware. This
enables us to use the generic rproc elf loading code. This has deliberately not
been implemented as a platform_driver, to avoid having to have double mappings 
of
I/O memory from two device drivers, and also to ensure that the DT node reflects
the actual hardware rather than Linux subsystems. The slim core is the basis
for various pieces of IP in STi chipsets and the intention is that other drivers
(e.g. demux) can also be migrated over to using the slim rproc for their
elf firmware loading and start/stop control.

v5 includes various updates from Bjorn related to the slim rproc implementation.
It also includes a patch to make rsc_table optional in remoteproc_core and 
various
other cleanups and review feedback from Vinod to do with the actual fdma
implementation. It also fixes a regression introduced in v4 when all drivers are
built-in spotted by Aranud.

v6 goes back to having a dummy rsc_table and fixes some kbuild warnings. However
a change is still required in rproc core when all drivers are built-in as the 
initial
async firmware resource table parsing can fail when built-in, which causes 
subsequent calls
to rproc_boot() to also fail. V6 changes this behaviour to retry 
rproc_fw_config_virtio()
from rproc_boot(), in cases where it previously failed, as at this point we 
know the
irmwaref has been successfully obtained.

v7 removes all remoteproc core changes required to get -EPROBE_DEFER working 
properly
when firmware resides on a rootfs and compiling as built-in. The fdma driver 
now relies on
the firmware being available in the initramfs when building fdma as built-in. 
This has
been tested and works well. If remoteproc subsystem implements a new mechanism 
for
firmware on late mounted root filesystems, we can migrate this driver over to 
use it
at that point.

v8 actions some review feedback from Bjorn to the slim rproc driver, and also 
includes
a patch which fixes a recursive Kconfig error which is triggered when st_fdma 
selects
slim_rproc driver. The series has also been rebased on v4.8-rc3.

regards,

Peter.

Changes since v7:
 - Rebase on v4.8-rc3 (Peter)
 - Double check that len is <= mem[i].size (Bjorn)
 - Remove if (!fw) checks (Bjorn)
 - Omit reference from fw_ops struct (Bjorn)
 - Call rproc_del() before rproc_put() (Bjorn)
 - Fix some odd line breaks (Bjorn)
 - Rename SLIM_* and slim_* with st prefix (Bjorn)

Changes since v6:
 - Fix recursive Kconfig warning (Patrice)
 - Fix various Intel zero day compiler warnings
 - Remove all changes related to late firmware load (now relies on initramfs) 
(Peter)

Changes since v5:
 - Remove optional rsc table and go back to dummy resource table (Bjorn)
 - Retry rproc_fw_config_virtio() from rproc_boot() if previously failed (Peter)
 - Fixup some kbuild warnings
 - rebase on v4.7-rc5
 - Remove some patches which were merged via ASoC tree

Changes since v4:
 - Make rsc table optional in remoteproc (Peter)
 - Various fixups to STi audio DT nodes (Arnaud)
 - Bulk rename of xp70 to slim (Peter)
 - Update my email to @linaro.org (Lee)
 - rebase on v4.7-rc2 (Peter)
 - Don't make ST_SLIM_REMOTEPROC user selectable (Bjorn)
 - -EPROBE_DEFER if rproc_boot fails when allocating DMA channel (Arnaud / 
Peter)
 - Drop some unnecessary headers (Vinod / Bjorn)
 - Change to writel now we have several mappings (Bjorn)
 - Remove io_res, rproc, and some unused structure fields / #define (Bjorn)
 - put clks in error path, also put clks before rproc_put() (Bjorn)
 - Make enum less generic (Bjorn)
 - Make slim_rproc_alloc() return a st_slim_rproc reference (Bjorn)
 - Alphabetical naming in Kconfig & Makefile (Vinod)
 - Add FDMA prefix to REQ_CTRL* (Vinod)
 - Print ret on some error paths (Vinod)
 - Add some acked-by (Peter)

Changes since v3:
 - Remove 

[Bug 97500] Cannot unbind GPU from AMDGPU

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

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

Bug ID: 97500
   Summary: Cannot unbind GPU from AMDGPU
   Product: DRI
   Version: XOrg git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: commendsarnex at gmail.com

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

Hi guys. With AMDGPU, if I try to unbind my GPU from amdgpu, I get a hard
kernel lockup. My GPU is the RX 480. I'm currently on 4.7.2, but I've tried
drm-next-4.9 also. I've tried both echo $CARD_PCI_LOCATION > unbind, and
unbinding the vtcon and then modprobe -r amdgpu. When I had my HD 7950, the
echo $CARD_PCI_LOCATION > unbind method worked every time. I'm not sure how to
get any debug info, since even an ssh session locks up. I tried using pstore,
but no logs were saved.

Please let me know if you have any ideas or need any more info.

Thanks,
Sarnex

-- 
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/20160826/e096949b/attachment.html>

[RFC] drm: implement generic firmware eviction

[Maxime Ripard]

On Fri, Aug 26, 2016 at 02:58:51PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 26-08-16 14:52, Maxime Ripard wrote:
> >On Fri, Aug 26, 2016 at 11:02:17AM +0200, Hans de Goede wrote:
> >>Hi,
> >>
> >>On 26-08-16 10:58, Maxime Ripard wrote:
> >>>Hi,
> >>>
> >>>On Fri, Aug 26, 2016 at 10:43:55AM +0200, Hans de Goede wrote:
> >>>>>>I'm not sure we would want to remove the device at all, we
> >>>>>>certainly should not be removing the dt_node from the devicetree
> >>>>>>IMHO. Having that around to see how the bootloader set things up
> >>>>>>is really useful for debugging and normally we should never modify
> >>>>>>the devicetree as set up by the bootloader.
> >>>>>>
> >>>>>>Why not just unbind the driver from the platform device? That
> >>>>>>should be enough.
> >>>>>
> >>>>>That will leave IORESOURCE_MEM around, causing conflicts if
> >>>>>re-used/claimed by other devices/drivers. Furthermore, it is really
> >>>>>fragile leaving the device around, without any control over
> >>>>>possible future driver probing.
> >>>>
> >>>>Ah, good point. On ARM this currently typically is reserved by the 
> >>>>bootloader
> >>>>so never touched by the kernel at all, not even when the simplefb is no 
> >>>>longer
> >>>>used, actually returning this memory to the kernel after unbinding the 
> >>>>simplefb /
> >>>>destroying the simplefb platform-dev would be really good to do. We should
> >>>>probably figure out how that should be done before getting rid of
> >>>>remove_conflicting_framebuffers... (sorry).
> >>>
> >>>That would be rather easy to do. The firmware could generate a
> >>>reserved-memory node instead of passing a smaller memory size to the
> >>>kernel. That way, the kernel will know that it's actual ram that it
> >>>can reclaim.
> >>
> >>So when would the kernel reclaim the RAM then?
> >
> >When we kickout the framebuffer driver?
> 
> Yes that is when we _want_ it to reclaim the RAM, my question was when
> it will _actually_ happen ? I'm not familiar with the reserved-memory
> implementation. Does your answer mean that some driver must make an
> explicit call to get the memory reclaimed ?

The reserved-memory implementation is relying on memblock. I don't
think there is a function yet to remove a reserved memory region, but
its implementation would use memblock_free I guess.

Maxime

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

[PATCH v4 7/7] drm/imx: Add active plane reconfiguration support

[Liu Ying]

We don't support configuring active plane on-the-fly for imx-drm.
The relevant CRTC should be disabled before the plane configuration.
Of course, the plane itself should be disabled as well.

This patch adds active plane reconfiguration support by forcing CRTC
mode change in plane's ->atomic_check callback so that the CRTC
will be disabled before the plane configuration.

Suggested-by: Daniel Vetter 
Cc: Philipp Zabel 
Cc: David Airlie 
Cc: Russell King 
Cc: Peter Senna Tschudin 
Cc: Lucas Stach 
Signed-off-by: Liu Ying 
---
v4:
* Newly introduced in v4, but the logic is picked from patch 3/3 in v3.

 drivers/gpu/drm/imx/imx-drm-core.c | 26 +-
 drivers/gpu/drm/imx/ipuv3-plane.c  | 13 -
 2 files changed, 33 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
b/drivers/gpu/drm/imx/imx-drm-core.c
index 99fff6c..75f35ea 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -146,10 +146,34 @@ static void imx_drm_output_poll_changed(struct drm_device 
*drm)
drm_fbdev_cma_hotplug_event(imxdrm->fbhelper);
 }

+static int imx_drm_atomic_check(struct drm_device *dev,
+   struct drm_atomic_state *state)
+{
+   int ret;
+
+   ret = drm_atomic_helper_check_modeset(dev, state);
+   if (ret)
+   return ret;
+
+   ret = drm_atomic_helper_check_planes(dev, state);
+   if (ret)
+   return ret;
+
+   /*
+* Check modeset again in case crtc_state->mode_changed is
+* updated in plane's ->atomic_check callback.
+*/
+   ret = drm_atomic_helper_check_modeset(dev, state);
+   if (ret)
+   return ret;
+
+   return ret;
+}
+
 static const struct drm_mode_config_funcs imx_drm_mode_config_funcs = {
.fb_create = drm_fb_cma_create,
.output_poll_changed = imx_drm_output_poll_changed,
-   .atomic_check = drm_atomic_helper_check,
+   .atomic_check = imx_drm_atomic_check,
.atomic_commit = drm_atomic_helper_commit,
 };

diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 6a48147..3c4f689 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -319,13 +319,16 @@ static int ipu_plane_atomic_check(struct drm_plane *plane,
return -EINVAL;

/*
-* since we cannot touch active IDMAC channels, we do not support
-* resizing the enabled plane or changing its format
+* We support resizing active plane or changing its format by
+* forcing CRTC mode change in plane's ->atomic_check callback
+* and disabling all affected active planes in CRTC's ->atomic_disable
+* callback.  The planes will be reenabled in plane's ->atomic_update
+* callback.
 */
if (old_fb && (state->src_w != old_state->src_w ||
  state->src_h != old_state->src_h ||
  fb->pixel_format != old_fb->pixel_format))
-   return -EINVAL;
+   crtc_state->mode_changed = true;

eba = drm_plane_state_to_eba(state);

@@ -336,7 +339,7 @@ static int ipu_plane_atomic_check(struct drm_plane *plane,
return -EINVAL;

if (old_fb && fb->pitches[0] != old_fb->pitches[0])
-   return -EINVAL;
+   crtc_state->mode_changed = true;

switch (fb->pixel_format) {
case DRM_FORMAT_YUV420:
@@ -372,7 +375,7 @@ static int ipu_plane_atomic_check(struct drm_plane *plane,
return -EINVAL;

if (old_fb && old_fb->pitches[1] != fb->pitches[1])
-   return -EINVAL;
+   crtc_state->mode_changed = true;
}

return 0;
-- 
2.7.4

[PATCH v4 6/7] drm/imx: Use DRM_PLANE_COMMIT_NO_DISABLE_AFTER_MODESET flag

[Liu Ying]

The IPUv3 display controller behind imx-drm needs all planes of
a CRTC be disabled when the CRTC is disabled.
The DRM_PLANE_COMMIT_NO_DISABLE_AFTER_MODESET flag reflects this
hardware requirement.  Let's use the flag for imx-drm.

Suggested-by: Daniel Vetter 
Cc: Philipp Zabel 
Cc: David Airlie 
Cc: Russell King 
Cc: Peter Senna Tschudin 
Cc: Lucas Stach 
Signed-off-by: Liu Ying 
---
v4:
* Newly introduced in v4, but some logic is picked from patch 3/3 in v3.

 drivers/gpu/drm/imx/imx-drm-core.c | 3 ++-
 drivers/gpu/drm/imx/ipuv3-crtc.c   | 3 +++
 drivers/gpu/drm/imx/ipuv3-plane.c  | 8 ++--
 3 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
b/drivers/gpu/drm/imx/imx-drm-core.c
index 56dfc4c..99fff6c 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -194,7 +194,8 @@ static void imx_drm_atomic_commit_tail(struct 
drm_atomic_state *state)
drm_atomic_helper_commit_modeset_disables(dev, state);

drm_atomic_helper_commit_planes(dev, state,
-   DRM_PLANE_COMMIT_ACTIVE_ONLY);
+   DRM_PLANE_COMMIT_ACTIVE_ONLY |
+   DRM_PLANE_COMMIT_NO_DISABLE_AFTER_MODESET);

drm_atomic_helper_commit_modeset_enables(dev, state);

diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c
index 83c46bd..c3d5933 100644
--- a/drivers/gpu/drm/imx/ipuv3-crtc.c
+++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
@@ -76,6 +76,9 @@ static void ipu_crtc_atomic_disable(struct drm_crtc *crtc,
crtc->state->event = NULL;
}
spin_unlock_irq(>dev->event_lock);
+
+   /* always disable planes on the CRTC */
+   drm_atomic_helper_disable_planes_on_crtc(old_crtc_state, true);
 }

 static void imx_drm_crtc_reset(struct drm_crtc *crtc)
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 4ad67d0..6a48147 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -392,8 +392,12 @@ static void ipu_plane_atomic_update(struct drm_plane 
*plane,
enum ipu_color_space ics;

if (old_state->fb) {
-   ipu_plane_atomic_set_base(ipu_plane, old_state);
-   return;
+   struct drm_crtc_state *crtc_state = state->crtc->state;
+
+   if (!drm_atomic_crtc_needs_modeset(crtc_state)) {
+   ipu_plane_atomic_set_base(ipu_plane, old_state);
+   return;
+   }
}

switch (ipu_plane->dp_flow) {
-- 
2.7.4

[PATCH v4 5/7] drm/imx: ipuv3-crtc: Use the callback ->atomic_disable instead of ->disable

[Liu Ying]

Now that the drm atomic core supports the callback ->atomic_disable,
we may replace the legacy one ->disable with it.

Cc: Philipp Zabel 
Cc: David Airlie 
Cc: Russell King 
Cc: Daniel Vetter 
Cc: Peter Senna Tschudin 
Cc: Lucas Stach 
Signed-off-by: Liu Ying 
---
v3->v4:
* None.

v3:
* Newly introduced in v3.

 drivers/gpu/drm/imx/ipuv3-crtc.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c
index 6e1dc90..83c46bd 100644
--- a/drivers/gpu/drm/imx/ipuv3-crtc.c
+++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
@@ -60,7 +60,8 @@ static void ipu_crtc_enable(struct drm_crtc *crtc)
ipu_di_enable(ipu_crtc->di);
 }

-static void ipu_crtc_disable(struct drm_crtc *crtc)
+static void ipu_crtc_atomic_disable(struct drm_crtc *crtc,
+   struct drm_crtc_state *old_crtc_state)
 {
struct ipu_crtc *ipu_crtc = to_ipu_crtc(crtc);
struct ipu_soc *ipu = dev_get_drvdata(ipu_crtc->dev->parent);
@@ -241,7 +242,7 @@ static const struct drm_crtc_helper_funcs ipu_helper_funcs 
= {
.mode_set_nofb = ipu_crtc_mode_set_nofb,
.atomic_check = ipu_crtc_atomic_check,
.atomic_begin = ipu_crtc_atomic_begin,
-   .disable = ipu_crtc_disable,
+   .atomic_disable = ipu_crtc_atomic_disable,
.enable = ipu_crtc_enable,
 };

-- 
2.7.4

[PATCH v4 4/7] gpu: ipu-v3: Do not wait for DMFC FIFO to clear when disabling DMFC channel

[Liu Ying]

According to basic tests, it looks there is no issue if we don't wait for
DMFC FIFO to clear when disabling DMFC channel.  NXP BSP doesn't do that,
either.  This patch is needed to avoid the annoying warning caused by a
timeout on waiting for the FIFO to clear after we add the new
DRM_PLANE_COMMIT_NO_DISABLE_AFTER_MODESET flag to the imx-drm driver
which changes the procedure to disable display channel slightly.

Cc: Philipp Zabel 
Cc: David Airlie 
Cc: Russell King 
Cc: Peter Senna Tschudin 
Cc: Lucas Stach 
Cc: Daniel Vetter 
Signed-off-by: Liu Ying 
---
v4:
* Newly introduced in v4.

 drivers/gpu/ipu-v3/ipu-dmfc.c | 18 +-
 1 file changed, 1 insertion(+), 17 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-dmfc.c b/drivers/gpu/ipu-v3/ipu-dmfc.c
index 42705bb..a40f211 100644
--- a/drivers/gpu/ipu-v3/ipu-dmfc.c
+++ b/drivers/gpu/ipu-v3/ipu-dmfc.c
@@ -123,20 +123,6 @@ int ipu_dmfc_enable_channel(struct dmfc_channel *dmfc)
 }
 EXPORT_SYMBOL_GPL(ipu_dmfc_enable_channel);

-static void ipu_dmfc_wait_fifos(struct ipu_dmfc_priv *priv)
-{
-   unsigned long timeout = jiffies + msecs_to_jiffies(1000);
-
-   while ((readl(priv->base + DMFC_STAT) & 0x02fff000) != 0x02fff000) {
-   if (time_after(jiffies, timeout)) {
-   dev_warn(priv->dev,
-"Timeout waiting for DMFC FIFOs to clear\n");
-   break;
-   }
-   cpu_relax();
-   }
-}
-
 void ipu_dmfc_disable_channel(struct dmfc_channel *dmfc)
 {
struct ipu_dmfc_priv *priv = dmfc->priv;
@@ -145,10 +131,8 @@ void ipu_dmfc_disable_channel(struct dmfc_channel *dmfc)

priv->use_count--;

-   if (!priv->use_count) {
-   ipu_dmfc_wait_fifos(priv);
+   if (!priv->use_count)
ipu_module_disable(priv->ipu, IPU_CONF_DMFC_EN);
-   }

if (priv->use_count < 0)
priv->use_count = 0;
-- 
2.7.4

[PATCH v4 3/7] drm/atomic-helper: Add NO_DISABLE_AFTER_MODESET flag support for plane commit

[Liu Ying]

Drivers may set the NO_DISABLE_AFTER_MODESET flag in the 'flags' parameter
of the helper drm_atomic_helper_commit_planes() if the relevant display
controllers(e.g., IPUv3 for imx-drm) require to disable a CRTC's planes
when the CRTC is disabled. The helper would skip the ->atomic_disable
call for a plane if the CRTC of the old plane state needs a modesetting
operation. Of course, the drivers need to disable the planes in their CRTC
disable callbacks since no one else would do that.

Suggested-by: Daniel Vetter 
Cc: Philipp Zabel 
Cc: David Airlie 
Cc: Russell King 
Cc: Peter Senna Tschudin 
Cc: Lucas Stach 
Signed-off-by: Liu Ying 
---
v4:
* Newly introduced in v4.

 drivers/gpu/drm/arm/malidp_drv.c |  3 +-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c |  2 +-
 drivers/gpu/drm/drm_atomic_helper.c  | 46 
 drivers/gpu/drm/exynos/exynos_drm_drv.c  |  2 +-
 drivers/gpu/drm/imx/imx-drm-core.c   |  3 +-
 drivers/gpu/drm/mediatek/mtk_drm_drv.c   |  6 ++--
 drivers/gpu/drm/msm/msm_atomic.c |  2 +-
 drivers/gpu/drm/omapdrm/omap_drv.c   |  2 +-
 drivers/gpu/drm/rcar-du/rcar_du_kms.c|  3 +-
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c   |  3 +-
 drivers/gpu/drm/sti/sti_drv.c|  2 +-
 drivers/gpu/drm/tegra/drm.c  |  3 +-
 drivers/gpu/drm/tilcdc/tilcdc_drv.c  |  2 +-
 drivers/gpu/drm/vc4/vc4_kms.c|  2 +-
 drivers/gpu/drm/virtio/virtgpu_display.c |  3 +-
 include/drm/drm_atomic_helper.h  |  6 +++-
 16 files changed, 61 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 82171d2..c383d72 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -91,7 +91,8 @@ static void malidp_atomic_commit_tail(struct drm_atomic_state 
*state)

drm_atomic_helper_commit_modeset_disables(drm, state);
drm_atomic_helper_commit_modeset_enables(drm, state);
-   drm_atomic_helper_commit_planes(drm, state, true);
+   drm_atomic_helper_commit_planes(drm, state,
+   DRM_PLANE_COMMIT_ACTIVE_ONLY);

malidp_atomic_commit_hw_done(state);

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index d4a3d61..8e7483d 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -457,7 +457,7 @@ atmel_hlcdc_dc_atomic_complete(struct atmel_hlcdc_dc_commit 
*commit)

/* Apply the atomic update. */
drm_atomic_helper_commit_modeset_disables(dev, old_state);
-   drm_atomic_helper_commit_planes(dev, old_state, false);
+   drm_atomic_helper_commit_planes(dev, old_state, 0);
drm_atomic_helper_commit_modeset_enables(dev, old_state);

drm_atomic_helper_wait_for_vblanks(dev, old_state);
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 30c52a8..cf19b6e 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1148,7 +1148,8 @@ EXPORT_SYMBOL(drm_atomic_helper_wait_for_vblanks);
  *
  * drm_atomic_helper_commit_modeset_enables(dev, state);
  *
- * drm_atomic_helper_commit_planes(dev, state, true);
+ * drm_atomic_helper_commit_planes(dev, state,
+ * DRM_PLANE_COMMIT_ACTIVE_ONLY);
  *
  * for committing the atomic update to hardware.  See the kerneldoc entries for
  * these three functions for more details.
@@ -1159,7 +1160,7 @@ void drm_atomic_helper_commit_tail(struct 
drm_atomic_state *state)

drm_atomic_helper_commit_modeset_disables(dev, state);

-   drm_atomic_helper_commit_planes(dev, state, false);
+   drm_atomic_helper_commit_planes(dev, state, 0);

drm_atomic_helper_commit_modeset_enables(dev, state);

@@ -1678,7 +1679,7 @@ bool plane_crtc_active(struct drm_plane_state *state)
  * drm_atomic_helper_commit_planes - commit plane state
  * @dev: DRM device
  * @old_state: atomic state object with old state structures
- * @active_only: Only commit on active CRTC if set
+ * @flags: flags for committing plane state
  *
  * This function commits the new plane state using the plane and atomic helper
  * functions for planes and crtcs. It assumes that the atomic state has already
@@ -1698,25 +1699,33 @@ bool plane_crtc_active(struct drm_plane_state *state)
  * most drivers don't need to be immediately notified of plane updates for a
  * disabled CRTC.
  *
- * Unless otherwise needed, drivers are advised to set the @active_only
- * parameters to true in order not to receive plane update notifications 
related
- * to a disabled CRTC. This avoids the need to manually ignore plane updates in
+ * Unless otherwise needed, drivers are advised to set the ACTIVE_ONLY flag in
+ * @flags in order not to receive plane update notifications related to a
+ * disabled 

[PATCH v4 2/7] drm/atomic-helper: Disable appropriate planes in disable_planes_on_crtc()

[Liu Ying]

Currently, the helper drm_atomic_helper_disable_planes_on_crtc() calls
->atomic_disable for all planes _to be_ enabled on a particular CRTC.
This is obviously wrong for those planes which are not scanning out frames
when the helper is called.  Instead, it's sane to disable active planes
of old_crtc_state in the helper.

Suggested-by: Daniel Vetter 
Cc: Philipp Zabel 
Cc: David Airlie 
Cc: Russell King 
Cc: Peter Senna Tschudin 
Cc: Lucas Stach 
Signed-off-by: Liu Ying 
---
v4:
* Newly introduced in v4.

 drivers/gpu/drm/drm_atomic_helper.c | 16 +---
 include/drm/drm_atomic_helper.h |  5 +++--
 2 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 254bdde..30c52a8 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1842,12 +1842,12 @@ EXPORT_SYMBOL(drm_atomic_helper_commit_planes_on_crtc);

 /**
  * drm_atomic_helper_disable_planes_on_crtc - helper to disable CRTC's planes
- * @crtc: CRTC
+ * @old_crtc_state: atomic state object with the old CRTC state
  * @atomic: if set, synchronize with CRTC's atomic_begin/flush hooks
  *
  * Disables all planes associated with the given CRTC. This can be
- * used for instance in the CRTC helper disable callback to disable
- * all planes before shutting down the display pipeline.
+ * used for instance in the CRTC helper atomic_disable callback to disable
+ * all planes.
  *
  * If the atomic-parameter is set the function calls the CRTC's
  * atomic_begin hook before and atomic_flush hook after disabling the
@@ -1856,9 +1856,11 @@ EXPORT_SYMBOL(drm_atomic_helper_commit_planes_on_crtc);
  * It is a bug to call this function without having implemented the
  * ->atomic_disable() plane hook.
  */
-void drm_atomic_helper_disable_planes_on_crtc(struct drm_crtc *crtc,
- bool atomic)
+void
+drm_atomic_helper_disable_planes_on_crtc(struct drm_crtc_state *old_crtc_state,
+bool atomic)
 {
+   struct drm_crtc *crtc = old_crtc_state->crtc;
const struct drm_crtc_helper_funcs *crtc_funcs =
crtc->helper_private;
struct drm_plane *plane;
@@ -1866,11 +1868,11 @@ void drm_atomic_helper_disable_planes_on_crtc(struct 
drm_crtc *crtc,
if (atomic && crtc_funcs && crtc_funcs->atomic_begin)
crtc_funcs->atomic_begin(crtc, NULL);

-   drm_for_each_plane(plane, crtc->dev) {
+   drm_atomic_crtc_state_for_each_plane(plane, old_crtc_state) {
const struct drm_plane_helper_funcs *plane_funcs =
plane->helper_private;

-   if (plane->state->crtc != crtc || !plane_funcs)
+   if (!plane_funcs)
continue;

WARN_ON(!plane_funcs->atomic_disable);
diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
index 5a02e49..1abf2c0 100644
--- a/include/drm/drm_atomic_helper.h
+++ b/include/drm/drm_atomic_helper.h
@@ -71,8 +71,9 @@ void drm_atomic_helper_commit_planes(struct drm_device *dev,
 void drm_atomic_helper_cleanup_planes(struct drm_device *dev,
  struct drm_atomic_state *old_state);
 void drm_atomic_helper_commit_planes_on_crtc(struct drm_crtc_state 
*old_crtc_state);
-void drm_atomic_helper_disable_planes_on_crtc(struct drm_crtc *crtc,
- bool atomic);
+void
+drm_atomic_helper_disable_planes_on_crtc(struct drm_crtc_state *old_crtc_state,
+bool atomic);

 void drm_atomic_helper_swap_state(struct drm_atomic_state *state,
  bool stall);
-- 
2.7.4

[PATCH v4 1/7] drm/atomic-helper: Add atomic_disable CRTC helper callback

[Liu Ying]

Some display controllers need plane(s) to be disabled together with
the relevant CRTC, e.g., the IPUv3 display controller for imx-drm.
This patch adds atomic_disable CRTC helper callback so that
old_crtc_state(as a parameter of the callback) could be used
to get the active plane(s) of the old CRTC state for disable operation.

Suggested-by: Daniel Vetter 
Cc: Philipp Zabel 
Cc: David Airlie 
Cc: Russell King 
Cc: Peter Senna Tschudin 
Cc: Lucas Stach 
Signed-off-by: Liu Ying 
---
v3->v4:
* Improve kernel-doc of CRTC's atomic_disable callback to address Daniel
  Vetter's comment.

v3:
* Newly introduced in v3.

 drivers/gpu/drm/drm_atomic_helper.c  |  2 ++
 include/drm/drm_modeset_helper_vtables.h | 24 
 2 files changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 9abe0a2..254bdde 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -749,6 +749,8 @@ disable_outputs(struct drm_device *dev, struct 
drm_atomic_state *old_state)
/* Right function depends upon target state. */
if (crtc->state->enable && funcs->prepare)
funcs->prepare(crtc);
+   else if (funcs->atomic_disable)
+   funcs->atomic_disable(crtc, old_crtc_state);
else if (funcs->disable)
funcs->disable(crtc);
else
diff --git a/include/drm/drm_modeset_helper_vtables.h 
b/include/drm/drm_modeset_helper_vtables.h
index 6c8d3da..10e449c 100644
--- a/include/drm/drm_modeset_helper_vtables.h
+++ b/include/drm/drm_modeset_helper_vtables.h
@@ -266,6 +266,8 @@ struct drm_crtc_helper_funcs {
 * disable anything at the CRTC level. To ensure that runtime PM
 * handling (using either DPMS or the new "ACTIVE" property) works
 * @disable must be the inverse of @enable for atomic drivers.
+* Atomic drivers should consider to use @atomic_disable instead of
+* this one.
 *
 * NOTE:
 *
@@ -391,6 +393,28 @@ struct drm_crtc_helper_funcs {
 */
void (*atomic_flush)(struct drm_crtc *crtc,
 struct drm_crtc_state *old_crtc_state);
+
+   /**
+* @atomic_disable:
+*
+* This callback should be used to disable the CRTC. With the atomic
+* drivers it is called after all encoders connected to this CRTC have
+* been shut off already using their own ->disable hook. If that
+* sequence is too simple drivers can just add their own hooks and call
+* it from this CRTC callback here by looping over all encoders
+* connected to it using for_each_encoder_on_crtc().
+*
+* This hook is used only by atomic helpers. Atomic drivers don't
+* need to implement it if there's no need to disable anything at the
+* CRTC level.
+*
+* Comparing to @disable, this one provides the additional input
+* parameter @old_crtc_state which could be used to access the old
+* state. Atomic drivers should consider to use this one instead
+* of @disable.
+*/
+   void (*atomic_disable)(struct drm_crtc *crtc,
+  struct drm_crtc_state *old_crtc_state);
 };

 /**
-- 
2.7.4

[PATCH v4 0/7] drm/imx: Add active plane reconfiguration support

[Liu Ying]

This patch adds active plane reconfiguration support for imx-drm.
This may fixes some mode setting failure issues which were introduced
by imx-drm atomic conversion patch set.  The main idea is to disable the
plane in question in CRTC's atomic_disable operation and then the drm
atomic core will enable it again automatically.

v3->v4:
* Change the bool active_only parameter of commit_planes() to an uint32_t
  parameter named 'flags' and add two flags - DRM_PLANE_COMMIT_ACTIVE_ONLY
  and DRM_PLANE_COMMIT_NO_DISABLE_AFTER_MODESET.  This way, the drm atomic
  core is able to skip the atomic_disable call for the planes which are
  committed with the NO_DISABLE_AFTER_MODESET flag set.
* Fix the helper disable_planes_on_crtc(), which is needed for CRTC's
  atomic_disable callback to disable planes.
* Improve kernel-doc of CRTC's atomic_disable callback to address Daniel
  Vetter's comment.
* Do not wait for DMFC FIFO to clear to avoid timeout warning, as the
  precedure to disable display channel is changed slightly after the
  NO_DISABLE_AFTER_MODESET flag is used.

v2->v3:
* Disable all appropriate affected planes(when necessary) in CRTC's
  ->atomic_disable callback, but not in each plane's ->atomic_update callback,
  as suggested by Daniel Vetter.
* +Cc Lucas Stach, as he tested the patch v2.

v1->v2:
* Do not reject reconfiguring an active overlay plane.

Liu Ying (7):
  drm/atomic-helper: Add atomic_disable CRTC helper callback
  drm/atomic-helper: Disable appropriate planes in
disable_planes_on_crtc()
  drm/atomic-helper: Add NO_DISABLE_AFTER_MODESET flag support for plane
commit
  gpu: ipu-v3: Do not wait for DMFC FIFO to clear when disabling DMFC
channel
  drm/imx: ipuv3-crtc: Use the callback ->atomic_disable instead of
->disable
  drm/imx: Use DRM_PLANE_COMMIT_NO_DISABLE_AFTER_MODESET flag
  drm/imx: Add active plane reconfiguration support

 drivers/gpu/drm/arm/malidp_drv.c |  3 +-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c |  2 +-
 drivers/gpu/drm/drm_atomic_helper.c  | 64 +++-
 drivers/gpu/drm/exynos/exynos_drm_drv.c  |  2 +-
 drivers/gpu/drm/imx/imx-drm-core.c   | 30 -
 drivers/gpu/drm/imx/ipuv3-crtc.c |  8 +++-
 drivers/gpu/drm/imx/ipuv3-plane.c| 21 ++---
 drivers/gpu/drm/mediatek/mtk_drm_drv.c   |  6 ++-
 drivers/gpu/drm/msm/msm_atomic.c |  2 +-
 drivers/gpu/drm/omapdrm/omap_drv.c   |  2 +-
 drivers/gpu/drm/rcar-du/rcar_du_kms.c|  3 +-
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c   |  3 +-
 drivers/gpu/drm/sti/sti_drv.c|  2 +-
 drivers/gpu/drm/tegra/drm.c  |  3 +-
 drivers/gpu/drm/tilcdc/tilcdc_drv.c  |  2 +-
 drivers/gpu/drm/vc4/vc4_kms.c|  2 +-
 drivers/gpu/drm/virtio/virtgpu_display.c |  3 +-
 drivers/gpu/ipu-v3/ipu-dmfc.c| 18 +---
 include/drm/drm_atomic_helper.h  | 11 +++--
 include/drm/drm_modeset_helper_vtables.h | 24 +++
 20 files changed, 146 insertions(+), 65 deletions(-)

-- 
2.7.4

[RFC] drm: implement generic firmware eviction

[Maxime Ripard]

Hi,

On Fri, Aug 26, 2016 at 02:00:56AM +0200, David Herrmann wrote:
> Also: Does any platform make use the of 'display:' entry in 
> 'simple-framebuffer'
> DT nodes? If yes, how do I get access to it? And why don't vc4/sun4i make use 
> of
> it, rather than falling back to remove_conflicting_framebuffers()?

For the sun4i part, I'd say because I wasn't aware of it :)

A better argument would be that most of our device tree don't have it
at the moment, and we might boot on older device trees. So we need a
fallback solution anyway.

Maxime

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

[PATCH] omapdrm: dss: drop unneeded of_node_put() on ref passed to of_get_next_parent()

[Andrey Utkin]

Fixes runtime error:

[8.842806] OF: ERROR: Bad of_node_put() on /encoder/ports/port at 1/endpoint
[8.842812] CPU: 1 PID: 1494 Comm: systemd-udevd Not tainted 
4.8.0-rc1-letux-custom #17
[8.842815] Hardware name: Generic OMAP5 (Flattened Device Tree)
[8.842831] [] (unwind_backtrace) from [] 
(show_stack+0xb/0xc)
[8.842841] [] (show_stack) from [] 
(dump_stack+0x6d/0x98)
[8.842849] [] (dump_stack) from [] 
(kobject_put+0x93/0x140)
[8.842935] [] (kobject_put) from [] 
(omapdss_of_find_source_for_first_ep+0x2e/0x58 [omapdss])
[8.843014] [] (omapdss_of_find_source_for_first_ep [omapdss]) 
from [] (hdmic_probe+0x56/0x170 [connector_hdmi])
[8.843030] [] (hdmic_probe [connector_hdmi]) from [] 
(platform_drv_probe+0x33/0x62)
[8.843040] [] (platform_drv_probe) from [] 
(driver_probe_device+0x11f/0x284)
[8.843049] [] (driver_probe_device) from [] 
(__driver_attach+0x4d/0x98)
[8.843057] [] (__driver_attach) from [] 
(bus_for_each_dev+0x3d/0x46)
[8.843064] [] (bus_for_each_dev) from [] 
(bus_add_driver+0xe3/0x170)
[8.843073] [] (bus_add_driver) from [] 
(driver_register+0x59/0x88)
[8.843083] [] (driver_register) from [] 
(hdmi_connector_driver_init+0xa/0x13 [connector_hdmi])
[8.843095] [] (hdmi_connector_driver_init [connector_hdmi]) from 
[] (do_one_initcall+0xc5/0xf0)
[8.843108] [] (do_one_initcall) from [] 
(do_init_module+0x3b/0x318)
[8.843118] [] (do_init_module) from [] 
(load_module+0x13f3/0x1722)
[8.843126] [] (load_module) from [] 
(SyS_finit_module+0x51/0x74)
[8.843135] [] (SyS_finit_module) from [] 
(ret_fast_syscall+0x1/0x18)

Signed-off-by: Andrey Utkin 
---
 drivers/gpu/drm/omapdrm/dss/dss-of.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dss-of.c 
b/drivers/gpu/drm/omapdrm/dss/dss-of.c
index e256d87..3e2b191 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss-of.c
+++ b/drivers/gpu/drm/omapdrm/dss/dss-of.c
@@ -132,7 +132,6 @@ static struct device_node *omapdss_of_get_remote_port(const 
struct device_node *
return NULL;

np_parent = of_get_next_parent(np);
-   of_node_put(np);

return np_parent;
 }
-- 
2.9.2

[RFC] drm: implement generic firmware eviction

[Hans de Goede]

Hi,

On 26-08-16 14:52, Maxime Ripard wrote:
> On Fri, Aug 26, 2016 at 11:02:17AM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 26-08-16 10:58, Maxime Ripard wrote:
>>> Hi,
>>>
>>> On Fri, Aug 26, 2016 at 10:43:55AM +0200, Hans de Goede wrote:
>> I'm not sure we would want to remove the device at all, we
>> certainly should not be removing the dt_node from the devicetree
>> IMHO. Having that around to see how the bootloader set things up
>> is really useful for debugging and normally we should never modify
>> the devicetree as set up by the bootloader.
>>
>> Why not just unbind the driver from the platform device? That
>> should be enough.
>
> That will leave IORESOURCE_MEM around, causing conflicts if
> re-used/claimed by other devices/drivers. Furthermore, it is really
> fragile leaving the device around, without any control over
> possible future driver probing.

 Ah, good point. On ARM this currently typically is reserved by the 
 bootloader
 so never touched by the kernel at all, not even when the simplefb is no 
 longer
 used, actually returning this memory to the kernel after unbinding the 
 simplefb /
 destroying the simplefb platform-dev would be really good to do. We should
 probably figure out how that should be done before getting rid of
 remove_conflicting_framebuffers... (sorry).
>>>
>>> That would be rather easy to do. The firmware could generate a
>>> reserved-memory node instead of passing a smaller memory size to the
>>> kernel. That way, the kernel will know that it's actual ram that it
>>> can reclaim.
>>
>> So when would the kernel reclaim the RAM then?
>
> When we kickout the framebuffer driver?

Yes that is when we _want_ it to reclaim the RAM, my question was when
it will _actually_ happen ? I'm not familiar with the reserved-memory
implementation. Does your answer mean that some driver must make an
explicit call to get the memory reclaimed ?

Regards,

Hans

[RFC] drm: implement generic firmware eviction

[Maxime Ripard]

On Fri, Aug 26, 2016 at 11:02:17AM +0200, Hans de Goede wrote:
> Hi,
> 
> On 26-08-16 10:58, Maxime Ripard wrote:
> >Hi,
> >
> >On Fri, Aug 26, 2016 at 10:43:55AM +0200, Hans de Goede wrote:
> >>>>I'm not sure we would want to remove the device at all, we
> >>>>certainly should not be removing the dt_node from the devicetree
> >>>>IMHO. Having that around to see how the bootloader set things up
> >>>>is really useful for debugging and normally we should never modify
> >>>>the devicetree as set up by the bootloader.
> >>>>
> >>>>Why not just unbind the driver from the platform device? That
> >>>>should be enough.
> >>>
> >>>That will leave IORESOURCE_MEM around, causing conflicts if
> >>>re-used/claimed by other devices/drivers. Furthermore, it is really
> >>>fragile leaving the device around, without any control over
> >>>possible future driver probing.
> >>
> >>Ah, good point. On ARM this currently typically is reserved by the 
> >>bootloader
> >>so never touched by the kernel at all, not even when the simplefb is no 
> >>longer
> >>used, actually returning this memory to the kernel after unbinding the 
> >>simplefb /
> >>destroying the simplefb platform-dev would be really good to do. We should
> >>probably figure out how that should be done before getting rid of
> >>remove_conflicting_framebuffers... (sorry).
> >
> >That would be rather easy to do. The firmware could generate a
> >reserved-memory node instead of passing a smaller memory size to the
> >kernel. That way, the kernel will know that it's actual ram that it
> >can reclaim.
> 
> So when would the kernel reclaim the RAM then?

When we kickout the framebuffer driver?

Maxime

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

[PATCH] drm/panel: simple-panel: add delay timings for Starry KR122EA0SRA

[Brian Norris]

Taking our cue from commit a42f6e3f8f03 ("drm/panel: simple: Add delay
timing for Sharp LQ123P1JX31"), let's add timings:

 .prepare = t1 + t3
 .enable = t7
 .unprepare = t11 + 12

Without this, the panel may not be given enough time to come up.

Signed-off-by: Brian Norris 
---
 drivers/gpu/drm/panel/panel-simple.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index f17899867c10..74c321026fa1 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1435,6 +1435,11 @@ static const struct panel_desc starry_kr122ea0sra = {
.width = 263,
.height = 164,
},
+   .delay = {
+   .prepare = 10 + 200,
+   .enable = 50,
+   .unprepare = 10 + 500,
+   },
 };

 static const struct drm_display_mode tpk_f07a_0102_mode = {
-- 
2.8.0.rc3.226.g39d4020

[PATCH -next] drm/sun4i: Remove redundant dev_err call in sun4i_tcon_init_regmap()

[Wei Yongjun]

From: Wei Yongjun 

There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.

Signed-off-by: Wei Yongjun 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 2145ecf..9180e7e 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -374,10 +374,8 @@ static int sun4i_tcon_init_regmap(struct device *dev,

res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
regs = devm_ioremap_resource(dev, res);
-   if (IS_ERR(regs)) {
-   dev_err(dev, "Couldn't map the TCON registers\n");
+   if (IS_ERR(regs))
return PTR_ERR(regs);
-   }

tcon->regs = devm_regmap_init_mmio(dev, regs,
   _tcon_regmap_config);

[PATCH v7 7/8] PM / devfreq: rockchip: add devfreq driver for rk3399 dmc

[Brian Norris]

Hi,

On Mon, Aug 22, 2016 at 11:36:23AM +0800, Lin Huang wrote:
> base on dfi result, we do ddr frequency scaling, register
> dmc driver to devfreq framework, and use simple-ondemand
> policy.
> 
> Signed-off-by: Lin Huang 
> Reviewed-by: Chanwoo Choi 
> ---
> Changes in v7:
> - remove a blank line
> 
> Changes in v6:
> - fix some nit suggest by Chanwoo Choi
> 
> Changes in v5:
> - improve dmc driver suggest by Chanwoo Choi
> 
> Changes in v4:
> - use arm_smccc_smc() function talk to bl31
> - delete rockchip_dmc.c file and config
> - delete dmc_notify
> - adjust probe order
> 
> Changes in v3:
> - operate dram setting through sip call
> - imporve set rate flow
> 
> Changes in v2:
> - None
> 
> Changes in v1:
> - move dfi controller to event
> - fix set voltage sequence when set rate fail
> - change Kconfig type from tristate to bool
> - move unuse EXPORT_SYMBOL_GPL()
> 
>  drivers/devfreq/Kconfig  |  11 +
>  drivers/devfreq/Makefile |   1 +
>  drivers/devfreq/rk3399_dmc.c | 499 
> +++
>  3 files changed, 511 insertions(+)
>  create mode 100644 drivers/devfreq/rk3399_dmc.c
> 
> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
> index a5be56e..e848121 100644
> --- a/drivers/devfreq/Kconfig
> +++ b/drivers/devfreq/Kconfig
> @@ -100,6 +100,17 @@ config ARM_TEGRA_DEVFREQ
>   It reads ACTMON counters of memory controllers and adjusts the
>   operating frequencies and voltages with OPP support.
>  
> +config ARM_RK3399_DMC_DEVFREQ
> + tristate "ARM RK3399 DMC DEVFREQ Driver"
> + depends on ARCH_ROCKCHIP
> + select DEVFREQ_EVENT_ROCKCHIP_DFI
> + select DEVFREQ_GOV_SIMPLE_ONDEMAND
> + select PM_OPP
> + help
> +  This adds the DEVFREQ driver for the RK3399 DMC(Dynamic Memory 
> Controller).
> +  It sets the frequency for the memory controller and reads the 
> usage counts
> +  from hardware.
> +
>  source "drivers/devfreq/event/Kconfig"
>  
>  endif # PM_DEVFREQ
> diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
> index 09f11d9..fbff40a 100644
> --- a/drivers/devfreq/Makefile
> +++ b/drivers/devfreq/Makefile
> @@ -8,6 +8,7 @@ obj-$(CONFIG_DEVFREQ_GOV_PASSIVE) += governor_passive.o
>  
>  # DEVFREQ Drivers
>  obj-$(CONFIG_ARM_EXYNOS_BUS_DEVFREQ) += exynos-bus.o
> +obj-$(CONFIG_ARM_RK3399_DMC_DEVFREQ) += rk3399_dmc.o
>  obj-$(CONFIG_ARM_TEGRA_DEVFREQ)  += tegra-devfreq.o
>  
>  # DEVFREQ Event Drivers
> diff --git a/drivers/devfreq/rk3399_dmc.c b/drivers/devfreq/rk3399_dmc.c
> new file mode 100644
> index 000..b73a73c
> --- /dev/null
> +++ b/drivers/devfreq/rk3399_dmc.c
> @@ -0,0 +1,499 @@
> +/*
> + * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd.
> + * Author: Lin Huang 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +struct dram_timing {
> + unsigned int ddr3_speed_bin;
> + unsigned int pd_idle;
> + unsigned int sr_idle;
> + unsigned int sr_mc_gate_idle;
> + unsigned int srpd_lite_idle;
> + unsigned int standby_idle;
> + unsigned int dram_dll_dis_freq;
> + unsigned int phy_dll_dis_freq;
> + unsigned int ddr3_odt_dis_freq;
> + unsigned int ddr3_drv;
> + unsigned int ddr3_odt;
> + unsigned int phy_ddr3_ca_drv;
> + unsigned int phy_ddr3_dq_drv;
> + unsigned int phy_ddr3_odt;
> + unsigned int lpddr3_odt_dis_freq;
> + unsigned int lpddr3_drv;
> + unsigned int lpddr3_odt;
> + unsigned int phy_lpddr3_ca_drv;
> + unsigned int phy_lpddr3_dq_drv;
> + unsigned int phy_lpddr3_odt;
> + unsigned int lpddr4_odt_dis_freq;
> + unsigned int lpddr4_drv;
> + unsigned int lpddr4_dq_odt;
> + unsigned int lpddr4_ca_odt;
> + unsigned int phy_lpddr4_ca_drv;
> + unsigned int phy_lpddr4_ck_cs_drv;
> + unsigned int phy_lpddr4_dq_drv;
> + unsigned int phy_lpddr4_odt;
> +};
> +
> +struct rk3399_dmcfreq {
> + struct device *dev;
> + struct devfreq *devfreq;
> + struct devfreq_simple_ondemand_data ondemand_data;
> + struct clk *dmc_clk;
> + struct devfreq_event_dev *edev;
> + struct mutex lock;
> + struct dram_timing *timing;

Are you actually using this after probe time, or are you just loading
this straight into ATF? If the latter, then you can just use a stack
variable, with no kmalloc() (and you *definitely* don't 

drm/mediatek: fixed the calc method of data rate per lane

[Jitao Shi]

Tune dsi frame rate by pixel clock, dsi add some extra signal (i.e. Tlpx,
Ths-prepare, Ths-zero, Ths-trail,Ths-exit) when enter and exit LP mode, this
signal will cause h-time larger than normal and reduce FPS.
Need to multiply a coefficient to offset the extra signal's effect.
coefficient = ((htotal*bpp/lane_number)+Tlpx+Ths_prep+Ths_zero+Ths_trail+
Ths_exit)/(htotal*bpp/lane_number))

Signed-off-by: Jitao Shi 
---
 drivers/gpu/drm/mediatek/mtk_dsi.c |  111 ++--
 1 file changed, 67 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 28b2044..506aa22 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -85,28 +85,26 @@
 #define LD0_WAKEUP_EN  BIT(2)

 #define DSI_PHY_TIMECON0   0x110
-#define LPX(0xff << 0)
-#define HS_PRPR(0xff << 8)
-#define HS_ZERO(0xff << 16)
-#define HS_TRAIL   (0xff << 24)
+#define LPX(x) ((x) << 0)
+#define HS_PRPR(x) ((x) << 8)
+#define HS_ZERO(x) ((x) << 16)
+#define HS_TRAIL(x)((x) << 24)

 #define DSI_PHY_TIMECON1   0x114
-#define TA_GO  (0xff << 0)
-#define TA_SURE(0xff << 8)
-#define TA_GET (0xff << 16)
-#define DA_HS_EXIT (0xff << 24)
+#define TA_GO(x)   ((x) << 0)
+#define TA_SURE(x) ((x) << 8)
+#define TA_GET(x)  ((x) << 16)
+#define DA_HS_EXIT(x)  ((x) << 24)

 #define DSI_PHY_TIMECON2   0x118
-#define CONT_DET   (0xff << 0)
-#define CLK_ZERO   (0xff << 16)
-#define CLK_TRAIL  (0xff << 24)
+#define CONT_DET(x)((x) << 0)
+#define CLK_ZERO(x)((x) << 16)
+#define CLK_TRAIL(x)   ((x) << 24)

 #define DSI_PHY_TIMECON3   0x11c
-#define CLK_HS_PRPR(0xff << 0)
-#define CLK_HS_POST(0xff << 8)
-#define CLK_HS_EXIT(0xff << 16)
-
-#define NS_TO_CYCLE(n, c)((n) / (c) + (((n) % (c)) ? 1 : 0))
+#define CLK_HS_PRPR(x) ((x) << 0)
+#define CLK_HS_POST(x) ((x) << 8)
+#define CLK_HS_EXIT(x) ((x) << 16)

 struct phy;

@@ -158,28 +156,14 @@ static void mtk_dsi_mask(struct mtk_dsi *dsi, u32 offset, 
u32 mask, u32 data)
writel((temp & ~mask) | (data & mask), dsi->regs + offset);
 }

-static void dsi_phy_timconfig(struct mtk_dsi *dsi)
+static void dsi_phy_timconfig(struct mtk_dsi *dsi, u32 phy_timing0,
+ u32 phy_timing1, u32 phy_timing2,
+ u32 phy_timing3)
 {
-   u32 timcon0, timcon1, timcon2, timcon3;
-   unsigned int ui, cycle_time;
-   unsigned int lpx;
-
-   ui = 1000 / dsi->data_rate + 0x01;
-   cycle_time = 8000 / dsi->data_rate + 0x01;
-   lpx = 5;
-
-   timcon0 = (8 << 24) | (0xa << 16) | (0x6 << 8) | lpx;
-   timcon1 = (7 << 24) | (5 * lpx << 16) | ((3 * lpx) / 2) << 8 |
- (4 * lpx);
-   timcon2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
- (NS_TO_CYCLE(0x150, cycle_time) << 16);
-   timcon3 = (2 * lpx) << 16 | NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8 |
-  NS_TO_CYCLE(0x40, cycle_time);
-
-   writel(timcon0, dsi->regs + DSI_PHY_TIMECON0);
-   writel(timcon1, dsi->regs + DSI_PHY_TIMECON1);
-   writel(timcon2, dsi->regs + DSI_PHY_TIMECON2);
-   writel(timcon3, dsi->regs + DSI_PHY_TIMECON3);
+   writel(phy_timing0, dsi->regs + DSI_PHY_TIMECON0);
+   writel(phy_timing1, dsi->regs + DSI_PHY_TIMECON1);
+   writel(phy_timing2, dsi->regs + DSI_PHY_TIMECON2);
+   writel(phy_timing3, dsi->regs + DSI_PHY_TIMECON3);
 }

 static void mtk_dsi_enable(struct mtk_dsi *dsi)
@@ -202,19 +186,57 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
 {
struct device *dev = dsi->dev;
int ret;
+   u64 bit_clock, total_bits;
+   u32 htotal, htotal_bits, bit_per_pixel, overhead_cycles, overhead_bits;
+   u32 phy_timing0, phy_timing1, phy_timing2, phy_timing3;

if (++dsi->refcount != 1)
return 0;

+   phy_timing0 = LPX(5) | HS_PRPR(6) | HS_ZERO(10) | HS_TRAIL(8);
+   phy_timing1 = TA_GO(20) | TA_SURE(7) | TA_GET(25) | DA_HS_EXIT(7);
+   phy_timing2 = CLK_ZERO(38) | CLK_TRAIL(22);
+   phy_timing3 = CLK_HS_PRPR(8) | CLK_HS_POST(21) | CLK_HS_EXIT(10);
+
+   switch (dsi->format) {
+   case MIPI_DSI_FMT_RGB565:
+   bit_per_pixel = 16;
+   break;
+   case MIPI_DSI_FMT_RGB666_PACKED:
+   bit_per_pixel = 18;
+   break;
+   case 

[PATCH v7 6/8] Documentation: bindings: add dt documentation for rk3399 dmc

[Brian Norris]

+ devicetree list

You should be including devicetree at vger.kernel.org on all binding
documents. And as Chanwoo Choi already mentioned, you didn't fix his
comments from v6:

https://lkml.org/lkml/2016/8/16/913

On Mon, Aug 22, 2016 at 11:36:22AM +0800, Lin Huang wrote:
> This patch adds the documentation for rockchip rk3399 dmc driver.
> 
> Signed-off-by: Lin Huang 
> ---
> Changes in v7:
> -None
> 
> Changes in v6:
> -Add more detail in Documentation
> 
> Changes in v5:
> -None
> 
> Changes in v4:
> -None
> 
> Changes in v3:
> -None
> 
> Changes in v2:
> -None 
> 
> Changes in v1:
> -None
>  .../devicetree/bindings/devfreq/rk3399_dmc.txt | 85 
> ++
>  1 file changed, 85 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
> 
> diff --git a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt 
> b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
> new file mode 100644
> index 000..b787abb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
> @@ -0,0 +1,85 @@
> +* Rockchip rk3399 DMC(Dynamic Memory Controller) device
> +
> +Required properties:
> +- compatible: Must be "rockchip,rk3399-dmc".
> +- devfreq-events: Node to get DDR loading, Refer to
> +   Documentation/devicetree/bindings/devfreq/rockchip-dfi.txt
> +- interrupts: The interrupt number to the CPU. The interrupt specifier format
> +   depends on the interrupt controller. It should be DCF interrupts,
> +   when DDR dvfs finish, it will happen.
> +- clocks: Phandles for clock specified in "clock-names" property
> +- clock-names : The name of clock used by the DFI, must be "pclk_ddr_mon";
> +- operating-points-v2: Refer to 
> Documentation/devicetree/bindings/power/opp.txt
> +for details.
> +- center-supply: DMC supply node.
> +- status: Marks the node enabled/disabled.
> +
> +Optional properties:
> +- ddr_timing:  DDR timing need to pass to arm trust firmware

I believe it's "ARM Trusted Firmware", not "arm trust firmware".

> +- upthreshold: The upthreshold to simpleondeamnd policy
> +- downdifferential: The downdifferential to simpleondeamnd policy
> +
> +Example:
> +
> + ddr_timing: ddr_timing {
> + compatible = "rockchip,ddr-timing";
> + ddr3_speed_bin = <21>;
> + pd_idle = <0>;
> + sr_idle = <0>;
> + sr_mc_gate_idle = <0>;
> + srpd_lite_idle  = <0>;
> + standby_idle = <0>;
> + dram_dll_dis_freq = <300>;
> + phy_dll_dis_freq = <125>;
> +
> + ddr3_odt_dis_freq = <333>;
> + ddr3_drv = ;
> + ddr3_odt = ;
> + phy_ddr3_ca_drv = ;
> + phy_ddr3_dq_drv = ;
> + phy_ddr3_odt = ;
> +
> + lpddr3_odt_dis_freq = <333>;
> + lpddr3_drv = ;
> + lpddr3_odt = ;
> + phy_lpddr3_ca_drv = ;
> + phy_lpddr3_dq_drv = ;
> + phy_lpddr3_odt = ;
> +
> + lpddr4_odt_dis_freq = <333>;
> + lpddr4_drv = ;
> + lpddr4_dq_odt = ;
> + lpddr4_ca_odt = ;
> + phy_lpddr4_ca_drv = ;
> + phy_lpddr4_ck_cs_drv = ;
> + phy_lpddr4_dq_drv = ;
> + phy_lpddr4_odt = ;
> + };

Chanwoo suggested this ddr_timing node get moved to be direct properties
instead the dmc node. You also need to document them all in this file.

Also typically, you add "rockchip," prefixes to custom properties like
these.

Brian

> +
> + dmc_opp_table: dmc_opp_table {
> + compatible = "operating-points-v2";
> +
> + opp00 {
> + opp-hz = /bits/ 64 <3>;
> + opp-microvolt = <90>;
> + };
> + opp01 {
> + opp-hz = /bits/ 64 <66600>;
> + opp-microvolt = <90>;
> + };
> + };
> +
> + dmc: dmc {
> + compatible = "rockchip,rk3399-dmc";
> + devfreq-events = <>;
> + interrupts = ;
> + clocks = < SCLK_DDRCLK>;
> + clock-names = "dmc_clk";
> + ddr_timing = <_timing>;
> + operating-points-v2 = <_opp_table>;
> + center-supply = <_centerlogic>;
> + upthreshold = <15>;
> + downdifferential = <10>;
> + status = "disabled";
> + };
> +
> -- 
> 2.6.6

[RFC][PATCH 2/4] drm/bridge: adv7511: Add Audio support.

[Srinivas Kandagatla]

Few Minor comments below..

On 23/08/16 06:50, John Stultz wrote:
> This patch adds support to Audio for both adv7511 and adv7533
> bridge chips.
>
> This patch was originally from [1] by Lars-Peter Clausen 
> and was adapted by Archit Taneja  and
> Srinivas Kandagatla .
>
> Then I heavily reworked it to use the hdmi-codec driver. So credit
> to them, but blame to me.
>
> [1] 
> https://github.com/analogdevicesinc/linux/blob/xcomm_zynq/drivers/gpu/drm/i2c/adv7511_audio.c
>
> Cc: David Airlie 
> Cc: Archit Taneja 
> Cc: Laurent Pinchart 
> Cc: Wolfram Sang 
> Cc: Srinivas Kandagatla 
> Cc: "Ville Syrjälä" 
> Cc: Boris Brezillon 
> Cc: Andy Green 
> Cc: Dave Long 
> Cc: Guodong Xu 
> Cc: Zhangfei Gao 
> Cc: Mark Brown 
> Cc: Lars-Peter Clausen 
> Cc: Jose Abreu 
> Cc: dri-devel at lists.freedesktop.org
> Signed-off-by: John Stultz 
> ---
>  drivers/gpu/drm/bridge/adv7511/Kconfig |   1 +
>  drivers/gpu/drm/bridge/adv7511/Makefile|   2 +-
>  drivers/gpu/drm/bridge/adv7511/adv7511.h   |   4 +
>  drivers/gpu/drm/bridge/adv7511/adv7511_audio.c | 208 
> +
>  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   |   5 +
>  5 files changed, 219 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
>
> diff --git a/drivers/gpu/drm/bridge/adv7511/Kconfig 
> b/drivers/gpu/drm/bridge/adv7511/Kconfig
> index d2b0499..e3975e9 100644
> --- a/drivers/gpu/drm/bridge/adv7511/Kconfig
> +++ b/drivers/gpu/drm/bridge/adv7511/Kconfig
> @@ -3,6 +3,7 @@ config DRM_I2C_ADV7511
>   depends on OF
>   select DRM_KMS_HELPER
>   select REGMAP_I2C
> + select SND_SOC_HDMI_CODEC if SND_SOC
>   help
> Support for the Analog Device ADV7511(W) and ADV7513 HDMI encoders.
>
> diff --git a/drivers/gpu/drm/bridge/adv7511/Makefile 
> b/drivers/gpu/drm/bridge/adv7511/Makefile
> index 9019327..ad7245d 100644
> --- a/drivers/gpu/drm/bridge/adv7511/Makefile
> +++ b/drivers/gpu/drm/bridge/adv7511/Makefile
> @@ -1,3 +1,3 @@
> -adv7511-y := adv7511_drv.o
> +adv7511-y := adv7511_drv.o adv7511_audio.o
>  adv7511-$(CONFIG_DRM_I2C_ADV7533) += adv7533.o
>  obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511.o
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h 
> b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> index c7002a0..594ee0e1 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> @@ -23,6 +23,8 @@ struct adv7511;
>
>  int adv7511_packet_enable(struct adv7511 *adv7511, unsigned int packet);
>  int adv7511_packet_disable(struct adv7511 *adv7511, unsigned int packet);
> +int adv7511_audio_init(struct device *dev);
> +void adv7511_audio_exit(struct device *dev);
>
>  #define ADV7511_REG_CHIP_REVISION0x00
>  #define ADV7511_REG_N0   0x01
> @@ -317,6 +319,8 @@ struct adv7511 {
>   struct drm_display_mode curr_mode;
>
>   unsigned int f_tmds;
> + unsigned int f_audio;
> + unsigned int audio_source;
>
>   unsigned int current_edid_segment;
>   uint8_t edid_buf[256];
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c 
> b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
> new file mode 100644
> index 000..5aa9809
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
> @@ -0,0 +1,208 @@
> +/*
> + * Analog Devices ADV7511 HDMI transmitter driver
> + *
> + * Copyright 2012 Analog Devices Inc.
> + * Copyright (c) 2016, Linaro Limited
> + *
> + * Licensed under the GPL-2.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Looks like some of these includes are really not needed.

> +
> +#include "adv7511.h"
> +
> +static void adv7511_calc_cts_n(unsigned int f_tmds, unsigned int fs,
> +unsigned int *cts, unsigned int *n)
> +{
> + switch (fs) {
> + case 32000:
> + *n = 4096;
> + break;
> + case 44100:
> + *n = 6272;
> + break;
> + case 48000:
> + *n = 6144;
> + break;
> + }
> +
> + *cts = ((f_tmds * *n) / (128 * fs)) * 1000;
> +}
> +
> +static int adv7511_update_cts_n(struct adv7511 *adv7511)
> +{
> + unsigned int cts = 0;
> + unsigned int n = 0;
> +
> + adv7511_calc_cts_n(adv7511->f_tmds, adv7511->f_audio, , );
> +
> + regmap_write(adv7511->regmap, ADV7511_REG_N0, (n >> 16) & 0xf);
> + regmap_write(adv7511->regmap, ADV7511_REG_N1, (n >> 8) & 0xff);
> + regmap_write(adv7511->regmap, ADV7511_REG_N2, n & 0xff);
> +
> + regmap_write(adv7511->regmap, ADV7511_REG_CTS_MANUAL0,
> +  (cts >> 16) & 0xf);
> + regmap_write(adv7511->regmap, ADV7511_REG_CTS_MANUAL1,
> +  (cts >> 8) & 0xff);
> + regmap_write(adv7511->regmap, ADV7511_REG_CTS_MANUAL2,
> +  

[RFC][PATCH 0/4] Audio support for adv7511 hdmi bridge

[Srinivas Kandagatla]

Hi John,

On 23/08/16 06:50, John Stultz wrote:
> This is an initial swing at getting the adv7511 hdmi bridge
> audio support reviewed.
>
> I've taken the core audio work done by Lars-Peter Clausen, and
> adapted by Srinivas Kandagatla and Archit Taneja, and tried to
> rework it to use the hdmi-codec sound driver.
>
> This patchset, along with the i2s driver and dts changes allows
> HDMI audio to work on the HiKey board.
>
> I'd really appreciate any thoughts or feedback.

Thanks for putting up these patches together,

I tested them on DB410c on top of v4.8-rc3 with a dt 
patch(https://git.linaro.org/people/srinivas.kandagatla/linux.git/commit/ac06c0e91b1a0ac83a0d2946e593fcdd73836896)
 
and it works great.


Tested-by: Srinivas Kandagatla 

thanks,
srini
>
> thanks
> -john
>
> Cc: David Airlie 
> Cc: Archit Taneja 
> Cc: Laurent Pinchart 
> Cc: Wolfram Sang 
> Cc: Srinivas Kandagatla 
> Cc: "Ville Syrjälä" 
> Cc: Boris Brezillon 
> Cc: Andy Green 
> Cc: Dave Long 
> Cc: Guodong Xu 
> Cc: Zhangfei Gao 
> Cc: Mark Brown 
> Cc: Lars-Peter Clausen 
> Cc: Jose Abreu 
> Cc: dri-devel at lists.freedesktop.org
> Andy Green (1):
>   drm/bridge: adv7511: Initialize audio packet on adv7533
>
> Archit Taneja (1):
>   drm/bridge: adv7511: Move the common data structures to header file
>
> John Stultz (1):
>   drm/bridge: adv7511: Add Audio support.
>
> Srinivas Kandagatla (1):
>   drm/bridge: adv7511: Enable the audio data and clock pads on adv7533
>
>  drivers/gpu/drm/bridge/adv7511/Kconfig |   1 +
>  drivers/gpu/drm/bridge/adv7511/Makefile|   2 +-
>  drivers/gpu/drm/bridge/adv7511/adv7511.h   |  12 ++
>  drivers/gpu/drm/bridge/adv7511/adv7511_audio.c | 208 
> +
>  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   |   9 +-
>  drivers/gpu/drm/bridge/adv7511/adv7533.c   |  23 +++
>  6 files changed, 252 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
>

[PATCH 2/2] drm: make DRI1 drivers depend on BROKEN

[Emil Velikov]

On 26 August 2016 at 04:04, Kevin Brace  wrote:
> Hi Emil,
>
>> Hi Kevin,
>>
>> On 26 August 2016 at 01:19, Kevin Brace  wrote:
>>
>> > I do not want to be seen as stopping progress, but there are still people 
>> > who use less than current hardware (myself and countless others) or non 
>> > Big 3 x86 graphics (NVIDIA, AMD, and Intel) for things like thin clients.
>>
>> [snip]
>> > Anyway, regarding the move to DRI2 / KMS so that DRI1 can be discontinued, 
>> > I am not personally against it in the long run, but the work on it has 
>> > stalled.
>> >
>> Afaict nobody is discontinuing DRI1, but marking it as BROKEN. Why you
>> may ask - simply because there has been virtually zero development
>> effort (general refactoring do not count) and serious testing, for
>> those drivers over the last 5+ years.
>>
>
> If I am correct, OpenChrome DDX's Xv and XvMC still uses DRI1 if I am correct.
> That being said, I have not really touched that part of the code. (I have 
> been working on mainly fixing display detection and standby resume issues for 
> the past 6 months since I obtained commit privilege.)
>
Guess I should have put stronger emphasis on _serious testing_.

And yes, most people here are familiar with your work on the DDX side
and the previous one by James.

>
>> FWIW I would strongly recommend leaving UMS at peace and working
>> towards KMS. Having a hybrid UMS/KMS stack is possible, but it's far
>> too picky and time consuming even for larger teams.
>> On the forward porting efforts - DRM evolves rapidly so one could
>> consider starting from scratch. Wire up the (atomic?) mode setting
>> side first then think about the render side of things.
>>
>> Regards,
>> Emil
>>
>
> Here is the drm-openchrome's new DRM James Simmons (the previous OpenChrome 
> developer who did tremendous work between 2011 to early 2015, but has 
> completely disappeared) worked on.
>
> https://cgit.freedesktop.org/openchrome/drm-openchrome/tree/drivers/gpu/drm/via
>
> I do not mean to criticize you, but how easy is it to start from scratch when 
> there is that much code I will have to replace?
As suggested above - start small. Here is a more comprehensive list:
Stage 1:
KMS (display only) driver, without any custom ioctls/uapi that works
~ok with the modesetting ddx.
Only a single working output (type) is needed and the driver should be
ok to merge upstream.

 1 pick a trivial (ideally atomic) KMS driver as a base
 2 add the stubs, consider using CMA at first.
 3 pick a single display engines/resources (VGA, HDMI...) and wire it up.
 4 add hw module/engines only when needed by the above.
 5 make sure it's working OK(ish) with the modesetting ddx.

Stage 2(?)
As you can now drive an output you can continue with a) the other
output types b) look into PM or c) start on the render side of things.
If the last one - once the driver has achieved milestone push towards
upstream inclusion.

 1 Reconsider CMA vs other memory management, fb and other HW specifics
 2 Pick one usespace component - mesa/ddx.
 3 Design _new_ UAPI, get initial code (kernel and userspace), do very
rough benchmarking/perf analysis
 4 Get X, glxgears or XXX (sort of) working.

...
Profit ;-)

That's enough divergion from the original thread from me. If we have
anything else can we keep it separate ?

Sorry for hijacking the thread.
Emil

Plan to support Rockchip VPU in DRM, is it a good idea

[Hans Verkuil]

On 08/26/2016 12:05 PM, Randy Li wrote:
> 
> 
> On 08/26/2016 05:34 PM, Hans Verkuil wrote:
>> Hi Randi,
>>
>> On 08/26/2016 04:13 AM, Randy Li wrote:
>>> Hello,
>>>We always use some kind of hack work to make our Video Process
>>> Unit(Multi-format Video Encoder/Decoder) work in kernel. From a
>>> customize driver(vpu service) to the customize V4L2 driver. The V4L2
>>> subsystem is really not suitable for the stateless Video process or it
>>> could make driver too fat.
>>>After talking to some kindness Intel guys and moving our userspace
>>> library to VA-API driver, I find the DRM may the good choice for us.
>>> But I don't know whether it is welcome to to submit a video driver in
>>> DRM subsystem?
>>>Also our VPU(Video process unit) is not just like the Intel's, we
>>> don't have VCS, we based on registers to set the encoder/decoder. I
>>> think we may need a lots of IOCTL then. Also we do have a IOMMU in VPU
>>> but also not a isolated memory for VPU, I don't know I should use TT
>>> memory or GEM memory.
>>>I am actually not a member of the department in charge of VPU, and I
>>> am just beginning to learning DRM(thank the help from Intel again), I am
>>> not so good at memory part as well(I am more familiar with CMA not the
>>> IOMMU way), I may need know guide about the implementations when I am
>>> going to submit driver, I hope I could get help from someone.
>>>
>>
>> It makes no sense to do this in the DRM subsystem IMHO. There are already
>> quite a few HW codecs implemented in the V4L2 subsystem and more are in the
>> pipeline. Putting codec support in different subsystems will just make
>> userspace software much harder to write.
>>
>> One of the codecs that was posted to linux-media was actually from Rockchip:
>>
>> https://lkml.org/lkml/2016/2/29/861
>>
>> There is also a libVA driver (I think) that sits on top of it:
>>
>> https://github.com/rockchip-linux/rockchip-va-driver/tree/v4l2-libvpu
> It is old version, I am the author of this
> https://github.com/rockchip-linux/rockchip-va-driver
>>
>> For the Allwinner a patch series was posted yesterday:
>>
>> https://lkml.org/lkml/2016/8/25/246
>>
>> They created a pretty generic libVA userspace that looks very promising at
>> first glance.
>>
>> What these have in common is that they depend on the Request API and Frame 
>> API,
>> neither of which has been merged. The problem is that the Request API 
>> requires
>> more work since not only controls have to be part of a request, but also 
>> formats,
>> selection rectangles, and even dynamic routing changes. While that is not 
>> relevant
>> for codecs, it is relevant for Android CameraHAL in general and complex 
>> devices
>> like Google's Project Ara.
> Actually just as the Intel did, our hardware decoder/encoder need full 
> settings for them, most of them are relevant to the codec. You may 
> notice that there is four extra control need to be set before. If the 
> libvpu(a helper library we offered to parse each slice to generate 
> decoder settings) is remove(in process now, only three decoder settings 
> can't got from VA-API directly), it would be more clearly.
> We really a lots decoder settings information to make the decoder work.
>>
>> This is being worked on, but it is simply not yet ready. The core V4L2 
>> developers
>> involved in this plan to discuss this on the Monday before the ELCE in 
>> Berlin,
>> to see if we can fast track this work somehow so this support can be merged.
>>
> I am glad to hear that. I hope that I could have an opportunity to show 
> our problems.
>> If there are missing features in V4L2 (other that the two APIs discussed 
>> above)
>> that prevent you from creating a good driver, then please discuss that with 
>> us.
>> We are always open to suggestions and improvements and want to work with you 
>> on
>> that.
> I have a few experience with the s5p-mfc, and I do wrote a V4L2 encoder 
> plugin for Gstreamer.  I don't think the V4L2 is good place for us 
> stateless video processor, unless it would break the present implementation.
> 
>The stateful and stateless are operated quite differently. The 
> stateless must parse the header and set those settings for every frames.
> The request data may quite different from vendor to vendor, even chip to 
> chip. It is impossible to make a common way to send those settings to 
> driver.For the samsung MFC, you don't need to do any parse work at all.
>Anyway, I would like to follow what Intel does now, we are both 
> stateless video processor.

I don't see the problem. As I understand it what the hardware needs is the
video data and settings (i.e. 'state'). It will process the video data (encode
or decode) and return the result (probably with additional settings/state).

V4L2 + Request API does exactly that. What does DRM offer you that makes life
easier for you compared to V4L2? I am not aware of Intel upstreaming any of
their codec solutions, if you have pointers to patches from them 

[RFC] drm: implement generic firmware eviction

[Jani Nikula]

On Fri, 26 Aug 2016, David Herrmann  wrote:
> Provide a generic DRM helper that evicts all conflicting firmware
> framebuffers, devices, and drivers. The new helper is called
> drm_evict_firmware(), and takes a flagset controlling which firmware to
> kick out.

Reading the subject, I thought this was somehow about the firmware
themselves, not about their framebuffers... My bikeshed is to make that
clear in the function name too.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH] drm/tegra: dc: Apply clipping to the overlay plane

[Dmitry Osipenko]

Overlay plane should be clipped, otherwise overlay output gets distorted
once plane crosses display boundary. As a "side effect" this patch also
adds a sanity check for the primary plane, insuring that it covers whole
display area.

Signed-off-by: Dmitry Osipenko 
---
 drivers/gpu/drm/tegra/dc.c | 85 ++
 1 file changed, 56 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 4010d69..ddac53c 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -480,31 +480,24 @@ static const struct drm_plane_funcs 
tegra_primary_plane_funcs = {
.atomic_destroy_state = tegra_plane_atomic_destroy_state,
 };

-static int tegra_plane_state_add(struct tegra_plane *plane,
-struct drm_plane_state *state)
+static void tegra_plane_state_add(struct tegra_plane *plane,
+ struct drm_crtc_state *crtc_state)
 {
-   struct drm_crtc_state *crtc_state;
-   struct tegra_dc_state *tegra;
-
-   /* Propagate errors from allocation or locking failures. */
-   crtc_state = drm_atomic_get_crtc_state(state->state, state->crtc);
-   if (IS_ERR(crtc_state))
-   return PTR_ERR(crtc_state);
-
-   tegra = to_dc_state(crtc_state);
+   struct tegra_dc_state *tegra = to_dc_state(crtc_state);

tegra->planes |= WIN_A_ACT_REQ << plane->index;
-
-   return 0;
 }

 static int tegra_plane_atomic_check(struct drm_plane *plane,
-   struct drm_plane_state *state)
+   struct drm_plane_state *state,
+   bool overlay)
 {
struct tegra_plane_state *plane_state = to_tegra_plane_state(state);
struct tegra_bo_tiling *tiling = _state->tiling;
struct tegra_plane *tegra = to_tegra_plane(plane);
struct tegra_dc *dc = to_tegra_dc(state->crtc);
+   struct drm_crtc_state *crtc_state;
+   struct drm_rect clip;
int err;

/* no need for further checks if the plane is being disabled */
@@ -538,13 +531,38 @@ static int tegra_plane_atomic_check(struct drm_plane 
*plane,
}
}

-   err = tegra_plane_state_add(tegra, state);
+   /* propagate errors from allocation or locking failures. */
+   crtc_state = drm_atomic_get_crtc_state(state->state, state->crtc);
+   if (IS_ERR(crtc_state))
+   return PTR_ERR(crtc_state);
+
+   /* check plane for visibility and apply clipping */
+   clip.x1 = 0;
+   clip.y1 = 0;
+   clip.x2 = crtc_state->mode.hdisplay;
+   clip.y2 = crtc_state->mode.vdisplay;
+
+   err = drm_plane_helper_check_state(state, , 0, INT_MAX,
+  overlay, true);
if (err < 0)
return err;

+   if (!state->visible) {
+   DRM_ERROR("hardware doesn't handle invisible plane\n");
+   return -EINVAL;
+   }
+
+   tegra_plane_state_add(tegra, crtc_state);
+
return 0;
 }

+static int tegra_primary_plane_atomic_check(struct drm_plane *plane,
+   struct drm_plane_state *state)
+{
+   return tegra_plane_atomic_check(plane, state, false);
+}
+
 static void tegra_plane_atomic_update(struct drm_plane *plane,
  struct drm_plane_state *old_state)
 {
@@ -560,14 +578,14 @@ static void tegra_plane_atomic_update(struct drm_plane 
*plane,
return;

memset(, 0, sizeof(window));
-   window.src.x = plane->state->src_x >> 16;
-   window.src.y = plane->state->src_y >> 16;
-   window.src.w = plane->state->src_w >> 16;
-   window.src.h = plane->state->src_h >> 16;
-   window.dst.x = plane->state->crtc_x;
-   window.dst.y = plane->state->crtc_y;
-   window.dst.w = plane->state->crtc_w;
-   window.dst.h = plane->state->crtc_h;
+   window.src.x = plane->state->src.x1 >> 16;
+   window.src.y = plane->state->src.y1 >> 16;
+   window.src.w = drm_rect_width(>state->src) >> 16;
+   window.src.h = drm_rect_height(>state->src) >> 16;
+   window.dst.x = plane->state->dst.x1;
+   window.dst.y = plane->state->dst.y1;
+   window.dst.w = drm_rect_width(>state->dst);
+   window.dst.h = drm_rect_height(>state->dst);
window.bits_per_pixel = fb->bits_per_pixel;
window.bottom_up = tegra_fb_is_bottom_up(fb);

@@ -620,7 +638,7 @@ static void tegra_plane_atomic_disable(struct drm_plane 
*plane,
 }

 static const struct drm_plane_helper_funcs tegra_primary_plane_helper_funcs = {
-   .atomic_check = tegra_plane_atomic_check,
+   .atomic_check = tegra_primary_plane_atomic_check,
.atomic_update = tegra_plane_atomic_update,
.atomic_disable = tegra_plane_atomic_disable,
 };
@@ -675,7 +693,7 @@ static int tegra_cursor_atomic_check(struct drm_plane 
*plane,
   

[PATCH 2/2] drm: make DRI1 drivers depend on BROKEN

[Dave Airlie]

On 4 August 2016 at 18:06, David Herrmann  wrote:
> The legacy DRI1 drivers expose highly broken interfaces to user-space. No
> modern system should enable them, or you will effectively allow user-space
> to circumvent most of your kernel security measures. The DRI1 kernel APIs
> are simply broken.
>
> User-space can always use vesafb/efifb/simplefb and friends to get working
> graphics.
>
> Lets hide the old drivers behind CONFIG_BROKEN. In case they turn out to
> be still used (really?), we can easily revert this and figure out a way to
> move them out of sight (e.g., moving all DRI1 drivers to
> drivers/gpu/dri1/).
>
> Signed-off-by: David Herrmann 

So my opinion is that no modern system enables them in practice.

You can only load dri1 drivers on dri1 hardware, so you aren't exactly leaving
yourself open to root holes here. If you mean the fact that we keep leaving the
ioctls answering when dri2 drivers are loaded due to errors, then I hope we've
figured all those out by now.

Dave.

[Bug 97494] Tonga vce perf regression since drm/amdgpu: add vce bypass mode for tonga.

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

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

Bug ID: 97494
   Summary: Tonga vce perf regression since drm/amdgpu: add vce
bypass mode for tonga.
   Product: DRI
   Version: DRI git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: adf.lists at gmail.com

R9285 agd5f drm-next-4.9-wip since 

commit c04399f19436616875879ee2711c5b78a90dd1b0
Author: Rex Zhu 
Date:   Thu Aug 18 18:27:14 2016 +0800

drm/amdgpu: add vce bypass mode for tonga.

fix issue that encode test failed on the second time when
vce dpm enabled on tonga.

vce clocks seem stuck low, forcing gpu perf to high doesn't help.

500 frames 2160p nv12 from/to ram.

omx 8 seconds -> 35

vaapi 12 seconds -> 51

-- 
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/20160826/4e4a7f69/attachment.html>

[PATCH 5/5] drm/vmwgfx: Remove call to reservation_object_test_signaled_rcu before wait

[Sinclair Yeh]

Reviewed-by: Sinclair Yeh 

On Thu, Aug 11, 2016 at 03:46:22PM +0100, Chris Wilson wrote:
> Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
> timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
> need to handle such conversion in the caller. The only challenge are
> those callers that wish to differentiate the error code between the
> nonblocking busy check and potentially blocking wait.
> 
> Signed-off-by: Chris Wilson 
> Cc: Sinclair Yeh 
> Cc: Thomas Hellstrom 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
> index 6a328d507a28..afda2a57a094 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
> @@ -574,10 +574,8 @@ static int vmw_user_dmabuf_synccpu_grab(struct 
> vmw_user_dma_buffer *user_bo,
>   bool nonblock = !!(flags & drm_vmw_synccpu_dontblock);
>   long lret;
>  
> - if (nonblock)
> - return reservation_object_test_signaled_rcu(bo->resv, 
> true) ? 0 : -EBUSY;
> -
> - lret = reservation_object_wait_timeout_rcu(bo->resv, true, 
> true, MAX_SCHEDULE_TIMEOUT);
> + lret = reservation_object_wait_timeout_rcu(bo->resv, true, true,
> +nonblock ? 0 
> :MAX_SCHEDULE_TIMEOUT);
>   if (!lret)
>   return -EBUSY;
>   else if (lret < 0)
> -- 
> 2.8.1
> 

Plan to support Rockchip VPU in DRM, is it a good idea

[Hans Verkuil]

Hi Randi,

On 08/26/2016 04:13 AM, Randy Li wrote:
> Hello,
>We always use some kind of hack work to make our Video Process 
> Unit(Multi-format Video Encoder/Decoder) work in kernel. From a 
> customize driver(vpu service) to the customize V4L2 driver. The V4L2 
> subsystem is really not suitable for the stateless Video process or it 
> could make driver too fat.
>After talking to some kindness Intel guys and moving our userspace 
> library to VA-API driver, I find the DRM may the good choice for us.
> But I don't know whether it is welcome to to submit a video driver in 
> DRM subsystem?
>Also our VPU(Video process unit) is not just like the Intel's, we 
> don't have VCS, we based on registers to set the encoder/decoder. I 
> think we may need a lots of IOCTL then. Also we do have a IOMMU in VPU 
> but also not a isolated memory for VPU, I don't know I should use TT 
> memory or GEM memory.
>I am actually not a member of the department in charge of VPU, and I 
> am just beginning to learning DRM(thank the help from Intel again), I am 
> not so good at memory part as well(I am more familiar with CMA not the 
> IOMMU way), I may need know guide about the implementations when I am 
> going to submit driver, I hope I could get help from someone.
> 

It makes no sense to do this in the DRM subsystem IMHO. There are already
quite a few HW codecs implemented in the V4L2 subsystem and more are in the
pipeline. Putting codec support in different subsystems will just make
userspace software much harder to write.

One of the codecs that was posted to linux-media was actually from Rockchip:

https://lkml.org/lkml/2016/2/29/861

There is also a libVA driver (I think) that sits on top of it:

https://github.com/rockchip-linux/rockchip-va-driver/tree/v4l2-libvpu

For the Allwinner a patch series was posted yesterday:

https://lkml.org/lkml/2016/8/25/246

They created a pretty generic libVA userspace that looks very promising at
first glance.

What these have in common is that they depend on the Request API and Frame API,
neither of which has been merged. The problem is that the Request API requires
more work since not only controls have to be part of a request, but also 
formats,
selection rectangles, and even dynamic routing changes. While that is not 
relevant
for codecs, it is relevant for Android CameraHAL in general and complex devices
like Google's Project Ara.

This is being worked on, but it is simply not yet ready. The core V4L2 
developers
involved in this plan to discuss this on the Monday before the ELCE in Berlin,
to see if we can fast track this work somehow so this support can be merged.

If there are missing features in V4L2 (other that the two APIs discussed above)
that prevent you from creating a good driver, then please discuss that with us.
We are always open to suggestions and improvements and want to work with you on
that.

Regards,

Hans

[PATCH] drm/amdgpu: Add amdkfd softdep

[Michel Dänzer]

On 26/08/16 02:10 AM, Michal Marek wrote:
> amdgpu loads amdkfd via symbol_request(). Add a softdep hint so that
> userspace knows that amdgpu needs amdkfd in the initrd.
> 
> Reported-and-tested-by: Martin Jambor 
> Signed-off-by: Michal Marek 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 9aa533cf4ad1..9c469cd311ca 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -633,3 +633,4 @@ module_exit(amdgpu_exit);
>  MODULE_AUTHOR(DRIVER_AUTHOR);
>  MODULE_DESCRIPTION(DRIVER_DESC);
>  MODULE_LICENSE("GPL and additional rights");
> +MODULE_SOFTDEP("pre: amdkfd");

Will this work if amdkfd isn't built (CONFIG_HSA_AMD=n)?


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

[PATCH] drm/amdgpu: Add amdkfd softdep

[Michal Marek]

On 2016-08-26 04:20, Michel Dänzer wrote:
> On 26/08/16 02:10 AM, Michal Marek wrote:
>> amdgpu loads amdkfd via symbol_request(). Add a softdep hint so that
>> userspace knows that amdgpu needs amdkfd in the initrd.
>>
>> Reported-and-tested-by: Martin Jambor 
>> Signed-off-by: Michal Marek 
>> ---
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>> index 9aa533cf4ad1..9c469cd311ca 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>> @@ -633,3 +633,4 @@ module_exit(amdgpu_exit);
>>  MODULE_AUTHOR(DRIVER_AUTHOR);
>>  MODULE_DESCRIPTION(DRIVER_DESC);
>>  MODULE_LICENSE("GPL and additional rights");
>> +MODULE_SOFTDEP("pre: amdkfd");
> 
> Will this work if amdkfd isn't built (CONFIG_HSA_AMD=n)?

It's a soft dependency, so it will be silently ignored. /sbin/modprobe
--show-depends amdgpu will only list amdgpu.ko and its hard depedencies.

Michal

[RFC] drm: implement generic firmware eviction

[Hans de Goede]

Hi,

On 26-08-16 10:58, Maxime Ripard wrote:
> Hi,
>
> On Fri, Aug 26, 2016 at 10:43:55AM +0200, Hans de Goede wrote:
 I'm not sure we would want to remove the device at all, we
 certainly should not be removing the dt_node from the devicetree
 IMHO. Having that around to see how the bootloader set things up
 is really useful for debugging and normally we should never modify
 the devicetree as set up by the bootloader.

 Why not just unbind the driver from the platform device? That
 should be enough.
>>>
>>> That will leave IORESOURCE_MEM around, causing conflicts if
>>> re-used/claimed by other devices/drivers. Furthermore, it is really
>>> fragile leaving the device around, without any control over
>>> possible future driver probing.
>>
>> Ah, good point. On ARM this currently typically is reserved by the bootloader
>> so never touched by the kernel at all, not even when the simplefb is no 
>> longer
>> used, actually returning this memory to the kernel after unbinding the 
>> simplefb /
>> destroying the simplefb platform-dev would be really good to do. We should
>> probably figure out how that should be done before getting rid of
>> remove_conflicting_framebuffers... (sorry).
>
> That would be rather easy to do. The firmware could generate a
> reserved-memory node instead of passing a smaller memory size to the
> kernel. That way, the kernel will know that it's actual ram that it
> can reclaim.

So when would the kernel reclaim the RAM then? We do not want it
to reclaim before loading the simplefb / simpledrm driver.

And the real drm driver will likely be a module, so if the kernel
reclaims just before executing /sbin/init that would be too
early, unless we can somehow manually make it do another reclaim
pass when the simplefb gets disabled ...

Regards,

Hans

[RFC] drm: implement generic firmware eviction

[Maxime Ripard]

Hi,

On Fri, Aug 26, 2016 at 10:43:55AM +0200, Hans de Goede wrote:
> >>I'm not sure we would want to remove the device at all, we
> >>certainly should not be removing the dt_node from the devicetree
> >>IMHO. Having that around to see how the bootloader set things up
> >>is really useful for debugging and normally we should never modify
> >>the devicetree as set up by the bootloader.
> >>
> >>Why not just unbind the driver from the platform device? That
> >>should be enough.
> >
> >That will leave IORESOURCE_MEM around, causing conflicts if
> >re-used/claimed by other devices/drivers. Furthermore, it is really
> >fragile leaving the device around, without any control over
> >possible future driver probing.
> 
> Ah, good point. On ARM this currently typically is reserved by the bootloader
> so never touched by the kernel at all, not even when the simplefb is no longer
> used, actually returning this memory to the kernel after unbinding the 
> simplefb /
> destroying the simplefb platform-dev would be really good to do. We should
> probably figure out how that should be done before getting rid of
> remove_conflicting_framebuffers... (sorry).

That would be rather easy to do. The firmware could generate a
reserved-memory node instead of passing a smaller memory size to the
kernel. That way, the kernel will know that it's actual ram that it
can reclaim.

Maxime

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

[PATCH] modetest: Adding amdgpu to module list

[Alex Deucher]

From: satsahu 

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

diff --git a/tests/util/kms.c b/tests/util/kms.c
index 650b23b..c20134e 100644
--- a/tests/util/kms.c
+++ b/tests/util/kms.c
@@ -127,6 +127,7 @@ const char *util_lookup_connector_type_name(unsigned int 
type)

 static const char * const modules[] = {
"i915",
+   "amdgpu",
"radeon",
"nouveau",
"vmwgfx",
-- 
2.5.5

[RFC] drm: implement generic firmware eviction

[Hans de Goede]

Hi,

On 26-08-16 10:01, David Herrmann wrote:
> Hi
>
> On Fri, Aug 26, 2016 at 9:57 AM, Hans de Goede  wrote:
>> Hi,
>>
>> On 26-08-16 02:00, David Herrmann wrote:
>>>
>>> Provide a generic DRM helper that evicts all conflicting firmware
>>> framebuffers, devices, and drivers. The new helper is called
>>> drm_evict_firmware(), and takes a flagset controlling which firmware to
>>> kick out.
>>>
>>> This is meant to be used by drivers in their ->probe() callbacks of their
>>> parent bus, before calling into drm_dev_register().
>>>
>>> Signed-off-by: David Herrmann 
>>> ---
>>> Hey
>>>
>>> This is just compile-tested for now. I just want to get some comments on
>>> the
>>> design. I decided to drop the sysfb infrastructure and rather just use
>>> this
>>> generic helper. It keeps things simple and should work just fine for all
>>> reasonable use-cases.
>>>
>>> This will work with SimpleDRM out-of-the-box on x86.
>>>
>>> Architectures with dynamic simple-framebuffer devices are not supported
>>> yet. I
>>> actually have no idea what the strategy there is? Can the DeviceTree
>>> people come
>>> up with something? Am I supposed to call of_platform_depopulate()? Or
>>> of_detach_node()? Or what?
>>
>>
>> I'm not sure we would want to remove the device at all, we certainly should
>> not
>> be removing the dt_node from the devicetree IMHO. Having that around to see
>> how
>> the bootloader set things up is really useful for debugging and normally we
>> should never modify the devicetree as set up by the bootloader.
>>
>> Why not just unbind the driver from the platform device? That should be
>> enough.
>
> That will leave IORESOURCE_MEM around, causing conflicts if
> re-used/claimed by other devices/drivers. Furthermore, it is really
> fragile leaving the device around, without any control over possible
> future driver probing.

Ah, good point. On ARM this currently typically is reserved by the bootloader
so never touched by the kernel at all, not even when the simplefb is no longer
used, actually returning this memory to the kernel after unbinding the simplefb 
/
destroying the simplefb platform-dev would be really good to do. We should
probably figure out how that should be done before getting rid of
remove_conflicting_framebuffers... (sorry).

Regards,

Hans

[Bug 97492] Occasional harmless [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* ttm_eu_reserve_buffers failed.

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

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

Bug ID: 97492
   Summary: Occasional harmless [drm:amdgpu_cs_ioctl [amdgpu]]
*ERROR* ttm_eu_reserve_buffers failed.
   Product: DRI
   Version: DRI git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: adf.lists at gmail.com

R9285 Tonga running latest agd5f wip kernels.

No ill effects noticed, but I sometimes see in dmesg -

[drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* ttm_eu_reserve_buffers failed.

Can't find any way to make them happen, guessing from time maybe to do with
startx or coming out of dpms, but not sure.

grepping kernel log and I've had 22 starting Aug 7th.

-- 
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/20160826/70bed549/attachment-0001.html>

[PATCH 2/3] drm/rockchip: Don't key off vblank for psr

[Yakir Yang]

Sean,

Thanks for this good fix.

On 08/19/2016 07:34 AM, Sean Paul wrote:
> Instead of keying off vblank for psr, just flush every time
> we get an atomic update. This ensures that cursor updates
> will properly disable psr (without turning vblank on/off),
> and unifies the paths between fb_dirty and atomic psr
> enable/disable.
>
> Signed-off-by: Sean Paul 

Reviewed-by: Yakir Yang 

Also I have verified this patch on RK3399 Kevin, eDP PSR works rightly, so

Tested-by: Yakir Yang 

- Yakir

> ---
>   drivers/gpu/drm/rockchip/rockchip_drm_fb.c  |  2 +-
>   drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 72 
> -
>   drivers/gpu/drm/rockchip/rockchip_drm_psr.h |  8 ++--
>   drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 10 ++--
>   4 files changed, 62 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> index ba45d9d..10cafbc 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> @@ -70,7 +70,7 @@ static int rockchip_drm_fb_dirty(struct drm_framebuffer *fb,
>struct drm_clip_rect *clips,
>unsigned int num_clips)
>   {
> - rockchip_drm_psr_flush(fb->dev);
> + rockchip_drm_psr_flush_all(fb->dev);
>   return 0;
>   }
>   
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
> index c6ac5d0..de6252f 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
> @@ -31,6 +31,7 @@ struct psr_drv {
>   struct drm_encoder  *encoder;
>   
>   spinlock_t  lock;
> + boolactive;
>   enum psr_state  state;
>   
>   struct timer_list   flush_timer;
> @@ -67,11 +68,7 @@ static void psr_set_state_locked(struct psr_drv *psr, enum 
> psr_state state)
>*   v ||
>*   PSR_DISABLE < - - - - - - - - -
>*/
> - if (state == psr->state)
> - return;
> -
> - /* Requesting a flush when disabled is a noop */
> - if (state == PSR_FLUSH && psr->state == PSR_DISABLE)
> + if (state == psr->state || !psr->active)
>   return;
>   
>   psr->state = state;
> @@ -115,45 +112,79 @@ static void psr_flush_handler(unsigned long data)
>   }
>   
>   /**
> - * rockchip_drm_psr_enable - enable the encoder PSR which bind to given CRTC
> + * rockchip_drm_psr_activate - activate PSR on the given pipe
>* @crtc: CRTC to obtain the PSR encoder
>*
>* Returns:
>* Zero on success, negative errno on failure.
>*/
> -int rockchip_drm_psr_enable(struct drm_crtc *crtc)
> +int rockchip_drm_psr_activate(struct drm_crtc *crtc)
>   {
>   struct psr_drv *psr = find_psr_by_crtc(crtc);
> + unsigned long flags;
>   
>   if (IS_ERR(psr))
>   return PTR_ERR(psr);
>   
> - psr_set_state(psr, PSR_ENABLE);
> + spin_lock_irqsave(>lock, flags);
> + psr->active = true;
> + spin_unlock_irqrestore(>lock, flags);
> +
>   return 0;
>   }
> -EXPORT_SYMBOL(rockchip_drm_psr_enable);
> +EXPORT_SYMBOL(rockchip_drm_psr_activate);
>   
>   /**
> - * rockchip_drm_psr_disable - disable the encoder PSR which bind to given 
> CRTC
> + * rockchip_drm_psr_deactivate - deactivate PSR on the given pipe
>* @crtc: CRTC to obtain the PSR encoder
>*
>* Returns:
>* Zero on success, negative errno on failure.
>*/
> -int rockchip_drm_psr_disable(struct drm_crtc *crtc)
> +int rockchip_drm_psr_deactivate(struct drm_crtc *crtc)
>   {
>   struct psr_drv *psr = find_psr_by_crtc(crtc);
> + unsigned long flags;
> +
> + if (IS_ERR(psr))
> + return PTR_ERR(psr);
> +
> + spin_lock_irqsave(>lock, flags);
> + psr->active = false;
> + spin_unlock_irqrestore(>lock, flags);
> + del_timer_sync(>flush_timer);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(rockchip_drm_psr_deactivate);
> +
> +static void rockchip_drm_do_flush(struct psr_drv *psr)
> +{
> + mod_timer(>flush_timer,
> +   round_jiffies_up(jiffies + PSR_FLUSH_TIMEOUT));
> + psr_set_state(psr, PSR_FLUSH);
> +}
>   
> +/**
> + * rockchip_drm_psr_flush - flush a single pipe
> + * @crtc: CRTC of the pipe to flush
> + *
> + * Returns:
> + * 0 on success, -errno on fail
> + */
> +int rockchip_drm_psr_flush(struct drm_crtc *crtc)
> +{
> + struct psr_drv *psr = find_psr_by_crtc(crtc);
>   if (IS_ERR(psr))
>   return PTR_ERR(psr);
>   
> - psr_set_state(psr, PSR_DISABLE);
> + rockchip_drm_do_flush(psr);
>   return 0;
>   }
> -EXPORT_SYMBOL(rockchip_drm_psr_disable);
> +EXPORT_SYMBOL(rockchip_drm_psr_flush);
>   
>   /**
> - * rockchip_drm_psr_flush - force to flush all registered PSR encoders
> + * rockchip_drm_psr_flush_all - force to flush all registered PSR encoders
>* @dev: drm device
>

[PATCH 3/3] drm/rockchip: Reduce psr flush time to 100ms

[Yakir Yang]

Sean,

On 08/19/2016 07:34 AM, Sean Paul wrote:
> 3 seconds is a bit too conservative, drop this to 100ms for
> better power savings.
>
> Signed-off-by: Sean Paul 

Reviewed-by: Yakir Yang 

> ---
>   drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
> index de6252f..2cdd6eb 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
> @@ -18,7 +18,7 @@
>   #include "rockchip_drm_drv.h"
>   #include "rockchip_drm_psr.h"
>   
> -#define PSR_FLUSH_TIMEOUTmsecs_to_jiffies(3000) /* 3 seconds */
> +#define PSR_FLUSH_TIMEOUTmsecs_to_jiffies(100)
>   
>   enum psr_state {
>   PSR_FLUSH,

[PATCH v2 25/25] arm64: dts: apq8016-sbc: Add HDMI display support

[Archit Taneja]

On 06/23/2016 07:43 PM, Archit Taneja wrote:
> The APQ8016-sbc provides a HDMI output. The APQ8016 display block only
> provides a MIPI DSI output. So, the board has a ADV7533 DSI to HDMI
> encoder chip that sits between the DSI PHY output and the HDMI
> connector.
>
> Add the ADV7533 DT node under its I2C control bus, and tie the DSI
> output port to the ADV7533's input port.

and this one too?

Thanks,
Archit

>
> Cc: Andy Gross 
> Cc: Rob Herring 
> Cc: devicetree at vger.kernel.org
>
> Signed-off-by: Archit Taneja 
> ---
>   arch/arm64/boot/dts/qcom/apq8016-sbc-soc-pins.dtsi | 48 +
>   arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi  | 82 
> ++
>   2 files changed, 130 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc-soc-pins.dtsi 
> b/arch/arm64/boot/dts/qcom/apq8016-sbc-soc-pins.dtsi
> index ee828a8..e1e6c6b 100644
> --- a/arch/arm64/boot/dts/qcom/apq8016-sbc-soc-pins.dtsi
> +++ b/arch/arm64/boot/dts/qcom/apq8016-sbc-soc-pins.dtsi
> @@ -24,4 +24,52 @@
>   bias-pull-up;
>   };
>   };
> +
> + adv7533_int_active: adv533_int_active {
> + pinmux {
> + function = "gpio";
> + pins = "gpio31";
> + };
> + pinconf {
> + pins = "gpio31";
> + drive-strength = <16>;
> + bias-disable;
> + };
> + };
> +
> + adv7533_int_suspend: adv7533_int_suspend {
> + pinmux {
> + function = "gpio";
> + pins = "gpio31";
> + };
> + pinconf {
> + pins = "gpio31";
> + drive-strength = <2>;
> + bias-disable;
> + };
> + };
> +
> + adv7533_switch_active: adv7533_switch_active {
> + pinmux {
> + function = "gpio";
> + pins = "gpio32";
> + };
> + pinconf {
> + pins = "gpio32";
> + drive-strength = <16>;
> + bias-disable;
> + };
> + };
> +
> + adv7533_switch_suspend: adv7533_switch_suspend {
> + pinmux {
> + function = "gpio";
> + pins = "gpio32";
> + };
> + pinconf {
> + pins = "gpio32";
> + drive-strength = <2>;
> + bias-disable;
> + };
> + };
>   };
> diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi 
> b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> index 205ef89..5045695 100644
> --- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> +++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> @@ -59,6 +59,47 @@
>   /* On High speed expansion */
>   label = "HS-I2C2";
>   status = "okay";
> +
> + adv_bridge: bridge at 39 {
> + status = "okay";
> +
> + compatible = "adi,adv7533";
> + reg = <0x39>;
> +
> + interrupt-parent = <>;
> + interrupts = <31 2>;
> +
> + adi,dsi-lanes = <4>;
> +
> + pd-gpios = < 32 0>;
> +
> + avdd-supply = <_l6>;
> + v1p2-supply = <_l6>;
> + v3p3-supply = <_l17>;
> +
> + pinctrl-names = "default","sleep";
> + pinctrl-0 = <_int_active 
> _switch_active>;
> + pinctrl-1 = <_int_suspend 
> _switch_suspend>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> + adv7533_in: endpoint {
> + remote-endpoint = 
> <_out>;
> + };
> + };
> +
> + port at 1 {
> + reg = <1>;
> + adv7533_out: endpoint {
> + remote-endpoint = 
> <_con>;
> + };
> + };
> + };
> + };
>   };
>
>   i2c at 78ba000 {
> @@ -164,6 +205,36 @@
>   lpass at 07708000 {
>   status = "okay";
>   };
> +
> + mdss at 1a0 {
> + status = "okay";
> +
> 

[PATCH v2 24/25] arm64: dts: msm8916: Add display support

[Archit Taneja]

Hi Rob,

On 06/23/2016 07:43 PM, Archit Taneja wrote:
> The MSM8916 SoC contains a MDP5 based display block, and one DSI output.
> Add the top level MDSS DT node, and the MDP5, DSI and DSI PHY children
> sub-blocks. Establish the link between MDP5's INTF1 output port and DSI's
> input port.
>
> Cc: Andy Gross 
> Cc: Rob Herring 
> Cc: devicetree at vger.kernel.org

Can I get an Ack on this?

Thanks,
Archit

>
> Signed-off-by: Archit Taneja 
> ---
> v2:
>   - Removed "qcom,dsi-host-index" and "qcom,dsi-phy-index" props
>
>   arch/arm64/boot/dts/qcom/msm8916.dtsi | 117 
> ++
>   1 file changed, 117 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi 
> b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> index 9681200..fe74fea 100644
> --- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> @@ -537,6 +537,123 @@
>   clocks = < GCC_PRNG_AHB_CLK>;
>   clock-names = "core";
>   };
> +
> + mdss: mdss at 1a0 {
> + compatible = "qcom,mdss";
> + reg = <0x1a0 0x1000>,
> +   <0x1ac8000 0x3000>;
> + reg-names = "mdss_phys", "vbif_phys";
> +
> + power-domains = < MDSS_GDSC>;
> +
> + clocks = < GCC_MDSS_AHB_CLK>,
> +  < GCC_MDSS_AXI_CLK>,
> +  < GCC_MDSS_VSYNC_CLK>;
> + clock-names = "iface_clk",
> +   "bus_clk",
> +   "vsync_clk";
> +
> + interrupts = <0 72 0>;
> +
> + interrupt-controller;
> + #interrupt-cells = <1>;
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + mdp: mdp at 1a01000 {
> + compatible = "qcom,mdp5";
> + reg = <0x1a01000 0x9>;
> + reg-names = "mdp_phys";
> +
> + interrupt-parent = <>;
> + interrupts = <0 0>;
> +
> + clocks = < GCC_MDSS_AHB_CLK>,
> +  < GCC_MDSS_AXI_CLK>,
> +  < GCC_MDSS_MDP_CLK>,
> +  < GCC_MDSS_VSYNC_CLK>;
> + clock-names = "iface_clk",
> +   "bus_clk",
> +   "core_clk",
> +   "vsync_clk";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> + mdp5_intf1_out: endpoint {
> + remote-endpoint = 
> <_in>;
> + };
> + };
> + };
> + };
> +
> + dsi0: dsi at 1a98000 {
> + compatible = "qcom,mdss-dsi-ctrl";
> + reg = <0x1a98000 0x25c>;
> + reg-names = "dsi_ctrl";
> +
> + interrupt-parent = <>;
> + interrupts = <4 0>;
> +
> + assigned-clocks = < BYTE0_CLK_SRC>,
> +   < PCLK0_CLK_SRC>;
> + assigned-clock-parents = <_phy0 0>,
> +  <_phy0 1>;
> +
> + clocks = < GCC_MDSS_MDP_CLK>,
> +  < GCC_MDSS_AHB_CLK>,
> +  < GCC_MDSS_AXI_CLK>,
> +  < GCC_MDSS_BYTE0_CLK>,
> +  < GCC_MDSS_PCLK0_CLK>,
> +  < GCC_MDSS_ESC0_CLK>;
> + clock-names = "mdp_core_clk",
> +   "iface_clk",
> +   "bus_clk",
> +   "byte_clk",
> +   "pixel_clk",
> +   "core_clk";
> + phys = <_phy0>;
> + phy-names = "dsi-phy";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> +  

[PATCH v2 23/25] dt-bindings: display/msm: Remove power domain property from encoder nodes

[Archit Taneja]

Hi Rob,

On 06/23/2016 07:43 PM, Archit Taneja wrote:
> Remove the power-domain property from the DSI, HDMI and eDP dt-binding
> docs. The power domain only needs to be specified in the parent MDSS
> device node (that too only for SoCs which contain MDSS).

Can I get an Ack on this?

Thanks,
Archit

>
> Signed-off-by: Archit Taneja 
> ---
>   Documentation/devicetree/bindings/display/msm/dsi.txt  | 3 ---
>   Documentation/devicetree/bindings/display/msm/edp.txt  | 2 --
>   Documentation/devicetree/bindings/display/msm/hdmi.txt | 4 
>   3 files changed, 9 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt 
> b/Documentation/devicetree/bindings/display/msm/dsi.txt
> index e6933a8..c1ef181 100644
> --- a/Documentation/devicetree/bindings/display/msm/dsi.txt
> +++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
> @@ -8,7 +8,6 @@ Required properties:
>   - reg-names: The names of register regions. The following regions are 
> required:
> * "dsi_ctrl"
>   - interrupts: The interrupt signal from the DSI block.
> -- power-domains: Should be < MDSS_GDSC>.
>   - clocks: Phandles to device clocks.
>   - clock-names: the following clocks are required:
> * "mdp_core_clk"
> @@ -94,7 +93,6 @@ Required properties:
> * "dsi_phy_regulator"
>   - clock-cells: Must be 1. The DSI PHY block acts as a clock provider, 
> creating
> 2 clocks: A byte clock (index 0), and a pixel clock (index 1).
> -- power-domains: Should be < MDSS_GDSC>.
>   - clocks: Phandles to device clocks. See [1] for details on clock bindings.
>   - clock-names: the following clocks are required:
> * "iface_clk"
> @@ -116,7 +114,6 @@ Example:
>   interrupts = <4 0>;
>   reg-names = "dsi_ctrl";
>   reg = <0xfd922800 0x200>;
> - power-domains = < MDSS_GDSC>;
>   clock-names =
>   "bus_clk",
>   "byte_clk",
> diff --git a/Documentation/devicetree/bindings/display/msm/edp.txt 
> b/Documentation/devicetree/bindings/display/msm/edp.txt
> index 3a20f6e..e712dfa 100644
> --- a/Documentation/devicetree/bindings/display/msm/edp.txt
> +++ b/Documentation/devicetree/bindings/display/msm/edp.txt
> @@ -8,7 +8,6 @@ Required properties:
> * "edp"
> * "pll_base"
>   - interrupts: The interrupt signal from the eDP block.
> -- power-domains: Should be < MDSS_GDSC>.
>   - clocks: device clocks
> See Documentation/devicetree/bindings/clocks/clock-bindings.txt for 
> details.
>   - clock-names: the following clocks are required:
> @@ -39,7 +38,6 @@ Example:
>   <0xfd923a00 0xd4>;
>   interrupt-parent = <_mdp>;
>   interrupts = <12 0>;
> - power-domains = < MDSS_GDSC>;
>   clock-names =
>   "core_clk",
>   "pixel_clk",
> diff --git a/Documentation/devicetree/bindings/display/msm/hdmi.txt 
> b/Documentation/devicetree/bindings/display/msm/hdmi.txt
> index b63f614..ce84459 100644
> --- a/Documentation/devicetree/bindings/display/msm/hdmi.txt
> +++ b/Documentation/devicetree/bindings/display/msm/hdmi.txt
> @@ -11,7 +11,6 @@ Required properties:
>   - reg: Physical base address and length of the controller's registers
>   - reg-names: "core_physical"
>   - interrupts: The interrupt signal from the hdmi block.
> -- power-domains: Should be < MDSS_GDSC>.
>   - clocks: device clocks
> See ../clocks/clock-bindings.txt for details.
>   - qcom,hdmi-tx-ddc-clk-gpio: ddc clk pin
> @@ -48,7 +47,6 @@ Required properties:
>   * "hdmi_tx_l1"
>   * "hdmi_tx_l3"
>   * "hdmi_tx_l4"
> -- power-domains: Should be < MDSS_GDSC>.
>   - clocks: device clocks
> See Documentation/devicetree/bindings/clocks/clock-bindings.txt for 
> details.
>   - core-vdda-supply: phandle to vdda regulator device node
> @@ -63,7 +61,6 @@ Example:
>   reg-names = "core_physical";
>   reg = <0x04a0 0x2f0>;
>   interrupts = ;
> - power-domains = < MDSS_GDSC>;
>   clock-names =
>   "core_clk",
>   "master_iface_clk",
> @@ -92,7 +89,6 @@ Example:
>   reg = <0x4a00400 0x60>,
> <0x4a00500 0x100>;
>   #phy-cells = <0>;
> - power-domains = < MDSS_GDSC>;
>   clock-names = "slave_iface_clk";
>   clocks = < HDMI_S_AHB_CLK>;
>   core-vdda-supply = <_hdmi_mvs>;
>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 22/25] dt-bindings: msm/dsi: Remove unused properties

[Archit Taneja]

Hi Rob,

On 06/23/2016 07:43 PM, Archit Taneja wrote:
> Remove the DSI index properties from the DSI host and PHY binding
> documentation. The indices aren't a valid property and shouldn't
> be a part of the DT binding.
>

Can I get an Ack on this?

Thanks,
Archit

> Signed-off-by: Archit Taneja 
> ---
>   Documentation/devicetree/bindings/display/msm/dsi.txt | 6 --
>   1 file changed, 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt 
> b/Documentation/devicetree/bindings/display/msm/dsi.txt
> index 6b1cab1..e6933a8 100644
> --- a/Documentation/devicetree/bindings/display/msm/dsi.txt
> +++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
> @@ -7,8 +7,6 @@ Required properties:
>   - reg: Physical base address and length of the registers of controller
>   - reg-names: The names of register regions. The following regions are 
> required:
> * "dsi_ctrl"
> -- qcom,dsi-host-index: The ID of DSI controller hardware instance. This 
> should
> -  be 0 or 1, since we have 2 DSI controllers at most for now.
>   - interrupts: The interrupt signal from the DSI block.
>   - power-domains: Should be < MDSS_GDSC>.
>   - clocks: Phandles to device clocks.
> @@ -96,8 +94,6 @@ Required properties:
> * "dsi_phy_regulator"
>   - clock-cells: Must be 1. The DSI PHY block acts as a clock provider, 
> creating
> 2 clocks: A byte clock (index 0), and a pixel clock (index 1).
> -- qcom,dsi-phy-index: The ID of DSI PHY hardware instance. This should
> -  be 0 or 1, since we have 2 DSI PHYs at most for now.
>   - power-domains: Should be < MDSS_GDSC>.
>   - clocks: Phandles to device clocks. See [1] for details on clock bindings.
>   - clock-names: the following clocks are required:
> @@ -116,7 +112,6 @@ Optional properties:
>   Example:
>   dsi0: dsi at fd922800 {
>   compatible = "qcom,mdss-dsi-ctrl";
> - qcom,dsi-host-index = <0>;
>   interrupt-parent = <>;
>   interrupts = <4 0>;
>   reg-names = "dsi_ctrl";
> @@ -199,7 +194,6 @@ Example:
>
>   dsi_phy0: dsi-phy at fd922a00 {
>   compatible = "qcom,dsi-phy-28nm-hpm";
> - qcom,dsi-phy-index = <0>;
>   reg-names =
>   "dsi_pll",
>   "dsi_phy",
>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Plan to support Rockchip VPU in DRM, is it a good idea

[Randy Li]

Hello,
   We always use some kind of hack work to make our Video Process 
Unit(Multi-format Video Encoder/Decoder) work in kernel. From a 
customize driver(vpu service) to the customize V4L2 driver. The V4L2 
subsystem is really not suitable for the stateless Video process or it 
could make driver too fat.
   After talking to some kindness Intel guys and moving our userspace 
library to VA-API driver, I find the DRM may the good choice for us.
But I don't know whether it is welcome to to submit a video driver in 
DRM subsystem?
   Also our VPU(Video process unit) is not just like the Intel's, we 
don't have VCS, we based on registers to set the encoder/decoder. I 
think we may need a lots of IOCTL then. Also we do have a IOMMU in VPU 
but also not a isolated memory for VPU, I don't know I should use TT 
memory or GEM memory.
   I am actually not a member of the department in charge of VPU, and I 
am just beginning to learning DRM(thank the help from Intel again), I am 
not so good at memory part as well(I am more familiar with CMA not the 
IOMMU way), I may need know guide about the implementations when I am 
going to submit driver, I hope I could get help from someone.

-- 
Randy Li
The third produce department

[RFC] drm: implement generic firmware eviction

[David Herrmann]

Hi

On Fri, Aug 26, 2016 at 9:57 AM, Hans de Goede  wrote:
> Hi,
>
> On 26-08-16 02:00, David Herrmann wrote:
>>
>> Provide a generic DRM helper that evicts all conflicting firmware
>> framebuffers, devices, and drivers. The new helper is called
>> drm_evict_firmware(), and takes a flagset controlling which firmware to
>> kick out.
>>
>> This is meant to be used by drivers in their ->probe() callbacks of their
>> parent bus, before calling into drm_dev_register().
>>
>> Signed-off-by: David Herrmann 
>> ---
>> Hey
>>
>> This is just compile-tested for now. I just want to get some comments on
>> the
>> design. I decided to drop the sysfb infrastructure and rather just use
>> this
>> generic helper. It keeps things simple and should work just fine for all
>> reasonable use-cases.
>>
>> This will work with SimpleDRM out-of-the-box on x86.
>>
>> Architectures with dynamic simple-framebuffer devices are not supported
>> yet. I
>> actually have no idea what the strategy there is? Can the DeviceTree
>> people come
>> up with something? Am I supposed to call of_platform_depopulate()? Or
>> of_detach_node()? Or what?
>
>
> I'm not sure we would want to remove the device at all, we certainly should
> not
> be removing the dt_node from the devicetree IMHO. Having that around to see
> how
> the bootloader set things up is really useful for debugging and normally we
> should never modify the devicetree as set up by the bootloader.
>
> Why not just unbind the driver from the platform device? That should be
> enough.

That will leave IORESOURCE_MEM around, causing conflicts if
re-used/claimed by other devices/drivers. Furthermore, it is really
fragile leaving the device around, without any control over possible
future driver probing.

Thanks
David

[RFC] drm: implement generic firmware eviction

[Hans de Goede]

Hi,

On 26-08-16 02:00, David Herrmann wrote:
> Provide a generic DRM helper that evicts all conflicting firmware
> framebuffers, devices, and drivers. The new helper is called
> drm_evict_firmware(), and takes a flagset controlling which firmware to
> kick out.
>
> This is meant to be used by drivers in their ->probe() callbacks of their
> parent bus, before calling into drm_dev_register().
>
> Signed-off-by: David Herrmann 
> ---
> Hey
>
> This is just compile-tested for now. I just want to get some comments on the
> design. I decided to drop the sysfb infrastructure and rather just use this
> generic helper. It keeps things simple and should work just fine for all
> reasonable use-cases.
>
> This will work with SimpleDRM out-of-the-box on x86.
>
> Architectures with dynamic simple-framebuffer devices are not supported yet. I
> actually have no idea what the strategy there is? Can the DeviceTree people 
> come
> up with something? Am I supposed to call of_platform_depopulate()? Or
> of_detach_node()? Or what?

I'm not sure we would want to remove the device at all, we certainly should not
be removing the dt_node from the devicetree IMHO. Having that around to see how
the bootloader set things up is really useful for debugging and normally we
should never modify the devicetree as set up by the bootloader.

Why not just unbind the driver from the platform device? That should be enough.

Regards,

Hans




> Looking at drivers/of/{platform,dynamic}.c, I cannot see how this is supposed 
> to
> work at all. Who protects platform_device_del() from being called in parallel?
> Also: Does any platform make use the of 'display:' entry in 
> 'simple-framebuffer'
> DT nodes? If yes, how do I get access to it? And why don't vc4/sun4i make use 
> of
> it, rather than falling back to remove_conflicting_framebuffers()?
>
> Thanks
> David
>
>  drivers/gpu/drm/drm_drv.c | 257 
> ++
>  include/drm/drmP.h|  13 +++
>  2 files changed, 270 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 0773547..581c342 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -26,12 +26,16 @@
>   * DEALINGS IN THE SOFTWARE.
>   */
>
> +#include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
> +#include 
>  #include 
>  #include "drm_crtc_internal.h"
>  #include "drm_legacy.h"
> @@ -881,6 +885,259 @@ void drm_dev_unregister(struct drm_device *dev)
>  }
>  EXPORT_SYMBOL(drm_dev_unregister);
>
> +struct drm_evict_ctx {
> + struct apertures_struct *ap;
> + unsigned int flags;
> +};
> +
> +static bool drm_evict_match_resource(struct drm_evict_ctx *ctx,
> +  struct resource *mem)
> +{
> + struct aperture *g;
> + unsigned int i;
> +
> + for (i = 0; i < ctx->ap->count; ++i) {
> + g = >ap->ranges[i];
> +
> + if (mem->start == g->base)
> + return true;
> + if (mem->start >= g->base && mem->end < g->base + g->size)
> + return true;
> + if ((ctx->flags & DRM_EVICT_VBE) && mem->start == 0xA)
> + return true;
> + }
> +
> + return false;
> +}
> +
> +static int drm_evict_platform_device(struct device *dev, void *userdata)
> +{
> + struct drm_evict_ctx *ctx = userdata;
> + struct platform_device *pdev = to_platform_device(dev);
> + struct resource *mem;
> +
> + /*
> +  * We are only interested in static devices here (i.e., they carry
> +  * information via a statically allocated platform data field). Any
> +  * dynamically allocated devices have separate ownership models and
> +  * must be handled via their respective management calls.
> +  */
> + if (!dev_get_platdata(>dev))
> + return 0;
> + if (!pdev->name)
> + return 0;
> +
> + if (!strcmp(pdev->name, "simple-framebuffer")) {
> + mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!mem)
> + return 0;
> + if (!drm_evict_match_resource(ctx, mem))
> + return 0;
> +
> + platform_device_del(pdev);
> + }
> +
> + return 0;
> +}
> +
> +static int drm_evict_platform(struct drm_evict_ctx *ctx)
> +{
> + /*
> +  * Early-boot architecture setup and boot-loarders sometimes create
> +  * preliminary platform devices with a generic framebuffer setup. This
> +  * allows graphics access during boot-up, without a real graphics
> +  * driver loaded. However, once a real graphics driver takes over, we
> +  * have to destroy those platform devices. In the legacy fbdev case, we
> +  * just used to unload the fbdev driver. However, to make sure any kind
> +  * of driver is unloaded, the platform-eviction code here simply
> +  * removes any conflicting platform device 

[PATCH 2/2] drm/hisilicon: Make it compile again

[Xinliang Liu]

On 17 August 2016 at 19:11, Daniel Vetter  wrote:
> On Wed, Aug 17, 2016 at 07:02:01PM +0800, Xinliang Liu wrote:
>> Hi,
>>
>> On 17 August 2016 at 18:17, Daniel Vetter  wrote:
>> > I just broke the build :(
>> >
>> > Note that the cleanup function is a bit confused: ade_data was never
>> > set as drvdata, and calling drm_crtc_cleanup directly is a bug - this
>>
>> Yes, this is a bug. Thanks for pointing out this.
>>
>> > is called indirectly through drm_mode_config_cleanup, which calls into
>> > crtc->destroy, which already has the call to drm_crtc_cleanup. Which
>> > means we can just nuke it.
>> >
>> > Aside: I have no idea why this driver depends upon ARM64. It doesn't
>> > build warning-free on 32bit, but otherwise it's perfectly fine.
>>
>> Because this driver is written for ARM64 SoCs.
>
> It makes compile-testing harder, the same reasons why depending upon

What compile-testing we will have? I just try to understand the problem.

Thanks,
-xinliang

> specific arm platforms is really annoying (but lukily that problem seems
> to have stopped being one for the drm subsystem at least). Depending on
> CONFIG_OF and other stuff that's really needed is perfectly fine, but imo
> depending upon specific platforms and stuff really isn't.
> -Daniel
>
>>
>> Thanks,
>> -xinliang
>>
>> >
>> > Cc: Xinliang Liu 
>> > Cc: Xinwei Kong 
>> > Cc: Chen Feng 
>> > Cc: Sean Paul 
>> > Fixes: d25bcfb8c2e1 ("drm/hisilicon: Don't set drm_device->platformdev")
>> > Signed-off-by: Daniel Vetter 
>> > ---
>> >  drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 9 ++---
>> >  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 4 ++--
>> >  2 files changed, 4 insertions(+), 9 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c 
>> > b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
>> > index 91188f33b1d9..c64c82cb7e71 100644
>> > --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
>> > +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
>> > @@ -991,7 +991,7 @@ static int ade_dts_parse(struct platform_device *pdev, 
>> > struct ade_hw_ctx *ctx)
>> >
>> >  static int ade_drm_init(struct platform_device *pdev)
>> >  {
>> > -   struct drm_device *drm_dev = platform_get_drvdata(dev);
>> > +   struct drm_device *dev = platform_get_drvdata(pdev);
>> > struct ade_data *ade;
>> > struct ade_hw_ctx *ctx;
>> > struct ade_crtc *acrtc;
>> > @@ -1052,14 +1052,9 @@ static int ade_drm_init(struct platform_device 
>> > *pdev)
>> >
>> >  static void ade_drm_cleanup(struct platform_device *pdev)
>> >  {
>> > -   struct drm_device *drm_dev = platform_get_drvdata(dev);
>> > -   struct ade_data *ade = platform_get_drvdata(pdev);
>> > -   struct drm_crtc *crtc = >acrtc.base;
>> > -
>> > -   drm_crtc_cleanup(crtc);
>> >  }
>> >
>> >  const struct kirin_dc_ops ade_dc_ops = {
>> > .init = ade_drm_init,
>> > .cleanup = ade_drm_cleanup
>> > -;
>> > +};
>> > diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c 
>> > b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
>> > index 6b0f9f6c16e1..b9b8c25da5e3 100644
>> > --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
>> > +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
>> > @@ -103,7 +103,7 @@ static int kirin_drm_kms_init(struct drm_device *dev)
>> > kirin_drm_mode_config_init(dev);
>> >
>> > /* display controller init */
>> > -   ret = dc_ops->init(to_platform_device(dev));
>> > +   ret = dc_ops->init(to_platform_device(dev->dev));
>> > if (ret)
>> > goto err_mode_config_cleanup;
>> >
>> > @@ -137,7 +137,7 @@ static int kirin_drm_kms_init(struct drm_device *dev)
>> >  err_unbind_all:
>> > component_unbind_all(dev->dev, dev);
>> >  err_dc_cleanup:
>> > -   dc_ops->cleanup(dev);
>> > +   dc_ops->cleanup(to_platform_device(dev->dev));
>> >  err_mode_config_cleanup:
>> > drm_mode_config_cleanup(dev);
>> > devm_kfree(dev->dev, priv);
>> > --
>> > 2.8.1
>> >
>> > ___
>> > 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

Skylake graphics regression: projector failure with 4.8-rc3

[James Bottomley]

On Fri, 2016-08-26 at 09:10 -0400, James Bottomley wrote:
> We seem to have an xrandr regression with skylake now.  What's
> happening is that I can get output on to a projector, but the system 
> is losing video when I change the xrandr sessions (like going from a 
> --above b to a --same-as b).  The main screen goes blank, which is
> basically a reboot situation.  Unfortunately, I can't seem to get the
> logs out of systemd to see if there was a dump to dmesg (the system 
> was definitely responding).
> 
> I fell back to 4.6.2 which worked perfectly, so this is definitely 
> some sort of regression.  I'll be able to debug more fully when I get 
> back home from the Linux Security Summit.

Sorry, ignore the logs: they're from a previous bug; as I said I'll try
to gather logs when I get back to a more controlled environment over
the weekend.

James

Skylake graphics regression: projector failure with 4.8-rc3

[James Bottomley]

We seem to have an xrandr regression with skylake now.  What's
happening is that I can get output on to a projector, but the system is
losing video when I change the xrandr sessions (like going from a -
-above b to a --same-as b).  The main screen goes blank, which is
basically a reboot situation.  Unfortunately, I can't seem to get the
logs out of systemd to see if there was a dump to dmesg (the system was
definitely responding).

I fell back to 4.6.2 which worked perfectly, so this is definitely some
sort of regression.  I'll be able to debug more fully when I get back
home from the Linux Security Summit.

James
-- next part --
A non-text attachment was scrubbed...
Name: Xorg.0.log
Type: text/x-log
Size: 27983 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160826/0eaf894a/attachment-0001.bin>
-- next part --
[0.00] Linux version 4.7.0-rc1+ (jejb at jarvis) (gcc version 4.8.5 
(SUSE Linux) ) #1 SMP PREEMPT Mon May 30 12:29:53 PDT 2016
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-test 
root=UUID=994363fd-c12c-4c6c-92e9-85e8ac695cf9 ro resume=/dev/nvme0n1p2 
splash=silent quiet showopts pcie_aspm=force
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: xstate_offset[3]:  960, xstate_sizes[3]:   64
[0.00] x86/fpu: xstate_offset[4]: 1024, xstate_sizes[4]:   64
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'
[0.00] x86/fpu: Enabled xstate features 0x1f, context size is 1088 
bytes, using 'standard' format.
[0.00] x86/fpu: Using 'eager' FPU context switches.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0fff] reserved
[0.00] BIOS-e820: [mem 0x1000-0x00057fff] usable
[0.00] BIOS-e820: [mem 0x00058000-0x00058fff] reserved
[0.00] BIOS-e820: [mem 0x00059000-0x0009cfff] usable
[0.00] BIOS-e820: [mem 0x0009d000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x0010-0x69537fff] usable
[0.00] BIOS-e820: [mem 0x69538000-0x69538fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x69539000-0x69562fff] reserved
[0.00] BIOS-e820: [mem 0x69563000-0x695bdfff] usable
[0.00] BIOS-e820: [mem 0x695be000-0x69daefff] reserved
[0.00] BIOS-e820: [mem 0x69daf000-0x7907dfff] usable
[0.00] BIOS-e820: [mem 0x7907e000-0x793f8fff] reserved
[0.00] BIOS-e820: [mem 0x793f9000-0x79448fff] ACPI data
[0.00] BIOS-e820: [mem 0x79449000-0x79c00fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x79c01000-0x7a4fefff] reserved
[0.00] BIOS-e820: [mem 0x7a4ff000-0x7a4f] usable
[0.00] BIOS-e820: [mem 0x7a50-0x7a5f] reserved
[0.00] BIOS-e820: [mem 0xe000-0xefff] reserved
[0.00] BIOS-e820: [mem 0xfe00-0xfe010fff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00027eff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] e820: update [mem 0x67823018-0x67833057] usable ==> usable
[0.00] extended physical RAM map:
[0.00] reserve setup_data: [mem 0x-0x0fff] 
reserved
[0.00] reserve setup_data: [mem 0x1000-0x00057fff] 
usable
[0.00] reserve setup_data: [mem 0x00058000-0x00058fff] 
reserved
[0.00] reserve setup_data: [mem 0x00059000-0x0009cfff] 
usable
[0.00] reserve setup_data: [mem 0x0009d000-0x0009] 
reserved
[0.00] reserve setup_data: [mem 0x0010-0x67823017] 
usable
[0.00] reserve setup_data: [mem 0x67823018-0x67833057] 
usable
[0.00] reserve setup_data: [mem 0x67833058-0x69537fff] 
usable
[0.00] reserve setup_data: [mem 0x69538000-0x69538fff] 
ACPI NVS
[0.00] reserve setup_data: [mem 0x69539000-0x69562fff] 
reserved
[0.00] reserve setup_data: [mem 0x69563000-0x695bdfff] 
usable
[   

[PATCH 3/9] drm: Extract drm_mode_object.[hc]

[Archit Taneja]

On 08/26/2016 01:10 AM, Daniel Vetter wrote:
> On Thu, Aug 25, 2016 at 05:55:18PM +0530, Archit Taneja wrote:
>> On 08/18/2016 02:26 AM, Daniel Vetter wrote:
>>> +void drm_mode_object_unregister(struct drm_device *dev,
>>> +   struct drm_mode_object *object);
>>
>> Alignment issue in the declaration here.
>
> Again I don't like touching code when moving it. I guess I'll squash all
> your suggestions into the polish patches.

Sure, that seems like a better idea.

Archit

> -Daneil
>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v10 3/3] drm/panel: Add JDI LT070ME05000 WUXGA DSI Panel

[Vinay Simha BN]

Add support for the JDI LT070ME05000 WUXGA DSI panel used in
Nexus 7 2013 devices.

Programming sequence for the panel is was originally found in the
android-msm-flo-3.4-lollipop-release branch from:
https://android.googlesource.com/kernel/msm.git

And video mode setting is from dsi-panel-jdi-dualmipi1-video.dtsi
file in:
git://codeaurora.org/kernel/msm-3.10.git  LNX.LA.3.6_rb1.27

Cc: Archit Taneja 
Cc: Rob Clark 
Cc: Sumit Semwal 
Cc: John Stultz 
Cc: Emil Velikov 
Cc: Thierry Reding 
Cc: David Airlie 
Signed-off-by: Sumit Semwal 
Signed-off-by: John Stultz 
Signed-off-by: Vinay Simha BN 
Tested-by: John Stultz 
Reviewed-by: Emil Velikov 

---
v1:
 * sumit ported to drm/panel framework, john cherry-picked to mainline,
   folded down other fixes from Vinay and Archit, vinay removed interface
   setting cmd mode, video mode panel selected

v2:
 * incorporated code reviews from theiry, archit
   code style, alphabetical soring in Makefile, Kconfig, regulator_bulk,
   arrays of u8, generic helper function, documentation bindings,

v3:
 * dcs backlight support added
 * tested this panel driver in nexus7 2013 device

v4:
 * backlight interface added in the panel driver
 * incorporated width_mm and height_mm suggested by rob herring

v5:
 * theirry review comments incorporated
   panel model naming consistent, alphabetical soring in Kconfig
   Makefile, MAX_BRIGHTNESS dropped, regulator_names, parameterize
   panel width and height, descprition for control display, cabc
   and interface setting, temporary variable removed, consistent
   error reporting and commit message
 * removed tear on/off, scanline, since these are required only
   for command mode panels

v6:
 * emil review comments incorporated
   PANEL_NUM_REGULATORS dropped, return ret added at necessary
   places, if checks dropped for backlight and gpios

v7:
 * emil review comments incorporated
   added ARRAY_SIZE in struct, regulator_bulk_disable in poweroff,
   gpios checks dropped.
   some returns cannot be dropped, since drm panel framework return
   type required.

v8:
 * emil review commnets incorporated for jdi_panel_unprepare,
   dropped the returns (ref: panel-sharp-lq101r1sx01.c) and
   for jdi_panel_prepare(panel_on) it does not return prematurely
   and goes to poweroff if not success
 * few dev_err's for panel_init

v9:
 * function drm_panel_create_dsi_backlight made as static

v10:
 * proper naming conventions and sequence wrt panel datasheet
   (vddp-supply, iovcc-supply,
enable-gpios, reset-gpios, dcdc-en-gpios)
 * GPIO_ACTIVE_LOW polarity logic for reset-gpios
---
 drivers/gpu/drm/panel/Kconfig  |  11 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-jdi-lt070me05000.c | 532 +
 3 files changed, 544 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-jdi-lt070me05000.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 1500ab9..62aba97 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -18,6 +18,17 @@ config DRM_PANEL_SIMPLE
  that it can be automatically turned off when the panel goes into a
  low power state.

+config DRM_PANEL_JDI_LT070ME05000
+   tristate "JDI LT070ME05000 WUXGA DSI panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y here if you want to enable support for JDI DSI video mode
+ panel as found in Google Nexus 7 (2013) devices.
+ The panel has a 1200(RGB)×1920 (WUXGA) resolution and uses
+ 24 bit per pixel.
+
 config DRM_PANEL_SAMSUNG_LD9040
tristate "Samsung LD9040 RGB/SPI panel"
depends on OF && SPI
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index f277eed..a5c7ec0 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,4 +1,5 @@
 obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
+obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
 obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
 obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
panel-panasonic-vvx10f034n00.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
diff --git a/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c 
b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
new file mode 100644
index 000..5b2340e
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
@@ -0,0 +1,532 @@
+/*
+ * Copyright (C) 2016 InforceComputing
+ * Author: Vinay Simha BN 
+ *
+ * Copyright (C) 2016 Linaro Ltd
+ * Author: Sumit Semwal 
+ *
+ * From internet archives, the panel for Nexus 7 2nd Gen, 2013 model is a
+ * JDI model LT070ME05000, and its data sheet is at:
+ * http://panelone.net/en/7-0-inch/JDI_LT070ME05000_7.0_inch-datasheet
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License 

[PATCH v3 2/3] dt-bindings: Add jdi lt070me05000 panel bindings

[Vinay Simha BN]

Add documentation for lt070me05000 panel

Cc: Archit Taneja 
Cc: John Stultz 
Cc: Thierry Reding 
Cc: Sumit Semwal 
Signed-off-by: Vinay Simha BN 
Acked-by: Rob Herring 

---
v2:
 * incorporated rob herring and thierry reviews
   gpio to gpios, gpio to regulator using fixed regulators
   and pwm backlight is removed, since it is controlled by
   dcs commands

v3:
 * incorporated thierry reviews
   - Added gpio polarity details for reset-gpios
   - proper naming conventions and sequence wrt panel datasheet
 (vddp-supply, iovcc-supply,
  enable-gpios, reset-gpios, dcdc-en-gpios)
---
 .../bindings/display/panel/jdi,lt070me05000.txt| 33 ++
 1 file changed, 33 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt 
b/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
new file mode 100644
index 000..4724952
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
@@ -0,0 +1,33 @@
+JDI model LT070ME05000 1200x1920 7" DSI Panel
+
+Required properties:
+- compatible: should be "jdi,lt070me05000"
+- vddp-supply: phandle of the regulator that provides the supply voltage
+  Power IC supply (3-5V)
+- iovcc-supply: phandle of the regulator that provides the supply voltage
+  IOVCC , power supply for LCM (1.8V)
+- enable-gpios: phandle of gpio for enable line
+  LED_EN, LED backlight enable, High active
+- reset-gpios: phandle of gpio for reset line
+  This should be 8mA, gpio can be configured using mux, pinctrl, pinctrl-names
+  XRES, Reset, Low active
+- dcdc-en-gpios: phandle of the gpio for power ic line
+  Power IC supply enable, High active
+
+Example:
+
+   dsi0: qcom,mdss_dsi at 470 {
+   panel at 0 {
+   compatible = "jdi,lt070me05000";
+   reg = <0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_panel_pinctrl>;
+
+   vddp-supply = <_l17>;
+   iovcc-supply = <_lvs7>;
+
+   enable-gpios = <_gpio 36 GPIO_ACTIVE_HIGH>;
+   reset-gpios = <_pinmux 54 GPIO_ACTIVE_LOW>;
+   dcdc-en-gpios = <_gpio 23 GPIO_ACTIVE_HIGH>;
+   };
+   };
-- 
2.1.2