Re: [RFC 0/4] Exynos DRM: add Picture Processor extension

[Tomasz Figa]

Hi Everyone,

On Wed, May 10, 2017 at 9:24 AM, Inki Dae  wrote:
>
>
> 2017년 04월 26일 07:21에 Sakari Ailus 이(가) 쓴 글:
>> Hi Marek,
>>
>> On Thu, Apr 20, 2017 at 01:23:09PM +0200, Marek Szyprowski wrote:
>>> Hi Laurent,
>>>
>>> On 2017-04-20 12:25, Laurent Pinchart wrote:
 Hi Marek,

 (CC'ing Sakari Ailus)

 Thank you for the patches.

 On Thursday 20 Apr 2017 11:13:36 Marek Szyprowski wrote:
> Dear all,
>
> This is an updated proposal for extending EXYNOS DRM API with generic
> support for hardware modules, which can be used for processing image data
 >from the one memory buffer to another. Typical memory-to-memory operations
> are: rotation, scaling, colour space conversion or mix of them. This is a
> follow-up of my previous proposal "[RFC 0/2] New feature: Framebuffer
> processors", which has been rejected as "not really needed in the DRM
> core":
> http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg146286.html
>
> In this proposal I moved all the code to Exynos DRM driver, so now this
> will be specific only to Exynos DRM. I've also changed the name from
> framebuffer processor (fbproc) to picture processor (pp) to avoid 
> confusion
> with fbdev API.
>
> Here is a bit more information what picture processors are:
>
> Embedded SoCs are known to have a number of hardware blocks, which perform
> such operations. They can be used in paralel to the main GPU module to
> offload CPU from processing grapics or video data. One of example use of
> such modules is implementing video overlay, which usually requires color
> space conversion from NV12 (or similar) to RGB32 color space and scaling 
> to
> target window size.
>
> The proposed API is heavily inspired by atomic KMS approach - it is also
> based on DRM objects and their properties. A new DRM object is introduced:
> picture processor (called pp for convenience). Such objects have a set of
> standard DRM properties, which describes the operation to be performed by
> respective hardware module. In typical case those properties are a source
> fb id and rectangle (x, y, width, height) and destination fb id and
> rectangle. Optionally a rotation property can be also specified if
> supported by the given hardware. To perform an operation on image data,
> userspace provides a set of properties and their values for given fbproc
> object in a similar way as object and properties are provided for
> performing atomic page flip / mode setting.
>
> The proposed API consists of the 3 new ioctls:
> - DRM_IOCTL_EXYNOS_PP_GET_RESOURCES: to enumerate all available picture
>   processors,
> - DRM_IOCTL_EXYNOS_PP_GET: to query capabilities of given picture
>   processor,
> - DRM_IOCTL_EXYNOS_PP_COMMIT: to perform operation described by given
>   property set.
>
> The proposed API is extensible. Drivers can attach their own, custom
> properties to add support for more advanced picture processing (for 
> example
> blending).
>
> This proposal aims to replace Exynos DRM IPP (Image Post Processing)
> subsystem. IPP API is over-engineered in general, but not really 
> extensible
> on the other side. It is also buggy, with significant design flaws - the
> biggest issue is the fact that the API covers memory-2-memory picture
> operations together with CRTC writeback and duplicating features, which
> belongs to video plane. Comparing with IPP subsystem, the PP framework is
> smaller (1807 vs 778 lines) and allows driver simplification (Exynos
> rotator driver smaller by over 200 lines).
 This seems to be the kind of hardware that is typically supported by V4L2.
 Stupid question, why DRM ?
>>>
>>> Let me elaborate a bit on the reasons for implementing it in Exynos DRM:
>>>
>>> 1. we want to replace existing Exynos IPP subsystem:
>>>  - it is used only in some internal/vendor trees, not in open-source
>>>  - we want it to have sane and potentially extensible userspace API
>>>  - but we don't want to loose its functionality
>>>
>>> 2. we want to have simple API for performing single image processing
>>> operation:
>>>  - typically it will be used by compositing window manager, this means that
>>>some parameters of the processing might change on each vblank (like
>>>destination rectangle for example). This api allows such change on each
>>>operation without any additional cost. V4L2 requires to reinitialize
>>>queues with new configuration on such change, what means that a bunch of
>>>ioctls has to be called.
>>
>> What do you mean by re-initialising the queue? Format, buffers or something
>> else?
>>
>> If you need a larger buffer than what you have already allocated, you'll
>> need to re-allocate, V4L2 or not.
>>
>> We also do lack a way to destroy individual 

[Bug 100984] QupZilla crashes at startup after mesa upgrade

[bugzilla-daemon]

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

--- Comment #2 from Francesco Turco  ---
Created attachment 131291
  --> https://bugs.freedesktop.org/attachment.cgi?id=131291=edit
gdb backtrace (full version)

I used the "thread apply all bt full" gdb command.

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

[Bug 100984] QupZilla crashes at startup after mesa upgrade

[bugzilla-daemon]

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

--- Comment #1 from Francesco Turco  ---
Created attachment 131290
  --> https://bugs.freedesktop.org/attachment.cgi?id=131290=edit
gdb backtrace (basic version)

I used the "bt" gdb command.

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

[Bug 100984] QupZilla crashes at startup after mesa upgrade

[bugzilla-daemon]

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

Bug ID: 100984
   Summary: QupZilla crashes at startup after mesa upgrade
   Product: Mesa
   Version: 17.1
  Hardware: x86-64 (AMD64)
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/i915
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: ftu...@fastmail.fm
QA Contact: dri-devel@lists.freedesktop.org

Since I upgraded media-libs/mesa from version 17.0.4 to version 17.1.0_rc4 I
cannot start QupZilla anymore because it produces a segmentation fault. I have
an Intel GPU (Q35 chipset). My GNU/Linux distribution is Gentoo.

# lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation 82Q35 Express Integrated
Graphics Controller (rev 02)

# emerge -pv qupzilla mesa

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R] www-client/qupzilla-2.1.2::gentoo  USE="dbus -debug
-gnome-keyring -kwallet -libressl -nonblockdialogs" LINGUAS="-ar_SA -bg_BG
-ca_ES -cs_CZ -da_DK -de_DE -el_GR -es_ES -es_MX -es_VE -eu_ES -fa_IR -fi_FI
-fr_FR -gl_ES -he_IL -hr_HR -hu_HU -id_ID -is -it_IT -ja_JP -ka_GE -lg -lt
-lv_LV -nl_NL -nqo -pl_PL -pt_BR -pt_PT -ro_RO -ru_RU -sk_SK -sr -sr@ijekavian
-sr@ijekavianlatin -sr@latin -sv_SE -tr_TR -uk_UA -uz@Latn -zh_CN -zh_HK
-zh_TW" 2,703 KiB
[ebuild   R] media-libs/mesa-17.1.0_rc4::gentoo  USE="classic debug dri3
egl gallium gbm nptl -bindist -d3d9 -gles1 -gles2 -llvm -opencl -openmax
-osmesa -pax_kernel -pic (-selinux) -vaapi -valgrind -vdpau -vulkan -wayland
-xa -xvmc" VIDEO_CARDS="i915 intel (-freedreno) -i965 -imx -nouveau -r100 -r200
-r300 -r600 -radeon -radeonsi (-vc4) (-vivante) -vmware" 0 KiB

Total: 2 packages (2 reinstalls), Size of downloads: 2,703 KiB

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

[Bug 100983] qupzilla

[bugzilla-daemon]

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

Francesco Turco  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

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

Re: [PATCH 03/11] drm: parse ycbcr 420 vdb block

[Sharma, Shashank]

Regards

Shashank


On 5/9/2017 8:58 PM, Ville Syrjälä wrote:

On Tue, May 09, 2017 at 02:04:55PM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 5/8/2017 10:39 PM, Ville Syrjälä wrote:

On Mon, May 08, 2017 at 10:11:53PM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 5/8/2017 9:54 PM, Ville Syrjälä wrote:

On Fri, Apr 07, 2017 at 07:39:20PM +0300, Shashank Sharma wrote:

From: Jose Abreu 

HDMI 2.0 spec adds support for ycbcr420 subsampled output.
CEA-861-F adds two new blocks in EDID, to provide information about
sink's support for ycbcr420 output.

These new blocks are:
- ycbcr420 video data (vdb) block: video modes which can be supported
 only in ycbcr420 output mode.
- ycbcr420 video capability data (vcb) block: video modes which can be
 support in ycbcr420 output mode also (along with RGB, YCBCR 444/422 etc)

This patch adds parsing and handling of ycbcr420-vdb in the DRM
layer.

This patch is a modified version of Jose's RFC patch:
https://patchwork.kernel.org/patch/9492327/
so the authorship is maintained.

Cc: Ville Syrjala 
Signed-off-by: Jose Abreu 
Signed-off-by: Shashank Sharma 
---
drivers/gpu/drm/drm_edid.c  | 54 
+++--
drivers/gpu/drm/drm_modes.c | 10 +++--
include/drm/drm_connector.h |  1 +
include/uapi/drm/drm_mode.h |  6 +
4 files changed, 67 insertions(+), 4 deletions(-)



diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 4eeda12..cef76b2 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -199,6 +199,7 @@ struct drm_display_info {
#define DRM_COLOR_FORMAT_RGB444 (1<<0)
#define DRM_COLOR_FORMAT_YCRCB444   (1<<1)
#define DRM_COLOR_FORMAT_YCRCB422   (1<<2)
+#define DRM_COLOR_FORMAT_YCRCB420  (1<<2)

	/**

 * @color_formats: HDMI Color formats, selects between RGB and YCrCb
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 8c67fc0..1e74d8e 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -84,6 +84,12 @@ extern "C" {
#define  DRM_MODE_FLAG_3D_L_DEPTH_GFX_GFX_DEPTH (6<<14)
#define  DRM_MODE_FLAG_3D_TOP_AND_BOTTOM(7<<14)
#define  DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF (8<<14)
+/*
+ * HDMI 2.0
+ */
+#define DRM_MODE_FLAG_420_MASK (0x03<<23)
+#define  DRM_MODE_FLAG_420 (1<<23)
+#define  DRM_MODE_FLAG_420_ONLY(1<<24)

Adding those would again break the uabi. We can't add new mode flags
without some kind of client cap.
But I think we agreed that new user
space visible mode flags aren't needed, and instad we can keep it all
internal?

Yep you are right, we had decided to keep it internal, and this whole
patch series is implemented in such a way only, to control everything
through the HDMI output property itself.
But may be I slightly misunderstood that we shouldn't add the flags bits
all together, and I added this flag to differentiate between YCBCR420
and notmal modes.
Can you please suggest me on:
- how to differentiate a YCBCR420 mode with normal mode ? I still need
to add a flag, but not expose it into uapi layer.

I guess we can just tack on a few new bools to the end of
drm_display_mode. And then when we get the mode passed in by the user
we'll have to check whether that mode matches any CEA mode and
then look up the correct YCbCr 4:2:0 mode for it.

seems good to me, I can add a is_ycbcr420 flag, and we need not to
bother about converting it to drm_mode_modeinfo as we are keeping it
internal.

Hmm. Actually, that probably means that it isn't sufficient to
actually store this information on the modes we have on the connector's
mode list, because that list has been filtered and so may not actually
have all the modes that were declared in the EDID.

I dint get this point,  Why do you think its not sufficient ? Do we need
to care about the modes which are getting rejected from the driver ?

Yes, that was my worry. In general I don't think connector->modes should
ever be used for mode validation or state computation. Eg. if fbdev
handled the previus hotplug connector->modes will have been filtered
based on the size of the fb_helper framebuffer, and then a new master
might just blindly come in and blindly set a new mode without doing a
full connector probe.
Its very valid point when it comes to resolution, but do you think fbdev 
will reject based on the flags (YCBCR420_only/also) .
I mean if I add YCBCR420 info as bools (like in your previous 
suggestion), would that alter fbdev selection ?
Nevertheless, a YCBCR420 bitmap seems to be a good idea already, just as 
soon as we can map it clearly with the hdmi_output property.

I guess they cant be applied anyways.  Do you think we will miss some of
the YCBCR modes due to mode filtering ?

So I'm thinking we
should perhaps make 

[PATCH] drm: mediatek: change the variable type of rdma threshold

[Bibby Hsieh]

For some greater resolution, the rdma threshold
variable will overflow.

Signed-off-by: Bibby Hsieh 
---
 drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c 
b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index 0df05f9..2718413 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -109,7 +109,7 @@ static void mtk_rdma_config(struct mtk_ddp_comp *comp, 
unsigned int width,
unsigned int height, unsigned int vrefresh,
unsigned int bpc)
 {
-   unsigned int threshold;
+   unsigned long long threshold;
unsigned int reg;
 
rdma_update_bits(comp, DISP_REG_RDMA_SIZE_CON_0, 0xfff, width);
@@ -121,10 +121,11 @@ static void mtk_rdma_config(struct mtk_ddp_comp *comp, 
unsigned int width,
 * output threshold to 6 microseconds with 7/6 overhead to
 * account for blanking, and with a pixel depth of 4 bytes:
 */
-   threshold = width * height * vrefresh * 4 * 7 / 100;
+   threshold = (unsigned long long)width * height * vrefresh *
+   4 * 7 / 100;
reg = RDMA_FIFO_UNDERFLOW_EN |
  RDMA_FIFO_PSEUDO_SIZE(SZ_8K) |
- RDMA_OUTPUT_VALID_FIFO_THRESHOLD(threshold);
+ (unsigned int)RDMA_OUTPUT_VALID_FIFO_THRESHOLD(threshold);
writel(reg, comp->regs + DISP_REG_RDMA_FIFO_CON);
 }
 
-- 
1.9.1

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

Re: [RFC 0/4] Exynos DRM: add Picture Processor extension

[Inki Dae]

2017년 04월 26일 07:21에 Sakari Ailus 이(가) 쓴 글:
> Hi Marek,
> 
> On Thu, Apr 20, 2017 at 01:23:09PM +0200, Marek Szyprowski wrote:
>> Hi Laurent,
>>
>> On 2017-04-20 12:25, Laurent Pinchart wrote:
>>> Hi Marek,
>>>
>>> (CC'ing Sakari Ailus)
>>>
>>> Thank you for the patches.
>>>
>>> On Thursday 20 Apr 2017 11:13:36 Marek Szyprowski wrote:
 Dear all,

 This is an updated proposal for extending EXYNOS DRM API with generic
 support for hardware modules, which can be used for processing image data
>>> >from the one memory buffer to another. Typical memory-to-memory operations
 are: rotation, scaling, colour space conversion or mix of them. This is a
 follow-up of my previous proposal "[RFC 0/2] New feature: Framebuffer
 processors", which has been rejected as "not really needed in the DRM
 core":
 http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg146286.html

 In this proposal I moved all the code to Exynos DRM driver, so now this
 will be specific only to Exynos DRM. I've also changed the name from
 framebuffer processor (fbproc) to picture processor (pp) to avoid confusion
 with fbdev API.

 Here is a bit more information what picture processors are:

 Embedded SoCs are known to have a number of hardware blocks, which perform
 such operations. They can be used in paralel to the main GPU module to
 offload CPU from processing grapics or video data. One of example use of
 such modules is implementing video overlay, which usually requires color
 space conversion from NV12 (or similar) to RGB32 color space and scaling to
 target window size.

 The proposed API is heavily inspired by atomic KMS approach - it is also
 based on DRM objects and their properties. A new DRM object is introduced:
 picture processor (called pp for convenience). Such objects have a set of
 standard DRM properties, which describes the operation to be performed by
 respective hardware module. In typical case those properties are a source
 fb id and rectangle (x, y, width, height) and destination fb id and
 rectangle. Optionally a rotation property can be also specified if
 supported by the given hardware. To perform an operation on image data,
 userspace provides a set of properties and their values for given fbproc
 object in a similar way as object and properties are provided for
 performing atomic page flip / mode setting.

 The proposed API consists of the 3 new ioctls:
 - DRM_IOCTL_EXYNOS_PP_GET_RESOURCES: to enumerate all available picture
   processors,
 - DRM_IOCTL_EXYNOS_PP_GET: to query capabilities of given picture
   processor,
 - DRM_IOCTL_EXYNOS_PP_COMMIT: to perform operation described by given
   property set.

 The proposed API is extensible. Drivers can attach their own, custom
 properties to add support for more advanced picture processing (for example
 blending).

 This proposal aims to replace Exynos DRM IPP (Image Post Processing)
 subsystem. IPP API is over-engineered in general, but not really extensible
 on the other side. It is also buggy, with significant design flaws - the
 biggest issue is the fact that the API covers memory-2-memory picture
 operations together with CRTC writeback and duplicating features, which
 belongs to video plane. Comparing with IPP subsystem, the PP framework is
 smaller (1807 vs 778 lines) and allows driver simplification (Exynos
 rotator driver smaller by over 200 lines).
>>> This seems to be the kind of hardware that is typically supported by V4L2.
>>> Stupid question, why DRM ?
>>
>> Let me elaborate a bit on the reasons for implementing it in Exynos DRM:
>>
>> 1. we want to replace existing Exynos IPP subsystem:
>>  - it is used only in some internal/vendor trees, not in open-source
>>  - we want it to have sane and potentially extensible userspace API
>>  - but we don't want to loose its functionality
>>
>> 2. we want to have simple API for performing single image processing
>> operation:
>>  - typically it will be used by compositing window manager, this means that
>>some parameters of the processing might change on each vblank (like
>>destination rectangle for example). This api allows such change on each
>>operation without any additional cost. V4L2 requires to reinitialize
>>queues with new configuration on such change, what means that a bunch of
>>ioctls has to be called.
> 
> What do you mean by re-initialising the queue? Format, buffers or something
> else?
> 
> If you need a larger buffer than what you have already allocated, you'll
> need to re-allocate, V4L2 or not.
> 
> We also do lack a way to destroy individual buffers in V4L2. It'd be up to
> implementing that and some work in videobuf2.
> 
> Another thing is that V4L2 is very stream oriented. For most devices that's
> fine as a lot of the parameters are not 

Re: [PATCH RESEND 3/4] drm/exynos: Merge pre/postclose hooks

[Inki Dae]

Hi Daniel,

2017년 05월 08일 17:26에 Daniel Vetter 이(가) 쓴 글:
> Again no apparent explanation for the split except hysterical raisins.
> Merging them also makes it a bit more obviuos what's going on wrt the
> runtime pm refdancing.

I had requested git-pull,
http://www.spinics.net/lists/dri-devel/msg139194.html

However, Dave had already closed the merge window at -rc6.

As I commented below, most of patches of exynos-drm-next are fixups and cleanup 
so I will request pull to -fixes.
http://www.spinics.net/lists/dri-devel/msg139214.html

Thanks,
Inki Dae

> 
> Cc: Inki Dae 
> Cc: Joonyoung Shim 
> Cc: Seung-Woo Kim 
> Cc: Kyungmin Park 
> Reviewed-by: Sean Paul 
> Reviewed-by: Liviu Dudau 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_drv.c | 8 +---
>  1 file changed, 1 insertion(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index 09d3c4c3c858..50294a7bd29d 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -82,14 +82,9 @@ static int exynos_drm_open(struct drm_device *dev, struct 
> drm_file *file)
>   return ret;
>  }
>  
> -static void exynos_drm_preclose(struct drm_device *dev,
> - struct drm_file *file)
> -{
> - exynos_drm_subdrv_close(dev, file);
> -}
> -
>  static void exynos_drm_postclose(struct drm_device *dev, struct drm_file 
> *file)
>  {
> + exynos_drm_subdrv_close(dev, file);
>   kfree(file->driver_priv);
>   file->driver_priv = NULL;
>  }
> @@ -145,7 +140,6 @@ static struct drm_driver exynos_drm_driver = {
>   .driver_features= DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME
> | DRIVER_ATOMIC | DRIVER_RENDER,
>   .open   = exynos_drm_open,
> - .preclose   = exynos_drm_preclose,
>   .lastclose  = exynos_drm_lastclose,
>   .postclose  = exynos_drm_postclose,
>   .gem_free_object_unlocked = exynos_drm_gem_free_object,
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

[Dave Airlie]

>
> Just please make sure that one (user configurable/opt-in if necessary)
> policy from the beginning is to allow leasing out any output to
> applications, not just HMDs. My type of scientific/medical applications
> would benefit as soon as it has the option to get a drm lease for a given
> output on both X and Wayland based systems. That's not a theoretical future
> use case, but one i'd try to offer to my users as soon as a stable
> protocol/implementation is available in a regular Linux distribution. It
> wouldn't be fun for inexperienced users if they had to hack the database for
> every model of display they want to use, or if every untrusted user would
> have to have a root password to do so.
>

I think we need to restrict what outputs can be leased, but I might
just be paranoid,
maybe the is no security problem with having an app accessing an exclusive mode,
just makes me think of screensaver bypasses or something.

Do your apps need input? because if we lease out you won't be getting any input
from X and won't be able to open the input devices X has open.

VR is special since the input devices are all their own thing.

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

Re: [PATCH v3 4/5] drm: convert drivers to use drm_of_find_panel_or_bridge

[Leonard Crestez]

On Wed, Mar 22, 2017 at 5:01 PM, Philipp Zabel  wrote:
> On Wed, 2017-03-22 at 08:26 -0500, Rob Herring wrote:
> > 
> > Similar to the previous commit, convert drivers open coding OF graph
> > parsing to use drm_of_find_panel_or_bridge instead.
> > 
> > This changes some error messages to debug messages (in the graph core).
> > Graph connections are often "no connects" depending on the particular
> > board, so we want to avoid spurious messages. Plus the kernel is not a
> > DT validator.
> > 
> > Signed-off-by: Rob Herring 
> > Reviewed-by: Archit Taneja 
> Tested-by: Philipp Zabel 
> (imx-ldb on i.MX6)

It seems that this breaks on (at least) imx6qdl-sabreauto. The relevant
section of the boot log looks like this:

imx-drm display-subsystem: bound imx-ipuv3-crtc.2 (ops ipu_crtc_ops)
imx-drm display-subsystem: bound imx-ipuv3-crtc.3 (ops ipu_crtc_ops)
dwhdmi-imx 12.hdmi: Detected HDMI TX controller v1.31a with HDCP
(DWC HDMI 3D TX PHY)
dwhdmi-imx 12.hdmi: registered DesignWare HDMI I2C bus driver
imx-drm display-subsystem: bound 12.hdmi (ops dw_hdmi_imx_ops)
imx-drm display-subsystem: failed to bind 200.aips-bus:ldb (ops
imx_ldb_ops): -19
imx-drm display-subsystem: master bind failed: -19

It seems that imx6qdl-sabreauto does not have any panel defined in dts.
This used to be ignored when of_graph_get_endpoint_by_regs returned
NULL but now drm_of_find_panel_or_bridge returns -ENODEV and this
causes imx_ldb_bind to fail altogether. Defining a panel works
(including showing stuff on a LVDS panel). Ignoring -ENODEV also fixes
this:

--- drivers/gpu/drm/imx/imx-ldb.c
+++ drivers/gpu/drm/imx/imx-ldb.c
@@ -673,7 +673,7 @@ static int imx_ldb_bind(struct device *dev, struct device 
*master, void *data)
ret = drm_of_find_panel_or_bridge(child,
  imx_ldb->lvds_mux ? 4 : 2, 0,
  >panel, 
>bridge);
-   if (ret)
+   if (ret != -ENODEV)
return ret;
 
/* panel ddc only if there is no bridge */

I don't know much about drm and it's not clear if failing to find a
panel should be an error here or not and the hack above is likely the
wrong way to handle it anyway.

I was bisecting the fact that suspend now breaks on upstream. The fact
that a probe error later breaks suspend is possibly an unrelated issue,
right?

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

Re: [PATCH 0/3] GPU-DRM-Radeon: Fine-tuning for three function implementations

[Michel Dänzer]

On 03/05/17 09:46 PM, Christian König wrote:
> Am 02.05.2017 um 22:04 schrieb SF Markus Elfring:
>> From: Markus Elfring 
>> Date: Tue, 2 May 2017 22:00:02 +0200
>>
>> Three update suggestions were taken into account
>> from static source code analysis.
>>
>> Markus Elfring (3):
>>Use seq_putc() in radeon_sa_bo_dump_debug_info()
>>Use seq_puts() in radeon_debugfs_pm_info()
>>Use seq_puts() in r100_debugfs_cp_csq_fifo()
> 
> Reviewed-by: Christian König 

Based on
https://lists.freedesktop.org/archives/dri-devel/2017-May/140837.html
and followups, I'm afraid we'll have to make sure Markus' patches have
been tested adequately before applying them.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 8/8] drm: arc: Use crtc->mode_valid() callback

[Jose Abreu]

Now that we have a callback to check if crtc supports a given mode
we can use it in arcpgu so that we restrict the number of probbed
modes to the ones we can actually display.

This is specially useful because arcpgu crtc is responsible to set
a clock value in the commit() stage but unfortunatelly this clock
does not support all the needed ranges.

Also, remove the atomic_check() callback as mode_valid() callback
will be called before.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Alexey Brodkin 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Dave Airlie 
Cc: Andrzej Hajda 
Cc: Archit Taneja 
---
 drivers/gpu/drm/arc/arcpgu_crtc.c | 39 ---
 1 file changed, 24 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c 
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index ad9a959..01cae0a 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -32,6 +32,18 @@
{ "r8g8b8", 24, {16, 8}, {8, 8}, {0, 8}, {0, 0}, DRM_FORMAT_RGB888 },
 };
 
+static bool arc_pgu_is_mode_valid(struct arcpgu_drm_private *arcpgu,
+ const struct drm_display_mode *mode)
+{
+   long rate, clk_rate = mode->clock * 1000;
+
+   rate = clk_round_rate(arcpgu->clk, clk_rate);
+   if (rate != clk_rate)
+   return false;
+
+   return true;
+}
+
 static void arc_pgu_set_pxl_fmt(struct drm_crtc *crtc)
 {
struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
@@ -64,6 +76,17 @@ static void arc_pgu_set_pxl_fmt(struct drm_crtc *crtc)
.atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
 };
 
+enum drm_mode_status arc_pgu_crtc_mode_valid(struct drm_crtc *crtc,
+const struct drm_display_mode 
*mode)
+{
+   struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
+
+   if (!arc_pgu_is_mode_valid(arcpgu, mode))
+   return MODE_NOCLOCK;
+
+   return MODE_OK;
+}
+
 static void arc_pgu_crtc_mode_set_nofb(struct drm_crtc *crtc)
 {
struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
@@ -129,20 +152,6 @@ static void arc_pgu_crtc_disable(struct drm_crtc *crtc)
  ~ARCPGU_CTRL_ENABLE_MASK);
 }
 
-static int arc_pgu_crtc_atomic_check(struct drm_crtc *crtc,
-struct drm_crtc_state *state)
-{
-   struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
-   struct drm_display_mode *mode = >adjusted_mode;
-   long rate, clk_rate = mode->clock * 1000;
-
-   rate = clk_round_rate(arcpgu->clk, clk_rate);
-   if (rate != clk_rate)
-   return -EINVAL;
-
-   return 0;
-}
-
 static void arc_pgu_crtc_atomic_begin(struct drm_crtc *crtc,
  struct drm_crtc_state *state)
 {
@@ -158,6 +167,7 @@ static void arc_pgu_crtc_atomic_begin(struct drm_crtc *crtc,
 }
 
 static const struct drm_crtc_helper_funcs arc_pgu_crtc_helper_funcs = {
+   .mode_valid = arc_pgu_crtc_mode_valid,
.mode_set   = drm_helper_crtc_mode_set,
.mode_set_base  = drm_helper_crtc_mode_set_base,
.mode_set_nofb  = arc_pgu_crtc_mode_set_nofb,
@@ -165,7 +175,6 @@ static void arc_pgu_crtc_atomic_begin(struct drm_crtc *crtc,
.disable= arc_pgu_crtc_disable,
.prepare= arc_pgu_crtc_disable,
.commit = arc_pgu_crtc_enable,
-   .atomic_check   = arc_pgu_crtc_atomic_check,
.atomic_begin   = arc_pgu_crtc_atomic_begin,
 };
 
-- 
1.9.1


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

[PATCH v6 9/9] drm/i915: Set PWM divider to match desired frequency in vbt

[Puthikorn Voravootivat]

Read desired PWM frequency from panel vbt and calculate the
value for divider in DPCD address 0x724 and 0x728 to have
as many bits as possible for PWM duty cyle for granularity of
brightness adjustment while the frequency is still within 25%
of the desired frequency.

Signed-off-by: Puthikorn Voravootivat 
---
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 81 +++
 1 file changed, 81 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index fc26fea94fd4..0549ccb1bb09 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -113,12 +113,86 @@ intel_dp_aux_set_dynamic_backlight_percent(struct 
intel_dp *intel_dp,
}
 }
 
+/*
+ * Set PWM Frequency divider to match desired frequency in vbt.
+ * The PWM Frequency is calculated as 27Mhz / (F x P).
+ * - Where F = PWM Frequency Pre-Divider value programmed by field 7:0 of the
+ * EDP_BACKLIGHT_FREQ_SET register (DPCD Address 00728h)
+ * - Where P = 2^Pn, where Pn is the value programmed by field 4:0 of the
+ * EDP_PWMGEN_BIT_COUNT register (DPCD Address 00724h)
+ */
+static void intel_dp_aux_set_pwm_freq(struct intel_connector *connector)
+{
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct intel_dp *intel_dp = enc_to_intel_dp(>encoder->base);
+   int freq, fxp, f, fxp_min, fxp_max, fxp_actual;
+   u8 pn, pn_min, pn_max;
+
+   /* Find desired value of (F x P)
+* Note that, if F x P is out of supported range, the maximum value or
+* minimum value will applied automatically. So no need to check that.
+*/
+   freq = dev_priv->vbt.backlight.pwm_freq_hz;
+   DRM_DEBUG_KMS("VBT defined backlight frequency %u Hz\n", freq);
+   if (!freq) {
+   DRM_DEBUG_KMS("Use panel default backlight frequency\n");
+   return;
+   }
+
+   fxp = DP_EDP_BACKLIGHT_FREQ_BASE / freq;
+
+   /* Use highest possible value of Pn for more granularity of brightness
+* adjustment while satifying the conditions below.
+* - Pn is in the range of Pn_min and Pn_max
+* - F is in the range of 1 and 255
+* - Effective frequency is within 25% of desired frequency.
+*/
+   if (drm_dp_dpcd_readb(_dp->aux,
+  DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN, _min) != 1) {
+   DRM_DEBUG_KMS("Failed to read pwmgen bit count cap min\n");
+   return;
+   }
+   if (drm_dp_dpcd_readb(_dp->aux,
+  DP_EDP_PWMGEN_BIT_COUNT_CAP_MAX, _max) != 1) {
+   DRM_DEBUG_KMS("Failed to read pwmgen bit count cap max\n");
+   return;
+   }
+   pn_min &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
+   pn_max &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
+
+   fxp_min = fxp * 3 / 4;
+   fxp_max = fxp * 5 / 4;
+   if (fxp_min < (1 << pn_min) || (255 << pn_max) < fxp_max) {
+   DRM_DEBUG_KMS("VBT defined backlight frequency out of range\n");
+   return;
+   }
+
+   for (pn = pn_max; pn > pn_min; pn--) {
+   f = clamp(fxp >> pn, 1, 255);
+   fxp_actual = f << pn;
+   if (fxp_min <= fxp_actual && fxp_actual <= fxp_max)
+   break;
+   }
+
+   if (drm_dp_dpcd_writeb(_dp->aux,
+  DP_EDP_PWMGEN_BIT_COUNT, pn) < 0) {
+   DRM_DEBUG_KMS("Failed to write aux pwmgen bit count\n");
+   return;
+   }
+   if (drm_dp_dpcd_writeb(_dp->aux,
+  DP_EDP_BACKLIGHT_FREQ_SET, (u8) f) < 0) {
+   DRM_DEBUG_KMS("Failed to write aux backlight freq\n");
+   return;
+   }
+}
+
 static void intel_dp_aux_enable_backlight(struct intel_connector *connector)
 {
struct intel_dp *intel_dp = enc_to_intel_dp(>encoder->base);
uint8_t dpcd_buf = 0;
uint8_t new_dpcd_buf = 0;
uint8_t edp_backlight_mode = 0;
+   bool freq_cap;
 
if (drm_dp_dpcd_readb(_dp->aux,
DP_EDP_BACKLIGHT_MODE_SET_REGISTER, _buf) != 1) {
@@ -150,6 +224,10 @@ static void intel_dp_aux_enable_backlight(struct 
intel_connector *connector)
DRM_DEBUG_KMS("Enable dynamic brightness.\n");
}
 
+   freq_cap = intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_FREQ_AUX_SET_CAP;
+   if (freq_cap)
+   new_dpcd_buf |= DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE;
+
if (new_dpcd_buf != dpcd_buf) {
if (drm_dp_dpcd_writeb(_dp->aux,
DP_EDP_BACKLIGHT_MODE_SET_REGISTER, new_dpcd_buf) < 0) {
@@ -157,6 +235,9 @@ static void intel_dp_aux_enable_backlight(struct 
intel_connector *connector)
}
}
 
+   if (freq_cap)
+   intel_dp_aux_set_pwm_freq(connector);
+

[PATCH v6 3/9] drm/i915: Drop AUX backlight enable check for backlight control

[Puthikorn Voravootivat]

There are some panel that
(1) does not support display backlight enable via AUX
(2) support display backlight adjustment via AUX
(3) support display backlight enable via eDP BL_ENABLE pin

The current driver required that (1) must be support to enable (2).
This patch drops that requirement.

Signed-off-by: Puthikorn Voravootivat 
---
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index 870c03fc0f3a..c22712762957 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -28,6 +28,10 @@ static void set_aux_backlight_enable(struct intel_dp 
*intel_dp, bool enable)
 {
uint8_t reg_val = 0;
 
+   /* Early return when display use other mechanism to enable backlight. */
+   if (!(intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP))
+   return;
+
if (drm_dp_dpcd_readb(_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
  _val) < 0) {
DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
@@ -164,7 +168,6 @@ intel_dp_aux_display_control_capable(struct intel_connector 
*connector)
 * the panel can support backlight control over the aux channel
 */
if (intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP &&
-   (intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
(intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP) &&
!((intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_PIN_ENABLE_CAP) ||
  (intel_dp->edp_dpcd[2] & 
DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))) {
-- 
2.13.0.rc2.291.g57267f2277-goog

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

[PATCH v6 1/9] drm/i915: Fix cap check for intel_dp_aux_backlight driver

[Puthikorn Voravootivat]

intel_dp_aux_backlight driver should check for the
DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP before enable the driver.

Signed-off-by: Puthikorn Voravootivat 
---
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index 6532e226db29..341bf2cb0c25 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -144,6 +144,7 @@ intel_dp_aux_display_control_capable(struct intel_connector 
*connector)
 */
if (intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP &&
(intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
+   (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP) &&
!((intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_PIN_ENABLE_CAP) ||
  (intel_dp->edp_dpcd[2] & 
DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))) {
DRM_DEBUG_KMS("AUX Backlight Control Supported!\n");
-- 
2.13.0.rc2.291.g57267f2277-goog

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

Re: [drm:qxl] BUG: sleeping function called from invalid context - qxl_bo_kmap_atomic_page()...splat

[Mike Galbraith]

On Mon, 2017-05-08 at 16:48 -0300, Gabriel Krisman Bertazi wrote:

> Thanks for reporting this.  Can you confirm the following patch prevents
> the issue?

Nope, it still gripes.

[   43.910362] BUG: sleeping function called from invalid context at 
mm/slab.h:432
[   43.910955] in_atomic(): 1, irqs_disabled(): 0, pid: 2077, name: Xorg
[   43.911472] Preemption disabled at:
[   43.911478] [] qxl_bo_kmap_atomic_page+0xa5/0x100 [qxl]
[   43.912103] CPU: 0 PID: 2077 Comm: Xorg Tainted: GE   
4.12.0-master #38
[   43.912550] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
rel-1.8.1-0-g4adadbd-20161202_174313-build11a 04/01/2014
[   43.913202] Call Trace:
[   43.913371]  dump_stack+0x65/0x89
[   43.913581]  ? qxl_bo_kmap_atomic_page+0xa5/0x100 [qxl]
[   43.913876]  ___might_sleep+0x11a/0x190
[   43.914095]  __might_sleep+0x4a/0x80
[   43.914319]  ? qxl_bo_create+0x50/0x190 [qxl]
[   43.914565]  kmem_cache_alloc_trace+0x46/0x180
[   43.914836]  qxl_bo_create+0x50/0x190 [qxl]
[   43.915082]  ? refcount_dec_and_test+0x11/0x20
[   43.915332]  ? ttm_mem_io_reserve+0x41/0xe0 [ttm]
[   43.915595]  qxl_alloc_bo_reserved+0x37/0xb0 [qxl]
[   43.915884]  qxl_cursor_atomic_update+0x8f/0x260 [qxl]
[   43.916172]  ? drm_atomic_helper_update_legacy_modeset_state+0x1d6/0x210 
[drm_kms_helper]
[   43.916623]  drm_atomic_helper_commit_planes+0xec/0x230 [drm_kms_helper]
[   43.916995]  drm_atomic_helper_commit_tail+0x2b/0x60 [drm_kms_helper]
[   43.917398]  commit_tail+0x65/0x70 [drm_kms_helper]
[   43.917693]  drm_atomic_helper_commit+0xa9/0x100 [drm_kms_helper]
[   43.918039]  drm_atomic_commit+0x4b/0x50 [drm]
[   43.918334]  drm_atomic_helper_update_plane+0xf1/0x110 [drm_kms_helper]
[   43.918902]  __setplane_internal+0x19f/0x280 [drm]
[   43.919240]  drm_mode_cursor_universal+0x101/0x1c0 [drm]
[   43.919541]  drm_mode_cursor_common+0x15b/0x1d0 [drm]
[   43.919858]  drm_mode_cursor2_ioctl+0xe/0x10 [drm]
[   43.920157]  drm_ioctl+0x211/0x460 [drm]
[   43.920383]  ? drm_mode_cursor_ioctl+0x50/0x50 [drm]
[   43.920664]  ? handle_mm_fault+0x93/0x160
[   43.920893]  do_vfs_ioctl+0x96/0x6e0
[   43.921117]  ? __fget+0x73/0xa0
[   43.921322]  SyS_ioctl+0x41/0x70
[   43.921545]  entry_SYSCALL_64_fastpath+0x1a/0xa5
[   43.922188] RIP: 0033:0x7f1145804bc7
[   43.922526] RSP: 002b:7ffcd3e50508 EFLAGS: 3246 ORIG_RAX: 
0010
[   43.923367] RAX: ffda RBX: 0040 RCX: 7f1145804bc7
[   43.923852] RDX: 7ffcd3e50540 RSI: c02464bb RDI: 000b
[   43.924299] RBP: 0040 R08: 0040 R09: 000c
[   43.924694] R10: 7ffcd3e50340 R11: 3246 R12: 0018
[   43.925128] R13: 022bc390 R14: 0040 R15: 7ffcd3e5062c
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v6 2/9] drm/i915: Correctly enable backlight brightness adjustment via DPCD

[Puthikorn Voravootivat]

intel_dp_aux_enable_backlight() assumed that the register
BACKLIGHT_BRIGHTNESS_CONTROL_MODE can only has value 01
(DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET) when initialize.

This patch fixed that by handling all cases of that register.

Signed-off-by: Puthikorn Voravootivat 
Reviewed-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 33 ++-
 1 file changed, 27 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index 341bf2cb0c25..870c03fc0f3a 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -97,15 +97,36 @@ static void intel_dp_aux_enable_backlight(struct 
intel_connector *connector)
 {
struct intel_dp *intel_dp = enc_to_intel_dp(>encoder->base);
uint8_t dpcd_buf = 0;
+   uint8_t edp_backlight_mode = 0;
 
set_aux_backlight_enable(intel_dp, true);
 
-   if ((drm_dp_dpcd_readb(_dp->aux,
-  DP_EDP_BACKLIGHT_MODE_SET_REGISTER, _buf) 
== 1) &&
-   ((dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) ==
-DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET))
-   drm_dp_dpcd_writeb(_dp->aux, 
DP_EDP_BACKLIGHT_MODE_SET_REGISTER,
-  (dpcd_buf | 
DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD));
+   if (drm_dp_dpcd_readb(_dp->aux,
+   DP_EDP_BACKLIGHT_MODE_SET_REGISTER, _buf) != 1) {
+   DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
+ DP_EDP_BACKLIGHT_MODE_SET_REGISTER);
+   return;
+   }
+
+   edp_backlight_mode = dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
+
+   switch (edp_backlight_mode) {
+   case DP_EDP_BACKLIGHT_CONTROL_MODE_PWM:
+   case DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET:
+   case DP_EDP_BACKLIGHT_CONTROL_MODE_PRODUCT:
+   dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
+   dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
+   if (drm_dp_dpcd_writeb(_dp->aux,
+   DP_EDP_BACKLIGHT_MODE_SET_REGISTER, dpcd_buf) < 0) {
+   DRM_DEBUG_KMS("Failed to write aux backlight mode\n");
+   }
+   break;
+
+   /* Do nothing when it is already DPCD mode */
+   case DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD:
+   default:
+   break;
+   }
 }
 
 static void intel_dp_aux_disable_backlight(struct intel_connector *connector)
-- 
2.13.0.rc2.291.g57267f2277-goog

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

[PATCH v2 5/8] drm: Use new mode_valid() helpers in connector probe helper

[Jose Abreu]

This changes the connector probe helper function to use the new
encoder->mode_valid() and crtc->mode_valid() helper callbacks to
validate the modes.

The new callbacks are optional so the behaviour remains the same
if they are not implemented. If they are, then the code loops
through all the connector's encodersXcrtcs and calls the
callback.

If at least a valid encoderXcrtc combination is found which
accepts the mode then the function returns MODE_OK.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Alexey Brodkin 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Dave Airlie 
Cc: Andrzej Hajda 
Cc: Archit Taneja 
---

Changes v1->v2:
- Use new helpers suggested by Ville
- Change documentation (Daniel)

 drivers/gpu/drm/drm_probe_helper.c | 60 --
 1 file changed, 57 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index 1b0c14a..de47413 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -39,6 +39,8 @@
 #include 
 #include 
 
+#include "drm_crtc_internal.h"
+
 /**
  * DOC: output probing helper overview
  *
@@ -80,6 +82,54 @@
return MODE_OK;
 }
 
+static enum drm_mode_status
+drm_mode_validate_connector(struct drm_connector *connector,
+   struct drm_display_mode *mode)
+{
+   struct drm_device *dev = connector->dev;
+   uint32_t *ids = connector->encoder_ids;
+   enum drm_mode_status ret = MODE_OK;
+   unsigned int i;
+
+   /* Step 1: Validate against connector */
+   ret = drm_connector_mode_valid(connector, mode);
+   if (ret != MODE_OK)
+   return ret;
+
+   /* Step 2: Validate against encoders and crtcs */
+   for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) {
+   struct drm_encoder *encoder = drm_encoder_find(dev, ids[i]);
+   struct drm_crtc *crtc;
+
+   if (!encoder)
+   continue;
+
+   ret = drm_encoder_mode_valid(encoder, mode);
+   if (ret != MODE_OK) {
+   /* No point in continuing for crtc check as this encoder
+* will not accept the mode anyway. If all encoders
+* reject the mode then, at exit, ret will not be
+* MODE_OK. */
+   continue;
+   }
+
+   drm_for_each_crtc(crtc, dev) {
+   if (!drm_encoder_crtc_ok(encoder, crtc))
+   continue;
+
+   ret = drm_crtc_mode_valid(crtc, mode);
+   if (ret == MODE_OK) {
+   /* If we get to this point there is at least
+* one combination of encoder+crtc that works
+* for this mode. Lets return now. */
+   return ret;
+   }
+   }
+   }
+
+   return ret;
+}
+
 static int drm_helper_probe_add_cmdline_mode(struct drm_connector *connector)
 {
struct drm_cmdline_mode *cmdline_mode;
@@ -284,7 +334,11 @@ void drm_kms_helper_poll_enable(struct drm_device *dev)
  *- drm_mode_validate_flag() checks the modes against basic connector
  *  capabilities (interlace_allowed,doublescan_allowed,stereo_allowed)
  *- the optional _connector_helper_funcs.mode_valid helper can perform
- *  driver and/or hardware specific checks
+ *  driver and/or sink specific checks
+ *- the optional _crtc_helper_funcs.mode_valid and
+ *  _encoder_helper_funcs.mode_valid helpers can perform driver and/or
+ *  source specific checks which are also enforced by the modeset/atomic
+ *  helpers
  *
  * 5. Any mode whose status is not OK is pruned from the connector's modes 
list,
  *accompanied by a debug message indicating the reason for the mode's
@@ -428,8 +482,8 @@ int drm_helper_probe_single_connector_modes(struct 
drm_connector *connector,
if (mode->status == MODE_OK)
mode->status = drm_mode_validate_flag(mode, mode_flags);
 
-   if (mode->status == MODE_OK && connector_funcs->mode_valid)
-   mode->status = connector_funcs->mode_valid(connector,
+   if (mode->status == MODE_OK)
+   mode->status = drm_mode_validate_connector(connector,
   mode);
}
 
-- 
1.9.1


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

[PATCH v2 2/8] drm: Add drm_crtc_mode_valid()

[Jose Abreu]

Add a new helper to call crtc->mode_valid callback.

Suggested-by: Ville Syrjälä 
Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Alexey Brodkin 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Dave Airlie 
Cc: Andrzej Hajda 
Cc: Archit Taneja 
---
 drivers/gpu/drm/drm_crtc.c  | 22 ++
 drivers/gpu/drm/drm_crtc_internal.h |  3 +++
 2 files changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 5af25ce..07ae705 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -741,3 +742,24 @@ int drm_mode_crtc_set_obj_prop(struct drm_mode_object *obj,
 
return ret;
 }
+
+/**
+ * drm_crtc_mode_valid - call crtc->mode_valid callback, if any.
+ * @crtc: crtc
+ * @mode: mode to be validated
+ *
+ * If no mode_valid callback is available this will return MODE_OK.
+ *
+ * Returns: drm_mode_status Enum
+ */
+enum drm_mode_status drm_crtc_mode_valid(struct drm_crtc *crtc,
+const struct drm_display_mode *mode)
+{
+   const struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
+
+   if (!crtc_funcs || !crtc_funcs->mode_valid)
+   return MODE_OK;
+
+   return crtc_funcs->mode_valid(crtc, mode);
+}
+EXPORT_SYMBOL(drm_crtc_mode_valid);
diff --git a/drivers/gpu/drm/drm_crtc_internal.h 
b/drivers/gpu/drm/drm_crtc_internal.h
index d077c54..3800abd 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -45,6 +45,9 @@ int drm_crtc_check_viewport(const struct drm_crtc *crtc,
 
 struct dma_fence *drm_crtc_create_fence(struct drm_crtc *crtc);
 
+enum drm_mode_status drm_crtc_mode_valid(struct drm_crtc *crtc,
+const struct drm_display_mode *mode);
+
 /* IOCTLs */
 int drm_mode_getcrtc(struct drm_device *dev,
 void *data, struct drm_file *file_priv);
-- 
1.9.1


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

[PATCH v3 0/2] vsp1 writeback prototype

[Kieran Bingham]

This short series extends the VSP1 on the RCar platforms to allow creating a
V4L2 video node on display pipelines where the hardware allows writing to
memory simultaneously.

In this instance, the hardware restricts the output to match the display size
(no rescaling) but does allow pixel format conversion.

A current limitation (that the DRI devs might have ideas about) is that the vb2
buffers are swapped on the atomic_flush() calls rather than on vsync events.

Ideally swapping buffers would occur on every vsync such that the output rate
of the video node would match the display rate, however the timing here proves
more difficult to synchronise the updates from a vsync and flush without adding
latency to the flush.

Is there anything I can do to synchronise the v4l2 buffers with the DRM/KMS
interfaces currently? Or does anyone have any suggestions for extending as
such?

And of course ideas on anything that could be done generically to support other
targets as well would be worth considering - though currently this
implementation is very RCar/VSP1 specific.

v3:
 - Rebased to v4.12-rc1

v2:
 - Fix checkpatch.pl warnings
 - Adapt to use a single source pad for the Writeback and LIF
 - Use WPF properties to determine when to create links instead of VSP
 - Remove incorrect vsp1_video_verify_format() changes
 - Spelling and grammar fixes

Kieran Bingham (2):
  Revert "[media] v4l: vsp1: Supply frames to the DU continuously"
  v4l: vsp1: Provide a writeback video device

Kieran Bingham (2):
  Revert "[media] v4l: vsp1: Supply frames to the DU continuously"
  v4l: vsp1: Provide a writeback video device

 drivers/media/platform/vsp1/vsp1.h   |   1 +-
 drivers/media/platform/vsp1/vsp1_drm.c   |  18 +++-
 drivers/media/platform/vsp1/vsp1_drv.c   |   5 +-
 drivers/media/platform/vsp1/vsp1_rwpf.h  |   1 +-
 drivers/media/platform/vsp1/vsp1_video.c | 161 ++--
 drivers/media/platform/vsp1/vsp1_video.h |   5 +-
 drivers/media/platform/vsp1/vsp1_wpf.c   |  19 ++-
 7 files changed, 192 insertions(+), 18 deletions(-)

base-commit: 13e0988140374123bead1dd27c287354cb95108e
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH v5 3/9] drm/i915: Drop AUX backlight enable check for backlight control

[Puthikorn Voravootivat]

> How is backlight enabled in this case?
Using eDP BL_ENABLE pin

On Sat, May 6, 2017 at 1:59 AM, Pandiyan, Dhinakaran <
dhinakaran.pandi...@intel.com> wrote:

> On Wed, 2017-05-03 at 17:28 -0700, Puthikorn Voravootivat wrote:
> > There are some panel that
> > (1) does not support display backlight enable via AUX
> > (2) support display backlight adjustment via AUX
> > (3) support display backlight enable via eDP BL_ENABLE pin
> >
> > The current driver required that (1) must be support to enable (2).
> > This patch drops that requirement.
> >
> > Signed-off-by: Puthikorn Voravootivat 
> > ---
> >  drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > index ad8560c5f689..5b83c9737644 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > @@ -28,6 +28,10 @@ static void set_aux_backlight_enable(struct intel_dp
> *intel_dp, bool enable)
> >  {
> >   uint8_t reg_val = 0;
> >
> > +   /* Early return when display use other mechanism to enable
> backlight. */
> > + if (!(intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP))
> > + return;
> > +
>
> How is backlight enabled in this case?
>
> -DK
>
> >   if (drm_dp_dpcd_readb(_dp->aux, DP_EDP_DISPLAY_CONTROL_
> REGISTER,
> > _val) < 0) {
> >   DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
> > @@ -164,7 +168,6 @@ intel_dp_aux_display_control_capable(struct
> intel_connector *connector)
> >* the panel can support backlight control over the aux channel
> >*/
> >   if ((intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP)
> &&
> > - (intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
> >   (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP))
> {
> >   DRM_DEBUG_KMS("AUX Backlight Control Supported!\n");
> >   return true;
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 1/2] Revert "[media] v4l: vsp1: Supply frames to the DU continuously"

[Kieran Bingham]

This reverts commit 3299ba5c0b21 ("[media] v4l: vsp1: Supply frames to
the DU continuously")

The DU output mode does not rely on frames being supplied on the WPF as
its pipeline is supplied from DRM. For the upcoming WPF writeback
functionality, we will choose to enable writeback mode if there is an
output buffer, or disable it (leaving the existing display pipeline
unharmed) otherwise.

Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_video.c | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_video.c 
b/drivers/media/platform/vsp1/vsp1_video.c
index eab3c3ea85d7..47b5c24043d7 100644
--- a/drivers/media/platform/vsp1/vsp1_video.c
+++ b/drivers/media/platform/vsp1/vsp1_video.c
@@ -304,11 +304,6 @@ static struct v4l2_rect vsp1_video_partition(struct 
vsp1_pipeline *pipe,
  * This function completes the current buffer by filling its sequence number,
  * time stamp and payload size, and hands it back to the videobuf core.
  *
- * When operating in DU output mode (deep pipeline to the DU through the LIF),
- * the VSP1 needs to constantly supply frames to the display. In that case, if
- * no other buffer is queued, reuse the one that has just been processed 
instead
- * of handing it back to the videobuf core.
- *
  * Return the next queued buffer or NULL if the queue is empty.
  */
 static struct vsp1_vb2_buffer *
@@ -330,12 +325,6 @@ vsp1_video_complete_buffer(struct vsp1_video *video)
done = list_first_entry(>irqqueue,
struct vsp1_vb2_buffer, queue);
 
-   /* In DU output mode reuse the buffer if the list is singular. */
-   if (pipe->lif && list_is_singular(>irqqueue)) {
-   spin_unlock_irqrestore(>irqlock, flags);
-   return done;
-   }
-
list_del(>queue);
 
if (!list_empty(>irqqueue))
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] gpu: drm: gma500: remove dead code

[Gustavo A. R. Silva]

Local variable use_gct is assigned to a constant value and it is never
updated again. Remove this variable and the dead code it guards.

Addresses-Coverity-ID: 145690
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/gpu/drm/gma500/mdfld_tpo_vid.c | 51 ++
 1 file changed, 9 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/gma500/mdfld_tpo_vid.c 
b/drivers/gpu/drm/gma500/mdfld_tpo_vid.c
index d8d4170..d40628e 100644
--- a/drivers/gpu/drm/gma500/mdfld_tpo_vid.c
+++ b/drivers/gpu/drm/gma500/mdfld_tpo_vid.c
@@ -32,53 +32,20 @@ static struct drm_display_mode 
*tpo_vid_get_config_mode(struct drm_device *dev)
struct drm_display_mode *mode;
struct drm_psb_private *dev_priv = dev->dev_private;
struct oaktrail_timing_info *ti = _priv->gct_data.DTD;
-   bool use_gct = false;
 
mode = kzalloc(sizeof(*mode), GFP_KERNEL);
if (!mode)
return NULL;
 
-   if (use_gct) {
-   mode->hdisplay = (ti->hactive_hi << 8) | ti->hactive_lo;
-   mode->vdisplay = (ti->vactive_hi << 8) | ti->vactive_lo;
-   mode->hsync_start = mode->hdisplay +
-   ((ti->hsync_offset_hi << 8) |
-   ti->hsync_offset_lo);
-   mode->hsync_end = mode->hsync_start +
-   ((ti->hsync_pulse_width_hi << 8) |
-   ti->hsync_pulse_width_lo);
-   mode->htotal = mode->hdisplay + ((ti->hblank_hi << 8) |
-   ti->hblank_lo);
-   mode->vsync_start =
-   mode->vdisplay + ((ti->vsync_offset_hi << 8) |
-   ti->vsync_offset_lo);
-   mode->vsync_end =
-   mode->vsync_start + ((ti->vsync_pulse_width_hi << 8) |
-   ti->vsync_pulse_width_lo);
-   mode->vtotal = mode->vdisplay +
-   ((ti->vblank_hi << 8) | ti->vblank_lo);
-   mode->clock = ti->pixel_clock * 10;
-
-   dev_dbg(dev->dev, "hdisplay is %d\n", mode->hdisplay);
-   dev_dbg(dev->dev, "vdisplay is %d\n", mode->vdisplay);
-   dev_dbg(dev->dev, "HSS is %d\n", mode->hsync_start);
-   dev_dbg(dev->dev, "HSE is %d\n", mode->hsync_end);
-   dev_dbg(dev->dev, "htotal is %d\n", mode->htotal);
-   dev_dbg(dev->dev, "VSS is %d\n", mode->vsync_start);
-   dev_dbg(dev->dev, "VSE is %d\n", mode->vsync_end);
-   dev_dbg(dev->dev, "vtotal is %d\n", mode->vtotal);
-   dev_dbg(dev->dev, "clock is %d\n", mode->clock);
-   } else {
-   mode->hdisplay = 864;
-   mode->vdisplay = 480;
-   mode->hsync_start = 873;
-   mode->hsync_end = 876;
-   mode->htotal = 887;
-   mode->vsync_start = 487;
-   mode->vsync_end = 490;
-   mode->vtotal = 499;
-   mode->clock = 33264;
-   }
+   mode->hdisplay = 864;
+   mode->vdisplay = 480;
+   mode->hsync_start = 873;
+   mode->hsync_end = 876;
+   mode->htotal = 887;
+   mode->vsync_start = 487;
+   mode->vsync_end = 490;
+   mode->vtotal = 499;
+   mode->clock = 33264;
 
drm_mode_set_name(mode);
drm_mode_set_crtcinfo(mode, 0);
-- 
2.5.0

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

[PATCH v6 4/9] drm/i915: Allow choosing how to adjust brightness if both supported

[Puthikorn Voravootivat]

Add option to allow choosing how to adjust brightness if
panel supports both PWM pin and AUX channel.

Signed-off-by: Puthikorn Voravootivat 
---
 drivers/gpu/drm/i915/i915_params.c|  8 +---
 drivers/gpu/drm/i915/i915_params.h|  2 +-
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 23 ++-
 3 files changed, 24 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index b6a7e363d076..13cf3f1572ab 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -63,7 +63,7 @@ struct i915_params i915 __read_mostly = {
.huc_firmware_path = NULL,
.enable_dp_mst = true,
.inject_load_failure = 0,
-   .enable_dpcd_backlight = false,
+   .enable_dpcd_backlight = -1,
.enable_gvt = false,
 };
 
@@ -246,9 +246,11 @@ MODULE_PARM_DESC(enable_dp_mst,
 module_param_named_unsafe(inject_load_failure, i915.inject_load_failure, uint, 
0400);
 MODULE_PARM_DESC(inject_load_failure,
"Force an error after a number of failure check points (0:disabled 
(default), N:force failure at the Nth failure check point)");
-module_param_named(enable_dpcd_backlight, i915.enable_dpcd_backlight, bool, 
0600);
+module_param_named(enable_dpcd_backlight, i915.enable_dpcd_backlight, int, 
0600);
 MODULE_PARM_DESC(enable_dpcd_backlight,
-   "Enable support for DPCD backlight control (default:false)");
+   "Enable support for DPCD backlight control "
+   "(-1:disable (default), 0:Use PWM pin if both supported, "
+   "1:Use DPCD if both supported");
 
 module_param_named(enable_gvt, i915.enable_gvt, bool, 0400);
 MODULE_PARM_DESC(enable_gvt,
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 34148cc8637c..ac02efce6e22 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -66,7 +66,7 @@
func(bool, verbose_state_checks); \
func(bool, nuclear_pageflip); \
func(bool, enable_dp_mst); \
-   func(bool, enable_dpcd_backlight); \
+   func(int, enable_dpcd_backlight); \
func(bool, enable_gvt)
 
 #define MEMBER(T, member) T member
diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index c22712762957..e82f7cb9a7af 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -167,21 +167,34 @@ intel_dp_aux_display_control_capable(struct 
intel_connector *connector)
/* Check the  eDP Display control capabilities registers to determine if
 * the panel can support backlight control over the aux channel
 */
-   if (intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP &&
-   (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP) &&
-   !((intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_PIN_ENABLE_CAP) ||
- (intel_dp->edp_dpcd[2] & 
DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))) {
+   if ((intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP) &&
+   (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP)) {
DRM_DEBUG_KMS("AUX Backlight Control Supported!\n");
return true;
}
return false;
 }
 
+static bool
+intel_dp_pwm_pin_display_control_capable(struct intel_connector *connector)
+{
+   struct intel_dp *intel_dp = enc_to_intel_dp(>encoder->base);
+
+   /* Check the  eDP Display control capabilities registers to determine if
+* the panel can support backlight control via BL_PWM_DIM eDP pin
+*/
+   return intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP;
+}
+
 int intel_dp_aux_init_backlight_funcs(struct intel_connector *intel_connector)
 {
struct intel_panel *panel = _connector->panel;
 
-   if (!i915.enable_dpcd_backlight)
+   if (i915.enable_dpcd_backlight == -1)
+   return -ENODEV;
+
+   if (i915.enable_dpcd_backlight == 0 &&
+   intel_dp_pwm_pin_display_control_capable(intel_connector))
return -ENODEV;
 
if (!intel_dp_aux_display_control_capable(intel_connector))
-- 
2.13.0.rc2.291.g57267f2277-goog

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

[PATCH v6 7/9] drm/i915: Restore brightness level in aux backlight driver

[Puthikorn Voravootivat]

Some panel will default to zero brightness when turning the
panel off and on again. This patch restores last brightness
level back when panel is turning back on.

Signed-off-by: Puthikorn Voravootivat 
Reviewed-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index 7d323af96636..fc26fea94fd4 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -158,6 +158,7 @@ static void intel_dp_aux_enable_backlight(struct 
intel_connector *connector)
}
 
set_aux_backlight_enable(intel_dp, true);
+   intel_dp_aux_set_backlight(connector, connector->panel.backlight.level);
 }
 
 static void intel_dp_aux_disable_backlight(struct intel_connector *connector)
-- 
2.13.0.rc2.291.g57267f2277-goog

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

[PATCH v2 0/8] Introduce new mode validation callbacks

[Jose Abreu]

This series is a follow up from the discussion at [1]. We start by
introducing crtc->mode_valid(), encoder->mode_valid() and
bridge->mode_valid() callbacks which will be used in followup
patches.

We proceed by introducing new helpers to call this new callbacks
at 2/8, 3/8 and 4/8.

Next, at 5/8 we modify the connector probe helper so that only modes
which are supported by a given encoder+crtc combination are probbed.

At 6/8 a helper function is introduced that calls all mode_valid()
from a set of bridges.

At 7/8 we call all the mode_valid() callbacks for a given pipeline,
except the connector->mode_valid one, so that the mode is validated.
This is done before calling mode_fixup().

Finally, at 8/8 we use the new crtc->mode_valid() callback in arcpgu
and remove the atomic_check() callback.

[1] https://patchwork.kernel.org/patch/9702233/

Jose Abreu (8):
  drm: Add crtc/encoder/bridge->mode_valid() callbacks
  drm: Add drm_crtc_mode_valid()
  drm: Add drm_encoder_mode_valid()
  drm: Add drm_connector_mode_valid()
  drm: Use new mode_valid() helpers in connector probe helper
  drm: Introduce drm_bridge_mode_valid()
  drm: Use mode_valid() in atomic modeset
  drm: arc: Use crtc->mode_valid() callback

Cc: Carlos Palminha 
Cc: Alexey Brodkin 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Dave Airlie 
Cc: Andrzej Hajda 
Cc: Archit Taneja 

 drivers/gpu/drm/arc/arcpgu_crtc.c| 39 ++---
 drivers/gpu/drm/drm_atomic_helper.c  | 75 ++--
 drivers/gpu/drm/drm_bridge.c | 33 ++
 drivers/gpu/drm/drm_connector.c  | 23 ++
 drivers/gpu/drm/drm_crtc.c   | 22 ++
 drivers/gpu/drm/drm_crtc_internal.h  |  7 +++
 drivers/gpu/drm/drm_encoder.c| 23 ++
 drivers/gpu/drm/drm_probe_helper.c   | 60 +++--
 include/drm/drm_bridge.h | 22 ++
 include/drm/drm_modeset_helper_vtables.h | 45 +++
 10 files changed, 328 insertions(+), 21 deletions(-)

-- 
1.9.1


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

[PATCH] gpu: drm: gma500: remove dead code

[Gustavo A. R. Silva]

Local variable pipe is assigned to a constant value and it is never
updated again. Remove this variable and the dead code it guards.

Addresses-Coverity-ID: 201351
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/gpu/drm/gma500/oaktrail_hdmi.c | 21 ++---
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/gma500/oaktrail_hdmi.c 
b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
index 8b2eb32..58a9751 100644
--- a/drivers/gpu/drm/gma500/oaktrail_hdmi.c
+++ b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
@@ -265,17 +265,16 @@ int oaktrail_crtc_hdmi_mode_set(struct drm_crtc *crtc,
struct drm_device *dev = crtc->dev;
struct drm_psb_private *dev_priv = dev->dev_private;
struct oaktrail_hdmi_dev *hdmi_dev = dev_priv->hdmi_priv;
-   int pipe = 1;
-   int htot_reg = (pipe == 0) ? HTOTAL_A : HTOTAL_B;
-   int hblank_reg = (pipe == 0) ? HBLANK_A : HBLANK_B;
-   int hsync_reg = (pipe == 0) ? HSYNC_A : HSYNC_B;
-   int vtot_reg = (pipe == 0) ? VTOTAL_A : VTOTAL_B;
-   int vblank_reg = (pipe == 0) ? VBLANK_A : VBLANK_B;
-   int vsync_reg = (pipe == 0) ? VSYNC_A : VSYNC_B;
-   int dspsize_reg = (pipe == 0) ? DSPASIZE : DSPBSIZE;
-   int dsppos_reg = (pipe == 0) ? DSPAPOS : DSPBPOS;
-   int pipesrc_reg = (pipe == 0) ? PIPEASRC : PIPEBSRC;
-   int pipeconf_reg = (pipe == 0) ? PIPEACONF : PIPEBCONF;
+   int htot_reg = HTOTAL_B;
+   int hblank_reg = HBLANK_B;
+   int hsync_reg = HSYNC_B;
+   int vtot_reg = VTOTAL_B;
+   int vblank_reg = VBLANK_B;
+   int vsync_reg = VSYNC_B;
+   int dspsize_reg = DSPBSIZE;
+   int dsppos_reg = DSPBPOS;
+   int pipesrc_reg = PIPEBSRC;
+   int pipeconf_reg = PIPEBCONF;
int refclk;
struct oaktrail_hdmi_clock clock;
u32 dspcntr, pipeconf, dpll, temp;
-- 
2.5.0

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

[PATCH v6 5/9] drm/i915: Set backlight mode before enable backlight

[Puthikorn Voravootivat]

We should set backlight mode register before set register to
enable the backlight.

Signed-off-by: Puthikorn Voravootivat 
Reviewed-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index e82f7cb9a7af..5ef3ade7c40e 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -103,8 +103,6 @@ static void intel_dp_aux_enable_backlight(struct 
intel_connector *connector)
uint8_t dpcd_buf = 0;
uint8_t edp_backlight_mode = 0;
 
-   set_aux_backlight_enable(intel_dp, true);
-
if (drm_dp_dpcd_readb(_dp->aux,
DP_EDP_BACKLIGHT_MODE_SET_REGISTER, _buf) != 1) {
DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
@@ -131,6 +129,8 @@ static void intel_dp_aux_enable_backlight(struct 
intel_connector *connector)
default:
break;
}
+
+   set_aux_backlight_enable(intel_dp, true);
 }
 
 static void intel_dp_aux_disable_backlight(struct intel_connector *connector)
-- 
2.13.0.rc2.291.g57267f2277-goog

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

[PATCH v2 3/8] drm: Add drm_encoder_mode_valid()

[Jose Abreu]

Add a new helper to call encoder->mode_valid callback.

Suggested-by: Ville Syrjälä 
Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Alexey Brodkin 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Dave Airlie 
Cc: Andrzej Hajda 
Cc: Archit Taneja 
---
 drivers/gpu/drm/drm_crtc_internal.h |  2 ++
 drivers/gpu/drm/drm_encoder.c   | 23 +++
 2 files changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc_internal.h 
b/drivers/gpu/drm/drm_crtc_internal.h
index 3800abd..6165bc9 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -129,6 +129,8 @@ int drm_mode_obj_set_property_ioctl(struct drm_device *dev, 
void *data,
 /* drm_encoder.c */
 int drm_encoder_register_all(struct drm_device *dev);
 void drm_encoder_unregister_all(struct drm_device *dev);
+enum drm_mode_status drm_encoder_mode_valid(struct drm_encoder *encoder,
+   const struct drm_display_mode 
*mode);
 
 /* IOCTL */
 int drm_mode_getencoder(struct drm_device *dev,
diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
index 0708779..af75f42 100644
--- a/drivers/gpu/drm/drm_encoder.c
+++ b/drivers/gpu/drm/drm_encoder.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "drm_crtc_internal.h"
 
@@ -239,3 +240,25 @@ int drm_mode_getencoder(struct drm_device *dev, void *data,
 
return 0;
 }
+
+/**
+ * drm_encoder_mode_valid - call encoder->mode_valid callback, if any.
+ * @encoder: encoder
+ * @mode: mode to be validated
+ *
+ * If no mode_valid callback is available this will return MODE_OK.
+ *
+ * Returns: drm_mode_status Enum
+ */
+enum drm_mode_status drm_encoder_mode_valid(struct drm_encoder *encoder,
+   const struct drm_display_mode *mode)
+{
+   const struct drm_encoder_helper_funcs *encoder_funcs =
+   encoder->helper_private;
+
+   if (!encoder_funcs || !encoder_funcs->mode_valid)
+   return MODE_OK;
+
+   return encoder_funcs->mode_valid(encoder, mode);
+}
+EXPORT_SYMBOL(drm_encoder_mode_valid);
-- 
1.9.1


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

[PATCH v6 0/9] Enhancement to intel_dp_aux_backlight driver

[Puthikorn Voravootivat]

This patch set contain 9 patches.
- First five patches fix bug in the driver and allow choosing which
  way to adjust brightness if both PWM pin and AUX are supported
- Next patch adds enable DBC by default
- Next patch makes the driver restore last brightness level after
  turning display off and on.
- Last two patches set the PWM freqency to match data in panel vbt.

Change log:
v6:
- Address review from Dhinakaran
- Make PWM frequency to have highest value of Pn that make the
  frequency still within 25% of desired frequency.

v5:
- Split first patch in v4 to 3 patches
- Bump priority for "Correctly enable backlight brightness adjustment via DPCD"
- Make logic clearer for the case that both PWM pin and AUX are supported
- Add more log when write to register fail
- Add log when enable DBC

v4:
- Rebase / minor typo fix.

v3:
- Add new implementation of PWM frequency patch

v2:
- Drop PWM frequency patch
- Address suggestion from Jani Nikula

Puthikorn Voravootivat (9):
  drm/i915: Fix cap check for intel_dp_aux_backlight driver
  drm/i915: Correctly enable backlight brightness adjustment via DPCD
  drm/i915: Drop AUX backlight enable check for backlight control
  drm/i915: Allow choosing how to adjust brightness if both supported
  drm/i915: Set backlight mode before enable backlight
  drm/i915: Support dynamic backlight via DPCD register
  drm/i915: Restore brightness level in aux backlight driver
  drm: Add definition for eDP backlight frequency
  drm/i915: Set PWM divider to match desired frequency in vbt

 drivers/gpu/drm/i915/i915_params.c|   8 +-
 drivers/gpu/drm/i915/i915_params.h|   2 +-
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 171 --
 include/drm/drm_dp_helper.h   |   2 +
 4 files changed, 167 insertions(+), 16 deletions(-)

-- 
2.13.0.rc2.291.g57267f2277-goog

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

Re: [PATCH v2] drm/vc4: Enable selection in Kconfig on any 32-bit BCM platform.

[Scott Branden]

Looks good for Cygnus.

On 17-05-09 11:15 AM, Eric Anholt wrote:

With the Cygnus port, we needed to add at least "|| ARCH_BCM_CYGNUS"
to let the module get built on a cygnus-only kernel.  However, I
anticipate having a port for Kona soon, so just present the module on
all of BCM.

v2: Keep allowing selection with ARCH_BCM2835, since ARCH_BCM doesn't
exist on arm64.

Signed-off-by: Eric Anholt 
Acked-by: Daniel Vetter  (v1)

Acked-by: Scott Branden 

---
 drivers/gpu/drm/vc4/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/Kconfig b/drivers/gpu/drm/vc4/Kconfig
index 973b4203c0b2..b16aefe4a8d3 100644
--- a/drivers/gpu/drm/vc4/Kconfig
+++ b/drivers/gpu/drm/vc4/Kconfig
@@ -1,6 +1,6 @@
 config DRM_VC4
tristate "Broadcom VC4 Graphics"
-   depends on ARCH_BCM2835 || COMPILE_TEST
+   depends on ARCH_BCM || ARCH_BCM2835 || COMPILE_TEST
depends on DRM
depends on SND && SND_SOC
depends on COMMON_CLK


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

[PATCH v6 6/9] drm/i915: Support dynamic backlight via DPCD register

[Puthikorn Voravootivat]

This patch enables dynamic backlight by default for eDP
panel that supports this feature via DPCD register and
set minimum / maximum brightness to 0% and 100% of the
normal brightness.

Signed-off-by: Puthikorn Voravootivat 
---
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 39 ++-
 1 file changed, 33 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index 5ef3ade7c40e..7d323af96636 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -97,10 +97,27 @@ intel_dp_aux_set_backlight(struct intel_connector 
*connector, u32 level)
}
 }
 
+/*
+ * Set minimum / maximum dynamic brightness percentage. This value is expressed
+ * as the percentage of normal brightness in 5% increments.
+ */
+static void
+intel_dp_aux_set_dynamic_backlight_percent(struct intel_dp *intel_dp,
+  u32 min, u32 max)
+{
+   u8 dbc[] = { DIV_ROUND_CLOSEST(min, 5), DIV_ROUND_CLOSEST(max, 5) };
+
+   if (drm_dp_dpcd_write(_dp->aux, DP_EDP_DBC_MINIMUM_BRIGHTNESS_SET,
+ dbc, sizeof(dbc) < 0)) {
+   DRM_DEBUG_KMS("Failed to write aux DBC brightness level\n");
+   }
+}
+
 static void intel_dp_aux_enable_backlight(struct intel_connector *connector)
 {
struct intel_dp *intel_dp = enc_to_intel_dp(>encoder->base);
uint8_t dpcd_buf = 0;
+   uint8_t new_dpcd_buf = 0;
uint8_t edp_backlight_mode = 0;
 
if (drm_dp_dpcd_readb(_dp->aux,
@@ -110,18 +127,15 @@ static void intel_dp_aux_enable_backlight(struct 
intel_connector *connector)
return;
}
 
+   new_dpcd_buf = dpcd_buf;
edp_backlight_mode = dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
 
switch (edp_backlight_mode) {
case DP_EDP_BACKLIGHT_CONTROL_MODE_PWM:
case DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET:
case DP_EDP_BACKLIGHT_CONTROL_MODE_PRODUCT:
-   dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
-   dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
-   if (drm_dp_dpcd_writeb(_dp->aux,
-   DP_EDP_BACKLIGHT_MODE_SET_REGISTER, dpcd_buf) < 0) {
-   DRM_DEBUG_KMS("Failed to write aux backlight mode\n");
-   }
+   new_dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
+   new_dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
break;
 
/* Do nothing when it is already DPCD mode */
@@ -130,6 +144,19 @@ static void intel_dp_aux_enable_backlight(struct 
intel_connector *connector)
break;
}
 
+   if (intel_dp->edp_dpcd[2] & DP_EDP_DYNAMIC_BACKLIGHT_CAP) {
+   new_dpcd_buf |= DP_EDP_DYNAMIC_BACKLIGHT_ENABLE;
+   intel_dp_aux_set_dynamic_backlight_percent(intel_dp, 0, 100);
+   DRM_DEBUG_KMS("Enable dynamic brightness.\n");
+   }
+
+   if (new_dpcd_buf != dpcd_buf) {
+   if (drm_dp_dpcd_writeb(_dp->aux,
+   DP_EDP_BACKLIGHT_MODE_SET_REGISTER, new_dpcd_buf) < 0) {
+   DRM_DEBUG_KMS("Failed to write aux backlight mode\n");
+   }
+   }
+
set_aux_backlight_enable(intel_dp, true);
 }
 
-- 
2.13.0.rc2.291.g57267f2277-goog

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

Re: [PATCH v2] drm/vc4: Enable selection in Kconfig on any 32-bit BCM platform.

[Florian Fainelli]

On 05/09/2017 04:16 PM, Eric Anholt wrote:
> Florian Fainelli  writes:
> 
>> On 05/09/2017 11:15 AM, Eric Anholt wrote:
>>> With the Cygnus port, we needed to add at least "|| ARCH_BCM_CYGNUS"
>>> to let the module get built on a cygnus-only kernel.  However, I
>>> anticipate having a port for Kona soon, so just present the module on
>>> all of BCM.
>>>
>>> v2: Keep allowing selection with ARCH_BCM2835, since ARCH_BCM doesn't
>>> exist on arm64.
>>
>> Nit: the patch changelog usually goes after the "---" line so it gets
>> stripped with git am. Not necessary to resubmit just because of that.
> 
> Behavior on that front differs between subsystems.  DRM is one where the
> changelog is generally retained.

Once the patch lands in git, it's sort of interesting to know its
history and the context surrounding this acceptance, but there is
already so much context being lost already (like where are all other
patches from the same patch series for instance?) that I wonder if we
should not add more to it (like links to past iterations and so on).

Thanks for explaining how DRM works in that regard, though.
-- 
Florian
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv2 0/3] Intel FPGA VIP Frame Buffer II DRM Driver

[Ong, Hean Loong]

On Mon, 2017-05-08 at 09:03 -0700, Eric Anholt wrote:
> "Ong, Hean Loong"  writes:
> 
> > 
> > On Thu, 2017-05-04 at 10:11 -0700, Eric Anholt wrote:
> > > 
> > > "Ong, Hean Loong"  writes:
> > > 
> > > > 
> > > > 
> > > > On Wed, 2017-05-03 at 13:28 -0700, Eric Anholt wrote:
> > > > > 
> > > > > 
> > > > > hean.loong@intel.com writes:
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > From: Ong Hean Loong 
> > > > > > 
> > > > > > Hi,
> > > > > > 
> > > > > > The new Intel Arria10 SOC FPGA devkit has a Display Port IP
> > > > > > component 
> > > > > > which requires a new driver. This is a virtual driver in
> > > > > > which
> > > > > > the
> > > > > > FGPA hardware would enable the Display Port based on the
> > > > > > information
> > > > > > and data provided from the DRM frame buffer from the OS.
> > > > > > Basically
> > > > > > all
> > > > > > all information with reagrds to resolution and bits per
> > > > > > pixel
> > > > > > are
> > > > > > pre-configured on the FPGA design and these information are
> > > > > > fed
> > > > > > to
> > > > > > the driver via the device tree information as part of the
> > > > > > hardware 
> > > > > > information.
> > > > > I started reviewing the code, but I want to make sure I
> > > > > understand
> > > > > what's going on:
> > > > > 
> > > > > This IP core isn't displaying contents from system memory on
> > > > > some
> > > > > sort
> > > > > of actual physical display, right?  It's a core that takes
> > > > > some
> > > > > input
> > > > > video stream (not described in the DT or in this driver) and
> > > > > stores
> > > > > it
> > > > > to memory?
> > > > If the IP Core you are referring to is some form of GPU then in
> > > > this
> > > > case we are using the Intel FPGA Display Port Framebuffer IP.
> > > > It
> > > > does
> > > > display contents streamed from the ARM/Linux system to the
> > > > Display
> > > > Port
> > > > of the physical Monitor.
> > > > 
> > > > Below a simple illustration of the system:
> > > > 
> > > > ARM/Linux --DMA-->Intel FPGA Display Port Framebuffer IP
> > > > |
> > > > |
> > > > Physical Connection
> > > > Display Port
> > > The "DMA" in this diagram is the frame reader IP, right?  The
> > > frame
> > > reader, as described in the spec, sounds approximately like a DRM
> > > plane,
> > > so if you have that in your system then that needs to be part of
> > > this
> > > DRM driver (otherwise you won't be putting the right things on
> > > the
> > > screen!).
> > Would the drm_simple_display_pipe_init be able to handle this ? It
> > seems to be displaying the proper images on screen, based on my
> > current
> > changes. There were recommendations to use the
> > drm_simple_display_pipe_init instead of creating the CRTC and
> > planes
> > myself
> The docs I've read for the Frame Buffer IP don't fit into any current
> DRM component, since it's what we're currently calling a "writeback
> connector".
> 
While running my own test (since the intel-gpu-tools doesn't seems
applicable.) The drm_simple_display_pipe_init seems to be simple enough
for displaying a matchbox console. The use case for this driver is only
part of the enablemennt of the reference design board so that users of
the Arria10 devkit can use this as base for their own designs.

> I don't understand your system enough to answer.  You didn't answer
> if
> the "DMA" block you diagrammed was the frame reader IP (or maybe the
> frame reader IP comes after).  I also don't see how the frame buffer
> IP
> could possibly be connected directly to a physical display connector.

The FPGA FrameBuffer 2 soft IP reads the information provided to it
from the Linux Kernel via the platform device register provided in the
DT. The Linux driver here allocates a chunk of coherent memory that
directly maps to the SDRAM. The FPGA soft IP would stream the display
out to the Display Port based on the information that was written to
the SDRAM.

The FrameBuffer 2 IP or previously used Frame Reader IP are soft IP is
programmed as part of the FPGA which is connected to the Display Port
via a native physical transceiver. The Soft IP are driven by the NIOS 2
soft core which is also the soft processor. 

Note however whatever that goes beyond the the memory bus (between ARM
and FPGA) known as Avalon is no longer under the control of the Linux
Driver (as we only establish connection on the ARM side)
  

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

[PATCH v2 4/8] drm: Add drm_connector_mode_valid()

[Jose Abreu]

Add a new helper to call connector->mode_valid callback.

Suggested-by: Ville Syrjälä 
Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Alexey Brodkin 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Dave Airlie 
Cc: Andrzej Hajda 
Cc: Archit Taneja 
---

TODO: function prototype should receive a const, but currently
mode_valid declaration is not const. In order to change this
I needed to touch *every* driver who uses this callback.
Postponed to when I have the time.

 drivers/gpu/drm/drm_connector.c | 23 +++
 drivers/gpu/drm/drm_crtc_internal.h |  2 ++
 2 files changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 9f84761..f2634a2 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "drm_crtc_internal.h"
 #include "drm_internal.h"
@@ -1418,3 +1419,25 @@ struct drm_tile_group *drm_mode_create_tile_group(struct 
drm_device *dev,
return tg;
 }
 EXPORT_SYMBOL(drm_mode_create_tile_group);
+
+/**
+ * drm_connector_mode_valid - call connector->mode_valid callback, if any.
+ * @connector: connector
+ * @mode: mode to be validated
+ *
+ * If no mode_valid callback is available this will return MODE_OK.
+ *
+ * Returns: drm_mode_status Enum
+ */
+enum drm_mode_status drm_connector_mode_valid(struct drm_connector *connector,
+ struct drm_display_mode *mode)
+{
+   const struct drm_connector_helper_funcs *connector_funcs =
+   connector->helper_private;
+
+   if (!connector_funcs || !connector_funcs->mode_valid)
+   return MODE_OK;
+
+   return connector_funcs->mode_valid(connector, mode);
+}
+EXPORT_SYMBOL(drm_connector_mode_valid);
diff --git a/drivers/gpu/drm/drm_crtc_internal.h 
b/drivers/gpu/drm/drm_crtc_internal.h
index 6165bc9..018b154 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -146,6 +146,8 @@ int drm_mode_connector_set_obj_prop(struct drm_mode_object 
*obj,
uint64_t value);
 int drm_connector_create_standard_properties(struct drm_device *dev);
 const char *drm_get_connector_force_name(enum drm_connector_force force);
+enum drm_mode_status drm_connector_mode_valid(struct drm_connector *connector,
+ struct drm_display_mode *mode);
 
 /* IOCTL */
 int drm_mode_connector_property_set_ioctl(struct drm_device *dev,
-- 
1.9.1


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

Re: [PATCH v2 00/29] Remove the omapdrm and omapdss devices from platform code

[Tony Lindgren]

* Tomi Valkeinen  [170509 04:56]:
> On 08/05/17 20:07, Tony Lindgren wrote:
> > * Laurent Pinchart  [170508 04:36]:
> >> The next step is to remove the omapdss platform driver (for the virtual
> >> omapdss platform device, also known as core code, not to be confused with 
> >> the
> >> omapdss_dss driver for the DSS hardware device). Patches 21/28 to 23/28 
> >> move
> >> the useful features of the core to the omapdss_dss driver. Patch 24/28 adds
> >> omapdrm platform device registration to the omapdss_dss driver to replace
> >> board code, and patch 25/28 finally removes the omapdss platform driver.
> >>
> >> Note that registering the omapdrm platform device from within the 
> >> omapdss_dss
> >> driver is a hack, but isn't worse than the current situation. Quite the
> >> contrary, given that the omapdrm device exists for the sole purpose of
> >> supporting the omapdrm/omapdss driver architecture, moving it out of 
> >> platform
> >> code can be considered as (slightly) cleaner. In any case, it will be 
> >> easier
> >> to refactor the code as everything is now isolated on the driver side.
> > 
> > Good to see this happening. While at it, can you please also check that
> > the struct device entries follow what's in the hardware to avoid more
> > headaches later on.
> 
> This has been the case for many years. We've just had some extra stuff
> on top, due to legacy reasons (from time before hwmods).

OK thanks for confirming that.

Tony



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

[PATCH v3 2/2] v4l: vsp1: Provide a writeback video device

[Kieran Bingham]

When the VSP1 is used in an active display pipeline, the output of the
WPF can supply the LIF entity directly and simultaneously write to
memory.

Support this functionality in the VSP1 driver, by extending the WPF
source pads, and establishing a V4L2 video device node connected to the
new source.

The source will be able to perform pixel format conversion, but not
rescaling, and as such the output from the memory node will always be
of the same dimensions as the display output.

Signed-off-by: Kieran Bingham 

---
Changes since RFC
 - Fix checkpatch.pl warnings
 - Adapt to use a single source pad for the Writeback and LIF
 - Use WPF properties to determine when to create links instead of VSP
 - Remove incorrect vsp1_video_verify_format() changes
 - Spelling and grammar fixes

 - Rebased to v4.12-rc1
---
 drivers/media/platform/vsp1/vsp1.h   |   1 +-
 drivers/media/platform/vsp1/vsp1_drm.c   |  18 +++-
 drivers/media/platform/vsp1/vsp1_drv.c   |   5 +-
 drivers/media/platform/vsp1/vsp1_rwpf.h  |   1 +-
 drivers/media/platform/vsp1/vsp1_video.c | 150 +++-
 drivers/media/platform/vsp1/vsp1_video.h |   5 +-
 drivers/media/platform/vsp1/vsp1_wpf.c   |  19 ++-
 7 files changed, 192 insertions(+), 7 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1.h 
b/drivers/media/platform/vsp1/vsp1.h
index 85387a64179a..a2d462264312 100644
--- a/drivers/media/platform/vsp1/vsp1.h
+++ b/drivers/media/platform/vsp1/vsp1.h
@@ -54,6 +54,7 @@ struct vsp1_uds;
 #define VSP1_HAS_WPF_HFLIP (1 << 6)
 #define VSP1_HAS_HGO   (1 << 7)
 #define VSP1_HAS_HGT   (1 << 8)
+#define VSP1_HAS_WPF_WRITEBACK (1 << 9)
 
 struct vsp1_device_info {
u32 version;
diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index 9d235e830f5a..539890b27864 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -25,6 +25,7 @@
 #include "vsp1_lif.h"
 #include "vsp1_pipe.h"
 #include "vsp1_rwpf.h"
+#include "vsp1_video.h"
 
 
 /* 
-
@@ -483,6 +484,13 @@ void vsp1_du_atomic_flush(struct device *dev)
__func__, rpf->entity.index);
}
 
+   /*
+* If we have a writeback node attached, we use this opportunity to
+* update the video buffers.
+*/
+   if (pipe->output->video && pipe->output->video->frame_end)
+   pipe->output->video->frame_end(pipe);
+
/* Configure all entities in the pipeline. */
list_for_each_entry(entity, >entities, list_pipe) {
/* Disconnect unused RPFs from the pipeline. */
@@ -572,6 +580,16 @@ int vsp1_drm_create_links(struct vsp1_device *vsp1)
if (ret < 0)
return ret;
 
+   if (vsp1->wpf[0]->has_writeback) {
+   /* Connect the video device to the WPF for Writeback support */
+   ret = media_create_pad_link(>wpf[0]->entity.subdev.entity,
+   RWPF_PAD_SOURCE,
+   >wpf[0]->video->video.entity,
+   0, flags);
+   if (ret < 0)
+   return ret;
+   }
+
return 0;
 }
 
diff --git a/drivers/media/platform/vsp1/vsp1_drv.c 
b/drivers/media/platform/vsp1/vsp1_drv.c
index 048446af5ae7..240045e82cc2 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -411,7 +411,7 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
vsp1->wpf[i] = wpf;
list_add_tail(>entity.list_dev, >entities);
 
-   if (vsp1->info->uapi) {
+   if (vsp1->info->uapi || wpf->has_writeback) {
struct vsp1_video *video = vsp1_video_create(vsp1, wpf);
 
if (IS_ERR(video)) {
@@ -709,7 +709,8 @@ static const struct vsp1_device_info vsp1_device_infos[] = {
.version = VI6_IP_VERSION_MODEL_VSPD_GEN3,
.model = "VSP2-D",
.gen = 3,
-   .features = VSP1_HAS_BRU | VSP1_HAS_LIF | VSP1_HAS_WPF_VFLIP,
+   .features = VSP1_HAS_BRU | VSP1_HAS_LIF | VSP1_HAS_WPF_VFLIP
+ | VSP1_HAS_WPF_WRITEBACK,
.rpf_count = 5,
.wpf_count = 2,
.num_bru_inputs = 5,
diff --git a/drivers/media/platform/vsp1/vsp1_rwpf.h 
b/drivers/media/platform/vsp1/vsp1_rwpf.h
index 58215a7ab631..d26a92cd5c7d 100644
--- a/drivers/media/platform/vsp1/vsp1_rwpf.h
+++ b/drivers/media/platform/vsp1/vsp1_rwpf.h
@@ -53,6 +53,7 @@ struct vsp1_rwpf {
 
u32 mult_alpha;
u32 outfmt;
+   bool has_writeback;
 
struct {
spinlock_t lock;
diff --git a/drivers/media/platform/vsp1/vsp1_video.c 
b/drivers/media/platform/vsp1/vsp1_video.c
index 

[PATCH v6 8/9] drm: Add definition for eDP backlight frequency

[Puthikorn Voravootivat]

This patch adds the following definition
- Bit mask for EDP_PWMGEN_BIT_COUNT and min/max cap
  register which only use bit 0:4
- Base frequency (27 MHz) for backlight PWM frequency
  generator.

Signed-off-by: Puthikorn Voravootivat 
---
 include/drm/drm_dp_helper.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index c0bd0d7651a9..810b7d5d9f2b 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -572,10 +572,12 @@
 #define DP_EDP_PWMGEN_BIT_COUNT 0x724
 #define DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN 0x725
 #define DP_EDP_PWMGEN_BIT_COUNT_CAP_MAX 0x726
+# define  DP_EDP_PWMGEN_BIT_COUNT_MASK  (0x1f << 0)
 
 #define DP_EDP_BACKLIGHT_CONTROL_STATUS 0x727
 
 #define DP_EDP_BACKLIGHT_FREQ_SET   0x728
+# define DP_EDP_BACKLIGHT_FREQ_BASE 2700
 
 #define DP_EDP_BACKLIGHT_FREQ_CAP_MIN_MSB   0x72a
 #define DP_EDP_BACKLIGHT_FREQ_CAP_MIN_MID   0x72b
-- 
2.13.0.rc2.291.g57267f2277-goog

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

[PATCH v2 1/8] drm: Add crtc/encoder/bridge->mode_valid() callbacks

[Jose Abreu]

This adds a new callback to crtc, encoder and bridge helper functions
called mode_valid(). This callback shall be implemented if the
corresponding component has some sort of restriction in the modes
that can be displayed. A NULL callback implicates that the component
can display all the modes.

We also change the description of connector->mode_valid() callback
so that it matches the existing behaviour: It is never called in
atomic check phase.

Only the callbacks were implemented to simplify review process,
following patches will make use of them.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Alexey Brodkin 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Dave Airlie 
Cc: Andrzej Hajda 
Cc: Archit Taneja 
---

Changes v1->v2:
- Change description of connector->mode_valid() (Daniel)

 include/drm/drm_bridge.h | 20 ++
 include/drm/drm_modeset_helper_vtables.h | 45 
 2 files changed, 65 insertions(+)

diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index fdd82fc..00c6c36 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -59,6 +59,26 @@ struct drm_bridge_funcs {
void (*detach)(struct drm_bridge *bridge);
 
/**
+* @mode_valid:
+*
+* This callback is used to check if a specific mode is valid in this
+* bridge. This should be implemented if the bridge has some sort of
+* restriction in the modes it can display. For example, a given bridge
+* may be responsible to set a clock value. If the clock can not
+* produce all the values for the available modes then this callback
+* can be used to restrict the number of modes to only the ones that
+* can be displayed.
+*
+* This is called at mode probe and at atomic check phase.
+*
+* RETURNS:
+*
+* drm_mode_status Enum
+*/
+   enum drm_mode_status (*mode_valid)(struct drm_bridge *crtc,
+  const struct drm_display_mode *mode);
+
+   /**
 * @mode_fixup:
 *
 * This callback is used to validate and adjust a mode. The paramater
diff --git a/include/drm/drm_modeset_helper_vtables.h 
b/include/drm/drm_modeset_helper_vtables.h
index c01c328..eec2c70 100644
--- a/include/drm/drm_modeset_helper_vtables.h
+++ b/include/drm/drm_modeset_helper_vtables.h
@@ -106,6 +106,26 @@ struct drm_crtc_helper_funcs {
void (*commit)(struct drm_crtc *crtc);
 
/**
+* @mode_valid:
+*
+* This callback is used to check if a specific mode is valid in this
+* crtc. This should be implemented if the crtc has some sort of
+* restriction in the modes it can display. For example, a given crtc
+* may be responsible to set a clock value. If the clock can not
+* produce all the values for the available modes then this callback
+* can be used to restrict the number of modes to only the ones that
+* can be displayed.
+*
+* This is called at mode probe and at atomic check phase.
+*
+* RETURNS:
+*
+* drm_mode_status Enum
+*/
+   enum drm_mode_status (*mode_valid)(struct drm_crtc *crtc,
+  const struct drm_display_mode *mode);
+
+   /**
 * @mode_fixup:
 *
 * This callback is used to validate a mode. The parameter mode is the
@@ -457,6 +477,26 @@ struct drm_encoder_helper_funcs {
void (*dpms)(struct drm_encoder *encoder, int mode);
 
/**
+* @mode_valid:
+*
+* This callback is used to check if a specific mode is valid in this
+* encoder. This should be implemented if the encoder has some sort
+* of restriction in the modes it can display. For example, a given
+* encoder may be responsible to set a clock value. If the clock can
+* not produce all the values for the available modes then this callback
+* can be used to restrict the number of modes to only the ones that
+* can be displayed.
+*
+* This is called at mode probe and at atomic check phase.
+*
+* RETURNS:
+*
+* drm_mode_status Enum
+*/
+   enum drm_mode_status (*mode_valid)(struct drm_encoder *crtc,
+  const struct drm_display_mode *mode);
+
+   /**
 * @mode_fixup:
 *
 * This callback is used to validate and adjust a mode. The parameter
@@ -795,6 +835,11 @@ struct drm_connector_helper_funcs {
 * (which is usually derived from the EDID data block from the sink).
 * See e.g. drm_helper_probe_single_connector_modes().
   

[PATCH v2 7/8] drm: Use mode_valid() in atomic modeset

[Jose Abreu]

This patches makes use of the new mode_valid() callbacks introduced
previously to validate the full video pipeline when modesetting.

This calls the connector->mode_valid(), encoder->mode_valid(),
bridge->mode_valid() and crtc->mode_valid() so that we can
make sure that the mode will be accepted in every components.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Alexey Brodkin 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Dave Airlie 
Cc: Andrzej Hajda 
Cc: Archit Taneja 
---

Changes v1->v2:
- Removed call to connector->mode_valid (Ville, Daniel)
- Change function name (Ville)
- Use for_each_new_connector_in_state (Ville)
- Do not validate if connector and mode didn't change (Ville)
- Use new helpers to call mode_valid

 drivers/gpu/drm/drm_atomic_helper.c | 75 +++--
 1 file changed, 72 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 8be9719..19d0ea1 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -452,6 +452,69 @@ static int handle_conflicting_encoders(struct 
drm_atomic_state *state,
return 0;
 }
 
+static enum drm_mode_status mode_valid_path(struct drm_connector *connector,
+   struct drm_encoder *encoder,
+   struct drm_crtc *crtc,
+   struct drm_display_mode *mode)
+{
+   enum drm_mode_status ret;
+
+   ret = drm_encoder_mode_valid(encoder, mode);
+   if (ret != MODE_OK) {
+   DRM_DEBUG_ATOMIC("[ENCODER:%d:%s] mode_valid() failed\n",
+   encoder->base.id, encoder->name);
+   return ret;
+   }
+
+   ret = drm_bridge_mode_valid(encoder->bridge, mode);
+   if (ret != MODE_OK) {
+   DRM_DEBUG_ATOMIC("[BRIDGE] mode_valid() failed\n");
+   return ret;
+   }
+
+   ret = drm_crtc_mode_valid(crtc, mode);
+   if (ret != MODE_OK) {
+   DRM_DEBUG_ATOMIC("[CRTC:%d:%s] mode_valid() failed\n",
+   crtc->base.id, crtc->name);
+   return ret;
+   }
+
+   return ret;
+}
+
+static int
+mode_valid(struct drm_atomic_state *state)
+{
+   struct drm_connector_state *conn_state;
+   struct drm_connector *connector;
+   int i;
+
+   for_each_new_connector_in_state(state, connector, conn_state, i) {
+   struct drm_encoder *encoder = conn_state->best_encoder;
+   struct drm_crtc *crtc = conn_state->crtc;
+   struct drm_crtc_state *crtc_state;
+   enum drm_mode_status mode_status;
+   struct drm_display_mode *mode;
+
+   if (!crtc || !encoder)
+   continue;
+
+   crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
+   if (!crtc_state)
+   continue;
+   if (!crtc_state->mode_changed && 
!crtc_state->connectors_changed)
+   continue;
+
+   mode = _state->mode;
+
+   mode_status = mode_valid_path(connector, encoder, crtc, mode);
+   if (mode_status != MODE_OK)
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
 /**
  * drm_atomic_helper_check_modeset - validate state object for modeset changes
  * @dev: DRM device
@@ -466,13 +529,15 @@ static int handle_conflicting_encoders(struct 
drm_atomic_state *state,
  * 2. _connector_helper_funcs.atomic_check to validate the connector state.
  * 3. If it's determined a modeset is needed then all connectors on the 
affected crtc
  *crtc are added and _connector_helper_funcs.atomic_check is run on 
them.
- * 4. _bridge_funcs.mode_fixup is called on all encoder bridges.
- * 5. _encoder_helper_funcs.atomic_check is called to validate any encoder 
state.
+ * 4. _encoder_helper_funcs.mode_valid, _bridge_funcs.mode_valid and
+ *_crtc_helper_funcs.mode_valid are called on the affected components.
+ * 5. _bridge_funcs.mode_fixup is called on all encoder bridges.
+ * 6. _encoder_helper_funcs.atomic_check is called to validate any encoder 
state.
  *This function is only called when the encoder will be part of a 
configured crtc,
  *it must not be used for implementing connector property validation.
  *If this function is NULL, _atomic_encoder_helper_funcs.mode_fixup is 
called
  *instead.
- * 6. _crtc_helper_funcs.mode_fixup is called last, to fix up the mode 
with crtc constraints.
+ * 7. _crtc_helper_funcs.mode_fixup is called last, to fix up the mode 
with crtc constraints.
  *
  * _crtc_state.mode_changed is set when the input mode is changed.
  * 

Re: [PATCH v2 00/29] Remove the omapdrm and omapdss devices from platform code

[Sebastian Reichel]

Hi,

On Tue, May 09, 2017 at 03:10:40PM +0300, Tomi Valkeinen wrote:
> On 08/05/17 14:32, Laurent Pinchart wrote:
> > Hello,
> > 
> > This patch series is a second, extended version of the code previously 
> > posted
> > as "[PATCH/RFC 0/7] Remove the omapdrm device from platform code".
> 
> As this is a long series, I'd like to pick a bunch of patches from this
> series already:
> 
> 1-5, 7, 19, 21.

I can't reply directly, since I was not subscribed to dri-devel when
this was sent, but I also noticed, the incorrect pattern in patch 1:

foo = devm_ioremap_resource(...)
if (!foo)
return -ENOMEM;

The same pattern is in patch 2, so you may want a PATCHv2 of that
one first. Also I have a few more notes:

patch 10:
I think dsi pin muxing should be done by providing pinmux
info via DT.

patch 11:
There is a typo in the comment "can be told apart" => "can't be told
apart".

patch 21:
As far as I can see dss.h contains an empty #if
defined(CONFIG_OMAP2_DSS_DEBUGFS) after the patch.

> I didn't test yet, but I think those should not cause conflicts with the
> rest of the series.
> 
> I can then push the branch, which contains also the fences and cache
> patches, so you can base the rest on that.
> 
> Is this ok?

-- Sebastian


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

Re: [PATCH v2] drm/vc4: Enable selection in Kconfig on any 32-bit BCM platform.

[Florian Fainelli]

On 05/09/2017 11:15 AM, Eric Anholt wrote:
> With the Cygnus port, we needed to add at least "|| ARCH_BCM_CYGNUS"
> to let the module get built on a cygnus-only kernel.  However, I
> anticipate having a port for Kona soon, so just present the module on
> all of BCM.
> 
> v2: Keep allowing selection with ARCH_BCM2835, since ARCH_BCM doesn't
> exist on arm64.

Nit: the patch changelog usually goes after the "---" line so it gets
stripped with git am. Not necessary to resubmit just because of that.

> 
> Signed-off-by: Eric Anholt 
> Acked-by: Daniel Vetter  (v1)

Acked-by: Florian Fainelli 

> ---
>  drivers/gpu/drm/vc4/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/vc4/Kconfig b/drivers/gpu/drm/vc4/Kconfig
> index 973b4203c0b2..b16aefe4a8d3 100644
> --- a/drivers/gpu/drm/vc4/Kconfig
> +++ b/drivers/gpu/drm/vc4/Kconfig
> @@ -1,6 +1,6 @@
>  config DRM_VC4
>   tristate "Broadcom VC4 Graphics"
> - depends on ARCH_BCM2835 || COMPILE_TEST
> + depends on ARCH_BCM || ARCH_BCM2835 || COMPILE_TEST
>   depends on DRM
>   depends on SND && SND_SOC
>   depends on COMMON_CLK
> 


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

[PATCH v2 6/8] drm: Introduce drm_bridge_mode_valid()

[Jose Abreu]

Introduce a new helper function which calls mode_valid() callback
for all bridges in an encoder chain.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Alexey Brodkin 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Dave Airlie 
Cc: Andrzej Hajda 
Cc: Archit Taneja 
---
 drivers/gpu/drm/drm_bridge.c | 33 +
 include/drm/drm_bridge.h |  2 ++
 2 files changed, 35 insertions(+)

diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 86a7637..dc8cdfe 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -206,6 +206,39 @@ bool drm_bridge_mode_fixup(struct drm_bridge *bridge,
 EXPORT_SYMBOL(drm_bridge_mode_fixup);
 
 /**
+ * drm_bridge_mode_valid - validate the mode against all bridges in the
+ *encoder chain.
+ * @bridge: bridge control structure
+ * @mode: desired mode to be validated
+ *
+ * Calls _bridge_funcs.mode_valid for all the bridges in the encoder
+ * chain, starting from the first bridge to the last. If at least one bridge
+ * does not accept the mode the function returns the error code.
+ *
+ * Note: the bridge passed should be the one closest to the encoder.
+ *
+ * RETURNS:
+ * MODE_OK on success, drm_mode_status Enum error code on failure
+ */
+enum drm_mode_status drm_bridge_mode_valid(struct drm_bridge *bridge,
+  const struct drm_display_mode *mode)
+{
+   enum drm_mode_status ret = MODE_OK;
+
+   if (!bridge)
+   return ret;
+
+   if (bridge->funcs->mode_valid)
+   ret = bridge->funcs->mode_valid(bridge, mode);
+
+   if (ret != MODE_OK)
+   return ret;
+
+   return drm_bridge_mode_valid(bridge->next, mode);
+}
+EXPORT_SYMBOL(drm_bridge_mode_valid);
+
+/**
  * drm_bridge_disable - disables all bridges in the encoder chain
  * @bridge: bridge control structure
  *
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 00c6c36..8358eb3 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -233,6 +233,8 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct 
drm_bridge *bridge,
 bool drm_bridge_mode_fixup(struct drm_bridge *bridge,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode);
+enum drm_mode_status drm_bridge_mode_valid(struct drm_bridge *bridge,
+  const struct drm_display_mode *mode);
 void drm_bridge_disable(struct drm_bridge *bridge);
 void drm_bridge_post_disable(struct drm_bridge *bridge);
 void drm_bridge_mode_set(struct drm_bridge *bridge,
-- 
1.9.1


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

Re: [PATCH v2] drm/vc4: Enable selection in Kconfig on any 32-bit BCM platform.

[Eric Anholt]

Florian Fainelli  writes:

> On 05/09/2017 11:15 AM, Eric Anholt wrote:
>> With the Cygnus port, we needed to add at least "|| ARCH_BCM_CYGNUS"
>> to let the module get built on a cygnus-only kernel.  However, I
>> anticipate having a port for Kona soon, so just present the module on
>> all of BCM.
>> 
>> v2: Keep allowing selection with ARCH_BCM2835, since ARCH_BCM doesn't
>> exist on arm64.
>
> Nit: the patch changelog usually goes after the "---" line so it gets
> stripped with git am. Not necessary to resubmit just because of that.

Behavior on that front differs between subsystems.  DRM is one where the
changelog is generally retained.


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

Re: [PATCH v3 4/5] drm: convert drivers to use drm_of_find_panel_or_bridge

[Rob Herring]

On Tue, May 9, 2017 at 9:28 AM, Leonard Crestez  wrote:
> On Wed, Mar 22, 2017 at 5:01 PM, Philipp Zabel  wrote:
>> On Wed, 2017-03-22 at 08:26 -0500, Rob Herring wrote:
>> >
>> > Similar to the previous commit, convert drivers open coding OF graph
>> > parsing to use drm_of_find_panel_or_bridge instead.
>> >
>> > This changes some error messages to debug messages (in the graph core).
>> > Graph connections are often "no connects" depending on the particular
>> > board, so we want to avoid spurious messages. Plus the kernel is not a
>> > DT validator.
>> >
>> > Signed-off-by: Rob Herring 
>> > Reviewed-by: Archit Taneja 
>> Tested-by: Philipp Zabel 
>> (imx-ldb on i.MX6)
>
> It seems that this breaks on (at least) imx6qdl-sabreauto. The relevant
> section of the boot log looks like this:
>
> imx-drm display-subsystem: bound imx-ipuv3-crtc.2 (ops ipu_crtc_ops)
> imx-drm display-subsystem: bound imx-ipuv3-crtc.3 (ops ipu_crtc_ops)
> dwhdmi-imx 12.hdmi: Detected HDMI TX controller v1.31a with HDCP
> (DWC HDMI 3D TX PHY)
> dwhdmi-imx 12.hdmi: registered DesignWare HDMI I2C bus driver
> imx-drm display-subsystem: bound 12.hdmi (ops dw_hdmi_imx_ops)
> imx-drm display-subsystem: failed to bind 200.aips-bus:ldb (ops
> imx_ldb_ops): -19
> imx-drm display-subsystem: master bind failed: -19
>
> It seems that imx6qdl-sabreauto does not have any panel defined in dts.
> This used to be ignored when of_graph_get_endpoint_by_regs returned
> NULL but now drm_of_find_panel_or_bridge returns -ENODEV and this
> causes imx_ldb_bind to fail altogether. Defining a panel works
> (including showing stuff on a LVDS panel). Ignoring -ENODEV also fixes
> this:
>
> --- drivers/gpu/drm/imx/imx-ldb.c
> +++ drivers/gpu/drm/imx/imx-ldb.c
> @@ -673,7 +673,7 @@ static int imx_ldb_bind(struct device *dev, struct device 
> *master, void *data)
> ret = drm_of_find_panel_or_bridge(child,
>   imx_ldb->lvds_mux ? 4 : 2, 
> 0,
>   >panel, 
> >bridge);
> -   if (ret)
> +   if (ret != -ENODEV)
> return ret;
>
> /* panel ddc only if there is no bridge */
>
> I don't know much about drm and it's not clear if failing to find a
> panel should be an error here or not and the hack above is likely the
> wrong way to handle it anyway.

That looks like the right fix to me. Ideally, the DT should probably
define an LVDS connector node (if not a panel) in this case like we do
for other cases with DDC, but more importantly we shouldn't require a
DT update to fix things. If you needed power or gpio controls of the
panel you would also need some node in DT.

Do you mind sending a proper patch?

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

Re: [PATCH 1/6 v2] drm/omap: add new connector types

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Tuesday 09 May 2017 10:16:27 Tomi Valkeinen wrote:
> We have been using DRM_MODE_CONNECTOR_Unknown for many of our outputs
> because there has not been a proper connector type for them.
> 
> We now have connector type for DPI so let's take it into use. At the
> same time, add better connector types for the remaining outputs too.
> 
> This patch sets the following outputs to use the following connector
> types:
> 
> DPI -> DPI
> DBI -> DPI (MIPI DBI is very similar to DPI at the bus level)
> SDI -> LVDS (SDI, TI Flatlink 3G, is a type of LVDS)
> VENC -> SVIDEO (it could also be composite, but we don't have that
> information here, so svideo should be quite good match)
> 
> Signed-off-by: Tomi Valkeinen 
> ---
>  drivers/gpu/drm/omapdrm/omap_drv.c | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
> b/drivers/gpu/drm/omapdrm/omap_drv.c index e1f47f0b3ccf..16c537837742
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> @@ -214,6 +214,19 @@ static int get_connector_type(struct omap_dss_device
> *dssdev) return DRM_MODE_CONNECTOR_DVID;
>   case OMAP_DISPLAY_TYPE_DSI:
>   return DRM_MODE_CONNECTOR_DSI;
> + case OMAP_DISPLAY_TYPE_DPI:
> + case OMAP_DISPLAY_TYPE_DBI:
> + return DRM_MODE_CONNECTOR_DPI;
> + case OMAP_DISPLAY_TYPE_VENC:
> + if (of_device_is_compatible(dssdev->dev->of_node,
> + "omapdss,svideo-connector"))
> + return DRM_MODE_CONNECTOR_SVIDEO;
> + if (of_device_is_compatible(dssdev->dev->of_node,
> + "omapdss,composite-video-connector"))
> + return DRM_MODE_CONNECTOR_Composite;

Checking the compat string here feels like a bit of a hack to me. Wouldn't it 
be simpler and cleaner to add the connector type to the omap_dss_device 
structure ? That's more work though, so as a first step I think I could 
tolerate this hack if you really feel lazy ;-) Although, maybe we should just 
return SVIDEO unconditionally for VENC for now and fix that later.

> + return DRM_MODE_CONNECTOR_Unknown;
> + case OMAP_DISPLAY_TYPE_SDI:
> + return DRM_MODE_CONNECTOR_LVDS;
>   default:
>   return DRM_MODE_CONNECTOR_Unknown;
>   }

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v2 08/28] drm: omapdrm: dpi: Replace OMAP SoC model checks with DSS device type

[Laurent Pinchart]

Hi Tomi,

On Wednesday 10 May 2017 01:24:52 Laurent Pinchart wrote:
> On Tuesday 09 May 2017 12:23:13 Tomi Valkeinen wrote:
> > On 08/05/17 14:32, Laurent Pinchart wrote:
> > > The DPI code only needs to differentiate between major OMAP revisions,
> > > which can be obtained from the DSS compatible string. Replace the OMAP
> > > SoC model checks to prepare for removal of the OMAP SoC version platform
> > > data.
> > > 
> > > Signed-off-by: Laurent Pinchart 
> > > ---
> > > 
> > >  drivers/gpu/drm/omapdrm/dss/dpi.c | 59
> > >  ++
> > >  drivers/gpu/drm/omapdrm/dss/dss.c | 10 ++-
> > >  drivers/gpu/drm/omapdrm/dss/dss.h | 13 +++--
> > >  3 files changed, 45 insertions(+), 37 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/omapdrm/dss/dpi.c
> > > b/drivers/gpu/drm/omapdrm/dss/dpi.c index 3d87f3af72bb..b5cb23c167db
> > > 100644
> > > --- a/drivers/gpu/drm/omapdrm/dss/dpi.c
> > > +++ b/drivers/gpu/drm/omapdrm/dss/dpi.c
> > > @@ -39,6 +39,7 @@
> > > 
> > >  struct dpi_data {
> > >  
> > >   struct platform_device *pdev;
> > > 
> > > + enum dss_device_type type;
> > 
> > I really don't like "dss_device_type" or "type" here... "dss_version"?
> > Or maybe it should be tied to DPI, so "dpi_version"?
> 
> I don't think it should be tied to the DPI, as it's really the DSS version
> that matters here. I'll rename dss_device_type to dss_version.

Thinking about it again, how about dss_model ?

> Note that I don't think the type field should be stored in the dpi_data
> structure. It should be part of the dss structure, which should become
> visible to the DPI code. I plan to rework the driver in this direction, but
> in the meantime I think we could merge this patch (after renaming the enum)
> as it doesn't make the current situation any worse.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v2 08/28] drm: omapdrm: dpi: Replace OMAP SoC model checks with DSS device type

[Laurent Pinchart]

Hi Tomi,

On Tuesday 09 May 2017 12:23:13 Tomi Valkeinen wrote:
> On 08/05/17 14:32, Laurent Pinchart wrote:
> > The DPI code only needs to differentiate between major OMAP revisions,
> > which can be obtained from the DSS compatible string. Replace the OMAP
> > SoC model checks to prepare for removal of the OMAP SoC version platform
> > data.
> > 
> > Signed-off-by: Laurent Pinchart 
> > ---
> > 
> >  drivers/gpu/drm/omapdrm/dss/dpi.c | 59 ++
> >  drivers/gpu/drm/omapdrm/dss/dss.c | 10 ++-
> >  drivers/gpu/drm/omapdrm/dss/dss.h | 13 +++--
> >  3 files changed, 45 insertions(+), 37 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/omapdrm/dss/dpi.c
> > b/drivers/gpu/drm/omapdrm/dss/dpi.c index 3d87f3af72bb..b5cb23c167db
> > 100644
> > --- a/drivers/gpu/drm/omapdrm/dss/dpi.c
> > +++ b/drivers/gpu/drm/omapdrm/dss/dpi.c
> > @@ -39,6 +39,7 @@
> > 
> >  struct dpi_data {
> > struct platform_device *pdev;
> > +   enum dss_device_type type;
> 
> I really don't like "dss_device_type" or "type" here... "dss_version"?
> Or maybe it should be tied to DPI, so "dpi_version"?

I don't think it should be tied to the DPI, as it's really the DSS version 
that matters here. I'll rename dss_device_type to dss_version.

Note that I don't think the type field should be stored in the dpi_data 
structure. It should be part of the dss structure, which should become visible 
to the DPI code. I plan to rework the driver in this direction, but in the 
meantime I think we could merge this patch (after renaming the enum) as it 
doesn't make the current situation any worse.

-- 
Regards,

Laurent Pinchart

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

Re: [rfc] drm sync objects (search for spock)

[Jason Ekstrand]

On Wed, Apr 26, 2017 at 7:57 AM, Christian König 
wrote:

> Am 26.04.2017 um 11:57 schrieb Dave Airlie:
>
>> On 26 April 2017 at 18:45, Christian König 
>> wrote:
>>
>>> Am 26.04.2017 um 05:28 schrieb Dave Airlie:
>>>
 Okay I've gone around the sun with these a few times, and
 pretty much implemented what I said last week.

 This is pretty much a complete revamp.

 1. sync objects are self contained drm objects, they
 have a file reference so can be passed between processes.

 2. Added a sync object wait interface modelled on the vulkan
 fence waiting API.

 3. sync_file interaction is explicitly different than
 opaque fd passing, you import a sync file state into an
 existing syncobj, or create a new sync_file from an
 existing syncobj. This means no touching the sync file code
 at all. \o/

>>>
I've done a quick scan over the patches and I like the API.  It almost
looks as if Santa read my wish list. :-)

That said, it was a "quick scan" so don't take this as any sort of actual
code review.  It'll probably be a little while before I get a chance to sit
down and look at i915 again but things seem reasonable.


> Doesn't that break the Vulkan requirement that if a sync_obj is exported to
>>> an fd and imported on the other side we get the same sync_obj again?
>>>
>>> In other words the fd is exported and imported only once and the
>>> expectation
>>> is that we fence containing it will change on each signaling operation.
>>>
>>> As far as I can see with the current implementation you get two
>>> sync_objects
>>> on in the exporting process and one in the importing one.
>>>
>> Are you talking about using sync_file interop for vulkan, then yes
>> that would be wrong.
>>
>> But that isn't how this works, see 1. above the sync obj has a 1:1
>> mapping with an
>> opaque fd (non-sync_file) that is only used for interprocess passing
>> of the syncobj.
>>
>
> Ah, ok that makes some more sense.
>
> You can interoperate with sync_files by importing/exporting the
>> syncobj fence into
>> and out of them but that aren't meant for passing the fds around, more
>> for where you
>> get a sync_file fd from somewhere else and you want to use it and
>> vice-versa.
>>
>
> I would prefer dealing only with one type of fd in userspace, but that
> approach should work as well.
>
> I'd like to move any drm APIs away from sync_file to avoid the fd wastages,
>>
>
> That sounds like it make sense, but I would still rather vote for
> extending the sync_file interface than deprecating it with another one.
>
> I'd also like to move the driver specific fences to syncobj where I can.
>>
>
> I'm pretty sure that is not a good idea.
>
> Beating the sequence based fence values we currently use for CPU sync in
> performance would be pretty hard. E.g. at least on amdgpu we can even check
> those by doing a simple 64bit read from a memory address, without IOCTL or
> any other overhead involved.
>
> Regards,
> Christian.
>
>
>
>> Dave.
>>
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 00/29] Remove the omapdrm and omapdss devices from platform code

[Laurent Pinchart]

Hi Tomi,

On Tuesday 09 May 2017 15:10:40 Tomi Valkeinen wrote:
> On 08/05/17 14:32, Laurent Pinchart wrote:
> > Hello,
> > 
> > This patch series is a second, extended version of the code previously
> > posted as "[PATCH/RFC 0/7] Remove the omapdrm device from platform code".
> As this is a long series, I'd like to pick a bunch of patches from this
> series already:
> 
> 1-5, 7, 19, 21.
> 
> I didn't test yet, but I think those should not cause conflicts with the
> rest of the series.
> 
> I can then push the branch, which contains also the fences and cache
> patches, so you can base the rest on that.
> 
> Is this ok?

Patch 21 will conflict, the other ones shouldn't. For your convenience I've 
picked all the Reviewed-by tags, fixed a typo in patch 01/28 that broke 
compilation, rebased the patches with 1-5, 7 and 19 moved to the beginning of 
the series, tested the result and pushed it to

git://linuxtv.org/pinchartl/media.git omapdrm/platform

You can just pick the 7 first patches from there.

-- 
Regards,

Laurent Pinchart

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

[Bug 100306] System randomly freezes or crashes to the login screen, glitches until rebooted

[bugzilla-daemon]

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

--- Comment #20 from MirceaKitsune  ---
The same freeze happened again today, after a two week period of not seeing the
problem any more. This is reaching the point where it's becoming outright
ridiculous: I've used openSUSE for years, and have never seen such a thing
spanning over such a long time period.

Unfortunately I can't risk breaking my system by installing custom versions of
llvm or the system wide Mesa. I can only hope the developers know what to
bisect to find out where this fault lies, based on the logs I've attached here.
Let me know if there is more info I could somehow help with.

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

Re: [PATCH v2 23/28] drm: omapdrm: Merge the dss_features and omap_dss_features structures

[Laurent Pinchart]

Hi Tomi,

On Tuesday 09 May 2017 15:02:36 Tomi Valkeinen wrote:
> On 08/05/17 14:32, Laurent Pinchart wrote:
> > Both structures describe features of a particular OMAP DSS version,
> > there's no reason to keep them separate. Merge them together, allowing
> > initialization of the features based on the DSS compatible string
> > instead of the OMAP SoC version.
> 
> I don't think this is the correct way. As I mentioned earlier,
> dss_features should go. We should work on moving the parts from
> dss_features to each individual driver. I think there are probably only
> a very few dss-features that need to be accessed by multiple files, and
> those features could have a function of their own to query them.

I don't disagree with that, but can't we do so on top of this series ? I don't 
think that these patches make the situation worse.

> But that may also be a bit bigger work, so... I thought about it already
> earlier in this series: wouldn't it be easier to first reconstruct the
> current OMAPDSS_VER_* with soc_device_match(), at module init time,
> which would allow us to keep most of the omapdss side unchanged. Then
> continue removing the arch/arm/ stuff.

I considered that to start with, but decided it was really a hack. I instead 
went for cleaning things up where possible, and keeping hacks where a proper 
rework would require a set of new patch series. The result is a balance 
between a few hacks and lots of cleanup patches, which I considered was right 
when I realized that the series was already 28 patches long.

> When that's done and merged, we could have follow up patches later to
> clean up dss_features, and add version handling to each driver, however
> is best in that particular file.
> 
> I feel that this series is perhaps doing a bit too much at once.

Then let's not add more ;-) More seriously, as lots of cleanups are here 
already, I think we should merge them. If there's any hack that you believe 
goes in the wrong direction and would make a proper rework more complex, let's 
discuss them. Otherwise, for the ones that either are too small improvements, 
or just keep the status quo, I plan to rework them later.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 1/5] drm: introduce sync objects

[Jason Ekstrand]

On Mon, May 8, 2017 at 7:26 PM, Dave Airlie  wrote:

> On 4 May 2017 at 18:16, Chris Wilson  wrote:
> > On Wed, Apr 26, 2017 at 01:28:29PM +1000, Dave Airlie wrote:
> >> +#include 
> >
> > I wonder if Daniel has already split everything used here into its own
> > headers?
>
> not sure, if drm_file is out there yet. I'll find out when I rebase
> this onto something newer I expect.
> >> +
> >> +static struct drm_syncobj *drm_syncobj_get(struct drm_file
> *file_private,
> >> +u32 handle)
> >
> > I would like this exposed to the driver as well, so I can do handle to
> > syncobj conversion once. (drm_syncobj_find() if we go with kref_get style
> > naming.)
>
> Where do you expect to need two lookups? At least for the semaphore APIs,
> you have a list of wait and list of signals, the lists should be
> different, I've
> no objections to exporting this later, but it would be easier to just do
> that
> with the first user.
>
> >
> >> +static struct drm_syncobj *drm_syncobj_fdget(int fd)
> >
> > It will aslo be useful to export the fd -> syncobj function for drivers.
> In
> > the interface Jason has for execbuf, we can substitute the handle for an
> > fd + flag, which may be more convenient for the user.
>
> Happy once we have a use case for it, I'd rather we didn't expose the
> syncobj
> fd to userspace for anything but sending a syncobj between processes,
> avoiding
> using fd's is one of the main points of this, I'd hate for an API to
> demand we use
> fd's.
>

I'm not sure how useful Chris' use-case is here.  From a userspace
perspective, I don't want to burn any more FDs than I absolutely have to,
so I'll do the FD -> syncobj conversion on import and use the handle from
there on.  For sync_file, using the FD isn't a big deal as it's a one-shot
and we close it as soon as execbuf() is completed.  Permanently
exported/imported VkSemaphores, on the other hand, are re-usable long-lived
objects and the ioctl on import is a smal
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 13/28] drm: omapdrm: dss: Initialize DSS internal features at probe time

[Laurent Pinchart]

Hi Tomi,

On Tuesday 09 May 2017 12:48:57 Tomi Valkeinen wrote:
> On 08/05/17 14:32, Laurent Pinchart wrote:
> > The DSS internal features are derived from the platform device
> > compatible string which is available at probe time. Don't delay
> > initialization until bind time. This prepares for the merge of the two
> > DSS features structures that will be needed before the DSS is bound.
> > 
> > Signed-off-by: Laurent Pinchart 
> > ---
> > 
> >  drivers/gpu/drm/omapdrm/dss/dss.c | 26 +-
> >  1 file changed, 13 insertions(+), 13 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/omapdrm/dss/dss.c
> > b/drivers/gpu/drm/omapdrm/dss/dss.c index 7546ba8ab955..4fdb77dd90b8
> > 100644
> > --- a/drivers/gpu/drm/omapdrm/dss/dss.c
> > +++ b/drivers/gpu/drm/omapdrm/dss/dss.c
> > @@ -1183,23 +1183,10 @@ static const struct soc_device_attribute
> > dss_soc_devices[] = {> 
> >  static int dss_bind(struct device *dev)
> >  {
> >  
> > struct platform_device *pdev = to_platform_device(dev);
> > 
> > -   const struct soc_device_attribute *soc;
> > 
> > struct resource *dss_mem;
> > u32 rev;
> > int r;
> > 
> > -   dss.pdev = pdev;
> > -
> > -   /*
> > -* The various OMAP3-based SoCs can be told apart from the compatible
> > -* string, use SoC device matching.
> > -*/
> > -   soc = soc_device_match(dss_soc_devices);
> > -   if (soc)
> > -   dss.feat = soc->data;
> > -   else
> > -   dss.feat = of_match_device(dss_of_match, >dev)->data;
> > -
> > 
> > dss_mem = platform_get_resource(dss.pdev, IORESOURCE_MEM, 0);
> > dss.base = devm_ioremap_resource(>dev, dss_mem);
> > if (!dss.base)
> > 
> > @@ -1331,9 +1318,22 @@ static int dss_add_child_component(struct device
> > *dev, void *data)> 
> >  static int dss_probe(struct platform_device *pdev)
> >  {
> > 
> > +   const struct soc_device_attribute *soc;
> > 
> > struct component_match *match = NULL;
> > int r;
> > 
> > +   dss.pdev = pdev;
> > +
> > +   /*
> > +* The various OMAP3-based SoCs can be told apart from the compatible
> > +* string, use SoC device matching.
> > +*/
> > +   soc = soc_device_match(dss_soc_devices);
> > +   if (soc)
> > +   dss.feat = soc->data;
> > +   else
> > +   dss.feat = of_match_device(dss_of_match, >dev)->data;
> > +
> 
> This has the problem that we should remove the static 'dss' variable,
> and allocate memory for each device. We can have more than one DSS in
> the future.

Sure, and that's on my to-do list, but I didn't want to make the patch series 
bigger than it is already.

> Also, I haven't looked at the following patches yet, but dss_features
> was a failed attempt to manage the dss features. Since then, we've
> slowly been moving the bits and pieces from dss_features to each
> individual driver.
> 
> So if this is needed for dss_features, we should instead move everything
> from dss_features and remove that altogether.

I agree with you, but again, I've tried to keep the existing architecture 
here, we can certainly rework it as a next step.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v2 11/28] drm: omapdrm: dss: Select features based on compatible string

[Laurent Pinchart]

Hi Tomi,

On Tuesday 09 May 2017 12:41:26 Tomi Valkeinen wrote:
> On 08/05/17 14:32, Laurent Pinchart wrote:
> > Use the compatible string instead of the OMAP SoC revision to determine
> > device features. The various OMAP3-based SoCs can be told apart from the
> > compatible string, use soc_device_match() to tell them apart.
> 
> Here, and in a comment below, you probably mean "can _not_ be told apart
> _using_ the compatible string".

Oops, indeed. Anything else I need to change in this patch, or do I get your 
Reviewed-by if I fix the comment and the commit message ?

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v2 10/28] drm: omapdrm: dsi: Handle pin muxing internally

[Laurent Pinchart]

Hi Tomi,

On Tuesday 09 May 2017 12:37:36 Tomi Valkeinen wrote:
> On 08/05/17 14:32, Laurent Pinchart wrote:
> > Don't rely on callback functions provided by the platform, but access
> > the syscon internally to mux the DSI pins.
> > 
> > Signed-off-by: Laurent Pinchart 
> > ---
> > 
> >  drivers/gpu/drm/omapdrm/dss/core.c | 20 --
> >  drivers/gpu/drm/omapdrm/dss/dsi.c  | 82 +++--
> >  drivers/gpu/drm/omapdrm/dss/dss.h  |  2 -
> >  3 files changed, 79 insertions(+), 25 deletions(-)

[snip]

> > diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c
> > b/drivers/gpu/drm/omapdrm/dss/dsi.c index 400f903d8197..d86a1ca6da00
> > 100644
> > --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> > +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c

[snip]

> > @@ -5332,6 +5393,21 @@ static int dsi_bind(struct device *dev, struct
> > device *master, void *data)
> > dsi->module_id = d->id;
> > 
> > +   if (dsi->data->type == DSI_TYPE_OMAP4) {
> > +   struct device_node *np;
> > +
> > +   /*
> > +* The OMAP4 display DT bindings don't reference the padconf
> > +* syscon. Our only option to retrieve it is to find it by 
name.
> > +*/
> 
> We could also do DT modifications at early boot phase (we do that
> already for a few things for tilcdc and omapdss), and then have the
> driver require the reference to padconf.

That's a good idea too, but I'd do that as a second step to avoid adding more 
dependencies on arch/arm/mach-omap2/ in this series.

> But I think this is fine too.
> 
> Reviewed-by: Tomi Valkeinen 

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v2 22/28] drm: omapdrm: Move shutdown() handler from core to dss

[Laurent Pinchart]

Hi Tomi,

On Tuesday 09 May 2017 14:38:39 Tomi Valkeinen wrote:
> On 08/05/17 14:32, Laurent Pinchart wrote:
> > In preparation for removal of the core module, move the shutdown()
> > handler from core to dss.
> > 
> > Signed-off-by: Laurent Pinchart 
> > ---
> > 
> >  drivers/gpu/drm/omapdrm/dss/core.c | 20 
> >  drivers/gpu/drm/omapdrm/dss/dss.c  | 16 
> >  2 files changed, 16 insertions(+), 20 deletions(-)
> 
> Reviewed-by: Tomi Valkeinen 
> 
> Although I wonder if shutdown is even needed... I think the DRM side
> should disable all the displays when being removed.

The .shutdown() handler is called when the system is shut down, including 
prior to a reboot. As far as I know the DRM core doesn't get involved there.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v2 07/28] drm: omapdrm: dpi: Remove platform driver

[Laurent Pinchart]

Hi Tomi,

On Tuesday 09 May 2017 12:06:58 Tomi Valkeinen wrote:
> On 08/05/17 14:32, Laurent Pinchart wrote:
> > No device is ever registered that binds with the driver, the DPI port is
> > handled manually. Remove the DPI platform driver.
> 
> You could add a bit more details: the DPI platform device was used for
> non-DT booting, which can now be removed.

I'll reword the commit message as follows:

drm: omapdrm: dpi: Remove platform driver

The DPI platform driver was used for non-DT platforms only. On DT 
platforms the DPI port is handled manually. As OMAP display devices are 
now instantiated from DT only, remove the DPI platform driver.

(same for patch 19/28)

> > Signed-off-by: Laurent Pinchart 
> > ---
> > 
> >  drivers/gpu/drm/omapdrm/dss/core.c |  6 ---
> >  drivers/gpu/drm/omapdrm/dss/dpi.c  | 93 -
> >  drivers/gpu/drm/omapdrm/dss/dss.h  |  3 --
> >  3 files changed, 102 deletions(-)
> 
> Reviewed-by: Tomi Valkeinen 
> 
>  Tomi

-- 
Regards,

Laurent Pinchart

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

[Bug 100979] Radeon r4 on a6-6310(BEEMA) APU hard lockup on hibernate and on second resume from suspend

[bugzilla-daemon]

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

--- Comment #5 from Przemek  ---
Created attachment 131285
  --> https://bugs.freedesktop.org/attachment.cgi?id=131285=edit
system log after second suspend and hard lockup

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

[Bug 100979] Radeon r4 on a6-6310(BEEMA) APU hard lockup on hibernate and on second resume from suspend

[bugzilla-daemon]

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

--- Comment #4 from Przemek  ---
Created attachment 131284
  --> https://bugs.freedesktop.org/attachment.cgi?id=131284=edit
system log after first suspend

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

[Bug 100979] Radeon r4 on a6-6310(BEEMA) APU hard lockup on hibernate and on second resume from suspend

[bugzilla-daemon]

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

--- Comment #3 from Przemek  ---
Created attachment 131283
  --> https://bugs.freedesktop.org/attachment.cgi?id=131283=edit
kernel config file

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

[Bug 100979] Radeon r4 on a6-6310(BEEMA) APU hard lockup on hibernate and on second resume from suspend

[bugzilla-daemon]

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

--- Comment #2 from Przemek  ---
Created attachment 131282
  --> https://bugs.freedesktop.org/attachment.cgi?id=131282=edit
system log after performing hibernate

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

[Bug 100979] Radeon r4 on a6-6310(BEEMA) APU hard lockup on hibernate and on second resume from suspend

[bugzilla-daemon]

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

--- Comment #1 from Przemek  ---
Created attachment 131281
  --> https://bugs.freedesktop.org/attachment.cgi?id=131281=edit
system log after clean boot

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

[Bug 100979] Radeon r4 on a6-6310(BEEMA) APU hard lockup on hibernate and on second resume from suspend

[bugzilla-daemon]

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

Bug ID: 100979
   Summary: Radeon r4 on a6-6310(BEEMA) APU hard lockup on
hibernate and on second resume from suspend
   Product: DRI
   Version: DRI git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: sop...@gmail.com

I'm using kernel 4.11 on gentoo with SI/CIK enabled on Lenovo G50-45 Notebook.
Machine has AMD APU A6 6130 with Radeon r4 graphics card (Beema/Mullins). This
CPU supports olny AMD IOMMU v1. There is no discrete graphic card on it, APU
only.

When I try to hibernate this notebook it doesn't turning off. I have to press
power button to reboot the machine. Similar situation is on "radeon" driver,
and I had submitted bug report about this on kernel's bugzilla:

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

But in this situation I'm unable to bisect because as I remember correctly
problem always occur on amdgpu driver, so I think those two can correlate with
each other. (dmesg form hibernation process attached).

As for suspend.
I can suspend/resume machine successfully only once in a row. Second time
machine suspends correctly, but on resume I have hard lockup, fans are spinning
on full rpm's and I cannot do anything but pressing power button to reboot(cold
boot) the netbook.
Moreover in dmesg after first suspend I've got error messages:

[drm:amdgpu_atombios_dp_link_train [amdgpu]] *ERROR* displayport link status
failed
[drm:amdgpu_atombios_dp_link_train [amdgpu]] *ERROR* clock recovery failed

Attachments:
1. Log after clean start.
2. Kernel's config file.
3. Log after hibernation process.
4. Log after first suspend/resume.
5. Log after second suspend/resume.

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

Re: Soliciting DRM feedback on latest DC rework

[Harry Wentland]

On 2017-05-09 04:24 AM, Daniel Vetter wrote:

On Mon, May 08, 2017 at 02:54:22PM -0400, Harry Wentland wrote:

Hi Daniel,

Thanks for taking the time to look at DC.

I had a couple more questions/comments in regard to the patch you posted on
IRC: http://paste.debian.net/plain/930704

My impression is that this item is the most important next step for us:


From a quick glance I think what we want instead is:
- amdgpu_crtc_state and amdgpu_plane_state as following:

struct amdgpu_crtc_state {
struct drm_crtc_state base;
struct dc_stream;
};


Unfortunately as sketched here it doesn't quite mesh with what we currently
have, which is:

struct stream {
struct core_stream protected;
...
}

struct core_stream {
struct dc_stream public;
...
}

struct dc_stream {
...
}

Any objections to doing something like this instead:

#ifdef LINUX
#include "drm_crtc.h"
#endif

struct dc_stream {
#ifdef LINUX
struct drm_crtc_state base;
#endif
...
}

The ifdefs are then removed on Linux versions of DC, while other OSs
wouldn't compile with the LINUX flag.


- validate_context->res_ctx->pool looks extremely fishy. In principle,
  refcounting does not mesh with the duplicate, check, then
  free-or-commit semantics of atomic. Are you sure this works
  correctly when doing TEST_ONLY commits? igt or weston (with Daniel's
  patches) are your friend (or enemy) here :-)

  The common approach all other drivers implement:
  - Same duplicate semantics for private objects as for core drm
objects. The private obj helpers will help with cutting down the
boiler-plate.
  - No refcounts, instead an allocation bitmask in the object one up
in the hierarchy (usually global state, but sometimes also
crtc/stream).
  - If you want to keep the current design, then you
must do a deep copy of pool (i.e. not just the struct, but also
every struct that might change it points too). The above
accomplishes that essentially, except in standard atomic patterns.
  - You'll probably need a bunch of for_each_foo_in_context macros,
built using the private state helpers.

  Trying to review correctness of atomic_check when private resources
  are refcounted is real hard. The only case we have is vc4, and it's
  kinda not pretty (it has it's own manual rollback hacks in the
  release functions). Going entirely with free-standing stuff is much
  better.


Good points here. I think I'll ultimately have to get IGT running against
our code with TEST_ONLY commits and see what happens. Ultimately we probably
have to deep copy, one way or another. I don't really want any rollback
stuff as that would be near impossible to maintain.


This shouldn't be a huge conceptual change in the DC design (it
already has checks for "is this unchanged" and then ignore that
object), just quite a bit more invasive than sprinkling for_each_*
macros all over the place. From a glane it could be that you'd get
80% there by having a for_each_changed_*_in_context set of macros,
with the current code everywhere else, and the "jumps over unchanged
obj because they're not in drm_atomic_state/dc_validation_context"
logic on drm atomic.


Yeah, this should fit mostly with DC design. Will evaluate this once we link
DC objects to DRM state objects.


@@ -1640,6 +1644,8 @@ static void dm_crtc_helper_disable(struct drm_crtc *crtc)
 {
 }

+/* no dummy funcs pls, counts everywhere */
+


Does the comment apply to the preceding or next function? What do you mean
with "counts everywhere"?


In general you have a lot of callbacks which are either just {} or {
return 0; }, aka empty/dummy implementations.

We've refactored atomic helpers a lot to make all of these optional, pls
remove them. This was a somewhat recent development, I guess initial
atomic DC still had to have all these dummy callbacks.



That makes sense. We haven't really revisited these since our initial 
work on atomic more than a year ago.



 static int dm_crtc_helper_atomic_check(
struct drm_crtc *crtc,
struct drm_crtc_state *state)




@@ -3077,6 +3102,15 @@ int amdgpu_dm_atomic_check(struct drm_device *dev,

acrtc = to_amdgpu_crtc(crtc);

+   /* This is the wrong way round. If you have a requirement for a
+* 1:1 connector/crtc mapping, then loop over connectors and
+* grab the crtc from there. Plus make sure there's really only
+* 1 connector per crtc (but the possible clones stuff should
+* catch that for you I think, at least with latest atomic
+* helpers.
+*
+* Similar for the same loop in commit.
+*/
aconnector = 
amdgpu_dm_find_first_crct_matching_connector(state, crtc, true);

RE: amdgpu display corruption and hang on AMD A10-9620P

[Deucher, Alexander]

> -Original Message-
> From: Daniel Drake [mailto:dr...@endlessm.com]
> Sent: Tuesday, May 09, 2017 12:55 PM
> To: dri-devel; amd-...@lists.freedesktop.org; Deucher, Alexander
> Cc: Chris Chiu; Linux Upstreaming Team
> Subject: amdgpu display corruption and hang on AMD A10-9620P
> 
> Hi,
> 
> We are working with new laptops that have the AMD Bristol Ridge
> chipset with this SoC:
> 
> AMD A10-9620P RADEON R5, 10 COMPUTE CORES 4C+6G
> 
> I think this is the Bristol Ridge chipset.
> 
> During boot, the display becomes unusable at the point where the
> amdgpu driver loads. You can see at least two horizontal lines of
> garbage at this point. We have reproduced on 4.8, 4.10 and linus
> master (early 4.12).
> 
> Photo: http://pasteboard.co/qrC9mh4p.jpg
> 
> Getting logs is tricky because the system appears to freeze at that point.
> 
> Is this a known issue? Anything we can do to help diagnosis?

I'm not aware of any specific issues.  Please file a bug and attach your logs 
(https://bugs.freedesktop.org) along with information about the system.

Alex

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

Re: [PATCH v6 08/13] drm/sun4i: add support for Allwinner DE2 mixers

[Maxime Ripard]

On Fri, May 05, 2017 at 08:39:31PM +0800, Icenowy Zheng wrote:
> >> > > +  /* Set base coordinates */
> >> > > +  DRM_DEBUG_DRIVER("Layer coordinates X: %d Y: %d\n",
> >> > > +   state->crtc_x, state->crtc_y);
> >> > > +  regmap_write(mixer->engine.regs,
> >> > > +   SUN8I_MIXER_CHAN_UI_LAYER_COORD(chan, layer),
> >> > > +   SUN8I_MIXER_COORD(state->crtc_x, state->crtc_y));
> >> > 
> >> > X and Y are fixed point numbers. You want to keep only the higher
> >16
> >> > bits there.
> >> 
> >> Do you mean "lower 16 bits"? Thus should I (x & 0x) or ((u16)x) ?
> >
> >Nevermind, I got confused with src_x and src_y.
> >
> >> P.S. The negative coordinates are broken, how should I deal with it?
> >or
> >> is the coordinates promised to be not negative?
> >
> >Adjust the buffer base address, and use a shorter line. You have such
> >an example in the sun4i code.
> 
> Are they these two lines:
> ```
> paddr += (state->src_x >> 16) * bpp;
> paddr += (state->src_y >> 16) * fb->pitches[0];
> ```
> 
> I think I copied them here, so I don't need to mind this problem any
> more, right?

Hmmm, yes, probably. That's pretty easy to test anyway, you just need
to set up a plane with a negative base coordinate.

Maxime

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


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

Re: [linux-sunxi] [PATCH v6 11/13] ARM: dts: sun8i: add DE2 nodes for V3s SoC

[Maxime Ripard]

1;4601;0c
On Fri, May 05, 2017 at 08:34:16PM +0800, Icenowy Zheng wrote:
> 
> 
> 于 2017年5月5日 GMT+08:00 下午8:30:35, Maxime Ripard 
>  写到:
> >On Fri, May 05, 2017 at 04:53:43PM +0800, icen...@aosc.io wrote:
> >> > > +   de2_clocks: clock@100 {
> >> > > +   compatible =
> >"allwinner,sun50i-h5-de2-clk";
> >> > 
> >> > I am a bit skeptical about this. Since the V3S only has one mixer,
> >do
> >> > the clocks
> >> > for the second one even exist?
> >> 
> >> It's described in the de_clock.c in the BSP source code, and in
> >hardware
> >> these bits can be really set (although without clock output).
> >> 
> >> So I use this compatible which has still the extra clocks.
> >
> >If it's not usable, then it shouldn't be in the code, it's basically
> >dead code.
> 
> Thus should we have one more DE2 CCU compatible without mixer1
> clocks for V3s?

If those clocks don't exist on v3s, then yes.

Maxime

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


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

Re: [PATCH] drm/vgem: Convert to a struct drm_device subclass

[Laura Abbott]

On 05/08/2017 06:22 AM, Chris Wilson wrote:

With Laura's introduction of the fake platform device for importing
dmabuf, we add a second static that is logically tied to the vgem_device.
Convert vgem over to using the struct drm_device subclassing, so that
the platform device is stored inside its owner.

Signed-off-by: Chris Wilson 
Cc: Laura Abbott 
Cc: Daniel Vetter 
---
  drivers/gpu/drm/vgem/vgem_drv.c | 63 +++--
  1 file changed, 41 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index c9381d457a03..4b23ba049632 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -42,7 +42,10 @@
  #define DRIVER_MAJOR  1
  #define DRIVER_MINOR  0
  
-static struct platform_device *vgem_platform;

+static struct vgem_device {
+   struct drm_device drm;
+   struct platform_device *platform;
+} *vgem_device;
  
  static void vgem_gem_free_object(struct drm_gem_object *obj)

  {
@@ -307,7 +310,9 @@ static struct sg_table *vgem_prime_get_sg_table(struct 
drm_gem_object *obj)
  static struct drm_gem_object* vgem_prime_import(struct drm_device *dev,
struct dma_buf *dma_buf)
  {
-   return drm_gem_prime_import_dev(dev, dma_buf, _platform->dev);
+   struct vgem_device *vgem = container_of(dev, typeof(*vgem), drm);
+
+   return drm_gem_prime_import_dev(dev, dma_buf, >platform->dev);
  }
  
  static struct drm_gem_object *vgem_prime_import_sg_table(struct drm_device *dev,

@@ -377,8 +382,19 @@ static int vgem_prime_mmap(struct drm_gem_object *obj,
return 0;
  }
  
+static void vgem_release(struct drm_device *dev)

+{
+   struct vgem_device *vgem = container_of(dev, typeof(*vgem), drm);
+
+   platform_device_unregister(vgem->platform);
+   drm_dev_fini(>drm);
+
+   kfree(vgem);
+}
+
  static struct drm_driver vgem_driver = {
.driver_features= DRIVER_GEM | DRIVER_PRIME,
+   .release= vgem_release,
.open   = vgem_open,
.postclose  = vgem_postclose,
.gem_free_object_unlocked   = vgem_gem_free_object,
@@ -408,45 +424,48 @@ static struct drm_driver vgem_driver = {
.minor  = DRIVER_MINOR,
  };
  
-static struct drm_device *vgem_device;

-
  static int __init vgem_init(void)
  {
int ret;
  
-	vgem_device = drm_dev_alloc(_driver, NULL);

-   if (IS_ERR(vgem_device))
-   return PTR_ERR(vgem_device);
+   vgem_device = kzalloc(sizeof(*vgem_device), GFP_KERNEL);
+   if (!vgem_device)
+   return -ENOMEM;
  
-	vgem_platform = platform_device_register_simple("vgem",

-   -1, NULL, 0);
+   ret = drm_dev_init(_device->drm, _driver, NULL);
+   if (ret)
+   goto out_free;
  
-	if (!vgem_platform) {

+   vgem_device->platform =
+   platform_device_register_simple("vgem", -1, NULL, 0);
+   if (!vgem_device->platform) {
ret = -ENODEV;
-   goto out;
+   goto out_fini;
}
  
-	dma_coerce_mask_and_coherent(_platform->dev,

-   DMA_BIT_MASK(64));
+   dma_coerce_mask_and_coherent(_device->platform->dev,
+DMA_BIT_MASK(64));
  
-	ret  = drm_dev_register(vgem_device, 0);

+   /* Final step: expose the device/driver to userspace */
+   ret  = drm_dev_register(_device->drm, 0);
if (ret)
-   goto out_unref;
+   goto out_unregister;
  
  	return 0;
  
-out_unref:

-   platform_device_unregister(vgem_platform);
-out:
-   drm_dev_unref(vgem_device);
+out_unregister:
+   platform_device_unregister(vgem_device->platform);
+out_fini:
+   drm_dev_fini(_device->drm > +out_free:
+   kfree(vgem_device);
return ret;
  }
  
  static void __exit vgem_exit(void)

  {
-   platform_device_unregister(vgem_platform);
-   drm_dev_unregister(vgem_device);
-   drm_dev_unref(vgem_device);
+   drm_dev_unregister(_device->drm);
+   drm_dev_unref(_device->drm);
  }
  
  module_init(vgem_init);




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

Re: [PATCH] gpu: drm: amd: amdgpu: remove dead code

[Andres Rodriguez]

On 2017-05-09 08:53 AM, Alex Deucher wrote:

On Mon, May 8, 2017 at 1:01 PM, Gustavo A. R. Silva
 wrote:

Local variable use_doorbell is assigned to a constant value and it is never
updated again. Remove this variable and the dead code it guards.

Addresses-Coverity-ID: 1401828
Signed-off-by: Gustavo A. R. Silva 


This code is already removed in the latest code queued for the next
kernel for gfx8.  For gfx7, I think Andres' priority patch set fixes
this up for gfx7.


Yeah, on gfx7 it should use ring->use_doorbell instead of the hard-coded 
local variable.


Andres



Alex


---
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 53 +--
 1 file changed, 20 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
index 67afc90..e824c2b 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
@@ -4991,7 +4991,6 @@ static int gfx_v8_0_cp_compute_resume(struct 
amdgpu_device *adev)
 {
int r, i, j;
u32 tmp;
-   bool use_doorbell = true;
u64 hqd_gpu_addr;
u64 mqd_gpu_addr;
u64 eop_gpu_addr;
@@ -5079,11 +5078,7 @@ static int gfx_v8_0_cp_compute_resume(struct 
amdgpu_device *adev)

/* enable doorbell? */
tmp = RREG32(mmCP_HQD_PQ_DOORBELL_CONTROL);
-   if (use_doorbell) {
-   tmp = REG_SET_FIELD(tmp, CP_HQD_PQ_DOORBELL_CONTROL, 
DOORBELL_EN, 1);
-   } else {
-   tmp = REG_SET_FIELD(tmp, CP_HQD_PQ_DOORBELL_CONTROL, 
DOORBELL_EN, 0);
-   }
+   tmp = REG_SET_FIELD(tmp, CP_HQD_PQ_DOORBELL_CONTROL, 
DOORBELL_EN, 1);
WREG32(mmCP_HQD_PQ_DOORBELL_CONTROL, tmp);
mqd->cp_hqd_pq_doorbell_control = tmp;

@@ -5157,29 +5152,23 @@ static int gfx_v8_0_cp_compute_resume(struct 
amdgpu_device *adev)
   mqd->cp_hqd_pq_wptr_poll_addr_hi);

/* enable the doorbell if requested */
-   if (use_doorbell) {
-   if ((adev->asic_type == CHIP_CARRIZO) ||
-   (adev->asic_type == CHIP_FIJI) ||
-   (adev->asic_type == CHIP_STONEY) ||
-   (adev->asic_type == CHIP_POLARIS11) ||
-   (adev->asic_type == CHIP_POLARIS10) ||
-   (adev->asic_type == CHIP_POLARIS12)) {
-   WREG32(mmCP_MEC_DOORBELL_RANGE_LOWER,
-  AMDGPU_DOORBELL_KIQ << 2);
-   WREG32(mmCP_MEC_DOORBELL_RANGE_UPPER,
-  AMDGPU_DOORBELL_MEC_RING7 << 2);
-   }
-   tmp = RREG32(mmCP_HQD_PQ_DOORBELL_CONTROL);
-   tmp = REG_SET_FIELD(tmp, CP_HQD_PQ_DOORBELL_CONTROL,
-   DOORBELL_OFFSET, 
ring->doorbell_index);
-   tmp = REG_SET_FIELD(tmp, CP_HQD_PQ_DOORBELL_CONTROL, 
DOORBELL_EN, 1);
-   tmp = REG_SET_FIELD(tmp, CP_HQD_PQ_DOORBELL_CONTROL, 
DOORBELL_SOURCE, 0);
-   tmp = REG_SET_FIELD(tmp, CP_HQD_PQ_DOORBELL_CONTROL, 
DOORBELL_HIT, 0);
-   mqd->cp_hqd_pq_doorbell_control = tmp;
-
-   } else {
-   mqd->cp_hqd_pq_doorbell_control = 0;
+   if ((adev->asic_type == CHIP_CARRIZO) ||
+   (adev->asic_type == CHIP_FIJI) ||
+   (adev->asic_type == CHIP_STONEY) ||
+   (adev->asic_type == CHIP_POLARIS11) ||
+   (adev->asic_type == CHIP_POLARIS10) ||
+   (adev->asic_type == CHIP_POLARIS12)) {
+   WREG32(mmCP_MEC_DOORBELL_RANGE_LOWER, AMDGPU_DOORBELL_KIQ 
<< 2);
+   WREG32(mmCP_MEC_DOORBELL_RANGE_UPPER, 
AMDGPU_DOORBELL_MEC_RING7 << 2);
}
+   tmp = RREG32(mmCP_HQD_PQ_DOORBELL_CONTROL);
+   tmp = REG_SET_FIELD(tmp, CP_HQD_PQ_DOORBELL_CONTROL,
+  DOORBELL_OFFSET, ring->doorbell_index);
+   tmp = REG_SET_FIELD(tmp, CP_HQD_PQ_DOORBELL_CONTROL, 
DOORBELL_EN, 1);
+   tmp = REG_SET_FIELD(tmp, CP_HQD_PQ_DOORBELL_CONTROL, 
DOORBELL_SOURCE, 0);
+   tmp = REG_SET_FIELD(tmp, CP_HQD_PQ_DOORBELL_CONTROL, 
DOORBELL_HIT, 0);
+   mqd->cp_hqd_pq_doorbell_control = tmp;
+
WREG32(mmCP_HQD_PQ_DOORBELL_CONTROL,
   mqd->cp_hqd_pq_doorbell_control);

@@ -5217,11 +5206,9 @@ static int gfx_v8_0_cp_compute_resume(struct 
amdgpu_device *adev)
amdgpu_bo_unreserve(ring->mqd_obj);
}

-   if (use_doorbell) {
-   tmp = RREG32(mmCP_PQ_STATUS);
-   tmp = REG_SET_FIELD(tmp, CP_PQ_STATUS, DOORBELL_ENABLE, 1);
-   

[Bug 100618] Dead Island crash after starting a new game

[bugzilla-daemon]

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

--- Comment #14 from John Brooks  ---
(In reply to at46n from comment #13)
> Seems like its a glsl compiler bug and not a radeonsi bug. With "prlimit
> --pid PIDofDeadIsland -n65535" I am able to start and play the game.
> 
> *** This bug has been marked as a duplicate of bug 85564 ***

Not quite. The shaders actually compile fine, but Mesa does not yet support
retrieving a binary with glGetProgramBinary(), and it's likely that the game
mishandles this, resulting in running out of file descriptors, mishandling that
error condition, and then crashing.

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

Re: [PATCH] tinydrm: mipi-dbi: Use seq_putc() in mipi_dbi_debugfs_command_show()

[Joe Perches]

On Tue, 2017-05-09 at 19:29 +0200, Noralf Trønnes wrote:
> Den 08.05.2017 13.54, skrev SF Markus Elfring:
> > A single character (line break) should be put into a sequence.
> > Thus use the corresponding function "seq_putc".

Markus, I know this is hard for you,
but think more before sending patches.

> > diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c 
> > b/drivers/gpu/drm/tinydrm/mipi-dbi.c
[]
> > @@ -946,7 +946,7 @@ static int mipi_dbi_debugfs_command_show(struct 
> > seq_file *m, void *unused)
> >   
> > for (i = 0; i < len; i++)
> > seq_printf(m, "%02x", val[i]);
> > -   seq_puts(m, "\n");
> > +   seq_putc(m, '\n');

Use the %p extensions.

seq_printf(m, "%*phN\n", len, val)

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

Re: [PATCH v2] drm/pl111: Register the clock divider and use it.

[Eric Anholt]

Linus Walleij  writes:

> On Mon, May 8, 2017 at 9:33 PM, Eric Anholt  wrote:
>
>> This is required for the panel to work on bcm911360, where CLCDCLK is
>> the fixed 200Mhz AXI41 clock.  The rate set is still passed up to the
>> CLCDCLK, for platforms that have a settable rate on that one.
>>
>> v2: Set SET_RATE_PARENT (caught by Linus Walleij), depend on
>> COMMON_CLK.
>>
>> Signed-off-by: Eric Anholt 
>
> Reviewed-by: Linus Walleij 

Thanks.  Waiting on an ack from clock folks, then we'll be ready to go,
I think.


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

[PATCH v2] drm/vc4: Enable selection in Kconfig on any 32-bit BCM platform.

[Eric Anholt]

With the Cygnus port, we needed to add at least "|| ARCH_BCM_CYGNUS"
to let the module get built on a cygnus-only kernel.  However, I
anticipate having a port for Kona soon, so just present the module on
all of BCM.

v2: Keep allowing selection with ARCH_BCM2835, since ARCH_BCM doesn't
exist on arm64.

Signed-off-by: Eric Anholt 
Acked-by: Daniel Vetter  (v1)
---
 drivers/gpu/drm/vc4/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/Kconfig b/drivers/gpu/drm/vc4/Kconfig
index 973b4203c0b2..b16aefe4a8d3 100644
--- a/drivers/gpu/drm/vc4/Kconfig
+++ b/drivers/gpu/drm/vc4/Kconfig
@@ -1,6 +1,6 @@
 config DRM_VC4
tristate "Broadcom VC4 Graphics"
-   depends on ARCH_BCM2835 || COMPILE_TEST
+   depends on ARCH_BCM || ARCH_BCM2835 || COMPILE_TEST
depends on DRM
depends on SND && SND_SOC
depends on COMMON_CLK
-- 
2.11.0

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

[Bug 100919] [DC] "Out of range" on a display connected to a DVI-D output of RX460 card via DVI-D<=>HDMI-A cable

[bugzilla-daemon]

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

--- Comment #9 from Nikola Forró  ---
Thanks Harry,

I've just tested the patch and I can confirm it fixes the problem.

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

[Bug 100618] Dead Island crash after starting a new game

[bugzilla-daemon]

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

at...@t-online.de changed:

   What|Removed |Added

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

--- Comment #13 from at...@t-online.de ---
Seems like its a glsl compiler bug and not a radeonsi bug. With "prlimit --pid
PIDofDeadIsland -n65535" I am able to start and play the game.

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

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

[Bug 100919] [DC] "Out of range" on a display connected to a DVI-D output of RX460 card via DVI-D<=>HDMI-A cable

[bugzilla-daemon]

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

Harry Wentland  changed:

   What|Removed |Added

 Attachment #131276|0   |1
is obsolete||

--- Comment #8 from Harry Wentland  ---
Created attachment 131279
  --> https://bugs.freedesktop.org/attachment.cgi?id=131279=edit
2nd attempt at patch

Thanks, Alex, Nikola, for pointing out the problem in my code. I should've
looked more closely. Here's an update.

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

[Bug 100919] [DC] "Out of range" on a display connected to a DVI-D output of RX460 card via DVI-D<=>HDMI-A cable

[bugzilla-daemon]

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

--- Comment #7 from Nikola Forró  ---
Hi Alex,

yes, that's exactly what I meant.
Sorry for not being clear.

Nikola

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

Re: [PATCH] tinydrm: mipi-dbi: Use seq_putc() in mipi_dbi_debugfs_command_show()

[Noralf Trønnes]

Den 08.05.2017 13.54, skrev SF Markus Elfring:

From: Markus Elfring 
Date: Mon, 8 May 2017 13:42:03 +0200

A single character (line break) should be put into a sequence.
Thus use the corresponding function "seq_putc".

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---


Thanks,

Acked-by: Noralf Trønnes 


  drivers/gpu/drm/tinydrm/mipi-dbi.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c 
b/drivers/gpu/drm/tinydrm/mipi-dbi.c
index f4eb412f3604..54d66b732d55 100644
--- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
+++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
@@ -946,7 +946,7 @@ static int mipi_dbi_debugfs_command_show(struct seq_file 
*m, void *unused)
  
  		for (i = 0; i < len; i++)

seq_printf(m, "%02x", val[i]);
-   seq_puts(m, "\n");
+   seq_putc(m, '\n');
}
  
  	return 0;


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

[Bug 100919] [DC] "Out of range" on a display connected to a DVI-D output of RX460 card via DVI-D<=>HDMI-A cable

[bugzilla-daemon]

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

--- Comment #6 from Alex Deucher  ---
what about the else case?  Shouldn't the logic be:


if (dc_is_dvi_signal(stream->signal)) {
if (stream->public.timing.pix_clk_khz >
TMDS_MAX_PIXEL_CLOCK_IN_KHZ)
stream->signal = SIGNAL_TYPE_DVI_DUAL_LINK;
else
stream->signal = SIGNAL_TYPE_DVI_SINGLE_LINK;
}

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

Re: [PATCH v2 0/3] drm/amd/display: add HDMI Stereo 3D support

[Harry Wentland]

Series is Reviewed-by: Harry Wentland 

Harry

On 2017-05-08 12:35 PM, Jeff Smith wrote:

Changes: I have broken one patch into three.

Note: this only covers the display (not amdgpu) portion and does not
  include the code to make it work over the card's DVI port.

I only have one Stereo-3D-capable display to test this on, an LG TV from
about 2014.  All 3 modes (side-by-side half, top-and-bottom, and
frame-packing) appear to work as intended.

Jeff Smith (3):
  drm/amd/display: translate drm's mode to display's stereo-3D timing
  drm/amd/display: use stereo-3D-aware methods when calculating
dimensions
  drm/amd/display: enable stereo-3D modes/timings

 .../drm/amd/display/amdgpu_dm/amdgpu_dm_types.c| 33 +++---
 .../display/dc/dce110/dce110_timing_generator.c|  4 ---
 2 files changed, 23 insertions(+), 14 deletions(-)


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

[Bug 100919] [DC] "Out of range" on a display connected to a DVI-D output of RX460 card via DVI-D<=>HDMI-A cable

[bugzilla-daemon]

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

--- Comment #5 from Harry Wentland  ---
Nikola, this line from the patch should take care of your concern:

+   if (dc_is_dvi_signal(stream->signal) &&

Other signal types shouldn't be affected.

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

[Bug 100919] [DC] "Out of range" on a display connected to a DVI-D output of RX460 card via DVI-D<=>HDMI-A cable

[bugzilla-daemon]

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

--- Comment #4 from Nikola Forró  ---
Comment on attachment 131276
  --> https://bugs.freedesktop.org/attachment.cgi?id=131276
Patch to fix this (hopefully)

Review of attachment 131276:
-

::: drivers/gpu/drm/amd/display/dc/core/dc_resource.c
@@ +1268,4 @@
>   stream->public.timing.pix_clk_khz > TMDS_MAX_PIXEL_CLOCK_IN_KHZ)
>   stream->signal = SIGNAL_TYPE_DVI_DUAL_LINK;
> + else
> + stream->signal = SIGNAL_TYPE_DVI_SINGLE_LINK;

I don't think this is such a good idea, because AFAICS this sets stream->signal
to SIGNAL_TYPE_DVI_SINGLE_LINK also for all types of signal other than DVI.

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

amdgpu display corruption and hang on AMD A10-9620P

[Daniel Drake]

Hi,

We are working with new laptops that have the AMD Bristol Ridge
chipset with this SoC:

AMD A10-9620P RADEON R5, 10 COMPUTE CORES 4C+6G

I think this is the Bristol Ridge chipset.

During boot, the display becomes unusable at the point where the
amdgpu driver loads. You can see at least two horizontal lines of
garbage at this point. We have reproduced on 4.8, 4.10 and linus
master (early 4.12).

Photo: http://pasteboard.co/qrC9mh4p.jpg

Getting logs is tricky because the system appears to freeze at that point.

Is this a known issue? Anything we can do to help diagnosis?

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

Re: [PATCHv2 0/3] Intel FPGA VIP Frame Buffer II DRM Driver

[Eric Anholt]

"Ong, Hean Loong"  writes:

> On Mon, 2017-05-08 at 09:03 -0700, Eric Anholt wrote:
>> "Ong, Hean Loong"  writes:
>> 
>> > 
>> > On Thu, 2017-05-04 at 10:11 -0700, Eric Anholt wrote:
>> > > 
>> > > "Ong, Hean Loong"  writes:
>> > > 
>> > > > 
>> > > > 
>> > > > On Wed, 2017-05-03 at 13:28 -0700, Eric Anholt wrote:
>> > > > > 
>> > > > > 
>> > > > > hean.loong@intel.com writes:
>> > > > > 
>> > > > > > 
>> > > > > > 
>> > > > > > 
>> > > > > > From: Ong Hean Loong 
>> > > > > > 
>> > > > > > Hi,
>> > > > > > 
>> > > > > > The new Intel Arria10 SOC FPGA devkit has a Display Port IP
>> > > > > > component 
>> > > > > > which requires a new driver. This is a virtual driver in
>> > > > > > which
>> > > > > > the
>> > > > > > FGPA hardware would enable the Display Port based on the
>> > > > > > information
>> > > > > > and data provided from the DRM frame buffer from the OS.
>> > > > > > Basically
>> > > > > > all
>> > > > > > all information with reagrds to resolution and bits per
>> > > > > > pixel
>> > > > > > are
>> > > > > > pre-configured on the FPGA design and these information are
>> > > > > > fed
>> > > > > > to
>> > > > > > the driver via the device tree information as part of the
>> > > > > > hardware 
>> > > > > > information.
>> > > > > I started reviewing the code, but I want to make sure I
>> > > > > understand
>> > > > > what's going on:
>> > > > > 
>> > > > > This IP core isn't displaying contents from system memory on
>> > > > > some
>> > > > > sort
>> > > > > of actual physical display, right?  It's a core that takes
>> > > > > some
>> > > > > input
>> > > > > video stream (not described in the DT or in this driver) and
>> > > > > stores
>> > > > > it
>> > > > > to memory?
>> > > > If the IP Core you are referring to is some form of GPU then in
>> > > > this
>> > > > case we are using the Intel FPGA Display Port Framebuffer IP.
>> > > > It
>> > > > does
>> > > > display contents streamed from the ARM/Linux system to the
>> > > > Display
>> > > > Port
>> > > > of the physical Monitor.
>> > > > 
>> > > > Below a simple illustration of the system:
>> > > > 
>> > > > ARM/Linux --DMA-->Intel FPGA Display Port Framebuffer IP
>> > > >|
>> > > >|
>> > > >Physical Connection
>> > > >Display Port
>> > > The "DMA" in this diagram is the frame reader IP, right?  The
>> > > frame
>> > > reader, as described in the spec, sounds approximately like a DRM
>> > > plane,
>> > > so if you have that in your system then that needs to be part of
>> > > this
>> > > DRM driver (otherwise you won't be putting the right things on
>> > > the
>> > > screen!).
>> > Would the drm_simple_display_pipe_init be able to handle this ? It
>> > seems to be displaying the proper images on screen, based on my
>> > current
>> > changes. There were recommendations to use the
>> > drm_simple_display_pipe_init instead of creating the CRTC and
>> > planes
>> > myself
>> The docs I've read for the Frame Buffer IP don't fit into any current
>> DRM component, since it's what we're currently calling a "writeback
>> connector".
>> 
> While running my own test (since the intel-gpu-tools doesn't seems
> applicable.) The drm_simple_display_pipe_init seems to be simple enough
> for displaying a matchbox console. The use case for this driver is only
> part of the enablemennt of the reference design board so that users of
> the Arria10 devkit can use this as base for their own designs.
>
>> I don't understand your system enough to answer.  You didn't answer
>> if
>> the "DMA" block you diagrammed was the frame reader IP (or maybe the
>> frame reader IP comes after).  I also don't see how the frame buffer
>> IP
>> could possibly be connected directly to a physical display connector.
>
> The FPGA FrameBuffer 2 soft IP reads the information provided to it
> from the Linux Kernel via the platform device register provided in the
> DT. The Linux driver here allocates a chunk of coherent memory that
> directly maps to the SDRAM. The FPGA soft IP would stream the display
> out to the Display Port based on the information that was written to
> the SDRAM.

Your "FPGA soft IP" that's reading pixels from an area of memory (a DRM
plane does this) and outputting that to a display port (a DRM CRTC and
encoder does this) would make a lot of sense as a DRM driver.

However, this piece of hardware that takes in pixels in a stream from
elsewhere and stores it to memory doesn't make sense to me as a DRM
driver.

I can't really offer more advice until I understand what's generating
the pixels that the FrameBuffer IP is storing.


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

[Bug 99029] VCE VAAPI segfault using ffmpeg

[bugzilla-daemon]

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

--- Comment #3 from Andy Furniss  ---
Hmm, I haven't tested yet, but if you hit the division by zero, I guess there
is something special about thet file (or ffmpeg/something changed since I last
looked). Before reading your other bug the only way I thought would trigger
that one was to explicitly add -g 0 to the command line.

On speed - I would get rid of the yuv420p, maybe add -g 48 as for some reason
things don't seem quite right with the gop, or you shouldn't hit the division
by zero.

Your fix seems to change the intent of that code a little bit - I don't know if
it makes any difference. That code got added to correct some corner case rate
control cbr issue - ffmpeg switched to using vbr by default so may not show it
anyway. I don't recall what rate (maybe it's cqp) you'll get if you don't ask
for anything like your example. There may be a better place to check if gop is
0.

-profile:v 77 doesn't quite work properly IIRC (well it doesn't change anything
encoding wise but the file will not show as main).

You may get more perf if you force your GPU to high.

I guess this is just a test, but for real world use, using your h/w to
transcode without b-frames is not really an optimum solution and it's up to the
firmware team whether b-frames ever work (They don't work on windows either
AFAICT).

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

[RFC] drm: add unref_fb ioctl

[Rob Clark]

Similar to rmfb but does not have the side effect of shutting down any
pipes that are scanning out the fb.

Advantages compared to rmfb:
  * slightly easier userspace, it doesn't have to track fb-id's until
they come of the screen
  * it might be desirable to keep existing layers on screen across
process restart (for crashing or upgrading the compositor)

Disadvantages:
  * depending on userspace architecture, layers left on screen could
be considered an information leak, ie. new incoming master process
has access to buffers that are still being scanned out.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/drm_crtc_internal.h |  2 ++
 drivers/gpu/drm/drm_framebuffer.c   | 66 +++--
 drivers/gpu/drm/drm_ioctl.c |  1 +
 include/uapi/drm/drm.h  |  1 +
 include/uapi/drm/drm_mode.h | 20 +++
 5 files changed, 72 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc_internal.h 
b/drivers/gpu/drm/drm_crtc_internal.h
index 8c04275..dafa17b 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -167,6 +167,8 @@ int drm_mode_addfb2(struct drm_device *dev,
void *data, struct drm_file *file_priv);
 int drm_mode_rmfb(struct drm_device *dev,
  void *data, struct drm_file *file_priv);
+int drm_mode_unref_fb(struct drm_device *dev,
+ void *data, struct drm_file *file_priv);
 int drm_mode_getfb(struct drm_device *dev,
   void *data, struct drm_file *file_priv);
 int drm_mode_dirtyfb_ioctl(struct drm_device *dev,
diff --git a/drivers/gpu/drm/drm_framebuffer.c 
b/drivers/gpu/drm/drm_framebuffer.c
index e8f9c13..8f2afdf 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -356,31 +356,17 @@ static void drm_mode_rmfb_work_fn(struct work_struct *w)
}
 }
 
-/**
- * drm_mode_rmfb - remove an FB from the configuration
- * @dev: drm device for the ioctl
- * @data: data pointer for the ioctl
- * @file_priv: drm file for the ioctl call
- *
- * Remove the FB specified by the user.
- *
- * Called by the user via ioctl.
- *
- * Returns:
- * Zero on success, negative errno on failure.
- */
-int drm_mode_rmfb(struct drm_device *dev,
-  void *data, struct drm_file *file_priv)
+static int __rmfb(struct drm_device *dev, struct drm_file *file_priv,
+ uint32_t fb_id, bool rmfb)
 {
struct drm_framebuffer *fb = NULL;
struct drm_framebuffer *fbl = NULL;
-   uint32_t *id = data;
int found = 0;
 
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EINVAL;
 
-   fb = drm_framebuffer_lookup(dev, *id);
+   fb = drm_framebuffer_lookup(dev, fb_id);
if (!fb)
return -ENOENT;
 
@@ -406,7 +392,7 @@ int drm_mode_rmfb(struct drm_device *dev,
 * so run this in a separate stack as there's no way to correctly
 * handle this after the fb is already removed from the lookup table.
 */
-   if (drm_framebuffer_read_refcount(fb) > 1) {
+   if (rmfb && drm_framebuffer_read_refcount(fb) > 1) {
struct drm_mode_rmfb_work arg;
 
INIT_WORK_ONSTACK(, drm_mode_rmfb_work_fn);
@@ -427,6 +413,50 @@ int drm_mode_rmfb(struct drm_device *dev,
 }
 
 /**
+ * drm_mode_rmfb - remove an FB from the configuration
+ * @dev: drm device for the ioctl
+ * @data: data pointer for the ioctl
+ * @file_priv: drm file for the ioctl call
+ *
+ * Remove the FB specified by the user.
+ *
+ * Called by the user via ioctl.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_mode_rmfb(struct drm_device *dev,
+ void *data, struct drm_file *file_priv)
+{
+   uint32_t *id = data;
+   return __rmfb(dev, file_priv, *id, true);
+}
+
+/**
+ * drm_mode_unref_fb - unreference an FB
+ * @dev: drm device for the ioctl
+ * @data: data pointer for the ioctl
+ * @file_priv: drm file for the ioctl call
+ *
+ * Unreference the FB specified by the user.
+ *
+ * Called by the user via ioctl.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_mode_unref_fb(struct drm_device *dev, void *data,
+ struct drm_file *file_priv)
+{
+   struct drm_mode_unref_fb *r = data;
+
+   if (r->pad)
+   return -EINVAL;
+
+   return __rmfb(dev, file_priv, r->fb_id, false);
+}
+
+/**
  * drm_mode_getfb - get FB info
  * @dev: drm device for the ioctl
  * @data: data pointer for the ioctl
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 7d6deaa..a113972 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -642,6 +642,7 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_MODE_ATOMIC, drm_mode_atomic_ioctl, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),

Re: [PATCH 03/11] drm: parse ycbcr 420 vdb block

[Ville Syrjälä]

On Tue, May 09, 2017 at 02:04:55PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 5/8/2017 10:39 PM, Ville Syrjälä wrote:
> > On Mon, May 08, 2017 at 10:11:53PM +0530, Sharma, Shashank wrote:
> >> Regards
> >>
> >> Shashank
> >>
> >>
> >> On 5/8/2017 9:54 PM, Ville Syrjälä wrote:
> >>> On Fri, Apr 07, 2017 at 07:39:20PM +0300, Shashank Sharma wrote:
>  From: Jose Abreu 
> 
>  HDMI 2.0 spec adds support for ycbcr420 subsampled output.
>  CEA-861-F adds two new blocks in EDID, to provide information about
>  sink's support for ycbcr420 output.
> 
>  These new blocks are:
>  - ycbcr420 video data (vdb) block: video modes which can be supported
>  only in ycbcr420 output mode.
>  - ycbcr420 video capability data (vcb) block: video modes which can be
>  support in ycbcr420 output mode also (along with RGB, YCBCR 444/422 
>  etc)
> 
>  This patch adds parsing and handling of ycbcr420-vdb in the DRM
>  layer.
> 
>  This patch is a modified version of Jose's RFC patch:
>  https://patchwork.kernel.org/patch/9492327/
>  so the authorship is maintained.
> 
>  Cc: Ville Syrjala 
>  Signed-off-by: Jose Abreu 
>  Signed-off-by: Shashank Sharma 
>  ---
> drivers/gpu/drm/drm_edid.c  | 54 
>  +++--
> drivers/gpu/drm/drm_modes.c | 10 +++--
> include/drm/drm_connector.h |  1 +
> include/uapi/drm/drm_mode.h |  6 +
> 4 files changed, 67 insertions(+), 4 deletions(-)
> >>> 
>  diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
>  index 4eeda12..cef76b2 100644
>  --- a/include/drm/drm_connector.h
>  +++ b/include/drm/drm_connector.h
>  @@ -199,6 +199,7 @@ struct drm_display_info {
> #define DRM_COLOR_FORMAT_RGB444   (1<<0)
> #define DRM_COLOR_FORMAT_YCRCB444 (1<<1)
> #define DRM_COLOR_FORMAT_YCRCB422 (1<<2)
>  +#define DRM_COLOR_FORMAT_YCRCB420   (1<<2)
> 
>   /**
>    * @color_formats: HDMI Color formats, selects between RGB and 
>  YCrCb
>  diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
>  index 8c67fc0..1e74d8e 100644
>  --- a/include/uapi/drm/drm_mode.h
>  +++ b/include/uapi/drm/drm_mode.h
>  @@ -84,6 +84,12 @@ extern "C" {
> #define  DRM_MODE_FLAG_3D_L_DEPTH_GFX_GFX_DEPTH   (6<<14)
> #define  DRM_MODE_FLAG_3D_TOP_AND_BOTTOM  (7<<14)
> #define  DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF   (8<<14)
>  +/*
>  + * HDMI 2.0
>  + */
>  +#define DRM_MODE_FLAG_420_MASK  (0x03<<23)
>  +#define  DRM_MODE_FLAG_420  (1<<23)
>  +#define  DRM_MODE_FLAG_420_ONLY (1<<24)
> >>> Adding those would again break the uabi. We can't add new mode flags
> >>> without some kind of client cap.
> >>> But I think we agreed that new user
> >>> space visible mode flags aren't needed, and instad we can keep it all
> >>> internal?
> >> Yep you are right, we had decided to keep it internal, and this whole
> >> patch series is implemented in such a way only, to control everything
> >> through the HDMI output property itself.
> >> But may be I slightly misunderstood that we shouldn't add the flags bits
> >> all together, and I added this flag to differentiate between YCBCR420
> >> and notmal modes.
> >> Can you please suggest me on:
> >> - how to differentiate a YCBCR420 mode with normal mode ? I still need
> >> to add a flag, but not expose it into uapi layer.
> > I guess we can just tack on a few new bools to the end of
> > drm_display_mode. And then when we get the mode passed in by the user
> > we'll have to check whether that mode matches any CEA mode and
> > then look up the correct YCbCr 4:2:0 mode for it.
> seems good to me, I can add a is_ycbcr420 flag, and we need not to 
> bother about converting it to drm_mode_modeinfo as we are keeping it 
> internal.
> >
> > Hmm. Actually, that probably means that it isn't sufficient to
> > actually store this information on the modes we have on the connector's
> > mode list, because that list has been filtered and so may not actually
> > have all the modes that were declared in the EDID.
> I dint get this point,  Why do you think its not sufficient ? Do we need 
> to care about the modes which are getting rejected from the driver ?

Yes, that was my worry. In general I don't think connector->modes should
ever be used for mode validation or state computation. Eg. if fbdev
handled the previus hotplug connector->modes will have been filtered
based on the size of the fb_helper framebuffer, and then a new master
might just blindly come in and blindly set a new mode without doing a
full connector probe.

> I guess they cant be applied 

Re: [PATCH 1/5] drm: introduce sync objects

[Sean Paul]

On Wed, Apr 26, 2017 at 01:28:29PM +1000, Dave Airlie wrote:
> From: Dave Airlie 
> 
> Sync objects are new toplevel drm object, that contain a
> pointer to a fence. This fence can be updated via command
> submission ioctls via drivers.
> 
> There is also a generic wait obj API modelled on the vulkan
> wait API (with code modelled on some amdgpu code).
> 
> These objects can be converted to an opaque fd that can be
> passes between processes.
> 
> TODO: define sync_file interaction.
> 
> Signed-off-by: Dave Airlie 



> diff --git a/include/drm/drm_syncobj.h b/include/drm/drm_syncobj.h
> new file mode 100644
> index 000..3cc42b7
> --- /dev/null
> +++ b/include/drm/drm_syncobj.h



> +/**
> + * drm_gem_object_reference - acquire a GEM BO reference
> + * @obj: GEM buffer object
> + *
> + * This acquires additional reference to @obj. It is illegal to call this
> + * without already holding a reference. No locks required.
> + */
> +static inline void
> +drm_syncobj_reference(struct drm_syncobj *obj)
> +{
> + kref_get(>refcount);
> +}
> +
> +/**
> + * __drm_gem_object_unreference - raw function to release a GEM BO reference
> + * @obj: GEM buffer object
> + *
> + * This function is meant to be used by drivers which are not encumbered with
> + * _device.struct_mutex legacy locking and which are using the
> + * gem_free_object_unlocked callback. It avoids all the locking checks and
> + * locking overhead of drm_gem_object_unreference() and
> + * drm_gem_object_unreference_unlocked().
> + *
> + * Drivers should never call this directly in their code. Instead they should
> + * wrap it up into a ``driver_gem_object_unreference(struct driver_gem_object
> + * *obj)`` wrapper function, and use that. Shared code should never call 
> this, to
> + * avoid breaking drivers by accident which still depend upon
> + * _device.struct_mutex locking.

Lot's of gem_obj copypasta to clean up in the comment here and above

> + */
> +static inline void
> +drm_syncobj_unreference(struct drm_syncobj *obj)
> +{
> + kref_put(>refcount, drm_syncobj_free);
> +}
> +
> +int drm_syncobj_fence_get(struct drm_file *file_private,
> +   u32 handle,
> +   struct dma_fence **fence);
> +int drm_syncobj_replace_fence(struct drm_file *file_private,
> +   u32 handle,
> +   struct dma_fence *fence);
> +
> +#endif
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index b2c5284..dd0b99c 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -647,6 +647,7 @@ struct drm_gem_open {
>  #define DRM_CAP_CURSOR_HEIGHT0x9
>  #define DRM_CAP_ADDFB2_MODIFIERS 0x10
>  #define DRM_CAP_PAGE_FLIP_TARGET 0x11
> +#define DRM_CAP_SYNCOBJ  0x13
>  
>  /** DRM_IOCTL_GET_CAP ioctl argument type */
>  struct drm_get_cap {
> @@ -696,6 +697,25 @@ struct drm_prime_handle {
>   __s32 fd;
>  };
>  
> +struct drm_syncobj_create {
> + __u32 handle;
> + __u32 flags;
> +};
> +
> +struct drm_syncobj_destroy {
> + __u32 handle;
> + __u32 pad;
> +};
> +
> +struct drm_syncobj_handle {
> + __u32 handle;
> + /** Flags.. only applicable for handle->fd */
> + __u32 flags;
> +
> + __s32 fd;
> + __u32 pad;
> +};
> +
>  #if defined(__cplusplus)
>  }
>  #endif
> @@ -814,6 +834,11 @@ extern "C" {
>  #define DRM_IOCTL_MODE_CREATEPROPBLOBDRM_IOWR(0xBD, struct 
> drm_mode_create_blob)
>  #define DRM_IOCTL_MODE_DESTROYPROPBLOB   DRM_IOWR(0xBE, struct 
> drm_mode_destroy_blob)
>  
> +#define DRM_IOCTL_SYNCOBJ_CREATE DRM_IOWR(0xBF, struct 
> drm_syncobj_create)
> +#define DRM_IOCTL_SYNCOBJ_DESTROYDRM_IOWR(0xC0, struct 
> drm_syncobj_destroy)
> +#define DRM_IOCTL_SYNCOBJ_HANDLE_TO_FD   DRM_IOWR(0xC1, struct 
> drm_syncobj_handle)
> +#define DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE   DRM_IOWR(0xC2, struct 
> drm_syncobj_handle)
> +
>  /**
>   * Device specific ioctls should only be in their respective headers
>   * The device specific ioctl range is from 0x40 to 0x9f.
> -- 
> 2.9.3
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100919] [DC] "Out of range" on a display connected to a DVI-D output of RX460 card via DVI-D<=>HDMI-A cable

[bugzilla-daemon]

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

--- Comment #3 from Harry Wentland  ---
Created attachment 131276
  --> https://bugs.freedesktop.org/attachment.cgi?id=131276=edit
Patch to fix this (hopefully)

Hi Nikola, Thomas.

Thanks for reporting this.

Try this patch. I haven't been able to test it myself but it should fix this.

Harry

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

[Bug 99029] VCE VAAPI segfault using ffmpeg

[bugzilla-daemon]

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

Martin Bednar  changed:

   What|Removed |Added

Version|13.0|17.1

--- Comment #2 from Martin Bednar  ---
After fixing https://bugs.freedesktop.org/show_bug.cgi?id=100972 , 
ffmpeg -hwaccel vaapi -hwaccel_output_format vaapi -i Elephants_Dream_HD.avi
-vf format=yuv420p,hwupload -threads 2 -acodec copy  -vaapi_device
/dev/dri/renderD128  -bf 0 -c:v h264_vaapi -c:v h264_vaapi -profile:v 77
~/test.mkv

seems to work (ffmpeg from git master).
Performance is atrocious though : I get about an encoding rate of about 2 FPS.

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

[PATCH 3/5] drm/vblank: Add FIXME comments about moving the vblank ts hooks

[Daniel Vetter]

This is going to be a bit too much, but good to have at least a small
note about where this should all head towards.

Acked-by: Ville Syrjälä 
Reviewed-by: Neil Armstrong 
Signed-off-by: Daniel Vetter 
---
 include/drm/drm_drv.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index a97dbc1eeccd..619da98533cd 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -276,6 +276,11 @@ struct drm_driver {
 * constant but unknown small number of scanlines wrt. real scanout
 * position.
 *
+* FIXME:
+*
+* Since this is a helper to implement @get_vblank_timestamp, we should
+* move it to  drm_crtc_helper_funcs, like all the other
+* helper-internal hooks.
 */
int (*get_scanout_position) (struct drm_device *dev, unsigned int pipe,
 unsigned int flags, int *vpos, int *hpos,
@@ -319,6 +324,11 @@ struct drm_driver {
 *
 * True on success, false on failure, which means the core should
 * fallback to a simple timestamp taken in drm_crtc_handle_vblank().
+*
+* FIXME:
+*
+* We should move this hook to  drm_crtc_funcs like all the other
+* vblank hooks.
 */
bool (*get_vblank_timestamp) (struct drm_device *dev, unsigned int pipe,
 int *max_error,
-- 
2.11.0

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

[PATCH 4/5] drm/vblank: drop the mode argument from drm_calc_vbltimestamp_from_scanoutpos

[Daniel Vetter]

If we restrict this helper to only kms drivers (which is the case) we
can look up the correct mode easily ourselves. But it's a bit tricky:

- All legacy drivers look at crtc->hwmode. But that is updated already
  at the beginning of the modeset helper, which means when we disable
  a pipe. Hence the final timestamps might be a bit off. But since
  this is an existing bug I'm not going to change it, but just try to
  be bug-for-bug compatible with the current code. This only applies
  to radeon

- i915 tries to get it perfect by updating crtc->hwmode when the pipe
  is off (i.e. vblank->enabled = false).

- All other atomic drivers look at crtc->state->adjusted_mode. Those
  that look at state->requested_mode simply don't adjust their mode,
  so it's the same. That has two problems: Accessing crtc->state from
  interrupt handling code is unsafe, and it's updated before we shut
  down the pipe. For nonblocking modesets it's even worse.

For atomic drivers try to implement what i915 does. To do that we add
a new hwmode field to the vblank structure, and update it from
drm_calc_timestamping_constants(). For atomic drivers that's called
from the right spot by the helper library already, so all fine. But
for safety let's enforce that.

For legacy driver this function is only called at the end (oh the
fun), which is broken, so again let's not bother and just stay
bug-for-bug compatible.

The  benefit is that we can use drm_calc_vbltimestamp_from_scanoutpos
directly to implement ->get_vblank_timestamp in every driver, deleting
a lot of code.

v2: Completely new approach, trying to mimick the i915 solution.

v3: Fixup kerneldoc.

v4: Drop the WARN_ON to check that the vblank is off, atomic helpers
currently unconditionally call this. Recomputing the same stuff should
be harmless.

v5: Fix typos and move misplaced hunks to the right patches (Neil).

v6: Undo hunk movement (kbuild).

Cc: Mario Kleiner 
Cc: Eric Anholt 
Cc: Rob Clark 
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Cc: Alex Deucher 
Cc: Christian König 
Cc: Ben Skeggs 
Reviewed-by: Neil Armstrong 
Acked-by: Ville Syrjälä 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h   |  4 ---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   | 14 +++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c   | 41 
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h  |  3 ++
 drivers/gpu/drm/drm_irq.c | 43 ++---
 drivers/gpu/drm/i915/i915_irq.c   | 52 +--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c   | 45 +-
 drivers/gpu/drm/nouveau/nouveau_display.c | 38 +-
 drivers/gpu/drm/nouveau/nouveau_display.h |  8 ++---
 drivers/gpu/drm/nouveau/nouveau_drm.c |  2 +-
 drivers/gpu/drm/radeon/radeon_drv.c   | 18 +++
 drivers/gpu/drm/radeon/radeon_kms.c   | 37 --
 drivers/gpu/drm/radeon/radeon_mode.h  |  3 ++
 drivers/gpu/drm/vc4/vc4_crtc.c| 34 ++--
 drivers/gpu/drm/vc4/vc4_drv.c |  2 +-
 drivers/gpu/drm/vc4/vc4_drv.h | 11 +++
 include/drm/drmP.h|  8 -
 include/drm/drm_drv.h | 20 
 include/drm/drm_irq.h | 15 +++--
 19 files changed, 121 insertions(+), 277 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 0ce8292d97c0..9de615bb0c2e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1910,10 +1910,6 @@ int amdgpu_device_resume(struct drm_device *dev, bool 
resume, bool fbcon);
 u32 amdgpu_get_vblank_counter_kms(struct drm_device *dev, unsigned int pipe);
 int amdgpu_enable_vblank_kms(struct drm_device *dev, unsigned int pipe);
 void amdgpu_disable_vblank_kms(struct drm_device *dev, unsigned int pipe);
-bool amdgpu_get_vblank_timestamp_kms(struct drm_device *dev, unsigned int pipe,
-int *max_error,
-struct timeval *vblank_time,
-bool in_vblank_irq);
 long amdgpu_kms_compat_ioctl(struct file *filp, unsigned int cmd,
 unsigned long arg);
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 4e0f7d2d87f1..73e982cd6136 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -711,6 +711,16 @@ static const struct file_operations amdgpu_driver_kms_fops 
= {
 #endif
 };
 
+static bool
+amdgpu_get_crtc_scanout_position(struct drm_device *dev, unsigned int pipe,
+bool 

[PATCH 5/5] drm/vblank: Lock down vblank->hwmode more

[Daniel Vetter]

In the previous patch we've implemented hwmode tracking a la i915 for
the vblank timestamp calculations. But that was just the basic
semantics, i915 has some nice sanity checks to make sure we keep
getting this right. Move them over too.

v2:
- WARN_ON_ONCE to avoid excessive spam (Ville)
- Really only WARN on atomic drivers.

Cc: Ville Syrjälä 
Reviewed-by: Neil Armstrong 
Acked-by: Ville Syrjälä 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_irq.c|  6 ++
 drivers/gpu/drm/i915/i915_irq.c  | 10 ++
 drivers/gpu/drm/i915/intel_display.c | 11 ++-
 3 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 89f0928b042a..c7debaad67f8 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -777,6 +777,8 @@ bool drm_calc_vbltimestamp_from_scanoutpos(struct 
drm_device *dev,
 */
if (mode->crtc_clock == 0) {
DRM_DEBUG("crtc %u: Noop due to uninitialized mode.\n", pipe);
+   WARN_ON_ONCE(drm_drv_uses_atomic_modeset(dev));
+
return false;
}
 
@@ -1338,6 +1340,10 @@ void drm_crtc_vblank_off(struct drm_crtc *crtc)
send_vblank_event(dev, e, seq, );
}
spin_unlock_irqrestore(>event_lock, irqflags);
+
+   /* Will be reset by the modeset helpers when re-enabling the crtc by
+* calling drm_calc_timestamping_constants(). */
+   vblank->hwmode.crtc_clock = 0;
 }
 EXPORT_SYMBOL(drm_crtc_vblank_off);
 
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 34b09edc18e4..5292fb1e5c53 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -720,9 +720,7 @@ static u32 i915_get_vblank_counter(struct drm_device *dev, 
unsigned int pipe)
struct drm_i915_private *dev_priv = to_i915(dev);
i915_reg_t high_frame, low_frame;
u32 high1, high2, low, pixel, vbl_start, hsync_start, htotal;
-   struct intel_crtc *intel_crtc = intel_get_crtc_for_pipe(dev_priv,
-   pipe);
-   const struct drm_display_mode *mode = _crtc->base.hwmode;
+   const struct drm_display_mode *mode = >vblank[pipe].hwmode;
unsigned long irqflags;
 
htotal = mode->crtc_htotal;
@@ -779,13 +777,17 @@ static int __intel_get_crtc_scanline(struct intel_crtc 
*crtc)
 {
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
-   const struct drm_display_mode *mode = >base.hwmode;
+   const struct drm_display_mode *mode;
+   struct drm_vblank_crtc *vblank;
enum pipe pipe = crtc->pipe;
int position, vtotal;
 
if (!crtc->active)
return -1;
 
+   vblank = >base.dev->vblank[drm_crtc_index(>base)];
+   mode = >hwmode;
+
vtotal = mode->crtc_vtotal;
if (mode->flags & DRM_MODE_FLAG_INTERLACE)
vtotal /= 2;
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 85b9e2f521a0..a190973daeee 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11443,12 +11443,6 @@ intel_modeset_update_crtc_state(struct 
drm_atomic_state *state)
for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
to_intel_crtc(crtc)->config = 
to_intel_crtc_state(new_crtc_state);
 
-   /* Update hwmode for vblank functions */
-   if (new_crtc_state->active)
-   crtc->hwmode = new_crtc_state->adjusted_mode;
-   else
-   crtc->hwmode.crtc_clock = 0;
-
/*
 * Update legacy state to satisfy fbc code. This can
 * be removed when fbc uses the atomic state.
@@ -15425,8 +15419,6 @@ static void intel_modeset_readout_hw_state(struct 
drm_device *dev)
to_intel_crtc_state(crtc->base.state);
int pixclk = 0;
 
-   crtc->base.hwmode = crtc_state->base.adjusted_mode;
-
memset(>base.mode, 0, sizeof(crtc->base.mode));
if (crtc_state->base.active) {
intel_mode_from_pipe_config(>base.mode, 
crtc_state);
@@ -15456,7 +15448,8 @@ static void intel_modeset_readout_hw_state(struct 
drm_device *dev)
if (IS_BROADWELL(dev_priv) && crtc_state->ips_enabled)
pixclk = DIV_ROUND_UP(pixclk * 100, 95);
 
-   drm_calc_timestamping_constants(>base, 
>base.hwmode);
+   drm_calc_timestamping_constants(>base,
+   
_state->base.adjusted_mode);
update_scanline_offset(crtc);
}
 
-- 

[PATCH 2/5] drm/vblank: Switch to bool in_vblank_irq in get_vblank_timestamp

[Daniel Vetter]

It's overkill to have a flag parameter which is essentially used just
as a boolean. This takes care of core + adjusting drivers.

Adjusting the scanout position callback is a bit harder, since radeon
also supplies it's own driver-private flags in there.

v2: Fixup misplaced hunks (Neil).

v3: kbuild says v1 was better ...

Cc: Mario Kleiner 
Cc: Eric Anholt 
Cc: Rob Clark 
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Cc: Alex Deucher 
Cc: Christian König 
Cc: Ben Skeggs 
Reviewed-by: Ville Syrjälä 
Reviewed-by: Neil Armstrong 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h   |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c   |  6 ++---
 drivers/gpu/drm/drm_irq.c | 41 +--
 drivers/gpu/drm/i915/i915_irq.c   |  4 +--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c   |  4 +--
 drivers/gpu/drm/nouveau/nouveau_display.c |  5 ++--
 drivers/gpu/drm/nouveau/nouveau_display.h |  2 +-
 drivers/gpu/drm/radeon/radeon_drv.c   |  2 +-
 drivers/gpu/drm/radeon/radeon_kms.c   |  4 +--
 drivers/gpu/drm/vc4/vc4_crtc.c|  4 +--
 drivers/gpu/drm/vc4/vc4_drv.h |  2 +-
 include/drm/drm_drv.h | 17 +++--
 include/drm/drm_irq.h |  2 +-
 13 files changed, 50 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 7b4f808afff9..0ce8292d97c0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1913,7 +1913,7 @@ void amdgpu_disable_vblank_kms(struct drm_device *dev, 
unsigned int pipe);
 bool amdgpu_get_vblank_timestamp_kms(struct drm_device *dev, unsigned int pipe,
 int *max_error,
 struct timeval *vblank_time,
-unsigned flags);
+bool in_vblank_irq);
 long amdgpu_kms_compat_ioctl(struct file *filp, unsigned int cmd,
 unsigned long arg);
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index a1b97809305e..babd969a63d1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -941,7 +941,7 @@ void amdgpu_disable_vblank_kms(struct drm_device *dev, 
unsigned int pipe)
  * @crtc: crtc to get the timestamp for
  * @max_error: max error
  * @vblank_time: time value
- * @flags: flags passed to the driver
+ * @in_vblank_irq: called from drm_handle_vblank()
  *
  * Gets the timestamp on the requested crtc based on the
  * scanout position.  (all asics).
@@ -950,7 +950,7 @@ void amdgpu_disable_vblank_kms(struct drm_device *dev, 
unsigned int pipe)
 bool amdgpu_get_vblank_timestamp_kms(struct drm_device *dev, unsigned int pipe,
 int *max_error,
 struct timeval *vblank_time,
-unsigned flags)
+bool in_vblank_irq)
 {
struct drm_crtc *crtc;
struct amdgpu_device *adev = dev->dev_private;
@@ -971,7 +971,7 @@ bool amdgpu_get_vblank_timestamp_kms(struct drm_device 
*dev, unsigned int pipe,
 
/* Helper routine in DRM core does all the work: */
return drm_calc_vbltimestamp_from_scanoutpos(dev, pipe, max_error,
-vblank_time, flags,
+vblank_time, in_vblank_irq,
 >hwmode);
 }
 
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 677b37b0372b..fba6a842f4cd 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -54,7 +54,7 @@
 
 static bool
 drm_get_last_vbltimestamp(struct drm_device *dev, unsigned int pipe,
- struct timeval *tvblank, unsigned flags);
+ struct timeval *tvblank, bool in_vblank_irq);
 
 static unsigned int drm_timestamp_precision = 20;  /* Default to 20 usecs. */
 
@@ -138,7 +138,7 @@ static void drm_reset_vblank_timestamp(struct drm_device 
*dev, unsigned int pipe
 */
do {
cur_vblank = __get_vblank_counter(dev, pipe);
-   rc = drm_get_last_vbltimestamp(dev, pipe, _vblank, 0);
+   rc = drm_get_last_vbltimestamp(dev, pipe, _vblank, false);
} while (cur_vblank != __get_vblank_counter(dev, pipe) && --count > 0);
 
/*
@@ -171,7 +171,7 @@ static void drm_reset_vblank_timestamp(struct drm_device 
*dev, unsigned int pipe
  * device vblank fields.
  */
 static void drm_update_vblank_count(struct drm_device 

[PATCH 1/5] drm/vblank: Switch drm_driver->get_vblank_timestamp to return a bool

[Daniel Vetter]

There's really no reason for anything more:
- Calling this while the crtc vblank stuff isn't set up is a driver
  bug. Those places alrready DRM_ERROR.
- Calling this when the crtc is off is either a driver bug (calling
  drm_crtc_handle_vblank at the wrong time) or a core bug (for
  anything else). Again, we DRM_ERROR.
- EINVAL is checked at higher levels already, and if we'd use struct
  drm_crtc * instead of (dev, pipe) it would be real obvious that
  those are again core bugs.

The only valid failure mode is crap hardware that couldn't sample a
useful timestamp, to ask the core to just grab a not-so-accurate
timestamp. Bool is perfectly fine for that.

v2: Also fix up the one caller, I lost that in the shuffling (Jani).

v3: Fixup commit message (Neil).

Cc: Jani Nikula 
Cc: Mario Kleiner 
Cc: Eric Anholt 
Cc: Rob Clark 
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Cc: Alex Deucher 
Cc: Christian König 
Cc: Ben Skeggs 
Reviewed-by: Neil Armstrong 
Acked-by: Ville Syrjälä 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h   |  8 ++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c   | 14 -
 drivers/gpu/drm/drm_irq.c | 49 ---
 drivers/gpu/drm/i915/i915_irq.c   |  8 ++---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c   | 12 
 drivers/gpu/drm/nouveau/nouveau_display.c |  4 +--
 drivers/gpu/drm/nouveau/nouveau_display.h |  4 +--
 drivers/gpu/drm/radeon/radeon_drv.c   |  8 ++---
 drivers/gpu/drm/radeon/radeon_kms.c   | 14 -
 drivers/gpu/drm/vc4/vc4_crtc.c|  2 +-
 drivers/gpu/drm/vc4/vc4_drv.h |  2 +-
 include/drm/drmP.h|  1 -
 include/drm/drm_drv.h |  7 ++---
 include/drm/drm_irq.h | 10 +++
 14 files changed, 64 insertions(+), 79 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 6a8129949333..7b4f808afff9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1910,10 +1910,10 @@ int amdgpu_device_resume(struct drm_device *dev, bool 
resume, bool fbcon);
 u32 amdgpu_get_vblank_counter_kms(struct drm_device *dev, unsigned int pipe);
 int amdgpu_enable_vblank_kms(struct drm_device *dev, unsigned int pipe);
 void amdgpu_disable_vblank_kms(struct drm_device *dev, unsigned int pipe);
-int amdgpu_get_vblank_timestamp_kms(struct drm_device *dev, unsigned int pipe,
-   int *max_error,
-   struct timeval *vblank_time,
-   unsigned flags);
+bool amdgpu_get_vblank_timestamp_kms(struct drm_device *dev, unsigned int pipe,
+int *max_error,
+struct timeval *vblank_time,
+unsigned flags);
 long amdgpu_kms_compat_ioctl(struct file *filp, unsigned int cmd,
 unsigned long arg);
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index 832be632478f..a1b97809305e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -945,19 +945,19 @@ void amdgpu_disable_vblank_kms(struct drm_device *dev, 
unsigned int pipe)
  *
  * Gets the timestamp on the requested crtc based on the
  * scanout position.  (all asics).
- * Returns postive status flags on success, negative error on failure.
+ * Returns true on success, false on failure.
  */
-int amdgpu_get_vblank_timestamp_kms(struct drm_device *dev, unsigned int pipe,
-   int *max_error,
-   struct timeval *vblank_time,
-   unsigned flags)
+bool amdgpu_get_vblank_timestamp_kms(struct drm_device *dev, unsigned int pipe,
+int *max_error,
+struct timeval *vblank_time,
+unsigned flags)
 {
struct drm_crtc *crtc;
struct amdgpu_device *adev = dev->dev_private;
 
if (pipe >= dev->num_crtcs) {
DRM_ERROR("Invalid crtc %u\n", pipe);
-   return -EINVAL;
+   return false;
}
 
/* Get associated drm_crtc: */
@@ -966,7 +966,7 @@ int amdgpu_get_vblank_timestamp_kms(struct drm_device *dev, 
unsigned int pipe,
/* This can occur on driver load if some component fails to
 * initialize completely and driver is unloaded */
DRM_ERROR("Uninitialized crtc %d\n", pipe);
-   return -EINVAL;
+   

Re: [RFC v2 0/7] drm: asynchronous atomic plane update

[Ville Syrjälä]

On Thu, Apr 27, 2017 at 12:15:12PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> Hi,
> 
> Second take of Asynchronous Plane Updates over Atomic. Here I looked
> to msm, vc4 and i915 to identify a common pattern to create atomic helpers
> for async updates. So in patch 1 drm_atomic_async_check() and
> drm_atomic_helper_async_commit() are introduced along with driver's plane 
> hooks:
> ->atomic_async_check() and ->atomic_async_commit().
> 
> For now we only support async update for one plane at a time. Also the async
> update can't modify the CRTC so no modesets are allowed.
> 
> Then the other patches add support for it in the drivers. I did virtio mostly
> for testing. i915 have been converted and I've been using it without any
> problem. IGT tests seems to be fine, but there are somewhat random failures
> with or without the async update changes. msm and vc4 are only compile-tested.
> So I think this needs more testing
> 
> I started IGT changes to test the Atomic IOCTL with the new flag:
> 
> https://git.collabora.com/cgit/user/padovan/intel-gpu-tools.git/

BTW I also realized recently that this is probably not going to work
w.r.t. per-crtc out fences. I know we agrees earlier that the
"return -1" trick would work, but now that I think about it again,
I don't think it actually will work when combined with non-blocking
commits since we can't decide whether to return -1 or a fence
until the commit has actually been performed.

> 
> v2:
> 
> Apart from all comments on v1 one extra change I made was to remove the
> constraint of only updating the plane if the queued state didn't touch
> that plane. I believe it was a too cautious of a change, furthermore this
> constraint was affecting throughput negatively on i915.
> 
> TODO
> 
>  - improve i-g-t tests where needed
>  - support async page flips (that can be done after uptreaming this part)
>  - figure out what to do for hw that do not update the plane until the next
>  vblank. Maybe wait and see what they do and them extract helpers?
> 
> Comments are welcome!
> 
> Gustavo Padovan (7):
>   drm/atomic: initial support for asynchronous plane update
>   drm/virtio: support async cursor updates
>   drm/i915: update cursors asynchronously through atomic
>   drm/i915: remove intel_cursor_plane_funcs
>   drm/msm: update cursors asynchronously through atomic
>   drm/msm: remove mdp5_cursor_plane_funcs
>   drm/vc4: update cursors asynchronously through atomic
> 
>  drivers/gpu/drm/drm_atomic.c  |  50 ++
>  drivers/gpu/drm/drm_atomic_helper.c   |  48 +
>  drivers/gpu/drm/i915/intel_atomic_plane.c |  52 ++
>  drivers/gpu/drm/i915/intel_display.c  | 158 -
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 161 
> ++
>  drivers/gpu/drm/vc4/vc4_plane.c   |  94 +
>  drivers/gpu/drm/virtio/virtgpu_plane.c|  42 
>  include/drm/drm_atomic.h  |   2 +
>  include/drm/drm_atomic_helper.h   |   2 +
>  include/drm/drm_modeset_helper_vtables.h  |  45 +
>  include/uapi/drm/drm_mode.h   |   4 +-
>  11 files changed, 343 insertions(+), 315 deletions(-)
> 
> -- 
> 2.9.3
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH] gpu: drm: amd: amdgpu: remove dead code

[Alex Deucher]

On Mon, May 8, 2017 at 1:01 PM, Gustavo A. R. Silva
 wrote:
> Local variable use_doorbell is assigned to a constant value and it is never
> updated again. Remove this variable and the dead code it guards.
>
> Addresses-Coverity-ID: 1401828
> Signed-off-by: Gustavo A. R. Silva 

This code is already removed in the latest code queued for the next
kernel for gfx8.  For gfx7, I think Andres' priority patch set fixes
this up for gfx7.

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 53 
> +--
>  1 file changed, 20 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c 
> b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> index 67afc90..e824c2b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> @@ -4991,7 +4991,6 @@ static int gfx_v8_0_cp_compute_resume(struct 
> amdgpu_device *adev)
>  {
> int r, i, j;
> u32 tmp;
> -   bool use_doorbell = true;
> u64 hqd_gpu_addr;
> u64 mqd_gpu_addr;
> u64 eop_gpu_addr;
> @@ -5079,11 +5078,7 @@ static int gfx_v8_0_cp_compute_resume(struct 
> amdgpu_device *adev)
>
> /* enable doorbell? */
> tmp = RREG32(mmCP_HQD_PQ_DOORBELL_CONTROL);
> -   if (use_doorbell) {
> -   tmp = REG_SET_FIELD(tmp, CP_HQD_PQ_DOORBELL_CONTROL, 
> DOORBELL_EN, 1);
> -   } else {
> -   tmp = REG_SET_FIELD(tmp, CP_HQD_PQ_DOORBELL_CONTROL, 
> DOORBELL_EN, 0);
> -   }
> +   tmp = REG_SET_FIELD(tmp, CP_HQD_PQ_DOORBELL_CONTROL, 
> DOORBELL_EN, 1);
> WREG32(mmCP_HQD_PQ_DOORBELL_CONTROL, tmp);
> mqd->cp_hqd_pq_doorbell_control = tmp;
>
> @@ -5157,29 +5152,23 @@ static int gfx_v8_0_cp_compute_resume(struct 
> amdgpu_device *adev)
>mqd->cp_hqd_pq_wptr_poll_addr_hi);
>
> /* enable the doorbell if requested */
> -   if (use_doorbell) {
> -   if ((adev->asic_type == CHIP_CARRIZO) ||
> -   (adev->asic_type == CHIP_FIJI) ||
> -   (adev->asic_type == CHIP_STONEY) ||
> -   (adev->asic_type == CHIP_POLARIS11) ||
> -   (adev->asic_type == CHIP_POLARIS10) ||
> -   (adev->asic_type == CHIP_POLARIS12)) {
> -   WREG32(mmCP_MEC_DOORBELL_RANGE_LOWER,
> -  AMDGPU_DOORBELL_KIQ << 2);
> -   WREG32(mmCP_MEC_DOORBELL_RANGE_UPPER,
> -  AMDGPU_DOORBELL_MEC_RING7 << 2);
> -   }
> -   tmp = RREG32(mmCP_HQD_PQ_DOORBELL_CONTROL);
> -   tmp = REG_SET_FIELD(tmp, CP_HQD_PQ_DOORBELL_CONTROL,
> -   DOORBELL_OFFSET, 
> ring->doorbell_index);
> -   tmp = REG_SET_FIELD(tmp, CP_HQD_PQ_DOORBELL_CONTROL, 
> DOORBELL_EN, 1);
> -   tmp = REG_SET_FIELD(tmp, CP_HQD_PQ_DOORBELL_CONTROL, 
> DOORBELL_SOURCE, 0);
> -   tmp = REG_SET_FIELD(tmp, CP_HQD_PQ_DOORBELL_CONTROL, 
> DOORBELL_HIT, 0);
> -   mqd->cp_hqd_pq_doorbell_control = tmp;
> -
> -   } else {
> -   mqd->cp_hqd_pq_doorbell_control = 0;
> +   if ((adev->asic_type == CHIP_CARRIZO) ||
> +   (adev->asic_type == CHIP_FIJI) ||
> +   (adev->asic_type == CHIP_STONEY) ||
> +   (adev->asic_type == CHIP_POLARIS11) ||
> +   (adev->asic_type == CHIP_POLARIS10) ||
> +   (adev->asic_type == CHIP_POLARIS12)) {
> +   WREG32(mmCP_MEC_DOORBELL_RANGE_LOWER, 
> AMDGPU_DOORBELL_KIQ << 2);
> +   WREG32(mmCP_MEC_DOORBELL_RANGE_UPPER, 
> AMDGPU_DOORBELL_MEC_RING7 << 2);
> }
> +   tmp = RREG32(mmCP_HQD_PQ_DOORBELL_CONTROL);
> +   tmp = REG_SET_FIELD(tmp, CP_HQD_PQ_DOORBELL_CONTROL,
> +  DOORBELL_OFFSET, ring->doorbell_index);
> +   tmp = REG_SET_FIELD(tmp, CP_HQD_PQ_DOORBELL_CONTROL, 
> DOORBELL_EN, 1);
> +   tmp = REG_SET_FIELD(tmp, CP_HQD_PQ_DOORBELL_CONTROL, 
> DOORBELL_SOURCE, 0);
> +   tmp = REG_SET_FIELD(tmp, CP_HQD_PQ_DOORBELL_CONTROL, 
> DOORBELL_HIT, 0);
> +   mqd->cp_hqd_pq_doorbell_control = tmp;
> +
> WREG32(mmCP_HQD_PQ_DOORBELL_CONTROL,
>mqd->cp_hqd_pq_doorbell_control);
>
> @@ -5217,11 +5206,9 @@ static int gfx_v8_0_cp_compute_resume(struct 
> amdgpu_device *adev)
> amdgpu_bo_unreserve(ring->mqd_obj);
> }
>
> -   if (use_doorbell) {
> -   tmp = RREG32(mmCP_PQ_STATUS);
> -   tmp = REG_SET_FIELD(tmp, 

Re: [PATCH v2 00/29] Remove the omapdrm and omapdss devices from platform code

[Tomi Valkeinen]

On 08/05/17 14:32, Laurent Pinchart wrote:
> Hello,
> 
> This patch series is a second, extended version of the code previously posted
> as "[PATCH/RFC 0/7] Remove the omapdrm device from platform code".

As this is a long series, I'd like to pick a bunch of patches from this
series already:

1-5, 7, 19, 21.

I didn't test yet, but I think those should not cause conflicts with the
rest of the series.

I can then push the branch, which contains also the fences and cache
patches, so you can base the rest on that.

Is this ok?

 Tomi



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