[Bug 66963] Rv6xx dpm problems
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #294 from Kyle K --- Hello, I have been having problem with my HD6870 for some time. I experienced it on 4.7/4.8/4.9 kernels (haven't tested earlier). My HD6870 works great out of the box with DPM enabled, I do not have any issues for general use. I do have a problem with applications that put heavier load on GPU, for example MPV with hw acceleration enabled. My R600 tries to upclock from 300Mhz base d efault but fails with: Apr 21 00:34:22 xenon kernel: [drm:btc_dpm_set_power_state [radeon]] *ERROR* rv770_restrict_performance_levels_before_switch failed Apr 21 00:34:33 xenon kernel: [drm:btc_dpm_set_power_state [radeon]] *ERROR* rv770_restrict_performance_levels_before_switch failed I can reproduce this every time with: $ mpv --hwdec=vdpau --vo=vdpau The video playback follows but it is very choppy as you would imagine. Attempting to use VAAPI pipeline for hw decoding results in hard system crash with blank screen after just few seconds of playback. I can reproduce it always with: $ mpv --hwdec=vaapi --vo=vaapi I'm booting with radeon.dpm=0 as a workaround, vdpau hw decoding is butter smooth and playback in mpv is very reliable, however temps and noise is not as great :( I used to run Arch on latest 4.10 kernel but recently I'm playing around with Solus so I'm on 4.9.22, here are stock settings with DPM enabled on Solus system that I have this problem: root@xenon /home/kyle # cat /proc/version Linux version 4.9.22-17.lts (root@solus-build-server) (gcc version 6.3.0 (Solus) ) #1 SMP Sat Apr 15 06:05:30 UTC 2017 root@xenon /home/kyle # grep . /sys/module/radeon/parameters/* /sys/module/radeon/parameters/agpmode:0 /sys/module/radeon/parameters/aspm:-1 /sys/module/radeon/parameters/audio:-1 /sys/module/radeon/parameters/auxch:-1 /sys/module/radeon/parameters/backlight:-1 /sys/module/radeon/parameters/bapm:-1 /sys/module/radeon/parameters/benchmark:0 /sys/module/radeon/parameters/connector_table:0 /sys/module/radeon/parameters/deep_color:0 /sys/module/radeon/parameters/disp_priority:0 /sys/module/radeon/parameters/dpm:-1 /sys/module/radeon/parameters/dynclks:-1 /sys/module/radeon/parameters/fastfb:0 /sys/module/radeon/parameters/gartsize:1024 /sys/module/radeon/parameters/hard_reset:0 /sys/module/radeon/parameters/hw_i2c:0 /sys/module/radeon/parameters/lockup_timeout:1 /sys/module/radeon/parameters/modeset:1 /sys/module/radeon/parameters/msi:-1 /sys/module/radeon/parameters/mst:0 /sys/module/radeon/parameters/no_wb:0 /sys/module/radeon/parameters/pcie_gen2:-1 /sys/module/radeon/parameters/r4xx_atom:0 /sys/module/radeon/parameters/runpm:-1 /sys/module/radeon/parameters/test:0 /sys/module/radeon/parameters/tv:1 /sys/module/radeon/parameters/use_pflipirq:2 /sys/module/radeon/parameters/uvd:1 /sys/module/radeon/parameters/vce:1 /sys/module/radeon/parameters/vm_block_size:12 /sys/module/radeon/parameters/vm_size:8 /sys/module/radeon/parameters/vramlimit:0 root@xenon /home/kyle # md5sum /lib/firmware/radeon/R600_* f2432caf487c4b586a2c391435f3749c /lib/firmware/radeon/R600_me.bin 448dbf1df580c31a0e55de22bb076be3 /lib/firmware/radeon/R600_pfp.bin f74a5163948bde215be6b689ca24afde /lib/firmware/radeon/R600_rlc.bin 9bc76ae83f9326debf728f98803a7e11 /lib/firmware/radeon/R600_uvd.bin libdrm, version: 2.4.76, release: 16 Alex, I do not know if you're still keeping eye on this Bug but your attention and effort would be hugely appreciated! Thank you -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: fourcc byteorder: drop DRM_FORMAT_BIG_ENDIAN
It's unused.
Suggested-by: Daniel Vetter
Signed-off-by: Gerd Hoffmann
---
include/uapi/drm/drm_fourcc.h | 2 --
drivers/gpu/drm/drm_fourcc.c | 3 +--
drivers/gpu/drm/drm_framebuffer.c | 2 +-
3 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 1579765..97f26d9 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -33,8 +33,6 @@ extern "C" {
#define fourcc_code(a, b, c, d) ((__u32)(a) | ((__u32)(b) << 8) | \
((__u32)(c) << 16) | ((__u32)(d) << 24))
-#define DRM_FORMAT_BIG_ENDIAN (1<<31) /* format is big endian instead of
little endian */
-
/* color index */
#define DRM_FORMAT_C8 fourcc_code('C', '8', ' ', ' ') /* [7:0] C */
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 9c0152d..adb3ff5 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -86,12 +86,11 @@ EXPORT_SYMBOL(drm_mode_legacy_fb_format);
const char *drm_get_format_name(uint32_t format, struct drm_format_name_buf
*buf)
{
snprintf(buf->str, sizeof(buf->str),
-"%c%c%c%c %s-endian (0x%08x)",
+"%c%c%c%c (0x%08x)",
printable_char(format & 0xff),
printable_char((format >> 8) & 0xff),
printable_char((format >> 16) & 0xff),
printable_char((format >> 24) & 0x7f),
-format & DRM_FORMAT_BIG_ENDIAN ? "big" : "little",
format);
return buf->str;
diff --git a/drivers/gpu/drm/drm_framebuffer.c
b/drivers/gpu/drm/drm_framebuffer.c
index fc8ef42..efe8b5e 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -152,7 +152,7 @@ static int framebuffer_check(struct drm_device *dev,
int i;
/* check if the format is supported at all */
- info = __drm_format_info(r->pixel_format & ~DRM_FORMAT_BIG_ENDIAN);
+ info = __drm_format_info(r->pixel_format);
if (!info) {
struct drm_format_name_buf format_name;
DRM_DEBUG_KMS("bad framebuffer format %s\n",
--
2.9.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: fourcc byteorder: brings header file comments in line with reality.
While working on graphics support for virtual machines on ppc64 (which
exists in both little and big endian variants) I've figured the comments
for various drm fourcc formats in the header file don't match reality.
Comments says the RGB formats are little endian, but in practice they
are native endian. Look at the drm_mode_legacy_fb_format() helper. It
maps -- for example -- bpp/depth 32/24 to DRM_FORMAT_XRGB, no matter
whenever the machine is little endian or big endian. The users of this
function (fbdev emulation, DRM_IOCTL_MODE_ADDFB) expect the framebuffer
is native endian, not little endian. Most userspace also operates on
native endian only.
So, go update the comments for all 16+24+32 bpp RGB formats.
Leaving the yuv formats as-is. I have no idea if and how those are used
on bigendian machines.
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Pekka Paalanen
Cc: Ilia Mirkin
Cc: Michel Dänzer
Cc: Alex Deucher
Cc: amd-...@lists.freedesktop.org
Signed-off-by: Gerd Hoffmann
---
include/uapi/drm/drm_fourcc.h | 82 +--
1 file changed, 41 insertions(+), 41 deletions(-)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 995c8f9..1579765 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -42,68 +42,68 @@ extern "C" {
#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
little endian */
+#define DRM_FORMAT_R16 fourcc_code('R', '1', '6', ' ') /* [15:0] R
native endian */
/* 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 */
+#define DRM_FORMAT_RG88fourcc_code('R', 'G', '8', '8') /*
[15:0] R:G 8:8 native endian */
+#define DRM_FORMAT_GR88fourcc_code('G', 'R', '8', '8') /*
[15:0] G:R 8:8 native endian */
/* 32 bpp RG */
-#define DRM_FORMAT_RG1616 fourcc_code('R', 'G', '3', '2') /* [31:0] R:G
16:16 little endian */
-#define DRM_FORMAT_GR1616 fourcc_code('G', 'R', '3', '2') /* [31:0] G:R
16:16 little endian */
+#define DRM_FORMAT_RG1616 fourcc_code('R', 'G', '3', '2') /* [31:0] R:G
16:16 native endian */
+#define DRM_FORMAT_GR1616 fourcc_code('G', 'R', '3', '2') /* [31:0] G:R
16:16 native endian */
/* 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 */
/* 16 bpp RGB */
-#define DRM_FORMAT_XRGBfourcc_code('X', 'R', '1', '2') /* [15:0]
x:R:G:B 4:4:4:4 little endian */
-#define DRM_FORMAT_XBGRfourcc_code('X', 'B', '1', '2') /* [15:0]
x:B:G:R 4:4:4:4 little endian */
-#define DRM_FORMAT_RGBXfourcc_code('R', 'X', '1', '2') /* [15:0]
R:G:B:x 4:4:4:4 little endian */
-#define DRM_FORMAT_BGRXfourcc_code('B', 'X', '1', '2') /* [15:0]
B:G:R:x 4:4:4:4 little endian */
+#define DRM_FORMAT_XRGBfourcc_code('X', 'R', '1', '2') /* [15:0]
x:R:G:B 4:4:4:4 native endian */
+#define DRM_FORMAT_XBGRfourcc_code('X', 'B', '1', '2') /* [15:0]
x:B:G:R 4:4:4:4 native endian */
+#define DRM_FORMAT_RGBXfourcc_code('R', 'X', '1', '2') /* [15:0]
R:G:B:x 4:4:4:4 native endian */
+#define DRM_FORMAT_BGRXfourcc_code('B', 'X', '1', '2') /* [15:0]
B:G:R:x 4:4:4:4 native endian */
-#define DRM_FORMAT_ARGBfourcc_code('A', 'R', '1', '2') /* [15:0]
A:R:G:B 4:4:4:4 little endian */
-#define DRM_FORMAT_ABGRfourcc_code('A', 'B', '1', '2') /* [15:0]
A:B:G:R 4:4:4:4 little endian */
-#define DRM_FORMAT_RGBAfourcc_code('R', 'A', '1', '2') /* [15:0]
R:G:B:A 4:4:4:4 little endian */
-#define DRM_FORMAT_BGRAfourcc_code('B', 'A', '1', '2') /* [15:0]
B:G:R:A 4:4:4:4 little endian */
+#define DRM_FORMAT_ARGBfourcc_code('A', 'R', '1', '2') /* [15:0]
A:R:G:B 4:4:4:4 native endian */
+#define DRM_FORMAT_ABGRfourcc_code('A', 'B', '1', '2') /* [15:0]
A:B:G:R 4:4:4:4 native endian */
+#define DRM_FORMAT_RGBAfourcc_code('R', 'A', '1', '2') /* [15:0]
R:G:B:A 4:4:4:4 native endian */
+#define DRM_FORMAT_BGRAfourcc_code('B', 'A', '1', '2') /* [15:0]
B:G:R:A 4:4:4:4 native endian */
-#define DRM_FORMAT_XRGB1555fourcc_code('X', 'R', '1', '5') /* [15:0]
x:R:G:B 1:5:5:5 little endian */
-#define DRM_FORMAT_XBGR1555fourcc_code('X', 'B', '1', '5') /* [15:0]
x:B:G:R 1:5:5:5 little endian */
-#define DRM_FORMAT_RGBX5551fourcc_code('R', 'X', '1', '5') /* [15:0]
R:G:B:x 5:5:5:1 little endian */
-#define DRM_FORMAT_BGRX5551fourcc_code('B', 'X', '1', '5') /* [15:0]
B:G:R:x 5:5:5:1 little endian */
+#define DRM_FORMAT_XRGB1555fourcc_code('X', 'R', '1', '5') /* [15:0]
x:R:G:B 1:5:5:5 native endian */
Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.
On Fri, 21 Apr 2017 09:58:24 +0200 Gerd Hoffmann wrote: > While working on graphics support for virtual machines on ppc64 (which > exists in both little and big endian variants) I've figured the comments > for various drm fourcc formats in the header file don't match reality. > > Comments says the RGB formats are little endian, but in practice they > are native endian. Look at the drm_mode_legacy_fb_format() helper. It > maps -- for example -- bpp/depth 32/24 to DRM_FORMAT_XRGB, no matter > whenever the machine is little endian or big endian. The users of this > function (fbdev emulation, DRM_IOCTL_MODE_ADDFB) expect the framebuffer > is native endian, not little endian. Most userspace also operates on > native endian only. > > So, go update the comments for all 16+24+32 bpp RGB formats. > > Leaving the yuv formats as-is. I have no idea if and how those are used > on bigendian machines. > > Cc: Ville Syrjälä > Cc: Daniel Vetter > Cc: Pekka Paalanen > Cc: Ilia Mirkin > Cc: Michel Dänzer > Cc: Alex Deucher > Cc: amd-...@lists.freedesktop.org > Signed-off-by: Gerd Hoffmann > --- > include/uapi/drm/drm_fourcc.h | 82 > +-- > 1 file changed, 41 insertions(+), 41 deletions(-) Hi, just an idea - since we are not sure how the remaining formats are being used, should those be marked somehow uncertain whether they are little or native endian? Otherwise the documentation will guide people to believe those are certain, which OTOH might not be bad, because then it will make them certain over time. Unless we would prefer everything to be native endian? This might be a chance to choose the endianess (native vs. little) for all formats. Should we take it? Prefer native? Thanks, pq pgpOcMRsA9j10.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100375] forced EDID's can cause a amdgpu to null ptr deref
https://bugs.freedesktop.org/show_bug.cgi?id=100375 --- Comment #5 from Michel Dänzer --- (In reply to Edward O'Callaghan from comment #4) > The actual root causes is that if a page flip is in progress something races > on that fd and causes the null ptr deref: How did you determine that it's related to a page flip (or amdgpu in the first place)? I don't see the connection between that and set_root. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/cec: Add CEC over Aux register definitions
On Thu, 20 Apr 2017, clinton.a.tay...@intel.com wrote: > From: Clint Taylor > > Adding DPCD register definitions from the DP 1.3 specification for CEC > over AUX support. > > V2: Add DP_ prefix to all defines. > V3: missed prefixes from the ESI1 defines > > Cc: Jani Nikula > > Reviewed-by: Jani Nikula > Signed-off-by: Clint Taylor Pushed to drm-misc-next, thanks for the patch. BR, Jani. > --- > include/drm/drm_dp_helper.h | 59 > +++ > 1 file changed, 59 insertions(+) > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > index c0bd0d7..3f4ad70 100644 > --- a/include/drm/drm_dp_helper.h > +++ b/include/drm/drm_dp_helper.h > @@ -603,6 +603,9 @@ > #define DP_DEVICE_SERVICE_IRQ_VECTOR_ESI0 0x2003 /* 1.2 */ > > #define DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1 0x2004 /* 1.2 */ > +# define DP_RX_GTC_MSTR_REQ_STATUS_CHANGE(1 << 0) > +# define DP_LOCK_ACQUISITION_REQUEST (1 << 1) > +# define DP_CEC_IRQ (1 << 2) > > #define DP_LINK_SERVICE_IRQ_VECTOR_ESI0 0x2005 /* 1.2 */ > > @@ -636,6 +639,62 @@ > # 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 */ > > +/* HDMI CEC tunneling over AUX DP 1.3 section 5.3.3.3.1 DPCD 1.4+ */ > +#define DP_CEC_TUNNELING_CAPABILITY0x3000 > +# define DP_CEC_TUNNELING_CAPABLE (1 << 0) > +# define DP_CEC_SNOOPING_CAPABLE(1 << 1) > +# define DP_CEC_MULTIPLE_LA_CAPABLE (1 << 2) > + > +#define DP_CEC_TUNNELING_CONTROL 0x3001 > +# define DP_CEC_TUNNELING_ENABLE(1 << 0) > +# define DP_CEC_SNOOPING_ENABLE (1 << 1) > + > +#define DP_CEC_RX_MESSAGE_INFO 0x3002 > +# define DP_CEC_RX_MESSAGE_LEN_MASK (0xf << 0) > +# define DP_CEC_RX_MESSAGE_LEN_SHIFT0 > +# define DP_CEC_RX_MESSAGE_HPD_STATE(1 << 4) > +# define DP_CEC_RX_MESSAGE_HPD_LOST (1 << 5) > +# define DP_CEC_RX_MESSAGE_ACKED(1 << 6) > +# define DP_CEC_RX_MESSAGE_ENDED(1 << 7) > + > +#define DP_CEC_TX_MESSAGE_INFO 0x3003 > +# define DP_CEC_TX_MESSAGE_LEN_MASK (0xf << 0) > +# define DP_CEC_TX_MESSAGE_LEN_SHIFT0 > +# define DP_CEC_TX_RETRY_COUNT_MASK (0x7 << 4) > +# define DP_CEC_TX_RETRY_COUNT_SHIFT4 > +# define DP_CEC_TX_MESSAGE_SEND (1 << 7) > + > +#define DP_CEC_TUNNELING_IRQ_FLAGS 0x3004 > +# define DP_CEC_RX_MESSAGE_INFO_VALID (1 << 0) > +# define DP_CEC_RX_MESSAGE_OVERFLOW (1 << 1) > +# define DP_CEC_TX_MESSAGE_SENT (1 << 4) > +# define DP_CEC_TX_LINE_ERROR (1 << 5) > +# define DP_CEC_TX_ADDRESS_NACK_ERROR (1 << 6) > +# define DP_CEC_TX_DATA_NACK_ERROR (1 << 7) > + > +#define DP_CEC_LOGICAL_ADDRESS_MASK0x300E /* 0x300F word */ > +# define DP_CEC_LOGICAL_ADDRESS_0 (1 << 0) > +# define DP_CEC_LOGICAL_ADDRESS_1 (1 << 1) > +# define DP_CEC_LOGICAL_ADDRESS_2 (1 << 2) > +# define DP_CEC_LOGICAL_ADDRESS_3 (1 << 3) > +# define DP_CEC_LOGICAL_ADDRESS_4 (1 << 4) > +# define DP_CEC_LOGICAL_ADDRESS_5 (1 << 5) > +# define DP_CEC_LOGICAL_ADDRESS_6 (1 << 6) > +# define DP_CEC_LOGICAL_ADDRESS_7 (1 << 7) > +#define DP_CEC_LOGICAL_ADDRESS_MASK_2 0x300F /* 0x300E word */ > +# define DP_CEC_LOGICAL_ADDRESS_8 (1 << 0) > +# define DP_CEC_LOGICAL_ADDRESS_9 (1 << 1) > +# define DP_CEC_LOGICAL_ADDRESS_10 (1 << 2) > +# define DP_CEC_LOGICAL_ADDRESS_11 (1 << 3) > +# define DP_CEC_LOGICAL_ADDRESS_12 (1 << 4) > +# define DP_CEC_LOGICAL_ADDRESS_13 (1 << 5) > +# define DP_CEC_LOGICAL_ADDRESS_14 (1 << 6) > +# define DP_CEC_LOGICAL_ADDRESS_15 (1 << 7) > + > +#define DP_CEC_RX_MESSAGE_BUFFER 0x3010 > +#define DP_CEC_TX_MESSAGE_BUFFER 0x3020 > +#define DP_CEC_MESSAGE_BUFFER_LENGTH 0x10 > + > /* 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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 10/10] drm: omapdrm: Take GEM obj and DRM dev references when exporting dmabuf
Hi Chris,
On Friday 21 Apr 2017 00:08:21 Chris Wilson wrote:
> On Fri, Apr 21, 2017 at 12:33:59AM +0300, Laurent Pinchart wrote:
> > To ensure that neither the GEM object nor the DRM device goes away while
> > a GEM object exported through dma-buf is still accessible, take a
> > reference to both the GEM object and the DRM device at export time. The
> > dma-buf release handler already releases the GEM object (which resulted
> > in a refcount underflow) and now also releases the DRM device.
> >
> > Fixes: 6ad11bc3a0b8 ("staging: drm/omap: dmabuf/prime support")
> > Signed-off-by: Laurent Pinchart
> > ---
> >
> > drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 17 +
> > 1 file changed, 13 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
> > b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c index
> > 79dfded9613c..88ad723b3044 100644
> > --- a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
> > +++ b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
> > @@ -75,10 +75,11 @@ static void omap_gem_unmap_dma_buf(struct
> > dma_buf_attachment *attachment,>
> > static void omap_gem_dmabuf_release(struct dma_buf *buffer)
> > {
> >
> > struct drm_gem_object *obj = buffer->priv;
> >
> > - /* release reference that was taken when dmabuf was exported
> > -* in omap_gem_prime_set()..
> > -*/
> > + struct drm_device *dev = obj->dev;
> > +
> > + /* Release references taken by omap_gem_prime_export(). */
> >
> > drm_gem_object_unreference_unlocked(obj);
> >
> > + drm_dev_ref(dev);
> >
> > }
> >
> > @@ -184,13 +185,21 @@ struct dma_buf *omap_gem_prime_export(struct
> > drm_device *dev,>
> > struct drm_gem_object *obj, int flags)
> >
> > {
> >
> > DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
> >
> > + struct dma_buf *dma_buf;
> >
> > exp_info.ops = &omap_dmabuf_ops;
> > exp_info.size = obj->size;
> > exp_info.flags = flags;
> > exp_info.priv = obj;
> >
> > - return dma_buf_export(&exp_info);
> > + dma_buf = dma_buf_export(&exp_info);
> > + if (IS_ERR(dma_buf))
> > + return dma_buf;
> > +
> > + drm_dev_ref(dev);
> > + drm_gem_object_reference(obj);
> > +
> > + return dma_buf;
> >
> > }
>
> Please see drm_gem_dmabuf_export() and drm_gem_dmabuf_release()
Good point, I'll replace the custom implementation by those functions. I had
noticed drm_gem_dmabuf_release() but for some reason failed to see that
drm_gem_dmabuf_export() was exported.
> - unless the double drm_dev_ref() wasn't an accident...
Oops :-/ Thank you for catching that.
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/28] drm/ttm: fix include notation and remove -Iinclude/drm flag
On 20/04/17 06:56 PM, Masahiro Yamada wrote: > Include instead of relative path from include/drm, then > remove the -Iinclude/drm compiler flag. > > The fixes of include/drm/ttm/*.h will help driver Makefiles drop > -Iinclude/drm flag. > > Signed-off-by: Masahiro Yamada [...] > diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h > index 6bbd34d..5071d0e 100644 > --- a/include/drm/ttm/ttm_bo_driver.h > +++ b/include/drm/ttm/ttm_bo_driver.h > @@ -30,10 +30,10 @@ > #ifndef _TTM_BO_DRIVER_H_ > #define _TTM_BO_DRIVER_H_ > > -#include > -#include > -#include > -#include > +#include > +#include > +#include > +#include > #include > #include > #include > diff --git a/include/drm/ttm/ttm_execbuf_util.h > b/include/drm/ttm/ttm_execbuf_util.h > index 47f35b8..3ad2477 100644 > --- a/include/drm/ttm/ttm_execbuf_util.h > +++ b/include/drm/ttm/ttm_execbuf_util.h > @@ -31,7 +31,7 @@ > #ifndef _TTM_EXECBUF_UTIL_H_ > #define _TTM_EXECBUF_UTIL_H_ > > -#include > +#include > #include > > /** > diff --git a/include/drm/ttm/ttm_lock.h b/include/drm/ttm/ttm_lock.h > index 2902beb..e8a5fcf 100644 > --- a/include/drm/ttm/ttm_lock.h > +++ b/include/drm/ttm/ttm_lock.h > @@ -49,7 +49,7 @@ > #ifndef _TTM_LOCK_H_ > #define _TTM_LOCK_H_ > > -#include > +#include > #include > #include > > diff --git a/include/drm/ttm/ttm_object.h b/include/drm/ttm/ttm_object.h > index 1487011..1c1b9cc 100644 > --- a/include/drm/ttm/ttm_object.h > +++ b/include/drm/ttm/ttm_object.h > @@ -42,7 +42,7 @@ > #include > #include > #include > -#include > +#include > > /** > * enum ttm_ref_type > These could all be simplified to #include "ttm_memory.h" etc. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/28] drm/amd: fix include notation and remove -Iinclude/drm flag
On 20/04/17 06:56 PM, Masahiro Yamada wrote: > Include instead of relative path from include/drm, then > remove the -Iinclude/drm compiler flag. > > Signed-off-by: Masahiro Yamada This patch and patch 12 are Reviewed-by: Michel Dänzer -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 08/12] drm: mali-dp: Add CTM support
From: Mihail Atanassov
All DPs have a COLORADJ matrix which is applied prior to output gamma.
Attach that to the CTM property. Also, ensure the input CTM's coefficients
can fit in the DP registers' Q3.12 format.
Signed-off-by: Mihail Atanassov
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_crtc.c | 64 +--
drivers/gpu/drm/arm/malidp_drv.c | 35 -
drivers/gpu/drm/arm/malidp_drv.h | 1 +
drivers/gpu/drm/arm/malidp_hw.h | 1 +
drivers/gpu/drm/arm/malidp_regs.h | 1 +
5 files changed, 98 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_crtc.c
b/drivers/gpu/drm/arm/malidp_crtc.c
index 27ab09459b9d..8f2e1ae51ba0 100644
--- a/drivers/gpu/drm/arm/malidp_crtc.c
+++ b/drivers/gpu/drm/arm/malidp_crtc.c
@@ -195,6 +195,58 @@ static int malidp_crtc_atomic_check_gamma(struct drm_crtc
*crtc,
return 0;
}
+/*
+ * Check if there is a new CTM and if it contains valid input. Valid here means
+ * that the number is inside the representable range for a Q3.12 number,
+ * excluding truncating the fractional part of the input data.
+ *
+ * The COLORADJ registers can be changed atomically.
+ */
+static int malidp_crtc_atomic_check_ctm(struct drm_crtc *crtc,
+ struct drm_crtc_state *state)
+{
+ struct malidp_crtc_state *mc = to_malidp_crtc_state(state);
+ struct drm_color_ctm *ctm;
+ int i;
+
+ if (!state->color_mgmt_changed)
+ return 0;
+
+ if (!state->ctm)
+ return 0;
+
+ if (crtc->state->ctm && (crtc->state->ctm->base.id ==
+state->ctm->base.id))
+ return 0;
+
+ /*
+* The size of the ctm is checked in
+* drm_atomic_replace_property_blob_from_id.
+*/
+ ctm = (struct drm_color_ctm *)state->ctm->data;
+ for (i = 0; i < ARRAY_SIZE(ctm->matrix); ++i) {
+ /* Convert from S31.32 to Q3.12. */
+ s64 val = ctm->matrix[i];
+ u32 mag = u64)val) & ~BIT_ULL(63)) >> 20) &
+ GENMASK_ULL(14, 0);
+
+ /*
+* Convert to 2s complement and check the destination's top bit
+* for overflow. NB: Can't check before converting or it'd
+* incorrectly reject the case:
+* sign == 1
+* mag == 0x2000
+*/
+ if (val & BIT_ULL(63))
+ mag = ~mag + 1;
+ if (!!(val & BIT_ULL(63)) != !!(mag & BIT(14)))
+ return -EINVAL;
+ mc->coloradj_coeffs[i] = mag;
+ }
+
+ return 0;
+}
+
static int malidp_crtc_atomic_check(struct drm_crtc *crtc,
struct drm_crtc_state *state)
{
@@ -204,6 +256,7 @@ static int malidp_crtc_atomic_check(struct drm_crtc *crtc,
const struct drm_plane_state *pstate;
u32 rot_mem_free, rot_mem_usable;
int rotated_planes = 0;
+ int ret;
/*
* check if there is enough rotation memory available for planes
@@ -270,7 +323,10 @@ static int malidp_crtc_atomic_check(struct drm_crtc *crtc,
}
}
- return malidp_crtc_atomic_check_gamma(crtc, state);
+ ret = malidp_crtc_atomic_check_gamma(crtc, state);
+ ret = ret ? ret : malidp_crtc_atomic_check_ctm(crtc, state);
+
+ return ret;
}
static const struct drm_crtc_helper_funcs malidp_crtc_helper_funcs = {
@@ -295,6 +351,8 @@ static struct drm_crtc_state
*malidp_crtc_duplicate_state(struct drm_crtc *crtc)
__drm_atomic_helper_crtc_duplicate_state(crtc, &state->base);
memcpy(state->gamma_coeffs, old_state->gamma_coeffs,
sizeof(state->gamma_coeffs));
+ memcpy(state->coloradj_coeffs, old_state->coloradj_coeffs,
+ sizeof(state->coloradj_coeffs));
return &state->base;
}
@@ -392,8 +450,8 @@ int malidp_crtc_init(struct drm_device *drm)
drm_crtc_helper_add(&malidp->crtc, &malidp_crtc_helper_funcs);
drm_mode_crtc_set_gamma_size(&malidp->crtc, MALIDP_GAMMA_LUT_SIZE);
- /* No inverse-gamma and color adjustments yet. */
- drm_crtc_enable_color_mgmt(&malidp->crtc, 0, false,
MALIDP_GAMMA_LUT_SIZE);
+ /* No inverse-gamma: it is per-plane */
+ drm_crtc_enable_color_mgmt(&malidp->crtc, 0, true,
MALIDP_GAMMA_LUT_SIZE);
return 0;
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 1eb6bbc5118a..eae41e26b819 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -79,6 +79,37 @@ static void malidp_atomic_commit_update_gamma(struct
drm_crtc *crtc,
}
}
+static
+void malidp_atomic_commit_update_coloradj(struct drm_crtc *crtc,
+ struct drm_crtc_state *old_state)
+{
+ struct malidp_drm *malidp = crtc_to_mal
[PATCH 07/12] drm: mali-dp: enable gamma support
From: Mihail Atanassov
Add gamma via the DRM GAMMA_LUT/GAMMA_LUT_SIZE CRTC
properties. The expected LUT size is 4096 in order
to produce as accurate a set of segments as possible.
This version uses only the green channel's gamma curve
to set the hardware curve on DP550/650. For the sake of
simplicity, it uses the same table of coefficients for
all 3 curves on DP500.
Signed-off-by: Mihail Atanassov
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_crtc.c | 122 --
drivers/gpu/drm/arm/malidp_drv.c | 51
drivers/gpu/drm/arm/malidp_drv.h | 1 +
drivers/gpu/drm/arm/malidp_hw.c | 3 +
drivers/gpu/drm/arm/malidp_hw.h | 6 ++
drivers/gpu/drm/arm/malidp_regs.h | 22 ++-
6 files changed, 196 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_crtc.c
b/drivers/gpu/drm/arm/malidp_crtc.c
index ec1396f79cbd..27ab09459b9d 100644
--- a/drivers/gpu/drm/arm/malidp_crtc.c
+++ b/drivers/gpu/drm/arm/malidp_crtc.c
@@ -93,6 +93,108 @@ static void malidp_crtc_disable(struct drm_crtc *crtc)
}
}
+static const struct gamma_curve_segment {
+ u16 start;
+ u16 end;
+} segments[MALIDP_COEFFTAB_NUM_COEFFS] = {
+ /* sector 0 */
+ {0,0 }, {1,1 }, {2,2 }, {3,3 },
+ {4,4 }, {5,5 }, {6,6 }, {7,7 },
+ {8,8 }, {9,9 }, { 10, 10 }, { 11, 11 },
+ { 12, 12 }, { 13, 13 }, { 14, 14 }, { 15, 15 },
+ /* sector 1 */
+ { 16, 19 }, { 20, 23 }, { 24, 27 }, { 28, 31 },
+ /* sector 2 */
+ { 32, 39 }, { 40, 47 }, { 48, 55 }, { 56, 63 },
+ /* sector 3 */
+ { 64, 79 }, { 80, 95 }, { 96, 111 }, { 112, 127 },
+ /* sector 4 */
+ { 128, 159 }, { 160, 191 }, { 192, 223 }, { 224, 255 },
+ /* sector 5 */
+ { 256, 319 }, { 320, 383 }, { 384, 447 }, { 448, 511 },
+ /* sector 6 */
+ { 512, 639 }, { 640, 767 }, { 768, 895 }, { 896, 1023 },
+ { 1024, 1151 }, { 1152, 1279 }, { 1280, 1407 }, { 1408, 1535 },
+ { 1536, 1663 }, { 1664, 1791 }, { 1792, 1919 }, { 1920, 2047 },
+ { 2048, 2175 }, { 2176, 2303 }, { 2304, 2431 }, { 2432, 2559 },
+ { 2560, 2687 }, { 2688, 2815 }, { 2816, 2943 }, { 2944, 3071 },
+ { 3072, 3199 }, { 3200, 3327 }, { 3328, 3455 }, { 3456, 3583 },
+ { 3584, 3711 }, { 3712, 3839 }, { 3840, 3967 }, { 3968, 4095 },
+};
+
+#define DE_COEFTAB_DATA(a, b) a) & 0xfff) << 16) | (((b) & 0xfff)))
+
+static void malidp_generate_gamma_table(struct drm_property_blob *lut_blob,
+ u32 coeffs[MALIDP_COEFFTAB_NUM_COEFFS])
+{
+ struct drm_color_lut *lut = (struct drm_color_lut *)lut_blob->data;
+ int i;
+
+ for (i = 0; i < MALIDP_COEFFTAB_NUM_COEFFS; ++i) {
+ u32 a, b, delta_in, out_start, out_end;
+
+ delta_in = segments[i].end - segments[i].start;
+ /* DP has 12-bit internal precision for its LUTs. */
+ out_start = drm_color_lut_extract(lut[segments[i].start].green,
+ 12);
+ out_end = drm_color_lut_extract(lut[segments[i].end].green, 12);
+ a = (delta_in == 0) ? 0 : ((out_end - out_start) * 256) /
delta_in;
+ b = out_start;
+ coeffs[i] = DE_COEFTAB_DATA(a, b);
+ }
+}
+
+/*
+ * Check if there is a new gamma LUT and if it is of an acceptable size. Also,
+ * reject any LUTs that use distinct red, green, and blue curves.
+ */
+static int malidp_crtc_atomic_check_gamma(struct drm_crtc *crtc,
+ struct drm_crtc_state *state)
+{
+ struct malidp_crtc_state *mc = to_malidp_crtc_state(state);
+ struct drm_color_lut *lut;
+ size_t lut_size;
+ int i;
+
+ if (!state->color_mgmt_changed || !state->gamma_lut)
+ return 0;
+
+ if (crtc->state->gamma_lut &&
+ (crtc->state->gamma_lut->base.id == state->gamma_lut->base.id))
+ return 0;
+
+ if (state->gamma_lut->length % sizeof(struct drm_color_lut))
+ return -EINVAL;
+
+ lut_size = state->gamma_lut->length / sizeof(struct drm_color_lut);
+ if (lut_size != MALIDP_GAMMA_LUT_SIZE)
+ return -EINVAL;
+
+ lut = (struct drm_color_lut *)state->gamma_lut->data;
+ for (i = 0; i < lut_size; ++i)
+ if (!((lut[i].red == lut[i].green) &&
+ (lut[i].red == lut[i].blue)))
+ return -EINVAL;
+
+ if (!state->mode_changed) {
+ int ret;
+
+ state->mode_changed = true;
+ /*
+* Kerneldoc for drm_atomic_helper_check_modeset mandates that
+* it be invoked when the driver sets ->mode_changed. Since
+
[PATCH 10/12] drm: mali-dp: Add plane upscaling support
From: Mihail Atanassov
Enable the scaling engine for upscaling a single plane using the polyphase
scaler. No image enhancement support or downscaling yet*, and composition
result scaling is not implemented.
* Downscaling a plane requires mclk > pxlclk.
Signed-off-by: Mihail Atanassov
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_crtc.c | 80 +
drivers/gpu/drm/arm/malidp_drv.c| 47
drivers/gpu/drm/arm/malidp_drv.h| 3 +
drivers/gpu/drm/arm/malidp_hw.c | 140
drivers/gpu/drm/arm/malidp_hw.h | 45
drivers/gpu/drm/arm/malidp_planes.c | 75 ++-
drivers/gpu/drm/arm/malidp_regs.h | 36 ++
7 files changed, 409 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_crtc.c
b/drivers/gpu/drm/arm/malidp_crtc.c
index 8f2e1ae51ba0..ceee2a77bfb4 100644
--- a/drivers/gpu/drm/arm/malidp_crtc.c
+++ b/drivers/gpu/drm/arm/malidp_crtc.c
@@ -247,6 +247,82 @@ static int malidp_crtc_atomic_check_ctm(struct drm_crtc
*crtc,
return 0;
}
+static int malidp_crtc_atomic_check_scaling(struct drm_crtc *crtc,
+ struct drm_crtc_state *state)
+{
+ struct malidp_crtc_state *cs = to_malidp_crtc_state(state);
+ struct malidp_se_config *s = &cs->scaler_config;
+ struct drm_plane *plane;
+ const struct drm_plane_state *pstate;
+ u32 h_upscale_factor = 0; /* U16.16 */
+ u32 v_upscale_factor = 0; /* U16.16 */
+ u8 scaling = cs->scaled_planes_mask;
+
+ if (!scaling) {
+ s->scale_enable = false;
+ return 0;
+ }
+
+ /* The scaling engine can only handle one plane at a time. */
+ if (scaling & (scaling - 1))
+ return -EINVAL;
+
+ drm_atomic_crtc_state_for_each_plane_state(plane, pstate, state) {
+ struct malidp_plane *mp = to_malidp_plane(plane);
+ u64 crtc_w, crtc_h;
+ u32 phase;
+
+ if (!(mp->layer->id & scaling))
+ continue;
+
+ /*
+* Convert crtc_[w|h] to U32.32, then divide by U16.16 src_[w|h]
+* to get the U16.16 result.
+*/
+ crtc_w = (u64)pstate->crtc_w << 32;
+ crtc_h = (u64)pstate->crtc_h << 32;
+ h_upscale_factor = (u32)(crtc_w / pstate->src_w);
+ v_upscale_factor = (u32)(crtc_h / pstate->src_h);
+
+ /* Downscaling won't work when mclk == pxlclk. */
+ if (!(h_upscale_factor >> 16) || !(v_upscale_factor >> 16))
+ return -EINVAL;
+
+ s->input_w = pstate->src_w >> 16;
+ s->input_h = pstate->src_h >> 16;
+ s->output_w = pstate->crtc_w;
+ s->output_h = pstate->crtc_h;
+
+#define SE_N_PHASE 4
+#define SE_SHIFT_N_PHASE 12
+ /* Calculate initial_phase and delta_phase for horizontal. */
+ phase = s->input_w;
+ s->h_init_phase =
+ ((phase << SE_N_PHASE) / s->output_w + 1) / 2;
+
+ phase = s->input_w;
+ phase <<= (SE_SHIFT_N_PHASE + SE_N_PHASE);
+ s->h_delta_phase = phase / s->output_w;
+
+ /* Same for vertical. */
+ phase = s->input_h;
+ s->v_init_phase =
+ ((phase << SE_N_PHASE) / s->output_h + 1) / 2;
+
+ phase = s->input_h;
+ phase <<= (SE_SHIFT_N_PHASE + SE_N_PHASE);
+ s->v_delta_phase = phase / s->output_h;
+#undef SE_N_PHASE
+#undef SE_SHIFT_N_PHASE
+ s->plane_src_id = mp->layer->id;
+ }
+
+ s->scale_enable = true;
+ s->hcoeff = malidp_se_select_coeffs(h_upscale_factor);
+ s->vcoeff = malidp_se_select_coeffs(v_upscale_factor);
+ return 0;
+}
+
static int malidp_crtc_atomic_check(struct drm_crtc *crtc,
struct drm_crtc_state *state)
{
@@ -325,6 +401,7 @@ static int malidp_crtc_atomic_check(struct drm_crtc *crtc,
ret = malidp_crtc_atomic_check_gamma(crtc, state);
ret = ret ? ret : malidp_crtc_atomic_check_ctm(crtc, state);
+ ret = ret ? ret : malidp_crtc_atomic_check_scaling(crtc, state);
return ret;
}
@@ -353,6 +430,9 @@ static struct drm_crtc_state
*malidp_crtc_duplicate_state(struct drm_crtc *crtc)
sizeof(state->gamma_coeffs));
memcpy(state->coloradj_coeffs, old_state->coloradj_coeffs,
sizeof(state->coloradj_coeffs));
+ memcpy(&state->scaler_config, &old_state->scaler_config,
+ sizeof(state->scaler_config));
+ state->scaled_planes_mask = 0;
return &state->base;
}
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 24bc96f9e91c..baca2dce1b92 100644
--- a/drivers/gpu/drm/
[PATCH 05/12] drm: mali-dp: add custom reset hook for planes
From: Mihail Atanassov
Now that we are using a custom plane state in mali-dp, we need a
bespoke reset that takes into account the larger structure.
Signed-off-by: Mihail Atanassov
[Updated commit message]
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_planes.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/arm/malidp_planes.c
b/drivers/gpu/drm/arm/malidp_planes.c
index afd59e0f7918..8106e22f9349 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -61,6 +61,27 @@ static void malidp_de_plane_destroy(struct drm_plane *plane)
devm_kfree(plane->dev->dev, mp);
}
+/*
+ * Replicate what the default ->reset hook does: free the state pointer and
+ * allocate a new empty object. We just need enough space to store
+ * a malidp_plane_state instead of a drm_plane_state.
+ */
+static void malidp_plane_reset(struct drm_plane *plane)
+{
+ struct malidp_plane_state *state = to_malidp_plane_state(plane->state);
+
+ if (state)
+ __drm_atomic_helper_plane_destroy_state(&state->base);
+ kfree(state);
+ plane->state = NULL;
+ state = kzalloc(sizeof(*state), GFP_KERNEL);
+ if (state) {
+ state->base.plane = plane;
+ state->base.rotation = DRM_ROTATE_0;
+ plane->state = &state->base;
+ }
+}
+
static struct
drm_plane_state *malidp_duplicate_plane_state(struct drm_plane *plane)
{
@@ -106,7 +127,7 @@ static const struct drm_plane_funcs malidp_de_plane_funcs =
{
.disable_plane = drm_atomic_helper_disable_plane,
.set_property = drm_atomic_helper_plane_set_property,
.destroy = malidp_de_plane_destroy,
- .reset = drm_atomic_helper_plane_reset,
+ .reset = malidp_plane_reset,
.atomic_duplicate_state = malidp_duplicate_plane_state,
.atomic_destroy_state = malidp_destroy_plane_state,
.atomic_print_state = malidp_plane_atomic_print_state,
--
2.12.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 09/12] drm/mali-dp: Add core_id file to the sysfs interface
Add a core_id file in the driver's sysfs directory,
exposing the hardware CORE ID. This is useful to allow
userspace to discover the hardware version used.
Signed-off-by: Mihail Atanassov
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_drv.c | 35 +++
drivers/gpu/drm/arm/malidp_drv.h | 1 +
2 files changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index eae41e26b819..24bc96f9e91c 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -371,6 +371,32 @@ static bool malidp_has_sufficient_address_space(const
struct resource *res,
return true;
}
+static ssize_t core_id_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct drm_device *drm = dev_get_drvdata(dev);
+ struct malidp_drm *malidp = drm->dev_private;
+
+ return snprintf(buf, PAGE_SIZE, "%08x\n", malidp->core_id);
+}
+
+DEVICE_ATTR_RO(core_id);
+
+static int malidp_init_sysfs(struct device *dev)
+{
+ int ret = device_create_file(dev, &dev_attr_core_id);
+
+ if (ret)
+ DRM_ERROR("failed to create device file for core_id\n");
+
+ return ret;
+}
+
+static void malidp_fini_sysfs(struct device *dev)
+{
+ device_remove_file(dev, &dev_attr_core_id);
+}
+
#define MAX_OUTPUT_CHANNELS3
static int malidp_runtime_pm_suspend(struct device *dev)
@@ -503,6 +529,8 @@ static int malidp_bind(struct device *dev)
DRM_INFO("found ARM Mali-DP%3x version r%dp%d\n", version >> 16,
(version >> 12) & 0xf, (version >> 8) & 0xf);
+ malidp->core_id = version;
+
/* set the number of lines used for output of RGB data */
ret = of_property_read_u8_array(dev->of_node,
"arm,malidp-output-port-lines",
@@ -521,6 +549,10 @@ static int malidp_bind(struct device *dev)
if (ret < 0)
goto query_hw_fail;
+ ret = malidp_init_sysfs(dev);
+ if (ret)
+ goto init_fail;
+
/* Set the CRTC's port so that the encoder component can find it */
malidp->crtc.port = of_graph_get_port_by_id(dev->of_node, 0);
@@ -580,6 +612,8 @@ static int malidp_bind(struct device *dev)
bind_fail:
of_node_put(malidp->crtc.port);
malidp->crtc.port = NULL;
+init_fail:
+ malidp_fini_sysfs(dev);
malidp_fini(drm);
query_hw_fail:
pm_runtime_put(dev);
@@ -614,6 +648,7 @@ static void malidp_unbind(struct device *dev)
component_unbind_all(dev, drm);
of_node_put(malidp->crtc.port);
malidp->crtc.port = NULL;
+ malidp_fini_sysfs(dev);
malidp_fini(drm);
pm_runtime_put(dev);
if (pm_runtime_enabled(dev))
diff --git a/drivers/gpu/drm/arm/malidp_drv.h b/drivers/gpu/drm/arm/malidp_drv.h
index e1c784dcdd92..75070efda2fc 100644
--- a/drivers/gpu/drm/arm/malidp_drv.h
+++ b/drivers/gpu/drm/arm/malidp_drv.h
@@ -25,6 +25,7 @@ struct malidp_drm {
wait_queue_head_t wq;
atomic_t config_valid;
struct drm_atomic_state *pm_state;
+ u32 core_id;
};
#define crtc_to_malidp_device(x) container_of(x, struct malidp_drm, crtc)
--
2.12.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 02/12] drm: mali-dp: Enable power management for the device.
Enable runtime and system Power Management. Clocks are now managed
from malidp_crtc_{enable,disable} functions. Suspend-to-RAM tested
as working on Juno.
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_crtc.c | 14 -
drivers/gpu/drm/arm/malidp_drv.c | 128 +++---
drivers/gpu/drm/arm/malidp_drv.h | 1 +
drivers/gpu/drm/arm/malidp_hw.h | 5 ++
4 files changed, 125 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_crtc.c
b/drivers/gpu/drm/arm/malidp_crtc.c
index f9d665550d3e..fab776c37602 100644
--- a/drivers/gpu/drm/arm/malidp_crtc.c
+++ b/drivers/gpu/drm/arm/malidp_crtc.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include "malidp_drv.h"
@@ -58,9 +59,14 @@ static void malidp_crtc_enable(struct drm_crtc *crtc)
struct malidp_drm *malidp = crtc_to_malidp_device(crtc);
struct malidp_hw_device *hwdev = malidp->dev;
struct videomode vm;
+ int err = pm_runtime_get_sync(crtc->dev->dev);
- drm_display_mode_to_videomode(&crtc->state->adjusted_mode, &vm);
+ if (err < 0) {
+ DRM_DEBUG_DRIVER("Failed to enable runtime power management:
%d\n", err);
+ return;
+ }
+ drm_display_mode_to_videomode(&crtc->state->adjusted_mode, &vm);
clk_prepare_enable(hwdev->pxlclk);
/* We rely on firmware to set mclk to a sensible level. */
@@ -75,10 +81,16 @@ static void malidp_crtc_disable(struct drm_crtc *crtc)
{
struct malidp_drm *malidp = crtc_to_malidp_device(crtc);
struct malidp_hw_device *hwdev = malidp->dev;
+ int err;
drm_crtc_vblank_off(crtc);
hwdev->enter_config_mode(hwdev);
clk_disable_unprepare(hwdev->pxlclk);
+
+ err = pm_runtime_put(crtc->dev->dev);
+ if (err < 0) {
+ DRM_DEBUG_DRIVER("Failed to disable runtime power management:
%d\n", err);
+ }
}
static int malidp_crtc_atomic_check(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 5442baf310c8..e954c22bb974 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -13,9 +13,11 @@
#include
#include
#include
+#include
#include
#include
#include
+#include
#include
#include
@@ -91,6 +93,8 @@ static void malidp_atomic_commit_tail(struct drm_atomic_state
*state)
{
struct drm_device *drm = state->dev;
+ pm_runtime_get_sync(drm->dev);
+
drm_atomic_helper_commit_modeset_disables(drm, state);
drm_atomic_helper_commit_planes(drm, state, 0);
@@ -101,6 +105,8 @@ static void malidp_atomic_commit_tail(struct
drm_atomic_state *state)
drm_atomic_helper_wait_for_vblanks(drm, state);
+ pm_runtime_put(drm->dev);
+
drm_atomic_helper_cleanup_planes(drm, state);
}
@@ -283,6 +289,37 @@ static bool malidp_has_sufficient_address_space(const
struct resource *res,
#define MAX_OUTPUT_CHANNELS3
+static int malidp_runtime_pm_suspend(struct device *dev)
+{
+ struct drm_device *drm = dev_get_drvdata(dev);
+ struct malidp_drm *malidp = drm->dev_private;
+ struct malidp_hw_device *hwdev = malidp->dev;
+
+ /* we can only suspend if the hardware is in config mode */
+ WARN_ON(!hwdev->in_config_mode(hwdev));
+
+ hwdev->pm_suspended = true;
+ clk_disable_unprepare(hwdev->mclk);
+ clk_disable_unprepare(hwdev->aclk);
+ clk_disable_unprepare(hwdev->pclk);
+
+ return 0;
+}
+
+static int malidp_runtime_pm_resume(struct device *dev)
+{
+ struct drm_device *drm = dev_get_drvdata(dev);
+ struct malidp_drm *malidp = drm->dev_private;
+ struct malidp_hw_device *hwdev = malidp->dev;
+
+ clk_prepare_enable(hwdev->pclk);
+ clk_prepare_enable(hwdev->aclk);
+ clk_prepare_enable(hwdev->mclk);
+ hwdev->pm_suspended = false;
+
+ return 0;
+}
+
static int malidp_bind(struct device *dev)
{
struct resource *res;
@@ -311,7 +348,6 @@ static int malidp_bind(struct device *dev)
memcpy(hwdev, of_device_get_match_data(dev), sizeof(*hwdev));
malidp->dev = hwdev;
-
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
hwdev->regs = devm_ioremap_resource(dev, res);
if (IS_ERR(hwdev->regs))
@@ -344,14 +380,17 @@ static int malidp_bind(struct device *dev)
goto alloc_fail;
}
- /* Enable APB clock in order to get access to the registers */
- clk_prepare_enable(hwdev->pclk);
- /*
-* Enable AXI clock and main clock so that prefetch can start once
-* the registers are set
-*/
- clk_prepare_enable(hwdev->aclk);
- clk_prepare_enable(hwdev->mclk);
+ drm->dev_private = malidp;
+ dev_set_drvdata(dev, drm);
+
+ /* Enable power management */
+ pm_runtime_enable(dev);
+
+ /* Resume device to enable the clocks
[PATCH 04/12] drm: mali-dp: remove unused variable
From: Arnd Bergmann
The newly introduced function causes a harmless build warning:
drivers/gpu/drm/arm/malidp_planes.c: In function
'malidp_plane_atomic_print_state':
drivers/gpu/drm/arm/malidp_planes.c:98:23: error: unused variable 'mp'
[-Werror=unused-variable]
The variable serves no purpose here and can be removed.
Fixes: 242f43b69c61 ("drm: mali-dp: add atomic_print_state for planes")
Signed-off-by: Arnd Bergmann
Acked-by: Liviu Dudau
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_planes.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/arm/malidp_planes.c
b/drivers/gpu/drm/arm/malidp_planes.c
index 5b0bad87f0b5..afd59e0f7918 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -95,7 +95,6 @@ static void malidp_plane_atomic_print_state(struct
drm_printer *p,
const struct drm_plane_state *state)
{
struct malidp_plane_state *ms = to_malidp_plane_state(state);
- struct malidp_plane *mp = to_malidp_plane(state->plane);
drm_printf(p, "\trotmem_size=%u\n", ms->rotmem_size);
drm_printf(p, "\tformat_id=%u\n", ms->format);
--
2.12.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/12] drm/mali-dp: Collate the pending patches in a series
Hello, This is not a topic series, but a collection of patches that I have acked previously on the dri-devel list and I now plan to push to drm-next. I have rebased on the latest drm-next from 20/04 and also cleaned up some comments compared to what has been already pushed into the mailing list. I'm sending them now to see if there are any more comments to the series, otherwise I will send a pull request to David next week. Best regards, Liviu Arnd Bergmann (1): drm: mali-dp: remove unused variable Liviu Dudau (3): drm: mali-dp: Update the state of all planes before re-enabling active CRTCs. drm: mali-dp: Enable power management for the device. drm/mali-dp: Add core_id file to the sysfs interface Mihail Atanassov (8): drm: mali-dp: add atomic_print_state for planes drm: mali-dp: add custom reset hook for planes drm: mali-dp: add malidp_crtc_state struct drm: mali-dp: enable gamma support drm: mali-dp: Add CTM support drm: mali-dp: Add plane upscaling support drm: mali-dp: Enable image enhancement when scaling drm: mali-dp: Check the mclk rate and allow up/down scaling drivers/gpu/drm/arm/malidp_crtc.c | 342 ++-- drivers/gpu/drm/arm/malidp_drv.c| 307 +--- drivers/gpu/drm/arm/malidp_drv.h| 13 ++ drivers/gpu/drm/arm/malidp_hw.c | 213 ++ drivers/gpu/drm/arm/malidp_hw.h | 81 + drivers/gpu/drm/arm/malidp_planes.c | 110 ++-- drivers/gpu/drm/arm/malidp_regs.h | 72 +++- 7 files changed, 1076 insertions(+), 62 deletions(-) -- 2.12.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/12] drm: mali-dp: add malidp_crtc_state struct
From: Mihail Atanassov
Add a custom CRTC state struct to enable storing driver's private
state. This patch only adds the base drm_crtc_state struct and
the atomic functions that handle it.
Signed-off-by: Mihail Atanassov
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_crtc.c | 52 ---
drivers/gpu/drm/arm/malidp_drv.h | 6 +
2 files changed, 55 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_crtc.c
b/drivers/gpu/drm/arm/malidp_crtc.c
index fab776c37602..ec1396f79cbd 100644
--- a/drivers/gpu/drm/arm/malidp_crtc.c
+++ b/drivers/gpu/drm/arm/malidp_crtc.c
@@ -178,6 +178,52 @@ static const struct drm_crtc_helper_funcs
malidp_crtc_helper_funcs = {
.atomic_check = malidp_crtc_atomic_check,
};
+static struct drm_crtc_state *malidp_crtc_duplicate_state(struct drm_crtc
*crtc)
+{
+ struct malidp_crtc_state *state;
+
+ if (WARN_ON(!crtc->state))
+ return NULL;
+
+ state = kmalloc(sizeof(*state), GFP_KERNEL);
+ if (!state)
+ return NULL;
+
+ __drm_atomic_helper_crtc_duplicate_state(crtc, &state->base);
+
+ return &state->base;
+}
+
+static void malidp_crtc_reset(struct drm_crtc *crtc)
+{
+ struct malidp_crtc_state *state = NULL;
+
+ if (crtc->state) {
+ state = to_malidp_crtc_state(crtc->state);
+ __drm_atomic_helper_crtc_destroy_state(crtc->state);
+ }
+
+ kfree(state);
+ state = kzalloc(sizeof(*state), GFP_KERNEL);
+ if (state) {
+ crtc->state = &state->base;
+ crtc->state->crtc = crtc;
+ }
+}
+
+static void malidp_crtc_destroy_state(struct drm_crtc *crtc,
+ struct drm_crtc_state *state)
+{
+ struct malidp_crtc_state *mali_state = NULL;
+
+ if (state) {
+ mali_state = to_malidp_crtc_state(state);
+ __drm_atomic_helper_crtc_destroy_state(state);
+ }
+
+ kfree(mali_state);
+}
+
static int malidp_crtc_enable_vblank(struct drm_crtc *crtc)
{
struct malidp_drm *malidp = crtc_to_malidp_device(crtc);
@@ -201,9 +247,9 @@ static const struct drm_crtc_funcs malidp_crtc_funcs = {
.destroy = drm_crtc_cleanup,
.set_config = drm_atomic_helper_set_config,
.page_flip = drm_atomic_helper_page_flip,
- .reset = drm_atomic_helper_crtc_reset,
- .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
- .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
+ .reset = malidp_crtc_reset,
+ .atomic_duplicate_state = malidp_crtc_duplicate_state,
+ .atomic_destroy_state = malidp_crtc_destroy_state,
.enable_vblank = malidp_crtc_enable_vblank,
.disable_vblank = malidp_crtc_disable_vblank,
};
diff --git a/drivers/gpu/drm/arm/malidp_drv.h b/drivers/gpu/drm/arm/malidp_drv.h
index cd4c04c65ead..bdc26203a451 100644
--- a/drivers/gpu/drm/arm/malidp_drv.h
+++ b/drivers/gpu/drm/arm/malidp_drv.h
@@ -48,6 +48,12 @@ struct malidp_plane_state {
#define to_malidp_plane(x) container_of(x, struct malidp_plane, base)
#define to_malidp_plane_state(x) container_of(x, struct malidp_plane_state,
base)
+struct malidp_crtc_state {
+ struct drm_crtc_state base;
+};
+
+#define to_malidp_crtc_state(x) container_of(x, struct malidp_crtc_state, base)
+
int malidp_de_planes_init(struct drm_device *drm);
void malidp_de_planes_destroy(struct drm_device *drm);
int malidp_crtc_init(struct drm_device *drm);
--
2.12.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 01/12] drm: mali-dp: Update the state of all planes before re-enabling active CRTCs.
Mali DP needs to have all the planes that are becoming inactive in the
new state disabled before re-enabling the active CRTC, otherwise we
start streaming out data from old pointers in memory.
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_drv.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 898c2b58e73d..5442baf310c8 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -66,10 +66,12 @@ static void malidp_atomic_commit_hw_done(struct
drm_atomic_state *state)
struct drm_pending_vblank_event *event;
struct drm_device *drm = state->dev;
struct malidp_drm *malidp = drm->dev_private;
- int ret = malidp_set_and_wait_config_valid(drm);
- if (ret)
- DRM_DEBUG_DRIVER("timed out waiting for updated
configuration\n");
+ if (malidp->crtc.enabled) {
+ /* only set config_valid if the CRTC is enabled */
+ if (malidp_set_and_wait_config_valid(drm))
+ DRM_DEBUG_DRIVER("timed out waiting for updated
configuration\n");
+ }
event = malidp->crtc.state->event;
if (event) {
@@ -90,9 +92,11 @@ static void malidp_atomic_commit_tail(struct
drm_atomic_state *state)
struct drm_device *drm = state->dev;
drm_atomic_helper_commit_modeset_disables(drm, state);
- drm_atomic_helper_commit_modeset_enables(drm, state);
+
drm_atomic_helper_commit_planes(drm, state, 0);
+ drm_atomic_helper_commit_modeset_enables(drm, state);
+
malidp_atomic_commit_hw_done(state);
drm_atomic_helper_wait_for_vblanks(drm, state);
--
2.12.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 12/12] drm: mali-dp: Check the mclk rate and allow up/down scaling
From: Mihail Atanassov
When downscaling, mclk needs to be sufficiently higher than pxlclk in
order to be able to fetch the higher-resolution data and produce output
pixels. When not scaling, or when upscaling, mclk can be equal to
pxlclk. Since the driver doesn't control mclk, just ensure that the
requirement is satisfied with the current clock rate.
Signed-off-by: Mihail Atanassov
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_crtc.c | 23 ++---
drivers/gpu/drm/arm/malidp_hw.c | 70 +++
drivers/gpu/drm/arm/malidp_hw.h | 4 +++
3 files changed, 85 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_crtc.c
b/drivers/gpu/drm/arm/malidp_crtc.c
index b0f0365efd23..19f1f3b34691 100644
--- a/drivers/gpu/drm/arm/malidp_crtc.c
+++ b/drivers/gpu/drm/arm/malidp_crtc.c
@@ -36,13 +36,6 @@ static bool malidp_crtc_mode_fixup(struct drm_crtc *crtc,
long rate, req_rate = mode->crtc_clock * 1000;
if (req_rate) {
- rate = clk_round_rate(hwdev->mclk, req_rate);
- if (rate < req_rate) {
- DRM_DEBUG_DRIVER("mclk clock unable to reach %d kHz\n",
-mode->crtc_clock);
- return false;
- }
-
rate = clk_round_rate(hwdev->pxlclk, req_rate);
if (rate != req_rate) {
DRM_DEBUG_DRIVER("pxlclk doesn't support %ld Hz\n",
@@ -250,17 +243,21 @@ static int malidp_crtc_atomic_check_ctm(struct drm_crtc
*crtc,
static int malidp_crtc_atomic_check_scaling(struct drm_crtc *crtc,
struct drm_crtc_state *state)
{
+ struct malidp_drm *malidp = crtc_to_malidp_device(crtc);
+ struct malidp_hw_device *hwdev = malidp->dev;
struct malidp_crtc_state *cs = to_malidp_crtc_state(state);
struct malidp_se_config *s = &cs->scaler_config;
struct drm_plane *plane;
+ struct videomode vm;
const struct drm_plane_state *pstate;
u32 h_upscale_factor = 0; /* U16.16 */
u32 v_upscale_factor = 0; /* U16.16 */
u8 scaling = cs->scaled_planes_mask;
+ int ret;
if (!scaling) {
s->scale_enable = false;
- return 0;
+ goto mclk_calc;
}
/* The scaling engine can only handle one plane at a time. */
@@ -284,10 +281,6 @@ static int malidp_crtc_atomic_check_scaling(struct
drm_crtc *crtc,
h_upscale_factor = (u32)(crtc_w / pstate->src_w);
v_upscale_factor = (u32)(crtc_h / pstate->src_h);
- /* Downscaling won't work when mclk == pxlclk. */
- if (!(h_upscale_factor >> 16) || !(v_upscale_factor >> 16))
- return -EINVAL;
-
s->enhancer_enable = ((h_upscale_factor >> 16) >= 2 ||
(v_upscale_factor >> 16) >= 2);
@@ -323,6 +316,12 @@ static int malidp_crtc_atomic_check_scaling(struct
drm_crtc *crtc,
s->scale_enable = true;
s->hcoeff = malidp_se_select_coeffs(h_upscale_factor);
s->vcoeff = malidp_se_select_coeffs(v_upscale_factor);
+
+mclk_calc:
+ drm_display_mode_to_videomode(&state->adjusted_mode, &vm);
+ ret = hwdev->se_calc_mclk(hwdev, s, &vm);
+ if (ret < 0)
+ return -EINVAL;
return 0;
}
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index e444c23a8261..28360b8542f7 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -12,6 +12,7 @@
* in an attempt to provide to the rest of the driver code a unified view
*/
+#include
#include
#include
#include
@@ -334,6 +335,39 @@ static int malidp500_se_set_scaling_coeffs(struct
malidp_hw_device *hwdev,
return 0;
}
+static long malidp500_se_calc_mclk(struct malidp_hw_device *hwdev,
+ struct malidp_se_config *se_config,
+ struct videomode *vm)
+{
+ unsigned long mclk;
+ unsigned long pxlclk = vm->pixelclock; /* Hz */
+ unsigned long htotal = vm->hactive + vm->hfront_porch +
+ vm->hback_porch + vm->hsync_len;
+ unsigned long input_size = se_config->input_w * se_config->input_h;
+ unsigned long a = 10;
+ long ret;
+
+ /*
+* mclk = max(a, 1.5) * pxlclk
+*
+* To avoid float calculaiton, using 15 instead of 1.5 and div by
+* 10 to get mclk.
+*/
+ if (se_config->scale_enable) {
+ a = 15 * input_size / (htotal * se_config->output_h);
+ if (a < 15)
+ a = 15;
+ }
+ mclk = a * pxlclk / 10;
+ ret = clk_get_rate(hwdev->mclk);
+ if (ret < mclk) {
+ DRM_DEBUG_DRIVER("mclk requirement of %lu kHz can't be met.\n",
+
[PATCH 03/12] drm: mali-dp: add atomic_print_state for planes
From: Mihail Atanassov
Add function to dump the state of the plane.
Signed-off-by: Mihail Atanassov
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_planes.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/arm/malidp_planes.c
b/drivers/gpu/drm/arm/malidp_planes.c
index d5aec082294c..5b0bad87f0b5 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include "malidp_hw.h"
#include "malidp_drv.h"
@@ -90,6 +91,17 @@ static void malidp_destroy_plane_state(struct drm_plane
*plane,
kfree(m_state);
}
+static void malidp_plane_atomic_print_state(struct drm_printer *p,
+ const struct drm_plane_state *state)
+{
+ struct malidp_plane_state *ms = to_malidp_plane_state(state);
+ struct malidp_plane *mp = to_malidp_plane(state->plane);
+
+ drm_printf(p, "\trotmem_size=%u\n", ms->rotmem_size);
+ drm_printf(p, "\tformat_id=%u\n", ms->format);
+ drm_printf(p, "\tn_planes=%u\n", ms->n_planes);
+}
+
static const struct drm_plane_funcs malidp_de_plane_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
@@ -98,6 +110,7 @@ static const struct drm_plane_funcs malidp_de_plane_funcs = {
.reset = drm_atomic_helper_plane_reset,
.atomic_duplicate_state = malidp_duplicate_plane_state,
.atomic_destroy_state = malidp_destroy_plane_state,
+ .atomic_print_state = malidp_plane_atomic_print_state,
};
static int malidp_de_plane_check(struct drm_plane *plane,
--
2.12.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 11/12] drm: mali-dp: Enable image enhancement when scaling
From: Mihail Atanassov
Apply image enhacement when we are upscaling by a factor of 2
or more in either direction.
Signed-off-by: Mihail Atanassov
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_crtc.c | 7 ++-
drivers/gpu/drm/arm/malidp_drv.c | 3 +++
drivers/gpu/drm/arm/malidp_hw.h | 20
drivers/gpu/drm/arm/malidp_regs.h | 13 +
4 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/arm/malidp_crtc.c
b/drivers/gpu/drm/arm/malidp_crtc.c
index ceee2a77bfb4..b0f0365efd23 100644
--- a/drivers/gpu/drm/arm/malidp_crtc.c
+++ b/drivers/gpu/drm/arm/malidp_crtc.c
@@ -288,6 +288,9 @@ static int malidp_crtc_atomic_check_scaling(struct drm_crtc
*crtc,
if (!(h_upscale_factor >> 16) || !(v_upscale_factor >> 16))
return -EINVAL;
+ s->enhancer_enable = ((h_upscale_factor >> 16) >= 2 ||
+ (v_upscale_factor >> 16) >= 2);
+
s->input_w = pstate->src_w >> 16;
s->input_h = pstate->src_h >> 16;
s->output_w = pstate->crtc_w;
@@ -530,9 +533,11 @@ int malidp_crtc_init(struct drm_device *drm)
drm_crtc_helper_add(&malidp->crtc, &malidp_crtc_helper_funcs);
drm_mode_crtc_set_gamma_size(&malidp->crtc, MALIDP_GAMMA_LUT_SIZE);
- /* No inverse-gamma: it is per-plane */
+ /* No inverse-gamma: it is per-plane. */
drm_crtc_enable_color_mgmt(&malidp->crtc, 0, true,
MALIDP_GAMMA_LUT_SIZE);
+ malidp_se_set_enh_coeffs(malidp->dev);
+
return 0;
crtc_cleanup_planes:
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index baca2dce1b92..0d3eb537d08b 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -138,6 +138,9 @@ static void malidp_atomic_commit_se_config(struct drm_crtc
*crtc,
val = malidp_hw_read(hwdev, se_control);
val |= MALIDP_SE_SCALING_EN | MALIDP_SE_ALPHA_EN;
+ val &= ~MALIDP_SE_ENH(MALIDP_SE_ENH_MASK);
+ val |= s->enhancer_enable ? MALIDP_SE_ENH(3) : 0;
+
val |= MALIDP_SE_RGBO_IF_EN;
malidp_hw_write(hwdev, val, se_control);
diff --git a/drivers/gpu/drm/arm/malidp_hw.h b/drivers/gpu/drm/arm/malidp_hw.h
index 52a65a8a056f..a93ae0a951a3 100644
--- a/drivers/gpu/drm/arm/malidp_hw.h
+++ b/drivers/gpu/drm/arm/malidp_hw.h
@@ -71,6 +71,7 @@ enum malidp_scaling_coeff_set {
struct malidp_se_config {
u8 scale_enable : 1;
+ u8 enhancer_enable : 1;
u8 hcoeff : 3;
u8 vcoeff : 3;
u8 plane_src_id;
@@ -295,6 +296,25 @@ malidp_se_select_coeffs(u32 upscale_factor)
#undef FP_0_5
#undef FP_0_7
#undef FP_1_0
+
+static inline void malidp_se_set_enh_coeffs(struct malidp_hw_device *hwdev)
+{
+ static const s32 enhancer_coeffs[] = {
+ -8, -8, -8, -8, 128, -8, -8, -8, -8
+ };
+ u32 val = MALIDP_SE_SET_ENH_LIMIT_LOW(MALIDP_SE_ENH_LOW_LEVEL) |
+ MALIDP_SE_SET_ENH_LIMIT_HIGH(MALIDP_SE_ENH_HIGH_LEVEL);
+ u32 image_enh = hwdev->map.se_base +
+ ((hwdev->map.features & MALIDP_REGMAP_HAS_CLEARIRQ) ?
+0x10 : 0xC) + MALIDP_SE_IMAGE_ENH;
+ u32 enh_coeffs = image_enh + MALIDP_SE_ENH_COEFF0;
+ int i;
+
+ malidp_hw_write(hwdev, val, image_enh);
+ for (i = 0; i < ARRAY_SIZE(enhancer_coeffs); ++i)
+ malidp_hw_write(hwdev, enhancer_coeffs[i], enh_coeffs + i * 4);
+}
+
/*
* background color components are defined as 12bits values,
* they will be shifted right when stored on hardware that
diff --git a/drivers/gpu/drm/arm/malidp_regs.h
b/drivers/gpu/drm/arm/malidp_regs.h
index 91d2ba5729bf..2039f857f77d 100644
--- a/drivers/gpu/drm/arm/malidp_regs.h
+++ b/drivers/gpu/drm/arm/malidp_regs.h
@@ -109,6 +109,8 @@
/* Scaling engine registers and masks. */
#define MALIDP_SE_SCALING_EN (1 << 0)
#define MALIDP_SE_ALPHA_EN (1 << 1)
+#define MALIDP_SE_ENH_MASK 3
+#define MALIDP_SE_ENH(x) (((x) & MALIDP_SE_ENH_MASK) <<
2)
#define MALIDP_SE_RGBO_IF_EN (1 << 4)
#define MALIDP550_SE_CTL_SEL_MASK7
#define MALIDP550_SE_CTL_VCSEL(x) \
@@ -139,6 +141,17 @@
#define MALIDP_SE_COEFFTAB_DATA_MASK 0x3fff
#define MALIDP_SE_SET_COEFFTAB_DATA(x) \
((x) & MALIDP_SE_COEFFTAB_DATA_MASK)
+/* Enhance coeffents reigster offset */
+#define MALIDP_SE_IMAGE_ENH0x3C
+/* ENH_LIMITS offset 0x0 */
+#define MALIDP_SE_ENH_LOW_LEVEL24
+#define MALIDP_SE_ENH_HIGH_LEVEL 63
+#define MALIDP_SE_ENH_LIMIT_MASK 0xfff
+#define MALIDP_SE_SET_ENH_LIMIT_LOW(x) \
+ ((x) & MALIDP_SE_ENH_LIMIT_MASK)
+#define MALIDP_SE_SET_ENH_LIMIT_HIGH(x) \
+ (((x) & MALIDP_SE_ENH_LIMIT_MASK) << 16)
+#define MALIDP_SE_
Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.
On Fri, Apr 21, 2017 at 09:58:24AM +0200, Gerd Hoffmann wrote:
> While working on graphics support for virtual machines on ppc64 (which
> exists in both little and big endian variants) I've figured the comments
> for various drm fourcc formats in the header file don't match reality.
>
> Comments says the RGB formats are little endian, but in practice they
> are native endian. Look at the drm_mode_legacy_fb_format() helper. It
> maps -- for example -- bpp/depth 32/24 to DRM_FORMAT_XRGB, no matter
> whenever the machine is little endian or big endian. The users of this
> function (fbdev emulation, DRM_IOCTL_MODE_ADDFB) expect the framebuffer
> is native endian, not little endian. Most userspace also operates on
> native endian only.
I'm not a fan of "native". Native to what? "CPU" or "host" is what I'd
call it.
And what about the mxied endian case? Are you just going to pretend it
doesn't exist or what?
>
> So, go update the comments for all 16+24+32 bpp RGB formats.
>
> Leaving the yuv formats as-is. I have no idea if and how those are used
> on bigendian machines.
>
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Pekka Paalanen
> Cc: Ilia Mirkin
> Cc: Michel Dänzer
> Cc: Alex Deucher
> Cc: amd-...@lists.freedesktop.org
> Signed-off-by: Gerd Hoffmann
> ---
> include/uapi/drm/drm_fourcc.h | 82
> +--
> 1 file changed, 41 insertions(+), 41 deletions(-)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 995c8f9..1579765 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -42,68 +42,68 @@ extern "C" {
> #define DRM_FORMAT_R8fourcc_code('R', '8', ' ', ' ') /*
> [7:0] R */
>
> /* 16 bpp Red */
> -#define DRM_FORMAT_R16 fourcc_code('R', '1', '6', ' ') /*
> [15:0] R little endian */
> +#define DRM_FORMAT_R16 fourcc_code('R', '1', '6', ' ') /*
> [15:0] R native endian */
>
> /* 16 bpp RG */
> -#define DRM_FORMAT_RG88 fourcc_code('R', 'G', '8', '8') /*
> [15:0] R:G 8:8 little endian */
> -#define DRM_FORMAT_GR88 fourcc_code('G', 'R', '8', '8') /*
> [15:0] G:R 8:8 little endian */
> +#define DRM_FORMAT_RG88 fourcc_code('R', 'G', '8', '8') /*
> [15:0] R:G 8:8 native endian */
> +#define DRM_FORMAT_GR88 fourcc_code('G', 'R', '8', '8') /*
> [15:0] G:R 8:8 native endian */
>
> /* 32 bpp RG */
> -#define DRM_FORMAT_RG1616fourcc_code('R', 'G', '3', '2') /* [31:0] R:G
> 16:16 little endian */
> -#define DRM_FORMAT_GR1616fourcc_code('G', 'R', '3', '2') /* [31:0] G:R
> 16:16 little endian */
> +#define DRM_FORMAT_RG1616fourcc_code('R', 'G', '3', '2') /* [31:0] R:G
> 16:16 native endian */
> +#define DRM_FORMAT_GR1616fourcc_code('G', 'R', '3', '2') /* [31:0] G:R
> 16:16 native endian */
>
> /* 8 bpp RGB */
> #define DRM_FORMAT_RGB332fourcc_code('R', 'G', 'B', '8') /* [7:0] R:G:B
> 3:3:2 */
> #define DRM_FORMAT_BGR233fourcc_code('B', 'G', 'R', '8') /* [7:0] B:G:R
> 2:3:3 */
>
> /* 16 bpp RGB */
> -#define DRM_FORMAT_XRGB fourcc_code('X', 'R', '1', '2') /* [15:0]
> x:R:G:B 4:4:4:4 little endian */
> -#define DRM_FORMAT_XBGR fourcc_code('X', 'B', '1', '2') /* [15:0]
> x:B:G:R 4:4:4:4 little endian */
> -#define DRM_FORMAT_RGBX fourcc_code('R', 'X', '1', '2') /* [15:0]
> R:G:B:x 4:4:4:4 little endian */
> -#define DRM_FORMAT_BGRX fourcc_code('B', 'X', '1', '2') /* [15:0]
> B:G:R:x 4:4:4:4 little endian */
> +#define DRM_FORMAT_XRGB fourcc_code('X', 'R', '1', '2') /* [15:0]
> x:R:G:B 4:4:4:4 native endian */
> +#define DRM_FORMAT_XBGR fourcc_code('X', 'B', '1', '2') /* [15:0]
> x:B:G:R 4:4:4:4 native endian */
> +#define DRM_FORMAT_RGBX fourcc_code('R', 'X', '1', '2') /* [15:0]
> R:G:B:x 4:4:4:4 native endian */
> +#define DRM_FORMAT_BGRX fourcc_code('B', 'X', '1', '2') /* [15:0]
> B:G:R:x 4:4:4:4 native endian */
>
> -#define DRM_FORMAT_ARGB fourcc_code('A', 'R', '1', '2') /* [15:0]
> A:R:G:B 4:4:4:4 little endian */
> -#define DRM_FORMAT_ABGR fourcc_code('A', 'B', '1', '2') /* [15:0]
> A:B:G:R 4:4:4:4 little endian */
> -#define DRM_FORMAT_RGBA fourcc_code('R', 'A', '1', '2') /* [15:0]
> R:G:B:A 4:4:4:4 little endian */
> -#define DRM_FORMAT_BGRA fourcc_code('B', 'A', '1', '2') /* [15:0]
> B:G:R:A 4:4:4:4 little endian */
> +#define DRM_FORMAT_ARGB fourcc_code('A', 'R', '1', '2') /* [15:0]
> A:R:G:B 4:4:4:4 native endian */
> +#define DRM_FORMAT_ABGR fourcc_code('A', 'B', '1', '2') /* [15:0]
> A:B:G:R 4:4:4:4 native endian */
> +#define DRM_FORMAT_RGBA fourcc_code('R', 'A', '1', '2') /* [15:0]
> R:G:B:A 4:4:4:4 native endian */
> +#define DRM_FORMAT_BGRA fourcc_code('B', 'A', '1', '2') /* [15:0]
> B:G:R:A 4:4:4:4 native endian */
>
> -#define DRM_FORMAT_XRGB1555 fourcc_code('X', 'R', '1', '5') /* [15:0]
> x:R:G:B 1:5:5:5 little endian */
> -#define
Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.
Hi, > > Leaving the yuv formats as-is. I have no idea if and how those are used > > on bigendian machines. > just an idea - since we are not sure how the remaining formats are being > used, should those be marked somehow uncertain whether they are little > or native endian? ATM the yuv don't have any byte order annotations, and I simply left them that way. So it is as clear/unclear as before. IIRC someone mentioned that for the yuv fourccs there actually is some standard about the exact ordering. Anyone has a good reference? We could stick a link to it into a comment. cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.
On Fri, Apr 21, 2017 at 11:38:28AM +0200, Gerd Hoffmann wrote: > Hi, > > > > Leaving the yuv formats as-is. I have no idea if and how those are used > > > on bigendian machines. > > > just an idea - since we are not sure how the remaining formats are being > > used, should those be marked somehow uncertain whether they are little > > or native endian? > > ATM the yuv don't have any byte order annotations, and I simply left > them that way. So it is as clear/unclear as before. Eh? Everything that is affected by byte order has the relevant comments. If they don't, then that's a bug. > > IIRC someone mentioned that for the yuv fourccs there actually is some > standard about the exact ordering. Anyone has a good reference? We > could stick a link to it into a comment. The "standard" is fourcc. Whether there is any official reference for that is unclear. That's exactly why I added the explicit comments into drm_fourcc.h so that people don't have to go trawling the internets looking for information on what each pixel format might mean. -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.
On Fr, 2017-04-21 at 12:25 +0300, Ville Syrjälä wrote: > On Fri, Apr 21, 2017 at 09:58:24AM +0200, Gerd Hoffmann wrote: > > While working on graphics support for virtual machines on ppc64 (which > > exists in both little and big endian variants) I've figured the comments > > for various drm fourcc formats in the header file don't match reality. > > > > Comments says the RGB formats are little endian, but in practice they > > are native endian. Look at the drm_mode_legacy_fb_format() helper. It > > maps -- for example -- bpp/depth 32/24 to DRM_FORMAT_XRGB, no matter > > whenever the machine is little endian or big endian. The users of this > > function (fbdev emulation, DRM_IOCTL_MODE_ADDFB) expect the framebuffer > > is native endian, not little endian. Most userspace also operates on > > native endian only. > > I'm not a fan of "native". Native to what? "CPU" or "host" is what I'd > call it. native == whatever the cpu is using. I personally find "native" more intuitive, but at the end of the day I don't mind much. If people prefer "host" over "native" I'll change it. > And what about the mxied endian case? Are you just going to pretend it > doesn't exist or what? What exactly do you mean with "mixed endian"? The powerpc case, where kernel + userspace can run in either big or little endian mode? Or something else? cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RFC 3/6] drm: Plane YCbCr to RGB conversion related properties
Add standard properties to control YCbCr to RGB conversion in DRM
planes. The created properties are stored to drm_plane object to allow
different set of supported conversion modes for different planes on
the device. For simplicity the related property blobs for CSC matrix
and YCbCr preoffsets are also stored in the same place. The blob
contents are defined in the uapi/drm/drm_mode.h header.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/drm_atomic.c| 26 +++
drivers/gpu/drm/drm_atomic_helper.c | 9 +++
drivers/gpu/drm/drm_color_mgmt.c| 136 +++-
drivers/gpu/drm/drm_plane.c | 10 +++
include/drm/drm_color_mgmt.h| 23 ++
include/drm/drm_plane.h | 10 +++
include/uapi/drm/drm_mode.h | 12
7 files changed, 223 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index f881319..d1512aa 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -732,6 +732,8 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
{
struct drm_device *dev = plane->dev;
struct drm_mode_config *config = &dev->mode_config;
+ int ret;
+ bool dummy;
if (property == config->prop_fb_id) {
struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, val);
@@ -774,6 +776,22 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
state->rotation = val;
} else if (property == plane->zpos_property) {
state->zpos = val;
+ } else if (property == plane->ycbcr_to_rgb_mode_property) {
+ state->ycbcr_to_rgb_mode = val;
+ } else if (property == plane->ycbcr_to_rgb_csc_property) {
+ ret = drm_atomic_replace_property_blob_from_id(dev,
+ &state->ycbcr_to_rgb_csc,
+ val,
+ sizeof(struct drm_ycbcr_to_rgb_csc),
+ &dummy);
+ return ret;
+ } else if (property == plane->ycbcr_to_rgb_preoffset_property) {
+ ret = drm_atomic_replace_property_blob_from_id(dev,
+ &state->ycbcr_to_rgb_preoffset,
+ val,
+ sizeof(struct drm_ycbcr_to_rgb_preoffset),
+ &dummy);
+ return ret;
} else if (plane->funcs->atomic_set_property) {
return plane->funcs->atomic_set_property(plane, state,
property, val);
@@ -834,6 +852,14 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
*val = state->rotation;
} else if (property == plane->zpos_property) {
*val = state->zpos;
+ } else if (property == plane->ycbcr_to_rgb_mode_property) {
+ *val = state->ycbcr_to_rgb_mode;
+ } else if (property == plane->ycbcr_to_rgb_csc_property) {
+ *val = state->ycbcr_to_rgb_csc ?
+ state->ycbcr_to_rgb_csc->base.id : 0;
+ } else if (property == plane->ycbcr_to_rgb_preoffset_property) {
+ *val = state->ycbcr_to_rgb_preoffset ?
+ state->ycbcr_to_rgb_preoffset->base.id : 0;
} else if (plane->funcs->atomic_get_property) {
return plane->funcs->atomic_get_property(plane, state,
property, val);
} else {
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index c3994b4..89fd826 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3196,6 +3196,12 @@ void __drm_atomic_helper_plane_duplicate_state(struct
drm_plane *plane,
{
memcpy(state, plane->state, sizeof(*state));
+ if (state->ycbcr_to_rgb_csc)
+ drm_property_blob_get(state->ycbcr_to_rgb_csc);
+
+ if (state->ycbcr_to_rgb_preoffset)
+ drm_property_blob_get(state->ycbcr_to_rgb_preoffset);
+
if (state->fb)
drm_framebuffer_get(state->fb);
@@ -3236,6 +3242,9 @@ struct drm_plane_state *
*/
void __drm_atomic_helper_plane_destroy_state(struct drm_plane_state *state)
{
+ drm_property_blob_put(state->ycbcr_to_rgb_csc);
+ drm_property_blob_put(state->ycbcr_to_rgb_preoffset);
+
if (state->fb)
drm_framebuffer_put(state->fb);
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index cc23b9a..badaddd 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -29,9 +29,14 @@
/**
* DOC: overview
*
- * Color management or color space adjustments is supported through a set of 5
- * properties on the &drm_crtc object. They are set up by calling
- * drm_crtc_enable_color_mgmt().
+ * Color management or color space adjustments in CRTCs is supported
+ * through a set of 5 properties on the &drm_crtc
[PATCH RFC 0/6] drm: Add properties to control YCbCr to RGB conversion
The series adds plane specific atomic properties to control YCbCr to RGB conversions. My intention was to try to implement the plane specific (before DEGAMMA) part of the suggestion in this dri-devel post: https://lists.freedesktop.org/archives/dri-devel/2017-March/135870.html This series may not be ready as such. At least the kernel doc parts should be more detailed and carefully written. The purpose is merely to move the discussion to a more concrete level. The series also includes drm/omap patches that implement the standard properties for OMAP DSS in omapdrm driver. Best regards, Jyri Jyri Sarha (4): drm: drm_color_mgmt.h needs struct drm_crtc declaration drm: Make drm_atomic_replace_property_blob_from_id() more generic drm: Plane YCbCr to RGB conversion related properties drm/omap: Enable ycbcr_to_rgb_properties for omapdrm planes REVISIT Tomi Valkeinen (2): drm/omap: cleanup color space conversion drm/omap: csc full range support drivers/gpu/drm/drm_atomic.c | 36 +++-- drivers/gpu/drm/drm_atomic_helper.c | 9 +++ drivers/gpu/drm/drm_color_mgmt.c | 136 +++- drivers/gpu/drm/drm_plane.c | 10 +++ drivers/gpu/drm/omapdrm/dss/dispc.c | 141 +- drivers/gpu/drm/omapdrm/dss/omapdss.h | 14 drivers/gpu/drm/omapdrm/omap_plane.c | 41 ++ include/drm/drm_color_mgmt.h | 25 ++ include/drm/drm_plane.h | 10 +++ include/uapi/drm/drm_mode.h | 12 +++ 10 files changed, 408 insertions(+), 26 deletions(-) -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RFC 6/6] drm/omap: Enable ycbcr_to_rgb_properties for omapdrm planes REVISIT
Adds support for YCBCR_TO_RGB_MODE and YCBCR_TO_RGB_CSC properties to
omap_plane.c and dispc.c. The supported CSC presets are:
- YCbCt BT.601 limited range to RGB BT.601 full range
- YCbCt BT.601 full range to RGB BT.601 full range
- YCbCt BT.709 limited range to RGB BT.709 full range
Custom CSC with YCbCr limited and full range preoffsets are
also supported.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 131 +++---
drivers/gpu/drm/omapdrm/dss/omapdss.h | 14
drivers/gpu/drm/omapdrm/omap_plane.c | 41 +++
3 files changed, 144 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index f2a2d08..48dfb9c 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -752,16 +752,6 @@ static void dispc_ovl_set_scale_coef(enum omap_plane_id
plane, int fir_hinc,
}
}
-struct csc_coef_yuv2rgb {
- int ry, rcb, rcr, gy, gcb, gcr, by, bcb, bcr;
- bool full_range;
-};
-
-struct csc_coef_rgb2yuv {
- int yr, yg, yb, cbr, cbg, cbb, crr, crg, crb;
- bool full_range;
-};
-
static void dispc_ovl_write_color_conv_coef(enum omap_plane_id plane,
const struct csc_coef_yuv2rgb *ct)
{
@@ -795,6 +785,54 @@ static void dispc_wb_write_color_conv_coef(const struct
csc_coef_rgb2yuv *ct)
#undef CVAL
}
+/* YUV -> RGB, ITU-R BT.601, full range */
+const static struct csc_coef_yuv2rgb coefs_yuv2rgb_bt601_full = {
+ 256, 0, 358, /* ry, rcb, rcr |1.000 0.000 1.402|*/
+ 256, -88, -182, /* gy, gcb, gcr |1.000 -0.344 -0.714|*/
+ 256, 452,0, /* by, bcb, bcr |1.000 1.772 0.000|*/
+ true, /* full range */
+};
+
+/* YUV -> RGB, ITU-R BT.601, limited range */
+const static struct csc_coef_yuv2rgb coefs_yuv2rgb_bt601_lim = {
+ 298,0, 409,/* ry, rcb, rcr |1.164 0.000 1.596|*/
+ 298, -100, -208,/* gy, gcb, gcr |1.164 -0.392 -0.813|*/
+ 298, 516,0,/* by, bcb, bcr |1.164 2.017 0.000|*/
+ false, /* limited range */
+};
+
+/* YUV -> RGB, ITU-R BT.709, limited range */
+const static struct csc_coef_yuv2rgb coefs_yuv2rgb_bt709_lim = {
+ 298,0, 459,/* ry, rcb, rcr |1.164 0.000 1.793|*/
+ 298, -55, -136,/* gy, gcb, gcr |1.164 -0.213 -0.533|*/
+ 298, 541,0,/* by, bcb, bcr |1.164 2.112 0.000|*/
+ false, /* limited range */
+};
+
+/* RGB -> YUV, ITU-R BT.601, limited range */
+const struct csc_coef_rgb2yuv coefs_rgb2yuv_bt601_lim = {
+66, 129, 25, /* yr, yg, yb | 0.257 0.504 0.098|*/
+ -38, -74, 112, /* cbr, cbg, cbb |-0.148 -0.291 0.439|*/
+ 112, -94, -18, /* crr, crg, crb | 0.439 -0.368 -0.071|*/
+ false, /* limited range */
+};
+
+/* RGB -> YUV, ITU-R BT.601, full range */
+const static struct csc_coef_rgb2yuv coefs_rgb2yuv_bt601_full = {
+77, 150, 29, /* yr, yg, yb | 0.299 0.587 0.114|*/
+ -43, -85, 128, /* cbr, cbg, cbb |-0.173 -0.339 0.511|*/
+ 128, -107, -21, /* crr, crg, crb | 0.511 -0.428 -0.083|*/
+ true, /* full range */
+};
+
+/* RGB -> YUV, ITU-R BT.709, limited range */
+const struct csc_coef_rgb2yuv coefs_rgb2yuv_bt701_lim = {
+47, 157, 16,/* yr, yg, yb | 0.1826 0.6142 0.0620|*/
+ -26, -87, 112,/* cbr, cbg, cbb |-0.1006 -0.3386 0.4392|*/
+ 112, -102, -10,/* crr, crg, crb | 0.4392 -0.3989 -0.0403|*/
+ false, /* limited range */
+};
+
static void dispc_setup_color_conv_coef(void)
{
int i;
@@ -802,38 +840,6 @@ static void dispc_setup_color_conv_coef(void)
/* always use full range for now */
bool use_full_range = true;
- /* YUV -> RGB, ITU-R BT.601, limited range */
- const struct csc_coef_yuv2rgb coefs_yuv2rgb_bt601_lim = {
- 298,0, 409,/* ry, rcb, rcr */
- 298, -100, -208,/* gy, gcb, gcr */
- 298, 516,0,/* by, bcb, bcr */
- false, /* limited range */
- };
-
- /* YUV -> RGB, ITU-R BT.601, full range */
- const struct csc_coef_yuv2rgb coefs_yuv2rgb_bt601_full = {
- 256, 0, 358, /* ry, rcb, rcr */
- 256, -88, -182, /* gy, gcb, gcr */
- 256, 452,0, /* by, bcb, bcr */
- true, /* full range */
- };
-
- /* RGB -> YUV, ITU-R BT.601, limited range */
- const struct csc_coef_rgb2yuv coefs_rgb2yuv_bt601_lim = {
-66, 129, 25, /* yr, yg, yb */
- -38, -74, 112, /* cbr, cbg, cbb */
- 112, -94, -18, /* crr, crg, crb */
-
[PATCH RFC 2/6] drm: Make drm_atomic_replace_property_blob_from_id() more generic
Change drm_atomic_replace_property_blob_from_id()'s first parameter
from drm_crtc to drm_device, so that the function can be used for other
drm_mode_objects too.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/drm_atomic.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 9b892af..f881319 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -425,7 +425,7 @@ int drm_atomic_set_mode_prop_for_crtc(struct drm_crtc_state
*state,
}
static int
-drm_atomic_replace_property_blob_from_id(struct drm_crtc *crtc,
+drm_atomic_replace_property_blob_from_id(struct drm_device *dev,
struct drm_property_blob **blob,
uint64_t blob_id,
ssize_t expected_size,
@@ -434,7 +434,7 @@ int drm_atomic_set_mode_prop_for_crtc(struct drm_crtc_state
*state,
struct drm_property_blob *new_blob = NULL;
if (blob_id != 0) {
- new_blob = drm_property_lookup_blob(crtc->dev, blob_id);
+ new_blob = drm_property_lookup_blob(dev, blob_id);
if (new_blob == NULL)
return -EINVAL;
@@ -483,7 +483,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
drm_property_blob_put(mode);
return ret;
} else if (property == config->degamma_lut_property) {
- ret = drm_atomic_replace_property_blob_from_id(crtc,
+ ret = drm_atomic_replace_property_blob_from_id(dev,
&state->degamma_lut,
val,
-1,
@@ -491,7 +491,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
state->color_mgmt_changed |= replaced;
return ret;
} else if (property == config->ctm_property) {
- ret = drm_atomic_replace_property_blob_from_id(crtc,
+ ret = drm_atomic_replace_property_blob_from_id(dev,
&state->ctm,
val,
sizeof(struct drm_color_ctm),
@@ -499,7 +499,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
state->color_mgmt_changed |= replaced;
return ret;
} else if (property == config->gamma_lut_property) {
- ret = drm_atomic_replace_property_blob_from_id(crtc,
+ ret = drm_atomic_replace_property_blob_from_id(dev,
&state->gamma_lut,
val,
-1,
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RFC 5/6] drm/omap: csc full range support
From: Tomi Valkeinen
At the moment the driver always uses limited range when doing YUV-RGB
conversions. This patch adds full-range tables, and makes the code to
always use full-range tables.
In the future we should allow the user to select the color range instead
of hardcoding it.
Signed-off-by: Tomi Valkeinen
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 33 +++--
1 file changed, 31 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index b53e63d..f2a2d08 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -799,6 +799,8 @@ static void dispc_setup_color_conv_coef(void)
{
int i;
int num_ovl = dss_feat_get_num_ovls();
+ /* always use full range for now */
+ bool use_full_range = true;
/* YUV -> RGB, ITU-R BT.601, limited range */
const struct csc_coef_yuv2rgb coefs_yuv2rgb_bt601_lim = {
@@ -808,6 +810,14 @@ static void dispc_setup_color_conv_coef(void)
false, /* limited range */
};
+ /* YUV -> RGB, ITU-R BT.601, full range */
+ const struct csc_coef_yuv2rgb coefs_yuv2rgb_bt601_full = {
+ 256, 0, 358, /* ry, rcb, rcr */
+ 256, -88, -182, /* gy, gcb, gcr */
+ 256, 452,0, /* by, bcb, bcr */
+ true, /* full range */
+ };
+
/* RGB -> YUV, ITU-R BT.601, limited range */
const struct csc_coef_rgb2yuv coefs_rgb2yuv_bt601_lim = {
66, 129, 25, /* yr, yg, yb */
@@ -816,11 +826,30 @@ static void dispc_setup_color_conv_coef(void)
false, /* limited range */
};
+ /* RGB -> YUV, ITU-R BT.601, full range */
+ const struct csc_coef_rgb2yuv coefs_rgb2yuv_bt601_full = {
+77, 150, 29, /* yr, yg, yb */
+ -43, -85, 128, /* cbr, cbg, cbb */
+ 128, -107, -21, /* crr, crg, crb */
+ true, /* full range */
+ };
+
+ const struct csc_coef_yuv2rgb *yuv2rgb;
+ const struct csc_coef_rgb2yuv *rgb2yuv;
+
+ if (use_full_range) {
+ yuv2rgb = &coefs_yuv2rgb_bt601_full;
+ rgb2yuv = &coefs_rgb2yuv_bt601_full;
+ } else {
+ yuv2rgb = &coefs_yuv2rgb_bt601_lim;
+ rgb2yuv = &coefs_rgb2yuv_bt601_lim;
+ }
+
for (i = 1; i < num_ovl; i++)
- dispc_ovl_write_color_conv_coef(i, &coefs_yuv2rgb_bt601_lim);
+ dispc_ovl_write_color_conv_coef(i, yuv2rgb);
if (dispc.feat->has_writeback)
- dispc_wb_write_color_conv_coef(&coefs_rgb2yuv_bt601_lim);
+ dispc_wb_write_color_conv_coef(rgb2yuv);
}
static void dispc_ovl_set_ba0(enum omap_plane_id plane, u32 paddr)
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RFC 1/6] drm: drm_color_mgmt.h needs struct drm_crtc declaration
Signed-off-by: Jyri Sarha --- include/drm/drm_color_mgmt.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h index bce4a53..03a59cb 100644 --- a/include/drm/drm_color_mgmt.h +++ b/include/drm/drm_color_mgmt.h @@ -25,6 +25,8 @@ #include +struct drm_crtc; + uint32_t drm_color_lut_extract(uint32_t user_input, uint32_t bit_precision); void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc, -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RFC 4/6] drm/omap: cleanup color space conversion
From: Tomi Valkeinen
The setup code for color space conversion is a bit messy. This patch
cleans it up.
For some reason the TRM uses values in YCrCb order, which is also used
in the current driver, whereas everywhere else it's YCbCr (which also
matches YUV order). This patch changes the tables to use the common
order to avoid confusion.
The tables are split into separate lines, and comments added for
clarity.
WB color conversion registers are similar but different than non-WB, but
the same function was used to write both. It worked fine because the
coef table was adjusted accordingly, but that was rather confusing. This
patch adds a separate function to write the WB values so that the coef
table can be written in an understandable way.
Signed-off-by: Tomi Valkeinen
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 59 +++--
1 file changed, 44 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index 5ac0145..b53e63d 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -293,11 +293,6 @@ struct dispc_gamma_desc {
},
};
-struct color_conv_coef {
- int ry, rcr, rcb, gy, gcr, gcb, by, bcr, bcb;
- int full_range;
-};
-
static unsigned long dispc_fclk_rate(void);
static unsigned long dispc_core_clk_rate(void);
static unsigned long dispc_mgr_lclk_rate(enum omap_channel channel);
@@ -757,9 +752,18 @@ static void dispc_ovl_set_scale_coef(enum omap_plane_id
plane, int fir_hinc,
}
}
+struct csc_coef_yuv2rgb {
+ int ry, rcb, rcr, gy, gcb, gcr, by, bcb, bcr;
+ bool full_range;
+};
+
+struct csc_coef_rgb2yuv {
+ int yr, yg, yb, cbr, cbg, cbb, crr, crg, crb;
+ bool full_range;
+};
static void dispc_ovl_write_color_conv_coef(enum omap_plane_id plane,
- const struct color_conv_coef *ct)
+ const struct csc_coef_yuv2rgb *ct)
{
#define CVAL(x, y) (FLD_VAL(x, 26, 16) | FLD_VAL(y, 10, 0))
@@ -769,7 +773,24 @@ static void dispc_ovl_write_color_conv_coef(enum
omap_plane_id plane,
dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 3), CVAL(ct->bcr, ct->by));
dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 4), CVAL(0, ct->bcb));
- REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), ct->full_range, 11, 11);
+ REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), !!ct->full_range, 11, 11);
+
+#undef CVAL
+}
+
+static void dispc_wb_write_color_conv_coef(const struct csc_coef_rgb2yuv *ct)
+{
+ const enum omap_plane_id plane = OMAP_DSS_WB;
+
+#define CVAL(x, y) (FLD_VAL(x, 26, 16) | FLD_VAL(y, 10, 0))
+
+ dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 0), CVAL(ct->yg, ct->yr));
+ dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 1), CVAL(ct->crr, ct->yb));
+ dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 2), CVAL(ct->crb, ct->crg));
+ dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 3), CVAL(ct->cbg, ct->cbr));
+ dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 4), CVAL(0, ct->cbb));
+
+ REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), !!ct->full_range, 11, 11);
#undef CVAL
}
@@ -778,20 +799,28 @@ static void dispc_setup_color_conv_coef(void)
{
int i;
int num_ovl = dss_feat_get_num_ovls();
- const struct color_conv_coef ctbl_bt601_5_ovl = {
- /* YUV -> RGB */
- 298, 409, 0, 298, -208, -100, 298, 0, 517, 0,
+
+ /* YUV -> RGB, ITU-R BT.601, limited range */
+ const struct csc_coef_yuv2rgb coefs_yuv2rgb_bt601_lim = {
+ 298,0, 409,/* ry, rcb, rcr */
+ 298, -100, -208,/* gy, gcb, gcr */
+ 298, 516,0,/* by, bcb, bcr */
+ false, /* limited range */
};
- const struct color_conv_coef ctbl_bt601_5_wb = {
- /* RGB -> YUV */
- 66, 129, 25, 112, -94, -18, -38, -74, 112, 0,
+
+ /* RGB -> YUV, ITU-R BT.601, limited range */
+ const struct csc_coef_rgb2yuv coefs_rgb2yuv_bt601_lim = {
+66, 129, 25, /* yr, yg, yb */
+ -38, -74, 112, /* cbr, cbg, cbb */
+ 112, -94, -18, /* crr, crg, crb */
+ false, /* limited range */
};
for (i = 1; i < num_ovl; i++)
- dispc_ovl_write_color_conv_coef(i, &ctbl_bt601_5_ovl);
+ dispc_ovl_write_color_conv_coef(i, &coefs_yuv2rgb_bt601_lim);
if (dispc.feat->has_writeback)
- dispc_ovl_write_color_conv_coef(OMAP_DSS_WB, &ctbl_bt601_5_wb);
+ dispc_wb_write_color_conv_coef(&coefs_rgb2yuv_bt601_lim);
}
static void dispc_ovl_set_ba0(enum omap_plane_id plane, u32 paddr)
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/mediatek: fix a timeout loop
This code causes a static checker warning because it treats "i == 0" as
a timeout but, because it's a post-op, the loop actually ends with "i"
set to -1. Philipp Zabel points out that it would be cleaner to use
readl_poll_timeout() instead.
Fixes: 21898816831f ("drm/mediatek: add dsi transfer function")
Signed-off-by: Dan Carpenter
---
v2: Use readl_poll_timeout(). Please review this carefully because I've
never used readl_poll_timeout() and could easily mess up.
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 808b995a990f..b5cc6e12334c 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -900,16 +901,12 @@ static int mtk_dsi_host_detach(struct mipi_dsi_host *host,
static void mtk_dsi_wait_for_idle(struct mtk_dsi *dsi)
{
- u32 timeout_ms = 50; /* total 1s ~ 2s timeout */
-
- while (timeout_ms--) {
- if (!(readl(dsi->regs + DSI_INTSTA) & DSI_BUSY))
- break;
-
- usleep_range(2, 4);
- }
+ int ret;
+ u32 val;
- if (timeout_ms == 0) {
+ ret = readl_poll_timeout(dsi->regs + DSI_INTSTA, val, !(val & DSI_BUSY),
+4, 200);
+ if (ret) {
DRM_WARN("polling dsi wait not busy timeout!\n");
mtk_dsi_enable(dsi);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.
On Fri, Apr 21, 2017 at 11:50:18AM +0200, Gerd Hoffmann wrote: > On Fr, 2017-04-21 at 12:25 +0300, Ville Syrjälä wrote: > > On Fri, Apr 21, 2017 at 09:58:24AM +0200, Gerd Hoffmann wrote: > > > While working on graphics support for virtual machines on ppc64 (which > > > exists in both little and big endian variants) I've figured the comments > > > for various drm fourcc formats in the header file don't match reality. > > > > > > Comments says the RGB formats are little endian, but in practice they > > > are native endian. Look at the drm_mode_legacy_fb_format() helper. It > > > maps -- for example -- bpp/depth 32/24 to DRM_FORMAT_XRGB, no matter > > > whenever the machine is little endian or big endian. The users of this > > > function (fbdev emulation, DRM_IOCTL_MODE_ADDFB) expect the framebuffer > > > is native endian, not little endian. Most userspace also operates on > > > native endian only. > > > > I'm not a fan of "native". Native to what? "CPU" or "host" is what I'd > > call it. > > native == whatever the cpu is using. > > I personally find "native" more intuitive, but at the end of the day I > don't mind much. If people prefer "host" over "native" I'll change it. > > > And what about the mxied endian case? Are you just going to pretend it > > doesn't exist or what? > > What exactly do you mean with "mixed endian"? The powerpc case, where > kernel + userspace can run in either big or little endian mode? Or > something else? Big endian CPU and little endian GPU. I think that should be the most common case these days. -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.
On Fri, Apr 21, 2017 at 11:50:18AM +0200, Gerd Hoffmann wrote: > On Fr, 2017-04-21 at 12:25 +0300, Ville Syrjälä wrote: > > On Fri, Apr 21, 2017 at 09:58:24AM +0200, Gerd Hoffmann wrote: > > > While working on graphics support for virtual machines on ppc64 (which > > > exists in both little and big endian variants) I've figured the comments > > > for various drm fourcc formats in the header file don't match reality. > > > > > > Comments says the RGB formats are little endian, but in practice they > > > are native endian. Look at the drm_mode_legacy_fb_format() helper. It > > > maps -- for example -- bpp/depth 32/24 to DRM_FORMAT_XRGB, no matter > > > whenever the machine is little endian or big endian. The users of this > > > function (fbdev emulation, DRM_IOCTL_MODE_ADDFB) expect the framebuffer > > > is native endian, not little endian. Most userspace also operates on > > > native endian only. > > > > I'm not a fan of "native". Native to what? "CPU" or "host" is what I'd > > call it. > > native == whatever the cpu is using. > > I personally find "native" more intuitive, but at the end of the day I > don't mind much. If people prefer "host" over "native" I'll change it. "native" to me feels more like "native to the GPU" since these things really are tied to the GPU not the CPU. That's also why I went with the explicit endianness originally so that the driver could properly declare what the GPU supports. -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC 3/6] drm: Plane YCbCr to RGB conversion related properties
On Fri, Apr 21, 2017 at 12:51:14PM +0300, Jyri Sarha wrote:
> Add standard properties to control YCbCr to RGB conversion in DRM
> planes. The created properties are stored to drm_plane object to allow
> different set of supported conversion modes for different planes on
> the device. For simplicity the related property blobs for CSC matrix
> and YCbCr preoffsets are also stored in the same place. The blob
> contents are defined in the uapi/drm/drm_mode.h header.
>
> Signed-off-by: Jyri Sarha
> ---
> drivers/gpu/drm/drm_atomic.c| 26 +++
> drivers/gpu/drm/drm_atomic_helper.c | 9 +++
> drivers/gpu/drm/drm_color_mgmt.c| 136
> +++-
> drivers/gpu/drm/drm_plane.c | 10 +++
> include/drm/drm_color_mgmt.h| 23 ++
> include/drm/drm_plane.h | 10 +++
> include/uapi/drm/drm_mode.h | 12
> 7 files changed, 223 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index f881319..d1512aa 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -732,6 +732,8 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
> {
> struct drm_device *dev = plane->dev;
> struct drm_mode_config *config = &dev->mode_config;
> + int ret;
> + bool dummy;
>
> if (property == config->prop_fb_id) {
> struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, val);
> @@ -774,6 +776,22 @@ int drm_atomic_plane_set_property(struct drm_plane
> *plane,
> state->rotation = val;
> } else if (property == plane->zpos_property) {
> state->zpos = val;
> + } else if (property == plane->ycbcr_to_rgb_mode_property) {
> + state->ycbcr_to_rgb_mode = val;
> + } else if (property == plane->ycbcr_to_rgb_csc_property) {
> + ret = drm_atomic_replace_property_blob_from_id(dev,
> + &state->ycbcr_to_rgb_csc,
> + val,
> + sizeof(struct drm_ycbcr_to_rgb_csc),
> + &dummy);
> + return ret;
> + } else if (property == plane->ycbcr_to_rgb_preoffset_property) {
> + ret = drm_atomic_replace_property_blob_from_id(dev,
> + &state->ycbcr_to_rgb_preoffset,
> + val,
> + sizeof(struct drm_ycbcr_to_rgb_preoffset),
> + &dummy);
> + return ret;
> } else if (plane->funcs->atomic_set_property) {
> return plane->funcs->atomic_set_property(plane, state,
> property, val);
> @@ -834,6 +852,14 @@ int drm_atomic_plane_set_property(struct drm_plane
> *plane,
> *val = state->rotation;
> } else if (property == plane->zpos_property) {
> *val = state->zpos;
> + } else if (property == plane->ycbcr_to_rgb_mode_property) {
> + *val = state->ycbcr_to_rgb_mode;
> + } else if (property == plane->ycbcr_to_rgb_csc_property) {
> + *val = state->ycbcr_to_rgb_csc ?
> + state->ycbcr_to_rgb_csc->base.id : 0;
> + } else if (property == plane->ycbcr_to_rgb_preoffset_property) {
> + *val = state->ycbcr_to_rgb_preoffset ?
> + state->ycbcr_to_rgb_preoffset->base.id : 0;
> } else if (plane->funcs->atomic_get_property) {
> return plane->funcs->atomic_get_property(plane, state,
> property, val);
> } else {
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index c3994b4..89fd826 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3196,6 +3196,12 @@ void __drm_atomic_helper_plane_duplicate_state(struct
> drm_plane *plane,
> {
> memcpy(state, plane->state, sizeof(*state));
>
> + if (state->ycbcr_to_rgb_csc)
> + drm_property_blob_get(state->ycbcr_to_rgb_csc);
> +
> + if (state->ycbcr_to_rgb_preoffset)
> + drm_property_blob_get(state->ycbcr_to_rgb_preoffset);
> +
> if (state->fb)
> drm_framebuffer_get(state->fb);
>
> @@ -3236,6 +3242,9 @@ struct drm_plane_state *
> */
> void __drm_atomic_helper_plane_destroy_state(struct drm_plane_state *state)
> {
> + drm_property_blob_put(state->ycbcr_to_rgb_csc);
> + drm_property_blob_put(state->ycbcr_to_rgb_preoffset);
> +
> if (state->fb)
> drm_framebuffer_put(state->fb);
>
> diff --git a/drivers/gpu/drm/drm_color_mgmt.c
> b/drivers/gpu/drm/drm_color_mgmt.c
> index cc23b9a..badaddd 100644
> --- a/drivers/gpu/drm/drm_color_mgmt.c
> +++ b/drivers/gpu/drm/drm_color_mgmt.c
> @@ -29,9 +29,14 @@
> /**
> * DOC: overview
> *
> - * Color management or color space adjustments is supported through a set of
> 5
> - * properties on the &drm_crtc ob
Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.
On Fri, 21 Apr 2017 14:08:04 +0300 Ville Syrjälä wrote: > On Fri, Apr 21, 2017 at 11:50:18AM +0200, Gerd Hoffmann wrote: > > On Fr, 2017-04-21 at 12:25 +0300, Ville Syrjälä wrote: > > > On Fri, Apr 21, 2017 at 09:58:24AM +0200, Gerd Hoffmann wrote: > > > > While working on graphics support for virtual machines on ppc64 (which > > > > exists in both little and big endian variants) I've figured the comments > > > > for various drm fourcc formats in the header file don't match reality. > > > > > > > > Comments says the RGB formats are little endian, but in practice they > > > > are native endian. Look at the drm_mode_legacy_fb_format() helper. It > > > > maps -- for example -- bpp/depth 32/24 to DRM_FORMAT_XRGB, no matter > > > > whenever the machine is little endian or big endian. The users of this > > > > function (fbdev emulation, DRM_IOCTL_MODE_ADDFB) expect the framebuffer > > > > is native endian, not little endian. Most userspace also operates on > > > > native endian only. > > > > > > I'm not a fan of "native". Native to what? "CPU" or "host" is what I'd > > > call it. > > > > native == whatever the cpu is using. > > > > I personally find "native" more intuitive, but at the end of the day I > > don't mind much. If people prefer "host" over "native" I'll change it. > > "native" to me feels more like "native to the GPU" since these things > really are tied to the GPU not the CPU. That's also why I went with the > explicit endianness originally so that the driver could properly declare > what the GPU supports. Hi, yeah, one should really be explicit on which component's endianess does "native" refer to. I just can't imagine "GPU native" to ever be an option, because then userspace needs a way to discover what the GPU endianess is, and I believe that would only deepen the swamp, not drain it, because suddenly you need two enums to describe one format. Ville, wording aside, what do think about changing the endianess definition? Is it going in the right direction? Thanks, pq pgpTVR4Lrl90N.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.
Hi, > > I personally find "native" more intuitive, but at the end of the day I > > don't mind much. If people prefer "host" over "native" I'll change it. > > "native" to me feels more like "native to the GPU" since these things > really are tied to the GPU not the CPU. Ok, then maybe "host" is the better term then, to make clear we talk about cpu/kernel/userspace byteorder here. cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC 1/6] drm: drm_color_mgmt.h needs struct drm_crtc declaration
Hi Jyri, Thank you for the patch On Friday 21 Apr 2017 12:51:12 Jyri Sarha wrote: No commit message ? > Signed-off-by: Jyri Sarha Apart from that, Reviewed-by: Laurent Pinchart > --- > include/drm/drm_color_mgmt.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h > index bce4a53..03a59cb 100644 > --- a/include/drm/drm_color_mgmt.h > +++ b/include/drm/drm_color_mgmt.h > @@ -25,6 +25,8 @@ > > #include > > +struct drm_crtc; > + > uint32_t drm_color_lut_extract(uint32_t user_input, uint32_t > bit_precision); > > void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc, -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC 2/6] drm: Make drm_atomic_replace_property_blob_from_id() more generic
Hi Jyri,
Thank you for the patch.
On Friday 21 Apr 2017 12:51:13 Jyri Sarha wrote:
> Change drm_atomic_replace_property_blob_from_id()'s first parameter
> from drm_crtc to drm_device, so that the function can be used for other
> drm_mode_objects too.
>
> Signed-off-by: Jyri Sarha
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/drm_atomic.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 9b892af..f881319 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -425,7 +425,7 @@ int drm_atomic_set_mode_prop_for_crtc(struct
> drm_crtc_state *state, }
>
> static int
> -drm_atomic_replace_property_blob_from_id(struct drm_crtc *crtc,
> +drm_atomic_replace_property_blob_from_id(struct drm_device *dev,
>struct drm_property_blob **blob,
>uint64_t blob_id,
>ssize_t expected_size,
> @@ -434,7 +434,7 @@ int drm_atomic_set_mode_prop_for_crtc(struct
> drm_crtc_state *state, struct drm_property_blob *new_blob = NULL;
>
> if (blob_id != 0) {
> - new_blob = drm_property_lookup_blob(crtc->dev, blob_id);
> + new_blob = drm_property_lookup_blob(dev, blob_id);
> if (new_blob == NULL)
> return -EINVAL;
>
> @@ -483,7 +483,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
> drm_property_blob_put(mode);
> return ret;
> } else if (property == config->degamma_lut_property) {
> - ret = drm_atomic_replace_property_blob_from_id(crtc,
> + ret = drm_atomic_replace_property_blob_from_id(dev,
> &state->degamma_lut,
> val,
> -1,
> @@ -491,7 +491,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
> state->color_mgmt_changed |= replaced;
> return ret;
> } else if (property == config->ctm_property) {
> - ret = drm_atomic_replace_property_blob_from_id(crtc,
> + ret = drm_atomic_replace_property_blob_from_id(dev,
> &state->ctm,
> val,
> sizeof(struct drm_color_ctm),
> @@ -499,7 +499,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
> state->color_mgmt_changed |= replaced;
> return ret;
> } else if (property == config->gamma_lut_property) {
> - ret = drm_atomic_replace_property_blob_from_id(crtc,
> + ret = drm_atomic_replace_property_blob_from_id(dev,
> &state->gamma_lut,
> val,
> -1,
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100058] amdgpu/dpm: NULL pointer dereference
https://bugs.freedesktop.org/show_bug.cgi?id=100058 --- Comment #12 from Edward O'Callaghan --- @Alex Deucher I confirmed with Adam that, even with c10c8f7 he still has the null pointer issue. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.
On Fri, Apr 21, 2017 at 02:40:18PM +0300, Pekka Paalanen wrote: > On Fri, 21 Apr 2017 14:08:04 +0300 > Ville Syrjälä wrote: > > > On Fri, Apr 21, 2017 at 11:50:18AM +0200, Gerd Hoffmann wrote: > > > On Fr, 2017-04-21 at 12:25 +0300, Ville Syrjälä wrote: > > > > On Fri, Apr 21, 2017 at 09:58:24AM +0200, Gerd Hoffmann wrote: > > > > > While working on graphics support for virtual machines on ppc64 (which > > > > > exists in both little and big endian variants) I've figured the > > > > > comments > > > > > for various drm fourcc formats in the header file don't match reality. > > > > > > > > > > Comments says the RGB formats are little endian, but in practice they > > > > > are native endian. Look at the drm_mode_legacy_fb_format() helper. > > > > > It > > > > > maps -- for example -- bpp/depth 32/24 to DRM_FORMAT_XRGB, no > > > > > matter > > > > > whenever the machine is little endian or big endian. The users of > > > > > this > > > > > function (fbdev emulation, DRM_IOCTL_MODE_ADDFB) expect the > > > > > framebuffer > > > > > is native endian, not little endian. Most userspace also operates on > > > > > native endian only. > > > > > > > > I'm not a fan of "native". Native to what? "CPU" or "host" is what I'd > > > > call it. > > > > > > native == whatever the cpu is using. > > > > > > I personally find "native" more intuitive, but at the end of the day I > > > don't mind much. If people prefer "host" over "native" I'll change it. > > > > "native" to me feels more like "native to the GPU" since these things > > really are tied to the GPU not the CPU. That's also why I went with the > > explicit endianness originally so that the driver could properly declare > > what the GPU supports. > > Hi, > > yeah, one should really be explicit on which component's endianess does > "native" refer to. I just can't imagine "GPU native" to ever be an > option, because then userspace needs a way to discover what the > GPU endianess is, It has to know that. How else would it know how to write the bytes into memory in the right order for the GPU to consume, or read the stuff the GPU produced? > and I believe that would only deepen the swamp, not > drain it, because suddenly you need two enums to describe one format. > > Ville, wording aside, what do think about changing the endianess > definition? Is it going in the right direction? I don't think so, but I guess I'm in the minority. -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC 4/6] drm/omap: cleanup color space conversion
Hi Jyri,
Thank you for the patch.
On Friday 21 Apr 2017 12:51:15 Jyri Sarha wrote:
> From: Tomi Valkeinen
>
> The setup code for color space conversion is a bit messy. This patch
> cleans it up.
>
> For some reason the TRM uses values in YCrCb order, which is also used
> in the current driver, whereas everywhere else it's YCbCr (which also
> matches YUV order). This patch changes the tables to use the common
> order to avoid confusion.
>
> The tables are split into separate lines, and comments added for
> clarity.
>
> WB color conversion registers are similar but different than non-WB, but
> the same function was used to write both. It worked fine because the
> coef table was adjusted accordingly, but that was rather confusing. This
> patch adds a separate function to write the WB values so that the coef
> table can be written in an understandable way.
That's quite a few changes for a single patch. I might have split the last one
in a separate patch.
> Signed-off-by: Tomi Valkeinen
> Signed-off-by: Jyri Sarha
> ---
> drivers/gpu/drm/omapdrm/dss/dispc.c | 59 +++--
> 1 file changed, 44 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
> b/drivers/gpu/drm/omapdrm/dss/dispc.c index 5ac0145..b53e63d 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dispc.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
> @@ -293,11 +293,6 @@ struct dispc_gamma_desc {
> },
> };
>
> -struct color_conv_coef {
> - int ry, rcr, rcb, gy, gcr, gcb, by, bcr, bcb;
> - int full_range;
> -};
> -
> static unsigned long dispc_fclk_rate(void);
> static unsigned long dispc_core_clk_rate(void);
> static unsigned long dispc_mgr_lclk_rate(enum omap_channel channel);
> @@ -757,9 +752,18 @@ static void dispc_ovl_set_scale_coef(enum omap_plane_id
> plane, int fir_hinc, }
> }
>
> +struct csc_coef_yuv2rgb {
> + int ry, rcb, rcr, gy, gcb, gcr, by, bcb, bcr;
> + bool full_range;
> +};
> +
> +struct csc_coef_rgb2yuv {
> + int yr, yg, yb, cbr, cbg, cbb, crr, crg, crb;
> + bool full_range;
> +};
>
> static void dispc_ovl_write_color_conv_coef(enum omap_plane_id plane,
> - const struct color_conv_coef *ct)
> + const struct csc_coef_yuv2rgb *ct)
> {
> #define CVAL(x, y) (FLD_VAL(x, 26, 16) | FLD_VAL(y, 10, 0))
>
> @@ -769,7 +773,24 @@ static void dispc_ovl_write_color_conv_coef(enum
> omap_plane_id plane, dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 3),
> CVAL(ct->bcr, ct->by)); dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 4),
> CVAL(0, ct->bcb));
>
> - REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), ct->full_range, 11, 11);
> + REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), !!ct->full_range, 11, 11);
> +
> +#undef CVAL
> +}
> +
> +static void dispc_wb_write_color_conv_coef(const struct csc_coef_rgb2yuv
> *ct) +{
> + const enum omap_plane_id plane = OMAP_DSS_WB;
> +
> +#define CVAL(x, y) (FLD_VAL(x, 26, 16) | FLD_VAL(y, 10, 0))
> +
> + dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 0), CVAL(ct->yg, ct->yr));
> + dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 1), CVAL(ct->crr, ct->yb));
> + dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 2), CVAL(ct->crb, ct-
>crg));
> + dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 3), CVAL(ct->cbg, ct-
>cbr));
> + dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 4), CVAL(0, ct->cbb));
> +
> + REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), !!ct->full_range, 11, 11);
>
> #undef CVAL
> }
> @@ -778,20 +799,28 @@ static void dispc_setup_color_conv_coef(void)
> {
> int i;
> int num_ovl = dss_feat_get_num_ovls();
> - const struct color_conv_coef ctbl_bt601_5_ovl = {
> - /* YUV -> RGB */
> - 298, 409, 0, 298, -208, -100, 298, 0, 517, 0,
> +
> + /* YUV -> RGB, ITU-R BT.601, limited range */
> + const struct csc_coef_yuv2rgb coefs_yuv2rgb_bt601_lim = {
> + 298,0, 409,/* ry, rcb, rcr */
> + 298, -100, -208,/* gy, gcb, gcr */
> + 298, 516,0,/* by, bcb, bcr */
You changed 517 to 516, was it intentional ? The commit message doesn't
mention that modification.
> + false, /* limited range */
> };
> - const struct color_conv_coef ctbl_bt601_5_wb = {
> - /* RGB -> YUV */
> - 66, 129, 25, 112, -94, -18, -38, -74, 112, 0,
> +
> + /* RGB -> YUV, ITU-R BT.601, limited range */
> + const struct csc_coef_rgb2yuv coefs_rgb2yuv_bt601_lim = {
> + 66, 129, 25, /* yr, yg, yb */
> + -38, -74, 112, /* cbr, cbg, cbb */
> + 112, -94, -18, /* crr, crg, crb */
> + false, /* limited range */
> };
>
> for (i = 1; i < num_ovl; i++)
> - dispc_ovl_write_color_conv_coef(i, &ctbl_bt601_5_ovl);
> + dispc_ovl_write_color_conv_coef(i, &coefs_yuv2rgb_bt601_lim);
>
> if (dispc.feat->has_writeback)
> - di
Re: [PATCH RFC 5/6] drm/omap: csc full range support
Hi Jyri,
Thank you for the patch.
On Friday 21 Apr 2017 12:51:16 Jyri Sarha wrote:
> From: Tomi Valkeinen
>
> At the moment the driver always uses limited range when doing YUV-RGB
> conversions. This patch adds full-range tables, and makes the code to
> always use full-range tables.
>
> In the future we should allow the user to select the color range instead
> of hardcoding it.
>
> Signed-off-by: Tomi Valkeinen
> Signed-off-by: Jyri Sarha
> ---
> drivers/gpu/drm/omapdrm/dss/dispc.c | 33 +++--
> 1 file changed, 31 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
> b/drivers/gpu/drm/omapdrm/dss/dispc.c index b53e63d..f2a2d08 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dispc.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
> @@ -799,6 +799,8 @@ static void dispc_setup_color_conv_coef(void)
> {
> int i;
> int num_ovl = dss_feat_get_num_ovls();
> + /* always use full range for now */
> + bool use_full_range = true;
>
> /* YUV -> RGB, ITU-R BT.601, limited range */
> const struct csc_coef_yuv2rgb coefs_yuv2rgb_bt601_lim = {
> @@ -808,6 +810,14 @@ static void dispc_setup_color_conv_coef(void)
> false, /* limited range */
> };
>
> + /* YUV -> RGB, ITU-R BT.601, full range */
> + const struct csc_coef_yuv2rgb coefs_yuv2rgb_bt601_full = {
> + 256, 0, 358, /* ry, rcb, rcr */
> + 256, -88, -182, /* gy, gcb, gcr */
> + 256, 452,0, /* by, bcb, bcr */
> + true, /* full range */
> + };
Shouldn't all those tables be static const ?
With that fixed,
Reviewed-by: Laurent Pinchart
> +
> /* RGB -> YUV, ITU-R BT.601, limited range */
> const struct csc_coef_rgb2yuv coefs_rgb2yuv_bt601_lim = {
>66, 129, 25, /* yr, yg, yb */
> @@ -816,11 +826,30 @@ static void dispc_setup_color_conv_coef(void)
> false, /* limited range */
> };
>
> + /* RGB -> YUV, ITU-R BT.601, full range */
> + const struct csc_coef_rgb2yuv coefs_rgb2yuv_bt601_full = {
> + 77, 150, 29, /* yr, yg, yb */
> + -43, -85, 128, /* cbr, cbg, cbb */
> + 128, -107, -21, /* crr, crg, crb */
> + true, /* full range */
> + };
> +
> + const struct csc_coef_yuv2rgb *yuv2rgb;
> + const struct csc_coef_rgb2yuv *rgb2yuv;
> +
> + if (use_full_range) {
> + yuv2rgb = &coefs_yuv2rgb_bt601_full;
> + rgb2yuv = &coefs_rgb2yuv_bt601_full;
> + } else {
> + yuv2rgb = &coefs_yuv2rgb_bt601_lim;
> + rgb2yuv = &coefs_rgb2yuv_bt601_lim;
> + }
> +
> for (i = 1; i < num_ovl; i++)
> - dispc_ovl_write_color_conv_coef(i, &coefs_yuv2rgb_bt601_lim);
> + dispc_ovl_write_color_conv_coef(i, yuv2rgb);
>
> if (dispc.feat->has_writeback)
> - dispc_wb_write_color_conv_coef(&coefs_rgb2yuv_bt601_lim);
> + dispc_wb_write_color_conv_coef(rgb2yuv);
> }
>
> static void dispc_ovl_set_ba0(enum omap_plane_id plane, u32 paddr)
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.
Am 21.04.2017 um 13:08 schrieb Ville Syrjälä: On Fri, Apr 21, 2017 at 11:50:18AM +0200, Gerd Hoffmann wrote: On Fr, 2017-04-21 at 12:25 +0300, Ville Syrjälä wrote: On Fri, Apr 21, 2017 at 09:58:24AM +0200, Gerd Hoffmann wrote: While working on graphics support for virtual machines on ppc64 (which exists in both little and big endian variants) I've figured the comments for various drm fourcc formats in the header file don't match reality. Comments says the RGB formats are little endian, but in practice they are native endian. Look at the drm_mode_legacy_fb_format() helper. It maps -- for example -- bpp/depth 32/24 to DRM_FORMAT_XRGB, no matter whenever the machine is little endian or big endian. The users of this function (fbdev emulation, DRM_IOCTL_MODE_ADDFB) expect the framebuffer is native endian, not little endian. Most userspace also operates on native endian only. I'm not a fan of "native". Native to what? "CPU" or "host" is what I'd call it. native == whatever the cpu is using. I personally find "native" more intuitive, but at the end of the day I don't mind much. If people prefer "host" over "native" I'll change it. "native" to me feels more like "native to the GPU" since these things really are tied to the GPU not the CPU. That's also why I went with the explicit endianness originally so that the driver could properly declare what the GPU supports. And to be honest I would really prefer to stick with that approach for exactly that reason. The proposed change would require that drivers have different code path for different CPU byte order. Those code path tend to be not tested very well and are additional complexity we probably don't want inside the driver. My personal opinion is that formats in drm_fourcc.h should be independent of the CPU byte order and the function drm_mode_legacy_fb_format() and drivers depending on that incorrect assumption be fixed instead. Regards, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC 3/6] drm: Plane YCbCr to RGB conversion related properties
Hello,
CC'ing Hans Verkuil for his knowledge on colorspace.
On Friday 21 Apr 2017 14:17:56 Ville Syrjälä wrote:
> On Fri, Apr 21, 2017 at 12:51:14PM +0300, Jyri Sarha wrote:
> > Add standard properties to control YCbCr to RGB conversion in DRM
> > planes. The created properties are stored to drm_plane object to allow
> > different set of supported conversion modes for different planes on
> > the device. For simplicity the related property blobs for CSC matrix
> > and YCbCr preoffsets are also stored in the same place. The blob
> > contents are defined in the uapi/drm/drm_mode.h header.
> >
> > Signed-off-by: Jyri Sarha
> > ---
> >
> > drivers/gpu/drm/drm_atomic.c| 26 +++
> > drivers/gpu/drm/drm_atomic_helper.c | 9 +++
> > drivers/gpu/drm/drm_color_mgmt.c| 136 ++-
> > drivers/gpu/drm/drm_plane.c | 10 +++
> > include/drm/drm_color_mgmt.h| 23 ++
> > include/drm/drm_plane.h | 10 +++
> > include/uapi/drm/drm_mode.h | 12
> > 7 files changed, 223 insertions(+), 3 deletions(-)
[snip]
> > diff --git a/drivers/gpu/drm/drm_color_mgmt.c
> > b/drivers/gpu/drm/drm_color_mgmt.c index cc23b9a..badaddd 100644
> > --- a/drivers/gpu/drm/drm_color_mgmt.c
> > +++ b/drivers/gpu/drm/drm_color_mgmt.c
> > @@ -29,9 +29,14 @@
> > /**
> > * DOC: overview
> > *
> > - * Color management or color space adjustments is supported through a set
> > of 5
> > - * properties on the &drm_crtc object. They are set up by calling
> > - * drm_crtc_enable_color_mgmt().
> > + * Color management or color space adjustments in CRTCs is supported
> > + * through a set of 5 properties on the &drm_crtc object. They are set
> > + * up by calling drm_crtc_enable_color_mgmt().
> > + *
> > + * Color space conversions from YCbCr to RGB color space in planes is
> > + * supporter trough 3 optional properties in &drm_plane object.
> > + *
> > + * The &drm_crtc object's properties are:
> > *
> > * "DEGAMMA_LUT”:
> > * Blob property to set the degamma lookup table (LUT) mapping pixel data
> > @@ -85,6 +90,28 @@
> > * drm_mode_crtc_set_gamma_size(). Drivers which support both should use
> > * drm_atomic_helper_legacy_gamma_set() to alias the legacy gamma ramp
> > with the
> > * "GAMMA_LUT" property above.
> >
> > + *
> > + * The &drm_plane object's properties are:
> > + *
> > + * "YCBCR_TO_RGB_MODE"
> > + * Optional plane enum property to configure YCbCr to RGB
> > + * conversion. The possible modes include a number of standard
> > + * conversions and a possibility to select custom conversion
> > + * matrix and preoffset vector. The driver should select the
> > + * supported subset of of the modes.
> > + *
> > + * "YCBCR_TO_RGB_CSC"
> > + * Optional plane property blob to set YCbCr to RGB conversion
> > + * matrix. The blob contains struct drm_ycbcr_to_rgb_csc which is
> > + * defined in uapi/drm/drm_mode.h. Whether this property is
> > + * active dependent on YCBCR_TO_RGB_MODE property.
> > + *
> > + * "YCBCR_TO_RGB_PREOFFSET"
> > + * Optional plane property blob to configure YCbCr offset before
> > + * YCbCr to RGB CSC is applied. The blob contains struct
> > + * drm_ycbcr_to_rgb_preoffset which is defined in
> > + * uapi/drm/drm_mode.h. Whether this property is active dependent
> > + * on YCBCR_TO_RGB_MODE property.
> > */
> >
> > /**
> > @@ -330,3 +357,106 @@ int drm_mode_gamma_get_ioctl(struct drm_device *dev,
> > drm_modeset_unlock_all(dev);
> > return ret;
> > }
> > +
> > +static char *ycbcr_to_rgb_mode_name[] = {
> > + [DRM_PLANE_YCBCR_BT601_LIM_TO_RGB_BT601_FULL] =
> > + "YCbCr BT.601 limited range TO RGB BT.601 full range",
> > + [DRM_PLANE_YCBCR_BT601_FULL_TO_RGB_BT601_FULL] =
> > + "YCbCr BT.601 full range TO RGB BT.601 full range",
> > + [DRM_PLANE_YCBCR_BT709_LIM_TO_RGB_BT709_FULL] =
> > + "YCbCr BT.709 limited range TO RGB BT.709 full range",
> > + [DRM_PLANE_YCBCR_BT2020_LIM_TO_RGB_BT2020_FULL] =
> > + "YCbCr BT.2020 limited range TO RGB BT.2020 full range",
> > + [DRM_PLANE_YCBCR_BT601_LIM_TO_RGB_BT709_FULL] =
> > + "YCbCr BT.601 limited range TO RGB BT.709 full range",
>
> We probably don't want to conflate the YCbCr->RGB part with the colorspace
> conversion because the YCbCr->RGB part should be performed on gamma encoded
> data and the colorspace conversion on linear data. So we need a degamma
> stage in between. At least that seemed to be the general concencus after
> the last round of mails on this topic.
>
> After staring at the v4l docs on this stuff I kinda like their
> "encoding" terminology to describe the YCbCr->RGB part, so I'm now a
> little partial to calling the prop something like YCBCR_ENCODING.
For quite obvious reasons I agree with this partial reasoning :-) I would also
copy how V4L2 splits color space information into a transfer function, an
encoding and a quantization. If you group a
Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.
Am 21.04.2017 um 13:49 schrieb Ville Syrjälä: On Fri, Apr 21, 2017 at 02:40:18PM +0300, Pekka Paalanen wrote: On Fri, 21 Apr 2017 14:08:04 +0300 Ville Syrjälä wrote: On Fri, Apr 21, 2017 at 11:50:18AM +0200, Gerd Hoffmann wrote: On Fr, 2017-04-21 at 12:25 +0300, Ville Syrjälä wrote: On Fri, Apr 21, 2017 at 09:58:24AM +0200, Gerd Hoffmann wrote: While working on graphics support for virtual machines on ppc64 (which exists in both little and big endian variants) I've figured the comments for various drm fourcc formats in the header file don't match reality. Comments says the RGB formats are little endian, but in practice they are native endian. Look at the drm_mode_legacy_fb_format() helper. It maps -- for example -- bpp/depth 32/24 to DRM_FORMAT_XRGB, no matter whenever the machine is little endian or big endian. The users of this function (fbdev emulation, DRM_IOCTL_MODE_ADDFB) expect the framebuffer is native endian, not little endian. Most userspace also operates on native endian only. I'm not a fan of "native". Native to what? "CPU" or "host" is what I'd call it. native == whatever the cpu is using. I personally find "native" more intuitive, but at the end of the day I don't mind much. If people prefer "host" over "native" I'll change it. "native" to me feels more like "native to the GPU" since these things really are tied to the GPU not the CPU. That's also why I went with the explicit endianness originally so that the driver could properly declare what the GPU supports. Hi, yeah, one should really be explicit on which component's endianess does "native" refer to. I just can't imagine "GPU native" to ever be an option, because then userspace needs a way to discover what the GPU endianess is, It has to know that. How else would it know how to write the bytes into memory in the right order for the GPU to consume, or read the stuff the GPU produced? and I believe that would only deepen the swamp, not drain it, because suddenly you need two enums to describe one format. Ville, wording aside, what do think about changing the endianess definition? Is it going in the right direction? I don't think so, but I guess I'm in the minority. I don't think your are in the minority. At least I would clearly say those formats should be in a fixed byte order and don't care about the CPU in the system. What I need from the driver side is a consistent description of how the bytes in memory map to my hardware. What CPU is in use in the system is completely irrelevant for that. Regards, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100058] amdgpu/dpm: NULL pointer dereference
https://bugs.freedesktop.org/show_bug.cgi?id=100058 --- Comment #13 from Edward O'Callaghan --- Created attachment 130967 --> https://bugs.freedesktop.org/attachment.cgi?id=130967&action=edit dpm patch @Adam, please try applying the attached patch and let me know if it helps with your issue? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99368] Full aspect scaling introduces interlacing on specific resolutions
https://bugs.freedesktop.org/show_bug.cgi?id=99368 --- Comment #6 from Adam Bolte --- I'm seeing this too. Running a BenQ XL2730Z (2560x1440@144Hz) gaming monitor, but some games (eg. Prototype 2 under Wine, Saints Row 2) only accept resolutions up to 1920x1080. They cause GPU scaling to automatically kick in (the monitor reports the resolution is still 2560x1440) and everything looks too horrible to look at. Fury X, Mesa 17.0.1. If I run the scaling mode with Center instead of Full aspect, everything looks great (but annoyingly small). -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC 0/6] drm: Add properties to control YCbCr to RGB conversion
Regards Shashank On 4/21/2017 3:21 PM, Jyri Sarha wrote: The series adds plane specific atomic properties to control YCbCr to RGB conversions. My intention was to try to implement the plane specific (before DEGAMMA) part of the suggestion in this dri-devel post: I would probably extend this series to have a bigger view. Instead of addressing RGB->YCBCR conversion, the actual target here should be blending of various framebuffers considering: - their color spaces (Rec 601/709/2020) - their format (YCBCR->RGB or RGB->YCBCR) - their linear state (Linear/Non-linear) or if they are ready for Gamut mapping/color conversion or not. Also, we need to have the sequence of properties, so that, it would match all(most of the) HWs. I will add my comments in the upcoming patches accordingly. - Shashank https://lists.freedesktop.org/archives/dri-devel/2017-March/135870.html This series may not be ready as such. At least the kernel doc parts should be more detailed and carefully written. The purpose is merely to move the discussion to a more concrete level. The series also includes drm/omap patches that implement the standard properties for OMAP DSS in omapdrm driver. Best regards, Jyri Jyri Sarha (4): drm: drm_color_mgmt.h needs struct drm_crtc declaration drm: Make drm_atomic_replace_property_blob_from_id() more generic drm: Plane YCbCr to RGB conversion related properties drm/omap: Enable ycbcr_to_rgb_properties for omapdrm planes REVISIT Tomi Valkeinen (2): drm/omap: cleanup color space conversion drm/omap: csc full range support drivers/gpu/drm/drm_atomic.c | 36 +++-- drivers/gpu/drm/drm_atomic_helper.c | 9 +++ drivers/gpu/drm/drm_color_mgmt.c | 136 +++- drivers/gpu/drm/drm_plane.c | 10 +++ drivers/gpu/drm/omapdrm/dss/dispc.c | 141 +- drivers/gpu/drm/omapdrm/dss/omapdss.h | 14 drivers/gpu/drm/omapdrm/omap_plane.c | 41 ++ include/drm/drm_color_mgmt.h | 25 ++ include/drm/drm_plane.h | 10 +++ include/uapi/drm/drm_mode.h | 12 +++ 10 files changed, 408 insertions(+), 26 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC 3/6] drm: Plane YCbCr to RGB conversion related properties
Regards
Shashank
On 4/21/2017 4:47 PM, Ville Syrjälä wrote:
On Fri, Apr 21, 2017 at 12:51:14PM +0300, Jyri Sarha wrote:
Add standard properties to control YCbCr to RGB conversion in DRM
planes. The created properties are stored to drm_plane object to allow
different set of supported conversion modes for different planes on
the device. For simplicity the related property blobs for CSC matrix
and YCbCr preoffsets are also stored in the same place. The blob
contents are defined in the uapi/drm/drm_mode.h header.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/drm_atomic.c| 26 +++
drivers/gpu/drm/drm_atomic_helper.c | 9 +++
drivers/gpu/drm/drm_color_mgmt.c| 136 +++-
drivers/gpu/drm/drm_plane.c | 10 +++
include/drm/drm_color_mgmt.h| 23 ++
include/drm/drm_plane.h | 10 +++
include/uapi/drm/drm_mode.h | 12
7 files changed, 223 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index f881319..d1512aa 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -732,6 +732,8 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
{
struct drm_device *dev = plane->dev;
struct drm_mode_config *config = &dev->mode_config;
+ int ret;
+ bool dummy;
if (property == config->prop_fb_id) {
struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, val);
@@ -774,6 +776,22 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
state->rotation = val;
} else if (property == plane->zpos_property) {
state->zpos = val;
+ } else if (property == plane->ycbcr_to_rgb_mode_property) {
+ state->ycbcr_to_rgb_mode = val;
+ } else if (property == plane->ycbcr_to_rgb_csc_property) {
+ ret = drm_atomic_replace_property_blob_from_id(dev,
+ &state->ycbcr_to_rgb_csc,
+ val,
+ sizeof(struct drm_ycbcr_to_rgb_csc),
+ &dummy);
+ return ret;
+ } else if (property == plane->ycbcr_to_rgb_preoffset_property) {
+ ret = drm_atomic_replace_property_blob_from_id(dev,
+ &state->ycbcr_to_rgb_preoffset,
+ val,
+ sizeof(struct drm_ycbcr_to_rgb_preoffset),
+ &dummy);
+ return ret;
} else if (plane->funcs->atomic_set_property) {
return plane->funcs->atomic_set_property(plane, state,
property, val);
@@ -834,6 +852,14 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
*val = state->rotation;
} else if (property == plane->zpos_property) {
*val = state->zpos;
+ } else if (property == plane->ycbcr_to_rgb_mode_property) {
+ *val = state->ycbcr_to_rgb_mode;
+ } else if (property == plane->ycbcr_to_rgb_csc_property) {
+ *val = state->ycbcr_to_rgb_csc ?
+ state->ycbcr_to_rgb_csc->base.id : 0;
+ } else if (property == plane->ycbcr_to_rgb_preoffset_property) {
+ *val = state->ycbcr_to_rgb_preoffset ?
+ state->ycbcr_to_rgb_preoffset->base.id : 0;
} else if (plane->funcs->atomic_get_property) {
return plane->funcs->atomic_get_property(plane, state,
property, val);
} else {
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index c3994b4..89fd826 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3196,6 +3196,12 @@ void __drm_atomic_helper_plane_duplicate_state(struct
drm_plane *plane,
{
memcpy(state, plane->state, sizeof(*state));
+ if (state->ycbcr_to_rgb_csc)
+ drm_property_blob_get(state->ycbcr_to_rgb_csc);
+
+ if (state->ycbcr_to_rgb_preoffset)
+ drm_property_blob_get(state->ycbcr_to_rgb_preoffset);
+
if (state->fb)
drm_framebuffer_get(state->fb);
@@ -3236,6 +3242,9 @@ struct drm_plane_state *
*/
void __drm_atomic_helper_plane_destroy_state(struct drm_plane_state *state)
{
+ drm_property_blob_put(state->ycbcr_to_rgb_csc);
+ drm_property_blob_put(state->ycbcr_to_rgb_preoffset);
+
if (state->fb)
drm_framebuffer_put(state->fb);
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index cc23b9a..badaddd 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -29,9 +29,14 @@
/**
* DOC: overview
*
- * Color management or color space adjustments is supported through a set of 5
- * properties on the &drm_crtc object. They are set up by calling
- * drm_crtc_en
Re: [PATCH RFC 3/6] drm: Plane YCbCr to RGB conversion related properties
On Fri, Apr 21, 2017 at 03:10:31PM +0300, Laurent Pinchart wrote:
> Hello,
>
> CC'ing Hans Verkuil for his knowledge on colorspace.
>
> On Friday 21 Apr 2017 14:17:56 Ville Syrjälä wrote:
> > On Fri, Apr 21, 2017 at 12:51:14PM +0300, Jyri Sarha wrote:
> > > Add standard properties to control YCbCr to RGB conversion in DRM
> > > planes. The created properties are stored to drm_plane object to allow
> > > different set of supported conversion modes for different planes on
> > > the device. For simplicity the related property blobs for CSC matrix
> > > and YCbCr preoffsets are also stored in the same place. The blob
> > > contents are defined in the uapi/drm/drm_mode.h header.
> > >
> > > Signed-off-by: Jyri Sarha
> > > ---
> > >
> > > drivers/gpu/drm/drm_atomic.c| 26 +++
> > > drivers/gpu/drm/drm_atomic_helper.c | 9 +++
> > > drivers/gpu/drm/drm_color_mgmt.c| 136 ++-
> > > drivers/gpu/drm/drm_plane.c | 10 +++
> > > include/drm/drm_color_mgmt.h| 23 ++
> > > include/drm/drm_plane.h | 10 +++
> > > include/uapi/drm/drm_mode.h | 12
> > > 7 files changed, 223 insertions(+), 3 deletions(-)
>
> [snip]
>
> > > diff --git a/drivers/gpu/drm/drm_color_mgmt.c
> > > b/drivers/gpu/drm/drm_color_mgmt.c index cc23b9a..badaddd 100644
> > > --- a/drivers/gpu/drm/drm_color_mgmt.c
> > > +++ b/drivers/gpu/drm/drm_color_mgmt.c
> > > @@ -29,9 +29,14 @@
> > > /**
> > > * DOC: overview
> > > *
> > > - * Color management or color space adjustments is supported through a set
> > > of 5
> > > - * properties on the &drm_crtc object. They are set up by calling
> > > - * drm_crtc_enable_color_mgmt().
> > > + * Color management or color space adjustments in CRTCs is supported
> > > + * through a set of 5 properties on the &drm_crtc object. They are set
> > > + * up by calling drm_crtc_enable_color_mgmt().
> > > + *
> > > + * Color space conversions from YCbCr to RGB color space in planes is
> > > + * supporter trough 3 optional properties in &drm_plane object.
> > > + *
> > > + * The &drm_crtc object's properties are:
> > > *
> > > * "DEGAMMA_LUT”:
> > > * Blob property to set the degamma lookup table (LUT) mapping
> > > pixel data
> > > @@ -85,6 +90,28 @@
> > > * drm_mode_crtc_set_gamma_size(). Drivers which support both should use
> > > * drm_atomic_helper_legacy_gamma_set() to alias the legacy gamma ramp
> > > with the
> > > * "GAMMA_LUT" property above.
> > >
> > > + *
> > > + * The &drm_plane object's properties are:
> > > + *
> > > + * "YCBCR_TO_RGB_MODE"
> > > + * Optional plane enum property to configure YCbCr to RGB
> > > + * conversion. The possible modes include a number of standard
> > > + * conversions and a possibility to select custom conversion
> > > + * matrix and preoffset vector. The driver should select the
> > > + * supported subset of of the modes.
> > > + *
> > > + * "YCBCR_TO_RGB_CSC"
> > > + * Optional plane property blob to set YCbCr to RGB conversion
> > > + * matrix. The blob contains struct drm_ycbcr_to_rgb_csc which is
> > > + * defined in uapi/drm/drm_mode.h. Whether this property is
> > > + * active dependent on YCBCR_TO_RGB_MODE property.
> > > + *
> > > + * "YCBCR_TO_RGB_PREOFFSET"
> > > + * Optional plane property blob to configure YCbCr offset before
> > > + * YCbCr to RGB CSC is applied. The blob contains struct
> > > + * drm_ycbcr_to_rgb_preoffset which is defined in
> > > + * uapi/drm/drm_mode.h. Whether this property is active dependent
> > > + * on YCBCR_TO_RGB_MODE property.
> > > */
> > >
> > > /**
> > > @@ -330,3 +357,106 @@ int drm_mode_gamma_get_ioctl(struct drm_device *dev,
> > > drm_modeset_unlock_all(dev);
> > > return ret;
> > > }
> > > +
> > > +static char *ycbcr_to_rgb_mode_name[] = {
> > > + [DRM_PLANE_YCBCR_BT601_LIM_TO_RGB_BT601_FULL] =
> > > + "YCbCr BT.601 limited range TO RGB BT.601 full range",
> > > + [DRM_PLANE_YCBCR_BT601_FULL_TO_RGB_BT601_FULL] =
> > > + "YCbCr BT.601 full range TO RGB BT.601 full range",
> > > + [DRM_PLANE_YCBCR_BT709_LIM_TO_RGB_BT709_FULL] =
> > > + "YCbCr BT.709 limited range TO RGB BT.709 full range",
> > > + [DRM_PLANE_YCBCR_BT2020_LIM_TO_RGB_BT2020_FULL] =
> > > + "YCbCr BT.2020 limited range TO RGB BT.2020 full range",
> > > + [DRM_PLANE_YCBCR_BT601_LIM_TO_RGB_BT709_FULL] =
> > > + "YCbCr BT.601 limited range TO RGB BT.709 full range",
> >
> > We probably don't want to conflate the YCbCr->RGB part with the colorspace
> > conversion because the YCbCr->RGB part should be performed on gamma encoded
> > data and the colorspace conversion on linear data. So we need a degamma
> > stage in between. At least that seemed to be the general concencus after
> > the last round of mails on this topic.
> >
> > After staring at the v4l docs on this stuff I kinda like their
> > "encoding" termin
Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.
Hi, > > "native" to me feels more like "native to the GPU" since these things > > really are tied to the GPU not the CPU. That's also why I went with the > > explicit endianness originally so that the driver could properly declare > > what the GPU supports. > And to be honest I would really prefer to stick with that approach for > exactly that reason. > > The proposed change would require that drivers have different code path > for different CPU byte order. Those code path tend to be not tested very > well and are additional complexity we probably don't want inside the driver. We can add fixed-endian #defines without too much effort, at least for the 8 bits per color formats. In qemu we have the same problem, only with pixman. Those formats are native endian too, but often we have to handle a fixed format, so we did this: /* * pixman image formats are defined to be native endian, * that means host byte order on qemu. So we go define * fixed formats here for cases where it is needed, like * feeding libjpeg / libpng and writing screenshots. */ #ifdef HOST_WORDS_BIGENDIAN # define PIXMAN_BE_r8g8b8 PIXMAN_r8g8b8 # define PIXMAN_BE_x8r8g8b8 PIXMAN_x8r8g8b8 # define PIXMAN_BE_a8r8g8b8 PIXMAN_a8r8g8b8 # define PIXMAN_BE_b8g8r8x8 PIXMAN_b8g8r8x8 # define PIXMAN_BE_b8g8r8a8 PIXMAN_b8g8r8a8 # define PIXMAN_BE_r8g8b8x8 PIXMAN_r8g8b8x8 # define PIXMAN_BE_r8g8b8a8 PIXMAN_r8g8b8a8 # define PIXMAN_BE_x8b8g8r8 PIXMAN_x8b8g8r8 # define PIXMAN_BE_a8b8g8r8 PIXMAN_a8b8g8r8 # define PIXMAN_LE_x8r8g8b8 PIXMAN_b8g8r8x8 #else # define PIXMAN_BE_r8g8b8 PIXMAN_b8g8r8 # define PIXMAN_BE_x8r8g8b8 PIXMAN_b8g8r8x8 # define PIXMAN_BE_a8r8g8b8 PIXMAN_b8g8r8a8 # define PIXMAN_BE_b8g8r8x8 PIXMAN_x8r8g8b8 # define PIXMAN_BE_b8g8r8a8 PIXMAN_a8r8g8b8 # define PIXMAN_BE_r8g8b8x8 PIXMAN_x8b8g8r8 # define PIXMAN_BE_r8g8b8a8 PIXMAN_a8b8g8r8 # define PIXMAN_BE_x8b8g8r8 PIXMAN_r8g8b8x8 # define PIXMAN_BE_a8b8g8r8 PIXMAN_r8g8b8a8 # define PIXMAN_LE_x8r8g8b8 PIXMAN_x8r8g8b8 #endif > My personal opinion is that formats in drm_fourcc.h should be > independent of the CPU byte order and the function > drm_mode_legacy_fb_format() and drivers depending on that incorrect > assumption be fixed instead. The problem is this isn't a kernel-internal thing any more. With the addition of the ADDFB2 ioctl the fourcc codes became part of the kernel/userspace abi ... cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] Rv6xx dpm problems
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #295 from Alex Deucher --- (In reply to Kyle K from comment #294) > Hello, > > I have been having problem with my HD6870 for some time. I experienced it on > 4.7/4.8/4.9 kernels (haven't tested earlier). My HD6870 works great out of > the box with DPM enabled, I do not have any issues for general use. Please file your own bug. This bug is for dpm on r6xx hardware. Your hardware is NI. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100745] amdgpu fails to wake up DisplayPort DELL monitors with 'clock recovery failed'
https://bugs.freedesktop.org/show_bug.cgi?id=100745 --- Comment #4 from Harry Wentland --- Are the monitors set to DP input or to auto-select? If they are in auto-select will setting input to DP help? I've seen auto-select mode have problems with DP many times, especially with scenarios like coming back from DPMS or S3 resume. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.
Am 21.04.2017 um 15:12 schrieb Gerd Hoffmann: Hi, "native" to me feels more like "native to the GPU" since these things really are tied to the GPU not the CPU. That's also why I went with the explicit endianness originally so that the driver could properly declare what the GPU supports. And to be honest I would really prefer to stick with that approach for exactly that reason. The proposed change would require that drivers have different code path for different CPU byte order. Those code path tend to be not tested very well and are additional complexity we probably don't want inside the driver. We can add fixed-endian #defines without too much effort, at least for the 8 bits per color formats. In qemu we have the same problem, only with pixman. Those formats are native endian too, but often we have to handle a fixed format, so we did this: /* * pixman image formats are defined to be native endian, * that means host byte order on qemu. So we go define * fixed formats here for cases where it is needed, like * feeding libjpeg / libpng and writing screenshots. */ #ifdef HOST_WORDS_BIGENDIAN # define PIXMAN_BE_r8g8b8 PIXMAN_r8g8b8 # define PIXMAN_BE_x8r8g8b8 PIXMAN_x8r8g8b8 # define PIXMAN_BE_a8r8g8b8 PIXMAN_a8r8g8b8 # define PIXMAN_BE_b8g8r8x8 PIXMAN_b8g8r8x8 # define PIXMAN_BE_b8g8r8a8 PIXMAN_b8g8r8a8 # define PIXMAN_BE_r8g8b8x8 PIXMAN_r8g8b8x8 # define PIXMAN_BE_r8g8b8a8 PIXMAN_r8g8b8a8 # define PIXMAN_BE_x8b8g8r8 PIXMAN_x8b8g8r8 # define PIXMAN_BE_a8b8g8r8 PIXMAN_a8b8g8r8 # define PIXMAN_LE_x8r8g8b8 PIXMAN_b8g8r8x8 #else # define PIXMAN_BE_r8g8b8 PIXMAN_b8g8r8 # define PIXMAN_BE_x8r8g8b8 PIXMAN_b8g8r8x8 # define PIXMAN_BE_a8r8g8b8 PIXMAN_b8g8r8a8 # define PIXMAN_BE_b8g8r8x8 PIXMAN_x8r8g8b8 # define PIXMAN_BE_b8g8r8a8 PIXMAN_a8r8g8b8 # define PIXMAN_BE_r8g8b8x8 PIXMAN_x8b8g8r8 # define PIXMAN_BE_r8g8b8a8 PIXMAN_a8b8g8r8 # define PIXMAN_BE_x8b8g8r8 PIXMAN_r8g8b8x8 # define PIXMAN_BE_a8b8g8r8 PIXMAN_r8g8b8a8 # define PIXMAN_LE_x8r8g8b8 PIXMAN_x8r8g8b8 #endif Exactly what Mesa did as well. My personal opinion is that formats in drm_fourcc.h should be independent of the CPU byte order and the function drm_mode_legacy_fb_format() and drivers depending on that incorrect assumption be fixed instead. The problem is this isn't a kernel-internal thing any more. With the addition of the ADDFB2 ioctl the fourcc codes became part of the kernel/userspace abi ... I know and that's exactly the reason I'm going to object those changes. The kernel/userspace abi is fixed and changing it like this could potentially break drivers I'm the co-maintainer of. So that whole approach is a clear NAK from my side. If you find a driver or userspace which doesn't use the formats as defined in the comments of drm_fourcc.h the fix the driver instead of trying to adjust the common header to broken behavior. Cause the later will clearly cause problems with drivers who correctly implemented the interface. Regards, Christian. cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.
Adding Harry to this mail thread as well, cause is one of the people really affected by this. Christian. Am 21.04.2017 um 15:21 schrieb Christian König: Am 21.04.2017 um 15:12 schrieb Gerd Hoffmann: Hi, "native" to me feels more like "native to the GPU" since these things really are tied to the GPU not the CPU. That's also why I went with the explicit endianness originally so that the driver could properly declare what the GPU supports. And to be honest I would really prefer to stick with that approach for exactly that reason. The proposed change would require that drivers have different code path for different CPU byte order. Those code path tend to be not tested very well and are additional complexity we probably don't want inside the driver. We can add fixed-endian #defines without too much effort, at least for the 8 bits per color formats. In qemu we have the same problem, only with pixman. Those formats are native endian too, but often we have to handle a fixed format, so we did this: /* * pixman image formats are defined to be native endian, * that means host byte order on qemu. So we go define * fixed formats here for cases where it is needed, like * feeding libjpeg / libpng and writing screenshots. */ #ifdef HOST_WORDS_BIGENDIAN # define PIXMAN_BE_r8g8b8 PIXMAN_r8g8b8 # define PIXMAN_BE_x8r8g8b8 PIXMAN_x8r8g8b8 # define PIXMAN_BE_a8r8g8b8 PIXMAN_a8r8g8b8 # define PIXMAN_BE_b8g8r8x8 PIXMAN_b8g8r8x8 # define PIXMAN_BE_b8g8r8a8 PIXMAN_b8g8r8a8 # define PIXMAN_BE_r8g8b8x8 PIXMAN_r8g8b8x8 # define PIXMAN_BE_r8g8b8a8 PIXMAN_r8g8b8a8 # define PIXMAN_BE_x8b8g8r8 PIXMAN_x8b8g8r8 # define PIXMAN_BE_a8b8g8r8 PIXMAN_a8b8g8r8 # define PIXMAN_LE_x8r8g8b8 PIXMAN_b8g8r8x8 #else # define PIXMAN_BE_r8g8b8 PIXMAN_b8g8r8 # define PIXMAN_BE_x8r8g8b8 PIXMAN_b8g8r8x8 # define PIXMAN_BE_a8r8g8b8 PIXMAN_b8g8r8a8 # define PIXMAN_BE_b8g8r8x8 PIXMAN_x8r8g8b8 # define PIXMAN_BE_b8g8r8a8 PIXMAN_a8r8g8b8 # define PIXMAN_BE_r8g8b8x8 PIXMAN_x8b8g8r8 # define PIXMAN_BE_r8g8b8a8 PIXMAN_a8b8g8r8 # define PIXMAN_BE_x8b8g8r8 PIXMAN_r8g8b8x8 # define PIXMAN_BE_a8b8g8r8 PIXMAN_r8g8b8a8 # define PIXMAN_LE_x8r8g8b8 PIXMAN_x8r8g8b8 #endif Exactly what Mesa did as well. My personal opinion is that formats in drm_fourcc.h should be independent of the CPU byte order and the function drm_mode_legacy_fb_format() and drivers depending on that incorrect assumption be fixed instead. The problem is this isn't a kernel-internal thing any more. With the addition of the ADDFB2 ioctl the fourcc codes became part of the kernel/userspace abi ... I know and that's exactly the reason I'm going to object those changes. The kernel/userspace abi is fixed and changing it like this could potentially break drivers I'm the co-maintainer of. So that whole approach is a clear NAK from my side. If you find a driver or userspace which doesn't use the formats as defined in the comments of drm_fourcc.h the fix the driver instead of trying to adjust the common header to broken behavior. Cause the later will clearly cause problems with drivers who correctly implemented the interface. Regards, Christian. cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ amd-gfx mailing list amd-...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC 3/6] drm: Plane YCbCr to RGB conversion related properties
On 04/21/17 14:17, Ville Syrjälä wrote:
>> +static char *ycbcr_to_rgb_mode_name[] = {
>> +[DRM_PLANE_YCBCR_BT601_LIM_TO_RGB_BT601_FULL] =
>> +"YCbCr BT.601 limited range TO RGB BT.601 full range",
>> +[DRM_PLANE_YCBCR_BT601_FULL_TO_RGB_BT601_FULL] =
>> +"YCbCr BT.601 full range TO RGB BT.601 full range",
>> +[DRM_PLANE_YCBCR_BT709_LIM_TO_RGB_BT709_FULL] =
>> +"YCbCr BT.709 limited range TO RGB BT.709 full range",
>> +[DRM_PLANE_YCBCR_BT2020_LIM_TO_RGB_BT2020_FULL] =
>> +"YCbCr BT.2020 limited range TO RGB BT.2020 full range",
>> +[DRM_PLANE_YCBCR_BT601_LIM_TO_RGB_BT709_FULL] =
>> +"YCbCr BT.601 limited range TO RGB BT.709 full range",
> We probably don't want to conflate the YCbCr->RGB part with the colorspace
> conversion because the YCbCr->RGB part should be performed on gamma encoded
> data and the colorspace conversion on linear data. So we need a degamma
> stage in between. At least that seemed to be the general concencus after
> the last round of mails on this topic.
>
I do not really have the expertise to argue with that. I merely copied
the idea from the mail thread I referred to in the cover letter.
However, there are several display HWs out there that do not have all
bolts and knobs to make the color-space conversion in exactly the ideal
order, omap DSS being one of them.
> After staring at the v4l docs on this stuff I kinda like their
> "encoding" terminology to describe the YCbCr->RGB part, so I'm now a
> little partial to calling the prop something like YCBCR_ENCODING. OTOH
I guess this property should be called YCBCR_DECODING.
> if we want to expose the raw matrix as a blob then maybe calling it a
> CSC might be better. Not sure there's much point in exposing it though.
In my first version it was called just CSC, but then I wanted to make it
explicit what this CSC was used for to avoid mixing the YCbCr decoding
matrix with YCbCr encoding matrix. At least on OMAP DSS we have pieces
of HW that can do only one or the other, e.g. the offset calculations
are supported only to one direction.
> I don't think most people are in the habit if cooking up new ways to
> encode their pixel data.
>
In the embedded side I can imagine there could be some custom appliances
where one may want to do some custom thing with the CSC and not needing
a custom kernel for that could make a life easier... but then again I am
not really an expert in this area.
Best regards,
Jyri
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/mediatek: fix a timeout loop
On Fri, 2017-04-21 at 13:51 +0300, Dan Carpenter wrote:
> This code causes a static checker warning because it treats "i == 0" as
> a timeout but, because it's a post-op, the loop actually ends with "i"
> set to -1. Philipp Zabel points out that it would be cleaner to use
> readl_poll_timeout() instead.
>
> Fixes: 21898816831f ("drm/mediatek: add dsi transfer function")
> Signed-off-by: Dan Carpenter
Reviewed-by: Philipp Zabel
> ---
> v2: Use readl_poll_timeout(). Please review this carefully because I've
> never used readl_poll_timeout() and could easily mess up.
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 808b995a990f..b5cc6e12334c 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -19,6 +19,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -900,16 +901,12 @@ static int mtk_dsi_host_detach(struct mipi_dsi_host
> *host,
>
> static void mtk_dsi_wait_for_idle(struct mtk_dsi *dsi)
> {
> - u32 timeout_ms = 50; /* total 1s ~ 2s timeout */
> -
> - while (timeout_ms--) {
> - if (!(readl(dsi->regs + DSI_INTSTA) & DSI_BUSY))
> - break;
> -
> - usleep_range(2, 4);
> - }
> + int ret;
> + u32 val;
>
> - if (timeout_ms == 0) {
> + ret = readl_poll_timeout(dsi->regs + DSI_INTSTA, val, !(val & DSI_BUSY),
> + 4, 200);
> + if (ret) {
> DRM_WARN("polling dsi wait not busy timeout!\n");
>
> mtk_dsi_enable(dsi);
>
regards
Philipp
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC 0/6] drm: Add properties to control YCbCr to RGB conversion
Hi Jyri, On Fri, Apr 21, 2017 at 12:51:11PM +0300, Jyri Sarha wrote: > The series adds plane specific atomic properties to control YCbCr to > RGB conversions. My intention was to try to implement the plane > specific (before DEGAMMA) part of the suggestion in this dri-devel > post: > > https://lists.freedesktop.org/archives/dri-devel/2017-March/135870.html > > This series may not be ready as such. At least the kernel doc parts > should be more detailed and carefully written. The purpose is merely > to move the discussion to a more concrete level. > > The series also includes drm/omap patches that implement the standard > properties for OMAP DSS in omapdrm driver. Thanks for re-starting this. The first two patches sort of matches what I've had internally from Mihail when we starting the discussion in the thread you mentioned. I will also try to port the mali-dp specific patches on top of your series and provide feedback. Best regards, Liviu > > Best regards, > Jyri > > Jyri Sarha (4): > drm: drm_color_mgmt.h needs struct drm_crtc declaration > drm: Make drm_atomic_replace_property_blob_from_id() more generic > drm: Plane YCbCr to RGB conversion related properties > drm/omap: Enable ycbcr_to_rgb_properties for omapdrm planes REVISIT > > Tomi Valkeinen (2): > drm/omap: cleanup color space conversion > drm/omap: csc full range support > > drivers/gpu/drm/drm_atomic.c | 36 +++-- > drivers/gpu/drm/drm_atomic_helper.c | 9 +++ > drivers/gpu/drm/drm_color_mgmt.c | 136 +++- > drivers/gpu/drm/drm_plane.c | 10 +++ > drivers/gpu/drm/omapdrm/dss/dispc.c | 141 > +- > drivers/gpu/drm/omapdrm/dss/omapdss.h | 14 > drivers/gpu/drm/omapdrm/omap_plane.c | 41 ++ > include/drm/drm_color_mgmt.h | 25 ++ > include/drm/drm_plane.h | 10 +++ > include/uapi/drm/drm_mode.h | 12 +++ > 10 files changed, 408 insertions(+), 26 deletions(-) > > -- > 1.9.1 > -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC 3/6] drm: Plane YCbCr to RGB conversion related properties
On Fri, Apr 21, 2017 at 04:39:16PM +0300, Jyri Sarha wrote:
> On 04/21/17 14:17, Ville Syrjälä wrote:
> >> +static char *ycbcr_to_rgb_mode_name[] = {
> >> + [DRM_PLANE_YCBCR_BT601_LIM_TO_RGB_BT601_FULL] =
> >> + "YCbCr BT.601 limited range TO RGB BT.601 full range",
> >> + [DRM_PLANE_YCBCR_BT601_FULL_TO_RGB_BT601_FULL] =
> >> + "YCbCr BT.601 full range TO RGB BT.601 full range",
> >> + [DRM_PLANE_YCBCR_BT709_LIM_TO_RGB_BT709_FULL] =
> >> + "YCbCr BT.709 limited range TO RGB BT.709 full range",
> >> + [DRM_PLANE_YCBCR_BT2020_LIM_TO_RGB_BT2020_FULL] =
> >> + "YCbCr BT.2020 limited range TO RGB BT.2020 full range",
> >> + [DRM_PLANE_YCBCR_BT601_LIM_TO_RGB_BT709_FULL] =
> >> + "YCbCr BT.601 limited range TO RGB BT.709 full range",
> > We probably don't want to conflate the YCbCr->RGB part with the colorspace
> > conversion because the YCbCr->RGB part should be performed on gamma encoded
> > data and the colorspace conversion on linear data. So we need a degamma
> > stage in between. At least that seemed to be the general concencus after
> > the last round of mails on this topic.
> >
>
> I do not really have the expertise to argue with that. I merely copied
> the idea from the mail thread I referred to in the cover letter.
> However, there are several display HWs out there that do not have all
> bolts and knobs to make the color-space conversion in exactly the ideal
> order, omap DSS being one of them.
Yeah. Intel hardware is in the same boat for the time being. On current
hw I think we can only really expose the YCbCr->RGB and degamma stages.
On some limited set of platforms we could expose a blob as well, and I
suppose it would then be possible to use it for color space conversion
if you ignore gamma and/or only deal with linear RGB data. But it's such
a limited subset of hardware for us that I don't think I'm interested
in exposing it.
In the future we should be getting a more fully fleged pipeline.
>
> > After staring at the v4l docs on this stuff I kinda like their
> > "encoding" terminology to describe the YCbCr->RGB part, so I'm now a
> > little partial to calling the prop something like YCBCR_ENCODING. OTOH
>
> I guess this property should be called YCBCR_DECODING.
Only if you think of it as a verb.
>
> > if we want to expose the raw matrix as a blob then maybe calling it a
> > CSC might be better. Not sure there's much point in exposing it though.
>
> In my first version it was called just CSC, but then I wanted to make it
> explicit what this CSC was used for to avoid mixing the YCbCr decoding
> matrix with YCbCr encoding matrix. At least on OMAP DSS we have pieces
> of HW that can do only one or the other, e.g. the offset calculations
> are supported only to one direction.
Are you planning to do RGB->YCbCr conversion in the plane as well? I
think we'll be only doing that at crtc/connector level.
>
> > I don't think most people are in the habit if cooking up new ways to
> > encode their pixel data.
> >
>
> In the embedded side I can imagine there could be some custom appliances
> where one may want to do some custom thing with the CSC and not needing
> a custom kernel for that could make a life easier... but then again I am
> not really an expert in this area.
I would assume most customy things you'd do in the crtc (eg. color
correction and whatnot). But could be that I just lack imagination.
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 195483] New: radeon: video modes over 1920x1080 not working with DP audio
https://bugzilla.kernel.org/show_bug.cgi?id=195483 Bug ID: 195483 Summary: radeon: video modes over 1920x1080 not working with DP audio Product: Drivers Version: 2.5 Kernel Version: 4.0 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: msucha...@suse.de Regression: No Created attachment 255947 --> https://bugzilla.kernel.org/attachment.cgi?id=255947&action=edit binary edid obtained with read-edid (complained about extra blocks) Since introduction of DP audio in 4.0 all the way to 4.10 monitor does not sync unless mode <=1920x1080 is used or radeon module is loaded with audio=0. Tried modes 1920x1200 (nearest supported larger mode) and 2560x1440 (native). -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 195483] radeon: video modes over 1920x1080 not working with DP audio
https://bugzilla.kernel.org/show_bug.cgi?id=195483 --- Comment #1 from Michal Suchánek (msucha...@suse.de) --- Created attachment 255949 --> https://bugzilla.kernel.org/attachment.cgi?id=255949&action=edit text representation of edid as decoded by edid-decode -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 195483] radeon: video modes over 1920x1080 not working with DP audio
https://bugzilla.kernel.org/show_bug.cgi?id=195483 --- Comment #2 from Michal Suchánek (msucha...@suse.de) --- Created attachment 255951 --> https://bugzilla.kernel.org/attachment.cgi?id=255951&action=edit radeon card pci id -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.
On Fri, Apr 21, 2017 at 3:58 AM, Gerd Hoffmann wrote:
> While working on graphics support for virtual machines on ppc64 (which
> exists in both little and big endian variants) I've figured the comments
> for various drm fourcc formats in the header file don't match reality.
>
> Comments says the RGB formats are little endian, but in practice they
> are native endian. Look at the drm_mode_legacy_fb_format() helper. It
> maps -- for example -- bpp/depth 32/24 to DRM_FORMAT_XRGB, no matter
> whenever the machine is little endian or big endian. The users of this
> function (fbdev emulation, DRM_IOCTL_MODE_ADDFB) expect the framebuffer
> is native endian, not little endian. Most userspace also operates on
> native endian only.
>
> So, go update the comments for all 16+24+32 bpp RGB formats.
>
> Leaving the yuv formats as-is. I have no idea if and how those are used
> on bigendian machines.
I think this is premature. The current situation is that I can't get
modetest to work *at all* on my NV34 / BE setup (I mean, it runs, just
the colors displayed are wrong). I believe that currently it packs
things in "cpu native endian". I've tried futzing with that without
much success, although I didn't spend too much time on it. I have a
NV34 plugged into my LE setup as well although I haven't tested to
double-check that it all works there. However I'm quite sure it used
to, as I used modetest to help develop the YUV overlay support for
those GPUs.
Does modetest work for you, under any interpretation of the formats?
There's an additional complication wrt looking at what fbcon does,
since it will feed the data in via special accel interfaces in fbdev,
which at least on nouveau, may end up byteswapping the data on upload
to VRAM (I'm not 100% clear on whether they do or not). However
modetest, which is creating its own fb, likely won't get such
treatment.
This is a shitty situation - we have hardware we don't know how it
works, tools we don't know whether they're broken, and comments we're
pretty sure are at least somewhat wrong. Furthermore the hardware is
relatively rare and developers with time to work on improving it are
even rarer.
I'd like to reiterate that the status quo does end up in a functioning
system. Let's try not to break that.
Cheers,
-ilia
>
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Pekka Paalanen
> Cc: Ilia Mirkin
> Cc: Michel Dänzer
> Cc: Alex Deucher
> Cc: amd-...@lists.freedesktop.org
> Signed-off-by: Gerd Hoffmann
> ---
> include/uapi/drm/drm_fourcc.h | 82
> +--
> 1 file changed, 41 insertions(+), 41 deletions(-)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 995c8f9..1579765 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -42,68 +42,68 @@ extern "C" {
> #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
> little endian */
> +#define DRM_FORMAT_R16 fourcc_code('R', '1', '6', ' ') /* [15:0] R
> native endian */
>
> /* 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 */
> +#define DRM_FORMAT_RG88fourcc_code('R', 'G', '8', '8') /*
> [15:0] R:G 8:8 native endian */
> +#define DRM_FORMAT_GR88fourcc_code('G', 'R', '8', '8') /*
> [15:0] G:R 8:8 native endian */
>
> /* 32 bpp RG */
> -#define DRM_FORMAT_RG1616 fourcc_code('R', 'G', '3', '2') /* [31:0] R:G
> 16:16 little endian */
> -#define DRM_FORMAT_GR1616 fourcc_code('G', 'R', '3', '2') /* [31:0] G:R
> 16:16 little endian */
> +#define DRM_FORMAT_RG1616 fourcc_code('R', 'G', '3', '2') /* [31:0] R:G
> 16:16 native endian */
> +#define DRM_FORMAT_GR1616 fourcc_code('G', 'R', '3', '2') /* [31:0] G:R
> 16:16 native endian */
>
> /* 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 */
>
> /* 16 bpp RGB */
> -#define DRM_FORMAT_XRGBfourcc_code('X', 'R', '1', '2') /* [15:0]
> x:R:G:B 4:4:4:4 little endian */
> -#define DRM_FORMAT_XBGRfourcc_code('X', 'B', '1', '2') /* [15:0]
> x:B:G:R 4:4:4:4 little endian */
> -#define DRM_FORMAT_RGBXfourcc_code('R', 'X', '1', '2') /* [15:0]
> R:G:B:x 4:4:4:4 little endian */
> -#define DRM_FORMAT_BGRXfourcc_code('B', 'X', '1', '2') /* [15:0]
> B:G:R:x 4:4:4:4 little endian */
> +#define DRM_FORMAT_XRGBfourcc_code('X', 'R', '1', '2') /* [15:0]
> x:R:G:B 4:4:4:4 native endian */
> +#define DRM_FORMAT_XBGRfourcc_code('X', 'B', '1', '2') /* [15:0]
> x:B:G:R 4:4:4:4 native endian */
> +#define DRM_FORMAT_RGBX44
Re: [PATCH RFC 3/6] drm: Plane YCbCr to RGB conversion related properties
Hi,
Thanks for picking this up Jyri.
On Fri, Apr 21, 2017 at 04:52:03PM +0300, Ville Syrjälä wrote:
On Fri, Apr 21, 2017 at 04:39:16PM +0300, Jyri Sarha wrote:
On 04/21/17 14:17, Ville Syrjälä wrote:
>> +static char *ycbcr_to_rgb_mode_name[] = {
>> + [DRM_PLANE_YCBCR_BT601_LIM_TO_RGB_BT601_FULL] =
>> + "YCbCr BT.601 limited range TO RGB BT.601 full range",
>> + [DRM_PLANE_YCBCR_BT601_FULL_TO_RGB_BT601_FULL] =
>> + "YCbCr BT.601 full range TO RGB BT.601 full range",
>> + [DRM_PLANE_YCBCR_BT709_LIM_TO_RGB_BT709_FULL] =
>> + "YCbCr BT.709 limited range TO RGB BT.709 full range",
>> + [DRM_PLANE_YCBCR_BT2020_LIM_TO_RGB_BT2020_FULL] =
>> + "YCbCr BT.2020 limited range TO RGB BT.2020 full range",
>> + [DRM_PLANE_YCBCR_BT601_LIM_TO_RGB_BT709_FULL] =
>> + "YCbCr BT.601 limited range TO RGB BT.709 full range",
> We probably don't want to conflate the YCbCr->RGB part with the colorspace
> conversion because the YCbCr->RGB part should be performed on gamma encoded
> data and the colorspace conversion on linear data. So we need a degamma
> stage in between. At least that seemed to be the general concencus after
> the last round of mails on this topic.
>
I thought the conclusion of the last round was that on some hardware
this would be conflated as a conscious choice. If the HW doesn't have
the required degamma->csc->gamma stages, and the implementor/user
doesn't care about being a little incorrect, then it can all be
described in this single property.
If there is more capable hardware with the additional stages, then
they should expose additional properties (in pipeline order):
YCBCR_TO_RGB_*:
Does YCbCr->RGB conversion on non-linear YCbCr data,
only the enum values which don't have a CSC are exposed.
DEGAMMA:
Does the non-linear to linear conversion on the RGB data output from
the YCBCR_TO_RGB stage.
RGB_TO_RGB_*:
Similar set of properties to YCBCR_TO_RGB_*, allowing RGB->RGB CSC
on the linear data.
GAMMA:
Convert the CSC'd RGB data back in to non-linear for blending (if
blending is to be done with non-linear data).
Drivers can expose as many or as few of the above properties as their
hardware supports.
I do not really have the expertise to argue with that. I merely copied
the idea from the mail thread I referred to in the cover letter.
However, there are several display HWs out there that do not have all
bolts and knobs to make the color-space conversion in exactly the ideal
order, omap DSS being one of them.
Yeah. Intel hardware is in the same boat for the time being. On current
hw I think we can only really expose the YCbCr->RGB and degamma stages.
On some limited set of platforms we could expose a blob as well, and I
suppose it would then be possible to use it for color space conversion
if you ignore gamma and/or only deal with linear RGB data. But it's such
a limited subset of hardware for us that I don't think I'm interested
in exposing it.
I'm not sure the custom blob is worth having either. It can easily be
added later if we decide we want it after all.
Thanks,
-Brian
In the future we should be getting a more fully fleged pipeline.
> After staring at the v4l docs on this stuff I kinda like their
> "encoding" terminology to describe the YCbCr->RGB part, so I'm now a
> little partial to calling the prop something like YCBCR_ENCODING. OTOH
I guess this property should be called YCBCR_DECODING.
Only if you think of it as a verb.
> if we want to expose the raw matrix as a blob then maybe calling it a
> CSC might be better. Not sure there's much point in exposing it though.
In my first version it was called just CSC, but then I wanted to make it
explicit what this CSC was used for to avoid mixing the YCbCr decoding
matrix with YCbCr encoding matrix. At least on OMAP DSS we have pieces
of HW that can do only one or the other, e.g. the offset calculations
are supported only to one direction.
Are you planning to do RGB->YCbCr conversion in the plane as well? I
think we'll be only doing that at crtc/connector level.
> I don't think most people are in the habit if cooking up new ways to
> encode their pixel data.
>
In the embedded side I can imagine there could be some custom appliances
where one may want to do some custom thing with the CSC and not needing
a custom kernel for that could make a life easier... but then again I am
not really an expert in this area.
I would assume most customy things you'd do in the crtc (eg. color
correction and whatnot). But could be that I just lack imagination.
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100673] Tonga agd5f drm-next-4.12-wip xorg segfault on startx
https://bugs.freedesktop.org/show_bug.cgi?id=100673 Alex Deucher changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from Alex Deucher --- Patch is in drm-next now. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 195483] radeon: video modes over 1920x1080 not working with DP audio
https://bugzilla.kernel.org/show_bug.cgi?id=195483 Michal Suchánek (msucha...@suse.de) changed: What|Removed |Added Attachment #255947|0 |1 is obsolete|| --- Comment #3 from Michal Suchánek (msucha...@suse.de) --- Created attachment 255953 --> https://bugzilla.kernel.org/attachment.cgi?id=255953&action=edit binary edid obtained with read-edid using i2c driver -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 195483] radeon: video modes over 1920x1080 not working with DP audio
https://bugzilla.kernel.org/show_bug.cgi?id=195483 Michal Suchánek (msucha...@suse.de) changed: What|Removed |Added Attachment #255949|0 |1 is obsolete|| --- Comment #4 from Michal Suchánek (msucha...@suse.de) --- Created attachment 255955 --> https://bugzilla.kernel.org/attachment.cgi?id=255955&action=edit text representation of edid as decoded by edid-decode -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/edid: Add 10 bpc quirk for LGD 764 panel in HP zBook 17 G2
The builtin eDP panel in the HP zBook 17 G2 supports 10 bpc,
as advertised by the Laptops product specs and verified via
injecting a fixed edid + photometer measurements, but edid
reports unknown depth, so drivers fall back to 6 bpc.
Add a quirk to get the full 10 bpc.
Cc: sta...@vger.kernel.org
Signed-off-by: Mario Kleiner
---
drivers/gpu/drm/drm_edid.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index fad3d44..2e55599 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -80,6 +80,8 @@
#define EDID_QUIRK_FORCE_12BPC (1 << 9)
/* Force 6bpc */
#define EDID_QUIRK_FORCE_6BPC (1 << 10)
+/* Force 10bpc */
+#define EDID_QUIRK_FORCE_10BPC (1 << 11)
struct detailed_mode_closure {
struct drm_connector *connector;
@@ -122,6 +124,9 @@ static const struct edid_quirk {
{ "FCM", 13600, EDID_QUIRK_PREFER_LARGE_75 |
EDID_QUIRK_DETAILED_IN_CM },
+ /* LGD panel of HP zBook 17 G2, eDP 10 bpc, but reports unknown bpc */
+ { "LGD", 764, EDID_QUIRK_FORCE_10BPC },
+
/* LG Philips LCD LP154W01-A5 */
{ "LPL", 0, EDID_QUIRK_DETAILED_USE_MAXIMUM_SIZE },
{ "LPL", 0x2a00, EDID_QUIRK_DETAILED_USE_MAXIMUM_SIZE },
@@ -4244,6 +4249,9 @@ int drm_add_edid_modes(struct drm_connector *connector,
struct edid *edid)
if (quirks & EDID_QUIRK_FORCE_8BPC)
connector->display_info.bpc = 8;
+ if (quirks & EDID_QUIRK_FORCE_10BPC)
+ connector->display_info.bpc = 10;
+
if (quirks & EDID_QUIRK_FORCE_12BPC)
connector->display_info.bpc = 12;
--
2.7.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.
Thanks, Christian for adding me. On 2017-04-21 09:27 AM, Christian König wrote: Adding Harry to this mail thread as well, cause is one of the people really affected by this. Christian. Am 21.04.2017 um 15:21 schrieb Christian König: Am 21.04.2017 um 15:12 schrieb Gerd Hoffmann: Hi, "native" to me feels more like "native to the GPU" since these things really are tied to the GPU not the CPU. That's also why I went with the explicit endianness originally so that the driver could properly declare what the GPU supports. And to be honest I would really prefer to stick with that approach for exactly that reason. I strongly agree with Christian and Ville on this. I understand fourcc endianness as GPU endianness. Usermode needs to be clear on the framebuffer format, whether it's GPU or CPU rendered, so kernel should define this clearly. In practice it probably doesn't currently make much difference for AMD GPUs. I've never heard of anyone using them on big-endian systems. Harry The proposed change would require that drivers have different code path for different CPU byte order. Those code path tend to be not tested very well and are additional complexity we probably don't want inside the driver. We can add fixed-endian #defines without too much effort, at least for the 8 bits per color formats. In qemu we have the same problem, only with pixman. Those formats are native endian too, but often we have to handle a fixed format, so we did this: /* * pixman image formats are defined to be native endian, * that means host byte order on qemu. So we go define * fixed formats here for cases where it is needed, like * feeding libjpeg / libpng and writing screenshots. */ #ifdef HOST_WORDS_BIGENDIAN # define PIXMAN_BE_r8g8b8 PIXMAN_r8g8b8 # define PIXMAN_BE_x8r8g8b8 PIXMAN_x8r8g8b8 # define PIXMAN_BE_a8r8g8b8 PIXMAN_a8r8g8b8 # define PIXMAN_BE_b8g8r8x8 PIXMAN_b8g8r8x8 # define PIXMAN_BE_b8g8r8a8 PIXMAN_b8g8r8a8 # define PIXMAN_BE_r8g8b8x8 PIXMAN_r8g8b8x8 # define PIXMAN_BE_r8g8b8a8 PIXMAN_r8g8b8a8 # define PIXMAN_BE_x8b8g8r8 PIXMAN_x8b8g8r8 # define PIXMAN_BE_a8b8g8r8 PIXMAN_a8b8g8r8 # define PIXMAN_LE_x8r8g8b8 PIXMAN_b8g8r8x8 #else # define PIXMAN_BE_r8g8b8 PIXMAN_b8g8r8 # define PIXMAN_BE_x8r8g8b8 PIXMAN_b8g8r8x8 # define PIXMAN_BE_a8r8g8b8 PIXMAN_b8g8r8a8 # define PIXMAN_BE_b8g8r8x8 PIXMAN_x8r8g8b8 # define PIXMAN_BE_b8g8r8a8 PIXMAN_a8r8g8b8 # define PIXMAN_BE_r8g8b8x8 PIXMAN_x8b8g8r8 # define PIXMAN_BE_r8g8b8a8 PIXMAN_a8b8g8r8 # define PIXMAN_BE_x8b8g8r8 PIXMAN_r8g8b8x8 # define PIXMAN_BE_a8b8g8r8 PIXMAN_r8g8b8a8 # define PIXMAN_LE_x8r8g8b8 PIXMAN_x8r8g8b8 #endif Exactly what Mesa did as well. My personal opinion is that formats in drm_fourcc.h should be independent of the CPU byte order and the function drm_mode_legacy_fb_format() and drivers depending on that incorrect assumption be fixed instead. The problem is this isn't a kernel-internal thing any more. With the addition of the ADDFB2 ioctl the fourcc codes became part of the kernel/userspace abi ... I know and that's exactly the reason I'm going to object those changes. The kernel/userspace abi is fixed and changing it like this could potentially break drivers I'm the co-maintainer of. So that whole approach is a clear NAK from my side. If you find a driver or userspace which doesn't use the formats as defined in the comments of drm_fourcc.h the fix the driver instead of trying to adjust the common header to broken behavior. Cause the later will clearly cause problems with drivers who correctly implemented the interface. Regards, Christian. cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ amd-gfx mailing list amd-...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC 3/6] drm: Plane YCbCr to RGB conversion related properties
On Fri, Apr 21, 2017 at 03:53:42PM +0100, Brian Starkey wrote:
> Hi,
>
> Thanks for picking this up Jyri.
>
> On Fri, Apr 21, 2017 at 04:52:03PM +0300, Ville Syrjälä wrote:
> >On Fri, Apr 21, 2017 at 04:39:16PM +0300, Jyri Sarha wrote:
> >> On 04/21/17 14:17, Ville Syrjälä wrote:
> >> >> +static char *ycbcr_to_rgb_mode_name[] = {
> >> >> + [DRM_PLANE_YCBCR_BT601_LIM_TO_RGB_BT601_FULL] =
> >> >> + "YCbCr BT.601 limited range TO RGB BT.601 full range",
> >> >> + [DRM_PLANE_YCBCR_BT601_FULL_TO_RGB_BT601_FULL] =
> >> >> + "YCbCr BT.601 full range TO RGB BT.601 full range",
> >> >> + [DRM_PLANE_YCBCR_BT709_LIM_TO_RGB_BT709_FULL] =
> >> >> + "YCbCr BT.709 limited range TO RGB BT.709 full range",
> >> >> + [DRM_PLANE_YCBCR_BT2020_LIM_TO_RGB_BT2020_FULL] =
> >> >> + "YCbCr BT.2020 limited range TO RGB BT.2020 full range",
> >> >> + [DRM_PLANE_YCBCR_BT601_LIM_TO_RGB_BT709_FULL] =
> >> >> + "YCbCr BT.601 limited range TO RGB BT.709 full range",
> >> > We probably don't want to conflate the YCbCr->RGB part with the
> >> > colorspace
> >> > conversion because the YCbCr->RGB part should be performed on gamma
> >> > encoded
> >> > data and the colorspace conversion on linear data. So we need a degamma
> >> > stage in between. At least that seemed to be the general concencus after
> >> > the last round of mails on this topic.
> >> >
>
> I thought the conclusion of the last round was that on some hardware
> this would be conflated as a conscious choice. If the HW doesn't have
> the required degamma->csc->gamma stages, and the implementor/user
> doesn't care about being a little incorrect, then it can all be
> described in this single property.
I was proposing the single prop approach initially, but now I think it
might just lead to more confusion. So a dedicated property for each stage
is the clearer design I think. We do lose potentially a bit of
discoverability when not all combinations are supported, but we have
that problem in many other places as well, so not a big deal I think.
>
> If there is more capable hardware with the additional stages, then
> they should expose additional properties (in pipeline order):
>
> YCBCR_TO_RGB_*:
>Does YCbCr->RGB conversion on non-linear YCbCr data,
>only the enum values which don't have a CSC are exposed.
Not sure what you mean but that last part.
>
> DEGAMMA:
>Does the non-linear to linear conversion on the RGB data output from
>the YCBCR_TO_RGB stage.
>
> RGB_TO_RGB_*:
>Similar set of properties to YCBCR_TO_RGB_*, allowing RGB->RGB CSC
>on the linear data.
We may want to call this just CTM to match the matching crtc prop.
>
> GAMMA:
>Convert the CSC'd RGB data back in to non-linear for blending (if
>blending is to be done with non-linear data).
>
> Drivers can expose as many or as few of the above properties as their
> hardware supports.
>
> >>
> >> I do not really have the expertise to argue with that. I merely copied
> >> the idea from the mail thread I referred to in the cover letter.
> >> However, there are several display HWs out there that do not have all
> >> bolts and knobs to make the color-space conversion in exactly the ideal
> >> order, omap DSS being one of them.
> >
> >Yeah. Intel hardware is in the same boat for the time being. On current
> >hw I think we can only really expose the YCbCr->RGB and degamma stages.
> >
> >On some limited set of platforms we could expose a blob as well, and I
> >suppose it would then be possible to use it for color space conversion
> >if you ignore gamma and/or only deal with linear RGB data. But it's such
> >a limited subset of hardware for us that I don't think I'm interested
> >in exposing it.
> >
>
> I'm not sure the custom blob is worth having either. It can easily be
> added later if we decide we want it after all.
>
> Thanks,
> -Brian
>
> >In the future we should be getting a more fully fleged pipeline.
> >
> >>
> >> > After staring at the v4l docs on this stuff I kinda like their
> >> > "encoding" terminology to describe the YCbCr->RGB part, so I'm now a
> >> > little partial to calling the prop something like YCBCR_ENCODING. OTOH
> >>
> >> I guess this property should be called YCBCR_DECODING.
> >
> >Only if you think of it as a verb.
> >
> >>
> >> > if we want to expose the raw matrix as a blob then maybe calling it a
> >> > CSC might be better. Not sure there's much point in exposing it though.
> >>
> >> In my first version it was called just CSC, but then I wanted to make it
> >> explicit what this CSC was used for to avoid mixing the YCbCr decoding
> >> matrix with YCbCr encoding matrix. At least on OMAP DSS we have pieces
> >> of HW that can do only one or the other, e.g. the offset calculations
> >> are supported only to one direction.
> >
> >Are you planning to do RGB->YCbCr conversion in the plane as well? I
> >think we'll be only doing that at crtc/connector level.
>
Re: [PULL] drm-misc-next-fixes
On 21 April 2017 at 03:20, Daniel Vetter wrote: >> - Rename dma_buf_ops->kmap_* to avoid naming collision (Logan) > > This one touches v4l and ion and is acked by the corresponding > maintainers (but Sumit forgot to record that when applying the patch, > and Sean didn't highlight it in the summary). > Hmm - I assumed that the mbox I downloaded (after all the acks got registered in patchworks) would've had the Acks? Didn't cross-check, my bad. Will of course take care from next time on. > Sean, should we augment the template that cross-subsystem stuff > (outside of what's on-topic for drm-misc) needs to be highlighted > specifically in the pull summary? > > Off for vacation for real now. > > Cheers, Daniel > Best, Sumit. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv4 00/12] Ion cleanup in preparation for moving out of staging
Hi Laura, Thanks much for this series! On 18 April 2017 at 23:57, Laura Abbott wrote: > Hi, > > This is v4 of the series to cleanup to Ion. Greg took some of the patches > that weren't CMA related already. There was a minor bisectability problem > with the CMA APIs so this is a new version to address that. I also > addressed some minor comments on the patch to collapse header files. For the series, please feel free to apply my Acked-by: Sumit Semwal > > Thanks, > Laura > > Laura Abbott (12): > cma: Store a name in the cma structure > cma: Introduce cma_for_each_area > staging: android: ion: Use CMA APIs directly > staging: android: ion: Stop butchering the DMA address > staging: android: ion: Break the ABI in the name of forward progress > staging: android: ion: Get rid of ion_phys_addr_t > staging: android: ion: Collapse internal header files > staging: android: ion: Rework heap registration/enumeration > staging: android: ion: Drop ion_map_kernel interface > staging: android: ion: Remove ion_handle and ion_client > staging: android: ion: Set query return value > staging/android: Update Ion TODO list > > arch/powerpc/kvm/book3s_hv_builtin.c| 3 +- > drivers/base/dma-contiguous.c | 5 +- > drivers/staging/android/TODO| 21 +- > drivers/staging/android/ion/Kconfig | 32 + > drivers/staging/android/ion/Makefile| 11 +- > drivers/staging/android/ion/compat_ion.c| 152 - > drivers/staging/android/ion/compat_ion.h| 29 - > drivers/staging/android/ion/ion-ioctl.c | 55 +- > drivers/staging/android/ion/ion.c | 812 > ++-- > drivers/staging/android/ion/ion.h | 386 --- > drivers/staging/android/ion/ion_carveout_heap.c | 21 +- > drivers/staging/android/ion/ion_chunk_heap.c| 16 +- > drivers/staging/android/ion/ion_cma_heap.c | 120 ++-- > drivers/staging/android/ion/ion_heap.c | 68 -- > drivers/staging/android/ion/ion_page_pool.c | 3 +- > drivers/staging/android/ion/ion_priv.h | 453 - > drivers/staging/android/ion/ion_system_heap.c | 39 +- > drivers/staging/android/uapi/ion.h | 36 +- > include/linux/cma.h | 6 +- > mm/cma.c| 31 +- > mm/cma.h| 1 + > mm/cma_debug.c | 2 +- > 22 files changed, 524 insertions(+), 1778 deletions(-) > delete mode 100644 drivers/staging/android/ion/compat_ion.c > delete mode 100644 drivers/staging/android/ion/compat_ion.h > delete mode 100644 drivers/staging/android/ion/ion_priv.h > > -- > 2.7.4 > -- Thanks and regards, Sumit Semwal Linaro Mobile Group - Kernel Team Lead Linaro.org │ Open source software for ARM SoCs ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC 3/6] drm: Plane YCbCr to RGB conversion related properties
On Fri, Apr 21, 2017 at 06:21:48PM +0300, Ville Syrjälä wrote:
On Fri, Apr 21, 2017 at 03:53:42PM +0100, Brian Starkey wrote:
Hi,
Thanks for picking this up Jyri.
On Fri, Apr 21, 2017 at 04:52:03PM +0300, Ville Syrjälä wrote:
>On Fri, Apr 21, 2017 at 04:39:16PM +0300, Jyri Sarha wrote:
>> On 04/21/17 14:17, Ville Syrjälä wrote:
>> >> +static char *ycbcr_to_rgb_mode_name[] = {
>> >> + [DRM_PLANE_YCBCR_BT601_LIM_TO_RGB_BT601_FULL] =
>> >> + "YCbCr BT.601 limited range TO RGB BT.601 full range",
>> >> + [DRM_PLANE_YCBCR_BT601_FULL_TO_RGB_BT601_FULL] =
>> >> + "YCbCr BT.601 full range TO RGB BT.601 full range",
>> >> + [DRM_PLANE_YCBCR_BT709_LIM_TO_RGB_BT709_FULL] =
>> >> + "YCbCr BT.709 limited range TO RGB BT.709 full range",
>> >> + [DRM_PLANE_YCBCR_BT2020_LIM_TO_RGB_BT2020_FULL] =
>> >> + "YCbCr BT.2020 limited range TO RGB BT.2020 full range",
>> >> + [DRM_PLANE_YCBCR_BT601_LIM_TO_RGB_BT709_FULL] =
>> >> + "YCbCr BT.601 limited range TO RGB BT.709 full range",
>> > We probably don't want to conflate the YCbCr->RGB part with the colorspace
>> > conversion because the YCbCr->RGB part should be performed on gamma encoded
>> > data and the colorspace conversion on linear data. So we need a degamma
>> > stage in between. At least that seemed to be the general concencus after
>> > the last round of mails on this topic.
>> >
I thought the conclusion of the last round was that on some hardware
this would be conflated as a conscious choice. If the HW doesn't have
the required degamma->csc->gamma stages, and the implementor/user
doesn't care about being a little incorrect, then it can all be
described in this single property.
I was proposing the single prop approach initially, but now I think it
might just lead to more confusion. So a dedicated property for each stage
is the clearer design I think. We do lose potentially a bit of
discoverability when not all combinations are supported, but we have
that problem in many other places as well, so not a big deal I think.
Yeah you lose discoverability, but do you also lose the ability to do
the non-perfect, single-stage conversions?
For HW that only has a matrix, is the driver expected to combine all
of the separated stages down into a single matrix? Or it wouldn't
expose the other properties, only a matrix, and userspace has to come
up with a blob that does the (approximate) right thing?
If there is more capable hardware with the additional stages, then
they should expose additional properties (in pipeline order):
YCBCR_TO_RGB_*:
Does YCbCr->RGB conversion on non-linear YCbCr data,
only the enum values which don't have a CSC are exposed.
Not sure what you mean but that last part.
Just that the enum list should only contain things that are:
YCbCr BT.601 -> RGB BT.601
YCbCr BT.709 -> RGB BT.709
YcbCr BT.2020 -> RGB BT.2020
and not a those including a color space change, e.g.:
YCbCr BT.601 -> RGB BT.709
because an RGB BT.601 -> RGB BT.709 conversion can be performed
later with the RGB_TO_RGB/CTM/whatever property.
DEGAMMA:
Does the non-linear to linear conversion on the RGB data output from
the YCBCR_TO_RGB stage.
RGB_TO_RGB_*:
Similar set of properties to YCBCR_TO_RGB_*, allowing RGB->RGB CSC
on the linear data.
We may want to call this just CTM to match the matching crtc prop.
Good call.
-Brian
GAMMA:
Convert the CSC'd RGB data back in to non-linear for blending (if
blending is to be done with non-linear data).
Drivers can expose as many or as few of the above properties as their
hardware supports.
>>
>> I do not really have the expertise to argue with that. I merely copied
>> the idea from the mail thread I referred to in the cover letter.
>> However, there are several display HWs out there that do not have all
>> bolts and knobs to make the color-space conversion in exactly the ideal
>> order, omap DSS being one of them.
>
>Yeah. Intel hardware is in the same boat for the time being. On current
>hw I think we can only really expose the YCbCr->RGB and degamma stages.
>
>On some limited set of platforms we could expose a blob as well, and I
>suppose it would then be possible to use it for color space conversion
>if you ignore gamma and/or only deal with linear RGB data. But it's such
>a limited subset of hardware for us that I don't think I'm interested
>in exposing it.
>
I'm not sure the custom blob is worth having either. It can easily be
added later if we decide we want it after all.
Thanks,
-Brian
>In the future we should be getting a more fully fleged pipeline.
>
>>
>> > After staring at the v4l docs on this stuff I kinda like their
>> > "encoding" terminology to describe the YCbCr->RGB part, so I'm now a
>> > little partial to calling the prop something like YCBCR_ENCODING. OTOH
>>
>> I guess this property should be called YCBCR_DECODING.
>
>Only if you think of it as a verb.
>
>>
>> > if we want to expose the raw matri
Re: [PATCH] drm/edid: Add 10 bpc quirk for LGD 764 panel in HP zBook 17 G2
On 2017-04-21 11:05 AM, Mario Kleiner wrote:
The builtin eDP panel in the HP zBook 17 G2 supports 10 bpc,
as advertised by the Laptops product specs and verified via
injecting a fixed edid + photometer measurements, but edid
reports unknown depth, so drivers fall back to 6 bpc.
Add a quirk to get the full 10 bpc.
Cc: sta...@vger.kernel.org
Signed-off-by: Mario Kleiner
Acked-by: Harry Wentland
Harry
---
drivers/gpu/drm/drm_edid.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index fad3d44..2e55599 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -80,6 +80,8 @@
#define EDID_QUIRK_FORCE_12BPC (1 << 9)
/* Force 6bpc */
#define EDID_QUIRK_FORCE_6BPC (1 << 10)
+/* Force 10bpc */
+#define EDID_QUIRK_FORCE_10BPC (1 << 11)
struct detailed_mode_closure {
struct drm_connector *connector;
@@ -122,6 +124,9 @@ static const struct edid_quirk {
{ "FCM", 13600, EDID_QUIRK_PREFER_LARGE_75 |
EDID_QUIRK_DETAILED_IN_CM },
+ /* LGD panel of HP zBook 17 G2, eDP 10 bpc, but reports unknown bpc */
+ { "LGD", 764, EDID_QUIRK_FORCE_10BPC },
+
/* LG Philips LCD LP154W01-A5 */
{ "LPL", 0, EDID_QUIRK_DETAILED_USE_MAXIMUM_SIZE },
{ "LPL", 0x2a00, EDID_QUIRK_DETAILED_USE_MAXIMUM_SIZE },
@@ -4244,6 +4249,9 @@ int drm_add_edid_modes(struct drm_connector *connector,
struct edid *edid)
if (quirks & EDID_QUIRK_FORCE_8BPC)
connector->display_info.bpc = 8;
+ if (quirks & EDID_QUIRK_FORCE_10BPC)
+ connector->display_info.bpc = 10;
+
if (quirks & EDID_QUIRK_FORCE_12BPC)
connector->display_info.bpc = 12;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/amd/display: Fix race between vblank irq and pageflip irq.
Since DC now uses CRTC_VERTICAL_INTERRUPT0 as VBLANK irq trigger
and vblank interrupts actually happen earliest at start of vblank,
instead of a bit before vblank, we no longer need some of the
fudging logic to deal with too early vblank irq handling (grep for
lb_vblank_lead_lines). This itself fixes a pageflip scheduling
bug in DC, caused by uninitialized use of lb_vblank_lead_lines,
with a wrong startup value of 0. Thanks to the new vblank irq
trigger this value of zero is now actually correct for DC :).
A new problem is that vblank irq's race against pflip irq's,
and as both can fire at first line of vblank, it is no longer
guaranteed that vblank irq handling (therefore -> drm_handle_vblank()
-> drm_update_vblank_count()) executes before pflip irq handling
for a given vblank interval when a pageflip completes. Therefore
the vblank count and timestamps emitted to user-space as part of
the pageflip completion event will be often stale and cause new
timestamping and swap scheduling errors in user-space.
This was observed with large frequency on R9 380 Tonga Pro.
Fix this by enforcing a vblank count+timestamp update right
before emitting the pageflip completion event from the pflip
irq handler. The logic in core drm_update_vblank_count() makes
sure that no redundant or conflicting updates happen, iow. the
call turns into a no-op if it wasn't needed for that vblank,
burning a few microseconds of cpu time though.
Successfully tested on AMD R9 380 "Tonga Pro" (VI/DCE 10)
with DC enabled on the current DC staging branch. Independent
measurement of pageflip completion timing with special hardware
measurement equipment now confirms correct pageflip timestamps
and counts in the pageflip completion events.
Note that there is another unresolved pageflip bug present in current
dc staging, which causes pageflips to complete one vblank too early
when the pageflip ioctl gets called while in vblank. Something seems
to be amiss in the way amdgpu_dm_do_flip() handles 'target_vblank',
or how amdgpu_dm_atomic_commit_tail() computes 'target' for calling
amdgpu_dm_do_flip().
Signed-off-by: Mario Kleiner
Cc: Harry Wentland
Cc: Andrey Grodzovsky
Cc: Alex Deucher
Cc: Michel Dänzer
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 794362e..0d77b0a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -208,6 +208,9 @@ static void dm_pflip_high_irq(void *interrupt_params)
if (amdgpu_crtc->event
&& amdgpu_crtc->event->event.base.type
== DRM_EVENT_FLIP_COMPLETE) {
+ /* Update to correct count/ts if racing with vblank irq */
+ drm_accurate_vblank_count(&amdgpu_crtc->base);
+
drm_crtc_send_vblank_event(&amdgpu_crtc->base,
amdgpu_crtc->event);
/* page flip completed. clean up */
amdgpu_crtc->event = NULL;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/amd/display: Prevent premature pageflip when comitting in vblank.
Make sure we do not program a hw pageflip inside vblank 'n' iff the atomic flip is comitted while inside the same vblank 'n'. We must defer such a flip by one refresh cycle to vblank 'n+1'. Without this, pageflips programmed via X11 GLX_OML_sync_control extensions glXSwapBuffersMscOML(..., target_msc, ...); call and/or via DRI3/Present PresentPixmap(..., target_msc, ...); request will complete one vblank too early whenever target_msc > current_msc + 1, ie. more than 1 vblank in the future. In such a case, the call of the pageflip ioctl() would be triggered by a queued drmWaitVblank() vblank event, which itself gets dispatched inside the vblank one frame before the target_msc vblank. Testing with this patch does no longer show any problems with OML_sync_control swap scheduling or flip completion timestamps. Tested on R9 380 Tonga. Signed-off-by: Mario Kleiner Cc: Harry Wentland Cc: Alex Deucher Cc: Michel Dänzer --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c index 086a842..19be2d9 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c @@ -2460,6 +2460,9 @@ static void amdgpu_dm_do_flip( struct amdgpu_device *adev = crtc->dev->dev_private; bool async_flip = (acrtc->flip_flags & DRM_MODE_PAGE_FLIP_ASYNC) != 0; + /* Prepare wait for target vblank early - before the fence-waits */ + target_vblank = target - drm_crtc_vblank_count(crtc) + + amdgpu_get_vblank_counter_kms(crtc->dev, acrtc->crtc_id); /*TODO This might fail and hence better not used, wait * explicitly on fences instead @@ -2478,13 +2481,9 @@ static void amdgpu_dm_do_flip( amdgpu_bo_unreserve(abo); - /* Wait for target vblank */ /* Wait until we're out of the vertical blank period before the one * targeted by the flip */ - target_vblank = target - drm_crtc_vblank_count(crtc) + - amdgpu_get_vblank_counter_kms(crtc->dev, acrtc->crtc_id); - while ((acrtc->enabled && (amdgpu_get_crtc_scanoutpos(adev->ddev, acrtc->crtc_id, 0, &vpos, &hpos, NULL, NULL, @@ -2763,7 +2762,7 @@ void amdgpu_dm_atomic_commit_tail( amdgpu_dm_do_flip( crtc, fb, - drm_crtc_vblank_count(crtc)); + drm_crtc_vblank_count(crtc) + 1); wait_for_vblank = acrtc->flip_flags & DRM_MODE_PAGE_FLIP_ASYNC ? -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Pageflip fixes for the amd dal/dc staging tree.
Hi These two patches were written and tested against Harry's hwentland amd-staging-dc-drm-next branch from a few days ago. Not sure if that is the right one to base dal/dc patches against, but it looks recent and active enough? They fix pageflip scheduling to always flip at the right target vblank and pageflip completion events to send out the correct vblank count and timestamp of flip completion. Successfully tested on AMD R9 380 Tonga Pro - VI/DCE-10. After applying these, the dal staging branch performs nicely with my tests :) I've also tested amdgpu-pro 17.10.2 on the same setup against Linux 4.4/4.8 and found a couple of similar bugs and fixes, but that in a separate mail. -mario ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC 3/6] drm: Plane YCbCr to RGB conversion related properties
On Fri, Apr 21, 2017 at 04:34:00PM +0100, Brian Starkey wrote:
> On Fri, Apr 21, 2017 at 06:21:48PM +0300, Ville Syrjälä wrote:
> >On Fri, Apr 21, 2017 at 03:53:42PM +0100, Brian Starkey wrote:
> >> Hi,
> >>
> >> Thanks for picking this up Jyri.
> >>
> >> On Fri, Apr 21, 2017 at 04:52:03PM +0300, Ville Syrjälä wrote:
> >> >On Fri, Apr 21, 2017 at 04:39:16PM +0300, Jyri Sarha wrote:
> >> >> On 04/21/17 14:17, Ville Syrjälä wrote:
> >> >> >> +static char *ycbcr_to_rgb_mode_name[] = {
> >> >> >> +[DRM_PLANE_YCBCR_BT601_LIM_TO_RGB_BT601_FULL] =
> >> >> >> +"YCbCr BT.601 limited range TO RGB BT.601 full range",
> >> >> >> +[DRM_PLANE_YCBCR_BT601_FULL_TO_RGB_BT601_FULL] =
> >> >> >> +"YCbCr BT.601 full range TO RGB BT.601 full range",
> >> >> >> +[DRM_PLANE_YCBCR_BT709_LIM_TO_RGB_BT709_FULL] =
> >> >> >> +"YCbCr BT.709 limited range TO RGB BT.709 full range",
> >> >> >> +[DRM_PLANE_YCBCR_BT2020_LIM_TO_RGB_BT2020_FULL] =
> >> >> >> +"YCbCr BT.2020 limited range TO RGB BT.2020 full range",
> >> >> >> +[DRM_PLANE_YCBCR_BT601_LIM_TO_RGB_BT709_FULL] =
> >> >> >> +"YCbCr BT.601 limited range TO RGB BT.709 full range",
> >> >> > We probably don't want to conflate the YCbCr->RGB part with the
> >> >> > colorspace
> >> >> > conversion because the YCbCr->RGB part should be performed on gamma
> >> >> > encoded
> >> >> > data and the colorspace conversion on linear data. So we need a
> >> >> > degamma
> >> >> > stage in between. At least that seemed to be the general concencus
> >> >> > after
> >> >> > the last round of mails on this topic.
> >> >> >
> >>
> >> I thought the conclusion of the last round was that on some hardware
> >> this would be conflated as a conscious choice. If the HW doesn't have
> >> the required degamma->csc->gamma stages, and the implementor/user
> >> doesn't care about being a little incorrect, then it can all be
> >> described in this single property.
> >
> >I was proposing the single prop approach initially, but now I think it
> >might just lead to more confusion. So a dedicated property for each stage
> >is the clearer design I think. We do lose potentially a bit of
> >discoverability when not all combinations are supported, but we have
> >that problem in many other places as well, so not a big deal I think.
> >
>
> Yeah you lose discoverability, but do you also lose the ability to do
> the non-perfect, single-stage conversions?
Not sure why one vs. multiple props should matter here. Either you
accept the less than perfect pipeline or you don't. Whether you ask it
via one of multiple props doesn't seem all that different to me.
>
> For HW that only has a matrix, is the driver expected to combine all
> of the separated stages down into a single matrix? Or it wouldn't
> expose the other properties, only a matrix, and userspace has to come
> up with a blob that does the (approximate) right thing?
If you're not happy with exposing just one or the other, then I guess
you would expose both but indicate that there's no degamma in between
and userspace can then choose whether it's happy with that solution or
or not.
>
> >>
> >> If there is more capable hardware with the additional stages, then
> >> they should expose additional properties (in pipeline order):
> >>
> >> YCBCR_TO_RGB_*:
> >>Does YCbCr->RGB conversion on non-linear YCbCr data,
> >>only the enum values which don't have a CSC are exposed.
> >
> >Not sure what you mean but that last part.
> >
>
> Just that the enum list should only contain things that are:
> YCbCr BT.601 -> RGB BT.601
> YCbCr BT.709 -> RGB BT.709
> YcbCr BT.2020 -> RGB BT.2020
>
> and not a those including a color space change, e.g.:
> YCbCr BT.601 -> RGB BT.709
Right. We probably shouldn't even have the "BT.whatever" on both sides
since it's not really a colorspace, just the encoding, and once you
decoded the YCbCr into RGB it's just RGB. We could actually just define
the enum values as "BT.601","BT.709" etc.
>
> because an RGB BT.601 -> RGB BT.709 conversion can be performed
> later with the RGB_TO_RGB/CTM/whatever property.
>
> >>
> >> DEGAMMA:
> >>Does the non-linear to linear conversion on the RGB data output from
> >>the YCBCR_TO_RGB stage.
> >>
> >> RGB_TO_RGB_*:
> >>Similar set of properties to YCBCR_TO_RGB_*, allowing RGB->RGB CSC
> >>on the linear data.
> >
> >We may want to call this just CTM to match the matching crtc prop.
> >
>
> Good call.
>
> -Brian
>
> >>
> >> GAMMA:
> >>Convert the CSC'd RGB data back in to non-linear for blending (if
> >>blending is to be done with non-linear data).
> >>
> >> Drivers can expose as many or as few of the above properties as their
> >> hardware supports.
> >>
> >> >>
> >> >> I do not really have the expertise to argue with that. I merely copied
> >> >> the idea from the mail thread I referred to in the cover letter.
> >> >> However, there are several display HWs out there that do not have all
>
[PATCH v3 1/5] nouveau_hwmon: Add config for all sensors and their settings
This is a preparation for the next patches. It just adds the sensors with
their possible configurable settings and then fills the struct
hwmon_channel_info
with all this information.
Signed-off-by: Oscar Salvador
---
drivers/gpu/drm/nouveau/nouveau_hwmon.c | 72 +
1 file changed, 72 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
index 23b1670..24b40c5 100644
--- a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
@@ -692,6 +692,78 @@ static const struct attribute_group hwmon_power_attrgroup
= {
static const struct attribute_group hwmon_power_caps_attrgroup = {
.attrs = hwmon_power_caps_attributes,
};
+
+static const u32 nouveau_config_chip[] = {
+ HWMON_C_UPDATE_INTERVAL,
+ 0
+};
+
+static const u32 nouveau_config_in[] = {
+ HWMON_I_INPUT | HWMON_I_MIN | HWMON_I_MAX | HWMON_I_LABEL,
+ 0
+};
+
+static const u32 nouveau_config_temp[] = {
+ HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_MAX_HYST |
+ HWMON_T_CRIT | HWMON_T_CRIT_HYST | HWMON_T_EMERGENCY |
+ HWMON_T_EMERGENCY_HYST,
+ 0
+};
+
+static const u32 nouveau_config_fan[] = {
+ HWMON_F_INPUT,
+ 0
+};
+
+static const u32 nouveau_config_pwm[] = {
+ HWMON_PWM_INPUT | HWMON_PWM_ENABLE,
+ 0
+};
+
+static const u32 nouveau_config_power[] = {
+ HWMON_P_INPUT | HWMON_P_CAP_MAX | HWMON_P_CRIT,
+ 0
+};
+
+static const struct hwmon_channel_info nouveau_chip = {
+ .type = hwmon_chip,
+ .config = nouveau_config_chip,
+};
+
+static const struct hwmon_channel_info nouveau_temp = {
+ .type = hwmon_temp,
+ .config = nouveau_config_temp,
+};
+
+static const struct hwmon_channel_info nouveau_fan = {
+ .type = hwmon_fan,
+ .config = nouveau_config_fan,
+};
+
+static const struct hwmon_channel_info nouveau_in = {
+ .type = hwmon_in,
+ .config = nouveau_config_in,
+};
+
+static const struct hwmon_channel_info nouveau_pwm = {
+ .type = hwmon_pwm,
+ .config = nouveau_config_pwm,
+};
+
+static const struct hwmon_channel_info nouveau_power = {
+ .type = hwmon_power,
+ .config = nouveau_config_power,
+};
+
+static const struct hwmon_channel_info *nouveau_info[] = {
+ &nouveau_chip,
+ &nouveau_temp,
+ &nouveau_fan,
+ &nouveau_in,
+ &nouveau_pwm,
+ &nouveau_power,
+ NULL
+};
#endif
int
--
2.1.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/5] nouveau_hwmon: Add nouveau_hwmon_ops structure with .is_visible/.read_string
This patch introduces the nouveau_hwmon_ops structure, sets up
.is_visible and .read_string operations and adds all the functions
for these operations.
This is also a preparation for the next patches, where most of the
work is being done.
This code doesn't interacture with the old one.
It's just to make easier the review of all patches.
Signed-off-by: Oscar Salvador
---
drivers/gpu/drm/nouveau/nouveau_hwmon.c | 171
1 file changed, 171 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
index 24b40c5..6e9bcfe 100644
--- a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
@@ -764,6 +764,177 @@ static const struct hwmon_channel_info *nouveau_info[] = {
&nouveau_power,
NULL
};
+
+static umode_t
+nouveau_chip_is_visible(const void *data, u32 attr, int channel)
+{
+ switch (attr) {
+ case hwmon_chip_update_interval:
+ return 0444;
+ default:
+ return 0;
+ }
+}
+
+static umode_t
+nouveau_power_is_visible(const void *data, u32 attr, int channel)
+{
+ struct nouveau_drm *drm = nouveau_drm((struct drm_device *)data);
+ struct nvkm_iccsense *iccsense = nvxx_iccsense(&drm->client.device);
+
+ if (!iccsense)
+ return 0;
+
+ switch (attr) {
+ case hwmon_power_input:
+ if (iccsense->data_valid &&
+ !list_empty(&iccsense->rails))
+ return 0444;
+ return 0;
+ case hwmon_power_max:
+ if (iccsense->power_w_max)
+ return 0444;
+ return 0;
+ case hwmon_power_crit:
+ if (iccsense->power_w_crit)
+ return 0444;
+ return 0;
+ default:
+ return 0;
+ }
+}
+
+static umode_t
+nouveau_temp_is_visible(const void *data, u32 attr, int channel)
+{
+ struct nouveau_drm *drm = nouveau_drm((struct drm_device *)data);
+ struct nvkm_therm *therm = nvxx_therm(&drm->client.device);
+
+ if (therm &&
+ therm->attr_get &&
+ therm->attr_set &&
+ nvkm_therm_temp_get(therm) < 0)
+ return 0;
+
+ switch (attr) {
+ case hwmon_temp_input:
+ case hwmon_temp_max:
+ case hwmon_temp_max_hyst:
+ case hwmon_temp_crit:
+ case hwmon_temp_crit_hyst:
+ case hwmon_temp_emergency:
+ case hwmon_temp_emergency_hyst:
+ return 0444;
+ default:
+ return 0;
+ }
+}
+
+static umode_t
+nouveau_pwm_is_visible(const void *data, u32 attr, int channel)
+{
+ struct nouveau_drm *drm = nouveau_drm((struct drm_device *)data);
+ struct nvkm_therm *therm = nvxx_therm(&drm->client.device);
+
+ if (therm &&
+ therm->attr_get &&
+ therm->fan_get &&
+ therm->fan_get(therm) < 0)
+ return 0;
+
+ switch (attr) {
+ case hwmon_pwm_enable:
+ case hwmon_pwm_input:
+ return 0644;
+ default:
+ return 0;
+ }
+}
+
+static umode_t
+nouveau_input_is_visible(const void *data, u32 attr, int channel)
+{
+ struct nouveau_drm *drm = nouveau_drm((struct drm_device *)data);
+ struct nvkm_volt *volt = nvxx_volt(&drm->client.device);
+
+ if (!volt || nvkm_volt_get(volt) < 0)
+ return 0;
+
+ switch (attr) {
+ case hwmon_in_input:
+ case hwmon_in_label:
+ case hwmon_in_min:
+ case hwmon_in_max:
+ return 0444;
+ default:
+ return 0;
+ }
+}
+
+static umode_t
+nouveau_fan_is_visible(const void *data, u32 attr, int channel)
+{
+ struct nouveau_drm *drm = nouveau_drm((struct drm_device *)data);
+ struct nvkm_therm *therm = nvxx_therm(&drm->client.device);
+
+ if (!therm || !therm->attr_get || nvkm_therm_fan_sense(therm) < 0)
+ return 0;
+
+ switch (attr) {
+ case hwmon_fan_input:
+ return 0444;
+ default:
+ return 0;
+ }
+}
+
+static umode_t
+nouveau_is_visible(const void *data, enum hwmon_sensor_types type, u32 attr,
+ int channel)
+{
+ switch (type) {
+ case hwmon_chip:
+ return nouveau_chip_is_visible(data, attr, channel);
+ case hwmon_temp:
+ return nouveau_temp_is_visible(data, attr, channel);
+ case hwmon_fan:
+ return nouveau_fan_is_visible(data, attr, channel);
+ case hwmon_in:
+ return nouveau_input_is_visible(data, attr, channel);
+ case hwmon_pwm:
+ return nouveau_pwm_is_visible(data, attr, channel);
+ case hwmon_power:
+ return nouveau_power_is_visible(data, attr, channel);
+ default:
+
[PATCH v3 0/5] replace hwmon_device_register for hwmon_device_register_with_info
Hi, this is version v3 with some fix-ups: Versions: v1 -> v2: * Keep temp attrs as read only v2 -> v3: * Code fix-ups: struct and string as const and add return within switch due to fallthrough * Add Signed-off-by to all commits This patchseries replaces the deprecated hwmon_device_register function with the new one hwmon_device_register_with_info. It also does some cleanup. Here is the list of patches and what they do: 1/ Adds config structures for all sensors and their possible settings. This patch and the next one are just preparing the code for what it comes. 2/ Now everything goes through nouveua_hwmon_ops. There we set up wich functions will be called for read/write and for checking if an attribute should be created or not. In this patch we just add .is_visible/.read_string operations. Here we sill don't interactuate with the old code. 3/ Most of the work is being done here. We remove the old code and replace it with the new one related to the new api. Here we introduce the .write and .read operations, and create all functions regarding these operations. 4/ We add support for special attributes like *_auto_point*. 5/ Cleanup: Change permissions to numeric and add me to the author Oscar Salvador (5): nouveau_hwmon: Add config for all sensors and their settings nouveau_hwmon: Add nouveau_hwmon_ops structure with .is_visible/.read_string nouveau_hwmon: Remove old code, add .write/.read operations nouveau_hwmon: Add support for auto_point attributes nouveau_hwmon: Change permissions to numeric drivers/gpu/drm/nouveau/nouveau_hwmon.c | 955 +--- 1 file changed, 501 insertions(+), 454 deletions(-) -- 2.1.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/5] nouveau_hwmon: Remove old code, add .write/.read operations
This patch removes old code related to the old api and transforms the
functions for the new api. It also adds the .write and .read operations.
Signed-off-by: Oscar Salvador
---
drivers/gpu/drm/nouveau/nouveau_hwmon.c | 722 +++-
1 file changed, 249 insertions(+), 473 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
index 6e9bcfe..57296cb 100644
--- a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
@@ -38,21 +38,17 @@
#include
#if defined(CONFIG_HWMON) || (defined(MODULE) && defined(CONFIG_HWMON_MODULE))
-static ssize_t
-nouveau_hwmon_show_temp(struct device *d, struct device_attribute *a, char
*buf)
+static int
+nouveau_hwmon_show_temp(struct nouveau_drm *drm)
{
- struct drm_device *dev = dev_get_drvdata(d);
- struct nouveau_drm *drm = nouveau_drm(dev);
struct nvkm_therm *therm = nvxx_therm(&drm->client.device);
int temp = nvkm_therm_temp_get(therm);
if (temp < 0)
return temp;
- return snprintf(buf, PAGE_SIZE, "%d\n", temp * 1000);
+ return (temp * 1000);
}
-static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, nouveau_hwmon_show_temp,
- NULL, 0);
static ssize_t
nouveau_hwmon_show_temp1_auto_point1_pwm(struct device *d,
@@ -129,312 +125,100 @@ static SENSOR_DEVICE_ATTR(temp1_auto_point1_temp_hyst,
S_IRUGO | S_IWUSR,
nouveau_hwmon_temp1_auto_point1_temp_hyst,
nouveau_hwmon_set_temp1_auto_point1_temp_hyst, 0);
-static ssize_t
-nouveau_hwmon_max_temp(struct device *d, struct device_attribute *a, char *buf)
-{
- struct drm_device *dev = dev_get_drvdata(d);
- struct nouveau_drm *drm = nouveau_drm(dev);
- struct nvkm_therm *therm = nvxx_therm(&drm->client.device);
-
- return snprintf(buf, PAGE_SIZE, "%d\n",
- therm->attr_get(therm, NVKM_THERM_ATTR_THRS_DOWN_CLK) * 1000);
-}
-static ssize_t
-nouveau_hwmon_set_max_temp(struct device *d, struct device_attribute *a,
- const char *buf, size_t count)
+static int
+nouveau_hwmon_max_temp(struct nouveau_drm *drm)
{
- struct drm_device *dev = dev_get_drvdata(d);
- struct nouveau_drm *drm = nouveau_drm(dev);
struct nvkm_therm *therm = nvxx_therm(&drm->client.device);
- long value;
- if (kstrtol(buf, 10, &value) == -EINVAL)
- return count;
-
- therm->attr_set(therm, NVKM_THERM_ATTR_THRS_DOWN_CLK, value / 1000);
-
- return count;
+ return therm->attr_get(therm, NVKM_THERM_ATTR_THRS_DOWN_CLK) * 1000;
}
-static SENSOR_DEVICE_ATTR(temp1_max, S_IRUGO | S_IWUSR, nouveau_hwmon_max_temp,
- nouveau_hwmon_set_max_temp,
- 0);
-static ssize_t
-nouveau_hwmon_max_temp_hyst(struct device *d, struct device_attribute *a,
- char *buf)
-{
- struct drm_device *dev = dev_get_drvdata(d);
- struct nouveau_drm *drm = nouveau_drm(dev);
- struct nvkm_therm *therm = nvxx_therm(&drm->client.device);
-
- return snprintf(buf, PAGE_SIZE, "%d\n",
- therm->attr_get(therm, NVKM_THERM_ATTR_THRS_DOWN_CLK_HYST) * 1000);
-}
-static ssize_t
-nouveau_hwmon_set_max_temp_hyst(struct device *d, struct device_attribute *a,
- const char *buf, size_t count)
+static int
+nouveau_hwmon_max_temp_hyst(struct nouveau_drm *drm)
{
- struct drm_device *dev = dev_get_drvdata(d);
- struct nouveau_drm *drm = nouveau_drm(dev);
struct nvkm_therm *therm = nvxx_therm(&drm->client.device);
- long value;
-
- if (kstrtol(buf, 10, &value) == -EINVAL)
- return count;
- therm->attr_set(therm, NVKM_THERM_ATTR_THRS_DOWN_CLK_HYST,
- value / 1000);
-
- return count;
+ return therm->attr_get(therm, NVKM_THERM_ATTR_THRS_DOWN_CLK_HYST) *
1000;
}
-static SENSOR_DEVICE_ATTR(temp1_max_hyst, S_IRUGO | S_IWUSR,
- nouveau_hwmon_max_temp_hyst,
- nouveau_hwmon_set_max_temp_hyst, 0);
-
-static ssize_t
-nouveau_hwmon_critical_temp(struct device *d, struct device_attribute *a,
- char *buf)
-{
- struct drm_device *dev = dev_get_drvdata(d);
- struct nouveau_drm *drm = nouveau_drm(dev);
- struct nvkm_therm *therm = nvxx_therm(&drm->client.device);
- return snprintf(buf, PAGE_SIZE, "%d\n",
- therm->attr_get(therm, NVKM_THERM_ATTR_THRS_CRITICAL) * 1000);
-}
-static ssize_t
-nouveau_hwmon_set_critical_temp(struct device *d, struct device_attribute *a,
- const char *buf,
-
[PATCH v3 5/5] nouveau_hwmon: Change permissions to numeric
This patch replaces the symbolic permissions with the numeric ones,
and adds me to the authors too.
Signed-off-by: Oscar Salvador
---
drivers/gpu/drm/nouveau/nouveau_hwmon.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
index b9efc29..2d465c0 100644
--- a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
@@ -1,5 +1,6 @@
/*
- * Copyright 2010 Red Hat Inc.
+ * Copyright 2010 Red Hat Inc. (Ben Skeggs)
+ * Copyright 2017 Oscar Salvador
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
@@ -19,7 +20,6 @@
* ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
* OTHER DEALINGS IN THE SOFTWARE.
*
- * Authors: Ben Skeggs
*/
#ifdef CONFIG_ACPI
@@ -56,7 +56,7 @@ nouveau_hwmon_show_temp1_auto_point1_pwm(struct device *d,
{
return snprintf(buf, PAGE_SIZE, "%d\n", 100);
}
-static SENSOR_DEVICE_ATTR(temp1_auto_point1_pwm, S_IRUGO,
+static SENSOR_DEVICE_ATTR(temp1_auto_point1_pwm, 0444,
nouveau_hwmon_show_temp1_auto_point1_pwm, NULL, 0);
static ssize_t
@@ -88,7 +88,7 @@ nouveau_hwmon_set_temp1_auto_point1_temp(struct device *d,
return count;
}
-static SENSOR_DEVICE_ATTR(temp1_auto_point1_temp, S_IRUGO | S_IWUSR,
+static SENSOR_DEVICE_ATTR(temp1_auto_point1_temp, 0644,
nouveau_hwmon_temp1_auto_point1_temp,
nouveau_hwmon_set_temp1_auto_point1_temp, 0);
@@ -121,7 +121,7 @@ nouveau_hwmon_set_temp1_auto_point1_temp_hyst(struct device
*d,
return count;
}
-static SENSOR_DEVICE_ATTR(temp1_auto_point1_temp_hyst, S_IRUGO | S_IWUSR,
+static SENSOR_DEVICE_ATTR(temp1_auto_point1_temp_hyst, 0644,
nouveau_hwmon_temp1_auto_point1_temp_hyst,
nouveau_hwmon_set_temp1_auto_point1_temp_hyst, 0);
@@ -255,7 +255,7 @@ nouveau_hwmon_set_pwm1_min(struct device *d, struct
device_attribute *a,
return count;
}
-static SENSOR_DEVICE_ATTR(pwm1_min, S_IRUGO | S_IWUSR,
+static SENSOR_DEVICE_ATTR(pwm1_min, 0644,
nouveau_hwmon_get_pwm1_min,
nouveau_hwmon_set_pwm1_min, 0);
@@ -295,7 +295,7 @@ nouveau_hwmon_set_pwm1_max(struct device *d, struct
device_attribute *a,
return count;
}
-static SENSOR_DEVICE_ATTR(pwm1_max, S_IRUGO | S_IWUSR,
+static SENSOR_DEVICE_ATTR(pwm1_max, 0644,
nouveau_hwmon_get_pwm1_max,
nouveau_hwmon_set_pwm1_max, 0);
--
2.1.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 4/5] nouveau_hwmon: Add support for auto_point attributes
This patch creates a special group attributes for attrs like "*auto_point*".
We check if we have support for them, and if we do, we gather them all in
an attribute_group's structure which is the parameter regarding special groups
of hwmon_device_register_with_info.
Signed-off-by: Oscar Salvador
---
drivers/gpu/drm/nouveau/nouveau_hwmon.c | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
index 57296cb..b9efc29 100644
--- a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
@@ -358,6 +358,24 @@ nouveau_hwmon_get_power1_crit(struct nouveau_drm *drm)
return iccsense->power_w_crit;
}
+static const struct attribute *pwm_fan_sensor_attrs[] = {
+ &sensor_dev_attr_pwm1_min.dev_attr.attr,
+ &sensor_dev_attr_pwm1_max.dev_attr.attr,
+ NULL
+};
+ATTRIBUTE_GROUPS(pwm_fan_sensor);
+
+static const struct attribute *temp1_auto_point_sensor_attrs[] = {
+ &sensor_dev_attr_temp1_auto_point1_pwm.dev_attr.attr,
+ &sensor_dev_attr_temp1_auto_point1_temp.dev_attr.attr,
+ &sensor_dev_attr_temp1_auto_point1_temp_hyst.dev_attr.attr,
+ NULL
+};
+ATTRIBUTE_GROUPS(temp1_auto_point_sensor);
+
+#define N_ATTR_GROUPS 3
+
+
static const u32 nouveau_config_chip[] = {
HWMON_C_UPDATE_INTERVAL,
0
@@ -793,17 +811,27 @@ nouveau_hwmon_init(struct drm_device *dev)
#if defined(CONFIG_HWMON) || (defined(MODULE) && defined(CONFIG_HWMON_MODULE))
struct nouveau_drm *drm = nouveau_drm(dev);
struct nvkm_therm *therm = nvxx_therm(&drm->client.device);
+ const struct attribute_group *special_groups[N_ATTR_GROUPS];
struct nouveau_hwmon *hwmon;
struct device *hwmon_dev;
int ret = 0;
+ int i = 0;
hwmon = drm->hwmon = kzalloc(sizeof(*hwmon), GFP_KERNEL);
if (!hwmon)
return -ENOMEM;
hwmon->dev = dev;
+ if (therm && therm->attr_get && therm->attr_set) {
+ if (nvkm_therm_temp_get(therm) >= 0)
+ special_groups[i++] = &temp1_auto_point_sensor_group;
+ if (therm->fan_get && therm->fan_get(therm) >= 0)
+ special_groups[i++] = &pwm_fan_sensor_group;
+ }
+
+ special_groups[i] = 0;
hwmon_dev = hwmon_device_register_with_info(dev->dev, "nouveau", dev,
- &nouveau_chip_info, NULL);
+ &nouveau_chip_info, special_groups);
if (IS_ERR(hwmon_dev)) {
ret = PTR_ERR(hwmon_dev);
NV_ERROR(drm, "Unable to register hwmon device: %d\n", ret);
--
2.1.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.
On Fri, Apr 21, 2017 at 10:49:49AM -0400, Ilia Mirkin wrote:
> On Fri, Apr 21, 2017 at 3:58 AM, Gerd Hoffmann wrote:
> > While working on graphics support for virtual machines on ppc64 (which
> > exists in both little and big endian variants) I've figured the comments
> > for various drm fourcc formats in the header file don't match reality.
> >
> > Comments says the RGB formats are little endian, but in practice they
> > are native endian. Look at the drm_mode_legacy_fb_format() helper. It
> > maps -- for example -- bpp/depth 32/24 to DRM_FORMAT_XRGB, no matter
> > whenever the machine is little endian or big endian. The users of this
> > function (fbdev emulation, DRM_IOCTL_MODE_ADDFB) expect the framebuffer
> > is native endian, not little endian. Most userspace also operates on
> > native endian only.
> >
> > So, go update the comments for all 16+24+32 bpp RGB formats.
> >
> > Leaving the yuv formats as-is. I have no idea if and how those are used
> > on bigendian machines.
>
> I think this is premature. The current situation is that I can't get
> modetest to work *at all* on my NV34 / BE setup (I mean, it runs, just
> the colors displayed are wrong). I believe that currently it packs
> things in "cpu native endian". I've tried futzing with that without
> much success, although I didn't spend too much time on it. I have a
> NV34 plugged into my LE setup as well although I haven't tested to
> double-check that it all works there. However I'm quite sure it used
> to, as I used modetest to help develop the YUV overlay support for
> those GPUs.
I just took a quick stab at fixing modetest to respect the current
wording in drm_fourcc.h:
git://github.com/vsyrjala/libdrm.git modetest_endian
>
> Does modetest work for you, under any interpretation of the formats?
>
> There's an additional complication wrt looking at what fbcon does,
> since it will feed the data in via special accel interfaces in fbdev,
> which at least on nouveau, may end up byteswapping the data on upload
> to VRAM (I'm not 100% clear on whether they do or not). However
> modetest, which is creating its own fb, likely won't get such
> treatment.
>
> This is a shitty situation - we have hardware we don't know how it
> works, tools we don't know whether they're broken, and comments we're
> pretty sure are at least somewhat wrong. Furthermore the hardware is
> relatively rare and developers with time to work on improving it are
> even rarer.
>
> I'd like to reiterate that the status quo does end up in a functioning
> system. Let's try not to break that.
>
> Cheers,
>
> -ilia
>
> >
> > Cc: Ville Syrjälä
> > Cc: Daniel Vetter
> > Cc: Pekka Paalanen
> > Cc: Ilia Mirkin
> > Cc: Michel Dänzer
> > Cc: Alex Deucher
> > Cc: amd-...@lists.freedesktop.org
> > Signed-off-by: Gerd Hoffmann
> > ---
> > include/uapi/drm/drm_fourcc.h | 82
> > +--
> > 1 file changed, 41 insertions(+), 41 deletions(-)
> >
> > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> > index 995c8f9..1579765 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -42,68 +42,68 @@ extern "C" {
> > #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
> > little endian */
> > +#define DRM_FORMAT_R16 fourcc_code('R', '1', '6', ' ') /* [15:0] R
> > native endian */
> >
> > /* 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 */
> > +#define DRM_FORMAT_RG88fourcc_code('R', 'G', '8', '8') /*
> > [15:0] R:G 8:8 native endian */
> > +#define DRM_FORMAT_GR88fourcc_code('G', 'R', '8', '8') /*
> > [15:0] G:R 8:8 native endian */
> >
> > /* 32 bpp RG */
> > -#define DRM_FORMAT_RG1616 fourcc_code('R', 'G', '3', '2') /* [31:0]
> > R:G 16:16 little endian */
> > -#define DRM_FORMAT_GR1616 fourcc_code('G', 'R', '3', '2') /* [31:0]
> > G:R 16:16 little endian */
> > +#define DRM_FORMAT_RG1616 fourcc_code('R', 'G', '3', '2') /* [31:0]
> > R:G 16:16 native endian */
> > +#define DRM_FORMAT_GR1616 fourcc_code('G', 'R', '3', '2') /* [31:0]
> > G:R 16:16 native endian */
> >
> > /* 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 */
> >
> > /* 16 bpp RGB */
> > -#define DRM_FORMAT_XRGBfourcc_code('X', 'R', '1', '2') /* [15:0]
> > x:R:G:B 4:4:4:4 little endian */
> > -#define DRM_FORMAT_XBGRfourcc_code('X', 'B', '1', '2') /* [15:0]
> > x:B:G:R 4:4:4:4 little endian */
> > -#define DRM_FORMAT_RGBXfourcc_cod
[git pull] vmwgfx-next
Hi Dave, The following changes since commit 6b1462700b4a6a1244c018cdd2fa97ded43090a0: Merge tag 'drm-misc-next-fixes-2017-04-20' of git://anongit.freedesktop.org/git/drm-misc into drm-next (2017-04-21 13:51:59 +1000) are available in the git repository at: git://people.freedesktop.org/~syeh/repos_linux drm-vmwgfx-next for you to fetch changes up to 7a9d2001a16f11d30a1e128a067cf1aef2a99a70: drm/vmwgfx: Convert macro to octal representation (2017-04-21 09:25:47 -0700) Øyvind A. Holm (1): drm/vmwgfx: Convert macro to octal representation drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RFC 1/7] clk: samsung: Add enable/disable operation for PLL36XX clocks
The existing enable/disable ops for PLL35XX are made more generic
and used also for PLL36XX. This fixes issues in the kernel with
PLL36XX PLLs when the PLL has not been already enabled by bootloader.
Signed-off-by: Sylwester Nawrocki
---
drivers/clk/samsung/clk-pll.c | 85 +--
1 file changed, 49 insertions(+), 36 deletions(-)
diff --git a/drivers/clk/samsung/clk-pll.c b/drivers/clk/samsung/clk-pll.c
index 5229089..10c76eb 100644
--- a/drivers/clk/samsung/clk-pll.c
+++ b/drivers/clk/samsung/clk-pll.c
@@ -23,6 +23,10 @@ struct samsung_clk_pll {
struct clk_hw hw;
void __iomem*lock_reg;
void __iomem*con_reg;
+ /* PLL enable control bit offset in @con_reg register */
+ unsigned short enable_offs;
+ /* PLL lock status bit offset in @con_reg register */
+ unsigned short lock_offs;
enum samsung_pll_type type;
unsigned intrate_count;
const struct samsung_pll_rate_table *rate_table;
@@ -61,6 +65,34 @@ static long samsung_pll_round_rate(struct clk_hw *hw,
return rate_table[i - 1].rate;
}
+static int samsung_pll3xxx_enable(struct clk_hw *hw)
+{
+ struct samsung_clk_pll *pll = to_clk_pll(hw);
+ u32 tmp;
+
+ tmp = readl_relaxed(pll->con_reg);
+ tmp |= BIT(pll->enable_offs);
+ writel_relaxed(tmp, pll->con_reg);
+
+ /* wait lock time */
+ do {
+ cpu_relax();
+ tmp = readl_relaxed(pll->con_reg);
+ } while (!(tmp & BIT(pll->lock_offs)));
+
+ return 0;
+}
+
+static void samsung_pll3xxx_disable(struct clk_hw *hw)
+{
+ struct samsung_clk_pll *pll = to_clk_pll(hw);
+ u32 tmp;
+
+ tmp = readl_relaxed(pll->con_reg);
+ tmp |= BIT(pll->enable_offs);
+ writel_relaxed(tmp, pll->con_reg);
+}
+
/*
* PLL2126 Clock Type
*/
@@ -142,34 +174,6 @@ static unsigned long samsung_pll3000_recalc_rate(struct
clk_hw *hw,
#define PLL35XX_LOCK_STAT_SHIFT(29)
#define PLL35XX_ENABLE_SHIFT (31)
-static int samsung_pll35xx_enable(struct clk_hw *hw)
-{
- struct samsung_clk_pll *pll = to_clk_pll(hw);
- u32 tmp;
-
- tmp = readl_relaxed(pll->con_reg);
- tmp |= BIT(PLL35XX_ENABLE_SHIFT);
- writel_relaxed(tmp, pll->con_reg);
-
- /* wait_lock_time */
- do {
- cpu_relax();
- tmp = readl_relaxed(pll->con_reg);
- } while (!(tmp & BIT(PLL35XX_LOCK_STAT_SHIFT)));
-
- return 0;
-}
-
-static void samsung_pll35xx_disable(struct clk_hw *hw)
-{
- struct samsung_clk_pll *pll = to_clk_pll(hw);
- u32 tmp;
-
- tmp = readl_relaxed(pll->con_reg);
- tmp &= ~BIT(PLL35XX_ENABLE_SHIFT);
- writel_relaxed(tmp, pll->con_reg);
-}
-
static unsigned long samsung_pll35xx_recalc_rate(struct clk_hw *hw,
unsigned long parent_rate)
{
@@ -239,11 +243,11 @@ static int samsung_pll35xx_set_rate(struct clk_hw *hw,
unsigned long drate,
writel_relaxed(tmp, pll->con_reg);
/* wait_lock_time if enabled */
- if (tmp & BIT(PLL35XX_ENABLE_SHIFT)) {
+ if (tmp & BIT(pll->enable_offs)) {
do {
cpu_relax();
tmp = readl_relaxed(pll->con_reg);
- } while (!(tmp & BIT(PLL35XX_LOCK_STAT_SHIFT)));
+ } while (!(tmp & BIT(pll->lock_offs)));
}
return 0;
}
@@ -252,8 +256,8 @@ static int samsung_pll35xx_set_rate(struct clk_hw *hw,
unsigned long drate,
.recalc_rate = samsung_pll35xx_recalc_rate,
.round_rate = samsung_pll_round_rate,
.set_rate = samsung_pll35xx_set_rate,
- .enable = samsung_pll35xx_enable,
- .disable = samsung_pll35xx_disable,
+ .enable = samsung_pll3xxx_enable,
+ .disable = samsung_pll3xxx_disable,
};
static const struct clk_ops samsung_pll35xx_clk_min_ops = {
@@ -275,6 +279,7 @@ static int samsung_pll35xx_set_rate(struct clk_hw *hw,
unsigned long drate,
#define PLL36XX_SDIV_SHIFT (0)
#define PLL36XX_KDIV_SHIFT (0)
#define PLL36XX_LOCK_STAT_SHIFT(29)
+#define PLL36XX_ENABLE_SHIFT (31)
static unsigned long samsung_pll36xx_recalc_rate(struct clk_hw *hw,
unsigned long parent_rate)
@@ -354,10 +359,12 @@ static int samsung_pll36xx_set_rate(struct clk_hw *hw,
unsigned long drate,
writel_relaxed(pll_con1, pll->con_reg + 4);
/* wait_lock_time */
- do {
- cpu_relax();
- tmp = readl_relaxed(pll->con_reg);
- } while (!(tmp & (1 << PLL36XX_LOCK_STAT_SHIFT)));
+ if (pll_con0 & BIT(pll->enable_offs)) {
+ do {
+ cpu_relax();
+ tmp = readl_relaxed(pll->con_reg);
+ } while (!(tmp & BIT(PLL36XX_LOCK_STAT_SHIFT)));
+ }
return 0;
}
@@ -366,6 +373,8 @@ static int sam
[PATCH RFC 4/7] drm: exynos: Add driver for HDMI audio interface
The hdmi-codec interface added in this patch is required to properly
support HDMI audio. Currently the audio part of the SoC internal
HDMI transmitter is configured with fixed values, which makes HDMI
audio working by chance, only on boards equipped with external audio
codec connected in parallel with the HDMI audio transmitter I2S input
interface.
Signed-off-by: Sylwester Nawrocki
---
drivers/gpu/drm/exynos/Kconfig | 1 +
drivers/gpu/drm/exynos/exynos_hdmi.c | 220 +--
2 files changed, 188 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 1d18534..a6edbb6 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -3,6 +3,7 @@ config DRM_EXYNOS
depends on OF && DRM && (ARCH_S3C64XX || ARCH_EXYNOS ||
ARCH_MULTIPLATFORM)
select DRM_KMS_HELPER
select VIDEOMODE_HELPERS
+ select SND_SOC_HDMI_CODEC if SND_SOC
help
Choose this option if you have a Samsung SoC EXYNOS chipset.
If M is selected the module will be called exynosdrm.
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 88ccc04..be18023 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -40,7 +40,7 @@
#include
#include
#include
-
+#include
#include
#include "exynos_drm_drv.h"
@@ -110,13 +110,23 @@ struct hdmi_driver_data {
struct string_array_spec clk_muxes;
};
+struct hdmi_audio {
+ struct platform_device *pdev;
+ struct hdmi_audio_infoframe infoframe;
+ unsigned int sample_rate;
+ unsigned int sample_width;
+ u8 enable;
+};
+
struct hdmi_context {
struct drm_encoder encoder;
struct device *dev;
struct drm_device *drm_dev;
struct drm_connectorconnector;
+ struct hdmi_audio audio;
boolpowered;
booldvi_mode;
+ struct mutexmutex;
struct delayed_work hotplug_work;
struct drm_display_mode current_mode;
const struct hdmi_driver_data *drv_data;
@@ -766,6 +776,22 @@ static int hdmi_clk_set_parents(struct hdmi_context
*hdata, bool to_phy)
return ret;
}
+static int hdmi_audio_infoframe_apply(struct hdmi_context *hdata)
+{
+ struct hdmi_audio_infoframe *infoframe = &hdata->audio.infoframe;
+ u8 buf[HDMI_INFOFRAME_SIZE(AUDIO)];
+ int len;
+
+ len = hdmi_audio_infoframe_pack(infoframe, buf, sizeof(buf));
+ if (len < 0)
+ return len;
+
+ hdmi_reg_writeb(hdata, HDMI_AUI_CON, HDMI_AUI_CON_EVERY_VSYNC);
+ hdmi_reg_write_buf(hdata, HDMI_AUI_HEADER0, buf, len);
+
+ return 0;
+}
+
static void hdmi_reg_infoframes(struct hdmi_context *hdata)
{
union hdmi_infoframe frm;
@@ -803,15 +829,7 @@ static void hdmi_reg_infoframes(struct hdmi_context *hdata)
hdmi_reg_write_buf(hdata, HDMI_VSI_DATA(0), buf + 3, ret - 3);
}
- ret = hdmi_audio_infoframe_init(&frm.audio);
- if (!ret) {
- frm.audio.channels = 2;
- ret = hdmi_audio_infoframe_pack(&frm.audio, buf, sizeof(buf));
- }
- if (ret > 0) {
- hdmi_reg_writeb(hdata, HDMI_AUI_CON, HDMI_AUI_CON_EVERY_VSYNC);
- hdmi_reg_write_buf(hdata, HDMI_AUI_HEADER0, buf, ret);
- }
+ hdmi_audio_infoframe_apply(hdata);
}
static enum drm_connector_status hdmi_detect(struct drm_connector *connector,
@@ -993,23 +1011,18 @@ static void hdmi_reg_acr(struct hdmi_context *hdata, u32
freq)
hdmi_reg_writeb(hdata, HDMI_ACR_CON, 4);
}
-static void hdmi_audio_init(struct hdmi_context *hdata)
+static void hdmi_audio_config(struct hdmi_context *hdata)
{
- u32 sample_rate, bits_per_sample;
- u32 data_num, bit_ch, sample_frq;
- u32 val;
+ u32 data_num, sample_freq, val;
+ u32 bit_ch = 1;
- sample_rate = 44100;
- bits_per_sample = 16;
- switch (bits_per_sample) {
+ switch (hdata->audio.sample_width) {
case 20:
data_num = 2;
- bit_ch = 1;
break;
case 24:
data_num = 3;
- bit_ch = 1;
break;
default:
data_num = 1;
@@ -1017,7 +1030,7 @@ static void hdmi_audio_init(struct hdmi_context *hdata)
break;
}
- hdmi_reg_acr(hdata, sample_rate);
+ hdmi_reg_acr(hdata, hdata->audio.sample_rate);
hdmi_reg_writeb(hdata, HDMI_I2S_MUX_CON, HDMI_I2S_IN_DISABLE
| HDMI_I2S_AUD_I2S | HDMI_I2S_CUV_I2S_ENABLE
@@ -1028,10 +1041,21 @@ static void hdmi_audio_init(struct hdmi_context *hdata)
hdmi_reg_writeb(hdata, HDMI_I2S_MUX_CUV,
[PATCH RFC 0/7] HDMI audio support for Exynos Odroid boards
In this series I gathered patches touching various subsystems to make the overall review easier, finally I'm going to post independently patches for each subsystem and the dts patch(es) will be postponed to subsequent merge window. The main purpose of this series is to add audio codec interface to the Exynos DRM driver, so HDMI audio can be properly supported, also on boards where HDMI is the only connector available for audio. Currently in mainline the ASoC simple-card is used for Odroid XU3, I decided to change it and use a dedicated ASoC machine driver, which allowed to implemement specific clock settings (EPLL and the I2S root clock adjusted to audio sample rates) and to ensure proper number of audio channels gets negotiated in multicodec system configuration. This series is based on v4.11-rc6, has been tested on Odroid XU3. Sylwester Nawrocki (7): clk: samsung: Add enable/disable operation for PLL36XX clocks clk: samsung: Add definitions of some audio related clocks clk: samsung: exynos542x: Add EPLL rate table drm: exynos: Add driver for HDMI audio interface ASoC: Add Odroid sound DT bindings documentation ASoC: samsung: Add Odroid ASoC machine driver ARM: dts: samsung: Switch to dedicated Odroid sound card binding .../devicetree/bindings/sound/samsung,odroid.txt | 57 ++ arch/arm/boot/dts/exynos4.dtsi | 1 + arch/arm/boot/dts/exynos5420.dtsi | 1 + arch/arm/boot/dts/exynos5422-odroidxu3-audio.dtsi | 59 -- drivers/clk/samsung/clk-exynos5420.c | 31 ++- drivers/clk/samsung/clk-pll.c | 85 drivers/gpu/drm/exynos/Kconfig | 1 + drivers/gpu/drm/exynos/exynos_hdmi.c | 220 + include/dt-bindings/clock/exynos5420.h | 3 + sound/soc/samsung/Kconfig | 8 + sound/soc/samsung/Makefile | 2 + sound/soc/samsung/odroid.c | 219 12 files changed, 599 insertions(+), 88 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/samsung,odroid.txt create mode 100644 sound/soc/samsung/odroid.c -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RFC 2/7] clk: samsung: Add definitions of some audio related clocks
This patch adds missing definitions of mux clocks required for using
EPLL as the audio subsystem root clock on exynos5420/exynos5422 SoCs.
Signed-off-by: Sylwester Nawrocki
---
drivers/clk/samsung/clk-exynos5420.c | 13 -
include/dt-bindings/clock/exynos5420.h | 3 +++
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index cdc092a..87c711a 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -477,8 +477,7 @@ static void __init exynos5420_clk_sleep_init(void) {}
"mout_sclk_mpll", "ff_dout_spll2",
"mout_sclk_spll", "mout_sclk_epll"};
PNAME(mout_mau_epll_clk_5800_p)= { "mout_sclk_epll", "mout_sclk_dpll",
- "mout_sclk_mpll",
- "ff_dout_spll2" };
+ "mout_sclk_mpll", "ff_dout_spll2" };
PNAME(mout_group8_5800_p) = { "dout_aclk432_scaler", "dout_sclk_sw" };
PNAME(mout_group9_5800_p) = { "dout_osc_div", "mout_sw_aclk432_scaler" };
PNAME(mout_group10_5800_p) = { "dout_aclk432_cam", "dout_sclk_sw" };
@@ -487,6 +486,7 @@ static void __init exynos5420_clk_sleep_init(void) {}
PNAME(mout_group13_5800_p) = { "dout_osc_div", "mout_sw_aclkfl1_550_cam" };
PNAME(mout_group14_5800_p) = { "dout_aclk550_cam", "dout_sclk_sw" };
PNAME(mout_group15_5800_p) = { "dout_osc_div", "mout_sw_aclk550_cam" };
+PNAME(mout_group16_5800_p) = { "dout_osc_div", "mout_mau_epll_clk" };
/* fixed rate clocks generated outside the soc */
static struct samsung_fixed_rate_clock
@@ -536,8 +536,8 @@ static void __init exynos5420_clk_sleep_init(void) {}
MUX(CLK_MOUT_MX_MSPLL_CCORE, "mout_mx_mspll_ccore",
mout_mx_mspll_ccore_p, SRC_TOP7, 16, 2),
- MUX(0, "mout_mau_epll_clk", mout_mau_epll_clk_5800_p, SRC_TOP7,
- 20, 2),
+ MUX(CLK_MOUT_MAU_EPLL, "mout_mau_epll_clk", mout_mau_epll_clk_5800_p,
+ SRC_TOP7, 20, 2),
MUX(0, "sclk_bpll", mout_bpll_p, SRC_TOP7, 24, 1),
MUX(0, "mout_epll2", mout_epll2_5800_p, SRC_TOP7, 28, 1),
@@ -546,6 +546,8 @@ static void __init exynos5420_clk_sleep_init(void) {}
MUX(0, "mout_aclk432_cam", mout_group6_5800_p, SRC_TOP8, 24, 2),
MUX(0, "mout_aclk432_scaler", mout_group6_5800_p, SRC_TOP8, 28, 2),
+ MUX(CLK_MOUT_USER_MAU_EPLL, "mout_user_mau_epll", mout_group16_5800_p,
+ SRC_TOP9, 8, 1),
MUX(0, "mout_user_aclk550_cam", mout_group15_5800_p,
SRC_TOP9, 16, 1),
MUX(0, "mout_user_aclkfl1_550_cam", mout_group13_5800_p,
@@ -703,7 +705,7 @@ static void __init exynos5420_clk_sleep_init(void) {}
MUX(0, "mout_sclk_spll", mout_spll_p, SRC_TOP6, 8, 1),
MUX(0, "mout_sclk_ipll", mout_ipll_p, SRC_TOP6, 12, 1),
MUX(0, "mout_sclk_rpll", mout_rpll_p, SRC_TOP6, 16, 1),
- MUX(0, "mout_sclk_epll", mout_epll_p, SRC_TOP6, 20, 1),
+ MUX(CLK_MOUT_EPLL, "mout_sclk_epll", mout_epll_p, SRC_TOP6, 20, 1),
MUX(0, "mout_sclk_dpll", mout_dpll_p, SRC_TOP6, 24, 1),
MUX(0, "mout_sclk_cpll", mout_cpll_p, SRC_TOP6, 28, 1),
@@ -1399,6 +1401,7 @@ static void __init exynos5x_clk_init(struct device_node
*np,
if (_get_rate("fin_pll") == 24 * MHZ) {
exynos5x_plls[apll].rate_table = exynos5420_pll2550x_24mhz_tbl;
+ exynos5x_plls[epll].rate_table = exynos5420_pll2550x_24mhz_tbl;
exynos5x_plls[kpll].rate_table = exynos5420_pll2550x_24mhz_tbl;
exynos5x_plls[bpll].rate_table = exynos5420_pll2550x_24mhz_tbl;
}
diff --git a/include/dt-bindings/clock/exynos5420.h
b/include/dt-bindings/clock/exynos5420.h
index 6fd21c2..2740ae0 100644
--- a/include/dt-bindings/clock/exynos5420.h
+++ b/include/dt-bindings/clock/exynos5420.h
@@ -217,6 +217,9 @@
#define CLK_MOUT_MCLK_CDREX654
#define CLK_MOUT_BPLL 655
#define CLK_MOUT_MX_MSPLL_CCORE656
+#define CLK_MOUT_EPLL 657
+#define CLK_MOUT_MAU_EPLL 658
+#define CLK_MOUT_USER_MAU_EPLL 659
/* divider clocks */
#define CLK_DOUT_PIXEL 768
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RFC 3/7] clk: samsung: exynos542x: Add EPLL rate table
A specific clock rate table is added for EPLL so it is possible
to set frequency of the EPLL output clock as multiple of various
audio sampling rates.
Signed-off-by: Sylwester Nawrocki
---
drivers/clk/samsung/clk-exynos5420.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 87c711a..6fbd6ae 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -1279,6 +1279,22 @@ static void __init exynos5420_clk_sleep_init(void) {}
PLL_35XX_RATE(2, 200, 3, 3),
};
+static const struct samsung_pll_rate_table exynos5420_epll_24mhz_tbl[] = {
+ PLL_36XX_RATE(6U, 100, 2, 1, 0),
+ PLL_36XX_RATE(4U, 200, 2, 2, 0),
+ PLL_36XX_RATE(393216000U, 197, 3, 2, 25690),
+ PLL_36XX_RATE(361267200U, 301, 5, 2, 3671),
+ PLL_36XX_RATE(2U, 200, 3, 3, 0),
+ PLL_36XX_RATE(196608000U, 197, 3, 3, -25690),
+ PLL_36XX_RATE(180633600U, 301, 5, 3, 3671),
+ PLL_36XX_RATE(131072000U, 131, 3, 3, 4719),
+ PLL_36XX_RATE(1U, 200, 3, 4, 0),
+ PLL_36XX_RATE( 65536000U, 131, 3, 4, 4719),
+ PLL_36XX_RATE( 49152000U, 197, 3, 5, 25690),
+ PLL_36XX_RATE( 45158400U, 301, 5, 3, 3671),
+ PLL_36XX_RATE( 32768000U, 131, 3, 5, 4719),
+};
+
static struct samsung_pll_clock exynos5x_plls[nr_plls] __initdata = {
[apll] = PLL(pll_2550, CLK_FOUT_APLL, "fout_apll", "fin_pll", APLL_LOCK,
APLL_CON0, NULL),
@@ -1286,7 +1302,7 @@ static void __init exynos5420_clk_sleep_init(void) {}
CPLL_CON0, NULL),
[dpll] = PLL(pll_2550, CLK_FOUT_DPLL, "fout_dpll", "fin_pll", DPLL_LOCK,
DPLL_CON0, NULL),
- [epll] = PLL(pll_2650, CLK_FOUT_EPLL, "fout_epll", "fin_pll", EPLL_LOCK,
+ [epll] = PLL(pll_36xx, CLK_FOUT_EPLL, "fout_epll", "fin_pll", EPLL_LOCK,
EPLL_CON0, NULL),
[rpll] = PLL(pll_2650, CLK_FOUT_RPLL, "fout_rpll", "fin_pll", RPLL_LOCK,
RPLL_CON0, NULL),
@@ -1401,7 +1417,7 @@ static void __init exynos5x_clk_init(struct device_node
*np,
if (_get_rate("fin_pll") == 24 * MHZ) {
exynos5x_plls[apll].rate_table = exynos5420_pll2550x_24mhz_tbl;
- exynos5x_plls[epll].rate_table = exynos5420_pll2550x_24mhz_tbl;
+ exynos5x_plls[epll].rate_table = exynos5420_epll_24mhz_tbl;
exynos5x_plls[kpll].rate_table = exynos5420_pll2550x_24mhz_tbl;
exynos5x_plls[bpll].rate_table = exynos5420_pll2550x_24mhz_tbl;
}
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RFC 5/7] ASoC: Add Odroid sound DT bindings documentation
This patch adds DT binding documentation for Odroid XU3/4
sound subsystem.
Signed-off-by: Sylwester Nawrocki
---
.../devicetree/bindings/sound/samsung,odroid.txt | 57 ++
1 file changed, 57 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/samsung,odroid.txt
diff --git a/Documentation/devicetree/bindings/sound/samsung,odroid.txt
b/Documentation/devicetree/bindings/sound/samsung,odroid.txt
new file mode 100644
index 000..c1ac70c
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/samsung,odroid.txt
@@ -0,0 +1,57 @@
+Samsung Exynos Odroid XU3/XU4 audio complex with MAX98090 codec
+
+Required properties:
+
+ - compatible - "samsung,odroidxu3-audio" - for Odroid XU3 board,
+ "samsung,odroidxu4-audio" - for Odroid XU4 board
+ - model - the user-visible name of this sound complex
+ - 'cpu' subnode with a 'sound-dai' property containing the phandle of the I2S
+controller
+ - 'codec' subnode with a 'sound-dai' property containing list of phandles
+to the CODEC nodes, first entry must be corresponding to the MAX98090
+CODEC and the second entry must be the phandle of the HDMI IP block node
+ - clocks - should contain entries matching clock names in the clock-names
+property
+ - clock-names - should contain following entries:
+- "epll" - indicating the EPLL output clock
+- "i2s_rclk" - indicating the RCLK (root) clock of the I2S0 controller
+ - samsung,audio-widgets - this property specifies off-codec audio elements
+ like headphones or speakers, for details see widgets.txt
+ - samsung,audio-routing - a list of the connections between audio
+ components; each entry is a pair of strings, the first being the
+ connection's sink, the second being the connection's source;
+ valid names for sources and sinks are the MAX98090's pins (as
+ documented in its binding), and the jacks on the board
+
+ For Odroid X2:
+ "Headphone Jack", "Mic Jack", "DMIC"
+
+ For Odroid U3, XU3:
+ "Headphone Jack", "Speakers"
+
+ For Odroid XU4:
+ no entries
+
+Example:
+
+sound {
+ compatible = "samsung,odroidxu3-audio";
+ samsung,cpu-dai = <&i2s0>;
+ samsung,codec-dai = <&max98090>;
+ model = "Odroid-XU3";
+ samsung,audio-routing =
+ "Headphone Jack", "HPL",
+ "Headphone Jack", "HPR",
+ "IN1", "Mic Jack",
+ "Mic Jack", "MICBIAS";
+
+ clocks = <&clock CLK_FOUT_EPLL>, <&i2s0 CLK_I2S_RCLK_SRC>;
+ clock-names = "epll", "sclk_i2s";
+
+ cpu {
+ sound-dai = <&i2s0 0>;
+ };
+ codec {
+ sound-dai = <&hdmi>, <&max98090>;
+ };
+};
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RFC 6/7] ASoC: samsung: Add Odroid ASoC machine driver
This dedicated driver allows to support SoC specific clock
settings and helps to ensure proper number of channels gets
negotiated in multicodec system configurations.
Signed-off-by: Sylwester Nawrocki
---
sound/soc/samsung/Kconfig | 8 ++
sound/soc/samsung/Makefile | 2 +
sound/soc/samsung/odroid.c | 219 +
3 files changed, 229 insertions(+)
create mode 100644 sound/soc/samsung/odroid.c
diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig
index f1f1d79..0520f5a 100644
--- a/sound/soc/samsung/Kconfig
+++ b/sound/soc/samsung/Kconfig
@@ -185,6 +185,14 @@ config SND_SOC_SNOW
Say Y if you want to add audio support for various Snow
boards based on Exynos5 series of SoCs.
+config SND_SOC_ODROID
+ tristate "Audio support for Odroid XU3/XU4"
+ depends on SND_SOC_SAMSUNG && I2C
+ select SND_SOC_MAX98090
+ select SND_SAMSUNG_I2S
+ help
+ Say Y here to enable audio support for the Odroid XU3/XU4.
+
config SND_SOC_ARNDALE_RT5631_ALC5631
tristate "Audio support for RT5631(ALC5631) on Arndale Board"
depends on I2C
diff --git a/sound/soc/samsung/Makefile b/sound/soc/samsung/Makefile
index b5df5e2e..b6c2ee3 100644
--- a/sound/soc/samsung/Makefile
+++ b/sound/soc/samsung/Makefile
@@ -40,6 +40,7 @@ snd-soc-tobermory-objs := tobermory.o
snd-soc-lowland-objs := lowland.o
snd-soc-littlemill-objs := littlemill.o
snd-soc-bells-objs := bells.o
+snd-soc-odroid-objs := odroid.o
snd-soc-arndale-rt5631-objs := arndale_rt5631.o
snd-soc-tm2-wm5110-objs := tm2_wm5110.o
@@ -62,5 +63,6 @@ obj-$(CONFIG_SND_SOC_TOBERMORY) += snd-soc-tobermory.o
obj-$(CONFIG_SND_SOC_LOWLAND) += snd-soc-lowland.o
obj-$(CONFIG_SND_SOC_LITTLEMILL) += snd-soc-littlemill.o
obj-$(CONFIG_SND_SOC_BELLS) += snd-soc-bells.o
+obj-$(CONFIG_SND_SOC_ODROID) += snd-soc-odroid.o
obj-$(CONFIG_SND_SOC_ARNDALE_RT5631_ALC5631) += snd-soc-arndale-rt5631.o
obj-$(CONFIG_SND_SOC_SAMSUNG_TM2_WM5110) += snd-soc-tm2-wm5110.o
diff --git a/sound/soc/samsung/odroid.c b/sound/soc/samsung/odroid.c
new file mode 100644
index 000..0c0b00e
--- /dev/null
+++ b/sound/soc/samsung/odroid.c
@@ -0,0 +1,219 @@
+/*
+ * Copyright (C) 2017 Samsung Electronics Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "i2s.h"
+#include "i2s-regs.h"
+
+struct odroid_priv {
+ struct snd_soc_card card;
+ struct snd_soc_dai_link dai_link;
+
+ struct clk *pll;
+ struct clk *rclk;
+};
+
+static int odroid_card_startup(struct snd_pcm_substream *substream)
+{
+ struct snd_pcm_runtime *runtime = substream->runtime;
+
+ snd_pcm_hw_constraint_single(runtime, SNDRV_PCM_HW_PARAM_CHANNELS, 2);
+ return 0;
+}
+
+static int odroid_card_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params)
+{
+ struct snd_soc_pcm_runtime *rtd = substream->private_data;
+ struct odroid_priv *priv = snd_soc_card_get_drvdata(rtd->card);
+ unsigned int pll_freq, rclk_freq;
+ int ret;
+
+ switch (params_rate(params)) {
+ case 32000:
+ case 64000:
+ pll_freq = 131072000U;
+ break;
+ case 44100:
+ case 88200:
+ case 176400:
+ pll_freq = 180633600U;
+ break;
+ case 48000:
+ case 96000:
+ case 192000:
+ pll_freq = 196608000U;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ ret = clk_set_rate(priv->pll, pll_freq + 1);
+ if (ret < 0)
+ return ret;
+
+ rclk_freq = params_rate(params) * 256 * 4;
+
+ ret = clk_set_rate(priv->rclk, rclk_freq);
+ if (ret < 0)
+ return ret;
+
+ if (rtd->num_codecs > 1) {
+ struct snd_soc_dai *codec_dai = rtd->codec_dais[1];
+
+ ret = snd_soc_dai_set_sysclk(codec_dai, 0, rclk_freq,
+SND_SOC_CLOCK_IN);
+ if (ret < 0)
+ return ret;
+ }
+
+ return 0;
+}
+
+static const struct snd_soc_ops odroid_card_ops = {
+ .startup = odroid_card_startup,
+ .hw_params = odroid_card_hw_params,
+};
+
+static void odroid_put_codec_of_nodes(struct snd_soc_dai_link *link)
+{
+ struct snd_soc_dai_link_component *component = link->codecs;
+ int i;
+
+ for (i = 0; i < link->num_codecs; i++, component++) {
+ if (!component->of_node)
+ break;
+ of_node_put(component->of_node);
+ }
+}
+
+static int odroid_audio_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_nod
[PATCH RFC 7/7] ARM: dts: samsung: Switch to dedicated Odroid sound card binding
The new sound card DT binding is used for Odroid XU3 in order
to properly support the HDMI audio path.
Clocks configuration is changed so the I2S controller is now the bit
and the frame clock master with EPLL as the root clock source.
Signed-off-by: Sylwester Nawrocki
---
arch/arm/boot/dts/exynos4.dtsi| 1 +
arch/arm/boot/dts/exynos5420.dtsi | 1 +
arch/arm/boot/dts/exynos5422-odroidxu3-audio.dtsi | 59 ++-
3 files changed, 48 insertions(+), 13 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 18def1c..f3dcb7f 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -761,6 +761,7 @@
phy = <&hdmi_i2c_phy>;
power-domains = <&pd_tv>;
samsung,syscon-phandle = <&pmu_system_controller>;
+ #sound-dai-cells = <0>;
status = "disabled";
};
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 7dc9dc8..c7d29b6 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -618,6 +618,7 @@
samsung,syscon-phandle = <&pmu_system_controller>;
status = "disabled";
power-domains = <&disp_pd>;
+ #sound-dai-cells = <0>;
};
hdmiphy: hdmiphy@145D {
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-audio.dtsi
b/arch/arm/boot/dts/exynos5422-odroidxu3-audio.dtsi
index 9493923..84703f7 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-audio.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-audio.dtsi
@@ -11,15 +11,17 @@
* published by the Free Software Foundation.
*/
+#include
+
/ {
sound: sound {
- compatible = "simple-audio-card";
+ compatible = "samsung,odroid-xu3-audio";
+ model = "Odroid-XU3";
- simple-audio-card,name = "Odroid-XU3";
- simple-audio-card,widgets =
+ samsung,audio-widgets =
"Headphone", "Headphone Jack",
"Speakers", "Speakers";
- simple-audio-card,routing =
+ samsung,audio-routing =
"Headphone Jack", "HPL",
"Headphone Jack", "HPR",
"Headphone Jack", "MICBIAS",
@@ -27,22 +29,51 @@
"Speakers", "SPKL",
"Speakers", "SPKR";
- simple-audio-card,format = "i2s";
- simple-audio-card,bitclock-master = <&link0_codec>;
- simple-audio-card,frame-master = <&link0_codec>;
+ clocks = <&clock CLK_FOUT_EPLL>, <&i2s0 CLK_I2S_RCLK_SRC>;
+ clock-names = "epll", "i2s_rclk";
- simple-audio-card,cpu {
+ cpu {
sound-dai = <&i2s0 0>;
- system-clock-frequency = <1920>;
};
-
- link0_codec: simple-audio-card,codec {
- sound-dai = <&max98090>;
- clocks = <&i2s0 CLK_I2S_CDCLK>;
+ codec {
+ sound-dai = <&hdmi>, <&max98090>;
};
};
};
+&clock_audss {
+ assigned-clocks = <&clock_audss EXYNOS_DOUT_SRP>,
+ <&clock CLK_FOUT_EPLL>;
+ assigned-clock-rates = <(196608000 / 256)>,
+ <196608000>;
+};
+
+&sound {
+ assigned-clocks = <&clock CLK_MOUT_EPLL>,
+ <&clock CLK_MOUT_MAU_EPLL>,
+ <&clock CLK_MOUT_USER_MAU_EPLL>,
+ <&clock_audss EXYNOS_MOUT_AUDSS>,
+ <&clock_audss EXYNOS_MOUT_I2S>,
+ <&clock_audss EXYNOS_DOUT_SRP>,
+ <&clock_audss EXYNOS_DOUT_AUD_BUS>,
+ <&clock_audss EXYNOS_DOUT_I2S>;
+
+ assigned-clock-parents = <&clock CLK_FOUT_EPLL>,
+ <&clock CLK_MOUT_EPLL>,
+ <&clock CLK_MOUT_MAU_EPLL>,
+ <&clock CLK_MAU_EPLL>,
+ <&clock_audss EXYNOS_MOUT_AUDSS>;
+
+ assigned-clock-rates = <0>,
+ <0>,
+ <0>,
+ <0>,
+ <0>,
+ <196608000>,
+ <(196608000 / 2)>,
+ <196608000>;
+};
+
&hsi2c_5 {
status = "okay";
max98090: max98090@10 {
@@ -58,4 +89,6 @@
&i2s0 {
status = "okay";
+ assigned-clocks = <&i2s0 CLK_I2S_RCLK_SRC>;
+ assigned-clock-parents = <&clock_audss EXYNOS_SCLK_I2S>;
};
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Applied "ASoC: Add Odroid sound DT bindings documentation" to the asoc tree
On Fri, Apr 21, 2017 at 07:31:42PM +0200, Krzysztof Kozlowski wrote: > Although Sylwester is known of writing good quality code and can be > trusted but he posted it just 9 minutes ago. Isn't it a little bit too > fast to apply? I just finished reading cover letter but didn't manage > to start looking at the rest. :) It's pretty standard boilerplate stuff, there's not much in there to review and Sylwester is one of the maintainers listed for this code so I wasn't particularly expecting extra review. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Applied "ASoC: samsung: Add Odroid ASoC machine driver" to the asoc tree
The patch
ASoC: samsung: Add Odroid ASoC machine driver
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
From aba611fc4c69896f1355ff0b8ff0ff21c9b5b6fb Mon Sep 17 00:00:00 2001
From: Sylwester Nawrocki
Date: Fri, 21 Apr 2017 19:19:50 +0200
Subject: [PATCH] ASoC: samsung: Add Odroid ASoC machine driver
This dedicated driver allows to support SoC specific clock
settings and helps to ensure proper number of channels gets
negotiated in multicodec system configurations.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Mark Brown
---
sound/soc/samsung/Kconfig | 8 ++
sound/soc/samsung/Makefile | 2 +
sound/soc/samsung/odroid.c | 219 +
3 files changed, 229 insertions(+)
create mode 100644 sound/soc/samsung/odroid.c
diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig
index f1f1d7959a1b..0520f5afd7cc 100644
--- a/sound/soc/samsung/Kconfig
+++ b/sound/soc/samsung/Kconfig
@@ -185,6 +185,14 @@ config SND_SOC_SNOW
Say Y if you want to add audio support for various Snow
boards based on Exynos5 series of SoCs.
+config SND_SOC_ODROID
+ tristate "Audio support for Odroid XU3/XU4"
+ depends on SND_SOC_SAMSUNG && I2C
+ select SND_SOC_MAX98090
+ select SND_SAMSUNG_I2S
+ help
+ Say Y here to enable audio support for the Odroid XU3/XU4.
+
config SND_SOC_ARNDALE_RT5631_ALC5631
tristate "Audio support for RT5631(ALC5631) on Arndale Board"
depends on I2C
diff --git a/sound/soc/samsung/Makefile b/sound/soc/samsung/Makefile
index b5df5e2e3d94..b6c2ee358333 100644
--- a/sound/soc/samsung/Makefile
+++ b/sound/soc/samsung/Makefile
@@ -40,6 +40,7 @@ snd-soc-tobermory-objs := tobermory.o
snd-soc-lowland-objs := lowland.o
snd-soc-littlemill-objs := littlemill.o
snd-soc-bells-objs := bells.o
+snd-soc-odroid-objs := odroid.o
snd-soc-arndale-rt5631-objs := arndale_rt5631.o
snd-soc-tm2-wm5110-objs := tm2_wm5110.o
@@ -62,5 +63,6 @@ obj-$(CONFIG_SND_SOC_TOBERMORY) += snd-soc-tobermory.o
obj-$(CONFIG_SND_SOC_LOWLAND) += snd-soc-lowland.o
obj-$(CONFIG_SND_SOC_LITTLEMILL) += snd-soc-littlemill.o
obj-$(CONFIG_SND_SOC_BELLS) += snd-soc-bells.o
+obj-$(CONFIG_SND_SOC_ODROID) += snd-soc-odroid.o
obj-$(CONFIG_SND_SOC_ARNDALE_RT5631_ALC5631) += snd-soc-arndale-rt5631.o
obj-$(CONFIG_SND_SOC_SAMSUNG_TM2_WM5110) += snd-soc-tm2-wm5110.o
diff --git a/sound/soc/samsung/odroid.c b/sound/soc/samsung/odroid.c
new file mode 100644
index ..0c0b00e40646
--- /dev/null
+++ b/sound/soc/samsung/odroid.c
@@ -0,0 +1,219 @@
+/*
+ * Copyright (C) 2017 Samsung Electronics Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "i2s.h"
+#include "i2s-regs.h"
+
+struct odroid_priv {
+ struct snd_soc_card card;
+ struct snd_soc_dai_link dai_link;
+
+ struct clk *pll;
+ struct clk *rclk;
+};
+
+static int odroid_card_startup(struct snd_pcm_substream *substream)
+{
+ struct snd_pcm_runtime *runtime = substream->runtime;
+
+ snd_pcm_hw_constraint_single(runtime, SNDRV_PCM_HW_PARAM_CHANNELS, 2);
+ return 0;
+}
+
+static int odroid_card_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params)
+{
+ struct snd_soc_pcm_runtime *rtd = substream->private_data;
+ struct odroid_priv *priv = snd_soc_card_get_drvdata(rtd->card);
+ unsigned int pll_freq, rclk_freq;
+ int ret;
+
+ switch (params_rate(params)) {
+ case 32000:
+ case 64000:
+ pll_freq = 131072000U;
+ break;
+ case 44100:
+ case 88200:
+ case 176400:
+ pll_freq = 180633600U;
+ break;
+ case 48000:
+ case 96000:
+ case 192000:
+ pll_freq = 196608000U;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ ret = clk_set_rate(priv->pll, p
Re: [PULL] drm-misc-next-fixes
On Thu, Apr 20, 2017 at 11:50:02PM +0200, Daniel Vetter wrote: > On Thu, Apr 20, 2017 at 10:11 PM, Sean Paul wrote: > > Hi Dave, > > A few fixes for you to pick up. The driver changes are trivial, and the > > maintainer change was necessitated by the sti fix. The headliner here is the > > dma_buf_ops rename, since it touches so many drivers. Everything looks sane > > and > > builds with that change, so it shouldn't cause problems. > > > > > > drm-misc-next-fixes-2017-04-20: > > > > Core changes: > > - Maintain sti via drm-misc (Vincent) > > - Rename dma_buf_ops->kmap_* to avoid naming collision (Logan) > > This one touches v4l and ion and is acked by the corresponding > maintainers (but Sumit forgot to record that when applying the patch, > and Sean didn't highlight it in the summary). > > Sean, should we augment the template that cross-subsystem stuff > (outside of what's on-topic for drm-misc) needs to be highlighted > specifically in the pull summary? Yeah, I think that's reasonable. I'd like to think that I would have done a better job highlighting this had it been a standard header. Going forward, I'll add UABI and cross-sub headers to force myself to be more careful :) > > Off for vacation for real now. Enjoy! Sean > > Cheers, Daniel > > > > > Driver changes: > > - Fix UHD displays on stih407 (Vincent) > > - Fix uninitialized var return in atmel-hlcdc (Dan) > > > > Take care, Sean > > > > > > The following changes since commit 8cb68c83ab99a474ae847602f0c514d0fe17cc82: > > > > drm: Fix get_property logic fumble (2017-04-12 18:11:32 +0200) > > > > are available in the git repository at: > > > > git://anongit.freedesktop.org/git/drm-misc > > tags/drm-misc-next-fixes-2017-04-20 > > > > for you to fetch changes up to f9b67f0014cba18f1aabb6fa9272335a043eb6fd: > > > > dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro > > (2017-04-20 13:47:46 +0530) > > > > > > drm-misc-next-fixes-2017-04-20 > > > > Core changes: > > - Maintain sti via drm-misc (Vincent) > > - Rename dma_buf_ops->kmap_* to avoid naming collision (Logan) > > > > Driver changes: > > - Fix UHD displays on stih407 (Vincent) > > - Fix uninitialized var return in atmel-hlcdc (Dan) > > > > > > Dan Carpenter (1): > > drm: atmel-hlcdc: Uninitialized return in atmel_hlcdc_create_outputs() > > > > Logan Gunthorpe (1): > > dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro > > > > Vincent Abriou (2): > > MAINTAINERS: add drm/sti driver into drm-misc > > drm/sti: fix GDP size to support up to UHD resolution > > > > MAINTAINERS | 2 +- > > drivers/dma-buf/dma-buf.c| 16 > > drivers/gpu/drm/armada/armada_gem.c | 8 > > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 5 ++--- > > drivers/gpu/drm/drm_prime.c | 8 > > drivers/gpu/drm/i915/i915_gem_dmabuf.c | 8 > > drivers/gpu/drm/i915/selftests/mock_dmabuf.c | 8 > > drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c| 8 > > drivers/gpu/drm/sti/sti_gdp.c| 12 +++- > > drivers/gpu/drm/tegra/gem.c | 8 > > drivers/gpu/drm/udl/udl_dmabuf.c | 8 > > drivers/gpu/drm/vmwgfx/vmwgfx_prime.c| 8 > > drivers/media/v4l2-core/videobuf2-dma-contig.c | 4 ++-- > > drivers/media/v4l2-core/videobuf2-dma-sg.c | 4 ++-- > > drivers/media/v4l2-core/videobuf2-vmalloc.c | 4 ++-- > > drivers/staging/android/ion/ion.c| 8 > > include/linux/dma-buf.h | 22 > > +++--- > > 17 files changed, 71 insertions(+), 70 deletions(-) > > > > -- > > Sean Paul, Software Engineer, Google / Chromium OS > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
