[Bug 96492] Running Opera web-browser with forced hardware rendering cause GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=96492 russianneuromancer at ya.ru changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED --- Comment #4 from russianneuromancer at ya.ru --- Issue is not reproducible in Kubuntu 16.10 with Linux 4.8 and X.Org Server 1.18.4. (Tested Mesa releases 12.0.3, 13.0.2. 13.1-git.) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161220/8d31b457/attachment.html>
[Bug 99078] Desktop icons oversaturated with red after December 11 2016 update
https://bugs.freedesktop.org/show_bug.cgi?id=99078 --- Comment #12 from Furkan --- I'm experiencing a similar issue after updating to the same packages. I ran some tests last night, with Michel's suggestions on IRC. The problem goes away when I build Mesa against LLVM 3.8. So the bug was most likely introduced between with the LLVM update, going from 3.9.0 to 3.9.1rc3. Hopefully I'll get around to bisecting it to find the offending commit. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161220/8a008f56/attachment-0001.html>
[PATCH] drm/nouveau/dma: use rb_entry()
To make the code clearer, use rb_entry() instead of container_of() to
deal with rbtree.
Signed-off-by: Geliang Tang
---
drivers/gpu/drm/nouveau/nvkm/engine/dma/base.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/dma/base.c
b/drivers/gpu/drm/nouveau/nvkm/engine/dma/base.c
index f11ebdd..4655d17 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/dma/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/dma/base.c
@@ -34,7 +34,7 @@ nvkm_dma_search(struct nvkm_dma *dma, struct nvkm_client
*client, u64 object)
struct rb_node *node = client->dmaroot.rb_node;
while (node) {
struct nvkm_dmaobj *dmaobj =
- container_of(node, typeof(*dmaobj), rb);
+ rb_entry(node, typeof(*dmaobj), rb);
if (object < dmaobj->handle)
node = node->rb_left;
else
@@ -67,7 +67,7 @@ nvkm_dma_oclass_new(struct nvkm_device *device,
dmaobj->handle = oclass->object;
while (*ptr) {
- struct nvkm_dmaobj *obj = container_of(*ptr, typeof(*obj), rb);
+ struct nvkm_dmaobj *obj = rb_entry(*ptr, typeof(*obj), rb);
parent = *ptr;
if (dmaobj->handle < obj->handle)
ptr = &parent->rb_left;
--
2.9.3
[Bug 98897] Macbook pro 11,5 screen flicker when AC adapter plugged in
https://bugs.freedesktop.org/show_bug.cgi?id=98897 --- Comment #21 from berg --- I've still not noticed any problems with this patch, I accidentally left the top two git diff lines in the top of the patch file, this will probably cause patch command to fail if you don't remove them. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161220/3da80e57/attachment.html>
[Bug 93649] [radeonsi] Graphics lockup while playing tf2
https://bugs.freedesktop.org/show_bug.cgi?id=93649 --- Comment #77 from hofmann.zachary at gmail.com --- Oops, forgot to confirm the patch working here too. Yes, the game works without crashing now. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161220/25783faa/attachment.html>
[PATCH v2] drm: zte: add overlay plane support
From: Shawn Guo
It enables VOU VL (Video Layer) to support overlay plane with scaling
function. VL0 has some quirks on scaling support. We chose to skip it
and only adds VL1 and VL2 into DRM core for now.
Signed-off-by: Shawn Guo
---
Changes for v2:
- Use clipped coordinates for overlay position calculation
drivers/gpu/drm/zte/zx_plane.c | 293 ++--
drivers/gpu/drm/zte/zx_plane_regs.h | 51 +++
drivers/gpu/drm/zte/zx_vou.c| 149 +-
drivers/gpu/drm/zte/zx_vou.h| 3 +
drivers/gpu/drm/zte/zx_vou_regs.h | 18 +++
5 files changed, 497 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/zte/zx_plane.c b/drivers/gpu/drm/zte/zx_plane.c
index 546eb92a94e8..8cd7cf71b2b0 100644
--- a/drivers/gpu/drm/zte/zx_plane.c
+++ b/drivers/gpu/drm/zte/zx_plane.c
@@ -40,6 +40,269 @@ struct zx_plane {
DRM_FORMAT_ARGB,
};
+static const uint32_t vl_formats[] = {
+ DRM_FORMAT_NV12,/* Semi-planar YUV420 */
+ DRM_FORMAT_YUV420, /* Planar YUV420 */
+ DRM_FORMAT_YUYV,/* Packed YUV422 */
+ DRM_FORMAT_YVYU,
+ DRM_FORMAT_UYVY,
+ DRM_FORMAT_VYUY,
+ DRM_FORMAT_YUV444, /* YUV444 8bit */
+ /*
+* TODO: add formats below that HW supports:
+* - YUV420 P010
+* - YUV420 Hantro
+* - YUV444 10bit
+*/
+};
+
+#define FRAC_16_16(mult, div)(((mult) << 16) / (div))
+
+static int zx_vl_plane_atomic_check(struct drm_plane *plane,
+ struct drm_plane_state *plane_state)
+{
+ struct drm_framebuffer *fb = plane_state->fb;
+ struct drm_crtc *crtc = plane_state->crtc;
+ struct drm_crtc_state *crtc_state;
+ struct drm_rect clip;
+ int min_scale = FRAC_16_16(1, 8);
+ int max_scale = FRAC_16_16(8, 1);
+
+ if (!crtc || !fb)
+ return 0;
+
+ crtc_state = drm_atomic_get_existing_crtc_state(plane_state->state,
+ crtc);
+ if (WARN_ON(!crtc_state))
+ return -EINVAL;
+
+ /* nothing to check when disabling or disabled */
+ if (!crtc_state->enable)
+ return 0;
+
+ /* plane must be enabled */
+ if (!plane_state->crtc)
+ return -EINVAL;
+
+ clip.x1 = 0;
+ clip.y1 = 0;
+ clip.x2 = crtc_state->adjusted_mode.hdisplay;
+ clip.y2 = crtc_state->adjusted_mode.vdisplay;
+
+ return drm_plane_helper_check_state(plane_state, &clip,
+ min_scale, max_scale,
+ true, true);
+}
+
+static u32 zx_vl_get_fmt(uint32_t format)
+{
+ u32 val = 0;
+
+ switch (format) {
+ case DRM_FORMAT_NV12:
+ val = VL_FMT_YUV420;
+ break;
+ case DRM_FORMAT_YUV420:
+ val = VL_YUV420_PLANAR | VL_FMT_YUV420;
+ break;
+ case DRM_FORMAT_YUYV:
+ val = VL_YUV422_YUYV | VL_FMT_YUV422;
+ break;
+ case DRM_FORMAT_YVYU:
+ val = VL_YUV422_YVYU | VL_FMT_YUV422;
+ break;
+ case DRM_FORMAT_UYVY:
+ val = VL_YUV422_UYVY | VL_FMT_YUV422;
+ break;
+ case DRM_FORMAT_VYUY:
+ val = VL_YUV422_VYUY | VL_FMT_YUV422;
+ break;
+ case DRM_FORMAT_YUV444:
+ val = VL_FMT_YUV444_8BIT;
+ break;
+ default:
+ WARN_ONCE(1, "invalid pixel format %d\n", format);
+ }
+
+ return val;
+}
+
+static inline void zx_vl_set_update(struct zx_plane *zplane)
+{
+ void __iomem *layer = zplane->layer;
+
+ zx_writel_mask(layer + VL_CTRL0, VL_UPDATE, VL_UPDATE);
+}
+
+static inline void zx_vl_rsz_set_update(struct zx_plane *zplane)
+{
+ zx_writel(zplane->rsz + RSZ_VL_ENABLE_CFG, 1);
+}
+
+static u32 zx_vl_rsz_get_fmt(uint32_t format)
+{
+ u32 val = 0;
+
+ switch (format) {
+ case DRM_FORMAT_NV12:
+ case DRM_FORMAT_YUV420:
+ val = RSZ_VL_FMT_YCBCR420;
+ break;
+ case DRM_FORMAT_YUYV:
+ case DRM_FORMAT_YVYU:
+ case DRM_FORMAT_UYVY:
+ case DRM_FORMAT_VYUY:
+ val = RSZ_VL_FMT_YCBCR422;
+ break;
+ case DRM_FORMAT_YUV444:
+ val = RSZ_VL_FMT_YCBCR444;
+ break;
+ default:
+ WARN_ONCE(1, "invalid pixel format %d\n", format);
+ }
+
+ return val;
+}
+
+static inline u32 rsz_step_value(u32 src, u32 dst)
+{
+ u32 val = 0;
+
+ if (src == dst)
+ val = 0;
+ else if (src < dst)
+ val = RSZ_PARA_STEP((src << 16) / dst);
+ else if (src > dst)
+ val = RSZ_DATA_STEP(src / dst) |
+ RSZ_PARA_STEP(((src << 16) / dst) & 0x);
+
+ return val;
+}
+
+static void zx_vl_rsz_setup(struct
[PATCH] drm: zte: add overlay plane support
Hi Ville,
On Thu, Dec 08, 2016 at 05:57:55PM +0200, Ville Syrjälä wrote:
> On Thu, Dec 08, 2016 at 11:12:41AM +0800, Shawn Guo wrote:
>
> > +static void zx_vl_plane_atomic_update(struct drm_plane *plane,
> > + struct drm_plane_state *old_state)
> > +{
> > + struct zx_plane *zplane = to_zx_plane(plane);
> > + struct drm_framebuffer *fb = plane->state->fb;
> > + struct drm_gem_cma_object *cma_obj;
> > + void __iomem *layer = zplane->layer;
> > + void __iomem *hbsc = zplane->hbsc;
> > + void __iomem *paddr_reg;
> > + dma_addr_t paddr;
> > + u32 src_x, src_y, src_w, src_h;
> > + u32 dst_x, dst_y, dst_w, dst_h;
> > + uint32_t format;
> > + u32 fmt;
> > + int num_planes;
> > + int i;
> > +
> > + if (!fb)
> > + return;
> > +
> > + format = fb->pixel_format;
> > +
> > + src_x = plane->state->src_x >> 16;
> > + src_y = plane->state->src_y >> 16;
> > + src_w = plane->state->src_w >> 16;
> > + src_h = plane->state->src_h >> 16;
> > +
> > + dst_x = plane->state->crtc_x;
> > + dst_y = plane->state->crtc_y;
> > + dst_w = plane->state->crtc_w;
> > + dst_h = plane->state->crtc_h;
>
> This shouls use the clipped coordiantes.
Thanks for spotting this. I will fix it in v2.
Shawn
[pull] amdgpu drm-next-4.10
Hi Dave, Fixes for 4.10. Highlights: - fix display regression on DCE6/8 - Powergating fixes for GFX8 - amdgpu SI fixes (golden settings, proper rev id setup, etc.) The following changes since commit 2cf026ae85c42f253feb9f420d1b4bc99bd5503d: Merge branch 'linux-4.10' of git://github.com/skeggsb/linux into drm-next (2016-12-13 14:29:05 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-next-4.10 for you to fetch changes up to f8d9422ef80c5126112284493e69c88753c56ad1: drm/amdgpu: update tile table for oland/hainan (2016-12-20 19:43:39 -0500) Flora Cui (12): drm/amdgpu: fix cursor setting of dce6/dce8 drm/amdgpu: update golden setting/tiling table of tahiti drm/amdgpu: update golden setting for pitcairn drm/amdgpu: update rev id for pitcairn drm/amdgpu: update golden setting for hainan drm/amdgpu: update rev id for hainan drm/amdgpu: update golden setting for oland drm/amdgpu: update rev id for oland drm/amdgpu: update golden setting for verde drm/amdgpu: update rev id for verde drm/amdgpu: update tile table for verde drm/amdgpu: update tile table for oland/hainan Rex Zhu (9): drm/amdgpu: disable uvd pg on Tonga. drm/amdgpu: fix enable_cp_power_gating in gfx_v8.0. drm/amdgpu: fix init save/restore list in gfx_v8.0 drm/amdgpu: enable AMD_PG_SUPPORT_CP in Carrizo/Stoney. drm/amdgpu: always initialize gfx pg for gfx_v8.0. drm/amdgpu: fix pg can't be disabled by PG mask. drm/amdgpu: add new gfx cg flags. drm/amdgpu: initialize cg flags for tonga/polaris10/polaris11. drm/amdgpu: refine set clock gating for tonga/polaris drivers/gpu/drm/amd/amdgpu/dce_v6_0.c| 6 +- drivers/gpu/drm/amd/amdgpu/dce_v8_0.c| 2 - drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c| 935 ++- drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c| 249 +--- drivers/gpu/drm/amd/amdgpu/si.c | 442 --- drivers/gpu/drm/amd/amdgpu/vi.c | 211 +-- drivers/gpu/drm/amd/include/amd_shared.h | 4 + 7 files changed, 1218 insertions(+), 631 deletions(-)
[Bug 99136] Blood Effects Total War: Warhammer
https://bugs.freedesktop.org/show_bug.cgi?id=99136 --- Comment #1 from siyia --- Created attachment 128596 --> https://bugs.freedesktop.org/attachment.cgi?id=128596&action=edit blood bug this bug also persists with current mesa 13.1-git. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161220/885bb11f/attachment.html>
[PATCH 1/2] drm: Add new DRM_IOCTL_MODE_GETPLANE2
On Tue, Dec 20, 2016 at 7:12 PM, Kristian H. Kristensen
wrote:
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index ce7efe2..cea3de3 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -209,6 +209,33 @@ struct drm_mode_get_plane {
> __u64 format_type_ptr;
> };
>
> +struct drm_format_modifier {
> + /* Bitmask of formats in get_plane format list this info
> +* applies to. */
> + uint64_t formats;
Hmm, this seems a bit clunky/brittle when you have a lot of supported
formats (esp. if format order changes or new formats are not added at
end). I guess fine when you support a four or five different formats,
but I think you'll start to hate maintaining those tables on hw that
supports more.
Also I guess it limits you to modifiers only with the first 64
formats.. maybe not a problem right away, but a quick look and drm/msm
is already at 23 formats (and there are probably some more it could
do.. without even starting to get into "exotic" float/etc formats and
whatever else might come in the future.
Not that I really have a better idea.. maybe just instead of
getplane2 we just add a querymodifiers ioctl (ie. fourcc in, list of
modifiers out), with the idea that userspace probably knows what
format/fourcc it wants to use, and only just cares about modifiers for
that particular fourcc..
BR,
-R
> + /* This modifier can be used with the format for this plane. */
> + uint64_t modifier;
> +};
> +
[Bug 99163] Radeon HDMI audio lost after resuming from suspend on kernel >4.2
https://bugs.freedesktop.org/show_bug.cgi?id=99163 Alex Deucher changed: What|Removed |Added QA Contact|xorg-team at lists.x.org | Assignee|xorg-driver-ati at lists.x.org |dri-devel at lists.freedesktop ||.org Component|Driver/Radeon |DRM/Radeon Product|xorg|DRI -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161220/515390aa/attachment.html>
[PATCH v2 2/2] drm: Add Content Protection properties to drm
On Thu, Dec 4, 2014 at 8:03 PM, Sean Paul wrote: > Add new standard connector properties to track whether content protection > (ex: hdcp) is desired by userspace. There are two properties involved, > "Content Protection" and "Content Protection KSV". > > The "Content Protection" property allows userspace to request protection > on a connector. Set "Desired" to enable, "Undesired" to disable. > > The "Content Protection KSV" property reflects the current state of > protection. If the KSV is 0, the connection is not protected. Once the > driver has enabled protection, it will update the the value with the KSV > (or similarly unique identifier, if not using HDCP) of the first-hop > device (sink or repeater). > > Signed-off-by: Sean Paul > --- > > Changes in v2: > - Split property into 2 > - one for desired/undesired > - one for disabled/ksv So this came up again, and I have a slightly less abritrary opinion on the split vs. non-split property topic. My assumption was that we want to tell userspace the ksv so that it can do the blacklisting. But it sounds like at least all the designs with some kind of secure processor (maybe that's a hdcp2.x thing only) will do the blacklisting in that special processor and fail to set up encryption if the sink is blacklisted. So for those cases I think just the tri-state property + maybe some way to update the SRM (system renewability message iirc, aka The Blacklist) would be the better interface. We might still need the split approach that exposes the the ksv in a separate property. And for that probably still need a tri-state to lock down the ksv to a specific one, to allow userspace to blacklist it. But I think we should only add that once we have hw that needs it (doesn't seem the case for now after a quick irc chat). tldr; I'm leaning back to v1 ;-) Patch itself needs updating since properties are a bit more formal nowadays - we haz real docs, and we expect some core support for standardized props - something along the lines of the recently floated "link status" stuff is imo the new gold standard. Wrt naming bikeshed: I think we can just go with this since it's shipping in cros, makes the entire userspace thing much easier ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH v2 2/2] drm: parse hf-vsdb
HDMI 2.0 / CEA-861-F specs define a new CEA extension data block,
called hdmi-forum vendor specific data block (HF-VSDB). This block
contains information about sink's support for HDMI 2.0 compliant
features. These features are:
- Deep color YUV 420 support and BPC
- 3D flags for
- OSD Displarity
- Dual view signaling
- independent view signaling
- SCDC support
- Max TMDS char rate
- Scrambling support
This patch adds a parser function for this block, and add flags to
indicate support for new features, in drm_display_info structure
V2:
- Addressed review comments from Thierry
- remove len > 31 check
- remove version check
- fix duplicate values for macros of 36 and 30-bit depths
- Added a sub-class for HDMI related information within drm_display_info
(Thierry, Daniel) and populated it with HF-VSDB specific info.
Cc: Thierry Reding
Cc: Daniel Vetter
Cc: Jose Abreu
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/drm_edid.c | 70 ++
include/drm/drm_edid.h | 5
include/linux/hdmi.h | 1 +
3 files changed, 76 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index b552197..59e04fb 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3224,6 +3224,23 @@ static int add_3d_struct_modes(struct drm_connector
*connector, u16 structure,
return 0;
}
+static bool cea_db_is_hf_vsdb(const u8 *db)
+{
+ u8 len;
+ int hfvsdb_id;
+
+ if (cea_db_tag(db) != VENDOR_BLOCK)
+ return false;
+
+ len = cea_db_payload_len(db);
+ if (len < 7)
+ return false;
+
+ hfvsdb_id = db[1] | (db[2] << 8) | (db[3] << 16);
+
+ return hfvsdb_id == HDMI_IEEE_OUI_HFVSDB;
+}
+
static bool cea_db_is_hdmi_vsdb(const u8 *db)
{
int hdmi_id;
@@ -3768,6 +3785,57 @@ bool drm_rgb_quant_range_selectable(struct edid *edid)
}
EXPORT_SYMBOL(drm_rgb_quant_range_selectable);
+static void drm_parse_yuv420_deep_color_info(struct drm_connector *connector,
+ const u8 *db)
+{
+ struct drm_hdmi_info *info = &connector->display_info.hdmi_info;
+
+ if (db[7] & DRM_EDID_YUV420_DC_48)
+ info->edid_yuv420_dc_modes |= DRM_EDID_YUV420_DC_48;
+ if (db[7] & DRM_EDID_YUV420_DC_36)
+ info->edid_yuv420_dc_modes |= DRM_EDID_YUV420_DC_36;
+ if (db[7] & DRM_EDID_YUV420_DC_30)
+ info->edid_yuv420_dc_modes |= DRM_EDID_YUV420_DC_30;
+
+ if (!info->edid_yuv420_dc_modes) {
+ DRM_DEBUG("%s: No YUV 420 deep color support in sink.\n",
+ connector->name);
+ return;
+ }
+}
+
+static void
+drm_parse_hf_vsdb(struct drm_connector *connector, const u8 *db)
+{
+ struct drm_display_info *info = &connector->display_info;
+ struct drm_hdmi_info *hdmi_info = &info->hdmi_info;
+
+ if (db[5]) {
+ /*
+* If the sink supplies max tmds char rate in db,
+* the actual max tmds rate = db[5] * 5Mhz.
+*/
+ info->max_tmds_clock = db[5] * 5000;
+ DRM_DEBUG_KMS("HF-VSDB: max TMDS clock %d kHz\n",
+ info->max_tmds_clock);
+ }
+
+ if (db[6] & DRM_HFVSDB_SCDC_SUPPORT)
+ hdmi_info->scdc_supported = true;
+ if (db[6] & DRM_HFVSDB_SCDC_RR_CAP)
+ hdmi_info->scdc_rr_cap = true;
+ if (db[6] & DRM_HFVSDB_SCRAMBLING)
+ hdmi_info->scrambling = true;
+ if (db[6] & DRM_HFVSDB_INDEPENDENT_VIEW)
+ hdmi_info->independent_view_3d = true;
+ if (db[6] & DRM_HFVSDB_DUAL_VIEW)
+ hdmi_info->dual_view_3d = true;
+ if (db[6] & DRM_HFVSDB_3D_OSD)
+ hdmi_info->osd_disparity_3d = true;
+
+ drm_parse_yuv420_deep_color_info(connector, db);
+}
+
static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
const u8 *hdmi)
{
@@ -3882,6 +3950,8 @@ static void drm_parse_cea_ext(struct drm_connector
*connector,
if (cea_db_is_hdmi_vsdb(db))
drm_parse_hdmi_vsdb_video(connector, db);
+ if (cea_db_is_hf_vsdb(db))
+ drm_parse_hf_vsdb(connector, db);
}
}
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 38eabf6..df606e3 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -212,6 +212,11 @@ struct detailed_timing {
#define DRM_EDID_HDMI_DC_30 (1 << 4)
#define DRM_EDID_HDMI_DC_Y444 (1 << 3)
+/* YUV 420 deep color modes */
+#define DRM_EDID_YUV420_DC_48(1 << 6)
+#define DRM_EDID_YUV420_DC_36(1 << 5)
+#define DRM_EDID_YUV420_DC_30(1 << 4)
+
/* ELD Header Block */
#define DRM_ELD_HEADER_BLOCK_SIZE 4
diff --g
[PATCH v2 1/2] drm: Create new structure for HDMI info
This patch creates a new structure drm_hdmi_info (inspired from
drm_display_info). Driver will parse HDMI sink's advance capabilities
from HF-VSDB and populate this structure. This structure will be kept
and used as a sub-class within drm_display_info.
We are adding parsing of HF-VSDB In the next patch.
Cc: Thierry Reding
Cc: Daniel Vetter
Cc: Jose Abreu
Suggested-by: Thierry Reding
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/drm_edid.c | 6 ++--
include/drm/drm_connector.h | 79 ++---
2 files changed, 77 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 67d6a73..b552197 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3782,21 +3782,21 @@ static void drm_parse_hdmi_deep_color_info(struct
drm_connector *connector,
if (hdmi[6] & DRM_EDID_HDMI_DC_30) {
dc_bpc = 10;
- info->edid_hdmi_dc_modes |= DRM_EDID_HDMI_DC_30;
+ info->hdmi_info.edid_hdmi_dc_modes |= DRM_EDID_HDMI_DC_30;
DRM_DEBUG("%s: HDMI sink does deep color 30.\n",
connector->name);
}
if (hdmi[6] & DRM_EDID_HDMI_DC_36) {
dc_bpc = 12;
- info->edid_hdmi_dc_modes |= DRM_EDID_HDMI_DC_36;
+ info->hdmi_info.edid_hdmi_dc_modes |= DRM_EDID_HDMI_DC_36;
DRM_DEBUG("%s: HDMI sink does deep color 36.\n",
connector->name);
}
if (hdmi[6] & DRM_EDID_HDMI_DC_48) {
dc_bpc = 16;
- info->edid_hdmi_dc_modes |= DRM_EDID_HDMI_DC_48;
+ info->hdmi_info.edid_hdmi_dc_modes |= DRM_EDID_HDMI_DC_48;
DRM_DEBUG("%s: HDMI sink does deep color 48.\n",
connector->name);
}
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 6e352a0..fba2b88 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -90,6 +90,76 @@ enum subpixel_order {
};
/**
+ * struct drm_hdmi_info - runtime data specific to a connected hdmi sink
+ *
+ * Describes a given hdmi display (e.g. CRT or flat panel) and its
capabilities.
+ * Mostly refects the advanced features added in HDMI 2.0 specs and the deep
+ * color support. This is a sub-segment of struct drm_display_info and should
be
+ * used within.
+ *
+ * For sinks which provide an EDID this can be filled out by calling
+ * drm_add_edid_modes().
+ */
+
+struct drm_hdmi_info {
+
+ /**
+* @edid_hdmi_dc_modes: Mask of supported hdmi deep color modes. Even
+* more stuff redundant with @bus_formats.
+*/
+ u8 edid_hdmi_dc_modes;
+
+ /**
+* @edid_yuv420_dc_modes: bpc for deep color yuv420 encoding.
+* various sinks can support 10/12/16 bit per channel deep
+* color encoding. edid_yuv420_dc_modes = 0 means sink doesn't
+* support deep color yuv420 encoding.
+*/
+ u8 edid_yuv420_dc_modes;
+
+
+#define DRM_HFVSDB_SCDC_SUPPORT(1<<7)
+#define DRM_HFVSDB_SCDC_RR_CAP (1<<6)
+#define DRM_HFVSDB_SCRAMBLING (1<<3)
+#define DRM_HFVSDB_INDEPENDENT_VIEW(1<<2)
+#define DRM_HFVSDB_DUAL_VIEW (1<<1)
+#define DRM_HFVSDB_3D_OSD (1<<0)
+
+ /**
+* @scdc_supported: Sink supports SCDC functionality.
+*/
+ bool scdc_supported;
+
+ /**
+* @scdc_rr_cap: Sink has SCDC read request capability.
+*/
+ bool scdc_rr_cap;
+
+ /**
+* @scrambling: Sync supports scrambling for <=340 Mcsc TMDS
+* char rates. Above 340 Mcsc rates, scrambling is always reqd.
+*/
+ bool scrambling;
+
+ /**
+* @independent_view_3d: Sink supports 3d independent view signaling
+* in HF-VSIF.
+*/
+ bool independent_view_3d;
+
+ /**
+* @dual_view_3d: Sink supports 3d dual view signaling in HF-VSIF.
+*/
+ bool dual_view_3d;
+
+ /**
+* @osd_disparity_3d: Sink supports 3d osd disparity indication
+* in HF-VSIF.
+*/
+ bool osd_disparity_3d;
+};
+
+/**
* struct drm_display_info - runtime data about the connected sink
*
* Describes a given display (e.g. CRT or flat panel) and its limitations. For
@@ -179,15 +249,14 @@ struct drm_display_info {
bool dvi_dual;
/**
-* @edid_hdmi_dc_modes: Mask of supported hdmi deep color modes. Even
-* more stuff redundant with @bus_formats.
+* @cea_rev: CEA revision of the HDMI sink.
*/
- u8 edid_hdmi_dc_modes;
+ u8 cea_rev;
/**
-* @cea_rev: CEA revision of the HDMI sink.
+* @ drm_hdmi_info: Capabilities of connected HDMI display
*/
- u8 cea_rev;
+ struct drm_hdmi_info hdmi_info;
};
int drm_display_info_set_bus_formats(struct drm_display_info *info,
--
1.9.1
[Bug 107001] Radeon HDMI audio lost after resuming from suspend
https://bugzilla.kernel.org/show_bug.cgi?id=107001 --- Comment #4 from Timo Valtoaho --- ...and with 4.9.0. Sadly this has been bothering for over a year now. Anybody else suffering from this? -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drivers/gpu/drm/ast: Support reading configuration values from device tree
The ast driver configures a window to enable access into BMC memory space
in order to read some configuration registers. If this window is
disabled, which it can be from the BMC side, the ast driver can't
function. Closing this window is a necessity for security if a machine's
host side and BMC side are controlled by different parties; i.e. a cloud
provider offering machines "bare metal".
To work around this, enable reading these configuration values from the
device tree instead of through the window into BMC memory. This enables
the driver to work when the window is closed; if the window is open, the
driver functions as usual regardless of whether it uses the device tree
or register accesses.
Signed-off-by: Russell Currey
---
This patch applies on top of my other patch
"drivers/gpu/drm/ast: Fix infinite loop if read fails"
which was recently applied to drm-misc-fixes.
---
drivers/gpu/drm/ast/ast_main.c | 46 --
1 file changed, 31 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index f75c6421db62..9e362b4d913a 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -65,6 +65,7 @@ uint8_t ast_get_index_reg_mask(struct ast_private *ast,
static int ast_detect_chip(struct drm_device *dev, bool *need_post)
{
+ struct device_node *np = dev->pdev->dev.of_node;
struct ast_private *ast = dev->dev_private;
uint32_t data, jreg;
ast_open_key(ast);
@@ -140,10 +141,16 @@ static int ast_detect_chip(struct drm_device *dev, bool
*need_post)
ast->support_wide_screen = true;
else {
ast->support_wide_screen = false;
- /* Read SCU7c (silicon revision register) */
- ast_write32(ast, 0xf004, 0x1e6e);
- ast_write32(ast, 0xf000, 0x1);
- data = ast_read32(ast, 0x1207c);
+
+ if (!np || of_property_read_u32(np,
+ "ast,scu-revision-id",
+ &data)) {
+ /* Read SCU7c (silicon revision register) */
+ ast_write32(ast, 0xf004, 0x1e6e);
+ ast_write32(ast, 0xf000, 0x1);
+ data = ast_read32(ast, 0x1207c);
+ }
+
data &= 0x300;
if (ast->chip == AST2300 && data == 0x0) /* ast1300 */
ast->support_wide_screen = true;
@@ -212,21 +219,24 @@ static int ast_detect_chip(struct drm_device *dev, bool
*need_post)
static int ast_get_dram_info(struct drm_device *dev)
{
+ struct device_node *np = dev->pdev->dev.of_node;
struct ast_private *ast = dev->dev_private;
uint32_t data, data2;
uint32_t denum, num, div, ref_pll;
- ast_write32(ast, 0xf004, 0x1e6e);
- ast_write32(ast, 0xf000, 0x1);
+ if (!np || of_property_read_u32(np, "ast,mcr-configuration", &data)) {
+ ast_write32(ast, 0xf004, 0x1e6e);
+ ast_write32(ast, 0xf000, 0x1);
+ ast_write32(ast, 0x1, 0xfc600309);
- ast_write32(ast, 0x1, 0xfc600309);
-
- do {
- if (pci_channel_offline(dev->pdev))
- return -EIO;
- } while (ast_read32(ast, 0x1) != 0x01);
- data = ast_read32(ast, 0x10004);
+ /* poll until unlocked */
+ do {
+ if (pci_channel_offline(dev->pdev))
+ return -EIO;
+ } while (ast_read32(ast, 0x1) != 0x01);
+ data = ast_read32(ast, 0x10004);
+ }
if (data & 0x40)
ast->dram_bus_width = 16;
@@ -267,8 +277,14 @@ static int ast_get_dram_info(struct drm_device *dev)
}
}
- data = ast_read32(ast, 0x10120);
- data2 = ast_read32(ast, 0x10170);
+ if (!np || of_property_read_u32(np, "ast,mcr-scu-mpll", &data)) {
+ data = ast_read32(ast, 0x10120);
+ data2 = ast_read32(ast, 0x10170);
+ } else {
+ /* always 0 for AST2400 and AST2500 */
+ data2 = 0;
+ }
+
if (data2 & 0x2000)
ref_pll = 14318;
else
--
2.11.0
[PATCH 2/2] drm: Get atomic property value even if DRIVER_ATOMIC is not set
i915 does not set DRIVER_ATOMIC by default yet but uses atomic_check and atomic_commit. drm_object_property_get_value() does not read the correct value of atomic properties if DRIVER_ATOMIC is not set. Checking whether the driver uses atomic modeset is a better check instead as the property values are tracked in the state structures. Cc: Daniel Vetter Signed-off-by: Dhinakaran Pandiyan --- drivers/gpu/drm/drm_mode_object.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_mode_object.c b/drivers/gpu/drm/drm_mode_object.c index 9f17085..292d339 100644 --- a/drivers/gpu/drm/drm_mode_object.c +++ b/drivers/gpu/drm/drm_mode_object.c @@ -273,7 +273,7 @@ int drm_object_property_get_value(struct drm_mode_object *obj, * their value in obj->properties->values[].. mostly to avoid * having to deal w/ EDID and similar props in atomic paths: */ - if (drm_core_check_feature(property->dev, DRIVER_ATOMIC) && + if (drm_drv_uses_atomic_modeset(property->dev) && !(property->flags & DRM_MODE_PROP_IMMUTABLE)) return drm_atomic_get_property(obj, property, val); -- 2.7.4
[PATCH 1/2] drm: Wrap the check for atomic_commit implementation
This check is useful for drivers that do not have DRIVER_ATOMIC set but
have atomic modesetting internally implemented. Wrap the check into a
function since this is used in many places and as a bonus, the function
name helps to document what the check is for.
Suggested-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Ben Skeggs
Signed-off-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/drm_fb_helper.c | 6 +++---
drivers/gpu/drm/nouveau/nouveau_connector.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_display.c | 6 +++---
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 2 +-
include/drm/drmP.h | 5 +
5 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 145d55f..730342c 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -405,7 +405,7 @@ static int restore_fbdev_mode(struct drm_fb_helper
*fb_helper)
drm_warn_on_modeset_not_all_locked(dev);
- if (dev->mode_config.funcs->atomic_commit)
+ if (drm_drv_uses_atomic_modeset(dev))
return restore_fbdev_mode_atomic(fb_helper);
drm_for_each_plane(plane, dev) {
@@ -1444,7 +1444,7 @@ int drm_fb_helper_pan_display(struct fb_var_screeninfo
*var,
return -EBUSY;
}
- if (dev->mode_config.funcs->atomic_commit) {
+ if (drm_drv_uses_atomic_modeset(dev)) {
ret = pan_display_atomic(var, info);
goto unlock;
}
@@ -2060,7 +2060,7 @@ static int drm_pick_crtcs(struct drm_fb_helper *fb_helper,
* NULL we fallback to the default drm_atomic_helper_best_encoder()
* helper.
*/
- if (fb_helper->dev->mode_config.funcs->atomic_commit &&
+ if (drm_drv_uses_atomic_modeset(fb_helper->dev) &&
!connector_funcs->best_encoder)
encoder = drm_atomic_helper_best_encoder(connector);
else
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 947c200..c4cc21a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -769,7 +769,7 @@ nouveau_connector_set_property(struct drm_connector
*connector,
struct drm_encoder *encoder = to_drm_encoder(nv_encoder);
int ret;
- if (connector->dev->mode_config.funcs->atomic_commit)
+ if (drm_drv_uses_atomic_modeset(connector->dev))
return drm_atomic_helper_connector_set_property(connector,
property, value);
ret = connector->funcs->atomic_set_property(&nv_connector->base,
@@ -1074,7 +1074,7 @@ nouveau_connector_helper_funcs = {
static int
nouveau_connector_dpms(struct drm_connector *connector, int mode)
{
- if (connector->dev->mode_config.funcs->atomic_commit)
+ if (drm_drv_uses_atomic_modeset(connector->dev))
return drm_atomic_helper_connector_dpms(connector, mode);
return drm_helper_connector_dpms(connector, mode);
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index c5cf888..add353e 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -162,7 +162,7 @@ nouveau_display_vblstamp(struct drm_device *dev, unsigned
int pipe,
list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
if (nouveau_crtc(crtc)->index == pipe) {
struct drm_display_mode *mode;
- if (dev->mode_config.funcs->atomic_commit)
+ if (drm_drv_uses_atomic_modeset(dev))
mode = &crtc->state->adjusted_mode;
else
mode = &crtc->hwmode;
@@ -738,7 +738,7 @@ nouveau_display_suspend(struct drm_device *dev, bool
runtime)
struct nouveau_display *disp = nouveau_display(dev);
struct drm_crtc *crtc;
- if (dev->mode_config.funcs->atomic_commit) {
+ if (drm_drv_uses_atomic_modeset(dev)) {
if (!runtime) {
disp->suspend = nouveau_atomic_suspend(dev);
if (IS_ERR(disp->suspend)) {
@@ -784,7 +784,7 @@ nouveau_display_resume(struct drm_device *dev, bool runtime)
struct drm_crtc *crtc;
int ret;
- if (dev->mode_config.funcs->atomic_commit) {
+ if (drm_drv_uses_atomic_modeset(dev)) {
nouveau_display_init(dev);
if (disp->suspend) {
drm_atomic_helper_resume(dev, disp->suspend);
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index 5600f6c..ad722f14 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -524,7 +524,7 @@ nouveau_fbcon_init(struct drm_device *dev)
preferred_bpp = 32;
/* disable all the possible outp
[PATCH 2/2] rnndb: mdp5: Update mdp5_pipe
Update mdp5_pipe to incorporate SSPP_NONE and SSPP_CURSORx pipes Signed-off-by: Archit Taneja --- rnndb/mdp/mdp5.xml | 25 ++--- 1 file changed, 14 insertions(+), 11 deletions(-) diff --git a/rnndb/mdp/mdp5.xml b/rnndb/mdp/mdp5.xml index 49aa207..a5ae1e3 100644 --- a/rnndb/mdp/mdp5.xml +++ b/rnndb/mdp/mdp5.xml @@ -47,16 +47,19 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ rules-ng.xsd"> - - - - - - - - - - + + + + + + + + + + + + + @@ -291,7 +294,7 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ rules-ng.xsd"> - + -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
[PATCH 1/2] rnndb: mdp5: Add missing bitfields for MDP5_LM_BLEND_COLOR_OUT
Signed-off-by: Archit Taneja --- rnndb/mdp/mdp5.xml | 4 1 file changed, 4 insertions(+) diff --git a/rnndb/mdp/mdp5.xml b/rnndb/mdp/mdp5.xml index de9560b..49aa207 100644 --- a/rnndb/mdp/mdp5.xml +++ b/rnndb/mdp/mdp5.xml @@ -451,6 +451,10 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ rules-ng.xsd"> + + + + -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
[PATCH 0/2] rnndb: mdp5: Cursor related reg updates
Some cursor SSPP related updates. Archit Taneja (2): rnndb: mdp5: Add missing bitfields for MDP5_LM_BLEND_COLOR_OUT rnndb: mdp5: Update mdp5_pipe rnndb/mdp/mdp5.xml | 29 ++--- 1 file changed, 18 insertions(+), 11 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
[PATCH 2/2] modetest: Teach modetest about format info
From: "Kristian H. Kristensen"
BUG=chrome-os-partner:56407
TEST=modetest on a KMS driver that exposes modifiers should print those
Change-Id: I91b2a408b1c8f112d7ba5d0998119b3c800b199c
---
tests/modetest/modetest.c | 40
1 file changed, 36 insertions(+), 4 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index dedd286..091bcba 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -417,9 +417,30 @@ static void dump_framebuffers(struct device *dev)
printf("\n");
}
+static const char *
+mod_to_string(uint64_t mod, char *buf, int len)
+{
+ switch (mod) {
+ case DRM_FORMAT_MOD_NONE:
+ return "LINEAR";
+ case I915_FORMAT_MOD_X_TILED:
+ return "X_TILED";
+ case I915_FORMAT_MOD_Y_TILED:
+ return "Y_TILED";
+ case I915_FORMAT_MOD_Yf_TILED:
+ return "Yf_TILED";
+ case DRM_FORMAT_MOD_SAMSUNG_64_32_TILE:
+ return "SAMSUNG_64_32_TILE";
+ default:
+ snprintf(buf, len, "%016x", mod);
+ return buf;
+ }
+}
+
static void dump_planes(struct device *dev)
{
- unsigned int i, j;
+ unsigned int i, j, k;
+ char buf[17];
printf("Planes:\n");
printf("id\tcrtc\tfb\tCRTC x,y\tx,y\tgamma size\tpossible crtcs\n");
@@ -442,8 +463,19 @@ static void dump_planes(struct device *dev)
continue;
printf(" formats:");
- for (j = 0; j < ovr->count_formats; j++)
- printf(" %4.4s", (char *)&ovr->formats[j]);
+ for (j = 0; j < ovr->count_formats; j++) {
+ if (ovr->count_format_modifiers == 0) {
+ printf(" %4.4s", (char *)&ovr->formats[j]);
+ continue;
+ }
+ struct drm_format_modifier *fm;
+ for (k = 0; k < ovr->count_format_modifiers; k++) {
+ fm = &ovr->format_modifiers[k];
+ if (fm->formats & (1 << j))
+ printf(" %4.4s:%s", (char
*)&ovr->formats[j],
+ mod_to_string(fm->modifier, buf,
sizeof(buf)));
+ }
+ }
printf("\n");
if (plane->props) {
@@ -609,7 +641,7 @@ static struct resources *get_resources(struct device *dev)
if (!res->planes)
goto error;
- get_resource(res, plane_res, plane, Plane);
+ get_resource(res, plane_res, plane, Plane2);
get_properties(res, plane_res, plane, PLANE);
return res;
--
2.9.3
[PATCH 1/2] Add DRM_IOCTL_MODE_GETPLANE2 ioctl wrapper
From: "Kristian H. Kristensen"
This adds support for the new DRM_IOCTL_MODE_GETPLANE2 ioctl. For older
kernels drmModeGetPlane2() falls back to DRM_IOCTL_MODE_GETPLANE and
return the new, bigger drmModePlaneRec, reporting 0 modifiers.
BUG=chrome-os-partner:56407
TEST=modetest with next commit reports modifiers
Change-Id: I9cf9979c0b72933bad661fd03b9beebb36120dfd
---
include/drm/drm.h | 1 +
include/drm/drm_mode.h | 27 +++
xf86drmMode.c | 49 -
xf86drmMode.h | 4
4 files changed, 76 insertions(+), 5 deletions(-)
diff --git a/include/drm/drm.h b/include/drm/drm.h
index f6fd5c2..09d4262 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -799,6 +799,7 @@ extern "C" {
#define DRM_IOCTL_MODE_DESTROY_DUMBDRM_IOWR(0xB4, struct
drm_mode_destroy_dumb)
#define DRM_IOCTL_MODE_GETPLANERESOURCES DRM_IOWR(0xB5, struct
drm_mode_get_plane_res)
#define DRM_IOCTL_MODE_GETPLANEDRM_IOWR(0xB6, struct
drm_mode_get_plane)
+#define DRM_IOCTL_MODE_GETPLANE2 DRM_IOWR(0xB6, struct
drm_mode_get_plane2)
#define DRM_IOCTL_MODE_SETPLANEDRM_IOWR(0xB7, struct
drm_mode_set_plane)
#define DRM_IOCTL_MODE_ADDFB2 DRM_IOWR(0xB8, struct drm_mode_fb_cmd2)
#define DRM_IOCTL_MODE_OBJ_GETPROPERTIES DRM_IOWR(0xB9, struct
drm_mode_obj_get_properties)
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index df0e350..ce773fa 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -193,6 +193,33 @@ struct drm_mode_get_plane {
__u64 format_type_ptr;
};
+struct drm_format_modifier {
+ /* Bitmask of formats in get_plane format list this info
+* applies to. */
+ __u64 formats;
+
+ /* This modifier can be used with the format for this plane. */
+ __u64 modifier;
+};
+
+struct drm_mode_get_plane2 {
+ __u32 plane_id;
+
+ __u32 crtc_id;
+ __u32 fb_id;
+
+ __u32 possible_crtcs;
+ __u32 gamma_size;
+
+ __u32 count_format_types;
+ __u64 format_type_ptr;
+
+ /* New in v2 */
+ __u32 count_format_modifiers;
+ __u32 flags;
+ __u64 format_modifier_ptr;
+};
+
struct drm_mode_get_plane_res {
__u64 plane_id_ptr;
__u32 count_planes;
diff --git a/xf86drmMode.c b/xf86drmMode.c
index fb22f68..298d502 100644
--- a/xf86drmMode.c
+++ b/xf86drmMode.c
@@ -990,15 +990,15 @@ int drmModeSetPlane(int fd, uint32_t plane_id, uint32_t
crtc_id,
return DRM_IOCTL(fd, DRM_IOCTL_MODE_SETPLANE, &s);
}
-drmModePlanePtr drmModeGetPlane(int fd, uint32_t plane_id)
+static drmModePlanePtr get_plane(unsigned long cmd, int fd, uint32_t plane_id)
{
- struct drm_mode_get_plane ovr, counts;
+ struct drm_mode_get_plane2 ovr, counts;
drmModePlanePtr r = 0;
retry:
memclear(ovr);
ovr.plane_id = plane_id;
- if (drmIoctl(fd, DRM_IOCTL_MODE_GETPLANE, &ovr))
+ if (drmIoctl(fd, cmd, &ovr))
return 0;
counts = ovr;
@@ -1010,11 +1010,21 @@ retry:
goto err_allocs;
}
- if (drmIoctl(fd, DRM_IOCTL_MODE_GETPLANE, &ovr))
+ if (ovr.count_format_modifiers) {
+ ovr.format_modifier_ptr =
+ VOID2U64(drmMalloc(ovr.count_format_modifiers *
+ sizeof(struct drm_format_modifier)));
+ if (!ovr.format_modifier_ptr)
+ goto err_allocs;
+ }
+
+ if (drmIoctl(fd, cmd, &ovr))
goto err_allocs;
- if (counts.count_format_types < ovr.count_format_types) {
+ if (counts.count_format_types < ovr.count_format_types ||
+ counts.count_format_modifiers < ovr.count_format_modifiers) {
drmFree(U642VOID(ovr.format_type_ptr));
+ drmFree(U642VOID(ovr.format_modifier_ptr));
goto retry;
}
@@ -1022,6 +1032,7 @@ retry:
goto err_allocs;
r->count_formats = ovr.count_format_types;
+ r->count_format_modifiers = ovr.count_format_modifiers;
r->plane_id = ovr.plane_id;
r->crtc_id = ovr.crtc_id;
r->fb_id = ovr.fb_id;
@@ -1033,20 +1044,48 @@ retry:
drmFree(r->formats);
drmFree(r);
r = 0;
+ goto err_allocs;
+ }
+
+ r->format_modifiers =
+ drmAllocCpy(U642VOID(ovr.format_modifier_ptr),
+ ovr.count_format_modifiers,
+ sizeof(struct drm_format_modifier));
+ if (ovr.count_format_modifiers && !r->format_modifiers) {
+ drmFree(r->formats);
+ drmFree(r);
+ r = 0;
}
err_allocs:
drmFree(U642VOID(ovr.format_type_ptr));
+ drmFree(U642VOID(ovr.format_modifier_ptr));
return r;
}
+drmModePlanePtr drmModeGetPlane2(int fd, uint32_t plane_id)
+{
+ drmMod
[PATCH 2/2] i915: Add format modifiers for Intel
Signed-off-by: Kristian H. Kristensen
---
drivers/gpu/drm/i915/intel_display.c | 35 ---
drivers/gpu/drm/i915/intel_sprite.c | 36 +++-
2 files changed, 67 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 9c198fb..6150636 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -61,6 +61,11 @@ static const uint32_t i8xx_primary_formats[] = {
DRM_FORMAT_XRGB,
};
+static const struct drm_format_modifier i8xx_format_modifiers[] = {
+ { .formats = 0x0f, .modifier = DRM_FORMAT_MOD_NONE },
+ { .formats = 0x0f, .modifier = I915_FORMAT_MOD_X_TILED }
+};
+
/* Primary plane formats for gen >= 4 */
static const uint32_t i965_primary_formats[] = {
DRM_FORMAT_C8,
@@ -71,6 +76,11 @@ static const uint32_t i965_primary_formats[] = {
DRM_FORMAT_XBGR2101010,
};
+static const struct drm_format_modifier i965_format_modifiers[] = {
+ { .formats = 0x3f, .modifier = DRM_FORMAT_MOD_NONE },
+ { .formats = 0x3f, .modifier = I915_FORMAT_MOD_X_TILED }
+};
+
static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_C8,
DRM_FORMAT_RGB565,
@@ -86,6 +96,12 @@ static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_VYUY,
};
+static const struct drm_format_modifier skl_format_modifiers[] = {
+ { .formats = 0xfff, .modifier = DRM_FORMAT_MOD_NONE },
+ { .formats = 0xff, .modifier = I915_FORMAT_MOD_X_TILED },
+ { .formats = 0x3f, .modifier = I915_FORMAT_MOD_Y_TILED }
+};
+
/* Cursor formats */
static const uint32_t intel_cursor_formats[] = {
DRM_FORMAT_ARGB,
@@ -14962,6 +14978,8 @@ intel_primary_plane_create(struct drm_i915_private
*dev_priv, enum pipe pipe)
const uint32_t *intel_primary_formats;
unsigned int supported_rotations;
unsigned int num_formats;
+ const struct drm_format_modifier *intel_format_modifiers;
+ unsigned int num_format_modifiers;
int ret;
primary = kzalloc(sizeof(*primary), GFP_KERNEL);
@@ -14999,24 +15017,32 @@ intel_primary_plane_create(struct drm_i915_private
*dev_priv, enum pipe pipe)
if (INTEL_GEN(dev_priv) >= 9) {
intel_primary_formats = skl_primary_formats;
num_formats = ARRAY_SIZE(skl_primary_formats);
+ intel_format_modifiers = skl_format_modifiers;
+ num_format_modifiers = ARRAY_SIZE(skl_format_modifiers);
primary->update_plane = skylake_update_primary_plane;
primary->disable_plane = skylake_disable_primary_plane;
} else if (HAS_PCH_SPLIT(dev_priv)) {
intel_primary_formats = i965_primary_formats;
num_formats = ARRAY_SIZE(i965_primary_formats);
+ intel_format_modifiers = i965_format_modifiers;
+ num_format_modifiers = ARRAY_SIZE(i965_format_modifiers);
primary->update_plane = ironlake_update_primary_plane;
primary->disable_plane = i9xx_disable_primary_plane;
} else if (INTEL_GEN(dev_priv) >= 4) {
intel_primary_formats = i965_primary_formats;
num_formats = ARRAY_SIZE(i965_primary_formats);
+ intel_format_modifiers = i965_format_modifiers;
+ num_format_modifiers = ARRAY_SIZE(i965_format_modifiers);
primary->update_plane = i9xx_update_primary_plane;
primary->disable_plane = i9xx_disable_primary_plane;
} else {
intel_primary_formats = i8xx_primary_formats;
num_formats = ARRAY_SIZE(i8xx_primary_formats);
+ intel_format_modifiers = i8xx_format_modifiers;
+ num_format_modifiers = ARRAY_SIZE(i8xx_format_modifiers);
primary->update_plane = i9xx_update_primary_plane;
primary->disable_plane = i9xx_disable_primary_plane;
@@ -15026,21 +15052,24 @@ intel_primary_plane_create(struct drm_i915_private
*dev_priv, enum pipe pipe)
ret = drm_universal_plane_init(&dev_priv->drm, &primary->base,
0, &intel_plane_funcs,
intel_primary_formats,
num_formats,
- NULL, 0,
+ intel_format_modifiers,
+ num_format_modifiers,
DRM_PLANE_TYPE_PRIMARY,
"plane 1%c", pipe_name(pipe));
else if (INTEL_GEN(dev_priv) >= 5 || IS_G4X(dev_priv))
ret = drm_universal_plane_init(&dev_priv->drm, &primary->base,
0, &intel_plane_funcs,
intel_primary_formats,
num_for
[PATCH 1/2] drm: Add new DRM_IOCTL_MODE_GETPLANE2
From: "Kristian H. Kristensen"
This new ioctl exctends DRM_IOCTL_MODE_GETPLANE, by returning
information about the modifiers that will work with each format.
Signed-off-by: Kristian H. Kristensen
---
drivers/gpu/drm/arm/hdlcd_crtc.c| 1 +
drivers/gpu/drm/armada/armada_crtc.c| 1 +
drivers/gpu/drm/armada/armada_overlay.c | 1 +
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 4 ++-
drivers/gpu/drm/drm_ioctl.c | 2 +-
drivers/gpu/drm/drm_modeset_helper.c| 1 +
drivers/gpu/drm/drm_plane.c | 40 +++--
drivers/gpu/drm/drm_simple_kms_helper.c | 5
drivers/gpu/drm/exynos/exynos_drm_plane.c | 2 +-
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 2 +-
drivers/gpu/drm/i915/intel_display.c| 5 +++-
drivers/gpu/drm/imx/ipuv3-plane.c | 4 +--
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 2 +-
drivers/gpu/drm/nouveau/nv50_display.c | 5 ++--
drivers/gpu/drm/omapdrm/omap_plane.c| 3 +-
drivers/gpu/drm/rcar-du/rcar_du_plane.c | 4 +--
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 4 +--
drivers/gpu/drm/sti/sti_cursor.c| 1 +
drivers/gpu/drm/sti/sti_gdp.c | 2 +-
drivers/gpu/drm/sti/sti_hqvdp.c | 2 +-
drivers/gpu/drm/tegra/dc.c | 12
drivers/gpu/drm/vc4/vc4_plane.c | 2 +-
drivers/gpu/drm/virtio/virtgpu_plane.c | 2 +-
include/drm/drm_plane.h | 7 -
include/drm/drm_simple_kms_helper.h | 2 ++
include/uapi/drm/drm.h | 1 +
include/uapi/drm/drm_mode.h | 27 +
27 files changed, 116 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index 20ebfb4..6062578 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -283,6 +283,7 @@ static struct drm_plane *hdlcd_plane_init(struct drm_device
*drm)
ret = drm_universal_plane_init(drm, plane, 0xff, &hdlcd_plane_funcs,
formats, ARRAY_SIZE(formats),
+ NULL, 0,
DRM_PLANE_TYPE_PRIMARY, NULL);
if (ret) {
devm_kfree(drm->dev, plane);
diff --git a/drivers/gpu/drm/armada/armada_crtc.c
b/drivers/gpu/drm/armada/armada_crtc.c
index e62ee44..e1a6170 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -1250,6 +1250,7 @@ static int armada_drm_crtc_create(struct drm_device *drm,
struct device *dev,
&armada_primary_plane_funcs,
armada_primary_formats,
ARRAY_SIZE(armada_primary_formats),
+ NULL, 0,
DRM_PLANE_TYPE_PRIMARY, NULL);
if (ret) {
kfree(primary);
diff --git a/drivers/gpu/drm/armada/armada_overlay.c
b/drivers/gpu/drm/armada/armada_overlay.c
index 34cb73d..32fb8f3 100644
--- a/drivers/gpu/drm/armada/armada_overlay.c
+++ b/drivers/gpu/drm/armada/armada_overlay.c
@@ -458,6 +458,7 @@ int armada_overlay_plane_create(struct drm_device *dev,
unsigned long crtcs)
&armada_ovl_plane_funcs,
armada_ovl_formats,
ARRAY_SIZE(armada_ovl_formats),
+ NULL, 0,
DRM_PLANE_TYPE_OVERLAY, NULL);
if (ret) {
kfree(dplane);
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
index bd2791c..ac9e4db 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
@@ -1038,7 +1038,9 @@ atmel_hlcdc_plane_create(struct drm_device *dev,
ret = drm_universal_plane_init(dev, &plane->base, 0,
&layer_plane_funcs,
desc->formats->formats,
- desc->formats->nformats, type, NULL);
+ desc->formats->nformats,
+ NULL, 0,
+ type, NULL);
if (ret)
return ERR_PTR(ret);
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 59b6911..9724209 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -615,7 +615,7 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPLANERESOURCES, drm_mode_getplane_res,
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL
[PATCH v3 1/4] DRM: add help to get ELD speaker allocation
On Mon, 19 Dec 2016, Arnaud Pouliquen wrote:
> Add helper to allow users to retrieve the speaker allocations without
> knowledge of the ELD structure.
>
> Signed-off-by: Arnaud Pouliquen
I've already replied with my Reviewed-by, please take care to include
them.
Reviewed-by: Jani Nikula
> ---
> include/drm/drm_edid.h | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index c3a7d44..de93543 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -248,6 +248,7 @@ struct detailed_timing {
> # define DRM_ELD_AUD_SYNCH_DELAY_MAX 0xfa/* 500 ms */
>
> #define DRM_ELD_SPEAKER 7
> +# define DRM_ELD_SPEAKER_MASK0x7f
> # define DRM_ELD_SPEAKER_RLRC(1 << 6)
> # define DRM_ELD_SPEAKER_FLRC(1 << 5)
> # define DRM_ELD_SPEAKER_RC (1 << 4)
> @@ -415,6 +416,18 @@ static inline int drm_eld_size(const uint8_t *eld)
> }
>
> /**
> + * drm_eld_get_spk_alloc - Get speaker allocation
> + * @eld: pointer to an ELD memory structure
> + *
> + * The returned value is the speakers mask. User has to use %DRM_ELD_SPEAKER
> + * field definitions to identify speakers.
> + */
> +static inline u8 drm_eld_get_spk_alloc(const uint8_t *eld)
> +{
> + return eld[DRM_ELD_SPEAKER] & DRM_ELD_SPEAKER_MASK;
> +}
> +
> +/**
> * drm_eld_get_conn_type - Get device type hdmi/dp connected
> * @eld: pointer to an ELD memory structure
> *
--
Jani Nikula, Intel Open Source Technology Center
[PATCH v2 17/29] drm: bridge: dw-hdmi: Refactor PHY power handling
Hi Russell,
Thank you for the review.
On Tuesday 20 Dec 2016 11:45:53 Russell King - ARM Linux wrote:
> On Tue, Dec 20, 2016 at 03:33:48AM +0200, Laurent Pinchart wrote:
> > Instead of spreading version-dependent PHY power handling code around,
> > group it in two functions to power the PHY on and off and use them
> > through the driver.
> >
> > Powering off the PHY at the beginning of the setup phase is currently
> > split in two locations for first and second generation PHYs, group all
> > the operations in the dw_hdmi_phy_init() function.
>
> This changes the behaviour of the driver.
It does, but slightly only (I'm of course very aware that slightly can easily
be way too much :-)).
Let's analyse the differences, starting with PHY initialization in
dw_hdmi_phy_init(). Before this patch, the function calls
for (i = 0; i < 2; i++) {
dw_hdmi_phy_sel_data_en_pol(hdmi, 1);
dw_hdmi_phy_sel_interface_control(hdmi, 0);
dw_hdmi_phy_enable_tmds(hdmi, 0);
dw_hdmi_phy_enable_powerdown(hdmi, true);
/* Enable CSC */
ret = hdmi_phy_configure(hdmi, cscon);
if (ret)
return ret;
}
and hdmi_phy_configure() starts with (I've removed lines that don't touch the
hardware)
/* Enable csc path */
if (cscon)
val = HDMI_MC_FLOWCTRL_FEED_THROUGH_OFF_CSC_IN_PATH;
else
val = HDMI_MC_FLOWCTRL_FEED_THROUGH_OFF_CSC_BYPASS;
hdmi_writeb(hdmi, val, HDMI_MC_FLOWCTRL);
/* gen2 tx power off */
dw_hdmi_phy_gen2_txpwron(hdmi, 0);
/* gen2 pddq */
dw_hdmi_phy_gen2_pddq(hdmi, 1);
After the change, dw_hdmi_phy_init() calls
for (i = 0; i < 2; i++) {
dw_hdmi_phy_sel_data_en_pol(hdmi, 1);
dw_hdmi_phy_sel_interface_control(hdmi, 0);
/* Enable CSC */
ret = hdmi_phy_configure(hdmi, cscon);
if (ret)
return ret;
}
and hdmi_phy_configure() starts with
/* Enable csc path */
if (cscon)
val = HDMI_MC_FLOWCTRL_FEED_THROUGH_OFF_CSC_IN_PATH;
else
val = HDMI_MC_FLOWCTRL_FEED_THROUGH_OFF_CSC_BYPASS;
hdmi_writeb(hdmi, val, HDMI_MC_FLOWCTRL);
dw_hdmi_phy_power_off(hdmi);
with dw_hdmi_phy_power_off() defined as
if (hdmi->phy->gen == 1) {
dw_hdmi_phy_enable_tmds(hdmi, 0);
dw_hdmi_phy_enable_powerdown(hdmi, true);
} else {
dw_hdmi_phy_gen2_txpwron(hdmi, 0);
dw_hdmi_phy_gen2_pddq(hdmi, 1);
}
This patch thus changes the behaviour in two ways:
- Move the dw_hdmi_phy_enable_tmds() and dw_hdmi_phy_enable_powerdown() calls
after CSC configuration (HDMI_MC_FLOWCTRL).
- Only touch the power bits related to the PHY generation.
I believe the first change to be harmless. Furthermore, given that the i.MX6
and Rockchip SoCs use a Gen2 PHY, the TMDS and POWERDOWN bits should be no-
ops, so it should have no effect at all on those platforms.
I also believe the second change to be harmless as the TMDS and POWERDOWN bits
should be no-ops on i.MX6 and Rockchip. I have tested this patch series on
RK3288 and i.MX6Q and haven't noticed any regression.
The power on path should similarly be fine too, as the change
- dw_hdmi_phy_enable_powerdown(hdmi, false);
-
- /* toggle TMDS enable */
- dw_hdmi_phy_enable_tmds(hdmi, 0);
- dw_hdmi_phy_enable_tmds(hdmi, 1);
-
- /* gen2 tx power on */
- dw_hdmi_phy_gen2_txpwron(hdmi, 1);
- dw_hdmi_phy_gen2_pddq(hdmi, 0);
+ dw_hdmi_phy_power_on(hdmi);
results in
static void dw_hdmi_phy_power_on(struct dw_hdmi *hdmi)
{
if (hdmi->phy->gen == 1) {
dw_hdmi_phy_enable_powerdown(hdmi, false);
/* Toggle TMDS enable. */
dw_hdmi_phy_enable_tmds(hdmi, 0);
dw_hdmi_phy_enable_tmds(hdmi, 1);
} else {
dw_hdmi_phy_gen2_txpwron(hdmi, 1);
dw_hdmi_phy_gen2_pddq(hdmi, 0);
}
}
which splits the Gen1/Gen2 code but doesn't reorder anything.
The last change is in dw_hdmi_phy_disable(), see below.
> > +static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
> > +{
> > + if (hdmi->phy->gen == 1) {
> > + dw_hdmi_phy_enable_tmds(hdmi, 0);
> > + dw_hdmi_phy_enable_powerdown(hdmi, true);
> > + } else {
> > + dw_hdmi_phy_gen2_txpwron(hdmi, 0);
> > + dw_hdmi_phy_gen2_pddq(hdmi, 1);
> > + }
> > +}
> >
> > @@ -1290,9 +1302,7 @@ static void dw_hdmi_phy_disable(struct dw_hdmi
> > *hdmi)
> > if (!hdmi->phy_enabled)
> > return;
> >
> > - dw_hdmi_phy_enable_tmds(hdmi, 0);
> > - dw_hdmi_phy_enable_powerdown(hdmi, true);
> > -
> > + dw_hdmi_phy_power_off(hdmi);
>
> This makes dw_hdmi_phy_disable() power down
[PATCH v2 04/13] drm: Add data mirror bus flag
Hi Stefan,
Thank you for the review.
On Tuesday 20 Dec 2016 14:01:46 Stefan Agner wrote:
> On 2016-12-18 21:31, Laurent Pinchart wrote:
> > Hi Stefan and Thierry,
> >
> > As the author and suggester of the other bus flags, could you please
> > review this patch ?
>
> It looks to me like an appropriate use case for the flag. One remark
> below:
>
> > On Saturday 19 Nov 2016 05:28:04 Laurent Pinchart wrote:
> >> The flag indicates that data is mirrored on the bus. The exact meaning
> >> is bus-type dependent. For LVDS buses it indicates that the seven data
> >> bits that transmitted in a clock pulse are sent in slots 6 to 0 order.
> >>
> >> Signed-off-by: Laurent Pinchart
> >>
> >> ---
> >>
> >> include/drm/drm_connector.h | 2 ++
> >> 1 file changed, 2 insertions(+)
> >>
> >> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> >> index ac9d7d8e0e43..5c1dda236760 100644
> >> --- a/include/drm/drm_connector.h
> >> +++ b/include/drm/drm_connector.h
> >> @@ -159,6 +159,8 @@ struct drm_display_info {
> >>
> >> #define DRM_BUS_FLAG_PIXDATA_POSEDGE (1<<2)
> >> /* drive data on neg. edge */
> >> #define DRM_BUS_FLAG_PIXDATA_NEGEDGE (1<<3)
> >>
> >> +/* data is mirrored on the bus */
> >> +#define DRM_BUS_FLAG_DATA_MIRROR (1<<4)
>
> Sounds like a bit endianness issue. I am wondering is if "mirror" is a
> good term. Can we name the possible orderings? How about:
>
> DRM_BUS_FLAG_DATA_MSB_TO_LSB
> DRM_BUS_FLAG_DATA_LSB_TO_MSB
LVDS display buses send pixels in RGB666 or RGB888 as follows.
- "jeida-18" - 18-bit data mapping compatible with the [JEIDA], [LDI] and
[VESA] specifications. Data are transferred as follows on 3 LVDS lanes.
Slot0 1 2 3 4 5 6
_
Clock \___/
__ __ __ __ __ __ __
DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__><
DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__><
DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__><
- "jeida-24" - 24-bit data mapping compatible with the [DSIM] and [LDI]
specifications. Data are transferred as follows on 4 LVDS lanes.
Slot0 1 2 3 4 5 6
_
Clock \___/
__ __ __ __ __ __ __
DATA0 ><__G2__><__R7__><__R6__><__R5__><__R4__><__R3__><__R2__><
DATA1 ><__B3__><__B2__><__G7__><__G6__><__G5__><__G4__><__G3__><
DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B7__><__B6__><__B5__><__B4__><
DATA3 ><_CTL3_><__B1__><__B0__><__G1__><__G0__><__R1__><__R0__><
- "vesa-24" - 24-bit data mapping compatible with the [VESA] specification.
Data are transferred as follows on 4 LVDS lanes.
Slot0 1 2 3 4 5 6
_
Clock \___/
__ __ __ __ __ __ __
DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__><
DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__><
DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__><
DATA3 ><_CTL3_><__B7__><__B6__><__G7__><__G6__><__R7__><__R6__><
Mirroring flips slots 0 to 6, resulting in a sort of LSB to MSB transmission
(I'm not sure I'd call that endianness though). I'm fine renaming the flag as
you propose. Do we need two flags, or should we assume MSB to LSB by default
and add a single flag ?
> >>/**
> >> * @bus_flags: Additional information (like pixel signal polarity) for
--
Regards,
Laurent Pinchart
[PATCH] fbdev: remove current maintainer
On 19/12/16 15:34, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > On Thursday, December 15, 2016 12:12:52 PM Andrew Morton wrote: >> On Thu, 8 Dec 2016 10:34:12 +0200 Tomi Valkeinen >> wrote: >> >>> Remove Tomi Valkeinen from fbdev maintainer and mark fbdev as orphan. >>> >>> ... >>> >>> I just don't have time to even pretend I maintain fbdev, so mark it as >>> Orphan. >>> >>> Anyone want to pick fbdev maintainership? > > http://marc.info/?l=linux-fbdev&m=148181317415549&w=2 > >> I'll keep an eye on the mailing list, try to ensure that things keep >> ticking along. > > Andrew, do you want to manage patches yourself or should I step > in and try to do it? > > Tomi, in case I would end up handling patches your help would be > still greatly appreciated (I'm not much a fbdev expert so any > non-obvious stuff will likely take some time to be processed).. Yes, I can have a look (but no promises). But I'm no fbdev expert either =). I think I was mostly acting as a gate-keeper to sort the worst problems out. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161220/c71b35da/attachment.sig>
[PATCH v2 16/29] drm: bridge: dw-hdmi: Detect PHY type at runtime
Hi Jose,
On Tuesday 20 Dec 2016 11:39:21 Jose Abreu wrote:
> On 20-12-2016 01:33, Laurent Pinchart wrote:
> > Detect the PHY type and use it to handle the PHY type-specific SVSRET
> > signal.
> >
> > Signed-off-by: Laurent Pinchart
> >
> > ---
> >
> > drivers/gpu/drm/bridge/dw-hdmi.c | 68 +--
> > include/drm/bridge/dw_hdmi.h | 10 ++
> > 2 files changed, 75 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c
> > b/drivers/gpu/drm/bridge/dw-hdmi.c index f4faa14213e5..ef4f2f96ed2c
> > 100644
> > --- a/drivers/gpu/drm/bridge/dw-hdmi.c
> > +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
[snip]
> > struct i2c_adapter *ddc;
> > @@ -1015,7 +1023,8 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi,
> > int cscon)>
> > dw_hdmi_phy_gen2_txpwron(hdmi, 1);
> > dw_hdmi_phy_gen2_pddq(hdmi, 0);
> >
> > - if (hdmi->dev_type == RK3288_HDMI)
> > + /* The DWC MHL and HDMI 2.0 PHYs need the SVSRET signal to be set. */
> > + if (hdmi->phy->has_svsret)
> > dw_hdmi_phy_enable_svsret(hdmi, 1);
>
> I didn't review the original code but according to the docs the
> svsret signal should be set before de-asserting phy reset.
I don't have access to the documentation so I can't comment on that :-) What
does the SVSRET signal control (and what does the name stand for) ?
By de-asserting PHY reset, do you mean
/* PHY reset */
hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_DEASSERT, HDMI_MC_PHYRSTZ);
hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_ASSERT, HDMI_MC_PHYRSTZ);
? HDMI_MC_PHYRSTZ_DEASSERT is defined as 0x01 and HDMI_MC_PHYRSTZ_ASSERT as
0x00, which I believe leads to correct operation on Gen2 PHYs, but is
incorrect on Gen1 PHYs that have an active low reset signal. Could you confirm
that ? The DEASSERT and ASSERT macros should be renamed as they're obviously
incorrect.
I can move the SVSRET assertion before PHY reset and test it on RK3288 and R-
Car H3.
> > /*Wait for PHY PLL lock */
> >
> > @@ -1840,6 +1849,54 @@ static irqreturn_t dw_hdmi_irq(int irq, void
> > *dev_id)
> > return IRQ_HANDLED;
> > }
> >
> > +static const struct dw_hdmi_phy_data dw_hdmi_phys[] = {
> > + {
> > + .type = DW_HDMI_PHY_DWC_HDMI_TX_PHY,
> > + .name = "DWC HDMI TX PHY",
> > + }, {
> > + .type = DW_HDMI_PHY_DWC_MHL_PHY_HEAC,
> > + .name = "DWC MHL PHY + HEAC PHY",
> > + .has_svsret = true,
> > + }, {
> > + .type = DW_HDMI_PHY_DWC_MHL_PHY,
> > + .name = "DWC MHL PHY",
> > + .has_svsret = true,
> > + }, {
> > + .type = DW_HDMI_PHY_DWC_HDMI_3D_TX_PHY_HEAC,
> > + .name = "DWC HDMI 3D TX PHY + HEAC PHY",
> > + }, {
> > + .type = DW_HDMI_PHY_DWC_HDMI_3D_TX_PHY,
> > + .name = "DWC HDMI 3D TX PHY",
> > + }, {
> > + .type = DW_HDMI_PHY_DWC_HDMI20_TX_PHY,
> > + .name = "DWC HDMI 2.0 TX PHY",
> > + .has_svsret = true,
>
> Hmm, what I have here is that only MHL phys have svsret. Is this
> case for your phy?
The SoC datasheet mentions the SVSRET bit in the HDMI TX registers but doesn't
document it any further. If I don't set SVSRET the HDMI output stays dead, so
I assume I need to set it :-)
> > + }
> > +};
[snip]
--
Regards,
Laurent Pinchart
[PATCH v2 16/29] drm: bridge: dw-hdmi: Detect PHY type at runtime
Hi Laurent, On 20-12-2016 13:11, Laurent Pinchart wrote: > Hi Jose, > > On Tuesday 20 Dec 2016 11:39:21 Jose Abreu wrote: >> On 20-12-2016 01:33, Laurent Pinchart wrote: >>> Detect the PHY type and use it to handle the PHY type-specific SVSRET >>> signal. >>> >>> Signed-off-by: Laurent Pinchart >>> >>> --- >>> >>> drivers/gpu/drm/bridge/dw-hdmi.c | 68 +-- >>> include/drm/bridge/dw_hdmi.h | 10 ++ >>> 2 files changed, 75 insertions(+), 3 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c >>> b/drivers/gpu/drm/bridge/dw-hdmi.c index f4faa14213e5..ef4f2f96ed2c >>> 100644 >>> --- a/drivers/gpu/drm/bridge/dw-hdmi.c >>> +++ b/drivers/gpu/drm/bridge/dw-hdmi.c [snip] > I don't have access to the documentation so I can't comment on that :-) What > does the SVSRET signal control (and what does the name stand for) ? SVSRET stands for SVSRET :) (no idea what it means) Its a low power mode of consumption. > > By de-asserting PHY reset, do you mean > > /* PHY reset */ > hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_DEASSERT, HDMI_MC_PHYRSTZ); > hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_ASSERT, HDMI_MC_PHYRSTZ); > > ? HDMI_MC_PHYRSTZ_DEASSERT is defined as 0x01 and HDMI_MC_PHYRSTZ_ASSERT as > 0x00, which I believe leads to correct operation on Gen2 PHYs, but is > incorrect on Gen1 PHYs that have an active low reset signal. Could you > confirm > that ? The DEASSERT and ASSERT macros should be renamed as they're obviously > incorrect. Correct. Older phys require PHYRSTZ to be deasserted (i.e. low) for a PHY-dependent time. Newer phys require PHYRSTZ to be asserted (i.e. high) for, again, a PHY-dependent time. This is the kind of things that made me suggest you to extract all the phy configuration from dw-hdmi. I think that having a bunch of if's because of all the phy's that we need to support does not make much sense. The downside is, of course, having code duplicated. > > I can move the SVSRET assertion before PHY reset and test it on RK3288 and R- > Car H3. Probably wont make much difference unless you have a way to measure how much power the phy is consuming. But I think it is the right thing to do according to docs. [snip] > The SoC datasheet mentions the SVSRET bit in the HDMI TX registers but > doesn't > document it any further. If I don't set SVSRET the HDMI output stays dead, so > I assume I need to set it :-) > Hmm, ok. I still haven't figured out which phy you are using so can't comment much further. Best regards, Jose Miguel Abreu
[PATCH] drm/mediatek: Support UYVY and YUYV format for overlay
Hi Bibby, On Wed, 2016-12-14 at 13:14 +0800, Bibby Hsieh wrote: > MT8173 overlay can support UYVY and YUYV format, > we add the format in DRM driver. > > Signed-off-by: Bibby Hsieh > --- > drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 6 ++ > drivers/gpu/drm/mediatek/mtk_drm_plane.c | 2 ++ > 2 files changed, 8 insertions(+) > > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c > b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c > index 019b7ca..0a340f3 100644 > --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c > +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c > @@ -44,6 +44,8 @@ > #define OVL_CON_CLRFMT_RGB888(1 << 12) > #define OVL_CON_CLRFMT_RGBA (2 << 12) > #define OVL_CON_CLRFMT_ARGB (3 << 12) > +#define OVL_CON_CLRFMT_UYVY (4 << 12) > +#define OVL_CON_CLRFMT_YUYV (5 << 12) > #define OVL_CON_AEN BIT(8) > #define OVL_CON_ALPHA 0xff > > @@ -161,6 +163,10 @@ static unsigned int ovl_fmt_convert(unsigned int fmt) > case DRM_FORMAT_XBGR: > case DRM_FORMAT_ABGR: > return OVL_CON_CLRFMT_RGBA | OVL_CON_BYTE_SWAP; > + case DRM_FORMAT_YUYV: > + return OVL_CON_CLRFMT_YUYV; > + case DRM_FORMAT_UYVY: > + return OVL_CON_CLRFMT_UYVY; > } > } Your patch looks good, but I am not sure about some details. AFAIK, there is a color matrix here to describe how to transform from BT.601 / BT.709 / other color space to RGB color space. You can use the default value if you don't care how colors are represented. Or you can specify the matrix in this patch. Regards, yt.shen > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c > b/drivers/gpu/drm/mediatek/mtk_drm_plane.c > index c461a23..b94c6ee 100644 > --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c > +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c > @@ -28,6 +28,8 @@ > DRM_FORMAT_XRGB, > DRM_FORMAT_ARGB, > DRM_FORMAT_RGB565, > + DRM_FORMAT_YUYV, > + DRM_FORMAT_UYVY, > }; > > static void mtk_plane_reset(struct drm_plane *plane)
[Bug 99158] vdpau segfaults and gpu locks with kodi on R9285
https://bugs.freedesktop.org/show_bug.cgi?id=99158 --- Comment #2 from Michel Dänzer --- Can you try reproducing it in valgrind and see if that raises some interesting errors? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161220/c0f7b262/attachment.html>
[RFC 8/9] HACK: drm/msm/mdp5: Add support for legacy cursor updates
Op 20-12-16 om 07:23 schreef Archit Taneja: > > > On 12/19/2016 06:20 PM, Maarten Lankhorst wrote: >> Op 19-12-16 om 13:08 schreef Archit Taneja: >>> This code has been more or less picked up from the vc4 and intel >>> implementations of update_plane() funcs for cursor planes. >>> >>> The update_plane() func is usually the drm_atomic_helper_update_plane >>> func that will issue an atomic commit with the plane updates. Such >>> commits are not intended to be done faster than the vsync rate. >>> >>> The legacy cursor userspace API, on the other hand, expects the kernel >>> to handle cursor updates immediately. >>> >>> Create a fast path in update_plane, which updates the cursor registers >>> and flushes the configuration. The fast path is taken when there is only >>> a change in the cursor's position in the crtc, or a change in the >>> cursor's crop co-ordinates. For anything else, we go via the slow path. >>> >>> We take the slow path even whenever the fb changes, and even when there >>> is currently no fb tied to the plane. This should hopefully ensure that >>> we always take a slow path for every new fb. The slow path will ensure >>> that the fb is prepared/pinned etc. >>> >>> Cc: >>> Signed-off-by: Archit Taneja >>> --- >>> - Don't know what to do for locking here :/ >> Shouldn't patch 9 be done first before 8? > > Patch 9 introduces cursor drm_planes for the first time, so > anything done in 8 doesn't really take effect until we add > the planes in patch 9. So it's safe to have this order. The other way around will allow you to test with the normal atomic helpers first, and then if the hack breaks you're able to bisect it correctly and revert it, that's why I think it should be the other way around. :) ~Maarten
[PATCH v2 2/2] drm: parse hf-vsdb
Hi Shashank,
On 20-12-2016 13:47, Shashank Sharma wrote:
> HDMI 2.0 / CEA-861-F specs define a new CEA extension data block,
> called hdmi-forum vendor specific data block (HF-VSDB). This block
> contains information about sink's support for HDMI 2.0 compliant
> features. These features are:
> - Deep color YUV 420 support and BPC
> - 3D flags for
> - OSD Displarity
> - Dual view signaling
> - independent view signaling
> - SCDC support
> - Max TMDS char rate
> - Scrambling support
>
> This patch adds a parser function for this block, and add flags to
> indicate support for new features, in drm_display_info structure
>
> V2:
> - Addressed review comments from Thierry
> - remove len > 31 check
> - remove version check
> - fix duplicate values for macros of 36 and 30-bit depths
> - Added a sub-class for HDMI related information within drm_display_info
> (Thierry, Daniel) and populated it with HF-VSDB specific info.
>
> Cc: Thierry Reding
> Cc: Daniel Vetter
> Cc: Jose Abreu
> Signed-off-by: Shashank Sharma
> ---
> drivers/gpu/drm/drm_edid.c | 70
> ++
> include/drm/drm_edid.h | 5
> include/linux/hdmi.h | 1 +
> 3 files changed, 76 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index b552197..59e04fb 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3224,6 +3224,23 @@ static int add_3d_struct_modes(struct drm_connector
> *connector, u16 structure,
> return 0;
> }
>
> +static bool cea_db_is_hf_vsdb(const u8 *db)
> +{
> + u8 len;
> + int hfvsdb_id;
> +
> + if (cea_db_tag(db) != VENDOR_BLOCK)
> + return false;
> +
> + len = cea_db_payload_len(db);
> + if (len < 7)
> + return false;
> +
> + hfvsdb_id = db[1] | (db[2] << 8) | (db[3] << 16);
> +
> + return hfvsdb_id == HDMI_IEEE_OUI_HFVSDB;
> +}
> +
> static bool cea_db_is_hdmi_vsdb(const u8 *db)
> {
> int hdmi_id;
> @@ -3768,6 +3785,57 @@ bool drm_rgb_quant_range_selectable(struct edid *edid)
> }
> EXPORT_SYMBOL(drm_rgb_quant_range_selectable);
>
> +static void drm_parse_yuv420_deep_color_info(struct drm_connector *connector,
> + const u8 *db)
> +{
> + struct drm_hdmi_info *info = &connector->display_info.hdmi_info;
> +
> + if (db[7] & DRM_EDID_YUV420_DC_48)
> + info->edid_yuv420_dc_modes |= DRM_EDID_YUV420_DC_48;
> + if (db[7] & DRM_EDID_YUV420_DC_36)
> + info->edid_yuv420_dc_modes |= DRM_EDID_YUV420_DC_36;
> + if (db[7] & DRM_EDID_YUV420_DC_30)
> + info->edid_yuv420_dc_modes |= DRM_EDID_YUV420_DC_30;
> +
> + if (!info->edid_yuv420_dc_modes) {
> + DRM_DEBUG("%s: No YUV 420 deep color support in sink.\n",
> + connector->name);
> + return;
> + }
> +}
> +
> +static void
> +drm_parse_hf_vsdb(struct drm_connector *connector, const u8 *db)
> +{
> + struct drm_display_info *info = &connector->display_info;
> + struct drm_hdmi_info *hdmi_info = &info->hdmi_info;
> +
> + if (db[5]) {
> + /*
> + * If the sink supplies max tmds char rate in db,
> + * the actual max tmds rate = db[5] * 5Mhz.
> + */
> + info->max_tmds_clock = db[5] * 5000;
> + DRM_DEBUG_KMS("HF-VSDB: max TMDS clock %d kHz\n",
> + info->max_tmds_clock);
> + }
> +
> + if (db[6] & DRM_HFVSDB_SCDC_SUPPORT)
> + hdmi_info->scdc_supported = true;
> + if (db[6] & DRM_HFVSDB_SCDC_RR_CAP)
> + hdmi_info->scdc_rr_cap = true;
> + if (db[6] & DRM_HFVSDB_SCRAMBLING)
> + hdmi_info->scrambling = true;
According to spec you should also check if scdc is supported in
order to support scrambling.
> + if (db[6] & DRM_HFVSDB_INDEPENDENT_VIEW)
> + hdmi_info->independent_view_3d = true;
> + if (db[6] & DRM_HFVSDB_DUAL_VIEW)
> + hdmi_info->dual_view_3d = true;
> + if (db[6] & DRM_HFVSDB_3D_OSD)
> + hdmi_info->osd_disparity_3d = true;
> +
> + drm_parse_yuv420_deep_color_info(connector, db);
> +}
> +
> static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
> const u8 *hdmi)
> {
> @@ -3882,6 +3950,8 @@ static void drm_parse_cea_ext(struct drm_connector
> *connector,
>
> if (cea_db_is_hdmi_vsdb(db))
> drm_parse_hdmi_vsdb_video(connector, db);
> + if (cea_db_is_hf_vsdb(db))
> + drm_parse_hf_vsdb(connector, db);
> }
> }
>
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 38eabf6..df606e3 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -212,6 +212,11 @@ struct detailed_timing {
> #define DRM_EDID_HDMI_DC_30 (1 << 4
[PATCH v2 04/13] drm: Add data mirror bus flag
On 2016-12-20 14:21, Laurent Pinchart wrote:
> Hi Stefan,
>
> Thank you for the review.
>
> On Tuesday 20 Dec 2016 14:01:46 Stefan Agner wrote:
>> On 2016-12-18 21:31, Laurent Pinchart wrote:
>> > Hi Stefan and Thierry,
>> >
>> > As the author and suggester of the other bus flags, could you please
>> > review this patch ?
>>
>> It looks to me like an appropriate use case for the flag. One remark
>> below:
>>
>> > On Saturday 19 Nov 2016 05:28:04 Laurent Pinchart wrote:
>> >> The flag indicates that data is mirrored on the bus. The exact meaning
>> >> is bus-type dependent. For LVDS buses it indicates that the seven data
>> >> bits that transmitted in a clock pulse are sent in slots 6 to 0 order.
>> >>
>> >> Signed-off-by: Laurent Pinchart
>> >>
>> >> ---
>> >>
>> >> include/drm/drm_connector.h | 2 ++
>> >> 1 file changed, 2 insertions(+)
>> >>
>> >> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
>> >> index ac9d7d8e0e43..5c1dda236760 100644
>> >> --- a/include/drm/drm_connector.h
>> >> +++ b/include/drm/drm_connector.h
>> >> @@ -159,6 +159,8 @@ struct drm_display_info {
>> >>
>> >> #define DRM_BUS_FLAG_PIXDATA_POSEDGE (1<<2)
>> >> /* drive data on neg. edge */
>> >> #define DRM_BUS_FLAG_PIXDATA_NEGEDGE (1<<3)
>> >>
>> >> +/* data is mirrored on the bus */
>> >> +#define DRM_BUS_FLAG_DATA_MIRROR (1<<4)
>>
>> Sounds like a bit endianness issue. I am wondering is if "mirror" is a
>> good term. Can we name the possible orderings? How about:
>>
>> DRM_BUS_FLAG_DATA_MSB_TO_LSB
>> DRM_BUS_FLAG_DATA_LSB_TO_MSB
>
> LVDS display buses send pixels in RGB666 or RGB888 as follows.
>
> - "jeida-18" - 18-bit data mapping compatible with the [JEIDA], [LDI] and
> [VESA] specifications. Data are transferred as follows on 3 LVDS lanes.
>
> Slot 0 1 2 3 4 5 6
> _
> Clock \___/
> __ __ __ __ __ __ __
> DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__><
> DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__><
> DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__><
>
> - "jeida-24" - 24-bit data mapping compatible with the [DSIM] and [LDI]
> specifications. Data are transferred as follows on 4 LVDS lanes.
>
> Slot 0 1 2 3 4 5 6
> _
> Clock \___/
> __ __ __ __ __ __ __
> DATA0 ><__G2__><__R7__><__R6__><__R5__><__R4__><__R3__><__R2__><
> DATA1 ><__B3__><__B2__><__G7__><__G6__><__G5__><__G4__><__G3__><
> DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B7__><__B6__><__B5__><__B4__><
> DATA3 ><_CTL3_><__B1__><__B0__><__G1__><__G0__><__R1__><__R0__><
>
> - "vesa-24" - 24-bit data mapping compatible with the [VESA] specification.
> Data are transferred as follows on 4 LVDS lanes.
>
> Slot 0 1 2 3 4 5 6
> _
> Clock \___/
> __ __ __ __ __ __ __
> DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__><
> DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__><
> DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__><
> DATA3 ><_CTL3_><__B7__><__B6__><__G7__><__G6__><__R7__><__R6__><
>
>
> Mirroring flips slots 0 to 6, resulting in a sort of LSB to MSB transmission
> (I'm not sure I'd call that endianness though). I'm fine renaming the flag as
> you propose. Do we need two flags, or should we assume MSB to LSB by default
> and add a single flag ?
Wikipedia has a chapter about bit endianness, but I agree, I would not
call it that way; the term endianness usually refers to byte endianness.
For the other flags we usually have both variants. One variant is the
(unwritten) default for most displays (and most drivers/display
controllers configure it that way). And most displays only specify a
flag if they require the non-default setting.
I suggest to add both, just for the sake of completeness.
--
Stefan
>
>> >> /**
>> >>* @bus_flags: Additional information (like pixel signal polarity) for
[Bug 99143] r9 390: Hardware cursor invisible after hibernate/resume
https://bugs.freedesktop.org/show_bug.cgi?id=99143 --- Comment #3 from Michel Dänzer --- (In reply to Harald Judt from comment #2) > Unfortunately, the commit does not fix the problem. Just to make sure, you did update the drm-next-4.10-wip branch again before testing, right? The commit in question only appeared there after you submitted this report. If that commit really doesn't fix the problem, can you bisect which commit introduced it? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161220/bf0bdf6e/attachment.html>
[PATCH v3] drm: Improve drm_mm search (and fix topdown allocation) with rbtrees
The drm_mm range manager claimed to support top-down insertion, but it
was neither searching for the top-most hole that could fit the
allocation request nor fitting the request to the hole correctly.
In order to search the range efficiently, we create a secondary index
for the holes using either their size or their address. This index
allows us to find the smallest hole or the hole at the bottom or top of
the range efficiently, whilst keeping the hole stack to rapidly service
evictions.
v2: Search for holes both high and low. Rename flags to mode.
v3: Discover rb_entry_safe() and use it!
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 16 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 20 +-
drivers/gpu/drm/armada/armada_gem.c | 4 +-
drivers/gpu/drm/drm_mm.c | 511 +++
drivers/gpu/drm/drm_vma_manager.c| 3 +-
drivers/gpu/drm/etnaviv/etnaviv_mmu.c| 8 +-
drivers/gpu/drm/i915/i915_gem.c | 10 +-
drivers/gpu/drm/i915/i915_gem_evict.c| 9 +-
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 5 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 39 +-
drivers/gpu/drm/i915/i915_gem_stolen.c | 6 +-
drivers/gpu/drm/msm/msm_gem.c| 3 +-
drivers/gpu/drm/msm/msm_gem_vma.c| 3 +-
drivers/gpu/drm/selftests/test-drm_mm.c | 58 ++-
drivers/gpu/drm/sis/sis_mm.c | 6 +-
drivers/gpu/drm/tegra/gem.c | 4 +-
drivers/gpu/drm/ttm/ttm_bo_manager.c | 18 +-
drivers/gpu/drm/vc4/vc4_crtc.c | 2 +-
drivers/gpu/drm/vc4/vc4_hvs.c| 3 +-
drivers/gpu/drm/vc4/vc4_plane.c | 6 +-
drivers/gpu/drm/via/via_mm.c | 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 10 +-
include/drm/drm_mm.h | 135 +++
23 files changed, 434 insertions(+), 449 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index 00f46b0e076d..d841fcb2e709 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -97,8 +97,7 @@ int amdgpu_gtt_mgr_alloc(struct ttm_mem_type_manager *man,
{
struct amdgpu_gtt_mgr *mgr = man->priv;
struct drm_mm_node *node = mem->mm_node;
- enum drm_mm_search_flags sflags = DRM_MM_SEARCH_BEST;
- enum drm_mm_allocator_flags aflags = DRM_MM_CREATE_DEFAULT;
+ enum drm_mm_insert_mode mode;
unsigned long fpfn, lpfn;
int r;
@@ -115,15 +114,14 @@ int amdgpu_gtt_mgr_alloc(struct ttm_mem_type_manager *man,
else
lpfn = man->size;
- if (place && place->flags & TTM_PL_FLAG_TOPDOWN) {
- sflags = DRM_MM_SEARCH_BELOW;
- aflags = DRM_MM_CREATE_TOP;
- }
+ mode = DRM_MM_INSERT_BEST;
+ if (place && place->mode & TTM_PL_FLAG_TOPDOWN)
+ mode = DRM_MM_INSERT_HIGH;
spin_lock(&mgr->lock);
- r = drm_mm_insert_node_in_range_generic(&mgr->mm, node, mem->num_pages,
- mem->page_alignment, 0,
- fpfn, lpfn, sflags, aflags);
+ r = drm_mm_insert_node_in_range(&mgr->mm, node,
+ mem->num_pages, mem->page_alignment, 0,
+ fpfn, lpfn, mode);
spin_unlock(&mgr->lock);
if (!r) {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index d710226a0fff..5f106ad815ce 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -97,8 +97,7 @@ static int amdgpu_vram_mgr_new(struct ttm_mem_type_manager
*man,
struct amdgpu_vram_mgr *mgr = man->priv;
struct drm_mm *mm = &mgr->mm;
struct drm_mm_node *nodes;
- enum drm_mm_search_flags sflags = DRM_MM_SEARCH_DEFAULT;
- enum drm_mm_allocator_flags aflags = DRM_MM_CREATE_DEFAULT;
+ enum drm_mm_insert_mode mode;
unsigned long lpfn, num_nodes, pages_per_node, pages_left;
unsigned i;
int r;
@@ -121,10 +120,9 @@ static int amdgpu_vram_mgr_new(struct ttm_mem_type_manager
*man,
if (!nodes)
return -ENOMEM;
- if (place->flags & TTM_PL_FLAG_TOPDOWN) {
- sflags = DRM_MM_SEARCH_BELOW;
- aflags = DRM_MM_CREATE_TOP;
- }
+ mode = DRM_MM_INSERT_BEST;
+ if (place->flags & TTM_PL_FLAG_TOPDOWN)
+ mode = DRM_MM_INSERT_HIGH;
pages_left = mem->num_pages;
@@ -135,13 +133,11 @@ static int amdgpu_vram_mgr_new(struct
ttm_mem_type_manager *man,
if (pages == pages_per_node)
alignment = pages_per_node;
- else
- sfla
[PATCH v2 1/2] drm: Create new structure for HDMI info
Hi Shashank,
On 20-12-2016 13:47, Shashank Sharma wrote:
> This patch creates a new structure drm_hdmi_info (inspired from
> drm_display_info). Driver will parse HDMI sink's advance capabilities
> from HF-VSDB and populate this structure. This structure will be kept
> and used as a sub-class within drm_display_info.
You populate the structure but I think you should add a helper to
reset it when there is a new EDID or when the previous EDID is no
longer valid. The same applies to other fields in
drm_display_info structure. I've had problems before because of
incorrect values in this structure.
> We are adding parsing of HF-VSDB In the next patch.
>
> Cc: Thierry Reding
> Cc: Daniel Vetter
> Cc: Jose Abreu
> Suggested-by: Thierry Reding
> Signed-off-by: Shashank Sharma
> ---
> drivers/gpu/drm/drm_edid.c | 6 ++--
> include/drm/drm_connector.h | 79
> ++---
> 2 files changed, 77 insertions(+), 8 deletions(-)
>
[snip]
>
> /**
> + * struct drm_hdmi_info - runtime data specific to a connected hdmi sink
> + *
> + * Describes a given hdmi display (e.g. CRT or flat panel) and its
> capabilities.
> + * Mostly refects the advanced features added in HDMI 2.0 specs and the deep
> + * color support. This is a sub-segment of struct drm_display_info and
> should be
> + * used within.
> + *
> + * For sinks which provide an EDID this can be filled out by calling
> + * drm_add_edid_modes().
> + */
> +
> +struct drm_hdmi_info {
[snip]
> +
> + /**
> + * @edid_yuv420_dc_modes: bpc for deep color yuv420 encoding.
> + * various sinks can support 10/12/16 bit per channel deep
> + * color encoding. edid_yuv420_dc_modes = 0 means sink doesn't
> + * support deep color yuv420 encoding.
> + */
> + u8 edid_yuv420_dc_modes;
> +
> +
> +#define DRM_HFVSDB_SCDC_SUPPORT (1<<7)
> +#define DRM_HFVSDB_SCDC_RR_CAP (1<<6)
> +#define DRM_HFVSDB_SCRAMBLING(1<<3)
> +#define DRM_HFVSDB_INDEPENDENT_VIEW (1<<2)
> +#define DRM_HFVSDB_DUAL_VIEW (1<<1)
> +#define DRM_HFVSDB_3D_OSD(1<<0)
> +
> + /**
> + * @scdc_supported: Sink supports SCDC functionality.
> + */
> + bool scdc_supported;
> +
> + /**
> + * @scdc_rr_cap: Sink has SCDC read request capability.
> + */
> + bool scdc_rr_cap;
> +
> + /**
> + * @scrambling: Sync supports scrambling for <=340 Mcsc TMDS
> + * char rates. Above 340 Mcsc rates, scrambling is always reqd.
> + */
> + bool scrambling;
> +
> + /**
> + * @independent_view_3d: Sink supports 3d independent view signaling
> + * in HF-VSIF.
> + */
> + bool independent_view_3d;
> +
> + /**
> + * @dual_view_3d: Sink supports 3d dual view signaling in HF-VSIF.
> + */
> + bool dual_view_3d;
> +
> + /**
> + * @osd_disparity_3d: Sink supports 3d osd disparity indication
> + * in HF-VSIF.
> + */
> + bool osd_disparity_3d;
Maybe you should only add these fields in the second patch.
Best regards,
Jose Miguel Abreu
[PATCH v2 04/13] drm: Add data mirror bus flag
Hi Laurent,
On 2016-12-18 21:31, Laurent Pinchart wrote:
> Hi Stefan and Thierry,
>
> As the author and suggester of the other bus flags, could you please review
> this patch ?
It looks to me like an appropriate use case for the flag. One remark
below:
>
> On Saturday 19 Nov 2016 05:28:04 Laurent Pinchart wrote:
>> The flag indicates that data is mirrored on the bus. The exact meaning
>> is bus-type dependent. For LVDS buses it indicates that the seven data
>> bits that transmitted in a clock pulse are sent in slots 6 to 0 order.
>>
>> Signed-off-by: Laurent Pinchart > ideasonboard.com>
>> ---
>> include/drm/drm_connector.h | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
>> index ac9d7d8e0e43..5c1dda236760 100644
>> --- a/include/drm/drm_connector.h
>> +++ b/include/drm/drm_connector.h
>> @@ -159,6 +159,8 @@ struct drm_display_info {
>> #define DRM_BUS_FLAG_PIXDATA_POSEDGE(1<<2)
>> /* drive data on neg. edge */
>> #define DRM_BUS_FLAG_PIXDATA_NEGEDGE(1<<3)
>> +/* data is mirrored on the bus */
>> +#define DRM_BUS_FLAG_DATA_MIRROR(1<<4)
Sounds like a bit endianness issue. I am wondering is if "mirror" is a
good term. Can we name the possible orderings? How about:
DRM_BUS_FLAG_DATA_MSB_TO_LSB
DRM_BUS_FLAG_DATA_LSB_TO_MSB
--
Stefan
>>
>> /**
>> * @bus_flags: Additional information (like pixel signal polarity) for
[PATCH v2 17/29] drm: bridge: dw-hdmi: Refactor PHY power handling
Hi Russell,
On 20-12-2016 11:45, Russell King - ARM Linux wrote:
> On Tue, Dec 20, 2016 at 03:33:48AM +0200, Laurent Pinchart wrote:
>> Instead of spreading version-dependent PHY power handling code around,
>> group it in two functions to power the PHY on and off and use them
>> through the driver.
>>
>> Powering off the PHY at the beginning of the setup phase is currently
>> split in two locations for first and second generation PHYs, group all
>> the operations in the dw_hdmi_phy_init() function.
> This changes the behaviour of the driver.
>
>> +static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
>> +{
>> +if (hdmi->phy->gen == 1) {
>> +dw_hdmi_phy_enable_tmds(hdmi, 0);
>> +dw_hdmi_phy_enable_powerdown(hdmi, true);
>> +} else {
>> +dw_hdmi_phy_gen2_txpwron(hdmi, 0);
>> +dw_hdmi_phy_gen2_pddq(hdmi, 1);
>> +}
>> +}
>> @@ -1290,9 +1302,7 @@ static void dw_hdmi_phy_disable(struct dw_hdmi *hdmi)
>> if (!hdmi->phy_enabled)
>> return;
>>
>> -dw_hdmi_phy_enable_tmds(hdmi, 0);
>> -dw_hdmi_phy_enable_powerdown(hdmi, true);
>> -
>> +dw_hdmi_phy_power_off(hdmi);
> This makes dw_hdmi_phy_disable() power down a gen2 phy.
>
> The iMX6 has a DW_HDMI_PHY_DWC_HDMI_3D_TX_PHY phy, which you list as a
> gen2 phy. I've been carrying this change for a while, which I've had
> to revert (and finally expunge), as it causes problems on iMX6:
>
> @@ -1112,6 +1112,14 @@ static void dw_hdmi_phy_disable(struct dw_hdmi *hdmi)
> if (!hdmi->phy_enabled)
> return;
>
> + /* Actually set the phy into low power mode */
> + dw_hdmi_phy_gen2_txpwron(hdmi, 0);
> +
> + /* FIXME: We should wait for TX_READY to be deasserted */
> +
> + dw_hdmi_phy_gen2_pddq(hdmi, 1);
> +
> + /* This appears to have no effect on iMX6 */
> dw_hdmi_phy_enable_tmds(hdmi, 0);
> dw_hdmi_phy_enable_powerdown(hdmi, true);
>
> So, I think your change here will cause problems for iMX6.
>
> From what I remember, it seems that iMX6 has issues with RXSENSE/HPD
> bouncing when the PHY is powered down. I can't promise when I'll be
> able to check for that again.
>
Indeed TX_READY must be low before asserting pddq. HPD and
RXSENSE should work in power down mode by enabling enhpdrxsense
bit in phy_conf0 BUT to enter power down you must disable
TX_PWRON, enhpdrxsense and enable PDDQ and PHY _RESET. Only after
doing this (and consequently entering power down mode) you can
enable again enhpdrxsense.
Best regards,
Jose Miguel Abreu
[PATCH] drm/ttm: use designated initializers
On Sun, Dec 18, 2016 at 10:53 PM, Alexander Stein wrote: > Hello Kees, > > While understanding what your patches (I've seen the other ones as well) do > themself, I still don't get what your intention is, e.g. why you need this? > Apart from a better readability. > > On Friday 16 December 2016 16:59:29, Kees Cook wrote: >> Prepare to mark sensitive kernel structures for randomization by making >> sure they're using designated initializers. > > Can you please elaborate what you mean with that sentence? Hi! Sure: the coming (and optional) gcc plugin "randstruct" performs structure layout randomization, which means that static initializers cannot be "ordered" (they must be "designated"), since the place were layout randomization occurs happens separate from how static initializers are applied. This change from ordered to designated is just to help the compiler do the right thing. -Kees -- Kees Cook Nexus Security
[RFC 8/9] HACK: drm/msm/mdp5: Add support for legacy cursor updates
On 12/19/2016 06:20 PM, Maarten Lankhorst wrote: > Op 19-12-16 om 13:08 schreef Archit Taneja: >> This code has been more or less picked up from the vc4 and intel >> implementations of update_plane() funcs for cursor planes. >> >> The update_plane() func is usually the drm_atomic_helper_update_plane >> func that will issue an atomic commit with the plane updates. Such >> commits are not intended to be done faster than the vsync rate. >> >> The legacy cursor userspace API, on the other hand, expects the kernel >> to handle cursor updates immediately. >> >> Create a fast path in update_plane, which updates the cursor registers >> and flushes the configuration. The fast path is taken when there is only >> a change in the cursor's position in the crtc, or a change in the >> cursor's crop co-ordinates. For anything else, we go via the slow path. >> >> We take the slow path even whenever the fb changes, and even when there >> is currently no fb tied to the plane. This should hopefully ensure that >> we always take a slow path for every new fb. The slow path will ensure >> that the fb is prepared/pinned etc. >> >> Cc: >> Signed-off-by: Archit Taneja >> --- >> - Don't know what to do for locking here :/ > Shouldn't patch 9 be done first before 8? Patch 9 introduces cursor drm_planes for the first time, so anything done in 8 doesn't really take effect until we add the planes in patch 9. So it's safe to have this order. Archit > > ~Maarten > -- > To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
i915 regression in kernel 4.10
On Tue, Dec 20, 2016 at 09:42:46AM -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 19, 2016 at 03:16:44PM +0100, Juergen Gross wrote:
> > On 19/12/16 13:29, Chris Wilson wrote:
> > > On Mon, Dec 19, 2016 at 12:39:16PM +0100, Juergen Gross wrote:
> > >> With recent 4.10 kernel the graphics isn't coming up under Xen. First
> > >> failure message is:
> > >>
> > >> [ 46.656649] i915 :00:02.0: swiotlb buffer is full (sz: 1630208
> > >> bytes)
> > >
> > > Do we get a silent failure? i915_gem_gtt_prepare_pages() is where we
> > > call dma_map_sg() and pass the sg to swiotlb (in this case) for
> > > remapping, and we do check for an error value of 0. After that error,
> > > SWIOTLB_MAP_ERROR is propagated back and converted to 0 for
> > > dma_map_sg(). That looks valid, and we should report ENOMEM back to the
> > > caller.
> > >
> > >> Later I see splats like:
> > >>
> > >> [ 49.393583] general protection fault: [#1] SMP
> > >
> > > What was the faulting address? RAX is particularly non-pointer-like so I
> > > wonder if we walked onto an uninitialised portion of the sgtable. We may
> > > have tripped over a bug in our sg_page iterator.
> >
> > During the bisect process there have been either GP or NULL pointer
> > dereferences or other page faults. Typical addresses where:
> >
> > xen_swiotlb_unmap_sg_attrs+0x1f/0x50: access to 0018
> > xen_swiotlb_unmap_sg_attrs+0x1f/0x50: access to 03020118
> >
> > >
> > > The attached patch should prevent an early ENOMEM following the swiotlb
> > > allocation failure. But I suspect that we will still be tripping up the
> > > failure in the sg walker when binding to the GPU.
> > > -Chris
> > >
> >
> > The patch is working not too bad. :-)
> >
> > Still several "swiotlb buffer is full" messages (some with sz:, most
> > without), but no faults any more (neither GP nor NULL pointer
> > dereference). Graphical login is working now.
>
>
> I think I know why. The optimization that was added assumes that
> bus addresses is the same as physical address. Hence it packs all
> of the virtual addresses in the sg, and hands it off to SWIOTLB
> which walks each one and realizes that it has to use the bounce
> buffer.
>
> I am wondering if would make sense to pull 'swiotlb_max_size' inside
> of SWIOTLB and make it an library-ish - so Xen-SWIOTLB can register
> as well and report say that it can only provide one page
> (unless it is running under baremtal).
>
> Or make the usage of 'max_segement' and 'page_to_pfn(page) != last_pfn + 1'
> in i915_gem_object_Get_pages_gtt use something similar to
> xen_biovec_phys_mergeable?
Chris,
I was thinking of something like this (which Juergen has already tested).
>From f196f1294fd25f1402c3dd1231babb8d7f5db2e7 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk
Date: Tue, 20 Dec 2016 10:02:02 -0500
Subject: [PATCH] swiotlb: Export swiotlb_max_segment to users
So they can figure out what is the optimal number of pages
that can be contingously stitched together without fear of
bounce buffer.
We also expose an mechanism for sub-users of SWIOTLB API, such
as Xen-SWIOTLB to set the max segment value. And lastly
if swiotlb=force is set (which mandates we bounce buffer everything)
we set max_segment so at least we can bounce buffer one 4K page
instead of a giant 512KB one for which we may not have space.
Reported-and-Tested-by: Juergen Gross
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/i915/i915_gem.c | 11 +--
drivers/xen/swiotlb-xen.c | 4
include/linux/swiotlb.h | 3 +++
lib/swiotlb.c | 26 ++
4 files changed, 34 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d0dcaf3..115fa39 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2290,15 +2290,6 @@ void __i915_gem_object_put_pages(struct
drm_i915_gem_object *obj,
mutex_unlock(&obj->mm.lock);
}
-static unsigned int swiotlb_max_size(void)
-{
-#if IS_ENABLED(CONFIG_SWIOTLB)
- return rounddown(swiotlb_nr_tbl() << IO_TLB_SHIFT, PAGE_SIZE);
-#else
- return 0;
-#endif
-}
-
static void i915_sg_trim(struct sg_table *orig_st)
{
struct sg_table new_st;
@@ -2345,7 +2336,7 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object
*obj)
GEM_BUG_ON(obj->base.read_domains & I915_GEM_GPU_DOMAINS);
GEM_BUG_ON(obj->base.write_domain & I915_GEM_GPU_DOMAINS);
- max_segment = swiotlb_max_size();
+ max_segment = swiotlb_max_segment();
if (!max_segment)
max_segment = rounddown(UINT_MAX, PAGE_SIZE);
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index aba1200..f905d6e 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -275,6 +275,10 @@ int __ref xen_swiotlb_init(int verbose, bool early)
rc = 0;
} else
rc = swiotlb_late_in
[PATCH v2 17/29] drm: bridge: dw-hdmi: Refactor PHY power handling
On Tue, Dec 20, 2016 at 03:33:48AM +0200, Laurent Pinchart wrote:
> Instead of spreading version-dependent PHY power handling code around,
> group it in two functions to power the PHY on and off and use them
> through the driver.
>
> Powering off the PHY at the beginning of the setup phase is currently
> split in two locations for first and second generation PHYs, group all
> the operations in the dw_hdmi_phy_init() function.
This changes the behaviour of the driver.
> +static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
> +{
> + if (hdmi->phy->gen == 1) {
> + dw_hdmi_phy_enable_tmds(hdmi, 0);
> + dw_hdmi_phy_enable_powerdown(hdmi, true);
> + } else {
> + dw_hdmi_phy_gen2_txpwron(hdmi, 0);
> + dw_hdmi_phy_gen2_pddq(hdmi, 1);
> + }
> +}
> @@ -1290,9 +1302,7 @@ static void dw_hdmi_phy_disable(struct dw_hdmi *hdmi)
> if (!hdmi->phy_enabled)
> return;
>
> - dw_hdmi_phy_enable_tmds(hdmi, 0);
> - dw_hdmi_phy_enable_powerdown(hdmi, true);
> -
> + dw_hdmi_phy_power_off(hdmi);
This makes dw_hdmi_phy_disable() power down a gen2 phy.
The iMX6 has a DW_HDMI_PHY_DWC_HDMI_3D_TX_PHY phy, which you list as a
gen2 phy. I've been carrying this change for a while, which I've had
to revert (and finally expunge), as it causes problems on iMX6:
@@ -1112,6 +1112,14 @@ static void dw_hdmi_phy_disable(struct dw_hdmi *hdmi)
if (!hdmi->phy_enabled)
return;
+ /* Actually set the phy into low power mode */
+ dw_hdmi_phy_gen2_txpwron(hdmi, 0);
+
+ /* FIXME: We should wait for TX_READY to be deasserted */
+
+ dw_hdmi_phy_gen2_pddq(hdmi, 1);
+
+ /* This appears to have no effect on iMX6 */
dw_hdmi_phy_enable_tmds(hdmi, 0);
dw_hdmi_phy_enable_powerdown(hdmi, true);
So, I think your change here will cause problems for iMX6.
>From what I remember, it seems that iMX6 has issues with RXSENSE/HPD
bouncing when the PHY is powered down. I can't promise when I'll be
able to check for that again.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
[RFC 0/4] Introduce drmfs pseudo filesystem for drm subsystem
On Tue, 20 Dec 2016, Laurent Pinchart wrote: > Hi Swati, > > On Monday 19 Dec 2016 16:12:22 swati.dhingra at intel.com wrote: >> From: Swati Dhingra >> >> Currently, we don't have a stable ABI which can be used for the purpose of >> providing output debug/loggging/crc and other such data from DRM. >> The ABI in current use (filesystems, ioctls, et al.) have their own >> constraints and are intended to output a particular type of data. >> Few cases in point: >> sysfs- stable ABI, but constrained to one textual value per file >> debugfs - unstable ABI, free-for-all >> ioctls - not as suitable to many single purpose continuous data >>dumping, we would very quickly run out ioctl space; requires more >>userspace support than "cat" >> device nodes - a real possibilty, kernel instantiation is more tricky, >> requires udev (+udev.rules) or userspace discovery of the >> dynamic major:minor (via sysfs) [mounting a registered >> filesystem is easy in comparison] >> netlink - stream based, therefore involves numerous copies. >> >> Debugfs is the lesser among the evils here, thereby we have grown used to >> the convenience and flexibility in presentation that debugfs gives us >> (including relayfs inodes) that we want some of that hierachy in stable user >> ABI form. > > Seriously, why ? A subsystem growing its own file system sounds so wrong. It > seems that you want to have all the benefits of a stable ABI without going > through the standardization effort that this requires. I can see so many ways > that drmfs could be abused, with drivers throwing in new data with little or > no review. You'll need very compelling arguments to convince me. This is not unlike my sentiments on the first version posted [1]. There's also the distinct feeling of [2]. Suffice it to say at this time that I'm dubious, not convinced enough to defend this. Swati, please refrain from posting new versions of the patches until there's some consensus one way or the other; it's counter-productive to keep splitting off the discussion into several patch series threads at this stage. Let's have the discussion here. BR, Jani. [1] http://mid.mail-archive.com/87lgw0xcf4.fsf at intel.com [2] https://xkcd.com/927/ > >> Due to these limitations, there is a need for a new pseudo filesytem, that >> would act as a stable 'free-for-all' ABI, with the heirarchial structure and >> thus convenience of debugfs. This will be managed by drm, thus named >> 'drmfs'. DRM would register this filesystem to manage a canonical >> mountpoint, but this wouldn't limit everyone to only using that pseudofs >> underneath. >> >> This can serve to hold various kinds of output data from Linux DRM >> subsystems, for the files which can't truely fit anywhere else with >> existing ABI's but present so, for the lack of a better place. >> >> In this patch series, we have introduced a pseudo filesystem named as >> 'drmfs' for now. The filesystem is introduced in the first patch, and the >> subsequent patches make use of the filesystem interfaces, in drm driver, >> and making them available for use by the drm subsystem components, one of >> which is i915. We've moved the location of i915 GuC logs from debugfs to >> drmfs in the last patch. Subsequently, more such files such as pipe_crc, >> error states, memory stats, etc. can be move to this filesystem, if the >> idea introduced here is acceptable per se. The filesystem introduced is >> being used to house the data generated by i915 driver in this patch series, >> but will hopefully be generic enough to provide scope for usage by any >> other drm subsystem component. >> >> The patch series is being floated as RFC to gather feedback on the idea and >> infrastructure proposed here and it's suitability to address the specific >> problem statement/use case. >> >> v2: fix the bat failures caused due to missing config check >> >> v3: Changes made: >> - Move the location of drmfs from fs/ to drivers/gpu/drm/ (Chris) >> - Moving config checks to header (Chris,Daniel) >> >> v4: Added the kernel Documentaion (using Sphinx). >> >> Sourab Gupta (4): >> drm: Introduce drmfs pseudo filesystem interfaces >> drm: Register drmfs filesystem from drm init >> drm: Create driver specific root directory inside drmfs >> drm/i915: Creating guc log file in drmfs instead of debugfs >> >> Documentation/gpu/drm-uapi.rst | 76 >> drivers/gpu/drm/Kconfig| 9 + >> drivers/gpu/drm/Makefile | 1 + >> drivers/gpu/drm/drm_drv.c | 26 ++ >> drivers/gpu/drm/drmfs.c| 566 ++ >> drivers/gpu/drm/i915/i915_guc_submission.c | 33 +- >> include/drm/drm_drv.h | 3 + >> include/drm/drmfs.h| 77 >> include/uapi/linux/magic.h | 3 + >> 9 files changed, 773 insertions(+), 21
[PATCH v2 16/29] drm: bridge: dw-hdmi: Detect PHY type at runtime
Hi Laurent,
On 20-12-2016 01:33, Laurent Pinchart wrote:
> Detect the PHY type and use it to handle the PHY type-specific SVSRET
> signal.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/dw-hdmi.c | 68
> ++--
> include/drm/bridge/dw_hdmi.h | 10 ++
> 2 files changed, 75 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c
> b/drivers/gpu/drm/bridge/dw-hdmi.c
> index f4faa14213e5..ef4f2f96ed2c 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
> @@ -113,6 +113,12 @@ struct dw_hdmi_i2c {
> boolis_regaddr;
> };
>
> +struct dw_hdmi_phy_data {
> + enum dw_hdmi_phy_type type;
> + const char *name;
> + bool has_svsret;
> +};
> +
> struct dw_hdmi {
> struct drm_connector connector;
> struct drm_bridge bridge;
> @@ -134,7 +140,9 @@ struct dw_hdmi {
> u8 edid[HDMI_EDID_LEN];
> bool cable_plugin;
>
> + const struct dw_hdmi_phy_data *phy;
> bool phy_enabled;
> +
> struct drm_display_mode previous_mode;
>
> struct i2c_adapter *ddc;
> @@ -1015,7 +1023,8 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, int
> cscon)
> dw_hdmi_phy_gen2_txpwron(hdmi, 1);
> dw_hdmi_phy_gen2_pddq(hdmi, 0);
>
> - if (hdmi->dev_type == RK3288_HDMI)
> + /* The DWC MHL and HDMI 2.0 PHYs need the SVSRET signal to be set. */
> + if (hdmi->phy->has_svsret)
> dw_hdmi_phy_enable_svsret(hdmi, 1);
I didn't review the original code but according to the docs the
svsret signal should be set before de-asserting phy reset.
>
> /*Wait for PHY PLL lock */
> @@ -1840,6 +1849,54 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
> return IRQ_HANDLED;
> }
>
> +static const struct dw_hdmi_phy_data dw_hdmi_phys[] = {
> + {
> + .type = DW_HDMI_PHY_DWC_HDMI_TX_PHY,
> + .name = "DWC HDMI TX PHY",
> + }, {
> + .type = DW_HDMI_PHY_DWC_MHL_PHY_HEAC,
> + .name = "DWC MHL PHY + HEAC PHY",
> + .has_svsret = true,
> + }, {
> + .type = DW_HDMI_PHY_DWC_MHL_PHY,
> + .name = "DWC MHL PHY",
> + .has_svsret = true,
> + }, {
> + .type = DW_HDMI_PHY_DWC_HDMI_3D_TX_PHY_HEAC,
> + .name = "DWC HDMI 3D TX PHY + HEAC PHY",
> + }, {
> + .type = DW_HDMI_PHY_DWC_HDMI_3D_TX_PHY,
> + .name = "DWC HDMI 3D TX PHY",
> + }, {
> + .type = DW_HDMI_PHY_DWC_HDMI20_TX_PHY,
> + .name = "DWC HDMI 2.0 TX PHY",
> + .has_svsret = true,
Hmm, what I have here is that only MHL phys have svsret. Is this
case for your phy?
Best regards,
Jose Miguel Abreu
> + }
> +};
> +
> +static int dw_hdmi_detect_phy(struct dw_hdmi *hdmi)
> +{
> + unsigned int i;
> + u8 phy_type;
> +
> + phy_type = hdmi_readb(hdmi, HDMI_CONFIG2_ID);
> +
> + for (i = 0; i < ARRAY_SIZE(dw_hdmi_phys); ++i) {
> + if (dw_hdmi_phys[i].type == phy_type) {
> + hdmi->phy = &dw_hdmi_phys[i];
> + return 0;
> + }
> + }
> +
> + if (phy_type == DW_HDMI_PHY_VENDOR_PHY)
> + dev_err(hdmi->dev, "Unsupported vendor HDMI PHY\n");
> + else
> + dev_err(hdmi->dev, "Unsupported HDMI PHY type (%02x)\n",
> + phy_type);
> +
> + return -ENODEV;
> +}
> +
> static struct dw_hdmi *
> __dw_hdmi_probe(struct platform_device *pdev,
> const struct dw_hdmi_plat_data *plat_data)
> @@ -1950,9 +2007,14 @@ __dw_hdmi_probe(struct platform_device *pdev,
> goto err_iahb;
> }
>
> - dev_info(dev, "Detected HDMI TX controller v%x.%03x %s HDCP\n",
> + ret = dw_hdmi_detect_phy(hdmi);
> + if (ret < 0)
> + goto err_iahb;
> +
> + dev_info(dev, "Detected HDMI TX controller v%x.%03x %s HDCP (%s)\n",
>hdmi->version >> 12, hdmi->version & 0xfff,
> - prod_id1 & HDMI_PRODUCT_ID1_HDCP ? "with" : "without");
> + prod_id1 & HDMI_PRODUCT_ID1_HDCP ? "with" : "without",
> + hdmi->phy->name);
>
> initialize_hdmi_ih_mutes(hdmi);
>
> diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
> index 3bb22a849830..b080a171a23f 100644
> --- a/include/drm/bridge/dw_hdmi.h
> +++ b/include/drm/bridge/dw_hdmi.h
> @@ -27,6 +27,16 @@ enum dw_hdmi_devtype {
> RK3288_HDMI,
> };
>
> +enum dw_hdmi_phy_type {
> + DW_HDMI_PHY_DWC_HDMI_TX_PHY = 0x00,
> + DW_HDMI_PHY_DWC_MHL_PHY_HEAC = 0xb2,
> + DW_HDMI_PHY_DWC_MHL_PHY = 0xc2,
> + DW_HDMI_PHY_DWC_HDMI_3D_TX_PHY_HEAC = 0xe2,
> + DW_HDMI_PHY_DWC_HDMI_3D_TX_PHY = 0xf2,
> + DW_HDMI_PHY_DWC_HDMI20_TX_PHY = 0xf3,
> + DW_HDMI_PHY_VENDOR_PHY = 0xfe,
> +};
> +
> struct dw_hdmi_mpll_config {
> unsigned long mpixelclock;
> struct {
[PATCH] drm: remove immutable flag from suggested X/Y connector properties
The suggested X and Y connector properties are intended as a way for drivers
for virtual machine GPUs to provide information about the layout of the
host system windows (or whatever) corresponding to given guest connectors.
The intention is for the guest system to lay out screens in the virtual
desktop in a way which reflects the host layout. Sometimes though the guest
system chooses not to follow those hints, usually due to user requests. In
this case it is useful to be able to pass information back about the actual
layout chosen.
The immediate use case for this is host-to-guest pointer input mapping.
Qemu, VirtualBox and VMWare currently handle this by providing an emulated
graphics tablet device to the guest. libinput defaults, as did X.Org before
it used libinput, to mapping the position information reported by the device
to the smallest rectangle enclosing the screen layout. Knowing that layout
lets the hypervisor send the right position information through the input
device.
Signed-off-by: Michael Thayer
---
Follow-up to thread "Passing multi-screen layout to KMS driver". In that
thread, Gerd suggested an alternative way of solving the use case, namely
emulating one input device per virtual screen, touchscreen-style. My reasons
for prefering this approach is that it is relatively uninvasive, and closer
to the way things are done now without (in my opinion) being ugly; and that
automatic touchscreen input to screen mapping is still not a solved problem.
I think that both are valid though.
Both approaches require changes to the hypervisor and virtual hardware, and
to user-space consumers which would use the interface. I have checked the
mutter source and believe that the change required to support the interface
as implemented here would be minimal and intend to submit a patch if this
change is accepted. I think that the virtual hardware changes are likely to
be less invasive with this approach than with the other. This change will
though also require small drm driver changes once the virtual hardware has
been adjusted; currently to the qxl driver and to the out-of-tree vboxvideo
driver. It would certainly be nice to have in virtio-gpu.
Regards
Michael
Documentation/gpu/kms-properties.csv | 4 ++--
drivers/gpu/drm/drm_connector.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/gpu/kms-properties.csv
b/Documentation/gpu/kms-properties.csv
index 981873a..825238e 100644
--- a/Documentation/gpu/kms-properties.csv
+++ b/Documentation/gpu/kms-properties.csv
@@ -20,8 +20,8 @@ Owner Module/Drivers,Group,Property Name,Type,Property
Values,Object attached,De
,,âoverscanâ,RANGE,"Min=0, Max=100",Connector,TBD
,,âsaturationâ,RANGE,"Min=0, Max=100",Connector,TBD
,,âhueâ,RANGE,"Min=0, Max=100",Connector,TBD
-,Virtual GPU,âsuggested Xâ,RANGE,"Min=0,
Max=0x",Connector,property to suggest an X offset for a connector
-,,âsuggested Yâ,RANGE,"Min=0, Max=0x",Connector,property to
suggest an Y offset for a connector
+,Virtual GPU,âsuggested Xâ,RANGE,"Min=0,
Max=0x",Connector,"property to suggest an X offset for a connector to
help match positions of host windows and guest screens; can be set by the
driver for the host or user-space for the guest"
+,,âsuggested Yâ,RANGE,"Min=0, Max=0x",Connector,"property to
suggest an Y offset for a connector to help match positions of host windows and
guest screens; can be set by the driver for the host or user--space for the
guest"
,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9""
}",Connector,TDB
i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited
16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is
set, the hardware will be programmed with the result of the multiplication of
CTM by the limited range matrix to ensure the pixels normaly in the range
0..1.0 are remapped to the range 16/255..235/255."
,,âaudioâ,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on"" }",Connector,TBD
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 5a45262..ebb3cee 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -876,10 +876,10 @@ int drm_mode_create_suggested_offset_properties(struct
drm_device *dev)
return 0;
dev->mode_config.suggested_x_property =
- drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE,
"suggested X", 0, 0x);
+ drm_property_create_range(dev, 0, "suggested X", 0, 0x);
dev->mode_config.suggested_y_property =
- drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE,
"suggested Y", 0, 0x);
+ drm_property_create_range(dev, 0, "suggested Y", 0, 0x);
if (dev->mode_config.suggested_x_property == NULL ||
dev->mode_config.suggested_y_property == NULL)
--
2.9.3
[PATCH v2 15/29] drm: bridge: dw-hdmi: Handle overflow workaround based on device version
Hi Laurent,
On 20-12-2016 01:33, Laurent Pinchart wrote:
> Use the device version queried at runtime instead of the device type
> provided through platform data to handle the overflow workaround. This
> will make support of other SoCs integrating the same HDMI TX controller
> version easier.
>
> Among the supported platforms only i.MX6DL and i.MX6Q have been
> identified as needing the workaround. Disabling it on Rockchip RK3288
> (which integrates a v2.00a controller) didn't produce any error or
> artifact.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Jose Abreu
Best regards,
Jose Miguel Abreu
> ---
> drivers/gpu/drm/bridge/dw-hdmi.c | 46
>
> 1 file changed, 33 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c
> b/drivers/gpu/drm/bridge/dw-hdmi.c
> index 730a7558d4d4..f4faa14213e5 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
> @@ -117,8 +117,10 @@ struct dw_hdmi {
> struct drm_connector connector;
> struct drm_bridge bridge;
>
> - struct platform_device *audio;
> enum dw_hdmi_devtype dev_type;
> + unsigned int version;
> +
> + struct platform_device *audio;
> struct device *dev;
> struct clk *isfr_clk;
> struct clk *iahb_clk;
> @@ -1323,19 +1325,38 @@ static void hdmi_enable_audio_clk(struct dw_hdmi
> *hdmi)
> /* Workaround to clear the overflow condition */
> static void dw_hdmi_clear_overflow(struct dw_hdmi *hdmi)
> {
> - int count;
> + unsigned int count;
> + unsigned int i;
> u8 val;
>
> - /* TMDS software reset */
> - hdmi_writeb(hdmi, (u8)~HDMI_MC_SWRSTZ_TMDSSWRST_REQ, HDMI_MC_SWRSTZ);
> + /*
> + * Under some circumstances the Frame Composer arithmetic unit can miss
> + * an FC register write due to being busy processing the previous one.
> + * The issue can be worked around by issuing a TMDS software reset and
> + * then write one of the FC registers several times.
> + *
> + * The number of iterations matters and depends on the HDMI TX revision
> + * (and possibly on the platform). So far only i.MX6Q (v1.30a) and
> + * i.MX6DL (v1.31a) have been identified as needing the workaround, with
> + * 4 and 1 iterations respectively.
> + */
>
> - val = hdmi_readb(hdmi, HDMI_FC_INVIDCONF);
> - if (hdmi->dev_type == IMX6DL_HDMI) {
> - hdmi_writeb(hdmi, val, HDMI_FC_INVIDCONF);
> + switch (hdmi->version) {
> + case 0x130a:
> + count = 4;
> + break;
> + case 0x131a:
> + count = 1;
> + break;
> + default:
> return;
> }
>
> - for (count = 0; count < 4; count++)
> + /* TMDS software reset */
> + hdmi_writeb(hdmi, (u8)~HDMI_MC_SWRSTZ_TMDSSWRST_REQ, HDMI_MC_SWRSTZ);
> +
> + val = hdmi_readb(hdmi, HDMI_FC_INVIDCONF);
> + for (i = 0; i < count; i++)
> hdmi_writeb(hdmi, val, HDMI_FC_INVIDCONF);
> }
>
> @@ -1832,7 +1853,6 @@ __dw_hdmi_probe(struct platform_device *pdev,
> int irq;
> int ret;
> u32 val = 1;
> - u16 version;
> u8 prod_id0;
> u8 prod_id1;
> u8 config0;
> @@ -1917,21 +1937,21 @@ __dw_hdmi_probe(struct platform_device *pdev,
> }
>
> /* Product and revision IDs */
> - version = (hdmi_readb(hdmi, HDMI_DESIGN_ID) << 8)
> - | (hdmi_readb(hdmi, HDMI_REVISION_ID) << 0);
> + hdmi->version = (hdmi_readb(hdmi, HDMI_DESIGN_ID) << 8)
> + | (hdmi_readb(hdmi, HDMI_REVISION_ID) << 0);
> prod_id0 = hdmi_readb(hdmi, HDMI_PRODUCT_ID0);
> prod_id1 = hdmi_readb(hdmi, HDMI_PRODUCT_ID1);
>
> if (prod_id0 != HDMI_PRODUCT_ID0_HDMI_TX ||
> (prod_id1 & ~HDMI_PRODUCT_ID1_HDCP) != HDMI_PRODUCT_ID1_HDMI_TX) {
> dev_err(dev, "Unsupported HDMI controller (%04x:%02x:%02x)\n",
> - version, prod_id0, prod_id1);
> + hdmi->version, prod_id0, prod_id1);
> ret = -ENODEV;
> goto err_iahb;
> }
>
> dev_info(dev, "Detected HDMI TX controller v%x.%03x %s HDCP\n",
> - version >> 12, version & 0xfff,
> + hdmi->version >> 12, hdmi->version & 0xfff,
>prod_id1 & HDMI_PRODUCT_ID1_HDCP ? "with" : "without");
>
> initialize_hdmi_ih_mutes(hdmi);
[Bug 99158] vdpau segfaults and gpu locks with kodi on R9285
https://bugs.freedesktop.org/show_bug.cgi?id=99158 --- Comment #1 from Andy Furniss --- Created attachment 128584 --> https://bugs.freedesktop.org/attachment.cgi?id=128584&action=edit some gpu locks -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161220/bfd64ae0/attachment.html>
[Bug 99158] vdpau segfaults and gpu locks with kodi on R9285
https://bugs.freedesktop.org/show_bug.cgi?id=99158 Bug ID: 99158 Summary: vdpau segfaults and gpu locks with kodi on R9285 Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: adf.lists at gmail.com QA Contact: dri-devel at lists.freedesktop.org Created attachment 128583 --> https://bugs.freedesktop.org/attachment.cgi?id=128583&action=edit some segfaults This is an initial report no bisects as I have no clue when it started yet. It seems there is an unlucky timing situation with kodi that may segfault radeonsi or lock gpu playing videos with vdpau h/w decode + temporal vdpau deint which is default kodi settings. I can't reproduce with mplayer or mpv. It seems to need HD interlaced + deint, but that may be just because it changes timing. Running with VDPAU_TRACE=1 so far avoids the crash/lock, as does setting cpus to perf. Running kodi git, but it's reproducable with 11 month old git as well. It's easiest to provoke starting kodi with a file on command line, but is possible starting from running kodi menu - possible improved chance of crash/lock by moving mouse after clicking file to make overlay instantly render over video. Attaching some segfaults and locks. I am running git mesa/llvm/kernel and the crash is rare enough that I may have missed it for ages given the amount I test kodi. Additionally the best way to provoke = repeated command line start, only started being possible again ecently due to a kodi bug. The segfaults are a bit random. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161220/0cf2cdc8/attachment.html>
[PATCH] drm/amdgpu: use designated initializers
On Fri, Dec 16, 2016 at 8:02 PM, Kees Cook wrote:
> Prepare to mark sensitive kernel structures for randomization by making
> sure they're using designated initializers. These were identified during
> allyesconfig builds of x86, arm, and arm64, with most initializer fixes
> extracted from grsecurity.
>
> Signed-off-by: Kees Cook
Applied. thanks!
Alex
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c| 84
> +++---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c| 10 +--
> .../drm/amd/powerplay/hwmgr/cz_clockpowergating.c | 12 +++-
> drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c | 58 +++
> drivers/gpu/drm/amd/powerplay/hwmgr/smu7_thermal.c | 22 +++---
> 5 files changed, 96 insertions(+), 90 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
> index 9ada56c16a58..fd1ee40c41a2 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
> @@ -1197,51 +1197,51 @@ static int amdgpu_cgs_call_acpi_method(struct
> cgs_device *cgs_device,
> }
>
> static const struct cgs_ops amdgpu_cgs_ops = {
> - amdgpu_cgs_gpu_mem_info,
> - amdgpu_cgs_gmap_kmem,
> - amdgpu_cgs_gunmap_kmem,
> - amdgpu_cgs_alloc_gpu_mem,
> - amdgpu_cgs_free_gpu_mem,
> - amdgpu_cgs_gmap_gpu_mem,
> - amdgpu_cgs_gunmap_gpu_mem,
> - amdgpu_cgs_kmap_gpu_mem,
> - amdgpu_cgs_kunmap_gpu_mem,
> - amdgpu_cgs_read_register,
> - amdgpu_cgs_write_register,
> - amdgpu_cgs_read_ind_register,
> - amdgpu_cgs_write_ind_register,
> - amdgpu_cgs_read_pci_config_byte,
> - amdgpu_cgs_read_pci_config_word,
> - amdgpu_cgs_read_pci_config_dword,
> - amdgpu_cgs_write_pci_config_byte,
> - amdgpu_cgs_write_pci_config_word,
> - amdgpu_cgs_write_pci_config_dword,
> - amdgpu_cgs_get_pci_resource,
> - amdgpu_cgs_atom_get_data_table,
> - amdgpu_cgs_atom_get_cmd_table_revs,
> - amdgpu_cgs_atom_exec_cmd_table,
> - amdgpu_cgs_create_pm_request,
> - amdgpu_cgs_destroy_pm_request,
> - amdgpu_cgs_set_pm_request,
> - amdgpu_cgs_pm_request_clock,
> - amdgpu_cgs_pm_request_engine,
> - amdgpu_cgs_pm_query_clock_limits,
> - amdgpu_cgs_set_camera_voltages,
> - amdgpu_cgs_get_firmware_info,
> - amdgpu_cgs_rel_firmware,
> - amdgpu_cgs_set_powergating_state,
> - amdgpu_cgs_set_clockgating_state,
> - amdgpu_cgs_get_active_displays_info,
> - amdgpu_cgs_notify_dpm_enabled,
> - amdgpu_cgs_call_acpi_method,
> - amdgpu_cgs_query_system_info,
> - amdgpu_cgs_is_virtualization_enabled
> + .gpu_mem_info = amdgpu_cgs_gpu_mem_info,
> + .gmap_kmem = amdgpu_cgs_gmap_kmem,
> + .gunmap_kmem = amdgpu_cgs_gunmap_kmem,
> + .alloc_gpu_mem = amdgpu_cgs_alloc_gpu_mem,
> + .free_gpu_mem = amdgpu_cgs_free_gpu_mem,
> + .gmap_gpu_mem = amdgpu_cgs_gmap_gpu_mem,
> + .gunmap_gpu_mem = amdgpu_cgs_gunmap_gpu_mem,
> + .kmap_gpu_mem = amdgpu_cgs_kmap_gpu_mem,
> + .kunmap_gpu_mem = amdgpu_cgs_kunmap_gpu_mem,
> + .read_register = amdgpu_cgs_read_register,
> + .write_register = amdgpu_cgs_write_register,
> + .read_ind_register = amdgpu_cgs_read_ind_register,
> + .write_ind_register = amdgpu_cgs_write_ind_register,
> + .read_pci_config_byte = amdgpu_cgs_read_pci_config_byte,
> + .read_pci_config_word = amdgpu_cgs_read_pci_config_word,
> + .read_pci_config_dword = amdgpu_cgs_read_pci_config_dword,
> + .write_pci_config_byte = amdgpu_cgs_write_pci_config_byte,
> + .write_pci_config_word = amdgpu_cgs_write_pci_config_word,
> + .write_pci_config_dword = amdgpu_cgs_write_pci_config_dword,
> + .get_pci_resource = amdgpu_cgs_get_pci_resource,
> + .atom_get_data_table = amdgpu_cgs_atom_get_data_table,
> + .atom_get_cmd_table_revs = amdgpu_cgs_atom_get_cmd_table_revs,
> + .atom_exec_cmd_table = amdgpu_cgs_atom_exec_cmd_table,
> + .create_pm_request = amdgpu_cgs_create_pm_request,
> + .destroy_pm_request = amdgpu_cgs_destroy_pm_request,
> + .set_pm_request = amdgpu_cgs_set_pm_request,
> + .pm_request_clock = amdgpu_cgs_pm_request_clock,
> + .pm_request_engine = amdgpu_cgs_pm_request_engine,
> + .pm_query_clock_limits = amdgpu_cgs_pm_query_clock_limits,
> + .set_camera_voltages = amdgpu_cgs_set_camera_voltages,
> + .get_firmware_info = amdgpu_cgs_get_firmware_info,
> + .rel_firmware = amdgpu_cgs_rel_firmware,
> + .set_powergating_state = amdgpu_cgs_set_powergating_state,
> + .set_clockgating_state = amdgpu_cgs_set_clockgating_state,
> + .get_active_displays_info = amdgpu_cgs_get_active_displays_info,
> + .notify_dpm_enabled = amdgpu_cgs_notify_dpm_enabled,
> + .call_acpi_method = amdgpu_cgs_call_acpi_method,
> + .query_syste
[Bug 99143] r9 390: Hardware cursor invisible after hibernate/resume
https://bugs.freedesktop.org/show_bug.cgi?id=99143 Harald Judt changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #2 from Harald Judt --- Unfortunately, the commit does not fix the problem. I have also seen this issue when logging out, and the lightdm login appears, so it may not even be related to hibernation/resuming, but I haven't had enough time to look properly into this. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161220/bf8e0671/attachment.html>
[PATCH] drm/i915/debugfs: use rb_entry()
On Mon, Dec 19, 2016 at 10:43:49PM +0800, Geliang Tang wrote:
> To make the code clearer, use rb_entry() instead of container_of() to
> deal with rbtree.
>
> Signed-off-by: Geliang Tang
Not sure a direct alias for container_of is all that useful, but we have
list_entry too ...
Queued up for 4.11, thanks for the patch.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index b77b53b..e04d9a1 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -686,7 +686,7 @@ static void i915_ring_seqno_info(struct seq_file *m,
>
> spin_lock_irq(&b->lock);
> for (rb = rb_first(&b->waiters); rb; rb = rb_next(rb)) {
> - struct intel_wait *w = container_of(rb, typeof(*w), node);
> + struct intel_wait *w = rb_entry(rb, typeof(*w), node);
>
> seq_printf(m, "Waiting (%s): %s [%d] on %x\n",
> engine->name, w->tsk->comm, w->tsk->pid, w->seqno);
> @@ -1336,7 +1336,7 @@ static int i915_hangcheck_info(struct seq_file *m, void
> *unused)
>
> &dev_priv->gpu_error.missed_irq_rings)));
> spin_lock_irq(&b->lock);
> for (rb = rb_first(&b->waiters); rb; rb = rb_next(rb)) {
> - struct intel_wait *w = container_of(rb, typeof(*w),
> node);
> + struct intel_wait *w = rb_entry(rb, typeof(*w), node);
>
> seq_printf(m, "\t%s [%d] waiting for %x\n",
> w->tsk->comm, w->tsk->pid, w->seqno);
> @@ -3252,7 +3252,7 @@ static int i915_engine_info(struct seq_file *m, void
> *unused)
>
> spin_lock_irq(&b->lock);
> for (rb = rb_first(&b->waiters); rb; rb = rb_next(rb)) {
> - struct intel_wait *w = container_of(rb, typeof(*w),
> node);
> + struct intel_wait *w = rb_entry(rb, typeof(*w), node);
>
> seq_printf(m, "\t%s [%d] waiting for %x\n",
> w->tsk->comm, w->tsk->pid, w->seqno);
> --
> 2.9.3
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH v2 14/29] drm: bridge: dw-hdmi: Detect AHB audio DMA using correct register
Hi Laurent,
On 20-12-2016 01:33, Laurent Pinchart wrote:
> Bit 0 in CONFIG1_ID tells whether the IP core uses an AHB slave
> interface for control. The correct way to identify AHB audio DMA support
> is through bit 1 in CONFIG3_ID.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Jose Abreu
Best regards,
Jose Miguel Abreu
> ---
> drivers/gpu/drm/bridge/dw-hdmi.c | 6 +++---
> drivers/gpu/drm/bridge/dw-hdmi.h | 4
> 2 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c
> b/drivers/gpu/drm/bridge/dw-hdmi.c
> index 1809247745b8..730a7558d4d4 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
> @@ -1836,7 +1836,7 @@ __dw_hdmi_probe(struct platform_device *pdev,
> u8 prod_id0;
> u8 prod_id1;
> u8 config0;
> - u8 config1;
> + u8 config3;
>
> hdmi = devm_kzalloc(dev, sizeof(*hdmi), GFP_KERNEL);
> if (!hdmi)
> @@ -1988,9 +1988,9 @@ __dw_hdmi_probe(struct platform_device *pdev,
> pdevinfo.id = PLATFORM_DEVID_AUTO;
>
> config0 = hdmi_readb(hdmi, HDMI_CONFIG0_ID);
> - config1 = hdmi_readb(hdmi, HDMI_CONFIG1_ID);
> + config3 = hdmi_readb(hdmi, HDMI_CONFIG3_ID);
>
> - if (config1 & HDMI_CONFIG1_AHB) {
> + if (config3 & HDMI_CONFIG3_AHBAUDDMA) {
> struct dw_hdmi_audio_data audio;
>
> audio.phys = iores->start;
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.h
> b/drivers/gpu/drm/bridge/dw-hdmi.h
> index 91d7fabbd6e5..a4fd64a203c9 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi.h
> +++ b/drivers/gpu/drm/bridge/dw-hdmi.h
> @@ -559,6 +559,10 @@ enum {
> /* CONFIG1_ID field values */
> HDMI_CONFIG1_AHB = 0x01,
>
> +/* CONFIG3_ID field values */
> + HDMI_CONFIG3_AHBAUDDMA = 0x02,
> + HDMI_CONFIG3_GPAUD = 0x01,
> +
> /* IH_FC_INT2 field values */
> HDMI_IH_FC_INT2_OVERFLOW_MASK = 0x03,
> HDMI_IH_FC_INT2_LOW_PRIORITY_OVERFLOW = 0x02,
[PATCH v2 13/29] drm: bridge: dw-hdmi: Reject invalid product IDs
Hi Laurent,
On 20-12-2016 01:33, Laurent Pinchart wrote:
> The DWC HDMI TX can be recognized by the two product identification
> registers. If the registers don't read as expect the IP will be very
> different than what the driver has been designed for, or will be
> misconfigured in a way that makes it non-operational (invalid memory
> address, incorrect clocks, ...). We should reject this situation with an
> error.
>
> While this isn't critical for proper operation with supported IPs at the
> moment, the driver will soon gain automatic device-specific handling
> based on runtime device identification. This change makes it easier to
> implement that without having to default to a random guess in case the
> device can't be identified.
>
> While at it print a readable version number in the device identification
> message instead of raw register values.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Jose Abreu
> ---
> drivers/gpu/drm/bridge/dw-hdmi.c | 25 +++--
> drivers/gpu/drm/bridge/dw-hdmi.h | 8
> 2 files changed, 27 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c
> b/drivers/gpu/drm/bridge/dw-hdmi.c
> index 06c252f560ad..1809247745b8 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
> @@ -1832,6 +1832,9 @@ __dw_hdmi_probe(struct platform_device *pdev,
> int irq;
> int ret;
> u32 val = 1;
> + u16 version;
> + u8 prod_id0;
> + u8 prod_id1;
> u8 config0;
> u8 config1;
>
> @@ -1914,12 +1917,22 @@ __dw_hdmi_probe(struct platform_device *pdev,
> }
>
> /* Product and revision IDs */
> - dev_info(dev,
> - "Detected HDMI controller 0x%x:0x%x:0x%x:0x%x\n",
> - hdmi_readb(hdmi, HDMI_DESIGN_ID),
> - hdmi_readb(hdmi, HDMI_REVISION_ID),
> - hdmi_readb(hdmi, HDMI_PRODUCT_ID0),
> - hdmi_readb(hdmi, HDMI_PRODUCT_ID1));
> + version = (hdmi_readb(hdmi, HDMI_DESIGN_ID) << 8)
> + | (hdmi_readb(hdmi, HDMI_REVISION_ID) << 0);
> + prod_id0 = hdmi_readb(hdmi, HDMI_PRODUCT_ID0);
> + prod_id1 = hdmi_readb(hdmi, HDMI_PRODUCT_ID1);
> +
> + if (prod_id0 != HDMI_PRODUCT_ID0_HDMI_TX ||
> + (prod_id1 & ~HDMI_PRODUCT_ID1_HDCP) != HDMI_PRODUCT_ID1_HDMI_TX) {
> + dev_err(dev, "Unsupported HDMI controller (%04x:%02x:%02x)\n",
> + version, prod_id0, prod_id1);
> + ret = -ENODEV;
> + goto err_iahb;
> + }
> +
> + dev_info(dev, "Detected HDMI TX controller v%x.%03x %s HDCP\n",
> + version >> 12, version & 0xfff,
> + prod_id1 & HDMI_PRODUCT_ID1_HDCP ? "with" : "without");
>
> initialize_hdmi_ih_mutes(hdmi);
>
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.h
> b/drivers/gpu/drm/bridge/dw-hdmi.h
> index 08235aef2fa3..91d7fabbd6e5 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi.h
> +++ b/drivers/gpu/drm/bridge/dw-hdmi.h
> @@ -545,6 +545,14 @@
> #define HDMI_I2CM_FS_SCL_LCNT_0_ADDR0x7E12
>
> enum {
> +/* PRODUCT_ID0 field values */
> + HDMI_PRODUCT_ID0_HDMI_TX = 0xa0,
> +
> +/* PRODUCT_ID1 field values */
> + HDMI_PRODUCT_ID1_HDCP = 0xc0,
> + HDMI_PRODUCT_ID1_HDMI_RX = 0x02,
> + HDMI_PRODUCT_ID1_HDMI_TX = 0x01,
> +
> /* CONFIG0_ID field values */
> HDMI_CONFIG0_I2S = 0x10,
>
[PATCH v2 12/29] drm: bridge: dw-hdmi: Rename CONF0 SPARECTRL bit to SVSRET
Hi Laurent,
On 20-12-2016 01:33, Laurent Pinchart wrote:
> The bit is documented in a Rockchip BSP as
>
> #define m_SVSRET_SIG (1 << 5) /* depend on PHY_MHL_COMB0=1 */
>
> This is confirmed by a Renesas platform, which uses a 2.0 DWC HDMI TX as
> the RK3288. Rename the bit accordingly.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Jose Abreu
> ---
> drivers/gpu/drm/bridge/dw-hdmi.c | 8
> drivers/gpu/drm/bridge/dw-hdmi.h | 4 ++--
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c
> b/drivers/gpu/drm/bridge/dw-hdmi.c
> index b4fb0bd78910..06c252f560ad 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
> @@ -895,11 +895,11 @@ static void dw_hdmi_phy_enable_tmds(struct dw_hdmi
> *hdmi, u8 enable)
>HDMI_PHY_CONF0_ENTMDS_MASK);
> }
>
> -static void dw_hdmi_phy_enable_spare(struct dw_hdmi *hdmi, u8 enable)
> +static void dw_hdmi_phy_enable_svsret(struct dw_hdmi *hdmi, u8 enable)
> {
> hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
> - HDMI_PHY_CONF0_SPARECTRL_OFFSET,
> - HDMI_PHY_CONF0_SPARECTRL_MASK);
> + HDMI_PHY_CONF0_SVSRET_OFFSET,
> + HDMI_PHY_CONF0_SVSRET_MASK);
> }
>
> static void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
> @@ -1014,7 +1014,7 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, int
> cscon)
> dw_hdmi_phy_gen2_pddq(hdmi, 0);
>
> if (hdmi->dev_type == RK3288_HDMI)
> - dw_hdmi_phy_enable_spare(hdmi, 1);
> + dw_hdmi_phy_enable_svsret(hdmi, 1);
>
> /*Wait for PHY PLL lock */
> msec = 5;
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.h
> b/drivers/gpu/drm/bridge/dw-hdmi.h
> index 55135bbd0c16..08235aef2fa3 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi.h
> +++ b/drivers/gpu/drm/bridge/dw-hdmi.h
> @@ -847,8 +847,8 @@ enum {
> HDMI_PHY_CONF0_PDZ_OFFSET = 7,
> HDMI_PHY_CONF0_ENTMDS_MASK = 0x40,
> HDMI_PHY_CONF0_ENTMDS_OFFSET = 6,
> - HDMI_PHY_CONF0_SPARECTRL_MASK = 0x20,
> - HDMI_PHY_CONF0_SPARECTRL_OFFSET = 5,
> + HDMI_PHY_CONF0_SVSRET_MASK = 0x20,
> + HDMI_PHY_CONF0_SVSRET_OFFSET = 5,
> HDMI_PHY_CONF0_GEN2_PDDQ_MASK = 0x10,
> HDMI_PHY_CONF0_GEN2_PDDQ_OFFSET = 4,
> HDMI_PHY_CONF0_GEN2_TXPWRON_MASK = 0x8,
[Intel-gfx] [PATCH 0/2] drm: link status property and DP link training failure handling
On Mon, Dec 19, 2016 at 11:15:40PM +, Pandiyan, Dhinakaran wrote: > On Sun, 2016-12-18 at 14:43 +0100, Daniel Vetter wrote: > > On Sat, Dec 17, 2016 at 05:47:56AM +, Pandiyan, Dhinakaran wrote: > > > On Fri, 2016-12-16 at 16:47 +0200, Jani Nikula wrote: > > > > On Fri, 16 Dec 2016, Daniel Vetter wrote: > > > > > On Fri, Dec 16, 2016 at 12:29:05PM +0200, Jani Nikula wrote: > > > > >> The two remaining patches from [1], rebased. > > > > >> > > > > >> BR, > > > > >> Jani. > > > > >> > > > > >> > > > > >> [1] > > > > >> http://mid.mail-archive.com/1480984058-552-1-git-send-email-manasi.d.navare > > > > >> at intel.com > > > > > > > > > > Just for the record, I think the only thing missing here is the Xorg > > > > > review on the -modesetting patch. As soon as we have that I can vacuum > > > > > this up (probably best through drm-misc, but not sure). > > > > > > > > Yeah I rebased this (and provided a debug hack privately) so Martin can > > > > test the modesetting changes. > > > > > > > > BR, > > > > Jani. > > > > > > > > > > > > > > I tested the -modesetting patch, which Martin had provided to Manasi, > > > with a compliance testing device (DPR-120) that can simulate link > > > training failure. The link rate correctly lowered after the link_status > > > property was set to BAD by the kernel and the userspace responded with a > > > modeset. > > > > > > One thing that was not straight forward to figure out was I had to boot > > > with i915.nuclear_pageflip=1. Is it documented somewhere that the > > > property needs DRIVER_ATOMIC to be set, or is it implicit? > > > > It should work without DRIVER_ATOMIC. At least the property should be > > exposed ... If this does only work with DRIVER_ATOMIC set then we have a > > bug somewhere. Can you pls try to figure out why it doesn't work? > > > > The property is exposed even without DRIVER_ATOMIC set, but the value is > always GOOD (0). > We set connector->state->link_status to BAD when link training fails but > the getconnector() ioctl ends up reading obj->properties->values[i] if > DRIVER_ATOMIC is NOT set. But with DRIVER_ATOMIC set, getconnector() > calls into drm_atomic_connector_get_property() and retrieves the value > stored in connector->state->link_status. That sounds like a bug in the getconnector code. This needs the same treatment as other places, see e.g. commit d3a46183db97536a53df5de6b556bd61197842b2 Author: Daniel Vetter Date: Wed Jun 8 14:19:15 2016 +0200 drm: Replace fb_helper->atomic with mode_config->atomic_commit I think it'd be good to extract this check into a drm_drv_uses_atomic_modeset to better self-document the code, roll it out to all existing places that check for atomic_commit and then also roll it out to the getproperty functions (for connectors, planes and crtcs). > > > The other thing I had trouble with -modesetting was, there was no > > > modeset following a long pulse from the sink at the begging of the test. > > > I had to force a modeset by changing the resolution so that the link > > > training path is executed. However, the link training failure induced a > > > modeset without any intervention. > > > > Sounds roughly like how it's supposed to work. For real mode configuration > > changes the desktop environment is supposed to set the mode it wants, by > > listening to the xrandr hotplug event. That's not the same as the udev > > hotplug event. You can listen for the xrandr hotplug event using > > > > $ xev -event randr > > > > Got it, -modesetting does indeed send out the hotplug events upon > hotplug. Excellent, so at least that's all working well. -Daniel > > -DK > > > > Cheers, Daniel > > > > > > > > -DK > > > > > > > > > > > -Daniel > > > > > > > > > >> > > > > >> > > > > >> Manasi Navare (2): > > > > >> drm: Add a new connector atomic property for link status > > > > >> drm/i915: Implement Link Rate fallback on Link training failure > > > > >> > > > > >> drivers/gpu/drm/drm_atomic.c | 16 + > > > > >> drivers/gpu/drm/drm_atomic_helper.c | 15 > > > > >> drivers/gpu/drm/drm_connector.c | 52 > > > > >> +++ > > > > >> drivers/gpu/drm/i915/intel_dp.c | 27 ++ > > > > >> drivers/gpu/drm/i915/intel_dp_link_training.c | 22 ++-- > > > > >> drivers/gpu/drm/i915/intel_drv.h | 3 ++ > > > > >> include/drm/drm_connector.h | 19 ++ > > > > >> include/drm/drm_mode_config.h | 5 +++ > > > > >> include/uapi/drm/drm_mode.h | 4 +++ > > > > >> 9 files changed, 161 insertions(+), 2 deletions(-) > > > > >> > > > > >> -- > > > > >> 2.1.4 > > > > >> > > > > >> ___ > > > > >> dri-devel mailing list > > > > >> dri-devel at lists.freedesktop.org > > > > >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > > > > > > > -- Daniel Vetter Sof
[PATCH v2 6/6] drm/i915: Add a cursor hack to allow converting legacy page flip to atomic, v3.
On Mon, Dec 12, 2016 at 11:34:55AM +0100, Maarten Lankhorst wrote:
> Do something similar to vc4, only allow updating the cursor state
> in-place through a fastpath when the watermarks are unaffected. This
> will allow cursor movement to be smooth, but changing cursor size or
> showing/hiding cursor will still fall back so watermarks can be updated.
>
> Only moving and changing fb is allowed.
>
> Changes since v1:
> - Set page flip to always_unused for trybot.
> - Copy fence correctly, ignore plane_state->state, should be NULL.
> - Check crtc_state for !active and modeset, go to slowpath if the case.
> Changes since v2:
> - Make error handling work correctly. (Matthew Auld)
>
> Signed-off-by: Maarten Lankhorst
Pulled in the entire pile through drm-misc, thanks.
-Daniel
> ---
> drivers/gpu/drm/i915/intel_atomic_plane.c | 47 +++
> drivers/gpu/drm/i915/intel_display.c | 132
> +-
> drivers/gpu/drm/i915/intel_drv.h | 2 +
> 3 files changed, 163 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/intel_atomic_plane.c
> index dbe9fb41ae53..60d75ce8a989 100644
> --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
> @@ -103,36 +103,24 @@ intel_plane_destroy_state(struct drm_plane *plane,
> drm_atomic_helper_plane_destroy_state(plane, state);
> }
>
> -static int intel_plane_atomic_check(struct drm_plane *plane,
> - struct drm_plane_state *state)
> +int intel_plane_atomic_check_with_state(struct intel_crtc_state *crtc_state,
> + struct intel_plane_state *intel_state)
> {
> + struct drm_plane *plane = intel_state->base.plane;
> struct drm_i915_private *dev_priv = to_i915(plane->dev);
> - struct drm_crtc *crtc = state->crtc;
> - struct intel_crtc *intel_crtc;
> - struct intel_crtc_state *crtc_state;
> + struct drm_plane_state *state = &intel_state->base;
> struct intel_plane *intel_plane = to_intel_plane(plane);
> - struct intel_plane_state *intel_state = to_intel_plane_state(state);
> - struct drm_crtc_state *drm_crtc_state;
> int ret;
>
> - crtc = crtc ? crtc : plane->state->crtc;
> - intel_crtc = to_intel_crtc(crtc);
> -
> /*
>* Both crtc and plane->crtc could be NULL if we're updating a
>* property while the plane is disabled. We don't actually have
>* anything driver-specific we need to test in that case, so
>* just return success.
>*/
> - if (!crtc)
> + if (!intel_state->base.crtc && !plane->state->crtc)
> return 0;
>
> - drm_crtc_state = drm_atomic_get_existing_crtc_state(state->state, crtc);
> - if (WARN_ON(!drm_crtc_state))
> - return -EINVAL;
> -
> - crtc_state = to_intel_crtc_state(drm_crtc_state);
> -
> /* Clip all planes to CRTC size, or 0x0 if CRTC is disabled */
> intel_state->clip.x1 = 0;
> intel_state->clip.y1 = 0;
> @@ -184,6 +172,31 @@ static int intel_plane_atomic_check(struct drm_plane
> *plane,
> return intel_plane_atomic_calc_changes(&crtc_state->base, state);
> }
>
> +static int intel_plane_atomic_check(struct drm_plane *plane,
> + struct drm_plane_state *state)
> +{
> + struct drm_crtc *crtc = state->crtc;
> + struct drm_crtc_state *drm_crtc_state;
> +
> + crtc = crtc ? crtc : plane->state->crtc;
> +
> + /*
> + * Both crtc and plane->crtc could be NULL if we're updating a
> + * property while the plane is disabled. We don't actually have
> + * anything driver-specific we need to test in that case, so
> + * just return success.
> + */
> + if (!crtc)
> + return 0;
> +
> + drm_crtc_state = drm_atomic_get_existing_crtc_state(state->state, crtc);
> + if (WARN_ON(!drm_crtc_state))
> + return -EINVAL;
> +
> + return
> intel_plane_atomic_check_with_state(to_intel_crtc_state(drm_crtc_state),
> +to_intel_plane_state(state));
> +}
> +
> static void intel_plane_atomic_update(struct drm_plane *plane,
> struct drm_plane_state *old_state)
> {
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 9eaf1e5bdae9..5568ecac2edc 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15028,6 +15028,136 @@ const struct drm_plane_funcs intel_plane_funcs = {
> .atomic_destroy_state = intel_plane_destroy_state,
> };
>
> +static int
> +intel_legacy_cursor_update(struct drm_plane *plane,
> +struct drm_crtc *crtc,
> +struct drm_framebuffer *fb,
> +int crtc_x, int crtc_y,
> +unsigned int crtc_w, unsigned int
[RFC 0/4] Introduce drmfs pseudo filesystem for drm subsystem
On Tue, Dec 20, 2016 at 4:44 AM, Jani Nikula wrote: > On Tue, 20 Dec 2016, Laurent Pinchart > wrote: >> Hi Swati, >> >> On Monday 19 Dec 2016 16:12:22 swati.dhingra at intel.com wrote: >>> From: Swati Dhingra >>> >>> Currently, we don't have a stable ABI which can be used for the purpose of >>> providing output debug/loggging/crc and other such data from DRM. >>> The ABI in current use (filesystems, ioctls, et al.) have their own >>> constraints and are intended to output a particular type of data. >>> Few cases in point: >>> sysfs- stable ABI, but constrained to one textual value per file >>> debugfs - unstable ABI, free-for-all >>> ioctls - not as suitable to many single purpose continuous data >>>dumping, we would very quickly run out ioctl space; requires more >>>userspace support than "cat" >>> device nodes - a real possibilty, kernel instantiation is more tricky, >>> requires udev (+udev.rules) or userspace discovery of the >>> dynamic major:minor (via sysfs) [mounting a registered >>> filesystem is easy in comparison] >>> netlink - stream based, therefore involves numerous copies. >>> >>> Debugfs is the lesser among the evils here, thereby we have grown used to >>> the convenience and flexibility in presentation that debugfs gives us >>> (including relayfs inodes) that we want some of that hierachy in stable user >>> ABI form. >> >> Seriously, why ? A subsystem growing its own file system sounds so wrong. It >> seems that you want to have all the benefits of a stable ABI without going >> through the standardization effort that this requires. I can see so many ways >> that drmfs could be abused, with drivers throwing in new data with little or >> no review. You'll need very compelling arguments to convince me. > > This is not unlike my sentiments on the first version posted > [1]. There's also the distinct feeling of [2]. Suffice it to say at this > time that I'm dubious, not convinced enough to defend this. > > Swati, please refrain from posting new versions of the patches until > there's some consensus one way or the other; it's counter-productive to > keep splitting off the discussion into several patch series threads at > this stage. Let's have the discussion here. > I'll echo Laurent's concerns here, seems like the goal is easy to merge, hard to change. I think the problem with this is that easy to merge usually leads to designs which need to change :) Secondly, I'm not sure there's value outside of i915, perhaps I'm missing use cases for other drivers. Sean > > BR, > Jani. > > > [1] http://mid.mail-archive.com/87lgw0xcf4.fsf at intel.com > [2] https://xkcd.com/927/ > >> >>> Due to these limitations, there is a need for a new pseudo filesytem, that >>> would act as a stable 'free-for-all' ABI, with the heirarchial structure and >>> thus convenience of debugfs. This will be managed by drm, thus named >>> 'drmfs'. DRM would register this filesystem to manage a canonical >>> mountpoint, but this wouldn't limit everyone to only using that pseudofs >>> underneath. >>> >>> This can serve to hold various kinds of output data from Linux DRM >>> subsystems, for the files which can't truely fit anywhere else with >>> existing ABI's but present so, for the lack of a better place. >>> >>> In this patch series, we have introduced a pseudo filesystem named as >>> 'drmfs' for now. The filesystem is introduced in the first patch, and the >>> subsequent patches make use of the filesystem interfaces, in drm driver, >>> and making them available for use by the drm subsystem components, one of >>> which is i915. We've moved the location of i915 GuC logs from debugfs to >>> drmfs in the last patch. Subsequently, more such files such as pipe_crc, >>> error states, memory stats, etc. can be move to this filesystem, if the >>> idea introduced here is acceptable per se. The filesystem introduced is >>> being used to house the data generated by i915 driver in this patch series, >>> but will hopefully be generic enough to provide scope for usage by any >>> other drm subsystem component. >>> >>> The patch series is being floated as RFC to gather feedback on the idea and >>> infrastructure proposed here and it's suitability to address the specific >>> problem statement/use case. >>> >>> v2: fix the bat failures caused due to missing config check >>> >>> v3: Changes made: >>> - Move the location of drmfs from fs/ to drivers/gpu/drm/ (Chris) >>> - Moving config checks to header (Chris,Daniel) >>> >>> v4: Added the kernel Documentaion (using Sphinx). >>> >>> Sourab Gupta (4): >>> drm: Introduce drmfs pseudo filesystem interfaces >>> drm: Register drmfs filesystem from drm init >>> drm: Create driver specific root directory inside drmfs >>> drm/i915: Creating guc log file in drmfs instead of debugfs >>> >>> Documentation/gpu/drm-uapi.rst | 76 >>> drivers/gpu/drm/Kconfig| 9 + >>> dri
i915 regression in kernel 4.10
On Mon, Dec 19, 2016 at 03:16:44PM +0100, Juergen Gross wrote: > On 19/12/16 13:29, Chris Wilson wrote: > > On Mon, Dec 19, 2016 at 12:39:16PM +0100, Juergen Gross wrote: > >> With recent 4.10 kernel the graphics isn't coming up under Xen. First > >> failure message is: > >> > >> [ 46.656649] i915 :00:02.0: swiotlb buffer is full (sz: 1630208 > >> bytes) > > > > Do we get a silent failure? i915_gem_gtt_prepare_pages() is where we > > call dma_map_sg() and pass the sg to swiotlb (in this case) for > > remapping, and we do check for an error value of 0. After that error, > > SWIOTLB_MAP_ERROR is propagated back and converted to 0 for > > dma_map_sg(). That looks valid, and we should report ENOMEM back to the > > caller. > > > >> Later I see splats like: > >> > >> [ 49.393583] general protection fault: [#1] SMP > > > > What was the faulting address? RAX is particularly non-pointer-like so I > > wonder if we walked onto an uninitialised portion of the sgtable. We may > > have tripped over a bug in our sg_page iterator. > > During the bisect process there have been either GP or NULL pointer > dereferences or other page faults. Typical addresses where: > > xen_swiotlb_unmap_sg_attrs+0x1f/0x50: access to 0018 > xen_swiotlb_unmap_sg_attrs+0x1f/0x50: access to 03020118 > > > > > The attached patch should prevent an early ENOMEM following the swiotlb > > allocation failure. But I suspect that we will still be tripping up the > > failure in the sg walker when binding to the GPU. > > -Chris > > > > The patch is working not too bad. :-) > > Still several "swiotlb buffer is full" messages (some with sz:, most > without), but no faults any more (neither GP nor NULL pointer > dereference). Graphical login is working now. I think I know why. The optimization that was added assumes that bus addresses is the same as physical address. Hence it packs all of the virtual addresses in the sg, and hands it off to SWIOTLB which walks each one and realizes that it has to use the bounce buffer. I am wondering if would make sense to pull 'swiotlb_max_size' inside of SWIOTLB and make it an library-ish - so Xen-SWIOTLB can register as well and report say that it can only provide one page (unless it is running under baremtal). Or make the usage of 'max_segement' and 'page_to_pfn(page) != last_pfn + 1' in i915_gem_object_Get_pages_gtt use something similar to xen_biovec_phys_mergeable?
[Nouveau] [PATCH] drm/nouveau: fix unknown chipset for GTX 1060
we already have that included in 4.10
2016-12-12 12:26 GMT+01:00 Chris Chiu :
> Nouveau driver shows unknown chipset (136000a1) for GTX 1060, so it
> only gives VGA resolution on screen. Use the same chipset as nv134
> then it shows FullHD. This commit copies fields from nv134_chipset
> to nv136_chipset for GTX 1060.
>
> Signed-off-by: Chris Chiu
> ---
> drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 29
> +++
> 1 file changed, 29 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
> b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
> index 7218a06..7c6eece 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
> @@ -2209,6 +2209,34 @@ nv134_chipset = {
> .fifo = gp100_fifo_new,
> };
>
> +static const struct nvkm_device_chip
> +nv136_chipset = {
> + .name = "GP104",
> + .bar = gf100_bar_new,
> + .bios = nvkm_bios_new,
> + .bus = gf100_bus_new,
> + .devinit = gm200_devinit_new,
> + .fb = gp104_fb_new,
> + .fuse = gm107_fuse_new,
> + .gpio = gk104_gpio_new,
> + .i2c = gm200_i2c_new,
> + .ibus = gm200_ibus_new,
> + .imem = nv50_instmem_new,
> + .ltc = gp100_ltc_new,
> + .mc = gp100_mc_new,
> + .mmu = gf100_mmu_new,
> + .pci = gp100_pci_new,
> + .timer = gk20a_timer_new,
> + .top = gk104_top_new,
> + .ce[0] = gp104_ce_new,
> + .ce[1] = gp104_ce_new,
> + .ce[2] = gp104_ce_new,
> + .ce[3] = gp104_ce_new,
> + .disp = gp104_disp_new,
> + .dma = gf119_dma_new,
> + .fifo = gp100_fifo_new,
> +};
> +
> static int
> nvkm_device_event_ctor(struct nvkm_object *object, void *data, u32 size,
>struct nvkm_notify *notify)
> @@ -2644,6 +2672,7 @@ nvkm_device_ctor(const struct nvkm_device_func *func,
> case 0x12b: device->chip = &nv12b_chipset; break;
> case 0x130: device->chip = &nv130_chipset; break;
> case 0x134: device->chip = &nv134_chipset; break;
> + case 0x136: device->chip = &nv136_chipset; break;
> default:
> nvdev_error(device, "unknown chipset (%08x)\n",
> boot0);
> goto done;
> --
> 2.1.4
>
> ___
> Nouveau mailing list
> Nouveau at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
[PATCH 3/3] drm/msm: Verify that MSM_SUBMIT_BO_FLAGS are set
For every submission buffer object one of MSM_SUBMIT_BO_WRITE
and MSM_SUBMIT_BO_READ must be set (and nothing else). If we
allowed zero then the buffer object would never get queued to
be unreferenced.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_gem_submit.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
b/drivers/gpu/drm/msm/msm_gem_submit.c
index 2697b32..2982702 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -106,7 +106,8 @@ static int submit_lookup_objects(struct msm_gem_submit
*submit,
pagefault_disable();
}
- if (submit_bo.flags & ~MSM_SUBMIT_BO_FLAGS) {
+ if ((submit_bo.flags & ~MSM_SUBMIT_BO_FLAGS) ||
+ !(submit_bo.flags & MSM_SUBMIT_BO_FLAGS)) {
DRM_ERROR("invalid flags: %x\n", submit_bo.flags);
ret = -EINVAL;
goto out_unlock;
--
1.9.1
[PATCH 2/3] drm/msm: Put back the vaddr in submit_reloc()
The error cases in submit_reloc() need to put back the virtual
address of the bo before failling. Add a single failure path
for the function.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_gem_submit.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
b/drivers/gpu/drm/msm/msm_gem_submit.c
index 25e8786..2697b32 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -290,7 +290,7 @@ static int submit_reloc(struct msm_gem_submit *submit,
struct msm_gem_object *ob
{
uint32_t i, last_offset = 0;
uint32_t *ptr;
- int ret;
+ int ret = 0;
if (offset % 4) {
DRM_ERROR("non-aligned cmdstream buffer: %u\n", offset);
@@ -317,12 +317,13 @@ static int submit_reloc(struct msm_gem_submit *submit,
struct msm_gem_object *ob
ret = copy_from_user(&submit_reloc, userptr,
sizeof(submit_reloc));
if (ret)
- return -EFAULT;
+ goto out;
if (submit_reloc.submit_offset % 4) {
DRM_ERROR("non-aligned reloc offset: %u\n",
submit_reloc.submit_offset);
- return -EINVAL;
+ ret = -EINVAL;
+ goto out;
}
/* offset in dwords: */
@@ -331,12 +332,13 @@ static int submit_reloc(struct msm_gem_submit *submit,
struct msm_gem_object *ob
if ((off >= (obj->base.size / 4)) ||
(off < last_offset)) {
DRM_ERROR("invalid offset %u at reloc %u\n", off, i);
- return -EINVAL;
+ ret = -EINVAL;
+ goto out;
}
ret = submit_bo(submit, submit_reloc.reloc_idx, NULL, &iova,
&valid);
if (ret)
- return ret;
+ goto out;
if (valid)
continue;
@@ -353,9 +355,10 @@ static int submit_reloc(struct msm_gem_submit *submit,
struct msm_gem_object *ob
last_offset = off;
}
+out:
msm_gem_put_vaddr_locked(&obj->base);
- return 0;
+ return ret;
}
static void submit_cleanup(struct msm_gem_submit *submit)
--
1.9.1
[PATCH 1/3] drm/msm: Ensure that the hardware write pointer is valid
Currently the value written to CP_RB_WPTR is calculated on the fly as
(rb->next - rb->start). But as the code is designed rb->next is wrapped
before writing the commands so if a series of commands happened to
fit perfectly in the ringbuffer, rb->next would end up being equal to
rb->size / 4 and thus result in an out of bounds address to CP_RB_WPTR.
The easiest way to fix this is to mask WPTR when writing it to the
hardware; it makes the hardware happy and the rest of the ringbuffer
math appears to work and there isn't any point in upsetting anything.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index f386f46..b45481a 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -210,7 +210,14 @@ void adreno_submit(struct msm_gpu *gpu, struct
msm_gem_submit *submit,
void adreno_flush(struct msm_gpu *gpu)
{
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
- uint32_t wptr = get_wptr(gpu->rb);
+ uint32_t wptr;
+
+ /*
+* Mask wptr value that we calculate to fit in the HW range. This is
+* to account for the possibility that the last command fit exactly into
+* the ringbuffer and rb->next hasn't wrapped to zero yet
+*/
+ wptr = get_wptr(gpu->rb) & ((rb->size / 4) - 1);
/* ensure writes to ringbuffer have hit system memory: */
mb();
--
1.9.1
[PATCH 0/3] drm/msm: 4.10 fixes
Here is a short trio of drm/msm fixes suitable for 4.10. The first fixes a hang that occurs when the ring is completely filled, the other two can be triggered through the API and cause mild distress. Jordan Crouse (3): drm/msm: Ensure that the hardware write pointer is valid drm/msm: Put back the vaddr in submit_reloc() drm/msm: Verify that MSM_SUBMIT_BO_FLAGS are set drivers/gpu/drm/msm/adreno/adreno_gpu.c | 9 - drivers/gpu/drm/msm/msm_gem_submit.c| 18 +++--- 2 files changed, 19 insertions(+), 8 deletions(-) -- 1.9.1
[PATCH v3 0/4] Generic HDMI codec: Add channel mapping control
Hi, On Dec 19 2016 20:08, Arnaud Pouliquen wrote: > Aim of this patch is to add 'Playback Channel Map' control to export > audio capabilities in term of HDMI sink speakers allocation. > > V3: > - "ASoC: hdmi-codec: add channel mapping control": > => Minor fixes: > - select stereo speaker config by default if HDMI cable unplugged > - fix compilation warning. > - "DRM: add help to get ELD speaker allocation" > => No delta vs V2. > - "ALSA pcm: allow non constant snd_pcm_chmap_elem" > => No delta vs V2. > - "ASoC: core: add optional pcm_new callback for DAI driver" > => No delta vs V2. > > V2: > In this version I use chmap helper functions from pcm_lib.c. > It is quite tricky to use it from ASoC due to the relation chip of the > controls > with the pcm runtime. > After several tries, my conclusion is that it must be handled in ASoC DAI > driver. > Main reason is that the DAI driver can not provide snd_pcm_chmap struct > through kcontrol structure. But this induces that soc-core provides pcm > runtime > structure to DAI driver during probe. > > Base on this conclusion. I reworked my patches by adding 2 > new patches in patch-set > 1) ALSA pcm: allow non constant snd_pcm_chmap_elem >This patch allows to handle non constant channel mapping. As ELD >information can change during runtime it is mandatory to properly >handle the feature. >In term of compatibility with legacy it should be straightforward, >as update just consists in suppressing the 'const' constraint. > > 2) ASoC: core: add optional pcm_new callback for DAI driver > This is the only way i found to be able to use > snd_pcm_add_chmap_ctls and associated controls helper functions. > From my point of view, this is the more simple way to add relationship > between DAI and associated pcm devices. >Notice that this patch, if accepted, makes the following one obsolete, >as it also answer to the associated topic: > [PATCH v5 0/2] ALSA controls management using index/device/sub-devices > fields > (http://www.spinics.net/lists/alsa-devel/msg57639.html). > > If you estimate that this it not reasonable i will come back to my first > version. > > V1: > This patch follows discussion initiate here: > [RFC] ASOC: HDMI audio info frame speaker allocation > http://www.spinics.net/lists/alsa-devel/msg57363.html > > The code is fully inspired from HDA driver. > On hw_param, HDMI sink speaker capabilities are exported via TLV ops > and a CEA allocation is choson, based on ELD information and the number of > channels requested by user. > > Mains differences with HDA implementation are: > - Control is read only > - Channel swap is not supported. Consequence is that unused channel in >the mid of CEA audio infoframe channel mapping are considered as >active. >example for channel allocation 0x02: FL, FR, 0, FC) > This configuration is only available for a 4 channels stream. > - Channel allocation table has been reordered and HDMI 2.0 is not > supported. > > Arnaud Pouliquen (4): > DRM: add help to get ELD speaker allocation > ALSA pcm: allow non constant snd_pcm_chmap_elem > ASoC: core: add optional pcm_new callback for DAI driver > ASoC: hdmi-codec: add channel mapping control > > include/drm/drm_edid.h| 13 ++ > include/sound/pcm.h | 4 +- > include/sound/soc-dai.h | 3 + > sound/core/pcm_lib.c | 6 +- > sound/soc/codecs/hdmi-codec.c | 313 > +- > sound/soc/soc-core.c | 28 > 6 files changed, 361 insertions(+), 6 deletions(-) I'm sorry but please drop me from CC list. I'd like not to be involved into this kind of new integration within merge window of next Linux kernel, as I said to you. Regards Takashi Sakamoto
[PATCH v2 29/29] arm64: dts: r8a7795: salvator-x: Add DU1 and DU2 external dot clocks
The DU1 and DU2 external dot clocks are fixed frequency clock generators
running at 33MHz.
Signed-off-by: Laurent Pinchart
---
arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 23 ++
1 file changed, 23 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
index 08554b4d7e86..b6dc6f5188d6 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
@@ -147,6 +147,19 @@
};
};
+ /* External DU dot clocks */
+ x21_clk: x21-clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <3300>;
+ };
+
+ x22_clk: x22-clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <3300>;
+ };
+
hdmi0-out {
compatible = "hdmi-connector";
label = "HDMI0 OUT";
@@ -245,6 +258,16 @@
pinctrl-names = "default";
status = "okay";
+ clocks = <&cpg CPG_MOD 724>,
+<&cpg CPG_MOD 723>,
+<&cpg CPG_MOD 722>,
+<&cpg CPG_MOD 721>,
+<&cpg CPG_MOD 727>,
+<&x21_clk>,
+<&x22_clk>;
+ clock-names = "du.0", "du.1", "du.2", "du.3", "lvds.0",
+ "dclkin.1", "dclkin.2";
+
ports {
port at 0 {
endpoint {
--
Regards,
Laurent Pinchart
[PATCH v2 28/29] arm64: dts: r8a7795: salvator-x: Enable HDMI outputs
From: Koji Matsuoka
Instantiate the HDMI connectors and enable the encoders.
Signed-off-by: Koji Matsuoka
Signed-off-by: Ulrich Hecht
Signed-off-by: Laurent Pinchart
---
arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 50 ++
1 file changed, 50 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
index 73a22b93f7b1..08554b4d7e86 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
@@ -147,6 +147,30 @@
};
};
+ hdmi0-out {
+ compatible = "hdmi-connector";
+ label = "HDMI0 OUT";
+ type = "a";
+
+ port {
+ hdmi0_con: endpoint {
+ remote-endpoint = <&rcar_dw_hdmi0_out>;
+ };
+ };
+ };
+
+ hdmi1-out {
+ compatible = "hdmi-connector";
+ label = "HDMI1 OUT";
+ type = "a";
+
+ port {
+ hdmi1_con: endpoint {
+ remote-endpoint = <&rcar_dw_hdmi1_out>;
+ };
+ };
+ };
+
vga-encoder {
compatible = "adi,adv7123";
@@ -190,6 +214,32 @@
};
};
+&hdmi0 {
+ status = "okay";
+
+ ports {
+ port at 1 {
+ reg = <1>;
+ rcar_dw_hdmi0_out: endpoint {
+ remote-endpoint = <&hdmi0_con>;
+ };
+ };
+ };
+};
+
+&hdmi1 {
+ status = "okay";
+
+ ports {
+ port at 1 {
+ reg = <1>;
+ rcar_dw_hdmi1_out: endpoint {
+ remote-endpoint = <&hdmi1_con>;
+ };
+ };
+ };
+};
+
&du {
pinctrl-0 = <&du_pins>;
pinctrl-names = "default";
--
Regards,
Laurent Pinchart
[PATCH v2 27/29] arm64: dts: r8a7795: Add HDMI encoder support
From: Ulrich Hecht
Add DT nodes for the two HDMI encoders in disabled state.
Based on work by Koji Matsuoka.
Signed-off-by: Ulrich Hecht
Signed-off-by: Laurent Pinchart
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 50
1 file changed, 50 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 9b717dee1f7b..5e8f231cf5a0 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -1590,11 +1590,13 @@
port at 1 {
reg = <1>;
du_out_hdmi0: endpoint {
+ remote-endpoint =
<&dw_hdmi0_in>;
};
};
port at 2 {
reg = <2>;
du_out_hdmi1: endpoint {
+ remote-endpoint =
<&dw_hdmi1_in>;
};
};
port at 3 {
@@ -1604,5 +1606,53 @@
};
};
};
+
+ hdmi0: hdmi0 at fead {
+ compatible = "renesas,r8a7795-hdmi",
"renesas,rcar-gen3-hdmi";
+ reg = <0 0xfead 0 0x1>;
+ interrupts = <0 389 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 729>, <&cpg CPG_CORE
R8A7795_CLK_HDMI>;
+ clock-names = "iahb", "isfr";
+ power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port at 0 {
+ reg = <0>;
+ dw_hdmi0_in: endpoint {
+ remote-endpoint =
<&du_out_hdmi0>;
+ };
+ };
+ port at 1 {
+ reg = <1>;
+ };
+ };
+ };
+
+ hdmi1: hdmi1 at feae {
+ compatible = "renesas,r8a7795-hdmi",
"renesas,rcar-gen3-hdmi";
+ reg = <0 0xfeae 0 0x1>;
+ interrupts = <0 436 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 728>, <&cpg CPG_CORE
R8A7795_CLK_HDMI>;
+ clock-names = "iahb", "isfr";
+ power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port at 0 {
+ reg = <0>;
+ dw_hdmi1_in: endpoint {
+ remote-endpoint =
<&du_out_hdmi1>;
+ };
+ };
+ port at 1 {
+ reg = <1>;
+ };
+ };
+ };
};
};
--
Regards,
Laurent Pinchart
[PATCH v2 26/29] drm: rcar-du: Add HDMI outputs to R8A7795 device description
From: Koji Matsuoka
Update the device description with the two available HDMI outputs.
Signed-off-by: Koji Matsuoka
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 4 +++-
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 12 ++--
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
index 6f08b7e7db06..459e5390d6e0 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
@@ -1,7 +1,7 @@
/*
* rcar_du_crtc.h -- R-Car Display Unit CRTCs
*
- * Copyright (C) 2013-2014 Renesas Electronics Corporation
+ * Copyright (C) 2013-2015 Renesas Electronics Corporation
*
* Contact: Laurent Pinchart (laurent.pinchart at ideasonboard.com)
*
@@ -61,6 +61,8 @@ enum rcar_du_output {
RCAR_DU_OUTPUT_DPAD1,
RCAR_DU_OUTPUT_LVDS0,
RCAR_DU_OUTPUT_LVDS1,
+ RCAR_DU_OUTPUT_HDMI0,
+ RCAR_DU_OUTPUT_HDMI1,
RCAR_DU_OUTPUT_TCON,
RCAR_DU_OUTPUT_MAX,
};
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 74352140f55f..3107719c4653 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -150,13 +150,21 @@ static const struct rcar_du_device_info
rcar_du_r8a7795_info = {
| RCAR_DU_FEATURE_VSP1_SOURCE,
.num_crtcs = 4,
.routes = {
- /* R8A7795 has one RGB output, one LVDS output and two
-* (currently unsupported) HDMI outputs.
+ /* R8A7795 has one RGB output, two HDMI outputs and one
+* LVDS output.
*/
[RCAR_DU_OUTPUT_DPAD0] = {
.possible_crtcs = BIT(3),
.port = 0,
},
+ [RCAR_DU_OUTPUT_HDMI0] = {
+ .possible_crtcs = BIT(1),
+ .port = 1,
+ },
+ [RCAR_DU_OUTPUT_HDMI1] = {
+ .possible_crtcs = BIT(2),
+ .port = 2,
+ },
[RCAR_DU_OUTPUT_LVDS0] = {
.possible_crtcs = BIT(0),
.port = 3,
--
Regards,
Laurent Pinchart
[PATCH v2 25/29] drm: rcar-du: Add DPLL support
From: Koji Matsuoka
The implementation hardcodes a workaround for the H3 ES1.x SoC
regardless of the SoC revision, as the workaround can be safely applied
on all devices in the Gen3 family without any side effect.
Signed-off-by: Koji Matsuoka
Signed-off-by: Ulrich Hecht
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 81 +-
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 1 +
drivers/gpu/drm/rcar-du/rcar_du_drv.h | 1 +
drivers/gpu/drm/rcar-du/rcar_du_regs.h | 23 ++
4 files changed, 105 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index a2ec6d8796a0..cec20abd61aa 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -106,9 +106,62 @@ static void rcar_du_crtc_put(struct rcar_du_crtc *rcrtc)
* Hardware Setup
*/
+struct dpll_info {
+ unsigned int output;
+ unsigned int fdpll;
+ unsigned int n;
+ unsigned int m;
+};
+
+static void rcar_du_dpll_divider(struct rcar_du_crtc *rcrtc,
+struct dpll_info *dpll,
+unsigned long input,
+unsigned long target)
+{
+ unsigned long best_diff = (unsigned long)-1;
+ unsigned long diff;
+ unsigned int fdpll;
+ unsigned int m;
+ unsigned int n;
+
+ for (n = 39; n < 120; n++) {
+ for (m = 0; m < 4; m++) {
+ for (fdpll = 1; fdpll < 32; fdpll++) {
+ unsigned long output;
+
+ /* 1/2 (FRQSEL=1) for duty rate 50% */
+ output = input * (n + 1) / (m + 1)
+ / (fdpll + 1) / 2;
+
+ if (output >= 4)
+ continue;
+
+ diff = abs((long)output - (long)target);
+ if (best_diff > diff) {
+ best_diff = diff;
+ dpll->n = n;
+ dpll->m = m;
+ dpll->fdpll = fdpll;
+ dpll->output = output;
+ }
+
+ if (diff == 0)
+ goto done;
+ }
+ }
+ }
+
+done:
+ dev_dbg(rcrtc->group->dev->dev,
+ "output:%u, fdpll:%u, n:%u, m:%u, diff:%lu\n",
+dpll->output, dpll->fdpll, dpll->n, dpll->m,
+best_diff);
+}
+
static void rcar_du_crtc_set_display_timing(struct rcar_du_crtc *rcrtc)
{
const struct drm_display_mode *mode = &rcrtc->crtc.state->adjusted_mode;
+ struct rcar_du_device *rcdu = rcrtc->group->dev;
unsigned long mode_clock = mode->clock * 1000;
unsigned long clk;
u32 value;
@@ -124,12 +177,18 @@ static void rcar_du_crtc_set_display_timing(struct
rcar_du_crtc *rcrtc)
escr = div | ESCR_DCLKSEL_CLKS;
if (rcrtc->extclock) {
+ struct dpll_info dpll = { 0 };
unsigned long extclk;
unsigned long extrate;
unsigned long rate;
u32 extdiv;
extclk = clk_get_rate(rcrtc->extclock);
+ if (rcdu->info->dpll_ch & (1 << rcrtc->index)) {
+ rcar_du_dpll_divider(rcrtc, &dpll, extclk, mode_clock);
+ extclk = dpll.output;
+ }
+
extdiv = DIV_ROUND_CLOSEST(extclk, mode_clock);
extdiv = clamp(extdiv, 1U, 64U) - 1;
@@ -140,7 +199,27 @@ static void rcar_du_crtc_set_display_timing(struct
rcar_du_crtc *rcrtc)
abs((long)rate - (long)mode_clock)) {
dev_dbg(rcrtc->group->dev->dev,
"crtc%u: using external clock\n", rcrtc->index);
- escr = extdiv | ESCR_DCLKSEL_DCLKIN;
+
+ if (rcdu->info->dpll_ch & (1 << rcrtc->index)) {
+ u32 dpllcr = DPLLCR_CODE | DPLLCR_CLKE
+ | DPLLCR_FDPLL(dpll.fdpll)
+ | DPLLCR_N(dpll.n) | DPLLCR_M(dpll.m)
+ | DPLLCR_STBY;
+
+ if (rcrtc->index == 1)
+ dpllcr |= DPLLCR_PLCS1
+ | DPLLCR_INCS_DOTCLKIN1;
+ else
+ dpllcr |= DPLLCR_PLCS0
+ | DPLLCR_INCS_DOTCLKIN0;
+
+ rcar_du_group_write(rcrtc->group, DPLLCR,
+
[PATCH v2 24/29] drm: rcar-du: Skip disabled outputs
When a DT node connected to a DU output is disabled no bridge will ever
be instantiated for it. Skip the output in that case.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index aa84689043ae..7a6bd8bdba05 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -384,6 +384,13 @@ static int rcar_du_encoders_init_one(struct rcar_du_device
*rcdu,
return -ENODEV;
}
+ if (!of_device_is_available(entity)) {
+ dev_dbg(rcdu->dev,
+ "connected entity %s is disabled, skipping\n",
+ entity->full_name);
+ return -ENODEV;
+ }
+
entity_ep_node = of_parse_phandle(ep->local_node, "remote-endpoint", 0);
for_each_endpoint_of_node(entity, ep_node) {
--
Regards,
Laurent Pinchart
[PATCH v2 23/29] drm: rcar-du: Add Gen3 HDMI encoder support
From: Koji Matsuoka
The R-Car Gen3 SoCs include on-chip DesignWare HDMI encoders. Support
them with a platform driver to provide platform glue data to the dw-hdmi
driver.
The driver is a complete rewrite of code coming from the Renesas BSP,
save for the values in the PHY parameters table.
Signed-off-by: Koji Matsuoka
Signed-off-by: Ulrich Hecht
Signed-off-by: Laurent Pinchart
Signed-off-by: Kieran Bingham
---
drivers/gpu/drm/rcar-du/Kconfig| 8 +++
drivers/gpu/drm/rcar-du/Makefile | 1 +
drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 100 +
3 files changed, 109 insertions(+)
create mode 100644 drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 06121eeba9e5..a356d2f2f6d6 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -11,6 +11,14 @@ config DRM_RCAR_DU
Choose this option if you have an R-Car chipset.
If M is selected the module will be called rcar-du-drm.
+config DRM_RCAR_DW_HDMI
+ bool "R-Car DU Gen3 HDMI Encoder Support"
+ depends on DRM_RCAR_DU
+ depends on OF
+ select DRM_DW_HDMI
+ help
+ Enable support for R-Car Gen3 internal HDMI encoder.
+
config DRM_RCAR_LVDS
bool "R-Car DU LVDS Encoder Support"
depends on DRM_RCAR_DU
diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile
index a492e6858691..2131e722de3b 100644
--- a/drivers/gpu/drm/rcar-du/Makefile
+++ b/drivers/gpu/drm/rcar-du/Makefile
@@ -11,3 +11,4 @@ rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS) += rcar_du_lvdsenc.o
rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
obj-$(CONFIG_DRM_RCAR_DU) += rcar-du-drm.o
+obj-$(CONFIG_DRM_RCAR_DW_HDMI) += rcar_dw_hdmi.o
diff --git a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
new file mode 100644
index ..7539626b8ebd
--- /dev/null
+++ b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
@@ -0,0 +1,100 @@
+/*
+ * R-Car Gen3 HDMI PHY
+ *
+ * Copyright (C) 2016 Renesas Electronics Corporation
+ *
+ * Contact: Laurent Pinchart (laurent.pinchart at ideasonboard.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+
+#include
+
+#define RCAR_HDMI_PHY_OPMODE_PLLCFG0x06/* Mode of operation and PLL
dividers */
+#define RCAR_HDMI_PHY_PLLCURRGMPCTRL 0x10/* PLL current and Gmp
(conductance) */
+#define RCAR_HDMI_PHY_PLLDIVCTRL 0x11/* PLL dividers */
+
+struct rcar_hdmi_phy_params {
+ unsigned long mpixelclock;
+ u16 opmode_div; /* Mode of operation and PLL dividers */
+ u16 curr_gmp; /* PLL current and Gmp (conductance) */
+ u16 div;/* PLL dividers */
+};
+
+static const struct rcar_hdmi_phy_params rcar_hdmi_phy_params[] = {
+ { 3550, 0x0003, 0x0344, 0x0328 },
+ { 4490, 0x0003, 0x0285, 0x0128 },
+ { 7100, 0x0002, 0x1184, 0x0314 },
+ { 9000, 0x0002, 0x1144, 0x0114 },
+ { 14025, 0x0001, 0x20c4, 0x030a },
+ { 18275, 0x0001, 0x2084, 0x010a },
+ { 28125, 0x, 0x0084, 0x0305 },
+ { 29700, 0x, 0x0084, 0x0105 },
+ { ~0UL, 0x, 0x, 0x },
+};
+
+static int rcar_hdmi_phy_configure(struct dw_hdmi *hdmi,
+ const struct dw_hdmi_plat_data *pdata,
+ unsigned long mpixelclock)
+{
+ const struct rcar_hdmi_phy_params *params = rcar_hdmi_phy_params;
+
+ for (; params && params->mpixelclock != ~0UL; ++params) {
+ if (mpixelclock <= params->mpixelclock)
+ break;
+ }
+
+ if (params->mpixelclock == ~0UL)
+ return -EINVAL;
+
+ dw_hdmi_phy_i2c_write(hdmi, params->opmode_div,
+ RCAR_HDMI_PHY_OPMODE_PLLCFG);
+ dw_hdmi_phy_i2c_write(hdmi, params->curr_gmp,
+ RCAR_HDMI_PHY_PLLCURRGMPCTRL);
+ dw_hdmi_phy_i2c_write(hdmi, params->div, RCAR_HDMI_PHY_PLLDIVCTRL);
+
+ return 0;
+}
+
+static const struct dw_hdmi_plat_data rcar_dw_hdmi_plat_data = {
+ .configure_phy = rcar_hdmi_phy_configure,
+};
+
+static int rcar_dw_hdmi_probe(struct platform_device *pdev)
+{
+ return dw_hdmi_probe(pdev, &rcar_dw_hdmi_plat_data);
+}
+
+static int rcar_dw_hdmi_remove(struct platform_device *pdev)
+{
+ dw_hdmi_remove(pdev);
+
+ return 0;
+}
+
+static const struct of_device_id rcar_dw_hdmi_of_table[] = {
+ { .compatible = "renesas,rcar-gen3-hdmi" },
+ { /* Sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, rcar_dw_hdmi_of_table);
+
+static struct platform_driver rcar_dw_hdmi_platform_driver = {
+
[PATCH v2 22/29] dt-bindings: display: renesas: Add R-Car Gen3 HDMI TX DT bindings
The Renesas R-Car Gen3 SoCs use a Synopsys DWC HDMI TX encoder IP. Add
corresponding device tree bindings based on the DWC HDMI TX bindings
model.
Signed-off-by: Laurent Pinchart
Acked-by: Rob Herring
---
.../bindings/display/bridge/renesas,dw-hdmi.txt| 75 ++
MAINTAINERS| 1 +
2 files changed, 76 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
diff --git
a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
new file mode 100644
index ..f6b3f36d422b
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
@@ -0,0 +1,75 @@
+Renesas Gen3 DWC HDMI TX Encoder
+
+
+The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP
+with a companion PHY IP.
+
+These DT bindings follow the Synopsys DWC HDMI TX bindings defined in
+Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt with the
+following device-specific properties.
+
+
+Required properties:
+
+- compatible : Shall contain one or more of
+ - "renesas,r8a7795-hdmi" for R8A7795 (R-Car H3) compatible HDMI TX
+ - "renesas,rcar-gen3-hdmi" for the generic R-Car Gen3 compatible HDMI TX
+
+When compatible with generic versions, nodes must list the SoC-specific
+version corresponding to the platform first, followed by the
+family-specific version.
+
+- reg: See dw_hdmi.txt.
+- interrupts: HDMI interrupt number
+- clocks: See dw_hdmi.txt.
+- clock-names: Shall contain "iahb" and "isfr" as defined in dw_hdmi.txt.
+- ports: See dw_hdmi.txt. The DWC HDMI shall have one port numbered 0
+ corresponding to the video input of the controller and one port numbered 1
+ corresponding to its HDMI output. Each port shall have a single endpoint.
+
+Optional properties:
+
+- power-domains: Shall reference the power domain that contains the DWC HDMI,
+ if any.
+
+
+Example:
+
+ hdmi0: hdmi0 at fead {
+ compatible = "renesas,r8a7795-dw-hdmi";
+ reg = <0 0xfead 0 0x1>;
+ interrupts = <0 389 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_CORE R8A7795_CLK_S0D4>, <&cpg CPG_MOD 729>;
+ clock-names = "iahb", "isfr";
+ power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port at 0 {
+ reg = <0>;
+ dw_hdmi0_in: endpoint {
+ remote-endpoint = <&du_out_hdmi0>;
+ };
+ };
+ port at 1 {
+ reg = <1>;
+ rcar_dw_hdmi0_out: endpoint {
+ remote-endpoint = <&hdmi0_con>;
+ };
+ };
+ };
+ };
+
+ hdmi0-out {
+ compatible = "hdmi-connector";
+ label = "HDMI0 OUT";
+ type = "a";
+
+ port {
+ hdmi0_con: endpoint {
+ remote-endpoint = <&rcar_dw_hdmi0_out>;
+ };
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 1a7a773114aa..162d904d5cc3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4247,6 +4247,7 @@ S:Supported
F: drivers/gpu/drm/rcar-du/
F: drivers/gpu/drm/shmobile/
F: include/linux/platform_data/shmob_drm.h
+F: Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
F: Documentation/devicetree/bindings/display/renesas,du.txt
DRM DRIVER FOR QXL VIRTUAL GPU
--
Regards,
Laurent Pinchart
[PATCH v2 21/29] dt-bindings: display: dw-hdmi: Clean up DT bindings documentation
Make it clear that the core bridge/dw_hdmi.txt document isn't a device
tree binding by itself but is meant to be referenced by platform device
tree bindings, and update the Rockchip and Freescale DWC HDMI TX
bindings to reference it.
Signed-off-by: Laurent Pinchart
Acked-by: Rob Herring
---
.../devicetree/bindings/display/bridge/dw_hdmi.txt | 85 +-
.../devicetree/bindings/display/imx/hdmi.txt | 51 +++--
.../bindings/display/rockchip/dw_hdmi-rockchip.txt | 43 +++
3 files changed, 91 insertions(+), 88 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt
b/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt
index 5e9a84d6e5f1..33bf981fbe33 100644
--- a/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt
+++ b/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt
@@ -1,52 +1,33 @@
-DesignWare HDMI bridge bindings
-
-Required properties:
-- compatible: platform specific such as:
- * "snps,dw-hdmi-tx"
- * "fsl,imx6q-hdmi"
- * "fsl,imx6dl-hdmi"
- * "rockchip,rk3288-dw-hdmi"
-- reg: Physical base address and length of the controller's registers.
-- interrupts: The HDMI interrupt number
-- clocks, clock-names : must have the phandles to the HDMI iahb and isfr
clocks,
- as described in Documentation/devicetree/bindings/clock/clock-bindings.txt,
- the clocks are soc specific, the clock-names should be "iahb", "isfr"
--port@[X]: SoC specific port nodes with endpoint definitions as defined
- in Documentation/devicetree/bindings/media/video-interfaces.txt,
- please refer to the SoC specific binding document:
-* Documentation/devicetree/bindings/display/imx/hdmi.txt
-* Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
-
-Optional properties
-- reg-io-width: the width of the reg:1,4, default set to 1 if not present
-- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing,
- if the property is omitted, a functionally reduced I2C bus
- controller on DW HDMI is probed
-- clocks, clock-names: phandle to the HDMI CEC clock, name should be "cec"
-
-Example:
- hdmi: hdmi at 012 {
- compatible = "fsl,imx6q-hdmi";
- reg = <0x0012 0x9000>;
- interrupts = <0 115 0x04>;
- gpr = <&gpr>;
- clocks = <&clks 123>, <&clks 124>;
- clock-names = "iahb", "isfr";
- ddc-i2c-bus = <&i2c2>;
-
- port at 0 {
- reg = <0>;
-
- hdmi_mux_0: endpoint {
- remote-endpoint = <&ipu1_di0_hdmi>;
- };
- };
-
- port at 1 {
- reg = <1>;
-
- hdmi_mux_1: endpoint {
- remote-endpoint = <&ipu1_di1_hdmi>;
- };
- };
- };
+Synopsys DesignWare HDMI TX Encoder
+===
+
+This document defines device tree properties for the Synopsys DesignWare HDMI
+TX Encoder (DWC HDMI TX). It doesn't constitue a device tree binding
+specification by itself but is meant to be referenced by platform-specific
+device tree bindings.
+
+When referenced from platform device tree bindings the properties defined in
+this document are defined as follows. The platform device tree bindings are
+responsible for defining whether each property is required or optional.
+
+- reg: Memory mapped base address and length of the DWC HDMI TX registers.
+
+- reg-io-width: Width of the registers specified by the reg property. The
+ value is expressed in bytes and must be equal to 1 or 4 if specified. The
+ register width defaults to 1 if the property is not present.
+
+- interrupts: Reference to the DWC HDMI TX interrupt.
+
+- clocks: References to all the clocks specified in the clock-names property
+ as specified in Documentation/devicetree/bindings/clock/clock-bindings.txt.
+
+- clock-names: The DWC HDMI TX uses the following clocks.
+
+ - "iahb" is the bus clock for either AHB and APB (mandatory).
+ - "isfr" is the internal register configuration clock (mandatory).
+ - "cec" is the HDMI CEC controller main clock (optional).
+
+- ports: The connectivity of the DWC HDMI TX with the rest of the system is
+ expressed in using ports as specified in the device graph bindings defined
+ in Documentation/devicetree/bindings/graph.txt. The numbering of the ports
+ is platform-specific.
diff --git a/Documentation/devicetree/bindings/display/imx/hdmi.txt
b/Documentation/devicetree/bindings/display/imx/hdmi.txt
index 1b756cf9afb0..66a8f86e5d12 100644
--- a/Documentation/devicetree/bindings/display/imx/hdmi.txt
+++ b/Documentation/devicetree/bindings/display/imx/hdmi.txt
@@ -1,29 +1,36 @@
-Device-Tree bindings for HDMI Transmitter
+Freescale i.MX6 DWC HDMI TX Encoder
+===
-HDMI Transmitter
-
+The HDMI trans
[PATCH v2 20/29] drm: bridge: dw-hdmi: Remove device type from platform data
From: Kieran Bingham
The device type isn't used anymore now that workarounds and PHY-specific
operations are performed based on version information read at runtime.
Remove it.
Signed-off-by: Kieran Bingham
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/dw-hdmi.c| 2 --
drivers/gpu/drm/imx/dw_hdmi-imx.c | 2 --
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 1 -
include/drm/bridge/dw_hdmi.h| 7 ---
4 files changed, 12 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index ebea96ad5dd0..8480f95d3e0b 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -127,7 +127,6 @@ struct dw_hdmi {
struct drm_connector connector;
struct drm_bridge bridge;
- enum dw_hdmi_devtype dev_type;
unsigned int version;
struct platform_device *audio;
@@ -1969,7 +1968,6 @@ __dw_hdmi_probe(struct platform_device *pdev,
hdmi->plat_data = plat_data;
hdmi->dev = dev;
- hdmi->dev_type = plat_data->dev_type;
hdmi->sample_rate = 48000;
hdmi->disabled = true;
hdmi->rxsense = true;
diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c
b/drivers/gpu/drm/imx/dw_hdmi-imx.c
index f645275e6e63..f039641070ac 100644
--- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
+++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
@@ -175,7 +175,6 @@ static struct dw_hdmi_plat_data imx6q_hdmi_drv_data = {
.mpll_cfg = imx_mpll_cfg,
.cur_ctr= imx_cur_ctr,
.phy_config = imx_phy_config,
- .dev_type = IMX6Q_HDMI,
.mode_valid = imx6q_hdmi_mode_valid,
};
@@ -183,7 +182,6 @@ static struct dw_hdmi_plat_data imx6dl_hdmi_drv_data = {
.mpll_cfg = imx_mpll_cfg,
.cur_ctr = imx_cur_ctr,
.phy_config = imx_phy_config,
- .dev_type = IMX6DL_HDMI,
.mode_valid = imx6dl_hdmi_mode_valid,
};
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index a6d4a0236e8f..d53827413996 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -237,7 +237,6 @@ static const struct dw_hdmi_plat_data
rockchip_hdmi_drv_data = {
.mpll_cfg = rockchip_mpll_cfg,
.cur_ctr= rockchip_cur_ctr,
.phy_config = rockchip_phy_config,
- .dev_type = RK3288_HDMI,
};
static const struct of_device_id dw_hdmi_rockchip_dt_ids[] = {
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index c539f64a280a..735a8ab2509c 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -21,12 +21,6 @@ enum {
DW_HDMI_RES_MAX,
};
-enum dw_hdmi_devtype {
- IMX6Q_HDMI,
- IMX6DL_HDMI,
- RK3288_HDMI,
-};
-
enum dw_hdmi_phy_type {
DW_HDMI_PHY_DWC_HDMI_TX_PHY = 0x00,
DW_HDMI_PHY_DWC_MHL_PHY_HEAC = 0xb2,
@@ -58,7 +52,6 @@ struct dw_hdmi_phy_config {
};
struct dw_hdmi_plat_data {
- enum dw_hdmi_devtype dev_type;
const struct dw_hdmi_mpll_config *mpll_cfg;
const struct dw_hdmi_curr_ctrl *cur_ctr;
const struct dw_hdmi_phy_config *phy_config;
--
Regards,
Laurent Pinchart
[PATCH v2 19/29] drm: bridge: dw-hdmi: Add support for custom PHY configuration
From: Kieran Bingham
The DWC HDMI TX controller interfaces with a companion PHY. While
Synopsys provides multiple standard PHYs, SoC vendors can also integrate
a custom PHY.
Modularize PHY configuration to support vendor PHYs through platform
data. The existing PHY configuration code was originally written to
support the DWC HDMI 3D TX PHY, and seems to be compatible with the DWC
MLP PHY. The HDMI 2.0 PHY will require a separate configuration
function.
Signed-off-by: Kieran Bingham
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Check pdata->phy_configure in hdmi_phy_configure() to avoid
dereferencing NULL pointer.
---
drivers/gpu/drm/bridge/dw-hdmi.c | 107 ++-
include/drm/bridge/dw_hdmi.h | 7 +++
2 files changed, 79 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 7c69c8c0285e..ebea96ad5dd0 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -118,6 +118,9 @@ struct dw_hdmi_phy_data {
const char *name;
unsigned int gen;
bool has_svsret;
+ int (*configure)(struct dw_hdmi *hdmi,
+const struct dw_hdmi_plat_data *pdata,
+unsigned long mpixelclock);
};
struct dw_hdmi {
@@ -878,8 +881,8 @@ static bool hdmi_phy_wait_i2c_done(struct dw_hdmi *hdmi,
int msec)
return true;
}
-static void hdmi_phy_i2c_write(struct dw_hdmi *hdmi, unsigned short data,
-unsigned char addr)
+void dw_hdmi_phy_i2c_write(struct dw_hdmi *hdmi, unsigned short data,
+ unsigned char addr)
{
hdmi_writeb(hdmi, 0xFF, HDMI_IH_I2CMPHY_STAT0);
hdmi_writeb(hdmi, addr, HDMI_PHY_I2CM_ADDRESS_ADDR);
@@ -891,6 +894,7 @@ static void hdmi_phy_i2c_write(struct dw_hdmi *hdmi,
unsigned short data,
HDMI_PHY_I2CM_OPERATION_ADDR);
hdmi_phy_wait_i2c_done(hdmi, 1000);
}
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_i2c_write);
static void dw_hdmi_phy_enable_powerdown(struct dw_hdmi *hdmi, bool enable)
{
@@ -966,37 +970,62 @@ static void dw_hdmi_phy_power_on(struct dw_hdmi *hdmi)
}
}
-static int hdmi_phy_configure(struct dw_hdmi *hdmi)
+/*
+ * PHY configuration function for the DWC HDMI 3D TX PHY. Based on the
available
+ * information the DWC MHL PHY has the same register layout and is thus also
+ * supported by this function.
+ */
+static int hdmi_phy_configure_dwc_hdmi_3d_tx(struct dw_hdmi *hdmi,
+ const struct dw_hdmi_plat_data *pdata,
+ unsigned long mpixelclock)
{
- u8 val, msec;
- const struct dw_hdmi_plat_data *pdata = hdmi->plat_data;
const struct dw_hdmi_mpll_config *mpll_config = pdata->mpll_cfg;
const struct dw_hdmi_curr_ctrl *curr_ctrl = pdata->cur_ctr;
const struct dw_hdmi_phy_config *phy_config = pdata->phy_config;
/* PLL/MPLL Cfg - always match on final entry */
for (; mpll_config->mpixelclock != ~0UL; mpll_config++)
- if (hdmi->hdmi_data.video_mode.mpixelclock <=
- mpll_config->mpixelclock)
+ if (mpixelclock <= mpll_config->mpixelclock)
break;
for (; curr_ctrl->mpixelclock != ~0UL; curr_ctrl++)
- if (hdmi->hdmi_data.video_mode.mpixelclock <=
- curr_ctrl->mpixelclock)
+ if (mpixelclock <= curr_ctrl->mpixelclock)
break;
for (; phy_config->mpixelclock != ~0UL; phy_config++)
- if (hdmi->hdmi_data.video_mode.mpixelclock <=
- phy_config->mpixelclock)
+ if (mpixelclock <= phy_config->mpixelclock)
break;
if (mpll_config->mpixelclock == ~0UL ||
curr_ctrl->mpixelclock == ~0UL ||
- phy_config->mpixelclock == ~0UL) {
- dev_err(hdmi->dev, "Pixel clock %d - unsupported by HDMI\n",
- hdmi->hdmi_data.video_mode.mpixelclock);
+ phy_config->mpixelclock == ~0UL)
return -EINVAL;
- }
+
+ dw_hdmi_phy_i2c_write(hdmi, mpll_config->res[0].cpce, 0x06);
+ dw_hdmi_phy_i2c_write(hdmi, mpll_config->res[0].gmp, 0x15);
+
+ /* CURRCTRL */
+ dw_hdmi_phy_i2c_write(hdmi, curr_ctrl->curr[0], 0x10);
+
+ dw_hdmi_phy_i2c_write(hdmi, 0x, 0x13); /* PLLPHBYCTRL */
+ dw_hdmi_phy_i2c_write(hdmi, 0x0006, 0x17);
+
+ dw_hdmi_phy_i2c_write(hdmi, phy_config->term, 0x19); /* TXTERM */
+ dw_hdmi_phy_i2c_write(hdmi, phy_config->sym_ctr, 0x09); /* CKSYMTXCTRL
*/
+ dw_hdmi_phy_i2c_write(hdmi, phy_config->vlev_ctr, 0x0E); /* VLEVCTRL */
+
+ /* REMOVE CLK TERM */
+ dw_hdmi_phy_i2c_write(hdmi, 0x8000, 0x05); /* CKCALCTRL */
+
+ return 0;
+}
+
+static int hdmi_phy_configure(struct dw_hdmi *hdmi)
+{
+ const struct dw_hdmi_plat_data *pdata = hdmi->plat_data;
+ unsig
[PATCH v2 18/29] drm: bridge: dw-hdmi: Move CSC configuration out of PHY code
The color space converter isn't part of the PHY, move its configuration
out of PHY code.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/dw-hdmi.c | 25 ++---
1 file changed, 10 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 6167eb6806fe..7c69c8c0285e 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -966,7 +966,7 @@ static void dw_hdmi_phy_power_on(struct dw_hdmi *hdmi)
}
}
-static int hdmi_phy_configure(struct dw_hdmi *hdmi, int cscon)
+static int hdmi_phy_configure(struct dw_hdmi *hdmi)
{
u8 val, msec;
const struct dw_hdmi_plat_data *pdata = hdmi->plat_data;
@@ -998,14 +998,6 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, int
cscon)
return -EINVAL;
}
- /* Enable csc path */
- if (cscon)
- val = HDMI_MC_FLOWCTRL_FEED_THROUGH_OFF_CSC_IN_PATH;
- else
- val = HDMI_MC_FLOWCTRL_FEED_THROUGH_OFF_CSC_BYPASS;
-
- hdmi_writeb(hdmi, val, HDMI_MC_FLOWCTRL);
-
dw_hdmi_phy_power_off(hdmi);
/* PHY reset */
@@ -1063,18 +1055,13 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, int
cscon)
static int dw_hdmi_phy_init(struct dw_hdmi *hdmi)
{
int i, ret;
- bool cscon;
-
- /*check csc whether needed activated in HDMI mode */
- cscon = hdmi->sink_is_hdmi && is_color_space_conversion(hdmi);
/* HDMI Phy spec says to do the phy initialization sequence twice */
for (i = 0; i < 2; i++) {
dw_hdmi_phy_sel_data_en_pol(hdmi, 1);
dw_hdmi_phy_sel_interface_control(hdmi, 0);
- /* Enable CSC */
- ret = hdmi_phy_configure(hdmi, cscon);
+ ret = hdmi_phy_configure(hdmi);
if (ret)
return ret;
}
@@ -1334,6 +1321,14 @@ static void dw_hdmi_enable_video_path(struct dw_hdmi
*hdmi)
clkdis &= ~HDMI_MC_CLKDIS_CSCCLK_DISABLE;
hdmi_writeb(hdmi, clkdis, HDMI_MC_CLKDIS);
}
+
+ /* Enable color space conversion if needed (for HDMI sinks only). */
+ if (hdmi->sink_is_hdmi && is_color_space_conversion(hdmi))
+ hdmi_writeb(hdmi, HDMI_MC_FLOWCTRL_FEED_THROUGH_OFF_CSC_IN_PATH,
+ HDMI_MC_FLOWCTRL);
+ else
+ hdmi_writeb(hdmi, HDMI_MC_FLOWCTRL_FEED_THROUGH_OFF_CSC_BYPASS,
+ HDMI_MC_FLOWCTRL);
}
static void hdmi_enable_audio_clk(struct dw_hdmi *hdmi)
--
Regards,
Laurent Pinchart
[PATCH v2 17/29] drm: bridge: dw-hdmi: Refactor PHY power handling
Instead of spreading version-dependent PHY power handling code around,
group it in two functions to power the PHY on and off and use them
through the driver.
Powering off the PHY at the beginning of the setup phase is currently
split in two locations for first and second generation PHYs, group all
the operations in the dw_hdmi_phy_init() function.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/dw-hdmi.c | 54 ++--
1 file changed, 35 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index ef4f2f96ed2c..6167eb6806fe 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -116,6 +116,7 @@ struct dw_hdmi_i2c {
struct dw_hdmi_phy_data {
enum dw_hdmi_phy_type type;
const char *name;
+ unsigned int gen;
bool has_svsret;
};
@@ -940,6 +941,31 @@ static void dw_hdmi_phy_sel_interface_control(struct
dw_hdmi *hdmi, u8 enable)
HDMI_PHY_CONF0_SELDIPIF_MASK);
}
+static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
+{
+ if (hdmi->phy->gen == 1) {
+ dw_hdmi_phy_enable_tmds(hdmi, 0);
+ dw_hdmi_phy_enable_powerdown(hdmi, true);
+ } else {
+ dw_hdmi_phy_gen2_txpwron(hdmi, 0);
+ dw_hdmi_phy_gen2_pddq(hdmi, 1);
+ }
+}
+
+static void dw_hdmi_phy_power_on(struct dw_hdmi *hdmi)
+{
+ if (hdmi->phy->gen == 1) {
+ dw_hdmi_phy_enable_powerdown(hdmi, false);
+
+ /* Toggle TMDS enable. */
+ dw_hdmi_phy_enable_tmds(hdmi, 0);
+ dw_hdmi_phy_enable_tmds(hdmi, 1);
+ } else {
+ dw_hdmi_phy_gen2_txpwron(hdmi, 1);
+ dw_hdmi_phy_gen2_pddq(hdmi, 0);
+ }
+}
+
static int hdmi_phy_configure(struct dw_hdmi *hdmi, int cscon)
{
u8 val, msec;
@@ -980,11 +1006,7 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, int
cscon)
hdmi_writeb(hdmi, val, HDMI_MC_FLOWCTRL);
- /* gen2 tx power off */
- dw_hdmi_phy_gen2_txpwron(hdmi, 0);
-
- /* gen2 pddq */
- dw_hdmi_phy_gen2_pddq(hdmi, 1);
+ dw_hdmi_phy_power_off(hdmi);
/* PHY reset */
hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_DEASSERT, HDMI_MC_PHYRSTZ);
@@ -1013,15 +1035,7 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, int
cscon)
/* REMOVE CLK TERM */
hdmi_phy_i2c_write(hdmi, 0x8000, 0x05); /* CKCALCTRL */
- dw_hdmi_phy_enable_powerdown(hdmi, false);
-
- /* toggle TMDS enable */
- dw_hdmi_phy_enable_tmds(hdmi, 0);
- dw_hdmi_phy_enable_tmds(hdmi, 1);
-
- /* gen2 tx power on */
- dw_hdmi_phy_gen2_txpwron(hdmi, 1);
- dw_hdmi_phy_gen2_pddq(hdmi, 0);
+ dw_hdmi_phy_power_on(hdmi);
/* The DWC MHL and HDMI 2.0 PHYs need the SVSRET signal to be set. */
if (hdmi->phy->has_svsret)
@@ -1058,8 +1072,6 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi)
for (i = 0; i < 2; i++) {
dw_hdmi_phy_sel_data_en_pol(hdmi, 1);
dw_hdmi_phy_sel_interface_control(hdmi, 0);
- dw_hdmi_phy_enable_tmds(hdmi, 0);
- dw_hdmi_phy_enable_powerdown(hdmi, true);
/* Enable CSC */
ret = hdmi_phy_configure(hdmi, cscon);
@@ -1290,9 +1302,7 @@ static void dw_hdmi_phy_disable(struct dw_hdmi *hdmi)
if (!hdmi->phy_enabled)
return;
- dw_hdmi_phy_enable_tmds(hdmi, 0);
- dw_hdmi_phy_enable_powerdown(hdmi, true);
-
+ dw_hdmi_phy_power_off(hdmi);
hdmi->phy_enabled = false;
}
@@ -1853,23 +1863,29 @@ static const struct dw_hdmi_phy_data dw_hdmi_phys[] = {
{
.type = DW_HDMI_PHY_DWC_HDMI_TX_PHY,
.name = "DWC HDMI TX PHY",
+ .gen = 1,
}, {
.type = DW_HDMI_PHY_DWC_MHL_PHY_HEAC,
.name = "DWC MHL PHY + HEAC PHY",
+ .gen = 2,
.has_svsret = true,
}, {
.type = DW_HDMI_PHY_DWC_MHL_PHY,
.name = "DWC MHL PHY",
+ .gen = 2,
.has_svsret = true,
}, {
.type = DW_HDMI_PHY_DWC_HDMI_3D_TX_PHY_HEAC,
.name = "DWC HDMI 3D TX PHY + HEAC PHY",
+ .gen = 2,
}, {
.type = DW_HDMI_PHY_DWC_HDMI_3D_TX_PHY,
.name = "DWC HDMI 3D TX PHY",
+ .gen = 2,
}, {
.type = DW_HDMI_PHY_DWC_HDMI20_TX_PHY,
.name = "DWC HDMI 2.0 TX PHY",
+ .gen = 2,
.has_svsret = true,
}
};
--
Regards,
Laurent Pinchart
[PATCH v2 16/29] drm: bridge: dw-hdmi: Detect PHY type at runtime
Detect the PHY type and use it to handle the PHY type-specific SVSRET
signal.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/dw-hdmi.c | 68 ++--
include/drm/bridge/dw_hdmi.h | 10 ++
2 files changed, 75 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index f4faa14213e5..ef4f2f96ed2c 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -113,6 +113,12 @@ struct dw_hdmi_i2c {
boolis_regaddr;
};
+struct dw_hdmi_phy_data {
+ enum dw_hdmi_phy_type type;
+ const char *name;
+ bool has_svsret;
+};
+
struct dw_hdmi {
struct drm_connector connector;
struct drm_bridge bridge;
@@ -134,7 +140,9 @@ struct dw_hdmi {
u8 edid[HDMI_EDID_LEN];
bool cable_plugin;
+ const struct dw_hdmi_phy_data *phy;
bool phy_enabled;
+
struct drm_display_mode previous_mode;
struct i2c_adapter *ddc;
@@ -1015,7 +1023,8 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, int
cscon)
dw_hdmi_phy_gen2_txpwron(hdmi, 1);
dw_hdmi_phy_gen2_pddq(hdmi, 0);
- if (hdmi->dev_type == RK3288_HDMI)
+ /* The DWC MHL and HDMI 2.0 PHYs need the SVSRET signal to be set. */
+ if (hdmi->phy->has_svsret)
dw_hdmi_phy_enable_svsret(hdmi, 1);
/*Wait for PHY PLL lock */
@@ -1840,6 +1849,54 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
return IRQ_HANDLED;
}
+static const struct dw_hdmi_phy_data dw_hdmi_phys[] = {
+ {
+ .type = DW_HDMI_PHY_DWC_HDMI_TX_PHY,
+ .name = "DWC HDMI TX PHY",
+ }, {
+ .type = DW_HDMI_PHY_DWC_MHL_PHY_HEAC,
+ .name = "DWC MHL PHY + HEAC PHY",
+ .has_svsret = true,
+ }, {
+ .type = DW_HDMI_PHY_DWC_MHL_PHY,
+ .name = "DWC MHL PHY",
+ .has_svsret = true,
+ }, {
+ .type = DW_HDMI_PHY_DWC_HDMI_3D_TX_PHY_HEAC,
+ .name = "DWC HDMI 3D TX PHY + HEAC PHY",
+ }, {
+ .type = DW_HDMI_PHY_DWC_HDMI_3D_TX_PHY,
+ .name = "DWC HDMI 3D TX PHY",
+ }, {
+ .type = DW_HDMI_PHY_DWC_HDMI20_TX_PHY,
+ .name = "DWC HDMI 2.0 TX PHY",
+ .has_svsret = true,
+ }
+};
+
+static int dw_hdmi_detect_phy(struct dw_hdmi *hdmi)
+{
+ unsigned int i;
+ u8 phy_type;
+
+ phy_type = hdmi_readb(hdmi, HDMI_CONFIG2_ID);
+
+ for (i = 0; i < ARRAY_SIZE(dw_hdmi_phys); ++i) {
+ if (dw_hdmi_phys[i].type == phy_type) {
+ hdmi->phy = &dw_hdmi_phys[i];
+ return 0;
+ }
+ }
+
+ if (phy_type == DW_HDMI_PHY_VENDOR_PHY)
+ dev_err(hdmi->dev, "Unsupported vendor HDMI PHY\n");
+ else
+ dev_err(hdmi->dev, "Unsupported HDMI PHY type (%02x)\n",
+ phy_type);
+
+ return -ENODEV;
+}
+
static struct dw_hdmi *
__dw_hdmi_probe(struct platform_device *pdev,
const struct dw_hdmi_plat_data *plat_data)
@@ -1950,9 +2007,14 @@ __dw_hdmi_probe(struct platform_device *pdev,
goto err_iahb;
}
- dev_info(dev, "Detected HDMI TX controller v%x.%03x %s HDCP\n",
+ ret = dw_hdmi_detect_phy(hdmi);
+ if (ret < 0)
+ goto err_iahb;
+
+ dev_info(dev, "Detected HDMI TX controller v%x.%03x %s HDCP (%s)\n",
hdmi->version >> 12, hdmi->version & 0xfff,
-prod_id1 & HDMI_PRODUCT_ID1_HDCP ? "with" : "without");
+prod_id1 & HDMI_PRODUCT_ID1_HDCP ? "with" : "without",
+hdmi->phy->name);
initialize_hdmi_ih_mutes(hdmi);
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index 3bb22a849830..b080a171a23f 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -27,6 +27,16 @@ enum dw_hdmi_devtype {
RK3288_HDMI,
};
+enum dw_hdmi_phy_type {
+ DW_HDMI_PHY_DWC_HDMI_TX_PHY = 0x00,
+ DW_HDMI_PHY_DWC_MHL_PHY_HEAC = 0xb2,
+ DW_HDMI_PHY_DWC_MHL_PHY = 0xc2,
+ DW_HDMI_PHY_DWC_HDMI_3D_TX_PHY_HEAC = 0xe2,
+ DW_HDMI_PHY_DWC_HDMI_3D_TX_PHY = 0xf2,
+ DW_HDMI_PHY_DWC_HDMI20_TX_PHY = 0xf3,
+ DW_HDMI_PHY_VENDOR_PHY = 0xfe,
+};
+
struct dw_hdmi_mpll_config {
unsigned long mpixelclock;
struct {
--
Regards,
Laurent Pinchart
[PATCH v2 15/29] drm: bridge: dw-hdmi: Handle overflow workaround based on device version
Use the device version queried at runtime instead of the device type
provided through platform data to handle the overflow workaround. This
will make support of other SoCs integrating the same HDMI TX controller
version easier.
Among the supported platforms only i.MX6DL and i.MX6Q have been
identified as needing the workaround. Disabling it on Rockchip RK3288
(which integrates a v2.00a controller) didn't produce any error or
artifact.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/dw-hdmi.c | 46
1 file changed, 33 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 730a7558d4d4..f4faa14213e5 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -117,8 +117,10 @@ struct dw_hdmi {
struct drm_connector connector;
struct drm_bridge bridge;
- struct platform_device *audio;
enum dw_hdmi_devtype dev_type;
+ unsigned int version;
+
+ struct platform_device *audio;
struct device *dev;
struct clk *isfr_clk;
struct clk *iahb_clk;
@@ -1323,19 +1325,38 @@ static void hdmi_enable_audio_clk(struct dw_hdmi *hdmi)
/* Workaround to clear the overflow condition */
static void dw_hdmi_clear_overflow(struct dw_hdmi *hdmi)
{
- int count;
+ unsigned int count;
+ unsigned int i;
u8 val;
- /* TMDS software reset */
- hdmi_writeb(hdmi, (u8)~HDMI_MC_SWRSTZ_TMDSSWRST_REQ, HDMI_MC_SWRSTZ);
+ /*
+* Under some circumstances the Frame Composer arithmetic unit can miss
+* an FC register write due to being busy processing the previous one.
+* The issue can be worked around by issuing a TMDS software reset and
+* then write one of the FC registers several times.
+*
+* The number of iterations matters and depends on the HDMI TX revision
+* (and possibly on the platform). So far only i.MX6Q (v1.30a) and
+* i.MX6DL (v1.31a) have been identified as needing the workaround, with
+* 4 and 1 iterations respectively.
+*/
- val = hdmi_readb(hdmi, HDMI_FC_INVIDCONF);
- if (hdmi->dev_type == IMX6DL_HDMI) {
- hdmi_writeb(hdmi, val, HDMI_FC_INVIDCONF);
+ switch (hdmi->version) {
+ case 0x130a:
+ count = 4;
+ break;
+ case 0x131a:
+ count = 1;
+ break;
+ default:
return;
}
- for (count = 0; count < 4; count++)
+ /* TMDS software reset */
+ hdmi_writeb(hdmi, (u8)~HDMI_MC_SWRSTZ_TMDSSWRST_REQ, HDMI_MC_SWRSTZ);
+
+ val = hdmi_readb(hdmi, HDMI_FC_INVIDCONF);
+ for (i = 0; i < count; i++)
hdmi_writeb(hdmi, val, HDMI_FC_INVIDCONF);
}
@@ -1832,7 +1853,6 @@ __dw_hdmi_probe(struct platform_device *pdev,
int irq;
int ret;
u32 val = 1;
- u16 version;
u8 prod_id0;
u8 prod_id1;
u8 config0;
@@ -1917,21 +1937,21 @@ __dw_hdmi_probe(struct platform_device *pdev,
}
/* Product and revision IDs */
- version = (hdmi_readb(hdmi, HDMI_DESIGN_ID) << 8)
- | (hdmi_readb(hdmi, HDMI_REVISION_ID) << 0);
+ hdmi->version = (hdmi_readb(hdmi, HDMI_DESIGN_ID) << 8)
+ | (hdmi_readb(hdmi, HDMI_REVISION_ID) << 0);
prod_id0 = hdmi_readb(hdmi, HDMI_PRODUCT_ID0);
prod_id1 = hdmi_readb(hdmi, HDMI_PRODUCT_ID1);
if (prod_id0 != HDMI_PRODUCT_ID0_HDMI_TX ||
(prod_id1 & ~HDMI_PRODUCT_ID1_HDCP) != HDMI_PRODUCT_ID1_HDMI_TX) {
dev_err(dev, "Unsupported HDMI controller (%04x:%02x:%02x)\n",
- version, prod_id0, prod_id1);
+ hdmi->version, prod_id0, prod_id1);
ret = -ENODEV;
goto err_iahb;
}
dev_info(dev, "Detected HDMI TX controller v%x.%03x %s HDCP\n",
-version >> 12, version & 0xfff,
+hdmi->version >> 12, hdmi->version & 0xfff,
prod_id1 & HDMI_PRODUCT_ID1_HDCP ? "with" : "without");
initialize_hdmi_ih_mutes(hdmi);
--
Regards,
Laurent Pinchart
[PATCH v2 14/29] drm: bridge: dw-hdmi: Detect AHB audio DMA using correct register
Bit 0 in CONFIG1_ID tells whether the IP core uses an AHB slave
interface for control. The correct way to identify AHB audio DMA support
is through bit 1 in CONFIG3_ID.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/dw-hdmi.c | 6 +++---
drivers/gpu/drm/bridge/dw-hdmi.h | 4
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 1809247745b8..730a7558d4d4 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -1836,7 +1836,7 @@ __dw_hdmi_probe(struct platform_device *pdev,
u8 prod_id0;
u8 prod_id1;
u8 config0;
- u8 config1;
+ u8 config3;
hdmi = devm_kzalloc(dev, sizeof(*hdmi), GFP_KERNEL);
if (!hdmi)
@@ -1988,9 +1988,9 @@ __dw_hdmi_probe(struct platform_device *pdev,
pdevinfo.id = PLATFORM_DEVID_AUTO;
config0 = hdmi_readb(hdmi, HDMI_CONFIG0_ID);
- config1 = hdmi_readb(hdmi, HDMI_CONFIG1_ID);
+ config3 = hdmi_readb(hdmi, HDMI_CONFIG3_ID);
- if (config1 & HDMI_CONFIG1_AHB) {
+ if (config3 & HDMI_CONFIG3_AHBAUDDMA) {
struct dw_hdmi_audio_data audio;
audio.phys = iores->start;
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.h b/drivers/gpu/drm/bridge/dw-hdmi.h
index 91d7fabbd6e5..a4fd64a203c9 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.h
+++ b/drivers/gpu/drm/bridge/dw-hdmi.h
@@ -559,6 +559,10 @@ enum {
/* CONFIG1_ID field values */
HDMI_CONFIG1_AHB = 0x01,
+/* CONFIG3_ID field values */
+ HDMI_CONFIG3_AHBAUDDMA = 0x02,
+ HDMI_CONFIG3_GPAUD = 0x01,
+
/* IH_FC_INT2 field values */
HDMI_IH_FC_INT2_OVERFLOW_MASK = 0x03,
HDMI_IH_FC_INT2_LOW_PRIORITY_OVERFLOW = 0x02,
--
Regards,
Laurent Pinchart
[PATCH v2 13/29] drm: bridge: dw-hdmi: Reject invalid product IDs
The DWC HDMI TX can be recognized by the two product identification
registers. If the registers don't read as expect the IP will be very
different than what the driver has been designed for, or will be
misconfigured in a way that makes it non-operational (invalid memory
address, incorrect clocks, ...). We should reject this situation with an
error.
While this isn't critical for proper operation with supported IPs at the
moment, the driver will soon gain automatic device-specific handling
based on runtime device identification. This change makes it easier to
implement that without having to default to a random guess in case the
device can't be identified.
While at it print a readable version number in the device identification
message instead of raw register values.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/dw-hdmi.c | 25 +++--
drivers/gpu/drm/bridge/dw-hdmi.h | 8
2 files changed, 27 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 06c252f560ad..1809247745b8 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -1832,6 +1832,9 @@ __dw_hdmi_probe(struct platform_device *pdev,
int irq;
int ret;
u32 val = 1;
+ u16 version;
+ u8 prod_id0;
+ u8 prod_id1;
u8 config0;
u8 config1;
@@ -1914,12 +1917,22 @@ __dw_hdmi_probe(struct platform_device *pdev,
}
/* Product and revision IDs */
- dev_info(dev,
-"Detected HDMI controller 0x%x:0x%x:0x%x:0x%x\n",
-hdmi_readb(hdmi, HDMI_DESIGN_ID),
-hdmi_readb(hdmi, HDMI_REVISION_ID),
-hdmi_readb(hdmi, HDMI_PRODUCT_ID0),
-hdmi_readb(hdmi, HDMI_PRODUCT_ID1));
+ version = (hdmi_readb(hdmi, HDMI_DESIGN_ID) << 8)
+ | (hdmi_readb(hdmi, HDMI_REVISION_ID) << 0);
+ prod_id0 = hdmi_readb(hdmi, HDMI_PRODUCT_ID0);
+ prod_id1 = hdmi_readb(hdmi, HDMI_PRODUCT_ID1);
+
+ if (prod_id0 != HDMI_PRODUCT_ID0_HDMI_TX ||
+ (prod_id1 & ~HDMI_PRODUCT_ID1_HDCP) != HDMI_PRODUCT_ID1_HDMI_TX) {
+ dev_err(dev, "Unsupported HDMI controller (%04x:%02x:%02x)\n",
+ version, prod_id0, prod_id1);
+ ret = -ENODEV;
+ goto err_iahb;
+ }
+
+ dev_info(dev, "Detected HDMI TX controller v%x.%03x %s HDCP\n",
+version >> 12, version & 0xfff,
+prod_id1 & HDMI_PRODUCT_ID1_HDCP ? "with" : "without");
initialize_hdmi_ih_mutes(hdmi);
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.h b/drivers/gpu/drm/bridge/dw-hdmi.h
index 08235aef2fa3..91d7fabbd6e5 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.h
+++ b/drivers/gpu/drm/bridge/dw-hdmi.h
@@ -545,6 +545,14 @@
#define HDMI_I2CM_FS_SCL_LCNT_0_ADDR0x7E12
enum {
+/* PRODUCT_ID0 field values */
+ HDMI_PRODUCT_ID0_HDMI_TX = 0xa0,
+
+/* PRODUCT_ID1 field values */
+ HDMI_PRODUCT_ID1_HDCP = 0xc0,
+ HDMI_PRODUCT_ID1_HDMI_RX = 0x02,
+ HDMI_PRODUCT_ID1_HDMI_TX = 0x01,
+
/* CONFIG0_ID field values */
HDMI_CONFIG0_I2S = 0x10,
--
Regards,
Laurent Pinchart
[PATCH v2 12/29] drm: bridge: dw-hdmi: Rename CONF0 SPARECTRL bit to SVSRET
The bit is documented in a Rockchip BSP as
#define m_SVSRET_SIG (1 << 5) /* depend on PHY_MHL_COMB0=1 */
This is confirmed by a Renesas platform, which uses a 2.0 DWC HDMI TX as
the RK3288. Rename the bit accordingly.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/dw-hdmi.c | 8
drivers/gpu/drm/bridge/dw-hdmi.h | 4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index b4fb0bd78910..06c252f560ad 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -895,11 +895,11 @@ static void dw_hdmi_phy_enable_tmds(struct dw_hdmi *hdmi,
u8 enable)
HDMI_PHY_CONF0_ENTMDS_MASK);
}
-static void dw_hdmi_phy_enable_spare(struct dw_hdmi *hdmi, u8 enable)
+static void dw_hdmi_phy_enable_svsret(struct dw_hdmi *hdmi, u8 enable)
{
hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
-HDMI_PHY_CONF0_SPARECTRL_OFFSET,
-HDMI_PHY_CONF0_SPARECTRL_MASK);
+HDMI_PHY_CONF0_SVSRET_OFFSET,
+HDMI_PHY_CONF0_SVSRET_MASK);
}
static void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
@@ -1014,7 +1014,7 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, int
cscon)
dw_hdmi_phy_gen2_pddq(hdmi, 0);
if (hdmi->dev_type == RK3288_HDMI)
- dw_hdmi_phy_enable_spare(hdmi, 1);
+ dw_hdmi_phy_enable_svsret(hdmi, 1);
/*Wait for PHY PLL lock */
msec = 5;
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.h b/drivers/gpu/drm/bridge/dw-hdmi.h
index 55135bbd0c16..08235aef2fa3 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.h
+++ b/drivers/gpu/drm/bridge/dw-hdmi.h
@@ -847,8 +847,8 @@ enum {
HDMI_PHY_CONF0_PDZ_OFFSET = 7,
HDMI_PHY_CONF0_ENTMDS_MASK = 0x40,
HDMI_PHY_CONF0_ENTMDS_OFFSET = 6,
- HDMI_PHY_CONF0_SPARECTRL_MASK = 0x20,
- HDMI_PHY_CONF0_SPARECTRL_OFFSET = 5,
+ HDMI_PHY_CONF0_SVSRET_MASK = 0x20,
+ HDMI_PHY_CONF0_SVSRET_OFFSET = 5,
HDMI_PHY_CONF0_GEN2_PDDQ_MASK = 0x10,
HDMI_PHY_CONF0_GEN2_PDDQ_OFFSET = 4,
HDMI_PHY_CONF0_GEN2_TXPWRON_MASK = 0x8,
--
Regards,
Laurent Pinchart
[PATCH v2 11/29] drm: bridge: dw-hdmi: Remove PHY configuration resolution parameter
From: Kieran Bingham
The current code hard codes the call of hdmi_phy_configure() to be 8bpp
and provides extraneous error checking to verify that this hardcoded
value is correct. Simplify the implementation by removing the argument.
Signed-off-by: Kieran Bingham
Signed-off-by: Laurent Pinchart
Reviewed-by: Jose Abreu
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/dw-hdmi.c | 27 +--
1 file changed, 5 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 107fea49c4c6..b4fb0bd78910 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -930,31 +930,14 @@ static void dw_hdmi_phy_sel_interface_control(struct
dw_hdmi *hdmi, u8 enable)
HDMI_PHY_CONF0_SELDIPIF_MASK);
}
-static int hdmi_phy_configure(struct dw_hdmi *hdmi,
- unsigned char res, int cscon)
+static int hdmi_phy_configure(struct dw_hdmi *hdmi, int cscon)
{
- unsigned res_idx;
u8 val, msec;
const struct dw_hdmi_plat_data *pdata = hdmi->plat_data;
const struct dw_hdmi_mpll_config *mpll_config = pdata->mpll_cfg;
const struct dw_hdmi_curr_ctrl *curr_ctrl = pdata->cur_ctr;
const struct dw_hdmi_phy_config *phy_config = pdata->phy_config;
- switch (res) {
- case 0: /* color resolution 0 is 8 bit colour depth */
- case 8:
- res_idx = DW_HDMI_RES_8;
- break;
- case 10:
- res_idx = DW_HDMI_RES_10;
- break;
- case 12:
- res_idx = DW_HDMI_RES_12;
- break;
- default:
- return -EINVAL;
- }
-
/* PLL/MPLL Cfg - always match on final entry */
for (; mpll_config->mpixelclock != ~0UL; mpll_config++)
if (hdmi->hdmi_data.video_mode.mpixelclock <=
@@ -1004,11 +987,11 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi,
HDMI_PHY_I2CM_SLAVE_ADDR);
hdmi_phy_test_clear(hdmi, 0);
- hdmi_phy_i2c_write(hdmi, mpll_config->res[res_idx].cpce, 0x06);
- hdmi_phy_i2c_write(hdmi, mpll_config->res[res_idx].gmp, 0x15);
+ hdmi_phy_i2c_write(hdmi, mpll_config->res[0].cpce, 0x06);
+ hdmi_phy_i2c_write(hdmi, mpll_config->res[0].gmp, 0x15);
/* CURRCTRL */
- hdmi_phy_i2c_write(hdmi, curr_ctrl->curr[res_idx], 0x10);
+ hdmi_phy_i2c_write(hdmi, curr_ctrl->curr[0], 0x10);
hdmi_phy_i2c_write(hdmi, 0x, 0x13); /* PLLPHBYCTRL */
hdmi_phy_i2c_write(hdmi, 0x0006, 0x17);
@@ -1068,7 +1051,7 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi)
dw_hdmi_phy_enable_powerdown(hdmi, true);
/* Enable CSC */
- ret = hdmi_phy_configure(hdmi, 8, cscon);
+ ret = hdmi_phy_configure(hdmi, cscon);
if (ret)
return ret;
}
--
Regards,
Laurent Pinchart
[PATCH v2 10/29] drm: bridge: dw-hdmi: Implement DRM bridge registration
As an option for drivers not based on the component framework, register
the bridge with the DRM core with the DRM bridge API. Existing drivers
based on dw_hdmi_bind() and dw_hdmi_unbind() are not affected as those
functions are preserved with their current behaviour.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jose Abreu
---
drivers/gpu/drm/bridge/dw-hdmi.c | 112 ---
include/drm/bridge/dw_hdmi.h | 3 ++
2 files changed, 83 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 88cd40adb977..107fea49c4c6 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -1836,24 +1836,9 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
return IRQ_HANDLED;
}
-static int dw_hdmi_register(struct drm_encoder *encoder, struct dw_hdmi *hdmi)
-{
- struct drm_bridge *bridge = &hdmi->bridge;
- int ret;
-
- bridge->driver_private = hdmi;
- bridge->funcs = &dw_hdmi_bridge_funcs;
- ret = drm_bridge_attach(encoder, bridge, NULL);
- if (ret) {
- DRM_ERROR("Failed to initialize bridge with drm\n");
- return -EINVAL;
- }
-
- return 0;
-}
-
-int dw_hdmi_bind(struct platform_device *pdev, struct drm_encoder *encoder,
-const struct dw_hdmi_plat_data *plat_data)
+static struct dw_hdmi *
+__dw_hdmi_probe(struct platform_device *pdev,
+ const struct dw_hdmi_plat_data *plat_data)
{
struct device *dev = &pdev->dev;
struct device_node *np = dev->of_node;
@@ -1869,7 +1854,7 @@ int dw_hdmi_bind(struct platform_device *pdev, struct
drm_encoder *encoder,
hdmi = devm_kzalloc(dev, sizeof(*hdmi), GFP_KERNEL);
if (!hdmi)
- return -ENOMEM;
+ return ERR_PTR(-ENOMEM);
hdmi->plat_data = plat_data;
hdmi->dev = dev;
@@ -1896,7 +1881,7 @@ int dw_hdmi_bind(struct platform_device *pdev, struct
drm_encoder *encoder,
break;
default:
dev_err(dev, "reg-io-width must be 1 or 4\n");
- return -EINVAL;
+ return ERR_PTR(-EINVAL);
}
ddc_node = of_parse_phandle(np, "ddc-i2c-bus", 0);
@@ -1905,7 +1890,7 @@ int dw_hdmi_bind(struct platform_device *pdev, struct
drm_encoder *encoder,
of_node_put(ddc_node);
if (!hdmi->ddc) {
dev_dbg(hdmi->dev, "failed to read ddc node\n");
- return -EPROBE_DEFER;
+ return ERR_PTR(-EPROBE_DEFER);
}
} else {
@@ -1956,8 +1941,10 @@ int dw_hdmi_bind(struct platform_device *pdev, struct
drm_encoder *encoder,
initialize_hdmi_ih_mutes(hdmi);
irq = platform_get_irq(pdev, 0);
- if (irq < 0)
+ if (irq < 0) {
+ ret = irq;
goto err_iahb;
+ }
ret = devm_request_threaded_irq(dev, irq, dw_hdmi_hardirq,
dw_hdmi_irq, IRQF_SHARED,
@@ -1988,11 +1975,11 @@ int dw_hdmi_bind(struct platform_device *pdev, struct
drm_encoder *encoder,
hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
HDMI_IH_PHY_STAT0);
- ret = dw_hdmi_fb_registered(hdmi);
- if (ret)
- goto err_iahb;
+ hdmi->bridge.driver_private = hdmi;
+ hdmi->bridge.funcs = &dw_hdmi_bridge_funcs;
+ hdmi->bridge.of_node = pdev->dev.of_node;
- ret = dw_hdmi_register(encoder, hdmi);
+ ret = dw_hdmi_fb_registered(hdmi);
if (ret)
goto err_iahb;
@@ -2041,7 +2028,7 @@ int dw_hdmi_bind(struct platform_device *pdev, struct
drm_encoder *encoder,
platform_set_drvdata(pdev, hdmi);
- return 0;
+ return hdmi;
err_iahb:
if (hdmi->i2c) {
@@ -2055,14 +2042,11 @@ int dw_hdmi_bind(struct platform_device *pdev, struct
drm_encoder *encoder,
err_res:
i2c_put_adapter(hdmi->ddc);
- return ret;
+ return ERR_PTR(ret);
}
-EXPORT_SYMBOL_GPL(dw_hdmi_bind);
-void dw_hdmi_unbind(struct device *dev)
+static void __dw_hdmi_remove(struct dw_hdmi *hdmi)
{
- struct dw_hdmi *hdmi = dev_get_drvdata(dev);
-
if (hdmi->audio && !IS_ERR(hdmi->audio))
platform_device_unregister(hdmi->audio);
@@ -2077,6 +2061,70 @@ void dw_hdmi_unbind(struct device *dev)
else
i2c_put_adapter(hdmi->ddc);
}
+
+/*
-
+ * Probe/remove API, used from platforms based on the DRM bridge API.
+ */
+int dw_hdmi_probe(struct platform_device *pdev,
+ const struct dw_hdmi_plat_data *plat_data)
+{
+ struct dw_hdmi *hdmi;
+ int ret;
+
+ hdmi = __dw_hdmi_probe(pdev, plat_data);
+ if (IS_ERR(hdmi))
+ return PTR_ERR(hdmi);
+
+ ret = drm_bridge_add(&hdmi
[PATCH v2 09/29] drm: bridge: dw-hdmi: Create connector in the bridge attach operation
The DRM device is not guaranteed by the bridge API to be available
before the attach callback. The driver performs properly at the moment
as it doesn't use the drm_bridge_add() registration method. As this will
be changed later, move connector creation to attach time to ensure
compatibility with the API.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jose Abreu
---
drivers/gpu/drm/bridge/dw-hdmi.c | 33 -
1 file changed, 20 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 92ce9e532603..88cd40adb977 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -1667,6 +1667,25 @@ static const struct drm_connector_helper_funcs
dw_hdmi_connector_helper_funcs =
.best_encoder = drm_atomic_helper_best_encoder,
};
+static int dw_hdmi_bridge_attach(struct drm_bridge *bridge)
+{
+ struct dw_hdmi *hdmi = bridge->driver_private;
+ struct drm_encoder *encoder = bridge->encoder;
+ struct drm_connector *connector = &hdmi->connector;
+
+ connector->interlace_allowed = 1;
+ connector->polled = DRM_CONNECTOR_POLL_HPD;
+
+ drm_connector_helper_add(connector, &dw_hdmi_connector_helper_funcs);
+
+ drm_connector_init(bridge->dev, connector, &dw_hdmi_connector_funcs,
+ DRM_MODE_CONNECTOR_HDMIA);
+
+ drm_mode_connector_attach_encoder(connector, encoder);
+
+ return 0;
+}
+
static void dw_hdmi_bridge_mode_set(struct drm_bridge *bridge,
struct drm_display_mode *orig_mode,
struct drm_display_mode *mode)
@@ -1704,6 +1723,7 @@ static void dw_hdmi_bridge_enable(struct drm_bridge
*bridge)
}
static const struct drm_bridge_funcs dw_hdmi_bridge_funcs = {
+ .attach = dw_hdmi_bridge_attach,
.enable = dw_hdmi_bridge_enable,
.disable = dw_hdmi_bridge_disable,
.mode_set = dw_hdmi_bridge_mode_set,
@@ -1829,17 +1849,6 @@ static int dw_hdmi_register(struct drm_encoder *encoder,
struct dw_hdmi *hdmi)
return -EINVAL;
}
- hdmi->connector.polled = DRM_CONNECTOR_POLL_HPD;
-
- drm_connector_helper_add(&hdmi->connector,
-&dw_hdmi_connector_helper_funcs);
-
- drm_connector_init(encoder->dev, &hdmi->connector,
- &dw_hdmi_connector_funcs,
- DRM_MODE_CONNECTOR_HDMIA);
-
- drm_mode_connector_attach_encoder(&hdmi->connector, encoder);
-
return 0;
}
@@ -1862,8 +1871,6 @@ int dw_hdmi_bind(struct platform_device *pdev, struct
drm_encoder *encoder,
if (!hdmi)
return -ENOMEM;
- hdmi->connector.interlace_allowed = 1;
-
hdmi->plat_data = plat_data;
hdmi->dev = dev;
hdmi->dev_type = plat_data->dev_type;
--
Regards,
Laurent Pinchart
[PATCH v2 08/29] drm: bridge: dw-hdmi: Reorder functions to prepare for next commit
The next commit will reference structures and functions in a way that
currently requires forward declarations. Reorder the functions to avoid
that. No functional change to the code is performed.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jose Abreu
---
drivers/gpu/drm/bridge/dw-hdmi.c | 72
1 file changed, 36 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 563cbec47da6..92ce9e532603 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -1575,42 +1575,6 @@ static void dw_hdmi_update_phy_mask(struct dw_hdmi *hdmi)
hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
}
-static void dw_hdmi_bridge_mode_set(struct drm_bridge *bridge,
- struct drm_display_mode *orig_mode,
- struct drm_display_mode *mode)
-{
- struct dw_hdmi *hdmi = bridge->driver_private;
-
- mutex_lock(&hdmi->mutex);
-
- /* Store the display mode for plugin/DKMS poweron events */
- memcpy(&hdmi->previous_mode, mode, sizeof(hdmi->previous_mode));
-
- mutex_unlock(&hdmi->mutex);
-}
-
-static void dw_hdmi_bridge_disable(struct drm_bridge *bridge)
-{
- struct dw_hdmi *hdmi = bridge->driver_private;
-
- mutex_lock(&hdmi->mutex);
- hdmi->disabled = true;
- dw_hdmi_update_power(hdmi);
- dw_hdmi_update_phy_mask(hdmi);
- mutex_unlock(&hdmi->mutex);
-}
-
-static void dw_hdmi_bridge_enable(struct drm_bridge *bridge)
-{
- struct dw_hdmi *hdmi = bridge->driver_private;
-
- mutex_lock(&hdmi->mutex);
- hdmi->disabled = false;
- dw_hdmi_update_power(hdmi);
- dw_hdmi_update_phy_mask(hdmi);
- mutex_unlock(&hdmi->mutex);
-}
-
static enum drm_connector_status
dw_hdmi_connector_detect(struct drm_connector *connector, bool force)
{
@@ -1703,6 +1667,42 @@ static const struct drm_connector_helper_funcs
dw_hdmi_connector_helper_funcs =
.best_encoder = drm_atomic_helper_best_encoder,
};
+static void dw_hdmi_bridge_mode_set(struct drm_bridge *bridge,
+ struct drm_display_mode *orig_mode,
+ struct drm_display_mode *mode)
+{
+ struct dw_hdmi *hdmi = bridge->driver_private;
+
+ mutex_lock(&hdmi->mutex);
+
+ /* Store the display mode for plugin/DKMS poweron events */
+ memcpy(&hdmi->previous_mode, mode, sizeof(hdmi->previous_mode));
+
+ mutex_unlock(&hdmi->mutex);
+}
+
+static void dw_hdmi_bridge_disable(struct drm_bridge *bridge)
+{
+ struct dw_hdmi *hdmi = bridge->driver_private;
+
+ mutex_lock(&hdmi->mutex);
+ hdmi->disabled = true;
+ dw_hdmi_update_power(hdmi);
+ dw_hdmi_update_phy_mask(hdmi);
+ mutex_unlock(&hdmi->mutex);
+}
+
+static void dw_hdmi_bridge_enable(struct drm_bridge *bridge)
+{
+ struct dw_hdmi *hdmi = bridge->driver_private;
+
+ mutex_lock(&hdmi->mutex);
+ hdmi->disabled = false;
+ dw_hdmi_update_power(hdmi);
+ dw_hdmi_update_phy_mask(hdmi);
+ mutex_unlock(&hdmi->mutex);
+}
+
static const struct drm_bridge_funcs dw_hdmi_bridge_funcs = {
.enable = dw_hdmi_bridge_enable,
.disable = dw_hdmi_bridge_disable,
--
Regards,
Laurent Pinchart
[PATCH v2 07/29] drm: bridge: dw-hdmi: Move IRQ and IO resource allocation to common code
There's no need to duplicate identical code in multiple drivers (two at
the moment, one more to come soon). Move it to the dw-hdmi core where it
can be shared. If resource allocation ever becomes device-specific later
we'll always have the option of splitting it out again.
While it at pass the platform device to the bind function to avoid
having to cast struct device to struct platform_device.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jose Abreu
---
drivers/gpu/drm/bridge/dw-hdmi.c| 13 ++---
drivers/gpu/drm/imx/dw_hdmi-imx.c | 12 +---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 12 +---
include/drm/bridge/dw_hdmi.h| 3 +--
4 files changed, 13 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 488dc1a9204f..563cbec47da6 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -1843,14 +1843,16 @@ static int dw_hdmi_register(struct drm_encoder
*encoder, struct dw_hdmi *hdmi)
return 0;
}
-int dw_hdmi_bind(struct device *dev, struct drm_encoder *encoder,
-struct resource *iores, int irq,
+int dw_hdmi_bind(struct platform_device *pdev, struct drm_encoder *encoder,
const struct dw_hdmi_plat_data *plat_data)
{
+ struct device *dev = &pdev->dev;
struct device_node *np = dev->of_node;
struct platform_device_info pdevinfo;
struct device_node *ddc_node;
struct dw_hdmi *hdmi;
+ struct resource *iores;
+ int irq;
int ret;
u32 val = 1;
u8 config0;
@@ -1903,6 +1905,7 @@ int dw_hdmi_bind(struct device *dev, struct drm_encoder
*encoder,
dev_dbg(hdmi->dev, "no ddc property found\n");
}
+ iores = platform_get_resource(pdev, IORESOURCE_MEM, 0);
hdmi->regs = devm_ioremap_resource(dev, iores);
if (IS_ERR(hdmi->regs)) {
ret = PTR_ERR(hdmi->regs);
@@ -1945,6 +1948,10 @@ int dw_hdmi_bind(struct device *dev, struct drm_encoder
*encoder,
initialize_hdmi_ih_mutes(hdmi);
+ irq = platform_get_irq(pdev, 0);
+ if (irq < 0)
+ goto err_iahb;
+
ret = devm_request_threaded_irq(dev, irq, dw_hdmi_hardirq,
dw_hdmi_irq, IRQF_SHARED,
dev_name(dev), hdmi);
@@ -2025,7 +2032,7 @@ int dw_hdmi_bind(struct device *dev, struct drm_encoder
*encoder,
if (hdmi->i2c)
dw_hdmi_i2c_init(hdmi);
- dev_set_drvdata(dev, hdmi);
+ platform_set_drvdata(pdev, hdmi);
return 0;
diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c
b/drivers/gpu/drm/imx/dw_hdmi-imx.c
index f79665801543..f645275e6e63 100644
--- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
+++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
@@ -207,8 +207,6 @@ static int dw_hdmi_imx_bind(struct device *dev, struct
device *master,
struct drm_device *drm = data;
struct drm_encoder *encoder;
struct imx_hdmi *hdmi;
- struct resource *iores;
- int irq;
int ret;
if (!pdev->dev.of_node)
@@ -223,14 +221,6 @@ static int dw_hdmi_imx_bind(struct device *dev, struct
device *master,
hdmi->dev = &pdev->dev;
encoder = &hdmi->encoder;
- irq = platform_get_irq(pdev, 0);
- if (irq < 0)
- return irq;
-
- iores = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!iores)
- return -ENXIO;
-
encoder->possible_crtcs = drm_of_find_possible_crtcs(drm, dev->of_node);
/*
* If we failed to find the CRTC(s) which this encoder is
@@ -249,7 +239,7 @@ static int dw_hdmi_imx_bind(struct device *dev, struct
device *master,
drm_encoder_init(drm, encoder, &dw_hdmi_imx_encoder_funcs,
DRM_MODE_ENCODER_TMDS, NULL);
- ret = dw_hdmi_bind(dev, encoder, iores, irq, plat_data);
+ ret = dw_hdmi_bind(pdev, encoder, plat_data);
/*
* If dw_hdmi_bind() fails we'll never call dw_hdmi_unbind(),
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index e8fb5c56b224..a6d4a0236e8f 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -257,8 +257,6 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct
device *master,
struct drm_device *drm = data;
struct drm_encoder *encoder;
struct rockchip_hdmi *hdmi;
- struct resource *iores;
- int irq;
int ret;
if (!pdev->dev.of_node)
@@ -273,14 +271,6 @@ static int dw_hdmi_rockchip_bind(struct device *dev,
struct device *master,
hdmi->dev = &pdev->dev;
encoder = &hdmi->encoder;
- irq = platform_get_irq(pdev, 0);
- if (irq < 0)
- return irq;
-
- iores = platform_get_resource(pdev, IORESOURCE_MEM, 0);
[PATCH v2 06/29] drm: bridge: dw-hdmi: Don't forward HPD events to DRM core before attach
Hotplug events should only be forwarded to the DRM core by the interrupt
handler when the bridge has been attached, otherwise the DRM device
pointer will be NULL, resulting in a crash.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jose Abreu
---
drivers/gpu/drm/bridge/dw-hdmi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index ef10bb866b2f..488dc1a9204f 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -1805,7 +1805,8 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
if (intr_stat & HDMI_IH_PHY_STAT0_HPD) {
dev_dbg(hdmi->dev, "EVENT=%s\n",
phy_int_pol & HDMI_PHY_HPD ? "plugin" : "plugout");
- drm_helper_hpd_irq_event(hdmi->bridge.dev);
+ if (hdmi->bridge.dev)
+ drm_helper_hpd_irq_event(hdmi->bridge.dev);
}
hdmi_writeb(hdmi, intr_stat, HDMI_IH_PHY_STAT0);
--
Regards,
Laurent Pinchart
[PATCH v2 05/29] drm: bridge: dw-hdmi: Remove encoder field from struct dw_hdmi
The field isn't needed, remove it.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jose Abreu
---
drivers/gpu/drm/bridge/dw-hdmi.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 2c85b6c07a80..ef10bb866b2f 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -115,7 +115,6 @@ struct dw_hdmi_i2c {
struct dw_hdmi {
struct drm_connector connector;
- struct drm_encoder *encoder;
struct drm_bridge bridge;
struct platform_device *audio;
@@ -1816,9 +1815,8 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
return IRQ_HANDLED;
}
-static int dw_hdmi_register(struct drm_device *drm, struct dw_hdmi *hdmi)
+static int dw_hdmi_register(struct drm_encoder *encoder, struct dw_hdmi *hdmi)
{
- struct drm_encoder *encoder = hdmi->encoder;
struct drm_bridge *bridge = &hdmi->bridge;
int ret;
@@ -1835,7 +1833,7 @@ static int dw_hdmi_register(struct drm_device *drm,
struct dw_hdmi *hdmi)
drm_connector_helper_add(&hdmi->connector,
&dw_hdmi_connector_helper_funcs);
- drm_connector_init(drm, &hdmi->connector,
+ drm_connector_init(encoder->dev, &hdmi->connector,
&dw_hdmi_connector_funcs,
DRM_MODE_CONNECTOR_HDMIA);
@@ -1867,7 +1865,6 @@ int dw_hdmi_bind(struct device *dev, struct drm_encoder
*encoder,
hdmi->dev = dev;
hdmi->dev_type = plat_data->dev_type;
hdmi->sample_rate = 48000;
- hdmi->encoder = encoder;
hdmi->disabled = true;
hdmi->rxsense = true;
hdmi->phy_mask = (u8)~(HDMI_PHY_HPD | HDMI_PHY_RX_SENSE);
@@ -1980,7 +1977,7 @@ int dw_hdmi_bind(struct device *dev, struct drm_encoder
*encoder,
if (ret)
goto err_iahb;
- ret = dw_hdmi_register(encoder->dev, hdmi);
+ ret = dw_hdmi_register(encoder, hdmi);
if (ret)
goto err_iahb;
--
Regards,
Laurent Pinchart
[PATCH v2 04/29] drm: bridge: dw-hdmi: Embed drm_bridge in struct dw_hdmi
The drm_bridge instance is always needed, there's no point in allocating
it separately.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jose Abreu
---
drivers/gpu/drm/bridge/dw-hdmi.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 5f8044a7d602..2c85b6c07a80 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -116,7 +116,7 @@ struct dw_hdmi_i2c {
struct dw_hdmi {
struct drm_connector connector;
struct drm_encoder *encoder;
- struct drm_bridge *bridge;
+ struct drm_bridge bridge;
struct platform_device *audio;
enum dw_hdmi_devtype dev_type;
@@ -1806,7 +1806,7 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
if (intr_stat & HDMI_IH_PHY_STAT0_HPD) {
dev_dbg(hdmi->dev, "EVENT=%s\n",
phy_int_pol & HDMI_PHY_HPD ? "plugin" : "plugout");
- drm_helper_hpd_irq_event(hdmi->bridge->dev);
+ drm_helper_hpd_irq_event(hdmi->bridge.dev);
}
hdmi_writeb(hdmi, intr_stat, HDMI_IH_PHY_STAT0);
@@ -1819,16 +1819,9 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
static int dw_hdmi_register(struct drm_device *drm, struct dw_hdmi *hdmi)
{
struct drm_encoder *encoder = hdmi->encoder;
- struct drm_bridge *bridge;
+ struct drm_bridge *bridge = &hdmi->bridge;
int ret;
- bridge = devm_kzalloc(drm->dev, sizeof(*bridge), GFP_KERNEL);
- if (!bridge) {
- DRM_ERROR("Failed to allocate drm bridge\n");
- return -ENOMEM;
- }
-
- hdmi->bridge = bridge;
bridge->driver_private = hdmi;
bridge->funcs = &dw_hdmi_bridge_funcs;
ret = drm_bridge_attach(encoder, bridge, NULL);
--
Regards,
Laurent Pinchart
[PATCH v2 03/29] drm: bridge: dw-hdmi: Remove unused function parameter
From: Kieran Bingham
The 'prep' parameter passed to hdmi_phy_configure() is useless. It is
hardcoded as 0, and if set, simply prevents the configure function from
executing.
Remove it.
Signed-off-by: Kieran Bingham
Signed-off-by: Laurent Pinchart
Reviewed-by: Jose Abreu
---
drivers/gpu/drm/bridge/dw-hdmi.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index f86894622070..5f8044a7d602 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -931,7 +931,7 @@ static void dw_hdmi_phy_sel_interface_control(struct
dw_hdmi *hdmi, u8 enable)
HDMI_PHY_CONF0_SELDIPIF_MASK);
}
-static int hdmi_phy_configure(struct dw_hdmi *hdmi, unsigned char prep,
+static int hdmi_phy_configure(struct dw_hdmi *hdmi,
unsigned char res, int cscon)
{
unsigned res_idx;
@@ -941,9 +941,6 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi,
unsigned char prep,
const struct dw_hdmi_curr_ctrl *curr_ctrl = pdata->cur_ctr;
const struct dw_hdmi_phy_config *phy_config = pdata->phy_config;
- if (prep)
- return -EINVAL;
-
switch (res) {
case 0: /* color resolution 0 is 8 bit colour depth */
case 8:
@@ -1072,7 +1069,7 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi)
dw_hdmi_phy_enable_powerdown(hdmi, true);
/* Enable CSC */
- ret = hdmi_phy_configure(hdmi, 0, 8, cscon);
+ ret = hdmi_phy_configure(hdmi, 8, cscon);
if (ret)
return ret;
}
--
Regards,
Laurent Pinchart
[PATCH v2 02/29] drm: bridge: dw-hdmi: Remove unneeded arguments to bind/unbind functions
The master argument isn't used. The data argument, a void pointer, is
used by the bind function only where it's cast to a drm_device pointer,
which can easily be obtained from the encoder argument instead. Remove
them.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jose Abreu
---
drivers/gpu/drm/bridge/dw-hdmi.c| 8 +++-
drivers/gpu/drm/imx/dw_hdmi-imx.c | 4 ++--
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 4 ++--
include/drm/bridge/dw_hdmi.h| 5 ++---
4 files changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index a6685502571e..f86894622070 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -1854,12 +1854,10 @@ static int dw_hdmi_register(struct drm_device *drm,
struct dw_hdmi *hdmi)
return 0;
}
-int dw_hdmi_bind(struct device *dev, struct device *master,
-void *data, struct drm_encoder *encoder,
+int dw_hdmi_bind(struct device *dev, struct drm_encoder *encoder,
struct resource *iores, int irq,
const struct dw_hdmi_plat_data *plat_data)
{
- struct drm_device *drm = data;
struct device_node *np = dev->of_node;
struct platform_device_info pdevinfo;
struct device_node *ddc_node;
@@ -1992,7 +1990,7 @@ int dw_hdmi_bind(struct device *dev, struct device
*master,
if (ret)
goto err_iahb;
- ret = dw_hdmi_register(drm, hdmi);
+ ret = dw_hdmi_register(encoder->dev, hdmi);
if (ret)
goto err_iahb;
@@ -2059,7 +2057,7 @@ int dw_hdmi_bind(struct device *dev, struct device
*master,
}
EXPORT_SYMBOL_GPL(dw_hdmi_bind);
-void dw_hdmi_unbind(struct device *dev, struct device *master, void *data)
+void dw_hdmi_unbind(struct device *dev)
{
struct dw_hdmi *hdmi = dev_get_drvdata(dev);
diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c
b/drivers/gpu/drm/imx/dw_hdmi-imx.c
index 359cd2765552..f79665801543 100644
--- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
+++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
@@ -249,7 +249,7 @@ static int dw_hdmi_imx_bind(struct device *dev, struct
device *master,
drm_encoder_init(drm, encoder, &dw_hdmi_imx_encoder_funcs,
DRM_MODE_ENCODER_TMDS, NULL);
- ret = dw_hdmi_bind(dev, master, data, encoder, iores, irq, plat_data);
+ ret = dw_hdmi_bind(dev, encoder, iores, irq, plat_data);
/*
* If dw_hdmi_bind() fails we'll never call dw_hdmi_unbind(),
@@ -264,7 +264,7 @@ static int dw_hdmi_imx_bind(struct device *dev, struct
device *master,
static void dw_hdmi_imx_unbind(struct device *dev, struct device *master,
void *data)
{
- return dw_hdmi_unbind(dev, master, data);
+ return dw_hdmi_unbind(dev);
}
static const struct component_ops dw_hdmi_imx_ops = {
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 0665fb915579..e8fb5c56b224 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -301,7 +301,7 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct
device *master,
drm_encoder_init(drm, encoder, &dw_hdmi_rockchip_encoder_funcs,
DRM_MODE_ENCODER_TMDS, NULL);
- ret = dw_hdmi_bind(dev, master, data, encoder, iores, irq, plat_data);
+ ret = dw_hdmi_bind(dev, encoder, iores, irq, plat_data);
/*
* If dw_hdmi_bind() fails we'll never call dw_hdmi_unbind(),
@@ -316,7 +316,7 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct
device *master,
static void dw_hdmi_rockchip_unbind(struct device *dev, struct device *master,
void *data)
{
- return dw_hdmi_unbind(dev, master, data);
+ return dw_hdmi_unbind(dev);
}
static const struct component_ops dw_hdmi_rockchip_ops = {
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index bae79f3c4d28..11edda631a9d 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -56,9 +56,8 @@ struct dw_hdmi_plat_data {
struct drm_display_mode *mode);
};
-void dw_hdmi_unbind(struct device *dev, struct device *master, void *data);
-int dw_hdmi_bind(struct device *dev, struct device *master,
-void *data, struct drm_encoder *encoder,
+void dw_hdmi_unbind(struct device *dev);
+int dw_hdmi_bind(struct device *dev, struct drm_encoder *encoder,
struct resource *iores, int irq,
const struct dw_hdmi_plat_data *plat_data);
--
Regards,
Laurent Pinchart
[PATCH v2 01/29] drm: bridge: dw-hdmi: Merge __hdmi_phy_i2c_write and hdmi_phy_i2c_write
The latter is just an int wrapper around the former void function that
unconditionally returns 0. As the return value is never checked, merge
the two functions into one.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jose Abreu
---
drivers/gpu/drm/bridge/dw-hdmi.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index f5009ae39b89..a6685502571e 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -868,7 +868,7 @@ static bool hdmi_phy_wait_i2c_done(struct dw_hdmi *hdmi,
int msec)
return true;
}
-static void __hdmi_phy_i2c_write(struct dw_hdmi *hdmi, unsigned short data,
+static void hdmi_phy_i2c_write(struct dw_hdmi *hdmi, unsigned short data,
unsigned char addr)
{
hdmi_writeb(hdmi, 0xFF, HDMI_IH_I2CMPHY_STAT0);
@@ -882,13 +882,6 @@ static void __hdmi_phy_i2c_write(struct dw_hdmi *hdmi,
unsigned short data,
hdmi_phy_wait_i2c_done(hdmi, 1000);
}
-static int hdmi_phy_i2c_write(struct dw_hdmi *hdmi, unsigned short data,
- unsigned char addr)
-{
- __hdmi_phy_i2c_write(hdmi, data, addr);
- return 0;
-}
-
static void dw_hdmi_phy_enable_powerdown(struct dw_hdmi *hdmi, bool enable)
{
hdmi_mask_writeb(hdmi, !enable, HDMI_PHY_CONF0,
--
Regards,
Laurent Pinchart
[PATCH v2 00/29] R-Car Gen3 HDMI output support
Hello, This patch series implements support for the HDMI output on Renesas R-Car Gen3 SoCs, and more specifically on the R-Car H3. R-Car Gen3 SoCs include one or multiple Synopsys DWC HDMI TX controllers. The series thus starts with 20 cleanup or feature patches for the dw-hdmi driver. Patches 01/29 to 05/29 are small miscellaneous cleanups. Patch 06/29 fixes a crash when the HPD interrupt is generated before the bridge gets attached to a DRM device. Patch 07/29 then starts refactoring the API towards platform glue by moving common I/O and clock resource allocation to common code. Patches 08/29 and 09/29 continue by moving connector creation to the bridge attach operation to comply with the DRM bridge API. Patch 10/29 implements a new API for platform glue to register the bridge with the DRM core, for platform that doesn't use the component framework. Patches 11/29 to 20/29 refactor platform support in the dw-hdmi driver. This is the largest change compared to v1. Patch 11/29 is a small cleanup and patch 12/29 a register rename to match available documentation. Patch 13/29 starts making use of the hardware product ID to reject invalid devices and patch 14/29 and 15/29 continue with refactoring of audio DMA detection and overflow workaround handling based on the device version. Patch 16/29 adds PHY type detection at runtime and patch 17/29 reworks PHY power handling accordingly. Patches 18/29 and 19/29 add support for custom PHYs, and patch 20/29 finally removes the now unneeded device type field from platform data. The next three patches add glue code for the DWC HDMI on Renesas R-Car Gen3 platforms. Patch 21/29 rework the DWC HDMI DT bindings to make them more modular, and patch 22/29 makes use of them to document the R-Car Gen DWC HDMI TX DT bindings. Patch 23/29 then implements the platform glue code. The next three patches implement support for the R8A7795 HDMI outputs in the R-Car DU driver. Patch 24/29 fixes a bug that makes the driver defer probe forever if an encoder is disabled. Patch 25/29 implements DPLL support to generate more precise clocks required by the HDMI controller, and patch 26/29 then enables the two HDMI output on the R-Car H3 SoC. The last three patches enable the HDMI outputs on the H3 Salvator-X board by adding the HDMI encoders to the R-Car H3 DT (27/29), adding HDMI connectors and enabling the encoders (28/29) and adding the external dot clocks (29/29). I have tested the code on a Renesas Salvator-X H3 board, a Rockchip RK3288 Rock2 board and an IMX6Q Rex Pro board. No issue due to the dw-hdmi rework have been observed. More improvements to the dw-hdmi driver would be beneficial. The PHY modularization is based on the limited understanding of the HDMI PHYs used on the three supported platforms and will possibly be enhanced later when adding support for more platforms. The PHY used on Renesas platforms is probably generic, but due to limited documentation and unavailability of public datasheets from Synopsys I can't at the moment determine if the code could be shared. I propose addressing this when another platform will be merged in mainline using the same PHY. The DT bindings would also benefit from a standardized definition of the ports, and the reg-io-width property could possibly be deprecated in favour of encoding the information in platform glue code. The patch series is however big enough as is to be submitted for review and merge before the dw-hdmi driver achieves perfection. Kieran Bingham (4): drm: bridge: dw-hdmi: Remove unused function parameter drm: bridge: dw-hdmi: Remove PHY configuration resolution parameter drm: bridge: dw-hdmi: Add support for custom PHY configuration drm: bridge: dw-hdmi: Remove device type from platform data Koji Matsuoka (4): drm: rcar-du: Add Gen3 HDMI encoder support drm: rcar-du: Add DPLL support drm: rcar-du: Add HDMI outputs to R8A7795 device description arm64: dts: r8a7795: salvator-x: Enable HDMI outputs Laurent Pinchart (20): drm: bridge: dw-hdmi: Merge __hdmi_phy_i2c_write and hdmi_phy_i2c_write drm: bridge: dw-hdmi: Remove unneeded arguments to bind/unbind functions drm: bridge: dw-hdmi: Embed drm_bridge in struct dw_hdmi drm: bridge: dw-hdmi: Remove encoder field from struct dw_hdmi drm: bridge: dw-hdmi: Don't forward HPD events to DRM core before attach drm: bridge: dw-hdmi: Move IRQ and IO resource allocation to common code drm: bridge: dw-hdmi: Reorder functions to prepare for next commit drm: bridge: dw-hdmi: Create connector in the bridge attach operation drm: bridge: dw-hdmi: Implement DRM bridge registration drm: bridge: dw-hdmi: Rename CONF0 SPARECTRL bit to SVSRET drm: bridge: dw-hdmi: Reject invalid product IDs drm: bridge: dw-hdmi: Detect AHB audio DMA using correct register drm: bridge: dw-hdmi: Handle overflow workaround based on device version drm: bridge: dw-hdmi: Detect PHY type at runtime drm: bridge: dw-hdmi: Refactor PHY power handlin
[PATCH] fbdev: remove current maintainer
Hi Daniel, On Thursday 08 Dec 2016 11:04:47 Daniel Vetter wrote: > On Thu, Dec 08, 2016 at 10:34:12AM +0200, Tomi Valkeinen wrote: > > Remove Tomi Valkeinen from fbdev maintainer and mark fbdev as orphan. > > > > Signed-off-by: Tomi Valkeinen > > --- > > > > I just don't have time to even pretend I maintain fbdev, so mark it as > > Orphan. > > > > Anyone want to pick fbdev maintainership? > > I think for fbdev stuff that we need for the fbdev emulation in drm we > could merge it through drm-misc. Or we could instead invest time on getting rid of that last dependency on fbdev ? :-) > And I'd very much welcome if you can > still review those patches (e.g. the nommu enabling that's floating right > now). If you want can also give you commit rights to drm-misc for that > area. Or drm-misc maintainers can apply those patches. > > Anything else would be still out of scope ofc. > > What we might want to do is add dri-devel to the mailing lists, to make > sure patch submissions get redicted to the right subsystem. Mail volume > seems pretty low compared to dri-devel, I think we can absorb that. > -Daniel > > > MAINTAINERS | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 851b89b9edcb..fc2790eb4e84 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -4968,10 +4968,9 @@ F: drivers/net/wan/dlci.c > > > > F: drivers/net/wan/sdla.c > > > > FRAMEBUFFER LAYER > > > > -M: Tomi Valkeinen > > > > L: linux-fbdev at vger.kernel.org > > Q: http://patchwork.kernel.org/project/linux-fbdev/list/ > > > > -S: Maintained > > +S: Orphan > > > > F: Documentation/fb/ > > F: drivers/video/ > > F: include/video/ -- Regards, Laurent Pinchart
[RFC 0/4] Introduce drmfs pseudo filesystem for drm subsystem
Hi Swati, On Monday 19 Dec 2016 16:12:22 swati.dhingra at intel.com wrote: > From: Swati Dhingra > > Currently, we don't have a stable ABI which can be used for the purpose of > providing output debug/loggging/crc and other such data from DRM. > The ABI in current use (filesystems, ioctls, et al.) have their own > constraints and are intended to output a particular type of data. > Few cases in point: > sysfs - stable ABI, but constrained to one textual value per file > debugfs - unstable ABI, free-for-all > ioctls- not as suitable to many single purpose continuous data > dumping, we would very quickly run out ioctl space; requires more > userspace support than "cat" > device nodes - a real possibilty, kernel instantiation is more tricky, > requires udev (+udev.rules) or userspace discovery of the > dynamic major:minor (via sysfs) [mounting a registered > filesystem is easy in comparison] > netlink - stream based, therefore involves numerous copies. > > Debugfs is the lesser among the evils here, thereby we have grown used to > the convenience and flexibility in presentation that debugfs gives us > (including relayfs inodes) that we want some of that hierachy in stable user > ABI form. Seriously, why ? A subsystem growing its own file system sounds so wrong. It seems that you want to have all the benefits of a stable ABI without going through the standardization effort that this requires. I can see so many ways that drmfs could be abused, with drivers throwing in new data with little or no review. You'll need very compelling arguments to convince me. > Due to these limitations, there is a need for a new pseudo filesytem, that > would act as a stable 'free-for-all' ABI, with the heirarchial structure and > thus convenience of debugfs. This will be managed by drm, thus named > 'drmfs'. DRM would register this filesystem to manage a canonical > mountpoint, but this wouldn't limit everyone to only using that pseudofs > underneath. > > This can serve to hold various kinds of output data from Linux DRM > subsystems, for the files which can't truely fit anywhere else with > existing ABI's but present so, for the lack of a better place. > > In this patch series, we have introduced a pseudo filesystem named as > 'drmfs' for now. The filesystem is introduced in the first patch, and the > subsequent patches make use of the filesystem interfaces, in drm driver, > and making them available for use by the drm subsystem components, one of > which is i915. We've moved the location of i915 GuC logs from debugfs to > drmfs in the last patch. Subsequently, more such files such as pipe_crc, > error states, memory stats, etc. can be move to this filesystem, if the > idea introduced here is acceptable per se. The filesystem introduced is > being used to house the data generated by i915 driver in this patch series, > but will hopefully be generic enough to provide scope for usage by any > other drm subsystem component. > > The patch series is being floated as RFC to gather feedback on the idea and > infrastructure proposed here and it's suitability to address the specific > problem statement/use case. > > v2: fix the bat failures caused due to missing config check > > v3: Changes made: > - Move the location of drmfs from fs/ to drivers/gpu/drm/ (Chris) > - Moving config checks to header (Chris,Daniel) > > v4: Added the kernel Documentaion (using Sphinx). > > Sourab Gupta (4): > drm: Introduce drmfs pseudo filesystem interfaces > drm: Register drmfs filesystem from drm init > drm: Create driver specific root directory inside drmfs > drm/i915: Creating guc log file in drmfs instead of debugfs > > Documentation/gpu/drm-uapi.rst | 76 > drivers/gpu/drm/Kconfig| 9 + > drivers/gpu/drm/Makefile | 1 + > drivers/gpu/drm/drm_drv.c | 26 ++ > drivers/gpu/drm/drmfs.c| 566 ++ > drivers/gpu/drm/i915/i915_guc_submission.c | 33 +- > include/drm/drm_drv.h | 3 + > include/drm/drmfs.h| 77 > include/uapi/linux/magic.h | 3 + > 9 files changed, 773 insertions(+), 21 deletions(-) > create mode 100644 drivers/gpu/drm/drmfs.c > create mode 100644 include/drm/drmfs.h -- Regards, Laurent Pinchart
[Bug 97980] [amdgpu] New kernel warning during shutdown
https://bugs.freedesktop.org/show_bug.cgi?id=97980 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161220/17e89216/attachment.html>
