[Bug 99120] VERDE 7770 - glxdemo, vlc/glx, weston fail with garbled screen. Elsewhere blurry text rendering when focus lost
https://bugs.freedesktop.org/show_bug.cgi?id=99120 --- Comment #19 from Larry <5lokuf+c77xmvwa3y1jk at sharklasers.com> --- (In reply to Tom St Denis from comment #18) > So there is no known point for which this worked even with radeonsi+radeon > KMD? > > That surprises me. What can I tell ya?, I'd love to be wrong. :) I has the same issues in fc23 about 18 months ago and was using catalyst until fc25 recently came out forcing fc23 into EOL, at which point I had to upgrade for security updates. All the issues are still there, only now I can't use catalyst to sidestep the problem. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170102/ace4e861/attachment.html>
[PATCH 13/17] drm/bridge: Use recommened kerneldoc for struct member refs
On 12/30/2016 2:18 AM, Daniel Vetter wrote: > I just learned that &struct_name.member_name works and looks pretty > even. It doesn't (yet) link to the member directly though, which would > be really good for big structures or vfunc tables (where the > per-member kerneldoc tends to be long). > > Also some minor drive-by polish where it makes sense, I read a lot > of docs ... > > Cc: Archit Taneja > Cc: Jani Nikula > Cc: Chris Wilson > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/drm_bridge.c | 27 +++-- > include/drm/drm_bridge.h | 48 > +--- > 2 files changed, 39 insertions(+), 36 deletions(-) > > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c > index ae5e57ad718c..86a7637ba344 100644 > --- a/drivers/gpu/drm/drm_bridge.c > +++ b/drivers/gpu/drm/drm_bridge.c > @@ -55,7 +55,7 @@ > * just provide additional hooks to get the desired output at the end of the > * encoder chain. > * > - * Bridges can also be chained up using the next pointer in &struct > drm_bridge. > + * Bridges can also be chained up using the &drm_bridge.next pointer. > * > * Both legacy CRTC helpers and the new atomic modeset helpers support > bridges. > */ > @@ -179,7 +179,7 @@ void drm_bridge_detach(struct drm_bridge *bridge) > * @mode: desired mode to be set for the bridge > * @adjusted_mode: updated mode that works for this bridge > * > - * Calls ->mode_fixup() &drm_bridge_funcs op for all the bridges in the > + * Calls &drm_bridge_funcs.mode_fixup for all the bridges in the > * encoder chain, starting from the first bridge to the last. > * > * Note: the bridge passed should be the one closest to the encoder > @@ -206,11 +206,10 @@ bool drm_bridge_mode_fixup(struct drm_bridge *bridge, > EXPORT_SYMBOL(drm_bridge_mode_fixup); > > /** > - * drm_bridge_disable - calls ->disable() &drm_bridge_funcs op for all > - * bridges in the encoder chain. > + * drm_bridge_disable - disables all bridges in the encoder chain > * @bridge: bridge control structure > * > - * Calls ->disable() &drm_bridge_funcs op for all the bridges in the encoder > + * Calls &drm_bridge_funcs.disable op for all the bridges in the encoder > * chain, starting from the last bridge to the first. These are called before > * calling the encoder's prepare op. > * > @@ -229,11 +228,10 @@ void drm_bridge_disable(struct drm_bridge *bridge) > EXPORT_SYMBOL(drm_bridge_disable); > > /** > - * drm_bridge_post_disable - calls ->post_disable() &drm_bridge_funcs op for > - *all bridges in the encoder chain. > + * drm_bridge_post_disable - cleans up after disabling all bridges in the > encoder chain > * @bridge: bridge control structure > * > - * Calls ->post_disable() &drm_bridge_funcs op for all the bridges in the > + * Calls &drm_bridge_funcs.post_disable op for all the bridges in the > * encoder chain, starting from the first bridge to the last. These are > called > * after completing the encoder's prepare op. > * > @@ -258,7 +256,7 @@ EXPORT_SYMBOL(drm_bridge_post_disable); > * @mode: desired mode to be set for the bridge > * @adjusted_mode: updated mode that works for this bridge > * > - * Calls ->mode_set() &drm_bridge_funcs op for all the bridges in the > + * Calls &drm_bridge_funcs.mode_set op for all the bridges in the > * encoder chain, starting from the first bridge to the last. > * > * Note: the bridge passed should be the one closest to the encoder > @@ -278,11 +276,11 @@ void drm_bridge_mode_set(struct drm_bridge *bridge, > EXPORT_SYMBOL(drm_bridge_mode_set); > > /** > - * drm_bridge_pre_enable - calls ->pre_enable() &drm_bridge_funcs op for all > - * bridges in the encoder chain. > + * drm_bridge_pre_enable - prepares for enabling all > + * bridges in the encoder chain > * @bridge: bridge control structure > * > - * Calls ->pre_enable() &drm_bridge_funcs op for all the bridges in the > encoder > + * Calls &drm_bridge_funcs.pre_enable op for all the bridges in the encoder > * chain, starting from the last bridge to the first. These are called > * before calling the encoder's commit op. > * > @@ -301,11 +299,10 @@ void drm_bridge_pre_enable(struct drm_bridge *bridge) > EXPORT_SYMBOL(drm_bridge_pre_enable); > > /** > - * drm_bridge_enable - calls ->enable() &drm_bridge_funcs op for all bridges > - * in the encoder chain. > + * drm_bridge_enable - enables all bridges in the encoder chain > * @bridge: bridge control structure > * > - * Calls ->enable() &drm_bridge_funcs op for all the bridges in the encoder > + * Calls &drm_bridge_funcs.enable op for all the bridges in the encoder > * chain, starting from the first bridge to the last. These are called > * after completing the encoder's commit op. > * > diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h > index d3ca16f4da8f..159
[Intel-gfx] [PATCH 01/17] drm/docs: Small cleanup in drm-uapi.rst
On 30 December 2016 at 12:12, David Herrmann wrote: > Hi > > On Thu, Dec 29, 2016 at 9:48 PM, Daniel Vetter > wrote: >> - Remove the outdated hunk about driver documentation which somehow >> got misplaced here in the split-up. >> >> - Collect all the testing&validation stuff together and give the CRC >> section a heading for prettier output. >> >> Cc: Tomeu Vizoso >> Cc: Jani Nikula >> Signed-off-by: Daniel Vetter >> --- >> Documentation/gpu/drm-uapi.rst | 25 +++-- >> 1 file changed, 11 insertions(+), 14 deletions(-) > > Reviewed-by: David Herrmann Reviewed-by: Tomeu Vizoso Regards, Tomeu > > Thanks > David > >> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst >> index de3ac9f90f8f..fcc228ef5bc4 100644 >> --- a/Documentation/gpu/drm-uapi.rst >> +++ b/Documentation/gpu/drm-uapi.rst >> @@ -156,8 +156,12 @@ other hand, a driver requires shared state between >> clients which is >> visible to user-space and accessible beyond open-file boundaries, they >> cannot support render nodes. >> >> + >> +Testing and validation >> +== >> + >> Validating changes with IGT >> -=== >> +--- >> >> There's a collection of tests that aims to cover the whole functionality of >> DRM drivers and that can be used to check that changes to DRM drivers or the >> @@ -193,6 +197,12 @@ run-tests.sh is a wrapper around piglit that will >> execute the tests matching >> the -t options. A report in HTML format will be available in >> ./results/html/index.html. Results can be compared with piglit. >> >> +Display CRC Support >> +--- >> + >> +.. kernel-doc:: drivers/gpu/drm/drm_debugfs_crc.c >> + :doc: CRC ABI >> + >> VBlank event handling >> = >> >> @@ -209,16 +219,3 @@ DRM_IOCTL_MODESET_CTL >> mode setting, since on many devices the vertical blank counter is >> reset to 0 at some point during modeset. Modern drivers should not >> call this any more since with kernel mode setting it is a no-op. >> - >> -This second part of the GPU Driver Developer's Guide documents driver >> -code, implementation details and also all the driver-specific userspace >> -interfaces. Especially since all hardware-acceleration interfaces to >> -userspace are driver specific for efficiency and other reasons these >> -interfaces can be rather substantial. Hence every driver has its own >> -chapter. >> - >> -Testing and validation >> -== >> - >> -.. kernel-doc:: drivers/gpu/drm/drm_debugfs_crc.c >> - :doc: CRC ABI >> -- >> 2.7.4 >> >> ___ >> dri-devel mailing list >> dri-devel at lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ > Intel-gfx mailing list > Intel-gfx at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[PATCH 1/2] drm: Add target_vblank member to drm_crtc_state
On Sun, Jan 1, 2017 at 4:59 PM, Andrey Grodzovsky
wrote:
> This change allows usage of the new page_flip_target hook for
> drivers implementing the atomic path.
>
> Signed-off-by: Andrey Grodzovsky
> Reviewed-by: Harry Wentland
> Reviewed-by: Alex Deucher
Instead of patching your amdgpu version of the page_flip helper you
should patch at least the one in drm_atomic_helper..c, and then use
that one. We probably need a page_flip_target version of that, which
then opens some questions about how you would expose this for atomic
drivers and the atomic ioctl. Just adding this here in the shared
struct is somewhat pointless, you could do that in the
amdgpu_crtc_state struct too.
> ---
> include/drm/drm_crtc.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 946672f..3a7685f 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -156,6 +156,9 @@ struct drm_crtc_state {
> struct drm_property_blob *ctm;
> struct drm_property_blob *gamma_lut;
>
> + /* target vblank count to do a flip */
Please type real kerneldoc for this.
Thanks, Daniel
> + u32 target_vblank;
> +
> /**
> * @event:
> *
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH 13/17] drm/bridge: Use recommened kerneldoc for struct member refs
On Mon, Jan 02, 2017 at 11:53:03AM +0530, Archit Taneja wrote: > > > On 12/30/2016 2:18 AM, Daniel Vetter wrote: > > I just learned that &struct_name.member_name works and looks pretty > > even. It doesn't (yet) link to the member directly though, which would > > be really good for big structures or vfunc tables (where the > > per-member kerneldoc tends to be long). > > > > Also some minor drive-by polish where it makes sense, I read a lot > > of docs ... > > > > Cc: Archit Taneja > > Cc: Jani Nikula > > Cc: Chris Wilson > > Signed-off-by: Daniel Vetter > > --- > > drivers/gpu/drm/drm_bridge.c | 27 +++-- > > include/drm/drm_bridge.h | 48 > > +--- > > 2 files changed, 39 insertions(+), 36 deletions(-) > > > > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c > > index ae5e57ad718c..86a7637ba344 100644 > > --- a/drivers/gpu/drm/drm_bridge.c > > +++ b/drivers/gpu/drm/drm_bridge.c > > @@ -55,7 +55,7 @@ > > * just provide additional hooks to get the desired output at the end of > > the > > * encoder chain. > > * > > - * Bridges can also be chained up using the next pointer in &struct > > drm_bridge. > > + * Bridges can also be chained up using the &drm_bridge.next pointer. > > * > > * Both legacy CRTC helpers and the new atomic modeset helpers support > > bridges. > > */ > > @@ -179,7 +179,7 @@ void drm_bridge_detach(struct drm_bridge *bridge) > > * @mode: desired mode to be set for the bridge > > * @adjusted_mode: updated mode that works for this bridge > > * > > - * Calls ->mode_fixup() &drm_bridge_funcs op for all the bridges in the > > + * Calls &drm_bridge_funcs.mode_fixup for all the bridges in the > > * encoder chain, starting from the first bridge to the last. > > * > > * Note: the bridge passed should be the one closest to the encoder > > @@ -206,11 +206,10 @@ bool drm_bridge_mode_fixup(struct drm_bridge *bridge, > > EXPORT_SYMBOL(drm_bridge_mode_fixup); > > > > /** > > - * drm_bridge_disable - calls ->disable() &drm_bridge_funcs op for all > > - * bridges in the encoder chain. > > + * drm_bridge_disable - disables all bridges in the encoder chain > > * @bridge: bridge control structure > > * > > - * Calls ->disable() &drm_bridge_funcs op for all the bridges in the > > encoder > > + * Calls &drm_bridge_funcs.disable op for all the bridges in the encoder > > * chain, starting from the last bridge to the first. These are called > > before > > * calling the encoder's prepare op. > > * > > @@ -229,11 +228,10 @@ void drm_bridge_disable(struct drm_bridge *bridge) > > EXPORT_SYMBOL(drm_bridge_disable); > > > > /** > > - * drm_bridge_post_disable - calls ->post_disable() &drm_bridge_funcs op > > for > > - * all bridges in the encoder chain. > > + * drm_bridge_post_disable - cleans up after disabling all bridges in the > > encoder chain > > * @bridge: bridge control structure > > * > > - * Calls ->post_disable() &drm_bridge_funcs op for all the bridges in the > > + * Calls &drm_bridge_funcs.post_disable op for all the bridges in the > > * encoder chain, starting from the first bridge to the last. These are > > called > > * after completing the encoder's prepare op. > > * > > @@ -258,7 +256,7 @@ EXPORT_SYMBOL(drm_bridge_post_disable); > > * @mode: desired mode to be set for the bridge > > * @adjusted_mode: updated mode that works for this bridge > > * > > - * Calls ->mode_set() &drm_bridge_funcs op for all the bridges in the > > + * Calls &drm_bridge_funcs.mode_set op for all the bridges in the > > * encoder chain, starting from the first bridge to the last. > > * > > * Note: the bridge passed should be the one closest to the encoder > > @@ -278,11 +276,11 @@ void drm_bridge_mode_set(struct drm_bridge *bridge, > > EXPORT_SYMBOL(drm_bridge_mode_set); > > > > /** > > - * drm_bridge_pre_enable - calls ->pre_enable() &drm_bridge_funcs op for > > all > > - *bridges in the encoder chain. > > + * drm_bridge_pre_enable - prepares for enabling all > > + *bridges in the encoder chain > > * @bridge: bridge control structure > > * > > - * Calls ->pre_enable() &drm_bridge_funcs op for all the bridges in the > > encoder > > + * Calls &drm_bridge_funcs.pre_enable op for all the bridges in the encoder > > * chain, starting from the last bridge to the first. These are called > > * before calling the encoder's commit op. > > * > > @@ -301,11 +299,10 @@ void drm_bridge_pre_enable(struct drm_bridge *bridge) > > EXPORT_SYMBOL(drm_bridge_pre_enable); > > > > /** > > - * drm_bridge_enable - calls ->enable() &drm_bridge_funcs op for all > > bridges > > - *in the encoder chain. > > + * drm_bridge_enable - enables all bridges in the encoder chain > > * @bridge: bridge control structure > > * > > - * Calls ->enable() &drm_bridge_funcs op for all the bridges
[Intel-gfx] [PATCH 01/10] drm : adds Y-coordinate and Colorimetry Format
On Sat, Dec 31, 2016 at 07:48:38AM +0530, vathsala nagaraju wrote: > PSR2 vsc revision number hb2( as per table 6-11)is updated to > 4 or 5 based on Y cordinate and Colorimetry Format as below > 04h = 3D stereo + PSR/PSR2 + Y-coordinate. > 05h = -3D stereo- + PSR/PSR2 + Y-coordinate + Pixel Encoding/Colorimetry > Format indication. A DP Source device is allowed to indicate the pixel > encoding/colorimetry format to the DP Sink device with VSC SDP only when > the DP Sink device supports it ( > i.e.,VSC_SDP_EXTENSION_FOR_COLORIMETRY_SUPPORTED bit in the > DPRX_FEATURE_ENUMERATION_LIST register (DPCD Address 02210h, bit 3; > is set to 1). > > v2: (Jani) > - Change DP_PSR_Y_COORDINATE to DP_PSR2_SU_Y_COORDINATE_REQUIRED. > - Add DP_PSR2_SU_GRANULARITY_REQUIRED. > - Change DPRX_FEATURE_ENUMERATION_LIST to DP_DPRX. > - Add GTC_CAP and AV_SYNC_CAP, other bits in DPRX_FEATURE_ENUMERATION_LIST. > > v3: (Jani) > - Add support for bits 7:4 and 1 as per DP v1.4 for > DPRX_FEATURE_ENUMERATION_LIST. > > Cc: Rodrigo Vivi > Cc: Jim Bride > Signed-off-by: Vathsala Nagaraju > Signed-off-by: Patil Deepti Please cc the entire patch series to all mailing lists, so that people have the full context. Thanks, Daniel > --- > include/drm/drm_dp_helper.h | 13 - > 1 file changed, 12 insertions(+), 1 deletion(-) > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > index 55bbeb0..0468135 100644 > --- a/include/drm/drm_dp_helper.h > +++ b/include/drm/drm_dp_helper.h > @@ -194,7 +194,8 @@ > # define DP_PSR_SETUP_TIME_0(6 << 1) > # define DP_PSR_SETUP_TIME_MASK (7 << 1) > # define DP_PSR_SETUP_TIME_SHIFT1 > - > +# define DP_PSR2_SU_Y_COORDINATE_REQUIRED (1 << 4) /* eDP 1.4a */ > +# define DP_PSR2_SU_GRANULARITY_REQUIRED(1 << 5) /* eDP 1.4b */ > /* > * 0x80-0x8f describe downstream port capabilities, but there are two layouts > * based on whether DP_DETAILED_CAP_INFO_AVAILABLE was set. If it was not, > @@ -568,6 +569,16 @@ > #define DP_RECEIVER_ALPM_STATUS 0x200b /* eDP 1.4 */ > # define DP_ALPM_LOCK_TIMEOUT_ERROR (1 << 0) > > +#define DP_DPRX_FEATURE_ENUMERATION_LIST0x2210 /* DP 1.3 */ > +# define DP_GTC_CAP (1 << 0) /* DP 1.3 */ > +# define DP_SST_SPLIT_SDP_CAP(1 << 1) /* DP > 1.4 */ > +# define DP_AV_SYNC_CAP (1 << 2) /* DP > 1.3 */ > +# define DP_VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED(1 << 3) /* DP 1.3 */ > +# define DP_VSC_EXT_VESA_SDP_SUPPORTED (1 << 4) /* DP > 1.4 */ > +# define DP_VSC_EXT_VESA_SDP_CHAINING_SUPPORTED (1 << 5) /* DP > 1.4 */ > +# define DP_VSC_EXT_CEA_SDP_SUPPORTED(1 << 6) /* DP > 1.4 */ > +# define DP_VSC_EXT_CEA_SDP_CHAINING_SUPPORTED (1 << 7) /* DP > 1.4 */ > + > /* DP 1.2 Sideband message defines */ > /* peer device type - DP 1.2a Table 2-92 */ > #define DP_PEER_DEVICE_NONE 0x0 > -- > 1.9.1 > > ___ > Intel-gfx mailing list > Intel-gfx at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[Intel-gfx] [PATCH 01/10] drm : adds Y-coordinate and Colorimetry Format
On Sat, 31 Dec 2016, vathsala nagaraju wrote: > PSR2 vsc revision number hb2( as per table 6-11)is updated to > 4 or 5 based on Y cordinate and Colorimetry Format as below > 04h = 3D stereo + PSR/PSR2 + Y-coordinate. > 05h = -3D stereo- + PSR/PSR2 + Y-coordinate + Pixel Encoding/Colorimetry > Format indication. A DP Source device is allowed to indicate the pixel > encoding/colorimetry format to the DP Sink device with VSC SDP only when > the DP Sink device supports it ( > i.e.,VSC_SDP_EXTENSION_FOR_COLORIMETRY_SUPPORTED bit in the > DPRX_FEATURE_ENUMERATION_LIST register (DPCD Address 02210h, bit 3; > is set to 1). > > v2: (Jani) > - Change DP_PSR_Y_COORDINATE to DP_PSR2_SU_Y_COORDINATE_REQUIRED. > - Add DP_PSR2_SU_GRANULARITY_REQUIRED. > - Change DPRX_FEATURE_ENUMERATION_LIST to DP_DPRX. > - Add GTC_CAP and AV_SYNC_CAP, other bits in DPRX_FEATURE_ENUMERATION_LIST. > > v3: (Jani) > - Add support for bits 7:4 and 1 as per DP v1.4 for > DPRX_FEATURE_ENUMERATION_LIST. > > Cc: Rodrigo Vivi > Cc: Jim Bride > Signed-off-by: Vathsala Nagaraju > Signed-off-by: Patil Deepti Reviewed-by: Jani Nikula > --- > include/drm/drm_dp_helper.h | 13 - > 1 file changed, 12 insertions(+), 1 deletion(-) > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > index 55bbeb0..0468135 100644 > --- a/include/drm/drm_dp_helper.h > +++ b/include/drm/drm_dp_helper.h > @@ -194,7 +194,8 @@ > # define DP_PSR_SETUP_TIME_0(6 << 1) > # define DP_PSR_SETUP_TIME_MASK (7 << 1) > # define DP_PSR_SETUP_TIME_SHIFT1 > - > +# define DP_PSR2_SU_Y_COORDINATE_REQUIRED (1 << 4) /* eDP 1.4a */ > +# define DP_PSR2_SU_GRANULARITY_REQUIRED(1 << 5) /* eDP 1.4b */ > /* > * 0x80-0x8f describe downstream port capabilities, but there are two layouts > * based on whether DP_DETAILED_CAP_INFO_AVAILABLE was set. If it was not, > @@ -568,6 +569,16 @@ > #define DP_RECEIVER_ALPM_STATUS 0x200b /* eDP 1.4 */ > # define DP_ALPM_LOCK_TIMEOUT_ERROR (1 << 0) > > +#define DP_DPRX_FEATURE_ENUMERATION_LIST0x2210 /* DP 1.3 */ > +# define DP_GTC_CAP (1 << 0) /* DP 1.3 */ > +# define DP_SST_SPLIT_SDP_CAP(1 << 1) /* DP > 1.4 */ > +# define DP_AV_SYNC_CAP (1 << 2) /* DP > 1.3 */ > +# define DP_VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED(1 << 3) /* DP 1.3 */ > +# define DP_VSC_EXT_VESA_SDP_SUPPORTED (1 << 4) /* DP > 1.4 */ > +# define DP_VSC_EXT_VESA_SDP_CHAINING_SUPPORTED (1 << 5) /* DP > 1.4 */ > +# define DP_VSC_EXT_CEA_SDP_SUPPORTED(1 << 6) /* DP > 1.4 */ > +# define DP_VSC_EXT_CEA_SDP_CHAINING_SUPPORTED (1 << 7) /* DP > 1.4 */ > + > /* DP 1.2 Sideband message defines */ > /* peer device type - DP 1.2a Table 2-92 */ > #define DP_PEER_DEVICE_NONE 0x0 -- Jani Nikula, Intel Open Source Technology Center
[PATCH] drm/exynos/decon5433: configure sysreg in case of hardware trigger
In case of HW trigger mode, sysreg register should be configured to
enable TE functionality. The patch refactors also trigger setup function.
Signed-off-by: Andrzej Hajda
---
v2: fixed bitop operator (thanks Ilia)
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 40 +--
1 file changed, 32 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 6ca1f31..b63b8e6 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -13,9 +13,11 @@
#include
#include
#include
+#include
#include
#include
#include
+#include
#include
@@ -25,6 +27,9 @@
#include "exynos_drm_plane.h"
#include "exynos_drm_iommu.h"
+#define DSD_CFG_MUX 0x1004
+#define DSD_CFG_MUX_TE_UNMASK_GLOBAL BIT(13)
+
#define WINDOWS_NR 3
#define MIN_FB_WIDTH_FOR_16WORD_BURST 128
@@ -56,6 +61,7 @@ struct decon_context {
struct exynos_drm_plane planes[WINDOWS_NR];
struct exynos_drm_plane_config configs[WINDOWS_NR];
void __iomem*addr;
+ struct regmap *sysreg;
struct clk *clks[ARRAY_SIZE(decon_clks_name)];
int pipe;
unsigned long flags;
@@ -117,12 +123,22 @@ static void decon_disable_vblank(struct exynos_drm_crtc
*crtc)
static void decon_setup_trigger(struct decon_context *ctx)
{
- u32 val = !(ctx->out_type & I80_HW_TRG)
- ? TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F |
- TRIGCON_TE_AUTO_MASK | TRIGCON_SWTRIGEN
- : TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F |
- TRIGCON_HWTRIGMASK | TRIGCON_HWTRIGEN;
- writel(val, ctx->addr + DECON_TRIGCON);
+ if (!(ctx->out_type & (IFTYPE_I80 | I80_HW_TRG)))
+ return;
+
+ if (!(ctx->out_type & I80_HW_TRG)) {
+ writel(TRIGCON_TE_AUTO_MASK | TRIGCON_SWTRIGEN
+ | TRIGCON_TE_AUTO_MASK | TRIGCON_SWTRIGEN,
+ ctx->addr + DECON_TRIGCON);
+ return;
+ }
+
+ writel(TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F | TRIGCON_HWTRIGMASK
+ | TRIGCON_HWTRIGEN, ctx->addr + DECON_TRIGCON);
+
+ if (regmap_update_bits(ctx->sysreg, DSD_CFG_MUX,
+ DSD_CFG_MUX_TE_UNMASK_GLOBAL, ~0))
+ DRM_ERROR("Cannot update sysreg.\n");
}
static void decon_commit(struct exynos_drm_crtc *crtc)
@@ -147,8 +163,7 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
val = CMU_CLKGAGE_MODE_SFR_F | CMU_CLKGAGE_MODE_MEM_F;
writel(val, ctx->addr + DECON_CMU);
- if (ctx->out_type & (IFTYPE_I80 | I80_HW_TRG))
- decon_setup_trigger(ctx);
+ decon_setup_trigger(ctx);
/* lcd on and use command if */
val = VIDOUT_LCD_ON;
@@ -640,6 +655,15 @@ static int exynos5433_decon_probe(struct platform_device
*pdev)
ctx->out_type |= IFTYPE_I80;
}
+ if (ctx->out_type & I80_HW_TRG) {
+ ctx->sysreg = syscon_regmap_lookup_by_phandle(dev->of_node,
+ "samsung,disp-sysreg");
+ if (IS_ERR(ctx->sysreg)) {
+ dev_err(dev, "failed to get system register\n");
+ return PTR_ERR(ctx->sysreg);
+ }
+ }
+
for (i = 0; i < ARRAY_SIZE(decon_clks_name); i++) {
struct clk *clk;
--
2.7.4
[PATCH] drm: Constify drm_mode_config atomic helper private pointer
The drm_mode_config helper private field points to a structure of
function pointers that don't need to be modified at runtime. Make it
const.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/arm/malidp_drv.c | 2 +-
drivers/gpu/drm/drm_atomic_helper.c| 2 +-
drivers/gpu/drm/imx/imx-drm-core.c | 2 +-
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 2 +-
drivers/gpu/drm/virtio/virtgpu_display.c | 2 +-
include/drm/drm_mode_config.h | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 32f746e31379..64babce654e4 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -101,7 +101,7 @@ static void malidp_atomic_commit_tail(struct
drm_atomic_state *state)
drm_atomic_helper_cleanup_planes(drm, state);
}
-static struct drm_mode_config_helper_funcs malidp_mode_config_helpers = {
+static const struct drm_mode_config_helper_funcs malidp_mode_config_helpers = {
.atomic_commit_tail = malidp_atomic_commit_tail,
};
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 583f47f27b36..2099868ee9f7 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1197,7 +1197,7 @@ EXPORT_SYMBOL(drm_atomic_helper_commit_tail);
static void commit_tail(struct drm_atomic_state *old_state)
{
struct drm_device *dev = old_state->dev;
- struct drm_mode_config_helper_funcs *funcs;
+ const struct drm_mode_config_helper_funcs *funcs;
funcs = dev->mode_config.helper_private;
diff --git a/drivers/gpu/drm/imx/imx-drm-core.c
b/drivers/gpu/drm/imx/imx-drm-core.c
index 33404295b447..da9ae4f20aec 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -176,7 +176,7 @@ static void imx_drm_atomic_commit_tail(struct
drm_atomic_state *state)
drm_atomic_helper_cleanup_planes(dev, state);
}
-static struct drm_mode_config_helper_funcs imx_drm_mode_config_helpers = {
+static const struct drm_mode_config_helper_funcs imx_drm_mode_config_helpers =
{
.atomic_commit_tail = imx_drm_atomic_commit_tail,
};
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index 0f6eda023bd0..233497402246 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -193,7 +193,7 @@ rockchip_atomic_commit_tail(struct drm_atomic_state *state)
drm_atomic_helper_cleanup_planes(dev, state);
}
-static struct drm_mode_config_helper_funcs rockchip_mode_config_helpers = {
+static const struct drm_mode_config_helper_funcs rockchip_mode_config_helpers
= {
.atomic_commit_tail = rockchip_atomic_commit_tail,
};
diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c
b/drivers/gpu/drm/virtio/virtgpu_display.c
index 58048709c34e..10aa44d60344 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -346,7 +346,7 @@ static void vgdev_atomic_commit_tail(struct
drm_atomic_state *state)
drm_atomic_helper_cleanup_planes(dev, state);
}
-static struct drm_mode_config_helper_funcs virtio_mode_config_helpers = {
+static const struct drm_mode_config_helper_funcs virtio_mode_config_helpers = {
.atomic_commit_tail = vgdev_atomic_commit_tail,
};
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index bf9991b20611..88725cb355d7 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -653,7 +653,7 @@ struct drm_mode_config {
/* cursor size */
uint32_t cursor_width, cursor_height;
- struct drm_mode_config_helper_funcs *helper_private;
+ const struct drm_mode_config_helper_funcs *helper_private;
};
void drm_mode_config_init(struct drm_device *dev);
--
Regards,
Laurent Pinchart
[PATCH 2/2] [media] v4l: Add 10-bits per channel YUV pixel formats
Hi Randy,
Thanks for the patch.
On Mon, Jan 02, 2017 at 04:50:04PM +0800, Randy Li wrote:
> The formats added by this patch are:
> V4L2_PIX_FMT_P010
> V4L2_PIX_FMT_P010M
> Currently, none of driver uses those format, but some video device
> has been confirmed with could as those format for video output.
> The Rockchip's new decoder has supported those format for profile_10
> HEVC/AVC video.
>
> Signed-off-by: Randy Li
If the format resembles the existing formats but on a different bit depth,
it should be named in similar fashion.
Could you also add ReST documentation for the format, please?
The common requirement for merging patches that change interfaces has been
that there's a user for that change. It'll still help you to get this
reviewed now so the interface that the future hopefully-in-mainline driver
provides will not change.
> ---
> include/uapi/linux/videodev2.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 46e8a2e3..9e03f20 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -551,6 +551,7 @@ struct v4l2_pix_format {
> #define V4L2_PIX_FMT_NV61v4l2_fourcc('N', 'V', '6', '1') /* 16 Y/CrCb
> 4:2:2 */
> #define V4L2_PIX_FMT_NV24v4l2_fourcc('N', 'V', '2', '4') /* 24 Y/CbCr
> 4:4:4 */
> #define V4L2_PIX_FMT_NV42v4l2_fourcc('N', 'V', '4', '2') /* 24 Y/CrCb
> 4:4:4 */
> +#define V4L2_PIX_FMT_P010v4l2_fourcc('P', '0', '1', '0') /* 15 Y/CbCr
> 4:2:0, 10 bits per channel */
>
> /* two non contiguous planes - one Y, one Cr + Cb interleaved */
> #define V4L2_PIX_FMT_NV12M v4l2_fourcc('N', 'M', '1', '2') /* 12 Y/CbCr
> 4:2:0 */
> @@ -559,6 +560,7 @@ struct v4l2_pix_format {
> #define V4L2_PIX_FMT_NV61M v4l2_fourcc('N', 'M', '6', '1') /* 16 Y/CrCb
> 4:2:2 */
> #define V4L2_PIX_FMT_NV12MT v4l2_fourcc('T', 'M', '1', '2') /* 12 Y/CbCr
> 4:2:0 64x32 macroblocks */
> #define V4L2_PIX_FMT_NV12MT_16X16 v4l2_fourcc('V', 'M', '1', '2') /* 12
> Y/CbCr 4:2:0 16x16 macroblocks */
> +#define V4L2_PIX_FMT_P010M v4l2_fourcc('P', 'M', '1', '0') /* 15 Y/CbCr
> 4:2:0, 10 bits per channel */
>
> /* three planes - Y Cb, Cr */
> #define V4L2_PIX_FMT_YUV410 v4l2_fourcc('Y', 'U', 'V', '9') /* 9 YUV
> 4:1:0 */
--
Kind regards,
Sakari Ailus
e-mail: sakari.ailus at iki.fi XMPP: sailus at retiisi.org.uk
NULL pointer dereference in i915_gem_request_alloc()
On Sun, Jan 01, 2017 at 03:16:31PM -0600, vcaputo at pengaru.com wrote: > Hi Chris, > > I've uncovered a bug in i915_gem_request_alloc(): > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/i915/i915_gem_request.c?h=v4.9#n425 > > ctx here may be NULL, and i915_gem_context_get() is unconditionally > adding a reference to the supplied ctx, which makes things go boom when > NULL. ctx is not allowed to be NULL. > This happens for me in practice via: > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/i915/intel_display.c?h=v4.9#n12317 > > It appears engine->last_context may be NULL. It was meant to be using mmioflip if last_context was NULL, since we can do that immediately (i.e. lower latency) than via queuing the csflip. > The comment heading i915_gem_request_alloc() states that ctx shall be > NULL and that an appropriate context will be chosen automatically. This > is not what is currently implemented. Comment is wrong. -Chris -- Chris Wilson, Intel Open Source Technology Centre
[PATCH 1/1] drm/amd/amdgpu: get maximum and used UVD handles (v3)
Am 15.12.2016 um 23:43 schrieb Grazvydas Ignotas: > On Thu, Dec 15, 2016 at 4:12 PM, Christian König > wrote: >> Regarding which error code to return I think that Emil has the right idea >> here. >> >> Returning -EINVAL usually means that userspace provided an invalid value, >> but in this case it doesn't matter which value the UMD provide all of them >> would be invalid because starting with Polaris the hardware/firmware simply >> doesn't work this way any more. >> >> So using -ENODEV or maybe -ENODATA indeed sound like the right think to do >> here. > What about ERANGE then, "Math result not representable" aka infinity? > To me ENODEV is more like "the GPU you are asking about is not there" > and ENODATA "information you ask for is not known", although the later > still somewhat makes sense. Sorry for the delayed reply. I think EDATA would still make more sense than ERANGE, because the number of open sessions is simply not known any more. That the maximum number of sessions is now unlimited is just a side effect of the new handling if you ask me. Regards, Christian. > > Gražvydas
[PATCH 2/2] [media] v4l: Add 10-bits per channel YUV pixel formats
Hi,
On Mon, Jan 02, 2017 at 06:53:16PM +0800, ayaka wrote:
>
>
> On 01/02/2017 05:10 PM, Sakari Ailus wrote:
> >Hi Randy,
> >
> >Thanks for the patch.
> >
> >On Mon, Jan 02, 2017 at 04:50:04PM +0800, Randy Li wrote:
> >>The formats added by this patch are:
> >>V4L2_PIX_FMT_P010
> >>V4L2_PIX_FMT_P010M
> >>Currently, none of driver uses those format, but some video device
> >>has been confirmed with could as those format for video output.
> >>The Rockchip's new decoder has supported those format for profile_10
> >>HEVC/AVC video.
> >>
> >>Signed-off-by: Randy Li
> >If the format resembles the existing formats but on a different bit depth,
> >it should be named in similar fashion.
> Do you mean it would be better if it is called as NV12_10?
If it otherwise resembles NV12 but just has 10 bits per pixel, I think
NV12_10 is a good name for it.
> >
> >Could you also add ReST documentation for the format, please?
> I will.
> >
> >The common requirement for merging patches that change interfaces has been
> >that there's a user for that change. It'll still help you to get this
> The kernel used in rockchip has supported that format in drm driver, but
> just we don't have a agreement about the pixel format. As the Gstreamer and
> some others would call it with a P010_ prefix, but Mark(rockchip's drm
> author) prefer the something like NV12_10, that is why I sent out those
> patches, I want the upstream decided its final name.
Ack.
I think we haven't really tried to unify the format naming in the past
between the two subsystems. If existing conventions exist on both regarding
this format, then it's probably better to follow those.
Cc Laurent as well.
> >reviewed now so the interface that the future hopefully-in-mainline driver
> >provides will not change.
> >
> >>---
> >> include/uapi/linux/videodev2.h | 2 ++
> >> 1 file changed, 2 insertions(+)
> >>
> >>diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> >>index 46e8a2e3..9e03f20 100644
> >>--- a/include/uapi/linux/videodev2.h
> >>+++ b/include/uapi/linux/videodev2.h
> >>@@ -551,6 +551,7 @@ struct v4l2_pix_format {
> >> #define V4L2_PIX_FMT_NV61v4l2_fourcc('N', 'V', '6', '1') /* 16
> >> Y/CrCb 4:2:2 */
> >> #define V4L2_PIX_FMT_NV24v4l2_fourcc('N', 'V', '2', '4') /* 24
> >> Y/CbCr 4:4:4 */
> >> #define V4L2_PIX_FMT_NV42v4l2_fourcc('N', 'V', '4', '2') /* 24
> >> Y/CrCb 4:4:4 */
> >>+#define V4L2_PIX_FMT_P010v4l2_fourcc('P', '0', '1', '0') /* 15 Y/CbCr
> >>4:2:0, 10 bits per channel */
> >> /* two non contiguous planes - one Y, one Cr + Cb interleaved */
> >> #define V4L2_PIX_FMT_NV12M v4l2_fourcc('N', 'M', '1', '2') /* 12
> >> Y/CbCr 4:2:0 */
> >>@@ -559,6 +560,7 @@ struct v4l2_pix_format {
> >> #define V4L2_PIX_FMT_NV61M v4l2_fourcc('N', 'M', '6', '1') /* 16
> >> Y/CrCb 4:2:2 */
> >> #define V4L2_PIX_FMT_NV12MT v4l2_fourcc('T', 'M', '1', '2') /* 12
> >> Y/CbCr 4:2:0 64x32 macroblocks */
> >> #define V4L2_PIX_FMT_NV12MT_16X16 v4l2_fourcc('V', 'M', '1', '2') /* 12
> >> Y/CbCr 4:2:0 16x16 macroblocks */
> >>+#define V4L2_PIX_FMT_P010M v4l2_fourcc('P', 'M', '1', '0') /* 15 Y/CbCr
> >>4:2:0, 10 bits per channel */
> >> /* three planes - Y Cb, Cr */
> >> #define V4L2_PIX_FMT_YUV410 v4l2_fourcc('Y', 'U', 'V', '9') /* 9 YUV
> >> 4:1:0 */
>
--
Kind regards,
Sakari Ailus
e-mail: sakari.ailus at iki.fi XMPP: sailus at retiisi.org.uk
[PATCH v3 0/2] Add support for the S6E3HA2 panel on TM2 board
On 30.12.2016 07:58, Hoegeun Kwon wrote: > Purpose of this patch is add support for S6E3HA2 AMOLED panel on > the TM2 board. The first patch adds support for S6E3HA2 panel > device tree document and driver, the second patch add support for > S6E3HA2 panel device tree. > > Changes for V3: > > - In the DT binding document, made it clearly that the panel is a > child node of dsi. > - Fix reset-gpio active from high to low. > - Is the OF graph saying related to [1]? Yes, video-interfaces described in [1] are OF graphs described in [2] with additional properties specific for video pipelines. [2]: Documentation/devicetree/bindings/graph.txt > Althogh the panel is a child of dsi, I think OF graph necessary. > because if a remote-endpoint is not specified, the dsi also > panel is not probed. OK, I see the issue: dsi driver requires presence of DSI_PORT_OUT endpoint, because it needs to read MIPI-DSI burst and esc clock frequencies from these nodes, however it does not use it to get panel node, panel node is get by .attach callback. Probably these clock frequencies should be passed via struct mipi_dsi_device. So as for now I think it would be simpler to leave OF graph, as it is already used this way in other drivers. > - The display-timings has been fixed to be provided by the device > driver. however, I think display-timings is necessary in dts. > because if dts does not have display-timings, dsi will not load. After examining drivers it looks like these timings, beside panel, are read by MIC driver, and this is wrong. MIC driver shouldn't peek into other driver's nodes, it can use DRM callbacks (mode_fixup, mode_set) to get necessary information. And more importantly display-timings in panels are not accepted by panels maintainer AFAIK, see [1] for rationale. [1]: https://sietch-tagr.blogspot.de/2016/04/display-panels-are-not-special.html Regards Andrzej > > [1]: Documentation/devicetree/bindings/media/video-interfaces.txt > > Hoegeun Kwon (1): > drm/panel: Add support for S6E3HA2 panel driver on TM2 board > > Hyungwon Hwang (1): > arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board > > .../bindings/display/panel/samsung,s6e3ha2.txt | 58 ++ > arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 31 + > drivers/gpu/drm/panel/Kconfig | 6 + > drivers/gpu/drm/panel/Makefile | 1 + > drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 741 > + > 5 files changed, 837 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt > create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c >
[PATCH] drm/atomic-helper: roll out commit synchronization
Hi Daniel,
Thank you for the patch.
On Wednesday 08 Jun 2016 17:15:36 Daniel Vetter wrote:
> To facilitate easier reviewing this is split out from the overall
> nonblocking commit rework. It just rolls out the helper functions
> and uses them in the main drm_atomic_helper_commit() function
> to make it clear where in the flow they're used.
>
> The next patch will actually split drm_atomic_helper_commit() into
> 2 pieces, with the tail being run asynchronously from a worker.
>
> v2: Improve kerneldocs (Maarten).
>
> v3: Don't convert ERESTARTSYS to EINTR (Maarten). Also don't fail if
> the wait succeed in stall_check - we need to convert that case (it
> returns the remaining jiffies) to 0 for success.
>
> v4: Switch to long for wait_for_completion_timeout return value
> everywhere (Maarten).
>
> Reviewed-by: Maarten Lankhorst
> Tested-by: Tomeu Vizoso
> Cc: Maarten Lankhorst
> Cc: Tomeu Vizoso
> Cc: Daniel Stone
> Tested-by: Liviu Dudau
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 347 +
> include/drm/drm_atomic_helper.h | 7 +
> 2 files changed, 354 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c index 326ee34cdba4..fa2f89253b17
> 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1155,6 +1155,10 @@ int drm_atomic_helper_commit(struct drm_device *dev,
> if (nonblock)
> return -EBUSY;
>
> + ret = drm_atomic_helper_setup_commit(state, nonblock);
> + if (ret)
> + return ret;
> +
> ret = drm_atomic_helper_prepare_planes(dev, state);
> if (ret)
> return ret;
> @@ -1185,16 +1189,22 @@ int drm_atomic_helper_commit(struct drm_device *dev,
>
> drm_atomic_helper_wait_for_fences(dev, state);
>
> + drm_atomic_helper_wait_for_dependencies(state);
> +
> drm_atomic_helper_commit_modeset_disables(dev, state);
>
> drm_atomic_helper_commit_planes(dev, state, false);
>
> drm_atomic_helper_commit_modeset_enables(dev, state);
>
> + drm_atomic_helper_commit_hw_done(state);
> +
> drm_atomic_helper_wait_for_vblanks(dev, state);
>
> drm_atomic_helper_cleanup_planes(dev, state);
>
> + drm_atomic_helper_commit_cleanup_done(state);
> +
> drm_atomic_state_free(state);
>
> return 0;
> @@ -1239,6 +1249,306 @@ EXPORT_SYMBOL(drm_atomic_helper_commit);
> * being displayed.
> */
>
> +static int stall_checks(struct drm_crtc *crtc, bool nonblock)
> +{
> + struct drm_crtc_commit *commit, *stall_commit = NULL;
> + bool completed = true;
> + int i;
> + long ret = 0;
> +
> + spin_lock(&crtc->commit_lock);
> + i = 0;
> + list_for_each_entry(commit, &crtc->commit_list, commit_entry) {
> + if (i == 0) {
> + completed = try_wait_for_completion(&commit-
>flip_done);
> + /* Userspace is not allowed to get ahead of the
previous
> + * commit with nonblocking ones. */
> + if (!completed && nonblock) {
> + spin_unlock(&crtc->commit_lock);
> + return -EBUSY;
> + }
> + } else if (i == 1) {
> + stall_commit = commit;
> + drm_crtc_commit_get(stall_commit);
> + } else
> + break;
> +
> + i++;
> + }
> + spin_unlock(&crtc->commit_lock);
> +
> + if (!stall_commit)
> + return 0;
> +
> + /* We don't want to let commits get ahead of cleanup work too much,
> + * stalling on 2nd previous commit means triple-buffer won't ever
stall.
> + */
> + ret = wait_for_completion_interruptible_timeout(&commit->cleanup_done,
> + 10*HZ);
> + if (ret == 0)
> + DRM_ERROR("[CRTC:%d:%s] cleanup_done timed out\n",
> + crtc->base.id, crtc->name);
> +
> + drm_crtc_commit_put(stall_commit);
> +
> + return ret < 0 ? ret : 0;
> +}
> +
> +/**
> + * drm_atomic_helper_setup_commit - setup possibly nonblocking commit
> + * @state: new modeset state to be committed
> + * @nonblock: whether nonblocking behavior is requested.
> + *
> + * This function prepares @state to be used by the atomic helper's support
> for + * nonblocking commits. Drivers using the nonblocking commit
> infrastructure + * should always call this function from their
> ->atomic_commit hook. + *
> + * To be able to use this support drivers need to use a few more helper
> + * functions. drm_atomic_helper_wait_for_dependencies() must be called
> before + * actually committing the hardware state, and for nonblocking
> commits this call + * must be placed in the async worker. See also
> drm_atomic_helper_swap_state() + * and it's stall parameter, for when a
> driver's commit hoo
[PATCH] drm: add fourcc codes for 16bit R and GR
Hi
On Mon, Jan 2, 2017 at 11:41 AM, Rainer Hochecker
wrote:
> From: Rainer Hochecker
>
> Add fourcc codes for 16bit planes. Required by mesa for
> eglCreateImageKHR to access P010 surfaces created by vaapi.
>
> Signed-off-by: Rainer Hochecker
> ---
> include/uapi/drm/drm_fourcc.h | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index a5890bf..e6ab638 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -41,10 +41,16 @@ extern "C" {
> /* 8 bpp Red */
> #define DRM_FORMAT_R8 fourcc_code('R', '8', ' ', ' ') /* [7:0] R */
>
> +/* 16 bpp Red */
> +#define DRM_FORMAT_R16 fourcc_code('R', '1', '6', ' ') /* [15:0] R */
> +
> /* 16 bpp RG */
> #define DRM_FORMAT_RG88fourcc_code('R', 'G', '8', '8') /*
> [15:0] R:G 8:8 little endian */
> #define DRM_FORMAT_GR88fourcc_code('G', 'R', '8', '8') /*
> [15:0] G:R 8:8 little endian */
>
> +/* 32 bpp GR */
> +#define DRM_FORMAT_GR16fourcc_code('G', 'R', '1', '6') /*
> [31:0] G:R 16:16 little endian */
> +
Shouldn't it be 'G', 'R', '3', '2'?
Also, please put dri-devel on CC.
Thanks
David
> /* 8 bpp RGB */
> #define DRM_FORMAT_RGB332 fourcc_code('R', 'G', 'B', '8') /* [7:0]
> R:G:B 3:3:2 */
> #define DRM_FORMAT_BGR233 fourcc_code('B', 'G', 'R', '8') /* [7:0]
> B:G:R 2:3:3 */
> --
> 2.9.3
>
[PATCH 06/27] drm/sun4i: Implement some semblance of vblank event handling
Hi Daniel,
On Wednesday 08 Jun 2016 14:18:58 Daniel Vetter wrote:
> atomic_flush seems to be the right place, right after we commit the
> plane updates. Again use the fullproof version, since the pipe might
> be off.
>
> Cc: Boris Brezillon
> Cc: Maxime Ripard
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/sun4i/sun4i_crtc.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_crtc.c
> b/drivers/gpu/drm/sun4i/sun4i_crtc.c index 4182a21f5923..f628b6d8f23f
> 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_crtc.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_crtc.c
> @@ -51,10 +51,22 @@ static void sun4i_crtc_atomic_flush(struct drm_crtc
> *crtc, {
> struct sun4i_crtc *scrtc = drm_crtc_to_sun4i_crtc(crtc);
> struct sun4i_drv *drv = scrtc->drv;
> + struct drm_pending_vblank_event *event = crtc->state->event;
>
> DRM_DEBUG_DRIVER("Committing plane changes\n");
>
> sun4i_backend_commit(drv->backend);
> +
> + if (event) {
> + crtc->state->event = NULL;
> +
> + spin_lock_irq(&crtc->dev->event_lock);
> + if (drm_crtc_vblank_get(crtc) == 0)
> + drm_crtc_arm_vblank_event(crtc, event);
> + else
> + drm_crtc_send_vblank_event(crtc, event);
> + spin_unlock_irq(&crtc->dev->event_lock);
> + }
Is it me, or is it entirely useless given the code in
sun4i_crtc_atomic_flush() that sets crtc->state->event to NULL ?
AuthorDate: Wed Jun 8 14:18:58 2016 +0200
CommitDate: Fri Jun 10 16:55:48 2016 +0200
It would have been worth it waiting for the maintainers to review the patch...
You've added similar code to a bunch of drivers. How do you protect against
the race conditions documented in the drm_crtc_arm_vblank_event() function ?
> }
>
> static void sun4i_crtc_disable(struct drm_crtc *crtc)
--
Regards,
Laurent Pinchart
[Bug 99219] The Stanley Parable GPU hang when starting a new game
https://bugs.freedesktop.org/show_bug.cgi?id=99219 --- Comment #2 from Samuel Pitoiset --- Thanks for reporting this. I can reproduce the hang on rx 480 with latest mesa/llvm git. It hangs at drawcall 674985. I will investigate. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170102/644f64f4/attachment.html>
[PATCH v14 0/4] New debugfs API for capturing CRC of frames
Hi, here are the patches that remain to be merged in this series. Since v13, I have added a patch that makes open() block until the first CRC comes. This is because otherwise, userspace would need to guess how much time this particular HW takes to become ready to generate frame CRCs. This patch could be dropped if it's preferred that userspace waits for the first frame CRC to come before assuming that the HW is ready. The other patches are unchanged. Thanks, Tomeu Tomeu Vizoso (4): drm: Move locking into drm_debugfs_crtc_crc_add drm: crc: Wait for a frame before returning from open() drm/i915: Use new CRC debugfs API drm/i915: Put "cooked" vlank counters in frame CRC lines drivers/gpu/drm/drm_debugfs_crc.c | 32 +--- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/i915_irq.c | 81 -- drivers/gpu/drm/i915/intel_display.c | 1 + drivers/gpu/drm/i915/intel_drv.h | 6 +++ drivers/gpu/drm/i915/intel_pipe_crc.c | 94 ++- 6 files changed, 169 insertions(+), 46 deletions(-) -- 2.9.3
[PATCH v14 1/4] drm: Move locking into drm_debugfs_crtc_crc_add
There's no reason any more for callers of this function to take the lock
themselves, so just move the lock to the function to avoid confusion and
bugs when more callers are contributed.
Signed-off-by: Tomeu Vizoso
Reviewed-by: Emil Velikov
Reviewed-by: Robert Foss
---
drivers/gpu/drm/drm_debugfs_crc.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_debugfs_crc.c
b/drivers/gpu/drm/drm_debugfs_crc.c
index 00e771fb7df2..68b171af237b 100644
--- a/drivers/gpu/drm/drm_debugfs_crc.c
+++ b/drivers/gpu/drm/drm_debugfs_crc.c
@@ -325,16 +325,19 @@ int drm_crtc_add_crc_entry(struct drm_crtc *crtc, bool
has_frame,
struct drm_crtc_crc_entry *entry;
int head, tail;
- assert_spin_locked(&crc->lock);
+ spin_lock(&crc->lock);
/* Caller may not have noticed yet that userspace has stopped reading */
- if (!crc->opened)
+ if (!crc->opened) {
+ spin_unlock(&crc->lock);
return -EINVAL;
+ }
head = crc->head;
tail = crc->tail;
if (CIRC_SPACE(head, tail, DRM_CRC_ENTRIES_NR) < 1) {
+ spin_unlock(&crc->lock);
DRM_ERROR("Overflow of CRC buffer, userspace reads too
slow.\n");
return -ENOBUFS;
}
@@ -347,6 +350,8 @@ int drm_crtc_add_crc_entry(struct drm_crtc *crtc, bool
has_frame,
head = (head + 1) & (DRM_CRC_ENTRIES_NR - 1);
crc->head = head;
+ spin_unlock(&crc->lock);
+
return 0;
}
EXPORT_SYMBOL_GPL(drm_crtc_add_crc_entry);
--
2.9.3
[PATCH v14 2/4] drm: crc: Wait for a frame before returning from open()
Don't return from the open() call on the crc/data file until the HW has
produced a first frame, as there's great variability in when the HW is
able to do that and userspace shouldn't have to guess when this specific
HW is ready to start giving frame CRCs.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/drm_debugfs_crc.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_debugfs_crc.c
b/drivers/gpu/drm/drm_debugfs_crc.c
index 68b171af237b..8b0d4d78 100644
--- a/drivers/gpu/drm/drm_debugfs_crc.c
+++ b/drivers/gpu/drm/drm_debugfs_crc.c
@@ -125,6 +125,12 @@ static const struct file_operations
drm_crtc_crc_control_fops = {
.write = crc_control_write
};
+static int crtc_crc_data_count(struct drm_crtc_crc *crc)
+{
+ assert_spin_locked(&crc->lock);
+ return CIRC_CNT(crc->head, crc->tail, DRM_CRC_ENTRIES_NR);
+}
+
static int crtc_crc_open(struct inode *inode, struct file *filep)
{
struct drm_crtc *crtc = inode->i_private;
@@ -160,8 +166,19 @@ static int crtc_crc_open(struct inode *inode, struct file
*filep)
crc->entries = entries;
crc->values_cnt = values_cnt;
crc->opened = true;
+
+ /*
+* Only return once we got a first frame, so userspace doesn't have to
+* guess when this particular piece of HW will be ready to start
+* generating CRCs.
+*/
+ ret = wait_event_interruptible_lock_irq(crc->wq,
+ crtc_crc_data_count(crc),
+ crc->lock);
spin_unlock_irq(&crc->lock);
+ WARN_ON(ret);
+
return 0;
err_disable:
@@ -189,12 +206,6 @@ static int crtc_crc_release(struct inode *inode, struct
file *filep)
return 0;
}
-static int crtc_crc_data_count(struct drm_crtc_crc *crc)
-{
- assert_spin_locked(&crc->lock);
- return CIRC_CNT(crc->head, crc->tail, DRM_CRC_ENTRIES_NR);
-}
-
/*
* 1 frame field of 10 chars plus a number of CRC fields of 10 chars each,
space
* separated, with a newline at the end and null-terminated.
--
2.9.3
[PATCH v14 3/4] drm/i915: Use new CRC debugfs API
The core provides now an ABI to userspace for generation of frame CRCs,
so implement the ->set_crc_source() callback and reuse as much code as
possible with the previous ABI implementation.
When handling the pageflip interrupt, we skip 1 or 2 frames depending on
the HW because they contain wrong values. For the legacy ABI for
generating frame CRCs, this was done in userspace but now that we have a
generic ABI it's better if it's not exposed by the kernel.
v2:
- Leave the legacy implementation in place as the ABI implementation
in the core is incompatible with it.
v3:
- Use the "cooked" vblank counter so we have a whole 32 bits.
- Make sure we don't mess with the state of the legacy CRC capture
ABI implementation.
v4:
- Keep use of get_vblank_counter as in the legacy code, will be
changed in a followup commit.
v5:
- Skip first frame or two as it's known that they contain wrong
data.
- A few fixes suggested by Emil Velikov.
v6:
- Rework programming of the HW registers to preserve previous
behavior.
v7:
- Address whitespace issue.
- Added a comment on why in the implementation of the new ABI we
skip the 1st or 2nd frames.
v9:
- Add stub for intel_crtc_set_crc_source.
v12:
- Rebased.
- Remove stub for intel_crtc_set_crc_source and instead set the
callback to NULL (Jani Nikula).
Signed-off-by: Tomeu Vizoso
Reviewed-by: Emil Velikov
Reviewed-by: Robert Foss
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_irq.c | 81 --
drivers/gpu/drm/i915/intel_display.c | 1 +
drivers/gpu/drm/i915/intel_drv.h | 6 +++
drivers/gpu/drm/i915/intel_pipe_crc.c | 94 ++-
5 files changed, 145 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 77d7a079c51b..b8a66cc225ff 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1886,6 +1886,7 @@ struct intel_pipe_crc {
enum intel_pipe_crc_source source;
int head, tail;
wait_queue_head_t wq;
+ int skipped;
};
struct i915_frontbuffer_tracking {
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index a0e70f5b3aad..24b7620c1005 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1553,41 +1553,70 @@ static void display_pipe_crc_irq_handler(struct
drm_i915_private *dev_priv,
{
struct intel_pipe_crc *pipe_crc = &dev_priv->pipe_crc[pipe];
struct intel_pipe_crc_entry *entry;
- int head, tail;
+ struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
+ struct drm_driver *driver = dev_priv->drm.driver;
+ uint32_t crcs[5];
+ int head, tail, ret;
+ u32 frame;
spin_lock(&pipe_crc->lock);
+ if (pipe_crc->source) {
+ if (!pipe_crc->entries) {
+ spin_unlock(&pipe_crc->lock);
+ DRM_DEBUG_KMS("spurious interrupt\n");
+ return;
+ }
- if (!pipe_crc->entries) {
- spin_unlock(&pipe_crc->lock);
- DRM_DEBUG_KMS("spurious interrupt\n");
- return;
- }
-
- head = pipe_crc->head;
- tail = pipe_crc->tail;
+ head = pipe_crc->head;
+ tail = pipe_crc->tail;
- if (CIRC_SPACE(head, tail, INTEL_PIPE_CRC_ENTRIES_NR) < 1) {
- spin_unlock(&pipe_crc->lock);
- DRM_ERROR("CRC buffer overflowing\n");
- return;
- }
+ if (CIRC_SPACE(head, tail, INTEL_PIPE_CRC_ENTRIES_NR) < 1) {
+ spin_unlock(&pipe_crc->lock);
+ DRM_ERROR("CRC buffer overflowing\n");
+ return;
+ }
- entry = &pipe_crc->entries[head];
+ entry = &pipe_crc->entries[head];
- entry->frame = dev_priv->drm.driver->get_vblank_counter(&dev_priv->drm,
-pipe);
- entry->crc[0] = crc0;
- entry->crc[1] = crc1;
- entry->crc[2] = crc2;
- entry->crc[3] = crc3;
- entry->crc[4] = crc4;
+ entry->frame = driver->get_vblank_counter(&dev_priv->drm, pipe);
+ entry->crc[0] = crc0;
+ entry->crc[1] = crc1;
+ entry->crc[2] = crc2;
+ entry->crc[3] = crc3;
+ entry->crc[4] = crc4;
- head = (head + 1) & (INTEL_PIPE_CRC_ENTRIES_NR - 1);
- pipe_crc->head = head;
+ head = (head + 1) & (INTEL_PIPE_CRC_ENTRIES_NR - 1);
+ pipe_crc->head = head;
- spin_unlock(&pipe_crc->lock);
+ spin_unlock(&pipe_crc->lock);
- wake_up_interruptible(&pipe_crc->wq);
+ wake_up_interruptible(&pipe_crc->wq);
+ } else {
+ /
[PATCH v14 4/4] drm/i915: Put "cooked" vlank counters in frame CRC lines
Use drm_accurate_vblank_count so we have the full 32 bit to represent
the frame counter and userspace has a simpler way of knowing when the
counter wraps around.
Signed-off-by: Tomeu Vizoso
Reviewed-by: Emil Velikov
Reviewed-by: Robert Foss
---
drivers/gpu/drm/i915/i915_irq.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 24b7620c1005..c0e3d1c1b4f0 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1557,7 +1557,6 @@ static void display_pipe_crc_irq_handler(struct
drm_i915_private *dev_priv,
struct drm_driver *driver = dev_priv->drm.driver;
uint32_t crcs[5];
int head, tail, ret;
- u32 frame;
spin_lock(&pipe_crc->lock);
if (pipe_crc->source) {
@@ -1612,8 +1611,9 @@ static void display_pipe_crc_irq_handler(struct
drm_i915_private *dev_priv,
crcs[2] = crc2;
crcs[3] = crc3;
crcs[4] = crc4;
- frame = driver->get_vblank_counter(&dev_priv->drm, pipe);
- ret = drm_crtc_add_crc_entry(&crtc->base, true, frame, crcs);
+ ret = drm_crtc_add_crc_entry(&crtc->base, true,
+
drm_accurate_vblank_count(&crtc->base),
+crcs);
if (!ret)
wake_up_interruptible(&crtc->base.crc.wq);
}
--
2.9.3
[PATCH] drm/edid: constify edid quirk list
On Wed, 28 Dec 2016, Daniel Vetter wrote:
> On Wed, Dec 28, 2016 at 01:06:26PM +0200, Jani Nikula wrote:
>> No reason not to be const.
>>
>> Signed-off-by: Jani Nikula
>
> Reviewed-by: Daniel Vetter
Pushed, thanks for the review.
BR,
Jani.
>
>> ---
>> drivers/gpu/drm/drm_edid.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 67d6a73731d8..4ff04aa84dd0 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -91,7 +91,7 @@ struct detailed_mode_closure {
>> #define LEVEL_GTF2 2
>> #define LEVEL_CVT 3
>>
>> -static struct edid_quirk {
>> +static const struct edid_quirk {
>> char vendor[4];
>> int product_id;
>> u32 quirks;
>> @@ -1478,7 +1478,7 @@ EXPORT_SYMBOL(drm_edid_duplicate);
>> *
>> * Returns true if @vendor is in @edid, false otherwise
>> */
>> -static bool edid_vendor(struct edid *edid, char *vendor)
>> +static bool edid_vendor(struct edid *edid, const char *vendor)
>> {
>> char edid_vendor[3];
>>
>> @@ -1498,7 +1498,7 @@ static bool edid_vendor(struct edid *edid, char
>> *vendor)
>> */
>> static u32 edid_get_quirks(struct edid *edid)
>> {
>> -struct edid_quirk *quirk;
>> +const struct edid_quirk *quirk;
>> int i;
>>
>> for (i = 0; i < ARRAY_SIZE(edid_quirk_list); i++) {
>> --
>> 2.1.4
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Jani Nikula, Intel Open Source Technology Center
[PATCH libdrm 2/3] xf86drm: Add USB support
On Sat, Dec 24, 2016 at 04:38:04PM +, Emil Velikov wrote:
> Hi Thierry,
>
> On 23 December 2016 at 17:49, Thierry Reding
> wrote:
> > Allow DRM/KMS devices hosted on USB to be detected by the drmDevice
> > infrastructure.
> >
> > Signed-off-by: Thierry Reding
> > ---
> > Note that this is completely untested because I don't have a UDL device
> > for testing. I'm fairly confident that this will work, though, and it'd
> > be nice to include it before the new platform and host1x busses because
> > support for it existed in the kernel longer than for platform devices.
> >
> Functionality looks spot on, but I'm a bit hesitant to get this in
> without any testing.
> Can we please extend tests/drmdevice.c (separate patch?) as poke
> someone on dri-devel/xorg-devel to give it a quick run ?
I can do that.
> > +static int drmParseUsbDeviceInfo(int maj, int min, drmUsbDeviceInfoPtr
> > info)
> > +{
> > +char path[PATH_MAX + 1], *value;
> > +unsigned int vendor, product;
> > +int ret;
> > +
> > +snprintf(path, PATH_MAX, "/sys/dev/char/%d:%d/device", maj, min);
> > +
> > +value = sysfs_uevent_get(path, "PRODUCT");
> > +ret = sscanf(value, "%x/%x", &vendor, &product);
> > +free(value);
> > +
> > +if (ret <= 0)
> > +return -errno;
> > +
> > +info->vendor = vendor;
> > +info->product = product;
> > +
> Worth fetching bcdDevice as well ?
This is currently only parsing the uevent file, which doesn't have
bcdDevice. The only data that isn't currently being parsed is TYPE
(bDeviceClass/bdeviceSubClass/bDeviceProtocol), not sure if we'd
want that.
I could of course read bcdDevice from the bcdDevice file.
One thing that I realized the other day, and it's relevant to all of
drmDevice, not just USB, is that we don't have a good way of preserving
ABI compatibility. With the USB and platform/host1x bus patches we're
not running into problems yet, but consider what would happen if we
added more bus or device info. The drmDevice.businfo and
drmDevice.deviceinfo unions could be growing beyond what they are now,
causing applications written against old versions to potentially
allocate too little memory.
I wonder if that's something we need to care about. As long as we keep
the bus and device info fixed after they've been added, we should be
safe because the bus type will be unknown to earlier versions and hence
cause the code to error out early. Technically we wouldn't be able to
ever extend one type of bus or device info, though.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170102/c38623ed/attachment.sig>
[PATCH libdrm 3/3] xf86drm: Add platform and host1x bus support
On Sat, Dec 24, 2016 at 05:00:27PM +, Emil Velikov wrote:
> On 23 December 2016 at 17:49, Thierry Reding
> wrote:
> > From: Thierry Reding
> >
> > ARM SoCs usually have their DRM/KMS devices on the platform bus, so add
> > support for that to enable these devices to be used with the drmDevice
> > infrastructure.
> >
> > NVIDIA Tegra SoCs have an additional level in the hierarchy and DRM/KMS
> > devices can also be on the host1x bus. This is mostly equivalent to the
> > platform bus.
> >
> > Signed-off-by: Thierry Reding
> > ---
> > Note that we could probably get away with treating host1x as platform
> > bus. However, they are technically two different busses in the kernel
> > and hence we may want to make use of that differentiation later on.
> >
> Admittedly there's no clear cut either way, but I'm inclined to have
> host1x as platform.
> I'm leaning towards that since there is no /sys/bus/host1x (afaict),
Actually there is:
# find /sys/bus/host1x
/sys/bus/host1x
/sys/bus/host1x/drivers_probe
/sys/bus/host1x/devices
/sys/bus/host1x/devices/drm
/sys/bus/host1x/uevent
/sys/bus/host1x/drivers
/sys/bus/host1x/drivers/drm
/sys/bus/host1x/drivers/drm/bind
/sys/bus/host1x/drivers/drm/unbind
/sys/bus/host1x/drivers/drm/module
/sys/bus/host1x/drivers/drm/uevent
/sys/bus/host1x/drivers/drm/drm
/sys/bus/host1x/drivers_autoprobe
> plus otherwise devices (like imx-vpu/vc4) will end with their own bus
> type.
I don't think that would happen. Tegra is somewhat special in this case
because of the host1x device that is a parent for both display and
capture devices. The host1x bus is architected to allow binding each of
the DRM/KMS and V4L2 devices (the V4L2 driver hasn't been merged yet)
to the host1x device.
The reason for this is mostly historical. Back when Tegra support was
added there was a strict rule against adding dummy device nodes to the
device tree. For Tegra this wasn't much of a problem because the host1x
device is the logical choice for a parent, so I just had to write some
glue (the host1x bus) to instantiate a dummy device for each composite
driver.
Later on the component/master infrastructure was added and the rules
regarding dummy device nodes were relaxed, so as far as I know all other
devices end up anchored to a dummy device on the platform bus.
> > +static int drmParsePlatformBusInfo(int maj, int min, drmPlatformBusInfoPtr
> > info)
> > +{
> > +char path[PATH_MAX + 1], *name;
> > +
> > +snprintf(path, PATH_MAX, "/sys/dev/char/%d:%d/device", maj, min);
> > +
> > +name = sysfs_uevent_get(path, "OF_FULLNAME");
> > +strcpy(info->fullname, name);
> > +free(name);
> > +
> Let's be extra careful and ensure that we don't overrun (and properly
> terminate) the fixed size fullname[].
Okay, will do.
> > +return 0;
> > +}
> > +
> > +static int drmParsePlatformDeviceInfo(int maj, int min,
> > + drmPlatformDeviceInfoPtr info)
> > +{
> > +/* XXX fill in platform device info */
> > +
> Not 100% sure what exactly we should consider bus and what device
> info, either way an empty struct is not going to go well.
> As a food for thought, here is some info for imx/etna and vc4.
>
> cat /sys/dev/char/226\:*/device/uevent
>
> DRIVER=etnaviv
> OF_NAME=gpu-subsystem
> OF_FULLNAME=/gpu-subsystem
> OF_COMPATIBLE_0=fsl,imx-gpu-subsystem
> OF_COMPATIBLE_N=1
> MODALIAS=of:Ngpu-subsystemTCfsl,imx-gpu-subsystem
> DRIVER=imx-drm
> OF_NAME=display-subsystem
> OF_FULLNAME=/display-subsystem
> OF_COMPATIBLE_0=fsl,imx-display-subsystem
> OF_COMPATIBLE_N=1
>
> DRIVER=vc4-drm
> OF_NAME=gpu
> OF_FULLNAME=/soc/gpu
> OF_COMPATIBLE_0=brcm,bcm2835-vc4
> OF_COMPATIBLE_N=1
> MODALIAS=of:NgpuTCbrcm,bcm2835-vc4
I think the full name is appropriate for bus info because it's about the
closest thing we have to address the device (the equivalent to domain,
bus, device and function numbers).
The list of compatible strings might be suitable for device information
and might be useful for drivers to determine capabilities if the kernel
doesn't have another means of communicating that to userspace.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170102/d8a2088f/attachment.sig>
[PATCH] drm: add fourcc codes for 16bit R and GR
On Mon, Jan 02, 2017 at 01:23:23PM +0100, David Herrmann wrote:
> Hi
>
> On Mon, Jan 2, 2017 at 11:41 AM, Rainer Hochecker
> wrote:
> > From: Rainer Hochecker
> >
> > Add fourcc codes for 16bit planes. Required by mesa for
> > eglCreateImageKHR to access P010 surfaces created by vaapi.
> >
> > Signed-off-by: Rainer Hochecker
> > ---
> > include/uapi/drm/drm_fourcc.h | 6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> > index a5890bf..e6ab638 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -41,10 +41,16 @@ extern "C" {
> > /* 8 bpp Red */
> > #define DRM_FORMAT_R8 fourcc_code('R', '8', ' ', ' ') /* [7:0] R
> > */
> >
> > +/* 16 bpp Red */
> > +#define DRM_FORMAT_R16 fourcc_code('R', '1', '6', ' ') /* [15:0] R
> > */
> > +
> > /* 16 bpp RG */
> > #define DRM_FORMAT_RG88fourcc_code('R', 'G', '8', '8') /*
> > [15:0] R:G 8:8 little endian */
> > #define DRM_FORMAT_GR88fourcc_code('G', 'R', '8', '8') /*
> > [15:0] G:R 8:8 little endian */
> >
> > +/* 32 bpp GR */
> > +#define DRM_FORMAT_GR16fourcc_code('G', 'R', '1', '6') /*
> > [31:0] G:R 16:16 little endian */
> > +
>
> Shouldn't it be 'G', 'R', '3', '2'?
The name should be _GR1616. Using GR16 for the fourcc seems OK to me
since we can't fit in the full GR1616 in there. Althogh GR32 could work
too I suppose.
And what about RG16?
>
> Also, please put dri-devel on CC.
>
> Thanks
> David
>
> > /* 8 bpp RGB */
> > #define DRM_FORMAT_RGB332 fourcc_code('R', 'G', 'B', '8') /* [7:0]
> > R:G:B 3:3:2 */
> > #define DRM_FORMAT_BGR233 fourcc_code('B', 'G', 'R', '8') /* [7:0]
> > B:G:R 2:3:3 */
> > --
> > 2.9.3
> >
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel OTC
[PATCHv2 0/4] video/exynos/cec: add HPD state notifier & use in s5p-cec
From: Hans Verkuil
This patch series adds the hotplug detect notifier code, based on Russell's
code:
https://patchwork.kernel.org/patch/9277043/
It adds support for it to the exynos_hdmi drm driver, adds support for
it to the CEC framework and finally adds support to the s5p-cec driver,
which now can be moved out of staging.
Tested with my Odroid U3 exynos4 devboard.
Comments are welcome. I'd like to get this in for the 4.11 kernel as
this is a missing piece needed to integrate CEC drivers.
Changes since v1:
Renamed HDMI notifier to HPD (hotplug detect) notifier since this code is
not HDMI specific, but is interesting for any video source that has to
deal with hotplug detect and EDID/ELD (HDMI, DVI, VGA, DP, ).
Only the use with CEC adapters is HDMI specific, but the HPD notifier
is more generic.
Regards,
Hans
Hans Verkuil (4):
video: add hotplug detect notifier support
exynos_hdmi: add HPD notifier support
cec: integrate HPD notifier support
s5p-cec: add hpd-notifier support, move out of staging
.../devicetree/bindings/media/s5p-cec.txt | 2 +
arch/arm/boot/dts/exynos4.dtsi | 1 +
drivers/gpu/drm/exynos/Kconfig | 1 +
drivers/gpu/drm/exynos/exynos_hdmi.c | 24 +++-
drivers/media/cec/cec-core.c | 50
drivers/media/platform/Kconfig | 18 +++
drivers/media/platform/Makefile| 1 +
.../media => media/platform}/s5p-cec/Makefile | 0
.../platform}/s5p-cec/exynos_hdmi_cec.h| 0
.../platform}/s5p-cec/exynos_hdmi_cecctrl.c| 0
.../media => media/platform}/s5p-cec/regs-cec.h| 0
.../media => media/platform}/s5p-cec/s5p_cec.c | 35 +-
.../media => media/platform}/s5p-cec/s5p_cec.h | 3 +
drivers/staging/media/Kconfig | 2 -
drivers/staging/media/Makefile | 1 -
drivers/staging/media/s5p-cec/Kconfig | 9 --
drivers/staging/media/s5p-cec/TODO | 7 --
drivers/video/Kconfig | 3 +
drivers/video/Makefile | 1 +
drivers/video/hpd-notifier.c | 134 +
include/linux/hpd-notifier.h | 109 +
include/media/cec.h| 15 +++
22 files changed, 389 insertions(+), 27 deletions(-)
rename drivers/{staging/media => media/platform}/s5p-cec/Makefile (100%)
rename drivers/{staging/media => media/platform}/s5p-cec/exynos_hdmi_cec.h
(100%)
rename drivers/{staging/media => media/platform}/s5p-cec/exynos_hdmi_cecctrl.c
(100%)
rename drivers/{staging/media => media/platform}/s5p-cec/regs-cec.h (100%)
rename drivers/{staging/media => media/platform}/s5p-cec/s5p_cec.c (89%)
rename drivers/{staging/media => media/platform}/s5p-cec/s5p_cec.h (97%)
delete mode 100644 drivers/staging/media/s5p-cec/Kconfig
delete mode 100644 drivers/staging/media/s5p-cec/TODO
create mode 100644 drivers/video/hpd-notifier.c
create mode 100644 include/linux/hpd-notifier.h
--
2.8.1
[PATCHv2 1/4] video: add hotplug detect notifier support
From: Hans Verkuil
Add support for video hotplug detect and EDID/ELD notifiers, which is used
to convey information from video drivers to their CEC and audio counterparts.
Based on an earlier version from Russell King:
https://patchwork.kernel.org/patch/9277043/
The hpd_notifier is a reference counted object containing the HPD/EDID/ELD state
of a video device.
When a new notifier is registered the current state will be reported to
that notifier at registration time.
Signed-off-by: Hans Verkuil
Tested-by: Marek Szyprowski
---
drivers/video/Kconfig| 3 +
drivers/video/Makefile | 1 +
drivers/video/hpd-notifier.c | 134 +++
include/linux/hpd-notifier.h | 109 +++
4 files changed, 247 insertions(+)
create mode 100644 drivers/video/hpd-notifier.c
create mode 100644 include/linux/hpd-notifier.h
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 3c20af9..cddc860 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -36,6 +36,9 @@ config VIDEOMODE_HELPERS
config HDMI
bool
+config HPD_NOTIFIERS
+ bool
+
if VT
source "drivers/video/console/Kconfig"
endif
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 9ad3c17..424698b 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -1,5 +1,6 @@
obj-$(CONFIG_VGASTATE)+= vgastate.o
obj-$(CONFIG_HDMI)+= hdmi.o
+obj-$(CONFIG_HPD_NOTIFIERS) += hpd-notifier.o
obj-$(CONFIG_VT) += console/
obj-$(CONFIG_LOGO) += logo/
diff --git a/drivers/video/hpd-notifier.c b/drivers/video/hpd-notifier.c
new file mode 100644
index 000..54f7a6b
--- /dev/null
+++ b/drivers/video/hpd-notifier.c
@@ -0,0 +1,134 @@
+#include
+#include
+#include
+#include
+#include
+
+static LIST_HEAD(hpd_notifiers);
+static DEFINE_MUTEX(hpd_notifiers_lock);
+
+struct hpd_notifier *hpd_notifier_get(struct device *dev)
+{
+ struct hpd_notifier *n;
+
+ mutex_lock(&hpd_notifiers_lock);
+ list_for_each_entry(n, &hpd_notifiers, head) {
+ if (n->dev == dev) {
+ mutex_unlock(&hpd_notifiers_lock);
+ kref_get(&n->kref);
+ return n;
+ }
+ }
+ n = kzalloc(sizeof(*n), GFP_KERNEL);
+ if (!n)
+ goto unlock;
+ n->dev = dev;
+ mutex_init(&n->lock);
+ BLOCKING_INIT_NOTIFIER_HEAD(&n->notifiers);
+ kref_init(&n->kref);
+ list_add_tail(&n->head, &hpd_notifiers);
+unlock:
+ mutex_unlock(&hpd_notifiers_lock);
+ return n;
+}
+EXPORT_SYMBOL_GPL(hpd_notifier_get);
+
+static void hpd_notifier_release(struct kref *kref)
+{
+ struct hpd_notifier *n =
+ container_of(kref, struct hpd_notifier, kref);
+
+ mutex_lock(&hpd_notifiers_lock);
+ list_del(&n->head);
+ mutex_unlock(&hpd_notifiers_lock);
+ kfree(n->edid);
+ kfree(n);
+}
+
+void hpd_notifier_put(struct hpd_notifier *n)
+{
+ kref_put(&n->kref, hpd_notifier_release);
+}
+EXPORT_SYMBOL_GPL(hpd_notifier_put);
+
+int hpd_notifier_register(struct hpd_notifier *n, struct notifier_block *nb)
+{
+ int ret = blocking_notifier_chain_register(&n->notifiers, nb);
+
+ if (ret)
+ return ret;
+ kref_get(&n->kref);
+ mutex_lock(&n->lock);
+ if (n->connected) {
+ blocking_notifier_call_chain(&n->notifiers, HPD_CONNECTED, n);
+ if (n->edid_size)
+ blocking_notifier_call_chain(&n->notifiers,
HPD_NEW_EDID, n);
+ if (n->has_eld)
+ blocking_notifier_call_chain(&n->notifiers,
HPD_NEW_ELD, n);
+ }
+ mutex_unlock(&n->lock);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(hpd_notifier_register);
+
+int hpd_notifier_unregister(struct hpd_notifier *n, struct notifier_block *nb)
+{
+ int ret = blocking_notifier_chain_unregister(&n->notifiers, nb);
+
+ if (ret == 0)
+ hpd_notifier_put(n);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(hpd_notifier_unregister);
+
+void hpd_event_connect(struct hpd_notifier *n)
+{
+ mutex_lock(&n->lock);
+ n->connected = true;
+ blocking_notifier_call_chain(&n->notifiers, HPD_CONNECTED, n);
+ mutex_unlock(&n->lock);
+}
+EXPORT_SYMBOL_GPL(hpd_event_connect);
+
+void hpd_event_disconnect(struct hpd_notifier *n)
+{
+ mutex_lock(&n->lock);
+ n->connected = false;
+ n->has_eld = false;
+ n->edid_size = 0;
+ blocking_notifier_call_chain(&n->notifiers, HPD_DISCONNECTED, n);
+ mutex_unlock(&n->lock);
+}
+EXPORT_SYMBOL_GPL(hpd_event_disconnect);
+
+int hpd_event_new_edid(struct hpd_notifier *n, const void *edid, size_t size)
+{
+ mutex_lock(&n->lock);
+ if (n->edid_allocated_size < size) {
+ void *p = kmalloc(size, GFP_KERNEL);
+
+ if (p == NULL) {
+
[PATCHv2 2/4] exynos_hdmi: add HPD notifier support
From: Hans Verkuil
Implement the HPD notifier support to allow CEC drivers to
be informed when there is a new EDID and when a connect or
disconnect happens.
Signed-off-by: Hans Verkuil
Tested-by: Marek Szyprowski
---
drivers/gpu/drm/exynos/Kconfig | 1 +
drivers/gpu/drm/exynos/exynos_hdmi.c | 24 +---
2 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index d706ca4..80bfd1d 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -77,6 +77,7 @@ config DRM_EXYNOS_DP
config DRM_EXYNOS_HDMI
bool "HDMI"
depends on DRM_EXYNOS_MIXER || DRM_EXYNOS5433_DECON
+ select HPD_NOTIFIERS
help
Choose this option if you want to use Exynos HDMI for DRM.
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 5ed8b1e..28bf609 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -118,6 +119,7 @@ struct hdmi_context {
booldvi_mode;
struct delayed_work hotplug_work;
struct drm_display_mode current_mode;
+ struct hpd_notifier *notifier;
const struct hdmi_driver_data *drv_data;
void __iomem*regs;
@@ -807,9 +809,12 @@ static enum drm_connector_status hdmi_detect(struct
drm_connector *connector,
{
struct hdmi_context *hdata = connector_to_hdmi(connector);
- if (gpiod_get_value(hdata->hpd_gpio))
+ if (gpiod_get_value(hdata->hpd_gpio)) {
+ hpd_event_connect(hdata->notifier);
return connector_status_connected;
+ }
+ hpd_event_disconnect(hdata->notifier);
return connector_status_disconnected;
}
@@ -848,6 +853,9 @@ static int hdmi_get_modes(struct drm_connector *connector)
edid->width_cm, edid->height_cm);
drm_mode_connector_update_edid_property(connector, edid);
+ hpd_event_connect(hdata->notifier);
+ hpd_event_new_edid(hdata->notifier, edid,
+ EDID_LENGTH * (1 + edid->extensions));
ret = drm_add_edid_modes(connector, edid);
@@ -1483,6 +1491,7 @@ static void hdmi_disable(struct drm_encoder *encoder)
if (funcs && funcs->disable)
(*funcs->disable)(crtc);
+ hpd_event_disconnect(hdata->notifier);
cancel_delayed_work(&hdata->hotplug_work);
hdmiphy_disable(hdata);
@@ -1832,15 +1841,22 @@ static int hdmi_probe(struct platform_device *pdev)
}
}
+ hdata->notifier = hpd_notifier_get(&pdev->dev);
+ if (hdata->notifier == NULL) {
+ ret = -ENOMEM;
+ goto err_hdmiphy;
+ }
+
pm_runtime_enable(dev);
ret = component_add(&pdev->dev, &hdmi_component_ops);
if (ret)
- goto err_disable_pm_runtime;
+ goto err_notifier_put;
return ret;
-err_disable_pm_runtime:
+err_notifier_put:
+ hpd_notifier_put(hdata->notifier);
pm_runtime_disable(dev);
err_hdmiphy:
@@ -1859,9 +1875,11 @@ static int hdmi_remove(struct platform_device *pdev)
struct hdmi_context *hdata = platform_get_drvdata(pdev);
cancel_delayed_work_sync(&hdata->hotplug_work);
+ hpd_event_disconnect(hdata->notifier);
component_del(&pdev->dev, &hdmi_component_ops);
+ hpd_notifier_put(hdata->notifier);
pm_runtime_disable(&pdev->dev);
if (!IS_ERR(hdata->reg_hdmi_en))
--
2.8.1
[PATCHv2 3/4] cec: integrate HPD notifier support
From: Hans Verkuil
Support the HPD notifier framework, simplifying drivers that
depend on this.
Signed-off-by: Hans Verkuil
Tested-by: Marek Szyprowski
---
drivers/media/cec/cec-core.c | 50
include/media/cec.h | 15 +
2 files changed, 65 insertions(+)
diff --git a/drivers/media/cec/cec-core.c b/drivers/media/cec/cec-core.c
index aca3ab8..a466dbe 100644
--- a/drivers/media/cec/cec-core.c
+++ b/drivers/media/cec/cec-core.c
@@ -195,6 +195,52 @@ static void cec_devnode_unregister(struct cec_devnode
*devnode)
put_device(&devnode->dev);
}
+#ifdef CONFIG_HPD_NOTIFIERS
+static u16 parse_hdmi_addr(const struct edid *edid)
+{
+ if (!edid || edid->extensions == 0)
+ return CEC_PHYS_ADDR_INVALID;
+
+ return cec_get_edid_phys_addr((u8 *)edid,
+ EDID_LENGTH * (edid->extensions + 1), NULL);
+}
+
+static int cec_hpd_notify(struct notifier_block *nb, unsigned long event,
+ void *data)
+{
+ struct cec_adapter *adap = container_of(nb, struct cec_adapter, nb);
+ struct hpd_notifier *n = data;
+ unsigned int phys;
+
+ dprintk(1, "event %lu\n", event);
+
+ switch (event) {
+ case HPD_DISCONNECTED:
+ cec_s_phys_addr(adap, CEC_PHYS_ADDR_INVALID, false);
+ break;
+
+ case HPD_NEW_EDID:
+ phys = parse_hdmi_addr(n->edid);
+ cec_s_phys_addr(adap, phys, false);
+ break;
+ }
+
+ return NOTIFY_OK;
+}
+
+void cec_register_hpd_notifier(struct cec_adapter *adap,
+ struct hpd_notifier *notifier)
+{
+ if (WARN_ON(!adap->devnode.registered))
+ return;
+
+ adap->nb.notifier_call = cec_hpd_notify;
+ adap->notifier = notifier;
+ hpd_notifier_register(adap->notifier, &adap->nb);
+}
+EXPORT_SYMBOL_GPL(cec_register_hpd_notifier);
+#endif
+
struct cec_adapter *cec_allocate_adapter(const struct cec_adap_ops *ops,
void *priv, const char *name, u32 caps,
u8 available_las)
@@ -344,6 +390,10 @@ void cec_unregister_adapter(struct cec_adapter *adap)
adap->rc = NULL;
#endif
debugfs_remove_recursive(adap->cec_dir);
+#ifdef CONFIG_HPD_NOTIFIERS
+ if (adap->notifier)
+ hpd_notifier_unregister(adap->notifier, &adap->nb);
+#endif
cec_devnode_unregister(&adap->devnode);
}
EXPORT_SYMBOL_GPL(cec_unregister_adapter);
diff --git a/include/media/cec.h b/include/media/cec.h
index 96a0aa7..d6c7b20 100644
--- a/include/media/cec.h
+++ b/include/media/cec.h
@@ -28,6 +28,11 @@
#include
#include
#include
+#ifdef CONFIG_HPD_NOTIFIERS
+#include
+#include
+#include
+#endif
#include
#include
@@ -173,6 +178,11 @@ struct cec_adapter {
bool passthrough;
struct cec_log_addrs log_addrs;
+#ifdef CONFIG_HPD_NOTIFIERS
+ struct hpd_notifier *notifier;
+ struct notifier_block nb;
+#endif
+
struct dentry *cec_dir;
struct dentry *status_file;
@@ -213,6 +223,11 @@ void cec_transmit_done(struct cec_adapter *adap, u8
status, u8 arb_lost_cnt,
u8 nack_cnt, u8 low_drive_cnt, u8 error_cnt);
void cec_received_msg(struct cec_adapter *adap, struct cec_msg *msg);
+#ifdef CONFIG_HPD_NOTIFIERS
+void cec_register_hpd_notifier(struct cec_adapter *adap,
+ struct hpd_notifier *notifier);
+#endif
+
#else
static inline int cec_register_adapter(struct cec_adapter *adap,
--
2.8.1
[PATCHv2 4/4] s5p-cec: add hpd-notifier support, move out of staging
From: Hans Verkuil
By using the HPD notifier framework there is no longer any reason
to manually set the physical address. This was the one blocking
issue that prevented this driver from going out of staging, so do
this move as well.
Update the bindings documenting the new hdmi phandle and
update exynos4.dtsi accordingly.
Tested with my Odroid U3.
Signed-off-by: Hans Verkuil
Tested-by: Marek Szyprowski
---
.../devicetree/bindings/media/s5p-cec.txt | 2 ++
arch/arm/boot/dts/exynos4.dtsi | 1 +
drivers/media/platform/Kconfig | 18 +++
drivers/media/platform/Makefile| 1 +
.../media => media/platform}/s5p-cec/Makefile | 0
.../platform}/s5p-cec/exynos_hdmi_cec.h| 0
.../platform}/s5p-cec/exynos_hdmi_cecctrl.c| 0
.../media => media/platform}/s5p-cec/regs-cec.h| 0
.../media => media/platform}/s5p-cec/s5p_cec.c | 35 ++
.../media => media/platform}/s5p-cec/s5p_cec.h | 3 ++
drivers/staging/media/Kconfig | 2 --
drivers/staging/media/Makefile | 1 -
drivers/staging/media/s5p-cec/Kconfig | 9 --
drivers/staging/media/s5p-cec/TODO | 7 -
14 files changed, 55 insertions(+), 24 deletions(-)
rename drivers/{staging/media => media/platform}/s5p-cec/Makefile (100%)
rename drivers/{staging/media => media/platform}/s5p-cec/exynos_hdmi_cec.h
(100%)
rename drivers/{staging/media => media/platform}/s5p-cec/exynos_hdmi_cecctrl.c
(100%)
rename drivers/{staging/media => media/platform}/s5p-cec/regs-cec.h (100%)
rename drivers/{staging/media => media/platform}/s5p-cec/s5p_cec.c (89%)
rename drivers/{staging/media => media/platform}/s5p-cec/s5p_cec.h (97%)
delete mode 100644 drivers/staging/media/s5p-cec/Kconfig
delete mode 100644 drivers/staging/media/s5p-cec/TODO
diff --git a/Documentation/devicetree/bindings/media/s5p-cec.txt
b/Documentation/devicetree/bindings/media/s5p-cec.txt
index 925ab4d..710fc00 100644
--- a/Documentation/devicetree/bindings/media/s5p-cec.txt
+++ b/Documentation/devicetree/bindings/media/s5p-cec.txt
@@ -15,6 +15,7 @@ Required properties:
- clock-names : from common clock binding: must contain "hdmicec",
corresponding to entry in the clocks property.
- samsung,syscon-phandle - phandle to the PMU system controller
+ - samsung,hdmi-phandle - phandle to the HDMI controller
Example:
@@ -25,6 +26,7 @@ hdmicec: cec at 100B {
clocks = <&clock CLK_HDMI_CEC>;
clock-names = "hdmicec";
samsung,syscon-phandle = <&pmu_system_controller>;
+ samsung,hdmi-phandle = <&hdmi>;
pinctrl-names = "default";
pinctrl-0 = <&hdmi_cec>;
status = "okay";
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index c64737b..51dfcbb 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -762,6 +762,7 @@
clocks = <&clock CLK_HDMI_CEC>;
clock-names = "hdmicec";
samsung,syscon-phandle = <&pmu_system_controller>;
+ samsung,hdmi-phandle = <&hdmi>;
pinctrl-names = "default";
pinctrl-0 = <&hdmi_cec>;
status = "disabled";
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index d944421..cab1637 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -392,6 +392,24 @@ config VIDEO_TI_SC
config VIDEO_TI_CSC
tristate
+menuconfig V4L_CEC_DRIVERS
+ bool "Platform HDMI CEC drivers"
+ depends on MEDIA_CEC_SUPPORT
+
+if V4L_CEC_DRIVERS
+
+config VIDEO_SAMSUNG_S5P_CEC
+ tristate "Samsung S5P CEC driver"
+ depends on VIDEO_DEV && MEDIA_CEC_SUPPORT && (PLAT_S5P || ARCH_EXYNOS
|| COMPILE_TEST)
+ select HPD_NOTIFIERS
+ ---help---
+ This is a driver for Samsung S5P HDMI CEC interface. It uses the
+ generic CEC framework interface.
+ CEC bus is present in the HDMI connector and enables communication
+ between compatible devices.
+
+endif #V4L_CEC_DRIVERS
+
menuconfig V4L_TEST_DRIVERS
bool "Media test drivers"
depends on MEDIA_CAMERA_SUPPORT
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 5b3cb27..ad3bf22 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG) += s5p-jpeg/
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC)+= s5p-mfc/
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_G2D)+= s5p-g2d/
+obj-$(CONFIG_VIDEO_SAMSUNG_S5P_CEC)+= s5p-cec/
obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC) += exynos-gsc/
obj-$(CONFIG_VIDEO_STI_BDISP) += sti/bdisp/
diff --git a/drivers/staging/media/s5p-cec/Makefile
b/drivers/media/platform/s5p-cec/Makefile
similarity index 100%
rename from drivers/staging/media/s5p-cec/Makefile
rename to d
[PATCH v2 0/2] drm documentation and clean ups
Here's a v2 with the part of the series that didn't get pushed yet. Patch 2 has the suggestions from Daniel applied. Thanks, Gabriel Krisman Bertazi (2): exynos_drm: Clean up duplicated assignment in exynos_drm_driver drm: Document deprecated load/unload hook drivers/gpu/drm/exynos/exynos_drm_drv.c | 1 - include/drm/drm_drv.h | 35 + 2 files changed, 35 insertions(+), 1 deletion(-) -- 2.11.0
[PATCH v2 1/2] exynos_drm: Clean up duplicated assignment in exynos_drm_driver
num_ioctls is already assigned when declaring the exynos_drm_driver structure. No need to duplicate it here. Signed-off-by: Gabriel Krisman Bertazi CC: Inki Dae CC: Joonyoung Shim CC: Seung-Woo Kim CC: Kyungmin Park --- drivers/gpu/drm/exynos/exynos_drm_drv.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index 739180ac3da5..44b4d07eefb5 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -570,7 +570,6 @@ static int exynos_drm_platform_probe(struct platform_device *pdev) struct component_match *match; pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32); - exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls); match = exynos_drm_match_add(&pdev->dev); if (IS_ERR(match)) -- 2.11.0
[PATCH v2 2/2] drm: Document deprecated load/unload hook
v2:
- Replace discouraged with deprecated
- Link to new initialization/teardown functions
Signed-off-by: Gabriel Krisman Bertazi
---
include/drm/drm_drv.h | 35 +++
1 file changed, 35 insertions(+)
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index c4fc49583dc0..9c2d9f0bb043 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -64,12 +64,47 @@ struct drm_mode_create_dumb;
* structure for GEM drivers.
*/
struct drm_driver {
+
+ /**
+* @load:
+*
+* Backward-compatible driver callback to complete
+* initialization steps after the driver is registered. For
+* this reason, may suffer from race conditions and its use is
+* deprecated for new drivers. It is therefore only supported
+* for existing drivers not yet converted to the new scheme.
+* See drm_dev_init() and drm_dev_register() for proper and
+* race-free way to set up a &struct drm_device.
+*
+* Returns:
+*
+* Zero on success, non-zero value on failure.
+*/
int (*load) (struct drm_device *, unsigned long flags);
int (*firstopen) (struct drm_device *);
int (*open) (struct drm_device *, struct drm_file *);
void (*preclose) (struct drm_device *, struct drm_file *file_priv);
void (*postclose) (struct drm_device *, struct drm_file *);
void (*lastclose) (struct drm_device *);
+
+ /**
+* @unload:
+*
+* Reverse the effects of the driver load callback. Ideally,
+* the clean up performed by the driver should happen in the
+* reverse order of the initialization. Similarly to the load
+* hook, this handler is deprecated and its usage should be
+* dropped in favor of an open-coded teardown function at the
+* driver layer. See drm_dev_unregister() and drm_dev_unref()
+* for the proper way to remove a &struct drm_device.
+*
+* The unload() hook is called right after unregistering
+* the device.
+*
+* Returns:
+*
+* The return value is ignored.
+*/
int (*unload) (struct drm_device *);
int (*dma_ioctl) (struct drm_device *dev, void *data, struct drm_file
*file_priv);
int (*dma_quiescent) (struct drm_device *);
--
2.11.0
HDMI Audio screwed up w/ recent kernels
On Sat, Dec 31, 2016 at 2:55 AM, James Cloos wrote: >> "AD" == Alex Deucher writes: > > AD> That option is just a carry over from when the amdgpu was copied from > AD> radeon. There is some code for older asics left over from when the > AD> code was originally ported from radeon. If you want hdmi audio > AD> support you need to use the new dc modesetting code we are working on: > AD> https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-4.7 > > AD> As for radeon, a bisection would help. If both drivers worked before > AD> and now both have issues, I'd suggest looking at the hda audio driver. > > All I know is that radeon audio worked fine in 3.x and stopped working > in 4.x Where stopped working means fairly recognizable audio which > sounds mixed with white noise. > > I doubt I can bisect. The screen it uses is in almost constant use > > In order for the fb to be there from boot, the firmware is all compiled > into the kernels via CONFIG_EXTRA_FIRMWARE. > > Given that, with 4.9, the audio has exactly the same problem with amdgpu > as with radeon, I suspect the actual problem is in the firmware. If so, > and since I do not have whatever firmware files were installed back when > I compiled the 3. kernels, I doubt bisecting the kernel would help. The GPU firmware is not involved in display or audio at all. Alex
[Bug 99236] System (seems to) completely freeze when interacting with java swing applications.
https://bugs.freedesktop.org/show_bug.cgi?id=99236 --- Comment #1 from Alex Deucher --- Please attach your xorg log and dmesg output. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170102/93f8fbd5/attachment.html>
HDMI Audio screwed up w/ recent kernels
> "AD" == Alex Deucher writes: AD> The GPU firmware is not involved in display or audio at all. Oh. Thanks for that! In that case the bug showed up some time between 3.19.0 and 4.1.0. git tag tells me 3.19 was the last 3. Only 14.56+ bits worth of commits between those two tags. ;) -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
[PATCH 1/2] drm: Document drm_cache interface
Signed-off-by: Gabriel Krisman Bertazi
---
drivers/gpu/drm/drm_cache.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index a7916e5f8864..b52e16e2b8ef 100644
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -67,6 +67,14 @@ static void drm_cache_flush_clflush(struct page *pages[],
}
#endif
+/**
+ * drm_clflush_pages - Flush dcache lines of a set of pages
+ * @pages - struct page array
+ * @num_pages - Number of pages in the array
+ *
+ * Flush every data cache line entry that points to an address belonging
+ * to a page in the array.
+ */
void
drm_clflush_pages(struct page *pages[], unsigned long num_pages)
{
@@ -101,6 +109,13 @@ drm_clflush_pages(struct page *pages[], unsigned long
num_pages)
}
EXPORT_SYMBOL(drm_clflush_pages);
+/**
+ * drm_clflush_sg - Flush dcache lines pointing to a scather-gather
+ * @st - struct sg_table
+ *
+ * Flush every data cache line entry that points to an address in the
+ * sg.
+ */
void
drm_clflush_sg(struct sg_table *st)
{
@@ -125,6 +140,14 @@ drm_clflush_sg(struct sg_table *st)
}
EXPORT_SYMBOL(drm_clflush_sg);
+/**
+ * drm_clflush_virt_range - Flush dcache lines of a region
+ * @addr - Initial memory address
+ * @length - Region size
+ *
+ * Flush every data cache line entry that points to an address in the
+ * region requested.
+ */
void
drm_clflush_virt_range(void *addr, unsigned long length)
{
--
2.11.0
[PATCH 2/2] drm: Move drm_clflush prototypes to drm_cache header file
Continue to clean up drmP.h by moving the cache flushing functions into
it's own header file.
Signed-off-by: Gabriel Krisman Bertazi
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/vgem/vgem_drv.h | 1 +
include/drm/drmP.h | 5 -
include/drm/drm_cache.h | 4
4 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 89dbe55077f5..7143f28b5cf1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -49,6 +49,7 @@
#include /* for struct drm_dma_handle */
#include
#include
+#include
#include "i915_params.h"
#include "i915_reg.h"
diff --git a/drivers/gpu/drm/vgem/vgem_drv.h b/drivers/gpu/drm/vgem/vgem_drv.h
index 1f8798ad329c..cb59c7ab98b9 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.h
+++ b/drivers/gpu/drm/vgem/vgem_drv.h
@@ -31,6 +31,7 @@
#include
#include
+#include
#include
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 8671ddd256fc..6d5c06bf2db1 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -730,11 +730,6 @@ int drm_noop(struct drm_device *dev, void *data,
int drm_invalid_op(struct drm_device *dev, void *data,
struct drm_file *file_priv);
-/* Cache management (drm_cache.c) */
-void drm_clflush_pages(struct page *pages[], unsigned long num_pages);
-void drm_clflush_sg(struct sg_table *st);
-void drm_clflush_virt_range(void *addr, unsigned long length);
-
/*
* These are exported to drivers so that they can implement fencing using
* DMA quiscent + idle. DMA quiescent usually requires the hardware lock.
diff --git a/include/drm/drm_cache.h b/include/drm/drm_cache.h
index cebecff536a3..beab0f0d0cfb 100644
--- a/include/drm/drm_cache.h
+++ b/include/drm/drm_cache.h
@@ -33,7 +33,11 @@
#ifndef _DRM_CACHE_H_
#define _DRM_CACHE_H_
+#include
+
void drm_clflush_pages(struct page *pages[], unsigned long num_pages);
+void drm_clflush_sg(struct sg_table *st);
+void drm_clflush_virt_range(void *addr, unsigned long length);
static inline bool drm_arch_can_wc_memory(void)
{
--
2.11.0
[Bug 98761] [regression][radeonsi][polaris]"radeonsi: set IF_THRESHOLD to 3" breaks Witcher2's ground
https://bugs.freedesktop.org/show_bug.cgi?id=98761 Arek RuÅniak changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #23 from Arek RuÅniak --- Oops.. when Marek reverted "SGPR spilling..."-stuff, this one should be closed aswell. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170102/820fac0b/attachment-0001.html>
[Bug 89447] [bisected] [radeonsi+wine_d3dadapter+Bioshock] GPU lockup 8 minutes after start
https://bugs.freedesktop.org/show_bug.cgi?id=89447 Arek RuÅniak changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Arek RuÅniak --- Few month ago when I checked Bioshock 1, there was no problem with wine-nine, probably no one care even me at last -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170102/c0cd9fb9/attachment.html>
[Bug 96906] OpenCL program causes steady stream of GPU fault detected errors
https://bugs.freedesktop.org/show_bug.cgi?id=96906 --- Comment #5 from Jolan Luff --- I haven't tested with anything newer than 16.30.x yet. (I use Arch Linux and the unofficial package hasn't been updated) I didn't see any mention of OpenCL fixes in the changelog so I haven't tried to update myself. I did just check and it looks like 16.50.X may be coming soon. Will report back if no one else beats me to it. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170102/99419a23/attachment.html>
[PATCH] drm: Constify drm_mode_config atomic helper private pointer
Laurent Pinchart writes: > The drm_mode_config helper private field points to a structure of > function pointers that don't need to be modified at runtime. Make it > const. Reviewed-by: Gabriel Krisman Bertazi -- Gabriel Krisman Bertazi
[Bug 97634] [amdgpu SI] multigpu setup crashes during boot when dpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=97634 --- Comment #8 from Arek RuÅniak --- I don't have HW (multiGPU) to test it anymore, so fill free to close it in any time/way you want. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170102/4e416a21/attachment.html>
[Bug 97055] Black screens on A10-8780P (Carrizo) + R7 M260/M265 (Topaz) Combo
https://bugs.freedesktop.org/show_bug.cgi?id=97055 SET changed: What|Removed |Added CC||nmset at netcourrier.com --- Comment #13 from SET --- @Thomas J Moore My HP laptop with AMD A10-7300 (Kaveri iGPU, Topaz dGPU) has a fully working X up to kernel 4.9 (not beyond) with these module options applied as such : # cat /etc/modprobe.d/amdgpu.conf install radeon /bin/false options amdgpu aspm=0 bapm=0 runpm=0 powerplay=1 In case it helps. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170102/7ddc8d62/attachment.html>
[Bug 99219] The Stanley Parable GPU hang when starting a new game
https://bugs.freedesktop.org/show_bug.cgi?id=99219 --- Comment #3 from Samuel Pitoiset --- It's actually a regression in mesa, works fine with 13.0.2. After bisecting, the first bad commit is: commit ed3190b3f3a776fc8c75b1e6130a88079166d115 Author: Marek Olšák Date: Sun Nov 13 18:41:43 2016 +0100 radeonsi: don't export ClipVertex and ClipDistance[] if clipping is disabled This is the first user of optimized monolithic shader variants. Cull distances can't be disabled by states. Tested-by: Edmondo Tommasina Reviewed-by: Nicolai Hähnle But this doesn't seem to be actually related to the clip planes optimization because if you replay the trace with R600_DUMP_SHADERS=y, it no longer crashes. If my understanding is correct, it won't compile shaders asynchronously. Forcing num_compiler_threads = 1 in si_pipe.c also "fixes" the hang. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170102/e4282498/attachment.html>
[Bug 97055] Black screens on A10-8780P (Carrizo) + R7 M260/M265 (Topaz) Combo
https://bugs.freedesktop.org/show_bug.cgi?id=97055 --- Comment #14 from SET --- @Thomas J Moore One more note : my laptop won't boot with dpm=0. (I suppose you have efficiently blacklisted radeon, and that the kernel is compiled with CIK enabled). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170102/ed0d8a3a/attachment-0001.html>
linux-next: build failure after merge of the drm-intel-fixes tree
On Tue, 3 Jan 2017 10:59:29 +0800
Zhenyu Wang wrote:
> On 2017.01.03 10:42:39 +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the drm-intel-fixes tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > drivers/gpu/drm/i915/gvt/kvmgt.c: In function 'intel_vgpu_open':
> > drivers/gpu/drm/i915/gvt/kvmgt.c:511:32: error: dereferencing pointer to
> > incomplete type 'struct mdev_device'
> > vfio_unregister_notifier(&mdev->dev, VFIO_GROUP_NOTIFY,
> > ^
> >
> > Caused by commit
> >
> > 99e3123e3d72 ("vfio-mdev: Make mdev_device private and abstract
> > interfaces")
> >
> > from the vfio-fixes tree interacting with commit
> >
> > 364fb6b789ff ("drm/i915/gvt/kvmgt: prevent double-release of vgpu")
> >
> > from the drm-intel-fixes tree.
>
> Alex, I liked to have kvmgt related mdev interface change be merged through
> vfio tree, but wasn't awared one of Jike's fix had conflict. Could you apply
> below fix in your tree? I think in general for possible interface change in
> future we still need a pull request for i915 to resolve dependence earlier.
Hi Zhenyu,
Hopefully this abstraction will help to isolate vendor drivers from
mdev API changes in the future. I can certainly roll this patch into
the original to maintain bisectability. I want to get these changes in
for rc3, will a pull request for the i915 changes be sent this week?
Thanks for spotting and fixing this, Stephen. Thanks,
Alex
> > I applied this merge fix patch:
> >
> > From: Stephen Rothwell
> > Date: Tue, 3 Jan 2017 10:38:48 +1100
> > Subject: [PATCH] vfio-mdev: fixup for "Make mdev_device private and
> > abstract interfaces"
> >
> > Signed-off-by: Stephen Rothwell
> > ---
> > drivers/gpu/drm/i915/gvt/kvmgt.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c
> > b/drivers/gpu/drm/i915/gvt/kvmgt.c
> > index c24b665e007b..faaae07ae487 100644
> > --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> > +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> > @@ -508,7 +508,7 @@ static int intel_vgpu_open(struct mdev_device *mdev)
> > return ret;
> >
> > undo_group:
> > - vfio_unregister_notifier(&mdev->dev, VFIO_GROUP_NOTIFY,
> > + vfio_unregister_notifier(mdev_dev(mdev), VFIO_GROUP_NOTIFY,
> > &vgpu->vdev.group_notifier);
> >
> > undo_iommu:
> > --
> > 2.10.2
> >
> > --
> > Cheers,
> > Stephen Rothwell
>
[PATCH 00/10] enable psr2 for idle_screen on y-cordinate panel
This series enables psr2 on idle on screen for y cordinate panel. Code is tested on sharp 32X18 edp 1.4 y cordinate enabled panel. if system enters psr2, the system must go to deep sleep state. Can be verifed by checking psr2_status register bit 31:28. DEEP_SLEEP[value 8] must be entered while in idle on screen with psr2 panel. PSR1 and PSR2 are mutually exclusive. In the current code, when PSR2 is enabled , psr1 is also enabled, and for psr2 the status is read from psr1 registers, leading to blank screen. 1-3: Fixes vsc header programming for psr2 as per edp1.4 a table 6-11 and blank screen issue for psr2 panel. 4-5: Enables alpm and disables aux frame sync , need for psr2. 6-7: Progarms CHICKEN_TRANS and PSR_MASK for deep sleep state, as per bspec 8: Psr2 is enabled only for y cordinate enabled psr2 panel. this restriction will be removed after adding gtc support. 9-10: Adds debug support for psr2.It also enables reading of EDP_PSR_PERF_CNT on skl+ platforms, when dc6 is disabled through kernel parameter i915.enable_dc=0 Vathsala Nagaraju (10): drm : adds Y-coordinate and Colorimetry Format drm/i915/psr: program vsc header for psr2 drm/i915/psr: fix blank screen issue for psr2 drm/i915/psr: disable aux_frame_sync on psr2 exit drm/i915/psr: enable ALPM for psr2 drm/i915/psr: set CHICKEN_TRANS for psr2 drm/i915/psr: set PSR_MASK bits for deep sleep drm/i915/psr: enable psr2 for y cordinate panels drm/i915/psr: report live PSR2 State drm/i915/psr: EDP_PSR_PERF_CNT not valid for psr2 drivers/gpu/drm/i915/i915_debugfs.c | 38 ++- drivers/gpu/drm/i915/i915_drv.h | 3 + drivers/gpu/drm/i915/i915_reg.h | 19 drivers/gpu/drm/i915/intel_dp.c | 35 +++ drivers/gpu/drm/i915/intel_psr.c| 199 include/drm/drm_dp_helper.h | 13 ++- 6 files changed, 263 insertions(+), 44 deletions(-) Cc: Rodrigo Vivi Cc: Jim Bride -- 1.9.1
[PATCH] omap drm: fix compile errors where the conversion from omap_timing to videomode was not perfect
Hi, On 12/26/2016 09:23 PM, H. Nikolaus Schaller wrote: > Signed-off-by: H. Nikolaus Schaller I did compile and boot tests after each patch when doing the conversion, but this certainly skipped because these were 'hidden' by #ifdef PRINT_VERBOSE_VM_TIMINGS which is not a Kconfig option and needs to be enabled in the dsi.c on purpose. Thank you for finding it and sorry for the inconvenience. Acked-by: Peter Ujfalusi > --- > drivers/gpu/drm/omapdrm/dss/dsi.c | 18 +- > 1 file changed, 9 insertions(+), 9 deletions(-) > > diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c b/drivers/gpu/drm/omapdrm/dss/dsi.c > index f060bda..f74615d 100644 > --- a/drivers/gpu/drm/omapdrm/dss/dsi.c > +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c > @@ -4336,7 +4336,7 @@ static void print_dsi_vm(const char *str, > > wc = DIV_ROUND_UP(t->hact * t->bitspp, 8); > pps = DIV_ROUND_UP(wc + 6, t->ndl); /* pixel packet size */ > - bl = t->hss + t->hsa + t->hse + t->hbp + t->hfront_porch; > + bl = t->hss + t->hsa + t->hse + t->hbp + t->hfp; > tot = bl + pps; > > #define TO_DSI_T(x) ((u32)div64_u64((u64)x * 10llu, byteclk)) > @@ -4345,14 +4345,14 @@ static void print_dsi_vm(const char *str, > "%u/%u/%u/%u/%u/%u = %u + %u = %u\n", > str, > byteclk, > - t->hss, t->hsa, t->hse, t->hbp, pps, t->hfront_porch, > + t->hss, t->hsa, t->hse, t->hbp, pps, t->hfp, > bl, pps, tot, > TO_DSI_T(t->hss), > TO_DSI_T(t->hsa), > TO_DSI_T(t->hse), > TO_DSI_T(t->hbp), > TO_DSI_T(pps), > - TO_DSI_T(t->hfront_porch), > + TO_DSI_T(t->hfp), > > TO_DSI_T(bl), > TO_DSI_T(pps), > @@ -4367,7 +4367,7 @@ static void print_dispc_vm(const char *str, const struct videomode *vm) > int hact, bl, tot; > > hact = vm->hactive; > - bl = vm->hsync_len + vm->hbp + vm->hfront_porch; > + bl = vm->hsync_len + vm->hback_porch + vm->hfront_porch; > tot = hact + bl; > > #define TO_DISPC_T(x) ((u32)div64_u64((u64)x * 10llu, pck)) > @@ -4376,10 +4376,10 @@ static void print_dispc_vm(const char *str, const struct videomode *vm) > "%u/%u/%u/%u = %u + %u = %u\n", > str, > pck, > - vm->hsync_len, vm->hbp, hact, vm->hfront_porch, > + vm->hsync_len, vm->hback_porch, hact, vm->hfront_porch, > bl, hact, tot, > TO_DISPC_T(vm->hsync_len), > - TO_DISPC_T(vm->hbp), > + TO_DISPC_T(vm->hback_porch), > TO_DISPC_T(hact), > TO_DISPC_T(vm->hfront_porch), > TO_DISPC_T(bl), > @@ -4401,12 +4401,12 @@ static void print_dsi_dispc_vm(const char *str, > dsi_tput = (u64)byteclk * t->ndl * 8; > pck = (u32)div64_u64(dsi_tput, t->bitspp); > dsi_hact = DIV_ROUND_UP(DIV_ROUND_UP(t->hact * t->bitspp, 8) + 6, t->ndl); > - dsi_htot = t->hss + t->hsa + t->hse + t->hbp + dsi_hact + t->hfront_porch; > + dsi_htot = t->hss + t->hsa + t->hse + t->hbp + dsi_hact + t->hfp; > > vm.pixelclock = pck; > vm.hsync_len = div64_u64((u64)(t->hsa + t->hse) * pck, byteclk); > - vm.hbp = div64_u64((u64)t->hbp * pck, byteclk); > - vm.hfront_porch = div64_u64((u64)t->hfront_porch * pck, byteclk); > + vm.hback_porch = div64_u64((u64)t->hbp * pck, byteclk); > + vm.hfront_porch = div64_u64((u64)t->hfp * pck, byteclk); > vm.hactive = t->hact; > > print_dispc_vm(str, &vm); > -- Péter
[PATCH 04/10] drm/i915/psr: disable aux_frame_sync on psr2 exit
Screen freeze observed if AUX_FRAME_SYNC is not disabled
on psr2 exit.AUX_FRAME_SYNC needed for psr2 is enabled during
psr2 entry. It must be disabled on psr2 exit.
Cc: Rodrigo Vivi
Cc: Jim Bride
Signed-off-by: Vathsala Nagaraju
Signed-off-by: Patil Deepti
---
drivers/gpu/drm/i915/intel_psr.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index ff2ecfd..93eb0f0 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -589,6 +589,11 @@ static void hsw_psr_disable(struct intel_dp *intel_dp)
struct drm_i915_private *dev_priv = to_i915(dev);
if (dev_priv->psr.active) {
+ if (dev_priv->psr.aux_frame_sync)
+ drm_dp_dpcd_writeb(&intel_dp->aux,
+ DP_SINK_DEVICE_AUX_FRAME_SYNC_CONF,
+ 0);
+
if (dev_priv->psr.psr2_support)
I915_WRITE(EDP_PSR2_CTL,
I915_READ(EDP_PSR2_CTL) &
@@ -729,6 +734,10 @@ static void intel_psr_exit(struct drm_i915_private
*dev_priv)
return;
if (HAS_DDI(dev_priv)) {
+ if (dev_priv->psr.aux_frame_sync)
+ drm_dp_dpcd_writeb(&intel_dp->aux,
+ DP_SINK_DEVICE_AUX_FRAME_SYNC_CONF,
+ 0);
if (dev_priv->psr.psr2_support) {
val = I915_READ(EDP_PSR2_CTL);
WARN_ON(!(val & EDP_PSR2_ENABLE));
--
1.9.1
[PATCH] drm/doc: Document uapi requirements in DRM
Hi Daniel, Thank you for the patch. On Friday 19 Aug 2016 22:50:38 Daniel Vetter wrote: > Everyone knows them, except all the new folks joining from the ARM > side haven't lived through all the pain of the past years and are > entirely surprised when I raise this. Definitely time to document > this. > > Last time this was a big discussion was about 6 years ago, when qcom > tried to land a kernel driver without userspace. Dave Airlie made the > rules really clear: > > http://airlied.livejournal.com/73115.html > > This write-up here is essentially what I've put into a presentation a > while ago, which was also reviewed by Dave: > > http://blog.ffwll.ch/2015/05/gfx-kernel-upstreaming-requirements.html > > Cc: Dave Airlie > Cc: Oded Gabbay > Cc: Russell King > Cc: Tomi Valkeinen > Cc: Eric Anholt > Cc: Thomas Hellstrom > Cc: Sinclair Yeh > Cc: Lucas Stach > Cc: Benjamin Gaignard > Cc: Mark Yao > Cc: Laurent Pinchart > Cc: Ben Skeggs > Cc: Rob Clark > Cc: CK Hu > Cc: Xinliang Liu > Cc: Philipp Zabel > Cc: Stefan Agner > Cc: Inki Dae > Cc: Maxime Ripard > Cc: Boris Brezillon > Cc: Jani Nikula > Cc: Daniel Vetter > Cc: Thierry Reding > Cc: Christian König > Cc: Alex Deucher > Cc: Gerd Hoffmann > Cc: Brian Starkey > Cc: Liviu Dudau > Cc: Alexey Brodkin > Acked-by: Dave Airlie > Signed-off-by: Daniel Vetter > --- > Documentation/gpu/drm-uapi.rst | 67 +++ > 1 file changed, 67 insertions(+) > > diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst > index 94876938aef3..a7e3aa27167d 100644 > --- a/Documentation/gpu/drm-uapi.rst > +++ b/Documentation/gpu/drm-uapi.rst > @@ -36,6 +36,73 @@ Primary Nodes, DRM Master and Authentication > Open-Source Userspace Requirements > == > > +The DRM subsystem has stricter requirements on what the userspace side for > new +uAPI needs to look like. This section here explains what exactly those > +requirements are, and why they exist. > + > +The short summary is that any addition of DRM uAPI requires corresponding > +open-sourced userspace patches, and those patches must be reviewed and > ready for +merging into a suitable and canonical upstream project. > + > +GFX devices (both display and render/GPU side) are really complex bits of > hardware, +with userspace and kernel by necessity having to work together > really closely. +The interfaces, for rendering and modesetting must be > extremely wide and +flexible, and therefore it is almost always impossible > to precisely define them +for every possible corner case. This in turns > makes it really practically +infeasible to differentiate between behaviour > that's required by userspace, and +which must not be changed to avoid > regressions, and behaviour which is only an +accidental artifact of the > current implementation. While I agree that this is a proper description of the current state of the DRM/KMS subsystem, I don't like how it implies that shipping code is an acceptable replacement for documentation. We need to aim at documenting the DRM/KMS userspace API to a level of detail that will cover the vast majority of cases (be they corner or round), if not all of them. > +Without access to the full source code of all userspace users that means it > +becomes impossible to change the implementation details, since userspace > could +depend upon the accidental behaviour of the current implementation > in minute +details. And debugging such regressions without access to source > code is pretty +much impossible. As a consequence this means: > + > +- The Linux kernel's "no regression" policy holds in practice only for > + open-source userspace of the DRM subsystem. DRM developers are perfectly > fine + if closed-source blob drivers in userspace use the same uAPI as the > open + drivers, In which category do you put the open-source userspace code that is not part of the mainline version of a major userspace framework (X11, Weston, Android hwcomposer, ...) ? I'm thinking about open-source vendor forks of those projects, or home-brew implementation of a tailor-made display stack for a product (I'm intentionally using the word display instead of GFX here, if a full tailor-made GFX stack including 3D rendering is quite unlikely, a display stack or even just an application driving the display through the DRM/KMS API is much easier to write from scratch). > but they must do so in the exact same way as the open drivers. > + Creative (ab)use of the interfaces will, and in the past routinely has, > lead + to breakage. This in my opinion calls for documentation, otherwise how can userspace developers tell what is an abuse without copying open-source code verbatim ? > +- Any new userspace interface must have an open-source implementation as > + demonstration vehicle. > + > +The other reason for requiring open-source userspace is uAPI review. Since > the +kernel and userspace parts of a GFX sta
[PATCH 01/10] drm : adds Y-coordinate and Colorimetry Format
PSR2 vsc revision number hb2( as per table 6-11)is updated to 4 or 5 based on Y cordinate and Colorimetry Format as below 04h = 3D stereo + PSR/PSR2 + Y-coordinate. 05h = -3D stereo- + PSR/PSR2 + Y-coordinate + Pixel Encoding/Colorimetry Format indication. A DP Source device is allowed to indicate the pixel encoding/colorimetry format to the DP Sink device with VSC SDP only when the DP Sink device supports it ( i.e.,VSC_SDP_EXTENSION_FOR_COLORIMETRY_SUPPORTED bit in the DPRX_FEATURE_ENUMERATION_LIST register (DPCD Address 02210h, bit 3; is set to 1). v2: (Jani) - Change DP_PSR_Y_COORDINATE to DP_PSR2_SU_Y_COORDINATE_REQUIRED. - Add DP_PSR2_SU_GRANULARITY_REQUIRED. - Change DPRX_FEATURE_ENUMERATION_LIST to DP_DPRX. - Add GTC_CAP and AV_SYNC_CAP, other bits in DPRX_FEATURE_ENUMERATION_LIST. v3: (Jani) - Add support for bits 7:4 and 1 as per DP v1.4 for DPRX_FEATURE_ENUMERATION_LIST. Cc: Rodrigo Vivi Cc: Jim Bride Signed-off-by: Vathsala Nagaraju Signed-off-by: Patil Deepti Reviewed-by: Jani Nikula --- include/drm/drm_dp_helper.h | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 55bbeb0..0468135 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -194,7 +194,8 @@ # define DP_PSR_SETUP_TIME_0(6 << 1) # define DP_PSR_SETUP_TIME_MASK (7 << 1) # define DP_PSR_SETUP_TIME_SHIFT1 - +# define DP_PSR2_SU_Y_COORDINATE_REQUIRED (1 << 4) /* eDP 1.4a */ +# define DP_PSR2_SU_GRANULARITY_REQUIRED(1 << 5) /* eDP 1.4b */ /* * 0x80-0x8f describe downstream port capabilities, but there are two layouts * based on whether DP_DETAILED_CAP_INFO_AVAILABLE was set. If it was not, @@ -568,6 +569,16 @@ #define DP_RECEIVER_ALPM_STATUS0x200b /* eDP 1.4 */ # define DP_ALPM_LOCK_TIMEOUT_ERROR(1 << 0) +#define DP_DPRX_FEATURE_ENUMERATION_LIST0x2210 /* DP 1.3 */ +# define DP_GTC_CAP(1 << 0) /* DP 1.3 */ +# define DP_SST_SPLIT_SDP_CAP (1 << 1) /* DP 1.4 */ +# define DP_AV_SYNC_CAP(1 << 2) /* DP 1.3 */ +# define DP_VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED (1 << 3) /* DP 1.3 */ +# define DP_VSC_EXT_VESA_SDP_SUPPORTED (1 << 4) /* DP 1.4 */ +# define DP_VSC_EXT_VESA_SDP_CHAINING_SUPPORTED(1 << 5) /* DP 1.4 */ +# define DP_VSC_EXT_CEA_SDP_SUPPORTED (1 << 6) /* DP 1.4 */ +# define DP_VSC_EXT_CEA_SDP_CHAINING_SUPPORTED (1 << 7) /* DP 1.4 */ + /* DP 1.2 Sideband message defines */ /* peer device type - DP 1.2a Table 2-92 */ #define DP_PEER_DEVICE_NONE0x0 -- 1.9.1
[PATCH 02/10] drm/i915/psr: program vsc header for psr2
Function hsw_psr_setup handles vsc header setup for psr1 and
skl_psr_setup_vsc handles vsc header setup for psr2.
Setup VSC header in function skl_psr_setup_vsc for psr2 support,
as per edp 1.4 spec, table 6-11:VSC SDP HEADER Extension for psr2
operation.
v2: (Jani)
- Initialize variables to 0
- intel_dp_get_y_cord_status and intel_dp_get_y_cord_status made static
- Correct indentation for continuation lines
- Change DP_PSR_Y_COORDINATE to DP_PSR2_SU_Y_COORDINATE_REQUIRED
- Change DPRX_FEATURE_ENUMERATION_LIST to DP_DPRX_*
- Change VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED to DP_VSC_*
Cc: Rodrigo Vivi
Cc: Jim Bride
Signed-off-by: Vathsala Nagaraju
Signed-off-by: Patil Deepti
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_dp.c | 26 ++
drivers/gpu/drm/i915/intel_psr.c | 17 +++--
3 files changed, 43 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 22d3f61..36dc835 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1164,6 +1164,8 @@ struct i915_psr {
bool psr2_support;
bool aux_frame_sync;
bool link_standby;
+ bool y_cord_support;
+ bool colorimetry_support;
};
enum intel_pch {
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index fb12896..da577c9 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3042,6 +3042,24 @@ static void chv_dp_post_pll_disable(struct intel_encoder
*encoder,
DP_LINK_STATUS_SIZE) == DP_LINK_STATUS_SIZE;
}
+static bool intel_dp_get_y_cord_status(struct intel_dp *intel_dp)
+{
+ uint8_t psr_caps = 0;
+
+ drm_dp_dpcd_readb(&intel_dp->aux, DP_PSR_CAPS, &psr_caps);
+ return psr_caps & DP_PSR2_SU_Y_COORDINATE_REQUIRED;
+}
+
+static bool intel_dp_get_colorimetry_status(struct intel_dp *intel_dp)
+{
+ uint8_t dprx = 0;
+
+ drm_dp_dpcd_readb(&intel_dp->aux,
+ DP_DPRX_FEATURE_ENUMERATION_LIST,
+ &dprx);
+ return dprx & DP_VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED;
+}
+
/* These are source-specific values. */
uint8_t
intel_dp_voltage_max(struct intel_dp *intel_dp)
@@ -3620,6 +3638,14 @@ void intel_dp_set_idle_link_train(struct intel_dp
*intel_dp)
dev_priv->psr.psr2_support = dev_priv->psr.aux_frame_sync;
DRM_DEBUG_KMS("PSR2 %s on sink",
dev_priv->psr.psr2_support ? "supported" : "not
supported");
+
+ if (dev_priv->psr.psr2_support) {
+ dev_priv->psr.y_cord_support =
+ intel_dp_get_y_cord_status(intel_dp);
+ dev_priv->psr.colorimetry_support =
+ intel_dp_get_colorimetry_status(intel_dp);
+ }
+
}
/* Read the eDP Display control capabilities registers */
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 6aca8ff..c3aa649 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -122,13 +122,26 @@ static void vlv_psr_setup_vsc(struct intel_dp *intel_dp)
static void skl_psr_setup_su_vsc(struct intel_dp *intel_dp)
{
struct edp_vsc_psr psr_vsc;
+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+ struct drm_device *dev = intel_dig_port->base.base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
/* Prepare VSC Header for SU as per EDP 1.4 spec, Table 6.11 */
memset(&psr_vsc, 0, sizeof(psr_vsc));
psr_vsc.sdp_header.HB0 = 0;
psr_vsc.sdp_header.HB1 = 0x7;
- psr_vsc.sdp_header.HB2 = 0x3;
- psr_vsc.sdp_header.HB3 = 0xb;
+ if (dev_priv->psr.colorimetry_support &&
+ dev_priv->psr.y_cord_support) {
+ psr_vsc.sdp_header.HB2 = 0x5;
+ psr_vsc.sdp_header.HB3 = 0x13;
+ } else if (dev_priv->psr.y_cord_support) {
+ psr_vsc.sdp_header.HB2 = 0x4;
+ psr_vsc.sdp_header.HB3 = 0xe;
+ } else {
+ psr_vsc.sdp_header.HB2 = 0x3;
+ psr_vsc.sdp_header.HB3 = 0xc;
+ }
+
intel_psr_write_vsc(intel_dp, &psr_vsc);
}
--
1.9.1
[PATCH 2/2] [media] v4l: Add 10-bits per channel YUV pixel formats
The formats added by this patch are:
V4L2_PIX_FMT_P010
V4L2_PIX_FMT_P010M
Currently, none of driver uses those format, but some video device
has been confirmed with could as those format for video output.
The Rockchip's new decoder has supported those format for profile_10
HEVC/AVC video.
Signed-off-by: Randy Li
---
include/uapi/linux/videodev2.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 46e8a2e3..9e03f20 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -551,6 +551,7 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_NV61v4l2_fourcc('N', 'V', '6', '1') /* 16 Y/CrCb
4:2:2 */
#define V4L2_PIX_FMT_NV24v4l2_fourcc('N', 'V', '2', '4') /* 24 Y/CbCr
4:4:4 */
#define V4L2_PIX_FMT_NV42v4l2_fourcc('N', 'V', '4', '2') /* 24 Y/CrCb
4:4:4 */
+#define V4L2_PIX_FMT_P010v4l2_fourcc('P', '0', '1', '0') /* 15 Y/CbCr
4:2:0, 10 bits per channel */
/* two non contiguous planes - one Y, one Cr + Cb interleaved */
#define V4L2_PIX_FMT_NV12M v4l2_fourcc('N', 'M', '1', '2') /* 12 Y/CbCr
4:2:0 */
@@ -559,6 +560,7 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_NV61M v4l2_fourcc('N', 'M', '6', '1') /* 16 Y/CrCb
4:2:2 */
#define V4L2_PIX_FMT_NV12MT v4l2_fourcc('T', 'M', '1', '2') /* 12 Y/CbCr
4:2:0 64x32 macroblocks */
#define V4L2_PIX_FMT_NV12MT_16X16 v4l2_fourcc('V', 'M', '1', '2') /* 12
Y/CbCr 4:2:0 16x16 macroblocks */
+#define V4L2_PIX_FMT_P010M v4l2_fourcc('P', 'M', '1', '0') /* 15 Y/CbCr
4:2:0, 10 bits per channel */
/* three planes - Y Cb, Cr */
#define V4L2_PIX_FMT_YUV410 v4l2_fourcc('Y', 'U', 'V', '9') /* 9 YUV 4:1:0
*/
--
2.7.4
[PATCH v7 4/5] ARM: dts: da850-lcdk: add the vga-bridge node
On Wednesday 14 December 2016 03:24 PM, Tomi Valkeinen wrote: > On 13/12/16 12:09, Bartosz Golaszewski wrote: >> Add the vga-bridge node to the board DT together with corresponding >> ports and vga connector. This allows to retrieve the edid info from >> the display automatically. >> >> Signed-off-by: Bartosz Golaszewski >> Reviewed-by: Laurent Pinchart >> --- >> arch/arm/boot/dts/da850-lcdk.dts | 51 >> >> 1 file changed, 51 insertions(+) > > Reviewed-by: Tomi Valkeinen Applied to v4.11/dt with Tomi's reviewed-by. Thanks, Sekhar
[PATCH 06/10] drm/i915/psr: set CHICKEN_TRANS for psr2
As per bpsec, CHICKEN_TRANS_EDP bit 12 ,15
must be programmed.
Enable bit 12 for programmable header packet.
Enable bit 15 for Y cordinate support.
Cc: Rodrigo Vivi
Cc: Jim Bride
Signed-off-by: vathsala nagaraju
Signed-off-by: Patil Deepti
---
drivers/gpu/drm/i915/i915_reg.h | 7 +++
drivers/gpu/drm/i915/intel_psr.c | 7 +++
2 files changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 7830e6e..5ca506a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6449,6 +6449,13 @@ enum {
#define BDW_DPRS_MASK_VBLANK_SRD (1 << 0)
#define CHICKEN_PIPESL_1(pipe) _MMIO_PIPE(pipe, _CHICKEN_PIPESL_1_A,
_CHICKEN_PIPESL_1_B)
+#define CHICKEN_TRANS_A 0x420c0
+#define CHICKEN_TRANS_B 0x420c4
+#define CHICKEN_TRANS(trans) _MMIO_TRANS(trans, CHICKEN_TRANS_A,
CHICKEN_TRANS_B)
+#define TRANS_EDP 3
+#define CHICKEN_TRANS_BIT12(1<<12)
+#define CHICKEN_TRANS_BIT15(1<<15)
+
#define DISP_ARB_CTL _MMIO(0x45000)
#define DISP_FBC_MEMORY_WAKE (1<<31)
#define DISP_TILE_SURFACE_SWIZZLING (1<<13)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 494e4b2..2e75ef6 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -332,6 +332,7 @@ static void hsw_enable_source_psr2(struct intel_dp
*intel_dp)
*/
uint32_t idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
uint32_t val = EDP_PSR_ENABLE;
+ uint32_t chicken_trans = 0;
val |= idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
@@ -349,6 +350,12 @@ static void hsw_enable_source_psr2(struct intel_dp
*intel_dp)
else
val |= EDP_PSR2_TP2_TIME_50;
+ /* Set CHICKEN_TRANS_BIT15 if Y coordinate is supported */
+ if (dev_priv->psr.y_cord_support)
+ chicken_trans = CHICKEN_TRANS_BIT15;
+ /* Set CHICKEN_TRANS_BIT12 for programable header */
+ chicken_trans = chicken_trans | CHICKEN_TRANS_BIT12;
+ I915_WRITE(CHICKEN_TRANS(TRANS_EDP), chicken_trans);
I915_WRITE(EDP_PSR2_CTL, val);
}
--
1.9.1
[PATCH 1/2] drm_fourcc: Add new P010 video format
P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits
per channel video format. Rockchip's vop support this
video format(little endian only) as the input video format.
Signed-off-by: Randy Li
---
include/uapi/drm/drm_fourcc.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 9e1bb7f..d2721da 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -119,6 +119,7 @@ extern "C" {
#define DRM_FORMAT_NV61fourcc_code('N', 'V', '6', '1') /* 2x1
subsampled Cb:Cr plane */
#define DRM_FORMAT_NV24fourcc_code('N', 'V', '2', '4') /*
non-subsampled Cr:Cb plane */
#define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
+#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2
subsampled Cr:Cb plane 10 bits per channel */
/*
* 3 plane YCbCr
--
2.7.4
[PATCH 05/10] drm/i915/psr: enable ALPM for psr2
As per edp1.4 spec , alpm is required for psr2 operation as it's
used for all psr2 main link power down management and alpm enable
bit must be set for psr2 operation.
Cc: Rodrigo Vivi
Cc: Jim Bride
Signed-off-by: vathsala nagaraju
Signed-off-by: Patil Deepti
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_dp.c | 10 ++
drivers/gpu/drm/i915/intel_psr.c | 6 +-
3 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 36dc835..0742b81 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1166,6 +1166,7 @@ struct i915_psr {
bool link_standby;
bool y_cord_support;
bool colorimetry_support;
+ bool alpm;
};
enum intel_pch {
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index da577c9..9b313a3 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3060,6 +3060,14 @@ static bool intel_dp_get_colorimetry_status(struct
intel_dp *intel_dp)
return dprx & DP_VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED;
}
+bool intel_dp_get_alpm_status(struct intel_dp *intel_dp)
+{
+ uint8_t alpm_caps = 0;
+
+ drm_dp_dpcd_readb(&intel_dp->aux, DP_RECEIVER_ALPM_CAP, &alpm_caps);
+ return alpm_caps & DP_ALPM_CAP;
+}
+
/* These are source-specific values. */
uint8_t
intel_dp_voltage_max(struct intel_dp *intel_dp)
@@ -3644,6 +3652,8 @@ void intel_dp_set_idle_link_train(struct intel_dp
*intel_dp)
intel_dp_get_y_cord_status(intel_dp);
dev_priv->psr.colorimetry_support =
intel_dp_get_colorimetry_status(intel_dp);
+ dev_priv->psr.alpm =
+ intel_dp_get_alpm_status(intel_dp);
}
}
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 93eb0f0..494e4b2 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -209,7 +209,11 @@ static void hsw_psr_enable_sink(struct intel_dp *intel_dp)
drm_dp_dpcd_writeb(&intel_dp->aux,
DP_SINK_DEVICE_AUX_FRAME_SYNC_CONF,
DP_AUX_FRAME_SYNC_ENABLE);
-
+ /* Enable ALPM at sink for psr2 */
+ if (dev_priv->psr.psr2_support && dev_priv->psr.alpm)
+ drm_dp_dpcd_writeb(&intel_dp->aux,
+ DP_RECEIVER_ALPM_CONFIG,
+ DP_ALPM_ENABLE);
if (dev_priv->psr.link_standby)
drm_dp_dpcd_writeb(&intel_dp->aux, DP_PSR_EN_CFG,
DP_PSR_ENABLE | DP_PSR_MAIN_LINK_ACTIVE);
--
1.9.1
[PATCH 2/2] [media] v4l: Add 10-bits per channel YUV pixel formats
On 01/02/2017 05:10 PM, Sakari Ailus wrote:
> Hi Randy,
>
> Thanks for the patch.
>
> On Mon, Jan 02, 2017 at 04:50:04PM +0800, Randy Li wrote:
>> The formats added by this patch are:
>> V4L2_PIX_FMT_P010
>> V4L2_PIX_FMT_P010M
>> Currently, none of driver uses those format, but some video device
>> has been confirmed with could as those format for video output.
>> The Rockchip's new decoder has supported those format for profile_10
>> HEVC/AVC video.
>>
>> Signed-off-by: Randy Li
> If the format resembles the existing formats but on a different bit depth,
> it should be named in similar fashion.
Do you mean it would be better if it is called as NV12_10?
>
> Could you also add ReST documentation for the format, please?
I will.
>
> The common requirement for merging patches that change interfaces has been
> that there's a user for that change. It'll still help you to get this
The kernel used in rockchip has supported that format in drm driver, but
just we don't have a agreement about the pixel format. As the Gstreamer
and some others would call it with a P010_ prefix, but Mark(rockchip's
drm author) prefer the something like NV12_10, that is why I sent out
those patches, I want the upstream decided its final name.
> reviewed now so the interface that the future hopefully-in-mainline driver
> provides will not change.
>
>> ---
>> include/uapi/linux/videodev2.h | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
>> index 46e8a2e3..9e03f20 100644
>> --- a/include/uapi/linux/videodev2.h
>> +++ b/include/uapi/linux/videodev2.h
>> @@ -551,6 +551,7 @@ struct v4l2_pix_format {
>> #define V4L2_PIX_FMT_NV61v4l2_fourcc('N', 'V', '6', '1') /* 16 Y/CrCb
>> 4:2:2 */
>> #define V4L2_PIX_FMT_NV24v4l2_fourcc('N', 'V', '2', '4') /* 24 Y/CbCr
>> 4:4:4 */
>> #define V4L2_PIX_FMT_NV42v4l2_fourcc('N', 'V', '4', '2') /* 24 Y/CrCb
>> 4:4:4 */
>> +#define V4L2_PIX_FMT_P010v4l2_fourcc('P', '0', '1', '0') /* 15 Y/CbCr
>> 4:2:0, 10 bits per channel */
>>
>> /* two non contiguous planes - one Y, one Cr + Cb interleaved */
>> #define V4L2_PIX_FMT_NV12M v4l2_fourcc('N', 'M', '1', '2') /* 12 Y/CbCr
>> 4:2:0 */
>> @@ -559,6 +560,7 @@ struct v4l2_pix_format {
>> #define V4L2_PIX_FMT_NV61M v4l2_fourcc('N', 'M', '6', '1') /* 16 Y/CrCb
>> 4:2:2 */
>> #define V4L2_PIX_FMT_NV12MT v4l2_fourcc('T', 'M', '1', '2') /* 12 Y/CbCr
>> 4:2:0 64x32 macroblocks */
>> #define V4L2_PIX_FMT_NV12MT_16X16 v4l2_fourcc('V', 'M', '1', '2') /* 12
>> Y/CbCr 4:2:0 16x16 macroblocks */
>> +#define V4L2_PIX_FMT_P010M v4l2_fourcc('P', 'M', '1', '0') /* 15 Y/CbCr
>> 4:2:0, 10 bits per channel */
>>
>> /* three planes - Y Cb, Cr */
>> #define V4L2_PIX_FMT_YUV410 v4l2_fourcc('Y', 'U', 'V', '9') /* 9 YUV
>> 4:1:0 */
[PATCH 09/10] drm/i915/psr: report live PSR2 State
Reports live state of PSR2 form PSR2_STATUS register.
bit field 31:28 gives the live state of PSR2.
It can be used to check if system is in deep sleep,
selective update or selective update standby.
During video play back, we can use this to check
if system is entering SU mode or not.
when system is in idle state, DEEP_SLEEP(8) must be entered.
When video playback is happening, system must be in
SLEEP(3 / selective update) or SU_STANDBY( 6 / selective update standby)
Cc: Rodrigo Vivi
Cc: Jim Bride
Signed-off-by: Vathsala Nagaraju
Signed-off-by: Patil Deepti
---
drivers/gpu/drm/i915/i915_debugfs.c | 24
drivers/gpu/drm/i915/i915_reg.h | 2 ++
2 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 9d7b5a8..8b0e3f9 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2606,6 +2606,30 @@ static int i915_edp_psr_status(struct seq_file *m, void
*data)
seq_printf(m, "Performance_Counter: %u\n", psrperf);
}
+ if (dev_priv->psr.psr2_support) {
+ static const char * const live_status[] = {
+ "IDLE",
+ "CAPTURE",
+ "CAPTURE_Fs",
+ "SLEEP",
+ "BUFON_FW",
+ "ML_UP",
+ "SU_STANDBY",
+ "FAST_SLEEP",
+ "DEEP_SLEEP",
+ "BUF_ON",
+ "TG_ON" };
+ u8 pos = (I915_READ(EDP_PSR2_STATUS_CTL) &
+ EDP_PSR2_STATUS_STATE_MASK) >>
+ EDP_PSR2_STATUS_STATE_SHIFT;
+
+ seq_printf(m, "PSR2_STATUS_EDP: %x\n",
+ I915_READ(EDP_PSR2_STATUS_CTL));
+
+ if (pos <= EDP_PSR2_STATUS_TG_ON)
+ seq_printf(m, "PSR2 live state %s\n",
+ live_status[pos]);
+ }
mutex_unlock(&dev_priv->psr.lock);
intel_runtime_pm_put(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0cbe564..03a14d9 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3624,6 +3624,8 @@ enum {
#define EDP_PSR2_STATUS_CTL_MMIO(0x6f940)
#define EDP_PSR2_STATUS_STATE_MASK (0xf<<28)
+#define EDP_PSR2_STATUS_STATE_SHIFT28
+#define EDP_PSR2_STATUS_TG_ON 0xa
/* VGA port control */
#define ADPA _MMIO(0x61100)
--
1.9.1
[PATCHv2 4/4] s5p-cec: add hpd-notifier support, move out of staging
On Mon, Jan 02, 2017 at 03:19:07PM +0100, Hans Verkuil wrote:
> From: Hans Verkuil
>
> By using the HPD notifier framework there is no longer any reason
> to manually set the physical address. This was the one blocking
> issue that prevented this driver from going out of staging, so do
> this move as well.
>
> Update the bindings documenting the new hdmi phandle and
> update exynos4.dtsi accordingly.
>
> Tested with my Odroid U3.
>
> Signed-off-by: Hans Verkuil
> Tested-by: Marek Szyprowski
> ---
> .../devicetree/bindings/media/s5p-cec.txt | 2 ++
> arch/arm/boot/dts/exynos4.dtsi | 1 +
> drivers/media/platform/Kconfig | 18 +++
> drivers/media/platform/Makefile| 1 +
> .../media => media/platform}/s5p-cec/Makefile | 0
> .../platform}/s5p-cec/exynos_hdmi_cec.h| 0
> .../platform}/s5p-cec/exynos_hdmi_cecctrl.c| 0
> .../media => media/platform}/s5p-cec/regs-cec.h| 0
> .../media => media/platform}/s5p-cec/s5p_cec.c | 35
> ++
> .../media => media/platform}/s5p-cec/s5p_cec.h | 3 ++
> drivers/staging/media/Kconfig | 2 --
> drivers/staging/media/Makefile | 1 -
> drivers/staging/media/s5p-cec/Kconfig | 9 --
> drivers/staging/media/s5p-cec/TODO | 7 -
> 14 files changed, 55 insertions(+), 24 deletions(-)
> rename drivers/{staging/media => media/platform}/s5p-cec/Makefile (100%)
> rename drivers/{staging/media => media/platform}/s5p-cec/exynos_hdmi_cec.h
> (100%)
> rename drivers/{staging/media =>
> media/platform}/s5p-cec/exynos_hdmi_cecctrl.c (100%)
> rename drivers/{staging/media => media/platform}/s5p-cec/regs-cec.h (100%)
> rename drivers/{staging/media => media/platform}/s5p-cec/s5p_cec.c (89%)
> rename drivers/{staging/media => media/platform}/s5p-cec/s5p_cec.h (97%)
> delete mode 100644 drivers/staging/media/s5p-cec/Kconfig
> delete mode 100644 drivers/staging/media/s5p-cec/TODO
>
> diff --git a/Documentation/devicetree/bindings/media/s5p-cec.txt
> b/Documentation/devicetree/bindings/media/s5p-cec.txt
> index 925ab4d..710fc00 100644
> --- a/Documentation/devicetree/bindings/media/s5p-cec.txt
> +++ b/Documentation/devicetree/bindings/media/s5p-cec.txt
> @@ -15,6 +15,7 @@ Required properties:
>- clock-names : from common clock binding: must contain "hdmicec",
> corresponding to entry in the clocks property.
>- samsung,syscon-phandle - phandle to the PMU system controller
> + - samsung,hdmi-phandle - phandle to the HDMI controller
>
> Example:
>
> @@ -25,6 +26,7 @@ hdmicec: cec at 100B {
> clocks = <&clock CLK_HDMI_CEC>;
> clock-names = "hdmicec";
> samsung,syscon-phandle = <&pmu_system_controller>;
> + samsung,hdmi-phandle = <&hdmi>;
> pinctrl-names = "default";
> pinctrl-0 = <&hdmi_cec>;
> status = "okay";
> diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
> index c64737b..51dfcbb 100644
> --- a/arch/arm/boot/dts/exynos4.dtsi
> +++ b/arch/arm/boot/dts/exynos4.dtsi
> @@ -762,6 +762,7 @@
> clocks = <&clock CLK_HDMI_CEC>;
> clock-names = "hdmicec";
> samsung,syscon-phandle = <&pmu_system_controller>;
> + samsung,hdmi-phandle = <&hdmi>;
> pinctrl-names = "default";
> pinctrl-0 = <&hdmi_cec>;
> status = "disabled";
DTS change has to be a separate patch. It should also go through
arm-soc/samsung-soc tree.
If it is a dependency, then I could provide a tag with it.
Best regards,
Krzysztof
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index d944421..cab1637 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -392,6 +392,24 @@ config VIDEO_TI_SC
> config VIDEO_TI_CSC
> tristate
>
> +menuconfig V4L_CEC_DRIVERS
> + bool "Platform HDMI CEC drivers"
> + depends on MEDIA_CEC_SUPPORT
> +
> +if V4L_CEC_DRIVERS
> +
> +config VIDEO_SAMSUNG_S5P_CEC
> + tristate "Samsung S5P CEC driver"
> + depends on VIDEO_DEV && MEDIA_CEC_SUPPORT && (PLAT_S5P || ARCH_EXYNOS
> || COMPILE_TEST)
> + select HPD_NOTIFIERS
> + ---help---
> + This is a driver for Samsung S5P HDMI CEC interface. It uses the
> + generic CEC framework interface.
> + CEC bus is present in the HDMI connector and enables communication
> + between compatible devices.
> +
> +endif #V4L_CEC_DRIVERS
> +
> menuconfig V4L_TEST_DRIVERS
> bool "Media test drivers"
> depends on MEDIA_CAMERA_SUPPORT
> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> index 5b3cb27..ad3bf22 100644
> --- a/drivers/media/platform/Makefile
> +++ b/drivers/media/platform/Makefile
> @@ -33,6 +33,7 @@ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG)+= s5p-jpeg/
> obj-$(CONFIG_
[PATCH] drm/doc: Document uapi requirements in DRM
On Sun, Jan 1, 2017 at 11:40 PM, Laurent Pinchart wrote: > Hi Daniel, > > Thank you for the patch. > > On Friday 19 Aug 2016 22:50:38 Daniel Vetter wrote: >> Everyone knows them, except all the new folks joining from the ARM >> side haven't lived through all the pain of the past years and are >> entirely surprised when I raise this. Definitely time to document >> this. >> >> Last time this was a big discussion was about 6 years ago, when qcom >> tried to land a kernel driver without userspace. Dave Airlie made the >> rules really clear: >> >> http://airlied.livejournal.com/73115.html >> >> This write-up here is essentially what I've put into a presentation a >> while ago, which was also reviewed by Dave: >> >> http://blog.ffwll.ch/2015/05/gfx-kernel-upstreaming-requirements.html >> >> Cc: Dave Airlie >> Cc: Oded Gabbay >> Cc: Russell King >> Cc: Tomi Valkeinen >> Cc: Eric Anholt >> Cc: Thomas Hellstrom >> Cc: Sinclair Yeh >> Cc: Lucas Stach >> Cc: Benjamin Gaignard >> Cc: Mark Yao >> Cc: Laurent Pinchart >> Cc: Ben Skeggs >> Cc: Rob Clark >> Cc: CK Hu >> Cc: Xinliang Liu >> Cc: Philipp Zabel >> Cc: Stefan Agner >> Cc: Inki Dae >> Cc: Maxime Ripard >> Cc: Boris Brezillon >> Cc: Jani Nikula >> Cc: Daniel Vetter >> Cc: Thierry Reding >> Cc: Christian König >> Cc: Alex Deucher >> Cc: Gerd Hoffmann >> Cc: Brian Starkey >> Cc: Liviu Dudau >> Cc: Alexey Brodkin >> Acked-by: Dave Airlie >> Signed-off-by: Daniel Vetter >> --- >> Documentation/gpu/drm-uapi.rst | 67 +++ >> 1 file changed, 67 insertions(+) >> >> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst >> index 94876938aef3..a7e3aa27167d 100644 >> --- a/Documentation/gpu/drm-uapi.rst >> +++ b/Documentation/gpu/drm-uapi.rst >> @@ -36,6 +36,73 @@ Primary Nodes, DRM Master and Authentication >> Open-Source Userspace Requirements >> == >> >> +The DRM subsystem has stricter requirements on what the userspace side for >> new +uAPI needs to look like. This section here explains what exactly those >> +requirements are, and why they exist. >> + >> +The short summary is that any addition of DRM uAPI requires corresponding >> +open-sourced userspace patches, and those patches must be reviewed and >> ready for +merging into a suitable and canonical upstream project. >> + >> +GFX devices (both display and render/GPU side) are really complex bits of >> hardware, +with userspace and kernel by necessity having to work together >> really closely. +The interfaces, for rendering and modesetting must be >> extremely wide and +flexible, and therefore it is almost always impossible >> to precisely define them +for every possible corner case. This in turns >> makes it really practically +infeasible to differentiate between behaviour >> that's required by userspace, and +which must not be changed to avoid >> regressions, and behaviour which is only an +accidental artifact of the >> current implementation. > > While I agree that this is a proper description of the current state of the > DRM/KMS subsystem, I don't like how it implies that shipping code is an > acceptable replacement for documentation. We need to aim at documenting the > DRM/KMS userspace API to a level of detail that will cover the vast majority > of cases (be they corner or round), if not all of them. I agree that this is a good idea, the trouble is in convincing everyone else, and more important, that this is important enough that they should spent time typing these docs. I think the only way to do that is to 1) type those docs for existing ioctls yourself, and then start and RFC to make it a standard. For properties I'm already starting with at least some not-too-formal docs within the existing kernel-doc stuff. Not there yet either. I somewhat plan to get around to ioctl in the next few years, but would be real awesome if someone beats me to it ;-) >> +Without access to the full source code of all userspace users that means it >> +becomes impossible to change the implementation details, since userspace >> could +depend upon the accidental behaviour of the current implementation >> in minute +details. And debugging such regressions without access to source >> code is pretty +much impossible. As a consequence this means: >> + >> +- The Linux kernel's "no regression" policy holds in practice only for >> + open-source userspace of the DRM subsystem. DRM developers are perfectly >> fine + if closed-source blob drivers in userspace use the same uAPI as the >> open + drivers, > > In which category do you put the open-source userspace code that is not part > of the mainline version of a major userspace framework (X11, Weston, Android > hwcomposer, ...) ? I'm thinking about open-source vendor forks of those > projects, or home-brew implementation of a tailor-made display stack for a > product (I'm intentionally using the word display instead of GFX here, if a > full tailor-made GFX stack
[PATCH 03/10] drm/i915/psr: fix blank screen issue for psr2
Psr1 and psr2 are mutually exclusive,ie when psr2 is enabled,
psr1 should be disabled.When psr2 is exited , bit 31 of reg
PSR2_CTL must be set to 0 but currently bit 31 of SRD_CTL
(psr1 control register)is set to 0.
Also ,PSR2_IDLE state is looked up from SRD_STATUS(psr1 register)
instead of PSR2_STATUS register, which has wrong data, resulting
in blankscreen.
hsw_enable_source is split into hsw_enable_source_psr1 and
hsw_enable_source_psr2 for easier code review and maintenance,
as suggested by rodrigo and jim.
Cc: Rodrigo Vivi
Cc: Jim Bride
Signed-off-by: Vathsala Nagaraju
Signed-off-by: Patil Deepti
---
drivers/gpu/drm/i915/i915_reg.h | 3 +
drivers/gpu/drm/i915/intel_psr.c | 124 +--
2 files changed, 97 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 00970aa..7830e6e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3615,6 +3615,9 @@ enum {
#define EDP_PSR2_FRAME_BEFORE_SU_MASK(0xf<<4)
#define EDP_PSR2_IDLE_MASK 0xf
+#define EDP_PSR2_STATUS_CTL_MMIO(0x6f940)
+#define EDP_PSR2_STATUS_STATE_MASK (0xf<<28)
+
/* VGA port control */
#define ADPA _MMIO(0x61100)
#define PCH_ADPA_MMIO(0xe1100)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index c3aa649..ff2ecfd 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -261,12 +261,11 @@ static void vlv_psr_activate(struct intel_dp *intel_dp)
VLV_EDP_PSR_ACTIVE_ENTRY);
}
-static void hsw_psr_enable_source(struct intel_dp *intel_dp)
+static void hsw_enable_source_psr1(struct intel_dp *intel_dp)
{
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = dig_port->base.base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
-
uint32_t max_sleep_time = 0x1f;
/*
* Let's respect VBT in case VBT asks a higher idle_frame value.
@@ -312,14 +311,30 @@ static void hsw_psr_enable_source(struct intel_dp
*intel_dp)
val |= EDP_PSR_TP1_TP2_SEL;
I915_WRITE(EDP_PSR_CTL, val);
+}
- if (!dev_priv->psr.psr2_support)
- return;
+static void hsw_enable_source_psr2(struct intel_dp *intel_dp)
+{
+ struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+ struct drm_device *dev = dig_port->base.base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+
+ /*
+* Let's respect VBT in case VBT asks a higher idle_frame value.
+* Let's use 6 as the minimum to cover all known cases including
+* the off-by-one issue that HW has in some cases. Also there are
+* cases where sink should be able to train
+* with the 5 or 6 idle patterns.
+*/
+ uint32_t idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
+ uint32_t val = EDP_PSR_ENABLE;
+
+ val |= idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
/* FIXME: selective update is probably totally broken because it doesn't
* mesh at all with our frontbuffer tracking. And the hw alone isn't
* good enough. */
- val = EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
+ val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 5)
val |= EDP_PSR2_TP2_TIME_2500;
@@ -333,6 +348,20 @@ static void hsw_psr_enable_source(struct intel_dp
*intel_dp)
I915_WRITE(EDP_PSR2_CTL, val);
}
+
+static void hsw_psr_enable_source(struct intel_dp *intel_dp)
+{
+ struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+ struct drm_device *dev = dig_port->base.base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+
+ /* psr1 and psr2 are mutually exclusive.*/
+ if (dev_priv->psr.psr2_support)
+ hsw_enable_source_psr2(intel_dp);
+ else
+ hsw_enable_source_psr1(intel_dp);
+}
+
static bool intel_psr_match_conditions(struct intel_dp *intel_dp)
{
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
@@ -410,7 +439,10 @@ static void intel_psr_activate(struct intel_dp *intel_dp)
struct drm_device *dev = intel_dig_port->base.base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
- WARN_ON(I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE);
+ if (dev_priv->psr.psr2_support)
+ WARN_ON(I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE);
+ else
+ WARN_ON(I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE);
WARN_ON(dev_priv->psr.active);
lockdep_assert_held(&dev_priv->psr.lock);
@@ -462,8 +494,6 @@ void intel_psr_enable(struct intel_dp *intel_dp)
dev_priv->psr.busy_frontbuffer_bits = 0;
if (HAS_DDI(dev_priv)) {
- hsw_psr_setup_vsc(intel_dp);
-
if (dev_priv->psr.psr2_sup
[PATCH 08/10] drm/i915/psr: enable psr2 for y cordinate panels
Psr2 is enabled only for y cordinate panels.Once GTC (global time code)
is implemented,this restriction is removed so that psr2
can work on panels without y cordinate support.
Cc: Rodrigo Vivi
Cc: Jim Bride
Signed-off-by: Vathsala Nagaraju
Signed-off-by: Patil Deepti
---
drivers/gpu/drm/i915/intel_psr.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 19cd4d7..ca3ef3e 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -495,6 +495,15 @@ void intel_psr_enable(struct intel_dp *intel_dp)
return;
}
+ /*
+* FIXME:enable psr2 only for y-cordinate psr2 panels
+* After gtc implementation , remove this restriction.
+*/
+ if (!dev_priv->psr.y_cord_support && dev_priv->psr.psr2_support) {
+ DRM_DEBUG_KMS("PSR2 disabled, panel does not support Y
coordinate\n");
+ return;
+ }
+
mutex_lock(&dev_priv->psr.lock);
if (dev_priv->psr.enabled) {
DRM_DEBUG_KMS("PSR already in use\n");
--
1.9.1
[PATCH 0/2] Add pixel format for 10 bits YUV video
Those pixel formats comes from Gstreamer and ffmpeg. Currently, the VOP(video output mixer) found on RK3288 and future support those pixel formats are input. Also the decoder on RK3288 could use them as output. Randy Li (2): drm_fourcc: Add new P010 video format [media] v4l: Add 10-bits per channel YUV pixel formats include/uapi/drm/drm_fourcc.h | 1 + include/uapi/linux/videodev2.h | 2 ++ 2 files changed, 3 insertions(+) -- 2.7.4
[PATCH 10/10] drm/i915/psr: EDP_PSR_PERF_CNT not valid for psr2
PSR1 and PSR2 enable sequence are mutually exclusive.
Register SRD_PERF_COUNT increments while system is in psr1.
This register is not valid for psr2.while in psr2,SRD_PERF_COUNT
is always 0.
Reporting psr perfcount from SRD_PERF_COUNT is not valid for psr2 case.
Also, if dc6 is disabled via kernel parameter i915.enable_dc=0,
EDP_PSR_PERF_CNT can be reported for SKL+ platforms for debug
purpose.
Cc: Rodrigo Vivi
Cc: Jim Bride
Signed-off-by: Vathsala Nagaraju
---
drivers/gpu/drm/i915/i915_debugfs.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 8b0e3f9..4136cec 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2539,6 +2539,7 @@ static int i915_edp_psr_status(struct seq_file *m, void
*data)
u32 stat[3];
enum pipe pipe;
bool enabled = false;
+ bool dc6_enabled = false;
if (!HAS_PSR(dev_priv)) {
seq_puts(m, "PSR not supported\n");
@@ -2598,11 +2599,20 @@ static int i915_edp_psr_status(struct seq_file *m, void
*data)
/*
* VLV/CHV PSR has no kind of performance counter
+* EDP_PSR_PERF_CNT is not valid for psr2.
* SKL+ Perf counter is reset to 0 everytime DC state is entered
+* if we want to read EDP_PSR_PERF_CNT for debug purpose on SKL+,
+* disable dc state in kernel parameter i915.enable_dc=0.
*/
- if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
+
+ dc6_enabled = ((I915_READ(DC_STATE_EN) &
+ DC_STATE_EN_UPTO_DC5_DC6_MASK) ==
+ DC_STATE_EN_UPTO_DC6);
+
+ if ((!dev_priv->psr.psr2_support && !dc6_enabled) ||
+IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
psrperf = I915_READ(EDP_PSR_PERF_CNT) &
- EDP_PSR_PERF_CNT_MASK;
+ EDP_PSR_PERF_CNT_MASK;
seq_printf(m, "Performance_Counter: %u\n", psrperf);
}
--
1.9.1
[PATCH v7 3/5] drm: bridge: add support for TI ths8135
Hi Archit, On Wednesday 14 December 2016 10:35 AM, Archit Taneja wrote: > > > On 12/13/2016 03:39 PM, Bartosz Golaszewski wrote: >> THS8135 is a configurable video DAC, but no configuration is actually >> necessary to make it work. >> >> For now use the dumb-vga-dac driver to support it. > > Queued to drm-misc-next This patch and 2/5 are not in v4.10 kernel. Did you mean to queue them to v4.10? Thanks, Sekhar
[PATCH v7 1/5] ARM: dts: da850: rename the display node label
On Wednesday 14 December 2016 03:27 PM, Tomi Valkeinen wrote:
> On 13/12/16 12:09, Bartosz Golaszewski wrote:
>> The tilcdc node name is 'display' as per the ePAPR 1.1 recommendation.
>> The label is also 'display', but change it to 'lcdc' to make it clear
>> what the underlying hardware is.
>>
>> Signed-off-by: Bartosz Golaszewski
>> ---
>> arch/arm/boot/dts/da850.dtsi | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>> index 104155d..6b0ef3d 100644
>> --- a/arch/arm/boot/dts/da850.dtsi
>> +++ b/arch/arm/boot/dts/da850.dtsi
>> @@ -458,7 +458,7 @@
>> dma-names = "tx", "rx";
>> };
>>
>> -display: display at 213000 {
>> +lcdc: display at 213000 {
>> compatible = "ti,da850-tilcdc";
>> reg = <0x213000 0x1000>;
>> interrupts = <52>;
>>
>
> Reviewed-by: Tomi Valkeinen
Applied with Tomi's reviewed-by.
Thanks,
Sekhar
[RFC v2] drm: Parse HDMI 2.0 YCbCr 4:2:0 VDB and VCB
HDMI 2.0 introduces a new sampling mode called YCbCr 4:2:0.
According to the spec the EDID may contain two blocks that
signal this sampling mode:
- YCbCr 4:2:0 Video Data Block
- YCbCr 4:2:0 Video Capability Map Data Block
The video data block contains the list of vic's were
only YCbCr 4:2:0 sampling mode shall be used while the
video capability map data block contains a mask were
YCbCr 4:2:0 sampling mode may be used.
This RFC patch adds support for parsing these two new blocks
and introduces new flags to signal the drivers if the
mode is 4:2:0'only or 4:2:0'able.
The reason this is still a RFC is because there is no
reference in kernel for this new sampling mode (specially in
AVI infoframe part), so, I was hoping to hear some feedback
first.
Tested in a HDMI 2.0 compliance scenario.
Signed-off-by: Jose Abreu
Cc: Carlos Palminha
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Sean Paul
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
Cc: linux-kernel at vger.kernel.org
---
v2:
- Correct checkpatch errors
drivers/gpu/drm/drm_edid.c | 138 +++-
drivers/gpu/drm/drm_modes.c | 10 +++-
include/uapi/drm/drm_mode.h | 6 ++
3 files changed, 150 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 67d6a73..caa796c 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2549,6 +2549,8 @@ static int drm_cvt_modes(struct drm_connector *connector,
#define VENDOR_BLOCK0x03
#define SPEAKER_BLOCK 0x04
#define VIDEO_CAPABILITY_BLOCK 0x07
+#define VIDEO_DATA_BLOCK_420 0x0E
+#define VIDEO_CAP_BLOCK_4200x0F
#define EDID_BASIC_AUDIO (1 << 6)
#define EDID_CEA_YCRCB444 (1 << 5)
#define EDID_CEA_YCRCB422 (1 << 4)
@@ -3050,6 +3052,99 @@ static int add_3d_struct_modes(struct drm_connector
*connector, u16 structure,
return modes;
}
+static int add_420_mode(struct drm_connector *connector, u8 vic)
+{
+ struct drm_device *dev = connector->dev;
+ struct drm_display_mode *newmode;
+
+ if (!drm_valid_cea_vic(vic))
+ return 0;
+
+ newmode = drm_mode_duplicate(dev, &edid_cea_modes[vic]);
+ if (!newmode)
+ return 0;
+
+ newmode->flags |= DRM_MODE_FLAG_420_ONLY;
+ drm_mode_probed_add(connector, newmode);
+
+ return 1;
+}
+
+static int add_420_vdb_modes(struct drm_connector *connector, const u8 *svds,
+ u8 svds_len)
+{
+ int modes = 0, i;
+
+ for (i = 0; i < svds_len; i++)
+ modes += add_420_mode(connector, svds[i]);
+
+ return modes;
+}
+
+static int add_420_vcb_modes(struct drm_connector *connector, const u8 *svds,
+ u8 svds_len, const u8 *video_db, u8 video_len)
+{
+ struct drm_display_mode *newmode = NULL;
+ int modes = 0, i, j;
+
+ for (i = 0; i < svds_len; i++) {
+ u8 mask = svds[i];
+
+ for (j = 0; j < 8; j++) {
+ if (mask & (1 << j)) {
+ newmode = drm_display_mode_from_vic_index(
+ connector, video_db, video_len,
+ i * 8 + j);
+ if (newmode) {
+ newmode->flags |= DRM_MODE_FLAG_420;
+ drm_mode_probed_add(connector, newmode);
+ modes++;
+ }
+ }
+ }
+ }
+
+ return modes;
+}
+
+static int add_420_vcb_modes_all(struct drm_connector *connector,
+ const u8 *video_db, u8 video_len)
+{
+ struct drm_display_mode *newmode = NULL;
+ int modes = 0, i;
+
+ for (i = 0; i < video_len; i++) {
+ newmode = drm_display_mode_from_vic_index(connector, video_db,
+ video_len, i);
+ if (newmode) {
+ newmode->flags |= DRM_MODE_FLAG_420;
+ drm_mode_probed_add(connector, newmode);
+ modes++;
+ }
+ }
+
+ return modes;
+}
+
+static int do_hdmi_420_modes(struct drm_connector *connector, const u8 *vdb,
+ u8 vdb_len, const u8 *vcb, u8 vcb_len, const u8 *video_db,
+ u8 video_len)
+{
+ int modes = 0;
+
+ if (vdb && (vdb_len > 1)) /* Add 4:2:0 modes present in EDID */
+ modes += add_420_vdb_modes(connector, &vdb[2], vdb_len - 1);
+
+ if (vcb && (vcb_len > 1)) /* Parse bit mask of supported modes */
+ modes += add_420_vcb_modes(connector, &vcb[2], vcb_len - 1,
+ video_db, video_len);
+ else if (vcb) /* All modes support 4:2:0 mode */
+ modes += add_420_vcb_modes_all(connector, video_db, video_len);
+
+ DRM_DEBUG("added %d 4:2:0 modes
[PATCH v7 5/5] ARM: dts: da850: specify the maximum pixel clock rate for tilcdc
On Tuesday 13 December 2016 03:39 PM, Bartosz Golaszewski wrote: > At maximum CPU frequency of 300 MHz the maximum pixel clock frequency > is 37.5 MHz[1]. We must filter out any mode for which the calculated > pixel clock rate would exceed this value. > > Specify the max-pixelclock property for the display node for > da850-lcdk. > > [1] > http://processors.wiki.ti.com/index.php/OMAP-L1x/C674x/AM1x_LCD_Controller_(LCDC)_Throughput_and_Optimization_Techniques This wiki page is not really a TI datasheet and can change without notice. I changed this to refer to http://www.ti.com/lit/ds/symlink/am1808.pdf (SPRS653E, revised March 2014), table 6-110. Applied to v4.11/dt Thanks, Sekhar
[PATCH 07/10] drm/i915/psr: set PSR_MASK bits for deep sleep
Program EDP_PSR_DEBUG_CTL (PSR_MASK) to enable system
to go to deep sleep while in psr2.PSR2_STATUS bit 31:28
should report value 8 , if system enters deep sleep state.
Also, EDP_FRAMES_BEFORE_SU_ENTRY is set 1 , if not set,
flickering is observed on psr2 panel.
Cc: Rodrigo Vivi
Cc: Jim Bride
Signed-off-by: Vathsala Nagaraju
Signed-off-by: Patil Deepti
---
drivers/gpu/drm/i915/i915_reg.h | 7 +++
drivers/gpu/drm/i915/intel_dp.c | 1 -
drivers/gpu/drm/i915/intel_psr.c | 29 -
3 files changed, 27 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5ca506a..0cbe564 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3600,6 +3600,12 @@ enum {
#define EDP_PSR_DEBUG_MASK_LPSP (1<<27)
#define EDP_PSR_DEBUG_MASK_MEMUP (1<<26)
#define EDP_PSR_DEBUG_MASK_HPD (1<<25)
+#define EDP_PSR_DEBUG_MASK_MAX_SLEEP (1<<28)
+#define EDP_PSR_DEBUG_MASK_LPSP (1<<27)
+#define EDP_PSR_DEBUG_MASK_MEMUP (1<<26)
+#define EDP_PSR_DEBUG_MASK_HPD (1<<25)
+#define EDP_PSR_DEBUG_MASK_DISP_REG_WRITE(1<<16)
+#define EDP_PSR_DEBUG_EXIT_ON_PIXEL_UNDERRUN (1<<15)
#define EDP_PSR2_CTL _MMIO(0x6f900)
#define EDP_PSR2_ENABLE (1<<31)
@@ -3614,6 +3620,7 @@ enum {
#define EDP_PSR2_FRAME_BEFORE_SU_SHIFT 4
#define EDP_PSR2_FRAME_BEFORE_SU_MASK(0xf<<4)
#define EDP_PSR2_IDLE_MASK 0xf
+#define EDP_FRAMES_BEFORE_SU_ENTRY (1<<4)
#define EDP_PSR2_STATUS_CTL_MMIO(0x6f940)
#define EDP_PSR2_STATUS_STATE_MASK (0xf<<28)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 9b313a3..0a10858 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3655,7 +3655,6 @@ void intel_dp_set_idle_link_train(struct intel_dp
*intel_dp)
dev_priv->psr.alpm =
intel_dp_get_alpm_status(intel_dp);
}
-
}
/* Read the eDP Display control capabilities registers */
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 2e75ef6..19cd4d7 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -339,7 +339,9 @@ static void hsw_enable_source_psr2(struct intel_dp
*intel_dp)
/* FIXME: selective update is probably totally broken because it doesn't
* mesh at all with our frontbuffer tracking. And the hw alone isn't
* good enough. */
- val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
+ val |= EDP_PSR2_ENABLE |
+ EDP_SU_TRACK_ENABLE |
+ EDP_FRAMES_BEFORE_SU_ENTRY;
if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 5)
val |= EDP_PSR2_TP2_TIME_2500;
@@ -512,18 +514,27 @@ void intel_psr_enable(struct intel_dp *intel_dp)
dev_priv->psr.psr2_support = false;
else
skl_psr_setup_su_vsc(intel_dp);
+ I915_WRITE(EDP_PSR_DEBUG_CTL,
+ EDP_PSR_DEBUG_MASK_MEMUP |
+ EDP_PSR_DEBUG_MASK_HPD |
+ EDP_PSR_DEBUG_MASK_LPSP |
+ EDP_PSR_DEBUG_MASK_MAX_SLEEP |
+ EDP_PSR_DEBUG_MASK_DISP_REG_WRITE);
} else {
/* set up vsc header for psr1 */
hsw_psr_setup_vsc(intel_dp);
+ /*
+* Per Spec: Avoid continuous PSR exit by masking MEMUP
+* and HPD. also mask LPSP to avoid dependency on other
+* drivers that might block runtime_pm besides
+* preventing other hw tracking issues now we can rely
+* on frontbuffer tracking.
+*/
+ I915_WRITE(EDP_PSR_DEBUG_CTL,
+ EDP_PSR_DEBUG_MASK_MEMUP |
+ EDP_PSR_DEBUG_MASK_HPD |
+ EDP_PSR_DEBUG_MASK_LPSP);
}
- /*
-* Per Spec: Avoid continuous PSR exit by masking MEMUP and HPD.
-* Also mask LPSP to avoid dependency on other drivers that
-* might block runtime_pm besides preventing other hw tracking
-* issues now we can rely on frontbuffer tracking.
-*/
- I915_WRITE(EDP_PSR_DEBUG_CTL, EDP_PSR_DEBUG_MASK_MEMUP |
- EDP_PSR_DEBUG_MASK_HPD | EDP_PSR_DEBUG_MASK_LPSP);
/* Enable PSR on the panel */
hsw_psr_enable_sink(intel_dp);
--
1.9.1
[PATCH] drm: add fourcc codes for 16bit R and GR
I chose GR16 because that matches with Mesa texture formats. Unfortunately
RG16 is already taken by DRM_FORMAT_RGB565
<http://lxr.free-electrons.com/ident?v=3.6;i=DRM_FORMAT_RGB565>
So GR32 / RG32 might be better. All other codes in fourcc.h seem to sum up
all planes.
On Mon, Jan 2, 2017 at 3:05 PM, Ville Syrjälä wrote:
> On Mon, Jan 02, 2017 at 01:23:23PM +0100, David Herrmann wrote:
> > Hi
> >
> > On Mon, Jan 2, 2017 at 11:41 AM, Rainer Hochecker
> wrote:
> > > From: Rainer Hochecker
> > >
> > > Add fourcc codes for 16bit planes. Required by mesa for
> > > eglCreateImageKHR to access P010 surfaces created by vaapi.
> > >
> > > Signed-off-by: Rainer Hochecker
> > > ---
> > > include/uapi/drm/drm_fourcc.h | 6 ++
> > > 1 file changed, 6 insertions(+)
> > >
> > > diff --git a/include/uapi/drm/drm_fourcc.h
> b/include/uapi/drm/drm_fourcc.h
> > > index a5890bf..e6ab638 100644
> > > --- a/include/uapi/drm/drm_fourcc.h
> > > +++ b/include/uapi/drm/drm_fourcc.h
> > > @@ -41,10 +41,16 @@ extern "C" {
> > > /* 8 bpp Red */
> > > #define DRM_FORMAT_R8 fourcc_code('R', '8', ' ', ' ') /*
> [7:0] R */
> > >
> > > +/* 16 bpp Red */
> > > +#define DRM_FORMAT_R16 fourcc_code('R', '1', '6', ' ') /*
> [15:0] R */
> > > +
> > > /* 16 bpp RG */
> > > #define DRM_FORMAT_RG88fourcc_code('R', 'G', '8',
> '8') /* [15:0] R:G 8:8 little endian */
> > > #define DRM_FORMAT_GR88fourcc_code('G', 'R', '8',
> '8') /* [15:0] G:R 8:8 little endian */
> > >
> > > +/* 32 bpp GR */
> > > +#define DRM_FORMAT_GR16fourcc_code('G', 'R', '1',
> '6') /* [31:0] G:R 16:16 little endian */
> > > +
> >
> > Shouldn't it be 'G', 'R', '3', '2'?
>
> The name should be _GR1616. Using GR16 for the fourcc seems OK to me
> since we can't fit in the full GR1616 in there. Althogh GR32 could work
> too I suppose.
>
> And what about RG16?
>
> >
> > Also, please put dri-devel on CC.
> >
> > Thanks
> > David
> >
> > > /* 8 bpp RGB */
> > > #define DRM_FORMAT_RGB332 fourcc_code('R', 'G', 'B', '8') /*
> [7:0] R:G:B 3:3:2 */
> > > #define DRM_FORMAT_BGR233 fourcc_code('B', 'G', 'R', '8') /*
> [7:0] B:G:R 2:3:3 */
> > > --
> > > 2.9.3
> > >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Ville Syrjälä
> Intel OTC
>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170102/9ec94c1b/attachment-0001.html>
Re: [PATCH V7 3/4] drm/bridge: Add driver for GE B850v3 LVDS/DP++ Bridge
On 01 January, 2017 21:24 CET, Peter Senna Tschudin wrote:
[ ... ]
> +static void ge_b850v3_lvds_dp_detach(struct drm_bridge *bridge)
> +{
> + struct ge_b850v3_lvds_dp *ptn_bridge
> + = bridge_to_ge_b850v3_lvds_dp(bridge);
> + struct i2c_client *ge_b850v3_lvds_dp_i2c
> + = ptn_bridge->ge_b850v3_lvds_dp_i2c;
> +
> + /* Disable interrupts */
> + i2c_smbus_write_word_data(ge_b850v3_lvds_dp_i2c,
> + STDP4028_DPTX_IRQ_EN_REG, ~STDP4028_DPTX_IRQ_CONFIG);
~STDP4028_DPTX_IRQ_CONFIG? Argh! Will fix this and resend after reviews...
[ ... ]
[PATCH] drm: add fourcc codes for 16bit R and GR
I chose GR16 because that matches with Mesa texture formats. Unfortunately
RG16 is already taken by DRM_FORMAT_RGB565
So GR32 / RG32 might be better. All other codes in fourcc.h seem to sum up
all planes.
(sorry, gmail included some html links on last attempt)
On Mon, Jan 2, 2017 at 3:05 PM, Ville Syrjälä wrote:
> On Mon, Jan 02, 2017 at 01:23:23PM +0100, David Herrmann wrote:
> > Hi
> >
> > On Mon, Jan 2, 2017 at 11:41 AM, Rainer Hochecker
> wrote:
> > > From: Rainer Hochecker
> > >
> > > Add fourcc codes for 16bit planes. Required by mesa for
> > > eglCreateImageKHR to access P010 surfaces created by vaapi.
> > >
> > > Signed-off-by: Rainer Hochecker
> > > ---
> > > include/uapi/drm/drm_fourcc.h | 6 ++
> > > 1 file changed, 6 insertions(+)
> > >
> > > diff --git a/include/uapi/drm/drm_fourcc.h
> b/include/uapi/drm/drm_fourcc.h
> > > index a5890bf..e6ab638 100644
> > > --- a/include/uapi/drm/drm_fourcc.h
> > > +++ b/include/uapi/drm/drm_fourcc.h
> > > @@ -41,10 +41,16 @@ extern "C" {
> > > /* 8 bpp Red */
> > > #define DRM_FORMAT_R8 fourcc_code('R', '8', ' ', ' ') /*
> [7:0] R */
> > >
> > > +/* 16 bpp Red */
> > > +#define DRM_FORMAT_R16 fourcc_code('R', '1', '6', ' ') /*
> [15:0] R */
> > > +
> > > /* 16 bpp RG */
> > > #define DRM_FORMAT_RG88fourcc_code('R', 'G', '8',
> '8') /* [15:0] R:G 8:8 little endian */
> > > #define DRM_FORMAT_GR88fourcc_code('G', 'R', '8',
> '8') /* [15:0] G:R 8:8 little endian */
> > >
> > > +/* 32 bpp GR */
> > > +#define DRM_FORMAT_GR16fourcc_code('G', 'R', '1',
> '6') /* [31:0] G:R 16:16 little endian */
> > > +
> >
> > Shouldn't it be 'G', 'R', '3', '2'?
>
> The name should be _GR1616. Using GR16 for the fourcc seems OK to me
> since we can't fit in the full GR1616 in there. Althogh GR32 could work
> too I suppose.
>
> And what about RG16?
>
> >
> > Also, please put dri-devel on CC.
> >
> > Thanks
> > David
> >
> > > /* 8 bpp RGB */
> > > #define DRM_FORMAT_RGB332 fourcc_code('R', 'G', 'B', '8') /*
> [7:0] R:G:B 3:3:2 */
> > > #define DRM_FORMAT_BGR233 fourcc_code('B', 'G', 'R', '8') /*
> [7:0] B:G:R 2:3:3 */
> > > --
> > > 2.9.3
> > >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Ville Syrjälä
> Intel OTC
>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170102/185bab15/attachment.html>
[PATCH] drm/armada: Fix compile fail
On Fri, Dec 30, 2016 at 05:33:38PM +0100, Daniel Vetter wrote: > I reported the include issue for tracepoints a while ago, but nothing > seems to have happened. Now it bit us, since the drm_mm_print > conversion was broken for armada. Fix them both. Nothing's happened because I haven't had an opportunity to investigate yet. It's not as simple as you think... This has been tested over several kernel versions before submission, and it's also been sitting in my build tree for a while before sending upstream. At no point have I seen the failure you are reporting. The tracepoints have been in use on 4.7 and 4.8 kernels, and it builds fine there without any changes. It's been in my nightly builder, which has found no problems with it, eg, 4.9 allmodconfig: CC [M] drivers/gpu/drm/armada/armada_crtc.o CC [M] drivers/gpu/drm/armada/armada_drv.o CC [M] drivers/gpu/drm/armada/armada_fb.o CC [M] drivers/gpu/drm/armada/armada_fbdev.o CC [M] drivers/gpu/drm/armada/armada_gem.o CC [M] drivers/gpu/drm/armada/armada_overlay.o CC [M] drivers/gpu/drm/armada/armada_trace.o CC [M] drivers/gpu/drm/armada/armada_510.o CC [M] drivers/gpu/drm/armada/armada_debugfs.o LD [M] drivers/gpu/drm/armada/armada.o So the question remains: why do you see it, and I don't - there's something different in our build environments that's triggering it. I always build with a separated object tree - maybe you build in the same tree. Does the problem disappear if you build using a separated object tree (O=/path/to/object/tree) ? However, given the contents of your patch, it seems only relevant for separated object tree builds. So... confused. I'll investigate further once I've updated my cubox tree to 4.9. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[PATCH 2/2] [media] v4l: Add 10-bits per channel YUV pixel formats
On 01/02/2017 07:07 PM, Sakari Ailus wrote:
> Hi,
>
> On Mon, Jan 02, 2017 at 06:53:16PM +0800, ayaka wrote:
>>
>> On 01/02/2017 05:10 PM, Sakari Ailus wrote:
>>> Hi Randy,
>>>
>>> Thanks for the patch.
>>>
>>> On Mon, Jan 02, 2017 at 04:50:04PM +0800, Randy Li wrote:
The formats added by this patch are:
V4L2_PIX_FMT_P010
V4L2_PIX_FMT_P010M
Currently, none of driver uses those format, but some video device
has been confirmed with could as those format for video output.
The Rockchip's new decoder has supported those format for profile_10
HEVC/AVC video.
Signed-off-by: Randy Li
>>> If the format resembles the existing formats but on a different bit depth,
>>> it should be named in similar fashion.
>> Do you mean it would be better if it is called as NV12_10?
> If it otherwise resembles NV12 but just has 10 bits per pixel, I think
> NV12_10 is a good name for it.
The main reason I don't like it is that there is a various of software
having used the P010 for this kind of pixel format. It would leadi a
conflict between them(and I never saw it is used as NV12_10), as the
P010 is more common to be used.
I left a problem unsolved for P010 in v4l2, P010 have two variant,
little endian and big endian. Which could be easy identified in drm
driver(there is a flag for all the big endian pixel format).
>
>>> Could you also add ReST documentation for the format, please?
>> I will.
>>> The common requirement for merging patches that change interfaces has been
>>> that there's a user for that change. It'll still help you to get this
>> The kernel used in rockchip has supported that format in drm driver, but
>> just we don't have a agreement about the pixel format. As the Gstreamer and
>> some others would call it with a P010_ prefix, but Mark(rockchip's drm
>> author) prefer the something like NV12_10, that is why I sent out those
>> patches, I want the upstream decided its final name.
> Ack.
>
> I think we haven't really tried to unify the format naming in the past
> between the two subsystems. If existing conventions exist on both regarding
> this format, then it's probably better to follow those.
>
> Cc Laurent as well.
>
>>> reviewed now so the interface that the future hopefully-in-mainline driver
>>> provides will not change.
>>>
---
include/uapi/linux/videodev2.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/uapi/linux/videodev2.h
b/include/uapi/linux/videodev2.h
index 46e8a2e3..9e03f20 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -551,6 +551,7 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_NV61v4l2_fourcc('N', 'V', '6', '1') /* 16
Y/CrCb 4:2:2 */
#define V4L2_PIX_FMT_NV24v4l2_fourcc('N', 'V', '2', '4') /* 24
Y/CbCr 4:4:4 */
#define V4L2_PIX_FMT_NV42v4l2_fourcc('N', 'V', '4', '2') /* 24
Y/CrCb 4:4:4 */
+#define V4L2_PIX_FMT_P010v4l2_fourcc('P', '0', '1', '0') /* 15
Y/CbCr 4:2:0, 10 bits per channel */
/* two non contiguous planes - one Y, one Cr + Cb interleaved */
#define V4L2_PIX_FMT_NV12M v4l2_fourcc('N', 'M', '1', '2') /* 12
Y/CbCr 4:2:0 */
@@ -559,6 +560,7 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_NV61M v4l2_fourcc('N', 'M', '6', '1') /* 16
Y/CrCb 4:2:2 */
#define V4L2_PIX_FMT_NV12MT v4l2_fourcc('T', 'M', '1', '2') /* 12
Y/CbCr 4:2:0 64x32 macroblocks */
#define V4L2_PIX_FMT_NV12MT_16X16 v4l2_fourcc('V', 'M', '1', '2') /* 12
Y/CbCr 4:2:0 16x16 macroblocks */
+#define V4L2_PIX_FMT_P010M v4l2_fourcc('P', 'M', '1', '0') /* 15
Y/CbCr 4:2:0, 10 bits per channel */
/* three planes - Y Cb, Cr */
#define V4L2_PIX_FMT_YUV410 v4l2_fourcc('Y', 'U', 'V', '9') /* 9 YUV
4:1:0 */
